LWN.net Weekly Edition for June 26, 2008

Notes on the Fedora board election

The Fedora Project recently held an election to fill four seats on its governing board. This is the first vote to happen since Red Hat decided to let the community elect the majority of the board's members. The results of this vote surprised the Fedora community in a couple of ways, leading to an extended discussion on how this community should be governing itself - and whether it can do that at all.

In the end, Tom Callaway, Jesse Keating, and Seth Vidal were elected to the board for two release cycles, and Jef Spaleta for one cycle. The fifth elected seat is currently held by Matt Domsch; three of the appointed seats are currently held by Bill Nottingham, Karsten Wade, and Harald Hoyer. Red Hat has not yet announced who will be put into the fourth appointed seat. The newly-elected members are all well-known Fedora contributors who have done a lot for the project. So why are there questions? It comes down to two points:

• Three of the four representatives elected to the board are employed by Red Hat. So, while Red Hat has given up its ability to directly appoint the majority of the board, that board will still be dominated by Red Hat employees.

• Of the 4069 Fedora community members who were entitled to vote in this election, only 250 actually turned in ballots. A 6% turnout strikes many as being somewhat lower than one would expect from a fully-engaged community.

Though nobody said so directly, some people apparently suspected that Red Hat employees voted in rather larger numbers than anybody else, and that they duly elected some of their own to fill the board seats. The truth of the matter is probably not so simple; what we are seeing is a middle stage in the Fedora Project's ongoing effort to become a more open, community-oriented effort.

A few possible reasons for the low turnout were put forward. One had to do with how the election was conducted. The self-nomination process evidently does not sit well with some people, who would rather see candidates nominated by their peers. The range voting mechanism used by the project seems complex and intimidating - though it still seems simple compared to the Condorcet scheme employed by Debian. There were also some complaints that the election was not run in a sufficiently high-profile manner, to the point that many community members might not have known that an election was underway at all.

Greg DeKoenigsberg put forward a different hypothesis to explain why so few people voted:

In this point of view, everybody is so happy that there's no need to get involved in the process. There is a contrary point of view which is also worth considering, though:

By this line of reasoning, instead of everybody being happy, the community is in despair and sees no point in participating in a process which seems unlikely to change anything.

The truth of the matter is almost certainly somewhere in between. The Fedora project has clearly opened considerably in recent years, to the point that it is one of the most transparent and active distributions out there. The community contributes a lot of work and certainly participates in discussions about the future of the project. But Red Hat still holds considerable sway; the fact that it employs a great number of Fedora developers is, by itself, enough to ensure that.

Red Hat's large presence is also enough to explain the large number of Red Hat employees elected to the board. Those are the people who have the luxury of working on Fedora full time; it is not surprising that they tend to be the most prominent developers in the community. Additionally, there is a certain tendency for outsiders who become strong community members to eventually become Red Hat employees as well. Red Hat has been increasing its investment in Fedora and hiring a number of people to work on it; the fact that they would be inclined to hire people who are already doing good work with Fedora should not be surprising.

So when Fedora developers look at a ballot and think about the names found there, chances are good that they will vote for the people they have seen working hard and accomplishing things within the community. And those people, at this point, are likely to be Red Hat employees. Until a time comes when other companies find it worthwhile to pay full-time Fedora developers, this situation is not likely to change much.

The free software community is full of examples of company-dominated projects. The bulk of these projects are subject to a high degree of control by the sponsoring company. That is natural; these companies have specific needs which they expect their development projects to meet. Making such projects truly open can be hard. Red Hat has gone farther than many in its efforts to make Fedora open, even if said efforts have come later than some would like.

Hopefully Red Hat will continue to follow that path, but, to a great extent, the next steps have to be taken by others. When the investment into Fedora from outsiders exceeds Red Hat's investment, Red Hat will be less of a dominant force. Until then, efforts to increase the number of people voting board elections - while being worthwhile and welcome - are unlikely to significantly change the results of those elections.

Comments (10 posted)

A belated look at the Red Hat/Firestar patent settlement

On June 11, Red Hat announced that it had reached a settlement in the software patent lawsuit it was defending against Firestar Software, Inc. and DataTern, Inc. This settlement is of interest to the community; it may point toward how how such cases may go in the future. Unfortunately, the amount of information which has been released so far leaves as many questions as answers, including the fundamental question of whether this settlement is as good for the community as Red Hat is claiming.

The suit involves patent #6,101,502, which claims the concept of creating an impedance-matching layer to connect relational databases to object-oriented applications. The first claim reads like this:

One might well wonder how object-oriented programmers managed before 1998, when this patent was filed. Firestar claimed that a piece of JBoss violated the patent and duly filed suit; Red Hat has been fighting back ever since. The June 11 announcement appears to bring an end to this particular dispute.

While Red Hat has not agreed that it was in violation of this patent, the company did not reach a settlement which clears it of infringement. Instead, Red Hat agreed to license the patent for itself and for its customers. The thing that makes this settlement a little more interesting is that Red Hat did not stop there; it also obtained a license for the project's upstream developers. From the settlement FAQ posted by the company:

