Koha Community Considers Affero License

The cost of a book is more than what you pay for it. If you intend to keep it, as libraries do, you need to pay for a shelf to put it on, some space in a building to put the shelf in, air-conditioning for the building so the book doesn't rot away, and some labor and assorted administration expenses to make sure you know where it is.

Similarly, the indirect cost of an electronic resource, whether it's a piece of software, an ebook, or a database can also be significant. You don't need a shelf or a building, which can save you a lot of money, but you may need some computing hardware or some space on a hard drive. Usually, there's a license, and it's easy to overlook the cost of managing it. The cost of license management can be substantial in institutions, even if it's negligible for individuals. Institutions need to minimize liability exposure and monitor compliance. At the very least they need to be aware of what licenses they've agreed to.

When my startup began providing services to libraries, I was very grateful to discover a resource called the CLIR/DLF Model license. This had been produced through discussions between university libraries and academic publishers, and by copying and adapting the model license, I saved money on legal fees. I'm sure that the libraries I dealt with also saved, because my license agreement looked just like many others they had seen. Lawyers are expensive, so a new or unusual license can rapidly generate legal bills comparable to the license fee itself.

I am amazed how many publishers that deal with institutions fail to understand the expense burdens (and thus, barriers to sale) that license agreements can put on potential customers. To pick a trivial example, state universities often have to abide by state laws that prevent them from agreeing to choice of law provisions that lawyers put in contracts by default. The time spent going back and forth on things like this benefits no one. Tacked-on provisions almost never add value and almost always causes expense.

Using a standard license is of particular importance when the license seeks to accomplish something creative. Such is the case with the licenses drafted by the Free Software Foundation (FSF). These licenses, the GNU General Public Licenses, seek to use copyright law to enforce "copyleft". When you release software with copyleft, the recipient is free to redistribute the software so long as they use the same copyleft license to do so. In the ideology of the FSF, this allows for freedom for users of the software. It's ok for you to charge for the software, or for using the software, but it's not ok to prevent users of your code from improving it and passing along those improvements for others to improve again. Non-copyleft licenses are less restrictive. The "Apache" license, for example, only requires the licensee to release the licensor from any liability or warranty, respect the trademark of the licensor and to retain the attribution and license in any redistribution.

There are currently three flavors of GPL licenses, each with its own set of restrictions. The least restrictive of these is the " GNU Lesser General Public License" (LGPL). This license allows the licensee to redistribute the software as a component in larger works, including proprietary software, as long as any alterations inside the component are released under LGPL. The GNU General Public License, or GPL, is more restrictive; you're not allowed to use a GPL work as a component in proprietary software, as any software linked to the work must also use GPL. Both the LGPL and GPL have been around long enough that any lawyer who works with software will be familiar with their benefits, drawbacks and limitations.

The Affero License

A newer FSF license is even more restrictive than GPL. The GNU Affero General Public License, or AGPL, requires licensees to release the source code for any improvements if they are used to deliver networked services. The AGPL is designed to facilitate the release of software that works "in the cloud", for example, in a "Software as a Service" configuration.

To understand the benefits of AGPL, suppose that you have developed software that does optical character recognition (OCR). Your business deploys the software over the network- images come in and text goes out. If you released the software under GPL, your competitors would be entitled to use your code, add their improvements and use them to deliver a competing service, without having to release those improvements. Since they don't redistribute the software, GPL's copyleft provisions don't kick in. Under AGPL, they could still run a competing service, but would have to release their improvements. You could use those improvements in your own service. Both you and your competitor can benefit from the resulting virtuous cycle of improvement.

These benefits do not come without cost, however. Compared to GPL, the Affero license is relatively new and untested; this can result in increased costs for licensees, and the license may prove to be unenforceable in practice. The added restrictions of AGPL put additional burdens on licensees who use the software to deliver network services. This is to your benefit if you want to pursue a dual licensing strategy such as the one pursued with such success by MySQL. The developers of MongoDB, for example, have chosen to use AGPL as part of this strategy.

