This session will arm you with all the key information you need to to figure out Open Source software licensing issues, understand legal situation, etc. The aim is to present your obligations in terms of OSS licences, patent and intellectual property, before launching a project. Next, a method developed within QualiPSo project will be presented!

1. 1!
fOSSa Conference
Grenoble 17/11/2009
OSS & LAW
Luc Grateau
Direction du Transfert et de l’Innovation
!!"#"$%&#'$(
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

2. 2!
(Open Source ?) software and Law(s)
Back to the basics
Introduction (Open Source Assets Management at INRIA)
Open Source Project Lifecycle
Reminder IPR related to software & License
The Freedom Matrix : (co) ownership & code reuse
The developers needs vs obligations
Exploitation intentions
Intellectual Property Rights (IPR) Tracking Models
IPR Tracking Methodology
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

3. 3!
Introduction: KNOWLEDGE and TECHNOLOGY TRANSFER AT INRIA
!! Knowledge provider: Scientific Papers and Technical Reports
(Open Archive HAL-INRIA launched in April 2005)
!! Prototype Technology Provider
"! Software components / libraries and prototype applications (component based)
Proprietary or Open Source development licensing and spin-off creation
Software development and transfer policies
- G-forge based infrastructure
Dedicated support services (SED)
A focus on software “quality” (including IPR management issues in
development best practices)
A recent position Paper on Open Source (OSWF 2009)
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

4. 4!
Introduction
Open Source Assets Management at INRIA
•! more than 400 Open Source Projects
with open repositories involving INRIA and
2009 www.antelink.com
its partners (Universities, CNRS, etc…)
•! more than 1500 projects hosted on
INRIAGforge service
© INRIA Université Paris Diderot -
ROW :
•! ! 300 000 Projects with available source
code (not always open source components)
OW2 forge
Massive code reuse => by INRIA INRIAGforge
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau from INRIA Size: number of committers

5. 5!
Open Source Project Lifecycle
example Scilab: The open source platform for numerical
computation
! 1980 kernel for
numerical computation
1994 Open code project
2003 Consortium
(transition phase)
© INRIA Université Paris Diderot - 2009 www.antelink.com
2008 New editor
Digitéo Foundation
Open Source Project
! 2 M lines of code
! 17 000 files
After: Anthony Senyard and Martin Michlmayr
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

6. Legal Maturity
6!
0
100 %
%
Residual
risk
(patent, etc…)
First
release
Legal maturity
Legal risk
Unacceptable legal risk
100 %
0
“Cathedral” Transition Bazaar Phase time
%
Functional Proof Architectural Technical maturity
of concept prototype
Technical maturity
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

7. 7!
Software: definition(s) Preparatory works (specifications)
Code
Documentation
Scilab
Scicos
2 levels
The level of the component (component license)
The level of the components based system (software license)
Scilab kernel could be
a part of an
embedded software Software = components based (and collaboratively developed)
software typically an OSS project
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

8. 8!
IPR related to software & License
International law framework (Berne convention)
National / regional differences
Moral rights Owner = author(s)
Patrimonial rights =
Exploitation Right with 3 main features (reproduction, modification,
distribution of original or modified works)
Owner = employer of the author
License = contract on exploitation rights +
owner’s provisions (i.e. Citation provision) =>
“licence jungle”
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

9. 9!
Freedom Matrix: Exploitation & enforcement
CASE 2: Medium risk CASE 4: High risk
(licenses compatibility) (licenses compatibility
yes
contracts –
(open source or not)
Freedom to exploit ? choice of exploitation license)
Code reuse
Freedom to enforce ?
Freedom to exploit ?
Freedom to enforce ?
CASE 3: Medium risk
CASE 1: Low risk
(contracts –
choice of exploitation license)
no
Freedom to exploit
Freedom to enforce Freedom to exploit ?
Freedom to enforce ?
No yes
(sol ownership)
Collaborative development
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

