Conférence en Suède- Le projet GNU - Free Software Foundation (FSF)

Conférence de RMS (Richard M. Stallman) au KTH

(Kungliga Tekniska Högskolan (Institut Royal de Technologies))
Stockholm Suède

organisé par l'association des étudiants
« Datorföreningen Stacken »

30 octobre 1986

[Note : Ceci une transcription légèrement révisée de l'entretien. En tant que tel, il contient des faux départs en plus de locutions naturelles en anglais parlé mais qui paraissent bizarres dans une publication. Il n'est pas évident de savoir comment le traduire dans un anglais correct sans faire violence au discours original.]

Il semble qu'il y a 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 M.I.T. autrefois. Ce qui faisait du laboratoire d'Intelligence Artificielle un endroit si particulier. Mais des gens me disent aussi, étant donné qu'il s'agit de personnes totalement différentes de celles qui étaient à la conférence lundi et mardi, que je dois parler de ce qu'il se passe dans le projet GNU et que je devrais dire pourquoi le logiciel et l'information ne peuvent pas être considérés comme des propriétés. Ce qui veut dire qu'il y a trois entretiens en tout. 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 les diviser 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 quand c'est fini et les gens peuvent sortir et je peux envoyer Jan Rynning dehors pour appeler les autres.

[Quelqu'un dit : « Jan, han trenger ingen mike ? » (traduction : « Jan, vous avez besoin d'un microphone ? »)]

Jan, êtes-vous prêt à sortir en courant pour aller chercher les autres personnes ?

JMR : Je recherche un microphone, quelqu'un me dit qu'il est à l'intérieur de cette boîte verrouillée.

RMS : Et bien, autrefois au laboratoire d'I.A., nous aurions pris une masse et nous l'aurions fendu jusqu'à ce qu'il s'ouvre et la porte cassée aurait été une leçon pour quiconque aurait osé mettre sous clé ce dont les gens avaient besoin de se servir. Heureusement toutefois que j'ai appris le chant bulgare, aussi je n'ai aucune peine à me débrouiller sans microphone.

Bon, dois-je installer ce système pour vous signaler les différentes parties de l'entretien ou vous avez juste envie de le suivre jusqu'au bout ?

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, probablement comme la plupart, un service informatique. 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 une pénurie de terminaux pour la plupart d'entre nous. Or pas mal de professeurs en avaient un personnellement dans leurs bureaux, ce qui était du gaspillage, mais typique de leur attitude. Quand j'ai visité le laboratoire d'Intelligence Artificielle au M.I.T., j'ai trouvé un esprit qui différait de celui-ci de façon rafraîchissante. Par exemple : là, on considérait que les terminaux étaient à tout le monde et les professeurs s'étaient enfermés à clef dans leurs bureaux à force de voir leurs portes défoncées. On m'a montré une fois un chariot avec un grand bloc de fer au-dessus. Celui qui avait été utilisé pour défoncer la porte du bureau d'un des professeurs quand il a eu le culot d'y enfermer un terminal. Il y en avait très peu à cette époque. Il y avait à peu près quelque chose comme cinq terminaux à écran pour tout le système, aussi si l'un d'entre eux était bloqué, c'était un vrai désastre.

Dans les années qui ont suivi, j'ai été inspiré par ces idées et de nombreuses fois j'ai escaladé les plafonds ou sous les planchers pour débloquer les salles qui contenaient des machines dont les gens avaient besoin. Et je laissais derrière un mot qui expliquait aux gens qu'il ne devaient pas être aussi égoïste pour fermer la porte. Les gens qui fermaient la porte, au fond, ne pensaient qu'à eux. Ils avaient une raison de le faire, bien-sûr. Ils pensaient quelque part qu'ils pouvaient être volés et désiraient fermer à clef. Mais ils ne pensaient pas aux autres qui souffraient d'avoir des choses enfermées 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 de la fermeture 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, que les autres aillent au diable ! », et c'est exactement l'esprit que nous devons leur apprendre à ne pas avoir.

Mais cet esprit d'ouvrir les portes n'était pas un comportement isolé, il faisait partie d'une façon de vivre à part entière. Les hackers du laboratoire d'I.A. étaient vraiment très motivés pour écrire de bons programmes. Et des programmes intéressants. Ils étaient à ce point impatients que le travail se fasse, qu'ils n'acceptaient pas de voir les terminaux enfermés ou quoi que ce soit d'autre que les gens pouvaient faire pour entraver le travail utile. C'est la différence entre les personnes au moral d'acier qui s'inquiètent vraiment de ce qu'elles essayent de faire et les gens qui prennent ça juste pour un boulot. Mais si c'est juste un boulot, qui s'inquiète vraiment de savoir si les gens qui vous embauchent sont assez stupides pour vous inciter à vous reposer et attendre ? 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 laboratoire d'I.A., c'était la protection des dossiers. Il n'y avait aucune sécurité sur l'ordinateur. Et nous l'avons très consciemment voulu comme ça. Les hackers qui ont écrit le « Système de répartition du temps incompatible » (Incompatible Timesharing System) avaient jugé que la protection des dossiers n'était qu'un moyen comme un autre pour un soi-disant directeur de système, d'avoir du pouvoir sur tout le monde. Ils n'ont pas voulu que n'importe qui puisse avoir du pouvoir sur eux comme ça. Aussi, ils n'ont pas mis en application 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'aviez jamais à vous asseoir impuissant parce qu'il n'y avait PAS D'ISSUE, alors que vous saviez parfaitement quoi faire mais parce qu'il avait été décidé de ne pas vous faire confiance pour ça. Vous n'aviez pas à laisser tomber et rentrer à la maison en attendant que quelqu'un vienne le matin pour réparer le système, alors que vous saviez dix fois mieux que lui ce qu'il fallait faire.

Et nous n'avons laissé aucun professeur, aucun patron non plus décider quel travail allait être effectué, 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 qui est nécessaire. Nous étions les seuls, les plus aptes à savoir quel genre d'améliorations étaient possibles. Et nous parlions toujours entre nous pour savoir comment nous voulions voir le système évoluer, quelles sortes d'idées ordonnées vues dans d'autres systèmes, nous pouvions utiliser. Ainsi au final, nous avions une anarchie de fonctionnement sans douleur et après mon expérience là-bas, je fus convaincu que c'était la meilleure façon de vivre pour les gens.

Malheureusement le laboratoire d'I.A. sous cette angle a été détruit. Pendant des années nous avions craint que le laboratoire ne soit détruit par un autre labo du M.I.T., le laboratoire d'Informatique dont le directeur était le genre de type à construire un empire. Il faisait tout ce qu'il pouvait pour avoir une promotion à l'intérieur du M.I.T. et faire grossir son organisation. Personne ne voulait faire les choses à sa manière étant donné qu'il croyait que les gens devaient obéir aux ordres et d'autres choses dans le style.

Mais ce danger, nous avions réussi à nous en défendre. Il a été détruit par quelque chose que nous n'avions pas prévu : l'esprit commercial. Vers le début des années 80, les hackers ont soudainement compris qu'il y avait maintenant un intérêt commercial à faire ce qu'ils faisaient. Il était possible de devenir riche en travaillant pour des compagnies privées. Tout ce qu'il suffisait de faire, c'était de cesser de partager le travail et détruire le labo d'I.A. du M.I.T. Et c'est ce qu'ils ont fait, malgré tous mes efforts pour les en empêcher.

L'essentiel des programmeurs compétents du laboratoire du M.I.T., 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 drôles et des gens qui faisaient les choses les plus intéressantes avec. Et aussi un esprit qu'il était très plaisant à partager. Une fois ceci mort, il n'y avait plus d'endroit à recommander aux nouveaux. Aussi, ils ont cessé d'arriver. Il n'y avait plus personne qui aurait pu les inspirer, personne dont ils auraient pu apprendre les traditions. De plus personne de qui apprendre à bien programmer. Avec juste une petite équipe de professeurs et d'étudiants diplômés qui ne savaient pas vraiment comment faire marcher un programme, vous ne pouviez pas apprendre à faire fonctionner un bon programme. Aussi le labo d'I.A. du M.I.T. que j'aimais a disparu. Et après quelques années passées à me battre contre les gens qui avait fait ça, pour essayer de les punir pour ça, j'ai décidé de me consacrer à créer une nouvelle communauté avec cet esprit.

Mais un des problèmes auxquels j'ai dû faire face fut celui des logiciels propriétaires (18Ko). Par exemple, ce qu'il s'est passé au laboratoire une fois les hackers partis, c'est que les machines et les logiciels que nous avions développés ne pouvaient plus être maintenus. Les logiciels marchaient évidemment et continuaient de marcher si personne ne les changeait, mais pas les machines. Les machines allaient casser et personne n'allait pouvoir les réparer et par la suite on allait les jeter. Dans les vieux jours, oui, il y avait des contrats d'entretien pour les machines mais c'était une plaisanterie pour l'essentiel. C'était une manière de participer après que les experts du labo d'IA aient arrangé le problème. Parce que si vous aviez laissé les personnes de service le faire, ça leur aurait pris des jours. Et vous ne vouliez pas que ça arrive. Vous vouliez que ça marche. Aussi, les personnes qui savaient faire ce genre de choses allaient réparer ça très vite, puisqu'elles étaient dix fois plus compétentes que n'importe quelle personne du service. Ils pouvaient faire un bien meilleur travail. Et donc si les cartes étaient abîmées, ils avaient juste à les laisser là et appeler les personnes de service « Reprenez-les et ramenez-nous en de nouvelles ».

