KI-generierter Code spaltet die Open-Source-Welt: Flathub sagt Nein, QEMU sagt Ja

Die Richtlinie enthält eine enge Ausnahme für "ausgereifte, gut gepflegte Projekte", stellt aber klar, dass dies keine Garantie ist . Einreichungen können jederzeit abgelehnt oder sogar nach der Zusammenführung wieder entfernt werden, wenn sie gegen die Regeln verstoßen . Bereits veröffentlichte Apps mit KI-Code bleiben auf Flathub – das Verbot gilt nicht rückwirkend –, aber neue KI-unterstützte Einsendungen sind damit faktisch blockiert .

Flathub hat nicht versucht, feine Linien zwischen akzeptabler und inakzeptabler KI-Nutzung zu ziehen. Es entschied sich für ein Verbot, weil die Sichtung selbst zu einer untragbaren Belastung geworden war. Die Plattform schützte die Aufmerksamkeit und mentale Gesundheit ihrer Prüfer, anstatt ein Rechtssystem reparieren zu wollen, das der Technologie noch hinterherhinkt.

QEMUs Kehrtwende: Der Test eines Mittelwegs mit Offenlegung

QEMU hatte Mitte 2025 eine der strengsten KI-Richtlinien der Open-Source-Welt eingeführt. Die formellen Regeln zur Code-Herkunft besagten, dass jeder Beitrag, der vermutlich KI-generierte Inhalte enthält – von ChatGPT, Claude, Copilot, Llama und ähnlichen Tools – abgelehnt wird. Die Begründung: KI-Code könne das Developer's Certificate of Origin (DCO) nicht erfüllen, da es keinen menschlichen Autor für die erforderlichen Zusicherungen gibt .

Doch Ende Mai 2026 schlug das Projekt nun die entgegengesetzte Richtung ein. Paolo Bonzini, Distinguished Engineer bei Red Hat und KVM-Maintainer, schlug vor, KI-unterstützte Patches in begrenzten, risikoarmen Bereichen zuzulassen – insbesondere dort, wo die Folgen von Urheberrechtsverletzungen leicht rückgängig zu machen und unwahrscheinlich sind, sich auszubreiten. Der Kerncode bliebe ohne vorherige Zustimmung eines Maintainers tabu .

Bonzinis Argumentation war pragmatisch: Projekte, die KI-unterstützte Beiträge akzeptieren, haben bisher keine ernsthaften rechtlichen Probleme bekommen, und auch Red Hats eigene Rechtsabteilung bewertete das Risiko für definierte Kategorien von Änderungen als akzeptabel . Der Vorschlag sieht eine verpflichtende Offenlegung vor: Beitragende müssten KI-generierte Teile explizit kennzeichnen, anstatt sie zu verstecken .

QEMU wettet im Grunde darauf, dass ein transparenzbasierter Mittelweg funktionieren kann, wo ein pauschales Verbot Reibung erzeugt, ohne einen verhältnismäßigen rechtlichen Nutzen zu bringen – besonders bei mechanischen Beiträgen wie Testfällen, Dokumentationskorrekturen und kleinen Patches.

Das DCO als Bruchlinie

Sowohl Flathubs striktes Verbot als auch QEMUs vorsichtige Lockerung kreisen um dieselbe ungelöste Rechtsfrage: Was passiert, wenn KI-generierter Code auf das Developer's Certificate of Origin trifft?

Das DCO verlangt von Beitragenden die Zusicherung, dass sie den Beitrag erstellt haben oder das Recht haben, ihn unter der Projektlizenz einzureichen. KI-generierter Code hat nach aktuellem US-Recht jedoch keinen identifizierbaren menschlichen Urheber. Das US Copyright Office entschied im Januar 2025, dass KI-Ergebnisse nur dann urheberrechtlich geschützt werden können, wenn ein Mensch ausreichend "schöpferische Elemente" beigesteuert hat – und die reine Eingabe von Prompts, selbst ausgefeilter, ist dafür nicht genug . Im Fall Thaler v. Perlmutter bestätigte das Bundesberufungsgericht im März 2025, dass der Copyright Act von Anfang an eine menschliche Urheberschaft verlangt. Der Oberste Gerichtshof lehnte bis März 2026 weitere Anfechtungen ab .

Das schafft eine unangenehme Zwickmühle. Ein Entwickler, der KI-generierten Code einreicht, kann das DCO möglicherweise nicht wahrheitsgemäß unterzeichnen. Die Antwort des Linux-Kernels – formalisiert im April 2026 mit der ersten Richtlinie für KI-Coding-Assistenten – bestand darin, zu verlangen, dass nur Menschen Signed-off-by-Tags hinzufügen und dass der Mensch die volle rechtliche Verantwortung für alle KI-generierten Codezeilen übernimmt . QEMUs ursprüngliches Verbot argumentierte hingegen, dass die Zusicherung der DCO-Konformität bei KI-Code angesichts der lizenzrechtlichen Unklarheiten "nicht als glaubwürdig angesehen wird" .

