Histoire des logiciels open source et de leurs licences

Ce qu’est un logiciel open source et d’où il vient

L’histoire des logiciels open source est principalement celle de leurs licences, car une licence est le seul élément qui détermine ce que vous pouvez faire avec du code écrit par quelqu’un d’autre. Le code était partagé ouvertement bien avant que quiconque ne mette ces licences par écrit. Il a cessé d’être partagé lorsqu’il est devenu un produit, et les licences ont été rédigées pour que le partage puisse être défendu devant un tribunal.

C’est la version courte. La version longue est importante, car les logiciels que vous exécutez aujourd’hui sur un serveur portent encore les traces de ces décisions. Certaines ont été prises en 1983. D’autres l’ont été l’année dernière, et c’est pourquoi quelques applications de nos guides d’auto-hébergement existent désormais en deux versions portant des noms différents.

Les logiciels étaient partagés avant d’être vendus

Dans les années 1950 et 1960, les logiciels étaient fournis avec la machine. IBM distribuait le code source avec ses systèmes, et des groupes d’utilisateurs comme SHARE, fondé en 1955, s’échangeaient des programmes sur bande. Deux évolutions ont mis fin à cette pratique. En 1969, IBM a annoncé que les logiciels seraient facturés séparément du matériel, ce qui a créé un marché autonome pour les logiciels. Puis le droit a suivi. Le Computer Software Copyright Act de 1980 a confirmé que les programmes sont des œuvres protégées par le droit d’auteur aux États-Unis. Après 1980, le code que vous n’aviez pas écrit était fermé par défaut. Son partage nécessitait donc l’autorisation écrite de son auteur.

Le Homebrew Computer Club et la lettre ouverte aux amateurs

Le Homebrew Computer Club a tenu sa première réunion en mars 1975, dans un garage de Menlo Park, en Californie. Les membres apportaient du matériel et des bandes perforées, et la copie faisait partie de la réunion. Altair BASIC, écrit par Bill Gates et Paul Allen, circulait dans la salle sur des bandes copiées. En février 1976, Gates répondit dans la newsletter du club avec « Une lettre ouverte aux amateurs ».

Comme la plupart des amateurs doivent le savoir, la plupart d’entre vous volent vos logiciels.

Il écrivait que moins d’un propriétaire d’Altair sur dix avait payé BASIC et que le temps machine utilisé pour l’écrire valait plus de 40,000 dollars. Toute l’argumentation moderne figure déjà dans cette lettre. Copier un logiciel ne coûte rien et aide tous ceux qui le copient. Son écriture a tout de même coûté une année de la vie de quelqu’un. Chaque licence décrite ci-dessous tente de répondre simultanément à ces deux faits.

GNU en 1983, et la GPL comme invention juridique

Richard Stallman a annoncé GNU en septembre 1983 sur Usenet, le réseau de newsgroups utilisé avant le Web. GNU signifie « GNU’s Not Unix ». Le projet consistait à créer un système complet compatible avec Unix, que chacun pourrait copier et modifier.

Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.

La Free Software Foundation (FSF) a été créée en 1985. Sa définition du logiciel libre énonce quatre libertés, numérotées à partir de zéro : exécuter le programme pour n’importe quel usage, l’étudier et le modifier, redistribuer des copies et distribuer ses versions modifiées. La liberté 1 exige le code source, car personne ne peut étudier un binaire de manière pratique. Ici, « free » désigne la liberté, pas le prix. La formule utilisée par la FSF est « free as in free speech, not free beer ».

Le manifeste n’était pas l’invention. La licence, si. La GNU General Public License (GPL) utilise le droit d’auteur pour imposer le partage, au lieu de l’empêcher. Vous bénéficiez des quatre libertés à une condition : toute personne à qui vous transmettez le logiciel doit en bénéficier aussi, avec le code source. Stallman a appelé ce mécanisme le copyleft. Il a d’abord été distribué avec GNU Emacs en 1985, puis est devenu la GPL version 1 en 1989 et la version 2 en juin 1991.

