Paroles d’experts – Gérer la propriété intellectuelle des logiciels : un enjeu croissant

Pour aller plus loin, l’IEEPI et Magali Fitzgibbon vous proposent les formations suivantes :

• Cycle Propriété Intellectuelle et Licensing des Logiciels
• Gérer la PI des logiciels : méthodologie et outils

Paroles d’experts : Magali Fitzgibbon.

L’IEEPI donne la parole à ses experts, aujourd’hui Magali Fitzgibbon, IP Legal expert – chargée de mission à la direction générale déléguée au transfert et aux partenariats d’Inria.

Elle nous propose une analyse sur :
Gérer la propriété intellectuelle des logiciels : un enjeu croissant

Marc Andreessen annonçait il y a près de 10 ans :

Software is eating the world.

Le monde d’aujourd’hui ne peut que lui donner raison, tant le logiciel a effectivement envahi nos vies. Ceci est vrai en tant qu’individus au quotidien, que ce soit à travers l’utilisation de notre smartphone, notre voiture, notre machine à laver; ça l’est tout autant pour l’industrie, qui dépend de plus en plus des logiciels, notamment open source. Si le logiciel a ainsi bouleversé ou contribué à faire évoluer les modèles économiques, les comportements, les façons de produire, il a également eu une incidence sur la façon d’appréhender et de gérer la propriété intellectuelle attachée à cet objet atypique du droit.

En quoi le cas du logiciel est-il particulier ?

L’approche des enjeux en droit de la propriété intellectuelle se fait essentiellement à travers le concept de propriété que l’on cherche à protéger et du monopole d’exploitation associé. Or, les pratiques de développement et les modes de production des logiciels font que cette propriété intellectuelle est extrêmement morcelée : les composants logiciels développés en interne d’une entité « cohabitent » avec des composants tiers open source, les composants d’une filiale ou encore ceux des sous-traitants.  Dans ce contexte, les enjeux dans la gestion de la propriété intellectuelle des logiciels résident davantage dans le contrôle de la liberté d’exploitation de ces assemblages de composants parfois complexes, pour en capter une partie de la valeur d’usage, que dans leur pleine propriété.

Comment se contrôle ou s’évalue cette liberté d’exploitation, par exemple lorsqu’on réutilise des composants open source ?

Si les différents composants d’un logiciel doivent être interopérables entre eux sur le plan « techniques », ils doivent également être interopérables sur le plan juridique : il faut dans un premier temps identifier quelle est la licence rattachée à chaque composant open source, pour s’assurer dans un second temps de sa compatibilité avec la stratégie d’exploitation ou de distribution de l’entreprise. Au fil d’une version d’un logiciel à une autre, tout ceci peut bien évidemment évoluer, en fonction des composants open source ajoutés, retirés ou mis à jour. Le logiciel est un objet qui ne cesse d’évoluer, et il en va de même par conséquent pour son statut juridique.

Par ailleurs, au-delà de la question des comptabilités de licences entre les composants d’un même logiciel, il est souvent important, pour une entité, de s’assurer de la provenance d’un composant open source donné. On peut vouloir s’assurer, par exemple, que la version du composant open source intégrée est bien celle pour laquelle une faille de sécurité précédemment identifiée a été corrigée.

Cependant, cette analyse ou vérification nécessite en premier lieu d’accéder à l’information « brute » à examiner à cette fin. Or, le simple fait d’être capable d’identifier, mais aussi de tracer de façon certaine la provenance d’un composant logiciel et de métadonnées juridiques associées, n’est pas toujours une chose aisée. Ceci est d’autant plus vrai dans des environnements où les modes de productions sont complexes, du fait de leur éclatement, de leur temporalité et du nombre d’acteurs impliqués.

Est-il possible de s’outiller pour cela ?

Il y a tout d’abord une méthode et des procédures à mettre en place pour traiter ces questions. Ce type d’exercice ne s’improvise pas. Dès 2008, Inria avait notamment publié, dans le cadre d’un projet européen, une méthodologie d’analyse de la propriété intellectuelle des logiciels. Un certain nombre d’entreprises pour lesquels ces enjeux ont été identifiés comme critiques,  ont par exemple organisé cette activité en mettant en place des services de compliance, en charge de traiter ces questions. Les employés dans ces services ont souvent des profils à la fois techniques et juridiques, tout en étant imprégnés des enjeux business de l’entité.

