von: Dennis Jansen
 
In Oracle ./. Google (Beschluss v. 31.05.2012, C-10-03561 WHA, Bundesgericht der 1. Instanz im 9. Bundesgerichtsbezirk, Unterbezirk Nord-Kalifornien) hat der 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. Dabei erkannte das Gericht 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. Programmierer wollen dieselbe Methode auf dieselbe Weise wiederfinden können. (S. 12f.).

Eine vollständige Kopie 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 Jury sah zudem keine der Patente von Oracle verletzt.
 
Nicht nur können die einzelnen Methoden ("Mini-Programme") aus der Java-API nachprogrammiert werden, sondern sie können auch so implementiert werden, dass sie diejenigen von Oracle's Java direkt ersetzen können. Methoden können also in den gleichen Klassen (Sammlungen) mit den gleichen Namen enthalten sein und dieselben Parameter und Rückgabewerte unter den gleichen Namen haben wie bei Java. Das bedeutet, dass Deklarationen und Header-Dateien eins zu eins übereinstimmen können, ohne das Urheberrecht zu verletzen.

Grundsätzlich dürfen sie dabei zwar in ihrem Kopf, jedoch nicht in ihrem Kern, der den genauen Ablauf der einzelnen Aktionen einer Methode beschreibt, eine eins zu eins Kopie darstellen. Eine Ausnahme dazu kann der Vermischungsgrundsatz bewirken. Dieser greift, wenn es nur sehr wenige effiziente Möglichkeiten gibt, eine Methode zu implementieren. Dann vermischen sich nach diesem von einigen Gerichten angewandten Grundsatz Idee und Implementierung so stark, dass die Implementierung von der Idee vorgegeben ist und nicht länger auf freien kreativen Entscheidungen beruht.

Das Gericht erkannte die von Oracle vorgetragene Trennlinie zwischen der API von Java und der Programmiersprache Java nicht an (S. 12), sondern sieht die weiteren Methoden, die über die Kernfunktionalität hinausgehen, als weitere Bestandteile der Programmiersprache soweit die Deklaration, Klassen und Pakete und deren jeweilige Namen und Einteilungen betroffen sind. Diese Entscheidung dürfte auch tendenziell - jedenfalls 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.
 
Die Rechtslage ist noch alles andere als eindeutig in den USA. Das Gericht konnte klar feststellen, dass Namen, Titel und kurze Sätze nicht geschützt sind. Klar ist auch, dass nach amerikanischem Bundesgesetz dem Copyright Act von 1976 (vgl. UrhG) Ideen nicht schutzfähig sind, sondern nur die Implementierung. Problematisch ist jedoch, wo Ideen enden und die Implementierung anfängt und umgekehrt. Kernpunkt der Entscheidung war, wann die "Struktur, Abfolge und Organisation" auf die sich Oracle schwerpunktmäßig berief ein schutzfähiger Ausdruck der Idee ist.
 
Zunächst wurde Whelan Associates Inc. v. Jaslow Dental Laboratory, Inc. (1986) im 3. Bundesgerichtsbezirk ein sehr weiter Schutzbereich gezogen - alles was nicht zwingend für die Implementierung einer Idee nötig sei, wurde als geschützt angesehen. Der Gegenpol kristallisierte sich seit Computer Associates International, Inc. v. Altai (1992) im "Abstrakten-Filtrier-Vergleichstest" heraus. Demnach sind Strukturen, die durch Kriterien wie Geschwindigkeit, Nutzerfreundlichkeit, Effizienz, externe Faktoren wie Kompatibilitätsanforderungen und Design-Standards basieren oder gemeinfrei sind, nicht geschützt.
 
Die Entwicklung scheint in Richtung einer liberaleren Auslegung im Sinne der letzteren Entscheidung fortzuschreiten. Vorliegend musste sich das Gericht an bindende Präzedenz aus Johnson Controls, Inc. v. Phoenix Control Sys., Inc. (1989) halten, welches noch vor Computer Associates Int. erging und eher in Richtung des weiten Standards von Whelan tendierte. An diesem Standard orientiert bewirkt die Entscheidung einen vergleichsweise kleinen Schutzbereich und 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, dann jedoch in einer 4 zu 4 Patt-Situation nicht beantwortet worden.
 
Die Entscheidung ist streng genommen nicht bindend. US-Bundesgerichte sind nur an vorherige höherinstanzliche Entscheidungen aus ihrem Bezirk gebunden. Da es eine Entscheidung eines Gerichts der ersten Bundesinstanz ist, sind US-Gerichte derselben Instanz selbst aus dem  9. Bundesgerichtsbezirk also nicht daran gebunden. Jedoch wird sie voraussichtlich erhebliche Beachtung findend, da sie sich ausführlich, gründlich und recht überzeugend mit den zu grunde liegenden Problemen befasst. Gerichte aus dem eigenen Bezirk werden üblicherweise ähnlich entscheiden. 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.