Les défis à venir

Le matériel secret

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

On peut résoudre ce problème de deux manières. Les programmeurs peuvent analyser l'ensemble afin de deviner comment prendre en compte le matériel. Les autres peuvent choisir le matériel qui est reconnu par du logiciel libre ; plus nous serons nombreux, plus la politique de garder les spécifications secrètes sera vouée à l'échec.

L'ingénierie à l'envers est un travail conséquent ; disposerons-nous de programmeurs suffisamment déterminés pour le prendre en main ? Oui — si nous avons construit un sentiment puissant selon lequel le logiciel libre est une question de principe, et que les pilotes non libres sont inacceptables. Et serons-nous nombreux à dépenser un peu plus d'argent, ou à passer un peu de temps, pour que nous puissions utiliser des pilotes libres ? Oui — si la détermination afférente à la liberté est largement répandue.

Les bibliothèques non libres

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

Ce problème s'est posé pour la première fois avec la boîte à outils Motif, dans les années 80. Même s'il n'existait pas encore de systèmes d'exploitation libres, il était limpide que Motif leur causerait des problèmes, plus tard. Le projet GNU a réagi de deux manières : en demandant aux projets de logiciel libre de rendre l'utilisation de Motif facultative en privilégiant les gadgets de la boîte à outils X, libre, et en recherchant un volontaire pour écrire une solution de remplacement libre à Motif. Ce travail prit de nombreuses années ; LessTif, développé par les Hungry Programmers (les « Programmeurs affamés »), n'est devenu suffisamment étendu pour faire fonctionner la plupart des applications utilisant Motif qu'en 1997.

De 1996 à 1998, une compilation conséquente de logiciel libre, le bureau KDE, a fait usage d'une autre bibliothèque non libre de boîte à outils pour l'interface graphique utilisateur, appelée Qt.

Les systèmes GNU/Linux libres ne pouvaient pas utiliser KDE, car nous ne pouvions pas utiliser la bibliothèque. Cependant, certains distributeurs commerciaux de systèmes GNU/Linux n'ont pas été assez stricts pour coller au logiciel libre et ont ajouté KDE dans leurs systèmes — produisant un système disposant d'un plus grand nombre de fonctionnalités, mais souffrant d'une liberté réduite. Le groupe KDE encourageait activement un plus grand nombre de programmeurs à utiliser la bibliothèque Qt, et des millions de « nouveaux utilisateurs de Linux » n'ont jamais eu connaissance du fait que tout ceci posait un problème. La situation était sinistre.

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

GNOME, le GNU Network Object Model Environment (environnement de GNU de modèle d'objets pour le réseau), est le projet de bureau de GNU. Démarré en 1997 par Miguel de Icaza, et développé avec l'aide de la société Red Hat Software™, GNOME avait pour but de fournir des fonctionnalités de bureau similaires, en utilisant exclusivement du logiciel libre. Il jouit aussi d'avantages techniques, comme le fait de collaborer avec toute une variété de langages, et de ne pas de se limiter au C++. Mais son objectif principal est la liberté : ne pas imposer l'utilisation du moindre logiciel non libre.

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

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

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

Les brevets sur les logiciels

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, la menace d'une poursuite pour cause de violation de brevets a mis fin à la distribution d'un programme libre qui produisait des données sonores compressées au format MP3.

Il existe plusieurs manières de répondre au problème des brevets : on peut rechercher des preuves qui invalident un brevet, et on peut rechercher d'autres solutions pour remplir une tâche. Mais chacune de ces méthodes ne fonctionne que dans certains cas ; quand les deux échouent, il se peut qu'un brevet empêche le logiciel libre de disposer de fonctionnalités souhaitées par les utilisateurs. Que ferons-nous dans ce genre de situation ?

Ceux d'entre nous qui prêtent de la valeur au logiciel libre par amour de la liberté continueront à utiliser du logiciel libre dans tous les cas. On pourra travailler sans utiliser de fonctionnalités protégées par des brevets. Mais ceux d'entre nous qui prêtent de la valeur au logiciel libre car ils s'attendent à trouver là des logiciels techniquement supérieurs sont susceptibles de critiquer l'idée même du logiciel libre quand un brevet l'empêchera de progresser plus avant. Ainsi, même s'il est utile de discuter de l'efficacité, dans la pratique, du modèle de développement de type « cathédrale », et de la fiabilité et de la puissance de certains logiciels libres, il ne faut pas s'en tenir là. Il nous faut parler de liberté et de principes.

La documentation libre

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 prix[1]. La raison d'être d'un manuel libre est très proche de celle d'un logiciel libre : il s'agit d'offrir certaines libertés à tous les utilisateurs. Il faut autoriser la redistribution (y compris la vente commerciale), en ligne et sur papier, de telle sorte que le manuel puisse accompagner toute copie du programme.

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

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

Il est acceptable d'apposer certaines limites sur la manière dont les modifications sont faites. Il est par exemple envisageable d'exiger de préserver la notice de copyright de l'auteur original, les conditions de distribution, ou la liste des auteurs. D'exiger que les versions modifiées contiennent une notice qui stipule qu'elles ont été modifiées, et même d'interdire de modifier ou d'ôter des sections entières, pourvu que ces sections ne traitent pas de considérations techniques, ne pose pas non plus de problèmes, car cela n'interdit pas au programmeur consciencieux d'adapter le manuel afin qu'il corresponde au programme modifié par ses soins. En d'autres termes, cela n'empêche la communauté du logiciel libre d'utiliser pleinement le manuel.

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

Les développeurs de logiciels libres seront-ils déterminés, auront-ils conscience du fait qu'il est nécessaire de produire tout un spectre de manuels libres ? Une fois de plus, notre avenir dépend de notre philosophie.

Il nous faut faire l'apologie de la liberté

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

Cet état de fait a des conséquences heureuses, qui n'échapperont à personne : on voit plus de développeurs intéressés par la production de logiciels libres, les entreprises de logiciels libres comptent plus de clients, et il est plus facile d'encourager les sociétés à développer des logiciels libres commerciaux, plutôt que des produits logiciels propriétaires.

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

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