4 ms·
I'd really like to understand your perspective! My current/primitive understanding: * CDDL is 'BSD-like'- allowing the right for CDDL code to co-exist in perh
by napkin 3y ago
I'd really like to understand your perspective!
My current/primitive understanding:
* CDDL is 'BSD-like'- allowing the right for CDDL code to co-exist in perhaps proprietary/closed source codebase, so long as the CDDL parts remain CDDL. It does not make demands for non-CDDL parts, allowing dual-license scenarios?
* GPL demands all code in the same codebase are subject to GPL. e.g. This excludes a scenario where some parts are open source, and others proprietary/closed.
* All contributions to the Linux kernel are subject to GPL
* Say OpenZFS is merged into Linux, CDDL demands that OpenZFS parts remain CDDL?
Now the resulting codebase has more restrictions than the spirit of the CDDL allows for. Is this not a conflict?
If you could attempt to ELI5 how I'm potentially getting part of this wrong, or point me to some article, I'd appreciate it! I honestly find this stuff pretty confusing.
- yjftsjthsd-h 3y agoIANAL, but my understanding of some of the details differs: > CDDL is 'BSD-like'- allowing the right for CDDL code to co-exist in perhaps proprietary/closed source codebase, so long as the CDDL parts remain CDDL. It does not make demands for non-CDDL parts, allowing dual-license scenarios? It's more like halfway between GPL and BSD. Importantly, BSD licenses impose sufficiently limited conditions that BSD code can be subject to GPL conditions at the same time without violating either license. CDDL makes mutually exclusive demands with GPL. (But yes, CDDL does allow for mixed CDDL+proprietary systems; that's what it was created for. Sun wanted to open source Solaris, but needed to be able to keep some parts of it closed-source (because they didn't actually own all the code, having licensed some of it from third parties).) > All contributions to the Linux kernel are subject to GPL There's actually non-GPL code in there, but it's all under GPL compatible licenses, so the final result is GPL. But for instance, if someone wanted to put in the work and there was interest, you could almost certainly get HAMMER2 from dragonfly BSD included into Linux because it'll be under a BSD license that's GPL compatible. > Now the resulting codebase has more restrictions than the spirit of the CDDL allows for. Is this not a conflict? Yes, that's basically the conflict. Note that there is some difference of opinion on the situation; Canonical, for instance, seems to believe that they can ship ZFS kernel modules under the CDDL without making them part of the GPL kernel and thus not mix the licenses. Others say that compiling the ZFS modules against the kernel makes the result a derivative work of the kernel and therefore is a conflict. Until someone actually tries to file a lawsuit over it, I don't know that we definitively know.
- mustache_kimono 3y ago> If you could attempt to ELI5 how I'm potentially getting part of this wrong, or point me to some article, I'd appreciate it! Suffice to say: a shallow reading of the GPLv2 might lead one to believe that the CDDL and the GPLv2 are incompatible. And I believe SFC and FSF's readings of the GPLv2 and copyright law, which the GPL incorporates by reference, are shallow. There are quite a few reasons to believe a CDDL and ZFS combination would not be incompatible. If you want learned legal opinions expressing my/this contrary view there are a few. [0], [1], [2]. Moreover, I'd warn you that SFC and FSF are not disinterested parties. They have agendas which extend beyond whether ZFS is actually incompatible to what that might mean for the GPL. If you want my unschooled personal understanding -- most generally, there is no reason to believe that dynamic linking creates a derived work. Without further reasoning, FSF's analysis obliterates this boundary without reference to case law, and without an argument as why this must be the case. Whereas I think there are sound copyright law reasons to think where one creates an API boundary, through the use of dynamic linking or otherwise (a modular kernel interface), fair use allows one to make use of software at that boundary. This is a difficult pill to swallow for many FOSS advocates because this would mean closed source software modules would be permissible in combination with the Linux kernel. And while I understand their political reasoning for disfavoring this view, I think their legal reasoning is weak. I also think the FSF view makes it much harder to build software which interoperates with other software, which BTW should be a key goal of the FSF and FOSS advocates. I'm just not sure your copyright license has this kind of power. Imagine you build some software which links to MegaEvil Corp's libc, whose license specifically states, if you link to this libc, your work is a derived work of MegaCorp libc, you forfeit all copyright to MegaEvil Corp. My feeling is any court would say building any such software at an API boundary is fair use and copyright law simply does not grant any court the power to enforce this copyright term. More specifically re: ZFS module and the GPL, I'd dig into what is a "derived work". The GPLv2 after all incorporates the copyright term by reference at Section 0 when describing a "work based on the Program". I'd consider the ambiguity of what is the "whole" work as described in Section 2 and how that might be construed in light of the long held copyright distinction between derived and collective works. I'd also consider recent copyright jurisprudence when asking whether any court would take the view that distributing the Linux kernel and ZFS module is a copyright violation. [3], [4]. [0]: https://softwarefreedom.org/resources/2016/linux-kernel-cddl.html https://softwarefreedom.org/resources/2016/linux-kernel-cddl... [1]: http://www.networkworld.com/article/2301697/smb/encouraging-closed-source-modules-part-1--copyright-and-software.html http://www.networkworld.com/article/2301697/smb/encouraging-... [2]: https://www.linuxjournal.com/article/6366 https://www.linuxjournal.com/article/6366 [3]: https://en.wikipedia.org/wiki/Sega_v._Accolade https://en.wikipedia.org/wiki/Sega_v._Accolade [4]: https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nintendo_of_America,_Inc https://en.wikipedia.org/wiki/Lewis_Galoob_Toys,_Inc._v._Nin....