QEMU definiert Richtlinie: „Nutzung von AI-Code-Generatoren verboten“

• Die QEMU-Community hat ihre Richtlinien kürzlich geändert. Die Nutzung von AI-Code-Generatoren (z. B. Copilot, ChatGPT usw.) sowie das Einreichen von mit diesen Tools erzeugtem Code sind verboten

define policy forbidding use of AI code generators

• Das Interesse an der Nutzung von AI-Code-Generatoren ist zuletzt stark gestiegen, doch die Lizenzrechtliche Einordnung ihrer Ausgaben ist in der Branche noch nicht breit akzeptiert
• Wichtige Anbieter behaupten, es gebe kein Problem und die Lizenz könne frei gewählt werden, doch bei ihnen besteht ein Interessenkonflikt
• Da AI-Code-Generatoren mit Daten trainiert werden, die unter verschiedenen Lizenzen stehen, fehlt weiterhin ein branchenweiter Konsens über die Lizenzprobleme der erzeugten Ausgaben
• QEMU verlangt im DCO (Developer Certificate of Origin), dass Mitwirkende eindeutig das Recht haben müssen, Code unter der Lizenz des Projekts beizutragen
  • Es wird ausdrücklich darauf hingewiesen, dass sich bei mit AI-Code-Generatoren erzeugtem Code die Einhaltung der DCO-Klauseln b/c nur schwer nachweisen lässt
  • Daher wurde eine Richtlinie eingeführt, nach der Codebeiträge zum QEMU-Projekt nicht zugelassen werden, wenn die Nutzung von AI-Code-Generatoren eindeutig ist oder vermutet wird

Flexibilität der Richtlinie und Ausnahmen

• AI-gestützte Softwareentwicklung befindet sich noch in einem frühen Stadium, sodass rechtliche Fragen künftig voraussichtlich geklärt werden
• Mit der Weiterentwicklung der Tools wird erwartet, dass einige Werkzeuge künftig in Open-Source-Projekten sicher einsetzbar sein werden
• Derzeit gilt zunächst eine strenge und sichere Richtlinie, die bei Bedarf später gelockert werden kann
• Ausnahmeanträge sollen einzeln geprüft werden, um über eine Zulassung zu entscheiden

[GN⁺]

Hacker-News-Kommentare

