Readers of Computers & Law should be familiar with open source software. Andrew Katz wrote an excellent article on the subject for the June/July 2006 issue of Computers & Law (Open Source: An Opening Resource), the text of which is available on the SCL website.

This article drills down into one of the significant issues identified in Andrew's article, namely "loads of different licences". As Andrew mentioned, the existence of more than 200 hundred different licences presents a challenge to any lawyer trying to understand open source licensing provisions.

In tackling this challenge, we have asked the questions "which licences matter?" and "which licences are we likely to encounter on a regular basis?".

In answering the first question, we sought guidance from the Open Source Initiative (OSI). The OSI maintains a list of licences which it has approved as compatible with the Open Source Definition (OSD). In July 2008 this list contained 72 different licences. While not an unfeasible number, the task of familiarising oneself with 72 different licences is a daunting prospect.

In answering the second question, we sought statistical evidence of actual usage of open source software licences within the open source community. According to Black Duck Software, in July 2008 more than 94% of open source software was licensed under one of 10 different licences. These are, in order of usage:

To view table click here

Assuming first that these figures are correct and second, that they remain reasonably constant over time, it seems reasonable to take the view that by understanding these top 10 licences, a lawyer can be familiar with the licences that govern over 90% of open source software currently in use. Accordingly we have produced a short guide to these licences. We have also included in this guide reference to the Affero GPL licence (AGPL), use of which is predicted by some commentators to increase significantly in the next few years as Software-as-a-Service (SaaS) providers move towards using open source rather than proprietary software.

Key issues in open source software licences

In preparing the guide we have focused on key questions that clients commonly ask in scenarios where they encounter open source software. These scenarios include, among others, use of open source software:

  • in an organisation that is a target in an M&A transaction;
  • in the development of a software product that a client may wish to bring to market;
  • in the procurement of software from a supplier; and
  • in the procurement or provision of SaaS.

In any scenario, a potential licensee of open source software is keen to know what they can and cannot do with the software. Can they modify the source code? Can they redistribute the object code? Can they charge a fee for redistributing the object code or providing ancillary services to the open source software? If they modify the code, are they obliged to make such modifications available to the wider open source community? If they incorporate the code into their own proprietary code, will they jeopardise the proprietary status of their own pre-existing code, and of later proprietary additions to that code?

We've taken these questions and have attempted to answer them for the top 10 licences identified above plus the AGPL licence. Obviously the list of questions is not exhaustive, but it should provide a useful starting point for anyone seeking to understand the key differences between these licences.

Guidance

As a first step in understanding these licences, it is important to consider the main distinction between simple permissive licences and restrictive licences. Permissive licences, such as the Apache Licence, the BSD Licence and the MIT Licence, impose few restrictions on the licensee. Restrictive licences, such as the GPL, the LGPL and the MPL, impose significant restrictions both on the licensee of the original open source software and on any subsequent licensees of modified versions of original open source software.

This key difference in approach between permissive and restrictive licences lies in the idea of "copyleft". Whereas copyright allows the author of software to prohibit others from copying, modifying or distribution their software, copyleft (which is a deliberate play on the word copyright) is a different approach to licensing. The author of software permits others to copy, modify and distribute it, provided that any resulting copies, modifications and distributions are licensed under the same licence terms and conditions as the original software.

A simple example which illustrates how copyleft works is given below:

  • Developer A writes some software code and releases it under the GPL;
  • Developer B takes Developer A's code, modifies it and re-releases it;
  • The copyleft provisions in the GPL require Developer B to also release her modifications to Developer A's code under the GPL.

Conversely, were Developer A to release his software code under a permissive licence, such as the MIT Licence, Developer B would not be required to release her modifications under the same licence. Developer B could choose to release her modifications to Developer A's code under any licence she chooses, be it another permissive licence, a restrictive licence, or a commercial proprietary licence.

The distinction between permissive and restrictive licences goes to the root of our analysis. Permissive licences crucially are compatible with the commercial proprietary software licences and therefore permit the licensee to incorporate open source software source code into proprietary source code. Restrictive licences are generally not compatible with proprietary licences. Therefore, use of software licensed under a restrictive licence is something that an organisation needs to be aware. It should consider the commercial and legal implications in any of the scenarios identified above.

