KI-generierter Code: Warum verbietet OpenJDK ihn?

Oracle verbietet KI-generierten Code in OpenJDK

Markus Seyfferth

Autor Dr. Web

7. August 2026

2 Min. Lesezeit

KI-generierter Code ist in OpenJDK gesperrt. Der Grund liegt nicht in der Qualität, sondern im Oracle Contributor Agreement: Jeder Beitragende muss die Rechte am eingereichten Code besitzen. Diese Zusage gibt keine Modellausgabe her.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

KI-generierter Code trifft im Java-Ökosystem auf eine harte Grenze. In allen 410 offenen Pull Requests des Haupt-Repositorys openjdk/jdk steht inzwischen eine Zeile, mit der der Einsender die KI-Richtlinie der Community bestätigt.^[1] Untersagt ist danach jeder Inhalt, den ein Sprach- oder Diffusionsmodell ganz oder teilweise erzeugt hat, in Quellcode und Text ebenso wie in Mails oder Bugtracker-Einträgen.^[2]

Das Wichtigste in Kürze

Beiträge in OpenJDK dürfen keine Inhalte enthalten, die ein Sprach- oder Diffusionsmodell erzeugt hat.
Grund ist das Oracle Contributor Agreement: Der Einsender muss die Rechte am Beitrag besitzen und abtreten können.
Analysieren, Debuggen und Reviewen mit KI bleibt erlaubt, solange die Ausgabe nicht in den Beitrag wandert.
GraalVM, ebenfalls ein Oracle-Projekt, erlaubt KI-Assistenz unter demselben Vertrag.

Warum entscheidet der Vertrag und nicht die Codequalität?

Ein Holzstempel mit einem Schild „Kein Eigentümer“ und einem Antragsformular auf weißem Grund — Oracle verbietet KI-generierte Beiträge, da Contributor müssen Vollrechte besitzen und abtreten können. KI-Modelle trainieren mit geschütztem Material und können Fremdenrechte verletzen

Das Verbot folgt aus dem Vertragswerk der Community. Das Oracle Contributor Agreement verlangt, dass ein Beitragender die Rechte an jedem Beitrag besitzt und ohne Einschränkung an Oracle abtreten kann. Generative Modelle lernen an urheberrechtlich geschütztem und lizenziertem Material; ihre Ausgabe kann fremde Rechte verletzen. Ob ein Nutzer überhaupt Rechte am Erzeugten hält, klären Gerichte gerade erst.^[2] Eine Zusicherung, die niemand einlösen kann, bricht den Vertrag bereits beim Einreichen.

Dieselbe Logik zieht QEMU: Das Emulator-Projekt weist KI-Beiträge zurück, weil Lizenz- und Urheberstatus der Ausgabe ungeklärt bleiben.^[3] Der Bruch verläuft damit entlang der Rechtsinstrumente. Wo ein Projekt die Eigentumszusage verlangt, bleibt Modellcode draußen. Der Linux-Kernel kommt mit einer bloßen Herkunftsbestätigung aus und erlaubt Assistenzwerkzeuge; untersagt ist dort nur, dass ein Agent selbst das Signed-off-by setzt.^[4] Auch die Debian-Community hat über genau diese Frage abgestimmt.

Wie lässt sich die Regel überhaupt durchsetzen?

Durchgesetzt wird die Regel über die Selbsterklärung der Einsender. Die Community räumt ein, dass sich menschlicher und maschineller Code nicht zuverlässig unterscheiden lässt; ein Reviewer greift erst bei konkreten Anhaltspunkten ein.^[2] Das Automationssystem Skara setzt die Bestätigungszeile deshalb in jeden Pull Request. Der Beitragende steht danach selbst dafür gerade.

Wie weit dieselbe Rechtslage auseinanderführt, zeigt ein zweites Oracle-Projekt. GraalVM untersteht nicht der OpenJDK-Governance und erlaubt KI-Assistenz unter demselben Contributor Agreement ausdrücklich. Die Verantwortung liegt dort beim Menschen: Kann ein Beitragender seine Änderung nicht erklären und nicht pflegen, wird sie abgelehnt.^[5]

Oracle sperrt KI-Code in OpenJDK wegen einer einzigen Vertragsklausel: Das Contributor Agreement verlangt eine Eigentumszusage, die keine Modellausgabe hergibt. Jedes Unternehmen mit eigenem CLA sollte diese Klausel lesen, bevor der erste Agent einen Pull Request stellt.
— Michael Dobler, Herausgeber Dr. Web

410 von 410

Offene Pull Requests im Repository openjdk/jdk enthalten die Bestätigungszeile zur KI-Richtlinie.

11.09.2026

Ab diesem Tag greifen die Meldepflichten des Cyber Resilience Act für Hersteller.

Das Rechtsinstrument entscheidet

OpenJDK

Oracle Contributor Agreement, also Eigentumszusage des Einsenders

Modellausgabe gesperrt

QEMU

Developer’s Certificate of Origin, streng ausgelegt

Modellausgabe gesperrt

Linux-Kernel

Developer’s Certificate of Origin, Kennzeichnung per Assisted-by-Zeile

erlaubt mit Auflagen

GraalVM

Oracle Contributor Agreement, Verantwortung beim Menschen

erlaubt mit Auflagen

Was bedeutet das für Entwicklerteams in der DACH-Region?

Für deutsche Teams verschärft das Urheberrecht die Lage zusätzlich. Nach § 2 Absatz 2 und § 69a UrhG schützt das Gesetz nur die persönliche geistige Schöpfung eines Menschen; rein maschinell erzeugter Code ist danach kein Werk, an dem sich Rechte einräumen ließen. Ein Mitarbeiter, der solchen Code unter ein Contributor Agreement stellt, sichert etwas zu, das rechtlich nicht existiert. An derselben Haftungsfrage scheitern vollautomatische Softwarefabriken.

Die zweite Schicht kommt aus Brüssel. Ab dem 11. September 2026 greifen die Meldepflichten des Cyber Resilience Act. Der Hersteller haftet dann für jede Komponente seines Produkts, gleich wer oder was die Zeilen geschrieben hat. Prüfen Sie deshalb die Upstream-Policy jedes Projekts, in das Ihr Team einliefert. Lesen Sie danach die eigene Contributor-Vereinbarung auf genau diese Eigentumsklausel hin. Halten Sie die Herkunft von KI-Code im Repository fest, so wie der Linux-Kernel das mit seiner Assisted-by-Zeile vormacht. Dass die Verantwortung zum eigentlichen Engpass wird, spüren Entwicklerteams längst.