### 1.3.3.1 Les origines

En 1978, la France s'est dotée d'une loi « portant diverses mesures d'amélioration des relations entre l'administration et le public et diverses dispositions d'ordre administratif, social et fiscal ». Elle était destinée à assurer aux citoyens l'accès aux documents administratifs (en provenance d'établissements publics administratifs, ou privés avec mission de service public) et entraînait d'une part des obligations de mise à disposition pour l'administration et d'autre part la constitution d'une commission, la Commission d'Accès aux Documents Administratifs (CADA<fnref n="1" />), garante de leur respect. Il y eu ensuite peu d'usage de cette loi, même si, en phase avec son époque, le gouvernement français confirma en 1998 que les « données publiques essentielles » devaient être accessibles gratuitement sur Internet.

En 2005, une ordonnance « relative à la liberté d'accès aux documents administratifs et à la réutilisation des informations publiques » (transposant la directive européenne de 2003 « sur la réutilisation des données du secteur public ») est venue ajouter — et organiser — la possibilité de réutiliser les données publiques. Certains documents sont expressément exclus de cette réutilisation (lorsque protégés par un droit de propriété intellectuelle d'un tiers, relatifs à un service public industriel et commercial, ou provenant d'établissements et institutions d'enseignement et de recherche ou d'organismes ou services culturels). Une circulaire du Premier Ministre ajoute, courant mai 2006, un « objectif de développement économique par une meilleure valorisation des gisements de données dont disposent les administrations. »

Deux logiques coexistent donc : celle (passive) de la simple mise à disposition impliquant une démarche du demandeur et celle (active) de la diffusion reposant sur une démarche du producteur de la donnée. Constitutives d'une politique incitative, ces dispositions prennent la forme d'une série d'obligations à l'encontre de certaines personnes publiques (tous les établissements publics ne sont pas concernés), pour certains documents (tous les documents ne sont pas visés — sont notamment exclus tous ceux devant demeurer secret, touchant à la défense nationale, la sécurité publique, la protection d'espèces rares ou des données archéologiques)

<footnote n="1">1. http://www.cada.fr.</footnote>
afin d'assurer certains droits aux citoyens. Au-delà de ce cadre minimum,
il leur est évidemment tout à fait possible d'opter pour une diffusion plus
large des données/informations publiques détenues : le mouvement de
l'open data étant la politique la plus ouverte en la matière, et la meilleure
en termes de marketing...

Enfin, parallèlement, et dans deux domaines précis, ont été organisés
des régimes plus contraignants. Une Charte de l'environnement a été
rédigée dans la continuité de la Convention d'Aarhus afin de préciser que
« [t]oute personne a le droit, dans les conditions et les limites définies par
la loi, d'accéder aux informations relatives à l'environnement détenues
par les autorités publiques et de participer à l'élaboration des décisions
publiques ayant une incidence sur l'environnement ». Peu de temps après,
la directive européenne INSPIRE a ajouté un cadre légal pour l'établisse-
ment et l'exploitation d'une infrastructure d'information spatiale com-
mune en Europe.

Pour aller plus loin...

- Rapport « Recommandation. Quelle politique de diffusion des données publiques ? », Forum des droits sur l'internet (http://www.foruminternet.org/);

- « Les sources de la démocratie environnementale — le principe de participation du public : de la convention d'Aarhus à la charte de l'environnement », dossier du participant, Conférence du Conseil d'État — 22 décembre 2010 (voir : http://www.conseil-etat.fr).

1.3.3.2 Les démarches *open data* à l'échelle des pays

À l'échelle internationale, les États-Unis<fnref n="1" /> en 2009, puis le Royaume-Uni<fnref n="2" /> en 2010, ont été les deux premiers pays à communiquer sur l'adoption d'une politique d'open data avec la mise en place de leurs portails respectifs.

<footnote n="1">1. http://www.data.gov.</footnote>

<footnote n="2">2. http://data.gov.uk.</footnote>
Devant le succès de ces initiatives, tant en termes de communication qu'au regard des usages qu'elles ont engendrés, les autres pays ont rapidement adopté des démarches similaires : Pays-Bas<fnref n="1" />, Suède<fnref n="2" />, Espagne, Bulgarie, Canada, Tunisie, Finlande, Australie<fnref n="3" />, Nouvelle-Zélande<fnref n="4" />, Irlande du Nord et Maroc<fnref n="5" />. L'excellent site américain Open Data Site<fnref n="6" /> répertorie ainsi plus de 200 initiatives similaires à l'échelle des états, des collectivités ou des organisations internationales. Par ailleurs, un regroupement de collectivités et administrations autrichiennes a annoncé la mise en place d'une coopération « Cooperation OGD Austria » qui mutualisera les outils juridiques (les licences) et techniques (grâce au logiciel CKAN développé par l'OKF) pour la diffusion des informations publiques ; et le Royaume-Uni a récemment publié le rapport « Making Open Data Real : A Public Consultation <fnref n="7" /> » destiné à « établir une culture de la transparence et de l'ouverture des services publics. »

Plusieurs types de licences sont utilisées pour la diffusion de ces données :

- les licences communautaires préexistantes (principalement les licences Creative Commons et ODbL) :

- la coopération autrichienne Cooperation OGD Austria ainsi que la Nouvelle-Zélande ont opté pour la CC-By 3.0 ;

- La région du Piemont italienne, déjà précurseur en matière de logiciels libres en Italie, a publié son portail open data<fnref n="8" /> sous CC-By et utilise la licence CC-0 sur les données ;

- La suisse a opté pour une CC-By-SA 3.0 ;

- l'ODbL a été choisie par de nombreuses collectivités françaises (notamment la Mairie de Paris<fnref n="9" />, Nantes Metropole, Grand Toulouse, le Nord-Pas-De-Calais, etc.) et quelques pays (notamment le Maroc).

<footnote n="1">1. http://www.opendatanederland.nl.</footnote>

<footnote n="2">2. http://www.opengov.se.</footnote>

<footnote n="3">3. http://data.gov.au.</footnote>

<footnote n="4">4. http://nzgoal.info.</footnote>

<footnote n="5">5. http://data.gov.ma.</footnote>

<footnote n="6">6. http://www.data.gov/opendatasites.</footnote>

<footnote n="7">7. https://update.cabinetoffice.gov.uk/sites/default/files/resources/open-data-consultation.pdf</footnote>

<footnote n="8">8. http://dati.piemonte.it.</footnote>

<footnote n="9">9. http://opendata.paris.fr.</footnote>
- ou des licences spécifiques :

- l'Open Government Licence <fnref n="1" /> (OGL) en Angleterre pour le site legislation.gov.uk : la licence est rédigée pour les besoins du gouvernement britannique et compatible avec la licence Creative Commons Attribution (pour le copyright) et la licence Open Data Commons Attribution (pour les bases de données) ;

- la licence ColorIURIS <fnref n="2" /> (ColorIURIS) pour la ville espagnole de Saragosse ;

- la récente Licence Ouverte <fnref n="3" /> (LO) qui sera utilisée en France par toute l'administration et les collectivités qui le décident. Elle est très ouverte et compatible avec les principales licences commu-nautaires existantes, notamment avec l'OGL, la CC-By-SA 2.0 et l'ODbL.

Il n'existe à l'heure actuelle aucun consensus quant à l'usage de licences de type copyleft ou non : celles-ci offrant des pistes de valorisation ras-surent de nombreuses collectivités, mais qui génèrent aussi un courant de mécontentement du côté des industriels qui souhaiteraient profiter de ces données sans contrepartie <fnref n="4" />.

Pour finir, outre ces initiatives directement menées par les États, ceux-ci incitent indirectement les sociétés privées à suivre ces recommandations (notamment celles qui travaillent directement avec elles) : ainsi la société simplegeo <fnref n="5" />, qui développe des applications autour de la géolocalisation, a annoncé la publication de ses propres données sous licence CC-0 afin de se concentrer sur le service.

### 1.3.3.3 Les démarches open data à l'échelle française

Les villes de Brest, Rennes et Nantes (aux dernières nouvelles en 2011) ont chacune à leur tour arboré les couleurs de l'open data. La démarche

<footnote n="1">1. http://www.nationalarchives.gov.uk/doc/open-government-licence.</footnote>

<footnote n="2">2. https://www.coloriuris.net/risp-ayto-zaragoza/contenido/126.</footnote>

<footnote n="3">3. http://ddata.over-blog.com/xxxyyy/4/37/99/26/licence/Licence-Ouverte-Open-Licence.pdf</footnote>

<footnote n="4">4. Voir sur le sujet le récent (et criticable) rapport Samuelson-Glushko, Analysis of share-alike obligations in municipal open data licenses, Canadian Internet Policy and Public Interest Clinic, University of Ottawa, 2011.</footnote>

<footnote n="5">5. https://simplegeo.com.</footnote>
parisienne se distingue aussi, mais par le fort investissement (et la réflexion relative aux licences) et par son aspect « pionnier » qui donnèrent confiance à d'autres collectivités (notamment : Marseille, Montpellier, Nantes, Bordeaux, Toulouse et le Nord-Pas-de-Calais).

On peut néanmoins regretter que les échanges aient été si faibles quant au choix des licences, des technologies, etc., chaque collectivité et administration fonctionnant de façon isolée en l'absence de cadre commun (ou de licence française), quitte à renouveler le travail réalisé par d'autres — même si l'investissement et l'implication de la ville de Paris permirent de dégager une certaine orientation au profit de la licence ODBL. C'est ainsi, grâce aux initiatives communes et au travail des communautés, que les expériences respectives sont partiellement mutualisées.

Parmi les autres initiatives isolées, on peut citer :

- le Répertoire du registre français des émissions polluantes sur Internet (IREP <fnref n="1" />), qui donne accès aux données concernant la pollution ;

- le site du ministère de l'Écologie, du Développement durable, des Transports et du Logement qui permet une utilisation libre des données tant que celles-ci ne sont pas dénaturées et en précisant que « [l]es informations mises à disposition ne sont pas fournies en vue d'une utilisation particulière, et aucune garantie quant à leur aptitude à un usage particulier n'est apportée par le service fournisseur » (voir notamment les conditions générales d'utilisation des données disponibles en téléchargement sur le site) ;

- plus récemment, et plus loin dans cette démarche d'ouverture, le Ministère de la justice a rédigé en 2010 une licence « Information Publiques librement réutilisable <fnref n="2" /> » qui s'appuie essentiellement sur la loi de 1978 relative aux données publiques (Licence IP ou LIP).

Enfin, une prise de conscience nationale du phénomène s'est traduite par la création de l'Agence du patrimoine immatériel de l'État (APIE <fnref n="3" />) et de la mission Etalab <fnref n="4" />.

<footnote n="1">1. http://www.pollutionsindustrielles.ecologie.gouv.fr/IREP/index.php.</footnote>

<footnote n="2">2. http://www.rip.justice.fr/information_publique_librement_reutilisable</footnote>

