LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for November 6, 2008The end of the road for Firefox 2By 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:
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:
The triage and release team that currently works on Firefox and
Thunderbird 2.0.0.x releases will continue to triage requests for
Thunderbird 2.0.0.x and maintain its releases until six months
after the release of Thunderbird 3.
Note that this will mean that browser-specific security and stability bugs will likely be ignored/minused. We'll only be considering bugs that affect Thunderbird 2.0.0.x. 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:
The community can take over this branch, just as has been done for
Gecko 1.8.0 (currently managed by Linux vendors)
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.
GFDL 1.3: Wikipedia's exit permitWikipedia 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:
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software
Foundation; with no Invariant Sections, with no Front-Cover Texts,
and with no Back-Cover Texts.
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:
An MMC [Massive Multiauthor Collaboration Site] is "eligible for
relicensing" if it is licensed under this License, and if all works
that were first published under this License somewhere other than
this MMC, and subsequently incorporated in whole or in part into
the MMC, (1) had no cover texts or invariant sections, and (2) were
thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing. 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:
Richard Stallman deserves enormous credit for enabling this change
to occur. There were some who said RMS would never permit Wikipedia
to be relicensed, as it is one of the crown jewels in his movement
for freedom. And so it is: like the GNU/Linux operation system,
which his movement made possible, Wikipedia was made possible by
the architecture of freedom the FDL enabled. One could well
understand a lesser man finding any number of excuses for blocking
the change.
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:
Later this month, we will post a re-licensing proposal for all
Wikimedia wikis which are currently licensed under the GFDL. It
will be collaboratively developed on meta.wiki and I will announce
it here. This re-licensing proposal will include a simplified
dual-licensing proposition, under which content will continue to be
indefinitely available under GFDL, except for articles which
include CC-BY-SA-only additions from external sources. (The terms
of service, under this proposal, will be modified to require
dual-licensing permission for any new changes.)
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.
Testing Fedora on the OLPCIn 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:
The Fedora community is working
closely with OLPC to incorporate their changes upstream, and we are also
working to package Sugar as a standard desktop environment for Fedora.
Our hope is that, in future releases, the XO can run a completely stock
version of Fedora — that way, OLPC will not have to bear any costs of
maintaining the distro itself, and can focus their resources where they
are most effective: the hardware, and Sugar.
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:
We hope to have success with the Fedora on XO testing project, but the
real goal is longer term and more strategic. OLPC has placed a very large
bet on open source software. In order to be successful, they need
knowledgeable contributors — which Fedora has in abundance. There may be
more than a million XOs in the wild by the end of this year, and all of
them will be running a remix of Fedora by default. In Fedora, we have a
responsibility to help make OLPC successful, and the Fedora community
takes that responsibility very seriously.
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.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||