Page suivante Page précédente Table des matières

4. Du Free Software à l'Open Source.

Jusqu'à présent, le logiciel libre fut l'affaire des spécialistes, des hackers qui disposaient d'un accès à l'Internet. Ces « bitouilleurs » de génie trouvaient dans le logiciel libre un moyen d'évoluer dans un monde parallèle, où leur talent pouvait s'exprimer librement. Ils se sont ainsi créé un univers régi par les préceptes de Richard Stallman et de sa GPL (Licence Publique Générale). L'ensemble des acteurs du « monde libre » s'accommodait alors fort bien de cette situation. Puis vint le jour où le logiciel libre, victime de son succès, passa les frontières de l'Internet. On constatait alors que l'approche de Stallman était quelque peu incompatible avec le « monde extérieur ».

Avec les propositions de l'Open Source, le logiciel libre réoriente son discours pour toucher l'ensemble des utilisateurs : le particulier comme l'entreprise.

4.1 Une brève histoire du logiciel libre

Le logiciel libre n'est récent que médiatiquement. Dans les faits, il remonte aux années 70, où l'informatique des « gros systèmes » — les mainframes — connaissait ses heures de gloire dans le monde universitaire. Les logiciels transitaient alors librement de labo en labo au gré des échanges entre équipes de recherche.

La transparence est de mise dans un monde où la validation des travaux passe d'une manière ou d'une autre par un examen critique mené par les pairs. Le logiciel libre hérite ainsi de cette volonté de transparence. La disponibilité du code source — caractéristique des distributions libres — est la conséquence naturelle de cet esprit d'ouverture.

Le célèbre MIT (Massachusetts Institute of Technology), et plus particulièrement son laboratoire d'intelligence artificielle, fut le repère des fondateurs de ce qui deviendra le Free Software. Richard Stallman — qui appartenait à ce laboratoire — est universellement reconnu comme le père spirituel du logiciel libre. Il est notamment à l'initiative du projet GNU (GNU is Not Unix — prononcé « gnou », comme l'antilope d'Afrique à barbichette).

Le projet GNU avait pour ambition d'enrichir la famille des Unix d'une version libre. Dans un premier temps, Stallman et les développeurs de la FSF (Free Software Foundation) produisirent le compilateur gcc et le débogueur gdb — outils multi-plates-formes toujours très largement utilisés. La bibliothèque glibc apparaît également au palmarès du projet GNU. À la fois pour des raisons techniques et de licence — principalement liées au choix du micro-noyau Mach de l'université Carnegie-Mellon comme couche de base — la sortie du noyau Hurd du GNU (coeur du système d'exploitation) se trouva retardée. Au début des années 90, le système GNU se voyait ainsi privé de noyau. L'arrivée en 1991 du noyau Linux de Linus Torvalds — LINUs a fait son uniX — fut une aubaine pour le projet GNU. D'un côté, on avait un noyau dont l'auteur était prêt à rejoindre le mouvement du logiciel libre, et de l'autre, tous les logiciels de base d'un système d'exploitation. Le système GNU/Linux était né. Hurd est aujourd'hui masqué par le succès du système GNU/Linux.

Auteur de la Licence Publique Générale — la célèbre GPL, fondateur en 1984 de la FSF et initiateur du projet GNU, Stallman a définitivement marqué l'histoire du logiciel libre. Il appartient toujours au courant de pensée le plus radical du mouvement libre : celui des libertaires.

La Licence Publique Générale est rapidement devenue « la » licence de référence. Pour les développeurs, elle constitue encore aujourd'hui un moyen simple et efficace de distribuer un logiciel libre. Elle propose toutefois une approche très radicale du concept de logiciel libre et ne pouvait satisfaire l'ensemble des besoins.

4.2 Vers une nouvelle définition

Note : Dans ce qui suit, nous attribuons la paternité de l'Open Source à Bruce Perens. Il s'agit là d'un simple raccourci. L'Open Source est en fait l'oeuvre commune de Bruce Perens, Eric S. Raymond et des « anonymes » de l'Internet qui participèrent aux débats. Perens et Raymond ont notamment créé l'OSI (Open Source Initiative), organisation vouée à la promotion de l'Open Source et à son rapprochement avec le monde de l'entreprise.

