You've written some software as part of your research, and you would like others to be able to use it. You've made sure your code is ready for release so there's only one thing left to do: choose a licence.
Bookmark this page
Bookmarked
Choosing an open-source license
By Neil Chue Hong and Tim Parkinson.
You've written some software as part of your research, and you would like others to be able to use it. You've made sure your code is ready for release so there's only one thing left to do: choose a licence.
Why write this guide?
There are so many useful resources on the web when it comes to open-source licensing that it can be confusing. This guide highlights the best resources that provide clear information about choosing a licence for software.
Although the following information might appear overwhelming, it's important to make a choice (even if it is to choose a commercial, closed-source licence). If you don't have a licence for your software, it is effectively unusable by the whole research community, and those potential collaborators will turn to someone else's software.
The detail may well be overwhelming, but your choice will normally come down to one of a few popular licences. To provide more specific advice, we will look at providing a guide with more detailed guidance for researchers working in the UK.
Disclaimer
This guide is intended to highlight resources which may be useful to those developing research software. It was not produced by lawyers, and is not legal advice. The Software Sustainability Institute is not responsible for the content referenced in this guide.
Why is an open-source licence useful?
As a researcher, you want to encourage collaboration. The software you've written might be useful to other researchers, but if others use your software you deserve credit and recognition for your software, which will help further your research career and reputation.
An open-source licence is a set of conditions that grants the users of your software (your potential collaborators!) certain rights to use, copy, modify, and possibly redistribute the source code or content of the software. It also asserts your authorship.
More importantly, open source is now seen as fundamental to good research by centring around the principles of open access and reproducible research, as described in the following articles.
- Shining Light into Black Boxes (Nature Research Priorities)
- Troubling Trends in Scientific Software Use (Nature Policy Forum)
How can I tell the difference between open-source licences?
All open-source licences allow other people to take the source code for your software and modify it, as long as they give credit to you as an author. The best way of differentiating the various open source licences is to consider three questions:
- Do you care about how any modifications that people make to the code are distributed?
- Do you or your institution own any related software patents?
- Do you care about the way your name is or isn't mentioned when someone makes use of your code?
A good description of the various choices, along with examples relevant to research software, is provided by OSS-Watch:
tl;drLegal is an online service that provides plain-English summaries of popular open-source licenses, allows these to be searched according to features of interest (what users Can, Cannot and Must do with software released under than licence), allows the implications of combining licences to be explored and provides a simple tool to auto-generate attribution documents in HTML so you can give credit where it's due to open-source software you use:
The sheer number of licences can cause confusion, but you should always choose an Open Source Initiative (OSI) approved licence, and ideally one of the popular licences listed on their website (in particular the Apache, BSD, and GPL licences):
GitHub have provided a very useful summary of what is required, permitted and forbidden by some of the most popular open source licences:
Similarly, the Institute of Formal and Applied Linguistics at Charles University in Prague provide an open license selection tool, which provides guidance on licenses for both software and data:
You should note that the applicability of certain conditions may vary from country to country under different legal systems. For instance, under English law, some exclusion clauses (such as those limiting liability for death and/or personal injury) are not allowed.
If you are really interested in how different licences might be interpreted and claims pursued in different countries, a group of national legal experts are publishing a resource (which is quite difficult to read if you are not a lawyer) that contains references to specific laws and cases from each country:
What happens if I am using someone else's code in my software?
People often overlook what to do when you are using someone else's code in your software. The reuse, bundling or redistribution of code snippets, libraries and other assets such as images as part of your software can only be done if the licences are compatible.
Although it dates from 2007, this diagram gives a good indication of compatibility for some commonly used open-source licences, with more protective licences being able to encapsulate more permissive ones:
- The Free-Libre / Open Source Software (FLOSS) License Slide (note that MPL 1.1 has been superceded by MPL 2.0 which is compatible with Apache and GPL licences)
As a general point, you should always know the licence of any code, libraries or other files that you reuse or redistribute.
What do I need to do before applying my choice of licence?
It may surprise you to learn that as a researcher, even as a professor, you are probably not free to make the decision to open source your code. In general in the UK, software that you create as an employee of a university belongs to the university. If you search for the phrase “intellectual property policy” on your institution’s website you will see something along the lines of:
“Staff of the University are subject to sections 39 to 43 of the Patents Act 1977 (as amended) and sections 11, 215 and 267 of the Copyright, Designs and Patents Act 1988 (as amended). IP owned by the University by default includes any invention or design work created by a member of Staff as part of their normal or specially assigned duties ……… copyright in the works of staff is held by the party stipulated in their contract of service or signed written agreement…….. In addition, employment with the University means that the University will own IP created by Staff as part of their duties. Examples of Intellectual Property owned by the University include… inventions, designs, databases, software and related support materials, brands, copyright in course materials” (Southampton Solent University) [i.e. your employer owns the copyright to 'your' software]
and
“Staff and Students shall at all times take all steps reasonably necessary to maintain the confidentiality and registrability of any IP and shall do nothing which will prejudice the right to apply for its registered protection.” (University of Southampton) [i.e. you may not publish potentially commercially exploitable source code, even in a peer-reviewed journal, without prior permission]
Your institution will have its own policies and procedures that lay out how to obtain permission to open source your software. These procedures will also take account of the fact that your funding conditions may require software source code to be made freely available. The people who can provide advice on this subject will be based in your institution and will often be called things like Research Innovation Services, Enterprise or Commercialisation.
Once you find the right person, they may also be able to advise as to which open-source licences are acceptable to your institution.
Further information
The OSS-Watch produce many excellent guides to open source, licensing and intellectual property related matters aimed at a higher education and further education audiences:
Lawrence Rosen has written a comprehensive introduction to the legal aspects of open-source licensing, which is freely available from his website:
A good distillation of this book in plain English is available here from Rich Apodaca:
Finally, this blog article covers many of the points from our guide, as well as going a bit further into other things you might need to consider:
- Picking an open source license w/o becoming brain dead (or brain washed)