Pourquoi le logiciel doit être libre

par Richard Stallman

L'existence du logiciel soulève forcément la question de la façon dont doivent être prises les décisions concernant son usage. Par exemple, supposons qu'une personne ayant un exemplaire d'un programme rencontre une autre personne qui en voudrait une copie. Il leur est possible de copier le programme ; qui doit décider si cela se fera ? Les personnes elles-mêmes ? Ou une tierce personne, son « propriétaire » ?

Les développeurs de logiciel envisagent typiquement ces questions en supposant que le critère de la réponse est la maximisation de leurs propres profits. Le pouvoir politique des affaires a poussé le gouvernement à adopter à la fois ce critère et la réponse proposée par les développeurs, à savoir qu'un programme a un propriétaire, en général une société associée à son développement.

Je voudrais envisager la même question avec un critère différent : la prospérité et la liberté du public en général.

La réponse ne peut venir de la loi actuelle – la loi devrait se conformer à l'éthique et non l'inverse. La pratique actuelle n'apporte pas non plus de réponse, bien qu'elle puisse en suggérer. La seule façon d'en juger est de chercher à savoir qui gagne et qui perd en reconnaissant des propriétaires aux logiciels, pourquoi et dans quelle mesure. En d'autres termes, nous devons effectuer une analyse des coûts et des avantages au nom de la société dans son ensemble, en prenant en compte aussi bien la liberté individuelle que la production de biens matériels.

Dans cet essai, je décrirai les effets de l'existence des propriétaires et je montrerai que les résultats en sont préjudiciables. Ma conclusion est que les programmeurs ont le devoir d'encourager les autres à partager, redistribuer, étudier et améliorer les logiciels qu'ils écrivent ; autrement dit, d'écrire des logiciels libres [1].

Comment les propriétaires justifient leur pouvoir

Ceux qui bénéficient du système actuel, dans lequel les programmes sont une propriété, présentent deux arguments en appui à leur prétention de les détenir : l'argument affectif et l'argument économique.

L'argument affectif ressemble à ceci : « J'ai mis ma sueur, mon cœur, mon âme dans ce programme. Il vient de moi, c'est le mien ! »

Cet argument ne nécessite pas de réfutation sérieuse. Les programmeurs peuvent cultiver ce sentiment d'affection quand ça les arrange ; il n'est pas inévitable. Considérons, par exemple, comment ces mêmes programmeurs cèdent volontiers leurs droits à une grosse entreprise moyennant salaire ; mystérieusement, l'attachement affectif disparaît. Faisons le contraste avec ces grands artistes et artisans des temps médiévaux, qui ne signaient même pas leurs œuvres. Pour eux, le nom de l'artiste n'avait pas d'importance. Ce qui importait, c'était que le travail soit accompli et que son but afférent soit atteint. Cette façon de voir a prévalu pendant des centaines d'années.

L'argument économique est du style : « Je veux devenir riche (ce qui en général, se dit incorrectement 'je veux gagner ma vie'), et si vous ne me permettez pas de devenir riche en programmant, eh bien je ne programmerai pas. Comme tout le monde me ressemble, personne n'écrira de programmes. Et vous serez coincés, car il n'y aura pas de programme du tout ! » Cette menace est généralement déguisée en conseil amical venant de la bouche d'un sage.

J'expliquerai plus tard pourquoi cette menace est du bluff. J'aimerais d'abord mettre le doigt sur une supposition implicite qui est plus évidente dans une autre formulation de l'argument.

Cette formulation part de la comparaison entre l'utilité sociale d'un programme privateur ^a et de l'absence de programme, pour alors conclure que le développement de logiciel privateur est globalement bénéfique et qu'il doit être encouragé. L'erreur, ici, vient de ne comparer que deux résultats – logiciel privateur contre pas de logiciel – et de supposer qu'il n'y a pas d'autre possibilité.

Dans un système reconnaissant le droit d'auteur, le développement logiciel est habituellement lié à l'existence d'un propriétaire qui contrôle l'utilisation du logiciel. Tant que ce lien existe, nous devons souvent faire face au choix entre un programme privateur et l'absence de programme. Cependant, ce lien n'est pas inhérent ni inévitable ; c'est une conséquence d'une décision politique spécifique, législative et sociétale, que nous contestons : la décision qu'il y ait des propriétaires. Formuler le choix entre logiciel privateur et pas de logiciel, c'est faire une pétition de principe.

L'argument contre la propriété privée du logiciel

La question qu'il faut poser, c'est : « Le développement d'un logiciel doit-il être lié à un propriétaire qui en restreint l'usage ? »

Pour pouvoir en décider, il nous faut estimer l'effet sur la société de chacune de ces activités, prise indépendamment : l'effet du développement d'un logiciel (indépendamment des conditions de sa diffusion), et l'effet de la restriction de son emploi (à supposer que le logiciel ait été développé). Si l'une de ces activités est utile alors que l'autre est nuisible, il serait à notre avantage de les dissocier et de ne poursuivre que celle qui est utile.

En d'autres termes, si restreindre la distribution d'un logiciel déjà développé est préjudiciable à la société dans son ensemble, alors un développeur ayant du sens moral rejettera cette activité.

Pour déterminer l'effet de la restriction du partage, nous avons besoin de comparer la valeur, pour la société, d'un programme restreint (par ex. privateur) avec le même programme, mais disponible pour tout le monde. Ce qui signifie comparer deux mondes possibles.

Cette analyse répond également à un contre-argument simpliste qu'on entend parfois : le bénéfice pour le voisin de lui donner une copie d'un logiciel est annulé par le préjudice causé au propriétaire. Ce contre-argument suppose qu'inconvénients et avantages sont équivalents dans leur ampleur. Notre analyse compare ces deux termes et montre que les avantages l'emportent de beaucoup.

