Brave GNU World

(jpeg 7k)

Bienvenue dans ce nouveau numéro de Brave GNU World. Comme d'habitude, je commencerai par du pratique pour avancer lentement vers le théorique.

Sawmill

Sawmill [5] est un gestionnaire de fenêtre créé par John Harper qui est extensible via son propre language script, comme Emacs. Ce langage était à l'origine proche du Lisp d'Emacs, mais il inclut maintenant des éléments de Scheme et est donc devenu un mélange des deux.

Pour rester rapide et petit malgré cette extensibilité, Sawmill n'inclut rien qui puisse être fait par d'autre programme, comme gérer le fond d'écran ou présenter une barre de tâches. Son seul but est de gérer les fenêtres de la meilleure manière, la plus souple et la plus attractive.

Le programme en lui-même est un noyau de primitives en C. Les fonctions sont développées par des scripts, ce qui permet de ré-écrire n'importe quelle partie selon son propre goût. Personellement, je pense qu'il est important que chaque fonction puisse être liée à n'importe quelle touche, selon le contexte déterminé par le "focus" de la souris.

Bien sûr, Sawmill supporte les thèmes [6] et est livré avec l'imitation de certains thème bien connus d' Enlightenment. Combiné avec une bonne intégration GTK+ et GNOME, cela donne à Sawmill le potentiel de devenir le gestionnaire de fenêtres standard "de-facto" de GNOME.

Malgré toutes ses fonctionalités, les "utilisateurs purs" ne doivent pas se sentir intimidés parce qu'à peu près tout peut être configuré via un outil de configuration graphique.

Selon John Harper les plans incluent le support KDE et l'élimination des derniers bogues restants. Son autre objectif est d'empécher l'introduction de nouvelles fonctionalités afin de garder Sawmill petit, rapide, et efficace.

Je continue avec un projet qui est sur le point de démarrer.

Free Unix Benchmark Project

Stefan Carstens me dit qu'il a commencé le "Free Unix Benchmark Project" (Projet Libre de Mesure des Unix). Pour le moment, les tests disponibles soit ne mesurent que de petites sous-parties du système, ignorant certaines tâches importantes spécifiques de Unix, ou alors ils sont propriétaires et donc non transparents. Un autre problème, c'est qu'ils sont disséminés sur le net, sans aucun point central.

Le but est donc de créer une "suite de test" complète qui permettra de lancer tous les tests depuis un seul programme. On prévoit aussi d'inclure des tests pour les parties réseau, par exemple la pile TCP/IP. Vu qu'un tel test n'est pas encore disponible, le projet devrait soulever un intérêt certain très vite. Le choix de la licence permettra aussi une diffusion rapide puisque ce sera la licence publique GNU générale et la licence publique GNU moins générale. Le code source étant également disponible, les tests seront reproductibles et transparent, ce qui est important pour une suite de tests.

Les résultats seront affichés en unités simples et comparables pour que l'utilisateur "normal" puisse aussi travailler avec la suite. Les différentes parties du système pourront être réglées et comparées via un utilitaire spécial. Une sortie vers GNUPlot est également prévue, et je suis sûr que ce ne sera pas un problème de prévoir également une sortie vers une base de données.

Si vous avez envie d'attraper ce logiciel et de l'installer, il vous faudra attendre. Mais si vous êtes intéréssé à prendre part à ce projet, écrivez à Stefan Carstens [7]; il a été très clair quand à son appel pour des participants.

Ceci étant dit, j'en viens à un sujet qui me touche particulièrement à coeur .

Droits de L'Homme à l'Information, partie II

Après ma déclaration des "Droits de L'Homme à l'Information" dans le numéro 8 de Brave GNU World, j'ai reçu énormément de réponses positives. Parmi elles, celle de Ken Engel qui m'a envoyé des changements intéressants que j'aimerai partager avec vous.

Son premier amendement aux Droits de L'Homme à l'Information dit: "La liberté de "reverse engineer" ne sera pas abolie." Son exemple était qu'il est tout à fait légal de démonter sa voiture et de la remonter, et de la réparer. La même chose est illégale avec les logiciels propriétaires, et le faire peut non seulement vous coûter de l'argent mais aussi vous envoyer en prison.

Le second changement se fonde sur l'expérience acquise en devant écrire des applications avec un environnement de développement propriétaire. L'environemment en question étant propriétaire, les données sont enfermées dans un format binaire opaque. La seule manière d'y accéder est via une interface graphique lente et très compliquée. D'où le second amendement aux Droits de L'Homme à l'Information: "les données des clients et utilisateurs ne seront pas enfermées dans le produit du vendeur."

Le dernier point combat la mentalité masochiste et le fait que souvent les dévelloppeurs se voient interdire d'utiliser le meilleur outil pour le travail: "Le choix du logiciel ne sera pas dicté par des employeurs au mépris de l'expertise des employés, limitant ainsi leur choix de pratiques de développement et de platte-formes et limitant leur productivité."

Je suis certain que beaucoup d'entre vous peuvent s'identifier avec au moins un de ces amendements.

J'en viens maintenant à la deuxième partie promise de mes souvenirs de "Systems `99".

La licence "Source Communautaire" de Sun (Sun Community Source License)

Environ une semaine avant mon départ pour "Systems", Marco Boerries, le fondateur de Star Division, a donné une entrevue à un magazine britannique. Dans cette entrevue, il disait qu'il ne comprenait pas pourquoi la licence Sun était considérée aussi négativement, alors qu'il la considérait, lui, comme supérieure à la GPL.

