Slashdot Mirror
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.
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!
GPL doesn't require supplying future updates, it just says that you must provide an offer of source with binaries, and can't restrict redistribution of source/binaries. It looks like they've found another way to follow the letter of the GPL without following the spirit of it.
They're actually trying to do an end run around the contract to which they've already agreed, which guarantees the right of redistribution. The question becomes whether grsecurity contains any GPL code to which they do not hold the copyright. If so, then they're risking losing the right to distribute that code.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In California, SLAPP stops all discovery and requires the plaintiff to pay the defendant's expenses if they lose.
They may be complying with the terms of the GPL, whether you call it a contract or not. 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've disgreed with Bruce on this specific issue and I still do. While GRsecurity may be in violation of GPLv2 sec. 6 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein. "), the idea that their customers may be liable for contributory infringement and breach of contract is off-the-wall crazy. Bruce's theory is directly contradicted by GPLv2 secs. 2, 4, and 6 -- the customers are free to use GRsecurity's product and there is no potential violation of the GPLv2 unless the customers themselves redestribute that code.
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.
"You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
But the GPLv2 does not grant a right to obtain future revisions, whether you're a paying customer or otherwise. The GPLv2 does not require that the (re)licensor grant a right to distribute anything more than what has already been distributed to the recipient. Those are not "rights granted herein." The first is a right granted by grsecurity's paid support contracts -- contracts for services. The second is a right that is reserved and carved out from the first.
Tivoization violates the "spirit" of the GPLv2, but what matters is whether a licencee has violated the letter of the license. That violation is not as clear cut as you think.
The question becomes whether grsecurity contains any GPL code to which they do not hold the copyright.
The answer is absolutely yes, it is a derivative work. It is a derivative work because there is no part of the patches that would exist without the Linux kernel: their entire purpose is to modify the kernel (and theoretically make it more secure). I would like to point out that at DEFCON last week, trixr4skids took a Point of Sale device with GRSecurity on it, and hacked it to run DOOM. The keyboard input on the device was not user friendly.
"First they came for the slanderers and i said nothing."
Like someone who trivially ties their real world identity to a pseudonym while posting the dreck that you do?
You mean, someone who is not a coward? Run along, frightened one. I tie my slashdot identity to my real identity because I have the courage of my convictions. You don't because... you don't. Feel free to make up bullshit excuses, though.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I'm not sure it is as clear cut as you seem to think. They distribute the software to you under the GPL and ask you to sign a second contract if you also want support. The second contact has the restrictive clause.
Furthermore, the contract doesn't say "you can't redistribute this software", it says "we won't give you future versions of this software". I think they have a point, although I am not a lawyer.
As for whether Bruce Perens is committing libel by publishing an opinion that they are in breach of GPL, we'd better hope they find for the defendant, otherwise it would be impossible for anybody to argue a company is breaching a software licence (or any licence or contract or law) without being potentially a target for a libel suit.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
This explains it. I am actually now leaning towards it being a violation by GRsecurity, but that turns entirely on what a court construes a "restriction[] on the recipients' exercise of the rights granted herein" to include. If I offer to pay you $20 if you do not redistribute the package for a year, is that a restriction? If we don't have a support contact and I say that I'll only give you future updates to my code if you don't redistribute it, is that a restriction? If we have a paid support contract that automatically terminates if you redistribute it, is that a restriction? The support contract is outside the scope of the GPL, and ordinarily a restriction is a "limitation which cannot be exceeded or rule which cannot be broken," not merely a disincentive in that you might lose some other right like continuing support.
Yes, I don't. But we don't enforce the "spirit" of contracts. We enforce the letter of the contracts, and tend to construe ambiguity against the drafter because if they meant that, then they could have put more effort into stating it clearly.
See above. Why did you switch from "restrict" to "punish"? I'm leaning towards there being an issue in that courts hate terms that create forfeitures where a side has otherwise completed its performance of its obligations. Since GRsecurity is selling year-long subscriptions with patch access, their customers would have a good claim against them. I'm simply not as sure about it being a license violation.
Yes -- membership in protected classes involving race, sex, creed, etc., not the terms of the GPL. The GPL does not govern support services, or provide any right to future revisions of code. I think that their biggest problem is they are structuring this as a forfeiture of up to year of subscription support, rather than a decision not to renew a month-to-month agreement.
The "is GRsecurity violating the terms of the GPL" argument is messy and could go either way. Which is why I wrote "may be in violation" to begin with.
The argument that almost enrages me is Bruce's argument that GRsecurity's customers could be liable, and frankly that is the one that is far more interesting to me. The GPL was expressly structured so that downstream users were automatically licensed and were not affected by an upsteam distributor's violation of the GPL. Bruce is now not only denying that GPLv2 sections 4 and 6 preclude this, but throwing out concepts like "contributory infringement" without any analysis of what is required to be liable as a contributory infringer.