GPL Violations Related to Combining ZFS and Linux (2016)
sfconservancy.org
sfconservancy.org
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.
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.
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.
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.
It's effectively the same mechanism as MPL's update system, and also effectively the same as GPL's update mechanism. You can take a GPLv2-or-later codebase and redistribute it as GPLv3-or-later because the FSF has released GPLv3. Similarly, you can take a CDDL-1.0 codebase and redistribute it as CDDL-2.0 because the "or any later version" clause is implicit and opt-out.
If you agree that GPLv2-or-later code (regardless of who owns the copyright) can be redistributed or combined with GPLv3-or-later code, then you agree with the basic point of what I'm saying. Obviously the specifics are different but the basic idea is the same.
Seriously. Read section 4 of the CDDL[1]. It's only three short paragraphs.
[1]: https://github.com/zfsonlinux/zfs/blob/master/OPENSOLARIS.LI...
1. Re-implement those files. 2. Ask the current copyright holder to remove the opt-out.
Given how small the number of lines is[1], I would be surprised if re-implementing would take more than a few weeks.
True, but I don't think the OpenZFS developers would be against relicensing their code to be GPL compatible,they are offering a Linux version of OpenZFS after all, so if Oracle would re/dual license their part of the code in a GPL compatible manner I'm sure the OpenZFS devs would do the same.
Or, they might object because this hypothetical new license is incompatible with FreeBSD for various reasons, legal or otherwise, and they would not be able to get new contributions back into FreeBSD.
I believe it was in the same talk that Cantrill likened Ellison to a lawnmower, but an ex-Sun employee talked about how the tangled legal web of who owned what part of Solaris precluded them from being able to release it under the GPL, and thus the CDDL was born. My understanding is that, if any of these bits that they do not own themselves and have restrictions on how they can license them, were licensed in such a way that they could be switched to the GPL or a GPL-compatible license, then Sun and now Oracle would probably be out of compliance with the terms they are bound by. My educated guess is that the files that have opted out of the update mechanism are the files that are in this situation.
It's also unlikely that Oracle would be the ones to sue Canonical - the CDDL license doesn't include any provisions that would give them the ability to sue. I'm sure they have copyrights on some parts of the Linux kernel, which they could potentially use to sue if they truly believe that they could win a case in court to show that OpenZFS is a derivative work of the kernel.
You're right, only 96% of the files and 99.5% of the code are.
> My educated guess is that the files that have opted out of the update mechanism are the files that are in this situation.
The files that have opted out contain very little in the way of interesting code, so I don't believe this to be true.
I don't think this can be accurate. Ownership of ZFS-related code is not tied to being the license steward - Oracle could theoretically pass off license steward duties to a third party without passing ZFS copyrights or obligations to the same third party. That third party could then change the terms of the CDDL without having any obligations towards those third parties.
In any case, it doesn't make sense - the CDDL is more permissive than GPL 2.0 other than its patent clause, and (as far as this discussion is concerned) the only relevant party covered by 6.2 is Oracle.
So, uh, citation strongly needed.
his/her contention is that most of the code has been released without the explicit opt-out for a more recent version of CDDL.
there's no need to get nasty; just bring the facts.
Actually no, it is not.
By allowing ZFS-derived works to be licensed under GPL, I suppose. I wonder if they could do it without allowing for a GPL fork which would become unmergable to the upstream?
Dunno, it's just a hypothetical question and speculation whether there are any sensible reasons for Oracle to maintain status quo.
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.
----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
The real issue is if anyone who can claim copyright to Linux kernel will sue Canonical. I don't think so.
It's whether someone who distributes the kernel module and the kernel together is obliged to distribute the module under GPL terms as described in the "part of a whole" paragraph:
« If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. »
(It seems pretty clear to me that the answer is "yes".)
Is it possible to glue a kernel module shim to something else under License A, glued to another shim under License B, etc until you have license compatibility with ZFS?
At the very least, this would seem to violate the very spirit of what the GPL intends.
I'm not sure where the legal line is going to get drawn, but clearly it's still fuzzy.
We each write something that passes as 'English' the language. Yet each of our brains has a different implementation of that interface. We do not copy each other even though we happen to be able to interact.
Eben Moglen from Software Freedom Law Center thinks its OK as long as the source is distributed and no proprietary changes is made.
https://www.softwarefreedom.org/resources/2016/linux-kernel-...
>In this specific sense, then, the conduct which falls outside the words of GPLv2 falls within the "equity of the license," or its "spirit." As all Western legal systems have known since Aristotle, literal interpretation of any legal material will sometimes produce unintended unjust results, which can and should be corrected by the invocation of "equity." This present issue is evidently an example in which the tension between literal and equitable interpretation is raised, and it is the consensus of the kernel copyright holders' intention which determines which mode of interpretation is to be employed.
Linus is one central figure among kernel copyright holders. When he has stated his interpretation and it seems that most other maintainers are not objecting either, kernel copyright holders' intention seems to be closer to the "equity of the license".
Clearly ZFS is not a derivative work of Linux and Linux is not a derivative work of ZFS. Only the glue code is in violation (because it derives from both).
To determine whether there is glue here that violates the GPL would require looking at the particulars. Said glue might be licensed under the GPL, and might export the sorts of interfaces that Illumos does, thus allowing the ZFS module to link without reference to either the glue or the kernel! Then how could such glue be said to violate the GPL? It couldn't! Nor could ZFS be said to be violating the GPL in that case.
I don't think you can avoid an escape hatch for the GPL in the kernel without disallowing dynamic loading or modifying the GPL to have harsher terms. But recall that the GPL, and/or much software distributed under the GPL, is designed to have escape hatches: so you can run proprietary software using standard interfaces, for example (i.e., user-land code is not required to be GPLed just because it runs on a GPLed kernel, though a kernel could require it, it's just that _Linux_ doesn't).
It seems here you can't have your cake and eat it too.
I'd like to see more legal argument, with citation to applicable precedent, on this conclusion. It necessarily, for functional reasons, makes some use of copyrighted kernel interfaces, but whether this use of functional elements makes it a legal derivative work is a question I've seen many people present cobflicting conclusions on, but never with much argument supporting the conclusion.
This then requires looking for a way in which the GPL prevents creating such adaptor modules. I don't see how it does. Perhaps it could if modified, but as it is I don't think it does. IANAL though.
In the kernel, functions which might be used by any modules are exported using EXPORT_SYMBOL. But if a module wants to use functions exported via EXPORT_SYMBOL_GPL, then the module has to use GPL.
This was brought up in a (very long) ML thread on LKML[1].
[1]: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...
But even if I _had_ said that, you're still not correct. In a contractual agreement, the legal document _itself_ is not what has the "power" in the agreement -- the agreement is what matters. To whit, contract law applies in cases where legal documents are not actually written down (you can even have implicit contractual obligations) and due to the requirement for "meeting of the minds" there can be cases where a contract doesn't have the power that it may claim it has. Of course, a legal document is a much more formalised agreement (and obviously they are a very useful tool to make sure that the precise agreement is laid out) but just because it's more formal doesn't implicitly mean that the document itself is somehow imbued with some mystical force to effect consequences.
I'm not a lawyer, but I have discussed this topic with lawyers in the past.
The release yesterday has some great new features: https://news.ycombinator.com/item?id=14864145
Why in the world would they do that, though? Oracle pretty clearly does not value community goodwill, nor do they gain anything by trying to go through the process of re-licensing ZFS.
I do know he's very never-get-lawyers about compliancy
Also found this old comment from awhile back: https://news.ycombinator.com/item?id=11176937
Those stories were unsubstianted FUD. Solaris is alive and kicking. I would know, because I am working on a particular component that will be part of the next version of Solaris.
It's great. I love it. I wish Solaris was still open sourced and the open source aspect of it better managed than it used to be in OpenSolaris days so that there wouldn't be any need of a fork but I like it.
> especially since most of the original Solaris talent left Oracle after the OpenSolaris fiasco in 2010 and went to work on illumos
A lot of people left indeed. But most people? Hmm...
Which, in short, is a violation of the GPL and/or the CDDL. Now, if you go and build your own modules and not distribute them (such as using DKMS to build from source via Debian's zfs-dkms and spl-dkms, which Ubuntu decided not to do as well), then it's fine. No violation here, and the linked article basically says this inside of a bunch of wiggle room just in case they ever need to say they didn't say that.
As a ZoL user on Debian, Ubuntu usage of ZFS is a bit irritating. ZFS is hands down the best file system out there, and Ubuntu fouling up things with their style of politics isn't okay.
Many years ago there was a disussion between a member of the Squeak Smalltalk community (an IP lawyer by day) and the FSF's Eben Moglen. Moglen's position was roughly along the lines that libraries that are not considered to be deeply linked while out on disk in separate files, become deeply linked when loaded into RAM (or maybe into the same process's virtual address space, or something), such that taking a memory image of such a combination of modules, and using it as a means of distribution would be sufficient to trigger the "viral" aspect of the GPL.
(Since Smalltalk systems tend to rely heavily upon memory images, this is why GPL code became distinctly unwelcome in most Smalltalk communities, presumably except for GNU Smalltalk.)
Please don't make statements of opinion as though they are verified fact.
On one hand you have claims like this, and on the other you have Ubuntu who have said they consulted with attorneys well-versed in open source matters who did not believe there was a violation here.
In the absence of litigation, or similar, especially considering the high profile of this issue, I'm inclined to go that way, rather than armchair lawyering here.
You cannot build a binary with CDDL code and distribute it as anything other than CDDL. Ubuntu is wrong and likewise you are wrong. Otherwise, riddle me this: What is the license of the ubuntu shipped kernel packages? Oracle says it's CDDL. Linus says it's the GPL. Which do you believe it is?
Thanks, anonymous internet attorney. This is not an appeal to authority, but when a corporation is willing to put out official communication stating that they have consulted with attorneys whose legal opinion is that there is no violation here, and who has a lot more to lose than you or I, I am inclined to give them the benefit of the doubt.
I like ZFS. I like Linux. I love the two together. I don't care about the niggling legal interpretations that they themselves agree have never even been tested by the courts.
If they really want to push this, bring it to the courts. Put up or shut up.
You may not, but a corporation may and probably will.
Who exactly would stand to gain from keeping ZFS out of Linux, and would be willing to spend a ton of money on legal fees to do this?
What makes you say that? It's a very common tactic to give people "enough rope to hang themselves", where you intentionally delay suing someone in the hopes that more people will infringe so you can settle for more money. This happened with the LZ4 patent trolls for example (where they were suing people for using GIF files, and they waited several years after their patent was filed before suing people).
Not to mention that copyright lasts _120 years_ at the moment. Unless you wait until 2125 until you redistribute ZoL, you cannot ever be sure that Oracle won't sue you.
> Who exactly would stand to gain from keeping ZFS out of Linux
Oracle. They were the main btrfs developers (and still are), and since they no longer have any of the old ZFS engineers they would (rather ironically) probably consider a viable ZFS-on-Linux distribution to affect their bottom-line.
anybody can download the two software packages and link them together. As long as you don't redistribute them, then you are completely compliant with both licenses.
as a result, the only discussion here is for distributors of the programs (such as canonical, debian, etc).
I guess I am asking if the GPL is compatible with itself under a different name? Because if it isn't that seems like an unfortunate feature.
Obviously you'd hope that if Oracle licensed it under a permissive license, the whole point of doing so was to enable third party usage and thus they won't be taking legal action against this kind of minor and technical infringement (if it actually is). However counting on Oracle the company to act in good faith might not be smart.