KI-Code in Open Source: Richtlinien vor dem PR prüfen

Was Sie vor dem Einreichen KI-unterstützten Codes tun sollten

Open-Source-Projekte veröffentlichen inzwischen Richtlinien für KI-unterstützten Code. Diese Richtlinien stimmen nicht miteinander überein. Die einfache Vorgehensweise lautet daher: Suchen Sie die Richtlinie, bevor Sie den Patch schreiben, und machen Sie bei der Einreichung vollständige und korrekte Angaben. Eine Regel gilt für alle Richtlinien: Reichen Sie niemals eine Zeile ein, die Sie im Review nicht erklären können.

Ein korrekter Patch wird trotzdem geschlossen, wenn das Projekt generierten Code verbietet oder wenn Sie verschwiegen haben, woher der Code stammt. Die Folgen werden Ihrem Namen zugerechnet und bleiben dort haften. Ein Maintainer, der die fehlende Angabe später entdeckt, hat keinen Grund, dem übrigen Verlauf Ihrer Beiträge zu vertrauen. Zunächst einige Begriffe, weil die Richtlinien sie verwenden. Ein LLM (large language model) ist das Modell hinter Ihrem Coding-Agenten. Ein PR (pull request) auf GitHub entspricht einem MR (merge request) auf GitLab; alles Folgende gilt für beide. Der DCO (developer certificate of origin) ist die Sign-off-Zeile am Ende einer Commit-Nachricht. Sie bildet den Mittelpunkt der gesamten Diskussion.

Wo Open-Source-Richtlinien zu KI-generiertem Code stehen

Projekte haben sich auf vier Kategorien eingependelt. Jedes Beispiel ist datiert, weil sich diese Texte ändern.

Verboten. Der Gentoo Council stimmte am 14. April 2024 dafür, dass es „ausdrücklich verboten ist, Gentoo Inhalte beizusteuern, die mit Unterstützung von Tools für künstliche Intelligenz zur Verarbeitung natürlicher Sprache erstellt wurden“. Die Commit-Richtlinien von NetBSD bezeichnen die Ausgabe eines LLM als „kontaminierten Code“, der „ohne vorherige schriftliche Genehmigung durch das Core-Team nicht committed werden darf“. Das Dokument zur Code-Herkunft von QEMU besagt im August 2026 weiterhin, dass das Projekt „JEGLICHE Beiträge ABLEHNEN wird, von denen angenommen wird, dass sie KI-generierte Inhalte enthalten oder daraus abgeleitet sind“.

Nur zur Analyse. Die meisten Verbote sind enger gefasst, als die Überschrift vermuten lässt. Im QEMU-Dokument steht, dass die Richtlinie „für andere Verwendungen von KI nicht gilt, etwa zur Recherche von APIs oder Algorithmen, für statische Analyse oder zur Fehlersuche, sofern die Ausgabe nicht in Beiträge aufgenommen wird“. Sie dürfen den Agenten zum Lesen des Codes verwenden. Sie dürfen den von ihm geschriebenen Code nicht ausliefern. Diese Unterscheidung ist die praktische Grenze innerhalb der meisten restriktiven Projekte. Genau sie wird häufig übersehen.

Offenlegung erforderlich. Der Fedora Council genehmigte im Oktober 2025 eine Richtlinie zu KI-unterstützten Beiträgen. Sie erlaubt den Einsatz solcher Tools und legt die Verantwortung bei der jeweiligen Person: Der Beitragende ist der Autor, trägt die vollständige Verantwortung für den gesamten Beitrag und muss offenlegen, wenn ein wesentlicher Teil davon unverändert aus einem Tool stammt. Der Linux-Kernel erhielt im Dezember 2025 eine Seite zu Coding-Assistenten in seiner Prozessdokumentation. Sie enthält einen Trailer zur Aufzeichnung des verwendeten Tools sowie eine verbindliche Regel dazu, wer die Freigabe erteilen darf.