Is the licensee permitted to modify the source code? Is the licensee permitted to redistribute the source code?

In order to be approved by the OSI, all of the above licences have to be compatible with the OSD. Two key principles of the OSD are:

"1. Free Redistribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale."

and

"3. Derived Works. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."

Accordingly, all of the above licences permit licensees to modify and distribute the source code of the open source software.

Will use of the source code in proprietary software present a risk to the copyright status of proprietary software?

This question has been touched on above. Whether or not use of open source software source code in proprietary software will affect the proprietary status of that software is a complicated issue which requires detailed analysis of:

  • the relationship between the proprietary software and the open source software; and
  • the terms of the licence under which the open source software is distributed.

However, as a rule of thumb, where the use of open source software licensed under a restrictive licence is present or encountered in a proprietary software distribution there is the need to consider the risk that the proprietary software may be affected, for example by being "embraced", by the terms of the restrictive licence and the need to carry out further technical and legal due diligence to identify whether or not the risk is material.

Is the licensee required to release modified source code back to the open source community, if it: (a) distributes it to a third party?; (b) does not distribute it to a third party?; (c) does not distribute it to a third party, but uses the software to provide a service to a third party over a computer network?

The second principle of the OSD states:

"2. Source Code. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge."

Accordingly, the distribution of open source software under a licence approved by the OSI requires the licensor to make the source code of the software available to the licensee for no more than a reasonable reproduction cost.

Using the distinction outlined above, restrictive licences allow distribution of modified open source software provided the software is licensed under terms the same as or similar to the original restrictive licence. Where a licensee modifies open source software licensed under a restrictive licence and seeks to distribute that modified code to a third party, they will be required to distribute the modified code under the terms of the restrictive licence, and accordingly make the modified source code available to that third party.

Where a licensee modifies open source software licensed under a permissive licence and seeks to distribute that modified code to a third party, they will not be required to distribute the modified code under the terms of the permissive licence. Even if they do so wish, they do not have to make the modified source code available to that third party (albeit, they are generally encouraged to make the source code available to the wider open source community).

Neither restrictive nor permissive licences require a licensee of open source software to make modifications to source code available to third parties where the licensee does not distribute their modifications to third parties. Generally, most OSI-approved licences agree that use of modified open source software internally within an organisation does not count as "distribution".

This has led some commentators to identify a "SaaS loop-hole" in the world of open source software licensing; organisations are free to take open source software, modify it, use it to provide a service over a computer network, but do not have to make any of their modifications to the open source software source code available to the wider open source community. The AGPL was specifically designed to address this loop-hole and ensure that any modifications to AGPL-licensed software used to provide SaaS are released back into the open source community.

May the licensee levy a fee for redistribution? May the licensee levy a fee for additional support or services?

Going back to principle 1 of the OSD, the licensee is not restricted "from selling or giving away the software as a component of an aggregate software distribution". Generally, all OSI-approved licences permit the licensee to charge a fee to redistribute the open source software and provide additional support, services and warranties. The OSD places no upper cap on the fees that may be charged for redistribution of the object code or for the provision of support, services or warranties, but as referred to above, limits the cost payable for obtaining the source code to "no more than a reasonable reproduction cost preferably, downloading via the Internet without charge".

Conclusion Given the scale of the terrain covered by open source software and the complexity of the open source licensing regime, this article can be no more than a high level map identifying major points of interest in the most commonly used open source licences. There are subjects referred to in this article which merit a separate article: licence compatibility, what counts as incorporation into a proprietary work, what counts as "distribution" of open source software, among others.

We hope this article provides a useful starting point for readers looking to explore the work of open source software and licences and welcome any feedback that may be used to refine and develop the above table.

Endnote

It is interesting to contemplate the meaning of "internally" in the context of group structures where modifications might be made by a single group company with the intention of making the modified software available generally within the group of which that company is part. In such circumstances, in the case of Restrictive Licences the group company making the modifications might need to make the source code of the modified software "available" to its other group companies before distribution to them.