Conférence de RMS au KTH (Suède), le 30 octobre 1986

[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.]

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 MIT 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.

Quelqu'un : Janne, han trenger ingen mike (Janne, il n'a pas besoin de micro).

RMS : Jan, tu es prêt à courir chercher les autres ?

JMR : Je suis à la recherche d'un micro, et quelqu'un me dit qu'il est dans ce casier fermé à clé.

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.

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

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.

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.

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.

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¹ 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.

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.

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.

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.

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.

Mais un des problèmes auxquels j'ai dû faire face était celui des logiciels propriétaires.² 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 fasse, ç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, ils leur suffisait de les mettre de côté et d'appeler le technicien : « Reprenez-les et ramenez-nous-en des neufs. »

À 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 [paging] 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 [scheduler] 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.

Je suppose que c'est l'un des inconvénients de la VLSI (intégration à très grande échelle) : il n'est plus vraiment pratique d'ajouter des instructions sur vos machines.

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 munching squares (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.

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.

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 parce, 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.

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.

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.

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.

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 wheel bit³ 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 wheel bits d'à peu près tout le monde avaient été supprimés.

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⁴ 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 wheel bit à 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 – Radio Free OZ (la radio libre d'Oz). » Plus tard j'ai découvert que Radio Free OZ est l'une des expressions utilisées par le Firesign Theater. Je ne le savais pas à ce moment-là.

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é. »

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.

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.

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.

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… et des années.

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 ouvraient toujours 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 j'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… [à ce moment-là, RMS est interrompu par un tonnerre d'applaudissements]

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 ARPA 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.

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 ».

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.

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 logiciel libre. 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 quelques 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.

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.

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 GNU's Not Unix (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 Tint Is Not Teco, et plus tard c'est passé par des noms comme SINE pour Sine Is Not Emacs, et FINE pour Fine Is Not Emacs, et EINE pour Eine Is Not Emacs, et ZWEI pour Zwei Was Eine Initially, et finalement on est arrivé à GNU.

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é the Free University Compiler Kit, qui était intéressant, et j'ai pensé qu'avec un nom pareil je pourrais peut-être l'avoir.⁵ 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.

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 ».

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 string dans ce langage était un type paramétré ; vous pouviez dire string(n) si vous vouliez une chaîne d'une longueur particulière ; vous pouviez également juste dire string, et le paramètre était déterminé à partir du contexte. Maintenant, les chaînes sont très importantes et nécessaires à beaucoup de constructions qui les utilisent pour fonctionner rapidement. Et ça veut dire qu'il devait y avoir 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 quelques idées sur la façon de gérer différents types de machines.

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 forward du Pascal était obsolète. Pour cette raison il fallait lire le programme dans son intégralité, le garder en mémoire centrale [core] 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 quelques dix passes du compilateur en compilation croisée sur cette machine et j'ai constaté alors que la seconde ne pourrait jamais fonctionner.

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.

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.

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 mock (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).

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.

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.

À 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 que Gosling avait leur permission après tout, 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, et mis une annonce sur le réseau comme quoi je n'avais pas le droit de distribuer le programme. Ils n'ont pas réellement 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.

(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.)

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.

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 help 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.

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 float ou double à 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 print*$.next 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.

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 [breakpoints] 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 $foo+=5 pour incrémenter la valeur $foo de 5, ou juste $foo++. 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 $foo--==0. Est-ce que tout le monde suit ? Faire décroître foo et une fois qu'il est à zéro, pause. Vous faites démarrer $foo 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 :

print X[$foo++]

mais d'abord vous faites

set $foo=0

OK, quand vous faites ça [il montre l'expression print], vous obtenez l'élément zéro de X et quand vous le faites à nouveau, il atteint le premier élément. Supposez que ce soient des pointeurs vers des structures, alors vous mettez probablement un astérisque là [avant le X dans l'expression print] et à chaque fois, il affiche la structure sur laquelle pointe l'élément suivant du tableau. Et bien sûr vous pouvez répéter cette commande en tapant « Entrée ». Si ce n'est pas suffisant de répéter une seule chose, vous pouvez créer une « commande utilisateur ». Vous pouvez dire define mumble, vous mettez quelques lignes de commandes puis end. Vous venez ainsi de définir une commande mumble 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 help comme des commandes intégrées.

Une autre chose peu habituelle dans ce débogueur, c'est la capacité d'écarter des cadres [frames] 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 :

set $PC=<un certain nombre>

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

set $SP+=<quelque_chose>

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 return. Vous sélectionnez un cadre de la pile et vous dites return. 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.

Et si vous combinez tout ça, vous avez pas mal de contrôle sur ce qui se passe dans un programme.

Une autre chose assez amusante : C a des constantes qui sont des chaînes de caractères [string constants] ; 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 à malloc dans le programme débogué, laisse tourner malloc, puis reprend la main. Ainsi il trouve de façon transparente un endroit où placer la chaîne constante.

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 [interrupt driven input] ; 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.

Deux autres parties centrales du système GNU existent déjà. L'un est le nouveau compilateur C et l'autre le noyau Trix.

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 » [University of Arizona Portable Optimizer]. 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 add peut être représentée comme ceci :

  r[3]=r[2]+4

C'est une représentation interne au compilateur de l'instruction « prendre le contenu du registre n°2, y ajouter 4 et le stocker dans le registre n°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.

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 [assignment] : 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.

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 [pattern matcher], 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.

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 :

     (set (reg 2)
          (+ (reg 2)
             (int 4)))

Ç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.

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.

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 slots de la pile. Sur certaines machines, des instructions peuvent devenir invalides quand ça arrive. Par exemple sur le 68000, on peut ajouter depuis un registre dans la mémoire et ajouter depuis la mémoire dans un registre mais pas ajouter depuis une adresse mémoire vers une autre. Par exemple, si lors d'une instruction add vous sortez vers un 68000 et que les deux éléments se retrouvent dans la mémoire, ce n'est pas valide. Donc ce dernier passage examine le tout et copie au besoin des éléments dans les registres ou en dehors des registres, pour corriger ce genre de problème.

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 slot de mémoire où elle vit vraiment.

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.

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.

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.

Actuellement ce compilateur fonctionne à peu près aussi rapidement que le PCC. 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.

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.

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 slots 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.

(Question : Avez-vous un générateur de code pour le 32000 ?)

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 argument 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.

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.

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.

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 [Remote Procedure Call]. 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é » [capability ports] 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.

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.

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 tail 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.

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 ».

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.

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.

Et cette idée peut être rapprochée de l'utilisation de l'astérisque comme joker [star matching] : 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 :

  foo.1 foo.2 bar.8

Si je dis « * », ça équivaut à

  foo bar

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… Bon, pas vraiment, vous devriez dire « *.c.*. », mais ici je ne tiens pas compte des détails.

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.

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.

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.

Un shell a déjà été écrit, je crois. Il a deux modes, l'un imitant le Bourne shell et l'autre imitant le C-shell,⁶ dans le même programme. Je n'en ai pas reçu de copie et je ne sais pas combien de travail j'aurai à faire dessus. Il y a encore beaucoup d'autres utilitaires. Un make existe, ls également ; il y a Bison qui remplace YACC et qui est déjà distribué. Il existe quelque chose d'assez proche de Lex, mais qui n'est pas totalement compatible et a besoin d'être retravaillé. Et en général, ce qui reste à faire est beaucoup moins important que ce qui a été fait mais on a toujours besoin de beaucoup de gens pour aider.

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⁷). 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.

[Ici, nous avons eu 15 minutes de pause]

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 Free Software Foundation (Fondation pour le logiciel libre). Naturellement les programmes libres [free programs], ce n'est pas la même chose que la distribution gratuite [free distribution]. Je l'expliquerai en détail plus tard.

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 Free Software Foundation. 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.

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.

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.

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.

Mais l'analogie qui a été choisie fut celle des livres, sur lesquels s'appliquent le copoyright. 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.

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 à CMU, 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 par exemple 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.

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.

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é.

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.

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.

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.

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.

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.

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 laissez 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. »

Après être tombé sur des gens qui disaient qu'il 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.

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.

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.

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.

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.

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.

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… 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.

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.

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.

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.

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.

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.

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é.

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.

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 !! » Bon, 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.

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.

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 ? »

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.

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é ? »

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.

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. »

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. »

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.

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.

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 ».

En réalité, il 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. »

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.

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, et 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.

Merci.

[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 un travail approprié sur la totalité]

Question : Est-ce que quelqu'un a tenté de vous causer des ennuis ?

Réponse : 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.

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.

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.

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… [coupure due à l'inversion de la bande].

Ainsi nous retournons à la même situation que dans le monde antique où le copyright n'avait aucun sens.

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.

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 ?

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.

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.

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.

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.

Question : 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 ?

Réponse : 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.

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.