INRIA Licence de logiciels libres Mode d'emploi

Page 1 sur 18

GUIDE D’APPROCHE ET D’ANALYSE DES LICENCES DE

LOGICIELS LIBRES

Version 2.0

Sylvain STEER

-

Magali FITZGIBBON

http://creativecommons.org/licenses/by-nc-nd/2.0/fr/

© INRIA – S. Steer – M. Fitzgibbon

Glossaire

- logiciel : le terme est ici employé dans une acception générique : il désigne tout ensemble de programmes informatiques, que ce soit en code source ou en code objet, qui constitue une

œuvre protégeable par le droit d'auteur sur laquelle des droits peuvent être concédés.

L'étude ne portant que sur les questions relatives aux logiciels ce terme a été préféré à celui d'"œuvre".

- logiciel dérivé : désigne un logiciel dont le code source, contenu dans les fichiers du logiciel, a

été modifié par dérivation.

- dérivation : modification faite au code source contenu dans un ou plusieurs fichiers d’un logiciel ou nouveau fichier source contenant du code source préexistant.

- logiciel composé/logiciel à composants : désigne un logiciel au sein duquel ont été assemblés d’autres composants logiciels.

- composition : assemblage de différents composants au sein d’un même logiciel. Ceci ne se limite pas aux composants liés dynamiquement, il peut également s’agir de composants liés statiquement ou l’introduction d’un nouveau fichier source dans le logiciel.

- logiciel modifié : désigne sans distinction un logiciel dérivé ou composé.

- bibliothèque : désigne un composant logiciel regroupant un ensemble de fonctionnalités, regroupées et ainsi mises à disposition, sans avoir à les réécrire dans le code source du logiciel.

Ce dernier fera appel aux fonctionnalités de la bibliothèque lorsqu’il en aura besoin.

- code source : désigne le langage informatique intelligible par l’homme, lui permettant d’écrire les différentes fonctionnalités d’un logiciel.

- code objet : désigne le code traduit lors de la phase de compilation, de façon à être intelligible pour la machine, et permettre à cette dernière d’exécuter le programme.

- compatibilité supérieure : désigne la capacité du Logiciel sous Licence d'être soumis ou de

« cohabiter » avec les termes d'une autre licence, en liant ce Logiciel à un autre soumis à une licence propre.

(Ex : capacité d'un logiciel sous licence BSD d'être soumis à la licence GNU GPL = compatibilité supérieure de la licence BSD vers la licence GNU GPL)

- compatibilité inférieure : désigne la capacité de la Licence d'accueillir des composants logiciels soumis à d'autres licences au sein d'un même logiciel à composants soumis à cette

Licence.

(Ex : capacité de la licence GNU GPL à accueillir du code sous licence BSD ou sous licence CeCILL = compatibilité inférieure de la licence GNU GPL envers la licence BSD et la licence CeCILL)

Page 2 sur 18 © INRIA – S. Steer – M. Fitzgibbon

- compatibilité expresse : désigne la compatibilité supérieure qui ne découle pas de la permissivité de la Licence mais d'une clause expresse indiquant une compatibilité avec une (ou plusieurs) licence(s) précise(s).

(Ex : compatibilité expresse de la licence CeCILL envers la licence GNU GPL)

- composant logiciel/module : désigne un composant logiciel constituant une part identifiable au sein d’un logiciel qui permet de réaliser des fonctionnalités ou services identifiés au sein du

Logiciel.

- concédant : désigne toute personne (physique ou morale) détenant des droits sur un logiciel qui va concéder certains de ses droits par le biais d'une licence.

*concédant initial : désigne le concédant sur un logiciel initial.

*sous-concédant : désigne le concédant sur un logiciel dérivé / modifié ou éventuellement le

« simple » redistributeur du logiciel, qui n’aurait apporté aucune contribution.

- contribution : désigne l'ensemble des interventions et changements apportés à un logiciel par un contributeur. Il peut s’agir de modifications, corrections, traductions, adaptations, ajouts de nouvelles fonctionnalités, intégration d'un autre logiciel ou de toute autre intervention sur le logiciel susceptible d'être considérée comme une œuvre.

- contributeur : désigne toute personne qui apporte une contribution à un logiciel.

-

copyleft : par opposition à la notion de « copyright », ce terme signifie que l’auteur d’une

œuvre (logiciel ou autre) donne l’autorisation de copier, modifier, utiliser et redistribuer son

œuvre dans la mesure où ces possibilités ne sont pas remises en cause (l’œuvre en question, modifiée ou pas, ne pas être redistribuée avec des restrictions aux libertés précitées).