En ce qui concerne les outils, les développeurs ont depuis longtemps à leur disposition des environnements de développement (gestionnaires de versions, de dépendances…) qui assurent une certaine traçabilité. Cependant, ces outils (même s’ils peuvent aider) n’ont pas été conçus pour identifier de façon certaine la provenance des composants ou pour procéder à des analyses juridiques de façon automatisée, qui plus est sur des gros corpus de code source.

Des outils dédiés à ce type d’exercice sont arrivés sur le marché il y a une dizaine d’années. Fossology, développé par une communauté open source, s’est rapidement imposé comme un outil parmi les plus robustes pour automatiser l’identification des mentions des licences dans les en-têtes des fichiers de code source. Des éditeurs propriétaires proposent également des outils  identifiant les licences, mais aussi la provenance des composants open source.

Pouvez-vous indiquer un défi important à relever aujourd’hui ?

Il reste aujourd’hui des défis liés à notre capacité d’identifier, de façon certaine, les composants open source tiers et de leur provenance. Les outils qui permettent cela s’appuient sur une base de connaissances, contenant un certain nombre de code open source, et avec lesquels le code source du logiciel analysé est comparé. Lorsqu’une correspondance est trouvée, elle est notifiée. Cela signifie que pour être efficace, l’outil a besoin de s’appuyer sur une base de connaissances aussi complète et exhaustive que possible.

Cependant aujourd’hui, les éditeurs d’outils utilisent chacun leur propre base de connaissances « propriétaire ». Or, cela soulève deux choses importantes :

• Compte tenu de la masse de code open source disponible aujourd’hui, il est très compliqué de produire et maintenir une base de connaissances qui se veut exhaustive. Les coûts liés sont importants et il existe encore des verrous techniques ; les efforts pour créer et maintenir une telle infrastructure gagneraient à être mutualisés et de se différencier, pour les acteurs de l’audit de code, sur les applications et les services proposés autour.
• Le fait de s’appuyer sur des bases de connaissances fermées n’est pas transparent vis-à-vis des utilisateurs, qui ne savent pas sur quelle matière s’appuient concrètement leurs analyses de compliance.

Existe-t-il des initiatives cherchant à apporter une solution à cela ?

Oui, il existe une initiative d’envergure mondiale appelée Software Heritage, lancée en 2016 par Inria Software Heritage œuvre à la mise en place d’une infrastructure pérenne pour collecter, indexer, préserver et rendre accessibles tous les codes sources disponibles.

Cette initiative prendra prochainement la forme d’une fondation, l’objectif étant de créer et maintenir, à l’instar des standards du web au W3C,  une « commodité » ouverte à tous, tout en mutualisant les coûts auprès d’une communauté d’acteurs soutenant le projet.

C’est une initiative qui dépasse les seuls enjeux industriels,  et qui adresse également des  enjeux scientifiques et sociétaux. Cependant, l’intérêt que représente cette initiative pour la compliance dans l’industrie est évident. Software Heritage va en effet apporter deux contributions importantes :

• Un identifiant unique pour chaque version d’un logiciel donnée, correspondant à un « numéro de série »;
• L’accès à une base de connaissance ouverte, avec un certain nombre d’informations associées concernant la provenance du logiciel, à différent niveaux de granularités allant d’une version donnée à un fichier.

La mission de Software Heritage se limite à créer et maintenir cette archive de code source, et n’a donc pas vocation à commercialiser une série d’outils ou de service dédiés à l’analyse juridique de code. C’est en revanche une infrastructure sur laquelle les acteurs proposant ce type de services et de produits et les industries utilisant du logiciel pourront s’appuyer. L’avenir dira si les gens sauront s’en emparer !

Pour aller plus loin, l’IEEPI et Magali Fitzgibbon vous proposent les formations suivantes :

• Cycle Propriété Intellectuelle et Licensing des Logiciels
• Gérer la PI des logiciels : méthodologie et outils