The press release adds:

So, in other words, this license and covenant covers the "predecessor versions" of any package shipped by Red Hat. Once a particular project finds its way into RHEL, it's part of the deal.

This very carefully-worded text leaves one very interesting question open: what about users of the software who are not Red Hat customers? It would appear that developers are covered, presumably even as they develop the program beyond the "predecessor version" shipped by Red Hat. It has been made abundantly clear that Red Hat's customers are covered. There is a lot of text in the press release and FAQ suggesting that non-customer users should be protected too, but that is never said explicitly. An omission like that in a carefully-written, lawyer-vetted document can speak loudly; one must wonder what is going on.

Another interesting question is this: what about all of the other projects out there which are using object-relational glue layers? One can only assume that this set includes just about every object-oriented application which is using a relational database. The language makes it pretty clear that this patent has not been licensed for free software in general; it only applies to the specific piece of JBoss which was under dispute. The press release claims that the settlement covers derivative works, leading one to imagine that it would be possible incorporate some small function from JBoss into an entirely unrelated project and get the patent license with it. But there is no way to know whether this interpretation matches the real settlement or not.

And therein lies the real problem at this time: the actual terms of the settlement, and of the licenses and covenants, have not been published. One presumes that will change at some point; your editor queried Red Hat on when that might be, but did not receive an answer by the time this article was written. Without knowing what the actual agreement is, nobody can really assume that they have received any protection at all.

One other claim from the FAQ merits attention:

All of this is somewhat debatable, and needs to be questioned. As noted above, the actual breadth of the protection obtained is yet to be disclosed. The more relevant question, though, is: did Red Hat really "stand up for the community" in this case, and will it discourage these cases in the future? Your editor is not convinced of either.

The way to stand up against this patent aggressor would have been to invalidate the patent and put an end to it forevermore. A quick trip to your editor's bookshelf turned up David Taylor's Business Engineering With Object Technology, dated 1995, which discusses difficulty with relational databases and impedance-matching layers. Grady Booch's Object Solutions (1996) says: "Thus, it is reasonable to approach the design of a data-centric system by devising a thin object-oriented layer on top of a more traditional relational database technology." Or look at Object-Oriented Modeling and Design by Rumbaugh et. al. (1991), which has an entire chapter on mapping objects into relational databases.

In other words, there can be no shortage of prior art in this case; this is not an idea which was first conceived in 1998. But, rather than take this approach, Red Hat chose to settle. It is not said anywhere, but chances are good that some money changed hands here, and, by accepting a license for this patent, Red Hat has given it some legitimacy. Other free software projects - those which Red Hat does not ship - have apparently been left open to the same attack. Is this really the way to "discourage future similar cases"?

Of course, such criticism is easy to make from the sidelines; it's easy for those of us not directly involved in the suit to claim that Red Hat should have taken the higher-risk, higher-expense road and fought this case to the end. There is no doubt that such an approach would be better for the community - assuming Red Hat prevailed - but Red Hat's management must make its own choices about which battles it is to fight. Given that it chose to settle, Red Hat clearly tried to do the right thing by obtaining some sort of protection for the community beyond its customer base. Time will tell how well that will work out and whether it will serve as a model for future settlements or not.

Comments (19 posted)

Symbian to be another open mobile platform

The already crowded open source mobile phone software market just got more so as Nokia has announced plans to open up the Symbian operating system. Symbian currently has the biggest installed base of any mobile OS, which makes this announcement somewhat more surprising—market leaders generally do not radically change their successful methods. What it means for the various Linux mobile phone initiatives is unclear, but it certainly shakes things up a bit.

Nokia, along with many of the biggest players in the mobile phone market, has formed the Symbian Foundation to provide its members with the OS on a royalty-free basis. Several other components are being donated to the foundation as well, to create a complete platform for mobile applications. The plan is for all of the code to be released using the Eclipse Public License over the next two years.

In order to own the code, Nokia is purchasing the 52% of Symbian Limited that it does not currently own for more than $400 million. This will allow Nokia to donate Symbian, along with its S60 smartphone platform, which runs atop Symbian, to the foundation. Sony Ericsson and Motorola will donate their UIQ user interface layer, while NTT DoCoMo will donate its Mobile Oriented Application Platform (MOAP).

Nearly two dozen companies have come together to form the foundation, including handset makers, mobile carriers, and chip manufacturers. Interestingly, there is substantial overlap between Symbian Foundation members and those of the Open Handset Alliance—the umbrella organization for Google's Android effort—and the LiMo Foundation. Whether this reflects impatience with the pace of Android/LiMo development or just an effort to hedge their bets remains to be seen.

Membership in the foundation is open to all who are willing to pay the $1500 annual membership fee. That fee will allow the use of all of the components that make up the Symbian platform on a royalty-free basis. Any developers that wish to create software for the platform need not join as there will be a developer program available at no charge. The foundation is expected to start operations in 2009.

