Chapitre 11. La définition de l'open source

Introduction

L'histoire

KDE, Qt, et Troll Tech

Analyse de la définition de l'open source

Analyse des licences et de concordance avec la définition de l'open source

Les licences de logiciels libres en général

Choisir une licence

L'avenir

Introduction

L'utilisateur-type d'ordinateurs possède des quantités de logiciels acquis dans le passé mais qu'il n'utilise plus. Il a peut-être acheté un ordinateur plus performant ou changé de constructeur, ce qui lui interdit d'employer ses programmes. Ils sont peut-être devenus obsolètes, ou ne répondent plus à ses besoins. Il a peut-être acheté plusieurs ordinateurs et ne souhaite pas débourser quoi que ce soit pour obtenir un deuxième exemplaire du même logiciel. Quelle qu'en soit la raison, le logiciel lui a coûté de l'argent voici quelques années et ne remplit plus son rôle. Cette situation est-elle inévitable ?

Que penseriez-vous d'une situation dans laquelle vous auriez le droit d'obtenir une mise à jour dès que cela s'avère nécessaire ? Que penser d'une situation dans laquelle, en passant l'architecture Mac à l'architecture compatible IBM PC, on pourrait changer gratuitement les versions des logiciels ? Et si, quand par malheur le logiciel ne fonctionne pas ou ne remplit pas tous vos besoins, vous pouviez le faire améliorer ou le réparer vous-même ? Peut-on imaginer qu'un logiciel soit encore maintenu et disponible après la faillite de son éditeur ? Que l'on puisse les utiliser sur la station de travail installée au bureau, sur l'ordinateur personnel du domicile, et sur son portable, plutôt que d'être limité à une seule machine ? Si tel était le cas, vous continueriez sans doute à utiliser les logiciels achetés voici des années. Ce sont là quelques-uns des droits que l'open source vous garantit.

L'open source est une déclaration des droits de l'utilisateur d'ordinateur. Elle définit certains droits que la licence d'un logiciel doit lui garantir afin d'être qualifiée d'open source. Ceux qui ne proposent pas des programmes open source estiment que les autres leur opposent une concurrence de plus en plus rude, car ils n'ont pas compris que les utilisateurs prennent enfin conscience de leurs droits, et donc les revendiquent. Des programmes comme ceux qui constituent le système d'exploitation GNU/Linux et le navigateur web de Netscape ont acquis une grande popularité en prenant la place de logiciels protégés par des licences plus restrictives. Les sociétés qui utilisent du logiciel open source profitent des avantages liés à un modèle de développement très réactif, souvent mis en place par plusieurs sociétés qui coopèrent, et dont une grande partie du travail est fournie par des indépendants qui ont tout simplement besoin d'une amélioration qui réponde mieux à leurs besoins.

Les volontaires qui ont créé des produits comme Linux n'existent, et les sociétés ne peuvent coopérer, que grâce aux droits fournis par l'open source. Le programmeur moyen se sentirait lésé s'il investissait énormément de travail dans un programme, pour constater que le propriétaire de ce dernier se contente de vendre la version améliorée sans rien lui proposer en retour. Mais ces mêmes programmeurs n'ont pas peur d'apporter des contributions à l'open source, car ils savent que les droits suivants leur sont alors garantis :

• le droit de faire des copies du programme, et de les distribuer,

• le droit d'accéder au code source du logiciel, un préliminaire nécessaire pour pouvoir y apporter des modifications,

• le droit d'améliorer le programme.

Ces droits comptent pour celui qui contribue à améliorer des logiciels car ils maintiennent tous les développeurs au même niveau. Quiconque le souhaite a le droit de vendre un programme open source, aussi les prix seront-ils bas et le développement destiné à conquérir de nouveaux marchés sera-t-il rapide. Quiconque investit de son temps à construire des connaissances sous la forme d'un programme open source peut fournir de l'aide sur ce dernier, et cela fournit aux utilisateurs la possibilité de mettre en place leur propre assistance technique, ou de choisir parmi des assistances techniques en concurrence les unes avec les autres. Tout programmeur peut spécialiser un programme open source pour le rendre utilisable dans des marchés spécifiques afin d'atteindre de nouveaux consommateurs. Ceux qui se lancent dans de telles entreprises ne sont pas tenus d'acquitter des royalties ni la moindre licence.

La raison de la réussite de cette stratégie qui semble s'inspirer du communisme, alors que le communisme est lui-même un échec patent dans le monde entier, vient du fait que l'économie de l'information est fondamentalement différente de l'économie qui règle la consommation des autres produits. On peut copier une information telle qu'un programme d'ordinateur pour un prix dérisoire. L'électricité qu'il en coûte ne dépasse par l'eurocent, pas plus que l'utilisation de l'équipement nécessaire à cet acte. En comparaison, on ne peut pas recopier une miche de pain sans dépenser une livre de farine.

L'histoire

