6 ms·

This appears to be inaccurate. They appear to be distributing it as a binary module, outside of the kernel tree, just like many other binary-only kernel modules

This appears to be inaccurate. They appear to be distributing it as a binary module, outside of the kernel tree, just like many other binary-only kernel modules. See zfs.ko here: http://blog.dustinkirkland.com/2016/02/zfs-is-fs-for-containers-in-ubuntu-1604.html http://blog.dustinkirkland.com/2016/02/zfs-is-fs-for-contain... "However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code.": http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue The binary kernel image is a separate issue from the kernel packages (deb); they could include multiple files in a kernel package (deb) that are licensed under different licenses.

awalton 11y ago
Regardless of how the binary is shipped (which could be legal), their aggregation of the source is likely not, since it almost certainly is a derivative work at that point. The fact they have a public git repo where the two codebases touch is probably enough to bait a lawsuit from Oracle, in that they're distributing CDDL code in a way that is against its license. There's a reason LLNL developed their branch out-of-tree - it's just not worth the legal headaches to aggregate the source like Canonical just did.
- hhw 11y ago
  The CDDL does not prevent ZFS from being used in Linux. It's the GPL that prevents using CDDL code in the kernel. Oracle doesn't have any grounds to sue based on their IP. They would only be able to sue on behalf of Linux, and violation of the GPL. Although I wouldn't rule that out, it's somewhat less likely to happen. On the other hand, I suspect RMS isn't too happy with this turn of events. The sfconservancy may be the more likely party to bring a lawsuit. I'm curious to see either of them comment on the situation.
  - l1ambda 11y ago
    The GPL doesn't even really prevent it, the only clause is a "derived work" which is quite a stretch that a court would find a module to be such a thing.
    - belorn 11y ago
      How would you explain to a non-technical person that a kernel module is not a derived work? Can you remove the Linux kernel and still have a complete and working program? What happen if one removed all function calls to the Linux kernel or use of internal kernel variables? As a module, does it work with any other kernels like windows or apple, and what was the programmers intention when writing it? There is some arguments in favor of fair use in regard to compatibility, where derived works are infringements but still deemed legal. The courts has historically been rather split on this subject when it comes to software, in particular with several cases voting in favor of unlicensed modules to consoles. It would be quite a big bet either way you vote.
      - tzs 11y ago
        > How would you explain to a non-technical person that a kernel module is not a derived work? GPLv2 does not use the term "derived work" anywhere. It uses "work [...] derived from the Program", and does not define this term [1]. I'd start out by explaining that before we even get to the question of whether or not the module is a "work [...] derived from the Program", we have to ask the question of whether or not the license even applies. GPLv2 only applies if the module does something that requires permission under copyright law. The copyright law question that needs to be asked is whether or not the module is a "derivative work" of the kernel. > Can you remove the Linux kernel and still have a complete and working program? What happen if one removed all function calls to the Linux kernel or use of internal kernel variables? As a module, does it work with any other kernels like windows or apple, and what was the programmers intention when writing it? None of these questions are actually relevant to the copyright law question of whether or not it is a derivative work. They are relevant to the question of whether or not it is useful when not used in conjunction with a Linux kernel but that's not a copyright law question. To answer the copyright law question of whether or not some program P [2] is a derivative work of some other program Q, you only need to look at the source code to P and Q. If P and Q interact with each other (unilaterally or bilaterally, directly or indirectly) some people get hung up on the mechanism of that interaction, but that's not relevant to the question of whether or not P is a derivative work. Whether or not a program P that uses function names, function argument ordering, and data structures of program Q, but does not copy algorithmic code from Q, is a derivative work of Q is going to essentially come down to whether or not the interface (I'm including data structures as part of the interface) of Q is copyrightable. If program interfaces are copyrightable, then programs that interact with other programs will be derivative works of those programs, regardless of whether they interface by static linking, dynamic linking, system calls from a user process P to kernel code Q, IPC from process P to process Q, RPC from process P across a network to process Q on another machine and so on. If program interfaces are not copyrightable, then as long as all P incorporates from Q are interfaces P won't be a derivative work. Generally, courts have held that program interfaces are not copyrightable (with the notable exception of the Court of Appeals for the Federal Circuit in the Oracle vs. Google case, which does not set copyright precedent). Thus we arrive at the major question for kernel modules: what copyrightable kernel elements do they incorporate? If they just incorporate non-copyrightable interfaces then a kernel module would not be a derivative work of the kernel. That's not the end of the inquiry though. It would be if some third party were making and distributing the module. E.g., if I were to write a kernel module that does not incorporate any copyrightable kernel elements and distribute it stand alone, for others to download if they want and use it with their kernels, we'd be done. In the case of a distribution vendor distributing a kernel module along with a kernel, then even though the module itself might not be a derivative work their distribution as a whole is. Questions might arise as to just what constitutes a "work". If they statically link the module to the kernel, the resulting binary is clearly a work, and it is a derivative work of both the kernel and the module, and so the module would have to be GPL. It is important to note in this case that this is because the combined work is a derivative work of the kernel...the module itself is still not a derivative work of the kernel. How about if the module is dynamically linked, but the configuration they ship automatically loads it at boot time? Might one argue that the kernel, init scripts, and dynamic modules together are all one work that the vendor is distributing? [1] For completeness, GPLv3 does not use "derive" or "derived" or any similar terms it all. It uses the term "covered work", which is defined as the original program or a "work based on the Program", and it defines that as basically a work that requires copyright permission. [2] I'm going to use the term "program" expansively to include modules, applications, plug-ins, and so on.
  - gillianseed 11y ago
    The CDDL was crafted with GPL existing and was according to the person responsible for creating it, deliberately made incompatible with GPLv2. Of course not hard to understand given that Sun had no reason whatsoever to hand over their prized technology (ZFS, DTrace) to the competitor which was killing them in the market. >On the other hand, I suspect RMS isn't too happy with this turn of events. Why not ? >The sfconservancy may be the more likely party to bring a lawsuit. That would require that a Linux copyright holder would want to sue, why would they ? OpenZFS is open source, and previous suits has been about source code compliance.
    - ryao 11y ago
      It is probably more accurate to claim the GPL was designed to be incompatible with an entire class of licenses that includes the CDDL, and the MPL on which it was based and any future licenses similar to or based on licenses in that class (of which the CDDL was given that it was made after the GPL). There is no clause in the CDDL that places restrictions on other files in a combined work, but there is one the GPL. There are people out there who dislike the GPL for that, there are some people who explicitly go out of their way to avoid GPL compatibility because of that and I am sure that some of those people existed at Sun, but I really doubt that the design of a license by a huge organization with many people giving input can be simplified to one guy thinking GPL incompatibility is a good feature. I also think this happened years ago and there really is no point to living in the past. People cannot distribute a vmlinux file with ZFS linked into it (i.e. not a kernel module, but part of the binary itself) because of that, but that does not stop people from distributing it as a kernel module and that is how filesystem code is loaded these days, so it is a non-issue.
      - ajsalminen 11y ago
        > It is probably more accurate to claim the GPL was designed to be incompatible with an entire class of licenses that includes the CDDL, and the MPL on which it was based and any future licenses similar to or based on licenses in that class (of which the CDDL was given that it was made after the GPL). Given that work was done to make GPLv3 more compatible with other open source licenses and that GPLv2 predates both of the licenses you mention by quite a bit I'm inclined to think that's nonsense.

