From 1ae0306a3cf2ea27f60b2d205789994d260c2cce Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 11 Oct 2020 13:29:45 +0200 Subject: add i18n FSFS --- talermerchantdemos/blog/articles/fr/java-trap.html | 295 +++++++++++++++++++++ 1 file changed, 295 insertions(+) create mode 100644 talermerchantdemos/blog/articles/fr/java-trap.html (limited to 'talermerchantdemos/blog/articles/fr/java-trap.html') diff --git a/talermerchantdemos/blog/articles/fr/java-trap.html b/talermerchantdemos/blog/articles/fr/java-trap.html new file mode 100644 index 0000000..1fad082 --- /dev/null +++ b/talermerchantdemos/blog/articles/fr/java-trap.html @@ -0,0 +1,295 @@ + + + + + + +Libre mais entravé - le piège Java - Projet GNU - Free Software Foundation + + + +

Libre mais entravé - le piège Java

+ +

par Richard Stallman

+ + +

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 http://www.gnu.org/philosophy/free-sw.html). +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 http://jcp.org/aboutJava/communityprocess/JSPA2.pdf [en] +et http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html [en]). +

+ +

+ 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 (http://www.fsf.org/directory). 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 (http://www.gnu.org/licenses/license-list.html). +

+ +

+ 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

+ +
+ + +
+ + + + + + + + -- cgit v1.2.3