Implications juridiques liées au développement assisté par l’IA des logiciels Open Source

Dans l'article précédent de cette série, nous avons évoqué la manière dont l'IA commence à transformer les méthodes de développement des logiciels. Dans la suite de cet article, nous nous concentrons sur certains des principaux problèmes juridiques (ou quasi-juridiques) que les développeurs Open Source eux-mêmes ont soulevés concernant le développement assisté par l'IA. 

Le présent document ne constitue pas un aperçu exhaustif de toutes les questions juridiques liées à l'IA. Nous n'abordons pas, par exemple, les préoccupations des clients concernant la conformité avec les réglementations en matière d'IA ni les questions de responsabilité liées aux contrats des produits basés sur l'IA. Nous nous concentrons plutôt sur les questions qui sont activement débattues au sein des communautés Open Source. 

Nos points de vue sur ces questions reflètent notre engagement envers une utilisation responsable des technologies d'IA et notre philosophie d'« ouverture par défaut ». Nous sommes convaincus que des approches collaboratives et transparentes constituent un moyen efficace d'aborder ces préoccupations de manière constructive.

Attribution et marquage 

L'attribution est une norme juridique et culturelle essentielle dans l'Open Source. Les licences exigent généralement que vous préserviez les avis de droits d'auteur et de paternité, et que vous évitiez les revendications de paternité trompeuses. 

Le développement assisté par IA complique cette situation. Puisque les systèmes d'IA ne sont pas considérés comme des « auteurs » au sens de la loi sur les droits d'auteur, il n'y a techniquement personne à créditer. Toutefois, il serait trompeur pour un développeur de présenter un contenu substantiel généré par l'IA comme étant son propre travail. 

C'est pour cette raison qu'un nombre croissant de projets Open Source adoptent des règles de divulgation pour les contributions assistées par l'IA, en s'inspirant de normes de divulgation utilisées dans d'autres domaines, comme l'étiquetage des supports synthétiques. Le « marquage » des contributions contribue à préserver la clarté juridique et la confiance de la communauté, et facilite l'évaluation du code par les relecteurs dans son contexte.

Nous soutenons le marquage, mais nous pensons qu'il ne doit pas être excessivement normatif. Les utilisations relativement anodines de l'IA (comme la saisie automatique d'un nom de variable ou la suggestion d'une docstring) ne devraient pas nécessiter de divulgation. Pour des usages plus significatifs, le marquage peut consister en un simple commentaire de code source, une note dans une demande de fusion ou un pied de commit tel que Assisted-by: (d'autres options utilisées par certains projets incluent Generated-by: et Co-authored by:).  

Formalités relatives aux droits d'auteur et aux licences

Aussi importante que puisse être l'attribution, l'Open Source dépend encore plus fortement de l'octroi de licences claires. Cette situation soulève une question pratique : comment les avis de licence doivent-ils fonctionner lorsqu'une contribution comprend du matériel généré par l'IA non protégé par des droits d'auteur ?

Dans la plupart des cas, lorsque des avis de licence existent déjà dans un référentiel ou un fichier source individuel, rien ne devrait changer. En raison de la nature hautement fonctionnelle du code, les fichiers sources se composent généralement d'un mélange de matériel protégé par les droits d'auteur et de matériel qui ne l'est pas. Les octrois de licences Open Source s'appliquent uniquement aux parties protégées par les droits d'auteur. Pour les contributions substantielles générées par l'IA, la divulgation par le marquage complète les avis de licence existants et représente un moyen efficace d'éviter d'induire quiconque en erreur. 

Le cas se complexifie lorsqu'un fichier source entier, ou même un référentiel complet, est généré par l'IA. Dans ce cas, l'ajout d'un avis de droits d'auteur et de licence peut s'avérer inapproprié, tant que les contributions humaines n'ont pas transformé le fichier en une œuvre protégeable par les droits d'auteur. Toutefois, étant donné la norme selon laquelle les référentiels Open Source devraient inclure un fichier LICENSE global, il est raisonnable d'ajouter une licence Open Source ultra-permissive courante (par exemple, l'Unlicense) comme licence globale d'un référentiel généré par l'IA, même si techniquement de telles licences présupposent l'existence de droits d'auteur. Au fur et à mesure que des contributions humaines sont ajoutées, les responsables de la maintenance peuvent revoir ce choix de licence initial ; en raison de l'absence de contributeurs humains précédents, ce processus sera plus simple que le scénario classique d'une modification de licence pour un projet Open Source. Nous nous attendons à ce que les pratiques évoluent avec les changements législatifs et l'expérience accrue de la communauté concernant les outils d'IA.  

