Skip to navigation – Site map

HomeNuméros14Autour d’Ostrom : communs, droits...Ostrom, la propriété et les communsUne innovation institutionnelle, ...

Autour d’Ostrom : communs, droits de propriété et institutionnalisme méthodologique
Ostrom, la propriété et les communs

Une innovation institutionnelle, la constitution des communs du logiciel libre

Institutional innovation, the birth of free software commons
Una innovación institucional, la constitución de los communs de programas libres
Pierre-André Mangolte

Abstracts

Today, free software has become a benchmark for resistance to the “tragedy of the anti-commons”. The sharing and reuse of source code are indeed principles opposed to the exclusive control of technical objects by individual owners. Inventing licenses which diverts copyright and rules of “intellectual property”, free software programmers were able to create a commons (a stock of software) to which anyone may add but from which no one may subtract which everyone can add something. One can speak of a true institutional innovation and an authentic common. The article traces the history of the formation of free software by highlighting the original features of this common understanding as a set of resources, more or less perennial, to which access and use are shared in a group, and here, this group is formally all mankind. It discusses the constitutional basis of the common, the free software (or open source software) licenses and their rules, founding of a particular economy. It sets limits and draws a map of this common.

Top of page

Full text

1. Introduction

1Partout où règnent les « droits de propriété intellectuelle », de nombreuses activités sont entravées, ou même interdites, par le principe d’exclusivité qui accompagne le copyright et les patents (droit d’auteur et brevet d’invention). Aussi, et ne serait-ce que pour ce motif, l’analyse de l’expérience des logiciels libres est incontournable. La mise en commun, le partage et la libre circulation du code et des logiciels sont en effet des principes opposés au contrôle exclusif de l’objet technique par un propriétaire. Ce contrôle a pourtant été renforcé et même transformé en une règle quasi-absolue dans toutes les sociétés réglées par les « droits de propriété intellectuelle » depuis les années 1980. C’est ainsi que le logiciel libre est devenu une référence, voire la référence, en matière de résistance à cette « deuxième tragédie des anti-communs ». C’est une preuve historique de la possibilité de s’opposer à cette tragédie, une preuve qui a pleinement démontré son efficacité en matière d’innovation, ayant donné naissance à de grands projets communautaires de développement logiciel, tels Linux, Debian, Mozilla, Gnome, etc. On parle alors couramment des « communautés du logiciel libre ».

  • 1 « It [la licence GPL] creates a commons, to which anyone may add but from which no one may subtract(...)

2Au cœur de cette expérience, il y a des règles de partage et de mise en commun des logiciels, qui détournent les règles de la « propriété intellectuelle », avec la constitution progressive « d’un commun [un stock de logiciels] auquel chacun peut ajouter quelque chose mais duquel personne ne peut rien retirer », comme l’explique le juriste Eben Moglen, conseiller de la Free Software Foundation. Ce stock de ressources pérennes garantit d’ailleurs que « les améliorations et les corrections seront [toujours] accessibles »1. Notons au demeurant que l’expérience des logiciels libres a fait école dans des domaines a priori étrangers au logiciel. C’est en particulier la première et principale source d’inspiration des fondateurs des Creative Commons (Aigrain, Peugeot, 2005).

3Le logiciel libre représente donc une référence et même une des origines du mouvement actuel de formation (ou reformation) d’un certain nombre de communs. C’est une définition en acte, concrète et vivante, de ce que beaucoup entendent par le terme « commun », un commun sans doute très différent des anciens communaux des sociétés paysannes de l’Ancien Régime, ou des pêcheries, ou des communs fonciers, analysés dans la littérature actuelle sur les « commons ». Une des particularités du commun des logiciels libres est en effet d’avoir donné naissance à des activités de production utilisant les ressources partagées et destinées au commun, un trait qui différencie ce commun des logiciels libres de bien d’autres.

4Le but de cet article est de retracer l’histoire de la formation du logiciel libre, et ce faisant de mettre en évidence en quoi il constitue un type original de commun, entendu ici (dans un sens très général) comme un ensemble de ressources, plus ou moins pérennes, dont l’accès et l’usage sont partagés dans un groupe plus ou moins étendu, pouvant aller jusqu’à l’humanité toute entière. Mon parti-pris méthodologique est en effet de partir de l’analyse du phénomène logiciel libre et des discours théoriques des promoteurs du libre, pour produire une définition du terme « commun » compatible avec le phénomène étudié, sans faire référence à des cadres conceptuels ou des modèles préétablis tirés de la littérature existante. On ne trouvera donc ici aucune référence aux constructions théoriques de l’école américaine, aucune référence aux travaux d’Elinor Ostrom, à l’article d’Edella Schlager et Elinor Ostrom (1992), ou à l’approche alternative d’Etienne Le Roy, d’Alain Karsenty et d’Alain Bertrand (1996), ou à des analyses plus anciennes comme celle de Marc Bloch (1931) sur les communaux.

5On peut, me semble-t-il, très bien définir les communs du logiciel libre sans cette littérature. L’étude détaillée de l’histoire de la mise en place du système des licences montre qu’il existe une définition du logiciel libre et de ses communs produite par les acteurs eux-mêmes, ceux qui ont fait le logiciel libre. C’est même un des intérêts de la démarche proposée ici. L’investigation autour de la naissance du logiciel libre et la discussion de ses traits constitutifs ouvre à une autre origine et une autre définition des communs que celle d’Elinor Ostrom et de son école. Richard Stallman en particulier est ici d’un précieux secours.

  • 2 Par « économie », nous entendons ce qu’entendait Adam Smith, c’est-à-dire la création, la distribut (...)

6Pour préciser les choses, l’exposé se limitera à la naissance des logiciels libres, et de leur base constitutionnelle, les licences de free software ou open source software. Ces licences, et les règles qu’elles contiennent, sont en effet la base juridique à partir de laquelle le monde du logiciel libre et certains communs sont nés, ce qui représente aujourd’hui un sous-ensemble de l’économie des logiciels2. Mais nous laisserons de côté la description de cette économie du logiciel libre et de ses formes de production, communautaires ou non.

7Dans mon exposé, je commencerai par contre par retracer l’histoire de cette innovation institutionnelle du logiciel libre, et ses causes (points 2. et 3.). J’analyserai ensuite le système des règles fondant et structurant les communs du logiciel libre (point 4.), puis essayerai d’en tracer les limites et d’en dresser une cartographie (point 5.). Finalement, dans la conclusion (point 6.), suite à cette investigation, je reviendrai plus longuement sur la définition et la discussion du terme « commun ».

2. Le logiciel, une valeur d’usage transformée en marchandise

  • 3 Le code (ou code-source) est un ensemble d’instructions adressées à une machine (l’ordinateur) mais (...)

8Aujourd’hui, dès sa création, tout logiciel (ou software) est sous copyright (ou droit d’auteur). C’est une règle absolue depuis les années 1980. Cela signifie qu’il existe toujours un propriétaire individuel, être humain ou firme, qui détient des droits exclusifs sur le code-source et les copies binaires3, et que celui-ci peut légalement en interdire ou en contrôler l’usage. Cette situation différencie le logiciel des autres objets techniques que sont par exemple les composants de l’ordinateur. En règle générale en effet, connaissances et artefacts techniques évoluent tous dans des systèmes de règles et de droits qui sont non exclusifs, le contrôle éventuel de la technique n’étant que partiel, précaire et temporaire. C’est le régime du secret avant divulgation, et du domaine public après divulgation. Seules les innovations brevetées échappent à ce cadre. En pratique donc, en dehors des industries émergentes, reposant sur quelques innovations basiques mises sous brevet, ce régime général intègre une forme de commun (le domaine public). La plus grande partie des connaissances et des techniques sont alors librement utilisables pour toute activité industrielle et commerciale (ce qui est d’ailleurs une condition fondamentale de l’entrée dans les industries et de la mise en concurrence des entreprises). Mais les innovations logicielles et le stock même des logiciels existants relèvent (en dehors du système des logiciels libres) d’un régime différent, où tous les produits sont attribués dès leur création, avec des droits exclusifs, à des personnes physiques ou morales, des êtres humains ou des entreprises.

