9 ms·
Here's the other side of the argument: https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-linux/ https://insights.ubuntu.com/2016/02/18/zfs-licensing-and
by CannisterFlux 9y ago
Here's the other side of the argument:
https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-linux/ https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-lin...
"""The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module — the kernel itself is quite obviously not a derivative work of this new file system.
And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris."""
This has been shipped in Ubuntu for a year now and nothing bad has happened, so it must be OK. Maybe.
- 43224gg252 9y agoMaybe more people would adopt it if they changed the license?
- icebraining 9y agoWho is "they"?
- betaby 9y agoI guess only Oracle can change the license, since they own original ZFS now.
- 4ad 9y agoOracle can't change the license alone. While Oracle is the majority copyright holder, some parts are copyrighted by other people and/or organisations. In fact, this was one of the building principles of the CDDL license. This ZFS on Linux project mentioned in the article doesn't use the current Oracle ZFS code (which is proprietary), but rather the OpenZFS code which has had very significant changes that happened post-Oracle fork by parties other than Oracle.
- mjg59 9y agoAlmost all of ZoL is under "CDDL 1.0 or later". Oracle could release a new version of CDDL that explicitly made the ZoL project GPL compatible.
- cthalupa 9y agoI'm not sure you understand the situation, which is surprising with how much time you spend talking about it - is this willful? - Oracle (And Sun before them) do not hold all of the copyrights involved. Some of them are held by third parties. The CDDL was written to be as permissive as possible within the boundaries they are held to by these third parties. It is impossible for Oracle to release a version of the license that is GPL compatible without completely removing all of these third party components they do not hold the copyright to.
- cyphar 9y agoI would recommend reading section 4 of the CDDL (it's actually very similar to section 6 of the MPL 1.1 because that's what it was based on). In particular, it has an or-any-later version clause that is opt-out. This means that if Oracle decided to release CDDL 2.0 tomorrow that was GPL-compatible, anyone with CDDL 1.0 licensed (without the opt-out) codebases could then use it in conjunction with GPL code (by exercising the upgrade path). From memory, the original ZFS codebase (and also OpenZFS) doesn't exercise the opt-out -- which means that they can be switched this way. [This is basically how you would take LGPLv2 code and put it into an AGPLv3 codebase (LGPLv2 -> GPLv2+ -> GPLv3+ -> AGPLv3+).] I believe that's what they were trying to say. I'm not a lawyer (as usual) but that was the opinion of the community a few years ago. Canonical decided to just "go for it" and see whether Oracle will sue them. We'll see what happens in the future.
- protomyth 9y agoThe basic misunderstanding is that Oracle does not own the the copyright to all of OpenZFS. A lot of code in the OpenZFS code base is not under any sort of copyright assignment to Oracle. To change the license on the whole, you would need Oracle and all the contributors who have not done copyright assignments to agree to re-license their code.
- mrweasel 9y agoWhy would Oracle care about the number of people using ZFS on anything but Solaris?
- sqeaky 9y agoI don't know if they do care about these things, but it is conceivable they might care about: Selling support, increasing the amount of engineers familiar with their stuff, finding some new angle to try to sue Linux out of existence with or any one other goal that is furthered by the network effect.
- DannyB2 9y agoWhat "other side" of the argument. If you read the GPL, it is clearly designed to prevent EXACTLY this thing. I'm sure as it was being written, Microsoft was envisioned as the evil entity that would steal free software and mix it with closed proprietary code. The license is clearly and deliberately designed to prevent this. The "other side" may not see it this way. But the "other side" must abide by all involved licenses, including the GPL. Their own license, and the GPL license. The GPL is clear that if you cannot abide by all licenses, then don't do this.
- Nokinside 9y agohttp://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html ----8<---- But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour. Basically: - anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work. - anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it. Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area. Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kernel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking). So being a module is not a sign of not being a derived work. It's just one sign that _maybe_ it might have other arguments for why it isn't derived. Linus ----8<---- The real issue is if anyone who can claim copyright to Linux kernel will sue Canonical. I don't think so.
- scott00 9y agoDoes building zfs.ko not involve #include ing some linux header files? Or is it all done via ABI?
- zbobet2012 9y agoThe linux kernel headers are specifically exempt from the "linking" GPL infection.
- mjg59 9y agoNo they're not. The kernel is under pure GPLv2 with a clarification that using standard system calls does not create a derivative work of the kernel. There are no additional exemptions.
- deleted 9y ago[deleted]
- servilio 9y agoThere is no such thing as a "licensing infection", licenses being inert documents...
- user5994461 9y agoUnless the document has a close saying everything it touches gets infected.
- cyphar 9y agoThe GPL does not use the word "infect" in any of its versions or related licenses. You're just projecting your biases onto an inert legal document, based on a fundamental misunderstanding of copyleft.
- user5994461 9y agoLegal documents have real life implications, calling it inert is just project a fantasy of yours that they are papers with no consequences.