Wandering Thoughts archives

The practicalities of non-GPL'd Linux kernel modules

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.org 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.)

A thought on feed readers versus the social web

It's become common for bloggers to announce their new entries by posting little announcements to places like Twitter and Facebook; the ultimate version of this is the Planet Sysadmin twitter feed. Even beyond how common this is, my vague Referer-watching here on WanderingThoughts suggests that readers actually use this.

(Although a certain amount of the hits are from robots; for some reason, harvesting URLs from Twitter streams seems popular.)

In fact, anecdotally a fair number of people have switched from feed readers to finding out about new posts through Twitter and Facebook updates. On the face of it this sounds vaguely crazy, which makes me think two uncomfortable thoughts about why people could be doing it (especially for something that's already an aggregated feed, like Planet Sysadmin).

First, it could be that most people don't actually want to read all of your entries most of the time. Instead, they prefer to skim over a short headline and click through only sometimes, if they're sufficiently interested. In theory this could be done in feed readers, but in practice most feed readers seem to put obstacles in your way for doing this sort of fast skimming, some of them subtle (for example, even having an 'unread' state for entries).

Second, it could be that people actively prefer the web browser experience (and haven't found web based feed readers to be compelling). I can sort of see this, especially in the modern world of heavily tab based browsing. I suspect that when you get down to it, few feed readers provide as good a user experience as opening a bunch of links in a bunch of tabs and then going through them; you get random browsing through them, you can pause your reading of one entry and go to another without losing your place, you probably have less space eaten up with administrative clutter, and the result may well be prettier.

(This leads to some thoughts on feed readers themselves, but that's another entry.)