Open Source et IA : de quoi parle-t-on vraiment ?

Le recours à l’intelligence artificielle (IA) soulève des enjeux juridiques, éthiques et sociétaux majeurs, auxquels les législateurs tentent de répondre par de nouveaux cadres réglementaires. L’Union européenne s’est dotée du Règlement (UE) 2024/1689 sur l’Intelligence Artificielle (RIA) (ci-après « RIA » ou « AI Act »), qui accorde un régime dérogatoire aux systèmes d’IA Open Source, mais avec des limitations qui révèlent une interprétation étroite de ce qu’est l’« Open Source » en matière d’IA.

Autour de la série de trois articles « Open Source et IA », inno3 propose une analyse du RIA, de son impact sur l’écosystème Open Source aboutissant à des pistes d’actions à implémenter.

• Dans le premier article « Open Source et IA : les apports du Règlement sur l’Intelligence Artificielle européen« , il s’agissait de donner quelques repères clefs sur la place de l’Open Source dans ce Règlement autour des modèles d’IA à usage général (GPAI) et des systèmes d’IA.
• Dans le deuxième article « Open Source et IA : trois règlements européens, trois logiques et un écosystème », l’objectif était de replacer le RIA dans un contexte plus large d’un ensemble de régulations européennes (NLPD, CRA, etc.) et d’analyser leurs impacts sur l’écosystème Open Source européen et dans ses dynamiques internationales.
• Dans ce dernier article « Open Source et IA : de quoi parle-t-on vraiment ? », il s’agit d’une part de revenir sur les différentes définitions à l’œuvre sur une IA « open », leurs points de divergence et d’autre part de proposer des pistes d’actions à implémenter.

Ce qu’il faut retenir

Le terme « IA open source » recouvre des réalités parfois divergentes. Trois approches coexistent aujourd’hui : une approche régulatoire (l’Europe du RIA), une approche « principes » (l’OSI avec OSAID), et une approche industrielle (la Linux Foundation avec le Model Openness Framework). Ces divergences ne sont pas des maladresses : elles reflètent des objectifs distincts (réguler, préserver, innover) qui expliquent pourquoi les définitions ne convergent pas. Comprendre pourquoi ces définitions existent (régulation, transparence, collaboration technique et légale) est la clé pour repositionner le débat. Au-delà des licences, la question de la gouvernance des systèmes d’IA ouverts et l’analogie avec le droit sui generis des bases de données (ODbL) ouvrent des voies prometteuses.

Il a une signification précise lorsque l’on utilise l’adjectif « Open » sur des créations numériques (artefact). En effet, le terme Open associé à chacun de ces objets a une signification précise (matérialisé dans une définition dédiée) et une licence qui permet de matérialiser un partage à la fois d’un point de vue technique (l’objet numérique) et juridique (quant aux droits détenus par les organisations et personnes impliquées).

Ces définitions ont évolué d’année en année pour s’assurer notamment d’absence de mécanismes (juridiques ou techniques) qui permettraient de reprendre d’une main ce qui est accordé de l’autre : absence de brevets, partage des clés de chiffrement, absence de DRM, etc. . Cette notion s’applique au logiciel (Open source), aux données (Open Data), au contenu (Open Content), au matériel (Open Source Hardware) — et, potentiellement, aux modèles d’IA si on les considère comme des artefacts distincts. Pour une analyse historique de la construction de ces mécanismes juridiques, voir « L’évolution des licences libres et open source : critères, finalités et complétude ? » (B. Jean, in Histoires et cultures du libre, Framabook, 2013).

Mais « ouvert » s’applique aussi à des dynamiques : l’Open Science, l’Open Access, l’Open Innovation désignent moins des objets que des manières de s’organiser : partager l’infrastructure, l’IP, ouvrir les flux, repenser la gouvernance, etc. Ces dynamiques ne se réduisent pas à la somme des licences appliquées aux artefacts qu’elles mobilisent : elles supposent des choix collectifs sur qui contribue, qui décide, qui bénéficie. Elles amènent à un changement de posture des acteurs pour collectivement dépasser les limites de ce que la somme des intérêts individuels peut engendrer.