Les outils d'IA sont-ils des « machines à plagiat » ? 

Certains développeurs Open Source se montrent sceptiques, voire hostiles, à l'égard du développement assisté par l'IA, accusant les modèles d'IA d'être des « machines à plagiat » ou des mécanismes de « blanchiment des droits d'auteur ». 

Cette préoccupation se décline en deux versions. La première est d'ordre pratique : un outil d'IA pourrait insérer discrètement des extraits de code propriétaire (ou incompatible avec les licences) dans un projet Open Source, créant potentiellement un risque juridique pour les responsables de la maintenance et les utilisateurs. La seconde préoccupation est plus vaste et plus philosophique : les grands modèles de langage, entraînés sur de vastes quantités de logiciels Open Source, s'approprient essentiellement le travail de la communauté, produisant des résultats dépourvus des obligations requises par les licences Open Source.   

Nous estimons que ces préoccupations méritent d'être prises au sérieux. Il est vrai que les grands modèles de langage sont capables, dans certains cas, d'émettre des extraits non négligeables de leurs données d'entraînement. Si cela constituait un comportement fréquent ou inévitable, ce serait une raison valable d'éviter complètement l'utilisation de ces outils. 

Cependant, les preuves suggèrent le contraire. Lorsque GitHub Copilot a été lancé, des allégations largement médiatisées ont affirmé que ses suggestions étaient copiées de projets Open Source. Lorsque ces allégations étaient fondées, elles impliquaient généralement des efforts délibérés pour inciter l'outil à reproduire du code connu à l'identique, ce qui ne constitue pas une utilisation courante. Depuis lors, nous n'avons pas constaté de preuves crédibles selon lesquelles les outils de développement d'IA couramment utilisés répliquent systématiquement des portions de données d'entraînement suffisamment substantielles pour soulever des préoccupations en matière de droits d'auteur.

L'idée fausse qui sous-tend une grande partie du discours sur la « machine à plagiat » est que les modèles d'IA générative ne sont qu'une forme de compression avec perte de leurs données d'entraînement. En réalité, le comportement habituel des modèles consiste à générer des textes originaux basés sur les schémas statistiques qu'ils ont appris. Le fait qu'ils soient entraînés sur du code Open Source ne signifie pas que leur production soit une reproduction de ce code. 

Cela dit, la possibilité de réplication occasionnelle ne saurait être ignorée. Les développeurs qui utilisent des outils d'IA devraient rester attentifs à ce risque et considérer les résultats générés par l'IA comme un élément à examiner avec le même soin que toute autre contribution. Lorsque les outils de développement d'IA offrent la fonctionnalité de détecter ou de signaler des suggestions étendues qui correspondent à du code Open Source existant, ces fonctionnalités devraient être activées. Associées aux pratiques de divulgation et à une surveillance humaine, ces étapes constituent un moyen pratique d'atténuer les préoccupations liées à la réplication, sans considérer toute utilisation de l'IA comme intrinsèquement compromise. 

Contributions assistées par l'IA et le DCO

Les projets qui utilisent le Certificat d'origine du développeur (DCO) ont soulevé des préoccupations particulières concernant les contributions assistées par l'IA. Le DCO, que nous recommandons depuis longtemps comme pratique exemplaire de développement Open Source, exige des contributeurs qu'ils certifient avoir le droit de soumettre leur travail sous la licence du projet. Certains développeurs soutiennent que, étant donné que les résultats des outils d'IA peuvent inclure des éléments inconnus ou non divulgués, personne ne peut légitimement apposer sa signature DCO pour le code assisté par l'IA. Cette approche a conduit certains projets utilisant le DCO à interdire complètement les contributions assistées par l'IA. 