La GPL fonctionne parce qu’elle s’appuie sur le droit d’auteur, au lieu de s’y opposer. Sans licence, vous n’avez aucun droit de distribuer le code de quelqu’un d’autre. La GPL vous accorde ce droit et y associe des conditions. Ainsi, un fabricant qui distribue du code GPL modifié dans un routeur et refuse de fournir le code source ne rompt pas une promesse. Il enfreint le droit d’auteur, et le titulaire des droits peut saisir la justice. C’est ce qui rend les poursuites possibles, depuis les affaires gpl-violations.org de Harald Welte dans les années 2000 jusqu’à l’action en justice de la Software Freedom Conservancy contre Vizio, engagée en 2021, qui soutient qu’une personne ayant acheté le téléviseur peut elle aussi exiger le code source.

Linux a terminé le système

En 1991, le projet GNU disposait du compilateur, de la bibliothèque C, du shell et de la plupart des outils. Il n’avait pas de kernel fonctionnel, car le kernel du projet GNU, Hurd, avait pris beaucoup plus de temps que prévu. En août 1991, un étudiant d’Helsinki a publié ce message sur le newsgroup comp.os.minix :

Je développe un système d’exploitation (libre), uniquement pour le plaisir, qui ne sera ni grand ni professionnel comme GNU, pour des clones AT 386(486).

Linux 0.01 est sorti en septembre 1991 sous une licence écrite par Linus Torvalds lui-même, qui en interdisait la vente. Il l’a remplacée par la GPLv2 au début de 1992 et a déclaré depuis que c’était l’une de ses meilleures décisions. Cette licence a sécurisé les contributions des entreprises : une entreprise pouvait affecter des ingénieurs au kernel en sachant qu’un concurrent ne pourrait pas rendre ces améliorations propriétaires.

Un Unix libre existait déjà à Berkeley. Si Linux, et non BSD (Berkeley Software Distribution), est devenu l’Unix libre par défaut, c’est en partie à cause d’un procès. Unix System Laboratories a poursuivi Berkeley Software Design en 1992, et l’affaire a duré jusqu’au début de 1994. Pendant ces deux années, les systèmes BSD comportaient un risque juridique, contrairement à Linux, et c’est à ce moment que les utilisateurs sont arrivés. La FSF demande d’appeler le système combiné GNU/Linux, car Linux est le kernel et que la plupart des outils qui l’entourent viennent de GNU. La plupart des gens disent Linux. Les deux noms désignent la même collection de logiciels.

1998 : le changement de nom vers l’open source et la scission qui ne s’est jamais résorbée

En janvier 1998, Netscape a annoncé qu’il publierait le code source de son navigateur. C’était la plus grande entreprise à prendre une telle décision jusque-là, et cela a mis en évidence un problème pratique. En anglais, l’expression « free software » se comprend comme « logiciel gratuit », et les dirigeants l’ont interprétée exactement ainsi. Un groupe s’est réuni à Palo Alto en février 1998 pour trouver un meilleur terme, et Christine Peterson a proposé « open source ». En quelques semaines, Eric Raymond et Bruce Perens ont créé l’Open Source Initiative (OSI). Elle a adopté l’Open Source Definition, adaptée des Debian Free Software Guidelines rédigées par Perens en 1997.

L’Open Source Definition comporte dix critères. Deux d’entre eux déterminent la plupart des débats actuels : le code source doit être disponible, et la licence ne doit pas limiter les utilisateurs autorisés à utiliser le programme ni les usages qu’ils peuvent en faire. Une licence qui indique « vous ne pouvez pas proposer ce logiciel comme service commercial » ne satisfait pas ce critère, même si elle autorise tous les autres usages. Retenez cette phrase. C’est la limite que franchissent les licences actuelles de type source-available.

