LWN.net Weekly Edition for December 18, 2008

Debian goes to the polls

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):

1. 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."

2. 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.

3. Allow Lenny to release with DFSG violations. This choice, also requiring a supermajority, has almost the same effect as option 2.

4. 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.

5. 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.

6. 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.

7. 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.

Comments (20 posted)

Hv3 and the art of minimalist web-browsing

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 embedding 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%.

Using Hv3

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 do.

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 provides support for what is commonly referred to as JavaScript.

Bookmarks

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.

Speed vs.Geekiness

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.

Moreover, Hv3 has the advantage over Dillo of supporting JavaScript, which means that it displays more pages correctly than Dillo does -- although, if you are watching, you will see any text-only alternative pages display before Hv3 renders a JavaScript page. If Hv3 would only include a Flash 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)

The FSF raises the stakes for Cisco

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 subsidiaries. It 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 worth watching.

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.

The complaint [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 up:

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 programs.

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)