Le concept de logiciel libre est ancien. Quand les ordinateurs sont entrés dans les universités, c'était en tant qu'outils de recherche. Les logiciels étaient librement passés de laboratoire en laboratoire, et les programmeurs étaient payés pour le fait de programmer, et non pour les programmes en eux-mêmes. Ce n'est que plus tard, quand les ordinateurs sont entrés dans le monde des affaires, que les programmeurs ont commencé à subvenir à leurs besoins en limitant les droits associés à leurs logiciels et en en taxant chaque copie. Richard Stallman répand les concepts politiques liés au Logiciel Libre depuis 1984, année où il créa la Free Software Foundation et son projet GNU. La prémisse de M. Stallman est que tout le monde devrait jouir de plus de liberté, et savoir l'apprécier. Il a dressé la liste des droits dont tout utilisateur doit selon lui jouir, et les a codifiés au sein de la licence publique générale de GNU, ou GPL. M. Stallman a intitulé, non sans malice, cette licence « gauche d'auteur » (copyleft), car au lieu d'interdire, elle donne le droit de copier. M. Stallman a lui-même développé de féconds travaux en matière de logiciels libres, tels que le compilateur de langage C du projet GNU, et GNU Emacs, un éditeur disposant d'attraits tels que certains en parlent comme d'une religion. Ses travaux ont inspiré de nombreux autres développeurs à proposer du logiciel libre selon les conditions de la GPL. Même si elle n'est pas promue avec la même ferveur libertaire, la définition de l'open source reprend de nombreuses idées de M. Stallman, et on peut la considérer comme un texte dérivé de ses propres travaux.

La définition de l'open source a vu le jour en tant que document présentant les grandes lignes du logiciel libre au sens de la distribution Debian de Gnu/Linux. Debian, un système Linux de la première heure, toujours populaire de nos jours, était entièrement constitué de logiciels libres. Cependant, comme la « gauche d'auteur » n'était pas la seule licence qui prétendît couvrir du logiciel « libre », Debian avait des difficultés à tracer la limite entre ce qui est libre et ce qui ne l'est pas, et n'avait jamais clairement indiqué les règles qu'elle appliquait pour déterminer si un logiciel était libre ou non. Je dirigeais alors le projet Debian, et j'ai résolu ce problème en proposant le Contrat social de Debian et les Lignes de conduite en matière de logiciel libre de Debian en juillet 1997. De nombreux développeurs Debian ont proposé des critiques et des améliorations, que j'incorporais peu à peu dans les documents. Le Contrat social documentait l'intention de la distribution Debian de ne composer leur système que de logiciels libres, et les Lignes de conduite en matière de logiciel libre permettaient de classer facilement le logiciel en deux catégories, « libre » ou non, en comparant la licence du logiciel aux lignes de conduite.

La ligne de conduite de Debian reçut les louanges de la communauté du logiciel libre, et en particulier des développeurs de Linux, qui menaient alors leur propre révolution du logiciel libre en développant le premier système d'exploitation libre utilisable. Quand la société Netscape a décidé de faire de son navigateur pour le web un logiciel libre, elle a contacté Eric Raymond, véritable Margaret Meade [1] du logiciel libre qui a écrit plusieurs articles anthropologiques expliquant ce phénomène et détaillant la culture qui a peu à peu germé autour de lui, premiers travaux sur le sujet qui ont fait la lumière sur ce phénomène auparavant peu connu. La direction de la société Netscape fut impressionnée par l'essai de M. Raymond intitulé « La cathédrale et le bazar », chronique de la réussite du développement de logiciels libres, qui n'utilise que des contributeurs volontaires non rémunérés, et l'a engagé en tant que conseiller, sous un accord de non divulgation, pendant qu'elle développait une licence pour son propre logiciel libre. M. Raymond leur a clairement indiqué qu'il fallait que cette licence suive les lignes de conduite de Debian pour être prise au sérieux en tant que licence de logiciel libre.

J'ai rencontré M. Raymond de façon fortuite à la conférence des Hackers, réunion peu conventionnelle de programmeurs créatifs, réservée aux invités. Nous avions traité de divers sujets par courrier électronique. Il m'a contacté en février 1997 en me présentant l'idée de l'open source. Il regrettait alors que les hommes d'affaires, conservateurs, soient effrayés par le mouvement de liberté initié par M. Stallman, qui rencontrait par contraste un écho très favorable auprès des programmeurs les plus libertaires. Il pensait que cela étouffait le développement de Linux dans le monde des affaires tout en encourageant sa croissance dans le milieu de la recherche. Il a rencontré les hommes d'affaires de l'industrie balbutiante qui se formait autour de Linux, et ils ont conçu ensemble un programme pour faire la campagne du concept de logiciel libre auprès de ceux qui portent des cravates. Larry Augustin, de VA Research, et Sam Ockman (qui a quitté VA un peu plus tard pour créer la société Penguin Computing) ont participé à l'affaire, ainsi que d'autres personnes, que je n'ai pas la chance de connaître.

Quelques mois avant de lancer le projet de l'open source, j'avais conçu l'idée de l'Open Hardware [2], concept similaire, mais traitant des périphériques matériels et de leurs interfaces plutôt que de programmes et de logiciels. L'Open Hardware n'a pas rencontré à ce jour le même succès que l'open source, mais il suit son bonhomme de chemin et vous trouverez toutes informations le concernant à l'adresse http://www.openhardware.org/.

M. Raymond estimait que les Lignes de conduite du logiciel libre selon Debian était le document indiqué pour définir l'open source, mais qu'il leur fallait un nom plus général et en extirper toute référence spécifique à la distribution Debian. J'ai édité les Lignes de conduite pour mettre en place la définition de l'open source. J'avais formé une corporation pour Debian, intitulée SPI (logiciel d'intérêt public), et j'ai proposé d'enregistrer une marque déposée pour l'open source de telle sorte qu'on puisse réserver son utilisation aux logiciels qui répondent à la définition. M. Raymond étant d'accord avec cette idée, j'enregistrai la marque de certification, ce qui est une forme particulière de marque déposée, à appliquer aux produits des autres. Un mois après que j'aie enregistré cette marque, il était devenu clair que SPI n'était pas le lieu d'hébergement idéal pour la marque open source, et j'en ai transféré la propriété à M. Raymond. Depuis, nous avons créé l'open source Initiative, organisation dont le seul but est de gérer la campagne de l'open source et sa marque de certification. Au moment de cet écrit, son conseil d'administration compte six membres choisis parmi des contributeurs renommés du monde du logiciel libre, et cherche à atteindre la taille d'environ dix membres.