La scission apparue en 1998 concerne les raisons, et non les licences acceptables. La position de la FSF est éthique : un utilisateur qui ne peut pas modifier le programme ne contrôle pas son propre ordinateur. La position de l’OSI, présentée aux entreprises par l’essai « The Cathedral and the Bazaar » de Raymond, est pratique : le développement ouvert produit de meilleurs logiciels, et une entreprise peut en tirer parti. La réponse de Stallman, « Why Open Source Misses the Point of Free Software », est toujours publiée sur gnu.org, et il n’a jamais accepté le nouveau terme. Perens, qui avait contribué à le créer, a démissionné du conseil d’administration de l’OSI en 1999, estimant que le mouvement s’était éloigné du logiciel libre.

Il faut être précis sur l’ampleur réduite de l’écart pratique. La liste des licences libres de la FSF et celle des licences approuvées par l’OSI concordent sur presque tout, notamment la GPL, MIT, Apache 2.0 et BSD. Les auteurs qui doivent exprimer les deux notions à la fois utilisent FOSS (free and open source software) ou FLOSS (free/libre and open source software).

Comment les entreprises ont appris à commercialiser le code

L’introduction en bourse de Red Hat en 1999 a montré que l’argent se trouvait dans le support et le packaging, et non dans la vente de copies. IBM a consacré 1 milliard de dollars à Linux en 2001. Le directeur général de Microsoft a qualifié Linux de « cancer » en 2001. La même entreprise a rejoint la Linux Foundation comme membre platinum en 2016, puis a racheté GitHub en 2018 pour 7,5 milliards de dollars en actions. IBM a racheté Red Hat en 2019 pour 34 milliards de dollars. Rien de tout cela ne correspondait à un changement d’avis sur les licences. C’était un changement concernant l’endroit où se trouve l’argent. Lorsqu’un système d’exploitation constitue un coût partagé, assurer soi-même sa maintenance revient cher, et chaque éditeur préfère se concurrencer sur la couche supérieure.

La propriété par une entreprise peut aussi produire l’effet inverse. Quand Oracle a racheté Sun en 2010, elle a récupéré MySQL et OpenOffice.org, et les deux communautés sont parties. MariaDB est issue de MySQL, et LibreOffice a été forké à partir d’OpenOffice.org en septembre 2010. Un fork est le seul véritable vote dont dispose une communauté d’utilisateurs, et c’est la licence qui rend ce vote possible.

Pourquoi certaines applications que vous auto-hébergez ont désormais des forks

À partir de 2018, plusieurs entreprises ont modifié les conditions de licence de logiciels qu’elles avaient déjà publiés. Le scénario était à chaque fois similaire. Une entreprise employait presque tous les développeurs, un fournisseur cloud beaucoup plus important vendait le même logiciel sous forme de service managé, et la petite entreprise estimait que la licence l’empêchait de rivaliser.

• MongoDB a adopté la Server Side Public License (SSPL) en octobre 2018. La SSPL indique que, si vous proposez le logiciel à des tiers sous forme de service, vous devez publier le code source de tout ce que vous utilisez pour fournir ce service. L’OSI ne l’a pas acceptée comme licence open source, et MongoDB a retiré sa proposition de l’examen en 2019.
• Redis a ajouté des restrictions d’utilisation à certains modules en 2018 et 2019, puis a placé le serveur principal sous des conditions duales de type source-available avec la version 7.4, en mars 2024. Un fork de la dernière version sous licence BSD est apparu quelques jours plus tard sous le nom de Valkey, au sein de la Linux Foundation, avec notamment le soutien d’Amazon, de Google et d’Oracle. En mai 2025, Redis a ajouté l’Affero General Public License version 3 (AGPLv3), approuvée par l’OSI, comme troisième option pour Redis 8.
• Elastic a retiré Elasticsearch et Kibana de la licence Apache 2.0 en janvier 2021, pour les placer sous des conditions duales SSPL et Elastic License. Amazon a créé le fork OpenSearch. Elastic a ajouté l’AGPLv3 comme troisième option en août 2024, et OpenSearch a été transféré à la Linux Foundation en septembre 2024 sous le nom d’OpenSearch Software Foundation.
• HashiCorp a placé Terraform et ses autres outils sous la Business Source License (BUSL) en août 2023. La BUSL n’est pas une licence open source pendant sa période d’application, car elle interdit l’utilisation en production par des concurrents. Chaque version est convertie en licence open source à une date fixe, quatre ans plus tard dans le cas de Terraform. OpenTofu a été créé comme fork en quelques semaines et relève désormais lui aussi de la Linux Foundation.

