4 ms·

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

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.
  - mjevans 9y ago
    You're misunderstanding the difference between an implementation of an interface and merely being compatible with an interface. We each write something that passes as 'English' the language. Yet each of our brains has a different implementation of that interface. We do not copy each other even though we happen to be able to interact.
- Nokinside 9y ago
  Licenses, copyrights and trademarks have value only when there is actual change of someone getting sued. Who among the many Linux kernel copyright holders would oppose having ZFS module? Who would be willing to sue Canonical? Will Oracle object? Eben Moglen from Software Freedom Law Center thinks its OK as long as the source is distributed and no proprietary changes is made. https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html https://www.softwarefreedom.org/resources/2016/linux-kernel-... >In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the "equity of the license," or its "spirit." As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of "equity." This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders' intention which determines which mode of interpretation is to be employed. Linus is one central figure among kernel copyright holders. When he has stated his interpretation and it seems that most other maintainers are not objecting either, kernel copyright holders' intention seems to be closer to the "equity of the license".
nialv7 9y ago
Linux has a established rule for module license. In the kernel, functions which might be used by any modules are exported using EXPORT_SYMBOL. But if a module wants to use functions exported via EXPORT_SYMBOL_GPL, then the module has to use GPL.
- cyphar 9y ago
  The thing is, it's actually not clear whether the intention here might actually harm the GPL. Effectively, programmers aren't lawyers so is marking something as EXPORT_SYMBOL_GPL considered to be a legal restriction? And does that actually imply that EXPORT_SYMBOL is not considered a derived work? The problem is that "derived work" is something that needs to be handled on a case-by-case basis -- if you had a module that scanned the kernel's address space to violate the EXPORT_SYMBOL_GPL restriction, would that module have to be under the GPL (the answer is yes IMO, even though it didn't use any EXPORT_SYMBOL_GPL APIs). This was brought up in a (very long) ML thread on LKML[1]. [1]: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003542.html https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...

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.
- mjevans 9y ago
  You're misunderstanding the difference between an implementation of an interface and merely being compatible with an interface. We each write something that passes as 'English' the language. Yet each of our brains has a different implementation of that interface. We do not copy each other even though we happen to be able to interact.
Nokinside 9y ago
Licenses, copyrights and trademarks have value only when there is actual change of someone getting sued. Who among the many Linux kernel copyright holders would oppose having ZFS module? Who would be willing to sue Canonical? Will Oracle object? Eben Moglen from Software Freedom Law Center thinks its OK as long as the source is distributed and no proprietary changes is made. https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html https://www.softwarefreedom.org/resources/2016/linux-kernel-... >In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the "equity of the license," or its "spirit." As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of "equity." This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders' intention which determines which mode of interpretation is to be employed. Linus is one central figure among kernel copyright holders. When he has stated his interpretation and it seems that most other maintainers are not objecting either, kernel copyright holders' intention seems to be closer to the "equity of the license".

nialv7 9y ago

Linux has a established rule for module license. In the kernel, functions which might be used by any modules are exported using EXPORT_SYMBOL. But if a module wants to use functions exported via EXPORT_SYMBOL_GPL, then the module has to use GPL.

cyphar 9y ago
The thing is, it's actually not clear whether the intention here might actually harm the GPL. Effectively, programmers aren't lawyers so is marking something as EXPORT_SYMBOL_GPL considered to be a legal restriction? And does that actually imply that EXPORT_SYMBOL is not considered a derived work? The problem is that "derived work" is something that needs to be handled on a case-by-case basis -- if you had a module that scanned the kernel's address space to violate the EXPORT_SYMBOL_GPL restriction, would that module have to be under the GPL (the answer is yes IMO, even though it didn't use any EXPORT_SYMBOL_GPL APIs). This was brought up in a (very long) ML thread on LKML[1]. [1]: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003542.html https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...