Oracle donates OpenOffice.org to Apache

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's contribution

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 Weir, Ed 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 deficiencies.

Apache incubation

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 worked out.

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.

Licensing

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, difficult.

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 non-copyleft code.

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

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.

Possible outcomes

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

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

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.

Challenges

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.