Pour prouver cette affirmation, ila expliqué que le consomateur attend une garantie sur les droits de propriété du code qu'il achète, et que la GPL ne permet pas cela. Du point de vue d'une entreprise produisant et vendant à l'ancienne, cette affirmation est normale, mais dans ce contexte, elle ne prouve que l'incompréhension du modèle commercial du logiciel libre.

Première incompréhension: le consommateur achète le logiciel qui devient sa "propriété". Si on vole le code, alors le consommateur perdrait son argent. Me lancer dans une explication de pourquoi le vol de code source propriétaire (vu que le logiciel libre ne peut pas être volé) pour l'utiliser dans du logiciel libre sortirait de mon propos. J'ignore donc ce point pour le moment, j'y reviendrai si cela vous intéresse.

Cette foiss je voudrais me concentrer sur la question de savoir pourquoi le "modèle de propriété" n'a pas de sense lorque l'on parle de logiciel. Cependant, pour ce faire, je vais devoir plonger dans les concepts de base.

L'ancien modèle commercial est de concevoir un produit, le produire et le vendre. La production à la chaîne laisse peu de place au goût individuel, autrement les coûts exploseraient. C'est la raison pour laquelle les produits sont conçus pour aller le mieux possible à une personne moyenne qui souvent n'existe même pas dans la réalité. Après, c'est au vendeur de convaincre tout le monde que que le produit est fait spécialement pour eux et qu'ils devraient l'acheter car il les rendra heureux.

Ce modèle commercial "vie réelle" a été transféré sans autre forme de procès à l'industrie logicielle. On crée des piles de bit et d'octets qui sont vendues au consommateur en suggérant que la possession de cette pile résoudra tous les problèmes. La vraie raison de ce concept, la production à la chaîne, n'existe cependant pas dans l'espace virtuel du logiciel. Le logiciel peut être adapté au consommateur mieux que n'importe quel autre produit. Il est cependant enfermé dans des habitudes de comportement dont la nécessité a disparu depuis longtemps.

C'est la raison pour laquelle le modèle du logiciel libre se concentre sur la solution du problème plutôt que sur la possession de la solution. Et c'est pour cette raison que la discussion des droits de propriété n'a pas lieu d'être. Pour le consommateur, peu importe que le logiciel soit sa propriété, tant que son problème est résolu.

En fait, c'est préférable pour le consommateur que le logiciel n'appartienne à personne: ni à lui, ni à la société qui lui a fourni. La valeur du logiciel est déterminée par la maintenance qui en est faite. Sans ce service, le logiciel perd rapidement son utilité. Avec un logiciel propriétaire, l'utilisateur achète rarement le logiciel lui-même, mais plutôt le droit d'acheter une version spécifique. Mais bien entendu cette version est statique et son utilisation se dégrade rapidement. Le consommateur doit alors acheter rapidmeent une nouvelle version, que le développement aille dans une direction qui l'aide - ou pas !

De plus, le consommateur entre dans une dépendance dangereuse. En choisissant un certain produit propriétaire, le succès de l'entreprise du consommateur est lié au succès du fournisseur de logiciel, même si souvent, ce n'est pas évident. Seul le logiciel libre garanti au consommateur la sécurité de son succès en le rendant indépendant du vendeur de logiciel. De plus, le développement du logiciel peut être influencé de plusieurs manières afin de lui faire rencontrer les besoins futurs.

Cela m'amène au deuxième point. Marco Boerries disait que la raison pour laquelle on n'aime pas la licence Sun, c'est parce que Sun a du succès et s'enrichit. Ce n'est pas vrai. L'ensemble des acteur du logiciel libre se réjouit du succès financier d'acteur comme RedHat qui utilise la Licence Publique Générale GNU sur une large échelle.

Le problème de la licence Sun est ailleurs. Même si le code source est visible, il est interdit de le modifier et de le passer à quelqu'un d'autre. Tous les changements doivent être envoyés à Sun et seul Sun décide si ces changements seront appliqués. Finalement, Sun garde tous les droits. Ce que Sun a réussi à faire de cette manière, c'est une espèce de "licence source libre propriétaire". La raison la plus importante de l'utilisation et du succès du logiciel libre, la liberté, n'a pas été donnée à l'utilisateur. C'est pourquoi nous n'aimons pas la licence Sun, pas plus que tout autre licence propriétaire.

Voilà, c'est fini pour ce mois-ci. Comme d'habitude j'espère recevoir des échos sous forme d'idées, commentaires et questions, que vous enverrez à l'adresse habituelle: [1].

numéro suivant

Retour au Site GNU.

Envoyez vos questions sur GNU et FSF à gnu@gnu.org. Il y a aussi d'autres manières de contacter la FSF.

Envoyez vos commentaires sur "Brave GNU World" à column@gnu.org, et les commentaires sur cette page à webmasters@www.gnu.org, les autres questions à gnu@gnu.org.

Copyright (C) 2000 Georg C. F. Greve, Version allemande publiée dans Linux-Magazin

Permission vous est donnée de distribuer des copies exactes de cette page tant que cette note de permission et le copyright apparaissent clairement.

Remise à jour : $Date: 2002/02/13 17:52:13 $ $Author: r4f $ Traduction: Thunus F.