8 ms·

Edit: 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 p

Edit: 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 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.

DannyBee 9y ago
"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.
- deleted 9y ago
  [deleted]
- resf 9y ago
  Nvidia have a lot of money, so the law is on their side.
simion314 9y ago
So where do you draw the line?
- deleted 9y ago
  [deleted]
deleted 9y ago
[deleted]
tw04 9y ago
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.
SwellJoe 9y ago
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).
- zzalpha 9y ago
  Your last parenthetical is clearly correct. I misunderstood Peren's argument and have updated my comment accordingly.
microwavecamera 9y ago
The difference with something like Nvidia's proprietary driver is that it interfaces with the kernel through the kernel's API as a kernel module, which is fine under the GPLv2, assuming you're not Richard Stallman. Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your own. Grsecurity is really in a grey area here (I personally think it violates the GPL) because it modifies GPL code with proprietary code and possibly borrows GPL code. It's not interfacing with the kernel via APIs and doesn't work outside the kernel. If it were a kernel module it would be fine.
- deleted 9y ago
  [deleted]
- fooker 9y ago
  >Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your own. That is not actually true. That's why LGPL exists.
  - microwavecamera 9y ago
    So I went and read up on it again. Apparently there's no clear consensus on the dynamic linking issue (still). Warning this post may get long. Here goes, so over at gnu.org in the FAQ it says this: "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly." But gnu.org also states: "If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL." But over at the Wikipedia article there's this: "Some people believe that while static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak copyleft). Linux author Linus Torvalds agrees that dynamic linking can create derived works but disagrees over the circumstances. A Novell lawyer has written that dynamic linking not being derivative "makes sense" but is not "clear-cut", and that evidence for good-intentioned dynamic linking can be seen by the existence of proprietary Linux kernel drivers." Now Lawrence Rosen, one-time Open Source Initiative general counsel argues this: "The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work." But what there's more! The GPLv2 allows for a linking exception clause if the original developer(s) want to offer it. "If you're using GPLv2, you can provide your own exception to the license's terms. The following license notice will do that. Again, you must replace all the text in brackets with text that is appropriate for your program. If not everybody can distribute source for the libraries you intend to link with, you should remove the text in braces; otherwise, just remove the braces themselves." Much of it seems to come down to intent and good faith. While the pure application GPLv3 pretty much says no to linking, both dynamic and static, the legal definition of what constitutes a derivative work creates a grey area. It seems to come down to the intent of the developer(s) who license it as to whether it would be enforced that way but the dynamic linking issue is untested in court so no one seems to be sure if it's enforceable. Who knows? GNU, making simple things complicated since 1983.
vacri 9y ago
> Just because it's useless without the kernel doesn't make it a derivative work. What's your definition of a derivative work?
pcwalton 9y ago
But NVIDIA is violating the GPL. (At least, according to many lawyers.)
cthalupa 9y ago
It's not that grsecurity is useless without the kernel, it's that it patches the kernel. It HAS to be a derivative work of the kernel, since that's what it is modifying.

DannyBee 9y ago

"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.

deleted 9y ago
[deleted]
resf 9y ago
Nvidia have a lot of money, so the law is on their side.

simion314 9y ago

So where do you draw the line?

deleted 9y ago
[deleted]

deleted 9y ago

[deleted]

tw04 9y ago

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.

SwellJoe 9y ago

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).

zzalpha 9y ago
Your last parenthetical is clearly correct. I misunderstood Peren's argument and have updated my comment accordingly.

microwavecamera 9y ago

The difference with something like Nvidia's proprietary driver is that it interfaces with the kernel through the kernel's API as a kernel module, which is fine under the GPLv2, assuming you're not Richard Stallman. Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your own. Grsecurity is really in a grey area here (I personally think it violates the GPL) because it modifies GPL code with proprietary code and possibly borrows GPL code. It's not interfacing with the kernel via APIs and doesn't work outside the kernel. If it were a kernel module it would be fine.

deleted 9y ago
[deleted]
fooker 9y ago
>Same goes for libraries, you can link to a GPL library in your commercial application as long as you distribute the library as is but you couldn't just steal or modify the libraries' code and call it your own. That is not actually true. That's why LGPL exists.
- microwavecamera 9y ago
  So I went and read up on it again. Apparently there's no clear consensus on the dynamic linking issue (still). Warning this post may get long. Here goes, so over at gnu.org in the FAQ it says this: "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly." But gnu.org also states: "If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL." But over at the Wikipedia article there's this: "Some people believe that while static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak copyleft). Linux author Linus Torvalds agrees that dynamic linking can create derived works but disagrees over the circumstances. A Novell lawyer has written that dynamic linking not being derivative "makes sense" but is not "clear-cut", and that evidence for good-intentioned dynamic linking can be seen by the existence of proprietary Linux kernel drivers." Now Lawrence Rosen, one-time Open Source Initiative general counsel argues this: "The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work." But what there's more! The GPLv2 allows for a linking exception clause if the original developer(s) want to offer it. "If you're using GPLv2, you can provide your own exception to the license's terms. The following license notice will do that. Again, you must replace all the text in brackets with text that is appropriate for your program. If not everybody can distribute source for the libraries you intend to link with, you should remove the text in braces; otherwise, just remove the braces themselves." Much of it seems to come down to intent and good faith. While the pure application GPLv3 pretty much says no to linking, both dynamic and static, the legal definition of what constitutes a derivative work creates a grey area. It seems to come down to the intent of the developer(s) who license it as to whether it would be enforced that way but the dynamic linking issue is untested in court so no one seems to be sure if it's enforceable. Who knows? GNU, making simple things complicated since 1983.

vacri 9y ago

> Just because it's useless without the kernel doesn't make it a derivative work. What's your definition of a derivative work?

pcwalton 9y ago

But NVIDIA is violating the GPL. (At least, according to many lawyers.)

cthalupa 9y ago

It's not that grsecurity is useless without the kernel, it's that it patches the kernel. It HAS to be a derivative work of the kernel, since that's what it is modifying.