• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
FITT Toolbox: Choosing the right License
 

FITT Toolbox: Choosing the right License

on

  • 693 views

www.FITT-for-Innovation.eu

www.FITT-for-Innovation.eu

Statistics

Views

Total Views
693
Views on SlideShare
638
Embed Views
55

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 55

http://www.fitt-for-innovation.eu 54
url_unknown 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    FITT Toolbox: Choosing the right License FITT Toolbox: Choosing the right License Presentation Transcript

    • Choosing the right license: elements to guide technology transfer officers Emmanuel Gougé, 5/05/2011 www.FITT-for-Innovation.euExcept where otherwise noted, this work is licensed under a Creative Commons Attribution 3.0 License.
    • 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.
    • The aims of Software Licensing For the developer: visibility, promotion, financial gains. For the team, research lab: visibility, new partnerships, financial gains, public investments.
    • 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).
    • 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.
    • 3 main steps for license selection 1. Identify any pre-existing contractual constraints 2. Identify any pre-existing components 3. Define software use
    • 3 main steps for license selection 1. Identify any pre-existing contractual constraints 2. Identify any pre-existing components 3. Define software use
    • 1. Identify any pre-existing contractualconstraints
    • 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.
    • 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.
    • Case 2: Definition of a consortium agreementA consortium agreement is intended to organizethe relationships among partners in acollaborative 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.
    • Case 2: Consequences Solution: The consortium agreement solves the issue ofthe exploitation of the software Gamma and thus of theapplicable license. What about the lack of a consortium agreement? Thesoftware 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.
    • 2. Identify any pre-existing components
    • 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.
    • 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.
    • 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.
    • Case 2: Identify the applicable regime Either the use of pre-existing elementscorrespond to a legal exception to Copyright (Art.L. 122-5, L. 122-6-1 of French IP Code): in thiscase the use without license is lawful. Or the use of the elements of code does notcorrespond to any legal exception to Copyright: inthis case its use is subject to the rights providedby the author of the elements used (vacant,owners, etc.).
    • Case 2: Identify the corresponding licencesPrinciple: Respect the licenses bound to thecomponents used (including the integrity of their texts). Thus, the development of the software Gamma could leadto 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 mustcarefully identify existing licenses and check on theiraccounting.
    • Case 2: Check compatibility In the case of GNU GPL (the most frequent case),consult the list referencing more that 50 licensesmodels compatible or incompatible with each other:http://www.gnu.org/licenses/license-list.fr.html The laboratory AFM should therefore pay specialattention to the compatibility of licenses boundto components with the intentions for use anddissemination.
    • Case 2: Check compatibility (2) The main danger comes from copyleft licenses (As areminder, they forbid distributors to add restrictions of uses,although they have made changes). Indeed, these subversive licenses force the author whoused a copyleft licensed component to redistribute its owncontributions under the same conditions of use (freedomto copy, use, study, modify and/or distribute). These licenses (e.g. GNU GPL) are a protection againstany 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.
    • 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 softwareCeCill Yes Yes Yes YesGNU Yes Yes Yes YesLGPL Yes Yes No YesBSD Yes No No No
    • Case 2: Check compatibility (4) The TT manager of the laboratory AFM thereforeensures, through a table and if necessary with theassistance of a lawyer, the compatibility for thelicenses of the pieces of code used. Example of incompatibility: if the softwareGamma uses GPL code but the laboratory AFMwants to grant its use via a license BSD, AFMwould then authorize the redistribution withoutproviding the source code, and this is prohibited bythe terms of the GPL license.
    • 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.
    • 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.
    • 3. Define software use
    • Case 1: Stop Research & Developmentactivities 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.
    • 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.
    • 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.
    • 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.
    • 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".