- distribution : désigne toute transmission ou mise à disposition du logiciel à toute personne physique ou morale (la seule possibilité d'utilisation d'un Logiciel par le biais d'un réseau ne constitue donc pas une distribution).

- DRM / MTP : Digital Right Management / Mesures Techniques de Protection : dispositifs techniques permettant de contrôler l’utilisation qui est faite d’une d’œuvre (et notamment d’empêcher d’en faire des copies).

- interface des bibliothèques : désigne les headers qui annoncent les fonctions et les objets d’une bibliothèque, ce qui permet au développeur de les utiliser, quand bien même il n’a accès qu’au code objet de la bibliothèque.

- licence : désigne ici le contrat que le détenteur des droits sur un logiciel (concédant) va proposer afin de concéder certains droits à ses cocontractants (licenciés) leurs permettant ainsi de réaliser certaines opérations sur le logiciel en contrepartie du respect des conditions et obligations prévues dans ce contrat.

- licencié : désigne toute personne qui souscrit à une licence, s'engageant à en respecter les obligations, afin de pouvoir exercer les droits qu'elle confère sur un logiciel.

Page 3 sur 18 © INRIA – S. Steer – M. Fitzgibbon

*licencié initial : licencié qui a souscrit une licence émanant du concédant initial.

*sous-licencié : licencié qui a souscrit une licence émanant d'un sous-concédant.

- « linking » : édition de liens permettant de faire appel à une ou plusieurs fonctionnalités de composants d’un logiciel.

- lien statique : édition de liens réalisée lors de la dernière phase de compilation, qui permet de

« recopier » le code objet de différents composants, dans le même fichier exécutable.

- lien dynamique : édition de lien qui permet à un composant 1, après compilation, de faire appel à une ou plusieurs fonctionnalités d’un autre composant 2 (ex. une bibliothèque), sans les recopier dans le fichier exécutable du composant 1.

- Logiciel / Licence / Concédant / Licencié / Contribution / Contributeur : en présence d'une majuscule l'ensemble de ces termes s'appliquent spécifiquement à LA Licence expressément

étudiée et au Logiciel qui lui est soumis.

- module externe

: désigne tout module, qui n’est ni dérivé, ni lié, ni combiné à un logiciel mais qui interagit néanmoins avec ce dernier, et qui doit par conséquent être considéré comme une logiciel indépendant. A défaut de l’existence d’une définition arrêtée et reconnue sur le plan juridique, la limite entre un module lié ou combiné et un module externe est parfois difficile à déterminer.

Page 4 sur 18 © INRIA – S. Steer – M. Fitzgibbon

Liste des Abréviations Utilisées

ADAE (ex ATICA) : Agence pour le Développement de l’Administration Electronique (Ex Agence pour les Technologies de l’Information et de la Communication dans l’Administration)

L’ADAE a cessé d’exister en 2005. Elle a été remplacée par la DGME.

CE : Commission Européenne

FSF : Free Software Foundation

NE : Non Envisagé (par la Licence)

OSI : Open Source Initiative

Abréviations de nom de licences logiciel libre :

GNU AGPL : Gnu Affero General Public License

BSD : Berkeley Software Distribution

CeCILL (-B, -C) : CEA CNRS INRIA Logiciel Libre

CPL : Common Public License

EPL : Eclipse Public License

EUPL : European Union Public License

GNU GPL : GNU General Public License

GNU LGPL : Lesser General Public License

MPL : Mozilla Public License

OSL : Open Software License

QPL : Qt Public License

********

Ce guide a pour objectif de proposer une approche et une méthode d’analyse des licences libres, afin d’en assurer une meilleure compréhension et une meilleure mise en œuvre. Néanmoins, il ne s’agit que d’une analyse qui résulte d’une interprétation des auteurs de ce guide, qui ne saurait engager la responsabilité de ces derniers ou celle de l’INRIA.

En tout état de cause, il est important de consulter systématiquement un juriste pour toute demande de conseil ou d’expertise pour l’analyse d’une licence libre, au regard d’une situation donnée.

Page 5 sur 18 © INRIA – S. Steer – M. Fitzgibbon

INTRODUCTION

Le développement de logiciels utilisant des composants préexistants reçoit une attention croissante, notamment dans le domaine de la Recherche où il facilite la mise au point rapide de prototypes. Le phénomène du « libre » contribue au développement de cette tendance, en permettant la mise à disposition au plus grand nombre, le plus souvent à titre gratuit, des logiciels avec un accès au code source de ces derniers.

Chaque éditeur de composants logiciels ou de logiciel à composants accorde certains droits de propriété intellectuelle sur la création qu’il distribue : utilisation, modification, redistribution etc…

Les licences de logiciels sont les outils juridiques qui déterminent de façon précise les droits concédés et les obligations imposées au Licencié par le Concédant. A titre d’exemple, un éditeur de composants peut autoriser une utilisation de composants « à des fins de recherche, en dehors de toute application commerciale » - C’est une des obligations imposées dans les licences attachées aux bibliothèques

« Numerical recipes ».

Cependant, les licences de type propriétaire côtoient aujourd’hui un grand nombre croissant de licences dites « libres ». Bien que ces licences offrent effectivement une grande liberté pour tout ce qui concerne l’utilisation du logiciel, et notamment de son code source (copier, modifier…), il n’en reste pas moins que certaines obligations restent rattachées aux logiciels concernés. Ces obligations, à l’image de celles des licences propriétaires, doivent être respectées.

De façon générale, deux traits particuliers propres au logiciel sont traités dans les licences auxquelles ils sont soumis :

- d’une part les droits concédés portent non seulement sur la création licenciée à laquelle est attachée la licence, mais aussi sur les créations futures qui peuvent en découler, œuvres dérivées ou composites,

- d’autre part certaines obligations concernent non pas le code source du logiciel, mais le code objet.

La sélection des droits concédés et le choix d’obligations contractuelles particulières imposées par la licence (clauses portant sur les brevets par exemple) reflètent des intérêts, des philosophies d’exploitation ou de développement propres à chaque éditeur ou fournisseur de composants. Il en résulte une variété de licences qu’il convient de connaître. Cette variété des régimes juridiques de distribution et d’assemblage des composants peut conduire à des constructions ne pouvant être distribuées ou utilisées sans contrainte ou conséquence. Dans certains cas, les règles imposées par les licences libres ou les droits concédés sont contradictoires et interdisent la possibilité même de la redistribution de l’assemblage. C’est le cas de logiciels à composants dont certains sont régis par des licences dites « incompatibles ». Il en résulte des travaux de développement et de ré-ingéniering (et des coûts) supplémentaires afin de retirer, remplacer ou réécrire les composants soumis à une licence incompatible, en vue d’une exploitation conforme aux régimes imposés par les licences des composants les constituants.

Ce guide propose une méthode d’analyse des licences de logiciel libre qui, bien qu’étant devenues familières dans le monde du logiciel, restent encore souvent mal comprises.

Cette méthode apporte des éléments pour bien comprendre les enjeux, les avantages et les inconvénients d’une licence de logiciel libre donnée et de documenter les obligations qu’elle impose au développeur/licencié qui l’utilise, notamment les règles de composition et de dérivation liées à la redistribution. Ce guide a par ailleurs servi à la rédaction d’un recueil de fiches descriptives d’un

« échantillon » de ces licences libres.

Page 6 sur 18 © INRIA – S. Steer – M. Fitzgibbon

La méthodologie proposée est fondée sur une démarche en 9 étapes, permettant l’analyse de toute licence attachée à un composant et à son utilisation dans une logique de développement de système à composants, notamment, en vue d’une distribution.

L’identification de la licence (étape 1) est un préalable nécessaire. L’analyse des définitions (2) que cette licence introduit conditionne notamment l’analyse des droits et des obligations qu’elle confère.

La méthodologie passe ensuite par l’analyse des droits en tant qu’utilisateur du logiciel (3), des droits et des obligations liées à la redistribution du logiciel (4) et finalement des conséquences qui en résultent pour l’assemblage de composants (5). L’analyse du cadre juridique qu’impose la licence (6) – langue, licence adossée à un droit national identifié ou non, etc…– détermine le cadre législatif applicable en matière de responsabilité, de garanties et de sécurité juridique (7). L’analyse des autres clauses spécifiques de la licence (8) peut amener à créer des obligations supplémentaires. Enfin, les conditions juridiques de production de la licence elle-même, des acteurs ayant pris l’initiative de sa rédaction et de son statut au regard d’organismes de « labellisation » (OSI, FSF) peut complèter ou

éclairer son statut (9).

La présentation de ces 9 étapes auxquelles sont associées des critères est détaillée ci-après.

1 / Identification de la Licence : Nom et version, Date, Titulaire droits d’auteur sur le texte,

famille de licence éventuelle

L’attention du lecteur est attirée sur la question des détenteurs des droits sur le texte de la licence

(a) ainsi que sur son numéro de version (b), en raison de leur incidence juridique.

a) Les détenteurs de droits sur le texte de la Licence :

