4 ms·

Part of your comment illustrates the confusion I was seeking - and apparently failing - to point out. You wrote: "The issue is whether the conjoined pieces th

by iam-TJ 11y ago

Part of your comment illustrates the confusion I was seeking - and apparently failing - to point out. You wrote: "The issue is whether the conjoined pieces that Ubuntu plans to distribute constitute a single "work", for if so the GPL says that this "work" cannot be distributed with the ZFS source offered under the less restrictive CDDL." My point is that the OpenZFS on Linux project contains individual components licensed by either the CDDL or GPLv2 is where the problem lies. As in, if I distribute binaries of the OpenZFS on Linux project to you on their own this apparent CDDL vs GPLv2 conflict arises. In that case bundling with the Linux kernel is irrelevant to the claimed issue of license incompatibility (unless the SPL is considered a derivative work of Linux [and that implies some further license interference pattern] - but equally it could be said SPL is a derivative of Solaris). Bundling would usually fall under the copyright aggregation definition, which in almost all jurisdictions does not cause license conflicts between the component parts of the aggregated works.

nkurz 11y ago
I noticed your distinction, but didn't see the relevance at first. With your clarification, I think I understand your point, although I still think this is separate from the current kerfuffle with Canonical. Mogen and Choudhary address come close to addressing this in a footnote: 4. The phrase "derivative work" is also a term of art in US copyright law, but is absent from most of the rest of the world's major copyright systems. The idiosyncratic meaning of "derivative work" in US copyright law is unrelated to the use of the term by the kernel developers. This causes confusion among US copyright lawyers, but the kernel community's use of the phrase is consistent and clear notwithstanding. I don't know that they are correct, but I think they would assert that while a collection of kernel modules bundled as a single download could constitute a "derivative work" under US copyright law, it does not constitute a "derivative work" as defined by the GPL, and thus does not violate the license. I think you raise a good point, though, and I don't think there is yet any case law covering this. Is it legal to distribute a tar file that contains both GPL and non-GPL files? I'd hope so, and hope that a court would agree, although I fear it would depend on which court and which lawyers are arguing it.
- iam-TJ 11y ago
  I was using the definition of 'derivative' from copyright.gov [0] The most direct quote I can lift from there is: "To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work. The derivative work right is often referred to as the adaptation right" That document also defines what I term an "aggregate" work as "Collective" works (Compilations). Software Freedom Conservancy (SFC) claims [1]: "In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b)" So if OpenZFS on Linux's spl.ko is considered a derivative work of the Linux kernel it abides by 'GPLv2 section 2(b)'. "b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." [2] SFC seems to be trying to extend the 'derivative' definition to the independently developed CDDL OpenZFS Solaris code in zfs.ko et al. which is ported/portable across several operating systems. Additionally, to get ever more precise in the analysis, bearing in mind the supposed issue here is triggering GPLv2 section 2(b) incompatibility at the point of distribution of binaries by Canonical (or others): 1. If I distribute OpenZFS on Linux binaries to you on their own I'm distributing effectively 8 compiled executable files which are either CDDL or GPLv2 licensed. Is this incompatible with GPLv2 section 2(b)? 2. If I distribute those 8 OpenZFS on Linux binaries to you in the same package as another GPLv2 licensed work that is a Collective Work; is this incompatible? 3. If I distribute both Opens ZFS on Linux and Linux Kernel binaries in the same package is this a Collective or a Derivative work, and if the latter, where does the reach of the GPLv2 end? I cannot see any sustainable argument that the CDDL code (zfs.ko et al.) could be considered a derivative work since it is independent cross-OS code originally written for and targeted at Solaris. At this stage of analysis consider the way SFC talks about the 'kernel' as a single 'work' in terms of copyright: "But when essentially the same code is linked into kernel space through the LKM APIs, it becomes part of one work with the kernel, and a potential conflict of license terms results." So now the issue seems to have switched from "it is incompatible to distribute the OpenZFS on Linux and Linux kernel binaries together" to "it is incompatible to link them at run-time". Canonical is responsible for the former but the User is responsible for the latter. SFC also makes the argument that the Open ZFS on Linux GPLv2-ed binaries are licensed "subject to the kernel copyright holders' interpretation of those terms". But is (as I posited previously) spl.ko a derivative work of the Linux kernel, or of OpenZFS, or Solaris, or all, or none? As SPL contains original creative copyrightable code wouldn't the 'interpretation' of the programmers who wrote the SPL code be more controlling than that of the programmers that wrote the Linux kernel API it calls? Furthermore, at the point of distribution those binaries do not contain Linux kernel copyright code in the 'derivative' sense, but have place-holders for linking into the Linux kernel API that will be done by an executing kernel. It's certainly a very intriguing case study of licensing; hopefully it'll eventually help more programmers clarify their understanding. Personally I publish all my code under the GPL, version 3 for preference, which I consider a way of encouraging 'pay-forward'. I'd be extremely annoyed (to put it mildly) if an unconnected third party was making claims that implicitly marginalised my intentions when I chose the license. On a final (perverse yet humorous) note - this entire discussion is based on the assumption of U.S.A. copyright law and its derivative legal theory. Canonical is a U.K. company operating under E.U./U.K. law. In strict legal theory if this 'incompatibility' were taken to its maximum extent it could end up being legal to distribute OpenZFS on Linux binaries everywhere but in the U.S.A! [0] http://www.copyright.gov/circs/circ14.pdf http://www.copyright.gov/circs/circ14.pdf [1] http://softwarefreedom.org/resources/2016/linux-kernel-cddl.html http://softwarefreedom.org/resources/2016/linux-kernel-cddl.... [2] https://www.gnu.org/licenses/gpl-2.0.en.html https://www.gnu.org/licenses/gpl-2.0.en.html

