Koha community squares off against commercial fork

Koha is the world's first open source system for managing libraries (the books and periodical variety, that is), and one of the most successful. In the ten years since its first release, Koha has expanded from serving as the integrated library system (ILS) at a single public library in New Zealand to more than 1000 academic, public, and private libraries across the globe. But the past twelve months have been divisive for the Koha community, due to a familiar source of argument in open source: tensions between community developers, end users, and for-profit businesses seeking to monetize the code base. As usual, copyrights and trademarks are the legal sticks, but the real issue is sharing code contributions.

Koha was originally written in 1999 by New Zealand's Katipo Communications, spearheaded by developer Chris Cormack. Katipo was contracted to build an ILS for the Horowhenua Library Trust (HLT) to replace its aging (and Y2K-bug-vulnerable) system, and to release the code under an open source license. The name Koha is a Māori word for a reciprocal gift-giving custom.

The first public release was made in 2000. Over the years, Koha usage grew, and several businesses popped up to provide support and customization services for Koha-using libraries; as with many infrastructure applications, the ongoing support of an ILS is the real expense. An ILS not only serves as an electronic "card catalog" system for library patrons, but handles acquisitions, circulation tracking, patron account management, checkout, search, and integration with other cataloging systems for inter-library loan. Libraries do not change ILS vendors quickly or lightly.

One of these support businesses was US-based LibLime, founded in 2005 by Koha developer Joshua Ferraro. In 2007, LibLime purchased Katipo Communications' assets in Koha, including its copyright on the Koha source code, and took over maintenance of the koha.org web site. For several years, life continued on as it had before; koha.org was the home of the project, and LibLime participated in Koha's ongoing development as did several other support-based businesses, many individuals, and many libraries.

The fork

The first signs of trouble began to appear in mid-2009, when LibLime announced that it would be providing its customers with a version of Koha built from a private Git repository, instead of the public source code maintained by the community as a whole. Many in the community regarded this as an announcement that LibLime was forking the project, a claim that Ferraro denied. The company cited several factors as its reasons for maintaining a separate code base, including the need to deliver on Koha contract work on its own deadlines, lack of quality control in community code contributions, and customer data it could not make public.

Ferraro stated that LibLime would publish its enhancements to Koha, that it was "100% committed to the open-source movement", and that its integration with the main code repository would be "seamless." However, no such publication took place; as of today, the most recent source code for LibLime's products that is available on the web site are from June of 2009, and the LibLime source code repository remains inaccessible to the public.

LibLime's enhanced version of Koha is named LibLime Enterprise Koha (LLEK), runs on Amazon's EC2 cloud platform, and sports a list of features not present in the 3.0.2 "community" release. Meanwhile, the community has continued to develop Koha, making point releases to the 3.0.x branch, and is readying a major update in version 3.2.

Enough people in the Koha community were concerned about the project's future and about practical matters like the web site and Git repository that they decided to migrate to a new domain, koha-community.org, to be managed by a committee and legally held by Koha's original sponsors, HLT. Those migrating included Cormack, many other core developers, and several of the other Koha support vendors.

2010 started off with a ray of hope for commercial and community reconciliation, when Progressive Technology Federal Systems, Inc. (PTFS), another Koha support vendor, announced in January that it was acquiring LibLime. PTFS was a relatively recent convert to the Koha community; it started out as a proprietary-only ILS vendor catering to government and military institutions. But it selected Koha as its open source product of choice in 2008, in part for its ability to integrate with PTFS's profitable digital content management products. PTFS engineers had been active on the mailing list and IRC channel, and submitted patches back to the community, so the community was optimistic that they would continue to participate, and the LLEK fork would be merged back into the main branch.

In April, PTFS asked the community — developers, documentation and translation teams, release managers — to return to the koha.org domain, and set up a new repository with the intent of merging the code. As community members explained in the thread, they did not like those terms and instead asked PTFS to either turn the koha.org domain over to the community or to bring its code and participants to the koha-community.org site.

