4 ms·

What "other side" of the argument. If you read the GPL, it is clearly designed to prevent EXACTLY this thing. I'm sure as it was being written, Microsoft was

What "other side" of the argument. If you read the GPL, it is clearly designed to prevent EXACTLY this thing. I'm sure as it was being written, Microsoft was envisioned as the evil entity that would steal free software and mix it with closed proprietary code. The license is clearly and deliberately designed to prevent this. The "other side" may not see it this way. But the "other side" must abide by all involved licenses, including the GPL. Their own license, and the GPL license. The GPL is clear that if you cannot abide by all licenses, then don't do this.

Nokinside 9y ago
http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html ----8<---- But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour. Basically: - anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it. Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area. Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kernel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking). So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived. Linus ----8<---- The real issue is if anyone who can claim copyright to Linux kernel will sue Canonical. I don't think so.
- mjw1007 9y ago
  The relevant question isn't whether a kernel module is a derived work of the kernel (which is what Linus is discussing there). It's whether someone who distributes the kernel module and the kernel together is obliged to distribute the module under GPL terms as described in the "part of a whole" paragraph: « If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. » (It seems pretty clear to me that the answer is "yes".)
  - Nokinside 9y ago
    Intention of the copyright owners matters, see my other comment.
- DannyB2 9y ago
  A Linux kernel module is a derived work of the kernel and under GPL. While ZFS may not be a derived work of Linux, you have to glue it to GPL code. And the GPL license is viral. Is it possible to glue a kernel module shim to something else under License A, glued to another shim under License B, etc until you have license compatibility with ZFS? At the very least, this would seem to violate the very spirit of what the GPL intends.
  - phkahler 9y ago
    And yet most of us wanted Google not to be held liable for infringing Java copyrights when they implemented the same APIs for Android. Theoretically one could use that reasoning to make an OS that's API-compatible with Linux but under a different license. They could then write a .ko for that other OS under that other license, and yet it would be compatible with Linux and non-infringing. I'm not sure where the legal line is going to get drawn, but clearly it's still fuzzy.
fredgrott 9y ago
the problem with that point is that certain open source Mobile OSes have been doing exactly that with the closed source SOC drivers found in most mobile handsets
cryptonector 9y ago
If the module has no code from the Linux kernel, then how can it be said to derive from it? Well, some would say that a distribution that includes both is deriving one or the other from.. the other, since in the end both will be loaded in one "process". I think that's too much of a stretch, though ultimately that would have to be decided by the courts, naturally. Or maybe it's a strawman -- I really don't understand the arguments that Canonical is violating the GPL here.

Nokinside 9y ago

http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html ----8<---- But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour. Basically: - anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it. Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area. Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kernel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking). So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived. Linus ----8<---- The real issue is if anyone who can claim copyright to Linux kernel will sue Canonical. I don't think so.

mjw1007 9y ago
The relevant question isn't whether a kernel module is a derived work of the kernel (which is what Linus is discussing there). It's whether someone who distributes the kernel module and the kernel together is obliged to distribute the module under GPL terms as described in the "part of a whole" paragraph: « If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. » (It seems pretty clear to me that the answer is "yes".)
- Nokinside 9y ago
  Intention of the copyright owners matters, see my other comment.
DannyB2 9y ago
A Linux kernel module is a derived work of the kernel and under GPL. While ZFS may not be a derived work of Linux, you have to glue it to GPL code. And the GPL license is viral. Is it possible to glue a kernel module shim to something else under License A, glued to another shim under License B, etc until you have license compatibility with ZFS? At the very least, this would seem to violate the very spirit of what the GPL intends.
- phkahler 9y ago
  And yet most of us wanted Google not to be held liable for infringing Java copyrights when they implemented the same APIs for Android. Theoretically one could use that reasoning to make an OS that's API-compatible with Linux but under a different license. They could then write a .ko for that other OS under that other license, and yet it would be compatible with Linux and non-infringing. I'm not sure where the legal line is going to get drawn, but clearly it's still fuzzy.

fredgrott 9y ago

the problem with that point is that certain open source Mobile OSes have been doing exactly that with the closed source SOC drivers found in most mobile handsets

cryptonector 9y ago

If the module has no code from the Linux kernel, then how can it be said to derive from it? Well, some would say that a distribution that includes both is deriving one or the other from.. the other, since in the end both will be loaded in one "process". I think that's too much of a stretch, though ultimately that would have to be decided by the courts, naturally. Or maybe it's a strawman -- I really don't understand the arguments that Canonical is violating the GPL here.