I alluded to this in an earlier blog post: it’s a turbulent time for the Koha community. So far BibLibre has been publicly discreet about this, but we think that it’s now time to put our version forward.
In short, as long time members of the Koha community and an open source support company, we want to make it clear that contrary to recent publications, LibLime is indeed forking Koha. We truly believe, as do many others, that the actions of a single vendor will have no impact on Koha itself as an application, and a short term impact on the community: at best, it has gotten the community to build a proper organization, which would be a nice outcome from this bump in the road
It is important to us at this point to make it clear that we are and will be members of the Koha community, we will not go in LibLime’s direction. More on that later.
So, the question becomes, what is and had been happening?
LibLime, little by little, retreated from the community, participating less and less on the discussion lists, the #koha IRC channel and other community venues, then started contributing less and less code to the software itself. To sum it up: we saw this coming for some time, and finally, in September, LibLime announced they had a new offer: LibLime Enterprise Koha (LEK).
What is it? A version of Koha containing features only available through LibLime, “LibLime bonuses”, so to speak, and only available in a version hosted by LibLime – which means you cannot download that version. LEK is a Koha-based system, with special features, which will have its own cycle of development, that’s a fork; For now, it’s (say) 80% Koha and 20% LibLime, but with time, the two versions are bound to diverge, each following its own path and calendar, and we’ll end up with an application with, say, 20% Koha and 80% LibLime. I.e. another ILS
Is it legal for LibLime to do this? It is: the GPL license that Koha uses is not well suited to an environment “in the cloud” and the new, LibLime-only version is available only in a hosted version and thus never actually released: LibLime uses a loophole in the GPL to circumvent the license. But then it’s a constraint for LibLime too: this version cannot be locally installed, or else it’s GPLed again, and thus available for all to download.
What do we make of this?
We share on this point the analysis made by Chris Cormack. Forks are quite normal in the life of many Open Source projects and should not be drama. One project will go quicker, slower, will select different technical options, will rejoin the main branch overtime, etc. It’s a part of the life of an Open Source project. No big deal. But the spin put on this by LibLime is not good:: you can’t have it both ways, i.e. fork and deny it at the same time. And that’s really unnecessary: forking is a business decision on the part of LibLime: they have every right to take this decision, and we respect that.
What is BibLibre’s position on this?
We respect LibLime’s business decision to fork. We don’t think it makes much business sense, though. The line separating the proprietary from the open source vendor is thin enough that you can’t walk on it: you’ll fall on one side very soon. But we have our doubts as to the chances of an Open Source vendor becoming a successful proprietary vendor: they’d leave out precisely the things which made them successful in the first place, i.e. representing a different value proposition for libraries. BibLibre will not make that mistake: there are many reasons why a business can fail (or succeed), but BibLibre will not fail because we would cease to believe in what we do: we provide open source support for libraries, that’s who we are.
BibLibre will continue to release the developments we write to the official version of Koha. The work we do is public. Available. Downloadable. GPLed. If you’re curious, you can see it early at http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=shortlog;h=biblibre-integration or, in an even earlier stage, at http://git.biblibre.com/cgi-bin/gitweb.cgi?p=koha;a=summary
BibLibre decided we needed to modify our standard hosting contract to close the GPL loophole used by LibLime: in our future contracts, and when the current contracts are renewed, an extra article is added to the contract which specifies that even though the software is hosted, the library has access to the source code, GPLed.
BibLibre wants to push libraries who call us to do development work, for Koha or any other piece of software, to write in the RFP itself or the contract that all the code produced will both: have an open source license; and be accessible on a public repository
Because there was no legal entity representing the Koha community, BibLibre ended up being the “owner” of koha-fr.org domain name and the “KOHA” trademark in France and the European Union). We always said we were keeping these assets in the name of the community. And indeed we never used those assets in any way. But that’s enough: the “LibLime case” renders this position untenable and we very much want to unload ourselves of those assets on the community. Which is in the process of organizing itself. There’s a poll that will be open through Sunday (25/10) for all to vote on. We’ve prepared the paperwork to transfer the assets we have, at no charge whatsoever, to the entity selected by the community to receive them – next week. And we ask LibLime to do the same – next week.
In summary
This is a crisis of growth for Koha, certainly. Teenagers, you know… But we’re confident that something very interesting will come out of this: a vibrant, structured community to help Koha grow further in the future.
