Wem gehört der von Claude Code geschriebene Code?
(legallayer.substack.com)- Das Urheberrecht an KI-unterstütztem Code hängt davon ab, ob ein Mensch einen wesentlichen kreativen Beitrag geleistet hat; Ergebnisse, die überwiegend von einer KI erzeugt und vom Menschen kaum bearbeitet wurden, könnten keinen Schutz genießen
- Das zentrale Kriterium ist meaningful human authorship; wichtiger als bloße Zielvorgaben sind kreative Entscheidungen wie die Architektur festzulegen, Ergebnisse auszusortieren und Code neu zu strukturieren
- Unabhängig davon, ob an dem Code Urheberrechte entstehen, kann work-for-hire doctrine oder eine weit gefasste IP-Abtretungsklausel dazu führen, dass auch KI-unterstützter Code, der in Firmenzeit, mit Firmengeräten, für Firmenprojekte oder mit vom Unternehmen lizenzierten Tools erstellt wurde, dem Unternehmen gehört
- Selbst wenn Eigentumsrechte bestehen, ist Open-Source-Lizenz-Kontamination ein separates Problem; insbesondere Ausgaben, die GPL-Code im Wesentlichen wörtlich kopieren, können zu Lizenzverstößen führen
- Relativ klar sind derzeit drei Achsen: kein Schutz ohne menschliche Urheberschaft, Rechtezuordnung nach Arbeitsvertrag und das Risiko wörtlicher GPL-Kopie; in der Praxis sind Dokumentation und Lizenz-Scans oft wichtiger als eine spätere Gerichtsentscheidung
Urheberrechtsmaßstäbe und ungeklärte Bereiche
- Urheberrechtsschutz gilt nur für von Menschen geschaffene Werke; Ergebnisse, die überwiegend von einer KI erzeugt wurden und keinen wesentlichen kreativen Beitrag eines Menschen enthalten, könnten nach aktuellem Maßstab nicht schutzfähig sein
- Auch nach dem Thaler-Fall hat der Supreme Court nicht in der Sache selbst entschieden; das Urteil des DC Circuit blieb zwar bestehen, aber es gibt noch keinen direkt einschlägigen Präzedenzfall, der sich 1:1 auf KI-unterstützte Coding-Ergebnisse anwenden lässt
- Der zentrale Bereich, den Gerichte noch nicht direkt behandelt haben, ist, wie viel menschliche Mitwirkung bei KI-unterstützten Arbeitsergebnissen erforderlich ist
- Anders als bei rein KI-generierten Bildern mit null menschlicher Mitwirkung ist die Grenze bei Code unschärfer, weil Menschen oft zumindest teilweise die Richtung vorgeben und Ergebnisse freigeben
- Im Code-Bereich gibt es bislang noch keine Entscheidung, die das Prinzip menschlicher Urheberschaft direkt auf Ausgaben von KI-Coding-Tools anwendet
- Wenn von einer KI erzeugter Code fast unverändert übernommen wurde, ist es möglich, dass niemand Urheberrechte daran geltend machen kann; selbst gegen eine wortgleiche Übernahme durch Konkurrenten wären die Gegenmittel dann schwächer
- Im Zentrum der Bewertung steht meaningful human authorship; wichtiger als nur Ziele zu formulieren sind kreative Entscheidungen darüber, die Struktur festzulegen, Ergebnisse auszusortieren und den Entwurf neu aufzusetzen
Wie sich menschliche Urheberschaft nachweisen lässt
- Wesentlicher menschlicher Beitrag lässt sich nicht einfach als Prozentsatz oder Zahl von Änderungen berechnen; entscheidend ist, ob der Mensch tatsächlich kreative Entscheidungen getroffen hat
-
Architekturentscheidungen
- Es muss entschieden werden, welche Entwürfe abgelehnt werden
- Ergebnisse müssen passend zu einem bestimmten Design neu strukturiert werden
- Wenn ein Tool nach einer kurzen Anweisung wie „Erstelle ein Rate-Limiting-Modul für eine API“ mehrere Dateien erzeugt und iterativ anpasst, gibt es noch keine klare Antwort, ob der menschliche Beitrag vor Gericht ausreicht
- Bei Modulen, die stark überarbeitet und in ihrer Richtung verändert wurden, ist eine Anerkennung menschlicher Urheberschaft wahrscheinlicher; unverändert übernommener Code kann dagegen in die entgegengesetzte Richtung ausgelegt werden
- Allen v. Perlmutter blieb ein wichtiger Wendepunkt zur Frage, wann menschliche Mitwirkung ausreicht: Trotz über 600 Prompts und Bearbeitung in Photoshop wurde die Registrierung der von der KI erzeugten Basiselemente abgelehnt
- In Zarya of the Dawn wurde nur der vom Menschen geschriebene Text registriert, während die mit Midjourney erzeugten Bilder ausgeschlossen wurden; dieses Prinzip weist auch bei KI-unterstützten Codebasen in die Richtung, von Menschen direkt geschaffene Elemente getrennt zu schützen
- Designdokumente können als Beleg dienen
- In Commit-Messages festgehaltene Designentscheidungen können als Beleg dienen
- ADRs können als Beleg dienen
- Prompt-Logs mit absichtlichen Richtungsänderungen helfen ebenfalls
- Um den schutzfähigen Anteil zu vergrößern, ist es vorteilhaft, festzuhalten, was man selbst entschieden und wie man es verändert hat
-
Der Arbeitsvertrag entscheidet oft zuerst über das Eigentum
- Noch bevor geprüft wird, ob Code urheberrechtlich geschützt ist, sollte geklärt werden, wem ein solches Recht überhaupt ursprünglich zusteht
- Übliche Arbeitsverträge ordnen innerhalb des Tätigkeitsbereichs entstandene Arbeitsergebnisse dem Unternehmen zu; das wird häufig mit der work-for-hire doctrine erklärt
- Ergebnisse, die während der Arbeitszeit, für Firmenprojekte, mit Firmengeräten oder mithilfe eines vom Unternehmen bereitgestellten KI-Coding-Tools erstellt wurden, werden mit hoher Wahrscheinlichkeit sowohl bei manuell geschriebenem als auch bei KI-unterstütztem Code dem Unternehmen zugerechnet
- In der Praxis sind Verträge meist weiter gefasst als die Grundprinzipien des Rechts; folgende Formulierungen können auch KI-unterstützten Code erfassen
- Auch mit Firmengeräten oder Unternehmensressourcen erstellte Arbeitsergebnisse können einbezogen sein
- Auch während des Beschäftigungszeitraums entstandene Erfindungen oder Entwicklungen können einbezogen sein
- Auch mit Hilfe von vom Unternehmen lizenzierten Tools entwickelte Software kann einbezogen sein
- Gerade die Formulierung company-licensed tools kann sich auch auf private Projekte ausdehnen
- Wenn das Unternehmen Claude Code, Cursor oder Copilot für Teams eingeführt hat
- und dieselben Tools auch in einem Nebenprojekt in der Freizeit verwendet wurden
- kann das Unternehmen unter einer weit gefassten IP-Abtretungsklausel Ansprüche geltend machen
- Die Behauptung, eine Ausgabe sei schon deshalb ein abgeleitetes Werk von Unternehmens-IP, weil Unternehmenscode in der IDE geöffnet war und die KI ihn sehen konnte, lässt sich rechtlich nicht ohne Weiteres als gesichert ansehen
- Wenn die Vertragsklauseln weit gefasst sind, kann jedoch unabhängig davon, was die KI tatsächlich getan hat, zumindest eine plausible Anspruchsposition entstehen
- Wer Side Projects trennen will, fährt sicherer mit einem vollständig getrennten Workflow über privates Konto, private Geräte und privat bezahlte Tools
Risiken durch Open-Source-Lizenz-Kontamination
- Selbst wenn man Eigentumsrechte an KI-generiertem Code hat, bleibt die Frage separat, ob dieser Code unsichtbare Open-Source-Lizenzpflichten mit sich bringt
- KI-Coding-Tools werden mit großen Mengen öffentlichen Codes trainiert, darunter auch Code unter Copyleft-Lizenzen wie GPL oder LGPL
- Copyleft-Lizenzen bewirken, dass bei der Verbreitung abgeleiteter Werke Offenlegungspflichten unter derselben Lizenz entstehen
- Wer ein abgeleitetes Werk aus GPL-Code verbreitet, muss den eigenen Quellcode unter derselben Lizenz offenlegen
- Unwissen über die Lizenz ist keine tragfähige Verteidigung
- Der Maßstab für das rechtliche Risiko ist nicht funktionale Ähnlichkeit, sondern wesentliche und weitgehend wörtliche Übernahme
- Ein Ergebnis, das sich wie GPL-Code verhält
- und ein Ergebnis, das GPL-Code nahezu unverändert reproduziert
- sind rechtlich unterschiedliche Fälle
- Das Risiko konzentriert sich auf wörtliche Übernahme, aber ohne Scan ist oft schwer erkennbar, welcher Fall in einer Codebasis vorliegt
- Beim chardet community dispute Anfang 2026 wurde chardet mit Claude neu geschrieben und unter MIT-Lizenz weiterverteilt; darüber entstand Streit, ob das als Clean-Room-Implementierung gelten könne
- Dabei handelte es sich nicht um ein Gerichtsverfahren, sondern um einen Community-Konflikt; rechtlich abschließend geklärt wurde die Sache nicht
- Dass eine wortgetreue Kopie von GPL-Code einen Lizenzverstoß darstellt, ist dagegen bereits etabliert
- Noch ungeklärt ist, ob KI-Ausgaben, die Muster aus Trainingsdaten reproduzieren, als wörtliche Kopie einzustufen sind
- In der Praxis von M&A-Beratung wird dieses Risiko bereits ernst genommen; Lizenz-Scans von KI-Codebasen sind Teil von Due-Diligence-Prüfungen geworden
- Doe v GitHub befasst sich mit der Frage, ob Copilot lizenzierten Code ohne Quellenangabe reproduziert; Stand April 2026 ist das Verfahren weiterhin beim Ninth Circuit anhängig
- Die erste Instanz hat zwar den Großteil der Ansprüche abgewiesen, die Berufung läuft jedoch weiter
- Unabhängig vom Ausgang des Verfahrens hat GitHub duplicate detection filters eingeführt, und auch die Branchenpraxis hat sich verändert
Was praktisch sofort zu tun ist
-
Lizenz-Scan durchführen
- Bei KI-unterstützten Codebasen ist es wichtig, zuerst einen Open-Source-Lizenz-Scan laufen zu lassen
- FOSSA — ein breit genutztes Komplett-Tool im Enterprise-Bereich
- Snyk Open Source — gute GitHub-Integration, daher leicht in Entwickler-Workflows einpassbar
- Black Duck — häufig Standard bei M&A-Due-Diligence
- Solche Tools scannen eine Codebasis auf Übereinstimmungen mit bekannten Open-Source-Bibliotheken und die dazugehörigen Lizenzen
-
Menschliche kreative Beiträge dokumentieren
- Materialien zum Nachweis wesentlicher menschlicher Urheberschaft entstehen im normalen Engineering-Prozess ohnehin, entfalten aber mehr Wirkung, wenn sie bewusst aufbewahrt werden
- Commit-Messages sollten nicht nur das KI-Ergebnis selbst, sondern festhalten, was warum geändert wurde
- Formulierungen wie „Restructured Claude’s module architecture, rejected initial state management approach, rewrote error handling from scratch“ können als Beleg dienen
- Bleibt nur ein Eintrag wie „Add rate limiting module“, ist der menschliche Beitrag schwerer erkennbar
- Auch Interaktionsprotokolle von Claude Code und Cursor sollten per Export oder Screenshot gesichert werden
- Designdokumente, ADRs und Notizen, die vor dem generierten Code entstanden sind, können als Hinweis dienen, dass die Struktur zuerst vom Menschen festgelegt wurde
-
IP-Klauseln im Arbeitsvertrag prüfen
- Im Vertrag sollten die Abschnitte intellectual property, IP assignment und work product direkt überprüft werden
- „Während der Arbeitszeit geschaffene Arbeitsergebnisse“ ist enger als „mit Unternehmensressourcen geschaffene Arbeitsergebnisse“
- „Im Zusammenhang mit dem Geschäft des Unternehmens“ ist enger als „jede Softwareentwicklung“
- Die Formulierung company-licensed tools kann selbst bei Privatprojekten Spuren der Nutzung von KI-Tools relevant machen
- Wer ein unabhängiges Projekt verfolgt, sollte
- vorab ein schriftliches carveout vereinbaren
- strikt auf private Geräte, private Zeit und private Tools trennen
- möglicherweise trotzdem das Risiko eines Unternehmensanspruchs einkalkulieren
-
Typ der Anthropic-Bedingungen prüfen
- Vor einem kommerziellen Release sollte anthropic.com/legal geprüft und der Unterschied zwischen consumer terms und commercial terms betrachtet werden
- free / Pro übertragen zwar die Rechte an Ausgaben auf den Nutzer, bieten aber einen engeren Umfang bei IP indemnification
- API / enterprise sehen neben der Übertragung der Rechte an Ausgaben auch weitergehenden Schutz bei Urheberrechtsvorwürfen vor, die aus genehmigter Nutzung und den Ausgaben entstehen
- Solche Freistellungen lösen jedoch nicht automatisch Probleme wie GPL-Kontamination innerhalb der eigenen Codebasis
- Dieser Bereich muss durch Lizenz-Scans und interne Governance selbst gesteuert werden
Was feststeht und was offen bleibt
- Relativ klar sind bereits drei Punkte
- Werke ohne menschliche Urheberschaft genießen keinen Urheberrechtsschutz
- Die work-for-hire doctrine kann unabhängig davon greifen, auf welche Weise der Code erzeugt wurde
- Die wortgetreue Übernahme von GPL-Code stellt einen Lizenzverstoß dar
- Noch nicht klar entschieden sind zwei andere Fragen
- wie viele menschliche Anweisungen und Überarbeitungen in agentischen Workflows für ausreichende Urheberschaft nötig sind
- ob eine KI-Ausgabe, die Muster aus Trainingsdaten reproduziert, als wörtliche Kopie zu bewerten ist
- Ob diese Fragen in naher Zukunft in große Gerichtsverfahren münden, bleibt reine Spekulation
- In der Praxis werden diese Unsicherheiten jedoch oft früher in M&A-Due-Diligence und bei institutionellen Investment-Prüfungen relevant als vor Gericht
- Käufer und Investoren stellen solche Fragen bereits als Bedingung für den Abschluss von Transaktionen; selbst wenn das aktuell noch nicht ansteht, ist es von Vorteil, Dokumentation und Scans frühzeitig vorzubereiten
1 Kommentare
Hacker-News-Kommentare
Das sollte man in derselben Kategorie sehen wie die Rechtsprechung zu KI-generierten Bildern
Wie schon in Zarya of the Dawn geklärt wurde, waren die von Menschen geschriebenen Elemente geschützt, KI-generierte Bilder dagegen nicht, und auch vom Menschen ausgewählte, per Prompt erzeugte und kuratierte Charakterdesigns bekamen keinen Urheberrechtsschutz.
Bei Code sehe ich das nicht anders. Claude anzuweisen, eine Funktion zu erstellen, ist eher damit vergleichbar, Midjourney Frames erzeugen zu lassen, als die Funktion selbst zu schreiben.
Dass Ingenieure das anders empfinden, liegt meist an der Compiler-Analogie: Ein Compiler ist ein deterministisches Werkzeug, das bei gleichem Input denselben Output liefert, ein LLM aber nicht. Genau hier zieht auch das Copyright Office die Grenze, und bei Bildern ist man zuerst zu diesem Schluss gekommen.
Es ist auch unklar, ob schon die Tatsache, dass jemand denselben Prompt erneut verwenden und etwas Ähnliches reproduzieren könnte, den Rechtsanspruch dieser Person an sich entwertet.
Eine cert denial stellt kein geltendes Recht fest
Der Supreme Court lehnt die Annahme einer Berufung oft aus Gründen ab, die mit der Sache selbst nichts zu tun haben, daher klärt das allein die Streitfrage nicht landesweit.
Dass der Supreme Court die Thaler-Berufung nicht verhandelt hat, bedeutet weder, dass er die Argumentation der Vorinstanz gebilligt noch dass er landesweit ein abschließendes Ergebnis festgelegt hat; es heißt nur, dass die Entscheidung des DC Circuit bestehen bleibt, die Position des Copyright Office fortgilt und bislang kein Gericht gegenteilig entschieden hat.
Der jetzt zitierte Wortlaut steht allerdings nicht mehr im TFA.
Mir fällt keine Präzedenzentscheidung ein, die bestätigt, welche der aufgezählten Elemente ausreichen, um Urheberschaft anzuerkennen.
Insbesondere würde ich gern wissen, ob das wiederholte Zurückweisen von Ergebnissen und das Lenken in eine andere Richtung jemals als menschliche Urheberschaft anerkannt wurde.
Was derzeit klar ist: Von Menschen nicht geschriebene Codeanteile kann man disclaimen, und das Copyright Office verlangt tatsächlich Offenlegung und Disclaimer. Wenn jemand zitierfähigere Quellen hat, würde ich sie gern sehen.
Der zentrale rechtliche Effekt einer Aufhebung wäre doch gerade der Verlust dieser Präzedenzwirkung.
Präzedenzfälle, die nie den Supreme Court durchlaufen haben, kann man theoretisch jederzeit angreifen, praktisch funktionieren sie aber meist wie geltendes Recht, bis sie aufgehoben werden. Dieser Fall scheint nicht groß anders zu sein.
Ist mein Code Review meaningful?
Gilt von mir geänderter und editierter generierter Code als menschliche Urheberschaft?
Eine cert denial bedeutet nur, dass der Supreme Court den Fall nicht angenommen hat, nicht dass er die Argumentation der Vorinstanz billigt oder landesweit entschieden hat.
Die DC-Circuit-Entscheidung steht weiter und die Position des Copyright Office ist konsistent, aber das ist eher eine gefestigte doctrine als vom Supreme Court endgültig festgestelltes Recht.
Ich meine zwar, dass die Person, die den Agenten anweist, das Copyright am Ergebnis haben sollte, aber schon die Grundlage, die diesen Agenten überhaupt dazu befähigt, beruht meines Erachtens auf unrechtmäßig angeeignetem IP
Gerade im OSS-Bereich macht mir Sorgen, dass so etwas copyright washing ermöglicht, und deshalb denke ich, dass OSS-Entwickler ihre Arbeit mit der stärksten Copyleft-Lizenz veröffentlichen sollten, die sie innerhalb ihres zumutbaren Rahmens vertreten können.
https://jackson.dev/post/moral-ai-licensing/
Wenn man das Original immer noch besitzt, was genau wurde dann gestohlen?
Auch in Dowling v. United States, 473 U.S. 207 (1985) wurde entschieden, dass unautorisierter Verkauf kein „stolen, converted or taken by fraud“-Eigentum im Sinne des National Stolen Property Act ist.
Wenn ein Gericht den Output eines LLM als hinreichend abgeleitet einstuft, erst recht wenn das LLM mit verletzenden Originalen trainiert wurde, dann haftet die Person, die diesen abgeleiteten Output weiterverbreitet, für Urheberrechtsverletzung.
Das Erstellen eines LLM mag transformativ sein, der konkret verletzende Output ist es aber nicht.
Wenn Copyright Fortschritt also eher behindert, halte ich Ausnahmen deshalb für völlig plausibel.
Community for Creative Non Violence v. Reid(https://en.wikipedia.org/wiki/Community_for_Creative_Non-Violence_v._Reid) zeigt, dass der Auftraggeber nicht allein deshalb Autor wird, weil er die Arbeit beauftragt und eine Richtung vorgibt; Urheber ist die Person, die die Arbeit tatsächlich ausführt.
Per Vertrag kann man Rechte übertragen, aber seit Fällen wie dem Affenselfie gilt auch als gefestigt, dass Copyright nur Menschen zusteht.
Ein LLM ist kein Mensch, kann also kein Copyright besitzen, und ohne rechtliches Copyright gibt es auch kein Recht, das es dir übertragen könnte.
Wenn ich Code schreibe, bin ich ebenfalls von unzähligen Quellcodes beeinflusst, die ich über Ausbildung und Karriere hinweg gesehen habe, und bei LLMs ist es insofern ähnlich, als sie ihren späteren Output auf Basis des Gesehenen verfeinern.
Natürlich kommt sofort der Einwand „diesen Code durfte es nicht lesen“, aber auch diese Logik überzeugt mich nicht. Der Großteil des Codes, aus dem ich gelernt habe, war urheberrechtlich geschützt, und sofern es nicht mein privater Code war, lagen die Rechte meist bei anderen. Sogar NDA-geschützter oder verteidigungsrelevanter geheimer Code hat meine spätere Art zu programmieren beeinflusst.
In der Kunst ist es genauso. Bei Fotos waren es Ansel Adams, bei Malerei Bob Ross und viele andere Lehrer; ich habe Fragmente aus fremden Arbeiten gesehen, sie mit meiner eigenen Sicht vermischt und etwas anderes daraus gemacht.
Trotzdem würde ich nicht sagen, dass allein dieses Einflussverhältnis jemandem Rechte an meinem Ergebnis gibt.
Auch jüngere Kollegen haben aus meinem Code gelernt, und ich habe Bücher über Softwareentwicklung geschrieben. Ich hoffe, dass irgendwann auch meine Kunst so wertvoll wird, dass jemand etwas davon in sich aufnimmt.
Schon lange vor LLMs wollte ich nie, dass meine Arbeit mit mir versiegelt wird und meine Ideen mit ins Grab gehen.
Letztlich stehen wir alle auf den Schultern von Riesen, und ohne frühere Arbeiten in uns aufzunehmen, hätten wir kaum einen Bruchteil dessen erreicht, was wir heute erreicht haben.
In ein paar Jahrzehnten werde ich tot sein und mein Name schnell vergessen, aber wenn die von mir geschaffene Software, meine Fotos oder Gemälde kleine Wellen durch die Zeit schlagen, fühlt sich das wie eine kleine Form von Unsterblichkeit an.
Ich würde mir wünschen, dass keine generierten Kommentare mehr auf HN gepostet werden
Laut Regeln ist das nicht erlaubt, und ich habe dieses Muster jetzt schon über 30 Mal gesehen.
Natürlich kann ich nicht zu 100 % sicher sein, aber die Softwareeinschätzung und das Gesamtmuster sind ziemlich überzeugend.
Siehe https://news.ycombinator.com/newsguidelines.html#generated und https://news.ycombinator.com/item?id=47340079
Ich habe für die Antwort ein KI-Assistenzsystem verwendet und werde das künftig nicht mehr tun.
Diese Frage ist als Gedankenspiel interessant, aber in der Realität wird es am Ende vermutlich die Seite mit dem Geld sein, die gewinnt
Zu erwarten, dass Anthropic Claude Code nicht besitzen kann, nur weil Claude es geschrieben hat, wirkt auf mich wie Wunschdenken.
Nicht jedes Land stellt sich stillschweigend auf die Seite der Kapitalkräftigen, daher ist ein Ausgang schwer vorherzusagen.
Nicht weil Claude es geschrieben hat, sondern weil die Arbeitsverträge der Ingenieure, die es angewiesen haben, eher dafür sprechen, dass die Firma die Rechte hält.
Spannender ist dagegen die Frage zu DMCA-Takedowns: Für einen DMCA-Anspruch muss der Anspruchsteller in gutem Glauben behaupten, Copyright-Inhaber zu sein.
Wenn ein Gericht später zu dem Schluss kommt, dass die Codebasis überwiegend von KI geschrieben wurde und daher nicht urheberrechtlich schützbar ist, könnten diese 8.000 Takedowns als DMCA-Ansprüche in bad faith angegriffen werden.
Das ist als Rechtsfrage realistischer und trennschärfer als die Eigentumsfrage selbst.
Im US-Rechtssystem scheint relativ klar zu sein, dass ein Modell kein Mensch ist und daher kein Eigentum besitzen kann; ebenso kann es geistiges Eigentum, das es selbst nicht besitzt, nicht per Vertrag weiterübertragen.
Trotzdem scheinen Strafverfolgungsbehörden wenig Interesse daran zu haben, dass grok CSAM oder revenge porn erzeugt, weshalb es seltsam wirkt, als wolle man am Ende nur die guten Dinge besitzen und sich den schlechten Verantwortlichkeiten entziehen.
Aus Sicht der Unternehmen wirkt das wie ein ziemlich gerissener Ansatz
Erst baut man etwas mit claude code, und erst danach macht man sich Gedanken darüber, wem dieser Code eigentlich gehört.
Der aktuelle gold rush um uns herum zeigt meines Erachtens die Kurzsichtigkeit des Managements. Selbst die EMs in meiner Firma drängen darauf, Claude so schnell wie möglich einzusetzen.
Erstens: Wenn man sich zu sehr auf Claude Code verlässt, verliert man das Verständnis für die Codebasis.
Zweitens: Gute Entwicklungspraxis wie XP oder Code Reviews erodiert. Am Ende reviewt Claude den von Claude geschriebenen Code.
Drittens: Teamarbeit leidet. Dinge, die früher zwischen FE- und BE-Teams aufgeteilt waren, lassen sich für einen einzelnen Entwickler vom Backend bis zum Frontend leichter und billiger am Stück erledigen.
Viertens: Früher hieß es, der Code selbst sei die Dokumentation, also könne man Kommentare ignorieren. Jetzt muss man wegen der Kontextgrenzen von Claude wieder Erklärungen für Claude dazuschreiben. Wenn Menschen etwas nicht verstanden, war das angeblich ihr Problem; für Claudes engen Kontext plötzlich Rückschritte zu akzeptieren, wirkt unfair.
Ich könnte noch mehr nennen, aber die treibende Kraft hinter diesem Kulturwandel ist letztlich Geld. Deshalb nenne ich das einen Goldrausch und schaue mit Popcorn zu.
Als Copilot neu war, gab es klare Warnungen, ihn wegen Lizenz- und Rechtefragen nicht für Unternehmenscode zu verwenden.
Was hat sich seitdem geändert? Hat sich die Stimmung gedreht, weil Anthropic rechtliche Verteidigung und indemnify anbietet?
Backend und Frontend müssen aufeinander abgestimmt entworfen werden, und wenn die Teams getrennt sind, sind die Koordinationskosten oft sogar höher.
Wenn die mentalen Modelle der Menschen langsam verhungern, wird es auch schwieriger, bei Störungen belastbar zu erklären, wie etwas funktioniert und wie es weitergehen soll.
Selbst wenn falsche Verallgemeinerungen eingebaut sind, können KI-Systeme den Code reviewen und freigeben, und dann weiß man irgendwann nicht mehr, wer eigentlich noch am Steuer sitzt.
Meist ist es besser, wenn das Team gemeinsam Anforderungen und Fallstricke bespricht, die Umsetzungsverantwortung dann aber bei einer Person liegt.
Der EU AI Act legt hier noch eine zusätzliche Ebene darüber
Artikel 50 verlangt, dass KI-generierte oder manipulierte Inhalte gegenüber Endnutzern offengelegt werden, und diese Transparenzpflicht trifft nicht den Modellanbieter, sondern den deployer.
Selbst wenn die Copyright-Frage also zugunsten des menschlichen Prompters geklärt würde, hätten Unternehmen, die KI-unterstützte Ergebnisse in großem Maßstab verbreiten, eine eigenständige Offenlegungspflicht.
Die meisten machen das bisher nicht ordentlich.
Eigentumsfrage und Offenlegungspflicht sind voneinander unabhängig, doch Organisationen werfen beides oft durcheinander.
Diese Vorschrift wirkt eher auf Videos zugeschnitten, die KI-generiertes Material als echt erscheinen lassen, als auf Code für interne Anwendungen.
Wenn man einem Werkzeug eine Spezifikation für den gewünschten Code gibt, erscheint mir ziemlich klar, dass man bereits kreativen Input geliefert hat
Im Grunde ist ein Compiler doch nicht so anders. Ein LLM agent wirkt nur wie ein viel fortgeschritteneres Werkzeug, das mit deutlich weniger detaillierten Spezifikationen zu Ergebnissen kommt als ein traditioneller Compiler.
Um den Code zu besitzen, musste der Auftragnehmer die Rechte ausdrücklich abtreten.
Wenn ich zum Beispiel nur den Prompt „schreib mir in Python einen Rate Limiter“ eingebe, habe ich weder die API noch den Request-Bucket-Algorithmus noch den Speicherort der Counter festgelegt.
Ich habe nur Fakten benannt, und Fakten sind ihrem Wesen nach nicht kreativ.
Außerdem werden bei einem Compiler die resultierenden Binärdateien nicht als separates Werk behandelt. Das ist ähnlich wie bei der Umwandlung eines Bildformats in PDF: Es bleibt dasselbe Werk.
Bei einem LLM ist das anders. Der Input ist möglicherweise nicht urheberrechtlich geschützt, und der Output ist keine mechanische Transformation, sondern enthält Auswahlentscheidungen.
In der Praxis kann derselbe Prompt bei zehn Durchläufen zehn inhaltlich unterschiedliche Ergebnisse liefern.
Deshalb bezweifle ich, dass Prompting auf beliebigem Niveau schon als hinreichende Kreativität anerkannt wird.
Entscheidend ist nicht, ob man Input gegeben hat, sondern ob die kreative Ausdrucksform des Outputs menschliche Urheberschaft widerspiegelt.
Bei traditionellen Compilern verantwortet der Programmierer jede Ausdrucksentscheidung im Source Code, bei LLMs gibt der Programmierer eher die Absicht vor, während Struktur, Benennungen, Muster und Umsetzung als Ausdrucksentscheidungen vom Modell kommen.
Ob dieser Unterschied rechtlich entscheidend ist, ist derzeit Gegenstand von Allen v. Perlmutter; die Summary-Judgment-Briefings für Anfang 2026 sind abgeschlossen, sodass das die nächste wichtige Leitentscheidung werden könnte.
Das alles ist theoretisch interessant, in der Praxis aber meist nicht besonders wichtig
Fast niemand glaubt ernsthaft, dass der eigene Code einen starken moat darstellt, und auch das Gefühl, dass Code überhaupt urheberrechtlich relevant ist, ist in der Praxis oft schwach ausgeprägt.
Ich selbst habe unter verschiedenen Arbeitgebern ähnliche Codefragmente immer wieder verwendet, und den meisten Ingenieuren dürfte es ähnlich gehen. Auch Code von Orten wie Stack Overflow wird oft genutzt, ohne die Rechtezuordnung besonders streng zu prüfen.
Dieses Thema taucht meist in verbitterten Auseinandersetzungen auf. Dass Oracle Google verklagt hat, weil Android seine APIs zu ähnlich nachgebildet habe, ist ein typisches Beispiel, und der Supreme Court hat das am Ende als fair use eingestuft.
Es gab auch Fälle, in denen Hochfrequenz-Hedgefonds gegen ehemalige Mitarbeiter geklagt haben, und in den USA kann grundsätzlich jeder aus jedem Grund klagen.
Ein Streit wie Ellison gegen Page und Brin bis hin zum Supreme Court ist also denkbar, aber in 99,9 % der Fälle hat das im Arbeitsalltag wohl kaum Auswirkungen.
https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
Dort wird Code sehr häufig als gewaltiges IP und Geschäftsgeheimnis betrachtet.
Als CTO sehe ich oft überraschte Gesichter, wenn ich sage, dass Code im Allgemeinen gar nicht so ein großes Geheimnis ist.
Ein Unternehmen hätte fast einen großen Vertrag platzen lassen, weil dafür Quellcode-Offenlegung unter NDA nötig gewesen wäre; nachdem ich erklärt hatte, warum diese Reaktion überzogen war, wurde es zwar verstanden.
Trotzdem ist diese alte Denkweise immer noch stark verbreitet.
Genau davon sprechen wir hier doch: Wenn jeder einzelne Buchstabe des zu schreibenden Codes durch die benötigten APIs faktisch vorgegeben ist, gibt es darin weder künstlerischen Ausdruck noch Copyright.
Wenn man aber eine völlig neue API entwirft, könnte genau das Schutz genießen.
Die kurzen Schnipsel, die du nennst, vielleicht nicht, aber in größerem Umfang gehen sowohl Unternehmen als auch Einzelpersonen im Allgemeinen davon aus, dass Code urheberrechtlich geschütztes geistiges Eigentum ist.
Wenn Code nicht urheberrechtlich geschützt wäre, woher würde dann die GPL ihre Wirkung beziehen?
Warum müssten Projekte allein wegen des Verdachts, dass Microsoft-Code in ReactOS eingeflossen sein könnte, monatelang oder jahrelang in einen locked-down review mode gehen?
Warum würden Unternehmen in Arbeitsverträgen ausdrücklich den Besitz des Copyrights an Code festschreiben?
Abgesehen von APIs, Interoperabilität oder allzu trivialen Implementierungen scheint doch fast jeder die Schutzfähigkeit von Code anzuerkennen.
Frag einfach Emulator-Entwickler oder ReactOS-Entwickler.
https://reactos.org/forum/viewtopic.php?t=21740
Auch die Aussage „Für Code, den Claude Code oder Cursor erzeugt hat und den du nicht sinnvoll verändert hast, hat möglicherweise niemand Copyright“ kennt Ausnahmen
Wenn dieser Code wesentliche Auszüge aus bestehenden Werken wörtlich wiederkäut, kann der ursprüngliche Urheber sein Copyright weiterhin geltend machen, und dann geht es unmittelbar um Urheberrechtsverletzung.