Pour mettre cet argument en lumière, prenons un autre domaine d'application : la construction routière.

Il serait possible de financer l'ensemble de la construction routière par des péages, ce qui impliquerait d'avoir des postes de péage à tous les coins de rues. Un tel système inciterait grandement à améliorer l'état des routes. Il aurait aussi comme vertu de faire payer l'usager de la route concernée. Cependant, un poste de péage est un obstacle artificiel à la fluidité du trafic, artificiel dans le sens où ce n'est pas une conséquence du fonctionnement des routes et des voitures.

Si l'on compare l'utilité des routes avec et sans péage, nous voyons (toutes choses égales par ailleurs) que les routes sans péage sont moins chères à construire et à maintenir, plus sûres et plus efficaces à emprunter [2].^b Dans les pays pauvres, les postes de péage rendent les routes inaccessibles à bien des citoyens. Les routes sans péage offrent ainsi plus d'avantages à moindre coût ; elles sont préférables pour la société. C'est pourquoi la société doit trouver d'autres moyens de financer les routes, sans recourir aux péages. L'usage des routes, une fois construites, doit être libre (ou gratuit) [free].^c

Quand les partisans des postes de péage les proposent comme étant simplement une façon de lever des fonds, ils déforment le choix offert. Les postes de péage, effectivement, permettent de récolter des fonds, mais ils ont une autre conséquence : ils dégradent la valeur des routes. Une route n'offre pas autant d'avantages si elle a un péage que si elle n'en a pas ; nous donner plus de routes, ou des routes supérieures sur le plan technique, n'est peut-être pas une amélioration véritable si cela signifie substituer aux routes libres [free] des routes à péage.

Bien entendu, construire des routes sans péage coûte de l'argent, que le public doit payer d'une façon ou d'une autre. Toutefois, cela n'implique pas que les postes de péage soient inévitables. Nous, qui devrons payer dans un cas comme dans l'autre, obtiendrons plus pour notre argent en achetant des routes sans péage.

Je ne suis pas en train de dire que les routes à péage sont pires que pas de route du tout. Ce serait vrai si les péages étaient tels que presque personne n'emprunterait la route – ce qui n'est pas une politique plausible pour un collecteur de péage. Cependant, tant que les postes de péage causeront des gaspillages et des inconvénients significatifs, il sera plus avantageux de lever des fonds d'une façon qui fasse moins obstacle à l'usage des routes.

Pour appliquer ce même argument au développement logiciel, je vais maintenant montrer que d'avoir des « postes de péage » sur des logiciels utiles coûte cher à la société : cela rend le programme plus coûteux à élaborer et à distribuer, moins satisfaisant et moins efficace à utiliser. Je poursuivrai en disant que la construction du programme devrait être encouragée autrement. Puis je m'attacherai à présenter d'autres méthodes d'encouragement et de financement du développement logiciel (dans la mesure réellement nécessaire).

Les obstacles font du tort au logiciel

Considérez un instant un programme dont le développement est terminé et entièrement payé ; maintenant, la société doit faire le choix entre le rendre privateur, ou en permettre le partage et l'utilisation en toute liberté. Supposez que l'existence et la disponibilité de ce programme soient souhaitables [3].

Les restrictions sur la distribution et la modification du programme ne facilitent pas son utilisation. Elles ne peuvent qu'interférer. Donc, leur effet ne peut être que négatif. Mais jusqu'à quel point ? Et de quelle manière ?

On distingue trois niveaux de préjudice matériel dans ce genre d'obstacle :

• moins de gens utilisent le programme ;
• aucun des utilisateurs ne peut l'adapter ni le corriger ;
• les autres développeurs ne peuvent rien en apprendre et il est impossible de commencer un nouveau projet en se basant dessus.

Chaque niveau de préjudice matériel a un préjudice psychosocial concomitant. Cela renvoie aux effets à long terme de nos décisions sur nos propres sentiments, attitudes et prédispositions. Ces changements dans notre façon de penser auront à leur tour un effet sur nos relations avec nos concitoyens et peuvent avoir des conséquences matérielles.

Les trois niveaux de préjudice matériel font perdre une partie de la valeur que le programme pourrait offrir, mais ne peuvent la réduire à zéro. S'ils font perdre la presque totalité de la valeur du programme, alors l'écriture du programme cause du tort à la société, au plus à hauteur de l'effort qu'il a fallu fournir pour écrire ce programme. En effet, un programme dont la vente génère des profits fournit nécessairement un bénéfice net matériel direct.

Cependant, compte tenu des préjudices psychosociaux concomitants, il n'y a pas de limite au préjudice que peut provoquer le développement d'un logiciel privateur.

Obstacles à l'utilisation des programmes

Le premier niveau de préjudice gêne le simple usage d'un programme. Une copie d'un programme a un coût marginal proche de zéro (et ce prix, vous pouvez le payer en faisant le travail vous-même), ce qui veut dire que, dans un marché libre, elle aurait un prix avoisinant zéro. Une licence payante est une désincitation significative à l'utilisation d'un programme. Si un logiciel utile à l'ensemble de la population est privateur, beaucoup moins de gens l'utiliseront.

Il est facile de montrer que la contribution totale d'un programme à la société est réduite si on lui assigne un propriétaire. Chaque utilisateur potentiel du logiciel, face à la nécessité de le payer pour l'utiliser, peut choisir de payer ou de renoncer à son usage. Si un utilisateur fait le choix de payer le programme, il y a un simple transfert de richesses entre deux parties. Mais chaque fois qu'une personne choisit de s'abstenir d'utiliser le programme, cela cause du tort à cette personne sans que quiconque y trouve son compte. Quand on additionne des nombres négatifs avec zéro, le résultat ne peut être que négatif.

