Le projet GNU

par Richard Stallman

La première communauté qui partageait le logiciel

En 1971, quand j'ai commencé à travailler au labo d'intelligence artificielle (IA) du MIT (Institut de technologie du Massachusetts), j'ai intégré une communauté qui partageait le logiciel depuis de nombreuses années déjà. Le partage du logiciel n'était pas limité à notre communauté ; c'est une notion aussi ancienne que les premiers ordinateurs, tout comme le partage des recettes est aussi ancien que la cuisine. Mais nous partagions davantage que la plupart.

Le labo d'IA utilisait un système d'exploitation à temps partagé appelé ITS (système à temps partagé incompatible) que les hackers [1] de l'équipe avaient écrit et mis au point en langage assembleur pour le PDP-10 de Digital, l'un des grands ordinateurs de l'époque [1]. En tant que membre de cette communauté, hacker système de l'équipe du labo d'IA, mon travail consistait à améliorer ce système.

Nous ne qualifiions pas nos productions de « logiciels libres », car ce terme n'existait pas encore ; c'est pourtant ce qu'elles étaient. Quand d'autres universitaires, ou bien une entreprise, souhaitaient porter l'un de nos programmes pour l'utiliser sur leur matériel, nous les laissions volontiers faire. Et quand on voyait quelqu'un utiliser un programme inconnu qui semblait intéressant, on pouvait toujours en obtenir le code source, afin de le lire, le modifier, ou d'en réutiliser des parties dans le cadre d'un nouveau programme.

L'effondrement de la communauté

La situation changea de manière radicale au début des années 80 quand la société Digital mit fin à la série des PDP-10. Cette architecture, élégante et puissante dans les années 60, ne pouvait pas s'adapter sans difficulté aux plus grands espaces d'adressage qui devenaient réalisables dans les années 80. Cela rendait obsolètes la quasi-totalité des programmes constituant ITS.

La communauté des hackers du labo d'IA s'était effondrée peu de temps auparavant. La plupart d'entre eux avaient été engagés par une nouvelle société, Symbolics, et ceux qui étaient restés ne parvenaient pas à maintenir la communauté (le livre Hackers, écrit par Steve Levy, décrit ces événements et dépeint clairement l'apogée de cette communauté). Quand le laboratoire a, en 1982, choisi d'acheter un nouveau PDP-10, ses administrateurs ont décidé de remplacer ITS par le système à temps partagé de la société Digital, qui n'était pas libre.

Les ordinateurs modernes d'alors, tels le VAX et le 68020, disposaient de leurs propres systèmes d'exploitation, mais aucun d'entre eux n'était libre : il fallait signer un accord de confidentialité pour en obtenir ne serait-ce qu'une copie exécutable.

Cela signifiait que la première étape de l'utilisation d'un ordinateur était la promesse de ne pas aider son prochain. On interdisait toute communauté fondée sur la coopération. La règle qu'édictaient ceux qui détenaient le monopole d'un logiciel privateur ^b était : « Qui partage avec son voisin est un pirate. Qui souhaite la moindre modification doit nous supplier de la lui faire. »

L'idée que le système social du logiciel privateur – le système qui vous interdit de partager ou d'échanger le logiciel – est antisocial, contraire à l'éthique, et qu'il est tout simplement mauvais, surprendra peut-être certains lecteurs. Mais comment qualifier autrement un système fondé sur la division et l'isolement des utilisateurs ? Les lecteurs surpris par cette idée ont probablement pris le système social du logiciel privateur pour argent comptant, ou l'ont jugé en employant les termes suggérés par les entreprises de logiciel privateur. Les éditeurs de logiciels travaillent d'arrache-pied, et depuis longtemps, à convaincre tout un chacun qu'il n'existe qu'un seul point de vue sur la question – le leur.

Quand les éditeurs de logiciels parlent de « faire respecter » leurs « droits » ou de « couper court au piratage », ce qu'ils disent est secondaire. Le véritable message se trouve entre les lignes et il consiste en des hypothèses de travail qu'ils considèrent comme acquises ; nous sommes censés les accepter les yeux fermés. Passons-les donc en revue.

La première hypothèse est que les sociétés éditrices de logiciel disposent d'un droit naturel, incontestable, à être propriétaire du logiciel et asseoir ainsi leur pouvoir sur tous ses utilisateurs (si c'était là un droit naturel, on ne pourrait formuler aucune objection, indépendamment du tort qu'il cause à tous). Il est intéressant de remarquer que la Constitution et la tradition juridique des États-Unis d'Amérique rejettent toutes deux cette idée ; le copyright n'est pas un droit naturel, mais un monopole artificiel, imposé par l'État, restreignant le droit naturel de copier que possèdent les utilisateurs.

Autre hypothèse sous-jacente : seules importent les fonctionnalités du logiciel; des utilisateurs comme nous ne doivent pas s'intéresser au modèle de société qu'on leur prépare.

Une troisième hypothèse est qu'on ne disposerait d'aucun logiciel utilisable (ou qu'on ne disposerait jamais d'un logiciel qui s'acquitte de telle ou telle tâche en particulier) si l'on ne garantissait pas à une entreprise l'assise d'un pouvoir sur les utilisateurs du programme. Cette idée était plausible, jusqu'à ce que le mouvement du logiciel libre démontrât qu'on peut produire toutes sortes de logiciels utiles sans qu'il soit nécessaire de les barder de chaînes.

Si l'on se refuse à accepter ces hypothèses et qu'on examine ces questions en se fondant sur une morale dictée par le bon sens, tout en plaçant les utilisateurs au premier plan, on parvient à des conclusions bien différentes. Les utilisateurs doivent être libres de modifier les programmes pour qu'ils répondent mieux à leurs besoins, et libres de partager le logiciel parce que la société est fondée sur l'aide à autrui.

La place me manque ici pour développer le raisonnement menant à cette conclusion, aussi renverrai-je le lecteur aux articles « Pourquoi les logiciels ne doivent pas avoir de propriétaire » et « Le logiciel libre est encore plus essentiel maintenant ».

Un choix moral difficile

Avec l'extinction de ma communauté, il m'était impossible de continuer comme par le passé. J'étais confronté à un choix moral difficile.

La solution de facilité était de rejoindre le monde du logiciel privateur, signer des accords de confidentialité et promettre de ne pas aider mon camarade hacker. Très probablement, j'aurais aussi été amené à développer du logiciel publié avec des clauses de confidentialité, contribuant ainsi à en pousser d'autres vers la trahison de leurs camarades.

J'aurais pu gagner de l'argent de cette façon et peut-être même trouver amusant d'écrire du code. Mais je savais qu'à la fin de ma carrière je n'aurais à contempler que des années passées à construire des murs pour séparer les gens, avec l'impression d'avoir employé ma vie à rendre le monde pire.

J'avais déjà eu l'expérience douloureuse des clauses de confidentialité, quand quelqu'un m'avait refusé, ainsi qu'au labo d'IA du MIT, l'accès au code source du programme de contrôle de notre imprimante (l'absence de certaines fonctionnalités dans ce programme rendait l'utilisation de l'imprimante très frustrante). Aussi ne pouvais-je pas me dire que les clauses de confidentialité étaient bénignes. Le refus de cette personne de partager avec nous m'avait mis très en colère ; je ne pouvais pas, à mon tour, adopter un tel comportement à l'égard de mon prochain.

