Ceci est un document de Richard M.Stallman
en décembre 1998, traduit en français par
Sébastien Blondeel
en février 1999.
Essai publié dans le livre Open Sources : Voices from the Open Source Revolution, ISBN 1-56592-582-3, janvier 1999, édité par Chris DiBona, Sam Ockman, et Mark Stone chez O'Reilly & Associates. La version originale de ce document est abritée par la Free Software Foundation. une version en français est en cours d'adaptation par et pour les Éditions O'Reilly. Richard Stallman détient le copyright sur ce texte.
En 1971, quand j'ai commencé à travailler au laboratoire d'intelligence artificielle
(IA) du MIT1.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 hackers1.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 leur en accordions volontiers l'autorisation. 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.
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 n'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 point de vue sur la question : le leur.
Quand les éditeurs de logiciels parlent de ``faire respecter'' leurs
``droits'' ou de ``couper court au piratage1.3'', 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).
Avec 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 commencer par
trahir ses amis en promettant de restreindre leurs liberté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, 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 retenu 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 à Hillel1.4:
If I am not for myself, who will be for me ?
If I am only for myself, what am I ?
If not now, when ? 1.5
C'est dans un état d'esprit semblable que j'ai pris la décision de lancer le projet GNU.
Parfois1.6, 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 à 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é de proposer 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 entraves'') étant
le meilleur candidat, d'un point de vue sémantique, des mots comme
``liberated'' (``libéré''), ``freedom'' (``liberté''), et
``open'' (``ouvert'') souffrant tous d'un inconvénient ou d'un autre.
C'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 X Window 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.
En 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.
Peu de temps avant de me lancer dans le projet GNU, j'avais entendu parler du
Free University Compiler Kit1.7, 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 proposer 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 que l'université était libre,
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
proposant 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 réclamait plusieurs méga-octets d'espace de pile, alors que le
système Unix disponible sur le 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 dans le but d'analyser le fichier proposé en entrée,
d'en faire un arbre syntaxique, de convertir cet arbre syntaxique en chaîne
d'''instructions'', et d'engendrer ensuite le fichier de sortie,
sans jamais libérer le moindre espace mémoire occupé. C'est à ce moment-là
que j'ai 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'interface que j'avais écrite pour le C. Mais tout cela ne s'est
produit que quelques années plus tard; j'ai commencé par travailler sur
GNU Emacs.
J'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, nombreux étaient ceux qui parmi les
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 entiers fondés sur
GNU/Linux.
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 frappés de copyrights
mais distribués sous des licences permissives qui autorisent la création de
versions modifiées et propriétaires.
L'exemple paradigmatique de ce problème est le système X Window.
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
copies d'X n'étaient en rien du logiciel plus libre 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 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 pas la version libre.
Le 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
copyleft1.8,
ou ``gauche d'auteur''.
Le gauche d'auteur utilise les lois du droit d'auteur1.9, 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 et 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. Cela, pour s'assurer que toute oeuvre 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 de requérir 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 X Window 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'étaient pas immédiates et faciles à effectuer.
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'implantation 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.
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. 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 suivi 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
1.10, 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 atteindre cet
objectif.
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 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''
1.11 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''.
L'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 les caractères
encodés 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.
La 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 du 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
d'exploitation libre, nous remplacions la machine.
Le 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 est devenue célèbre sous
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 ont tous
é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 à un nombre
non confidentiel 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 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 proposer 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.
Eric Raymond
dit 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és, à savoir le compilateur de langage 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 proposé 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.
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 implanté 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.
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'implanter 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.
À 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 nom pourrait remplir les conditions
imposées aux noms 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 produisent, 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.
Le 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.
Nous avons prouvé que nous étions capables de 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.
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 proposer des 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
faire de l'ingéniérie à l'envers pour deviner comment prendre en compte
le matériel. Les autres d'entre nous 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éniérie à 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.
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 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
d'utiliser les gadgets de la boîte à outils X, libre, en plus
d'utiliser Motif, et en demandant à quelqu'un d'é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
semblait bloquée.
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 modèle d'objets pour le réseau de GNU), 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 proposer des
fonctionnalités de bureau similaires, en utilisant exclusivement du
logiciel libre. Il jouit aussi d'avantages techniques, comme le fait de
proposer 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, mise
au point 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.
La 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, on a cessé de distribuer un programme
libre qui produisait des données sonores compressées au format
MP3 sous la menace d'une poursuite pour cause de violation de
brevets.
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 parler d'échec là ou un brevet bridera
les possibilités des logiciels libres. 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.
Il 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 prix1.12. 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 en profitera pour mettre
également à jour le manuel - afin de proposer 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, pour peu que ces
restrictions ne s'appliquent pas à des 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.
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 de
faire le choix de 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 cause
des ennuis. 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.
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 software1.13.
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
fait passer au second plan les idées de liberté, de communauté, et de
principes.
Les magazines traitant de ``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.
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 je suffirais à les mener
à bien dans l'affirmative. Mais j'ai tenté ma chance, car j'étais seul
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 m'aide à 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.
``The GNU Operating System and the Free Software Movement'' is Copyright
©1998 Richard M. Stallman. Verbatim copying and
duplication is permitted in any medium provided this notice is
preserved.
Richard M. Stallman détient le copyright sur le texte ``Le système d'exploitation du projet GNU et le mouvement du logiciel libre'', ©1998. Il autorise toute copie verbatim pour peu que la présente notice soit présente.