[DE | EN | FR | JA | ES | KO | PT]

Bienvenue à cette nouvelle édition du Brave GNU World de Georg. Ce mois-ci je parlerai beaucoup des fondements philosophiques concernant le Logiciel Libre commercial. Mais en premier lieu, j'aimerais introduire quelques projets.

TuxFamily.org

Julien croit que les communautés européenne et africaine ont besoin d'un tel service sur leurs continents. C'est justement ce que le projet TuxFamily cherche à fournir.

Clairement, TuxFamily est fortement orientée vers le Logiciel Libre. Le logiciel mis en oeuvre pour l'hébergement (vhffs) est lui-même publié sous la licence GNU LPG. De plus la TuxFamily accepte exclusivement des projets qualifiés de logiciels libres.

Ainsi les projets à la recherche d'un nouvel hébergeur peuvent envisager de rejoindre la TuxFamily.

Chrooted SSH CVS-Server HOWTO (comment mettre en place un serveur CVS avec une modification de répertoire racine)

Sur le site communautaire d'IdealX [7] vous pourrez trouver plusieurs modules et documents concernant les logiciels libres. Ils résoudront un certain nombre de problèmes standards et naturellement tout est disponible sous Licence Publique Générale GNU et Licence de Documentation Libre GNU.

Parmi ces paquetages, un module Python qui permet de créer des calendriers dans des scripts CGI. Vous pourrez également y trouver un script de notification CVS configurable en XML pour automatiser les actions pendant l'introduction de nouvelles versions ou une fonctionnalité pour lier du code Erlang dans des programmes Python.

Le Howto («Comment faire») [8] écrit par Olivier Berger et Olivier Tharan, qui traite de la mise en place d'un serveur CVS de manière très sure et très isolée, est un document extrêmement intéressant.

Les programmeurs connaissent normalement les avantages du «Système de Versions Concurrentes» (CVS) [9], mais CVS est un outil que beaucoup de gens sous-estiment particulièrement, donc j'en donnerai un aperçu rapide.

Comme chacun sait, un logiciel est écrit sous forme de code source. Ce code source est amélioré par un ou plusieurs auteurs pendant le processus de développement. Pendant cette phase, survient le problème de coordination de plusieurs développeurs, car normalement chaque développeur restera assis à son propre poste de travail pour apporter des modifications au code source. Cela signifie que ce dernier est modifié fréquemment à différents endroits.