À la belle époque, nos hackers avaient également l'habitude de modifier les machines qui venaient de Digital. Par exemple, ils construisaient des boîtes de pagination à poser sur le PDP-10's. De nos jours, je pense qu'il y en a certains ici [à Stockholm] qui le font aussi. Mais ce n'était pas courant en ces temps-là. Et aux temps très anciens, au début des années 60, les gens modifiaient les ordinateurs en ajoutant toutes sortes de nouvelles instructions et de nouveaux systèmes fantaisistes de temps partagé. De sorte que le PDP-1 du M.I.T., 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 dans les années 60. Et il avait un planificateur matériel spécial pour aider les unités logiques et d'étranges dispositifs de mémoire-traçante qui rendait possible le fait de relier individuellement les périphériques matériels à des systèmes de répartition du temps et des tas d'autres choses comme ça que je connais à peine. Je pense qu'ils ont également construit, dans un certain type de mode d'adressage étendu qu'ils ont rajouté, l'index des registres et l'adressage indirect et ont transformé pour l'essentiel une toute petite machine en une autre à peu près correcte.

Je devine que l'un des inconvénients de la VLSI (Very Large Scale Integration (intégration à très grande échelle)) est qu'il n'est plus vraiment pratique d'ajouter des instructions sur vos machines.

Le PDP-1 avait des fonctions très intéressantes, particulièrement de pouvoir être accessible à des programmes très intéressants en très peu d'instructions. Moins qu'aucune autre machine depuis. Je crois par exemple que le célèbre haché d'affichage « munching squares » (lit. : grignotage de carrés) qui faisait que des carrés grandissaient puis se brisaient en une multitude de petits carrés qui devenaient plus grands et se cassaient 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 en peu d'instructions.

C'était le laboratoire d'I.A. Mais c'était quoi la culture des hackers hormis leur anarchisme ? Dans les temps du PDP-1 une seule personne pouvait utiliser la machine, du moins au début. Plusieurs années après ils ont écrit un système de répartition du temps et ils ont rajouté pas mal de matériel pour ça. Mais au début, vous pouviez seulement vous enregistrer pour une période donnée. Naturellement les professeurs et les étudiants qui travaillaient sur des projets officiels venaient toujours pendant la journée. Ainsi, les gens qui voulaient avoir plus de temps s'enregistraient la nuit quand il y avait moins d'affluence et ce fut la coutume des hackers de travailler la nuit. Même lorsqu'il y avait le répartiteur de temps, il était toujours plus facile d'en avoir, vous pouviez obtenir plus de cycles la nuit parce qu'il y avait peu d'utilisateurs. Aussi ceux qui désiraient effectuer un volume de travail plus important devaient venir la nuit. Mais ça a commencé à changer parce que vous n'étiez pas seul, il y avait quelques autres hackers ici et là et 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 celle d'aller chercher de la nourriture chinoise à trois heure du matin. Et j'ai beaucoup de souvenirs de levers de soleil depuis la voiture en revenant de Chinatown. C'était tellement beau de voir le lever du soleil, c'est une heure tellement calme du jour. C'est une heure merveilleuse pour aller au lit. Il est si doux de marcher vers sa maison dans une lumière qui commence juste à poindre et les oiseaux qui commencent à gazouiller. Vous aviez une sensation de douce satisfaction, de tranquillité pour le travail que vous avez fait la nuit.

Une autre tradition que nous avons commencée était celle d'avoir des endroits où dormir au laboratoire. Depuis que j'y étais venu la première fois, il y avait toujours au moins un lit. Et j'y passais un peu plus de temps que la plupart des autres parce que chaque année, pour une raison ou une autre, je n'avais pas d'appartement et j'y vivais quelques mois. Et je l'ai toujours trouvé très confortable et sympa et frais en été. Mais il n'était pas du tout rare de tomber sur des personnes endormies au laboratoire, toujours à cause de leur enthousiasme : vous restez le plus longtemps possible à hacker parce que vous ne vouliez pas vous arrêter, et une fois que vous êtiez complètement épuisé, vous escaladiez la surface horizontale souple la plus proche. Une ambiance vraiment sans cérémonie.

Mais quand les hackers sont partis du laboratoire, ç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'avant ; ils représentaient la majorité. Et ils ont vraiment eu peur. Sans hacker pour maintenir le système, ils se sont dit : « Ça va être un désastre, il nous faut un logiciel commercial », et ils se sont dit « Comme ça, nous pourrons compter sur la maintenance de l'entreprise ». Il fut prouvé qu'ils avaient absolument tort, mais c'est ce qu'ils ont fait. Ce fut exactement au moment où un nouveau système KL-10 était sensé arriver et la question fut d'utiliser le Système de répartition du temps incompatible ou le système numérique de Twenex. Une fois les hackers partis - qui auraient sans doute encouragé à utiliser le leur - les universitaires ont choisi d'utiliser le logiciel commercial, et ça eu plusieurs effets immédiats. Certains n'ont pas été vraiment immédiats mais ils ont inévitablement suivi comme n'importe qui d'averti l'aurait vu.

La première chose fut que ce logiciel était très mal écrit et dur à comprendre ; rendant donc plus durs les changements nécessaires. Une autre fut que le logiciel était sécurisé, ce qui a eu pour effet inévitable de diminuer la collaboration entre les uns et les autres. Dans le passé, sur ITS, on trouvait bénéfique le fait d'avoir accès à tous les fichiers et de pouvoir changer 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'aide en utilisant Macsyma. Macsyma est un programme symbolique d'algèbre qui a été développé au M.I.T.. Il a envoyé une demande d'aide à 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 a été horrifié. Il a envoyé le message : « Untel ou 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. Quel est le problème ? Vous avez obtenu votre réponse plus tôt, pourquoi en êtes-vous chagriné ? É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 savent pas qu'elles sont riches.

Mais naturellement Twenex n'était 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 choses très faciles à faire qui peuvent causer des dommages et la seule chose qui vous empêche de les faire par accident c'est la sécurité. Sur ITS, nous avions développé des moyens supplémentaires pour éviter que les gens fassent des erreurs par accident, mais sur Twenex vous ne les aviez pas étant donné qu'il était supposé y avoir une sécurité totale dans les résultats et que seulement les chefs avaient la possibilité de faire des erreurs. Ainsi ils n'ont mis de sécurité dans aucun des mécanismes. Le résultat, c'est que vous ne pouviez plus enlever la sécurité et avoir ce que vous vouliez vraiment avoir. Et il n'y avait plus de hackers pour faire les changements nécessaires dans les mécanismes. Aussi les gens ont été obligés de travailler avec la sécurité. Et environ six mois après que la machine soit arrivée, il a commencé à y avoir quelques « coups d'état ». C'est-à-dire, d'abord nous avons émis l'hypothèse que tous ceux qui travaillaient pour le laboratoire allaient avoir un bout de gouvernail donnant les pleins pouvoirs et la priorité sur les mesures de sécurité, mais il a suffit de venir quelques après-midi pour découvrir que le bout de gouvernail d'à peu près tout le monde avait été supprimé.

Quand je m'en suis rendu compte, j'ai tout renversé. Dans un premier temps, j'ai fini par connaître le mot de passe d'une des personnes qui faisait partie de l'élite et j'ai pu l'utiliser pour renvoyer tout le monde dessus. Dans un deuxième temps, il a changé son mot de passe et ensuite changé de relations. Il faisait maintenant partie de l'aristocratie. Alors j'ai dû faire baisser le régime de la machine et utiliser le temps non-partagé DDT 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 rendre les pleins pouvoirs au groupe entier. 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 - La radio Libre d'OZ ». Plus tard j'ai découvert que « la Radio Libre d'Oz » est l'une des expressions utilisées par Firesign Theater. Je ne le savais pas à ce moment-là.

Mais graduellement les choses ont empiré, à cause de la façon dont le système avait été construit qui forcait les gens à demander 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 laboratoire d'I.A. du M.I.T., j'en étais venu à la conclusion que pour respecter ma croyance, pour suivre ma croyance, il ne devait y avoir aucun mot de passe. Je devais toujours veiller à avoir un mot de passe aussi évident que possible et le dire à tout le monde. Parce que je ne crois pas qu'il soit vraiment souhaitable d'avoir une sécurité sur un ordinateur, je ne devrais pas aider au maintien du régime de sécurité. Sur les systèmes qui me permettent d'utiliser 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 ailleurs, des choses comme ça, j'utilise mon login en tant que mot de passe. Il est évident que vous pouvez l'obtenir. Et quand les gens précisent que de cette manière on peut ouvrir une session en mon nom, je réponds « Oui, c'est une idée, quelqu'un pourrait avoir besoin de quelques données sur cette machine. Je veux m'assurer qu'elles ne sont pas verrouillées par la sécurité ».

Et une autre chose que je fais toujours, c'est 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'a pas non plus été conçue pour défendre le phénomène appelé « tourisme ». Le « tourisme » est une très vieille tradition du laboratoire d'I.A. qui allait dans le sens de nos autres conceptions de l'anarchie et qui était que nous devions laisser les gens de l'extérieur utiliser la machine. À l'époque où quiconque pouvait marcher jusqu'à elle et se connecter à ce qui lui plaisait, c'était automatique : si vous veniez pour visiter, vous pouviez ouvrir une session et travailler. Plus tard nous avons plus ou moins formalisé ça comme une tradition admise, particulièrement quand l'Arpanet a commencé et que les gens ont commencé à se relier à nos machines à partir de n'importe quel coin du pays. Maintenant ce que nous espérions, c'était que ces personnes apprendraient réellement à programmer et qu'elles commenceraient à modifier le logiciel d'exploitation. Quand vous dites ça à un directeur système n'importe où ailleurs, il en serait horrifié. Si vous lui proposez l'idée que n'importe quel étranger puisse utiliser la machine, il dirait « Mais s'il commence à modifier nos programmes ? ». Mais pour nous, si un étranger commence à modifier les programmes, cela signifie qu'il montre un vrai intérêt en devenant un membre contributif de la communauté. Nous encouragions toujours les gens à le faire. À commencer naturellement par écrire de nouveaux utilitaires, des petits, et nous jetions un œil sur ce qu'ils avaient fait et nous les corrigions. Ils en arrivaient alors à ajouter des dispositifs à de grands utilitaires existants. Et ce sont des programmes qui ont existé pendant une dizaine ou peut-être une quinzaine d'années, grandissant petit à petit, un artisan après l'autre, auquels s'ajoutaient de nouveaux dispositifs supplémentaires.

