Because the CDDL (by design, as inherited from the MPL 1.x) is not compatible with the GPL, due to the fact that both try to enforce their own copyleft without allowing relicensing (i.e the MPL2 avoids this thanks to a annex clause that allows you to consider everything as covered by the GPL instead). You can't cover the ZFS modules with the GPL in the final agglomerated result (i.e. kernel + module), so it's not allowed technically by the kernel license (see the difference between the LGPL and the GPL for more info). In practice no one ever questioned this in court, so who knows what the final result would be.
FreeBSD uses a super weak permissive BSD license instead, so there is no conflict because it leaves whatever code you're trying to add to it alone, without trying to enforce any additional terms on it.
There is potential GPL violation. Nothing in ZFS violates BSD.
GPL violation is matter of opinion. For the opinion to be settled someone owning Linux copyright should sue Canonical and find out.
Canonical's did legal review and they have some big name open-source lawyers like Eben Moglen and Mishi Choudhary on their side https://www.softwarefreedom.org/resources/2016/linux-kernel-...
They see it as a non-issue. So much that Canonical provides legal cover for all paying customers.
>ZFS was intentionally made incompatible with the GPL via the "CDDL"
That was said by one lousy youtube comment without any explanation, Ubuntu has no problems with it...and i bet they have lawyers, i think it was in that vid:
It's also crazy, nearly no distro has a problem shipping ultra-proprietary software (firmware), but has a big discussion about CDDL, no one wants ZFS in the Kernel tree, imagine Linus has control over it and has no clue was ZFS even is:
> It's also crazy, nearly no distro has a problem shipping ultra-proprietary software (firmware), but has a big discussion about CDDL,
It's the difference between "mere aggregation" and "derived work". The kernel+ZFS can be considered a derived work from both, so it has to obey both licenses (GPL2 and CDDL) at the same time; on the other hand, the firmware is completely independent from the kernel, so the licenses (GPL2 and the proprietary license) apply separately to each component.
> Ubuntu has no problems with it...and i bet they have lawyers
On the other hand, Fedora has problems with it as a kernel module (but they do ship it as a ZFS FUSE module, see https://fedoraproject.org/wiki/ZFS), and they do have lawyers (Red Hat's lawyers review all the licenses for Fedora, and they consider the CDDL to be incompatible with the GPL: https://fedoraproject.org/wiki/Licensing:Main).
>You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.
>To reiterate, executable forms of CDDL source code can be under ANY license you want.
That means your compiled ZFS module package can even be under GPL2 or 3 or beerware ;)
> no one of those project is derived from each other, ZFS is a module (on all platforms i think)
Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.
> > You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice [...] does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.
> That means your compiled ZFS module package can even be under GPL2 or 3 or beerware
I trust the Red Hat lawyers on this matter more than someone who is not a lawyer (from that page: "While it's true that I am not a lawyer [...]"). And from what I understand (I'm also not a lawyer), that clause in the CDDL applies only to the compiled result; but the GPL requires that, if the compiled result is distributed as GPL, the corresponding source code also be available under the GPL. So you cannot distribute your compiled ZFS module package under GPL2 unless the corresponding source code can also be distributed under GPL2.
I have always been skeptical of the FSF dogma that dynamic linking of a module or shared library into a GPL program's address space propagates the GPL into that module. The choice of inter-module communication technique (dynamic linking, sockets, etc.) shouldn't have any bearing on licensing. Either components are independent or they're not. There's nothing magic that happens when you take an API that's intra-process and run it over a socket instead. If FUSE filesystems don't carry the GPL tag, neither should in-kernel modules logically decoupled from the kernel core.
You are right that the choice of inter-module communication technique does not have a bearing on the licensing unless the license explicit say so.
To be fair to FSF however, they have to my knowledge never actually said anything else. What they do say is that they will enforce the license at that distinction, a conclusion RMS arrived at many years ago when apple tried to make proprietary addons to GCC. The reasoning, as provided by a consulted lawyer Eben Moglen at the time, was that a judge would likely see it as creating a single derivative work out of the linked parts, and as such you need a copyright license. This story has been mention in a few talks because so far no one has yet to challenge FSF in court and prove it wrong, which is a fight that at least Eben Moglen have been all this years willing (and possible wanted) to take up if given the opportunity.
As a bright line in the sand the concept has served FSF well, but it is not a supreme court decision that defines what a derivative work is under software. It could be that the line should be drawn much more narrower, but personally my bet is the opposite. Courts are rarely on the side that want to abolish copyright control or limit its scope.
To make compiled ZFS module a derived work of Linux and ZFS, it would need to contain (ie include) parts of Linux source code, which is easily avoidable with a shim layer.
>Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.
Really? So if i compile something with gcc it is a derived work from gcc and gcc is derived work from my bin? Or when i make a firefox extension it's a derived work of firefox? Compile the nvidia module...a derived work from linux?
>I trust the Red Hat lawyers on this matter more than someone who is not a lawyer
But he can read :) but hey whatever, really not interested if linux has something good like DTrace ZFS or Crossbow, they like the NIH-Syndrome and i am ok with that too.
> So if i compile something with gcc it is a derived work from gcc
Yes. This is why the "libgcc exception" (https://www.gnu.org/licenses/gcc-exception-3.1.en.html) exists. The issue is that parts of runtime libraries which come with gcc are statically linked into the compiled executable; without that exception, the result would have to be under the GPL.
The same issue happens with Linux kernel modules. Many functions they need are only defined as macros or inline functions in the headers (since ZFS is a filesystem, just take a look at how many inline functions there are in include/linux/fs.h). And even outside of these, many functions are so closely coupled to the internal data structures of the kernel (and the data structures themselves are also exposed to modules) that any module using them could be considered a derived work of the kernel.
Are data structures copyrightable? The headers are not, and macros can be easily avoided.
And in any case, there's an easy way to prove something does not constitute a derived work: just show that it can work outside of the codebase it's allegedly a derived work of. The reason NVidia is safe is that they provide the same driver for FreeBSD.
Criteria for whether a work is copyrighted are a bit more nuanced and the word “header” doesn’t figure in it. A work needs to be original and have creativity element in it. Code in header files can - and very often does - meet that requirement. Some kind of code (whether in headers or elsewhere) can be unoriginal, but that really has nothing to do with “headers”.
In Nvidia’s case, they have an open-source shim layer in between the kernel and the closed-source bulk of the driver. In theory, the shim layer is a derived work of the kernel, but the closed-source part is not. I’d say that’s a bit of a dubious argument, but who knows? It’s never gone to court. Search for “GPL condom”.
So, ZFS would be in the exact same situation as the NVidia driver - shim layer would be derived work, and the CDDL code wouldn't. It is dubious, sure, but then the whole idea of GPL virality is.
It is however undisputable that Sun (and Oracle later) chose to write their own license for some of their opensource efforts, when there were very established alternatives already available. It's hard not to draw the conclusion that they made things awkward on purpose (i.e. to keep it away from Linux, the dominant OS in Solaris' market).
There's a very interesting talk on the matter by Bryan Cantrill where he explained that the gpl was unsuitable for their scope for a number of valid reasons, including the fact that the gpl vitality would have affected indipendent hardware vendors too, iirc. And some more cases.
I hope I didn't write bs, however here is the talk of you want to know more and with more details: https://youtu.be/Zpnncakrelk (leaping the chasm from proprietary to open: a survivor's guide)
As usual Bryan Cantrill is just brilliant at explaining stuff.
Edit: just to be explicit: it was NOT about keeping stuff out of Linux.
It's sad that even a brilliant person like Bryan can get opensource so horribly wrong at a fundamental level. Right at the beginning, he says F/OSS established itself because it leapt ahead technologically, not because "all that freedom / user rights stuff"; he totally fails to see how that "user rights stuff" is what allowed the jump to happen - because even developers are users when they first encounter a piece of software. Without the rights of users to read source, tweak it to their liking, and republish it, there is no right for developers to enable the technological leap. I hope Bryan simply chose a poor turn of phrase.
He makes another poor turn when he says that the CDDL kept stuff out of Linux, but "not because of the CDDL but because of perceptions of the GPL" (i.e. IHVs didn't want to deal with the GPL). The license and the choice of using it are two different things. Sun could have written a license that was not GPL (to satisfy IHVs) but was compatible with GPL. They did not. Danese Cooper, who was part of that effort, says this was on purpose, and stated it on record ( http://caesar.ftp.acc.umu.se/pub/debian-meetings/2006/debcon... from 27:30). I guess Bryan was one of those engineers Danese mentions as "having some biases" back then. It was certainly obvious, at the time, what a careful avoidance of a license compatible with the biggest Solaris competitor would have resulted in, from a practical and commercial standpoint.
In the same talk, Simon Phipps disagrees with her assessment and later said he was furious at her spiteful comment. Now, almost fifteen years later, nobody else had corroborated her claim despite there being no reason to protect Sun anymore.
I haven't seen people give any unkind judgment towards Danese Cooper for helping write the CDDL and stating it was done to block tools from Linux. And so many people already blame them for the incompatibility, it's hard to think a confirmation would make it worse for them.
I've seen a ton of flak thrown at Sun for the license, but Cooper's name only seems to come up as a source that it was intentional. I've never gotten the impression people blame her.
Of course I haven't read every discussion about it, but I have read quite a few. I think someone would have to both confirm that the incompatibility was intentional and argue it was the correct choice to to get much hate about it.
>Sun could have written a license that was not GPL (to satisfy IHVs) but was compatible with GPL
Why? Why even care about GPL? It's 100% compatible to MIT/BSD/ISC and that's enough, even Linus said that he probably would choose the ISC today, he chose mainly the GPL because GCC had it...and now they have GPLv3 (an absolute shit decision if you ask me).
(ISC is a troublesome license, but that's beyond the point)
Licenses are not adopted in a vacuum. The license is what made GCC what it was when Linus had to pick a license, and arguably what made Linux what it is today. A "BSD Linux" would have likely ended up the same way BSD systems have: a largely academic project routinely cannibalized by behemoth closed-source companies.
The question, yesterday and today, is really "why not care about the GPL?". The rights it grants are what made the F/OSS ecosystem what it is today. If you want to grant more rights to your users and developers, by all means use a less restrictive but compatible license like modified BSD, or MPL 2. It's easier to do that without fear of withering, now that opensource is the de-facto default choice in a lot of fields. It definitely was not as easy back in the '90s or early '00s, which is when the GPL effectively fought the war for the whole field.
If you choose to stick with pre-MPL2 derivatives, though, you are clearly not interested in granting users and developers the same basic rights as the GPL.
Look the problem is, you CAN make Linux as proprietary as you want if you DON'T redistribute it, like google, so google cannibalizes Linux too.
It's just a different vision, if you want real freedom and want to work with a community go with BSD/MIT.
>ended up the same way BSD systems have: a largely academic project routinely cannibalized by behemoth closed-source companies.
That's BS, just look at how Netflix and Dell EMC work with FreeBSD. And for example Juniper, they learned a lesson not working with the community and fell far behind because of that.
I am not going to argue beliefs, MIT/BSD and GPL are compatible. My point on cannibalization was in the historical context. Today the situation is different (thanks largely to what the GPL did in the past). And of course Linux is GPL2, not 3 - which would address some of the issues you raise.
All of these licenses would have avoided the problems we see with ZFS' adoption of CDDL or other MPL1 derivatives.
The historical context is that Linux had a proper community support at the time when everyone was looking for Unix on x86, to migrate off RISC workstations, and BSDs at the time were either a bunch of jerks, or had unclear status due to ATT vs UCB lawsuit. You could try to argue that licensing had played a role at this, but experience with other projects suggests otherwise.
You know what enabled that "proper community"? A license that provided a sort of moral compass, fostering collaboration and goodwill towards shared improvement, safe in the knowledge that efforts wouldn't be abused. Something that other licenses still fail to provide, to this day.
Even a cursory look at the open source ecosystem shows that GPL doesn't work like that. In fact, you can easily find examples that show the exact opposite: look what happened to MySQL, while Postgres continues to thrive. Look at GPL-licensed X11 implementations, or GPL web servers, or DNS servers (which are pretty much nowhere).
You cannot argue on one side that Linux's success was due to commercial happenstance, as you do in another comment, and on the other hand that Postgresql's success vs MySQL is entirely due to the license. In fact, before the Sun acquisition and following mismanagement, MySQL was the opensource rdbms, the M in LAMP. When opensource started to take off and the likes of Microsoft fired back hard with FUD and lawsuits, 3 out of 4 main tools in that stack were GPL and the other was GPL-compatible.
Obviously each project and field has a story; licensing and timing are both part of it.
I would also argue that we are eventually going to pay for the ecosystem refusal to adopt GPL3, which is effectively "closing" away the software at another layer.
I’m not saying the success of Postgres is entirely due to license; what I’m saying is the license is not a significant factor.
MySQL was always the more popular database, true. But it was also the one technically inferior, a PHP of databases.
As for GPL3 - on the contrary, the problem is the adoption of GPL3, which forced many parties to switch to non-GPL alternatives. But it also gave boost to Open Source alternatives, putting an end to the unhealthy monopoly of GNU toolchain.
> the problem is the adoption of GPL3, which forced many parties to switch to non-GPL alternatives.
Those are the same sort of businesses that, back in the '90s, would take BSD code and ship it without giving anything back. They were using GPL code only because they could respect the letter of the license while ignoring the spirit, thanks to coincidental technological changes (the move from PCs to server-based architectures). This problem keeps coming up and promotes a parasitic business model.
We'd be better served in the long run, as an ecosystem, by trying to find business models that work with GPL3.
Companies which don’t contribute - just sell code written by others - don’t mind GPL. GPL can be the problem for the rest, as it forces them to immediately donate all their changes to their competitors, who can then offer the same thing cheaper, since they don’t have to amortize the development costs.
I'm not sure those are good examples. MySQL lives on with a different name (MariaDB). X11 is currently being replaced by GPL implementations of Wayland, in the form of Kwin and Mutter.
As far as I know there were never any serious attempts at making GPLed alternatives to Apache httpd, nginx and BIND.
To make a license GPL-compatible, it needs to be a subset of GPL. Which means, to make ZFS GPL-compatible, Sun would need to ditch patent protection, among other things. That would create real problems for everyone, while not really helping ZFS on Linux - Linux devs would simply find another excuse; case in point is AdvFS.
I don't think AdvFS ever reached the level of community buy-in that ZFS has. A lot of people in Linux land really like ZFS, IMHO both demand and supply to sustain an in-kernel ZFS is there already.
> ditch patent protection [...] would create real problems for everyone
Are you arguing that users of MIT/BSD licensed software the world over are "at risk" of being sued by the copyright holder for patent infringement...? Big if true.
yes, so you're saying MIT/BSD licenses should be considered at risk of lawsuits for patent infringement (presumably from the same copyright holder that released the code in the first place)? If that were a realistic threat, most F/OSS projects should shut down tomorrow.
The patent-protection clauses of the CDDL are at odds with the spirit and practice of open licenses anyway, since they are voided as soon as the relevant code is modified.
So basically, the cddl ships clauses that are pointless and likely to be disregarded in practice and in court. Losing them would make no difference whatsoever.
Again, BSD/MIT is the same as GPL in that aspect. It’s not a problem for the open source projects themselves, as there’s no point in suing them. It can be a problem for high profile downstream users.
The CDDL clauses are not voided when the code is modified. Where did you get that idea? What you are saying is plain fantasy.
Maybe, some could say that the GPL2 is really awkward, but you have to know that Microsoft and Apple have their own opensource license too...big business is awkward.
> It's also crazy, nearly no distro has a problem shipping ultra-proprietary software (firmware), but has a big discussion about CDDL, no one wants ZFS in the Kernel tree
Jesus Christ you are absolutely right I hadn't seen the issue under that light.
> imagine Linus has control over it and has no clue was ZFS even is
I keep getting down voted, maybe I am too annoying for HN. But I'll risk it in the hopes this is helpful, in the social and psychological space.
First of all, I have been in awe of ZFS since... ever. But FS were not my curiosity, OS was, so I installed OpenSolaris and Illumos in VMs, a few times to get used to how these things install. No work, just play. That's me. I was sad Apple did not adopt ZFS, but they did develop a read-only something, kernel extension, I think, don't recall. And there is some support from the generous for OpenZFS on OS X (idk about macOS). Why not ZFS? Because it is different and complicated, and it takes dedication to learn. Had Apple adopted it as the native FS, I would have been forced to learn it, so that is why it made me sad. I need that kind of motivation. But many are this way to some extent. Everyone is industrious and everyone is lazy. When you can learn easily, you learn. When you must learn, you learn. When you get older, you just want to keep doing things the old way, the way you know how, and you can do that for 12+ hours a day and yet learn nothing new.
Linus is just a man. I'm glad the penguinistas have faded into the background, and I am happy for Linux, but fail to see that it was any better than NetBSD when the fanatics were vocal. Linux would have benefitted from not changing a lot of userland stuff that was changed from *NIX for no rational reason, but probably just for ignorance and arrogance. Just MHO. But now Linux is important. It just is what it is.
So Linus is insanely industrious, and also lazy just like most. How often does he learn something new, how often does he just work like a mad dog without learning anything new? Just a man, perhaps a very smart man, but no more. And he is imperfect. And I strongly suspect, by the public evidence of the tell-tale symptoms, he has an identifiable personality disorder, and it is the one that includes the symptom of an unwillingness or inability to recognize the problem. But IIRC, he did admit to things, and supposedly took time off to work on himself. But this can't be cured by the patient, though it, oddly enough, can be cured, one of the few mental illness than can be cured, not just maintained, but only after getting evaluated by a professional, and treated, and the treatment is easy, just sitting with the pro and talking twice a month for 45 minutes for up to two years. At least my understanding of it, it can be cured in two years or less depending on its severity, though rarely ever is. This is not criticism, it is compassion. Presidents get this. Captains of industry get this. Winning NFL quarterbacks get this. And it is not any surprise the Lord of the Linux kernel can get this. And I wish him the best.
We're all allowed to be incorrect and imperfect. But those that stand out get better, because they try. But as far as laziness is concerned, because I am lazy, too, and I believe most are, I can't fault anyone for being lazy and not learning new stuff, especially in order to have a better understanding of it to be able to say something about it that makes sense.
However, those that do change themselves for the better, those that are not lazy and learn new things, should be applauded, and given gratitude for the possibility that their example will be followed... hopefully by me, too.
I mean no harm. But I should have just let it hang. No one cares, and this was a technical discussion, not a touchy feely one, and no one wanted the explanation. I embrace the absurd, but I should do it quietly when the adults are talking.