Les deux parties ont des arguments légitimes, et aucune n’agit de mauvaise foi. Une entreprise qui paie cinquante salaires pendant qu’un groupe beaucoup plus important revend son travail rencontre un problème que la bonne volonté ne suffit pas à résoudre. L’utilisateur qui a construit son infrastructure sur les conditions de la licence Apache 2.0 et s’est retrouvé du jour au lendemain soumis à de nouvelles conditions rencontre également un problème, et personne ne lui a demandé son avis auparavant. Observez ce qui s’est passé ensuite dans deux de ces cas. Une fois les forks établis, Elastic et Redis ont tous deux réintroduit un copyleft fort. Le copyleft répondait à la plainte initiale, car l’AGPLv3 oblige un fournisseur de services à publier les modifications qu’il exécute. En août 2026, les deux projets et les deux forks sont toujours actifs, ce qui correspond à l’objectif permis par ces licences.

Qui est autorisé à modifier une licence

Un projet ne peut changer de licence que si une seule partie contrôle les droits d’auteur sur l’ensemble du projet. Les entreprises obtiennent ce contrôle de l’une de deux façons. La cession des droits d’auteur transfère à l’entreprise la propriété de chaque contribution. Un contributor licence agreement (CLA) vous laisse propriétaire de votre contribution, mais accorde à l’entreprise des droits suffisamment larges pour modifier la licence de votre travail. Dans les deux cas, la signature se fait généralement en cliquant sur un lien publié par un bot lors de votre première pull request.

Linux n’a pas de CLA. Les contributions sont soumises à la GPLv2 avec un Developer Certificate of Origin, et les droits d’auteur sont répartis entre des milliers de personnes et d’entreprises. Personne ne peut modifier la licence de Linux, car personne ne pourrait réunir toutes ces signatures. La même protection s’applique à tout projet qui compte de nombreux titulaires indépendants des droits d’auteur. Elle est plus solide qu’une simple promesse, car elle repose sur le fait de savoir qui possède quoi.

La question à poser à propos d’un logiciel dont vous prévoyez de dépendre n’est donc pas de savoir s’il est open source aujourd’hui. Il faut savoir qui pourrait modifier sa licence et s’il pourrait le faire seul.

Ce qu’une fondation vous apporte réellement

Une fondation détient les actifs et fixe les règles de prise de décision. L’Apache Software Foundation, la Linux Foundation, la Cloud Native Computing Foundation qui en fait partie et la Software Freedom Conservancy remplissent chacune une version de ce rôle. Une fondation n’est pas neutre par magie. Les membres paient leur siège, et la plupart des personnes qui travaillent à temps plein sur un grand projet de fondation sont rémunérées par des entreprises membres. Ce que vous obtenez est plus limité, mais reste très précieux : la marque et le processus de release n’appartiennent pas à un seul éditeur. Aucune entreprise ne peut donc rendre le projet privé.

La marque est l’élément souvent oublié. Le code est couvert par une licence. Un nom est une marque, et une marque n’est pas couverte par la licence du code. Vous pouvez toujours forker le code. En général, vous ne pouvez pas conserver le nom. C’est pourquoi les forks mentionnés ici s’appellent Valkey, OpenSearch, OpenTofu et Forgejo.

