Gérer la propriété intellectuelle dans les projets à base de logiciels libres

Transcription

1 Gérer la propriété intellectuelle dans les projets à base de logiciels libres Robert VISEUR Université de Mons, Faculté Polytechnique, Place du Parc, 20, B-7000 Mons, Centre d Excellence en Technologies de l Information et de la Communication, Rue des Frères Wright, 29/3, B-6041 Charleroi, [email protected]. Résumé Les logiciels libres sont progressivement devenus d'utilisation courante dans les développements de logiciels commerciaux. Les entreprises ne disposent cependant pas toujours de la connaissance des droits et des obligations découlant de l'utilisation de logiciels couverts par des licences libres. Les logiciels libres ne sont par ailleurs pas concernés par le seul droit d'auteur mais peuvent l'être par d'autres types de propriété intellectuelle, comme les marques ou les brevets. Ce papier propose dès lors un état de l'art synthétisant les principaux risques auxquels s'expose l'entreprise en cas d'utilisation de composants libres, ou d'architectures ouvertes couvertes par des licences hétérogènes. Nous présenterons ensuite trois pistes de solutions, ainsi que la première version d'un outil basé sur des logiciels libres courants et permettant l'automatisation d'audits juridiques de codes sources. Mots-clés Open Source, logiciel libre, gouvernance, licence, propriété intellectuelle, audit, Ohcount. Abstract Free softwares become commonly used in commercial software development. However companies do not always own knowledge about rights and obligations arising from the use of softwares covered under free licenses. Free softwares are not only covered by copyright but can be by other types of intellectual property such as trademarks or patents. This paper therefore proposes a state of the art summarizing the key risks facing the company in case of use of free components, or open architectures covered by heterogeneous licenses. We then present three solutions, and the first version of a tool based on common open source softwares for automating legal audits of source codes. Keywords Open Source, free software, governance, license, intellectual property, audit, Ohcount. 1

2 1. Contexte Bien du chemin a été parcouru depuis la publication du noyau Linux par Linus Torvalds en Si le logiciel libre a gardé pendant longtemps l'image de logiciels développés par des hobbyistes, cela a progressivement changé avec la mise en avant du caractère innovant de ces logiciels (Von Hippel, 2001) et, surtout, l'implication croissante des entreprises dans leur développement (Fitzgerald, 2006). A ce niveau, le lancement du projet Mozilla par la société Netscape marque une étape importante dans l'histoire du logiciel libre (Viseur, 2011). Plus largement, la mise en œuvre de systèmes informatiques recourant à des architectures ouvertes, mêlant des API ouvertes et des composants couverts par des licences hétérogènes, libres ou propriétaires, ne va pas sans poser de nouveaux défis en matière de propriété intellectuelle (Alspaugh et al., 2009b). Les enjeux sont importants pour les entreprises. Après avoir scanné 635 applications mobiles open source sur l'apple Appstore, OpenLogic (2011) a révélé que 71% des applications sous licence Apache, GPL ou LGPL ne respectaient pas les termes de leur licence. Lors de la publication (sans licence) du logiciel électoral belge, du code source sous licence GPL v2 a été découvert (Hillenius, 2009). La violation de licences libres peut pourtant donner lieu à des actions en justice (Henley et Kemp, 2007). Ce papier est organisé comme suit. Nous commençons par un état de l'art présentant les caractéristiques des licences libres, puis synthétisant les principaux risques auxquels s'expose l'entreprise en cas d'utilisation de composants libres, ou d'architectures ouvertes couvertes par des licences hétérogènes. Nous présenterons ensuite trois pistes de solutions pour gérer les risques identifiés. Nous présentons ensuite la première version d'un outil basé sur des logiciels libres courants et permettant l'automatisation d'audits juridiques de codes sources. Nous terminons par une discussion mettant notamment en avant les perspectives futures pour notre recherche. 2. Licences de logiciels libres Le logiciel libre est défini à partir de 4 libertés: la liberté d'exécuter le logiciel, de l'étudier, d'en redistribuer des copies et de le modifier (gnu.org). Les licences de logiciels libres garantissent ces quatre libertés, qui impliquent la mise à disposition du code source du logiciel (Montero et al., 2005). L'appellation open source est parfois préférée à celle de free software (logiciel libre). Ce terme est défini par l'osi sur base d'une liste de 10 critères appelée Open Source Definition (OSD). A de rares exceptions près (comme dans le passé la licence Apple Public Source License v1.0 et v1.2), les licences reconnues comme libres par la FSF sont reconnues open source par l'osi, et vice versa. Les différences entre la Free Software Foundation (fsf.org) et l'open Source Initiative (opensource.org) sont essentiellement d'ordre idéologique. La première met en avant une forme d'éthique (la liberté du logiciel est vue comme une nécessité) ; la seconde insiste sur l'efficacité du modèle de développement collaboratif caractéristique des développements libres et open source. Certains auteurs préfèrent parler de FOSS (Free / Open Source Software) ou de FLOSS (Free / Libre / Open Source Software) pour éviter les débats sur la terminologie à adopter (Neumann et Breidert, 2005; Wheeler, 2007). Dans la suite du document, nous considérerons les expressions «logiciel libre» et «logiciel open source» comme équivalentes. D'une manière générale, il n'y a pas d'outil de protection juridique spécifique aux logiciels, et ces derniers sont couverts par le droit d'auteur. La licence permet à l'auteur du logiciel de fixer les droits et obligations de l'utilisateur du logiciel. Des brevets peuvent également peser sur le logiciel (Messerschmitt et Szyperski, 2001). Ce cas peut être prévu par la licence, qui peut également 2

3 mentionner des marques (Alspaugh et al., 2009b). La protection par brevet est possible, notamment aux Etats-Unis, mais pas en Europe, sauf dans le cas particulier des procédés industriels brevetables. Ce mode de protection n'est pas sans causer des difficultés compte tenu du caractère cumulatif du développement logiciel et de l'absence d'état de l'art (Julien et Zimmermann, 2002). Les logiciels, libres ou non, sont donc confrontés à plusieurs types d'ip (propriété intellectuelle) : les droits d'auteur mais aussi les marques et les brevets. A noter que des licences inspirées par les licences libres, mais n'en offrant pas toutes les libertés, existent. Laure Muselli (2008) les qualifie de «licences hybrides» et cite notamment comme exemple la licence SCSL de Sun Microsystems. Ces licences sont supposées faciliter la captation de revenus par l'entreprise comparé à d'authentiques licences libres. Les licences de logiciels libres sont généralement classées en deux grandes familles : les licences permissives (ou académiques) et les licences copyleft (ou gauches d'auteur ou réciproques). Une licence permissive (ex. : BSD, MIT, etc.) autorise l'utilisateur à appliquer une nouvelle licence, y compris propriétaire, aux œuvres dérivées. Elles permettent donc l'appropriation du logiciel par le preneur de licence. Une licence copyleft (ex. : LGPL, GPL, AGPL, MPL, etc.) «lie l'octroi des droits à l'obligation de ne redistribuer le logiciel et ses modifications que sous la même licence que celle par laquelle le licencié a obtenu ces droits» (Montero et al., 2005). Des distinctions plus fines existent. Farcot et Viseur (2007) pointent ainsi le cas particulier des licences contextuelles, dont les effets sont modulés en fonction du contexte d'utilisation (ex. : LGPL v2.1). Honkasalo (2009) ajoute le concept de réciprocité de réseau (ex. : AGPL) à ceux de réciprocités faible (ex. : LGPL) et forte (ex. : GPL). 3. Risques associés aux licences libres Les licences libres de type copyleft peuvent être ou non contaminantes. Le caractère contaminant suppose que «la totalité d'un programme dérivé du logiciel doive être placée sous la même licence libre» (Muselli, 2008). On parlera aussi de copyleft faible (lorsque le copyleft s'applique uniquement au composant logiciel) ou de copyleft fort (dans le cas où toute œuvre dérivée doit adapter la licence copyleft du composant logiciel). Les licences copyleft fortes sont parfois qualifiées de licences «à fort devoir contributif» ( Les licences copyleft fortes ont un impact important sur la politique commerciale de l'entreprise. Certaines entreprises (MySQL, Trolltech, etc.) basent (ou ont jadis basé) leur modèle d'affaires sur les propriétés de ces licences, en proposant des logiciels sous double licence propriétaire / libre (typiquement: GPL), de manière à discriminer les utilisateurs souhaitant participer à l'effort de développement collectif, des autres préférant payer et ne pas divulguer leur code source (Muselli, 2007; Välimäki, 2003). D'autres organisations peuvent par contre voir leur code affecté par une licence copyleft forte, alors que cela n'est a priori pas souhaité. C'est notamment la situation du logiciel électoral belge, publié sans licence (donc propriétaire) mais incluant du code source sous licence GPL v2 (Hillenius, 2009). Une éditeur propriétaire préfèrera généralement l'utilisation de composants sous licences propriétaire (pour les composants COTS, ou Commercial-Off-The-Shelf), académique ou copyleft faible (Neumann et Breidert, 2005). La violation de licences libres peut par ailleurs donner lieu à des actions en justice (Henley et Kemp, 2007). La culture du partage promotionnée dans la communauté du logiciel libre ne doit pas occulter le 3

4 problème de l'incompatibilité entre les licences. Ces incompatibilités proviennent parfois de termes apparemment annodins dans le texte des licences (Montero et al., 2005; St.Laurent, 2004). Des licences connues peuvent par ailleurs être fournies avec des exceptions (German et Hassan, 2009). Parmi les plus connues, citons la FLOSS License Exception ou la Java Classpath Exception, combinées à la GPL pour en limiter les effets lors de la création d'œuvres dérivées. Certains logiciels, comme Bugzilla, sont distribués avec des conflits de licences (German et Hassan, 2009). Dans le cas d'un projet développé ou utilisé par une entreprise, ce cas de figure devrait être anticipé. Il ne s'agit pas d'une tâche simple, sachant qu'il existe environ 70 licences open source approuvées, et que les développements basés sur des composants réutilisables gagnent en popularité. La problématique peut donc s'étendre à des composants sous licences non libres (gratuiciels, restriction à un usage non commercial,...), incluant des technologies brevetées (voir le cas de l'algorithme breveté SIFT dans le logiciel libre Hugin de création de panoramas; hugin.sourceforge.net), etc. Certaines licences de logiciels libres disposent de clauses relatives aux brevets. C'est le cas des licences Apache, GPL v2 et GPL v3, LGPL ou encore AGPL. Ces clauses peuvent aller d'un simple devoir d'information à la cession automatique d'une licence pour les utilisateurs du logiciel couvert par la licence libre. Le cas de l'octroi automatique de licence apparaît potentiellement problématique, par exemple pour une entreprise gérant ses droits de propriété intellectuelle comme des actifs stratégiques dans le cadre d'une stratégie d'innovation ouverte (Loillier et Tellier, 2011). L'essor récent des places de marchés pour terminaux mobiles (Appstore, Windows Marketplace, Android Market, etc.) impose au développeur de prendre de nouvelles précautions. Le statut accordé aux logiciels sous licences libres y est en effet incertain. Microsoft rejette par exemple les logiciels sous licences copyleft (et met en emphase l'interdiction pour la AGPL v3, la GPL v3 et la LGPL v3), à l'exception d'une liste fermée de licences à copyleft faible (CDDL, MPL, EPL, CPL et MS-RL). 4. Gestion des risques Plusieurs approches permettent de gérer les risques associés à l'utilisation de composants, externes à l'entreprise, couverts par des licences hétérogènes: la mise en place d'une structure de gouvernance, la modélisation des licences et de l'architecture du système informatique, et l'analyse juridique du code source. A noter que ces trois approches ne sont pas exclusives. L'entreprise peut mettre en place une structure de gouvernance permettant de tracer et d'autoriser l'utilisation de logiciels libres dans les développements informatiques. Gobeille (2008) donne l'exemple de l'open Source Review Board chez Hewlett Packard. Kemp (2010) rappelle pourtant que plus des deux tiers des entreprises n'ont pas de politique formelle pour évaluer et cataloguer les logiciels libres utilisés en interne. Il propose cinq éléments clefs pour une gouvernance open source: l'inventaire des technologies open source utilisées, la disponibilité de l'information sur l'origine des logiciels libres, la traçabilité des usages des logiciels libres en interne (réutilisation), l'affectation des rôles et l'identification des responsables, et l'étude de la compatibilité des obligations associées aux licences avec les contraintes de l'organisation. Alspaugh et al. (2009a, 2009b) proposent une automatisation de l'analyse de l'impact de licences basée sur la modélisation des licences et de l'architecture des logiciels. Ils s'appuient pour cela sur le logiciel ArchStudio4. Ce logiciel libre, basé sur Eclipse, facilite la création d'architectures logicielles et systèmes. L'architecture y est modélisée, et l'impact des licences est ensuite calculé à l'aide d'un module baptisé Software Architecture License Tracability Analysis. Ce dernier s'appuie 4

5 sur une description formelle des licences. Les auteurs proposent également la mise en œuvre de sous-ensembles architecturaux baptisés «pares-feux de licence» (license firewall) permettant de contenir les effets contaminant de certaines licences copyleft. Si ce procédé fonctionne, par exemple, avec la GPL (General Public License), il serait par contre inopérant avec la AGPL (Affero General Public License) Cette approche impose, outre la modélisation de l'architecture, la documentation de l'ensemble des licences possibles. Une autre approche, plus simple, consiste à analyser le code source, de manière à inventorier les licences utilisées. Les logiciels propriétaires Palamida ( et Black Duck Suite ( gèrent par exemple les problèmes de licences. Côté logiciels libres, Hewlett Packard a publié FOSSology ( une suite d'outils destinée à outiller la réutilisation des composants validés par la structure de contrôle de l'entreprise (Gobeille, 2008). FOSSology dépasse le seul cadre de l'analyse de licences, et peut rebuter, lors de l'installation, par le manque de documentation. 5. Expérimentation: outil d'audit juridique de code source Notre objectif est de mettre en place un outil simple d'installation et permettant une analyse automatique détaillée des droits de propriété intellectuelle présents dans un code source peu documenté (ou dont la documentation sur ce point est sujette à caution). Nous avons basé notre développement sur le logiciel libre Ohcount ( Ce dernier est surtout connu pour sa fonction première: compter le nombre de lignes de code source par langage de programmation. Cependant, il est également capable de dresser un inventaire des licences libres utilisées, par simple appel de ligne de commande. L'option «-l», ou «--license», affiche en effet l'information relative aux licences pour chaque fichier de code source. Nous avons dès lors exploité cette sortie pour produire un tableau de synthèse permettant de voir, module par module, les licences utilisées. Deux autres logiciels libres ont été utilisés en complément: find et grep ( Ces derniers ont permis d'identifier les fichiers contenant des copyrights, et mentionnant des marques ou des brevets, puis de mettre en évidence les extraits correspondants. Cette partie de l'outil s'est basée sur des mots-clefs dans les textes («trademark», «patent», «copyright», etc.) mais aussi sur des conventions de nommage utilisées dans les logiciels libres. L'analyse est configurée dans un fichier dédié. L'outil génère au final un rapport au format HTML, que l'on peut facilement convertir en PDF pour une lecture aisée ou une transmission papier. 6. Discussion Au travers de ce papier, nous avons tout d'abord montré les risques liés à l'utilisation de logiciels libres dans des développements commerciaux, et avons proposé différentes solutions pour mieux les gérer. Nous avons ensuite présenté les caractéristiques générales d'un outil d'analyse juridique de code source s'appuyant sur des logiciels libres existants et exploitant les conventions de nommage fréquemment utilisées dans les logiciels libres. 5

6 L'outil est apparu utile pour l'automatisation d'audits juridiques de code source. Ohcount est apparu fonctionnel mais présente quelques limitations. Les versions des licences (par exemple: GPL v2, GPL v3, GPL v2 ou supérieure, etc.) ne sont pas toujours bien identifiées, ce qui génère de fausses alarmes. La détection de la licence AGPL est par ailleurs problématique dans la version du logiciel présente dans le dépôt Ubuntu (août 2011). Le filtrage des sorties find / grep pourrait être amélioré. Une table d'incompatibilités entre licences pourrait être ajoutée au logiciel afin de mettre en évidence les conflits potentiels (actuellement, cette étape implique une bonne expertise de l'utilisateur). L'utilisation pratique de l'outil a également permis d'identifier d'autres éléments, parfois intégrés aux logiciels, couverts par des licences différentes : les documentations et les ressources audios (et, par extensions, les photos, les vidéos, etc.). Dans ce cas, l'utilisation de licences, telles que la Free Documentation License ou les Creative Commons, est possible. Ces licences pourraient également être automatiquement détectées pour une meilleure exhaustivité. Bien que perfectible car dépendant de la bonne identification des mentions relatives aux licences (pas toujours formatées de manière standard), cette approche se révèle cependant efficace pour réaliser des audits de code source en un temps raisonnable, sans pour autant se limiter au listage des licences libres utilisées. Elle se montre utile pour la pré-sélection de composants libres, pour l'analyse de codes sources peu documentés sur le plan des licences, ou encore pour venir compléter des approches plus organisationnelles ou analytiques. Références Alspaugh, T.A., Asuncion, H.U., Scacchi W. (2009a), "Analyzing software licenses in open architecture software systems", FLOSS '09 Proceedings of the 2009 ICSE Workshop on Emerging Trends in Free/Libre/Open Source Software Research and Development. Alspaugh, T.A., Asuncion, H.U., Scacchi W. (2009b), "Intellectual property rights requirements for heterogeneously-licensed systems", 17th IEEE International Requirements Engineering Conference (RE 09), pp , Augustus 31 - September 4, Farcot, M., Viseur, R. (2007), "YAME in the KBE! Yet Another Mutualist Ecosystem", Conférence de l'association Information et Management, Lausanne (Suisse). Fitzgerald, B. (2006), "The transformation of open source software", MIS Quarterly, vol. 30 n 3, pp , September German, D.M., Hassan, A.E. (2009), "License integration patterns: Addressing license mismatches in component-based development", ICSE '09 Proceedings of the 31st International Conference on Software Engineering. Gobeille, R. (2008), "The FOSSology project", MSR '08 Proceedings of the 2008 international working conference on Mining software repositories. Henley, M., Kemp, R. (2007), "Open Source Software: An introduction", Computer Law & Security Review, Volume 24, Issue 1, pp Hillenius, G. (2009), "BE: Government publishes source code for election software", European Commission (ISA, Joinup: joinup.ec.europa.eu), June 11, 2009 (consulté le 13 février 2012). Honkasalo, P. (2009), "Reciprocity under the GNU General Public Licenses", NJCL. Jullien, N., Zimmermann, J.B. (2002), "Le logiciel libre: une nouvelle approche de la propriété intellectuelle", Revue d'économie industrielle, Vol. 99, 2è trimestre 2002, pp Kemp, R. (2010), "Open source software (OSS) governance in the organisation", Computer Law Security Review, Vol. 26, Issue 3, Elsevier Ltd, pp Loillier, T., Tellier, A. (2011), "Que faire du modèle de l'innovation ouverte?", Revue française de 6

7 gestion, n 210, pp. p Messerschmitt, D.G., Szyperski, C. (2001), "Industrial and Economic Properties of Software: Technology, Processes, and Value", University of California at Berkeley Computer Science Division, Technical Report UCB//CSD , Jan. 18, 2001, and Microsoft Corporation Technical Report MSR-TR , Jan. 18, Montero E., Cool Y., de Patoul F., De Roy D., Haouideg H., Laurent P. (2005), Les logiciels libres face au droit, Cahier du CRID, n 25, Bruylant. Muselli, L. (2008), "Le rôle de licences dans les modèles économiques des éditeurs de logiciels open source", Revue française de gestion, n 181, pp Neumann, C., Breidert, C. (2005), "The challenges of using open source software as a reuse strategy", Libre software as a field of study, Upgrade, Vol. VI, issue No. 3, June OpenLogic (2011), "OpenLogic Scan Shows Open Source License Violations for iphone and Android", March 08, St.Laurent A.M. (2004), Understanding Open Source and Free Software Licensing, O'Reilly Media, Välimäki, M. (2003), "Dual Licensing in Open Source Software Industry", Systemes d Ínformation et Management, Vol. 8, No. 1, pp Viseur, R. (2011), "Associer commerce et logiciel libre : étude du couple Netscape / Mozilla, Conférence de l'association Information et Management 2011, Saint-Denis (France). Von Hippel, E. (2001), "Innovation by User Communities: Learning from Open-Source Software, MIT Sloan Management Review. Wheeler, D.A. (2007), "Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!", URL: (consulté le 21 janvier 2011). *** 7