Reinraum-Implementierung
Eine mit Hilfe von Reinraum-Design bzw. Cleanroom-Design (manchmal auch Chinesische-Mauer-Technik genannt)[1] erstellte Software kopiert den Funktionsumfang einer schon existierenden Software, ohne den Code der existierenden Software (direkt) zu verwenden. Das Design wird aus den Spezifikationen von Schnittstellen, Dateiformaten und Protokollen abgeleitet und durch Reverse Engineering verifiziert.
Beschreibung
Die mit Hilfe von Reinraum-Design erstellte Software leistet somit Vergleichbares wie die Vorlage, ist aber vollkommen unabhängig von dieser. Dies ist wichtig, weil in den meisten Ländern das Urheberrecht für Software nur die konkrete Implementierung unter Schutz stellt, nicht aber die Funktionsweise einer Software. Erstellt man somit eine Software nach dem Reinraum-Design, so ist die neue Software frei von Urheberrechten des Rechteinhabers der Vorlage.
Ein wichtiger Grund für die Erzeugung einer Reinraumimplementierung ist daneben historisch gewachsene Software. Dadurch, dass bei solcher Software zum Beginn der Entwicklung nicht unbedingt klar war, wie das Endergebnis aussehen würde, also nicht linear darauf hin entwickelt wurde, enthält sie häufig entwicklungsbedingte Schwächen, die sich im Nachhinein kaum beheben lassen. Solche Schwächen können das Laufzeitverhalten in den Punkten Sicherheit und Geschwindigkeit betreffen. Bei einer Reinraumimplementierung wird im Unterschied dazu versucht, direkt und stringent auf das bereits vollständig formulierte Endziel hin zu entwickeln.
Eine Reinraumimplementierung schützt nur vor Forderungen aus dem Urheberrecht. Andere gewerbliche Schutzrechte, wie das Patent- und Markenrecht können durch eine Reinraumimplementierung nicht umgangen werden. Aus diesem Grund legen sich gerade große Softwarekonzerne zunehmend ein großes Repertoire an Patenten zu.
Auch die Programmierung von Software aus einer durch Reverse Engineering gewonnenen Dokumentation bzw. Spezifikation bezeichnet man als Reinraumimplementierung. Diese Spezifikationsextraktion und die Nachprogrammierung müssen laut US-amerikanischer Rechtsinterpretation von verschiedenen Personen durchgeführt werden, einem Dirty room team (Reverse engineering) und einem Clean room team (Programmierer).[1][2] Die extrahierte Dokumentation kann gegebenenfalls vor der Verwendung zusätzlich von einem Rechtsanwalt auf Urheberrechtsverletzung überprüft werden.
Beispiele
Ein berühmtes historisches Beispiel ist der erste IBM-PC-kompatible Klon von Columbia Data Products (MPC 1600 „Multi Personal Computer“), welcher eine Reinraum-Nachimplementierung des IBM-BIOS enthielt.[1]
Ein weiteres Beispiel ist der VTech-Klon von Apple-II-ROM für den Laser 128, der einzige Klon von vielen, der die rechtliche Handhabe von Apple überstand.
Prominente Beispiele für Reinraum-Entwicklungen finden sich besonders im Open-Source-Umfeld, da in diesem Umfeld selten geeignete Lizenzvereinbarungen getroffen werden können. Beispiele sind das unixoide Betriebssystem Linux, die Windows-kompatible Laufzeitumgebung Wine oder das GPL lizenzierte Betriebssystem ReactOS.
Siehe auch
Weblinks
- Artikel im Computerworld-Magazin (englisch, 2001)
Einzelnachweise
- ↑ a b c Mathew Schwartz: Reverse-Engineering. computerworld.com. 12. November 2001. Abgerufen am 23. Juni 2013: „To protect against charges of having simply (and illegally) copied IBM's BIOS, Phoenix reverse-engineered it using what's called a "clean room," or "Chinese wall," approach. First, a team of engineers studied the IBM BIOS—about 8KB of code—and described everything it did as completely as possible without using or referencing any actual code. Then Phoenix brought in a second team of programmers who had no prior knowledge of the IBM BIOS and had never seen its code. Working only from the first team's functional specifications, the second team wrote a new BIOS that operated as specified.“
- ↑ Sean Hogle: Clean Room Defeats Software Infringement Claim in US Federal Court. 23. Oktober 2008. Abgerufen am 23. Mai 2013: „[...] dirty room reverse engineering should be done in conjunction with clean room development by using two physically and electronically isolated teams where one team does dirty room reverse engineering and the other does clean room development. If a dirty room team exists, the clean room engineers can write a description of the portion of the specification that needs elaboration or clarification. The dirty room engineers then use that request to create additional functional specifications or tests.“