Using AGPL may not be the best choice, however, if you hope to soon attract a diverse community of deployers-developers. Few corporate development processes have been designed with the requirements of code release simultaneous with deployment in mind. When I released software as open source, there would always be a bit of "sanitization" before final release. My pre-sanitized source code comments were always too rude and too meager to show in public. An AGPL-aware process would have resulted in better code, but perhaps less sleep. Familiarity with AGPL and better support in integrated development environments is likely to improve corporate acceptance of AGPL over the next few years.

Another application where AGPL will be inappropriate is software that needs to integrate proprietary components. Enterprise "portal" software will often need to hook into a variety of systems many of which have non-public APIs. GPL software can be used with care in this situation, because copyleft provisions are only triggered if derivative works are distributed.

The recent controversy surrounding the "Thesis" theme for WordPress is illustrative of the boundaries of GPL copyleft. Usually, when you use some GPL software as a platform, you don't expect that works using the platform would, by themselves, trigger GPL's copyleft. For example, if you change a presentation template and HTML code in a database-driven website system, you don't expect that your templates would have to be governed by GPL as well. Thesis does more that just change HTML, it also changes some PHP code used by WordPress. While the controversy is yet to be resolved, it seems to me that WordPress's developers have a strong case. Update (7/23): the Thesis developers have decided to GPL the part of Thesis that is clearly derivative of WordPress.

Would anything have been different if WordPress had used AGPL instead of GPL? If we assume that the distribution of Thesis violates GPL, then any similar modification of WordPress, even if you just run it on your own site, would trigger copyleft and you'd be forced to make source of your modification available.

Koha's License

When the developers of Koha, an Open-Source Library Management System, first released their code, they chose GPL as their license. The copyleft provisions appealed to them because they believed that the library community should share development just as they share books. Since at least 2002, the license distributed with the software has specified GNU GPL version 2 (or later).

Last year, many of the original Koha developers were upset when it emerged that the largest Koha support company, LibLime, had decided to pull out of the public development process for their Software-as-a-Service offering, LibLime Enterprise Koha (LLEK), and delay the release of their improvements and modifications. I wrote three articles about this situation in the early part of this year. For the current discussion, the important thing to note is that LibLime was perfectly entitled to do what they've done. Since they've not redistributed the software they are running, they have not triggered the copyleft provisions of GPL.

Since my last article, the acquisition of LibLime by PTFS was completed. In May, PTFS released (using the GPL license) a package of its improvements to Koha. The distribution, labeled "Harley", can be downloaded and run by anyone, the changes are being absorbed by the community; most of the enhancements and bugfixes are scheduled for merger with the 3.4 community version of Koha. According to PTFS, a much larger set of enhancements, developed as part of development contracts such as one with WALDO, is in the pipeline for release.

Nonetheless, there remains considerable friction and animus between PTFS-LibLime and the rest of the Koha Community. This friction has culminated in a call to change the license for Koha to AGPL. Participants in a IRC chat meeting decided to call a vote on the possible license change, to take place sometime this summer. The choices on the ballot are to be:

1. Stay with GPL version 2.1 or later.
2. Change to GPL version 3 or later.
3. Change to AGPL version 3 or later.

The electorate is to consist of any individual who self-identifies as a Koha stakeholder. While that may seem to be a simple choice, it turns out that changing a GPL license is not as easy as having a vote. To do so legally would require the affirmative assent of each and every contributor to the software. If poor records have been kept as to the contributors, it is virtually impossible to legally change the license. In the case of Koha, the source code record is reasonably complete. For example, the opac-main.pl script was touched by users Chris Nighswonger, Henri-Damien LAURENT, Nahuel ANGELINETTI, savitra.sirohi, Chris Cormack, Galen Charlton, Joshua Ferraro, Frederic Demians, Paul POULAIN, hdl, tipaul, toins, bob_lyon, kados, rangi, acli, finlayt, and tonnesen. It seems unlikely that the contributors associated with LibLime would agree to a licence change that would force them to change their preferred development process.

GPL version 3 is not compatible with version 2, but since most of the Koha code appears to allow version 2.1 or later, it should not be a major problem to change to version 3. However, should enforcement of version 3 provisions ever be required, questions about the license status could complicate enforcement. The significant new additions in version 3 concern the use of patents and hardware locks to subvert license terms.

