Policy on licensing software produced by STFC e-Science
STFC e-Science staff develop software which others wish to use or which may be exploited commercially. That software needs to be released under an appropriate licence. Licensing issues should be considered at the start of any development project, since the choice of software libraries to be included, and their licence terms influence the final choice of licence of the software released by STFC.
UK Government policy on licensing software  is that:
"Publicly funded R and D projects which aim to produce software outputs shall specify a proposed software exploitation route at the start of the project. At the completion of the project, the software shall be exploited either commercially or within an academic community or as OSS."
JISC have also provided guidance  to the UK HEI and RC community, which includes: "4.2 Copyright of software, documentation, design materials, manuals, user interface and source code must be released under an OSI-approved open source licence , unless the bid explicitly argues why this should not be the case and proposes an alternative licence."
However, this government policy has not been enforced via Research Council grant terms. In fact, EPSRC are not in favour of a requirement for open source publication of software, preferring to support routes to commercial exploitation of results.
The STFC preferred position is to provide a licence which allows free use of software for academic and research purposes, but to reserve commercial options. As stated in the opening, the terms of licences of software libraries included may force the use of GPL licences which contradict this preference.
There is a conflict between the two requirements:
- to release software under licences to protect the STFC IPR;
- to maximise the use of the software STFC develop as a knowledge transfer activity.
This policy states the method for choosing the appropriate licence, and includes templates for those licences.
Software is never given away. The copyright is always retained by STFC, and the software is licensed, often without cost for academic R and D. To ensure that copyright is retained, all source files should include at least a minimal statement statement:
"© YEAR Science and Technology Facilities Council."
How to select the appropriate licence.
There are two issues to be considered when choosing which licence to use for software with several options for each:
- What liabilities apply to the software?
- software incorporated requires the use of a GPL licence.
- Software incorporated allows the use of any licence.
- No software is included.
- There is a conflict between the requirements of the licences of the included software so it cannot be released without breaking at least one licence - default.
- What is the probability of commercial exploitation by STFC?
- real expectation of commercial exploitation negotiate a commercial licence based on the commercial template ?
- high prospect of commercial exploitation, so we want to reserve our rights so use a public source licence which is not OSS - default.
- too low prospect of commercial exploitation to justify expense of alternative exploitation routes, but we want to get the code used - BSD style open source software licence.
The following decision tree structures the interaction of these issues, with the possible outcomes.
Notes on the licence selection decision tree:
Q1) This question should be considered before software is developed in order to maximise the impact of the software.
Q2) Conflicts arise most frequently when different OSS packages have been included. Care must be taken when combining software that is covered by different licences. Many licences have clauses that relate to "derivative works" that can limit the way that they can be combined with software covered by other licences. The myriad of possible licence combinations is beyond the scope of this guidance note, but issues surrounding the GNU Public Licence (GPL and LGPL) need more explanation.
The unusual nature of the GPL's "derivative works" clause affects the way in which software covered by it can be combined with non-GPL software. The GPL requires that any "derivative works" of software covered by it must also be licensed in accordance with the GPL. The precise meaning of "derivative work" is contentious and has, as yet, been little tested in court. It has been argued that the entire concept of a derivative work, in the software context, applies only in US law and has no precise equivalent in EU jurisdictions. It is possible that GPL licences breach the "Interoperability" rights as laid out in European 90/EC/250 Copyright Law, but STFC do not wish to test this argument in court, so conflicts must be avoided.
Whatever the status of the "derivative work" concept in a given country, some commentators also consider that it does not rule out all forms of integration with non-GPL code and that careful engineering can allow the legal use of GPL software in conjunction with non-GPL open source software and even with proprietary software. [This may for instance be the case if the GPL code references external code only via run-time linking.] Many of the most common free software licences, such as the original MIT/X licence, the BSD licence (in its current 3-clause form), and the LGPL, are "GPL-compatible". That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole).
Given the uncertainty in this area, developers who are intending to use software covered by the GPL as part of a development activity are strongly advised to check exactly how they are integrating the GPL code with their own to ensure, so far as possible, that they are not violating the terms of the licence. Wikipedia lists those licences which are known to be incompatible with GPL licences .
If there are no conflicts, but GPL licensed code has been incorporated then the software must be released under a GPL licence. The GPL has been described as being "viral" by many of its critics, because the GPL terms require that all modified versions of the software must in turn be licensed under the GPL. The program must be GPL only if it includes GPL source code or it is linked with a GPL library. For example, using gcc to compile proprietary software is allowed.
Q3) If there is an immediate route to commercial exploitation then a commercial contract needs to be drawn up by contracts section.
Q4) The default answer to the question is that there is some potential for exploitation and public source licence should be used. This limits the use to non-commercial use, and is not
an open source licence. However, it is suitable to share software with universities and research partners who only wish to use the software for research purposes.
If there is no realistic chance of commercial exploitation, or there is a contractual commitment to produce open source software, then the standard BSD licence  should be used. Do not alter the text of this licence to produce a new one, otherwise all the case law, and common practice established for the BSD licence may not apply.
Policy Control Details
This policy comes into effect on 1st August 2007.
The policy applies to all software developed in STFC e-science department.
Requests for change to the policy, and questions about interpretation should be sent to Resources Group, STFC e-Science.
 HM Gov't policy on OSS [1, 28/10/04] (pg 4), http://www.govtalk.gov.uk/documents/oss_policy_version2.pdf