1 réponse à ce sujet

[Furyoisivie]

Bonjour à tous ! 
Ce post fait echo au dernier post de Mike sur l'IA : https://www.robot-ma...en-pensez-vous/
 
L'open source a toujours reposé sur un pacte tout simple : je partage mon code, mais sous une licence qui pose des règles. GPL, MIT, Apache, LGPL… peu importe : tu réutilises, à condition de respecter le contrat (attribution, partage à l'identique, mention de la licence, etc.). C'est ce contrat, et la confiance qui va avec, qui fait tenir tout l'édifice depuis 30 ans.
Sauf que l'IA générative est venue mettre un sacré coup de pied dedans. Et je ne parle pas d'un débat théorique : ça se joue déjà devant les tribunaux.
 
Les gros modèles de génération de code ont avalé des milliards de lignes publiées sur GitHub et ailleurs, dont énormément de code copyleft. Le modèle « digère » tout ça et te ressort des fonctions… sans licence, sans attribution, sans qu'on sache d'où ça vient.
C'est exactement le cœur de l'affaire Doe v. GitHub, lancée fin 2022 contre GitHub, Microsoft et OpenAI à propos de Copilot. Le juge a écarté les principales accusations de violation pure du droit d'auteur, faute de preuve que Copilot recrachait du code identique ligne pour ligne. Mais, et c'est là que ça devient intéressant pour nous, il a laissé vivre la plainte pour rupture de contrat et violation de licence open source, en acceptant de traiter une licence open source comme un contrat contraignant. Autrement dit : même si ce n'est pas du « copier-coller », ignorer les conditions d'une licence pourrait suffire à se faire condamner. L'affaire est aujourd'hui remontée devant la cour d'appel du 9e circuit, avec des plaidoiries tenues en février 2026. La réponse qui en sortira concerne potentiellement chacun d'entre nous qui publie du code. (l'article dont je parle : https://yanglawoffices.com/github-copilot-open-source-licensing-for-developers-and-startups/)
 
Deuxième front, plus sournois. Face à l'IA, la définition même d'open source est devenue floue, au point que l'Open Source Initiative a dû publier fin 2024 une « Open Source AI Definition » pour tenter de clarifier. Elle exige notamment un accès réel aux informations sur les données d'entraînement.
Et là, surprise : la plupart des modèles présentés comme « open source » ne passent pas le test. Le cas d'école, c'est Llama de Meta, que tout le monde appelle « open source ». Sauf que sa licence restreint l'usage commercial au-delà d'un certain nombre d'utilisateurs, ne donne pas accès aux données d'entraînement, et impose même des blocages géographiques. On appelle ça de l'open washing : récupérer l'image sympa de l'open source sans en jouer les règles. Un peu comme certenne start du showbuiss qui ont prennent le jet pour faire 200km mais qui font des campagne contre le réchauffement climatique parce que quand meme c'est important la planete et le développement durable... D'où la distinction qui monte partout aujourd'hui entre « open weights » et « open source ». Ce n'est pas la même chose, et l'amalgame arrange bien certains.

Le paradoxe qui me gène vraiment : l'open source, inventé pour rendre le savoir libre et partagé, sert aujourd'hui de matière première gratuite à des modèles souvent fermés et propriétaires. On donne, ils encaissent, et ils ne rendent pas forcément. Le communisme du code au service du capitalisme de l'IA, en quelque sorte...

Je pense qu'il y a aussi une vraie bonne nouvelle. L'IA abaisse énormément la barrière d'entrée : elle aide à comprendre un projet inconnu, à le documenter, à corriger un bug, à contribuer à des dépôts qu'on n'aurait jamais osé toucher. Pour un projet open source qui manque de contributeurs, c'est peut-être une chance autant qu'une menace. Sans compter que l'IA permet à des débutants de se lancer et, à terme, de nourrir à leur tour la communauté. D'ailleurs ! On voit émerger des clauses « no AI training » dans certaines licences, des dépôts qui se ferment, des devs qui quittent carrément GitHub. Est-ce la bonne réponse… ou juste une manière de saborder l'esprit d'ouverture qui a fait la force du libre ? 
Il y a pas longtemps j'ai survolé cet article (https://www.termscor...-agency-clients) au début il m'avait semblé intéressant, mais je me pose quand même la question de la valeur juridique réelle de ce type de clause, notamment dans le contexte français ou européen.
Je me demande également comment une telle clause pourrait être concrètement appliquée. Supposons qu'une personne accuse une entreprise d'avoir utilisé son code pour entraîner un LLM : comment peut-elle réellement le démontrer ?
 
Le problème est que le fonctionnement d'un LLM rend la preuve particulièrement complexe. Une fois le modèle entraîné, le code source n'est évidemment pas stocké sous la même forme dans le modèle : il a contribué à modifier les paramètres du réseau, et on se retrouve avec des milliards de paramètres numériques plutôt qu'avec une copie identifiable du fichier source. Il n'est donc pas forcément possible de faire un simple rapprochement entre le code original et le modèle entraîné.
On peut comparer ça à une pincée de farine dans une pâte à crêpes : une fois mélangée et transformée, il devient extrêmement difficile de démontrer qu'une farine précise provenait de telle ou telle source. La farine a bien contribué au résultat final, mais le résultat ne permet pas nécessairement de remonter jusqu'à la pincée d'origine.

Cela pose alors une vraie difficulté probatoire : si l'entreprise ne joue pas le jeu, comment démontrer qu'elle a effectivement utilisé ce code dans son jeu de données d'entraînement ? Elle pourrait simplement nier l'utilisation, et il serait extrêmement difficile pour le freelance d'obtenir la totalité des données ayant servi à entraîner le modèle, notamment s'il s'agit d'un modèle propriétaire.
À mon sens, la question essentielle n'est donc pas seulement « est-ce qu'une clause interdisant l'entraînement d'un modèle est juridiquement valable ? », mais plutôt : « comment cette clause peut-elle être effectivement opposée et prouvée en cas de litige ? »
C'est là que je trouve que l'article est un peu léger : il explique assez bien comment interdire contractuellement l'utilisation des données, mais beaucoup moins comment établir la violation de cette interdiction lorsqu'on n'a pas accès au pipeline d'entraînement, aux datasets ou aux logs internes de l'entreprise.
Et finalement, c'est peut-être là que se trouve le vrai problème : une interdiction peut être parfaitement écrite sur le papier, mais si personne n'est capable de démontrer qu'elle a été violée, quelle est réellement son efficacité ?
Curieux d'avoir vos avis, notamment si certains ici ont des connaissances en droit, en propriété intellectuelle, en IA ou ont déjà été confrontés à ce genre de situation.


Cette vidéo est un peu moins directement liée au sujet, mais je la trouve intéressante car elle permet de bien synthétiser le cadre juridique européen autour de l’IA, et notamment les différentes obligations qui commencent à s’appliquer aux acteurs développant ou utilisant ces systèmes.

 
Et vous, qu'en pensez-vous ?
Vous continuez à publier vos projets (code, STEP, schémas KiCad…) sans arrière-pensée, ou vous commencez à faire attention à ce que vous exposez ?
Une licence open source a-t-elle encore un sens si personne ne peut vérifier ce qui entre dans un modèle ?
On va vers un open source « à la carte », avec des clauses anti-entraînement, et est-ce que ça reste encore de l'open source ?
Et pour les makers et roboticiens ici : ça change quoi concrètement à votre manière de partager vos projets ?

[Mike118]

Sujet fort intéressant !

L'open source, c'est formidable et ça a permis de construire énormément de choses grâce au partage des connaissances. Mais je pense qu'il y a une réalité assez terre-à-terre derrière tout ça : mettre une licence sur quelque chose ne signifie pas forcément qu'on a réellement les moyens de la faire respecter.

Finalement, quand on publie quelque chose sur Internet, je vois presque trois grandes possibilités :

• soit on l'ouvre réellement et il faut accepter qu'en pratique on perde une bonne partie du contrôle sur ce qui va en être fait ;
• soit on considère que ce qu'on développe a suffisamment de valeur pour ne pas vouloir que d'autres puissent le réutiliser, et dans ce cas la meilleure protection reste souvent tout simplement… de ne pas le publier et de conserver le secret ;
• soit on veut publier tout en gardant un contrôle fort sur son exploitation, mais il faut alors avoir les moyens juridiques et financiers de défendre ses droits : licences, contrats, brevets lorsque c'est applicable, avocats, etc.

Parce qu'entre avoir un droit et être capable de le faire respecter, il y a parfois un monde.

C'était déjà vrai avant l'IA. Si je publie un projet sous GPL et qu'une PME située à l'autre bout du monde récupère une partie de mon code, le modifie, l'intègre dans un produit commercial sans publier ses modifications et sans rien me dire, encore faut-il que je le découvre. Ensuite, il faut pouvoir le démontrer et éventuellement engager une procédure.

Avec l'IA, on pousse simplement ce problème beaucoup plus loin : non seulement il faut découvrir que son travail a été utilisé, mais il peut devenir extrêmement difficile de démontrer précisément comment il a été utilisé.

Et c'est là que je suis assez sceptique sur les clauses du type « No AI Training ». Je comprends parfaitement leur objectif, mais une fois mon code accessible publiquement, copié, forké, archivé, aspiré dans différents datasets puis éventuellement utilisé dans plusieurs étapes d'entraînement, comment puis-je réellement contrôler ce qu'il devient ?

Surtout : comment puis-je prouver quelques années plus tard que telle entreprise a utilisé précisément mon dépôt pour entraîner son modèle ?

Une clause peut être juridiquement très bien écrite, mais si la violation est quasiment impossible à détecter ou à prouver, sa protection pratique devient forcément limitée.

Il y a aussi quelque chose qui me gêne un peu dans certaines évolutions de la notion d'« open source ».

Pour moi, publier quelque chose tout en disant : « vous pouvez regarder le code, mais pas l'utiliser commercialement, pas l'utiliser pour entraîner une IA, pas faire ceci, pas faire cela… » devient progressivement de moins en moins open.

Ce n'est pas forcément mauvais ! Un auteur est parfaitement légitime à vouloir imposer des conditions à son travail. Mais peut-être faut-il simplement appeler les choses différemment.

C'est d'ailleurs pour cela que je trouve la distinction entre open source, source available et, pour les IA, open weights, de plus en plus importante.

Et il y a un autre aspect qui dépasse largement l'IA : une fois qu'une information est réellement publique, il est très difficile de la rendre à nouveau secrète.

C'est particulièrement parlant dans notre domaine. Si je publie les sources d'un programme, les fichiers KiCad d'une carte, les STEP d'une pièce mécanique et toute la documentation nécessaire pour fabriquer mon robot, je dois partir du principe que quelqu'un pourra probablement en faire une copie.

Je peux mettre un fichier LICENSE à côté, mais techniquement je viens quand même de donner à la planète entière les informations nécessaires pour reproduire mon travail.

La licence peut ensuite définir ce que les gens ont le droit d'en faire. Elle ne définit pas ce qu'ils vont réellement en faire.

Et je pense que cette distinction est fondamentale.

Personnellement, j'aurais donc tendance à raisonner davantage en amont : qu'est-ce que je suis réellement prêt à rendre public ?

Si je publie quelque chose en open source, j'accepte qu'une partie du contrôle m'échappe. Si au contraire un élément constitue un véritable avantage technologique ou commercial que je ne veux absolument pas voir repris, la solution la plus efficace est peut-être simplement de ne pas le publier.

Cela n'empêche évidemment pas d'utiliser une licence et de faire respecter ses droits lorsqu'on le peut.
Mais je pense qu'il ne faut pas considérer la licence comme une barrière technique : c'est avant tout une barrière juridique.

Finalement ce n'est même pas L'IA qui crée le problème, elle l'accentue seulement.
Elle rend simplement beaucoup plus visible une faiblesse qui existait déjà dans le modèle : l'open source fonctionne énormément grâce au respect volontaire des règles et à une certaine confiance entre les acteurs.

La question intéressante devient alors : jusqu'où peut-on ajouter des restrictions pour tenter de conserver ce contrôle avant que cela ne soit plus vraiment de l'open source ?

Et surtout, est-ce que vouloir empêcher les IA d'apprendre à partir de ce que nous avons volontairement rendu public ne nous oblige pas à redéfinir ce que nous entendons réellement par « ouvert » ?