awalton 11y ago

Regardless of how the binary is shipped (which could be legal), their aggregation of the source is likely not, since it almost certainly is a derivative work at that point. The fact they have a public git repo where the two codebases touch is probably enough to bait a lawsuit from Oracle, in that they're distributing CDDL code in a way that is against its license. There's a reason LLNL developed their branch out-of-tree - it's just not worth the legal headaches to aggregate the source like Canonical just did.

hhw 11y ago
The CDDL does not prevent ZFS from being used in Linux. It's the GPL that prevents using CDDL code in the kernel. Oracle doesn't have any grounds to sue based on their IP. They would only be able to sue on behalf of Linux, and violation of the GPL. Although I wouldn't rule that out, it's somewhat less likely to happen. On the other hand, I suspect RMS isn't too happy with this turn of events. The sfconservancy may be the more likely party to bring a lawsuit. I'm curious to see either of them comment on the situation.
- l1ambda 11y ago
  The GPL doesn't even really prevent it, the only clause is a "derived work" which is quite a stretch that a court would find a module to be such a thing.
  - belorn 11y ago
    How would you explain to a non-technical person that a kernel module is not a derived work? Can you remove the Linux kernel and still have a complete and working program? What happen if one removed all function calls to the Linux kernel or use of internal kernel variables? As a module, does it work with any other kernels like windows or apple, and what was the programmers intention when writing it? There is some arguments in favor of fair use in regard to compatibility, where derived works are infringements but still deemed legal. The courts has historically been rather split on this subject when it comes to software, in particular with several cases voting in favor of unlicensed modules to consoles. It would be quite a big bet either way you vote.
    - tzs 11y ago
      > How would you explain to a non-technical person that a kernel module is not a derived work? GPLv2 does not use the term "derived work" anywhere. It uses "work [...] derived from the Program", and does not define this term [1]. I'd start out by explaining that before we even get to the question of whether or not the module is a "work [...] derived from the Program", we have to ask the question of whether or not the license even applies. GPLv2 only applies if the module does something that requires permission under copyright law. The copyright law question that needs to be asked is whether or not the module is a "derivative work" of the kernel. > Can you remove the Linux kernel and still have a complete and working program? What happen if one removed all function calls to the Linux kernel or use of internal kernel variables? As a module, does it work with any other kernels like windows or apple, and what was the programmers intention when writing it? None of these questions are actually relevant to the copyright law question of whether or not it is a derivative work. They are relevant to the question of whether or not it is useful when not used in conjunction with a Linux kernel but that's not a copyright law question. To answer the copyright law question of whether or not some program P [2] is a derivative work of some other program Q, you only need to look at the source code to P and Q. If P and Q interact with each other (unilaterally or bilaterally, directly or indirectly) some people get hung up on the mechanism of that interaction, but that's not relevant to the question of whether or not P is a derivative work. Whether or not a program P that uses function names, function argument ordering, and data structures of program Q, but does not copy algorithmic code from Q, is a derivative work of Q is going to essentially come down to whether or not the interface (I'm including data structures as part of the interface) of Q is copyrightable. If program interfaces are copyrightable, then programs that interact with other programs will be derivative works of those programs, regardless of whether they interface by static linking, dynamic linking, system calls from a user process P to kernel code Q, IPC from process P to process Q, RPC from process P across a network to process Q on another machine and so on. If program interfaces are not copyrightable, then as long as all P incorporates from Q are interfaces P won't be a derivative work. Generally, courts have held that program interfaces are not copyrightable (with the notable exception of the Court of Appeals for the Federal Circuit in the Oracle vs. Google case, which does not set copyright precedent). Thus we arrive at the major question for kernel modules: what copyrightable kernel elements do they incorporate? If they just incorporate non-copyrightable interfaces then a kernel module would not be a derivative work of the kernel. That's not the end of the inquiry though. It would be if some third party were making and distributing the module. E.g., if I were to write a kernel module that does not incorporate any copyrightable kernel elements and distribute it stand alone, for others to download if they want and use it with their kernels, we'd be done. In the case of a distribution vendor distributing a kernel module along with a kernel, then even though the module itself might not be a derivative work their distribution as a whole is. Questions might arise as to just what constitutes a "work". If they statically link the module to the kernel, the resulting binary is clearly a work, and it is a derivative work of both the kernel and the module, and so the module would have to be GPL. It is important to note in this case that this is because the combined work is a derivative work of the kernel...the module itself is still not a derivative work of the kernel. How about if the module is dynamically linked, but the configuration they ship automatically loads it at boot time? Might one argue that the kernel, init scripts, and dynamic modules together are all one work that the vendor is distributing? [1] For completeness, GPLv3 does not use "derive" or "derived" or any similar terms it all. It uses the term "covered work", which is defined as the original program or a "work based on the Program", and it defines that as basically a work that requires copyright permission. [2] I'm going to use the term "program" expansively to include modules, applications, plug-ins, and so on.
