Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grsecurity: Potential contributory infringement and breach of contract risk

perens.com

Post reply on HN
Print view View original

51–60 of 128 posts

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#51

Post by cma »

drewcrawford wrote: post #43
gizmo686 wrote: post #27

Earlier quoted context omitted.

GPLv2, section 6: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to…

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

He's talking about the right granted in the contract, not something analogous to the right of no government abridgment of free speech.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#52

Post by Jach »

drewcrawford wrote: post #13

> Currently, Grsecurity is a commercial product and is distributed only to paying customers. My understanding from several reliable sources is that customers are verbally or otherwise warned that if they redistribute the Grsecurity patch, as would be their right under the GPL, that they will be assessed a penalty: they will no longer be allowed to be customers, and will not be granted access to any further versions o…

Seems pretty clear. They cannot stop you from redistributing the binary of v1, and anyone you redistribute the binary to can demand the source if it's not already included. They can say that if they find out you redistributed v1, they're not going to give you v2 in the future, but if you get v2 some other way you can still ask for the source (and whoever distributed that one might not get v3 etc.). There may be further restrictions from trademarks to make redistribution perfectly legal (like CentOS just removing mentions of RHEL) but it can quickly become a lost battle for upstream.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#53

Post by fooker »

microwavecamera wrote: post #26
zzalpha wrote: post #2

Edit: I replied too soon and misunderstood the core of Peren's argument. His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes. At issue is this agreement: https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the s…

The difference with something like Nvidia's proprietary driver is that it interfaces with the kernel through the kernel's API as a kernel module, which is fine under the GPLv2, assuming you're not Richard Stallman. Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your…

>Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your own.

That is not actually true. That's why LGPL exists.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#55

Post by SwellJoe »

protomyth wrote: post #36
SwellJoe wrote: post #32

Earlier quoted context omitted.

"They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination." Red Hat does not contractually bind anyone to not distribute source. They just don't. They distribute the source themselves, without contract or cost. And, Red Hat employs several of the largest contributors to the mainline Linux kernel. Most of the time, if something is in the RHEL kernel,…

Ok, so what is Red Hat contractually binding me not to do? Am I misunderstanding what makomk is trying to say?

The only thing I'm aware of that Red Hat sort of locks away is their documentation and knowledge base, as well as the binary builds. It contains specific information about patches that backport CVE fixes, bugfixes, etc. The kernel sources are maintained in an internal revision control system and pushed out as a tarball (which is then integrated into CentOS and other RHEL derived distros).

There is a wealth of knowledge in there if you're looking to solve specific enterprisey problems, but it's not necessary to have access to any of it to track what changes Red Hat makes to their kernels and to reproduce them from freely obtainable sources. I don't think you're even prohibited from sharing what you learn from their customer portal resources; though copy-pasting the whole thing into the wild is certainly a copyright and/or license violation and might get you some sort of trouble.

But, the premise of the comparison that Red Hat will somehow penalize someone for distributing RH sources (which has also been alleged in this thread) is just wrong. You can get and copy and modify and redistribute the kernel sources from RH; whether you get it as a paying customer in the form of RHEL or from CentOS for free. Red Hat will not penalize you for doing so, nor will they end any contracts you have with them.

The change to a mashed together tarball rather than a mainline kernel with patches applied was a direct response to Oracle rebuilding RHEL from sources and calling it Oracle Linux. It's unfortunate (I used to maintain a bunch of kernel RPMs, and it was nice having all the independent patches), but it's not a violation of the license, and it's still entirely possible to distribute custom RHEL-based kernels; you just have to actually know what you're doing to do so. There's no more copypasta-custom kernel building, in the general case. If you follow their kernels, maybe keeping your own revision control of them, you can see what changes between each revision, and it would be possible to parse out the specific patches in a lot of cases with relative ease. But, none of that is necessary to be compliant with the GPL.

The GPL requires you make the source code available to anyone you distribute to, and under the same terms as the kernel itself. Red Hat does exactly that (and then some, by maintaining CentOS).

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#56

Post by protomyth »

mobilethrow wrote: post #41
protomyth wrote: post #36

Earlier quoted context omitted.

Ok, so what is Red Hat contractually binding me not to do? Am I misunderstanding what makomk is trying to say?

While Red Hats individual kernel patches are not available, they distribute the "squashed" sources under the terms of the GPL.

Thanks for the answer. Is the removal of the context of the changes generally considered acceptable? We have a Red Hat license, but frankly, I am more a BSD person and our use of Red Hat is a requirement for specific programs.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#57

Post by SwellJoe »

drewcrawford wrote: post #45
SwellJoe wrote: post #14

Earlier quoted context omitted.

"Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff." I don't know about Oracle, but I know about Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it, they dist…

> Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it Of course they prohibit it. e.g. from [1] > This EULA does not permit you to distribute the Programs or their components using Red Hat's trademarks, regardless of whether the copy has been modified. You may make a commercial redistribution of the Programs only if (a) permitted under a separate written agreement…

Your first quote covers trademarks. That is unrelated to source code. CentOS ships with a different set of trademarks. If you want to rebuild and redistribute the RH sources, you remove the trademarks. That's well understood and well within the terms of the GPL.

Second refers to binary builds of the software. Also well within the terms of the GPL.

Third refers to the Subscription Service which includes access to binary builds, access to a customer portal with knowledge base, private support tickets, etc.

None of these refer to distribution of source, which is explicitly permitted by Red Hat.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#58

Post by simcop2387 »

I've got a question about this whole GPL enforcement issue.

Scenario:

I'm a VPS company, I provide my customers with kernels compiled with GRSec. I provide a number of modules for different protocols, nftables, etc. with the custom kernels i've built for the VMs. Under the GPL I have to provide the patched source of all those modules (and kernel If I provide that image too) to my customer.

Question:

With GRSec's reported threat of no longer being allowed to be a customer of theirs if I provide the legally required source to my customer, does this mean I can no longer reconcile their two licenses and means that I cannot use their kernel patches for my customers?

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#59

Post by jbapple »

drewcrawford wrote: post #43
gizmo686 wrote: post #27

Earlier quoted context omitted.

GPLv2, section 6: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to…

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

> In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it.

Are you sure about this? Are you an attorney? I am not.

I ask because it was my impression that, more than each individual having a right to free speech, each individual has a right to be free from a certain set of governmental restrictions or punishments for their speech, and that this is also true of the non-governmental-employer-employee relationship, but the set is smaller.

For instance, it was my impression that:

(A) People who are not governmental employees have the right to be free from the government restricting them from criticizing Congress in most locations at most times (and have the right to be free from the government punishing them for this criticism)

(B) Governmental employees have fewer rights that (A) in certain respects related to their employment

(C) People who are non-governmental employees can generally be fired for their speech, though not for certain speech, like stating that she is pregnant or whistleblowing to the federal government (under some circumstances)

But I am not a lawyer.

Re: Grsecurity: Potential contributory infringement and breach of contract risk

#60

Post by gizmo686 »

drewcrawford wrote: post #43
gizmo686 wrote: post #27

Earlier quoted context omitted.

GPLv2, section 6: "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to…

> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text. It is a fundamental misunderstanding of the law, and it is not (an open) question of law. In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fi…

In the US, your only "right" to free speech is protection from the government restricting your speech. Indeed, if your employer is the government, then there are significant (but not absolute) limitations on how much they can retaliate for your speech.
Post reply on HN