Comme dans certaines villes de France on pourrait dire, où vous pouvez voir des bâtiments extrêmement vieux avec des rajouts, faits des centaines d'années après, dans tous les styles jusqu'à aujourd'hui. Dans le domaine de l'informatique, un programme qui a été commencé en 1965 c'est exactement ça. Ainsi nous espérions toujours que des touristes entretiennent le système et peut-être allaient-ils être embauchés après avoir déjà commencé à travailler sur les programmes et nous avoir montré qu'ils étaient capables de faire du bon travail.

Mais il y avait sur les machines ITS certains 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 tout le monde faisait. Et naturellement les touristes ont aimé espionner. Ils pensaient que c'était une chose ingénieuse. C'est un peu méchant vous voyez mais le résultat est que si un touriste commence à faire n'importe quoi qui cause problème, il y a toujours quelqu'un pour le voir. Assez vite ses amis allaient en être furieux parce qu'ils savaient que le tourisme continue à exister, il fallait des touristes responsables. Aussi il y avait forcément quelqu'un qui savait qui c'était et nous étions en mesure de lui dire de nous laisser tranquilles. Et si nous ne pouvions pas, alors ce que nous avions à faire était de fermer entièrement l'accès à certains endroits pendant un moment, et quand nous le réouvriions, 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 de 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 les sessions en 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; tellement que finalement j'ai abandonné et cessé à tout jamais de le réactiver. C'était comme ça. Je ne m'étais pas connecté sur cette machine en tant que moi… [ à ce moment-là, RMS est interrompu par des applaudissements énormes ]… pour ça.

Quand ils eurent le système Twenex pour la première fois, ils avaient à l'esprit d'y faire plusieurs changements. Ceux opérés dans le domaine de la sécurité ont fonctionné. Ils ont aussi voulu avoir la machine sur le réseau d'ARPA et sur celui du M.I.T. Chaos en même temps. Et il s'avère 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 c'était trop difficile. Ce système était beaucoup plus dur à comprendre parce qu'on l'avait mal écrit et naturellement Digital ne voulait pas faire ce genre de choses. Ainsi l'idée d'un système commercial qui se maintenait tout seul s'est révélé être une erreur. Ils avaient absolument besoin de hacker le système. Mais ils n'avaient plus les moyens d'attirer les hackers. Et de nos jours au M.I.T., il y a plus de gens intéressés à hacker ITS que Twenex.

Et la raison, 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 de façon assez agressive et ça leur donne mauvais goût. À moins que la personne soit inconsciente. Comme le sont certains en informatique ; il y en a qui feraient n'importe quoi si c'est drôle 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, c'est une autre façon de décourager. 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 le système de programmation scolaire du genre « million de singes dactylographiant qui finiront bien par apporter quelque chose d'utile ».

Il m'apparût clair, d'après ce que j'avais vu advenir de ces systèmes propriétaires que la seule façon de conserver l'esprit du vieux labo d'I.A. était d'avoir un logiciel d'exploitation libre. D'avoir un système formé par du logiciel libre pouvant être partagé avec n'importe qui. De façon à pouvoir inviter tout le monde à s'associer pour l'améliorer. Et c'est ce qui a conduit au projet GNU. Ainsi j'estime que nous sommes arrivés à la deuxième partie de l'entretien.

Environ trois ans et demi auparavant, il était devenu clair pour moi que je devais commencer à développer un système de logiciel libre. Je pouvais voir deux genres de systèmes se développer : le premier, un système qui ressemblait à celui des machines LISP, un système essentiellement comme celui qui venait d'être développé sur les machines LISP du M.I.T. mais libre et fonctionnant sur tout type de matériel, pas seulement sur les machines LISP spécialisées. Et l'autre système possible était 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 alentours. Peu de temps plus tard, j'en ai conclu que c'était ce qu'il fallait faire. Et la raison, c'était qu'il n'était pas vraiment possible d'obtenir quelque chose d'identique au système des machines LISP sur tout type de matériel. Le système des machines LISP utilise du matériel spécial, plus un microcode à affichage spécial pour gagner une bonne vitesse d'exécution et une détection solide 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, vous devez commencer par faire des suppositions. En supposant que tel argument est le bon. Et si ce n'est pas le cas, vous obtenez le plantage du système.

Naturellement vous pouvez y placer des contrôles explicites, vous pouvez écrire un programme solide si vous voulez, mais le fait est que vous allez obtenir des choses comme des erreurs d'adressage de mémoire lorsque vous alimentez une fonction, un argument de type inapproprié si vous n'aviez pas prévu d'y placer des éléments à contrôler pour ça.

Le résultat, c'est qu'il fallait que quelque chose fonctionne en dessous du système LISP pour percevoir ces erreurs, donner à l'utilisateur la possibilité de maintenir le fonctionnement et de déboguer les problèmes qui étaient survenus. Enfin j'en ai conclu que si je devais avoir à plus bas niveau un logiciel d'exploitation, je pouvais tout aussi bien faire un bon système d'exploitation -- c'était un choix entre un système d'exploitation et le LISP ou juste un système d'exploitation ; donc je devais faire le logiciel 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 que je devais faire était clair. Et ce mot est bien-sûr GNU, qui signifie « GNU is Not UNIX »". L'acronyme récursif est une très vieille tradition dans la communauté des hackers aux environs du M.I.T. 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 c'était arrivé à GNU.

Je dirais qu'environ deux ans et demi avant de commencer réellement à travailler sur GNU, j'avais 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 portatif intéressant de compilateur appelé « le kit compilateur libre universitaire » et j'ai pensé qu'avec un nom comme ça, je pouvais peut-être l'avoir. Ainsi, j'ai envoyé un message à la personne qui l'avait développé 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'ils développent ne l'est pas », mais aussi qu'il voulait avoir un système compatible avec UNIX et qu'il a voulu écrire une sorte de noyau pour lui, alors pourquoi je n'écrirais pas les utilitaires, comme ça les deux pourraient être distribués avec son compilateur propriétaire et ça encouragerait les gens à l'acheter. J'ai pensé que c'était ignoble alors je lui ai dit que mon premier projet sera de faire un compilateur.

Je ne savais pas vraiment grand-chose au sujet des compilateurs de linéarisation parce que je n'avais jamais travaillé dessus. Mais j'ai mis les mains dedans. Et celui dont on m'avait parlé était libre. C'était un compilateur appelé PASTEL dont les auteurs disaient que c'était du « PASCAL mal fichu ».

Le Pastel était un langage très compliqué comprenant des dispositifs comme des caractères paramétrisés et des caractères paramètres explicites et beaucoup de choses compliquées. Le compilateur naturellement a été écrit dans ce langage et comportait nombre de dispositifs compliqués pour optimiser l'utilisation de ces éléments. Par exemple : le caractère « string » dans ce langage était un caractère paramétrisé; vous pouviez dire le « 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'elles devaient avoir beaucoup de fonctions pour détecter des choses comme quand la longueur déclarée d'une chaîne est un argument connu pour être constant dans toute la fonction, quand il s'agit de sauvegarder la valeur et d'optimiser le code qu'elles vont 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 manipuler différents types de machines.

Bon, ce compilateur ayant déjà compilé PASTEL, j'avais à rajouter une entrée pour le C ; ce que je fis. Puis d'ajouter un arrière-plan pour la 68000 qui devait être ma première machine 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. Les déclarations et utilitaires pouvaient être dans n'importe quel ordre ; en d'autres termes : la déclaration « forward » du Pascal était obsolète. Pour cette raison il était nécessaire d'emmagaziner le programme dans son entier, de le garder dans le noyau et de l'appliquer d'un trait. Le résultat, c'était que le stockage intermédiaire utilisé dans le compilateur, la taille de la mémoire requise, étaient proportionnels à la taille de votre fichier. Et cela incluait aussi l'espace de pile ; vous aviez besoin d'une quantité gigantesque d'espace de pile, et j'en ai conclu que le système 68000 dont je disposais ne pouvait pas faire fonctionner le compilateur. Car c'était une horrible version d'Unix qui vous limitait à quelque chose comme 16K de mots de pile, ceci en dépit de l'existence de six méga-octets dans la machine. Et naturellement pour générer la matrice des conflits pour voir quelles valeurs temporaires étaient en conflit ou actives en même temps que les autres, 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. Aussi je suis parvenu à corriger la première des quelque dix passes du compilateur en compilation croisée sur cette machine et j'ai constaté alors que la seconde ne pourrait jamais fonctionner.

