This post basically discusses Ubuntu's shipping of ZoL kernel modules, stock, inside of their initrd image, from what I can tell.
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.
The SFC article doesn't seem to me to be very clear on this point, but I wonder it has to do with shipping a memory image.
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.)
> Which, in short, is a violation of the GPL and/or the CDDL.
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.
"Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. "
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.
It's not one corporation, it's at least two. Joyent did basically the reverse thing. They took KVM, a Linux-derived GPL module and put it together with the CDDL illumos kernel. They lawyers analyzed this situation and vetted it okay.
Please add 2016 to the title. I thought this was going to be a new standpoint on this topic, with a new release yesterday.. I thought something had changed.
"""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.
Oracle 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.
I'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.
I 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.
The 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.
I'm going to repeat this again. It's got nothing to do with copyright assignment. The license that the code is under (CDDL), by default, allows Oracle to provide newer versions that anyone can update their copy of the code to.
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.
I have read it, but not all of the files are under the "later" clause. Its a small number right now, but it will probably increase. So Oracle cannot do the whole OpenZFS in one swoop.
The majority of OpenZFS hasn't exercised the opt-out (and most importantly, the portions that are from the original ZFS are definitely not exercising the opt-out). There are two possible options:
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.
They agreed to that when they released the code under CDDL without specifying that it was restricted to version 1.0. Look at how Wikipedia was relicensed from GFDL to CC-BY-SA for an example of this.
>Oracle does not own the the copyright to all of OpenZFS
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.
I would imagine the FreeBSD groups might object because it gives their project an edge over Linux. I can see if it went to a BSD license, but let's be real this is friggin Oracle. They won't do it because there is no actual advantage for them. Grateful developers are about their lowest priority. Maybe if it helped them win a contract that paid a lot of money they'd do it.
> I would imagine the FreeBSD groups might object because it gives their project an edge over Linux.
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've read it. That doesn't mean that all of the files are licensed with the any-or-later clause.
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.
> 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.
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.
there is a lot of self-confidence in your reply, but it doesn't address his/her point: that there is essentially a "loophole" that Oracle could exploit if they wanted to by writing a new version of the CDDL.
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.
CDDL requires you to opt out of later versions. 9 files (out of 219) totaling 950 lines (out of over 190,000) in the ZoL kernel code claim to be 1.0 only. What definition of "Almost all" are you using?
> Oracle could release a new version of CDDL that explicitly made the ZoL project GPL compatible.
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?
The problem would be similar to MIT or Apache licensing a project. It is very uncommon for someone to create a fork of an existing project _just_ to change the license. Most of the people working on OpenZFS are unlikely to just switch licenses, the net result would just be to allow dual-licensing under GPLv2 so you can use it in Linux.
People working on OpenZFS are unlikely to switch licenses, but somebody (presumably a company) could possibly develop an "improved" fork to make money on it and refuse to contribute back, at which point Oracle would be forced to switch to GPL if the fork takes off.
Dunno, it's just a hypothetical question and speculation whether there are any sensible reasons for Oracle to maintain status quo.
I 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.
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.
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.
The relevant question isn't whether a kernel module is a derived work of the kernel (which is what Linus is discussing there).
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".)
A Linux kernel module is a derived work of the kernel and under GPL. While ZFS may not be a derived work of Linux, you have to glue it to GPL code. And the GPL license is viral.
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.
And yet most of us wanted Google not to be held liable for infringing Java copyrights when they implemented the same APIs for Android. Theoretically one could use that reasoning to make an OS that's API-compatible with Linux but under a different license. They could then write a .ko for that other OS under that other license, and yet it would be compatible with Linux and non-infringing.
I'm not sure where the legal line is going to get drawn, but clearly it's still fuzzy.
You're misunderstanding the difference between an implementation of an interface and merely being compatible with an interface.
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.
Licenses, copyrights and trademarks have value only when there is actual change of someone getting sued. Who among the many Linux kernel copyright holders would oppose having ZFS module? Who would be willing to sue Canonical? Will Oracle object?
Eben Moglen from Software Freedom Law Center thinks its OK as long as the source is distributed and no proprietary changes is made.
>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".
Stupid question: can the glue code not be licensed under both GPL and CCDL?
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).
I'm not sure this is true. It's certainly possible to construct an API/ABI such that one could build the glue, or even dispense with it, without having to use any part of ZFS or the kernel to build the other or the glue. I'm not saying that's been done. But it could be done. Indeed, that's what FUSE is, for example, and that's what NDIS does, for another.
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.
The idea to use shims in order to evade the law seems extremely dubious to me. I just can't see a judge say "oh, nice trick there in evading the intention of the copyright authors. I will now rule in your favor".
> A Linux kernel module is a derived work of the kernel
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.
Imagine a kernel module which provides a bridge between an external (possibly standard, for some value of standard) API/ABI on one side, and the Linux kernel's internal interfaces on the other. Such a module might derive from the kernel depending on whether those internal interfaces can be copyrighted (and, do we want it to be the case that all interfaces can be copyrighted and licensed restrictively?! probably not), in which case it would have to be distributed under the terms of the GPL. But other modules using that external API/ABI certainly could not be said to be derived from the kernel, full stop.
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.
The thing is, it's actually not clear whether the intention here might actually harm the GPL. Effectively, programmers aren't lawyers so is marking something as EXPORT_SYMBOL_GPL considered to be a legal restriction? And does that actually imply that EXPORT_SYMBOL is not considered a derived work? The problem is that "derived work" is something that needs to be handled on a case-by-case basis -- if you had a module that scanned the kernel's address space to violate the EXPORT_SYMBOL_GPL restriction, would that module have to be under the GPL (the answer is yes IMO, even though it didn't use any EXPORT_SYMBOL_GPL APIs).
This was brought up in a (very long) ML thread on LKML[1].
the problem with that point is that certain open source Mobile OSes have been doing exactly that with the closed source SOC drivers found in most mobile handsets
If the module has no code from the Linux kernel, then how can it be said to derive from it? Well, some would say that a distribution that includes both is deriving one or the other from.. the other, since in the end both will be loaded in one "process". I think that's too much of a stretch, though ultimately that would have to be decided by the courts, naturally. Or maybe it's a strawman -- I really don't understand the arguments that Canonical is violating the GPL here.
No 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.
The 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.
That's not what I was saying, I was responding to a statement about documents "infecting" one another which is clearly incorrect.
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.
So the root of the incompatibility is essentially that even though both the GPL and Oracle open source licenses offer similar protections, they both are not allowed to be combined with other licenses.
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.
You can combine GPL-licensed code with code licensed under many other similar licenses without any trouble. This pairing is not viable because the terms of the two licenses are not mutually compatible.
What is Oracle's strategy for ZFS and Solaris other than continuing support for existing products ? There were quite a few stories about the imminent death of Solaris earlier this year. Wouldn't Oracle stand to benefit from an official ZoL product that they can sell with their linux product ?
> There were quite a few stories about the imminent death of Solaris earlier this year.
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.
Not to stir the pot, but what do you think of illumos (especially since most of the original Solaris talent left Oracle after the OpenSolaris fiasco in 2010 and went to work on illumos).
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...
> As such, we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license.
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.
They gain to sell ZoL themselves with their own RHEL derivative distro. And they get all the usual open-source community benefits. It may even become necessary for them to do so, perhaps not in the short term, for Solaris' long term future is uncertain, while Linux and ZoL continue to get better.
Kind of a strange request, too. CDDL predates GPLv3 by a few years. If they care so much about license proliferation, they should argue against GPLv3 too.
It's all free software but due to license proliferation, we have this mess. Hope somebody relicenses and everybody becomes happy. After all from what I hear ZFS is a great file system for recovering backups and better than ext4. And the BSD guys are using it all the time.
OMG this is ridiculous. If you want to be a zealot, go ahead, but nobody will like you.
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.
> 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.
You may not, but a corporation may and probably will.
Which one will? You can't bring a lawsuit unless you have standing. Does Oracle want to sue? I kinda doubt it: if they did, they would have done so by now. Is the Linux Foundation going to sue? Why would they?
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?
> Does Oracle want to sue? I kinda doubt it: if they did, they would have done so by now.
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).
And even then all Canonical needs to do is include a utility to allow you to pull down the ZFS binaries. They did something similar for the old AMD Radeon drivers years ago.
If the obvious public good was something anyone cared about, proprietary software would not exist at all. We have license protections in our free software, and those must be respected for the license to be of any value. Zealot is a very rude way to say "People with respect for the authors' intentions".
This is not a new argument or discussion. The Conservancy, and GNU (especially Eben Moglen, who tends to get deferred to on interpretations of the GPL, for a variety of good reasons) believe the distribution of the drivers inside a binary memory image like initrd constitute a violation of the license(s). The only way to determine definitely if they are correct (I happen to think they are, but that's irrelevant) is if a copyright holder with standing decides to issue a desist and the thing carries on into court. My (also irrelevant) opinion is that if that were to occur Canonical would probably revert to Debian's solution of shipping ZFS as source-only rather than litigate it. As it currently stands, none of this seems likely to happen, so further conversation about it isn't really relevant or particularly useful.
Addendum: there is one relevant thing. If Canonical actually agree that they're violating the license(s) and are just doing it anyway, then there's probably some warranted discussion. But even that is more an issue for the community than one for IP law (unless Canonical is doing it precisely to force a definitive license interpretation. I see no evidence of this). If it's just a case that one set of people think it's a violation and Canonical disagreeing, then it's doesn't become an issue until someone with standing decides to make it one.
100 comments
[ 2.8 ms ] story [ 152 ms ] threadWhich, 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.
The release yesterday has some great new features: https://news.ycombinator.com/item?id=14864145
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.
[1]: https://news.ycombinator.com/item?id=14866179
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.
----8<----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.
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.
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...
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 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.