• Open Source und freie Software fühlen sich durch KI-generierten Code besonders verwundbar, falls dieser als urheberrechtsverletzendes Werk eingestuft oder als Public Domain betrachtet wird. Wenn man irgendwann zwischen KI-Bearbeitungen und menschlichen Bearbeitungen unterscheiden muss, könnten Projekte jahrelang in rechtlichen Problemen feststecken und hätten zudem nicht das Geld für Prozesse. Wenn von KI erzeugter Code später von Menschen verändert oder in bestehenden Code integriert wird, ist außerdem strittig, ob nachfolgende menschliche Bearbeitungen als abgeleitete Werke außerhalb von Fair Use gelten könnten. Falls KI-generierter Code als Public Domain eingestuft wird, hätten Projekte, bei denen nur Teile des Quellcodes unter Open-Source-/Free-Software-Lizenzen stehen, deutlich weniger Möglichkeiten, gegen Unternehmen vorzugehen, die Lizenzen missbräuchlich nutzen. Dann müsste man nämlich in erheblichem Umfang nachweisen, dass Lizenzverletzer tatsächlich von Menschen geschriebenen, also klar lizenzierten Code verwendet haben. Proprietäre Software wäre davon vergleichsweise weniger stark betroffen. Um dort zu behaupten, KI-generierter Code sei ein unzulässiges Zitat, müsste letztlich jemand die Binärdatei zerlegen und mit dem Originalcode vergleichen, und zudem ist in proprietärer Software ohnehin oft schon Public-Domain-Code enthalten
  • Ich denke, für die MIT-Lizenz ist diese Situation eher vorteilhaft
  • Als erfahrener Entwickler kann ich gut nachvollziehen, dass viele keine „Entwickler“ ohne Fachwissen wollen, die wahllos KI-Code beitragen. KI-Code Zeile für Zeile von Menschen prüfen zu lassen, würde unabhängig von der Rechtslage jahrelang Personal binden. Erstens wird es künftig wohl kaum praktikable Methoden geben, um verlässlich festzustellen, ob Code von KI erzeugt wurde. Zweitens wird Software, die wirklich zu 100 % nur von Menschen entwickelt wurde, gegenüber Projekten, die von KI unterstützt oder geschrieben werden, klar im Nachteil sein. Das einzige Gegenargument wäre ein Zusammenbruch auf apokalyptischem Niveau, bei dem Menschen nicht einmal mehr Halbleiter oder Strom in Massen produzieren können. Drittens: Selbst wenn ein Projekt KI-Code vollständig ausschließen könnte — was unklar ist — und selbst wenn nur eine kleine anti-KI-Minderheit beitragen würde, würde am Ende jemand den Code kopieren, die rechtlich riskanten Teile entfernen und zu einem neuen Projekt wechseln. Wenn die Lizenz Forks erlaubt, kann es direkt geforkt werden, aber vielleicht wird ein Kopieren und anschließendes Bereinigen sogar bevorzugt. Für Open Source gibt es weiterhin einen Weg nach vorn, und die Software der Zukunft wird mengenmäßig explodieren; 99 % davon mögen miserabel sein, aber es wird auch mehr wirklich wertvolle Software geben
  • Im Zusammenhang mit der KI-Urheberrechtsfrage werden ein aktueller Artikel auf news.artnet.com zur Position des US Copyright Office zu KI-Kunst und der Wikipedia-Artikel zum Monkey-Selfie-Urteil geteilt; dazu der Hinweis, dass diese Debatte bereits einen irreversiblen Punkt erreicht habe
  • Wenn Software wirklich radikal offen ist im Sinne von „Mach mit diesem Code, was du willst, uns ist das egal“, dann gibt es wegen KI überhaupt nichts zu befürchten