by iam-TJ 11y ago

nkurz 11y ago

I noticed your distinction, but didn't see the relevance at first. With your clarification, I think I understand your point, although I still think this is separate from the current kerfuffle with Canonical. Mogen and Choudhary address come close to addressing this in a footnote: 4. The phrase "derivative work" is also a term of art in US copyright law, but is absent from most of the rest of the world's major copyright systems. The idiosyncratic meaning of "derivative work" in US copyright law is unrelated to the use of the term by the kernel developers. This causes confusion among US copyright lawyers, but the kernel community's use of the phrase is consistent and clear notwithstanding. I don't know that they are correct, but I think they would assert that while a collection of kernel modules bundled as a single download could constitute a "derivative work" under US copyright law, it does not constitute a "derivative work" as defined by the GPL, and thus does not violate the license. I think you raise a good point, though, and I don't think there is yet any case law covering this. Is it legal to distribute a tar file that contains both GPL and non-GPL files? I'd hope so, and hope that a court would agree, although I fear it would depend on which court and which lawyers are arguing it.

iam-TJ 11y ago
I was using the definition of 'derivative' from copyright.gov [0] The most direct quote I can lift from there is: "To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work. The derivative work right is often referred to as the adaptation right" That document also defines what I term an "aggregate" work as "Collective" works (Compilations). Software Freedom Conservancy (SFC) claims [1]: "In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b)" So if OpenZFS on Linux's spl.ko is considered a derivative work of the Linux kernel it abides by 'GPLv2 section 2(b)'. "b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." [2] SFC seems to be trying to extend the 'derivative' definition to the independently developed CDDL OpenZFS Solaris code in zfs.ko et al. which is ported/portable across several operating systems. Additionally, to get ever more precise in the analysis, bearing in mind the supposed issue here is triggering GPLv2 section 2(b) incompatibility at the point of distribution of binaries by Canonical (or others): 1. If I distribute OpenZFS on Linux binaries to you on their own I'm distributing effectively 8 compiled executable files which are either CDDL or GPLv2 licensed. Is this incompatible with GPLv2 section 2(b)? 2. If I distribute those 8 OpenZFS on Linux binaries to you in the same package as another GPLv2 licensed work that is a Collective Work; is this incompatible? 3. If I distribute both Opens ZFS on Linux and Linux Kernel binaries in the same package is this a Collective or a Derivative work, and if the latter, where does the reach of the GPLv2 end? I cannot see any sustainable argument that the CDDL code (zfs.ko et al.) could be considered a derivative work since it is independent cross-OS code originally written for and targeted at Solaris. At this stage of analysis consider the way SFC talks about the 'kernel' as a single 'work' in terms of copyright: "But when essentially the same code is linked into kernel space through the LKM APIs, it becomes part of one work with the kernel, and a potential conflict of license terms results." So now the issue seems to have switched from "it is incompatible to distribute the OpenZFS on Linux and Linux kernel binaries together" to "it is incompatible to link them at run-time". Canonical is responsible for the former but the User is responsible for the latter. SFC also makes the argument that the Open ZFS on Linux GPLv2-ed binaries are licensed "subject to the kernel copyright holders' interpretation of those terms". But is (as I posited previously) spl.ko a derivative work of the Linux kernel, or of OpenZFS, or Solaris, or all, or none? As SPL contains original creative copyrightable code wouldn't the 'interpretation' of the programmers who wrote the SPL code be more controlling than that of the programmers that wrote the Linux kernel API it calls? Furthermore, at the point of distribution those binaries do not contain Linux kernel copyright code in the 'derivative' sense, but have place-holders for linking into the Linux kernel API that will be done by an executing kernel. It's certainly a very intriguing case study of licensing; hopefully it'll eventually help more programmers clarify their understanding. Personally I publish all my code under the GPL, version 3 for preference, which I consider a way of encouraging 'pay-forward'. I'd be extremely annoyed (to put it mildly) if an unconnected third party was making claims that implicitly marginalised my intentions when I chose the license. On a final (perverse yet humorous) note - this entire discussion is based on the assumption of U.S.A. copyright law and its derivative legal theory. Canonical is a U.K. company operating under E.U./U.K. law. In strict legal theory if this 'incompatibility' were taken to its maximum extent it could end up being legal to distribute OpenZFS on Linux binaries everywhere but in the U.S.A! [0] http://www.copyright.gov/circs/circ14.pdf http://www.copyright.gov/circs/circ14.pdf [1] http://softwarefreedom.org/resources/2016/linux-kernel-cddl.html http://softwarefreedom.org/resources/2016/linux-kernel-cddl.... [2] https://www.gnu.org/licenses/gpl-2.0.en.html https://www.gnu.org/licenses/gpl-2.0.en.html