Clean-Room-Reimplementation
Bei einer Clean-Room-Reimplementation baut ein Team eine Software neu, ohne den ursprünglichen Programmtext je gesehen zu haben. Es arbeitet nur mit einer Beschreibung dessen, was das Programm tun soll — so soll bewiesen werden, dass nichts abgeschrieben wurde.
Software besteht aus Text, den Programmierer schreiben. Dieser Text heißt Quellcode, und er gehört rechtlich dem, der ihn geschrieben hat. Wer ihn kopiert, verletzt das Urheberrecht. Man darf aber nachbauen, was ein Programm tut, solange man es selbst formuliert. Eine Clean-Room-Reimplementation ist das Verfahren, mit dem Firmen genau das organisieren: Ein Team beschreibt, was das fremde Programm nach außen hin macht. Ein zweites Team, das den fremden Text nie gesehen hat, programmiert daraus eine eigene Version. Der Name kommt vom Reinraum in der Chipfertigung — nur dass hier nicht Staub draußen bleiben soll, sondern fremder Code.
Warum Firmen sich diesen Umstand machen
Ein Prozess ist teuer und riskant. Wer eine bekannte Software nachbaut, muss damit rechnen, verklagt zu werden. Vor Gericht kommt dann die entscheidende Frage: Habt ihr abgeschrieben oder selbst entwickelt? Ohne Dokumentation ist das kaum zu beweisen. Ähnlichkeiten allein reichen nämlich nicht als Entlastung, denn zwei Programme mit derselben Aufgabe sehen sich oft zwangsläufig ähnlich.
Das Clean-Room-Verfahren erzeugt deshalb eine Beweiskette. Es gibt Protokolle darüber, wer wann Zugang zu welchen Unterlagen hatte. Es gibt schriftliche Erklärungen der Entwickler. Es gibt eine Trennwand zwischen dem Team, das analysiert, und dem, das baut. Kommt es zum Streit, kann die Firma zeigen: Unsere Leute konnten gar nicht kopieren.
Historisch hat das die IT-Branche stark geprägt. In den 1980er-Jahren baute die Firma Phoenix Technologies auf diese Weise die Startsoftware von IBM-PCs nach. Damit konnten andere Hersteller kompatible Rechner verkaufen. Ohne dieses Vorgehen wäre der PC-Markt vermutlich ein IBM-Monopol geblieben.
Die Trennung in zwei Teams
Das erste Team darf alles ansehen. Es untersucht das fremde Programm, liest Handbücher, testet Eingaben und Ausgaben. Manchmal analysiert es auch die fertige Programmdatei, um deren Verhalten zu verstehen. Dieses Rückwärts-Untersuchen nennt man Reverse Engineering. Das Ergebnis ist eine reine Beschreibung: Bei dieser Eingabe kommt dieses Ergebnis heraus, in dieser Reihenfolge, in diesem Format.
Diese Beschreibung wird geprüft, oft von Juristen. Alles, was zu nah am Original klebt, muss raus: Variablennamen, Kommentare, ungewöhnliche Formulierungen, ganze Codezeilen. Übrig bleiben soll nur die Funktion, nicht die Form. Nach dieser Kontrolle wandert das Dokument über die Trennwand.
Das zweite Team arbeitet nur damit. Es hat nie einen Blick auf das Original geworfen und darf auch keine Fragen an das erste Team stellen, die über das Dokument hinausgehen. Rückfragen laufen schriftlich und werden mitprotokolliert. Häufig sind es sogar zwei getrennte Firmen an zwei Orten. Das Ergebnis ist neuer Code, der dieselbe Aufgabe löst, aber anders aufgebaut ist.
Vom PC-Nachbau bis zum Streit um KI-Trainingsdaten
Am bekanntesten ist das Verfahren aus dem Streit um Programmierschnittstellen. Eine Schnittstelle ist die Liste der Befehle, mit denen ein Programm ein anderes ansprechen kann. Google baute für Android die Schnittstellen der Programmiersprache Java nach. Der Rechtsstreit mit Oracle dauerte über zehn Jahre. 2021 entschied der Oberste Gerichtshof der USA zugunsten von Google.
In Wirtschaftsnachrichten taucht der Begriff heute vor allem bei KI auf. Wenn ein Sprachmodell mit fremdem Code trainiert wurde, kann es Passagen daraus fast wörtlich ausgeben. Genau das ist das Gegenteil eines Reinraums: Das Modell hat das Original gesehen. Firmen suchen deshalb nach Wegen, die Herkunft von generiertem Code nachzuweisen.
Ein häufiger Irrtum ist übrigens, dass ein Clean Room jede Nachahmung erlaubt. Er schützt nur gegen den Vorwurf des Abschreibens von Code. Patente und Markenrechte gelten weiter — deshalb heißt ein Nachbau nie so wie das Original. Und wirtschaftlich ist das Verfahren teuer: Man baut dieselbe Software zweimal, einmal zum Verstehen und einmal zum Bauen.