Pendant que je réfléchissais à ces problèmes en me demandant si je devais essayer de les corriger ou bien d'é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 pour son extension de langage. Le rédacteur lui-même est implémenté en C de même que l'interpréteur LISP. Ainsi l'interpréteur LISP est entièrement portatif et vous n'avez pas besoin de système LISP externe au rédacteur. Le rédacteur 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 d'édition et des éléments pour débuter avec. Ainsi vous pouvez les changer pour les commandes d'édition que vous voulez vraiment.

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 Gosling Emacs, il a eu 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 posant un copyright dessus, en faisant promettre aux gens de ne pas le redistribuer puis en le vendant à une maison d'édition de logiciels. Les rapports d'affaires que j'ai eu avec lui par la suite m'ont personnellement prouvé qu'il était aussi lâche et ignoble 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 à un 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 et tout ce que l'on pouvait s'attendre à ce qu'elles manipulent, en étant pourvues de tous les dispositifs que je voulais. Mais peu après, j'ai découvert que le langage d'extension de ce rédacteur, 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'abord. Maintenant, la raison pour laquelle MOCKLISP s'appelle MOCK (FAUX), c'est qu'il n'y a aucun type de structure des données : il n'y a pas de listes LISP ; il n'y a aucun type de tableau. Il n'y a également pas de symboles LISP, qui sont des objets nommés : à chaque nom particulier est attribué un seul objet de manière à ce que la saisie du nom se rapporte toujours au même objet. Sinon, ça entrave considérablement l'écriture de pas mal de types de programmes, en vous obligeant à passer par des manipulations alphanumériques compliquées qui ne vont pas vraiment dans ce sens.

Alors j'ai écrit un interpréteur de LISP pour le mettre à la place de MOCKLISP. Et pendant le processus, 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. J'ai voulu que l'interface entre le LISP et l'éditeur soit propre. C'est à dire que les objets comme les tampons, les sous-programmes, les fenêtres et les zones tampon de l'éditeur soient tous des objets LISP. Pour que les instructions de l'éditeur qui leur étaient affectées soient réellement attribuables en tant que fonctions LISP avec des données LISP. Cela voulait dire qu'il fallait reconcevoir les formats de données de tous les objets et réécrire toutes les fonctions qui leur étaient affectées. 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, parce qu'il est vraiment difficile d'écrire dans MOCKLISP, tout ce qui avait été écrit était très imparfait. 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. Alors je l'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à, l'entreprise à qui Gosling pensait avoir vendu le programme a contesté à mon ami le droit de le distribuer. Le message était alors enregistré sur des bandes qu'il ne pouvait pas trouver. Malgré tout, Gosling a nié lui avoir donné la permission. Une chose étrange s'est alors produite. Il était en pourparlers avec cette compagnie qui semblait principalement concernée par le fait qu'il avait distribué quelque chose de similaire à ce qu'elle distribuait. En gros, Gosling distribuait ce que la compagnie, Megatest, où il avait travaillé, distribuait aussi. C'est-à-dire ce qu'il m'avait donné; en réalité une de ses anciennes versions d'Emacs modifiée. Il allait donc passer un accord avec eux dans lequel il cessait de le distribuer. Ils voulaient ensuite passer à GNU Emacs, en reconnaissant à Gosling la permission de le faire après tout et donc théoriquement tout le monde était content. Alors cette entreprise m'a entretenu au sujet de leur désir de distribuer GNU Emacs, librement bien-sûr, mais aussi de vendre divers types de supports d'aide. Et ils ont voulu louer mes compétences pour aider à faire ce travail. Aussi, il est un peu étrange qu'ils aient soudain changé d'avis et refusé de signer cet accord, en mettant un message d'annonce sur le réseau comme quoi on ne m'avait pas donné le droit de distribuer le programme. Ils n'ont pas réellement dit qu'ils feraient quelque chose. 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 encore sous secret commercial et de commencer à en distribuer des copies à tous les coins de rue en les faisant sortir du secret commercial. Ça serait peut-être une manière beaucoup plus efficace pour moi de fournir aux gens du nouveau logiciel libre plutôt qu'en l'écrivant réellement moi-même ; mais tout le monde serait trop lâche pour le prendre quand même.)

Ça m'a obligé à réécrire tout ce qui restait qui n'était pas de moi, et je l'ai fait. Il m'a fallu environ une semaine et demie. Ainsi ils ont gagné une grande victoire! Il était certain que je ne coopérerais jamais plus avec eux en aucune manière après ça.

Après que GNU Emacs soit devenu raisonnablement stable - ce qui m'a pris environ un an et demi à tout prendre - 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 un débogueur en code C symbolique récemment entré dans la distribution. Réalisé en grande partie dans l'esprit de DBX qui est 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. Et les commandes communes sont des abréviations à caractère unique, sachant que toute abréviation à caractère unique est permise. Il y a aussi des aménagements considérables pour HELP. Vous pouvez taper HELP suivi de toutes les commandes ou même 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 il en imprimera la valeur.

Vous pouvez également faire des choses inhabituelles pour un débogueur C symbolique, par exemple : vous pouvez faire référer n'importe quel type de donnée de C à n'importe quelle adresse de mémoire pour en étudier la valeur ou pour l'attribuer. Par exemple si vous voulez stocker une valeur de virgule flottante dans un mot à une certaine adresse, vous devez juste dire : « Donnez-moi l'objet du type FLOAT ou DOUBLE à cette adresse et attribuez-le ». Une autre chose que vous pouvez faire est d'étudier toutes les valeurs qui ont été étudiées auparavant. Chaque valeur étudiée est placée au dessus de l'« historique des valeurs ». Vous pouvez vous référer à n'importe quel élément par sa position dans l'historique. Ou vous pouvez facilement vous référer au dernier élément juste avec le signe dollar. Et ça facilite le suivi de la structure des listes. Pour n'importe quel genre de structure de C qui contient un pointeur vers une autre structure, vous pouvez faire quelque chose comme « PRINT*$.next » qui dit : « Sortez le prochain champ de la dernière chose que vous m'avez montré et ensuite affichez la structure sur laquelle il pointe ». En répétant cette commande, vous voyez chaque fois la prochaine structure de la liste, sachant que dans chacun des débogueurs C que j'ai vus, la seule manière de le faire est de taper une commande chaque fois plus longue. Et quand c'est combiné à un retour-chariot tapé juste après la dernière commande donnée, ça devient très pratique. Vous avez juste à taper retour-chariot pour chaque élément de la liste que vous voulez voir.

Vous pouvez aussi poser des variables de façon explicite dans le débogueur, en n'importe quel nombre. Vous posez le signe dollar suivi d'un nom et c'est une variable. Vous pouvez attribuer les valeurs de ces variables à n'importe quel type de données de C et vous pourrez les étudier plus tard. Parmi les choses pour lesquelles c'est utile, s'il y a une valeur particulière que vous voulez étudier, 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 les utiliser quand vous placez des paliers conditionnels. Les paliers conditionnels sont un dispositif qui existe dans beaucoup de débogueurs symboliques. Vous dites : « Arrêtez-vous quand vous serez arrivés à ce point du programme, mais seulement si une certaine expression est vraie ». Les variables dans le 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 de compter. Parce qu'après tout, les allocations sont des expressions en C, donc on peut faire : « $foo+=5 » pour incrémenter la valeur « $foo » de cinq ou juste « $foo++ ». Vous pouvez également le faire lors d'un palier conditionnel. Une manière économe de le voir s'arrêter 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, arrêt. Vous faites démarrer $foo au nombre de fois 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 avez un tableau de pointeurs, vous pouvez faire :

