Leading items

Debian and Nexenta collide

When Sun Microsystems decided to release Solaris under the CDDL license, it did so with the knowledge that this code could not be combined with GPL-licensed code. That incompatibility was pretty much guaranteed to create some interesting conflicts at some time. That time appears to have arrived, thanks to the release of Nexenta, a Debian-based system built on top of the Solaris kernel and runtime libraries. How this conflict is resolved may set the tone for how the GPL and CDDL worlds intersect in the future.

The Nexenta developers got off to a bit of a bad start by announcing its existence while putting its entire web site behind a password gate. Once general access was allowed, developers discovered that binaries of their software were being distributed without the associated source. The Nexenta developers responded in a rather unhelpful manner:

Anybody who has hung around anywhere near the Debian community for any period of time will know immediately that this sort of answer is unlikely to go over well. Various developers responded with requests to delete the binaries immediately, and some even pondered the use of a DMCA takedown notice. The Nexenta developers appear to have taken the hint, and source availability has improved, though the occasional glitch still comes to light.

The hardest issue, however, remains unresolved. The Nexenta project uses, along with the Solaris kernel, a number of user-space libraries (including the core C library) from Solaris. These libraries, being licensed under the CDDL, are not compatible with GPL-licensed applications. But much of Nexenta's user space is GPL licensed, and is linked against Sun's libc. And, in particular, much of the management infrastructure which makes Nexenta a Debian-derived distribution is built this way.

Several Debian developers are claiming that distributing GPL-licensed applications linked to a CDDL libc constitutes copyright infringement and should be stopped. The Nexenta developers, instead, justify this distribution by citing the "system software" exemption in section 3 of the GPL:

This exemption has allowed the distribution of, for example, binaries of GPL applications for Solaris for many years. The Debian folks respond that this situation is different: since the libraries and the GPL applications are all part of the Nexenta distribution, the CDDL-licensed libc does, indeed, accompany the executable, and the exemption does not apply.

The Nexenta developers do not appear to entirely buy this argument. They have suggested, however, that Nexenta could be split into two pieces: the CDDL-licensed core, and the GPL-licensed applications. Once the core is installed, the applications could be brought in from a repository somewhere. The only problem there is that bringing in those applications requires the use of (GPL-licensed) tools like dpkg, which would thus have to be distributed with the core system. Getting past this little bootstrap issue could be a challenge.

Once again, Nexenta has not helped itself here: project developers have suggested that the Debian community might want to help them out by relicensing dpkg under CDDL-compatible terms. Suffice to say that this idea was not received enthusiastically. The idea of rewriting dpkg as a CDDL application has also been raised, though that raises some issues of its own.

A more plausible solution to this problem might be to get Sun to relicense its libraries in a GPL-compatible way. Nobody has asked Sun (publicly, at least) whether it would be willing to take this step, but, once again, Sun was certainly aware of the consequences of its licensing decisions when it made them. This situation could also be resolved by porting the GNU C library to the Solaris kernel and shipping it with Nexenta. This is evidently a big task, and the Nexenta developers (who seem to be fairly small in number) are not thrilled about taking it on.

The licensing issues are real, and need to be worked out. But many of the people involved in the debate appear to have lost track of the fact that the Nexenta project, while perhaps being occasionally arrogant and ignorant of how Debian does things, is trying to make a contribution to the free software world. It is a free software project. Anthony Towns has been almost the lone voice in calling for a higher degree of cooperation with Nexenta:

He also points out that Debian's hands have not always been 100% clean, and that there is more to gain by helping a project like this toward free-software purity than by threatening legal action against it. With luck, the community will hear this message. What Nexenta is doing is very much within the spirit of free software licensing; with patience and help, they should be able to get within the letter of those licenses as well.

Comments (84 posted)

On binary drivers and stable interfaces

There has recently been a surge of discussion, once again, on whether the Linux kernel should support closed-source drivers. The debate was driven, perhaps, by the suspicion (later put to rest) that OSDL was supporting the creation of a stable binary driver ABI for Linux. So perhaps the time has come to review the reasons why the kernel developers are opposed to closed-source drivers. Our apologies to all of you who have seen this before.