Lorsque l’on parle d’« Intelligence Artificielle » sans définir les termes, on touche généralement aux deux :

• On peut considérer un système d’IA comme la somme de ses composantes (code, données, poids, pipeline) chacune relevant d’un régime juridique distinct. C’est à peu près l’approche du Règlement européen sur l’IA (RIA) lorsqu’il parle globalement du « Système d’IA ».
• On peut aussi penser une dynamique d’IA ouverte (une « Open IA ») : qui serait un mouvement qui interroge plus largement la manière dont les acteurs s’organisent, partagent les ressources de calcul, construisent ensemble. Cette seconde vision (proche des échanges de Commons AI) invite, à l’image de l’Open Science, à repenser les infrastructures, les flux sous-jacents et les conditions d’une véritable collaboration.

Les définitions existantes de l’« IA open source » ont eu du mal à converger parce qu’elles tentent d’accommoder des préoccupations qui opèrent à des niveaux différents : travailler ensemble (partage technique et juridique), montrer la transparence (enjeux éthiques), et réguler (obligations versus exemptions pour l’innovation).

Cet article, dernier de notre série sur l’IA, l’Open Source et le RIA, tente de démêler ces niveaux pour comprendre pourquoi les définitions divergent, pourquoi c’est normal, et donner quelques propositions d’actions.

Trois définitions, trois objectifs : pourquoi les définitions divergent

L’Europe : réguler les modèles et les systèmes

L’Europe a été précurseure en matière de régulation de l’IA. La notion européenne d’IA open source distingue :

• Les systèmes d’IA publiés dans le cadre de licences libres et ouvertes, en précisant qu’un système d’IA est défini comme « un système automatisé qui est conçu pour fonctionner à différents niveaux d’autonomie et peut faire preuve d’une capacité d’adaptation après son déploiement, et qui, pour des objectifs explicites ou implicites, déduit, à partir des entrées qu’il reçoit, la manière de générer des sorties telles que des prédictions, du contenu, des recommandations ou des décisions qui peuvent influencer les environnements physiques ou virtuels » (article 3.1) ;
• Les modèles d’IA à usage général (article 53§2) « mis à disposition au titre d’une licence libre et « open source » qui permet l’accès, l’utilisation, la modification et la diffusion du modèle, et dont les paramètres, y compris les pondérations, les informations relatives à l’architecture du modèle et les informations relatives à l’utilisation du modèle, sont rendus accessibles au public ».

Le cadrage est utile, mais crée une incertitude, car 1) les textes ne définissent pas ce que sont les « licences libres et ouvertes » (ou encore Open Source) et que 2) les définitions existantes pour les licences Open Source ne permettent pas de couvrir les objets concernés — soit des ensembles d’artefacts (comme le Système d’IA) soit des modèles (mais alors sans considération de ce qui fait la spécificité d’un modèle).

S’ajoute à cela que le RIA s’inscrit dans une régulation plus large incluant le Règlement sur la cyber-résilience (CRA) et la Directive sur la responsabilité des produits défectueux (NPLD) qui contiennent chacun une exception Open Source, avec leur propre logique et une articulation pas tout le temps évidente pour qui souhaiterait naviguer dans les exceptions de l’Open Source dans la régulation européenne. Cela s’explique par les finalités inhérentes à ces exceptions pour l’Open Source, qui s’avèrent tout à fait louables mais pas nécessairement suffisamment explicites (voir l’article dédié).