Mais cela ne réduit pas la somme de travail qu'il a fallu pour développer le programme. Donc, l'efficacité de l'ensemble du processus, calculée sur la base de la satisfaction des utilisateurs par heure de travail, en est diminuée.

Ceci reflète la différence cruciale entre la copie d'un programme et celle d'une voiture, d'une chaise ou d'un sandwich. À part dans la science-fiction, il n'existe pas de machine pouvant reproduire les objets matériels. Mais les programmes sont faciles à copier ; n'importe qui peut faire autant de copies que nécessaire, sans grand effort – ce qui n'est pas vrai dans le cas des objets matériels, étant donné que la matière est conservée : chaque copie nécessite des matières premières, tout comme l'original.

En ce qui concerne les objets matériels, décourager leur usage est logique, car moins d'objets achetés signifie moins de matières premières, moins de travail pour les construire. C'est vrai qu'il y a aussi, en général, un investissement initial et un coût de développement que l'on doit répartir sur l'ensemble de la production. Mais tant que le coût marginal de production est significatif, y ajouter un pourcentage des coûts de développement ne provoque pas de différence qualitative. Et cela n'exige aucune restriction à la liberté des utilisateurs ordinaires.

Cependant, imposer un prix à quelque chose qui, autrement, aurait pu être gratuit, c'est un changement qualitatif. Une redevance imposée de manière centralisée sur la distribution de logiciels devient une puissante source de démotivation.

De plus, la production centralisée, telle qu'elle est pratiquée de nos jours, est inefficace, même comme moyen de fournir des copies de logiciels. Ce système implique d'empaqueter des disquettes ou des bandes dans un emballage superflu, de les envoyer en grande quantité dans le monde entier puis de les stocker avant leur vente. Ces coûts sont présentés comme étant le prix à payer pour faire des affaires ; en vérité, ils font partie du gaspillage qu'entraîne le fait d'avoir des propriétaires.

Dommages à la cohésion sociale

Supposons que vous et votre voisin trouviez utile de faire tourner un certain programme. Par souci d'éthique envers votre voisin, vous estimerez probablement que la bonne chose à faire est de vous en servir tous les deux. Proposer de n'en permettre l'usage qu'à un seul d'entre vous, tout en l'interdisant à l'autre, entraînerait la division ; ni vous, ni votre voisin ne trouveriez cela acceptable.

Signer un contrat de licence typique pour un logiciel revient à trahir votre voisin : « Je fais la promesse de priver mon voisin de ce programme de sorte que je puisse en avoir un exemplaire pour moi-même. » Les gens qui font de tels choix ressentent la pression psychologique interne de se justifier, en diminuant l'importance d'aider leur voisin – cela au détriment du sens civique. C'est là un préjudice psychosocial associé au préjudice matériel consistant à décourager l'utilisation du logiciel.

Beaucoup d'utilisateurs reconnaissent inconsciemment que le fait de refuser le partage est mal ; ils décident alors d'ignorer les licences et les lois, et de partager tout de même les programmes. Mais ils s'en sentent souvent coupables. Ils savent qu'ils doivent enfreindre la loi pour être de bons voisins, mais ils continuent de penser que les lois font autorité et concluent qu'être un bon voisin (ce qu'ils sont), c'est vilain et honteux. C'est aussi une forme de préjudice psychosocial, mais on peut y échapper en prenant la décision de considérer que ces licences et ces lois n'ont aucune force morale.

Les programmeurs souffrent aussi de préjudice psychosocial, sachant que bien des utilisateurs ne seront pas autorisés à se servir des fruits de leur labeur. Ceci conduit à une attitude de cynisme ou de dénégation. Un programmeur peut faire une description enthousiaste d'un travail qu'il trouve stimulant sur le plan technique ; puis, quand on lui demande « Est-ce qu'il me sera permis de l'utiliser ? », son visage se ferme et il doit bien admettre que non. Pour éviter de se sentir découragé, soit, la plupart du temps, il ignore ce fait, soit il adopte une attitude cynique afin d'en minimiser l'importance.

Aux États-Unis, depuis la période reaganienne, ce qui manque le plus n'est pas l'innovation technique, mais plutôt la volonté de travailler ensemble pour le bien public. Cela n'a pas de sens d'encourager l'un au détriment de l'autre.

Obstacles à l'adaptation sur mesure des programmes

Le deuxième niveau de préjudice matériel est l'impossibilité d'adapter les programmes. La facilité de modification du logiciel est un de ses grands avantages par rapport aux technologies plus anciennes. Mais la plupart des logiciels commerciaux ne peuvent être modifiés, même après les avoir achetés. Ils sont à prendre ou à laisser, comme une boîte noire, un point c'est tout.

Un programme exécutable se compose d'une série de nombres dont le sens est obscur. Personne, même un bon programmeur, ne peut aisément changer les nombres pour amener le programme à faire quelque chose de différent.

Normalement, les programmeurs travaillent sur le « code source » d'un programme, écrit dans un langage de programmation comme le Fortran ou le C. Ils utilisent des noms pour désigner les données utilisées et les différentes parties du programme, et ils représentent les opérations par des symboles comme le + pour une addition ou le - pour une soustraction. Le langage est conçu pour aider les programmeurs à déchiffrer et modifier les programmes. Voici un exemple : il s'agit d'un programme qui calcule la distance entre deux points d'un plan :

     float
     distance (p0, p1)
          struct point p0, p1;
     {
       float xdist = p1.x - p0.x;
       float ydist = p1.y - p0.y;
       return sqrt (xdist * xdist + ydist * ydist);
     }