Nichts schriftlich festgehalten. Das ist weiterhin der häufigste Fall. Ein Preprint aus dem Mai 2026 untersuchte 1,000 beliebte GitHub-Repositories und fand in 118 davon eine schriftliche KI-Richtlinie. Schweigen ist keine Erlaubnis. Fragen Sie im Issue-Tracker in einem Satz nach, bevor Sie den Patch schreiben. Dann ist die Antwort öffentlich dokumentiert und kann später als Beleg dienen.

Warum Maintainer diese Regeln verfasst haben

Der erste Grund ist der Prüfaufwand, und die Rechnung geht nur in eine Richtung. Ein Agent erstellt in einer Minute einen plausiblen Merge Request mit 400 Zeilen. Eine gründliche Prüfung dieses Requests kostet einen Maintainer einen ganzen Nachmittag, und die meisten Maintainer arbeiten ehrenamtlich. Die Kosten für das Einreichen sind gegen null gesunken. Die Kosten für die Prüfung haben sich überhaupt nicht verändert.

curl zeigt das andere Ende dieser Entwicklung. Daniel Stenberg berichtete Mitte 2025, dass ungefähr ein Fünftel der über das Bug-Bounty-Programm des Projekts eingehenden Security Reports das war, was er als AI-Slop bezeichnet: Reports, die echte Funktionen und echte Codepfade nennen, einen plausiblen Angriff beschreiben und inhaltlich nichts enthalten. Anfang 2026 beendete das Projekt das Bounty-Programm, statt die Flut weiter zu finanzieren. Es handelte sich dabei um Reports und nicht um Patches. Der Mechanismus ist jedoch derselbe: Ein Maintainer öffnet Ihren PR bereits erschöpft.

GNOME Calendar hat das Problem als Label festgehalten. Im Juni 2026 führte das Projekt für Merge Requests mit „major or total reliance on artificial 'intelligence' to generate code“ die Bezeichnung „Probabilistically Automated“ ein und benannte das Symptom genau: „usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code“. Lesen Sie den letzten Teil zweimal. Der Code sieht so aus, als müsste er funktionieren. Niemand hat geprüft, ob er tatsächlich funktioniert.

Der zweite Grund ist die Herkunft des Codes, also woher er stammt und unter welcher Lizenz er steht. QEMU beschreibt den Konflikt klar: Mit dem Sign-off bestätigen Sie, dass Sie „fully understand the copyright and license status of content“ haben, das Sie beitragen. Der urheberrechtliche Status von Model-Ausgaben ist jedoch ungeklärt. Der Gentoo Council nannte denselben Grund sowie Qualitäts- und ethische Aspekte. Sie müssen diese rechtliche Einschätzung nicht teilen. Sie müssen jedoch berücksichtigen, dass die Entscheidung beim Maintainer liegt und nicht bei Ihnen.

Wie finde ich die KI-Richtlinie eines Projekts?

Suchen Sie in dieser Reihenfolge an den folgenden Stellen.

• Zuerst in CONTRIBUTING.md im Stammverzeichnis des Repositorys, dann in .github/CONTRIBUTING.md und anschließend in jeder danebenliegenden DCO-Datei.
• In der Entwicklerdokumentation. QEMU führt seine Regel in docs/devel/code-provenance.rst, der Kernel in Documentation/process/coding-assistants.rst.
• Auf der Projektwebsite oder im Wiki. Die Richtlinie von Gentoo steht auf der Wiki-Seite des Council, die von NetBSD in den Commit-Richtlinien.
• Im Issue-Tracker und im Archiv der Mailingliste. Eine Richtlinie existiert dort oft monatelang, bevor sie jemand in das Repository übernimmt.

