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

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, elles ne saisissent pas pleinement cette réalité : le copyleft s’arrête au code, laissant les composants IA dans un angle mort.
• Cet article expose l’idée d’une « AI Model Component Exception », 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.

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 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écisement 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 Exception. 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 » les source correspdondante)	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 en 1989 dans la distribution Perl, à l’occasion de l’adoption de la GNU GPL par Perl : « 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 trente-cinq ans ; 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 -​- GPL FAQ de la FSF (citée notamment par la cour d’appel de Paris dans Free / Entr’ouvert, 3 janvier 2008), 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, proposée notamment par Andrew Marble, 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 sitation fait courrir 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 toutes 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 modèles + d’une licence Open Source copyleft avec l’exception).
• 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’ambiguité 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 renvoit directement à la preferred form for making modifications, étendue aux spécificités de l’IA. Cela inclut :

1. 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 ;
2. Les paramètres entraînés (poids, biais) dans un format standard ou documenté ;
3. Le code source complet des procédures d’entraînement, de fine-tuning et d’évaluation, y compris les pipelines de prétraitement ;
4. La configuration d’entraînement (hyperparamètres, optimiseur, seeds aléatoires le cas échéant) ;
5. 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 ;
6. 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 l’exception

Publiée sur gitlab 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. Elle ne dépend d’aucune licence spécifique.

AI Model Component Exception

Interpretive clarification for software incorporating AI model components

The following interpretive clarification applies to the software designated below (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.

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. 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 alter its character as software or diminish the rights granted to recipients under the Applicable License.

The « Model Corresponding Information » for an AI Model Component means the complete set of information, data, and instructions reasonably necessary for a skilled person to understand, reproduce, modify, 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 complete specification of the model architecture (topology, layer configuration, activation functions, normalization schemes) 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 -​- to enable a reasonably skilled person to assemble a functionally equivalent dataset, or the training data itself where it can be lawfully redistributed; 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 functions with the modified Component in the same manner as it functioned with the original.

1. Model Corresponding Information as part of Corresponding Source.

For the avoidance of doubt, the copyright holder(s) clarify that the Model Corresponding Information for each AI Model Component constitutes part of the Corresponding Source (or equivalent concept, as defined in the Applicable License) -​- that is, the preferred form of the work for making modifications to it. The obligation to provide such information arises from the Applicable License itself; this clarification merely makes its scope explicit in the context of software incorporating AI model components.

Accordingly, any person who distributes or otherwise makes available the Program (or any work based on it) must provide the Model Corresponding Information for each AI Model Component under the same conditions, through the same means, and at the same time as the source code (or equivalent material) required by the Applicable License.

This applies regardless of the form in which the AI Model Component is distributed -​- whether as source code, binary files, serialized parameters, compiled or optimized intermediate representations, or any other form.

2. Scope and limitations.

This clarification applies solely to AI Model Components that form an integral part of the Program -​- that is, components without which the Program would not function as intended, or whose removal would materially alter the behavior of the Program. It does not extend to:

(a) independent AI models merely aggregated with the Program on a volume of storage or distribution medium; or

(b) AI models invoked by the Program as separate and independent works through standard, publicly documented interfaces (including but not limited to APIs and network calls).

This clarification creates no obligation with respect to outputs produced by the Program, nor with respect to AI models generated through the use of the Program as a tool. It pertains exclusively to components of the Program itself.

Where the provision of any element of the Model Corresponding Information is prevented by a legal impediment independent of the distributor’s will -​- in particular, obligations arising under data protection law or the sui generis database right -​- the distributor must provide all elements not so affected, together with a documented description of the missing elements and the precise legal grounds for their omission, so as to enable the recipient to reconstitute or independently obtain such elements.

3. No further restrictions.

The Model Corresponding Information must be provided under terms no more restrictive than the Applicable License. You may not impose any further restrictions on the exercise of the rights granted under the Applicable License with respect to the Model Corresponding Information -​- including by way of additional contractual obligations, technical protection measures, access controls, or terms of use that would prevent recipients from using, studying, modifying, or redistributing such information. Any such restriction shall be deemed a further restriction within the meaning of the Applicable License, and shall be void and of no effect to the maximum extent permitted by applicable law.

À 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é.
• La clause « no further restrictions » (section 3) est directement inspirée de la GPL-3.0, section 10 (« You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License »). Elle interdit les restrictions contractuelles, techniques (DRM, access controls) ou conditionnelles sur les informations correspondantes du modèle. C’est un garde-fou contre l’open-washing : publier les poids sous licence libre tout en rendant les informations d’entraînement inaccessibles via des conditions d’utilisation restrictives. Elle peut être redondante avec certaines licences Open Source contenant déjà ces type de clause.

Suite et roadmap du projet

Cette proposition est volontairement publiée comme un draft 1.0 : 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, 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-Exception à 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épasse cette attente ;
• 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 Exception 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 (NomdelaLicence WITH Nomdelexception, par ex. GPL-3.0 WITH AI Model Component Exception).

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.