Ce que fait précisément ce code source n'est pas le problème ; le point important est que cela ressemble à de l'algèbre et qu'une personne connaissant ce langage de programmation le trouvera sensé et clair. En revanche, voici le même programme sous sa forme exécutable, sur l'ordinateur que j'utilisais lorsque j'ai écrit ceci :

     1314258944      -232267772      -231844864      1634862
     1411907592      -231844736      2159150         1420296208
     -234880989      -234879837      -234879966      -232295424
     1644167167      -3214848        1090581031      1962942495
     572518958       -803143692      1314803317

Le code source est utile (au moins potentiellement) à chacun des utilisateurs d'un programme, mais la plupart ne sont pas autorisés à en posséder une copie. Normalement, le code source d'un programme privateur est tenu secret par son propriétaire, de peur que quelqu'un d'autre n'en apprenne quelque chose. L'utilisateur reçoit simplement des fichiers de nombres incompréhensibles que l'ordinateur exécutera. Cela signifie que seul le propriétaire du logiciel peut changer le programme.

Un jour, une amie me raconta avoir travaillé comme programmeuse dans une banque durant environ six mois, pour écrire un programme semblable à un autre qui était disponible commercialement. Elle croyait que, si elle avait eu accès au code source de ce programme commercial, elle aurait facilement pu l'adapter aux besoins de la banque. La banque souhaitait payer pour cela, mais elle n'y fut pas autorisée – le code source était un secret. Pendant six mois, elle a donc dû faire un travail bidon, un travail qui a compté pour quelque chose dans le PNB, mais qui était en fait du gaspillage.

Aux alentours de 1977, le laboratoire d'intelligence artificielle (IA) du MIT reçut un cadeau de Xerox, une imprimante graphique. Elle était pilotée par un logiciel libre, auquel nous avons ajouté de nombreuses fonctionnalités bien commodes. Par exemple, le logiciel avertissait immédiatement l'utilisateur de la fin du processus d'impression. Si l'imprimante venait à rencontrer un problème, comme un bourrage ou un manque de papier, le programme avertissait de suite tous ceux qui avaient des travaux d'impression en cours. Ces fonctionnalités facilitaient la vie.

Plus tard, Xerox offrit au labo d'IA une nouvelle imprimante, plus rapide, une des premières laser. Elle était pilotée par un logiciel privateur qui tournait sur un poste dédié et séparé, nous ne pouvions donc ajouter aucune de nos fonctionnalités favorites. On pouvait s'arranger pour envoyer un avertissement quand une tâche d'impression était envoyée au poste dédié, mais pas quand celle-ci était terminée (et les délais étaient habituellement importants). Il n'y avait aucun moyen de savoir si le document était imprimé ; il fallait deviner. Et personne n'était informé d'un bourrage papier ; l'imprimante attendait ainsi souvent une heure avant d'être remise en route.

Les programmeurs système du labo d'IA étaient capables de corriger de tels problèmes, probablement tout aussi capables que les auteurs du programme. Xerox n'avait pas envie de les corriger et choisit de nous en empêcher, nous avons donc été forcés de subir les problèmes. Ils n'ont jamais été corrigés.

La plupart des bons programmeurs ont fait l'expérience de cette frustration. La banque pouvait se permettre de résoudre son problème en écrivant un nouveau programme depuis le début, mais un utilisateur lambda, quelle que soit son habileté, ne peut que laisser tomber.

Laisser tomber provoque un préjudice psychosocial – sur l'esprit d'indépendance. C'est démoralisant d'habiter une maison qu'on ne peut réarranger selon ses besoins. Cela conduit à la résignation et au découragement, ce qui peut affecter d'autres aspects de la vie d'une personne. Les gens qui ont ce sentiment ne sont pas heureux et ne font pas du bon travail.

Imaginez ce que ce serait si les recettes de cuisine étaient logées à la même enseigne que les logiciels. Vous vous diriez : « Voyons, comment modifier cette recette pour en enlever le sel ? » Et le chef renommé de vous répondre : « Comment oses-tu insulter ma recette, fruit de mon cerveau et de mon palais, en tentant de la modifier ? Tu n'as pas assez de jugement pour la changer sans la dénaturer. »

« Mais mon docteur m'a recommandé de ne pas manger salé. Que puis-je faire ? Pouvez-vous en ôter le sel pour moi ? »

« Je serais heureux de le faire ; mes honoraires ne sont que de 50 000 dollars. » À partir du moment où le propriétaire a le monopole des modifications, les honoraires tendent à gonfler. « De toute façon, je n'ai pas le temps maintenant. Je suis pris par une commande du ministère de la marine qui m'a demandé de créer une nouvelle recette de biscuit de mer. Je reprendrai contact avec toi dans environ deux ans. »

Obstacles au développement logiciel

Le troisième niveau de préjudice matériel touche le développement logiciel. C'était autrefois un processus évolutif, où quelqu'un prenait un programme existant et en réécrivait une partie pour ajouter une nouvelle fonctionnalité ; puis une autre personne en réécrivait aussi une partie pour y ajouter une autre fonctionnalité. Dans certains cas, cela a continué ainsi sur une période d'une vingtaine d'années. Entre-temps, certaines parties du programme se voyaient « cannibalisées » pour créer l'amorce d'autres programmes.

L'existence de propriétaires empêche ce genre d'évolution, ce qui rend nécessaire de repartir à zéro si l'on veut développer un programme. Cela empêche également les nouveaux praticiens d'étudier les programmes existants pour en apprendre des techniques utiles ou même apprendre comment on structure de gros programmes.