Opening up Symbian is seen as a reaction to Android and other free software efforts in the mobile phone space. One of the advantages touted for Linux solutions is the zero cost—particularly the lack of per-unit royalties. By moving Symbian to this model, the foundation undercuts that advantage. Because Symbian is already a dominant player in the smartphone market—with a large development community—there are some who believe it will redirect efforts currently focused on Linux to Symbian.

That remains to be seen, of course, but Linux-based smartphones are still in their infancy. MontaVista's Mobilinux has been installed in more than 35 million mobile devices, mostly in Asian markets, but, perhaps because of it being controlled by a single company, hasn't really generated a large developer community. It may also be targeting mobile carriers who are not very interested in allowing users to customize their phones—at least not to the extent Android and others envision.

There is a widening rift between the "free" and "locked down" camps for mobile devices. With this move, Nokia—and the other foundation members—seem to be moving toward allowing users more freedom, though undoubtedly some handset makers and carriers will opt for locking down their phones regardless of the openness of the underlying OS. One need look no further than the iPhone for an example of a tightly controlled application environment that is, at least so far, very popular with consumers.

In the long run, it is hard to imagine that mobile device users will be willing to stick with the limited choices of applications provided by their carrier or phone maker. As more open alternatives become available, there will be a pushback from handset buyers that will be harder for the carriers to resist. For many, their mobile phone is the most sophisticated computer they own and the history of personal computers would indicate that a thriving ecosystem of the third-party applications is an important part of the purchasing decision. That requires developers.

The current proliferation of open mobile phone software platforms is, in many ways, a battle for developer mindshare. LiMo, Android, and OpenMoko are all Linux-based development platforms that support multiple hardware devices, which should allow applications to run on many different mobile devices with minimal porting. How well that works in practice is still an open question.

For many of the established players in the mobile device market, Symbian is a known quantity. It has shipped on countless devices—its strengths and weaknesses are well understood. Turning it into a free software release will allow, at least potentially, members to move the Symbian code in the direction they want. But will that stop, or substantially slow down, the adoption of Linux-based solutions?

In order for that to happen, Symbian itself will need some kind of developer community, something like what currently exists for the kernel and user space applications on Linux. Whether the opening of the code will be enough to attract that community is an open question. It may be that developers at the member companies will be forced to form that community—something that could affect the bottom line.

One of the key problems that the various Linux-based efforts face is that of fragmentation. The vendors of royalty-based mobile platforms—primarily Microsoft and Palm—tend to point to the multiple incompatible Linux efforts as proof. They tout the control that a single vendor provides to ensure compatibility. Others, like Apple and RIM (maker of Blackberry email phones), do not license their software to others so they tightly control the hardware, which tends to avoid fragmentation.

Within a particular initiative, fragmentation is likely to be a very bad thing, but having multiple platform choices tends to provide healthy competition and thus help consumers. Over time, some of the current Linux-based platforms may fall by the wayside to leave fewer choices, but that will likely happen due to technical considerations, part of which will be determined by the third-party application developers.

One questions remains though: what happens with Qt, or more specifically the Qtopia Phone Edition? Nokia bought Trolltech early this year, at least partially for their mobile toolkit. Will they port it to Symbian and donate it to the foundation? They could, of course, port it but keep it separate, but that would seem to lead down the path toward fragmentation. It seems somewhat unlikely that they would change Trolltech's successful hybrid of GPL and commercial licenses, but before this announcement few thought that Symbian would be freed. Nokia has certainly adopted a more open-friendly stance of late—they clearly see it as a way to generate more business—so it certainly is not out of the realm of possibility.

While opening up Symbian may inhibit Linux adoption on mobile devices, it can only be seen as a good thing for consumers and the free software community as a whole. In many ways, it validates the free software development model along with the idea of freedom for users and developers. The competition between Linux and Symbian will also likely help both improve. Expect lots of interesting devices and applications in the next few years because of it.

Comments (15 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Leaking browser history; New vulnerabilities in fetchmail, gallery, kernel, ruby,...
• Kernel: A day in the life of linux-next; What's AdvFS good for?; Freezing filesystems and containers.
• Distributions: Debian Lenny and the Eee PC?; openSUSE 11.0 GM; CentOS 5.2; BackTrack 3; A report from the Debian Testing security team; GNOME Helping Hands Project; The NetBSD Foundation Moves to a Two Clause BSD License; FUDCon report
• Development: The Elastix PBX system, Realizing Jython 2.5, new versions of Midgard, nginx, aria2, GARNOME, Sylpheed, Gnash, libsmf, Chandler Desktop, Parrot, Python, Sphinx, Pydev, GIT.
• Press: Open Source Data Recovery Tools, Red Hat's virtualization initiatives, extended support for RHEL 4 and 5, clarinet-playing robot, reviews of Hotwire, OpenSUSE 11 and Wine 1.0.
• Announcements: Bitbucket launched, Liberty Alliance frameworks, NoTA open-sourced, EFF on Seer patent, Symbian Foundation launched, BSI OOXML action to be appealed, Black Duck on GPLv3, SLE 2008 cfp, IFIP conf cfp, make art cfp, EFMI open-source conf.

Next page: Security>>