path: root/talermerchantdemos/blog/articles/fr/thegnuproject.html

<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->

<!--#include virtual="/server/header.fr.html" -->
<!-- Parent-Version: 1.86 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>À propos du projet GNU - Projet GNU - Free Software Foundation</title>
<meta http-equiv="Keywords" content="GNU, GNU Project, FSF, Free Software, Free Software Foundation, History" />

<!--#include virtual="/gnu/po/thegnuproject.translist" -->
<!--#include virtual="/server/banner.fr.html" -->
<h2>Le projet GNU</h2>

<p>
par <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>

<blockquote>
<p>
Publié à l'origine dans le livre <em>Open Sources</em>. Richard Stallman <a
href="/philosophy/open-source-misses-the-point.html">n'a jamais été partisan
de l'« open source »</a>, mais a contribué à ce livre par cet article pour
que les idées du logiciel libre n'en soient pas complètement absentes.
</p>
<p>
Pourquoi il est plus important que jamais <a
href="/philosophy/free-software-even-more-important.html">d'exiger que le
logiciel dont nous nous servons soit libre</a>.
</p>
</blockquote>

<h3>La première communauté qui partageait le logiciel</h3>
<p>
En 1971, quand j'ai commencé à travailler au labo d'intelligence
artificielle (IA) du <abbr title="Massachusetts Institute of
Technology">MIT</abbr> (Institut de technologie du Massachusetts), j'ai
intégré une communauté qui partageait le logiciel depuis de nombreuses
années déjà. Le partage du logiciel n'était pas limité à notre
communauté ; c'est une notion aussi ancienne que les premiers ordinateurs,
tout comme le partage des recettes est aussi ancien que la cuisine. Mais
nous partagions davantage que la plupart.</p>
<p>
Le labo d'IA utilisait un système d'exploitation à temps partagé appelé
<abbr title="Incompatible Timesharing System">ITS</abbr> (système à temps
partagé incompatible) que les hackers (1) de l'équipe avaient écrit et mis
au point en langage assembleur pour le <abbr title="Programmed Data
Processor">PDP</abbr>-10 de Digital, l'un des grands ordinateurs de
l'époque. En tant que membre de cette communauté, hacker système de l'équipe
du labo d'IA, mon travail consistait à améliorer ce système.</p>
<p>
Nous ne qualifiions pas nos productions de « logiciels libres », car ce
terme n'existait pas encore ; c'est pourtant ce qu'elles étaient. Quand
d'autres universitaires, ou bien une entreprise, souhaitaient porter l'un de
nos programmes pour l'utiliser sur leur matériel, nous les laissions
volontiers faire. Et quand on voyait quelqu'un utiliser un programme inconnu
qui semblait intéressant, on pouvait toujours en obtenir le code source,
afin de le lire, le modifier, ou d'en réutiliser des parties dans le cadre
d'un nouveau programme.</p>
<p>
(1) L'utilisation du mot « hacker » dans le sens de « casseur de systèmes de
sécurité », est un amalgame instillé par les mass media. Nous autres hackers
refusons de reconnaître cette signification et continuons de donner à ce mot
le sens de « celui qui aime programmer ou qui prend plaisir à exercer son
ingéniosité de façon ludique ».<a id="TransNote1-rev"
href="#TransNote1"><sup>a</sup></a> Consultez mon article <a
href="http://stallman.org/articles/on-hacking.html">On Hacking</a>.</p>