Lors de son lancement, la campagne de l'open source a suscité de nombreuses critiques, même au sein des troupes dévouées à Linux, qui avaient déjà accepté le concept du logiciel libre. Nombreux sont ceux qui signalèrent que le terme « open source » était déjà employé dans l'industrie de XXX . D'autres pensaient que le mot « Open » était déjà utilisé à toutes les sauces. D'autres, simplement, préféraient le terme Free Software, établi. J'ai répondu que le galvaudage du terme « Open » ne pourrait jamais causer autant de tort que l'ambiguïté, dans la langue anglaise, du terme « Free » — la liberté ou la gratuité [3], la notion de « gratuité » étant celle que le monde commercial, en informatique, met le plus souvent en avant. Richard Stallman a plus tard pris ombrage du fait que la campagne ne mettait pas suffisamment l'accent sur la liberté, et que le mouvement de l'open source gagnant en popularité, son rôle dans la genèse du logiciel libre, ainsi que celui de la Free Software Foundation qu'il a créée, étaient passés sous silence — il s'est plaint d'être « effacé des livres d'histoire ». La situation s'est aggravée par la tendance qu'ont les industriels de comparer MM. Raymond et Stallman comme s'ils défendaient des philosophies contradictoires, sans comprendre qu'en réalité ils ne font qu'utiliser des méthodes différentes pour promouvoir le même concept. J'ai probablement contribué à jeter de l'huile sur le feu en opposant MM. Stallman et Raymond dans des débats tenus à l'occasion des manifestations Linux Expo et open source Expo. Leurs confrontations étaient si appréciées que le journal en ligne Salon est allé jusqu'à publier un débat qu'ils ont tenu par courrier électronique, sans jamais avoir eu l'intention de le publier. Quand nous en fûmes rendus là, j'ai demandé à M. Raymond de calmer un jeu auquel il n'avait jamais eu l'intention de participer.

Lors de l'écriture de la définition de l'open source, nombreux déjà étaient les programmes qui y satisfaisaient. Mais un problème se posait dans le cas des programmes qui n'y correspondaient pas, tout en plaisant aux utilisateurs.

KDE, Qt, et Troll Tech

Il faut ici traiter du groupe de développement de KDE et de la société Troll Tech car ils ont tenté de placer un produit non conforme à l'open source dans l'infrastructure de Linux, et se sont heurtés à une résistance qu'ils n'avaient pas su prévoir. Le tollé général et la menace d'un remplacement de leur produit par une solution open source ont finalement convaincu la société Troll Tech d'adopter une nouvelle licence pleinement conforme à l'open source. C'est un exemple intéressant de l'acceptation enthousiaste par la communauté de la définition de l'open source, si forte qu'il fallait que la société Troll Tech s'y plie si elle souhaitait que son produit soit bien accueilli.

KDE représente la première tentative d'un bureau graphique libre pour Linux. Les applications de KDE étaient par elles-mêmes protégées par la GPL, mais elles dépendaient d'une bibliothèque graphique propriétaire, appelée Qt, et développée par la société Troll Tech. Les conditions de la licence de Qt en interdisaient la modification ou l'utilisation en relation avec tout logiciel d'affichage graphique autre que le vieillissant X Window System. Pour ces autres utilisations, il fallait acheter une licence de développeur qui s'élevait à 1 500 USD. La société Troll Tech fournissait des versions de Qt pour les systèmes MS-Windows et Macopen source, et c'était là sa première source de revenus. La prétendue « licence libre » pour les systèmes fonctionnant sous « X » avait pour objectif de susciter des contributions de la part des développeurs de Linux en matière de démonstrations, exemples, et autres accessoires, qu'ils revendraient ensuite dans le cadre de leurs produits pour MS-Windows et Macopen source, qui n'étaient pas donnés.

Malgré la clarté des problèmes posés par la licence de Qt, la perspective de disposer d'un bureau graphique sous Linux était si séduisante que de nombreux utilisateurs étaient prêts à fermer les yeux sur le fait que ce n'était pas vraiment une licence de type open source. Les défenseurs de l'open source remettaient KDE en question car ils estimaient que les développeurs de KDE tentaient d'estomper la définition du logiciel libre pour y inclure des éléments qui ne le sont que partiellement, comme Qt. Ce à quoi ces derniers rétorquaient que leurs programmes étaient open source, même s'il n'en existait aucune version exécutable qui ne nécessitât pas de bibliothèque non open source. D'autres et moi pensions que les applications de KDE n'étaient que des fragments open source de programmes non open source, et qu'on ne pourrait pas qualifier KDE d'open source avant de disposer d'une version open source de Qt.

Les développeurs de KDE ont tenté de résoudre en partie le problème posé par la licence de KDE en négociant un accord sur une base Qt libre pour KDE avec Troll Tech, selon lequel ces derniers et le groupe KDE contrôleraient ensemble les publications de la version libre de Qt, et Troll Tech publierait Qt selon les conditions d'une licence conforme à l'open source si la société devait être rachetée ou faire banqueroute.

