Chapitre 8.1Open source et licences

En informatique, un logiciel est d'abord du code source, des fichiers texte écrits par des développeurs dans un langage de programmation. Ce code est ensuite transformé en programme exécutable par la machine, comme on l'a vu dans le chapitre Le code.

La question fondamentale est de savoir qui a le droit de lire, de modifier et de redistribuer ce code. C'est elle qui sépare le monde du logiciel en deux grandes familles, et elle a des conséquences très concrètes sur ton produit, y compris juridiques.

Free as in freedom, not as in free beer.

Logiciel propriétaire vs open source

Un logiciel propriétaire garde son code source secret. Tu achètes le droit d'utiliser le programme, mais tu ne peux ni voir comment il fonctionne, ni le modifier, ni le redistribuer. Windows, Photoshop et Microsoft Office sont des logiciels propriétaires.

Un logiciel open source rend son code source accessible à tous. N'importe qui peut le lire, le modifier et le redistribuer, dans les conditions définies par sa licence. Linux, Firefox, VLC et WordPress sont des logiciels open source.

Attention, open source ne veut pas dire gratuit. On parle de liberté d'accès au code et pas de prix. Certains logiciels open source sont vendus avec un support payant ou une édition entreprise, et beaucoup de logiciels propriétaires sont distribués gratuitement, comme Chrome ou Instagram.

Un peu d'histoire

Dans les années 1970, le code s'échangeait librement entre chercheurs et ingénieurs. Le logiciel était un accessoire, on vendait la machine. C'est dans les années 1980 que l'industrie bascule vers le logiciel fermé et payant.

En réaction, Richard Stallman lance en 1983 le projet GNU, dont l'objectif est de construire un système d'exploitation entièrement libre, puis fonde la Free Software Foundation en 1985. Il formalise quatre libertés qui définissent un logiciel libre.

• Exécuter le programme pour n'importe quel usage.
• Étudier son fonctionnement et l'adapter à ses besoins, ce qui suppose d'avoir accès au code source.
• Redistribuer des copies pour aider les autres.
• Distribuer ses versions modifiées, pour que toute la communauté en profite.

Il manquait un noyau à ce système. En 1991, un étudiant finlandais nommé Linus Torvalds publie le sien, Linux, et l'assemblage des deux donne les systèmes que font tourner aujourd'hui la quasi-totalité des serveurs de la planète.

En 1998, Netscape ouvre le code de son navigateur, ce qui donnera naissance à Mozilla puis à Firefox. Dans la foulée, un groupe crée l'Open Source Initiative et popularise le terme "open source", jugé plus rassurant pour les entreprises que le mot "libre", trop connoté militant en anglais.

Logiciel libre et open source recouvrent presque le même périmètre de licences, mais pas le même discours. Le logiciel libre défend une position éthique sur les libertés de l'utilisateur, l'open source met en avant un modèle de développement plus efficace. Beaucoup écrivent "FLOSS" pour parler des deux sans trancher.

Pourquoi ouvrir son code ?

À première vue, donner son code semble contre-productif. Pourquoi une entreprise ferait-elle ça ?

• La qualité : quand beaucoup de développeurs peuvent lire et corriger le code, les bugs sont détectés plus vite et les améliorations viennent de partout. Linux, avec ses milliers de contributeurs, est l'un des systèmes les plus robustes jamais écrits.
• La confiance : un logiciel dont le code est visible inspire plus confiance qu'une boîte noire. On peut vérifier qu'il ne contient pas de porte dérobée ni de collecte de données cachée.
• L'écosystème : un projet ouvert attire des contributeurs, des utilisateurs et des entreprises qui construisent dessus. Ça crée un cercle vertueux qui renforce le projet et la réputation de ses créateurs.
• Le recrutement : un projet visible et respecté est un formidable argument pour attirer des développeurs, qui peuvent juger sur pièce avant de postuler.
• Le modèle économique : beaucoup d'entreprises donnent le logiciel et vendent le service autour, support technique, hébergement clé en main, fonctionnalités avancées réservées aux clients. C'est le modèle de Red Hat, de GitLab ou de Grafana.

Les licences

Ouvrir son code ne veut pas dire qu'on abandonne tout contrôle. La licence est le document juridique qui définit ce que les autres ont le droit de faire avec le code. Sans licence explicite, un code publié sur GitHub reste protégé par le droit d'auteur et personne n'a légalement le droit de le réutiliser, ce que beaucoup ignorent.

Il existe des dizaines de licences, mais les plus courantes se répartissent en deux grandes familles.

Les licences permissives

Elles donnent une liberté quasi totale. Tu peux utiliser le code, le modifier, l'intégrer dans un logiciel propriétaire et le revendre. La seule obligation est généralement de conserver la mention de l'auteur original et le texte de la licence.

