Une Note « AI Model Component » dans les licences Open Source

15 avril 2026

Ce qu’il faut retenir

Les poids d’un modèle d’IA intégrés dans un logiciel libre sont fonctionnellement équivalents à du code objet (ils déterminent le comportement du programme mais ne sont pas modifiables sans les informations qui ont permis de les produire).

Même si l’esprit des licences libres imposerait de fournir tout ce qui précède à la conception du modèle, la pratique de conformité s’arrête aux fichiers source classiques, laissant les composants d’IA dans un angle mort pratique, alors même que les définitions des licences (« forme privilégiée pour apporter des modifications ») les couvrent déjà.

Cet article expose l’idée d’une « AI Model Component Note », sous la forme d’une clarification interprétative greffable sur toute licence copyleft, qui explicite la portée, pour les composants de modèles d’IA, des obligations de fourniture de source déjà établies par ces licences. Elle n’ajoute ni ne retranche aux droits et obligations de la licence d’accueil.

Cette démarche s’inscrit dans une tradition établie d’adaptation des licences libres à un environnement technique en mouvement (anti-tivoisation, clause Affero, informations d’interface LGPL). Elle s’en distingue toutefois en ce qu’elle ne modifie aucune licence : il s’agit d’une interprétation publiée par les titulaires de droits, à l’image de la note du noyau Linux sur les appels système ou de la GPL FAQ de la FSF.

Mise à jour (juin 2026). À la suite des retours du FSFE Legal Network et de la Free Software Foundation, la proposition a évolué en version 1.1-draft : renommage en « Note », périmètre de la section 2 arbitré (test fonctionnel ancré dans les décisions d’assemblage des titulaires), section 3 reformulée en standard de délivrance, régime des modèles tiers pré-entraînés, FAQ étendue. L’article conserve son récit d’origine ; le texte canonique vit dans le dépôt.

Dans notre article consacré aux définitions de l’IA open source de la série « Open Source et IA », nous avons montré que les licences Open Source peinent actuellement à saisir les enjeux de l’ouverture en matière d’IA.

Les licences Open Data telle que l’Open Database license (ODbL) constituent une solution mobilisable en amont, permettant de couvrir à la fois la base de données d’entrainement et potentiellement le modèle d’IA lui-même. Pour aller plus loin et se rapprocher du mouvement du logiciel libre et Open Source, il avait aussi été développé l’idée d’une exception aux licences Open Source qui, tel un avenant, viendrait définir précisément les obligations relatives aux modèles d’IA intégrés au code. Complémentaire à la solution précédente, il s’agirait alors d’assurer aux utilisateurs des logiciels toutes les libertés auxquelles ils peuvent prétendre au titre des licences libres.

Cet article propose une clause concrète : l’AI Model Component Note. Il s’agit d’une clarification interprétative, rédigée en anglais pour être directement utilisable, greffable sur toute licence copyleft existante. Elle précise (sans rien y ajouter) la portée des obligations de fourniture de source déjà contenues dans la licence d’accueil, lorsque le logiciel intègre des composants de modèles d’IA. Nous exposons ici le raisonnement juridique qui la fonde, les précédents qui l’inspirent, et le texte lui-même.

Situer le contexte : un logiciel libre avec un composant opaque

Le postulat initial, qui justifie la démarche, est qu’un logiciel libre/Open Source intégrant de l’IA n’est pas réellement libre au sens où les détenteurs d’une copie ne peuvent que partiellement bénéficier des libertés attendues.

Le code est sous GPL-3.0 ou Apache-2.0, les dépendances sont documentées, le SBOM est propre. Mais le modèle d’IA utilisé ne partage pas sa « recette » – les poids, les embeddings, les fichiers de calibration – alors que seule cette dernière permet de comprendre le comportement du programme.

La situation est strictement analogue à celle qui a motivé chaque extension majeure du copyleft dans l’histoire des licences libres :

