What kind of licence should I choose?

by Rowan Wilson on 23 May 2011 , last updated 9 September 2012

Introduction

There are many free and open source software licences, and while they all broadly attempt to facilitate the same things, they also have some differences. Some of the major differences can be grouped together into categories, and this document acts as an introduction to these categories. Having read this document, you should be able to understand which decisions you should take in order to select a licence for your code.

Staying mainstream

The Open Source Initiative - a non-profit organisation formed to educate about open source - maintains a list of licences that they see as being ‘popular and widely used or with strong communities’. The purpose of the list is to highlight those licences which are likely to answer the needs of many licensors new to open source. The list also helps to make the task of open source licence selection seem manageable; the full list of more than 60 licences can be daunting, and contains many licences which are in most ways similar in function to one or more of the ‘popular and widely used’ listed licences.

Using a licence that many others use has some advantages. If the terms of the licence are challenged, there will be a larger pool of licensors with an interest in funding a response to the challenge. Using one of the ‘popular and widely used’ licences also makes it more likely that your licensees will already be familiar with the terms you are offering. Equally though, licensors should not feel ‘locked in’ to only using a ‘popular and widely used’ licence. Some of the features we discuss below are only present in the wider pool of all OSI-approved licences.

Permissive and copyleft

All free and open source licences allow others to make modified versions of your code, and to make these modified versions available to others. The licence you choose can make conditions about how this happens - specifically what licences can be used on these modified versions. These conditions can help keep your code free, but they can also put some people off reusing your code. Such conditions are sometimes called ‘copyleft’ conditions, in a play on the word ‘copyright’.

Open source licences that do not seek to control how modified code is licensed are often referred to as ‘permissive’ licences. While the original code covered by a permissive licence stays under that permissive licence, any modifications to it can be released under any licence that the modifier chooses, open source or not. This means that permissively licensed code can form the basis of closed source products. Some argue that this makes permissive licences more ‘free’ than copyleft licences, in that people who modify the code are freer to choose what they do with it. Others argue that the lack of a requirement that modifications be open source means that permissive licences are less ‘free’. As discussions of ideas of freedom - and particularly the idea of compulsion to be free - are essentially philosophical they fall outside the scope of this document. It is worth noting, however, that there are differing views within the free and open source world about what ‘free’ in the sense of freedom really means.

Example: As part of her astrophysics research Anne creates a standard for recording a specific kind of complex data object. She also writes code to create and parse files that adhere to the standard. Anne is keen that the standard becomes widely used, as minority standards are far less useful. Therefore she decides that she will release the code under a permissive licence. Anne believes that by allowing creators of both closed and open source projects to use the same code to create and read the data objects, uptake and efficacy of the standard will both be helped along.

Strong and weak copyleft

Should you choose to include copyleft licensing conditions on reuse of your code, there is a further choice to be made. Copyleft licences are broadly divided into two ‘strengths’: strong and weak. Strong copyleft conditions dictate that when a piece of software contains some of your code, the software as a whole must be distributed under your licence, if it is distributed at all. The effect of this will be that the source code to all additions made to the code will be available.

Weak copyleft, on the other hand, means that when software contains some of your code, some parts of the software must be distributed under your licence, if the software is distributed at all. Other parts may be distributed under other licences, even though they form part of a work which is - as a whole - a modified version of your code. One effect of this will be that the source code to some additions made by others to your software may not be available as open source. Another effect may be that people may find it easier to ‘productise’ your code by adding closed components and selling licences to these closed parts.

To choose a specific weak copyleft licence, you must also decide precisely which parts of your code will retain your licence and what kinds of additions can bear a licence of the modifier’s choosing. This division can happen at one of three levels:

Module level weak copyleft licences dictate that each functional sub-section (‘module’) of code within the software is considered separately. Where a module contains some of your code, it must bear your licence. Where it does not, the owner of that code gets to choose their own licence for that module.
File level weak copyleft licences dictate that each collection of code and data that is distinct according to the computer’s file system is considered separately. Where a file contains some of your code, it must bear your licence. Where it does not, the owner of that code gets to choose their own licence.
Library interface level weak copyleft licences are generally used where your code is a software library (a collection of software functionality which is usable by other programs via an agreed interface). Modifications of your library must bear your licence, if they are distributed. Programs that use your library, and are perhaps distributed alongside it, need not use your licence.

Example: Barry writes a piece of C code that examines websites over a network connection and generates image file diagrams of the links between their pages. Barry wants to release his code under a copyleft licence because he wants to mandate access to the source code of all modifications of his program that are released. However, Barry also wants a wide variety of projects to be able to use his program - partly because he believes this will encourage the useful modifications and optimisations of his work that he wants to see. Barry decides to package his program as a library and use the library interface level weak copyleft licence the GNU LGPLv2.1 on it, as it seems to him that this represents a good balance between encouraging reuse by both closed and open source projects while mandating the release of source of modifications to the parts he is interested in - his own code and the functionality it embodies.

Jurisdiction

A ‘jurisdiction’ refers to a specific location or territory and its system of law. Where a licence specifies a jurisdiction, the licensor and the licensee(s) agree that the terms in the licence are to be understood in reference to that jurisdiction’s law and that legal action resulting - for example - from breach of the licence’s terms will take place in that jurisdiction.

While jurisdiction is an important issue, it may be worth noting that traditionally free and open source software owners do not tend to seek monetary damages from those who infringe their licensing terms, but seek instead to compel the infringer to either abide by the terms or terminate their use of the code in question. For these purposes it is often unnecessary to resort to actually taking an infringer to court, particularly if they have a public profile and reputation to protect. Often simply requesting compliance can be effective, and if that fails, publicising the infringement can help achieve compliance. Not all free and open source software licences specify a jurisdiction. In fact most are silent on the subject. In these cases any jurisdiction can be selected when and if necessary, although it is quite possible that the person you are trying to take to court will either ignore you or dispute your choice of location if it does not suit them. Finally some free and open source software licences state that the jurisdiction is either up to the licensor or automatically that of the licensor (where they reside or principally do business).