Ce travail de définition est louable, mais voué à un objectif régulatoire : déterminer qui est exempté d’obligations et qui ne l’est pas — et non à qualifier ce qui est ouvert ou non. Ainsi, la licence associée au modèle ou à l’ensemble des constituantes d’un système est certainement un point central dans le bénéfice de cette exception, mais qui s’ajoute à d’autres contraintes (le champ communautaire, l’absence d’activités commerciales, etc.) qui sont nécessaires pour justifier cette régulation à l’aune de finalité globale telle que la libre concurrence ou encore les enjeux de transparence ou et de souveraineté. Pour une analyse approfondie du RIA, consultez notre l’article dédié ainsi que les réflexions proches au sein du Guide CRA.

L’OSI (OSAID) : préserver les principes face au détournement

Après près de 12 mois d’échanges et de dialogues, l’Open Source Initiative a réagi en 2024 en adoptant l’OSAID 1.0 (Open Source AI Definition), avec l’objectif explicite de défendre les principes de l’Open Source face au détournement industriel. L’OSAID réaffirme les quatre libertés fondamentales : utiliser librement, étudier le fonctionnement, modifier et partager. Mais contrairement à la définition OSI classique (qui ne couvre que le logiciel), l’OSAID va plus loin : elle intègre la documentation technique, les données minimales nécessaires, et l’accès aux outils de modification.

Étant « finalisée », l’OSAID est plus proche de la Définition de Logiciel Libre (FSF) qu’à la Définition Open Source classique (OSI). Elle reconnaît que les licences seules ne suffisent pas : on peut distribuer un logiciel GPL sans la source, ou publier les poids d’un modèle sans les données d’entraînement, ce qui vide les libertés de leur substance. Cela explique pourquoi l’OSAID exige, par exemple, que des « informations suffisamment détaillées sur les données utilisées pour entraîner le système » soient disponibles – sans aller jusqu’à exiger l’accès aux données elles-mêmes, un compromis vivement critiqué par la FSF et Bradley Kuhn qui y voient une concession vidant les libertés de leur substance (voir notre article « Comment l’IA interroge et réinvente l’Open Source ») .

C’est une approche réactive : comme le montre l’histoire de l’évolution des licences libres, le mouvement n’a jamais été créé pour plaire aux acteurs dominants, mais pour proposer une voie alternative plus respectueuse de nos libertés. Il ne faut donc pas s’étonner si les licences vont plus loin que ce que les géants de la tech acceptent. Cette tension est historique. Rappelez-vous les débats sur l’Open Access : pendant des années, le lobbying industriel a assuré qu’aucune position n’était trop forte — une approche graduée qui a empêché le changement réel. La même dynamique est à l’œuvre avec l’IA ouverte. La définition originale de l’Open Source avait émergée en s’appuyant sur des entreprises qui souhaitaient faire émerger un modèle alternatif au modèle dominant, c’est peut être aussi vers ce type d’acteur qu’il faut se tourner pour faire évoluer ce travail normatif.

Pour une critique argumentée de l’OSAID, voir le billet de Bradley Kuhn (du SFC), ou la présentation de Carlo Piana lors d’EOLE 2024.

La Linux Foundation (MOF) : un consensus industriel

La Linux Foundation a proposé le Model Openness Framework (MOF) (avril 2024, six mois avant l’OSAID, ce qui montre aussi les rapports de force), qui reflète la position de ses membres (les géants du numérique qui poussent aujourd’hui l’IA, nous sommes loin des acteurs alternatifs). Le MOF utilise une approche en matrice avec 17 composantes évaluées sur 3 niveaux :

• Class III (Open Model, le minimum),
• Class II (Open Tooling, incluant le code d’entraînement et d’inférence)
• Class I (Open Science, le plus exigeant, incluant les jeux de données brutes).

Cela signifie que sous le MOF, un modèle peut être qualifié d’« ouvert » (Class III) en ne publiant que les poids et l’architecture, sans code d’entraînement ni données. À cet égard, le MOF se veut pragmatique : il reconnaît que publier intégralement est coûteux et complexe. De ce fait, il sert aussi à légitimer une vision minimale de l’ouverture (les poids ouverts, c’est « assez » ouvert). Cette approche reflète les intérêts de ses sponsors : elle permet à Microsoft, Google, Meta de dire « nous sommes ouverts » en publiant les poids de Llama ou Mistral, tout en gardant le secret sur les données, les scripts d’entraînement, voire le code lui-même. Voir l’analyse de l’Ada Lovelace Institute sur ce point.

