Longtime LWN readers will be aware of your editor's tendency toward the
publishing of wild predictions at the beginning of each year. The
Debian developers and users by suggesting that, after getting the Etch
release out the door, the project would go back to arguing about
firmware issues. At the end of the year, it became necessary to
acknowledge that this prediction, like so many others, had failed to come
to pass. In retrospect, the error in this prediction was obvious: the
Debian Project traditionally saves the firmware argument for the end of the
release process. After all, they need to find some
way to delay a
release once it's looking close to ready.
The problem with firmware, of course, is that it is a binary blob lacking
the corresponding source, and, sometimes, even a license allowing its
distribution. Many developers and users see that blob as being part of the
hardware; as long as the blob is distributable, it does not bother them.
Others, though, regard firmware blobs as proprietary software and their
incorporation into the kernel as a GPL violation. The Debian Project,
which promises to deliver a 100% free distribution to its users, houses
many developers from the latter camp. These developers, who see firmware
distribution as a violation of the project's social contract, can be
counted upon to raise the issue each release cycle.
In 2004, the project responded by passing a general resolution
suspending some social contract provisions through September 1 of that
year on the
reasoning that it would be long enough to get the Sarge release done.
Putting a date on a Debian release tends to be a mistake, though; Sarge was
not finished until June, 2005. By unspoken consensus, that date was
somehow deemed to have fallen before September 1, 2004. In 2006, the
project voted again
on firmware. Having learned from experience, the exception they allowed
this time lacked a date, simply saying that the presence of binary-only
firmware in the Etch release was something the project was willing to
The 2008 discussion started when Ben Finney
pointed out that a number of firmware-related entries in the Debian bug
tracking system had been quietly marked "lenny-ignore" - not relevant to
the upcoming Lenny release. This action, many have subsequently argued,
runs counter to the social contract and constitution, which do not allow
the shipping of non-free software to be swept under the carpet in this way.
They would, instead, like to see the kernel team remove the (relatively
few) firmware blobs remaining in the kernel. Such a change, it is said,
should be relatively easy; recent changes within the kernel are
helpful in this regard - though said changes became available in 2.6.27,
which is not the kernel expected to be shipped with the Lenny release. For
the 2.6.26 kernel used by Lenny, Ben Hutchings reports that he has done the necessary work to
excise the remaining firmware.
On the other side, there are developers who are more concerned about
(1) getting the Lenny release out as quickly as possible, and
(2) making sure that hardware Just Works for Lenny users. They would
rather that the process of removing firmware continue independently of (and
without delaying) the
This is Debian that we're talking about, so the issue will probably be
decided by way of a general resolution. There are currently two sets of
resolutions being circulated, though neither has reached a final state for
voting. The first set addresses the Lenny
question, providing two options: either delay Lenny until the firmware
removal work is complete, or accept that - just once more, really this
time, honest - a major Debian release will include some firmware in its
kernel. (The "ship Lenny" option is actually two options, one allowing
firmware and one allowing Debian Free Software Guidelines violations in
general). What the project will decide once this resolution comes to a
vote is unclear - but Debian's developers have always voted to get the
release out in the past.
The second proposal addresses what happens
after the Lenny release; it says that any package which violates the Debian
Free Software Guidelines for more than 180 days will be forced into
the non-free repository. The clear hope here is to ensure that this tiresome
discussion doesn't happen yet again in the next release cycle. By the time
the next release is getting close to ready, any non-compliant packages will
have long since been banished to the non-free wasteland. If it ever comes
down to moving the kernel to non-free, though, one can assume that the
discussion will resume with a vengeance.
Developers, Members, Maintainers, and Contributors
Meanwhile, a different disagreement is headed toward - you guessed it - a
general resolution. Long-time Debian watchers have noted that another
recurring topic of debate is the acceptance of new developers. The new
maintainer process involves long delays, tests of ideological purity, and
more. Even when it works smoothly (which seems to generally be the case in
recent years) it requires a certain amount of patience and determination on
the part of an aspiring Debian Developer.
The difficulty of the process is a design feature; Debian developers occupy
a position of some trust, and the project wants to make sure that
applicants are serious. Over time, though, it has become clear that this
process is costing the project the time and energy of talented contributors
who do not wish to jump through all the hoops. In response, the project
created a "Debian maintainer" designation which allows the uploading of
packages, but withholds many of the other privileges enjoyed by full
developers. This change appears to have been successful in enabling a
larger group of developers to contribute to Debian.
More recently, Joerg Jaspert has proposed
lowering the bar to certain types of contribution even further. The
Debian is about developing a free operating system, but there's
more in an operating system than just software and packages. If we
want translators, documentation writers, artists, free software
advocates, et al. to get endorsed by the project and feel proud for
it, we need some way to acknowledge that.
To that end, Joerg would create a new "Debian Contributor" classification.
Contributors would be those doing translations or documentation; the
proposal doesn't say that contributors don't touch code, but one gets that
sense. Contributors would still have to jump through some hoops, but they
would be fewer. They would not be able to upload packages on their own.
The proposal also changes the Debian Maintainer standards, making that
designation a little bit harder to get. Finally, the proposal states that
all new applicants to the project would become Contributors or
Maintainers. Only after a six-month period would they be able to apply for
full Debian Developer or Debian Member status -- "Debian Member" being
another new category that, while being equivalent to Debian Developer in
almost all respects, would not have package upload privileges.
Interestingly, there has not been much discussion of the substance of this
proposal. But there has been a fair amount of debate over how it is being
done. It would appear that some developers see this change as being
imposed by a single project official without the debate that Debian changes
normally require. Martin Krafft has further asserted that this kind of change goes beyond
Joerg's authority as Debian account manager, a claim that Joerg
So now there are proposed general resolutions being circulated. An early version simply decreed that the
proposed changes were "suspended" in favor of changes to be made through a
more consensus-oriented process. Later
versions soften the language somewhat, and thank Joerg for his effort
in this area - but still require a "consensus or general resolution" before
changes are adopted. In any form, the clear point of the resolution is to
slow down the process and open it up for a wider discussion.
Again, voting has not begun on any specific resolution, so we don't yet
know what will even be voted on, much less how it will come out. But we
can expect that, as a certain presidential election process finally
(thankfully) comes to a close, activity will be picking up on a different
set of votes.
to post comments)