Nous comprenons cette préoccupation, mais le DCO n'a jamais été interprété comme exigeant que chaque ligne d'une contribution soit l'expression créative personnelle du contributeur ou d'un autre développeur humain. De nombreuses contributions contiennent du matériel courant non protégé par des droits d'auteur, et les développeurs les valident néanmoins. Le véritable enjeu du DCO réside dans la responsabilité. Le contributeur estime avoir le droit d'utiliser sa contribution dans une œuvre régie (pour ses éléments protégés par les droits d'auteur) par une licence Open Source particulière. Les responsables de la maintenance du projet peuvent raisonnablement s'attendre à ce que le contributeur ait effectué une diligence raisonnable pour cette certification. Grâce à la divulgation, à l'attention humaine et à la supervision (appuyées si possible par des outils qui vérifient la similitude du code), les contributions assistées par l'IA peuvent être pleinement compatibles avec l'esprit du DCO.

Tout cela ne signifie toutefois pas que les projets sont tenus d'autoriser les contributions assistées par l'IA. Chaque projet est en droit d'établir ses propres règles et de déterminer son niveau de confort. Si un projet décide d'interdire les contributions assistées par l'IA pour l'instant, cette décision mérite d’être respectée. Les projets qui choisissent cette voie devraient reconnaître que les préoccupations qu'ils expriment ne sont ni nouvelles ni propres à l'IA. Pendant des années, les utilisateurs commerciaux d'Open Source, soucieux des risques, se sont inquiétés du « code blanchi » : des contributions dissimulant du matériel protégé par des droits d'auteur sous des conditions problématiques et non divulguées. Au fil du temps, ces craintes se sont avérées infondées. Il n'est pas impossible qu'une contribution assistée par l'IA contienne du matériel protégé par des droits d'auteur non divulgué. Cependant, l'expérience suggère que ce risque est gérable et qu'il n'est pas fondamentalement différent des défis auxquels l'Open Source a été confronté par le passé. 

En d'autres termes, le DCO peut demeurer ce qu'il a toujours été : un outil pratique et efficace pour maintenir la confiance et la clarté juridique dans le développement Open Source, même à l'ère de l'IA.

Établir la confiance

La question de la confiance est au cœur de la plupart des discussions sur l'IA dans le développement logiciel, qu'elles soient juridiques, techniques ou éthiques. La confiance représente un enjeu humain fondamental, essentiel à la réussite de tout projet Open Source. L'introduction de l'IA dans le développement Open Source soulève de nouvelles questions de confiance à plusieurs niveaux : la confiance que les contributeurs utilisent l'IA de manière responsable, que ceux qui le font ne sont pas stigmatisés, et que les entreprises qui développent et encouragent l'utilisation de l'IA agissent dans l'intérêt public. Il est également essentiel de reconnaître que ces entreprises, dont Red Hat, ont un intérêt commercial dans la réussite de l'IA, et que cela fait partie intégrante de la transparence concernant leur rôle dans cette transformation numérique.

Le défi d'établir la confiance dans la technologie n'est pas nouveau. La conférence fondamentale de 1984 de Ken Thompson, intitulée « Reflections on Trusting Trust », demeure une référence essentielle pour comprendre à quel point le jugement humain et l'intégrité institutionnelle sous-tendent le logiciel lui-même. L'IA remet ces concepts en évidence. La confiance doit toujours se mériter par des actions cohérentes et visibles. Chez Red Hat, nous valorisons la confiance établie avec les communautés en amont. Nous sommes convaincus que notre modèle de développement Open Source, fondé sur la transparence, la collaboration et la responsabilité, demeure un moyen efficace de la préserver tandis que nous abordons ensemble l'avenir de l'IA et de l'Open Source.

Perspectives d'avenir

Les enjeux abordés ici (le marquage, les avis de licence, les préoccupations liées à la réplication des données d'entraînement et le DCO) représentent les questions juridiques qui préoccupent particulièrement les développeurs Open Source. Avec la divulgation de l'utilisation de l'IA, la supervision humaine et le respect des règles des projets, le développement assisté par l'IA peut être concilié avec les fondements juridiques et les valeurs culturelles de l'Open Source. Nous encourageons la collaboration dans les projets en amont autour de ces approches (et d’autres) visant à équilibrer ces différents intérêts. Chaque projet devrait être libre de faire ses propres choix. Les communautés Open Source seraient plus solides si elles s'attaquaient elles-mêmes à ces défis, plutôt que de rester passives.