3 ms·

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 GP

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".
resf 9y ago
Stupid question: can the glue code not be licensed under both GPL and CCDL? Clearly ZFS is not a derivative work of Linux and Linux is not a derivative work of ZFS. Only the glue code is in violation (because it derives from both).
- cryptonector 9y ago
  I'm not sure this is true. It's certainly possible to construct an API/ABI such that one could build the glue, or even dispense with it, without having to use any part of ZFS or the kernel to build the other or the glue. I'm not saying that's been done. But it could be done. Indeed, that's what FUSE is, for example, and that's what NDIS does, for another. To determine whether there is glue here that violates the GPL would require looking at the particulars. Said glue might be licensed under the GPL, and might export the sorts of interfaces that Illumos does, thus allowing the ZFS module to link without reference to either the glue or the kernel! Then how could such glue be said to violate the GPL? It couldn't! Nor could ZFS be said to be violating the GPL in that case. I don't think you can avoid an escape hatch for the GPL in the kernel without disallowing dynamic loading or modifying the GPL to have harsher terms. But recall that the GPL, and/or much software distributed under the GPL, is designed to have escape hatches: so you can run proprietary software using standard interfaces, for example (i.e., user-land code is not required to be GPLed just because it runs on a GPLed kernel, though a kernel could require it, it's just that _Linux_ doesn't). It seems here you can't have your cake and eat it too.
belorn 9y ago
The idea to use shims in order to evade the law seems extremely dubious to me. I just can't see a judge say "oh, nice trick there in evading the intention of the copyright authors. I will now rule in your favor".
dragonwriter 9y ago
> A Linux kernel module is a derived work of the kernel I'd like to see more legal argument, with citation to applicable precedent, on this conclusion. It necessarily, for functional reasons, makes some use of copyrighted kernel interfaces, but whether this use of functional elements makes it a legal derivative work is a question I've seen many people present cobflicting conclusions on, but never with much argument supporting the conclusion.
- cryptonector 9y ago
  Imagine a kernel module which provides a bridge between an external (possibly standard, for some value of standard) API/ABI on one side, and the Linux kernel's internal interfaces on the other. Such a module might derive from the kernel depending on whether those internal interfaces can be copyrighted (and, do we want it to be the case that all interfaces can be copyrighted and licensed restrictively?! probably not), in which case it would have to be distributed under the terms of the GPL. But other modules using that external API/ABI certainly could not be said to be derived from the kernel, full stop. This then requires looking for a way in which the GPL prevents creating such adaptor modules. I don't see how it does. Perhaps it could if modified, but as it is I don't think it does. IANAL though.

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

resf 9y ago

Stupid question: can the glue code not be licensed under both GPL and CCDL? Clearly ZFS is not a derivative work of Linux and Linux is not a derivative work of ZFS. Only the glue code is in violation (because it derives from both).

cryptonector 9y ago
I'm not sure this is true. It's certainly possible to construct an API/ABI such that one could build the glue, or even dispense with it, without having to use any part of ZFS or the kernel to build the other or the glue. I'm not saying that's been done. But it could be done. Indeed, that's what FUSE is, for example, and that's what NDIS does, for another. To determine whether there is glue here that violates the GPL would require looking at the particulars. Said glue might be licensed under the GPL, and might export the sorts of interfaces that Illumos does, thus allowing the ZFS module to link without reference to either the glue or the kernel! Then how could such glue be said to violate the GPL? It couldn't! Nor could ZFS be said to be violating the GPL in that case. I don't think you can avoid an escape hatch for the GPL in the kernel without disallowing dynamic loading or modifying the GPL to have harsher terms. But recall that the GPL, and/or much software distributed under the GPL, is designed to have escape hatches: so you can run proprietary software using standard interfaces, for example (i.e., user-land code is not required to be GPLed just because it runs on a GPLed kernel, though a kernel could require it, it's just that _Linux_ doesn't). It seems here you can't have your cake and eat it too.

belorn 9y ago

The idea to use shims in order to evade the law seems extremely dubious to me. I just can't see a judge say "oh, nice trick there in evading the intention of the copyright authors. I will now rule in your favor".

dragonwriter 9y ago

> A Linux kernel module is a derived work of the kernel I'd like to see more legal argument, with citation to applicable precedent, on this conclusion. It necessarily, for functional reasons, makes some use of copyrighted kernel interfaces, but whether this use of functional elements makes it a legal derivative work is a question I've seen many people present cobflicting conclusions on, but never with much argument supporting the conclusion.

cryptonector 9y ago
Imagine a kernel module which provides a bridge between an external (possibly standard, for some value of standard) API/ABI on one side, and the Linux kernel's internal interfaces on the other. Such a module might derive from the kernel depending on whether those internal interfaces can be copyrighted (and, do we want it to be the case that all interfaces can be copyrighted and licensed restrictively?! probably not), in which case it would have to be distributed under the terms of the GPL. But other modules using that external API/ABI certainly could not be said to be derived from the kernel, full stop. This then requires looking for a way in which the GPL prevents creating such adaptor modules. I don't see how it does. Perhaps it could if modified, but as it is I don't think it does. IANAL though.