Le texte de la Licence est protégé par le droit d'auteur : son auteur est seul habilité à modifier ou autoriser à modifier le texte de sa licence. L’auteur du texte peut donc réagir en cas de modification, d’amputation du texte d’origine ou d’utilisation du nom de la licence qui pourraient nuire à la renommée et la portée de cette dernière.

b) Le numéro de version de la Licence :

Les licences les plus suivies ont été corrigées ou adaptées au fil du temps. Elles disposent ainsi de versions successives présentant des différences dans leurs textes.

Il est donc nécessaire d'accorder une attention particulière au numéro de version utilisée pour ne pas se "tromper" de Licence applicable et risquer de se voir (ou de ne pas se voir) appliquer des clauses différant d'une version à l'autre.

Certaines licences ont des clauses rappelant expressément le droit pour les détenteurs de droits sur le texte de la Licence de corriger, d’améliorer ou d’adapter la Licence et de réaliser une nouvelle version de celle-ci. Selon la Licence, cette nouvelle version peut venir remplacer l'ancienne version et devenir applicable au Logiciel. (Sur ce point une analyse plus détaillée est présente plus loin dans le

guide)

Page 7 sur 18 © INRIA – S. Steer – M. Fitzgibbon

2/ Analyse des définitions de la Licence

La présence et le nombre de définitions est très variable d’une licence à l’autre :

Certaines licences ne comportent aucune définition (surtout les plus anciennes) : ceci rend la Licence plus souple et plus encline à s'adapter aux évolutions qui pourraient survenir en matière de logiciel. En revanche, elle sera surtout exposée aux risques d'interprétations diverses de la part des différents acteurs concernés (titulaires de droits sur la Licence, Concédants, Licenciés, doctrine, …). Ces derniers pourront en effet s'appuyer sur diverses législations, diverses acceptions des termes, sur la volonté des auteurs, etc., qui représentent autant d’interprétations possibles différentes. Ceci peut créer une insécurité juridique aussi bien dans l'application pratique de la Licence, qu'en présence d'un

éventuel litige.

A l'inverse, d'autres licences (plus récentes) présentent des définitions très exhaustives, qui peuvent orienter la signification des clauses. Elles accroissent la sécurité juridique, dans la mesure où elles permettent de cadrer l’interprétation d’une licence donnée par les différents acteurs.

Il est à noter que les définitions utilisées par certaines licences peuvent être rattachées à un droit particulier. A titre d’exemple, les définitions, de même que la terminologie de la licence GNU GPL v2 est d’influence de droit anglo-saxon. La licence GNU GPL v3 a au contraire adopté des définitions et une terminologie plus neutre, afin d’éviter le rattachement de la licence au droit anglo-saxon et en faire ainsi une licence plus « universelle » ou juridiquement plus « neutre ».

3/ Analyse des droits de propriété intellectuelle conférés en tant qu’utilisateur, en dehors de toute redistribution

Cette liste des différents droits pertinents pour l’analyse les licences de logiciel libre est inspirée de celle dégagée par l’ADAE (aujourd’hui remplacée par la DGME), dans son Guide de choix et d’usage des licences de logiciels libres pour les administrations paru en décembre 2002.

a) Droit d'usage :

Ce droit doit être total et sans limite pour être conforme au logiciel libre : le Licencié doit pouvoir utiliser le Logiciel comme il le souhaite et sans restriction. Il n’est pas possible, de ce fait, d’exclure certains domaines ou types d’utilisation, quand bien même cette limitation concernerait certaines valeurs « morales » ou des convictions personnelles de l’auteur du logiciel (exemple : l’auteur souhaite que l’usage de son logiciel soit libre, à l’exclusion de tout usage dans le domaine militaire ou de l’armement).

Ce droit correspond à la liberté "0" de la FSF : "La liberté d'exécuter le programme pour tous les usages".

b) Accès au code source :

Il s’agit d'un droit fondamental en matière de logiciel libre : les Licenciés doivent pouvoir accéder à l’intégralité du code source du Logiciel dans une forme non altérée et modifiable librement.

C’est également un prérequis pour la liberté "1" de la FSF : "La liberté d'étudier le fonctionnement du programme, et de l'adapter à vos besoins".

Page 8 sur 18 © INRIA – S. Steer – M. Fitzgibbon

c) Droit de dupliquer :

Ce droit est un préalable nécessaire à la redistribution des logiciels libres : le Licencié doit pouvoir dupliquer (reproduire) le Logiciel sous Licence.

d) Droit d'extraire des composants :

