d'utilisation du droit des marques est que l'éditeur, trop mercantile, se mette à dos la communauté qui s'émancipe alors en enlevant toute allusion à la marque du logiciel et en reprenant à son compte les logiciels diffusés sous licence *open source* <fnref n="1" />. Aux États-Unis, les brevets sont aussi utilisés comme un levier supplémentaire permettant de convaincre les investisseurs et les clients (Novell en étant le meilleur exemple). On observe le même phénomène en Europe, même si l'utilisation des brevets parallèlement à une licence libre reste heureusement un comportement isolé et très critiquable.

Par ailleurs, il est fréquent que les éditeurs ne fassent pas le choix exclusif de l*open source* et développent de façon périphérique des offres commerciales en associant à la version libre des *add-ons* ou *plug-ins* (graffon) sous licence commerciale <fnref n="2" />. Dans le même esprit, il est possible de proposer le même logiciel sous une licence commerciale présentée comme alternative à la licence *open source* <fnref n="3" /> ou de proposer un service autour d'une version non encore distribuée du logiciel (à noter néanmoins que ces deux solutions sont conditionnées au fait que la société détienne tous les droits sur le logiciel <fnref n="4" /> ou que les licences des composants *open source* utilisés n'interdisent pas de telles utilisations ou distributions fermées). Dans ce second cas, il est possible de penser à un modèle du type *free cloud* telle que l'offre *Drupal Garden* de la société Acquia : un ou plusieurs services fournis sur la plate-forme de l'éditeur (par exemple création et hébergement d'un site) s'harmonisent avec la distribution *open source* du logiciel puisque l'utilisateur peut à tout moment exporter le code et le contenu générés pour les installer sur sa propre instance.

<footnote n="1">1. Red Hat a ainsi vu naître CentOS, version « expurgée » de la première (opération qui est par ailleurs techniquement compliquée par Red Hat), et Firefox s'est vu opposer Iceweasel (avec un succès plus mitigé) — aujourd'hui GNU IceCat.</footnote>

<footnote n="2">2. Cette pratique est surtout répandue en matière de distribution ou compilation de logiciel, c'est-à-dire des situations où des briques non libres peuvent être mêlées à d'autres qui le sont. C'est notamment le cas de Red Hat et Mandriva.</footnote>

<footnote n="3">3. Encore faut-il que cette licence soit suffisamment contraignante pour intéresser au choix de la licence commerciale. Ce sont les exemples de MySQL AB, Sleepycat Software Inc., TrollTech AS, etc. Ainsi, MySQL AB qui propose MySQL Entreprise sous licence GNU GPL v 2 (avec exception en faveur d'autres logiciels libres) ou sous licence propriétaire pour ceux qui ne désirent pas respecter la licence (notamment pour développer ou distribuer un projet propriétaire) ou veulent bénéficier de mises à jour, de service support et assurance.</footnote>

<footnote n="4">4. Ce dont MySQL s'assure en n'intégrant dans le produit que les contributions qu'elle a pu réécrire ou racheter.</footnote>
Dans ces hypothèses, mixer licences *open source* et commerciales<fnref n="1" /> permet divers montages dans lesquels les communautés continuent à trouver leur intérêt à utiliser et collaborer au développement du logiciel grâce à la licence *open source*, tandis que les utilisateurs professionnels préfèrent à terme opter pour une licence commerciale<fnref n="2" />.

De façon assez similaire, certaines sociétés proposent des mises à jour plus simples et régulières à leurs clients (non immédiatement accessible aux utilisateurs de la version communautaire) : soit par une mise à disposition systématiquement décalée (de quelques mois ou quelques semaines) ; soit par une mise à disposition graduelle des mises à jour pour les clients (alors qu’elles seraient regroupées pour la version complémentaire). Ce décalage peut être matériel ou juridique (les mises à jour ne sont considérées comme *divulguées* qu’à compter d’une certaine période).

Enfin, certaines sociétés usent du droit des contrats afin de limiter accessoirement l’utilisateur dans les libertés que lui concède la licence *open source* : que ce soit lors de la vente de services aux utilisateurs qui souhaitent bénéficier du support et des mises à jour<fnref n="3" /> ou dans les rapports entre distributeurs et revendeurs<fnref n="4" />. Les contrats sont aussi essentiels pour les logiciels orientés métiers demandant de concevoir plus finement la collaboration entre les différents industriels<fnref n="5" /> : la licence *open source* n’étant alors plus qu’une partie du cadre contractuel (s’ils sont concurrents, une

<footnote n="1">1. Le terme peut sembler ambigu : une licence *open source* autorise parfaitement un usage commercial du logiciel, mais elle n’en restera pas moins une cession non exclusive gracieuse ; à l’inverse, une licence dite commerciale sera conditionnée au paiement d’une souscription quelconque.</footnote>

<footnote n="2">2. À la différence de la licence *open source* par ailleurs proposée (probablement *copyleft* ou tout du moins suffisamment contraignante pour que l’utilisateur ait un intérêt à opter pour la licence commerciale), la licence commerciale de l’éditeur offre aux clients des avantages comme la possibilité de ne pas diffuser le contenu de leur création dérivée (échappant ainsi à la réciprocité afin de continuer de disposer de leur monopole).</footnote>

<footnote n="3">3. C’est notamment le cas de Red Hat avec les produits comme *JBoss Enterprise Middleware*, *Red Hat Directory Server*, *Red Hat Certificate System*, etc.</footnote>

<footnote n="4">4. On retrouve ce type de limitation dans les contrats de MySQL, Ingres, Alfresco, etc. Le revendeur se retrouvant bien souvent contraint de ne pas utiliser ou conseiller la version communautaire.</footnote>

<footnote n="5">5. La licence *open source* assurera la confiance entre ces derniers vis-à-vis de ce qui est créé et permettra éventuellement à d'autres acteurs de bénéficier d'un coût d'entrée quasi inexistant — de façon à ce qu'ils puissent par la suite éventuellement rejoindre le cercle des partenaires ; par ailleurs, le consortium jouera le rôle d'un contrat d'indivision par lequel les partenaires s'organisent pour la gestion du projet (en amont lors de la création et en aval pour l'exploitation du projet).</footnote>
licence *copyleft* sera une condition *sine qua non* afin d'assurer une relative pérennité et équité dans le développement du logiciel) — un contrat de consortium complétant éventuellement tous les aspects non couverts par la licence (comité de direction, procédé de développement, prise en compte des orientations, marketing et communication, etc.)

## Par exemple...

Révélateur de l'intérêt de l'open source, les diverses structures représentatives de l'industrie du logiciel se positionnent progressivement sur le sujet et mettent en place des commissions open source. Ainsi, Syntec Numérique a rédigé un Guide Open Source<fnref n="1" /> et créé un comité open source avec pour mission de « fixer le cadre contractuel et d'usage en matière de projets informatiques incluant du logiciel libre : comment s'inscrit le logiciel libre dans l'architecture des projets informatiques, en matière technique, juridique, business model, organisationnelle et distribution ». À son tour, l'AFDEL qui avait abordé les logiciels libres au travers d'un guide<fnref n="2" />, a récemment mis en place une commission dédiée, présidée par Bertrand Diard (Talend), avec pour mission de « réunir et fédérer les éditeurs de logiciels en France pour débattre de thèmes spécifiques liés au modèle open source, et rédiger des conclusions et propositions sur ces thèmes ». Le Cigref a aussi récemment publié son guide intitulé « Maturité et gouvernance de l'Open Source : la vision des grandes entreprises » (http://www.cigref.fr).

## MICROSOFT ET L'OPEN SOURCE

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

Le comportement de cette société peut, à divers égards, sembler paradoxal.

<footnote n="1">1. Disponible sur : http://guideopensource.info. Voir JEAN (Benjamin) et FLI (Olivia), « Bonnes pratiques en matière de conception et de pilotage de projets informatiques incluant ou composés de briques logicielles libres », EOLE 2009.</footnote>

<footnote n="2">2. Voir notamment l'étude « Propriété intellectuelle et logiciels, la position l'association Française des éditeurs de logiciels », AFDEL, 2007.</footnote>
– Microsoft a ouvertement qualifié le mouvement du logiciel libre de « cancer »¹ avant de rédiger ses propres licences labellisées *open source* (Microsoft Public License (Ms-PL) et Microsoft Reciprocal License (Ms-RL)) au sein du programme Shared Source Initiative¹ (initiative destinée à favoriser l'innovation technique, elle permet un accès favorisé au code source des logiciels de la société au profit des clients, partenaires, chercheurs et développeurs).

– Un laboratoire *open source* a été mis en place, et Microsoft s'enorgueillit de contribuer à plusieurs projets libres (voir le billet intitulé « Microsoft Contributes Linux Drivers to Linux Community », sur Microsoft.com).

– La société a une politique en matière de brevets généralement contraire à l'*open source* : elle oppose régulièrement ses brevets contre des projets *open source* ; et a racheté des brevets de Novell par l'intermédiaire d'un consortium (CPTN Holdings LLC) qu'elle dirige ; même si elle a par ailleurs publié deux promesses de non-agression (« Patent Pledge for Open Source Developers » ; « Microsoft Approach to Interoperability »).

– La société s'est rapprochée de l'éditeur Novell au sein d'un Interop Ability Lab (interopérabilité entre Windows serveur et Suse Linux Entreprise : http://www.moreinterop.com).

– La WebApp de Microsoft comporte par ailleurs des clauses interdisant aux développeurs d'utiliser directement ou indirectement des composants sous licence *open source* (voir Computing.co.uk, « Microsoft restricts use of open source in app ») : « the application must not include software, documentation, or other materials that, in whole or in part, are governed by or subject to an 'excluded license', or that would otherwise cause the application to be subject to the terms of an excluded license. ». Sont ainsi exclues les licences GNU GPL et AGPL, et équivalentes...
Depuis peu, la société communique sur son modèle économique intitulé Open Surface (un *cloud* qui mêle logiciels libres et propriétaires).

### 3.2.1.1.b Les intégrateurs

De leur côté, les intégrateurs de logiciels libres et *open source* (ou de solutions partiellement composées de ceux-ci) subissent généralement plus les licences qu'ils ne les choisissent : leur seule préoccupation étant que les briques logicielles puissent aisément se combiner entre elles. Il n'y a donc pas d'usage du droit des marques à l'égard des produits, mais surtout une expertise approfondie des combinaisons de licences leur permettant de s'assurer de la faisabilité du projet et de s'engager sur ce point auprès de leurs clients et dans leurs contrats (les clients demandant aujourd'hui la garantie de telle compétence ainsi que la livraison de certaines études précises sur ces questions). Transférant généralement un logiciel qu'il n'a pas (à priori) lui-même développé, mais seulement adapté au besoin de son client, l'intégrateur est lui-même limité par sa qualité de licencié à l'égard des auteurs des logiciels libres sur lesquels il intervient, et, ne pouvant céder plus de droits qu'il n'en possède lui-même, il communiquera à ses clients cesdits logiciels sous leur licence *open source* d'origine (ou toute autre licence compatible).

En ce qui concerne leurs contributions spécifiques, les pratiques sont multiples, mais il semblerait finalement que le plus avantageux pour l'ensemble des parties soit que la titularité des droits soit conservée par celui qui maintient et édite le logiciel (généralement l'intégrateur). Ainsi celui-ci cède l'ensemble de ses développements sous licence libre au client et conserve la titularité des droits. Ce compromis reste fidèle au procédé de création *open source* dans lequel l'auteur reste titulaire de droits et cède sous licence *open source* de façon non exclusive, afin de

<footnote n="1">1. Voir GREEN (Thomas C.), « Ballmer : 'Linux is a cancer' ; Contaminates all other software with Hippie GPL rubbish » (*The Register*, 2001), qui cite les propos de Steve Ballmer lors d'une interview pour le *Chicago Sun-Times* : « Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. »</footnote>
permettre tant au client de mutualiser les résultats de la prestation, qu’à l’intégrateur de valoriser les travaux par tous moyens appropriés <fnref n="1" />.

### 3.2.1.1.c Les constructeurs

Concourant à la création d'une industrie réunissant innovations matérielles et logicielles, les constructeurs (tels HP, Intel, IBM ou Dell) embarquent de plus en plus de logiciels et se rapprochent à ce titre des différents projets de logiciels libres (et l'open cloud) — devenant de jour en jour des contributeurs majeurs dans les projets OS (Linux, Busybox, etc.) au point de faire de leurs contributions respectives des éléments différenciant.

En effet, de tels logiciels permettent, en plus d'écorner certains monopoles, de réduire le coût de développement, d'optimiser l'interaction entre les logiciels et leurs matériels (ou *a minima* d'assurer la compatibilité avec leur produit).

À l'instar des intégrateurs, les constructeurs sont généralement désireux d'une compatibilité maximum entre les licences des logiciels *open source* utilisés, même s'ils peuvent avoir intérêt à définir certaines politiques : favorables à certaines licences permissives (par exemple dans le secteur du mobile, avec la diffusion d'Android sous licence Apache); ou exemptes de certaines obligations (par exemple, de licences de brevets) qui seraient incompatibles avec leur politique plus vaste relative à la propriété intellectuelle.

De nombreux secteurs sont concernés par une certification (ou qualification, cf. *supra*) de leur produit : l'open source est pour eux une solution qui permet de mutualiser les frais de développement tout en conservant le bénéfice personnel de la certification de leur version.

### 3.2.1.1.d Les utilisateurs

Contrairement aux logiciels traditionnels, les logiciels libres sont généralement accessibles à toutes catégories d'utilisateurs, dans les

<footnote n="1">1. L'intégrateur se révèle être le mieux disposé pour faire évoluer le produit et assurer la pérennité de son développement au travers, notamment, d'un reversement systématique au bénéfice des communautés. Sa situation d'intermédiaire lui permet par ailleurs d'être idéalement placé pour favoriser les échanges indirects de contributions entre ses différents clients — l'évolution des solutions étant aussi dans l'intérêt de ceux-ci, tout le monde profite de cette collaboration.</footnote>
mêmes conditions. Ainsi, libre à chacun (individu, société, organisme à
but non lucratif, collectivité ou État) de s'installer un forum (Phpbb), un
wiki (Mediawiki), voire un Facebook-like (Elgg) ou un Youtube-like (Me-
diacore), etc.

Les utilisateurs d'un projet *open source* sont particulièrement sensibles
à la licence du projet : l'impact de cette dernière étant fonction de l'util-
isation qu'ils en font (par exemple, si des services sont proposés sur la
base de ces logiciels libres) voire de leur forme (société, GIE, association,
etc.).

Lorsqu’il s’agit de sociétés « utilisatrices poussées », elles peuvent faire appel à des intégrateurs ou consultants pour mettre en place les solutions *open source* dans leur SI — ce qui les place dans une situation analogue aux utilisateurs standards, avec quelques spécificités relatives aux contrats passés avec ces prestataires. En l’absence de tels intermédiaires, il est aussi possible de se tourner vers des solutions d’assurance (telle l’offre américaine Open Source Risk Management proposée par la société OSRM).

Néanmoins, l'impact de l'utilisation des logiciels libres peut être lié à des politiques stratégique ou économique particulières : par exemple en cas d'externalisation quasi totale du support, maintenance, veille *open source* à partir d'un SI essentiellement composé de logiciels libres, ou, au contraire, lors de la mise en place d'une entité informatique interne qui gère le déploiement de solutions en logiciels libres au sein de toute la structure (avec une vraie logique de service et d'édition). Dans toutes ces situations, les utilisateurs veillent à ce que les développements réalisés pour leur compte soient ensuite mis à disposition du (et si possible intégrés dans) projet *open source* — gardant à l'esprit qu'il est généralement aussi cher de maintenir un composant logiciel dans la durée que de le faire développer.

3.2.1.1.e Les organisations à but lucratif et non lucratif

