http://perens.com/blog/2017/06/28/w...contributory-infringement-risk-for-customers/ I had mentioned this legal problem already here.
But is it still licensed under GPL? Just because it derives from the Kernel, it doesn't mean it must fall into the same license as long as the code isn't identical. They could create patches that are in no way related to what's in the Kernel, make this code under a proprietary license, and still negate/warn customers that they cannot redistribute the code.
I'm not a lawyer but that's not how I understand GPL. These patches are patches of the kernel - they cannot exist as stand-alone code. As far as I understand it this means that GPL also applies to them.
https://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense The entire point of the GPL license is that you cannot ADD restrictions to GPL code, only REMOVE restrictions. With restrictions I mean stuff that prevents you from using the software. Therefore it's impossible for Grsecurity to add restrictions preventing people from sharing the code. For example: Signal Protocol and every Signal program is GPL licensed For WhatsApp the Signal Protocol is licensed as Apache, because Apache is less restrictive than the GPL license. During no circumstances could the Signal Protocol be made proprietary.
The way I see it, it's like with proprietary kernel modules: the code is proprietary, and it can be incorporated into the Kernel. As long as GRSec doesn't distribute the kernel itself with proprietary patches, and as long as the code doesn't derive directly from the code inside the Kernel, they can still be proprietary. Proprietary patches/modules can be incorporated into the Kernel in the user end. But yes, if GRSec code has bits and pieces of code that come from the Kernel, I guess they cannot impose any restrictions on it without violating the GPL.
The grsecurity modifications have always been GPLv2, which means it would be illegal for them to make it proprietary all of a sudden. They haven't tried to make it proprietary though, they only tried adding adding limitations against sharing the code with others. Something the GPL code forbids. Thus Grsecurity is breaking their own license. https://grsecurity.net/agree/agreement.php To clarify: Since Grsecurity was written with the GPLv2 license, they cannot add additional restrictions to their code. To do that they would have to rewrite the code and impose those limitations on THAT code.
@Beyonder Old code previously licensed under GPL cannot become proprietary, that's true. But new code that previously wasn't GPL can. Since a lot of what GRSecurity publishes goes into the Kernel quite quickly, I guess they could simply start writing new patches and make them proprietary. It would be nice if the new patches leaked, so we can have a definitive answer to whether or not they contain code from the Kernel or code of older patches. If so, then they're completely breaking everything they ever stood for. Though I'm not sure there would be any consequences at all.
As mentioned above, I doubt that. They are patches of the kernel and not stand-alone code. As the kernel is under GPL it's legally impossible that patches are not. But again, I'm not a lawyer.
Grsecurity is suing Perens. https://www.theregister.co.uk/2017/08/03/linux_kernel_grsecurity_sues_bruce_perens_for_defamation/
Gentoo removes their hardened-sources: https://www.gentoo.org/support/news-items/2017-08-19-hardened-sources-removal.html
It's great to see that Copperhead is making their own hardened kernel! Also I hope Grsecurity loses the lawsuit.
EFF Defends Bruce Perens In Appeal of Open Source Security/Spengler Ruling August 25, 2018 https://yro.slashdot.org/story/18/0...appeal-of-open-source-securityspengler-ruling
Maker of Linux patch batch grsecurity can't duck $260,000 legal bills, says Cali appeals court in anti-SLAPP case Ninth Circuit affirms decision that Bruce Perens was entitled to voice opinion about GPL compliance https://www.theregister.co.uk/2020/02/07/open_source_security_defamation/ Very good