Support for binary-only drivers seems, on the surface, like it could be a good idea. Companies could provide Linux drivers for their hardware without exposing their "valuable intellectual property" to the world. Users would have a higher degree of assurance that their hardware would simply work. All of the current hardware hassles would go away, and everybody would be happy. What could be wrong with that?

One obvious problem is that, with a proprietary driver, a Linux system loses one of its best characteristics: independence from vendors. A user of a proprietary driver depends on the vendor for fixes and updates, but the vendor is under no obligation to provide them. Computing hardware has a notoriously short product life; if the vendor drops driver support when a product hits the end of its life, there is little that a user can do. If the vendor goes out of business, there will be no further support for the driver. If the vendor decides to start charging for driver updates, the user has little option but to pull out the wallet. If the driver has a bug which affects the stability of the system, only the vendor can fix it.

And history shows that proprietary drivers tend to have plenty of bugs. They are often written by developers with little time and even less expertise with the Linux kernel. The code does not go through any sort of peer review, so obvious problems will persist into the final product. And, since only the vendor can fix the driver, bugs can last for a long time.

Binary drivers are brittle. The kernel API can and does change; that aspect of the kernel is not going away. Freezing an API would limit the developers' ability to fix poor interfaces, improve how the kernel works, and remove cruft. So binary drivers will always be likely to break between kernel releases, and users will have to wait for the vendor to get around to catching up with the current API.

Linux kernel developers will not help users who have proprietary drivers loaded into their systems. That is not because the developers want to be petty and vengeful (well, perhaps one or two of them do); it is simply that the developers have no way to track down problems when closed-source code is running.

Even if a vendor offers top-quality drivers and support, it is unlikely that said vendor supports all of the architectures that run Linux. Freedom to run on something other than i386 is one of the great advantages of Linux; proprietary code takes that freedom away.

Finally, proprietary drivers may constitute copyright infringement. Certainly some developers feel that kernel modules are derived products of the kernel itself, and thus required to carry the kernel's (GPL) license. Whether the module interface constitutes a boundary which the GPL cannot cross can only, in the end, be determined by the courts. Until then, every proprietary driver carries with it a degree of legal uncertainty.

None of this is new; here's what Linus Torvalds said back in 1999:

The alternative to cold sweats is to stick with hardware which comes with free drivers. In most areas, finding such hardware is not a challenge. In the cases where it can be a problem (video adapters, some wireless network cards), the solution is not to weigh down the kernel with some sort of set-in-stone ABI. As Linux continues to grow in popularity - and proprietary drivers get harder to write and maintain - recalcitrant vendors should eventually come around. That's exactly what has tended to happen thus far.

Comments (37 posted)

A quick update on subscriber links

As we noted last week, the "subscriber link" feature is now active on the site. With these links, a subscriber can hand out "get in free" tickets to specific subscriber-only articles. To do so, you need only pull up the article (if you are reading it in the Weekly Edition, click on the "comments" link at the bottom to get there) and use the "send a link" option in the left column.

Initially the feature was only made available to "project leader" subscribers. Based on the feedback we have received (and the original plan, in any case), subscriber links are now available to all subscribers. We will continue to think of ways to make added features available to the higher-level subscribers, but this feature did not seem like the right one to use this way.

An unanticipated side benefit of this feature has already become clear. By looking at the list of outstanding subscriber links, we can quickly see which of our articles are considered sufficiently interesting to make links for. That is a level of feedback we didn't have before. For the curious, last week's winners were A study on free software in British schools and Sony, rootkits, and the escalation of the DRM war.

Finally, we'll note that readers coming in on a subscriber link may now be presented with a tasteful pitch for LWN subscriptions. Happily, our initial plans for a Flash-based, popup ad were abandoned after a few milliseconds worth of thought. Hopefully the use of subscriber links will eventually lead to more subscribers for LWN. Meanwhile, please enjoy the feature, and we thank you for helping us to design it.

Comments (7 posted)

Page editor: Jonathan Corbet
Next page: Security>>