En plus des acteurs précédents, on retrouve plusieurs types de groupe-
ments sur lesquels s'appuient les projets libres et open source : ils
sont commerciaux (tels les sociétés ou GIE) ou non (associations ou
fondations), avec une personnalité morale ou non (association de fait
— fréquent lors du lancement d'un projet — ou consortium), voire multiples (tel OpenOffice.org qui reposait sur l'association TeamEV, mais dont les droits de PI étaient gérés par Sun puis Oracle).

Les fondations et autres organisations à but non lucratif occupent une place prépondérante dans le système du Libre. Elles peuvent être classées en deux catégories<fnref n="1" /> : celles qui concourent directement au développement d'un logiciel et celles qui y concourent indirectement.

Les premières sont productrices de code, de créations (qu'elles soient ou non titulaires de droits) :

- organisations avec base de code diversifiée (Linux Foundation, Apache Foundation, Eclipse Foundation, OW2 Consortium, Adullact);

- organisations supportant une ligne de produits (Libreoffice, Mozilla.org, VideoLan, Genivi, Open Handset Alliance);

- communautés orientées technologie (FreeBSD, Ruby, Rails, Joomla).

Les secondes concourent indirectement au développement de projets (ne produisent pas de code *per se*) :

- organisations fournissant des ressources organisationnelles (administratif, hébergement, conseil, etc.) aux projets (Software Freedom Conservancy, Eclipse, Linux Foundation);

- organisations fournissant des ressources légales (Free Software Foundation, Open Source Initiative, Software Freedom Law Center, VVL);

- organisations de standards (W3C, IEEE, ODF Alliance, OSGI Alliance, ETSI);

- organisations de lobbying et de promotion (April, Aful, Framasoft, Open Source for America, Ubuntu-fr, Fedora Fr, Adullact, etc.)

### 3.2.1.1.f Les centres de recherche

L'implication et l'utilisation des logiciels libres par les centres de recherche sont si importantes qu'il est impossible de ne pas considérer

<footnote n="1">1. Distinction basée sur les travaux présentés par Jean-Pierre Laisné lors de l'OWF 2011.</footnote>
les centres de recherches <fnref n="1" /> (et, dans une moindre mesure les universités <fnref n="2" />) comme des acteurs à part entière du système que nous décrivons (notamment pour au regard de leur recherche à application industrielle).

Leur apport est néanmoins limité aux domaines directement liés à leur activité de recherche et ils ne prennent ainsi qu’un rôle passif dans l’animation des communautés ou la proposition de services. Ainsi, et même si la situation semble évoluer, on s’aperçoit que leur action se limite aujourd’hui au stade qui précède la valorisation de leurs projets Open Source : cette dernière phase étant réalisée par des sociétés existantes, partenaires ou non, ou nouvellement créées (le transfert en faveur de *spin off* se multiplie).

### 3.2.1.2 Les relations entre le projet et les acteurs du système

Enfin, il est fréquent que l’intégrateur soit tenu de contribuer aux projets *open source* en fournissant les modifications réalisées pour le client : il s’agit là d’une sécurité tant pour le client qui s’assure ainsi que les versions ultérieures du projet intégreront ces développements (et qu’il n’aura ainsi pas à le payer une seconde fois) que pour l’intégrateur qui ne souhaite généralement pas endosser la responsabilité d’un éditeur.

Chaque relation mérite néanmoins un examen dédié : entre un projet et ses utilisateurs (3.2.1.2.a), entre un projet et ses contributeurs (3.2.1.2.b), entre le projet et les autres groupements (3.2.1.2.c) et entre les sociétés (3.2.1.2.d).

#### 3.2.1.2.a Les relations entre un projet et ses utilisateurs

Les utilisateurs sont les premiers destinataires des logiciels. Ils contribuent généralement en livrant des retours sur leur expérience. Ils sont aussi souvent les premiers générateurs de valeur, le nombre d'utilisateurs d'un logiciel étant généralement un facteur multipliant la valeur du logiciel vis-à-vis de ceux qui ne l'utilisent pas encore. La licence utilisée sur l'œuvre logicielle est souvent le seul document les intéressant et, au sein

<footnote n="1">1. L'INRIA et le CNRS étant les deux centres français les plus actifs sur le sujet.</footnote>

<footnote n="2">2. L'Université de technologie de Compiègne (UTC) est ainsi à l'origine de nombreux projets Open Source dans le domaine du logiciel (scenari-platform pour n'en nommer qu'un) et en dehors.</footnote>
de ce dernier, seuls les droits d'utilisation les concernent véritablement. Dans le cadre de certains projets, il arrive que des limitations s'ajoutent, en raison, par exemple, de composants commerciaux : l'utilisateur y consentira alors lors du téléchargement, de l'exécution ou de l'installation du logiciel.

Ces utilisateurs peuvent néanmoins devenir clients, contributeurs et/ou partenaires potentiels, voire concurrents du projet, et il est toujours utile de prévoir à leur attention des documents les informant de leurs droits et devoirs au terme de la licence, des conditions d'utilisation des marques, logos et noms du projet, voire, s'il y a lieu, du processus leur permettant de contribuer au projet (ainsi que la politique du projet en matière de propriété intellectuelle).

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

### EXEMPLE PRATIQUE

Par application d'un effet de réseau, les logiciels libres gagnent en intérêt et fonctionnalité au fur et à mesure que la communauté d'utilisateurs (et de développeurs) s'en approche. Ainsi, les utilisateurs de téléphones Android ont formé des projets, tel le projet CyanogenMod, qui distribue des ROM optimisées pour de nombreux portables, permettant de bénéficier des dernières versions d'Android sur les téléphones qui ne sont plus maintenus par leur constructeur. Cela grâce à la version communautaire du système d'exploitation Android qui est publiée par Google sous licence Apache (et sans embarquer les applications propriétaires telles google maps, voice, search, etc.).

### 3.2.1.2.b La collaboration avec les contributeurs

Les caractères évolutifs et participatifs étant l'essence même du logiciel libre, il n'est pas exclu que certains contributeurs souhaitent apporter leur lot de développements (envisagés sur un mode projet, en constante amélioration).

Dans la situation d'un éditeur (ou la communauté qui revêt ce rôle) déjà identifié sur le projet, il peut proposer plusieurs schémas de contribution qui conditionneront la reprise du code au sein du projet :
- lorsque ces développements concernent le logiciel lui-même, il est souvent demandé une cession globale (ou suffisante) des droits (il est aussi fréquent, au sein des projets commerciaux, que les sociétés rachètent ou réécrivent les contributions qui les intéressent);

- lorsque ces développements portent sur des modules communautaires, les solutions sont généralement liées au choix initial de la licence du projet (mais il est aussi possible que l'éditeur n'héberge ou ne maintienne la contribution qu'en cas de cession de droits ou d'une politique de licence précise).

Dès les premières contributions au projet, il devient nécessaire d'avoir une réflexion pointue sur la gestion de la propriété intellectuelle, donnant éventuellement naissance à une politique en la matière, que celle-ci soit très protectionniste ou au contraire très ouverte.

→ *Les enjeux et problématiques liés à la détention des droits de propriété intellectuelle*

La question de la détention des droits de propriété intellectuelle, de la « titularité », est d'une importance variable dans un projet *open source*. En fonction de la licence (surtout si cette dernière est *copyleft*) et du type de projets, la détention peut être cruciale en ce qu'elle confère un certain contrôle sur le projet (par exemple pour toutes les sociétés qui pratiquent les doubles licences, dit *dual licensing*). Cette détention peut au contraire être très faible lorsque la licence choisie est très ouverte, lorsque le projet est soumis aux licences de composants *open source* qu'il intègre, ou encore lorsque trop de contributeurs se partagent cette titularité.

Pour remédier à cette division de la propriété, de nombreux projets re-
courent à des politiques de licences spécifiques, de cession de droits ou de
« copropriété libre » (chaque copropriétaire pouvant exploiter librement
les droits détenus) : par le biais de *Contributor License Agreements*, *Copy-
right Assignment* ou de *Joint Copyright* qui conditionnent généralement la
possibilité pour un développeur de voir sa contribution être acceptée dans
un projet ou, dans le cadre professionnel, pour un client qui souhaite que
ses développements soient maintenus par le projet. C'est une politique que
l'on retrouve à l'égard des salariés d'une société — qui sont aujourd'hui
les principaux contributeurs, sur tout type de contenu<fnref n="1" />.

<footnote n="1">1. Pour rappel, la dévolution légale des droits en faveur de l'employeur ne joue qu'en présence d'une création salariale logicielle. Voir notamment BENSAMOUN (Alexandra),</footnote>
Inversement, afin de se prémunir face à un éventuel contrôle sur un logi-
ciel libre du fait de la détention des droits par un ou plusieurs, certains
peuvent chercher à bloquer l'exercice de ces prérogatives en imposant
une convention de copropriété (ou d'indivision) qui lie les parties quant à
l'exploitation conformément à la licence open source du projet <fnref n="1" />.

⇒ *Les Contributor License Agreement, Copyright Assignment ou de Join Copyright*

Il est ainsi fréquent que le nombre de contributeurs (et donc de titulaires de droits) dépasse la dizaine voire le millier. Leur anonymat ainsi que leur dispersion géographique sont parfois des obstacles infranchissables pour la suite du projet : l'absence de consentement d'un seul interdit toute décision concernant la création dans son ensemble et la seule échappatoire reste alors de supprimer les contributions pour lesquelles il manque cette autorisation.

C'est pour cette raison que, très tôt, certains développeurs ou organ-
ismes, telle la FSF, ont mis en place des documents qui permettent aux
contributeurs d'un projet soit de leur céder leur copyright — pour cen-
traliser la prise de décision (notamment le changement de licence<fnref n="2" />), la
gestion, et la défense de l'œuvre — soit de leur consentir une licence très
large. On parle de *Copyright Assignement* en présence d'un vrai trans-
fert (cession exclusive) de droits, la structure devenant la seule et unique
titulaire de droit. On parle de *Contributor License Agreement* lorsque le
contrat opère une cession (non exclusive) très large au profit de la struc-
ture sans que le contributeur soit lui-même dessaisi de ses prérogatives.
Ils sont généralement doublés d'un second document à destination des
employeurs lorsque les contributions sont réalisées dans un cadre salarial.
Chacun de ces contrats est rédigé en fonction de l'équilibre particulier du
projet, de l'implication des contributeurs dans celui-ci et de la confiance
dont bénéficie l'organisme collecteur.

<footnote>« La titularité des droits patrimoniaux sur une création salariée : du paradis artificiel à l'artificie du paradis », dans *Revue Lamy Droit de l'Immatériel*, n°67, 2011.</footnote>

<footnote n="1">1. C'est notamment le choix pris pour l'ENT Lilie commandée par la Région Île-de-France.</footnote>

<footnote n="2">2. Plusieurs situations de blocage peuvent être prises comme exemple : le changement de licence du contenu du site de Debian au profit d'une licence compatible avec la GNU GPL, l'ajout des licences GNU LGPL, et sur le navigateur Firefox (en faisant une triple licence MPL/LGPL/GPL) ou encore le noyau Linux qui utilise actuellement volontairement la seule version 2 de la GNU GPL.</footnote>
Devant le constat de la multiplicité, de la diversité et de la complexité de ces documents, de nombreux industriels, professionnels et associations du libre ont formé un groupe de travail pour plancher sur la rédaction de documents types à destination des communautés et entreprises : leur épargnant un travail d'écriture en même temps qu'ils épargnent à leurs utilisateurs-contributeurs un travail de lecture (et de compréhension). Le projet Harmony<fnref n="1" />, s'il permet de mutualiser les politiques au-paravant éclatées<fnref n="2" />, ne résout néanmoins pas la difficulté du rapport que cela génère entre les parties, les uns voulant un engagement fort des contributeurs — notamment par le biais de clauses de responsabilité et de garantie —, les autres voulant un engagement fort des collecteurs — notamment quant à l'exploitation des contributions.

Par ailleurs, ces contrats ne sont réellement fiables qu'en cas de certitude quant à l'identification du contributeur. C'est la raison pour laquelle la Free Software Foundation (mais Mozilla aussi) envoie un contrat papier qu'il convient de retourner signé. De même, l'Eclipse Foundation à mis en place un processus complet visant à sécuriser les relations entre les différents acteurs (Eclipse Legal Process<fnref n="3" />).

### 3.2.1.2.c La collaboration avec d'autres groupements

Il est très fréquent que les différents projets ou organisations se réunissent pour travailler de concert sur des projets communs : soit qu'ils aient des compétences ou expériences complémentaires, transverses (tels les aspects juridiques liés aux licences et aux brevets), soit qu'ils mettent en commun leurs forces pour le développement d'une solution plus vaste.

### 3.2.1.2.d La collaboration entre sociétés

Une société éditrice de logiciels qui met en place son modèle commercial prend généralement en considération ses partenaires, ses concurrents et ses clients. Il est assez simple de séparer les uns des autres : la société est liée par contrat avec ses partenaires (distributeurs, revendeurs, etc.) et ses clients (contrats souvent négociés pour les premiers et imposés pour les

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

<footnote n="2">2. Voir MEEKS (Michael), « Some brief thoughts on Project Harmony », 2011 (disponible sur http://people.gnome.org).</footnote>

<footnote n="3">3. http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf.</footnote>
seconds), et n'entretient que des relations contractuelles exceptionnelles avec ses concurrents.

Les licences libres modifient cet ordre puisqu'elles s'adressent autant aux individus — personnes physiques — qu'aux entreprises commerciales. Ainsi, les concurrents comme les partenaires pourront en revendiquer le bénéfice, leur permettant notamment d'utiliser ou de proposer des services autour des logiciels édités par un autre avec pour seule limite le respect de la licence libre du projet et éventuellement de la politique de marques ou de brevets.

On peut y voir un paradoxe puisque les partenaires risquent d'être « moins libres » que les concurrents, du fait de clauses supprimant le bénéfice de la licence, qui peuvent être comprises dans leurs engagements avec l'éditeur<fnref n="1" />.

→ *Gérer les risques de fork*

On parle de fork lorsqu'une partie d'une communauté décide de s'éloigner du projet principal pour en développer une version différente. De manière générale, les forks préjudicient à tous : l'ancienne et la nouvelle communautés, les utilisateurs et les projets.

C'est la raison pour laquelle il est généralement conseillé d'augmenter l'investissement dans un projet plutôt que d'initier son propre projet<fnref n="2" />.

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

### DE STAROFFICE À LIBREOFFICE

Récemment, la communauté d'OpenOffice.org s'est détachée du projet pour proposer sa propre version (nommée LibreOffice) au sein d'une fondation créée à cet effet : la Document Foundation. Cette dernière abrite le code de LibreOffice, mais aussi de tout autre produit qui souhaiterait dériver de ses sources. Lors de la formation du projet OpenOffice.org en 2000, la mise en place d'une telle fondation avait été annoncée par Sun. Dix ans après, et pour se protéger de la nouvelle politique commerciale imposée

<footnote n="1">1. Clauses d'usage dans les contrats de partenariats proposés par MySQL, Ingres, Talend, etc.</footnote>

<footnote n="2">2. Voir notamment la présentation de PROUTY (Tim), « Becoming a Samba Developer », Isilon Systems, 2009 (disponible sur http://sambaxp.org).</footnote>
par Oracle (qui a racheté Sun) sur ses produits, les principaux responsables communautaires du projet ont pensé qu'il était temps de monter une fondation vraiment indépendante. Il n'y a pas de rupture avec le projet, simplement une communauté suffisamment mature pour prendre son destin en main et ne plus dépendre d'un décideur unique. LibreOffice (ou LibO) est une suite bureautique, développée par la fondation, qui s'appuie sur les sources d'OpenOffice.org et contient des patchs fournis par ses contributeurs (les plus assidus étant Novell, Red Hat et Debian, mais il y en a de plus en plus chaque jour).

Quelques mois après ces évènements, et pour répondre aux fortes demandes d'IBM, Oracle a « donné » son code et ses marques à la Fondation Apache qui distribue ainsi OpenOffice.org sous licence Apache.

Il faudrait certainement se projeter dans quelques années pour mesurer l'impact de ce fork (sur l'entreprise, les communautés, voire, plus globalement, le projet global), mais beaucoup y voient une excellente nouvelle et de nombreux concurrents d'Oracle commencent à retrouver un intérêt dans le développement de cette version dont le succès dépendra de tous et non plus majoritairement d'une société (ne serait-ce que par la détention du patrimoine immatériel). Gageons aussi que cette « insurrection » sera perçue comme une épée de Damoclès pour toute société qui chercherait à trop contrôler un projet qui se veut ouvert. Éspérons aussi que les deux projets parviennent à mutualiser leurs efforts.

### 3.2.2 Organiser la diffusion (accompagner l'ouverture du code)

L'organisation de la diffusion est souvent la clé qui assure la pérennité d'un projet, sa stagnation ou son abandon. Malheureusement, il n'y a pas une organisation idéale, une structure parfaite, mais uniquement des cas d'espèce. Pour une entreprise, cela implique de se reposer sur un ensemble
hétérogène de personnes au sein de l'entreprise qui perçoivent les enjeux de l'open source et qui s'assure du respect des licences.

Ainsi, que ce soit pour ce seul projet ou pour une multitude, il est nécessaire d'entamer une telle réflexion et, une fois les besoins identifiés, d'organiser l'accompagnement — que ce soit en interne ou en externe<fnref n="1" />.

### 3.2.2.1 Gérer les licences libres

La mise en place d'une bonne gestion des licences libres passe nécessairement par une étude des enjeux pour la société et/ou le projet (3.2.2.1.a), la définition des besoins (3.2.2.1.b) et l'organisation de l'accompagnement (3.2.2.1.c).

#### 3.2.2.1.a Mesurer les enjeux liés au respect des licences

Quelles sont les sanctions juridiques, mais aussi commerciales ou marketing, susceptibles de découler du non-respect des licences libres ? De nombreuses sociétés, pourtant importantes, ont ainsi dû baisser l'échine face aux actions des communautés qui leur reprochaient l'absence de prise en compte des licences sur des composants utilisés (ce qui inclut BestBuy, Westinghouse et Cisco). Ajoutons que les titulaires de droits, généralement seuls aptes à faire respecter leur licence, ont tendance à les accompagner l'utilisation de leur logiciel open source).

En effet, tout non-respect de licence emporte le risque de se voir qualifié de contrefacteur : tout usage n'entrant pas dans le cadre de la licence est un usage non autorisé et donc contrefaisant. Par ailleurs, en cas de violation, par certains usages de droits de propriété intellectuelle, ou plus fréquemment, du non-respect du formalisme de la licence, celle-ci sera généralement automatiquement résiliée et l'ancien licencié se trouvera rapidement contrefacteur pour tout usage de la création. Cela vaut pour l'entreprise, mais aussi pour tous ses clients et partenaires qui redistribuent les logiciels « non conformes » (on perçoit d'ailleurs une telle prise de conscience en Asie).

<footnote n="1">1. Voir le Guide Open Source, op. cit. (http://guideopensource.info).</footnote>
Au minimum (mais ce n'est pas toujours vrai), il est possible de considérer que lors de l'utilisation d'un composant *open source* sans modification, la simple redistribution (tel qu'il a été reçu) devrait suffire. Au contraire, une démarche plus lourde serait nécessaire en cas de modification. La solution la plus fiable est néanmoins de mettre en place un formalisme générique, construit sur le modèle de la licence la plus contraignante, de manière à ce que son respect suffise pour remplir les attentes classiques de l'ensemble des licences. Enfin, des procédures particulières peuvent être élaborées afin de prendre en compte les spécificités des utilisateurs (professionnels du métier ou non, de nationalité précise, etc.) ou du domaine d'exploitation (embarqué, SaaS, etc.).

### 3.2.2.1.b Définir les besoins

En fonction des enjeux, plusieurs besoins peuvent être identifiés :

- la mise en place de bonnes pratiques (*guidelines*). Il s'agit ici de l'édition de procédures relatives au respect du formalisme des licences ainsi qu'une procédure associée à l'usage de toutes nouvelles licences/composants *open source*. Celles-ci permettraient par ailleurs de rendre transparente la gestion des droits de propriété intellectuelle tant à l'intérieur qu'à l'extérieur de la société;

- la mise en place d'une veille relative aux licences, pratiques afférentes et outils d'audit de codes (il est en effet important de rester connecté aux usages qui se développent, voire d'y confronter ses nouvelles pratiques, afin de se tenir informé tout en conservant un regard critique);

- la création d'un support relatif aux questions liées à l'utilisation des licences ou autres questions juridiques. Il s'agit ici des problématiques liées à l'ajout de licences et aux enjeux de compatibilité, mais un support juridique étendu peut permettre de résoudre certaines difficultés liées à la propriété intellectuelle ou à d'autres dispositions légales (comme l'exportation de certains produits);

- une procédure d'audit de codes. Pour ce faire, il peut être très utile d'utiliser les outils réalisés pour faciliter ces missions : notamment le logiciel *open source* Fossology qui peut permettre un examen systématique de code et l'outil commercial Protex de la société Black
Duck qui offrira une analyse beaucoup plus poussée<fnref n="1" />. Les deux solutions<fnref n="2" /> peuvent utilement être combinées : la première étant systématique et la seconde préalable à certaines mises à dispositions ou distributions du code ;

- la labellisation de composants et de licences. Cette politique de labellisation permettrait d'accélérer la réutilisation de composants, modifiés ou non, déjà audités et considérés comme conformes à la politique du groupement (techniquement et juridiquement), alors que le suivi d'une procédure particulière obligatoire accompagnerait l'utilisation de composants non encore certifiés. La même pratique pourrait être élaborée au profit des licences libres et *open source a priori* considérées comme « conformes à la politique du projet/du groupement ». Une procédure particulière serait alors attachée à l'acceptation de composants *open source* soumis à d'autres licences (de nombreuses sociétés ont ainsi constitué en leur sein de tels catalogues de composants *open source*, éventuellement aidées pour cela par des logiciels comme l'outil *Code Center* de la société Black Duck).

### 3.2.2.1.c Organiser l'accompagnement

À ce stade, il s'agit de définir quelles sont les tâches qui peuvent être externalisées et quelles sont celles qui doivent être conservées en interne.

→ La création d'une structure ad hoc

Une externalisation totale semble difficile en raison de l'interpénétration des notions juridiques et techniques d'une part, et de la criticité de ces enjeux d'autre part. Tout au plus est-il possible de penser à l'intervention de tiers quant à l'audit initial (en cas de solution préexistante), à l'édition d'une gouvernance, voire en préalable à toute distribution — pour le reste, une personne, voire une équipe interne, doit être référente afin de résoudre (ou transmettre à cette fin) les difficultés qui se présentent à elle et « infuser » les bonnes pratiques. Une solution intermédiaire pourrait être de rejoindre une structure plus grande (comme une fondation) qui permette de mutualiser une partie de la fonction.

<footnote n="1">1. La société éditrice propose un certain nombre d'offres pour les projets communautaires — à commencer d'ailleurs par l'Eclipse Foundation.</footnote>

<footnote n="2">2. La liste n'est néanmoins pas exhaustive et d'autres produits similaires existent, édités par des sociétés américaines (telles Palamida, OpenLogic ou ProteCode) ou françaises (comme Antelink).</footnote>
L'internalisation elle-même peut prendre différentes formes, qu'il s'agisse de créer une entité *ad hoc* (référent *open source*, comité *open source*, etc.) ou de modifier les structures existantes pour y intégrer ces besoins, notamment par l'intégration de règles générales, comme la définition de politique en matière de licences, la validation de paquets logiciels, etc.. De nombreux paramètres entrent dans cette équation, mais il est généralement conseillé, lorsque la taille le permet, de commencer par la mise en place d'entités autonomes, de sorte qu'elles s'éclipsent une fois la nouvelle culture infusée et les réflexes intégrés — au risque sinon de buter sur la résistance des collaborateurs (surtout dans le cas du passage d'une politique de licence traditionnelle à une politique ouverte : la longue domination du paradigme antérieur, engendrant de nombreux réflexes et habitudes profondément ancrées, peut entraîner le rejet irrationnel de ce mode alternatif d'édition).

Quelle que soit l'organisation choisie, il est nécessaire que cet accompagnement s'appuie sur des relais locaux (*scouts*), des correspondants aptes à faire remonter et redescendre les informations utiles.

À la fois structure de référence et structure inter-services, un tel organisation permet de mutualiser le travail d'accompagnement, de rationaliser les décisions, de définir des politiques globales et d'automatiser le traitement des questions. Par ailleurs, pour qu'une telle structure puisse être suivie d'effet, il est nécessaire qu'elle soit facilement joignable, qu'elle bénéficie d'un pouvoir décisionnel et, dans l'idéal, qu'elle soit suivie par un membre de la direction. Enfin, elle seule doit être consultée pour autoriser et décider de l'utilisation de briques logicielles sous licences libres *open source* et de la diffusion sous de telles licences (quitte à ce que ses décisions soient avalisées par la direction).

→ *Gérer les contributions au sein de la société*

Comme nous l'avons vu, les licences s'étendent graduellement à l'ensemble des droits de propriété intellectuelle. Une vigilance accrue s'observe donc chez les sociétés qui mixent une culture libre (*open source*) et propriétaire : l'enjeu est alors de délimiter très précisément (généralement par des politiques *open source* très soignées), voire de cloisonner, les portefeuilles de droits relatifs au projet afin de s'assurer que l'activité *open source* ne vienne pas impacter et dévaloriser certains droits de propriété intellectuelle qui restent très attractifs pour la société.
C'est ce type d'attention qui explique par exemple la renonciation au bénéfice de la dévolution légale de droits relative à certains développements qui doivent être reversés à des projets placés sous des licences trop contraignantes (au profit des salariés qui conservent ainsi leurs droits) <fnref n="1" />. De la même façon, une responsabilité particulière pèse sur les services juridiques qui doivent s'assurer que les engagements contractuels avec les sous-traitants, fournisseurs, etc. soient bien respectés et maintenus lors de la diffusion sous licence libre et *open source*.

Pour une société, il arrive parfois qu’il soit plus simple, voire nécessaire, d’envisager un cession de droits au profit de projets qui assureront le maintient et l’intégration des différentes contributions. Dans cette solution, tant l’entreprise que le salarié seront généralement signataires d’un document de cession de droits au profit du projet. Il peut aussi être envisagé, lorsque la mission du salarié l’exige ou en raison du contrat particulier qui le lie à la société, que celle-ci lui délègue le pouvoir de mettre sous licences libres les contributions réalisées dans le cadre de ses missions salariales : le risque est faible pour l’entreprise lorsque celui-ci travaille dans un tel environnement, et cela lui permettra de sécuriser les contributions de son salarié vis-à-vis des communautés et des projets dans lesquels il intervient.

→ Faire travailler ensemble les différentes équipes

De façon pragmatique, lorsque l’on exploite du contenu sous licence libre en entreprise ou ailleurs, il est nécessaire d’adapter la procédure de validation juridique et contractuelle, l’analyse devant être réalisée autant en amont des projets qu’en aval. Un travail est nécessaire dès en amont afin de déterminer la faisabilité juridique des propositions techniques et s’assurer que les engagements puissent être respectés (en gardant en tête le leitmotiv : « on ne peut donner plus de droits que l’on en possède », c’est d’ailleurs cette seule idée qui ressort des contentieux français ayant mis en jeu la GNU GPL). Enfin, une dernière étude juridique est nécessaire en aval pour confirmer le choix final de la licence et procéder, s’il y a lieu, aux ajustements contractuels en fonction du produit, des attentes et bien évidemment des licences en présence.

<footnote n="1">1. On peut ici citer l’exemple d’HP vis-à-vis de la GNU GPL v. 3 (qui pourrait impacter la valeur de son portefeuille de brevets).</footnote>
Ainsi, ce travail ne peut être mené que conjointement entre l'équipe
technique, seule apte à fournir les informations détaillées sur le logiciel,
et l'équipe juridique. Les données brutes nécessaires à l'étude juridique
sont : le détail des briques logicielles utilisées, leur(s) licence(s) respec-
tive(s) (comprenant leur version, et toute autre information influant sur
ces licences : restriction, interprétation, exception, etc.), et enfin les inter-
actions existantes entre chacune de ces briques (en pratique, un schéma).
Un dialogue s'établit par la suite pour affiner les derniers détails, et de
nombreuses navettes permettront de compléter l'analyse.

D'une manière plus générale, le succès d'une politique active en faveur
de l'open source repose sur une implication de l'ensemble des collab-
orateurs dans le processus de restructuration et une montée des compé-
tences de ces derniers afin qu'ils comprennent et partagent ce nouveau
paradigme : par l'organisation de formations, la rédaction et la mise à
disposition des informations qui leurs sont utiles, l'organisation de leurs
contributions au sein de chartes (contribution, développements, processus
de validation, etc.).

→ S'équiper avec de bons outils

Enfin, l'usage de certaines solutions logicielles peut simplifier, voire ap-
profondir<fnref n="1" /> cette mission, en automatisant l'audit de code<fnref n="2" /> voire la gestion
au quotidien de la base de code validée. Tous les outils ne sont pas équiva-
lents, et tous n'ont pas vocation à être utilisés au même moment ou par les
mêmes personnes (dans le cadre de *due diligence*, les audits demanderont
ponctuellement l'utilisation d'outils très poussés, alors que la vérification
automatique et journalière des développements réalisés pourra être plus
superficielle).

Enfin, le projet *Software Package Data Exchange*<fnref n="3" /> (SPDX<fnref n="4" />) a récem-
ment introduit un format standard pour communiquer les éléments, les

<footnote n="1">1. Par exemple avec une comparaison du code du projet avec celui de leur base.</footnote>

<footnote n="2">2. Voir à cet égard les solutions décrites dans le *Guide Open Source*, partie 1.2.2. « Description du code source », op. cit. .</footnote>

<footnote n="3">3. Le projet SPDX (pour Software Package Data Exchange) est un format standard pour la communication des composants, licences et mentions légales associées à la distribution d'un logiciel. Le site a été réalisé sous la direction de la Linux Foundation, avec la participation de nombreuses sociétés parmi lesquelles Alcatel-Lucent, Antelink, Black Duck Software, Canonical, HP, Micro Focus, Motorola Mobility, nexB Inc, OpenLogic, Palamida, Protecode, Source Auditor, Texas Instruments et Wind River.</footnote>

<footnote n="4">4. http://spdx.org.</footnote>
licences et droits d'auteur associés à un logiciel (et ainsi faciliter la prise de connaissance des obligations et le respect des licences). Ainsi, chaque société ayant réalisé ce travail d'audit pourra dorénavant accompagner la livraison de son logiciel d'un fichier SPDX qui recensera tous les composants utilisés et leur(s) licence(s).

### 3.2.2.2 Gérer les autres aspects juridiques

Comme vu précédemment, différents documents peuvent être mis en place pour accompagner l'organisation vis-à-vis des tiers et notamment pour donner un cadre formel à la collaboration (3.2.2.2.a), et la rédaction d'une politique en matière de marque précise à l'intention des tiers et des licenciés (3.2.2.2.b).

#### 3.2.2.2.a Structurer le projet

Que le projet soit ouvert ou fermé, la mise en place d'un cadre propice à son développement et son exploitation nécessite une réflexion quant à l'organisation du groupement autour du projet et vis-à-vis des tiers.

Tant que l'organisation du projet est suffisamment attractive pour motiver des contributions extérieures et qu'il répond aux contraintes des mainteneurs, il n'y a aucune raison de changer celle-ci.

Si le projet souhaite s'ouvrir de manière à impliquer plus de contributeurs, plusieurs schémas peuvent être construits pour organiser les développements collaboratifs, avec leurs avantages et inconvénients (création d'une entité juridique distincte, mise en place d'un consortium, l'appu d'un partenaire leader — voire une absence délibérée). Notons que la mise en place d'un consortium est la solution la plus légère (généralement la première utilisée par les sociétés qui cherchent à collaborer en raison de la faiblesse de l'engagement), éventuel premier jalon d'une autonomisation quasi-systématique des projets dès lors qu'ils gagnent en contributeurs.

Dans l'hypothèse de la libération d'un projet, il est préférable de strukturer un minimum dès le début (donner simplement l'accès au code et le processus pour contribuer) quitte à mettre ensuite en place une organisation adaptée.
Enfin, la gouvernance des groupements est généralement découpée en-
tre les aspects stratégiques, les aspects techniques et les aspects commu-
nication/sensibilisation (lien avec les utilisateurs et la communauté).

3.2.2.2.b Les politiques en matière de marque

Le droit des marques retrouve toute sa noblesse dans l'industrie de
l'open source, puisqu'il reste bien souvent le meilleur garde-fou pour em-
pêcher certains types d'exploitation d'un projet qui est pourtant librement
disponible (notamment en termes d'image, mais aussi de comportement
commercial). Néanmoins, il est parfois nécessaire de relativiser l'usage
qui peut en être fait au regard des prérogatives qu'il confère à son titu-
laire, car la tentation est grande pour certains d'essayer de récupérer là un
contrôle qu'ils ont abandonné en faisant le choix de l'open source.

Ainsi, les politiques en matière de marque sont généralement des docu-
ments publics qui précisent quelles sont les marques détenues par le projet
et les conditions de leur utilisation : une seule marque pouvant être utilisée
différemment selon le contexte (lorsque la création est modifiée ou non)
ou plusieurs marques pouvant être utilisées pour différencier les usages
permis sur chacune (par exemple en autorisant seulement les partenaires
à utiliser la marque figurative).

Les meilleurs exemples existants, à cet égard, sont ceux des projets du
type OpenOffice.org / LibreOffice, Firefox, GNU/Linux, etc., qui réunis-
sent à la fois entreprises, associations et fondations, contributeurs indi-
viduels et le grand public.
III

Quelques études de
licences libres
<figure><img src="image_54.png" /></figure>
La diversité des licences s’explique par la diversité des projets et des modèles commerciaux qui suivent le courant de l’open source. On observe néanmoins une forte parenté entre ces licences, le nombre de celles réputées pleinement « originales » devant être d’une petite dizaine dans le seul domaine du logiciel (GNU GPL, MPL, OSL, EUPL, Apache voire EPL). L’analyse de ces dernières permet de donner un aperçu fidèle de leur écosystème.

Nous allons donc nous intéresser aux licences suivantes : AFL, Apache, APSL, EPL, EUPL, GNU (GPL, LGPL et Affero GPL), MIT, MPL, CeCILL(-A, -B, -C), Creative Commons, LAL, ODbL, PHP License, OSL, et la TAPR Open Hardware License.

Chacune d’elle sera analysée conformément à la grille de lecture proposée précédemment<fnref n="1" /> : droits et obligations, étendue, élément déclencheur et clause de compatibilité.

## AFL v 3.0 (Academic Free License)

Assez similaire à la licence Apache, l’Academic Free License<fnref n="2" /> est la petite sœur permissive de l’OSL (toutes les clauses lui sont identiques, à l’exception de celles instaurant le *copyleft*) rédigée par l’avocat américain Lawrence Rosen. Elle est dite « de contenu libre », c’est-à-dire qu’elle a vocation à être utilisée sur toutes œuvres originales (ce qui inclut donc les logiciels, mais aussi les documentations, images, etc. — avec comme intention de pouvoir s’appliquer à tout ce qui accompagne le logiciel). La version 1.1 date de 2002 et fut certifiée *open source* par l’Open Source Initiative (OSI), mais déclarée incompatible avec la DFSG par la communauté Debian ; la version 2.0 date de 2003, et la dernière version fut publiée en 2005.

En termes de *droits*, c’est une licence conforme à l’OSD qui autorise expressément les sous-licenciements (sous la même licence). Elle est gratuite (mais la communication de l’œuvre peut être payante), non exclusive et perpétuelle et porte sur les droits d’auteur comme sur ceux des brevets contenus dans le code soumis à la licence (elle cherche à créer ici un pot

<footnote n="1">1. Cf Partie II, Chapitre 2 : « 2.3 Déchiffrer : une grille de lecture de licences libres ».</footnote>

<footnote n="2">2. http://www.opensource.org/licenses/afl-3.0.php.</footnote>
commun de brevets, équivalent à celui issu de l'usage des licences *copy-left*). Enfin, la licence incorpore une limitation — et non pas une exclusion — de garantie (de la provenance des sources) et de responsabilité à l'é-gard du concédant ; solution bien plus pragmatique puisqu'il s'agit de ce qui est, dans les faits, le minimum légal.

En termes d'obligations, la licence n'est pas *copyleft*, mais quiconque poursuit l'auteur original ou ses utilisateurs pour violation de brevet contenu dans le logiciel soumis à cette licence voit toutes les licences qui lui étaient accordées se terminer immédiatement. Toute action ou poursuite doit se faire devant un tribunal de la juridiction du lieu où le concédant exerce son activité principale — tous les frais d'avocats seront à la charge de la partie qui poursuit.

L'élément déclencheur de la licence est l'external deployment, c'est-à-dire « l'utilisation, la distribution ou la communication de l'œuvre originale ou dérivée d'une façon telle que cette œuvre originale ou dérivée puisse être utilisée par toute autre personne que vous. » <fnref n="1" />.

L'étendue de la licence s'appuie sur les distinctions du copyright quant à la portée de l'œuvre dérivée. À noter que le code source, tel que défini par l'OSL, inclut la « documentation décrivant comment modifier l'œuvre originale. »

En termes de compatibilité, la licence est relativement souple dès lors que ses obligations sont respectées : ce qui la rendait incompatible avec la GNU GPL v2 (elle serait néanmoins compatible avec la troisième version), mais entièrement compatible avec sa grande sœur de l'OSL (rédigée sur le même canevas).

Enfin, la licence elle-même est copyrightée et ne peut donc servir de base à une nouvelle licence <fnref n="2" />.

<footnote n="1">1. Article 5, *external deployment* : « The term 'External Deployment' means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c). »</footnote>

<footnote n="2">2. Même si dans son livre *Open Source Licensing : Software Freedom and Intellectual Property Law* (Upper Saddle River, NJ, Prentice Hall, 2004 — http://www.rosenlaw.com/oslbook.htm), Lawrence Rosen doute de la pertinence d'une telle protection attachée aux licences.</footnote>
Apache License (APL)

Seule l'utilisation de la version 2.0, publiée le 1er mars 2004, de l'Apache Public License<fnref n="1" /> est aujourd'hui préconisée (notamment, par défaut, pour tous les projets de la fondation Apache)<fnref n="2" />. C'est aussi une licence permissive par laquelle les contributeurs partagent leur monopole en matière de droit d'auteur et éventuellement de brevets portant sur ces contributions (cette licence tombe en cas d'action à l'encontre des contributeurs).

En termes de droits, la licence autorise expressément les sous-licences.

En termes d'obligations, on retrouve les mentions traditionnelles relatives à la paternité et à la licence (avec notamment la nécessité de distinguer les différentes contributions et le respect d'un formalisme quant aux mentions légales attachées aux œuvres dérivées). Toute contribution reversée au concédant pour inclusion dans son logiciel est, sauf mention contraire, réputée être soumise à la même licence. Enfin, une sanction est prévue à l'encontre de tout licencié qui agirait sur la base d'une violation de brevet dans l'usage d'un logiciel sous licence Apache ou ses contributions (toutes les licences de brevets qu'il tire de la licence Apache se terminent au jour de l'assignation).

L'étendue de la licence est, pour l'essentiel, limitée à la portion du code sous licence Apache, mais certaines obligations (notamment celles concernant les mentions légales du logiciel final) s'étendent aussi aux logiciels dérivés (basés sur ou incluant des composants sous licences Apache).

L'élément déclencheur est la distribution de copies du logiciel (l'accès au code offert à un tiers).

La licence ne prévoit pas de compatibilité particulière, mais plusieurs licences peuvent être utilisées, dont la GNU GPL v. 3 si sont précisées les obligations supplémentaires liées à la licence Apache.

<footnote n="1">1. http://www.apache.org/licenses/LICENSE-2.0%20.</footnote>

<footnote n="2">2. Il est encore néanmoins possible de retrouver la version 1.0 dans certains projets, comme OpenSSL License.</footnote>
## Apple Public Source License v2.0

Licence utilisée depuis 2003 sur une partie du système d'exploitation MacOS X d'Apple, la APSL<fnref n="1" /> n'a pas vocation à être utilisée sur d'autres projets et la firme Apple est citée à plusieurs reprises (ce qui est d'autant plus logique que cette licence est elle-même une adaptation de la licence MPL).

Ainsi, en termes d'obligations peut-on remarquer que la licence est copyleft et organise une licence en matière de brevets. En cas de non-respect de la licence, la licence prévoit une certaine souplesse qui permet éventuellement de corriger le comportement défaillant. La compétence territoriale est fixée en Californie.

En termes d'étendue, la licence est modulaire et opère par fichier<fnref n="2" /> autorisant donc le lien vers d'autres fichiers qui peuvent être entièrement propriétaires.

Son élément déclencheur est celui du déploiement externe<fnref n="3" /> (external deployment), ce qui la met à l'échelle des licences du type OSL ou GNU Affero GPL.

La licence ne prévoit aucune compatibilité particulière.

## Eclipse Public License (EPL)

L'Eclipse Public License<fnref n="4" /> est la licence qui a succédé à la CPL sur le projet Eclipse (cette dernière ayant elle-même succédé à la licence IBM Public License).

Concernant ses obligations, la licence Eclipse est elle aussi copyleft, et comporte une clause en matière de brevets qui est sensiblement similaire

<footnote n="1">1. http://www.opensource.apple.com/apsl.</footnote>

<footnote n="2">2. « When code is released as a series of files, a modification is : (a) any addition to or deletion from the contents of a file containing Covered Code; and/or (b) any new file or other representation of computer program statements that contains any part of Covered Code. »</footnote>

<footnote n="3">3. Traduction personnelle : 1.4 — « déployé extérieurement » signifie : (a) de sous-licencier, distribuer ou rendre le code couvert disponible autrement, directement ou indirectement, à quiconque autre que vous, et/ou (b) d'utiliser le code couvert, seul ou comme partie d'une création plus large, d'une manière à fournir à service, notamment pour fournir du contenu, à travers une communication électronique avec un client autre que vous.</footnote>

<footnote n="4">4. http://www.eclipse.org/legal/epl-v10.html.</footnote>
à celle de la licence Apache (en cas d'action basée sur une violation de brevet dans l'usage du logiciel sous EPL, toutes les licences de brevets tirées de la licence sont terminées).

L'étendue de l'EPL est basée sur la définition américaine de l'œuvre dérivée, interprétée de manière plus restrictive que pour la GNU GPL : la licence ne s'étend pas aux modules séparés développés autour du logiciel, ni aux autres travaux qui ne seraient pas directement dérivés du programme<fnref n="1" />.

L'élément déclencheur est, classiquement, celui de la distribution.

La licence précise que la loi applicable est celle de l'état de New York et des États-Unis en matière de propriété intellectuelle.

## European Union Public License (EUPL)

Disponible en 22 langues (chacune de ses traductions ayant la même valeur contractuelle), l'European Union Public License <fnref n="2" /> est sans conteste la licence la plus internationale.

Elle est copyleft et contient une licence de brevets dans la « mesure nécessaire à l'exercice des droits qui [...] sont concédés sur l'œuvre distribuée sous la [...] licence ». La terminaison de la licence est automatique en cas de son non-respect.

<footnote n="1">1. « As described in article 1(b)(ii) of the Eclipse Public License, "...Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program". The definition of derivative work varies under the copyright laws of different jurisdictions. The Eclipse Public License is governed under U.S. law. Under the U.S. Copyright Act, a 'derivative work' is defined as "... a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'". The Eclipse Foundation interprets the term 'derivative work' in a way that is consistent with the definition in the U.S. Copyright Act, as applicable to computer software. You will need to seek the advice of your own legal counsel in deciding whether your program constitutes a derivative work.</footnote>

<footnote n="2">2. http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1.</footnote>
En termes d'étendue, la licence renvoie à la loi « applicable en matière de droit d'auteur dans le pays désigné à l'article 15 » (pays du concédant, voire loi belge si ce dernier n'est pas européen ou s'il s'agit de la Commission européenne).

En termes d'élément déclencheur : tant la distribution que la communication au public (même de façon indirecte, ce qui comprend notamment l'usage d'un logiciel en Software as a Service)<fnref n="1" />.

La loi applicable et le tribunal compétent sont ceux de « l'État mem-
bre de l'Union européenne où le donneur de licence réside ou a établi son
siège social » (pays du concédant, voire loi belge si ce dernier n'est pas
européen ou s'il s'agit de la Commission européenne). La licence con-
tient une garantie d'éviction (l'assurance que chaque concédant est bien
titulaire de droits sur ses contributions) et repose sur un mécanisme de
sous-licence.

Enfin, la licence est expressément compatible avec cinq autres licences similaires : une clause venant spécialement autoriser la redistribution sous un certain nombre de licences dès lors qu'une œuvre dérivée combine composants sous licence EUPL et composants sous l'une de ces licences compatibles<fnref n="2" />.

GNU General Public License (GNU GPL)

Première licence libre, la GNU GPL fut la première à contractualiser la
notion de pot commun, avec pour objectif de faciliter l'accès aux codes
sources et leurs interactions. La GNU GPL est, historiquement, réservée
aux logiciels et elle est de mieux en mieux rédigée au fur et à mesure de
ses versions.

L'étendue ainsi que la portée (droit d'auteur, droit des brevets, droit des topographies des semi-conducteurs, DRM, etc.) très larges de la licence GNU GPL sont ses principales caractéristiques.

<footnote n="1">1. À noter cependant que la version 1.0 de la licence n'avait que la distribution comme élément déclencheur.</footnote>

<footnote n="2">2. Sont actuellement concernées : la GNU General Public License (GNU GPL) v. 2, l'Open Software License (OSL) v. 2.1, v. 3.0, la Common Public License v. 1.0, l'Eclipse Public License v. 1.0 et la CeCILL v. 2.0.</footnote>
Deux versions de la licence (la deuxième et la troisième) sont actuellement utilisées et méritent un examen spécifique.

## GNU GPL v. 2

En termes d'obligations :

- tout est fait pour que les mentions légales soient accessibles sinon publiées : ainsi, dans l'hypothèse d'un programme lisant habituellement des instructions de façon interactive lorsqu'on l'exécute, celui-ci doit imprimer ou afficher une annonce comprenant une mention relative aux droits d'auteur, à l'absence de garantie, et à la soumission à la GNU GPL;

- la livraison du code source doit être réalisée dans sa forme préférentielle;

- la licence est bien sûr copyleft.

L'étendue de la GNU GPL est très large puisque tout logiciel basé sur un composant sous GNU GPL doit être distribué sous cette même licence et que le logiciel lui-même est envisagé « comme un tout ». Le flou de ces notions induit plusieurs interprétations. La Free Software Foundation prône la plus extensive (par laquelle toute liaison avec un composant sous cette licence emporterait son extension).

Ainsi, dans le cas du logiciel auquel est associé de multiples modules :

- les modules développés autour du logiciel sont, selon la FAQ de la licence<fnref n="1" />, des « créations basées » (based on) sur le logiciel. En tant que telles, elles doivent donc être diffusées sous la même licence que le logiciel<fnref n="2" />;

- si le logiciel est distribué simultanément avec des modules sous cette licence, alors celle-ci doit s'étendre au logiciel « comme un tout », c'est-à-dire au logiciel et ses différents modules.

<footnote n="1">1. http://www.gnu.org/licenses/gpl-faq.html.</footnote>

<footnote n="2">2. Sauf à envisager une politique de type « double licence » qui permettrait, moyennant un certain prix, le développement de module tiers commerciaux. Ceci peut néanmoins être un frein à la diffusion du logiciel.</footnote>
Concernant l'élément déclencheur, les obligations de la licence ne sont opposées aux licencié que s'il distribue le programme. Le copyleft s'applique uniquement au programme et non à ses sorties, par exemple un portail web utilisant une version modifiée privée d'un CMS (Content Management System) sous GPL ne sera pas obligé de livrer ses sources (élément traité par la GNU Affero GPL) tant qu'il n'aura pas donné accès à une copie du logiciel.

Intransigeante, même envers les autres licences libres et open source, la licence GNU GPL n'organise elle-même aucune compatibilité.

## GNU GPL v. 3

Un lot de nouvelles stipulations précise ou étend les obligations de la précédente version :

- la notion de code source est précisée et étendue<fnref n="1" />;

- vis-à-vis des mesures techniques, de protection et d'information (ADPIC, EUCD, DADVSI) : l'auteur d'un logiciel sous GPL renonce à ce que celui-ci soit considéré comme une mesure technique (à priori, autant de protection que d'information — MTP/MTI) et ne peut limiter la jouissance tirée de la licence par une interdiction du contournement de mesures techniques.

