The news that Oracle was proposing to donate the OpenOffice.org (OOo) code to the
Apache Software Foundation (ASF) came as a surprise to many, though it
probably shouldn't have. Many optimistically hoped that Oracle's plan to turn OOo over to an
"organization focused on serving that broad constituency [the OOo
community] on a
non-commercial basis" meant that it would turn to The Document Foundation (TDF),
which forked OOo into LibreOffice (LO) in September 2010, as the obvious
repository for the code. But, for a number of reasons, that was probably
never a very likely outcome; some discussions evidently took place between
Oracle and the TDF, but there seems to be enough bad blood—along with
licensing differences—that another home for OOo was sought.
Oracle proposed OOo as an Apache Incubator
project on June 1 with a post to Apache's incubator-general mailing
list. The original posting from Oracle VP Luke Kowalski was done as an
.odt file, which made it hard to comment on, so Greg
Stein posted the text of the proposal.
Shortly thereafter, it was turned into a wiki page
which has been updated to reflect the discussions about the proposal.
Other than the proposal itself, and a press
release with statements from Oracle, Apache, and IBM, there has been
little said by Oracle about this move. IBM, on the other hand, has been
quite vocal, with three separate, very favorable blog posts (Rob
Brill, and Bob
Sutor) that came out more-or-less at the same time as the proposal.
This seemingly coordinated response didn't necessarily sit well with some
in the OOo/LO community, but TDF had enough notice to put out its own statement
that was conciliatory, if disappointed.
Basically, Oracle has signed a license grant
to the ASF covering a list of files that make up OOo. That allows the ASF to
release the code under the Apache License.
Oracle will also be transferring the OOo trademarks to the foundation,
though there is a typo in the current transfer ("OpenOffice" rather than
"OpenOffice.org") that is currently being addressed. There are some
questions whether the listed files are actually all of those needed to
build OOo, but the belief is that Oracle will work with ASF to address any
The license and trademark grant is a "done deal", by and large, but where
things go from there
are still a bit up in the air. Apache has an "incubation" process that is
meant to help new (to Apache) projects come up to speed on how Apache
projects work and are governed. In addition, the incubation process is
meant to allow time to handle any licensing issues with the code (as all
Apache projects must be licensed under the Apache license), as well as to
determine if the project has attracted enough of a community to be a viable
project going forward.
As spelled out in the Incubation
Policy, the project must have a "champion" who is an ASF member. For
OOo, Sam Ruby will be the champion. In addition, there needs to be at
least one "mentor" from the ASF for an incubator project. For OOo, there
are eight mentors listed at the time of this writing. The role of the
mentors is to assist the project through the process by providing guidance
on Apache philosophy and policies. In order to get a sense for how much
interest there is in the potential "podling" (as accepted incubator
projects are called), a list of "initial committers" is being gathered in
the proposal. "Committers" does not necessarily imply developers as it is
meant to cover anyone who plans to do any kind of contribution to the
project. There are more than 60 people listed as initial committers at the
time of this writing.
Once the proposal is firmed up, a vote will be taken to determine whether
the podling is accepted into the incubator program. That vote will likely
happen quite soon, almost certainly before the middle of June. Based on
the discussions in the mailing list, it seems pretty likely that the
proposal will be accepted. The consensus seems to be that, while there may
be substantial barriers to overcome before the OOo project could become an
Apache top-level project, the incubation process is meant to shake those
problems out. If that doesn't happen, the project will eventually be
terminated, but there is no reason not to see if the problems can be
As might be guessed, that consensus (if consensus it truly is) used up a lot
of electrons to emerge. There are multiple 100+ message threads in the
mailing list that are discussing various aspects of the proposal. It is
not only ASF members who are participating either, as various TDF members,
OOo and LO community members, and other interested parties are chiming in.
For the most part, it has been a polite conversation, as various commenters
have been careful to steer the discussion so as to keep it on-topic and
congenial—asking that flames be taken elsewhere. But it's also clear
that there are some strong emotional undercurrents, at least partly because
the TDF/LO community feels somewhat slighted.
It's not surprising that they feel that way. TDF and its community have
done a huge amount of work in the last eight months to create a
meritocratic organization to foster LO. In addition, there has been a lot
of technical work done to clean up what is, by many accounts, a codebase
that has the potential to inflict eye cancer, as well as work to add new
features, set up build farms, and so on. Much of that work may need to be
redone by any Apache project, so it looks an awful lot like a waste of
effort to the LO community.
The bigger issue may be licensing, however. When TDF formed, largely due
to what it saw as mismanagement of the project, first by Sun then by
Oracle, it took the OOo code under the only license it could: LGPLv3. In
order to try to attract companies like IBM into contributing to LO, the
foundation asked that contributions be made with a dual LGPL/Mozilla Public
License (MPL) license. The MPL is a weaker copyleft license which requires
that changes to existing code be released, but allows extensions and the
like to be kept closed. By dual-licensing with the MPL, it would
still allow companies to release LO with proprietary extensions if they
could get a license for the LGPL-covered and Oracle-owned core.
At least one company has such a license, and that's IBM for its Lotus
Symphony products. Prior to Sun changing the license for OOo version
2, IBM released its proprietary OOo-based products using the earlier Sun
Industry Standards Source License (SISSL), which did not require that
code changes be released. After Sun dropped that license for version 2,
IBM had to negotiate a license separate from the LGPL so that it could keep
its code closed.
The only reason Sun could issue that license to IBM is because it always
required OOo contributors to grant Sun a joint copyright on the
contribution. That means that Sun, now Oracle, can do anything it wants
with the code, including licensing it for proprietary use. This
contributor license agreement (CLA), which essentially made for an uneven playing
field because only Sun/Oracle had certain rights, was another problem that
caused the LO fork. It should be noted, though, that the CLA is what
allows Oracle to grant ASF the right to release the code under the Apache
license. Without it, all contributors would have had to agree to the
change—which might have been logistically, and perhaps ideologically,
Ideology comes into play because there are two very different philosophies here
when it comes to free software: copyleft vs. non-copyleft. The Apache
license is a
non-copyleft license that, similar to the BSD license, allows anyone to do
what they wish with the code. The GPL, LGPL, MPL, and others require that
modifications be released under various circumstances. Copyleft licenses
restrict the ability of companies to keep parts of the code private, while
non-copyleft licenses have no requirements of that sort.
The belief is that companies are more likely to contribute when they can
keep some of their "secret sauce" to themselves. The BSDs have had some
success with that philosophy, though GPL-covered Linux is often held up as
a counter-example. It is Apache, though, that has arguably had the most
success with building communities of both companies and individuals around
The ASF is, quite reasonably, proud of its license and
accomplishments, so the ability to gain an Apache-branded desktop office
suite is rather attractive. That said, OOo is also not an obvious fit for
the organization. ASF has largely targeted server applications and, as
noted by several commenters in the mailing list, is accustomed to making
source-only releases. Users of OOo are unlikely to expect to have to build
their own binaries, so some kind binary release will be needed. For Linux,
this is less of an issue as there are distributions aplenty that will make
binary releases for their users if they decide to ship OOo; in the Windows
and Mac worlds—which
make up the vast majority of OOo users—it's a more difficult
It should be noted that, even in the Linux world, most major
distributions have switched over to LO, or plan to, so some kind of a
switch back to OOo would be required. Since many of the companies behind
the larger distributions are also TDF supporters, that kind of a change is
unlikely, at least in the near term.
One of the more optimistic conversations on the mailing list looks at ways
that TDF and
ASF could collaborate, without necessarily joining forces. Neither side
looks likely to budge on its license choice, at least in the near term, so
combining the two is simply not possible. There is something of an
imbalance between the two, though, because TDF can adopt any of the
Apache-licensed code (either Oracle's initial contribution or any further
changes), while an Apache project cannot adopt the LGPL/MPL-licensed
changes that TDF has made (or will make in the future). That one-way door
is inherent in the nature of non-copyleft licenses; not only can the code
be taken proprietary, it can be additionally licensed under a copyleft
Should the podling get accepted but fail to graduate to a top-level
project, the Apache-licensed code will be available and presumably TDF will
be the home of the community around the OOo/LO codebase. On the other
hand, if Apache OOo takes off and the LO community largely moves over to
the new project, one could imagine the LO code being re-licensed. The bulk
of the LO changes were done by companies like Novell, Red Hat, Canonical,
and others, so a change to the Apache license for those parts would just
require the strokes of a few pens.
The other plausible outcome is that both projects thrive—or at least survive—presumably each
smaller than the combination would be. The codebases would continue to
diverge to a point where they would be completely different office suites
that both natively supported Open Document Format (ODF). It would get
harder and harder for LO to adopt OOo changes because of the divergence, so
at some point, they would go their separate ways. That split is what
worries many, because it would probably result in two less-capable suites.
Others argue that competition between the projects may lead to both
becoming better—it certainly wouldn't be the first such split in free
Looking at how the two projects can collaborate is an avenue toward
avoiding the split, however. If the codebases could be kept in sync fairly
closely, and perhaps some LO contributions also licensed under the Apache
license, the divergence could be kept to a minimum. Whether the two
communities can work together remains to be seen, but there are proposals
for joint meetings and/or a summit of some kind. At least some cooperation
in the near term seems likely, but there are some big hurdles for Apache
OOo to clear.
Numerous challenges for the likely podling have been mentioned in the
threads, starting with the problem of creating binaries for end
users—along with the bandwidth and server requirements to support
those users. But
there is more to it than that. While there are numerous initial committers
listed for the project, from many different organizations as well as
individual contributors, the bulk of the full-time, paid OOo staff will, at
least initially, be coming from IBM. That worries some because IBM's
priorities could change at any time, which might lead to a podling without
enough of a contributor base.
There are also some questions about IBM's goals in pushing for an Apache
OOo project. The company was never a large contributor to OOo, even after
it joined the project with some fanfare in 2007. Many of its contributions
have languished, and not been merged into the OOo mainline. On the other
hand, IBM already has a license for the code that it needs so it's a bit
unclear why it would go to the trouble of pushing Apache OOo if it didn't
really have hopes of seeing a larger community grow up around it.
In addition, IBM doesn't have much of a track record in community-oriented
free software projects. It has certainly contributed to various projects
(notably the Linux kernel), but it lacks experience in leading a free
software community—at least one that isn't directly under its
control. Apache does have that experience, however, and has
policies in place to ensure that its projects are governed well (starting
with the incubator program itself).
There are also questions about external dependencies that may not be
available under an Apache license, which might necessitate disabling some
functionality or rewriting those pieces. Another missing piece from the
list of files provided by
Oracle is the translations that were done for OOo,
which may just be an oversight. The ASF folks posting on the mailing list
seem comfortable that these
things can be worked out as part of the incubation process.
As a number of people have pointed out, there is a certain irony to this
recent engagement between ASF, IBM, and Oracle. Apache certainly has
reason to be relatively unhappy with IBM because of its abandonment of the
Harmony project—something that has been cited several times as a
cautionary tale regarding OOo—and Oracle because of its unwillingness
to license the Java compatibility tests to Apache, which led to Apache resigning from the Java Community Process
executive committee. It is a testament to the pragmatism and maturity
of the ASF that it has seemingly not allowed those other problems to interfere
with the current OOo contribution.
It will be interesting to watch this play out. It is unfortunate in many
ways because an opportunity to fix the split in the OOo and LO development
communities has been lost—or at least delayed further. It is tempting to
speculate on what might have happened
had Oracle made this move, say, ten months ago. But it didn't, and it
owned the code, so it can make decisions that make the most sense for
Oracle and its partners. At this point it seems like a face-saving move by
Oracle, along with a poke in the eye to TDF, but it may be that Oracle has
contracts with IBM or others that require moving the code to an
organization with a non-copyleft outlook.
The decisions made by the podling going forward will likely give us a view
of how interested IBM and the OOo community are in working with LO. There
are presumably lots of cleanups that LO has done that could be adopted by
OOo (it's hard to imagine that code and comment removals, for example, are
covered by a
license). That would make it easier for code to move between the two
projects as it takes more than just compatible licenses (assuming some LO
contributors are willing to do that) to make that work.
There seems to be a belief that some part, perhaps a large part, of the OOo
community was left behind when TDF forked. Clearly Oracle employees were
left out (presumably by Oracle fiat), but that doesn't really change as
Oracle appears to have no
interest in the project once the transition is complete. Perhaps there are
constituencies that are not served well by TDF and will be by an Apache OOo
project, but the progress made by LO vs. OOo since the fork doesn't seem to
indicate that. We'll all just have to watch and see where things go from here.
Comments (30 posted)
At first glance it looks like a typo, but Webian is in fact an experimental, open
source desktop environment using Mozilla and Gecko as its core. Developer
Ben Francis made the first public release last week, spawning immediate
comparisons to Google's ChromeOS project, and even
inciting concern that Mozilla would draw the search giant's wrath for
wandering into its corporate territory. But Webian is Francis' personal
project, not underwritten or sponsored by Mozilla. It does, however, show
off some key concepts that the browser-maker is interested in promoting
— namely Mozilla's belief that HTML5 and open web standards are the development platform of the future.
Essentially, Webian is a small set of applications written on top of
Note that the name "Chromeless" refers to
Mozilla's long-standing habit of calling its existing user interface
layer "chrome," and is not taking a swipe at the Google browser.
It strips away the entire browser interface (including
the XUL and XPCOM used by Firefox) and replaces it with a layer written in
Last week, Mozilla Labs featured a guest blog post by Francis about the 0.1 release of Webian Shell, the basic "desktop" for Webian. The Shell is an integrated web browser that needs no other window manager or desktop trappings. It runs in full-screen mode, providing a "home screen," a row of tabs across the bottom, and a URL-and-title-bar across the top. Francis has been actively developing Webian since 2009, based on design concepts he cooked up while in college. The design concept document explains the scope and architecture choices in more detail than the project's wiki: the browser is the only application, there are stripped-down tools to access other functions (such as hardware settings), and only minimal borrowing from "thick client" desktop metaphors of ages past.
The 0.1 release is available in binary form for
Linux (32- and 64-bit), Windows, and Mac OS X, as well as source. Not
everything described in the design document is implemented yet; Webian
Shell works as a full-screen browser, but the home screen
sports only a clock and "shut down" button. Also missing is Francis' concept of "stripe" UI elements: notifications and queries that slip into place horizontally and stack on top of each other, pushing browser window contents down rather than layering on top of them. The goal, according to the design document, is to "remove the concept of 2.5 dimensions where possible and treat 2D as 2D."
It is important to note that Webian Shell by design runs on top of your
existing operating system. While it does run full-screen (for Linux, that
means it run over X, and does not interact with the window manager), it is
not a full OS stack like ChromeOS is. Thus, at the moment, you can use it
as a browser and a UI demo for the eventual desktop system, but not a
replacement for your complete environment. As a browser, it runs quite
fast — faster, it seemed to me, than did Firefox 4 itself. Partly that is
due to not loading Firefox extensions, but simply shedding the heft of Firefox's own interface seems to give a noticeable speedup (installed plug-ins, it should be noted, do run in Chromeless and Webian Shell).
Webian inherits its security model from Chromeless. The latest version
takes advantage of out-of-process plugins and out-of-process tabs (which
debuted in Firefox 4), so one page crashing should not crash the entire
app (or, in Webian's case, shell). However, Flash or Java hiccups in
one page may force the user to re-load other pages in order to re-start
a crashed plug-in. Privacy controls are another matter; Chromeless and Webian can
technically maintain separate user profiles just like Firefox, but the
interface for managing profiles is not yet implemented in Webian Shell.
Aggravatingly, at the moment several of the high-profile Google web services do not run in Webian Shell, due to an upstream bug in Chromeless that hits pages incorporating the X-Frame-Options HTTP header. Nevertheless, there are still plenty of functional web applications available in the wild, so you can can easily test out Webian Shell for long browsing sessions.
The long-term plan involves separate applications beyond the Shell, however. The project is working on desktop widgets for the home screen based on the W3C widget specification, and a photo management application that implements a local interface for tagging and organizing content, but still connects to remote, web-based services for publishing and storage. That choice is initially hard to get used to: the ChromeOS-like approach would be to write an entirely server-delivered photo organizer, then deliver it through the browser.
Chrome OS and other competition
Despite Webian's limited scope as a browser and (potentially) desktop environment, the comparisons to ChromeOS are inevitable. Francis' post on the Mozilla Labs blog led some online media outlets to describe Webian as a Mozilla project — an error Francis is quick to correct. He has received help and input from the Chromeless team (including work on the X-Frame-Options bug), but the project is not affiliated with Mozilla nor is he an employee.
Still, the project does line up quite closely with several of Mozilla's goals. It serves as an independent showcase for Chromeless, which is poised to take on a more prominent role now that Mozilla has announced the end of support for Gecko embedding APIs.
Mozilla is also pushing forward on the "installable web app" front,
through apps.mozillalabs.com. While Firefox support for these apps is
provided by an extension, native support built into a thin-client desktop
like Webian would arguably be a better demonstration of their value.
Google's Chrome team has independently developed its own installable web
app framework, with a
similar but not-quite-compatible manifest format for the browser to
consume. Francis said he would like to support both, although he would prefer that both parties come to an agreement on a common format.
Another feature discussed in the Webian design documentation is a command-line interface implemented in the Shell URL bar / text-entry widget: supporting search queries is the first order of business, but arithmetic, app launching, and natural-language questions have been discussed on the mailing list and discussion forum. As several people in the Webian community pointed out, this type of functionality is already available in Mozilla Ubiquity, so here again cross-pollination with another Mozilla-based project seems natural.
But to really stage a direct challenge to ChromeOS, Webian would have to be bundled with an underlying OS. At the moment, Chromeless does not have the access to low-level system hardware that it would need to provide the hardware control described in the Webian Shell plan (although Mozilla's Rainbow does show signs of life in that area). Thus, to develop into a full OS replacement, Webian would almost certainly have to leave cross-platform compatibility behind, and pick a single stack to build upon.
Linux is the obvious first choice, and Francis alluded to that future direction in an email. "How much of Webian's functionality will be cross-platform is an unknown at the moment. The priority will be to build a Linux-based version but if some level of cross platform support can be maintained that would be great."
Of course, whether or not a full Webian-based OS offering would be successful competing against ChromeOS is a different question entirely. Francis and the other contributors are nowhere near the point where they could push Webian as a commercial offering like Google is doing for ChromeOS. Several contributors make the argument on the mailing list that Webian's non-commercial approach makes it more trustworthy for end users, who may be concerned over Google's user-tracking activities, or simply unhappy with ChromeOS's lack of transparent and meritocratic development processes.
No doubt, that stance makes sense to many free software advocates, but it does not do the work of bundling Webian with a Linux-based kernel and providing it as an installable image. The other argument common to the list is that Webian (like Mozilla) is dedicated to full support of open standards. Consequently, for example, it will feature HTML5 video playback of royalty-free formats only, rather than supporting royalty-bearing formats as well.
Frankly, that is a highly speculative line of thinking anyway, and threatens to overshadow what Webian Shell showcases here and now. At the moment, it is a showcase for Mozilla Chromeless — an idea that the browser vendor has been arguing for for years without a visible product to demonstrate. The notion that desktops are dead and the web is the new delivery platform gets considerable airplay in the press, often including the refrain that the open source community is behind the times as its desktop wars rage on. But up until now, ChromeOS was the only end-user-targeted attempt to build a "web desktop" at all, and it was intimately entwined with the proprietary web services offered by Google.
Thus it is good to take a close look at Webian, if for no other reason that to put the notion of the "web desktop" to the test in a Google-free environment. Personally, I certainly hope it continues to push forward, and to accelerate development of some of Mozilla's "lab experiment" projects at the same time. It could serve as a valuable motivator for the free software community on the web services front as well. But if nothing else, it goes to show how lean and fast a Mozilla-based browser can be, once all of that chrome is stripped away.
Comments (10 posted)
Many words have been said about the relationship between the Android
project and the mainline kernel development community. At LinuxCon Japan,
James Bottomley took the stage to say a few more. There are, he said, some
interesting lessons to be learned from that disconnect. If the development
community pays attention to what has been going on, we may be better placed
to deal well with such situations in the future.
James started with the statement that Android is, hands down, the most
successful Linux distribution ever produced. Its adoption dwarfs that of
Linux on the desktop - and on the server too. Android's success is
spectacular, but it was achieved by:
- Forking the kernel,
- Rewriting the toolchain and C library,
- Developing a custom Java-based application framework, and
- Working from an extreme dislike of the GPL
In other words, James said, Android is a poster child for how one should
not work in the open source community. They did everything we told them
not to, and won big. While we would like the Android developers to change
and do some things differently, their success suggests that, perhaps,
Android is not the only group in need of change. Maybe the community needs
to reevaluate how it weighs code quality against market success; do we, he
asked, need a more commercially-oriented metric?
One of the big assumptions brought into this debate is that forking is a
bad thing. Android started by forking the kernel and writing its own user
space mostly from scratch, and the community has duly condemned these
moves. But it is worth understanding what the Android developers were
trying to do; Android started by finding adopters first; only then did they
get around to actually implementing their system. At that point, the time
pressures were severe; they had to have something ready as soon as
possible. There is a lot to be said for the development community's patch
review and acceptance processes, but they do tend to be somewhat
open-ended. Google couldn't wait for that process to run its course before
it shipped Android, so there was little choice other than forking the
Was forking the kernel wrong? In a sense, James said, it cannot be wrong:
the GPL guarantees that right, after all. The right is guaranteed because
forking is sometimes necessary, and rights are meaningless if they are not
exercised. In this specific case, without a fork, the Android project
would have had a hard time achieving its goals (with regard to power
management and more) in a commercially useful time. The result would have
been a delayed Android release which would have led to less success in the
market or, perhaps, missing the market window entirely and failing to take
off. Forks, in other words, can be good things - they can enable groups to
get things done more quickly than going through the community process.
Is forking equal to fragmentation, he asked? It is an important question;
fragmentation killed the Unix market back in the 1990's. James claimed
that forks which fail do not fragment the community; they simply
disappear. Forks which are merged back into their parent project also do
not represent fragmentation; they bring their code and their developers
back to the original project. The forks which are harmful are those which
achieve some success, carrying part of the community with them, and which
do not return to the parent project. From that, James said, it follows
that it is important for the community to help forks merge back.
The Android developers, beyond forking the kernel, also took the position
that the GPL is bad for business. The project's original goal was to
avoid GPL-licensed code altogether; the plan was to write a new kernel as
well. In the end, a certain amount of reason prevailed, and the
(GPL-licensed) Linux kernel was adopted; there are a few other GPL-licensed
components as well. So, James said, we can thank Andy Rubin - from whom
the dislike of the GPL originates - for conclusively demonstrating that a
handset containing GPL-licensed code can be successful in the market. It
turns out that downstream vendors really don't care about the licensing of
the code in their devices; they only care that it's clear and compliant.
What about Android's special application framework? James said that the
Java-based framework is one of the most innovative things about Android; it
abstracts away platform details and moves the application layer as far away
from the kernel as possible. The framework restricts the API available to
applications, giving more control over what those applications do.
Given the structure of the system, it seems
that rewriting the C library was entirely unnecessary; nobody above the
framework makes any sort of direct use of it anyway.
So maybe Android didn't do everything wrong. But there were some mistakes
made; the biggest, from James's point of view, was the lack of a calendar
which can handle SyncML. That made Android handsets relatively useless for
business users. One of the keys to the Blackberry's success was its nice
calendaring. Motorola had seen this problem and implemented its own
proprietary SyncML calendaring application for the Droid; that actually
made things worse, as business users would get an Android handset with the
idea that it would work with their calendars. If they ended up with
something other than the Droid, they would be disappointed and, eventually,
just buy an iPhone instead. Android had no SyncML support until 2.1, when
a new, written-from-scratch implementation was added. The cost of this
mistake was one year of poor corporate uptake.
The other problem with Android, of course, is its "walled garden" approach
to development. Android may be an open-source project, but Google
maintains total control over the base release; nobody else even sees the
code until Google throws it over the wall. No changes from partners get
in, so there is no community around the code, no shared innovation. As an
example, Android could have solved its calendar problem much sooner had it
been willing to accept help from outside.
Google's total control over Android was needed to give the project its
market focus. It was a necessary precondition for market dominance, but it
is bad for community and has forced Google to reinvent a lot of wheels.
Another big mistake was being sued by Oracle. That suit is based on
Android's rewrite of Java which, in turn, was entirely motivated by fear of
the GPL. Had Android been built on Oracle's GPL-licensed Java code base,
there would have been no suit; Google would have been protected by the
GPL's implied patent license. If Oracle wins, rewriting Java will turn out
to be a hugely expensive exercise in license avoidance. And the sad fact
is that the license is entirely irrelevant: the Java runtime's API
constitutes a "bright line" isolating applications from the GPL.
So what can be learned from all of this? James reiterated that forking can
be a good thing, but only if the results are merged back. The Android fork
has not been merged back despite a great deal of effort; it's also not
clear that the Android developers have bought into the solutions that the
kernel community has come up with. Maybe, he said, we need to come up with
a way to make merging easier. The community should have a better way of
handling this process, which currently tends to get bogged down in review,
especially if the fork is large.
Projects which create forks also need to think about their processes.
Forks tend to create not-invented-here mentalities which, in turn, lead to
a reluctance to show the resulting code. It's no fun to post code that you
know is going to be panned by the community. The longer a fork goes, the
worse the situation gets; fixing of fundamental design mistakes (which is
what wakelocks are in the community's view)
gets harder. Preventing this
problem requires forks to be more inclusive, post their code more often,
and ask the community's advice - even if they do not plan to take that
advice. It's important to open the wall and let ideas pass through in both
James talked a bit about "licensing fears," stating that the GPL is our
particular version of FUD. The discussions we have in the community about
licensing tend to look like scary problems to people in industry; less heat
from the community on this subject would do a lot of good. The fear of the
GPL is driven by outside interests, but we tend to make it easy for them.
The community should be more proactive on this front to allay fears;
pointing to Android as an example of how GPL-licensed code can work is one
possibility. The Linux Foundation does some of this work, but James thinks
that the community needs to help. The GPL, he said, is far easier to
comply with than most commercial licensing arrangements; that's a point we
need to be making much more clearly.
We should also design more "bright line" systems which make the question of
GPL compliance clear. The kernel's user-space ABI is one such system;
developers know that user-space code is not considered to be derived from
the kernel. Making the boundary easy to understand helps to make the GPL
The community should do better at fostering and embracing diversity,
encouraging forks (which can create significant progress) and helping them
to merge back. Currently, James said,
the kernel gets a "C - must do better" grade at best here. We only take
code from people who look like us; as a result, the Android merge attempt
was more painful than it needed to be.
Companies, in turn, should aim for "control by acclamation" rather than
control by total ownership. Linus Torvalds was given as an example; he has
a lot of control, but only because the community trusts him to do the right
thing. In general, if the community trusts you, it will happily hand over
a lot of control; that's why the benevolent dictator model is as common as
it is. On the other hand, companies which try to assert control through
walled garden development or by demanding copyright assignment from
contributors have a much harder time with the community.
In summary, James said, Android was a fiasco for everybody involved; we all
need to figure out how to do better. We need to find better ways of
encouraging and managing forks and allaying licensing fears. Projects
which create forks should be thinking about merging back from the outset.
Then projects which (like Android) are a commercial success can also be a
[Your editor would like to thank the Linux Foundation for funding his
travel to Japan to attend this event.]
Comments (92 posted)
Page editor: Jonathan Corbet
Next page: Security>>