Revised and improved translation of Why Software Should Be Free

[Mathieu Gauthier-Pilote <mathieu.g.p AT republiquelibre.org>]

Hello/Bonjour,

With the help of a friend (François Grimaud), I revised and improved the
French translation of Richard Stallman's essay "Why Software Should Be
Free":

http://www.gnu.org/philosophy/shouldbefree.html

Attached to this message is a copy of the original and a copy of the
revised version in simple text format. Applying a diff on the two files
will show the nature and extent of the changes.

Regards,

Mathieu GP
mathieu.g.p AT republiquelibre.org

Pourquoi les logiciels devraient être libres

par Richard Stallman

(Version du 24 avril 1992)
Introduction

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

Les développeurs de logiciels considèrent typiquement que le critère de 
réponse supposé est la maximisation de leurs 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 : c'est-à-dire qu'un programme a un 
propriétaire, en général une société associée à son développement.

J'aimerais considérer la même question en utilisant un critère différent : la 
prospérité et la liberté du public en général.

Cette réponse ne peut pas être décidée par la loi actuelle — la loi devrait 
se conformer à la morale, pas l'inverse — ni par l'usage, bien qu'ils 
puissent suggérer des réponses possibles. La seule façon d'en juger, est 
d'observer qui bénéficie et qui est lésé en reconnaissant un propriétaire au 
logiciel, pourquoi et dans quelle mesure. En d'autres termes, nous devrions 
en évaluer le pour et le contre pour la société dans son ensemble, en prenant 
en compte aussi bien la liberté individuelle que la production de biens 
matériels.

Dans cet article, je décrirai les effets d'avoir des propriétaires, et je 
montrerai que les résultats sont préjudiciables. Ma conclusion est que les 
programmeurs ont le devoir d'encourager les autres à partager, distribuer, 
étudier et améliorer les logiciels que nous écrivons : autrement dit, 
d'écrire des logiciels libres.(1)
Comment les propriétaires justifient leur pouvoir

Ceux-là, qui bénéficient du système actuel où les programmes sont 
propriétaires, proposent deux arguments en leur faveur : 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 de possession quand ça les arrange; cen'est pas 
inévitable. Considérez, par exemple, comment ces mêmes programmeurs cèdent 
volontiers leurs droits à une grosse entreprise moyennant salaire ; 
mystérieusement, l'attachement affectif disparaît. Faites le contraste avec 
ces grands artistes et artisans des temps médiévaux, qui ne signaient même 
pas de leur nom leurs travaux. Pour eux, le nom de l'artiste n'avait pas 
d'importance. Ce qui importait, c'était que le travail, et son but afférent, 
aient été faits. Cette façon de voir à 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'écrirade programmes. Et 
vous serez coincés, car 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 propriétaire et celle où il n'y a pas de programme, pour alors 
conclure que le développement de logiciels propriétaires est, globalement, 
bénéfique et qu'il devrait être encouragé. L'erreur, ici, vient de ne 
comparer que deux résultats — logiciel propriétaire contre pas de logiciel — 
et de supposer qu'il n'y a pas d'autres possibilités.

Dans un système reconnaissant la propriété intellectuelle, 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 d'un programme propriétaire ou pas de programme. Cependant, ce 
lien n'est pas inhérent ou inévitable; c'est une conséquence d'une décision 
politique, légale et sociale spécifique, que nous contestons : la décision 
qu'il y ait des propriétaires. Formuler le choix entre logiciel propriétaire 
contre pas de logiciel, c'est faire une pétition de principe.
L'argument contre le fait qu'il y ait des propriétaires

La question qu'il faut poser, c'est : « Est-ce que le développement de 
logiciels doit être lié à un propriétaire qui en restreint l'usage ? »

Pour pouvoir en décider, il nous faut juger chaque effet des deux activités 
suivantes sur la société, indépendamment : l'effetdu développement de 
logiciels (indépendamment de ses termes de diffusion), et l'effet de la 
restriction de son emploi (supposant que le logiciel ait été développé). Si 
l'une de ces activités est utile et l'autre nocive, nous devrions les 
dissocier et nous lancer uniquement dans la première.

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 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. 
propriétaire) avec le même programme, mais disponible pour tout le monde. Ce 
qui signifie comparer deux mondes possibles.

Cette analyse met aussi en exergue le simple contre-argument qui est parfois 
soulevé que « le bénéfice pour le voisin en lui donnant unecopie d'un 
logiciel est annulé par le préjudice fait au propriétaire ». Ce 
contre-argument suppose que les inconvénients et bénéfices sont équivalents 
dans leur ampleur. L'analyse implique de comparer ces étendues et elle montre 
que les bénéfices sont bien plus importants.

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

Il serait possible de financer la contruction de toutes les routes avec des 
péages. Ce qui entraînerait 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, le péage n'est qu'une entrave artificielle à la fluidité du 
trafic, artificielle dans le sens où elle n'est pas une conséquence du 
fonctionnement des routes et des voitures.

Si on compare les routes avec ou sans péage, nous voyons que (si tout se 
déroule normalement) les routes sans péage sont meilleur marché à construire 
et à maintenir, plus sûres et plus efficaces à emprunter. (2) Dans les pays 
pauvres, les postes de péage rendent les routes inaccessibles à bien des 
citoyens. Les routes sans péage offrent ainsi plus de bénéfices à moindre 
coût ; elles sont préférables pour la société. C'est pourquoi la société 
devrait trouver d'autres moyens de financer les routes, sans recourir aux 
péages. L'usage des routes, une fois construites, devrait être libre.

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 elles 
occasionnent aussi autre chose : elles dégradent les routes. La route à péage 
n'est pas aussi bonne que celle sans péage; nous donner plus de routes ou 
supérieures sur le plan technique, n'est peut-être pas une amélioration si 
cela signifie substituer aux routes gratuites des routes à péage.

Bien entendu, construire des routes sans péage coûte de l'argent, que, d'une 
façon ou d'une autre, le public doit payer. Mais ce n'est pas ce qui, 
inévitablement, implique des postes de péage. Nous, qui dans un cas comme 
dans l'autre, devrons payer, aurons tout intérêt pour notre porte-monnaie à 
acheter 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 — mais ce 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 est plus avantageux de 
lever des fonds de façon moins obstructive.

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, plus cher 
à distribuer et moins satisfaisant et efficace à utiliser. Je poursuivrai en 
disant que la construction du programme devra ê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).
Le tort fait en entravant le logiciel

