How to choose a Licence for Open Source code or software
You’ve decided to make your code Open Source, but choosing the right licence for your software code can be a difficult task. There are a vast array of different licences to choose from all with varying rules. Some things to help you choose your licence are discussed below.
Why should I put a licence on my software?
Who owns the Intellectual Property?
Does your code use existing software libraries?
Making software or code open source
Can I change the software licence?
Why should I put a licence on my software?
Giving your software a licence will increase the impact of your research outputs through reuse and development by others. It is important to think about who you want to reach and what you want to enable, so that you choose an option which maximises the chances of long-lasting impact.
If you publish your code but don’t choose a licence, then default copyright laws are applied which assumes all rights of the source code are retained by the owner essentially meaning that no one can use your code. If you want to make your source code available under a fully open licence, this intention needs to be made clear by choosing a licence that allows others to freely use, copy, modify, resell or distribute the software. A licence can also make clear who is liable for example, if something goes wrong with the software.
Who owns the Intellectual Property?
It is important to establish who owns the Intellectual Property (IP) before a decision can be made on who can license the software and which licence to use. In many Universities, it is the University and/or funding body who hold the copyright over any work created. The University of Cambridge is different from most Universities as the creator of work is the primary owner of the IP rights. There may be situations when this is not the case such as sponsored research, or research stemming from multi-institutional collaborations or collaborations with Industry. We would recommend that you check with your contracts department, or Cambridge Enterprise who can help you to see what applies to you. If you think that your work could potentially form the basis of a patent application (whether by you or somebody else) then it is very important to consult with Cambridge Enterprise before choosing a licence or sharing your code with anyone other than your fellow creators.
With the majority of licences, acknowledgement is granted for the copyright holder and acknowledging anyone beyond that can be difficult. So, in the case of a Cambridge researcher, it would be difficult to acknowledge the University of Cambridge. The same would be true if the university or funding body owned the work but also wanted to credit a researcher. For example, GNU explicitly say that their GPL v.3.0 licence does not permit adding extra terms that mandate citation or acknowledgement beyond the content of the licence.
What is licensed?
Another thing you may need to consider is that in general it is the source code and not the output that is licensed. This means that if someone uses the software or source code within their project, they own its output and they can choose to publish that output however they like, with or without any acknowledgements. The licence requirements only apply to sharing the code; for example, if someone wanted to publish a derivative of the software or source code. For more information on this topic see the frequently asked question about GNU licenses
Does your code use existing software libraries?
If you are using any existing software libraries within your code, then you need to be aware that not all open source software licences are compatible. The licensing conditions on some libraries may restrict what can be used as the licence for any resulting code: for example GPL licences have restrictions. It is important to check the licence on any additional software libraries your code uses or relies on. It is considered good practice (and even necessary) to follow the licences already in place. If you are using proprietary software, then this can’t be used without explicit written permission from the owner. You should also include details of any copyright notices and licences for open source packages you are distributing alongside or within any of your new outputs.
Common Software Licences
If you are working in a community, then it is best to choose a licence that is associated with that community. An extensive list of common software licences can be found at https://spdx.org/licenses/ . For open source, look for a licence on the list with “Y” in the last two columns (“FSF Free/Libre?” and “OSI Approved?”). Examples of how licences may differ include whether they require acknowledgement in any derivative work or require distribution of the source code in any derivative work.
Other useful licence selector tools are:
Permissive software licences (e.g. MIT, BSD, Apache).
There are no restrictions on what you can do with the code as long as you attribute the original creator. With code under a MIT or BSD licence, you can place a proprietary licence on top making these the most open-source software licences available. Apache can be used “permissively” by co-existing with other licences; for example, having code available as add-ons that can be licensed under a proprietary licence and separately from the original code (under Apache). You are not able to file patent infringement proceedings against anyone using Apache code.
Restrictive software licences (GPL)
GPL (from the GNU General Public Licence suite) and derivatives (e.g. LGPL, AGPL and EUPL) is a copyleft licence which allows free use and modification as long as the same rights are applied to any derivative work. In academic research, the GPL licence is a popular choice as any software resulting from code published previously under a GPL licence will automatically be covered by the GPL licence. An example of this is open source code under a GNU GPL v. 3.0 licence (https://opensource.org/license/gpl-3-0/). With this licence anyone can use and adapt the work, but they must acknowledge the copyright holder and list any changes they have made. Code distributed like this can be used commercially, and can be used in a proprietary workflow, but the software cannot be distributed unless is made open source. There is a GNU Lesser GPL licence (LGPL) which allows some proprietary use.
Making software or code open source
GitHub, with the chosen licence attached. Note that if you publish the code without any licence, full copyright is assumed to be retained by the author, despite the code being public.
GitHub’s terms of service do not address long-term storage, access and preservation of code and a concern would be that the code could disappear at any point. For this reason, GitHub would not meet the expectations of funding bodies such as EPSRC.
One recommended option could be to use GitHub for ongoing work and development of the source code, and to submit relevant software releases or versions to a repository that provides long-term preservation, such as Apollo or Zenodo. Apollo is the University of Cambridge’s institutional repository and is CoreTrustSeal certified, ensuring appropriate curation processes and long-term access and preservation. Apollo also offers DOI versioning, allowing you to deposit variations of existing source code. Zenodo is a general-purpose public repository that offers a GitHub plugin, which allows researchers to easily share and archive versions of their code stored on GitHub.
Can I change the software licence?
It depends on the current licence compatibility and who owns the copyright, as you would need agreement from all the copyright holders. If the licence you want to change to is compatible with the new licence you may be able to change. Generally this is when you want to change from a permissive to a more restrictive licence (the permissive licence essentially gives permission in advance from the copyright holders to change the licence). If your current licence is not permissive or you are not a sole copyright holder then it might not be so easy to change. Some examples of different scenarios are below.
Scenario 1: I have written some software and would like to release it. What licence am I permitted to use? Answer: It depends on which external libraries you have used in your software. If all of the libraries have permissive open-source licences, then you are usually free to use any licence you wish. If any of the libraries have strong copyleft licences, though, such as the GNU General Public Licence, you have to use an open-source licence. In any case, you are legally required to follow the licence conditions of the external libraries you use within your code. In addition, if your software is written as a collaboration, the licence conditions should be agreed by all copyright holders, who are usually the authors.
Scenario 2: I have written some software and released it under licence A. I'd now like to release it under licence B. Can I? Answer: In general, yes, though it depends on who owns the copyright, as you would need agreement from all the copyright holders to release the software under a new licence. In addition, anyone is still welcome to use the version released under the original licence with the conditions of that licence if they so wish. For example, say version 1.0 is released under licence A and version 2.0 under licence B. If licence A is more permissive than licence B, it is not possible to remove those extra permissions from version 1.0, but a user is restricted to the licence B provisions for version 2.0. Your licence must also be compatible with the licence of any external library you use within your code.
Scenario 3: I have received some software and made modifications to it. What licence am I permitted to release my modified version under? Answer: It depends on the licensing conditions of the software you received. Some open source licences permit you to (re-)licence your modified version under any licence conditions (including proprietary ones), while others (such as GNU General Public License) do not.
As you can see, choosing your licence carefully from the outset is very important. For more information see this open source guide.
Create metadata
Finally, it is generally good practice to create metadata to describe the source code or any generated data and to keep updating this with any subsequent new versions.