Linux Kernel Hardeners Grsecurity Sue Open Source's Bruce Perens (theregister.co.uk)
An anonymous reader shares a report from The Register: In late June, noted open-source programmer Bruce Perens [a longtime Slashdot reader] warned that using Grsecurity's Linux kernel security could invite legal trouble. "As a customer, it's my opinion that you would be subject to both contributory infringement and breach of contract by employing this product in conjunction with the Linux kernel under the no-redistribution policy currently employed by Grsecurity," Perens wrote on his blog. The following month, Perens was invited to court. Grsecurity sued the open-source doyen, his web host, and as-yet-unidentified defendants who may have helped him draft that post, for defamation and business interference. Grsecurity offers Linux kernel security patches on a paid-for subscription basis. The software hardens kernel defenses through checks for common errors like memory overflows. Perens, meanwhile, is known for using the Debian Free Software Guidelines to draft the Open Source Definition, with the help of others.
Grsecurity used to allow others to redistribute its patches, but the biz ended that practice for stable releases two years ago and for test patches in April this year. It offers its GPLv2 licensed software through a subscription agreement. The agreement says that customers who redistribute the code -- a right under the GPLv2 license -- will no longer be customers and will lose the right to distribute subsequent versions of the software. According to Perens, "GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition." A legal complaint (PDF) filed on behalf of Grsecurity in San Francisco, California, insists the company's software complies with the GPLv2. Grsecurity's agreement, the lawsuit states, only applies to future patches, which have yet to be developed. Perens isn't arguing that the GPLv2 applies to unreleased software. Rather, he asserts the GPLv2, under section 6, specifically forbids the addition of contractual terms.
Grsecurity used to allow others to redistribute its patches, but the biz ended that practice for stable releases two years ago and for test patches in April this year. It offers its GPLv2 licensed software through a subscription agreement. The agreement says that customers who redistribute the code -- a right under the GPLv2 license -- will no longer be customers and will lose the right to distribute subsequent versions of the software. According to Perens, "GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition." A legal complaint (PDF) filed on behalf of Grsecurity in San Francisco, California, insists the company's software complies with the GPLv2. Grsecurity's agreement, the lawsuit states, only applies to future patches, which have yet to be developed. Perens isn't arguing that the GPLv2 applies to unreleased software. Rather, he asserts the GPLv2, under section 6, specifically forbids the addition of contractual terms.
That would put a full stop to Gr's suit.
But besides that, it's pretty clear this is an intimidation move because it would be relatively trivial to just show you're not doing it.
Perens vindicated.
I fully expect them to loose, the GPL is very clear that you cannot add additional restrictions, and they are doing exactly that.
The kernel folks have been dismissive of GRSecurity as having little importance, and not worth the hassle of involving the lawyers. But since GRSecurity is starting the lawsuits and the GPL needs to be defended in court, I expect a lot of high powered legal involvement to settle this.
this is going to be interesting to watch. one of the world's best-informed advocates of software libre, who has studied the GPL for many years, versus some idiots who will have been ill-advised by some moron whose only saving grace is the indemnification insurance provided as a sop to corporate madness. for those people not familiar with what indemnification insurance is: it's where lawyers can basically get away with making fundamental errors, and the corporation to whom they give the advice can sue their company quite safely, *as long as they follow that advice*.
i really look forward to seeing how this turns out.
This is a stupid lawsuit. According to the attorneys for the plaintiff company:
"Mr Perens has made false statements, claiming them to be facts, and based on those statements employed fear-mongering tactics to intentionally hurt Open Source Security Inc's business."
Perens actually wrote: "it's my opinion that..."
Opinion, not assertion of fact. This lawsuit will be thrown out almost immediately. However, it is useful in helping the community identify a company that we should never do business with. So thanks for that, at least...
Enjoy life! This is not a dress rehearsal.
Comment removed based on user account deletion
If anyone was still wondering why their patches never made it in the kernel...
It shows a lot about their attitude and delusions, there are good reasons not to want code from people not able to objectively judge their own work, especially when they are asses on top...
Linus Torvalds called grsecurity patches garbage earlier this year. https://www.theregister.co.uk/...
If version A says you can't distribute this without losing rights to version B, then either
you just get version B and then distribute THAT and "lose rights" to distribute version C and so on and so on
OR
you lose rights to GET version B because of a violation of a term on the same GPL software (version A) which is either illegal to do because
a) a license for B can't be contingent on a license for another bit of software, copyright does not give you that right at all
b) the license addition is to both A and B, therefore explicitly against the clause Bruce mentioned, hence GRSecurity has no license for their code and are "pirates"
Why? I do not need to like Bruce Perens to read his opinion and evaluate whether I agree with him or disagree. By concept it should even be irrelevant for my evaluation how sane his previous comments were. Linus Torvalds can also be a 'dick', but still is competent regarding the topic of Linux kernel development.
It's defamation to claim we're likely to launch a spurious lawsuit! ...
We're suing!
It does not prevent you from charging for your work. Charge for it all you want. You can't put more restrictions on the work than you agreed to before you got the base software you used in YOUR work.
It's LESS of a cancer than, say, MS licenses, where you lose all right to distribute, comment or derive future benefit if MS think that you should lose the license. AND you get audited by the BSA and MS's audit teams at your expense.
If you think that GPL is a cancer and you should be able to slap your own license on code you have added to, try getting source for an MS application or their OS, adding in some stuff, then selling it under BSD, with source. See if MS think that you deserve the right to change the license on the combined work because some of it is "yours".
In California, SLAPP stops all discovery and requires the plaintiff to pay the defendant's expenses if they lose.
Perens will not have to prove his assertions. The next move you will see is that he brings an anti-SLAPP motion. This will mean no discovery in the case and that the plaintiff will pay all of his expenses if they lose. At that point if the plaintiff has a thread of sanity they will back out, they failed to intimidate him, the posting is still on his web site, they can't win the case, they can only pile up big bills and they have to pay for Perens lawyer, a big, competent, law firm rather than the one-man patent attorney firm Grsecurity is using.
If the case goes on, Perens will prove that he has a right to state his opinion. And the case ends there. Perens is not making an "assertion of fact" as the patent lawyer states in his complaint and will win on 1st amendment grounds.
There will be no litigation of whether Grsecurity has the right to use its patch access agreement in contravention of the GPL, because there is a much simpler way to end the case.
That said, I suggest that any of us who are competent to work on the kernel do everything possible to make Grsecurity obsolete.
The problem with this is that you wrongly assume that kernel developers are also security experts. I don't mean "aware of security", I mean real bono-fide experts, of which there are very few indeed.
Attempts to do just as you suggest, that is to take an existing patch and break it up, have been criticised due to their missing important points or changing something in such a way as to make it ineffective. Basically, unless you understand what you are doing, you are going to make some mistakes.
This applies to not just to any initial merge, but also for ongoing development. It's not enough to merge and say "job done", because future work will almost certainly introduce new problems or break existing protections. Security is not a product.
Either security experts are onboard with ongoing kernel development work, or they're not. At the moment, they're not.
"The code" meaning?
The user still has a license to the Linux kernel:
1. GPLv2 sec 6 says that "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."
2. GPLv2 sec 4 says that "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."
3. GPLv2 sec 2 says "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program...," and sec 2.b. only applies if you distribute or publish the result.
And the user has an express license from GRsecurity for GRsecurity's potion of the code under the GPLv2.
No. GRsecurity granted a license under the GPLv2.
Nope. GRsecurity granted a license under the GPLv2. GRsecurity uses a separate Stable Patch Access Agreement with the supposed restriction, and that agreement is between GRsecurity and the individual customer, not the customer and any other recipient. That agreement also explicitly says that "The User has all rights and obligations granted by grsecurity's software license, version 2 of the GNU GPL," so the user would not be doing the same thing.
Strawman.
False premise. There's no basis to assert that the customer would be distributing the code with that restriction themselves.
No and no.
Everything is simple if you make no effort to understand reality and merely use your own assumptions.
Very unlikely. Downstream recipients are likewise required comply with the terms of the GPL, regardless of any violation upstream.
"Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License."
https://www.gnu.org/licenses/gpl-3.0.en.html#section8
Correct. They have no more right to add restrictions to the license than the upstream distributor does, and if they violate the terms of the GPL their license is subject to termination.
The key word/phrase is "it's my opinion".
Grsecurity needs to be hit with a SLAPP countersuit.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Streissand effect. Grsecurity should hire another lawyer, if they survive this one.
Not only what Perens wrote is always reason for precaution, even if it wasn't, he repeatedly states in his blog post that this is his opinion, and that furthermore, he's open to discussion and that he's not a lawyer.
https://perens.com/blog/2017/0...
Lawsuit won't pass because it has no grounds. Courts can't define opinions as "false statements", he explicitly claimed several times that this is his opinion, and it's a huge stretch to call it "fearmongering".
Issues with licensing have always been part of the Linux community worries, and there's nothing in his post that could be classified as fearmongering. It's advice pure and simple with strong basis to boot.
If stuff like this was enough for a company to sue an individual, we'd effectively have businesses dictating censorship as they pleased, and a whole ton of democratic instruments to go against big corporations wouldn't exist.
The whole thing will be dismissed and it'll only serve as more reason to suspect Grsecurity. Why don't they go ahead and also try suing Torwalds for calling their patches garbage? Go out with a bang.
The only thing that has changed is that they are suing Bruce Perens, so any "shitstorm" regarding this must come down to your personal like or dislike of him and his camp.
That's a stupid thing to say. You can also be against lawsuits designed to stifle public speech, which is to say, you can be pro-constitution or pro-rights or just pro-speech. There may have formerly been a shitstorm, but there was not an actual case.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
so it has no effect.
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
The part of the post that you omitted, with quotes from the GPL, is not an explanation?
The cited sections and quoted language of the GPL, along with the linked copy of the Stable Patch Access Agreement and quoted language. You know, 85% of the content of the post, which you cut out.
And I don't Title this post just to flamebait.
The subscription agreement they use is definitely against the spirit of the GPL, but could be within the letter if they were distributing a completely original work, for which they held all copyrights and had the correct sort of patent licenses to distribute code that way. But the question naturally arises why the hell wouldn't they just outright pick a restrictive license if they just outright held all rights to an original work and wanted to restrict redistribution.
The answer is that the lawyers at GrSecurity believe their patch set would likely be found to be a derivative work of the Linux kerne should the question arise in court. Additionally I speculate they may be taking advantage of patent license that are more liberal with OSS licensees. In fact in the legal complaint, GrSecurity does not counter or otherwise address Bruce's assertion that the patch set is a derived work of the Linux kernel.
On the grsecurity's home page, they describe their product as being primarily "an extensive security enhancement to the Linux kernel". This strengthens and reflects Bruce's claim that the grsecurity patch set is a derived work of the Linux kernel.
In the actual complaint, there's a lot of slime in paragraphs 14,18, and 19 are particularly flawed. The GPL does not merely cover the patches once distributed, but also the original distribution because they are a derived work of the Linux kernel and as such may only be distributed in compliance with the terms of the GPL or a compatible license. Thus Paragraph 14 is false. Paragraph 18 is also false in so far as future version will almost surely be derived from a GPLv2 licenses Linux and subject to GPL terms upon the first distribution.
While it's true the subscription agreement only sets out an explicit limit of future access, it's clearly and plainly designed to limit the actual and current exercise of rights granted under the the kernel's GPLv2 license. There is a conflation of simple "exercise" and "ability to exercise", which are not the same thing. They way it is written and the way that it is intended is that for works under the GPL, only the GPL may restrict copying, modification and redistribution.
Their customers have the right to redistribute the software that they've received. GRsecurity is then saying that if they do, GRsecurity will not provide them with any future revisions to the code. There is nothing in the GPL that gives the recipient of a copy of code the right to future versions of that code or the right to distribute future versions of that code.
I'll buy a copy, and redistribute it freely and widely. They won't sell me the next version because of that, so someone else here will have to buy a copy, and redistribute it freely and widely.
Ideally in the end they will have one customer for each release, who will all be part of my plan........
Ad hominem.
The GPL does not give the customer any rights to future revisions. The customer is not forced to give up the right to redistribute the current version -- they can choose to or not.
No. The GPL does not give the customer any rights to future revisions. The customer is not forced to give up the right to redistribute the current version -- they can choose to or not.
"A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent's argument, while refuting an argument that was not presented by that opponent."
You wrote:
"So even if you were to contend that secondary infringement cannot apply here (and we need more than just your say-so), they're still open to being sued by GRSecurity for no good reason (after all if they're this clueless about the rights and responsibilities of copyright licensing, how do you know that what you think you can do with it is what they think you can?) or for doing the same thing."
Definitional strawman. Followed by another ad hominem.
Sorry, you claimed that they would be doing the same thing. They would not, therefore false premise.
Glad that you admit that both your points were wrong.
You claimed that this was pretty simple, yet made no effort to provide an analysis based on the text of the actual licenses.
It's also perfectly fine argument style for others, and not a fallacy.
Bruce is going to "Denny Crane" the shit out of them.
Neither Bruce nor you have provided a satisfactory explanation of how the derivative work would not be licensed at all vis-a-vis the customer.
The GPLv2 secs. 4 and 6 grant the customer a license from each licensor -- not merely from the upstream distributor -- and state that the customer's license is not terminated by termination of the upstream distributor's license.
The GPLv2 sec. 2 permits the customer to make derivative works using any type of code. That code must only be licensed or relicensed under the GPLv2 if the customer publishes or distributes it to third parties.
The customer has the Linux kernel under the GPLv2 and the grsecurity contribution under the GPLv2, and NEITHER party can terminate the customer's license without a breach by the customer. The customer can even distribute the code since both parts are licensed under the GPLv2 and are ipso facto compatibly licensed as a combination under the GPLv2.
Both works are licensed. The right to make the combination is licensed. There is no "public domain" issue involved.
GRSecurity cannot grant a license to the Linux kernel if GRSecurity doesn't have a valid license. If they have violated the GPL, then they don't have a valid license. These licenses aren't free-floating; legally, they have to be granted. (The question of what you do when you violate the GPL and lose your license can get rather involved, and GPLv3 provided for automatic reinstatement of the license under certain conditions - however, Linux is GPLv2 only, and is not distributed under GPLv3.)
That sounds an awful lot like adding terms to the GPL, which is not permitted by the GPL.
Therefore, I'm claiming the following things about reality. GRsecurity may be violating GPLv2 (I'm not taking a definite position on that). If so, GRsecurity doesn't have a valid license for the Linux kernel, and is forbidden to change or further copy it. If GRsecurity doesn't have a valid license, GRsecurity can't grant a license, and therefore their customers are running unlicensed copies of software. We know from the MAFIAA and lawsuits that illegitimate copies of copyrighted works can cost a whole lot of money. The Linux kernel does not operate under a copyright-assignment principle, so there's a large number of people with copyrighted code in the kernel, and I believe any of them could sue.
Hence, it looks legally risky to me to rely on a kernel supplied from GRsecurity.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
And reality disagrees with you. Per the GPLv2:
"4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. 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."
"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 this License."
From the SFLC:
This is GPLv2's "automatic downstream licensing" provision. Each time you redistribute a GPL'd program, the recipient automatically receives a license from each original licensor to copy, distribute or modify the program subject to the conditions of the license. There is no requirement to take any action to ensure the downstream recipient's acceptance of the license terms, see above. This places every copyright holder in the chain of descent of the code in legal privity, or direct relationship, with every downstream redistributor. Two legal effects follow. First, as sec. 6 says, parties themselves remaining in compliance have valid permissions for all actions including modification and redistribution even if their immediate upstream supplier of the software has been terminated for license violation. Their licensed rights are not dependent on compliance of their upstream, because their licenses issue directly from the copyright holder. Second, automatic termination cannot be cured by obtaining additional copies from an alternate supplier: the license permissions emanate only from the original licensors, and if they have automatically terminated permission, no act by any intermediate license holder can restore those terminated rights.
It also follows, as sec. 6 makes clear, that licensors are in no way responsible for enforcing compliance by third party recipients or distributors. Every licensee gains or loses permissions from each original licensor solely on the basis of its own conduct .
But they are all bound by sections 4 and 6 of the GPL as "original licensors" of their contributions, they've automatically granted licenses to GRsecurity's customers by the terms of section 6, and those licenses were not terminated by GRsecutiy's alleged violation of the terms of section 4.
Wrong.
The first GPL clause says that you lose your license under certain conditions, but everyone who already has a license is fine. The second one could be construed as applying to legal distribution only. The SFLC quote, while more definite, is the SFLC's interpretation, and the SFLC does not represent all Linux contributors. I don't think there's any case law here (and would be fascinated to be corrected).
Therefore, it's very possible that GRsecurity is violating the GPL and hence does not have a valid license, and the courts might rule that they can't transfer a license (disagreeing with the SFLC), and there's any number of people who could sue for statutory damages, so I'd say there's a risk. I'm not a lawyer, and this isn't even illegal advice, so if this matters to you please consult a real lawyer.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
No it doesn't. It 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." You're rewording it, e.g., "However, parties who have already received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance." There is no qualification upon time included in the anti-termination provision.
No, it can't. It says "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." There's no condition on the automatic grant of a license from the original licensor to the recipient, and there's no required grant of license from the distributor. There is no termination of the recipient's rights under even a particular instance of license under the GPLv2 -- see the statement that it "will automatically terminate your rights under this License" in addition to the above-quoted "However..." clarification.
They don't have to transfer a license. The recipient is an intended third party beneficiary of a direct license from the original licensor under GPLv2 sec. 6, and the third party beneficiaries' rights are not terminated under GPLv2 sec. 4, both by the terms of actual termination clause and the subsequent "However" clarification.
Even if you argue that the GPLv2 is not a contract with third party beneficiaries, sec. 6 creates a promissory estoppel with respect to the recipients. Sec. 6 is not conditioned on the distributor's compliance with secs. 2 and 3, is automatic, and is not terminated by sec. 4.
Irrelevant. The SFLC is a group of lawyers who have expertise concerning this license. Without a coutervailing analysis from a lawyer, or any indication that any Linux kernal contributor even holds such an opinion, this is merely FUD.
Your wish is granted. Skip down to "The use of GPLv2-licensed code is authorized for compliant users, even if they receive the code from a non-compliant licensee."
Thank you. Very interesting.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes