copie locale - Robert Viseur

Colloque 2012 de l'Association Information et Management
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,
[email protected],
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
1. Contexte
Bien du chemin a été parcouru depuis la publication du noyau Linux par Linus Torvalds en 1991. 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
Colloque 2012 de l'Association Information et Management
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 » (www.april.org). 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
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
Colloque 2012 de l'Association Information et Management
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 (www.palamida.com) et Black
Duck Suite (www.blackducksoftware.com) gèrent par exemple les problèmes de licences. Côté
logiciels libres, Hewlett Packard a publié FOSSology (www.fossology.org), 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 (www.ohloh.net). 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 (www.gnu.org). 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
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. 24–33, Augustus 31 - September 4, 2009.
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. 587-598, September 2006.
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. 77-85.
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. 159-178.
Kemp, R. (2010), "Open source software (OSS) governance in the organisation", Computer Law
Security Review, Vol. 26, Issue 3, Elsevier Ltd, pp. 309-316.
Loillier, T., Tellier, A. (2011), "Que faire du modèle de l'innovation ouverte ?", Revue française de
6
Colloque 2012 de l'Association Information et Management
gestion, n°210, pp. p69-85.
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-01-1130, Jan. 18, 2001, and Microsoft Corporation
Technical Report MSR-TR-2001-11, Jan. 18, 2001.
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. 199-214.
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 2005.
OpenLogic (2011), "OpenLogic Scan Shows Open Source License Violations for iPhone and
Android", March 08, 2011.
St.Laurent A.M. (2004), Understanding Open Source and Free Software Licensing, O'Reilly Media,
2004.
Välimäki, M. (2003), "Dual Licensing in Open Source Software Industry", Systemes d ́Information
et Management, Vol. 8, No. 1, pp. 63-75.
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: www.dwheeler.com (consulté le 21 janvier 2011).
***
7