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:
Also some stuff not committed yet, beca[u]se we are testing them. In
2-3 months we are hoping to sort out all these "starting" issues
with code browsing, scripts availability, etc.
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
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:
However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source
or binary form) with the major components (compiler, kernel, and so
on) of the operating system on which the executable runs, unless
that component itself accompanies the executable.
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
I'm amazed at the level of intolerance that's greeting a pretty
major contribution to the free software community. There are, what,
five major OS/kernels for PCs/workstations these days -- Windows,
OS X, Solaris, BSD and Linux. How does it make any sense at all to
be hostile to the fact that now four out of those five are free at
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)
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
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
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:
Basically, I want people to know that when they use binary-only
modules, it's THEIR problem. I want people to know that in their
bones, and I want it shouted out from the rooftops. I want people
to wake up in a cold sweat every once in a while if they use
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
Comments (37 posted)
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>>