Un vaste ensemble de traditions relatives au d�veloppement de logiciels libres permet � d'autres personnes de porter le code plus facilement, de l'utiliser et de participer � son d�veloppement. Certaines de ces conventions sont des traditions du monde Unix ant�rieures � Linux ; d'autres ont �t� suscit�es r�cemment par l'apparition de nouveaux outils et de nouvelles technologies comme le World Wide Web.
Ce document vous aidera � acqu�rir ces r�gles d'usage. Il se compose de plusieurs sections th�matiques, chacune contenant une liste de points � v�rifier. Consid�rez que ces sections sont pour votre distribution comme la liste de contr�le qu'un pilote d'avion v�rifie avant le d�collage.
Ce document sera envoy� chaque mois dans le forum de discussion
comp.os.linux.answers . Ce document est archiv� sur plusieurs
sites FTP Linux, dont metalab.unc.edu dans le r�pertoire
pub/Linux/docs/HOWTO.
Vous pouvez aussi voir la derni�re version, en anglais, de ce HOWTO sur le World Wide Web � l'URL http://www.linuxdoc.org/HOWTO/Software-Release-Practice.html. La version fran�aise est disponible � l'adresse http://metalab.unc.edu/pub/Linux/docs/HOWTO/translations/fr.
Vous pouvez envoyer vos questions et vos commentaires sur ce HOWTO � Eric S. Raymond, esr@snark.thyrsus.com.
On a choisi de ne pas traduire les noms de fichiers que l'auteur recommande d'inclure dans un logiciel. En effet, le monde des logiciels libres est fortement internationalis�, et il utilise l'anglais comme langue commune. On supposera donc que le lecteur qui souhaiterait mettre en application les conseils de ce HOWTO conna�t suffisamment d'anglais pour �crire des documents tels que le fichier README ou le fichier INSTALL. Cela n'interdit pas, bien entendu, d'inclure dans les projets une version fran�aise de ces documents, qui sera tr�s appr�ci�e des utilisateurs francophones, qu'ils parlent ou non l'anglais.
Au fur et � mesure que s'accro�t la charge de travail des gestionnaires d'archives comme Metalab, le site PSA ou le CPAN, les soumissions sont de plus en plus souvent trait�es, en tout ou en partie, par des programmes (et non en totalit� par des humains).
Il est donc tr�s important que le nom de votre projet et celui de votre fichier d'archive suivent des r�gles pr�cises, afin que des programmes informatiques puissent les analyser et les comprendre.
Vous faciliterez la vie � tout le monde en donnant � vos archives des noms dans le style GNU : un pr�fixe-racine alphanum�rique tout en minuscules, suivi par un tiret, puis un num�ro de version, une extension et d'autres suffixes.
Supposons que vous ayez un projet nomm� "toto", qui en est � la version 1, mise � jour 2, niveau 3. S'il est compos� d'une seule archive (sans doute le code source), voici � quoi devrait ressembler son nom :
L'archive des sources
Le fichier LSM (si vous l'envoyez � Metalab).
N'utilisez pas les noms suivants :
Beaucoup de programmes croiront qu'il s'agit du fichier d'archive d'un projet nomm� `toto123', sans num�ro de version.
Beaucoup de programmes croiront qu'il s'agit de l'archive d'un projet nomm� `toto1' � la version 2.3.
Beaucoup de programmes prendront cela pour un projet nomm� `toto-v1'.
Le caract�re soulign� est difficile � prononcer, � taper, et � retenir.
A moins que vous vouliez vraiment ressembler � un accroc du marketing. L� encore, c'est difficile � prononcer, � taper et � retenir.
Si vous voulez faire s�par�ment une archive de sources et une archive de binaires, ou diff�rentes archives de binaires, ou encore indiquer un certain type d'option de fabrication dans le nom de l'archive, rajoutez pour cela une extension apr�s le num�ro de version. Voici quelques exemples :
sources
binaires, type non sp�cifi�
binaires ELF
binaires ELF li�s statiquement
binaires pour SPARC
N'utilisez pas des noms comme `toto-ELF.1.2.3.tar.gz', car les programmes ont beaucoup de mal � s�parer un infixe (tel que `ELF') de la racine du mot.
Un bon sch�ma d'appellation g�n�rique contient, dans l'ordre, les parties suivantes :
Certains projets ou communaut�s ont des conventions bien �tablies pour les noms et les num�ros de version, et ces conventions ne sont pas toujours compatibles avec les conseils qui pr�c�dent. Par exemple, les modules Apache ont en g�n�ral des noms du genre mod_foo, et ils ont � la fois un num�ro de version propre et le num�ro de la version d'Apache avec laquelle ils fonctionnent. De m�me, les num�ros de version des modules Perl peuvent �tre trait�s comme des nombres d�cimaux (par exemple, vous pouvez voir 1.303 � la place de 1.3.3), et les distributions s'appellent en g�n�ral Foo-Bar-1.303.tar.gz pour la version 1.303 du module Foo::Bar.
Apprenez et respectez les conventions des communaut�s et d�veloppeurs sp�cialis�s ; suivez les r�gles d�crites ci-dessus dans le cas g�n�ral.
Le pr�fixe-racine devrait �tre le m�me pour tous les fichiers d'un projet, et il devrait �tre facile � lire, � taper et � retenir. N'utilisez pas le caract�re "soulign�". Et ne mettez pas de majuscules ou de MajusculesInt�rieures sans une tr�s bonne raison -- cela d�range le trajet naturel de l'oeil humain, et vous aurez l'air de faire du marketing.
C'est difficile de s'y retrouver lorsque deux projets ont le m�me nom. Assurez-vous donc, dans la mesure du possible, qu'il n'y a pas de conflit de noms avant de publier votre premi�re version. Deux bons endroits pour v�rifier ceci sont l'index de Metalab et l'index des applications (appindex) � Freshmeat. Un autre endroit recommand� est SourceForge, en effectuant une recherche par nom.
La licence que vous choisissez d�finit le contrat social que vous souhaitez mettre en place avec vos co-d�veloppeurs et vos utilisateurs. Le copyright que vous mettez sur le logiciel sert principalement de d�claration l�gale de votre droit � fixer les termes de la licence sur le logiciel et sur les oeuvres qui en sont d�riv�es.
(Note du traducteur : dans cette section comme dans celles qui suivent, l'expression "(logiciel �) code ouvert" est utilis�e pour traduire l'anglais "open source", tandis que l'expression habituelle "logiciel libre" sert � transcrire "free software")
Tout ce qui n'appartient pas au domaine public poss�de un copyright, voire plusieurs. Selon la Convention de Berne (qui a force de loi aux Etats-Unis depuis 1978), le copyright n'a pas besoin d'�tre explicite. C'est-�-dire que les auteurs d'une oeuvre sont d�tenteurs du copyright m�me s'il n'y a pas de note de copyright.
Il peut �tre tr�s difficile de d�terminer qui peut �tre compt� comme un auteur, surtout lorsque de nombreuses auteurs ont travaill� sur le logiciel. C'est ce qui fait l'importance des licences. En pr�cisant les conditions dans lesquelles l'oeuvre peut �tre utilis�e, elles donnent aux utilisateurs des droits qui les prot�gent des actions arbitraires que pourraient entreprendre les d�tenteurs du copyright.
Dans le logiciel propri�taire, les termes de la licence sont formul�s de mani�re � prot�ger le copyright. Ils permettent de donner quelques droits aux utilisateurs tout en assurant au propri�taire (le d�tenteur du copyright) la plus grande possibilit� d'action possible sur le plan l�gal. Le d�tenteur du copyright a une grande importance, et la licence est tellement restrictive dans l'esprit que les d�tails techniques de ses termes sont g�n�ralement sans importance.
Dans le logiciel � code ouvert, la situation est souvent exactement inverse ; le copyright existe pour prot�ger la licence. Les seuls droits qui sont toujours conserv�s au d�tenteur du copyright sont ceux qui permettent de renforcer la licence. Parmi les autres droits, un petit nombre seulement sont r�serv�s, et c'est l'utilisateur qui a la plus grande libert�. En particulier, le d�tenteur du copyright ne peut pas modifier la licence sur une copie que vous poss�dez d�j�. Par cons�quent, le d�tenteur du copyright dans les logiciels � code ouvert n'a presque aucune importance -- contrairement aux termes de la licence.
Normalement, le d�tenteur du copyright sur un projet est le responsable actuel du projet ou une organisation m�c�ne. Le changement de responsable � la t�te d'un projet se manifeste souvent par la modification du copyright. Toutefois ce n'est pas une r�gle absolue ; dans de nombreux projets � code source ouvert, le copyright revient � de multiples personnes, et il n'y a pas de cas connu o� cela ait entra�n� des complications sur le plan l�gal.
Certains projets choisissent de donner le copyright � la Free Software Foundation, avec l'id�e que cette fondation a un int�r�t dans la d�fense du logiciel � code ouvert, et poss�de les avocats pour s'en occuper.
En ce qui concerne la licence, on peut distinguer plusieurs sortes de droits transf�rables via une licence. Les droits de copie et de redistribution, les droits d'utilisation, les droits de modification � usage personnel et les droits de redistribution de copies modifi�es. Une licence peut restreindre chacun de ces droits ou les accompagner de conditions.
L' Open Source Initiative est le r�sultat d'un important effort de r�flexion sur ce qui fait un ``logiciel � code ouvert'' ou (dans une terminologie plus ancienne) un ``logiciel libre''. L'association place les contraintes suivantes sur les licences :
Ces r�gles proscrivent les restrictions sur la redistribution de binaires modifi�s ; cela correspond aux besoins des distributeurs de logiciels, � qui il faut pouvoir livrer sans entraves du code en �tat de marche. Cela permet aux auteurs de demander que le code source modifi� soit redistribu� sous la forme du code source original plus des patchs, ce qui fait appara�tre les intentions de l'auteur et, dans un``suivi d'audit'', toutes les modifications faites par d'autres personnes.
L'OSD est la d�finition l�gale de la marque de certification `OSI Certified Open Source', et vaut toutes les d�finitions qu'on a pu faire du ``logiciel libre'' (note du traducteur : OSI est ici l'Open Source Initiative et n'a rien � voir avec l'Organisme de Standardisation Internationale ou ISO). Toutes les licences courantes (MIT, BSD, Artistic et GPL/LGPL) la v�rifient (encore que certaines, comme la GPL, ajoutent d'autres restrictions que vous devriez comprendre avant de les adopter).
Notez que les licences n'autorisant qu'un usage non commercial ne peuvent pas �tre qualifi�es de licences � code ouvert, m�me si elles affichent la licence ``GPL'' ou quelque autre licence courante. Elles font de la discrimination envers des emplois, des personnes et des groupes particuliers. Elles rendent la vie trop compliqu�e aux distributeurs de CD-ROM et aux autres personnes qui essaient de diffuser commercialement les logiciels � code ouvert.
Voici comment appliquer dans la pratique la th�orie qui pr�c�de :
Dans certains cas, si vous avez derri�re vous une organisation m�c�ne qui poss�de des avocats, vous pouvez choisir de donner le copyright � cette organisation.
L'Open Source Definition (D�finition du Code Ouvert) est la r�gle d'or pour les licences. L'OSD n'est pas une licence en soi ; elle d�finit plut�t un ensemble minimal de droits qu'une licence doit garantir afin d'�tre consid�r�e comme une licence � code ouvert. On peut trouver L'OSD, avec des documents compl�mentaires, sur le site Web de l' Open Source Initiative.
Les licences compatibles � l'OSD et connues de tous ont des traditions d'interpr�tation bien �tablies. Les d�veloppeurs (et, dans la mesure o� ils s'y int�ressent, les utilisateurs) savent ce qui en d�coule, et mesurent les risques et les inconv�nients qu'elles comportent. Par cons�quent, utilisez si possible l'une des licences standards sur le site de l'Open Source Initiative.
Si vous devez �crire votre propre licence, prenez soin de la faire certifier par l'Open Source Initiative. Cela vous �pargnera de nombreuses discussions et des co�ts importants. Si vous n'�tes jamais pass� par l�, vous ne pouvez pas imaginer pas � quel point un d�bat sur les licences peut tourner au vinaigre ; les gens s'enflamment, parce que les licences sont consid�r�es comme des pactes presque sacr�s qui touchent aux valeurs essentielles de la communaut� des logiciels ouverts.
De plus, l'existence d'une tradition d'interpr�tation bien �tablie pourrait se r�v�ler importante si un jour votre licence faisait l'objet d'un proc�s. A la date o� ces lignes sont �crites (septembre 1999), il n'y a pas d'exemple de d�cision judiciaire qui ait confirm� ou invalid� une licence de logiciel � code ouvert. Toutefois, c'est un principe de droit (au moins aux Etats-Unis, et sans doute dans d'autres pays de droit coutumier comme l'Angleterre et le reste du Commonwealth) que les cours de justice doivent interpr�ter les licences et les contrats en fonction des attentes et des pratiques de la communaut� qui les a produits.
La plupart de ces r�gles visent � assurer la portabilit�, non seulement entre les diff�rentes distributions de Linux, mais aussi avec d'autres vari�t�s d'Unix. La portabilit� vers Unix n'est pas seulement une question de professionnalisme ou de savoir-vivre entre programmeurs, c'est aussi une assurance non n�gligeable contre les �volutions futures de Linux lui-m�me.
D'autres personnes finiront par essayer de compiler votre code dans d'autres environnements que Linux ; avec la portabilit�, vous recevrez moins de messages ennuyeux de la part d'utilisateurs perplexes.
Pour des raisons de portabilit� et de stabilit�, il est fortement recommand� d'�crire soit en C ANSI pur, soit dans un langage de script dont la portabilit� soit garantie par une impl�mentation multi-plateforme unique.
Parmi les langages de script, Python, Perl, Tcl, Emacs Lisp et PHP respectent ce crit�re. Le bon vieux shell ne convient pas ; il existe trop d'impl�mentations diff�rentes, chacune ayant des particularit�s subtiles, et l'environnement du shell est souvent transform� de mani�re impr�visible par des configurations propres � chaque utilisateur, comme les alias.
Java promet beaucoup sur le plan de la portabilit�, mais les impl�mentations disponibles sur Linux sont encore sommaires et mal int�gr�es dans le syst�me d'exploitation. Java est encore un choix exotique, bien qu'il ait de fortes chances de gagner en popularit� lorsqu'il aura plus de maturit�.
Si vous �crivez en C, n'h�sitez pas � utiliser � fond les fonctionnalit�s d�crites dans la norme ANSI -- y compris les prototypes de fonction, qui vous aideront � rep�rer les incoh�rences entre modules. Les compilateurs du type K&R rel�vent du pass�.
En revanche, ne supposez pas que certaines caract�ristiques sp�cifiques � GCC comme l'option `-pipe' ou les fonctions imbriqu�es sont disponibles. Cela vous poursuivra et vous vous en repentirez le jour o� quelqu'un portera votre logiciel vers un syst�me autre que Linux, ou d�pourvu de GCC.
Si vous �crivez en C, utilisez autoconf/automaker/autoheader pour assurer la portabilit�, v�rifier la configuration du syst�me et affiner vos makefiles. De nos jours, les gens qui compilent � partir des sources s'attendent � devoir juste taper "configure; make" et que tout se compile proprement - sans la moindre erreur.
Si vous �crivez en C, faites une compilation de test avec l'option -Wall et corrigez les erreurs r�sultantes, au moins une fois avant chaque nouvelle version. On trouve comme cela un nombre surprenant d'erreurs. Pour �tre vraiment complet, compilez aussi avec l'option -pedantic.
Si vous �crivez en Perl, v�rifiez votre code avec perl -c (voire -T dans les cas ad�quats). Utilisez perl -w et 'use strict' religieusement (consultez la documentation de Perl pour plus d'informations).
Passez-les au correcteur d'orthographe. Si vous donnez l'impression de ne pas conna�tre l'orthographe et de vous en moquer, les gents penseront que vous avez aussi b�cl� votre code.
Les indications qui suivent montrent � quoi votre distribution devrait ressembler lorsqu'on la r�cup�re et qu'on la d�compacte.
L'erreur la plus aga�ante que font les d�veloppeurs novices est de fabriquer des archives qui d�compactent les fichiers et r�pertoires de la distribution dans le r�pertoire courant, avec le risque d'�craser des fichiers d�j� pr�sents. Ne faites jamais cela !
A la place, faites en sorte que les fichiers de vos archives partagent le m�me r�pertoire, avec un nom d�rivant de celui du projet. Ainsi, ils se placeront dans un seul r�pertoire, juste en-dessous du r�pertoire courant.
Voici un moyen de r�aliser cela dans un makefile, en supposant que le r�pertoire de votre distribution est `toto' et que SRC est une variable contenant la liste des fichiers de votre distribution. Vous devez avoir GNU tar 1.13.
VERS=1.0
toto-$(VERS).tar.gz:
tar --name-prefix='toto-$(VERS)/' -czf toto-$(VERS).tar.gz $(SRC)
Si votre version de tar est plus ancienne, faites quelque chose dans ce genre :
toto-$(VERS).tar.gz:
@ls $(SRC) | sed s:^:toto-$(VERS)/: >MANIFEST
@(cd ..; ln -s toto toto-$(VERS))
(cd ..; tar -czvf toto/toto-$(VERS).tar.gz `cat toto/MANIFEST`)
@(cd ..; rm toto-$(VERS))
Fournissez un fichier nomm� README ou READ.ME, qui donne une vision d'ensemble de votre distribution. C'est une vieille convention, et c'est le premier fichier que l'intr�pide explorateur lira apr�s avoir extrait les sources.
Voici quelques �l�ments qu'il est bon d'avoir dans un README :
Avant m�me d'avoir regard� le README, votre intr�pide explorateur aura parcouru la liste des fichiers dans le r�pertoire principal de votre distribution. Ces noms, par eux-m�mes, contiennent de l'information. En suivant certaines r�gles d'appellation, vous donnerez � l'explorateur de bons indices pour orienter son parcours.
Voici quelques noms recommand�s pour les fichiers du r�pertoire principal, avec leur signification. Tous ne sont pas indispensables dans chaque projet.
le plan d'ensemble, � lire en premier
instructions de configuration, de compilation et d'installation
liste des contributeurs du projet
derni�res nouvelles
histoire du projet
termes de la licence (convention GNU)
termes de la licence
liste des fichiers
"Foire Aux Questions" pour le projet, au format texte.
fichier de tags g�n�r� automatiquement, pour �tre utilis� par Emacs ou vi
Remarquez que la convention g�n�rale est que les fichiers dont le nom ne comporte que des majuscules sont des fichiers d'information sur le projet lui-m�me, et ne sont pas des �l�ments du syst�me � compiler.
La pr�sence d'une FAQ vous soulagera beaucoup. Quand une question relative au projet revient fr�quemment, rajoutez-la dans la FAQ. Puis demandez aux utilisateurs de lire la FAQ avant de poser des questions ou d'envoyer des rapports de bogues. Une FAQ bien entretenue peut r�duire d'au moins un ordre de grandeur la charge du support pour les mainteneurs du projet.
Il est bon d'avoir un fichier HISTORY ou NEWS avec un historique du projet mis � jour � chaque nouvelle version. Entre autres choses, il pourrait vous aider � prouver votre ant�riorit� si vous �tiez pris dans un proc�s pour contrefa�on (ce n'est jamais encore arriv� � personne, mais autant y �tre pr�par�).
Votre logiciel �voluera dans le temps au rythme des versions successives. Certains des changements ne seront pas compatibles avec l'existant. Par cons�quent, r�fl�chissez bien � l'organisation du logiciel afin que plusieurs versions puissent �tre install�es et coexister sur le m�me syst�me. C'est particuli�rement important pour les biblioth�ques de fonctions : vous ne pouvez pas compter que tous les programmes clients soient mis � jour d'un seul coup pour s'adapter aux modifications de vos interfaces.
Les projets Emacs, Python et Qt ont adopt� une bonne convention pour traiter ce probl�me, celle des r�pertoires num�rot�s par version. Voici � quoi ressemble une hi�rarchie de biblioth�ques Qt (${ver} est le num�ro de version) :
/usr/lib/qt
/usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin # Emplacement de moc
/usr/lib/qt-${ver}/lib # Emplacement des .so
/usr/lib/qt-${ver}/include # Emplacement des fichiers d'en-t�te
+
Une telle organisation vous permet de faire coexister plusieurs versions. Les programmes clients doivent sp�cifier quelle version de la biblioth�que ils d�sirent, mais c'est un faible prix � payer en comparaison des incompatibilit�s d'interface qu'ils �vitent.
Le format standard de facto pour les distributions de binaires � installer est celui qu'utilise le Red Hat Package Manager, RPM. Il est pr�sent dans les distributions Linux les plus populaires, et il est support� en pratique par toutes les autres (sauf Debian et Slackware ; et Debian peut faire des installations � partir de RPM).
Par cons�quent, c'est une bonne id�e de fournir sur le site de votre projet des RPM installables en m�me temps qu'une archive des sources.
C'est aussi une bonne id�e d'inclure dans votre archive de sources le fichier de sp�cification du RPM, avec dans le Makefile une entr�e qui fabrique les RPM � partir de lui. Le fichier de sp�cification devrait avoir l'extension `.spec' ; c'est comme cela que l'option -t de rpm le trouve � l'int�rieur de l'archive.
Encore un point de style : g�n�rez votre fichier de sp�cification avec un script shell qui ins�re automatiquement le num�ro de version en analysant le Makefile ou un fichier version.h.
Note : si vous fournissez des RPM sources, utilisez BuildRoot pour fabriquer le programme dans /tmp ou /var/tmp. Si vous ne le faites pas, l'installation, r�alis�e au cours de la partie install de votre fabrication, se d�roulera dans les r�pertoires finaux. Ceci se produira m�me en cas d'homonymie de fichiers ou si vous ne d�sirez pas r�ellement installer le produit. Une fois la fabrication termin�e, les fichiers seront install�s � leur emplacement d�finitif, et la base de donn�es RPM du syst�me ne sera pas mise � jour. Des SRPM ayant ce mauvais comportement sont des champs de mines et doivent �tre �vit�s.
Votre logiciel n'apportera pas grand-chose � l'univers si vous �tes le seul � conna�tre son existence. De plus, en �tablissant une pr�sence visible sur Internet pour votre projet, vous pourrez recruter plus facilement des utilisateurs et des co-d�veloppeurs. On le fait habituellement comme ceci :
Annoncez vos nouvelles versions dans comp.os.linux.announce. Non seulement ce forum est lu par un grand nombre de personnes, mais c'est aussi un fournisseur important pour des sites Web d'information comme Freshmeat.
Trouvez un forum USENET dont le th�me de discussion est directement concern� par votre application, et faites-y aussi votre annonce. N'envoyez votre message qu'aux endroits o� la fonction remplie par votre logiciel est pertinente, et restez mesur�.
Si (par exemple) vous publiez un programme en Perl qui interroge des serveurs IMAP, vous devriez probablement envoyer un message dans comp.mail.imap. Mais s�rement pas dans comp.lang.perl, � moins que le programme utilise de mani�re instructive des techniques Perl avanc�es.
Votre annonce devrait aussi contenir l'URL du site Web de votre projet.
Si vous comptez �tablir une communaut� substantielle d'utilisateurs ou de d�veloppeurs autour de votre projet, celui-ci devrait avoir son site Web. Voici des �l�ments que l'on trouve habituellement sur un site Web :
Certains projets ont m�me une URL pour un acc�s anonyme � l'arborescence principale du code source.
Il est d'usage d'avoir une liste de d�veloppement priv�e qui permet aux collaborateurs du projet de communiquer et d'�changer des patchs. Vous voudrez peut-�tre cr�er en plus une liste d'annonces pour les gens qui veulent �tre inform�s de la progression du projet.
Depuis plusieurs ann�es, le site Metalab est le plus important des endroits d'�change de logiciels pour Linux.
Voici quelques autres sites notables :
Bien g�rer un projet lorsque tous les participants sont b�n�voles pr�sente des d�fis particuliers. Le sujet est trop large pour �tre trait� dans le cadre d'un HOWTO. Heureusement, il existe des documents de r�flexion qui vous aideront � comprendre les principaux points.
Pour un essai sur l'organisation de base du d�veloppement et du principe `distribuez t�t, mettez � jour souvent' propre au `mode bazar', lisez The Cathedral and the Bazaar.
Pour une r�flexion sur les motivations psychologiques, des coutumes de la communaut� et de la r�solution des conflits, lisez Homesteading the Noosphere.
Pour un expos� des principes �conomiques et des mod�les commerciaux � adopter, lisez The Magic Cauldron.
Si vous �tes allergique � la langue de Shakespeare, vous pourrez trouver des traductions de ces documents sur le site Linux France.
Ces papiers ne pr�tendent pas se poser comme les r�f�rences ultimes � propos des d�veloppements � code source ouvert. Mais ils constituent les premi�res analyses s�rieuses �crites sur le sujet, et n'ont pas encore �t� d�pass�s (l'auteur esp�re toutefois qu'ils le seront un jour).