Explorez la philosophie de Richard Stallman sur le logiciel libre, le projet GNU et la GPL — et comment ils ont transformé les licences, les droits des développeurs et l’open source.
Le logiciel n’est pas seulement un produit technique — c’est aussi un ensemble d’autorisations. Qui peut l’exécuter, le copier, le partager avec un ami, corriger un bug ou bâtir quelque chose de nouveau dessus ? Ces questions se répondent moins par le code que par les licences. À mesure que le logiciel est devenu central au travail, à la communication et à la recherche, les règles sur « ce que vous êtes autorisé à faire » ont commencé à façonner l’innovation autant que les fonctionnalités.
Richard Stallman (souvent appelé « RMS ») compte parce qu’il a rendu ces règles impossibles à ignorer. Au début des années 1980, il a constaté un basculement : de plus en plus de programmes étaient distribués sans code source, et on disait aux utilisateurs qu’ils ne pouvaient utiliser le logiciel qu’aux conditions de quelqu’un d’autre. Stallman a présenté cela non comme un simple désagrément, mais comme une perte de liberté pour les utilisateurs et les développeurs — et il a répondu en proposant un ensemble clair de principes et d’outils juridiques pour protéger ces libertés.
Cet article se concentre sur les idées de Stallman et leurs conséquences pratiques : la définition du logiciel libre, le projet GNU, le copyleft et la licence générale GNU (GPL) — et comment tout cela a façonné l’écosystème open source moderne et les normes de licence logicielle.
Ce n’est pas une biographie, ni un approfondissement technique sur la compilation d’un noyau ou la gestion de dépôts. Vous n’avez pas besoin d’un bagage en programmation pour suivre.
Stallman est influent et aussi controversé. L’objectif ici est de rester factuel et lisible : ce qu’il a défendu, quels mécanismes juridiques ont émergé, comment entreprises et développeurs se sont adaptés, et où les débats persistent aujourd’hui — afin que vous compreniez pourquoi son travail influence encore les choix logiciels quotidiens.
« Logiciel libre » se prête facilement au malentendu car le mot libre ressemble à une indication de prix. Richard Stallman utilisait libre pour parler de liberté — la capacité de l’utilisateur à contrôler le logiciel sur lequel il compte.
Si un programme coûte 0 $ mais que vous n’êtes pas autorisé à l’inspecter, le modifier ou le partager, il peut être « gratuit comme la bière » tout en étant non libre au sens qui importait à Stallman.
Le logiciel libre se définit par quatre permissions de base :
Ces libertés portent sur l’autonomie : vous n’êtes pas seulement consommateur d’outils — vous pouvez devenir participant, vérifier, adapter et améliorer ces outils.
Les libertés 1 et 3 sont impossibles sans accès au code source — les instructions lisibles par des humains. Sans cela, le logiciel ressemble davantage à un appareil scellé : vous pouvez l’utiliser, mais vous ne savez pas ce qu’il fait, vous ne pouvez pas le réparer quand il tombe en panne, ni l’adapter à de nouveaux besoins.
L’accès au source importe aussi pour la confiance. Il permet la relecture indépendante (sécurité, confidentialité, équité) et rend possible la maintenance si l’auteur original cesse son support.
Pensez à un repas de restaurant.
C’est l’idée centrale : le logiciel libre porte sur les libertés nécessaires pour garder le contrôle de son informatique.
Avant que la « licence logicielle » ne devienne un sujet de débat courant, une grande partie de la culture du développement — surtout dans les universités et laboratoires de recherche — reposait sur une hypothèse : si vous pouviez améliorer un outil, vous partagiez l’amélioration. Le code source accompagnait souvent les logiciels, on apprenait en lisant le travail des autres, et les corrections se diffusaient par collaboration informelle.
Cette culture a commencé à changer à mesure que le logiciel devenait un produit. Entreprises (et même certaines institutions) ont commencé à considérer le code source comme un avantage concurrentiel. La distribution s’accompagnait de clauses « pas de partage », le code a cessé d’être livré avec les programmes, et les accords de confidentialité sont devenus la norme. Pour des développeurs habitués à résoudre des problèmes collectivement, ce changement n’était pas seulement gênant : c’était un changement de règles qui rendait la résolution communautaire de problèmes risquée sur le plan légal.
L’une des histoires d’origine les plus répétées concerne une imprimante au MIT AI Lab. Stallman a décrit comment une nouvelle imprimante est arrivée avec un logiciel distribué uniquement sous forme binaire, sans code source. Le problème pratique était banal : le laboratoire voulait modifier le programme pour gérer des problèmes comme notifier les utilisateurs en cas de bourrage ou mieux router les tâches. Dans les anciennes normes « hacker », quelqu’un aurait patché le code et partagé la correction. Ici, ils ne pouvaient pas — parce qu’ils n’avaient pas le droit de voir ou de modifier le source.
Il faut remettre cela en proportion : ce n’est pas qu’une imprimante a créé un mouvement mondial. C’était un exemple clair et parlant d’une tendance plus large — des outils dont dépendaient les gens devenaient inaccessibles à leurs utilisateurs.
Pour Stallman, la question centrale n’était pas seulement l’accès technique ; c’était la perte de la liberté de coopérer. Si vous ne pouvez pas étudier comment un programme fonctionne, vous ne pouvez pas vraiment le contrôler. Si vous ne pouvez pas partager des améliorations, les communautés se fragmentent et chacun finit par réinventer des solutions en privé.
Cette motivation a façonné les innovations de licence qui ont suivi. Plutôt que de compter sur la bonne volonté ou des normes informelles, Stallman voulait des règles préservant la capacité à utiliser, étudier, modifier et partager le logiciel — pour que la collaboration ne puisse pas être retirée dès qu’un programme devient commercialement précieux.
Le grand geste de Stallman n’a pas été seulement d’écrire un manifeste : c’était de lancer un effort d’ingénierie pratique. En 1983, il a annoncé le projet GNU, avec un objectif ambitieux : construire un système d’exploitation complet que n’importe qui pourrait utiliser, étudier, modifier et partager, tout en restant compatible avec Unix afin que les gens puissent exécuter des programmes et workflows familiers.
Un système d’exploitation n’est pas un seul programme — c’est toute une pile. GNU a entrepris de créer toutes les pièces quotidiennes nécessaires pour rendre un ordinateur utile, y compris :
En termes simples : GNU construisait la plomberie, le câblage et les interrupteurs — pas seulement un appareil.
Au début des années 1990, GNU avait produit une grande partie de cet « userland », mais un élément critique faisait défaut : le noyau (la partie qui gère matériel et ressources système). Quand Linux est apparu en 1991, il a comblé cette lacune.
C’est pourquoi de nombreux systèmes populaires aujourd’hui combinent des composants GNU avec le noyau Linux — souvent appelés « GNU/Linux ».
GNU a rendu l’idée du logiciel libre concrète en fournissant une base fonctionnelle sur laquelle d’autres pouvaient construire. La philosophie expliquait pourquoi la liberté importait ; GNU a livré les outils qui rendaient la liberté pratique, répétable et extensible.
Le copyleft est une stratégie de licence conçue pour maintenir le logiciel libre (au sens de la liberté) non seulement dans sa première version, mais aussi dans les versions futures. Si vous recevez du code sous copyleft, vous avez le droit de l’utiliser, de l’étudier, de le modifier et de le partager — mais lorsque vous distribuez votre version modifiée, vous devez transmettre les mêmes libertés aux autres.
Le copyleft peut sembler « anti‑copyright », mais il repose en réalité sur le droit d’auteur. L’auteur utilise son droit d’auteur pour définir des règles de permission dans une licence : « Vous pouvez copier et modifier ceci, mais si vous redistribuez, vous devez le faire sous cette même licence. » Sans droit d’auteur, il n’y aurait pas de mécanisme juridique pour faire respecter ces conditions.
Pensez‑y comme à une règle qui suit le code :
Le but est d’empêcher un schéma qui inquiétait Stallman : quelqu’un prend le travail communautaire, l’améliore, puis enferme ces améliorations.
Les licences permissives (comme MIT ou BSD) vous laissent généralement faire presque tout avec le code, y compris redistribuer des versions modifiées sous une licence propriétaire. Les licences copyleft (comme la GPL) autorisent toujours un large usage et la modification, mais exigent que les dérivés redistribués restent soumis aux mêmes termes copyleft — ainsi la liberté est préservée en aval.
La GNU General Public License (GPL) a changé la licence logiciel en transformant le « partage » en règle exécutoire, pas seulement en geste de bonne volonté. Avant la GPL, vous pouviez recevoir du code source, l’améliorer, puis expédier une version fermée que les utilisateurs ne pouvaient ni étudier ni modifier. La GPL a inversé cette dynamique : elle protège les libertés des utilisateurs en attachant des conditions à la redistribution.
Concrètement, la GPL accorde aux utilisateurs le droit d’exécuter le programme pour n’importe quel usage, de lire et modifier le source, et de partager les versions originelles ou modifiées.
Si vous redistribuez un logiciel GPL (surtout dans un produit), vous devez transmettre ces mêmes libertés. Cela signifie généralement :
Les obligations de la GPL se déclenchent principalement lorsque vous distribuez le logiciel à d’autres — expédier des binaires, vendre des appareils embarquant le logiciel ou donner des copies à des clients. Si vous modifiez du code GPL pour un usage interne sans distribution, vous n’êtes généralement pas tenu de publier le source.
Pas besoin d’un cours de droit pour saisir l’idée : si votre programme incorpore du code GPL d’une manière qui crée une œuvre combinée (par exemple en le liant à votre application), le résultat est généralement traité comme une œuvre dérivée et doit être distribué sous GPL. Exécuter un programme GPL ou communiquer avec lui comme processus séparé via des interfaces standard est souvent différent.
GPLv2 est la version classique et largement utilisée. GPLv3 ajoute des protections autour des accords de brevets et de la « tivoïsation » (appareils qui bloquent les logiciels modifiés). La LGPL est conçue pour les bibliothèques : elle permet le lien depuis des programmes propriétaires sous certaines conditions tout en gardant la bibliothèque elle‑même libre.
Les licences libres (en particulier la GNU GPL) n’« autorisent » pas seulement le partage — elles protègent le droit d’étudier, de modifier et de redistribuer le logiciel d’une façon difficile à retirer ensuite. Pour les développeurs, cela signifie que vos améliorations peuvent rester disponibles pour les autres sous les mêmes termes, au lieu d’être absorbées par un produit fermé sans que la communauté n’en bénéficie.
Sous la GPL, vous pouvez :
C’est pourquoi la GPL est souvent décrite comme une « réciprocité exécutoire ». Si quelqu’un distribue un programme couvert par la GPL (ou une œuvre dérivée), il ne peut pas ajouter des restrictions qui empêcheraient les utilisateurs en aval d’effectuer les mêmes types de modifications et partages.
Ces droits s’accompagnent d’obligations lorsque vous redistribuez le logiciel :
Ces responsabilités ne sont pas des « pièges » — ce sont le mécanisme qui empêche que la collaboration ne devienne de l’extraction à sens unique.
Les équipes devraient traiter la conformité des licences comme une hygiène de publication. Suivez :
Un simple Software Bill of Materials (SBOM) et une checklist reproductible pour les publications peuvent prévenir la plupart des problèmes avant que des juristes n’aient à intervenir.
Au niveau du code, « logiciel libre » et « open source » décrivent souvent les mêmes projets. La divergence porte surtout sur pourquoi le partage importe.
Le mouvement Free Software (associé à Richard Stallman et à la Free Software Foundation) considère la liberté logicielle comme une question éthique : les utilisateurs devraient avoir le droit d’exécuter, d’étudier, de modifier et de partager le logiciel. L’objectif n’est pas seulement une meilleure ingénierie — c’est la protection de l’autonomie des utilisateurs.
L’approche Open Source met l’accent sur les résultats pratiques : meilleure collaboration, itération plus rapide, moins de bugs et sécurité améliorée par la transparence. Elle présente l’ouverture comme un modèle de développement supérieur, sans exiger une posture morale.
En 1998, l’Open Source Initiative (OSI) a popularisé le terme « open source » pour rendre l’idée plus acceptable aux entreprises. « Free software » était souvent mal compris comme « gratuit », et certaines entreprises se méfiaient d’un message centré sur les droits et l’éthique. « Open source » a permis aux organisations de dire « nous pouvons fonctionner ainsi » sans paraître idéologiques.
Beaucoup de projets qui se disent open source utilisent la GNU GPL ou d’autres licences copyleft, tandis que d’autres choisissent des licences permissives comme MIT ou Apache. Le texte juridique peut être identique ; c’est le récit adressé aux contributeurs, utilisateurs et clients qui change. Un message dit « cela protège vos libertés », l’autre dit « cela réduit les frictions et améliore la qualité ».
Si la priorité de votre équipe est de garantir que les utilisateurs en aval conservent les mêmes libertés, parlez en termes de logiciel libre et envisagez le copyleft.
Si la priorité est de maximiser l’adoption (y compris par des entreprises qui ne veulent pas d’obligations réciproques), le cadrage open source — et souvent une licence permissive — conviendra mieux.
Si vous voulez une large collaboration tout en veillant à ce que les améliorations reviennent, utilisez un langage open source pour l’accessibilité et choisissez une licence copyleft pour l’effet réel.
Le logiciel libre n’implique pas « personne ne se fait payer ». Il signifie que les utilisateurs ont la liberté d’exécuter, d’étudier, de modifier et de partager le code. De nombreuses entreprises tirent des revenus sains de cette liberté — souvent en facturant pour ce que les organisations trouvent difficile : fiabilité, responsabilité et gain de temps.
Quelques modèles courants et éprouvés :
Un exemple moderne de l’offre « managée » est l’essor de plateformes qui génèrent et exécutent rapidement des applications. Par exemple, Koder.ai est une plateforme vibe‑coding qui aide les équipes à construire des applications web, backend et mobiles via le chat — tout en permettant l’export du code source. Cette combinaison (itération rapide + propriété du code) s’inscrit naturellement dans les valeurs de la liberté logicielle : pouvoir inspecter, modifier et déplacer son logiciel quand on en a besoin.
Le choix de licence peut déterminer qui capte la valeur :
« Commercial » décrit la façon dont c’est vendu ; « logiciel libre » décrit les droits de l’utilisateur. Une entreprise peut vendre du logiciel libre, facturer le support, et respecter la liberté logicielle.
Avant d’adopter ou de fonder un produit sur un projet FOSS, demandez‑vous :
La GPL et le « FOSS » sont souvent au cœur de discussions, mais quelques mythes récurrents embrouillent les équipes qui veulent simplement livrer un produit sans violer de licence.
Non. Le domaine public signifie qu’il n’y a pas d’auteur qui impose des conditions — n’importe qui peut réutiliser l’œuvre sans obligation.
La GNU GPL est le contraire du « sans conditions ». L’auteur conserve le droit d’auteur et accorde de larges permissions d’utilisation, de modification et de partage — mais seulement si vous respectez les termes de la GPL (notamment le partage du code source lors de la distribution de binaires couverts).
Rendre le code visible peut aider la sécurité, mais ce n’est pas une garantie. Un projet open source peut être :
La sécurité vient d’une maintenance active, d’audits, d’un signalement responsable et de bonnes pratiques opérationnelles — pas du seul label de licence.
On qualifie parfois la GPL de « virale » pour suggérer qu’elle se propage hors de contrôle. C’est une image chargée.
Ce dont il est généralement question, c’est le copyleft : si vous distribuez une œuvre dérivée de code GPL, vous devez fournir le code source correspondant sous GPL. Cette exigence est volontaire et délibérée : elle préserve les libertés des utilisateurs en aval. Ce n’est pas une « infection » ; c’est une condition que vous pouvez choisir d’accepter — ou d’éviter en utilisant autre code.
Règle générale : les obligations se déclenchent surtout lors de la distribution.
Quand cela compte, obtenez une lecture précise basée sur la manière dont le code est combiné et distribué — pas seulement des hypothèses.
Richard Stallman est une figure controversée. On peut le reconnaître tout en discutant clairement de l’influence durable des idées et licences qui lui sont associées.
Un point de départ utile est de séparer deux conversations : (1) les débats sur Stallman en tant que personne et membre de la communauté, et (2) l’impact mesurable des principes du logiciel libre, du projet GNU et de la GPL sur les licences logicielles et les droits des développeurs. Le second peut se discuter à partir de sources primaires (textes de licences, histoires de projets, modèles d’adoption) même quand on est en fort désaccord sur le premier.
Une critique récurrente ne porte pas sur la licence mais sur la gouvernance : comment les projets prennent des décisions, qui a l’autorité et que se passe‑t‑il quand fondateurs, mainteneurs et utilisateurs veulent des choses différentes. Les communautés du logiciel libre se sont penchées sur des questions comme :
Ces questions comptent car les licences fixent des termes juridiques, mais elles ne créent pas à elles seules une prise de décision saine.
Un autre débat porte sur l’inclusivité et les normes : comment les projets définissent l’attente d’un comportement respectueux, gèrent les conflits et accueillent les nouveaux venus. Certaines communautés favorisent des codes de conduite formels ; d’autres préfèrent des règles minimales et une modération informelle. Aucune approche n’est automatiquement « juste », mais les compromis sont réels et dignes de discussion sans attaques personnelles.
Si vous évaluez l’héritage de Stallman, il est utile d’appuyer les affirmations sur des éléments vérifiables : ce que la GPL exige, comment le copyleft a modifié les pratiques de conformité, et comment ces idées ont influencé des licences et institutions ultérieures. On peut être critique, soutien ou indécis — mais visez la précision, le respect et la clarté sur ce qui est critiqué.
Le plus grand cadeau pratique de Stallman pour les équipes quotidiennes est une question claire : quelles libertés voulez‑vous garantir en aval ? Y répondre transforme le « choix de licence » d’un ressenti en une décision éclairée.
Si vous hésitez, décidez selon votre objectif : adoption (permissive) vs réciprocité (copyleft) vs réciprocité adaptée aux bibliothèques (copyleft faible).
LICENSE à la racine du dépôt (copiez le texte complet de la licence).Si vous construisez des produits avec de l’aide d’outils IA (y compris des plateformes de chat comme Koder.ai), cette checklist prend encore plus d’importance : vous livrez de véritables dépendances et artefacts, et avez de réelles obligations de licence. La vitesse n’élimine pas la responsabilité — elle rend juste les routines de conformité reproductibles plus précieuses.
Rendez‑la ennuyeuse et répétable :
Pour des comparaisons plus détaillées, voir /blog/choosing-an-open-source-license et /blog/gpl-vs-mit-vs-apache.
« Logiciel libre » signifie liberté, pas prix.
Un programme peut être gratuit ($0) et rester non libre si vous ne pouvez pas l’inspecter, le modifier ou le partager. Le logiciel libre porte sur les droits d’exécuter, d’étudier, de modifier et de redistribuer le logiciel dont vous dépendez.
La définition repose sur quatre permissions :
Si l’une de ces libertés manque, les utilisateurs perdent le contrôle et la collaboration devient plus difficile.
Parce que vous ne pouvez pas raisonnablement étudier ou modifier un logiciel sans en avoir le code source.
L’accès au code source permet :
Le copyleft utilise le droit d’auteur pour exiger un « partage dans les mêmes conditions » lors de la redistribution.
Vous pouvez utiliser, modifier et même vendre le logiciel, mais si vous redistribuez une version modifiée, vous devez fournir aux destinataires les mêmes libertés (généralement en publiant le code source correspondant sous la même licence).
La GPL accorde des droits larges (utiliser, étudier, modifier, partager) et exige de la réciprocité lorsqu’on redistribue.
Si vous redistribuez des binaires couverts par la GPL, vous devez généralement :
Souvent, non.
Pour la GPL, les obligations se déclenchent généralement lors de la distribution. Si vous modifiez du code GPL pour un usage interne et que vous ne donnez pas de copies à l’extérieur de votre organisation, vous n’êtes en général pas tenu de publier vos changements.
(Ce point comporte des cas limites — considérez cela comme une règle pratique, pas un avis juridique.)
Cela dépend de la façon dont le code est combiné.
En pratique :
Quand ça compte, cartographiez précisément le mode d’intégration avant de distribuer.
Elles ciblent des préoccupations différentes :
Choisissez selon que vous vouliez une forte réciprocité (GPL) ou une réciprocité adaptée aux bibliothèques (LGPL).
Généralement non sous la GPL.
Si vous exécutez un logiciel GPL sur vos serveurs et que les utilisateurs n’interagissent que via le réseau, vous ne « distribuez » habituellement pas de copies, donc les obligations de partage de la GPL ne se déclenchent pas.
Si vous voulez que l’usage réseau exige le partage du code, regardez l’AGPL et évaluez‑la en fonction de votre modèle de déploiement.
Oui — de nombreuses entreprises monétisent le logiciel libre via des services et la livraison, sans restreindre les droits des utilisateurs.
Modèles courants :
Le choix de licence influe sur la stratégie : les licences permissives favorisent l’adoption ; le copyleft peut décourager les forks propriétaires et soutenir des modèles basés sur la réciprocité.