Problème historique	Mécanisme de réponse	Analogie avec l’IA
Tivoisation (vérifier la signature du logiciel embarqué afin que seule la version du fabricant fonctionne sur le matériel)	GPLv3, section 6 (obligation de fournir les clés de signature et informations d’installation)	Distribuer les poids sans les données ni les scripts d’entraînement, c’est distribuer un binaire sans le source
ASP Loophole (utiliser un logiciel libre en SaaS sans jamais « distribuer » la source correspondante)	AGPL-3.0, section 13 (obligation d’accès au code pour les utilisateurs réseau)	Utiliser un modèle via une API sans jamais fournir les informations de modification
Verrouillage des bibliothèques (intégrer une bibliothèque libre dans une application propriétaire sans fournir les informations d’interface pour faire tourner une bibliothèque modifiée)	LGPLv3, section 4 (obligation de fournir le « Corresponding Application Code » et les informations d’interface)	Intégrer un modèle libre dans un logiciel sans fournir ce qui permet de le modifier ou le remplacer

Le dénominateur commun est le même : une partie du logiciel est rendue effectivement non-libre faute d’information pour la modifier pleinement, alors que la licence formelle est libre. La clause anti-tivoisation, la clause Affero et le mécanisme LGPL ont chacun étendu les obligations existantes à ces situations en levant les ambiguïtés que l’évolution technique avait créées.

Il convient toutefois de préciser ce que ces trois précédents nous enseignent – et ce qu’ils n’enseignent pas. Ils constituent autant de modifications de licence : le texte de la GPL a été réécrit pour intégrer la section anti-tivoisation, l’AGPL est une licence distincte de la GPL, la LGPL a fait évoluer son mécanisme d’interface au fil des versions. Notre démarche est volontairement différente : elle ne modifie aucune licence, n’ajoute aucune obligation et ne retranche aucun droit. Elle relève d’une autre famille de réponses – tout aussi établie en pratique – qu’on peut appeler la clarification interprétative : le titulaire des droits publie sa lecture du texte existant, sans le réécrire.

Plusieurs exemples bien connus illustrent ce mécanisme :

la note du fichier COPYING du noyau Linux sur les appels système (Torvalds, à partir de 1992 – aujourd’hui enregistrée dans SPDX sous l’identifiant Linux-syscall-note) : les co-titulaires du noyau y précisent que les programmes utilisateur invoquant le noyau via des appels système normaux ne sont pas considérés comme des œuvres dérivées. Une clarification de la portée de la GPL-2.0 qui structure depuis trente ans l’écosystème Linux sans avoir jamais été tranchée par un juge ;
la note interprétative de Larry Wall dans le README de la distribution Perl (vérifiable depuis Perl 4.0, 1991) : « mon interprétation de la GNU General Public License est qu’aucun script Perl ne tombe sous les termes de la GPL sauf mention explicite de votre part mettant ledit script sous les termes de la licence GPL ». Comme la note Linux, jamais tranchée par un juge ; tenue pour autoritative par les mainteneurs et les conseils depuis plus de trois décennies ; largement créditée d’avoir rendu possible l’écosystème de modules tiers de Perl ;
la couche de prises de position publiques des stewards de licences – la GPL FAQ de la FSF – référence pratique des conseils et des équipes conformité –, Apache Software Foundation legal-discuss, opinions juridiques de l’Eclipse Foundation, statements MPL de la fondation Mozilla, position papers de l’OSI – qui forment, sur leurs licences respectives, une couche interprétative régulièrement utilisée sans réémission de la licence.

Sur la distinction doctrinale entre interprétation (précision d’une clause imprécise ou équivoque pour figer la portée de la licence) et exception (dérogation modifiant le texte de la licence), voir B. Jean, L’évolution des licences libres et open source, HAL halshs-02077882.

L’effet d’une telle interprétation n’est pas certain devant un juge – celui-ci pourrait s’écarter de la lecture du licenseur. Mais elle a deux effets pratiques importants : (1) elle ferme les lectures les plus opportunistes qu’un distributeur en aval pourrait invoquer, puisqu’il ne peut plus prétendre avoir compris la licence d’une manière que le titulaire avait expressément exclue ; (2) elle fait basculer la charge argumentative – et le risque contentieux – sur celui qui souhaiterait soutenir la lecture inverse, alors qu’il utilise volontairement la licence concernée. Dit autrement : ne pas se conformer à l’interprétation publiée par les titulaires reste juridiquement défendable, mais devient matériellement plus coûteux que d’exploiter un silence.