Considérez un instant un programme qui a été développé et dont tous les 
financements nécessaires à son élaboration ont été pris ; maintenant, la 
société doit faire le choix entre le rendre propriétaire ou le rendre libre 
d'utilisation et de partage. Supposezqu'il est désiré que ce programme existe 
et soit disponible.(3)

Les restrictions sur la distribution et la modification du programme ne 
facilitent pas son utilisation. Elles ne peuvent qu'interférer. Ainsi, 
l'effet ne peut avoir qu'un impact négatif. Mais jusqu'à quel point ? Et de 
quelle manière ?

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

    * Moins de gens utilisent le programme.
    * Aucun des utilisateurs ne peut adapter ou corriger le programme.
    * Les autres développeurs ne peuvent rien apprendre du programme ou 
encore démarrer un nouveau travail en se basant dessus.

Chaque niveau de préjudice matériel est concomitant à un préjudice 
psycho-social. Cela se réfère aux effets qu'ont les décisions des gens sur 
leurs sentiments, attitudes et prédispositions futurs. Ces changements dans 
la façon de penser des gens auront par la suite un effet sur leurs relations 
avec leurs concitoyens et peuvent avoir des conséquences matérielles.

Les trois niveaux de préjudice matériel gaspillent une partie de la valeur 
que le programme pourrait offrir, mais ne peuvent la réduire à zéro. S'ils 
gaspillent 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 sûrement un net bénéfice matériel direct.

Cependant, tenant compte des préjudices psycho-sociaux concomitants, il n'y a 
pas de limite au préjudice que peut provoquer le développement d'un logiciel 
propriétaire.
L'entrave à l'utilisation de programmes

Le premier niveau de préjudice gêne le simple emploi d'un programme. Une 
copie d'un programme a pratiquement un coût marginal 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 taxe via une 
licence est un découragement significatif à l'utilisation d'un programme. Si 
un logiciel largement utile est propriétaire, 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 d'outrepasser l'utilisation 
du programme, cela causedu tort à cette personne sans que quelqu'un y trouve 
son compte. La somme de nombres négatifs avec zéro, ça doit être négatif.

Mais cela ne réduit pas la somme de travail qu'il faut pour développer le 
programme. Donc l'efficacité du processus, calculée en divisant la 
satisfaction des utilisateurs par le coût du développement, en est diminuée.

Ceci reflète la différence cruciale entre la copie de programmes et celle de 
voitures, de chaises ou de sandwiches. À 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 gros effort. Ce qui n'est pas vrai dans le cas des 
objets matériels, vu que la matière est conservée : chaque copie nécessite 
des matières premières, tout comme la première.

En ce qui concerne les objets matériels, décourager leur usage est logique, 
car moins d'objets signifie moins de matières premières, moins de travail 
pour les construire. C'est vrai qu'il faut un coût pour démarrer, pour 
développer, coût réparti sur l'ensemble de la production. Mais tant que le 
coût marginal est significatif, y ajouter un pourcentage des coûts de 
développement ne provoque pas de différence qualitative. Et cela ne nécessite 
pas de restrictions sur la liberté des utilisateurs.

Cependant, imposer un prix à quelque chose qui, autrement, aurait pu être 
gratuit, c'est un changement qualitatif. Une taxe imposée, centralisée, sur 
la distribution de logiciels devient fortement décourageante.

De plus, la production centrale, telle qu'elle est pratiquée de nos jours, 
est inefficace, y compris dans son rôle de fournisseur de copies de 
logiciels. Ce système implique d'empaqueter des disquettes ou des bandes dans 
un emballage superflu, de les envoyer en nombre 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 
causé par la présence d'un propriétaire.
Endommager la cohésion sociale

Supposons que vous et votre voisin trouviez utile de faire tourner un certain 
programme. Dans un souci moral pour votre voisin, vous devriez sentir que la 
façon correcte d'appréhender la situation, est de permettre une utilisation 
de ce logiciel par vous deux. S'il n'y avait la possibilité que pour un seul 
d'entre vous de faire tourner ceprogramme, il y aurait division ; ni vous, ni 
votre voisin ne trouveriez cela acceptable.

Signer un accord de licence logicielle typique revient à trahir votre voisin 
: « je fais la promesse de priver mon voisin de ce programme, ainsi je peux 
en avoir une copie pour moi-même ». Les gens qui font de tels choix 
ressentent une pression psychologique interne pour se justifier, en diminuant 
l'importance d'aider leur voisin — c'est comme cela que le sens civique 
souffre. C'est un préjudice psycho-social associé au préjudice matériel de 
décourager l'utilisation du logiciel.

Beaucoup d'utilisateurs reconnaissent inconsciemment le tort de refuser le 
partage ; 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 psycho-social, mais on peut y échapper en 
prenant la décision que ces licences et ces lois n'ont pas de force morale.

Les programmeurs souffrent aussi de préjudices psycho-sociaux, sachant que 
bien des usagers ne pourront utiliser leurs travaux. Ceci conduit à une 
attitude de cynisme ou de dénégation. Un programmeur peut faire une 
description enthousiaste du travail qu'il pense techniquement excitant; 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 il ignore ce fait la plupart du temps, soit il adopte une 
attitude cynique afin d'en minimiser l'importance.

Depuis la période reaganienne, la plus grande pénurie, aux États-Unis, ce 
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.
L'entrave à 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 sur les 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 que vous pouvez exécuter 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 afin que le logiciel exécute autre chose.

Normalement, les programmeurs travaillent sur le « code source » d'un 
programme, écrit dans un langage de programmation comme le Fortran oule C. 
Ils utilisent des noms pour désigner les données utilisées et des parties du 
programme, et ils représentent les opérations par des symboles comme le « + » 
pour une opération 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);
     }

Voici le même programme sous sa forme exécutable, sur l'ordinateur que 
j'utilise habituellement :

     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) pour chaque utilisateur 