Il s’agit d’un droit constant en matière de logiciel libre : le Licencié doit pouvoir extraire des composants du Logiciel lui permettant de n’utiliser qu’une ou plusieurs fonctions du logiciel, en vue de les combiner avec d’autres.

e) Droit de modification ou d'intégration d'un autre logiciel :

Ce droit se déduit des précédents : le Licencié doit pouvoir modifier le Logiciel, l’améliorer et

éventuellement le combiner avec d’autres ou l’intégrer dans le fichier source d’un autre logiciel.

Le respect de l’esprit de la licence implique que le Concédant s’abstienne de tout acte qui aurait pour conséquence, de façon directe ou indirecte, d’entraver ce droit de modification ou d’intégration.

Certaines licences, dans un souci de protection de ce droit, le rappelle clairement et expressément dans leurs dispositions, avec des exemples précis. C’est le cas de la licence GNU GPL v3, qui interdit expressément les mécanismes de type DRM/MTP.

f) (Absence de) Droit de réclamer à l'auteur initial le bénéfice d'une garantie ou d'une maintenance :

Ce droit ne constitue pas une base du logiciel libre. Par ailleurs, la quasi-totalité des licences de logiciel libre prévoient au contraire d’importantes clauses exonératoires de garanties comme de responsabilité. Ces clauses soulèvent des problèmes en droit européen, et notamment en droit français, au regard desquels elles sont susceptibles d’être nulles.

Cependant, il est à noter que la portée de l’ensemble des droits évoqués dans cette section peut être plus ou moins fortement limitée ou nuancée, dès lors que le logiciel est redistribué.

4/ Droits et obligations liées à la redistribution :

Les questions relatives au changement de licence et aux problèmes de compatibilité de licences ne sera pas abordé dans ce point 4, et fera l’objet d’une section spécifique.

Le droit de distribuer/redistribuer correspond à la "Liberté "2" de la FSF : "la liberté de redistribuer des copies, donc d'aider votre voisin".

Le Licencié doit pouvoir, sans y être contraint, redistribuer le Logiciel qu’il a obtenu en acceptant une Licence libre.

Cette liberté doit être garantie, mais les conditions et les obligations liées à son exercice varient considérablement d’une licence à l’autre.

Il s'agit des obligations directes et "pratiques" que vont imposer les licences aux différents acteurs :

Concédants, Licenciés, redistributeurs, utilisateurs et contributeurs du Logiciel.

Page 9 sur 18 © INRIA – S. Steer – M. Fitzgibbon

Ces points sont importants dans les implications pratiques de la licence. En effet, les licences libres confient dans l’ensemble des droits d’usage similaires. Leurs principales distinctions proviennent donc des possibilités qu’elles permettent et des obligations qu’elles imposent en matière de redistribution.

Il est important de noter qu’en vertu de certaines licences, l’élément « déclencheur » des obligations n’est pas seulement la distribution, mais également la mise à disposition à distance (en mode Saas), sans distribution du Logiciel pour son utilisation. C’est le cas de la licence GNU Affero et de l’Open

Source License.

a) Méthode de mise à disposition du code source :

La mise à disposition du code source est une priorité lors de la distribution d'un logiciel libre.

Toutefois, les moyens par lesquels le Concédant ou le Licencié peuvent satisfaire à cette obligation peuvent être plus ou moins encadrés par la Licence.

En effet, si certaines licences sont relativement vagues et laissent une importante, voir totale liberté pour cette mise à disposition, d'autres sont plus exigeantes et demandent la mise à disposition du code source selon des méthodes précises.

b) Traçabilité des contributions (auteur + date, dans la notice, le Logiciel ou assimilé) :

Les licences prévoient souvent une obligation pour le Licencié d’indiquer son nom (et parfois la date) sur la « portion » du logiciel qu'il a modifiée. Cette obligation peut également être plus large et prévoir d'autres notifications, dans une notice accompagnant le Logiciel, par exemple.

Ces prescriptions sont accompagnées d'une obligation pour les Licenciés de conserver ces indications lors des distributions successives.

En droit français, le respect du droit de paternité est une obligation légale. Cependant, ce n’est pas le cas dans toutes les législations, comme en droit américain, par exemple. Ainsi, la clause d’une licence libre prévoyant le respect du droit de paternité permet de garantir ce dernier contractuellement, à défaut d’en bénéficier du fait de la loi applicable. Elles permettent par ailleurs d’effectuer un certain contrôle sur la provenance et la date des modifications, assurant ainsi la traçabilité des diverses contributions. Sur ce dernier point, l’obligation contractuelle coïncide avec les bonnes pratiques de développement logiciel.

c) Documentation ou publicité spécifique :

Certaines licences prévoient des obligations de publicité spécifiques relatives au Logiciel, dont la présence est par conséquent à vérifier.

d) Gestion des marques, nom de la Licence, noms des titulaires de droits et autres signes distinctifs :

Il existe une protection légale propre sur les marques, noms patrimoniaux et autres signes distinctifs.

Certaines licences en rappellent l'existence, afin de prévenir toute utilisation non autorisée par les licenciés. Une telle disposition permet par ailleurs d’attester la mauvaise foi du licencié qui utiliserait malgré cela le signe distinctif, en-dehors de toute utilisation de son titulaire.

Certaines licences prévoient également une utilisation encadrée de tels signes et confèrent donc certains droits sur ces derniers au Licencié.

Page 10 sur 18 © INRIA – S. Steer – M. Fitzgibbon

e) Droit de faire payer la redistribution :

Le logiciel libre n’implique pas nécessairement la gratuité, la maxime de la FSF sur ce point est "free

as in free speech, not as in free beer".

Il s’agit d’une « idée reçue » relativement forte et courante, qui trouve sans aucun doute son origine dans le terme anglais « free », qui signifie à la fois libre et gratuit. En réalité, le Licencié peut parfaitement effectuer la distribution de façon onéreuse.

Cependant, ce caractère onéreux ne doit pas restreindre les libertés apportées par la Licence. Les droits cités dans le point 3 doivent être respectés et si un logiciel libre peut être vendu, la Licence peut interdire, par exemple, de redistribuer le code source à un coût supérieur au simple coût du transfert matériel, en cas de distribution séparée du code objet.

