LWN.net Weekly Edition for November 6, 2008

The end of the road for Firefox 2

By some accounts, the Firefox browser is now responsible for a full 20% of web traffic. As the number of Firefox users grows, so does the need for top-quality support; 20% makes for a large number of potential attack points. So it is interesting to note that Mozilla is now planning to end Firefox 2 support in the near future, perhaps before the end of the year. This change could leave a lot of users - and not just Firefox users - in a difficult position.

One obvious question to ask would be: have most Firefox users moved on to Firefox 3? Apparently, about two out of three users have made the change, but millions of users have yet to move away from the older browser. The Mozilla project would like to get as many of those users to switch before ending support; that, in turn, requires looking at why they haven't yet upgraded. There seem to be a few prominent reasons beyond sheer inertia:

• Some users have systems which are not supported by Firefox 3. Many of these, it seems, are running old versions of Windows - 9x or NT4. In these cases, the operating system itself has long since ceased to receive support, so it's not entirely clear that continuing to support the browser does a whole lot of good.

• Others are dependent on extensions which have not been ported to Firefox 3. While most actively-developed extensions were ported some time ago, it appears that there are quite a few extensions which, while still having significant numbers of users, have been abandoned by their developers. Zack Weinberg has suggested that the project could make an active effort to find new maintainers for those extensions, or even fix a few of them itself.

• The Firefox 3 experience is not problem-free for all users; there have been some complaints about printing on some systems, for example. Finding - and fixing - the remaining blockers is clearly an important thing for the Firefox developers to do.

Somehow, ways will probably be found to coax most of these users into moving forward to a newer browser. Beyond doubt, though, some will be left behind, and some of those may learn the hard way what "unsupported" really means. But that will be true no matter how long Firefox 2 is supported; there's never a way to get all users to upgrade. Firefox is not different from any other application in this regard, with the sole exception that its user base is larger than most.

There is another important aspect to this story, though: this decision will affect users well beyond those who use Firefox. The end of Firefox 2 support will also bring an end to support for the Gecko 1.8.1 platform. And this version of Gecko is used by several applications beyond Firefox, including Camino, SeaMonkey, Sunbird, Miro, Instantbird, and Thunderbird. All of these platforms currently use Gecko - the soon-to-be-discontinued version of Gecko - for HTML rendering.

There is a fair amount of concern about Thunderbird in particular. This mail client was recently kicked out of the Mozilla nest to fend for itself. Thunderbird developers are working toward a Thunderbird 3 release (the third alpha release came out in mid-October) which will use a newer version of Gecko. But the 3.0 release is still several months away - some months after the end of Gecko 1.8.1 support. Naturally enough, the Thunderbird developers worry that their current users will be running in an unsupported mode; that does not strike them as the best start for their newly-independent project.

The word from the Mozilla Foundation seems to be that the Gecko platform will continue to be supported, in some minimal fashion, for a while yet. According to Samuel Sidler:

So it seems that Thunderbird should be covered - as long as the people who decide whether bugs are "browser-specific" do their job properly. But experience has shown many times that it can be hard to understand the full implications of a given bug. It would not be all that surprising for one or more "browser-specific" bugs to turn out to be fully exploitable in Thunderbird.

Beyond that, though, applications like SeaMonkey and Camino are browsers. Developers from those projects are, needless to say, concerned that their needs are not being taken into account. They are not attracted by the idea of shipping a browser based on a platform where browser-specific bugs are being ignored. Mozilla developers have tried to reassure these groups that the situation is not as bad as it seems, but how things will work for them is far from clear. The real answer was, perhaps, suggested by Samuel:

In other words, Mozilla would like to outsource the maintenance of this code to the community, and to distributors in particular. The good news is that this is free software, so this kind of extended maintenance is possible as long as the interest is there to do it. Gecko is a non-trivial body of software to maintain, but it should be possible for the various interested projects, along with distributors still shipping this code, to pool their effort and get the job done. In their spare time, perhaps, they can give some thought to how they might avoid getting caught in the same situation when Firefox 3 reaches the end of its supported life.

