SoylentNews is people
SoylentNews
Grsecurity is a patch for the Linux kernel which, it is claimed, improves its security. It is a derivative work of the Linux kernel which touches the kernel internals in many different places. It is inseparable from Linux and can not work without it. it would fail a fair-use test (obviously, ask offline if you don’t understand). Because of its strongly derivative nature of the kernel, it must be under the GPL version 2 license, or a license compatible with the GPL and with terms no more restrictive than the GPL. Earlier versions were distributed under GPL version 2.
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 of Grsecurity. GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition.
By operating under their policy of terminating customer relations upon distribution of their GPL-licensed software, Open Source Security Inc., the owner of Grsecurity, creates an expectation that the customer’s business will be damaged by losing access to support and later versions of the product, if that customer exercises their re-distribution right under the GPL license. This is tantamount to the addition of a term to the GPL prohibiting distribution or creating a penalty for distribution. GPL section 6 specifically prohibits any addition of terms. Thus, the GPL license, which allows Grsecurity to create its derivative work of the Linux kernel, terminates, and the copyright of the Linux Kernel is infringed. The contract from the Linux kernel developers to both Grsecurity and the customer which is inherent in the GPL is breached.
(Score: 5, Informative) by requerdanos on Thursday July 06 2017, @12:18PM (11 children)
(Almost) No one was talking about grsecurity for a while, but their recent mention on LKML seems to have raised interest again.
At the time that grsecurity "went dark", I wondered where one could download the clean binaries a la RHEL/Centos, or at least the gr source (or patch set), but never found a place. Then seeing that other projects depending on grsecurity were terminated because of lack of grsecurity availability kind of confirmed that there was nowhere to get it.
Perens, I believe, has parsed the situation exactly correctly. The terms of the GPL2 [gnu.org] are clear: Term 6, "... You may not impose any further restrictions on the recipients' exercise of the rights granted herein ..." means that one can't place additional restrictions, as Perens points out -- in fact, the license affirms that customers (those receiving the distributed program or code) specifically may distribute it verbatim (term 1), or even distribute compiled versions (not just source)(term 3).
Further, term 4 states that "You may not... sublicense, or distribute the Program except as expressly provided under this License." Which is what grsecurity isn't complying with (they are distributing and sublicensing under *different* terms with additional restrictions). Term 4 continues... "Any attempt otherwise to... sublicense or distribute the Program... will automatically terminate your rights under this License." Game over. Grsecurity has no right to distribute modified versions of the Linux kernel.
As to "contributory infringement", term 4 says "However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. " So if you comply with grsecurity's wishes, you are infringing and your rights are terminated, which is okay because to comply with grsecurity's wishes, you don't need the right to modify or distribute their kernels because you won't be doing it.
I say it's okay because of term 5, which explains "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works." It is fine not to comply with a license that you have not accepted, and you do not need to accept the GPL to use a GPL'd program. Not complying just means you can't modify nor distribute.
These terms are detailed and intricate, but not complicated. It would be interesting to read a (coherent) argument in favor of grsecurity's position.
(Score: 1, Interesting) by Anonymous Coward on Thursday July 06 2017, @01:49PM (6 children)
If GRSECURITY is distributing patches it doesn't violate the GPL, or qualify as a derivative work, unless it explicitly includes copyrighted code from the linux kernel and doesn't qualify under the interoperation clauses. Otherwise the ZFS on Linux patches, BSD in general (go look at how many non-BSD licenses are available as both non-default and default build options in Open/Free/NetBSD kernels!) and many other things (including all software operating on top of Oracle/Microsoft operating systems!) would qualify as derived works and fall under the copyright jurisdiction of their relevant dictators.
Furthermore, what took Bruce so long? This happened like 4-5 years ago. It was discussed lots when they were closing it up, and there has been plenty of time for a lawsuit to make its way through the courts, if anybody cared, or if they were really in violation.
Given all this, I am inclined to ask: 'Who cares?'
GRSecurity was a big thing 20 years ago to about 10 years ago, but it is irrelevant today.
(Score: 4, Interesting) by pendorbound on Thursday July 06 2017, @02:06PM (1 child)
Read up on GPL and derivative work, as well as Linus' own writing [yarchive.net] on the topic. The key distinction between GRSec and ZFS is that ZFS is a driver originally written for another operating system that was ported to Linux. It's not a derived work because it is a work unto itself that was adapted to also work with Linux. Linus describes the AFS driver as, "something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin)."
GRSec is fundamentally different because it has no life without the kernel. It's designed explicitly and exclusively to be used with the kernel. Distributing it as patches *might* (but probably doesn't) exclude the patchset from being GPL. Problem for them is that it's distributed with the explicit intent of merging those patches with the base kernel. As soon as that merge is completed, the resulting work is GPL because the kernel is GPL. A user then has the freedom under the GPL to redistribute that resultant work under GPL. Any attempt to prevent them from doing so is a GPL violation. GRSec's threats against their customers distributing the resultant work is a violation.
(Score: 2) by Wootery on Friday July 07 2017, @08:59AM
This is the same reasoning Torvalds applies to nVidia's binary-blob graphics drivers. Strikes me as a fairly scary loophole, but where one should draw the line is a difficult question.
Obviously derivative: deeply-integrated Linux-specific machinery like SELinux. Obviously non-derivative: connecting to a web-server which happens to run Linux. Much lies between the two extremes.
Of course, in a court of law, it doesn't matter much what Torvalds and Stallman think the licence means.
(Score: 0) by Anonymous Coward on Thursday July 06 2017, @02:19PM (1 child)
Patch files include significant portions of the original work, so I think this argument is wrong on the face of it.
Uh no, this happened just a couple months ago (around March I think), when grsecurity pulled the public "testing" patches and started actually cancelling people's subscriptions for exercising permissions granted to them by the GPL. They were unhappy with the fact that KSPP was getting their stuff merged into mainline Linux.
I don't think this is a long-term successful plan for grsecurity because all the distributions hate them now, and the community isn't going to be putting in any effort to make sure things work with grsecurity anymore.
(Score: 2) by Bot on Thursday July 06 2017, @02:32PM
Eh, this is the side effect of the popularity of the GPL. It gets adopted by people for convenience, not because they believe in freedom. No matter how much you invest in a linux based project, what you get in return from it is an order of magnitude more. So, idealism aside, they are still in debt with free software, no matter what. And if they do not recognize this, I am afraid I am going to stop trusting them for everything else.
Account abandoned.
(Score: 4, Insightful) by Bot on Thursday July 06 2017, @02:27PM (1 child)
the patch will always be used with the kernel, so claiming it is not derivative is valid only for those people who will take the patch print it out, put the result in a frame and display it as modern art.
Account abandoned.
(Score: 4, Insightful) by requerdanos on Thursday July 06 2017, @03:48PM
There's interesting reading on this topic at grsecurity's web site, where they explain [grsecurity.net] that certain features are present in the, quote, "grsecurity kernels":
(Emphasis added)
grsecurity makes a strong case on this page that their product is a derivative of the stock Linux kernel, to which their grsecurity kernels are directly compared.
(Score: 5, Informative) by TheRaven on Friday July 07 2017, @09:16AM (3 children)
I'll give it a go, in the interests of playing devil's advocate (as I understand their position):
They grant you access to their code under GPLv2. Nothing that you do will affect this. They permit you to do everything that GPLv2 permits. If you choose to exercise these rights in a particular way, then they will refuse to do business with you in the future. Your rights to the code that you have already received under GPLv2 are unaffected. You may continue to use, modify, or distribute this code as you wish, but you will not receive any further updates from them. They're not infringing the GPL, because they never restrict what you can do with the code that you have already received - their license does not relate to your rights to the code, but to your access to their update mechanism.
This kind of thing is fairly common with GPL'd code. Imagine that you are a major CPU vendor and you want to give partners early access to a feature. You give them a modified version of Linux and GCC to experiment with. You can't stop them from distributing these, but you really don't want them to (it would pre-announce the feature publicly, and the experimental versions may have things like opcode assignments that will change in the final shipping version). You have a gentlemen's agreement not to publish the code, and if they do then they won't get early access to future new features. This is one of the reasons that ARM is now increasingly prototyping with LLVM and FreeBSD: it's easier to share with partners without legal hassles.
sudo mod me up
(Score: 3, Interesting) by requerdanos on Friday July 07 2017, @05:09PM
Thank you.
Well, no, they claim specifically that "The User has all rights and obligations granted by grsecurity's software license, version 2 of the GNU GPL" but reveal additional, more restrictive terms just afterwards.
There is no question whether they are doing this; it's not a matter for speculation or argument. In their own words, their prohibition on exercising your distribution rights under the GPL are "terms" in their "agreement" that you can "violate" -- there is no question here. Their agreement that adds additional terms to the GPL with a penalty for violation is on their website [grsecurity.net] for review.
Under "Termination" in their additional-terms-added-to-the-GPL-in-violation-of-same-agreement, they say that their aim is only to terminate access to code if you violate the terms of the agreement under which they are distributed (meaning, the additional-terms-added-to-the-GPL-agreement), they also "reserve the right" to revoke access "at any time for any reason," with or without a refund to customers who prepaid.
That section reads (emphasis added):
Not only do they deny (as "violations") freedoms 2 and 3 as they relate to distribution, they even deny freedom 0, to freely use of their kernel in the first place:
This is as big a deal or bigger than the denial of freedoms 2 and 3, distribution of verbatim or modified copies. They do not even let you use their kernels freely; grsecurity has to approve of each and every computer before you are allowed to run their kernel on it. That is not an example of someone having all the freedom of the GPL.
If you "violate" their "terms" of the additional-terms-added-to-the-GPL-in-violation-of-same-agreement, then it will be "terminated." An agreement that is additional, with terms, adds "additional terms" and they are more restrictive than the GPL. This is disallowed.
Given that they are adding terms to the GPL that make it more restrictive, as previously covered in this thread and by Perens, their rights are terminated under the GPL and they don't have any right to do anything at all with the kernel, much less modify it, redistribute the patches, and withhold the source code and add the additional restriction that everyone who receives it from them also withhold it, and deny even freedom 0 to use the software freely in the first place.
That's seriously a no-no to do, even if they claim they aren't doing it as they do it.
Consider the following pseudocode:
while (user_data_remains) {
display_duplicitous_message("I am totally not erasing all the user data.\n");
erase_all_user_data();
}
What would this code, if implemented, accomplish? Would the presence of the "display" clause mean that the next line does not exist, despite the fact that it does exist?
Either the writer of such a claim is less than knowledgeable, and believes additional terms are not additional terms, more restrictive terms are not more restrictive, and black is white for all we know; or the writer believes that You The Reader/Customer are less than knowledgeable, and that You will believe such nonsense.
Their additional, more restrictive terms specifically and substantially restrict what you can do with the code, in terms of both use and distribution. Their license does not remove your rights under the GPL, but that's only because such additional terms are invalidated by the GPL of the parent work.
That they impose a penalty if you violate their additional, more restrictive terms goes over and above just having the additional terms--normally if you violate license terms the penalty is that "the license said not to do this but I did it anyway," and perhaps terminate your rights under that license. But they are actually writing a penalty into the license for violating their additional, more restrictive terms that they assert in addition to the terms of the GPL, such that they will go beyond that and actually terminate your rights under other agreements as well.
Well, not exactly this kind of thing, in my opinion.
It's questionable whether partners sharing code among themselves counts as "distribution," and a gentleman's agreement is not the same as a EULA that curtails freedoms 0, 2, and 3 of the GPL regardless of any agreement or lack thereof. Parties to a gentleman's agreement are working together. Parties to the additional-terms-added-to-the-GPL-in-violation-of-same-agreement are more likely working against each other, and they're doing so under false pretenses.
Amen to that.
I wasn't convinced by your explanation, and if you would be so kind, I would like to know your opinion or impression of whether I took the time to properly listen to and consider it. I feel that I did, but then again, if I have a blind spot, I would not know about it.
(Score: 0) by Anonymous Coward on Sunday July 09 2017, @03:50PM (1 child)
That's what I thought and what they COULD have done, basically stating something like: "we reserve the right to cancel subscriptions at any time. Subscriptions are meant to help people secure their own systems, and we are thus likely to cancel subscriptions that are to a significant degreee used for other purposes". This likely would make it just a matter of "well, we do business only with certain types of customers".
However they instead wrote it as a legal agreement, to the terms of which you have to agree, which to me seems like it would break any kind of justification like yours since it clearly makes it additional contract terms, which the GPL CLEARLY forbids.
In which case the only way for them to be allowed to distribute the kernel or any derivative again (including patches, as long as they contain a relevant amount of code not written by them, and in particular including internal distribution like any of their developers doing a checkout from their version control system) would be to get every major kernel contributor to personally re-instantiate their license. Good that they didn't just piss most of those off...
Either incredibly stupid, or the kind of people that bet everything on the chances of being able to get away with it. Either way, with that attitude it's no wonder their code was usually rejected.
(Score: 0) by Anonymous Coward on Wednesday July 12 2017, @09:43PM
"That's what I thought and what they COULD have done, basically stating something like: "we reserve the right to cancel subscriptions at any time. Subscriptions are meant to help people secure their own systems, and we are thus likely to cancel subscriptions that are to a significant degreee used for other purposes". This likely would make it just a matter of "well, we do business only with certain types of customers"."
Nope. Once a pattern emerged and was known that they only cancel subscriptions of people who redistribute the patches it would be a clear case of imposing an additional terms through course of business practice. Terms can be written, verbal, or implicit. That would be an implicit additional term.
You and the rest of the lay people here have to understand: the law has dealt with pretty much every issue you can come up with and... you don't know the law.