- Le *peer to peer* est enfin pris en considération en tant que distribution (sans pour autant que les personnes qui téléchargent le logiciel par ce canal n'aient à fournir les sources);

- *Tivoïzation*<fnref n="2" /> : stipulation réservée aux « produits de consommation » (non applicable à un usage interne ou entre professionnels), elle in-

<footnote n="1">1. La « source correspondante » d'une création sous forme de code objet désigne 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. Cependant, cela n'inclut pas les bibliothèques systèmes de la création, ni les outils d'usage général ou les programmes libres généralement disponibles qui peuvent être utilisés sans modification pour réaliser ces activités, mais ne sont pas partie de cette création. Par exemple, la source correspondante inclut les fichiers de définition d'interfaces associés aux fichiers sources de la création, et le code source des bibliothèques partagées et des sous-programmes liés dynamiquement, dès lors que la création est spécialement conçue pour les requérir via, par exemple, des communications de données ou contrôles de flux internes entre ces sous-programmes et d'autres parties de la création.</footnote>

<footnote n="2">2. Néologisme définissant la création d'un système qui inclut des logiciels libres, mais utilise le matériel électronique pour interdire aux utilisateurs d'y exécuter des versions modifiées (voir la page Wikipedia consacrée).</footnote>
terdit de limiter l'usage d'un produit embarquant du code sous GNU GPL v. 3 à la seule version fournie par le constructeur ;

- en matière de brevet, la GNU GPL garantit une « licence de brevet non exclusive, mondiale et gratuite, sur les revendications essentielles de brevet du contributeur pour réaliser, utiliser, vendre, commercialiser, importer et ainsi qu'exécuter, modifier et propager les contenus de sa version contributive » et impose à tout bénéficiaire de brevets de rendre le code source disponible, renoncer au bénéfice de licences sur cesdits brevets ou s'engager à étendre la licence au destinataire du logiciel ;

- la *terminaison automatique des droits*, avec procédure de semonce (article 8) est tempérée lorsqu'il s'agit d'une première violation et en fonction de la réaction du concédant ;

- en termes de *compatibilité* : on notera une compatibilité expresse au profit de la GNU Affero GPL et l'ajout d'une modularité qui permet à la licence de se rendre compatible avec plusieurs licences permissives grâce à l'ajout autorisé de termes additionnels : soit pour donner plus de droits, soit pour ajouter quelques obligations limitativement énumérées (la GNU GPL liste dans son article 7 six termes supplétifs).

## Exceptions à la GNU GPL

La GNU GPL étant la licence la plus utilisée, il n'est pas étonnant qu'une pratique se soit développée atour des aménagements qui pouvaient lui être apportés par le biais d'exceptions expresses. La GPL Linking exception et la FOSS exception sont les deux plus connues.

### La GPL with special linking exception

Pour répondre aux besoins de certains projets libres importants souhaitant autoriser le développement de plug-ins propriétaires, une exception (*GPL Linking exception*) a été rédigée (elle est actuellement utilisée par des projets comme GNU Guile, GNAT ou GNU Classpath). Elle contient les mêmes libertés que la GNU LGPL en ce qu'elle permet expressément les liaisons entre programmes, mais sans requérir les conditions posées
par la LGPL quant à la fourniture des informations nécessaires à la modification de la bibliothèque.

La bibliothèque GNU Classpath utilise ainsi la licence qui suit :

*Classpath is distributed under the terms of the GNU General Public License with the following clarification and special exception.*

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version.

## FOSS exception

La FOSS exception organise une limitation de l'étendue de la licence dans un contexte *open source* seulement : système souvent utilisé, notamment sur la bibliothèque MySQL diffusée sous GNU GPL<fnref n="1" />, 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égi par leur licence d'origine).

