KI-Nachbau von Software: Was das Recht erlaubt

Das README von PhotoCraft beschreibt den Photoshop-Nachbau als "clean-room reimplementation". Etwas weiter unten steht, was damit gemeint ist: "implemented from public specs and observed behaviour only. No proprietary code, shaders or assets." Gebaut wurde PhotoCraft mit Claude, unter den Beitragenden des Repositorys steht ein Konto namens claude.

Seit dem Start am 30.09.2026 fragen Nutzer im Issue-Tracker der Craft-Reihe, ob das gut gehen kann. Ein Issue trägt den Titel "You are asking for lawsuits". Die Kurzbeschreibung von PhotoCraft auf GitHub nennt Photoshop inzwischen nicht mehr, das README tut es weiter.

In den bisherigen Teilen dieser Serie ging es darum, was kleine Teams mit Agenten bauen können, wer den Code pflegt und was ein Produkt noch schützt. Dieser Teil fragt, ob man das darf. Das ist keine Rechtsberatung und keine Bewertung des Einzelfalls. Es ist eine Einordnung anhand der Gesetze und Urteile, die für Software im DACH-Raum gelten, und der Fragen, die noch kein Gericht beantwortet hat.

Funktionen sind frei, Code nicht

Das Urheberrecht schützt an Software den Code in all seinen Formen, nicht die Ideen dahinter. So steht es in der europäischen Software-Richtlinie und gleichlautend in § 69a UrhG: "Ideen und Grundsätze, die einem Element eines Computerprogramms zugrunde liegen, einschließlich der den Schnittstellen zugrundeliegenden Ideen und Grundsätze, sind nicht geschützt."

Wie weit das reicht, hat der Europäische Gerichtshof 2012 im Fall SAS Institute entschieden. Ein Unternehmen hatte eine Statistiksoftware nachgebaut, ohne Zugang zum Quellcode und ohne den Code zu dekompilieren. Es hatte das Programm beobachtet, untersucht und getestet. Der EuGH stellte fest, dass weder die Funktionalität eines Programms noch die Programmiersprache noch das Dateiformat eine Ausdrucksform des Programms sind und deshalb nicht unter den Softwareschutz fallen. Würde man die Funktionalität schützen, könnte man Ideen monopolisieren, "zum Schaden des technischen Fortschritts und der industriellen Entwicklung".

Zwei Einschränkungen nennt dasselbe Urteil. Wer sich den Teil des Codes beschafft, der Sprache oder Format umsetzt, und damit ähnliche Teile baut, könnte möglicherweise doch Code vervielfältigen. Und das Handbuch eines Programms ist ein eigenes Werk. Wer daraus Formulierungen, Auswahl und Anordnung übernimmt, kann dessen Urheberrecht verletzen.

Für die Craft-Reihe heißt das: Ein Programm zu bauen, das dasselbe kann wie Photoshop und dieselben Dateien öffnet, ist urheberrechtlich nicht das Problem. Das Problem wäre, Code, Shader, Grafiken oder Texte aus dem Original zu übernehmen. Genau das schließt das README aus.

Was man beim Nachbauen tun darf

Wie man an die Informationen kommt, regelt das Gesetz eigens. Nach § 69d Abs. 3 UrhG darf, wer ein Programm berechtigt nutzt, "das Funktionieren dieses Programms beobachten, untersuchen oder testen, um die einem Programmelement zugrundeliegenden Ideen und Grundsätze zu ermitteln", solange er dabei nur tut, was er beim Laden, Anzeigen und Ausführen ohnehin darf. Laut EuGH kann der Hersteller das auch nicht per Lizenzvertrag verbieten.

Dekompilieren, also den Maschinencode zurück in lesbaren Code übersetzen, ist dagegen nur in engen Grenzen erlaubt. § 69e UrhG erlaubt es, wenn es unerlässlich ist, um ein unabhängig geschaffenes Programm mit anderen zusammenarbeiten zu lassen, also für Interoperabilität. Die so gewonnenen Informationen dürfen ausdrücklich nicht für die Entwicklung eines Programms "mit im wesentlichen ähnlicher Ausdrucksform" verwendet werden. Für einen Nachbau deckt § 69e das Dekompilieren also nicht. Ein späteres EuGH-Urteil, Top System von 2021, erlaubt das Dekompilieren zusätzlich zur Fehlerbehebung, aber nur dafür.

