Open Source: The Affero General Public Licence

In their recent article ‘Open Source Software: Top Ten Licences’, Jones, Meenagh and Mewies provide an excellent table-form summary of the most commonly used open source licences. Interestingly, they include one extra licence which falls outside the ‘top ten’ requirement – the Affero General Public Licence (AGPL). This was included – rightly in my opinion – on the grounds that its use is ‘predicted to increase significantly in the next few years as Software-as-a-Service (‘SaaS’) providers move towards using open source rather than proprietary software’.

The application of the AGPL is, however, rather arcane even by software licensing standards, and as yet remains untested.

The latest version of the AGPL, version 3, essentially replicates the GPL version 3, but with an extension specifically applying to SaaS – that is, programs providing ‘remote network interaction’.[1] The Free Software Foundation, publisher of the GPL and AGPL licences, says examples of programs meeting this criterion are web and mail servers, interactive web-based applications and online games servers.[2]

The origin of the AGPL arose from a perceived loophole in the GPL and other licences regarding software used across a network (as illustrated in the table by Jones et al). Under the GPL, when software is distributed, the source code must also be distributed, thus allowing modification or incorporation into other software. But in the case of SaaS, it is not the software itself which is being distributed, but rather some functionality of the software.

A common example of this is accessing a Web site: the user receives the output of a program (eg a stream of HTML), but not the actual program generating the output (eg the web server). As the program itself is not being distributed, the provider of the service is not required to distribute its source code to users. Another example is Google, which uses open source software in its search engine but does not distribute the source code – indeed, it is kept a closely guarded secret.

While convenient for users, critics claim this situation is contrary to the spirit of the GPL.[3] Firms can benefit from open source software without returning their improvements to the community, which may not be the intention of developers who release their software under an open source licence.

That the GPL does not expressly address SaaS is not surprising; earlier versions of the GPL were developed before the era of the web and online services. Today, the use of SaaS is becoming ever more popular. Web-based email and word processing tools are examples of software now commonly provided as an online service as opposed to via an installable application.

The AGPL aims to close the SaaS loophole by introducing a requirement that modified source code must be provided to users of the service. The essential provision of the current version (AGPL version 3, clause 13), states:

‘… your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version’.

The Free Software Foundation initially considered closing the SaaS loophole in its latest update of the GPL but decided instead to promote the AGPL as a separate licence, allowing developers to choose whether to impose the additional requirement of the AGPL and providing easy identification for users.

An example of the AGPL in action is the Prime Minister’s e-Petitions Web site (http://petitions.number10.gov.uk). A link is provided on the FAQ page to allow users to download the source code, which may be freely modified or reused on the same terms.

For businesses, the most common encounter with the AGPL is likely to be in the context of a Web site. Many Web sites use an open source content management system (CMS) to provide the framework and management tools for the site. If the CMS is licensed under the GPL (or similar), a firm can modify the CMS as required without the need to provide the source code, as long as this involves simply using the software to provide a Web site and not distributing the CMS software itself. Thus the modified CMS is essentially a private, in-house project.

However, if the CMS is licensed under the AGPL, the modified source code must be made available to users who access the Web site (to everyone in the case of a public Web site).

The AGPL is not without controversy.

There is debate about whether the AGPL is overly onerous for those who simply want to modify open source code for the purpose of providing a publicly-accessible online service or Web site.[4] The AGPL will in such cases force the modifier to release every update of what may be thought of as an in-house project, albeit with a public interface. Contrast this with the GPL which, according to the Free Software Foundation:

‘… does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them’.[5]

Whether the AGPL will therefore discourage the use of particular code remains to be seen. Certainly, it does introduce an additional obligation on licensees beyond those in the GPL.

But with the increasing growth of SaaS, where the distribution of software is of less relevance than the service it provides, the AGPL may be an important factor in ensuring the continued feedback of modified code to the community.

 

Guy Burgess is an IT lawyer and software developer: grb@ihug.co.nz