d'un programme. Mais la plupart des utilisateurs n'ont pas la permission 
d'avoir des copies du code source. Normalement, le code source d'un programme 
propriétaire est tenu secret par son propriétaire, empêchant quiconque d'en 
apprendre 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 dit qu'elle travaillait comme programmeur dans une 
banque depuis environ six mois, écrivant un programme similaire à quelque 
chose de commercialement disponible. Elle croyait que, si elle avait accès au 
code source de ce programme commercial, elle pourrait facilement l'adapter à 
ses besoins. La banque souhaitait payer pour cela, mais elle n'y fut pas 
autorisée — le code source était un secret. Elle a dû alors travailler 
d'arrache-pied pendant six mois, un travail qui compte pour le PNB, mais qui 
était en fait du gaspillage.

Le Laboratoire d'Intelligence Artificielle du MIT reçut une imprimante 
graphique comme cadeau de la part de Xerox, aux alentours de 1977. Elle était 
pilotée par un logiciel libre, auquel nous avons ajouté de nombreuses 
caractéristiques 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'I.A. une nouvelle imprimante, plus rapide, 
une des premières laser. Elle était pilotée par un logiciel propriétaire 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 
message quand le travail d'impression se lançait sur le poste dédié, mais pas 
quand celui-ci se faisait effectivement (et les délais étaient habituellement 
importants). Il n'y avait aucun moyen de savoir si l'impression était faite; 
il fallait deviner. Et personne n'était informé d'un bourrage papier, 
l'imprimante attendait ainsi souvent une heure avant d'être rechargée.

Les programmeurs système du labo d'I.A. é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 psycho-social — 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 gagner d'autres aspects de la vie. Les gens qui se 
sentent ainsi ne sont pas heureux et ne font pas du bon travail.

Imaginez ce que ce serait si les recettes étaient logées à la même enseigne 
que les logiciels. Vous vous diriez « Voyons, comment modifiercette recette 
pour qu'il n'y ait plus de sel ? », et le chef cuistot 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 le jugement pour changer ma recette 
afin qu'elle marche mieux ».

«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 50000 
dollars». À partir du moment où le propriétaire a le monopole sur 
lesmodifications, les honoraires tendent à gonfler. « De toute façon, je n'ai 
pas le temps maintenant. Je suis pris par une commission afin de créer une 
nouvelle recette de biscuits marins pour le Département de la Marine. Je 
reprendrai contact avec toi d'ici à peu près deux ans ».
L'entrave au développement logiciel

Le troisième niveau de préjudice matériel touche le développement logiciel. 
Il é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 auront été « cannibalisées » pour créer les prémices d'autres 
programmes.

L'existence de propriétaires empêche ce genre d'évolution, rendant nécessaire 
de repartir de rien si 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 entravent aussi l'éducation, l'apprentissage. J'ai 
rencontré de brillants étudiants en informatique qui n'avaient jamais vu le 
code source d'un gros logiciel. Ils peuvent être bons à écrire de courts 
programmes, mais ils ne peuvent commencer à apprendre les techniques 
différentes de l'écriture d'un vaste programme, s'ils ne peuvent observer 
comment d'autres l'ont fait.

Dans tout domaine intellectuel, on peut atteindre de plus grandes hauteurs en 
se tenant sur les épaules des autres. Mais ce n'est généralement plus permis 
dans le domaine logiciel — vous ne pouvez vous tenir sur les épaules que de 
ceux qui font partie de votre propre compagnie.

Le préjudice psycho-social 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 les 
océanographes japonais, abandonnant leur labo dans une île du Pacifique, ont 
soigneusement conservé leurs travaux pour les Marines qui commençaient à 
débarquer, et laissèrent un mot leur demandant d'en prendre bien soin.

Les conflits de 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, qui permettraient aux 
autres de reproduire leur expérience. Ils ne publient que ce qui permet au 
lecteur d'être impressionnés 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.
Peu importe comment le partage est restreint

J'ai parlé des effets d'empêcher les gens de copier, de modifier ou de se 
baser sur un programme existant. Je n'ai pas précisé comment cette 
obstruction était réalisée, car cela n'affecte pas la conclusion. Que ce soit 
par protection contre la copie, copyright, licences, cryptage, 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 considèrent certaines de ces méthodes comme plus odieuses 
que d'autres. Je suggère que les méthodes les plus détestées sont celles qui 
accomplissent leur objectif.
Les logiciels devraient être libres

J'ai montré comment le fait d'être propriétaire d'un programme, le pouvoir de 
restreindre sa modification ou sa copie, est une entrave. Ses retombées 
négatives sont vastes et importantes. Il s'ensuit que la société devrait se 
passer de propriétaires de logiciels.

Une autre façon de comprendre cela, est que ce dont a besoin la société, 
c'est de logiciels libres et que les logiciels propriétaires ne sont qu'un 
pauvre substitut. Encourager le substitut n'est pas une façon rationnelle 
d'obtenir ce dont nous avons besoin.

Vaclav Havel nous a conseillé de «travailler pour une chose parce qu'elle est 
bien, pas parce qu'elle a des chances de réussir». Un marché créant des 
logiciels propriétaires a des chances de réussir selon son propre point de 
vue, mais ce n'est pas ce qui est bon pour la société.
Pourquoi les gens développeront des logiciels

Si nous éliminons la propriété intellectuelle comme un moyen d'encourager les 
gens à développer des logiciels, au début, peu 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 malgré tout l'augmenter, il y a d'autres moyens d'encourager le 
développement, tout comme il y a des alternatives aux postes de péage pour 
tirer del'argent des routes. 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 
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 fascination ou à cause de sa valeur perçue 
pour la société. On peut y inclure par exemple, les mathématiques logiques, 
la musique classique et l'archéologie; puis l'organisation politique au sein 
des travailleurs. Les gens concourent, plus tristement qu'âprement, pour les 
quelques situations assises disponibles, aucune d'entre elles n'étant 
vraiment bien solide. Ils paieraient pour avoir la chance de travailler dans 
un de ces domaines, s'ils le pouvaient.

Un 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 demanderont de fortes sommes 
d'argent pour ce qu'ils avaient l'habitude de faire pour le plaisir. Puis 
quelques années passent, chaque personne en relation avec ce domaine tournera 
en dérision l'idée que le travail pourrait être fait sans salaires 
mirobolants. Ils conseilleront aux acteurs sociaux de s'assurer que de tels 
salaires soient possibles, en prescrivant des privilèges spéciaux et les 
pouvoirs, monopoles nécessaires pour que cela puisse se faire.