Les propriétaires font ainsi obstacle à l'éducation, à l'apprentissage. J'ai rencontré de brillants étudiants en informatique qui n'avaient jamais vu le code source d'un grand programme. Ils sont peut-être bons à écrire des programmes courts, mais les grands demandent des techniques d'écriture différentes qu'ils ne peuvent pas commencer à apprendre s'ils ne peuvent observer comment d'autres ont fait.

Dans tout domaine intellectuel, on peut atteindre de plus hauts sommets en se tenant sur les épaules des autres. Mais ce n'est généralement plus permis dans le domaine logiciel – ce n'est permis qu'à l'intérieur de votre propre entreprise.

Le préjudice psychosocial qui s'y rattache affecte l'esprit de coopération scientifique, qui était autrefois si fort que les scientifiques coopéraient même quand leurs pays étaient en guerre. C'est dans cet esprit que des océanographes japonais, abandonnant leur labo dans une île du Pacifique, ont soigneusement conservé leurs travaux pour les Marines américains qui commençaient à débarquer et laissèrent un mot leur demandant d'en prendre bien soin.

Les conflits de la course aux profits ont détruit ce que les conflits internationaux avaient épargné. Aujourd'hui, les scientifiques de nombreuses disciplines ne donnent pas assez de détails dans leurs publications pour que d'autres puissent reproduire leur expérience. Ils ne publient que ce qui permet au lecteur d'être impressionné par l'étendue de leurs travaux. C'est particulièrement vrai pour la recherche informatique, où le code source des programmes décrits dans les publications est en général secret.

Le moyen utilisé pour restreindre le partage n'a pas d'importance

J'ai parlé de ce qui se passe quand on empêche les gens de copier, de modifier ou de prendre comme base un programme existant. Je n'ai pas précisé la nature de ces obstacles, car cela n'affecte pas la conclusion. Que ce soit par une protection contre la copie, le droit d'auteur, les licences, le chiffrement, les cartes ROM ou encore un numéro de série sur le matériel, si cela réussit à empêcher l'utilisation, alors il y a préjudice.

Les utilisateurs jugent certaines de ces méthodes plus odieuses que d'autres. Je suggère que les méthodes les plus détestées sont celles qui accomplissent leur objectif.

Le logiciel doit être libre

J'ai montré comment la propriété d'un programme, le pouvoir de restreindre sa modification ou sa copie, est source d'obstacles. Ses retombées négatives sont vastes et importantes. Il s'ensuit que la société doit se passer des propriétaires de logiciels.

Pour voir les choses autrement : ce dont a besoin la société, c'est de logiciels libres ; les logiciels privateurs n'en sont qu'un médiocre substitut. Encourager le substitut n'est pas une façon rationnelle d'obtenir ce dont nous avons besoin.

Václav Havel nous a conseillé de « travailler pour une chose parce qu'elle est bonne, pas parce que cela a des chances de réussir ». Un marché créant des logiciels privateurs a des chances de réussir dans l'étroite limite de ses propres règles, mais ce n'est pas ce qui est bon pour la société.

Pourquoi les gens développeront des logiciels

Si nous éliminons le droit d'auteur comme moyen d'encourager les gens à développer des logiciels, au début moins de programmes seront développés, mais ils seront plus utiles. Difficile de dire si la satisfaction d'ensemble des utilisateurs sera moindre. Mais si c'est le cas, ou si nous voulons l'augmenter de toute façon, il y a d'autres moyens d'encourager le développement, tout comme il y a des alternatives aux postes de péage pour financer les rues. Mais avant de parler de la façon dont cela peut se faire, je vais d'abord me demander dans quelle mesure un encouragement artificiel est vraiment nécessaire.

Programmer, c'est amusant

Certains domaines professionnels trouvent peu de candidats, sauf pour de l'argent ; la construction routière, par exemple. Il en est d'autres, touchant aux études ou à l'art, dans lesquelles il y a peu de chance de devenir riche, mais où les gens s'engagent par passion ou à cause de la valeur que leur accorde la société. On peut y inclure, par exemple, la logique mathématique, la musique classique et l'archéologie ; également l'action politique au sein du monde du travail. Les gens concourent, plus tristement qu'âprement, pour les quelques postes rémunérés disponibles, dont aucun n'est vraiment bien payé. Ils iraient jusqu'à payer pour avoir la chance de travailler dans un de ces domaines, s'ils pouvaient se le permettre.

Un tel domaine peut se transformer du jour au lendemain s'il commence à offrir la possibilité de devenir riche. Si un travailleur devient riche, les autres réclament la même opportunité. Bientôt tous pourront exiger de fortes sommes d'argent pour ce qu'ils avaient l'habitude de faire pour le plaisir. Deux ou trois ans de plus, et tous ceux qui appartiendront au domaine tourneront en dérision l'idée que le travail puisse se faire sans une rentabilité financière conséquente. Ils conseilleront aux acteurs sociaux de rendre possible cette rentabilité en imposant les privilèges, pouvoirs et monopoles spéciaux qu'elle nécessite.

Ce changement est survenu dans le domaine de la programmation au cours des années 80. Dans les années 70, des articles parlaient d'« accrocs à l'informatique » : les utilisateurs étaient « connectés » et vivaient avec 100 $ par semaine.^d Il était généralement admis que des gens pouvaient aimer la programmation au point qu'elle devienne une cause de divorce. Aujourd'hui, il est généralement admis que personne ne programmerait sauf en échange d'un salaire élevé. On a oublié ce qu'on savait à l'époque.

