Open software licensing

Some of the information on this webpage is adapted from ‘TU Delft Guidelines on Research Software: Licensing, Registration and Commercialisation’ and reused under a CC BY 4.0 licence

Introduction

An overwhelming majority of researchers develop and re-use software as part of the research process to generate, process or analyse results. Software is increasingly recognised as its own research output. Software should be well documented, preserved and whenever appropriate, the FAIR principles (Findable, Accessible, Interoperable, Reusable) should be applied.

Software can be made freely available in many ways, for example to a large audience through a repository such as GitHub or shared peer-to-peer under restricted licences. Alternatively, it is possible to run software as web services, restricting access to the output of the software, while keeping the source code confidential.

When making software available to others there should always be a balance between the level of openness, however, as possible commercial exploitation of software and any (legal) restrictions may prevent sharing it as Open Source. You may also need to consider any requirements of those funding the research. This may be different if the funder is a charity or a government department, such as the Ministry of Defence, where there may be sensitivity issues. This guidance sets out what the researcher needs to think about to share their software, as Free and Open-Source Software (FOSS).

Intellectual property

Intellectual property (“IP”) is the result of creativity of the human mind and, as property, it can be protected using various intellectual property rights (“IPR”) such as copyright, patents, trademarks, trade secrets etc. IPRs often protect the way something is expressed or a method of doing something, it will not protect the concept that is represented by it.

University staff

Members of staff, which includes both employees and honorary staff, at the University may generate IP in the course of their work at the University. Under English law, IP that is generated by employees in the course of their employment belongs to the employer, in this case the University. When a member of staff generates some IP while carrying out their role and believe this IP may be of some economic value, (or could be developed to have some economic value), they should bring it to the attention of UoB Enterprise, either directly, or by reporting it to their Head of College (or their Senior Officer in the case of professional services staff). The Code of Practice for Research (CoPR) outlines these requirements.

Students

Conversely, students own the IPR in the work they create during their studies. Where students are involved in collaborative projects with staff members, for example working alongside staff and participating in research projects, the University may require that IP generated by the student is assigned to the University. Again, this is covered by the CoPR.

Software development

Computer software (also referred to as code or programs) will be protected via copyright which lasts for the author’s lifetime, plus 70 years.

Those developing software also need to consider if they are using pre-existing IP (including software, software libraries or software generated by AI) produced by other people within their software or as a library. Where this is the case, you may need to seek permission (a licence) from them for re-use. Open-Source software is usually already licensed for re-use provided the users follow the terms of the licence, one of which may be the requirement to reference and acknowledge the original author in any new software created using that code.

You should also bear in mind that not all reuse licences are compatible with each other. You will need to consider the licence conditions of any software you have used to create your work. Some tools that you use to create software, e.g. MATLAB and LabVIEW, require you to have a commercial licence if you wish to make the software available for yourself or others to use for commercial purposes.

The software developer should also consider the impact of collecting personal data, whether it will be held within the software or any associated files required by the software. Thought needs to be given as to where the data is stored and how it will be curated and disposed of, as per the Data Protection Act 2018 (commonly known as GDPR). More information can be found on the Information Commissioner’s Office webpages (ICO).

Types of licence

Permissive licences

Permissive licences have minimal requirements about how the software can be redistributed. They do not block appropriation, nor do they force the redistributor to open the modified source code. By its nature, code written under a permissive licence can be incorporated in code written by a more restrictive licence, but not the other way around. There are many types of permissive software licences that are commonly used for FOSS. Such licences include minimal restrictions on how the software can be used, modified, and redistributed, usually including a warranty disclaimer. 

Permissive licences are often non-exclusive. This means that an owner can license their software under many different routes if they choose too, although this might make managing those rights difficult. While open licences are often irrevocable (i.e. once the software is openly licensed it cannot be closed again) an owner could choose to remove the code from the repository and release a new edition under different licensing terms, including all rights reserved.