Les poids d’un modèle d’IA intégrés dans un logiciel sont fonctionnellement équivalents à du code objet. Ils déterminent le comportement du programme mais ne sont pas modifiables sans les informations qui ont permis de les produire (architecture, scripts d’entraînement, données, hyperparamètres). Cette analogie, discutée notamment par Andrew Marble (« Copyright for AI Model Weights », 2023), est partagée par une partie croissante de la communauté : les poids sont le « object code » du modèle, les données et scripts d’entraînement en sont le « source code ».

Cette grille de lecture est d’ailleurs cohérente avec la définition de la « source » retenue par les licences copyleft elles-mêmes. La GPL-3.0 (§1) définit le code source comme « the preferred form of the work for making modifications to it » ; l’EUPL-1.2 (art. 1) retient « the human-readable form of the Work which is the most convenient for people to study and modify ». Aucune de ces formulations n’exige un format textuel ou un jeu d’instructions impératives : elles désignent la forme qui permet le mieux d’étudier et de modifier l’œuvre. Pour un composant de modèle d’IA, cette forme est l’architecture, les scripts d’entraînement, la configuration et la description des données (pas le binaire des poids). Néanmoins, en l’absence de formule claire sur cette application aux modèles, la situation fait courir un risque interprétatif et nuit à la prévisibilité contractuelle (nécessaire aux opérateurs économiques).

En ajoutant aux licences Copyleft une exception (même s’il s’agit plus d’une déclaration de portée) qui vient interpréter et lever toute ambiguïté quant à la nécessité de partager les informations du modèle, l’obligation naît du contrat de licence, pas d’une qualification juridique encore débattue. Cette approche se situe dans un espace précis :

Moins radicale que la position de la FSF, qui estime qu’une application d’apprentissage machine libre induit que le code d’entraînement et les données d’entraînement doivent être libres (voir leur position officielle). La FSF et la Software Freedom Conservancy maintiennent une position ambitieuse (« FOSS in, FOSS out, FOSS throughout ») qui exige l’ouverture complète de toute la chaîne. Cette approche est factuellement plus proche de la situation qui combinerait une licence ODbL sur les bases de données d’entraînement et les modèles et d’une licence Open Source copyleft assortie de la Note.
Plus conservatrice que le « Contextual Copyleft » proposé par Shanklin, Hine, Novelli et al. (juillet 2025), qui étend le copyleft des données d’entraînement aux modèles résultants – mais qui potentiellement impose de couvrir plus que le logiciel objet de la licence, ce qui pourrait être considéré comme contraire à l’OSD (qui pose notamment comme critère que la licence ne peut pas « contaminer » d’autres œuvres indépendantes).
Complémentaire à la relance de copyleft-next par Bradley Kuhn et Richard Fontana (juillet 2025), qui vise à concevoir une licence copyleft de nouvelle génération. La proposition d’une exception qui vient lever l’ambiguïté nous semble plus simple à mettre en oeuvre que d’attendre qu’une telle licence aboutisse (aussi intéressant que soit le projet).

Les deux concepts clés susceptibles d’être précisés

Le « Composant de Modèle d’IA » (AI Model Component) désigne toute partie du logiciel dont le comportement est déterminé, en tout ou partie, par un modèle d’apprentissage automatique : les paramètres entraînés (poids, biais, embeddings), les fichiers de configuration du modèle, les données de calibration, les tables de quantification, ou tout autre artefact dont la modification est nécessaire pour adapter le comportement de cette partie du programme.

Il fait partie du programme. Le fait que son comportement résulte de paramètres appris plutôt que d’instructions explicitement programmées ne modifie pas sa nature de logiciel et ne diminue pas les droits accordés aux destinataires par la licence applicable. Il est donc pleinement couvert par la licence Open Source associée au logiciel.