<footnote n="1">1. Voir http://www.mysql.com/about/legal/licensing/foss-exception.</footnote>
Oracle's Free and Open Source Software (FOSS) License Exception (formerly known as the FLOSS License Exception) allows developers of FOSS applications to include Oracle's MySQL Client Libraries (also referred to as 'MySQL Drivers' or 'MySQL Connectors') with their FOSS applications. MySQL Client Libraries are typically licensed pursuant to version 2 of the General Public License (GPL), but this exception permits distribution of certain MySQL Client Libraries with a developer's FOSS applications licensed under the terms of another FOSS license listed below, even though such other FOSS license may be incompatible with the GPL.

## GNU Lesser General Public License (GNU LGPL)

Deux versions coexistent actuellement, sans grande différence sur le fond, mais avec une grande différence sur la forme : la GNU LGPL était une licence à part entière jusqu'à la version 2.1 et n'est plus qu'une exception associée à la GNU GPL à partir de la version 3 (les textes des deux licences devant alors simultanément être distribués).

De manière générale, elle apporte un lot de permissions additionnelles à la GNU GPL en venant atténuer l'étendue ou les effets de cette dernière (une telle technique est toujours possible pour le titulaire de droits).

Ainsi, la GPLv3 est la licence que l'on applique par défaut et, dès lors que l'on se trouve dans l'une des situations définies par la LGPL v. 3, on applique le « régime dérogatoire » spécialement prévu (exception d'interprétation stricte) :

