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
- 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
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,
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:
IMHO, a properly functioning governance body *should* be so
effective that no one cares much either way when it comes time to
replace the membership. From my perspective, low turnout means low
dissatisfaction. All other indicators seem to point to continued
success for Fedora and its contributors...
I myself almost didn't vote. Why? Because I liked the entire
slate of candidates.
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:
What I mean is that almost all Fedora related decisions come out of
Red Hat anyway. The few +1 from community seats during FPB meetings
don't matter, do they? They are just noise.
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)
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:
1. A method for interfacing an object oriented software application
with a relational database, comprising the steps of:
- selecting an object model;
- generating a map of at least some relationships between schema in the
database and the selected object model;
- employing the map to create at least one interface object associated
with an object corresponding to a class associated with the object
oriented software application; and
- utilizing a runtime engine which invokes said at least one interface
object with the object oriented application to access data from the
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
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:
Upstream developers receive a perpetual, fully paid-up,
royalty-free, irrevocable worldwide license to the patents in suit
to engage in any and all activities with respect to a predecessor
version of a Red Hat product. Those developers also receive a
perpetual covenant not to sue with regard to all of DataTern's and
Amphion's other patents on claims related to Red Hat products.
The press release adds:
The settlement also protects derivative works of, or combination
products using, the covered products from any patent claim based in
any respect on the covered products. Essentially, all that have
innovated to create, or that will innovate with, software
distributed under Red Hat brands are protected, as are Red Hat
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:
The settlement should encourage the open source community by
providing broad protection as to the patents covered by the
agreement. More generally, the settlement demonstrates Red Hat's
commitment to standing up for the community against patent
aggressors. We believe it will serve as a precedent that should
discourage future similar cases.
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
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)
The already crowded open source mobile phone software market just got more
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.
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
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
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
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
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
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
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.