Pour résoudre ce problème, CVS (comme d'autres «systèmes de contrôle de versions») a un point central de collecte, nommé «repository». Chaque développeur communique directement avec le repository, en recevant les mises à jour effectuées par les autres développeurs ou en soumettant ses propres modifications. Naturellement, il peut arriver que deux auteurs modifient la même partie, mais les différentes manières de résoudre ou d'éviter de tels conflits ne sont pas importantes pour le moment.

Ce qui importe c'est que le repository CVS ne contienne pas uniquement la version courante, il sauvegarde également chaque modification. La manière dont le développement se déroule peut être suivi pas à pas, plus tard. Il est également possible de revenir à des versions plus anciennes afin de faire bifurquer un projet et avoir des processus de développement différents, qui progressent en parallèle avec l'option de fusionner tout cela ultérieurement.

Tout cela n'est pas uniquement intéressant pour les développeurs. Considérant que le code source est sous forme de simples fichiers ASCII dans la plupart des cas, il est tout de suite évident que cet outil peut être utilisé pour n'importe quelle sorte de données, particulièrement si elles peuvent s'exprimer sous forme de texte brut.

Des sites web, des documents, des archives de courriers électroniques et beaucoup d'autres sont de parfaits domaines d'application de CVS.

Le point névralgique d'un serveur CVS se situe dans ses droits d'accès. Il existe plusieurs possibilités pour gérer cela, qui ont différents niveaux de sécurité. Dans la plupart des cas, un compte sur le serveur CVS nécessite un compte sur le système, et plusieurs parmi ces méthodes transmettent les mots de passe «en clair», de sorte qu'il est aisé à des tiers de les intercepter.

Même si on peut éviter cela par l'usage de SSH, il n'est souvent pas souhaitable de donner à chaque utilisateur de CVS un accès global au système.

Le Howto [8] cité ci-dessus décrit très bien comment configurer plusieurs serveur CVS en parallèle sur un serveur, tout en autorisant aux utilisateurs seulement les droits nécessaires pour accéder à un repository spécifique. Cela devrait permettre à la majorité des utilisateurs moyens d'installer un serveur CVS sécurisé sur leur propre machine afin d'exploiter les avantages de CVS susmentionnés.

AutoGen

Exemple classique : les boucles mises en oeuvre dans l'évaluation de la ligne de commande. Dans le pire des cas, le texte est répété avec des couper/coller pour chaque option afin de fixer les valeurs, afin que d'autres fonctions puissent les retrouver ultérieurement. Comme il s'agit d'un problème très courant, AutoGen possède pour gérer cela un patron (template en anglais) appelé "AutoOpts".

AutoGen comporte certaines similitudes avec m4 [11], le traditionnel processeur de macros d'Unix. Mais il est supérieur à m4 sur bien des aspects, comme dans sa manière d'ajouter des options à des fonctions. De plus AutoGen supporte les collections de valeurs imbriquées. Grâce à cela, Gary V. Vaughan, le contributeur d'AutoGen le plus actif après Bruce Korb, aimerait voir autoconf commencer à utiliser AutoGen en lieu et place de m4.

Selon Bruce, une des forces d'AutoGen est la séparation explicite des patrons et des définitions, ce qui rend les patrons plus flexibles. Qui plus est, toute donnée est nommée par un mnémonique, pas une position, ce qui permet de restructurer et re-trier les fichiers. Et la cerise sur le gâteau est que les anciennes définitions peuvent devenir obsolètes sans avoir à modifier les anciens fichiers, ce qui augmente la compatibilité. Et naturellement, toutes les définitions peuvent être imbriquées.

Comme les variables marquent les emplacements des remplacements, on peut définir avec l'aide de mots-clefs quelles sont les parties laissées tel quel ou répétées. AutoGen possède aussi la propriété de mieux contrôler sa sortie que le pré-processeur C.

Lorsqu'on l'interroge à propos des points faibles d'AutoGen, Bruce Korb répond qu'il est trop peu répandu et qu'il est trop facile de laisser les patrons ressembler à des hiéroglyphes. L'évaluation statique des définitions est aujourd'hui la plus grande limitation d'AutoGen, mais il est prévu qu'elle soit dynamique dans les prochaines versions.

À part cela, AutoGen est quasiment fini et de nombreux retours sont nécessaires pour étendre sa portabilité. Jusqu'à présent, il est reconnu qu'il tourne sur GNU/Linux, BSD, SVR4-5, HPUX, SCO OpenServer et Solaris, de même que sur Windows NT pourvu que CygWin soit installé.

Bien qu'AutoGen lui-même soit sous Licence Publique Générale GNU, certains ajouts sont sous Licence Publique Générale Amoindrie (LGPL), sous licence FreeBSD ou dans le domaine public.

Logiciels libres et commercialisation

Avant de pouvoir comprendre les interactions entre le commerce et l'industrie, il est indispensable de jeter un oeil sur la définition du Logiciel Libre. La première étape est toujours de comprendre que «free» dans «Free Software» ne se traduit pas par «gratuit» mais par «libre» (NdT : la distinction entre libre et gratuit tombe sous le sens en français car les 2 termes sont disjoints, alors que l'anglais les confond sous le terme «free»).

