GPL Violations Related to Combining ZFS and Linux
sfconservancy.org
sfconservancy.org
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)
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.
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.
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.
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.
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.
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 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.
How is that a strong case for ZFS?
The ZFS Linux kernel module is a port of the solaris version, and that one was written dependently on Linux. The developers knew about 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.
[1] https://www.law.cornell.edu/uscode/text/17/chapter-1 (read 101, 106, 117) [2] https://www.law.cornell.edu/uscode/text/17/117 [3] https://www.law.cornell.edu/uscode/text/17/101
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.
* 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.
[1] http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules....
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.
> 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).
There are even cases where copyright for code you write after leaving the company could be considered to belong to that company.
I might have chosen my words poorly.
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.
We are okay with it.
Although ZFS developers on all open source platforms are considered OpenZFS developers, I am explicitly listed on the wiki:
http://open-zfs.org/wiki/Contributors#Richard_Yao
I am also the #2 ZFSOnLinux contributor by commit count according to github's statistics and I have maintained that position for years:
https://github.com/zfsonlinux/zfs/graphs/contributors
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.
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.
I just consulted with another OpenZFS developer. All new files will be CDDL version 1.0 only. Consequently, this loophole is being closed.
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.
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.
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.
Hence CDDL, GPLv2 incompatible.
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.
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.
Certainly Oracle, Sun's legal successor, hasn't publicly complained.
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.
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.
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.
So, who knows.
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.
Are there really? Are there any who state so publicly? Or is this a purely theoretical concern?
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".
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".
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.
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.
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?
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.)
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.
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.
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.
I don't want to seem like I'm trying to dominate the conversation.
(In the meantime, please see my other comments.)
"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.
[0] - https://lists.debian.org/debian-devel-announce/2015/04/msg00...
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 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.
(Also, as another poster points out, it's possible that all OpenZFS copyright is already assigned to Oracle -- I have no particular knowledge)
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.
[0] - http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/diff/z...
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?
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.
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.
Here's a piece from the time quoting Eben Moglen on the topic: http://www.cnet.com/news/linux-to-gplv3-a-practical-matter-n...
(Unfortunately the original linked to article was on a site that no longer exists.) It's just one opinion of course. (And IANAL.)
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.
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)
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.
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:
http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...
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.
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.
See my other comment: https://news.ycombinator.com/edit?id=11177827
> 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.
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 is what the SFC did when it suggested that Oracle was unilaterally capable of changing the license of ZFSOnLinux.
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 the gripping hand it wouldn't actually solve anything because lawyers will continually argue that this case isn't covered by that precedent.
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.)
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)
From: https://sfconservancy.org/copyleft-compliance/
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...
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).
Not true at all. Most claims of GPL violation are very straightforward.
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.
Happily, we don't live in that world.
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
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.
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.
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.
> Let a court solve it once and for all please.
Edit: dwrensha posted a related comment (https://news.ycombinator.com/item?id=11176361) with a YouTube link of Bryan making the statement.
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.
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.
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.
If they actually wrote the wrong thing, then intent is irrelevant.
But if the meaning of a term is unclear, then you can clarify the meaning.
But my understanding after reading everything else is that the license is blatantly incompatible and there is no possible clarification that could fix it.
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.
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...
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.
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.
This is an article on the GPL with SUN
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."
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.
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).
This is entirely unlike VMWare, who really did make and ship their own butchered linux distro with big binary blobs planted right in the middle.
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.
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.)
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?
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.
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.
> 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.
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.
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.
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 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.
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)
> 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?
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.
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.
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?
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.
Thank you for your patience.
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.
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.
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.
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.
https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-lin...
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."
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).
See here for some details of the ridiculousness:
http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-B...
(Interestingly, they use XFS for /home)
This year alone, its managed to "fully compress" open files to 0 bytes about 2-3 times.
Why anyone uses it for / or at all right now is beyond me. I think Novell is nuts 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?
Edit: Wow, I just checked DistroWatch and they've been #4 for some time now...
- What's the difference between zfs and nvidia as binary blobs in the kernel? Either they are both incompatible on principle or they are not.
- If the file system just uses standard kernel file system APIs then isn't it LGPL rather than GPL as per the exported symbols?
- Given that relicencing either ZFS or Linux are prohibitively impractical what exactly is the point of assuming that may happen?
- Who exactly complained about this? AFAIK the software conservancy doesn't have code themselves in the two products
- If it goes to court the GPL may be harmed due to courts not understanding the difference between static and dynamic linking; who wins then?
It seems like the beginning of the mother of nobody wins, and very little upside in any case.
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.
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).
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?
Edit: I see that this has been done. Thanks. :)
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.
>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?
https://www.gnu.org/licenses/rms-why-gplv3.html seems to imply that that wouldn't work, but I don't understand why. Can someone with more experience with the GPLs enlighten me?
If he liked the GPLv3 he may have added the line back in, but he hasn't done so for the reason you mentioned.
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 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. :-)
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.
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.
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.
Deleted comment
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!"
0. https://opensource.stackexchange.com/questions/1774/why-does...
Is it a GPL violation to create a separate .deb which includes only the binary kernel module for zfs which can be simply apt-get'd?
Or are canonical planning on including the zfs code in the base 'kernel-blabla' package?
If the latter, why not just have a sep package for the module? I imagine you'll need to install some 'zfs' package to get the userland tools anyway ?
(Actually I think you just need the headers, but those are GPLv2 anyway, so the distinction is irrelevant.)
I'm not well enough traversed in the kernel source to find a direct reference but you see commits like this every now and then:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Having parts of the kernel LGPLed doesn't seem like an unusual or odd thing, from what I can tell:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
So of all of those, literally 1 is changing the licence to LGPL.
A better search is https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=%2..., which reveals 147 results in the code.
This is still tiny, given that the kernel is a ~20 million LOC codebase, so yes, I would call LGPL code in the kernel an unusual thing.
Does Linux allow for a file system to be invoked at run-time using a general-purpose interface? (If not, could one be added?)
If ZFS could be modified to use the general-purpose interface, people who wanted to use it could download it and install it.