Innerhalb eines Checkouts deckt ein grep-Aufruf den größten Teil ab:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Lesen Sie anschließend die eigene Historie des Projekts. Die tatsächlich committete Konvention ist maßgeblicher als jede Zusammenfassung davon:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Eine Anzahl neben einem Trailer-Wert zeigt, welche Form dieses Projekt tatsächlich verwendet. Ein leeres Ergebnis bedeutet, dass hier niemand diese Form angegeben hat. Auch das ist eine Information. Wenn das Projekt auf GitHub liegt und der Workflow für Sie neu ist, erklärt wie Pull Requests und Forks auf GitHub funktionieren die in diesem Abschnitt vorausgesetzten Abläufe.

Offenlegung im Commit-Trailer statt in einem Kommentar

Ein Trailer ist eine Key: value-Zeile im letzten Absatz einer Commit-Nachricht. Git verwendet dieses Format bereits für Signed-off-by: und Co-authored-by:, und Werkzeuge können es auswerten. Daher ist dies die einzige Offenlegung, die zusammen mit dem Code in den Baum gelangt.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Der Kernel dokumentiert dieses Format als Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]. Dabei wird die Einschränkung der Zeile ausdrücklich genannt: „AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).“ Der Name des Agents kommt in Assisted-by. Ihr Name kommt in Signed-off-by. Lassen Sie ein Werkzeug niemals den zweiten Eintrag schreiben. Lassen Sie es außerdem niemals eine Co-authored-by-Adresse erfinden, die niemandem gehört.

Die Bezeichnungen unterscheiden sich. Kopieren Sie daher die lokale Bezeichnung, statt eine eigene zu erfinden. Ein im Mai 2026 an die QEMU-Mailingliste gesendeter Patch schlug vor, das Verbot dieses Projekts für mechanische Änderungen, Tests, Dokumentation und Fehlerkorrekturen mit höchstens zwanzig Zeilen zu lockern. Die Änderung sollte mit einem Trailer wie AI-used-for: tests, docs gekennzeichnet werden. Im August 2026 war dies weiterhin nur ein Vorschlag auf einer Mailingliste. Das verbindliche Dokument lehnte generierten Inhalt weiterhin ab. Ein Projekt änderte seine Position zwischen 2023 und 2026 zweimal. Die nächste Änderung wird nicht auf Sie warten. Deshalb ist die Methode wichtiger als die Liste.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer erfordert Git 2.32 oder neuer. Der zweite Befehl sollte den Wert direkt wieder ausgeben. Eine leere Zeile bedeutet, dass git den Trailer nicht erkannt hat. Ursache ist fast immer eine Leerzeile oder ein gewöhnlicher Satz innerhalb des Trailer-Blocks am Ende der Nachricht. Für eine bereits geschriebene Serie fügt git rebase --signoff origin/main den Sign-off zu jedem Commit hinzu. git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt bearbeitet eine Nachrichtendatei.

Zwei Fehlerfälle sollten Sie einplanen. Ein Squash-Merge schreibt die Commit-Nachricht neu. Wenn ein Projekt Commits per Squash zusammenführt, wiederholen Sie die Offenlegung daher in der PR-Beschreibung, wo der Maintainer sie liest. Ein Review-Kommentar ist dagegen kein verlässlicher Nachweis, weil Kommentare bearbeitet werden können und niemals in der git-Historie landen.

Genauigkeit ist in beide Richtungen wichtig. Assisted-by bei einem Commit, den Sie selbst von Hand eingegeben haben, ist überflüssig und entwertet Ihre tatsächlichen Offenlegungen. Wenn Sie es bei einem vom Agent geschriebenen Commit weglassen, beenden Sie damit die Zusammenarbeit.

Was bestätigt Signed-off-by tatsächlich?

Das DCO ist ein kurzer Text in Version 1.1. Es wurde auf developercertificate.org veröffentlicht und wird vom Kernel, von QEMU und vielen anderen Projekten verwendet. Das Hinzufügen von Signed-off-by: Your Name <you@example.com> bedeutet, dass Sie dies bestätigen. Lesen Sie, was Sie damit bestätigen. Die meisten Personen signieren es, ohne den Text jemals gelesen zu haben.