Le problème des mainteneurs

Les infrastructures modernes reposent sur des projets gérés par un ou deux mainteneurs non rémunérés, et ce sont les défaillances qui le rendent visible. La faille Heartbleed dans OpenSSL, en 2014, a touché une bibliothèque qui transportait une grande partie du trafic web chiffré, tout en étant maintenue par une poignée de personnes disposant de presque aucun financement. Log4Shell, en décembre 2021, a fait converger la réponse aux incidents du monde entier vers une petite équipe de bénévoles du projet Apache Log4j.

La backdoor découverte dans XZ Utils en mars 2024 en est l’exemple le plus net, car l’attaque visait le mainteneur plutôt que le code. Un compte a consacré environ deux ans à apporter des contributions réellement utiles à une bibliothèque de compression utilisée par de nombreuses distributions Linux. D’autres comptes ont fait pression sur l’unique mainteneur, épuisé, pour qu’il accepte de l’aide. Le nouveau co-mainteneur a alors implanté une backdoor dans les archives de release, ciblant les systèmes où le daemon SSH (secure shell) est lié à liblzma. Un développeur l’a découverte en cherchant pourquoi les connexions prenaient environ une demi-seconde de plus que prévu. C’était dû à la chance, et toutes les personnes concernées l’ont reconnu publiquement.

Les financements ont commencé à arriver : GitHub Sponsors depuis 2019, Open Collective, le Sovereign Tech Fund allemand depuis 2022 et le projet Alpha-Omega de l’OpenSSF. Ils arrivent de manière inégale et bénéficient surtout aux projets déjà connus. La réglementation arrive également. Le Cyber Resilience Act de l’Union européenne est entré en vigueur en décembre 2024, la plupart de ses obligations devant s’appliquer à partir de décembre 2027. Les premières versions auraient fait peser la responsabilité du fabricant sur des bénévoles non rémunérés. Le texte final crée donc une catégorie moins contraignante appelée « open source software steward », après un long travail de lobbying mené par des fondations et des distributions.

Ce que l’histoire de l’open source signifie pour les logiciels de votre VPS

Toutes les applications présentées dans nos guides d’auto-hébergement dépendent de ces décisions. Nextcloud existe à la suite d’un fork : en 2016, le fondateur d’ownCloud et une grande partie de l’équipe ont quitté le projet et l’ont relancé sous AGPLv3. Les deux produits évoluent en parallèle depuis. Cette histoire explique les alternatives à Nextcloud à envisager ainsi que les alternatives auto-hébergées à Dropbox qui concurrencent ces deux solutions.

Le même schéma se retrouve dans l’hébergement Git. Gitea a lui-même commencé en 2016 comme un fork de Gogs. Fin 2022, la marque et les domaines du projet ont été transférés à une entreprise. Codeberg a forké Forgejo en décembre de la même année, puis Forgejo est passé de la licence MIT à la GPLv3 avec la version 9, en 2024. Les deux solutions sont présentées dans les solutions de serveurs Git auto-hébergés, et la différence de licence explique en grande partie pourquoi elles continuent à diverger. Parallèlement, la plupart des logiciels libres sont développés sur GitHub, une plateforme propriétaire appartenant à Microsoft. C’est un débat ancien, avec de bons arguments des deux côtés : voir ce qu’est réellement GitHub.

Avant de confier un serveur à un projet, quatre vérifications prennent dix minutes et sont utiles.

• Lisez le fichier LICENSE dans le dépôt, pas la page marketing. Ces pages continuent souvent à parler d’« open source » longtemps après que le fichier ne confirme plus cette affirmation.
• Recherchez une CLA ou une cession des droits d’auteur. S’il en existe une, un seul propriétaire peut modifier les conditions des versions futures.
• Vérifiez qui détient les droits d’auteur : une entreprise, plusieurs contributeurs ou une fondation.
• Comptez les mainteneurs actifs. Un projet qui n’en compte qu’un représente un risque pour cette personne autant que pour vous.

