1. Workshop Juridique GTLL SYSTEMATIC –
02/04/2013
Compliance: enjeux et pratique
Magali Fitzgibbon – Technology Transfer and Innovation Department - CC BY-NC-ND 2.0

2. Une brève présentation d’Inria…
Inria : institut de recherche en informatique et en automatique
8 centres de recherche + un siège (directions fonctionnelles)
Plusieurs missions dont :
 la recherche fondamentale et appliquée
 la diffusion des connaissances scientifiques - Transfert de technologie
 contribuer à la normalisation - Edition open source de
logiciels prototypes
 réaliser des systèmes expérimentaux
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

3. Des questions récurrentes lors du montage d’opérations de transfert /
éditions open source à Inria
 Qui sont les propriétaires du logiciel ?
 Quelle liberté d’exploitation?
Bref, dispose-t-on des droits d’exploitation nécessaires pour mettre en oeuvre le projet?
Des questions simples en apparence… mais parfois difficiles à répondre dans la
pratique
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

4. Software development process
(seen from the legal / TTO point of view)
Licensing in  STRATEGY (compliance)  Licensing out
Code reuse Software : set of components exploitation
(pre-existing components) (with new “ex-nihilo”components)
L Licensing out
1 choice
Component
Licensing in based systems
Policy
Legal status of software
(Not so easy to defined)
Legal status of components
Component’s licence
Usually well defined
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

5. Compliance – des enjeux bien réels
Contrats de transfert de
Contrats/exploitation prototypes (recherche publique) –
« industriels » licences open source
confiance/ qualité
Clauses de garanties
Contrefaçon
sur la PI
(réclamation de
tiers) Image
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

6. Compte tenu de ces enjeux:
o Comment s’assurer de la compatibilité des licences au sein de
systèmes à composants ?
o Quelle mise en œuvre possible des analyses de compatibilité de
licences ?
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

7. Dans la pratique, l’exercice peut s’avérer complexe…
o Des licences libres/open source nombreuses et variées (“jungle des licences”)
o Un cas simple: les cas de compatibilité expresse entre 2 licences
 Exemple: compatibilité expresse de la CeCILL v2 avec la GNU GPL
o Pour les autres cas, utiliser les typologies de licences pour évaluer la marge de
manoeuvre disponible concernant:
 Le choix de licence pour redistribuer le composant réutilisé
 Le choix de licence pour redistribuer l’assemblage intégrant le composant réutilisé
o Attention aux obligations “secondaires” parfois imposées par les licences!
 Exemple: obligations de citation contraignantes, au point de ne pas être compatibles avec
d’autres licences
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

8. Autres éléments impactants
o Grande diversité de logiciels et d’architectures logicielles à Inria
 quel périmètre pour l’analyse? Quelle compréhension de l’objet analysé?
o Des logiciels développés :
 Parfois sur des durées longues…
 … avec un “défilé” de contributeurs…
 … des problématiques IP qui ne sont pas toujours au coeur des préoccupations
 Quelle traçabilité des composant exogènes intégrés et de leur statut juridique?
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

9. Ce vers quoi Inria est allé…
o Compatibilité de licences – un sujet qu’on aborde notamment:
 En équipe (juriste PI/Licensing-chargé d’affaire/développeur et/ou chercheur)
 En partant de la “matière première”
 Avec un couplage entre une méthode et des outils pour identifier et qualifier
l’information
Projet EU Qualipso Spin-off Antelink
« Proposed IPR tracking methodology » (L.
Grateau, M. Fitzgibbon, G. Rousseau)
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

10. I. Analyse de compatibilité et architectures logicielles
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

11. Quelques bonnes raisons de formaliser l’architecture du logiciel analysé
o Identifier le périmètre de l’analyse
 Distinguer les dépendances “juridiques” des autres dépendances de l’environnement du
logiciel
o Cas des logiciels avec une stratégie multi-licensing à l’échelle du composant
 Exemple du logiciel SOFA: stratégie “open core” en GNU LGPL + modules sous licences
libres ou propriétaires
o Disposer d’un support de discussion “accessible”
 Compréhension commune de l’objet de l’analyse
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

12. Using software’s architecture – the example of DIET software (monitoring High Performance
Computing Infrastructures)
Source: Qualipso – Report on the proposed IPR tracking methodology – 16/12/2009 – www.qualipso.org
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