- Art. 3 : l'inclusion de material from header file that is part of the library;

- Art. 4 : la création de combined work (qui peut être diffusée sous une autre licence);

- Art. 5 : la création de combined libraries.

Il est à tout moment possible de redistribuer sous GNU GPL un logiciel auparavant sous GNU LGPL.
GNU Affero General Public License (GNU AGPL)

La GNU AGPL 3.0¹ est elle aussi construite sur le canevas de la GNU GPL v. 3. Seul son article 13 est différent.

Ainsi, en matière d'obligation, il faut distinguer d'une part ceux qui distribuent le logiciel ou en offrent un accès en ligne et, d'autre part, ceux qui contribuent :

- les distributeurs et utilisateurs offrant un accès en ligne, sont tenus :
  a) à un certain affichage des mentions légales, b) à la distribution de la licence et c) à la distribution du code source correspondant ;

- et, au surplus, les contributeurs sont « classiquement » tenus : a) par le caractère *copyleft* de la licence, c'est-à-dire à ce que toute redistribution du logiciel, d'une version modifiée ou d'une solution basée sur ce logiciel se fasse sous la même licence<fnref n="2" />, b) à une licence de brevet qui s'étend automatiquement à tout brevet détenu par un contributeur sur sa contribution, c) à une interdiction d'opposer d'éventuels droits qui seraient détenus sur une mesure technique de protection.

L'étendue de la GNU AGPL est particulièrement large puisqu'elle reprend celle de la GNU GPL sans l'adapter aux solutions logicielles donnant accès à des services : ainsi sont soumises à la licence (et doivent donc être distribuées selon les termes de cette dernière) les versions modifiées du logiciel, mais aussi les versions basées sur le logiciel<fnref n="3" /> — la limite étant celle de l'« agrégat », compris comme « une compilation du code couvert (par la licence) avec d'autres œuvres séparées et indépendantes, qui ne sont pas par leur nature des extensions du code couvert, et qui ne sont pas combinées comme un programme plus large, sur ou dans un média de stockage ou de distribution[...] »

En matière d'élément déclencheur, deux hypothèses se cumulent : la distribution du logiciel (comprise comme la mise à disposition de celui-

<footnote n="1">1. La précédente version, corédigée par la société Affero et la FSF, n'était pas une licence (de la famille) GNU.</footnote>

<footnote n="2">2. L'article 7 de la GNU Affero GPL autorise l'ajout d'un certain nombre de clauses sur des parties clairement identifiées du logiciel.</footnote>

<footnote n="3">3. La licence emploie le vocabulaire « modified version », « work based on » et « entire work, as a whole ».</footnote>
ci<fnref n="1" />) ou l'interaction via le réseau d'une version modifiée du logiciel (il faut une interaction *et* une modification).

## GNU Free Documentation licence (GNU FDL)

La licence GNU FDL 2 est le pendant de la GNU GPL, utilisable de façon complémentaire sur la documentation des logiciels libres. La première version de la GNU FDL date de 1999, elle a ensuite connu deux révisions successives en 2000 (v. 1.1) et 2002 (v. 1.2) et une plus récente en 2008 (v. 1.3). Le draft de la GNU FDL v 2.0 3 est en discussion depuis 2006 (ainsi que celui de sa petite sœur, la GNU Simpler FDL v. 1.0 4 , licence plus souple qui supprime notamment les mécanismes complexes de la GNU FDL).

En termes d'obligation, la licence GNU FDL est une licence copyleft. Elle offre la possibilité de préciser la présence de certaines sections invari-antes (toute information ne peut néanmoins être identifiée comme telle) afin d'empêcher tout contributeur subséquent d'y apporter des modifica-tions (ou même de la supprimer). Par ailleurs, elle impose un formalisme particulier attaché à la diffusion de la version papier de la création diffusée sous GFDL (un formalisme assez contraignant qui passe notamment par l'impression de l'intégralité du texte de la licence).

En termes de compatibilité, la licence est une licence copyleft classique, c'est-à-dire sans autre compatibilité qu'avec les versions ultérieures de la même licence. Néanmoins, la publication de la version 1.3 prévoyait une compatibilité expresse et limitée au profit de la CC-By-SA 3.0 — par ailleurs spécialement limitée au seul bénéfice des sites de collaboration multiauteurs (Massive Multiauthor Collaboration Site) et avant le 1er août 2009 (cela pour répondre à la demande de la fondation Wikimedia qui souhaitait modifier la licence de Wikipedia).

<footnote n="1">1. Il est néanmoins possible (à l'instar de la GNU GPL v. 3) de faire appel à des prestataires sans que leurs développements pour le compte de leur client ne soient considérés comme une distribution.</footnote>

<footnote n="2">2. http://www.gnu.org/licenses/fdl.html.</footnote>

<footnote n="3">3. http://gplv3.fsf.org/fdl-draft-2006-09-22.html.</footnote>

<footnote n="4">4. http://gplv3.fsf.org/sfdl-draft-2006-09-26.html.</footnote>
<figure><img src="image_55.png" /></figure>

## REMARQUE

- Cette licence est l'une des « DFSG-incompatibles<fnref n="1" /> »
  — par exception, la licence est considérée comme libre lorsqu'utilisée GFDL sans sections invariantes<fnref n="2" />;

- La FSF a publié un article sur « comment utiliser la FDL de GNU pour vos documents<fnref n="3" />. »

## MIT License

La licence MIT<fnref n="1" />, dans ses différentes versions, est une licence libre très permissive qui ressemble beaucoup à la licence BSD : elle opère le partage de tous les droits patrimoniaux de l'auteur sous la seule condition de respecter la paternité de ce dernier et de conserver les mentions légales. Il s'agit ainsi d'une sorte de « mise dans le domaine public.<fnref n="2" /> »

Elle se distingue néanmoins de la licence BSD par une plus grande description des droits cédés (qui lui vaut d'être souvent préférée).

Les *obligations* de la licence concernent essentiellement les mentions légales et la licence qui doivent être incluses dans toute copie ou « portion substantielle ».

L'*étendue* de la licence se limite à la seule portion du code publiée sous cette licence et l'*élément déclencheur* est la distribution, diffusion, de copies du logiciel.

Enfin, en raison de son caractère peu contraignant, la licence est *compatible* avec la majorité des autres licences (commerciales ou libres).

## Mozilla Public License (MPL)

Crée en 1998 à l'occasion de la libération du code source de Netscape Communicator 5, la MPL est actuellement utilisée en sa version 1.1, une

<footnote n="1">1. http://wiki.debian.org/DFSGLicenses.</footnote>

<footnote n="2">2. http://www.debian.org/vote/2006/vote_001.</footnote>

<footnote n="3">3. http://www.gnu.org/licenses/fdl.html.</footnote>

<footnote n="1">1. http://opensource.org/licenses/mit-license.php.</footnote>

<footnote n="2">2. Une telle renonciation au droit est sans valeur, c'est-à-dire sans effet, en droit français. D'où la nécessité d'user d'une telle licence aux effets similaires.</footnote>
version 2.0 est néanmoins en cours d'écriture — intégrant quelques idées
qui avaient justifié la création de la licence CPAL.

## Mozilla Public License v. 1.1

Autorisation expresse est donnée de sous-licencier le code. La MPL<fnref n="1" /> est copyleft. En matière de brevets, une licence expresse (auteurs initiaux et contributeurs) autorise toute fabrication, utilisation ou vente du logiciel original, ses modifications et/ou des combinaisons entre le logiciel et les modifications (le tout limité à la seule version du contributeur auteur).

Quant à l'étendue : se limitant aux seules modifications apportées au logiciel, la licence permet de contribuer au logiciel sans devoir distribuer sous la même licence tant que les fichiers contenant du code sous MPL restent sous MPL (les autres fichiers pouvant dès lors être soumis à n'importe quelle autre licence).

L'élément déclencheur est la distribution (ou toute autre communication du code à un tiers). En cas de violation de la licence, la licence se termine automatiquement dans les trente jours qui suivent la prise de connaissance de cette violation par le licencié.

## Mozilla Public License v. 2.0

En plus de préciser les définitions de la version précédente, la seconde version 2 poursuit des objectifs supplémentaires :

- en termes d'élément déclencheur, il était envisagé que l'utilisation par le réseau soit assimilée à une distribution et emporte des obligations — notamment pour ce qui concerne les mentions légales ;

- en termes de compatibilité, la licence prévoit la possibilité de diffuser le composant sous licence GNU (GPL, LGPL ou AGPL) en situation d'incompatibilité.

<footnote n="1">1. Voir http://www.mozilla.org MPL.</footnote>

<footnote n="2">2. http://mpl.mozilla.org.</footnote>
## Common Public Attribution License Version 1.0 (CPAL)

Approuvée par l'OSI en 2007, la licence CPAL s'inspire de la MPL qu'elle module sur deux aspects :

- concernant les *obligations*, la licence ajoute une obligation d'attribution de paternité renforcée<fnref n="1" />;

- concernant l'élément *déclencheur*, la licence associe la notion de déploiement externe (*external deployment*) à celle de distribution<fnref n="2" />.

## CeCILL(-A, -B, -C)

Les licences CeCILL<fnref n="3" />, acronyme pour Ce(A) C(nrs) I(NRIA) L(ogiciel) L(ibre), furent créées pour répondre aux arguments qui empêchaient les administrations françaises d'utiliser les licences GNU pour diffuser leurs logiciels : l'application de la loi n°94-665 du 4 août 1994 relative à l'emploi de la langue française (plus connue sous le nom de *loi Toubon*, ministre de la Culture de l'époque) qui contraint toute administration à s'appuyer sur des textes juridiques français, le constat d'imprécision à l'égard du droit français (droit sur lequel repose la licence, droits patrimoniaux, clause de non garantie).

