QEMU définit une politique interdisant « l’utilisation de générateurs de code IA »

• La communauté QEMU a récemment modifié sa politique. L’utilisation de générateurs de code IA (par ex. Copilot, ChatGPT, etc.) ainsi que la soumission de code via ces outils sont interdites

define policy forbidding use of AI code generators

• L’intérêt pour l’utilisation de générateurs de code IA a récemment fortement augmenté, mais l’interprétation de la licence de leurs productions n’est pas largement acceptée dans l’industrie
• Les principaux fournisseurs affirment qu’il n’y a pas de problème et qu’il est possible de choisir librement une licence, mais ils sont en situation de conflit d’intérêts
• Comme les générateurs de code IA sont conçus à partir de données d’entraînement issues de licences variées, aucun consensus n’existe encore dans l’industrie sur les questions de licence des productions
• QEMU exige, via le DCO (Developer Certificate of Origin), que les contributeurs disposent clairement du droit de contribuer leur code au titre de la licence du projet
  • Il est explicitement indiqué que, dans le cas d’un code utilisant un générateur de code IA, il est difficile de démontrer le respect des clauses b/c du DCO
  • QEMU introduit donc une politique selon laquelle si l’utilisation d’un générateur de code IA est clairement établie ou soupçonnée, la contribution de code au projet QEMU ne sera pas autorisée

Souplesse de la politique et gestion des exceptions

• Le développement logiciel assisté par IA en est encore à ses débuts, et il est probable que les questions juridiques soient résolues à l’avenir
• À mesure que les outils progressent, certains pourront probablement être utilisés en toute sécurité dans des projets open source à l’avenir
• Pour l’instant, une politique stricte et prudente est appliquée en priorité, avec une possible évolution si nécessaire par la suite
• Les demandes d’exception seront examinées au cas par cas afin de décider de leur acceptation

[GN⁺]

Avis Hacker News

• L’open source et le logiciel libre se sentent particulièrement vulnérables si le code généré par IA est considéré comme une œuvre contrefaisante ou, à l’inverse, comme relevant du domaine public. S’il devient nécessaire de distinguer les modifications faites par l’IA de celles faites par des humains, les projets risquent d’être paralysés pendant des années par des problèmes juridiques, sans avoir les moyens de financer les procès. Si du code produit par IA est ensuite modifié par des humains ou intégré à du code existant, la question est aussi de savoir si ces modifications humaines ultérieures peuvent être considérées comme des œuvres dérivées dépassant le cadre du fair use. Si le code généré par IA est jugé relever du domaine public, les projets dont seule une partie du code source est couverte par une licence open source/logiciel libre perdront brutalement des moyens d’action forts contre les entreprises qui abusent de ces licences. Il faudrait alors démontrer jusqu’au fait que le contrevenant a utilisé du code écrit par un humain, donc effectivement soumis à licence. À l’inverse, les logiciels propriétaires seraient relativement moins touchés. Pour soutenir qu’un code généré par IA constitue une reprise non autorisée, il faudrait au final que quelqu’un désassemble les binaires de l’entreprise pour les comparer au code d’origine, et beaucoup de logiciels propriétaires mélangent déjà du code relevant du domaine public
  • La licence MIT pourrait même, au contraire, tirer bénéfice de cette situation
  • En tant que développeur expérimenté, je comprends tout à fait pourquoi beaucoup ne veulent pas voir des « développeurs » sans connaissances contribuer du code IA au hasard. Examiner ligne par ligne du code IA produit par des humains mobiliserait déjà des années de travail, même en dehors des questions juridiques. Premièrement, il n’existera probablement presque aucun moyen concret de vérifier qu’un code a été généré par IA. Deuxièmement, un logiciel développé à 100 % par des humains sera clairement moins compétitif à l’avenir qu’un projet assisté ou écrit par IA. La seule objection possible serait un effondrement de niveau apocalyptique où les humains ne pourraient plus produire en masse ni semi-conducteurs ni électricité. Troisièmement, même si un projet parvenait à exclure totalement les contributions de code IA — ce qui semble déjà incertain — il suffirait qu’un petit groupe anti-IA contribue, puis quelqu’un recopierait le code, en retirerait seulement les parties juridiquement risquées, et lancerait un nouveau projet. Si la licence autorise les forks, il pourrait simplement être forké tel quel, mais il est aussi possible qu’un nettoyage après copie soit préféré. L’open source a encore de la route devant lui, et les logiciels du futur vont exploser en quantité ; même si 99 % seront médiocres, il y aura aussi davantage de logiciels vraiment précieux
  • En partageant un article récent de news.artnet.com sur la position du Copyright Office américain à propos de l’art généré par IA, ainsi que le wiki sur la décision du selfie du singe, il est dit que cette discussion est déjà entrée dans une voie sans retour
  • Si un logiciel est du vrai open source très permissif au sens de « faites absolument ce que vous voulez avec ce code, cela nous est égal », alors il n’y a absolument rien à craindre de l’IA
