Wem gehört generierter Code? Wir haben die falsche Frage sauber beantwortet.

Die Frage, die wir uns selbst gestellt haben

Wir entwickeln Software und betreiben sie. Unsere Kunden kaufen in der Regel eine Lizenz an einer Lösung, die bei uns entsteht und bei uns läuft. Wer so lebt, muss irgendwann sagen können, wem der Code gehört, den er lizenziert. Solange Menschen ihn schreiben, ist die Antwort langweilig. Seit ein Teil davon generiert wird, ist sie es nicht mehr.

Die Frage, die wir uns gestellt haben, war zuerst eine andere als die, mit der ich heute herauskomme. Sie lautete: Wem gehört der Inhalt, den ein Modell erzeugt? Dem Betreiber, der das Modell anbietet? Dem Unternehmen, das es gebaut hat? Oder gesamthaft den Urhebern, deren Werke im Training steckten? Klar schien uns die Antwort nicht. Für alle drei liessen sich Argumente finden, und je nachdem, wen man fragte, bekam man eine andere.

Die Antwort, mit der wir seither arbeiten

Mein Geschäftspartner war an einer Veranstaltung, an der genau diese Frage geklärt wurde. Das Ergebnis, verkürzt: Unveränderter KI-Code gehört niemandem. Erst die manuelle Anpassung durch einen Menschen führt zum Urheberrecht. Mit diesem Wissensstand arbeiten wir seither.

Für diesen Take wollte ich es genauer wissen. Das Ergebnis vorweg: Die Aussage stimmt. Sie ist nur kleiner, als sie klingt.

Was das Gesetz hergibt

Das Schweizer Urheberrechtsgesetz schützt in Artikel 2 geistige Schöpfungen mit individuellem Charakter, und Artikel 6 sagt, wer Urheber ist: die natürliche Person, die das Werk geschaffen hat. Kein Mensch, kein Werk. Das Eidgenössische Institut für Geistiges Eigentum formuliert es seit 2023 in einem Satz, den man sich merken kann: Geschützt ist in der Schweiz nur, was von einem Menschen stammt.

Die EU kommt über den gleichen Werkbegriff zum gleichen Ergebnis. Das US Copyright Office hat es im Januar 2025 ausführlich aufgeschrieben und dabei einen Punkt festgehalten, der viele überrascht: Prompts allein genügen nicht. Wer noch so lange am Prompt feilt, steuert das Ergebnis nicht so weit, dass daraus eine eigene Schöpfung wird.

Also: Der Modellbetreiber hat kein Recht am Output, der Modellersteller auch nicht. Die Urheber der Trainingsdaten haben keines am erzeugten Ergebnis. Und die Person am Prompt hat auch keines, solange sie nichts Eigenes beiträgt. Übrig bleibt: niemand. Genau die Antwort von der Veranstaltung.

Der Riss

In den letzten zwei Wochen las ich einen Beitrag, der mein Bild wieder getrübt hat. Er handelte davon, dass Modelle Trainingscode fast wörtlich wiedergeben können. Wenn das stimmt, ist der Satz «gehört niemandem» schlicht falsch, sobald es passiert. Denn was das Modell wiedergibt, war vorher das Werk eines Menschen und bleibt es.

Die Zahlen dazu sind unbequem. GitHub filtert bei Copilot Vorschläge, die zu nah an öffentlichem Code liegen, und nennt die Trefferquote seit Jahren mit unter einem Prozent der Vorschläge. Das klingt beruhigend, bis man nachrechnet, wie viele Vorschläge ein Team in einem Jahr annimmt. Schlimmer ist der zweite Befund: Eine Untersuchung aus diesem Jahr findet bei offenen Code-Modellen zwischen 0,3 und 3,4 Prozent Funktionen, die funktional memoriert sind. Nicht Zeichen für Zeichen gleich, sondern in der Sache dasselbe, nur anders geschrieben. Kein Textscanner der Welt findet das.

In Deutschland hat das Landgericht München im November 2025 im Verfahren der GEMA gegen OpenAI entschieden, dass memorierte Inhalte eine Vervielfältigung darstellen. Das Urteil ist nicht rechtskräftig, die Berufung läuft. Aber die Richtung ist gesetzt, und sie ist die naheliegende.

Für uns heisst das: Steckt geschützter Code im Output, bleibt er geschützt. Wer ihn ausliefert, verletzt Urheberrecht. Auch wer nichts davon wusste, denn Unterlassung und Beseitigung setzen kein Verschulden voraus. Und bei Code kommt die Lizenz dazu. Ein Fragment aus einem Projekt unter Copyleft bringt seine Bedingungen mit, inklusive Offenlegung. Entweder man erfüllt sie, oder man verletzt sie.

Der Punkt, der mich am meisten getroffen hat

Ich hatte gedacht, das Urheberrecht sei unser Fundament. Ist es nicht.

Artikel 17 des Urheberrechtsgesetzes weist dem Arbeitgeber die Rechte an Programmen zu, die Mitarbeitende schaffen. Das ist eine Zuweisungsnorm. Sie verteilt, was existiert. Wo kein Werk entsteht, ist nichts zu verteilen. Bei rein generiertem Code läuft der Artikel leer, und wir haben kein Ausschliesslichkeitsrecht, das wir jemandem entgegenhalten könnten.

Eine Lizenz über ungeschützten Code wirkt deshalb nur zwischen den Vertragsparteien. Gegenüber unserem Kunden hält sie. Gegenüber einem Dritten, der denselben Code hat, hält sie nichts. Das Wettbewerbsrecht hilft dabei kaum: Die Bestimmung gegen die Übernahme fremder Arbeitsergebnisse gilt in der Lehre als weitgehend wirkungslos, sie hat in dreissig Jahren kaum Spuren hinterlassen.

Was bleibt, ist das, was wir ohnehin haben: der Vertrag mit dem Kunden und der Schutz unserer Geschäftsgeheimnisse. Für ein Haus, das Software lizenziert und betreibt, ist das die eigentliche Grundlage. Der Betrieb ist hier übrigens der stärkere Teil. Wer die Lösung betreibt, gibt den Code gar nicht erst aus der Hand.

Was die Anbieter versprechen, und was nicht

Ein Blick in die Bedingungen lohnt sich. OpenAI, Anthropic, GitHub, Microsoft, Google und Mistral treten dem Nutzer die Rechte am Output ab. Fast alle schreiben dabei zwei Wörter dazu: falls vorhanden. Sie geben, was sie haben, und das ist möglicherweise nichts. Der Vertrag schafft kein Recht, wo das Gesetz keines vorsieht.

Interessanter ist die Freistellung, also die Zusage, im Streitfall für den Kunden einzustehen. Die gibt es nur in den Geschäftsplänen, nur für unveränderten Output und nur unter Bedingungen. Auf den privaten Konten, mit denen viele arbeiten, gibt es sie gar nicht. Bei GitHub ist der Filter gegen doppelten Code seit April dieses Jahres keine Voraussetzung mehr für die Zusage. Ausschalten würde ich ihn trotzdem nicht.

Bei offenen Modellen ist es einfacher und unbequemer zugleich: Die Lizenz regelt die Gewichte, nicht den Output. Qwen 3.8 27B steht unter Apache 2.0, und über das, was das Modell erzeugt, steht dort nichts. Was gilt, ist allein das Urheberrecht.

Kennzeichnen oder regeln?

Meine praktische Frage war: Braucht es Vertragsanpassungen, und muss generierter Inhalt gekennzeichnet werden?

Zur Kennzeichnung: Der AI Act der EU verlangt seit dem 2. August 2026 Transparenz für KI-erzeugte Inhalte und erfasst auch Schweizer Anbieter, wenn das Ergebnis in der EU genutzt wird. Quellcode nimmt die Kommission in ihren Erläuterungen aber ausdrücklich aus. In der Schweiz gibt es bis heute gar keine Kennzeichnungspflicht. Für Code besteht also keine Pflicht. Für generierte Texte und Bilder gegenüber EU-Kunden schon.

Zum Vertrag: Ja, aber nicht wegen einer Pflicht. Sondern weil der Vertrag genau dort trägt, wo das Urheberrecht nichts hergibt. Wer nicht regelt, wem die Ergebnisse gehören und wer bei Ansprüchen Dritter einsteht, verlässt sich auf ein Recht, das bei generiertem Material vielleicht nicht existiert.

Was wir daraus machen

Fünf Dinge, die keine Rechtsabteilung brauchen.

Erstens, Filter gegen doppelten Code einschalten und eingeschaltet lassen. Zweitens, generierten Code genauso prüfen wie handgeschriebenen, mit Namen unter dem Review. Drittens, vor der Auslieferung einen Scan auf fremde Fragmente, im Wissen, dass er die funktionale Memorisierung nicht findet. Viertens, den menschlichen Beitrag nachvollziehbar halten. Wer später Schutz behaupten will, muss ihn belegen, und ohne saubere Historie wird das schwierig. Fünftens, eine Klausel im Kundenvertrag, die Nutzungsrechte, Verantwortung und das Einstehen für Drittansprüche regelt, ohne so zu tun, als sei alles urheberrechtlich geschützt.

