Given the amount of work which went into the recent Fedora 7 release,
it would not be surprising if the Fedora developers were to go off and
focus on beer consumption for a little while. As it happens, the beer is
(mostly) staying in the refrigerator and the Fedora community is getting a
quick start on the Fedora 8 release; the beginning of a feature
is in the works. The draft schedule
has been posted, and it is ambitious: Fedora 8 is due on
October 31 (Halloween), after a mere five months of development.
This schedule has raised some eyebrows within the community. Five months
seems quite short for the development of a new version of this
distribution. The final development freeze is on October 17, which
disappoints KDE fans: the KDE4
schedule calls for an October 23 release. If one looks at the
feature freeze date (August 20), then Fedora 8 appears poorly
aligned with the GNOME 2.20 schedule
as well. Why, it is asked, should the Fedora project rush out a
distribution under a tight schedule which causes it to miss the major
developments that users are looking for?
The answer lies in the Fedora leadership's desire to get the distribution back
onto a regular six-month schedule. A predictable release pattern is
better for everybody involved. Users know when it will happen, and major
development projects can, if they care, plan their own schedules around the
distribution releases. Fedora's releases have been a bit less predictable
than usual recently, an understandable result of the changes the project
has undergone. But Fedora 8 looks like a good opportunity to bring
things back in line.
That reasoning still leaves open the question of why this cycle needs to be
only five months long. The Fedora folks are juggling a couple of other
concerns here. One of them is that final distribution releases are best
placed far from the end of Red Hat's fiscal quarters; it seems that it's a
lot easier to get peoples' attention when they're not trying to close out a
quarter. The Fedora leadership has also noticed that, just occasionally,
Fedora releases have been known to slip back a bit from their planned
date. Putting that date in October allows for a certain amount of slippage
without pushing the release back into the middle of the holiday season. A
Fedora release as a Christmas/Hanukkah/Kwanza/Yule present is a pleasant
idea, but it's less pleasant for Fedora developers who may have other plans
during that time.
The end result of all this is that Fedora is likely to cling fairly tightly
to an April and October release schedule. We are seeing a similar pattern
with some other distributions, and with other large projects. Over time,
perhaps, some sort of loose, global coordination of release schedules
across much of the community is emerging. That would be an interesting
example of spontaneous organization where few expected it to happen.
Meanwhile, there is still some significant grumbling within the ranks of
the Fedora developers who came from the Extras side of the distribution.
Putting an updated package into the old Extras repository was a simple
process; now the "short
form" of the packaging guidelines shows a 15-step process to upload a
single package. A new requirement to route packages through the
updates-testing area was the last straw for
some developers who were already unhappy with what they see as a heavy
bureaucracy which has been imposed upon them. There is talk of having lost control of what used to be
a community-oriented Fedora Extras distribution.
This discussion should be looked at with the understanding that the merger
of Fedora Core and Fedora Extras was a major change in how Fedora
is made. Naturally there will be culture clashes, growing
pains, and conflicts as two very different sets of processes are merged
into a single, new process. The path toward a solution was articulated clearly by longtime contributor
So lets deal with it now -- for example by making "contributing to
Fedora easy again, get the community involved better into the
decisions process and make packagers happy again" one of the most
important "Features" for Fedora 8. Otherwise the merge might fail
in the end.
Disagreements within large projects are not uncommon, even without the
added stress of major change. The open nature of projects like Fedora
causes these disagreements to unfold in very public ways. The good news is
that if the project's participants are serious about pursuing a common goal
- creating the best free distribution they can, for example - they usually
find a way to address the issues and move on. With any luck the remaining
difficulties from the merger will be a distant memory by the time we're
thinking that our Fedora 7 systems are getting old and are in need of
Comments (1 posted)
A project's name is its identity which embodies all of the good (or bad)
will that the software and its developers have built up over time.
In order to protect it, a project will sometimes register a trademark
for the name allowing them to control who uses it.
If someone outside of the project tries to grab that control by
registering the trademark, especially without consulting the development
team, sparks will fly. That is just what we are seeing in a dispute
between handhelds.org and two of the
projects associated with it.
As one might guess from the name, handhelds.org is essentially a portal
for open source, typically Linux-based, software for small embedded
devices, mostly PDAs. It provides CVS repositories, bug tracking,
mailing lists and other developer services to a handful of projects
related to handheld devices. The GPE Palmtop Environment (GPE) and the
Open Palmtop Integrated Environment (Opie) provided a user interface
including some Personal Information Management (PIM) applications for PDAs.
Both projects were developed using the facilities at handhelds.org, but it
is apparent that there is a disconnect between the projects and the portal:
is handhelds.org just a
hosting site like SourceForge or is it something more? That question is
at the heart of the disputes.
In August of 2006, several GPE Palmtop Environment (GPE) developers
moving the project from handhelds.org to a relatively new site called
Linux-To-Go (LTG). The stated reasons
for the move were somewhat vague, but it clearly was an attempt by those
developers to gain more control over the hosting of the project and which
development tools were used. It was perceived to be a power grab by some and
was not met with wholehearted acceptance, but the main detractors were people
associated or affiliated with handhelds.org rather than core GPE developers.
Another round of mailing list flames came about in October when the move
to LTG actually started to happen. As with any acrimonious split,
there were accusations of various sorts being thrown around, the GPE
developers were accused of deleting the CVS repository on handhelds.org
while handhelds.org was alleged to have deleted user accounts, links to
the new site and mailing list messages. The transition seems to have gone
well for LTG as most or all of the GPE developers moved over to the new
All of that bickering is well in the past now, the GPE project has moved on,
and handhelds.org continues to host various projects, but a dispute over
an Internet Relay Chat (IRC) channel has recently rekindled the flames. The
administrators at freenode surely had
no idea what they were stepping into when they acted on a renaming request
from handhelds.org and pointed the #gpe channel at
#handhelds-gpe. The #gpe channel had been in use by
the project at LTG, and a request to control the channel had been made by
LTG in November but had not yet been acted upon. When freenode discovered
the problem they restored the channel to the LTG folks and promptly received
an email from handhelds.org claiming GPE as their trademark. At that point,
freenode took the channel away from both awaiting a resolution of the
It turns out that in March, George France, CEO of Handhelds.org Inc., which
is the non-profit company that runs the website, applied to register
trademarks for several of the projects that are hosted there. GPE and
Opie were two of those projects. Then in mid-May
under cover of an innocuous CVS comment, France changed the handhelds.org
legal page to include
a statement claiming that GPE, Opie and another 11 projects as "Trademarks of
that GPE and Opie were always trademarks of handhelds.org and
the registration is just to clean up the legalities of the matter:
Although I am not a lawyer, in the united states, a trademark comes from using
a mark in trade, which is known as an unregistered mark. You can not
register a trademark in the US unless it has been an unregistered mark first.
Registration is just bow, that gives extra rights like presumptive [ownership].
Opie has been a trademark of handhelds.org, inc for a long long time. Now it
is more visible, but nothing new is going on.
The GPE folks claim that the name GPE pre-dates hosting on
handhelds.org and that
the active project should be the one to hold the trademark, as all
handhelds.org ever did was provide hosting services. France never consulted
with either project regarding registering the trademarks, presumably because
he believed them to be already the property of handhelds.org. It seems
fairly presumptuous to claim a project's name, even for the most altruistic
of reasons, without consulting the people whose code embodies that project.
Whether the handhelds.org folks wish to acknowledge it or not, the active GPE
project is now hosted at LTG. The GPE mailing list archives
activity of consequence at handhelds.org since April whereas the
is fairly active. Under those circumstances
it seems disingenuous to suggest, as some handhelds.org folks have, that
the LTG project is a fork and should therefore change its name. GPE has
moved rather than forked.
Opie seems to have gotten caught in the GPE crossfire to some extent. The
project itself was not very active when one of the earlier developers
tried to start an OpieII project that would update the code to Qt4. His
choice of hosting it at LTG was at least partially to blame for a request
from handhelds.org that he not use the name OpieII as it infringes upon
the Opie trademark. This led to yet another flame-filled
thread about handhelds.org usurping a project's name, but it also led to a possible
solution to the whole mess. One of the original Opie founders stepped in
and has come up with a possible
where he will be licensed to use the Opie name and will host an Opie
development site separate from handhelds.org (though still affiliated as
opie.handhelds.org). In addition, a community council for handhelds.org
would be formed and a code of conduct would be created to try and avoid
these kind of situations in the future. One might hope this model could
lead to better relations between GPE and handhelds.org, but egos on both
sides would make that an unlikely scenario.
If a loose collection of developers comes together and starts contributing
code to a project, one would think that they would be entitled to own
the trademark on the name they chose.
But unless the project puts together some
kind of governing structure and applies for a trademark at or near day
one, there can always be questions about the name. Does it belong to the
founders, the current developers or the site that hosts their CVS repository?
How do you define who is a "member" so that the governing
structure adequately represents the interests of the "community"?
These are difficult questions and are probably about the last thing a group of
hackers wants to deal with at the initial stages of a project. In many
cases, it is too early to tell if the project will even get going enough
that it makes sense to spend any time on governance issues.
Trademarks are a bit of a double-edged sword, they can protect a project
from someone misrepresenting the code, a spyware infested browser called
Firefox for instance, but there needs to be some kind of entity that
administers and enforces the mark. It would be difficult for someone
completely unrelated to a project to register the trademark and hope to have
it stick, as William Della Croce found out with the Linux trademark in 1996,
but it costs real money to wrest the trademark back, and a free software
project is unlikely to have that easily at hand. This is an issue that
project leaders need to at least think about as their projects mature.
Comments (15 posted)
The Free Software Foundation has announced
of the "last call" draft of version 3 of the GNU General Public
License. In the absence of a significant reason to make changes, the FSF
will be releasing something that looks very much like this draft on
June 29. So this would be a good time for anybody who is concerned
about this license to take a final look at the license text
with an eye toward finding any last-minute problems.
There are a few significant changes that went in this time around, and one
which did not. The current draft contains this language:
You may not convey a covered work if you are a party to an
arrangement with a third party that is in the business of
distributing software, under which you make payment to the third
party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who
would receive the covered work from you, a discriminatory patent
license (a) in connection with copies of the covered work conveyed
by you (or copies made from those copies), or (b) primarily for and
in connection with specific products or compilations that contain
the covered work, unless you entered into that arrangement, or that
patent license was granted, prior to 28 March 2007.
The final part is the "grandfather clause" which exempts the
Microsoft/Novell deal from this restriction. In the previous draft, the
FSF had mentioned the possibility of removing that clause, causing the full
power of that language to apply against Novell. That, in turn, would have
made it hard (or impossible) for Novell to distribute software licensed
under GPLv3. According to the FSF, it now seems that it is better to let
Novell distribute this software than to prohibit it:
Microsoft is scrambling to dispose of as many Novell SLES coupons
as possible prior to the adoption of GPLv3. Unfortunately for
Microsoft, those coupons bear no expiration date, and paragraph 6
has no cut-off date. Through its ongoing distribution of coupons,
Microsoft will have procured the distribution of GPLv3-covered
programs as soon as they are included in Novell SLES distributions,
thereby extending patent defenses to all downstream recipients of
that software by operation of paragraph 6.
If this reasoning holds up, any Microsoft patent which can be said to be
infringed by GPLv3-licensed software distributed by Novell will, in
essence, be licensed to the free software community. It seems too good to
be true, but the people who are arguing this point should know what they
are talking about.
The definition of a "user product" - the sort of product to which the
anti-DRM provisions apply - has changed somewhat. The previous draft used
a reference to a U.S. law, which was not entirely well received in other
parts of the world. The new draft says, instead:
A "User Product" is either (1) a "consumer product," which means
any tangible personal property which is normally used for personal,
family, or household purposes, or (2) anything designed or sold for
incorporation into a dwelling. In determining whether a product is
a consumer product, doubtful cases shall be resolved in favor of
coverage. For a particular product received by a particular user,
"normally used" refers to a typical or common use of that class of
product, regardless of the status of the particular user or of the
way in which the particular user actually uses, or expects or is
expected to use, the product. A product is a consumer product
regardless of whether the product has substantial commercial,
industrial or non-consumer uses, unless such uses represent the
only significant mode of use of the product.
The clear intent is to define most products as "user products," exempting
only a very few products from the requirement that "installation
instructions" be provided with the source. This requirement has always
been one of the most controversial parts of GPLv3, but the FSF has stuck
with it from the beginning.
The permissions for distributing copies have been broadened a little with
You may convey covered works to others for the sole purpose of
having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply
with the terms of this License in conveying all material for which
you do not hold copyright. Those thus making or running the covered
works for you must do so exclusively on your behalf, under your
direction and control, on terms that prohibit them from making any
copies of your copyrighted material outside their relationship with
In other words, having an outside contractor work on a modified,
GPLv3-licensed program does not force the distribution of the modifications
to that program.
Finally, this draft of the GPLv3 is considered to be fully compatible with
version 2 of the Apache License. This compatibility was achieved by
changing the interpretation of the Apache License slightly (in a way which
matches the Apache Software Foundation's interpretation) and by adding a
couple of permissible extra terms to the GPL. It is now possible to
require indemnification of upstream contributors and to require modified
works to be distributed under a different name. Since the Apache License
contains terms like that, allowing them under GPLv3 was essential if the
two were to be made compatible with each other.
The screaming which accompanied earlier drafts of GPLv3 is notably absent
this time around. A number of the issues which upset people have been
resolved at this point. And most observers understand that other
controversial terms - such as the anti-DRM provisions - are not going to
change regardless of how much criticism is directed at them. For better or
for worse, the GPLv3 process is nearly complete; soon it will be a matter
of seeing which projects make the change to the new license. To that end,
Richard Stallman has posted an
essay encouraging movement to GPLv3. Starting on June 29,
projects will have the option of following that advice.
Comments (13 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Firefox security status; New vulnerabilities in clamav, firefox, php, Sun JDK/JRE...
- Kernel: Fun with file descriptors; The thorny case of kmalloc(0); Wireless regulatory compliance.
- Distributions: Ubucon Boulder; Fedora 7 (Moonshine) released; Foresight Linux 1.3 released; Fedora 7 FAQ and reviews
- Development: The CACAO Java Virtual Machine project releases version 0.93, Fedora 7 adds KDE live CD, plans for Nepomuk-KDE, GCC adds ISO C++0x support,
biannual Haskell report,
new versions of BusyBox, dvdtoogg, jack_capture, Rotter, Matplotlib,
GNOME, GARNOME, gEDA/gaf, QLoud, Flycam, Qt and Qtopia Core, SPTK, Wine,
Mozilla Thunderbird, GNUmed, PyChem, dvdspanky, Firefox and SeaMonkey,
PHP, Emacs, libfishsound.
- Press: Why DRM won't ever work, the making of Shrek, Microsoft and software patents,
Palm launches Foleo, Linux laptops in Brazil, Darl McBride's deposition,
Groklaw examines the Xandros/MS deal, Eben Moglen videos, A look at JOST,
presentations with KeyJnote, reviews of MPD, TreeLine outliner,
and the Wizpy MP3 player.
- Announcements: Creative Commons retires licenses, Final call GPLv3 draft,
Atmel AVR32 for embedded Linux, Novell partners with Capgemini,
Sun compilers add multi-core support, Xandros partners with Microsoft,
Tanenbaum to receive IEEE Medal, BCS'07 CFP, 64 Studio workshops in UK.