Richard Stallman et le logiciel libre : des idées qui ont changé le code

Pourquoi Richard Stallman compte encore

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.

Ce que cet article est (et n’est pas)

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.

Une vue équilibrée et accessible

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.

Ce que signifie réellement « logiciel libre »

« 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.

Les quatre libertés essentielles

Le logiciel libre se définit par quatre permissions de base :

• Liberté 0 : exécuter le programme pour n’importe quel usage.
• Liberté 1 : étudier comment le programme fonctionne et le modifier pour qu’il fasse ce que vous voulez.
• Liberté 2 : redistribuer des copies pour aider les autres.
• Liberté 3 : distribuer vos versions modifiées pour que la communauté en bénéficie.

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.

Pourquoi l’accès au code source est non négociable

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.

Une analogie simple : recettes vs plats scellés

Pensez à un repas de restaurant.

• Le logiciel propriétaire, c’est comme acheter un plat prêt à manger scellé : vous pouvez le déguster, mais vous ne connaissez pas les ingrédients, vous ne pouvez pas ajuster la recette et vous n’êtes pas autorisé à en faire des copies.
• Le logiciel libre, c’est comme obtenir la recette : vous pouvez la cuisiner chez vous, apprendre comment c’est fait, l’ajuster pour des allergies et partager votre version améliorée avec des amis.

C’est l’idée centrale : le logiciel libre porte sur les libertés nécessaires pour garder le contrôle de son informatique.

Le problème contre lequel Stallman réagissait

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.

Des normes de partage à des logiciels verrouillés

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’histoire de l’imprimante (exemple, pas mythe)

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.

Pourquoi cela a conduit à de nouvelles idées de licence

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 projet GNU : construire un système d’exploitation libre

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 complet, pas un seul outil

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 :

• Compilateurs (le plus célèbre étant GCC) pour transformer le code en programmes exécutables
• Utilitaires en ligne de commande (outils de base pour copier des fichiers, rechercher du texte, gérer des processus)
• Bibliothèques et outils pour développeurs pour supporter la construction de logiciels
• Shells et éditeurs pour travailler sur la machine au quotidien

En termes simples : GNU construisait la plomberie, le câblage et les interrupteurs — pas seulement un appareil.

GNU + Linux : comment la plupart des gens l’ont rencontré

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 ».

L’infrastructure importait autant que les idées

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 en langage clair

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.

Un outil juridique construit sur le droit d’auteur

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.

L’idée du “share alike” (avec des exemples simples)

Pensez‑y comme à une règle qui suit le code :

• Forks : vous fork‑ez un projet copyleft, ajoutez des fonctionnalités et publiez votre fork. Vous devez publier le code source et conserver la même licence pour que d’autres puissent aussi forker le vôtre.
• Redistributions : vous intégrez le programme dans un produit que vous expédiez aux clients. Vous pouvez facturer, mais vous devez fournir le source et les mêmes droits aux destinataires.

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.

Copyleft vs licences permissives

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.

Comment la GNU GPL a remodelé les licences

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.

Ce que la GPL donne — et ce qu’elle demande en retour

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 :

• fournir le code source (ou un moyen valable de l’obtenir) aux destinataires
• inclure le texte de la licence et préserver les mentions de droit d’auteur
• licencier vos modifications sous la GPL également, pour que les utilisateurs en aval ne soient pas « exclus »

Obligations de distribution du code source (quand elles s’appliquent)

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.

“Œuvre dérivée” en termes simples

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.

Variantes de la GPL : v2, v3 et LGPL

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.

Droits — et responsabilités — des développeurs sous les licences libres

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.

Quels droits vous gagnez

Sous la GPL, vous pouvez :

• bidouiller en toute confiance : lire le source, le modifier et exécuter votre version modifiée
• partager votre travail : distribuer des copies du programme original ou modifié
• bâtir sur les améliorations des autres : parce que les destinataires doivent obtenir les mêmes libertés

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.

Quelles responsabilités vous prenez

Ces droits s’accompagnent d’obligations lorsque vous redistribuez le logiciel :

• préserver les avis de droit d’auteur et la licence
• fournir (ou offrir) le code source correspondant quand la GPL l’exige
• laisser la licence intacte pour que les destinataires connaissent leurs droits

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.

Note pratique sur la conformité

Les équipes devraient traiter la conformité des licences comme une hygiène de publication. Suivez :

• quels composants open source vous expédiez,
• leurs versions et licences,
• où vous fournissez le code source (ou des offres écrites),
• et toutes modifications que vous avez apportées.

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.

Logiciel libre vs open source : une séparation de valeurs

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.

Priorités différentes : liberté vs adoption

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.

Pourquoi « open source » a pris

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.

Mêmes licences, cadrage différent

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é ».

Un guide de décision simple

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.

Modèles économiques et incitations réelles

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.

Comment les entreprises gagnent de l’argent avec le FOSS

Quelques modèles courants et éprouvés :