9La situation était pourtant complètement différente au début de l’industrie informatique, personne ne se posant alors réellement la question du statut juridique des programmes destinés aux ordinateurs, car ceux-ci étaient avant tout considérés comme des valeurs d’usage et non comme des valeurs d’échange. Jusqu’au milieu des années 1960 en effet, les logiciels ne sont jamais vendus directement. Les constructeurs d’ordinateurs, au premier rang la firme IBM, fournissent « gratuitement » le code avec les matériels loués ou vendus. Il s’agit principalement du système d’exploitation, indispensable pour toute utilisation d’un ordinateur, ou de logiciels permettant la traduction des langages de programmation en langage machine. De leur côté, les utilisateurs développent eux-mêmes les logiciels d’application dont ils ont besoin. Une autre possibilité est la production par une société de service d’un programme développé pour la demande spécifique d’un client et en interaction étroite avec celui-ci. Le logiciel n’est donc jamais réellement vendu en tant que tel, mais fourni plutôt dans le cadre d’une autre relation marchande : vente de matériel ou relation de service. C’est d’ailleurs la pratique chez IBM, dont la politique officielle est : « Nous vendons des services et non des matériels », cette entreprise facturant des prestations globales en fonction du « service rendu par l’ordinateur », et non en fonction de ses propres coûts (Dréan, 1996).

  • 4 À l’époque de la mécanographie, ce sont les schémas de câblage entre machines (l’équivalent d’un lo (...)

10Parallèlement à la vente de services, IBM encourage et organise même le partage du code. Dans les années 1950-1960, les pratiques de coopération en matière de développement logiciel entre utilisateurs des mêmes machines sont en effet courantes, car elles répondent à un véritable besoin. Pour les scientifiques et les chercheurs, c’est une sorte de norme, et pour l’ensemble des firmes, une habitude qui remonte à l’époque de la mécanographie4. IBM fournit un « soutien logiciel » aux utilisateurs de ses ordinateurs, c’est-à-dire quelques programmes et une formation à la programmation, et les ingénieurs et commerciaux d’IBM rassemblent les sous-programmes (en langage d’assemblage à l’époque) qu’ils développent chez les clients, ainsi que ceux que les clients ont eux-mêmes développés, pour les redistribuer ensuite. Les coûts de développement et les résultats sont ainsi partagés, les machines peuvent être utilisées de manière plus efficace, et IBM comme les utilisateurs y trouvent leur compte.

  • 5 Voir aussi l’article d’Atsushi Akera, (2001).

11On peut donner un exemple ici, le programme SHARE mis sur pied lors du lancement de l’IBM 704 en 1954. Ce nom n’était pas une abréviation, mais affirmait simplement de manière explicite l’objectif, partager (to share) les informations et les programmes. Il s’agissait aussi de favoriser la communication entre les utilisateurs et les ingénieurs d’IBM qui préparaient déjà les futurs produits de la firme. Les économies attendues étaient d’ailleurs considérables. On estimait que chaque utilisateur pionnier de l’IBM 704 devait dépenser l’équivalent de sa première année de location à mettre au point ses programmes de base, lesquels étaient alors rendus accessibles gratuitement aux autres utilisateurs, membres du programme SHARE. Au bout d’un an d’existence, SHARE comprenait 62 organisations membres aux États-Unis ou ailleurs dans le monde, pour un parc de 76 machines IBM 704, avec une bibliothèque de plus de 300 programmes disponibles (Campbell-Kelly, 2003, p. 35-365). SHARE servit aussi d’interface entre les demandes des utilisateurs et les services de programmation du constructeur, en permettant de dégager progressivement une définition commune des outils logiciels nécessaires aux utilisateurs.

Schéma 1. SHARE, un pool de ressources communes géré par une firme

Schéma 1. SHARE, un pool de ressources communes géré par une firme

12À cette époque, personne ne se pose la question de la protection juridique des logiciels comme actifs de la firme, ni même celle de leur valeur marchande. Il n’y a ni vente directe, ni prix fixé, ni valeur d’échange attribuée au code, mais simplement un ensemble de règles et de formes organisationnelles présidant à une circulation plus ou moins étendue du code et des programmes. Pour tous, le logiciel est une chose coûteuse à produire et le but du partage est la diminution des coûts et la réduction des investissements nécessaires. Le logiciel est aussi une chose utile, très utile même, indispensable pour « donner une âme à la machine », selon l’expression de Dréan (1996), mais cette chose n’a encore aucune valeur d’échange, car il n’y a aucun commerce ici, aucun « marché ». Le logiciel circule alors comme circulent les « idées », les recettes, les méthodes de production, à travers les rapports que les différents programmeurs peuvent entretenir entre eux dans les opérations de production, de formation et de maintenance, à l’intérieur et entre les firmes, dans une relative indifférence des services juridiques ou marketing de celles-ci.

13À partir du milieu des années 1960, les premières tentatives de commercialisation de logiciels vont apparaître. C’est le fait de certaines sociétés de services qui, ayant développé un programme particulier pour un client, pensent possible la vente à d’autres clients. Un logiciel écrit pour traiter la paye d’une firme A est donc réécrit pour une firme B, puis pour une firme C, à l’image d’un costume prêt à porter « de bonne qualité, mais toujours mal ajusté » (Campbell-Kelly, 2003). Le modèle économique de ces firmes reste construit sur la fourniture d’une solution sur mesure, avec un réemploi plus ou moins habile et plus ou moins important des développements antérieurs, accompagné d’opérations de maintenance et de formation des utilisateurs. Le logiciel n’est donc pas vendu indépendamment du reste, comme un produit autonome prêt à l’emploi. L’apparition de ce type de produits logiciels (ou progiciels) est en effet plus tardive, au cours des années 1970 essentiellement.

14IBM représentait encore 70 % du chiffre d’affaires de l’industrie informatique américaine. Mais la vente des ordinateurs l’emporte désormais sur la location, et sur cette base de machines installées, un secteur autonome de fourniture de services est apparu, y compris pour les logiciels. La politique de facturation globale selon le service rendu (et vendu) est donc remise en cause. Pour les autorités antitrust, cette politique est d’ailleurs susceptible de couvrir des pratiques de ventes liées, elle est donc suspecte. IBM va donc changer sa politique commerciale en 1969, en facturant désormais séparément ses différentes prestations (c’est l’unbundling) : vente de matériels, ingénierie de système, formation des utilisateurs, maintenance, services de programmation et... fourniture de software. La tarification dissociée est généralisée dès 1972 à l’exception de certaines prestations toujours incluses et « gratuites », comme le système d’exploitation compris dans le prix de l’ordinateur. Le logiciel a donc maintenant officiellement un prix. Il peut même être commercialisé en tant que tel.

15La politique de l’unbundling donne au logiciel une valeur marchande qu’il n’avait pas auparavant. Et ce n’est pas le travail de programmation effectué pour le client, le travail sur le code qui acquiert subitement de la valeur, car ce travail était déjà évalué et comptabilisé comme coût. C’est le logiciel en tant que tel, comme produit indépendant de tout service associé, indépendant des machines, indépendant même de son propre développement, et de tout travail sur le code. À l’époque cependant, la séparation reste embryonnaire et largement artificielle, dans la mesure où les développements logiciels sont encore la plupart du temps spécifiques à tel ou tel client et accompagnés d’autres prestations, qui représentent encore la part la plus importante des offres d’IBM et de ses concurrents.

16La nouvelle approche fait cependant du logiciel un produit commercial comme un autre, ce qui va donner naissance un peu plus tard à un nouveau modèle économique, avec l’essor du marché des progiciels à la fin des années 1970 et au cours des années 1980, des logiciels vendus « comme des produits au sens le plus classique du mot, commercialisés prêts à l’emploi, utilisables indépendamment de leur auteur, définis pour un marché anonyme et non pour un utilisateur particulier » (Dréan, 1996, p. 205). Ce type de logiciel est conçu pour une demande anonyme, bien définie, le choix des clients se faisant sur catalogue (ou sur étagère dans un magasin spécialisé), le même progiciel est diffusé en de nombreux exemplaires identiques et le plus longtemps possible. Le développement du programme est alors séparé de sa diffusion, relevant dans la même firme de deux services différents ou incombant à deux sociétés distinctes, les services d’accompagnement (formation, maintenance) ayant pratiquement disparus.

  • 6 Pour développer un logiciel, il faut pouvoir accéder à un ordinateur facilement et de manière perma (...)
  • 7 La logique générale de cette économie du progiciel est en effet monopoliste, avec « la persistance (...)

17Au cours des années 1970, la pression d’une concurrence par les coûts sur le matériel pousse d’ailleurs à l’abandon des modèles économiques antérieurs, où la vente du matériel subventionnait le développement logiciel. Le prix des programmes s’envole et les livraisons de logiciels gratuits se font de plus en plus rares (Dréan, 1996, p. 207). Le secteur des logiciels utilitaires généraux (comptabilité, paye, gestion des ressources humaines, etc.) est le premier à s’organiser ainsi, sans vente de matériel et sans fourniture d’autre service. Mais c’est avec l’arrivée de la micro-informatique, dans les années 1980, que le modèle économique du progiciel commercial va réellement devenir important, car la diffusion rapide des micro-ordinateurs crée le marché de masse nécessaire aux programmes développés comme progiciels6. Une multitude de petites entreprises, souvent formées par une poignée de programmeurs, apparaissent alors, offrant chacune un logiciel particulier conçu pour une utilisation bien précise. Mais ce foisonnement quasi-artisanal va très vite laisser place à quelques grandes firmes à caractère industriel contrôlant des positions dominantes (comme Oracle ou Microsoft)7.

18Ces transformations posent à tous le problème de la caractérisation juridique des logiciels. Comme le code a désormais une valeur marchande, et qu’il génère des revenus et des profits, il devient un actif de la firme, il doit donc être « protégé » en tant que tel, ainsi pensent du moins la plupart des managers des entreprises. Vient alors la question pratique : trouver, parmi les dispositifs existants (patents, copyright, secret de fabrication, etc.), celui qui est le plus adapté au nouveau modèle économique des progiciels commerciaux. Pour les juristes bientôt mobilisés pour trancher le problème, il y a ici un problème de caractérisation, savoir quel dispositif juridique s’applique aux logiciels, et quelles modifications éventuelles apporter aux lois existantes pour adapter le droit à ces nouveaux objets que sont les programmes, et plus généralement à tout ce qui peut être stocké dans les mémoires des ordinateurs.

  • 8 Selon une jurisprudence de la fin du xixe siècle (Baker v. Selden, 1879), un principe explicitement (...)

19Ce sont d’abord les patents qui sont utilisés en premier, l’Office américain des patents (USPTO) acceptant assez vite la brevetabilité dans le domaine des softwares qu’ils soient ou non liés avec le matériel (hardware). Mais la validité de ces patents est déjà à l’époque largement contestée, les brevets étant traditionnellement conçus comme devant protéger des artefacts tangibles, et non des idées ou des actifs intangibles. Le logiciel, une forme d’écriture utilisant largement les algorithmes, les formules mathématiques et les symboles semble en effet plus proche des idées que de l’artefact tangible, et par là-même difficilement brevetable. Les patents accordés peuvent alors se révéler de faible valeur en cas de contestation juridique. D’un autre côté, le copyright est applicable au code source, au texte écrit par le programmeur dans une forme compréhensible par les êtres humains, avec les commentaires et la documentation associée. À partir de 1964, des programmes sont alors déposés sous cette forme à l’administration des copyrights. Mais cela protège assez mal le producteur du logiciel, puisque le code source est alors dévoilé, et que la loi du copyright n’accorde un droit exclusif que sur une « expression » particulière, excluant toute protection en matière « d’idées, de principes, de faits », etc.8 Mais la lecture du code source donne accès aux algorithmes et aux fonctionnalités, et permet une réécriture dans une « expression » différente, avec au final un programme équivalent.

  • 9 Dans cette commission, fait remarquable, il n’y avait aucun représentant de l’industrie informatiqu (...)
  • 10 Pour Hersey, le code source a deux caractéristiques : communiquer des instructions à la machine et (...)

20La demande des éditeurs de progiciels est alors une inscription directe du logiciel dans la loi du copyright sans obligation de dévoilement, avec une extension de la protection à toutes les formes de « copies », une extension donc au code machine des fichiers binaires. Une commission, la commission CONTU (National Commission on New Technological Uses of Copyrighted Works), est formée aux États-Unis pour trancher la question qui préconise en 1978 d’étendre au logiciel (sous toutes ses formes) la protection du copyright9. La seule opinion dissidente fut celle de John Hersey, président de l’Authors League of America et auteur lui-même. Distinguant le code source du code compilé (le code machine), il proposa en vain un amendement à la loi du copyright de 1976 pour rendre explicite que le copyright portant sur le code source ne pouvait être étendu au code compilé, devenu par là même un simple élément de la machine10. Mais en 1980, le Congrès suivit les recommandations de la commission CONTU et amenda le copyright Act, en étendant le principe d’exclusivité aux fichiers binaires.

21Ce changement de la loi ne faisait que valider, légitimer et renforcer des pratiques déjà bien établies. Les producteurs de progiciels avaient en effet mis au point des « stratégies propriétaires », selon l’expression consacrée, combinant secret de fabrication, droit du copyright, droit des marques, et systèmes de licences. Le point clef était de vendre uniquement des fichiers binaires, le code source devant rester inaccessible et caché. Le logiciel était de plus accompagné d’une licence restrictive en matière d’utilisation, interdisant toute décompilation ou rétro-ingénierie, limitant les installations possibles du programme (nombre de machines, etc.), prohibant toute copie, toute modification, toute redistribution. La documentation accompagnant les binaires était mise sous copyright classique le personnel de la firme ayant développé le logiciel soumis à des clauses de non divulgation. Le partage du code ou des binaires est alors une pratique proscrite, stigmatisée comme étant de la « piraterie ». Le logiciel n’est plus qu’un actif commercial dont il faut tirer le maximum de revenus le plus longtemps possible, en empêchant donc toute « copie » et toute activité de transformation, amélioration ou innovation à partir du code source.

3. Les années 1980, l’enfermement propriétaire et la naissance du logiciel libre

  • 11 On peut évoquer ici l’expérience vécue par Richard Stallman. Devant régler pour son laboratoire un (...)

22Dans l’industrie informatique américaine, il y a alors une sorte de rupture dans les normes de comportement régulant la circulation des logiciels et plus particulièrement du code source. L’essor du marché des progiciels a changé la représentation qu’on se faisait de ce code. Pour les dirigeants et les services juridiques des entreprises, ce n’est plus un simple objet technique, c’est un actif, une forme de capital ; et les programmeurs vont devoir intégrer cette nouvelle donnée, qu’ils le veuillent ou non. Le secret et la non-communication deviennent des règles absolues, et les politiques « propriétaires » de fermeture et de rétention du code servent de modèle de référence à toute l’industrie informatique, et ceci, même dans les situations où les modèles économiques des firmes ne sont aucunement menacés (bien au contraire) par le maintien des pratiques antérieures de partage11.

23C’est un renversement général des règles de comportement qui est alors prôné et imposé. Car comme le note Richard Stallman, aux débuts de l’informatique la règle générale était plutôt le partage du logiciel, « une notion aussi ancienne que les premiers ordinateurs, tout comme on partage des recettes depuis les débuts de la cuisine » (Stallman, 1999, p. 61), tous les programmeurs, qu’ils soient chercheurs universitaires ou employés par des firmes de l’industrie, avaient pour habitude de communiquer le code à la demande. « Quand des ingénieurs souhaitaient utiliser l’un de nos programmes, nous leur en accordions volontiers l’autorisation. Et quand on voyait quelqu’un utiliser un programme intéressant mais inconnu, on pouvait toujours en obtenir le code source, afin de le lire, de le modifier, ou d’en vampiriser des parties dans le cadre d’un nouveau programme » (Stallman, 1999, p. 62).

24La nouvelle représentation contamine même les universités et les centres de recherche, des institutions où la norme est pourtant traditionnellement la publication et la mise dans le domaine public, la diffusion la plus large possible des résultats d’une recherche étant de l’avis général le seul moyen d’obtenir une progression rapide de la science et du savoir. Ce renversement des représentations, des règles et des valeurs pose alors un problème aux chercheurs et aux programmeurs. S’agit-il d’une évolution somme toute inéluctable, l’économie du code devenant enfin « mature », car marchande ? Ou s’agit-il du simple exercice, normal et légitime, d’un « droit naturel » du propriétaire du code ? Le contrôle des usages est-il réellement nécessaire et indispensable pour assurer le financement et la production de logiciels de bonne qualité, couvrant toutes les demandes sociales ? Ou s’agit-il simplement d’un « système social, celui du logiciel propriétaire », qui en vous interdisant de partager et d’échanger le logiciel, « est antisocial, immoral, et tout bonnement incorrect » (Stallman, 1999, p. 62) ?

  • 12 C’est ce qui devait arriver en particulier à la communauté des programmeurs constituée autour du sy (...)

25Le changement des règles de comportement entre de plus directement en conflit avec les formes de coopération nouées antérieurement pour le développement de certains programmes. Les nouveaux ordinateurs apparus dans les années 1980, comme par exemple les Vax de la société Digital, sont fournis comme toujours avec leur propre système d’exploitation, mais celui-ci est accompagné de la nouvelle norme. Il faut signer des accords de non divulgation pour en obtenir des copies exécutables, et tout travail coopératif entre utilisateurs-programmeurs visant la transformation et l’amélioration de ces programmes est désormais impossible. Les processus d’invention collective qui existaient çà et là dans l’industrie sont sapés à la base, et les communautés de programmeurs-utilisateurs constituées autour de certains développements logiciels menacées d’effondrement12.

  • 13 Pour l’histoire d’Unix, voir Salus, 1994, et Behlendorf et al., 1999.

26C’est le cas en particulier pour la communauté constituée à partir de 1974 autour du développement du système d’exploitation Unix, une communauté comprenant les Bell Labs, appartenant à AT&T et Western Electric, et un grand nombre d’universités et de centres de recherche situés un peu partout aux États-Unis et dans le reste du monde. À l’origine de cette communauté d’utilisateurs-programmeurs qui émerge plus ou moins spontanément, il y a l’impossibilité pour les Bell Labs d’envisager une exploitation commerciale du code, en vertu d’un consent decree de 1956 dans le cadre d’une procédure antitrust interdisant à la compagnie de téléphone toute activité commerciale en informatique13. L’exercice habituel des droits de patents, copyright ou secrets de fabrication est donc abandonné, et la pratique des Bell Labs pour tout ce qui relève de l’informatique est d’accorder automatiquement licence avec un fee peu élevé et même gratuitement dans le cas des universités et des centres de recherche. Cette situation particulière favorise la diffusion et la réutilisation du code d’Unix, et donne naissance à un réseau d’utilisateurs partageant leurs corrections de bogues et toutes les améliorations et développements qu’ils apportent au système d’exploitation. Assez vite d’ailleurs, les Bell Labs, à l’origine du système, ne sont plus qu’un foyer de production et diffusion d’innovations parmi d’autres, un foyer dont l’importance décline progressivement, l’Université de Berkeley s’imposant dès le milieu des années 1970 comme le foyer principal du développement d’Unix, avec les premières distributions de code BSD (Berkeley Software Distribution).

  • 14 En 1978, les droits (fee) étaient déjà de 7000 $ pour une Université, et plus pour une licence « co (...)
  • 15 En dehors du développement de l’Arpanet (cf. Abate, 1999), un des problèmes préoccupant la DARPA ét (...)
  • 16 Cette distribution comportait tout ce qui permettait la gestion des réseaux (TCP/IP) et la connexio (...)

27Mais au début des années 1980, la procédure antitrust contre AT&T est relancée sur d’autres bases avec comme perspective la fin du monopole téléphonique, réalisé en 1984 avec l’apparition des Baby Bells, la séparation des Bell Labs du reste du groupe, et le droit pour ceux-ci de développer des activités commerciales en informatique, dans le domaine du hardware comme du software, ce qui sera acté officiellement en juin 1984 par le proposed decree du juge Greene. On assiste alors à un changement complet de la politique de licence des Bell Labs, avec une augmentation importante du prix des licences (y compris pour les universités), et une redéfinition restrictive des conditions d’utilisation du code14. L’un des effets de cette évolution est le transfert de fait à la communauté de la responsabilité du développement du système d’exploitation Unix, les programmeurs de Berkeley bénéficiant d’ailleurs pour ce faire de plusieurs financements de la DARPA accordés pour développer la portabilité du système, d’un matériel à l’autre, et la gestion des réseaux (TCP/IP) nécessaire au développement de l’Arpanet, l’ancêtre de l’internet15. Cependant, les utilisateurs du code produit à l’université de Berkeley, un code accompagné d’une licence très permissive accordée par les Régents de l’Université de Californie, doivent toujours obtenir une licence d’AT&T pour le code provenant des Bell Labs. Devant l’augmentation du coût des licences, certains utilisateurs demandent la séparation du code produit à Berkeley et du code sous licence AT&T, ce qui conduit en juin 1989 à la sortie de la première distribution de Berkeley librement redistribuable, la Networking Release 116. À cette époque, l’éclatement de la communauté Unix était déjà consommé. AT&T et les Bell Labs étaient engagés dans la mise au point de distributions commerciales stables, une démarche qui devait aboutir à la formation de la société Unix System Laboratories, afin de commercialiser le System V, lequel fut la base de la plupart des Unix propriétaires (AIX, HP-UX, IRIX, Solaris 2, etc.) des années 1980-1990. La séparation pour raison juridique des codes sources était donc inévitable, et un travail de réécriture du code des Bell Labs fut engagé par le réseau des utilisateurs, afin de « libérer » la totalité du code d’Unix (y compris les utilitaires et les bibliothèques) de la licence AT&T, ce qui devait donner finalement la Networking Release 2 (juin 1991). Différentes équipes de développeurs apparurent alors : NetBSD, freeBSD, OpenBSD et BSDI qui prenaient désormais en charge le destin du programme dans différentes architectures et selon différents modèles économiques.

28Le changement général des règles en matière de logiciel pose aussi problème à chaque programmeur individuel, au moment en particulier où il quitte l’université et le monde de la recherche pour rentrer dans l’industrie. Le choix est alors d’accepter les nouvelles règles ou de les refuser. Accepter donc, comme le dit Stallman, de rejoindre le monde du logiciel propriétaire, en signant des accords de non divulgation, en promettant de ne pas aider les autres programmeurs, en contribuant ainsi à une évolution conduisant à un monde où toute communauté coopérative serait interdite, un monde où des murs de plus en plus hauts, ceux des différentes firmes, sépareraient les différents programmeurs (ou programmeurs-utilisateurs), les isolant les uns des autres (Stallman, 1999, p. 64). Le refus de cette perspective conduisit Richard Stallman à démissionner du MIT pour démarrer un projet de création d’un ensemble de « logiciels libres » (free softwares) autour d’un système d’exploitation compatible Unix « libre », le code source devant être disponible et accompagné juridiquement de droits d’usage très étendus, des droits que les auteurs du code concéderaient à tous les utilisateurs. L’objectif est alors le maintien ou la renaissance des « communautés coopératives » de développement de logiciels ; et ce projet fut bientôt désigné par le terme GNU, un acronyme récursif signifiant simplement « GNU’s Not Unix » (GNU n’est pas Unix), pour bien marquer le refus éthique et politique de l’évolution en cours dans la communauté d’Unix, avec la fermeture d’une partie du code, la division de la communauté, et l’apparition de différents Unix propriétaires. Pour entreprendre ce projet, il était cependant nécessaire d’être soi-même libre d’accorder juridiquement des droits aux autres. « J’ai [alors] démissionné de mon poste du MIT, [car] le MIT aurait pu se déclarer propriétaire de mon travail, et lui imposer ses propres conditions de distribution, voire en faire un paquetage de logiciels propriétaires. Je n’avais pas l’intention d’abattre autant de travail et de le voir rendu inutilisable pour ce à quoi il était destiné : créer une nouvelle communauté qui partage le logiciel » (Stallman, 1999, p. 66).

29Le choix de développer un système d’exploitation compatible Unix était plus technique et stratégique ; car un tel système serait immédiatement portable sur de nombreuses machines et accessible de surcroît à tous les utilisateurs d’Unix.

  • 17 GCC (GNU Compiler Collection), dont l’écriture fut entreprise en 1985 par Richard Stallman et publi (...)
  • 18 Ce logiciel est distribué à l’époque de deux façons, directement et gratuitement par l’intermédiair (...)

30Le premier programme du projet GNU, écrit par Stallman, fut un compilateur traitant plusieurs langages pour plusieurs plateformes, le compilateur GCC17 ; suivi dès 1985 par l’éditeur de code Emacs, un outil de base pour tout programmeur18. Le nombre de participants au projet GNU augmentant, une association à but non lucratif, la Free Software Foundation, est fondée en 1985 afin de récolter des fonds pour promouvoir la cause du logiciel libre et organiser les actions des différents participants au projet GNU. La FSF récupère la distribution et la vente des logiciels libres, des manuels et d’autres services associés, et les fonds recueillis payent des programmeurs qui travaillent sur certains logiciels du projet GNU, comme la bibliothèque de langage C, un ensemble de composants logiciels que toute application fonctionnant sur un système d’exploitation Unix libre doit utiliser pour communiquer avec celui-ci, ou l’interpréteur de commandes BASH, développé par Brian Fox, un employé de la FSF.

  • 19 Cette modularité – un simple fait technique – n’est d’ailleurs pas réservée au logiciel libre. Sur (...)
  • 20 Les micro-noyaux représentaient une ligne de recherche importante dans les années 1980-1990. On peu (...)

31Le projet GNU hérite d’Unix un ensemble d’outils (comme le langage C) et de principes techniques comme la conception modulaire des logiciels. Chaque programme est construit comme un ensemble de fichiers indépendants et chacun de ses modules peut être écrit et compilé séparément, ce qui rend possible une construction progressive de l’ensemble19. L’histoire du projet GNU illustre d’ailleurs cette possibilité (technique) de débuter la construction d’un système par n’importe quel élément, sans ordre préétabli, en produisant par exemple en dernier ce qui semble être la base même du système, comme le noyau du système d’exploitation. « Au commencement, raconte Stallman (1999), il s’agissait d’écrire n’importe quel composant, car tous les composants manquaient. L’ordre importait peu alors. Plus tard, une liste de ce qui manquait fut établie, la task-list de GNU ; cette liste permettait de recruter des développeurs pour telle ou telle partie du projet ». Vers 1990, presque tout le système existait, composé entièrement de logiciels libres. Seul le noyau, le cœur du système d’exploitation, manquait encore. Mais la conception technique retenue par Stallman (Le projet Hurd basé sur un principe de micro-noyau20) s’avérant difficile à réaliser, c’est finalement un noyau compact plus classique écrit par Linus Thorvald (Linux), qui est venu compléter et réaliser ce qui était le but même du projet GNU, constituer un système complet de logiciels libres.

32Ce qui sépare les programmeurs travaillant sur le projet GNU ou sur d’autres projets logiciels libres, d’autres programmeurs travaillant à développer des logiciels propriétaires n’est cependant ni les outils, ni les langages utilisés, ni même un comportement particulièrement innovateur, car souvent, il s’agit simplement de libérer (par réécriture) un programme qui existe déjà et dont les principes et l’architecture sont connus. La différence se situe dans les licences accompagnant le code. Le projet GNU avait (et a toujours) deux objectifs : constituer d’un côté un stock de ressources logicielles (système d’exploitation, logiciels d’accompagnement, code source, etc.), que toute la communauté des programmeurs peut librement utiliser et réutiliser ; et établir d’un autre côté les règles de partage et de mise en commun de ces ressources, définir donc les droits et obligations de chacun, définir les règles qui devraient donner à tous une grande liberté d’usage en matière de modification, transformation et redistribution des programmes, en précisant aussi les relations de la communauté à l’égard des tiers. Ces deux objectifs sont d’ailleurs inséparables dans la définition de ce commun.

  • 21 Tous les logiciels développés pour le projet GNU sont en principe sous licence GNU-GPL (avec clause (...)

33Cela va conduire Stallman et la Free Software Foundation à élaborer une définition du free software (logiciel libre), permettant de dire si un logiciel est « libre » ou « non libre », et compatible ou non avec le projet GNU. Cela va donc conduire à la rédaction d’une licence, la licence GPL ou GNU-GPL (GNU-General Public Licence), qui accompagne tous les programmes développés dans le cadre du projet GNU21 ; ce qui sera principalement l’œuvre de Richard Stallman et de juristes comme Eben Moglen.

4. La base constitutionnelle du commun, les licences de logiciel libre

  • 22 Il faudrait ajouter ici ceux qui interviennent activement dans la production d’un logiciel sans tra (...)

34Le concept de logiciel libre (free software) est en rapport direct avec la licence accompagnant le programme (code source), une licence où l’auteur, titulaire du copyright, accorde des droits d’usage particulièrement étendus à l’utilisateur. Celui-ci peut non seulement exécuter le logiciel pour ses fonctionnalités, mais il peut aussi le copier et le modifier comme il l’entend. Il peut le transférer sur un autre système d’exploitation ou sur un autre type de machine, ou en corriger les défauts (bogues), ou encore l’utiliser comme matériau afin de construire un tout autre programme, en supprimant certaines parties du code, en réécrivant d’autres parties, en ajoutant des extensions, etc. En pratique, cela signifie qu’il faut non seulement pouvoir accéder au code source, mais pouvoir aussi le redistribuer à sa guise, modifié ou non. Sans cette liberté, il n’y a en effet aucune possibilité de partage et de mise en commun, et aucune coopération possible entre programmeurs pour le développement d’un programme22.

35Le logiciel est alors traité comme un simple objet technique, comme une valeur d’usage, comme une ressource disponible pour un travail de programmation. Ce n’est qu’un paquet de code, un ensemble de pièces et d’éléments réutilisables pour un nouveau développement logiciel (éventuellement concurrent du programme d’origine). Le logiciel est donc traité du point de vue de l’utilisateur (programmeur), et non du point de vue de l’auteur d’origine, propriétaire ou « ayant-droit ». Il est traité du point de vue d’une catégorie d’utilisateur qui, pour une raison ou pour une autre, ne peut se satisfaire de la simple exécution du programme tel qu’il est (ce qui peut suffire à un utilisateur ordinaire), mais veut pouvoir le modifier ou produire un autre programme à partir du même code. Les licences de logiciel libre sont justement faites pour cela. On voit l’écart avec les licences commerciales habituelles du logiciel propriétaire.

36C’est au milieu des années 1980 que le concept de logiciel libre (free software) est introduit par Richard Stallman et la Free Software Foundation. Il existe donc aujourd’hui une définition officielle du logiciel libre fournie par la Free Software Foundation, une définition disponible sur le site web de la FSF, un site volontairement éducatif, où les distinctions introduites : logiciel privé, logiciel libre, logiciel copylefté, logiciel non copylefté, lcompatible avec la GNU-GPL, propriétaire, semi-propriétaire, etc., sont en liaison directe avec l’objectif de création et maintien dans la durée d’un pool de ressources logicielles partagées dans une communauté, le projet GNU. Ces définitions et ces classements étant directement fonction des termes de la licence et des droits (ou libertés) accordés par celle-ci aux utilisateurs.

37Un logiciel est considéré comme libre si la licence accorde à l’utilisateur les quatre libertés suivantes : (1) La liberté d’exécuter le programme, pour tous les usages et sans restriction particulière. (2) La liberté d’étudier le fonctionnement du programme et de l’adapter à ses propres besoins, ce qui signifie pouvoir corriger des erreurs, supprimer certaines parties du code, ajouter des extensions, et fusionner son propre code (ou le code d’une tierce partie) dans les modules existants. (3) La liberté de copier le logiciel et d’en redistribuer ses copies. (4) La liberté d’améliorer ou transformer le programme et de publier les transformations, « pour en faire profiter toute la communauté ».

38La redistribution du logiciel, modifié ou non (point 3 et 4), inclut le code source et les formes binaires, exécutables, du programme (y compris les images et la documentation) ; et cette redistribution peut être faite gratuitement ou moyennant paiement, au choix de l’utilisateur. « Vous êtes libre de redistribuer des copies, avec ou sans modification, gratuitement ou non, à tout le monde, partout ». Car « l’expression free software fait référence à la liberté et non au prix ». Le software est donc free au sens du « free speech » et non au sens de « free beer » ; et il est bien précisé qu’une licence qui interdirait ou limiterait la vente des copies ne pourrait être considérée comme une licence de logiciel libre.

Tableau 1. Les droits (ou libertés) du logiciel libre

Droits sur le code-source inscrits dans les licences de logiciels libres

Exécuter le programme

Copier et distribuer (en l’état)

Modifier, pour son propre usage

Modifier, combiner avec un autre code, et redistribuer

Clause copyleft

Usages, domaines d’utilisation

usage final
(tel que)

partage et circulation sans modification

correction de bogues, nouvelles fonctionnalités

développement logiciel

développement logiciel

Forme du logiciel

code compilé (binaire)

code source et binaires

code source

codes sources d’origines différentes

logiciel (code source +...)

Utilisateur final

oui

oui

sans objet

sans objet

sans objet

Utilisateur-programmeur

oui

oui

oui

oui

oui

  • 23 Le terme free était aussi jugé trop ambigu, puisque free peut signifier aussi bien libre que gratui (...)

39L’expression « open source software » (ou logiciel open source) est d’apparition plus récente, introduite par Eric Raymond, Bruce Perens, et quelques autres, avec l’Open Source Initiative en 1998, dans le cadre d’une critique du discours de Richard Stallman et de la FSF, un discours jugé par eux trop éthique et trop idéologique. Comme le rappelle Bruce Perens (1999, p. 186), pour « faire la campagne du logiciel libre auprès de ceux qui portent des cravates, [...] les hommes d’affaires, conservateurs, effrayés par le mouvement de liberté initié par Stallman », un discours en termes plus pragmatiques (« qualité des logiciels », « efficacité du mode de développement », etc.) plutôt qu’en termes éthiques (« liberté », « entraide ») fut élaboré, et une stratégie de labellisation mise sur pied afin d’imposer les critères du libre aux licences des entreprises séduites par l’expérience de développement de Linux. Le terme « open source » (le label) devait ainsi remplacer le terme free23.

  • 24 Il s’agit en l’occurrence de la licence NASA Open Source Agreement 1.3, qui impose une « création o (...)

40Une définition de « l’open source » (Open source definition) fut rédigée par Bruce Perens, à partir du contrat social Debian approuvé un peu avant (1997) par les développeurs de ce projet de distribution de logiciels libres autour du système d’exploitation Linux. Cette définition sert encore de référence au processus d’attribution du label « OSI-Approved Open Source », et plus généralement à tous ceux qui utilisent le terme open source software. Elle se présente comme une liste de dix critères, et non comme un ensemble de libertés (ou droits) comme dans la définition du logiciel libre. En pratique, les deux définitions donnent quasiment les mêmes résultats, on y retrouve fondamentalement les mêmes garanties, par exemple : « la licence ne doit pas restreindre... ». Ainsi, en juillet 2009, il y avait 66 licences labellisées sur le site de l’Open Source Initiative, dont deux seulement étaient rejetées par la Free Software Foundation comme trop restrictives dans les droits accordés pour être pleinement considérées comme des licences de logiciels libres24.

41Pour permettre la formation du commun, de ce pool de ressources mis à la disposition de tous les programmeurs, et assurer sa pérennité, les promoteurs du projet GNU ont inventé une clause dite « copyleft ». Attribuer en effet des droits étendus de copie, de transformation et de redistribution du code, ou mettre le logiciel dans le domaine public, ne garantit pas que ce code va rester dans le commun. La transformation d’un logiciel du domaine public ou d’un logiciel libre (non copylefté) en un logiciel propriétaire est toujours possible ; car la loi du copyright n’impose aucune obligation de publication en matière de code source et protège à l’inverse les copies binaires ; et dans une stratégie propriétaire, le code n’est et ne sera jamais publié. On peut donc tout à fait légalement utiliser du code du domaine public pour réaliser un programme distribué uniquement en versions binaires sous licence propriétaire, le code source (ancien et nouveau) restant caché. Pour éviter cette mésaventure aux logiciels libres, il fallait donc inclure dans les licences une clause spécifique interdisant cette pratique, en imposant une redistribution du logiciel, modifié ou non, dans les mêmes conditions que la licence d’origine. C’est le principe du copyleft, une des caractéristiques d’ailleurs de la licence GNU-GPL.

42Dans la philosophie du logiciel libre de Richard Stallman et de la Free Software Foundation, les libertés sont données aux utilisateurs (à tous les utilisateurs) et non au développeur. Comme le logiciel est libre, il peut le modifier et en redistribuer une nouvelle version, mais, avec le copyleft, il doit transmettre les mêmes libertés (ou droits d’usage) aux autres utilisateurs, sans pouvoir ajouter ici de conditions restrictives, et sa propre licence doit donc comporter une clause copyleft. La privatisation d’un code partagé dans une communauté de programmeurs par introduction d’extensions ou modifications des interfaces, sans communication du nouveau code source, devient alors juridiquement impossible. GNU n’est pas Unix, et ne veut pas l’être. Le projet de développement du commun ne doit pas connaître le même destin que celui que connut la communauté Unix, avec l’éclatement et l’apparition de versions différentes d’un même système d’exploitation, toutes propriétaires, avec pour les utilisateurs de multiples problèmes d’incompatibilités.

43En s’appuyant sur le principe propriétaire de la loi du copyright – le droit exclusif de l’auteur à contrôler les utilisations de son code – la clause copyleft en détourne l’exercice habituel. Elle crée une forme de domaine public sécurisé, intégrant un principe d’extension continue de ce domaine, puisque tous les ajouts, toutes les modifications du code source sous copyleft entrent directement dans le commun, sans pouvoir en sortir. Il s’agit en effet, comme l’explique très bien Mélanie Clément-Fontaine (1999), de « créer progressivement un fonds commun de logiciels libres dans lequel tout le monde pourrait puiser, auquel chacun pourrait ajouter, mais duquel personne ne pourrait retrancher ». Ce dispositif juridique élémentaire sécurise à l’avance la production et la transformation des logiciels libres en installant dans la durée le principe de partage du code, et le rejet par les auteurs-programmeurs de leur droit à l’exclusivité inscrit dans la loi du copyright. Il fournit alors un cadre institutionnel égalitaire et pérenne, où l’auteur d’origine et les développeurs ultérieurs n’ont pas plus de droits que les autres utilisateurs, un cadre favorable au développement prolongé des logiciels libres et à la mise sur pied de formes de production coopérative.

  • 25 C’est « un logiciel développé par un utilisateur (individu, organisation ou entreprise) qui le gard (...)

44On peut noter qu’une licence de logiciel libre, qu’elle soit copyleftée ou non, donne à l’utilisateur le droit de modifier le code et le programme, mais n’impose aucune publication des modifications. La clause copyleft ne joue que si le logiciel est redistribué. Dans le cas d’une utilisation purement privée (logiciel privé25), les modifications peuvent rester confidentielles ou « secrètes », un cas d’ailleurs extrêmement fréquent, celui, typiquement, du programmeur qui développe un nouveau logiciel ou écrit du code pour ses propres besoins, ou pour son entreprise ou son organisation. Une clause qui imposerait la publication ou la communication de toute modification serait même une atteinte aux droits de l’utilisateur-programmeur, limitant fortement en pratique la réutilisation du code source. On ne pourrait plus parler alors d’un logiciel libre.

5. Limites et cartographie du commun

45Presque trente ans après la naissance historique des logiciels libres, on peut dresser une ébauche de cartographie de ces ressources logicielles mises en commun à partir des licences, à partir donc des règles portant sur l’usage du code. Notons tout d’abord que le nombre de licences possibles en matière de logiciel est a priori infini, ou du moins très grand. Tout propriétaire d’un copyright peut rédiger sa propre licence, avec ses propres clauses, en définissant à sa manière, comme il l’entend, les usages possibles du logiciel qu’il distribue. Il n’existe pas en effet de statut ou de contrat type imposé par les législations. Il n’y a que le principe – imposé à tous – selon lequel les logiciels (code source et binaires) relèvent du copyright (ou du droit d’auteur) et doivent donc être accompagnés d’une licence. Le nombre de licences propriétaires possibles est donc très grand ; chaque firme ayant sa propre licence, voire des licences différentes, spécifiques à chaque logiciel, ou même plusieurs licences pour le même logiciel, suivant les situations. La segmentation des marchés et la discrimination des clients sont en effet de règle dans les modèles économiques construits sur des stratégies propriétaires. Mais la variété potentielle est aussi une réalité du logiciel libre, et la GNU-GPL n’est pas la seule licence de logiciel libre, il en existe bien d’autres, et tout programmeur peut d’ailleurs rédiger sa propre licence de logiciel libre.

  • 26 Il existe d’autres licences intégrant le principe du copyleft. En France, le CEA, le CNRS et l’INRI (...)
  • 27 Cette licence GNU-LGPL interdit cependant la fusion du code libre dans du code propriétaire. Elle e (...)
  • 28 Les bibliothèques logicielles sont des collections de composants logiciels qui sont utilisés par d’ (...)

46Il y a deux distinctions fondamentales pour cartographier ce commun : (1) La distinction entre logiciel libre (free software ou open source software) et logiciel non libre (propriétaire, semi-propriétaire, etc.), qui établit la frontière entre le commun et le reste ; (2) La distinction, interne au commun des logiciels libres, entre les logiciels copyleftés et les logiciels non copyleftés. La clause copyleft caractérise en effet la licence GPL du projet GNU et quelques autres licences (comme la licence CeCILL en France par exemple) et les distingue de la plupart des autres licences de logiciels libres26. Elle rend irrévocable la décision de partage du code source et maintient le développement et la transformation éventuelle du programme dans l’univers du commun. Mais d’autres licences sont plus permissives en autorisant une redistribution du code accompagnée d’un changement de licence restreignant les droits des utilisateurs. Le nouveau programme peut alors passer de la catégorie des logiciels libres à celle des logiciels non libres. C’est le cas par exemple pour les licences X11 (ou MIT License), pour les licences BSD (ou BSD like), pour la licence FreeBSD, pour les licences Apache, et beaucoup d’autres. Il existe même une licence de ce type dans le projet GNU, la licence GNU-LGPL, au copyleft allégé27. À l’origine, quand cette licence est apparue en juin 1991, l’acronyme LGPL signifiait Library General Public Licence ; le but étant alors pour la Free Software Foundation de faciliter la pénétration de certains logiciels libres dans l’univers des logiciels propriétaires, en permettant de lier un programme sous licence propriétaire, ou sous licence incompatible avec la clause copyleft, avec des bibliothèques développées comme logiciels libres28. Aujourd’hui, ce nom a changé. Certaines bibliothèques peuvent très bien être sous licence GPL, et pour la FSF, c’est de toute manière préférable.

47Le schéma ci-dessous présente alors la cartographie du commun :

Schéma 2. Le commun des logiciels libres (copyleftés ou non copyleftés)

Schéma 2. Le commun des logiciels libres (copyleftés ou non copyleftés)

48Entre le logiciel « libre » et le logiciel « open source », il n’y a, comme nous l’avons déjà vu, que des différences minimes, et la majorité des programmes relevant du commun appartiennent aux deux catégories. La clause copyleft constitue par contre un clivage important, en fixant à l’avance la manière dont le code doit être redistribué, quand il y a redistribution évidemment, car pour une utilisation purement privée, cette distinction n’a guère d’importance. La clause inverse détermine en effet le sens des migrations des paquets de code d’un système de règles à l’autre. Ici, nous avons en gros trois systèmes de règles en présence : le système propriétaire, l’utilisation habituelle des « droits de propriété intellectuelle » sur le mode de l’exclusivité, le système du logiciel libre sans copyleft, et le système du logiciel libre avec copyleft. Un paquet de code tiré du commun peut servir, si la licence n’est qu’une simple licence de logiciel libre sans copyleft, à construire un logiciel propriétaire, dont le code transformé échappe alors au commun. Il peut aussi servir à construire un logiciel libre avec clause copyleft. Mais du code copylefté ne peut être utilisé légitimement et légalement ni pour produire un logiciel propriétaire, ni même pour produire un simple logiciel libre (sans clause copyleft). La clause règle donc à l’avance le destin du code au de son développement, et plus généralement à chaque opérations de distribution et redistribution du logiciel.

49Pour préciser les choses au moyen d’exemples, prenons comme seules licences, une licence propriétaire, la GNU-GPL, avec copyleft et deux licences de logiciel libre, la licence BSD sans copyleft et la licence GNU-LGPL avec son copyleft allégé.

  • 29 Comme le code de Navigator, le navigateur de Netscape en 1998, ce qui devait conduire à la formatio (...)

50On peut avoir les mouvements suivants :
BSD ➡ licence propriétaire,
BSD ➡ BSD et LGPL ➡ LGPL,
BSD ➡ LGPL,
BSD ➡ GPL et LGPL ➡ GPL,
GPL ➡ GPL ;
et aussi :
licence propriétaire ➡ BSD (ou LGPL, ou GPL), par dévoilement du code et changement de licence, c’est ce qu’on appelle dans les communautés du logiciel libre une « libération de code »29, mais on ne peut avoir :
GPL ➡ BSD,
GPL ➡ LGPL,
ni même LGPL ➡ BSD,
et encore moins GPL ➡ licence propriétaire.

Schéma 3. Le sens des migrations du code, d’un système de licence à l’autre

Schéma 3. Le sens des migrations du code, d’un système de licence à l’autre

51Les migrations d’un système de règles à l’autre sont donc ordonnées, avec deux grandes directions possibles (voir schéma) : (1) celle conduisant à la privatisation, qui ne peut puiser ses ressources que dans une partie du commun ; (2) et le mouvement inverse qui aboutit au commun sécurisé par cette clause copyleft.

52Le copyleft est ainsi devenu une institution fondamentale du commun des logiciels libres qui en assure la pérennité et le renforcement progressif, en contraignant à l’avance les changements possibles du système des règles juridiques accompagnant le code. Cette clause a inversé la représentation traditionnelle, en partie fausse d’ailleurs, du « domaine public », conçu comme une simple communauté négative, comme un espace de « non propriété », selon l’expression de Landes et Posner (2002), qu’on peut piller sans scrupule pour des stratégies toutes entières construites sur un principe d’exclusivité (et d’exclusion). Avec cette clause, le commun devient une communauté positive, excluant les stratégies propriétaires et rendant obligatoire le partage, ce qui est parfaitement adapté à la mise sur pied de projets de développement et d’invention collective ayant pour objet les logiciels.

53Développer un logiciel en utilisant du code source provenant de différents logiciels libres pose en effet deux problèmes de coordination, un problème technique et un problème juridique. Au niveau de la programmation et du développement lui-même, il faut rendre compatibles et intégrer dans un même ensemble les différents paquets de code source. Dans le cadre juridique des logiciels libres et pour toute utilisation privée, il n’y a en principe aucun obstacle à ce type de travail. Mais en cas de redistribution du nouveau code, y compris pour le partage dans une communauté de programmeurs travaillant à un projet commun, il faut aussi que les licences d’origine soient juridiquement compatibles entre elles, c’est-à-dire permettent de définir un ensemble de règles communes applicables à la combinaison (en pratique, soit une nouvelle licence, soit une ou plusieurs des licences d’origine). C’est un problème purement juridique de coordination, totalement différent du problème précédent qui n’est qu’un problème de coordination technique. Des clauses spécifiques d’une licence peuvent alors faire obstacle à une combinaison de différents codes sources30. Pour sensibiliser les programmeurs à ce problème et aider les développeurs de logiciels libres, la Free Software Foundation distingue alors dans les différentes licences de logiciels libres, les licences compatibles avec la GNU-GPL et les licences incompatibles. Quand les licences sont juridiquement compatibles, les deux codes peuvent être combinés avec du code sous licence GNU-GPL et l’ensemble mis sous licence GNU-GPL. On peut par exemple combiner du code appartenant au domaine public, du code sous licence ISC (OpenBSD) et du code sous licence GNU-GPL en mettant le tout sous la même licence GNU-GPL, car les différentes règles sont compatibles avec la GNU-GPL. Mais on ne peut pas ajouter à cette combinaison du code sous licence Mozilla Public License 1.1, pour cause d’incompatibilité juridique, même si l’ensemble peut parfaitement bien fonctionner sur le plan technique (la version 2 de la MPL est par contre compatible avec la GNU-GPL version 2 ou 3). Sur le site de la FSF, on trouve ainsi une liste (non exhaustive) de licences, et sur les 110 licences examinées (en mai 2012), 82 étaient des licences de logiciels libres, 43 licences étant compatibles avec la GNU-GPL et 39 incompatibles31.

54On peut terminer cette cartographie du commun par une mesure statistique de l’importance relative des différentes licences de logiciels libres, une importance mesurée en termes de popularité et d’adoption par les programmeurs. Le fait le plus frappant est la place centrale occupée par la GNU-GPL de la Free Software Foundation dans l’ensemble du commun des logiciels libres. L’examen des projets logiciels répertoriés sur le site Sourceforge est révélateur. Ce site répertorie un très grand nombre de projets logiciels free ou open source (plus de 160 000 au moment de notre décompte réalisé en juillet 2009). Il maintient donc en ligne la description du projet, un lien avec l’équipe de développeurs (adresses électroniques, etc.), et un accès direct au code source en cours de développement, avec parfois la possibilité de télécharger directement, quand le code produit est suffisamment stable, des versions binaires déjà compilées pour les principaux systèmes d’exploitation. En règle générale, la ou les licences sont précisées, avec la plupart du temps une seule licence par projet, mais certains logiciels peuvent combiner plusieurs licences (jusqu’à cinq). On a donc relevé ces différentes licences pour établir deux tableaux, l’un calculé sur l’ensemble des projets présents dans Sourceforge, quel que soit leur vie effective et leur popularité, l’autre sur les « 300 logiciels les plus populaires », autrement dit les plus téléchargés (code source ou binaires).

Tableau 2. Ensemble des projets présents sur Sourceforge (Juillet 2009)

Nombre

en %

GNU General Public License (GPL)

101425

62,44

GNU Library or Lesser General Public License (LGPL)

17440

10,74

Licences style BSD

11257

6,93

Licences Apache

6352

3,91

Licences style X11 (ou MIT license)

4263

2,62

Academic Free License (AFL)

2812

1,73

Licences Artistic

2030

1,25

Mozilla Public licence

2385

1,47

Common Public License 1.0

1394

0,86

Open Software License 3.0 (OSL3.0)

1261

0,78

Domaine Public

5896

3,63

Autres licences (moins de 1000 projets)

5913

3,64

TOTAL (NP exclues)

162428

100

Licences non précisées (NP), exclues du total

1889

Tableau 3. Les 300 logiciels les plus téléchargés « all time »

Nombre

en %

GNU General Public License (GPL)

203

63,24

GNU Library or Lesser General Public License (LGPL)

44

13,71

BSD License

12

3,74

Mozilla Public License

12

3,74

zlib/libpng license

11

3,43

Autres (< 10 références)

39

12,15

Total

321

100

55Dans le décompte initial, il y a 68 licences différentes, plus les catégories « Public domain », « autres OSI-Approved Open Source », et « autres » (la licence n’étant pas précisée). Mais un certain nombre de licences sont manifestement très peu utilisées. Ainsi les 15 licences les plus utilisées (sur 68) représentent 95 % du nombre total des logiciels. Dans ces 15, celle qui pèse le moins est la MPL 1.0, une des premières versions de la licence MPL du projet Mozilla.org, avec 865 références. À l’opposé, la GNU-GPL est en quelque sorte plébiscitée dans toutes ses versions, avec 62 % des projets logiciels, et avec sa variante lesser au copyleft allégé, c’est 72 % des projets qui sont rattachés juridiquement aux règles définies par la Free Software Foundation, qui n’est pourtant qu’une simple fondation privée. Le deuxième tableau sur les 300 logiciels « les plus populaires », confirme le premier, avec 74 % pour les licences GNU (63 % pour la GNU-GPL).

56Juridiquement, le monde du logiciel libre est remarquablement unifié, avec en gros trois situations (et choix) possibles pour le code source d’un logiciel libre : la situation du domaine public où le logiciel « appartient directement au public » et où aucun copyright n’existe, puis les licences style BSD ou des licences équivalentes dénuées de tout copyleft, et enfin les licences de la FSF, avec leurs clauses copyleft, et ici la GNU-GPL domine très largement. Cette unification est remarquable, car elle existe au niveau mondial et s’est formée en quelque sorte spontanément, sans l’appui d’aucun gouvernement, à l’encontre même du discours dominant des économistes et des hommes politiques sur les bienfaits ou le caractère favorable pour l’innovation de la « propriété intellectuelle », c’est-à-dire du droit exclusif des auteurs (et des firmes) à contrôler toutes les utilisations de leurs œuvres (code source et binaires). Au moment où dans des négociations internationales autour de l’Organisation mondiale de la Propriété intellectuelle ou de l’OMC (accords ADPIC), on peinait à essayer d’unifier les principes, les règles et les législations, les développeurs de l’open source, en adoptant massivement les mêmes licences et les mêmes principes, ont créé une sorte de statut juridique mondial du logiciel libre.

  • 32 Dans les communautés du logiciel libre, certains refusent la clause copyleft, qui leur semble philo (...)

57On peut se demander pourquoi un tel résultat ? Quelles sont les causes de cette unification ? Et pourquoi cette cristallisation autour de la licence GNU-GPL, et non autour d’une autre licence (BSD par exemple32), ou de plusieurs licences différentes ? Et pourquoi les tendances centrifuges qui opèrent en permanence, avec régulièrement l’apparition de nouvelles licences, ne l’emportent-elles pas ?

  • 33 Le code du système d’exploitation Linux au début de son développement (octobre 1991) était sous une (...)
  • 34 Depuis l’affaire Educaffix contre CNRS, Université Joseph Fourrier et autres (TGI Paris 28 mars 200 (...)

58Une explication possible du succès de la GNU-GPL est sans doute son lien avec le projet GNU de la Free Software Foundation de construction d’un système complet (de plus en plus étoffé) de logiciels libres autour d’un (ou plusieurs) systèmes d’exploitation Unix, tous ces logiciels étant sous licence GNU-GPL. Le statut de cette licence serait alors largement le résultat du travail accompli dans la construction du commun. Une autre explication est le caractère « général » et volontairement universel de cette General Public License, et du discours « philosophique » qui l’accompagne. Le principe du copyleft suscite en lui-même une forte adhésion. Il assure que toutes les modifications apportées au code seront, sauf usage purement privé, redonnées à la communauté avec pour tous les mêmes droits d’usage que sur le code d’origine. Il met formellement tous les utilisateurs sur le même plan en leur donnant les mêmes droits, ce qui a favorisé l’émergence de projets de développement logiciel de très grande ampleur, et mobilisé de très nombreux développeurs répartis un peu partout dans le monde, comme le projet Linux33. Et cette licence est effectivement « générale » d’un point de vue purement juridique. Elle n’est pas liée à un programme ou projet logiciel particulier. Il n’y a pas non plus de clause renvoyant à une législation particulière, ni de « clause publicitaire » (comme dans certaines versions de la licence BSD), et ainsi de suite. Bien que conçue dans le contexte juridique du copyright américain, elle peut être adoptée telle quelle par les programmeurs de tous les pays34.

59Comme nous l’avons vu, ma clause copyleft est contaminante, puisque tout nouveau logiciel utilisant du code source sous GNU-GPL doit être mis sous licence GNU-GPL (ou sous une licence équivalente accordant les mêmes droits), ce qui décourage de choisir une autre licence et renforce la tendance à l’unification. Les règles de compatibilité entre licences poussent dans la même direction. Le jeu des rendements croissants d’adoption contribue donc à faire de cette licence la référence en matière juridique des communautés open source. C’est donc devenu une forme de standard qui donne au commun des logiciels libres une grande unité en matière juridique.

6. Conclusion

60Le principe de base du logiciel libre est l’annulation du droit exclusif attribué par la loi (droit d’auteur ou copyright) à l’auteur du code. Celui-ci y renonce totalement, n’étant plus qu’un utilisateur parmi d’autres, bénéficiant comme les autres de la totalité des droits d’usage. Cette innovation institutionnelle a alors effectivement donné naissance à un commun, rendu pérenne par une clause spécifique présente dans certaines licences, la clause copyleft. L’adoption croissante de ces règles à l’échelle mondiale a permis la production de nombreux logiciels libres, avec apparition de formes communautaires de production. Ces règles ont aussi permis l’intégration des logiciels libres dans les activités des firmes les plus capitalistes (dont certaines d’ailleurs aujourd’hui produisent du logiciel libre). Le commun, comme stock de ressources partagées, est alors devenu de plus en plus important, et même incontournable.

  • 35 L’économie de l’information, contrairement à ce que certains économistes affirment, citant Kenneth (...)
  • 36 On peut donner comme exemples deux accords de licences croisées qui abolissaient localement les pat (...)

61Derrière cette croissance, il y avait d’ailleurs un impératif technique (et économique), avec la nécessité de surmonter la paralysie et les dysfonctionnements nés de l’utopie propriétaire, c’est-à-dire de l’imposition mondiale d’un principe propriétaire (ou exclusif) à partir des années 1980, ce qui bloquait l’innovation et l’invention collective, et affectait négativement toute l’économie des logiciels. Il fallait donc supprimer les obstacles juridiques à la libre circulation et réutilisation du code entre programmeurs (et entreprises), en créant un commun avec des règles sécurisant celui-ci. On peut alors revenir sur la définition proposée dans l’introduction, le commun comme ensemble de ressources plus ou moins pérennes, dont l’accès et l’usage sont partagés dans une population plus ou moins étendue, cette définition étant applicable au logiciel libre comme à bien d’autres communs dans des domaines très divers. En effet, nos sociétés marchandes et capitalistes qui reposent, selon la croyance et les affirmations de la majorité des économistes et des juristes, exclusivement sur la propriété privée, reposent aussi sur de nombreux ensembles de ressources qui sont, qu’on en ait pleinement conscience ou non, des communs ; et ces communs sont indispensables à un grand nombre d’activités privées et au bon fonctionnement de l’ensemble de l’économie marchande. Ainsi les routes, les trottoirs des villes, les parcs et autres espaces ouverts au public, les bibliothèques publiques, les musées sont des formes de communs. On peut aussi évoquer la langue (la langue française par exemple), ou les idées et les informations, qui circulent librement, par impossibilité d’empêcher réellement leur diffusion et leur partage, mais aussi et surtout en vertu des règles constitutionnelles des sociétés démocratiques (la liberté de pensée et d’information par exemple)35. Le domaine public des œuvres littéraires est aussi une forme de commun. Il en est de même pour certains pools de brevets, quand leur seule finalité est de mettre en commun et de partager un certain nombre de techniques brevetées, en annulant les droits du titulaire du brevet36.

62Trois éléments interviennent alors dans la constitution des communs : (1) une ou des ressources, (2) un groupe ou une population, (3) des règles sociales (et parfois juridiques) qui permettent, organisent, et régulent l’utilisation de ces ressources par les membres de cette population, une utilisation partagée, de manière collective ou individuelle, simultanée ou successive, et qui peut aller – ce qui est le cas pour les logiciels libres – jusqu’à donner naissance à des formes de production communautaire de ces ressources. Précisons les trois points de cette définition générale.

  • 37 Contrairement à ce que postule l’analyse économique standard des droits de propriété intellectuelle (...)

63(1) Les ressources peuvent être de toute nature, matérielle ou immatérielle, tangible ou intangible, et cette nature va intervenir dans les formes concrètes prises par le commun, dans la manière dont les ressources sont produites ou circulent, et dans la manière dont s’organise le partage. Mais ce n’est pas cette nature qui détermine en elle-même l’existence du commun. Les communs ne sont donc pas des res communes ou définis par l’impossibilité ou une difficulté extrême à établir ici l’appropriation individuelle, une difficulté qui découlerait directement de certaines caractéristiques des ressources considérées37. C’est particulièrement évident en matière de logiciel, puisqu’on a des logiciels libres et des logiciels dits « propriétaires », alors qu’il s’agit fondamentalement des mêmes objets techniques, remplissant les mêmes fonctions, et fonctionnant souvent de la même façon. La forme numérique des fichiers permet la démultiplication et la diffusion à grande échelle sous forme de gratuiciels, mais là encore on trouve aussi bien des logiciels libres que des logiciels propriétaires à code fermé.

64(2) On peut compter dans les membres de la population, du groupe nécessaire au commun, aussi bien des êtres humains que des entreprises (personnes physiques et morales donc). Ici la chose la plus importante est sans doute la taille du groupe, une taille en grande partie fixée par les règles d’accès aux ressources (point 3 de cette définition). Il y a des communs dont les membres peuvent être peu nombreux, et qui restent fermés aux autres (cas fréquent pour les pools de brevets), d’autres à l’inverse sont largement ouverts et certains ouverts à tous. Dans le cas qui nous intéresse, le commun des logiciels libres, la communauté est par principe l’ensemble des utilisateurs des logiciels, sans distinction particulière. Évidemment, les compétences des uns et des autres peuvent limiter leur utilisation de la ressource. En pratique, un utilisateur programmeur peut utiliser le code pour faire un autre programme, un utilisateur maîtrisant une langue étrangère peut traduire les interfaces et changer lui aussi le programme, alors qu’un utilisateur ordinaire ne peut qu’utiliser le programme tel qu’il est. Mais formellement tous les utilisateurs ont les mêmes droits d’accès et d’usage. Le commun des logiciels libres est à vocation universelle.

65(3) Mais l’élément le plus important de cette définition du commun est la base institutionnelle, constitutionnelle, du commun, c’est-à-dire l’ensemble des règles qui relient les membres de la population considérée aux ressources. Ces règles font que les ressources n’appartiennent plus au domaine de jouissance exclusive de certains individus, mais sont posées comme communes ou partagées en matière d’usage. Qu’il s’agisse de simples règles de fait, plus ou moins coutumières, ou de règles formellement établies, codifiées éventuellement sous forme juridique, elles définissent l’accès de chaque membre du groupe aux ressources et les utilisations possibles (ou proscrites) de celles-ci. Elles fixent donc le comportement de chacun vis-à-vis de ces ressources, et ont aussi comme conséquence de définir les relations que les membres de la population concernée peuvent et doivent entretenir entre eux dans le cadre du commun, quand ils utilisent les ressources, contribuant à transformer un groupe de fait en une communauté ayant conscience d’elle-même. Ces règles ont souvent comme fonction d’assurer la pérennité ou le renouvellement de l’ensemble des ressources, et donc du commun. Elles peuvent limiter ou interdire même une éventuelle appropriation privée de celles-ci, ou autoriser cette appropriation, dans la mesure où cela ne remet pas en cause l’existence du commun. On doit donc effectivement parler de règles constitutionnelles. Dans le cas des logiciels libres, ces règles constitutionnelles sont les différents systèmes de licence (GNU-GPL, BSD, MIT, Apache, MPL, etc.). Sans cette base constitutionnelle, il n’y aurait pas eu de commun, et sans ce commun (ainsi rendu possible et sécurisé), il n’y aurait pas eu de communautés de développement logiciel, ou du moins pas de communautés aussi productives et pérennes que celles que nous connaissons.

66Savoir si ces éléments sont complémentaires ou se distinguent des définitions et caractérisations des communs, traditionnellement inspirées par les approches d’Ostrom et de l’école d’Indiana, est une question ouverte que nous ne trancherons pas ici. Notre propos était seulement de mettre l’accent sur une autre origine du commun, celle que représente l’histoire du logiciel libre, ceci pour alimenter le débat et la discussion.

Top of page

Bibliography

Abate Janet (1999), Inventing the internet, Cambridge, The MIT Press.

Aigrain Philippe et Valérie Peugeot (2005), « Les licences “Creative Commons” : origine, développement, limites et opportunités », juillet, http://vecam.org/IMG/pdf/etude_Sopinspace_Creative_CommonsV1.pdf

Akera Atsushi (2001), “Volontarism and the fruits of collaboration: The IBM’ user group, Share”, Technology and Culture, 42(9), october, p. 710-736.

Arrow Kenneth (1962), “Economic Welfare and the Allocation of Resources for Innovation”, in The Rate and Direction of Inventive Activity, Nelson (ed.), Universities-National Bureau, p. 609-626.

Behlendorf B., Bradner S., Hamerly J., McKusick K., O’Reilly T., Paquin T., Perens B., Raymond E., Stallman R., Tiermann M., Torvalds L., Vixie P., Wall L., Young B. (1999), Tribune libre, Ténors de l’informatique libre, Paris, éditions O’Reilly.

Bloch Marc (1931), les caractères originaux de l’histoire rurale française, Paris, édition Armand Colin, (1960 tome I, 1956 tome II).

Breyer Stephen (1970), “The uneasy case for copyright: a study of copyright in books, photocopies, and computer programs”, Harvard Law Review, 84(2), december, p. 281-351.

Campbell-Kelly Martin (2003), Histoire de l’industrie du logiciel, des réservations aériennes à Sonic le hérisson, trad. Pierre Mounier-Kuhn, éditions Vuibert.

Clément-Fontaine Mélanie (1999), « Une étude juridique de la Licence Publique Générale GNU », mémoire de DEA en Droit.

Dréan Gérard (1996), L’industrie informatique. Structure, économie, perspectives, Paris, Masson.

Foray Dominique, Zimmermann Jean-Benoît (2001), « L’économie du logiciel libre. Organisation coopérative et incitation à l’innovation », Revue économique, 52, numéro hors-série, p. 77-93.

Hersey John (1978), “Computers and copyright (ch. 3), Dissent of commissioner Hersey”, Final Report of the National Commission on New Technology Uses of Copyrighted Works (CONTU), http://digital-law-online.info/CONTU/contu14.html

Landes William M., Posner Richard (1989), “An Economic Analysis of Copyright Law”, Journal of Legal Studies, vol. XVIII (2), p. 325-363.

Landes William M., Posner Richard (2002), “Indefinitely Renewable Copyright”, University of Chicago Law & Economics, Olin Working Paper, No. 154, p. 1-41.

Le Roy Etienne, Karsenty Alain, Bertrand Alain (1996), La sécurisation foncière en Afrique, pour une gestion viable des ressources renouvelables, Paris, Karthala.

Levy Steven (2010 [1985]), Hackers: Heroes of the Computer Revolution, O’Reilly Media.

Mangolte Pierre-André (2010), « Les communs du logiciel libre (1re partie) », document de travail ANR-PROPICE, décembre [WP 2010-3].

Mangolte Pierre-André (2012), « Patents Wars (3e partie) : Les pools, du cartel à l’abolition partielle du système des patents », document de travail ANR-PROPICE, mars [WP 2012-9].

Mangolte Pierre-André (2013), « Le logiciel libre, comme commun créateur de richesses », communication au séminaire international « Propriété et communs, les nouveaux enjeux de l’accès et de l’innovation partagée », Paris, 25-26 avril.

Merges Robert P. (2000), “One Hundred Years of Solicitude: Intellectual Property Law 1900-2000”, California Law Review, vol. 88, p. 2187-2240.

Moglen Eben (1999), “Anarchism triumphant: Free software and the death of copyright”, First Monday, Volume 4, Number 8, August.

Narduzzo Alessandro, Rossi Alessandro (2003), “Modularity in Action: GNU/Linux and Free/Open Source Software Development Model Unleased”, Document de travail.

Perens Bruce (1999), « La définition de l’open source », in Tribune libre, Ténors de l’informatique libre, Behlendorf et al., Paris, O’Reilly, p. 183-203.

Salus Peter H. (1994), A Quarter Century of UNIX, Addison-Wesley Publishing Company, Inc.

Schlager Edella, Ostrom Elinor (1992), “Property-rights regimes and natural resources: A conceptual analysis”, Land Economics, vol. 68, n° 3 (Aug.), p. 249-462.

Stallman Richard M. (1999), « Le système d’exploitation du projet GNU et le mouvement du logiciel libre », in Tribune libre, Ténors de l’informatique libre, Behlendorf et al., Paris, O’Reilly, p. 61-82.

Yamagata Hiroo (1997), « Le pragmatiste du logiciel libre : entretien avec Linus Torvalds », trad. S. Blondeel (1999),

http://www.linux-france.org/article/these/interview/torvalds/pragmatist-fr.html

Sites internet :

http://www.gnu.org/philisophy/philosophy.fr.html

http://emoglen.law.columbia.edu

http://www.gnu.org/licenses/license-list.html

http://www.fsf.org (site de la Free Software Foundation)

http://opensource.org (site de l’Open Source Initiative)

Top of page

Notes

1 « It [la licence GPL] creates a commons, to which anyone may add but from which no one may subtract », (Moglen, 1999).

2 Par « économie », nous entendons ce qu’entendait Adam Smith, c’est-à-dire la création, la distribution, la redistribution et l’utilisation des « richesses », de « valeurs d’usage » donc ici les logiciels, et non la gestion de ressources rares ou l’économie monétaire, ces deux approches étant par trop limitées pour notre objet, puisqu’un très grand nombre d’activités de production et d’échange des logiciels se font à l’écart de toute relation marchande, et qu’un très grand nombre de produits sont disponibles gratuitement et copiables à l’infini, ce qui rend vain le concept même de la « rareté ».

3 Le code (ou code-source) est un ensemble d’instructions adressées à une machine (l’ordinateur) mais indépendant de celle-ci. Il est écrit en utilisant un langage de programmation plus ou moins proche du langage naturel et donc directement compréhensible par les programmeurs, étant de surcroît accompagné de commentaires en langage naturel. Ce code est ensuite compilé pour telle ou telle machine (hardware), tel ou tel processeur, ce qui donne un fichier binaire, en langage machine, directement exécutable mais incompréhensible à tout être humain.

4 À l’époque de la mécanographie, ce sont les schémas de câblage entre machines (l’équivalent d’un logiciel) qui sont collectés par les commerciaux d’IBM, pour être publiés ensuite dans une revue, et servir ainsi de modèle et d’inspiration aux autres utilisateurs des machines.

5 Voir aussi l’article d’Atsushi Akera, (2001).

6 Pour développer un logiciel, il faut pouvoir accéder à un ordinateur facilement et de manière permanente, ce qui était réservé jusqu’ici aux informaticiens travaillant dans une grande entreprise, un centre de recherche ou une université. Mais cet obstacle à la création de firmes indépendantes est levé avec l’arrivée des micro-ordinateurs ; et de très petites firmes, des individus isolés même, peuvent désormais développer leurs propres programmes, ce qui explique la rapidité de l’évolution.

7 La logique générale de cette économie du progiciel est en effet monopoliste, avec « la persistance de profitabilités très élevées et la domination quasi-absolue de Microsoft dans des segments comme les systèmes d’exploitation pour micro-ordinateurs (81 % avec MS-DOS), les tableurs (73 % avec Excel), ou à un degré moindre les traitements de texte (55 % avec Word), [Car] le secteur du progiciel est en réalité formé d’un grand nombre de sous-secteurs, dont chacun est concentré. [Même si] dans chaque secteur, l’entreprise leader peut être de taille modeste » (Dréan, 1996, p. 209-210). Le droit de propriété intellectuelle ne fait alors qu’accompagner, renforcer et justifier la structure monopoliste existante.

8 Selon une jurisprudence de la fin du xixe siècle (Baker v. Selden, 1879), un principe explicitement rappelé dans la loi du copyright de 1976. Cf. § 102 (b) « In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work ».

9 Dans cette commission, fait remarquable, il n’y avait aucun représentant de l’industrie informatique, aucun programmeur, aucune personne qui soit professionnellement, de près ou de loin, en rapport avec les softwares. À la même époque, la question était cependant débattue dans les revues et la presse ; Stephen Breyer par exemple, futur juge à la Cour suprême, dans son étude sur le copyright de 1970, proposait ainsi de ne rien faire, amender la loi n’étant pas nécessaire pour le développement de l’industrie.

10 Pour Hersey, le code source a deux caractéristiques : communiquer des instructions à la machine et communiquer avec des êtres humains (les programmeurs qui ont travaillé ou travailleront sur le programme) ; les commentaires qui parsèment le code source ne sont en particulier destinés qu’aux êtres humains. Une fois compilé, comme fichier binaire, le logiciel ne peut servir qu’à la machine. Ce n’est plus un « texte », ou une œuvre, selon la tradition du copyright, mais une partie de la machine, une pièce comparable à un vilebrequin (a cam) donnant des impulsions au reste du moteur. Voir son analyse en ligne : http://digital-law-online.info/CONTU/contu14.html.

11 On peut évoquer ici l’expérience vécue par Richard Stallman. Devant régler pour son laboratoire un problème de dysfonctionnement logiciel d’une imprimante, il se vit opposer la propriété intellectuelle du fournisseur et refuser pour cette raison tout accès au code source. Il ne put donc résoudre le problème (première absurdité), ni améliorer le programme pour tous les autres utilisateurs (deuxième absurdité), pour un programme qui était livré avec la machine et ne pouvait guère être utilisé (et vendu) sans cette machine (troisième absurdité). Aujourd’hui, la règle générale pour les producteurs d’imprimante est de vendre les machines et les consommables (les encres et certains papiers), en fournissant gratuitement les pilotes (et leurs mises à jour logicielles) ; et souvent le pilote est maintenant disponible comme logiciel libre, pour permettre justement sa transformation et son amélioration par les utilisateurs.

12 C’est ce qui devait arriver en particulier à la communauté des programmeurs constituée autour du système d’exploitation à temps partagé ITS (Incompatible Timesharing System), du laboratoire d’intelligence artificielle du MIT, pour lequel Richard Stallman travaillait (cf. Stallman, 1999 ; Levy, 1985).

13 Pour l’histoire d’Unix, voir Salus, 1994, et Behlendorf et al., 1999.

14 En 1978, les droits (fee) étaient déjà de 7000 $ pour une Université, et plus pour une licence « commerciale ». Mais dix ans après (1988), le prix était bien plus élevé, environ 100 000 $ ; et en 1993, il fallait compter 200 000 $ pour obtenir le code source, ce qui éliminait les individus, les petites compagnies et une bonne partie des universités et centres de recherches. (Cf. Salus, 1994).

15 En dehors du développement de l’Arpanet (cf. Abate, 1999), un des problèmes préoccupant la DARPA était le vieillissement des matériels et leur hétérogénéité. Pour assurer un minimum de standardisation et de pérennité des logiciels, et permettre aussi la communication des machines entre elles, la DARPA mise alors sur le système d’exploitation Unix, car celui-ci avait déjà montré sa portabilité sur différentes machines ; l’équipe de Berkeley fut plus spécifiquement retenue à cause des premières distributions BSD.

16 Cette distribution comportait tout ce qui permettait la gestion des réseaux (TCP/IP) et la connexion à l’Arpanet, avec les utilitaires associés ; l’essentiel de ce code ayant été produit en dehors des Bell Labs, à Berkeley ou dans d’autres universités.

17 GCC (GNU Compiler Collection), dont l’écriture fut entreprise en 1985 par Richard Stallman et publié en 1987 pour la première fois, est une collection de logiciels capables de compiler divers langages de programmation (C, C++, Objective-C, Java, Ada, Fortran) pour un grand nombre de systèmes d’exploitation et microprocesseurs. Aujourd’hui, c’est le compilateur de base de Linux, BSD, Mac OSX, NeXTSTEP, BeOS/Haiku.

18 Ce logiciel est distribué à l’époque de deux façons, directement et gratuitement par l’intermédiaire d’un site ftp, et vendu parallèlement (bandes magnétiques) au profit de l’auteur. « Étant sans emploi, je cherchais des moyens de gagner de l’argent grâce au logiciel libre. C’est pourquoi j’ai annoncé que j’enverrais une bande à quiconque en désirait une, en échange d’une contribution de 150 USD. De cette manière, je mettais en place une entreprise autour de la distribution du logiciel libre. » (Stallman, 1999, p. 68). Le même principe de double distribution (payante par envoi postal, avec éventuellement des services associés, etc., et comme freeware par simple téléchargement direct) fut repris par la suite pour les distributions BSD, et représente d’ailleurs toujours un modèle économique possible du monde des logiciels libres.

19 Cette modularité – un simple fait technique – n’est d’ailleurs pas réservée au logiciel libre. Sur ce point, voir Narduzzo et Rossi (2003).

20 Les micro-noyaux représentaient une ligne de recherche importante dans les années 1980-1990. On peut citer aujourd’hui comme réalisation XNU mis au point pour NextStep à partir d’un noyau Mach et intégré aujourd’hui dans Darwin (OS X) et GNU-Hurd dont le développement a été poursuivi avec en 2012 une version opérationnelle qui devrait donner naissance à une distribution Debian.

21 Tous les logiciels développés pour le projet GNU sont en principe sous licence GNU-GPL (avec clause copyleft), à l’exception de certains programmes sous licence GNU-LGPL. Le système d’exploitation Linux, développé séparément, est lui aussi sous licence GNU-GPL. Mais d’autres logiciels libres existants ont été intégrés directement dans le « système GNU », comme Tex (formateur de texte) et le système de fenêtrage X avec leur propre licence. Le système GNU, nous dit Stallman, est donc différent du projet GNU. « Il comprend des programmes qui ont été développés par d’autres, dans le cadre d’autres projets, pour leurs buts propres, mais qu’on peut réutiliser, car ce sont des logiciels libres » (Stallman, 1999, p. 66).

22 Il faudrait ajouter ici ceux qui interviennent activement dans la production d’un logiciel sans travailler sur le code source, qui rédigent par exemple ou traduisent la documentation, ou les fichiers d’aide accompagnant le programme, etc. Le projet de développement KDE (un environnement de bureau pour les systèmes d’exploitation GNU/Linux et BSD) a environ 800 contributeurs, dont 300 pour l’équipe de traduction.

23 Le terme free était aussi jugé trop ambigu, puisque free peut signifier aussi bien libre que gratuit. Mais open est tout aussi ambigu, ayant de plus déjà beaucoup servi dans l’industrie informatique, dans des contextes souvent proches mais différents des logiciels libres, comme dans toutes les initiatives visant à introduire un minimum de standardisation et de partage des interfaces (norme POSIX, par exemple, pour les différents Unix propriétaires). Ce caractère commun des interfaces étant nécessaire pour assurer le fonctionnement conjoint de systèmes par nature hétérogènes, car conçus séparément, avec un double problème ici, la divulgation du code des interfaces et les droits d’usage.

24 Il s’agit en l’occurrence de la licence NASA Open Source Agreement 1.3, qui impose une « création originale » pour l’ajout de code source au code d’origine, interdisant donc l’utilisation d’un code source venu d’un autre logiciel, et de la Reciprocal Public Licence 1.5, qui limite le prix éventuel demandé pour la vente d’une copie et oblige à publier toute modification, même réalisée pour un usage purement privé, avec envoi d’une notification au développeur d’origine.

25 C’est « un logiciel développé par un utilisateur (individu, organisation ou entreprise) qui le garde pour lui et ne publie ni les fichiers sources, ni les fichiers binaires ». C’est donc, dit la FSF, une sorte de logiciel libre « au sens le plus trivial », car l’unique utilisateur a tous les droits dessus. Dans cette situation, il n’y a aucun apport au commun, mais rien n’est retranché à celui-ci. Voir http://www.gnu.org/philosophy/categories.fr.html.

26 Il existe d’autres licences intégrant le principe du copyleft. En France, le CEA, le CNRS et l’INRIA ont ainsi développé leur propre licence de logiciel libre, la licence CeCILL, qui est présentée comme « une licence libre de droit français compatible avec la licence GNU-GPL ». Elle est reconnue comme telle par la FSF qui en critique cependant le « texte », car « il utilise des mots biaisés qui doivent être évités, comme “propriété intellectuelle” et “protection” […] Cependant, cela ne pose pas de problème particulier pour les programmes utilisant la licence CeCILL ».

27 Cette licence GNU-LGPL interdit cependant la fusion du code libre dans du code propriétaire. Elle est donc moins permissive que les licences BSD, MIT, ou Apache. Son copyleft est simplement allégé.

28 Les bibliothèques logicielles sont des collections de composants logiciels qui sont utilisés par d’autres programmes ; ce qui évite d’avoir à réécrire à chaque fois un code que plusieurs applications peuvent utiliser. Sur le danger des bibliothèques propriétaires pour le projet de constitution le projet GNU (Stallman, 1999, p. 77). La Free Software Foundation a produit d’autres licences, comme la GNU Free Documentation License, conçue pour les documents accompagnant les logiciels, mais qui peut aussi être utilisée pour d’autres catégories d’œuvres comme les manuels scolaires ou les dictionnaires, ou la GNU Affero General Public License (AGPL), une licence de logiciel libre avec copyleft pour des programmes utilisés par des réseaux.

29 Comme le code de Navigator, le navigateur de Netscape en 1998, ce qui devait conduire à la formation de Mozilla.org (Firefox, Thunderbird, etc.), où celui de StarOffice, qui mis sous LGPL donnera naissance à OpenOffice.org en 2000, celui de Blender, un logiciel d’animation et rendu 3D en 2002, etc.

30 Ainsi une licence qui précise que tous les litiges éventuels doivent être tranchés aux États-Unis dans l’État de Virginie est incompatible avec la licence GNU-GPL, qui exclut toute domiciliation judiciaire particulière (cas de certaines versions de la licence Python), etc. La combinaison de code source dans le cadre d’une même version de la licence GNU-GPL est possible. Il en est de même pour le code source sous LGPL, compatible avec la GPL dans le cadre d’une même version. Mais entre les différentes versions (3 et 2 par exemple) existent certains problèmes d’incompatibilité.

31 Cf. http://www.gnu.org/licenses/license-list.fr.html

32 Dans les communautés du logiciel libre, certains refusent la clause copyleft, qui leur semble philosophiquement trop contraignante, d’autres pour des raisons plus pragmatiques et stratégiques. L’alternative est alors en général le choix d’une licence dite BSD, inspirée de la vieille licence de l’Université de Berkeley mais dans une version nouvelle, sans l’inconvénient de la clause publicitaire.

33 Le code du système d’exploitation Linux au début de son développement (octobre 1991) était sous une licence libre qui interdisait strictement toute distribution commerciale ; Linus Torvalds voulant protester alors contre le fait qu’à l’époque il n’existait aucun logiciel bon marché destiné aux étudiants. Au printemps 1992, le code fut mis sous GPL au printemps 1992, la GPL garantissant que quiconque travaille sur le code dans l’avenir en ferait profiter la communauté ; et Linus Torvalds devait déclarer plus tard : « Protéger Linux par la GPL est la meilleure décision que j’aie jamais prise » (Yamagata, 1997).

34 Depuis l’affaire Educaffix contre CNRS, Université Joseph Fourrier et autres (TGI Paris 28 mars 2007), les tribunaux français reconnaissent la validité de la GNU-GPL (y compris la clause copyleft) sur le territoire de la République; une décision importante, car il était à craindre que la France, l’un des pays les plus protecteurs en matière de droit d’auteur, considère la licence libre comme nulle en droit français. Cette jurisprudence a été confirmée depuis dans l’affaire AFPA contre la société EDU 4 (Cour d’appel de Paris, 16 septembre 2009). [source : Staub & Associés].

35 L’économie de l’information, contrairement à ce que certains économistes affirment, citant Kenneth Arrow (1962), est largement construite sur un principe de non propriété de l’information, une fois celle-ci dévoilée pour la première fois. C’est en particulier le cas aux États-Unis, une règle imposée par le premier amendement de la Constitution américaine (free speech), traditionnellement interprété par la Cour suprême comme le droit pour chaque individu d’accéder à l’information. Cet amendement interdit donc la mise sous copyright de l’information ; et c’est sur ce principe, et à partir des communs informationnels qui en découlent, que le secteur de la presse et des médias a pris son essor et prospéré aux États-Unis comme dans d’autres pays.

36 On peut donner comme exemples deux accords de licences croisées qui abolissaient localement les patents en leur substituant d’autres règles (mise en commun, etc.), celui de 1914 à 1955 de l’industrie automobile américaine né après l’affaire du brevet Selden et la Manufacturers Aircraft Association formée en 1917 pour clore la guerre des patents initiée par les frères Wright. Le même principe d’abolition locale des patents a permis l’essor actuel de l’internet et du web, c’est la W3C Patent Policy, http://www.w3.org/Consortium/Patent-Policy-20040205/. (Cf. Merges, 2000 ; Mangolte, 2012).

37 Contrairement à ce que postule l’analyse économique standard des droits de propriété intellectuelle, celle de l’Université de Chicago du moins, qui pose comme seule limite au copyright et aux autres « droits de propriété intellectuelle » le niveau des coûts de transaction, et plus particulièrement des coûts liés au maintien de l’exclusivité et au prélèvement des droits. Sur ce point voir Landes et Posner (2002).

Top of page

List of illustrations

Title Schéma 1. SHARE, un pool de ressources communes géré par une firme
URL http://journals.openedition.org/regulation/docannexe/image/10517/img-1.png
File image/png, 35k
Title Schéma 2. Le commun des logiciels libres (copyleftés ou non copyleftés)
URL http://journals.openedition.org/regulation/docannexe/image/10517/img-2.jpg
File image/jpeg, 76k
Title Schéma 3. Le sens des migrations du code, d’un système de licence à l’autre
URL http://journals.openedition.org/regulation/docannexe/image/10517/img-3.png
File image/png, 50k
Top of page

References

Electronic reference

Pierre-André Mangolte, Une innovation institutionnelle, la constitution des communs du logiciel libreRevue de la régulation [Online], 14 | 2e semestre / Autumn 2013, Online since 14 February 2014, connection on 19 March 2024. URL: http://journals.openedition.org/regulation/10517; DOI: https://doi.org/10.4000/regulation.10517

Top of page

About the author

Pierre-André Mangolte

Maître de conférences en sciences économiques à l’université Paris 13 (à la retraite), p.a.mangolte@wanadoo.fr.

Top of page

Copyright

CC-BY-NC-ND-4.0

The text only may be used under licence CC BY-NC-ND 4.0. All other elements (illustrations, imported files) are “All rights reserved”, unless otherwise stated.

Top of page
Search OpenEdition Search

You will be redirected to OpenEdition Search