Every so often, somebody shows up on the linux-kernel list with the same
bright idea: separate the device drivers from the rest of the kernel and
release them independently. Then drivers could be installed or updated
without having to change the entire kernel. This idea never gets very far;
among other things, it implies the creation of a stable driver API, which
is just not in the
. But the idea keeps coming back anyway.
When Novell's breathless
press release, describing a "device driver breakthrough" which "solves
Linux device driver compatibility issues," your editor's first thought was
that this old idea had returned yet again. This breakthrough process
"allows customers to obtain drivers independently of Novell kernel
updates," after all, and is said to make life easier for vendors. As it
turns out, however, Novell has no plans for defining any sort of stable
kernel API; instead, it has created a mechanism making it easier for
vendors to cope with the existing, dynamic API.
Essentially, a vendor with a driver for its hardware can approach Novell,
pay whatever fee is required to become a "partner," and have its driver
distributed through the SUSE YaST mechanism. If the partner supplies
versions of the driver which work with distributed SUSE kernels, Novell
will make sure that each user gets the right version. Novell will provide
API change notifications, helping vendors to keep their drivers working
with current kernels. If the vendor becomes an Extra Special partner,
Novell will take care of much of the driver updating work themselves.
To some, this program looks for a way for Novell to help vendors who ship
proprietary drivers. And there may be some truth to that view. But the
real customer base may be elsewhere. Imagine that you are a vendor selling
products into a highly competitive market. When your new widget comes out,
you do the right thing and contribute a driver to the mainline tree. Even
if the driver is accepted on the same day (a relatively unlikely course of
events), it will not appear in a released kernel for a month or two, and it
will not show up in released distributions for some months (or years) after
that. By the time normal users can install the driver, the device is already
obsolete and being replaced by something newer, shinier, and faster.
And, in any case, having the driver in new distributions is of little help
to customers who are running older kernels and don't want to change that.
The Novell program will make it easy for this vendor to make drivers
available for the range of currently installed SUSE systems, without
forcing a kernel upgrade on their customers. If the program is done right,
it could change the landscape for the better: vendors would have an easier
time supporting the range of distributor kernels, and users would get
current drivers, even on older systems. If done wrong, it could lead to
more out-of-tree drivers, but Novell appears to have anticipated that
concern. From the driver
As an active member of the open source community, Novell's position
is clear: The best place for partners to develop kernel drivers is
upstream in the kernel.org source tree, where kernel driver code
benefits from thorough review and community involvement. Novell
promotes having all Linux device drivers be a part of the official
kernel.org source tree.
As long as vendors use this program as a backporting mechanism, it will do
nothing but good for everybody involved. If they use it as a way to avoid
the kernel development process or the need to release their code, the
benefits will be rather less. The initial signs are good enough, however,
that it is worth wishing Novell luck in this endeavor.
Comments (15 posted)
With a great deal of fanfare, Sun Microsystems used its podium at JavaOne
a change in the
Java licensing terms intended to make it easier for distributors to ship
Sun's Java implementation. To this point, the terms have been so difficult
that few distributors bother; those wanting to run Java code must either
install Sun's implementation themselves, or go with one of the free
alternatives. Sun, perhaps seeing that said free alternatives are rapidly
improving, has tried to reestablish its own dominance by way of a small
licensing tweak. It is a half measure at best.
Sun's new terms go under the name "Operating System Distributor License for
Java," or "DLJ" for short. As always, when pondering licenses, one must go
to the actual text. So, for the curious, a look at the text of the DLJ
(v1.1) is warranted. The core of the DLJ is this:
Sun also grants you a non-exclusive, non-transferable, royalty-free
limited license to reproduce and distribute the Software, directly
or indirectly through your licensees, distributors, resellers, or
OEMs, electronically or in physical form or pre-installed with your
Operating System on a general purpose desktop computer or server,
So distributors can now ship the Java code as part of the operating system,
assuming they meet all the conditions - and there are several of those.
They include some obvious ones, such as indemnification of Sun from
liability, and some that one would expect, such as the requirement that the
software be distributed without modifications. Some of the other
conditions are interesting, though. Consider:
(b) the Software is distributed with your Operating System, and
such distribution is solely for the purposes of running Programs
under the control of your Operating System and designing,
developing and testing Programs to be run under the control of your
So the license only applies to operating system distributors. This clause
would appear to make it impossible for a third party to distribute Java
packages for somebody else's distribution. So this license may not improve
the lives of people who run distributions from organizations which will not
distribute non-free code at all.
c) you do not combine, configure or distribute the Software to run
in conjunction with any additional software that implements the
same or similar functionality or APIs as the Software
So Sun's Java remains incompatible with any free Java implementations and,
presumably, a fair amount of related code. How this term might affect the
combination of Sun's Java and Eclipse is an interesting question.
Finally, there is a term stating that if any compatibility issues arise
"caused by the interaction of the Software with your Operating
System," the distributor has 90 days to fix the problem or stop
distributing Java. It is unlikely - but not inconceivable - that such a
term could be used to pressure a distributor to change Linux system call
semantics which could be deemed to cause incompatibilities.
This license can be advantageous for distributors with mechanisms for
distributing non-free software. Some of them may now be able to ship Sun's
Java code for the first time. Thus, for example, Java has just landed in Debian's non-free
repository; Ubuntu and Gentoo seem interested as well. But the new
license will not help Fedora users, since there is no place in Fedora for
non-free code (though what Red Hat does with RHEL could be different). For
all the hints made at JavaOne regarding the eventual open-sourcing of Java,
this code remains resolutely non-free at this time. Sun's slightly more
friendly license has not changed that fundamental fact.
Comments (43 posted)
Frequent LWN readers will be well aware that your editor has had some real
fun playing with Rockbox
, a set of
GPL-licensed firmware for digital music players. So the Rockbox 3.0
release, originally scheduled for March 15, is of more than passing
interest. This release will offer a number of new features:
- The addition of the iRiver H1xx and H3xx players as fully-supported
targets. Rockbox works on a number of other players as well (notably
iPods and the iAudio X5), but those platforms are not quite ready for
a stable release yet.
- Several new games, including Jewels,
and others. Players with suitable displays can even run Doom.
- Support for Unicode and translations to 28 languages.
- New codecs, including WAV playback on Archos models and AIFF.
- The Tag
Cache music database, allowing the user to browse through the
collection based on several attributes.
- A built-in five-band parametric equalizer.
- High-quality, lossless recording on platforms which support it.
There are, of course, many other improvements to the code which help to
make it more robust and maintainable, but which tend not to show up on
feature lists. Your editor has been running the occasional daily build
with good results. This looks to be a release which exposes Rockbox to a
wider user base and, in general, draws more attention to the project.
Only one problem remains: it doesn't all work yet. There are a number of
codec issues, such as confusion when the user skips around too much. A
number of trouble reports with the H1xx models have been posted. Battery
life on the H3xx is still far less than with the iRiver firmware. In
general, the list
of open bugs is on the long side for a project on the verge of a stable
The Rockbox developers thus find themselves in a place familiar to many
projects: trying to decide when to make a major release. Putting out a
buggy system would not endear Rockbox to many of its users, and could set
the project back severely. Meanwhile, however, the ongoing feature freeze
has brought development to a stop and is creating a fair amount of patch
pressure. The developers would very much like to get this release out of
the way and move on to working on the new, fun stuff.
Getting releases out is one of the biggest challenges faced by many free
software projects. There is a natural tension between the creation of
truly stable releases and going on to develop the Next Cool Thing. A
number of techniques have evolved as a way of resolving this conflict:
The Rockbox developers do not appear to welcome the idea of creating
a separate development branch. So some sort of compromise between a timely
release and a bug-free release will have to be found. There is some
sentiment for putting out 3.0 on Monday the 22nd, with known bugs if need
be. The worst of those bugs might subsequently be fixed in an update
release shortly thereafter. So, while Rockbox 3.0 will doubtless make
many users entirely happy, it may well be a true "dot-zero" release for
Comments (7 posted)
the previous article in
this series pointed out, one of the key developments in the rise of
open content was the drafting of suitable licenses to codify the
freedom to use these materials in various ways. One important licensing option
is that of modifying open content to create new works. Licenses may
open up the possibility of such collaborative ventures, but on their
own are not enough. Practical tools are needed to help people to
work together on open content. For that, software code is required
alongside the legal code, and application development has played just
as important role in the rise of open content as the refining of
catalytic effect of tools can be seen in the sphere of blogs, which
represent a very popular, if coarse-grained, kind of online
collaboration. Several online Web diaries were around as early as
1995, the same year that the authors of Suck's
mordant posts first stepped onto the punishing daily treadmill that
has become a hallmark of top blogs. But the term “weblog”
in December 1997, and was shortened to “blog”
in 1999, by which time there were just 23 of them according
to one count.
trigger for their rapid growth was the arrival of tools such as
LiveJournal, Pita, Blogger and Groksoup in 1999 that made creating
blog posts as easy as sending an email. Once the medium began to
take off, keeping up with all the postings became a problem.
Technology provided the solution through the Really Simple
standard, which grew out of earlier work by Dave Winer and Netscape.
Once in place, this apparently obscure XML standard allowed blog
readers to subscribe to a blog feed – vastly easier than going
to a blog and reading posts one by one.
availability of this technical solution drove the readership of blogs to
even higher levels. Now the problem became not so much reading the
posts you had subscribed to, but finding blogs of interest among the
millions out there. The solution – dedicated blog search
engines like Technorati –
flowed from another of Dave Winer's technical innovations: the blog
ping. Each time someone made a post to a blog created with
Winer's software, the program pinged his site weblogs.com,
which held a record of all such postings. Blog search engines like
Technorati could therefore use the pings as a signal to refresh their
indexes for the site in question, ensuring that they were always
up-to-date. By contrast, conventional search engines tend to be days
or even weeks behind the rapid posting rhythm that distinguishes
blogs from traditional Web pages.
are clearly collaborative – their essence is the intellectual
give-and-take between those posting, quoting and linking, and those
commenting, which together create a kind of patchwork communal
document. But to allow a more thoroughgoing and fine-grained
collaboration, where texts could be modified right down to the level
of individual words, a new kind of software had to be developed, what
came to be called the wiki.
it was in the world of coding that this solution emerged. Ward
Cunningham, now employed
by the Eclipse Foundation, is well-known for his work on areas like
agile development and
programming. Many of agile development's principles read as if
they were referring to open source and open content, notably in
valuing “individuals and interactions over processes and
tools,” and “customer collaboration over contracts
important field that Cunningham has been associated with is design
patterns, notably through his Portland
Pattern Repository. It was for the latter that Cunningham
in 1995 as a way of
facilitating the exchange of ideas between programmers. The name
“wiki” comes from a Hawaiian term meaning
“quick”, and was chosen in part for its alliteration with
the word “Web”, mimicking “WorldWideWeb”.
The “quickness” refers to the ease with which Wiki pages
can be added or edited, allowing content to be worked on in a true
apparently minor modification of previous Web technologies has led to
a proliferation of large-scale collaborative open content, both on
the public Web and, increasingly, on corporate intranets. Perhaps
the most famous example is Wikipedia,
which grew out of Nupedia,
an earlier online encyclopedia. Nupedia did not employ the wiki's
completely open approach for content creation, and never got beyond
producing a handful of articles, whereas Wikipedia has already passed
the one million article mark for the English language alone.
Wikipedia there is Wikimedia
Commons, which offers non-textual open content – images,
sounds and videos. But unlike the main Wikipedia articles, these are
rarely edited or modified, even though many are released under
licenses that would permit this. Similarly, the huge holdings of
open content images on Flickr
tend to be used as they are, rather than as the basis for derived
works. As well as these consolidated collections, there is
Yotophoto, a dedicated open
content search engine for images, and similar facilities on Google,
and the open source Nutch
(all available from the Creative Commons search
page, included by default among the Firefox search engines),
which allow material to be found across the Web.
ready availability of graphical open content raises the question of
what might be done with it. Tools like GIMP
have been around for years, but so far there does not seem to be the
same kind of broad collaborative tradition for graphics as there is
for texts. An interesting first attempt can be found in Kollabor8,
and recently the film “Elephant's
Dream”, produced using the 3D graphics creation package
under a Creative Commons license.
area of non-textual open content where collaboration does seem to be
thriving is that of music. This is probably for both historical and
technical reasons. Musicians have always used the work of others as
springboards for their own music, often incorporating tunes, motifs
or chord progressions directly. In addition, the well-defined
time-based nature of music (beats/bars/phrases) provides an
easily-grasped framework within which fragments/samples from various
sources can be placed either sequentially or simultaneously –
something lacking for graphical images, where spatial relationships
are not so formally defined. The abundance of high-quality open
source music creation, editing and mixing software may be another
the reason, open content music is flourishing, as the existence of a
number of music sites offering material for remixing indicates. One
recent commercial example is My
Life in the Bush of Ghosts [Flash], by David Byrne and Brian Eno, while,
on the non-commercial side, the Creative Commons site has a
section. Past and present projects found there include the Wired
CD, which offered tracks from major artists that were made freely
available for remixing (though usually only for non-commercial
purposes), and the ccMixter site.
The latter encourages musicians to upload samples, and to take each
other's music for use as the basis of new open content works which
can then be added to the pool of raw materials for others to work on.
An alternative approach is offered by MyVirtualBand,
which enables collaboration to take place even earlier in the
Moody writes about open source and open content at opendotdotdot.
Comments (1 posted)
Page editor: Jonathan Corbet
Next page: Security>>