• Das wirkt auf mich klar härter als die LLVM-Politik. Details stehen in der LLVM-Entwicklerrichtlinie. Als alter Entwickler will ich auf keinen Fall Code reviewen, den weder der Autor noch ich selbst verstehe
  • Es ist wirklich unerquicklich, Code reviewen zu müssen, den nicht einmal der Autor selbst versteht. Tatsächlich passiert es, dass mich jemand um etwas bittet und mir dann die Erklärung weiterreicht, die er von einer KI bekommen hat, nach dem Motto: „So soll es wohl gehen.“ Ehrlich gesagt wäre ein simples „Bitte mach das“ viel besser. So wirkt es eher beleidigend
  • Ich habe begonnen, allen meinen Open-Source-Projekten ein DCO (Developer Certificate of Origin) hinzuzufügen, und plane, in CONTRIBUTING.md folgende Richtlinie für LLM-Codebeiträge aufzunehmen

  ---

  LLM-Generated Contribution Policy
  Die Color-Bibliothek ist eine Bibliothek voller komplexer Mathematik und subtiler Entscheidungen. Alle Issues und PRs müssen auf einem tiefen Verständnis der Einreichenden beruhen; insbesondere bei PRs müssen Entwickler für jeden Commit ein DCO bestätigen. Wenn ein PR mit Hilfe eines LLM erstellt wurde, muss dies sowohl in der Commit-Nachricht als auch im PR offengelegt werden. Wenn eine LLM-Unterstützung ohne Nachweis erkannt wird, wird der PR abgelehnt. Inhalte, die von einem LLM erstellt und ohne Review eingereicht werden, werden ausnahmslos abgelehnt

  Auch in SECURITY.md soll es als LLM-Generated Security Report Policy festgelegt werden, dass von LLM erzeugte Sicherheitsmeldungen grundsätzlich nicht angenommen werden

  Als jemand, der ein Projekt allein verantwortet, versuche ich, die Balance zu halten, aber persönlich mag ich LLM-Codebeiträge nicht
  • Ich nutze GitHub Copilot in privaten Projekten. Allerdings nur als „smarte Autovervollständigung“ und nicht anders. Erst wenn das, was vorgeschlagen wird, dem Code, den ich ohnehin tippen wollte, ausreichend ähnlich ist, übernehme ich es. So verstehe ich meinen Code weiterhin zu 100 %, und ich vermeide Bugs durch Fehler ebenso wie Urheberrechtsstreitigkeiten. Auf diese Weise beschleunigt Copilot die Entwicklung. Nicht weil ich langsam tippe, sondern weil ich mich oft in Nebengedanken verliere oder gelangweilt bin. Dank Copilot komme ich schneller zur nächsten Denk- oder Debugging-Phase.
    Ich kann mir kaum vorstellen, dass jemand einen PR einreicht, ohne den eigenen Code zu verstehen. Deshalb nervt es mich etwas, dass ich wegen solcher Leute möglicherweise sogar beim Einsatz von LLMs auf Autocomplete-Niveau eingeschränkt werde.
    Automatische Refactoring-Aufgaben würde ich Copilot gern überlassen, aber in meinen Tests macht es meist alles kaputt und erzeugt oft ganze neue Blöcke, sodass ich am Ende langsamer bin, als wenn ich es per Hand mache.
    Interessanterweise vervollständigt Copilot oft sogar denselben Bug, wenn ich gerade dabei bin, einen Fehler einzutippen. Es ergänzt sogar offensichtliche kontextuelle Fehler wie Tippfehler in Variablennamen
  • Wenn ich LLMs fürs Programmieren nutze, dann etwa für Anfragen wie: „Wandle diesen YAML-Inhalt in Strukturen um und ziehe wiederkehrende Muster in Variablen heraus.“ Das ließe sich auch mit deterministischen Werkzeugen erledigen, aber KI macht es in 30 Sekunden sauber, und es ist leicht zu testen, dass das Ergebnis dem Input entspricht
    Meine High-Level-Arbeit würde ich niemals einer KI überlassen, aber repetitive und weniger wichtige Aufgaben beschleunige ich damit. Wenn ich Claude Code etwa die CSV-Dateien mit Datenbank-Benchmark-Ergebnissen gebe und es bitte, verschiedene Diagramme samt Ausreißeranalyse zu verknüpfen, erledigt es schnell etwas, das konzeptionell einfach ist, aber viel Zeit kosten würde, weil man Bibliotheken finden und alles aufsetzen muss
  • Ich verstehe sehr gut die Haltung, keinen Code reviewen zu wollen, den der Autor selbst nicht versteht. Dennoch können KI-Werkzeuge mit richtiger Anleitung durch erfahrene Menschen ziemlich anspruchsvollen Code erzeugen. Sie werden alle paar Monate leistungsfähiger, und oft reichen natürliche Sprachbefehle schon aus
    Ich denke darüber nach, was „Code verstehen“ überhaupt bedeutet. In einem meiner Projekte integriere ich ein völlig neues Storage-Backend in ein bestehendes VM-Orchestrierungssystem. Ich kenne den vorhandenen Code nicht, habe auch kaum Zeit, alles selbst zu implementieren, aber ich baue Testcluster auf, lasse verschiedene Szenarien laufen und habe das Gesamtbild aus Design- und Testperspektive ausreichend im Blick
    Ich bin selbst Open-Source-Maintainer und kann mir gut vorstellen, wie stressig es ist, wenn minderwertige LLM-„Slop“-PRs hereinkommen. Am Ende müssen Maintainer den Code immer reviewen, egal ob der Autor ihn versteht oder nicht.
    Künftig muss man wohl Wege finden, solche Werkzeuge sinnvoll zu nutzen und gleichzeitig anderen Entwicklern zu signalisieren, welches Qualitätsniveau eingereichter Code hat. Eine Lehre aus subtilen Bugs im frühen Linux-ZFS-Port ist für mich, dass gründliche Tests extrem wichtig sind — genauso wichtig wie menschliches Review und das Schreiben des Codes selbst
• Was ich in meinem Blog „yes i will judge you for using AI“ vorhergesagt habe, wird Realität. Open Source hat sich traditionell stark auf versteckte Kompetenzsignale von Mitwirkenden verlassen, und LLMs sorgen nun dafür, dass selbst völlig Unerfahrene Code erzeugen können, der kompetent aussieht. Für erfahrene Leute ist das ein wirklich verwirrender Schock. Künftig wird man für den Einstieg in große Projekte wohl immer stärker auf soziale Beweise setzen müssen, die nichts mit dem eigentlichen PR zu tun haben, etwa virtuelle oder persönliche Treffen
  • Dasselbe passiert auch in Unternehmen. Kolleginnen und Kollegen erstellen mit LLMs Review-Kommentare, die zunächst sehr hochwertig wirken, sodass man sich kurz täuschen lässt. Dann vergeht enorm viel Zeit darauf, zu überprüfen, ob die Kommentare überhaupt stimmen, und am Ende verbrauche ich viel mehr Energie als die Person, die den Text einfach hineinkopiert hat
  • Bitte um den Blog-Link
• Die Richtlinie ist stark von Red Hat geprägt. Red Hat ist ziemlich ernsthaft und unternehmensorientiert. Vermutlich sorgt man sich dort weniger darum, „wem die Urheberrechte an KI-Erzeugnissen gehören“, sondern eher darum, dass Quellcode aus anderen Projekten, den die KI im Training aufgenommen hat, versehentlich wieder ausgespuckt wird. Die meisten Hypervisoren sind Closed Source, und viele der beteiligten Unternehmen führen gern Prozesse
  • Wenn das Risiko ist, dass KI „Code aus anderen Projekten“ aus den Trainingsdaten wortwörtlich ausspuckt, dann gilt dieses Problem in Wirklichkeit für fast jeden Code, den KI erzeugt
  • Sprachmodelle bergen oft ein höheres Risiko, subtile Logikfehler zu erzeugen, die sogar die Sicherheitsgrenzen eines Hypervisors verletzen könnten. Nutzer, die sich stark auf KI-Hilfe verlassen, sind meist schlechter darauf vorbereitet, solche Fehler zu entdecken, was die Sache noch gefährlicher macht
• Auffällig ist, dass vor allem die nach der IBM-Übernahme bei Red Hat verbliebenen Leute diese Richtlinie unterzeichnet haben. IBM hat Watson gebaut und 2011 Jeopardy gewonnen. Ich frage mich, ob das Gerede über KI-Softwareentwicklung als „erst ganz am Anfang“ wirklich ernst gemeint ist oder eher ein weiteres Beispiel für die zerstörerische Seite von IBM-Übernahmen.
  Dotnet Runtime nimmt KI sehr aktiv an. Von außen mag das belächelt werden, aber man sollte beachten, dass hervorragende Ingenieure wie Stephen Toub und David Fowler das unterstützen.
  Unternehmen würde ich raten, sich beim nächsten Besuch von IBM, wenn wieder KI-Services verkauft werden sollen, nach einem tatsächlich zukunftsorientierten Partner umzusehen.
  Als jemand aus North Carolina hoffe ich einfach, dass IBM und Red Hat den richtigen Kurs finden
