Grsecurity: Potential contributory infringement and breach of contract risk
1–10 of 128 posts
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#2Edit:
I replied too soon and misunderstood the core of Peren's argument.
His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes.
At issue is this agreement:
https://grsecurity.net/agree/agreement.php
This clearly represents additional conditions imposed on the software. Seems like a grey area as to whether those conditions at enough to violate the GPL under which the Linux kernel is licensed.
Original comment:
I don't buy it.
Grsecurity isn't distributed as a derivative work of the Linux kernel.
Just because it's useless without the kernel doesn't make it a derivative work. By that logic, Nvidia's closed source driver would qualify as a derivative work and fall under the GPL.
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#3Edit: I replied too soon and misunderstood the core of Peren's argument. His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes. At issue is this agreement: https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the s…
"Just because it's useless without the kernel doesn't make it a derivative work. By that logic, Nvidia's closed source driver would qualify as a derivative work and fall under the GPL.
"
FWIW: This is in fact, the belief of a number of lawyers.
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#4Edit: I replied too soon and misunderstood the core of Peren's argument. His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes. At issue is this agreement: https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the s…
So where do you draw the line?
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#5Edit: I replied too soon and misunderstood the core of Peren's argument. His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes. At issue is this agreement: https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the s…
[deleted]
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#6Edit: I replied too soon and misunderstood the core of Peren's argument. His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes. At issue is this agreement: https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the s…
Given it's closed source we don't know for sure, but IIRC the Nvidia Linux driver shares a ton of code (majority?) with the Windows driver, so one could argue that the bulk of the code "works" just fine without Linux. Grsecurity definitely can't make that claim.
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#7I stopped taking Grsec seriously a long time ago. Grsec makes the kernel more secure by breaking it. The code in their patches does not meet the standards/style of the Linux kernel and has in fact been criticized by third parties for just not being good code. I could make a crappy patch that breaks networking and market it as a security feature because it "prevents intrusion", but it also breaks useful features. They appear to have some kind of internet defense force or something defending them at every turn but it's become more and more apparent lately that grsec is a low-quality code base maintained by programmer(s) with bad attitudes and superiority complexes.
I've been in tech for quite some time and never encountered anyone using grsec patches. They do a really good job of marketing their product on tech forums though.
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#8I'm curious why the same argument wouldn't apply to Red Hat Enterprise Linux and all its customers, since they apply the same policy of terminating the license of anyone who redistributes it to their kernel patch set.
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#9Edit: I replied too soon and misunderstood the core of Peren's argument. His claim is that by withdrawing support if a customer redistributes the grsecurity patch (which absolutely is licensed under the GPLv2), that amounts to adding a clause to the GPL due to the penalty this imposes. At issue is this agreement: https://grsecurity.net/agree/agreement.php This clearly represents additional conditions imposed on the s…
Grsecurity is far more integrated into the Linux kernel than a graphics driver. It patches huge swaths of Linux core code.
Nvidia is distributing a blob with a few hooks to make it work as a Linux driver. It doesn't touch core Linux code in any way; it adds a driver.
One could complain about Nvidia, too, and I wouldn't be bothered by that (I prefer OSS drivers), but to say that it's the same as Grsecurity is disingenuous (or lacks deep enough comprehension of the problem to comment on the subject).
Re: Grsecurity: Potential contributory infringement and breach of contract risk
#10I'm curious why the same argument wouldn't apply to Red Hat Enterprise Linux and all its customers, since they apply the same policy of terminating the license of anyone who redistributes it to their kernel patch set.
That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is binary distribution.