Licences logicielles IA et open source expliquées : MIT vs Apache vs GPL vs AGPL vs propriétaire

Repères rapides

• MIT est la licence permissive la plus courte et la plus répandue — environ 170 mots, sans clause de brevet.
• Apache-2.0 ajoute une concession de brevet explicite que MIT n'a pas, ce qui explique la préférence de nombreuses entreprises pour les projets d'origine corporate.
• GPL n'exige la divulgation du code source qu'en cas de distribution du logiciel ; AGPL-3.0 étend cette obligation à l'exploitation comme service réseau.
• L'"open source" certifié OSI est une certification précise de l'Open Source Initiative ; "source-available" et "fair-code" sont des termes marketing pour des licences qui ne répondent pas à cette définition.
• Les licences de modèles IA forment une catégorie distincte des licences de code. Le code d'un outil peut être sous Apache-2.0 alors que les poids du modèle qu'il télécharge portent des conditions entièrement différentes, souvent plus restrictives.

Que sont les licences permissives ? MIT, Apache-2.0 et BSD

• La licence MIT est née au Massachusetts Institute of Technology comme moyen de diffuser des logiciels universitaires avec un minimum de restrictions. Elle compte environ 170 mots, accorde des droits quasi illimités, et exige seulement que le texte original de copyright et de licence reste attaché à toute copie ou portion substantielle redistribuée.
• La licence Apache 2.0 provient de l'Apache Software Foundation, créée pour offrir aux contributeurs corporate et communautaires un cadre juridique commun pour de grands projets collaboratifs. Contrairement à MIT, elle inclut une concession de brevet explicite — les contributeurs concèdent aux utilisateurs leurs droits de brevet couvrant le code — ce qui explique la préférence de nombreuses entreprises détentrices de portefeuilles de brevets.
• Les licences BSD (2 clauses et 3 clauses) sont nées à l'Université de Californie à Berkeley pour le système d'exploitation Berkeley Software Distribution. La variante à 3 clauses ajoute une clause de non-approbation interdisant d'utiliser le nom des auteurs originaux pour promouvoir un produit dérivé sans autorisation.
• Effet pratique pour les utilisateurs : vous pouvez forker, modifier, intégrer et vendre un outil sous licence permissive dans un produit fermé sans jamais publier votre propre code source — le seul risque réel est d'omettre la mention de copyright/licence requise dans votre distribution.
• Exemples réels tirés des reviews de ce site : Ollama et llama.cpp sont tous deux sous MIT ; vLLM est sous Apache-2.0 — les trois peuvent être intégrés dans un produit commercial sans déclencher d'obligation de divulgation du code source.

Qu'est-ce que le copyleft ? La famille GPL et LGPL