Klausel (a) besagt, dass der Beitrag „ganz oder teilweise von mir erstellt wurde und ich das Recht habe, ihn unter der in der Datei angegebenen Open-Source-Lizenz einzureichen“. Klausel (b) betrifft Arbeiten, die auf früherem Open-Source-Code basieren und die Sie mit Änderungen weitergeben dürfen. Klausel (c) betrifft Code, den Ihnen eine Person übergeben hat, die dasselbe bestätigt hat. Klausel (d) besagt, dass Sie verstehen, dass der Beitrag und die persönlichen Informationen in Ihrem Sign-off öffentlich sind und dauerhaft gespeichert werden.

Beachten Sie, was fehlt. Das DCO besagt nicht, dass Sie jedes Zeichen selbst eingegeben haben. Es besagt, dass Sie das Recht haben, den Code unter dieser Lizenz einzureichen. Deshalb ist generierter Code in diesem Zusammenhang problematisch: Es geht nicht um die Urheberschaft, sondern darum, ob Sie die Herkunft nachvollziehbar belegen können. Die meisten Projekte, die ein Sign-off verlangen, fordern außerdem einen echten Namen. Ein Pseudonym erfüllt diese Prüfung daher nicht. Fügen Sie die Zeile mit git commit -s hinzu. Sie liest user.name und user.email aus Ihrer git-Konfiguration. Wenn ein DCO-Bot Ihren PR ablehnt und den Commit nennt, in dem die Zeile fehlt, beheben git rebase --signoff origin/main und ein Force-Push auf Ihren Branch das Problem.

Das Signieren eines Commits ist nicht dasselbe wie das Sign-off

git commit -s fügt eine Textzeile hinzu. git commit -S erstellt mit Ihrem GPG- oder SSH-Schlüssel eine kryptografische Signatur über das Commit-Objekt. Beide Verfahren beantworten unterschiedliche Fragen. Die Signatur bestätigt, dass dieser Commit vom Inhaber dieses Schlüssels stammt und seitdem nicht verändert wurde. Sie sagt nichts darüber aus, woher der enthaltene Code stammt. Ein signierter Commit mit nicht offengelegtem generiertem Code ist daher zwar signiert, verstößt aber weiterhin gegen die Richtlinie. Das Sign-off ist die Erklärung zur Herkunft. Die Signatur ist die Erklärung zur Identität. Projekte, die beides verlangen, fordern auch beides.

Reichen Sie keinen Code ein, den Sie im Review nicht erklären können

Hier ist der Test. Dabei geht es nicht wirklich um Ehrlichkeit. Fragen Sie sich für jede Zeile: Wofür ist sie da, und was funktioniert ohne sie nicht? Fehlt eine der beiden Antworten, ist der Patch noch nicht bereit. Denn dann kommt der Review-Kommentar, und Ihre Antwort führt zu einer weiteren Generierungsrunde. Reviewer erkennen das. In diesem Moment wird ein Beitrag zu einem Kostenfaktor. Stellen Sie dieselbe Frage zu Randfällen, leerer Eingabe, dem Fehlerpfad und dem zweiten Aufrufer.

Führen Sie den Code aus. Bauen Sie ihn, führen Sie die Testsuite des Projekts aus und schreiben Sie einen Reproducer für den Fehler, den Sie angeblich beheben. Die Kernel-Dokumentation nennt die ehrliche Ausweichlösung in klaren Worten: "If the fix could not be built or tested, or if no reproducer could be produced, say so explicitly: maintainers currently waste too much time analyzing unverified reports and untested fixes." Zu schreiben: "I could not test this on real hardware" kostet Sie nichts. Den Eindruck zu erwecken, Sie hätten es getestet, schadet dem Projekt.

