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.