• Support et services : assistance payante, SLAs, formation, audits, fonctionnalités sur mesure, migrations
• Offres hébergées et managées : vendre une version hébergée où les clients paient pour la commodité, la montée en charge, les sauvegardes et la conformité
• Double licence : proposer le même logiciel sous une licence libre (souvent copyleft) et également sous une licence commerciale payante pour des clients qui veulent d’autres conditions
• Open core (avec prudence) : garder un noyau véritablement libre tout en vendant des extensions propriétaires. Cela peut fonctionner, mais risque d’éroder la confiance communautaire si la partie « libre » semble volontairement limitée

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.

Pourquoi permissif vs copyleft influence la stratégie

Le choix de licence peut déterminer qui capte la valeur :

• Licences permissives (MIT/Apache) facilitent la réutilisation par d’autres — y compris de grands acteurs — ce qui peut accroître l’adoption mais réduire la possibilité de monétiser l’exclusivité.
• Licences copyleft (GPL) obligent les redistributeurs à partager les modifications sous les mêmes termes. Cela peut décourager les forks fermés et soutenir des modèles commerciaux basés sur les services, distributions certifiées ou la double licence.

« Commercial » et « logiciel libre » ne sont pas opposés

« 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.

Checklist de pérennité

Avant d’adopter ou de fonder un produit sur un projet FOSS, demandez‑vous :

• La communauté est‑elle active (issues, releases, revues) ?
• La gouvernance est‑elle claire (qui décide, comment sont gérés les conflits) ?
• Le financement est‑il visible (sponsors, sociétés soutenant, fondation) ?
• La charge des mainteneurs est‑elle soutenable (bus factor, signaux d’épuisement) ?
• Les pratiques de sécurité sont‑elles documentées (rythme des patches, avis) ?

Idées fausses courantes sur la GPL et le FOSS

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.

« La GPL, c’est domaine public »

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).

« L’open source est toujours sécurisé »

Rendre le code visible peut aider la sécurité, mais ce n’est pas une garantie. Un projet open source peut être :

• non maintenu,
• peu relu,
• vulnérable pendant des années avant que quelqu’un ne s’en aperçoive.

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.

L’idée de « licence virale »

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.

« Puis‑je utiliser du code GPL dans mon application ou service ? » (niveau élevé)

Règle générale : les obligations se déclenchent surtout lors de la distribution.

• Usage interne : utiliser du logiciel GPL en interne ne vous oblige généralement pas à publier vos changements.
• Expédition d’une appli/appareil : si vous distribuez un programme ou un dérivé sous GPL, vous devez en général fournir le source et les mentions de licence.
• SaaS / services web : exécuter du logiciel GPL sur vos serveurs n’oblige généralement pas à publier le source pour les utilisateurs. (L’AGPL a été créée pour combler cette lacune.)

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.

Critiques, controverses et débats en cours

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.

Gouvernance et « qui décide ? »

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 :

• Comment choisir ou remplacer une direction ?
• Les fondations doivent‑elles être pilotées par leurs membres, par un conseil ou par les mainteneurs ?
• Quand la « liberté » des mainteneurs entre‑elle en conflit avec les besoins des contributeurs ?

Ces questions comptent car les licences fixent des termes juridiques, mais elles ne créent pas à elles seules une prise de décision saine.

Inclusion, conduite et normes communautaires

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.

Garder la discussion ancrée

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é.

Conclusions pratiques : choisir une licence et contribuer

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.

Un arbre décisionnel simple

• Voulez‑vous que d’autres (y compris des concurrents) réutilisent votre code avec peu de conditions ? Choisissez une licence permissive (ex. MIT, Apache‑2.0).
• Voulez‑vous que les améliorations de votre code restent partageables lors de la redistribution ? Choisissez copyleft fort (ex. GNU GPL).
• Voulez‑vous que le partage s’applique surtout aux modifications de votre bibliothèque tout en permettant à des apps propriétaires de lier la bibliothèque ? Choisissez copyleft faible (ex. LGPL, MPL).

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).

Étapes pratiques pour livrer du logiciel de façon responsable

1. Choisissez une licence par projet et indiquez‑la clairement dans votre README.
2. Ajoutez un fichier LICENSE à la racine du dépôt (copiez le texte complet de la licence).
3. Ajoutez des en‑têtes de droit d’auteur là où votre organisation l’exige.
4. Documentez les dépendances (directes et transitives importantes) et leurs licences.
5. Si vous distribuez des binaires, préparez les mentions, offres de source (si applicable) et attributions requises.

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.

Mettre en place une routine interne légère de conformité

Rendez‑la ennuyeuse et répétable :

• Générez un SBOM pendant les builds.
• Maintenez un fichier de mentions type et mettez‑le à jour quand les dépendances changent.
• Ajoutez un point de contrôle licence aux PRs/releases (même une checklist de 10 minutes).

Pour des comparaisons plus détaillées, voir /blog/choosing-an-open-source-license et /blog/gpl-vs-mit-vs-apache.