Même si à un moment précis, il est vrai que la plupart des gens ne veulent travailler dans un domaine particulier que pour un haut salaire, il ne faut pas en conclure que ce sera toujours le cas. La tendance peut s'inverser sous l'impulsion de la société. Si nous retirons du jeu la possibilité d'amasser de grandes fortunes, alors au bout de quelque temps, quand les gens auront réajusté leurs attitudes, ils seront de nouveau impatients de travailler dans ce domaine pour le simple plaisir de réaliser quelque chose.

Répondre à la question « Comment pouvons-nous payer les programmeurs ? » devient plus facile quand nous réalisons qu'il ne s'agit pas de leur offrir une petite fortune. Il est plus facile de leur assurer un niveau de vie correct, mais sans plus.

Financer le logiciel libre

Les institutions qui payent les programmeurs n'ont pas besoin d'être des éditeurs de logiciels. Beaucoup d'autres institutions existantes peuvent le faire.

Les fabricants de matériel informatique pensent qu'il est essentiel de soutenir le développement du logiciel, même s'ils ne peuvent contrôler son usage. En 1970, la plupart de leurs logiciels étaient libres, car ils ne pensaient pas à les entraver. Aujourd'hui, leur volonté croissante de se joindre à des consortiums montre bien qu'ils ont conscience que posséder le logiciel n'est pas ce qui est vraiment important pour eux.

Les universités dirigent de nombreux projets de développement logiciel. Aujourd'hui, elles en vendent souvent les résultats, mais dans les années 70 elles ne le faisaient pas. Peut-on douter que les universités développeraient des logiciels libres si elles n'étaient pas autorisées à vendre les logiciels ? Ces projets pourraient recevoir le soutien des mêmes contrats et subventions publiques qui soutiennent actuellement le développement de logiciels privateurs.

Il est courant de nos jours que les chercheurs universitaires reçoivent une subvention pour développer un système, qu'ils l'amènent presque jusqu'au point d'achèvement, qu'ils le déclarent effectivement « fini », puis créent des sociétés où ils finiront réellement le projet et le rendront utilisable. Parfois, ils déclarent « libre » la version non terminée ; s'ils sont vraiment corrompus, ils obtiendront plutôt une licence exclusive de la part de l'université. Ce n'est pas un secret, c'est ouvertement admis par toutes les personnes concernées. Pourtant, si les chercheurs n'étaient pas exposés à la tentation de faire ce genre de chose, ils poursuivraient quand même leurs recherches.

Les programmeurs qui écrivent des logiciels libres peuvent gagner leur vie en vendant des services liés au logiciel. J'ai été recruté pour porter le compilateur C de GNU sur du nouveau matériel informatique et pour faire des extensions d'interface utilisateur pour GNU Emacs (j'offre ces améliorations au public, une fois qu'elles sont réalisées). Je suis aussi payé pour faire des cours.

Je ne suis pas le seul à travailler de cette façon ; il existe maintenant une entreprise florissante, en expansion, qui ne fait que ce genre de travail. Plusieurs autres sociétés fournissent également un support commercial aux logiciels libres issus du système GNU. C'est le début d'une industrie indépendante de support au logiciel libre, une industrie qui pourrait prendre de fortes proportions si le logiciel libre devait se généraliser. Elle offre aux utilisateurs des options qui sont généralement indisponibles dans le cas du logiciel privateur, sauf pour les plus riches.

De nouvelles institutions peuvent aussi financer les programmeurs, par exemple la Free Software Foundation. Cette dernière tire la majeure partie de ses fonds de la vente de bandes magnétiques par correspondance. Le logiciel présent sur la bande est libre, ce qui signifie que chaque utilisateur est libre de le copier et de le modifier, mais néanmoins beaucoup payent pour en obtenir des copies (rappelez-vous que free software veut dire logiciel libre, non pas logiciel gratuit). Certains utilisateurs achètent des bandes, alors qu'ils en possèdent déjà une copie, simplement parce qu'ils sentent que nous méritons cette contribution. La Fondation reçoit aussi des donations considérables de la part de fabricants d'ordinateurs.

La Free Software Foundation est une organisation caritative et ses revenus sont utilisés pour embaucher le plus de programmeurs possible. Si elle avait été montée comme une entreprise, distribuant les mêmes logiciels libres au public pour le même tarif, elle assurerait aujourd'hui un très bon niveau de vie à son fondateur.

Puisque la Fondation est une organisation caritative, les programmeurs travaillent souvent pour la moitié de ce qu'ils pourraient toucher ailleurs. Ils le font parce qu'ils sont libres de toute bureaucratie et parce qu'ils ressentent de la satisfaction à savoir qu'il n'y aura pas d'obstacle à l'utilisation de leur travail. Et, par-dessus tout, ils le font parce que programmer est un vrai plaisir. Ajoutons que des bénévoles nous ont écrit nombre de programmes (même des rédacteurs techniques ont commencé à nous aider bénévolement).

Ceci confirme que la programmation est l'un des domaines les plus fascinants, au même titre que la musique et les arts. Nous n'avons pas à craindre que plus personne ne veuille programmer.

Qu'est-ce que les utilisateurs doivent aux programmeurs ?

Les utilisateurs d'un logiciel ont une bonne raison de se sentir moralement obligés de contribuer à son soutien. Les développeurs de logiciel libre contribuent aux activités des utilisateurs, il est donc à la fois juste et – sur le long terme – aussi dans l'intérêt des utilisateurs de continuer à les financer.

Cependant, ceci ne s'applique pas aux développeurs de logiciel privateur, car la création d'obstacles appelle plutôt une sanction qu'une récompense.

Nous nous trouvons ainsi face à un paradoxe : le développeur d'un logiciel utile a droit au soutien des utilisateurs, mais n'importe quelle tentative de transformer cette obligation morale en une exigence détruit les bases de l'obligation. Un développeur peut soit recevoir une récompense, soit l'exiger, mais pas les deux.

