Why ZFS's CDDL license matters for ZFS on Linux

May 16, 2013

In a G+ conversation about ZFS I read the following:

[...] so, why use BTRFS at all? :-) Just the fact that it's GPL (and so able to be embedded into the kernel source tree) doesn't seem enough, specially considering that CDDL (the ZFS license) is a bona fide open source license, [...]

On the whole I like ZFS on Linux, but let's not mince words here: this licensing issue is a big issue. Were btrfs and ZFS close to general parity, it would be a very strong push towards btrfs.

That ZFS is CDDL licensed means that it can never be included in the Linux kernel source. It may mean that it can't be prepackaged in binary form by distributions, or at least by distributions that care strongly about licensing issues. The CDDL is part of what makes it extremely unlikely that Red Hat Enterprise or Ubuntu LTS will ever officially support ZoL, making it always be a 'batteries not included, you get to integrate it' portion of the system.

That ZFS will not be included in the Linux kernel source (because of the CDDL among other reasons) means that you are more at risk of developers ceasing to update ZFS for newer kernels (among other less important effects).

(Being in the Linux kernel source is no guarantee that code will be maintained, but it increases the chances a fair bit.)

These are risks that we'd be willing and able to take on, so they aren't real obstacles for us using ZoL if that turns out to be the best option for new fileservers. But they still weigh on my mind and there are any number of places where they are going to be real issues, sometimes killer ones.

(I've written about this before.)

(Given the current situation with 4k disks, we're already looking at recreating pools when we move them to a new fileserver infrastructure. At that point we could just as easily migrate from ZFS to something else, if the something else was good enough. Btrfs currently does not qualify.)


Comments on this page:

From 77.188.176.183 at 2013-05-16 10:00:36:

Could you elaborate on the "btrfs does not qualify" part?

What's missing? How likely do you think this to change in the near future?

I'm currently using ext4 over md for smaller and MooseFS over ext4 for some larger setups. I've avoided ZoL mostly because of the maintenance issues and have been keeping a keen eye on btrfs. Btrfs currently runs my main machine's / and /home without incident and I might try a multi-disk setup on my personal server when I get new disks (overdue) and the raid6-equivalent is usable.

Somehow I have the feeling btrfs is in a continuous "almost ready" state now for quite some time.

By cks at 2013-05-17 11:20:28:

This is such a good question that I wrote an entry about it, BtrfsWhyNotYet.

(And yes, btrfs has been the great white hope of Linux filesystems for years now. I could only shake my head when I looked back at my entry on it from two years ago, because nothing has fundamentally changed.)

From 67.188.160.90 at 2013-05-17 13:58:14:

ZFS in Solaris/illumos is under usr/src/uts/common/fs/zfs. It's built as a separate module, which is loaded by the kernel. The code uses kernel resources via API calls, and vise versa (VFS). They can, and are, developed independently.

This notion that not having ZFS in the Linux kernel tree would be a "big issue" seems, to me (someone who has actually worked on the ZFS code), to be a fuss over nothing.

If at Sun, ZFS was in a separate repository to the rest of the kernel, then we'd have two cscope's open when developing code rather than one. It would not be a "big issue" - it would be a very minor issue.

For Linux, we can create an extra repository called "kernel-extra" for non-GPL code, which is the destination for projects such as ZFS, DTrace, and other drivers.

- Brendan

By cks at 2013-05-17 14:58:17:

The issues with ZFS being out of tree are not directly technical, they are cultural. Things happen and do not happen when your code is not actually in the main kernel source, and additional things happen when it is not merely out of tree but license-incompatible with the kernel.

(Note that the Linux kernel does not have a stable internal API for modules. It is fundamentally not designed to particularly enable independent out of tree modules in the way that, say, Solaris is.)

By cks at 2013-05-19 01:22:11:

I've now written an entry on the specific more or less technical effects of being an out of tree module (such as ZFS on Linux), TechnicalNonGPLKernelModules.

Written on 16 May 2013.
« Why I've so far been neglecting functional programming languages
Why I'm not considering btrfs for our future fileservers just yet »

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

Last modified: Thu May 16 01:16:45 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.