AGPL is another license entirely, not a new version of GPL. However, it is allowed to include GPL works as components in an AGPL licensed work. It is NOT allowed, however, to include AGPL components in a GPL work, just as it is not allowed to include GPL code in an LGPL work. I assume this is the mechanism that AGPL-Koha proponents advocate for changing the Koha license. Section 13 of the AGPL states:

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

For this to work, a new work (not a copy) to contain the Koha work (licensed under GPL) would have to be created and licensed under AGPL. In my view, this would be too far a stretch to be allowed under the GPL License. If the license used for Community Koha or any of its components was changed to AGPL, I would strongly advise anyone considering use of Koha to first seek legal advice to determine whether such use is a license violation. (I am not a lawyer!) It would be a shame, in my opinion, if libraries were forced to incur this expense. Nicolas Morin, who led the French Koha support company BibLibre until his recent move to PRES de Toulouse gave me a very practical view of this issue:

I think focusing on the legal aspects of Koha, the copyright, TM and license, kind of misses the point. The problems Koha faces are much more mundane : lack of clarity and focus. Project management issues are real, legal issues are pretty theoretical at this point. I feel it's a bit of a distraction.

I'll add more information here about the IRC-called vote when it becomes available.

Branches of Koha

An arborist recently came to look at the white oak tree in my back yard. The tree is about 80 years old and is the biggest in the neighborhood. According to the arborist, our tree was in excellent health because of its large number of leaders, or main branches. Even in the strongest wind, these leaders will bend and a few might even break, but the tree itself is very unlikely to topple. Some neighbors have a very tall, scary tulip tree with only one main branch. I fear it will come down one day very suddenly.

In my discussion of Koha and LibLime (part 1, part 2), I promised to write more about the so-called "forking" of the Koha development process. What happened was that about 10 months ago LibLime stopped participating in the the Koha open development community. According to Josh Ferraro, LibLime's CEO, this happened because LibLime developers were having trouble completing development projects that LibLime had committed to doing for customers. Together with his development partners, Ferraro judged that LibLime's developers were spending too much time providing support to non-customers and that the overhead of the community development process was slowing down development more than it was contributing to LibLime's development objectives.