Je crois qu'un développeur doué de sens moral faisant face à ce paradoxe doit agir de manière à mériter la récompense, mais devrait aussi encourager les utilisateurs à donner volontairement. Tôt ou tard, les utilisateurs apprendront à soutenir les développeurs d'eux-mêmes, tout comme ils ont appris à soutenir les radios et les stations télé indépendantes.

Qu'est-ce que la productivité logicielle ?

Si les logiciels étaient libres, il y aurait toujours des programmeurs, mais peut-être en nombre moindre. Est-ce que cela serait mauvais pour la société ?

Pas forcément. Aujourd'hui, les nations riches ont moins de fermiers qu'en 1900, mais nous ne pensons certainement pas que c'est mauvais pour la société, car ceux qui restent produisent plus de nourriture pour les consommateurs qu'un plus grand nombre n'en produisait autrefois. Nous appelons cela l'amélioration de la productivité. Le logiciel libre devrait demander moins de programmeurs pour satisfaire la demande, à cause de l'augmentation de la productivité logicielle à tous niveaux :

• une utilisation plus générale de chaque programme développé ;
• la possibilité d'adapter un programme existant pour le personnaliser au lieu de repartir de zéro ;
• une meilleure formation des programmeurs ;
• l'élimination des efforts de développement redondants.

Ceux qui s'opposent à la coopération dans la mesure où elle diminuerait le nombre d'emplois en programmation s'opposent en fait à l'accroissement de la productivité. Pourtant les mêmes acceptent souvent la croyance largement répandue que l'industrie logicielle a besoin d'accroître sa productivité. Comment cela se fait-il ?

La « productivité logicielle » peut vouloir dire deux choses : la productivité d'ensemble de tout le développement logiciel ou la productivité de projets individuels. La productivité d'ensemble, c'est ce que la société aimerait améliorer, et la voie la plus directe pour le faire est d'éliminer les obstacles artificiels à la coopération, qui la réduisent. Mais les chercheurs qui se penchent sur la « productivité logicielle » se concentrent uniquement sur le deuxième sens, limité, du terme, où l'amélioration demande des avancées technologiques difficiles.

Est-ce que la compétition est inévitable ?

Est-il inévitable que les gens entrent en compétition, qu'ils essayent de dépasser leurs rivaux dans la société ? Peut-être, oui. Mais la compétition en elle-même n'est pas nocive : ce qui est nocif, c'est le combat.

La compétition peut prendre de nombreuses formes. Elle peut consister en une tentative d'aller toujours plus loin, de surpasser ce que d'autres ont déjà réalisé. Par exemple, jadis, il y avait concurrence entre les meilleurs programmeurs, et l'on rivalisait pour faire faire à l'ordinateur les choses les plus incroyables, ou encore écrire le programme le plus court ou le plus rapide pour une tâche donnée. Ce genre de compétition est bénéfique pour tous, tant que subsiste le bon esprit sportif.

Une compétition constructive est suffisante pour pousser les gens à de grands efforts. Pas mal de gens rivalisent en ce moment pour savoir qui sera le premier à avoir visité tous les pays du globe ; il y en a même qui dépensent des fortunes pour cela. Mais ils ne corrompent pas les capitaines de navire pour faire échouer leurs rivaux sur des îles désertes. Ils sont satisfaits de laisser le meilleur gagner.

La compétition devient un combat quand les participants commencent à gêner les autres plutôt que de progresser eux-mêmes – c'est-à-dire quand le principe qui dit « que le meilleur gagne » fait place au « laissez-moi gagner, que je sois le meilleur ou non ». Le logiciel privateur est nocif, non parce que c'est une forme de compétition, mais parce que c'est une forme de combat entre les citoyens de notre société.

La compétition dans les affaires n'est pas forcément un combat. Par exemple, lorsque deux épiceries se font concurrence, tous leurs efforts tendent à l'amélioration de leurs propres services, pas au sabotage de l'entreprise rivale. Mais cela ne démontre pas un attachement particulier à l'éthique des affaires ; plutôt qu'il y a peu de place pour le combat dans ce secteur, violence physique mise à part. Tous les secteurs ne partagent pas cette caractéristique. La rétention d'information utile à tous, c'est une forme de combat.

L'idéologie des affaires ne prépare pas les gens à résister à la tentation de se battre lorsqu'ils sont en concurrence. Certaines formes de combat ont été interdites avec les lois antitrust, l'interdiction de la publicité mensongère, etc. ; mais plutôt que de considérer le rejet du combat comme un principe général, les dirigeants d'entreprises inventent d'autres formes de combat qui ne sont pas spécifiquement prohibées. Les ressources de la société sont gaspillées dans l'équivalent économique d'une guerre civile entre factions.

« Pourquoi ne pas t'établir en Russie ? »

Aux États-Unis, toute personne favorable à autre chose que le plus flagrant laisser-faire égoïste a souvent entendu ce genre de réflexion. On l'entend, par exemple, à l'encontre des partisans d'un système de santé publique tel qu'il existe dans toutes les autres nations industrialisées du monde libre. Ou encore à propos des partisans d'un soutien public des arts, tout aussi universel dans les nations développées. Aux États-Unis, l'idée que les citoyens aient une quelconque obligation de participer au bien public est considérée comme du communisme. Mais jusqu'à quel point ces idées sont-elles semblables ?

Le communisme, tel qu'il était pratiqué en Union Soviétique, était un système de contrôle centralisé où toutes les activités étaient strictement régentées, soi-disant pour le bien public, mais en fait pour le bien des membres du Parti communiste ; système où les machines à copier étaient étroitement gardées, pour empêcher la copie illégale.

