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 (‘Open Source: An Opening Resource’), the text of which is available here.
This article focuses upon one of the significant issues identified in Andrew’s article, namely ‘Loads of Different Licences’. As Andrew mentioned, the existence of over 200 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 (the ‘Approved List’) which it has ‘approved’ as compatible with the Open Source Definition (‘OSD’). In July 2008 the Approved List contained 72 different licences. Whilst not unfeasible, 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 the Approved List within the open source community. According to Black Duck Software, in July 2008 over 94% of open source software was licensed under one of 10 different licences (see http://www.blackducksoftware.com/oss#top20), all of which are on the Approved List
These are, in order of usage:
|
Rank |
Licence |
% |
|
1 |
GNU General Public License (GPL) 2.0 |
57.74% |
|
2 |
GNU Lesser General Public License (LGPL) 2.1 |
10.70% |
|
3 |
Artistic License (Perl) |
9.85% |
|
4 |
BSD License 2.0 |
6.15% |
|
5 |
Apache License 2.0 |
2.78% |
|
6 |
MIT License |
2.47% |
|
7 |
GNU General Public License (GPL) 3.0 |
1.86% |
|
8 |
Mozilla Public License (MPL) 1.1 |
1.29% |
|
9 |
Common Public License (CPL) |
0.77% |
|
10 |
zlib/libpng License |
0.59% |
Source: Black Duck Software – July 2008
Assuming that these figures are correct and 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 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 can and cannot be done with the software. Can the source code be modified? Can the object code be redistributed? Can a fee be charged for redistributing the object code or providing ancillary services to the open source software? If the code is modified, is the client obliged to make such modifications available to the wider open source community? If code is incorporated into the client’s own proprietary code, will the proprietary status of pre-existing code be jeopardised, and will later proprietary additions to that code also be affected?
We’ve taken these questions and in the table below 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. We also deal with the question of whether such licences are enforceable.
(Having trouble making sense of the table on your display? Click here to read the licence in pdf form.)
|
Licence |
Permissive or Restrictive? |
Is the licensee permitted to modify the source code? |
Is the licensee permitted to redistribute the source code? |
Will use of the source code in proprietary software present a risk to the copyright status of proprietary software? |
Is the licensee required to release modified source code back to the open source community, if it: |
May the licensee levy a fee for redistribution? |
May the licensee levy a fee for additional support or services? |
||
|
(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? |
|||||||
|
Affero GPL (AGPL) |
Restrictive |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
Yes |
Yes |
|
Apache License 2.0 |
Permissive |
Yes |
Yes |
No |
No |
No |
No |
Yes |
Yes |
|
Artistic License (Perl) |
Restrictive |
Yes |
Yes |
Yes |
Yes |
No |
No |
Yes |
Yes |
|
BSD License 2.0 |
Permissive |
Yes |
Yes |
No |
No |
No |
No |
Yes |
Yes |
|
Common Public License (CPL) |
Restrictive |
Yes |
Yes |
Yes |
Yes |
No |
No |
Yes |
Yes |
|
GNU General Public License (GPL) 2.0 |
Restrictive |
Yes |
Yes |
Yes |
Yes |
No |
No |
Yes |
Yes |
|
GNU General Public License (GPL) 3.0 |
Restrictive |
Yes |
Yes |
Yes |
Yes |
No |
No |
Yes |
Yes |
|
GNU Lesser General Public License (LGPL) 2.1 |
Restrictive (but permits linking) |
Yes |
Yes |
No (provided the proprietary code only links to the LGPL code) |
Yes |
No |
No |
Yes |
Yes |
|
MIT License |
Permissive |
Yes |
Yes |
No |
No |
No |
No |
Yes |
Yes |
|
Mozilla Public License (MPL) 1.1 |
Restrictive |
Yes |
Yes |
Yes |
Yes |
No |
No |
Yes |
Yes |
|
zlib/libpng License |
Permissive |
Yes |
Yes |
No |
No |
No |
No |
Yes |
Yes |
Guidance on the above table
As a first step in understanding these licences, it is important to consider the main distinction between simple permissive licences, such as the Apache Licence, the BSD Licence and the MIT Licence, which impose few restrictions on the licensee (‘Permissive Licences’) and licences such as the GPL, the LGPL and the MPL which 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 (‘Restrictive Licences’).
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 distributing their software, copyleft is an approach to licensing whereby 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. Such copyleft provisions are at the core of Restrictive Licences.
A simple example which illustrates how copyleft and, therefore Restrictive Licences, work 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 also require Developer B to 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 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 and therefore use of software licensed under a Restrictive Licence is something that an organisation needs to be aware of and in respect of which it should consider the commercial and legal implications in any of the scenarios mentioned 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 intellectual property rights in the proprietary software may be affected (adversely from the point of view of the owner of the proprietary software), for example by being ‘embraced’ by the terms of the Restrictive Licence. In such circumstances, the owner of the proprietary software is well advised 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) uses it itself but 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, the licensee 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, the licensee will not be required to distribute the modified code under the terms of the Permissive Licence. Even if they do so wish, they are not required 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’.[1]
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’.
Are Restrictive Licences enforceable?
On 13 August 2008, the Court of Appeals for the Federal Circuit in the US upheld the restrictions contained within the Artistic Licence, one of the top ten licences contained within our table.[2] In Jacobsen v Katzer and Kamind Associates, the Court held that the restrictions in the licence operate as conditions rather than mere covenants with the effect that if the conditions are violated the licence disappears, since its grant is conditional upon observance of them. Having determined that the terms of the Artistic Licence are enforceable copyright conditions, the case has been remitted back to the District Court to determine the likelihood of success on the merits and questions of potential irreparable harm in the context of an application for a preliminary injunction to prevent the defendants’ further use of the software. The District Court had held that the plaintiff did not have a cause of action for copyright infringement based on breach of the conditions of the Artistic Licence but only for breach of contract and, because a breach of contract under US law creates no presumption of irreparable harm, the District Court had denied the motion for a preliminary injunction. It is our view that an English court would take a similar approach to the US Court of Appeals, and therefore that ignoring restrictions in Restrictive Licences makes a user vulnerable not just to a claim for damages but also to injunctive remedies.
This is not the only case on the enforceability of open source licences. Actions in Germany in 2004 (involving a subsidiary of Sitecom) and in 2007 (involving Skype) successfully enforced GPL licences, as did a number of actions in the US by the Software Freedom Law Center filed in 2007 to enforce the GPL in respect of BusyBox software, the most notorious of which was against Verizon.
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 who are looking to explore the work of open source software and licences, and we welcome any feedback that may be used to refine and develop the above table.
Bill Jones, of Counsel, Brian Meenagh, Solicitor, and Sally Mewies, Partner, are all members of the Outsourcing, Technology and Trade Group at Wragge & Co LLP. Bill Jones is also Chair and a Trustee of SCL.
[1] 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.
[2] Jacobsen v Katzer and Kamind Associates, Inc, United States Court of Appeals for the Federal Circuit, 2008-1001, Decided August 13th 2008.
