The document discusses key elements to consider when choosing a software license for technology transfer. It outlines three main steps: 1) identify any pre-existing contractual constraints on the software; 2) identify any pre-existing code components used in developing the software; and 3) define intended use of the software. The document also provides a case study analyzing these steps for a research lab licensing its software to a mobile network operator. It examines license compatibility issues and offers recommendations like indicating the license clearly in documentation.

1. Choosing the right license:
elements to guide
technology transfer officers
Emmanuel Gougé, 5/05/2011
www.FITT-for-Innovation.eu
Except where otherwise noted, this work is licensed under a Creative Commons Attribution 3.0 License.

2. What is a license agreement?
 Contract between a software publisher
(licensor) and an end user/entity (licensee)
which governs use and support obligations of a
software
 It usually includes provisions regarding:
 Intellectual property rights,
 Contract law,
 Consumer law.
 In case of litigation, both parties are able to go to
Court.

3. The aims of Software Licensing
 For the developer: visibility, promotion, financial
gains.
 For the team, research lab: visibility, new
partnerships, financial gains, public investments.

4. Understanding the 2 main types of license…
 Software licenses can generally be fit into the
following categories:
 Proprietary licenses: Certain rights regarding the
software are reserved by the software publisher (e.g.,
number of copies). In addition, ownership of the
software remains with the software publisher.
 Open source licenses: It includes openness of the
software itself (copyleft licenses -- e.g., GNU), and
those that aim to give freedoms to the users of that
software (permissive licenses – e.g., BSD).

5. Case study presentation
 The research lab « All For Me » (« AFM ») has developed a
new software called Gamma enabling telephone
companies to determine which network would suit them
best according to their needs.
 The company « Let’s Share » (a mobile virtual network
operator) is willing to obtain a license for this software so
they can improve quality control and ensure cost
effectiveness.
 The research lab AFM would like to license rather than sell
its software.
The aim of this case study is to do a step by step analysis of
what needs to be done to achieve this objective and pick up
the right license.

6. 3 main steps for license selection
1. Identify any pre-existing contractual
constraints
2. Identify any pre-existing components
3. Define software use

7. 3 main steps for license selection
1. Identify any pre-existing contractual
constraints
2. Identify any pre-existing components
3. Define software use

8. 1. Identify any pre-
existing contractual
constraints

9. Case 1: A research program without constraints
 The software is developed as part of a research
program without constraints.
 In this case, the laboratory AFM would have
worked freely on the software Gamma, without
partners and/or specific contracts regulating the
use and development of the software.
 Solution: Free choice of a licence.

10. Case 2: A research program with constraints
 The software is developed as part of a research
program with constraints.
 In this case, the laboratory AFM has worked with
partners (e.g. a university, a company) and/or
with specific contracts regulating the use and
development of the software Gamma.
 Solution: Usually a consortium agreement is
signed with all the partners of the collaborative
R&D project, regardless their respective status.

11. Case 2: Definition of a consortium agreement
A consortium agreement is intended to organize
the relationships among partners in a
collaborative R&D project. It aims in particular to:
 Organize the leading of the project,
 Determine the obligations of each partner in terms of
inputs and outputs,
 Establish the IP rights,
 Set the rules for the ownership and exploitation of
innovations created as part of the project.

12. Case 2: Consequences
 Solution: The consortium agreement solves the issue of
the exploitation of the software Gamma and thus of the
applicable license.
 What about the lack of a consortium agreement? The
software should be considered as:
 A collaborative work (Art. L.113.2 & s. of French IP Code): the
copyright belongs to the different co-authors, the rule of the
undivided interests applies: each co-author has to agree on
the kind of license to grant; or
 A collective work (Art. L.113-2 & s. of French IP Code): creation
within a team without the possibility to assign each a separate
right for all the work. Copyright belongs to the person or entity
who is the initiator of the creation and that publishes and
discloses it. It decides on the license it wants to use.

13. 2. Identify any pre-
existing components

14. Case 1: Software created ex nihilo
 «Starting from scratch».
 Possible situation but rare because the vast
majority of developments require the use of
preexisting compilers, libraries and runtime
environments.
 In this case, the laboratory AFM would have
developed the software Gamma in full without
using any external element.
 Solution: the choice of the license by the
inventor is free.

15. Case 2: Software integrating pre-
existing elements
 When the software is developed by integrating
pre-existing components.
 In this case, the laboratory AFM would have used
pre-existing external components for the
implementation of the software Gamma.
 Proceed step by step in order to :
 identify what already exists and its use,
 check the availability of the licenses,
 characterize the relevant licenses,
 check their compatibility,
 Identify the alternatives if the licenses are not
compatible.

16. Case 2: Identify what already exists
 Reasons for the use of pre-existing components:
 modify/improve what already exists,
 build the software,
 insert extracts, combine/link pre-existing components.
Check the presence or absence of pre-
existing components among:
 Languages (Note: translation into a different
programming language does not release you from the
regime governing the piece of code used),
 Plug-ins,
 Modules, and
 Libraries used for developing the software Gamma.

17. Case 2: Identify the applicable regime
 Either the use of pre-existing elements
correspond to a legal exception to Copyright (Art.
L. 122-5, L. 122-6-1 of French IP Code): in this
case the use without license is lawful.
 Or the use of the elements of code does not
correspond to any legal exception to Copyright: in
this case its use is subject to the rights provided
by the author of the elements used (vacant,
owners, etc.).

18. Case 2: Identify the corresponding licences
Principle: Respect the licenses bound to the
components used (including the integrity of their texts).
 Thus, the development of the software Gamma could lead