Comments (19 posted)

GFDL 1.3: Wikipedia's exit permit

Wikipedia is one of the preeminent examples of what can be done in an open setting; it has, over the years, accumulated millions of articles - many of them excellent - in a large number of languages. Wikipedia also has a bit of a licensing problem, but it would appear that recent events, including the release of a new license by the Free Software Foundation, offers a way out.

Wikipedia is licensed under the GNU Free Documentation License (GFDL). The GFDL has been covered here a number of times; it is, to put it mildly, a controversial document. Its anti-DRM provisions are sufficiently broad that, by some peoples' interpretation, a simple "chmod -r" on a GFDL-licensed file is a violation. But the biggest complaint has to do with the GFDL's notion of "invariant sections." These sections must be propagated unchanged with any copy (or derived work) of the original document. The GFDL itself must also be included with any copies. So a one-page excerpt from the GNU Emacs manual, for example, must be accompanied by several dozen pages of material, including the original GNU Manifesto.

So the GFDL has come to be seen by many as more of a tool for the propagation of FSF propaganda than a license for truly free documentation. Much of the community avoids this license; some groups, such as the Debian Project, see it as non-free. Many projects which still do use the GFDL make a clear point of avoiding (or disallowing outright) the use of cover texts, invariant sections, and other GFDL features. Some projects have dropped the GFDL; in many cases, they have moved to the Creative Commons attribution-sharealike license which retains the copyleft provisions of the GFDL without most of the unwanted baggage.

Members of the Wikipedia project have wanted to move away from the GFDL for some time. They have a problem, though: like the Linux kernel, Wikipedia does not require copyright assignments from its contributors. So any relicensing of Wikipedia content would require the permission of all the contributors. For a project on the scale of Wikipedia, the chances of simply finding all of the contributors - much less getting them to agree on a license change - are about zero. So Wikipedia, it seems, is stuck with its current license.

There is one exception, though. The Wikipedia copyright policy, under which contributions are accepted, reads like this:

The presence of the "or any later version" language allows Wikipedia content to be distributed under the terms of later versions of the GFDL with no need to seek permission from individual contributors. Surprisingly, the Wikimedia Foundation has managed to get the Free Software Foundation to cooperate in the use of the "or any later version" permission to carry out an interesting legal hack.

On November 3, the FSF and the Wikimedia Foundation jointly announced the release of version 1.3 of the GFDL. This announcement came as a surprise to many, who had no idea that a new GFDL 1.x release was in the works. This update does not address any of the well-known complaints against the GFDL. Instead, it added a new section:

In other words, GFDL-licensed sites like Wikipedia have a special, nine-month window in which they can relicense their content to the Creative Commons attribution-sharealike license. This works because (1) moving to version 1.3 of the license is allowed under the "or any later version" terms, and (2) relicensing to CC-BY-SA is allowed by GFDL 1.3.

Legal codes, like other kinds of code, have a certain tendency to pick up cruft as they are patched over time. In this case, the FSF has added a special, time-limited hack which lets Wikipedia make a graceful exit from the GFDL license regime. This move is surprising to many, who would not have guessed that the FSF would go for it. Lawrence Lessig, who calls the change "enormously important," expresses it this way:

For whatever reason, Stallman and the FSF chose to go along with this change, though not before adding some safeguards. The November 1 cutoff date (which precedes the GFDL 1.3 announcement) is there to prevent troublemakers from posting FSF manuals to Wikipedia in their entirety, and, thus, relicensing them.

Now that Wikipedia has its escape clause, it needs to decide how to respond. The plan would appear to be this:

This proposal will be followed by a "community-wide referendum," with a majority vote deciding whether the new policy will be adopted or not. Expect some interesting discussions over the next month.

This series of events highlights a couple of important points to keep in mind when considering copyright and licensing for a project. There is a certain simplicity and egalitarianism inherent in allowing contributors to retain their copyrights. But it does also limit a project's ability to recover from a suboptimal license choice later on. Licensing inflexibility can be a good thing or a bad thing, depending on your point of view, but it is certainly something which could be kept in mind.

