Apache OpenOffice and LibreOffice both suffer from a legacy of ambivalent licensing, which they are addressing by rebasing the code. Photo: Shutterstock

The course of open-source software does not always run smoothly, especially when the development of software becomes entangled with broader corporate strategies.

Indeed, the complicated history and confusions of OpenOffice development, and the divisions between LibreOffice and Apache OpenOffice, provide a salutary lesson.

They show that however fine the intentions of a governing organisation such as Sun Microsystems might be, consistency and transparency of governance and licensing are vital to the long-term health and success of any free and open-source project.

When Sun Microsystems released the code of open-source office productivity software suite StarOffice to the open-source community in 2000, the company promised to create a self-governing foundation and to hand over the code to the control of the community. But ownership of the copyright on the code was retained by Sun, and governance of the project was kept inhouse.

OpenOffice.org (OO.o) could only be seen as an open-source project in the sense that the source code was visible. But neither the licensing nor the governance was transparent, and its subsequent progress never matched the ambition of its developers.

Ownership and tight control

Sun had a long tradition of contributing to and benefiting from open-source projects but always retained ownership and tight control. In the beginning Sun licensed the code of OO.o under a dual LGPL and Sun Industry Standards Source License (SISSL). The SISSL was a permissive licence and permitted reuse of the code in proprietary products by third parties.

By September 2005, Sun had dropped SISSL, but ownership of the copyright of the code of all contributors continued to be assigned to Sun. Ownership of the code allowed Sun to relicense and add patent indemnification to the software.

The code, nominally donated to the project under a copyleft licence, was relicensed to IBM as the base for Lotus Symphony, which was not a situation envisioned by the developers. IBM did not release amendments to the code.

Governance of OO.o was kept inside the company. Bug revision was slow and ponderous. Contributors became disillusioned, and came and went.

Novell created its own branch of OO.o, go-oo.org, to absorb revisions that were rejected by Sun for licensing reasons, and the branch became the default installation for all GNU/Linux distributions.

Contributions from third-party developers fell away, and OO.o never made the advances that were expected of it.

The sun goes down

When Sun was subsumed into Oracle in 2010, OpenOffice.org was low among the company's priorities.

After months of prevarication by Oracle and StarDivision, the community took the radical step of setting up the Document Foundation, a truly independent non-profit body on the model promised by Sun at the outset of the project, and forking the code to create LibreOffice.

The Document Foundation was a chance to redeem some of the failings of the past and to create a genuine code-sharing community.

Six months after the announcement of the LibreOffice breakaway, Oracle announced its intention to release the OpenOffice.org copyrights and trademark to the Apache Software Foundation. This approach too represented an improvement on the previous regime.

IBM backed the move and announced its future intention to make "an identical release of the Apache OpenOffice code under the Apache licence", but the danger of a replication of the code under another licence was that it set community against community, licence against licence, and Apache OpenOffice against LibreOffice.

LibreOffice had offered participation to both IBM and Oracle and was willing to relicense the code under a weak copyleft licence, the Mozilla Public License (MPL), to make it easier.

But its advances were spurned, and the Apache branch became IBM's favoured route. There were now two office suites, and both had increasing issues about the relicensing of the software.

Rebasing Apache OpenOffice

LibreOffice has the residual problem that while its preference is for a copyleft licensing regime, the copyright on the code it inherited from Oracle-Sun is still owned by Oracle.

So the LibreOffice developers have been considering the option of rebasing the LibreOffice code on the relicensed Apache code base, as the Apache licence allows for the rerelease of code under other licences.

"With the relicensing of the original OpenOffice.org code-base to Apache License 2.0 by Oracle," they reason, "we're now able to incrementally rebase our own code on top of that to offer a choice of licensing that does not only include LGPLv3 but also any of GPLv3.0+, LGPLv3.0+, and the AGPLv3.0+ that the MPLv2+ allows.

"This will also allow us to incorporate any useful improvements that are made available under that license from time to time."

There is a sound reason for this, as the developers state: "As we compete with our own code, licensed under an unhelpfully permissive licence, the MPL provides some advantages in attracting commercial vendors, distribution in both Apple and Microsoft app-stores, and as our Android and iPhone ports advance in tablets and mobile devices."

Dual licensing under LGPLv3+ and Mplv2+ allows LibreOffice to be ported to app stores which, for perverse reasons, allow copylefted MPL-licensed code but do not allow copylefted GPL-licensed code.

Apache OpenOffice's problems

However Apache OpenOffice has its own compications: the current release of Apache OpenOffice is based on the last release of Oracle OpenOffice.org. But IBM has since donated the code of Lotus Symphony to Apache with the intention of integrating Apache OpenOffice and Lotus Symphony, which is based on older versions of OpenOffice.org and includes several years of IBM customisations.

The next version of Apache OpenOffice is likely to very different to the current version of Apache OpenOffice, and the differences are likely to reach far into the code - because Lotus Symphony was never open source and the code was never released upstream.

In effect, both Apache OpenOffice and LibreOffice have the same issue, of rebasing the code to rectify a legacy of ambivalence in the licensing.