10. 10!
OPEN SOURCE LICENSES (FSF/OSI)
“ROUGH” TYPOLOGY
PERMISSIVE LICENCES: no restriction on exploitation
Example : BSD
NON PERMISSIVE LICENCES:
Restriction provisions on exploitation
–! Limited at the component level as such Example : GNU LGPL
Non permissive in derivation
Permissive in composition
(when composed with other CB software proprietary or OSS with appropriate
“composition rule”/link)
–! Non limited (copyleft) Example : GNU GPL
Non permissive in derivation
Non Permissive in composition
Obligation to redistribute the CB software under the “component” licence
Not effective to control Software as a Service component based Software
–! GNU Affero GPL (to cover SaaS exploitation model) obligation to make available
the source code of the CB software integrating a component under GNU Affero
GPL
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

11. 11!
Developers needs
Use pre-existing components (do not reinvent the wheel)
Modify them
Compose components :
integrate parts, combine, link pre-existing components or ex-nihilo
components
Distribute the resulting Software
Open source licensed components fulfilled developer needs, with some
restrictions
Software development is a domain with no standardised terminology
Combined files, composed, integrated, derived works, « copyleft » licenses, « contaminantes », « viral »,
« hereditary », permissive, non permissive, … components, files, modules, etc…)
Vocabulary could be technology related. Sometimes defined within the license itself (Glossary). The
license denomination varies (GPL, GNU GPL, GNU GPL V2) and the licenses change with time. The
license attached to a component may change with time
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

12. 12!
Exploitation intentions
(except on service activities)
Capture part of the value Permissive
Licensing
Freeware
no
(Free SaaS) (Open SaaS ?)
Mixt
Modes
Proprietary Licensing Double/Dual
yes
(Commercial SaaS)
Licensing
no yes
Give access to the source Code
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

13. 13!
Developers / Editor / Contributor obligations
3 Principles/key legal issues of responsible open source projects
contribution or edition
1.! respect the provisions of the licenses attached to the used pre-existing
components (and their text integrity) Be aware of open code but not open source
licensed components
2.! verify the license compatibility of each pre-existing component with the
distribution license of the CBCD Software you intend to use
3.! be owner of the parts you produce (do not create uncontrolled “de facto” joint-
ownership with physical contributors/committers)
(ex : assignment of IPR –patrimonial- of summer interns working for you and
under your authority)
!! Respect other contracts/grants or IPR assets attached to components
i.e. : confidentiality provisions, special access right to sponsoring states, patents,
trademarks, moral rights of authors, etc…
If a license attached to a file is a clearly defined legal object, it is not the case for a set of
licences and other legal obligations attached to a (sometimes large) set of files and
components.
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

14. 14!
Graphic
Configuration Interface
Install Kernel
parameterization
LGPL
GPL Libraries
Documentation
BSD
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

15. 15!
GNU GPL
Text integrity issue
(ex : mixt between
GNU GPL & LGPL)
No Licence
Summer intern developed
Component with no IPR
Assignment
LGPL
Proprietary
BSD
This lead us to propose the notion of legal situation of a CBCD
software
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

16. 16!
IPR Legal issues
!! Assumption of « legal - development good practices »
We assume “development in good faith” when it comes to use pre-existing components
(nevertheless, developers should be aware and informed that advanced code reuse detection
technologies (nextB, palamida, blackduck, etc … ) can prove unfair practices or
counterfeiting of that kind; “development good practices” must be the rule and other
practices should be strictly prohibited).
This means, for example, that developers do not:
"! delete existing headers
"! do not modify licence attached to external components, without formal authorisation of the
IPR owners of the external components.
"! try to hide the origin of external code, by reengineering it, changing the names of variables
or doing other non authorised practices.
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

17. 17!
Legal situation (1/3)"
!! IDENTIFY RIGHTS AND OBLIGATIONS
#! Identify all authors (?=contributors)
#! Identify copyright owners (? employee)"
#! Identify all components, kind of dependencies
(! wording “combined”, “link”, “derived”)"
#! Contractual issues (Consortium agreement)"
#! Applicable law (moral and patrimonial rights)"
#! Related content repository
#! ...
$!NEED FOR A “HIGH LEVEL” FORMALISATION
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
Confidentiel INRIA 26/11/08