Unfortunately, what could have been a simple disagreement over hosting and domain name relevance deteriorated further. PTFS asked HLT's Koha committee for a conference call under a non-disclosure agreement, but the committee asked for a public email or IRC discussion instead. PTFS then responded with a press release (copied to the Koha mailing list) publicly criticizing the committee, calling it "new to business matters," "one-sided," and "inaccurate," and touting its own version of Koha as superior. Judging by the responses on the list, that action served only to further alienate the already-suspicious Koha community at large.

Code, Trademarks, Copyrights, and Names

Koha is far from the first project to go through such a divisive conflict. In fact, forks of free software projects are not wrong in and of themselves, and can lead to improvements in the code. What caused the major split between the Koha community and LibLime was the company's decision to keep its fork private and not give back. It promised to do so, but instead withdrew from the Koha community altogether.

Naturally there is no way to prevent individuals or companies from acting with hostility, but the Koha project was vulnerable to LibLime's behavior on a couple of fronts. First, as it recognized, LibLime controlled the ostensibly community-run koha.org site — prompting the community to re-launch the content in a new location.

What is more troubling is that, based on its actions, LibLime evidently believed that it had the right to create a closed-source fork of Koha due to its acquisition of Katipo Communications's Koha assets, including the latter company's copyrights. But whether or not Katipo's copyrights constituted the whole of Koha in 2009 when LibLime forked the project is questionable. Cormack and other developers point to the Git repository's commit statistics, which show the percentages by individual authors. How to interpret those statistics is an open question, but there was no copyright assignment required to participate in Koha development. In the absence of such an agreement, Koha contributors retain copyrights for their work; as a result, taking the code proprietary is not an easy option for anybody.

It is still unclear whether or not LibLime provided the full source code to its LLEK product to its paying customers, as is required by the upstream Koha project's GPLv2+ license. Koha is written mostly in Perl, which is presumably distributed in source form, but the GPL source requirement does include all the source necessary to build the software, include supporting libraries and compilation scripts — a requirement that might affect support libraries needed to support LLEK's EC2 environment.

Muddying the waters still further is the issue of who can legally call their code "Koha" at all. LibLime filed for a registered US trademark on the name in October 2008; it was granted in May of 2009. European support vendor BibLibre filed for an EU trademark on "Koha" in December of 2008; it is still undergoing review. Finally, LibLime filed for the Koha trademark in New Zealand itself in February of 2010; it too is still undergoing review. Yet "Koha" has been used as the name of the open source project itself, not a vendor package or support product, since 2000.

The Software Freedom Law Center's Karen Sandler said that such trademark-based disputes are common, enough so that SFLC has published a primer on the subject for projects. Without commenting on the specifics of the Koha situation, she noted that although registration constitutes "legal presumption of ownership," if another party can prove it was using the mark first, it retains the right to use the mark. In addition, she added,

The community's unstructured approach to the project in past years does not make up for PTFS's very public missteps, however. The company may indeed have meant to put the community back together into a functioning whole when it initiated talks about the web site, but it clearly underestimated the ire that LibLime had earned through its actions over the previous year, and the derisive press release would be considered a mistake under any circumstances. If there was any hope of drawing the larger Koha community back to koha.org, it probably died when that message went out.

Cormack observed on his blog that any vendor has the right to try and turn its Koha offering into a superior product for customers in order to increase sales — the harm was inflicted because of the way LibLime chose to carry out that business decision.. Whether you agree with that or not, however, it seems that the project would have been better equipped to cope with LibLime's withdrawal from the community had the domain name, trademarks, and perhaps even copyrights been held by a trusted entity such as HLT. Taking those legal steps is something few projects seem to consider when things are running smoothly. They are no doubt time-consuming and tedious, perhaps even expensive. But so is trying to do them in a hurry, ten years after the project launches, with hostile players going after your name.

[ Thanks to Lars Wirzenius for pointing us toward this topic. ]