• Cela donne clairement l’impression d’une position plus dure que la politique de LLVM. On peut voir les détails dans la politique des développeurs LLVM. En tant que vieux développeur à l’ancienne, je ne veux absolument pas me retrouver à relire du code que son auteur ne comprend pas, et que moi non plus je ne comprends pas
  • Devoir relire du code que son auteur lui-même ne comprend pas est vraiment insupportable. En pratique, quelqu’un m’a déjà demandé de faire une tâche en me relayant l’explication qu’il avait obtenue d’une IA, du style « apparemment, il faut faire comme ça ». Franchement, il vaudrait bien mieux dire simplement « fais-le s’il te plaît ». Je trouve ça presque insultant
  • J’ai commencé à ajouter une DCO (Developer Certificate of Origin) à tous les projets open source que je maintiens, et je vais insérer dans CONTRIBUTING.md la politique suivante sur les contributions de code via LLM

  ---

  LLM-Generated Contribution Policy
  La bibliothèque Color est remplie de mathématiques complexes et de décisions subtiles. Chaque issue ou PR doit être rédigée à partir d’une compréhension approfondie par son auteur, et pour les PR en particulier, le développeur doit attester une DCO pour chaque commit. Si une PR a été rédigée avec l’aide d’un LLM, cela doit être explicitement indiqué dans le message de commit et dans la PR. Si une aide d’un LLM est détectée sans preuve déclarative, la PR sera rejetée. Tout contenu généré par LLM soumis sans relecture sera systématiquement rejeté

  Dans SECURITY.md, j’ai aussi l’intention d’ajouter une LLM-Generated Security Report Policy, selon laquelle aucun signalement de sécurité généré par LLM ne sera accepté

  En tant que personne seule responsable du projet, j’essaie de garder un équilibre, mais personnellement je n’apprécie pas les contributions de code via LLM
  • Dans mes projets personnels, j’utilise GitHub Copilot. Mais je ne l’utilise que comme un « autocompléteur intelligent », rien de plus. Je n’accepte une suggestion que si elle est suffisamment proche du code que j’allais taper de toute façon. Grâce à ça, je comprends mon code à 100 %, et j’évite aussi bien les bugs dus à l’inattention que les polémiques de copyright. Utilisé de cette manière, Copilot accélère vraiment le développement. Ce n’est pas tant parce que je tape lentement, mais parce que je me laisse souvent distraire ou que je m’ennuie. Copilot me permet de passer plus vite à l’étape suivante de réflexion ou de debug.
    J’ai du mal à imaginer que quelqu’un puisse soumettre une PR sans même comprendre son propre code. Cela me frustre un peu que, à cause de ces politiques, même mon usage du LLM au niveau de l’autocomplétion puisse être restreint à cause de personnes comme ça.
    J’aimerais bien confier à Copilot des tâches de refactoring automatique, mais à chaque essai cela casse tout dans la plupart des cas, et comme il régénère souvent des blocs entiers, je finis par perdre plus de temps qu’en le faisant moi-même.
    Ce qui est amusant, c’est que si je suis en train d’introduire un bug pendant que je tape, Copilot a souvent tendance à compléter ce bug lui aussi. Il autocomplète même des erreurs de contexte évidentes, comme des fautes de frappe dans les noms de variables
  • Quand j’utilise un LLM pour coder, c’est par exemple pour lui demander « transforme ce YAML en structures, et extrais les motifs répétitifs dans des variables ». On peut faire cela avec des outils déterministes, mais l’IA le fait proprement en 30 secondes, et il est facile de tester que le résultat est identique à l’entrée
    Je ne peux absolument pas lui confier mon travail de haut niveau, mais pour des tâches répétitives et peu critiques, l’IA me fait gagner du temps. Par exemple, si je donne à Claude Code un fichier CSV de résultats de benchmark de base de données et que je lui demande de relier différents graphiques et analyses d’outliers, il boucle rapidement un travail conceptuellement simple mais long à cause de la recherche de bibliothèques ou de la mise en place de l’environnement
  • Je comprends parfaitement l’idée de ne pas vouloir relire du code si son auteur ne le comprend pas lui-même. Mais avec une bonne guidance par un humain expérimenté, les outils d’IA peuvent aussi produire du code de niveau assez avancé. Et ils deviennent plus puissants tous les quelques mois ; il arrive déjà souvent qu’ils produisent un résultat sur simple instruction en langage naturel
    Je réfléchis à ce que veut dire « comprendre » du code. Un de mes projets consiste à ajouter complètement un nouveau backend de stockage à un système existant d’orchestration de VM. Comme je ne connais pas le code existant et que je n’ai pas vraiment le temps de tout implémenter moi-même, je construis tout de même un cluster de test et je fais tourner divers scénarios, ce qui me donne une compréhension suffisante de la vue d’ensemble du point de vue conception et tests
    Moi aussi, en tant que mainteneur open source, j’imagine très bien à quel point les PR pleines de « slop » LLM de mauvaise qualité peuvent être stressantes. Au final, que l’auteur comprenne ou non son code, le mainteneur doit de toute façon le relire.
    À l’avenir, il faudra sans doute trouver des moyens d’utiliser correctement ces outils et de signaler aux autres développeurs le niveau de qualité du code soumis. Ce que m’a appris un bug subtil trouvé dans les premiers portages de ZFS sur Linux, c’est qu’un test rigoureux est extrêmement important, autant qu’une relecture et une écriture ligne par ligne par des humains