Und ein Satz zur Ehrlichkeit: Ich bin kein Jurist. Das hier ist keine Rechtsberatung, sondern das Ergebnis einer Abklärung für den eigenen Betrieb, nachlesbar und überprüfbar. Für den eigenen Vertrag würde ich jemanden fragen, der dafür haftet.

Das Urteil

Wir haben die falsche Frage sauber beantwortet. «Wem gehört der Output» ist die Frage eines Verlags. Wir sind kein Verlag. Für uns lautet sie: Was liefern wir aus, welche fremden Rechte könnten darin stecken, und was steht dazu im Vertrag?

Auf diese Frage kann man heute antworten, ohne auf ein Gericht zu warten. Und warten müsste man lange: In der Schweiz gibt es zu all dem noch keinen einzigen Entscheid. Wo genau die Schwelle liegt, ab der menschliche Bearbeitung Schutz schafft, hat hier noch niemand festgelegt. Wer sich darauf beruft, beruft sich auf Lehrmeinungen.

Darum: Jetzt bauen. Nicht am Urheberrecht, das entsteht nicht, weil wir es gern hätten. Sondern an den Hausaufgaben, die in unserer Hand liegen.

Nachtrag: Womit man generierten Code durchsucht

Beim Schreiben kam die Frage auf, die mir vorher nicht präsent war: Womit sucht man eigentlich nach fremdem Open-Source-Code im eigenen? Die Werkzeugklasse heisst Snippet-Scanning und ist etwas anderes als die übliche Abhängigkeitsprüfung. Die schaut in die Paketliste, hier geht es um Fragmente mitten im eigenen Quelltext, ohne Lizenzkopf und ohne Herkunftsangabe.

Der Name, der mir gefehlt hat, ist **SCANOSS**. Quelloffen, selbst betreibbar, mit einer eigenen Datenbank bekannter Open-Source-Fragmente, und der naheliegende Einstieg für einen Betrieb unserer Grösse, weil er nichts kostet ausser der Zeit für die Einrichtung.

Daneben gibt es drei kommerzielle Namen. **Black Duck**, früher unter Synopsys geführt, ist der Klassiker im Enterprise-Umfeld und gleicht Prüfsummen gegen eine eigene Wissensdatenbank ab, ab etwa fünf bis sieben Zeilen. **FOSSA** vergleicht auf Funktionsebene und lässt sich von umbenannten Variablen und neuer Formatierung weniger täuschen; seit diesem Jahr arbeitet FOSSA für genau diese KI-Fälle mit SCANOSS zusammen. **FossID** ist auf Snippet-Scanning spezialisiert und im C- und Embedded-Umfeld stark.

Zwei Werkzeuge, die man dafür fälschlich nennt: **ScanCode Toolkit** ist gratis und gut, findet aber Lizenztexte und Copyright-Vermerke, nicht beliebige Fragmente. Ein kopierter GPL-Schnipsel ohne Kopfzeile bleibt unsichtbar. Und **Snyk** prüft Abhängigkeiten und sucht nach Schwachstellen im eigenen Code, ein dediziertes Fragment-Matching ist nicht dokumentiert. Wer Snyk im Einsatz hat, hat diese Frage damit nicht abgedeckt.

Der Filter in GitHub Copilot gehört in eine andere Kategorie. Er vergleicht Vorschläge gegen öffentliche Repositories auf GitHub, rein textlich, und der Index wird nur alle paar Monate aufgefrischt. Das ist Vorbeugung im Moment des Tippens, keine Prüfung vor der Auslieferung. Beides zusammen ergibt zwei Linien: der Filter beim Entstehen, der Scan vor dem Ausliefern.

Und die unangenehme Grenze, die für alle gilt: Diese Werkzeuge vergleichen Text. Die Untersuchung aus diesem Jahr, die zwischen 0,3 und 3,4 Prozent funktional memorierte Funktionen gefunden hat, beschreibt Code, der dasselbe tut, aber anders geschrieben ist. Davon findet kein Scanner etwas. Ein Scan senkt das Risiko, er beseitigt es nicht. Wer etwas anderes verspricht, verkauft Lizenzen.