18. 18!
Legal situation 1st implementation (2/3)
!! 1 Position in chain of rights
#! Initial software
#! Derived software
#! Heterogeneous software
!! 2 IPR Owners
#! Morals rights
#! Patrimonial rights
!! 3 Legal condition of exploitation
#! Exploitation is restricted by an agreement
#! Exploitation is restricted by law
#! Exploitation is restricted by license (s) or license components compatibility
#! Exploitation Is restricted by another binding rule or legal provision
!! 2 Other enforceable IPR against software
#! Patent
#! Trademark
#! copyright
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
Confidentiel INRIA 26/11/08

19. 19!
a need for a software component implementation (3/3)
!! Definition of normalised OSS licence denominations
!! Data extraction with licence checker tools to feed Legal Situation Meta-data
!! Applied to a large set of source code from various development communities
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
Confidentiel INRIA 26/11/08

20. 20!
IPR Tracking models
Selection of pre-existing
Content controlled Content & legal
Certified database
yes
process checking
components
controlled process
from
Post-development audit Legal checking
no
oriented process controlled process
no yes
Integration of IPR Tracking methodology
to the development process
(continuous or sequential)
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

21. 21!
Qualipso IPR tracking Methodology at INRIA
INRIA proposed an generic IPRT methodology within Qualipso EC funded research project and
implemented it for its own organisation (Luc Grateau, Magali Fitzgibbon, Guillaume
Rousseau).
!! The aim is to set up an appropriate legal governance and process to determine and follow
the legal situation of a CBCD software during its development process in order to make sure
that this legal status is compliant with the development and exploitation intends of the CBCD
software editor.
!! This IPRT policy is actually in a test phase at INRIA and based on :
•! A training program for developers and support staff to foster their awareness of IPR
tracking issues for CBCD software
•! a multi-skilled team composed of technical staff, legal persons and technology transfer
officers in charge of the legal governance of the software development
•! An IPR tracking methodology using software tools (i.e. FOSSology license checker)
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
Confidentiel INRIA 26/11/08

22. 22!
Qualipso Methodology implemented at INRIA
1.! High level
Description of the software 4. Problem Identification
(Description of the software
and Risk Evaluation
Architecture, functionalities, modules or components)
2. Definition of the scope
of the Audit 5. Solve Blocking/Critical
Problem
(Main objectives)
3. Determination of the Legal 6. Insurance, Dissemination
Situation and IPR tracking
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
Confidentiel INRIA 26/11/08

23. Qualipso Methodology (QM)
23!
Phase 1 : High level description Example
Example 1 : XtreemOS
Global position of XtreemOS layer in the software stack
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

24. 24!
QM Phase 1 : High level description Example
Example 1 : XtreemOS
Refined high level description of the « XtreemOS » layer showing main functional
domains of two sub-layers (middleware closed sub-layer and system closed sub-layer)
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

25. 25!
QM PHASE 2 : Defining strategy
Phase 2 is aiming at defining the IPR strategy in relation to the
« high level description » of the software.
The licensing scheme of a CBCD software could be function of
which part of the software you consider, and the related questions
you might have to define and monitor the IPR tracking process
would depend on the development phase and the licensing or
exploitation schemes associated to each relevant software layer
or functional domain. i.e. :
•! if you planned not to distribute the software, but to give access to
it as a “software as a service”, the legal issues are quite different
as if you planed to distribute it under as permissive BSD like
license.
•! If you planned to collaboratively develop the software, issues are
different of in-house development
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

26. 26!
QM
PHASE 2 : Defining strategy XtreemOS use-case
BSD layer
GNU GPL V2 layer
View of the « XtreemOS » licensing strategies
XtreemOS Grid support layer, XtreemOS-G : BSD licensing scheme
XtreemOS Foundation layer, XtreemOS-F : GNU GPL V2 licensing scheme
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

