Slashdot Mirror
Bruce Perens Warns Grsecurity Breaches the Linux Kernel's GPL License (perens.com)
Bruce Perens co-founded the Open Source Initiative with Eric Raymond. Now he's sharing a "strong opinion" that companies should avoid the Grsecurity security patch for the Linux kernel "because it presents a contributory infringement and breach of contract risk." Slashdot reader NewGnu shared Bruce's comments:
[I]t would fail a fair-use test... 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... 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...
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.
Perens advises companies to discuss his position with their attorneys, adding "In the public interest, I am willing to discuss this issue with companies and their legal counsel, under NDA, without charge."
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.
Perens advises companies to discuss his position with their attorneys, adding "In the public interest, I am willing to discuss this issue with companies and their legal counsel, under NDA, without charge."
Thanks for that well reasoned remark, way to contribute. The core kernel crowds utter unreasoning hostility toward grsecurity is well documented by now. Its made a laughing stock of the security of the stock kernel for decades, and nobody likes to be shown to be an idiot. Grsecurity recently changed its terms due to widespread abuse of its mark. I assume it has something to do with these new terms, and potentially these announcements were triggered by complaints made by way of retaliation.
Clippy says, "It appears you're starting yet another GPL vs. BSD holy war discussion. Would You Like Help?"
* Yes, please link to one of the approximately 17,000 near-identical discussions of this nature we've already had on Slashdot over the years.
* No, I'd rather pointlessly go through the exact same longwinded to-ing and fro-ing and restatements of the same old facts purely to indulge my personal need, despite the fact I know the chances of any new insight coming out of the billionth tedious discussion of this long-established subject is next to nothing, despite the fact that those on both sides feel the need to repeat the same entrenched positions- which mostly come down to personal philosophy and not an incomplete understanding of the issues (which everyone knows full well by now) and will therefore be unlikely to change in the face of the discussion (not that this was the point anyway).
(Joking aside, I'm pretty sure the OP knows all this and is intentionally trolling; I'm also pretty sure the replying AC above isn't, which IMHO makes it worse).
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Submit good patches and we'll merge them. Hell, report some bugs. But no, that's not how you guys operate. You work in an ivory tower for months and send us a massive patch that lacks any organization or any reasonable way to break it down for review. At this point, we think you should take your pile of "security" patches and go write your own kernel to go with it.
Actually, the GPL and a trademark registration will keep just what you're talking about from happening. Going proprietary won't give you any more protection unless you're talking about just locking up the source. But you have to enforce once in a while to keep idiots from breaking the rules.
Bruce Perens.
Brad Spengler of GRsecurity replies
So Linus, you called the patches garbage when someone asked how we fixed the heap stack gap issue 7 years ago when you failed to. Can you provide any technical details demonstrating why that fix is garbage, the fix that looks very similar in form and function to what's present upstream now finally (in some of the kernels at least, and minus ours being configurable and cleaner)?
Can you explain how our fix breaks userland and how your 2010 fix didn't?
If not, I'd suggest you keep your lies and FUD to yourself. No one but lackeys for your cult of personality are buying it. You and others trot out the same old tired excuse about "breaking userland" and never offer up any real facts. If it were the case, it wouldn't be possible to run grsec on anything but distros with recompiled userland, and yet we work just fine on any distro. It's a meaningless crutch for people apparently have never looked at any kernel code of ours who refuse to
accept the simple facts:
1) You're not security experts
2) You view security as an annoyance
3) The Linux kernel's security track record is terrible
It's the only way they can justify it in their minds -- the problem surely can't be that you've ignored the problem for years and lied to people telling them it's the best that can be done. When some outside group proves you wrong, you have to pretend there's no way you could have done what they did, because you care so much about code quality. How can you explain the verbatim copy+pasting of our code if that's the case? Please explain to the world how if our code is such garbage, you haven't been able to come up with any significant security improvements without it?
Put up or shut up, for once.
> Please.
Please.
-Brad
You understand the difference between "me libertarianism" and "us libertarianism". Some of these folks are offended that they aren't allowed to keep slaves.
Bruce Perens.
The problem isn't with the text there. It's with what else they have told their customers. It doesn't even have to be in writing.
I have witnesses. If there was ever a case, obviously the prosecution would have to depose people to make this point. I am not actually planning on a case, though. I think this warning will have the desired effect.
Bruce Perens.
This is a very large discussion and I'm not going to put in the hour necessary to explain it fully. One of the relevant cases is Galoob Games v. Nintendo. In that case, the Game Genie made by Galoob, which let you have infinite lifetime and ammo and thus cheat in Nintendo games, was thought to be a derivative work by Nintendo. Galoob won, because the Game Genie connected to a plug and only modified a few memory locations.
Unlike the modularity of the Game Genie and that of some of the other things you mention, Grsecurity does not limit itself to dealing with Linux through its APIs (like the plugs in the Nintendo console and game cartrige). Instead, Grsecurity gets dirty fingers all over the kernel internals. So, it's derivative.
I am very much a supporter of right to repair and to interoperate, and we should discuss that another time.
Bruce Perens.
You don't sound like a security expert either. If the kernels are so buggy, write patches and demonstrable exploit code.
Custom electronics and digital signage for your business: www.evcircuits.com
What I hear: "wah, you should be spoonfeeding us this because it's over our heads. Fuck the good ideas and flaws that get fixed, submit pretty patches or fuck off."
What I hear from you is that you have no idea how software development works. Yes, absolutely, if you supply something that cannot be integrated, then fuck off.
The problem with using the Founder's Copyright is that Public Domain is not more free for the aggregate of all people than the GPL would be. It's just an invitation to integrate the public code into private works without returning anything, while the GPL promotes that more code is shared.
Well, that depends upon whether you want freedom or a set of rules. I respect your opinion on most things, but in this case you cannot make the case that GPL is about freedom, because its not. It's about controlling those who use it while giving them great latitude in one way, but constraining them greatly in others. The closest thing to freedom regarding copyright and code are licenses such as MIT, BSD, and the Apache 2 licenses, and even those have clauses constraining use. They're just a lot less restraining than the GPL (2 or 3).
The cesspool just got a check and balance.
I would be extremely suspect of any company that supplied blob patches, like M$ does to hide the individual elements of that patch. Straight up, I would suspect them of trying to put in a back door. So the question is to put all the effort into tearing down and completely dissecting that blob and only apply those elements of it that have been fully checked or just bin it and do the coding directly, which will likely be quicker.
Everyone knows exactly the reason why kernel patches at keep neat, specific and fully detailed and a security company should know better than others. This code blob probably a try it on and the next one, the attack blob. Lets be honest everyone knows the CIA/NSA would pay tens of millions in corrupt bribes to get a back door forced into Linux.
Chaos - everything, everywhere, everywhen
The growth in use of permissive licenses (particularly if you look at github) over restrictive ones is a demonstration of pragmatism and the idea that not everything must be free and we can have non-free and free components working together and cooperating rather than focussing on a pure free software ideology.
I wouldn't necessarily even go that far. I am entirely in favour of a world in which all software comes with the FSF's four freedoms. The reason I release code under FreeBSD / MIT licenses is that this seems like a path that has an actual transition plan. If there's a BSDL project available that does 90% of what you need, then you can adopt it and add the remaining 10% without needing to change your business model. Most of the time, it's then cheaper to release the code. If it doesn't give you a competitive advantage, then upstreaming your changes means that your maintenance costs go down (and, often, other people will fix your bugs, in exchange for being able to use your new features).
If there's only a GPL'd project available, then I've worked with a lot of companies that aren't 100% sure that they will never want to do anything that the GPL prohibits and so will instead write a proprietary version (if you're lucky, you can persuade them to write a permissively licensed version). The GPL'd project doesn't ever enter the company (particularly with GPLv3, where anyone who owns patents gets very nervous) and so they never see the benefits of Free Software. It doesn't provide them with a transition path.
This transition path is particularly important because around 90% of all software developers are employed by companies that are not primarily computer companies. They are developing software for in-house use and so implicitly have all of the four freedoms (because they own the copyright), but don't contribute anything to the wider ecosystem (other than money to Microsoft, Oracle, SAP, and so on). Getting them to start using, contributing to, and then preferring open source solutions can unlock a lot of developer resources.
I am TheRaven on Soylent News