Beantworten Sie Review-Kommentare selbst, mit Ihren eigenen Worten und in Ihrem eigenen Zeitrahmen. Eine Antwort, die dreißig Sekunden nach dem Kommentar eingeht und ihn in fünf Absätzen wiederholt, zeigt dem Maintainer genau, was passiert ist. Halten Sie auch den Diff klein. Vierzig Zeilen, die Sie vollständig verstehen, sind für ein Projekt mehr wert als ein vierhundertzeiliges Refactoring, das Sie nur überwacht haben. Wenn Ihr Agent Ihnen weiterhin mehr zurückgibt als angefordert, ist eine Fähigkeit, die ihn auf die kleinste funktionierende Änderung begrenzt, eine Möglichkeit, den Patch auf einen Umfang zu beschränken, den Sie noch Zeile für Zeile vertreten können.

Anweisungen für den Agenten im Repository speichern

Die Anweisungen für Ihren Agenten sind Teil Ihrer Toolchain und sollten daher wie Code behandelt werden. Eine Datei im Stammverzeichnis des Repositorys, normalerweise AGENTS.md, enthält den Build-Befehl, den Test-Befehl, das Format für Commit-Nachrichten, die erforderliche Sign-off-Angabe und die bereits im Projekt dokumentierten Stilregeln. Diese Datei ist versioniert und kann geprüft werden. Sie ist morgen identisch mit der heutigen Version. Werden Anweisungen in jeder Sitzung aus dem Gedächtnis neu eingegeben, entsteht in jeder Sitzung ein anderer Patch. Dann ist nicht nachvollziehbar, in welcher Sitzung der Patch erstellt wurde, der abgelehnt wurde. Eine AGENTS.md schreiben, die sowohl ein Agent als auch ein Mensch lesen kann behandelt die Datei selbst.

Beachten Sie einen Punkt bei den Repositorys anderer Personen. Erstellen Sie nicht als ersten Beitrag einen PR, der eine Agentenanweisungsdatei zu einem Projekt hinzufügt, das Sie nicht verwalten. Das wirkt wie der Versuch, die Tooling-Richtlinien des Projekts von außen festzulegen. Außerdem wird Ihr Account dadurch schnell mit etwas in Verbindung gebracht, dessen die Maintainer bereits überdrüssig sind. Bewahren Sie die Datei in Ihrem Fork auf, bis jemand darum bittet.

Auch der Ort, an dem Sie den Agenten ausführen, ist aus demselben Grund wichtig. Ein Agent, der das Projekt in einer von Ihnen kontrollierten Sandbox bauen und dessen Tests ausführen kann, liefert Ihnen einen Patch, den Sie tatsächlich geprüft haben. Das ist der Unterschied zwischen dem Offenlegen von Unterstützung und dem Offenlegen einer Vermutung. Einen Coding-Agenten auf Ihrem eigenen VPS ausführen behandelt diese Einrichtung. Die praktischen Unterschiede zwischen Claude Code, Cursor, Codex und Copilot beschreibt, wie sich die Tools im täglichen Einsatz unterscheiden.

Die Vorgehensweise, sobald sich die Richtlinien ändern

1. Ermitteln Sie die geltende Richtlinie, bevor Sie etwas schreiben: Repository, Entwicklerdokumentation, Website oder Tracker.
2. Wenn keine Richtlinie vorhanden ist, fragen Sie dies in einem Satz im Issue und bewahren Sie die Antwort auf.
3. Geben Sie den Hinweis in der vom Projekt verwendeten Form im Commit-Trailer an. Wiederholen Sie ihn im PR-Text, wenn das Projekt Commits zusammenführt.
4. Signieren Sie mit Ihrem echten Namen. Die Zeile bestätigt, dass Sie zur Einreichung des Codes berechtigt sind.
5. Prüfen Sie Ihren eigenen Patch, als stamme er von einer fremden Person. Denn genau das ist geschehen.

Jedes auf dieser Seite genannte Projekt wird sich verändert haben, wenn Sie dies lesen. Die fünf Schritte bleiben unverändert.

