[DE |
EN |
FR |
IT |
JA |
ES |
KO |
PT]
Bienvenue pour un nouveau numéro du Brave GNU World. Comme promis à la fin du précédent numéro, je voudrais présenter ce mois-ci un projet qui m'a beaucoup simplifié la vie.
Le SpamAssassin [5] de Justin Mason permet "d'assassiner" le publipostage (spam) de votre courrier électronique - du moins il identifie l'indésirable et permet ainsi à Procmail ou au lecteur de courrier de traiter celui-ci de la façon la moins contrariante pour l'utilisateur.
Le coeur du SpamAssassin est un programme en Perl distribué sous la même double licence Publique Générale de GNU et Artistique que Perl. Cela autorise la distribution du SpamAssassin sur le "Comprehensive Perl Archive Network" (CPAN) [6] et de réutiliser son code sans problèmes légaux.
D'ailleurs, les problèmes de licence ont été un élément crucial dans le démarrage de ce projet. Avant d'écrire SpamAssassin, Justin utilisait un autre filtre de courrier écrit en Perl, mais qui posait problème de par ses règles statiques et la situation floue de sa licence.
Justin retint de ce projet l'idée de travailler avec des points, un concept très similaire au "Pointage Adaptatif" utilisé par le lecteur de courrier et de nouvelles GNUS [7].
Le SpamAssassin fonctionne en effectuant de nombreux tests sur le courrier analysé. Il y a des tests pour le courrier en HTML seulement, pour déterminer si le courrier contient des phrases souvent usitées dans les prospectus, s'il indique ne pas être du spam d'après certaines lois et règlements, s'il contient une quantité inhabituelle de points d'exclamation ou d'interrogation, s'il parle de "Millions de Dollars" et ainsi de suite.
Pour chaque test qui a été effectué, un courrier reçoit des points; l'utilisateur peut indiquer combien de points sont attribués aux tests dans un fichier de configuration simple en ASCII. Si la somme de tous les points dépasse un certain seuil - également configurable -, le SpamAssassin juge que le courrier est sans doute du spam.
Une fois cette décision prise, le SpamAssassin insère dans l'en-tête des marqueurs informant des résultats du test. Si l'utilisateur le souhaite, les spams sont également forcés d'avoir comme type de contenu "text/plain", ce qui facilite grandement la consultation ultérieure des résultats. Le SpamAssassin peut aussi insérer un rapport de test plus détaillé au début du courrier afin qu'un utilisateur puisse facilement voir pourquoi il a été classé comme spam.
Les plus grands risques potentiels de l'utilisation de SpamAssassin sont clairement les "fausses alertes" - courrier normal classé comme spam. C'est pourquoi il est recommandé de jeter régulièrement un oeil à la boîte aux lettres à spams, dans laquelle vont normalement tous les spams détectés, afin de corriger les résultats fausses alertes.
Vous pouvez également choisir de diminuer la sensibilité du SpamAssassin, ce qui va augmenter la quantité de spam non détecté. Trouver le bon réglage est la gageure de l'administrateur de SpamAssassin.
Pour empêcher les auteurs de spam de trouver des voies de contournement des tests de SpamAssassin, le projet comporte autant de tests que possible et est aussi facilement extensible.
Bien sûr il comprend aussi les listes noires proposées en ligne. Les listes usuelles de DNS référençant les sources connues et les relais de Spam sont également supportées, comme Vipul's Razor [8], une base de données de Spam permettant l'identification des Spam connus.
Afin de faciliter le filtrage de grandes quantités de courrier et de permettre la connexion à autant de sources possibles, Craig Hughes a écrit le démon "spamd", qui est fourni avec le paquetage SpamAssassin.
La plus grande faiblesse du SpamAssassin est qu'il est plus ou moins destiné à l'utilisateur techniquement expérimenté et qu'il n'a pas (encore) d'interface graphique.
Résoudre cela aussi bien qu'écrire plus de tests et créer plus d'interconnexions avec les sources de courriers est le prochain axe de développement. Les interconnexions avec Procmail, Qmail, Postfix sont actuellement disponibles, ainsi qu'avec Sendmail à travers la bibliothèque Milter et un greffon Mail::Audit.
J'espère que vous ne m'en voudrez pas de mentionner être l'auteur du greffon sendmail-milter [9]. Je l'ai écrit afin de pouvoir utiliser le SpamAssassin pour filtrer tous les courriers reçus, après une recherche infructueuse de solutions existantes. Cependant, pour ma part, le manque de temps m'interdit de m'occuper du projet correctement, ainsi Michael Brown, dont l'employeur l'offre dans un environnement commercial, m'a succédé comme coordinateur dans la meilleure tradition du Logiciel Libre.
Ce bel exemple montre comment le Logiciel Libre peut harmoniser l'approche classique "Grattez là où ça vous démange" avec les intérêts commerciaux d'une entreprise, pour le bien de tous.
Faisant face à un flot grandissant de prospectus menaçant d'enterrer l'Internet, je dois admettre que j'ai une grande sympathie pour les projets comme le SpamAssassin, qui vient à bout pour moi d'environ 60 courriers indésirables par jour.
Les lecteurs réguliers du Brave GNU World doivent maintenant se sentir familiers avec la plupart des arguments en faveur du Logiciel Libre dans le domaine scientifique.
En définitive, le Logiciel Libre est le seul choix sensé à long terme pour tous les types de travaux scientifiques, parce qu'il est le seul à leur offrir la garantie de rester utilisables pour des projets futurs et qu'il permet d'être inclus comme partie de son travail dans ses propres résultats scientifiques ou publication, et distribué si besoin est.
Voxximate [10] d'Andreas Neumann est un tel projet de Logiciel Libre scientifique sous la Licence Publique Générale de GNU.
Voxximate signifie "Vortex flow simulation made at home", soit simulation d'écoulement vortex à la maison. C'est un programme de simulation des courants et vortex dans les fluides. Il fonctionne à partir de positions de départ prédéfinies et utilise des étapes concrètes pour calculer l'influence de chaque vortex sur tous les autres, en suivant la progression dans le temps.
Le projet est sans doute surtout utile à tous les étudiants confrontés à la dynamique des fluides au cours de leurs études, et intéressés par étudier comment les vortex interagissent et forment des structures.
Voxximate a été écrit en Java, ce qui implique les problèmes habituels de Java, mais ceci ne doit pas empêcher d'aider le développement à venir. Pour les prochaines étapes, Andreas espère inclure un éditeur graphique pour définir les positions de départ ainsi que la possibilité de sauvegarder des graphiques et des animations qui pourraient alors être publiées sur le web.
Monica [11] est un programme de calibrage d'écran par Tilo Riemer. Il a été écrit en C++ et utilise le Fast Light Toolkit (FLTK) [12] et le programme xgamma de XFree86 [13].
Une mauvaise correction gamma de l'écran peut rendre impossible la distinction de couleurs rapprochées ou provoquer un affichage non satisfaisant des combinaisons de couleurs. Cela peut être particulièrement gênant si l'ordinateur est utilisé pour du graphisme.
Au début, Tilo Riemer essaya d'utiliser le projet apparenté KGamma [14], mais la compilation échoua parce que plusieurs bibliothèques KDE manquaient et aussi parce que KGamma semblait être si profondément lié à KDE qu'il avait besoin de nombreuses parties de KDE pour fonctionner.
Ainsi, en janvier 2002, il commença à écrire Monica, qui présente l'avantage d'être très petit et rapide. Ceci permit d'inclure un mode "à la volée", rendant possible une boucle de retour dynamique. Sur un ordinateur à 900 MHz cela nécessite environ 10-20% du temps CPU.
Les autres points forts de Monica sont l'absence de dépendance autre que celle avec FLTK et la façon de sauvegarder les changements dans le ".xinitrc" des utilisateurs afin de les rendre indépendants du gestionnaire de fenêtres ou du bureau.
L'annonce récente de la version 1.0 indique que Tilo n'a pas l'intention de consacrer beaucoup plus de temps à Monica, bien qu'il accepterait volontiers de l'aide pour l'internationalisation.
À l'origine, Tilo envisageait de publier Monica dans le "Domaine Public", car il lui semblait trop petit et insignifiant pour s'inquiéter des licences. Dans le code source, il écrivit néanmoins "Copyright © Tilo Riemer" - et n'y prêta plus attention.
Cependant, la notion de Domaine Public n'est pas sans poser problème en Europe continentale. En Allemagne, l'interprétation légale courante de ce terme est dégagée de revendication de propriété ou de droit d'auteur, ce qui signifie habituellement que celui-ci est inconnu ou mort depuis plus de 70 ans. Ces deux cas ne s'appliquent évidemment pas ici.
C'est pourquoi Tilo décida de publier Monica sous une licence de type BSD, ce qui régla les problèmes immédiats et fit de Monica un Logiciel Libre.
Cette histoire n'est pas très inhabituelle et montre que, de toute évidence, les développeurs n'aiment pas beaucoup s'occuper des licences - bien que ce soit très facile d'introduire des dangers en ne le faisant pas. C'est pourquoi je vais essayer de donner une introduction compréhensible sur le soutien légal du Logiciel Libre.
La plupart des gens sont conscients qu'une grande part de tous les logiciels nécessite une maintenance technique permanente sinon ils perdraient rapidement leur utilité. Les logiciels qui sont révisés en permanence sont souvent les seuls à pouvoir être utilisés à long terme.
Cette procédure technique dépend de l'accès au code source et le droit, c'est-à-dire la liberté, d'effectuer la maintenance. D'une manière générale, le système légal ou politique définit les droits et les obligations de chaque membre d'une société.
Que le système légal fonctionne bien ou pas n'est pas le point important. Ce dont il faut prendre conscience est que certains des pré requis à la faculté de maintenance technique sont de nature légale.
La garantie d'un accès permanent et durable à la maintenance est un des avantages intrinsèques du Logiciel Libre, en particulier dans un contexte commercial. Cet avantage dépend fortement de la légalité de la maintenance du Logiciel Libre.
Les libertés, droits et obligations du Logiciel Libre sont admis et parfois protégés par les licences, qui sont "ancrées" au logiciel à travers le droit d'auteur. Le Logiciel Libre ne dépend pas strictement de la loi du droit d'auteur, mais depuis que celle-ci existe, nous devons en tenir compte.
Que signifie accès légal à la maintenance dans ce contexte?
Même si ce n'est pas ainsi que la plupart des gens le perçoivent intuitivement, le système légal n'est pas figé, il change sans cesse.
Les changements portant sur la loi du droit d'auteur peuvent potentiellement affaiblir ou même rendre hors-la-loi le Logiciel Libre, comme ce fut récemment le cas en Allemagne. Dans ce cas particulier, l'irfOSS [15] et la FSF Europe [16] furent à même de suggérer une modification de la proposition de révision de la loi du droit d'auteur, en introduisant une exception pour le Logiciel Libre. Cette modification fut faite dans la loi sous la forme originelle proposée par l'ifrOSS et devint partie de la loi du 25 janvier 2002 qui entrera en vigueur prochainement.
L'une des tâches de la FSF Europe est de rester vigilante quant à de telles évolutions et de les orienter en faveur du Logiciel Libre. Celle-ci serait plus difficile sans coopération avec des organisations comme l'ifrOSS, qui a une nature clairement et totalement légale ; c'est pourquoi la FSF Europe travaille à établir et renforcer ces coopérations à travers l'Europe.
Il eut été également possible que des modifications d'autres paramètres légaux eussent nécessité une adaptation des licences. Les adaptations légales ou les nouveaux concepts techniques tels que la "Fourniture de Services Applicatifs" (Application Service Providing - ASP) pourraient contourner la protection de la liberté dans certains domaines ou même la rendre inefficace, en transgressant de fait l'esprit des licences.
La plupart des développeurs publient leurs logiciels sous la Licence Publique Générale de GNU, conscients de garantir et de protéger ainsi la liberté de leur logiciel. En agissant ainsi, l'étape la plus importante vers la protection du Logiciel Libre est franchie. En employant la clause "ou toute version ultérieure" ils donnent en partie le pouvoir à la FSF de protéger, défendre et soutenir globalement le placement sous licence (L)GPL.
Cependant, modifier explicitement une licence peut parfois avoir des conséquences importantes. Les projets qui n'ont pas mis en oeuvre une maintenance centralisée des droits légaux peuvent rencontrer de graves difficultés, tout particulièrement si la clause "ou toute version ultérieure" de la GPL a été supprimée.
Dans un tel cas, le changement doit être accepté par tous les développeurs - en supposant qu'ils puissent tous être trouvés. Étant donné le large éventail d'intérêts et d'opinions des développeurs travaillant sur certains projets, cela semble peu probable.
De plus, dans la plupart des cas, seul le détenteur de ce que l'on appelle les "droits d'exploitation exclusifs", c'est-à-dire le "droit d'auteur", est légalement désigné pour faire respecter la licence devant la Justice. Ainsi les projets peuvent rencontrer de sérieuses difficultés en essayant de défendre leurs intérêts au tribunal.
Étant donné que de nombreux auteurs travaillent sur un même projet, ils devront se regrouper et agir efficacement ensemble pour protéger leurs intérêts individuels. Ceci nécessite beaucoup de coordination, de temps et d'effort. Et beaucoup d'auteurs ne sont ni volontaires pour mener une lutte légale à son terme, ni préparés à la voir traîner en longueur..
Ce serait bien si plus de projets prenaient conscience de ces implications et mettaient en oeuvre les précautions adéquates. Aussi, en désignant un fiduciaire, les auteurs peuvent retourner se consacrer au logiciel lui-même.
Dans le futur, il semble vraisemblable que les projets ayant des situations légales claires et ordonnées gagneront plus facilement en popularité, car les utilisateurs vont sans doute faire plus souvent attention à cela.
Afin de garantir l'accès légal à la maintenance du Logiciel Libre - en particulier au sein du projet GNU, mais pas seulement - la Fondation pour le Logiciel Libre (FSF) a commencé à travailler de bonne heure avec ce que l'on appelle les "Transferts de droit d'auteur", ce qui la renforce pour défendre les droits du Logiciel Libre (même en justice, si nécessaire) et adapter le placement sous licence aux nouvelles situations.
Puisque la loi d'Europe continentale sur la paternité d'une oeuvre a une base différente de la loi anglo-américaine du droit d'auteur, la FSF Europe a également travaillé avec Axel Metzger, Carsten Schulz et Till Jaeger de l'ifrOSS sur un "Accord de licence fiduciaire", qui permet à la FSF Europe d'agir en tant que fiduciaire des auteurs.
L'auteur conserve une quantité illimitée de "droits d'exploitation individuelle", qu'il peut utiliser pour placer le logiciel sous une double licence, rien n'interdisant la seconde licence d'être propriétaire.
En même temps, la FSF Europe garantit de n'utiliser les droits transférés que dans l'intérêt du Logiciel Libre et se contentera de publier le logiciel sous une licence Libre - sinon tous les droits retournent à l'auteur.
Cet accord est actuellement dans la dernière "phase de relecture" interne et sera présenté au public dans un avenir proche.
En tant que président de la FSF Europe, je considère que la Fondation pour le Logiciel Libre (FSF) est la mieux placée pour ce travail car elle va continuer à relever ces défis avec le sérieux qui fait sa renommée depuis longtemps.
Elle ne possède pas seulement les plus grandes connaissance et expérience grâce à la Licence Publique Générale (GPL) et à la Licence Publique Générale Amoindrie (LGPL) de GNU, elle peut agir partout dans le monde et a une réputation justifiée d'être à même de défendre les intérêts du Logiciel Libre ; également par des moyens légaux, si nécessaire.
Voilà qui est suffisant pour aujourd'hui. J'espère avoir réussi dans la dernière partie à vous faire prendre conscience du contexte, des actions et du travail de la Fondation pour le Logiciel Libre (FSF).
Comme d'habitude, je sollicite des tas de courriers [1] contenant des idées, des commentaires, des questions et de nouveaux projets.
Envoyez vos questions sur GNU et la FSF à
gnu@gnu.org.
Il y a aussi d'autres manières de
contacter la FSF.
Envoyez vos commentaires sur "Brave GNU World" (anglais ou allemand) à
column@gnu.org,
et les commentaires sur cette page à
webmasters@www.gnu.org,
les autres questions à
gnu@gnu.org.
Copyright (C) 2001 Georg C. F. Greve
Traduction [FR]: Valéry Beaud
Permission vous est donnée de distribuer des copies exactes de cette page tant que cette note de permission et le copyright apparaissent clairement.
Dernière modification : $Date: 2008/06/16 16:43:14 $ $Author: mattl $