Le deuxième concept est celui des « Informations Correspondantes du Modèle » (Model Corresponding Information) qui concernent l’ensemble complet des informations, données et instructions raisonnablement nécessaires pour qu’une personne qualifiée puisse comprendre, reproduire, modifier et réintégrer le composant dans le programme : ce qui renvoie directement à la preferred form for making modifications, étendue aux spécificités de l’IA. Cela inclut :

La spécification complète de l’architecture du modèle (topologie, configuration des couches, fonctions d’activation) dans un format documenté et lisible par machine ;
Les paramètres entraînés (poids, biais) dans un format standard ou documenté ;
Le code source complet des procédures d’entraînement, de fine-tuning et d’évaluation, y compris les pipelines de prétraitement ;
La configuration d’entraînement (hyperparamètres, optimiseur, seeds aléatoires le cas échéant) ;
Une description suffisamment détaillée des données d’entraînement (provenance, méthode de collecte, étapes de traitement) pour permettre de constituer un jeu de données fonctionnellement équivalent, ou les données elles-mêmes lorsqu’elles peuvent être légalement redistribuées ;
Les instructions nécessaires pour réentraîner, fine-tuner ou remplacer le composant et le réintégrer dans le programme.

Le point (e) est intentionnellement flexible : lorsque les données ne peuvent pas être redistribuées (vie privée, droits d’auteur, volume), une description suffisante pour reconstituer un équivalent suffit. C’est une approche pragmatique, comparable à la manière dont la GPL demande les « scripts used to control compilation and installation » plutôt que le compilateur lui-même.

Le texte de la Note

Publiée sur la forge inno³ sous licence CC 0, cette proposition d’exception est rédigée en anglais comme clarification interprétative, greffable sur toute licence copyleft via un mécanisme de renvoi à la « Licence applicable ». Elle ne dépend d’aucune licence spécifique et ne modifie pas les droits et obligations établis par celle-ci ; elle se borne à rendre explicite la manière dont ces obligations s’appliquent aux composants de modèles d’IA.

Le texte canonique (version 1.1-draft, juin 2026) est maintenu dans le dépôt du projet ; les définitions clés sont reproduites ci-dessous.

AI Model Component Note

Interpretive clarification for software incorporating AI model components

The following interpretive clarification applies to the work to which it is attached (the « Program« ) and is provided by the copyright holder(s) of the Program. This clarification supplements – and shall be read together with – the license under which the Program is distributed (the « Applicable License« ). It does not add to or remove from the rights and obligations established by the Applicable License; rather, it makes explicit how certain existing obligations apply when the Program incorporates AI model components. To the extent that any provision of this clarification conflicts with the Applicable License, the Applicable License prevails.

0. Definitions

The « Program » means the work on which the Applicable License imposes the obligation to provide source code (or its preferred form for making modifications) – that is, the covered or licensed work as the Applicable License itself defines it. This clarification does not extend that obligation to any other work; it only makes explicit how the existing obligation applies to AI Model Components within that work.

An « AI Model Component » means any part of the Program whose behavior is determined, in whole or in part, by a machine learning model – including but not limited to trained parameters (weights, biases, embeddings), model configuration files, calibration data, quantization tables, or any other artifact whose modification is necessary to adapt, correct, or improve the behavior of that part of the Program. Whether an AI Model Component falls within this definition is determined by the role it plays in the Program’s behavior, and not by the technical form of its packaging or by its conceptual independence from the surrounding code. For the avoidance of doubt, an AI Model Component is part of the Program; the fact that its behavior results from learned parameters rather than from explicitly programmed instructions does not, by itself, take that Component outside the scope of the Applicable License when it is distributed as part of the Program. Sections 2(a), 2(b) and 2(c) below identify the configurations in which a model is not considered part of the Program.

The « Model Corresponding Information » for an AI Model Component means the set of information, data, and instructions sufficient for a skilled person to understand, retrain, fine-tune, replace, and reintegrate that Component into the Program – that is, the preferred form of the AI Model Component for making modifications to it. This includes, without limitation:

(a) the specification of the model architecture (topology, layer configuration, activation functions, normalization schemes) sufficient for a skilled person to understand and modify the Component, in a documented, machine-readable format;