Der Haken in den Nutzungsbedingungen

Hier wird es spannend, denn die Hersteller sehen das anders. Adobes Allgemeine Nutzungsbedingungen fassen Abschnitt 17 in einem Satz zusammen: Adobe erlaube Nutzern nicht, "unsere Produkte zu kopieren oder dies zu versuchen." Verboten ist unter anderem, die Software zurückzuentwickeln, und zwar ausdrücklich "einschließlich, aber nicht beschränkt auf das Überwachen oder Verfolgen der Eingaben und Ausgaben, die durch ein System oder eine Applikation fließen, um dieses System neu zu erstellen". Ein weiterer Punkt verbietet, Ausgaben oder Daten aus Adobe-Programmen zum Trainieren oder Testen von KI-Systemen zu verwenden.

Damit stehen zwei Texte nebeneinander, die sich beim Beobachten eines Programms berühren:

Wo genau die Grenze verläuft, entscheidet im Streitfall ein Gericht. Vertragspartner für Kunden außerhalb Nordamerikas und Japans ist laut den Bedingungen eine irische Adobe-Gesellschaft, es gilt irisches Recht, "es sei denn, sie werden durch lokales Recht verdrängt". Die Gegenüberstellung zeigt aber, worum ein solcher Streit sich drehen würde: um die Frage, ob "beobachten, um Ideen zu ermitteln" und "beobachten, um das System neu zu erstellen" dasselbe sind. Das Gesetz erlaubt das eine ausdrücklich, die Bedingungen verbieten das andere.

Was außerhalb des Urheberrechts schützt

Das Urheberrecht ist nicht das einzige Recht, das ein Nachbau berührt.

• Oberfläche. Eine grafische Benutzeroberfläche ist laut EuGH (BSA, 2010) kein geschütztes Programm, kann aber als eigenes Werk geschützt sein, wenn sie eine eigene geistige Schöpfung ist. Elemente, die nur durch ihre technische Funktion bestimmt sind, fallen nicht darunter. Werkzeugleisten und Menüs sind meist funktional, eine ganze Gestaltung kann es weniger sein.
• Namen. Nach § 14 MarkenG ist ein Zeichen verboten, wenn Verwechslungsgefahr mit einer Marke besteht, bei bekannten Marken auch, wenn ihr Ruf ausgenutzt wird. Ob "PhotoCraft" mit "Photoshop" verwechselbar ist, ist eine Einzelfallfrage, die wir nicht bewerten. Das Projekt weist im README darauf hin, dass es mit Adobe nichts zu tun hat. In einem weiteren Issue schlägt ein Nutzer vor, auf Wörter aus Adobe-Produktnamen ganz zu verzichten.
• Nachahmung. § 4 Nr. 3 UWG verbietet unter Mitbewerbern Nachahmungen, die über die Herkunft täuschen, den Ruf des Originals unangemessen ausnutzen oder auf unredlich erlangten Kenntnissen beruhen.
• Geschäftsgeheimnisse. Ein Produkt zu beobachten, zu untersuchen, zurückzubauen oder zu testen, ist nach § 3 GeschGehG ausdrücklich erlaubt, wenn es öffentlich verfügbar ist. Bei einem Produkt im eigenen Besitz gilt das nur, wenn man keiner Pflicht unterliegt, das zu unterlassen. Ob eine Lizenzklausel eine solche Pflicht begründet, ist offen.
• Dateiformate. Adobe veröffentlicht selbst eine Spezifikation des PSD-Formats, "for 3rd parties to read and write the Photoshop native file format". Für die Office-Formate gibt Microsoft mit dem Open Specification Promise eine Zusage, aus Patenten nicht gegen Implementierungen vorzugehen. Das betrifft Patente, nicht Marken oder Urheberrecht.

Clean Room mit einem Modell, das das Original kennen kann

"Clean Room" ist kein Rechtsbegriff, sondern eine Methode. Ein bekanntes Beispiel stammt aus der Frühzeit des PCs, als Phoenix Technologies das BIOS des IBM-PC nachbaute: Ein Team untersuchte das Original und beschrieb nur, was es tut. Ein zweites Team, das den IBM-Code nie gesehen hatte, schrieb daraus neuen Code. Laut Computerworld funktionierte das Ergebnis "for all intents and purposes" identisch. Die Trennung der Teams ist der Beweis, dass nichts kopiert wurde.