Ces trois approches ne sont pas les seules. La FSF adopte une position maximaliste : pour qu’une application d’apprentissage machine soit libre, le code d’entraînement et les données doivent être libres (position que l’OSAID elle-même n’a pas reprise). Aux États-Unis, le rapport du NTIA (juillet 2024) a introduit la catégorie intermédiaire de « modèles à poids ouverts » (open-weight models), reconnaissant une réalité que les définitions binaires peinent à saisir. Enfin, les licences RAIL (Responsible AI Licenses), nées du projet BigScience/BLOOM et aujourd’hui utilisées par des dizaines de milliers de modèles sur HuggingFace, explorent une voie distincte : ouverte mais avec restrictions d’usage : ce qui, pour l’OSI comme pour la FSF, est contraire aux définitions de l’Open Source ou du Logiciel Libre qui ne tolèrent aucune discrimination. Ces positions illustrent que le paysage est plus fragmenté encore que les trois pôles principaux ne le laissent penser (le sujet dépasse d’ailleurs la seule questions des modèles d’IA, voir le rapport de Ramya Chandrasekhar autour de l’explosion de licences pour encadrer les données face à l’IA).

Décomposer l’ouverture : ce que recouvre (ou non) l’« IA open source »

Il y a plusieurs questions à se poser pour savoir quoi protéger (et, incidemment, comment protéger).

Les modèles ouverts, de quoi parle t on ?

En droit français, un système d’IA pourrait être rapproché de celui d’une « œuvre complexe » telles que les jeux vidéos. Une œuvre complexe est composée de plusieurs éléments protégeables indépendamment : code (logiciel), textes et images (droits d’auteur), musique (droits musicaux), données structurées (droit sui generis des bases de données), etc. En pratique, il est nécessaire de protéger cet actif au travers de régimes cumulatifs : chaque élément obéit à son propre régime, avec ses propres droits et obligations. Il n’y a donc pas une licence pour l’ensemble, mais une multitude de licences, ce qui, lorsque l’on regarde notamment l’émulation qui suit la diffusion Open Source des moteurs de jeux vidéos, peut permettre de construire des stratégies de propriété intellectuelle relativement vertueuses.

Dans le même esprit, il semble possible de considérer qu’il n’est pas possible d’avoir une seule licence pour le système d’IA entier, mais qu’il est au contraire nécessaire de penser une architecture de licences qui reflète l’architecture technique et juridique du système. Le code peut être sous GPL, les données sous ODbL, les poids sous une licence spécifique, la documentation sous CC BY-SA. Chaque licence couvre son domaine, sauf le modèle qui fait réellement figure de parent pauvre. À cela faudrait il ajouter aussi les agents IA (systèmes autonomes construits sur le modèle), qui s’apparentent plus à des services tiers disponibles via API ( à ce sujet, voir le projet API ToS).

Dans le même esprit, le modèle d’IA (si on souhaite pouvoir le reconstruire) résulte lui-même d’un assemblage de composantes : code (frameworks, scripts d’entraînement), données (corpus d’entraînement), poids (paramètres du modèle), pipeline (orchestration, validation, déploiement). La majorité de ces éléments a son propre régime juridique : logiciel libre pour le code, Open Data pour les données, Open Content pour le contenu — mais rien ne semble tout à fait adapté au modèles (et notamment les poids liés à leur entraînement et paramétrage). Au mieux faudrait il considérer le modèle lui-même comme un assemblage de composants (du code, des données, des poids et une documentation complètes), mais avec le risque de ne pas saisir la subtilité de ce qui fait le modèle (son apprentissage) et qui n’est pas constitutif d’un droit en soit.

