In Deutschland und der EU ist es ausdrücklich erlaubt, ein frei gekauftes Produkt auseinanderzunehmen, um herauszufinden, wie es funktioniert. So steht es in § 3 Abs. 1 Nr. 2 lit. b des Geschäftsgeheimnisgesetzes und in Art. 3 Abs. 1 lit. b der Geheimnisschutz-Richtlinie (EU) 2016/943. Seit Anfang Oktober gibt es kostenlose Nachbauten von Photoshop, Premiere und Word. Geschrieben von einer KI.
Das wirft zwei Fragen auf. Wie baut ein KI-Agent in Tagen nach, woran Hersteller seit Jahrzehnten arbeiten? Und ist das Diebstahl? Wichtig vorweg: Nach Aussage ihres Gründers entstanden diese Nachbauten, ohne in den Code der Originale zu schauen und damit auch nicht unter Verwendung des Codes. Dieser Beitrag ordnet Technik, Recht und die Folgen für Unternehmen ein, die Software kaufen oder selbst herstellen.
Was passiert ist
Hinter allen Nachbauten steht ein einziges Projekt: ArtCraft, gegründet von Brandon Thomas aus Atlanta, früher CEO von Storyteller.ai und davor Engineer bei Square. Der Code liegt auf GitHub unter der Organisation storytold. Das erste Commit von PhotoCraft stammt vom 30. September 2026. Am 3. Oktober kündigte Thomas auf Reddit eine ganze Adobe-Suite an, wie PetaPixel berichtete. Am 7. Oktober folgten WordCraft, GridCraft und DeckCraft für Textverarbeitung, Tabellenkalkulation und Präsentationen (The Register).
Heute listet die Projektseite zwölf Apps. Neben PhotoCraft für Bildbearbeitung sind das VectorCraft für Vektorillustration, FilmCraft für Videoschnitt, LightCraft für Fotobibliothek und Raw-Entwicklung, PdfCraft für PDF, EffectCraft für Motion Graphics, DesignCraft für Layout und Publishing, WordCraft, SoundCraft als Audio-Workstation, DeckCraft, CADCraft und GridCraft. Alle sind in Rust geschrieben, quelloffen unter MIT und Apache 2.0 lizenziert und laufen offline auf macOS, Windows und Linux sowie als WebAssembly im Browser. Alle sind im Alpha-Stadium.
PhotoCraft in Version 0.7.0 beherrscht Ebenen, Masken, Einstellungsebenen und Ebenenstile. Die Darstellung läuft nativ über die Grafikschnittstellen Metal, Vulkan, DirectX 12 und WebGPU, ohne Electron. Das Programm öffnet und speichert PSD- und PSB-Dateien. Laut Projektseite werden 134 von 135 echten Testdateien byte-genau wieder gespeichert. WordCraft in Version 0.5.0 bietet Ribbon, Formatvorlagen, Tabellen, Änderungsverfolgung, Literaturverzeichnisse und Serienbriefe. Es liest und schreibt .docx nativ nach dem öffentlichen Standard ECMA-376. Die laut Projektseite 389 Befehle lassen sich über Ribbon, Kommandozeile, eine JSON-Schnittstelle und einen MCP-Server steuern. Ein KI-Agent kann die Textverarbeitung also direkt bedienen.
Die Projektdokumentation ist bei der Reife zurückhaltender als manche Schlagzeile. Die Roadmap von PhotoCraft schätzte die Profi-Tauglichkeit am 5. Oktober auf 25 bis 35 Prozent. Die README von WordCraft nannte rund 60 Prozent auf dem Weg zum vollständigen Word-Ersatz. Ein Pixel-Artist bezeichnete PhotoCraft gegenüber Decrypt als völlig unbrauchbar. Thomas, der gegenüber Ars Technica erklärt hatte, „Software is over“, korrigierte sein Versprechen voller Parität in einem Monat auf Monate statt Jahre. Adobe lehnte einen Kommentar ab, Microsoft bestätigte nur den Eingang der Anfrage. Klagen sind bisher nicht bekannt.
Entscheidend ist, wie gebaut wurde. Auf Hacker News schrieb Thomas, man nutze Claude Code ohne Zusätze und achte besonders darauf, das Reverse-Engineering-Werkzeug Ghidra nicht anzufassen. Adobe-Quellen dürften nicht angesehen werden. Diese Regeln stehen auch im Code. Die AGENTS.md im WordCraft-Repository verbietet der KI, irgendetwas im Word-Programmpaket zu lesen, zu disassemblieren oder zu kopieren. Word darf nur von außen beobachtet werden. Die AGENTS.md von PhotoCraft hält fest, dass Photoshop nur auf Verhalten und Aussehen untersucht wurde und Code, Shader, Profile und Assets nie kopiert werden dürfen.
Wie baut man so etwas? Zwei Wege
Parallel zu ArtCraft ging in denselben Tagen ein Werkzeug viral, das einen anderen Weg geht. REA, kurz für Reverse Engineer Anything, ist ein Open-Source-MCP-Server, der im April 2026 als „betterBinaryMCP“ gestartet ist. Er verbindet KI-Coding-Agenten wie Claude Code mit etablierten Reverse-Engineering-Werkzeugen: Ghidra, das die NSA 2019 veröffentlicht hat, Hopper, IDA und die Chrome DevTools für Web- und Electron-Apps. Laut Decrypt stieg REA von unter 10.000 GitHub-Sternen am 6. Oktober auf über 100.000 am 12. Oktober, davon über 30.000 an einem einzigen Tag.
Der Ablauf, wie MindStudio ihn beschreibt: Gestartet wird per Klartext-Anweisung. Der Agent lässt das Zielprogramm dekompilieren und bekommt Pseudocode mit Belegen und einer Liste offener Fragen. Daraus schreibt er eine eigene Implementierung, testet sie gegen das Original und wiederholt das Feature für Feature. Die README von REA ist dabei zurückhaltend. Sie beansprucht weder, Originalquellcode wiederherzustellen, noch Anwendungen automatisch zu klonen.
ArtCraft hat diesen Weg nach eigener Aussage bewusst nicht gewählt. Decrypt und Kingy.ai fanden bei unabhängigen Prüfungen keinen Beleg für einen Einsatz von REA. Beide Geschichten zeigen dennoch dasselbe Muster: Ein KI-Agent übernimmt die Fleißarbeit des Nachbauens, der Mensch setzt die Regeln und prüft die Ergebnisse.
| Weg 1: Black-Box und Spezifikation | Weg 2: Blick ins Innere | |
|---|---|---|
| Beispiel | ArtCraft nach eigener Aussage | was REA ermöglicht |
| Informationsquelle | Menüs, Tastenkürzel, Verhalten, Screenshots, öffentliche Formatspezifikationen wie Adobes PSD-Spezifikation und ECMA-376 | dekompilierter Programmcode als Pseudocode |
| Steuerung | feste Regeln in einer AGENTS.md, was der Agent darf und was nicht | Klartext-Anweisung, Abgleich mit dem Original |
| Fortschritt | Testkorpora, etwa ob echte Dateien unverändert wieder gespeichert werden | Tests gegen das Original, Feature für Feature |
| Rechtliche Lage | bewährtes Clean-Room-Prinzip | Dekompilieren in der EU nur unter sehr strengen Voraussetzungen zur Herstellung der Interoperabilität erlaubt |
Weg 1 ist im Kern das alte Clean-Room-Prinzip, nur dass der Programmierer eine KI ist. Weg 2 ist schneller beim Verständnis von Details, rechtlich aber deutlich heikler.
Wie viel der Blick ins Innere tatsächlich bringt, hat MindStudio ausprobiert. Die Mac-App Vorschau wurde einmal mit und einmal ohne REA nachgebaut. Beide Versionen funktionierten. Die Version ohne REA, nur mit Screenshots und dem eigenen Schlussfolgern des Agenten, war sogar zuerst fertig. MindStudio nennt REA deshalb einen Connector, keine neue Technologie, und den Hype teils memetisch. Die eigentliche Entwicklung sei, dass Software zur Massenware wird und dünne Wrapper-Apps ihre Verteidigungsfähigkeit verlieren.
Der spektakuläre Weg ist nicht unbedingt der erfolgreichere. Ein normaler Coding-Agent mit Screenshots und Spezifikation kam im Test genauso weit.
Reverse Engineering ist älter als der PC
Reverse Engineering bedeutet, ein fertiges Produkt rückwärts zu analysieren, bis man versteht, wie es funktioniert. Das ist alt und war oft legitimer Wettbewerb.
Das bekannteste Beispiel stammt aus dem Jahr 1984. Phoenix Technologies baute damals das BIOS des IBM-PC im Clean-Room-Verfahren nach. Ein Team analysierte das Original und schrieb Spezifikationen. Ein separater Entwickler schrieb daraus die Neuimplementierung. Er kannte sich mit anderen Prozessoren aus und wurde gerade deshalb ausgewählt, weil er den IBM-Code nie gesehen hatte. Das Verfahren ebnete den Weg für die PC-Klone.
Spätere Beispiele sind Samba für Windows-Dateifreigaben unter Linux, Wine für Windows-Programme auf anderen Betriebssystemen und die Office-Kompatibilität von LibreOffice.
Neu ist bei ArtCraft also nicht das Prinzip. Neu ist, wer die Rolle des sauberen Entwicklers übernimmt. 1984 war es ein Mensch, der den Originalcode nie gesehen hatte. 2026 ist es ein Sprachmodell, dem eine Textdatei vorschreibt, was es nicht ansehen darf. Ob das gleichwertig ist, gehört zu den offenen Fragen dieser Geschichte.
Ist das Diebstahl?
Die kurze Antwort: Funktionen nachzubauen ist in der EU grundsätzlich erlaubt, Code zu kopieren nicht. Die Grenze verläuft dort, wo jemand ins Innere eines Programms schaut oder aber eine unlautere Nachahmung vorliegt. Bei dieser müssen aber weitere unlautere Handlungstatbestände vorliegen (Täuschung der Abnehmer, Ausnutzung der Wertschätzung oder unredliche Erlangung der Kenntnisse oder Unterlagen für den Nachbau, § 4 Nr. 3 UWG). Die folgende Einordnung ersetzt keine Rechtsberatung im Einzelfall.
Grundlage ist das Urteil des EuGH in der Rechtssache C-406/10, SAS Institute gegen World Programming, vom 2. Mai 2012. Der Gerichtshof entschied, dass die Funktionalität eines Programms, die Programmiersprache und das Dateiformat keine urheberrechtlich geschützten Ausdrucksformen sind (Einordnung bei netzpolitik.org). Geschützt ist der konkrete Code. Ein wichtiges Detail: World Programming hatte keinen Zugang zum Quellcode und hat nicht dekompiliert.
Das deutsche Urheberrecht zieht die Linie in zwei Paragrafen. Nach § 69d Abs. 3 UrhG darf der berechtigte Nutzer ein Programm beobachten, untersuchen und testen, um die zugrunde liegenden Ideen zu ermitteln. Nach § 69e UrhG ist Dekompilieren ohne Zustimmung nur erlaubt, wenn es unerlässlich ist, um die Interoperabilität eines unabhängig geschaffenen Programms herzustellen. Die so gewonnenen Informationen dürfen nicht für ein Programm mit im Wesentlichen ähnlicher Ausdrucksform verwendet werden. Genau hier liegt die Grenze für einen dekompilierenden Nachbau.
Hinzu kommt § 3 Abs. 1 Nr. 2 GeschGehG. Seit 2019 ist Reverse Engineering an öffentlich verfügbaren Produkten damit ausdrücklich zulässig. Grenzen setzen Patente, Designs, Marken und Verträge. Diese Risiken bestehen unabhängig vom Code. Wer Optik und Gesamterscheinung eines Produkts zu nah übernimmt, fremde Marken nutzt oder Patente verletzt, hat ein Problem, auch wenn keine einzige Zeile kopiert wurde. Ob Verbote von Reverse Engineering in Lizenzbedingungen wirksam sind, ist umstritten.
Hersteller versuchen daher häufig, in den Nutzungsbedingungen das Reverse Engineering zu verbieten. Dass dieses (vertragliche) Verbot gilt, setzt aber voraus, dass man Vertragspartner ist und den Nutzungsbedingungen zugestimmt hat.
In den USA liegt die Linie ähnlich, ist aber anders begründet. Im Fall Sega gegen Accolade urteilte ein Gericht 1992, dass Disassemblieren Fair Use sein kann. 2021 entschied der Supreme Court in Google gegen Oracle, dass die Übernahme von API-Deklarationen Fair Use war.
Offen bleibt eine Frage, die das Recht noch nicht beantwortet hat. Ein klassischer Clean Room trennt zwei menschliche Teams. Ein Sprachmodell dagegen wurde mit riesigen Mengen öffentlichen Codes trainiert. Ob ein solches Modell überhaupt „clean“ sein kann, ist ungeklärt. Eine erste Debatte gab es im März 2026, als die Python-Bibliothek chardet mit Claude neu geschrieben wurde und Streit über die Umlizenzierung entstand. Der Jurist Neil Brown von decoded.legal hält unabhängige Neuimplementierungen für verteidigbar, erwartet aber Rechtsstreit, sobald Gegner mit tiefen Taschen betroffen sind. Auch Thomas rechnet mit Gegenwehr, allerdings für den anderen Weg. Der Einsatz von REA bei einem so prominenten Projekt würde nach seiner Aussage wahrscheinlich Klagen nach sich ziehen.
Was das für Ihr Unternehmen bedeutet
Früher war Software teuer zu bauen und billig zu kopieren. Heute wird auch das Bauen billig.
Für Softwarehersteller heißt das: Features allein sind kein Burggraben mehr. Wenn ein Agent Oberfläche, Befehle und Dateiformat in Wochen als Alpha nachbauen kann, schützt der Funktionsumfang nicht mehr. Was bleibt, sind Daten, tiefe Integration in Prozesse, Support, Zertifizierungen, Haftung und Vertrauen.
Für Softwarekäufer wächst die Verhandlungsmacht, und die Zahl der Alternativen steigt. Ein glaubwürdiger quelloffener Nachbau verändert die Ausgangslage bei der nächsten Lizenzverlängerung. Alpha-Software ist aber kein Ersatz für produktive Kernprozesse. Wartung, Sicherheitsupdates, Compliance und die Frage, wer haftet, bleiben die entscheidenden Kriterien. Ein Repository auf GitHub beantwortet keine davon.
Für die Eigenentwicklung verschieben sich die Make-or-Buy-Rechnungen, weil Bauen mit KI-Agenten billiger wird. Das gilt weniger für den nächsten Photoshop als für interne Werkzeuge und Fachanwendungen, für die bisher eine Lizenz gekauft wurde, weil der Eigenbau zu teuer war.
Die Gegenseite gehört zur ehrlichen Einordnung. Der Nachbau einer Oberfläche ist nicht der Nachbau eines Ökosystems. Jahrzehnte an Kompatibilität, Plug-ins und Randfällen holt niemand in Wochen auf. Die eine von 135 Testdateien, die PhotoCraft nicht byte-genau zurückschreibt, steht stellvertretend für genau diese Randfälle.
Fazit: Drei Dinge, die Sie jetzt tun sollten
Prüfen Sie Ihren Burggraben. Wenn Sie selbst Software verkaufen, fragen Sie für jedes Produkt, was ein Wettbewerber mit einem KI-Agenten in drei Monaten nicht nachbauen könnte. Besteht die Antwort nur aus Features, liegt dort die Aufgabe für die nächste Strategierunde. Nehmen Sie das Verbot des Reverse Engineering in die Nutzungsbedingungen auf. Die Durchsetzung ist aber rechtlich schwierig.
Rechnen Sie Make-or-Buy neu. Bewerten Sie bei anstehenden Lizenzverlängerungen und internen Werkzeugen die Eigenbauoption mit realistischen Kosten für agentengestützte Entwicklung. Preisen Sie Betrieb, Sicherheitsupdates und Haftung dabei vollständig ein.
Legen Sie Regeln für Coding-Agenten fest. Wenn Ihre Teams mit KI-Harnesses arbeiten, definieren Sie schriftlich, was ein Agent ansehen darf und was nicht. Eine AGENTS.md mit klaren Verboten, wie ArtCraft sie nutzt, ist ein einfacher Anfang. Das Dekompilieren fremder Software gehört ohne juristische Prüfung nicht in den Werkzeugkasten.
Wenn Sie Ihre KI-Strategie oder eine konkrete Make-or-Buy-Entscheidung vor diesem Hintergrund neu bewerten wollen, sprechen wir gern unverbindlich darüber.