<h3>L'effondrement de la communauté</h3>
<p>
La situation changea de manière radicale au début des années 80 quand la
société Digital mit fin à la série des PDP-10. Cette architecture, élégante
et puissante dans les années 60, ne pouvait pas s'adapter sans difficulté
aux plus grands espaces d'adressage qui devenaient réalisables dans les
années 80. Cela rendait obsolètes la quasi-totalité des programmes
constituant ITS.</p>
<p>
La communauté des hackers du labo d'IA s'était effondrée peu de temps
auparavant. La plupart d'entre eux avaient été engagés par une nouvelle
société, Symbolics, et ceux qui étaient restés ne parvenaient pas à
maintenir la communauté (le livre <cite>Hackers</cite>, écrit par Steve
Levy, décrit ces événements et dépeint clairement l'apogée de cette
communauté). Quand le laboratoire a, en 1982, choisi d'acheter un nouveau
PDP-10, ses administrateurs ont décidé de remplacer ITS par le système à
temps partagé de la société Digital, qui n'était pas libre.</p>
<p>
Les ordinateurs modernes d'alors, tels le VAX et le 68020, disposaient de
leurs propres systèmes d'exploitation, mais aucun d'entre eux n'était
libre : il fallait signer un accord de non-divulgation pour en obtenir ne
serait-ce qu'une copie exécutable.</p>
<p>
Cela signifiait que la première étape de l'utilisation d'un ordinateur était
la promesse de ne pas aider son prochain. On interdisait toute communauté
fondée sur la coopération. La règle qu'édictaient ceux qui détenaient le
monopole d'un logiciel privateur<a id="TransNote2-rev"
href="#TransNote2"><sup>b</sup></a> était : « Qui partage avec son voisin
est un pirate. Qui souhaite la moindre modification doit nous supplier de la
lui faire. »</p>
<p>
L'idée que le système social du logiciel privateur – le système qui vous
interdit de partager ou d'échanger le logiciel – est antisocial, contraire à
l'éthique, et qu'il est tout simplement mauvais, surprendra peut-être
certains lecteurs. Mais comment qualifier autrement un système fondé sur la
division et l'isolement des utilisateurs ? Les lecteurs surpris par cette
idée ont probablement pris le système social du logiciel privateur pour
argent comptant, ou l'ont jugé en employant les termes suggérés par les
entreprises de logiciel privateur. Les éditeurs de logiciels travaillent
d'arrache-pied, et depuis longtemps, à convaincre tout un chacun qu'il
n'existe qu'un seul point de vue sur la question – le leur.</p>
<p>
Quand les éditeurs de logiciels parlent de « faire respecter » leurs
« droits » ou de « couper court au <a
href="/philosophy/words-to-avoid.html#Piracy">piratage</a> », ce qu'ils
<em>disent</em> est secondaire. Le véritable message se trouve entre les
lignes et il consiste en des hypothèses de travail qu'ils considèrent comme
acquises ; nous sommes censés les accepter les yeux fermés. Passons-les donc
en revue.</p>
<p>
La première hypothèse est que les sociétés éditrices de logiciel disposent
d'un droit naturel, incontestable, à être propriétaire du logiciel et
asseoir ainsi leur pouvoir sur tous ses utilisateurs (si c'était là un droit
naturel, on ne pourrait formuler aucune objection, indépendamment du tort
qu'il cause à tous). Il est intéressant de remarquer que la Constitution et
la tradition juridique des États-Unis d'Amérique rejettent toutes deux cette
idée ; le copyright n'est pas un droit naturel, mais un monopole artificiel,
imposé par l'État, restreignant le droit naturel de copier que possèdent les
utilisateurs.</p>
<p>
Autre hypothèse sous-jacente : seules importent les fonctionnalités du
logiciel; des utilisateurs comme nous ne doivent pas s'intéresser au modèle
de société qu'on leur prépare.</p>
<p>
Une troisième hypothèse est qu'on ne disposerait d'aucun logiciel utilisable
(ou qu'on ne disposerait jamais d'un logiciel qui s'acquitte de telle ou
telle tâche en particulier) si l'on ne garantissait pas à une entreprise
l'assise d'un pouvoir sur les utilisateurs du programme. Cette idée était
plausible, jusqu'à ce que le mouvement du logiciel libre démontrât qu'on
peut produire toutes sortes de logiciels utiles sans qu'il soit nécessaire
de les barder de chaînes.</p>
<p>
Si l'on se refuse à accepter ces hypothèses et qu'on examine ces questions
en se fondant sur une morale dictée par le bon sens, tout en plaçant les
utilisateurs au premier plan, on parvient à des conclusions bien
différentes. Les utilisateurs doivent être libres de modifier les programmes
pour qu'ils répondent mieux à leurs besoins, et libres de partager le
logiciel parce que la société est fondée sur l'aide à autrui.</p>
<p>
La place me manque ici pour développer le raisonnement menant à cette
conclusion, aussi renverrai-je le lecteur aux articles <a
href="/philosophy/why-free.html">Pourquoi les logiciels ne doivent pas avoir
de propriétaire</a> et <a
href="/philosophy/free-software-even-more-important.html">Le logiciel libre
est encore plus essentiel maintenant</a>.
</p>

<h3>Un choix moral difficile</h3>
<p>
Avec l'extinction de ma communauté, il m'était impossible de continuer comme
par le passé. J'étais confronté à un choix moral difficile.</p>
<p>
La solution de facilité était de rejoindre le monde du logiciel privateur,
signer des accords de non-divulgation et promettre de ne pas aider mon
camarade hacker. Très probablement, j'aurais aussi été amené à développer du
logiciel publié dans le cadre d'accords de non-divulgation, contribuant
ainsi à en pousser d'autres vers la trahison de leurs camarades.</p>
<p>
J'aurais pu gagner de l'argent de cette façon et peut-être même trouver
amusant d'écrire du code. Mais je savais qu'à la fin de ma carrière je
n'aurais à contempler que des années passées à construire des murs pour
séparer les gens, avec l'impression d'avoir employé ma vie à rendre le monde
pire.</p>
<p>
J'avais déjà eu l'expérience douloureuse des accords de non-divulgation,
quand quelqu'un m'avait refusé, ainsi qu'au labo d'IA du MIT, l'accès au
code source du programme de contrôle de notre imprimante (l'absence de
certaines fonctionnalités dans ce programme rendait l'utilisation de
l'imprimante très frustrante). Aussi ne pouvais-je pas me dire que les
accords de non-divulgation étaient bénins. Le refus de cette personne de
partager avec nous m'avait mis très en colère ; je ne pouvais pas, à mon
tour, adopter un tel comportement à l'égard de mon prochain.</p>
<p>
Une autre possibilité, radicale mais déplaisante, était d'abandonner
l'informatique. De cette manière, mes capacités ne seraient pas employées à
mauvais escient, mais elles n'en seraient pas moins gaspillées. Je ne me
rendrais pas coupable de diviser les utilisateurs d'ordinateurs et de
restreindre leurs droits, mais cela se produirait malgré tout.</p>
<p>
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é.</p>
<p>
La réponse était limpide : le besoin le plus pressant était un système
d'exploitation. C'est le logiciel le plus crucial pour commencer à utiliser
un ordinateur. Un système d'exploitation permet de faire beaucoup de
choses ; sans système, l'ordinateur est inexploitable. Avec un système
d'exploitation libre, on pourrait reconstituer une communauté de hackers
travaillant en mode coopératif – et inviter chacun à participer. Ainsi tout
un chacun pourrait se servir d'un ordinateur sans au préalable entrer dans
une conspiration destinée à spolier ses ami.e.s.</p>
<p>
En tant que développeur de système d'exploitation, j'avais les compétences
requises. Aussi, bien que le succès ne me semblât pas garanti, je me suis
rendu compte que j'étais prédestiné à faire ce travail. J'ai choisi de
rendre le système compatible avec Unix de manière à le rendre portable, pour
que les utilisateurs d'Unix puissent migrer facilement. J'ai opté pour le
nom « GNU », fidèle en cela à une tradition des hackers, car c'est un
acronyme récursif qui signifie <cite>GNU's Not Unix</cite> (GNU N'est pas
Unix). Il se prononce <a href="/gnu/pronunciation.html">« gnou » (comme
l'animal), avec un g dur</a>.</p>
<p>
Un système d'exploitation ne se limite pas à un noyau, qui suffit à peine à
exécuter d'autres programmes. Dans les années 70, tout système
d'exploitation digne de ce nom disposait d'interpréteurs de commandes
(<cite>shell</cite>), d'assembleurs, de compilateurs, d'interpréteurs, de
débogueurs, d'éditeurs de textes, de logiciels de courrier électronique,
pour n'en citer que quelques-uns. C'était le cas d'ITS, c'était le cas de
Multics, c'était le cas de VMS et c'était le cas d'Unix. Ce serait aussi le
cas du système d'exploitation GNU.</p>
<p>
Plus tard, j'ai entendu ces mots, attribués à Hillel (1) :</p>

<blockquote><p>
     If I am not for myself, who will be for me?<br />
     If I am only for myself, what am I?<br />
     If not now, when? <a id="TransNote3-rev" href="#TransNote3"><sup>c</sup></a>
</p></blockquote>
<p>
C'est dans cet état d'esprit que j'ai pris la décision de lancer le projet
GNU.</p>
<p>
(1) En tant qu'athée, je ne suis les pas d'aucun guide spirituel, mais
j'admire parfois ce qu'a dit l'un d'entre eux.</p>

<h3><cite>Free</cite> comme libre</h3>
<p>
Le terme <cite>free software</cite> est mal compris : il n'a rien à voir
avec le prix.<a id="TransNote4-rev" href="#TransNote4"><sup>d</sup></a> Il
parle de liberté. Voici donc la définition d'un logiciel libre.</p>

<p>Un programme est un logiciel libre pour vous, utilisateur particulier, si :</p>

<ul>
  <li>vous avez la liberté de l'exécuter comme vous le souhaitez, pour quelque
motif que ce soit ;</li>

  <li>vous avez la liberté de modifier le programme afin qu'il corresponde mieux à
vos besoins (dans la pratique, pour que cette liberté prenne effet, il vous
faut pouvoir accéder au code source, puisqu'opérer des modifications au sein
d'un programme dont on n'a pas le code source est un exercice extrêmement
difficile) ;</li>

  <li>vous disposez de la liberté d'en redistribuer des copies, que ce de manière
gratuite ou onéreuse ;</li>

  <li>vous avez la liberté de distribuer des versions modifiées du programme, afin
que la communauté puisse bénéficier de vos améliorations.</li>
</ul>
<p>
Puisque le mot <cite>free</cite> se réfère ici à la liberté et non au prix,
il n'est pas contradictoire de vendre des copies de logiciels libres. En
réalité, cette liberté est cruciale : les compilations de logiciels libres
vendues sur CD-ROM sont importantes pour la communauté, car le produit de
leur vente permet de lever des fonds pour le développement du logiciel
libre. C'est pourquoi on ne peut pas qualifier de libre un logiciel qu'on
n'a pas la liberté d'inclure dans de telles compilations.</p>
<p>
Le mot <cite>free</cite> étant ambigu en anglais, on a longtemps cherché des
solutions de remplacement, mais personne n'a trouvé mieux. La langue
anglaise compte plus de mots et de nuances que toute autre langue, mais elle
souffre de l'absence d'un mot simple, univoque, qui ait le sens de
<cite>free</cite> comme liberté – <cite>unfettered</cite> (terme littéraire
signifiant « sans entrave ») étant le meilleur candidat, d'un point de vue
sémantique. Des mots comme <cite>liberated</cite> (libéré),
<cite>freedom</cite> (liberté) et <cite>open</cite> (ouvert) présentent tous
un sens incorrect ou un autre inconvénient.</p>

<h3>Les logiciels GNU et le système GNU</h3>
<p>
C'est un projet de très grande envergure que de développer un système
complet. Pour le mener à bien, j'ai décidé d'adapter et de réutiliser les
logiciels libres existants, quand cela était possible. J'ai par exemple
décidé dès le début d'utiliser TeX comme formateur de texte principal ;
quelques années plus tard, j'ai décidé d'utiliser le système X Window plutôt
que d'écrire un autre système de fenêtrage pour GNU.</p>
<p>
Cette décision, comme d'autres du même genre, a rendu le système GNU
distinct de la réunion de tous les logiciels GNU. Le système GNU comprend
des programmes qui ne sont pas des logiciels GNU ; ce sont des programmes
qui ont été développés par d'autres, dans le cadre d'autres projets, pour
leurs buts propres, mais qu'on peut réutiliser, car ce sont des logiciels
libres.</p>

<h3>La genèse du projet</h3>
<p>
En janvier 1984, j'ai démissionné de mon poste au MIT et commencé à écrire
les logiciels GNU. Il était nécessaire que je quitte le MIT pour empêcher ce
dernier de s'immiscer dans la distribution de GNU en tant que logiciel
libre. Si j'avais gardé mon poste, le MIT aurait pu se déclarer propriétaire
de mon travail et lui imposer ses propres conditions de distribution, voire
le transformer en logiciel privateur. Je n'avais pas l'intention d'abattre
autant de travail pour le voir devenir impropre à sa destination première :
créer une nouvelle communauté qui partage le logiciel.</p>
<p>
Cependant, le professeur Winston, qui dirigeait alors le labo d'IA du MIT,
m'a gentiment invité à continuer d'utiliser les équipements du laboratoire.</p>

<h3>Les premiers pas</h3>
<p>
Peu de temps avant de me lancer dans le projet GNU, j'avais entendu parler
du <cite>Free University Compiler Kit</cite>,<a id="TransNote5-rev"
href="#TransNote5"><sup>e</sup></a> plus connu sous le nom de VUCK (en
néerlandais, le mot qui veut dire <cite>free</cite> commence par un
<em>v</em>). Ce compilateur avait été mis au point dans l'intention de gérer
plusieurs langages, parmi lesquels C et Pascal, et de produire des binaires
pour de nombreuses machines cibles. J'ai écrit à son auteur en lui demandant
la permission d'utiliser ce compilateur dans le cadre du projet GNU.</p>
<p>
Il répondit d'un ton railleur, en déclarant (en anglais) que l'université
était <cite>free</cite> mais pas le compilateur. J'ai alors décidé que le
premier programme du projet GNU serait un compilateur gérant plusieurs
langages, sur plusieurs plateformes.</p>
<p>
En espérant m'épargner la peine d'écrire tout le compilateur moi-même, j'ai
obtenu le code source du compilateur Pastel, qui avait été développé au
laboratoire Lawrence Livermore et était multiplateforme. Il compilait une
version étendue de Pascal conçue comme langage de programmation système, et
c'était aussi le langage dans lequel il avait été écrit. J'y ai ajouté une
interface pour le C et j'ai entrepris le portage de ce programme sur le
Motorola 68000. Mais j'ai dû abandonner quand j'ai découvert qu'il fallait à
ce compilateur plusieurs mégaoctets d'espace de pile, alors que le système
Unix du 68000 n'en gérait que 64 ko.</p>
<p>
J'ai alors compris comment fonctionnait Pastel : il analysait le fichier en
entrée, en faisait un arbre syntaxique, convertissait cet arbre syntaxique
en chaîne d'« instructions » et engendrait ensuite le fichier de sortie,
sans jamais libérer le moindre espace mémoire. J'en ai conclu qu'il me
faudrait réécrire un nouveau compilateur en partant de zéro. Ce dernier est
maintenant connu sous le nom de <abbr title="GNU Compiler
Collection">GCC</abbr> ; il n'utilise rien de Pastel, mais j'ai réussi à
adapter et réutiliser l'analyseur syntaxique que j'avais écrit pour le
langage C. Mais tout cela ne s'est produit que quelques années plus tard ;
j'ai d'abord travaillé sur GNU Emacs.</p>

<h3>GNU Emacs</h3>
<p>
J'ai commencé à travailler sur GNU Emacs en septembre 1984 ; début 1985, ce
programme commençait à devenir fonctionnel, ce qui m'a permis d'utiliser des
systèmes Unix pour éditer mes fichiers ; n'ayant aucune envie de me
familiariser avec vi ou ed, j'avais jusqu'alors utilisé d'autres types de
machines pour les éditer.</p>
<p>
C'est alors que j'ai reçu des requêtes de gens souhaitant utiliser GNU
Emacs, ce qui a soulevé le problème de sa distribution. Je l'avais bien sûr
mis sur le serveur FTP anonyme de l'ordinateur du MIT que j'utilisais (cet
ordinateur, prep.ai.mit.edu, a ainsi été promu au rang de site de
distribution principal par FTP du projet GNU ; quelques années plus tard, à
la fin de son exploitation, nous avons transféré ce nom sur notre nouveau
serveur FTP). Mais à l'époque, une proportion importante des personnes
intéressées, n'ayant pas d'accès à Internet, ne pouvaient pas se procurer de
copie du programme par FTP. La question se posait en ces termes : que
devais-je leur dire ?</p>
<p>
J'aurais pu leur dire : « Trouvez un ami qui dispose d'un accès au réseau et
qui vous en fera une copie. » J'aurais pu également leur dire, comme je
l'avais fait avec la version originale d'Emacs pour PDP-10, « Envoyez-moi
une bande et une enveloppe timbrée à votre adresse ; je vous les renverrai
avec Emacs. » Mais j'étais sans emploi et je cherchais des moyens de gagner
de l'argent grâce au logiciel libre. C'est pourquoi j'ai annoncé que
j'enverrais une bande à quiconque en désirait une, en échange d'une
contribution de 150 dollars américains. C'est ainsi que j'ai créé une
entreprise de distribution de logiciel libre, l'ancêtre des sociétés qui, de
nos jours, proposent des distributions GNU/Linux complètes.</p>

<h3>Un programme est-il libre pour chacun de ses utilisateurs ?</h3>
<p>
Si un programme est un logiciel libre au moment où il quitte les mains de
son auteur, cela ne signifie pas nécessairement qu'il sera un logiciel libre
pour quiconque en possédera une copie. Un logiciel placé dans le <a
href="/philosophy/categories.html#PublicDomainSoftware">domaine public</a>,
par exemple (qui n'est couvert par aucun copyright), est un logiciel libre ;
mais tout un chacun peut en produire une version privatrice modifiée. De
façon comparable, de nombreux programmes libres sont couverts par des
copyrights, mais distribués sous des licences permissives qui autorisent la
création de versions modifiées privatrices.</p>
<p>
L'exemple le plus frappant de ce problème est le système X Window. Développé
au MIT et distribué sous forme de logiciel libre avec une licence
permissive, il a rapidement été adopté par divers constructeurs. Ils ont
ajouté X à leurs systèmes Unix privateurs, sous forme binaire uniquement, en
le frappant du même accord de non-divulgation. Ces exemplaires de X
n'étaient pas plus libres que le reste d'Unix.</p>
<p>
Les développeurs du système X Window ne voyaient là nul problème (ils
s'attendaient à cela et souhaitaient un tel résultat). Leur but n'était pas
la liberté, mais la simple « réussite », définie comme le fait d'« avoir
beaucoup d'utilisateurs ». Peu leur importait la liberté de ces
utilisateurs, seul leur nombre revêtait de l'importance à leurs yeux.</p>
<p>
Cela a conduit à une situation paradoxale où deux façons différentes
d'évaluer la liberté donnaient des réponses différentes à la question « Ce
programme est-il libre ? » Qui fondait son jugement sur la liberté accordée
par les termes de distribution de la version du MIT concluait que X était un
logiciel libre. Mais qui mesurait la liberté de l'utilisateur-type de X
devait conclure que X était un logiciel privateur. La plupart des
utilisateurs de X exécutaient les versions privatrices fournies avec les
systèmes Unix et non la version libre.</p>

<h3>Le copyleft et la GNU GPL</h3>
<p>
Le but du projet GNU était de rendre les utilisateurs libres, pas de se
contenter d'être populaire. Nous avions besoin de conditions de distribution
qui empêcheraient de transformer les logiciels GNU en logiciels
privateurs. La méthode que nous utilisons a pour nom « copyleft » (1), ou
« gauche d'auteur ».</p>
<p>
Le copyleft utilise le copyright (ou le droit d'auteur), en le retournant
pour lui faire servir le but opposé de ce pour quoi il a été conçu : ce
n'est pas une manière de restreindre l'utilisation d'un logiciel, mais une
manière de lui conserver sa liberté.</p>
<p>
L'idée centrale du copyleft est de donner à chacun la permission d'exécuter
le programme, de le copier, de le modifier et d'en distribuer des versions
modifiées (mais pas la permission d'ajouter des restrictions de son
cru). C'est ainsi que les libertés essentielles qui définissent le
« logiciel libre » sont garanties pour quiconque en possède un exemplaire ;
elles deviennent des droits inaliénables.</p>
<p>
Pour que le copyleft soit efficace, il faut que les versions modifiées
demeurent libres, afin de s'assurer que toute œuvre dérivée de notre travail
reste disponible pour la communauté en cas de publication. Quand un
programmeur professionnel améliore bénévolement un logiciel GNU, c'est le
copyleft qui empêche son employeur de dire : « Vous ne pouvez pas partager
ces modifications, car nous allons les utiliser dans le cadre de notre
version privatrice du programme. »</p>
<p>
Il est essentiel d'imposer que les modifications restent libres si l'on
souhaite garantir la liberté de tout utilisateur du programme. Les sociétés
qui ont privatisé le système X Window faisaient en général quelques
modifications pour le porter sur leur système d'exploitation et sur leur
matériel. Ces modifications étaient ténues si on les comparait à X dans son
ensemble, mais elles n'en étaient pas pour autant évidentes. Si le fait de
procéder à des modifications était un prétexte valable pour refuser aux
utilisateurs leur liberté, n'importe qui pourrait facilement en tirer parti.</p>
<p>
Le problème de la réunion d'un programme libre avec du code non libre est
similaire. Une telle combinaison serait indubitablement non libre ; les
libertés absentes de la partie non libre du programme ne se trouveraient pas
non plus dans l'ensemble, résultat de la combinaison. Autoriser de telles
pratiques ouvrirait une voie d'eau suffisante pour couler le navire. C'est
pourquoi il est essentiel que le copyleft colmate cette brèche : l'ajout ou
la jonction d'un élément quelconque à un programme sous copyleft doit se
faire de telle sorte que la version élargie résultant de l'opération soit
également libre et régie par le copyleft.</p>
<p>
La mise en œuvre spécifique du copyleft que nous utilisons pour la plupart
des logiciels GNU est la licence publique générale GNU, GNU <abbr title="GNU
General Public License">GPL</abbr> en abrégé. Nous disposons d'autres types
de copyleft pour des circonstances particulières. Les manuels du projet GNU
sont eux aussi régis par le copyleft, mais en utilisent une version très
simplifiée car il n'est pas nécessaire de faire appel à toute la complexité
de la GNU GPL dans le cadre de manuels. (2)</p>
<p>
(1) En 1984 ou 1985, Don Hopkins (dont l'imagination était sans bornes) m'a
envoyé une lettre. Il avait écrit sur l'enveloppe plusieurs phrases
amusantes et notamment celle-ci : <cite>Copyleft – all rights
reversed.</cite><a id="TransNote6-rev" href="#TransNote6"><sup>f</sup></a>
J'ai utilisé le mot « copyleft » pour donner un nom au concept de
distribution que je développais alors.</p>

<p>
(2) Nous utilisons maintenant la <a href="/licenses/fdl.html">licence GNU de
documentation libre</a> (GNU <abbr title="Free Documentation
License">FDL</abbr>) pour la documentation.</p>

<h3>La <cite>Free Software Foundation</cite>, ou Fondation pour le logiciel
libre</h3>

<p>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 <a
href="http://www.fsf.org/">Free Software Foundation</a> (Fondation pour le
logiciel libre), une association à but non lucratif, exemptée d'impôts, pour
le développement de logiciels libres. La <abbr title="Free Software
Foundation">FSF</abbr> a aussi pris en charge le commerce de la distribution
d'Emacs ; plus tard, elle a étendu cette activité en ajoutant aux bandes
d'autres logiciels libres (aussi bien GNU que non GNU) et en vendant des
manuels libres.</p>

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

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

<p>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.</p>

<p>(1) <cite>Bourne-Again Shell</cite><a id="TransNote7-rev"
href="#TransNote7"><sup>g</sup></a> est un clin d'œil au nom <cite>Bourne
Shell</cite>, qui était le shell habituel sur Unix.</p>

<h3>Assistance technique au logiciel libre</h3>

<p>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.</p>

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

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

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

<h3>Objectifs techniques</h3>

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

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

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

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

<h3>Des ordinateurs offerts</h3>

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

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

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

<h3>La <cite>GNU Task List</cite>, ou liste des tâches du projet GNU</h3>

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

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

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

<p>(1) Cela a été écrit en 1998. Depuis 2009, nous ne tenons plus à jour cette
longue liste de tâches. La communauté développe des logiciels libres
tellement vite que nous ne pouvons même pas les suivre tous. En revanche,
nous avons une liste des projets à haute priorité – liste bien plus courte
de projets dont nous souhaitons vivement qu'ils soient menés à bien.</p>

<h3>La <cite>GNU Library GPL</cite>, ou licence publique générale GNU pour les
bibliothèques</h3>

<p>La bibliothèque C de GNU fait appel à un copyleft particulier, appelé
« licence publique générale GNU pour les bibliothèques », ou GNU <abbr
title="Library General Public License">LGPL</abbr> (1), qui autorise la
liaison de logiciel privateur avec la bibliothèque. Pourquoi une telle
exception ?</p>

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

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

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

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

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

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

<p>(1) Cette licence s'appelle maintenant la <cite>GNU Lesser General Public
License</cite> (licence publique générale GNU amoindrie), pour éviter de
laisser penser que toutes les bibliothèques doivent l'utiliser. Consultez
l'article <a href="/philosophy/why-not-lgpl.html">Pourquoi vous ne devriez
pas utiliser la LGPL pour votre prochaine bibliothèque</a> pour plus
d'informations.</p>

<h3>Gratter là où ça démange ?</h3>
<p>
Éric Raymond affirme que « Tout bon logiciel commence par gratter un
développeur là où ça le démange. » Cela se produit peut-être, parfois, mais
de nombreux composants essentiels de GNU ont été développés dans le but de
disposer d'un système d'exploitation libre complet. Ils ont été inspirés par
une vision et un projet à long terme, pas par un coup de tête.</p>
<p>
Nous avons par exemple développé la bibliothèque C de GNU, car un système de
type Unix a besoin d'une bibliothèque C ; BASH, car un système de type Unix
a besoin d'un shell ; et GNU tar, car un système de type Unix a besoin d'un
programme d'archivage. Il en va de même pour les programmes que j'ai
développés, à savoir le compilateur C de GNU, GNU Emacs, GDB et GNU Make.</p>
<p>
Certains programmes GNU ont été développés pour répondre aux menaces qui
pesaient sur notre liberté. C'est ainsi que nous avons développé gzip en
remplacement du programme Compress, que la communauté avait perdu suite aux
brevets logiciels déposés sur <abbr
title="Lempel-Ziv-Welch">LZW</abbr>. Nous avons trouvé des gens pour
développer LessTif, et plus récemment nous avons démarré les projets <abbr
title="GNU Network Object Model Environment">GNOME</abbr> et Harmony en
réponse aux problème posés par certaines bibliothèques privatrices (lire
ci-après). Nous sommes en train de développer GNU Privacy Guard (GPG) pour
remplacer un logiciel de chiffrement populaire mais non libre, car les
utilisateurs ne devraient pas avoir à choisir entre la préservation de leur
vie privée et la préservation de leur liberté.</p>
<p>
Bien sûr, les gens qui écrivent ces programmes se sont intéressés à ce
travail et de nombreux contributeurs ont ajouté de nouvelles fonctionnalités
pour satisfaire leurs besoins ou leurs intérêts. Mais ce n'est pas là la
raison première de ces programmes.</p>

<h3>Des développements inattendus</h3>
<p>
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.</p>
<p>
Puisque chaque composant du système GNU était implémenté sur un système
Unix, chaque composant pouvait être exécuté sur des systèmes Unix bien avant
que le système GNU ne soit disponible dans sa globalité. Certains de ces
programmes sont devenus populaires et leurs utilisateurs ont commencé à
travailler sur des extensions et des portages – sur les diverses versions
incompatibles d'Unix et parfois aussi sur d'autres systèmes.</p>
<p>
Ce processus a rendu ces programmes bien plus complets et a drainé des fonds
et des participants vers le projet GNU. Mais il a probablement eu également
pour effet de retarder de plusieurs années la mise au point d'un système en
état de fonctionnement, puisque les développeurs du projet GNU passaient
leur temps à s'occuper de ces portages et à ajouter de nouvelles
fonctionnalités aux composants existants, plutôt que de continuer à
développer peu à peu les composants manquants.</p>

<h3>Le GNU Hurd</h3>
<p>
En 1990, le système GNU était presque terminé ; le seul composant principal
qui manquait encore à l'appel était le noyau. Nous avions décidé
d'implémenter le noyau sous la forme d'une série de processus serveurs qui
fonctionneraient au-dessus de Mach. Mach est un micronoyau qui a été
développé à l'université Carnegie-Mellon, puis à l'université d'Utah ; le
GNU Hurd est une série de serveurs (une « horde de gnous ») qui fonctionnent
au-dessus de Mach et remplissent les diverses fonctions du noyau Unix. Le
développement a été retardé, car nous attendions que Mach soit publié sous
forme de logiciel libre comme on nous l'avait promis.</p>
<p>
L'une des raisons qui ont dicté ce choix était d'éviter ce qui semblait être
la partie la plus difficile du travail : déboguer un programme de noyau sans
disposer pour cela d'un débogueur au niveau du code source. Ce travail avait
déjà été fait, dans Mach, et nous pensions déboguer les serveurs du Hurd en
tant que programmes utilisateur, à l'aide de GDB. Mais cela prit beaucoup de
temps et les serveurs à plusieurs fils d'exécution <cite>[multithreaded
servers]</cite>, qui s'envoyaient des messages les uns aux autres, se sont
révélés très difficiles à déboguer. Il a fallu de nombreuses années pour
faire fonctionner le Hurd de manière robuste.</p>

<h3>Alix</h3>
<p>
À l'origine, le noyau du système GNU n'était pas censé s'appeler Hurd. Son
premier nom était Alix – du nom de celle qui à l'époque était l'objet de ma
flamme. Administratrice de systèmes Unix, elle avait fait remarquer que son
prénom ressemblait aux noms typiques des versions de systèmes Unix ; elle
s'en était ouverte auprès d'amis en plaisantant : « Il faudrait baptiser un
noyau de mon nom. » Je n'ai rien dit, mais ai décidé de lui faire la
surprise avec un noyau appelé Alix.</p>
<p>
Mais les choses ont changé. Michael Bushnell (maintenant, il s'appelle
Thomas), le développeur principal du noyau, préférait le nom Hurd et a
confiné le nom Alix à une certaine partie du noyau – la partie qui se
chargeait d'intercepter les appels système et de les gérer en envoyant des
messages aux serveurs du Hurd.</p>
<p>
Plus tard, Alix et moi mîmes fin à notre relation et elle a changé de nom ;
de manière indépendante, le concept du Hurd avait évolué de telle sorte que
ce serait la bibliothèque C qui enverrait directement des messages aux
serveurs, ce qui a fait disparaître le composant Alix du projet.</p>
<p>
Mais avant que ces choses ne se produisent, un de ses amis avait remarqué le
nom d'Alix dans le code source du Hurd et s'en était ouvert auprès
d'elle. Elle a donc finalement eu l'occasion de découvrir un noyau à son
nom.</p>

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

<p>
Heureusement, on dispose d'un autre noyau. En 1991, Linus Torvalds a
développé un noyau compatible avec Unix et lui a donné le nom de Linux. Au
début c'était un logiciel privateur, mais en 1992 il l'a rendu libre ; la
jonction de Linux avec le système GNU, qui était presque complet, a donné un
système d'exploitation libre et complet (ce travail de jonction était
lui-même, bien sûr, considérable). C'est grâce à Linux qu'on peut désormais
employer une version du système GNU.</p>
<p>
Nous appelons cette version du système <a
href="/gnu/linux-and-gnu.html">GNU/Linux</a>, pour indiquer le fait que
c'est une combinaison du système GNU avec le noyau Linux. Je vous en prie,
ne vous laissez pas aller à appeler le système complet « Linux », puisque
cela équivaudrait à attribuer notre travail à quelqu'un d'autre. Merci de <a
href="/gnu/gnu-linux-faq.html">nous mentionner de manière équivalente</a>.</p>

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

<h3>Le matériel secret</h3>
<p>
Les fabricants de matériel tendent de plus en plus à garder leurs
spécifications secrètes. Cela rend plus difficile l'écriture de pilotes de
périphériques libres afin de permettre à Linux et au projet XFree86 de
reconnaître de nouveaux matériels. Nous disposons aujourd'hui de systèmes
entièrement libres, mais cela ne sera plus le cas à l'avenir si nous ne
pouvons pas gérer les ordinateurs de demain.</p>
<p>
On peut résoudre ce problème de deux manières. Les programmeurs peuvent
faire de la rétroingénierie pour comprendre comment gérer le matériel. Les
autres peuvent choisir le matériel qui est reconnu par du logiciel libre ;
plus nous serons nombreux, plus la politique du secret sur les
spécifications sera vouée à l'échec.</p>
<p>
La rétroingénierie est un travail considérable ; disposerons-nous de
programmeurs suffisamment déterminés pour le prendre en main ? Oui – si nous
sommes intimement persuadés que le logiciel libre est une question de
principe et que les pilotes non libres sont inacceptables. Et serons-nous
nombreux à dépenser un peu plus d'argent, ou à passer un peu plus de temps,
afin d'utiliser des pilotes libres ? Oui, si la détermination à revendiquer
la liberté se généralise.</p>
<p>
(Note de 2008 : ce problème s'applique également au BIOS. Il existe un BIOS
libre, <a href="http://www.libreboot.org/">LibreBoot</a> (une distribution
de coreboot) ; le problème est d'obtenir les spécifications des machines
pour que LibreBoot puisse les gérer sans recourir à des « blobs » non
libres.)</p>

<h3>Les bibliothèques non libres</h3>
<p>
Une bibliothèque non libre qui fonctionne sur des systèmes d'exploitation
libres se comporte comme un piège vis-à-vis des développeurs de logiciel
libre. Les fonctionnalités attrayantes de cette bibliothèque sont l'appât ;
si vous l'utilisez, vous tombez dans le piège car votre programme ne peut
pas faire partie utilement d'un système d'exploitation libre (en toute
rigueur, on pourrait y inclure le programme, mais on ne pourrait pas
<em>l'exécuter</em> en l'absence de la bibliothèque). Pire encore, si un
programme qui utilise une bibliothèque privatrice devient populaire, il peut
attirer dans le piège d'autres programmeurs peu soupçonneux.</p>
<p>
Ce problème s'est posé pour la première fois avec la boîte à outils Motif,
dans les années 80. Même s'il n'existait pas encore de systèmes
d'exploitation libres, le problème que Motif leur causerait plus tard était
évident. Le projet GNU a réagi de deux manières : en demandant aux projets
de logiciel libre d'utiliser les widgets de la boîte à outils libre
<cite>X Toolkit</cite> en parallèle avec Motif et en recherchant un
volontaire pour donner un remplaçant libre à Motif. Ce travail prit de
nombreuses années ; il a fallu attendre 1997 pour que LessTif, développé par
<cite>The Hungry Programmers</cite> (les Programmeurs affamés), devienne
capable de faire fonctionner la plupart des applications utilisant Motif.</p>
<p>
Entre 1996 et 1998, une autre boîte à outils non libre pour interface
graphique, nommée Qt, a été utilisée dans une importante collection de
logiciels libres, l'environnement de bureau <abbr title="K Desktop
Environment">KDE</abbr>.</p>
<p>
Les systèmes GNU/Linux libres ne pouvaient pas utiliser KDE, car nous ne
pouvions pas utiliser cette bibliothèque. Cependant, certains distributeurs
commerciaux de systèmes GNU/Linux n'ont pas été assez stricts dans leur
respect des règles du logiciel libre et ont ajouté KDE dans leurs systèmes,
ce qui en augmentait les capacités mais en réduisait la liberté. Le groupe
KDE encourageait activement de plus en plus de programmeurs à utiliser Qt et
des millions de « nouveaux utilisateurs de Linux » n'avaient jamais été
avertis du fait que tout ceci posait problème. La situation semblait
désespérée.</p>
<p>
La communauté du logiciel libre a répondu à ce problème de deux manières :
GNOME et Harmony.</p>
<p>
<abbr title="GNU Network Object Model Environment">GNOME</abbr> est le
projet de bureau de GNU. Démarré en 1997 par Miguel de Icaza et développé
avec l'aide de la société Red Hat Software, GNOME avait pour but de fournir
des fonctionnalités de bureau similaires en utilisant exclusivement du
logiciel libre. Il jouit aussi d'avantages techniques, comme de gérer toute
une variété de langages, pas seulement le C++. Mais son objectif principal
est la liberté : ne pas imposer l'utilisation du moindre logiciel non libre.</p>
<p>
Harmony est une bibliothèque compatible de remplacement, conçue pour
permettre l'utilisation des logiciels de KDE sans faire appel à Qt.</p>
<p>
En novembre 1998, les développeurs de Qt ont annoncé une modification de
leur licence qui, une fois effective, devrait faire de Qt un logiciel
libre. On ne peut pas en être sûr, mais je pense que cette décision est en
partie imputable à la réponse ferme de la communauté au problème que posait
Qt lorsqu'il n'était pas libre (la nouvelle licence n'est pas pratique ni
équitable, aussi demeure-t-il préférable d'éviter l'utilisation de Qt).</p>
<p>
[Note ultérieure : en septembre 2000, Qt a été republiée sous la GNU GPL, ce
qui pour l'essentiel a résolu le problème.]</p>
<p>
Comment répondrons-nous à la prochaine bibliothèque non libre mais
alléchante ? La communauté entière comprendra-t-elle la nécessité de ne pas
tomber dans le piège ? Ou serons-nous nombreux à préférer la facilité à la
liberté, ce qui donnera lieu à un autre problème majeur ? Notre avenir
dépend de notre philosophie.</p>

<h3>Les brevets logiciels</h3>
<p>
La pire menace provient des brevets logiciels, susceptibles de placer des
algorithmes et des fonctionnalités hors de portée du logiciel libre pendant
une période qui peut atteindre vingt ans. Les brevets sur l'algorithme de
compression LZW ont été déposés en 1983 et nous ne pouvons toujours pas
diffuser de logiciel libre qui produise des images au format <abbr
title="Graphics Interchange Format">GIF</abbr> correctement
compressées. [Note : ils ont expiré en 2009.] 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 <abbr title="MPEG-1 Audio Layer 3">MP3</abbr>. [En 2017, ces brevets
ont expiré. Regardez combien de temps il aura fallu attendre.]
</p>
<p>
Il existe plusieurs manières de faire face au problème des brevets : on peut
rechercher des preuves qu'un brevet est invalide, ou chercher d'autres
solutions pour remplir une tâche particulière. Mais chacune de ces méthodes
ne fonctionne que de temps en temps ; quand elles échouent toutes les deux,
un seul brevet peut mettre la totalité des logiciels libres dans
l'impossibilité d'offrir aux utilisateurs une fonctionnalité qu'ils
souhaitent. Après une longue attente, les brevets finissent par expirer,
mais que devons-nous faire d'ici là ?</p>
<p>
Ceux d'entre nous qui apprécient le logiciel libre pour la liberté qu'il
leur donne continueront à l'utiliser de toute façon. On pourra travailler
sans utiliser les fonctionnalités brevetées. Mais ceux d'entre nous qui
apprécient le logiciel libre parce qu'ils s'attendent à ce qu'il soit
techniquement supérieur diront probablement qu'il ne vaut rien, le jour où
un brevet l'empêchera de progresser plus avant. Ainsi, même s'il est utile
de parler de l'efficacité sur le plan pratique du développement de type
« bazar », ainsi que de la fiabilité et de la puissance de certains
logiciels libres, il ne faut pas s'en tenir là. Il nous faut parler de
liberté et de principes.</p>

<h3>La documentation libre</h3>
<p>
Il ne faut pas chercher les défauts les plus graves de nos systèmes
d'exploitation libres dans le logiciel; c'est l'absence de bons manuels
libres qu'on puisse inclure dans nos systèmes qui se fait le plus
cruellement sentir. La documentation est essentielle dans tout paquet
logiciel ; quand un paquet logiciel important ne dispose pas d'un bon manuel
libre, il s'agit d'une lacune majeure. On en compte de nombreuses
aujourd'hui.</p>
<p>
La documentation libre, tout comme le logiciel libre, est une question de
liberté, pas de prix. La définition d'un manuel libre est très proche de
celle du logiciel libre : il s'agit d'offrir certaines libertés à tous les
utilisateurs. Il faut autoriser la redistribution (y compris la vente
commerciale), en ligne et sur papier, de telle sorte que le manuel puisse
accompagner chaque copie du programme.</p>
<p>
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.</p>
<p>
Mais il existe une raison particulière pour laquelle il est crucial de
disposer de la liberté de modifier la documentation relative au logiciel
libre. Quand un programmeur exerce son droit de modifier le logiciel et
d'ajouter ou modifier des fonctionnalités, s'il est consciencieux il mettra
immédiatement à jour le manuel (afin de fournir une documentation précise et
utilisable aux côtés du programme modifié). Un manuel qui n'autorise pas les
programmeurs à être consciencieux et à terminer leur travail ne couvre pas
les besoins de notre communauté.</p>
<p>
Il n'y a pas de problème à poser certaines limites à la manière dont les
modifications sont faites. On peut accepter, par exemple, l'obligation de
conserver l'avis de copyright de l'auteur original, les conditions de
distribution, ou la liste des auteurs. Il n'y a pas non plus de problème à
exiger que les versions modifiées contiennent un avis indiquant qu'elles ont
été modifiées, voire à interdire de modifier ou d'ôter des sections
entières, pourvu que ces sections ne traitent pas de sujets techniques. En
effet cela n'interdit pas au programmeur consciencieux d'adapter le manuel
afin qu'il corresponde au programme modifié par ses soins. En d'autres
termes, cela n'empêche pas la communauté du logiciel libre d'utiliser
pleinement le manuel.</p>
<p>
En revanche, il faut autoriser la modification des portions
<em>techniques</em> du manuel et la distribution du résultat de ces
modifications par tous les médias habituels, à travers tous les canaux
habituels ; sans quoi, les restrictions sont un véritable obstacle pour la
communauté : le manuel n'est pas libre et il nous en faut un autre.</p>
<p>
Les développeurs de logiciel libre auront-ils conscience qu'il nous faut un
assortiment complet de manuels libres, seront-ils assez déterminés pour les
produire ? Une fois de plus, notre avenir dépend de notre philosophie.</p>

<h3>Il nous faut parler de la liberté</h3>
<p>
On estime aujourd'hui à dix millions le nombre d'utilisateurs de systèmes
GNU/Linux tels que Debian GNU/Linux et Red Hat « Linux » de par le monde. Le
logiciel libre propose tant d'avantages pratiques que les utilisateurs s'y
ruent pour des raisons purement pratiques.</p>
<p>
Cet état de fait a des conséquences heureuses, qui n'échapperont à
personne : le logiciel libre attire plus de développeurs, les entreprises du
logiciel libre ont plus de clients et il est plus facile d'encourager les
sociétés à développer des logiciels libres commerciaux, plutôt que des
logiciels privateurs.</p>
<p>
Mais l'intérêt pour le logiciel libre croît plus vite que la prise de
conscience de la philosophie sur laquelle il se fonde, et cela crée des
difficultés. Notre capacité à relever les défis et à répondre aux menaces
évoquées plus haut dépend de notre volonté de défendre énergiquement notre
liberté. Pour faire en sorte que notre communauté partage cette volonté, il
nous faut diffuser ces idées auprès des nouveaux utilisateurs au fur et à
mesure qu'ils rejoignent notre communauté.</p>
<p>
Mais nous négligeons ce travail ; on dépense bien plus d'efforts pour
attirer de nouveaux utilisateurs dans notre communauté qu'on n'en dépense
pour leur enseigner le civisme qui lui est attaché. Ces deux efforts sont
nécessaires et il nous faut les équilibrer.</p>

<h3>« Open Source »</h3>
<p>
En 1998, il est devenu plus difficile de sensibiliser les nouveaux
utilisateurs à la notion de liberté, quand une portion de notre communauté a
choisi d'arrêter d'utiliser le terme « logiciel libre » pour lui préférer la
dénomination « logiciel open source ».</p>
<p>
Certains de ceux qui ont choisi ce nouveau nom avaient en tête de mettre fin
à la confusion souvent constatée entre les mots <cite>free</cite> et
<cite>gratis</cite> – ce qui est un objectif valable. D'autres, au
contraire, cherchaient à laisser tomber l'attachement aux principes qui
avait toujours motivé le mouvement du logiciel libre et le projet GNU, afin
de cibler les cadres et les utilisateurs professionnels, dont beaucoup ont
une idéologie où la liberté, la communauté et les principes cèdent le pas au
profit. Ainsi, la rhétorique de l'open source met l'accent sur le potentiel
de faire du logiciel puissant et de grande qualité, mais occulte les notions
de liberté, de communauté et de principes.</p>
<p>
Les magazines « Linux » illustrent clairement cet exemple (ils sont bourrés
de publicités pour des logiciels privateurs qui fonctionnent sur
GNU/Linux). Quand le prochain Motif ou Qt poindra, ces magazines
mettront-ils les programmeurs en garde en leur demandant de s'en éloigner,
ou passeront-ils des publicités pour ces produits ?</p>
<p>
La communauté a beaucoup à gagner de la participation des entreprises ;
toutes choses étant égales par ailleurs, cette contribution est utile. Mais
sacrifier à cette aide les discours traitant de liberté et de principes peut
avoir des conséquences désastreuses ; cela augmente le déséquilibre
mentionné précédemment entre le recrutement de nouveaux utilisateurs et leur
l'éducation civique.</p>
<p>
Les termes « logiciel libre » et « open source » décrivent tous deux plus ou
moins la même catégorie de logiciel, mais ne disent pas la même chose sur le
logiciel et les valeurs qui lui sont associées. Le projet GNU continue
d'utiliser le terme « logiciel libre » pour exprimer l'idée que la liberté
est plus importante que la seule technique.</p>

<h3>Jetez-vous à l'eau</h3>
<p>
L'aphorisme de Yoda « <cite>There is no &lsquo;try&rsquo;</cite> »<a
id="TransNote9-rev" href="#TransNote9"><sup>i</sup></a> est séduisant, mais
il ne s'applique pas à moi. J'ai effectué la plupart de mes travaux sans
savoir si j'étais capable de les mener à bien et sans savoir si ces
derniers, une fois menés à bien, atteindraient les buts que je leur avais
fixés. Mais j'ai tenté ma chance, car il n'y avait personne d'autre que moi
entre l'ennemi et ma cité. À ma grande surprise, j'ai parfois réussi.</p>
<p>
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.</p>
<p>
Maintenant, il arrive souvent que je ne sois pas seul. C'est pour moi un
soulagement et une joie de constater que tout un régiment de hackers se
mobilise pour faire front et je réalise que cette cité a une chance de
survivre – pour le moment. Mais les dangers sont plus grands chaque année,
et maintenant la société Microsoft a explicitement pris notre communauté
dans son collimateur. L'avenir de la liberté n'est pas un fait acquis. Ne le
considérez pas comme tel ! Si vous souhaitez conserver votre liberté, vous
devez être prêts à la défendre.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<hr /><b>Notes de traduction</b><ol id="translator-notes-alpha">
<li id="TransNote1">En français, on peut utiliser le néologisme
« bitouilleur » pour désigner l'état d'esprit de celui qui « touille des
bits ». <a href="#TransNote1-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote2"><cite>Proprietary software</cite> se traduit souvent par
« logiciel propriétaire ». « Privateur » est un néologisme inventé par RMS
pour exprimer la notion que les logiciels propriétaires privent
l'utilisateur de ses libertés. <a href="#TransNote2-rev"
class="nounderline">&#8593;</a></li>
<li id="TransNote3">On peut rendre l'esprit de ce poème comme suit :<br />Si
je ne suis rien pour moi-même, qui sera pour moi ?<br />Si je suis tout pour
moi-même, que suis-je ?<br />Si ce n'est pas aujourd'hui, alors quand ? <a
href="#TransNote3-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote4">En anglais, le « libre » de « logiciel libre » se dit
<cite>free</cite>. Malheureusement, ce mot a une autre acception,
indépendante et incorrecte ici, il signifie également « gratuit ». Cette
ambiguïté a causé énormément de tort au mouvement du logiciel libre. <a
href="#TransNote4-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote5">Ce compilateur a été écrit à l'Université Libre
<cite>(Vrije Universiteit)</cite> d'Amsterdam. En anglais, le placement des
mots ne permet pas de déterminer s'il s'agit du « kit de compilation libre
de l'université » ou du « kit de compilation de l'Université Libre ». <a
href="#TransNote5-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote6">« Couvert par le gauche d'auteur, tous droits
renversés. » <a href="#TransNote6-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote7">Le mot anglais <cite>bash</cite> a le sens de « coup,
choc » et la signification de cet acronyme est double ; c'est à la fois une
nouvelle version de l'interpréteur de commandes de Bourne, et une allusion
aux chrétiens qui se sont sentis renaître dans cette religion et qu'aux
États-Unis d'Amérique on qualifie de <cite>born-again Christians</cite>. <a
href="#TransNote7-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote8">Littéralement, « [logiciel dont le] code source est
ouvert ». C'est une périphrase lourde et inélégante en français, mais qui
résout en anglais l'ambiguïté discutée plus haut, bien que RMS rejette cette
solution pour des raisons expliquées à la fin de cet article. <a
href="#TransNote8-rev" class="nounderline">&#8593;</a></li>
<li id="TransNote9">L'aphorisme complet est : <cite>Try not. Do, or do
not. There is no &lsquo;try&rsquo;.</cite> Ce qui pourrait se traduire par :
« N'essaie pas. Fais, ou ne fais pas. “Essayer” n'existe pas. » <a
href="#TransNote9-rev" class="nounderline">&#8593;</a></li>
</ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.fr.html" -->
<div id="footer">
<div class="unprintable">

<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Il existe aussi <a
href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens
orphelins et autres corrections ou suggestions peuvent être signalés à <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Nous faisons le maximum pour proposer des traductions fidèles et de bonne
qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires
sur cette page, ainsi que vos suggestions d'ordre général sur les
traductions, à <a href="mailto:web-translators@gnu.org">
&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Pour tout renseignement sur la coordination et la soumission des
traductions de nos pages web, reportez-vous au <a
href="/server/standards/README.translations.html">guide de traduction</a>.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
2017, 2018, 2020 Richard Stallman</p>

<p>Cette page peut être utilisée suivant les conditions de la licence <a
rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.fr">Creative
Commons attribution, pas de modification, 4.0 internationale (CC BY-ND
4.0)</a>.</p>

<!--#include virtual="/server/bottom-notes.fr.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
Traduction : Sébastien Blondeel.<br /> Révision : <a
href="mailto:trad-gnu&#64;april.org">trad-gnu&#64;april.org</a></div>

<p class="unprintable"><!-- timestamp start -->
Dernière mise à jour :

$Date: 2020/07/12 07:59:22 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>