Analyse de la définition de l'open source

Dans cette section, je présenterai le texte complet de la définition de l'open source, en y entrelaçant des commentaires (en hors-texte). Vous en trouverez la version canonique à l'adresse http://www.opensource.org[1]

Des coupeurs de cheveux en quatre m'ont fait remarquer que la définition de l'open source renfermait quelques ambiguïtés. J'ai reculé l'instant d'une révision car ce texte date d'à peine un an et j'aimerais qu'il soit considéré comme un texte stable. Dans l'avenir, j'y incorporerai des modifications mineures sur la forme, qui n'auront que très peu d'incidence sur le fond.

Version 1.0 de la définition d'open source

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

On remarque 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 celle du 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 !

Libre redistribution.

La licence ne doit pas interdire 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 soumettre cette vente à l'acquittement de droits, quels qu'ils soient.

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 des 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.

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 un produit n'est pas distribué avec le code source correspondant, il doit exister un moyen clairement indiqué de télécharger ce 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.

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 assurer son évolution (correction des bogues, portage vers de nouveaux systèmes, amélioration), 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 mais on impose de leur laisser la possibilité de le faire. Les différentes licences traitent ce problème de manières diverses : la licence BSD vous autorise à privatiser vos modifications, alors que la 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 fonction 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 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.

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 lors de sa 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 créer de grandes privations.

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é. Elle 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 (tm), alors que les versions libres du programme doivent porter un nom comme Mozilla ou autre chose encore.

Pas de discrimination portant sur l'identité de l'utilisateur

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.

Pas de discrimination portant sur le domaine d'application

La licence ne doit pas limiter le champ d'application du programme. Par exemple, elle ne doit pas interdire son utilisation dans le monde 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. Cette exigence choque beaucoup certaines personnes !

Distribution de la licence

Les droits attachés au programme doivent s'appliquer à tous ceux à qui le programme est transmis sans que ces parties 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.

Pas de spécificité

Les droits attachés au programme ne doivent pas dépendre de l'intégration du programme à un ensemble logiciel 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 par exemple signifie que vous ne pouvez pas contraindre un produit identifié en tant qu'open source à être utilisé en tant que composant d'une distribution particulière de Linux. Il doit rester libre, même séparé de l'ensemble de logiciels avec lequelle il a été fourni.

Pas de contamination d'autres logiciels

La licence ne doit pas restreindre d'autres logiciels distribués avec le programme qu'elle protège. Par exemple, elle ne doit pas exiger que tous les programmes distribués grâce au même medium 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, sous 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. La section 4 traite de cette dernière.

Exemples de licences

Les licences suivantes sont des exemples de licences que nous jugons conformes à la définition de l'« open source » : GNU GPL, BSD, X Consortium, et Artistic. C'est aussi le cas de la MPL.

Nous aurions beaucoup de problèmes si l'une de ces licences devait être modifiée de sorte qu'elle ne relève plus de l'open source — il nous faudrait publier immédiatement une version révisée de la définition de l'open source. Ce paragraphe relève plus d'un texte d'explication que de la définition par elle-même.

Notes

[1]

N.d.T. : une version en français est disponible.