Stallman et les défenseurs du Free Software considèrent que la conservation des droits d'auteur (par le biais du copyleft) a pour seul objet de prévenir toute appropriation abusive du logiciel après ouverture de son code source à la communauté. Toute autre forme d'avantage — que l'auteur pourrait tenter de s'octroyer — est proscrite. La GPL reflète cette conception (extrêmement libertaire) du logiciel libre.

À la fois licence et manifeste, dogmatique et oeuvre d'un seul homme, la GPL constituerait un obstacle au déploiement des logiciels libres dans l'entreprise.

Partant de cette constatation, Bruce Perens — ancien responsable de la distribution Debian GNU/Linux — a cherché à élargir le champ d'application des licences libres et permettre ainsi aux industriels d'approcher le monde des OSS. Il est le principal auteur d'une première proposition éditée sous le titre : définition de l'Open Source. Bien que non encore adopté par la communauté (ce n'est qu'une proposition), ce texte constitue un bon indicateur de l'évolution des mentalités.

Notons qu'il s'agit là d'un rapprochement avec l'ensemble de l'industrie, et pas uniquement avec celle du logiciel. Dans leur démarche, Perens et Raymond souhaitent avant tout modérer un discours propre à effrayer les hommes d'affaires et avec eux tous les utilisateurs potentiels de logiciels libres du monde de l'entreprise.

La communauté du logiciel libre semble ainsi se diriger vers une nouvelle définition générique de l'esprit qui l'anime. L'objet n'est pas de rédiger une licence universelle, mais de définir les règles auxquelles devront se conformer les auteurs afin de bénéficier de la certification Open Source.

Dans sa définition, Perens prend effectivement quelques distances avec les préceptes de Stallman. Le discours y est moins radical et les exigences moins strictes. Dissidence ?

Les plus fervents défenseurs de l'esprit Free Software sont sur leurs gardes : le logiciel libre vend son âme au diable ! Stallman et Raymond se sont notamment engagés dans une discussion à couteaux tirés sur le sujet. Perens arbitrait les débats. Au sein du logiciel libre, les courants se dessinent : les Stallmaniens constituent la branche dure, les modérés se rallient à Perens et Raymond.

La définition de l'Open Source reprend pourtant bon nombre des idées de Stallman et Perens la considère comme une dérivation des travaux du « gourou ». L'essentiel de ce qui fait la force du logiciel libre y est conservé : la transparence.

Moins intransigeante, elle permet à l'auteur « d'émettre quelques réserves » sur la distribution des versions modifiées de son logiciel. Il est notamment possible de conserver l'usage exclusif du nom commercial de l'application (i.e. de ne pas autoriser la distribution d'une version modifiée du logiciel sous son nom commercial). Plus intolérable encore pour les adeptes de la GPL, est le droit que peut se réserver l'éditeur — celui qui détient les droits sur le logiciel — d'intégrer dans son offre propriétaire les améliorations apportées par les développeurs de l'Internet, le code source correspondant à ces modifications restant disponible par ailleurs.

La licence NPL de Netscape est un exemple de texte où l'éditeur conserve certains privilèges tout en restant conforme à l'Open Source. Netscape a ainsi choisi de mettre le code de son Navigator© à la disposition de la communauté sous l'appellation Mozilla. L'utilisation du terme Navigator© demeurant l'exclusivité de l'éditeur. Il s'accorde également le droit d'intégrer toute amélioration du code dans son offre dédiée aux serveurs.

Un éditeur peut également exiger que les modifications soient distribuées sous forme de « patchs », qui pourront être appliqués au code source du programme. Dans cette démarche, la préoccupation majeure est de préserver son image de marque — de faire en sorte que l'utilisateur puisse distinguer la version « officielle » (approuvée par l'auteur) des versions modifiées par la communauté des développeurs. Il est légitime qu'un auteur ne souhaite pas être associé aux dérivés « boiteux » de son produit. La société Troll Tech a choisi ce mode de distribution pour sa bibliothèque graphique Qt.

