4 ms·

Torvalds indirectly made a strong case for ZFS being a not-derived work all the way back in 2003: http://www.gossamer-threads.com/lists/linux/kernel/401977#4019

Torvalds indirectly made a strong case for ZFS being a not-derived work all the way back in 2003: http://www.gossamer-threads.com/lists/linux/kernel/401977#401977 http://www.gossamer-threads.com/lists/linux/kernel/401977#40... He states: "having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen the argument that they clearly aren't derived." He does continue to say that he believe it would be "hard to argue that any new driver or filesystem was developed without any thought of Linux", although in the specific case of ZFS (as opposed to, say, nvidia.ko), I think there would be a strong argument that the ZFS module was originally written in whole as a non-derived work. (Obviously, Linus is not the only stakeholder here, and even his own opinion may have changed since then. Still, it's not a new conversation and the community hasn't been too ruffled by the status quo for the past 13 years)

belorn 11y ago
Wait, what? ZFS was designed and implemented by a team at Sun led by Jeff Bonwick, Bill Moore[106] and Matthew Ahrens. It was announced on September 14, 2004,[107] but development started in 2001.[108] Source code for ZFS was integrated into the main trunk of Solaris development on October 31, 2005[28] and released as part of build 27 of OpenSolaris on November 16, 2005 In 2003, Linus could not have known about ZFS without some insight knowledge, nor if the people developing it had any knowledge about linux. It also contradict the claim that CDDL was choose for the explicit purpose to prevent ZFS being used on Linux and competing with Solaris.
- robbyt 11y ago
  He's not talking specifically about ZFS, he's talking generally about non-GPL licensed modules and the kernel.
  - belorn 11y ago
    So: "having been developed totally (not) independently of Linux: they literally were developed (after) Linux even existed, by people who had (full) knowledge of Linux. That tends to strengthen the argument that...?" How is that a strong case for ZFS?
    - ori_b 11y ago
      ZFS was written independently of Linux, and in early incarnations only ran on Solaris. The only difference here is the timing.
      - belorn 11y ago
        ZFS that runs on solaris is not a linux kernel module, and that one was written independently of Linux. The developers likely knew about linux. The ZFS Linux kernel module is a port of the solaris version, and that one was written dependently on Linux. The developers knew about linux.
        ewindisch 11y ago
        The developers knew of Linux but did not necessarily design with any intention of a port or plans in regard to the Linux VFS or kernel design. When it was a Solaris kernel feature, it was clearly not derived from Linux. The modifications to make this driver to run on Linux caused a derivative work its original source (Solaris) and maybe of Linux itself. The 2003 thread implies that in such a case these modifications may not be derivative of Linux. That some kernel developers feel that the headers are factual and thus not copyrightable. One could legally blackbox recreate the necessary header files and guarantee that their kernel module was not a derivative binary, so I believe that creating a proprietary kernel module should be legal in principal. On the matter of linking, the FSF claims that dynamic linking can violate the license, but this is constituted under their understanding of a "derived work". Yet, the US code[1] clarifies that new copies and "adaptations" of a work do not constitute an infringement when created as an essential step in the utilization of the computer program[2]. The term "adaptation" is not defined but because this section is notwithstanding the author's "exclusive right... to prepare derivative works" implies that "adaptations" and "derivative works"[3] are not equal. This would strengthen a position stating that no derivative works are created by simply running, linking, or loading applications. [1] https://www.law.cornell.edu/uscode/text/17/chapter-1 https://www.law.cornell.edu/uscode/text/17/chapter-1 (read 101, 106, 117) [2] https://www.law.cornell.edu/uscode/text/17/117 https://www.law.cornell.edu/uscode/text/17/117 [3] https://www.law.cornell.edu/uscode/text/17/101 https://www.law.cornell.edu/uscode/text/17/101
epylar 11y ago
That link talks about AFS, not ZFS.
- cthalupa 11y ago
  He said he indirectly makes a strong case - not directly.
bjornsing 11y ago
For those of us that can read source code there are a couple of strong indications that the Linux copyright holders still believe that Linux kernel modules may not necessarily constitute derivative works: 1. Every Linux kernel module can tell the kernel what license regulates its use, using the MODULE_LICENSE() macro. The Linux kernel keeps track of which modules are under GPLv2 (and a few other compatible licenses). When a module under a presumably "proprietary" license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.) 2. There are two macros used to export Linux kernel symbols: EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. The former will make the symbol available to all kernel modules, while the latter makes it available only to GPL-licensed kernel modules. The clear purpose and motivation is that a kernel module that needs access to a symbol exported with EXPORT_SYMBOL_GPL must be a derivative work, while a kernel module that only depends on symbols exported with EXPORT_SYMBOL is not necessarily a derivate work. Also, IANAL, but from a purely legal perspective I think it would be difficult to get a court to agree that a user space program that talks to the Linux kernel through system calls is never a derivative work, while a kernel module (even one that accesses only symbols exported with EXPORT_SYMBOL) is always a derivative work. The system call versus dynamic loaded module distinction is simply not very relevant from a purely legal perspective.
- tobias3 11y ago
  That is why userspace programs are explicitely declared to not be derived work in the Linux kernel license https://www.kernel.org/pub/linux/kernel/COPYING https://www.kernel.org/pub/linux/kernel/COPYING (right at the top)
