Le choix de la licence traduit des intérêts juridiques, techniques et commerciaux. Le choix d'une licence Open Source suit un processus particulièrement simple à décrire :
La société doit adopter la licence la plus adaptée à son projet. L'existence de centaine de licences laisse présager un nombre tout aussi grand de situations particulières les ayant justifiées. Leur multiplicité préjudicie à leur compréhension, alors qu'il n'y a en réalité que quelques obligations qui différencient les licences les unes des autres1< : les clauses copyleft , les clauses relatives aux usages par la communauté, les clauses relatives aux brevets, DRM [1], Tivoïzation2<, la langue utilisée, etc.
La société dresse donc, dans un premier temps, un état des lieux qui permet de constater que certaines licences ne peuvent pas être réutilisées en l'état en dehors de projets particuliers, que d'autres ne sont manifestement pas adaptées à ses intentions et, pour finir, que seules quelques-unes répondent en totalité ou partie à ses attentes.
La société peut encore faire le choix de la multilicence (décrite supra). On parle de multilicence lorsqu'une seule et même création est soumise à différentes licences : qu'elles soient toutes Open Source ou qu'au moins l'une d'elle le soit. Multiplier les licences Open Source peut parfois offrir des situations véritablement avantageuses : assurer une compatibilité au bénéfice de plusieurs licences, bénéficier de la renommée d'une licence, optimiser la cession de droits, etc.
Exemple : Le navigateur web Firefox , sous licence MPL [2]/LGPL/GPL3<, est un très bon exemple de la souplesse qu'offrent les licences. En effet, le logiciel est construit de façon modulaire4< et gagne à conserver une licence qui intègre ce particularisme5<. Cependant, afin de rassurer les développeurs et les communautés sur leur faculté de disposer du code pour d'autres projets, les licences LGPL et GPL s'ajoutent à la MPL [2]. De cette façon, le logiciel libre Firefox dispose d'une licence qui lui permet d'être compatible avec les licences les plus populaires tout en bénéficiant des développements sous la licence la plus adaptée aux projets de Mozilla – notamment une portée réduite qui amenuise l'aspect contraignant de son copyleft6<.
Dans un second temps, une fois ce premier état des lieux réalisé, la société doit se poser un certain nombre de questions indirectement liées au projet : la licence doit-elle être connue et reconnue par les communautés ? Doit-on s'inspirer des choix opérés pour des projets concurrents analogues ? Certaines licences doivent-elles être proscrites ? Toutes ces questions ne trouvent de réponses qu'au cas par cas, en fonction de l'examen et de l'approche choisie par la société. Incontestablement, une licence disposant d'une large notoriété participe avantageusement à la communication qui suivra la libération du logiciel. En revanche, le choix d'une licence similaire à un projet concurrent est un pari dont il faut bien mesurer les aléas : les contributions pouvant librement circuler d'un projet à l'autre, celui qui réunit la meilleure communauté risque de l'emporter et de détourner à son profit les contributeurs de son concurrent.
A l'inverse, bénéficier de l'expérience et de l'expertise déployée par une société concurrente peut justifier un tel choix.
Dans l’hypothèse où un logiciel est distribué sous une licence libre déjà connue il peut être opportun d’ajouter une inteprétation relativement aux clauses des licences Open Source. Lorsque l'un des termes de la licence est source d'interprétation, celui qui choisit la licence peut lever l'ambiguïté qu'elle pourrait engendrer en donnant une portée bien définie à cette clause.
Ainsi, il y a création d’un faisceau d’indices qui pourrait donner des indications aux juges lors d'un litige dont la résolution passe par l'interprétation de la licence. Ainsi le juge pourrait valider l'interprétation définie par l'entreprise qui recourt à la licence. De nombreuses clauses imprécises ou équivoques peuvent être interprétées de la sorte lors du choix de la licence.
L'usage des exceptions est une autre technique plus radicale qui consiste à modifier la licence de base en ajoutant, dans une clause jointe à la licence ou insérée dans les en-têtes, une spécificité qui déroge aux termes initiaux avec
pour effet de rendre la licence finale plus ou moins contraignante. Il est à noter qu'en l'absence de stipulation contraire, une clause additionnelle permissive pourra être supprimée par tout licencié au moment de la redistribution d'une copie du logiciel1<.
La maîtrise de plus en plus fine de la pratique contractuelle liée aux licences Open Source conduit aujourd'hui à conseiller une pratique réfléchie et adaptée de ces exceptions et interprétations. Les premières confèrent plus de souplesse aux licences2<, les secondes assurent une plus grande sécurité juridique. Un bon usage de celles-ci peut permettre de prévoir et de résoudre a priori la plupart des situations préjudiciables : problèmes d'incompatibilité, failles au sein des licences, etc.
Les développement qui suivent visent à étudier de manière générale les licences Open Source par typologie et d’effectuer un zoom sur la GNU [9]< General Public License.
La rédaction des licences Open Source n’étant pas toujours l’œuvre de juristes et émanant de systèmes juridique hétérogènes, on s'aperçoit que certaines clauses sont inutiles au regard des règles de droit d’un pays, alors que d'autres doivent être interprétées pour être contextualisées.
Parmi les licences Open Source et afin d’avoir une vision plus globale du système, plusieurs classifications peuvent être croisées1<.
L'utilisation du terme copyleft s'entend des licences qui rendent persistantes les libertés consenties en astreignant les utilisateurs subséquents à concéder systématiquement les mêmes libertés. Concrètement, une cession non exclusive est demandée, les contributeurs restant titulaires de leurs droits et libres d'exploiter leur contribution par ailleurs.
On parle indifféremment de réciprocité ou de copyleft . Dans cette situation, c'est l'intérêt de l'utilisateur final qui prévaut sur la liberté de celui qui diffuse l'œuvre.
Deux mécanismes sont aujourd'hui utilisés :
À l'inverse, on parle de licence permissive lorsque seules les obligations de celui qui reçoit l'œuvre — comme celles en matière de brevets pour la licence Apache — doivent être transmises, laissant le contributeur libre d'en ajouter d'autres lors du transfert aux utilisateurs ultérieurs (le logiciel redistribué perd souvent les libertés qui lui étaient attachées). Ces licences sont traditionnellement assimilées à des renonciations et le statut des œuvres est souvent proche de celui des œuvres tombées dans le domaine public, puisqu'elles n'imposent en règle générale que le respect de la paternité (avec les habituelles clauses d'exclusion ou limitation de garanties et de responsabilité). Cette relative liberté les fait coexister sans anicroche puisqu'il est très simple pour ces licences d'être compatibles en perpétuant simplement les obligations initiales.
• Les licences GNU [9] / philosophiques : il s'agit des licences publiées par la Free Software Foundation et plus généralement toutes celles qui partagent son esprit et sa philosophie. Les plus utilisées sont celles de la FSF [12] : la première de la famille est la GNU [9] General Public License — publiée en 1989, modifiée en 1991 et 2007, sa petite sœur est la GNU [9] Library General Public License — renommée lesser GPL — et leur cousine à destination de la documentation [13], la GNU [9] Free Documentation [13] licence. Il y a deux nouvelles entrantes : la GNU [9] Affero GPL depuis fin 2007 et la Simpler FDL qui devrait suivre prochainement. À l'origine, le langage de ces licences, très proche de celui des développeurs, est empreint d'une intention forte et d'une portée parfois complexe à définir. La réécriture récente des licences ajoute à cette famille de licences des versions [4] beaucoup plus juridiques et complexes. Elles s'opposent à toute réappropriation du code grâce à leur copyleft qui impose que tout logiciel dérivé — basé sur, ou constituant un tout avec le logiciel — soit lui-même soumis à cette licence. Les sociétés intéressées par l'alternative du « Libre » hésitent souvent à recourir à l'utilisation de ces licences aux implications extensives et parfois incertaines.
• Les licences académiques / universitaires. Elles sont en large partie à l'origine du développement de l'infrastructure d'Internet. Pour exemple, le système de nom de domaine BIND, le protocole TCP-IP et Sendmail sont tous des standards de facto , issus de ces licences permissives. On y retrouve l'idée d'un partage des connaissances « sans condition » issu des universités américaines. Elles sont fréquemment formulées d'une façon courte et claire. Elles consistent généralement en l'énumération de la totalité des droits conférés, une obligation de respecter la paternité de l'œuvre et une exclusion de responsabilité et de garantie. Un bon exemple est la licence BSD [14] — pour Berkeley Software Distribution.
• Les licences communautaires. Elles sont principalement issues de projets libres qui, devenus populaires, choisissent de rédiger et d'utiliser leur propre licence. Très spécifiques puisqu'intimement liées à un projet et à son déroulement, elles sont en principe peu juridiques et trop souvent susceptibles d'interprétations hasardeuses. Les deux principales sont la licence Artistic et la licence Apache. Ce sont essentiellement des licences permissives, mais leur spécificité les rend difficiles — voire impossibles — à concilier avec la plupart des licences copyleft .
• Les licences institutionnelles : Elles furent introduites par des sociétés intéressées par le développement coopératif de leur produit selon le modèle de l'Open Innovation . La première, la plus symptomatique est la Mozilla Public License (MPL [2]), rédigée par la firme Netscape pour la libération du code de son navigateur. Ces licences sont précises et très complètes, ont une étendue définie et emblématique du mouvement Open Source.
Les licences Open Source sont aujourd'hui utilisées dans de nombreux domaines : les logiciels bien sûr, mais aussi les encyclopédies (on pense à Wikipedia), les livres, la musique et bientôt tout type d'œuvres. La majeure partie des licences Open Source trouve leur fondement dans une application particulière pour un domaine artistique bien déterminé. De ce fait, il est très délicat et déconseillé d'utiliser des licences rédigées pour un domaine dans un autre.
Par exemple, le formalisme extrêmement contraignant de la GNU GPL [8] n'est pas du tout adapté à la musique (le texte entier de la licence doit être attaché ; et imaginez qu'il faille distribuer le master et les sources en plus du CD [15]...).
Inversement, des licences comme les Creative Commons ont été écrites pour la musique, le film, les livres, etc., mais pas pour le logiciel. Très logiquement, licencier un logiciel sous Creative Commons — par exemple une CC [16]-By-SA pour prendre une licence Open Source assez similaire à la GNU GPL [8] — n'est pas conseillé puisque tous les aspects propres au logiciel sont inexistants : la distribution du code source [17] n'étant notamment pas envisagée.
Enfin, quelques licences, plutôt rares, ont été rédigées avec l'ambition de s'étendre à l'ensemble des créations couvertes par le droit d'auteur, voire toute la propriété littéraire et artistique : l'OSL [18] et la LAL [11] sont deux très bons exemples avec des origines bien différentes.
Il est néanmoins nécessaire dans certaines situations, notamment en présence d'œuvres dites multimédias — regroupant de nombreux types d'œuvres — de réfléchir à l'opportunité d'utiliser une licence pour le tout dans un objectif d'uniformisation ou de privilégier une approche modulaire (en utilisant une licence pour chaque type d'œuvre).
Il n'y a encore une fois ni de bonnes ni de mauvaises réponses : tout dépend de l'espèce.
Sous la coprésidence de Valérie-Laure BENABOU et Joëlle FARCHY la commission spécialisée du CSPLA [19] portant sur la mise à disposition ouverte des œuvres de l'esprit a publié en juin 2007 un rapport reprenant une distinction issue
des travaux de thèse sur les œuvres libres de Mélanie CLEMENT-FONTAINE. On y retrouve la classification selon le degré de libertés conférées :
Pour comprendre l’évolution des licences Open Source, il faut suivre l'évolution de la GNU [9] General Public Licence1<.
S’appliquant évidemment au logiciel et à la documentation [13] technique l’accompagnant, la licence GPL fixe les conditions de diffusion : les logiciels sous licence GPL peuvent librement être copiés, adaptés et distribués de quelque manière que ce soit, à la seule condition de rester soumis aux mêmes termes. La question de l’interprétation de la GNU GPL [8] v2 pose problème en ce qu’elle émane d’un système de droit anglo-saxon, mais la troisième version se détache de ce droit au profit d'une terminologie contractuelle plus conforme au droit français. L'objectif est de créer un « fonds commun auquel chacun peut ajouter, mais duquel personne ne peut retrancher », comme aime à le répéter Eben Moglen, l’avocat de la FSF [12] et directeur de la SFLC [20].
Cette licence se veut la plus ouverte, mais comporte bel et bien des obligations pour l’utilisateur :
Deux vagues successives (la première le 29 juin, et la seconde le 9 novembre 2007), ont respectivement donné lieu à publication des nouvelles versions [4]<2< des GNU GPL [8] (v3), GNU LGPL [21] (v3) et de la GNU [9] Affero GPL (v3) (dite aussi AGPL).
Sur la forme, les trois licences s'affichent avec une compatibilité parfaite au profit de la GNU GPL [8] et s'offrent une modularité qui permet de faciliter leur utilisation conjointe. Si les améliorations ont pesé sur la lisibilité des licences, la FSF [12] a fait attention à conserver leur similitude. Ainsi, la GNU LGPL [21] apparaît finalement comme une exception à la GNU GPL [8] (en se concentrant sur les droits supplémentaires accordés, et renvoyant à la GNU GPL [8] pour le reste de ses termes). De même, l'Affero GPL ne se distingue de la GNU GPL [8] que par une clause qui lui permet de s'adapter aux spécificités des logiciels voués à être utilisés via le réseau sans avoir à être distribués. Ces derniers devront alors permettre aux utilisateurs de bénéficier de la version du logiciel utilisée par ledit service, comblant ainsi ce que l'on avait dénommé l’« ASP [22] loophole ». Enfin, un travail de rédaction a aussi permis d'internationaliser les licences et d'assurer leur validité pour l'ensemble des systèmes juridiques.
Garante du rôle qu'elle s'est donnée, la Free Software Foundation assure par ces mises à jour la pérennité des libertés qu'elle prône, sans aucune concession.
Sur cette question, voir notamment : Benjamin JEAN, « Option Libre : compatibilité entre contrats », sous la direction de Michel
VIVANT, ERCIM, 2006
La question « particulière » est celle de la compatibilité des licences. Si la démarche qui précède permet de s'orienter vers le choix optimal d'une licence, celle-ci peut se révéler impossible à mettre en œuvre si le produit « final » intègre des composants soumis à d'autres licences, aux termes incompatibles lors de la distribution ou de l'utilisation du logiciel.
Il n'existe pas de facto de licences dominantes : toutes ont la même force obligatoire et le licencié doit renoncer à exploiter une création lorsqu'il ne peut pas respecter l'ensemble de ses engagements.
La seule condition pour distribuer sous licence unique un projet comprenant des composants sous d'autres licences1< est que cette distribution soit permise par l'ensemble des autres licences.
Après avoir été un frein majeur aux échanges entre projets libres pendant de longues années, le problème de l'incompatibilité entre licences semble se résorber progressivement grâce aux licences « de nouvelles générations » :
La dernière version de la GNU GPL [8] (V 3) s'appuie sur ce principe pour accueillir en son sein une modularité qui lui permet d'assurer la compatibilité à l'égard d'autres licences Open Source auparavant incompatibles5< : en permettant, sur chaque nouvelle contribution, d'une part, l'ajout de « permissions additionnelles » et, d'autre part, l'ajustement par l'utilisation de certains « termes supplétifs » limitativement autorisés. Le problème n'est néanmoins pas tout à fait résolu puisqu'il faudra ensuite confronter chaque licence aux différentes clauses, au cas par cas, afin d'être certain de leur compatibilité6<.
Cette réflexion peut se traduire mathématiquement grâce à la théorie des ensembles sous la forme qui suit7< : la licence B est dite compatible (c'est-à-dire qu'elle peut être utilisée pour redistribuer le logiciel en respectant les termes de la licence originaire A) si et seulement si l'ensemble des droits de la licence B est inclus dans la licence A et que l'ensemble des obligations de la licence A est inclus dans la licence B. Ainsi, une licence est compatible avec elle-même, une licence copyleft [7] n'est pas forcément compatible avec une licence permissive et une licence permissive ne l'est forcément pas à l'égard d'une licence copyleft [7] .
Attention, la version des licences constitue dans certains cas un élément déterminant : même si la plupart permettent une compatibilité ascendante au bénéfice des nouvelles versions [4] de la licence, certaines autorisent aussi aux auteurs de licences Open Source de figer la licence à une version spécifique8<. Il y a alors un copyleft en deux temps : le premier caractérisant l'étendue de la licence et le second déterminant la version sur chaque contribution.
La situation la plus confortable consiste à rester dans la même « famille de licences » : il en existe plusieurs et celles-ci couvrent en théorie un large panel de choix tout en assurant une compatibilité parfaite entre elles9<.
Certains conflits ne peuvent contractuellement être résolus. Si l'œuvre litigieuse s'avère trop complexe pour être réécrite, il faudra alors renoncer à la distribution ou à l'utilisation du tout1<134.
Il reste néanmoins quelques autres solutions : contacter le ou les auteurs d'un composant [6] litigieux pour leur demander une dérogation, une exception ou un changement de licence ; acheter une licence commerciale à ces derniers ; se faire céder la titularité de leurs droits2< ou contourner matériellement le problème posé par la licence.
Le premier expédient possède l'avantage de la simplicité, mais son succès dépendra du nombre d'auteurs du composant [6], de leur personnalité et de ce que l'entreprise est prête à investir dans le projet. Les deux autres mesures dépendront aussi totalement de la volonté des titulaires de droits. Le dernier procédé se révèle le plus précaire puisqu'il nécessite une connaissance parfaite des licences afin d'estimer ce qui peut matériellement être permis et ce qui ne le serait pas (certaines formes de distribution3<, certains modes de distribution4< et certaines constructions du logiciel5< permettent par exemple d'alléger les contraintes).
En résumé, le processus visant à vérifier la compatibilité expresse entre une licence Open Source A (d'origine) et une licence B (licence finale) est le suivant :
Plus généralement, la condition de compatibilité est donc atteinte si l'ensemble des droits accordés par la licence absorbante B est inclus dans l'ensemble des droits conférés par la licence compatible [28] A et que l'ensemble des obligations imposées par la licence absorbante B.
Liens:
[1] http://guideopensource.info/glossary/term/30
[2] http://guideopensource.info/glossary/term/49
[3] http://www.eolevent.eu
[4] http://guideopensource.info/glossary/term/14
[5] http://fr.wikipedia.org/wiki/Tivoisation
[6] http://guideopensource.info/glossary/term/3
[7] http://guideopensource.info/glossary/term/11
[8] http://guideopensource.info/glossary/term/33
[9] http://guideopensource.info/glossary/term/31
[10] http://ar tlibre.org/
[11] http://guideopensource.info/glossary/term/48
[12] http://guideopensource.info/glossary/term/43
[13] http://guideopensource.info/glossary/term/6
[14] http://guideopensource.info/glossary/term/17
[15] http://guideopensource.info/glossary/term/20
[16] http://guideopensource.info/glossary/term/19
[17] http://guideopensource.info/glossary/term/4
[18] http://guideopensource.info/glossary/term/58
[19] http://guideopensource.info/glossary/term/27
[20] http://guideopensource.info/glossary/term/63
[21] http://guideopensource.info/glossary/term/35
[22] http://guideopensource.info/glossary/term/16
[23] http://www.gnu.org/copyleft/gpl.html
[24] http://www.april.org/articles/divers/retrospective-2007.html#ToC23
[25] http://guideopensource.info/glossary/term/70
[26] http://guideopensource.info/glossary/term/39
[27] http://guideopensource.info/glossary/term/22
[28] http://guideopensource.info/glossary/term/10