LLM open source : licences et usage commercial (2026)
Un LLM open source, ou plutôt open-weights, se télécharge en un clic, mais le droit de l'utiliser dans un produit payant dépend d'un fichier texte que peu de gens lisent : sa licence. Ce guide explique ce que permettent Apache 2.0, MIT et une licence maison comme celle de Llama 3.3, à partir des textes officiels, puis donne une méthode pour vérifier chaque modèle avant de le déployer. Il ne remplace pas l'avis d'un juriste : il vous aide à poser les bonnes questions.
#Pourquoi la licence d'un LLM open source décide avant le modèle
Quand une équipe choisit un modèle à auto-héberger, elle regarde d'abord la qualité des réponses, la mémoire nécessaire et la vitesse. La licence arrive souvent en dernier, au moment où un client ou un service achats pose la question. C'est l'ordre inverse de celui qui évite les ennuis : un modèle excellent mais dont la licence interdit votre usage ne sert à rien, et changer de modèle après l'intégration coûte du temps de développement, de nouveaux tests et parfois un nouveau réglage fin.
Le vocabulaire entretient la confusion. Beaucoup de modèles présentés comme « open source » publient leurs poids, mais pas leurs données d'entraînement ni tout leur code, et certains sous une licence qui ne répond pas à la définition de l'Open Source Initiative. La différence conceptuelle entre open-weights et open source fait l'objet d'un guide dédié ; ici, on s'intéresse à une seule question pratique : qu'est-ce que le texte de la licence vous autorise à faire avec les poids, en particulier pour un usage commercial ?
Trois situations reviennent dans les entreprises. Usage interne : le modèle tourne sur vos serveurs pour vos équipes, rien n'est distribué. Service : vous exposez le modèle à des clients via une application ou une API, sans leur remettre les poids. Redistribution : vous livrez les poids, éventuellement modifiés ou quantifiés, dans un produit, un appareil ou un dépôt public. Les obligations des licences diffèrent fortement selon ces trois cas, gardez-les en tête pour la suite.
#Les trois familles de licences de LLM open source
Déployer une IA locale au travail : RGPD, AI Act, architecture multi-utilisateurs, coûts, note pour la direction.
- Espace en ligne à vie
- PDF + fichiers
- Remboursé 30 j
Les licences rencontrées sur Hugging Face ou dans la bibliothèque Ollama se rangent, en pratique, dans trois familles. Le classement ne dit rien de la qualité du modèle ; il indique seulement le niveau de contraintes à examiner.
- Licences permissives standard
- Apache 2.0 et MIT en tête. Ce sont des licences logicielles anciennes, connues des juristes, qui autorisent l'usage commercial, la modification et la redistribution avec des obligations limitées (conserver les mentions, fournir le texte). Elles ne visent pas spécifiquement l'IA, mais beaucoup d'éditeurs les appliquent à leurs poids.
- Licences communautaires maison
- Rédigées par l'éditeur du modèle pour ce modèle : Llama Community License chez Meta, conditions d'utilisation spécifiques chez d'autres éditeurs. Elles autorisent souvent l'usage commercial, mais ajoutent des conditions : seuil d'utilisateurs, mention obligatoire, règles de nommage, politique d'usage acceptable à respecter.
- Licences restrictives
- Licences de recherche, licences non commerciales (par exemple Creative Commons avec clause NC) ou licences à restrictions d'usage détaillées. L'usage commercial y est exclu ou soumis à un accord séparé avec l'éditeur.
Un même éditeur peut publier des modèles dans plusieurs familles. Selon les générations, des familles de modèles connues ont mélangé des tailles sous Apache 2.0 et d'autres sous licence maison ou de recherche. Ne déduisez donc jamais la licence d'un modèle de son nom de famille ou de son éditeur : vérifiez le fichier de la variante exacte que vous téléchargez.
#Apache 2.0 : ce que le texte autorise
La licence Apache 2.0 date de janvier 2004 et son texte est publié par l'Apache Software Foundation. C'est la licence permissive la plus fréquente pour les poids de LLM open-weights. Elle accorde à chaque destinataire une licence de droit d'auteur perpétuelle, mondiale, non exclusive, gratuite et sans redevance pour reproduire, modifier, afficher, sous-licencier et distribuer l'œuvre et ses dérivés (section 2).
Son point distinctif est la licence de brevets explicite de la section 3 : chaque contributeur accorde une licence sur ses brevets nécessairement violés par sa contribution. Cette licence prend fin pour vous si vous engagez une action en contrefaçon de brevet affirmant que l'œuvre elle-même viole un brevet. Pour une entreprise, cette clause clarifie un risque que MIT laisse dans l'ombre.
- Usage commercial
- Autorisé, en interne comme dans un service ou un produit vendu, sans redevance ni seuil d'utilisateurs.
- Modification
- Autorisée : réglage fin, quantification, fusion de poids. Le résultat peut être placé sous une autre licence pour vos propres apports, à condition de respecter Apache 2.0 pour la partie reprise (section 4).
- Redistribution
- Autorisée sous quatre conditions (section 4) : remettre une copie de la licence, signaler de façon visible les fichiers modifiés, conserver les mentions de droit d'auteur, de brevets, de marques et d'attribution, et reprendre le contenu du fichier NOTICE s'il existe.
- Marques
- Non accordées (section 6) : vous pouvez dire que votre produit utilise tel modèle, pas utiliser le nom ou le logo de l'éditeur comme s'il s'agissait de votre marque.
- Garantie et responsabilité
- Aucune (sections 7 et 8) : le modèle est fourni « en l'état ». Les erreurs du modèle restent votre responsabilité vis-à-vis de vos clients.
En usage interne ou en service sans remise des poids, les obligations de redistribution ne s'appliquent pas directement, puisque rien n'est distribué. Elles redeviennent centrales si vous publiez une version quantifiée ou ajustée du modèle, ou si vous l'embarquez dans un logiciel livré à des clients.
#MIT : la licence la plus courte
La licence MIT tient en trois paragraphes, tels que publiés par l'Open Source Initiative. Elle autorise gratuitement toute personne à utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies du logiciel, sans restriction. La seule condition : la mention de droit d'auteur et le texte de la permission doivent être inclus dans toutes les copies ou parties substantielles. Le reste du texte exclut toute garantie et toute responsabilité des auteurs.
- Usage commercial
- Autorisé, explicitement, y compris la vente.
- Modification et redistribution
- Autorisées, avec pour seule obligation de conserver la mention de droit d'auteur et le texte de la licence.
- Brevets
- Le texte ne contient pas de licence de brevets explicite, contrairement à Apache 2.0. La portée implicite de la permission en matière de brevets est une question d'interprétation à soumettre à un juriste si elle compte pour vous.
- Garantie
- Aucune, comme pour Apache 2.0.
Pour un LLM, MIT est donc la licence la plus simple à respecter. Le piège principal est ailleurs : vérifier que la mention MIT couvre bien les poids, et pas seulement le code d'inférence publié dans le même dépôt GitHub.
#Licence communautaire Llama 3.3 : usage commercial sous conditions
Meta publie ses modèles Llama sous une licence propre à chaque version. La Llama 3.3 Community License Agreement, datée sur la page officielle du 6 décembre 2024, sert ici d'exemple de licence maison, parce qu'elle est très répandue et que beaucoup de modèles dérivés en héritent. Elle accorde une licence non exclusive, mondiale, non transférable et sans redevance pour utiliser, reproduire, distribuer, copier, modifier les « Llama Materials » et créer des œuvres dérivées. L'usage commercial est donc possible, mais encadré.
- Redistribution
- Si vous distribuez les Llama Materials ou un produit qui les contient, y compris un modèle dérivé, vous devez fournir une copie de l'accord et afficher de façon visible « Built with Llama » sur un site, une interface, un article ou une documentation du produit.
- Nommage des modèles dérivés
- Si vous utilisez les Llama Materials ou leurs sorties pour créer, entraîner ou améliorer un modèle d'IA que vous distribuez, son nom doit commencer par « Llama ».
- Mention de droits
- Les copies distribuées doivent conserver le fichier Notice indiquant que Llama 3.3 est sous licence Llama 3.3 Community License, copyright Meta Platforms.
- Politique d'usage acceptable
- L'usage doit respecter les lois applicables et la politique d'usage acceptable de Llama 3.3, intégrée par référence. Elle liste des usages interdits ; elle peut être mise à jour par Meta, relisez-la à la date de votre décision.
- Seuil de 700 millions d'utilisateurs
- Si, à la date de sortie de Llama 3.3, les produits ou services du licencié ou de ses affiliés dépassaient 700 millions d'utilisateurs actifs mensuels le mois calendaire précédent, il doit demander une licence à Meta, que Meta peut accorder ou non à sa discrétion. Pour la quasi-totalité des entreprises, ce seuil n'est pas atteint, mais il montre que la licence n'est pas universelle.
- Marques
- Aucune licence de marque, hormis l'usage de « Llama » nécessaire pour respecter la mention et le nommage.
- Résiliation et droit applicable
- La licence prend fin si vous engagez une action contre Meta affirmant que les Llama Materials violent vos droits de propriété intellectuelle. L'accord est régi par le droit de l'État de Californie.
Cette licence n'est pas reconnue comme open source au sens de l'Open Source Initiative, notamment à cause des restrictions d'usage et du seuil. Cela n'empêche pas un usage commercial, mais impose un suivi plus attentif qu'Apache 2.0 ou MIT : mentions à afficher, nom de vos modèles dérivés, conformité à une politique qui peut évoluer.
#Tableau comparatif : Apache 2.0, MIT et Llama 3.3
Ce tableau est construit uniquement à partir des trois textes officiels cités en sources, consultés pour la préparation de ce guide (vérification du brief au 29 septembre 2026). Il résume des clauses, pas leur interprétation juridique. Il ne dit rien des autres licences maison, qui ont chacune leurs propres règles.
- Usage commercial
- Apache 2.0 : oui, sans condition particulière. MIT : oui, sans condition particulière. Llama 3.3 : oui, sous réserve du seuil de 700 millions d'utilisateurs actifs mensuels et de la politique d'usage acceptable.
- Modification, réglage fin
- Apache 2.0 : oui, fichiers modifiés à signaler. MIT : oui. Llama 3.3 : oui ; un modèle dérivé distribué doit porter un nom commençant par « Llama ».
- Redistribution des poids
- Apache 2.0 : oui, avec copie de la licence, mentions et fichier NOTICE. MIT : oui, avec mention de droit d'auteur et texte de licence. Llama 3.3 : oui, avec copie de l'accord, fichier Notice et mention « Built with Llama ».
- Licence de brevets explicite
- Apache 2.0 : oui (section 3). MIT : non. Llama 3.3 : le texte accorde une licence sur les droits de propriété intellectuelle de Meta sur les Llama Materials ; sa portée exacte est à faire analyser.
- Restrictions d'usage
- Apache 2.0 : aucune liste d'usages interdits. MIT : aucune. Llama 3.3 : politique d'usage acceptable intégrée par référence.
- Seuil de taille
- Apache 2.0 : aucun. MIT : aucun. Llama 3.3 : 700 millions d'utilisateurs actifs mensuels à la date de sortie.
- Marques
- Apache 2.0 : non accordées. MIT : non mentionnées. Llama 3.3 : non accordées, sauf l'usage de « Llama » requis par la licence.
- Garantie
- Aucune pour les trois textes.
Pour savoir quels modèles du moment relèvent de chaque famille, ne vous fiez pas à ce tableau : il compare des textes, pas des modèles. Consultez notre sélection des meilleurs LLM pour un usage commercial et, surtout, appliquez la méthode ci-dessous à la variante exacte que vous comptez déployer.
#Vérifier la licence d'un LLM open source modèle par modèle
La méthode tient en cinq étapes. Elle prend une vingtaine de minutes par modèle et laisse une trace exploitable par un juriste ou un auditeur.
- 01Identifier le dépôt d'origineRemontez à la page de l'éditeur sur Hugging Face (organisation officielle, pas un compte tiers qui republie une quantification). Notez le nom exact du dépôt et de la variante : taille, instruct ou base, version. Une conversion GGUF publiée par un tiers reste soumise à la licence du modèle d'origine.
- 02Lire le fichier de licence, pas l'étiquetteLe champ license de la fiche modèle donne une indication, mais seul le fichier LICENSE (ou équivalent) du dépôt fait foi, avec les éventuels fichiers USE_POLICY ou NOTICE. Vérifiez qu'il couvre bien les poids et pas seulement le code. Si l'étiquette indique « other », une licence maison est en jeu : lisez-la en entier.
- 03Croiser avec la page officielle de l'éditeurComparez avec la licence publiée sur le site de l'éditeur ou dans son annonce. Si les deux divergent, ne tranchez pas seul : signalez l'écart à votre juriste.
- 04Archiver le texte datéTéléchargez le fichier de licence, notez la date, l'URL et le numéro de révision du dépôt, et calculez son empreinte. Si l'éditeur change ses conditions plus tard, vous saurez quelle version vous avez acceptée.
- 05Confronter la licence à votre usageUsage interne, service ou redistribution : pour chaque cas, listez les obligations (mentions, nommage, politique d'usage, seuil) et la personne chargée de les respecter. Faites valider la grille par un juriste avant la mise en production.
L'API publique de Hugging Face renvoie les métadonnées d'une fiche, dont l'étiquette de licence. C'est un point de départ rapide, à compléter par la lecture du fichier lui-même. Remplacez le nom du dépôt par celui que vous évaluez.
Pour archiver le fichier de licence d'un dépôt public, téléchargez-le avec l'outil en ligne de commande de Hugging Face, puis calculez son empreinte. Les dépôts à accès contrôlé, comme ceux de Meta, demandent d'accepter les conditions sur le site et un jeton d'accès. Le nom exact du fichier varie selon les dépôts : vérifiez-le dans l'onglet « Files ».
Si le modèle est déjà installé dans Ollama, la commande ollama show affiche la licence embarquée dans le paquet. Utile pour un contrôle de cohérence, elle ne remplace pas la source de l'éditeur : un paquet communautaire peut contenir un texte incomplet ou absent.
#Pièges fréquents
- Confondre le code et les poids
- Un dépôt GitHub sous MIT peut contenir le code d'inférence, tandis que les poids sont publiés ailleurs sous une licence maison. C'est la licence des poids qui encadre votre usage du modèle.
- Se fier à une republication
- Les quantifications GGUF publiées par des tiers affichent parfois une licence erronée ou simplifiée. Elles ne changent pas les droits : seul le texte de l'éditeur d'origine compte.
- Oublier l'héritage des modèles dérivés
- Un modèle ajusté à partir de Llama reste soumis aux conditions de Llama, même si son auteur l'affiche sous Apache 2.0. Lisez la fiche du modèle de base mentionné dans les métadonnées et le texte de licence du dérivé.
- Supposer qu'une licence est figée
- Les éditeurs publient une licence par version, et les politiques d'usage intégrées par référence peuvent évoluer. D'où l'intérêt d'archiver le texte daté que vous avez accepté.
- Ignorer les données d'entraînement et les sorties
- La licence des poids ne règle pas tout : statut des contenus générés, données personnelles traitées par le modèle, obligations sectorielles. Ces sujets relèvent d'autres textes et d'un avis juridique dédié.
- Oublier la réglementation
- Une licence permissive ne dispense pas des obligations de l'AI Act selon votre rôle (fournisseur, déployeur) et l'usage du système. C'est une question distincte de la licence.
#Pour aller plus loin
La licence n'est qu'un des critères du choix d'un modèle. Pour comprendre pourquoi si peu de modèles sont vraiment open source, comparer les modèles disponibles ou situer votre déploiement face à l'AI Act, ces pages complètent ce guide.
Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.