- caf 11y ago
  What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one. One work is the module, considered in isolation. Is that a derivative of the kernel? Possibly, but that's a reasonably high bar to clear. If it's not, distributing the module by itself can be done entirely without reference to the Linux kernel's license. The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module.

belorn 11y ago

Wait, what? ZFS was designed and implemented by a team at Sun led by Jeff Bonwick, Bill Moore[106] and Matthew Ahrens. It was announced on September 14, 2004,[107] but development started in 2001.[108] Source code for ZFS was integrated into the main trunk of Solaris development on October 31, 2005[28] and released as part of build 27 of OpenSolaris on November 16, 2005 In 2003, Linus could not have known about ZFS without some insight knowledge, nor if the people developing it had any knowledge about linux. It also contradict the claim that CDDL was choose for the explicit purpose to prevent ZFS being used on Linux and competing with Solaris.

robbyt 11y ago
He's not talking specifically about ZFS, he's talking generally about non-GPL licensed modules and the kernel.
- belorn 11y ago
  So: "having been developed totally (not) independently of Linux: they literally were developed (after) Linux even existed, by people who had (full) knowledge of Linux. That tends to strengthen the argument that...?" How is that a strong case for ZFS?
  - ori_b 11y ago
    ZFS was written independently of Linux, and in early incarnations only ran on Solaris. The only difference here is the timing.
    - belorn 11y ago
      ZFS that runs on solaris is not a linux kernel module, and that one was written independently of Linux. The developers likely knew about linux. The ZFS Linux kernel module is a port of the solaris version, and that one was written dependently on Linux. The developers knew about linux.
      - ewindisch 11y ago
        The developers knew of Linux but did not necessarily design with any intention of a port or plans in regard to the Linux VFS or kernel design. When it was a Solaris kernel feature, it was clearly not derived from Linux. The modifications to make this driver to run on Linux caused a derivative work its original source (Solaris) and maybe of Linux itself. The 2003 thread implies that in such a case these modifications may not be derivative of Linux. That some kernel developers feel that the headers are factual and thus not copyrightable. One could legally blackbox recreate the necessary header files and guarantee that their kernel module was not a derivative binary, so I believe that creating a proprietary kernel module should be legal in principal. On the matter of linking, the FSF claims that dynamic linking can violate the license, but this is constituted under their understanding of a "derived work". Yet, the US code[1] clarifies that new copies and "adaptations" of a work do not constitute an infringement when created as an essential step in the utilization of the computer program[2]. The term "adaptation" is not defined but because this section is notwithstanding the author's "exclusive right... to prepare derivative works" implies that "adaptations" and "derivative works"[3] are not equal. This would strengthen a position stating that no derivative works are created by simply running, linking, or loading applications. [1] https://www.law.cornell.edu/uscode/text/17/chapter-1 https://www.law.cornell.edu/uscode/text/17/chapter-1 (read 101, 106, 117) [2] https://www.law.cornell.edu/uscode/text/17/117 https://www.law.cornell.edu/uscode/text/17/117 [3] https://www.law.cornell.edu/uscode/text/17/101 https://www.law.cornell.edu/uscode/text/17/101

epylar 11y ago

That link talks about AFS, not ZFS.

cthalupa 11y ago
He said he indirectly makes a strong case - not directly.

bjornsing 11y ago

For those of us that can read source code there are a couple of strong indications that the Linux copyright holders still believe that Linux kernel modules may not necessarily constitute derivative works: 1. Every Linux kernel module can tell the kernel what license regulates its use, using the MODULE_LICENSE() macro. The Linux kernel keeps track of which modules are under GPLv2 (and a few other compatible licenses). When a module under a presumably "proprietary" license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.) 2. There are two macros used to export Linux kernel symbols: EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. The former will make the symbol available to all kernel modules, while the latter makes it available only to GPL-licensed kernel modules. The clear purpose and motivation is that a kernel module that needs access to a symbol exported with EXPORT_SYMBOL_GPL must be a derivative work, while a kernel module that only depends on symbols exported with EXPORT_SYMBOL is not necessarily a derivate work. Also, IANAL, but from a purely legal perspective I think it would be difficult to get a court to agree that a user space program that talks to the Linux kernel through system calls is never a derivative work, while a kernel module (even one that accesses only symbols exported with EXPORT_SYMBOL) is always a derivative work. The system call versus dynamic loaded module distinction is simply not very relevant from a purely legal perspective.

tobias3 11y ago
That is why userspace programs are explicitely declared to not be derived work in the Linux kernel license https://www.kernel.org/pub/linux/kernel/COPYING https://www.kernel.org/pub/linux/kernel/COPYING (right at the top)
caf 11y ago
What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one. One work is the module, considered in isolation. Is that a derivative of the kernel? Possibly, but that's a reasonably high bar to clear. If it's not, distributing the module by itself can be done entirely without reference to the Linux kernel's license. The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module.