A. terminologie
1. La terminologie de base
Logiciel libre : au sens premier et strict du terme, vise le mouvement lancé autour de la GPL (General public licence) aux USA, évoquée plus loin dans cette étude.
Open source : vise les licences qui se sont développées dans l'esprit de l'OSI (Open source initiative).
Dans leur sens strict, les conditions d'une licence GPL et Open source différent sensiblement. D'où l'importance de savoir exactement de quoi on parle.
2. Les extensions de langage
Il est bien évident que la facilité de l'expression logiciel libre, et le fait qu'on ne dispose pas d'autre terme générique commode, a largement contribué à donner à ce terme le sens le plus large, groupant l'ensemble des phénomènes qui s'opposent au logiciel propriétaire. C'est dans ce sens - faute de mieux - que nous avons titré le présent article.
Les maniaques qui s'imaginent que jargonner anglais donne plus de prestige utilisent donc par extension le terme open source, sans trop savoir ce qu'il recouvre, tout comme ils utilisent, tout aussi improprement, le terme copyright dans un contexte français...
Mais les usages du langage sont là. Autant savoir qu'il existe plusieurs acceptions des termes et ajuster l'interprétation en fonction du contexte.
3. Une définition générique en négatif...
Une définition générique du logiciel dit libre serait qu'il s'oppose au logiciel totalement propriétaire, c'est-à-dire développés par un producteur identifié et qui entend en général voir respecter sa propriété. Le premier rejoint l'idée d'un certain partage des sources logicielles, nous y revenons plus bas.
B. Avertissement et vue d'ensemble
Le vaste domaine des logiciels dits libres se divise en quelques grands domaines.
Prenons cependant garde à trop théoriser. Ce mouvement est assez neuf et bouge encore beaucoup. Il est très difficile de s'y retrouver exactement dans une typologie fixe. Ajoutons que celle-ci n'est même pas souhaitable en ce sens qu'elle figerait les initiatives. Rien n'empêchera dont de rencontrer parmi les licences des monstres, en ce sens qu'elles oseraient panacher leurs éléments constitutifs, en picorant à droite et à gauche dans les divers modèles que nous allons tenter de présenter.
Un dernier mot juridique : un contrat n'est pas une loi universelle, chacun est libre d'y mettre les clauses qu'il souhaite et modeler ainsi sa relation avec un éventuel cocontractant. Rien n'est donc figé ; c'est ce que nous soulignons ici.
Cette présentation, comme toutes celles que nous avons pu voir ici ou là, doit donc être prise comme celle des grands pôles et tendances actuelles. Le mieux pour chacun sera donc de tenter de suivre les évolutions de ces courants qui peuvent encore largement muter.
La seule chose qui soit certaine : tous les acteurs et promoteurs de ces systèmes en ont par-dessus la tête du dictat des éditeurs qui jouent avec leur clientèle captive. Ils sont tous favorables à un partage, à une libre diffusion et aussi à une libre évolution des sources logicielles.
Dans ce vaste ensemble, on peut d'abord distinguer les logiciels du domaine public. Ensuite se trouve le groupe des logiciels du copyleft, les vrais logiciels libres au sens strict. Viennent ensuite les logiciels de la famille Open source. Nous y ajoutons pour être complet les plus anciens, les freeware.
C. Logiciels du domaine public
Il va s'agir de sources logicielles qui sont véritablement mises dans le domaine public, au sens du droit d'auteur classique. Ceci posera d'ailleurs un problème juridique en France puisque la seule manière qu'a un auteur de mettre vraiment son œuvre dans le domaine public est de se suicider, non sans avoir prié les usagers d'attendre 70 ans... (voir sur ce sujet le traité d'André Bertrand Le droit d'auteur et les droits voisins n°5.314 encadré ; cf. bibliographie du Droit de l'information).
1. Exploitation la plus libre possible sans aucun respect des droits
À supposer que l'œuvre soit considérée comme dans le domaine public et que plus aucun auteur ne revienne sur ce versement, toute personne pourra reprendre les éléments du logiciel sans aucun respect du droit. Ici se pose encore la question, dans les pays de droit d'auteur (par opposition aux pays de copyright qui ne connaissent pas le droit moral) du respect du nom de l'auteur. Toutes les fois où un informaticien reprendra un bout de code du domaine public pour l'implémenter dans son programme, devra-t-il malgré tout « indiquer clairement le nom de l'auteur et la source » ? Il semble que là encore, comme dans bien des domaines professionnels le droit moral « à la française » ne puisse être que bafoué par des pratiques que personne ne conteste dans un certain milieu (exemple des graphistes déjà cités dans notre article sur les Creative commons).
2. De libre d'origine, l'œuvre adaptée peut devenir propriétaire
En principe, nul n'interdit de reprendre des éléments de programmes du domaine public pour les intégrer dans des applications propriétaires qui seront donc vendues comme telles. Rien de choquant à cela, ce n'est pas parce que je fais œuvre d'anthologie commentée et annotée d'œuvres d'auteurs tombés dans le domaine public que je devrais m'abstenir de vendre mes talents. Toutes choses égales par ailleurs, on se retrouve dans une situation similaire.
3. Le code source pas forcément accessible
Un logiciel mis dans le domaine public peut ne pas livrer son code source. Comprenons bien l'hypothèse. La brique du domaine public pourra être intégrée dans une autre application, mais sans que le concepteur de l'application nouvelle puisse entrer dans la source. Il se contentera d'utiliser les fonctionnalités de la brique, sans y toucher, exactement comme un ensemblier intègre un processeur dans un ordinateur sans prétendre le démonter et percer les secrets dudit processeur.
Il pourra donc arriver qu'un logiciel soit dans le domaine public, librement exploitable mais qu'on ne puisse accéder à sa source. Il arrivera aussi, selon la volonté de son auteur d'origine, que la source soit disponible et ouverte.
D. Le concept de copyleft
Comme beaucoup de grandes innovations, le concept de copyleft est parti de la juste colère d'un chercheur, en l'occurrence Richard Stallman.
1. Origine du CopyLeft
Celui-ci fut un jour excédé de ne pouvoir accéder au pilote défaillant de son imprimante pour le réparer.
Utilisation du droit d'auteur contre le droit d'auteur...
De ce simple empêchement - qu'on a tous connus d'une manière ou d'une autre, surtout avec les systèmes d'exploitation modernes, c'est-à-dire empilant des couches de codes inextricables - est née l'idée de faire sauter le copyright ou plutôt d'utiliser le droit d'auteur contre le droit d'auteur. Le terme de copyleft, avec son double jeu de mot fut très vite emblématique de cette démarche. Notons qu'une traduction française a été tentée mais elle risque d'entraîner d'autres malentendus : gauche d'auteur.
Cession volontaire de droits d'exploitation largement libres
Ainsi fut imaginée la cession volontaire par l'auteur d'un logiciel de droits d'exploitation largement ouverts. L'auteur cède dans une licence, par avance à qui voudra l'exploiter, son droit d'exploitation mais dans des conditions de liberté assez larges : possibilité d'exploiter la source gratuitement, de la modifier sans autre accord de l'auteur, de la rediffuser, etc.
Licences bâties sur ce modèle : les GPL et les autres
Stallman fit école et fonda la Free software foundation (FSF) qui promeut un certain type de licences. Ainsi vit le jour la célèbre licence Général public licence (GPL) qui représente à elle seule environ 70% du logiciel libre.
Un logiciel très connu dans le monde de l'Internet, Apache (logiciel de serveur web) est également diffusé selon un système de copyleft.
Arrêtons-nous un instant sur les licences dites copyleftées.
2. Les licences « copyleftées » ou logiciels libres stricto sensu
Nous sommes là au cœur même de ce qu'il est convenu de nommer stricto sensu les logiciels libres. Les caractéristiques en sont bien arrêtées.
Respect du droit au nom des auteurs
Tout d'abord, si l'exploitation est libre, l'auteur conserve son droit au nom. Toutes les fois qu'une partie de son logiciel sera exploitée, intégrée dans une autre application, son nom devra donc figurer dans les « crédits documentaires » de l'application.
Réutilisation et adaptation toujours libre (licence dite « contaminante »)
Un logiciel qui est libre doit toujours faire l'objet d'une adaptation dans un autre produit libre. Cette caractéristique de la licence est appelée « contaminante » puisqu'elle contamine le produit nouveau et l'oblige à épouser le régime du produit d'origine. De sorte que le logiciel libre au départ ne peut engendrer que d'autres logiciels libres. Ainsi l'adjectif « libre » prend-il toute sa force et l'on comprend que ce soit ce type de licence qui revendique la vraie qualité de logiciel libre. Mais l'esprit de la licence affirme encore plus (4 fois plus !) le concept de liberté.
Les 4 Libertés de la FSF
La Free software foundation identifie en effet 4 libertés qui doivent se retrouver pour que la licence soit homologuée.
Liberté d'exécuter le programme pour n'importe quel usage
Le programme emprunté doit pouvoir être exploité pour n'importe quel usage. Pas de discrimination donc.
Liberté d'étudier et d'adapter le programme à ses besoins (accès à la source)
Le programme libre doit pouvoir être étudié, décortiqué par toute personne afin de le comprendre et de pouvoir l'adapter à ses besoins. La source doit donc être accessible.
Liberté de redistribuer des copies
Le programme emprunté doit pouvoir être librement redistribué.
Liberté d'améliorer le programme et de publier ces améliorations
Enfin, tout développeur doit pouvoir améliorer le programme qu'il a repris et publier ces améliorations.
L'esprit de partage en vue d'une amélioration constante
On voit ainsi très clairement les finalités du logiciel libre : la chaîne des développeurs et chercheurs doit pouvoir sans cesse se saisir des sources des collègues pour les adapter et/ou les améliorer dans une sorte de spirale de progrès sans fin et surtout sans frein juridique inutile. Tout le monde doit donc y trouver son compte dans une sorte d'esprit collectif de partage.
On peut y voir une sorte de communisme des moyens de production ; on peut aussi y voir l'esprit de communauté des monastères du moyen âge. Simple question de sensibilité...
La naissance de CECILL
Dans la foulée de la GPL et pour mieux adapter le concept de logiciel libre au droit français, le CEA (commissariat à l'énergie atomique), le CNRS (Centre national de la recherche scientifique) et l'INRIA (Institut national de la recherche en informatique et en automatique) ont unis leurs efforts pour mettre au point une licence commune de logiciel baptisée CECILL (CEa, Cnrs, Inria Logiciel Libre). La première version de cette licence a été présentée le 5 juillet 2004 avec le soutien de Renaud Dutreil, ministre de la fonction publique et de la réforme de l'État. Le 23 août 2004, l'AFUL (Association francophone des utilisateurs de Linux et des logiciels libres) apportait son soutien à CECILL. Un site d'information était ouvert dans la foulée (annoncé fin août 2005 - cf. ci-dessous Sites de référence).
Depuis le 21 mai 2005, la deuxième version de la licence CECILL est disponible. Elle existe en version française et en version anglaise, ces deux versions ayant la même valeur juridique.
E. L'open source
1. Un mouvement parallèle à celui de la FSF
L'Open source est un mouvement parallèle à celui de la FSF. On parle parfois en français de logiciel à source ouverte. Il est créé et promu par l'Open source initiative (OSI). Face au quatre libertés du logiciel libre, le système Open source s'organise autour de dix critères qui permettent d'homologuer une licence. Ce système s'oppose au copyleft en ce sens que la licence n'est pas contaminante, les licences sont dites non copyleftées...
2. Les 10 critères d'une licence pour être open source (non copyleftée)
Ces critères permettent de définir soigneusement les contours de la licence OS. Beaucoup de points sont communs à la licence GPL, mais des éléments spécifiques en font une licence non contaminante.
Libre redistribution : Le logiciel d'origine doit être gratuitement redistribué, même intégré dans un programme vendu.
Accès au code source : La source du logiciel doit être accessible.
Travaux dérivés également OS : Les travaux dérivés, c'est-à-dire reprenant et enrichissant une source sous licence OS doivent également être diffusés sous une licence OS. À ne pas confondre avec l'aspect non contaminant évoqué plus loin.
Garantie de paternité de l'auteur et intégrité du code source : L'auteur du code source et l'intégrité de celui-ci doivent être garantis. En pratique, on doit pouvoir continuer à individualiser, même dans un logiciel bâti à partir d'une source OS, la contribution empruntée et savoir de qui elle émane.
Pas de discrimination des usagers et secteurs d'activité : Le code source doit pouvoir être réutilisé dans tout type d'activité, lucratif ou non lucratif, quel que soit le secteur d'activité.
Pas de restriction des champs d'activité : Un même code source doit pouvoir servir dans tout champ d'activité professionnelle.
Redistribution du logiciel aussi ouverte : La redistribution du logiciel lui-même doit se faire de manière aussi ouverte que sa distribution d'origine. À ne pas confondre avec l'aspect non contaminant de la licence (ci-dessous).
Licence non spécifique à un produit, un package ou un réseau de distribution : Le logiciel ne peut être spécifiquement intégré à un produit, un package de divers produits ou dans un réseau de distribution particulier.
Distribution possible avec des produits protégés (licence non contaminante) : La distribution de la brique logicielle OS peut se faire avec un produit protégé et commercialisé. C'est cette particularité qui fait de la licence OS une licence non contaminante puisque le développeur qui emprunte un brique logicielle OS n'est pas tenu de propager ses conditions de distribution à l'ensemble du produit.
Neutralité technologique : Enfin, la neutralité technologique suppose que le produit puisse être portable sur tous les environnements logiciels et qu'il puisse être disponible ou transposé sous tous les systèmes d'exploitation.
F. Les logiciels « freeware »
Ce système est en quelque sorte l'ancêtre du logiciel dit libre. Il s'agit surtout d'un logiciel distribué gratuitement. Dans les débuts du développement de l'Internet, des concepteurs de logiciels dont c'était le métier ou la passion ont ainsi souhaité mettre leur création à la disposition de la communauté, dans l'esprit libertaire et de partage qui était celui du réseau lorsque celui-ci était encore essentiellement hanté par les chercheurs.
Droit d'utiliser et de copier
Pour qu'un logiciel soit freeware, il faut que son auteur distribue librement et gratuitement celui-ci. Ce système ne doit pas être confondu avec le shareware (ou partagiciel) dans lequel l'auteur fournit une copie du logiciel pour essai, à charge pour l'utilisateur d'acquitter un droit d'usage - souvent modeste - au cas où il déciderait d'en poursuivre l'usage. Certains shareware se bloquent techniquement à l'issue de la période d'essai concédée, d'autres se contentent de rappeler à chaque usage qu'il est temps de payer la redevance, histoire de donner mauvaise conscience à l'usager indélicat... Certains auteurs n'ont pas hésité à grouper le shareware dans la catégorie des logiciels libres, aux motifs qu'ils sont gratuits « un certain temps » et que la distribution en est libre.
Le freeware réunit au contraire une vraie distribution et une licence d'usage gratuites de bout en bout.
Code source non accessible
Cependant, dans le système freeware, le code source n'est en principe pas accessible. Le concepteur offre l'outil, mais ne permet pas qu'on entre dans la source, ni pour en comprendre le fonctionnement ni pour le modifier.
Le système du freeware est le degré le plus rudimentaire du logiciel dit libre.
G. Le vrai coût du libre et son opportunité
Les détracteurs du logiciel libre - en clair les partisans du logiciel propriétaire - mettent souvent en avant les coûts cachés du libre... Le plus gros argument est celui de la garantie. On se procure un logiciel en apparence gratuit mais qu'en est-il de la garantie apportée au produit ? Et que se passe-t-il lorsqu'on a « investi » dans des produits libres qui se révèlent défectueux, entraînant de coûteuses déconvenues dans l'entreprise ? Ne vaut-il mieux pas rester sagement entre les mains d'un propriétaire qui va choyer ses clients ?
La question est peut-être plus sophiste qu'il n'y paraît mais elle mérite qu'on s'y arrête.
Tout d'abord, même si les multinationales ont la vie dure, il arrive qu'elles disparaissent. Et dans ce cas que fait-on du produit propriétaire sur lequel on a tout misé ? Le code source étant fermé à tout jamais, il est même impossible d'en sortir élégamment. Il faut réinformatiser de A à Z. On le voit, l'argument peut se retourner contre les logiciels propriétaires.
Dans le cadre d'une licence libre, on peut veiller à avoir accès au code source et dans ce cas, c'est une affaire de compétence en interne dans l'entreprise. En d'autres termes, le libre n'est pas forcément une solution clé en main pour de petites structures qui n'auraient pas les compétences informatiques nécessaires, sauf à utiliser des modules simples pour des applications simples : rien ne prouve qu'un logiciel comme Open Office sera plus catastrophique à mettre en œuvre que Microsoft Office. Les deux produits ont fait leurs preuves et les produits Microsoft sont connus pour leurs bugs...
Par ailleurs, la question de la responsabilité est concrètement très difficile à mettre en œuvre face à des géants du logiciel standard. Elle se pose plutôt dans le cadre de progiciels spécifiques supposant des paramétrages délicats. Là encore, la distinction que les tenants du logiciel propriétaire voudraient absolument tranchée n'est pas si nette.
Mais il est vrai que dans certains contextes, le recours au libre suppose quelques précautions et parfois la certitude d'avoir sous la main une assistance technique, qu'elle soit interne ou simplement une ressource en termes de prestataires de service à portée de contrat.
En revanche, pour des usages aussi massifs que des administrations étatiques, l'investissement de départ est minime pour des gains de productivité et des économies d'échelle sans comparaison, des équipes informatiques pouvant se consacrer à développer et distribuer gracieusement des ajouts spécifiques à des briques de logiciels libres. C'est pourquoi de plus en plus d'États du monde, à commencer par les USA, mais aussi la France et beaucoup d'autres pays d'Europe, adoptent une politique de logiciel libre, suivis en cela par leurs instances territoriales (collectivités locales en France).
H. Conclusion
Il ne nous paraît pas qu'il faille présenter les logiciels propriétaires et les logiciels libres dans un absolu manichéisme, l'un excluant nécessairement l'autre. Il apparaît plutôt aujourd'hui qu'il en va des logiciels comme du reste des œuvres protégées par la propriété intellectuelle, certains peuvent être diffusés plus librement de par la volonté de leurs concepteurs et d'autres peuvent se développer dans un système de pure protection par la propriété intellectuelle, le cas échéant renforcée par leur brevetabilité.
Mais il faut bien prendre conscience du fait que les deux types de production peuvent cohabiter, chacun prenant ses responsabilités et la clientèle faisant ses choix au vu de ses intérêts. L'heure n'est donc pas à l'annonce de la mort du logiciel propriétaire, mais à l'ouverture d'un marché plus libre et plus collaboratif qui se déploie dans une perspective et selon un modèle économique différent.
Les sites de référence
- Le site de la FSF : http://www.fsf.org - le site français : http://fsffrance.org
- Communiqué de naissance de CECILL : http://www.inria.fr/presse/pre119.fr.html
- Communiqué de Renaud Dutreil :
http://www.fonction-publique.gouv.fr/leministre/lescommuniques/communique-200407061150.htm
- Communiqué de l'AFUL : http://www.aful.org/presse/pr-20040823-cecill
- Le site de CECILL : http://www.cecill.info
- Le site de l'OSI : http://www.opensource.org
|cc| Didier Frochot — juin 2005