Ce changement est apparu dans le domaine de la programmation cette dernière 
décennie. Il y a quinze ans, des articles parlaient d'« accros à 
l'informatique » : les utilisateurs étaient « connectés » et vivaient 
modestement. Il était généralement compris que les accros de la programmation 
pouvaient briser leur couple. Aujourd'hui, il est généralement admis que 
personne ne ferait de la programmation, sans salaire élevé. Les gens ont 
oublié ce qu'ils savaient il y a quinze ans.

Même si à un moment précis, la plupart des gens travailleront dans un certain 
domaine uniquement pour un haut salaire, cela ne durera pas forcément. La 
tendance peut s'inverser, si la société donne une impulsion. Si nous laissons 
de côté les possibilités de gros gains, peu de temps après, quand les gens 
auront réajusté leurs attitudes, ils auront à nouveau à coeur de travailler 
dans leur domaine pour la joie de le faire.

La question « comment payer un programmeur » devient plus simple, quand nous 
réalisons que ce n'est pas la peine de les payer une fortune. Il est plus 
facile de leur assurer un niveau de vie correct sans plus.
Financer le logiciel libre

Les institutions qui payent les programmeurs n'ont pas besoin d'être des « 
boîtes à logiciels ». Beaucoup d'autres institutions existantespeuvent le 
faire.

Les constructeurs de matériels informatiques pensent qu'il est essentiel de 
supporter le développement logiciel, même s'ils ne peuvent contrôler l'usage 
du logiciel. En 1970, la plupart de leurs logiciels étaient libres, car ils 
ne pensaient pas à les entraver. Aujourd'hui, la volonté croissante de se 
joindre à desconsortiums montre leur compréhension que de posséder le 
logiciel n'est pas ce qui est vraiment important pour eux.

Les universités mènent de nombreux projets de programmation. Aujourd'hui, 
elles en vendent souvent les résultats, mais, dans les années 70, elles ne le 
faisaient pas. Douterait-on que les universités développeraient des logiciels 
libres si elles n'étaient pas autorisées à vendre des logiciels ? Ces projets 
pourraient recevoir le soutien de contrats gouvernementaux et de bourses qui 
soutiennent actuellement le développement de logiciels propriétaires.

Il est commun de nos jours que les chercheurs universitaires reçoivent une 
bourse pour développer un système, qu'ils le développent presque jusqu'à la 
finalisation, qu'ils le déclarent «fini», puis qu'ils créent des sociétés où 
ils le finiront effectivement et le rendrontutilisable. Parfois, ils 
déclarent «libre» la version non terminée; s'ils sont vraiment corrompus, ils 
obtiendront une licence exclusive de la part de l'université. Ce n'est pas un 
secret, c'est ouvertement admis par les personnes concernées. Pourtant, si 
les chercheurs n'étaient pas exposés à ces tentations, ils continueraient 
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 reçu des honoraires pour le 
portage du compilateur GNU C sur un nouveau matériel et pour faire des 
extensions d'interfaces utilisateurs pour GNU Emacs. (J'ai offert ces 
améliorations au public, une fois qu'elles ont été réalisées). Je suis aussi 
payé pour enseigner dans des classes.

Je ne suis pas seul à travailler de cette façon; il existe maintenant une 
entreprise fructueuse, grandissante qui ne fait pas autrement. Plusieurs 
autres compagnies offrent aussi un support commercial aux logiciels libres 
issus du système GNU. C'est le début d'une industrie indépendante du support 
du logiciel libre, uneindustrie qui pourrait prendre de fortes proportions, 
si le logiciel libre devenait courant. Elle offre aux utilisateurs des 
options qui sont généralement indisponibles dans le cas de logiciels 
propriétaires, sauf pour les plus riches.

De nouvelles institutions, comme la Free Software Foundation, peuvent aussi 
financer les programmeurs. La majorité des fonds de la Fondation vient de 
l'argent récolté dans la vente de bandes 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 libre, et 
non gratuit). Certains utilisateurs achètent des bandes, alors qu'ils en 
possèdent déjà, 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 dépensés en employant le plus possible de programmeurs. Si elle avait 
été érigée en business, distribuant les mêmes logiciels libres au public pour 
la même somme, elle pourrait maintenant offrir un très bon niveau de vie à 
son fondateur.

Parce que la Fondation est une organisation caritative, les programmeurs 
travaillent souvent pour la moitié de 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 que leur travail pourra être utilisé 
par tous. Et, par-dessus tout, ils le font parce que programmer, c'est 
passionnant. Ajoutons que des volontaires nous ont écrit nombre de programmes 
(même des rédacteurs techniques ont récemment commencé à se proposer).

Ce qui confirme que la programmation est parmi les 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.
Que doivent les utilisateurs aux programmeurs ?

Il y a une bonne raison à ce que les utilisateurs de logiciels se sentent 
obligés moralement à contribuer à leur soutien. Les développeurs de logiciels 
libres contribuent à l'activité des utilisateurs, c'est à la fois loyal et — 
sur le long terme — aussi dans l'intérêt des utilisateurs que de les financer.

Cependant, ceci ne s'applique pas aux développeurs de logiciels 
propriétaires, vu que l'obstructionnisme appelle plutôt une sanction qu'une 
récompense.

Nous nous trouvons ainsi face à un paradoxe : le développeur de logiciels 
utiles 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 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 cela est mauvais pour la 
société, car ceux qui restent produisent plus de nourriture pour les 
consommateurs que tous ceux, plus nombreux, jadis. 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 large de chaque programme développé.
    * La possibilité d'adapter un programme existant pour le personnaliser au 
lieu de repartir de zéro.
    * Une meilleure instruction des programmeurs.
    * L'élimation des redondances dans l'effort de développement.

Ceux qui font objection à la coopération dans la mesure où elle diminuerait 
l'emploi des programmeurs 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é générale de tout développement logiciel ou la productivité de 
projets individuels. La productivité générale, 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 focalisent 
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 se mettent en concurrence, 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.

Il y a plusieurs façons de concourir. La compétition peut se présenter comme 
essayer d'aller plus loin, comme surpasser ce que d'autres ont déjà réalisé. 
Par exemple, jadis, il y avait concurrence entre les meilleurs programmeurs, 
afin que l'ordinateur fasse les choses les plus incroyables possible, ou 
encore à qui écrira le programme le plus court, le plus rapide pour une tâche 
donnée. Ce genre de compétition est bénéfique pour tous, tant que l'esprit de 
saine émulation est maintenu.