• La GNU General Public License (GPL) a été rédigée par Richard Stallman et la Free Software Foundation comme licence du projet GNU, fondée sur l'idée que la liberté logicielle doit se transmettre en aval — quiconque reçoit une copie modifiée doit avoir les mêmes droits que l'auteur original.
• GPL v2 et GPL v3 diffèrent surtout par le langage relatif aux brevets et les dispositions de compatibilité ; la v3 a ajouté des clauses explicites de rétorsion en matière de brevets et anti-tivoïsation (empêchant un matériel de bloquer l'exécution d'un logiciel modifié que vous avez pourtant le droit légal d'exécuter).
• La GNU Lesser General Public License (LGPL) assouplit GPL spécifiquement pour les bibliothèques — vous pouvez lier une bibliothèque LGPL à une application propriétaire sans ouvrir le code de l'application elle-même, tant que le composant bibliothèque reste remplaçable et que son propre code source reste disponible.
• Ce qui déclenche réellement l'obligation : distribuer une copie modifiée du code sous GPL. Le simple usage interne d'un logiciel GPL non modifié, ou l'exécution d'un logiciel propriétaire sur un système d'exploitation sous GPL, ne place pas automatiquement votre propre code sous GPL.
• Qui doit être prudent : une startup prévoyant de forker et modifier un outil GPL comme cœur d'un produit commercial a besoin d'un plan — soit ouvrir ces modifications, soit éviter le fork ; une entreprise se contentant d'exécuter en interne un outil GPL non modifié n'a pas cette obligation.

Comment AGPL-3.0 comble la brèche du SaaS

• La brèche comblée : sous GPL seule, exploiter une version modifiée comme service web hébergé ne constitue pas une "distribution" au sens juridique que déclenche la licence — une entreprise pouvait prendre du code GPL, le modifier, ne l'offrir que comme produit SaaS, et n'avoir jamais à publier les modifications. Ce phénomène est devenu connu de manière informelle comme la "brèche ASP" (application service provider) ou "brèche SaaS".
• AGPL-3.0 a été rédigée spécifiquement pour combler cette brèche en ajoutant une clause d'interaction réseau : proposer la fonctionnalité du logiciel modifié à des utilisateurs via un réseau déclenche la même obligation de mise à disposition du code source que la distribution d'une copie physique.
• Pourquoi cela compte pour l'hébergement et la revente : une agence ou un hébergeur qui prend un outil sous AGPL, le modifie et l'offre à des clients comme service hébergé doit rendre le code source modifié accessible à ces utilisateurs — l'exécuter sans modification ne déclenche aucune obligation de ce type.
• Exemples réels tirés des reviews de ce site : Jan, KoboldCpp, SillyTavern et text-generation-webui sont sous AGPL-3.0 — sans problème pour un auto-hébergement non modifié à usage personnel ou interne ; la question change radicalement dès que vous en modifiez un et revendez un accès hébergé.
• Ceci est une explication générale du fonctionnement du mécanisme de licence, pas un conseil juridique — savoir si un déploiement précis constitue un "proposer via un réseau" au sens exact d'AGPL-3.0 est une question à poser à un avocat examinant votre architecture spécifique.

Que sont les licences source-available et "fair-code" ?

• La Business Source License (BSL, aussi appelée BUSL) accorde d'emblée un accès au code source et de larges droits d'usage, avec une date future définie à laquelle la licence bascule vers une licence réellement open source (souvent Apache-2.0 ou une licence permissive similaire) — jusqu'à cette bascule, une restriction d'usage commercial s'applique, généralement destinée à empêcher une offre hébergée concurrente.
• La Server Side Public License (SSPL), créée par MongoDB, exige que quiconque propose le logiciel comme service ouvre également l'intégralité de la pile de service construite autour — une obligation bien plus large que celle d'AGPL-3.0, délibérément conçue pour rendre l'hébergement commercial impraticable pour un fournisseur cloud concurrent.
• La Commons Clause est une restriction additionnelle superposée à une licence de base autrement permissive ou copyleft, interdisant spécifiquement de vendre le logiciel ou de le proposer comme service hébergé payant, tout en autorisant l'usage et la modification libres.
• Pourquoi des projets adoptent ces licences : un projet qui démarre sous une licence entièrement ouverte puis adopte une licence source-available réagit typiquement à un grand fournisseur cloud proposant le projet comme service hébergé sans contribuer en retour — basculer vers une licence source-available permet au mainteneur de conserver l'essentiel de l'ouverture tout en bloquant cet usage concurrent précis.
• Effet pratique pour les utilisateurs : vous pouvez généralement lire, auto-héberger et modifier un logiciel source-available pour un usage interne sans problème ; la restriction s'applique lorsque vous tentez de le revendre comme produit hébergé concurrençant l'offre du titulaire de la licence — lisez la clause d'usage commercial précise, car les formulations varient fortement selon les projets.

Que signifient les licences propriétaires et freemium "gratuites" ?

• "Gratuit (fermé)" dans un tableau comparatif signifie logiciel propriétaire sans frais. Vous pouvez utiliser l'application compilée selon les conditions d'utilisation de l'éditeur, mais vous n'avez aucun accès au code source ni aucun droit de le modifier, l'auditer ou le forker.
• Le compromis principal face aux alternatives open source : une application propriétaire gratuite est souvent plus soignée et plus simple à installer, un éditeur unique contrôlant toute l'expérience utilisateur — mais vous dépendez entièrement de sa volonté continue de la maintenir gratuite, sécurisée et à jour.
• Risque de dépendance à l'éditeur (vendor lock-in) : sans accès au code source, vous ne pouvez pas auto-héberger une version modifiée, auditer précisément ce que l'application fait de vos données, ni poursuivre le développement si l'éditeur cesse la maintenance, change son modèle tarifaire ou ferme.
• Qui doit être le plus attentif : quiconque construit un workflow ou un processus métier autour d'un outil propriétaire gratuit devrait disposer d'un plan de repli documenté — la même diligence que pour toute dépendance à un fournisseur, car "gratuit" ne signifie ni "permanent" ni "garanti".
• Ce n'est pas équivalent à source-available : les licences source-available (BSL, SSPL) permettent au moins de lire et d'auditer le code même si l'usage commercial est restreint ; un outil totalement propriétaire n'offre ni le code ni ces garanties.

Comment fonctionnent les licences de modèles IA ? Open weights, RAIL et restrictions d'usage

• Poids entièrement permissifs : certaines familles de modèles publient leurs poids sous une licence logicielle permissive standard (souvent Apache-2.0), accordant les mêmes droits d'usage étendus que cette licence confère au code, y compris un usage commercial sans restriction de domaine.
• Les licences RAIL et OpenRAIL (Responsible AI License) sont nées avec la publication du modèle BLOOM par BigScience et ont été conçues conjointement avec des chercheurs en droit pour associer accès ouvert et liste précise d'usages interdits — interdisant généralement la génération de désinformation, une prise de décision discriminatoire ou du contenu contraire à la loi, tout en autorisant par ailleurs un large usage commercial.
• Licences "communautaires" ou "open-weight" sur mesure : plusieurs grands fournisseurs de modèles publient leurs poids sous une licence taillée sur mesure qui ressemble à une licence ouverte mais ajoute des conditions de domaine d'usage. L'exemple le plus cité est la licence communautaire que Meta attache à ses poids de modèles publiés ouvertement, qui accorde un large usage gratuit mais ajoute un seuil d'échelle d'usage au-delà duquel un accord commercial séparé est requis, avec des restrictions d'usage acceptable.
• Ce qu'il faut vérifier précisément : si l'usage commercial est autorisé du tout, s'il existe un seuil d'échelle d'usage ou de revenu modifiant les conditions, ce qu'interdit la politique d'usage acceptable, et si la licence restreint l'usage des sorties du modèle pour entraîner un modèle concurrent — une restriction apparue dans plusieurs licences spécifiques à des modèles et sans équivalent dans les licences logicielles standards.
• Ceci n'est pas un conseil juridique — les conditions de licence des modèles changent d'une publication à l'autre chez un même fournisseur ; vérifiez donc le texte exact de licence attaché aux poids de modèle précis que vous comptez déployer plutôt que de supposer une continuité avec une publication antérieure de la même organisation.

Qui doit se soucier de quelle licence ?

Checklist avant d'adopter un outil : 7 points à vérifier

1. 1
   Lire le fichier LICENSE réel du dépôt
   Why it matters: L'affirmation "open source" d'une page d'accueil peut relever du marketing, pas d'un fait juridique — le fichier LICENSE (ou NOTICE/COPYING) du dépôt source est le document faisant foi, pas un badge ou une page tarifaire.
2. 2
   Vérifier si la licence a récemment changé
   Why it matters: Certains projets rebasculent d'une licence permissive ou copyleft vers une licence source-available après avoir gagné en traction commerciale — ce schéma s'est répété dans l'industrie logicielle à mesure que des fournisseurs cloud hébergeaient des projets open source populaires sans contribuer en retour. Vérifiez l'historique de licence du dépôt, pas seulement le fichier actuel.
3. 3
   Vérifier si la licence est réellement certifiée OSI, si cela compte pour vous
   Why it matters: Des licences source-available comme BSL et SSPL sont couramment présentées comme open source mais ne figurent pas sur la liste approuvée par l'Open Source Initiative — si la certification OSI est une exigence pour votre cas d'usage, vérifiez la liste directement plutôt que de faire confiance à la description d'un projet.
4. 4
   Lire les clauses d'usage commercial et de domaine d'usage spécifiques aux modèles IA
   Why it matters: La licence d'un modèle peut autoriser largement l'usage commercial, le restreindre au-delà d'un seuil d'échelle d'usage, ou interdire purement et simplement certaines applications — ces clauses sortent du langage habituel des licences logicielles et sont faciles à manquer si vous ne vérifiez que la licence du code.
5. 5
   Déterminer si l'auto-hébergement ou l'hébergement SaaS change vos obligations
   Why it matters: Sous AGPL-3.0, proposer un logiciel modifié via un réseau déclenche la même obligation de divulgation que la distribution d'une copie sous GPL — confirmez dans quelle catégorie tombe votre déploiement prévu avant de modifier le code.
6. 6
   Vérifier l'existence d'un accord de licence de contributeur (CLA) en cas de contribution
   Why it matters: Un CLA peut accorder au mainteneur du projet des droits plus étendus sur votre contribution que ceux que la licence du projet accorde aux utilisateurs — pertinent surtout si vous comptez soumettre du code au projet, pas si vous ne faites que le consommer.
7. 7
   Vérifier les restrictions de marque séparément de la licence du code
   Why it matters: Une licence de code permissive ou copyleft n'accorde pas automatiquement de droits sur le nom ou le logo du projet — forker et rebrander un outil peut être bloqué par le droit des marques même quand la licence du code autoriserait par ailleurs le fork.

Erreurs fréquentes

• Faire confiance à l'affirmation "open source" d'une page marketing au lieu de lire le fichier LICENSE réel du dépôt.
• Supposer qu'AGPL-3.0 ne concerne que la distribution d'une copie du logiciel — elle s'applique aussi à proposer du code modifié comme service hébergé.
• Traiter la licence du code d'un modèle et la licence de ses poids comme un seul et même document — elles diffèrent fréquemment.
• Forker et rebrander un outil sans vérifier les restrictions de marque, distinctes de la licence du code.
• Supposer qu'une licence permissive au lancement d'un projet le reste après une relicenciation ultérieure — vérifiez la licence actuelle, pas celle dont vous vous souvenez.
• Se dispenser d'une revue juridique pour un outil copyleft ou source-available parce qu'il est "gratuit" — gratuit à l'usage et sans obligation ne sont pas la même chose.

Sources

• Open Source Initiative — The Open Source Definition — la définition formelle qu'une licence doit remplir pour être certifiée open source par l'OSI.
• Projet GNU — Free Software Licenses — les explications de la Free Software Foundation sur GPL, LGPL et AGPL.
• Apache Software Foundation — Apache License 2.0 — texte intégral de la licence.
• Texte de la licence MIT (Open Source Initiative) — texte intégral de la licence.
• MongoDB — Server Side Public License — les conditions et la justification propres à la SSPL.
• FAQ de la Business Source License — explication du fonctionnement de la conversion BSL/BUSL par un adoptant notable de la licence.

Questions fréquentes

Pour aller plus loin

• Le répertoire complet des logiciels LLM locaux — plus de 160 outils de LLM local avec la licence de chaque entrée.
• Review de Dify AI Workflow Builder — une review qui nomme sa licence ; utilisez ce guide pour comprendre ce qu'elle signifie pour votre déploiement.
• Contenu généré par IA et risque de propriété intellectuelle — les questions de propriété intellectuelle qui accompagnent la licence lorsque vous exploitez commercialement des sorties générées par IA.
• Sécurité de l'IA agentique : identité et accès — considérations de sécurité et de gouvernance pour les déploiements d'IA auto-hébergés, un enjeu complémentaire à la conformité des licences.
• RAG local conforme au RGPD pour documents sensibles — le risque de licence et le risque de résidence des données/conformité sont deux checklists distinctes ; ce guide couvre le volet conformité.