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
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
- 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
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
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.
Comments (19 posted)
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
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
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
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
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
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.
Comments (40 posted)
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:
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
The testing has already "found and resolved a number of potential
release blockers," according to DeKoenigsberg. There is an
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
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
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
10 freeze—but it would seem that many are in favor of granting it a
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.
Comments (3 posted)
Page editor: Jonathan Corbet
Next page: Security>>