27. QM PHASE 3 : 27!
3. Determination of the Legal Situation (s)
Questionnaire Automated
(how the software Legal Status Mining
Legal situation
is perceived “Fossology” (liked)
by the development (realization of a Legal Situation
Project Management team) from a source code archive
by automated tool(S))
Perceived Determined
Legal status Legal status
(LS1) (LS2)
Next Step: 4. Problem Identification Legal status analysis
and Risk Evaluation (LS1,LS2) ; # (LS1,LS2)
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

28. 28!
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

29. 29!
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

30. 30!
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

31. QM PHASE 4 : 31!
4. Problem Identification Legal status analysis
and Risk Evaluation (LS1,LS2) ; # (LS1,LS2)
LS1 : # (LS1,LS2) : LS2 :
features analysis of features analysis of
Analysis of differences
perceived legal status automatically determined
between perceived
legal status
and automatically determined
legal status
Problem identification / Risk Evaluation Technico - legal
Component Issues
Authorship issues Ownership issues (i.e. static/dynamic
License text
links study, etc…)
Public Domain Integrity/modification
Other Issues issues issues
(i.e. component redundancy)
Component Component License
with no License/headers “compatibility”
issues issues (upper & lower)
Other
Components Obligation
issues (i.e. : citation, etc…)
Towards Step 6. Insurance ,
Next Step: 5. Solve Blocking/Critical Problem(s)
Dissemination
and IPR tracking
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

32. 2) QM PHASE 5 : 32!
5. Solve Blocking/Critical Problem(s)
Problem Solving by development team
Component
Problem solved by time
Component substitution Component
(change of license)
rewriting by similar elimination
Java/Sun components
functional component
Problem Solving by legal team
Notification
Negotiation of another
IPR acquisition of unsolved
compatible licence
Licensing in situations
for a critical Component
to the development team
Next Step: 6. Insurance, Dissemination and IPR tracking
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

33. 33!
IPR Tracking CONCLUSION
Intellectual Property Rights Tracking Methodology for components
based and collaboratively developed software is proposed within
Qualipso EC Project and under testing at INRIA.
A governance or coordination level in charge of IPR tracking issues
A process using FOSSology as license checker
A better defined and enhanced quality software
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

34. 34!
CONCLUSION: IPR Legal issues of open source CBCD Software
!! Importance of Academic Actors for the Open Source Ecosystem
!! Shared awareness for legal quality control improvement of components based
and collaboratively developed software (CBCDS) from academic world
•! Toward a Robust Legal Framework for OSS
!! LEVERAGE STATE-OF-ART TO FULFILL OPEN SOURCE ECOSYSTEM NEEDS
New legal tools : Initiative like CeCILL family - compliant to European legal framework
(Define applicable law and comply with liability regulation)"
New Audit technologies or tools (FOSSology, OSLC, etc…),
New Business opportunity (Palamida, Black Duck, NextB, Neolex,….)
New insurance tools for residual risk (Lyods of London and OSRM …)
!! BUILD APPROPRIATE LEGAL FRAMEWORK AND PROCESS
Methodologies (IPR Tracking, Audit, Risk analysis)
Dedicated IPR Management Tools
Skills and team building
!! Aim : Increasing trust in CBCD software
Improve legal safety for Contributors, Editors, Customers, Service and product providers
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau

35. 35!
!! References:
1 Open (Research) issue toward a legal framework for OSS, FOSDEM 2008 ROUSSEAU
http://libresoft.es/Activities/Research_activities/downloads/fosdem2008/papers/INRIA-GR_20080218-final.pdf
2 Guide de diagnostic du logiciel (INRIA Internal document, DTI/SPIV 2006) GRATEAU and FONTAINE
3 Toward an open-source technology transfer model DALLE and ROUSSEAU
Proceeding of the 4th Workshop on Open Source Software Engineering
4 IPR Tracking: A methodology for Component Based and Collaboratively Developed software
L. GRATEAU, M. FITZGIBBON, G. ROUSSEAU Qualipso EC funded Project, Activity 1 “Legal issues”
Deliverable D1.4.1
Diffusion Status : Public January 26th, 2009
Final version: 20th November 2009
!! Contacts:
Patrick.Moreau@inria.fr
!!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau