Open source : liberté, responsabilité et choix

Le code source est la forme lisible par des personnes d'un programme, et c'est cet accès qui sépare le logiciel que l'on peut seulement utiliser de celui que l'on peut examiner. Sans la forme lisible, vous pouvez observer le comportement d'un programme et demander davantage à qui l'a écrit ; avec elle, vous — ou la personne que vous mandatez — pouvez voir pourquoi il se comporte ainsi, ce qu'il envoie sur le réseau, où se situe un défaut et où irait une modification.

L'open source ne décrit pas la manière dont le logiciel est fabriqué, et ne promet pas non plus que le code se trouve visible par hasard : c'est un ensemble de permissions attachées au logiciel par sa licence, et il existe une définition écrite et largement reconnue de ce que ces permissions doivent contenir. L'Open Source Initiative la tient à jour et décide sur cette base quelles licences comptent comme open source : elle exige notamment la redistribution libre, la disponibilité du code sous la forme réellement utile pour le modifier, le droit de créer et de distribuer des versions modifiées, aucune restriction sur qui utilise le logiciel ni pour quoi, et aucune dépendance à une technologie ou à une interface particulière. D'où une distinction utile en pratique : une licence qui permet de lire le code mais interdit l'usage commercial ou le partage des modifications est « à code disponible », pas open source.

La tradition du logiciel libre formule la même idée plus concrètement, en quatre libertés : exécuter le programme pour n'importe quel usage, étudier son fonctionnement et le modifier, redistribuer des copies, et distribuer des versions modifiées. Une licence accorde ces libertés et peut y ajouter des conditions, le plus souvent la conservation des mentions ou l'application de la même licence aux versions distribuées.

Deux formes dominent. Les licences permissives, comme l'Apache 2.0 utilisée ici, posent peu de conditions : elles permettent l'usage, la modification et la redistribution en conservant les mentions, et incluent une concession de brevets explicite. Les licences copyleft ajoutent une condition destinée à maintenir le logiciel ouvert pour celles et ceux qui le reçoivent : qui distribue une version doit le faire sous la même licence. La famille la plus connue est la GNU General Public License. Le copyleft n'est pas identique partout et les différences comptent : le déclencheur est habituellement la redistribution, et pour certaines licences aussi l'usage à travers un réseau — la GNU Affero General Public License exige alors que les utilisateurs puissent obtenir le code de la version effectivement exécutée. C'est une particularité de ces licences, pas une règle générale de l'open source. Ce qu'aucune licence open source n'impose, en revanche, c'est de publier votre propre travail privé : une modification que vous gardez pour vous, sans la distribuer, ne déclenche aucune de ces obligations.

Partager du logiciel est presque aussi ancien que l'écrire. Dans les premières décennies de l'informatique, une bonne part des programmes était écrite par celles et ceux qui les utilisaient, les logiciels circulaient entre utilisateurs et les centres de recherche tenaient l'échange de code pour normal. Cette pratique s'est effacée lorsque le logiciel a commencé à être vendu séparément du matériel : dans les années 1980, l'immense majorité des logiciels était propriétaire, et le code cessait d'arriver à l'acheteur.

La réponse est venue du projet GNU. Richard Stallman l'a annoncé en septembre 1983, le travail a commencé en janvier 1984 et la Free Software Foundation a été créée en 1985. La GNU General Public License est née d'une raison précise : le logiciel ne devait pas être placé dans le domaine public, où une version ultérieure pourrait redevenir propriétaire, mais rester libre pour toutes celles et tous ceux qui le reçoivent. En 1991, Linus Torvalds a entrepris un noyau de type Unix qui, avec le système GNU déjà presque complet, a donné un système d'exploitation librement utilisable — et le développement se faisait en public, les propositions étant envoyées et discutées à la vue de tous.

Le même schéma se retrouve ailleurs. Lorsque le développement du serveur NCSA HTTPd s'est enlisé en 1994, plusieurs administrateurs ont coordonné leurs correctifs, formé le groupe Apache en février 1995 et publié la première version en avril de la même année ; en moins d'un an, leur serveur était le plus utilisé au monde, et le projet a ensuite rejoint l'Apache Software Foundation, qui offre depuis 1999 un cadre à but non lucratif à ce type d'initiatives.

Le terme « open source » est né le 3 février 1998 à Palo Alto, peu après l'annonce par Netscape, le 22 janvier, de la libération du code de son navigateur ; le code a été publié le 31 mars de la même année, et c'est de là qu'est né le projet Mozilla. La même année, l'Open Source Initiative a été constituée, sa définition s'appuyant sur les directives Debian qui existaient depuis 1997. Pourquoi un nouveau nom ? Parce que le développement ouvert présente des avantages pratiques qu'une entreprise peu sensible aux débats éthiques comprend aussi, et qu'en 1998 il fallait dire exactement cela.

Logiciel libre et open source désignent en pratique presque la même chose : les mêmes licences, les mêmes programmes, la même manière de partager. La différence tient à l'accent. La tradition du logiciel libre, avec la Free Software Foundation, place au centre la liberté de qui utilise le programme et la justifie sur le plan éthique ; le courant open source insiste sur les avantages pratiques. Ni l'une ni l'autre ne change ce que vous pouvez faire du programme : cela dépend de la licence qui l'accompagne, pas de l'étiquette.