Une compétition constructive est suffisante pour pousser les gens à de grands 
efforts. Certains concourent pour être les premiers à 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 que leurs rivaux soient 
échoués une île déserte. Ils se satisfont de laisser le meilleur gagner.

La compétition devient un combat quand les participants commencent à entraver 
les autres plutôt que de progresser eux-mêmes — c'est-à-dire quand le « que 
le meilleur gagne »fait la place au « laissez-moi gagner, que je sois le 
meilleur ou non ». Le logiciel propriétaire est nocif, non parce qu'il est 
une forme de compétition, mais parce qu'il est une forme de combat au sein 
des citoyens de notre société.

La compétition dans les affaires n'est pas forcément un combat. Par exemple, 
lorsque deux épiceries sont en compétition, tout leur effort tend vers 
l'amélioration de leurs propres services, pas à saboter leur rival. Mais ce 
n'est pas ce qui démontre un engagement moral dans les affaires; plutôt qu'il 
existe une faible zone de combat dans ce genre de business, à la limite de la 
violence physique. Tous les domaines des affaires ne partagent pas cette 
caractéristique. La rétention d'information utile à tous, c'est une forme de 
combat.

L'idéologie, dans les affaires, ne prépare pas les gens à résister à la 
tentation de combattre, dans une compétition. Certaines formes de combat ont 
été interdites avec les lois anti-trusts, l'interdiction de la publicité 
mensongère, etc., mais plutôt que de généraliser le rejet du combat, les 
dirigeants inventent en général d'autres formes de combat qui ne sont pas 
spécifiquement prohibées. Les ressources de la société sont gaspillées 
économiquement, à l'instar d'une guerre civile entre factions.
« Pourquoi n'irais-tu pas en Russie ? »

Aux États-Unis, toute personne favorable à autre chose que le plus flagrant 
laissez-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, comme 
on en trouve dans les autres nations industrialisées. Ou encore à propos des 
partisans d'un soutien public des arts, tout aussi universel chez les nations 
avancées. L'idée que les citoyens aient une quelconque obligation de 
participer au bien public est considérée comme du communisme, aux États-Unis. 
Mais ce terme est-il bien approprié ?

Le communisme, comme il était pratiqué en Union Soviétique, était un système 
de contrôle centralisé, où toutes les activités étaient passées au crible du 
régime, soi-disant pour le bien public, mais en fait pour le bien des membres 
du Parti Communiste. Système où les appareils permettant les copies étaient 
étroitement gardés, pour empêcher les copies illégales.

Le système américain de la propriété intellectuelle exerce un contrôle 
central sur la distribution d'un programme et surveille les copieurs grâce à 
des systèmes automatiques de protection contre la copie, pour empêcher les 
copies illégales.

Par opposition, je travaille à bâtir un système où les gens sont libres de 
décider de leurs propres actions; en particulier, libres d'aider leur voisin, 
de modifier et d'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 on doit juger ces points de vue par leurs ressemblances au 
communisme soviétique, alors ce sont les propriétaires de logiciels qui sont 
les communistes.
La question des prémisses

Je fais la supposition, dans cet article, que l'utilisateur d'un logiciel 
n'est pas moins important qu'un auteur ou même 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 acceptée. Beaucoup maintiennent que 
l'employeur d'un auteur est fondamentalement plus important que n'importe qui 
d'autre. Ils disent, par exemple, que le but, d'avoir des propriétaires de 
logiciels, est de donner à l'employeur les avantages qui lui sont dûs — 
indépendamment de l'effet sur le public.

Cela ne sert à rien de prouver ou non ces prémisses. Prouver demande des 
prémisses partagées. C'est pourquoi la majorité de mon discourss'adresse à 
ceux qui partagent les prémisses que j'utilise, ou qui, au moins, sont 
intéressés par leurs conséquences. Pour ceux qui croientque 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 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 légales de la société 
américaine. Il y a des gens qui pensent que douter de la prémisse, c'est 
défier les bases de la société.

Il est important pour ces gens de savoir que cette prémisse ne fait pas 
partie de notre tradition légale. Ne l'a jamais été.

Ainsi, la Constitution dit que le but du copyright est de « promouvoir le 
progrès des sciences et des arts utiles ». La cour Suprême l'a élaboré ainsi, 
énonçant dans la « 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 bénéfices que retire le public du travail des auteurs ».

Nous ne sommes pas obligés d'approuver la Constitution ou la Cour Suprême (il 
fut un temps où les deux ont 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 la conscience qu'il s'agit d'une supposition de la droite radicale, 
plutôt que d'une tradition reconnue, affaiblira son intérêt.
Conclusion

Nous aimons penser que notre société encourage à aider son voisin ; mais 
chaque fois que nous récompensons quelqu'un pour son obstructionnisme ou que 
nous l'admirons pour les richesses qu'il a accumulé ainsi, nous renvoyons le 
message contraire.

La thésaurisation de logiciels est un exemple de notre volonté d'ignorer le 
bien-être de la société pour le gain personnel. On peut en voir la trace 
depuis Ronald Reagan jusqu'à Dick Cheney, depuis Exxon à Enron, en passant 
par les échecs des banques et des écoles. Nous pouvons la mesurer à l'aune 
des sans-abri et de la population dans les prisons. 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 qu'un bon citoyen est un 
citoyen qui coopère quand il le faut, que ce n'est pas celui qui réussit en 
volant les 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 et se nourrira la coopération volontaire.
Notes

   1. Le mot « free » dans « free software » signifie libre, et non gratuit 
[free désigne les deux termes, en anglais] ; le prix payé pour une copie d'un 
programme libre peut être nul, faible, ou (rarement) assez é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 des 
ventes 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.

Cet essai est publié dans Free Software, Free Society: The Selected Essays of 
Richard M. Stallman

Pourquoi les logiciels devraient être libres

par Richard Stallman

(Version du 24 avril 1992)
Introduction

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

Les développeurs de logiciels considèrent 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 : 
c'est-à-dire qu'un programme a un propriétaire, en général une société 
associée à son développement.

J'aimerais considérer la même question en utilisant un critère différent : la 
prospérité et la liberté du public en général.