• Ich frage mich, ob die Motivation wirklich rechtlicher Natur ist. Manche Projekte wirken einfach so, als seien sie von minderwertigen, KI-generierten Code-Reviews ermüdet
  • QEMU ist eine extrem zentrale Software in der Industrie. Sie steckt in Desktop-VMs, der Cloud, Build-Servern, Sicherheits-Sandboxes, plattformübergreifenden Umgebungen und vielem mehr. Schon ein sehr kleines rechtliches Risiko kann gravierende Folgen für die Branche haben
  • Die Richtlinie ist klar und zugleich eng gefasst. Sie scheint zu betonen, dass sich die Urheberrechtszuordnung algorithmisch erzeugten Codes derzeit nicht verlässlich absichern lässt. Das Wort „algorithmisch“ ist hier wohl bewusst gewählt. Auch die aktuelle Richtlinie scheint in diese Richtung zu zielen, und der Ansatz „Wir starten heute so streng und sicher wie möglich und lockern später gegebenenfalls“ wirkt von Anfang an vernünftig. Sicher geht es auch darum, große Mengen „Slop“ abzulehnen, aber die Strategie besteht zuerst darin, rechtliche Risiken und die Zuordnung zu klären. Das wirkt auf mich deutlich besser als die Politik von curl
  • Verweisend auf Monsanto und die aggressive Durchsetzung von Saatgutrechten wird zur Vorsicht gemahnt
  • Ich weiß ehrlich gesagt nicht, wie KI die Qualität von mittelmäßigem Code verändern wird, aber Menschen produzieren ebenfalls meistens nutzlosen Code. Wenn es zu viele Commits gibt und die Pflege zu schwierig wird, braucht man dann vielleicht projektspezifische Triage-Teams. Ich denke, die meisten Beiträge erfolgen in guter Absicht.
    Ich verstehe Leute, die KI wegen des Rechtsrisikos meiden, frage mich aber, ob die Sorge nicht manchmal übertrieben ist. Wer glaubt, irgendeine Möglichkeit wirklich auf null reduziert zu haben, hat meiner Meinung nach noch nicht genug darüber nachgedacht
  • Wenn das so weitergeht, könnte Open Source daran kaputtgehen. Copy-paste-Code wird viel zu leicht erzeugt, und Review wie Ablehnung kosten zu viel Zeit. Wahrscheinlich werden mehr Projekte zu einem Android-artigen Modell übergehen, in dem zwar jeder den Quellcode herunterladen kann, Außenstehende aber faktisch kaum noch etwas beitragen können
• Ich hoffe, dass man zwischen LLMs als smarter Autovervollständigung im IDE und der massenhaften Generierung kompletten Codes auf Basis hochrangiger Anweisungen unterscheiden kann. Ich erkenne an, dass es eine Grauzone ist, aber Autocomplete à la Copilot sollte man hoffentlich ohne Urheberrechtsrisiko nutzen können. Zum Beispiel kann Copilot bei einer Serie von case-Anweisungen Muster erkennen und die Tipparbeit stark reduzieren
  • Darüber hinaus träume ich von einer Zukunft, in der KI-Brillen wie ein Teil meines Denkens und meines Körpers werden. So wie normale Brillen die Sehkraft ergänzen, könnten smarte Brillen vielleicht sogar das Denken unterstützen.
    Mein Gehirn hat schließlich auch viel Closed-Source-Code „gelernt“, und ich halte die Urheberrechtsdebatte rund um KI für eine westliche NIMBY-Haltung. Wenn man mit solchen rechtlichen „Was-wäre-wenns“ großartige Technologie ablehnt, könnte am Ende sogar die westliche Zivilisation selbst Schaden nehmen
• Ich verstehe, warum solche Richtlinien auftauchen, halte sie aber für einen Fehler. Bei KI und Urheberrecht ist die Rechtslage aus meiner Sicht unklar, und gesetzgeberisch ist bislang kaum etwas passiert.
  Unabhängig von einem Verbot von KI-Beiträgen braucht es meiner Meinung nach eher klare Bereiche, in denen „hier darf KI verwendet werden“. Das CI-Setup von QEMU ist zum Beispiel kein Kernbereich, in dem Sicherheit gewahrt werden muss. Für interessante und neue Testfälle oder Umgebungen könnte man KI unter bestimmten Bedingungen durchaus zulassen
  • Ich frage mich, welches Risiko man eingeht, wenn man diese Richtlinie nicht umsetzt. Der Code wird vielleicht etwas langsamer besser, aber für ein so wichtiges Projekt wie QEMU sollte man dieses Risiko auch auf Kosten der Geschwindigkeit in Kauf nehmen. Es wirkt nicht so, als hätten die Autoren grundsätzlich etwas gegen GenAI; vielmehr scheinen sie vorsichtig zu sein, weil es, wenn es einmal eingeführt ist, kein Zurück mehr gibt
  • Die einfachste Lösung ist schlicht: warten, bis die Rechtslage klarer ist. QEMU steht fast vollständig unter GPL 2.0; wenn also GenAI-Code falsch eingeführt wird und später gerichtlich festgestellt wird, dass die ursprüngliche Lizenz zwingend beachtet werden muss, dann müsste man den betreffenden Code zurückrollen, und die ganze Downstream-Kette wäre belastet. Selbst wenn man Teile als „KI, nicht wiederverwenden“ kennzeichnet, bleibt später noch die Frage einer vollständigen Neuschreibung.
    Letztlich ist „Wir nehmen es vorerst nicht an“ für alle die weniger komplexe und weniger dramatische Entscheidung
    Dazu werden die QEMU-Lizenz und eine Liste nichtfreier Lizenzen verlinkt
  • Solche Fragen werden keine jahrzehntelangen Rechtsstreitigkeiten bleiben; es laufen bereits Dutzende einschlägige Klagen, und innerhalb weniger Jahre dürfte es Präzedenzfälle geben. QEMU ist 22 Jahre lang auch ohne KI hervorragend gewachsen, also schadet es überhaupt nicht, noch ein paar Jahre zu warten
  • Man sollte genau darauf achten, was die Richtlinie offen sagt und was zwischen den Zeilen steht. Jede Handlung birgt rechtliche Risiken, aber globale Großunternehmen gehen solche Risiken trotzdem ein. QEMU ist also nicht außergewöhnlich; vielmehr liest es sich so, als wolle man LLM-Code einfach wirklich nicht. Mit dem Muster „Lasst es von den Juristen prüfen → rechtliches Risiko → daher nicht erlaubt“ versucht man, die Debatte von vornherein zu beenden. Dasselbe Muster sieht man auch in Unternehmen
  • In der Computing-Branche gibt es seit Langem die Norm, keinen Code zu plagiieren. Selbst sehr kurzer Code wird üblicherweise nicht direkt aus der Quelle kopiert, auch wenn das rechtlich womöglich unter Fair Use fiele