(b) the trained parameters (weights, biases) in a standard or well-documented format;

(c) the complete source code of the training, fine-tuning, and evaluation procedures used to produce the distributed parameters, including data preprocessing and augmentation pipelines;

(d) the training configuration (hyperparameters, optimization settings, random seeds where deterministic reproduction is feasible);

(e) a sufficiently detailed description of the training data – including its provenance, collection method, and processing steps – enabling a skilled person to assemble a functionally equivalent dataset; the training data itself, where it can be lawfully redistributed; or, where the training data is publicly available or obtainable from third parties, a listing of that data and of where to obtain it, including, where applicable, for a fee; and

(f) the instructions necessary to retrain, fine-tune, or replace the AI Model Component and to reintegrate the modified version into the Program, such that the Program can be built and run with the modified Component in the same manner as with the original.

The Model Corresponding Information is sufficient when it enables a skilled person to retrain, fine-tune, or replace the AI Model Component and to reintegrate it into the Program. As for the preferred form of a work for making modifications, the reference is the form actually used: the Model Corresponding Information comprises the elements of points (a) to (f) as the licensor or distributor itself uses or holds them in order to modify the Component. It does not require acquiring elements that have never been in the distributor’s possession (Section 2 governs that case); it does require providing, without degradation, the forms actually used. The source code and the trained parameters of the Component, as distributed, are in all cases provided.

The Applicable License’s own definition of Corresponding Source continues to govern what is excluded from it (such as System Libraries or general-purpose development tools); this clarification adds inclusions, and does not remove those exclusions. The software and any training dataset are distinct creations subject to distinct rights; this clarification does not extend the Applicable License to a dataset or other work that is not itself part of the licensed Program. Whatever the form in which the information is provided, it must remain possible for a skilled person to produce a functionally equivalent model.

Les sections 1 à 3 (déclaration de portée, exclusions dont les modèles pré-entraînés de tiers, standard de délivrance) se lisent de préférence dans le texte canonique, avec la FAQ.

À noter que :

Cette proposition d’exception reprend la distinction classique du droit des licences libres entre « œuvre dérivée » et « simple agrégation ». Un modèle intégré au programme (sans lequel celui-ci ne fonctionnerait pas comme prévu) est un composant du programme et déclenche l’obligation. Un modèle agrégé sur le même support de distribution, ou appelé via une API publique, reste une œuvre indépendante non couverte par l’exception. C’est la transposition, pour l’IA, de la frontière entre linking et aggregation en matière de copyleft logiciel.
L’exception légale (section 2, alinéa final) : elle reconnaît qu’en pratique, certains éléments des informations correspondantes (données personnelles, bases de données protégées par le droit sui generis) ne pourront pas toujours être redistribués.Elle impose une obligation documentaire : fournir tout ce qui peut l’être, et documenter précisément ce qui manque et pourquoi. Cette approche est inspirée de la manière dont le RGPD et la directive 2019/790 (TDM) coexistent dans la pratique : les obligations se superposent, et c’est la transparence sur les limites qui permet la conformité. Le même régime documentaire couvre désormais les modèles pré-entraînés de tiers (identification précise, documentation des étapes réalisées par le distributeur).
La section 3 fixe un standard de délivrance : les Informations Correspondantes du Modèle suivent les mêmes moyens habituels et le même calendrier que le code source requis par la licence d’accueil ; lorsque cette licence contient une clause de non-restriction supplémentaire (GPL-3.0 §10, AGPL-3.0 §13, GPL-2.0 §6), les barrières contractuelles ou techniques empêchant d’utiliser, d’étudier, de modifier ou de redistribuer ces informations sont traitées comme des restrictions supplémentaires au sens de cette clause. Garde-fou anti open-washing, sans excéder ce que la licence d’accueil tolère pour la fourniture ordinaire de source.

Suite et roadmap du projet

Cette proposition est volontairement publiée comme un draft ouvert (actuellement v1.1-draft, intégrant la première vague de retours communautaires) : non parce qu’elle serait inaboutie, mais parce que la conversation qu’elle ouvre fait partie de la méthode. Le projet suit trois phases :