Un autre groupe de programmeurs démarra alors le projet GNOME, un concurrent de KDE pleinement open source, qui visait à être plus sophistiqué et à proposer plus de fonctionnalités, pendant qu'un troisième groupe démarrait un projet intitulé Harmony dans le but de produire un clone de Qt pleinement open source, qui permettrait de faire fonctionner KDE. Alors que le projet GNOME était applaudi de tous et que le projet Harmony était sur le point d'aboutir, la société Troll Tech a compris que Qt ne rendrait aucun service au marché de Linux tant que sa licence demeurerait en l'état. Troll Tech a publié une licence pleinement open source pour Qt, désamorçant ainsi le conflit, et laissant retomber le projet Harmony comme un soufflé. Mais le projet GNOME suit son cours, et cherche maintenant à surclasser KDE en termes de fonctionnalités et de sophistication, plutôt qu'en matière de licence.

Avant de publier sa licence open source, la société Troll Tech m'en a fourni une copie pour que je l'examine, en me demandant de n'en rien laisser filtrer jusqu'au moment où elle l'annoncerait. Trop enthousiaste d'enterrer la hache de guerre avec le groupe KDE et victime d'un aveuglement passager que je me reprocherais par la suite, j'ai fait une pré-annonce de leur future licence avec huit heures d'avance sur une liste de diffusion consacrée à KDE. Ce courrier fut presque immédiatement repris, à mon grand regret, par les principaux sites d'information en ligne, dont Slashdot.

La nouvelle licence de Troll Tech a ceci de remarquable qu'elle tire avantage d'un point faible de la définition de l'open source qui accorde aux fichiers de modifications (patches) un statut particulier. Je souhaiterais le corriger dans une prochaine version de la définition de l'open source, mais ce nouveau texte excluerait alors de nouveau la bibliothèque Qt.

Au moment où j'écris ces lignes, le nombre de défenseurs de l'open source augmente exponentiellement. Les récents apports des sociétés IBM et Ericsson au mouvement de l'open source ont fait la une. On compte deux distributions de Linux, Yggdrasil et Debian, qui diffusent des systèmes Linux conformes en tous points à l'open source, sans pour autant se priver d'une grande richesse de logiciels, tandis que plusieurs autres distributeurs, comme Red Hat, n'en sont pas loin. Quand le projet GNOME sera disponible [4], on disposera enfin d'un système d'exploitation avec bureau à interface utilisateur graphique, digne de concurrencer MS-Windows NT et entièrement open source.

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 [5].

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.

Analyse des licences et de leur concordance avec la définition de l'open source

Pour comprendre la définition de l'open source, il faut examiner de quelle manière certaines licences communes en remplissent ou non les critères.

Domaine public

Une idée reçue incorrecte veut que la plupart des logiciels libres relèvent du domaine public [6]. La raison en est tout simplement que l'idée du logiciel libre ou de l'open source est difficile à appréhender pour de nombreuses personnes qui considèrent donc que ces programmes sont du domaine public car c'est là le concept le plus proche qu'ils arrivent à comprendre. Ces programmes disposent clairement, cependant, d'un copyright, et sont protégés par une licence. Il se trouve simplement que cette licence accorde plus de droits aux utilisateurs qu'ils n'en ont l'habitude.

Un programme du domaine public est un programme sur lequel son auteur a délibérément choisi de ne pas faire valoir ses droits. On ne peut pas vraiment dire qu'il est assorti d'une licence ; quiconque peut l'utiliser comme bon lui semble, car quiconque peut le traiter comme s'il lui appartenait. On peut même assujettir un programme du domaine public à une nouvelle licence, en ôtant cette version modifiée du domaine public, ou en ôter le nom de l'auteur et traiter le programme comme son propre travail.

Si vous travaillez beaucoup sur un programme du domaine public, envisagez le fait d'y apposer votre propre copyright et de lui appliquer une nouvelle licence. Si vous ne souhaitez pas, par exemple, qu'un tiers le modifie d'une manière qu'il gardera secrète ensuite, appliquez à votre version du programme la GPL, ou une licence similaire. La version de laquelle vous êtes parti se trouvera encore dans le domaine public, mais votre propre version sera placée sous une licence que les autres devront prendre en compte s'ils veulent l'utiliser ou en proposer des travaux dérivés.

Vous pouvez facilement capter (rendre privé) un programme du domaine public en déclarant un copyright et en lui appliquant votre propre licence, ou simplement en déclarant « tous droits réservés. »

Les licences de logiciels libres en général

Si vous disposez d'un collection de logiciels libres telle qu'un disque renfermant une distribution de GNU/Linux, vous pensez peut-être posséder les programmes qui se trouvent sur ce disque. Ce n'est pas exactement vrai. Les programmes sous copyright appartiennent au détenteur du copyright, même lorsqu'ils sont protégés par une licence open source telle que la GPL. La licence du programme vous octroie certains droits, et d'autres droits vous sont acquis selon la définition d'« utilisation raisonnable » dans le droit du copyright. Il est important de remarquer qu'un auteur n'est pas limité à proposer un programme sous une seule licence. On peut protéger un programme par la GPL et en vendre en même temps une version sous une licence commerciale et non open source. C'est exactement cette tactique qu'emploient de nombreuses personnes, qui veulent qu'un programme soit open source tout en souhaitant gagner de l'argent à partir de ce dernier. Ceux qui ne souhaitent pas d'une licence open source encourent le risque de devoir rémunérer un tel privilège, assurant par là même un revenu à l'auteur. Toutes les licences que nous allons maintenant examiner ont un point en commun : aucune ne fournit la moindre garantie. L'intention est de protéger le propriétaire du logiciel de toute poursuite en justice relative à son programme. Les programmes étant souvent offerts sans contrepartie financière, c'est là une exigence raisonnable — le programme ne garantit pas un revenu suffisant pour que son auteur puisse acquitter une assurance et les frais engagés en cas de poursuite en justice. Si les auteurs de logiciels libres perdent ce droit de ne fournir aucune garantie et sont poursuivis en justice suite aux effets des programmes qu'ils ont écrits, ils cesseront d'écrire des logiciels libres. C'est dans notre avantage d'utilisateurs que d'aider les auteurs à protéger ce droit.

