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