taler-merchant-demos

shouldbefree.html (57351B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
 
 <!--#include virtual="/server/header.fr.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="essays aboutfs principles" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Pourquoi le logiciel doit être libre - Projet GNU - Free Software Foundation</title>
 <style type="text/css" media="print,screen"><!--
 #content h3 { margin-top: 1.6em; }
 -->
 
 </style>
 
 <!--#include virtual="/philosophy/po/shouldbefree.translist" -->
 <!--#include virtual="/server/banner.fr.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.fr.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.fr.html" -->
 <div class="article reduced-width">
 <h2>Pourquoi le logiciel doit être libre</h2>
 
 <address class="byline">par <a href="https://www.stallman.org/">Richard Stallman</a></address>
 
 <p  id="introduction">
 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
 class="ftn" 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
 class="ftn" 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) <i>[free]</i>.<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 <i>[free]</i> 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 class="ftn" 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 <code>+</code> pour une addition ou le <code>-</code> 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 <i>free software</i> 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 <i>Free Software Foundation</i> 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>
 <div class="column-limit"></div>
 
 <h3 id="footnotes" class="footnote">Notes</h3>
 
 <ol>
 <li id="f1"><a href="#f1-rev" class="nounderline">&#8593;</a>
 Le mot <i>free</i> dans <i>free software</i> signifie « libre », et non
 « gratuit » [<i>free</i> 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é.</li>
 
 <li id="f2"><a href="#f2-rev" class="nounderline">&#8593;</a>
 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.</li>
 
 <li id="f3"><a href="#f3-rev" class="nounderline">&#8593;</a>
 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.</li>
 </ol>
 
 <hr class="no-display" />
 <div class="edu-note c"><p id="fsfs">Cet essai est publié dans <a
 href="https://shop.fsf.org/product/free-software-free-society/"><cite>Free
 Software, Free Society: The Selected Essays of Richard
 M. Stallman</cite></a>.</p></div>
 </div>
 
 <div class="translators-notes">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 <b>Notes de traduction</b><ol id="translator-notes-alpha">
 <li><a id="TransNote1" href="#TransNote1-rev"
 class="nounderline">&#8593;</a>
 Autre traduction de <i>proprietary</i> : propriétaire.</li>
 <li><a id="TransNote2" href="#TransNote2-rev"
 class="nounderline">&#8593;</a>
 Cet argument peut sembler étonnant à une personne résidant en France. Il
 faut savoir qu'aux États-Unis les <i>interstates</i> 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.</li>
 <li><a id="TransNote3" href="#TransNote3-rev"
 class="nounderline">&#8593;</a>
 Dans ce paragraphe, ainsi que le suivant, on a un exemple de l'ambiguïté du
 mot <i>free</i> signalée dans la note n° 1.</li>
 <li><a id="TransNote4" href="#TransNote4-rev"
 class="nounderline">&#8593;</a>
 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 <i>U.S. Census Bureau</i>).</li>
 </ol></div>
 </div>
 
 <!-- for id="content", starts in the include above -->
 <!--#include virtual="/server/footer.fr.html" -->
 <div id="footer" role="contentinfo">
 <div class="unprintable">
 
 <p>Veuillez envoyer les requêtes concernant la FSF et GNU à &lt;<a
 href="mailto:gnu@gnu.org">gnu@gnu.org</a>&gt;. 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 à
 &lt;<a href="mailto:webmasters@gnu.org">webmasters@gnu.org</a>&gt;.</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 contributing translations of
         our web pages, see <a
         href="/server/standards/README.translations.html">Translations
         README</a>. -->
 Merci d'adresser vos commentaires sur les pages en français à &lt;<a
 href="mailto:trad-gnu@april.org">trad-gnu@april.org</a>&gt;, et sur les
 traductions en général à &lt;<a
 href="mailto:web-translators@gnu.org">web-translators@gnu.org</a>&gt;. Si
 vous souhaitez y contribuer, vous trouverez dans le <a
 href="/server/standards/README.translations.html">guide de traduction</a>
 les infos nécessaires.</p>
 </div>
 
 <!-- Regarding copyright, in general, standalone pages (as opposed to
      files generated as part of manuals) on the GNU web server should
      be under CC BY-ND 4.0.  Please do NOT change or remove this
      without talking with the webmasters or licensing team first.
      Please make sure the copyright date is consistent with the
      document.  For web pages, it is ok to list just the latest year the
      document was modified, or published.
      
      If you wish to list earlier years, that is ok too.
      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
      years, as long as each year in the range is in fact a copyrightable
      year, i.e., a year in which the document was published (including
      being publicly visible on the web or in a revision control system).
      
      There is more detail about copyright years in the GNU Maintainers
      Information document, www.gnu.org/prep/maintain. -->
 <p>Copyright &copy; 1991, 1992, 1998, 2006, 2010, 2021 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: 2021/11/04 21:30:58 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>