It is general resolution season at the Debian Project. As was discussed
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.
Comments (20 posted)
Even if you appreciate full-featured applications like OpenOffice.org,
Firefox, or GNOME, minimalist replacements have a fascination all their
own. Not only are minimalist applications a throwback to the original
traditions of Unix-like operating systems, but their emphasis on efficiency
at the expense of extra features can force you to re-evaluate your
computing needs. A case in point is Hv3, a web browser written in
Tcl/Tk. Although currently in alpha and paying more attention to
developers' needs than those of end users, Hv3 is already highly suitable
for basic web-browsing, with a design philosophy all its own -- and, quite
possibly, the fastest performance of any free software browser.
Hv3 is available for
both GNU/Linux and Windows. Packages of nightly builds are available for
Puppy Linux, but the users of most distributions must fall back on
statically-linked tarballs, following the instructions on the download page
to obtain the latest build with wget, then de-compress it and change the
permissions. You can also download the
source code, as well as Tkhtml3, a development tool for
standards-compliant HTML/CSS implementation in applications that Hv3 uses.
When you start Hv3, you also have the option of install hv3_polipo, a small
web cache, in the same directory. You can run Hv3 without hv3_polipo -- at
the expense of clicking through the same dialog each time you start the
application -- but, if you are end-user, there is no reason not to install
hv3_polipo. In fact, there is every reason to do so, since it increases
Hv3's speed by at least 25%.
Hv3 opens on a gun metal gray window with four top-level menus, a
toolbar consisting of five basic navigation choices, and the URL entry field
(as well as debugging tools that are, presumably, temporary). At the bottom
is a status bar that gives instructions for toggling between modes, but
apparently does nothing yet. Both bookmarks and downloads open in separate
tabs, rather than in a menu or a floating window, which makes for a less
cluttered appearance than in most browsers, but does result in each new tab
opening by displaying bookmarks. This default occasionally comes in handy,
but is more often an annoying preliminary step to what you really want to
Two unusual features in the Hv3 window are the ability to hide the menus
and toolbar to maximize display space, and a tree view of the page's HTML source.
Both are available from the right-click menu for a link. The tree
view is especially welcome, since it is quicker to navigate than the plain
text file of markup you get in most browsers. The difference, I suspect, is
that the Hv3 assumes that users are actively interested in looking through
the markup and using it as efficiently as possible, so that the view is not
just an after-thought.
So far, at least, search capacity is minimal in Hv3, differing little from
Firefox's except in the fact that searches of both the web and the current
page are grouped together and given prominence by a top-level search
menu. Again, the impression is that Hv3 developers are thinking of what
might be convenient for those who make regular use of the feature.
You can configure Hv3 from the Options menu, choosing the icon set to use
in the toolbar, and the size (but not the typeface) to use for the widgets
and on web pages. For some reason, you have three choices for font size on
web pages: The page zoom, the font scale (a percentage), and the font size
table (a description). You also have the option of disabling the display of
images for greater speed, and for turning off support for ECMAScript, which
As you explore Hv3, you will probably want to start by opening the Bookmark
tab. For one thing, Hv3 seems to have paid most attention to bookmarks
among the most common browser features. Because bookmarks in Hv3 open in a
separate tab, they display a tree-view list on the left, and the actual
page on the right, making them easy to learn.
More importantly, the default bookmarks include a short but adequate page
explaining the features of Hv3. An especially noteworthy feature is the
distinction between regular bookmarks, which open directly on the page, and
snapshots, an archived version of a bookmark that can be used to work
off-line. You can tell a regular bookmark because it is indicated in the
tree view by having a cyan colored circle for an icon, while a snapshot has
an icon resembling a page.
There is also a third type of bookmark that is a snapshot that retains a
link to the original. You tell this type of icon by clicking on it and
watching it toggle back and forth between the other two, a distinction that
seems all too easy to miss.
Another reason for turning early to the Bookmarks tab is to use the Import
Data button to import bookmarks from Firefox. The process lasts less than
ten seconds, and is almost formidably efficient: Not only your personal
bookmarks, but the default bookmarks for your distribution and Firefox's
default bookmarks are added to the tree view -- regardless of whether they
still appear on your personal toolbox in Firefox or not.
Many of Hv3's features suggest an effort to rethink functionality that you
can easily take for granted in your daily browsing. However, what interests
many people about minimalist web browsers is their speed. In this category,
Hv3 is in a class by itself. Without hv3_polipo installed (see above), Hv3
loads pages roughly 50% faster than Firefox, and about the same speed as Dillo, perhaps the best known minimalist
browser. However, with hv3_polipo installed, Hv3 loads pages nearly twice
as quickly as Firefox, and about 50% faster than Dillo.
means that it displays more pages correctly than Dillo does -- although, if
you are watching, you will see any text-only alternative pages display
plugin, possibly using Gnash, the free Flash replacement, then its users
would have few basic reasons to envy the users of heavyweight browsers like
Firefox except the absence of an active extensions-building community.
In its current release, Hv3 pays little attention to usability. Not only
are the debugging tools prominently displayed, but some of the options,
such as "GUI fonts" or "Force CSS metrics" seem pitched at the understanding of
developers more than that of everyday users. However, the interface names
are not that hard to figure out, particularly since they are relatively
few. Presumably, too, the Hv3 team is more concerned with performance right
now than finishing details, and will get around to such concerns closer to
the first full release.
For now, the lack of polish seems a small price to pay for the speed and
simplicity of Hv3 -- to say nothing of the reminder that useful and
thoughtful alternatives exist to well-known applications.
Comments (21 posted)
On December 11, the Free Software Foundation announced
the filing of a
GPL-infringement lawsuit against Cisco. This action represents another step
in a long series of license-compliance issues involving Cisco and its
may look like just another licensing lawsuit, but it represents an
interesting step in the evolution of attitudes toward compliance with the
GPL. The eventual outcome is fairly predictable, but the process is still
Cisco does look like a serial offender with regard to the GPL. Most of its
problems in this area were actually acquired with its purchase of Linksys;
routers made by Linksys have been been followed by GPL issues since at
least 2003. Over those years, a fairly consistent pattern has developed: a
new Linksys product is released which, upon inspection, is determined to be
running GPL-licensed software. There is no corresponding source release,
which is a clear violation of the GPL. After a series of contacts and
negotiations, some of the copyright holders involved succeed in getting a
source release - though that release is not always as complete as it should
be. The problem appears to be solved - until the next product comes out.
The sad part is that there is almost certainly no real desire on the part
of Cisco or Linksys to violate the GPL. The company is being set up for
trouble by its suppliers - the firms based in the far east which actually
make the hardware sold under the Linksys name. Those suppliers feel,
perhaps with good reason, that they need not concern themselves with the details
of license compliance. There is not, after all, much of a history of
successful license enforcement in that part of the world. So they deliver
an infringing product which Cisco then resells; it could well be that Cisco honestly
has no idea that those products incorporate software in
violation of its license. Of course, it could also be that Cisco does not
really want to know about such problems.
Nameless original equipment manufacturers in China are a difficult target
for those who would enforce the GPL; a high-profile American company is
clearly easier game. Beyond that, though, Cisco is a legitimate target for a lawsuit:
the company is distributing GPL-licensed software without making the source
available. It is also an appealing target because Cisco is in a
position to apply pressure on those nameless suppliers: if a company of
that size refuses to resell equipment which does not come with
fully-licensed software (whether free or proprietary), its suppliers will
learn to pay attention. The FSF is arguing, in essence, that it is Cisco's
responsibility to put a program in place to ensure that its suppliers are
delivering properly-licensed software. It is Cisco which should be finding
licensing problems in its products, not the owners of the code it is using.
[PDF] describes a long series of meetings with Cisco. Several times,
the complaint says, "Defendant corresponded with Plaintiff
repeatedly regarding the matter and Plaintiff believed in good faith that a
satisfactory resolution of its concerns could be reached." But then
more problems always turned up. So, after a few years, the FSF has given
Given Defendant's extensive history of violating Plaintiff's
Licenses, Plaintiff considers Defendant's current and proposed
activities insufficient to ensure Defendant's future compliance.
Defendant has refused to meet several of Plaintiff's reasonable
requirements for reinstatement of Defendant's right to distribute
the Programs. Defendant has not demonstrated that it has
meaningfully improved its software review process which failed to
prevent previous violations, or that it intends to do so. Defendant
has refused to acknowledge its previous violations or inform the
users who received Infringing Products of its omissions. And
Defendant has refused to provide regular compliance reports to
Plaintiff regarding Defendant's pervasive exploitation of
Plaintiff's software. Nonetheless, Defendant continues to
distribute the Infringing Products and Firmware in violation of
Plaintiffs' exclusive rights under the Copyright Act.
The complaint alleges that Cisco is guilty of copyright infringement. The
court is asked to provide injunctive relief - taking the offending products
off the market. The FSF is also asking for damages, attorney's fees, and
"all profits derived by Defendant from its unlawful acts."
All this would be a heavy price for Cisco to pay. And it could well be
that a court would go along with most of these requests. The fact of the
matter, though, is that things are unlikely to get that far. Unlike, say,
SCO, Cisco has not made any statements about the validity of the GPL. It
is an active contributor to GPL-licensed projects, including the Linux
kernel. Cisco's behavior looks more like negligence than malice. This
suit will probably get the attention of people in very high levels of
management at Cisco; they, in turn, will almost certainly come to the table
and find a way to make the FSF go away. There is no value for them in any
other course of action.
So this episode will blow over, probably within a few months. But there
are still a couple of interesting things to note here. One is that the
Linux kernel is not involved in this suit at all, and neither is Busybox.
Those two projects have been at the center of most GPL-enforcement actions
thus far. The FSF, though, is focusing on projects that it owns: glibc,
GCC, coreutils, binutils, gdb, and wget. That widens the scope somewhat,
showing that GPL compliance is not just required for a small number of
Incidentally, all of the code at issue in this suit is licensed under
GPLv2; version 3 of the license is not part of this action.
This suit also marks a bit of a change for the FSF, which, traditionally,
has strongly favored quiet resolution of GPL-compliance issues. It seems
that even the FSF has a point where its patience runs out. It may also be
that the influence of the Software Freedom Law Center, which appears to be
rather more willing to go to court, is being felt at the FSF. In any case,
it is reasonable to expect that the FSF might find itself involved in more
legal actions in the future.
This lawsuit will doubtless be used by people to show how use of
GPL-licensed software can create risks for companies. The truth is more
straightforward, though. Use of any copyrighted material without an
accompanying license is generally against the law; incorporating such
material into products will always be a risky thing to do. There is
nothing special about the GPL in that regard.
Comments (62 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: "Vishing" advisory targets Asterisk; New vulnerabilities in drupal, firefox/seamonkey, phpMyAdmin, uw-imap,...
- Kernel: System calls and 64-bit architectures; Followups: performance counters, ksplice, and fsnotify; SLQB.
- Distributions: Localization under a government umbrella; new releases of Slackware 12.2, Linux Mint 6 and Omega 10; Debian 5.0 update; Fedora fixes dbus problem; Sneak Peeks at openSUSE 11.1; openSUSE 10.2 EOL; new to the list cp6Linux, Hackable:1 and TurnKey Linux.
- Development: Profiling the Power Usage of a Desktop PC, new versions of Rivendell, Fuse, Samba, DavMail, libnetfilter_conntrack, multi-resolver, Apache, XPanel, Visualiser, Vamp, rrdtool, LyX, GpsMid, Irrlicht, pycairo, Elisa, ETS, WebcamStudio, Firefox, AsciiDoc, OpenSwing, Parrot, Perl, Hypy, MPFR, ULP, Hatta.
- Press: Can Open Source Help the Economy?, Small is beautiful, HP sells Linux PCs, Jaspersoft gets $12.5M investment, interviews with Jeremy Allison, Sjoerd Simons and Warren Woodford, LTSP review, Shuttle X27D review, problems in bug tracking systems.
- Announcements: FSF sues Cisco, FSFE adds fellowship seats, Waugh leaves GNOME board, Linux Fund partners with gEDA and Gnash, TPF gets $50K, X.org election, Browser Security Handbook, EuroPy cfp, OSCON cfp, FSFE translation sprint, Money:Tech speakers, VMworld SF.