Ok, quand vous faites ça [des points à 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 une astérisque là [avant le X dans l'expression « Print »] et chaque fois qu'elle affiche la prochaine structure pointée par l'élément du tableau. Et bien-sûr vous pouvez répéter cette commande en tapant retour-chariot. Si une chose simple à répéter ne suffit pas, vous pouvez créer une commande définie par l'utilisateur. Vous pouvez dire « Définissez Mumble », vous donnez quelques lignes de commandes et vous dites « end ». Il y a maintenant une commande « Mumble » définie qui exécutera ces lignes. Et il est très utile de mettre ces définitions dans un fichier de commande. Vous pouvez avoir un fichier de commande dans chaque répertoire qui sera chargé automatiquement lorsque vous mettez en marche le débogueur avec ça en tant que répertoire actif. Ainsi pour chaque programme, vous pouvez définir un ensemble de commandes sur mesure pour accéder aux structures de données de façon utile. Vous pouvez même fournir de la documentation pour vos commandes, de façon à ce qu'elles soient traitées dans les aménagements de « help » comme des commandes intégrées.

Une autre chose peu habituelle dans ce débogueur, c'est la capacité d'écarter les trames de la pile. Parce que je crois que c'est non seulement important 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 su ce qui n'allait pas, vous pouvez arranger les choses 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 secteurs 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 :

Et vous pouvez placer le compteur. Vous pouvez également placer l'indicateur de pile, ou vous pouvez dire :

Ceci si vous voulez incrémenter l'indicateur de pile d'une certaine quantité. Mais en outre, vous pouvez également le dire pour démarrer sur une ligne particulière du programme ; vous pouvez placer le compteur à 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 vous faites à la main ce que cette fonction devait faire. Pour cela, vous pouvez utiliser la commande « RETURN ». Vous sélectionnez une trame de la pile et vous dites « RETURN ». Et ça va faire que la trame de la pile comme toutes celles qui vont avec, seront abandonnées comme si cette fonction revenait instantanément en arrière. Vous pouvez aussi spécifier la valeur à laquelle vous voulez qu'elle revienne. Ça ne prolonge pas l'exécution ; ça simule le retour et stoppe à nouveau le programme ; vous pouvez ainsi continuer de modifier autre chose.

Avec toutes ces choses réunies, vous avez donc un excellent contrôle sur ce qu'il se passe dans un programme.

En outre, une chose assez amusante : C a des constantes de chaîne. Que se passe t-il si vous utilisez une constante de chaîne dans une expression que vous calculez dans le débogueur ? Il doit créer une chaîne dans le programme que vous déboguez. Alors il le fait. Il crée un appel à MALLOC dans le programme débogué, laisse MALLOC fonctionner et récupère le contrôle. Ainsi il trouve de façon invisible un endroit pour placer la constante de chaîne.

Quand le débogueur a finalement fonctionné sur le vrai système GNU, j'avais l'intention d'y installer des aménagements pour examiner l'ensemble des états internes du processus tournant en dessous de lui. Par exemple pour examiner l'état de la carte mémoire, pour savoir quelles pages existent, si elles sont lisibles, inscriptibles et pour examiner l'état inférieur du terminal du programme. Il y a déjà l'ébauche d'une commande ; ce débogueur, à la différence des débogueurs sous UNIX, maintient 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 des programmes qui tournent en mode brut, avec ceux qui font des interruptions d'entrées dynamiques ; et il y a également une commande qui vous permet d'apprendre quelque chose sur les positionnements des terminaux que le programme que vous déboguez utilise réellement. Je crois qu'en général un débogueur devrait vous permettre de découvrir tout qu'il 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 écrit le nouveau compilateur C cette année, depuis le printemps dernier. J'ai finalement décidé que je devais me passer du PASTEL. Ce compilateur utilise quelques idées du PASTEL et quelques idées de l'optimiseur portatif de l'université d'Arizona. Ce qu'ils avaient d'intéressant, c'était de manipuler plusieurs types différents de machines par des instructions simples et de là, combiner plusieurs instructions simples dans une seule instruction compliquée quand la machine cible le permettait. Pour que cela reste uniforme, ils représentaient les instructions en notation algébrique. Par exemple, l'instruction ADD pourrait être représentée comme ceci :

C'était une représentation interne à leur compilateur de l'instruction de : prendre le contenu du registre n°2, d'y ajouter 4 et de le stocker dans le registre n°3. De cette façon vous pouviez représenter n'importe quelle instruction pour n'importe quelle machine. Ils représentaient réellement toutes les instructions comme ça et quand est venu le temps d'essayer de les combiner, ils l'ont fait en substituant une expression dans une autre, donnant une expression algébrique plus compliquée à l'instruction combinée.

Cela dépendait parfois si le résultat de la première instruction avait une utilité quelconque ou pas mais il pouvait être nécessaire de faire une instruction combinée avec deux opérateurs d'assignement. Un pour la valeur [pointer sur ???] et un autre pour cette valeur [pointer sur ???] à l'intérieur de laquelle était substitué ce qui provenait de la deuxième instruction. Si cette valeur n'était utilisée qu'une fois, vous pouviez l'éliminer après l'avoir substituée ; il n'était plus nécessaire de calculer. Donc c'est réellement assez difficile de faire ces substitutions correctement, en vérifiant bien que les instructions qui interviennent ne vont changer aucune de ces valeurs ni rien d'autre du même genre. Quand vous devez permettre des choses comme l'utilisation de l'auto-incrémentation et l'adressage de l'auto-décrémentation, ce que je fais maintenant, vous avez diverses vérifications à faire à leur sujet dans les situations où votre objectif n'est pas de conserver de valeur.

Mais après avoir vérifié tout ça, vous prenez l'expression combinée substituée et vous la placez à travers un correspondeur de combinaison, qui reconnaît toutes les instructions valides de la machine cible que vous avez choisie. Quand c'est identifié, vous remplacez les deux instructions par leur instruction combinée, sinon vous les laissez seules. Leur technique est de combiner deux ou trois instructions liées en flux de données dans ce but.

Dans le compilateur d'Arizona, ils représentent vraiment les choses avec des chaînes de texte comme celles-là, et leur compilateur est terriblement lent. Au début j'avais l'idée d'utiliser leur compilateur 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, aussi je l'ai fait pour pouvoir utiliser des représentations de structure de liste pour toutes ces expressions. Des choses comme ceci :

Ça ressemble un peu au 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. De tous ceux dont vous avez besoin. Chacun ayant une combinaison particulière de types d'arguments, par exemple : « reg » a 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 va également un type de données qui pour l'essentiel indique s'il est fixe ou flottant et sa longueur en octets. Ça peut être élargi pour manipuler d'autres choses si vous en avez besoin.

Et la façon dont j'attribue automatiquement le registre, c'est qu'au moment où je génère initialement le code, quand je fais la combinaison puis le reste à toute variable qui entre théoriquement dans un registre, j'assigne ce que j'appelle un pseudo-nombre de registre. Un nombre qui commence à seize, ou tout ce qui pourrait être trop élevé pour un vrai registre de votre machine cible. Les vrais registres étant numérotés de zéro à quinze ou toute séquence au-dessus de laquelle viennent les pseudo-registres. Et là, une des dernières parties du compilateur consiste à intervenir et à changer tous les pseudo-registres en vrais registres. À nouveau, il fait un schéma des conflits, il voit quels pseudo-registres sont vivants au même point. Et comme ils ne peuvent naturellement pas entrer dans le même vrai registre, il essaye de regrouper les pseudo-registres dans de vrais registres autant qu'il peut, en les rangeant par ordre d'importance.

Et à la fin, il doit corriger le code pour les différents problèmes; comme celui des pseudo-registres qui ne s'adaptaient pas aux vrais registres et qui devaient être mis à la place dans des slots de pile. Quand ça arrive sur certaines machines, des instructions peuvent devenir invalides. Par exemple sur la 68000, on peut ajouter un registre dans la mémoire et ajouter de la mémoire dans un registre mais pas ajouter une adresse mémoire dans une autre. Aussi, si lors d'une instruction ADD vous allez vers des 68000 et que les deux éléments arrivent ensemble dans la mémoire, ce n'est pas valide. Donc ce passage final intervient et des éléments sont copiés dans et en dehors des registres, comme c'est nécessaire pour corriger ce genre de problème.

Les problèmes peuvent également surgir avec les registres d'index. Si vous essayez d'indexer par quelque chose, la plupart du temps le code deviendra invalide si la quantité d'index est dans la mémoire. Excepté dans quelques cas sur quelques machines où vous pouvez le faire avec un adressage indirect. Lorsque vous procédez à une auto-incrémentation sur un registre d'index, vous pouvez avoir à copier la valeur dans un registre, opérer l'instruction et de là copier la valeur incrémentée en amont du slot de mémoire où elle vit vraiment.

Il y a de la place pour beaucoup d'optimisation et je n'ai pas fini de mettre en œuvre tout ce qui est nécessaire pour le rendre vraiment pleinement efficace.

Ce compilateur fonctionne actuellement avec un analyseur syntaxique qui transforme en réalité le code C en arbre syntaxique, annoté d'informations en types de données C. Alors 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 des sauts à travers des sauts, des sauts de sauts, des sauts de +1 et tout ce qui peut être immédiatement simplifié. Puis un système de reconnaissance des sous-expressions courantes trouve alors les blocs de base et effectue l'analyse du flux des données afin de pouvoir indiquer pour chaque instruction quelles valeurs sont utilisées dans l'instruction et nulle part ailleurs. Et qui lie aussi chaque instruction aux endroits où les valeurs utilisées ont été créées. Donc si 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 lieu pour utiliser 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'attributeur dynamique de registre et enfin quelque chose pour le convertir en code assembleur.

Dans le compilateur d'Arizona, le système de reconnaissance d'instruction a été créé avec LEX. La description de votre machine était simplement un programme LEX, que LEX transformait en fonction de C pour identifier les instructions valides comme les chaînes. À la place, j'ai un arbre de décision à usage spécial, créé à partir d'une description de machine écrite dans cette syntaxe comme si c'était du 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 une attribution de registre limite. Dans ce cas elle assigne des 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 j'observe que pour VAX, il produit le meilleur code que j'ai vu de tous les compilateurs C sur VAX.

Pour les 68000 le code n'est pas toujours idéal. Je peux voir par endroits, aux étapes antérieures, se passer des choses qui ne sont pas forcément les meilleures parce qu'il ne peut pas anticiper vraiment. Il a un choix à faire à une étape antérieure et il fait ce qu'il pense être le mieux. Or s'il avait fait l'autre choix, une étape ultérieure aurait été assez intelligente pour faire encore mieux. Mais l'étape antérieure ne sait pas ce que l'étape ultérieure va faire, donc je dois travailler davantage sur ce genre de choses.

Parfois ça provoque le fait de libérer des registres inutilement. Étant donné que quand les choses finissent dans la mémoire, il a besoin de les copier dans des registres. Et il lui faut des registres pour ça. C'est-à-dire prendre des registres déjà assignés et virer les quantités provisoires des slots de pile. Évidemment, maintenant que ces choses sont dans la mémoire, ça peut invalider davantage d'instructions. Pas les registres. Donc il lui faut tout le temps vérifier. Parfois il pense à tort qu'il devrait copier les choses dans les registres, alors il peut en libérer trop et ne pas utiliser tous les registres qu'il pourrait.

Pas encore, mais à nouveau ce n'est pas un générateur de code dont vous avez besoin, juste d'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 de mettre en œuvre l'idée de contraintes sur les arguments - lesquels pourront être dans des registres et dans quel genre de registres - nécessaires pour les 68000 mais pas pour le VAX, le travail de portage de ce compilateur de VAX aux 68000 a juste pris quelques jours. Donc il est très facile à transférer.

Le compilateur produit actuellement du code assembleur. Et il peut produire de l'information de débogage soit dans le format que DBX veut, soit dans le format interne spécial à GDB. Je dirais que le seul travail à faire sur ce compilateur se situe à trois niveaux.

Ah, ouais je devine que nous avons oublié les coupures. Pourquoi je ne finirai pas de parler du noyau ? Ce qui devrait prendre environ cinq minutes seulement, et ensuite nous pourrons faire une coupure.

Maintenant pour le noyau, je projette d'utiliser un système appelé TRIX (il ne ressemble à rien de ce que je connais) qui a été développé comme projet de recherche au M.I.T. Ce système est basé sur le Remote Procedure Call - Appel de Procédure à Distance. 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és » 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 d'utilisateur. En fait vous ne pouvez pas dire lequel vous avez. Ainsi il est très facile d'avoir des dispositifs mis en œuvre par d'autres programmes utilisateur. Un système de fichiers pourrait l'être de façon transparente. 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 de réseau. Il prend l'information que vous avez donnée dans l'appel et la passe au-dessus du réseau à un autre programme du serveur qui appelle alors le domaine auquel vous essayez de parler. Mais pour vous et cet autre domaine, cela se passe de manière invisible.

Le noyau TRIX fonctionne et il a une certaine quantité limitée de compatibilités UNIX, mais il lui en faut beaucoup plus. Actuellement son système de fichiers utilise la même structure sur disque que l'antique 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 fonctionalités nécessaires d'après moi.

Les fonctionalités qui devraient être rajoutées d'après moi incluent : les numéros de version, la restauration, les informations sur quand, comment et où le dossier a été sauvegardé sur bande, le remplacement nucléaire des fichiers. Je crois qu'il est bon dans UNIX, lorsqu'un fichier est écrit, que vous puissiez déjà regarder ce qu'il se passe. Ainsi par exemple, vous pouvez utiliser « tail » pour voir où ça en est, c'est vraiment bien. Et si le programme échoue après avoir écrit le fichier partiellement, vous pouvez voir ce qu'il a fait. Toutes ces choses sont bonnes, mais le résultat partiellement écrit ne devrait jamais être considéré comme le résultat final escompté. La version précédente devrait 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 devrait être renommée quand c'est fini. C'est d'ailleurs ce qui se passe dans ITS, bien que chaque programme utilisateur doive le faire de façon explicite. Pour la compatibilité d'UNIX avec les programmes utilisateurs, ça doit se passer de façon invisible.

C'est un arrangement bizarrement effrayant d'essayer de faire coïncider les numéros de versions avec les programmes utilisateur présents sous UNIX. Il s'agit de l'idée 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 par la suite une nouvelle version de « FOO », mais si vous dites « FOO. », ça va écrire un fichier nommé exactement « FOO ».

Maintenant c'est un défi compliqué de mettre au point tous ces détails et de voir s'il y a des problèmes persistants, si vraiment certains logiciels UNIX échouent malgré le fait d'avoir fourni des noms avec des points et ainsi de suite, pour tenter de lui faire avoir le même comportement.

Je m'attends à ce que lorsque vous sortez un fichier dont le nom finit par un point, vous l'ouvrez en fait avec ce nom tout de suite et vous obtenez le même comportement qu'UNIX : le résultat partiellement écrit est immédiatement visible. Tandis que quand vous le sortez avec un nom qui ne finit pas par un point, la nouvelle version ne devrait apparaître que quand vous le fermez et seulement si vous le fermez explicitement. S'il a été fermé parce que le travail a échoué ou à cause du plantage du système ou de n'importe quoi du genre, il devrait être sous un nom différent.

Et cette idée peut être associée au « star matching » - correspondance par étoile (*) - où un nom qui ne finit pas par un point équivaut à tous les noms sans numéro de version. Ainsi, si un certain répertoire a des fichiers comme ceci :

parce que ça prend tous les noms, les débarasse 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 pareil, vous pouvez voir la différence entre le « *.c » et le « *.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 je n'ai pas rendu compte des détails ici.

Autre chose qui n'est pas une fonction visible par l'utilisateur et certainement compatible à installer, c'est la protection du système de fichiers. À savoir, écrire toutes les informations sur le disque dans l'ordre approprié, en s'arrangeant pour pouvoir 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 l'information redondante. 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 et par là rendre possible 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 de fichier. Ceci si vous voulez remplacer un sous-bloc particulier d'un fichier par de nouvelles données de manière à ce qu'à toute tentative de lecture du fichier cela ne permette de voir que celles-ci ou seulement les anciennes.

Pour le support de réseau, j'ai l'intention par la suite de mettre en œuvre TCP/IP pour ce système. Je pense également qu'il est possible d'utiliser KERMIT pour obtenir quelque chose d'équivalent au UUCP de manière efficace.

Un shell qui a déja été écrit je crois. Il a deux modes. L'un imitant le shell BOURNE et l'autre imitant le shell C dans le même programme. Je n'en ai pas reçu de copie et je ne connais pas la somme de travail que je vais devoir accomplir dessus. En outre, beaucoup d'autres utilitaires existent. Un MAKE existe, LS ; il y a BISON qui remplace YACC qui est distribué. Quelque chose d'assez proche de LEX sort 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 savoir, mais c'est une mauvaise question. Si vous avez payé 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 pouvez-vous aider pour que cela finisse plus tôt ? ». J'ai une liste de projets, elle est dans un dossier au M.I.T.. Les gens qui sont intéressés pour aider 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 « bouncing ball » (la balle magique). Et maintenant prenons 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 la véritable expérience.

On m'a demandé de faire connaître le moyen d'obtenir des copies du logiciel GNU. Bien, un moyen naturellement est de connaître un ami qui en a une copie. Mais si ce n'est pas le cas et que vous n'êtes pas sur l'Internet pour le télécharger, alors vous pouvez toujours commander une distribution et envoyer une certaine somme d'argent à la Free Software Foundation (Fondation pour le Logiciel Libre). Naturellement les logiciels libres ce n'est pas la même chose que la distribution libre. Je l'expliquerai en détail plus tard.

J'ai un manuel d'EMACS, de la série bien imprimée. Ça 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 obtenir ces copies de la Free Software Foundation. Vous pouvez venir après et regarder. Ça contient également une commande pour que vous puissiez copier l'information, de même que cette page [de garde] qui a été aussi appréciée : [montrant du doigt un personnage chassé par RMS à cheval sur un gnu] 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 environ vingt ans que quelqu'un a eu l'idée de faire du business avec ça. C'était un secteur sans à-priori sur la façon de faire ou sur les droits que l'on pouvait avoir. Et il y avait quelques idées sur ce que les autres domaines de la vie pouvaient apporter comme tradition par analogie.

Une analogie appréciée par un bon nombre de professeurs en Europe est celle faite entre les programmes et les 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 avec les recettes. Si vous 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 qu'il n'y a pas de différence entre le code source et le code objet pour la recette, mais c'est toujours 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 avec les livres, sur lesquels s'appliquent le droit d'auteur. 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, pas ceux qui les utilisaient, n'ont pas eu le droit de décider. 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 le domaine, quand j'ai commencé à travailler au M.I.T. en 1971, l'idée que les programmes que nous développions pourraient ne pas être partagés n'a même pas été discutée. Comme à Stanford et C.M.U., comme n'importe qui et DIGITAL également. Le logiciel d'exploitation de DIGITAL à ce moment-là était libre. J'ai de temps en temps obtenu des morceaux de programme du système de DIGITAL comme l'assembleur multi-compatible PDP-11. Je l'ai transféré pour qu'il fonctionne sur ITS et j'y ai ajouté de nombreux utilitaires. Il n'y avait aucun droit d'auteur sur ce programme.

C'est seulement vers la fin des années 70 que ça a commencé à changer. J'ai été extrêmement marqué par l'esprit de partage que nous avions alors. Nous espérions faire quelque chose d'utile et nous étions heureux si les gens pouvaient l'utiliser. Ainsi, quand j'ai développé le premier EMACS et que les gens ont commencé à vouloir l'utiliser en dehors du M.I.T., 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 aviez eu la responsabilité de participer à 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 à ce que chacun dans la communauté puisse en bénéficier.

Mais ça a commencé à se dégrader quand SCRIBE a été développé à C.M.U. puis vendu à une entreprise. Ça a été déroutant pour beaucoup d'entre nous dans de nombreuses universités, parce que nous avons vu que c'était une tentation offerte à chacun et qu'il était bien profitable d'être peu coopératif. Et ceux d'entre nous qui y croyaient toujours n'avaient aucune arme pour tenter de contraindre les gens à coopérer avec nous. Sans aucun doute, les uns après les autres, les gens allaient déserter et cesser de coopérer avec le reste de la société, jusqu'à ce qu'il ne reste plus que ceux qui avaient des consciences très fortes pour continuer. Et c'est ce qu'il s'est passé.

Le domaine de la programmation est maintenant devenu sinistre, où chacun pense de façon cynique à combien il va gagner à ne pas être sympa avec ses homologues et les utilisateurs.

Je veux montrer que le fait de posséder un logiciel est à la fois matériellement inutile, spirituellement nuisible à la société et malfaisant. Ces trois choses étant interdépendantes. C'est spirituellement nocif parce que ça engage manifestement chaque membre de la société en contact avec des ordinateurs dans une pratique matérielle inutile aux autres. Et chaque fois que vous faites quelque chose pour vous-même et que vous savez que ça blesse plus les autres que ça ne vous aide, vous êtes obligé de devenir cynique pour pouvoir supporter une telle chose dans votre esprit. Et c'est malfaisant parce que ça gaspille délibérément le travail effectué dans la société en provoquant l'affaiblissement social.

D'abord je veux expliquer les différentes nuisances causées par les tentatives de posséder un logiciel ou toute autre information utile en général, puis je m'appliquerai à réfuter les arguments qui soutiennent cette pratique, ensuite je veux parler de la façon de combattre ce phénomène et comment je m'y prends moi-même.

L'idée de posséder l'information est nocive à trois niveaux différents. Matériellement nocif à trois niveaux différents. Et à chaque type de nocivité matérielle correspond une nocivité spirituelle.

Au premier niveau, c'est juste que ça décourage l'utilisation du programme. Du coup, peu de gens utilisent le programme, mais ça ne demande pas moins de travail pour l'élaborer. Quand on vous 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 la moitié seulement de cette multitude de gens utilise le programme parce qu'il a un prix, le programme a été à moitié gaspillé. La même quantité de travail a produit seulement la moitié de richesse.

En fait, vous n'avez rien de spécial à faire pour qu'un programme se répande à tous ceux qui veulent l'utiliser, parce qu'ils peuvent le copier eux-mêmes parfaitement bien 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 reposer 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 tente de se faire aider en mettant la pression sur les autres. Toutes les fois qu'un utilisateur signe un accord de non-divulgation, il a essentiellement vendu tous ses homologues utilisateurs. Au lieu de suivre la règle d'or et de dire « J'aime ce programme, mon voisin le voudrait aussi, je veux que nous l'ayons tous les deux », il a dit : « Ouais, donnez-le moi. Au diable mon voisin ! Je vous aiderai à le maintenir hors de sa portée. Ne le donnez qu'à moi ! » et cet esprit est ce qui cause la nuisance spirituelle. Cette attitude de dire « Au diable mes voisins, donnez-moi à MOI une copie ».

Après être rentré dans les gens qui disaient qu'il ne me laisseraient pas avoir de copies parce qu'ils avaient signé un accord secret, 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 c'est juste un des niveaux de la nocivité. Le deuxième niveau arrive 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, en mettant moins de sel - ou peut-être aiment-ils rajouter du poivre vert ? - les gens doivent également modifier les programmes pour obtenir les effets dont ils ont besoin.

Maintenant, 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 une propriété industrielle, 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 frustation 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. La quantité de changement que cela demandait était probablement faible, mais comme les sources de ce programme n'étaient pas disponibles, c'était impossible. Elle a dû partir de zéro et dilapider beaucoup de temps. Et nous ne pouvons que spéculer sur la fraction de l'ensemble des programmeurs du monde qui perdent leur temps de cette façon.

Il y a aussi le cas où un programme est adéquat mais inconfortable. Par exemple : la première fois que nous avons eu une imprimante graphique au M.I.T., nous avons écrit le logiciel nous-mêmes et nous avons installé un bon nombre d'utilitaires sympathiques. Par exemple, il devait vous envoyer un message quand le travail d'impression était fini et il vous envoyait un message si l'imprimante manquait de papier, si vous aviez un travail en file d'attente et pas mal d'autres choses qui correspondaient à ce que nous voulions. Nous avons alors reçu 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'accepteraient pas d'intégrer les utilitaires et nous ne pouvions pas le faire nous-même. Aussi nous avons dû nous contenter de choses qui ne « fonctionnaient qu'à moitié ». Et c'était très frustrant de savoir que nous étions prêts, désireux et capables d'arranger ça mais que nous n'en avions pas le droit. On nous sabotait.

Et il y a toutes les personnes 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 devraient être écrits ou comment ils font ce qu'ils font, c'est de lire le code source.

Aussi je ne peux que me demander si l'idée d'un utilisateur qui voit l'ordinateur uniquement comme un outil tient réellement ou non de la prophétie d'auto-épanouissement ; une conséquence du fait de maintenir le code source secret.

Maintenant la nocivité spirituelle qui correspond à ce type de nocivité matérielle réside dans l'esprit d'auto-suffisance. Quand une personne dépense une bonne partie de son temps à utiliser un système informatique, la configuration de ce système informatique devient le pays dans lequel elle vit. Tout comme la manière dont nos maisons et nos meubles sont disposés détermine comment nous vivons parmi eux. Ainsi va le système informatique que nous utilisons. Et 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 sera toujours mauvais. Je ne vais rien gagner à tout déranger. Je ne vais qu'y consacrer mon temps et… quand j'aurai fini, je m'en irai en tâchant de ne plus y penser ». Ce genre d'esprit, ce manque d'enthousiasme est ce qui résulte de ne pas être autorisé à améliorer les choses quand vous avez l'esprit public.

Le troisième niveau de nocivité se situe dans l'interaction entre les développeurs de logiciel eux-mêmes. Puisque tout domaine de connaissance avance davantage quand les gens peuvent construire à partir du travail des autres. Mais l'appropriation de l'information est explicitement conçue pour empêcher tout autre de le faire. 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 à partir du début et en ralentissent ainsi considérablement l'avancement.

Aussi nous pouvons le constater : combien de tableurs ont-ils été crées par différentes entreprises sans avoir tiré bénéfice de ce qui avait déjà été fait ? Oui il est vrai, le premier tableur qui a été écrit n'était pas parfait. Il a probablement seulement fonctionné 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 réécrit les morceaux qu'elles voulaient vraiment améliorer, cela 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 seulement prendre la partie que vous aimez et seulement refaire le morceau qui vous inspire, vous pourriez avoir le meilleur système en tout point. Avec beaucoup moins de travail que cela n'en prend d'écrire un système entièrement. Et nous savons tous qu'un système peut souvent tirer bénéfice d'être entièrement réécrit, mais à condition de pouvoir lire le vieux d'abord.

Donc, les personnes dans le domaine de la programmation ont évolué de manière à perdre une bonne partie de leur temps en 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 ? Puisqu'avec la propriété intellectuelle ceux-ci se sont organisés pour gaspiller la moitié de leur travail, il semble 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 d'emploi, regardez l'ampleur de cette industrie »", cela ne prouve réellement que 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 pourraient la réduire, ils sont contre. Puisque cela réduirait le nombre de programmeurs utilisés. Il y a quelque chose d'un peu schizophrène là-dedans.

Et la nocivité spirituelle qui correspond à ce niveau de nocivité matérielle se trouve dans l'esprit de coopération scientifique, qui était si fort, que même les scientifiques dans les 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, les gens ne s'en inquiètent plus.

Pour avoir une idée de ce qui peut empêcher l'utilisation d'un programme, imaginez un sandwich que vous pouvez manger mais qui ne serait pas consommé. Vous pourriez le manger, une autre personne pourrait le manger, le même sandwich, n'importe quel nombre de fois et il en resterait toujours comme s'il nourrissait autant qu'à l'origine.

La meilleure chose à faire, ce que nous devons faire avec ce sandwich, est de l'amener partout où les gens sont affamés; l'amenant à autant de bouches que possible, de sorte qu'il alimente autant de personnes que possible. Il est certain que nous ne devrions pas mettre de prix sur ce sandwich, parce que sinon les gens ne se permettraient pas de le manger et il serait gaspillé.

Un programme est comme ce sandwich, mais encore plus, 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, et cela n'a pas pu se produire parce que quelqu'un a cru qu'il pouvait le posséder.

Maintenant, les gens qui croient qu'ils peuvent posséder les 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 coeur, mon âme y est. Qui peut me l'enlever ? Où qu'il aille, il est à moi, à moi, A MOI !! ». Bien, 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 c'est l'une des choses que vous pouvez facilement vous dire en croyant que c'est important, mais vous pouvez aussi aisément vous convaincre que cela n'a pas d'importance du tout.

Habituellement, ces personnes usent de cet argument pour exiger le droit de contrôler même la façon dont les gens peuvent modifier le programme. Ils disent : « Personne ne devrait pouvoir gâcher mon œuvre d'art ». Bien, imaginez que la personne qui a inventé le plat que vous projetez de cuisiner a eu le droit de contrôler la façon dont vous pouvez le faire cuire parce que c'est son œuvre d'art. Vous voulez y enlever le 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 dois-je faire ? ».

Clairement, la personne qui utilise le programme est bien plus près de l'événement. L'utilisation du programme l'affecte directement tandis qu'il y a juste une sorte de relation abstraite avec la personne qui l'a écrit. 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 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, au 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 ». De même « Comment aurai-je un toit au-dessus de ma tête ? » mais 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 de logiciel parce que ça leur donne la possibilité de se faire le plus d'argent possible, non pas parce que c'est le seul moyen de soutenir l'effort de développement d'un système. En fait, aussi récemment qu'il y a dix ou quinze ans, on aidait au développement de logiciel de différentes manières. 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 libres et les gens avaient déjà été payés pour ça.

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 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, après avoir payé des gens pour le faire. Par exemple, toutes les rues là-dehors. Autant il est très 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 créatrive ni amusante comme la programmation mais nous avons des tas de rues là-dehors. Nous apportons l'argent pour payer ces gens et c'est bien mieux comme ça que d'avoir dit : « Laissons les entreprises faire et construire des routes et des cabines de péage, et chaque fois que vous tournez à un coin de rue vous paierez un autre péage. De là, les entreprises qui auront sélectionné les bons endroits pour mettre leurs routes feront des profits et les autres feront faillite ».

Il y a une chose drôle qui se produit 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 le seul genre de 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 fonds pour que tout le monde le devienne. Et même lorsque vous obtenez des fonds, vous n'en obtenez pas beaucoup. Et ces gens ne vivent pas bien. Pour des musiciens c'est encore pire. J'ai vu des statistiques sur combien le musicien moyen - le péquin moyen qui consacre la majeure partie de son temps à tenter de devenir musicien - se fait dans le Massachusetts ; c'était 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 ».

Et j'ai vu cela se produire dans le domaine de la programmation. Les mêmes qui travaillaient au laboratoire d'I.A. en étant très peu payés et qui aimaient ça, aujourd'hui ne rêveraient pas d'un travail 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 à l'ancienne manière. Il est facile une fois que cela s'est produit, de penser que de bien payer les gens est désormais le seul moyen. 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, particulièrement quand c'est créatif et amusant.

Maintenant que j'ai vu le monde unique du laboratoire d'I.A. détruit et la vente du logiciel en être intrinsèquement responsable, j'ai également vu, comme je l'ai expliqué avant, le besoin en logiciel libre pour retrouver une communauté comme celle-là. Mais en y réfléchissant davantage, j'ai réalisé l'ampleur de la nocivité du logiciel accaparé sur l'ensemble de la société, plus particulièrement la pression mise sur les gens pour qu'ils vendent au détriment de leurs voisins et causant l'affaiblissement social. Le même esprit qui pousse les gens à observer quelqu'un qui se fait poignarder dans la rue sans le dire à personne. Cet esprit dont nous pouvons voir tant d'entreprises en faire la preuve autour de nous. Il était évident que j'avais le choix. 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. Ainsi 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'accaparer l'information utile à l'ensemble des gens. Et le système GNU est un moyen à cet effet. Il 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 d'une personne. Il y avait des gens aux USA, il y a plus ou moins cinquante ans, de la Mafia qui entraient dans les magasins et les bars, spécialement les bars hors-la-loi évidemment. Ils pouvaient entrer et dire : « Pas mal d'endroits par ici ont brûlé dernièrement. Vous ne voudriez pas que le vôtre subisse le même sort ? Aussi, nous pouvons vous protéger contre les incendies, vous avez juste à nous payer mille dollars par mois et nous nous assurerons qu'il n'y aura 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. Bien, si vous ne voulez pas que ces programmes disparaissent, si vous ne voulez pas que la police vous poursuive, vous feriez mieux de payer mille dollars et je vous donnerai une copie de ce programme avec une autorisation », et ça s'appelle « le racket de protection de logiciel ».

Vraiment, tout ce qu'ils font c'est interférer avec tous ceux qui font ce qui doit être fait, mais ils prétendent fournir - davantage pour eux-mêmes que pour le reste du monde - une fonction utile. Bon. Ce que j'espère, c'est que quand ce type de Mafia du logiciel entre et dit : « 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 ».

Maintenant, un des moyens de justifier parfois le fait de posséder le logiciel est l'idée de donner l'envie aux gens de produire des choses. Je soutiens l'idée de l'entreprise privée en général et l'idée de vouloir gagner de l'argent en produisant des choses que d'autres aiment à utiliser, mais ça se détraque dans le domaine du logiciel maintenant. Produire un programme propriétaire, ce n'est pas la même contribution à la société que produire ce 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é vient seulement quand le programme est utilisé. Et si vous empêchez l'utilisation du programme, la contribution ne se produit pas vraiment. Aussi, la contribution dont la société a besoin ne réside pas dans ces programmes propriétaires que tout le monde a tellement envie de faire. La contribution que nous voulons vraiment est celle du logiciel libre. Aussi notre société se détraque parce qu'elle donne aux gens l'envie de faire ce qui n'est pas utile et aucune envie de faire ce qu'est utile. Ainsi l'idée fondamentale de l'entreprise privée n'est pas comprise et vous pourriez même dire que la société est névrotique. Car après tout, quand un individu encourage dans le comportement des autres ce qui n'est pas bon pour lui, vous appelez ça une névrose. Ici la société se comporte comme ça, en encourageant les programmeurs à faire des choses qui ne sont pas bonnes pour la société.

Je ne suis pas 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 tout le monde est plus ou moins tracassé par le sentiment d'être payé pour faire ce qui n'est pas vraiment utile. Aussi cessons de défendre l'idée d'encourager à faire la mauvaise chose et essayons au moins de proposer des arrangements pour encourager les gens à faire la bonne, qui est de faire du logiciel libre.

[Après ça, RMS a répondu à des questions pendant environ une heure. J'ai seulement inclus très un peu de ces questions et réponses dans cette version. La bande était mauvaise, et je n'ai pas eu le temps de faire un travail approprié sur la totalité]

La seule fois qu'on a tenté de me causer des ennuis c'était avec ces propriétaires prétendus, soi-disant propriétaires de Gosling Emacs. Hormis le fait qu'ils n'en avaient aucune raison, ils ne peuvent rien faire de plus. D'ailleurs, je voudrais attirer l'attention de tout le monde sur la façon dont les gens se servent d'un langage pour essayer d'encourager les gens à penser certaines choses et à ne pas penser à d'autres. Une grande part de la terminologie actuelle dans le domaine a été choisie par les soi-disant propriétaires de logiciel pour tenter de vous encourager à voir le logiciel assimilé à des objets matériels comme une propriété 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 le logiciel avec son voisin comme un bon citoyen.

J'ai oublié de vous dire ceci : L'idée de droit d'auteur a été inventé après la presse imprimée. Dans l'ancien temps, les auteurs se copiaient les uns les autres librement et ceci n'était pas mal considéré. Et c'était même très utile : certains travaux d'auteurs ont seulement pu survivre, même en fragments, parce qu'ils ont été cités longuement dans d'autres travaux qui, eux ont survécu.

C'était parce que des livres étaient copiés une fois à ce moment-là. Il était dix fois plus dur d'en tirer dix copies qu'une seule. Alors la presse a été inventée. Et ceci n'a pas empêché les gens de copier les livres à la main. Mais par comparaison avec le fait de les imprimer, les copier à la main était si désagréable que cela pouvait rendre la tâche tout à fait impossible.

Quand les livres ont pu être produits en masse, le droit d'auteur commençait à avoir un sens. De plus, celui-ci n'a pas confisqué la liberté de lecture publique, puisqu'en tant que membre du public qui n'avait pas de presse vous ne pouviez pas copier de livre de toute façon. Aussi vous ne perdiez aucune liberté à cause du droit d'auteur. Il a été inventé et se comprenait par 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 à la rotation de la bande].

Ainsi nous retournons dans la même situation que dans le monde antique où le droit d'auteur n'avait pas de sens.

Si nous considérons notre concept de propriété, ça vient des objets matériels. Les objets matériels satisfont une loi économique, plutôt pas mal. Oui c'est vrai, je peux casser une craie en deux mais ce n'est pas ça, et 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 et nos idées de propriété ont été développées pour qu'il y ait un sens moral à ce que ces faits concordent.

Pour une partie d'information que tout le monde peut copier, les faits sont différents. 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'objet matériel, vous pouvez venir emporter cette chaise mais vous ne pouvez pas venir la copier. Et si vous emportiez la chaise, elle ne produirait rien, il n'y a 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 : « Ouais, c'est compréhensible ». Quand une personne dit : « J'ai gravé les bits sur ce disque, une seule personne peut l'avoir alors n'essayez pas de me l'enlever », ça se comprend aussi. Si seulement une personne peut avoir le disque, ça pourrait aussi bien être celui qui le possède.

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 et je l'emmènerai et vous pouvez continuer à utiliser ce disque comme vous le faisiez avant ». 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 bon.

Si les gens peuvent ne pas avoir à construire mais juste à claquer des doigts et reproduire, c'est merveilleux. Mais ce changement technologique ne convient pas aux gens 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 conservables. Aussi ils font leur possible pour transformer les programmes en objets matériels. Vous êtes-vous demandé pourquoi quand vous allez dans un magasin de logiciel et que vous achetez une copie de programme, cela revient à acheter quelque chose qui ressemble à un livre ? Ils veulent que les gens imaginent qu'ils obtiennent un objet matériel, pas qu'ils réalisent que ce qu'ils ont vraiment obtenu est 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, des machines qui peuvent imiter n'importe quelle autre machine. La raison pour laquelle une machine universelle est si bonne, c'est que vous pouvez lui faire imiter n'importe laquelle. Et les modes d'emploi peuvent être copiés et changés, tout ce 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 avoir l'avantage du changement technologique vers les machines universelles mais ils ne veulent pas que le public l'obtienne.

Pour l'essentiel, ils tentent de conserver « l'âge de l'objet matériel » mais celui-ci est fini et notre conception du vrai et du faux devrait être synchrone avec les faits réels du monde dans lequel nous vivons.

Ainsi ça réduit les droits de propriété de l'information. Pensez-vous qu'il y ait des exemples où, selon vous, il est bon de posséder l'information ?

Pour une information qui n'est pas utile au public ou à caractère personnel, je dirais OUI. En d'autres termes, pas l'information 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 réellement rien créer. Je dirais qu'il est parfaitement raisonnable de garder ce genre de chose secret et sous contrôle. Mais en termes d'information créatrice, celle que les gens peuvent utiliser ou dont ils peuvent profiter et qui le sera d'autant plus que plus de gens l'auront, nous devrions toujours en encourager la copie.

Autres textes à lire

Retournez à la page principale du projet GNU.

Pour les questions et requêtes relatives à la FSF & GNU : gnu@gnu.org. Autres moyens pour contacter la FSF. Merci d'envoyer des commentaires sur cette page web à webmasters@gnu.org, envoyer une autre question à gnu@gnu.org.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

La reproduction exacte et la distribution intégrale de cet article est permise sur n'importe quel support d'archivage, pourvu que cette notice soit préservée.

Dernière mise à jour : $Date: 2006/02/08 16:35:54 $ $Author: taz $

Traduction : Miluz
Révision : trad-gnu@april.org

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

Autres textes à lire