FAQ

Muss ich offenlegen, dass ich einen KI-Coding-Agenten verwendet habe?

Prüfen Sie das jeweilige Projekt, da die Antwort lokal festgelegt ist. Fedora verlangt eine Offenlegung, wenn ein wesentlicher Teil des Beitrags von einem Tool stammt und unverändert übernommen wurde. Der Linux-Kernel verlangt einen Assisted-by-Trailer. Gentoo und QEMU akzeptieren Beiträge, die daraus abgeleitet sind, seit August 2026 nicht. Wenn nichts dokumentiert ist, sollten Sie die Verwendung trotzdem in einem Commit-Trailer offenlegen. Ein Maintainer, der später davon erfährt, reagiert auf das Verschweigen und nicht auf das Tool. Diese Reaktion wirkt sich dann auf alles andere aus, was Sie eingereicht haben.

Welche Open-Source-Projekte verbieten KI-generierten Code?

Stand August 2026 sind dies Gentoo seit April 2024, NetBSD, das LLM-Ausgaben als verunreinigten Code behandelt, der eine Freigabe durch das Core-Team benötigt, QEMU, das Beiträge aus generierten Inhalten ablehnt, sowie mehrere GNOME-Anwendungen einschließlich Loupe und Calendar. Lesen Sie den jeweiligen Projekttext anstelle dieser Liste, da sie veralten wird. Beachten Sie die Ausnahme, die die meisten dieser Projekte gemeinsam haben: Die Verwendung eines Modells zur Recherche einer API, für statische Analysen oder zur Unterstützung beim Debugging ist in der Regel zulässig, solange seine Ausgabe nicht im Patch enthalten ist.

Was ist der Unterschied zwischen Signed-off-by und einem signierten Commit?

Signed-off-by ist eine von git commit -s hinzugefügte Klartextzeile. Sie bestätigt das Entwicklerzertifikat der Herkunft (Developer Certificate of Origin). Damit erklären Sie, dass Sie das Recht haben, diesen Code unter der Lizenz des Projekts einzureichen. Ein mit git commit -S erstellter signierter Commit ist eine kryptografische Signatur über dem Commit-Objekt, die Ihren GPG- oder SSH-Schlüssel verwendet. Sie beweist, dass der Commit von Ihrem Schlüssel stammt und nicht verändert wurde. Herkunft und Identität sind getrennte Aussagen. Daher kann ein signierter Commit trotzdem gegen eine KI-Richtlinie verstoßen.

Kann ich die Offenlegung in die Beschreibung des Pull Requests statt in die Commit-Nachricht aufnehmen?

Nehmen Sie sie in die Commit-Nachricht auf, da diese in der Git-Historie gespeichert wird und zusammen mit dem Code an alle weitergegeben wird, die das Repository später klonen. Eine Pull-Request-Beschreibung kann nachträglich bearbeitet werden und befindet sich auf der Hosting-Plattform. Fügen Sie die Offenlegung zusätzlich in den PR-Text ein, wenn das Projekt per Squash merged, da dabei Ihre Commit-Nachricht neu geschrieben werden kann und der Trailer verloren gehen kann.

Mein Pull Request wurde geschlossen, weil er KI-generiert war. Was soll ich jetzt tun?

Diskutieren Sie die Richtlinie nicht im Thread, da die Person, die den Pull Request geschlossen hat, die Regel nicht allein festgelegt hat und die Regel dort nicht geändert wird. Lesen Sie den Richtlinientext und entscheiden Sie anschließend, ob Sie ihn einhalten können. Wenn das Projekt generierte Patches verbietet, ist ein klarer Fehlerbericht mit einem Reproducer und ohne Patch weiterhin willkommen. Oft ist dies der nützlichere Beitrag. Wenn Sie erneut Code einreichen, sollte es eine kleine Änderung sein, die Sie Zeile für Zeile begründen können.