Consultez le rapport du NTIA sur les modèles de poids ouverts pour une analyse détaillée.

L’open-washing : un risque documenté

En l’absence de définition claire, le risque d’« open-washing » (prétendre être ouvert tout en l’étant minimalement) est bien réel. Les chiffres sont éloquents : selon une analyse de Osborne, Ding et Kirk, 64,67 % des modèles sur HuggingFace n’ont pas de licence ou sont sous une licence restrictive. LLaMA et Mistral sont souvent décrits comme « Open Source », mais incluent des « Acceptable Use Policies » restrictives qui rapprochent davantage leur statut de celui d’un freeware que d’une licence Open Source.

En réalité, très peu de modèles satisfont même à des critères minimums (Pythia, OLMo, T5). Cela pose un problème régulateur : en définissant l’IA open source très largement (comme le RIA le fait), l’Europe crée (involontairement) une incitation à l’open-washing. Si vous pouvez appeler votre modèle « ouvert » simplement en respectant la licence formellement, vous le ferez, même si vous gardez secret le reste. L’Observatoire Open Future a documenté ce phénomène et propose un suivi continu. Voir aussi l’étude Liesenfeld & Dingemanse (FAccT 2024) qui montre, sur 45 systèmes d’IA générative, comment les déclarations d’ouverture sont souvent exagérées.

Plus encore et au niveau de l’artefact, « Open AI » (comme dynamique, non comme objet) signifie quelque chose de plus important : il s’agit de repenser comment les acteurs s’organisent, similairement à la manière dont la Science ouverte repense l’infrastructure, les flux de données, la gouvernance. Cela inclut la question de qui contrôle l’accès, comment on décide des itérations, comment on gère les contributions. C’est alors un changement de paradigme : de la transparence du code à la gouvernance de l’écosystème. Si on pense à la défense des intérêts des usagers et de notre écosystème, le modèle seul ne suffit plus, c’est la communauté et le système qui comptent.

Ce que les licences peuvent (et ne peuvent pas) saisir

Le principe des licences Open Source est simple : s’appuyer sur un (ou plusieurs) droit(s) de propriété intellectuelle afin de contractualiser avec l’ensemble des utilisateurs (licenciés) un ensemble de conditions et de modalités juridico-techniques qui favorise la confiance et la collaboration.

La qualification juridique des modèles d’IA

Une licence présuppose un droit de propriété sur son objet. Si le logiciel peut s’appuyer sur le droit d’auteur, il n’y a rien à ce jour d’identique pour un modèle d’IA. Les poids s’apparentent plus à une configuration ou optimisation et ne tombent clairement sous aucune catégorie juridique établie : ce ne sont pas du logiciel (pas réellement du code), ce ne sont pas des données structurées au sens classique (la structure n’est pas visible de l’extérieur), ce ne sont pas non plus des œuvres artistiques ou littéraires au sens traditionnel. Nous sommes dans une zone grise juridique, mais plusieurs approches théoriques aux implications assez immédiates semble pouvoir se dessiner :

• considérer les modèles avec leurs poids comme une base de données et appliquer le droit sui generis bases de données. Les enjeux économiques de l’entrainement des modèles rappellent la création même du droitsui generis des bases de données qui permet de reconnaître un monopole (limité) lié à l’investissement substantiel ayant emmené à la conception de la base. L’intérêt d’une telle interprétation serait que des licences telle que l’ODbL (Open Database License) pourraient être relativement adaptées (cf infra);
• créer un régime sui generis (càd spécifique) pour les modèles d’IA (comme l’Intellectual Property Owners Association (2020) le proposait en 2020), ce qui repose sur un consensus international compliqué à anticiper en cette période d’instabilité ;
• étendre le droit d’auteur aux modèles entraînés (position moins probable, car contraire aux critères attendus d’originalité qui s’apprécie à l’aune de l’empreinte de la personnalité des auteurs — nous en sommes très loin) ;
• utiliser une approche hybride combinant plusieurs régimes comme évoqué précédemment, avec le risque de ne pas saisir la spécificité des modèles.