d) Droit de proposer une garantie à ceux à qui l'on distribue :

Le principe des licences libres est, le plus souvent, une exonération totale ou quasi-totale de garantie.

Il peut cependant exister une possibilité dans certaines licences libres, pour un distributeur, de proposer une garantie à ses Licenciés. Elle est toutefois encadrée de façon à ce que cette garantie ne lie que le distributeur la proposant et non pas les Concédants antérieurs ou initiaux.

En l'absence de disposition contraire dans la Licence sur ce point, le principe devrait être la liberté du sous-Concédant de proposer une garantie dans un contrat séparé, qui n’engage bien évidemment que lui.

5/ Conditions relatives à la redistribution sous une autre Licence et à la compatibilité entre licences a) Caractéristiques générales de la licence : non permissive/ permissive en matière de composition/ permissive en matière de composition et de dérivation

L’effet « copyleft » peut être plus ou moins limité d’une licence à l’autre. Identifier l'étendue de ce copyleft est important : la liberté de choix ou non d'une nouvelle licence, ainsi que la compatibilité avec les licences rattachés à du code/composant préexistants intégrés au logiciel, en dépendent.

Les licences libres se partagent en trois catégories très générales :

- Les licences non permissives ou à fort copyleft : il s’agit des licences imposant que toute redistribution du Logiciel, modifié ou non, se fasse sous les termes de la même licence ou

éventuellement, sous les termes d’une licence désignée compatible de façon expresse. L’objectif de ces licences est à la fois d’empêcher l’appropriation du code mis en open source dans un code propriétaire, et d’imposer ce même régime à tout ce qui y est rattaché, dans un même assemblage.

Toutefois, il est à noter que cette obligation de mise à disposition du code source du Logiciel Modifié ne vaut que dès lors qu’il y a redistribution.

- Les licences permissives en matière de composition : il s’agit des licences autorisant d’assembler des composants au Logiciel soumis à leur propre licence, lors de la redistribution. En revanche, toute modification faite sur le Code Source du Logiciel lui-même doit être soumise à la Licence de ce dernier, en cas de redistribution. L’objectif de ces licences est d’empêcher l’appropriation du code mis en open source dans un code propriétaire, tout en permettant une utilisation large du logiciel, en autorisant l’assemblage avec du code de toute nature.

Page 11 sur 18 © INRIA – S. Steer – M. Fitzgibbon

- les licences permissives en matière de composition et de dérivation : il s’agit de licences autorisant de distribuer le Logiciel modifié, de quelque façon que ce soit (combinaison avec d’autres modules, modifications de son Code Source…), sous une autre licence, y compris une licence propriétaire. A titre d’exemple, la licence BSD, qui est sans doute une des licences libres les plus permissives, autorise également de distribuer le Logiciel non modifié sous une autre licence (étant précisé que cette prérogative ne peut être en général utilisée que par le titulaire des droits sur le

Logiciel, notamment en vue de faire du dual-licensing). L’objectif de ces licences est de s’assurer une diffusion la plus large possible du code, quitte à autoriser les Licenciés à distribuer le Logiciel Dérivé sous licence propriétaire.

Il est par conséquent important de remarquer, lorsque du code préexistant est intégré dans un logiciel, que les modalités techniques de cette intégration et l’architecture d’un logiciel donné peuvent avoir une incidence dans le choix de la licence de redistribution. Par exemple, le fait de

« recopier » du code source distribué sous licence GNU LGPL dans un ou plusieurs fichiers sources d’un autre logiciel, contraint d’effectuer toute redistribution du Logiciel dérivé sous licence GNU LGPL. En revanche, si un composant sous licence GNU LGPL est lié dynamiquement à un logiciel, le composant reste sous licence GNU LGPL mais le logiciel peut être distribué sous une autre licence.

Il est également important de noter qu’en raison du caractère plus ou moins permissif de certaines licences libres, il est possible, et même fréquent, d’avoir des logiciels libres dont les différents composants ne sont pas tous soumis à la même licence. Pour que cette « cohabitation » soit possible et dès lors que le logiciel doit être distribué, il est important d’avoir vérifié au préalable la compatibilité entre les licences des différents composants du logiciel, mais aussi avec la licence envisagée pour la redistribution du logiciel modifié.

Il convient donc de s’intéresser tant à la compatibilité supérieure qu’à la compatibilité inférieure d’une licence.

b) Question de la compatibilité entre licences libres :

• Compatibilité supérieure :

La compatibilité supérieure désigne la capacité du Logiciel sous Licence d'être soumis aux termes d'une autre licence ou de « cohabiter » avec cette dernière.

(Ex : capacité d'un logiciel sous licence BSD d'être soumis à la licence GNU GPL = compatibilité supérieure de la licence BSD vers la licence GNU GPL).

Elle se décline en trois mécanismes :

- compatibilité de la Licence avec ses nouvelles versions (Sur ce point une analyse plus détaillée est

présente plus loin dans le guide).

- compatibilité supérieure expresse : certaines licences (récentes) incluent des clauses prévoyant une compatibilité expresse avec d’autres licences libres, aux profits desquelles elles acceptent que le

Logiciel soit soumis (afin de lutter contre des problèmes d’incompatibilité, et donc de blocages de développement, liés à la prolifération des licences de logiciel libre). A titre d’exemple, la licence

CeCILL v2 est expressément compatible avec la licence GNU GPL.

Ainsi, une clause prévoyant une compatibilité expresse a l’avantage de permettre au titulaire d’un logiciel de diffuser ce dernier sous une autre licence citée qui serait plus adaptée à un contexte juridique particulier (ex. choix de la licence CeCILL v2 pour se conformer à la législation française à laquelle le titulaire du logiciel dépend), tout en permettant aux licenciés d’intégrer librement du code soumis à une licence standard de fait (ex. en intégrant du code sous GNU GPL dans un logiciel sous licence CeCILL v2, et en distribuant le logiciel dérivé sous GNU GPL).

Page 12 sur 18 © INRIA – S. Steer – M. Fitzgibbon