This is especially important for works that are released under CC licences or other so called public domain declarations. The nature of CC0 is such that any one is free to do anything with it without restriction and that would include taking a copy (full or partial) and wrapping it up behind an "all rights reserved" regime. While this may be ethically questionable and open to challenge, it is certainly possible.

Examples of permissive licences include:

  • MIT (Massachusetts Institute of Technology) licence gives users express permission to reuse code for any purpose, sometimes even if code is part of proprietary software. Example of software that use this licence are X Window System, Ruby on Rails, Nim, Node.js, Lua, and jQuery. The biggest advantage of using the MIT License is that it is very permissive. The quality of the licence allows it to be both business-friendly and open-source friendly, while still making it possible to be monetise.
  • BSD 3-clause licence allows you almost unlimited freedom with the software, though it does include conditions on how copyright notices and disclaimers should be added into the code before redistribution. An example of software that uses this licence is Numpy, Nginx and C Shell.  
  • The Apache Licence allows users to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software under the terms of the licence, without concern for royalties. An example of software that uses this licence are PyCharm, Singualrity and Jetty.
  • Apple Public Source Licence (APSL) is the open-source and free software licence under which Apple's Darwin operating system was released in 2000. A free and open-source software licence was voluntarily adopted to further involve the community from which much of Darwin originated. An example of software that uses this licence are Keychain and XQuartz.

Public Domain Equivalent

A piece of software/coding would not legally enter the public domain (be out of copyright) until 70 years at the end of the calendar year in which the last author died. The Creative Commons CC0 licence is a way for creators, who would legally still retain the copyright, to let users know that they are happy for their work to be used as if was already in the public domain.  CC0 allows re-users to distribute, remix, adapt, and build upon the material in any medium or format, with no conditions, including no requirement to reference the original creator. However, it is an essential part of academic practice to reference any code written by other people, failure to do so could raise plagiarism issues.  If your software includes other types of works e.g. images etc you need to ensure that it is clear to any end users that these materials may not be covered by that licence.

Copyleft

Copyleft licences aim to keep code open for re-use by all. This means that any derivative code must be open source and distributed under the same or equivalent licence.  The most widely used copyleft licence is the GNU General Public Licence (GPL).

Proprietary licences

Many software programs are proprietary with all rights to access and use them being controlled by the owner or creator. Here the owner of the software grants the right to use the software under an End-User Licence Agreement (EULA), but the ownership rights in those copies remains with them (hence use of the term "proprietary"). It is typical of EULA’s to include terms which define who can use it and the permitted uses of the software, the number of installations allowed, and many other terms. An example of this would be Microsoft Windows.

Licensing your own software

Please ensure that you have read the above information so that you are aware of the issues involved in licensing your software.  The below decision tree will assist you in the steps you need to take before licensing your software.

  1. Can the software be defined as Dual-Use?
  2. Is the work funded or financed?
    • Yes -> Go to Step 3
    • No -> Go to Step 4
  3. Has the funder or collaborators placed any restrictions on the software being openly released (contracts)?
    • Yes -> Review the funding grant or contract or Talk to Funder /financier to discuss permissions / requirements.
    • No -> Go to Step 4
  4. Did you link to, include, or use lines of code from others, including collaborators?
    • Yes -> Go to Step 5
    • No -> Go to Step 6
  5. Is the others’ code out of copyright or Public Domain (and referenced)? Or licensed for your intended use with any terms & conditions followed (ensuring no conflicts in licence terms), and referenced?
    • Yes -> Go to Step 6
    • No -> Please contact the owner of the software to discuss re-use.
  6. Could your software have commercial value?
    • Yes -> Please review guidance on the UoB Enterprise website.
    • No -> Select an appropriate FOSS licence and add as a research output in PURE (Sharepoint, staff only). Please acknowledge funding and support from BEAR and others.

Signposting for further advice

The CoPR reiterates the commitment to academic freedom found in the University’s Ordinances, clarifies the University requirements, and offers information on the University’s facilities for advice on regulatory and ethical issues, which also cover research output. There are several teams who can help guide you:

Colleges

Professional Services