Cela ne signifie pas qu’il faut éviter les logiciels contrôlés par un seul fournisseur. Beaucoup sont excellents, et le fait d’être payants explique souvent pourquoi ils sont encore maintenus. Ces vérifications vous indiquent les risques auxquels vous vous exposez. Lorsque vous déterminez ce qui mérite d’être auto-hébergé, ajoutez la licence aux critères de comparaison, à côté de la mémoire nécessaire.

Vous pouvez consulter une partie de cet historique directement sur la machine que vous utilisez. Chaque paquet d’un système Debian ou Ubuntu fournit ses propres conditions de licence :

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Le premier nombre indique combien de paquets installés contiennent un fichier de copyright, généralement quelques centaines sur un petit VPS. La deuxième commande affiche le début de celui de bash, qui mentionne la GNU General Public License version 3. Un fichier manquant signifie que le paquet n’a pas été construit conformément à la policy Debian. C’est rare et cela mérite une vérification avant de lui faire confiance.

FAQ

Quelle est la différence entre logiciel libre et open source ?

Ils couvrent presque le même ensemble de licences, mais ne s’accordent pas sur la raison pour laquelle ces licences sont importantes. « Logiciel libre » est le terme le plus ancien. Il vient de la Free Software Foundation, en 1985, et son argument est éthique : un utilisateur qui ne peut pas modifier le programme ne contrôle pas son ordinateur. « Open source » a été créé en février 1998 pour expliquer plus facilement ces mêmes licences aux entreprises. Son argument est pratique. Les licences GPL, MIT, BSD et Apache 2.0 figurent toutes sur les deux listes officielles. Les auteurs qui veulent désigner les deux notions à la fois utilisent FOSS ou FLOSS.

Un logiciel source-available est-il la même chose qu’un logiciel open source ?

Non. Source-available signifie que vous pouvez lire le code. Selon l’Open Source Definition, open source signifie également que la licence ne peut pas limiter les personnes autorisées à utiliser le logiciel ni l’usage qu’elles en font. Les licences SSPL et Business Source License limitent l’usage commercial concurrent. Elles ne sont donc ni l’une ni l’autre open source selon cette définition, même si leur code source est publié. Si vous hébergez uniquement le logiciel pour votre propre usage, cette restriction peut ne jamais vous concerner. Si vous souhaitez construire un produit dessus, lisez d’abord attentivement le texte de la licence.

Une entreprise peut-elle retirer une licence open source qu’elle a déjà accordée ?

Pas pour le code qu’elle a déjà publié. Cette version reste couverte par la licence avec laquelle elle a été publiée. C’est précisément pourquoi des forks comme Valkey et OpenTofu ont pu partir du dernier commit distribué sous une licence permissive. Une entreprise peut en revanche placer les versions futures sous de nouvelles conditions. Elle ne peut le faire que si elle détient les droits d’auteur sur l’ensemble du projet, par cession de droits ou au moyen d’un contributor licence agreement. Les projets qui comptent de nombreux détenteurs indépendants des droits d’auteur, notamment Linux, ne peuvent être relicenciés par personne.

Quelle licence dois-je rechercher pour un logiciel auto-hébergé ?

Pour un logiciel que vous exécutez vous-même sans le revendre, toute licence approuvée par l’OSI, comme GPL, AGPL, MIT ou Apache 2.0, vous donne tout ce dont vous avez besoin. La vérification la plus utile consiste à déterminer qui détient les droits d’auteur, car cela détermine si les conditions peuvent changer ultérieurement sans votre accord. Un projet détenu par une fondation ou par de nombreux contributeurs indépendants ne peut pas être relicencié contre ses utilisateurs. Un projet détenu par un seul éditeur et soumis à un contributor licence agreement peut l’être. Les deux peuvent être de bons logiciels. Un seul peut modifier les règles de sa propre initiative.