[Traduit de l'anglais]

Libre mais entravé - le piège Java

Note préliminaire

Depuis la parution de cet article, Sun (qui fait maintenant partie d'Oracle) a fait passer l'essentiel de l'implémentation de référence de sa plateforme Java sous la licence publique générale GNU ; il y a donc maintenant un environnement de développement libre pour Java. Ainsi le langage Java n'est plus un piège.

Vous devez faire attention, cependant, parce que toutes les plateformes Java ne sont pas libres. Sun continue à distribuer une plateforme Java exécutable qui n'est pas libre et d'autres sociétés font de même.

L'environnement libre pour Java s'appelle IcedTea ; le code source libéré par Sun y est inclus. C'est donc cet environnement que vous devez utiliser. Beaucoup de distributions GNU/Linux sont fournies avec IcedTea, mais certaines contiennent des plateformes Java non libres. (Note ajoutée en octobre 2015 : l'implémentation libre de Java s'appelle OpenJDK dans beaucoup de distributions GNU/Linux.)

Pour vous assurer de manière fiable que votre programme Java s'exécutera correctement dans un environnement libre, vous devez le développer avec IcedTea. Théoriquement les plateformes Java devraient être compatibles, mais elles ne le sont pas à 100%.

De plus, il y a des programmes non libres dont le nom contient « Java », comme JavaFX, et il y a des paquets Java non libres qui pourraient vous tenter mais que vous devez rejeter. Donc vérifiez les licences de tout paquet que vous envisagez d'utiliser. Si vous utilisez Swing, faites en sorte d'utiliser la version libre, qui est fournie avec IcedTea. (Note ajoutée en octobre 2015 : un programme libre remplaçant JavaFX a été publié sous le nom d'OpenJFX.)

Mis à part ces problèmes spécifiques à Java, le problème général décrit ici demeure important, car toute bibliothèque ou plateforme de programmation non libre peut causer un problème similaire. Nous devons retenir la leçon de l'histoire de Java de manière à éviter d'autres pièges à l'avenir.

Veuillez aussi consulter : Le piège JavaScript.


Le 12 avril 2004

Si votre programme est un logiciel libre, il est éthique par nature, mais il y a un piège dont il faut se méfier. Bien qu'intrinsèque, la liberté de votre programme peut être restreinte à cause de logiciels non libres dont il dépend. Comme c'est avec les programmes Java que ce problème est aujourd'hui le plus évident, nous l'avons nommé le « piège Java ».

Un programme est un logiciel libre si ses utilisateurs possèdent certaines libertés fondamentales. En gros, il s'agit de : la liberté d'exécuter le programme, la liberté d'en étudier et modifier le code source, la liberté d'en redistribuer les fichiers source et binaires, et la liberté d'en publier des versions améliorées (voir la définition du logiciel libre). Qu'un programme donné soit un logiciel libre ne dépend que de la signification de sa licence.

Que le programme puisse être utilisé dans le monde du Libre, utilisé par des personnes qui entendent vivre en toute liberté, est une question plus compliquée. La seule licence du programme ne détermine pas cela, car aucun programme ne fonctionne en isolement total. Chaque programme dépend d'autres programmes. Par exemple, il nécessite d'être compilé ou interprété, il dépend donc d'un compilateur ou d'un interpréteur. S'il est compilé en pseudo-code binaire, il dépend d'un interpréteur de pseudo-code. Qui plus est, pour s'exécuter il a besoin de bibliothèques et peut faire appel à d'autres programmes qui s'exécutent sous d'autres processus. Tous ces programmes sont des dépendances. Ces dernières peuvent être totalement indispensables à l'exécution du programme, ou juste nécessaires à certaines de ses fonctionnalités. D'une façon ou d'une autre, tout ou partie du programme ne peut pas fonctionner sans elles.

Que certaines des dépendances d'un programme ne soient pas libres signifie que tout ou partie du programme ne peut s'exécuter sur un système totalement libre – il est inutilisable dans le monde du Libre. Bien sûr, nous pouvons distribuer le programme et en avoir des copies sur nos machines, mais cela ne sert pas à grand-chose s'il ne s'exécute pas. Ce programme est un logiciel libre, mais il est en fait entravé par des dépendances non libres.

Ce problème peut se produire avec n'importe quel type de logiciel, n'importe quel langage. Par exemple, un programme libre qui ne fonctionne que sous Microsoft Windows est parfaitement inutilisable dans le monde du Libre. Mais des logiciels qui tournent sous GNU/Linux peuvent aussi être inutilisable lorsqu'ils dépendent d'autres logiciels non libres. Par le passé, Motif (avant que nous ayons LessTif) et Qt (avant que ses développeurs n'en fassent un logiciel libre) étaient les causes principales de ce problème. La plupart des cartes vidéo 3D ne fonctionnent pleinement qu'avec des pilotes non libres, ceci pose également un problème. Mais en ce moment, la cause principale de ce problème est Java, parce que certaines personnes qui écrivent des logiciels libres pense que le langage Java est sexy. Aveuglés par l'attrait du langage, ils sous-estiment le problème des dépendances et tombent dans le piège Java.

L'implémentation Java de Sun est non libre. Les bibliothèques Java standard sont aussi non libres ; c'est une adaptation du code privateur (propriétaire) de Sun. Les bibliothèques de base de Java sont non libres aussi. Bien sûr, nous disposons d'implémentations libres de Java, comme le compilateur GNU pour Java (GCJ) et GNU Classpath, mais ils ne gèrent pas encore toutes les fonctionnalités. Nous sommes encore en train de rattraper le retard.

Si vous développez un programme Java sur la plateforme Java de Sun, vous êtes voué à utiliser des fonctionnalités Sun exclusives sans même vous en rendre compte. Vous pourriez les avoir utilisées pendant des mois avant de le découvrir et reprendre la tâche pourrait prendre plus de mois encore. Vous pourriez vous dire : « Recommencer demande trop de travail. » Alors votre programme sera tombé dans le piège Java ; il sera inutilisable dans le monde du Libre.

Le truc fiable pour éviter le piège Java est de n'avoir qu'une implémentation libre de Java sur votre système. Ainsi, si vous utilisez une fonctionnalité ou une bibliothèque que le logiciel libre ne supporte pas encore, vous vous en rendrez compte immédiatement et vous pourrez réécrire ce code tout de suite.

Sun continue de créer des bibliothèques « de base » supplémentaires, presque toutes non libres ; dans bien des cas, même les spécifications de la bibliothèque sont des secrets de fabrication. De plus, la dernière licence de Sun concernant ces spécifications interdit la publication d'une mise en œuvre partielle de ces dernières (voir par exemple Java Specification Participation Agreement et J2ME™ Personal Basis Profile Specification).

Heureusement, la licence de ces spécifications permet d'en publier une mise en œuvre libre ; ceux qui recevraient une telle bibliothèque peuvent être autorisés à la modifier et ne sont pas tenus d'en suivre les spécifications. Mais cette clause a pour effet d'interdire l'utilisation d'un modèle de développement collaboratif pour produire cette mise en œuvre libre. L'utilisation d'un tel modèle impliquerait la parution de versions incomplètes, ce qui est interdit aux personnes ayant lu les spécifications.

Aux premiers jours du mouvement du logiciel libre, il était impossible de ne pas dépendre de programmes non libres. Avant que nous ne disposions du compilateur C de GNU, tous les programmes C (qu'ils fussent libres ou non) dépendaient d'un compilateur C non libre. Avant que nous ne disposions de la bibliothèque C de GNU, tous les programmes dépendaient d'une bibliothèque C non libre. Avant que nous ne disposions de Linux, le premier noyau libre, tous les programmes dépendaient d'un noyau non libre. Avant que nous ne disposions de BASH, chaque script shell devait être exécuté par un interpréteur non libre. Il était inévitable que nos premiers programmes soient initialement sous le joug de ces dépendances, mais ceci était acceptable car leur sauvetage ultérieur faisait partie de notre plan. Notre objectif global, un système d'exploitation autonome, comprenait des remplacements libres à toutes ces dépendances ; si nous atteignions ce but, tous nos programmes seraient sauvés. Et c'est ce qui se produisit : avec le système GNU/Linux, nous pouvons à présent exécuter ces programmes sur des plateformes libres.

La situation est différente aujourd'hui. Nous disposons à présent de systèmes d'exploitation puissants et de nombreux outils de programmation libres. Quelle que soit la tâche que vous ayez à exécuter, vous pouvez le faire sur une plateforme libre ; il n'est plus nécessaire, même temporairement, d'accepter des dépendances non libres. À ce jour, la raison principale pour laquelle les gens tombent dans le piège est que cela ne leur vient pas à l'esprit. La plus simple des solutions concernant le piège Java est d'apprendre aux gens à ne pas tomber dedans.

Afin de protéger votre code Java du piège Java, installez un environnement de développement Java libre et utilisez-le. De façon générale, quel que soit le langage que vous utilisiez, ouvrez l'œil et assurez-vous du statut libre des programmes dont dépend le code de vos programmes. La façon la plus simple de vérifier si ce programme est libre est de s'assurer qu'il possède une entrée dans le répertoire du logiciel libre. Si un programme n'est pas dans ce répertoire, vous pouvez vérifier si la licence qui l'accompagne est dans la liste des licences de logiciel libre.

Nous sommes en train d'essayer de sauver les programmes Java piégés, alors si vous aimez le langage Java, nous vous invitons à nous aider à développer GNU Classpath. Vous pouvez aussi aider en essayant vos programmes avec le compilateur GCJ et GNU Classpath. Toutefois, cela prendra du temps pour terminer GNU Classpath ; si d'autres bibliothèques non libres continuent à y être ajoutées, il se peut que nous n'ayons jamais les plus récentes. Alors s'il vous plaît, ne placez pas d'entraves sur vos logiciels libres. Faites en sorte que l'application que vous écrivez en ce moment soit conçue pour fonctionner dans un environnement libre dès le départ.

Voir également :

Le curieux non-événement de Sun dans la pénombre