La loi actuelle ne permet pas de décider en faveur de cette réponse — la loi 
devrait se conformer à l'éthique, pas l'inverse. La pratique actuelle ne 
résoud pas plus la question, bien qu'elle puisse suggérer des réponses. La 
seule façon dont on peut 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 devrions 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 sont préjudiciables. Ma conclusion est que les 
programmeurs ont le devoir d'encourager les autres à partager, distribuer, 
étudier et améliorer les logiciels que nous écrivons : 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 va comme suit : « 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 de leur nom leurs travaux. 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 propriétaire et pas de programme du tout, pour alors conclure que 
le développement de logiciels propriétaires est, globalement, bénéfique et 
qu'il devrait être encouragé. L'erreur, ici, vient de ne comparer que deux 
résultats — logiciel propriétaire contre pas de logiciel — et de supposer 
qu'il n'y a pas d'autres possibilités.

Dans un système reconnaissant la propriété intellectuelle, 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 propriétaire ou pas de programme. Cependant, 
ce lien n'est pas inhérent ou inévitable; c'est une conséquence d'une 
décision politique, légale et sociale spécifique, que nous contestons : la 
décision qu'il y ait des propriétaires. Formuler le choix entre logiciel 
propriétaire contre pas de logiciel, c'est faire une pétition de principe.

L'argument contre le fait qu'il y ait des propriétaires

La question qu'il faut poser, c'est : « Est-ce que le développement de 
logiciels doit être lié à un propriétaire qui en restreint l'usage ? »

Pour pouvoir en décider, il nous faut juger l'effet que chacune de ces 
activités a sur la société, indépendamment l'une de l'autre : l'effet du 
développement de logiciels (indépendamment des conditions de sa diffusion), 
et l'effet de la restriction de son emploi (supposant 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 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. 
propriétaire) avec le même programme, mais disponible pour tout le monde. Ce 
qui signifie comparer deux mondes possibles.

Cette analyse met aussi en exergue le simple contre-argument qui est parfois 
soulevé que « le bénéfice pour le voisin en lui donnant une copie d'un 
logiciel est annulé par le préjudice fait au propriétaire ». Ce 
contre-argument suppose que les inconvénients et bénéfices sont équivalents 
dans leur ampleur. Notre analyse implique de comparer l'ampleur de chacun et 
elle montre que les bénéfices sont bien plus importants que les inconvénients.

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

Il serait possible de financer la contruction de toutes les routes avec des 
péages. Ce qui entraînerait 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, le péage n'est qu'une entrave artificielle à la fluidité du 
trafic, artificielle dans le sens où elle n'est pas une conséquence du 
fonctionnement des routes et des voitures.

Si on compare les routes avec ou 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) Dans les pays 
pauvres, les postes de péage rendent les routes inaccessibles à bien des 
citoyens. Les routes sans péage offrent ainsi plus de bénéfices à moindre 
coût ; elles sont préférables pour la société. C'est pourquoi la société 
devrait trouver d'autres moyens de financer les routes, sans recourir aux 
péages. L'usage des routes, une fois construites, devrait être libre.

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 elles 
occasionnent aussi autre chose : elles dégradent la valeur des routes. La 
route à péage n'est pas aussi avantageuse que celle sans péage; 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 gratuites 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 autre. Toutefois, ce fait n'implique pas 
l'inévitabilité des postes de péage. 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 — mais ce 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 est plus avantageux de 
lever des fonds de façon moins obstructive.

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, plus cher 
à 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).

Le tort fait en entravant le logiciel

Considérez un instant un programme qui a été développé et dont tous le 
financement nécessaire à son élaboration a été effectué ; maintenant, la 
société doit faire le choix entre le rendre propriétaire ou le rendre libre 
d'utilisation et de partage. Supposez que l'existence et la disponibilité de 
ce programme soit souhaitable.(3)

Les restrictions sur la distribution et la modification du programme ne 
facilitent pas son utilisation. Elles ne peuvent qu'interférer. Donc, son 
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'entrave :

    * Moins de gens utilisent le programme.
    * Aucun des utilisateurs ne peut adapter ou corriger le programme.
    * Les autres développeurs ne peuvent rien apprendre du programme et il 
est impossible de commencer un nouveau projet en se basant dessus.

Chaque niveau de préjudice matériel a un préjudice psycho-social concomitant. 
Cela renvoie aux effets que les décisions des gens ont sur leurs sentiments, 
attitudes et prédispositions futurs. Ces changements dans la façon de penser 
des gens auront par la suite un effet sur leurs relations avec leurs 
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 sûrement un net bénéfice matériel direct.

Cependant, tenant compte des préjudices psycho-sociaux concomitants, il n'y a 
pas de limite au préjudice que peut provoquer le développement d'un logiciel 
propriétaire.

Entraver l'utilisation des programmes

Le premier niveau de préjudice gêne le simple emploi d'un programme. Une 
copie d'un programme a pratiquement un coût marginal 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 taxe via une 
licence est un découragement significatif à l'utilisation d'un programme. Si 
un logiciel largement utile est propriétaire, 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 quelqu'un y trouve 
son compte. La somme de nombres négatifs avec zéro, ça doit être négatif.

Mais cela ne réduit pas la somme de travail qu'il faut 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 les copies des programmes et celles 
des voitures, des chaises ou des sandwiches. À 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, vu que la matière est conservée : chaque copie nécessite 
des matières premières, tout comme la première.

En ce qui concerne les objets matériels, décourager leur usage est logique, 
car moins d'objets signifie moins de matières premières, moins de travail 
pour les construire. C'est vrai qu'il y a un coût de démarrage 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.

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

De plus, la production centrale, telle qu'elle est pratiquée de nos jours, 
est inefficace, même comme moyen d'effectuer la livraison de 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.

Nuire à la cohésion sociale

Supposons que vous et votre voisin trouviez utile de faire fonctionner un 
certain programme. Par souci d'éthique envers votre voisin, vous devriez 
estimer convenable d'utiliser ce logiciel tous les deux. Proposer de ne 
permettre qu'à un seul d'entre vous d'utiliser le programme, tout en 
restreignant son usage par l'autre, entraînerait la division ; ni vous, ni 
votre voisin ne trouveriez cela acceptable.

Signer un contrat type de licence d'utilisation d'un logiciel en revient à 
trahir votre voisin : « Je fais la promesse de priver mon voisin de ce 
programme de sorte que je puisse en avoir une copie 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 psycho-social associé au préjudice 
matériel de décourager l'utilisation du logiciel.