Toutefois, il reste important de vérifier les conditions dans lesquelles peut se faire le changement envers une licence expressément compatible. En effet, dans certains cas, un logiciel modifié, sans intégration de code préexistant, peut être redistribué sous une licence expressément compatible avec la licence du logiciel initial. C’est le cas, à titre d’exemple, de la licence CeCILL-B, qui permet de redistribuer le logiciel modifié sous licence CeCILL-C.

En revanche, certaines licences autorisent un changement vers une licence expressément compatible, uniquement lorsque du code soumis à ladite licence compatible a été intégré dans le logiciel modifié.

Par exemple, un logiciel modifié initialement sous licence ceCILL v2 ne pourra être distribué sous licence GNU GPL que s’il intègre du code soumis à cette licence.

- compatibilité supérieure implicite : elle provient de la permissivité de la Licence en composition et/ou dérivation. Plus elle sera permissive, plus elle sera implicitement compatible avec de nombreuses licences. A titre d’exemple, la licence BSD est potentiellement compatible avec toute autre licence

Cependant, il ne suffit pas qu’une licence soit, dans son esprit, plus ou moins permissive pour qu’elle soit compatible avec une autre licence libre. En effet, le plus souvent, une licence libre, même très permissive, ne s’efface et/ou n’accepte de cohabiter avec une autre licence que sous réserve du respect de certaines obligations. Ces obligations, plus ou moins contraignantes, doivent pouvoir être reprises par la licence de redistribution et/ou celle des autres composants du logiciel modifié. Il s’agit de ce qui est appelé ci-après « compatibilité inférieure ».

• Compatibilité inférieure :

La compatibilité inférieure désigne la capacité de la Licence d'accueillir un logiciel ou des composants logiciels soumis à d'autres licences ou initialement soumis à une autre licence.

(Ex : capacité de la licence GNU GPL à accueillir du code sous licence CeCILLv2 = compatibilité inférieure de la licence GNU GPL envers la licence CeCILLv2)

Elle peut être vérifiée de deux façons :

- cette compatibilité existe lorsque la licence du logiciel/composant logiciel accueilli par la Licence est expressément compatible avec cette dernière (ex. la licence GNU GPL peut accueillir un composant logiciel sous licence CeCILL v2, cette dernière étant expressément compatible). La licence libre dite compatible peut accepter de s’effacer entièrement au profit de l’autre.

- sous l'angle des facilités d'accueil expresses ou implicites dont dispose la Licence « d’accueil ». En effet, quand bien même une licence permissive accepte que le logiciel dérivé ou certains composants soient soumis à une autre licence, cette possibilité reste néanmoins soumise au respect de certaines conditions. Si la licence « d’accueil » n’est pas en mesure d’accepter ces conditions, alors les licences ne seront pas compatibles.

Par exemple, la licence CeCILL-B accepte de redistribuer un logiciel dérivé ou composé sous une autre licence, sous réserve de respecter une très forte obligation de citation. Or, d’autres licences libres ne prévoient pas une obligation de citation aussi forte, et n’acceptent pas de reprendre celle de la licence CeCILL-B. C’est le cas, à titre d’exemple, de la GNU GPL.

d) Possibilité de distribuer les Modules Externes du Logiciel sous une autre licence :

Les Modules Externes sont par définition des logiciels considérés comme des œuvres indépendantes. Ils ne sont donc pas juridiquement liés avec le ou les logiciels avec lesquels ils fonctionnent et peuvent

Page 13 sur 18 © INRIA – S. Steer – M. Fitzgibbon

être soumis à leur propre licence, quelle qu’elle soit. Une disposition prévoyant le contraire dans une licence aurait une validité contestable.

6/ Analyse du cadre juridique de la Licence :

Ces critères permettent de déterminer le régime juridique applicable à une Licence. Ils nécessitent donc d'être connus, que ce soit dans l'application ou dans le choix d'une licence libre.

a) Durée et territoire :

Un contrat est conclu pour une durée et pour un territoire donné : s'agissant de licences de logiciel libre, la Licence est généralement concédée mondialement pour la durée de protection des droits (en

France 70 ans après la mort de l’auteur ou du dernier auteur, ou 70 ans après publication de l’œuvre

collective) pour faciliter la diffusion et l’exercice des libertés du libre.

Il arrive néanmoins qu'il n'y ait pas d'indication sur ce point, ce qui est, en théorie, une cause d’invalidité de la concession en droit français. Cependant, cette nullité est relative : seule le titulaire des droits sur le logiciel serait fondé à l’invoquer. Dans la pratique, on peut donc s’attendre à ce que ce dernier, ayant mis volontairement son logiciel sous une licence libre donnée, n’invoque pas une telle nullité.

b) Langue de la Licence :

Elle a bien évidemment une incidence sur les facilités/difficultés de compréhension au niveau de l'interprétation juridique de la Licence.

Elle emporte également des conséquences juridiques s'agissant de législations qui peuvent imposer l’usage de leur langue nationale dans certaines conditions.

(Ex : en droit français, la loi Toubon de 1994 impose que, pour les contrats auxquels sont partie des

personnes morales de droit public ou des personnes privées exécutant une mission de service public, ainsi que pour la désignation, l'offre, la présentation, le mode d'emploi ou d'utilisation, la description de l'étendue et des conditions de garantie d'un bien, d'un produit ou d'un service, l'emploi de la langue française est obligatoire. Cependant, à ce jour, les licences libres en langue anglaise utilisées sur le territoire français n’ont pas eu (pour des raisons évidente, dans la pratique) à souffrir

d’actions sur ce fondement.)

c) Loi applicable et juridiction compétente :

Ces deux points peuvent être déterminants :

- ils déterminent le lieu où devra être tranché un éventuel litige lié à la Licence ;

- l'interprétation juridique (dans sa mise en œuvre ou par le juge) de la Licence peut varier en fonction de la loi applicable.

La détermination de la loi applicable et de la juridiction compétente relève du droit international privé.

