The harm that comes from ZFS not being GPL-compatible

August 7, 2016

One of the big issues with ZFS for Linux people is that it is licensed under the CDDL, not the GPL (v2 or otherwise). In the past, I may have sort of said that this wasn't a too big deal because, for instance, there would have been major practical obstacles to getting ZFS code into the kernel anyways. I take that back unreservedly; I was wrong. I have come to see ZFS's license as a real problem for the simple reason that ZFS's license keeps it from being bundled with most Linux distributions.

Now, what makes this happen (or not happen) is not the legal technicalities. Some people feel the CDDL is not actually incompatible with the kernel GPLv2 license, and Canonical certainly thinks there is a legal way around things (since they're doing it in Ubuntu 16.04). And as a practical matter, a Linux distribution would probably not get sued. But software licenses are social things too, and the social side is quite clear: quite a lot of people feel that the kernel's license and ZFS's license clash in a way that means you cannot and should not combine them. A move to do so anyways that's justified on legal technicalities is going to make a bunch of people angry (and has, with Ubuntu 16.04).

I have come to feel that this lack of bundled ZFS on Linux matters quite a bit because ZFS on Linux remains your only real choice for an advanced, checksum-based filesystem. Btrfs remains not a viable alternative and when people are finding serious problems in btrfs's RAID 5/6 code, it's going to stay that way for a while. If ZFS was licensed in a way that was (socially) compatible with the kernel, I'm pretty convinced that a bunch of distributions would have already shipped ZFS on Linux in some form and a bunch of people would be using it and thus would have better-protected data.

(I don't think distributions would have integrated ZFS on Linux into their kernel source. But they could have shipped it as a separate package with precompiled kernel modules and so on, and the odds are higher that they would have supported it in the installer as an option for user filesystems.)

(I wrote about parts of this in an earlier entry, but back then I saw it from a somewhat different angle and I didn't consider the ZFS on Linux effort to be as well-proven and solid as I do now.)

Comments on this page:

... but on all relevant Linux distributions, you can install ZFS with a single command, no?

(Booting from ZFS, and directly installing on ZFS may not be supported out of the box, but it is on a few too.)

By cks at 2016-08-07 16:00:58:

I don't think you can on anything except Ubuntu, unless the command is some variant of 'curl somewhere | sh'. You certainly can't on Fedora (ZoL is not packaged in the main repository), and only Debian testing/unstable has the zfs-* packages in contrib. Arch seems to have the ZFS packages in a user-contributed section.

(On some or many distros it is a two-command installation, but then the first command is 'add some person's package repo'.)

Right now ZFS on Linux is not difficult to add to your system in general if you're actively interested. If ZoL was bundled with/by distros, my belief is that people beyond the actively interested would now be using ZFS filesystems, because it would be that more there, that more convenient, and that more visible.

By Greg A. Woods at 2016-08-10 19:50:33:

Strictly speaking that's a Linux kernel licensing problem, and to a lesser extent a GPL problem, not a ZFS problem.

In other words i don't agree that there's any real advantage in choosing a license that might lead to maximum availability in the in a specific set of OS distributions. Perhaps they would consider dual-licensing, but by this point there may be a quagmire of contributors to get approval from.

Indeed the ZFS benefactors may not even see Linux as an "important" enough market to worry about whether it's included by Linux distribution vendors or not (though obviously I can't speak for them). They may also see direct Linux support as preferable to indirect support via Linux vendors.

If the benefactor(s) of the Linux kernel really wanted its license to be compatible with the widest variety of add-on sub-systems then they would perhaps be the one(s) who might consider choosing the most license-friendly license. :-)

Written on 07 August 2016.
« Free software licenses are social things, not just legal ones
Why I like the sam editor »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 7 01:09:23 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.