The practicalities of non-GPL'd Linux kernel modules

June 14, 2010

A commotion has broken out on the ZFS mailing list; once again, someone has announced an open-source project to port the CDDL-licensed ZFS code to the Linux kernel, turning it into a kernel module. Predictably, a number of people are pointing out that this mixing of the CDDL and the GPLv2 is (probably) not legally viable, and equally predictably other people are both saying that it is and putting forth ways around the problem. But all the legal argument is missing the point; regardless of what the legal situation really is, in practice a non-GPL'd open-source Linux kernel module project is mostly useless.

The reasons are cultural (and rationally risk-based):

  • you'll never be included in the main kernel source. The main kernel source is GPL v2 only, period.

    (Since the Linux kernel has no stable kernel API, your project will be burdened with relatively constant effort to merge upstream API changes into your codebase.)

  • you'll basically never be included in strict distributions like Debian and Fedora.

  • you'll almost certainly not be included in more pragmatic distributions like Ubuntu and possibly Red Hat Enterprise, unless you provide some really compelling advantage.

    (While the situation of an open-source kernel module with a conflicting license is not quite the same as the situation with essentially closed-source graphics card drivers, ATI's and NVidia's closed source drivers are a much more compelling advantage than another filesystem and they're still very much on the outside.)

The practical effect is that a non-GPL'd kernel module will simply not be used by the vast majority of Linux users because it will not be included in their distribution (or won't be in the default setup, which is more or less the same thing). This is especially the case for things like filesystems that need significant extra work over just installing the module; now you need users who not just know about your module and where to find it (even if this is relatively easy) but care enough to do the extra work to use it.

(Graphics card drivers are not a comparable case because by and large they deliver benefits without users having to do anything beyond installing the software package (although configuration can give you even more benefits).)

The net result is that you wind up with an unimportant niche project that's used by almost no one.

(Many of these issues apply to all out-of-kernel kernel modules, regardless of their license. It's just that they especially apply to non-GPL'd kernel modules, because they are always going to be out-of-kernel modules.)

Sidebar: the risk to distributions

A Linux distribution that adopts any out of kernel module is taking on a practical risk, namely that the module will stop being kept up to date with the main kernel. If this happens, the distribution can either drop the module, annoying users who were using it, or start developing it itself; neither is an appetizing option.

This risk is especially acute for filesystems that want to be first class citizens in a distribution, with support for them at install time, users being encouraged to put real data on the filesystem, and so on. Dropping support for an uncommon feature is moderately painful to most people; making their data inaccessible or their system unbootable (or just not upgradeable) is really, really bad. It loses you users in a real hurry and causes incandescently angry people who will remember you very unkindly for years to come. As a result, you are effectively stuck with supporting the code, almost no matter how much work it takes.

(This can happen even to in-kernel filesystems, which is one reason that distributions are really conservative about what filesystems they consider first class citizens. Look at what happened with SuSE and ReiserFS 3, where my impression is that SuSE was basically forced to take over supporting the filesystem because the main developers first lost interest in favour of ReiserFS 4 and then evaporated.)

Comments on this page:

From at 2010-06-15 11:42:09:

There are several highly successful out of kernel "modules"... DRBD comes to mind (though I think it was finally allowed to merge recently). There does need to be a compelling advantage for something to live for so long outside the kernel tree, but in this case, I think the ZFS filesystem might be exactly that. Especially since we know BTRFS is a few years off from approaching maturity.

The other thing that hopefully this effort will provide is inertia. Even if it fails to catch on, it might spawn off other efforts, or increase the push to tackle the legal issues surrounding getting ZFS into the kernel...

From at 2010-06-15 19:05:09:

This post nailed it. ZFS is most beneficial to companies running storage servers. These companies will only use supported modules and there isn't a chance Ubuntu and RHEL will include this ZFS module ever. So I think it's dead from the beginning for most people. Except the HPC shops that want to use Luster and will go through the trouble to realise some benefits... they are 0.0001% of the market though.

I wish Oracle would either change the ZFS license or make OpenSolaris a better open source project (one that welcomes people' contribution wholeheartedly).

By cks at 2010-12-31 02:02:39:


I actually disagree about storage-server companies and out of kernel ZFS modules. I wrote up my reasons in WhoCanUseNonGPLKernelModules.

Written on 14 June 2010.
« A thought on feed readers versus the social web
The problem of testing firewall rules changes »

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

Last modified: Mon Jun 14 17:24:50 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.