Les plus connues sont MIT, BSD et Apache 2.0. Cette dernière ajoute une clause sur les brevets, qui protège l'utilisateur contre une attaque en contrefaçon venant des contributeurs eux-mêmes, ce qui explique qu'elle soit souvent préférée par les grandes entreprises. Cette famille permissive est le choix de la majorité des projets modernes, React étant sous MIT, Kubernetes et TensorFlow sous Apache 2.0.

Les licences copyleft

Elles imposent une contrainte forte. Si tu modifies le code et que tu distribues ta version, tu dois publier tes modifications sous la même licence. C'est le principe du partage à l'identique, le code libre reste libre et ne peut pas être refermé.

La plus connue est la GPL (GNU General Public License), dont c'est la version 2 qui couvre le noyau Linux. Si un fabricant de box internet embarque un Linux modifié dans son boîtier, il doit fournir ses modifications à ses clients. Plusieurs procès ont confirmé que ces licences sont bien opposables devant un tribunal.

Il existe des variantes plus ou moins strictes.

• LGPL : copyleft affaibli. Tu peux utiliser la bibliothèque dans un logiciel propriétaire, seules tes modifications de la bibliothèque elle-même doivent être publiées.
• GPL : copyleft fort. Tout programme qui intègre du code GPL et qui est distribué doit lui-même être publié sous GPL.
• AGPL : encore plus stricte. Elle comble le "trou du SaaS", puisqu'elle considère que mettre le logiciel à disposition via un site web équivaut à le distribuer. Beaucoup de grandes entreprises interdisent purement et simplement l'AGPL dans leurs produits.

Cette contrainte n'est pas théorique. Intégrer une bibliothèque GPL dans ton produit propriétaire peut t'obliger à ouvrir le code de ce produit dès lors que tu le distribues, et l'AGPL déclenche la même obligation même sans distribution, à partir du moment où des utilisateurs s'en servent à travers le réseau. C'est pour cette raison que beaucoup d'entreprises tiennent un inventaire des licences de leurs dépendances, parfois automatisé dans la chaîne d'intégration continue.

L'open source au quotidien

Aujourd'hui, l'open source n'est plus une niche idéaliste, c'est le socle de l'industrie du logiciel. Les langages de programmation les plus populaires, Python, JavaScript, Go, sont open source. Les frameworks utilisés par les développeurs du monde entier aussi, tout comme les bases de données, les outils de conteneurisation et une bonne partie de ce qui fait tourner le cloud.

Même les géants du logiciel propriétaire y contribuent massivement. Microsoft a racheté GitHub, la plus grande plateforme d'hébergement de projets open source, publie le code de VS Code et est devenu l'un des plus gros contributeurs de la planète, ce qui aurait paru absurde vingt ans plus tôt.

Le problème de la maintenance

L'open source a un défaut structurel, la maintenance. Beaucoup de composants critiques, utilisés par des millions d'applications, sont entretenus par une poignée de bénévoles sur leur temps libre, sans budget et sans reconnaissance. Quand l'un d'eux s'arrête, c'est tout un pan de l'infrastructure mondiale qui se retrouve sans gardien.

Les exemples ne manquent pas. En 2016, un développeur retire de npm un minuscule module de onze lignes et casse au passage les builds de milliers de projets. En 2021, la faille Log4Shell touche Log4j, une bibliothèque de journalisation présente presque partout dans le monde Java, maintenue par une équipe de bénévoles. En 2024, une porte dérobée est découverte de justesse dans l'utilitaire de compression xz, après qu'un contributeur patient a gagné la confiance d'un mainteneur épuisé.

Des initiatives de financement existent, sponsoring via GitHub, fondations, contrats de support, et la réglementation européenne commence à imposer aux éditeurs une responsabilité sur les composants qu'ils embarquent. Le sujet est loin d'être réglé.

Le retour des licences restrictives

Une tension traverse le secteur depuis quelques années. Des entreprises qui ont bâti un logiciel très populaire voient des fournisseurs cloud le revendre en service managé sans rien reverser. Plusieurs ont réagi en abandonnant leur licence open source pour une licence "source disponible", où le code reste lisible mais où la revente en service est interdite.

MongoDB, Elastic, HashiCorp et Redis ont tous fait ce type de bascule. Plusieurs fois, la communauté a répliqué en créant un fork, c'est-à-dire une copie du projet reprise sous la dernière version réellement libre. Elasticsearch a ainsi donné OpenSearch, Terraform a donné OpenTofu et Redis a donné Valkey. Elastic et Redis sont même revenus en arrière depuis, en proposant à nouveau une licence libre à côté de la leur, preuve que l'équilibre est difficile à trouver.

Si tu travailles côté produit, retiens surtout deux réflexes. Vérifie sous quelle licence sont les briques que ton équipe intègre, et méfie-toi de l'étiquette "open source" employée comme argument marketing par un éditeur dont la licence interdit en réalité l'essentiel des usages.