Pour conclure, considérons l'Open Source comme une simple adaptation du Free Software aux réalités économiques et sociales.

4.3 Définition de l'Open Source

Ce qui suit correspond à la version commentée (par son auteur) de la définition de l'Open Source telle qu'elle apparaît dans la traduction française du livre « Open Sources », intitulée Tribune Libre. Un chapitre est entièrement dédié à cette définition

N.D.É. : ce texte évolue continûment, ainsi que son adaptation en français. Pour une version à jour de ce document, consulter la version officielle du site original, son adaptation en français (sans valeur légale et qui aura forcément un peu de retard sur le texte précédent), ou la zone web consacrée à l'ouvrage « Tribune Libre » par son éditeur (les éditions successives d'un livre souffrant bien entendu de délais supérieurs encore). Le texte présenté ici est l'une des premières versions de l'adaptation en français de l'essai de Bruce Perens dans l'ouvrage Open Sources, légèrement modifiée par l'auteur du mémoire pour lui faire refléter le changement de numéro de version qui s'était produit entre temps. Pour ces raisons, il est sans doute propre et original au présent mémoire.
.

Définition de l'Open Source, version 1.4

Bruce Perens a écrit le premier brouillon de ce document sous le titre « The Debian Free Software Guidelines » (lignes de conduite pour le logiciel libre de la Debian), et l'a amélioré en utilisant les commentaires des développeurs Debian lors d'une conférence par courrier électronique qui a duré un mois, en juin 1997. Il a ôté du document les références propres à la Debian pour créer la « définition de l'Open Source ».

L'Open Source implique plus que la simple diffusion du code source. La licence d'un programme Open Source doit correspondre aux critères suivants :

Vous remarquerez que la définition de l'Open Source n'est pas une licence de logiciel en soi. C'est une spécification de ce qu'on autorise aux licences de logiciels pour qu'elles méritent le nom d'Open Source. La définition de l'Open Source n'a pas pour vocation d'être un document juridique. Le fait qu'on la retrouve dans des licences de logiciels, comme la licence qui est proposée pour le Linux Documentation Project (projet de documentation pour Linux), m'a fait envisager d'en écrire une version plus rigoureuse, qui serait appropriée pour une telle utilisation.

Pour qu'un logiciel puisse être qualifié d'Open Source, il faut que toutes les conditions suivantes soient remplies, en même temps, et dans tous les cas. Il faut par exemple qu'elles s'appliquent aux versions dérivées d'un programme aussi bien qu'au programme original. Il ne suffit pas de n'en appliquer que quelques-unes et pas d'autres, et il ne suffit pas de ne les appliquer que dans certaines périodes. Comme j'ai dû ferrailler pour contrer des interprétations particulièrement naïves de la définition de l'Open Source, je serai tenté d'ajouter : cela vous concerne.

1. Libre redistribution

La licence ne doit pas empêcher de vendre ou de donner le logiciel en tant que composant d'une distribution d'un ensemble contenant des programmes de diverses origines. La licence ne doit pas exiger que cette vente soit soumise à l'acquittement de droits d'auteur ou de royalties.

Cela signifie qu'on peut faire autant de copies du logiciel qu'on le souhaite, et les vendre ou les donner, sans devoir donner d'argent à qui que ce soit pour bénéficier de ce privilège.

La formule « composant d'une distribution d'un ensemble contenant des programmes de diverses origines » avait pour but de combler une lacune de la licence Artistic (artistique), dont personnellement je trouve qu'elle manque de rigueur, qui a été mise au point pour Perl, à l'origine. De nos jours, presque tous les programmes qui en font usage sont aussi proposés selon les conditions de la GPL. C'est pourquoi cette clause n'est plus nécessaire, et disparaîtra peut-être d'une prochaine version de la définition de l'Open Source.

2. Code source

Le programme doit inclure le code source, et la distribution sous forme de code source comme sous forme compilée doit être autorisée. Quand une forme d'un produit n'est pas distribuée avec le code source correspondant, il doit exister un moyen clairement indiqué de télécharger le code source, depuis l'Internet, sans frais supplémentaires. Le code source est la forme la plus adéquate pour qu'un programmeur modifie le programme. Il n'est pas autorisé de proposer un code source rendu difficile à comprendre. Il n'est pas autorisé de proposer des formes intermédiaires, comme ce qu'engendre un pré-processeur ou un traducteur automatique.

