He states: "having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen the argument that they clearly aren't derived."
He does continue to say that he believe it would be "hard to argue that any new driver or filesystem was developed without any thought of Linux", although in the specific case of ZFS (as opposed to, say, nvidia.ko), I think there would be a strong argument that the ZFS module was originally written in whole as a non-derived work.
(Obviously, Linus is not the only stakeholder here, and even his own opinion may have changed since then. Still, it's not a new conversation and the community hasn't been too ruffled by the status quo for the past 13 years)
For those of us that can read source code there are a couple of strong indications that the Linux copyright holders still believe that Linux kernel modules may not necessarily constitute derivative works:
1. Every Linux kernel module can tell the kernel what license regulates its use, using the MODULE_LICENSE() macro. The Linux kernel keeps track of which modules are under GPLv2 (and a few other compatible licenses). When a module under a presumably "proprietary" license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.)
2. There are two macros used to export Linux kernel symbols: EXPORT_SYMBOL and EXPORT_SYMBOL_GPL. The former will make the symbol available to all kernel modules, while the latter makes it available only to GPL-licensed kernel modules. The clear purpose and motivation is that a kernel module that needs access to a symbol exported with EXPORT_SYMBOL_GPL must be a derivative work, while a kernel module that only depends on symbols exported with EXPORT_SYMBOL is not necessarily a derivate work.
Also, IANAL, but from a purely legal perspective I think it would be difficult to get a court to agree that a user space program that talks to the Linux kernel through system calls is never a derivative work, while a kernel module (even one that accesses only symbols exported with EXPORT_SYMBOL) is always a derivative work. The system call versus dynamic loaded module distinction is simply not very relevant from a purely legal perspective.
What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one.
One work is the module, considered in isolation. Is that a derivative of the kernel? Possibly, but that's a reasonably high bar to clear. If it's not, distributing the module by itself can be done entirely without reference to the Linux kernel's license.
The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module.
> What this kind of analysis, which is very common, misses is this: there's potentially two "works" that need talking about here, not just one.
I agree this is only one side of the analysis (does zfs.ko fall under the Linux kernel GPLv2?), but that's also the only question that the OP can credibly address (because SFC is a copyright holder in Linux, not in ZFS).
> The other potential work though is the module-and-Linux-kernel (and possibly many other bits too), delivered as one combined work. Is that a separate work as per copyright law? If so, is that work a derivative (of both the kernel and the module)? This is a much lower bar, and means that the combined work can only be distributed in accordance with the licenses of both the kernel and the module.
That line of reasoning would upend pretty much all open source licensing as we know it. E.g., paragraph 9 of the OSI's Open Source Definition [1] clearly states that "The license must not place restrictions on other software that is distributed along with the licensed software." The fact that the OSI has accepted the GPLv2 [2] as an open source license implies that they (for one) do not agree.
There's clearly a continuum between two independent programs distributed on the same DVD through to a pre-linked static binary combining two pieces of code together.
I believe the OSI point is aiming towards the first part of that continuum (and of course the GPL itself specifically disclaims "mere aggregation"). The line here is somewhat fuzzy, but for example if you were selling NAS boxes based on linux-on-ZFS, it seems to me that it would be hard to explain that away as "mere aggregation", since the essential functionality of the product relies on both those parts working together.
SFC isn't a copyright holder of Linux. They are just giving their opinion.
Also, as far as combined work, the OSD is not talking about that, but what the GPL calls "mere aggregation". The GPL is quite clear that "mere aggregation" is not under the scope of the GPL, thus OSD consider the GPL to be open source. A module linked to Linux and distributed along with Linux, however, is no longer "mere aggregation", but distributed as a single work.
> license is loaded the kernel will mark itself as "tainted". (It could just as well refuse to load the module, but it doesn't.)
Why, because they used the word "tainted"? I kind of thought that always meant to be used a flag for "this user loaded some random binary in the kernel and now complains there is bug ". So developers look at the debug output and see "oh, well, it is tained, so, we won't waste time on this, you are on your own" kind of stuff. Which is reasonable.
As you said, if they didn't want it to work with non-GPL modules, they could have prevented loading. Unless you think they setup a honeypot of sorts -- "We'll trick them, then sue them!".
I kind of thought that always meant to be used a flag for "this user loaded some random binary in the kernel and now complains there is bug ". So developers look at the debug output and see "oh, well, it is tained, so, we won't waste time on this, you are on your own" kind of stuff. Which is reasonable.
I think it's useful to look at it as that if the kernel is flagged as tainted, it means it's in a state that can't be properly debugged, independent of the exact reason.
This could be because there's a opaque blob loaded that makes debugging difficult, if not impossible.
It could also be because the license of the code that was loaded (even if it isn't an opaque blob) means that even if someone did figure out the problem, they couldn't necessarily get their changes committed upstream (or might have a hard time of it) and then they'd have wasted that time debugging something that legally can't be debugged by anyone or anyone can't use the results of the debugging (the fix), which are freedoms the GPL is designed to protect. There's a lot of bugs to work on, and it's meaningful to consider code that is licensed in a way that is not strictly GPL compatible as lower priority than code that is GPL.
ZFS was designed and implemented by a team at Sun led by Jeff Bonwick, Bill Moore[106] and Matthew Ahrens. It was announced on September 14, 2004,[107] but development started in 2001.[108] Source code for ZFS was integrated into the main trunk of Solaris development on October 31, 2005[28] and released as part of build 27 of OpenSolaris on November 16, 2005
In 2003, Linus could not have known about ZFS without some insight knowledge, nor if the people developing it had any knowledge about linux. It also contradict the claim that CDDL was choose for the explicit purpose to prevent ZFS being used on Linux and competing with Solaris.
So:
"having been developed totally (not) independently of Linux: they literally were developed (after) Linux even existed, by people who had (full) knowledge of Linux. That tends to strengthen the argument that...?"
The developers knew of Linux but did not necessarily design with any intention of a port or plans in regard to the Linux VFS or kernel design. When it was a Solaris kernel feature, it was clearly not derived from Linux.
The modifications to make this driver to run on Linux caused a derivative work its original source (Solaris) and maybe of Linux itself. The 2003 thread implies that in such a case these modifications may not be derivative of Linux. That some kernel developers feel that the headers are factual and thus not copyrightable.
One could legally blackbox recreate the necessary header files and guarantee that their kernel module was not a derivative binary, so I believe that creating a proprietary kernel module should be legal in principal.
On the matter of linking, the FSF claims that dynamic linking can violate the license, but this is constituted under their understanding of a "derived work". Yet, the US code[1] clarifies that new copies and "adaptations" of a work do not constitute an infringement when created as an essential step in the utilization of the computer program[2]. The term "adaptation" is not defined but because this section is notwithstanding the author's "exclusive right... to prepare derivative works" implies that "adaptations" and "derivative works"[3] are not equal. This would strengthen a position stating that no derivative works are created by simply running, linking, or loading applications.
I think what's cute is the part where they point out why citing lawyer's (especially those employed by interested parties) opinions is not helpful because of the biases lawyers have to aggressively represent the interest of their parties, such that their opinions will generally reflect not the most likely correct view of the law but the view of the law most favorable to the interests of their clients -- and then, in the next paragraph, proceed to present their lawyers' opinion of the key and fundamental determining factor in the situation.
Which, of course -- as they've just telegraphed -- reflects SFConservancy's vested interests in a maximalist interpretation of what is a "derived work", since that is what maximizes the scope of works to which the necessity to adhere to a license (like the GPL) applies.
In the case of Linux, Linus has a public position [1] that:
* A kernel module is run by the kernel, not incorporated in it,
* A kernel module only uses LGPL interfaces, so full GPL compliance shouldn't be necessary,
* Binary modules should be legal (though he doesn't like them), and
* Projects (like filesystems developed for other platforms) with their own life outside of Linux shouldn't be required to re-license if they clearly weren't based on Linux.
I know Linus doesn't represent all kernel developers, but his opinion should carry a lot of weight.
The SFConservancy is just practicing GPL overreach here, and is rattling a saber in hopes that Oracle blinks. Ubuntu has been distributing NVidia binary kernel modules for years and this hasn't resulted in a lawsuit, so it seems like an empty threat.
> The SFConservancy is just practicing GPL overreach here, and is rattling a saber in hopes that Oracle blinks.
Why would Oracle care? Oracle is not involved in OpenZFS and has closed source all of their changes for a while. The new code (which is a lot) is not owned by Oracle. It is owned by the individual contributors as OpenZFS is not doing copyright assignments.
> > The SFConservancy is just practicing GPL overreach here, and is rattling a saber in hopes that Oracle blinks.
> Why would Oracle care? Oracle is not involved in OpenZFS and has closed source all of their changes for a while. The new code (which is a lot) is not owned by Oracle. It is owned by the individual contributors as OpenZFS is not doing copyright assignments.
That's not how copyright works, and we've all seen how zealous Oracle loves to get with copyright arguments (the Android thing, for example).
All ZFS contributions before the illumos split were assigned to Oracle because they had a CLA with all contributors. I'd still argue they definitely have copyright ownership (the current source is based on the original files, no doubt about it).
They don't own the current code, but all contributions are based on diffs on the original code. The contributors own their changes, but not the code as a whole. I don't believe that it's ever been tested in court how many incremental changes are enough to remove the original copyright owners' copyright claims. Especially when it comes to something like ZFS where there are data structures that were designed a long time ago and they must be kept (as well as the code for handling them) for backwards compatibility essentially indefinitely.
The issue isn't removing the original copyright holders claim. No one is saying that's possible. Oracle is free to relicense the code they own at any time, but that relicense doesn't affect the code written by others and Oracle does not have rights to that code unless they had a CLA. The new OpenZFS code is not under a CLA.
This probably doesn't affect the argument one way or the other, but in Germany, if some company employs you, and you write some code as part of your work for that company, AFAIK, copyright for that code automatically belongs to the company.
There are even cases where copyright for code you write after leaving the company could be considered to belong to that company.
The basic argument is that the OpenZFS folks have not been assigning their copyrights to Oracle after the Sun buyout and are not subject to what you have encountered in Germany (which I find just wrong, sorry for your troubles). Perhaps LGPL would be a better license for an OS (might be an interesting discussion).
I have not had any troubles with this legal situation. When I am employed at a company that pays me to write code for them, I have no problem with the company owning the copyright.
And none of my former employers have ever tried to claim copyright on any code I have written once I stopped working there. Actually, I do not know of any specific case where this has happened.
That's nice, but it's only one side. What about the opinion of the developers who wrote the module and licensed it under CDDL?
The incompatibility between CDDL and GPL is well-known, and the authors at Sun made it that way deliberately.
It's not kosher to just say, "Well the authors of the GPL software are okay with it, so it's fine." You need to respect the wishes of the developers who contributed the CDDL code to begin with.
If any of the other OpenZFS developers had a problem with Linux distributions shipping the OpenZFS code, I ought to have heard about that by now. So far, every OpenZFS developer on every other platform that I meet is happy that the code is available on Linux. I have even met employees at Oracle that are happy about it. While that is not an official stance of Oracle, Oracle itself publishes a dtrace module under the CDDL for use on Linux, so it would be strange to think that they would have a problem with shipping a port of the ZFS driver from the original OpenSolaris codebase under the original license for Linux, especially when it benefits Oracle Linux.
You're not one of the original copyright holders.. Oracle is one of the largest copyright holders. Maybe you should stop posting legal opinions when you clearly have your own bias?
I hold copyright on a significant enough amount of the Linux port that the license cannot easily change without my consent. The same is true for at least a dozen other people/organizations, if not a few dozen. You cannot say the same about yourself.
That being said, I am actively avoiding any statements that are repetitive with other comments that I have made on hacker news because they are not productive.
Someone emailed me to say that someone that Oracle might be able to change the terms of the CDDL for all software licensed under the CDDL as per sections 4.1 and 4.2. My discussions with lawyers thus far had focused on whether Oracle could change the license for just the OpenZFS code base (the answer is no) without any other copyright holders agreeing. Whether Oracle can change the definition of the CDDL for all software licensed under it (without the statement "version 1.0 only") is something that I need to run past a lawyer, but that might be possible.
I did not say it earlier, but this loophole would theoretically allow Oracle to publish a new version of the CDDL that is not open source at all and all software under the CDDL without a version peg would be avaliable under it.
I just consulted with another OpenZFS developer. All new files will be CDDL version 1.0 only. Consequently, this loophole is being closed.
The CDDL has a copyleft provision, similar to the MPL. One of the clauses states "The Modifications that You create or to which You contribute are governed by the terms of this License."
The CDDL is file-based, just like the MPL that it was forked from, and was specifically authored to allow mixing with proprietary code. The only thing that the part you quoted means is that changes to existing files must be available under CDDL terms (or freer).
In any case, the contributors who own the rights to the code they submit are free to make it available under any other license they want, whether it be MIT or something else.
Exactly, you don't own enough of the code to change the license nor do you have the power to just magically change the license texts to allow them to become compatible. We can't allow this one violation without allowing all.
You assume that there is a violation, but I do not know of anyone who owns copyright on any portion of the ZFSOnLinux codebase that thinks that is the case. Canonical does not believe it either. Someone will need to convince us that there is a violation in order for any of us to try doing anything about it.
Also, your account was clearly registered in order to reply exclusively to me. Would you care to provide your actual name in a way that can be verified? Otherwise, you are just wasting my time, which will not last much longer as my only replies are going to be for you to identify yourself.
> That's nice, but it's only one side. What about the opinion of the developers who wrote the module and licensed it under CDDL?
The developers' opinions don't matter. All contributors used to have to sign a CLA to give copyright to Sun. Then Sun was bought by Oracle. So you should care about what Oracle thinks about copyright infringement.
> The incompatibility between CDDL and GPL is well-known, and the authors at Sun made it that way deliberately.
No, that's bullshit. CDDL (which is just the MPL) is a file-based copyleft because that's what license fitted their requirements. It's not their fault that people have a completely fucked up interpretation of "derivative work" that includes any combination of two completely separately developed works.
Oh please, even the author of the CDDL license states that this is so (Danese Cooper).
And it's not as if that admission was ever needed, were you even around back then ?
Solaris was being killed in the market by Linux, Sun decided to go open source in an effort to better compete with Linux, but there was NO way that they would give away their prized technology (ZFS, DTrace) under a license which would allow their main competitor to whom they were losing, to integrate said technology.
> Oh please, even the author of the CDDL license states that this is so (Danese Cooper).
Wikipedia mentions several other authors. Maybe Wikipedia is wrong, but I am doubtful only one person wrote the CDDL.
> Solaris was being killed in the market by Linux, Sun decided to go open source in an effort to better compete with Linux, but there was NO way that they would give away their prized technology (ZFS, DTrace) under a license which would allow their main competitor to whom they were losing, to integrate said technology.
That is one telling of the story. Other Sun employees have different tellings. It's not as cut and dry as you claim.
CDDL is GPL incompatible in a very subtle way. The copyright of the CDDL licensed code isn't infringed, it's technically the copyright of the GPL code that's infringed. CDDL allows distribution of the binaries under a different license (provided the license doesn't restrict the users' rights, which the GPL doesn't), but the source files must always be under the same license. The GPL requires the source files for the "dervied work" be under the same license, which is where the incompatibility steps in.
I don't see how that's supposed to make sense. The developers/their employers retain copyright to their contributions—even those who signed the contributor agreement. (And it's dead, by the way. Nobody new is signing that agreement, and there's a backlog containing years of changes where the agreement doesn't apply.) So in a world where Oracle is making no indication of changing those terms, the developers' opinions do matter.
And I'm very specifically not just talking about the ZFS people here. This isn't "the ZFS license"; it's the CDDL. There's other software released under the CDDL.
> No, that's bullshit. CDDL (which is just the MPL) is a file-based copyleft because that's what license fitted their requirements. It's not their fault that people have a completely fucked up interpretation of "derivative work" that includes any combination of two completely separately developed works.
Again, this is completely incoherent to me. I recognize the words you're using, and I see that they're arranged in valid sentence structure, but I have no idea what point is supposed to lie in it or what it has to do with what I wrote.
And as I wrote to you before, the CDDL is not "just the MPL". Sun didn't just rename it and appoint themselves as license stewards when they forked the MPL. They made significant changes. They are not the same license.
> It's not their fault that people have a completely fucked up interpretation of "derivative work" that includes any combination of two completely separately developed works.
Indeed, "derivative work" is a well-understood term of art in Copyright law. So the courts will have to decide if that's truly what they will interpret, or will they take the redistribution & usage restrictions of the GPL as a separable matter.
The owners of CDDL-licensed code aren't complaining about a CDDL violation. It's only certain GPL advocates and licensors complaining of a GPL violation.
> The owners of CDDL-licensed code aren't complaining about a CDDL violation
That may be true for the authors of ZFS (and I don't know that it is, but we can agree to accept that it might be true). There are people, though, that when looking for a license to use when releasing their software specifically choose one that is known to be incompatible with the GPL. Among them are people who go with the CDDL.
Saying that we should ignore the license text and treat the CDDL as compatible affects more than just the authors of the project we're talking about.
And if the authors of the code in question are really okay with it being combined with the GPL, then at any time they can make that explicit offering it under a license that is widely accepted to be compatible.
Who are the only ones who have a legal interest in the manner in which the CDDL-licensed code at issue is used.
The fact that other people issue code with a license with the same text has no bearing on anything.
> Saying that we should ignore the license text and treat the CDDL as compatible affects more than just the authors of the project we're talking about.
No one is saying that, the argument is that this is not legally a derived work of the GPL-licensed work, so that neither the GPL nor compatibility between the CDDL and the GPL is relevant. No one involved has argued that the CDDL is, or should be treated as, compatible with the GPL.
The CDDL-licensed code is being distributed under the CDDL alone, not the GPL. That's the whole reason some people on the GPL side are complaining. I can't even see what people on the CDDL side would have to complain about under any interpretation of copyright law or either license that anyone has publicly made ever.
> There are people, though, that when looking for a license to use when releasing their software specifically choose one that is known to be incompatible with the GPL.
The issue at hand is not that the CDDL licensed software is being re-distributed under a GPL license. It's not. The issue is whether or not GPL software and CDDL software can interact in such a way as to violate the GPL license.
I doubt very much that "this can't be ported to a Linux kernel module" was a deciding factor when choosing the CDDL. If it was such an important factor, then they should have modified the CDDL to add such language to the license, which would make this issue much more clear.
I doubt very much that "this can't be ported to a Linux kernel module" was a deciding factor when choosing the CDDL.
The fly in that ointment is Danise Cooper's claim that they chose to base the CDDL on Mozilla's MPL 1.0 license in part for its GPL-incompatibility.
On the other hand, Sun's "Chief Open Source Officer", who introduced her at that talk as "the person who actually wrote the CDDL", later wrote she said that out of spite for losing the argument for licensing OpenSolaris as GPL.
Are you arguing that the licensing requirements of the CDDL are the problem here? To the best of my knowledge (though I am not a lawyer and this is not legal advice) that is not the case.
My understanding is that what Canonical is doing here is not a violation of any CDDL licensing terms, and the legal question is purely of whether or not it is a violation of GPL license terms.
> There are people, though, that when looking for a license to use when releasing their software specifically choose one that is known to be incompatible with the GPL. Among them are people who go with the CDDL.
Are there really? Are there any who state so publicly? Or is this a purely theoretical concern?
Good point. I don't think I've ever heard of CDDL ever being used except by Sun (and Oracle as Sun's successor), and people redistributing work (or derivatives of work) originally released by Sun/Oracle.
I would imagine that the decision to use CDDL by anyone other than Sun/Oracle is based almost completely on "its the only license under which Sun/Oracle will allow me to release this work".
You will find that most fans of the CDDL are bigger fans of BSD licensing (e.g. node.js is BSD licensed), but there are a couple examples.
Offhand, I know that star and cdrtools are under a variant of the CDDL called CDDL-Schily, which is the CDDL with an addendum that software under it is "governed by the laws of Germany".
star and cdrtools are developed by someone who really loves Solaris and wants to make Linux more like it. Relicensing then under CDDL is just part of it; cdrtools also use Solaris-style device names even under Linux and he got quite angry with distros for patching it to use Linux's native device naming.
> The incompatibility between CDDL and GPL is well-known, and the authors at Sun made it that way deliberately.
To clarify, by "authors" do you mean individual developers? Or do you mean Sun/Oracle as a corporation.
If you mean individuals, how often do you see individual developers working for multinational companies just wing it with a license choice? (If that is what you are implying). Your comment made it seem as if CDDL was a long and hard personal choice made by each developers, and somehow people here are wiling to discount that hard decision.
I worked for 2 big companies and in neither case had a much of a personal choice in picking licenses for the code. As in thinking "hmm, I think this code today will be MIT, maybe tomorrow I'll feel like Public Domain". It is usually the higher ups / company owners / legal department that decides what the license is and the company as an entity owns the code.
Point being ownership of the code is very concentrated with ZFS, and in this case concentrated in the hands of Oracle + a few outside developers and it is just a file system (albeit a cool one). So that is way of the quickest solution to the impasse is for Oracle to re-license the code.
Of course the other fly in the ointment here is that Oracle has some stake in BTRFS -- a competing filesystem. It was project sponsored by them initially and so I think besides being, well, you know Oracle, they could be interested in stiffing adoption of ZFS to avoid competition with their own project.
Well Danese Cooper, who wrote the thing, said she was deliberately made to author it to be incompatible.
I don't understand this line of reasoning, where somebody can say, "person A at Sun says it was intentional", then somebody else says, "person B at Sun says it wasn't intentional", and then acts as if that settles the matter.
All it means is that there's contention about it at best.
... and whether it was intentional or not doesn't affect what the text actually says.
The other reply [1] nails the real point: No one at Oracle is complaining. If they were, then one could care about their POV.
You also ignore the binary kernel object point: Nvidia's drivers are completely proprietary and closed source. How is that in any way less of a violation?
> If they were, then one could care about their POV.
Oracle isn't exactly known for their attempts at fostering good-will with the open source community. Considering that, I don't think they have much incentive to complain now, even if their lawyers are 100% sure that there is a violation of their copyright.
Instead they can just wait for Canonical to hang themselves, then sue them and their customers for the fair market value plus damages. (Maybe they'll offer Canonical's customers a good deal when they switch to Oracle Linux.)
I thought TFA argues releasing a binary combining code under GPL 2 and CDDL 1 violates both of those licenses.
But my point was: IF Oracle thinks their copyright is being violated, they wouldn't complain NOW. If they don't think so, they wouldn't complain either. So Oracle staying silent shouldn't be taken as a signal of their opinion on the matter.
I believe that had been the case for some time, but it will no longer be true with the next Ubuntu release. (that is why everyone is particularly concerned about the issue right now)
If you look at the .diff.gz associated with Xenial's kernel, linked from http://packages.ubuntu.com/xenial/linux-image-4.4.0-7-generi... you will see that this diff adds spl/ and zfs/ directories to the linux source tree. I believe, but don't know for certain because the "[list of files]" links are all broken at the time I write this message, that zfs.ko is in the same binary .deb package as the GPL'd kernel.
That's not to say that mere aggregation is enough to trigger the portions of the GPL that also require a derived work in the copyright sense, but the Conservancy post we started with lays out in detail their view: A particular zfs.ko does nothing until it is linked with a matching version of the Linux kernel; the fact that the linking is dynamic and not static is irrelevant in their analysis.
>The other reply [1] nails the real point: No one at Oracle is complaining.
Canonical hasn't shipped their distro with the ZFS kernel module yet. My impression of Oracle is that they let their lawsuits do the talking.
>You also ignore the binary kernel object point: Nvidia's drivers are completely proprietary and closed source. How is that in any way less of a violation?
AFAIK NVidia's drivers are not a default part of any distribution (including Ubuntu from Canonical) and has to be enabled/installed explicitly by the end user, meanwhile Canonical said they were going to make the ZFS kernel module part of their default distribution.
Yes, I'm sure that Sun's legal department went through the trouble of creating a brand new license, and never checked whether it was incompatible with the GPL... despite the fact that their biggest competitor in the market was GPL licensed. Because that interpretation makes sense and isn't at all laughably naive.
What I'm really curious to find out is who Ubuntu talked to - the original discussions of this had Canonical saying they consulted "industry's leading software freedom legal counsel".
"There are as many opinions as there are lawyers. You just have to find the one you need."
Apparently Debian got the ok from the Software Freedom Law Center[0], but they distribute it as source only, and the binary is built on the end user's computer (and they consider it then unredistributable). This is different than what Canonical is claiming to do which is to generate the binary themselves.
They're pretty clear about their own biases (e.g., they provide legal advice to Debian, they're involved with the VMware suit). But more importantly, they are pretty clear that they believe their lawyers' opinion to be the majority one among lawyers who have thought about this question: "Canonical has found some lawyers who disagree — a minority position, from our understanding of community norms."
in this context, Oracle could make everyone's life easier by waving their magic relicensing wand.
Well, so could the linux developers by relicensing to MIT. That's not much of an argument.
Additionally, I'd still love to see an actual court case with regards to the GPL here. Licensing is always murky, because almost none of it has been tested directly in the courts. Thus the only legal opinions we have are from people who have a vested interest in the outcome one way or another. Let a court solve it once and for all please. In particular, I'd love to have a 100% lock on whether a binary module that links to the kernel is actually a derivative work or not.
The "linux developers" aren't a single entity. You'd need a separate release from theoretically every copyright holder (or a really good legal argument for a subset that defines all the conflicting APIs).
The point here was practical, not moral. Linux, in practice, can't relicense the kernel. Oracle, in practice, can relicense ZFS. Thus the "magic wand" comment.
Does Oracle own the code for all of the existent OpenZFS code that Canonical imported? If not, then doesn't there exist the same issue that all of the developers would also need to relicense?
Arrgh. The same issue in principle, but not in practice. "All the developers" of OpenZFS are Oracle Corporation, plus a few dozen other folks we can grep from the commit log. And if they don't consent and Oracle does, surely the community can duplicate the effort quickly. In practice (that word again) all the meaningful copyright to ZFS sits inside Oracle headquarters. It's just not the same.
(Also, as another poster points out, it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge)
No need to "Arrgh.". I'm asking serious questions that seem relevant, in which I'm interesting in getting actual opinions.
And if they don't consent and Oracle does, surely the community can duplicate the effort quickly.
it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge
As a reference, the AUTHORS[0] file from the 'zfs on linux' project that was imported into ubuntu lists 73 authors not including the Oracle developers, which appear to be both individuals (gmail accounts, etc) and multiple individual businesses (nexenta, ovh, etc)
This still seems to fall in to the category of "It's must be easy for you, because I could totally do it in 2 hours" that developers (such as myself) sometimes fall into where a task is deemed 'easy' because the complexity is hidden. It really seems like neither could easily relicense, so there is no magic wand.
I wondered the same thing: if say the Linux kernel was to be re-licensed, how long would it take to get a hold of all the developers that ever contributed something to it? I'm sure some of them have by now passed away, so they'd have to get a hold of their next of kin?
Also, how does duplicating someone's patches work? If I contributed some really basic piece of code, say a very specific hash map implementation where there aren't really two useful ways of doing it, does another developer get to copy/paste bits of it into their code? What if they name the variables the same and structure the code similarly? What exactly distinguishes the original code and the new replacement if they look similar? The fact that someone else typed it in?
I wondered the same thing: if say the Linux kernel was to be re-licensed, how long would it take to get a hold of all the developers that ever contributed something to it? I'm sure some of them have by now passed away, so they'd have to get a hold of their next of kin?
This came up back when the GPLv3 was first being discussed. At the time, as best as I can recall, the consensus was that it would be effectively impossible. I'm pretty sure that it is, indeed, the case that some of the copyright holders have passed away, and I believe there are some that nobody knows how to contact, etc.
All this is, IIRC, a separate issue aside from Linus not wanting to re-license anyway.
If anyone is really especially interested in this particular point, dig around in the /. archives or maybe Groklaw from that era. That and the lkml, of course. There was a decent amount of discussion and gnashing of teeth over this whole issue back then.
IANAL, but as far as I understand it, the theory is that you commit copyright infringement if you copy, that is, you don't come up with the code by yourself (whether you type it or use a copying tool is irrelevant).
How the courts go about deciding whether you actually copied is tricky; it involves actual evidence (emails, testimonial, etc) and common sense, often in the form of expert opinions (you probably didn't just happen to write a 30 kLOC library that implements everything the same way, with just different variable names).
Now, there is a threshold of originality, that is, if there's only obvious way to write something, it shouldn't be infringing. But considering that rangeCheck() was considered to be infringing (see Oracle v. Google), I'm not sure we can depend on that. Then again, the guy did testify he actually copied it.
There's actually some ambiguity over what it would take to relicense Linux. This came up at the time of GPLv3. Torvalds didn't want to relicense it so the question was moot but there was some discussion.
Look, ZFS on linux is a comparatively small community project with a comparatively small number of developers as such things go. To argue that this requires significant hassle to relicense is... probably correct. If Oracle were to relicense ZFS under GPLv2, the community would have to do some work (in the worst case asymptote: they'd have to duplicate the work that's already been done).
To argue that this is somehow of equivalent complexity to relicensing the entire Linux kernel is... I dunno, I've used up my "arrgh" for this post.
Seriously, I don't understand what you're arguing here.
Seriously, I don't understand what you're arguing here.
I'll try to be a little clearer, but it's basically what I started with and ended with (which you actually appear to agree with)
1.) SFC says 'in this context, Oracle could make everyone's life easier by waving their magic relicensing wand'
2.) I say 'That's not much of an argument.'
3.) I say 'lists 73 authors not including the Oracle developers, which appear to be both individuals (gmail accounts, etc) and multiple individual businesses (nexenta, ovh, etc)'
4.) I say 'It really seems like neither could easily relicense, so there is no magic wand.'
In other words, there is no 'magic wand' because even if Oracle magically did there thing it would not fix the issue that FSC has with Canonical because the actual 'ZFS on Linux' code would still be licensed as CDDL. So it's 'not much of an argument' because it would be hard (if even possible) to get every ZoL contributor to relicense, and thus doesn't solve the problem.
To argue that this is somehow of equivalent complexity
You seem to be getting stuck on some issue of relicensing being equivalent. From a mathematical point of view, I'm sure you could assign some probability to both events (with Linux relicensing having a smaller chance), but it seems like for all intents and purposes, it's zero (even if Oracle relicensed). Do two events have to have equivalent complexity in order to be basically irrelevant as FSC argument? Seems to me like it's just FSC finger-pointing as rhetorical trick (and thus my pointing out it's lack of merit)
VLC re-licensed their project and they had 300 authors.
When people talked about the feasibility of re-license linux to gplv3 (as a thought experiment), people talked about several thousands of authors under the time period of almost 30 years. Several of them are dead.
But the discussion here also lack a significant detail; the target license for which ZFS would switch to. Commenters here on HN has said (unsourced) that the original developers has expressed an opinion that it all would be better if ZFS would be Apache licensed. That way it would be compatible with both GPLv2 and CDDL licensed contributions, and everyone would stop bugging ZFS about it.
In the CDDL, like the MPL that it was modeled after, forward compatibility is not opt-in—unlike the GPL, where you explicitly have to state that it's under any later version if you want to allow for that. (The CDDL does allow you restrict the code to a specific version, but you have to explicitly opt out.)
The CDDL is at 1.0. Sun (Oracle) is the license steward. If they publish CDDL 1.1 tomorrow, and it says you can use the software under the terms of the MIT License, then every CDDL project in existence that didn't explicitly opt out will be available under very permissive terms.
That's a whole lot easier than relicensing the kernel.
> because it would be hard (if even possible) to get every ZoL contributor to relicense
I think this is the fundamental point that 'ajross disagrees with.
First, they could dump the code and rewrite it. That solves the actual problem (getting a ZFS under GPL) without actually relicensing. If the code from non-Oracle owners is small, that's reasonable.
Second, they could ignore their copyrights. I believe this is legal in many jurisdictions where you have many of the copyright holders on board; in particular, for many small patches, they are too small to be copyrightable. (The FSF, for instance, doesn't require copyright assignment if your patch is under 15 lines or otherwise not "legally significant", like a mechanical find/replace.) That's why Conservancy can't file lawsuits with anyone in the entire `git log` of Linux who's contributed one or two patches once, but needs someone who wrote something at least somewhat substantial.
See also this VLC blog post and its discussion of French law:
Third, per that VLC blog post, it is empirically possible to get every contributor to a large project to relicense. And VLC's ownership is almost certainly more varied than ZFS's.
> Arrgh. The same issue in principle, but not in practice. "All the developers" of OpenZFS are Oracle Corporation, plus a few dozen other folks we can grep from the commit log.
That's just patently not true. All of the BSD and Illumos guys all are the main source of ZFS talent.
> (Also, as another poster points out, it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge)
No, that was how it worked before the OpenSolaris proprietarisation fiasco. Now, everyone retains the copyrights IIRC.
That part doesn't matter. Ownership of work done by SUN employees would have been transferred to SUN, then transferred to Oracle. Ownership of work done by Oracle employees would have been transferred to Oracle. It's only the non-SUN/Oracle bits that matter.
No. Despite what other replies to your post have said, several companies (and many individuals) have contributed large pieces to ZFS, and they still hold copyright.
Unless a project published under CDDL includes a conspicuous notice saying that no future versions published by Sun shall apply to the software, then the project is totally at the whim of Sun, who is allowed to relicense it under whichever terms it wants, at any time.
To treat this as Oracle's fault would be to reward Linux for sabotaging their own ability to relicense through a haphazard copyright policy and resulting murky ownership. It's not like some external force prevents Linux from relicensing. They've made their own bed.
> in this context, Oracle could make everyone's life easier by waving their magic relicensing wand.
SF Conservancy is stating that they have grounds and willingness -- though only as a "last resort" -- to tie Canonical, one of Oracle's competitors in the commercial Linux space -- with a lawsuit, but says that Oracle could make everyone's life easier by waving their magical relicensing wand.
Why on Earth would Oracle do that, though? I think the best-case scenario for Oracle here is that SF Conservancy and Canonical fail to resolve their dispute, the former sues the latter, much time and money on both sides is spent in litigation, and ultimately Canonical wins. But even Canonical losing doesn't really seem to hurt Oracle significantly (it may be bad for Linux generally, but even if that somehow hurt Oracle's own Linux business, it probably wouldn't do so significantly in the near term.)
The only wand I see Oracle as likely to wave is their popcorn-making wand.
> Well, so could the linux developers by relicensing to MIT.
The majority of the zfs sources are owned by Oracle, one entity. The linux kernel has many copyright owners and it would require the permission of nearly all of them to relicense the kernel. That makes it a different situation.
That might no longer be true. There has been an enormous amount of development since Oracle killed OpenSolaris, such that Oracle is unlikely to remain the majority copyright holder in the future and at some point, there will be no majority copyright holder. That might have already happened. So far, no one has checked.
And by your logic, also what Canonical did. Wee! Why are you still commenting with legal speculation? You realise your name is attached to it, and you are potentially liable for misleading people?
If I could go back in time and change what I have written, I would correct a few typos, but leave everything I said otherwise unchanged.
That being said, it is clear that your account was made for the sole purpose of replying to me. Would you care to put your name behind your comments in a manner that can be independently verified? I have trouble viewing those that do not distinguish themselves from anonymous trolls as anything but anonymous trolls.
On one hand a court decision would solve it once and for all on the other hand who the hell are we gonna find that A) is actually qualified to judge this sort of thing B) doesn't have a vested interest in one way or another.
On the gripping hand it wouldn't actually solve anything because lawyers will continually argue that this case isn't covered by that precedent.
> On one hand a court decision would solve it once and for all on the other hand who the hell are we gonna find that A) is actually qualified to judge this sort of thing
In the US, any federal judge in a court where venue is appropriate for whatever claim is filed. Apply the derived works rule in copyright law is certainly something they are qualified to do.
> B) doesn't have a vested interest in one way or another.
Same answer as above.
> On the gripping hand it wouldn't actually solve anything because lawyers will continually argue that this case isn't covered by that precedent.
While perhaps it will remain unsettled in a particularly strained binary sense in that someone, somewhere will be willing to argue against it -- in that sense, nothing is ever settled -- there is such a thing as fairly settled areas of law covered by fairly clear precedent where actors in the market generally do accept the existence of certain rules without challenging them, because the low probability of success in a challenge isn't worth the cost of challenging the rule. (Pretty much the only places where precedential decisions have only a weak effect on settling things is highly politically salient cases where opponents of the decision have a significant role on the judicial selection process, so a constant flow of cases seeking -- with some hope of success -- to overturn the existing rules are generated. But, even then, it usually requires actors with virtually unlimited supplies of other people's money (such as US states) on the side seeking to overturn the rules to keep up the flow; one place you see this is in the area of abortion rights. But I don't really see a major political party having a key constituency that is as concerned with any position on derived works rules as the "pro-life" movement is on restricting abortion.)
I think the hard part would be to find someone with standing to sue. Finding a court would be easy.
Who really has standing in this case? Maybe Oracle could sue Canonical? Or perhaps a kernel developer could sue Canonical? (although that seems unlikely to me)
One would assume that Canonical would be sued, and basically any individual kernel contributor (or someone like the SFC) could do it. I agree it's unlikely, which is why I hoped for a court case, because it's just another 'exception' to the rule otherwise.
In the very article here, the SF Conservancy claims both to have a legal basis to sue and willingness to do so, though the intention to do so only as a last resort.
In May 2012, Conservancy launched the GPL Compliance Project for Linux Developers, which handles compliance and enforcement activities on behalf of more than a dozen Linux copyright holders.
The GPL Compliance Project for Linux Developers is comprised of copyright holders in the kernel, Linux, who have contributed to Linux under its license, the GPLv2. These copyright holders have formally asked Conservancy to engage in compliance efforts for their copyrights in the Linux kernel. In addition, some developers have directly assigned their copyrights on Linux to Conservancy, so Conservancy also enforces the GPL on Linux via its own copyrights in Linux.
Although one wonders if copyright holders ever thought that they'd be suing a Linux company like Canonical...
This is a copyright issue just like any other. Thus the normal court system should be able to make a decision one way or the other. If the reality is that literally no one is capable of adjudicating this issue, then there is literally no teeth to the GPL since who could make a decision on it. I believe that's not really the case though.
And of course lawyers are always going to argue, that's literally their job after all. However, having some actual solid ground here would be helpful since "exceptions" abound, and it's basically "if we like you or we're forced to do because you have market power (nvidia), then it's totally cool". Land on the wrong side of that and you're getting bashed (again note the difference between Canonical distributing zfs vs nvidia's graphics binary).
>If the reality is that literally no one is capable of adjudicating this issue, then there is literally no teeth to the GPL since who could make a decision on it.
Not true at all. Most claims of GPL violation are very straightforward.
True, but we were not discussing general GPL violations.
But specifically the murkiness of the binary kernel module 'exceptions' (or if they are not actually derivative works in the first place, and thus not really 'exceptions', but rights). That's what 'this issue' refers to above.
But you claim that if "no one is capable of adjudicating this issue" then there are "literally no teeth to the GPL".
That is nonsense. Binary modules that may-or-may-not derive from open source programs are an edge case. The GPL can do many useful and powerful things without touching that edge case.
The other poster stated a partial argument that "who the hell are we gonna find that A) is actually qualified to judge this sort of thing". I then stated that IF literally no one was able to adjudicate it, then there would no teeth to the GPL (since anyone who wanted non-compliance would just binary kernel module everything). In other words, for the sake of argument, I was granting the other poster their position, and stating the outcome of that line of logic. Then I immediately disagreed with the base assumption saying "I believe that's not really the case though.".
Continuing the other poster's logical line (again, even though I disagree that a court could not settle the issue), if at some point a court came down and said, "Regardless of the text of the GPL itself, it is completely legal to link binary blobs against the linux kernel, and that linking does not create a derivative work", then the result of that line of reasoning would end in a weakening of the GPL because it would allow companies to 'lock away' the source code in direct opposition to the spirit of the GPL. Also note, that if the courts said something like "We cannot find any person in the entire world who is qualified to judge this issue", then it would have the same effect because abusers of the GPL would know that enforcement was not a possibility (thus the GPL losing it's teeth). I think it's hard to argue that if (in the counterfactual world where there was no one qualified to judge the violation) it would be possible to enforce copyright on the GPL.
I kept that "if" in my wording. I disagree with the line of logic. No matter what you think of the premise.
> (since anyone who wanted non-compliance would just binary kernel module everything)
Even if binary modules made you immune to the GPL, there are a lot of things the GPL would still do. It would not be toothless. On top of that, the issue here is binary modules that questionably derive from open source code. If you make a binary module that unambiguously derives from open source code, that would still be an easy question for the courts. That's why this is an edge case that remains an edge case, even in an alternate reality where the courts literally cannot decide on zfs.ko or nvidia.ko
I'm not sure what you mean by that. 'rhetorical device' is a very broad category. Can you explain if you think that's good or bad, and why?
dsp1234 made an argument that X, though not true, would lead to Y bad thing. I agree that X is not true, but object strongly to the idea that it would lead to Y.
Are you pointing out that the X->Y argument is only for effect, because X is false? I am aware of that, and I disagree with the effect, because I don't think X->Y is at all plausible. So I made a comment.
I agree that X is not true, but object strongly to the idea that it would lead to Y.
If the courts threw up their hands and said "It is literally impossible to adjudicate this issue of the binary kernel module", then who is left to enforce the copyright law? If a court said that, and an individual/company wanted to ignore the GPL, then they could put all of their code into binary modules. If a company's proprietary code is in a binary format, there is no one available to enforce licensing rules, and the company knows those two facts, then what reason does that company have to fear from the GPL?
Please provide an answer to both questions independently, so they are both addressed and no assumptions are left invisible. My answers are 'no one' and 'none'. I'd like to hear what you think the answers to those questions are, then I'd also be curious to hear what you think the logical outcome of the binary kernal module license issue being unenforceable would be.
> If the courts threw up their hands and said "It is literally impossible to adjudicate this issue of the binary kernel module", then who is left to enforce the copyright law?
The court would still be able to deal with the vast majority of copyright law, even if they decided that a specific license term was too vague to rule either way.
> If a court said that, and an individual/company wanted to ignore the GPL, then they could put all of their code into binary modules.
That's not true for two reasons. First, there are GPL violations that have nothing to do with binary modules, like a company embedding busybox and not distributing source code. Second, we are talking about binary modules where the question of "do they derive from the kernel" doesn't have a very clear answer. In most cases if a company tried to hide their code in a binary module, it would still blatantly derive. It would take a lot more engineering effort to get into the same gray zone as nvidio.ko and zfs.ko. Also note that right now, today, you can put in significant engineering effort to create a binary module that isn't affected by the GPL. All you have to do is make a non-GPL program that exposes the same API. But nobody goes through all this effort to skirt the GPL. So I doubt in this alternate world people would spend a similar amount of effort, at least not very often.
> If a company's proprietary code is in a binary format, there is no one available to enforce licensing rules, and the company knows those two facts, then what reason does that company have to fear from the GPL?
The courts would still in the general case enforce the rules, so they would fear legal action.
>I'd also be curious to hear what you think the logical outcome of the binary kernal module license issue being unenforceable would be.
The situation at hand is not one of all binary modules being GPL-proof. But even if they were, even if the GPL could do nothing at all about binary modules, it would still have uses. Anytime someone used a GPL module, you would be able to get source code. It would make the GPL act much like the LGPL.
These licenses are enforceable in hundreds of countries, courts set per-country legal precedence. There's no way a court can solve these issues once and for all.
It is my understanding that Sun's lawyers originally created the CDDL to be GPL-incompatible, with the specific desire that code under that license should not be able to aid their then-competitor, Linux. How Canonical can suddenly decide that Sun's lawyers were wrong about this, I don't know. I suspect wishful thinking.
I believe that Bryan Cantrill has stated that it was surprising to the people at Sun when outside parties didn't start incorporating ZFS and other technologies into Linux, because the original intention when the CDDL was written was not to be GPL-incompatible.
I'm going to go with the actual author of the licence (Danese), and not just because she authored it but because the idea that Sun management, seeing themselves struggle against Linux, would allow Linux to use their prized ZFS and DTrace, and thus offer even less reason to choose Solaris over Linux is simply insane from any kind of business point.
And not even now do we have anyone arguing here that CDDL is not GPL-incompatible, people accept that and Linus refuses to merge any CDDL code in to mainline, what is being discussed here is if ZFS counts as a derivative (and thus has to be GPL compatible) when it runs as a kernel module in Linux kernel space.
If that was the intent, is it not something that can be clarified and fix the problem? Or did they screw up too badly and it's unambiguously incompatible no matter what they say?
That is easy to disprove. If CDDL did not care, then one could follow the conditions in GPLv2 and the two licenses would be compatible.
License incompatibility can only occur if two license has conditions which are mutually exclusive. In this case, CDDL demands that source code must be distributed only under the terms of CDDL, and GPLv2 require that the distributed source code is made available under GPLv2. You can not comply with one without breaking the other, and thus we have license incompatibility.
> That is easy to disprove. If CDDL did not care, then one could follow the conditions in GPLv2 and the two licenses would be compatible.
The entire point of the CDDL is that it's module local. The only way to achieve GPL compatibility is to become the GPL. That would be impossible for the CDDL to do.
Yeah. If there's an unintended license-compatibility problem, the people who'd need to fix it are Oracle's lawyers. They might have a different attitude towards Open Source than Sun, to put it mildly.
Wouldn't a clarification of intent be based on evidence from the people that created the license? It doesn't matter what the lawyers think, they can't change history. You'd need the lawyers to relicense, a completely different way to solve the issue.
Why would Oracle spend any time correcting it? If you haven't figured out by now Oracle won't spend money on anything they don't think will make them money, I'm not sure what to tell you. And clarifying this doesn't seem like a path that would make them any amount of money.
I doubt that every single person that could clarify is employed by Oracle in 2016.
But my understanding after reading everything else is that the license is blatantly incompatible and there is no possible clarification that could fix it.
As a counterpoint, here's a 2011 video of Bryan Cantrill claiming that it is "emphatically not the case" that the CDDL was specifically developed to be GPL-incompatible: https://youtu.be/-zRN7XLCRhc?t=1375
It may not have been the "original intention" of the license, for whatever value of "original intention" that means, but it certainly was used for exactly this purpose - to keep the code out of Linux. Whether or not it was just a "happy accident" the CDDL was not GPL compatible, or whether it was engineered to be that way, I believe is mostly a moot point. (Though I'm still nowhere near believing Bryan Cantrill on this point. The executives and lawyers could have easily done this without the software developers involved ever knowing until after the fact.)
The GPL incompatibility was a well known fact before both of those tools were released, and it's frankly unbelievable this point wasn't raised internally at Sun before OpenSolaris walked out the door, given how much public discussion went into the license after it was first announced. The Sun executives knew exactly what they were doing when they chose that specific license for distributing D-Trace and ZFS.
I think all concerned (executives, lawyers, engineers) were simply trying to do the right thing by our source base, Sun's customers and the budding OpenSolaris community -- we really weren't trying to placate (or alienate) the Linux community, and didn't really factor in how the Linux community perceived its own license.
As for OpenSolaris, there were a couple of constraints with respect to the GPL: first, we didn't want to dual license (i.e., GPL + something else), because that was a mess that could lead to a license-based fork -- something we definitely wanted to avoid. Second, there was great concern about simply using the GPL because of exactly the ambiguity that's highlighted here: in 2005, we had many independent hardware vendors that had entirely proprietary Solaris drivers -- it was important to us that those be allowed to stay proprietary. We all liked the BSD license, but we also liked the idea of a weak copyleft -- and in that regard, the license that best captured what we were after was the MPL, despite some (minor) issues too that needed to be cleaned up. In the end, this is what we did (the CDDL is really just a cleaned up MPL) -- but (to be clear, and for what feels like the millionth time) we did it because of what we were trying to do for our own software and community, not because we were somehow trying to punish Linux.
As I've said before, one of my most vivid memories of the whole process was immediately after we launched OpenSolaris, standing in the conference room where we had just hit the carriage return, chatting with Chris Nadan from Sun Legal. We were both wondering aloud how long it would take for DTrace to show up in Linux -- but not from the perspective of license compatibility: we both accepted as a given that Linux would either view the licenses as compatible enough or wouldn't care about any incompatibility (after all, this is years after NVIDIA's binary drivers). Our only discussion was how much members of the Linux community would care about DTrace and how difficult the port would be technically. I remember saying that "maybe it will be two months, and maybe as long as two years." Of course, it was only a month or so later that SystemTap emerged from Red Hat -- and it became clear that Not-Invented-Here Syndrome would prove to be a much stronger force than any technical desire to assimilate DTrace or ZFS into Linux...
The NIH syndrome by established Linux developers definitely slowed down Linux's adoption of these technologies. However, the inability of Sun's marketing to promulgate how awesome its technologies were to the next generation of developers slowed down adoption even further. In my case, information about how awesome ZFS is did not reach me until about 5 years ago (I started contributing to the Linux port soon afterward) while information about how awesome DTrace is did not reach me until about 2 or 3 years ago.
I was barely even aware that a company called Sun existed until about 8.5 years ago when I was given access to a shell account on Solaris 9 at my university for a class on C at age 18. At the time, there was nothing to tell me that ZFS and DTrace even existed, much less how awesome they are. Back then, I had spent my entire life stuck in the desolate wasteland that is Windows computing with a tiny bit of LAMP sprinkled into my life that I had used to play webmaster of a Pokemon fan site between ages 10 and 15. Years later, I realized that I really disliked writing PHP.
Maybe things would have been different if Sun had tried fighting Microsoft for the PC market, but the knowledge that anything better out there existed just did not make it to me. I did not learn about Sun's technologies until I started actively looking for good technologies in their respective categories. I found out not long after my searches began, but it would have been nice had there been a bit more advertising.
These days, I cannot imagine going back to computing without ZFS and while I do not quite have DTrace available to me yet, when I finally do, I imagine that I will feel the same about DTrace too.
> It is my understanding that Sun's lawyers originally created the CDDL to be GPL-incompatible, with the specific desire that code under that license should not be able to aid their then-competitor, Linux.
Schwartz (or Sun under Schwartz) was not a fan of the GPL. As far as I remember they were hoping that Linux and OpenSolaris would together somehow migrate to an imaginary GPLv3 that never happened.
QUOTE: "Schwartz singled out the GPL provision that says source code may be mixed with other code only if the other code also is governed by the GPL. That provision is intended to create a body of software that must remain liberated from proprietary constraints. But Schwartz said that some people he's spoken to dislike it because it precludes them from using open-source software as a foundation for proprietary projects."
Exactly. They're arguing the combined work clause, which would automatically rule out all binary-only modules, such as nvidia.ko.
Most previous arguments about zfs.ko were about the derived work clause, which is much more grey. I belive that nvidia.ko would be more likely to be ruled a derived work than ZFS.ko, but that's hard to tell.
It does seem silly to argue about ZFS in this context. ZFS is open source and much less offensive to kernel developers than nvidia.ko.[1]
If nvidia.ko is fine, then so is zfs.ko. If nvidia.ko isn't fine, zfs.ko may or may not be fine. Ubuntu has been shipping nvidia.ko for years.
Of course the argument to be had here is OpenZFS lives completely independent of the Linux kernel, it runs on Illumos and FreeBSD and the availability of a Linux kernel module in no way makes or breaks the project. As such, is it a derived work since it is not dependent on the Linux kernel to exist?
This is the argument the Illumos developers make about including the GPL'ed KVM code, KVM does not depend on Illumos to exist, as such does loading the KVM module into an Illumos kernel constitute a derived work?
Conveniently, this is also precedent that could be set during the VMWare case the SFC is also perusing - we could either see ZFS relegated to being available anywhere but Linux and binary kernel modules totally banned (bad for nVidia, good for AMD), or a total change in the landscape of open source licensing (for better or worse).
Is that true? I thought Ubuntu's support for nvidia.ko involved downloading source code to the local machine and compiling it there, to avoid distributing a GPL violation.
Only binary distributions thereof. See the section called "Is The Analysis Different With Source-Only Distribution?":
Pure distribution of source with no binaries is undeniably different. When distributing source code and no binaries, requirements in those sections of GPLv2 and CDDLv1 that cover modification and/or binary (or “Executable”, as CDDLv1 calls it) distribution do not activate. Therefore, the analysis is simpler, and we find no specific clause in either license that prohibits source-only redistribution of Linux and ZFS, even on the same distribution media.
(Conservancy mentions the possibility of contributory/indirect infringement, though. Also, proprietary kernel modules written specifically for Linux, or using Linux-specific kernel features, may be GPL violations by virtue of their source code being a derivative work. But in the case of ZFS and several other cases such as OpenAFS and many hardware drivers, the source code is not a derivative work of Linux.)
> combine GPL'd software with some other software and distribute the resulting combination
I believe the key here is the distribution of the resulting combination. Were you to apply these patches after the distribution of Ubuntu, then would this still apply? Asked another way, if Ubuntu sets up a separate package channel that installs ZFS through a downstream patch via apt, would it be in violation of the license?
The GPL as a general case allows you to distribute separate works on the same media. Packaging shouldn't matter much, as far as I understand it either both ways of distributing zfs.ko are legal or both are illegal.
Yes, and I agree with Conservancy here. They are most certainly violations of the intended effect of the GPL, but it remains to be seen if courts agree.
I think at some point SF Conservancy feels they can poke Canonical with a legal stick, while doing the same with NVidia (a $5B company) could end up pretty costly and SF Conservancy being marginalized and criticized by the Linux community.
This article somehow implies a moral obligation on Oracle's behalf to either modify their licence or code to be gpl compliant. I sincerely hope they don't as the GPL brigade is getting louder in their intolerance of other licences.
> the GPL brigade is getting louder in their intolerance of other licences.
I really don't see much evidence of this, certainly not from the FSF/SFC, who specifically do not discourage use of free licenses that are GPL-compatible, such as the BSD and MIT licenses[0]. The anti-GPL crowd is much more vocal about their distaste for the GPL, especially on forums like HN.
The issue at hand is the use of a license which is not compatible with the GPL. No matter which way you slice it, that's a massive inconvenience to everyone, and pretty much nobody wins as a result.
(As for relicensing, it is literally impossible to change the license of Linux at this point, because the rights are held by thousands of contributors individually (some of whom are dead, and tracking copyright as it passes across estates is a notoriously difficult task[1]). If there's ever going to be a reconciliation between ZFS and Linux, it would require Oracle to relicense ZFS under any one of the many GPL-compatible licenses.)
[0] They do, incidentally, discourage the use of the terms "BSD license" and "MIT license", arguing that those are ambiguous and should be deprecated in favor of "3-clause BSD license" and "X11 license", respectively. But that has nothing to do with the discussion at hand, which is about the use of the actual licenses themselves and the terms they represent, not the names that people use to call them.
[1] Even figuring out if a given book can be reprinted is prohibitively difficult for publishers, and that's with works that only have one single author.
I think you got it backwards, the massive inconvenience for everyone is that Linux is using the GPL and people don't want to have to deal with all the re-licensing compatibility bullshit just to be able to distribute a binary of some other FOSS. seriously, CDDL is FSF/OSI approved.
Sure, Oracle could resolve it by switching to a GPL compatible license, but the problem is not oracle's clearly free software. The problem is GPL forcibly does not allow perfectly fine open source licensed software to be distributed in binary form due to it's copyleft.
GPL is "clearly free software" too, and FSF/OSI approved too. The problem is that the GPL and the CDDL both have no-further-restrictions clauses, as mentioned in the article:
> 6. …You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
> 3.4 … You may not offer or impose any terms on any Covered Software in Source Code form that alters or restricts the applicable version of this License
The situation would be exactly the same if, say, Linux were under the CDDL and ZFS were under the 4-clause BSD license, or the OpenSSL license, or Creative Commons, or the MPL 1.0, or whatever. The GPL and the CDDL both have exactly the same "problem" here.
If both licenses only had no-further-restrictions clauses, they would be perfectly fine. The issue is the imposing of further restrictions, which only the GPL has in this case.
And if no-further-restrictions clauses are evil and have to go, well, then the GPL's no-further-restriction clause has to go as well.
...as is the GPL, which is also written by the FSF. I'm not sure what point you're trying to make by saying this. Many FSF/OSI-approved licenses are not pairwise-compatible with each other. It's not limited to either the GPL or the CDDL.
> but the problem is not oracle's clearly free software.
The problem is as much Oracle as it is Linux. Especially since, as noted in other comments, the CDDL was created specifically to be incompatible with Linux's license.
> The problem is GPL forcibly does not allow perfectly fine open source licensed software to be distributed in binary form due to it's copyleft.
This isn't an accurate description either of the GPL or of the incompatibility at play here.
I agree, many of the open source licenses are not pairwise-compatible. But the fact that GPL is a strong copyleft license makes collaboration more difficult.
And the idea that CDDL was made specifically to be incompatible with GPL is at best a speculation.
See Bryan Cantrill's video about the history of Solaris [0] and about different licenses [1]
[0] https://www.youtube.com/watch?v=-zRN7XLCRhc
[1] https://www.youtube.com/watch?v=Pm8P4oCIY3g
> But the fact that GPL is a strong copyleft license makes collaboration more difficult.
The problem is that both the GPL and the CDDL prevent further restrictions to the license. This actually has very little to do with the copyleft; plenty of other licenses (including the CDDL) prevent further restrictions on redistribution, even without imposing a copyleft.
Only by a linear factor. Current OpenZFS is no longer the Sun released ZFSv28 code of old. Oracle does not have the copyright for these important, non-trivial parts.
If the point of the SFC is that those 10 years of non-Oracle/SUN development can be ignored, than on the same basis all the extensions to Linus' code can be ignored as well and he can simply relicense. But that is not something they want to argue, since they rely on ownership transference of some of those parts.
I read the article as "Despite the SF Conservancy grasping for any money at all to merely keep the lights on, we're going to waste time pursuing a licensing issue which boils down to "distribute the binary, not okay; distribute the source + tell user to 'make', okay". The essence of these two positions is pretty subtle, and not something that I think a running-on-fumes organisation should be pursuing.
I started donating to them last month; this article makes me wonder if I should retract that. What Canonical is doing isn't really violating the spirit of the distribution of ZFS - fundamentally, what is the difference between 'binary' and 'source + make' in this context? It's still intended to be shared. The article is a legal opinion, it took a fair amount of time to write, and talks about a lot of communication with other parties.
> "distribute the binary, not okay; distribute the source + tell user to 'make', okay"
That's literally what the GPL says. Look, I'm not a GPL zealot. The only thing even vaguely worth releasing, I've released 2-clause BSD.
But we can't just pick which bits of a license we feel good about and ignore the bits we don't - that doesn't exactly make a strong case for potential GPL violators to give a shit about copyright.
It's crappy behaviour from Canonical. I think there's another strategic motive here, they know they're stretching things a lot here but perhaps they see this as a catalyst to finally see some movement on ZFS licensing by various parties (or maybe they're acting on VMWare's behalf by sucking energy away from SC's VMWare case)
No, the essence of the GPL is about providing the source code. It's "you can't provide binaries without also providing source code", not "you can't do binaries".
> But we can't just pick which bits of a license...
Talk to people who work in legal aid agencies, and they'll tell you about triaging their limited resources; that they sometimes have to leave heartbreaking cases alone because other cases are more important. My point isn't about the technicalities of the case, it's about a group that is desperate for funds to merely 'keep the lights on' not triaging their limited resources appropriately.
On a tangent, I also wholeheartedly disagree with their contention that "almost there" is more painful than "absent". That is a piece of political bullshit (and I've recently ranted on progressives pissing on each other here https://news.ycombinator.com/item?id=11133321) and it smells to me more like they've got an axe to grind with Canonical and are looking for ammunition. It smells doubly that way because they give Debian a pass principally because they merely label the software 'contrib', and only secondarily because no binary is in contrib, only source.
Short form: The SFC wants to chase down GPL violators and has suboptimal funds. Would you prefer them to spend their resources chasing down the violations where the offender provides no source code, or the violations that can be sidestepped by typing 'make' into a terminal? Do you honestly believe that Oracle would be moved a single jot by Canonical putting up a wiki page that says "type make!" rather than provide the binary directly?
> It's "you can't provide binaries without also providing source code", not "you can't do binaries".
Edit: It's "without also providing source code under the terms of the GPL " - this is a nuance of the GPL's attempt at re-defining a term of art - "derived work". And yes, it deviates from Copyright law norms. Whether a court will consider only the meaning as understood traditionally, or whether they will simply treat the confusingly implied broader definition as a mere additional term of the license which must be enforced, I have no idea.
> Would you prefer them to spend their resources chasing down the violations where the offender provides no source code, or the violations that can be sidestepped by typing 'make' into a terminal?
Who says they're expending resources on Canonical? They've left NVidia alone, because they don't ship GPL'd software. They're spending on VMWare, because they ship a hacked Linux distro with proprietary blobs bolted on.
In the case of Canonical, they're letting them know they're trying to do LGPL things with a Linux that is actually GPL.
Edit2: GPLv2 says:
> Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you;
So distributing CDDL'd source and asking the user to do "make zfs.ko" is fine.
> rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
This, among other places in GPLv2 is where they have problems with binaries.
> Who says they're expending resources on Canonical?
Well, they say it, right there in the article: "Conservancy contacted Canonical to inform them of their GPL violation". And at the end of the article, when they say "Our lawyers, in conjunction with our GPL compliance and software forensics experts, have analyzed the Linux+ZFS that Canonical includes in their Ubuntu 16.04 prereleases". That's three kinds of experts, all doing "analysis".
And I say it above, when I talk about the article itself taking effort to write and the conversations it references also taking effort. These kinds of contacts aren't a one-sentence email fired off to 'hello@canonical.com'. They have to be thought out and worded correctly, and they engaged in a conversation afterwards. No, it's not like that email takes a week to write, but neither is it trivial; it's the result of thought, debate, and conversations.
> So distributing CDDL'd source and asking the user to do "make zfs.ko" is fine.
I really think you're missing my point. You keep speaking to the technical argument - I am not saying there is no merit in the technical argument. I want to reiterate (for the third time) that I think that this is far too small fry for a resource-starved group to chase after. Yes, there is a distinction here. No, it's not worth the time to chase, given other, more severe violations.
I am making a starved resources argument, not a technical merits argument. In the grand scheme in the world of violations of free software licenses, Canonical's violation (providing a binary and the source it came from, not just the source) is about as mild as you can get. The core spirit of the GPL (that the source code is freely available) is not compromised by the presence or absence of a build artifact.
I see your point more clearly now, I guess we still differ on priorities. Having such a key player within the open source community normalize GPL violation seems somewhat urgent to me - if the current level of interest from the conservancy is overkill, what level of engagement would you consider appropriate?
These things will keep. Come back to it later when they have more resources. Ubuntu was never going to pull it out of their impending 16.04 release, so there's nothing particularly time-locked here. Licensing issues can take years to play out and resolve - and indeed in this case, legal opinion is mixed on the matter in the first place.
Put it another way: The Conservancy spends all this time and effort and eventually convinces Ubuntu's lawyers to convince Ubuntu's product manager to drop the binary and write a "use make!" wiki page. Apart from idealistic purity, what has that effort actually done? Has it given us access to source code we don't already have?
Has it shown potential wrongdoers that the law is going to penalise them if they don't play ball? Has it fostered the sense of community underlying the GPL? Will anyone outside of those techies who discuss licensing for fun even notice? If they theoretically did notice, would they be more likely to use GPL software (the underlying aim of GNU and the conservancy) or less likely, as now it seems you will get in trouble for merely associating non-GPL software with GPL software? Will the Conservancy chase after Debian next, for including binary-only non-GPL firmware blobs in their distro (not even the source available)? Conservancy says that Canonical is normalising GPL violation, but on the other hand, it also says that it's a really weird violation, unlike any other - how does a future violator theoretically leverage that?
The conservancy's current level of input to the debate is appropriate. They're clearly not expending resources they don't have for this discussion. Also, they spent years with VMWare before it finally began legal action. What we have now is a discussion.
It sounds as if you don't think there should be discussion at all. "These licenses are incompatible but screw it, ship it anyway" is shitty behavior we expect from noname WiFi router OEMs.
> Apart from idealistic purity, what has that effort actually done? Has it given us access to source code we don't already have?
If we wanted a Linux that could be used like this, it'd be LGPL. That is exactly what the LGPL is for. Really. It's that simple.
I absolutely think people should think twice before blindly depending on or mashing up GPL software - at the moment they don't, and that's how we get these messes.
It's an important landmark in the history of the GPL and I find it completely weird that anyone would expect the conservancy to remain silent on it. In terms of their long-time resourcing problem, that's got nothing to do with this case and everything to do with VMWare pulling out all the stops to get their existing support pulled.
I rather suspect if the conservancy cared about their long-term survival and keeping everybody happy that much they simply wouldn't have pursued the VMWare case.
I've just read https://softwarefreedom.org/resources/2016/linux-kernel-cddl... - and whilst I still think the Conservancy is being reasonable, I can also see now how Canonical might have navigated itself toward its current position without being merely insane, malicious or self-serving.
This is the kind of thing that could hurt Linux in the long term. If Linux bans non-GPL kernel modules, what of the NVidia drivers? I think most of the GPU compute code out in the world runs on NVidia GPUs. If NVidia starts pushing a BSD distro as the distro for high performance GPU computing so it would not have to deal with type of hassle, it might really change things.
Also, this is coming on the heels of the big glibc vulnerability. BSD with its greater emphasis on security and less ideologicallyy driven licensing might start to look more interesting to large corporations.
More accurately, some people think it is a GPL violation.
There is no clear cut answer. You can get legal "opinions" either way.
My personal view is that it is NOT a GPL violation.
This is implied for reading the Linux source code, which explicitly allows for non GPL kernel modules.
So my understanding is that almost all mobile makers using Android are also in the violation of GPL, since they ship blobs to support their hardware. Right?
From what I see, this is just SFC trying to leverage Oracle to change it's licence manipulating public opinion because ZFS is something the "public" wants.
At this point, oracle can't wave their magic wand, as the SFC implies, and have the software be magically gpl-compatible. Since Oracle re-closed solaris, a lot of other entities have branched and forked and merged code into the openzfs codebase under the cddl. So you'd have to get in contact with all those entities to get it relicensed, unless you want to work on an ancient version of ZFS.
Not true. It doesn't matter who owns the copyright, because Sun has the keys to the kingdom and can publish a revision to the CDDL whenever they want. Forward compatibility is not something you opt-in to with the CDDL (unlike you have to do with the GPL).
This is, for example, how Mozilla has been relicensed to MPL 2.0 from earlier versions of the license—which the CDDL is based on, incidentally—even though there are no "any later version" notices anywhere in the headers or other files.
The amount of collective brainpower being burned on licensing issues for supposedly free (as in speech) software is astonishing.
I do symphatize with the sentiment that an author does not want his work to be a source of illicit gains for someone else, etc, neither do I, but at the same time find that the usefulness of a piece of code for other open source developers is (figuratively) inversely proportional to the length of the license, while the real abusers don't give a damn.
"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."
> Sun released the Z File System (ZFS) code under the Common Development and Distribution License, version 1 (CDDLv1) as part of OpenSolaris
ZFS isn't an acronym. It used to stand for Zettabyte File System (not Z File System as the article states), but like BP (formally British Petroleum), ZFS is no longer an acronym.
I wouldn't normally nitpick over something like this but that statement was the first sentence under the heading "The Basic Facts" and they didn't even get it's former name right.
"But zettabyte wasn't perfect, actually. We (we were a team by now) found that when you call it the zettabyte filesystem, you have to explain what a zettabyte is, and by then the elevator has reached the top floor and all people know is that you're doing large capacity. Which is true, but it's not the main point.
"So we finally decided to unpimp the name back to ZFS, which doesn't stand for anything. It's just a pseudo-acronym that vaguely suggests a way to store files that gets you a lot of points in Scrabble."
Mistake or not, I'm putting btrfs into production for a couple servers this year. All services (DNS, LDAP, NFS, DHCP) are running inside LXC containers, with btrfs as the backing store.
The idea is to be able to make snapshots of containers, and use btrfs send / receive to sync those with a backup container host. So if the primary fails, the services can be quickly and easily restarted on the backup container host.
So far, btrfs itself has been the main source of problems.
Out of perhaps unwarranted paranoia, I often configure servers with 3-disk RAID-1 for critical data, so two drives would have to fail before a service interruption or data loss. btrfs doesn't support this... their idea of RAID-1 means that two copies of data exist.
On a 3-drive btrfs RAID-1 array, if two drives fail, you are going to have problems. Rebalancing doesn't run automatically upon disk failure either. As a result, I've just gone back to a 2-drive btrfs RAID-1 config.
I've had a couple problem with sending / receiving snapshots. These were eventually resolved by back-porting the 4.4 btrfs-tools package. The version in Ubuntu 16.04 should be OK for my purposes, so I won't have to worry about that so much soon.
So btrfs may be OK for full production use in 2016, but significant problems exist for people using LTS distributions with older versions of the kernel code and user space tools.
But yeah, I'd like to see people just put effort into btrfs, and add the concept of a volume manager to it (like with mdadm when you create an array from /dev/sda1 and /dev/sdb1, it can be named /dev/md0 and you can refer to that as its own thing).
I'm using btrfs on ubuntu 15.10 right now and I can tell you from experience - it's unstable junk still. I have to manually rebalance my filesystem because it decides I'm out of free space and then that sometimes fails and things get even more complicated. This has really turned me off it.
The loss of data stored on the rootfs is more of an inconvenience (downtime) than something serious (permanent data loss). Consequently, the data stored elsewhere (e.g. /home) is far more important. If SUSE thought btrfs was stable enough, they would use btrfs for /home.
The last that I checked, SUSE used XFS for /home and others are saying the same here.
Given that you seem to have registered solely for the purpose of posting replies to me, would you care to say who you are in a manner that can be verified and provide citations, or do you just intend to troll?
The last time I wanted to use btrfs half the features I wanted from it weren't available unless I compiled a non-repo version myself. Needless to say I didn't bother. Possibly this has changed, but it won't be months or years until the choice comes up again for me.
If I understand the issue correctly, it's not ok to distribute a Linux with a zfs binary bundled, but it is ok to distribute a Linux with the zfs sources that builds the zfs binary at install time?
A rules-lawyering engineer might see one as a combined work and the other as separate works, but I highly doubt that any judge would find any difference between those two cases. IANAL.
The GPL makes an explicit distinction between source distribution and binary distribution. Are you saying a judge would reject that distinction? Would the judge find that simply having the source code to both the Linux kernel and ZFS on the same machine at the same time was a violation?
That's why I'm asking -- if building from source doesn't really change anything why then even consider a difference between sources and binaries in software licenses?
Copyright law is activated by the action of distribution -- you make something, you share it, copyright law checks whether you had permission to share it.
It's legal for someone to distribute you code under one license, and someone else to separately distribute you code under a different license -- it has to be. Once you combine them on your machine, you've created something that would no longer be legal were you to distribute it. But you don't plan to distribute it, and as long as you don't do so, you haven't violated any copyright licenses, because you didn't engage in any acts of distribution for copyright law to have power over.
But the distribution is on you, not the person who gave you the source. The thing they distributed wasn't violating any licenses.
I understand the reasoning, but I don't understand how the lines are drawn here (or how they could meaningfully be drawn).
Distributing two pieces of source code with different licenses is ok. Distributing them in a way that they can trivially be combined (e.g by compiling automatically on the receiving end during installation of the latest Ubuntu) can't be considered different from a distribution where the receiver takes more manual steps to combine them.
I'm curious why Canonical have to use binaries if they could easily just produce them on the clients machine and thereby not violate any copyrights? There has to be something else to it (or they just want to test the limits of the license conflict here, as a useful experiment).
I was not aware of the subtleties regarding the ZFS license.
Would it be possible (read: legal) for someone to modify the ZFS source to be more easily buildable into the Linux kernel, but then distribute it as source code only, such that an end user can build a ZFS-enabled Linux kernel on their own?
Surely as long as the end user didn't distribute the resulting kernel, that would be OK?
> Would it be possible (read: legal) for someone to modify the ZFS source to be more easily buildable into the Linux kernel, but then distribute it as source code only
Yes and that has been done. The ZFS on Linux[0] distributes a DKMS source package that each user of ZoL uses to build a binary kernel module. DKMS automatically builds the module without manual interaction from the user, similarly to installing a regular binary package.
This is legal but the resulting kernel/zfs module is non-redistributable.
Indeed, it's possible and even mostly-supported (at least on Gentoo) to compile the code into the kernel; i.e., not as a module. I have a zfs system without kmod support (reduces a huge attack surface and just seems cleaner).
>This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
So couldn't the FSF fix this by releasing a later version of the GPL that allows for this combination?
To be excruciatingly precise: That text is not part of the GPL itself. It is instead part of a standard small boilerplate text you are supposed to include in every code file; the text references the GPL “as published by the Free Software Foundation”, so the whole of the GPL is invoked, and the code file therefore then has a license. But the GPL itself does not have the “any later version” clause.
Linus removed that line from the kernel license because he disagreed with the tivoization clause in GPLv3, so the Linux kernel will forever remain GPLv2.
Linus removed that line before GPLv3 was created because he didn't want to give the FSF the ability to arbitrarily relicense his work to a license that he didn't have a chance to vet.
If he liked the GPLv3 he may have added the line back in, but he hasn't done so for the reason you mentioned.
> If he liked the GPLv3 he may have added the line back in
No, he couldn't have, because all the contributions received for the kernel were licensed GPLv2 without the "or later" clause, and cannot be relicensed to GPLv2 with the "or later" clause. Linux is GPLv2-only forever, essentially.
(It could relicense by stopping accepting contributions licensed without the "or later" clause, and either negotiating with all existing contributors to relicense or waiting for the copyrights to expire, but that's not likely to be practical. It certainly can't be relicensed on Linux or any other one actor's whim.)
The FSF couldn't arbitrarily relicense his work or the work of any of the other contributors to the Linux kernel that they don't hold the copyright to.
The GPLv3 had a long and comprehensive consultation phase. Linux contributors were involved in that.
And there's more than just dislike preventing relicensing - it would require contacting all the current Linux copyright holders and getting their agreement (or removing their code if they decline).
On balance I'd rather Linux remained GPLv2 than relicensed to Apache 2, so this is a good example of the definition of a compromise. :-)
That's exactly what happened to Samba. It was originally licensed with "GPLv2 or later", and now it's "GPLv3 or later". The main contributors to Samba were leading the switch, but they didn't get explicit permission from every single copyright holder, nor did they have to.
They didn't need to contact the contributors because of that "or later" clause. The license explicitly lets anyone relicense to GPLv3 without asking anybody first.
Linux's license doesn't have that clause, so you're not automatically allowed to relicense. Switching to GPLv3 would require the copyright holders to explicitly do so. Since Linux doesn't require contributors to assign copyright to some central organization, "the copyright holders" means all contributors, past and present.
https://www.youtube.com/watch?v=PaKIZ7gJlRU - he telegraphed GPLv3 many, many years in advance - just because it wasn't published until 2007 doesn't mean there wasn't talk about it for a long time before then.
It doesn't work to combine GPL code that way because both GPLv2 and GPLv3 would require the clause thus meaning a new "GPLv2" with that clause that isn't technically GPLv2. Heck I don't know their verbiage enough but they might not even be able to call it that.
However CDDL is not a strong copyleft, but a weak one, so would not require any update for the combination to work.
The real problem is that you would need a new hypothetical GPLv4 (since you wouldn't want to call it GPLv3 even if you could) that includes some verbiage that allows this and then get everything that is GPLv3 that you include to upgrade to this new version. That is a pretty tall order to allow a slightly different copyleft license to exist.
In theory a new GPL version that allows coexistence of licenses could exist but doing that without allowing perverse "copyleft" licenses or specifically calling out some set of copyleft licenses would be really difficult.
>The real problem is that you would need a new hypothetical GPLv4 (since you wouldn't want to call it GPLv3 even if you could) that includes some verbiage that allows this and then get everything that is GPLv3 that you include to upgrade to this new version.
GPLv3 has the same language, except with 3 instead of 2. So releasing v4 should allow both v2 and v3 programs to upgrade to v4 without anyone needing to do anything.
Yes it is. That sentence is not part of the license itself, but used in the text where you state what license (or what multiple licences) your program is released under.
I find it interesting that the SFConservancy argues 'Oracle has a magic wand to make this all go away' by re-licensing ZFS but completely ignores that just as much they could re-license the kernel under a CDDL compatible license. Given that Linux (in the broader sense) is asking for something it'd sound more reasonable for them to accomodate the other parties demands.
What they do is like saying "Hey I want to buy your house, what you don't want to sell it? How about you make it cheaper then so I can afford it!"
Um... If they really cared about making a quality product they would fix their existing problems, including their (apparently) poor choice of a license. Just because it is hard doesn't mean their shouldn't fix it.
It's not that it is hard, it is that there are literally thousands of contributors that have contributed code under a gplv2 license that would have to be hunted down and consulted about any license change. I'm sure if you're up for it they would be happy to have someone give it a shot so that if a re-license was needed in the future they could do it, but right now there is simply no way to legally re-license the code without spending thousands of hours getting people to sign little pieces of paper that could be used improving the kernel (zfs or no).
Right. So hard? Its a lot of work that is unplesant and nobody wants to do, I think that qualifies as "hard". I do agree its impractical, but it seems that for something as important as a function, working file system (and don't suggest that butterface fs is a production ready alternative) that somebody would put in the work to make it happen. After all the file system is everything, if you can't safely store your data, whats the point?
As an addition to the above, clearly ZFS is better than the common alternative: raid cards running some unknown firmware (that is most definitely open).
Why is Canonical bothering with the distribution of a binary ZFS module when building it via DKMS at install-time is already very simple (although, admittedly, time-consuming)? Their minimum system requirements, which gives the live environment plenty of resources to support compiling a kernel module, already weed out systems incapable of running ZFS. I just don't understand why Canonical's willing to take the risk of a successful copyright infringement suit involving the next Ubuntu release.
Because canonical wants to be the os of light weight vm images and docker images. You can't do that if the first step in distribution is always "boot into a separate filesystem, compile a kernel module, then reboot", and then if you want to distribute your image to anyone outside your organization, be sure to first remove that kernel module, and have them do the same process again.
The engineering problems are tractable even in those cases: Don't put the root file system on ZFS. Develop some kind of first-boot initrd that includes enough of a toolchain to build zfs.ko. I'm sure there are other, better ways to solve shipping ZFS in a virtual machine image, especially compared that to the legal and business risks of having a LTS release deemed a copyright infringement: Court costs, legal fees, fines, re-releasing Ubuntu, etc.
The single "zfs.ko" file that contains the ZFS kernel module is derived from both the ZFS sources and the Linux kernel sources, because you need the Linux kernel sources to link a module with the Linux kernel.
(Actually I think you just need the headers, but those are GPLv2 anyway, so the distinction is irrelevant.)
Of the 9 commits listed there, 2 are removing LGPL headers, 2 are adding LGPL headers to scripts which aren't linked into the kernel, 1 is relicensing a header file so it can be used outside the kernel, 1 is changing from linking against an external GPL3 library to an LGPL2 library without changing the licence of the tool that's in the kernel tree, 1 is an author noting that he's bringing in some external LGPL code which he wrote and is relicensing, 1 is a commit removing a driver and noting that an LGPLed userspace replacement exists, and 1 is noting an external LGPL userspace tool in the MAINTAINERS file.
So of all of those, literally 1 is changing the licence to LGPL.
Hmm. I suppose if you could show that the Linux kernel source files required to build zfs.ko were all LGPL, then distributing it as a binary module might actually be legal.
Yup. It's called FUSE and ZFS is available that way as well. The problem with running file systems in the user space is that they're generally really slow since you're chucking lots more data backwards and forwards between the user space and kernel space. So kernel drivers are much preferred in this instance.
So the only people that could sue based on this supposed GPL violation are the copyright holders of the Linux kernel, right? I doubt that they have the intention to do that.
Several copyright holders have assigned their copyright to SFC, so SFC can act on their behalf. There is also at least one copyright holder that is unhappy about Canonical distributing ZFS with the kernel:
perhaps people should've stopped messing about with ZFS a long time ago. it's always been known that licensing problems exist, yet people toil away as if they'll magically disappear - all they do is make Oracle product offerings stronger. if Oracle is happy to attack Google, they're sure as hell fine with the much smaller Canonical.
He states: "having been developed totally independently of Linux: they literally were developed before Linux even existed, by people who had zero knowledge of Linux. That tends to strengthen the argument that they clearly aren't derived."
He does continue to say that he believe it would be "hard to argue that any new driver or filesystem was developed without any thought of Linux", although in the specific case of ZFS (as opposed to, say, nvidia.ko), I think there would be a strong argument that the ZFS module was originally written in whole as a non-derived work.
(Obviously, Linus is not the only stakeholder here, and even his own opinion may have changed since then. Still, it's not a new conversation and the community hasn't been too ruffled by the status quo for the past 13 years)