La licence publique générale de GNU

La GPL est autant un manifeste politique qu'une licence de logiciel, et une grande partie de ce texte est dévolue à justifier les motifs qui ont poussé son auteur à la rédiger. Ce dialogue politique a déplu à certains, et c'est en partie à cause de cela que d'autres licences de logiciels libres ont été rédigées. Cependant, la GPL a été rédigée avec le concours de professeurs de droit, elle est donc bien mieux écrite que la plupart des autres licences de son genre. Je vous encourage vivement à employer la GPL, ou sa variante pour bibliothèques la LGPL, si vous le pouvez. Si vous choisissez une autre licence, ou écrivez la vôtre propre, vérifiez que les raisons qui vous poussent à cela sont valables. Il faut bien expliquer à ceux qui écrivent leurs propres licences que ce n'est pas là une décision à prendre à la légère. Les complications inattendues qu'une licence mal écrite peut entraîner peuvent créer, pendant plusieurs décennies, un fardeau pour les utilisateurs du logiciel.

Le texte de la GPL n'est pas lui-même placé sous la GPL. Cette licence est simple : quiconque a le droit de copier et de distribuer des copies exactes du document de cette licence, mais pas de le modifier. Il faut remarquer que le texte des licences open source n'est pas en général pas open source car, à l'évidence, une licence que tout un chacun pourrait modifier n'offrirait qu'une protection limitée.

Les dispositions de la GPL satisfont la définition de l'open source. La GPL n'exige aucune des clauses autorisées par le paragraphe 4 de la définition de l'open source, « Intégrité du code source de l'auteur ».

La GPL ne vous autorise pas à rendre des modifications secrètes. Vos modifications doivent elles aussi être distribuées selon les termes de la GPL. Ainsi, l'auteur d'un programme sous GPL recevra probablement des améliorations proposées par d'autres, y compris des sociétés commerciales qui modifient son logiciel pour leurs besoins propres.

La GPL n'autorise l'incorporation d'un programme GPL au sein d'un programme propriétaire. La définition de « programme propriétaire » utilisée par cette licence est : « tout programme dont la licence vous donne moins de droits que ne vous en donne la GPL. »