En matière contractuelle, les parties peuvent spécifier la loi applicable à leur contrat (si celui-ci présente un élément d’extranéité, ce qui est quasi systématique en matière de logiciel libre) et la juridiction compétente pour traiter des litiges relatifs à ce contrat.

Elles peuvent être invalides dans certains cas, en raison de droits protecteurs d'application impérative

(ex en droit français : droit de la consommation, du travail, …).

Page 14 sur 18 © INRIA – S. Steer – M. Fitzgibbon

Les conséquences possibles de ces clauses :

- le litige peut être soumis dans une juridiction éloignée, à l’étranger ;

- le droit applicable peut être méconnu.

En l'absence de telles clauses ou si elles sont inopposables : les règles contractuelles classiques en la matière sont applicables, qu'elles proviennent de droits nationaux ou plus souvent du droit international.

Les risques liés à l’absence de clauses : si les parties ne sont pas d’accord sur la loi applicable et la juridiction compétente, il peut y avoir un premier litige à trancher sur cette question. Le règlement du litige concernant la licence n’aura lieu qu’après.

d) Sécurité juridique :

La sécurité juridique est ici définie comme l'attente raisonnable que placent les cocontractants d’une

Licence dans la conformité de leurs souhaits à l'application effective de la Licence : il s'agira notamment de la validité de la Licence (ou de ses éléments), de la bonne compréhension de ses termes par les cocontractants comme par les tiers, des facilités d'exécution des obligations contractuelles (voir judiciaires en cas de litige), etc.

En matière de licence de logiciel libre, un intérêt particulier doit être accordé à la validité des clauses de cession ou de garanties qu'elle contient, aux risques de mauvaise interprétation ou compréhension des termes par les Licenciés…

La position de la jurisprudence en la matière est bien évidemment un élément clef pour se livrer à cet exercice. Toutefois, cette jurisprudence est à ce jour extrêmement rare, ce qui laisse de nombreuses licences sujettes à une grande part d’interprétation en ce qui concerne leur validité et leur sécurité juridique.

7/ Analyse des clauses exonératoires de responsabilité / garantie

Bien que rien ne soit expressément requis par la FSF ou par l’OSI, la règle en matière de licences libres reste les clauses prévoyant une exonération de garanties et de responsabilités du ou des

Concédants.

Ces clauses sont justifiées par l'absence de profit "direct" de l'auteur pour la mise à disposition de son travail et de ces droits de propriété intellectuelle, ou du fait que les logiciels concernés sont des travaux inachevés ou des prototypes de recherche, et donc imparfaits. Elles se justifient également, vis-à-vis du développeur initial, par le caractère très évolutif d'un logiciel libre, ainsi que par sa multiplication possible d'auteurs successifs : elle rend le contrôle effectif et la vérification de la fiabilité des modifications quasi-impossibles pour le développeur initial.

Malgré ces justifications, la validité de telles clauses n'est pas reconnue dans toutes les législations, notamment en droit français, et leur champ d'exemption maximal peut être limité.

Il existe toutefois des variantes d’une Licence à l’autre. A titre d’exemple, la famille des licences

CeCILL ne prévoit pas d’exonération totale de responsabilité, afin de se mettre davantage en conformité avec le droit français.

D’autres licences, telles que la licence GNU GPL v3, prévoient que cette exonération de garantie n’est valable que dans la limite du droit applicable. Il est donc possible d’en déduire que, dans l’hypothèse où le droit français serait applicable, cette exonération ne pourra pas être totale.

Page 15 sur 18 © INRIA – S. Steer – M. Fitzgibbon

8/ Analyse des clauses spécifiques de chaque licence

Si les licences de logiciel libre s'inscrivent dans des principes généraux semblables d'une licence à l'autre, chaque licence reste néanmoins un contrat spécifique avec des clauses qui lui sont propres.

Ces clauses peuvent créer des différences importantes entre deux licences.

Il peut notamment s'agir de clauses résolutoires (a), de clauses introduisant un régime spécifique vis-

à-vis des brevets (b), de clauses de survie ou d’adaptation de la licence (c) permettant une mise à jour de la Licence (d) etc.

a) Clause résolutoire :

Il s’agit d’un mécanisme de protection des obligations de la Licence : dans les cas où le Licencié viendrait à manquer aux obligations qu’elle lui impose, elle sera, ou pourra être, résiliée (le mettant ainsi dans la situation d’un contrefacteur si il continue ne serait-ce qu'à utiliser le Logiciel).

Ces clauses résolutoires peuvent être encadrées, que ce soit par des délais permettant au Licencié de cesser l’acte litigieux, avant que la résiliation ne soit effective, par des limites à l’étendue de la résiliation, ainsi que par son absence, dans la quasi-totalité des licences, de conséquence pour les sous-Licenciés non fautifs, auxquels le Licencié fautif aurait distribué le Logiciel.

Toutefois, le juge reste seul habilité à sanctionner un Licencié qui continuerait à utiliser le Logiciel, malgré la résiliation. Ceci implique, pour la personne qui souhaite obtenir une sanction du Licencié, d’avoir la capacité et le droit d’agir devant les tribunaux. Ceci peut s’avérer délicat lorsque le logiciel libre est un logiciel développé dans le cadre d’une communauté avec un grand nombre de contributeurs. En effet, dans cette hypothèse, pour agir devant les tribunaux, il est nécessaire d’avoir l’accord de tous les co-indivisaires sur le logiciel (et de pouvoir le démontrer).

A défaut, une personne peut se prévaloir de son droit d’agir sur sa seule contribution sur le Logiciel dès lors qu’elle est identifiable.

b) Articulation avec le droit des brevets :

Les logiciels sont protégés mondialement par le "droit d’auteur" ou ses équivalents, mais dans beaucoup de législations, il existe des techniques directes ou non permettant de breveter un logiciel.

Il existe également des brevets implémentés dans des logiciels (par exemple, des brevets portant sur des procédés techniques).

En matière de logiciel libre, cela pourrait permettre à une personne, en théorie, de mettre un Logiciel sous licence libre tout en conservant une possibilité d’action sur le terrain des brevets. En cas de survenance d’un litige, la question devra être tranchée par le juge, mais la validité juridique d'une telle pratique semble contestable (abus de droit, mauvaise foi du Concédant …).