13. II. Quelle traçabilité des composants exogènes et
de leur statut juridique?
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

14. La “situation perçue”
o Inria part toujours du point de vue des auteurs du logiciel pour recenser les
composants exogènes
 “Situation perçue”
o Cette “situation perçue” est souvent incomplète
 Les enjeux PI ne sont pas toujours une priorité au début d’un projet (POC)
 Quelle traçabilité au bout de 5 à 20 ans, en l’absence de méthode et d’outils de suivi (les
prototypes de recherche sont peu documentés)
o Cette “situation perçue” nécessite le plus souvent d’être objectivée/complétée
 Implique de trouver une source d’information complémentaire
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

15. Objectiver la situation perçue avec les outils de traçabilité
o Les « ouvre-boîtes » pour accéder aux informations juridiques du code:
 License checkers
 Détection de composants open source (comparaison de code)
o Les bénéfices pour Inria:
 Gain de temps (et donc réduction des coûts d’analyse)
 Possibilité de descendre à un niveau de granularité plus fin pour l’analyse
 Aide à l’industrialisation des processus
o Conséquence plus générale liée aux outils:
 L’information juridique devient aussi « open » que le code source des logiciels
libres…
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

16. Attention! Ne pas oublier que toute donnée doit être qualifiée
juridiquement!
o L’identification de l’origine des composants et de leur licence est un début…
o Mais comparer une liste d’information “brute” n’est suffisant ou fiable
o Les outils ne font pas à eux seuls toute l’analyse!
L’information doit être qualifiée (risques de faux positifs/négatifs)
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

17. Exemples
o Code source généré avec un éditeur comme le framework Eclipse
 Mentions de la licence EPL non pertinentes
o Licence du projet open source d’origine différente de la licence des en-têtes
 Cas des headers qui n’ont pas été mis à jour suite à un changement de licence
o Licences « gênantes » dans des fichiers en réalité non pertinents pour l’analyse
 Makefiles
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

18. o Raison pour laquelle la situation perçue reste pertinente pour l’analyse
 Confronter situation perçue et objectivée pour parvenir à une information
qualifiée
o Raison pour laquelle le dialogue entre juriste/développeur/chercheur/
chargé d’affaire est essentiel
 Couplage intelligent des expertises des uns et des autres
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

19. CONCLUSIONS – RECOMMANDATIONS
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

20. o Concernant les enjeux liés aux problématiques de compatibilité de licences:
 Une prise de conscience dans l’édition logicielle
 Une exigence croissante de l’écosystème, concernant la qualité juridique des logiciels
(évolution de l’état de l’art)
 L’émergence d’un marché relativement récent pour l’outillage de l’audit de code et la
gouvernance open source l’illustre bien
o Le retour d’expérience d’Inria concernant la pratique:
 Le travail d’équipe entre juriste/chercheur/développeur/chargé d’affaire au cœur de tout
 L’association d’une méthodologie d’analyse à de l’outillage est un élément de
professionnalisation
 Le « challenge » pour Inria : aller vers des démarches de suivi pendant le processus de
développement
 « Le geek, c’est chic » – l’intérêt et la curiosité du juriste pour la matière logicielle est
souhaitable
Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-
NC-ND 2.0

21. Merci !
www.inria.fr
Report on the proposed IPR Tracking methodology (L. Grateau, M. Fitzgibbon, G. Rousseau)
http://www.inria.fr/content/download/6143/55776/version/2/file/Methodologie-d-analyse-IPR.pdf
Qualipso EU funded project
www.qualipso.org
Guide d’approche et d’analyse des licences de logiciels libres (S. Steer, M. Fitzgibbon)
http://www.inria.fr/content/download/5892/48431/version/2/file/INRIA_guide_analyse_licences_libre
s_vf.pdf
Recueil de fiches explicatives de licences libres (S. Steer, M. Fitzgibbon)
http://www.inria.fr/content/download/5892/48431/version/2/file/INRIA_guide_analyse_licences_libre
s_vf.pdf
Magali Fitzgibbon magali.fitzgibbon@inria.fr
http://www.linkedin.com/pub/magali-fitzgibbon/3a/390/76a