|
Ténors de l'Informatique Libre Copyright © 1999 par Éditions O'Reilly
Chapitre 4. Le système d'exploitation du projet GNU et le mouvement du logiciel libreRichard Stallman
La première communauté qui partageait le logicielEn 1971, quand j'ai commencé à travailler au laboratoire d'intelligence artificielle (IA) du MIT [1], 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 on partage des recettes depuis les débuts de la cuisine. Mais nous partagions davantage que la plupart. Le laboratoire d'IA utilisait un système d'exploitation à temps partagé appelé ITS (Incompatible Timesharing System, ou système à temps partagé incompatible) que les hackers [2] de l'équipe avaient écrit et mis au point en langage d'assemblage pour le Digital PDP-10, l'un des grands ordinateurs de l'époque. En tant que membre de cette communauté, hacker système de l'équipe du laboratoire 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 quand des ingénieurs souhaitaient utiliser et porter l'un de nos programmes, nous les laissions volontiers faire. Et quand on remarquait que quelqu'un utilisait un programme intéressant mais inconnu, 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 s'est modifiée de manière drastique au début des années 1980 quand la société Digital™ a mis fin à la série des PDP-10. Cette architecture, élégante et puissante dans les années 60, ne pouvait pas s'étendre naturellement aux plus grands espaces d'adressage qu'on trouvait dans les années 80. Cela rendait obsolètes la quasi-totalité des programmes constituant ITS. La communauté des hackers du laboratoire 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 de temps partagé de la société Digital™, qui n'était pas libre. Les ordinateurs modernes d'alors, tels que le VAX ou le 68020, disposaient de leurs propres systèmes d'exploitation, mais aucun d'entre eux n'était un logiciel libre : il fallait signer un accord de non divulgation pour en obtenir ne serait-ce que des copies exécutables. Cela signifiait que la première étape de l'utilisation d'un ordinateur était de promettre de ne pas aider son prochain. On interdisait toute communauté coopérative. La règle qu'édictaient ceux qui détenaient le monopole d'un logiciel propriétaire é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 propriétaire — le système qui vous interdit de partager ou d'échanger le logiciel — est antisocial, immoral, et qu'il est tout bonnement incorrect, 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 propriétaire pour argent comptant, ou l'ont jugé en employant les termes suggérés par les entreprises vivant de logiciels propriétaires. Les éditeurs de logiciels travaillent durement, et depuis longtemps, pour 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 », le contenu réel de leur discours passe au second plan. 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 logiciels 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, qui restreint le droit naturel qu'ont les utilisateurs de copier le logiciel. Une autre hypothèse sous-jacente est que seules importent les fonctionnalités du logiciel — et que les utilisateurs d'ordinateurs n'ont pas leur mot à dire quant au modèle de société qu'ils souhaitent voir mettre en place. 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 on ne garantissait pas à une société 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 si on examine ces questions en se fondant sur une moralité dictée par le bon sens, qui place les utilisateurs au premier plan, on parvient à des conclusions bien différentes. Les utilisateurs des ordinateurs doivent être libres de modifier les programmes pour qu'ils répondent mieux à leurs besoins, et libres de partager le logiciel, car 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 au document web Why Software Should Not Have Owners (pourquoi le logiciel ne devrait appartenir à personne). Une profonde prise de décisionAvec la fin de ma communauté, il m'était impossible de continuer comme de par le passé. J'étais au lieu de cela confronté à une profonde prise de décision. La solution de facilité était de rejoindre le monde du logiciel propriétaire, de signer des accords de non divulgation et promettre ainsi de ne pas aider mon ami hacker. J'aurais aussi été, très probablement, amené à développer du logiciel qui aurait été publié en fonction d'exigences de non divulgation, augmentant la pression qui en inciterait d'autres à trahir également leurs semblables. J'aurais pu gagner ma vie de cette manière, et peut-être me serais-je même amusé à écrire du code. Mais je savais qu'à la fin de ma carrière, je n'aurais à contempler que des années de construction de murs pour séparer les gens, et que j'aurais l'impression d'avoir employé ma vie à rendre le monde pire. J'avais déjà eu l'expérience douloureuse des accords de non divulgation, quand quelqu'un m'avait refusé, ainsi qu'au laboratoire 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 accords de non divulgation étaient bénins. J'avais été très fâché du refus de cette personne de partager avec nous ; je ne pouvais pas, moi aussi, me comporter d'une telle manière à 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 et de restreindre les droits des utilisateurs d'ordinateurs, 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 ouvre de nombreuses portes ; sans système, l'ordinateur est inexploitable. Un système d'exploitation libre rendrait à nouveau possible une communauté de hackers, travaillant en mode coopératif — et tout un chacun serait invité à participer. Et tout un chacun pourrait utiliser un ordinateur sans devoir adhérer à une conspiration visant à priver ses amis des logiciels qu'il utilise. 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, j'ai pensé être le candidat de choix pour ce travail. J'ai décidé de rendre le système compatible avec Unix™ de manière à le rendre portable, et pour le rendre plus accessible aux utilisateurs d'Unix™. 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). Un système d'exploitation ne se limite pas à un noyau, qui suffit à peine à exécuter d'autres programmes. Dans les années 1970, tout système d'exploitation digne de ce nom disposait d'interpréteurs de commandes, d'assembleurs, de compilateurs, d'interpréteurs, de débogueurs, d'éditeurs de textes, de logiciels de courrier électronique, pour ne citer que quelques exemples. 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 [3] [4] :
C'est dans cet état d'esprit que j'ai pris la décision de lancer le projet GNU. Free comme libertéParfois [5], le terme « free software » est mal compris — il n'a rien à voir avec le prix. Il parle de liberté. Voici donc la définition d'un logiciel libre : un programme est un logiciel libre pour vous, utilisateur en particulier, si :
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é, et 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 logiciel libre un logiciel qu'on n'a pas la liberté d'inclure dans de telles compilations. Le mot « free » étant ambigu, on a longtemps cherché des solutions de remplacement, mais personne n'en a trouvé de convenable. 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ésentant tous un sens incorrect ou un autre inconvénient. Les logiciels et le système du projet GNUC'est une gageure que de développer un système complet. Pour mener ce projet à 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 de fenêtrage X plutôt que d'écrire un autre système de fenêtrage pour le projet GNU. Cette décision 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 projetEn janvier 1984, j'ai démissionné de mon poste au MIT et j'ai commencé à écrire les logiciels du projet GNU. Il était nécessaire que je quitte le MIT pour empêcher ce dernier de s'immiscer dans la distribution du projet GNU en tant que logiciel libre. Si j'étais resté dans l'équipe, le MIT aurait pu se déclarer le propriétaire de mon travail, et lui imposer ses propres conditions de distribution, voire en faire un paquetage de logiciels propriétaires. Je n'avais pas l'intention d'abattre autant de travail et de le voir rendu inutilisable pour ce à quoi il était destiné : créer une nouvelle communauté qui partage le logiciel. Cependant, le professeur Winston, qui dirigeait alors le laboratoire d'IA du MIT, m'a gentiment invité à continuer à utiliser les équipements du laboratoire. Les premiers pasPeu de temps avant de me lancer dans le projet GNU, j'avais entendu parler du Free University Compiler Kit [6], plus connu sous le nom de VUCK (en hollandais, le mot « free » commence par un V). Ce compilateur avait été mis au point dans l'intention de traiter 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 » [7], mais pas le compilateur. J'ai alors décidé que le premier programme du projet GNU serait un compilateur traitant de plusieurs langages, sur plusieurs plates-formes. 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 était un compilateur pour plusieurs plates-formes, développé au laboratoire Lawrence Livermore. Il compilait, et c'était aussi le langage dans lequel il avait été écrit, une version étendue de Pascal, mise au point pour jouer le rôle de langage de programmation système. 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 que ce compilateur ne fonctionnait qu'avec plusieurs méga-octets d'espace de pile disponibles, alors que le système Unix du 68000 ne gérait que 64 Ko d'espace de pile. C'est alors que j'ai compris que le compilateur Pastel avait été mis au point de telle manière qu'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 occupé. J'ai alors compris qu'il me faudrait réécrire un nouveau compilateur en partant de zéro. Ce compilateur est maintenant disponible, il s'appelle GCC ; il n'utilise rien du compilateur Pastel, mais j'ai réussi à adapter et à réutiliser l'analyseur syntaxique que j'avais écrit pour le C. Mais tout cela ne s'est produit que quelques années plus tard ; j'ai d'abord travaillé sur GNU Emacs. GNU EmacsJ'ai commencé à travailler sur GNU Emacs en septembre 1984, et ce programme commençait à devenir utilisable début 1985. Cela m'a permis d'utiliser des systèmes Unix pour éditer mes fichiers ; vi et ed me laissant froid, j'avais jusqu'alors utilisé d'autres types de machines pour éditer mes fichiers. 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 proposé sur le serveur ftp de l'ordinateur du MIT que j'utilisais (cet ordinateur, prep.ai.mit.edu, a ainsi été promu au rang de site de distribution par ftp principal 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'avaient pas d'accès à l'Internet et ne pouvaient pas obtenir une 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 fera une copie. » J'aurais pu également procéder comme j'avais procédé avec la version originale d'Emacs, sur PDP-10, et leur dire : « Envoyez-moi une bande et une enveloppe timbrée auto-adressée, et 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 USD. De cette manière, je mettais en place une entreprise autour du marché de la distribution du logiciel libre, entreprise précurseur des sociétés qu'on trouve aujourd'hui et qui distribuent des systèmes GNU entiers fondés sur Linux. 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. Le logiciel relevant du domaine public, par exemple (qui ne tombe sous le coup d'aucun copyright), est du logiciel libre ; mais tout un chacun peut en produire une version propriétaire 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 et propriétaires. L'exemple le plus frappant de ce problème est le système de fenêtrage X. Développé au MIT, et distribué sous forme de logiciel libre sous une licence permissive, il a rapidement été adopté par divers constructeurs. Ils ont ajouté X à leurs systèmes Unix™ propriétaires, sous forme binaire uniquement, en le frappant du même accord de non divulgation. Ces exemplaires de X n'étaient en rien du logiciel plus libre que le reste d'Unix™. Les développeurs du système de fenêtrage X 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 leurs utilisateurs, seul leur nombre revêtait de l'importance à leurs yeux. Cela a conduit à une situation paradoxale, où deux différentes façons d'évaluer la liberté répondaient de manières différente à la question « Ce programme est-il libre ? » Qui fondait son jugement sur la liberté fournie par les conditions de distribution de la distribution 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 propriétaire. La plupart des utilisateurs de X exécutaient des versions propriétaires fournies avec des systèmes Unix™, et non la version libre. Le copyleft et la GPL de GNULe but du projet GNU était de rendre les utilisateurs libres, pas de se contenter d'être populaire. Nous avions besoins de conditions de distribution qui empêcheraient de transformer du logiciel GNU en logiciel propriétaire. Nous avons utilisé la méthode du copyleft [8], ou « gauche d'auteur ». Le gauche d'auteur utilise les lois du droit d'auteur, en les retournant pour leur faire servir le but opposé de ce pour quoi elles ont été conçues : ce n'est pas une manière de privatiser du logiciel, mais une manière de le laisser « libre ». L'idée centrale du gauche d'auteur est de donner à quiconque 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 cruciales qui définissent le « logiciel libre » sont garanties pour quiconque en possède une copie ; elles deviennent des droits inaliénables. Pour que le gauche d'auteur 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 à la communauté en cas de publication. Quand des programmeurs professionnels se portent volontaires pour améliorer le logiciel GNU, c'est le gauche d'auteur qui empêche leurs employeurs de dire : « Vous ne pouvez pas partager ces modifications, car nous allons les utiliser dans le cadre de notre version propriétaire du programme. » Il est essentiel d'imposer que les modifications restent libres si on souhaite garantir la liberté de tout utilisateur du programme. Les sociétés qui ont privatisé le système de fenêtrage X faisaient en général quelques modifications pour le porter sur leurs systèmes 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 faciles. Si le fait de procéder à des modifications pouvait servir de prétexte à ôter leur liberté aux utilisateurs, il serait facile pour quiconque de s'en servir à son avantage. 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 cette compilation. Autoriser de telles pratiques ouvrirait une voie d'eau suffisante pour couler le navire. C'est pourquoi il est crucial pour le gauche d'auteur d'exiger qu'un programme couvert par le gauche d'auteur ne puisse pas être inclus dans une version plus grande sans que cette dernière ne soit également couverte par le gauche d'auteur. L'implémentation spécifique du gauche d'auteur que nous avons utilisée pour la plupart des logiciels GNU fut la GNU General Public License (licence publique générale de GNU), ou GNU GPL en abrégé. Nous disposons d'autres types de gauche d'auteur pour des circonstances particulières. Les manuels du projet GNU sont eux aussi couverts par le gauche d'auteur, 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. La Free Software Foundation, ou fondation du logiciel libreEmacs 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. En 1985, nous avons donc créé la fondation du logiciel libre (FSF), une association à but non lucratif, exemptée d'impôts, pour le développement de logiciel libre. La FSF a récupéré le marché de la distribution de logiciel libre sur bandes, auxquelles elle ajouta ensuite d'autres logiciels libres (GNU ou non), et par la vente de manuels libres. La FSF accepte les dons, mais la plus grande partie de ses recettes est toujours provenue des ventes — de copies de logiciel libre ou d'autres services associés. De nos jours, elle vend des CD-ROM de code source, des CD-ROM de binaires, des manuels de qualité (tout cela, en autorisant la redistribution et les modifications), et des distributions « Deluxe » (dans lesquelles nous construisons tous les logiciels pour la plate-forme de votre choix). Les employés de la fondation du logiciel libre ont écrit et maintenu un grand nombre de paquetages logiciels du projet GNU, en particulier la bibliothèque du langage C et l'interpréteur de commandes. La bibliothèque du langage C 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 du logiciel libre. L'interpréteur de commandes employé sur la plupart des systèmes GNU/Linux est BASH, le Bourne-Again Shell [9], qui a été développé par Brian Fox, employé 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 libreLa 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 de copies d'Emacs est une forme d'affaires fondées sur du logiciel libre. Quand la FSF a récupéré ce marché, j'ai dû chercher une autre solution pour gagner ma vie. Je l'ai trouvée sous la forme de vente de services associés au logiciel libre que j'avais développé. Cela consistait à enseigner des thèmes tels que la programmation de GNU Emacs et la personnalisation de GCC, et à développer du logiciel, principalement en portant GCC sur de nouvelles plates-formes. De nos jours, chacune de ces activités lucratives fondées sur le logiciel libre est proposée par de nombreuses sociétés. Certaines distribuent des compilations de logiciel libre 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 à observer des sociétés de logiciel libre fondées sur 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 » [10] fondent en réalité leur activité sur du logiciel propriétaire, qui interagit avec du logiciel libre. Ce ne sont pas des sociétés de logiciel libre, ce sont des sociétés de logiciel propriétaire dont les produits détournent les utilisateurs de leur liberté. Elles appellent cela de la « 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 techniquesL'objectif principal du projet GNU était le logiciel libre. Même si GNU ne jouissait d'aucun avantage technique sur Unix™, il disposerait d'un avantage social, en autorisant les utilisateurs à coopérer, et d'un avantage éthique, en respectant 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 encodables sur 8 bits, partout où cela avait un sens. De plus, nous rejetions l'accent mis par Unix™ sur les petites quantités de 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 en deçà d'un méga-octet. Dans les programmes pour lesquels il n'était pas crucial de manipuler des fichiers de tailles importantes, nous encouragions les programmeurs à lire le fichier en entrée, d'une traite, en mémoire, et d'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 équivalents sous Unix™ en termes de fiabilité et de vitesse d'exécution. Les ordinateurs offertsLa réputation du projet GNU croissant, on nous offrait des machines sous Unix™ pour nous aider à le mener à bien. Elles nous furent bien utiles, car le meilleur moyen 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 ou non, pour nous, de posséder des copies d'Unix™ ? Unix™ était (et demeure) du logiciel propriétaire, et la philosophie du projet GNU nous demandait de ne pas utiliser de logiciels propriétaire. Mais, en appliquant le même raisonnement que celui qui conclut qu'il est légitime de faire usage de violence en situation de légitime défense, j'ai conclu qu'il était légitime d'utiliser un paquetage propriétaire quand cela était crucial pour développer une solution de remplacement libre, qui en aiderait d'autres à se passer de ce même paquetage propriétaire. Mais ce mal avait beau être justifiable, il n'en restait pas moins un mal. De nos jours, nous ne possédons plus aucune copie d'Unix™, car nous les avons toutes remplacées 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 GNULe projet GNU suivant son cours, on trouvait ou 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 listé plusieurs autres projets utiles, de logiciel et de documentation, que nous jugions nécessaires au sein d'un système réellement complet. De nos jours, on ne trouve presque plus aucun composant d'Unix™ dans la liste des tâches du projet GNU — ces travaux tous ont été menés à bien, si 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 non 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 également 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™. Nous avons plutôt listé un spectre de divers types de jeux qui plairont vraisemblablement aux utilisateurs. La GNU Library GPL, ou licence publique générale de GNU pour les bibliothèquesLa bibliothèque du langage C du projet GNU fait appel à un gauche d'auteur particulier, appelé la GNU Library General Public License (licence publique générale de GNU pour les bibliothèques, ou GNU LGPL), qui autorise la liaison de logiciel propriétaire avec la bibliothèque. Pourquoi une telle exception ? Ce n'est pas une question de principe ; aucun principe ne dicte que les logiciels propriétaires 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 du langage C, ou de toute autre bibliothèque, est un choix stratégique. La bibliothèque du langage C joue un rôle générique ; tout système propriétaire, tout compilateur, dispose d'une bibliothèque du langage C. C'est pourquoi limiter l'utilisation de notre bibliothèque du langage C 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 un système GNU (et GNU/Linux est l'un de ces systèmes), la bibliothèque du langage C de GNU est la seule disponible. Aussi, ses conditions de distribution déterminent s'il est possible de compiler un programme propriétaire sur le système GNU. Il n'existe aucune raison éthique d'autoriser des applications propriétaires sur le système GNU, mais d'un point de vue stratégique, il semble que les interdire découragerait plus l'utilisation d'un système GNU que cela n'encouragerait le développement d'applications libres. C'est pourquoi l'utilisation de la GPL pour les bibliothèques (ou LGPL) est une bonne stratégie dans le cadre de la bibliothèque du langage 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 distribuer 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 à l'encontre du logiciel propriétaire. Considérons GNU Readline, une bibliothèque développée dans le but de fournir une édition de ligne de commande pour l'interpréteur de commandes BASH. Cette bibliothèque est distribuée sous la licence publique générale ordinaire de GNU, et non pas sous la LGPL. Cela a probablement pour effet de réduire l'utilisation de la bibliothèque Readline, mais cela n'induit aucune perte en ce qui nous concerne. Pendant ce temps, 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 propriétaire 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 couvertes par la GPL, et pour lesquelles il n'existera pas d'équivalent dans le monde du logiciel propriétaire. Nous disposerons ainsi de modules utiles, utilisables en tant que blocs de construction de nouveaux logiciels libres, et apportant un avantage considérable à la continuation du développement du logiciel libre. Gratter là où ça démange ?Eric 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 du logiciel 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 du langage C de GNU car un système de type Unix™ a besoin d'une bibliothèque du langage C, nous avons développé le Bourne-Again Shell (BASH) car un système de type Unix™ a besoin d'un interpréteur de commandes, et nous avons développé 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é, à savoir le compilateur C de GNU, GNU Emacs, GDB, et GNU Make. Certains programmes du projet 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 propriétaires (lire ci-après). Nous sommes en train de développer le GNU Privacy Guard (le gardien de l'intimité de GNU, ou GPG) pour remplacer un logiciel de chiffrement populaire mais pas libre, car les utilisateurs ne devraient pas devoir choisir entre la préservation de leur intimité 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 car elles comblaient leurs besoins ou les intéressaient. Mais ce n'est pas là la raison première de ces programmes. Des développements inattendusAu 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 fonctionner 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 ports — vers les diverses versions d'Unix™, incompatibles entre elles, et parfois, sur d'autres systèmes encore. 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 ports et à proposer des nouvelles fonctionnalités aux composants existants, plutôt que de continuer à développer peu à peu les composants manquants. Le GNU HurdEn 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 micro-noyau développé à l'université Carnegie-Mellon puis à l'université de l'Utah ; le GNU Hurd est une série de serveurs (ou une « horde de gnous ») qui fonctionnent au-dessus de Mach, et remplissent les diverses fonctions d'un noyau Unix™. Le développement a été retardé car nous attendions que Mach soit publié sous forme de logiciel libre, comme cela avait été 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 processus légers, qui s'envoyaient des messages les uns aux autres, se sont révélés très difficiles à déboguer. La consolidation du Hurd s'est étalée sur plusieurs années. 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 suis resté coi, mais ai décidé de lui faire la surprise d'appeler Alix le noyau du système GNU. Mais les choses ont changé. Michael Bushnell (maintenant, il s'agit de 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. Finalement, 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 du langage 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 produisissent, un de ses amis avait remarqué le nom Alix dans le code source du Hurd, et s'en était ouvert auprès d'elle. Finalement, ce nom avait rempli son office. Linux et GNU/LinuxLe GNU Hurd n'est pas encore utilisable de manière intensive. 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. Aux alentours de 1992, la jonction de Linux et du système GNU, qui était presque complet, a fourni 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. On appelle cette version du système « GNU/Linux » pour signaler qu'il est composé du système GNU et du noyau Linux. Les défis à venirNous avons fait la preuve de notre capacité à développer un large spectre de logiciel libre. 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 ; et il faudra des efforts et une endurance soutenus pour les relever, pendant parfois plusieurs années. 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 cinq sections suivantes discutent de ces défis. Le matériel secretLes 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 pourrait ne plus être le cas dans l'avenir, si nous ne pouvons plus proposer des pilotes pour les ordinateurs de demain. On peut résoudre ce problème de deux manières. Les programmeurs peuvent analyser l'ensemble afin de deviner comment prendre en compte le matériel. Les autres peuvent choisir le matériel qui est reconnu par du logiciel libre ; plus nous serons nombreux, plus la politique de garder les spécifications secrètes sera vouée à l'échec. L'ingénierie à l'envers est un travail conséquent ; disposerons-nous de programmeurs suffisamment déterminés pour le prendre en main ? Oui — si nous avons construit un sentiment puissant selon lequel 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 de temps, pour que nous puissions utiliser des pilotes libres ? Oui — si la détermination afférente à la liberté est largement répandue. Les bibliothèques non libresUne 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 utilisez la bibliothèque, vous tombez dans le piège, car votre programme ne peut pas être utilisé de manière utile au sein d'un système d'exploitation libre (pour être strict, on pourrait y inclure le programme, mais on ne pourrait pas l'exécuter en l'absence de la bibliothèque incriminée). Pire encore, si un programme qui utilise une bibliothèque propriétaire devient populaire, il peut attirer d'autres programmeurs peu soupçonneux dans le piège. 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, il était limpide que Motif leur causerait des problèmes, plus tard. Le projet GNU a réagi de deux manières : en demandant aux projets de logiciel libre de rendre l'utilisation de Motif facultative en privilégiant les gadgets de la boîte à outils X, libre, et en recherchant un volontaire pour écrire une solution de remplacement libre à Motif. Ce travail prit de nombreuses années ; LessTif, développé par les Hungry Programmers (les « Programmeurs affamés »), n'est devenu suffisamment étendu pour faire fonctionner la plupart des applications utilisant Motif qu'en 1997. De 1996 à 1998, une compilation conséquente de logiciel libre, le bureau KDE, a fait usage d'une autre bibliothèque non libre de boîte à outils pour l'interface graphique utilisateur, appelée Qt. Les systèmes GNU/Linux libres ne pouvaient pas utiliser KDE, car nous ne pouvions pas utiliser la bibliothèque. Cependant, certains distributeurs commerciaux de systèmes GNU/Linux n'ont pas été assez stricts pour coller au logiciel libre et ont ajouté KDE dans leurs systèmes — produisant un système disposant d'un plus grand nombre de fonctionnalités, mais souffrant d'une liberté réduite. Le groupe KDE encourageait activement un plus grand nombre de programmeurs à utiliser la bibliothèque Qt, et des millions de « nouveaux utilisateurs de Linux » n'ont jamais eu connaissance du fait que tout ceci posait un problème. La situation était sinistre. La communauté du logiciel libre a répondu à ce problème de deux manières : GNOME et Harmony. GNOME, le GNU Network Object Model Environment (environnement de GNU de modèle d'objets pour le réseau), 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 le fait de collaborer avec toute une variété de langages, et de ne pas de se limiter au 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, quand elle sera effective, fera 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 qu'a faite la communauté au problème que Qt posait quand il n'était pas libre (la nouvelle licence n'est pas pratique ni équitable, aussi demeure-t-il préférable d'éviter d'utiliser Qt). Comment répondrons-nous à la prochaine bibliothèque non libre mais alléchante ? La communauté comprendra-t-elle dans son entier la nécessité de ne pas tomber dans le piège ? Ou serons-nous nombreux à préférer la facilité à la liberté, et à produire un autre problème majeur ? Notre avenir dépend de notre philosophie. Les brevets sur les logicielsLa pire menace provient des brevets sur les logiciels, susceptibles de placer des algorithmes et des fonctionnalités hors de portée des logiciels libres 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 des logiciels libres qui produisent des images au format GIF correctement compressées. 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. Il existe plusieurs manières de répondre au problème des brevets : on peut rechercher des preuves qui invalident un brevet, et on peut rechercher d'autres solutions pour remplir une tâche. Mais chacune de ces méthodes ne fonctionne que dans certains cas ; quand les deux échouent, il se peut qu'un brevet empêche le logiciel libre de disposer de fonctionnalités souhaitées par les utilisateurs. Que ferons-nous dans ce genre de situation ? Ceux d'entre nous qui prêtent de la valeur au logiciel libre par amour de la liberté continueront à utiliser du logiciel libre dans tous les cas. On pourra travailler sans utiliser de fonctionnalités protégées par des brevets. Mais ceux d'entre nous qui prêtent de la valeur au logiciel libre car ils s'attendent à trouver là des logiciels techniquement supérieurs sont susceptibles de critiquer l'idée même du logiciel libre quand un brevet l'empêchera de progresser plus avant. Ainsi, même s'il est utile de discuter de l'efficacité, dans la pratique, du modèle de développement de type « cathédrale », et 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 libreIl ne faut pas chercher les lacunes les plus graves de nos systèmes d'exploitations libres dans le logiciel — c'est l'absence de manuels libres corrects qu'on puisse inclure dans nos systèmes qui se fait le plus cruellement sentir. La documentation est essentielle dans tout paquetage logiciel ; quand un paquetage logiciel important ne dispose pas d'un bon manuel libre, il s'agit d'un manque crucial. On en compte de nombreux aujourd'hui. La documentation libre, tout comme le logiciel libre, est une question de liberté, pas de prix [11]. La raison d'être d'un manuel libre est très proche de celle d'un 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 toute 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 afférente au logiciel libre. Quand on jouit de son droit de modifier le logiciel, et d'ajouter des fonctionnalités ou de modifier les fonctionnalités présentes, le programmeur consciencieux 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 remplit pas les besoins de notre communauté. Il est acceptable d'apposer certaines limites sur la manière dont les modifications sont faites. Il est par exemple envisageable d'exiger de préserver la notice de copyright de l'auteur original, les conditions de distribution, ou la liste des auteurs. D'exiger que les versions modifiées contiennent une notice qui stipule qu'elles ont été modifiées, et même d'interdire de modifier ou d'ôter des sections entières, pourvu que ces sections ne traitent pas de considérations techniques, ne pose pas non plus de problèmes, car 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 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 font obstruction à la communauté, le manuel n'est pas libre, et il nous en faut un autre. Les développeurs de logiciels libres seront-ils déterminés, auront-ils conscience du fait qu'il est nécessaire de produire tout un spectre de manuels libres ? Une fois de plus, notre avenir dépend de notre philosophie. Il nous faut faire l'apologie de la libertéOn estime aujourd'hui à dix millions le nombre d'utilisateurs de systèmes 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 : on voit plus de développeurs intéressés par la production de logiciels libres, les entreprises de logiciels libres comptent plus de clients, et il est plus facile d'encourager les sociétés à développer des logiciels libres commerciaux, plutôt que des produits logiciels propriétaires. 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 provoque des problèmes. Notre capacité à relever les défis et à répondre aux menaces évoqués plus haut dépend de notre volonté à défendre chèrement notre liberté. Pour nous assurer que notre communauté partage cette volonté, il nous faut répandre 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 l'éducation civique qui lui est attachée. 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é dans le logiciel, quand une portion de notre communauté a choisi d'arrêter d'utiliser le terme « Free Software » pour lui préférer la dénomination « Open Source software » [12]. 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 « gratuit » — ce qui est un objectif valable. D'autres, au contraire, avaient pour objectif de laisser de côté le principe qui a depuis 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 aux profits. Ainsi, la rhétorique de l'« Open Source » met l'accent sur le potentiel pour faire du logiciel puissant et de grande qualité, mais occulte délibérément les idées de liberté, de communauté, et de principes. Les magazines « Linux » illustrent clairement cet exemple — ils sont bourrés de publicités pour des logiciels propriétaires qui fonctionnent sur le système 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 déséquilibre encore plus la situation précédente, où on voit que l'éducation civique des nouveaux utilisateurs s'avère difficile lorsqu'ils affluent. Les termes « Free Software » et « Open Source » décrivent tous deux plus ou moins la même catégorie de logiciels, mais correspondent à des conceptions différentes du logiciel et des valeurs qui lui sont associées. Le projet GNU continue d'utiliser le terme « Free Software » pour exprimer l'idée que la liberté est plus importante que la seule technique. Jetez-vous à l'eau !La philosophie de Yoda (« il ne faut pas 'essayer' ») est attirante, mais elle 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, suffiraient aux 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 qu'il se peut que cette cité survive — pour le moment. Mais les dangers grandissent 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é, il vous faut vous préparer à la défendre. Informations légalesCopyright © 1998 Richard M. Stallman. Verbatim copying and duplication is permitted in any medium provided this notice is preserved. La diffusion de copies exactes de l'intégralité de cet article est autorisée, pourvu que la présente notice soit conservée.
Notes
|