It is general resolution season at the Debian Project. As was
here in October,
Debian seeks to resolve two questions: one regarding types of developers in
the project, and one being the perennial firmware debate. As of this
writing, the first vote is done, while the second remains open. But it has
become clear that, regardless of the outcome of the firmware vote, this
issue has stressed the Debian community, perhaps to the breaking point.
Taking the easier subject first: Joerg Jaspert's proposal to create new
classes of Debian developers was always going to be controversial. The
real purpose of the
associated general resolution was to put the brake on those changes.
That purpose was fulfilled; the winning choice in that (low-turnout) vote
was "Invite the DAM to further discuss until vote or consensus, leading to
a new proposal." So the project will go back to doing one of the things it
excels at: talking. What form the membership proposal will have when it
re-emerges from discussion - if it ever does - is unclear.
The other vote - open until December 21 - is essentially about whether the
upcoming "Lenny" release will be delayed until all known violations of the
Debian Free Software Guidelines have been resolved - and whether firmware
blobs in the kernel count as such violations. The question being asked is
not so simple, though; in fact, Debian developers have no less than seven
different options to vote upon. The nature of this ballot, how it was
constructed, and how it will be decided has led to significant acrimony
within the project.
It is worth looking at what the seven options are (with the actual ballot
text in bold):
- Reaffirm the Social Contract. The titling of this option is
somewhat controversial - all Debian developers committed to supporting
the Social Contract before gaining their status. What this option
really means is "delay the Lenny release until all DFSG violations
known on November 1, 2008 have been resolved."
- Allow Lenny to release with proprietary firmware. This option
allows the Lenny release to happen, as long as no new firmware blobs
make their way into the distribution. The language here is quite
similar to what has been found in the resolutions allowing the Sarge
and Etch releases to happen despite ongoing firmware concerns. This
option has been deemed by project secretary Manoj Srivastava to
require a three-to-one supermajority vote to pass.
- Allow Lenny to release with DFSG violations. This choice, also
requiring a supermajority, has almost the same effect as
- Empower the release team to decide about allowing DFSG
violations. Here, the project (again, with a supermajority) would
say that it trusts the release team to make the right decisions. The
team is currently working toward a release which includes firmware,
so, again, the end result would be about the same: allow the Lenny
release process to go ahead.
- Assume blobs comply with GPL unless proven otherwise. The
actual text of this choice does not mention the GPL at all; in fact,
it reads very much like options 2 and 3. However, this one
was not deemed to require a supermajority vote.
- Exclude source requirements for firmware. This option (which
requires a supermajority) says that, for all practical purposes,
firmware is not software and, thus, a corresponding source
distribution is not required.
- Further discussion. This outcome seems inevitable regardless
of how the developers vote. If it were to win, though, then the
outcome of this general resolution would be to decide nothing.
See this posting for the full text of all
So why are many Debian developers unhappy with this ballot? There would
appear to be a few reasons, the first of which being the long list of
options. Some developers would have rather seen a simple "can Lenny
release or not?" vote, with related issues being handled in a separate
The titles given to some of the choices are seen by some as deceptive.
"Reaffirm the Social Contract" really means "delay Lenny," and "Assume
blobs comply with GPL" goes with a resolution that never mentions the GPL
at all. Developers who are unhappy with a long, messy ballot are even less
happy with option titles which seem confusing at best, or deceptive at
Then, there is the matter of the supermajority requirements. Some
developers wonder why option 2
requires a three-to-one vote, while an almost identical resolution for Etch
did not require a supermajority in 2006. The decision on majority
requirements is made entirely by the project secretary, who has the task of
determining whether a given resolution "overrides a foundation document" or
not. A few developers have made the claim that Manoj's decisions are based
less on clear understanding of what really "overrides a foundation
document" and more with the goal of ensuring that his own favored outcome
That last is, needless to say, a strong charge. As it happens, Manoj is
the proposer of the "assume blobs comply with GPL" option; he also seconded
options 1 and 2. Two of the options he has publicly supported do
not have the supermajority requirement attached to them, so,
perhaps, one could argue that Manoj is, indeed, trying to rig the vote. On
the other hand, those two options conflict with each other: one would delay
Lenny indefinitely, the other would wave the firmware problem away. So if
this is an attempt to steal an election, it is one with a highly uncertain
outcome, even if it is successful. The more straightforward interpretation
- that a long-serving project secretary is interpreting the project's
constitution to the best of his understanding, ability, and good faith - would seem to
be the more likely alternative.
Still, that has not prevented a discussion involving statements like this:
Recognizing the validity of the vote is not a "must". The
alternative is that we end up in a state of constitutional crisis.
That's unfortunate, but it's also unfortunate that our Secretary is
failing to act in a manner that safeguards the integrity of that
Other, more reasoned - but still unhappy - voices are pondering the
replacement of the project secretary. It turns out that how to do that is
not entirely clear, though. Some others have asked project leader Steve
McIntyre - who has been conspicuously quiet in this whole discussion - to
intervene. He finally responded this way:
I've been talking with Manoj already, in private to try and avoid
flaming. I specifically asked him to delay this vote until the
numerous problems with it were fixed, and it was started
anyway. I'm *really* not happy with that, and I'm following through
What "following through" means remains unclear. The Debian project leader
does not command vast powers which can be brought to bear on a problem like
this. Debian is an exceptional project in that it operates in a democratic
mode under a formal constitution. Unlike many other projects, Debian lacks
a benevolent dictator or a backing corporation with the ability to force a
decision. So we do not know what Steve will be able to do to resolve this
What we do know is that quite a few developers are going to be unhappy with
this vote regardless of how it comes out. Talk of "constitutional crisis"
is almost certainly overblown; Debian has muddled its way through no end of
strong disagreements in the past. But that still leaves a lot of room for
public conflict which further diminishes Debian's reputation and further
delays the Lenny release. What one can hope is that, somehow, the project
will manage to muddle through to an understanding on firmware that can
prevent all this from happening yet again when the next major release cycle
comes near to completion.
to post comments)