3 ms·

He's not talking specifically about ZFS, he's talking generally about non-GPL licensed modules and the kernel.

by robbyt 11y ago

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

He's not talking specifically about ZFS, he's talking generally about non-GPL licensed modules and the kernel.

by robbyt 11y ago

He's not talking specifically about ZFS, he's talking generally about non-GPL licensed modules and the kernel.

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