<footnote n="3">3. Créée sous l'initiative de la Direction de l'Information Légale et Administrative (DILA), elle a pour mission de mener une réflexion, coordonner, évaluer et organiser un effort commun des différentes administrations sur leurs données (voir : https://www.apiefrance.fr).</footnote>

<footnote n="4">4. http://blog.etalab.gouv.fr.</footnote>
- L'APIE est un service à compétence nationale qui a pour mission de sensibiliser les acteurs publics aux enjeux attachés aux actifs immatériels de l'État, et propose à cette fin plusieurs licences<fnref n="1" /> destinées à accompagner la diffusion des données publiques (dans une logique qui mélange diffusion gratuite et payante). Néanmoins ces documents ont été pensés dans une logique propre à l'administration (avec un socle de conditions générales de réutilisation des informations publiques sur lequel sont construites deux licences, chacune composée de conditions générales et potentiellement de conditions particulières), pas forcément adaptée à un mouvement global d'open data qui n'est pas centré sur les concédants, mais sur les bases de données licenciées. Actuellement les documents sont encore trop complexes pour répondre aux enjeux de large diffusion des bases de données. Par ailleurs, ils restent franco-français, négligent le formalisme lié aux cessions de droits de propriété intellectuelle et sont plus orientés vers la libre diffusion que la libre réutilisation. Une nouvelle licence intitulée Informations Publiques (du même nom que la licence rédigée par le Ministère de la Justice en 2010) a été publiée suite à la constitution de la mission Etalab.

- Créée début 2011 dans le cadre du plan « France numérique 2012 », la mission Etalab anime un groupe de réflexion sur le sujet avec pour objectif la mise au point d'un portail unique, alimenté par les ministères et les collectivités territoriales, donnant accès à toutes les données publiques de l'État. La mission a aussi la lourde tâche de rédiger (ou préconiser) la licence qui sera utilisée sur la plate-forme : c'est-à-dire de dégager une stratégie globale et de se prononcer sur le contenu nécessaire. Actuellement, il semblerait que les différentes collectivités ayant fait le pas de l'open data privilégient une licence de type copyleft assimilable aux fréquents accords de coopération (une partie profite gratuitement d'une base de données et l'enrichit en échange) tout en se tournant résolument vers l'open data.

La mission Etalab a récemment publié sa licence libre permissive intitulée « Licence Ouverte » dédiée aux données du secteur public français et assurant une compatibilité avec les projets existants. Il est très probable

<footnote n="1">1. https://www.apiefrance.fr/sections/acces_thematique/reutilisation-des-informations-publiques/licence-type/view.</footnote>
que cette dernière licence rende obsolète les licences rédigées précédem-
ment par l'APIE et avant elle par le Ministère de la justice. Le portail
national est quant à lui prévu pour la fin de l'année 2011. Même si ces
travaux ne contraignent que l'État et ses administrations, les autres col-
lectivités territoriales sont invitées à mutualiser les ressources (juridiques
ou techniques) liées à l'ouverture de leurs données.

Pour aller plus loin...

- Plusieurs associations assurent un travail de veille et d'accom-
pagnement : LiberTIC, Regards Citoyens et Veni, Vidi, Libri ;

- la Fing a aussi publié en janvier 2011 la version de travail d'un « Guide pratique de l'ouverture des données publiques territoriaux — Guide à l'usage des territoires et de leurs partenaires » (sur http://fing.org) ;

- Voir l'article « Ouverture des données publiques : les enjeux relatifs au choix de la licence » sur http://blog.vvlibri.org;

- Voir le rapport « La valorisation des informations du secteur public (ISP) : un modèle économique de tarification optimale » rédigé en 2010 par le Bureau d'économie théorique et appliquée (BETA) à la demande de l'APIE (sur http://www.apiefrance.fr).

1.3.3.4 Réflexion sur une démarche *open data* européenne

On remarque en Europe une évolution des tendances : après un premier courant législatif (les directives citées *supra*) qui impulsa le mouvement d'ouverture, c'est maintenant conjointement que l'Union européenne et les différents acteurs publics se réunissent pour confronter et échanger sur leurs pratiques respectives. Le projet Open Cities<fnref n="1" />, issu de cette collaboration, ainsi que l'appel d'offres<fnref n="2" /> pour la mise en place d'un portail européen des données publiques sont de bons exemples.

Concernant les licences, l'une des questions très actuelles est de savoir
s'il est pertinent de mettre en place une initiative européenne — les logi-
ciels libres / *open source* s'étant en effet diffusés en l'absence d'une telle

<footnote n="1">1. http://opencities.net.</footnote>

<footnote n="2">2. http://www.dw-world.de/dw/article/0,,15007160,00.html.</footnote>
harmonisation. En plus d'assurer une certaine cohérence avec les différentes directives européennes, plusieurs arguments semblent pouvoir le justifier :

- l'évidence des enjeux politiques faciliterait la consécration d'un tel cadre;

- les moyens à disposition de l'Europe pour mettre en place un cadre juridique adapté aux contraintes spécifiques des personnes publiques : le document pourrait ainsi être conforme aux directives européennes, prendre en compte les impératifs des personnes publiques, et être traduit dans toutes les langues de l'Union européenne. Les gouvernements et collectivités seraient d'autant plus rassurés qu'ils sont plus habitués à utiliser les documents en provenance de l'Europe que des contrats privés du type des licences libres;

- la fenêtre de tir actuelle : étant encore à ses balbutiements, le cadre juridique va évoluer très rapidement — avec ou sans l'Europe.

Pour ce faire, l'Europe doit rapidement profiter de l'ouverture qui se présente à elle, conjonction de besoins forts des administrations (en terme d'outils) face à des réponses (les licences) encore peu nombreuses. Il faudrait par exemple que l'un des projets européens actuels, à déterminer, s'estime compétent pour travailler sur une telle licence (telle l'EUPL rédigée par l'IDABC)<fnref n="1" />.

### 1.3.3.5 Gouvernement ouvert— open government

Dès la première journée de son mandat, le président américain Barack Obama mit en place l'Open Government Initiative<fnref n="2" /> : elle promeut l'ouverture et la transparence politique, engageant le gouvernement américain et ses agences à travailler avec les citoyens et de manière transparente, participative et collaborative — cela d'autant plus que les créations réalisées par le gouvernement, ou financées par celui-ci, ne bénéficient pas d'une protection par le copyright (Copyright status of work by the U.S. government<fnref n="3" />).

<footnote n="1">1. Voir la directive On the re-use of public sector information sur le site http://ec.europa.eu.</footnote>

<footnote n="2">2. http://www.whitehouse.gov/open.</footnote>

<footnote n="3">3. http://en.wikipedia.org/wiki/Copyright_status_of_work_by_the_U.S._government.</footnote>
Cette tendance est à la fois la conséquence d'une ouverture progressive et la prise de conscience de l'impact de l'informatique et de son utilisation sur le politique dans son acception large, c'est-à-dire les entreprises comme les administrations, avec une nécessité de rendre compte et de responsabiliser leurs actions.

Au regard du caractère immatériel du numérique, il n'est guère étonnant que des collaborations transfrontalières se développent, tel l'Open govwest<fnref n="1" /> entre les États-Unis et le Canada.

Enfin, concernant les actions des citoyens en faveur d'une ouverture et d'une transparence de leur gouvernement, il est possible de citer la plate-forme Openspending<fnref n="2" /> — initié par l'OKF — qui trace le budget italien, l'équivalent public américain USApending<fnref n="3" /> ou encore les initiatives Farmsubsidy.org<fnref n="4" /> (qui suit le budget lié à la politique agricole européenne) ou « Publish What You Fund 5 » (qui promeut une transparence relative aux diverses aides, dans l'esprit de l'International Aid Transparency Initiative (IATI) 6). D'autres initiatives étendent cette ouverture : datalibre.ca<fnref n="7" /> qui « exhorte les gouvernements à rendre les données sur les citoyens du Canada et les Canadiens gratuites et accessibles aux citoyens », OpenCorporates<fnref n="8" /> (pour comprendre la place des sociétés dans nos vies) ou encore le site suédois OpenAid.se<fnref n="9" /> qui vise à « promouvoir la 'transparence' et les 'idées nouvelles' dans les programmes d'aide au développement ». Les initiatives nosdeputes.fr 10 et nossenateurs.fr 11 mises en place par Regards Citoyens 12 en France participent à ce mouvement (en affichant notamment l'assiduité de ces derniers lors des débats législatifs...).

<footnote n="1">1. http://www.opengovwest.org/events/conference/opengovwest-11.</footnote>

<footnote n="2">2. http://openspending.org.</footnote>

<footnote n="3">3. http://www.usaspending.gov.</footnote>

<footnote n="4">4. http://farmsubsidy.org.</footnote>

<footnote n="5">5. http://www.publishwhatyoufund.org/what-we-do.</footnote>

<footnote n="6">6. http://www.aidtransparency.net.</footnote>

<footnote n="7">7. http://datalibre.ca</footnote>

<footnote n="8">8. http://opencorporates.com.</footnote>

<footnote n="9">9. http://openaid.se.</footnote>

<footnote n="10">10. http://www.nosdeputes.fr.</footnote>

<footnote n="11">11. http://www.nossenateurs.fr.</footnote>

<footnote n="12">12. http://www.regardscitoyens.org.</footnote>
Enfin, l'Open Government Partnership <fnref n="1" /> est une initiative multilatérale qui a pour objet d'assurer des actions concrètes des gouvernements en faveur de la transparence, de l'action citoyenne, et de toutes les autres valeurs de l'open data. Elle compte actuellement de nombreux pays tels que le Brésil, l'Indonésie, le Mexique, la Norvège, les Philippines, l'Afrique du Sud, le Royaume-Uni et les États-Unis.

<figure><img src="image_34.png" /></figure>

## L'OPEN GOVERNMENT ET LA NASA

Aux États-Unis, la NASA et l'agence de protection de l'environnement sont les meilleures élèves. Ainsi, le plan Open Government de la NASA s'est aussi démarqué par ses ambitions, les moyens qui lui ont été accordés et les mécanismes de transparence mis en place.

L'initiative se base à la fois sur l'affirmation de certains principes et sur l'énumération de 25 projets (qui font l'objet d'un rapport régulier ²).

Les principes de la Nasa Open Government Plan sont :

1. accroître la transparence et la responsabilisation de l'Agence à des parties prenantes externes ;

2. permettre la participation des citoyens dans la mission de la NASA ;

3. améliorer la collaboration et l'innovation interne de la NASA ;

4. encourager les partenariats susceptibles de créer des opportunités économiques ;

5. institutionnaliser les principes et pratiques du Gouvernement Ouvert à la NASA.

La NASA a organisé l'Open Source Summit 2011 ³.

Voir aussi :

- Danish Board of Technology, « Open-source software in e-government », Octobre 2002 (sur http://www.tekno.dk) ;

<footnote n="1">1. http://www.opengovpartnership.org/about</footnote>
- voir l'article de Red Hat sur l'Open-Source Govern-
ment : http://openadvantage.redhat.com ;

- la plate-forme Open.Nasa (open.nasa.gov) ;

- « Publish what you fund », Aid Transparency Assessment 2010, 2011 (http://www.publishwhatyoufund.org) ;

- « NZ State Services Commission », New Zealand Government Open Access and Licensing framework (NZGOAL), 2010 (sur http://www.ict.govt.nz) ;

- GRAY (Jonathan), « We need international open government data principles », OKF, 2011 (sur http://blog.okfn.org).

- voir la page du Wiki Creative Commons intitulée « Government use of Creative Commons » ;

- Commission européenne, Stratégie numérique : la Commission lance une consultation sur un accès plus ouvert aux informations scientifiques, Communiqué de presse, 15 juillet 2011 (sur http://europa.eu).

Après cette présentation historique et systémique du libre, nécessaire
pour comprendre et appréhender une telle connaissance, nous sommes
désormais capables de nous orienter parmi les licences libres (chapitre
suivant).
<figure><img src="image_35.png" /></figure>
# CHAPITRE 2

## Les bons repères pour s'orienter parmi les licences libres

La description des différents mouvements et usages qui entourent les licences libres laisse entrevoir une certaine complexité néanmoins facile à relativiser grâce à quelques bons repères simplifiant la compréhension des différentes licences libres.

Le nombre de licences libres a plus que décuplé en une décennie. Cette multiplication s'explique essentiellement par le succès du Libre et par sa structure décentralisée. En dépit de l'autorité de certains organismes (notamment l'OSI et la FSF, mais aussi la Commission européenne ou les centres de recherche à leurs niveaux respectifs) plusieurs facteurs favorisent cet accroissement :

- un facteur *personne* lié à l'arrivée de nouveaux acteurs : en premier lieu l'industrie et ses atteintes particulières en termes de sécurité juridique et, en second lieu, les administrations et leurs contraintes particulières<fnref n="1" />);

<footnote n="1">1. En France il y a notamment un contrôle de légalité qui impose aux collectivités une prévisibilité dans leurs actes, ce qui peut inciter à utiliser des licences plus adaptées à cette</footnote>
- un facteur *temps* : les licences étant basées sur un système en constante évolution, elles évoluent ou se créent pour ajuster leurs effets ;

- un facteur *lieu* : certaines législations peuvent imposer des contraintes absentes dans d'autres régions. Toutes les combiner dans une seule licence peut s'avérer très difficile, voire impossible<fnref n="1" /> ;

- et enfin, un facteur périmétrique lié à l'extension du Libre à d'autres domaines, pour lesquels des problématiques différentes peuvent induire la rédaction de nouvelles licences.

Le mouvement connaît cependant actuellement un succès et une professionnalisation qui induisent une structuration du cadre juridique basé sur les licences. L'OSI définit par exemple une hiérarchie entre les licences alors qu'une initiative comme le projet Harmony<fnref n="2" /> rédige des Copyright Assignment « standards ».

Trois éléments sont donc nécessaires pour pouvoir se repérer au sein de la « jungle » des licences libres : une qualification juridique des licences (2.1), une classification des licences (2.2) et un déchiffrement au moyen d'une grille de lecture dédiée aux licences (2.3).

## 2.1 Qualifier juridiquement les licences libres

Un contrat exprime la volonté des parties et tient lieu de loi des parties dès lors qu'il ne porte pas atteinte aux bonnes mœurs ou à l'ordre public<fnref n="3" />.

<footnote>nécessité. Un autre très bon exemple est la Commission européenne qui a rédigé sa propre licence : l'European Union Public License.</footnote>

<footnote n="1">1. Notamment si la contrainte réside en l'imposition d'une langue au détriment d'une autre (comme c'est le cas en France vis-à-vis de certaines personnes publiques).</footnote>

<footnote n="2">2. http://www.harmonyagreements.org.</footnote>

<footnote n="3">3. En l'occurrence, le seul argument juridique opposable à cette extension des droits serait l'abus de droit (cf. supra). Tout au plus pouvons-nous rappeler la décision du Conseil constitutionnel n°2002-465 DC du 13 janvier 2003 : « Le législateur ne saurait, sans méconnaître les exigences résultant des articles 4 et 16 de la Déclaration des droits de l'homme et du citoyen de 1789, porter au contrat légalement conclu une atteinte qui ne soit justifiée par un motif d'intérêt général satisfaisant » (l'article 4 est le fondement de la liberté contractuelle. L'article 16 est le fondement du principe de la sécurité juridique). L'effet n'étant ici qu'inter partes, il semble devoir être considéré comme valide.</footnote>
### 2.1.1 Un engagement juridique

Il convient d'analyser le type d'engagement juridique (2.1.1.1), l'impact des éléments liés au caractère international des licences (2.1.1.2) ainsi que la validité des exclusions de garantie et de responsabilité (2.1.1.3).

#### 2.1.1.1 Le type d'engagement juridique

En l'absence de contestation sur les droits et devoirs de chacun, tout se passe généralement pour le mieux. En cas de discorde, le conciliateur, le juge ou l'arbitre, chercheront à déterminer la relation (exprimée ou non) qui lie les parties et à en retirer la dimension juridique afin de leur imposer les effets attendus. La qualification juridique de l'engagement est donc un passage obligé, mais encore faut-il rappeler aux juristes qui se pencheront sur cette question (juges, avocats, juristes d'entreprise, etc.) que cet exercice ne peut être mené sans intégrer le contexte particulier (communautaire et décentralisé, collaboratifs et évolutif, etc.) qui caractérise le Libre : une simple application des règles juridiques traditionnelles aboutissant à des réponses soit inadaptées soit contraires à la volonté des parties (voir à l'intérêt général).

Ce sont en l'occurrence les licences libres qui représentent l'essentiel de l'engagement, exprimant en termes de droits et d'obligations les engagements souscrits par chacune des parties dans le cadre du développement collaboratif d'une création (et reprenant très souvent les engagements souscrits préalablement par l'une d'elles). Ainsi, si l'auteur, ou ses héritiers, décide(nt) de revenir sur ce qu'il a pu promettre aux détenteurs d'une copie de l'œuvre ou créateurs d'œuvres dérivées, ou si l'un de ces détenteurs en déduit des libertés supplémentaires, la licence leur sera opposable. Afin que personne ne puisse prétendre ignorer ces dernières, les licences libres accompagnent quasi systématiquement la mise à disposition des créations originales ou dérivées (en favorisant ainsi la diffusion ultérieure).

#### 2.1.1.1.a La qualification juridique

Les licences libres ou *open source* confèrent au licencié des droits similaires à ceux des titulaires de droits initiaux (leur permettant notamment
de copier, modifier et distribuer librement la création), de façon à favoriser l'implication de ces derniers dans l'œuvre commune. Il s'agit donc de contrats gratuits opérant une cession non exclusive très large, posant éventuellement quelques problématiques au regard des droits moraux, et qui sont qualifiés de *licenses* dans les régimes anglo-saxons.

→ *Un contrat*

En usant d'une licence libre le titulaire va céder certains de ses droits aux utilisateurs de la création, à la condition pour ceux-ci de respecter le cadre défini par la licence. En cas de non-respect, ou si l'utilisateur ne souhaite pas y consentir, on retombe dans la contrefaçon classique.

Ainsi, les licences sont bien des contrats synallagmatiques, c'est-à-dire des conventions par lesquelles les parties s'obligent réciproquement l'une vers l'autre <fnref n="1" />. Plus précisément, les licences *open source* sont des contrats (ou offres, le contrat étant formé dès acceptation par le licencié) gracieux <fnref n="2" /> de cessions non exclusives de droit de propriété intellectuelle consentis pour le monde entier, pour toute la durée des droits, pour tous les usages et sur tout type de support <fnref n="3" />.

En termes de schémas contractuels attachés à des créations composées de multiples contributions deux modèles existent : soit la licence autorise les sous-licences et il n'y a dans la relation finale qu'un seul contrat entre le licencié et le concédant (ce dernier cédant simultanément les droits des auteurs des contributions antérieures), soit ce n'est pas le cas et il y a alors autant de contrats qu'il y a de titulaire de droit (chaque contrat portant néanmoins sur une contribution déterminée).

Enfin, une même personne sera liée à plusieurs personnes différentes (l'auteur de la création initiale d'une part et les utilisateurs de l'œuvre dérivée d'autre part) par la même licence (notamment lorsque celle-ci est *copyleft*). *L'instrumentum* (le contrat qui exprime les engagements) est

<footnote n="1">1. Art. 1102 C. civ.</footnote>

<footnote n="2">2. Le caractère gratuit, non pas de la mise à disposition, mais de la cession de droits (automatique) subséquente, constitue la principale distinction entre libre et propriétaire.</footnote>

<footnote n="3">3. À ce sujet : « Les licences libres sont des licences par lesquelles l'auteur autorise la copie, la modification et la diffusion de l'œuvre modifiée ou non, de façon concurrente, sans transférer les droits d'auteur qui y sont attachés et sans que l'utilisateur ne puisse réduire ces libertés tant à l'égard de l'œuvre originale que de ses dérivés », CLÉMENT-FONTAINE (Mélanie), *Les œuvres libres, op. cit.*.</footnote>
bien le même, mais les deux relations sont indépendantes : ainsi l'utilisateur ne pourra pas reprocher le non-respect des obligations de la licence, pas plus que l'auteur d'une contribution ne pourra reprocher ce même non-respect vis-à-vis d'une contribution dont il n'est pas l'auteur ou le cessionnaire. Ainsi, dans l'arrêt de la cour d'appel de Paris du 16 septembre 2009 (SA EDU4 c/ Association AFPA) le contrat n'est pas annulé pour non-respect de la licence, mais pour non-respect des autres obligations contractuelles prises au surplus par la société.

→ *Un contrat conclu à titre gratuit*

Aucun prix ne conditionnant le bénéfice des licences, celles-ci sont des contrats gratuits qui offrent notamment aux licenciés le droit de distribuer la création comme ils l'entendent, commercialement ou non. La mise à disposition (acte matériel) de la création soumise à la licence peut ainsi parfaitement être payante — et, de fait, beaucoup d'entreprises « vendent du Libre » — tant que la licence est par ailleurs respectée (certaines vont en effet immédiatement, automatiquement et gratuitement étendre leur bénéfice aux nouveaux utilisateurs). Une œuvre dont l'accès est gratuit n'est pas forcément libre et réciproquement.

Contrairement à une confusion fréquente, due à la traduction du terme *free*, la distribution d'un logiciel libre, ou tout acte de mise à disposition, n'est donc pas nécessairement gratuite (« libre ne veut pas dire gratuit<fnref n="1" /> ») alors que la licence est elle-même gratuite<fnref n="2" />. Sa violation reste néanmoins constitutive d'un préjudice<fnref n="3" />. Source fréquente de confusion, de nombreuses licences le stipulent expressément, à l'instar de l'AFL<fnref n="4" />, l'OSL<fnref n="5" />, la CDDL<fnref n="6" />, la Common Public License<fnref n="7" /> et de bien d'autres.

Même si la solution était depuis longtemps acquise, la loi DADVSI a ajouté l'article L122-7-1 au CPI qui précise que « [l']auteur est libre de

<footnote n="1">1. http://en.wikipedia.org/wiki/Gratis_versus_libre.</footnote>

<footnote n="2">2. D'après Richard Stallman : « Don't think free as in free beer ; think free as in free speech » (voir STALLMAN (Richard), MASUTTI (Christophe), WILLIAMS (Sam), *Richard Stallman et la révolution du logiciel libre*, Paris, Eyrolles/Framabook, 2010, p. 187.</footnote>

<footnote n="3">3. Cette question n'aurait pas posé de problème en France (le droit moral étant généralement lui-même violé), mais la même précision a été apportée aux États-Unis lors de l'arrêt de la cour d'appel dans l'affaire Jacobsen v. Katzer.</footnote>

<footnote n="4">4. http://wiki.venividilibri.org/index.php?title=AFL.</footnote>

<footnote n="5">5. http://wiki.venividilibri.org/index.php?title=OSL.</footnote>

<footnote n="6">6. http://wiki.venividilibri.org/index.php?title=CDDL.</footnote>

<footnote n="7">7. http://wiki.venividilibri.org/index.php?title=CommonPublicLicense.</footnote>
mettre ses œuvres gratuitement à la disposition du public, sous réserve des droits des éventuels coauteurs et de ceux des tiers ainsi que dans le respect des conventions qu'il a conclues. »

→ *La cession de droits*

La doctrine juridique se divise sur le sujet, une partie considérant que la cession de droits de propriété intellectuelle pouvait être exclusive ou non exclusive, une autre partie estimant qu'une cession était nécessairement exclusive, contrairement à la concession qui était non exclusive. Plus simple et parfaitement adaptée à l'idée d'une propriété immatérielle différente c'est la première conception qui est retenue dans cet ouvrage : celle-ci est par ailleurs naturellement non exclusive <fnref n="1" />.

La cession d'un droit est l'élément essentiel au fonctionnement des licences libres : en l'absence de droits que le concédant « partagerait », les licenciés n'auraient aucun intérêt à accepter de quelconques engagements pour l'utilisation de créations gratuitement accessibles.

Si toutes les licences récemment mises à jour répondent au formalisme légal <fnref n="2" />, il n'en était pas toujours ainsi, certaines licences <fnref n="3" /> contenant parfois des cessions implicites <fnref n="4" /> à la valeur très contestable.

→ *Les atteintes potentielles au droit moral*

La liberté de ne pas partager est aussi importante que celle de partager... Cette idée est souvent rappelée en réaction aux licences *copyleft* qui soumettent les licenciés ayant fait acte créatif sur la base de l'œuvre initiale à diffuser l'œuvre dérivée sous une licence précise.

Il est en effet incontestable que chacun doit pouvoir choisir l'exploitation souhaitée pour sa création et, en fonction, être libre d'opter pour une

<footnote n="1">1. Voir LUCAS (André) et LUCAS (Henri-Jacques), *Traité de la propriété littéraire et artistique*, Paris, Litec (567), 2006.</footnote>

<footnote n="2">2. Art. L131-3 du CPI : « La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. »</footnote>

<footnote n="3">3. Par une extrapolation de l'usage des termes *use* et *grant* dans la licence MIT par exemple.</footnote>

<footnote n="4">4. Contraire, donc, à l'article L613-8 du CPI qui stipule en son dernier alinéa que « [l]es actes comportant une transmission ou une licence, visés aux deux premiers alinéas, sont constatés par écrit, à peine de nullité ».</footnote>
licence libre ou non. Une telle clause pourrait être perçue comme une atteinte au droit (de divulgation, ou de destination si la création est publique) de l'auteur de la création dérivée. Mais la réalité est plus simple : le licencié conserve toujours la liberté soit de respecter la licence, et donc de diffuser l'œuvre dérivée ainsi qu'il lui est demandé, soit de renoncer à distribuer cette dernière en l'état, quitte à distribuer ses propres contributions, à part, sous une autre licence<fnref n="1" />.

Le droit au respect de l'intégrité de l'œuvre pourrait aussi être évoqué, fidèlement au principe classique selon lequel seules seraient valides les ratifications et approbations données en pleine connaissance de cause à postériori. Il semblerait néanmoins qu'il soit possible d'interpréter différemment cette contrainte lors de la modification de créations sous licences libres. Ce serait en effet ignorer l'aspect fondamental du Libre, les œuvres étant imaginées comme collaboratives et évolutives. À l'inverse, une diffusion propriétaire de celles-ci pourrait valablement être considérée comme contraire au respect des droits moraux de l'auteur.

### Pour aller plus loin...

- l'article de Jurispedia consacré aux licences libres (http://fr.jurispedia.org/index.php/Licence_libre) ;

- JOCQUEL (Grégoire), « Licence GPLv3 et aspects de droit privé », EOLE 2008.

### La notion de license

Il existe outre-Atlantique un débat relatif à la qualification de *license* (engagements de détenteurs de droits soumis à un régime fédéral dans le cadre des lois sur le copyright) préférée à celle de *contract* (convention similaire à notre notion française, soumise au régime général des contrats américains). La *license américaine* n'est pas l'équivalente de la licence que nous connaissons : sorte de convention unilatérale par laquelle, plutôt que de conférer des droits aux utilisateurs, l'auteur s'engage à ne pas les leur opposer. L'analogie est souvent faite avec une permission générale

<footnote n="1">1. Cela dit, ce comportement peut être lui-même critiquable lorsque ces contributions sont elles-mêmes fortement inspirées de l'œuvre originale.</footnote>
qui serait donnée de traverser un jardin à certaines conditions, par exemple celle de porter un chapeau : nous y verrions un contrat, les Américains une licence. Les conséquences pratiques sont de plusieurs ordres, notamment quant à la juridiction compétente et la réparation attachée à leur violation : interdiction d'exploiter ou exécution forcée en cas de licences, simple dédommagement en cas de contrat.

Néanmoins, même si certains auteurs américains contestent la qualification de contrat aux licences libres<fnref n="1" /> et que certaines d'entre elles refusent expressément l'appellation de contrat<fnref n="2" />, cette question suscite à priori peu d'intérêt dans notre système qui n'y voit qu'une cession gracieuse et non exclusive de droits de propriété intellectuelle. Par ailleurs, il semble difficilement défendable de nier l'existence d'un contrat lorsqu'un certain nombre de comportements est attendu des licenciés.

L'affaire Jacobsen v. Katzner<fnref n="3" />, qui s'est étendue de 2008 à 2010, a permis de porter l'attention sur les enjeux. Les apports des juges furent très intéressants puisque la cour d'appel estima que le non-respect de la licence (Artistic License) n'entraînait pas seulement des sanctions contractuelles (qui auraient seulement entraîné l'allocation de dommages et intérêts), mais aussi des sanctions pour violation de la licence. Décision spécifique à l'Artistic License, l'arrêt établit par ailleurs les critères permettant de distinguer les obligations (contractuelles) des conditions (rattachées au bénéfice de la licence)<fnref n="4" /> qui sont attachées aux cessions de droits.

### 2.1.1.1.b Les parties aux contrats

La question est ici généralement celle de l'opposabilité du contrat : conformément à l'effet relatif des contrats, seules les parties qui se sont engagées doivent répondre de leurs obligations. Les licences libres posent

<footnote n="1">1. Voir JONES (P.), « The GPL Is a License, not a Contract », Linux Weekly News, 3 décembre 2003 ; à contrario : ROSEN (L. E.), « Open Source Licensing : Software Freedom and Intellectual Property Law », Upper Saddle River, N.J., Prentice Hall PTR, 2004, p. 59-66.</footnote>

<footnote n="2">2. Voir par exemple l'article 9 de la GNU GPL v. 3 : « Not a Contract. »</footnote>

<footnote n="3">3. Voir l'arrêt Jacobsen v. Katzner, United States Court of Appeals for the Federal Circuit, 18/08/2008 (http://www.cafc.uscourts.gov/images/stories/opinions-orders/08-1001.pdf).</footnote>

<footnote n="4">4. La décision suivante fut néanmoins moins favorable aux auteurs du logiciel libre puisqu'elle fixa très haut les critères permettant d'obtenir les injonctions visant à faire cesser la violation de la licence. L'affaire s'est terminée en février 2010 par une transaction entre les parties.</footnote>
par ailleurs deux questions particulières : l'impact dans les grands groupes ou institutions, et l'impact de la chaîne contractuelle.

→ *L'engagement des grands groupes par les licences libres*

Il s'agit ici des grands groupes industriels, mais aussi des centres de recherche, universités, etc., c'est-à-dire le type de structure au sein de laquelle la personnalité juridique est plus large et le pouvoir d'engagement détenu à un plus haut niveau.

Les licences raisonnent, tels des contrats, à l'échelle des personnes (physiques ou morales) qui cèdent ou bénéficient de cette cession. Si l'enjeu est minime dans le cadre de la simple utilisation personnelle d'un logiciel libre par un collaborateur, il devient beaucoup plus important lorsque la licence est utilisée pour partager des droits détenus par l'entité utilisatrice dudit logiciel. C'est par exemple le cas lorsque la personne morale est titulaire de droit en vertu de la dévolution automatique des droits d'une œuvre collective (création logicielle salariale) ou encore d'une cession expresse. Or les créations sous licences libres sont souvent utilisées ou intégrées par des individus qui ne possèdent pas la capacité d'engager leur structure, ce qui oblige à trouver plusieurs palliatifs, comme la mise en place d'un processus qui permette d'obtenir les validations nécessaires ; la mise en place d'une délégation de pouvoir permettant à certaines personnes dans certaines conditions d'engager la société par une licence libre, ou la renonciation à la dévolution automatique des droits dans certaines circonstances et au profit de certaines personnes. La première solution est la moins risquée, mais aussi la plus lourde administrativement (songeons que seul le doyen peut consentir un tel engagement dans le cadre d'une université). La seconde présente les risques inhérents à toute délégation, notamment du fait d'un portefeuille de brevets qui pourraient se trouver affaiblis par ignorance de ces derniers. La dernière peut résoudre certaines difficultés, mais réduit les droits de la structure et n'est pas adaptée à toutes les solutions, notamment lorsqu'il y a ensuite une diffusion desdites créations.

En matière de groupe de sociétés, la FAQ de la GNU GPL<fnref n="1" /> renvoie à la loi applicable en indiquant que la loi américaine ne semble pas considérer qu'il y ait dans ce cas de distribution. En droit français la notion

<footnote n="1">1. http://www.gnu.org/licenses/GPL-faq.html.</footnote>
d'entreprise, dépassant les clivages de simples sociétés, permettrait sans doute d'arriver à la même conclusion. Néanmoins, il est fréquent que ces grands groupes fusionnent, intègrent des sociétés, s'en séparent ou fassent appel à des filiales. Il est alors nécessaire de veiller à ce que les licences soient respectées lorsque des créations sous licences libres circulent entre plusieurs personnes juridiques (entre une société mère et ses filiales, mais aussi en cas de rachat de l'activité d'une société par une autre, etc.). En effet, la situation juridique de ces dernières peut engendrer l'application des licences sans qu'il n'y ait d'acte matériel supplémentaire (sauf à s'assurer que seule la personne juridique initiale conserve lesdites créations), si l'élément déclencheur peut rétroactivement être considéré comme atteint.

→ *La question de la chaîne contractuelle*

La notion de chaîne contractuelle s'est développée avec l'industrialisation et la multiplication des intermédiaires. Il s'agit d'une succession de contrats reliés par une identité d'objet et relatifs à un même bien. La chaîne est dite homogène lorsqu'elle est constituée d'une suite de contrats qui ont une qualification identique. On parle par ailleurs de groupe de contrats lorsque les contrats qui se succèdent ne portent pas sur le même objet, mais concourent à un même but (ce qui peut caractériser les créations pour lesquelles chaque contribution est cédée selon les mêmes termes).

Elle permet, en présence de contrat translatif de propriété, tel que la vente, d'opposer des clauses contractuelles qui suivent le bien transféré de manière accessoire (clause d'exclusion de garantie, clause compromissoire, etc.). En l'espèce, et en l'absence d'exclusivité des cessions, il ne semble pas possible d'appliquer ces effets<fnref n="1" />.

En matière de licence libre, soit le contrat de licence autorise le sous-licenciement<fnref n="2" />, et dans ce cas le licencié cède les droits qui lui ont été cédés au surplus des droits patrimoniaux sur ses contributions propres, soit le sous licenciement est interdit<fnref n="3" /> et le licencié cède ses droits en son

<footnote n="1">1. Une étude supplémentaire serait probablement nécessaire, mais il est possible de noter que le Conseil Supérieur de la Propriété Littéraire et Artistique relevait dans son rapport de 2007 « la complexité de la chaîne contractuelle ».</footnote>

<footnote n="2">2. Comme les licences BSD et MIT (en réalité la majorité des licences permissives), ou CeCILL (-A, -B, ou -C), OSL, EUPL, etc.</footnote>

<footnote n="3">3. Comme la majeure partie des licences *copyleft*: GNU (L-,A-), GPL, MPL, etc.</footnote>
nom et agit au nom de chaque autre contributeur (mandat) ou grâce à la stipulation pour autrui<fnref n="1" /> pour les droits restants.

L'ajout d'une licence compatible est une autre situation qui peut aussi compliquer la chaîne contractuelle résultant de la création sous licence libre.

Ainsi, en plus de l'action qu'il pourrait souhaiter sur le fondement du contrat de mise à disposition, le licencié pourra se retourner contractuellement sur le fondement de la licence : contre le concédant seulement dans le cas d'une licence basée sur le sous-licenciement (à sa charge de se retourner ensuite contre ses propres concédants) ; contre chaque contributeur pour sa seule contribution si la licence n'autorise pas le sous-licenciement. Les deux options présentent néanmoins chacune des avantages et des inconvénients. La chaîne contractuelle peut par exemple remettre en question le bénéfice de la licence si l'un des maillons se retrouvait défaillant.

### 2.1.1.1.c L'objet du contrat

Quelle que soit la licence, la création à laquelle elle est associée — ou, plus précisément, les droits relatifs à cette création — constitue l'objet du contrat, qui peut pour partie être une œuvre, pour partie invention, etc. Au fur et à mesure que de nouveaux contributeurs participeront à l'évolution de cette création, le statut de celle-ci sera de plus en plus tourné vers le public/ses utilisateurs, pour finir par être uniquement gouverné par la licence libre (et sa finalité de rendre *libres* ses utilisateurs) lorsque leur nombre sera trop conséquent pour qu'ils puissent s'exprimer d'une seule voix. La création deviendra ainsi un élément distinct, détaché de la personne de ses auteurs, et avec sa propre vie (et ses évolutions inattendues).

C'est donc une logique véritablement inverse à la conception traditionnelle de ces droits selon laquelle un rapport fort lie l'œuvre et son auteur. D'où le fait que l'obligation essentielle du contrat (on pourrait aussi parler

<footnote n="1">1. Voir pour cette analyse, COOL (Yorick), *op. cit.* On ajoutera que depuis un arrêt de la première chambre civile de la Cour de cassation du 21 novembre 1978, « la stipulation pour autrui n'exclut pas, dans le cas de l'acceptation par le bénéficiaire, qu'il soit tenu de certaines obligations » (Bull. Civ., I, n° 356 ; voir aussi Civ. Ire, 8 déc. 1987, Bull. Civ., I, n° 43). On remarque néanmoins que pour une utilisation en l'espèce, la lettre du Code civil s'en trouve altérée.</footnote>
de prestation caractéristique) porte sur celui qui cède les droits (le don-
neur de licence), condition primordiale pour assurer l'objectif de liberté
au profit des utilisateurs subséquents.

Du fait de l'évolution de notre société vers l'immatérialisation, l'objet
de droits devient de plus en plus complexe, glissant du seul logiciel — en
qualité d'œuvre — à tout type de créations, tant du domaine de la propriété
littéraire et artistique (œuvres, interprétations, bases de données, etc.) que
de la propriété industrielle (brevets, topographies de semi-conducteurs,
etc.).

2.1.1.2 Les éléments liés au caractère international des licences

Il s'agit ici de la langue du contrat (2.1.1.2.a) et des notions de loi ap-
plicable et de tribunaux compétents (2.1.1.2.b).

2.1.1.2.a La langue du contrat

Les licences sont, dans leur très grande majorité, rédigées en langue anglaise. Pour contrôler les risques d'erreurs, les traductions des licences n'ont généralement aucune valeur contractuelle. C'est notamment la position vis-à-vis des licences GNU, même si, à l'inverse, d'autres licences (LAL, CeCILL ou plus largement encore l'EUPL) confèrent expressément une valeur équivalente aux diverses versions. Quoi qu'il en soit, il est toujours utile de les associer lors de la distribution de la création, leur faisant intégrer un tout qui, même expressément exclu de la relation contractuelle, sera connu des parties et du juge. Car si un titulaire de droits peut parfaitement choisir d'utiliser la seule version traduite, il court le risque d'y glisser des erreurs voire, lorsque la licence est *copyleft*, de rendre cette version incompatible avec la version originale.

Ainsi, l'usage de telle licence anglaise présente sur le plan civil un
risque de vice du consentement (sur le fondement de l'erreur le cocon-
tractant pouvant prétendre n'avoir pu saisir les termes du contrat) <fnref n="1" /> ou, sur
le plan pénal, une contravention en application de la loi Toubon relative

<footnote n="1">1. Une décision allemande du 19 mai 2004 — fortement critiquée — avait néanmoins considéré l'usage de la langue anglaise comme « usuel et compréhensible par les professionnels de l'informatique ».</footnote>
à l'emploi de la langue française<fnref n="1" /> notamment dans le cadre des licences de logiciels et à l'égard des contrats à destination des consommateurs ou impliquant des personnes publiques).

### 2.1.1.2.b La loi applicable et la juridiction compétente

En application de la convention de Rome sur la loi applicable aux obligations contractuelles (19 juin 1980) le juge doit se baser sur : le choix des parties (art. 3) ; à défaut, la loi du pays avec lequel le contrat présente les liens les plus étroits (art. 4) ; en présence du consommateur (c'est-à-dire un étranger à l'activité professionnelle), la loi du pays de résidence de celui-ci (art. 5).

La détermination se fera donc au cas par cas : conformément aux licences lorsqu'elles précisent la loi applicable (certaines licences précisent celle-ci ou les règles relatives à sa détermination) ou, à défaut, conformément aux règles classiques.

### 2.1.1.3 L'exclusion de responsabilité et de garanties

Par principe, les licences libres excluent toute responsabilité et il n'est d'ailleurs pas certain que le droit de la consommation trouve à s'appliquer à défaut de déséquilibre entre les parties. Deux remarques néanmoins : cela est surtout vrai dans l'hypothèse où tant la licence que la mise à disposition de la création se font à titre gracieux, ensuite, cette exclusion ne s'étend cependant pas à la responsabilité qui serait liée au propre fait de l'auteur (auteur d'une faute lourde).

En matière de garantie, la garantie d'éviction (être titulaire de droits sur les droits que l'on cède) ne peut être exclue, d'autant que cette cession de droit est la cause de l'engagement du licencié. En revanche, les garanties légales (garantie légale de conformité, garantie légale des vices cachés) ne s'appliquent pas automatiquement à la licence (en l'absence de vente), mais pourront éventuellement trouver à s'appliquer au contrat de mise à disposition (voire de développement spécifique) susceptible de lier le licencié au concédant.

<footnote n="1">1. Loi n°94-665 du 4 août 1994 relative à l'emploi de la langue française.</footnote>
### 2.1.2 Une cession non exclusive de droits

La non-exclusivité des licences est à la base de leur fonctionnement. C'est aussi elle qui permet de justifier les obligations, parfois excessive-ment contraignantes, à la charge du concédant. En effet, même lorsque celui-ci se voit contraint par une licence *copyleft*, il ne perd en aucun cas la possibilité d'exploiter différemment ses contributions à un autre mo-ment, dans un autre cadre et à d'autres conditions (quitte à en faire une version mise à jour entièrement propriétaire).

C'est grâce à ce mécanisme de cession non exclusive qu'il est souvent possible de multiplier des situations d'exploitation complexes mêlant pro-priétaire et *open source*, ou composants *open source* sous licences à priori incompatibles.

### 2.1.3 Quelques jugements

Même s'il ne cesse d'augmenter, le faible nombre de décisions relatives aux licences libres ne permet pas de considérer l'existence d'une vraie jurisprudence ou doctrine sur laquelle s'appuyer. Par ailleurs, la plupart des jugements « traditionnels » antérieurs reposent sur un esprit tout à fait différent et ne sont guère adaptés aux nouvelles situations relatives aux logiciels libres.

Néanmoins, il convient d'admettre que le mécanisme sur lequel re-posent les licences renforce leur respect. En effet, soit l'utilisateur reconnaît la validité de la licence et peut utiliser la création afférente, soit il conteste cette dernière et se retrouve en position de contrefacteur. C'est la raison pour laquelle la plupart des décisions ou des litiges ne concernent pas l'application des licences (ceux-ci étant à leur très grande majorité réglés par le biais d'une transaction<fnref n="1" />), mais le respect d'autres règles de droits (telle que la contestation des droits de propriété intellectuelle sur l'œuvre, la contestation de la sanction, la violation d'autres prérogatives patrimoniales ou extra-patrimoniales, etc.).

L'Allemagne est ainsi à l'origine des décisions les plus importantes pour la GNU GPL et, par extension, pour les autres licences libres : en référé

<footnote n="1">1. L'initiative gpl-violations.org évalue à plus de 150 le nombre de dossiers traité en dehors des tribunaux.</footnote>
en 2004 (Munich) contre Sitecom Deutschland, puis devant le tribunal de Francfort contre D-Link Deutschland<fnref n="1" /> GmbH le 22 septembre 2006 et enfin devant le tribunal de Munich contre Skype en 2008. Les apports vont de la reconnaissance de la GNU GPL comme un contrat valide jusqu'à la sanction du non-respect du formalisme qu'elle impose.

Un grand nombre d'actions furent menées aux États-Unis sous l'impuissance de la SFLC, mais l'affaire Jacobsen v. Katzer fut la plus riche puisqu'elle confirma, au regard du droit américain (et pour une licence en particulier) les sanctions attendues du non-respect d'une licence libre (telles que l'exécution forcée des obligations du licencié ou l'interdiction d'exploitation de la création).

Pour ce qui concerne la France, les quelques jugements relatifs à des litiges concernant des logiciels intégrant (ou plus précisément, utilisant) des composants open source 2 sont pauvres en apports. Tout au plus est-il rappelé que les droits relatifs à des logiciels sous licence libre appartenant à des tiers ne peuvent être cédés (de façon exclusive) par le prestataire que si ce dernier est soumis à une obligation d'information et de conseil qui s'étend notamment à l'indication d'un tel usage, mais que la faute peut être en partie imputée au client lui-même s'il ne pouvait ignorer l'existence de ces composants et de leur licence. Très intéressante en ce qu'elle entendait définir la notion de distribution au sein de la GNU GPL v. 2, l'affaire Free résulta, dans le courant de l'année 2011, en une transaction favorable aux attentes des titulaires de droits.

On retiendra enfin de l'arrêt américain Wallace v. International Business Machines Corp. et al. de 2006, ainsi que de l'affaire Skype, que l'usage des licences libres n'est pas constitutif d'un comportement contraire aux lois antitrust. Le juge américain a au contraire affirmé que :

> La GPL encourage, plutôt que décourage, la libre concurrence et la distribution de systèmes d'exploitation, desquels bénéficient directement les consommateurs.

<footnote n="1">1. Voir le communiqué sur http://gpl-violations.org/news/20060922-dlink-judgement_frankfurt.html.</footnote>

<footnote n="2">2. TGI Paris, 28 mars 2007, « Educaffix c/ CNRS, Université Joseph Fourier et a. » ; TGI Chambery, 15 nov. 2007, « Espaces et Réseaux Numériques c/ Conseil général de Savoie et Université de Savoie » ; et CA Paris, 16 sept. 2009, « SA EDU4 c/ Association AFPA »</footnote>
teurs. Ces bienfaits comprennent : des prix moins élevés,
un meilleur accès et plus d'innovation.<fnref n="1" />

Fruits partiels des litiges liés à l'utilisation des licences Creative Com-
mones, quelques jugements évoquèrent expressément ces dernières :

- 2006 : la District Court of Amsterdam a considéré que les termes des licences Creative Commons s'appliquaient automatiquement pour tout usage d'une œuvre sous cette licence et qu'un professionnel aurait au moins dû cliquer sur le symbole et lire le texte de la licence ;

- 2006 : une cour espagnole a rejeté la demande de la principale société de perception et de redistribution des droits espagnole (SGAE) qui souhaitait collecter des droits sur un bar qui ne passait que de la musique sous licence Creative Commons ;

- 2007 : pour la diffusion sous licence Creative Commons -By de la photographie d'un mineur dans une campagne de publicité de Virgin Australie 2. Les parents ont finalement retiré leur plainte à l'encontre de Virgin pour utilisation d'une photographie de leur enfant sans leur autorisation, comme le photographe retira la sienne qui reprochait à Creative Commons de ne pas suffisamment avertir des conséquences relatives à l'usage de ses licences 3 ;

- 2010 : tribunal de Nivelles concernant le non-respect de la licence (Paternité et NC) ; condamnation pour contrefaçon ;

- 2011 : une cour d'Israël a retenu la contrefaçon pour l'utilisation de photographies tirées du site Flikr non conforme aux licences Creative Commons apposées sur ces dernières (http://cyberlaw.stanford.edu/node/6589).

<footnote n="1">1. « The GPL encourages, rather than discourages, free competition and the distribution of computer operating systems, the benefits of which directly pass to consumers. These benefits include lower prices, better access and more innovation. »</footnote>

<footnote n="2">2. Voir le billet de LESSIG (Lawrence), « On the Texas Suit Against Virgin and Creative Commons », 2007, sur son blog (http://lessig.org).</footnote>

<footnote n="3">3. « to adequately educate and warn him ... of the meaning of commercial use and the ramifications and effects of entering into a license allowing such use. » (Point V de la plainte).</footnote>
### 2.2 Caractériser par une classification des licences libres

De nombreux regroupements permettent de classifier les différentes licences libres. Les cumuler et les croiser permet d'avoir une vision plus globale du système des licences libres. Il est ainsi possible de regrouper les licences en deux catégories, licences permissives et licences *copyleft* (2.2.1), en phase historique (2.2.2), par domaine d'application (2.2.3) ou encore en fonction des libertés qu'elles confèrent aux utilisateurs (2.2.4).

#### 2.2.1 Classification classique : licence copyleft versus permissive

L'utilisation du terme *copyleft* désigne des licences qui rendent persistantes les libertés consenties en astreignant les utilisateurs subséquents à concéder systématiquement les mêmes libertés. Dans cette situation c'est l'intérêt de l'utilisateur final qui prévaut sur la liberté de celui qui diffuse l'œuvre. Deux types de clauses traduisent cette mention :

- celles qui imposent l'utilisation d'une licence particulière (à l'instar de la GNU GPL, à son propre compte);

- celles qui obligent à conférer les mêmes libertés (comme le fait la Licence Art Libre (LAL) : les droits cédés devront se retrouver dans la licence finale, qu'il s'agisse de la LAL ou de toute autre.

Il en résulte une relation de confiance qui sécurise et favorise les collaborations entre professionnels. Seule une cession non exclusive est requise juridiquement et les contributeurs restent donc titulaires de leurs droits. Ils conservent ainsi la liberté d'exploiter leur contribution par ailleurs, que ce soit sous licence libre ou commerciale.

À l'inverse, on parle de licence *permissive* lorsque seules les obligations de celui qui reçoit l'œuvre doivent être transmises (ainsi en est-il notamment de la licence Apache), laissant le contributeur libre d'en ajouter d'autres lors du transfert aux utilisateurs subséquents, y compris sous forme de licence commerciale. Les licences les plus permissives (BSD, MIT, etc.) sont traditionnellement assimilées à des renonciations et le statut des œuvres est proche de celui des œuvres tombées dans le domaine public puisqu'elles n'imposent en règle général que le respect
de la paternité (avec les habituelles clauses d'exclusion ou limitation de garanties et de responsabilité). Cette relative liberté les fait coexister sans anicroche puisqu'il est très simple pour ces licences d'être compatibles en perpétuant simplement les obligations initiales. Elles peuvent néanmoins contenir des obligations qui les rendraient incompatibles avec certaines licences *copyleft*<fnref n="1" />. Cette absence d'incompatibilité a pour effet une très grande diversité de licences, parfois très *libertaires*, sans formalisme poussé, leur usage est néanmoins généralement conditionné à l'ajout a minima d'une exclusion de garantie et de responsabilité pour l'inclusion dans certaines distributions (notamment Debian).

<figure><img src="image_36.png" /></figure>

## ANDROID ET LA LICENCE APACHE

Comme la majorité des produits de la firme Google, Android est essentiellement distribué sous licence Apache, à l'exception de certains composants bien isolés tel le noyau Linux. Certaines applications fournies avec le logiciel restent néanmoins propriétaires, telles Android Market ou Google Maps.

Récemment, il est apparu que la version 3 de l'OS, dédiée aux tablettes, ne serait pas diffusée en *open source* (rien n'est dit quant à son portage sur les portables). Une situation critiquable lorsqu'on admet que certains contributeurs, personnes physiques ou morales, ont pu créer de la valeur au profit de ce système alors même qu'ils ne l'auraient pas fait pour un système fermé classique.

Voir sur ce point l'article de METZ (Cade), « Google Open Source Guru : 'Why we ban the AGPL', *The Register*, 2011 (http://www.theregister.co.uk/2011/03/31/google_on_open_source_licenses).

## Copyleft et autre terminologie

Le terme *copyleft*, double jeu de mots *copyleft/copyright et copy 'left'*, n'est pas le seul utilisé pour décrire ce type de clauses. On

<footnote n="1">1. Cf. infra.</footnote>
parle ainsi parfois de *réciprocité*, *prophylaxie*, ou, plus négativement, de *viralité* ou de *contamination*.

### 2.2.2 Classification historique

Même si moins tranchée et plus personnelle, une représentation historique des licences permet un second regroupement opportun.

La première série de licences est dite *philosophique*. Elle comprend les licences publiées par la Free Software Foundation ainsi que celles qui partagent leur esprit et leur philosophie.

Les plus utilisées sont celles de la FSF. La première de la famille est la GNU General Public License, publiée en 1989, modifiée en 1991 et 2007. Sa petite sœur est la GNU Library General Public License, renommée Lesser GPL, et leur cousine, à destination de la documentation, la GNU Free Documentation Licence. Fin 2007, la GNU Affero GPL est la dernière des licences à s'être ajoutée à celles existantes (le projet de la Simpler FDL semble être figé).

À l'origine, le langage de ces licences est très proche de celui des développeurs. Il est empreint d'une intention forte et d'une portée parfois difficile à définir. La réécriture récente des licences ajoute néanmoins à cette famille de licences des versions beaucoup plus juridiques et complexes. Elles s'opposent à toute réappropriation du code grâce à leur *copy-left* qui impose que tout logiciel dérivé, basé sur, ou constituant un tout avec le logiciel, soit lui-même soumis à cette même licence. Les sociétés intéressées par l'alternative du libre hésitent souvent à recourir à l'utilisation de ces licences aux implications extensives et parfois incertaines, mais les communautés y voient un gage de confiance.

Une seconde série de licences, poussée par le monde académique/universitaire, accompagna la diffusion des nombreux logiciels qui composent aujourd'hui l'infrastructure d'Internet. Par exemple, le système de nom de domaine BIND, le protocole TCP/IP et Sendmail sont tous des standards de facto construits et diffusés sous licences permissives. On y retrouve l'idée d'un partage des connaissances sans condition issue des universités américaines et elles sont le plus
fréquemment formulées d'une façon courte et claire. Elles consistent généralement en l'énumération de la totalité des droits conférés, une obligation de respecter la paternité de l'œuvre et une exclusion de responsabilité et de garantie. Un bon exemple est la licence BSD, pour Berkeley Software Distribution.

Parallèlement, de nombreuses communautés s'étaient constituées autour de projets qui, pour certains d'entre eux, finirent par se structurer au travers de leurs propres licences, dites *communautaires*. Très spécifiques puisqu'intimement liées à un projet et son vécu, elles sont en principe peu juridiques et trop souvent susceptibles d'interprétations hasardeuses. Les deux plus symptomatiques sont la licence Artistic et la licence Apache (dans sa première version). Elles sont essentiellement des licences permissives, mais leur spécificité (en matière de brevets ou clause de publicité) les rend difficiles, voire impossibles, à concilier avec la plupart des licences *copyleft*.

Concrétisation du mouvement *open source*, l'arrivée de sociétés commerciales induisit la rédaction de licences industrielles<fnref n="1" /> adaptées aux nouveaux modèles économiques qu'elles introduisirent. La licence la plus symptomatique est sans aucun doute la Mozilla Public License (MPL), rédigée par la firme Netscape pour la libération du code de son navigateur. Mais d'autres existent sur le même modèle : l'EPL, la Nokia Public License, l'OSL, etc. Ces licences sont précises, très complètes, et ont une étendue circonscrite.

### 2.2.3 Classification par domaine

Comme le laisse entrevoir cet ouvrage, les licences libres sont aujourd'hui utilisées dans de nombreux domaines : les logiciels bien sûr, mais aussi les encyclopédies (on pense bien sûr à Wikipedia), les livres, la musique et bientôt tout type de création. La majeure partie des licences libres trouve ainsi son fondement dans une application particulière pour un domaine artistique ou technique bien déterminé et il est généralement délicat, et déconseillé, de transposer dans un nouveau domaine des licences pensées et rédigées dans un contexte particulier.

<footnote n="1">1. Également dit *courant institutionnel*.</footnote>
Par exemple, le formalisme extrêmement contraignant de la GNU GPL n'est pas du tout adapté à la musique : le texte entier de la licence doit être attaché, les sources doivent être simultanément fournies, etc. Inversement, des licences comme les Creative Commons ont été écrites pour la musique, le film, les livres, etc., mais pas pour les logiciels ou les bases de données (de type OpenStreetMap). Ainsi, utiliser une licence Creative Commons pour un logiciel, par exemple une CC By-SA (licence assez similaire à la GNU GPL), n'est pas conseillé par Creative Commons<fnref n="1" /> puisque tous les aspects propres au logiciel sont inexistants : la distribution du code source n'est pas envisagée, la dimension liaison non plus, etc.

Enfin, quelques licences, plutôt rares, ont été rédigées avec l'ambition de s'étendre à l'ensemble des créations couvertes par le droit d'auteur, voire à toute la propriété littéraire et artistique : l'OSL et la LAL sont deux très bons exemples, même si l'une reste plus adaptée aux logiciels et la seconde aux œuvres non logicielles.

Il est néanmoins nécessaire dans certaines situations, notamment en présence d'œuvres dites multimédias (regroupant différents types d'œuvres), de réfléchir à l'opportunité d'utiliser une licence pour le tout dans un objectif d'uniformisation ou de privilégier une approche modulaire en utilisant une licence pour chaque type d'œuvre. Il n'y a encore une fois ni bonne ni de mauvaise réponse, tout dépend des circonstances. Les politiques complexes de licences sont par exemple fréquentes en matière de jeux vidéo : moteur sous licence GNU GPL, textures, cartes et graphisme sous une licence non libre.

<figure><img src="image_37.png" /></figure>

### EXEMPLE PRATIQUE

La motivation du changement de licence de Wikipedia en 2009 est un bon exemple de l'inadéquation des contraintes matérielles de la GFDL vis-à-vis des articles publiés sur l'encyclopédie en ligne. Toutes les licences de la famille GNU imposent en effet un formalisme assez lourd lors de l'exploitation du contenu, de la création, soumis à cette licence. La GNU FDL imposait notamment 1) que la

<footnote n="1">1. http://wiki.creativecommons.org/FAQ.</footnote>
licence soit systématiquement recopiée au côté de la création (voir imprimée, selon le nombre d'exemplaires tirés) et 2) un *copyleft* très fort (calqué sur celui de la GNU GPL).

Ces conditions, dont le non-respect aurait normalement dû causer la résolution de la licence, étaient ainsi très rarement respectées et diminuaient d'autant la capacité des auteurs à faire respecter d'autres points de leur licence. À titre d'exemple, l'ajout d'une Creative Commons CC BY-SA 3.0 (avec une étendue plus raisonnable et qui impose seulement des mentions légales succinctes ainsi qu'un lien vers la licence) a eu pour effet de sécuriser la réutilisation du contenu de Wikipedia.

### 2.2.4 Classification par libertés

Sous la coprésidence de Valérie-Laure Bénabou et de Joëlle Farchy, la commission spécialisée du CSPLA, portant sur la mise à disposition ouverte des œuvres de l'esprit, a publié en juin 2007 un rapport reprenant une distinction issue des travaux de thèse de Mélanie Clément Fontaine sur les œuvres libres<fnref n="1" />. On y retrouve cette classification entre libertés réellement conférées :

- les licences qui offrent une liberté pérenne. Il s'agit des licences disposant d'un *copyleft* : l'œuvre et ses dérivées sont libres et le resteront;

- les licences qui offrent une liberté fragile. Il s'agit ici des licences permissives qui autorisent la propriétarisation par un tiers d'une œuvre dérivée : les contributeurs acceptent que leurs contributions soient intégrées dans un produit commercial, et n'ont aucune garantie de bénéficier des contributions ultérieures;

- les licences qui offrent une liberté asymétrique. Il s'agit ici des licences qui créent un déséquilibre au profit de celui qui a choisi initialement la licence. Il s'agit par exemple des licences interdisant l'exploitation commerciale de l'œuvre (la CC BY-NC ou, autrefois,

<footnote n="1">1. CLÉMENT-FONTAINE (Mélanie), *Les œuvres libres, op. cit.*.</footnote>
l'Aladdin Free Public License <fnref n="1" /> en matière de logiciel) ou la modification de celle-ci (la CC By-ND) <fnref n="2" />.

## 2.3 Déchiffrer : une grille de lecture de licences libres

Distinguer les licences les unes des autres est une première étape, nécessaire, mais non suffisante pour en jouir entièrement. Encore faut-il en effet comprendre la structure commune à chacune d'entre elles.

S'il était possible de construire une nouvelle analogie avec les recettes, le code source étant très souvent comparé à celles-ci, il pourrait être dit qu'il est nécessaire d'apprendre et de maîtriser la recette originale avant de faire preuve d'imagination.

La grille qui suit s'inspire d'un tel travail empirique basé sur l'étude de plusieurs dizaines de licences libres et de leurs variantes — étant entendu qu'une telle grille de lecture a pour objet d'être simplificatrice et qu'il n'est pas possible, pour qui veut comprendre les licences libres, de s'épargner l'effort de les lire. De manière générale, les licences libres ont des effets différents selon que l'utilisation est destinée à l'usage privé du licencié <fnref n="3" /> (on parle de sphère privée) ou qu'elle dépasse cet usage (ces limites étant différentes selon les licences). Conformément à la philosophie *hacker*, l'usage dans la sphère privée est entièrement libre et sans aucune contrainte alors que l'usage du logiciel en dehors de celle-ci impose de respecter toutes les obligations de licences, voire d'étendre celle-ci à d'autres composants logiciels.

Il est ainsi possible de décomposer une licence libre selon trois éléments :

<footnote n="1">1. Voir par exemple la licence (version 9) sur http://www.pdfforge.fr/content/aladdin-free-public-license.</footnote>

<footnote n="2">2. « Des licences offrant une liberté asymétrique. Dans ce cadre, l'utilisateur peut faire usage de l'œuvre, mais l'auteur n'est pas contraint de la même manière que ce dernier. Les modifications apportées ne sont pas nécessairement sous la même licence que l'œuvre initiale. Mais l'auteur peut aussi se réserver des utilités qu'il refuse à l'utilisateur et combiner une licence libre et une exploitation commerciale, lesquelles peuvent le cas échéant reprendre des modifications apportées par des utilisateurs de la chaîne » (BENABOU (V.-L.) et FARCHY (J.), Rapport *La mise à disposition ouverte des œuvres de l'esprit*, CSPLA, 2007, p. 8).</footnote>

<footnote n="3">3. Pour peu qu'il n'ait pas précédemment violé la licence.</footnote>
- ses *droits et obligations* (2.3.1) — en matière de brevet, copyleft, etc.;

- son *étendue* (2.3.2) — les effets de la licence concernent-ils uniquement le code initial ou s'étendent-ils à d'autres codes qui en dépendraient ?;

- et son *élément déclencheur* (2.3.3) — action par laquelle le licencié se voit opposer des obligations supplémentaires, généralement liées à l'implication d'utilisateurs tiers.

Enfin, de plus en plus de licences intègrent en leur sein un mécanisme de *compatibilité* (2.3.4).

## 2.3.1 Les droits et obligations des licences libres

Comme tout contrat, les licences libres sont des rapports de droits qui se composent de droits et d'obligations, les droits venant accroître l'actif du licencié tandis que les obligations grèvent son passif.

Droits et obligations sont autant d'éléments qui distinguent les licences les unes des autres— selon leurs engagements vis-à-vis des brevets, signes distinctifs, DRM, etc. — ou les rapprochent — le minimum de liberté étant fixé par leur qualité de libre et/ou d'open source.

S'il est très facile de percevoir les droits cédés par les licences libres grâce aux efforts effectués par la rédaction de la Free Software Definition (FSD) et de l'OSD (2.3.1.1), il n'existe aujourd'hui aucun référentiel commun en matière d'obligations (2.3.1.2).

### 2.3.1.1 Des droits identiques

Les droits sont harmonisés grâce aux définitions que sont l'Open Source Definition ou la Free Software Definition précédemment présentées.

Il est néanmoins possible que les licences contiennent des droits supplémentaires, par exemple quant à l'usage du nom des auteurs ou du projet, le plus lourd des effets juridiques étant probablement l'autorisation de sous-licencier (là aussi, voir précédemment).
Enfin, notons que tous les droits de propriété intellectuelle ne sont pas
systématiquement cédés. C'est le cas de la GNU GPL v. 2 qui ne partage
que les prérogatives essentielles aux libertés offertes <fnref n="1" />.

2.3.1.2 Des obligations variées

Le corollaire de cette cession de droit est l'existence de multiples condi-
tions et obligations non négociables. Les personnes qui souhaitent béné-
ficier de la licence s'engagent ainsi à en respecter les contraintes : avec
l'engagement automatique de la responsabilité de celles souhaitant s'y
soustraire.

À ce stade, il est nécessaire de préciser que l'utilisateur d'un composant
sous licence libre sera lié contractuellement avec le ou les auteurs du-
dit composant, mais qu'il sera aussi lié avec les utilisateurs subséquents
s'il contribue lui-même au composant, qu'il le fasse selon le même con-
trat (mais sans nécessairement être soumis aux mêmes obligations) ou
selon un autre (pour peu que la première licence le permette). L'absence
de consensus en la matière nuit énormément aux licences libres et tout
le monde gagnerait à ce qu'un vocabulaire ou des définitions communes
soient partagés. Les initiatives normatives ne répondent pas en effet à un
autre besoin industriel qui consiste en l'identification et en la classifica-
tion des obligations des licences (principal élément différenciateur) et de
leurs variantes (notamment lors de l'ajout de clauses d'exception ou d'in-
terprétation) <fnref n="2" />.

C'est dans les obligations (en matière de paternité, de *copyleft*, brevets, etc.), et dans leurs différentes combinaisons, que se distinguent les li- cences libres. Il est possible de suivre la *summa division* du Code civil <fnref n="3" />

<footnote n="1">1. Ainsi, dans l'esprit du copyright américain qui la gouverne, certains droits manquent à la GNU GPL : ceux de représentation (to perform) et d'exposition (to display).</footnote>

<footnote n="2">2. Il semble donc aujourd'hui nécessaire de réfléchir à la rédaction d'une telle nomenclature auxiliaire. Ce travail serait utile à deux égards : pour répondre à la demande (croisante) des clients dans le cadre du développement d'un marché de services autour des logiciels libres (de façon à ce qu'ils puissent définir précisément, mais non limitativement, le type de licences souhaité) ; pour accompagner les avancées en matière d'informatisations et d'identifications des composants et de leur licence (qu'il s'agisse de solutions communautaires comme SPDX, QSOS, ou commerciales telles que BlackDuck). Voir à cet égard JEAN (Benjamin), « Identifier les obligations des licences libres et *open source* sur la base d'une nomenclature normalisée ? », OWF 2011.</footnote>

<footnote n="3">3. FABRE-MAGNAN (Muriel), *Les Obligations*, Puf Droit, coll. Thémis Droit privé (1re édition), n°71, 2004.</footnote>
qui distingue les obligations de faire <fnref n="1" /> (2.3.1.2.a), les obligations de ne pas faire <fnref n="2" /> (2.3.1.2.b) et les obligations de donner <fnref n="3" /> (2.3.1.2.c).

### 2.3.1.2.a Les obligations de faire au sein des licences

Les obligations de faire sont des obligations par lesquelles une des parties (le débiteur) s'engage à accomplir certains actes en faveur de l'autre partie (le créancier). On peut donner comme exemples les obligations de délivrance (de remettre matériellement la chose) ou de renseignement (devoir implicite d'informer l'autre partie des informations qu'elle détiendrait relatives au contrat).

L'obligation de renseignement est particulière en matière de licence libre, compte tenu de l'importance que peut revêtir l'usage de composants open source lors du transfert final de droit. À ce sujet, la cour d'appel de Paris avait donné raison à un client public qui avait unilatéralement résolu le marché pour non-respect de ses engagements par son contractant qui lui avait caché l'utilisation de logiciels libres dans le cadre de ses développements (de sorte que sa livraison n'était pas conforme à la mission qui lui avait été confiée) <fnref n="4" />. On retient surtout de cet arrêt une obligation de conseil renforcée à l'encontre du prestataire.

Le copyleft <fnref n="5" /> est aussi l'une des obligations de faire à laquelle s'engage l'utilisateur : dans l'hypothèse où il modifierait et redistribuerait sa version modifiée, il le ferait sous la même licence (voire une licence compatible). Il est tentant de voir ici une atteinte à ses droits d'auteurs <fnref n="6" />, mais la réalité est plus simple : le licencié peut soit respecter la licence et donc diffuser son œuvre ainsi qu'il lui est demandé, soit perdre sa qualité de licencié et renoncer à distribuer l'œuvre dérivée sans l'accord exprès de l'auteur de l'œuvre originaire.

D'autres formalités se retrouvent fréquemment parmi les licences open source : l'obligation de distinguer ses propres contributions de celles des autres contributeurs, celle de tenir à jour un fichier récapitulatif des

<footnote n="1">1. Article 1142 à 1144 C. civ.</footnote>

<footnote n="2">2. Article 1142 et 1145 C. civ.</footnote>

<footnote n="3">3. Article 1136 à 1141 C. civ.</footnote>

<footnote n="4">4. CA Paris, 16 sept. 2009, SA EDU4 c/ Association AFPA.</footnote>

<footnote n="5">5. Double jeu de mots avec copy — right et avec le second sens de left signifiant laissé.</footnote>

<footnote n="6">6. Cf. supra.</footnote>
plaintes ou revendications reçues par les licenciés et de le distribuer avec les sources<fnref n="1" />. Plus généralement, toutes les obligations relatives au formalisme qui accompagne l'utilisation de la licence sont des obligations de faire : donner accès aux sources dans certaines conditions, mentionner l'auteur ou le logiciel dans certaines conditions, etc.

Certains comportements peuvent aussi être dictés au licencié, comme les clauses aménageant la juridiction compétente<fnref n="2" /> ou la loi applicable, qui peuvent être réajustées en faveur du donneur de licence.

### 2.3.1.2.b Les obligations de ne pas faire au sein des licences

Celui qui s'engage à une obligation de ne pas faire s'abstient de faire quelque chose : utiliser un signe particulier, revendiquer certains droits de propriété intellectuelle, agir en contrefaçon, etc.

En supplément, quelques licences interdisent l'usage de certains mots, souvent dénués d'originalité, et même déposés à titre de marque. S'il faut émettre des réserves sur cette pratique qui crée des exclusivités et peut être à la source d'atteintes importantes à la liberté de l'utilisateur (notamment lorsque des clauses similaires se cumulent) une justification peut être avancée, consistant à dire que dans l'espace de promiscuité d'Internet la protection de certains droits de propriété industrielle n'est pas adéquate du fait de leur application territoriale. Par exemple, en matière de marque, le donneur de licence est astreint à multiplier les dépôts (et donc les coûts) s'il veut protéger sa marque, alors qu'interdire simplement l'utilisation de son nom à ses licenciés lui permet à moindre frais de se prévenir des confusions qu'engendrerait l'arrivée d'un licencié concurrent exploitant un produit identique sous un nom similaire.

<figure><img src="image_38.png" /></figure>

## L'INTERDICTION DE L'USAGE COMMERCIAL OU DE LA MODIFICATION

Certaines licences interdisent les usages commerciaux. Il s'agit en particulier des licences Creative Commons avec la clause NC, mais on peut aussi citer l'ancienne Yello Open Music Licence ou, par certains usages seulement, la

<footnote n="1">1. Dans un fichier *ad hoc*, voir par exemple la MPL, Article 3.4 a), « Third Party Claims ».</footnote>

<footnote n="2">2. Arbitrage pour certaines, comme la Reciprocal Public License.</footnote>
licence IANG. Réintroduire ce critère revient à un retour en arrière. Au milieu des années 1990, en effet, il existait des licences comme l'Aladdin Free Public License <fnref n="1" /> qui interdisaient l'usage commercial et niaient le rôle que peut jouer l'usage commercial dans la reprise et la diffusion des créations, en particulier dans notre société capitaliste. D'ailleurs, juridiquement, les choses hors commerce sont inaliénables <fnref n="1" /> (au contraire, ce qui circule est dans le commerce).

Une autre difficulté, majeure, naît de cette interdiction : l'appréciation du critère commercial. Quelques interprétations, définitions ou FAQ, tentent d'aider à la compréhension de la notion, mais aucun consensus n'existe sur la portée précise des engagements (sachant qu'aucune interprétation n'a de valeur contractuelle/contraignante puisque seule la licence est acceptée par les parties).

Publiée en 2009, l'enquête Defining Noncommercial ² menée par Creative Commons montre la difficulté qu'il y a à envisager une définition commune tant les conceptions peuvent diverger. Néanmoins, la majorité des interviewés semble arriver à un accord relatif :

- l'utilisateur : doit être un particulier ou une personne morale non-commerçante (ou sans but lucratif dans le cas d'une association);

- la nature de l'utilisation : ne doit pas être commerciale (directement ou indirectement, comme dans le cas d'une publicité);

- condition d'utilisation : l'utilisateur ne doit pas gagner d'argent par un service qui soit en relation avec le contenu sous NC.

Néanmoins, il n'existe pas de consensus en la matière et il semble ainsi préférable de préciser soi-même ce que l'on entend autoriser en utilisant cette licence.

<footnote n="1">1. Article 1128 du Code civil : « Il n'y a que les choses qui sont dans le commerce qui puissent être l'objet des conventions. »</footnote>
<figure><img src="image_39.png" /></figure>

## L'INTERDICTION DE LA MODIFICATION

Toutes les licences Creative Commons contenant la clause ND, ou encore les licences dites verbatim (copie et distribution conformes), interdisent à quiconque de modifier la création. La question est de savoir quelle définition doit-on appliquer aux créations non logicielles, et si la possibilité de modifier est aussi inconditionnelle : la FSF estime généralement que seules les œuvres utilitaires doivent être librement modifiables, non les œuvres d'opinion ¹.

Néanmoins, souvent utilisées par défaut, sans réflexion de fond, ces licences traduisent une peur des auteurs quant au partage de leurs œuvres — une peur d'autant moins compréhensible qu'ils partagent souvent naturellement en matière de logiciel. Les conséquences de ce choix de conformité ne sont néanmoins pas neutres puisque l'œuvre est figée alors que :

- quelle que soit la licence utilisée, à aucun moment les licenciés ne se voient reconnaître une permission de détourner le discours de l'auteur original, de lui attribuer de nouvelles paroles, voire plus généralement de lui porter préjudice. Un tel comportement serait punissable : sur le fondement de la responsabilité délictuelle, ou en vertu d'autres dispositions, si opportunes (droit de la presse, droit de la personnalité, droit commun de la responsabilité, droit pénal, etc.).

- la différenciation entre œuvres techniques et œuvres d'opinion reviendrait à distinguer les œuvres où la personnalité de l'auteur (ses idées, convictions, son style, etc.) apparaîtrait, et celles où cette personnalité ne serait pas perceptible. Cette distinction n'est pourtant pas défendable puisque, juridiquement, elle reviendrait à admettre que ce qui est qualifié d'œuvre par la loi (car empreint de la personnalité de son auteur) ne serait pas sous licence libre, alors que seul ce qui n'y est pas soumis le serait.

Ce serait alors bafouer précisément le principe selon
lequel les licences libres ne sont utiles qu'en cas de droits exclusifs, et qu'elles s'appuient alors sur ces derniers pour inverser leur utilisation... Ainsi, il semble être plus pertinent d'appréhender l'œuvre comme un tout, véhiculant pêle-mêle idées, informations, connaissances, style de l'auteur, etc.

Par la suite, toute œuvre aurait un versant utilitaire et un versant propre à son auteur, et l'équilibre entre ceux-ci présagerait d'une utilisation différente si elle venait à être mise sous licence libre (plus de modification sur des œuvres essentiellement utilitaires, plus de citation concernant les œuvres d'opinion).

### 2.3.1.2.c Les obligations de donner au sein des licences

On parle d'obligations de donner lorsqu'il y a transfert d'un droit réel sur une chose (droit permettant de tirer d'un bien tout ou partie de son utilité économique — les différents droits de propriété intellectuelle entrant dans cette catégorie de droits réels<fnref n="1" />).

Les licences ayant généralement pour objet tout ou partie des droits de propriété littéraire et artistique ou de propriété industrielle, l'obligation concerne généralement ces derniers. Ainsi, la personne qui diffuse une création sous GNU GPL v. 3 s'oblige à une certaine cession de ses droits d'auteur (ou assimilés), une licence en matière de brevet, etc.

<footnote n="1">1. Ces licences sont largement utilisées par la FSF. Eben Moglen s'en explique : « Notre intention dans la phrase « verbatim copying in any medium » n'est pas d'obliger la rétention des en-têtes et des pieds de page, ou d'autres mises en forme graphique. La rétention des liens hypertextes à la fois sur les supports de type hypertextes ou non (tels que les notes ou les URL imprimées dans des médias non HTML) est en revanche requise. »</footnote>

<footnote n="1">1. Lamy Droit de l'Informatique et des Réseaux, 2011, n°828, *La qualification de vente applicable à la cession totale des droits portant sur un logiciel* : « Les droits de propriété intellectuelle — qu'ils relèvent de la propriété littéraire et artistique ou de la propriété industrielle — sont en effet des droits réels qui peuvent faire l'objet d'une cession totale (à l'exception des attributs moraux du droit d'auteur, insusceptibles d'un quelconque transfert de propriété, mais dont nous savons qu'ils sont — en matière de logiciels — réduits à fort peu de choses, voir n°191 et s.). »</footnote>
<figure><img src="image_40.png" /></figure>

### DES LICENCES QUI NE SONT PAS ENTIÈREMENT IMPARTIALES...

Généralement, les licences sont dites « génériques » et emportent les mêmes effets quel que soit le contractant, néanmoins quelques unes différencient les obligations en fonction de la qualité des personnes potentiellement engagées (telle l'EUPL lorsque la Commission européenne est partie au contrat) ou de leur rôle.

Certains donneurs de licence ont ainsi choisi de se faire conférer des prérogatives exorbitantes. C'est le cas de la licence NPL (licence calquée sur la MPL, à laquelle se rajoute une annexe conférant ces prérogatives supplémentaires), qui permet(tait) au donneur de licence de réutiliser les contributions au sein d'une distribution propriétaire. La BIPL (Broad Institute Public License) en est un autre exemple, en imposant au licencié une licence sur leur brevet alors même qu'elle ne leur en consent aucune.

Ces pratiques sont néanmoins de plus en plus rares et les licences actuellement utilisées n'en contiennent plus.

### 2.3.1.3 La sanction du non-respect des licences

Les obligations des licences libres sont généralement des conditions résolutoires : la licence contenant en effet un processus de terminaison automatique de la licence, immédiate ou différée, en cas de non-respect. Cette résiliation<fnref n="1" /> du contrat a pour effet d'interdire toute exploitation de la création concernée et de rendre l'ancien licencié susceptible de contrefaçon pour toute exploitation postérieure. Au cours d'une action particulièrement violente, la SFLC avait par ailleurs plaidé qu'en cas de non-respect de la licence, celle-ci se terminait automatiquement sans possibilité d'en bénéficier à nouveau, sauf à ce que l'auteur (ou la communauté d'auteurs) réintroduise la société dans ses droits<fnref n="2" />.

<footnote n="1">1. Et non pas *résolution*, les effets n'étant pas rétroactifs.</footnote>

<footnote n="2">2. La SFLC avait alors déclaré :« Further, once Best Buy made a distribution of BusyBox that did not comply with the license terms, the license terminated, and therefore any further act of copying or distributing BusyBox by Best Buy (even if in compliance with the</footnote>
Cette sanction étant particulièrement sévère, surtout pour le secteur industriel qui peut violer une licence par ignorance, un nombre croissant de licences atténue les effets d'un tel non-respect grâce à des mécanismes permettant au licencié de corriger son comportement voire d'être automatiquement réintroduit dans ses droits à certaines conditions (tel l'article 8 de la GNU GPL v. 3 lorsqu'il s'agit d'une première violation et que celle-ci est rapidement corrigée). La FSF s'est notamment appuyée sur cette faiblesse de la licence pour inciter les contributeurs à solliciter le passage de GNU Linux à la troisième version de la licence (« Android GPLv. 2 termination worries : one more reason to upgrade to GPLv. 3 »).

### 2.3.2 L'étendue des licences libres

L'étendue de la licence permet de déterminer contractuellement dans quelle mesure certaines créations lui seront rattachées (comme le sont les œuvres dérivées ou composites du régime légal) et, dès lors, si elles sont combinées, subir les contraintes de la licence lors du déclenchement<fnref n="2" /> de cette dernière. En cas de situation floue, imprécise ou ambiguë, le juge recherchera la volonté des parties au moment de leur consentement au contrat. Pour cette raison, tout élément accompagnant la diffusion sous licence libre est bienvenu (FAQ, notice, etc.).

Ainsi, deux techniques peuvent être utilisées conjointement aux fins de détermination des créations soumises à l'étendue de la licence : un renvoi aux qualifications légales des œuvres dérivées<fnref n="3" /> et composites<fnref n="4" /> ou l'utilisation des contrats pour compléter ces dernières<fnref n="5" /> ou s'y substituer<fnref n="6" />

<footnote>license) is without [a particular author's] permission. [...] Thus, Best Buy's failure to comply with the license has terminated any right it may have to make any copies or distributions of BusyBox and its ongoing distribution of BusyBox therefore infringes Andersen's copyright regardless of whether the distributions today are in compliance with the Open Source license. »</footnote>

<footnote n="1">1. http://www.fsf.org/news/android-termination-upgrade-gplv3.</footnote>

<footnote n="2">2. Cf. infra.</footnote>

<footnote n="3">3. Voir pour ceci l'exemple de la licence Ms-CL.</footnote>

<footnote n="4">4. Toutes les législations n'ont pas nécessairement cette distinction entre œuvres dérivées et œuvres composites. Ainsi, la Belgique fait entrer les deux notions sous la définition d'oeuvre dérivée.</footnote>

<footnote n="5">5. Par exemple la licence OSL qui rajoute aux termes légaux celui d'external deployment.</footnote>

<footnote n="6">6. Les exemples sont nombreux, dont celui de la MPL, instituant un copyleft limité aux fichiers.</footnote>
(par exemple en stipulant que seules les œuvres dérivées sont soumises à l'application de la même licence).

Cette étendue peut être unique et imposer que l'ensemble des obligations soient respectées dans ses limites (induisant par exemple qu'un composant logiciel non séparé et indépendant soit soumis à la même licence <fnref n="1" />) ou être multiple et distinguer en fonction des droits de propriété intellectuelle en question (la cession en matière de brevets pouvant par exemple être moins étendue que la cession en matière de droit d'auteur). Enfin, l'impact est différent selon les obligations de la licence et il est fréquent que l'étendue de la licence soit modérée ou, au contraire, maximisée, eu égard à certaines clauses (telle la clause copyleft).

Différents types d'étendues peuvent être identifiées (2.3.2.1), mais leur appréciation demande quelques précisions complémentaires dans le cadre d'œuvres logicielles (2.3.2.2).

### 2.3.2.1 Les différents types d'étendue

On distingue généralement trois types d'étendue (étendue faible, standard et forte), mais il est possible d'en caractériser quatre :

- l'étendue *restreinte* : seule la création originaire reste soumise aux obligations de la licence, tout ce qui est apporté à cette dernière peut être diffusé sous d'autres termes (on la retrouve généralement dans les licences dites permissives);

- l'étendue *faible* : la création originale et les modifications qui lui sont faites sont soumises à cette étendue, mais elle peut se combiner avec d'autres créations sous d'autres licences ;

- l'étendue *standard* (ou *légale*) : l'appréciation de l'étendue conformément au droit applicable, permettant généralement diverses limitations entre plusieurs composants ;

- l'étendue *forte* : la création originale, ses modifications et toute autre création qui serait dépendante (donc liée) seraient soumises à cette étendue.

<footnote n="1">1. Toujours le cas de la GNU GPL, voir *infra*.</footnote>
### 2.3.2.1.a L'étendue restreinte

Cette étendue ne concerne en pratique que les licences permissives : seule la version diffusée par l'auteur initial restera soumise à la licence d'origine, tandis que toute modification sera potentiellement, pour les éléments apportés, sous une autre licence.

Plusieurs créations dotées d'une même étendue restreinte ne seront jamais susceptibles de générer des situations d'incompatibilité. Cependant, toutes ces licences imposent néanmoins de respecter les obligations qui les caractérisent, ce qui peut générer des incompatibilités lorsqu'on souhaite utiliser simultanément une autre licence (en présence de licences ayant une plus large étendue ou lorsqu'on souhaite associer une seule licence pour distribuer le tout).

### 2.3.2.1.b L'étendue faible

L'étendue est dite faible lorsqu'elle ne couvre qu'une partie de l'étendue des droits classiquement reconnus aux titulaires de droits (droits d'auteur notamment). Il s'agit généralement des licences qui vont estimer que toute œuvre dérivée sera soumise à la licence d'origine, alors qu'une œuvre composite pourra être soumise à d'autres licences tant que la licence d'origine est respectée à l'égard de l'œuvre d'origine (intouchée ou dérivée).

### 2.3.2.1.c L'étendue standard

Cette étendue désigne les licences dont il fut décidé de ne pas définir contractuellement l'étendue, laissant libre cours à l'interprétation de la législation applicable — cette législation étant déterminée par contrat ou, à défaut, en application des règles de droit international privé. Une telle étendue à l'avantage d'être éprouvée (appliquée systématiquement en cas de contentieux, la jurisprudence sur le sujet est large) et l'inconvénient d'être parfois moins adaptée à l'objet de la licence.

La licence Eclipse fait ainsi référence à la définition américaine de l'œuvre dérivée, sans se prononcer sur l'étendue de celle-ci<fnref n="1" /> alors que l'EUPL précise que l'interprétation de la notion d'œuvre dérivée dépendra de la

<footnote n="1">1. Voir notamment la FAQ juridique : « Some open source software communities specify what they mean by a "derivative work". Does the Eclipse Foundation have a position on this ? » (http://www.eclipse.org/legal/epifaq.php).</footnote>
loi applicable au contrat (celle-ci étant fixée comme étant « la loi de l'État membre de l'Union européenne où le donneur de licence réside ou a établi son siège social<fnref n="1" /> » ou, à défaut la loi Belge). Enfin, l'Open Software License ne définit pas la notion d'œuvre dérivée (*derivative work*), laissant aux juges le soin d'en interpréter la portée.

### 2.3.2.1.d L'étendue forte

L'étendue forte caractérise des licences qui développent une conception contractuelle extensive de l'œuvre dérivée, entraînant un nombre plus important d'œuvres dépendantes de l'œuvre initiale.

Il s'agit d'une potentielle expansion des droits de propriété intellectuelle qui s'explique par la volonté d'empêcher globalement toute atteinte liée à la jouissance de l'œuvre. Ce mécanisme repose en effet sur un droit exclusif, qu'il étend par le biais du contrat : celui qui veut utiliser l'œuvre consent à s'engager de la sorte. Sans porter de jugement de valeur sur ce type de clauses, très courantes, il convient de remarquer qu'elles se basent généralement sur des considérations non juridiques (appréciant le logiciel en tant qu'outil) et peuvent générer quelques difficultés d'interprétation qui sont autant de sources d'insécurité juridique (d'autant que les parties peuvent avoir une interprétation différente de celle du rédacteur de la licence).

Cette étendue constitue enfin un paradoxe puisque l'application d'une telle conception par l'industrie traditionnelle pourrait être très néfaste au logiciel libre.

### 2.3.2.2 L'étendue des licences en matière de créations logicielles

Dans le domaine du logiciel, en raison du caractère hybride de son objet à la fois technique et juridique, l'application de la typologie classique nécessite d'être précisée par des notions techniques (2.3.2.2.a) sans qu'elles ne suffisent à appréhender tous les types de relations particulières pouvant exister entre plusieurs composants logiciels (2.3.2.2.b).

<footnote n="1">1. Licence EUPL, version française, « Article 15. Loi applicable ».</footnote>
### 2.3.2.2.a L'application de la typologie classique précisée par des notions techniques

Dans le domaine des licences libres appliquées aux logiciels, on s'aperçoit que l'aspect juridique est accessoire aux considérations techniques qui constituent le véritable enjeu des licences.

Ainsi, la GNU General Public License<fnref n="1" /> raisonne à l'échelle du programme et s'étend au logiciel comme un tout, à l'exception des briques logicielles indépendantes et séparées (sauf si elles-mêmes distribuées comme un tout avec le reste du logiciel). La GNU Lesser General Public License<fnref n="2" /> allège cette dernière en mettant en place un mécanisme autorisant les simples utilisations du logiciel.

Enfin, d'autres licences comme la CeCILL-C ou la Mozilla Public License (MPL) raisonnent à l'échelle du fichier et demandent que tout fichier contenant du code sous l'une de ces licences soit aussi sous cette licence.

Ainsi, en terme d'étendue :

- l'étendue restreinte des licences permissives de types BSD, MIT ou Apache ne posent pas plus de difficulté que des licences classiques : le code d'origine est (et reste) soumis à la licence initiale, mais il est aussi possible de le redistribuer (modifié ou non) sous toute autre licence qui respecte ces obligations (mentions légales, licence de brevets, etc.);

- l'étendue faible caractérise les licences modulaires de type CeCILL-C et la licence MPL qui limitent le copyleft aux seuls fichiers contenant du code sous licence<fnref n="3" /> (chaque fichier demeurant ainsi sous une seule licence), de type GNU LGPL<fnref n="4" /> qui permet certaines utilisations (le copyleft envisage toujours l'œuvre comme un tout<fnref n="5" /> et

<footnote n="1">1. Principale licence open source, dont la première version a été publiée en 1989 par la Free Software Foundation. La troisième et dernière version, corédigée par la Free Software Foundation et le Software Freedom Law Center, date du 29 juin 2007.</footnote>

<footnote n="2">2. Petite sœur de la première, la GNU GPL est une « version amoindrie » de la GNU GPL. La première version date de 1991 et la troisième version a été publiée le 29 juin 2007.</footnote>

<footnote n="3">3. Mozilla Public License, Article 1.9 : « 1. Any addition to or deletion from the contents of a file containing Original Code or previous Modifications. 2. Any new file that contains any part of the Original Code or previous Modifications. »</footnote>

<footnote n="4">4. Article 5 de la GNU GPL v 2.1 : « A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. »</footnote>

<footnote n="5">5. Article 2 de la GNU GPL v 2.1, identique à celui de la GNU GPL.</footnote>
toute œuvre dérivée doit être distribuée sous la même licence alors que l'œuvre composite est autorisée, que le lien soit statique ou dynamique, tant qu'il n'y a qu'utilisation du logiciel) ou de type EPL qui permet certaines liaisons ;

- l'étendue standard pose plus de difficulté dans son interprétation, notamment quant à savoir si l'appréciation légale de l'œuvre dérivée couvre, ou non, les liens dynamiques. Par exemple, l'avocat américain rédacteur de l'OSL, Lawrence Rosen, considère qu'un simple lien entre plusieurs logiciels ne peut en faire des œuvres dérivées en application de la loi américaine <fnref n="1" />.

L'étendue forte qualifiera les licences :

- de type GNU GPL 2 qui, en se basant essentiellement sur une efficience technique de leur étendue, étende la licence au logiciel comme « un tout » <fnref n="3" />, dans sa globalité <fnref n="4" />, tel qu'il apparaît à l'utilisateur. Sont ainsi concernées les œuvres basées sur l'œuvre sous licence GNU GPL 5 et les œuvres parties d'un ensemble plus grand contenant

<footnote n="1">1. « In most cases we shouldn't care how the linkage between separate programs was technically done, unless that fact helps to determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle marketbased factors as indicators of intent, such as whether the resulting program is being sold as an "improved" or "enhanced" version of the original , or whether the original was designed and advertised to be improvable "like a library" », Lawrence E. Rosen, *Derivative Works*, p. 2. (http://www.rosenlaw.com/html/GL18.pdf).</footnote>

<footnote n="2">2. Celle-ci dans sa FAQ rend une solution assez large : « What constitutes combining two parts into one program ? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program » (http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html).</footnote>

<footnote n="3">3. Repris dans le projet de licence GNU GPL v. 3, dans son article 5.[2] « Distributing Modified Source Versions ».</footnote>

<footnote n="4">4. C'est ici une traduction que nous proposons de *the whole*, nous pourrions tout autant parler d'ensemble.</footnote>

<footnote n="5">5. Article 2, alinéa 1 de la GNU GPL : « You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and</footnote>
l'œuvre sous GNU GPL ¹. Ainsi, une œuvre considérée comme indépendante et séparée ne sera pas soumise à la licence tant qu'elle restera distribuée comme une œuvre distincte (différenciant l'œuvre indépendante et séparée, distribuée séparément dans une visée autre que d'être utilisée en combinaison avec le logiciel licencié, et la même œuvre distribuée cette fois-ci de façon à être combinée avec le logiciel licencié) ². Afin d'éviter des situations trop extrêmes où l'é tendue de la licence engloberait le système d'exploitation ou des éléments de ce dernier (les logiciels réutilisent en effet, pour leur quasi- totalité, des bibliothèques systèmes spécifiques à un environnement), la GNU GPL comporte une exception dédiée ³;

- de type de la licence CeCILL qui différencie les « modules internes » ⁴ (soumis à la licence) des « modules externes » ⁵ (non soumis) sur le fondement de l'espace d'adressage commun. Un module est interne s'il s'exécute dans le même espace d'adressage que le logiciel licencié et externe s'il s'exécute dans un autre espace d'adress-

distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions. »

1. Article 2, alinéa 2 de la GNU GPL : « These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. »

2. Article 5 du projet de GNU GPL v. 3 : « These requirements apply to the modified work as a whole. If identifiable sections of that work, added by you, are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works for use not in combination with the Program. But when you distribute the same sections for use in combination with covered works, no matter in what form such combination occurs, the whole of the combination must be licensed under this License, whose permissions for other licensees extend to the entire whole, and thus to every part of the whole. »

3. GNU GPL, Article 3 al. 2 : « However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. »

4. Article 1 : « Module Interne : désigne tout Module lié au Logiciel de telle sorte qu'ils s'exécutent dans le même espace d'adressage. »

5. Article 1 : « Module Externe : désigne tout Module, non dérivé du Logiciel, tel que ce Module et le Logiciel s'exécutent dans des espaces d'adressages différents, l'un appelant l'autre au moment de leur exécution. »
sage (et est appelé lors de l'exécution du logiciel). Plus objective que la définition précédente, cette notion simplifie la détermination de l'œuvre dérivée.

On notera enfin que le rassemblement d'œuvres logicielles distinctes (*mere aggregation*) au sein d'une compilation (dans le cadre d'un CD, d'une distribution GNU/Linux ou d'une Framakey) est néanmoins per-mise dès lors que chaque composant reste soumis à sa propre licence. Néanmoins, il est aussi possible d'apposer une licence sur la composi-tion elle-même, le droit d'auteur protégeant une telle compilation dès lors qu'elle est originale et reflète la personnalité de son auteur<fnref n="1" />.

<figure><img src="image_41.png" /><figcaption>FIGURE 2.1 - Représentation des licences (A,B,C,D composants du programme d'origine, X,Y composants d'un autre).</figcaption></figure>

<footnote n="1">1. Art. L112-3 CPI : « Un travail de compilation d'information peut accéder à la protection du droit d'auteur, mais la protection n'est pas acquise en soi par le genre, les juges du fond doivent préciser en quoi la forme retenue est originale ». Civ. 1ère, 2 mai 1989 : JCP 1990. II. 21392, note Lucas et « Un travail de rassemblement, de collection et de sélection de photographies historiques relatives à des personnages politiques de certains pays peut accéder à la protection par le droit d'auteur ». TGI Paris, 29 Janvier 1986 : RIDA, oct. 1986, p. 152.</footnote>
### 2.3.2.2.b L'appréciation de l'étendue au sein des relations particulières susceptibles de rattacher plusieurs composants logiciels

Les logiciels sont, dans des degrés différents, plus ou moins autonomes ou dépendants d'autres logiciels. Ainsi, de multiples relations peuvent exister entre différents logiciels, aux effets variables.

* Le cas des œuvres produites par un logiciel sous licence copyleft

Il est souvent demandé si l'œuvre issue d'un logiciel peut être qualifiée d'œuvre dérivée, ou basée sur celui-ci. La réponse est heureusement négative par principe : l'œuvre est produite par la fonction programme, exérieure à la forme de celui-ci. Un bémol persiste cependant, puisque certains programmes incluent une partie de leur code dans les œuvres qu'ils génèrent<fnref n="1" />. Celles-ci peuvent donc valablement être qualifiées d'œuvres dérivées et soumises en ce nom à la licence copyleft. La situation doit être nuancée en ce que ce type de logiciels prévoient fréquemment une exception dans leur licence permettant à l'utilisateur de disposer « librement » de sa création. Néanmoins, d'autres utilisent ce copyleft « déloyal » afin de rendre attractive une licence commerciale par ailleurs proposée. Par exemple, lors d'une compilation par EiffelStudio, les binaires contiennent du code<fnref n="2" /> soumis à la GNU GPL et doivent alors se conformer à la licence, situation paradoxale où les binaires sont soumis à la licence pour un simple runtime en GNU GPL, alors que les fichiers sources seuls ne le seraient pas (car ne contenant pas lesdits fichiers).

* La liaison entre une bibliothèque et un autre logiciel

Les bibliothèques logicielles se distinguent des logiciels programmes en ce qu'elles sont utilisées par ces derniers pour leur fournir un code assistant. Plus généralement on peut classer dans cette catégorie tout logiciel qui n'aurait pas vocation à s'exécuter par lui-même, mais à être utilisé par un autre. Si, dans le cas d'une liaison statique, la qualification d'« œuvre dérivée »<fnref n="3" /> ne fait pas de doute<fnref n="4" />, la liaison dynamique ne doit pas recevoir

<footnote n="1">1. On peut penser notamment aux éditeurs ou aux compilateurs, comme Bison ou le Gnu Compiler Collection (GCC).</footnote>

<footnote n="2">2. En l'occurrence, le support d'exécution.</footnote>

<footnote n="3">3. En l'occurrence, composite.</footnote>

<footnote n="4">4. En ce qui concerne la GNU GPL, l'intention de créer un seul programme est ici manifeste.</footnote>
de réponse différente puisque ce choix technique est transparent pour l’utilisateur final (que le logiciel soit complété lors de la compilation ou au moment de son utilisation).

→ *Le cas des plug-ins et drivers de périphériques*

Il semble qu’il faille ici transposer la démarche précédente puisqu’il s’agira le plus souvent<fnref n="1" /> d’une liaison dynamique entre le plug-in et le logiciel. Les drivers sous GNU GPL posent des questions plus simples puisque, lorsqu’ils communiquent avec des systèmes d’exploitation, ceux-ci bénéficient d’une exception expresse qui les dispense de la distribution du tout<fnref n="2" />. À l’opposé, si c’est le système d’exploitation qui est sous GNU GPL, l’effet devrait être contraire : d’où l’interprétation apportée par Linus Torvalds afin de réduire la portée du *copyleft* de son kernel. C’est pourquoi, dans le cas de développement de logiciels *en grappe* — par l’accumulation de plug-ins —, il est conseillé d’utiliser une licence avec un *copyleft* standard, ou de rajouter une exception à un *copyleft* fort. Dans le cas contraire, la GNU GPL n’y verra pour sa part qu’une seule œuvre, l’existence d’un module propre à un logiciel faisant quasi systématiquement supposer une intention de lier les deux en un tout. L’argument de Linus Torvalds qui consiste à prendre uniquement en considération l’intention des parties semble être la meilleure ligne de conduite<fnref n="3" />, même si c’est la plus difficile à mettre en œuvre et si beaucoup de licenciés n’en ont pas conscience. Dans une telle hypothèse, c’est le juge qui tranchera en déduisant l’intention du comportement (dans le cas du noyau Linux, une commande spécifique a été créée à cette fin<fnref n="4" />).

→ *L’héritage et le cas des classes dérivées, mères et filles (Java)*

La programmation avec le langage java organise une notion d’héritage (afin de spécialiser une classe qui possédera non seulement les propriétés et méthodes de son unique mère, mais d’autres méthodes spécifiques ou

<footnote n="1">1. Certaines fonctions sont considérées comme *non contaminantes* : par exemple si le plug-in est invoqué par la fonction *fork* ou *exec*, il est alors un programme séparé. Voir la FAQ GNU GPL.</footnote>

<footnote n="2">2. Article 3 al. 2, déjà cité.</footnote>

<footnote n="3">3. Voir à ce sujet un courriel publié et les exemples qu’il donne (en liaison entre les systèmes Unix et Linux : un module est créé pour se lier dynamiquement avec Unix, est ensuite portée sur Linux sans modification, alors il n’est pas question d’œuvre dérivée) : http://www.atnf.csiro.au/people/rgooch/linux/docs/licensing.txt.</footnote>

<footnote n="4">4. Il existe en effet une commande pour le noyau Linux qui ne peut être utilisée que pour lier des pilotes et modules sous licence GNU GPL ou compatibles, *EXPORT SYMBOL GPL*.</footnote>
redéfinies). Lorsqu'une classe<fnref n="1" /> est sous licence *copyleft*, toute sous-classe est une œuvre dérivée, soumise à l'obligation de réciprocité<fnref n="2" />. La justification découle en réalité des développements précédents puisque l'utilisation de classes parentes (ou surclasses) et de sous-classes n'est qu'une utilisation optimale des liaisons entre programmes : par défaut, toutes les classes dérivées héritent de toutes les méthodes et propriétés de ces super classes<fnref n="3" />. On assiste ici à une ramification où chaque nouvelle sous-classe ajoute de nouvelles fonctionnalités au tronc commun<fnref n="4" />.

### 2.3.3 L'élément déclencheur des licences libres

L'élément déclencheur est l'action par laquelle le logiciel sort de la « sphère privée » de son utilisateur : en présence de nouveaux utilisateurs, il est nécessaire que ceux-ci disposent des droits que leur confère la licence (le premier n'étant par ailleurs plus un « simple » utilisateur). Ce critère est extrêmement important puisque nombre de sociétés y ont adapté leur modèle économique de manière à bénéficier de logiciels libres avec le minimum de contraintes ou pour proposer à leurs utilisateurs une licence commerciale lorsque la licence libre prend ses pleins effets<fnref n="5" />.

Les éléments déclencheurs les plus fréquents sont : la distribution (2.3.3.1), l'utilisation (2.3.3.2) et le déploiement externe (2.3.3.3).

#### 2.3.3.1 La distribution

À l'origine seul et unique critère, la notion de distribution fut utilisée dès la première GNU GPL et reprise dans toute la génération de licences qui s'en inspirèrent. Ainsi, celui qui modifie une création peut l'exploiter sans

<footnote n="1">1. Concept de base de la programmation orientée objet, la classe déclare des attributs représentant l'état des objets et des méthodes représentant leur comportement.</footnote>

<footnote n="2">2. La FAQ GPL le stipule clairement.</footnote>

<footnote n="3">3. Un exemple de hiérarchie pour une *applet* java : java.lang.Object > java.awt Component > java.awt Container > java.awtPaneld > java.applet.Applet.</footnote>

<footnote n="4">4. Elle peut aussi permettre de redéfinir des membres hérités, à l'aide de la surcharge des méthodes, d'une réaffectation des variables ou du mot clé *super*.</footnote>

<footnote n="5">5. Cette situation est néanmoins intenable à moyen terme : chaque développement spé-cifique devant ensuite être maintenu et ajusté aux nouvelles versions du projet communau-taire, l'investissement devient très rapidement intenable. Ainsi, Google a finalement reversé de nombreuses améliorations apportées au noyau Linux, alors même qu'elle n'y était pas contrainte en l'absence de distribution.</footnote>
restriction jusqu'à ce qu'il décide de la distribuer. Dès lors qu'il y a distribution, il lui faut veiller à avoir bien respecté l'ensemble des contraintes des licences (maintien — voire extension — des licences, apposition des mentions obligatoires, etc.) <fnref n="1" />.

On considère classiquement que la distribution s'entend de la diffusion ou communication à un tiers d'une copie du logiciel. Néanmoins, il existe différentes acceptations selon que l'on fait référence au droit américain, français ou européen. La notion américaine de *distribution s'apparente à celle de mise sur le marché européenne*, tandis que cette dernière induit le *transfert d'une copie* <fnref n="2" />. C'est pour pallier aux difficultés d'interprétation liées à la localisation du litige, des auteurs, etc. que la dernière version de la GNU GPL redéfinit les notions fondamentales de la licence (en l'occurrence au travers des termes *convey* et *propagage*). Il est maintenant entendu que cet élément déclencheur n'appréhende pas l'usage ou l'offre de services d'un logiciel par le réseau, ces derniers pouvant être réalisés sans contraintes particulières.

Enfin, certains langages (notamment Ajax, Javascript, Flash, etc.) s'exécutent directement dans le navigateur web de l'utilisateur et sont donc automatiquement distribués (mais pas nécessairement les parties restantes du logiciel installées sur le serveur et qui communiquent via le réseau).

<figure><img src="image_42.png" /></figure>

## LES ACCORDS DE NON-DIVULGATION

Les licences peuvent parfaitement se conjuguer avec d'autres dispositifs contractuels. Par exemple, l'auteur d'une contribution peut s'engager à ne pas publier ses modifications, ou à ne les proposer qu'à son client. La situation est courante et ne pose pas de problème tant que la licence est respectée.

En effet, ce n'est ici que la mise à disposition qui est altérée, et non la licence : dans le premier cas, s'il n'y

<footnote n="1">1. En conséquence de quoi la simple utilisation d'une création logicielle en tant que service (SaaS) n'est pas une distribution selon la GNU GPL (en l'absence de transfert de copie).</footnote>

<footnote n="2">2. SIEDLECKA-VAN RUMST (A.), « Validity Issues of Open Source Licenses in European Union — The EU's solution », dans *Mazaryk University Journal of Law and Technology*, n°2, 2008, p. 63-73 (http://mujlt.law.muni.cz/), et VÄLIMÄKI (M.), « GNU General Public License and the Distribution of Derivative Works » (http://www.valimaki.com/org/gpl_valimaki_updated.pdf).</footnote>
a pas de distribution, l'auteur n'a pas à subir les effets
contraignants de la licence (par exemple mise sous une li-
cence identique), tandis que dans le second cas, l'auteur
doit respecter la licence, et donc éventuellement livrer le
logiciel sous licence libre — dans cette hypothèse, à un
client unique. Ce client sera alors le seul à bénéficier du
contrat (licence libre ou commerciale) et il pourra inter-
dire toute autre réutilisation à son prestataire. L'inverse
n'est pas vrai, et un licencié qui chercherait à limiter con-
tractuellement les droits de son partenaire en opposition
avec les libertés assignées par la licence serait en infrac-
tion avec cette dernière.

Pour aller plus loin...

Sur le fondement de la distribution, voir l'assignation de Free de-
vant le TGI de Paris : Assignation Welte, Andersen, Landley v. Free
(http://fsffrance.org/news/assignation-free.pdf).

2.3.3.2 L'utilisation

En réaction aux usages développés sans distribution (notamment l'util-
isation des logiciels en SaaS, c'est-à-dire comme un service — Software
as a Service) certains souhaitèrent régler la question du déclenchement en
fixant ce dernier très bas.

Ainsi, quelques licences réduisent la sphère privée de sorte que leurs
obligations s'appliquent très tôt : la Repricocal Public License fixe le seuil
à toute utilisation autre que pour sa recherche interne et/ou utilisation per-
sonnelle <fnref n="1" />.

Le palliatif était néanmoins non suffisant et d'autres éléments dé-
clencheurs apparurent, plus adaptés aux actions que les auteurs en-
tendaient interdire.

<footnote n="1">1. « other than for Your internal Research and/or Personal Use », Art. 1.2 de la Recipro-
cal Public License v. 1.5.</footnote>
### 2.3.3.3 Le déploiement externe

Enfin, la dernière génération de licences a multiplié les recours à un nou-
vel élément déclencheur inspiré de l'évolution d'Internet : l'Open Soft-
ware License<fnref n="1" /> ou la GNU Affero GPL<fnref n="2" /> imposent ainsi le respect de leurs
obligations dès lors que le logiciel peut être utilisé ou qu'il interagit avec
des tiers, directement ou indirectement<fnref n="3" />. Ces licences viennent combler
l'ASP Loophole (faille des logiciels libres utilisés en SaaS) en faisant en
sorte que le licencié qui utilise un logiciel pour fournir un service à des
utilisateurs via le réseau ne puisse le faire sans avoir l'obligation de redis-
tribuer les modifications qu'il aurait lui-même apportées à ce dernier.

Lors de leur mise à jour, certaines licences troquèrent, ou ajoutèrent, cet élément déclencheur au précédent (pour les plus récentes : l'EUPL v. 1.1 ou la MPL 2.0).

<figure><img src="image_43.png" /></figure>

#### BON À SAVOIR

La troisième version de la GNU GPL devait elle-même intégrer une telle modification (encore prévue à l'article 7b.4 de son second brouillon), mais l'idée fut finalement retirée sous la pression extérieure. Un choix contesté, certains n'hésitant pas à dire que la « GPL est la nouvelle BSD⁴ », voire à lui affubler l'appellation de « SHING GPL » (en référence à Sun HP IBM Nokia Google, principaux détracteurs et lobbyistes qui s'opposèrent à cette clause).

Néanmoins, la solution alternative mise en place s'avère tout aussi bonne : les deux licences peuvent cohabiter, étant expressément compatibles entre elles, mais, alors que chaque partie reste sous sa propre licence, l'élément déclencheur de la GNU Affero GPL s'étend au logiciel comme un tout... Les rédacteurs des licences ont ainsi introduit *un copyleft dans le copyleft* et il y a fort à parier

<footnote n="1">1. Elle emploie le terme d'*external deployment* pour appréhender l'usage par le réseau.</footnote>

<footnote n="2">2. Reprise en main par la FSF, la nouvelle GNU Affero version 3.0 a été publiée le 19 novembre 2007.</footnote>

<footnote n="3">3. Les licences de seconde génération assurent les libertés à l'égard de tout détenteur *et* de tout utilisateur des fonctionnalités du logiciel.</footnote>
que cette conception sera le standard dans quelques années, quelles qu'en soient les critiques.

Voir à ce propos : JEAN (Benjamin), « Sortie de la version 3 de la GNU General Public License », 2008 (sur http://blog.vvlibri.org).

### 2.3.4 La compatibilité au sein des licences libres

Notion particulièrement importante dans le domaine des licences libres, l'incompatibilité caractérise la situation ou deux licences imposent des obligations contradictoires dans l'usage des créations concernées (par exemple deux licences *copyleft* qui imposent que le logiciel global soit difusé sous une seule d'entre elles)<fnref n="1" />. Cette situation, inconnue dans le domaine traditionnel *propriétaire* qui, par principe, s'oppose à l'évolution de l'œuvre, n'est en réalité que la rançon de la gloire. De nouveaux usages se créant il peut sembler logique qu'ils entraînent aussi certaines exigences de réflexions de la part des utilisateurs — faible tribu donc, compte tenu de ce qui leur est offert...

Les licences n'étant que des contrats, leurs effets sont dits relatifs (limités aux parties du contrat : les auteurs qui cèdent sous licences libres et les utilisateurs) et il n'existe ainsi pas de licences qui seraient dominantes : toutes ont la même force obligatoire et le licencié doit renoncer à exploiter une création lorsqu'il ne peut pas respecter l'ensemble de ses engagements.

Malheureusement, la multiplication des licences accroît cette problématique alors même qu'il n'y a généralement que quelques obligations qui différencient les licences les unes des autres<fnref n="2" />. Par ailleurs, puisqu'il est impossible pour quiconque de décider unilatéralement de l'abandon d'une licence au profit d'une nouvelle :

<footnote n="1">1. Voir à ce sujet JEAN (Benjamin) « Compatibility - Incompatibility », EOLE 2009, Parlement européen, Bruxelles ; ainsi que JEAN (Benjamin), *Option Libre : compatibilité entre contrats*, mémoire sous la direction de Michel Vivant, Montpellier, ERCIM, 2006.</footnote>

<footnote n="2">2. Voir notamment SCHMITZ (Patrice-Emmanuel), « Licence compatibility lists : could they compensate proliferation by developing circles of trust? », EOLE 2010, Parlement européen, Bruxelles.</footnote>
1. chaque nouvelle version de licence peut être considérée comme une nouvelle licence à part entière<fnref n="1" /> ;

2. même si la plupart permettent une compatibilité ascendante au bénéfice des nouvelles versions de la licence, quelques licences autorisent expressément aux auteurs de licences libres et *open source* de figer la licence à une version spécifique<fnref n="2" />. Il y a alors un *copyleft* en deux temps : le premier caractérisant l’étendue de la licence et le second déterminant *la version sur chaque contribution*. Cette situation crée donc une potentielle incompatibilité entre deux versions d’une même licence<fnref n="3" />.

Ainsi, si les licences libres et *open source* tendent à être génériques pour faciliter leur réutilisation, cela n'a malheureusement pas empêché l'apparition de nouvelles licences destinées à répondre à des situations particulières (communautés, domaine, contributeurs types, langage, voire objet de la licence lorsqu'on dépasse la sphère du logiciel). Au final, plus de 1 800 licences sont ainsi recensées dans la seule base de code analysée par la société Black Duck — un chiffre qu'il convient néanmoins de relativiser en raison du socle commun que constituent les licences certifiées par l'Open Source Initiative (voire moins d'une douzaine d'entre elles<fnref n="4" />). En terme d'utilisation des différentes licences, il est possible de se référer au classement (en terme de couverture de code) tenu à jour<fnref n="5" /> par la société Black Duck et à l'étude publiée par OpenLogic<fnref n="6" />. Le premier classement concerne la couverture de code : GNU GPL v. 2 (42.77%), MIT (11.29%), licence Artistic (7.80%), GNU LGPL 2.1 (7.23%), BSD (6.79%), GNU

<footnote n="1">1. Il est en effet toujours possible d'utiliser les anciennes versions des licences — comme c'est souvent le cas pour la GNU GPL v. 2, même si la SFLC et la FSF plaident le change-ment en faveur de la dernière version (Voir : http://www.fsf.org/news/android-termination-upgrade-gplv3).</footnote>

<footnote n="2">2. Si on prend l'exemple de la GNU GPL et du noyau Linux, toutes les contributions de Linus Torvalds sont distribuées sous GNU GPL « version 2 seulement », ainsi, même si d'autres parties autorisent la distribution sous GNU GPL version 3, le noyau Linux ne pourra pas être distribué sous la troisième version de la GNU GPL tant que les composants sous GPL v. 2 n'auront pas été réécrits ou que leur auteur aura consenti à modifier la licence !</footnote>

<footnote n="3">3. C'est cette incompatibilité qui empêche actuellement le noyau Linux de passer sous GNU GPL v. 3 tant qu'il restera des contributions sous GNU GPL v. 2 *only*.</footnote>

<footnote n="4">4. « Fewer than a dozen open source software licenses govern the bulk of all enterprise use of open source », *The Myth of open source License Proliferation*, the451group.com, p. 16.</footnote>

<footnote n="5">5. http://www.blackducksoftware.com/oss/licenses</footnote>

<footnote n="6">6. KERNER (S. M.), « What is the Top Open Source License? », *internetnews.com*, 2011.</footnote>
GPL v. 3 (6.43%) et licence Apache v. 2 (5.41%); le second se focalise
sur les logiciels *open source* les plus importants : la licence Apache passe
en tête (32,7%) devant la GNU LGPL v. 2.1 (21%) et la GNU GPL v. 2
(14,4%)<fnref n="1" />.

La rédaction de nouvelles licences renforce cette problématique (ceci
même si elle prévoit expressément la compatibilité avec d'autres li-
cences <fnref n="2" />) en plus d'être source d'insécurité (par la réintroduction poten-
tielle de failles réglées par d'autres licences <fnref n="3" />, l'incapacité de la faire
évoluer, etc.). Il est donc généralement plus simple (juridiquement, tech-
niquement et en terme de communication) d'utiliser une licence connue
que l'on modifie par le biais d'une exception, dans le but de préciser des
clauses floues ou pour ajouter des droits ou obligations <fnref n="4" />.

Pour prendre en compte ce phénomène, les licences ont été revues au
moyen de clauses *actives* qui permettent de licencier l’œuvre lors de sa
redistribution sous une licence différente <fnref n="5" /> et de clauses *passives* qui, en
cas de cumul avec certaines autres licences, limitent ou excluent une partie
de leurs obligations <fnref n="6" /> pour se rendre compatibles. Avec la croissance de
l’usage de l’*open source*, la maîtrise de cette notion est devenue cruciale :
ce qui explique que de nouvelles formes de compatibilité (2.4.2.) se soient
ajoutées à celles existantes (2.4.1).

<figure><img src="image_44.png" /></figure>

COMPATIBILITÉ CC BY SA / GNU FDL 1.3 / LAL 1.3

Trois licences *copyleft* sont majoritairement utilisées sur
Internet pour tout ce qui n’est pas logiciel : la GNU FDL,
la Creative Commons By-SA et la Licence Art Libre. Cha-
cune étant d’origine différente, mais avec des caractéris-
tiques semblables, il était pendant très longtemps impossi-

<footnote n="1">1. Le projet Debian a aussi réalisé une étude des licences utilisées par sa distribution : voir http://lists.debian.org/debian-policy/2010/06/msg00099.html.</footnote>

<footnote n="2">2. Paradoxalement, cette concession conduit à se demander s'il est pertinent d'en créer une nouvelle puisque toute la sécurité créée peut disparaître via ce mécanisme de compatibilité.</footnote>

<footnote n="3">3. Ainsi, la première version de l'EUPL ne couvrait pas l'usage en SaaS (l'ASP loop-hole) alors même que tous les logiciels originairement destinataires de cette licence fonctionnaient ainsi.</footnote>

<footnote n="4">4. Cf. infra : « la création ou la sélection d'une ou plusieurs licences. »</footnote>

<footnote n="5">5. Comme il en est de la GNU LGPL ou de la CeCILL à l'égard de la GNU GPL.</footnote>

<footnote n="6">6. Solution adoptée par les licences CeCILL-B et CeCILL-C de la famille CeCILL à l'égard de la licence CeCILL.</footnote>
ble de mélanger du contenu sous une licence avec du contenu sous une autre licence. Cette contrainte a fait réagir leurs rédacteurs respectifs, considérant que « le point important n’est pas les différences, mais au contraire le but commun. »<fnref n="1" />

- Licence Art Libre : en 2007, une nouvelle version de la Licence Art Libre ouvre le chemin de la compatibilité en permettant de re licencier l’œuvre sous toutes licences offrant les mêmes obligations et droits et assurant une compatibilité réciproque (voir l’article 5 « critères de compatibilité ») ;

- Creative Commons By-SA : peu de temps après, en février 2007, la troisième version de la Creative Commons CC By-SA intègre elle aussi une compatibilité pour toute licence aux termes équivalents qui assurerait une réciprocity et qui est approuvée et listée sur le site de Creative Commons (aucune ne l'a été depuis) ;

- GNU FDL : le 3 novembre 2008, dans une version 1.3 de la GNU Free Documentation License (FDL), la FSF a répondu au souhait de Wikipedia de relicencier sous CC By-SA (c'était une bonne chose, le formalisme de la GNU FDL étant trop contraignante pour ce type de contenu — et ainsi rarement respecté). Ceci malgré le profond désaccord de RMS<fnref n="2" />.

### 2.3.4.1 Les différents types de compatibilité

La compatibilité peut ensuite être conditionnée à l'existence de certaines situations d'incompatibilité (2.2.4.1.b) ou discrétionnaire, c'est-à-dire à la seule volonté de la personne qui redistribue la création (2.2.4.1.a).

<footnote n="1">1. Tiré d'un courrier de LESSIG (Lawrence) : « The important point is not the differences but instead the common aim. », disponible sur http://creativecommons.org/weblog/entry/5709.</footnote>

<footnote n="2">2. Voir le billet de LESSIG (Lawrence), « Enormously Important News From the Free Software Foundation », 2008 (sur http://lessig.org/blog).</footnote>
#### 2.3.4.1.a La compatibilité discrétionnaire ou compatibilité non conditionnée

Dans ce type de compatibilité, la licence précise que la création peut indifféremment être redistribuée selon ses propres termes ou selon ceux d'une licence prédéterminée. Le choix est donc offert lors de la redistribution de la création soumise à la licence.

La clause expresse de la GNU GPL v. 2 traduit bien cette première hypothèse puisqu'elle prévoit, en son troisième article <fnref n="1" />, que le licencié peut choisir de lui substituer les termes de la GNU GPL. Dans sa troisième version, le mécanisme est perfectionné puisque la GNU GPL ne devient qu'une « exception » à la GNU GPL (pouvant, à ce titre, être supprimé à tout moment).

#### 2.3.4.1.b La compatibilité conditionnée

On parle de compatibilité conditionnée lorsque le mécanisme est limité aux seules situations d'incompatibilité, c'est-à-dire quand l'ajout d'un composant sous une autre licence *open source* imposerait de redistribuer le tout sous cette unique autre licence.

Technique initialement mise en place par la licence CeCILL (au profit de la GNU GPL), elle fut depuis réutilisée par d'autres licences (notamment l'EUPL qui utilise ce mécanisme au profit de cinq licences : l'OSL v. 2.1 et v. 3.0, la CPL v. 1.0, l'EPL v. 1.0, la CeCILL v. 2.0 et la GNU GPL v. 2.0.).

### 2.3.4.2 Les nouvelles formes de compatibilité

Après avoir été un frein majeur aux échanges entre projets libres durant de longues années, le problème de l'incompatibilité entre licences semble

<footnote n="1">1. GNU GPL, article 3 : « You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. »</footnote>
se résorber progressivement grâce aux licences de nouvelles générations qui intègrent progressivement cette problématique en amont dans leur rédaction (telles la GNU GPL v. 3, l'EUPL v. 1.1 ou la MPL 2).

Néanmoins, les réponses qu'elles apportent sont généralement imparfaites du fait qu'elles reposent sur une hiérarchie entre les licences. Or, il semble improbable que toutes les licences conviennent un jour à un tel système féodal et il serait probablement plus simple que les licences (et leurs rédacteurs) lèvent les situations conflictuelles en se reconnaissant comme égales (ou, pour le moins, alliées) et en ne cherchant plus à s'imposer aux autres ou à les influencer. Par exemple — mais ces réflexions sont encore trop récentes — il pourrait être suggéré que les licences *copyleft* incluent systématiquement en leur sein un mécanisme réduisant l'étendue de la licence lors d'une combinaison avec d'autres composants déjà diffusés sous une licence libre et *open source* (rien ne sert de les rendre « plus libres », surtout compte tenu des problèmes d'incompatibilité) ou que la clause *copyleft* soit « mise en veille » en présence de composants sous certaines autres licences (par ailleurs listées) qui reprendraient néanmoins des obligations semblables.

Enfin, il est souvent préférable, lorsque l'opportunité existe, de résoudre ces situations par des réflexions préalables en terme d'ajout de licences, de multilicences (licences multiples) ou encore d'exceptions hybrides du type « FOSS Exception »<fnref n="1" />.

<figure><img src="image_45.png" /></figure>

## COMPRENDRE LES INTENTIONS DES RÉDACTEURS

Les rédacteurs de licence ont généralement intérêt de s'assurer que leur licence se *substitue* à d'autres licences afin de favoriser son usage (il n'y a pas de réelle substitution, puisque les licences sont intégrées/contenues dans la première — cf. *infra*). Cette compatibilité est au moins recherchée à l'égard des licences permissives (l'absence de compatibilité entre les licences GNU GPL v. 2 et Apache

<footnote n="1">1. L'exception pourrait ainsi limiter l'étendue de la licence dans certains contextes seulement : par exemple, dans le cadre de son utilisation sur la bibliothèque MySQL diffusée sous GNU GPL, l'exception réduit l'étendue de la licence en présence d'une combinaison avec des composants tiers *open source* (ceux-ci, pour autant que leur licence figure dans la liste annexée à cette exception, peuvent ainsi continuer à être régis par cette seule licence).</footnote>
était très critiquée à cet égard), l'exemple le plus représentatif étant la GNU GPL v. 3 qui peut moduler certains de ses termes afin de s'assurer de cette compatibilité (notamment vis-à-vis des licences Apache ou Latex).

Inversement, il peut aussi être dans leur intérêt de reconnaître une licence comme expressément compatible (comme le font les licences CeCILL, EUPL, GNU AGPL, etc.) afin de répondre à une demande et de supprimer une partie des difficultés nées de situations d'incompatibilité : soit par souci de légitimité (la situation la plus courante concerne la GNU GPL) ; soit, dans une vision plus altruiste, pour assurer une plus large diffusion des développements réalisés (la licence est rédigée pour un projet ou une structure particulière, mais on cherche simultanément à faire profiter une large communauté de ces développements : c'est notamment le cas de la licence EUPL).

Ainsi, les intérêts entre rédacteurs de licences et simples utilisateurs de licences sont différents et il est généralement conseillé pour un utilisateur de contourner (par des techniques contractuelles) les situations d'incompatibilité plutôt que de revêtir la casquette de rédacteur d'une licence open source. Cela fait partie des nombreux réflexes relatifs à l'usage des licences libres (chapitre suivant).
# CHAPITRE 3

## Les bons réflexes

L'innovation, la création ou le développement reposent aujourd'hui, plus que jamais, sur une très large réutilisation des travaux de tiers. Dès lors, la question n'est plus de savoir qui détient les droits de propriété intellectuelle, mais simplement comment pouvoir les exercer ! Cette situation — une concentration de titulaires de droits exclusifs réunis pour l'exploitation d'une seule création — amplifie l'importance d'une bonne maîtrise tant des enjeux de propriété intellectuelle que des licences libres.

Chaque nouveau projet se traduit par une multitude de relations contractuelles destinées à favoriser et sécuriser les collaborations composées d'une part croissante de contrats types fixant à priori et de façon *intangible* les conditions d'utilisation. À cet égard et puisqu'elles opèrent une cession de droits d'exploitation très large facilitant la réutilisation de leurs créations (au bénéfice seulement de ceux qui respectent le cadre qu'elles ont fixé), les licences libres et *open source* constituent une réponse optimum à cette recherche d'une innovation rapide et efficace. La liberté offerte est néanmoins conditionnée au respect de certaines conditions et obligations qui nécessitent une vigilance particulière (avec comme
sanction l'action en contrefaçon). Ainsi, cette logique de mutualisation, génératrice d'importantes économies pour l'industrie, nécessite la mise en place d'une gestion spécifique, et notamment juridique, destinée à garantir le respect de l'ensemble des licences. Innover dans ce cadre juridique ouvert impose donc :

- de gérer l'extension des effets des licences sur d'autres composants : c'est la question de l'ajout d'une licence et des situations d'incompatibilité ;

- de veiller au respect du formalisme imposé par les différentes licences (transmission du code source, mention de paternité, différenciation des modifications, etc.). Celui-ci est notamment destiné à assurer la maîtrise effective du code, essentielle dans les projets open source (code source, documents préparatoires, scripts, etc.).

Ces deux composantes doivent imprégner l'élaboration de bonnes pratiques au sein des projets, voire de politiques open source formalisées au sein des sociétés concernées.

Ce dernier chapitre est celui le plus orienté « pratique » de l'ouvrage, répondant à la question « comment, concrètement, doit-on utiliser les licences libres ». Pour commencer, il convient d'admettre qu'il est encore habituel que les enjeux relatifs aux licences libres ne soient appréhendés que trop tardivement, par exemple lorsque la distribution de la création est d'ores et déjà programmée, ce qui abouti à des situations de concession peu satisfaisantes tant pour l'équipe juridique que technique. Une réflexion en amont doit donc être systématiquement préférée, car même si chaque licence obéit à un mécanisme qui lui est propre, il est néanmoins possible de donner un certain nombre de recommandations quant à la mise sous licence libre (3.1) et la diffusion sous licence libre (3.2).

## 3.1 Les réflexes préalables à la diffusion

Les projets doivent veiller à respecter l'ensemble des licences attachées aux composants qu'ils utilisent, notamment vis-à-vis du cadre juridique qu'elles imposent et ses conséquences quant au choix et l'ajout d'une licence (3.1.1) et du formalisme qui leur est attaché (3.1.2).
### 3.1.1 Apprécier le cadre juridique induit par les licences libres

Une bonne connaissance des licences est la condition nécessaire à l'appréhension du cadre juridique qu'elles induisent. Cette appréhension permet alors de prendre toute mesure liée aux contraintes issues des choix des composants. C'est en agissant avec méthode que l'on choisit la licence (3.1.1.1) et que l'on s'assure du respect des conditions nécessaires à l'ajout d'une licence libre (3.1.1.2).

#### 3.1.1.1 Méthode relative à la sélection de la licence initiale

Le choix initial de la licence est fondamental : en termes de marketing afin d'interpeller des communautés déjà existantes ; en termes stratégiques, car le modèle économique développé autour du logiciel peut en dépendre ; et enfin en termes juridiques puisque l'ouverture du projet peut engendrer l'arrivée de contributions pour lesquelles le titulaire initial ne pourra pas unilatéralement changer de licence. Une licence adaptée au logiciel et aux attentes de la société facilitera la structuration de la collaboration future, cette dernière n'étant alors concentrée que sur l'optimisation et la mutualisation dans le développement et l'exploitation du logiciel (les licences assurent, elles, les cessions de droits de propriété intellectuelle nécessaires). Le choix de la licence peut aussi avoir pour objectif d'ouvrir ou de fermer des pistes de collaboration avec des sociétés concurrentes : on parle alors de coopétition, pour traduire l'idée d'une coopération entre des entreprises potentiellement concurrentes qui gagnent toutes au développement du Libre.

Plusieurs démarches doivent être décrites : la création d'une nouvelle licence (3.1.1.1.a), ou le choix d'une ou plusieurs licence(s) existante(s), éventuellement adaptée(s) au logiciel (3.1.1.1.b).

#### 3.1.1.1.a La création d'une licence particulière

S'épargnant tout choix, il peut être tentant de s'orienter vers la rédaction d'une licence spécifique, particulièrement lorsque les projets et structures impliquées sont importants.

Néanmoins, avant de se lancer dans cet exercice, il est nécessaire de mesurer l'intérêt et les inconvénients de cette solution, généralement motivée par une volonté de créer un pot commun « encadré » ou de créer une
licence « mieux adaptée » aux besoins. En effet, ces préoccupations em-
portent aussi un certain nombre de désavantages qu’il peut être préférable
d’éviter.

S’il s’agit de sectoriser afin de ne pas risquer la récupération par un
projet ou une entreprise concurrents, l’effet n’est pas garanti (compte tenu
des libertés conférées par la licence) et les inconvénients sont non néglige-
ables : la manne de composants *open source* tiers devient indisponible (en
effet, plus la licence est spécifique et plus la compatibilité sera difficile à
atteindre) et il sera alors plus difficile d’intéresser les tiers aux projets (et il
n’est pas possible d’ajouter une compatibilité en faveur d’autres licences
sans entrer en contradiction avec cet objectif de réservation — mieux vaut
revoir complètement sa position que d’aboutir à la situation hybride qui
consisterait à ajouter *in extremis* une telle compatibilité).

S’il s’agit, de manière tout à fait légitime, d’une volonté de créer une
nouvelle licence optimisée pour la création (et son auteur), cet effort peut
aussi s’avérer contre-productif : il fait courir le risque que la licence con-
tienne des failles non existantes (ou résolues) dans d’autres licences, et
demande, outre sa rédaction, la mise en œuvre d’un travail de commu-
nication, d’interprétation et d’assistance dans la compréhension de cette
licence, ce qui est, une nouvelle fois, une activité coûteuse en temps et en
énergie<fnref n="1" />. En effet, la rédaction d’une licence est un projet ambitieux. Il
n’est pas rare que les nouvelles versions de licences prennent un ou deux
ans avant d’être terminées. Un tel projet fait appel à des compétences par-
ticulières. Il est ainsi généralement plus sûr d’utiliser une licence large-
ment répandue chez des grands groupes tels IBM, HP, Microsoft, Sun,
Oracle, Google, etc.. Le seul aspect positif est la potentielle compatibilité
avec la licence utilisée comme canevas, avantage bien faible compte tenu
des autres solutions assurant une même compatibilité.

Ainsi, la rédaction d'une nouvelle licence *open source*, si elle peut dans
certains cas (limités) se justifier, ne doit pas être une solution « par dé-
faut », mais au contraire le fruit d'une réflexion globale qui ne peut faire
l'économie d'une sélection en amont d'une ou plusieurs licences « mod-

<footnote n="1">1. C'est d'ailleurs ce constat qui explique en partie l'insécès des licences CeCILL : alors que l'initiative était réellement novatrice, il n'y avait qu'une seule personne qui s'occupait — parmi bien d'autres tâches — de la mise à jour du site, de la FAQ, des relations avec les différentes instances de l'écosystème (OSI, FSF, etc.).</footnote>
Èles ». Elle devra par ailleurs être le fruit de professionnels, aptes à intégrer les contraintes de sécurité juridique face à l'écosystème existant du Libre et de l'open source.

L'aspect politique pouvant, à lui seul, être la justification d'un tel choix, il est alors nécessaire de rappeler les éléments qui précèdent afin que les risques soient clairement identifiés (un mauvais choix en la matière pourra annuler l'intégralité des avantages qu'apporterait l'ouverture du projet).

### 3.1.1.1.b Le choix d'une licence adaptée

Plutôt que de « réinventer la roue », il est généralement conseillé d'utiliser une ou plusieurs licences existantes.

→ *Le choix d'une licence*

Le choix d'une licence est une juste combinaison de stratégie et de tactique.

En termes *stratégiques*, le choix de la licence doit traduire les intérêts juridiques, techniques et commerciaux du projet (voire de la société). Par ailleurs, il doit intégrer les contraintes issues de la réutilisation de créations tierces, sous licence *open source* ou non.

Il est nécessaire d'adopter la licence la plus adaptée à son projet en se concentrant sur ses obligations, son étendue, son élément déclencheur et éventuellement la compatibilité qu'elle organise. Il convient donc, dans un premier temps, de réaliser un « cahier des charges des besoins » et de dresser un inventaire des licences qui répondent, en totalité ou en partie, aux attentes. Dans un second temps, il peut être utile d'estimer l'intérêt des licences au regard du contexte : est-ce important d'utiliser une licence largement connue et testée ? Doit-on s'inspirer des choix opérés par des projets concurrents analogues ? Ces réponses ne peuvent être données qu'au cas par cas, en fonction de l'examen et de l'approche choisie. Incontestablement, une licence disposant d'une large notoriété participe avantageusement à la communication qui suivra la libération de la création. En revanche, le choix d'une licence similaire à un projet concurrent est un pari dont il faut bien mesurer les aléas : les contributions pouvant librement circuler d'un projet à l'autre, celui qui réunit la meilleure communauté risque de l'emporter et de détourner à son profit les contributeurs de son concurrent ; à l'inverse, bénéficier de l'expérience et de l'expertise
déployée par une société concurrente peut s'avérer être un choix judicieux.

Une fois sélectionnée la licence (ou un nombre limité de licences), il est nécessaire de faire preuve de *tactique* de sorte à peaufiner l'usage fait de la licence afin de s'assurer qu'elle réponde en tout point aux objectifs de l'auteur ou du projet. La seule existence de plusieurs centaines de licences laisse présager un nombre tout aussi grand de situations particulières les ayant justifiées. Il faut néanmoins rester vigilant au phénomène d'incompatibilité que cette multiplication a favorisé (cf. *supra*). Cette tactique peut prendre la forme d'interprétations ou d'exceptions.

En cas de clauses imprécises ou équivoques, il peut être utile de préciser le sens attendu, voire de désigner une personne tierce — un médiateur ou *proxy* — comme source d'interprétation. Cela confère une portée précise à la licence, qui tient les parties et le juge. C'est cette technique, dite de l'« interprétation » qu'utilisa Linus Torvalds sur le noyau Linux <fnref n="1" />.

L'usage des *exceptions* est une autre technique plus radicale qui consiste à modifier une licence préexistante en ajoutant, dans une clause jointe à la licence (ou insérée dans les en-têtes des fichiers), une spécificité qui déroge aux termes initiaux avec pour effet de rendre la licence finale plus ou moins contraignante. Cela permet, par exemple, de réduire efficacement la portée d'un *copyleft*, en lui fixant une étendue différente, en excluant plusieurs logiciels ou une catégorie entière de logiciels (plusieurs *exceptions* peuvent d'ailleurs être attachées à des parties différentes d'un logiciel <fnref n="2" />). Il est à noter qu'en l'absence de stipulation contraire, une clause additionnelle qui ne fait « qu'ajouter des droits » pourra être supprimée par tout licencié au moment de la redistribution d'une copie de cette création <fnref n="3" />.

<footnote n="1">1. « The "user program" exception is not an exception at all, for example, it's just a more clearly stated limitation on the "derived work" issue », TORVALDS (Linus), op. cit.. Le texte ajouté par l'auteur : « NOTE ! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of 'derived work'. »</footnote>

<footnote n="2">2. Tel Sencha qui offre une exception pour les applications différentes de l'exception pour le Framework (plus ouverte).</footnote>

<footnote n="3">3. Ceci valant bien sûr pour les licences dites permissives, mais aussi pour toute licence *copyleft* puisque le *copyleft* ne perpétue que les termes *stricto sensu* de la licence. Enfin, cette remarque n'est pas valable si la clause additionnelle contient aussi des obligations supplémentaires.</footnote>
La maîtrise de plus en plus fine de la pratique contractuelle liée aux licences *open source* conduit aujourd'hui à conseiller une pratique réfléchie et adaptée de ces exceptions et interprétations. Les premières confèrent plus de souplesse aux licences<fnref n="1" />, les secondes assurent une plus grande sécurité juridique. Un bon usage de celles-ci peut permettre de prévoir et de résoudre a priori la plupart des situations préjudiciables (obligations particulières du licencié, problèmes d'incompatibilité, failles au sein des licences, etc.).

→ *Le choix du libre choix : les multilicences*

On parle de multilicence lorsqu'une seule et même création est simul-
tanément disponible sous différentes licences : qu'elles soient toutes *open
source* ou qu'au moins l'une d'elles le soit. On ne parle plus de « double
licence » lorsque la licence *open source* n'est qu'une option au côté de
licences propriétaires classiques. Multiplier les licences permet générale-
ment d'associer leurs avantages : assurer une compatibilité au bénéfice
de plusieurs licences, bénéficier de la renommée de l'une, consolider la
cession de droits, etc.

Contrairement à ce que beaucoup semblent croire, il s'agit d'une tech-
nique simple et efficace :

1. le contenu sous licence est dès lors compatible avec la totalité des licences qui lui sont adjointes — auxquelles se rajoutent les licences avec lesquelles celles-ci sont déjà elles-mêmes compatibles ;

2. le licencié dispose donc de beaucoup plus de droits — dès lors qu'il
respecte au moins l'une des licences. En quelque sorte, cette pra-
tique permet d'ajouter une liberté au licencié qui est celle du choix
de la licence à laquelle il se soumet (chaque usage fait de la création
doit être conforme au moins à l'une des licences) ;

3. conséquence du point précédent, cette pratique permet de limiter
le *copyleft* global qui s'applique à l'œuvre par cela même que, le
licencié pouvant utiliser tout droit compris dans l'une au moins des

<footnote n="1">1. Dans un article dédié, la troisième version de la GNU GPL invite même à user de cette faculté sur ses propres contributions (en distinguant d'une part les permissions additionnelles qui peuvent être ajoutées sans limitation et les termes supplétifs à tirer parmi une liste de sept types de clauses).</footnote>
licences, ce sont les dispositions de la licence la plus permissive qui l'emportent souvent<fnref n="1" />;

4. enfin, en termes de sécurité juridique : si l'une des licences devait être annulée par une juridiction nationale, le licencié pourrait toujours revendiquer les droits conférés par l'autre<fnref n="2" /> (c'est aussi une source de prévisibilité pour celui qui utilise au moins une licence assurément valide — qui pourrait par exemple souhaiter utiliser une licence en langue française, conforme à son droit national, etc.).

C'est donc une solution qui, utilisée à bon escient par les auteurs, peut permettre optimiser la diffusion des créations et faciliter les contributions. Enfin, les motivations ne sont pas uniquement d'ordre juridique et il est possible de constater des situations où l'une des licences « contenant » déjà la seconde, la réunion des deux ne confère ainsi aucune prérogative spéciale au licencié<fnref n="3" />. Inutile juridiquement, mais utile en termes de communication...

Pour finir, ce mécanisme n'est pérenne dans son application sur un projet qu'autant que l'ensemble des contributions se fasse *a minima* sous licence multiple (quitte à ce que celles qui ne le seraient pas soient réécrites), ou licence permettant ces licences multiples (par exemple des licences du type MIT ou BSD).

### 3.1.1.2 Les conditions relatives à l'ajout d'une licence

L'ajout d'une licence libre à une création peut être du fait volontaire d'une personne physique ou morale qui diffuse l'œuvre (par exemple en application d'une politique globale à l'échelle de son entreprise ou du projet, etc.) ou par application des contraintes d'une licence (clause dite *copyleft*) qui imposerait l'extension des termes à d'autres composants (généralement du fait de leur combinaison ou d'une relation d'utilisation).

<footnote n="1">1. Une double licence MPL/GNU GPL permet d'appliquer les deux licences, ou l'une au choix, dans les limites du *copyleft* de la GPL.</footnote>

<footnote n="2">2. Par exemple, en utilisant conjointement les licences GNU GPL/CeCILL ou BSD/CeCILL-B, puisque les secondes sont expressément conformes au droit français.</footnote>

<footnote n="3">3. L'exemple révélateur est le navigateur Firefox, sous MPL, GNU LGPL et GNU GPL. Si la double licence MPL/LGPL est sans conteste utile, l'ajout de la licence GNU GPL semble l'être beaucoup moins puisque tout code sous GNU LGPL peut expressément être licencié sous GNU GPL.</footnote>
<figure><img src="image_46.png" /><figcaption>FIGURE 3.1 - Différentes techniques appliquées à une même licence</figcaption></figure>

Quel que soit le contexte, celui qui diffuse une création selon les termes d'une licence *open source* doit veiller à être en capacité de le faire. Il ne s'agit pas ici de savoir s'il a la capacité d'opérer sur le marché, mais de savoir si cela se fait en conformité avec les différents droits de propriété intellectuelle qui peuvent porter sur la création — les licences libres n'étant en effet que des outils juridiques dont l'effectivité repose sur la possession de droits de propriété intellectuelle suffisants. Deux statuts peuvent exister :

1. celui de titulaire des droits ;

2. celui de cessionnaire.

Finalement, un tel ajout est peu complexe vis-à-vis des créations que l'on contrôle personnellement (3.1.1.2.a), mais il en va autrement en présence de créations tierces soumises au respect de licences particulières (3.1.1.2.b).

### 3.1.1.2.a L'ajout d'une licence sur ses propres créations

Le titulaire des droits peut être le créateur originaire (ou son employeur si l'œuvre est créée « dans l'exercice de ses fonctions ou d'après les in-
structions de son employeur » <fnref n="1" />) ou une personne qui se serait fait céder l’intégralité des droits (par exemple le bénéficiaire de la création dans le cadre d’un contrat de commande lorsqu’une telle répartition des droits est prévue). On ne saurait trop conseiller à une personne morale (société, association, etc.) de vérifier les droits qu’elle détient (par contrat, dévolu- tion automatique ou du fait de ses propres démarches en cas de dépôts de brevet, marques, etc.).

Le titulaire des droits va ainsi user de ses prérogatives patrimoniales <fnref n="2" /> afin d’organiser le partage de ses droits gracieusement <fnref n="3" /> au profit de dé- tenteur de support ou de l’utilisateur de la création sur laquelle porte la licence. Cette cession non-exclusive n’empêche aucune autre exploitation ultérieure :

- le titulaire des droits qui communique son œuvre sous licence li- bre peut aussi (concomitamment ou ultérieurement) la diffuser d’une façon tout autre, et pas nécessairement libre ou *open source* ;

- le contributeur qui doit diffuser sous licence libre ses propres con- tributions peut cumulativement le faire sous une autre licence, voire sous une licence non libre (ou *open source*) s’il trouve à les réutiliser dans d’autres contextes (pour résumer : sa contribution restera *a min- ima* aussi libre).

Note

Il y a donc une grande différence de situation entre la (ou les) personne(s) titulaire(s) de droit(s) et les personnes cessionnaires (en capacité d’exploiter l’œuvre). Ainsi la création serait véritablement libre lorsque, au surplus d’être soumise à une licence, elle est aussi partagée entre de multiples auteurs : la création devenant alors quasi-ment autonome — une *res communis* qui, de par sa nature, ne peut être appropriée — appartenant à tous, donc à personne.

<footnote n="1">1. Cf. *supra*.</footnote>

<footnote n="2">2. Voir par exemple VIVANT (Michel), *Un jeu de prérogatives à caractère patrimonial*, dans *Lamy droit de l'informatique et des réseaux*, 2005, p. 192 sq..</footnote>

<footnote n="3">3. Art. L122-7 CPI prévoit la cession de ces droits à titre onéreux ou gratuit, dans la limite de ce qui est expressément stipulé dans le contrat.</footnote>
<figure><img src="image_47.png" /></figure>

### L'ŒUVRE D'UN MINEUR

L'auteur est celui qui crée l'œuvre originale : enfant, adulte, peu importe. Néanmoins, la question de sa capacité à s'engager se pose lorsque le concédant en est incapable (notamment entre enfant ou représentant légal).

La réponse est en deux temps, selon qu'il s'agit du droit moral ou du droit patrimonial...

En tant qu'auteur, le contrat est soumis à l'autorisation écrite de l'auteur (droit moral de divulgation), mais, en tant qu'incapable mineur, l'enfant ne peut pas exploiter son œuvre (droit patrimonial), car c'est un engagement qui dépasse les seuls actes de la vie courante et qui doit donc être confié à ses représentants.

Ainsi, pour mettre sous licence libre l'œuvre d'un mineur (ou d'un quelconque incapable), il faut réunir les deux signatures : celle de l'auteur et celle de son représentant (on peut noter que la seconde est moins importante puisque la seule action disponible est l'action en rescision pour lésion : si l'acte est pécuniairement désavantageux pour le mineur, alors même que les licences libres sont en principe sans considération économique).

### 3.1.1.2.b L'ajout d'une licence sur d'autres composants open source et les situations d'incompatibilité

Le second statut, celui de cessionnaire d'une licence, est régi par contrat et est généralement assorti d'un certain nombre de conditions : qu'il s'agisse d'une autre licence open source ou d'une cession limitée (il peut, par exemple, ne disposer que du droit de céder les droits, sans possibilité d'en jouir lui-même).

Les conditions peuvent être plus ou moins contraignantes, mais il faut garder à l'esprit qu'il est impossible de simplement « remplacer » une licence et, ainsi, que toute utilisation d'une nouvelle licence doit respecter celles préexistantes — c'est la raison pour laquelle on parle d'ajouter une licence « *au surplus* de celle(s) déjà existante(s). »
Ainsi, lorsque plusieurs licences nécessitent leur extension à un même composant, il convient de régler en amont les problèmes de compatibilité entre elles (la situation la plus simple étant lorsqu'une telle compatibilité est expressément assurée au sein de la licence) — en déterminant dans quelle mesure la distribution sous une licence spécifique respecte les autres licences — afin de vérifier ensuite que l'ajout est bien possible au regard de la licence d'origine.

Il convient donc de déterminer les situations de superposition et, à défaut d'une compatibilité expresse, de vérifier l'existence d'une compatibilité logique entre les différentes licences (c'est-à-dire la possibilité de respecter l'une en utilisant l'autre, généralement parce qu'elle n'oblige pas moins et ne donne pas plus de droits). Cette problématique est relativement simple lorsque les licences font partie d'une même famille de licences<fnref n="1" />, mais devient rapidement plus complexe lorsque les licences sont d'origines diverses. La dernière version de la GNU GPL (v. 3) s'appuie sur ce principe pour accueillir en son sein une souplesse et une modularité qui lui permettent d'assurer la compatibilité à l'égard de licences libres et *open source* uparavant incompatibles<fnref n="2" /> : en permettant, sur chaque nouvelle contribution, d'une part, l'ajout de *permissions additionnelles* et, d'autre part, l'ajustement par l'utilisation de certains *termes supplétifs* limitativement autorisés<fnref n="3" />.

Néanmoins, il peut arriver dans certaines situations que les obligations soient contradictoires et inconciliables (impossibles à respecter simultanément), y compris en présence seulement de composants *open source*, on parle alors d'incompatibilité entre les licences : la création ainsi composée ne peut être exploitée en respectant cumulativement toutes les licences. Parfois, la lecture des licences peut permettre, matériellement<fnref n="4" /> ou techniquement, de résoudre certaines incompatibilités (par exemple dans l'hy-

<footnote n="1">1. La plus connue est certainement la famille des licences GNU (GPL, LGPL, AGPL, etc.), mais bien d'autres peuvent être citées pour l'exemple : CeCILL (CeCILL-A, CeCILL-B, CeCILL-C), OSL (OSL, AFL), etc.</footnote>

<footnote n="2">2. Notamment les licences plus permissives comme les licences Apache, LaTeX, etc.</footnote>

<footnote n="3">3. Il convient donc de confronter chaque licence aux différentes clauses, au cas par cas, afin d'être certain de leur compatibilité — avec le risque d'une divergence d'interprétation, comme c'était déjà le cas les licences GPL et Apache.</footnote>

<footnote n="4">4. Les licences modulaires du type MPL sont justement optimisées en ce sens puisqu'elles permettent, par leur étendue limitée aux seuls fichiers, la conception de logiciels complexes soumis à différentes licences, ce qui réduit la nécessité de clause particulière assurant leur compatibilité. À noter néanmoins que la seconde version de la MPL</footnote>
pothèse de certaines formes de distribution¹, certains modes de distribu-
tion² et certaines constructions de la création³). Mais de tels contournements compliquent la compréhension de la licence et ne sont généralement pas souhaitables — ou possibles — et, à défaut de solution à cette incompatibilité, il faudra renoncer à l'utilisation d'un composant (ce qui revient souvent à le réécrire), voire à la diffusion d'un ensemble de composants, ou encore se rapprocher de l'auteur (ou des auteurs ⁴) de la création afin qu'il consente soit à une exception expresse ⁵ indiquant à quel logiciel il entend ne pas étendre sa licence ⁶ (dans un fichier supplémentaire distribué avec le logiciel et sa licence), soit à l'utilisation d'une autre licence ⁷.

<figure><img src="image_48.png" /></figure>

### LA THÉORIE DES ENSEMBLES ET LA COMPATIBILITÉ

Cette réflexion peut se traduire mathématiquement grâce
à la théorie des ensembles sous la forme qui suit : la licence
B est dite compatible (c'est-à-dire qu'elle peut être util-
isée pour redistribuer le logiciel en respectant les termes

devrait organiser une compatibilité au profit des licences GNU (le problème venant du fait que celles-ci ont des étendues très larges qui favorisent les situations d'incompatibilité).

1. Par exemple un exécutable, tant que les sources des modifications sont disponibles par ailleurs.

2. On pense notamment aux logiciels dont seul le client est distribué alors que le serveur est hébergé chez l'éditeur.

3. Par exemple la construction modulaire pour l'utilisation de composants sous licence du type MPL, voire LGPL.

4. Le nombre et la dispersion des auteurs et contributeurs restant néanmoins un écueil notable.

5. Qui n'est en réalité qu'un avenant au contrat.

6. Des exemples d'exceptions sont proposés par la FAQ de la GPL : « Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination. In addition, as a special exception, the copyright holders of ABC give you permission to combine ABC program with free software programs or libraries that are released under the GNU GPL and with independent modules that communicate with ABC solely through the ABCDEF interface. You may copy and distribute such a system following the terms of the GNU GPL for ABC and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code. Note that people who make modified versions of ABC are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception » (http://www.gnu.org/licenses/gpl-faq.html).

7. Sur ces points, voir aussi Software Freedom Law Center, *Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers*, 2007.
de la licence originaire A) si et seulement si l'ensemble
des droits de la licence B est inclus dans la licence A et
que l'ensemble des obligations de la licence A est inclus
dans la licence B.

3.1.2 Respecter le formalisme lié à l'utilisation des licences libres

La maîtrise effective des éléments constitutifs de la création est essen-
tielle dans les projets *open source* puisque ce n’est que lorsque l’utilisateur
est matériellement en mesure d’en user que les droits cédés par la licence
trouvent leur utilité <fnref n="1" /> — rendant indispensable l’accès à un certain nombre
d’éléments matériels (code source, documents préparatoires, scripts, etc.).

Ainsi, au-delà de la simple cession de droits, les licences libres et *open source* contiennent généralement un ensemble de dispositifs pratiques qui ont pour fonctions principales d’assurer aux utilisateurs une bonne information (3.1.2.1) et une réception effective de la création (3.1.2.2). C’est sur leur fondement que la cour de Munich avait, courant 2007, rendu une décision en ce sens lors de l’affaire Welte vs. Skype Technologies SA, condamnant la société Skype qui n’incluait ni une copie de la GNU GPL ni le code source correspondant au binaire conformément au texte de la licence (Skype incluait néanmoins l’URL de celui-ci par l’intermédiaire d’un flyer).

3.1.2.1 Le respect du formalisme assurant une bonne information

La reconnaissance par les pairs, ainsi que l'entretien d'une « im-
age » liée à leurs activités créatrices (pour des raisons artistiques ou
économiques), sont des éléments moteurs pour de nombreux individus.
Les mentions légales, obligatoires, y pourvoient, mais sans indiquer pré-
cisément quelles sont les actions attendues et quel formalisme doit accom-
pagner la réutilisation et la diffusion de leurs œuvres (les juges appréciant
au regard des « usages du métier »).

<footnote n="1">1. Voir/écouter à cet égard PETERSON (Scott) (Senior Counsel Hewlett-Packard Company), « Current trends in the hardware sector : the HP Experience », EOLE 2010. Ainsi que MARR (Dave) (Director Legal, Open Source Group Products and Technology Law, Sun Microsystems, Inc), « GPLv3 from an Embedded Industry Perspective », EOLE 2009.</footnote>
C'est ce manque — moins présent pour les œuvres non logicielles<fnref n="1" /> — que comblent les contraintes des licences relatives au formalisme, sous la forme d'une série d'obligations qui assurent une bonne information quant à l'origine du code et des conditions de son exploitation auprès des utilisateurs. Ces obligations vont parfois plus loin que les simples mentions légales — telles les clauses dites « de publicité » qui s'étendent à tous les documents commerciaux publicitaires relatifs au logiciel qui les contient.

Ainsi, il est possible de distinguer les obligations opérant une mise à disposition passive des informations légales (3.1.2.1.a) et celles contraignant à un affichage actif (3.1.2.1.b).

### 3.1.2.1.a La mise à disposition passive des informations légales

Les informations légales (y compris le texte des licences) figurent dans les en-têtes des fichiers et (si nécessaire) dans des fichiers joints aux sources.

De manière générale, tout fichier (comprenant du code sous licence libre ou non) devrait contenir un en-tête affichant les « mentions légales minimums » : c'est-à-dire rappelant le nom et la qualité du titulaire de droits, la date de la création (et éventuellement des ajouts) et les licences utilisées. Une mention excluant toute garantie est aussi à prévoir dans le cadre des licences libres. Elle peut être assez courte pour les petits fichiers, et reprendre l'intégralité de la clause d'exclusion de garantie de la licence utilisée pour les fichiers plus importants.

Pour éviter d'alourdir inutilement le code distribué, toutes les mentions trop longues pour être insérées en l'état dans chaque en-tête peuvent être transférées dans des fichiers joints aux sources :

- les textes des licences<fnref n="2" />, leurs éventuelles traductions et modalités spécifiques d'application (fichier license(s).txt);

<footnote n="1">1. Ce qui explique qu'elles imposent un formalisme beaucoup plus léger, qui peut le plus souvent être rempli par l'indication du titre de l'œuvre, son auteur, sa date, la licence et un lien vers l'œuvre originale. Les exemples qu'elles fournissent sont généralement très simples à mettre en œuvre (voir notamment la LAL ou la GNU FDL).</footnote>

<footnote n="2">2. Certaines, très courtes, telles les licences BSD, peuvent néanmoins se retrouver en en-tête.</footnote>
- le fichier explicatif permettant à l'utilisateur ou au licencié de comprendre où trouver les informations qu'il recherche, le fonctionnement du projet, comment contribuer au projet, les éventuels composants soumis à d'autres licences, etc. (fichier readme.txt);

- la liste exhaustive des contributeurs originaux et subséquents au logiciel, avec les dates de chacune de leur contribution (fichier authors.txt);

- les autres informations (documentation du logiciel — qui rappellera par ailleurs les mentions légales du logiciel —, une FAQ — qui permettra de lever toute ambiguïté —, etc.).

Il s'agit ici de bon sens et de bonnes pratiques, les licences n'imposant généralement que des mentions « raisonnables »<fnref n="1" /> de ces éléments, d'autres fichiers peuvent venir compléter cette liste : changelog.txt, legal.txt, export.txt, etc.

<figure><img src="image_49.png" /></figure>

## FAUT-IL IMPÉRATIVEMENT UTILISER LE SIGNE © ?

En matière de copyright, le droit américain s'est longtemps différencié du système latin du droit d'auteur, et ceci notamment en conditionnant l'action en justice à un enregistrement des œuvres auprès de l'United States Copyright Office.

En parallèle, et afin de reconnaître des droits aux auteurs étrangers dont les œuvres n'étaient pas soumises à ce formalisme, une procédure plus légère fut assimilée à cet enregistrement, consistant en l'apposition d'une mention comportant « de façon nette le symbole ©, accompagné du nom du titulaire du droit d'auteur et de l'année de publication de l'œuvre. »

Depuis l'adhésion des États-Unis à la Convention de Berne, en 1989, un assouplissement du formalisme américain a rapproché celui-ci du système du droit d'auteur

<footnote n="1">1. Voir le texte de la GNU GPL v. 3, Art. 7 : « b) Exigeant le maintien de mentions légales spécifiées ou de mentions d'attribution de paternité spécifiées raisonnables au sein de cette contribution ou dans les Mentions Légales Appropriées affichées par les créations la contenant ; c) Interdisant une indication erronée de l'origine de cette contribution, ou exigeant que les versions modifiées de cette contribution soient marquées de façon raisonnable comme étant différent de la version originale ; ou (...). »</footnote>
qui protège les œuvres du simple fait de leur conception. Ainsi, une simple mention de l'auteur et de la date de conception devrait permettre à toute personne de revendiquer ses droits.

Néanmoins, cette *notice de copyright* doit être considérée comme une présomption de titularité des droits, et la rédaction « à l'américaine », notamment recommandée par l'article III.1 de la Convention Universelle, conserve ainsi une certaine utilité.

### 3.1.2.1.b L'affichage actif des mentions légales

Dépassant l'affichage classique des mentions légales, quelques licences demandent aux licenciés de s'assurer par un comportement actif que les utilisateurs auront bien connaissance des mentions légales, de la licence, etc.

Ainsi peut-on regrouper les clauses qui ont pour vocation d'assurer :

- la visibilité de l'affichage des mentions légales. Les licences peuvent demander à ce que les mentions légales soient clairement affichées : à certains moments et dans certains contextes (telle la GNU GPL en présence d'interface utilisateur interactive<fnref n="1" />) ou telles qu'elles étaient affichées à la réception de l'œuvre (telles les licences Yahoo Public License ou Zimbra Public License<fnref n="2" />);

- l'affichage d'attributions particulières. Ces clauses vont un peu plus loin que les simples mentions légales et demandent que soient

<footnote n="1">1. Une interface utilisateur interactive affiche des « Mentions Légales Appropriées » dans la mesure où elle inclut un dispositif pratique et visible de façon proéminente qui (1) affiche une mention de droit d'auteur appropriée et (2) indique à l'utilisateur qu'il n'y a aucune garantie portant sur la création (sauf si des garanties sont accordées), que les licenciés peuvent transmettre la création sous cette licence, et comment voir une copie de cette licence. Si l'interface intègre une liste de commandes ou d'options utilisateur, tel qu'un menu, un élément proéminent dans la liste remplit ce critère.</footnote>

<footnote n="2">2. « 3 — Intellectual Property Rights (...) 3.2 — In any copy of the Software or in any Modification you create, You must retain and reproduce, any and all copyright, patent, trademark, and attribution notices that are included in the Software in the same form as they appear in the Software. This includes the preservation of attribution notices in the form of trademarks or logos that exist within a user interface of the Software. »</footnote>
ajoutées certaines mentions ou phrases lors de la distribution et/ou
l'utilisation du logiciel<fnref n="1" />;

- *la publicité autour du logiciel.* Ainsi était-ce notamment le cas de la licence Apache version 1.0 ou de la version initiale de la BSD (4-clause BSD) — ces deux licences étant encore utilisées sur le logiciel Truecrypt 2. Ces clauses, bénignes à leur origine, deviennent lourdes de conséquences lorsque leurs effets se cumulent ou s'accroissent. Ainsi en est-il lors de la multiplication de clauses de publicité, la plus renommée pour sa dégénérescence étant celle de la licence BSD 3. Elle contraignait à citer le donneur de licence dans toute publicité relative au logiciel ou à son utilisation, provoquant de lourds problèmes lorsque les contributeurs choisirent d'utiliser cette licence en modifiant la citation en leur faveur : la multiplication des citations devint rapidement extrêmement fastidieuse et gênante. La FSF s'est rapidement prononcée contre l'« odieuse clause de publicité BSD 4 » (Richard Stallman rapporte ainsi avoir décompté en 1997 plus de 75 mentions publicitaires obligatoires attachées à la distribution de NetBSD).

### 3.1.2.2 Le respect du formalisme assurant une réception effective de l'œuvre

Il s'agit ici du code source correspondant (3.1.2.2.a), de la documenta-
tion (3.1.2.2.b) et tout autre élément utile pour l'appréhension de la créa-
tion (3.1.2.2.c).

<footnote n="1">1. Par exemple : « This product includes PHP software, freely available from <http://www.phpnet/software/> » ou « RSA Data Security, Inc. MD5 Message-Digest Algorithm » ou « derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm », pour toute distribution du logiciel modifié.</footnote>

<footnote n="2">2. Ce qui oblige à cumuler les deux mentions suivantes : « This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org) » ; « This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). »</footnote>

<footnote n="3">3. Qui figurait dans son article 3 : « All advertising materials mentioning features or use of this software must display the following acknowledgement : This product includes software developed by the University of California, Berkeley and its contributors. », supprimé en 1999 par l'Université de Californie.</footnote>

<footnote n="4">4. http://www.gnu.org/philosophy/bsd.html</footnote>
### 3.1.2.2.a Le code source correspondant

De nombreuses licences définissent la notion de code source comme la forme de la création préférée pour faire des modifications sur celle-ci.

Les licences vont dorénavant plus loin et la GNU GPL requiert la « source correspondante » du logiciel fourni en exécutable, défini comme étant « tout le code source nécessaire pour générer, installer et (pour une création exécutable) exécuter le code objet et modifier la création, y compris les scripts pour contrôler ces activités ». Les bibliothèques systèmes et autres éléments habituellement disponibles dans un environnement de développement sont cependant exclus pour des raisons pratiques.

Le plus simple est généralement que la source accompagne le binaire (ou soit disponible sur le même serveur). Or, ce n'est cependant pas toujours possible ou souhaité et d'autres alternatives sont généralement proposées : telle l'offre de fournir les sources correspondantes à la demande (mais avec d'autres problématiques comme le délai raisonnable de cette communication des sources).

<figure><img src="image_50.png" /></figure>

## NON RESPECT DE LA GNU GPL SUR GNU EMACS ?

Il est toujours bon de se rappeler que même les meilleurs sont faillibles. Ainsi, RMS a récemment publié un article annonçant que plusieurs versions de son logiciel GNU Emacs ne respectaient pas la GNU GPL (Emacs distributions are not GPL-compliant)¹:

From: Richard Stallman
Subject: Re: Compiled files without sources????}
Date: Thu, 28 Jul 2011 19:00:17 -0400

> They are in Emacs releases 23.2 and 23.3.
> They have been in all pretests since
> emacs-23.1.90, dated 2009-12-09. They
> were merged into the Emacs trunk
> in bzr 97804, dated 2009-09-28;
> here's a URL for that: (URL).

> We have made a very bad mistake. Anyone
> redistributing those versions is violating
the GPL, through no fault of his own.

We need to fix those releases retroactively
(or else delete them), and we need to do it
right away.

I see two quick ways to fix them: to delete the
compiled files, or to add the sources they are
made from.

--

Dr Richard Stallman

President, Free Software Foundation

Bien entendu, cette erreur est aujourd'hui corrigée.

### 3.1.2.2.b La documentation

La documentation d'un code et d'un logiciel (ou d'une création utilitaire qui sera ou non amenée à évoluer) est une condition nécessaire à sa bonne prise en main. Deux types de documentation peuvent être distribués :

- la documentation relative à l'installation et au paramétrage du logiciel. Son statut juridique est calqué sur celui du logiciel et certaines licences imposent sa communication dans les mêmes termes (notamment l'OSL);

- la documentation « utilisateur » qui est protégée de manière indépendante et pour laquelle la société peut parfaitement utiliser une licence différente (la GNU FDL étant généralement la plus adaptée en raison de son étendue très large qui permet d'assurer de conserver une documentation entièrement libre).

### 3.1.2.2.c Autres éléments

Enfin, dans l'hypothèse où certains composants pourraient être certifiés (ou simplement qualifiés, selon le secteur industriel), la problématique

<footnote n="1">1. Source : http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01155.html.</footnote>
tique d'une mutualisation des coûts engendrés par cette certification peut venir s'ajouter aux réflexions sur l'open source : le matériel de certification pourra ainsi être librement communiqué (afin de favoriser la diffusion et utilisation du logiciel) ou, au contraire, être réservé à un groupe de sociétés afin de mutualiser le coût au sein d'une communauté d'utilisateurs. Ces problématiques sont très fortes dans des secteurs tels l'aéronautique, l'aérospatiale, le ferroviaire, l'automobile, etc.

## 3.2 Diffuser sous licences libres

Le courant des licences libres, malgré sa jeunesse et sa relative complexité, a rapidement donné naissance à un nouveau système. Ainsi, c'est l'organisation des acteurs privés qui doit être examinée (3.2.1) avant de se pencher sur l'organisation relative à la diffusion du logiciel sous licence libre (3.2.2).

### 3.2.1 Se positionner dans l'écosystème du logiciel libre

Par leur organisation, les acteurs privés ont dessiné un nouveau système dont il convient de présenter les acteurs (3.2.1.1) et les interactions qui le caractérisent (3.2.1.2)<fnref n="1" />.

#### 3.2.1.1 Les acteurs du système du logiciel libre

Les licences libres ne sont que des outils. Le corollaire est que tous les types de personnes (physiques ou morales, privées ou publiques, de tout secteur ou métier) les utilisent, avec une pluralité de motivations, mais au profit de la constitution d'un « pot commun » qui les réunit (chacun étant libre d'y verser comme d'y puiser). Les individus, les associations et autres organismes à but non lucratif ont souvent un rapport au Libre complexe qui mêle philosophie, idéologie, et des arguments plus raisonnés comme le coût ou l'indépendance qu'offrent les solutions logicielles libres. Tandis que les entreprises, neutres par essence<fnref n="2" />, ainsi que les col-

<footnote n="1">1. On pourra accessoirement se reporter au Rapport Ernst & Young, *Open source software in business-critical environments*, 2011 (sur http://www.ey.com).</footnote>

<footnote n="2">2. Voir notamment FRISON-ROCHE (Marie-Anne) : « Qu'est-ce qu'agir de façon neutre », dans *La neutralité dans les systèmes de régulation économique*, Colloque annuel de *The Journal of Regulation (JR)*.</footnote>
lectivités et administration adoptent le Libre par opportunité et pragma-
tisme (les logiciels libres assurant, outre une maîtrise des coûts, les avan-
tages d'une grande flexibilité et d'un développement rapide).

Parmi tous les courants et même s'il n'est peut-être pas le plus connu
du grand public (le mouvement de l'Open Data est par exemple « très
vendeur »), le secteur le plus avancé et structuré est incontestablement
celui du logiciel : 50 % des entreprises interrogées par Gartner<fnref n="1" />, ont
adopté les logiciels libres dans le cadre de leur stratégie informatique.
Ainsi, l'industrie du logiciel libre devrait représenter 10 % du marché de
demandes en logiciels et services français d'ici 2 ans<fnref n="2" /> (renforçant ainsi la
compétitivité de la France en matière de développement de logiciels).

Les développements qui suivent seront donc dédiés au système qui car-
actérise le logiciel libre. On s'aperçoit que les frontières entre les dif-
férents acteurs (éditeurs des logiciels, intégrateurs, constructeurs et util-
isateurs) sont beaucoup moins étanches que dans le secteur traditionnel
du logiciel : les éditeurs intègrent de plus en plus de composants *open
source* dans leurs logiciels, les intégrateurs peuvent prendre le rôle d'édi-
teur vis-à-vis de leur client (support de niveau 3, développement de nou-
velles fonctionnalités, etc.) et les utilisateurs eux-mêmes se réunissent
en « une communauté d'utilisateurs éditrice<fnref n="3" /> ». Néanmoins, si on dis-
tingue les entreprises simples utilisatrices de composants *open source* de
celles qui orientent leur modèle économique en rapport avec cet usage,
et qu'on se concentre sur ces dernières seulement, on peut distinguer dif-
férents rôles : éditeurs (3.2.1.1.a), intégrateurs (3.2.1.1.b), constructeurs
(3.2.1.1.c), grands utilisateurs clients (3.2.1.1.d), fondations et commu-
nautés (3.2.1.1.e) et centres de recherche (3.2.1.1.f).

3.2.1.1.a Les éditeurs *open source*

Il s'agit ici de l'entreprise distribuant sous licence libre un logiciel
qu'elle édite. De multiples adoptions de l'open source coexistent dans

<footnote n="1">1. « Gartner Survey Reveals More than Half of Respondents Have Adopted Open-Source Software Solutions as Part of IT Strategy », Fevrier 2011 (http://www.gartner.com).</footnote>

<footnote n="2">2. Étude OPIEC Mars 2009 : « Les métiers du logiciel libre en France » (www.syntec-informatique.fr — tendance 2008-2009 du logiciel libre, www.ob2l.com). Voir aussi le Rapport de la Commission pour la libération de la croissance française, sous la présidence de Jacques Attali, La documentation française, 2008 (http ://lesrap-ports.ladocumentationfrancaise.fr).</footnote>

<footnote n="3">3. Voir ÉLIE (François), *Économie du logiciel libre*, Paris, Eyrolles, 2009.</footnote>
le monde de l'édition : en fonction de l'éditeur (et de son histoire), du type de produit édité et de ses utilisateurs. Le choix n'est pas systématique, mais les éditeurs qui souhaitent construire un modèle économique innovant, voire disruptif, ont besoin de s'appuyer sur une communautés, préexistante ou nouvellement créée, qui va jouer le rôle de soutènement (renforçant le logiciel, se substituant parfois à la société, et constituant une réserve de clients voire de salariés pour la société). À partir de là, le modèle économique de la société est généralement issu d'un équilibre entre ce qui est cédé et le contrôle, plus ou moins fort, conservé par l'éditeur (par un droit exclusif, sur la feuille de route, etc.). Se concentrant sur les seules pratiques juridiques et sans que la liste soit exhaustive, les principaux mécanismes (librement combinables) sont l'usage du droit des marques, la proposition de licence commerciale complémentaire, la mise à disposition décalée ou encore le contrat.

Le plus souvent, les éditeurs assurent la protection de leur produit par l'usage complémentaire du droit des marques<fnref n="1" /> : le logiciel est librement diffusé sous licence *open source*, mais tout usage de la marque est soumis à autorisation. Cette faculté qu'offre le cumul de droits exclusifs concurrents sur un même objet a ici l'avantage de rendre quasi inexistant le coût d'entrée pour les utilisateurs, tout en assurant à l'éditeur principal un contrôle sur l'évolution, la distribution des copies et l'exploitation globale du logiciel. Dans l'usage de ce droit, il est possible de distinguer les sociétés commerciales qui ont tendance à en user de façon très agressive — au point parfois de réduire les libertés concédées par la licence *open source* sur le logiciel<fnref n="2" /> — tandis que les structures non commerciales en font un usage plus modéré, équilibré, qui a principalement pour objectif de défendre l'image associée au logiciel<fnref n="3" />. Le risque inhérent à ce type

<footnote n="1">1. *Cf. supra* concernant l'étude du droit des marques.</footnote>

<footnote n="2">2. Un très bon exemple est la société américaine Red Hat : elle n'autorise aucun usage de ses marques, sauf : pour un usage non commercial par des établissements éducatifs, des associations à but non lucratif, aux groupes d'utilisateurs et leurs personnels correspondants ; pour un usage personnel ou professionnel issu d'une version originale sous la condition de non-redistribution... Mandriva propose, elle, une licence de marque pour la distribution d'une version non modifiée d'un produit Mandriva lorsque celui-ci est disponible gratuitement sur son site internet.</footnote>

<footnote n="3">3. La Mozilla Foundation limite par exemple l'usage des marques Firefox et Thunderbird selon la version du logiciel (licence complète sur la version binaire non modifiée, licence large pour les versions officielles localisées, licence réduite pour la version communautaire et enfin aucune licence pour une version du logiciel trop modifiée).</footnote>