Analyse de la propriete intellectuel

Analyses PI de Code

Séminaire Jdev 2013 – 5 septembre 2013

Magali Fitzgibbon -Technology Transfer and Innovation Department - CC BY-NC-ND 2.0

Gouvernance Juridique dans les projets de développement


o Pourquoi se soucier de la PI dans un projet de développement issu d’un labo

public? « Je sais ce que je veux faire… Mais ai-je le droit de le faire ? Contrefaçon/respect de la licence d’un composant exogène

o Mais au-delà :

Valeur ajoutée pour un logiciel / élément de confiance vis-à-vis des partenaires

Image de marque

o Les développeurs souvent en première ligne (façonnent le code mais aussi… sa

PI )

Cf. présentation INRA/Nathalie

Gandon


exploitation “Licensing out”

Choix de modèle économique d’exploitation /diffusion « Licensing out »

Politique de « Licensing in »

Incidence de la réutilisation de code préexistant (le web est là ;-)

STRATEGIE (compatibilité juridique)

Statut juridique des composants Licence attachée aux composants

Statut juridique du logiciel

“Licensing in”

L1

Réutilisation de Code (composants pré-existants)

Système à base de composants

Logiciel : ensemble de composants (avec de nouveaux “ex-nihilo”composants)

Incidence du contexte “humain”


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 (surtout au début!)

Quel degré de prise en compte de la PI dans un projet?


Preuve de concept (le logiciel n’est pas une fin)

devient éventuellement un projet suivi et se construit…

… commence à faire l’objet d’investissements importants

… puis peut parfois faire l’objet d’un transfert

Le logiciel dans la recherche publique

How to master IP in an wide, open world ?



Ce vers quoi Inria est allé…et souhaite développer o Analyse PI – 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” et de son historique Avec un couplage entre une méthode et des outils pour identifier et qualifier

l’information

Projet EU Qualipso « Proposed IPR tracking methodology » (L. Grateau, M. Fitzgibbon, G. Rousseau)

Spin-off Antelink


Votre mission, si vous l’acceptez… o Définir le statut juridique d’un logiciel…

C-à-d ce qu’on a le droit de faire ou pas avec o … pour évaluer sa conformité avec une stratégie de diffusion donnée

Notion de statut juridique du logiciel (au sens de la méthodologie proposée)


La combinaison de 5 catégories d’éléments qui ont une incidence en termes de

propriété et de liberté d’exploitation pour le logiciel :

1. La nature du logiciel (développé ex-nihilo, dérivé d’un logiciel préexistant, réutilisation de librairies externes)

2. Les auteurs/ayants droits

3. Les contrats impactant le logiciel

4. Autres droits de propriété intellectuelle opposables

5. Autre règlementation/législation applicable

Déroulé de la méthode utilisée


STEP 1: Detailed description of the

Software Prototype (Architecture, components…)

STEP 2: Defining intentions of use

STEP 3: Determination of legal status

STEP 4: Identification of problems

Risk evaluation

STEP 5: Identification of solutions

STEP 6: Packaging and

dissemination/assignment

Situation perçue par les auteurs

Situation vue par les outils

Etape n°1: Quelques bonnes raisons de formaliser l’architecture du logiciel analysé

o Identifier clairement l’objet de l’analyse

Diversité des logiciels et de leurs architectures dans les laboratoires Ne retenir que ce qui nous intéresse pour l’analyse…

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” pour tout le monde

Compréhension commune de l’objet de l’analyse


Use Case DIET software (monitoring High Performance Computing Infrastructures) (1)

Source: Qualipso – Report on the proposed IPR tracking methodology – 16/12/2009 – www.qualipso.org


DIET CASE : A software for monitoring High Performance Computing Infrastructures to be licenced to a start-up

http://www.qualipso.org/



Use Case DIET software (monitoring High Performance Computing Infrastructures) (1)


o Pour savoir ce qu’on chercher à valider… o Pour définir la marge de manoeuvre dont on a besoin

o Use case DIET: licence double CeCILL v2 et propriétaire

Etape n°2: définition de la stratégie de diffusion


o On part toujours du point de vue des auteurs du logiciel

Source d’information première Maîtrise du code analysé Essentiellement basé sur du déclaratif

o Cette “situation perçue” est souvent incomplète

Quelle traçabilité au bout de 5 à 20 ans, surtout si absence de suivi de la PI ? Défilé de contributeurs au code et dispersion de l’information Les gens peuvent oublier de bonne foi

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

Etape n°3 a) – Définition du statut juridique

La “situation perçue”


Etape n°3 b) Définition du statut juridique

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 :

Gain de temps (et donc réduction des coûts d’analyse) Possibilité de descendre à un niveau de granularité plus fin pour l’analyse Bon outil de dialogue


Attention! Ne pas oublier que toute donnée doit être qualifiée (notamment juridiquement) !

o Comparer une liste d’informations “brutes” n’est suffisant ou fiable

o Les outils ne font pas à eux seuls toute l’analyse!

L’information doit être qualifiée


o Raison pour laquelle la situation perçue des auteurs reste pertinente pour l’analyse

o Raison pour laquelle le dialogue entre juriste/développeur/chercheur/ CPPI est

essentiel

Couplage intelligent des expertises des uns et des autres

Situation perçue par les auteurs

Situation vue par les outils


Etape n°4 et 5 – Identification des risques et des solutions

o Identifier pour documenter et gérer le risque… o … identifier des actions correctrices pour mettre en conformité le code

Solutions techniques

Solutions juridiques


Use Case DIET software (monitoring High Performance Computing Infrastructures)




Conclusion – Notre retour d’expérience à ce stade :

o Le travail d’équipe entre juriste/chercheur/développeur/CPPI au cœur de tout

o L’association d’une méthodologie d’analyse à de l’outillage est un élément de

professionnalisation o Une vraie valeur ajoutée pour un projet

Évolution de l’état de l’art La notion de qualité juridique rentre dans les process qualité de développement

o « Le geek, c’est chic » – la sensibilisation des développeurs à la PI est

importante… mais l’intérêt et la curiosité du juriste pour la matière logicielle le sont ausso


Merci pour votre attention !