Le code source est un préliminaire nécessaire à la correction ou la modification d'un programme. L'intention est ici de faire en sorte que le code source soit distribué aux côtés de la version initiale et de tous les travaux qui en dériveront.

3. Travaux dérivés

La licence doit autoriser les modifications et les travaux dérivés, et leur distribution sous les mêmes conditions que celles qu'autorise la licence du programme original.

Le logiciel est de peu d'utilité à qui ne peut pas assurer son évolution (correction des bogues, ports vers des nouveaux systèmes, apport d'améliorations), et il est nécessaire pour cela de le modifier. L'intention est ici d'autoriser tous types de modifications. Il faut autoriser qu'un travail dérivé soit distribué sous les mêmes conditions de licence que le travail original. Cependant, on n'exige pas que le producteur d'un travail dérivé utilise les mêmes conditions de licence, on n'impose que de leur laisser la possibilité de ce faire. Les différentes licences traitent ce problème de manières diverses : la licence BSD vous autorise de privatiser vos modifications, alors que GPL vous l'interdit.

Certains auteurs de logiciels craignent que cette clause n'autorise des gens peu scrupuleux à modifier leur logiciel de sorte à mettre dans l'embarras l'auteur original du logiciel. Ils ont peur qu'un individu mal intentionné ne fasse réagir le logiciel de manière incorrecte en laissant croire que l'auteur original était un programmeur de piètre qualité. D'autres craignent que le logiciel ne soit modifié pour des utilisations criminelles, par l'addition de fonctions jouant le rôle de cheval de Troie ou de techniques interdites dans certains pays ou régions, comme la cryptographie. Mais de telles actions tombent sous le coup des lois. On pense souvent à tort que les licences de logiciels devraient tout spécifier, y compris des détails comme « n'utilisez pas ce logiciel pour commettre un crime. ». Mais aucune licence n'a d'existence en dehors d'un corpus de lois civiles et pénales. Considérer qu'une licence peut s'affranchir du corpus des lois en vigueur est aussi idiot que considérer qu'un document rédigé en français puisse s'affranchir du dictionnaire, auquel cas aucun des mots utilisés n'aurait la moindre signification arrêtée.

4. Intégrité du code source de l'auteur

La licence ne peut restreindre la redistribution du code source sous forme modifiée que si elle autorise la distribution de fichiers « patch » aux côtés du code source dans le but de modifier le programme au moment de la construction.

Certains auteurs craignaient que d'autres ne distribuent le code source enrichi de modifications qui pourraient être perçues comme relevant du travail de l'auteur original, en donnant une mauvaise image de lui. Cette clause leur donne la possibilité d'imposer que les modifications soient bien distinctes de leur propre travail, sans pour autant interdire toute modification. Certaines personnes trouvent inesthétique le fait que les modifications encourent le risque de devoir être distribuées sous la forme d'un fichier de modifications (patch) distinct du code source, alors même que des distributions de Linux comme Debian ou Red Hat font usage d'une telle procédure pour mettre en place les modifications qu'elles apportent aux programmes qu'elles distribuent. Il existe des programmes qui fondent directement les modifications au sein du code source principal, et on peut faire en sorte qu'ils soient exécutés automatiquement lors de l'extraction d'un paquetage de code source. C'est pourquoi une telle clause ne devrait pas causer de difficultés majeures.

Vous remarquerez aussi que cette clause stipule que dans le cas des fichiers de modifications, la modification n'a lieu qu'au moment de la construction. La licence publique de Qt exploite cette lacune pour imposer une licence différente, quoique plus permissive, en matière de fichiers de modifications, en contradiction avec la section 3 de la définition de l'Open Source. Il existe le projet de corriger cette lacune dans la définition sans pour autant faire perdre à la licence Qt son état de licence Open Source.

La licence doit explicitement permettre la distribution de logiciel construit à partir du code source modifié. La licence peut exiger que les travaux dérivés portent un nom différent ou un numéro de version distinct de ceux du logiciel original.

