OSS Legal issues method


Published on

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!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OSS Legal issues method

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 14! Graphic Configuration Interface Install Kernel parameterization LGPL GPL Libraries Documentation BSD !!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28! !!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
  29. 29. 29! !!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
  30. 30. 30! !!INRIA fOSSa Grenoble 17/11/2009 Luc Grateau
  31. 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. 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. 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. 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. 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