This judgement is hotly contested by developers advocating a open community development process. (See, for example, this post by Chris Cormack, or Owen Leonard's post on the Koha List.) It's not hard to imagine that an open community might pose difficulties during focused development. Two coders may disagree about how a task is to be done, and depending on personality and skills involved,  such disputes might easily become major time-sinks. Implementing a feature important to US libraries might break a feature important to European libraries, for example, and making both features work at the same time might be a lot of work. On the other hand, a small community such as the one working on Koha can ill afford to fragment into factions and start working at cross purposes.

When one branch of code diverges too far from another, the branches can become incompatible, or forked. When this happens, effort applied to one branch may have to be duplicated for the other branch. Forking is a common occurrence in open source projects, and can be evidence of a project's health. Such a fork in the Linux kernel came to light just last week, as some drivers added to support Google's Android system were deleted from the project's main tree. The downside is that forks increase the maintenance burden. It's often worthwhile for developers to work hard to join their code to a main branch so that others can maintain the contributed code and keep it from breaking.

Open Source projects can be motivated in many ways. Some projects have their origin in proprietary software, when the developers decide their businesses would benefit from wider adoption or support. Or perhaps the emphasis of the developer's business has changed. Etherpad is a recent example- the company was acquired by Google, whose main interest was to improve Google Wave rather than to continue the Etherpad service.

Other Open Source projects arise as "calling cards". That's how IndexData started doing Open Source. Sebastian Hammer, IndexData's Founder and President, told me that when he started, he just wanted his software to be widely used. His business was primarily custom development, and companies who were using his software because it was free began using his company for development because the free software worked well.

Only a small percentage of open source software projects are supported by more then just a few developers, and even fewer survive without an acknowledged lead developer. Koha has been blessed with significant contributions from a number of developers (and it uses free open source components such as Apache, MySQL, Perl, PHP and IndexData's Zebra).

You can imagine that Koha contributors outside LibLime would be very upset at LibLime's withdrawal from community development. Their contributions to the project were made with an understanding of Koha as an inherently community-driven effort for the benefit of all Koha libraries, and LibLime's withdrawal from the community process implicitly minimizes the value of their ongoing contributions. In fact, several contributors within LibLime were upset at the changes, and are now working for competing companies.

The fact of competition among Koha project participants inevitably leads to conflicting incentives. While proprietary software creates incentives for vendors to compete for initial sales with a robust platform and advanced features at the expense of ongoing service, open source software creates incentives for companies to focus on service and custom development. A company that puts a lot of effort into the core software may gain no advantage from that work if it has competitors which instead focus on services. Competitive considerations may certainly have been an important factor in the manner of LibLime's withdrawal from the community process.

It's interesting to see the messaging that LibLime's competitors used to respond to LibLime's withdrawal from the community development process. These ranged from the sunny "Equinox Promise" to a pointed post from BibLibre and a worried post from ByWater. There is clearly a struggle among all these companies to resolve the tension between competition and the need for cooperation that underlies Open Source support businesses. (Note: Equinox supports a different library system, Evergreen, so it's not so directly competitive with LibLime. Update Feb. 11- Equinox announced its entry into the Koha support market.)

Another reason given by LibLime for the change in its development process was that they wanted development customers to be able to test and approve new functionality before it would be released to the world. In the words of a LibLime press release:

"A public software release of each version of LibLime Enterprise Koha will occur periodically, after the sponsoring library and LibLime's customers have had adequate time to ensure that the codebase is of sufficient quality and stability to be contributed back to the Koha Community."

One Koha developer described this rationale to me as "nonsensical" and pointed out that the code quality seemed to be good enough for LibLime production customers. A look through the Koha developer wiki gives the impression that an elaborate QA process has been built by the community; I don't know how well it is followed.

My perspective, as someone who has managed a development project of similar scope, is that testing and quality assurance require a fair amount of disciple and attention to process. Getting developers to comment their code, do proper testing, and keep documentation up to date (i.e. adhere to a documented QA process) is not always easy, even if you're signing their paychecks. So while I have little insight into whether LibLime's new internal development processes are in fact resulting in better or more timely code, I think that the explanation given is at least plausible.

Managing a software development project is really, really hard. A lot of people imagine that their success in managing one project is evidence of superior process or ability, when really they were just lucky to have the right people at the right time. So I'm really skeptical when someone says that "community development" is the best way to build software, or that "agile methodology" is the one true way. In the real world, development managers may have the skills to succeed in one style of development (or group of developers) and be lacking in the skills needed to succeed in another style.  Software development projects only work if they work. In the case of the two branches of Koha, only time will tell whether one branch will wither and die, or whether two branches will end up diverging, both healthy.

While the people in charge at LibLime and PTFS have been in no position to comment on what they will do before their transaction is complete, other Koha stakeholders that I talked to were "hopefully optimistic" that PTFS would ultimately decide to rejoin the community development process and help reunify the Koha code base. PTFS developers have been active with contributions during the period that LibLime has pursued separate development. At ALA Midwinter, PTFS' John Yokley emphasized that a decision as to the extent of PTFS participation in Koha community development had not yet been made. In the meantime, Koha stakeholders other than LibLime have launched a new website to be the "Temporary home of the Koha Community."

 (Update Feb.12 - the acquisition is not happening.) (Update Mar. 16 - the acquisition closed after all.)

You can look at my tree analogy in two ways. You could say that having multiple branches of the Koha code is good for the project, as it is for my oak tree. You could also say that concentrating development of Koha in one company is dangerous, and worry about it as I do about the tulip tree.

Or you could just be happy that spring is coming and buds are already appearing on the trees.

This is the third part of a series. Also see Part 1 and Part 2

Who Owns Koha?

In New Zealand, Maori customs are taken seriously. For example, in 2002, the route of a new highway through a swamp had to be altered because it was believed that three taniwha - Karutahi, Waiwai, and Te Iaroa - lived there, and were being disturbed by the road, causing an unusual number of accidents. Taniwha are mythical beings that act as guardian spirits. Many taniwha arrived in New Zealand as guardians of specific ancestral canoes and then took on a protective role over the descendants of the canoe's crew.

Another Maori custom, one that has crossed over into general New Zealand culture, is that of "koha".  "Koha" is often translated as "gift", but according to Chris Cormack, one of the original developers of the Free Open-Source Software (FOSS) Library System with the same name, a more accurate translation would be a "gift with expectations".   Cormack got his B.A. degree in both mathematics and Maori Studies, so he should know. A koha is gift that is offered with an expectation that it will be reciprocated.

In the U.S., (and to a lesser extent, in Europe) it's our lawyers that we seem to take seriously. And so when we let people use software that we've developed, its not enough to offer it as a koha, we have to use a legal license to spell out the terms of the release. The license that has become popular because of the expectations of reciprocity built in to it is the Gnu Public License (GPL).

Software released under the GPL cannot be thought of as an unconditional gift by its developer. GPL software is not in the public domain, it is copyrighted. A copyright owner can exert control over the use of the copyrighted material; the GPL uses that power to require licensees to publish any modifications they make if they want to redistribute the modified work.  When the Horowhenua Library Trust was choosing a license to use for Koha (the library system software), they chose GPL (version 2) because they thought it would prevent Koha from being further developed as non-open software.

Included in the recently announced (but not yet completed) acquisition of LibLime by PTFS were Koha-related assets, including source code copyrights, trademarks and the koha.org website. It may be difficult for the casual observer to understand what value these assets have, especially in light of the GPL license attached to Koha. Could these assets be used to privatize Koha in some way? The short answer is "No", but it gets complicated.

Some FOSS companies use "dual licensing" as a business model. They release their code under GPL, but if another company wants to use the software in a way that would not be allowed under GPL, it has the option to pay for a commercial license. Dual-licensing can only be done by the original copyright owner. Index Data has used this model for years to the great benefit of libraries everywhere. MySQL AB is an example of a company which was extremely successful with this model; it was acquired by Sun Microsystems for about a billion dollars. (See this article for an overview of how GPL licensing fared in Oracle's subsequent acquisition of Sun.)

The GPL makes it very difficult, however, for anyone to change licensing terms after software has been released into the world. That's because of the way copyright law determines the copyright holder of derivative works. In general, if I take a piece of software that you have written, and modify it in such a way that involves creative effort on my part, then I own the copyright to the changes that I've made and the resulting work is a derivative work that both you and I have a copyright interest in. Even though you are the original copyright holder, you would need my permission to release the derivative work under any license other than the GPL.

Unlike Index Data's software, Koha has included significant contributions from many developers, including many who have never worked for LibLime or Katipo Communications (which sold its copyrights to Koha source code to LibLime in 2007). So although LibLime probably owned clear copyright to a majority of Koha at some point, Koha is still a collective work locked into GPL, version 2, and it is unlikely that LibLime or PTFS would be able to distribute Koha under terms other than GPL without doing a thorough rewrite of the software.

Trademarks are a different story. LibLime owns the US trademark for Koha; a European trademark is held by BibLibre. Trademarks are frequently used by open source projects to prevent splintering. The excellent primer on legal issues by the Software Freedom Law Center puts it this way:

FOSS applications develop reputations over time as users come to associate an application’s name with a particular standard of quality or set of features. Trademark law can help protect this relationship of trust and reliance that a project develops with its users; it allows the project to maintain a certain amount of control over the use of its brand.

Since GPL and other FOSS licenses allow anyone to modify and distribute software as long as the license conditions are met, they frequently spawn variants. The owner of a trademark can prevent these variants from using the trademarked name, and thus enforce unity in a project.

In the case of Koha, there are currently two parallel tracks of development being pursued, one inside LibLime, and the other by the community of developers outside LibLime. I will have to postpone a discussion of the issues surrounding  these development tracks to yet another article, but for now, let's just assume there will be two main versions of Koha, LibLime Koha and Community Koha. In the US, LibLime could theoretically prevent anyone from  using the name "Koha" without its authorization, and could strip Community Koha of the right to use "Koha" in its name. In fact, LibLime and BibLibre threatened to use this power a year ago to regulate PTFS's use of Koha trademarks in the marketing of its Koha support services. Liblime could even apply the Koha name to non-Open Source software. Similarly, BibLibre could regulate the use of the Koha name in Europe, preventing LibLime from marketing LibLime Koha there.

Based on discussions I've had with the leaders of almost every open-source library system company, I think it is unlikely that there will be any such "trademark war". Even if the development of Koha continues on separate but related tracks, the success of every Koha-based company is tied to the success Koha as a whole, and vice versa. It would be advantageous for every stakeholder if the two trademark owners develop some sort of "big tent" system of Koha trademark governance. Assuming PTFS's acquisition of LibLime is completed, such governance will need to be acceptable to both PTFS and BibLibre, and will need to accommodate differing styles of software development.

Until a general agreement on the use of Koha trademarks is reached, Koha stakeholders would be well advised to recognize that collective copyrights tie them into the same canoe and that they should avoid disturbing the taniwha that guards and protects them.

This article is the second part of a series. Part 1 is here. Part 3 is here

PTFS to Acquire LibLime and Move to Library Systems Premier League

Update Feb.12 - the acquisition is not happening. 
Update Mar. 16- the acquisition closed after all.

In 2009, the New York Yankees had a payroll almost ten times that of the Florida Marlins. The reason that baseball lives with that disparity is that the financial interests of many owners do not align with their fans- they take in roughly the same amount of money no matter what the team's performance.

It's different in the English Football Leagues. Teams which fall to the bottom of the standings in the Premier League are relegated to the second division, the equivalent of baseball's minor leagues. At the same time, the best teams in the second division are promoted to the Premier League, giving them a chance to make much more money. There is a clear alignment between the interests of the fans and the owners.

The library industry has likewise been troubled by misalignment of interests between the owners of the companies and their customers. That's why it's important for libraries to pay close attention to the frequent mergers and acquisitions of the companies that serve them. These transactions are often announced just before an ALA meeting, and this past weekend's ALA Midwinter Meeting was no exception.

The big story of the weekend was the pending acquisition of Koha support vendor LibLime by PTFS (Progressive Technology Federal Systems, Inc.). (The acquisition is still in the due diligence phase and is expected to close in early February; terms were not disclosed.) The surprising part of the announcement was the sudden emergence of PTFS, which has had a very low profile in the library industry, into the top tier of integrated library system vendors.

Here I must digress to discuss a bit about business models in the library industry. Libraries have traditionally viewed their catalog system vendors as long term partners; the migration of data from one system to another is a major project, not lightly taken, and preferably not attempted more than once a decade. The choice of a new system touches almost all the library's processes, and thus involves many consultations and lengthy RFPs.

From the vendor's point of view, the sales process is very expensive. Promises to customize the system to address customer peculiarities are common, and these add to the cost of system maintenance. Once the system has been sold, a proprietary system vendor has a guarantee of continuing profits from support contracts. Only the vendor has the system knowledge (and sometimes even the system access) to make even the most trivial changes. It's in the support phase that the vendor and customer interests can become misaligned. The vendor has every incentive to do the least work at the highest price possible. The customer is locked into whatever system they have chosen.

Companies with strong cash flow have been attractive acquisition targets for private equity firms. Once acquired the company's new management focuses on eliminating expenses by cutting support staff and cleaning up the balance sheet by offloading liabilities such as unfinished development, thus making the company very profitable. The company can them be resold at a good mark-up. Customers often become very unhappy during the process. The company they "hired" during their system selection process transforms into something different.

The recent popularity of open source library management systems is in large part a search for business models that better align the interests of vendor and customer during the support phase. If the support vendor doesn't perform to the library's expectations, the library can hire a new support vendor without ditching their automation system. If a library wants to add a new feature to their system, or integrate it with a system from another vendor, they can hire a developer based on qualifications rather than access to source. The important thing to the library is not so much the access to source or the cost of the license, it's the absence of vendor lock-in.

The reason that PTFS is not widely known is that it specializes in an obscure segment of the market- it supports libraries predominantly in the government and the military. Founded in 1995, PTFS has been installing ILS systems, doing conversions and supporting systems in the unique security environment of government systems. John Yokley, a co-founder and the CEO of PTFS, spent 13 years as a Sirsi system administrator and programmer at the U.S. Courts, NASA, and University of Virginia Health Sciences Library has spent 20 years, 5 more than the age of PTFS, working in the library industry. Yokley himself worked in a government library for a short period in the early 90’s designing and building virtual library technology.. The company has experienced steady 20% per year growth and today has 120 employees. PTFS is particularly proud of their development of the US Government Printing Office's Federal Digital System (FDsys) which supports over a thousand libraries, but the company also has a library staffing component and a digitization facility.

Although PTFS has had a strategic partnership with SirsiDynix to market ArchivalWare, a digital content management system that grew out of technology developed for FDsys the Naval Research Laboratories (NRL) TORPEDO project, it found itself hamstrung in supporting its customers because of the lack of access to source code of the proprietary systems it was supporting. About 18 Months ago, PTFS decided that Koha was the Integrated Library System that it could most easily integrate with ArchivalWare, and it began to offer support for Koha. Koha is generally considered to be the first open source integrated library system; it was initially developed in New Zealand by Katipo Communications Ltd. and first deployed in January of 2000 for Horowhenua Library Trust.

LibLime (which is actually a trade name of Columbus, Ohio based Metavore, Inc.) was started in 2005 by Joshua Ferraro, Tina Berger and two others. LibLime has been the hardest-charging and fastest-growing proponent of the Koha Library System in the world. Over the intervening years, LibLime has acquired key Koha-related assets, including the US trademark, copyrights to Koha source code, and the Koha website. The combination of PTFS and LibLime will be supporting 640 installations of Koha under 123 contracts. The combined business will have Koha-related development contracts totaling $1.7 million. Despite the state of the economy, LibLime has actually had an increase in business over the past few months.

Recently, Ferraro and his co-principals at Metavore became very interested and excited by an opportunity outside of the library space. As the LibLime business grew, they recognized that they couldn't pursue both the new opportunity and LibLime, and they began to look for an acquisition partner. PTFS was the first company they went to. Given the reasons for the sale, only Ferraro among the Metavore principals will remain with LibLime; and he will stay only for 18 months to oversee the completion of planned development.

PTFS will keep the LibLime name and fold its own Koha support business into LibLime, which will be run by Patrick Jones. At the press conference held at ALA Midwinter in Boston, PTFS CEO John Yokley indicated that PTFS was committed to the concept of user-driven development and the open source concept, but also emphasized that he was still learning about open source and he was reviewing the LibLime business model; there is much left to be decided about how the LibLime business will move forward.

I spoke with Yokley afterwards. In his conversations with LibLime customers, he has found that their top priority for adopting Koha was to avoid vendor lock-in: their systems should be expandable by LibLime, the library or by another vendor. He sees Koha as a component of a fully capable integrated library system, and vowed that in two years, Koha will be fully capable of running a major academic library. The integration of Koha and ArchivalWare will be only the first phase. Although his team has discussed making ArchivalWare into an open source project, there are issues with third party components used which may prevent that from happening.

Yokley's clarity on avoiding vendor lock-in will be reassuring to customers, particularly with respect to LibLime Enterprise Koha (LLEK), a service announced by LibLime in September of 2009. LLEK is perhaps the most exciting asset being acquired by PTFS, and also the most controversial. The controversy deserves another article entirely, as it represents a break between LibLime and other developers supporting Koha. I plan to write that article in the coming week; please e-mail me if you wish to comment.

LLEK represents the evolution of LibLime's entry into cloud computing (also known as "software-as-a-service". Unlike vendors whose idea of cloud computing is simply to offer fully hosted services, LibLime's implementation of the cloud is more in line with that of modern "lean startups" who don't even own their own servers. By using Amazon EC2, LibLime has access to instantly expandable, low cost computing resources. LibLime is able to provision, configure, and implement a new Koha server in less than an hour. To accomplish this, LibLime has developed sophisticated deployment software (which it does not intend to release).

PTFS is already doing a sort of software-as-a-service, building private clouds for its military customers who don't have the option of going out on the open internet. As Yokley explained to me, "Economies of scale are an interesting thing. We've had a few large customers, but now with LibLime, we can provide services to large numbers of small libraries."

Welcome to the big leagues, PTFS!

This article is the first part of a series. Part 2 is here. Part 3 is here.