to two kinds of situations:
 A chain of unique rights (a first work produce a derivative work,
the derivative work is managed by the legal regime governing the
original work),
 a chain of multiple rights (assembling pre-existing elements
with different even divergent objectives, multiple licenses and
combinations).
 Assuming the second situation, the laboratory AFM must
carefully identify existing licenses and check on their
accounting.

19. Case 2: Check compatibility
 In the case of GNU GPL (the most frequent case),
consult the list referencing more that 50 licenses
models compatible or incompatible with each other:
http://www.gnu.org/licenses/license-list.fr.html
 The laboratory AFM should therefore pay special
attention to the compatibility of licenses bound
to components with the intentions for use and
dissemination.

20. Case 2: Check compatibility (2)
 The main danger comes from copyleft licenses (As a
reminder, they forbid distributors to add restrictions of uses,
although they have made changes).
 Indeed, these subversive licenses force the author who
used a copyleft licensed component to redistribute its own
contributions under the same conditions of use (freedom
to copy, use, study, modify and/or distribute).
 These licenses (e.g. GNU GPL) are a protection against
any appropriation of the code, as ultimate freedom.
 However, they also have defects:
 Hegemonic vocation,
 Very broad and intentionally ambiguous definition of derivative
works, creating an uncontrolled viral nature.

21. Case 2: Check compatibility (3)
Differences between the licenses (Source: CNRS)
Kind of licence Right to use, modify Obligation to diffuse Combination of a Obligation to diffuse
the source code and the changes of the program with another the source code
redistribute it source code under the one, imposes to modified (in case of
conditions of the initial distribute the result the diffusion of the
licence under the conditions of modified software)
the licence of the
original software
CeCill Yes Yes Yes Yes
GNU Yes Yes Yes Yes
LGPL Yes Yes No Yes
BSD Yes No No No

22. Case 2: Check compatibility (4)
 The TT manager of the laboratory AFM therefore
ensures, through a table and if necessary with the
assistance of a lawyer, the compatibility for the
licenses of the pieces of code used.
 Example of incompatibility: if the software
Gamma uses GPL code but the laboratory AFM
wants to grant its use via a license BSD, AFM
would then authorize the redistribution without
providing the source code, and this is prohibited by
the terms of the GPL license.

23. Case 2: Which alternative(s) in case of …
 In the event of incompatibility among listed licenses
several solutions would be considered:
1. Number of Anglo-Saxon licenses to date include illegal
clauses under French law (Example : clause of
warranty). These contradictions can be ignored.
2. It will be appreciated licensing models homogeneous.
Example: the license open source “CeCILL” provides that
in case of conflicting provisions between license
agreements (when, e.g. a software released under the
GNU GPL incorporates or would be incorporated into a
software distributed under CeCILL license), the GNU GPL
license may prevail.

24. Case 2: Which alternative(s) in case of …
3. If the license of a borrowed element of code prevents the
use of license desired, it is always possible to distribute the
software without the borrowed element. The licensee will
then be responsible for finalizing the software (especially
true for the case of libraries).
4. Obtain the exceptional consent of the assigns (difficult).
 If not, the laboratory AFM must find alternative
ways or face :
 possible legal suits by the IP rights owners,
 Adverse consequences in terms of image (especially within
the "free" community),
 A possible action of the company “Let’s Share” for breach
of the warranty provision.

25. 3. Define software use

26. Case 1: Stop Research & Development
activities on the software
 Situation in which the AFM laboratory management does not want
to continue research on the Gamma software.
 In terms of patent law, any employee or agent of the laboratory
AFM who wishes to do so has the ability to exploit the Gamma
invention , under conditions laid down by special agreement
concluded with the entity (Article R. 611-12 CPI).
 The laboratory will chose the license terms of use it intends to apply
to the software Gamma. This will affect the possible future
development by others:
 License owner,
 permissive free license,
 non-permissive free license,
 Double license.

27. Case 2: Continue the developments
 Situation in which AFM laboratory management wants to
continue research on the Gamma software.
 It should handle the user license granted to the company
“Let’s Share” without compromising future developments
and while anticipating as much as possible the risk of
incompatibilities among the licenses (discussed above).
 On this occasion, the multi-or dual-licensing is often one
of the solutions.

28. Case 2: Double or multiple licenses (1)
 Definition: A technique for the laboratory AFM to
concede several non-exclusive licenses on the software
Gamma.
 Advantages:
 The licensed content is therefore compatible with all the
licenses that are added, but also covering the licenses with
which they are themselves already compatible.
 This adds a freedom for the licensee : he as the choice of the
license.
 This limits the "copyleft" that applies to the overall work as the
licensee may use any right included in at least one of the licenses
(the provisions of the most permissive license prevail).
 If a license is revoked by a national court, the licensee may still
claim the rights conferred by the other.

29. Case 2: Double or multiple licenses (2)
 When is it useful? Useful to overcome the discords
between the different communities, so by overturning into
various "common pot".
 When is it useless? Relevant only if they can combine
multiple licenses that are originally incompatible.
 Thus concerning the Gamma software, it is likely to chose
the coexistence of the CeCILL license, which would meet
the requirements and needs of a French potential
licensee, but also a more international GNU GPL.

30. Practical Recommendations
 Establish a mechanism to ensure that the user has read
and accepted the license agreement attached to the
software.
 It is recommended to place a header in each of your
source files to indicate that they are covered by a
license.
 If the software contains a "loan“, it should be mentioned
in the header information of intellectual property on
this loan (names of authors, rights owner, year, license).
 The software documentation should clearly indicate
the license, authors and rights owner.
 A distribution file with an evocative name (ex: LICENSE,
or COPYRIGHT) and a copy of the license should appear
in each software "kit".