oss legal issues method

1!

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

fOSSa Conference Grenoble 17/11/2009

OSS & LAW

Luc Grateau

Direction du Transfert et de l’Innovation

!!"#"$%&#'$(

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

3!


!! 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)

Introduction: KNOWLEDGE and TECHNOLOGY TRANSFER AT INRIA

4!


© IN

RIA

U

niv

ers

ité

P

aris D

idero

t -

2

009 w

ww

.ante

link.c

om

•! more than 400 Open Source Projects

with open repositories involving INRIA and its partners (Universities, CNRS, etc…)

•! more than 1500 projects hosted on

INRIAGforge service

ROW :

•! ! 300 000 Projects with available source

code (not always open source components)

Massive code reuse => by INRIA

from INRIA

Introduction

Open Source Assets Management at INRIA

OW2 forge

INRIAGforge

Size: number of committers

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)

2008 New editor

Digitéo Foundation

Open Source Project

! 2 M lines of code

! 17 000 files

© INRIA Université Paris Diderot - 2009 www.antelink.com

After: Anthony Senyard and Martin Michlmayr

6!


Bazaar Phase

Technical maturity

Legal risk

Technical maturity

Legal Maturity

“Cathedral”

Functional Proof

of concept

Transition

Architectural

prototype

Legal m

atu

rity

0

% 100 %

0

% 100 %

First release

Unacceptable legal risk

Residual

risk (patent, etc…)

time

7!


Software: definition(s) Preparatory works (specifications)

Code Documentation

Scilab

Scilab kernel could be

a part of an

embedded software

2 levels

The level of the component (component license)

The level of the components based system (software license)

Software = components based (and collaboratively developed)

software typically an OSS project

Scicos

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”

9!


No (sol ownership)

yes

no

Code r

euse

(open s

ourc

e o

r not)

Collaborative development

yes

CASE 3: Medium risk

(contracts –

choice of exploitation license)

Freedom to exploit ? Freedom to enforce ?

CASE 4: High risk

(licenses compatibility

contracts – choice of exploitation license)

Freedom to exploit ? Freedom to enforce ?

CASE 2: Medium risk

(licenses compatibility)

Freedom to exploit ?

Freedom to enforce ?

CASE 1: Low risk

Freedom to exploit

Freedom to enforce

Freedom Matrix: Exploitation & enforcement

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

11!


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

Developers needs

12!


no yes

yes

Captu

re p

art

of

the v

alu

e

(except o

n s

erv

ice a

ctivitie

s)

Give access to the source Code

no

Exploitation intentions

Freeware (Free SaaS)

Proprietary Licensing

(Commercial SaaS)

Double/Dual

Licensing

Permissive

Licensing

(Open SaaS ?)

Mixt

Modes

13!


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)

Developers / Editor / Contributor obligations

3 Principles/key legal issues of responsible open source projects

contribution or edition

!! 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.

14!


Configuration

Documentation

Install

parameterization Kernel

Libraries

Graphic

Interface

BSD

LGPL

GPL

15!


This lead us to propose the notion of legal situation of a CBCD

software

BSD

LGPL

Proprietary

GNU GPL

Text integrity issue

(ex : mixt between

GNU GPL & LGPL)

No Licence

Summer intern developed

Component with no IPR

Assignment

16!


!! 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.

IPR Legal issues

17!


Confidentiel INRIA 26/11/08

!! 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

Legal situation (1/3) "

18!



!! 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

Legal situation 1st implementation (2/3)

19!



!! 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

a need for a software component implementation (3/3)

20!


no yes

no

Sele

ction o

f pre

-exis

ting

com

ponents

fr

om

Cert

ifie

d d

ata

base

Integration of IPR Tracking methodology

to the development process (continuous or sequential)

yes

Legal checking

controlled process

Content & legal

checking

controlled process

Content controlled

process

Post-development audit

oriented process

IPR Tracking models

21!



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)

Qualipso IPR tracking Methodology at INRIA

22!



1.! High level

Description of the software

(Description of the software Architecture, functionalities, modules or components)

2. Definition of the scope

of the Audit

(Main objectives)

3. Determination of the Legal

Situation

4. Problem Identification

and Risk Evaluation

5. Solve Blocking/Critical

Problem

6. Insurance, Dissemination

and IPR tracking

Qualipso Methodology implemented at INRIA

23!


Qualipso Methodology (QM)

Phase 1 : High level description Example

Example 1 : XtreemOS

Global position of XtreemOS layer in the software stack

24!


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)

QM Phase 1 : High level description Example

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

26!


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

BSD layer

GNU GPL V2 layer

QM

PHASE 2 : Defining strategy XtreemOS use-case

27!


Questionnaire (how the software

Legal situation is perceived

by the development Project Management team)

Automated

Legal Status Mining

“Fossology” (liked) (realization of a Legal Situation

from a source code archive by automated tool(S))

Perceived

Legal status (LS1)

Determined

Legal status (LS2)

Legal status analysis (LS1,LS2) ; # (LS1,LS2)

3. Determination of the Legal Situation (s)

Next Step: 4. Problem Identification

and Risk Evaluation

QM PHASE 3 :

28!


29!


30!


31!


Authorship issues Ownership issues

4. Problem Identification

and Risk Evaluation

Next Step: 5. Solve Blocking/Critical Problem(s)

Legal status analysis (LS1,LS2) ; # (LS1,LS2)

LS1 : features analysis of

perceived legal status

LS2 : features analysis of

automatically determined legal status

Problem identification / Risk Evaluation

# (LS1,LS2) : Analysis of differences

between perceived and automatically determined

legal status

Component License text

Integrity/modification issues

Component License “compatibility”

issues (upper & lower)

Technico - legal Issues

(i.e. static/dynamic

links study, etc…)

Other Issues (i.e. component redundancy)

Public Domain issues

Component with no License/headers

issues

Other Components Obligation

issues (i.e. : citation, etc…)

Towards Step 6. Insurance,

Dissemination and IPR tracking

QM PHASE 4 :

32!


5. Solve Blocking/Critical Problem(s)

Next Step: 6. Insurance, Dissemination and IPR tracking

Problem Solving by development team

Component rewriting

Component substitution

by similar functional component

Component elimination

Problem Solving by legal team

Negotiation of another compatible licence

for a critical Component

IPR acquisition Licensing in

Notification of unsolved

situations to the development team

2) QM PHASE 5 :

Problem solved by time (change of license)

Java/Sun components

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

34!


!! 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

CONCLUSION: IPR Legal issues of open source CBCD Software

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:

[email protected]

oss legal issues method

Technology

inria fossa grenoble

open source oswf

open source platform

open source components

inria size

open code project

software components

software quality