LWN.net Weekly Edition for June 7, 2007

Looking forward to Fedora 8

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 list 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 Thorsten Leemhuis:

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

Comments (1 posted)

Whose project is it anyway?

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

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

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 Handhelds.org, Inc."

France claims that GPE and Opie were always trademarks of handhelds.org and the registration is just to clean up the legalities of the matter:

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 show no activity of consequence at handhelds.org since April whereas the LTG list 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 resolution 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)

Last call for GPLv3

The Free Software Foundation has announced the release 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:

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:

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:

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 this language:

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)