By Karen Ngan, Partners and Averill Dickson, Senior Associates

In our June 2011 x-tech article, ' Making Open Source an Asset, and Not a Liability, In Your Commercialisation Strategy', we discussed some of the basic types of open source licences, and steps to take to ensure open source materials do not jeopardise the commercial exploitation of proprietary products. In this article, we look at some of the implications of open source licences in the cloud environment and, in particular, whether the terms of some popular open source licences adversely impact the ability to commercialise cloud computing offerings.

Open Source Software as a Key Enabler of Cloud-Based Computing

The last few years have seen staggering growth in cloud-based computing which shows no sign of slowing down.

Last month, Gartner predicted the personal cloud will eclipse the PC as the hub of consumers' digital lives by 20141. On the enterprise side, Gartner predicts worldwide software-as-a-service (SaaS) revenue reaching $14.5 billion in 2012, and $22.1 billion in 20152. This represents, for enterprise application markets, a predicted 17.2% compound annual growth rate through to 2015, compared with a total application market growth rate of 7.9%3.

Cloud services can bring down the infrastructure costs involved in computing, and using open source software reduces the costs further. Dion Hinchcliffe of ZDNET stated in 2009 that "open source has become a key enabler for cloud computing by providing both cheap inputs (as in free) as well as rich capabilities to providers of cloud services"4.

Permissive Licences and the GPL in Cloud Environments

In our previous article, we pointed out that "permissive free software licences", such as the Apache 2.0 licence, the MIT licence and the BSD licence, permit users to impose different (and more business-friendly) conditions upon the distribution of derivative programs. This applies equally in a cloud environment as it does for distributed software.

As a result, in a number of software investment, acquisition and licensing arrangements we have recently been involved with, we have seen a move away from blanket prohibitions against the use of open source software, and an increased willingness to allow the use of the software licensed under "permissive" licence terms.

We have not seen the same degree of relaxation in respect of prohibitions against the use of software licensed under the common GNU General Public Licence (GPL) (statistics show that close to 50% of open source software projects either version 2 or version 3 of the GPL5). The reason for this is the requirement that, where a developer creates and distributes programs that incorporate GPL materials, the developer must licence those new programs on the terms of the GPL. Therefore, they must also make the source code for the new programs publicly available.

However, this requirement does not necessarily apply in a cloud environment.

Under version 2 of the GPL (GPL v2), the on-licensing requirements are triggered by the act of 'distributing' a derivative work. It is arguable that, where a cloud services provider makes software available via a cloud-based deployment, the provider has not 'distributed' the software: the provider has simply allowed users to interact with the software via the internet. This could be viewed as a loophole, in that it allows people to commercialise new software developed using source code licensed under the GPL, without that new software being subject to on-licensing requirements, where the new software is available only via the cloud.

Version 3 of the GPL (GPLv3) makes the position even clearer. The on-licensing requirements of the GPLv3 are triggered by the act of 'conveying' a derivative work, and the GPLv3 specifically provides that merely interacting with a user through a computer network, with no transfer of a copy, is not conveying.


A few months after the release of GPLv3, the Free Software Foundation released an alternative licence to the GPL, the GNU Affero General Public License, or GNU AGPL. The GNU AGPL includes an additional clause under which, where a developer has modified GNU AGPL-licensed software, the act of allowing users to interact with that modified version remotely through a computer network triggers an obligation to make the source code available. The GNU AGPL contains the same requirements in relation to 'linked' software as the GPLv3; so if the software deployed in a cloud application contains, in its entirety or modified form, any GNU AGPL-licensed software then the source code for the entire running application must be made available to the community.

The Free Software Foundation recommends6 that people wanting to ensure their software remains free consider using the GNU AGPL for any software which will commonly be run over a network. Despite this, the uptake of the GNU AGPL has been slow. Black Duck's statistics as at May 2012 show 13,785 GPLv3 projects as against 411 GNU AGPL projects; GNU AGPL does not even appear on the top 20 list of open source licences in use7. Even in the cloud computing area where the GNU AGPL is specifically targeted, prominent open source cloud computing toolkits such as OpenNebula, Eucalyptus and OpenStack are licensed under the Apache or GPLv3 licences.


As a result, the majority of open source software and tools are likely to be available under licence terms that allow cloud computing providers to develop proprietary (closed) cloud offerings. Developers can also avoid any need to distribute source code for GPL-derived software through appropriate use of a cloud environment. The key is to understand exactly what software is being used in a project, and the licence terms that apply to that software.


6 18 May 2012.
7 Retrieved 18 May 2012.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.