Elles sont toutes construites sur le canevas de la première licence (la licence CeCILL ou CeCILL-A).

## La CeCILL-A

Première des licences, la licence CeCILL (ou CeCILL-A) précéda la rédaction des deux autres.

<footnote n="1">1. Article 14, Additional term : « the Original Developer may include [...] a requirement that each time an Executable and Source Code or a Larger Work is launched or initially run [...] a prominent display of the Original Developer's Attribution Information [...] must occur on the graphic user interface employed by the end user to access such Covered Code [...] »</footnote>

<footnote n="2">2. Article 15, « Terme additionnel : utilisation réseau ». Le terme « déploiement externe » signifie l'utilisation, distribution ou communication du code original ou des modifications d'une façon telle que le code original ou les modifications puissent être utilisés par toute autre personne que vous, que ces œuvres soient distribuées ou communiquées à ces personnes ou rendues disponibles comme une application destinée à une utilisation sur le réseau.</footnote>

<footnote n="3">3. http://www.cecill.info/licences.fr.html.</footnote>
En termes d'obligations, la CeCILL-A, rédigée sur le modèle de la GNU GPL, est une licence *copyleft* qui impose donc la redistribution selon ses propres termes. Par ailleurs, le concédant s'engage à ne pas opposer d'« éventuels droits conférés par ces brevets aux licenciés successifs qui utiliseraient, exploiteraient ou modifieraient le logiciel ». Par ailleurs, « [e]n cas de cession de ces brevets, le concédant s'engage à faire reprendre les obligations du présent alinéa aux cessionnaires. »

Son étendue se limite au logiciel et à ses seuls modules internes, ces derniers étant entendus comme tout module lié au logiciel de telle sorte qu'il s'exécute dans le même espace d'adressage. Tout autre module, appelé module externe, n'est pas soumis aux licences

L'élément déclencheur est la distribution (envisagée comme « notamment le droit de diffuser, de transmettre et de communiquer le Logiciel au public sur tout support et par tout moyen ainsi que le droit de mettre sur le marché à titre onéreux ou gratuit, un ou des exemplaires du logiciel par tout procédé ». Il est a noter que les rédacteurs de la licence CeCILL estiment, contre toute attente, que leur licence appréhende les usages par le réseau<fnref n="1" /> (il semble néanmoins plus prudent de considérer que, sauf mention contraire de l'auteur lors de la diffusion sous licence CeCILL, un tel usage n'est pas saisi par la licence elle-même).

La licence est compatible avec la CeCILL-A et la CeCILL-C. Ainsi toutes les clauses qui rendraient la licence CeCILL-B incompatible avec la CeCILL-A et CeCILL-C sont suspendues en cas de situation d'incompatibilité (mécanisme de compatibilité expresse passive)<fnref n="2" />.

## La CeCILL-B

La CeCILL-B, rédigée sur le modèle de la BSD, n'est pas *copyleft*, mais contient une clause supplémentaire en matière de citation. Ainsi, en cas de

<footnote n="1">1. Voir la FAQ sur le site http://www.cecill.info/faq.fr.html. « Si le 5.3.2 parle de distribution, il s'agit, comme indiqué en préambule de l'article 5.3, de "diffuser, de transmettre et de communiquer le logiciel au public, sur tout support et par tout moyen". Une mise à disposition via un site web ou un serveur est donc bien une distribution même si l'utilisateur ne dispose pas d'un exemplaire du logiciel en propre, et l'obligation de fournir le code source du logiciel modifié s'applique. »</footnote>

<footnote n="2">2. Article 5.3.4 : Compatibilité avec la licence GNU GPL.</footnote>
modification du logiciel (qui ne serait pas qualifié de module externe), le
licencié qui distribue s'engage expressément

1. à faire référence au logiciel avec ses mentions légales dans sa doc-
umentation ;

2. à faire en sorte que les mentions légales soient indiquées dans un texte facilement accessible depuis l'interface du logiciel ;

3. à mentionner, sur un site Web librement accessible décrivant le logi-
ciel modifié, et pendant au moins toute la durée de sa distribution,
qu'il a été réalisé à partir du logiciel ;

4. et lorsqu'il le distribue à un tiers susceptible de distribuer lui-même un logiciel modifié, sans avoir à en distribuer le code source, à faire les meilleurs efforts pour que les obligations soient reprises.

La licence est compatible avec la CeCILL-A et la CeCILL-C. Ainsi toutes les clauses qui rendraient la licence CeCILL-B incompatible avec la CeCILL-A et CeCILL-C sont suspendues en cas de situation d'incompatibilité (mécanisme de compatibilité expresse passive) <fnref n="1" />.

La CeCILL-C

Basée sur le CeCILL, la licence CeCILL-C limite son étendue en matière de copyleft à l'instar de la MPL (les autres obligations restant intouchées) puisqu'elle permet expressément la diffusion sous leur propre licence de modules liés (ensembles de fichiers sources y compris leur documentation qui, sans modification du code source, permet de réaliser des fonctionnalités ou services supplémentaires à ceux fournis par le logiciel).

La licence est compatible avec la CeCILL-A, de telle sorte que toutes les clauses qui rendraient la licence CeCILL-C incompatible avec la CeCILL-A sont suspendues en cas de situation d'incompatibilité (mécanisme de compatibilité expresse passive) <fnref n="2" />.

<footnote n="1">1. Article 5.3.5 : Compatibilité avec les licences CeCILL et CeCILL-C.</footnote>

<footnote n="2">2. Article 5.3.4 : Compatibilité avec la licence CeCILL.</footnote>
Les licences Creative Commons

Quatrième série des licences Creative Commons (la numérotation inter-
médiaire 2.5 s’expliquant par les faibles changements qu’elle intégrait),
les CC 3.0 furent rédigées en 2009 — publiées en version *unported* avant
d’être transposées dans les diverses juridictions (les versions françaises,
pourtant traduites depuis près de deux ans, ne sont pas encore officielle-
ment publiées). Elles sont aujourd’hui détachées du droit américain pour
simplifier leur portage et intègrent de nouveaux dispositifs (notamment
concernant les DRM et le droit *sui generis* des bases de données).

Les licences Creatives Commons sont dédiées aux œuvres utilitaires (et ne sont donc pas adaptées à une utilisation sur des logiciels <fnref n="1" /> ou bases de données <fnref n="2" />).

Droits et obligations

Concernant les droits, toutes les licences Creatives Commons ne sont
pas aussi libres et elles n'ont donc en commun que de permettre la diffu-
sion et l'utilisation non commerciale des œuvres *non modifiées*.

Ainsi, les deux premières clauses limitent les droits accordés :

- les utilisations commerciales sont autorisées dès lors que la clause NC n'est pas utilisée ;

- la modification est permise tant que la clause ND n'est pas utilisée.

Tandis que les deux autres clauses ajoutant des obligations relatives à
l'utilisation de l'œuvre partagée :

- la clause By (obligatoire) ;

- la clause Share Alike (SA) introduit un mécanisme de *copyleft* au sein de la licence.

<footnote n="1">1. http://wiki.creativecommons.org/FAQ (Can I use a Creative Commons license for software ?).</footnote>

<footnote n="2">2. https://creativecommons.org/weblog/entry/26283.</footnote>
## L'étendue

Dans leur seconde version, les licences CC distinguent les œuvres collectives (un ensemble d'œuvres) des œuvres « dites dérivées » (qui rejoint la définition française de l'œuvre dérivée). Au surplus, la licence précise que si l'œuvre est « une composition musicale ou un enregistrement sonore, la synchronisation de l'œuvre avec une image animée sera considérée comme une œuvre dite dérivée pour les propos de ce contrat. »

Dans leur troisième version, les termes utilisés sont « compilation » et « adaptation » (avec une portée similaire).

## L'élément déclencheur

Les licences CC ne précisent aucune sphère privée : tout acte autorisé par la licence est conditionné au respect des obligations de celle-ci (voir l'article 4 « Restrictions : L'autorisation accordée par l'article 3 est expressément assujettie et limitée par le respect des restrictions suivantes [...] »).

## La compatibilité

La compatibilité est l'un des points forts des licences Creative Commons : dès lors que la licence n'est pas copyleft (clause Share Alike), il est possible de redistribuer l'œuvre sous une licence plus contraignante que précédemment (par exemple en rajoutant un NC ou ND à une licence CC By, ou en distribuant des articles sous CC By-NC dans un ouvrage sous CC By-NC-ND — voire sous licence commerciale classique).

Au surplus, la CC By-SA insère une nouvelle compatibilité dans sa troisième version au travers la licence CC By-SA, permettant la redistribution sous d'autres licences compatibles (le dispositif tarde néanmoins à être activé<fnref n="1" />).

<footnote n="1">1. Voir notamment recherche de compatibilité au sein de la licence Creative Commons 3.0, http://lists.ibiblio.org/pipermail/cc-licenses/2007-February/005013.html.</footnote>
La licence Art Libre

Recommandée par la FSF, la licence Art Libre (LAL) est certainement
la licence appliquée aux créations artistiques la plus proche de l'esprit
originaire du Libre. Elle est porteuse d'une philosophie adaptée à l'ensem-
ble des pratiques artistiques (y compris logicielles) et rassemble l'aspect
communautaire qui fait la force de ces licences (et qui explique qu'elle soit
souvent utilisée par conviction, sans forcément être lue). La licence 1.3
« est rédigée en référence au droit français et à la Convention de Berne rel-
ative au droit d'auteur » (les versions précédentes, expressément soumises
au droit français restaient néanmoins valides dans tous les pays signataires
de la Convention de Berne).

Les changements apportés depuis sa rédaction en 2000 sont peu impor-
tants : une meilleure prise en compte du *copyleft* afin de l'adapter effec-
tivement aux œuvres d'art (insertion de la précision d'originels et con-
séquents dans l'article 3) par la version 1.2 et, en avril 2007, la version
1.3 (en cours) est venue apporter certains changements prévenant notam-
ment les conflits entre droits de propriété intellectuelle (article 3 : « droits
connexes »), et entre licences similaires.

Les *obligations* sont de plusieurs ordres. En termes de responsabilité,
la LAL rappelle que « la liberté de jouir de l'œuvre tel que permis par
la LAL (liberté de copier, diffuser, modifier) implique pour chacun la re-
sponsabilité de ses propres faits ». En termes de formalisme, les mentions
légales classiques sont demandées (avec la précision des modifications
lorsqu'il y a lieu) et un simple lien vers la licence est suffisant : placer son
œuvre sous licence Art Libre requiert l'implémentation d'un court texte,
et des notations (Copyright, Année Nom de l'auteur ou nom de l'auteur
original). Un exemple est donné :

[Nom de(s) l'auteur(s), titre, date et le cas échéant, le
nom des auteurs de l'œuvre initiale et conséquentes ainsi
que leurs localisations] Copyleft : cette œuvre est libre,
vous pouvez la copier, la diffuser et la modifier selon les
termes de la Licence Art Libre http://www.artlibre.org.

L'étendue de la licence est relativement standard : les compilations
d'œuvres sont permises sans qu'une licence soit imposée pour le tout.
L'élément déclencheur est la diffusion (définie comme l'interprétation, la représentation ou la distribution).

De par leur copyleft, les versions antérieures à la LAL v. 1.3 ne sont pas compatibles avec une autre licence copyleft ou qui imposerait certaines restrictions supplémentaires (comme la licence CC By par exemple). Pour résoudre cette incompatibilité de fait, la LAL v. 1.3 introduit un nouvel article (5. « Critères de compatibilité ») grâce auquel, dès lors qu'il y a modification de l'œuvre, une compatibilité avec toute licence répondant à un certain nombre d'exigences (être une licence libre, copyleft, et réciproquement compatible envers la LAL) est possible. Actuellement, la licence CC By-SA v 3.0 est la seule susceptible d'être déclarée comme compatible, dès lors que le mécanisme qu'elle-même contient sera opérationnel (il faut notamment que la LAL soit indiquée comme compatible sur le site de Creative Commons).

## L'OpenDatabase License

La particularité des licences attachée à des bases de données réside dans l'(in)adaptation à leurs objets : les données — ou, plus précisément, un ensemble de données organisées sous forme de bases de données.

En effet, contrairement aux créations classiques (logiciels, articles, etc.), les données ne génèrent pas, en tant que telles, un quelconque droit de propriété intellectuelle au profit de celui qui les crée, les détient ou les exploite — sauf à ce qu'elles en réunissent les critères (elles sont alors des créations originales soumises au droit d'auteur — cette qualification concernant l'organisation globale de la base, mais non les extractions qui peuvent en être faites). Or, en l'absence de droit exclusif qui permettrait de conditionner chaque usage au respect du cadre contractuel défini, celui qui détient des données se trouve démuni face à toute personne qui aurait pris connaissance des données sans contracter.

C'est à cette problématique que tente de répondre l'ODbL, la licence faisant reposer son efficience sur une assiette plus large que le seul droit d'auteur, en incluant également le droit des contrats et le droit *sui generis* des bases de données (article 2.0, « Champ d'application de la présente
licence »). Ainsi, la condition essentielle de la licence, son *copyleft*, impose que toute base de données — modifiée ou non — soit distribuée sous la même licence. C'est cette prise de conscience qui a conduit le projet OpenStreetMap a mettre en place un processus de changement de licence au profit de l'ODbL.

La licence ne couvre néanmoins pas le contenu même de la base de données pris isolément. Une nouvelle licence peut alors y être associée (article 2.4, « Rapport avec le contenu de la base de données »), ni même les brevets ou marques qui pourraient y figurer (article 2.3, « Droits non compris dans la licence »).

## Droits et obligations

Tout accès, toute transmission ou toute publication d'une base de données (d'origine, dérivée ou en tant que partie d'une BdD collaborative) vaut acceptation de la licence.

L'utilisateur bénéfice ainsi de certains droits tout en étant tenu par certaines obligations.

## Droits

Tous les droits d'auteur et droits *sui generis* détenus sur la base de données sont cédés (non exclusivement) à l'utilisateur de la base. Il en est de même de tout autre droit inclus dans la base et dont la cession est nécessaire au respect de la licence (article 10.4).

La licence n'autorise pas les sous-licences (il n'y a pas de chaîne contractuelle : chaque titulaire cédant ses seuls droits à chaque utilisateur) et est bien sûr non exclusive (article 3.3).

## Obligations

