La popularité de GitHub crée des attentes sur ce qu'est un logiciel « open source » (comme disent les jeunes) ou « libre » (comme disent les vrais). Il s'agit d'un dépôt de code avec une licence, une page de présentation (souvent nommée README), un endroit où remonter des problèmes (les issues), un autre où proposer corrections et évolutions (les pull requests) et, parfois, d'autres aspects : un espace de discussion, des actions lancées à chaque changement, un lien vers le site web officiel, etc.

Cette interface devenue familière réunit en une seule expérience deux aspects distincts du logiciel : le produit et le projet.

Vu comme un produit, un logiciel libre c'est :

• un code source ;
• les éventuelles versions compilées du programme ;
• les droits qui encadrent l'utilisation du programme.

Les éléments du logiciel vu comme projet sont plus nombreux et plus variés :

• un site Web ;
• un logo ;
• des tests ;
• un outil de suivi de bogues ;
• des espaces de discussions ;
• des espaces de gestion de tâches ;
• un moyen de soumettre des correctifs ;
• des services proposés par l'entité juridique qui porte le projet ;
• des outils d'intégration et/ou de déploiement continus ;
• des conventions que s'engagent à respecter les contributeurs
• etc.

La plupart des éléments de cette liste visent le produit : les outils de suivi de bogues, de gestion des contributions, les tests, les outils d'intégration continue, les conventions de nommage des versions, de style de programmation, les pratiques de sécurité, la possible obligation de signer un Developer Certificate of Origin, les règles de cession de droits, etc.

D'autres visent la communauté : le site Web, le logo, les espaces de discussion, les services proposés, etc. Notons au passage que cette « communauté » est une notion floue : vue du produit, elle est l'ensemble des personnes qui contribuent avec des idées ou du code ; vue du projet, elle inclut toute personne donnant de la valeur au produit, donc tout utilisateur potentiel.

La liste des éléments définissant le logiciel comme projet est de toutes façons ouverte car les exigences des uns et des autres à l'égard du produit et du projet évoluent. Gardons juste en tête ce contraste : ce qui définit le produit est défini et stable, ce qui définit le projet est indéfini et évolutif.

Quid de la documentation ?

À strictement parler, elle ne semble pas indispensable à l'exercice des libertés octroyées aux utilisateurs par un logiciel libre. Sans documentation, je peux exécuter le programme, l'étudier, le modifier, en distribuer des versions modifiées. Mais la définition des « sources » varie selon les licences : les licences GNU ne considèrent que le code source (la « forme préférée » pour modifier un programme) tandis que la licence Apache 2.0 inclut la « documentation et les fichiers de configuration ».

Quid des versions passées du code source ?

GitHub nous a habitué à obtenir l'historique Git des codes sources, nous avons donc tendance à penser que cet historique est partie intégrante du produit. Sauf que là encore, cet historique n'est pas indispensable à l'exercice des quatre libertés. Nous pouvons aussi argumenter en disant qu'un code source historicisé est la « forme préférable » sous laquelle il doit se présenter pour qu'un utilisateur puisse le modifier : mais c'est laisser parler nos habitudes. Nous pourrions enfin affirmer que, l'historique étant couvert par la licence au même titre que la dernière version du code, il fait bien partie du « produit », au moins au niveau des droits : mais c'est oublier que les droits peuvent couvrir des aspects relevant uniquement du logiciel-projet (les contenus d'un site web, etc.)

Coquille en soi, comme dirait Ponge, ces deux points délicats soulignent a contrario l'intérêt de la distinction proposée.

Cette distinction permet d'abord de décrire une tension inhérente à tout logiciel libre : d'un côté les coûts de distribution du produit sont quasi-nuls, mais de l'autre, l'énergie à dépenser pour maintenir le projet est élevée. Lorsque le nombre d'utilisateurs augmente, la valeur du produit augmente aussi, de même que la charge qui pèse sur le projet. C'est un peu comme l'amour et l'attention : le premier se multiplie facilement, mais le deuxième ne peut que se diviser.

C'est d'ailleurs cette tension qu'on trouve illustrée dans l'opposition entre les deux sens de fork. Dans le sens technique, forker un code source ne coûte rien. Dans le sens humain, forker un projet demande beaucoup d'effort : il faut recréer la structure porteuse, à la fois techniquement (hébergement du code, site web, etc.), juridiquement (éventuelle structure pour les droits, etc.) et humainement (attirer les utilisateurs et les contributeurs vers le projet forké.)

Cette distinction permet aussi de mieux poser certains problèmes, comme celui de la sécurité. Vérifier qu'un logiciel est sécurisé, c'est à la fois tester des propriétés observables du produit (pas de faille, pas de backdoor, etc.) et s'assurer que les contributeurs adhèrent aux bonnes pratiques de sécurité et les mettent en oeuvre (il ne suffit pas d'un fichier SECURITY.md dans le dépôt.)

