Debian goes to the polls
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
option 2.
- 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 seven options.
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 resolution.
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 worst.
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 wins.
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:
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:
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 issue.
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.