Tout manquement aux obligations de la licence entraîne la résiliation de la licence (article 9.0, « Cessation de vos droits au titre de la présente licence ») — même si un processus de rétablissement des droits est prévu pour réintroduire les utilisateurs « repentants » dans leurs droits (les personnes dont les droits font l'objet d'une cessation permanente ne pouvant bénéficier d'une nouvelle licence).
## Copyleft (partage à l'identique des conditions initiales)

La base de données d'origine et les bases de données dérivées doivent être licenciées sous la même licence ou sous l'une des licences compatibles (article 4.4, « Partage à l'identique des conditions initiales »).

## Formalisme

La licence impose un certain formalisme relatif à l'utilisation des bases (ou des créations générées) et à leur transfert.

Ainsi, en cas d'utilisation publique d'une base de données (originale, dérivée ou collaborative) ou d'une création issue d'une telle base,

- il faut mentionner la licence et les bases de données sous ODbL utilisées;

- en présence d'une BdD dérivée, il faut rendre disponible une copie numérique de la totalité de celle-ci ou un fichier contenant toutes les modifications apportées.

Lors de la transmission de la BdD, il faut veiller à conserver les men-tions légales intactes et inclure une copie de l'ODbL ou de son URI (dans la BdD, originale ou dérivée, ou toute autre documentation pertinente). Le coût de cette transmission doit être raisonnable, voire gratuit en cas de distribution en ligne.

## Divers

La licence contient par ailleurs une interdiction de l'usage de mesures techniques de protection (MTP), sauf à rendre parallèlement disponible ladite base sans MTP, ainsi qu'une exclusion de garantie et une limitation de responsabilité totale (la portée de ces dernières étant limitée en France).

## Étendue

Au-delà de la base de données d'origine, la licence doit être étendue à toute base de données dite dérivée (base de données reposant sur la base originaire) et exploitée publiquement.
La licence permet néanmoins toute utilisation conjointe de plusieurs bases de données indépendantes. Il s'agit alors de bases de données col- laboratives et seules la base de données d'origine ou ses dérivées doivent être diffusées sous ODbL.

## Éléments déclencheurs

La licence n'impose aucune contrainte quant au transfert, à l'utilisation privée de la base de données ou à la conception de créations grâce à ladite base de données.

La licence prend ses pleins effets dès lors qu'il y a :

- transfert public de la base de données (la communication d'une copie, de la base à un tiers);

- l'utilisation publique (mise au contact de tiers) d'une base de données dérivée ou d'une création issue de cette base (originale, dérivée ou partie d'une base de données collaborative).

## Compatibilité

Un mécanisme de compatibilité expresse est prévu au sein de la licence, laissant à la charge du concédant le soin de préciser quelles sont les li- cences compatibles ou de désigner un mandataire qui le fera pour son compte (article 4.4e).

## PHP License v. 3.01

La licence PHP est une licence *open source* aujourd'hui utilisée en ver- sion 3.01¹. C'est une licence permissive, qui contient néanmoins quelques *obligations* en matière d'attribution :

- pour tout type de distribution, l'indication de l'utilisation du logiciel par la mention « This product includes PHP software, freely available from <http://www.php.net/software/> » ;

<footnote n="1">1. http://www.php.net/license/3_01.txt.</footnote>
- l'interdiction d'utiliser le mot PHP comme titre de toute création dérivée : « Products derived from this software may not be called 'PHP', nor may 'PHP' appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying 'Foo for PHP' instead of calling it 'PHP Foo' or 'phpfoo'. »

## OSL (Open Software License)

L'Open Software License<fnref n="1" /> (OSL) est une licence issue des travaux du juriste américain Lawrence E. Rosen. La version 1.1 date de 2002 et fut certifiée open source par l'Open Source Initiative (OSI), mais fut déclarée incompatible avec la DFSG par la communauté Debian. La version 2.0 date de 2003, et la dernière version — la troisième — de 2005 (elle prend notamment en compte les remarques de la Commission européenne).

Cette licence permet expressément les sous-licenciements, mais ceux-ci doivent impérativement se faire sous la même licence.

En termes d'obligations, la licence est gratuite (mais la communication de l'œuvre peut être payante), non exclusive et perpétuelle et porte sur les droits d'auteur comme sur ceux des brevets contenus dans le code soumis à la licence (la licence cherche à créer ici un pot commun de brevets, équivalent à celui issu de l'usage des licences copyleft). Quiconque poursuit l'auteur original ou ses utilisateurs pour violation de brevet contenu dans le logiciel soumis à cette licence voit toutes les licences qui lui étaient accordées se terminer immédiatement. Enfin, la licence incorpore une limitation — et non pas une exclusion — de garantie (de la provenance des sources) et de responsabilité à l'égard du concédant, solution bien plus pragmatique puisqu'il s'agit de ce qui est, dans les faits, le minimum légal. Toutes les actions ou poursuites doivent se faire devant un tribunal de la juridiction du lieu où le concédant exerce son activité principale. Par ailleurs, tous les frais d'avocats seront à la charge de la partie qui poursuit. Enfin, la licence OSL est de type copyleft.

L'étendue de la licence n'est pas contractuellement définie et renvoie expressément à la définition de l'œuvre dérivée dans la loi américaine

<footnote n="1">1. http://www.opensource.org/licenses/OSL-3.0.</footnote>
<figure><img src="image_56.png" /></figure>
Annexes
<figure><img src="image_57.png" /></figure>
# ANNEXE A

## Tableaux de compatibilité

(Voir les deux pages suivantes)
## Compatibilité entre licences (a)

Lecture du tableau : peut-on, à partir d'une licence A (licence d'origine), distribuer sous une autre licence B (licence de distribution) ?

<figure><img src="image_58.png" /><figcaption>FIGURE 1.1 - Table de compatibilité entre licences</figcaption></figure>
## Compatibilité entre licences (documentation)

Lecture du tableau : peut-on, à partir d'une licence A (licence d'origine), distribuer sous une autre licence B (licence de distribution)

<figure><img src="image_59.png" /><figcaption>FIGURE 1.2 - Table de compatibilité entre licences (documentation)</figcaption></figure>
<figure><img src="image_60.png" /></figure>
# ANNEXE B

## Glossaire

Ce glossaire est basé sur le glossaire trilingue réalisée par Fanny Mourguet et Griselda Jung de la société ATIT pour l'association Veni, Vidi, Libri (sous double licence GNU GFDL 1.2 et LAL 1.3)

**Agrégat logiciel** : ensemble de contenus logiciels, ayant chacun une spécificité qui se complètent entre eux et qui ne peuvent fonctionner que réunis.

**Auteur** : personne, entreprise ou collectif créateur d'une application originale ou dérivée, qui va décider du type de licence à laquelle soumettre son œuvre.

**Bibliothèque (a)** : ensemble de fonctions regroupées pour réaliser un groupe de tâches du même domaine. (source : Wikipedia)

**Bibliothèque (b)** : en informatique, une bibliothèque ou librairie logicielle (ou encore, bibliothèque de programmes) est un ensemble de fonctions utilitaires, regroupées et mises à disposition afin de pouvoir être utilisées sans avoir à les réécrire. Les fonctions
sont regroupées par leur appartenance à un même domaine conceptuel (mathématique, graphique, tris, etc). Elles se distinguent d'un programme en ce qu'elles ne peuvent s'exécuter directement, et sont généralement utilisées simultanément par de nombreux programmes. (source : Wikipedia)

**Bien commun** : interêt général, ou ce qui n'appartient à personne mais qui est partagé par tous.

**Certification** : dans l'aéronautique, la certification définit les conditions de sécurité applicables aux logiciels critiques de l'avionique dans l'aviation commerciale et l'aviation générale. Elles précisent notamment les contraintes de développement liées à l'obtention de la certification d'un logiciel d'avionique. (source : Wikipedia)

**Code source** : ensemble d'instructions écrites dans un langage de programmation informatique de haut niveau, c'est-à-dire humainement compréhensible, permettant d'obtenir un programme pour un ordinateur. (source : Wikipedia)

**Code objet** : suite d'instructions en langage binaire, uniquement compréhensible par l'ordinateur qui va l'utiliser pour exécuter le programme. Résultat de la compilation du code source.

**Compilation** : transformation, à l'aide d'un compilateur, d'un code source en un langage binaire exécutable par une machine.

**Contributeur** : un des acteurs de la communauté du Libre, qui participe à l'élaboration d'une création en y apportant sa contribution.

**Contribution** : toute participation (modification, ajout, correction...) apportée par un contributeur à l'élaboration d'une création.

**Coopétition** : technique de gestion alliant la stratégie de la collaboration à celle de la concurrence, par laquelle deux entreprises concurrentes peuvent développer un partenariat.

**Copie verbatim** : reproduction intégrale sans changement d'aucune sorte.

**Culture libre** : courant de pensée défendant la libre diffusion et l'appropriation collective des œuvres de l'esprit par opposition aux limites contractuellement « imposées » par le copyright et les brevets. Elle est issue du logiciel libre.
**Déploiement externe (a) :** utilisation, distribution ou communication d'une œuvre originale ou dérivée à d'autres utilisateurs, que cette œuvre soit communiquée, distribuée ou mise à la disposition de ces utilisateurs en tant que programme destiné à l'utilisation par un réseau.

**Déploiement externe (b) :** utilisation d'un logiciel pour fournir un service à des utilisateurs via le réseau.

**Développeur :** personne, entreprise ou collectif qui réalise une application en utilisant un langage de programmation. (source : Wikipedia)

**Distribution (a) :** ensemble de logiciels formant un tout cohérent et prêts à installer, incluant des jeux de paquetages, le noyau du système d'exploitation [...], un système d'installation et des utilitaires de configuration. (source : Wikipedia)

**Distribution (b) :** diffusion ou communication à un tiers d'une copie de la création.

**Documentation :** ensemble de documents élaborés par l'éditeur de progiciel et le fournisseur de système et comprend notamment le guide utilisateur et la documentation technique.

**Droit d'auteur :** prérogative attribuée à l'auteur d'une œuvre de l'esprit [comportant] un droit pécuniaire (droit de tirer profit de l'œuvre) et un droit moral. (source : GUILLIEN (R.) et VINCENT (J.), *Lexique des termes juridiques*, Paris, Dalloz, 2005)

**Droits moraux :** droits qui protègent la personnalité de l'auteur par rapport à son œuvre. (source : Wikipedia)

**Droits patrimoniaux :** attributs du droit d'auteur qui permettent à l'autre d'autoriser ou d'interdire l'exploitation de son œuvre, généralement contre rémunération. Ces droits peuvent être cédés à des tiers, que ce soit à titre onéreux ou à titre gratuit. (source : http://bibliodoc.francophonie.org)

**Élément déclencheur :** action par laquelle le logiciel sort de la « sphère privée » de son utilisateur.

**Environnement :** état du système défini par des ressources allouées à un programme et un ensemble de valeurs associées à des variables d'environnement auxquelles ce programme a accès. (source : Wikipedia)
**Espace d'adressage** : plage des adresses auxquelles un processeur ou une tâche peut accéder, ou auxquelles un dispositif matériel peut être atteint. Le terme peut aussi bien faire référence à une adresse physique qu'à une adresse virtuelle. La taille de l'espace d'adressage d'un processeur dépend de la largeur de son bus d'adresse et de ses registres.

**Fichier source** : fichier texte contenant les lignes de code d'un logiciel, écrites par un (ou des) programmeur(s), dans un langage de programmation donné.

**FLOSS** : (Free/Libre Open Source Software), expression désignant les logiciels reconnus comme libres selon les critères de la Free Software Foundation (FSF) et ceux de l'Open Source Initiative (OSI).

**Fork** : projet informatique possédant une racine commune avec un autre projet et engendrant souvent la mort de ce dernier. (source : *Linux Pratique hors série*, décembre 2006 — janvier 2007)

**Format ouvert** : tout protocole de communication, d'interconnexion ou d'échange et tout format de données operable et dont les spécifications techniques sont publiques et sans restriction d'accès ni de mise en œuvre. (source : Loi n°2004-575 du 21 juin 2004, *Pour la confiance dans l'économie numérique*)

**Gouvernance** : ensemble de méthodologies, méthodes et outils utilisés pour contrôler un processus.

**Graticiel** : logiciel mis gratuitement à disposition par son créateur, mais soumis à certaines contraintes quant à sa diffusion. Il peut s'agir d'un logiciel complet ou d'un logiciel commercial diffusé de manière bridée en termes de fonctionnalités.

**Interopérabilité** : l'interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes existants ou futurs et ce sans restriction d'accès ou de mise en œuvre (source : Groupe de travail Interop. de l'AFUL). Il convient de distinguer *interopérabilité et compatibilité*. On peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble, et interopérabilité quand on sait pourquoi et comment ils peuvent fonctionner ensemble. Il n'existe donc d'interopérabilité d'un produit
ou d'un système que si on en connaît intégralement toutes ses inter-
faces. La notion de compatibilité est donc verticale et généralement
employée au bénéfice d'un produit unique (par exemple : « compat-
ible Windows XP »).

