taler-merchant-demos

stallman-kth.html (122101B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/stallman-kth.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="speeches" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Conférence de RMS au KTH (Suède, 1986) - Projet GNU - Free Software
 Foundation</title>
 <style type="text/css" media="screen"><!--
 #content span { font-style: italic; color: #505050; }
 -->
 </style>
 
 <!--#include virtual="/philosophy/po/stallman-kth.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>Conférence de RMS au KTH (Suède, 1986)</h2>
 
 <div class="infobox">
 <p>Transcription d'une conférence de Richard Stallman au <i>Kungliga Tekniska
 Högskolan</i> (Institiut royal de technologie), à Stockholm (Suède),
 organisée par l'association des étudiants, <i>Datorföreningen Stacken</i>,
 le 30 octobre 1986.
 </p>
 </div>
 <hr class="thin" />
 
 <div class="introduction">
 <p><i>[Note : Ce texte est une transcription légèrement révisée de la
 conférence. La version originale contient des faux départs ainsi que des
 locutions naturelles en anglais parlé mais qui paraissent bizarres dans une
 publication. Il n'est pas évident de la transformer en anglais écrit correct
 sans faire violence au discours original.]</i></p>
 </div>
 
 <p><b>RMS :</b> Il semble qu'il y ait trois choses dont les gens voudraient que
 je parle. Tout d'abord, j'ai pensé que le meilleur sujet ici pour un club de
 hackers était de dire comment ça se passait au <abbr title="Massachusetts
 Institute of Technology">MIT</abbr> autrefois, ce qui faisait du labo
 d'intelligence artificielle (labo d'IA) un endroit si particulier. Mais d'un
 autre côté on m'a suggéré, étant donné que les personnes qui sont ici ne
 sont pas celles qui étaient aux conférences de lundi et mardi, de raconter
 ce qui se passe dans le projet GNU, et de dire pourquoi le logiciel et
 l'information ne peuvent pas être considérés comme des propriétés. Cela fait
 un total de trois conférences. Et puisque deux de ces sujets prennent chacun
 une heure, nous y sommes pour un bon moment. Aussi je me suis dit que je
 pourrais éventuellement diviser la conférence en trois parties. Comme ça les
 gens pourraient sortir quand ça ne les intéresse pas. Une fois arrivé à la
 fin d'un sujet, je peux signaler que c'est fini, les gens peuvent sortir et
 je peux envoyer Jan Rynning dehors pour appeler les autres.</p>
 
 <p><span>[Quelqu'un : « <i>Janne, han trenger ingen mike.</i> » (Janne, il n'a
 pas besoin de micro.)]</span></p>
 
 <p>Jan, tu es prêt à courir chercher les autres ?</p>
 
 <p><b>JMR :</b> Je suis à la recherche d'un micro et quelqu'un me dit qu'il est
 dans ce casier fermé à clé.</p>
 
 <p><b>RMS :</b> Autrefois au labo d'IA, on l'aurait ouvert à coup de masse et
 la porte défoncée aurait servi de leçon à celui qui avait osé mettre sous
 clé quelque chose dont tout le monde avait besoin. Mais heureusement j'ai
 étudié le chant bulgare, donc je peux très bien me débrouiller sans micro.</p>
 
 <p>Bon, est-ce que je dois vous signaler les différentes parties de la
 conférence ou vous avez juste envie de la suivre jusqu'au bout ?
 <span>[Réponse : Yeaaah !]</span></p>
 
 <p>Quand j'ai commencé à programmer, c'était en 1969, dans un laboratoire d'IBM
 à New York. Ensuite, je suis allé dans une école qui avait un département
 d'informatique probablement semblable à la plupart des autres. Il y avait
 quelques professeurs responsables de ce qu'on était censé y faire et il y
 avait des gens qui décidaient de qui pouvait se servir de quoi. Il y avait
 pénurie de terminaux pour la plupart d'entre nous. Or pas mal de professeurs
 en avaient un personnellement dans leur bureau, ce qui était du gaspillage,
 mais typique de leur attitude. Quand j'ai visité le labo d'intelligence
 artificielle au MIT, j'ai trouvé une atmosphère qui était une bouffée d'air
 pur par rapport à ça. Par exemple : là, on considérait que les terminaux
 étaient à tout le monde et les professeurs qui les enfermaient à clef dans
 leurs bureaux couraient le risque de voir leurs portes défoncées. On m'a
 montré une fois un chariot avec un gros bloc de fer dessus. C'était celui
 qui avait été utilisé pour défoncer la porte du bureau d'un des professeurs
 quand il avait eu le culot d'y enfermer un terminal. Il y en avait très peu
 à cette époque. Il y avait probablement quelque chose comme cinq terminaux à
 écran pour tout le système ; aussi, si l'un d'entre eux était sous clé,
 c'était une vraie catastrophe.</p>
 
 <p>Dans les années qui ont suivi, j'ai été guidé par ces idées et il m'est
 souvent arrivé de crapahuter au-dessus des plafonds ou sous les planchers
 pour déverrouiller les salles qui contenaient des machines dont les gens
 avaient besoin. Et je laissais généralement un mot qui expliquait aux gens
 qu'il ne fallait pas fermer la porte à clé de manière aussi égoïste. Les
 gens qui fermaient la porte à clé, au fond, ne pensaient qu'à eux. Ils
 avaient une raison de le faire, bien sûr. Il y avait un truc qui,
 pensaient-ils, pouvait tenter les voleurs, et ils voulaient l'enfermer à
 clef. Mais ils ne s'occupaient pas des autres, que cela gênait de ne pas
 avoir accès au reste du matériel qui était dans la même salle. Presque à
 chaque fois que cela s'est produit – après avoir porté à leur attention
 qu'il ne leur appartenait pas de décider du verrouillage de la porte – ils
 étaient capables de trouver un compromis. Mais le problème, c'est que les
 gens ne prennent pas la peine d'y penser. Ils se disent : « Cette salle est
 à moi, je peux la fermer à clé, que les autres aillent au diable ! » C'est
 précisément cette attitude que nous devons leur désapprendre.</p>
 
 <p>Mais cette habitude de déverrouiller les portes n'était pas un comportement
 isolé, il faisait partie d'une façon de vivre à part entière. Les hackers du
 labo d'IA étaient vraiment passionnés par l'écriture de bons programmes, de
 programmes intéressants. Ils étaient à ce point impatients de faire avancer
 le travail qu'ils ne supportaient pas la mise sous clé des terminaux, ni un
 tas d'autres comportements qui faisaient obstacle au travail utile. C'est la
 différence entre des personnes très motivées qui se préoccupent vraiment de
 ce qu'elles sont en train de faire et des personnes qui prennent ça juste
 pour un boulot. Si c'est juste un boulot, qu'importe si les gens qui vous
 ont embauché sont assez stupides pour vous obliger à attendre sans rien
 faire. C'est leur temps, leur argent, mais pas grand-chose ne se fait dans
 un endroit comme ça ; ce n'est pas drôle d'être dans un endroit comme ça.</p>
 
 <p>Une autre chose que nous n'avions pas au labo d'IA, c'était la protection
 des fichiers. Il n'y avait aucune sécurité sur l'ordinateur, et c'était une
 décision mûrement réfléchie. Les hackers qui ont écrit ITS<a
 id="TransNote1-rev" href="#TransNote1"><sup>1</sup></a> ont jugé que la
 protection des fichiers n'était qu'un moyen comme un autre, pour un
 administrateur système autoproclamé, d'avoir du pouvoir sur tout le
 monde. Ils ont refusé que quiconque puisse avoir du pouvoir sur eux de cette
 façon. Aussi, ils n'ont pas implémenté ce genre de dispositif. Résultat,
 chaque fois que quelque chose était cassé dans le système, vous pouviez
 toujours le réparer. Vous n'étiez jamais obligé de rester planté là,
 frustré, parce qu'il n'y avait RIEN À FAIRE, alors que vous saviez
 parfaitement quoi faire mais que quelqu'un avait décidé de ne pas vous faire
 confiance. Vous n'étiez pas obligé de laisser tomber et de rentrer à la
 maison en attendant le lendemain matin que quelqu'un vienne réparer le
 système, alors que vous saviez dix fois mieux que lui ce qu'il fallait
 faire.</p>
 
 <p>Et nous ne laissions pas non plus de professeur, ni de patron, décider quel
 devait être notre prochain travail, parce que notre travail c'était
 d'améliorer le système ! Nous parlions aux utilisateurs évidemment ; si vous
 ne faites pas ça, vous ne pouvez pas savoir ce dont ils ont besoin. Mais
 ensuite, nous étions les seuls, les plus aptes à savoir quelles sortes
 d'améliorations étaient possibles. Et nous discutions toujours entre nous
 pour savoir comment nous voulions voir le système évoluer, quelles idées
 astucieuses nous avions vues dans d'autres systèmes et pourrions
 utiliser. Ainsi au final, nous avions une anarchie qui fonctionnait sans
 à-coups ; d'après mon expérience là-bas, je suis convaincu que c'est la
 meilleure façon de vivre.</p>
 
 <p>Malheureusement le labo d'IA, tel qu'il était à cette époque, a été
 détruit. Pendant des années nous avions craint qu'il ne soit détruit par un
 autre labo du MIT, le labo d'informatique, dont le directeur était le genre
 de type à construire un empire. Il faisait tout ce qu'il pouvait pour avoir
 une promotion au MIT et faire grossir son organisation. Il essayait
 continuellement d'annexer le labo d'IA. Personne ne voulait faire les choses
 à sa manière parce qu'il croyait que les gens devaient obéir aux ordres et
 d'autres choses dans le style.</p>
 
 <p>Mais ce danger, nous avons réussi à le repousser pour être en fin de compte
 détruits par une chose que nous n'avions pas prévue : l'esprit
 commercial. Vers le début des années 80, les hackers ont soudain compris que
 ce qu'ils faisaient avait désormais un intérêt commercial. Il était possible
 de devenir riche en travaillant pour une société privée. Il leur suffisait
 de cesser de partager leur travail avec le reste du monde et de détruire le
 labo d'IA du MIT. Et c'est ce qu'ils ont fait, malgré tous mes efforts pour
 les en empêcher.</p>
 
 <p>Presque tous les programmeurs compétents du labo d'IA, excepté moi, ont été
 embauchés ailleurs et cela a causé bien plus qu'un changement
 provisoire. Cela a causé une métamorphose définitive, parce que ça a brisé
 la continuité de la culture des hackers. Les nouveaux hackers sont toujours
 attirés par les anciens. Il y avait là les ordinateurs les plus amusants et
 les gens qui faisaient les choses les plus intéressantes avec. Et aussi une
 atmosphère qu'il était très amusant de partager. Une fois cela disparu, il
 ne restait rien pour attirer les nouveaux venus. Ils ont donc cessé
 d'arriver. Il n'y avait plus personne pour les inspirer, personne pour leur
 enseigner les traditions. Qui plus est, personne de qui apprendre à bien
 programmer. Avec juste un tas de professeurs et de doctorants qui ne savent
 pas vraiment comment faire marcher un programme, on ne peut pas apprendre à
 faire fonctionner de bons programmes. Ainsi le labo d'IA du MIT que j'aimais
 a disparu. Et après deux années passées à me battre contre les gens qui
 avaient fait ça, pour essayer de les punir, j'ai décidé de me consacrer à
 créer une nouvelle communauté ayant cet état d'esprit.</p>
 
 <p>Mais un des problèmes auxquels j'ai dû faire face était celui des logiciels
 <a
 href="/philosophy/categories.html#ProprietarySoftware">propriétaires</a>.<a
 id="TransNote2-rev" href="#TransNote2"><sup>2</sup></a> Par exemple, ce qui
 s'est passé au labo une fois les hackers partis, c'est que les machines et
 les logiciels que nous avions développés ne pouvaient plus être
 maintenus. Bien sûr Les logiciels fonctionnaient et continuaient de
 fonctionner si personne ne les modifiait, mais pas les machines. Les
 machines tombaient en panne et personne ne pouvait les réparer, et ensuite
 on les mettait au rebut. Autrefois, il y avait bien des contrats d'entretien
 pour les machines, mais pour l'essentiel c'était du bidon. C'était une
 manière d'obtenir des pièces détachées une fois que les hackers experts du
 labo d'IA avaient réparé. Parce que si on avait attendu que les techniciens
 de maintenance le fassent, ça aurait pris des jours. Et on ne voulait pas de
 ça. On voulait que ça marche. Aussi, les gens qui savaient faire ce genre de
 chose réparaient très vite, puisqu'ils étaient dix fois plus compétents que
 n'importe quel technicien. Ils pouvaient faire un bien meilleur travail. Et
 une fois qu'ils avaient démonté les circuits défectueux, il leur suffisait
 de les mettre de côté et d'appeler le technicien : « Reprenez-les et
 ramenez-nous-en des neufs. »</p>
 
 <p>À la belle époque, nos hackers avaient également l'habitude de modifier les
 machines qui venaient de Digital. Par exemple, ils ont construit des boîtes
 de radiomessagerie <i>[paging]</i> pour les PDP-10. De nos jours, je pense
 qu'il y en a certains ici [à Stockholm] qui le font aussi. Mais ce n'était
 pas courant en ce temps-là. Et encore avant, au début des années 60, les
 gens modifiaient les ordinateurs en ajoutant toutes sortes de nouvelles
 instructions et de nouvelles fonctionnalités sophistiquées en temps
 partagé. De sorte que le PDP-1 du MIT, avant qu'il ne parte à la retraite
 dans les années 70, avait quelque chose comme deux fois plus d'instructions
 qu'il n'en avait lors de sa livraison par Digital au début des années 60. Il
 avait des fonctionnalités spéciales complétant l'ordonnanceur
 <i>[scheduler]</i> matériel, d'étranges fonctionnalités de mappage de la
 mémoire qui permettaient d'affecter individuellement chaque périphérique
 matériel à une tâche en temps partagé, et des tas d'autres trucs dont j'ai à
 peine entendu parler. Je pense qu'ils ont également rajouté une sorte de
 mode d'adressage étendu, des registres d'indexation ainsi que l'adressage
 indirect ; en somme ils ont transformé une toute petite machine en une
 machine à peu près correcte.</p>
 
 <p>Je suppose que c'est l'un des inconvénients de la <abbr title="Very Large
 Scale Integration">VLSI</abbr> (intégration à très grande échelle) : il
 n'est plus vraiment pratique d'ajouter des instructions sur vos machines.</p>
 
 <p>Le PDP-1 avait une caractéristique très intéressante : il était possible
 d'écrire des programmes intéressants avec un très petit nombre
 d'instructions, moins qu'aucune autre machine construite depuis. Je crois
 par exemple que le célèbre hack d'affichage <i>munching squares</i> (lit. :
 grignotage de carrés) – qui traçait des carrés qui grandissaient puis se
 brisaient en une multitude de petits carrés qui devenaient plus grands et se
 brisaient en petits carrés – cela a été écrit en quelque chose comme cinq
 instructions sur le PDP-1. Et beaucoup d'autres beaux programmes d'affichage
 ont pu être écrits ainsi avec un très petit nombre d'instructions.</p>
 
 <p>Voilà donc ce qu'était le labo d'IA. Mais c'était quoi la culture des
 hackers, hormis leur anarchisme ? Au temps du PDP-1, la machine ne pouvait
 être utilisée que par une personne à la fois, du moins au début. Plusieurs
 années après, ils ont écrit un système fonctionnant en temps partagé et ils
 ont rajouté pas mal de matériel pour ça. Mais au début, on pouvait seulement
 s'inscrire pour une période donnée. Naturellement les professeurs et les
 étudiants qui travaillaient sur des projets officiels venaient toujours
 pendant la journée. Alors, les gens qui voulaient avoir plus de temps
 s'inscrivaient pour la nuit quand il y avait moins d'affluence. Voilà
 l'origine de la coutume hacker de travailler la nuit. Même lorsqu'il y eut
 le temps partagé, il était toujours plus facile d'avoir du temps la nuit, on
 pouvait avoir plus de cycles parce qu'il y avait peu d'utilisateurs. Aussi
 ceux qui voulaient abattre beaucoup de travail continuaient à venir la
 nuit. Mais ça a commencé à changer parce qu'on n'était pas seul, il y avait
 là quelques autres hackers ; ainsi c'est devenu un phénomène social. Si vous
 entriez pendant la journée, vous pouviez vous attendre à trouver des
 professeurs et des étudiants qui n'étaient pas des fans de la machine, alors
 que si vous veniez la nuit vous trouviez des hackers. Par conséquent, les
 hackers sont venus la nuit pour partager leur culture. Et ils ont développé
 d'autres traditions, comme d'aller se ravitailler au Chinois à trois heures
 du matin. Je me rappelle avoir vu beaucoup de levers de soleil alors que je
 revenais en voiture de Chinatown. C'était tellement beau de voir le lever de
 soleil, c'est une heure tellement calme de la journée. C'est une heure
 merveilleuse pour se préparer à aller dormir. Il est si agréable de rentrer
 à pied chez soi dans une lumière qui commence juste à poindre avec les
 oiseaux qui se mettent à gazouiller. On a une sensation de douce
 satisfaction, de tranquillité, en pensant au travail accompli pendant la
 nuit.</p>
 
 <p>Une autre tradition que nous avons initiée était celle d'avoir des endroits
 pour dormir au labo. Depuis le jour où j'y suis entré, il y a toujours eu au
 moins un lit. Et j'ai probablement habité au labo un peu plus longtemps que
 la plupart des autres car, tous les ans ou tous les deux ans, pour une
 raison ou une autre, je n'avais pas d'appartement et j'y habitais quelques
 mois. Et j'ai toujours trouvé que c'était très confortable, sans compter que
 c'était sympa et frais en été. Mais il n'était pas rare du tout de tomber
 sur des gens qui s'étaient endormis au labo, toujours à cause de leur
 enthousiasme : vous restez le plus longtemps possible à hacker parce que
 vous ne voulez pas vous arrêter, et une fois que vous êtes complètement
 épuisé, vous escaladez la surface horizontale souple la plus proche. Une
 ambiance vraiment sans cérémonie.</p>
 
 <p>Mais quand les hackers sont tous partis du labo, ça a causé un changement
 démographique parce que les professeurs et les étudiants qui n'étaient pas
 vraiment des fans de la machine étaient aussi nombreux qu'auparavant ;
 maintenant ils représentaient la majorité. Et ils ont vraiment eu peur. Sans
 hacker pour entretenir le système, ils se sont dit : « Ça va être un
 désastre, il nous faut du logiciel commercial. Comme ça, nous pourrons
 compter sur la maintenance de l'entreprise. » La suite prouva qu'ils avaient
 absolument tort, mais c'est ce qu'ils ont fait.</p>
 
 <p>C'était exactement au moment où ils devaient recevoir un nouvel ordinateur,
 le KL-10, et la question s'est alors posée : faut-il qu'il fonctionne avec
 ITS ou bien Twenex, le système de Digital ? Une fois les hackers partis
 – ils auraient sans doute poussé à utiliser le leur – les universitaires ont
 choisi d'utiliser le logiciel commercial et cela eut plusieurs effets
 immédiats. Certains n'ont pas été vraiment immédiats, mais ils en ont
 découlé inévitablement comme l'aurait prévu n'importe qui avec un peu de
 réflexion.</p>
 
 <p>Le premier problème était que ce logiciel était beaucoup plus mal écrit et
 plus difficile à comprendre qu'ITS, rendant donc plus difficiles les
 modifications nécessaires. L'autre était que le logiciel était sécurisé, ce
 qui eut pour effet inévitable de diminuer la collaboration entre les uns et
 les autres. Dans le passé, sur ITS, nous trouvions souhaitable d'avoir accès
 à tous les fichiers et de pouvoir modifier n'importe lequel, parce que nous
 avions des raisons pour cela. Je me rappelle un scandale intéressant où
 quelqu'un a envoyé une demande d'assistance en utilisant Macsyma. Macsyma
 est un programme d'algèbre symbolique qui a été développé au MIT. Il a
 envoyé une demande d'assistance à l'une des personnes qui travaillait dessus
 et a obtenu une réponse quelques heures plus tard de la part de quelqu'un
 d'autre. Il était horrifié. Il a envoyé le message suivant : « Untel doit
 lire votre courrier, les fichiers de courrier ne sont peut-être pas
 correctement protégés sur votre système ? » – « Naturellement, aucun dossier
 n'est protégé sur notre système. Où est le problème ? Vous avez obtenu votre
 réponse plus tôt, de quoi vous plaignez-vous ? Évidemment nous lisons le
 courrier de tout le monde, comme ça nous pouvons tomber sur des personnes
 comme vous et les aider. » Certains ne connaissent pas leur bonheur.</p>
 
 <p>Bien sûr, Twenex n'est pas seulement muni d'une sécurité – et par défaut la
 sécurité est activée – mais il est également conçu en partant de l'hypothèse
 que la sécurité est active. Or il y a un bon nombre de trucs très faciles à
 faire qui peuvent causer pas mal de dégâts et la seule chose qui vous
 empêche de les faire par accident, c'est la sécurité. Sur ITS, nous avions
 développé d'autres moyens d'éviter que les gens fassent ces trucs par
 accident, mais sur Twenex on ne les avait pas, étant donné que des mesures
 de sécurité strictes étaient censées être opérationnelles et que les chefs
 étaient les seuls à avoir la possibilité de faire des erreurs. Donc, ils
 n'avaient mis aucun autre mécanisme de sécurité pour éviter les
 accidents. Le résultat, c'est qu'on ne pouvait plus se contenter de
 désactiver la sécurité de Twenex pour avoir ce qu'on voulait. Et il n'y
 avait plus les hackers pour faire les changements nécessaires à
 l'introduction de ces autres mécanismes. Aussi les gens ont-ils été obligés
 de travailler avec la sécurité. Et la machine était là depuis six mois à peu
 près, quand il a commencé à y avoir quelques « coups d'État ». Au début nous
 avons supposé que tous ceux qui travaillaient pour le labo allaient avoir le
 <i>wheel bit</i><a id="TransNote3-rev" href="#TransNote3"><sup>3</sup></a>
 qui leur donnerait les pleins pouvoirs pour désactiver la sécurité, mais
 certains jours vous veniez dans l'après-midi pour découvrir que les <i>wheel
 bits</i> d'à peu près tout le monde avaient été supprimés.</p>
 
 <p>Quand je m'en suis rendu compte, j'ai rectifié la situation. La première
 fois, il se trouve que je connaissais le mot de passe d'un des membres de
 l'élite et que j'ai pu l'utiliser pour redonner à chacun ses privilèges. La
 deuxième fois, il avait changé son mot de passe, il avait changé de
 relations sociales, il appartenait désormais au parti aristocrate. Alors
 j'ai dû arrêter la machine et utiliser le système DDT<a id="TransNote4-rev"
 href="#TransNote4"><sup>4</sup></a> en temps non partagé pour fouiller un
 peu partout. J'ai fouillé dans le moniteur pendant un moment et j'ai compris
 à la fin comment faire pour qu'il se charge et que je puisse le patcher. De
 sorte que j'ai pu bloquer le contrôle des mots de passe et ainsi redonner
 leur <i>wheel bit</i> à plein de gens. Puis j'ai laissé un message
 système. Le nom de cette machine était OZ et le message disait : « Il y a eu
 une nouvelle tentative de prise du pouvoir, jusqu'ici les forces
 aristocratiques sont battues – <i>Radio Free OZ</i> (la radio libre d'Oz). »
 Plus tard j'ai découvert que <i>Radio Free OZ</i> est l'une des expressions
 utilisées par le <i>Firesign Theater</i>. Je ne le savais pas à ce
 moment-là.</p>
 
 <p>Mais petit à petit les choses ont empiré – c'est juste la façon dont le
 système avait été construit qui forçait les gens à exiger de plus en plus de
 sécurité – jusqu'à ce que, finalement, je sois obligé d'arrêter d'utiliser
 la machine parce que je refusais d'avoir un mot de passe secret. Depuis que
 les mots de passe étaient apparus pour la première fois au labo d'IA du MIT,
 j'en étais venu à la conclusion que pour respecter mes convictions, pour
 agir en accord avec mes convictions, il ne devait y avoir aucun mot de
 passe. Je dois toujours veiller à avoir un mot de passe aussi évident que
 possible et le dire à tout le monde. Puisque je ne crois pas qu'il soit
 vraiment souhaitable d'avoir une sécurité sur un ordinateur, je ne dois pas
 aider au maintien du régime de sécurité. Sur les systèmes qui le permettent,
 j'utilise un « mot de passe vide » et sur des systèmes où cela n'est pas
 permis (où cela signifie que vous ne pouvez pas ouvrir de session de
 l'extérieur, des choses comme ça), j'utilise mon nom d'utilisateur comme mot
 de passe. C'est aussi évident que possible. Et quand les gens me font
 remarquer que de cette manière on peut ouvrir une session sous mon nom, je
 réponds : « Oui, c'est ça l'idée, quelqu'un pourrait avoir besoin de
 certaines données sur cette machine. Je veux m'assurer qu'elles ne se feront
 pas avoir par la sécurité. »</p>
 
 <p>Et une autre chose que je fais toujours, c'est de désactiver la protection
 sur mon répertoire et mes dossiers. Parce que de temps en temps j'y stocke
 des programmes utiles et s'il y a un bogue je veux que les gens puissent le
 corriger.</p>
 
 <p>Mais cette machine n'avait pas non plus été conçue pour gérer un phénomène
 appelé « tourisme ». Le tourisme était une très vieille tradition du labo
 d'IA qui allait avec nos autres conceptions de l'anarchie. Elle disait que
 nous devions laisser les gens de l'extérieur utiliser la machine. À l'époque
 où n'importe qui pouvait venir se connecter à ce qui lui plaisait, c'était
 automatique : comme visiteur, vous pouviez ouvrir une session pour
 travailler. Plus tard nous avons plus ou moins formalisé ça comme une
 tradition établie, particulièrement quand l'Arpanet s'est mis en place et
 que les gens ont commencé à se connecter à nos machines à partir de
 n'importe quel coin du pays. Ce que nous espérions, c'était que ces
 personnes apprendraient vraiment à programmer et qu'elles commenceraient à
 modifier le système d'exploitation. Si vous disiez ça à un administrateur
 système n'importe où ailleurs, il serait horrifié. Si vous lui proposiez
 l'idée que n'importe quel étranger puisse utiliser la machine, il
 répondrait : « Et s'il commence à modifier nos programmes ? » Mais pour
 nous, si un étranger commençait à modifier les programmes, cela signifiait
 qu'il montrait un intérêt réel à devenir un membre contributif de la
 communauté. Nous encouragions toujours les gens à le faire ; à commencer,
 naturellement, par écrire de nouveaux utilitaires, des petits. Nous jetions
 un œil sur ce qu'ils avaient fait et nous le corrigions. Ils en arrivaient
 alors à ajouter des fonctionnalités à de grands utilitaires existants. Et ce
 sont des programmes qui existent depuis une dizaine ou peut-être une
 quinzaine d'années, et grandissent petit à petit à mesure que les artisans,
 l'un après l'autre, ajoutent de nouvelles fonctionnalités.</p>
 
 <p>C'est pour ainsi dire comme certaines villes de France, où l'on peut voir
 des bâtiments extrêmement anciens avec des rajouts construits des centaines
 d'années plus tard, jusqu'à aujourd'hui. Dans le domaine de l'informatique,
 un programme qui a été commencé en 1965, c'est à peu près ça. Ainsi nous
 espérions toujours que des touristes deviendraient mainteneurs du système ;
 et peut-être qu'ensuite ils allaient être embauchés, après avoir commencé à
 travailler sur les programmes du système et nous avoir montré qu'ils étaient
 capables de faire du bon travail.</p>
 
 <p>Mais il y avait sur les machines ITS certains autres dispositifs qui
 aidaient à éviter que ça nous échappe. L'un d'entre eux était un dispositif
 « espion » où tout le monde pouvait observer ce que chacun faisait. Et
 naturellement les touristes adoraient espionner. Ils pensaient que c'était
 super. C'était un peu méchant, voyez-vous, mais le résultat, c'était que si
 un touriste commençait à faire un truc à problème, il y avait toujours
 quelqu'un pour le voir. Donc assez vite ses amis étaient furieux parce
 qu'ils savaient que pour que le tourisme continue à exister, il fallait des
 touristes responsables. Aussi y avait-il forcément quelqu'un qui savait qui
 c'était et nous pouvions lui dire de nous laisser tranquilles. Et si nous ne
 pouvions pas, alors ce que nous faisions, c'était d'interdire les connexions
 provenant de certains endroits pendant un moment, et quand nous les
 autorisions à nouveau il était parti et nous avait oubliés. Et cela a
 continué comme ça pendant des années, des années&hellip; et des années.</p>
 
 <p>Mais le système Twenex n'avait pas été conçu pour ce genre de chose et par
 la suite ils ne m'ont plus toléré, moi et mon mot de passe que tout le monde
 connaissait. Les touristes n'arrêtaient pas d'ouvrir des sessions sous mon
 nom, à deux ou trois à la fois, et ont commencé à vider mon compte. À ce
 moment-là de toute façon, je travaillais le plus souvent sur d'autres
 machines ; si bien que finalement je l'ai abandonné et cessé à tout jamais
 de le réactiver. C'est tout. Je ne me suis pas connecté sur cette machine
 sous mon nom pendant&hellip; <span>[À ce moment-là, RMS est interrompu par
 un tonnerre d'applaudissements.]</span></p>
 
 <p>Quand ils ont installé le système Twenex, ils avaient à l'esprit d'y faire
 plusieurs changements, des changements dans le fonctionnement de la
 sécurité. Ils voulaient aussi mettre la machine sur le réseau <abbr
 title="Advanced Research Projects Agency">ARPA</abbr> ainsi que sur le
 réseau Chaos du MIT. Et il se trouve qu'ils n'ont pas pu le faire, qu'il n'y
 avait personne d'assez compétent pour ça. Il n'y avait plus de talent
 disponible et il était difficile de changer ça. Ce système était beaucoup
 plus difficile à comprendre qu'ITS parce qu'il était mal écrit, et
 naturellement Digital ne voulait pas faire ce genre de chose. Ainsi l'idée
 d'un système commercial qui se maintenait tout seul s'est révélée
 erronée. Ils avaient absolument besoin de hackers mais n'avaient plus les
 moyens de les attirer. Et de nos jours au MIT, il y a davantage de gens que
 ça intéresse de hacker ITS que Twenex.</p>
 
 <p>La dernière raison de cet état de fait, c'est que Twenex ne pouvait pas être
 partagé. Twenex est un programme propriétaire : vous n'avez le droit d'avoir
 les sources que si vous les gardez secrètes par des moyens très
 déplaisants. Et ça leur donne mauvais goût, à moins d'être inconscient comme
 le sont certains en informatique (il y en a qui feront n'importe quoi si
 c'est amusant pour eux et ne penseront pas une minute à coopérer avec qui
 que ce soit ; mais il faut être franchement ailleurs pour ne pas remarquer à
 quel point c'est triste de travailler comme ça sur un programme, comme c'est
 décourageant). Et comme si ce n'était pas suffisant, chaque année ils vous
 donnent une nouvelle version remplie d'une cinquantaine de milliers de
 lignes de code supplémentaires, toutes écrites par des singes. Parce qu'ils
 suivent généralement une école de programmation système du genre « un
 million de singes tapant sur une machine à écrire finiront bien un jour par
 sortir quelque chose d'utile ».</p>
 
 <p>Il était clair pour moi, après avoir vu ce qui arrivait à ces systèmes
 propriétaires, que la seule façon de conserver l'esprit du vieux labo d'IA
 était d'avoir un système d'exploitation libre ; d'avoir un système fait de
 logiciel libre pouvant être partagé avec n'importe qui, de façon à pouvoir
 inviter tout le monde à collaborer à son amélioration. Et c'est ce qui a
 conduit au projet GNU. Ainsi j'estime que nous sommes arrivés à la deuxième
 partie de la conférence.</p>
 
 <p>Il y a environ trois ans et demi, il m'est apparu comme une évidence que je
 devais commencer à développer un système constitué de <a
 href="/philosophy/free-sw.html">logiciel libre</a>. J'envisageais deux types
 de systèmes : le premier, pratiquement identique au système de machine Lisp
 du MIT, mais libre et fonctionnant sur tout type de matériel, pas seulement
 sur les machines Lisp spécialisées, et l'autre, un logiciel d'exploitation
 plus conventionnel. Et il était clair pour moi que si je faisais un logiciel
 d'exploitation conventionnel, je devais le rendre compatible avec Unix parce
 que ça rendait la migration plus facile aux gens de tous horizons. Après
 quelque temps, j'ai choisi la deuxième solution. Et la raison, c'était qu'il
 n'était pas possible d'obtenir quelque chose de vraiment comparable au
 système de machine Lisp sur du matériel polyvalent. Le système de machine
 Lisp utilise du matériel spécial, avec un microcode spécial réinscriptible,
 pour obtenir à la fois une bonne vitesse d'exécution et une détection
 robuste des erreurs pendant le temps d'exécution, en particulier les erreurs
 sur le type des données. Pour qu'un système Lisp puisse fonctionner assez
 rapidement sur du matériel ordinaire, on doit commencer par faire des
 suppositions, supposer que tel argument est du type voulu ; ensuite, si ce
 n'est pas le cas, le système se plante.</p>
 
 <p>Naturellement on peut mettre des contrôles explicites, on peut écrire un
 programme robuste si on veut, mais le fait est qu'on va obtenir des trucs
 comme des erreurs d'adressage de mémoire si l'on fournit à une fonction un
 argument de type inapproprié sans RIEN prévoir pour faire la vérification.</p>
 
 <p>Le résultat, c'est qu'il fallait que quelque chose fonctionne en dessous du
 système Lisp pour détecter ces erreurs et permettre à l'utilisateur de
 garder le système en état de marche et de déboguer les problèmes
 éventuels. J'en suis arrivé à la conclusion que si je devais avoir un
 système d'exploitation de bas niveau, je pouvais tout aussi bien faire un
 bon système d'exploitation – le choix était entre un système d'exploitation
 plus le Lisp, et juste un système d'exploitation ; donc je devais faire le
 système d'exploitation d'abord et le rendre compatible avec Unix. Enfin,
 quand j'ai réalisé que je pouvais utiliser le plus drôle des mots anglais
 pour nommer ce système, le choix était clair. Et ce mot est bien sûr GNU,
 qui signifie <i>GNU's Not Unix</i> (GNU N'est pas Unix). L'acronyme récursif
 est une très vieille tradition dans la communauté de hackers qui gravite
 autour du MIT. Il a commencé je crois, avec un éditeur appelé TINT, ce qui
 signifie <i>Tint Is Not <abbr title="Text Editor and
 COrrector">Teco</abbr></i>, et plus tard c'est passé par des noms comme SINE
 pour <i>Sine Is Not Emacs</i>, et FINE pour <i>Fine Is Not Emacs</i>, et
 EINE pour <i>Eine Is Not Emacs</i>, et ZWEI pour <i>Zwei Was Eine
 Initially</i>, et finalement on est arrivé à GNU.</p>
 
 <p>Je dirais que depuis le moment, il y a environ deux ans et demi, où j'ai
 commencé à travailler vraiment sur GNU, j'ai déjà fait plus de la moitié du
 travail. Au moment où j'étais prêt à démarrer le projet, j'ai d'abord
 regardé autour de moi ce qu'il y avait de libre déjà disponible. J'ai
 découvert un système de compilation portable appelé <i>the Free University
 Compiler Kit</i>, qui était intéressant, et j'ai pensé qu'avec un nom pareil
 je pourrais peut-être l'avoir.<a id="TransNote5-rev"
 href="#TransNote5"><sup>5</sup></a> Alors j'ai envoyé un message à son
 développeur en lui demandant s'il acceptait de le donner au projet GNU. Et
 il a dit « Non, l'université est peut-être libre, mais le logiciel qu'elle
 développe ne l'est pas », mais il a ajouté qu'il voulait aussi avoir un
 système compatible avec Unix et qu'il voulait écrire une sorte de noyau pour
 lui, alors pourquoi est-ce que je n'écrirais pas les utilitaires, comme ça
 les deux pourraient être distribués avec son compilateur propriétaire ? Ça
 encouragerait les gens à l'acheter. J'ai pensé que c'était ignoble, alors je
 lui ai dit que mon premier projet serait de faire un compilateur.</p>
 
 <p>Je ne savais pas vraiment grand-chose au sujet de l'optimisation des
 compilateurs à cette époque parce que je n'avais jamais travaillé
 dessus. Mais j'ai mis la main sur un compilateur dont on m'avait dit qu'il
 était libre. C'était un compilateur appelé Pastel dont les auteurs disaient
 que c'était du « Pascal mal fichu ».</p>
 
 <p>Le Pastel est un langage très compliqué comprenant des fonctionnalités comme
 des types paramétrés et des paramètres de types explicites et beaucoup de
 choses compliquées. Le compilateur naturellement était écrit dans ce langage
 et comportait nombre de fonctionnalités compliquées pour optimiser
 l'utilisation de ces éléments. Par exemple : le type <i>string</i> dans ce
 langage était un type paramétré ; vous pouviez dire <code>string(n)</code>
 si vous vouliez une chaîne d'une longueur particulière ; vous pouviez
 également juste dire <code>string</code>, et le paramètre était déterminé à
 partir du contexte. Cela dit, les chaînes sont très importantes et sont
 nécessaires à beaucoup de constructions qui les utilisent pour fonctionner
 rapidement. Et ça veut dire qu'on avait besoin de beaucoup de
 fonctionnalités pour détecter des choses comme : lorsque la longueur
 déclarée d'une chaîne est un argument dont on sait qu'il est constant dans
 toute la fonction, sauvegarder la valeur et optimiser le code qu'elle va
 produire ; beaucoup de choses compliquées. Mais j'ai pu voir dans ce
 compilateur comment procéder à l'allocation automatique de registre et
 glaner quelques idées sur la façon de gérer différents types de machines.</p>
 
 <p>Bon, puisque ce compilateur avait déjà compilé Pastel, tout ce que j'avais à
 faire était de rajouter une interface pour le C, ce que je fis, puis
 d'ajouter une sortie pour le 68000 qui devait être ma première cible. Mais
 j'allais vers un sérieux problème. Puisque le langage Pastel était conçu de
 manière à ne pas avoir besoin de déclarer quoi que ce soit avant de
 l'utiliser, la déclaration d'une variable et son usage pouvaient se faire
 dans n'importe quel ordre ; en d'autres termes, la déclaration
 <code>forward</code> du Pascal était obsolète. Pour cette raison il fallait
 lire le programme dans son intégralité, le garder en mémoire centrale
 <i>[core]</i> et le compiler d'une traite. Le résultat, c'était que le
 stockage intermédiaire utilisé par le compilateur, ou plutôt la taille de la
 mémoire requise, était proportionnel à la taille de votre fichier. Et il
 fallait aussi compter avec l'espace de pile ; vous aviez besoin d'une
 quantité gigantesque d'espace de pile. J'en ai conclu que le système 68000
 dont je disposais ne pouvait pas faire fonctionner ce compilateur. Car
 c'était une horrible version d'Unix qui vous limitait à quelque chose comme
 16 000 mots de pile, ceci en dépit de l'existence de six mégaoctets dans la
 machine. Et naturellement, pour générer la matrice des conflits afin de voir
 quelles valeurs temporaires étaient en conflit ou quel groupe de valeurs
 étaient actives en même temps, il était nécessaire d'avoir une matrice
 quadratique de bits. Et pour les grandes fonctions cela pouvait prendre des
 centaines de milliers d'octets. Ainsi je suis parvenu à déboguer la première
 des quelque dix passes du compilateur en compilation croisée sur cette
 machine et j'ai constaté alors que la seconde ne pourrait jamais
 fonctionner.</p>
 
 <p>Pendant que je réfléchissais à ces problèmes en me demandant si je devais
 essayer de les corriger ou bien écrire entièrement un nouveau compilateur,
 j'ai commencé de manière indirecte à travailler sur GNU Emacs. GNU Emacs est
 la partie principale de la distribution du système GNU. C'est un éditeur de
 texte extensible qui ressemble de près à l'Emacs original que j'ai développé
 il y a dix ans, sauf que celui-ci emploie le véritable Lisp comme langage
 d'extension. L'éditeur lui-même est implémenté en C, de même que
 l'interpréteur Lisp. Ainsi l'interpréteur Lisp est entièrement portable et
 vous n'avez pas besoin de système Lisp externe à l'éditeur. L'éditeur
 contient son propre système Lisp et toutes les commandes d'édition sont
 écrites en Lisp de manière à pouvoir vous donner des exemples sur la façon
 d'écrire vos propres commandes et des éléments à utiliser comme point de
 départ. Il vous suffit de les modifier pour obtenir les commandes que vous
 voulez.</p>
 
 <p>L'été de cette année-là, il y a environ deux ans maintenant, un ami m'a dit
 qu'en raison de son travail au tout début du développement de l'Emacs de
 Gosling, il avait la permission écrite de Gosling de distribuer sa propre
 version. Gosling, à l'origine, avait créé son Emacs. Il l'avait distribué
 librement et beaucoup de gens aidèrent à son développement, avec l'espoir
 – selon les propres mots de Gosling dans son manuel – qu'il avait suivi le
 même état d'esprit que celui que j'avais donné à l'Emacs original. Ensuite
 il a poignardé tout le monde dans le dos en prenant des copyrights dessus,
 en faisant promettre aux gens de ne pas le redistribuer puis en le vendant à
 une maison d'édition de logiciels. Les relations d'affaires que j'ai eues
 avec lui par la suite m'ont personnellement prouvé qu'il était aussi lâche
 et méprisable que vous pouvez le voir dans cette histoire.</p>
 
 <p>Mais de toute façon, mon ami m'avait donné le programme et j'avais
 l'intention de modifier les commandes d'édition du niveau supérieur pour les
 rendre compatibles avec l'Emacs original dont j'avais l'habitude. Ceci pour
 qu'elles puissent manipuler toutes les combinaisons d'arguments numériques,
 etc., tout ce que l'on pouvait s'attendre à ce qu'elles manipulent, en étant
 pourvues de toutes les fonctionnalités que je voulais. Mais peu après, j'ai
 découvert que le langage d'extension de cet éditeur, appelé Mocklisp, ne
 suffisait pas à la tâche. J'ai compris que je devais le remplacer
 immédiatement pour pouvoir réaliser mon projet. J'avais déjà pensé
 auparavant à remplacer éventuellement Mocklisp par le vrai Lisp, mais ce que
 j'ai découvert, c'est qu'il fallait le faire dès le début. Maintenant, la
 raison pour laquelle Mocklisp s'appelle <i>mock</i> (faux), c'est qu'il n'a
 aucune sorte de structure pour les types de données : il n'y a pas les
 listes Lisp ; il n'y a aucune sorte de tableau ; il n'y a pas non plus les
 symboles Lisp, qui sont des objets nommés (à chaque nom particulier
 correspond un seul objet de manière que la saisie du nom se rapporte
 toujours au même objet, sinon ça entrave considérablement l'écriture de pas
 mal de sortes de programmes en vous obligeant à passer par des manipulations
 de chaînes compliquées qui ne font pas vraiment avancer les choses).</p>
 
 <p>Alors j'ai écrit un interpréteur Lisp pour le mettre à la place de
 Mocklisp. Et ce faisant j'ai constaté que je devais réécrire un certain
 nombre de structures de données internes à l'éditeur parce que je voulais
 qu'il s'agisse d'objets Lisp. Je voulais que l'interface entre Lisp et
 l'éditeur soit propre, c'est-à-dire que des objets comme les tampons
 d'édition, les sous-processus, les fenêtres et les emplacements des tampons
 soient tous des objets Lisp, afin que les processus primaires de l'éditeur
 qui s'en servaient puissent vraiment être appelés en tant que fonctions Lisp
 avec des données Lisp. Cela voulait dire qu'il fallait recréer entièrement
 les formats de données de tous les objets et réécrire toutes les fonctions
 qui s'en servaient. Et cela a eu pour résultat, pendant environ six mois, de
 me faire réécrire à peu près tout ce qu'il y avait dans l'éditeur.</p>
 
 <p>En outre, du fait qu'il est vraiment difficile d'écrire en Mocklisp, rien
 n'était écrit proprement. Et en le réécrivant, je pouvais tirer profit de la
 puissance du vrai Lisp ; je pouvais rendre tout ça beaucoup plus puissant,
 beaucoup plus simple et rapide. C'est ce que j'ai fait. Et quand j'ai
 commencé à distribuer le programme, il ne restait qu'une petite partie de ce
 que j'avais reçu.</p>
 
 <p>À ce moment-là, la société à qui Gosling pensait avoir vendu le programme a
 contesté à mon ami le droit de le distribuer. Le message avait été
 sauvegardé sur une bande que mon ami n'arrivait plus à retrouver et Gosling
 a nié lui avoir donné cette permission. Une chose étrange s'est alors
 produite. Il était en pourparlers avec cette société qui semblait surtout
 vouloir éviter qu'il ne distribue quelque chose d'analogue à ce qu'elle-même
 distribuait. Voyez-vous, Gosling continuait à distribuer ce qu'il m'avait
 donné et la société pour laquelle il travaillait, Megatest, également ; il
 s'agissait en réalité d'une ancienne version de l'Emacs de Gosling, avec ses
 modifications. Il allait donc faire un accord avec eux dans lequel il
 cesserait de le distribuer, et passer ensuite à GNU Emacs. Ils
 reconnaîtraient alors qu'après tout Gosling avait leur permission, et donc
 théoriquement tout le monde serait content. De plus cette société m'a
 entretenu au sujet de leur désir de distribuer GNU Emacs, gratuitement bien
 sûr, mais aussi de vendre divers services d'assistance. Ils voulaient même
 m'embaucher pour aider à faire ce travail. Aussi est-il un peu étrange
 qu'ils aient soudain changé d'avis et refusé de signer cet accord, puis mis
 une annonce sur le réseau comme quoi je n'avais pas le droit de distribuer
 le programme. Ils n'ont pas vraiment dit qu'ils feraient quoi que ce
 soit. Ils ont juste dit qu'il n'était pas improbable qu'ils fassent quelque
 chose un jour. Cela faisait suffisamment peur aux gens pour que plus
 personne ne l'utilise. C'est triste.</p>
 
 <p>(Parfois je me dis que peut-être une des meilleures choses que je pourrais
 faire dans la vie serait de trouver une pile colossale de logiciels
 propriétaires couverts par le secret industriel et de commencer à en
 distribuer des copies à tous les coins de rue, ce qui les ferait sortir du
 secret. Peut-être que ce serait une manière beaucoup plus efficace de
 fournir aux gens de nouveaux logiciels libres, que de les écrire
 effectivement moi-même ; mais tout le monde serait trop lâche pour ne
 serait-ce qu'y toucher.)</p>
 
 <p>Donc ça m'a obligé à réécrire tout ce qui restait qui n'était pas de moi, ce
 que j'ai fait. Il m'a fallu environ une semaine et demie. Quelle victoire
 pour eux ! Il était certain qu'après ça ils n'obtiendraient jamais plus
 aucune collaboration de ma part.</p>
 
 <p>Une fois que GNU Emacs a été raisonnablement stable – ce qui m'a pris
 environ un an et demi tout compris – j'ai commencé à revenir sur d'autres
 parties du système. J'ai développé un programme de débogage que j'ai appelé
 GDB. C'est un débogueur symbolique pour le code C dont la distribution vient
 de commencer, réalisé en grande partie dans l'esprit de DBX, le débogueur de
 l'Unix de Berkeley. Les commandes se composent d'un mot indiquant ce que
 vous voulez faire, suivi des arguments. Dans ce programme, toutes les
 commandes peuvent être abrégées. Les commandes courantes ont des
 abréviations d'un seul caractère, mais toute abréviation d'un seul caractère
 est permise. La fonction « aide » est très fournie : vous pouvez taper
 <code>help</code> suivi de n'importe quelle commande, y compris des
 commandes secondaires, et vous obtenez une description complète de la façon
 de l'utiliser. Naturellement vous pouvez taper n'importe quelle expression
 en C et sa valeur s'affichera.</p>
 
 <p>Vous pouvez également faire des choses inhabituelles pour un débogueur C
 symbolique. Par exemple, vous pouvez vous référer à n'importe quel type de
 donnée C à n'importe quelle adresse de mémoire pour en examiner la valeur ou
 pour lui affecter une valeur. Supposons que vous vouliez stocker un nombre
 en virgule flottante dans un mot à une certaine adresse. Vous devez juste
 dire : « Donne-moi l'objet de type <i>float</i> ou <i>double</i> à cette
 adresse et ensuite affecte-lui cette valeur. » Une autre chose que vous
 pouvez faire est d'examiner toutes les valeurs qui ont été examinées
 auparavant. Chaque valeur examinée se place sur la pile de l'« historique
 des valeurs ». Vous pouvez vous référer à n'importe quel élément par sa
 position dans l'historique, ou bien vous pouvez facilement vous référer au
 dernier élément, juste avec le signe dollar. Ça facilite le suivi de la
 structure des listes. Si une structure C quelconque contient un pointeur
 vers une autre structure, vous pouvez faire quelque chose comme
 <code>print*$.next</code> qui veut dire : « Prends le champ suivant dans la
 dernière chose que tu m'as montrée, puis affiche la structure sur laquelle
 il pointe ». En répétant cette commande, on voit l'une après l'autre les
 structures sur lesquelles pointe la liste, alors qu'avec chacun des autres
 débogueurs C que j'ai vus, la seule manière de faire ça est de taper une
 commande de plus en plus longue. Et quand c'est combiné à une fonctionnalité
 qui fait qu'« Entrée » rappelle la dernière commande, ça devient très
 pratique. Vous avez juste à taper « Entrée » pour chaque élément de la liste
 que vous voulez voir.</p>
 
 <p>Vous pouvez aussi définir des variables de façon explicite dans le
 débogueur, en nombre illimité. Vous posez le signe dollar suivi d'un nom et
 c'est une variable. Vous pouvez lui affecter une valeur de n'importe quel
 type C et vous pourrez l'examiner plus tard. Parmi les choses pour
 lesquelles c'est utile, s'il y a une valeur particulière que vous voulez
 examiner, sachant que vous allez vous y référer souvent, plutôt que de vous
 souvenir de son numéro dans l'historique vous pouvez lui donner un nom. Vous
 pouvez aussi utiliser ces variables quand vous placez des paliers
 <i>[breakpoints]</i> conditionnels. Les paliers conditionnels sont une
 fonctionnalité qui existe dans beaucoup de débogueurs symboliques. Vous
 dites : « Fais une pause quand tu seras arrivé à cet endroit du programme,
 mais seulement si une certaine expression est vraie. » Les variables du
 débogueur vous permettent de comparer une variable du programme à sa
 précédente valeur sauvegardée dans la variable du débogueur. Une autre chose
 à laquelle elles peuvent servir, c'est à compter. Parce qu'après tout, les
 valeurs affectées à ces variables sont des expressions en C, donc on peut
 faire <code>$foo+=5</code> pour incrémenter la valeur <code>$foo</code>
 de 5, ou juste <code>$foo++</code>. Vous pouvez également le faire lors d'un
 palier conditionnel. Une manière économe de faire une pause dans le
 programme la dixième fois que le palier est atteint, serait de faire
 <code>$foo--==0</code>. Est-ce que tout le monde suit ? Faire décroître foo
 et une fois qu'il est à zéro, pause. Vous faites démarrer <code>$foo</code>
 au nombre de boucles que vous voulez qu'il saute et vous le lâchez. Vous
 pouvez aussi utiliser ça pour examiner les éléments d'un tableau. Supposez
 que vous ayez un tableau de pointeurs, vous pouvez faire :</p>
 
 <pre><code>PRINT X[$foo++]</code></pre>
 
 <p>Mais d'abord vous faites</p>
 
 <pre><code>SET $foo=0</code></pre>
 
 <p>OK, quand vous faites ça [il montre l'expression PRINT], vous obtenez
 l'élément zéro de X et quand vous le faites à nouveau, il atteint le premier
 élément. Supposez que ce soient des pointeurs vers des structures, alors
 vous mettez probablement un astérisque là [avant le X dans l'expression
 PRINT] et à chaque fois, il affiche la structure sur laquelle pointe
 l'élément suivant du tableau. Et bien sûr vous pouvez répéter cette commande
 en tapant « Entrée ». Si ce n'est pas suffisant de répéter une seule chose,
 vous pouvez créer une « commande utilisateur ». Vous pouvez dire
 <code>define mumble</code>, vous mettez quelques lignes de commandes puis
 <code>end</code>. Vous venez ainsi de définir une commande
 <code>mumble</code> qui exécutera ces lignes. Et il est très utile de mettre
 ces définitions dans un fichier de commandes. Vous pouvez avoir un fichier
 de commandes dans chaque répertoire qui sera chargé automatiquement en tant
 que répertoire actif lorsque vous lancerez le débogueur. Ainsi pour chaque
 programme, vous pouvez définir un ensemble de commandes utilisateur pour
 accéder efficacement aux structures. Vous pouvez même fournir de la
 documentation pour vos commandes, de façon qu'elles soient traitées par la
 fonction <code>help</code> comme des commandes intégrées.</p>
 
 <p>Une autre chose peu habituelle dans ce débogueur, c'est la capacité
 d'écarter des cadres <i>[frames]</i> de la pile ; parce que je crois que
 c'est important, non seulement pour pouvoir examiner ce qui se produit dans
 le programme que vous déboguez, mais aussi pour le modifier de toutes les
 façons possibles. De sorte qu'après avoir trouvé un problème et avoir
 compris ce qui n'allait pas, vous pouvez faire comme si le code était
 correct et trouver le prochain bogue sans avoir d'abord à recompiler le
 programme. Cela signifie non seulement pouvoir changer en souplesse les
 zones de données de votre programme, mais également changer le flux de
 contrôle. Dans ce débogueur, vous pouvez changer le flux de contrôle très
 directement en disant :</p>
 
 <pre><code>SET $PC=&lt;un certain nombre&gt;</code></pre>
 
 <p>Ainsi vous pouvez positionner le compteur ordinal <i>[program
 counter]</i>. Vous pouvez également positionner le pointeur de pile
 <i>[stack pointer]</i>, ou bien vous pouvez dire</p>
 
 <pre><code>SET $SP+=&lt;quelque_chose&gt;</code></pre>
 
 <p>si vous voulez incrémenter le pointeur de pile d'une certaine quantité. Mais
 en outre, vous pouvez également lui dire de démarrer sur une ligne
 particulière du programme ; vous pouvez placer le compteur ordinal à une
 ligne particulière du code source. Mais que se passe-t-il si vous constatez
 que vous avez appelé une fonction par erreur et que vous ne vouliez pas
 appeler cette fonction du tout ? Vous vous dites que cette fonction est trop
 merdique, que vous voulez vraiment en sortir et faire à la main ce qu'elle
 devait faire. Pour cela, vous pouvez utiliser la commande
 <code>RETURN</code>. Vous sélectionnez un cadre de la pile et vous dites
 <code>RETURN</code>. Et ça va faire que ce cadre, et tous ceux qui sont à
 l'intérieur, seront abandonnés comme si cette fonction renvoyait
 instantanément sa valeur. Vous pouvez aussi spécifier la valeur qu'elle doit
 renvoyer. Ça ne poursuit pas l'exécution ; ça fait comme si la valeur était
 renvoyée et le programme s'arrête à nouveau ; vous pouvez ainsi continuer de
 modifier autre chose.</p>
 
 <p>Et si vous combinez tout ça, vous avez pas mal de contrôle sur ce qui se
 passe dans un programme.</p>
 
 <p>Une autre chose assez amusante : C a des constantes qui sont des chaînes de
 caractères <i>[string constants]</i> ; que se passe-t-il si vous utilisez
 une constante de ce type dans une expression que vous calculez dans le
 débogueur ? Il faut qu'il crée une chaîne dans le programme que vous
 déboguez. Eh bien, c'est ce qu'il fait. Il crée un appel à
 <code>malloc</code> dans le programme débogué, laisse tourner
 <code>malloc</code>, puis reprend la main. Ainsi il trouve de façon
 transparente un endroit où placer la chaîne constante.</p>
 
 <p>Quand ce débogueur tournera enfin sur le vrai système GNU, j'ai l'intention
 d'y installer des fonctionnalités pour examiner l'ensemble des états
 internes du processus tournant en dessous de lui. Par exemple pour examiner
 l'état de la topographie mémoire, pour savoir quelles pages existent, si
 elles sont lisibles, si elles sont inscriptibles, et pour examiner l'état du
 terminal pour le programme inférieur. Il y a déjà l'ébauche d'une commande ;
 ce débogueur, à la différence des débogueurs sous Unix, garde l'état du
 terminal du débogueur et celui du programme que vous déboguez complètement
 séparés. De sorte que ça marche avec les programmes qui tournent en mode
 brut et avec ceux qui font des interruptions d'entrées dynamiques
 <i>[interrupt driven input]</i> ; et il y a également une commande qui vous
 permet d'apprendre quelque chose sur les réglages des terminaux que le
 programme que vous déboguez utilise réellement. Je crois qu'en général un
 débogueur doit vous permettre de découvrir tout qui se passe dans le
 processus inférieur.</p>
 
 <p>Deux autres parties centrales du système GNU existent déjà. L'un est le
 nouveau compilateur C et l'autre le noyau Trix.</p>
 
 <p>J'ai commencé à écrire le nouveau compilateur C cette année, au printemps
 dernier. J'ai finalement décidé que je devais me passer de Pastel. Ce
 compilateur utilise quelques idées de Pastel et quelques idées de
 « l'optimiseur portable de l'université d'Arizona » <i>[University of
 Arizona Portable Optimizer]</i>. Ce que ce dernier a d'intéressant, c'est de
 gérer plusieurs types différents de machines par des instructions simples et
 d'ensuite combiner plusieurs instructions simples dans une seule instruction
 compliquée quand la machine cible le permet. Pour que cela reste uniforme,
 ils représentent les instructions en notation algébrique. Par exemple,
 l'instruction <code>add</code> peut être représentée comme ceci :</p>
 
 <pre>
   <code>r[3]=r[2]+4</code>
 </pre>
 
 <p>C'est une représentation interne au compilateur de l'instruction « prendre
 le contenu du registre n&deg;2, y ajouter 4 et le stocker dans le registre
 n&deg;3 ». De cette façon vous pouvez représenter n'importe quelle
 instruction pour n'importe quelle machine. C'est donc comme ça qu'ils
 représentent toutes les instructions. Quand vient le moment d'essayer de les
 combiner, ils le font en substituant une expression dans une autre, ce qui
 donne pour l'instruction combinée une expression algébrique plus compliquée.</p>
 
 <p>Quelquefois, suivant que le résultat de la première instruction est utile
 par la suite, ou pas, il peut être nécessaire de faire une instruction
 combinée avec deux opérateurs d'affectation <i>[assignment]</i> : un pour
 cette valeur [il montre ???] et un autre pour cette valeur [il montre ???] à
 l'intérieur de laquelle est substitué ce qui provient de la deuxième
 instruction. Si cette valeur n'est utilisée qu'une fois, vous pouvez
 l'éliminer après l'avoir substituée ; elle n'a pas à entrer dans d'autres
 calculs. Donc c'est vraiment assez compliqué de faire ces substitutions
 correctement, en vérifiant bien que les instructions intermédiaires ne vont
 changer aucune de ces valeurs, ni rien d'autre du même genre. Quand vous
 gérez des choses comme l'adressage auto-incrémenté et auto-décrémenté, ce
 que je fais maintenant, vous avez aussi diverses vérifications à faire pour
 détecter les situations où l'objectif n'est pas de conserver la valeur de la
 variable.</p>
 
 <p>Mais après avoir vérifié tout ça, vous prenez l'expression combinée
 substituée et vous la passez à travers un filtre de motif <i>[pattern
 matcher]</i>, qui reconnaît toutes les instructions valides de la machine
 cible que vous avez choisie. Si le motif est reconnu, vous remplacez les
 deux instructions par leur instruction combinée, sinon vous les laissez
 tranquilles. Leur technique est de combiner de cette manière deux ou trois
 instructions reliées par le flux de données.</p>
 
 <p>Dans le compilateur d'Arizona, les choses sont en fait représentées par des
 chaînes de caractères comme ceci, et le compilateur est terriblement
 lent. Au début j'avais l'idée de l'utiliser et d'y apporter des
 modifications, mais j'ai compris que je devais le réécrire entièrement pour
 obtenir la rapidité que je voulais. En le réécrivant, j'ai fait en sorte de
 pouvoir utiliser des représentations de structure de liste pour toutes ces
 expressions ; des choses comme ceci :</p>
 
 <pre>
      <code>(set (reg 2)</code>
           <code>(+ (reg 2)</code>
              <code>(int 4)))</code>
 </pre>
 
 <p>Ça ressemble un peu à du Lisp mais la sémantique n'est pas tout à fait la
 même, parce que chaque symbole est ici identifié individuellement. Un
 ensemble fixe, particulier de ces symboles est défini, tous ceux dont vous
 avez besoin, chacun ayant une combinaison particulière de types
 d'arguments. Pour <code>reg</code> par exemple, c'est toujours un nombre
 entier, parce que les registres sont numérotés, mais <code>+</code> prend
 deux sous-expressions, et ainsi de suite. Et chacune de ces expressions a
 aussi un type de données qui, en gros, indique s'il est fixe ou flottant et
 combien d'octets il occupe. Ça peut être étendu pour manipuler d'autres
 choses si vous en avez besoin.</p>
 
 <p>Voilà comment je fais l'allocation automatique de registre : au moment où je
 génère initialement le code, et quand je fais la combinaison et le reste,
 pour toute variable qui entre théoriquement dans un registre j'alloue ce que
 j'appelle un pseudo-numéro de registre. C'est un nombre qui commence à
 seize, ou autre nombre trop élevé pour désigner un vrai registre de la
 machine cible. Les vrais registres sont numérotés de zéro à quinze (ou
 autre), et après viennent les pseudo-registres. Et là, une des dernières
 opérations consiste à examiner tous les pseudo-registres et à les changer en
 vrais registres. À nouveau, le compilateur fait un schéma des conflits, il
 voit quels pseudo-registres sont actifs en même temps – ils ne peuvent
 naturellement pas entrer dans le même vrai registre – et essaie de regrouper
 les pseudo-registres dans de vrais registres autant que possible, en les
 rangeant par ordre d'importance.</p>
 
 <p>Et à la fin, il doit corriger le code pour différents problèmes, tels qu'il
 peut s'en produire si des pseudo-registres ne trouvent pas place dans les
 vrais registres et doivent être mis à la place dans des <i>slots</i> de la
 pile. Sur certaines machines, des instructions peuvent devenir invalides
 quand ça arrive. Par exemple sur le 68000, on peut ajouter depuis un
 registre dans la mémoire et ajouter depuis la mémoire dans un registre mais
 pas ajouter depuis une adresse mémoire vers une autre. Par exemple, si lors
 d'une instruction ADD vous sortez vers un 68000 et que les deux éléments se
 retrouvent dans la mémoire, ce n'est pas valide. Donc ce dernier passage
 examine le tout et copie au besoin des éléments dans les registres ou en
 dehors des registres, pour corriger ce genre de problème.</p>
 
 <p>Des problèmes peuvent également survenir avec les registres d'index. Si vous
 essayez d'indexer par quelque chose, la plupart du temps le code deviendra
 invalide si cette quantité est en mémoire, sauf dans quelques cas, sur
 certaines machines où vous pouvez le faire avec un adressage
 indirect. Lorsque vous procédez à une autoincrémentation sur un registre
 d'index, vous pouvez avoir à copier la valeur dans un registre, effectuer
 l'instruction et ensuite recopier la valeur incrémentée dans le <i>slot</i>
 de mémoire où elle vit vraiment.</p>
 
 <p>Il y a encore de la marge pour pas mal de prises de tête, et je n'ai pas
 fini d'implémenter tout ce qui est nécessaire pour le rendre vraiment
 pleinement efficace.</p>
 
 <p>Ce compilateur fonctionne actuellement avec un analyseur syntaxique qui
 transforme efficacement le code C en arbre syntaxique, annoté d'informations
 sur le type de données C. Après ça, un autre passage examine cet arbre et
 produit du code comme celui-là [comme du Lisp]. Ensuite viennent plusieurs
 passages d'optimisation : un pour traiter par exemple les sauts à travers
 des sauts, les sauts aboutissant à des sauts, les sauts à <code>.+1</code>
 et tout ce qui peut être immédiatement simplifié ; puis la reconnaissance
 des sous-expressions communes ; puis la recherche des blocs de base et
 l'analyse du flux de données, afin de pouvoir indiquer pour chaque
 instruction quelles valeurs sont utilisées dans l'instruction et nulle part
 ailleurs ; et aussi la liaison entre chaque instruction et les endroits où
 les valeurs utilisées ont été créées. Ainsi, quand j'ai une instruction qui
 crée un pseudo-registre R[28] et une autre instruction plus tard qui utilise
 R[28], sachant que c'est le premier endroit qui utilise R[28], je fais
 pointer la seconde en arrière sur la première et ce pointeur est celui qui
 servira pour contrôler les essais de combinaison des instructions. Vous ne
 combinez pas des instructions adjacentes, vous combinez une instruction qui
 utilise une valeur avec l'instruction qui a produit cette valeur. Même s'il
 y a d'autres instructions au milieu, elles ne sont pas concernées ; vous
 avez juste à vous assurer qu'elles n'interviennent pas. Et après le
 combinateur vient l'allocateur dynamique de registres, et enfin quelque
 chose pour faire la conversion en code assembleur.</p>
 
 <p>Dans le compilateur d'Arizona, le système de reconnaissance d'instructions a
 été créé avec Lex. La description de votre machine est simplement un
 programme Lex, que Lex transforme en une fonction C pour identifier les
 instructions valides sous forme de chaînes. À la place, j'ai un arbre de
 décision particulier, créé à partir d'une description de la machine écrite
 dans cette syntaxe qui ressemble au Lisp. Et ce système de reconnaissance
 est utilisé comme sous-programme dans plusieurs parties différentes du
 compilateur.</p>
 
 <p>Actuellement ce compilateur fonctionne à peu près aussi rapidement que le
 <abbr title="Portable C Compiler">PCC</abbr>. Il fonctionne sensiblement
 plus rapidement si vous lui dites de ne pas faire d'allocation de registre
 limite. Dans ce cas il alloue les registres de la même manière que le
 PCC. Dans son mode super-limite, il fait un travail d'allocation de
 registres bien meilleur que le PCC et je constate que pour le VAX, il
 produit le meilleur code que j'aie vu de tous les compilateurs C sur VAX.</p>
 
 <p>Pour le 68000, le code n'est pas encore idéal. Je peux voir par endroits,
 aux étapes précoces, se passer des choses qui ne sont pas forcément
 optimales parce qu'il ne peut pas vraiment anticiper. Il a un choix à faire
 à une étape précoce et il fait ce qu'il pense être le mieux. Or s'il avait
 fait un autre choix, une étape ultérieure aurait été assez intelligente pour
 faire encore mieux. Mais l'étape précoce ne sait pas ce que l'étape
 ultérieure va faire, donc je dois retravailler certaines choses.</p>
 
 <p>Parfois ça lui fait libérer des registres inutilement : quand des choses
 atterrissent dans la mémoire et qu'il a besoin de les copier dans des
 registres, il faut qu'il trouve des registres. Cela veut dire prendre des
 registres déjà alloués et virer les données temporaires des <i>slots</i> de
 la pile. Évidemment, maintenant que ces choses sont dans la mémoire plutôt
 que dans les registres, ça peut invalider certaines instructions, donc il
 lui faut tout le temps vérifier. Parfois il pense à tort qu'il devrait
 copier des choses dans les registres, alors il arrive qu'il en libère trop
 et n'utilise pas tous les registres qu'il pourrait.</p>
 
 <p><span>[Question : Avez-vous un générateur de code pour le 32000 ?]</span>Pas
 encore, mais je le répète, ce n'est pas un générateur de code dont vous avez
 besoin, juste une description de machine, une liste de toutes les
 instructions de la machine décrites sous cette forme [comme du Lisp]. En
 fait, hormis le travail d'implémenter l'idée des contraintes qui déterminent
 quels arguments peuvent aller dans les registres et dans quelles sortes de
 registres ils iront – travail nécessaire pour le 68000, mais pas pour le
 VAX – le portage de ce compilateur du VAX au 68000 a juste pris quelques
 jours. Donc il est très facile à porter.</p>
 
 <p>Le compilateur produit actuellement du code assembleur et il peut produire
 de l'information de débogage, soit dans le format voulu par DBX, soit dans
 le format interne spécial à GDB. Je dirais que le seul travail qui reste à
 faire sur ce compilateur se situe à trois niveaux. Un : Je dois ajouter un
 dispositif de « profilage » comme celui des compilateurs d'Unix. Deux : Je
 dois rendre les allocations de registre plus intelligentes pour ne plus voir
 de choses stupides apparaître en sortie. Trois : Il y a divers bogues, des
 choses qu'il ne traite pas encore correctement bien qu'il se soit compilé
 correctement. Je pense que ça ne prendra que quelques mois, ensuite je le
 publierai.</p>
 
 <p>L'autre partie importante du système existant, c'est le
 noyau. <span>[Question : Une pause ?]</span> Ah, ouais, je suppose que nous
 avons oublié les coupures. Pourquoi est-ce que je ne finirais pas de parler
 du noyau, ce qui ne devrait pas prendre plus de cinq minutes ? Ensuite nous
 pourrons faire une coupure.</p>
 
 <p>Donc, pour le noyau je projette d'utiliser un système appelé TRIX (cela ne
 signifie rien de spécial, que je sache) qui a été développé comme projet de
 recherche au MIT. Ce système est basé sur l'appel de procédure à distance
 <i>[Remote Procedure Call]</i>. Les programmes sont appelés domaines. Chaque
 domaine est un espace d'adressage et a diverses capacités, une capacité
 n'étant rien d'autre que l'aptitude à appeler un domaine. Tout domaine peut
 créer des « ports de capacité » <i>[capability ports]</i> pour l'appeler et
 peut passer ces ports aux autres domaines. Et il n'y a aucune différence
 entre appeler le système et appeler un autre domaine utilisateur. En fait
 vous ne pouvez pas dire lequel vous avez. Ainsi il est très facile de faire
 implémenter des dispositifs par d'autres programmes utilisateur. Un système
 de fichiers pourrait être implémenté de façon transparente par ce moyen. Il
 est également transparent de communiquer à travers des réseaux. Vous pensez
 que vous appelez directement un autre domaine, mais en réalité vous appelez
 le domaine du serveur réseau. Il prend l'information que vous avez donnée
 dans l'appel et la passe par le réseau à un autre programme serveur qui
 appelle alors le domaine auquel vous essayez de parler. Mais pour vous et
 cet autre domaine, cela se passe de manière transparente.</p>
 
 <p>Le noyau TRIX fonctionne et il a une compatibilité limitée avec Unix, mais
 il lui en faut beaucoup plus. Actuellement son système de fichiers utilise
 la même structure sur disque que l'ancien système de fichiers d'Unix. Ça
 rendait plus facile le débogage parce qu'ils pouvaient installer les
 fichiers avec Unix et donc faire fonctionner TRIX, mais ce système de
 fichiers n'a aucune des fonctionnalités que je trouve nécessaires.</p>
 
 <p>Voilà les fonctionnalités qui, je pense, devraient être rajoutées : des
 numéros de version, la restauration des fichiers effacés, les informations
 sur quand, comment et où le dossier a été sauvegardé sur bande, le
 remplacement nucléaire des fichiers. Ce qui est bien dans Unix, d'après moi,
 c'est que lorsqu'un fichier est en cours d'écriture, on peut déjà regarder
 ce qui se passe. Ainsi par exemple, vous pouvez utiliser <code>tail</code>
 pour voir où ça en est ; c'est vraiment sympa. Et si le programme se plante
 après avoir écrit le fichier partiellement, vous pouvez voir ce qu'il a
 fait. Tout ça c'est très bien, mais le résultat partiellement écrit ne doit
 jamais être considéré comme le résultat final escompté. La version
 précédente doit continuer d'être visible et utilisée par tous ceux qui
 tentent de l'utiliser jusqu'à ce qu'une nouvelle version soit entièrement et
 correctement réalisée. Cela signifie que la nouvelle version devra être
 visible dans le système de fichiers, mais pas sous le nom qu'elle est censée
 avoir. Elle devra être renommée quand c'est fini. C'est d'ailleurs ce qui se
 passe avec ITS, bien que chaque programme utilisateur doive le faire de
 façon explicite. Pour la compatibilité d'Unix avec les programmes
 utilisateur, ça doit se passer de façon transparente.</p>
 
 <p>J'ai un plan bizarre et plutôt coton pour essayer de faire coller les
 numéros de version avec les programmes utilisateur existant sous Unix. Il
 s'agit de spécifier le nom de fichier, en laissant implicite le numéro de
 version si vous le spécifiez normalement. Et si vous souhaitez le faire de
 façon explicite – soit parce que vous voulez déclarer explicitement quelle
 version utiliser, soit parce que vous ne voulez pas de version du tout –
 vous mettez un point à son extrémité. Ainsi, si vous donnez le nom de
 fichier <code>FOO</code> cela signifie « cherche les versions qui existent
 pour FOO et prends la dernière ». Mais si vous dites <code>FOO.</code> cela
 signifie « utilise exactement le nom FOO et aucun autre ». Si vous dites
 <code>FOO.3. » cela veut dire « utilise exactement le nom FOO.3</code>, qui
 naturellement est la version trois de FOO et aucune autre. En sortie, si
 vous dites juste <code>FOO</code>, ça va créer une nouvelle version de FOO,
 mais si vous dites <code>FOO.</code>, ça va écrire un fichier nommé
 exactement « FOO ».</p>
 
 <p>Maintenant c'est un défi de mettre au point tous ces détails et de voir s'il
 persiste des problèmes, si vraiment certains logiciels Unix se plantent bien
 qu'on leur ait fourni des noms avec des points et ainsi de suite, pour
 tenter de leur faire garder le même comportement.</p>
 
 <p>Je m'attends à ce que, si on ouvre un fichier dont le nom finit par un
 point, on ouvre en fait immédiatement un fichier avec ce nom-là ; on obtient
 ainsi le même comportement qu'Unix : le résultat partiellement écrit est
 immédiatement visible. Tandis que, si on l'ouvre avec un nom qui ne finit
 pas par un point, la nouvelle version ne doit apparaître qu'à la fermeture
 du fichier, et seulement si on le ferme explicitement. S'il a été fermé
 parce que la tâche a échoué ou à cause du plantage du système ou de
 n'importe quoi du genre, il doit être sous un nom différent.</p>
 
 <p>Et cette idée peut être rapprochée de l'utilisation de l'astérisque comme
 joker <i>[star matching]</i> : un nom qui ne finit pas par un point équivaut
 à tous les noms sans leur numéro de version. Supposons qu'un certain
 répertoire ait des fichiers comme ceci :</p>
 
 <pre>
   <code>foo.1 foo.2 bar.8</code>
 </pre>
 
 <p>Si je dis <code>*</code>, ça équivaut à</p>
 <pre>
   <code>foo bar</code>
 </pre>
 
 <p>parce que ça prend tous les noms, les débarrasse de leurs versions et
 conserve tous ceux qui sont distincts. Mais si je dis <code>*.</code>, alors
 ça prend tous les noms exacts, met un point après chaque nom et cherche les
 équivalences. Ça me donne tous les noms avec toutes les différentes versions
 qui existent. Et de la même façon, vous pouvez voir la différence entre
 <code>*.c</code> et <code>*.c.</code>. Ceci [le premier] vous donnera
 essentiellement les références sans version de tous les fichiers
 <code>.c</code>, tandis que cela [le second] vous donnera toutes les
 versions&hellip; Bon, pas vraiment, vous devriez dire <code>*.c.*.</code>,
 mais ici je ne tiens pas compte des détails.</p>
 
 <p>Une autre chose qu'on pourrait ajouter, qui est transparente pour
 l'utilisateur et est certainement compatible, c'est la tolérance du système
 de fichiers aux défaillances de la machine. À savoir, écrire toutes les
 informations sur le disque dans l'ordre approprié, en s'arrangeant pour
 qu'on puisse presser le bouton <kbd>Arrêt</kbd> à tout moment sans
 endommager le système de fichiers du disque. C'est tellement connu que je ne
 peux pas imaginer qu'on puisse le négliger. Une autre idée, c'est
 d'augmenter la redondance de l'information. Je ne sais pas si je le ferai,
 mais j'ai des idées sur la façon de stocker dans chaque fichier tous ses
 noms, ce qui permettrait, si l'un des répertoires du disque est perdu, de le
 reconstruire à partir du reste du contenu du disque.</p>
 
 <p>En outre, je pense savoir comment rendre possible la mise à jour nucléaire
 de n'importe quelle partie d'un fichier – c'est-à-dire pouvoir remplacer un
 sous-bloc particulier d'un fichier par de nouvelles données de manière que
 si on essaie de le lire, on voie, ou bien les nouvelles données, ou bien les
 anciennes. Je crois que je peux faire ça, sans même de verrouillage.</p>
 
 <p>Pour la gestion du réseau, j'ai l'intention par la suite d'implémenter
 TCP/IP pour ce système. Je pense également qu'il est possible d'utiliser
 KERMIT pour obtenir quelque chose de pratiquement équivalent à UUCP.</p>
 
 <p>Un <i>shell</i> a déjà été écrit, je crois. Il a deux modes, l'un imitant le
 <i>Bourne shell</i> et l'autre imitant le <i>C-shell</i>,<a
 id="TransNote6-rev" href="#TransNote6"><sup>6</sup></a> dans le même
 programme. Je n'en ai pas reçu de copie et je ne sais pas combien de travail
 j'aurai à faire dessus. Il y a encore beaucoup d'autres utilitaires. Un MAKE
 existe, LS également ; il y a BISON qui remplace YACC et qui est déjà
 distribué. Il existe quelque chose d'assez proche de LEX, mais qui n'est pas
 totalement compatible et a besoin d'être retravaillé. Et en général, ce qui
 reste à faire est beaucoup moins important que ce qui a été fait mais on a
 toujours besoin de beaucoup de gens pour aider.</p>
 
 <p>Les gens me demandent toujours « Quand est-ce que ça sera fini ? »
 Naturellement je ne peux pas le savoir, mais c'est une mauvaise question. Si
 vous comptiez payer pour ça, je comprendrais que vous vouliez savoir
 exactement ce que vous allez obtenir, et quand. Mais puisque vous n'allez
 pas payer, la bonne question à vous poser est : « Comment peut-on aider pour
 que ça soit fini plus tôt ? » J'ai une liste de projets dans un dossier au
 MIT. Les gens qui souhaitent apporter leur aide peuvent m'envoyer un
 courrier à cette adresse internet et je leur enverrai en retour une liste de
 projets (je me demande si ça va marcher [en regardant la craie]). Est-ce que
 c'est lisible ? C'est « RMS@GNU.ORG » (suivez juste la balle magique<a
 id="TransNote7-rev" href="#TransNote7"><sup>7</sup></a>). Et maintenant
 faisons une pause, et après la pause, je vais dire des choses vraiment
 controversées, alors ne partez pas maintenant. Si vous partez maintenant,
 vous allez rater le clou de la conférence.</p>
 
 <p><strong>[Ici, nous avons eu 15 minutes de pause]</strong></p>
 
 <p>On m'a demandé de faire connaître le moyen d'obtenir des copies des
 logiciels GNU. Eh bien, un des moyens est évidemment de connaître un ami qui
 en a un exemplaire. Mais si ce n'est pas le cas et que vous n'êtes pas sur
 Internet pour le télécharger, alors vous pouvez toujours commander une
 distribution sur bande et envoyer une certaine somme à la <i>Free Software
 Foundation</i> (Fondation pour le logiciel libre). Naturellement les
 programmes libres <i>[free programs]</i>, ce n'est pas la même chose que la
 distribution gratuite <i>[free distribution]</i>. Je l'expliquerai en détail
 plus tard.</p>
 
 <p>J'ai ici un manuel d'Emacs, du genre bien imprimé. Il a été phototypé puis
 imprimé en offset. Bien que vous puissiez également l'imprimer vous-même à
 partir des sources de la distribution d'Emacs, vous pouvez en obtenir des
 copies de la <i>Free Software Foundation</i>. Vous pouvez venir après pour
 le regarder. Il contient également un bulletin de commande dont vous pouvez
 copier les renseignements, de même que ce dessin [de la page de garde] qui a
 quelquefois du succès : [montrant du doigt un personnage chassé par RMS à
 cheval sur un gnou] c'est un accapareur de logiciel effrayé, je parlerai de
 lui dans un moment.</p>
 
 <p>Le logiciel est un phénomène relativement nouveau. Les gens ont commencé à
 distribuer du logiciel il y a peut-être trente ans. Il y a seulement vingt
 ans à peu près que quelqu'un a eu l'idée de faire du commerce avec
 ça. C'était un secteur sans a-priori sur la façon de faire ou sur les droits
 que l'on pouvait avoir, mais on avait quelques idées sur les autres domaines
 de la vie auxquels on pouvait emprunter leurs traditions, par analogie.</p>
 
 <p>Une analogie appréciée par un bon nombre de professeurs en Europe est celle
 des mathématiques. Un programme est une sorte de grande formule. Par
 tradition, personne ne peut posséder une formule mathématique. N'importe qui
 peut la copier et s'en servir.</p>
 
 <p>L'analogie qui a le plus de sens pour les gens ordinaires, c'est celle des
 recettes. Si vous y réfléchissez, ce qui ressemble le plus à un programme
 dans la vie ordinaire, c'est une recette – des instructions pour faire
 quelque chose. La différence, c'est qu'une recette est suivie par une
 personne, pas par une machine de façon automatisée. Il est vrai que pour la
 recette il n'y a pas de différence entre le code source et le code objet,
 mais cela reste ce qu'il y a de plus proche. Et personne n'est autorisé à
 posséder une recette.</p>
 
 <p>Mais l'analogie qui a été choisie fut celle des livres, sur lesquels
 s'applique le copyright. Pourquoi ce choix a-t-il été fait ? Parce que les
 gens qui avaient le plus à gagner à faire ce choix particulier ont été
 autorisés à prendre la décision. Les gens qui écrivaient les programmes ont
 eu le droit de décider, pas ceux qui les utilisaient. Cela a été fait d'une
 façon totalement égoïste, en transformant le domaine de la programmation en
 quelque chose de sinistre.</p>
 
 <p>Quand je suis entré dans ce secteur d'activité, quand j'ai commencé à
 travailler au MIT en 1971, l'idée que les programmes que nous développions
 pourraient ne pas être partagés n'était même pas discutée. Même chose à
 Stanford et à <abbr title="Carnegie Mellon University">CMU</abbr>, et
 partout ailleurs y compris chez Digital. À cette époque-là, le système
 d'exploitation de Digital était libre. J'en ai de temps en temps récupéré
 des morceaux, comme un assembleur multi-compatible pour PDP-11 que j'ai
 porté sur ITS et auquel j'ai ajouté de nombreuses fonctionnalités. Il n'y
 avait aucun copyright sur ce programme.</p>
 
 <p>C'est seulement vers la fin des années 70 que ça a commencé à
 changer. J'étais extrêmement marqué par l'esprit de partage que nous avions
 jusque-là. Nous espérions faire quelque chose d'utile et nous étions heureux
 si les gens pouvaient s'en servir. Ainsi, quand j'ai développé le premier
 Emacs et que les gens ont commencé à vouloir l'utiliser en dehors du MIT,
 j'ai dit qu'il appartenait à la « communauté » Emacs. Pour utiliser Emacs
 vous deviez être membre de la communauté et ça voulait dire que vous deviez
 lui apporter en contribution toutes les améliorations que vous aviez
 faites. Toutes les améliorations de l'Emacs original devaient m'être
 renvoyées pour que je puisse les incorporer à de nouvelles versions d'Emacs,
 de manière que chacun dans la communauté puisse en bénéficier.</p>
 
 <p>Mais ça a commencé à se dégrader quand Scribe a été développé à CMU, puis
 vendu à une entreprise. Cela a dérouté beaucoup d'entre nous, dans de
 nombreuses universités, parce que nous avons vu quelle tentation c'était
 pour chacun et à quel point il était profitable d'être peu coopératif. Et
 ceux d'entre nous qui y croyaient toujours n'avaient aucune arme pour tenter
 de convaincre les autres de coopérer avec nous. Sans aucun doute, les uns
 après les autres, ils allaient déserter et cesser de coopérer avec le reste
 de la société, jusqu'à ce qu'il ne reste plus que ceux d'entre nous qui
 avaient des consciences très fortes. Et c'est ce qui s'est passé.</p>
 
 <p>La programmation est maintenant devenue un domaine sinistre, où chacun pense
 de façon cynique à combien il va gagner à ne pas être sympa avec les autres
 programmeurs, ni avec les utilisateurs.</p>
 
 <p>Je veux montrer que la pratique de posséder le logiciel est à la fois
 matériellement inutile, moralement nuisible à la société, et malfaisante,
 ces trois choses étant interdépendantes. C'est moralement nocif parce que ça
 engage chaque membre de la société qui entre en contact avec l'informatique
 dans une pratique qui est manifestement du gaspillage pour les autres. Et
 chaque fois que vous faites pour votre bien personnel une chose dont savez
 qu'elle fait plus de mal aux autres qu'elle ne vous aide, vous êtes obligé
 de devenir cynique pour pouvoir en supporter la pensée. Et c'est malfaisant
 parce que ça gaspille délibérément le travail effectué sur la société, en
 affaiblissant le lien social.</p>
 
 <p>D'abord je veux expliquer les différentes nuisances causées par les
 tentatives de posséder le logiciel ou, plus généralement, toute autre
 information utile, puis je m'appliquerai à réfuter les arguments des
 défenseurs de cette pratique, ensuite je voudrais parler de la façon de
 combattre ce phénomène et dire comment je m'y prends moi-même.</p>
 
 <p>L'idée de posséder l'information est nocive à trois niveaux
 différents. Matériellement nocive à trois niveaux différents. Et à chaque
 type de nocivité matérielle correspond une nocivité morale.</p>
 
 <p>Au premier niveau, c'est juste que ça décourage l'utilisation du
 programme. Il y a moins de gens qui utilisent le programme, mais ça ne
 demande pas moins de travail pour l'élaborer. Quand on met un prix sur
 l'utilisation d'un programme en tant qu'« incitation », c'est le mot que ces
 accapareurs de logiciel aiment à employer, c'est une incitation pour les
 gens à ne pas l'utiliser et c'est du gâchis. Si par exemple il y a deux fois
 moins de gens qui utilisent le programme à cause de son prix, le programme a
 été à moitié gaspillé. La même quantité de travail a produit moitié moins de
 richesse.</p>
 
 <p>En fait, vous n'avez rien de spécial à faire pour qu'un programme soit
 diffusé vers tous ceux qui veulent l'utiliser, parce qu'ils peuvent
 parfaitement le copier eux-mêmes et qu'il finit par atteindre tout le
 monde. Tout ce que vous avez à faire, après avoir écrit le programme, c'est
 de vous asseoir tranquillement et de laisser les gens faire ce qu'ils
 veulent. Mais ce n'est pas ce qu'il se passe. Au lieu de ça, quelqu'un
 essaye délibérément d'entraver le partage du programme. Mais il ne tente pas
 simplement de l'entraver, il essaie de pousser les autres à l'aider. Toutes
 les fois qu'un utilisateur signe un accord de confidentialité, c'est comme
 s'il trahissait ses camarades utilisateurs. Au lieu de suivre la règle d'or
 et de dire « J'apprécie ce programme, mon voisin le voudrait aussi, je veux
 que nous l'ayons tous les deux », il dit « Ouais, donnez-le-moi. Au diable
 mon voisin ! Je vous aiderai à le maintenir hors de sa portée. Ne le donnez
 qu'à moi ! » C'est cet état d'esprit qui est source de nuisance morale,
 cette attitude qui consiste à dire : « Au diable mes voisins, donnez-m'en, à
 MOI, une copie. »</p>
 
 <p>Après être tombé sur des gens qui disaient qu'ils ne me laisseraient pas
 avoir de copies parce qu'ils avaient signé un accord de confidentialité,
 quand quelqu'un me demandait de signer un truc comme ça je savais que
 c'était mal. Je ne pouvais pas faire à quelqu'un d'autre ce qui m'avait tant
 exaspéré quand on me l'avait fait à moi.</p>
 
 <p>Mais ce n'est que le premier niveau de nocivité. Le deuxième niveau se
 manifeste quand les gens veulent modifier le programme, parce qu'un
 programme ne satisfait jamais vraiment tous ceux qui voudraient
 l'utiliser. Tout comme ils aiment varier les recettes, disons, en mettant
 moins de sel – ou peut-être aiment-ils rajouter des poivrons verts – les
 gens doivent également pouvoir modifier les programmes pour obtenir les
 résultats dont ils ont besoin.</p>
 
 <p>Les propriétaires de logiciel ne s'inquiètent pas vraiment de savoir si les
 gens peuvent modifier le programme ou non, mais les en empêcher leur est
 utile pour parvenir à leurs fins. Généralement, quand un logiciel est
 propriétaire, vous ne pouvez pas obtenir les sources ; vous ne pouvez pas le
 modifier et c'est un grand gaspillage de travail pour les programmeurs,
 aussi bien qu'une grande frustration pour les utilisateurs. Par exemple, une
 amie m'a dit qu'elle avait travaillé pendant de nombreux mois dans une
 banque où elle était programmeuse pour écrire un nouveau programme. Or il y
 avait un programme disponible dans le commerce qui était presque bon, mais
 qui n'était pas tout à fait ce dont ils avaient besoin. Et tel quel, il leur
 était inutile. Cela ne demandait probablement qu'un changement minime, mais
 comme les sources de ce programme n'étaient pas disponibles c'était
 impossible. Elle a dû repartir de zéro et perdre beaucoup de temps. Et nous
 ne pouvons que spéculer sur la fraction de l'ensemble des programmeurs,
 partout dans le monde, qui perdent leur temps de cette façon.</p>
 
 <p>Il y a aussi le cas où un programme est adéquat, mais peu pratique. Par
 exemple, la première fois que nous avons eu une imprimante graphique au MIT,
 nous avons écrit le logiciel nous-mêmes et nous avons installé un bon nombre
 d'utilitaires sympathiques. Par exemple, il vous envoyait un message quand
 votre tâche d'impression était finie, ou quand l'imprimante manquait de
 papier et que vous aviez une tâche en file d'attente, et pas mal d'autres
 choses qui correspondaient à ce que nous voulions. Puis on nous a donné une
 imprimante graphique beaucoup plus intéressante, une des premières
 imprimantes laser, mais le logiciel était fourni par Xerox et nous ne
 pouvions pas le modifier. Ils n'acceptaient pas d'intégrer ces
 fonctionnalités et nous ne pouvions pas le faire nous-même. Aussi avons-nous
 dû nous contenter de choses qui ne « fonctionnaient qu'à moitié ». Et
 c'était très frustrant de savoir que nous étions prêts à arranger ça,
 désireux et capables de le faire, mais que nous n'en avions pas le droit. On
 sabotait notre travail.</p>
 
 <p>Et il y a tous les gens qui utilisent des ordinateurs et qui disent que les
 ordinateurs sont un mystère pour eux. Ils ne savent pas comment ça
 fonctionne. Mais comment pourraient-ils le savoir ? Ils ne peuvent pas lire
 les programmes qu'ils utilisent. La seule manière pour les gens d'apprendre
 comment les programmes doivent être écrits ou comment ils font ce qu'ils
 font, c'est de lire le code source.</p>
 
 <p>Aussi peut-on se demander si l'idée que l'utilisateur voit l'ordinateur
 comme un simple outil ne serait pas une prophétie autoréalisatrice, une
 conséquence de la pratique de garder secret le code source.</p>
 
 <p>La nocivité morale qui correspond à ce type de nocivité matérielle affecte
 le sentiment d'autosuffisance. Quand une personne passe une bonne partie de
 son temps à utiliser un système informatique, la configuration de ce système
 devient la cité dans laquelle elle vit. L'aménagement de nos maisons et la
 disposition des meubles déterminent comment nous y vivons, il en est de même
 pour le système informatique que nous utilisons. Si nous ne pouvons pas le
 modifier pour qu'il nous convienne, nos vies sont alors vraiment sous le
 contrôle des autres, et d'une certaine manière la personne qui le constate
 en est démoralisée : « Ça ne sert à rien d'essayer de changer ça, ce ne sera
 jamais bien. Ce n'est pas la peine de s'embêter. Je vais juste faire mes
 heures et&hellip; quand j'aurai fini, je m'en irai en tâchant de ne plus y
 penser. » Ce genre d'état d'esprit, ce manque d'enthousiasme, est le
 résultat obtenu quand on n'est pas autorisé à améliorer les choses alors
 qu'on serait prêt à montrer de l'esprit civique.</p>
 
 <p>Le troisième niveau de nocivité se situe dans l'interaction entre les
 développeurs de logiciel eux-mêmes, car tout domaine de connaissance avance
 davantage quand les gens peuvent construire à partir du travail des
 autres. Mais l'appropriation de l'information par une personne est
 explicitement conçue pour empêcher toutes les autres de faire cela. Si les
 gens pouvaient construire à partir du travail des autres, alors la propriété
 deviendrait difficile à cerner, c'est pourquoi ils s'assurent que chaque
 nouveau venu dans le domaine commence au début, ce qui ralentit
 considérablement le progrès.</p>
 
 <p>C'est ce que nous pouvons constater : combien y a-t-il de tableurs créés par
 des entreprises différentes sans qu'aucune ait profité de ce qui avait été
 fait auparavant ? Oui, c'est vrai, le premier tableur qui a été écrit
 n'était pas parfait. Il ne fonctionnait probablement que sur certains types
 d'ordinateurs et il ne faisait pas les choses de la meilleure manière
 possible. Donc il y avait diverses raisons pour lesquelles certaines
 personnes voulaient en réécrire des morceaux. Mais si elles avaient
 seulement dû réécrire les morceaux qu'elles voulaient vraiment améliorer, ça
 leur aurait donné beaucoup moins de travail. Vous pouvez très bien voir
 comment améliorer un des aspects d'un système, mais ne pas voir comment en
 améliorer un autre ; en fait cela pourrait vous être très difficile de le
 faire aussi bien. Si vous pouviez prendre la partie que vous trouvez bien et
 refaire seulement le morceau pour lequel vous avez des idées, vous pourriez
 avoir un système en tout point meilleur, avec beaucoup moins de travail que
 cela n'en prendrait de le réécrire entièrement. Nous savons tous qu'il peut
 être avantageux de réécrire un système complètement, mais à condition de
 pouvoir lire l'ancien d'abord.</p>
 
 <p>Ainsi, dans le domaine de la programmation, les gens ont développé une
 manière de perdre une bonne partie de leur temps, créant de ce fait un
 apparent besoin en programmeurs, plus important qu'en réalité. Pourquoi y
 a-t-il un manque de programmeurs ? Parce qu'avec la propriété intellectuelle
 ils se sont organisés pour gaspiller la moitié de leur travail ; il semble
 ainsi que nous en ayons besoin de deux fois plus. Quand les gens se tournent
 vers le système de la propriété intellectuelle en disant « Regardez les
 belles statistiques de l'emploi, regardez l'ampleur de cette industrie »,
 cela ne prouve qu'une chose : l'ampleur du gaspillage de temps et
 d'argent. Quand ils parlent de chercher des moyens d'améliorer la
 productivité du programmeur, ils sont ravis de le faire si cela implique des
 outils plus évolués, mais si cela implique de se débarrasser de choses
 précises qui sont faites pour la réduire, ils sont contre – puisque cela
 réduirait le nombre d'emplois en programmation. Il y a comme une
 contradiction interne là-dedans.</p>
 
 <p>Et la nocivité morale qui correspond à ce niveau de nocivité matérielle
 affecte l'esprit de coopération scientifique, qui autrefois était si fort
 que même les scientifiques de pays en guerre continuaient de coopérer, parce
 qu'ils savaient que ce qu'ils faisaient n'avait rien à voir avec la
 guerre. C'était uniquement pour le bénéfice à long terme de l'humanité. De
 nos jours, personne ne se préoccupe plus de ça.</p>
 
 <p>Pour vous représenter ce que c'est que de faire obstacle à l'utilisation
 d'un programme, imaginez un sandwich que vous pourriez manger mais qui ne
 serait pas consommé. Vous pourriez le manger, une autre personne pourrait le
 manger, le même sandwich, autant de fois qu'elle voudrait, et il resterait
 toujours aussi nourrissant qu'à l'origine.</p>
 
 <p>La meilleure chose à faire, ce que nous devrions faire avec ce sandwich,
 serait de l'amener partout où les gens ont faim ; de l'amener à autant de
 bouches que possible, de sorte qu'il alimente autant de personnes que
 possible. Il est certain que nous ne devons pas mettre de prix sur ce
 sandwich, parce que sinon les gens ne pourraient pas se permettre de le
 manger et il serait gaspillé.</p>
 
 <p>Un programme est comme ce sandwich, mais en mieux, parce qu'il peut être
 mangé en même temps dans de nombreux endroits différents, utilisé par des
 personnes différentes les unes après les autres. C'est comme si ce sandwich
 suffisait pour alimenter tout le monde, partout, pour toujours, mais que ça
 lui était interdit parce que quelqu'un croyait qu'il devait le posséder.</p>
 
 <p>Les gens qui croient pouvoir posséder des programmes proposent généralement
 deux types d'arguments. Le premier c'est : « Je l'ai écrit, c'est l'enfant
 de mon esprit, mon cœur, mon âme y est. Comment peut-on me l'enlever ? Où
 qu'il aille, il est à moi, à moi, À MOI !! » Très bien, mais il est curieux
 tout de même que la plupart d'entre eux signent des accords stipulant qu'il
 appartient à l'entreprise pour laquelle ils travaillent.</p>
 
 <p>Aussi je crois que cela fait partie des choses dont vous pouvez facilement
 vous persuader qu'elles sont importantes, mais tout aussi aisément, qu'elles
 n'ont aucune importance.</p>
 
 <p>Habituellement, ces personnes usent de cet argument pour exiger le droit de
 contrôler jusqu'à la façon dont les gens peuvent modifier le programme. Ils
 disent : « Personne ne doit pouvoir gâcher mon œuvre d'art. » Bien, imaginez
 que l'inventeur du plat que vous projetez de cuisiner ait le droit de
 contrôler la façon dont vous le préparez parce que c'est son œuvre
 d'art. Vous voulez enlever du sel, mais il dit : « Oh, non! J'ai conçu ce
 plat et il doit y avoir beaucoup de sel ! » – « Mais mon médecin m'a dit
 qu'il n'était pas bon pour moi de manger salé. Que puis-je faire ? »</p>
 
 <p>La personne qui se sert du programme est évidemment bien plus près de
 l'événement. L'utilisation du programme l'affecte directement tandis que
 l'auteur a seulement une sorte de relation abstraite avec cette
 utilisation. Et donc, pour donner aux gens autant de contrôle que possible
 sur leurs propres vies, c'est l'utilisateur qui doit décider.</p>
 
 <p>Le deuxième argument est économique. « Comment les gens seront-ils payés
 pour programmer ? » disent-ils, et il y a un peu de vrai là-dedans. Mais une
 bonne part de ce qu'ils disent est confus. Et la confusion vient de ce qu'il
 n'est pas du tout pareil de dire « Si nous voulons avoir beaucoup de gens
 pour programmer, nous devons nous assurer qu'ils n'auront pas besoin de
 gagner leur vie d'une autre manière » d'une part, et d'autre part de dire
 « Nous devons conserver le système actuel, nous devons devenir riches en
 programmant. » Il y a une grande différence entre juste percevoir un salaire
 pour vivre et se faire du fric comme le font les programmeurs de nos jours,
 du moins aux États-Unis. Ils disent toujours : « Comment vais-je manger ? »
 Mais le problème n'est pas vraiment de savoir « comment il va manger » mais
 « comment il va manger des sushis ». Ou bien : « Comment ferai-je pour avoir
 un toit au-dessus de la tête ? » Mais le vrai problème est : « Comment
 pourra-t-il se payer un appartement dans une copropriété ? »</p>
 
 <p>Le système actuel a été choisi par les gens qui investissent dans le
 développement logiciel parce que ça leur donne la possibilité de se faire le
 plus d'argent possible, et non parce que c'est le seul moyen possible de
 récolter des fonds pour soutenir l'effort de développement d'un système. En
 fait, aussi récemment qu'il y a dix ou quinze ans, il était courant de
 soutenir le développement logiciel autrement. Par exemple, les systèmes
 d'exploitation de Digital qui étaient libres, même au début des années 70,
 ont été développés par des personnes payées pour ce travail. Beaucoup de
 programmes utiles ont été développés dans les universités. De nos jours ces
 programmes sont souvent vendus, mais il y a quinze ans ils étaient la
 plupart du temps gratuits, et pourtant les gens étaient payés pour leur
 travail.</p>
 
 <p>Lorsque vous avez quelque chose comme un programme, comme un sandwich infini
 ou comme une route qui ne doit être construite qu'une fois, sachant qu'une
 fois construite il importe assez peu de savoir combien de fois vous
 l'utilisez, sachant que cela ne coûte rien de l'utiliser, il est
 généralement bien mieux de ne pas mettre de coût sur cette utilisation. Et
 il y a des tas de choses comme ça que nous développons aujourd'hui, en
 payant des gens pour le faire. Par exemple, toutes ces rues par
 là-bas. Autant il est facile de trouver des gens qui programmeront sans être
 payés, autant il est vraiment impossible d'en trouver qui construiront des
 routes sans être payés. La construction des routes n'est pas un travail
 créatif ni amusant comme la programmation mais il y a plein de rues par
 là-bas. Nous arrivons parfaitement à trouver de quoi payer ces gens et c'est
 bien mieux comme ça que d'avoir dit : « Laissons des entreprises privées
 construire des routes et installer des cabines de péage, et vous paierez un
 péage à chaque coin de rue. Alors les entreprises qui auront sélectionné les
 bons endroits pour mettre leurs routes feront des profits et les autres
 feront faillite. »</p>
 
 <p>Il se produit une chose amusante chaque fois que quelqu'un propose une
 manière de faire de l'argent en accaparant quelque chose. Jusque-là, vous
 aviez probablement un bon nombre de gens vraiment enthousiastes et désireux
 de travailler dans ce domaine. Et la seule question qui se posait était :
 « Comment peuvent-ils trouver un moyen d'existence ? » Si nous pensons aux
 mathématiciens par exemple, il y a beaucoup plus de gens qui veulent être
 des mathématiciens purs que de financement pour que tout le monde le
 devienne. Et même lorsqu'ils obtiennent des fonds, ils n'en obtiennent pas
 beaucoup. Et ces gens ne vivent pas bien. Pour les musiciens, c'est encore
 pire. J'ai vu des statistiques sur ce que gagne le musicien moyen, le péquin
 moyen qui consacre la majeure partie de son temps à tenter de devenir
 musicien dans le Massachusetts ; c'est quelque chose comme la moitié du
 revenu moyen, ou moins. C'est à peine assez pour vivre, c'est dur. Mais il y
 en a un bon nombre qui essaient. Et puis, d'une façon ou d'une autre, quand
 il devient possible d'être très bien payé pour faire quelque chose,
 généralement tous ces gens disparaissent. Et on commence à dire : « Personne
 ne le fera à moins d'être payé aussi bien. »</p>
 
 <p>J'ai vu cela se produire dans le domaine de la programmation. Les mêmes qui
 travaillaient au labo d'IA en étant très peu payés et qui trouvaient ça très
 bien, aujourd'hui n'imagineraient pas travailler pour moins de cinquante
 mille dollars par an. Que s'est-il passé ? Quand vous faites miroiter aux
 gens la possibilité de faire de l'argent, quand ils en voient d'autres faire
 le même travail en étant payés très cher, ils estiment devoir obtenir la
 même chose et personne n'est alors disposé à continuer comme avant. Il est
 facile, une fois que cela s'est produit, de penser que la seule option est
 de payer les gens énormément. Mais ce n'est pas vrai. Si la possibilité de
 faire de l'argent n'existait pas, vous auriez des gens qui accepteraient de
 le faire pour pas grand-chose, surtout si c'était créatif et amusant.</p>
 
 <p>J'ai donc vu ce monde unique du labo d'IA se faire détruire, et la vente du
 logiciel faire partie intégrante de ce qui l'a détruit. J'ai vu également,
 comme je l'ai expliqué, qu'on a besoin de logiciel libre pour retrouver une
 communauté comme celle-là. Mais en y réfléchissant davantage, j'ai compris
 en quoi l'accaparement du logiciel fait du mal à l'ensemble de la société
 – plus particulièrement en poussant les gens à trahir leurs voisins, ce qui
 entraîne l'affaiblissement du lien social ; ce même état d'esprit qui
 conduit les gens à voir quelqu'un se faire poignarder dans la rue et à
 n'avertir personne ; cet état d'esprit dont nous pouvons voir tant
 d'entreprises faire preuve autour de nous. Il m'est apparu clairement que
 j'avais un choix à faire. Je pouvais faire partie de ce monde et me sentir
 malheureux de voir ce que je faisais de ma vie, ou je pouvais décider de le
 combattre. Alors j'ai décidé de le combattre. J'ai consacré ma carrière à
 tenter de reconstruire la communauté de partage du logiciel, à tenter de
 mettre un terme au phénomène d'accaparement d'information utile à tous. Et
 le système GNU est un moyen à cet effet. C'est un moyen technique à des fins
 sociales. Avec le système GNU, j'espère vacciner les utilisateurs contre la
 menace des accapareurs de logiciel.</p>
 
 <p>En ce moment, les accapareurs réclament essentiellement le pouvoir de rendre
 inutile l'ordinateur personnel. Il y a une cinquantaine d'années, il y avait
 des gens aux USA, de la Mafia, qui entraient dans les magasins et les bars,
 surtout les bars quand les bars étaient hors-la-loi, évidemment. Une fois
 entrés, ils disaient : « Pas mal d'endroits par ici ont brûlé
 dernièrement. Vous ne voudriez pas que le vôtre subisse le même sort ? Eh
 bien, nous pouvons vous protéger contre les incendies, vous avez juste à
 nous payer mille dollars par mois et nous ferons en sorte qu'il n'y ait pas
 le feu. » Et ça s'appelait « le racket de protection ». Aujourd'hui nous en
 sommes à quelque chose près à ce qu'une personne nous dise : « Vous avez un
 joli ordinateur ici et vous utilisez quelques programmes. Eh bien, si vous
 ne voulez pas que ces programmes disparaissent, si vous ne voulez pas que la
 police vous poursuive, vous feriez mieux de me payer mille dollars et je
 vous donnerai un exemplaire de ce programme avec une licence. » Et ça
 s'appelle « le racket de protection du logiciel ».</p>
 
 <p>En réalité, ils ne font que mettre des bâtons dans les roues de tous ceux
 qui font ce qui doit être fait, mais ils se prétendent à eux-mêmes, et
 veulent nous faire croire, qu'ils ont une fonction utile. Bon. Ce que
 j'espère, c'est que le jour où ce type de la Mafia du logiciel entrera et
 dira « Vous voulez que ces programmes disparaissent de votre ordinateur ? »
 l'utilisateur puisse répondre « Je n'ai plus peur de vous. J'ai le logiciel
 libre GNU et il n'y a rien que vous puissiez me faire désormais. »</p>
 
 <p>Quelquefois, les gens essaient de se justifier de posséder le logiciel en
 avançant l'idée qu'il faut donner aux gens des incitations pour produire des
 choses. Je suis d'accord avec la notion d'entreprise privée en général et
 avec l'espoir de gagner de l'argent en produisant des choses que d'autres
 apprécient, mais ça se détraque dans le domaine du logiciel
 actuellement. Produire un programme propriétaire, ce n'est pas la même
 contribution à la société que produire ce même programme et le laisser
 libre. Parce que l'écriture du programme est juste une contribution
 potentielle à la société. La vraie contribution à la richesse de la société
 se fait seulement quand le programme est utilisé. Et si vous empêchez
 l'utilisation du programme, la contribution ne se fait pas vraiment. La
 contribution dont la société a besoin ne réside pas dans ces programmes
 propriétaires que tout le monde est tellement incité à faire. La
 contribution que nous voulons vraiment est celle du logiciel libre. Notre
 société se détraque parce qu'elle donne aux gens des incitations pour faire
 ce qui n'est pas très utile et aucune pour faire ce qui est utile. Ainsi
 l'idée sur quoi repose l'entreprise privée n'est pas mise en application. On
 pourrait même dire que la société est névrotique, car après tout, quand une
 personne encourage dans le comportement des autres ce qui n'est pas bon pour
 elle, on appelle ça une névrose. C'est comme cela que se comporte notre
 société, en encourageant les programmeurs à faire des choses qui ne sont pas
 bonnes pour elle.</p>
 
 <p>Je sors un peu du commun. Je préfère croire que je suis un bon membre de la
 société et que je contribue à quelque chose plutôt que de sentir que je
 l'arnaque avec succès, c'est pourquoi j'ai décidé de faire ce que j'ai
 fait. Mais cela tracasse chacun, au moins un petit peu, d'avoir le sentiment
 d'être payé pour faire ce qui n'est pas vraiment utile. Par conséquent,
 cessons de défendre les incitations à faire ce qui est mauvais et essayons
 au moins de proposer des arrangements pour inciter les gens à faire ce qui
 est bon, c'est-à-dire du logiciel libre.</p>
 
 <p>Merci.</p>
 
 <p><strong>[Après ça, RMS a répondu à des questions pendant environ une
 heure. Je n'en ai inclus que quelques-unes dans cette version. La bande
 était mauvaise et je n'ai pas eu le temps de faire le travail nécessaire sur
 la totalité]</strong></p>
 
 <dl>
 <dt><b>Question :</b> Est-ce que quelqu'un a tenté de vous causer des ennuis ?</dt>
 
 <dd><p><b>Réponse :</b> La seule fois où l'on a tenté de me causer des ennuis,
 c'était ces propriétaires, ces prétendus propriétaires, autoproclamés, de
 Gosling Emacs. Hormis le fait qu'ils n'avaient aucune raison de le faire,
 ils ne pouvaient pas faire grand-chose. D'ailleurs, je voudrais attirer
 l'attention de tout le monde sur la façon dont les gens se servent du
 langage pour vous inciter à penser d'une certaine façon et pas
 autrement. Une grande part de la terminologie actuelle dans ce domaine a été
 choisie par les propriétaires autoproclamés de logiciel pour vous inciter à
 assimiler le logiciel à des biens matériels et à oublier les
 différences. L'exemple le plus flagrant en est le terme « pirate ». Refusez
 s'il vous plaît d'utiliser le terme « pirate » pour décrire quelqu'un qui
 souhaite partager du logiciel avec son voisin comme tout bon citoyen.</p>
 
 <p>J'ai oublié de vous dire ceci : La notion de copyright est apparue après
 l'invention de la presse à imprimer. Dans les temps anciens, les auteurs se
 copiaient les uns les autres librement et ceci n'était pas considéré comme
 un mal. Et c'était même très utile : certaines œuvres originales n'ont pu
 survivre, bien que de manière fragmentaire, que grâce à des citations
 extensives dans d'autres œuvres qui, elles, ont survécu.</p>
 
 <p>C'est parce que la copie des livres se faisait à l'unité ; il était dix fois
 plus difficile d'en faire dix copies qu'une seule. Puis la presse à imprimer
 a été inventée. Ceci n'a pas empêché les gens de copier les livres à la
 main, mais comparée à l'impression, la copie manuelle était si pénible
 qu'elle aurait aussi bien pu être impossible.</p>
 
 <p>Quand les livres ont pu être produits en masse, le copyright commença à
 avoir un sens. De plus, celui-ci ne confisquait pas la liberté des lecteurs
 ordinaires, puisqu'en tant que membre du public qui n'avait pas de presse,
 vous ne pouviez pas copier de livre de toute façon. Le copyright ne vous
 privait donc d'aucune liberté. Il a été inventé, et avait du sens
 moralement, à cause d'un changement technologique. Or aujourd'hui le
 changement inverse se produit. La copie individuelle d'information se fait
 de mieux en mieux et nous pouvons voir que la finalité du progrès
 technologique est de permettre de copier n'importe quel genre
 d'information&hellip; <span>[coupure due à l'inversion de la bande]</span>.</p>
 
 <p>Ainsi nous retournons à la même situation que dans le monde antique où le
 copyright n'avait aucun sens.</p>
 
 <p>Considérons notre concept de propriété. Il a son origine dans les objets
 matériels. Ces derniers satisfont la loi de conservation, à peu de choses
 près. Oui c'est vrai, je peux casser une craie en deux, mais ce n'est pas
 ça ; elle va s'user, se « consommer ». Mais fondamentalement ceci est une
 chaise [pointant une chaise du doigt]. Je ne peux pas simplement claquer des
 doigts et en avoir deux. La seule manière d'en avoir une deuxième, c'est de
 la construire comme l'a été la première. Ça prend plus de matières
 premières, plus de travail de production. Nos idées de propriété ont été
 développées pour que le sens moral s'accorde avec ces faits.</p>
 
 <p>Pour une portion d'information que tout le monde peut copier, les faits sont
 différents, et donc les attitudes morales correspondantes sont
 différentes. Les attitudes morales proviennent de la réflexion sur le nombre
 de gens que cela va aider et le nombre de gens que cela va léser de faire
 certaines choses. Lorsqu'il s'agit d'un objet matériel, vous pouvez venir
 prendre cette chaise, mais vous ne pouvez pas venir la copier. Et si vous
 emportiez la chaise, cela ne produirait rien, vous n'auriez aucune
 excuse. Si quelqu'un dit « J'ai travaillé pour faire cette chaise, une seule
 personne peut avoir cette chaise, ça peut aussi bien être moi », nous
 pourrions aussi bien dire « Oui, c'est compréhensible. » Quand une personne
 dit « J'ai gravé les bits de ce disque, une seule personne peut l'avoir,
 alors n'essayez pas de me l'enlever », ça se comprend aussi. Si une seule
 personne peut avoir le disque, pourquoi pas celui à qui il appartient ?</p>
 
 <p>Mais quand quelqu'un d'autre arrive et dit « Je ne vais pas abîmer votre
 disque, je vais juste en faire un autre comme lui par magie, je l'emmènerai
 et vous pourrez continuer à utiliser ce disque comme vous le faisiez
 auparavant », eh bien, c'est la même chose que si quelqu'un disait « J'ai un
 copieur magique de chaise. Vous pouvez continuer à profiter de votre chaise
 en l'ayant toujours à disposition mais j'en aurai une aussi. » C'est une
 bonne chose.</p>
 
 <p>Si les gens n'ont pas à construire mais juste à claquer des doigts et
 reproduire, c'est merveilleux. Mais ce changement technologique ne convient
 pas à ceux qui voudraient pouvoir posséder des copies particulières et en
 tirer de l'argent. C'est une idée qui ne correspond qu'aux objets qui se
 conservent. Aussi font-ils leur possible pour transformer les programmes en
 objets matériels. Vous êtes-vous demandés pourquoi, quand vous allez dans un
 magasin de logiciel et que vous achetez un exemplaire d'un programme, cela
 revient à acheter quelque chose qui ressemble à un livre ? Ils veulent que
 les gens pensent à leur achat comme à un objet matériel, sans se rendre
 compte qu'il est en réalité sous forme de données numériques copiables.</p>
 
 <p>Après tout, qu'est-ce qu'un ordinateur à part une machine universelle ? Vous
 avez probablement étudié les machines universelles de Turing, ces machines
 qui peuvent imiter n'importe quelle autre machine. L'avantage d'une machine
 universelle, c'est que vous pouvez lui faire imiter n'importe quelle autre
 machine et que les modes d'emploi peuvent être copiés et changés, toutes
 choses que vous ne pouvez pas faire avec un objet matériel. Et c'est
 exactement ce que les accapareurs de logiciel veulent que le public arrête
 de faire. Ils veulent profiter du changement technologique, en marche vers
 les machines universelles, mais ils ne veulent pas que le public en profite.</p>
 
 <p>En gros, ils tentent de conserver « l'âge de l'objet matériel », mais
 celui-ci est dépassé. Notre conception du bien et du mal doit être synchrone
 avec les faits réels du monde dans lequel nous vivons.</p>
 </dd>
 
 <dt><b>Question :</b> Ainsi ça se ramène à la propriété de
 l'information. Pensez-vous qu'il y ait des exemples où, selon vous, il soit
 juste de posséder l'information ?</dt>
 
 <dd><p><b>Réponse :</b> Pour une information qui n'est pas utile au public ou qui a
 un caractère personnel, je dirais OK. En d'autres termes, l'information qui
 porte, non sur la manière de faire les choses mais sur ce que vous avez
 l'intention de faire ; l'information dont la seule valeur pour les autres
 est spéculative ; celle qui leur permet de vous faire perdre de l'argent
 mais avec laquelle ils ne peuvent véritablement rien créer. Je dirais qu'il
 est parfaitement raisonnable de garder ce genre de chose secrète et sous
 contrôle.</p>
 
 <p>Mais l'information créatrice, celle que les gens peuvent utiliser ou dont
 ils peuvent profiter, et ce d'autant mieux que plus de gens y auront accès,
 nous devons toujours en encourager la copie.</p>
 </dd>
 </dl>
 </div>
 
 <div class="translators-notes">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 <hr /><b>Notes de traduction</b><ol>
 <li><a id="TransNote1" href="#TransNote1-rev"
 class="nounderline">&#8593;</a> 
 ITS <i>(Incompatible Timesharing System)</i> : « Système à temps partagé
 incompatible », conçu par les hackers du laboratoire d'intelligence
 artificielle et nommé en opposition avec CTSS <i>(Compatible Time Sharing
 System)</i>, utilisé précédemment au MIT.</li>
 <li><a id="TransNote2" href="#TransNote2-rev"
 class="nounderline">&#8593;</a> 
 Nous traduisons maintenant <i>proprietary</i> par « privateur ».</li>
 <li><a id="TransNote3" href="#TransNote3-rev"
 class="nounderline">&#8593;</a> 
 <i>Wheel bit</i> (litt. bit de gouvernail) : il s'agit d'un bit particulier
 du nombre binaire définissant un utilisateur sous Twenex (ou certains autres
 systèmes à temps partagé des années 80), qui permet à cet utilisateur de
 faire certaines opérations interdites à l'utilisateur normal. Les privilèges
 du mode <i>wheel</i> sont analogues à ceux de <i>root</i> sous Unix.</li>
 <li><a id="TransNote4" href="#TransNote4-rev"
 class="nounderline">&#8593;</a> 
 DDT signifiait à l'origine <i><abbr title="Digital Equipment
 Corporation">DEC</abbr> Debugging Tape</i> (bande de débogage de
 DEC). C'était un ensemble de programmes, développé en 1961, permettant de
 déboguer le système d'exploitation du PDP-1 (les bandes dont il s'agissait
 étaient des bandes perforées). Des systèmes similaires existent pour des
 machines plus récentes, ils ont pour nom <i>Dynamic Debugging Technique</i>,
 de manière à garder le même sigle. DDT fait allusion à l'insecticide <i>[bug
 killer]</i> de l'époque.</li>
 <li><a id="TransNote5" href="#TransNote5-rev"
 class="nounderline">&#8593;</a> 
 <i>Free University Compiler Kit</i> peut s'interpréter de deux manières
 différentes, car on ne sait pas si l'adjectif <i>free</i> qualifie
 <i>compiler kit</i> ou <i>university</i>. En fait, il s'agit du « kit de
 compilation de l'Université Libre (d'Amsterdam) ».</li>
 <li><a id="TransNote6" href="#TransNote6-rev"
 class="nounderline">&#8593;</a> 
 <i>C-shell</i> se prononce de la même façon que <i>seashell</i>
 (coquillage). Il n'est pas impossible que ce jeu de mots soit voulu.</li>
 <li><a id="TransNote7" href="#TransNote7-rev"
 class="nounderline">&#8593;</a> 
 <i>Bouncing ball</i> : peut-être une allusion à la « balle bondissante » du
 karaoke qui rebondit sur les paroles affichées à l'écran au moment où il
 faut les chanter.</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; 1987 Richard Stallman et Bjrn Remseth
 </p>
 <p>
 La reproduction exacte et la distribution de copies intégrales de cette
 transcription sont permises sur n'importe quel support d'archivage, pourvu
 que l'avis de copyright et le présent avis de permission y figurent de
 manière apparente.
 </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 : Miluz.<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: 2022/06/11 14:31:02 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>