Cela signifie que la société Netscape, par exemple, peut insister sur le fait qu'elle seule a le droit de donner à une version du programme le nom de Netscape Navigator© , alors que les versions libres du programme doivent porter un nom comme Mozilla ou autre chose encore.

5. Pas de discrimination entre les personnes ou les groupes

La licence ne doit opérer aucune discrimination à l'encontre de personnes ou de groupes de personnes.

Une licence proposée par les Régents de l'université de Californie, à Berkeley, interdisait qu'un programme de conception de circuits électroniques soit employé par les forces de police de l'Afrique du Sud. Ce sentiment avait beau être généreux du temps de l'apartheid, cette clause n'a plus grand sens de nos jours. Certaines personnes sont toujours coincées avec le logiciel qu'elles ont acquis sous cette condition, dont les versions dérivées doivent elles aussi porter la même restriction. Les licences Open Source ne doivent rien renfermer de tel, quelle que soit la générosité qui dicte de telles intentions.

6. Pas de discrimination entre les domaines d'application

La licence ne doit pas limiter le champ d'application du programme. Par exemple, elle ne doit pas interdire l'utilisation du programme pour faire des affaires, ou dans le cadre de la recherche génétique.

Votre logiciel doit pouvoir être utilisé aussi bien par une clinique qui pratique des avortements que par une organisation militant contre le droit à l'avortement. Ces querelles politiques relèvent de l'Assemblée Nationale, et non pas des licences de logiciels. Certaines personnes sont même extrêmement choquées par cette absence de discrimination !

7. Distribution de la licence

Les droits attachés au programme doivent s'appliquer à tous ceux à qui le programme est redistribué sans que ces parties ne doivent remplir les conditions d'une licence supplémentaire.

La licence doit s'appliquer automatiquement, sans exiger une quelconque signature. Malheureusement, on ne dispose d'aucun précédent juridique solide en matière de validité d'une licence applicable sans signature, quand elle passe d'une seconde à une tierce personne. Cependant, cet argument considère que la licence fait partie du droit du contrat, alors que certains argumentent qu'elle relève du droit du copyright, où on trouve des cas de jurisprudence en matière de licences ne requérant pas de signature. Il y a fort à parier que ce débat aura lieu en cour de justice d'ici quelques années, si l'on en juge par l'emploi sans cesse croissant de ce type de licences et par l'essor fulgurant du mouvement de l'Open Source.

8. La licence ne doit pas être spécifique à un produit

Les droits attachés au programme ne doivent pas dépendre du fait que le programme fait partie d'une distribution logicielle spécifique. Si le programme est extrait de cette distribution et utilisé ou distribué selon les conditions de la licence du programme, toutes les parties auxquelles le programme est redistribué doivent bénéficier des droits accordés lorsque le programme est au sein de la distribution originale de logiciels.

Cela signifie que vous ne pouvez pas contraindre un produit identifié en tant qu'Open Source à être utilisé en tant que partie d'une distribution particulière de Linux, ou autre. Il doit rester libre, même séparé de la distribution logicielle avec laquelle il a été fourni.

9. La licence ne doit pas contaminer d'autres logiciels

La licence ne doit pas apposer de restrictions sur d'autres logiciels distribués avec le programme qu'elle couvre. Par exemple, la licence ne doit pas exiger que tous les programmes distribués grâce au même médium soient des logiciels « open-source ».

Une version de GhostScript (programme de rendu de PostScript) exige que le support sur lequel est distribué ce programme ne contienne que des logiciels libres. Les licences Open Source ne permettent pas cela. Heureusement, l'auteur du programme GhostScript distribue une autre version (un peu plus ancienne) de ce programme, couverte par une licence vraiment Open Source. Remarquez la différence entre dérivation et agglomération. La dérivation est le fait qu'un programme renferme en son sein une portion d'un autre programme. L'agglomération est le fait de proposer deux programmes sur le même CD-ROM. Cette section de la définition de l'Open Source traite de l'agglomération, pas de la dérivation. C'est la section 4 qui traite de cette dernière.


Page suivante Page précédente Table des matières