Certaines licences ont « pris les devants » et introduit des clauses dans ces licences afin d'empêcher de telles pratiques. Ces clauses consistent généralement à donner une licence sur l'ensemble des brevets du Concédant portant sur ou implémentés dans un Logiciel, ou à une interdiction de se prévaloir de ses brevets contre un Licencié, lorsque ces derniers sont utilisés pour la mise en œuvre du Logiciel.

Lorsque la clause prévoit une licence sur les brevets opposables, elle peut être couplée à une clause résolutoire qui « s’active » en cas d'action menée sur le terrain du droit des brevets contre le

Concédant du Logiciel.

Page 16 sur 18 © INRIA – S. Steer – M. Fitzgibbon

c) Clause de survie ou d'adaptation de la Licence :

Les licences libres sont souvent critiquées s'agissant de leurs validités face à différents droits. Afin d’éviter qu’elles ne soient annulées en totalité, certains rédacteurs ont décidé d’inclure des clauses afin de prévoir, en cas d’invalidation par le juge d’une clause de la licence, que :

* le reste de la Licence ne doit pas pour autant être annulée intégralement (=clause de survie)

* la clause est réformée a minima pour devenir valable au regard du droit applicable, tout en se rapprochant au maximum de la volonté de la clause initiale (= clause d'adaptation).

Le but de ces clauses est d'inciter le juge à ne pas invalider l’intégralité de la licence (ce qui remettrait en cause toutes les utilisations préalables libres).

Ce type de clause ne lie jamais totalement le juge, mais permet d’indiquer que l’intention des parties est de rechercher la survie de la Licence, quoi qu'il arrive.

d) Mise à jour de la licence :

Ces clauses prévoient la possibilité pour une personne ne disposant pas des droits suffisants sur le

Logiciel de modifier sa Licence au profit d'une nouvelle version (voir point 1)b)) et dans quelles conditions.

- elles peuvent en effet prévoir que la mise à jour de la Licence :

*se fait quasi automatiquement par la seule intervention des titulaires de droit sur le texte de la

Licence (ex licence EUPL)

*peut se faire par tout sous-Concédant ou Licencié (ex licence EPL)

*peut être empêchée par le Concédant, en indiquant s’il souhaite restreindre la Licence applicable à son Logiciel, en indiquant expressément un numéro de version applicable (en l'absence d'une telle précision ou en précisant "Version X et ultérieure" la mise à jour pourra se faire par n'importe quel sous Concédant ou Licencié) (ex licence GNU GPL)

e) Tout autre clause spécifique (Indication DRM/MTP, Prévention "tivoisation", …) :

Il s’agit de clauses très spécifiques, qui ne sont pas des « classiques » du libre. La licence GNU GPL v3 comporte de telles clauses, qui visent à « protéger » le libre contre toute atteinte technique qui pourrait lui être fait (ex. dispositif technique empêchant la reproduction du logiciel).

Le recours de dispositifs tels que les DRM et la tivoisation avait en effet donné lieu à une polémique à la fois dans le domaine du libre et du non-libre. Ces deux dispositifs visent à réduire les possibilités d’utilisation de logiciels, mais également de CD, DVD… Si les DRM sont présents dans le support-même du logiciel ou de n’importe quelle œuvre numérique, la tivoisation est quant à lui un mécanisme qui intègre un logiciel dans un support physique en restreignant l’utilisation. L’objectif poursuivi par les utilisateurs de tels dispositifs est bien évidemment d’empêcher toute copie du logiciel ou de l’œuvre numérique.

Dans le domaine du non-libre, il avait été reproché aux dispositifs précitées de porter atteinte au droit à la copie privée. Dans le domaine du logiciel libre, cette polémique va encore plus loin, dans la mesure où elle prive les Licenciés d’une partie de leurs droits accordés par la licence libre. Ainsi, il paraît évident qu’un recours à de tels dispositif porte manifestement atteinte à n’importe quelle licence répondant aux critères du libre.

On peut donc penser que l’introduction de clauses spécifiques liées aux DRM, tivoisation ou tout autre dispositif similaire, ne vise pas à créer une nouvelle obligation, mais seulement à confirmer l’incompatibilité d’une telle pratique avec les conditions d’une licence libre.

Page 17 sur 18 © INRIA – S. Steer – M. Fitzgibbon

9/ Analyse de l’encadrement matériel de la Licence

L’étude du contexte matériel de la Licence est utile pour en comprendre les tenants et les aboutissants.

a) Entité(s) s’occupant de la Licence et importance du suivi :

La qualité des auteurs de la Licence et de l'entité s'en occupant ainsi que l’investissement qu’ils y consacrent peuvent avoir un réel impact sur le choix de la licence libre: qualité du suivi, parution de nouvelles versions, mise à dispositions d'analyses précises sur la Licence, mise en œuvre de moyens visant à sa défense ou à son respect, etc.

b) Philosophie de la Licence (type de logiciels concernés, volonté sociale des auteurs …) :

Contenue dans le préambule de la Licence ou dans les discours de ses auteurs, la philosophie de la

Licence, si elle n’a aucune valeur contraignante, peut influer l’interprétation du juge qui aurait à trancher un litige.

Il est préférable d’être en accord avec les objectifs de la Licence ou a minima, de les prendre en considération, dans l’hypothèse d’une utilisation ou redistribution dont les termes de la Licence ne seraient pas clairs.

c) Reconnaissance FSF / OSI :

La reconnaissance de la FSF et de l’OSI est un repère dans le monde du logiciel libre. Cette reconnaissance ne reste toutefois qu'indicative, la Licence pouvant correspondre aux critères du libre sans être labellisée pour autant.

d) Documentation spécifique et principaux utilisateurs / logiciels sous Licence :

Il est possible de trouver différentes sources d’information et de documentation sur la Licence

(notamment sur internet) pouvant apporter des éléments de compréhension et des exemples d'utilisation de ses termes.

Page 18 sur 18 © INRIA – S. Steer – M. Fitzgibbon