path: root/talermerchantdemos/blog/articles/fr/shouldbefree.html

<!--#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>