Une autre possibilité, radicale mais déplaisante, était d'abandonner l'informatique. De cette manière, mes capacités ne seraient pas employées à mauvais escient, mais elles n'en seraient pas moins gaspillées. Je ne me rendrais pas coupable de diviser les utilisateurs d'ordinateurs et de restreindre leurs droits, mais cela se produirait malgré tout.

Alors, j'ai cherché une façon pour un programmeur de se rendre utile pour la bonne cause. Je me suis demandé si je ne pouvais pas écrire un ou plusieurs programmes qui permettraient de souder à nouveau une communauté.

La réponse était limpide : le besoin le plus pressant était un système d'exploitation. C'est le logiciel le plus crucial pour commencer à utiliser un ordinateur. Un système d'exploitation permet de faire beaucoup de choses ; sans système, l'ordinateur est inexploitable. Avec un système d'exploitation libre, on pourrait reconstituer une communauté de hackers travaillant en mode coopératif – et inviter chacun à participer. Ainsi tout un chacun pourrait se servir d'un ordinateur sans au préalable entrer dans une conspiration destinée à spolier ses ami.e.s.

En tant que développeur de système d'exploitation, j'avais les compétences requises. Aussi, bien que le succès ne me semblât pas garanti, je me suis rendu compte que j'étais prédestiné à faire ce travail. J'ai choisi de rendre le système compatible avec Unix de manière à le rendre portable, pour que les utilisateurs d'Unix puissent migrer facilement. J'ai opté pour le nom « GNU », fidèle en cela à une tradition des hackers, car c'est un acronyme récursif qui signifie GNU's Not Unix (GNU N'est pas Unix). Il se prononce « gnou » (comme l'animal), avec un g dur.

Un système d'exploitation ne se limite pas à un noyau, qui suffit à peine à exécuter d'autres programmes. Dans les années 70, tout système d'exploitation digne de ce nom disposait d'interpréteurs de commandes (shell), d'assembleurs, de compilateurs, d'interpréteurs, de débogueurs, d'éditeurs de textes, de logiciels de courrier électronique, pour n'en citer que quelques-uns. C'était le cas d'ITS, c'était le cas de Multics, c'était le cas de VMS et c'était le cas d'Unix. Ce serait aussi le cas du système d'exploitation GNU.

Plus tard, j'ai entendu ces mots, attribués à Hillel [2] :

If I am not for myself, who will be for me?
If I am only for myself, what am I?
If not now, when? ^c

C'est dans cet état d'esprit que j'ai pris la décision de lancer le projet GNU.

Free comme libre

Le terme free software est mal compris : il n'a rien à voir avec le prix.^d Il parle de liberté. Voici donc la définition d'un logiciel libre.

Un programme est un logiciel libre pour vous, utilisateur particulier, si :

• vous avez la liberté de l'exécuter comme vous le souhaitez, pour quelque motif que ce soit ;
• vous avez la liberté de modifier le programme afin qu'il corresponde mieux à vos besoins (dans la pratique, pour que cette liberté prenne effet, il vous faut pouvoir accéder au code source, puisqu'opérer des modifications au sein d'un programme dont on n'a pas le code source est un exercice extrêmement difficile) ;
• vous disposez de la liberté d'en redistribuer des copies, que ce de manière gratuite ou onéreuse ;
• vous avez la liberté de distribuer des versions modifiées du programme, afin que la communauté puisse bénéficier de vos améliorations.

Puisque le mot free se réfère ici à la liberté et non au prix, il n'est pas contradictoire de vendre des copies de logiciels libres. En réalité, cette liberté est cruciale : les compilations de logiciels libres vendues sur CD-ROM sont importantes pour la communauté, car le produit de leur vente permet de lever des fonds pour le développement du logiciel libre. C'est pourquoi on ne peut pas qualifier de libre un logiciel qu'on n'a pas la liberté d'inclure dans de telles compilations.

Le mot free étant ambigu en anglais, on a longtemps cherché des solutions de remplacement, mais personne n'a trouvé mieux. La langue anglaise compte plus de mots et de nuances que toute autre langue, mais elle souffre de l'absence d'un mot simple, univoque, qui ait le sens de free comme liberté – unfettered (terme littéraire signifiant « sans entrave ») étant le meilleur candidat, d'un point de vue sémantique. Des mots comme liberated (libéré), freedom (liberté) et open (ouvert) présentent tous un sens incorrect ou un autre inconvénient.

Les logiciels GNU et le système GNU

C'est un projet de très grande envergure que de développer un système complet. Pour le mener à bien, j'ai décidé d'adapter et de réutiliser les logiciels libres existants, quand cela était possible. J'ai par exemple décidé dès le début d'utiliser TeX comme formateur de texte principal ; quelques années plus tard, j'ai décidé d'utiliser le système X Window plutôt que d'écrire un autre système de fenêtrage pour GNU.

Cette décision, comme d'autres du même genre, a rendu le système GNU distinct de la réunion de tous les logiciels GNU. Le système GNU comprend des programmes qui ne sont pas des logiciels GNU ; ce sont des programmes qui ont été développés par d'autres, dans le cadre d'autres projets, pour leurs buts propres, mais qu'on peut réutiliser, car ce sont des logiciels libres.

La genèse du projet

En janvier 1984, j'ai démissionné de mon poste au MIT et commencé à écrire les logiciels GNU. Il était nécessaire que je quitte le MIT pour empêcher ce dernier de s'immiscer dans la distribution de GNU en tant que logiciel libre. Si j'avais gardé mon poste, le MIT aurait pu se déclarer propriétaire de mon travail et lui imposer ses propres conditions de distribution, voire le transformer en logiciel privateur. Je n'avais pas l'intention d'abattre autant de travail pour le voir devenir impropre à sa destination première : créer une nouvelle communauté qui partage le logiciel.

Cependant, le professeur Winston, qui dirigeait alors le labo d'IA du MIT, m'a gentiment invité à continuer d'utiliser les équipements du laboratoire.

Les premiers pas

Peu de temps avant de me lancer dans le projet GNU, j'avais entendu parler du Free University Compiler Kit,^e plus connu sous le nom de VUCK (en néerlandais, le mot qui veut dire free commence par un v). Ce compilateur avait été mis au point dans l'intention de gérer plusieurs langages, parmi lesquels C et Pascal, et de produire des binaires pour de nombreuses machines cibles. J'ai écrit à son auteur en lui demandant la permission d'utiliser ce compilateur dans le cadre du projet GNU.

Il répondit d'un ton railleur, en déclarant (en anglais) que l'université était free mais pas le compilateur. J'ai alors décidé que le premier programme du projet GNU serait un compilateur gérant plusieurs langages, sur plusieurs plateformes.