Mit einem Sprachmodell wird diese Trennung unscharf. Ein Modell kann den Code, den es nachbauen soll, im Training gesehen haben, und je nach Arbeitsweise bekommt es ihn sogar als Eingabe. Dass Modelle Inhalte aus dem Training speichern und wiedergeben können, hat das Landgericht München I im November 2025 für Liedtexte festgestellt (GEMA gegen OpenAI): Die Speicherung im Modell sei eine Vervielfältigung, "Die Festlegung in bloßen Wahrscheinlichkeitswerten sei hierbei unerheblich." Im Juli 2026 hat dieselbe Kammer im Verfahren gegen den Musikdienst Suno ähnlich entschieden, wie wir in der News GEMA gegen Suno beschrieben haben. Das OpenAI-Urteil ist laut Gericht nicht rechtskräftig, Suno hat Berufung angekündigt. Beide betreffen Musik, nicht Software. Ob sich die Begründung auf Code übertragen lässt, ist offen.

Den bisher deutlichsten Streit gab es in der Open-Source-Welt. Der Maintainer der Python-Bibliothek chardet ließ sie im März 2026 mit Claude neu schreiben und änderte die Lizenz von LGPL auf MIT. Der ursprüngliche Autor Mark Pilgrim widersprach im Issue-Tracker: Die Beteiligten hätten den alten Code gut gekannt, "i.e. this is not a 'clean room' implementation", und "Adding a fancy code generator into the mix does not somehow grant them any additional rights." Der Maintainer räumte ein, dass es keine klassische Trennung gab, und verwies auf einen Vergleich mit dem Werkzeug JPlag: im Mittel 0,04 Prozent Ähnlichkeit zur alten Version. Die Anwältin Heather Meeker hält es für die vermutlich richtige urheberrechtliche Analyse, dass keine Pflicht zur alten Lizenz besteht. Ein Gericht hat nicht entschieden.

Für einen Nachbau wie PhotoCraft folgt daraus kein Urteil, aber eine Frage, die jedes Team für sich beantworten sollte: Was hat das Modell gesehen, was hat es als Eingabe bekommen, und lässt sich zeigen, dass der Code nicht aus dem Original stammt? Ein Ähnlichkeitsvergleich wie bei chardet ist bei geschlossener Software nicht möglich, weil niemand den Originalcode zum Vergleichen hat.

Wem gehört Code, den ein Agent schreibt?

Die zweite offene Frage betrifft die Lizenz des Nachbaus selbst. Das deutsche Urheberrecht schützt nur "persönliche geistige Schöpfungen". Das Amtsgericht München hat im Februar 2026 bei drei KI-generierten Logos entschieden, dass Schutz von menschlichem schöpferischem Einfluss abhängt und ein aufwändiger Prompt allein nicht reicht: "Das Urheberrecht belohnt und schützt nicht Investitionen, Zeitaufwand oder Fleiß, sondern allein das Ergebnis einer kreativen Tätigkeit." Das betrifft Bilder, nicht Code, und ist das Urteil eines Amtsgerichts. Das US Copyright Office sieht es ähnlich: Prompts allein machen niemanden zum Urheber des Ergebnisses.

Für Open Source hat das eine merkwürdige Folge. Wenn an einem Teil des Codes niemand Rechte hat, kann auch niemand Rechte daran per MIT, Apache oder GPL einräumen. Genau diese Frage stand bei chardet im zweiten Issue im Raum. Der Maintainer stellte die Lizenz am Ende auf 0BSD um, die praktisch keine Bedingungen mehr stellt. Geschützt bleiben können die Teile, an denen Menschen kreativ gearbeitet haben: Architektur, Auswahl, Tests, Dokumentation. Die Software Freedom Conservancy rät, vorschnelle Schlüsse zu vermeiden, "There remain many unanswered legal questions", und empfiehlt, Prompt-Protokolle wie Quellcode mit abzulegen.

Und in den USA?