- gillianseed 11y ago
  The CDDL was crafted with GPL existing and was according to the person responsible for creating it, deliberately made incompatible with GPLv2. Of course not hard to understand given that Sun had no reason whatsoever to hand over their prized technology (ZFS, DTrace) to the competitor which was killing them in the market. >On the other hand, I suspect RMS isn't too happy with this turn of events. Why not ? >The sfconservancy may be the more likely party to bring a lawsuit. That would require that a Linux copyright holder would want to sue, why would they ? OpenZFS is open source, and previous suits has been about source code compliance.
  - ryao 11y ago
    It is probably more accurate to claim the GPL was designed to be incompatible with an entire class of licenses that includes the CDDL, and the MPL on which it was based and any future licenses similar to or based on licenses in that class (of which the CDDL was given that it was made after the GPL). There is no clause in the CDDL that places restrictions on other files in a combined work, but there is one the GPL. There are people out there who dislike the GPL for that, there are some people who explicitly go out of their way to avoid GPL compatibility because of that and I am sure that some of those people existed at Sun, but I really doubt that the design of a license by a huge organization with many people giving input can be simplified to one guy thinking GPL incompatibility is a good feature. I also think this happened years ago and there really is no point to living in the past. People cannot distribute a vmlinux file with ZFS linked into it (i.e. not a kernel module, but part of the binary itself) because of that, but that does not stop people from distributing it as a kernel module and that is how filesystem code is loaded these days, so it is a non-issue.
    - ajsalminen 11y ago
      > It is probably more accurate to claim the GPL was designed to be incompatible with an entire class of licenses that includes the CDDL, and the MPL on which it was based and any future licenses similar to or based on licenses in that class (of which the CDDL was given that it was made after the GPL). Given that work was done to make GPLv3 more compatible with other open source licenses and that GPLv2 predates both of the licenses you mention by quite a bit I'm inclined to think that's nonsense.