path: root/talermerchantdemos/blog/articles/fr/stallman-kth.html

<!--#set var="ENGLISH_PAGE" value="/philosophy/stallman-kth.en.html" -->

<!--#include virtual="/server/header.fr.html" -->
<!-- Parent-Version: 1.77 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Conférence en Suède - Projet GNU - Free Software Foundation</title>

<!--#include virtual="/philosophy/po/stallman-kth.translist" -->
<!--#include virtual="/server/banner.fr.html" -->
<h2>Conférence de RMS au KTH (Suède), le 30 octobre 1986</h2>

<div style="text-align: center;">
<p><em>[Kungliga Tekniska Högskolan (Institut royal de technologie)<br />
Stockholm, Suède]</em></p>
<p><em>organisée par l'association des étudiants<br />
« Datorföreningen Stacken »<br />
le 30 octobre 1986</em></p>
</div>

<p><strong>[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.]</strong></p>

<p>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. <br/><br/>Quelqu'un : <cite>Janne, han trenger ingen mike</cite>
(Janne, il n'a pas besoin de micro).<br/><br/>RMS : Jan, tu es prêt à courir
chercher les autres ?<br/><br/>JMR : Je suis à la recherche d'un micro et
quelqu'un me dit qu'il est dans ce casier fermé à clé.<br/><br/>RMS :
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 ? (Réponse :
Yeaaah !)</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 <cite>[paging]</cite> 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
<cite>[scheduler]</cite> 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 <cite>munching squares</cite>
(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. » Certaines personnes 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
<cite>wheel bit</cite><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 <cite>wheel bits</cite> 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 <cite>wheel bit</cite> à 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 – <cite>Radio Free OZ</cite> (la radio libre
d'Oz). » Plus tard j'ai découvert que <cite>Radio Free OZ</cite> est l'une
des expressions utilisées par le <cite>Firesign Theater</cite>. 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; [à ce moment-là, RMS est interrompu par un
tonnerre d'applaudissements]</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 <cite>GNU's Not Unix</cite> (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 <cite>Tint Is Not <abbr title="Text Editor and
COrrector">Teco</abbr></cite>, et plus tard c'est passé par des noms comme
SINE pour <cite>Sine Is Not Emacs</cite>, et FINE pour <cite>Fine Is Not
Emacs</cite>, et EINE pour <cite>Eine Is Not Emacs</cite>, et ZWEI pour
<cite>Zwei Was Eine Initially</cite>, 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é <cite>the Free
University Compiler Kit</cite>, 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 <cite>string</cite>
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
<cite>[core]</cite> 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 <cite>mock</cite> (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 <cite>float</cite> ou <cite>double</cite>
à 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
<cite>[breakpoints]</cite> 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
<cite>foo</cite> 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>print X[$foo++]</pre>

<p>mais d'abord vous faites</p>

<pre>set $foo=0</pre>

<p>OK, quand vous faites ça [il montre l'expression <code>print</code>], 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 <code>print</code>] 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 <cite>[frames]</cite> 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>set $PC=&lt;un certain nombre&gt;</pre>

<p>Ainsi vous pouvez positionner le compteur ordinal <cite>[program
counter]</cite>. Vous pouvez également positionner le pointeur de pile
<cite>[stack pointer]</cite>, ou bien vous pouvez dire</p>

<pre>set $SP+=&lt;quelque_chose&gt;</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 <cite>[string constants]</cite> ; 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
<cite>[interrupt driven input]</cite> ; 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 » <cite>[University of
Arizona Portable Optimizer]</cite>. 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>
  r[3]=r[2]+4
</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 <cite>[assignment]</cite> : 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 <cite>[pattern
matcher]</cite>, 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>
     (set (reg 2)
          (+ (reg 2)
             (int 4)))
</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 « reg » par exemple, c'est toujours un nombre entier,
parce que les registres sont numérotés, mais « + » 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 <cite>slots</cite>
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 <code>add</code> 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
<cite>slot</cite> 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 à .+1 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
<cite>slots</cite> 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>(Question : Avez-vous un générateur de code pour le 32000 ?)<br/><br/>
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. (Question :
Une pause ?) 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
<cite>[Remote Procedure Call]</cite>. 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é » <cite>[capability ports]</cite>
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 « FOO » cela signifie « cherchez les versions qui existent pour FOO
et prenez la dernière ». Mais si vous dites « FOO. » cela signifie
« utilisez exactement le nom FOO et aucun autre ». Si vous dites « FOO.3. »
cela veut dire « utilisez exactement le nom FOO.3 » qui naturellement est la
version trois de FOO et aucune autre. En sortie, si vous dites juste
« FOO », ça va créer une nouvelle version de FOO, mais si vous dites
« FOO. », ç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 <cite>[star matching]</cite> : 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>
  foo.1 foo.2 bar.8
</pre>

<p>Si je dis « * », ça équivaut à</p>
<pre>
  foo bar
</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 « *. », 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
« *.c » et « *.c. ». Ceci [le premier] vous donnera essentiellement les
références sans version de tous les fichiers « .c », tandis que cela [le
second] vous donnera toutes les versions&hellip; Bon, pas vraiment, vous
devriez dire « *.c.*. », 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 « Arrêt » à 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 <cite>shell</cite> a déjà été écrit, je crois. Il a deux modes, l'un
imitant le <cite>Bourne shell</cite> et l'autre imitant le
<cite>C-shell</cite>,<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 <cite>make</cite>
existe, <cite>ls</cite> é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 <cite>Free
Software Foundation</cite> (Fondation pour le logiciel libre). Naturellement
les programmes libres <cite>[free programs]</cite>, ce n'est pas la même
chose que la distribution gratuite <cite>[free distribution]</cite>. 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 <cite>Free Software Foundation</cite>. 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 non-divulgation, 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; [coupure due à l'inversion de la bande].</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 class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<hr /><b>Notes de relecture</b><ol>
<li id="TransNote1">ITS <cite>(Incompatible Timesharing System)</cite> :
« Système à temps partagé incompatible », conçu par les hackers du
laboratoire d'intelligence artificielle et nommé en opposition avec CTSS
<cite>(Compatible Time Sharing System)</cite>, utilisé précédemment au
MIT. <a href="#TransNote1-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote2">Nous traduisons maintenant <cite>proprietary</cite> par
« privateur ». <a href="#TransNote2-rev"
class="nounderline">&#8593;</a></li>
<li id="TransNote3"><cite>Wheel bit</cite> (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 <cite>wheel</cite> sont
analogues à ceux de <cite>root</cite> sous Unix. <a href="#TransNote3-rev"
class="nounderline">&#8593;</a></li>
<li id="TransNote4">DDT signifiait à l'origine <cite><abbr title="Digital
Equipment Corporation">DEC</abbr> Debugging Tape</cite> (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 <cite>Dynamic Debugging
Technique</cite>, de manière à garder le même sigle. DDT fait allusion à
l'insecticide <cite>[bug killer]</cite> de l'époque. <a
href="#TransNote4-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote5"><cite>Free University Compiler Kit</cite> peut
s'interpréter de deux manières différentes, car on ne sait pas si l'adjectif
<cite>free</cite> qualifie <cite>compiler kit</cite> ou
<cite>university</cite>. En fait, il s'agit du « kit de compilation de
l'Université Libre (d'Amsterdam) ». <a href="#TransNote5-rev"
class="nounderline">&#8593;</a></li>
<li id="TransNote6"><cite>C-shell</cite> se prononce de la même façon que
<cite>seashell</cite> (coquillage). Il n'est pas impossible que ce jeu de
mots soit voulu. <a href="#TransNote6-rev"
class="nounderline">&#8593;</a></li>
<li id="TransNote7"><cite>Bouncing ball</cite> : 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. <a
href="#TransNote7-rev">&#8593;</a></li>
</ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.fr.html" -->
<div id="footer">
<div class="unprintable">

<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Il existe aussi <a
href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
orphelins et autres corrections ou suggestions peuvent être signalés à <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Nous faisons le maximum pour proposer des traductions fidèles et de bonne
qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
sur cette page, ainsi que vos suggestions d'ordre général sur les
traductions, à <a href="mailto:web-translators@gnu.org">
&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Pour tout renseignement sur la coordination et la soumission des
traductions de nos pages web, reportez-vous au <a
href="/server/standards/README.translations.html">guide de traduction</a>.</p>
</div>

<!-- 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, 2009, 2010, 2020 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: 2020/07/01 16:32:17 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>