La GPL contient quelques échappatoires qui lui permettent d'être utilisée dans des programmes qui ne sont pas entièrement open source. On peut lier les bibliothèques de logiciels qui sont distribuées avec le compilateur ou le système d'exploitation avec des logiciels protégés par la GPL ; il en résulte un programme partiellement libre. Le détenteur du copyright (qui est en général l'auteur du programme) est la personne qui place la GPL sur son programme et qui dispose du droit de violer sa propre licence. C'est ce que faisaient les auteurs de KDE pour distribuer leurs programmes avec Qt avant que la société Troll Tech ne place la bibliothèque Qt sous une licence open source. Cependant, ce droit ne s'étend pas aux tiers qui redistribuent le programme — ils doivent suivre tous les termes de la licence, même ceux que le détenteur du copyright viole, c'est pourquoi il est problématique de redistribuer un programme GPL s'il contient Qt. Les développeurs de KDE semblent avoir résolu ce problème en appliquant la LGPL, et non la GPL, à leurs logiciels.

La rhétorique politique de la GPL déplaît à certaines personnes, dont une partie ont choisi pour leurs logiciels une licence moins appropriée pour la seule raison qu'ils fuient les idées de Richard Stallman et ne souhaitent pas les voir répétées dans leurs propres paquetages de logiciels.

La licence publique générale de GNU pour les bibliothèques

La LGPL est dérivée de la GPL et mise au point pour les bibliothèques de logiciels. À la différence de ce qui se produit avec la GPL, on peut incorporer un programme sous LGPL dans un programme propriétaire. La bibliothèque du langage C fournie avec les systèmes GNU/Linux est un exemple de logiciel sous LGPL — on peut l'utiliser pour construire des programmes propriétaires, sans quoi Linux ne serait utile qu'aux auteurs de logiciels libres.

On peut à tout moment convertir une instance d'un programme LGPL en programme GPL. Mais on ne peut ensuite plus reconvertir cette instance, ni tout ce qui en dérive, en programme sous LGPL.

Les autres dispositions de la LGPL sont semblables à celles de la GPL — en fait, cette licence inclut la GPL en y faisant référence.

Les licences X, BSD, et Apache

La licence X et celles qui lui sont proches — les licences BSD et Apache —  sont très différentes de la GPL et de la LGPL. Elles vous autorisent à tout faire avec les logiciels qu'elles protègent. Cela, parce que les logiciels que les licences X et BSD couvraient à l'origine était financés par des bourses du gouvernement des États-Unis d'Amérique. Puisque les citoyens des États-Unis d'Amérique avaient déjà payé pour ces logiciels une fois, avec leurs impôts, ils ont reçu la permission d'utiliser ces logiciels comme bon leur semblait.

La permission la plus importante, qu'on ne trouve pas dans la GPL, est qu'on peut rendre secrètes des modifications apportées à un programme sous licence X. En d'autres termes, vous pouvez récupérer le code source d'un programme protégé par la licence X, le modifier, et vendre ensuite des versions binaires de ce programme sans en distribuer le code source correspondant, et sans appliquer la licence X à ces modifications. Cela n'en reste pas moins de l'open source, car la définition de l'open source n'exige pas que les modifications soient sous la licence originale.

Nombreux furent les autres développeurs qui ont adopté la licence X et ses variantes, parmi lesquels on remarquera on particulier la BSD (distribution du système de Berkeley) et le projet de serveur web Apache. Une spécificité ennuyeuse de la licence BSD est qu'une de ses dispositions exige qu'on mentionne (généralement dans une note de bas de page) que le logiciel a été développé à l'université de Californie à chaque fois qu'on fait la publicité d'un aspect d'un programme couvert par la licence BSD. Garder la trace des logiciels sous licence BSD dans un ensemble aussi vaste qu'une distribution GNU/Linux, et penser à mentionner l'université de Californie à chaque fois qu'on mentionne l'un de ces programmes dans une publicité, sont des tâches trop lourdes pour ceux qui sont dans les affaires. Au moment où j'écris ces lignes, la distribution Debian GNU/Linux compte plus de 2 500 paquetages logiciels, et même si seule une fraction d'entre eux était sous la licence BSD, toute publicité pour un système GNU/Linux comme la distribution Debian impliquerait des pages et des pages de notes ! Cependant, la licence du Consortium X ne comporte pas cette clause relative à la publicité. Si vous envisagez d'utiliser une licence de la famille BSD, choisissez plutôt la licence X.

La licence Artistique

Même si cette licence, à l'origine, a été développée pour Perl, elle a depuis été employée pour d'autres logiciels. Je pense que c'est une licence rédigée sans soin, en ce sens qu'elle pose des exigences et qu'elle donne ensuite des échappatoires pour les contourner. C'est peut-être la raison pour laquelle presque tous les logiciels couverts par la licence Artistic le sont désormais par deux licences, offrant le choix entre l'Artistic et la GPL.

La section 5 de la licence Artistic interdit la vente du logiciel, mais autorise la vente d'une distribution contenant plusieurs logiciels. Ainsi, il suffit d'empaqueter un programme couvert par la licence Artistic dans un ensemble contenant également un « Hello world! » de cinq lignes écrit en C pour avoir le droit de vendre ce paquet. C'est cette spécificité de la licence Artistic qui était la seule cause de l'échappatoire « composant d'une distribution d'un ensemble... » du premier paragraphe de la définition de l'open source. L'utilisation de la licence Artistic déclinant, nous pensons ôter cette précision. Cela ferait de la licence Artistic une licence non open source. Ce n'est pas là une décision à prendre à la légère, et nous y penserons et en débattrons probablement pendant plus d'un an avant de la prendre.

La licence Artistic vous oblige à libérer les modifications que vous pouvez être amené à faire, tout en vous laissant une échappatoire (dans la section 7) qui vous autorise à garder secrètes des modifications, ou même à placer des portions d'un programme sous licence Artistic dans le domaine public !

La licence publique de Netscape et la licence publique de Mozilla

La NPL a été développée par la société Netscape quand elle a rendu son produit, Netscape Navigator, open source. En réalité, la version open source s'appelle Mozilla ; les gens de Netscape réservent la marque Navigator à leur propre produit. Eric Raymond et moi intervînmes en tant que conseillers non rémunérés tout au long du développement de cette licence. J'ai tenté, sans succès, de persuader la société Netscape d'utiliser la GPL, et suite à leur refus, je les ai aidés à composer une licence qui remplirait les conditions de la définition de l'open source.

La NPL a ceci de particulier qu'elle renferme des privilèges particuliers, dont seul jouit la société Netscape. Elle lui accorde le droit de placer des modifications apportées à leur logiciel par un tiers sous une autre licence. Les gens de Netscape peuvent rendre ces modifications secrètes, les améliorer, et refuser de communiquer le résultat. Cette clause était nécessaire car quand la société Netscape a décidé de placer son produit principal sous une licence open source, elle était sous contrat avec d'autres sociétés qui ont exigé d'obtenir le logiciel Navigator sous une licence non open source.

La société Netscape a créé la MPL, ou licence publique de Mozilla, pour régler ce problème. La MPL ressemble beaucoup à la NPL, mais ne contient pas la clause qui autorise Netscape à placer des modifications extérieures sous une autre licence.

La NPL et la MPL vous autorisent à rendre certaines modifications secrètes.

De nombreuses sociétés ont adopté une variante de la MPL pour leurs propres programmes. C'est regrettable, car la NPL a été créée en fonction de la situation commerciale particulière dans laquelle la société Netscape se trouvait alors, et elle n'est pas forcément appropriée à d'autres usages. Il vaut mieux qu'elle demeure la licence de Netscape et de Mozilla, et que les autres utilisent la GPL ou la licence X.

Choisir une licence

N'écrivez pas une nouvelle licence si vous pouvez employer l'une de celles qui sont listées ici. La propagation de licences nombreuses et incompatibles cause du tort au logiciel open source car on ne peut pas utiliser des fragments d'un programme au sein d'un autre programme si les deux licences qui les protègent sont incompatibles.

Abstenez-vous d'utiliser la licence Artistic à moins que vous ne prévoyiez de l'étudier attentivement et d'en ôter les échappatoires. Puis, prenez quelques décisions :

1. Souhaitez-vous ou non que l'on puisse rendre des modifications secrètes ? Si vous souhaitez pouvoir obtenir, de la part de ceux qui les ont apportées, le code source des modifications, utilisez une licence qui l'exige. La GPL et la LGPL sont de bons candidats. Si cela ne vous ennuie pas qu'on puisse modifier votre programme sans vous en rendre compte, utilisez les licences X ou Apache.

2. Souhaitez-vous que quelqu'un puisse fusionner votre programme avec son propre logiciel, propriétaire ? Si c'est le cas, utilisez la LGPL, qui autorise explicitement cela sans permettre à autrui d'apporter des modifications à votre propre code sans les publier, ou utilisez les licences Apache ou X, qui autorisent le fait de rendre des modifications secrètes.

3. Souhaitez-vous qu'on puisse vendre des versions de votre programme sous licence commerciale, non open source ? Si c'est le cas, distribuez votre programme sous les termes de deux licences. Je recommande la GPL en tant que licence open source ; vous pourrez trouver une licence commerciale appropriée dans des livres tels que Copyright Your Software (protégez vos logiciels grâce au copyright), édité par Nolo Press.

4. Souhaitez-vous que tous ceux qui utilisent votre programme acquittent une somme pour bénéficier de ce privilège ? Si c'est le cas, alors peut-être que l'open source n'est pas pour vous. Si souhaitez que certains utilisateurs vous donnent de l'argent, c'est toujours possible en publiant votre programme sous une licence open source. La plupart des auteurs de logiciels open source considèrent que leurs programmes sont des contributions au bien public, et se fichent de recevoir ou non de l'argent pour ces derniers.

Tableau 11-1. Comparaison des pratiques des différentes licences

L'avenir

Au moment où cet essai était sur le point de partir sous presse, la société IBM a rejoint le monde de l'open source, et la communauté du capital-risque découvre elle aussi l'open source. Les sociétés Intel et Netscape ont investi dans la société Red Hat, qui distribue Linux. La société VA Research, qui intègre des serveurs Linux sur des stations de travail, a annoncé qu'elle disposait d'un investisseur extérieur. La société Sendmail Inc., créée pour commercialiser sendmail, programme de distribution du courrier électronique qu'on trouve partout, a annoncé qu'elle disposait de six millions de dollars américains de fonds. Le programme de courrier électronique, Postfix, de la société IBM, est proposé selon les termes d'une licence open source, et un autre programme de la société IBM, le compilateur Jikes pour le langage Java, est proposé selon les termes d'une licence qui tente, à l'heure où j'écris ces lignes, de remplir les clauses de la définition de l'open source, sans y parvenir tout à fait. La société IBM semble vouloir modifier la licence de Jikes pour que ce programme soit vraiment open source, et rassemble les commentaires de la communauté en ce moment même.

Deux rapports internes à la société Microsoft, plus connus sous le nom de documents de Halloween, ont été portés à la connaissance de tous. Ces rapports documentent clairement le fait que la société Microsoft se sent menacée par le mouvement de l'open source et par Linux, et que la société Microsoft les attaquera tous deux pour protéger ses marchés. Il est évident que nous vivons une époque intéressante. Je pense que vous verrons la société Microsoft utiliser ses deux stratégies principales : placer les interfaces sous copyright, et protéger ses programmes à l'aide de brevets. Elle étendra les protocoles réseau, en y incluant des spécificités propres à Microsoft, qui ne seront pas disponibles pour le logiciel libre. Elle explorera, et d'autres sociétés avec elle, de nouveaux axes de recherche en informatique et pourra tout breveter avant que la communauté du logiciel libre ne puisse employer ces nouvelles techniques, et elle nous en maintiendra à distance respectueuse en exigeant le versement de sommes conséquentes pour avoir le droit d'utiliser ces brevets. J'ai écrit un essai pour le magazine sur le web Linux World expliquant comment combattre les ennemis de l'open source sur le front des brevets.

La bonne nouvelle, c'est que la société Microsoft a peur ! Dans le deuxième document Halloween, un employé de cette société s'extasie sur le sentiment qu'il a éprouvé en constatant qu'il pouvait facilement modifier des portions du système Linux pour lui faire remplir ses besoins, et que cela était bien plus facile dans le cas de Linux que ce ne l'était pour un employé de Microsoft de modifier MS-Windows NT !

Les coups de bélier provenant de l'intérieur sont les plus dangereux. Je pense que vous verrons également de plus en plus de tentatives de diluer la définition de l'open source pour lui faire inclure des produits partiellement libres, comme on l'a vu dans le cas de la bibliothèque Qt de KDE avant que la société Troll Tech n'ait été éclairée et n'ait fourni une licence open source. La société Microsoft, comme d'autres, pourraient nous causer du tort en produisant énormément de logiciels, suffisamment libres pour attirer les utilisateurs, sans pour autant proposer toutes les libertés de l'open source. On peut concevoir qu'ils pourraient tuer le développement de certaines catégories de logiciels open source en fournissant des solutions « assez bonnes » et « presque assez libres ». Cependant, la forte réaction à l'encontre du projet KDE, avant que la bibliothèque Qt ne soit pleinement open source, laisse présager que de telles tentatives de la part de la société Microsoft et de ses semblables échoueront.

Jusqu'à présent, nous avons échappé aux chevaux de Troie. Mais supposons que quelqu'un qui ne nous aime pas propose un logiciel renfermant un cheval de Troie, une manière cachée de casser la sécurité d'un système GNU/Linux. Supposons ensuite que cette personne patiente jusqu'au moment où son logiciel sera bien répandu avant de rendre publique la faille et sa vulnérabilité. Le grand public aura alors vu que notre système, l'open source, peut nous laisser plus démunis face à ce type d'attaque que ne le sont les systèmes fermés de la société Microsoft, ce qui risque de porter un coup à sa confiance dans les logiciels open source. On pourra rétorquer que la société Microsoft a son compte de problèmes de sécurité, et qu'elle n'a pas besoin pour les insérer de gens extérieurs mal intentionnés, et que le modèle de l'open source, exposant le code source des programmes à la vue de tous, facilite la découverte de tels bogues. Tout bogue de ce type se produisant sur Linux sera corrigé le lendemain de sa publication, alors qu'un tel problème sous MS-Windows peut demeurer indécelé ou non corrigé pendant des années. Ils nous faut cependant améliorer notre défense face aux chevaux de Troie. Bien identifier ceux qui proposent des logiciels et des modifications représente notre meilleure défense, et cela nous permet de poursuivre en justice ceux qui diffusent des chevaux de Troie. Quand je dirigeais la distribution Debian GNU/Linux, nous avions mis en place un système pour identifier de manière sûre tous ceux qui maintenaient des logiciels et pour qu'ils prennent part dans un réseau de cryptographie à clé publique qui nous permettrait de vérifier de qui provenait chaque logiciel. Ce type de système a pris de l'ampleur pour finalement inclure tous les développeurs de logiciels open source.

Il nous faut encore faire des améliorations gigantesques avant que Linux puisse être employé par l'utilisateur moyen. Nous manquons clairement d'interfaces graphiques, et ce sont les projets KDE et GNOME qui traitent ce déficit. Notre prochain but sera alors de faciliter l'administration du système : le logiciel linuxconf a beau régler partiellement cela, il est loin de proposer à l'utilisateur débutant un outil exhaustif d'administration système. Si le système COAS de la société Caldera tient ses promesses, il pourrait servir de base à une solution complète d'administration. Malheureusement, la société Caldera n'a pas pu allouer des ressources suffisantes pour que le développement du projet COAS soit mené à terme, et d'autres participants ont abandonné le projet, démotivés par une progression trop lente, voire inexistante.

La pléthore de distributeurs de GNU/Linux semble subir un écrémage, dont la société Red Hat sortira comme vainqueur annoncé, talonnée par la société Caldera. La société Red Hat a montré jusqu'à présent un solide attachement au concept de l'open source, mais l'avènement d'un nouveau président et les rumeurs d'une offre publique d'achat (OPA) pourraient être le signe d'un affaiblissement de cet attachement, surtout si des concurrents comme la société Caldera, qui ont manifesté bien moins de marques d'intérêt dans l'open source, entament les marchés de Red Hat. Si l'attachement des distributions commerciales de GNU/Linux au modèle de l'open source devait par trop s'affaiblir, on verrait vraisemblablement se mettre en place des efforts pour les remplacer par des distributions entièrement open source, telles que Debian GNU/Linux, plus ciblées vers les marchés commerciaux que cela n'a été le cas de la distribution Debian.

Malgré tous ces défis, je prédis que l'open source remportera la victoire. Le système GNU/Linux est devenu le système de tests des étudiants en informatique, et ces derniers introduiront ces systèmes libres dans leur entreprise, quand ils auront obtenu leur diplôme. Les laboratoires de recherche ont adopté le modèle de l'open source car le partage de l'information est essentiel dans la méthode scientifique, et l'open source permet de partager facilement le logiciel. Les entreprises adoptent elles aussi le modèle de l'open source car il permet à des groupes de sociétés de collaborer pour résoudre un problème sans craindre une poursuite en justice pour situation de monopole et à cause du gain apporté à leurs logiciels par les contributions libres des programmeurs du grand public. Certaines grandes sociétés ont adopté l'open source en tant que stratégie pour combattre la société Microsoft et s'assurer qu'aucun autre Microsoft ne dominera jamais plus l'industrie de l'informatique. Mais c'est dans le passé qu'il faut chercher l'indication la plus fiable de l'avenir de l'open source : en à peine quelques années, on est passé de presque rien à un solide fonds de logiciels qui résolvent de nombreux problèmes différents, et on est en passe d'atteindre le million d'utilisateurs. Nous n'avons aucune raison de réduire la voilure maintenant.

Notes

[1]	N.d.T. : célèbre anthropologue américaine.
[2]	N.d.T. : matériel dont les spécifications sont ouvertes
[3]	N.d.T. : en anglais, le mot « free» signifie à la fois « libre » et « gratuit », alors que le mot « open » signifie « ouvert ». Consulter les essais de Richard Stallman et d'Eric Raymond pour obtenir plus d'informations à ce sujet.
[4]	N.d.T. : la première version stable en a été annoncée en février 1999.
[5]	N.d.T. : une version en français est disponible.
[6]	Le strict équivalent de la notion de domaine public, dans l'acception américaine de public domain, n'existe pas en France où la propriété intellectuelle est inaliénable.