Adobe, Microsoft und Autodesk sind US-Konzerne, und in den USA läuft die Frage anders. Im Fall Google gegen Oracle ging es 2021 um rund 11.500 Zeilen aus der Java-Programmierschnittstelle, die Google für Android übernommen hatte. Der Supreme Court ließ offen, ob solcher Code überhaupt geschützt ist, und entschied mit sechs zu zwei Stimmen, die Übernahme sei als Fair Use erlaubt. In der EU stellt sich die Frage nach dem Schutz von Funktion und Schnittstellenidee gar nicht erst, sie ist durch SAS und die Richtlinie verneint.

Stand am 16.10.2026

Eine Abmahnung, Klage oder öffentliche Stellungnahme von Adobe, Microsoft, Autodesk oder Avid zu den Craft-Programmen ist bis zum 16.10.2026 nicht bekannt. Die Issues, die vor Ärger warnen, stammen von Nutzern, nicht vom Team und nicht von den Herstellern. Sichtbar geändert hat sich eine Zeile: Die Kurzbeschreibung von PhotoCraft lautete am 10.10. noch "clean-room reimplementation of Adobe Photoshop", jetzt ist dort von einem Fotoeditor die Rede. Warum, sagt das Projekt nicht.

Zum Vergleich lohnt ein Blick auf ein anderes Projekt aus derselben Welle. Die Sammlung replica-skill bietet Claude-Skills an, die Apps nachbauen. Ihr README schreibt vor, nur öffentliche Seiten und das eigene Konto zu lesen, das Ergebnis vor dem Start umzubenennen, keine Logos, Marken oder Texte zu übernehmen, und rät: "talk to a lawyer before launch if there is money on the line." Die Craft-Programme nennen ihre Vorbilder dagegen ausdrücklich im README.

Was ihr daraus mitnehmt

Wer selbst eine Alternative zu bestehender Software baut, mit oder ohne Agenten, kann sich an ein paar Fragen entlanghangeln. Sie ersetzen keine Beratung, zeigen aber, wo die heiklen Stellen liegen:

• Woher kommen eure Informationen? Öffentliche Spezifikationen, Dokumentation und das Beobachten eines berechtigt genutzten Programms sind das, was SAS und § 69d Abs. 3 decken. Dekompilieren für einen Nachbau ist es nicht.
• Was steht in eurer Lizenz für das Original? Klauseln wie Adobes Abschnitt 17 zielen genau auf das Beobachten zum Nachbau. Ob sie halten, ist offen. Dass sie existieren, solltet ihr wissen.
• Was hat euer Modell bekommen? Gebt ihm weder Originalcode noch geleakte Quellen oder Assets. Protokolliert die Prompts und Eingaben, dann könnt ihr später zeigen, wie der Code entstanden ist.
• Wie heißt es, und wie sieht es aus? Namen und Gesamtgestaltung sind das, was am ehesten Ärger über Marken- und Wettbewerbsrecht bringt. Ein eigener Name kostet wenig.
• Wer hält die Rechte am Ergebnis? Wenn große Teile vom Agenten stammen, ist offen, was eure Lizenz tatsächlich abdeckt. Dokumentiert, wo Menschen gestaltet haben.
• Geht es um Geld? Dann gehört das Vorhaben vor dem Start zu jemandem, der Software- und Markenrecht kennt.

Wer KI-generierten Code in eigene Produkte übernimmt, steht vor derselben Lizenzfrage aus der anderen Richtung. Was das für den Betrieb heißt, steht in unserem Artikel zur Haftung für KI in Anwendungen.

Kurz gesagt

Im europäischen Recht ist die Funktion einer Software frei: Nachbauen, was ein Programm kann, ist erlaubt, Code, Assets und Texte zu übernehmen nicht. Beobachten und Testen eines berechtigt genutzten Programms deckt das Gesetz, Dekompilieren für einen Nachbau nicht. Die Nutzungsbedingungen großer Hersteller verbieten genau das Beobachten zum Nachbau, wie weit sie in Deutschland greifen, ist offen. Dazu kommen Marken, Oberflächen und Nachahmungsschutz. Neu sind zwei ungeklärte Fragen: ob ein Modell, das das Original kennen kann, einen sauberen Nachbau liefern kann, und wem der Code gehört, den es schreibt. Bis Gerichte das klären, ist eine gute Dokumentation des Vorgehens der beste Schutz, den ein kleines Team hat.