De la façon dont j'ai présenté les choses, les libertés défendue par le mouvement du logiciel libre sont entièrement du côté du produit, et la façon dont celui-ci résulte du projet n'importe pas. Or, on entend parfois des objections de ce genre :

• « Un logiciel libre qui n'est pas accessible n'est pas vraiment libre. »
• « Un logiciel libre qui n'est pas déployable avec Docker n'est pas vraiment libre. »
• « Un logiciel libre qui n'accepte pas de contributions n'est pas vraiment libre. »
• « Un logiciel libre où la communication se fait via Slack n'est pas vraiment libre. »

Les deux premières portent sur le produit : or la liberté d'un logiciel ne dépend pas de ses propriétés techniques, mais des droits accordés à ses utilisateurs. Les deux autres objections portent sur le projet : une réponse serait alors de dire que la liberté du logiciel ne dépend pas des choix faits au niveau du projet…

Mais j'entends votre radar moral qui frémit, car notre petit coeur militant a envie que le libre soit autant dans le produit que dans le projet. Que faire ?

Côté morale, il y a les principes et les valeurs. Les principes sont des règles que nous nous donnons pour les suivre ; les valeurs expriment ce qui nous tient à coeur. Les deux guident notre action.

Un logiciel libre est un produit qui suit un principe, celui d'octroyer aux utilisateurs les quatre libertés. Il est porté par un projet ayant des valeurs, dont voici des exemples : l'importance de ne pas utiliser des plateformes dont le code source n'est pas libre pour publier un code source libre, celle d'utiliser des outils libres pour communiquer, de produire un logiciel accessible et bien documenté, d'être à l'état de l'art technique, d'être inclusif dans les contributions recherchées, d'avoir des règles pour prendre des décisions collectivement, de contribuer à la paix dans le monde, etc.

Notons que les valeurs peuvent être explicites ou implicites : une valeur non dite de la plupart des projets libres, c'est que le produit qui en résulte est super cool et important. Notons aussi que certaines valeurs peuvent être l'expression de principes qui sont soit en lien avec le mouvement du libre (comme celui de ne pas utiliser d'outils propriétaires pour communiquer) soit sans rapport (comme un principe qui serait de ne pas utiliser de services en ligne trop consommateurs d'énergie.)

Là encore, la distinction entre produit et projet est bien utile : elle aide à comprendre comment s'articulent le respect des principes du libre au niveau du produit et la place qu'ont les valeurs de ceux qui portent le projet. Cette articulation n'est pas toujours facile : si l'une des valeurs du projet est d'être économiquement rentable, il peut être tentant de rogner sur la liberté du produit ; si une autre valeur est d'attirer des contributeurs jeunes, utiliser Discord sera plus efficace qu'IRC.

Retenons ceci : les logiciels libres, en tant que produits, suivent un principe clair qui n'admet pas d'écart ; mais en tant que projets, ils sont animés par des valeurs qui contraignent souvent à des compromis.

Pour atteindre ses objectifs, le mouvement du libre a d'abord besoin… de logiciels libres, donc de produits comme le système GNU/Linux. Mais si le but de ce mouvement est de produire une société dans laquelle le plus grand nombre d'individus est réellement libre d'utiliser des programmes informatiques comme il l'entend, alors les produits ne suffisent pas : il faut aussi éduquer à l'informatique et à la culture numérique, développer une attitude morale à l'égard des services numériques courants, sensibiliser à l'importance de l'accessibilité, de l'inclusivité, etc. Et il faut, idéalement, des projets libres dont les valeurs sont alignées avec cet objectif plus large d'émancipation.

J'invite les lecteurs à se plonger dans les travaux de Nadia Asparouhova sur l'open source. La lecture de son livre Working in Public: The Making and Maintenance of Open Source Software m'a aidé à mieux appréhender l'importance de cette distinction entre produit et projet pour les logiciels libres.

Merci à @louisvgn pour ses remarques stimulantes sur une première version de cet article.