Beaucoup d'utilisateurs reconnaissent inconsciemment le tort qu'entraîne le 
fait de refuser le partage ; 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 psycho-social, 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éjudices psycho-sociaux, 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 du 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 il ignore ce fait la 
plupart du temps, 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.

Entraver 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 que vous pouvez exécuter 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 des 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);
     }

Voici le même programme sous sa forme exécutable, sur l'ordinateur que 
j'utilise habituellement :

     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) pour chaque utilisateur 
d'un programme. Mais la plupart des utilisateurs n'ont pas la permission 
d'avoir des copies du code source. Normalement, le code source d'un programme 
propriétaire est tenu secret par son propriétaire, empêchant quiconque d'en 
apprendre 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 programmeur 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. Elle a donc 
dû travailler d'arrache-pied pendant six mois, sur un travail qui compte pour 
quelque chose dans le PNB, mais qui était en fait du gaspillage.

Le Laboratoire d'Intelligence Artificielle du MIT (labo d'I.A.) reçut une 
imprimante graphique comme cadeau de la part de Xerox, aux alentours de 1977. 
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'I.A. une nouvelle imprimante, plus rapide, 
une des premières laser. Elle était pilotée par un logiciel propriétaire 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 en cours d'impression (et les délais étaient 
habituellement importants). Il n'y avait aucun moyen de savoir si 
l'impression était terminée; il fallait deviner. Et personne n'était informé 
d'un bourrage papier, l'imprimante attendait ainsi souvent une heure avant 
d'être rechargée.

Les programmeurs système du labo d'I.A. é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 psycho-social — 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 se sentent ainsi 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 qu'il n'y ait plus de sel ? », et le chef cuistot 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 le jugement pour changer 
ma recette afin qu'elle marche mieux ».

« 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 sur les 
modifications, les honoraires tendent à gonfler. « De toute façon, je n'ai 
pas le temps maintenant. Je suis pris par une commande de créer une nouvelle 
recette de biscuits marins pour le Département de la Marine. Je reprendrai 
contact avec toi dans environ deux ans ».

Entraver le développement logiciel

Le troisième niveau de préjudice matériel touche le développement logiciel. 
Il é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 les prémices d'autres 
programmes.

L'existence de propriétaires empêche ce genre d'évolution, ce qui rend 
nécessaire de repartir à zéro si 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 entravent aussi l'éducation, l'apprentissage. J'ai 
rencontré de brillants étudiants en informatique qui n'avaient jamais vu le 
code source d'un gros logiciel. Ils peuvent être bons à écrire de courts 
programmes, mais ils ne peuvent commencer à apprendre les techniques 
différentes de l'écriture d'un vaste programme, s'ils ne peuvent observer 
comment d'autres l'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 — vous ne pouvez vous tenir sur les épaules que de 
ceux qui font partie de votre propre compagnie.

Le préjudice psycho-social 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, qui 
permettraient aux autres de reproduire leur expérience. Ils ne publient que 
ce qui permet au lecteur d'être impressionnés 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é des effets d'empêcher les gens de copier, de modifier ou de se 
baser sur un programme existant. Je n'ai pas précisé comment cette 
obstruction était réalisée, car cela n'affecte pas la conclusion. Que ce soit 
par une protection contre la copie, le droit d'auteur, les licences, le 
cryptage, 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 sans doute celles qui 
accomplissent leur objectif.

Les logiciels devraient être libres

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

Une autre façon de comprendre cela, est de considérer que ce dont a besoin la 
société, c'est de logiciels libres et que les logiciels propriétaires ne sont 
qu'un pauvre substitut. Encourager le substitut n'est pas une façon 
rationnelle d'obtenir ce dont nous avons besoin.

Vaclav Havel nous a conseillé de « travailler pour une chose parce qu'elle 
est bien, pas parce qu'elle a des chances de réussir ». Un marché créant des 
logiciels propriétaires a des chances de réussir sur la base de ses propres 
conditions étroites, 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 un 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 
tirer de l'argent des routes. 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 
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 fascination ou à cause de sa valeur perçue 
pour la société. On peut y inclure par exemple, les mathématiques logiques, 
la musique classique et l'archéologie; puis l'organisation politique au sein 
des travailleurs. Les gens concourent, plus tristement qu'âprement, pour les 
quelques postes rémunérés disponibles, dont aucun n'est vraiment bien payé. 
Ils paieraient pour avoir la chance de travailler dans un de ces domaines, 
s'ils le pouvaient.

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 demanderont de fortes 
sommes d'argent pour ce qu'ils avaient l'habitude de faire pour le plaisir. 
Lorsque quelques années se seront écoulées, tous ceux qui appartiendront au 
domaine tourneront en dérision l'idée que le travail puisse se faire sans 
salaires mirobolants. Ils conseilleront aux acteurs sociaux de s'assurer que 
de tels salaires soient possibles, en prescrivant des privilèges spéciaux et 
les pouvoirs et monopoles nécessaires pour que cela puisse se faire.

Ce changement est survenu dans le domaine de la programmation au cours de la 
dernière décennie. Il y a quinze ans, des articles parlaient d'« accrocs à 
l'informatique » : les utilisateurs étaient « connectés » et vivaient 
modestement. 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é. Les gens ont oublié ce qu'ils savaient il y a quinze ans.

Même si à un moment précis, il s'avère vrai que la plupart des gens ne 
veulent travailler dans un domaine que pour un haut salaire, il ne faut pas 
conclure qu'il en sera toujours ainsi. 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 quelques 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 collecter des fonds pour 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, la 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. Y a-t-il à douter que les universités 
développeraient des logiciels libres si elles n'étaient pas autorisées à 
vendre des logiciels ? Ces projets pourraient recevoir le soutien des mêmes 
contrats et subventions des gouvernements qui soutiennent actuellement le 
développement de logiciels propriétaires.

Il est commun 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 ensuite 
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 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 de telles choses, 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 reçu des honoraires pour le 
portage du compilateur C de GNU sur du nouveau matériel informatique et pour 
faire des extensions d'interface utilisateur pour GNU Emacs. (J'ai offert ces 
améliorations au public, une fois qu'elles ont été réalisées). Je suis aussi 
payé pour enseigner dans des classes.

