Cloud computing easily ranks on par with Web 2.0 as a “term that means whatever we want it to mean” (i.e. meaningless). And try explaining the difference between cloud computing, software-as-a-service, network computing and ASP. So it’s arguably both meaningless and redundant.

Clearly, though, it is beloved by marketing departments. Interestingly, the term “cloud computing”, which only started gaining popularity in late 2007, hasn’t reduced “software as a service” in searches while becoming the dominant buzzword, as illustrated here (Google Trends):

It will be interesting to see how other NZ ISP’s and web hosts respond. Anything that promotes competition between, and awareness of, homegrown providers will be a good thing. It is surprising that most of the Kiwi companies I have talked to about cloud computing (well, it is catchy) have only ever mentioned EC2 or Azure, even though their main customer bases are in New Zealand.

The AGPL arose from a perceived loophole in the GPL and other licences regarding software used across a network. (I’ll refer to this as software as a service for the purposes of this article even though, like “cloud computing”, I find the name rather inapt sometimes).

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”. The Free Software Foundation, publisher of the GPL and AGPL licences, says examples of programs meeting this criteria are web and mail servers, interactive web-based applications and online games servers (here).

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 simple example is a website. The user receives the output of a program (e.g. a stream of HTML), but not the actual program generating the output (i.e. the web server). As the program itself is not being distributed, the provider of the service is not required to distribute their source code.

Another example is Google, which uses open source software in its search engine, but does not distribute the source code – indeed, Google’s source is kept a closely guarded secret.

While convenient for users, critics claim this situation is contrary to the spirit of the GPL. They say that firms can benefit from open source software without returning their improvements to the community, which was probably not the intention of developers who release their software under an open source licence.

That the GPL does not expressly address SaaS is not surprising; version 2 of the GPL was developed in 1991, before the Internet services era (for most people at least). However, with the huge rise in the use of SaaS, the loophole will become an increasingly important issue.

The AGPL aims to provide a way of closing 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 (wisely) decided instead to promote the AGPL as a separate licence, allowing developers to choose whether to impose the additional requirement of the AGPL.

Few projects use the AGPL at present, though this will doubtless increase. One live example is the UK Prime Minister’s e-Petitions website. – see the link on the FAQ page to download the source code.

Update: a local example of an AGPL-licensed site is ScoopIt, but it does not appear to provide a facility to download its source code.

For users, the most common encounter with the AGPL is likely to be a website content management system (CMS). 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 they are simply using the software to provide a website and are 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 website (e.g. everyone in the case of a public website).

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 website. 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, as the Free Software Foundation says:

“… 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.”

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.

This is an edited version of an article of mine recently published in Computers and Law magazine in the UK.