• Ce que j’avais prédit dans mon billet « yes i will judge you for using AI » devient réalité. L’open source s’est traditionnellement beaucoup appuyé sur des signaux implicites de compétence des contributeurs, et les LLM permettent désormais à des gens sans aucune expérience de produire un code qui a l’air compétent. Pour les personnes expérimentées, c’est un choc vraiment déstabilisant. À l’avenir, des formes de preuve sociale sans rapport avec les PR elles-mêmes — réunions virtuelles ou en présentiel, par exemple — deviendront probablement de plus en plus nécessaires pour entrer dans les grands projets
  • Nous vivons aussi ce phénomène en entreprise. Des collègues génèrent des commentaires de revue de code avec des LLM et, comme le niveau semble très élevé, on se laisse berner un instant. Résultat, on passe énormément de temps à vérifier si le commentaire est correct, et au final j’y dépense bien plus d’énergie que la personne qui a juste fait un copier-coller
  • Demande le lien du blog
• Cette politique semble être surtout portée par des signataires liés à Red Hat. Red Hat est une entreprise très sérieuse et très orientée corporate. Leur inquiétude n’est probablement pas tant « qui peut détenir le copyright d’un contenu généré par IA ? » que le fait qu’un morceau de code d’un autre projet, absorbé pendant l’entraînement, ressorte sans le vouloir. La plupart des hyperviseurs sont en source fermée, et beaucoup d’entreprises aiment les procès
  • Si le risque, c’est que l’IA recrache tel quel du « code d’un autre projet » présent dans ses données d’entraînement, alors j’ai l’impression que c’est un problème qui s’applique à pratiquement tout le code généré par IA
  • Les modèles de langage présentent aussi souvent un risque accru d’introduire des erreurs logiques subtiles, pouvant aller jusqu’à franchir les frontières de sécurité d’un hyperviseur. Les utilisateurs qui s’appuient beaucoup sur l’IA sont souvent moins préparés à détecter ce genre d’erreurs, ce qui les rend encore plus dangereux