Je ne suis pas seul à travailler de cette façon; il existe maintenant une 
entreprise fructueuse et grandissante qui ne fait que ce genre de travail. 
Plusieurs autres compagnies offrent aussi un support commercial aux logiciels 
libres issus du système GNU. C'est le début d'une industrie indépendante du 
support du 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 de 
logiciels propriétaires, sauf pour les plus riches.

De nouvelles institutions, comme la Free Software Foundation, peuvent aussi 
financer les programmeurs. La majorité des fonds de la Fondation vient de 
l'argent récolté dans 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 libre, et non gratuit). Certains utilisateurs achètent 
des bandes, alors qu'ils en possèdent déjà, 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 permettrait aujourd'hui un très bon niveau de 
vie à son fondateur.

Parce que 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 que leur travail pourra être utilisé 
par tous. Et, par-dessus tout, ils le font parce que programmer est un vrai 
plaisir. Ajoutons que des volontaires nous ont écrit nombre de programmes. 
(Même des rédacteurs techniques ont commencé à se porter volontaire).

Ce qui 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 logiciels libres 
contribuent aux activités des utilisateurs, il est est donc à la fois juste 
et — sur le long terme — aussi dans l'intérêt des utilisateurs de continuer 
de les financer.

Cependant, ceci ne s'applique pas aux développeurs de logiciels 
propriétaires, vu que l'obstructionnisme 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 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 cela 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 vaste de chaque programme développé.
    * La possibilité d'adapter un programme existant pour le personnaliser au 
lieu de repartir de zéro.
    * Une meilleure instruction des programmeurs.
    * L'élimination des efforts de développement en double.

Ceux qui font objection à la coopération dans la mesure où elle diminuerait 
l'emploi des programmeurs 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é générale de tout développement logiciel ou la productivité de 
projets individuels. La productivité générale, 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 qui réduisent la coopération. 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.

La compétition est-elle inévitable ?

Est-il inévitable que les gens se mettent en concurrence, 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.

Il y a plusieurs façons de faire concurrence. La compétition 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. Certaines personnes 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 à entraver 
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 propriétaire est nocif, 
non parce qu'il est une forme de compétition, mais parce qu'il 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 sont en compétition, tout leurs efforts tendent à 
l'amélioration de leurs propres services, pas au sabotage de l'entreprise 
rivale. Mais ce n'est pas ce qui démontre un engagement envers l'éthique dans 
les affaires; plutôt qu'il existe une faible zone de combat dans ce genre de 
business, mis à part la violence physique. Tous les domaines des affaires 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 
combattre dans une compétition. Certaines formes de combat ont été interdites 
avec les lois anti-trusts, l'interdiction de la publicité mensongère, etc., 
mais plutôt que de généraliser le rejet du combat, les dirigeants 
d'entreprises inventent en général d'autres formes de combat qui ne sont pas 
spécifiquement prohibées. Les ressources de la société sont gaspillées 
économiquement, à l'instar 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 
laissez-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, comme 
on en trouve dans les autres nations industrialisées. Ou encore à propos des 
partisans d'un soutien public des arts, tout aussi universel chez les nations 
développées. L'idée que les citoyens aient une quelconque obligation de 
participer au bien public est considérée comme du communisme, aux États-Unis. 
Mais jusqu'à quel point ces idées sont-elles semblables ?

Le communisme, comme il était pratiqué en Union Soviétique, était un système 
de contrôle centralisé, où toutes les activités étaient passées au crible du 
régime, soi-disant pour le bien public, mais en fait pour le bien des membres 
du Parti Communiste. Système où les appareils permettant les copies étaient 
étroitement gardés, pour empêcher les copies illégales.

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 copieurs grâce à 
des systèmes automatiques de protection contre la copie, pour empêcher les 
copies illégales.

Par opposition, je travaille à bâtir un système où les gens sont libres de 
décider de leurs propres actions; en particulier, libres d'aider leur voisin, 
de modifier et d'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 on doit juger ces points de vue par leurs ressemblances au 
communisme soviétique, alors ce sont les propriétaires de logiciels qui sont 
les communistes.

La question des prémisses

Je fais la supposition, dans cet article, que l'utilisateur d'un logiciel 
n'est pas moins important qu'un auteur ou même 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 maintiennent que 
l'employeur d'un auteur est fondamentalement plus important que n'importe qui 
d'autre. Ils disent, par exemple, que le but, d'avoir des propriétaires de 
logiciels, est de donner à l'employeur les avantages qui lui sont dûs — 
indépendamment 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 
majorité de mon discours s'adresse à ceux qui partagent les prémisses que 
j'utilise, ou qui, au 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 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 légales de la société 
américaine. Il y a des gens qui pensent que douter de la prémisse, c'est 
défier les bases de la société.

Il est important pour ces gens de savoir que cette prémisse ne fait pas 
partie de notre tradition légale. Et n'en a jamais fait partie non plus.

Ainsi, la Constitution dit que le but du copyright est de « promouvoir le 
progrès des sciences et des arts utiles ». La Cour suprême l'a élaboré ainsi, 
énonçant dans la « 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 généraux que le public tire du travail des auteurs ».

Nous ne sommes pas obligés d'approuver la Constitution ou la Cour suprême (il 
fut un temps où les deux ont 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 la conscience qu'il s'agit d'une supposition de la droite radicale, 
plutôt que d'une supposition traditionnellement reconnue, affaiblira son 
attrait.

Conclusion

Nous aimons penser que notre société encourage le fait d'aider son voisin ; 
mais chaque fois que nous récompensons quelqu'un pour son obstructionnisme ou 
que nous l'admirons pour les richesses qu'il a accumulé par ce moyen, nous 
renvoyons le message contraire.

La thésaurisation de logiciels est un exemple de notre volonté d'ignorer le 
bien-être de la société pour le gain personnel. On peut en voir la trace 
depuis Ronald Reagan jusqu'à Dick Cheney, depuis Exxon à Enron, en passant 
par les échecs des banques et des écoles. Nous pouvons la mesurer à la taille 
de la population itinérante 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 qu'un bon citoyen est un 
citoyen qui coopère quand il le faut, que ce n'est pas celui qui réussit en 
volant les 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 désigne les deux termes, en anglais] ; le prix payé pour une copie d'un 
programme libre peut être nul, faible, ou (rarement) assez é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 des 
ventes 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.

Cet essai est publié dans Free Software, Free Society: The Selected Essays of 
Richard M. Stallman