Pour des analyses juridiques approfondies, voir les travaux de Sousa e Silva ou encore l’étude du Parlement européen (2025).

La piste ODbL et le droit sui generis des bases de données

Face à cette zone grise juridique, il est intéressant de réfléchir aux modèles d’IA protégés par le droit sui generis des bases de données, et utiliser l’ODbL (Open Database License) pour cette protection. L’ODbL a déjà fait ses preuves : la migration d’OpenStreetMap de CC BY-SA vers l’ODbL a montré tant les limites des licences de contenu appliquées aux bases de données que la pertinence d’un instrument spécifique fondé sur le droit sui generis. Cette solution serait par ailleurs complémentaire à l’usage qui est fait de l’ODbL sur certaines bases de données d’entraînement, permettant d’harmoniser le régime des bases de données d’entraînement et celui des modèles (ou a minima des poids associés).

L’ODbL s’appuie (notamment) sur le droit sui generis des bases de données et distingue deux situations :

• les Produced Works (œuvres produites à partir de la base : un rapport, une carte, une analyse), l’obligation est limitée à l’attribution : indiquer que les données proviennent de la base d’origine.
• Pour les Derivative Databases (bases de données dérivées : comme une version modifiée ou enrichie de la base originale), l’ODbL impose en plus un copyleft : la base dérivée doit être partagée sous les mêmes conditions. Cette distinction est fondamentale pour comprendre les deux lectures possibles appliquées à l’IA.

À ce titre, le modèle d’IA pourrait être :

• le « created work » (création produite) créée à partir des données d’entraînement. L’ODbL exigerait alors : (1) d’indiquer les données utilisées (obligation de transparence), et (2) de permettre le partage des données améliorées. Cela signifie que publier les poids d’un modèle, c’est accepter que les données améliorées soient partageables. C’est une obligation de transparence transformée en obligation contractuelle de la licence, plutôt que régulatoire. C’est déjà significatif : cela imposerait une traçabilité des données d’entraînement comme obligation de licence, non seulement comme obligation légale.
• et/ou une base de données dérivée (c’est un « database » au sens large de l’ODbL) créée à partir des données d’entraînement. L’ODbL s’étendrait alors au modèle lui-même, exigeant que le modèle soit partagé sous les mêmes termes. C’est copyleft pour les bases de données, étendu aux modèles.

Cette approche est particulièrement intéressante parce qu’elle crée des obligations similaires au copyleft SANS avoir besoin de prouver que le modèle est une « œuvre dérivée » au sens du droit d’auteur. Le droit sui generis des bases de données a ses propres critères (investissement substantiel, extraction), plus faciles à appliquer. Cela signifie que vous pourriez avoir une obligation copyleft via l’ODbL même si le droit d’auteur ne reconnaît pas le modèle comme dérivé. La limite de cette solution est d’une part culturelle et d’autre part juridique : le droit sui generis des bases de données n’existant à ce jour qu’en Europe. Néanmoins cette voie de valorisation des modèles entraînés mériterait d’être étudiées plus finement.

Une obligation spécifique aux modèles dans les licences Open Source

Une option complémentaire, qui permettrait de rapprocher ces réflexions à celles de l’Open Source, serait d’évaluer la possibilité d’étendre les licences Open Source actuelles pour s’assurer qu’elles aient des effets sur les modèles d’IA intégrés au code. Cette démarche reprendrait des logiques que l’on connaît déjà vis-à-vis d’autres situations techniques ou juridiques qui ont été traitées directement dans les licences Open Source, sans aller à l’encontre des définitions de l’Open Source (OSD) ou du Logiciel Libre (FSF). Cela en phase avec des pratiques actuelles :