• On remarque que ce sont surtout des gens de Red Hat, désormais racheté par IBM, qui ont signé cette politique. IBM a créé Watson et a même gagné à Jeopardy! en 2011. On peut donc se demander si le discours selon lequel le développement logiciel par IA « n’en est qu’à ses débuts » est vraiment sincère, ou s’il s’agit d’un nouvel épisode du style destructeur des acquisitions à la IBM.
  Dotnet Runtime, de son côté, adopte l’IA de manière très proactive. On peut s’en moquer de l’extérieur, mais il faut noter que d’excellents ingénieurs comme Stephen Toub et David Fowler la soutiennent.
  Aux entreprises, je conseillerais de chercher un partenaire vraiment tourné vers l’avenir la prochaine fois qu’IBM viendra leur vendre des services IA.
  En tant que personne originaire de Caroline du Nord, j’espère que IBM et Red Hat prendront la bonne direction
• Je me demande si la motivation est vraiment juridique. Certains projets semblent simplement épuisés par les revues de code médiocre généré par IA
  • QEMU est un logiciel absolument central dans l’industrie. Il est utilisé partout : VM de bureau, cloud, serveurs de build, sandbox de sécurité, environnements multiplateformes, etc. Le moindre risque juridique peut avoir des effets sérieux sur l’ensemble du secteur
  • La politique est claire et limitée. Elle semble insister sur le fait qu’on ne peut pas attribuer en toute sécurité le copyright d’un code généré de manière algorithmique. Le mot « algorithmique » paraît volontairement choisi. La politique actuelle semble aller dans ce sens, et le principe « nous commençons aujourd’hui de la manière la plus stricte et la plus sûre, puis nous assouplirons plus tard » paraît raisonnable dès le départ. Il s’agit certes aussi de refuser la fameuse « masse de slop », mais la stratégie semble d’abord viser à clarifier le risque juridique et l’attribution. Je trouve cela bien meilleur que la politique de curl
  • Alerte en prenant l’exemple de Monsanto, connu pour appliquer de manière agressive ses droits sur les semences
  • Honnêtement, je ne sais pas quel sera l’effet de l’IA sur la qualité du code de niveau intermédiaire, mais les humains produisent eux aussi majoritairement du code inutile. S’il y a trop de commits et que cela devient ingérable, peut-être que les projets auront besoin d’équipes de triage dédiées. Je pense que la plupart des contributions sont faites de bonne foi.
    Je comprends ceux qui évitent l’IA à cause du risque juridique, mais je me demande aussi si certains ne s’inquiètent pas trop. Ceux qui croient avoir réellement réduit une possibilité à zéro n’ont probablement pas encore assez réfléchi
  • Si cette tendance continue, l’open source pourrait se dégrader. Le copier-coller de code devient trop facile, et le temps nécessaire pour tout examiner et rejeter est énorme. Davantage de projets pourraient finir par ressembler au modèle Android : n’importe qui peut télécharger le code source, mais il devient presque impossible pour un externe de réellement contribuer
• J’aimerais qu’on distingue l’usage d’un LLM dans l’IDE comme outil d’autocomplétion intelligent, et les cas où on lui donne des instructions de haut niveau pour générer massivement du code entier. J’admets qu’il y a une zone grise, mais j’aimerais qu’une autocomplétion de type Copilot puisse être utilisée sans risque de copyright. Par exemple, pour écrire une série de case, Copilot peut détecter le motif et réduire énormément la saisie
  • Plus encore, j’imagine un avenir où l’IA deviendrait comme des lunettes, une extension de ma pensée et de mon corps. De la même manière que des lunettes corrigent la vue, des lunettes intelligentes pourraient aussi assister la pensée.
    Mon cerveau aussi a appris à partir de beaucoup de code source fermé, et je pointe le fait que le débat occidental sur le copyright autour de l’IA ressemble à une forme de NIMBY. À force de rejeter des technologies formidables au nom de ces hypothèses juridiques, on pourrait finir par faire s’effondrer la civilisation occidentale elle-même