Kein Gericht hat bisher abschließend geklärt, ob KI-generierter Code urheberrechtlich geschützt werden kann, wer gegebenenfalls die Rechte daran hält oder welche Lizenzpflichten sich daraus ableiten. Projekte treffen ihre eigenen Risikoabwägungen, weil das Rechtssystem ihnen noch keine klare vorgegeben hat.

Die menschlichen Kosten jenseits des Urheberrechts

Die juristische Debatte ist wichtig, aber der Burnout der Maintainer hat bei Flathub das Fass zum Überlaufen gebracht. Maintainer verschiedener Projekte berichten von demselben Muster: KI-generierte Einsendungen sind oft umfangreich, aber oberflächlich – große Diff-Dateien mit wenig echtem Verständnis – und erzeugen eine Prüflast, die in keinem Verhältnis zu ihrem Wert steht .

Die GNOME Shell-Erweiterungen sahen sich einer ähnlichen Flut gegenüber. Ende 2025 berichteten Prüfer, an manchen Tagen über 15.000 Zeilen KI-generierten Erweiterungscode zu erhalten, zusammen mit KI-generierten Antworten auf Prüffragen . Flathub-Maintainer Piotrowski brachte den Punkt, an dem es nicht mehr ging, unverblümt auf den Punkt und erklärte, die Richtlinie sei nötig, weil einige Einsender "einfach nicht wissen, wie man anständig kommuniziert" .

Die menschlichen Kosten sind untrennbar mit den rechtlichen verbunden. Die DCO-Frage ist wichtig, weil Maintainer eine reale Haftung für den Code tragen, den sie akzeptieren. Die Burnout-Frage ist wichtig, weil Maintainer Freiwillige sind, die mit knappen Zeit- und Goodwill-Reserven arbeiten. KI-generierte Einsendungen belasten beides gleichzeitig.

Drei Lager, kein Konsens

Eine im Februar 2026 veröffentlichte RedMonk-Analyse untersuchte 32 Open-Source-Organisationen und fand keinen entstehenden Konsens . Die Projekte teilen sich grob in drei Lager:

• Totale Verbote: Flathub, Gentoo (einstimmiger Ratsbeschluss 2024), NetBSD (das KI-Code als "vermutlich kontaminiert" bezeichnet) und das EGO-Prüfsystem von GNOME verbieten KI-generierte Beiträge kategorisch.
• Bedingte Annahme mit Offenlegung: QEMUs Vorschlag würde sich Apache, Fedora, der Linux Foundation und der EFF anschließen, die alle KI-Nutzung mit verpflichtender Kennzeichnung und im Ermessen der Maintainer erlauben.
• Erlaubnis mit menschlicher Haftung: Der Linux-Kernel und Red Hat erlauben KI-Nutzung, wenn der menschliche Entwickler die volle Verantwortung übernimmt, das DCO unterzeichnet und das genutzte Tool kennzeichnet – das Signed-off-by bleibt jedoch ausschließlich Menschen vorbehalten.

Diese Lager sind sich nicht nur in der Politik uneins. Sie sind sich uneins, ob KI-Code ein zu handhabendes Werkzeug oder eine auszuschließende Bedrohung ist – und ob die Kosten für den Umgang damit bei den Maintainern oder einem noch nicht bereiten Rechtssystem liegen.

Wie geht es weiter?

Flathub und QEMU sind keine Ausreißer. Sie sind Datenpunkte auf einem Spektrum, das sich weiter verbreitern wird, je besser KI-Coding-Tools werden und das Volumen der generierten Einsendungen zunimmt. Einige Beobachter weisen darauf hin, dass die Erkennung von KI-generiertem Code innerhalb von ein bis zwei Jahren funktional unmöglich sein wird, was Verbote unabhängig von ihrer Absicht undurchsetzbar machen würde .

Die EFF kam bereits zu dem Schluss, dass ein pauschales Verbot angesichts der Allgegenwärtigkeit von LLM-Nutzung unpraktikabel durchzusetzen ist . Aber praktische Undurchsetzbarkeit löst das Burnout-Problem nicht, das Flathubs Entscheidung überhaupt erst ausgelöst hat.

Bis Gerichtsurteile oder Gesetze klare Regeln für Urheberschaft und Haftung bei KI-generiertem Code schaffen, trifft jedes Open-Source-Projekt im Grunde seine eigene Wette. Flathub entschied sich, seine Prüfer jetzt zu schützen, auf Kosten der Tür zu KI-Tools. QEMU ist dabei, die Tür einen Spalt weit zu öffnen, mit einer Transparenzanforderung und der Wette, dass das rechtliche Risiko bei geringfügigen Beiträgen handhabbar ist. Beide Schritte sind auf Basis der verfügbaren Informationen rational. Sie spiegeln nur unterschiedliche Antworten auf dieselbe beunruhigende Frage wider: Was tut man in einer Gemeinschaft, die auf menschlicher Urheberschaft und freiwilliger Arbeit aufbaut, wenn der Code ohne beides ankommt?