summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/fr/shouldbefree.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/shouldbefree.html')
-rw-r--r--talermerchantdemos/blog/articles/fr/shouldbefree.html988
1 files changed, 988 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/fr/shouldbefree.html b/talermerchantdemos/blog/articles/fr/shouldbefree.html
new file mode 100644
index 0000000..21d7dd2
--- /dev/null
+++ b/talermerchantdemos/blog/articles/fr/shouldbefree.html
@@ -0,0 +1,988 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
+
+<!--#include virtual="/server/header.fr.html" -->
+<!-- Parent-Version: 1.86 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Pourquoi le logiciel doit être libre - Projet GNU - Free Software Foundation</title>
+
+<!--#include virtual="/philosophy/po/shouldbefree.translist" -->
+<!--#include virtual="/server/banner.fr.html" -->
+<h2>Pourquoi le logiciel doit être libre</h2>
+
+<p>
+par <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
+<h3 id="introduction">Introduction</h3>
+<p>
+L'existence du logiciel soulève forcément la question de la façon dont
+doivent être prises les décisions concernant son usage. Par exemple,
+supposons qu'une personne ayant un exemplaire d'un programme rencontre une
+autre personne qui en voudrait une copie. Il leur est possible de copier le
+programme ; qui doit décider si cela se fera ? Les personnes elles-mêmes ?
+Ou une tierce personne, son « propriétaire » ?</p>
+<p>
+ Les développeurs de logiciel envisagent typiquement ces questions en
+supposant que le critère de la réponse est la maximisation de leurs propres
+profits. Le pouvoir politique des affaires a poussé le gouvernement à
+adopter à la fois ce critère et la réponse proposée par les développeurs, à
+savoir qu'un programme a un propriétaire, en général une société associée à
+son développement.</p>
+<p>
+ Je voudrais envisager la même question avec un critère différent : la
+prospérité et la liberté du public en général.</p>
+<p>
+ La réponse ne peut venir de la loi actuelle – la loi devrait se conformer à
+l'éthique et non l'inverse. La pratique actuelle n'apporte pas non plus de
+réponse, bien qu'elle puisse en suggérer. La seule façon d'en juger est de
+chercher à savoir qui gagne et qui perd en reconnaissant des propriétaires
+aux logiciels, pourquoi et dans quelle mesure. En d'autres termes, nous
+devons effectuer une analyse des coûts et des avantages au nom de la société
+dans son ensemble, en prenant en compte aussi bien la liberté individuelle
+que la production de biens matériels.</p>
+<p>
+ Dans cet essai, je décrirai les effets de l'existence des propriétaires et
+je montrerai que les résultats en sont préjudiciables. Ma conclusion est que
+les programmeurs ont le devoir d'encourager les autres à partager,
+redistribuer, étudier et améliorer les logiciels qu'ils écrivent ; autrement
+dit, d'écrire des <a href="/philosophy/free-sw.html">logiciels libres</a> <a
+id="f1-rev" href="#f1">(1)</a>.</p>
+
+<h3 id="owner-justification">Comment les propriétaires justifient leur pouvoir</h3>
+<p>
+ 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.</p>
+<p>
+ L'argument affectif ressemble à ceci : « J'ai mis ma sueur, mon cœur, mon
+âme dans ce programme. Il vient de <em>moi</em>, c'est le <em>mien</em> ! »</p>
+<p>
+ Cet argument ne nécessite pas de réfutation sérieuse. Les programmeurs
+peuvent cultiver ce sentiment d'affection quand ça les arrange ; il n'est
+pas inévitable. Considérons, par exemple, comment ces mêmes programmeurs
+cèdent volontiers leurs droits à une grosse entreprise moyennant salaire ;
+mystérieusement, l'attachement affectif disparaît. Faisons le contraste avec
+ces grands artistes et artisans des temps médiévaux, qui ne signaient même
+pas leurs œuvres. Pour eux, le nom de l'artiste n'avait pas d'importance. Ce
+qui importait, c'était que le travail soit accompli et que son but afférent
+soit atteint. Cette façon de voir a prévalu pendant des centaines d'années.</p>
+<p>
+ 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.</p>
+<p>
+ 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.</p>
+<p>
+ Cette formulation part de la comparaison entre l'utilité sociale d'un
+programme privateur<a id="TransNote1-rev"
+href="#TransNote1"><sup>a</sup></a> et de l'absence de programme, pour alors
+conclure que le développement de logiciel privateur est globalement
+bénéfique et qu'il doit être encouragé. L'erreur, ici, vient de ne comparer
+que deux résultats – logiciel privateur contre pas de logiciel – et de
+supposer qu'il n'y a pas d'autre possibilité.</p>
+<p>
+ Dans un système reconnaissant le droit d'auteur, le développement logiciel
+est habituellement lié à l'existence d'un propriétaire qui contrôle
+l'utilisation du logiciel. Tant que ce lien existe, nous devons souvent
+faire face au choix entre un programme privateur et l'absence de
+programme. Cependant, ce lien n'est pas inhérent ni inévitable ; c'est une
+conséquence d'une décision politique spécifique, législative et sociétale,
+que nous contestons : la décision qu'il y ait des propriétaires. Formuler le
+choix entre logiciel privateur et pas de logiciel, c'est faire une pétition
+de principe.</p>
+
+<h3 id="against-having-owners">L'argument contre la propriété privée du logiciel</h3>
+<p>
+ La question qu'il faut poser, c'est : « Le développement d'un logiciel
+doit-il être lié à un propriétaire qui en restreint l'usage ? »</p>
+<p>
+ Pour pouvoir en décider, il nous faut estimer l'effet sur la société de
+chacune de ces activités, prise <em>indépendamment</em> : l'effet du
+développement d'un logiciel (indépendamment des conditions de sa diffusion),
+et l'effet de la restriction de son emploi (à supposer que le logiciel ait
+été développé). Si l'une de ces activités est utile alors que l'autre est
+nuisible, il serait à notre avantage de les dissocier et de ne poursuivre
+que celle qui est utile.</p>
+<p>
+ En d'autres termes, si restreindre la distribution d'un logiciel déjà
+développé est préjudiciable à la société dans son ensemble, alors un
+développeur ayant du sens moral rejettera cette activité.</p>
+<p>
+ Pour déterminer l'effet de la restriction du partage, nous avons besoin de
+comparer la valeur, pour la société, d'un programme restreint (par
+ex. privateur) avec le même programme, mais disponible pour tout le
+monde. Ce qui signifie comparer deux mondes possibles.</p>
+<p>
+ Cette analyse répond également à un contre-argument simpliste qu'on entend
+parfois : le bénéfice pour le voisin de lui donner une copie d'un logiciel
+est annulé par le préjudice causé au propriétaire. Ce contre-argument
+suppose qu'inconvénients et avantages sont équivalents dans leur
+ampleur. Notre analyse compare ces deux termes et montre que les avantages
+l'emportent de beaucoup.</p>
+<p>
+ Pour mettre cet argument en lumière, prenons un autre domaine
+d'application : la construction routière.</p>
+<p>
+ Il serait possible de financer l'ensemble de la construction routière par
+des péages, ce qui impliquerait d'avoir des postes de péage à tous les coins
+de rues. Un tel système inciterait grandement à améliorer l'état des
+routes. Il aurait aussi comme vertu de faire payer l'usager de la route
+concernée. Cependant, un poste de péage est un obstacle artificiel à la
+fluidité du trafic, artificiel dans le sens où ce n'est pas une conséquence
+du fonctionnement des routes et des voitures.</p>
+<p>
+ Si l'on compare l'utilité des routes avec et sans péage, nous voyons (toutes
+choses égales par ailleurs) que les routes sans péage sont moins chères à
+construire et à maintenir, plus sûres et plus efficaces à emprunter <a
+id="f2-rev" href="#f2">(2)</a>.<a id="TransNote2-rev"
+href="#TransNote2"><sup>b</sup></a> Dans les pays pauvres, les postes de
+péage rendent les routes inaccessibles à bien des citoyens. Les routes sans
+péage offrent ainsi plus d'avantages à moindre coût ; elles sont préférables
+pour la société. C'est pourquoi la société doit trouver d'autres moyens de
+financer les routes, sans recourir aux péages. L'usage des routes, une fois
+construites, doit être libre (ou gratuit) <cite>[free]</cite>.<a
+id="TransNote3-rev" href="#TransNote3"><sup>c</sup></a></p>
+<p>
+ Quand les partisans des postes de péage les proposent comme étant
+<em>simplement</em> une façon de lever des fonds, ils déforment le choix
+offert. Les postes de péage, effectivement, permettent de récolter des
+fonds, mais ils ont une autre conséquence : ils dégradent la valeur des
+routes. Une route n'offre pas autant d'avantages si elle a un péage que si
+elle n'en a pas ; nous donner plus de routes, ou des routes supérieures sur
+le plan technique, n'est peut-être pas une amélioration véritable si cela
+signifie substituer aux routes libres <cite>[free]</cite> des routes à
+péage.</p>
+<p>
+ Bien entendu, construire des routes sans péage coûte de l'argent, que le
+public doit payer d'une façon ou d'une autre. Toutefois, cela n'implique pas
+que les postes de péage soient inévitables. Nous, qui devrons payer dans un
+cas comme dans l'autre, obtiendrons plus pour notre argent en achetant des
+routes sans péage.</p>
+<p>
+ Je ne suis pas en train de dire que les routes à péage sont pires que pas de
+route du tout. Ce serait vrai si les péages étaient tels que presque
+personne n'emprunterait la route – ce qui n'est pas une politique plausible
+pour un collecteur de péage. Cependant, tant que les postes de péage
+causeront des gaspillages et des inconvénients significatifs, il sera plus
+avantageux de lever des fonds d'une façon qui fasse moins obstacle à l'usage
+des routes.</p>
+<p>
+ Pour appliquer ce même argument au développement logiciel, je vais
+maintenant montrer que d'avoir des « postes de péage » sur des logiciels
+utiles coûte cher à la société : cela rend le programme plus coûteux à
+élaborer et à distribuer, moins satisfaisant et moins efficace à
+utiliser. Je poursuivrai en disant que la construction du programme devrait
+être encouragée autrement. Puis je m'attacherai à présenter d'autres
+méthodes d'encouragement et de financement du développement logiciel (dans
+la mesure réellement nécessaire).</p>
+
+<h4 id="harm-done">Les obstacles font du tort au logiciel</h4>
+<p>
+ Considérez un instant un programme dont le développement est terminé et
+entièrement payé ; maintenant, la société doit faire le choix entre le
+rendre privateur, ou en permettre le partage et l'utilisation en toute
+liberté. Supposez que l'existence et la disponibilité de ce programme soient
+souhaitables <a id="f3-rev" href="#f3">(3)</a>.</p>
+<p>
+ Les restrictions sur la distribution et la modification du programme ne
+facilitent pas son utilisation. Elles ne peuvent qu'interférer. Donc, leur
+effet ne peut être que négatif. Mais jusqu'à quel point ? Et de quelle
+manière ?</p>
+<p>
+ On distingue trois niveaux de préjudice matériel dans ce genre d'obstacle :</p>
+
+<ul>
+<li>moins de gens utilisent le programme ;</li>
+
+<li>aucun des utilisateurs ne peut l'adapter ni le corriger ;</li>
+
+<li>les autres développeurs ne peuvent rien en apprendre et il est impossible de
+commencer un nouveau projet en se basant dessus.</li>
+</ul>
+
+<p>
+ Chaque niveau de préjudice matériel a un préjudice psychosocial
+concomitant. Cela renvoie aux effets à long terme de nos décisions sur nos
+propres sentiments, attitudes et prédispositions. Ces changements dans notre
+façon de penser auront à leur tour un effet sur nos relations avec nos
+concitoyens et peuvent avoir des conséquences matérielles.</p>
+<p>
+ Les trois niveaux de préjudice matériel font perdre une partie de la valeur
+que le programme pourrait offrir, mais ne peuvent la réduire à zéro. S'ils
+font perdre la presque totalité de la valeur du programme, alors l'écriture
+du programme cause du tort à la société, au plus à hauteur de l'effort qu'il
+a fallu fournir pour écrire ce programme. En effet, un programme dont la
+vente génère des profits fournit nécessairement un bénéfice net matériel
+direct.</p>
+<p>
+ Cependant, compte tenu des préjudices psychosociaux concomitants, il n'y a
+pas de limite au préjudice que peut provoquer le développement d'un logiciel
+privateur.</p>
+
+<h4 id="obstructing-use">Obstacles à l'utilisation des programmes</h4>
+<p>
+ Le premier niveau de préjudice gêne le simple usage d'un programme. Une
+copie d'un programme a un coût marginal proche de zéro (et ce prix, vous
+pouvez le payer en faisant le travail vous-même), ce qui veut dire que, dans
+un marché libre, elle aurait un prix avoisinant zéro. Une licence payante
+est une désincitation significative à l'utilisation d'un programme. Si un
+logiciel utile à l'ensemble de la population est privateur, beaucoup moins
+de gens l'utiliseront.</p>
+<p>
+ Il est facile de montrer que la contribution totale d'un programme à la
+société est réduite si on lui assigne un propriétaire. Chaque utilisateur
+potentiel du logiciel, face à la nécessité de le payer pour l'utiliser, peut
+choisir de payer ou de renoncer à son usage. Si un utilisateur fait le choix
+de payer le programme, il y a un simple transfert de richesses entre deux
+parties. Mais chaque fois qu'une personne choisit de s'abstenir d'utiliser
+le programme, cela cause du tort à cette personne sans que quiconque y
+trouve son compte. Quand on additionne des nombres négatifs avec zéro, le
+résultat ne peut être que négatif.</p>
+<p>
+ Mais cela ne réduit pas la somme de travail qu'il a fallu pour
+<em>développer</em> 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.</p>
+<p>
+ Ceci reflète la différence cruciale entre la copie d'un programme et celle
+d'une voiture, d'une chaise ou d'un sandwich. À part dans la
+science-fiction, il n'existe pas de machine pouvant reproduire les objets
+matériels. Mais les programmes sont faciles à copier ; n'importe qui peut
+faire autant de copies que nécessaire, sans grand effort – ce qui n'est pas
+vrai dans le cas des objets matériels, étant donné que la matière est
+conservée : chaque copie nécessite des matières premières, tout comme
+l'original.</p>
+<p>
+ En ce qui concerne les objets matériels, décourager leur usage est logique,
+car moins d'objets achetés signifie moins de matières premières, moins de
+travail pour les construire. C'est vrai qu'il y a aussi, en général, un
+investissement initial et un coût de développement que l'on doit répartir
+sur l'ensemble de la production. Mais tant que le coût marginal de
+production est significatif, y ajouter un pourcentage des coûts de
+développement ne provoque pas de différence qualitative. Et cela n'exige
+aucune restriction à la liberté des utilisateurs ordinaires.</p>
+<p>
+ Cependant, imposer un prix à quelque chose qui, autrement, aurait pu être
+gratuit, c'est un changement qualitatif. Une redevance imposée de manière
+centralisée sur la distribution de logiciels devient une puissante source de
+démotivation.</p>
+<p>
+ De plus, la production centralisée, telle qu'elle est pratiquée de nos
+jours, est inefficace, même comme moyen de fournir des copies de
+logiciels. Ce système implique d'empaqueter des disquettes ou des bandes
+dans un emballage superflu, de les envoyer en grande quantité dans le monde
+entier puis de les stocker avant leur vente. Ces coûts sont présentés comme
+étant le prix à payer pour faire des affaires ; en vérité, ils font partie
+du gaspillage qu'entraîne le fait d'avoir des propriétaires.</p>
+
+<h4 id="damaging-social-cohesion">Dommages à la cohésion sociale</h4>
+<p>
+ Supposons que vous et votre voisin trouviez utile de faire tourner un
+certain programme. Par souci d'éthique envers votre voisin, vous estimerez
+probablement que la bonne chose à faire est de vous en servir tous les
+deux. Proposer de n'en permettre l'usage qu'à un seul d'entre vous, tout en
+l'interdisant à l'autre, entraînerait la division ; ni vous, ni votre voisin
+ne trouveriez cela acceptable.</p>
+<p>
+ Signer un contrat de licence typique pour un logiciel revient à trahir votre
+voisin : « Je fais la promesse de priver mon voisin de ce programme de sorte
+que je puisse en avoir un exemplaire pour moi-même. » Les gens qui font de
+tels choix ressentent la pression psychologique interne de se justifier, en
+diminuant l'importance d'aider leur voisin – cela au détriment du sens
+civique. C'est là un préjudice psychosocial associé au préjudice matériel
+consistant à décourager l'utilisation du logiciel.</p>
+<p>
+ Beaucoup d'utilisateurs reconnaissent inconsciemment que le fait de refuser
+le partage est mal ; ils décident alors d'ignorer les licences et les lois,
+et de partager tout de même les programmes. Mais ils s'en sentent souvent
+coupables. Ils savent qu'ils doivent enfreindre la loi pour être de bons
+voisins, mais ils continuent de penser que les lois font autorité et
+concluent qu'être un bon voisin (ce qu'ils sont), c'est vilain et
+honteux. C'est aussi une forme de préjudice psychosocial, mais on peut y
+échapper en prenant la décision de considérer que ces licences et ces lois
+n'ont aucune force morale.</p>
+<p>
+ Les programmeurs souffrent aussi de préjudice psychosocial, sachant que bien
+des utilisateurs ne seront pas autorisés à se servir des fruits de leur
+labeur. Ceci conduit à une attitude de cynisme ou de dénégation. Un
+programmeur peut faire une description enthousiaste d'un travail qu'il
+trouve stimulant sur le plan technique ; puis, quand on lui demande « Est-ce
+qu'il me sera permis de l'utiliser ? », son visage se ferme et il doit bien
+admettre que non. Pour éviter de se sentir découragé, soit, la plupart du
+temps, il ignore ce fait, soit il adopte une attitude cynique afin d'en
+minimiser l'importance.</p>
+<p>
+ 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.</p>
+
+<h4 id="custom-adaptation">Obstacles à l'adaptation sur mesure des programmes</h4>
+<p>
+ 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.</p>
+<p>
+ Un programme exécutable se compose d'une série de nombres dont le sens est
+obscur. Personne, même un bon programmeur, ne peut aisément changer les
+nombres pour amener le programme à faire quelque chose de différent.</p>
+<p>
+ Normalement, les programmeurs travaillent sur le « code source » d'un
+programme, écrit dans un langage de programmation comme le Fortran ou
+le C. Ils utilisent des noms pour désigner les données utilisées et les
+différentes parties du programme, et ils représentent les opérations par des
+symboles comme le « + » pour une addition ou le « - » pour une
+soustraction. Le langage est conçu pour aider les programmeurs à déchiffrer
+et modifier les programmes. Voici un exemple : il s'agit d'un programme qui
+calcule la distance entre deux points d'un plan :</p>
+
+<pre>
+ 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);
+ }
+</pre>
+<p>
+ Ce que fait précisément ce code source n'est pas le problème ; le point
+important est que cela ressemble à de l'algèbre et qu'une personne
+connaissant ce langage de programmation le trouvera sensé et clair. En
+revanche, voici le même programme sous sa forme exécutable, sur l'ordinateur
+que j'utilisais lorsque j'ai écrit ceci :
+</p>
+
+<pre>
+ 1314258944 -232267772 -231844864 1634862
+ 1411907592 -231844736 2159150 1420296208
+ -234880989 -234879837 -234879966 -232295424
+ 1644167167 -3214848 1090581031 1962942495
+ 572518958 -803143692 1314803317
+</pre>
+
+<p>
+ Le code source est utile (au moins potentiellement) à chacun des
+utilisateurs d'un programme, mais la plupart ne sont pas autorisés à en
+posséder une copie. Normalement, le code source d'un programme privateur est
+tenu secret par son propriétaire, de peur que quelqu'un d'autre n'en
+apprenne quelque chose. L'utilisateur reçoit simplement des fichiers de
+nombres incompréhensibles que l'ordinateur exécutera. Cela signifie que seul
+le propriétaire du logiciel peut changer le programme.</p>
+<p>
+ Un jour, une amie me raconta avoir travaillé comme programmeuse dans une
+banque durant environ six mois, pour écrire un programme semblable à un
+autre qui était disponible commercialement. Elle croyait que, si elle avait
+eu accès au code source de ce programme commercial, elle aurait facilement
+pu l'adapter aux besoins de la banque. La banque souhaitait payer pour cela,
+mais elle n'y fut pas autorisée – le code source était un secret. Pendant
+six mois, elle a donc dû faire un travail bidon, un travail qui a compté
+pour quelque chose dans le PNB, mais qui était en fait du gaspillage.</p>
+<p>
+ Aux alentours de 1977, le laboratoire d'intelligence artificielle (IA) du
+<abbr title="Massachusetts Institute of Technology">MIT</abbr> reçut un
+cadeau de Xerox, une imprimante graphique. Elle était pilotée par un
+logiciel libre, auquel nous avons ajouté de nombreuses fonctionnalités bien
+commodes. Par exemple, le logiciel avertissait immédiatement l'utilisateur
+de la fin du processus d'impression. Si l'imprimante venait à rencontrer un
+problème, comme un bourrage ou un manque de papier, le programme avertissait
+de suite tous ceux qui avaient des travaux d'impression en cours. Ces
+fonctionnalités facilitaient la vie.</p>
+<p>
+ Plus tard, Xerox offrit au labo d'IA une nouvelle imprimante, plus rapide,
+une des premières laser. Elle était pilotée par un logiciel privateur qui
+tournait sur un poste dédié et séparé, nous ne pouvions donc ajouter aucune
+de nos fonctionnalités favorites. On pouvait s'arranger pour envoyer un
+avertissement quand une tâche d'impression était envoyée au poste dédié,
+mais pas quand celle-ci était terminée (et les délais étaient habituellement
+importants). Il n'y avait aucun moyen de savoir si le document était
+imprimé ; il fallait deviner. Et personne n'était informé d'un bourrage
+papier ; l'imprimante attendait ainsi souvent une heure avant d'être remise
+en route.</p>
+<p>
+ Les programmeurs système du labo d'IA étaient capables de corriger de tels
+problèmes, probablement tout aussi capables que les auteurs du
+programme. Xerox n'avait pas envie de les corriger et choisit de nous en
+empêcher, nous avons donc été forcés de subir les problèmes. Ils n'ont
+jamais été corrigés.</p>
+<p>
+ 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.</p>
+<p>
+ Laisser tomber provoque un préjudice psychosocial – sur l'esprit
+d'indépendance. C'est démoralisant d'habiter une maison qu'on ne peut
+réarranger selon ses besoins. Cela conduit à la résignation et au
+découragement, ce qui peut affecter d'autres aspects de la vie d'une
+personne. Les gens qui ont ce sentiment ne sont pas heureux et ne font pas
+du bon travail.</p>
+<p>
+ Imaginez ce que ce serait si les recettes de cuisine étaient logées à la
+même enseigne que les logiciels. Vous vous diriez : « Voyons, comment
+modifier cette recette pour en enlever le sel ? » Et le chef renommé de vous
+répondre : « Comment oses-tu insulter ma recette, fruit de mon cerveau et de
+mon palais, en tentant de la modifier ? Tu n'as pas assez de jugement pour
+la changer sans la dénaturer. »</p>
+<p>
+ « Mais mon docteur m'a recommandé de ne pas manger salé. Que puis-je faire ?
+Pouvez-vous en ôter le sel pour moi ? »</p>
+<p>
+ « Je serais heureux de le faire ; mes honoraires ne sont que de 50 000
+dollars. » À partir du moment où le propriétaire a le monopole des
+modifications, les honoraires tendent à gonfler. « De toute façon, je n'ai
+pas le temps maintenant. Je suis pris par une commande du ministère de la
+marine qui m'a demandé de créer une nouvelle recette de biscuit de mer. Je
+reprendrai contact avec toi dans environ deux ans. »</p>
+
+<h4 id="software-development">Obstacles au développement logiciel</h4>
+<p>
+ Le troisième niveau de préjudice matériel touche le développement
+logiciel. C'était autrefois un processus évolutif, où quelqu'un prenait un
+programme existant et en réécrivait une partie pour ajouter une nouvelle
+fonctionnalité ; puis une autre personne en réécrivait aussi une partie pour
+y ajouter une autre fonctionnalité. Dans certains cas, cela a continué ainsi
+sur une période d'une vingtaine d'années. Entre-temps, certaines parties du
+programme se voyaient « cannibalisées » pour créer l'amorce d'autres
+programmes.</p>
+<p>
+ L'existence de propriétaires empêche ce genre d'évolution, ce qui rend
+nécessaire de repartir à zéro si l'on veut développer un programme. Cela
+empêche également les nouveaux praticiens d'étudier les programmes existants
+pour en apprendre des techniques utiles ou même apprendre comment on
+structure de gros programmes.</p>
+<p>
+ Les propriétaires font ainsi obstacle à l'éducation, à l'apprentissage. J'ai
+rencontré de brillants étudiants en informatique qui n'avaient jamais vu le
+code source d'un grand programme. Ils sont peut-être bons à écrire des
+programmes courts, mais les grands demandent des techniques d'écriture
+différentes qu'ils ne peuvent pas commencer à apprendre s'ils ne peuvent
+observer comment d'autres ont fait.</p>
+<p>
+ Dans tout domaine intellectuel, on peut atteindre de plus hauts sommets en
+se tenant sur les épaules des autres. Mais ce n'est généralement plus permis
+dans le domaine logiciel – ce n'est permis qu'à l'intérieur de <em>votre
+propre entreprise</em>.</p>
+<p>
+ Le préjudice psychosocial qui s'y rattache affecte l'esprit de coopération
+scientifique, qui était autrefois si fort que les scientifiques coopéraient
+même quand leurs pays étaient en guerre. C'est dans cet esprit que des
+océanographes japonais, abandonnant leur labo dans une île du Pacifique, ont
+soigneusement conservé leurs travaux pour les Marines américains qui
+commençaient à débarquer et laissèrent un mot leur demandant d'en prendre
+bien soin.</p>
+<p>
+ Les conflits de la course aux profits ont détruit ce que les conflits
+internationaux avaient épargné. Aujourd'hui, les scientifiques de nombreuses
+disciplines ne donnent pas assez de détails dans leurs publications pour que
+d'autres puissent reproduire leur expérience. Ils ne publient que ce qui
+permet au lecteur d'être impressionné par l'étendue de leurs travaux. C'est
+particulièrement vrai pour la recherche informatique, où le code source des
+programmes décrits dans les publications est en général secret.</p>
+
+<h4 id="does-not-matter-how">Le moyen utilisé pour restreindre le partage n'a pas d'importance</h4>
+<p>
+ J'ai parlé de ce qui se passe quand on empêche les gens de copier, de
+modifier ou de prendre comme base un programme existant. Je n'ai pas précisé
+la nature de ces obstacles, car cela n'affecte pas la conclusion. Que ce
+soit par une protection contre la copie, le droit d'auteur, les licences, le
+chiffrement, les cartes ROM ou encore un numéro de série sur le matériel, si
+cela <em>réussit</em> à empêcher l'utilisation, alors il y a préjudice.</p>
+<p>
+ Les utilisateurs jugent certaines de ces méthodes plus odieuses que
+d'autres. Je suggère que les méthodes les plus détestées sont celles qui
+accomplissent leur objectif.</p>
+
+<h4 id="should-be-free">Le logiciel doit être libre</h4>
+<p>
+ J'ai montré comment la propriété d'un programme, le pouvoir de restreindre
+sa modification ou sa copie, est source d'obstacles. Ses retombées négatives
+sont vastes et importantes. Il s'ensuit que la société doit se passer des
+propriétaires de logiciels.</p>
+<p>
+ Pour voir les choses autrement : ce dont a besoin la société, c'est de
+logiciels libres ; les logiciels privateurs n'en sont qu'un médiocre
+substitut. Encourager le substitut n'est pas une façon rationnelle d'obtenir
+ce dont nous avons besoin.</p>
+<p>
+ Václav Havel nous a conseillé de « travailler pour une chose parce qu'elle
+est bonne, pas parce que cela a des chances de réussir ». Un marché créant
+des logiciels privateurs a des chances de réussir dans l'étroite limite de
+ses propres règles, mais ce n'est pas ce qui est bon pour la société.</p>
+
+<h3 id="why-develop">Pourquoi les gens développeront des logiciels</h3>
+<p>
+ Si nous éliminons le droit d'auteur comme moyen d'encourager les gens à
+développer des logiciels, au début moins de programmes seront développés,
+mais ils seront plus utiles. Difficile de dire si la satisfaction d'ensemble
+des utilisateurs sera moindre. Mais si c'est le cas, ou si nous voulons
+l'augmenter de toute façon, il y a d'autres moyens d'encourager le
+développement, tout comme il y a des alternatives aux postes de péage pour
+financer les rues. Mais avant de parler de la façon dont cela peut se faire,
+je vais d'abord me demander dans quelle mesure un encouragement artificiel
+est vraiment nécessaire.</p>
+
+<h4 id="fun">Programmer, c'est amusant</h4>
+<p>
+ Certains domaines professionnels trouvent peu de candidats, sauf pour de
+l'argent ; la construction routière, par exemple. Il en est d'autres,
+touchant aux études ou à l'art, dans lesquelles il y a peu de chance de
+devenir riche, mais où les gens s'engagent par passion ou à cause de la
+valeur que leur accorde la société. On peut y inclure, par exemple, la
+logique mathématique, la musique classique et l'archéologie ; également
+l'action politique au sein du monde du travail. Les gens concourent, plus
+tristement qu'âprement, pour les quelques postes rémunérés disponibles, dont
+aucun n'est vraiment bien payé. Ils iraient jusqu'à payer pour avoir la
+chance de travailler dans un de ces domaines, s'ils pouvaient se le
+permettre.</p>
+<p>
+ Un tel domaine peut se transformer du jour au lendemain s'il commence à
+offrir la possibilité de devenir riche. Si un travailleur devient riche, les
+autres réclament la même opportunité. Bientôt tous pourront exiger de fortes
+sommes d'argent pour ce qu'ils avaient l'habitude de faire pour le
+plaisir. Deux ou trois ans de plus, et tous ceux qui appartiendront au
+domaine tourneront en dérision l'idée que le travail puisse se faire sans
+une rentabilité financière conséquente. Ils conseilleront aux acteurs
+sociaux de rendre possible cette rentabilité en imposant les privilèges,
+pouvoirs et monopoles spéciaux qu'elle nécessite.</p>
+<p>
+ Ce changement est survenu dans le domaine de la programmation au cours des
+années 80. Dans les années 70, des articles parlaient d'« accrocs à
+l'informatique » : les utilisateurs étaient « connectés » et vivaient avec
+100 $ par semaine.<a id="TransNote4-rev" href="#TransNote4"><sup>d</sup></a>
+Il était généralement admis que des gens pouvaient aimer la programmation au
+point qu'elle devienne une cause de divorce. Aujourd'hui, il est
+généralement admis que personne ne programmerait sauf en échange d'un
+salaire élevé. On a oublié ce qu'on savait à l'époque.</p>
+<p>
+ Même si à un moment précis, il est vrai que la plupart des gens ne veulent
+travailler dans un domaine particulier que pour un haut salaire, il ne faut
+pas en conclure que ce sera toujours le cas. La tendance peut s'inverser
+sous l'impulsion de la société. Si nous retirons du jeu la possibilité
+d'amasser de grandes fortunes, alors au bout de quelque temps, quand les
+gens auront réajusté leurs attitudes, ils seront de nouveau impatients de
+travailler dans ce domaine pour le simple plaisir de réaliser quelque chose.</p>
+<p>
+ Répondre à la question « Comment pouvons-nous payer les programmeurs ? »
+devient plus facile quand nous réalisons qu'il ne s'agit pas de leur offrir
+une petite fortune. Il est plus facile de leur assurer un niveau de vie
+correct, mais sans plus.</p>
+
+<h4 id="funding">Financer le logiciel libre</h4>
+<p>
+ Les institutions qui payent les programmeurs n'ont pas besoin d'être des
+éditeurs de logiciels. Beaucoup d'autres institutions existantes peuvent le
+faire.</p>
+<p>
+ Les fabricants de matériel informatique pensent qu'il est essentiel de
+soutenir le développement du logiciel, même s'ils ne peuvent contrôler son
+usage. En 1970, la plupart de leurs logiciels étaient libres, car ils ne
+pensaient pas à les entraver. Aujourd'hui, leur volonté croissante de se
+joindre à des consortiums montre bien qu'ils ont conscience que posséder le
+logiciel n'est pas ce qui est vraiment important pour eux.</p>
+<p>
+ Les universités dirigent de nombreux projets de développement
+logiciel. Aujourd'hui, elles en vendent souvent les résultats, mais dans les
+années 70 elles ne le faisaient pas. Peut-on douter que les universités
+développeraient des logiciels libres si elles n'étaient pas autorisées à
+vendre les logiciels ? Ces projets pourraient recevoir le soutien des mêmes
+contrats et subventions publiques qui soutiennent actuellement le
+développement de logiciels privateurs.</p>
+<p>
+ Il est courant de nos jours que les chercheurs universitaires reçoivent une
+subvention pour développer un système, qu'ils l'amènent presque jusqu'au
+point d'achèvement, qu'ils le déclarent effectivement « fini », puis créent
+des sociétés où ils finiront réellement le projet et le rendront
+utilisable. Parfois, ils déclarent « libre » la version non terminée ; s'ils
+sont vraiment corrompus, ils obtiendront plutôt une licence exclusive de la
+part de l'université. Ce n'est pas un secret, c'est ouvertement admis par
+toutes les personnes concernées. Pourtant, si les chercheurs n'étaient pas
+exposés à la tentation de faire ce genre de chose, ils poursuivraient quand
+même leurs recherches.</p>
+<p>
+ Les programmeurs qui écrivent des logiciels libres peuvent gagner leur vie
+en vendant des services liés au logiciel. J'ai été recruté pour porter le <a
+href="/software/gcc/">compilateur C de GNU</a> sur du nouveau matériel
+informatique et pour faire des extensions d'interface utilisateur pour <a
+href="/software/emacs/">GNU Emacs</a> (j'offre ces améliorations au public,
+une fois qu'elles sont réalisées). Je suis aussi payé pour faire des cours.</p>
+<p>
+ Je ne suis pas le seul à travailler de cette façon ; il existe maintenant
+une entreprise florissante, en expansion, qui ne fait que ce genre de
+travail. Plusieurs autres sociétés fournissent également un support
+commercial aux logiciels libres issus du système GNU. C'est le début d'une
+industrie indépendante de support au logiciel libre, une industrie qui
+pourrait prendre de fortes proportions si le logiciel libre devait se
+généraliser. Elle offre aux utilisateurs des options qui sont généralement
+indisponibles dans le cas du logiciel privateur, sauf pour les plus riches.</p>
+<p>
+ De nouvelles institutions peuvent aussi financer les programmeurs, par
+exemple la <a href="/fsf/fsf.html">Free Software Foundation</a>. Cette
+dernière tire la majeure partie de ses fonds de la vente de bandes
+magnétiques par correspondance. Le logiciel présent sur la bande est libre,
+ce qui signifie que chaque utilisateur est libre de le copier et de le
+modifier, mais néanmoins beaucoup payent pour en obtenir des copies
+(rappelez-vous que <cite>free software</cite> veut dire logiciel libre, non
+pas logiciel gratuit). Certains utilisateurs achètent des bandes, alors
+qu'ils en possèdent déjà une copie, simplement parce qu'ils sentent que nous
+méritons cette contribution. La Fondation reçoit aussi des donations
+considérables de la part de fabricants d'ordinateurs.</p>
+<p>
+ La <cite>Free Software Foundation</cite> est une organisation caritative et
+ses revenus sont utilisés pour embaucher le plus de programmeurs
+possible. Si elle avait été montée comme une entreprise, distribuant les
+mêmes logiciels libres au public pour le même tarif, elle assurerait
+aujourd'hui un très bon niveau de vie à son fondateur.</p>
+<p>
+ Puisque la Fondation est une organisation caritative, les programmeurs
+travaillent souvent pour la moitié de ce qu'ils pourraient toucher
+ailleurs. Ils le font parce qu'ils sont libres de toute bureaucratie et
+parce qu'ils ressentent de la satisfaction à savoir qu'il n'y aura pas
+d'obstacle à l'utilisation de leur travail. Et, par-dessus tout, ils le font
+parce que programmer est un vrai plaisir. Ajoutons que des bénévoles nous
+ont écrit nombre de programmes (même des rédacteurs techniques ont commencé
+à nous aider bénévolement).</p>
+<p>
+ Ceci confirme que la programmation est l'un des domaines les plus
+fascinants, au même titre que la musique et les arts. Nous n'avons pas à
+craindre que plus personne ne veuille programmer.</p>
+
+<h4 id="owe">Qu'est-ce que les utilisateurs doivent aux programmeurs ?</h4>
+<p>
+ Les utilisateurs d'un logiciel ont une bonne raison de se sentir moralement
+obligés de contribuer à son soutien. Les développeurs de logiciel libre
+contribuent aux activités des utilisateurs, il est donc à la fois juste et
+– sur le long terme – aussi dans l'intérêt des utilisateurs de continuer à
+les financer.</p>
+<p>
+ Cependant, ceci ne s'applique pas aux développeurs de logiciel privateur,
+car la création d'obstacles appelle plutôt une sanction qu'une récompense.</p>
+<p>
+ 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.</p>
+<p>
+ Je crois qu'un développeur doué de sens moral faisant face à ce paradoxe
+doit agir de manière à mériter la récompense, mais devrait aussi encourager
+les utilisateurs à donner volontairement. Tôt ou tard, les utilisateurs
+apprendront à soutenir les développeurs d'eux-mêmes, tout comme ils ont
+appris à soutenir les radios et les stations télé indépendantes.</p>
+
+<h3 id="productivity">Qu'est-ce que la productivité logicielle ? </h3>
+<p>
+ 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é ?</p>
+<p>
+ Pas forcément. Aujourd'hui, les nations riches ont moins de fermiers qu'en
+1900, mais nous ne pensons certainement pas que c'est mauvais pour la
+société, car ceux qui restent produisent plus de nourriture pour les
+consommateurs qu'un plus grand nombre n'en produisait autrefois. Nous
+appelons cela l'amélioration de la productivité. Le logiciel libre devrait
+demander moins de programmeurs pour satisfaire la demande, à cause de
+l'augmentation de la productivité logicielle à tous niveaux :</p>
+
+<ul>
+<li> une utilisation plus générale de chaque programme développé ;</li>
+<li> la possibilité d'adapter un programme existant pour le personnaliser au lieu
+de repartir de zéro ;</li>
+<li> une meilleure formation des programmeurs ;</li>
+<li> l'élimination des efforts de développement redondants.</li>
+</ul>
+
+<p>
+ Ceux qui s'opposent à la coopération dans la mesure où elle diminuerait le
+nombre d'emplois en programmation s'opposent en fait à l'accroissement de la
+productivité. Pourtant les mêmes acceptent souvent la croyance largement
+répandue que l'industrie logicielle a besoin d'accroître sa
+productivité. Comment cela se fait-il ?</p>
+<p>
+ La « productivité logicielle » peut vouloir dire deux choses : la
+productivité d'ensemble de tout le développement logiciel ou la productivité
+de projets individuels. La productivité d'ensemble, c'est ce que la société
+aimerait améliorer, et la voie la plus directe pour le faire est d'éliminer
+les obstacles artificiels à la coopération, qui la réduisent. Mais les
+chercheurs qui se penchent sur la « productivité logicielle » se concentrent
+uniquement sur le deuxième sens, limité, du terme, où l'amélioration demande
+des avancées technologiques difficiles.</p>
+
+<h3 id="competition">Est-ce que la compétition est inévitable ?</h3>
+<p>
+ Est-il inévitable que les gens entrent en compétition, qu'ils essayent de
+dépasser leurs rivaux dans la société ? Peut-être, oui. Mais la compétition
+en elle-même n'est pas nocive : ce qui est nocif, c'est le <em>combat</em>.</p>
+<p>
+ La compétition peut prendre de nombreuses formes. Elle peut consister en une
+tentative d'aller toujours plus loin, de surpasser ce que d'autres ont déjà
+réalisé. Par exemple, jadis, il y avait concurrence entre les meilleurs
+programmeurs, et l'on rivalisait pour faire faire à l'ordinateur les choses
+les plus incroyables, ou encore écrire le programme le plus court ou le plus
+rapide pour une tâche donnée. Ce genre de compétition est bénéfique pour
+tous, <em>tant que</em> subsiste le bon esprit sportif.</p>
+<p>
+ Une compétition constructive est suffisante pour pousser les gens à de
+grands efforts. Pas mal de gens rivalisent en ce moment pour savoir qui sera
+le premier à avoir visité tous les pays du globe ; il y en a même qui
+dépensent des fortunes pour cela. Mais ils ne corrompent pas les capitaines
+de navire pour faire échouer leurs rivaux sur des îles désertes. Ils sont
+satisfaits de laisser le meilleur gagner.</p>
+<p>
+ La compétition devient un combat quand les participants commencent à gêner
+les autres plutôt que de progresser eux-mêmes – c'est-à-dire quand le
+principe qui dit « que le meilleur gagne » fait place au « laissez-moi
+gagner, que je sois le meilleur ou non ». Le logiciel privateur est nocif,
+non parce que c'est une forme de compétition, mais parce que c'est une forme
+de combat entre les citoyens de notre société.</p>
+<p>
+ La compétition dans les affaires n'est pas forcément un combat. Par exemple,
+lorsque deux épiceries se font concurrence, tous leurs efforts tendent à
+l'amélioration de leurs propres services, pas au sabotage de l'entreprise
+rivale. Mais cela ne démontre pas un attachement particulier à l'éthique des
+affaires ; plutôt qu'il y a peu de place pour le combat dans ce secteur,
+violence physique mise à part. Tous les secteurs ne partagent pas cette
+caractéristique. La rétention d'information utile à tous, c'est une forme de
+combat.</p>
+<p>
+ L'idéologie des affaires ne prépare pas les gens à résister à la tentation
+de se battre lorsqu'ils sont en concurrence. Certaines formes de combat ont
+été interdites avec les lois antitrust, l'interdiction de la publicité
+mensongère, etc. ; mais plutôt que de considérer le rejet du combat comme un
+principe général, les dirigeants d'entreprises inventent d'autres formes de
+combat qui ne sont pas spécifiquement prohibées. Les ressources de la
+société sont gaspillées dans l'équivalent économique d'une guerre civile
+entre factions.</p>
+
+<h3 id="communism">« Pourquoi ne pas t'établir en Russie ? »</h3>
+<p>
+ Aux États-Unis, toute personne favorable à autre chose que le plus flagrant
+laisser-faire égoïste a souvent entendu ce genre de réflexion. On l'entend,
+par exemple, à l'encontre des partisans d'un système de santé publique tel
+qu'il existe dans toutes les autres nations industrialisées du monde
+libre. Ou encore à propos des partisans d'un soutien public des arts, tout
+aussi universel dans les nations développées. Aux États-Unis, l'idée que les
+citoyens aient une quelconque obligation de participer au bien public est
+considérée comme du communisme. Mais jusqu'à quel point ces idées sont-elles
+semblables ?</p>
+<p>
+ Le communisme, tel qu'il était pratiqué en Union Soviétique, était un
+système de contrôle centralisé où toutes les activités étaient strictement
+régentées, soi-disant pour le bien public, mais en fait pour le bien des
+membres du Parti communiste ; système où les machines à copier étaient
+étroitement gardées, pour empêcher la copie illégale.</p>
+<p>
+ Le système américain du droit d'auteur sur les logiciels exerce un contrôle
+central sur la distribution d'un programme et surveille les machines à
+copier grâce à des systèmes automatiques de protection contre la copie, pour
+empêcher la copie illégale.</p>
+<p>
+ Au contraire, je travaille à bâtir un système où les gens sont libres de
+décider de leurs propres actions ; libres en particulier d'aider leur
+voisin, ainsi que de modifier et améliorer les outils qu'ils utilisent dans
+leur vie quotidienne – un système basé sur la coopération volontaire et la
+décentralisation.</p>
+<p>
+ Du coup, si l'on doit juger ces points de vue par leurs ressemblances au
+communisme soviétique, alors ce sont les propriétaires de logiciel qui sont
+les communistes.</p>
+
+<h3 id="premises">La question des prémisses</h3>
+<p>
+ Dans cet article, je pars du principe que l'utilisateur d'un logiciel n'est
+pas moins important qu'un auteur ou même que l'employeur d'un
+auteur. Autrement dit, lorsqu'on décide quelle est la meilleure marche à
+suivre, leurs intérêts et leurs besoins ont autant d'importance.</p>
+<p>
+ Cette prémisse n'est pas universellement admise. Beaucoup soutiennent que
+l'employeur d'un auteur est fondamentalement plus important que n'importe
+qui d'autre. Ils disent, par exemple, que la raison d'être de la propriété
+du logiciel est de donner à l'employeur les avantages qui lui sont dus
+– sans s'occuper de l'effet sur le public.</p>
+<p>
+ Cela ne sert à rien d'essayer de prouver la véracité ou la fausseté de ces
+prémisses. Prouver demande des prémisses partagées. C'est pourquoi la plus
+grande partie de mon discours s'adresse à ceux qui partagent les prémisses
+que j'utilise ou qui, du moins, sont intéressés par leurs conséquences. Pour
+ceux qui croient que les propriétaires sont plus importants que tous les
+autres, pour ceux-là, cet article n'est tout simplement pas pertinent.</p>
+<p>
+ Mais pourquoi un grand nombre d'Américains accepteraient-ils une prémisse
+qui élèverait certaines personnes au-dessus des autres ? En partie à cause
+de la croyance que cette prémisse fait partie des traditions juridiques de
+la société américaine. Certaines personnes ont le sentiment qu'en douter,
+c'est défier les bases de la société.</p>
+<p>
+ Il est important de faire savoir à ces personnes que cette prémisse ne fait
+pas partie de notre tradition juridique. Elle n'en a jamais fait partie.</p>
+<p>
+ Ainsi, la Constitution dit que l'objectif du copyright est de « promouvoir
+le progrès des sciences et des arts utiles ». La Cour suprême l'a expliqué,
+énonçant dans <em>Fox Film contre Doyal</em> que « l'intérêt unique des
+États-Unis ainsi que l'objet principal du monopole [du copyright] résident
+dans les avantages globaux que le public tire du travail des auteurs ».</p>
+<p>
+ Nous ne sommes pas obligés d'être d'accord avec la Constitution ni avec la
+Cour suprême (il fut un temps où elles ont toutes deux approuvé
+l'esclavage). Leurs positions ne réfutent donc pas la prémisse de la
+suprématie du propriétaire. Mais j'espère que son attrait faiblira quand les
+gens prendront conscience que c'est un postulat de la droite radicale qui
+n'a pas sa source dans nos traditions.</p>
+
+<h3 id="conclusion">Conclusion</h3>
+<p>
+ Nous aimons à croire que notre société encourage le fait d'aider son
+voisin ; mais chaque fois que nous récompensons quelqu'un pour avoir posé
+des obstacles sur sa route ou que nous l'admirons pour les richesses qu'il a
+accumulées par ce moyen, nous renvoyons le message contraire.</p>
+<p>
+ La thésaurisation du logiciel est un exemple de notre volonté généralisée de
+faire passer le gain personnel avant le bien-être de la société. On peut
+suivre cette volonté à la trace depuis Ronald Reagan jusqu'à Dick Cheney,
+depuis Exxon jusqu'à Enron, en passant par les faillites des banques et des
+écoles. Nous pouvons la mesurer à la taille de la population des sans-abri
+et de la population carcérale. L'esprit antisocial se nourrit de lui-même,
+parce que plus on voit que les autres ne nous tendront pas la main, plus il
+nous semble futile de les aider. Ainsi, notre société dégénère en jungle.</p>
+<p>
+ Si nous ne voulons pas vivre dans une jungle, nous devons changer nos
+attitudes. Nous devons commencer à lancer le message que le bon citoyen est
+celui qui coopère quand il le faut, pas celui qui réussit à prendre aux
+autres. J'espère que le mouvement du logiciel libre contribuera à cela : au
+moins dans un domaine, nous remplacerons la jungle par un système plus
+efficace qui encouragera la coopération volontaire et fonctionnera grâce à
+elle.</p>
+
+
+<h3 id="footnotes">Notes</h3>
+
+<ol>
+<li id="f1">Le mot <cite>free</cite> dans <cite>free software</cite> signifie « libre »,
+et non « gratuit » [<cite>free</cite> a les deux sens, en anglais] ; le prix
+payé pour un exemplaire d'un programme libre peut être nul, faible, ou
+(rarement) très élevé. <a href="#f1-rev" class="nounderline">&#8593;</a></li>
+
+<li id="f2">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. <a href="#f2-rev"
+class="nounderline">&#8593;</a></li>
+
+<li id="f3">On peut voir un logiciel particulier comme une chose nocive, qui ne devrait
+être accessible à personne, à l'instar de la base de données d'informations
+personnelles de Lotus (Marketplace), qui a été retirée de la vente suite à
+la désapprobation du public. La plus grande partie de mon discours ne
+s'applique pas à ce cas, mais préférer un propriétaire dans la mesure où
+cela rendrait le programme moins disponible n'est pas très sensé. Le
+propriétaire ne le rendra pas <em>complètement</em> indisponible, comme on
+pourrait le souhaiter pour un programme considéré comme nocif. <a
+href="#f3-rev" class="nounderline">&#8593;</a></li>
+</ol>
+
+<hr />
+<blockquote id="fsfs"><p class="big">Cet essai est publié dans <a
+href="http://shop.fsf.org/product/free-software-free-society/"><cite>Free
+Software, Free Society: The Selected Essays of Richard
+M. Stallman</cite></a>.</p></blockquote>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+<hr /><b>Notes de traduction</b><ol id="translator-notes-alpha">
+<li id="TransNote1">Autre traduction de <cite>proprietary</cite> :
+propriétaire. <a href="#TransNote1-rev" class="nounderline">&#8593;</a></li>
+<li id="TransNote2">Cet argument peut sembler étonnant à une personne
+résidant en France. Il faut savoir qu'aux États-Unis les
+<cite>interstates</cite> sont gratuites alors que les péages se concentrent
+au voisinage des grosses agglomérations. Avant la généralisation du
+télépéage, ils ralentissaient considérablement les trajets
+domicile-travail. <a href="#TransNote2-rev"
+class="nounderline">&#8593;</a></li>
+<li id="TransNote3">Dans ce paragraphe, ainsi que le suivant, on a un
+exemple de l'ambiguïté du mot <cite>free</cite> signalée dans la note
+n° 1. <a href="#TransNote3-rev" class="nounderline">&#8593;</a></li>
+<li id="TransNote4">En 1975, le seuil de pauvreté pour un homme (sic) seul
+de moins de 65 ans (hors agriculture) était de 2 902 $ par an, soit
+env. 56 $ par semaine et le revenu médian était de 10 540 $ (données du
+<cite>U.S. Census Bureau</cite>). <a href="#TransNote4-rev"
+class="nounderline">&#8593;</a></li>
+</ol></div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.fr.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Il existe aussi <a
+href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
+orphelins et autres corrections ou suggestions peuvent être signalés à <a
+href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
+
+<p>
+<!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:web-translators@gnu.org">
+
+ &lt;web-translators@gnu.org&gt;</a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+Nous faisons le maximum pour proposer des traductions fidèles et de bonne
+qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
+sur cette page, ainsi que vos suggestions d'ordre général sur les
+traductions, à <a href="mailto:web-translators@gnu.org">
+&lt;web-translators@gnu.org&gt;</a>.</p>
+<p>Pour tout renseignement sur la coordination et la soumission des
+traductions de nos pages web, reportez-vous au <a
+href="/server/standards/README.translations.html">guide de traduction</a>.</p>
+</div>
+
+<p>Copyright &copy; 1991, 1992, 1998, 2000, 2001, 2006, 2007, 2010, 2017, 2018
+2020 Free Software Foundation, Inc.</p>
+
+<p>Cette page peut être utilisée suivant les conditions de la licence <a
+rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/deed.fr">Creative
+Commons attribution, pas de modification, 4.0 internationale (CC BY-ND
+4.0)</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.fr.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+Traduction : Benjamin Drieu.<br /> Révision : <a
+href="mailto:trad-gnu&#64;april.org">trad-gnu&#64;april.org</a></div>
+
+<p class="unprintable"><!-- timestamp start -->
+Dernière mise à jour :
+
+$Date: 2020/07/01 16:32:17 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>