The other thing to be aware of is just how much power the "or any later version" text puts into the hands of the FSF. The license promises that later versions will be "similar in spirit," but the GPLv3 debate made it clear that similarity of spirit is in the eye of the beholder. It is not immediately obvious that allowing text to be relicensed (to a license controlled by a completely different organization) is in the "spirit" of the original GFDL. Your editor suspects that most contributors will be willing to accept this change, but there may be some who feel that their trust was abused.

Finally, it's worth noting that "any later version" includes GFDL 2.0. The discussion draft of this major license upgrade has been available for comments for a full two years now. The FSF has not said anything about when it plans to move forward with the new license, but it seems clear that anybody wanting to comment on this draft would be well advised to do so soon.

Comments (40 posted)

Testing Fedora on the OLPC

In preparation for this year's version of the Give One, Get One (G1G1) promotion of the One Laptop Per Child (OLPC) XO, the Fedora OLPC special interest group (SIG) has undertaken a rather large testing effort. With the assistance of 80 mostly-free XOs, the group has been running Fedora 10 on the hardware, trying to shake out Fedora and OLPC bugs. The idea is to help lift some of the burden from the OLPC developers, while also providing some distribution testing focused on areas specific to the OLPC hardware.

G1G1 participants can optionally purchase an SD card pre-loaded with a Fedora 10 live distribution, so that they can run a full Fedora desktop on the XO. Normally, it runs a stripped-down version of Fedora 9 with the Sugar interface as the only desktop available. Part of the Fedora OLPC effort is to help reduce the operating system burden for the OLPC folks. Fedora OLPC liaison (and Red Hat Senior Community Architect) Greg DeKoenigsberg describes where the project is headed:

Back in September, DeKoenigsberg put out a call for folks interested in testing, with the incentive of a "mostly" free XO. Participants needed to be willing to buy an SD card to put Fedora on and to spend 20 hours testing Fedora on the XO. There were more volunteers than laptops, as would be expected, but 80 XOs—most refurbished returns from the original G1G1 last year—got into the hands of many "experienced Fedora community members". The XOs were provided by the OLPC project through its developer program.

The testing has already "found and resolved a number of potential release blockers", according to DeKoenigsberg. There is an extensive test plan that outlines the different testing areas as well as the methodology of testing and reporting bugs found. In many ways, this is just a test of Fedora on a new hardware platform, with the focus on things that set the XO apart: power management, networking, the built-in camera, display, performance, etc.

But there is more to the SIG than just testing the XO. The task list has a number of different activities that are currently underway. Getting a developer key to each person who chooses the Fedora 10 option in G1G1 is an important piece of the puzzle—the XO security policy will not allow it to boot from SD without it. Various Sugar tasks are high on the list as well.

One of those is the Fedora Sugar spin, a Live CD that allows running the Sugar environment on any computer. So far, there are just a few Sugar "activities"—roughly equivalent to applications for things like web browsing or word processing—available for the spin, but that is another of the tasks that Fedora OLPC will be working on. There is currently a bit of an awkward debate on the fedora-advisory-board mailing list about how "official" the Sugar spin really is—as it missed the deadline for the Fedora 10 freeze—but it would seem that many are in favor of granting it a waiver.

The Fedora OLPC SIG's mission statement—"To provide the OLPC project with a strong, sustainable, scalable, community-driven base platform for innovation"—makes it clear it sees a big role in assisting OLPC going forward. The testing effort is just one facet of that, as DeKoenigsberg notes:

The OLPC project is one with great promise. It has suffered at times from the mixed message that it gives regarding free vs. proprietary software, but it could, clearly, be a marvelous example of free software in action. In order for that to happen, though, there will need to be a concerted effort by the free software community to assist. The Fedora OLPC SIG looks to be an excellent step in that direction.

Comments (3 posted)