Le système américain du droit d'auteur sur les logiciels exerce un contrôle central sur la distribution d'un programme et surveille les machines à copier grâce à des systèmes automatiques de protection contre la copie, pour empêcher la copie illégale.

Au contraire, je travaille à bâtir un système où les gens sont libres de décider de leurs propres actions ; libres en particulier d'aider leur voisin, ainsi que de modifier et améliorer les outils qu'ils utilisent dans leur vie quotidienne – un système basé sur la coopération volontaire et la décentralisation.

Du coup, si l'on doit juger ces points de vue par leurs ressemblances au communisme soviétique, alors ce sont les propriétaires de logiciel qui sont les communistes.

La question des prémisses

Dans cet article, je pars du principe que l'utilisateur d'un logiciel n'est pas moins important qu'un auteur ou même que l'employeur d'un auteur. Autrement dit, lorsqu'on décide quelle est la meilleure marche à suivre, leurs intérêts et leurs besoins ont autant d'importance.

Cette prémisse n'est pas universellement admise. Beaucoup soutiennent que l'employeur d'un auteur est fondamentalement plus important que n'importe qui d'autre. Ils disent, par exemple, que la raison d'être de la propriété du logiciel est de donner à l'employeur les avantages qui lui sont dus – sans s'occuper de l'effet sur le public.

Cela ne sert à rien d'essayer de prouver la véracité ou la fausseté de ces prémisses. Prouver demande des prémisses partagées. C'est pourquoi la plus grande partie de mon discours s'adresse à ceux qui partagent les prémisses que j'utilise ou qui, du moins, sont intéressés par leurs conséquences. Pour ceux qui croient que les propriétaires sont plus importants que tous les autres, pour ceux-là, cet article n'est tout simplement pas pertinent.

Mais pourquoi un grand nombre d'Américains accepteraient-ils une prémisse qui élèverait certaines personnes au-dessus des autres ? En partie à cause de la croyance que cette prémisse fait partie des traditions juridiques de la société américaine. Certaines personnes ont le sentiment qu'en douter, c'est défier les bases de la société.

Il est important de faire savoir à ces personnes que cette prémisse ne fait pas partie de notre tradition juridique. Elle n'en a jamais fait partie.

Ainsi, la Constitution dit que l'objectif du copyright est de « promouvoir le progrès des sciences et des arts utiles ». La Cour suprême l'a expliqué, énonçant dans Fox Film contre Doyal que « l'intérêt unique des États-Unis ainsi que l'objet principal du monopole [du copyright] résident dans les avantages globaux que le public tire du travail des auteurs ».

Nous ne sommes pas obligés d'être d'accord avec la Constitution ni avec la Cour suprême (il fut un temps où elles ont toutes deux approuvé l'esclavage). Leurs positions ne réfutent donc pas la prémisse de la suprématie du propriétaire. Mais j'espère que son attrait faiblira quand les gens prendront conscience que c'est un postulat de la droite radicale qui n'a pas sa source dans nos traditions.

Conclusion

Nous aimons à croire que notre société encourage le fait d'aider son voisin ; mais chaque fois que nous récompensons quelqu'un pour avoir posé des obstacles sur sa route ou que nous l'admirons pour les richesses qu'il a accumulées par ce moyen, nous renvoyons le message contraire.

La thésaurisation du logiciel est un exemple de notre volonté généralisée de faire passer le gain personnel avant le bien-être de la société. On peut suivre cette volonté à la trace depuis Ronald Reagan jusqu'à Dick Cheney, depuis Exxon jusqu'à Enron, en passant par les faillites des banques et des écoles. Nous pouvons la mesurer à la taille de la population des sans-abri et de la population carcérale. L'esprit antisocial se nourrit de lui-même, parce que plus on voit que les autres ne nous tendront pas la main, plus il nous semble futile de les aider. Ainsi, notre société dégénère en jungle.

Si nous ne voulons pas vivre dans une jungle, nous devons changer nos attitudes. Nous devons commencer à lancer le message que le bon citoyen est celui qui coopère quand il le faut, pas celui qui réussit à prendre aux autres. J'espère que le mouvement du logiciel libre contribuera à cela : au moins dans un domaine, nous remplacerons la jungle par un système plus efficace qui encouragera la coopération volontaire et fonctionnera grâce à elle.

Notes

1. ↑ Le mot free dans free software signifie « libre », et non « gratuit » [free a les deux sens, en anglais] ; le prix payé pour un exemplaire d'un programme libre peut être nul, faible, ou (rarement) très élevé.
2. ↑ Les problèmes de pollution et de congestion du trafic ne modifient pas cette conclusion. Si nous désirons rendre plus coûteuse la conduite afin de la décourager, il n'est pas avantageux de le faire en mettant en place des péages qui participent, et à la pollution, et à la congestion. Une taxe sur l'essence serait bien mieux. Pareillement, le désir de renforcer la sécurité en limitant la vitesse maximale n'est pas pertinent ; un accès gratuit aux routes améliore la vitesse moyenne en évitant arrêts et retards, quelle que soit la limitation de vitesse.
3. ↑ On peut voir un logiciel particulier comme une chose nocive, qui ne devrait être accessible à personne, à l'instar de la base de données d'informations personnelles de Lotus (Marketplace), qui a été retirée de la vente suite à la désapprobation du public. La plus grande partie de mon discours ne s'applique pas à ce cas, mais préférer un propriétaire dans la mesure où cela rendrait le programme moins disponible n'est pas très sensé. Le propriétaire ne le rendra pas complètement indisponible, comme on pourrait le souhaiter pour un programme considéré comme nocif.

---