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):
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:
* * *
Atom feeds are available; see the bottom of most pages.