• Je comprends pourquoi une telle politique apparaît, mais je pense que c’est une erreur. Sur l’IA et le copyright, le cadre juridique reste flou et il y a très peu de législation.
  Indépendamment d’une interdiction des contributions IA, je pense qu’il faudrait au contraire définir clairement des zones où l’IA est autorisée. Par exemple, la configuration de la CI de QEMU n’est pas un domaine central pour la sécurité. Pour des contributions portant sur de nouveaux cas de test ou environnements intéressants, il serait tout à fait possible d’autoriser l’IA sous certaines conditions
  • Je me demande quel serait le risque si cette politique n’était pas appliquée. Le code serait peut-être un peu plus lent à arriver, mais meilleur, et pour un projet aussi important que QEMU, cela vaut sans doute la peine d’accepter ce niveau de prudence. Les auteurs ne semblent pas tant hostiles à la GenAI elle-même qu’attentifs au fait qu’une fois certaines choses enclenchées, il devient impossible de revenir en arrière
  • La solution la plus simple est probablement d’attendre que la situation juridique se clarifie. La quasi-totalité du code de QEMU est sous GPL 2.0 ; si du code GenAI y était introduit à tort et qu’une décision de justice imposait ensuite de respecter la licence du code d’origine, cela créerait une charge de rollback et de gestion pour tout l’écosystème downstream. Même si l’on étiquetait dès le départ certaines parties comme « IA, réutilisation interdite », la question d’une réécriture totale pourrait subsister plus tard.
    Au final, « on n’en accepte pas pour l’instant » reste le choix le moins complexe et le moins dramatique pour tout le monde
    Sont joints comme références la licence de QEMU et la liste des licences non libres
  • Ce n’est pas un débat juridique destiné à durer des décennies : il y a déjà des dizaines de procédures en cours, et des jurisprudences devraient apparaître dans les prochaines années. QEMU a très bien progressé pendant 22 ans sans IA, donc attendre encore quelques années n’a rien de dramatique
  • Il faut bien lire à la fois la forme et le fond de cette politique. Toute action comporte un risque juridique, mais les multinationales mondiales les assument souvent quand même. QEMU n’est pas spécialement à part ; on peut lire cette position comme le fait qu’ils ne veulent tout simplement pas de code LLM. La séquence « demandez à un avocat → il y a un risque juridique → donc on ne peut pas l’utiliser » sert surtout à tuer le débat. C’est exactement le même schéma qu’en entreprise
  • Il existe dans l’industrie informatique une vieille convention : « on ne plagie pas le code ». Même pour du code très court, et même si cela pourrait relever juridiquement du fair use, la culture veut qu’on ne copie pas le code source d’origine
• Le principe « commencer strict et prudent, puis assouplir progressivement » paraît vraiment raisonnable
  Mais je me demande s’il existe un moyen pratique de distinguer du code généré par IA d’un code simplement recopié quelque part par un humain. Dans l’open source, comme tout le monde peut contribuer, les humains sont eux aussi influencés par d’autres sources de code
  De mon point de vue actuel, le code généré par IA n’a pas tant une identité indépendante qu’il n’est un outil de plus entre les mains d’un humain
  • Une analogie proposée : « le code généré par IA, c’est comme une scie électrique très puissante tenue par un humain ». C’est un outil puissant, donc potentiellement dangereux juste après l’humain lui-même.
    Et l’auteur trouve que même cette analogie a déjà été trop tirée en longueur
• En pratique, ce genre de politique me semble totalement impossible à faire respecter. Zed, Cursor, VS Code : tous les éditeurs proposent de l’autocomplétion basée sur l’IA, et il est totalement impossible de distinguer le code que j’ai tapé de celui suggéré par l’IA.
  C’est un peu comme si je dessinais un bonhomme bâton puis qu’on me disait : « tu n’as peut-être pas le droit de soumettre ce dessin, car il pourrait copier le bonhomme bâton de quelqu’un d’autre »
  Le vrai but de cette politique semble surtout être de se ménager une excuse pour le jour où quelqu’un soumettra malgré tout quelque chose mélangé à du code IA : on pourra alors dire « on n’y pouvait rien ». J’ai du mal à croire que ses rédacteurs ignorent eux-mêmes à quel point elle est vide de sens
  • Ce genre de politique vise surtout à disposer d’un alibi évident du type « si un code suspect au regard de la politique est soumis, nous non plus n’y pouvons rien ». Les messages de commit et patchs contiennent d’ailleurs aussi l’idée que « les questions de licence autour des générateurs de code ne sont pas encore juridiquement stabilisées ».
    Au-delà des enjeux juridiques, il existe clairement aussi beaucoup d’autres problèmes liés à l’usage de code IA
  • Neovim n’impose pas l’IA. Il faut l’activer soi-même. Si un éditeur ne permettait pas de désactiver l’IA, alors ce serait l’éditeur lui-même qui poserait un grave problème