QEMU denkt über Ende des pauschalen KI-Code-Verbots nach – risikobasierter Ansatz für Open Source

Die aktuelle harte Linie

Um die Tragweite des Wandels zu verstehen, lohnt ein Blick auf die geltende Regelung. Mitte 2025 hat QEMU in seiner Code-Provenienz-Dokumentation eine strikte Richtlinie festgeschrieben: Das Projekt würde „JEGLICHE Beiträge ABLEHNEN, von denen angenommen wird, dass sie KI-generierte Inhalte enthalten oder daraus abgeleitet sind“ . Der Grund liegt in der rechtlichen Grauzone: Ein Beitragender kann nicht glaubhaft die Zertifizierungen des Entwickler-Ursprungszertifikats (Developer's Certificate of Origin, DCO) für Code abgeben, dessen urheberrechtliche Herkunft unklar ist . Die QEMU-Community erklärte ausdrücklich, sie sei „nicht bereit oder in der Lage, die rechtlichen Risiken einer Nicht-Konformität“ mit dem DCO zu akzeptieren .

Der neue Vorstoß: Ein abgestuftes Risikosystem

Der Vorschlag öffnet nicht pauschal die Tore für alle KI-generierten Code. Stattdessen arbeitet er mit einem risikobasierten Stufenmodell:

• Erlaubte Nutzung: KI-Unterstützung soll für Aufgaben erlaubt sein, „wo die Folgen von Urheberrechtsverstößen zumindest einfach rückgängig zu machen und unwahrscheinlich in ihrer Ausbreitung sind“ . Dazu zählen kleine Bugfixes und Dokumentationsaktualisierungen – also Bereiche, in denen ein potenzielles rechtliches Problem eingedämmt und leicht rückgängig gemacht werden kann . Triviale Nutzungen wie die Autovervollständigung eines Variablennamens durch die IDE gelten als so risikoarm, dass sie eventuell nicht einmal formell deklariert werden müssen .
• Eingeschränkte Nutzung: Beiträge zum Kerncode von QEMU bleiben stark eingeschränkt. In diesen Fällen wäre KI-Einsatz gänzlich „ohne vorherige Zustimmung eines Maintainers“ tabu . Diese Schutzmaßnahme stellt sicher, dass grundlegender, geschäftskritischer Code weiterhin eine klare, menschlich nachvollziehbare Herkunft behält.

Eine neue Ära der Transparenz: Der 'AI-used-for:'-Tag

Ein Eckpfeiler der geplanten Richtlinie ist ein neuer, verpflichtender Offenlegungsmechanismus. Bonzini schlägt einen 'AI-used-for:'-Commit-Trailer für Patches vor, bei denen KI eine wesentliche Rolle gespielt hat . Dieser Tag erfüllt einen doppelten Zweck: Er dokumentiert transparent den Werkzeugeinsatz für Reviewer und Maintainer und „dient gleichzeitig als Kontrolle, dass der Autor die Richtlinie gelesen hat“, bevor er Code einreicht . Dieser Ansatz unterscheidet sich von einem einfachen 'Assisted-by'-Tag und verlagert die Verantwortung auf den Beitragenden, aktiv zu bestätigen, dass sein KI-Einsatz innerhalb der definierten Projektgrenzen lag. Entscheidend: Der Einsatz von KI entbindet niemanden von den anderen Standardanforderungen – allen voran der unverzichtbaren DCO-Zertifizierung .

Was das für die Zukunft von Open Source bedeutet

QEMUs Diskussion wird in der Open-Source-Welt mit Argusaugen verfolgt. Die rechtlichen Kernfragen – wem KI-generierter Code gehört, unter welcher Lizenz er beigetragen werden darf und ob er dem DCO genügen kann – sind von Gerichten weiterhin weitgehend ungeklärt . In diesem Vakuum muss jedes Projekt seinen eigenen Rahmen für das Risikomanagement schaffen.

Der Ansatz, den QEMU nun prüft, könnte einen Mittelweg aufzeigen, den viele andere große Projekte nachahmen. Statt ein immer unhaltbareres absolutes Verbot aufrechtzuerhalten oder voreilig jeden KI-Code ohne Leitplanken zu akzeptieren, setzt dieses Modell auf Risikoabwägung und konsequente Offenlegung. Andere bedeutende Projekte wie FreeBSD ringen mit identischen Fragen, und es entstehen Initiativen, um „LLM-kontaminierten“ Open-Source-Code zu verfolgen . Indem QEMU risikoarme KI-Hilfe für Boilerplate und Dokumentation erlaubt, die Kernlogik aber unter strikter menschlicher Aufsicht hält, testet es eine Blaupause, die Produktivitätsgewinne durch KI mit den grundlegenden rechtlichen und sicherheitstechnischen Anforderungen kritischer Infrastruktursoftware ausbalancieren könnte .