• La GPL-3.0 a été conçue pour répondre au problème du « tivoization » (distribuer un matériel verrouillé qui empêche l’exercice des libertés du logiciel libre — voir l’analyse détaillée de ce mécanisme et de ses précédents) et l’AGPL-3.0 a répondu à l’ASP Loophole (faille des logiciels libres utilisés en SaaS). Le même problème surgit avec l’IA : distribuer les poids sans les données d’entraînement ou les scripts d’entraînement, c’est comme distribuer un binaire sans la source. Les utilisateurs ont un produit, mais pas la capacité réelle à modifier ou adapter. Il serait ainsi nécessaire d’assurer a minima toutes les informations qui permettent de comprendre et de modifier le modèle — cela rejoint l’analogie qui circule dans la communauté Open Source, considérant que les poids sont le « object code » du modèle, tandis que les données et les scripts d’entraînement sont le « source code » (voir les travaux d’Andrew Marble sur le copyright des poids).
• De même, la licence LGPL impose, lorsque vous intégrez une bibliothèque logicielle dans une application qui n’est pas Open Source, que vous fournissiez l’ensemble des informations qui permettent de s’interfacer avec la bibliothèque, d’user de ses fonctions, de recombiner l’application avec une version modifiée de la bibliothèque (LGPLv3, section 4). L’idée est de ne pas pouvoir verrouiller l’accès à la partie libre. Cette logique pourrait être étendue en matière de modèle : si vous utilisez un framework d’entraînement libre pour produire un modèle, vous n’êtes pas tenu d’ouvrir le modèle lui-même ni l’intégralité des données (mais vous devez fournir les informations d’interface qui permettent de reproduire, adapter ou affiner le modèle. C’est l’équivalent, pour l’IA, de ce que la LGPL appelle le « Corresponding Application Code ») non pas la totalité de l’œuvre, mais ce qui est nécessaire pour que les libertés sur la partie libre restent effectivement exerçables.

Cette démarche reposerait sur l’ajout d’une exception au sein des licences actuelles (ce qui peut être fait par l’ajout de l’exception à la racine du programme et l’ajout d’une mention spécifique dans la documentation du projet et ses métadonnées). La licence de logiciel contiendrait une clause exigeant que si une partie du logiciel intègre un modèle d’IA, alors toutes les informations nécessaires pour adapter ou réentraîner le modèle doivent être partagées. Cela reste dans le champ de la licence logicielle tout en garantissant l’exercice pratique des libertés. Ainsi, cette approche est donc :

• Un peu moins radicale que la position de la Free Software Foundation 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 (position officielle, voire aussi l’article de la Software Freedom Conservancy « FOSS in, FOSS out, FOSS throughout »).
• Peut être plus fluide aussi que le « Contextual Copyleft » (Shanklin, Hine, Novelli et al.) qui serait propose une démarche dépendant du type de modèle et de son usage (mais qui potentiellement imposerait de couvrir plus que le logiciel qui est l’objet de la licence, ce qui pourrait être considéré comme contraire à l’OSD qui stipule qu’une licence ne peut pas « s’étendre » à d’autres œuvres).

Ce type d’usage permettrait aussi de lever l’ambiguïté pour les 16 millions de fichiers GPL/AGPL trouvés dans les datasets d’entraînement (arxiv 2403.15230). Aujourd’hui, aucune cour n’a encore jugé si les poids constituent une « œuvre dérivée » au sens du droit d’auteur. En intégrant l’obligation dans la licence logicielle elle-même, on contourne cette incertitude : l’obligation naît du contrat de licence, pas d’une qualification juridique pour laquelle le consensus ne se fera que dans un second temps.

Partant du principe que les poids d’un modèle d’IA intégrés dans un logiciel sont fonctionnellement équivalents à du code objet, il faudrait que le code source d’un logiciel contenant un composant de modèle d’IA inclut les informations nécessaires à la modification de ce composant (comme il doit inclure le code source de tout autre partie du programme).