Mais à quoi la liberté se réfère-t-elle ? La définition de «Logiciel Libre» la plus précise se trouve dans les quatre libertés de la Free Software Foundation [12]. Les «Debian Free Software Guidelines» [13] (NdT : que l'on peut traduire par «Les principes du Logiciel Libre selon Debian») sont dérivés de là et ont servi de base à l'«Open Source Definition» (NdT : «La définition de l'Open Source» ; la traduction du terme «Open Source» étant quasi-inutile) [14]. Techniquement, ces trois définitions ont été écrites pour décrire les mêmes licences. Comme les quatre libertés en sont la définition la plus brève, je ne parlerai que d'elles.

La première liberté est d'avoir la possibilité d'utiliser le programme dans n'importe quel but. Restreindre l'usage dans une quelconque mesure mènerait immédiatement à ne pas qualifier le programme de libre.

La seconde liberté permet d'étudier un programme afin d'apprendre comment il fonctionne et d'y apporter des modifications selon ses propres besoins. L'accès au code source est alors un prérequis.

La liberté numéro 3 permet de faire des copies et de les redistribuer ; quant à la liberté numéro 4, elle est la somme des libertés 2 et 3. Elle dit que vous devez avoir la liberté de redistribuer vos modifications au bénéfice d'autrui. Comme la liberté numéro 2, cela requiert d'avoir accès au code source.

Il est important d'être conscient que d'avoir la liberté de faire quelque chose inclut aussi la liberté de ne pas le faire, ce qui s'applique particulièrement aux libertés 2, 3 et 4. Il n'est pas obligatoire de copier ou modifier un programme et il n'y a également pas d'obligation à le redistribuer. En fait, l'exigence de publier les changements a été ce qui a empêché la licence d'Apple «Apple Public Source License» d'être qualifiée de licence de logiciel libre.

La question de savoir si un logiciel est libre ou non se décide sur sa licence d'utilisation. Des licences de logiciels libres [15], la Licence Publique Générale GNU (la GNU GPL) est la plus largement utilisée. En dehors de la Licence Publique Générale Amoindrie GNU (GNU LGPL), qui est une variation de la LPG, la licence FreeBSD a la plus grande importance dans la pratique.

Donc, qu'en est-il de la commercialisation ? Le Logiciel Libre ignore délibérément la différence entre un usage commercial ou non commercial. Une limitation sur l'usage à but commercial violerait même la première liberté, donc le Logiciel Libre peut également toujours être mis en oeuvre à des fins commerciales. Combiné au fait qu'il n'y ait aucune condition sur sa redistribution, il devient immédiatement clair que le Logiciel Libre peut même être vendu.

On l'aura donc compris, les logiciels libres peuvent être commerciaux, mais ne le sont pas nécessairement.

Le modèle commercial prédominant à l'heure actuelle est le modèle propriétaire, où le prix est gonflé de manière artificielle en limitant ces libertés. Ainsi, une entreprise pourrait être tentée de priver ses clients de ces libertés afin d'augmenter sa marge de profit.

L'objectif est atteint de deux manières. Les licences comme celle de FreeBSD sont basées sur l'hypothèse que personne ne ferait passer ses intérêts personnels avant l'intérêt général. Elles autorisent délibérément le changement de licence sous licence propriétaire.

Les licences GNU bénéficient d'une «protection anti-appropriation» pour éviter une telle éventualité. Si vous fondez votre réussite directement sur le travail des autres, vous ne pouvez pas diffuser les résultats sous licence propriétaire.

La seule issue dans ce cas, pour retomber dans le schéma propriétaire, est d'écrire des modules qui soient techniquement isolés du programme original, ce qui demande un travail supplémentaire et n'est pas toujours possible.

Dans les deux cas, le produit final, que l'éditeur s'est approprié, est normalement vendu comme logiciel à valeur ajoutée en ayant à l'esprit que l'utilisateur va abandonner ses libertés. Cela peut arriver dans un contexte commercial ou non.

Donc, en dépit de la protection qu'offre la LPG, en fin de compte, seule la vigilance des utilisateurs peut éviter le retour au modèle propriétaire.

Pour résumer : il est clair qu'il existe des logiciels libres commerciaux de la même manière qu'il existe des logiciels libres non commerciaux. Le tout est d'opérer un choix. Au lieu de nous laisser aveugler par cette question, nous ferions mieux de ne pas perdre de vue notre liberté dans la mesure où c'est le fondement de tout le mouvement.

C'est tout pour aujourd'hui

Comme toujours, j'attends vos commentaires, questions, idées, inspirations et présentations de projets à l'adresse habituelle [1].