En espérant m'épargner la peine d'écrire tout le compilateur moi-même, j'ai obtenu le code source du compilateur Pastel, qui avait été développé au laboratoire Lawrence Livermore et était multiplateforme. Il compilait une version étendue de Pascal conçue comme langage de programmation système, et c'était aussi le langage dans lequel il avait été écrit. J'y ai ajouté une interface pour le C et j'ai entrepris le portage de ce programme sur le Motorola 68000. Mais j'ai dû abandonner quand j'ai découvert qu'il fallait à ce compilateur plusieurs mégaoctets d'espace de pile, alors que le système Unix du 68000 n'en gérait que 64 ko.

J'ai alors compris comment fonctionnait Pastel : il analysait le fichier en entrée, en faisait un arbre syntaxique, convertissait cet arbre syntaxique en chaîne d'« instructions » et engendrait ensuite le fichier de sortie, sans jamais libérer le moindre espace mémoire. J'en ai conclu qu'il me faudrait réécrire un nouveau compilateur en partant de zéro. Ce dernier est maintenant connu sous le nom de GCC ; il n'utilise rien de Pastel, mais j'ai réussi à adapter et réutiliser l'analyseur syntaxique que j'avais écrit pour le langage C. Mais tout cela ne s'est produit que quelques années plus tard ; j'ai d'abord travaillé sur GNU Emacs.

GNU Emacs

J'ai commencé à travailler sur GNU Emacs en septembre 1984 ; début 1985, ce programme commençait à devenir fonctionnel, ce qui m'a permis d'utiliser des systèmes Unix pour éditer mes fichiers ; n'ayant aucune envie de me familiariser avec vi ou ed, j'avais jusqu'alors utilisé d'autres types de machines pour les éditer.

C'est alors que j'ai reçu des requêtes de gens souhaitant utiliser GNU Emacs, ce qui a soulevé le problème de sa distribution. Je l'avais bien sûr mis sur le serveur FTP anonyme de l'ordinateur du MIT que j'utilisais (cet ordinateur, prep.ai.mit.edu, a ainsi été promu au rang de site de distribution principal par FTP du projet GNU ; quelques années plus tard, à la fin de son exploitation, nous avons transféré ce nom sur notre nouveau serveur FTP). Mais à l'époque, une proportion importante des personnes intéressées, n'ayant pas d'accès à Internet, ne pouvaient pas se procurer de copie du programme par FTP. La question se posait en ces termes : que devais-je leur dire ?

J'aurais pu leur dire : « Trouvez un ami qui dispose d'un accès au réseau et qui vous en fera une copie. » J'aurais pu également leur dire, comme je l'avais fait avec la version originale d'Emacs pour PDP-10, « Envoyez-moi une bande et une enveloppe timbrée à votre adresse ; je vous les renverrai avec Emacs. » Mais j'étais sans emploi et je cherchais des moyens de gagner de l'argent grâce au logiciel libre. C'est pourquoi j'ai annoncé que j'enverrais une bande à quiconque en désirait une, en échange d'une contribution de 150 dollars américains. C'est ainsi que j'ai créé une entreprise de distribution de logiciel libre, l'ancêtre des sociétés qui, de nos jours, proposent des distributions GNU/Linux complètes.

Un programme est-il libre pour chacun de ses utilisateurs ?

Si un programme est un logiciel libre au moment où il quitte les mains de son auteur, cela ne signifie pas nécessairement qu'il sera un logiciel libre pour quiconque en possédera une copie. Un logiciel placé dans le domaine public, par exemple (qui n'est couvert par aucun copyright), est un logiciel libre ; mais tout un chacun peut en produire une version privatrice modifiée. De façon comparable, de nombreux programmes libres sont couverts par des copyrights, mais distribués sous des licences permissives qui autorisent la création de versions modifiées privatrices.

L'exemple le plus frappant de ce problème est le système X Window. Développé au MIT et distribué sous forme de logiciel libre avec une licence permissive, il a rapidement été adopté par divers constructeurs. Ils ont ajouté X à leurs systèmes Unix privateurs, sous forme binaire uniquement, en le frappant du même accord de confidentialité. Ces exemplaires de X n'étaient pas plus libres que le reste d'Unix.