Voir l’article dédié avec la proposition d’une « AI model component exception« .

La question des données d’entraînement

Beaucoup d’acteurs de l’IA refuse aujourd’hui de publier les données d’entraînement au regard du risque d’action en contrefaçon que cela pourrait engendrait. Cette affirmation est partiellement hypocrite : ne pas publier les données pour ce motif, c’est avouer une violation. La Loi Darcos (votée au Sénat, avril 2026) et le rapport du Parlement européen (mars 2026) pointent vers une « présomption d’usage » qui favorisera les actions en contrefaçon. Rappelons qu’il y a deux cas légitimes pour demander le partage des données :

• La régulation (le RIA exige de la traçabilité et de l’auditabilité, donc les données doivent être accessibles pour la conformité) ;
• Les contraintes contractuelles telles que les licences dites copyleft : si le modèle en amont exige que les données soient libres (via ODbL ou autre), alors le non partage est une violation de la licence (l’obligation est induite par la volonté de ne pas être contrefacteur).

En dehors de ces deux cas, la publication intégrale n’est ni réaliste (vie privée, santé, volume, secret des affaires) ni nécessaire.

Ainsi et sauf à ce que le législateur considère qu’une exception au droit d’auteur puisse se justifier dans ce cas précis, il conviendrait plutôt de questionner l’obligation que souhaite imposer le législateur dans le cadre du RIA afin de la traduire précisément plutôt que de renvoyer à des licences et des mouvements Open Source qui vont potentiellement exiger des contraintes plus importantes. Cela permettrait de ne mélange pas le ce qui est de l’ordre de la transparence (pour le RIA) et de l’Open Source (pour les communautés qui souhaitent pouvoir modifier et contribuer).

Consultez le projet Common Pile d’EleutherAI, et la présentation de Marco Ciurcina lors d’EOLE 2024 sur les exceptions open source dans le RIA.

Conclusion (vers une gouvernance de l’IA ouverte)

Les trois grandes approches définitionnelles explorées (régulatoire (Europe), principes (OSI), industrielle (LF)) reflètent des objectifs légitimes qui ne doivent pas se concurrencer.

Les licences fonctionnent bien pour les artefacts individuels (du code, des données) mais elles saisissent encore mal les enjeux autour des modèles (mêmes si des solutions semblent pouvoir émerger). Plusieurs pistes émergent :

• L’approche ODbL/sui generis : en considérant les modèles comme des bases de données protégées par le droit spécifique des bases de données, l’ODbL offre un cadre robuste pour imposer des obligations sans extension problématique de droits.
• L’ajout d’une obligation relative aux modèles dans les licences Open Source pourrait aussi permettre de rapprocher le respecte les limites du droit tout en garantissant que les libertés restent substantielles (voir l’article dédié).

Au-delà de ces outils juridiques, nous avons besoin d’une réflexion plus large sur la gouvernance de l’IA ouverte. Les licences sont nécessaires, mais insuffisantes car elles ne saisissent pas les dynamiques au niveau du système. Comment gouverne-t-on un modèle partagé ? Qui décide des itérations ? Comment les contributions sont-elles gérées ? Comment évite-t-on que l’ouverture des poids renforce plutôt que réduise les asymétries de pouvoir entre les géants et les communautés ? Ce sont des questions de gouvernance, pas de licences.

Comment créer des structures qui permettent une véritable collaboration et une véritable participation ? Comment éviter la concentration du pouvoir autour de quelques fournisseurs « open » de modèles ? Ces questions ont été explorées dans notre article « Comment l’IA interroge et réinvente l’Open Source ». travail autour de la conférence Commons AI (session gouvernance), et elles resteront centrales dans les années à venir.

La prochaine édition de la conférence Commons AI sera une occasion de discuter ces enjeux et les projets sous-jacents. L’IA ouverte n’est pas qu’une question de licences, c’est une question de pouvoir et de gouvernance collective.

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.

---