Example: Crabapple University is keen to write a policy on open source release, as an extremely large endowment specifies this as a pre-condition. Lawyers within Crabapple decide that a key piece of this policy must be the anointing of a specific licence as the institution’s preferred option when licensing out software as open source. At the first meeting to discuss which licence to choose, it is pointed out that the institutional insurance policy does not cover legal action abroad. It is therefore decided that an essential feature of the anointed licence must be that it enforces a local jurisdiction for any legal action resulting from the release of software it covers.

Patents

Do you or your institution own any software patents? If you do, and you release some code that embodies them under a free or open source software licence, then you are very likely to be granting rights to use the relevant patent (in connection with that code) to anyone who chooses to use it - even if the licence does not explicitly say so. In many jurisdictions, for example the UK and the US, licensing someone to take a particular action (like copying or adapting your code) can also impliedly license them to take all other steps necessary to take that action. These impliedly licensed steps would almost certainly include use of your embodied software patent. It should be noted that people who adapt your code cannot expand its functionality to capture other software patents of yours - you grant rights only to the patents embodied in the code you released, not any subsequent form the code may take. Some free and open source software licences say nothing on the subject of patent grants - although as noted this may not mean that they grant no patent rights. Some free and open source software licences explicitly grant patent rights necessary to use, adapt and distribute the software.

Your free or open source software licence can also include what is sometimes called a ‘patent retaliation’ clause. These sections of a licence essentially say that anyone who brings legal action alleging that the licensed software embodies one of their software patents will lose the licence you have granted to copy, use, adapt and distribute the code. Such a clause is intended to dissuade people from bringing this kind of legal action.

Example: Professor Dopaska has created a software-embodied process for predicting civil unrest that his university believes is patentable. The professor is keen to release the software embodiment of this process under the permissive Apache License, v2, as he wishes to see the process used ubiquitously to enhance his academic reputation. Knowledge transfer staff at Professor Dopaska’s institution are not keen on this idea, as they wish to obtain the patent and build a spin-out company around it, and believe that the open source release will undermine the licensing income of this venture.

Enhanced attribution

All free or open source software licences specify that anyone who distributes or adapts the software must give credit to the original authors of the software somewhere in their distribution. Some free or open source software licences go further than this, and specify that the credit must take a particular form and appear in specific instances, for example on the software’s user interface every time it is run. This kind of stipulation is sometimes called ‘enhanced attribution’ or ‘badgeware’.

Example: Edward creates a tool for visualising the frequency of occurences of words in documents in an attractive way. Edward surmises that the tool will probably be used widely, but is not essential enough to most users’ core business to support a paid licensing model. In truth, what Edward really wants to achieve is publicity for the promotional consultancy he runs and for which the code was written. Edward decides to release his tool under the Common Public Attribution License v1 as this mandates the display of a URL, a graphic and an attribution phrase every time the software is run. Edward provides his consultancy site’s URL, logo and strapline along with the software so that users will help promote his business when they use and reuse his code.

The privacy loophole

If someone uses your code to create an online service or an in-house solution, perhaps adapting and improving it, most free and open source software licences do not specify that the source to the adapted or improved version must be released. Most free and open source software licences make it a condition of distribution that source code be released. In general neither making services available over a network, nor using the code, nor deploying the code within a single institution is defined as distribution within these licences.

Some within the free and open source software community feel that this phenomenon, sometimes called the ‘ASP (application service provider) loophole’ or ‘privacy loophole’ needs to be fixed. Their argument is that fairness dictates that all those who benefit from the code must contribute their work back to the world, even if they are not, strictly speaking, distributing the code.To address this issue, some free or open source software licences make release of the source code a condition not only for distribution but also for internal deployment and/or making services available over a network using the software. These kinds of conditions are therefore particularly suited to code which is likely to be used in-house or as a basis for a networked service.

Example: Fareeda wants to build a business providing an easy way for users to build complex slide show music videos from their photographs on social networking sites. She finds a piece of open source software under the GNU Affero GPL v3 which provides a convenient way to handle the requirement that her site must interface with many external sites. Looking into the licence, Fareeda discovers that its terms mandate that - if she modifies the code it covers and uses it as the basis of a service provided over a network as she intends - she must also make the source code to her modifications available to service users. Fareeda must now decide if her business model will be unaffected, aided or undermined by this potential responsibility.

No promotion

Some free and open source software licences explicitly forbid the use of the authors’ names to promote a product or service based upon the authors’ code.

Example: As part of a publicly-funded project Gerhentz University creates code which automatically adapts user interfaces to arbitrary display sizes. The institution is keen that the public funding leads to the maximum public benefit both in open and closed source software, and so wishes to release the code under a permissive open source licence. However Gerhentz does not wish to be seen to be endorsing products that contain their code, as they feel that this may potentially damage the institution’s reputation. Therefore it is decided that the BSD License will provide both the wide reusability and block on promotional use that they seek.

Conclusion

This document has presented some of the key differences between the various free and open source licences, in order to help you consider what kind of licence you might want to apply to your own code. Examples are provided to flesh out the kind of considerations that might feature in your own selection process. You should note, however, that there is not a licence for every possible combination of features, and so it may well be necessary to compromise on one or more category of features in order to actually choose a pre-existent licence. To achieve this it can be helpful to rate the features you desire in order of importance. OSS Watch can help you choose a licence which best fits your most desired characteristics - just get in touch.

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.