Phase A – semer et collecter (en cours). Poser une première proposition articulée et l’utiliser pour récolter (1) des retours substantifs, notamment côté FSFE Legal Network, SFLC/SFC, OSI et fora juridiques équivalents (les premiers retours, du FSFE Legal Network et de la Free Software Foundation, ont été reçus et intégrés), et (2) des contributeurs et relecteurs potentiels, à la fois côté juristes et côté mainteneurs.
Phase B – éprouver sur des projets réels. Accompagner l’usage sur des projets concrets, à commencer par Hermine-foss, outil open source de conformité licences que nous co-maintenons et où la question de l’intégration d’un composant d’IA est en discussion active dans la communauté partenaire – sans qu’un modèle ne soit intégré à ce stade. Tout autre projet souhaitant tester la clarification est bienvenu, via les issues du dépôt.
Phase C – pousser dans les standards et communiquer plus largement. Soumettre AI-Model-Component-Note à la SPDX License List, articuler la clarification avec OSAID 1.0 et la régulation européenne (RIA, CRA, NPLD), et porter la discussion dans les conférences (FOSDEM, EOLE, OSS Summit, Free Software Legal & Licensing Workshop) ainsi qu’auprès des fondations et publications académiques.

Une feuille de route plus détaillée est tenue à jour dans le dépôt du projet (ROADMAP.md).

Conclusion : clarifier, pas créer

Cette proposition d’exception « interprétative » est ainsi à la fois un outil de gouvernance open source et un outil de conformité réglementaire. Les deux logiques convergent : garantir que les utilisateurs disposent des informations nécessaires pour comprendre, modifier et auditer le logiciel qu’ils utilisent. Elle s’articule naturellement et complète les exigences des trois règlements européens analysés dans notre article sur l’articulation CRA/RIA/NPLD :

Le RIA (art. 53.1) impose aux fournisseurs de modèles GPAI de mettre à disposition une « documentation technique suffisamment détaillée » et les informations sur les données d’entraînement. Les « Model Corresponding Information » dépassent cette attente. L’article 53(2) exonère les modèles GPAI open source des points (a) et (b) précisément lorsque les poids, l’architecture et les informations d’usage sont rendus publics : les Informations Correspondantes du Modèle documentent exactement ce que cette exemption présuppose ;
Le CRA impose des SBOM et de la traçabilité. L’exception complète le SBOM logiciel par un inventaire des composants de modèle.
La NPLD étend la responsabilité produit aux logiciels. Documenter les composants IA du logiciel renforce la traçabilité en cas de défaut (et protège le mainteneur qui a respecté ses obligations de transparence).

Cette proposition d’AI Model Component Note ne crée pas d’obligation nouvelle. Elle clarifie que les obligations existantes de toute licence Open Source copyleft (fournir les informations nécessaires pour exercer les libertés sur le logiciel) s’étendent naturellement aux composants de modèles d’IA. Là où l’anti-tivoisation et la clause Affero avaient répondu à des évolutions techniques en réécrivant la licence, nous proposons ici une réponse de l’autre famille évoquée plus haut : une déclaration de portée par les titulaires des droits, qui ne touche pas le texte de la licence et se borne à dire ce qu’il faut, à leurs yeux, comprendre par « source correspondante » lorsque le programme intègre un composant de modèle d’IA.

L‘exception est publiée sous licence CC 0. Elle est conçue pour être adoptée, adaptée et discutée par la communauté. Nous invitons les mainteneurs, les fondations et les juristes à l’évaluer, la critiquer et la faire évoluer. Elle pourra être utilisée à l’instar des autres exceptions Open Source (NomDeLicence WITH Identifiant ; une fois l’identifiant accepté sur la SPDX License List : GPL-3.0-or-later WITH AI-Model-Component-Note ; dans l’intervalle, voir les expressions SPDX transitoires dans le HOW_TO_APPLY du projet).

Crédit de l’illustration : Remix de @2006, Señor Codo, blotter_explosion. This file is licensed under the Creative Commons Attribution-Share Alike 2.0 Generic license.