• Die Begründung „streng und sicher anfangen und dann schrittweise lockern“ erscheint mir wirklich vernünftig
  Ich frage mich allerdings, ob es überhaupt eine praktikable Möglichkeit gibt, KI-generierten Code und von Menschen irgendwo abgeschriebenen Code wirklich zu unterscheiden. Open Source lebt davon, dass jeder beitragen kann, und genauso können auch Menschen im Code von anderen Quellen beeinflusst sein
  Aus heutiger Sicht hat KI-generierter Code für mich keine eigene, unabhängige Identität, sondern ist eher ein Werkzeug in der Hand von Menschen
  • Die Metapher lautet: „KI-generierter Code ist wie eine Motorsäge in Menschenhand.“ Ein mächtiges Werkzeug, das nach dem Menschen selbst zur nächsten Gefahrenquelle werden kann.
    Inzwischen ist selbst diese Metapher wohl schon zu lang ausgewalzt worden
• Solche Richtlinien scheinen praktisch überhaupt nicht durchsetzbar. Zed, Cursor und VS Code bieten alle KI-basierte Autovervollständigung, und es ist völlig unmöglich, zwischen dem von mir getippten Code und von KI vorgeschlagenem Code zu unterscheiden.
  Das ist ungefähr so, als würde ich eine Strichfigur zeichnen und mir dann sagen lassen: „Vielleicht hast du dafür die Strichfigur von jemand anderem kopiert, also hast du kein Recht, sie einzureichen.“
  Der eigentliche Zweck der Richtlinie ist wohl, sich für den Fall abzusichern, dass irgendwann doch jemand etwas einreicht, das mit KI-Code vermischt ist, damit man sagen kann: „Da konnten wir leider nichts machen.“ Ich glaube kaum, dass die Verfasser selbst nicht wissen, wie bedeutungslos die Richtlinie in dieser Hinsicht ist
  • Solche Richtlinien dienen offensichtlich dazu, im Fall „politisch verdächtigen“ Codes sagen zu können: „Wir konnten nichts dafür.“ In Commit-Nachrichten oder Patches steht dann auch, dass die Lizenzfrage bei Codegeneratoren rechtlich nicht geklärt ist.
    Abgesehen von den Rechtsfragen gibt es beim Einsatz von KI-Code klar noch viele andere Probleme
  • Neovim erzwingt KI nicht. Es funktioniert nur, wenn man es selbst einrichtet. Wenn ein Editor KI nicht abschaltbar machen würde, wäre das meiner Meinung nach schon für sich ein schwerwiegendes Problem