**Licence** : contrat définissant les droits d'utilisation ou d'exploitation accordés à un tiers (le licencié) par les ayants droit d'un logiciel. Ce contrat peut définir notamment les conditions de fourniture (ex. : avec ou sans le code source), d'installation (ex. : nombre d'exemplaires), d'utilisation (ex. utilisation commerciale), de reproduction et de représentation (ex. exécution, adaptation, rediffusion), et les conditions de garantie. — Accord légal par lequel est accordé à quelqu'un l'autorisation d'utiliser une œuvre à certaines fins ou à certaines conditions. Une licence ne constitue pas un transfert de propriété du droit d'auteur. (source : http://strategis.ic.gc.ca)

**Licence absorbante** : licence dont l'ensemble des droits est inclus dans l'ensemble des droits conférés par une licence compatible et dont l'ensemble des obligations inclut l'ensemble des obligations imposées par cette licence compatible.

**Licence académique** : licence permissive reprenant l'idée de partage des connaissances par les universités. Le logiciel soumis à ce type de licence peut être réutilisé sans restriction dans son ensemble ou en partie dans une nouvelle œuvre sous licence libre ou sous licence propriétaire.

**Licence communautaire** : type de licence permissive, comportant des obligations pour le licencié, et propre à un projet, donc très spécifique.

**Licence compatible** : licence comportant des droits et obligations compatibles avec les droits et obligations d'une licence absorbante à laquelle une même œuvre serait soumise.

**Licence copyleft** : licence d'exploitation permettant la libre utilisation, modification et distribution de l'oeuvre qui y est soumise. Ce type de licence oblige le licencié à redistribuer l'œuvre sous le même type de licence, qu'il l'ait modifiée ou non.

**Licence de culture libre** licence qui s'applique à transposer à d'autres formes d'œuvres le mécanisme des licences libres.
**Licence institutionnelle** licence permettant l'utilisation d'un même logiciel en réseau, sur un nombre illimité d'ordinateurs, à condition qu'ils appartiennent tous à la même entité.

**Licence libre** : licence s'appliquant à une œuvre de nature quelconque pour en faire un contenu libre offrant à l'utilisateur certains droits quant à l'utilisation, à la modification, à la rediffusion et à la réutilisation de l'œuvre dans des œuvres dérivées. (source : Wikipedia)

**Licence open source** : licence respectant les critères établis par l'Open Source Initiative, qui sont : la libre redistribution, la mise à disposition du code source, la possibilité d'effectuer des travaux dérivés et des modifications, l'intégrité du code source de l'auteur, l'absence de discrimination à l'encontre des personnes ou des groupes, l'absence de discrimination par rapport aux domaines d'application, la distribution de la licence, la non-spécificité à un produit et la non-contamination d'autres logiciels. (source : LinuxFr)

**Licence permissive** : type de licence conférant un maximum de droits au licencié tout en ne lui imposant que peu d'obligations (limitées au code source original).

**Lien dynamique** : fonction permettant de charger la bibliothèque utile à un programme, stockée dans un fichier séparé, uniquement lorsque celui-ci en a besoin.

**Lien statique** : fonction permettant au logiciel de faire appel au contenu de la bibliothèque, qui fait partie intégrante de ce dernier.

**Logiciel** : ensemble des programmes et des procédures nécessaires au fonctionnement d'un système informatique (source Le Petit Robert, 2000). — Création ou œuvre de l'esprit pouvant être soumise par son auteur à une licence de droit d'auteur, de copyright ou à une licence libre.

**Logiciel embarqué** (ou firmware, ou microgiciel, ou logiciel interne) : ensemble d'instructions et de structures de données qui sont intégrées dans du matériel informatique (disque dur, routeur, caméra, lecteur DVD, etc.). (source : Wikipedia)

**Logiciel libre** : logiciel qui donne à toute personne, qui en possède une copie, le droit de l'utiliser, de l'étudier, de le modifier et de le redistribuer. (source : Wikipedia)
**Module** : un module en programmation désigne un espace de noms. Chaque module peut exporter ou importer certains symboles comme des variables, des fonctions ou des classes. Les modules peuvent se regrouper en package éventuellement hiérarchique. (source : Wikipedia)

**Multilicencciement** : technique qui consiste, pour [un] titulaire de droits, à consentir plusieurs licences non exclusives sur une même œuvre.

**Œuvre collective** : œuvre qui réuni une pluralité d'apports tout en étant in fine la propriété d'un seul. Cette qualification se retrouve lorsqu'une œuvre est créée à l'initiative et sous sa direction d'une personne, physique ou morale, et que la fusion des contributions entraîne l'impossibilité d'attribuer à chaque auteur des droits distincts sur l'ensemble. (Source : Art. L113-2 CPI)

**Œuvres de collaborations** : une œuvre de collaboration est une œuvre de l'esprit à la création de laquelle ont contribué plusieurs auteurs. (source : Art. L113-2 CPI)

**Œuvre dérivée** : œuvre créée à partir d'une œuvre déjà existante. — Œuvre nouvelle à laquelle est incorporée une œuvre préexistante sans la collaboration de l'auteur de cette dernière. — Une œuvre composite est la propriété de l'auteur qui l'a réalisée, sous réserve des droits de l'auteur de l'œuvre préexistante.

**Partagiciel** : logiciel téléchargeable gratuitement, généralement avec une limitation du nombre d'utilisations, du temps d'utilisation ou encore du nombre de fonctionnalités disponibles, et dont l'utilisation normale peut être prolongée moyennant le paiement d'une licence.

**Plug-in** (ou greffon, ou add-on) : en informatique, un plug-in est un programme qui interagit avec un logiciel principal (...) pour lui apporter de nouvelles fonctionnalités. (source : Wikipedia)

**Programme** : séquence d'instructions codée sous forme binaire, décrivant une tâche à accomplir par un ordinateur.

**Propriété intellectuelle** : ensemble composé, d'une part, des droits de propriété industrielle et, d'autre part, du droit d'auteur. (source : GUILLIEN (R.) et VINCENT (J.), *Lexique des termes juridiques*, Paris, Dalloz, 2005)
**Processus** : la notion de *process*, ou de processus, intervient lors de l'exécution du logiciel dans l'environnement système et définit un programme en cours d'exécution ou d'opération. Un rassemblement de processus permet de reconstituer les logiciels lors de leur exécution. — Un processus est une unité d'exécution, c'est à dire de partage du temps processeur et de la mémoire. On retrouve parfois la traduction de *process* par la notion de tâche.

**Réseau** : moyen technique permettant la diffusion d'un logiciel afin de le rendre accessible aux contributeurs et/ou utilisateurs.

**Sous licenciement** : action autorisée par certaines licences qui consiste à accorder au licencié, en plus des droits qui lui ont été cédés, le droit de céder ces mêmes droits au profit des licenciés ultérieurs.

**Sphère privée** : concerne toutes les utilisations permises car exclues, par la loi ou par contrat, du monopole légal de l'auteur (ou tout autre titulaire de droit).

**Système collaboratif** : mode de participation basé sur le partage des connaissances, grâce auquel de multiples acteurs interagissent, dans un but commun.

**Système d'exploitation** : ensemble de programmes responsables de la liason entre les ressources matérielles d'un ordinateur et les applications de l'utilisateur.

**Utilisateur** : toute personne (physique ou morale) utilisant un produit logiciel sans y apporter de modification.

**Wiki** : site web dynamique dont tout visiteur peut modifier les pages à volonté et qui permet non seulement de communiquer et diffuser des informations rapidement (ce que faisait déjà Usenet), mais aussi de structurer cette information pour permettre d'y naviguer commodément. Il réalise donc une synthèse des forums Usenet, des FAQ et du Web en une seule application intégrée (et hypertexte). (source : Wikipedia)
Bibliographie

AIGRAIN, Philippe, *Cause commune : l'information entre bien commun et propriété*, Paris : Fayard, 2005.

- *Internet et Création. Comment reconnaître les échanges hors-marché sur internet en finançant et rémunérant la création?*, Paris : In Libro Veritas, 2008, URL : http://paigrain.debatpublic.net/?page_id=171.

ANDERSON, C., *Free : The Future of a Radical Price*, New York : Hyperion, 2009.

- « Free ! Why $ 0.00 Is The Future of Business », dans : *Wired Magazine* (2008).

- *The Long Tail. Why the Future of Business is Selling Less of More*, New York : Hyperion, 2008.

APRIL, *Livre Blanc. Les modèles économiques du logiciel libre*, rap. tech., 2007, URL : http://www.april.org.

ARTISTIQUE, Conseil Supérieur de la Propriété Intellectuelle et, *La mise à disposition ouverte des œuvres de l'esprit*, Paris : CSPLA, 2007.

BESSEN, J., *A generation of software patents* (*Working Paper No.11-31*), Boston : Boston University School of Law, 2011.
BONA, C. di, *Tribune libre. Les ténors de l'informatique libre*, Paris : In Libro Veritas, 2006, URL : http://www.ilv-bibliotheca.net.

BRADLEY, M. K., A. WILLIAMSON et K. M. SANDLER, *A Practical Guide to GPL Compliance*, New York : Software Freedom Law Center, 2008, URL : http://www.softwarefreedom.org.

BRUGUIÈRE, J. et M. VIVANT, *Droit d'auteur*, Paris : Dalloz, 2009.

CHOISY, S., *Le domaine public en droit d'auteur*, Paris : Litec, 2002.

CLÉMENT-FONTAINE, M., « Les œuvres libres », thèse de doct., Montpellier : Université de Montpellier, 2006.

COOL, Y. et al., *Les logiciels libres face au droit*, Paris : Bruylant, 2005.

FOGEL, K., *Produire du logiciel libre*, Paris : Framasoft / Framabook, 2010.

GHOSH, R.A., éd., *CODE. Collaborative Ownership and the Digital Economy*, Boston : MIT Press, 2005.

JULLIEN, N., « Impact du logiciel libre sur l'industrie informatique », thèse de doct., Brest : Université de Bretagne Occidentale, 2001.

KELLY, K., *New Rules for the New Economy. 10 Radical Strategies for a Connected World*, New York : Penguin Group, 1999, URL : http://www.kk.org/newrules.

LATRIVE, F., *Du bon usage de la piraterie : culture libre, sciences ouvertes*, Paris : Exils, 2004.

LEMLEY, M. A., « The Myth of the Sole Inventor », dans : *Stanford Public Law Working Paper*, 2011, URL : http://ssrn.com/abstract=1856610.

LESSIG, L., *L'avenir des idées : Le sort des biens communs à l'heure des réseaux numériques*, Paris : Presses Universitaires de Lyon, 2005.

LINDBERG, V., *Intellectual Property and Open Source – A Practical Guide to Protecting Code*, Cambridge : O'Reilly Media, 2008.

LÉVY, M. et J. JOUYET, *L'économie de l'immatériel, la croissance de demain*, Paris : La Documentation Française, 2006, URL : http://www.ladocumentationfrancaise.fr.

MACREZ, F., « Créations informatiques : bouleversement des droits de propriété intellectuelle ? Essai sur la cohérence des droits », thèse de doct., Montpellier : Université de Montpellier, 2007.
MOREAU, A., « Le copyleft appliqué à la création hors logiciel. Une re-
formulation des données culturelles », thèse de doct., Nice : Université
Sophia-Antipolis, 2011.

MURRAY, G.F., « Categorization of Open Source Licenses : More than
Just Semantics », dans : *The Computer and Internet Lawyer* **26** (2009),
page(s): 1–12.

ROSEN, W., *The Most Powerful Idea in the World : A Story of Steam, Industry, and Invention*, New York : Random House, 2010.

SCHEPENS, P., *Guide sur la gestion collective des droits d'auteur*, Un-
esco, 2000, URL : http://unesdoc.unesco.org.

SMIERS, J. et M. van SCHIJNDEL, *Un monde sans copyright... et sans
monopole*, Paris : Framasoft / Framabook, 2011, URL : http://
framabook.org.

STALLMAN, R. M., C. MASUTTI et S. WILLIAMS, *Richard Stallman et
la révolution du logiciel libre. Une biographie autorisée*, Eyrolles / Fra-
masoft, 2010, URL : http://framabook.org.

STOVELAND, J. F., « Managing Firm-Sponsored Open Source Commu-
nities. A Case Study on Novell and The openSUSE Project », thèse de
doct., Oslo : Université d’Oslo, 2008.

STROHMEYER, R., « 11 Milestones in Linux History », dans : *InformationWeek* (2011), URL : http://www.informationweek.com.

THOUMSIN, P., « Creative Commons. Le meilleur des deux mondes ? », dans : *droit-technologie.org* (2008), URL : http://www.droit-technologie.org/dossier-183/.

VIVANT, M., éd., *Les créations immatérielles et le droit*, Paris : Ellipses, 1997.

– éd., *Propriété intellectuelle et mondialisation. La propriété intellectuelle est-elle une marchandise ?*, Paris : Dalloz, 2004.

VIVANT, M. et J. BRUGUIÈRE, *Protéger les inventions de demain. Biotechnologies, logiciels et méthodes d'affaires*, Paris : La Documentation Française, 2003.
<figure><img src="image_61.png" /></figure>
Table des matières

Remerciements iii

Préface v

Quelques acronymes et abréviations utilisés ix

Introduction générale xiii

# I Le cadre légal associé aux créations de l'esprit 1

## 1 Le bénéfice d'une propriété littéraire et artistique 9

1.1 L'œuvre relevant du droit d'auteur 10

1.1.1 La qualification d'œuvre 11

1.1.2 L'équilibre du droit d'auteur 14

1.2 Les créations auxiliaires soumises aux droits voisins 32

1.2.1 Les différentes qualifications des droits voisins 33

1.2.2 L'équilibre commun aux droits voisins 34

1.3 Les mesures techniques de protection et d'information 37

1.3.1 Qualification des mesures techniques de protection et d'information 37

1.3.2 L'équilibre au regard de la protection des mesures techniques 39

1.4 Les bases de données donnant accès à un droit *sui generis* 41

1.4.1 La qualification de base de données 42

1.4.2 L'équilibre du droit *sui generis* des bases de données 42
<table><tr><td>2</td><td>L'acquisition de titres de propriété industrielle</td><td>45</td></tr><tr><td>2.1</td><td>Les brevets et certificats d'utilité délivrés sur des inventions</td><td>47</td></tr><tr><td>2.1.1</td><td>La délivrance de brevets sur des inventions</td><td>49</td></tr><tr><td>2.1.2</td><td>La délivrance de certificats d'utilité sur des inventions</td><td>58</td></tr><tr><td>2.2</td><td>Le dépôt de topographies de produits semi-conducteurs</td><td>59</td></tr><tr><td>2.2.1</td><td>La qualification de topographies de produits semi-conducteurs</td><td>60</td></tr><tr><td>2.2.2</td><td>L'équilibre du droit des topographies de produits semi-conducteurs</td><td>60</td></tr><tr><td>2.3</td><td>La délivrance de certificats d'obtentions végétales</td><td>61</td></tr><tr><td>2.3.1</td><td>La qualification d'obtentions végétales</td><td>61</td></tr><tr><td>2.3.2</td><td>L'équilibre du certificat d'obtention végétale</td><td>63</td></tr><tr><td>2.4</td><td>Le dépôt de signes distinctifs</td><td>64</td></tr><tr><td>2.4.1</td><td>La marque, protection individuelle de prédilection</td><td>65</td></tr><tr><td>2.4.2</td><td>Les protections collectives d'un signe distinctif, les marques...</td><td>71</td></tr><tr><td>2.5</td><td>Le dépôt de dessins et modèles</td><td>73</td></tr><tr><td>2.5.1</td><td>La qualification de dessin ou modèle</td><td>73</td></tr><tr><td>2.5.2</td><td>L'équilibre du droit des dessins et modèles</td><td>74</td></tr></table>

<table><tr><td>II</td><td>Le système construit par les licences libres</td><td>75</td></tr><tr><td>1</td><td>La maturation d'un nouvel équilibre grâce aux licences libres</td><td>79</td></tr><tr><td>1.1</td><td>L'affirmation de nouveaux usages</td><td>79</td></tr><tr><td>1.1.1</td><td>La remise en question de la propriété intellectuelle classique</td><td>80</td></tr><tr><td>1.1.2</td><td>La structuration d'un équilibre différent sur la base du système existant</td><td>104</td></tr><tr><td>1.2</td><td>Les différentes écoles de pensée</td><td>114</td></tr><tr><td>1.2.1</td><td>La Free Software Foundation et l'école du logiciel libre</td><td>114</td></tr><tr><td>1.2.2</td><td>L'Open Source Initiative et l'école de l'open source</td><td>119</td></tr><tr><td>1.2.3</td><td>L'art libre ou le Libre sur les œuvres non logicielles</td><td>123</td></tr><tr><td>1.2.4</td><td>Le mouvement Creative Commons</td><td>131</td></tr><tr><td>1.2.5</td><td>L'extension du libre au-delà de la création</td><td>138</td></tr><tr><td>1.3</td><td>L'impulsion favorable des puissances politiques publiques</td><td>161</td></tr><tr><td>1.3.1</td><td>L'impulsion des puissances publiques en faveur du logiciel libre</td><td>162</td></tr><tr><td>1.3.2</td><td>Les standards ouverts</td><td>171</td></tr><tr><td>1.3.3</td><td>L'impulsion publique en faveur de l'open data</td><td>172</td></tr><tr><td>2</td><td>Les bons repères pour s'orienter parmi les licences libres</td><td>185</td></tr><tr><td>2.1</td><td>Qualifier juridiquement les licences libres</td><td>186</td></tr><tr><td>2.1.1</td><td>Un engagement juridique</td><td>187</td></tr><tr><td>2.1.2</td><td>Une cession non exclusive de droits</td><td>198</td></tr><tr><td>2.1.3</td><td>Quelques jugements</td><td>198</td></tr><tr><td>2.2</td><td>Caractériser par une classification des licences libres</td><td>201</td></tr><tr><td>2.2.1</td><td>Classification classique : licence copyleft versus permissive</td><td>201</td></tr><tr><td>2.2.2</td><td>Classification historique</td><td>203</td></tr></table>
<table><tbody><tr><td>2.2.3</td><td>Classification par domaine</td><td>204</td></tr><tr><td>2.2.4</td><td>Classification par libertés</td><td>206</td></tr><tr><td>2.3</td><td>Déchiffrer : une grille de lecture de licences libres</td><td>207</td></tr><tr><td>2.3.1</td><td>Les droits et obligations des licences libres</td><td>208</td></tr><tr><td>2.3.2</td><td>L'étendue des licences libres</td><td>216</td></tr><tr><td>2.3.3</td><td>L'élément déclencheur des licences libres</td><td>226</td></tr><tr><td>2.3.4</td><td>La compatibilité au sein des licences libres</td><td>230</td></tr><tr><td><b>3</b></td><td><b>Les bons réflexes</b></td><td><b>237</b></td></tr><tr><td>3.1</td><td>Les réflexes préalables à la diffusion</td><td>238</td></tr><tr><td>3.1.1</td><td>Apprécier le cadre juridique induit par les licences libres</td><td>239</td></tr><tr><td>3.1.2</td><td>Respecter le formalisme lié à l'utilisation des licences libres</td><td>250</td></tr><tr><td>3.2</td><td>Diffuser sous licences libres</td><td>257</td></tr><tr><td>3.2.1</td><td>Se positionner dans l'écosystème du logiciel libre</td><td>257</td></tr><tr><td>3.2.2</td><td>Organiser la diffusion (accompagner l'ouverture du code)</td><td>274</td></tr><tr><td><b>III</b></td><td><b>Quelques études de licences libres</b></td><td><b>283</b></td></tr><tr><td><b>Annexes</b></td><td></td><td><b>315</b></td></tr><tr><td><b>A</b></td><td><b>Tableaux de compatibilité</b></td><td><b>315</b></td></tr><tr><td><b>B</b></td><td><b>Glossaire</b></td><td><b>319</b></td></tr><tr><td><b>Bibliographie</b></td><td></td><td><b>327</b></td></tr></tbody></table>