Les développeurs du système X Window ne voyaient là nul problème (ils s'attendaient à cela et souhaitaient un tel résultat). Leur but n'était pas la liberté, mais la simple « réussite », définie comme le fait d'« avoir beaucoup d'utilisateurs ». Peu leur importait la liberté de ces utilisateurs, seul leur nombre revêtait de l'importance à leurs yeux.

Cela a conduit à une situation paradoxale où deux façons différentes d'évaluer la liberté donnaient des réponses différentes à la question « Ce programme est-il libre ? » Qui fondait son jugement sur la liberté accordée par les termes de distribution de la version du MIT concluait que X était un logiciel libre. Mais qui mesurait la liberté de l'utilisateur-type de X devait conclure que X était un logiciel privateur. La plupart des utilisateurs de X exécutaient les versions privatrices fournies avec les systèmes Unix et non la version libre.

Le copyleft et la GNU GPL

Le but du projet GNU était de rendre les utilisateurs libres, pas de se contenter d'être populaire. Nous avions besoin de conditions de distribution qui empêcheraient de transformer les logiciels GNU en logiciels privateurs. La méthode que nous utilisons a pour nom « copyleft » [3], ou « gauche d'auteur ».

Le copyleft utilise le copyright (ou le droit d'auteur), en le retournant pour lui faire servir le but opposé de ce pour quoi il a été conçu : ce n'est pas une manière de restreindre l'utilisation d'un logiciel, mais une manière de lui conserver sa liberté.

L'idée centrale du copyleft est de donner à chacun la permission d'exécuter le programme, de le copier, de le modifier et d'en distribuer des versions modifiées (mais pas la permission d'ajouter des restrictions de son cru). C'est ainsi que les libertés essentielles qui définissent le « logiciel libre » sont garanties pour quiconque en possède un exemplaire ; elles deviennent des droits inaliénables.

Pour que le copyleft soit efficace, il faut que les versions modifiées demeurent libres, afin de s'assurer que toute œuvre dérivée de notre travail reste disponible pour la communauté en cas de publication. Quand un programmeur professionnel améliore bénévolement un logiciel GNU, c'est le copyleft qui empêche son employeur de dire : « Vous ne pouvez pas partager ces modifications, car nous allons les utiliser dans le cadre de notre version privatrice du programme. »

Il est essentiel d'imposer que les modifications restent libres si l'on souhaite garantir la liberté de tout utilisateur du programme. Les sociétés qui ont privatisé le système X Window faisaient en général quelques modifications pour le porter sur leur système d'exploitation et sur leur matériel. Ces modifications étaient ténues si on les comparait à X dans son ensemble, mais elles n'en étaient pas pour autant évidentes. Si le fait de procéder à des modifications était un prétexte valable pour refuser aux utilisateurs leur liberté, n'importe qui pourrait facilement en tirer parti.

Le problème de la réunion d'un programme libre avec du code non libre est similaire. Une telle combinaison serait indubitablement non libre ; les libertés absentes de la partie non libre du programme ne se trouveraient pas non plus dans l'ensemble, résultat de la combinaison. Autoriser de telles pratiques ouvrirait une voie d'eau suffisante pour couler le navire. C'est pourquoi il est essentiel que le copyleft colmate cette brèche : l'ajout ou la jonction d'un élément quelconque à un programme sous copyleft doit se faire de telle sorte que la version élargie résultant de l'opération soit également libre et régie par le copyleft.

La mise en œuvre spécifique du copyleft que nous utilisons pour la plupart des logiciels GNU est la licence publique générale GNU, GNU GPL en abrégé. Nous disposons d'autres types de copyleft pour des circonstances particulières. Les manuels du projet GNU sont eux aussi régis par le copyleft, mais en utilisent une version très simplifiée car il n'est pas nécessaire de faire appel à toute la complexité de la GNU GPL dans le cadre de manuels [4].

La Free Software Foundation, ou Fondation pour le logiciel libre

Emacs attirant de plus en plus l'attention, le projet GNU comptait un nombre croissant de participants et nous avons décidé qu'il était temps de repartir à la chasse aux fonds pour financer le développement du système d'exploitation GNU. En 1985, j'ai donc intéressé des amis à notre objectif, et ensemble nous avons créé la Free Software Foundation (Fondation pour le logiciel libre), une association à but non lucratif, exemptée d'impôts, pour le développement de logiciels libres. La FSF a aussi pris en charge le commerce de la distribution d'Emacs ; plus tard, elle a étendu cette activité en ajoutant aux bandes d'autres logiciels libres (aussi bien GNU que non GNU) et en vendant des manuels libres.

Au début, les ressources de la FSF provenaient surtout de la vente de copies de logiciels libres et de services annexes (CD-ROM de code source, CD-ROM d'exécutables, manuels joliment imprimés, tout cela en autorisant la redistribution et les modifications) et des distributions Deluxe (distributions pour lesquelles nous compilions une collection de logiciels pour la plateforme choisie par le client). Aujourd'hui la FSF vend encore des manuels et d'autres outils, mais elle obtient l'essentiel de son financement grâce aux cotisations des membres. Vous pouvez adhérer à la FSF sur fsf.org.

Les salariés de la Fondation pour le logiciel libre ont écrit et maintenu un grand nombre de paquets logiciels du projet GNU, en particulier la bibliothèque C et le shell. La bibliothèque C de GNU est ce qu'utilise tout programme fonctionnant sur un système GNU/Linux pour communiquer avec Linux. Elle a été développée par Roland McGrath, membre de l'équipe de la Fondation pour le logiciel libre. Le shell employé sur la plupart des systèmes GNU/Linux est BASH, le Bourne-Again SHell [5], qui a été développé par Brian Fox, salarié de la FSF.

Nous avons financé le développement de ces programmes, car le projet GNU ne se limitait pas aux outils ou à un environnement de développement. Notre but était la mise en place d'un système d'exploitation complet et de tels programmes étaient nécessaires pour l'atteindre.

Assistance technique au logiciel libre

La philosophie du logiciel libre rejette une pratique spécifique, très répandue dans l'industrie du logiciel, mais elle ne s'oppose pas au monde des affaires. Quand des entreprises respectent la liberté des utilisateurs, nous leur souhaitons de réussir.

La vente d'exemplaires d'Emacs représente l'une des formes du commerce fondé sur le logiciel libre. Quand la FSF a récupéré ce commerce, j'ai dû chercher une autre solution pour gagner ma vie. Je l'ai trouvée dans la vente de services associés aux logiciels libres que j'avais développés. Cela consistait à faire des cours sur des sujets comme la programmation de GNU Emacs et la personnalisation de GCC, et à développer du logiciel (essentiellement pour porter GCC sur de nouvelles plateformes).

De nos jours, chacune de ces activités lucratives fondées sur le logiciel libre est pratiquée par de nombreuses sociétés. Certaines distribuent des compilations de logiciels libres sur CD-ROM ; d'autres vendent de l'assistance technique en répondant à des questions d'utilisateurs, en corrigeant des bogues et en insérant de nouvelles fonctionnalités majeures. On commence même à voir des entreprises dont l'objet est la mise sur le marché de nouveaux logiciels libres.

Prenez garde, toutefois : certaines des sociétés qui s'associent à la dénomination « open source »^h fondent en réalité leur activité sur du logiciel privateur qui fonctionne avec du logiciel libre. Ce ne sont pas des entreprises de logiciel libre, ce sont des entreprises de logiciel privateur dont les produits détournent les utilisateurs de leur liberté. Elles les appellent « produits à valeur ajoutée », ce qui reflète quelles valeurs elles souhaitent nous voir adopter : préférer la facilité à la liberté. Si nous faisons passer la liberté au premier plan, il nous faut leur donner le nom de « produits à liberté soustraite ».

Objectifs techniques

L'objectif principal de GNU est d'être libre. Même si GNU ne jouissait d'aucun avantage technique sur Unix, il disposerait d'un avantage sociétal, car il autorise les utilisateurs à coopérer, et d'un avantage éthique, car il respecte la liberté de l'utilisateur.

Mais il était naturel d'appliquer à ce travail les standards bien connus du développement logiciel de qualité en utilisant par exemple des structures de données allouées dynamiquement pour éviter de mettre en place des limites fixées arbitrairement, et en gérant tous les caractères possibles codables sur 8 bits, partout où cela avait un sens.

De plus, nous nous sommes démarqués d'Unix, dont la priorité était la réduction des besoins en mémoire, en décidant de ne pas nous occuper des architectures 16 bits (il était clair que les architectures 32 bits seraient la norme au moment de la finalisation du système GNU) et en ne faisant aucun effort pour réduire la consommation mémoire à moins qu'elle n'excède un mégaoctet. Dans les programmes pour lesquels il n'était pas crucial de manipuler des fichiers de taille importante, nous avons encouragé les programmeurs à lire le fichier en entrée d'une traite, en mémoire centrale, et à analyser ensuite son contenu sans plus se préoccuper des entrées/sorties.

Ces décisions ont rendu de nombreux programmes du projet GNU supérieurs à leurs homologues sous Unix en termes de fiabilité et de vitesse d'exécution.

Des ordinateurs offerts

La réputation du projet GNU croissant, on nous offrait des machines sous Unix pour nous aider à le mener à bien. Elles nous ont été bien utiles, car le moyen le plus facile de développer les composants de GNU était de travailler sur un système Unix dont on remplaçait les composants un par un. Mais cela a posé un problème éthique : était-il correct, pour nous, de posséder ne serait-ce qu'un exemplaire d'Unix ?

Unix était (et demeure) constitué de logiciel privateur, et la philosophie du projet GNU nous demandait de ne pas utiliser de logiciel privateur. Toutefois, en appliquant le raisonnement qui justifie le recours à la violence en situation de légitime défense, je suis arrivé à la conclusion qu'il était légitime d'utiliser un logiciel privateur quand c'était crucial pour développer une solution de remplacement libre qui en aiderait d'autres à se passer de ce même logiciel privateur.

Mais ce mal avait beau être justifiable, il n'en restait pas moins un mal. De nos jours, nous ne possédons plus aucun exemplaire d'Unix, car nous les avons tous remplacés par des systèmes d'exploitation libres. Quand nous ne parvenions pas à substituer au système d'exploitation d'une machine un système libre, nous remplacions la machine.

La GNU Task List, ou liste des tâches du projet GNU

Le projet GNU suivant son cours, on trouvait ou on développait un nombre croissant de composants du système et il est finalement devenu utile de faire la liste des parties manquantes. Nous l'avons utilisée pour recruter des développeurs afin d'écrire ces dernières. Cette liste a pris le nom de GNU task list. En plus des composants manquants d'Unix, nous y avons inscrit plusieurs autres projets utiles, de logiciel et de documentation, que nous jugions indispensables à un système réellement complet.

De nos jours [6], on ne trouve presque plus aucun composant d'Unix dans la liste des tâches du projet GNU – ces travaux ont tous été menés à bien, si l'on néglige certains composants non essentiels. Mais la liste est pleine de projets qu'on pourrait qualifier d'« applications ». Tout programme qui fait envie à une classe pas trop restreinte d'utilisateurs constituerait un ajout utile à un système d'exploitation.

On trouve même des jeux dans la liste des tâches (et c'est le cas depuis le commencement). Unix proposait des jeux, ce devait naturellement être aussi le cas de GNU. Mais il n'était pas nécessaire d'être compatible en matière de jeux, aussi n'avons-nous pas suivi la liste des jeux d'Unix. À la place, nous avons mis sur la liste un assortiment de jeux qui devraient plaire aux utilisateurs.

La GNU Lesser GPL, ou licence publique générale GNU amoindrie

La bibliothèque C de GNU fait appel à un copyleft particulier, appelé « licence publique générale GNU amoindrie », ou GNU LGPL [7], qui autorise la liaison de logiciel privateur avec la bibliothèque. Pourquoi une telle exception ?

Ce n'est pas une question de principe ; aucun principe ne dicte que les logiciels privateurs ont le droit de contenir notre code (pourquoi contribuer à un projet qui affirme refuser de partager avec nous ?) L'utilisation de la LGPL dans le cadre de la bibliothèque C, ou de toute autre bibliothèque, est un choix stratégique.

La bibliothèque C joue un rôle générique ; tout système privateur, tout compilateur, dispose d'une bibliothèque C. C'est pourquoi limiter l'utilisation de la nôtre au logiciel libre n'aurait donné aucun avantage au logiciel libre ; cela n'aurait eu pour effet que de décourager l'utilisation de notre bibliothèque.

Il existe une exception à cette règle : sur le système GNU (et cela comprend GNU/Linux), la bibliothèque C de GNU est la seule disponible. Aussi, ses conditions de distribution déterminent s'il est possible de compiler un programme privateur sur le système GNU. Il n'existe aucune raison éthique d'autoriser des applications privatrices sur le système GNU, mais d'un point de vue stratégique, il semble que les interdire découragerait plus l'utilisation du système GNU que cela n'encouragerait le développement d'applications libres. C'est pourquoi l'utilisation de la LGPL est une bonne stratégie pour la bibliothèque C.

En ce qui concerne les autres bibliothèques, il faut prendre la décision stratégique au cas par cas. Quand une bibliothèque remplit une tâche particulière qui peut faciliter l'écriture de certains types de programmes, la publier sous les conditions de la GPL, en limitant son utilisation aux programmes libres, est une manière d'aider les développeurs de logiciels libres et de leur accorder un avantage sur le logiciel privateur.

Considérons GNU Readline, une bibliothèque développée pour l'édition des commandes dans BASH. Cette bibliothèque est distribuée sous la GNU GPL et non pas sous la LGPL. L'effet probable est de réduire l'utilisation de la bibliothèque Readline, mais cela ne représente pas une perte pour nous. En attendant, on compte au moins une application utile qui a été libérée uniquement dans le but de pouvoir utiliser la bibliothèque Readline, et c'est là un gain réel pour la communauté.

Les développeurs de logiciel privateur jouissent des avantages que leur confère l'argent ; les développeurs de logiciel libre doivent compenser cela en s'épaulant les uns les autres. J'espère qu'un jour nous disposerons de toute une collection de bibliothèques sous GPL, pour lesquelles il n'existera pas d'homologue privateur. Nous disposerons ainsi de modules pouvant être utilisés comme composants dans de nouveaux programmes libres, ce qui favorisera considérablement la poursuite du développement de logiciel libre.

Gratter là où ça démange ?

Éric Raymond affirme que « Tout bon logiciel commence par gratter un développeur là où ça le démange. » Cela se produit peut-être, parfois, mais de nombreux composants essentiels de GNU ont été développés dans le but de disposer d'un système d'exploitation libre complet. Ils ont été inspirés par une vision et un projet à long terme, pas par un coup de tête.

Nous avons par exemple développé la bibliothèque C de GNU, car un système de type Unix a besoin d'une bibliothèque C ; BASH, car un système de type Unix a besoin d'un shell ; et GNU tar, car un système de type Unix a besoin d'un programme d'archivage. Il en va de même pour les programmes que j'ai développés, à savoir le compilateur C de GNU, GNU Emacs, GDB et GNU Make.

Certains programmes GNU ont été développés pour répondre aux menaces qui pesaient sur notre liberté. C'est ainsi que nous avons développé gzip en remplacement du programme Compress, que la communauté avait perdu suite aux brevets logiciels déposés sur LZW. Nous avons trouvé des gens pour développer LessTif, et plus récemment nous avons démarré les projets GNOME et Harmony en réponse aux problème posés par certaines bibliothèques privatrices (lire ci-après). Nous sommes en train de développer GNU Privacy Guard (GPG) pour remplacer un logiciel de chiffrement populaire mais non libre, car les utilisateurs ne devraient pas avoir à choisir entre la préservation de leur vie privée et la préservation de leur liberté.

Bien sûr, les gens qui écrivent ces programmes se sont intéressés à ce travail et de nombreux contributeurs ont ajouté de nouvelles fonctionnalités pour satisfaire leurs besoins ou leurs intérêts. Mais ce n'est pas là la raison première de ces programmes.

Des développements inattendus

Au commencement du projet GNU, j'ai imaginé que nous développerions le système GNU dans sa globalité avant de le publier. Les choses se sont passées différemment.

Puisque chaque composant du système GNU était implémenté sur un système Unix, chaque composant pouvait être exécuté sur des systèmes Unix bien avant que le système GNU ne soit disponible dans sa globalité. Certains de ces programmes sont devenus populaires et leurs utilisateurs ont commencé à travailler sur des extensions et des portages – sur les diverses versions incompatibles d'Unix et parfois aussi sur d'autres systèmes.

Ce processus a rendu ces programmes bien plus complets et a drainé des fonds et des participants vers le projet GNU. Mais il a probablement eu également pour effet de retarder de plusieurs années la mise au point d'un système en état de fonctionnement, puisque les développeurs du projet GNU passaient leur temps à s'occuper de ces portages et à ajouter de nouvelles fonctionnalités aux composants existants, plutôt que de continuer à développer peu à peu les composants manquants.

Le GNU Hurd

En 1990, le système GNU était presque terminé ; le seul composant principal qui manquait encore à l'appel était le noyau. Nous avions décidé d'implémenter le noyau sous la forme d'une série de processus serveurs qui fonctionneraient au-dessus de Mach. Mach est un micronoyau qui a été développé à l'université Carnegie-Mellon, puis à l'université d'Utah ; le GNU Hurd est une série de serveurs (une « horde de gnous ») qui fonctionnent au-dessus de Mach et remplissent les diverses fonctions du noyau Unix. Le développement a été retardé, car nous attendions que Mach soit publié sous forme de logiciel libre comme on nous l'avait promis.

L'une des raisons qui ont dicté ce choix était d'éviter ce qui semblait être la partie la plus difficile du travail : déboguer un programme de noyau sans disposer pour cela d'un débogueur au niveau du code source. Ce travail avait déjà été fait, dans Mach, et nous pensions déboguer les serveurs du Hurd en tant que programmes utilisateur, à l'aide de GDB. Mais cela prit beaucoup de temps et les serveurs à plusieurs fils d'exécution [multithreaded servers], qui s'envoyaient des messages les uns aux autres, se sont révélés très difficiles à déboguer. Il a fallu de nombreuses années pour faire fonctionner le Hurd de manière robuste.

Alix

À l'origine, le noyau du système GNU n'était pas censé s'appeler Hurd. Son premier nom était Alix – du nom de celle qui à l'époque était l'objet de ma flamme. Administratrice de systèmes Unix, elle avait fait remarquer que son prénom ressemblait aux noms typiques des versions de systèmes Unix ; elle s'en était ouverte auprès d'amis en plaisantant : « Il faudrait baptiser un noyau de mon nom. » Je n'ai rien dit, mais ai décidé de lui faire la surprise avec un noyau appelé Alix.

Mais les choses ont changé. Michael Bushnell (maintenant, il s'appelle Thomas), le développeur principal du noyau, préférait le nom Hurd et a confiné le nom Alix à une certaine partie du noyau – la partie qui se chargeait d'intercepter les appels système et de les gérer en envoyant des messages aux serveurs du Hurd.

Plus tard, Alix et moi mîmes fin à notre relation et elle a changé de nom ; de manière indépendante, le concept du Hurd avait évolué de telle sorte que ce serait la bibliothèque C qui enverrait directement des messages aux serveurs, ce qui a fait disparaître le composant Alix du projet.

Mais avant que ces choses ne se produisent, un de ses amis avait remarqué le nom d'Alix dans le code source du Hurd et s'en était ouvert auprès d'elle. Elle a donc finalement eu l'occasion de découvrir un noyau à son nom.

Linux et GNU/Linux

GNU Hurd n'est pas encore utilisable en production et nous ne savons pas s'il le sera un jour. Son architecture basée sur les fonctionnalités [capability-based design] a des problèmes provenant directement de la flexibilité de cette architecture et il n'est pas sûr que des solutions existent.

Heureusement, on dispose d'un autre noyau. En 1991, Linus Torvalds a développé un noyau compatible avec Unix et lui a donné le nom de Linux. Au début c'était un logiciel privateur, mais en 1992 il l'a rendu libre ; la jonction de Linux avec le système GNU, qui était presque complet, a donné un système d'exploitation libre et complet (ce travail de jonction était lui-même, bien sûr, considérable). C'est grâce à Linux qu'on peut désormais employer une version du système GNU.

Nous appelons cette version du système GNU/Linux, pour indiquer le fait que c'est une combinaison du système GNU avec le noyau Linux. Je vous en prie, ne vous laissez pas aller à appeler le système complet « Linux », puisque cela équivaudrait à attribuer notre travail à quelqu'un d'autre. Merci de nous mentionner de manière équivalente.

Les défis à venir

Nous avons fait la preuve de notre capacité à développer une large gamme de logiciels libres. Cela ne signifie pas que nous sommes invincibles et que rien ne peut nous arrêter. Certains défis rendent incertain l'avenir du logiciel libre ; pour les relever il faudra des efforts et une endurance soutenus, sur des années parfois. Il faudra montrer le genre de détermination dont les gens font preuve quand ils accordent de la valeur à leur liberté et qu'ils ne laisseront personne la leur voler.

Les quatre sections suivantes discutent de ces défis.

Le matériel secret

Les fabricants de matériel tendent de plus en plus à garder leurs spécifications secrètes. Cela rend plus difficile l'écriture de pilotes de périphériques libres afin de permettre à Linux et au projet XFree86 de reconnaître de nouveaux matériels. Nous disposons aujourd'hui de systèmes entièrement libres, mais cela ne sera plus le cas à l'avenir si nous ne pouvons pas gérer les ordinateurs de demain.

On peut résoudre ce problème de deux manières. Les programmeurs peuvent faire de la rétroingénierie pour comprendre comment gérer le matériel. Les autres peuvent choisir le matériel qui est reconnu par du logiciel libre ; plus nous serons nombreux, plus la politique du secret sur les spécifications sera vouée à l'échec.

La rétroingénierie est un travail considérable ; disposerons-nous de programmeurs suffisamment déterminés pour le prendre en main ? Oui – si nous sommes intimement persuadés que le logiciel libre est une question de principe et que les pilotes non libres sont inacceptables. Et serons-nous nombreux à dépenser un peu plus d'argent, ou à passer un peu plus de temps, afin d'utiliser des pilotes libres ? Oui, si la détermination à revendiquer la liberté se généralise [8].

Les bibliothèques non libres

Une bibliothèque non libre qui fonctionne sur des systèmes d'exploitation libres se comporte comme un piège vis-à-vis des développeurs de logiciel libre. Les fonctionnalités attrayantes de cette bibliothèque sont l'appât ; si vous l'utilisez, vous tombez dans le piège car votre programme ne peut pas faire partie utilement d'un système d'exploitation libre (en toute rigueur, on pourrait y inclure le programme, mais on ne pourrait pas l'exécuter en l'absence de la bibliothèque). Pire encore, si un programme qui utilise une bibliothèque privatrice devient populaire, il peut attirer dans le piège d'autres programmeurs peu soupçonneux.

Ce problème s'est posé pour la première fois avec la boîte à outils Motif, dans les années 80. Même s'il n'existait pas encore de systèmes d'exploitation libres, le problème que Motif leur causerait plus tard était évident. Le projet GNU a réagi de deux manières : en demandant aux projets de logiciel libre d'utiliser les widgets de la boîte à outils libre X Toolkit en parallèle avec Motif et en recherchant un volontaire pour donner un remplaçant libre à Motif. Ce travail prit de nombreuses années ; il a fallu attendre 1997 pour que LessTif, développé par The Hungry Programmers (les Programmeurs affamés), devienne capable de faire fonctionner la plupart des applications utilisant Motif.

Entre 1996 et 1998, une autre boîte à outils non libre pour interface graphique, nommée Qt, a été utilisée dans une importante collection de logiciels libres, l'environnement de bureau KDE.

Les systèmes GNU/Linux libres ne pouvaient pas utiliser KDE, car nous ne pouvions pas utiliser cette bibliothèque. Cependant, certains distributeurs commerciaux de systèmes GNU/Linux n'ont pas été assez stricts dans leur respect des règles du logiciel libre et ont ajouté KDE dans leurs systèmes, ce qui en augmentait les capacités mais en réduisait la liberté. Le groupe KDE encourageait activement de plus en plus de programmeurs à utiliser Qt et des millions de « nouveaux utilisateurs de Linux » n'avaient jamais été avertis du fait que tout ceci posait problème. La situation semblait désespérée.

La communauté du logiciel libre a répondu à ce problème de deux manières : GNOME et Harmony.

GNOME est le projet de bureau de GNU. Démarré en 1997 par Miguel de Icaza et développé avec l'aide de la société Red Hat Software, GNOME avait pour but de fournir des fonctionnalités de bureau similaires en utilisant exclusivement du logiciel libre. Il jouit aussi d'avantages techniques, comme de gérer toute une variété de langages, pas seulement le C++. Mais son objectif principal est la liberté : ne pas imposer l'utilisation du moindre logiciel non libre.

Harmony est une bibliothèque compatible de remplacement, conçue pour permettre l'utilisation des logiciels de KDE sans faire appel à Qt.

En novembre 1998, les développeurs de Qt ont annoncé une modification de leur licence qui, une fois effective, devrait faire de Qt un logiciel libre. On ne peut pas en être sûr, mais je pense que cette décision est en partie imputable à la réponse ferme de la communauté au problème que posait Qt lorsqu'il n'était pas libre (la nouvelle licence n'est pas pratique ni équitable, aussi demeure-t-il préférable d'éviter l'utilisation de Qt [9]).

Comment répondrons-nous à la prochaine bibliothèque non libre mais alléchante ? La communauté entière comprendra-t-elle la nécessité de ne pas tomber dans le piège ? Ou serons-nous nombreux à préférer la facilité à la liberté, ce qui donnera lieu à un autre problème majeur ? Notre avenir dépend de notre philosophie.

Les brevets logiciels

La pire menace provient des brevets logiciels, susceptibles de placer des algorithmes et des fonctionnalités hors de portée du logiciel libre pendant une période qui peut atteindre vingt ans. Les brevets sur l'algorithme de compression LZW ont été déposés en 1983 et nous ne pouvons toujours pas diffuser de logiciel libre qui produise des images au format GIF correctement compressées [10]. En 1998, la menace d'une poursuite pour cause de violation de brevets a mis fin à la distribution d'un programme libre qui produisait des données sonores compressées au format MP3 [11].

Il existe plusieurs manières de faire face au problème des brevets : on peut rechercher des preuves qu'un brevet est invalide, ou chercher d'autres solutions pour remplir une tâche particulière. Mais chacune de ces méthodes ne fonctionne que de temps en temps ; quand elles échouent toutes les deux, un seul brevet peut mettre la totalité des logiciels libres dans l'impossibilité d'offrir aux utilisateurs une fonctionnalité qu'ils souhaitent. Après une longue attente, les brevets finissent par expirer, mais que devons-nous faire d'ici là ?

Ceux d'entre nous qui apprécient le logiciel libre pour la liberté qu'il leur donne continueront à l'utiliser de toute façon. On pourra travailler sans utiliser les fonctionnalités brevetées. Mais ceux d'entre nous qui apprécient le logiciel libre parce qu'ils s'attendent à ce qu'il soit techniquement supérieur diront probablement qu'il ne vaut rien, le jour où un brevet l'empêchera de progresser plus avant. Ainsi, même s'il est utile de parler de l'efficacité sur le plan pratique du développement de type « bazar », ainsi que de la fiabilité et de la puissance de certains logiciels libres, il ne faut pas s'en tenir là. Il nous faut parler de liberté et de principes.

La documentation libre

Il ne faut pas chercher les défauts les plus graves de nos systèmes d'exploitation libres dans le logiciel; c'est l'absence de bons manuels libres qu'on puisse inclure dans nos systèmes qui se fait le plus cruellement sentir. La documentation est essentielle dans tout paquet logiciel ; quand un paquet logiciel important ne dispose pas d'un bon manuel libre, il s'agit d'une lacune majeure. On en compte de nombreuses aujourd'hui.

La documentation libre, tout comme le logiciel libre, est une question de liberté, pas de prix. La définition d'un manuel libre est très proche de celle du logiciel libre : il s'agit d'offrir certaines libertés à tous les utilisateurs. Il faut autoriser la redistribution (y compris la vente commerciale), en ligne et sur papier, de telle sorte que le manuel puisse accompagner chaque copie du programme.

Il est également crucial d'autoriser les modifications. En règle générale, je ne pense pas qu'il soit essentiel d'autoriser tout un chacun à modifier toutes sortes d'articles et de livres. Je ne pense pas, par exemple, que vous ou moi soyons tenus de donner la permission de modifier des textes comme le présent article, qui expose nos actions et nos idées.

Mais il existe une raison particulière pour laquelle il est crucial de disposer de la liberté de modifier la documentation relative au logiciel libre. Quand un programmeur exerce son droit de modifier le logiciel et d'ajouter ou modifier des fonctionnalités, s'il est consciencieux il mettra immédiatement à jour le manuel (afin de fournir une documentation précise et utilisable aux côtés du programme modifié). Un manuel qui n'autorise pas les programmeurs à être consciencieux et à terminer leur travail ne couvre pas les besoins de notre communauté.

Il n'y a pas de problème à poser certaines limites à la manière dont les modifications sont faites. On peut accepter, par exemple, l'obligation de conserver l'avis de copyright de l'auteur original, les conditions de distribution, ou la liste des auteurs. Il n'y a pas non plus de problème à exiger que les versions modifiées contiennent un avis indiquant qu'elles ont été modifiées, voire à interdire de modifier ou d'ôter des sections entières, pourvu que ces sections ne traitent pas de sujets techniques. En effet cela n'interdit pas au programmeur consciencieux d'adapter le manuel afin qu'il corresponde au programme modifié par ses soins. En d'autres termes, cela n'empêche pas la communauté du logiciel libre d'utiliser pleinement le manuel.

En revanche, il faut autoriser la modification des portions techniques du manuel et la distribution du résultat de ces modifications par tous les médias habituels, à travers tous les canaux habituels ; sans quoi, les restrictions sont un véritable obstacle pour la communauté : le manuel n'est pas libre et il nous en faut un autre.

Les développeurs de logiciel libre auront-ils conscience qu'il nous faut un assortiment complet de manuels libres, seront-ils assez déterminés pour les produire ? Une fois de plus, notre avenir dépend de notre philosophie.

Il nous faut parler de la liberté

On estime aujourd'hui à dix millions le nombre d'utilisateurs de systèmes GNU/Linux tels que Debian GNU/Linux et Red Hat « Linux » de par le monde. Le logiciel libre propose tant d'avantages pratiques que les utilisateurs s'y ruent pour des raisons purement pratiques.

Cet état de fait a des conséquences heureuses, qui n'échapperont à personne : le logiciel libre attire plus de développeurs, les entreprises du logiciel libre ont plus de clients et il est plus facile d'encourager les sociétés à développer des logiciels libres commerciaux, plutôt que des logiciels privateurs.

Mais l'intérêt pour le logiciel libre croît plus vite que la prise de conscience de la philosophie sur laquelle il se fonde, et cela crée des difficultés. Notre capacité à relever les défis et à répondre aux menaces évoquées plus haut dépend de notre volonté de défendre énergiquement notre liberté. Pour faire en sorte que notre communauté partage cette volonté, il nous faut diffuser ces idées auprès des nouveaux utilisateurs au fur et à mesure qu'ils rejoignent notre communauté.

Mais nous négligeons ce travail ; on dépense bien plus d'efforts pour attirer de nouveaux utilisateurs dans notre communauté qu'on n'en dépense pour leur enseigner le civisme qui lui est attaché. Ces deux efforts sont nécessaires et il nous faut les équilibrer.

« Open Source »

En 1998, il est devenu plus difficile de sensibiliser les nouveaux utilisateurs à la notion de liberté, quand une portion de notre communauté a choisi d'arrêter d'utiliser le terme « logiciel libre » pour lui préférer la dénomination « logiciel open source ».

Certains de ceux qui ont choisi ce nouveau nom avaient en tête de mettre fin à la confusion souvent constatée entre les mots free et gratis – ce qui est un objectif valable. D'autres, au contraire, cherchaient à laisser tomber l'attachement aux principes qui avait toujours motivé le mouvement du logiciel libre et le projet GNU, afin de cibler les cadres et les utilisateurs professionnels, dont beaucoup ont une idéologie où la liberté, la communauté et les principes cèdent le pas au profit. Ainsi, la rhétorique de l'open source met l'accent sur le potentiel de faire du logiciel puissant et de grande qualité, mais occulte les notions de liberté, de communauté et de principes.

Les magazines « Linux » illustrent clairement cet exemple (ils sont bourrés de publicités pour des logiciels privateurs qui fonctionnent sur GNU/Linux). Quand le prochain Motif ou Qt poindra, ces magazines mettront-ils les programmeurs en garde en leur demandant de s'en éloigner, ou passeront-ils des publicités pour ces produits ?

La communauté a beaucoup à gagner de la participation des entreprises ; toutes choses étant égales par ailleurs, cette contribution est utile. Mais sacrifier à cette aide les discours traitant de liberté et de principes peut avoir des conséquences désastreuses ; cela augmente le déséquilibre mentionné précédemment entre le recrutement de nouveaux utilisateurs et leur l'éducation civique.

Les termes « logiciel libre » et « open source » décrivent tous deux plus ou moins la même catégorie de logiciel, mais ne disent pas la même chose sur le logiciel et les valeurs qui lui sont associées. Le projet GNU continue d'utiliser le terme « logiciel libre » pour exprimer l'idée que la liberté est plus importante que la seule technique.

Jetez-vous à l'eau

L'aphorisme de Yoda « There is no ‘try’ »ⁱ est séduisant, mais il ne s'applique pas à moi. J'ai effectué la plupart de mes travaux sans savoir si j'étais capable de les mener à bien et sans savoir si ces derniers, une fois menés à bien, atteindraient les buts que je leur avais fixés. Mais j'ai tenté ma chance, car il n'y avait personne d'autre que moi entre l'ennemi et ma cité. À ma grande surprise, j'ai parfois réussi.

J'ai parfois échoué ; certaines de mes cités sont tombées. Je trouvais alors une autre cité menacée et je me préparais pour une nouvelle bataille. Avec le temps, j'ai appris à reconnaître les menaces et à m'interposer entre ces dernières et ma cité, en appelant mes amis hackers à la rescousse.

Maintenant, il arrive souvent que je ne sois pas seul. C'est pour moi un soulagement et une joie de constater que tout un régiment de hackers se mobilise pour faire front et je réalise que cette cité a une chance de survivre – pour le moment. Mais les dangers sont plus grands chaque année, et maintenant la société Microsoft a explicitement pris notre communauté dans son collimateur. L'avenir de la liberté n'est pas un fait acquis. Ne le considérez pas comme tel ! Si vous souhaitez conserver votre liberté, vous devez être prêts à la défendre.

Notes

1. L'utilisation du mot « hacker » dans le sens de « casseur de systèmes de sécurité », est un amalgame instillé par les mass media. Nous autres hackers refusons de reconnaître cette signification et continuons de donner à ce mot le sens de « celui qui aime programmer ou qui prend plaisir à exercer son ingéniosité de façon ludique ».^a Consultez mon article « On Hacking ».
   Les machines PDP étaient particulièrement propices au bidouillage, parce qu'elles étaient généralistes, complètement interactives contrairement aux gros ordinateurs centraux, et permettaient le partage du logiciel et de l'information.
2. En tant qu'athée, je ne suis les pas d'aucun guide spirituel, mais j'admire parfois ce qu'a dit l'un d'entre eux.
3. En 1984 ou 1985, Don Hopkins (dont l'imagination était sans bornes) m'a envoyé une lettre. Il avait écrit sur l'enveloppe plusieurs phrases amusantes et notamment celle-ci : Copyleft – all rights reversed.^f J'ai utilisé le mot « copyleft » pour donner un nom au concept de distribution que je développais alors.
4. Nous utilisons maintenant la licence GNU de documentation libre (GNU FDL) pour la documentation.
5. Bourne-Again Shell ^g est un clin d'œil au nom Bourne Shell, qui était le shell habituel sur Unix.
6. Cela a été écrit en 1998. Depuis 2009, nous ne tenons plus à jour cette longue liste de tâches. La communauté développe des logiciels libres tellement vite que nous ne pouvons même pas les suivre tous. En revanche, nous avons une liste des projets à haute priorité – liste bien plus courte de projets dont nous souhaitons vivement qu'ils soient menés à bien.
7. Cette licence s'appelait initialement la GNU Library General Public License (licence publique générale GNU pour les bibliothèques). Nous l'avons renommée pour ne pas laisser penser que toutes les bibliothèques doivent l'utiliser. Consultez l'article Pourquoi vous ne devriez pas utiliser la LGPL pour votre prochaine bibliothèque pour plus d'informations.
8. Note de 2008 : ce problème s'applique également au BIOS. Il existe un BIOS libre, LibreBoot (une distribution de coreboot) ; le problème est d'obtenir les spécifications des machines pour que LibreBoot puisse les gérer sans recourir à des « blobs » non libres.
9. En septembre 2000, Qt a été republiée sous la GNU GPL, ce qui pour l'essentiel a résolu le problème.
10. Les brevets sur GIF ont expiré en 2009.
11. Les brevets sur MP3 ont expiré en 2017. Regardez combien de temps il a fallu attendre.