Et il vaut la peine de séparer deux choses que l'anglais confond en un seul mot : ici, libre renvoie à la liberté, pas au prix. Un programme peut être gratuit sans être libre — si sa licence interdit de le partager ou de le modifier — et il peut être libre tout en coûtant de l'argent, car développer, exploiter et maintenir du logiciel demande toujours du travail. « Logiciel gratuit » n'explique donc rien : ce qui compte, c'est ce que sa licence autorise.

Les permissions ont des conséquences concrètes : vous pouvez examiner le logiciel, l'adapter à votre cas — structure de page, flux, traduction —, l'utiliser commercialement y compris dans quelque chose que vous ne publierez jamais, poursuivre avec lui si son auteur perd l'intérêt, et partir sans dépendre d'un compte ni de la générosité d'un fournisseur. En contrepartie, une licence donne des capacités, pas des moyens : quelqu'un doit configurer, déployer, maintenir et comprendre ce qui s'exécute.

Deux précisions s'imposent. La liberté de modifier est celle de modifier votre copie et de distribuer votre propre version ; ce n'est pas un droit à ce que votre modification soit reprise dans le projet dont vous avez pris le logiciel. Cela relève de celles et ceux qui le maintiennent, selon ce qui correspond à son objet et selon les règles qu'il s'est données. Et gratuit à l'usage ne signifie pas gratuit à produire : quelqu'un consacre du temps à la documentation, aux tests, aux versions et à la compatibilité — c'est pourquoi ce projet indique où peut aider qui le souhaite. Personne n'y est tenu : utiliser Foundation sans rien apporter n'est pas une faute.

Foundation est publiée sous Apache 2.0 parce que son objet est d'être une base réutilisable pour des sites d'information d'entreprise, et que cet objet serait contredit par une licence permettant de l'adopter pour ensuite limiter ce qu'il est possible d'en faire. Apache 2.0 autorise l'usage indépendant, privé et commercial, comporte une concession de brevets et ne transfère aucune propriété exclusive : Foundation reste ouvert pour tout le monde. Les éléments tiers conservent leur propre licence et leur attribution, et la licence n'accorde aucun droit sur le nom ni les marques de Provelopment.

L'essentiel n'est pas la promesse, mais la construction : que les contenus, la configuration et l'identité vivent sous forme de fichiers dans votre dépôt, que les adaptations ne se fassent pas dans le cœur de la plateforme, que les services externes se tiennent derrière des interfaces interchangeables et que la plateforme soit documentée publiquement. Cela ne rend pas l'indépendance automatique, mais la rend exerçable — et une indépendance que l'on ne peut pas exercer n'en est pas une. Si vous souhaitez de l'aide, Provelopment peut en proposer comme prestation, jamais comme condition.

Les projets ouverts commencent souvent par un problème personnel : quelqu'un écrit la solution dont il a besoin pour son propre travail et découvre que d'autres rencontrent le même problème. Les raisons de continuer sont diverses — apprendre, rendre son travail utile, la reconnaissance entre pairs — et, dans les organisations, s'y ajoutent des motifs plus prosaïques : une bibliothèque utilisée par beaucoup se maintient mieux à plusieurs que réécrite dans chaque entreprise, et dépendre d'un seul fournisseur pour une brique essentielle est un risque.

La première version du code est la petite part du travail. Le reste consiste à lire les signalements, répondre aux questions, mettre à jour les dépendances, réagir aux problèmes de sécurité, tenir la documentation, préparer les versions et vérifier qu'une mise à jour ne casse pas ce qui fonctionnait. Ce travail existe même lorsque le logiciel ne se paie pas, et il repose souvent sur très peu de personnes, parfois une seule : si cette personne s'arrête, le projet s'arrête. D'où deux affirmations honnêtes. Nul ne peut garantir qu'un projet continuera sous sa forme actuelle : les licences assurent la continuité juridique, pas l'entretien. Et le soutien le plus efficace est celui qui achète du temps : un soutien mensuel régulier permet à quelqu'un de consacrer au projet une part fixe de son temps de travail plutôt que ce qui reste entre deux tâches.

Foundation est proposé, comme tout projet ouvert, sans garantie : aucune licence n'oblige à corriger un défaut précis, à répondre à une question ou à fournir un support commercial. Ce que vous y gagnez, c'est la capacité d'agir par vous-même : réparer, confier le travail à quelqu'un d'autre ou remplacer ce qui ne convient pas ; choisir la version, décider quand mettre à jour et vérifier les sauvegardes vous revient. Participer n'exige pas d'être développeur : un signalement clair — ce que vous attendiez, ce qui s'est produit, comment le reproduire et avec quelle version — fait gagner du temps à qui le lit ; une proposition qui décrit le problème aide davantage qu'une solution fermée ; améliorer ou traduire la documentation profite directement à la personne suivante ; et répondre publiquement aux autres répartit l'effort. Le soutien financier est une autre voie, facultative, et n'équivaut pas à l'achat d'une prestation.