von: Dennis Jansen
In Oracle ./. Google (Beschluss v. 31.05.2012, Nr. C-10-03561 WHA) hat das Bundesgericht der 1. Instanz im 9. Bundesgerichtsbezirk ("Circuit") durch Richter William Alsup entschieden, dass Google mit der Kopie und Verwendung von Deklarationen und Header-Dateien aus Java in seinem Android-Betriebssystem keine Urheberrechte von Oracle verletzt. Das Gericht erkannte ein berechtigtes Interesse von Google an, teilweise Interoperabilität zu Java zu schaffen, ohne - wie von Oracle gewünscht - vollständige Kompatibilität herstellen zu müssen.
Die Entscheidung ist von zentraler Bedeutung für den Wettbewerb zwischen Softwarelösungen in den USA. Die Jury sah keine der Patente von Oracle verletzt. Diese Entscheidung dürfte auch - soweit das Urheberrecht betroffen ist - etwa das Mono-Projekt stützen, welches eine von Microsoft entwickelte Variante der Programmiersprache C#, nachprogrammiert. Dort wird allerdings die gesamte API in binärkompatibler Weise nachprogrammiert, statt nur eines Teils.
Das vollständige Kopieren von Inhalten - also nicht bloß der Deklaration - einer Methode aus Java gab es nur in zwei Fällen - bei der Methode "rangeCheck" und bei 8 dekompilierten Test-Dateien. Ersteres war ein "unschuldiger und folgenloser" Fall des Kopierens (S. 14). Letztere Dateien wurden nie Bestandteil von Android.
Die einzelnen Methoden ("Mini-Programme") aus der Java-API dürfen nachprogrammiert werden. Sie dürfen dabei so implementiert werden, dass sie diejenigen von Oracle's Java direkt ersetzen können. Methoden dürfen in den gleichen Klassen (Sammlungen) mit den gleichen Namen enthalten sein und für dieselben Parameter dieselben Rückgabewerte unter den gleichen Namen erzeugen wie bei Java. Das bedeutet, dass Deklarationen und Header-Dateien eins zu eins übereinstimmen können, ohne das Urheberrecht zu verletzen. In anderen Worten: Sie dürfen interoperabel sein.
Grundsätzlich dürfen Methoden nur in ihrem Kopf ("declaration"), jedoch nicht in ihrem Kern ("implementation"), eine 1:1-Kopie darstellen. Ausnahmsweise kann der Vermischungsgrundsatz auch eine Kopie gestatten: Wenn es nur sehr wenige effiziente Möglichkeiten gibt, eine Methode zu implementieren, vermischen sich Idee und Implementierung. Geschieht dies so stark, dass die Implementierung so sehr von der Idee vorgegeben ist, dass sie nicht länger maßgeblich auf freien kreativen Entscheidungen der Implementierung beruht, endet der Schutz des US-Urheberrechts. Denn die Implementierung ist mit der Idee verschmolzen und wie eine Idee selbst nicht urheberrechtlich geschützt.
Das Gericht erkannte die von Oracle vorgetragene Trennlinie zwischen der API von Java und der Programmiersprache Java nicht an (S. 12). Die weiteren Methoden, die über die Kernfunktionalität hinausgehen, sieht das Gericht als weitere Bestandteile der Programmiersprache soweit die Deklaration, Klassen und Pakete und deren jeweilige Namen und Einteilungen betroffen sind.
Die Rechtslage ist noch umstritten in den USA. Das Gericht konnte klar feststellen, dass nach amerikanischem Copyright Act von 1976 (vgl. UrhG) Namen, Titel und kurze Sätze nicht geschützt sind und dass Ideen nicht schutzfähig sind, sondern nur die Implementierung. Problematisch ist jedoch die Abgrenzung, wo Ideen enden und die Implementierung anfängt. Kernpunkt der Entscheidung war, wann die "Struktur, Abfolge und Organisation", auf die sich Oracle schwerpunktmäßig berief, ein schutzfähiger Ausdruck der Idee ist.
In Whelan Associates Inc. v. Jaslow Dental Laboratory, Inc. (1986) wurde im 3. Bundesgerichtsbezirk ein sehr weiter Schutzbereich gezogen: Alles was nicht zwingend für die Implementierung einer Idee nötig sei, sei geschützt.
Der Gegenpol kristallisierte sich seit Computer Associates International, Inc. v. Altai (1992) im "Abstrakten-Filtrier-Vergleichstest": Strukturen, die auf Kriterien wie Geschwindigkeit, Nutzerfreundlichkeit, Effizienz und externe Faktoren wie Kompatibilitätsanforderungen und Design-Standards basieren oder gemeinfrei sind, seien nicht geschützt.
Die Entwicklung scheint in Richtung einer liberaleren Auslegung im Sinne der letzteren Entscheidung fortzuschreiten. Vorliegend musste sich das Gericht an Johnson Controls, Inc. v. Phoenix Control Sys., Inc. (1989) halten. Das Urteil erging noch vor Computer Associates Int., stellt bindende Präzedenz dar und tendierte eher in Richtung des weiten Standards von Whelan. An diesem Standard orientiert bewirkt die Entscheidung einen vergleichsweise kleinen Schutzbereich. Dieser ermöglicht eher starken Wettbewerb zwischen konkurrierenden Softwarelösungen.
Es bleibt spannend, ob die Frage dem Revisionsgericht vorgelegt wird und ob sich der US-Supreme Court - als sehr selten Fragen zur Entscheidung annehmende letzte Instanz der US-Bundesgerichte - zu der Problematik äußern und bundesweite Rechtseinheit schaffen wird. Zuletzt waren dort ähnliche Fragen zwar zur Entscheidung angenommen worden. Aufgrund einer 4 zu 4 Patt-Situation wurden die Fragen jedoch nicht als bundesweit bindender Präzedenzfall entschieden. Denn Urteile der Gerichte unterhalb des Supreme Court sind nur für den jeweiligen Bundesgerichtsbezirk bindend. Andernfalls handelt es sich um sog. "non-binding precedent".
Die vorliegende Entscheidung wird auch als "non-binding precedent" voraussichtlich trotzdem erhebliche Beachtung finden, da sie sich ausführlich, gründlich und recht überzeugend mit den zu Grunde liegenden Problemen befasst. Gerichte aus demselben Bezirk entscheiden üblicherweise ähnlich. Gerichte aus anderen Bezirken können die Entscheidung freiwillig als Rechtsgrundlage heranziehen.
Die europäische Rechtslage ist etwas liberaler wie kürzlich berichtet. Dort wurde auch bereits dieses Verfahren mit der kürzlichen EuGH-Entscheidung zum Urheberrecht an Computerprogrammen verglichen.