«Oracle vs. Google» – eine Urheberrechts-Saga in mehreren Akten

|

Michael Reinle

Ab Dezember 1990 entwickelte Sun Microsystems Java. Java enthielt eine neue Programmiersprache und eine Reihe von Bibliotheken zur Verwendung mit der Sprache. Die Java Plattform ermöglicht es Softwareentwicklern, durch den Einsatz einer virtuellen Maschine Programme zu schreiben, die auf verschiedenen Arten von Computerhardware ausgeführt werden können, ohne sie für jeden einzelnen Typ neu schreiben zu müssen («Write once, run everywhere»).

Die Java Programmiersprache besteht aus Schlüsselwörtern und anderen Symbolen sowie einem Satz von vorgefertigten Programmen («commands») zur Ausführung verschiedener Befehle. Der Satz der vorgefertigten Programme wird als Anwendungsprogrammierschnittstelle oder einfach API (auch «class libraries» genannt) bezeichnet. Im Zeitpunkt der ersten Streitigkeiten zwischen Oracle und Google verfügte die Java API über 166 «Ordner» («packages»), alle mit über sechshundert vorgefertigten Programmen («classes»), zur Ausführung von insgesamt über sechstausend Unterprogrammen («methods»). Die Unterprogramme bzw. Methods bestehen aus dem Titel | («Header») und dem «Body». Wichtig ist, dass der Titel den «Method Body» einführt und dessen Funktionen spezifiziert. Jeder, der eine Methode mit der gleichen Funktionalität liefern möchte, muss daher den Header auf die gleiche Weise schreiben. Der «Method Body» beinhaltet sodann die Code-Blöcke, welche die betreffende Methode implementieren. Im Verfahren wurde der «Method-Header» von den Parteien als «Declaration» qualifiziert, während der «Method Body» als «Implementation» bezeichnet wurde. Die vorangehend beschriebene Architektur würde im Source Code z. B. folgendermassen aussehen:

package java.lang;			// Declares package java.lang
public class Math {			// Declares class Math
	public static int max (int x, int y) {		// Declares method max
		if (x > y) return x;	// Implementation, returns x or
		else return y;	// Implementation, returns y
	}		// Closes method
}			// Closes class

Man könnte zwar den Methoden andere Namen geben und sie innerhalb der Pakete oder Klassen anders anordnen und trotzdem dieselbe Funktionalität erzielen. Die betreffenden Programme wären jedoch nicht mehr interoperabel. Durch die Verwendung der von Java vorgegebenen Struktur der API soll die Interoperabilität gerade gewährleistet werden. Die API sollen die Programmierung erleichtern («Instead of re-inventing the wheels in the API from scratch, programmers can call on the tried-and-true pre-packaged programs in the API. These are ready-made to perform a vast menu of functions. This is the whole point of the API»).

1995 lancierte Sun Microsystems Java unter der «Sun Community Source Licence». Dadurch wurde der Quellcode frei verfügbar. Sun verlangte allerdings, dass Produkte, die den Code verwenden, den Java Standard gewährleisten müssen. Zudem mussten alle kommerziellen, von Java abgeleiteten Programme durch Sun lizenziert werden.

2003 wurde Android Inc. mit dem Ziel gegründet, eine neue Plattform für Smartphones zu entwickeln. Nach der Übernahme von Android Inc. durch Google 2005 wandte sich Google an Sun Microsystems, um eine Lizenzierung der Java Bibliotheken zu besprechen. Die Verhandlungen scheiterten. Google entschied sich danach, eine eigene «cleanroom version» der Java Standard Edition Bibliotheken zu entwickeln. Google entwickelte die Bibliotheken ohne Zugriff auf den Code von Sun Microsystems. Diese Bibliotheken wurden ein Hauptbestandteil von Androids damaliger virtueller Maschine Dalvik.

Die virtuelle Maschine beinhaltete 37 API-Pakete sowie ungefähr 11 500 Linien Source Code, welche für Java zentral sind. Die API-Pakete und der Source Code wurden von Apache Harmony übernommen, eine open source cleanroom Java Implementierung der Apache Software Foundation. Das Apache Harmony Projekt wurde von Sun Microsystems nicht unterstützt und daher auch nicht validiert.

2010 kaufte Oracle Sun Microsystems und damit auch die Rechte an Java. Oracle klagte kurz nach dem Kauf von Sun Microsystems gegen Google.

Unbestritten war, dass Google die Java Programmiersprache kostenlos benutzen durfte. Unbestritten war auch, dass die virtuelle Maschine von Google keine Urheberrechte von Oracle verletzte. Unbestritten war zuletzt auch, dass Google den Method Body, d. h. die «Implementation» (siehe vorangehend unter I.), selbst programmiert und damit diesbezüglich keine Urheberrechte verletzt hat.

Die urheberrechtlich entscheidende Frage war vielmehr, ob Google frei war und ist, die Namen, die Organisation dieser Namen und die Funktionalität von 37 von 166 Java API-Paketen zu kopieren, die in diesem Rechtsstreit manchmal als Struktur, Sequenz und Organisation («Structure, Sequence and Organization [SSO]») der 37 Pakete bezeichnet wurden. Die identischen Code-Zeilen sind diejenigen Zeilen, die Namen, Parameter und Funktionalität der Methoden und Klassen spezifizieren. Diese Code-Zeilen werden «Declarations» oder «Headers» genannt (siehe vorangehend I.). Insbesondere hat die Android-Plattform die gleichen Paket-, Methoden- und Klassennamen, Definitionen und Parameter der 37 Java API-Pakete von der Java 2SE 5.0-Plattform übernommen.

Nebst dieser Hauptfrage hat Oracle Google vorgeworfen, den Code für die sog. «rangeCheck»-Funktion kopiert zu haben. Dies ist unbestritten. Google kopierte auch acht Computerdateien, indem es den Bytecode aus acht Java Dateien zurück in den Quellcode dekompilierte und dann den Quellcode verwendete. Diese Dateien wurden lediglich als Testdateien verwendet und fanden nie ihren Weg in Android oder ein mobiles Endgerät. Der Richter erachtete diese Vergehen als Urheberrechtsverletzung, betonte jedoch, dass diese im Vergleich zur streitigen Frage der Verletzung des Declaration Code und der SSO der 37 Java API-Pakete unerheblich sei.

Richter Alsup hat entschieden, dass der Declaration Code und die SSO der Java | API-Pakete nicht urheberrechtlich schützbar sind. Er hat deshalb die Klage in diesem Punkt abgewiesen. Richter Alsup stützte sich bei seinem Urteil auf die nachfolgenden Überlegungen:

Diese vom U.S. Copyright Office begründete Doktrin besagt, dass Namen, Titel und «Short Phrases» nicht urheberrechtlich geschützt werden können. «Even if a name, title, or short phrase is novel or distinctive or lends itself to a play on words, it cannot be protected by copyright».

Richter Alsup fasste bei seiner Entscheidfindung die bestehende Rechtsprechung zum urheberrechtlichen Schutz der Struktur, Sequenz und Organisation von Computerprogrammen detailliert zusammen. Er wies darauf hin, dass das Argument der SSO-Verletzung in der Vergangenheit jeweils dann bemüht wurde, wenn keine Übernahme der literarischen Komponenten der Software vorlag, d. h. keine Kopie des Codes geltend gemacht wird. Richter Alsup wies sodann darauf hin, dass bei der Frage der SSO-Verletzung eine Abgrenzung zum Patentrecht notwendig ist.

«A question then arises whether the copyright holder is more appropriately asserting an exclusive right to a functional system, process, or method of operation that belongs in the realm of patents, not copyrights».

Richter Alsup befasste sich sodann mit der Entstehungsgeschichte des urheberrechtlichen Softwareschutzes in den USA. Der Kongress hielt anlässlich einer Revision des Urheberrechtsgesetzes 1976 fest, dass Computerprogramme als literarische Werke urheberrechtlich geschützt sind. Zudem wurde Section 102(b) in den Copyright Act eingefügt:

«In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.»

Section 102(b) wurde insbesondere auch wegen des neuen Schutzes von Computerprogrammen im Gesetz verankert. Es wurde bald erkannt, dass die Grenzziehung zwischen urheberrechtlich geschützten Elementen von Computerprogrammen und urheberrechtlich nicht geschützten Elementen schwierig werden wird, wenn es sich nicht um Zeilen-bei-Zeilen-Kopien des Codes handelt.

Weil bis anhin in den USA keine Gerichtsentscheide zur Frage des urheberrechtlichen Schutzes von API und des Schutzes der SSO von API ergangen seien, setzte sich Richter Alsup mit der allgemeinen Rechtsprechung zum Schutz der SSO auseinander, d. h. eines nicht-literarischen Elementes des Computerprogrammes. Richter Alsup zeigte hierbei auf, dass sich die Rechtsprechung der verschiedenen US-Gerichte in dieser Frage stark unterscheidet.

Auf der einen Seite steht der Entscheid «Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc». In diesem Entscheid hatte das urteilende Gericht den urheberrechtlichen Schutz der SSO eines Computerprogrammes bejaht, obwohl der Beklagte seine Software mit einer anderen Programmiersprache programmiert hatte. Die Gemeinsamkeiten bezogen sich auf den nicht-literarischen Teil des Programmes («most of the file structures, and the screen outputs, of the programs were virtually identical five particularly important ‹subroutines› within both programs – order entry, invoicing, accounts receivable, end of day procedure, and end of month procedure – performed almost identically in both programs»). Das Gericht bejahte den Urheberrechtsschutz der Programmstruktur, weil es zahlreiche Optionen gab, dieselbe Funktion mit einer anderen Struktur auszuführen.

Auf der anderen Seite steht der Entscheid «Computer Associates International, Inc. v. Altai», welchem gemäss Richter Alsup die meisten Gerichte gefolgt seien bzw. welchen verschiedene Gerichte weiterentwickelt hätten. Das Gericht im Fall «Computer Associates International, Inc. v. Altai» erachtete den Ansatz im «Whelan»-Entscheid als zu undifferenziert und führte den sog. «abstract – filtration – comparison»-Test ein. Bei diesem Test wird das Com- | puterprogramm zunächst in seine strukturellen Komponenten aufgeteilt («abstract»), sodann werden diejenigen Komponenten herausgefiltert, welche nicht urheberrechtlich geschützt werden können («filtration»), und zuletzt verglich das Gericht diejenigen Komponenten, welche nicht «herausgefiltert» wurden, mit dem Computerprogramm des Beklagten auf deren Übereinstimmung («comparsion»). Das Gericht kam im Computer Associates-Entscheid gestützt auf diese Analyse zum Schluss, dass keine Urheberrechtsverletzung vorlag.

Richter Alsup hielt fest, dass die Erwägungen im «Whelan»-Entscheid zwar keine «dead letters» seien, dass sich jedoch die Gerichte im Sinne des Computer Associates-Entscheides viel differenzierter mit der Frage des urheberrechtlichen Schutzes der SSO eines Computerprogrammes auseinandersetzen würden.

Richter Alsup hielt gestützt auf die Rechtsprechungsanalyse fest, dass die folgenden Überlegungen im vorliegenden Fall entscheidend seien:

• –
  Under the merger doctrine, when there is only one (or only a few) ways to express something, then no one can claim ownership of such expression by copyright.
• –
  Under the names doctrine, names and short phrases are not copyrightable.
• –
  Under Section 102(b), copyright protection never extends to any idea, procedure, process, system, method of operation or concept regardless of its form. Functional elements essential for interoperability are not copyrightable.
• –
  Under Feist, we should not yield to the temptation to find copyrightability merely to reward an investment made in a body of intellectual property.

Richter Alsup unterschied bei seinem Urteil zwischen der «Implementation», d. h. dem Method Body, und der Declaration sowie den Headers für die Klassen und Methoden. Solange der spezifische Code, der zur Implementierung einer Methode verwendet wird, verschieden ist, steht es jedem Unternehmen frei, seinen eigenen Code zu schreiben, um genau die gleiche Funktion oder Spezifikation aller in der Java API verwendeten Methoden auszuführen. Das Design der Methoden könne zwar eine kreative Entwicklung darstellen (neue Methode, um einen neuen Output zu kreieren), solche Entwicklungen – auf Konzept- und Funktionalitätsebene – seien jedoch Gegenstand des Patentrechtes. Urheberrechtsschutz würde hier den Patentschutz und die strengere Prüfung der Schutzfähigkeit umgehen. Die Methoden-Spezifikation in der Declaration sei die Idee, während die Implementierung im Method Body die Expression sei.

Unerheblich war gemäss Richter Alsup, dass die «Declarations» und «Headers» für die Klassen und Methoden identisch sind. Nach den Regeln von Java müssten sie identisch sein, um eine Methode zu deklarieren, die die gleiche Funktionalität spezifiziert – auch wenn die Implementierung unterschiedlich sei.

«Under the rules of Java, they must be identical to declare a method specifying the same functionality – even when the implementation is different».

Gäbe es nur eine Möglichkeit, eine Idee oder Funktion auszudrücken, dann stünde es jedem frei, dies zu tun, und niemand könne diesen Ausdruck monopolisieren (Merger Doctrine). Die Headers seien zudem wegen der «Names and Short Phrases»-Doktrin nicht geschützt.

Richter Alsup hielt zwar fest, dass Google durchaus die Möglichkeit gehabt hätte, dieselben Funktionalitäten ohne die Übernahme der Struktur der API-Pakete von Java zu erreichen. Google hätte z. B. die verschiedenen Methoden anders gruppieren können, z. B. auch in anderen Klassen. Aber die Struktur der Java API und die betreffenden Declarations und Headers der Klassen und Methoden seien eben mehr als nur eine Aneinanderreihung von Namen. Sie seien vielmehr Symbole in einer Befehlsstruktur, wobei jeder Befehl eine zugeordnete Funktion aktiviert.

«The overall name tree, of course, has creative elements but it is also a precise command structure – a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability».

Richter Alsup kam gestützt auf diese Erwägungen zum Schluss, dass die von Oracle vorgebrachten Behauptungen nicht überzeugen und vorliegend die Struktur, Sequenz und Organisation der Java API-Pakete nicht urheberrechtlich schützbar seien.

«To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all other from writing their own different | versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition».

Gegen den ersten Entscheid des District Court erhoben beide Parteien Beschwerde. Weil die ursprünglichen Begehren von Oracle Ansprüche aus Patentrecht beinhalteten, wurde die Beschwerde dem Court of Appeals for the Federal Circuit zugewiesen. Dieser entschied am 9. Mai 2014, dass der Declaration Code und die Struktur der 37 Java API-Pakete, welche von Google übernommen wurden, urheberrechtlich geschützt sind. Er kassierte damit den Entscheid des District Court und wies die Angelegenheit zur Prüfung der Frage des Fair Use an diesen zurück.

Der Court of Appeals vertrat die Auffassung, dass der District Court die Frage des urheberrechtlichen Schutzes, wofür die Anforderungen relativ tief seien, mit der Frage der Urheberrechtsverletzung vermischt habe. Zudem habe der District Court zu Unrecht Fair Use-Überlegungen (Frage der Interoperability) in die Prüfung des urheberrechtlichen Schutzes miteinbezogen.

Betreffend den Declaration Code hielt der Court of Appeals fest, dass dieser vorliegend urheberrechtlich geschützt sei. Der District Court habe die Merger-Doktrin falsch angewandt. Entscheidend sei nicht, ob der Verletzer im Zeitpunkt der Verletzung unterschiedliche Optionen bzw. eben keine anderen Optionen gehabt habe, um die Idee auszudrücken. Die Frage des Urheberrechtsschutzes – nicht der Verletzung – sei im Zeitpunkt der Entstehung des Werkes zu prüfen. Der Court of Appeals kam zum Schluss, dass Sun / Oracle unzählige Optionen hatten, um den Declaration Code zu gestalten. Zudem hätte Google andere Header für die Methoden und Klassen der eigenen API-Pakete verwenden können, ohne dass deren Funktionalität dadurch beeinträchtigt gewesen wäre. Von einem Merger zwischen Idee und Ausdruck könne daher keine Rede sein. Zuletzt habe der District Court auch die «Names and Short Phrases»-Doktrin falsch angewandt. Diese Doktrin bedeute nicht, dass kurze Sätze per se schutzunfähig seien. Vielmehr sei zu prüfen, ob die kurzen Sätze dennoch kreativ seien. Zudem könne eine Kombination von kurzen Sätzen oder Namen originell und damit schützbar sein. Oracle würde vorliegend nicht Schutz für spezifische Namen und kurze Sätze verlangen, sondern für 7000 Zeilen Declaration Code.

Auch betreffend die Frage der Schutzfähigkeit der Struktur, Sequenz und Organisation der API-Pakete vertrat der Court of Appeals eine andere Auffassung als der District Court.

Der Court of Appeals analysierte die relevante Rechtsprechung analog zum District Court, qualifizierte die Struktur der API-Pakete jedoch anders als der District Court. Der Court of Appeals stellte fest, dass literarische Werke Computerprogramme beinhalten, «to the extent that they incorporate authorship in the programmer’s expression of original ideas, as distinguished from the ideas themselves». Es war zwischen den Parteien unbestritten, dass der Declaration Code und die Gesamtstruktur der API-Pakete originell waren.

Umstritten war jedoch, ob es sich bei der Struktur der API-Pakete um eine gemäss § 102 (b) des U.S. Copyright Acts nicht urheberrechtlich schützbare Idee, ein Verfahren, einen Prozess, ein System, eine Operationsmethode oder ein Konzept handelt. Der Court of Appeals wies darauf hin, dass diese Prüfung im Einzelfall nicht einfach sei und die Gerichtsentscheide diesbezüglich teilweise deutlich auseinandergehen würden. Er hielt fest, dass vorliegend der «abstraction – filtration –comparison»-Test anwendbar sei. Der Test würde jedoch einen relativ breiten Vorgehensansatz darstellen und bedürfe einer differenzierten Beurteilung des konkreten Programmes, um zu bestimmen, welche Komponenten eine «Expression» seien und welche lediglich die «Idee» darstellen.

Der Court of Appeals betonte, dass im Gegensatz zur Erwägung des District Court die in § 102(b) des U.S. Copyright Act genannten Verfahren, Prozesse, Systeme, Operationsmethoden etc. nicht per se vom Urheberrechtsschutz ausgeschlossen seien. Die Darstellung («Expression») einer Operationsmethode oder eines Verfahrens könne durchaus schutzfähig sein. Die Auffassung des District Court – die SSO seien vorliegend zwar «expressive», aber eben auch funktional und damit nicht schutzfähig – würde dazu führen, | dass Computerprogramme faktisch nie schutzfähig seien. Computerprogramme hätten per Definition immer einen funktionalen Zweck. Der Court of Appeals unterstützte die Auffassung von Oracle, dass Google zwar die Java Programmiersprache und auch die abstrakte Paket-Klasse-Methode-Struktur verwenden könne. Google dürfe jedoch nicht die von Oracle gewählten präzisen Bezeichnungen oder die präzise Struktur verwenden. Entscheidend war zudem, dass Google Android auch anders hätte strukturieren können, um dieselben Funktionalitäten wie bei Java zu erreichen.

Zuletzt vertrat der Court of Appeals die Auffassung, dass der District Court das Thema der Interoperabilität (zwischen Android und der Java Plattform) zu Unrecht bei der Frage des Urheberrechtsschutzes berücksichtigt habe. Interoperabilität sei vielmehr ein Thema, welches nach der Bejahung der Schutzfähigkeit im Zusammenhang mit der Fair Use Defense bei der Beurteilung der Urheberrechtsverletzung zu prüfen sei. Es sei insbesondere nicht korrekt, bei der Prüfung der Schutzfähigkeit eines Computerprogrammes darauf abzustellen, ob ein späterer «Verletzer» das Computerprogramm oder Teile davon übernehme, um sein Produkt interoperabel auszugestalten. Entscheidend sei vielmehr, ob die Entwickler des Computerprogrammes, dessen Schutzfähigkeit zu prüfen ist, bei der Entwicklung und Ausgestaltung des Programmes durch externe Faktoren wie die Interoperabilität mit anderen Programmen eingeschränkt gewesen seien.

Im Oktober 2014 hatte Google an den Supreme Court das Gesuch gestellt, dass dieser sich mit der Angelegenheit, d. h. der Frage des Urheberrechtschutzes, befasst. Am 26. Mai 2015 hatte der U.S. Solicitor General dem Supreme Court empfohlen, nicht auf das Gesuch einzutreten. Der U.S. Solicitor General war der Auffassung, dass der Entscheid des Court of Appeals korrekt war. Mit Entscheid vom 29. Juni 2015 hatte der Supreme Court das Gesuch von Google abgelehnt.

Wie vom Court of Appeals in seiner Rückweisung der Angelegenheit verlangt, hatten Richter Alsup bzw. die Jury beurteilt, ob die Übernahme der 37 API-Pakete durch Google sich durch Fair Use rechtfertigen lässt. Die Jury kam zum Schluss, dass ein Fair Use vorliege. Gegen diesen Entscheid hatte Oracle eine sog. Rule 50 Motion eingereicht, welche jedoch am 8. Juni 2016 von Richter Alsup abgelehnt wurde.

Die Jury und nachher Richter Alsup hatten zu entscheiden, ob jemand, der mit der Java Programmiersprache arbeitet, berechtigt war, nicht nur die für die Programmiersprache zwingenden Funktionen der Java Bibliothek zu vervielfältigen, sondern auch andere Funktionen mit den entsprechenden Declaration Codes, solange er den Implementation Code selber entwickelte. Oracle vertrat die Auffassung, dass jedermann berechtigt ist, die Java Programmiersprache zu verwenden. Jeder ist deshalb auch berechtigt, die 62 für die Programmiersprache zwingenden Klassen in der Java Bibliothek zu verwenden. Jedermann sei zudem berechtigt, die Funktionalitäten aller Methoden nachzuahmen, sofern er einen anderen Declaration Code und eine andere SSO verwendet. Google hätte demnach die Funktionalitäten der 37 API-Pakete in einer anderen SSO organisieren können. Programmierer, welche sowohl Programme für das Java System als auch das Android System schreiben, hätten in diesem Fall jedoch mit zwei unterschiedlichen Strukturen arbeiten müssen. Diese Inkompatibilität hätte gemäss Jury und auch Richter Alsup zu Verwirrung und Irrtümern führen können.

Beim ersten Faktor der Fair Use-Analyse («purpose and character of the use, including whether such use is of commercial nature or is for non profit educational purposes») prüften die Jury und Richter Alsup insbesondere, ob die Verwendung «transformative» ist. Transformative Nutzung bedeutet, dass etwas Neues mit einem zusätzlichen Zweck oder einem anderen Charakter hinzugegeben wird, was das ursprüngliche Werk mit einem neuen Ausdruck, einer neuen Meinung oder einer neuen Aussage verändert. Die Jury und auch Richter Alsup waren der Auffassung, dass die Verwendung der 37 API-Pakete durch Google eine transformative Nutzung darstelle. Google habe die 37 API-Pakete aus den insgesamt 166 ausgewählt, mit einem eigenen Implementation Code implementiert und mit neuen | Paketen, Klassen und Methoden kombiniert, welche durch Google spezifisch für Smartphone Plattformen geschrieben wurden. Dies habe zu einem neuen Nutzungskontext geführt und damit den übernommenen API-Paketen einen neuen Ausdruck, eine neue Bedeutung bzw. eine neue Aussage gegeben. Es wurde hierbei erwähnt, dass die ursprünglichen API-Pakete von Java für Desktops und Notebooks entwickelt wurden. Google habe diejenigen (37) Pakete ausgewählt, welche für die Smartphone-Nutzung geeignet waren. Die Jury und Richter Alsup prüften zusätzlich, ob Google mit guten Absichten agierte und ob es sich bei der Nutzung der API-Pakete durch Google um einen kommerziellen Zweck handelte, was zwar unbestritten der Fall war, durch das Anbieten von Android als Open Source Software aber abgeschwächt worden sei.

Im Zusammenhang mit dem zweiten Fair Use-Faktor («the nature of the copyrighted work») kamen die Jury und Richter Alsup zum Schluss, dass weder der Declaration Code, noch die Struktur der API-Pakete überaus kreativ seien. Auch wenn der Code und die Struktur originell genug seien, um Urheberrechtsschutz zu geniessen, sei deren Design dennoch von funktionalen Überlegungen dominiert. Der zweite Faktor wirke sich daher nicht allzu stark zu Gunsten von Oracle aus.

Auch beim dritten Fair Use-Faktor («examination of the amount and substantiality of the portion used in relation to the copyrighted work as a whole») entschieden sich die Jury und Richter Alsup zu Gunsten von Google. Gemäss Richter Alsup konnte die Jury mit vernünftigen Gründen davon ausgehen, dass Google das Minimum der 37 API-Pakete kopiert habe, um die sog. Inter-System Consistency zu wahren. Indem Google lediglich den Declaration Code und die Struktur übernommen habe, nicht jedoch den Implementation Code, hätte Google nur so viel kopiert, wie für den transformativen Zweck notwendig.

Zuletzt entschieden sich die Jury und Richter Alsup auch beim vierten Faktor («the effect of the use upon the potential market for or value of the copyrighted work») zugunsten von Google. Die Übernahme des Declaration Code (sowie der SSO) in Android habe den Markt für die Java Plattform nicht beeinträchtigt, da diese auf Desktops und Notebooks ausgerichtet sei. Die Umsätze von Java ME seien zudem, wie von Sun vorausgesagt, gesunken, bevor Android auf den Markt gekommen sei. Android habe daher keinen zusätzlichen negativen Einfluss auf die Marktentwicklung von Java ME gehabt.

Oracle zog den Entscheid der Vorinstanz betreffend Fair Use an den Court of Appeals for the Federal Circuit weiter. In seinem Entscheid vom 27. März 2018 folgte der Court of Appeals den Argumenten von Oracle. Das Vorgehen von Google entspreche nicht Fair Use. Der Court of Appeals wies die Angelegenheit an den District Court zurück, damit dieser über den Schadenersatz befinden könne.

Der Court of Appeals verwies darauf, dass trotz der Verankerung der Fair Use Defense in § 107 U.S. Copyright Act die Fair Use-Prüfung als «the most troublesome in the whole law of copyright» betrachtet wurde.

Bezüglich des ersten Faktors der Fair Use-Prüfung hielt der Court of Appeals fest, dass durch die kostenlose Abgabe von Android der kommerzielle Zweck nicht ausgeschlossen sei. Ein direkter ökonomischer Vorteil sei für das Vorliegen eines kommerziellen Zweckes nicht notwendig. Der überwiegende kommerzielle Zweck spreche daher gegen Fair Use. Der Court of Appeals sprach Google auch eine transformative Nutzung ab. Der Zweck der API-Pakete in Android sei derselbe wie in der Java | Plattform. Google habe zudem den «expressive content or message» des urheberrechtlich geschützten Materials nicht verändert – entscheidend sei hierbei nicht, dass Google den Teil, der nicht kopiert wurde, selber neu geschrieben habe. Schliesslich seien Smartphones auch kein neuer Kontext. Die im Verfahren eingereichten Unterlagen würden zeigen, dass Java SE APIs in Smartphones verwendet wurden, bevor Android in den Markt eintrat. Oracle habe Java SE in SavaJe Mobiltelefonen verwendet sowie an Hersteller von Mobiltelefonen lizenziert (z. B. Danger und Nokia). Die überwiegende kommerzielle und die fehlende transformative Nutzung führten dazu, dass der erste Faktor gegen Fair Use spricht.

Beim zweiten Faktor («nature of the copyrighted work») bestritt der Court of Appeals nicht, dass der Declaration Code und die SSO der API-Pakete nicht überaus originell sind. Der zweite Faktor spreche zwar für einen Fair Use, er sei jedoch gemäss Rechtsprechung des Ninth Circuit für die gesamte Fair Use-Beurteilung nicht überaus gewichtig.

Beim dritten Faktor («amount and substantiality of the portion used») sprach sich der Court of Appeals wiederum zugunsten von Oracle aus. Der Court of Appeals hielt fest, dass für die Java Programmiersprache nur 170 Code Zeilen notwendig wären. Google habe jedoch 11 500 Zeilen kopiert. Google habe damit um einiges mehr kopiert als für die Nutzung der Programmiersprache notwendig. Der Court of Appeals widersprach auch dem Argument des District Courts, dass Google nur gerade diejenigen API-Pakete kopiert habe, welche für die Inter-System Consistency zwischen der Android und Java Plattform notwendig seien. Gemäss Court of Appeals sei es Google gar nie um diese Inter-System Consistency gegangen. Google habe beabsichtigt «to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue». Es bestünde jedoch kein inhärentes Recht darauf, die Popularität des urheberrechtlich geschützten Werkes durch dessen Übernahme auszunutzen. Die Elemente, welche kopiert wurden, seien zudem qualitativ nicht unerheblich gewesen. Die kopierten Komponenten seien für die Entwicklung der Android Plattform überaus wichtig gewesen. Der dritte Faktor sei im besten Fall neutral, spreche aber eher gegen Fair Use.

Beim vierten Faktor («effect upon the potential market») hielt der Court of Appeals fest, dass nicht nur die Beeinträchtigung des aktuellen oder potenziellen Marktes für die urheberrechtlich geschützten Werke relevant sei, sondern auch der Markt für mögliche derivative Nutzungen. Betreffend den aktuellen Markt gehe aus den Unterlagen hervor, dass Java SE bereits in mobilen Endgeräten genutzt wurde, bevor Android auf den Markt kam. So habe Oracle Java SE für den Amazon Kindle lizenziert. Als Android auf den Markt gekommen sei, habe sich Amazon für Android entschieden. Die Lizenzierung von Java SE für die Nutzung in mobilen Endgeräten mit höherer Leistungsfähigkeit sei ein potenzieller Markt für Oracle gewesen. Dies würden auch die Verhandlungen zwischen Oracle und Google zeigen. Es sei dabei irrelevant, dass Oracle selber kein Smartphone auf den Markt gebracht habe. Der potenzielle Markt beinhalte die Lizenzierung an andere zur Entwicklung eines derivativen Werkes. Zusammenfassend wiege der vierte Faktor besonders schwer gegen Fair Use.

Im Januar 2019 hat Google ein Gesuch an den Supreme Court eingereicht mit der Aufforderung, die beiden Urteile des Court of Appeals for the Federal Circuit zu prüfen. Am 15. November 2019 hat der Supreme Court mitgeteilt, dass er den Fall anhören wird.

Im Zusammenhang mit diesem zweiten Gesuch an den Supreme Court sind zahlreiche sog. Amicus Curiae Briefs eingegangen. Insbesondere haben 65 IP-Professoren einen solchen Amicus Curiae Brief zur Unterstützung von Google eingereicht. Die Professoren kritisieren, dass der Entscheid des Court of Appeals in entscheidenden Fragen von der Rechtsprechung des Supreme Courts und anderer Circuit Courts abweichen würde.

|

1. Der Rechtsstreit zwischen Oracle und Google ist nicht nur spannend, weil es sich um zwei Technologie-Schwergewichte handelt, sondern weil die Gerichte in ihren Urteilen die bestehende Rechtsprechung zum urheberrechtlichen Schutz von Computerprogrammen in den USA ausführlich dargestellt und seziert haben.

2. Gewisse Autoren sehen bei einer Niederlage von Google ein in der Programmier-Industrie übliches Vorgehen in Gefahr. Der Nachbau von API, welcher für die Interoperabilität von Systemen entscheidend sei, wäre allenfalls verunmöglicht oder beeinträchtigt.

3. Aus Sicht des schweizerischen Rechts sind die Urteile und die Erwägungen insofern spannend, als bei der Frage des urheberrechtlichen Schutzes von Computerprogrammen die Unterscheidung zwischen Idee und Ausdruck ebenfalls entscheidend ist. Auch wenn es in den wenigen Entscheiden, welche sich mit Urheberrechten an Computerprogrammen befassten, primär um Vervielfältigungen des Source Code ging, dürfte auch für die Schweiz unbestritten sein, dass nicht-literarische Komponenten einer Software urheberrechtlich geschützt sein können, sofern es sich nicht um eine Idee, sondern deren Ausdruck handelt und solange dieser Ausdruck die vom Urheberrecht verlangte schöpferische Höhe erreicht. Die Anforderungen hierfür sind auch in der Schweiz eher tief.

4. Bei der Beurteilung des urheberrechtlichen Schutzes von nicht-literarischen Komponenten einer Software dürfte eine Orientierung am sog. «abstraction – filtration – comparison»-Test durchaus sinnvoll sein. Wie der Court of Appeals in seinem Urteil zu Recht festgehalten hat, liegt der Teufel jedoch im Detail. Der Test kann daher nur als konzeptionelles Gedankengerüst betrachtet werden. Er ändert nichts daran, dass für jede Komponente im Einzelfall entschieden werden muss, ob es sich um eine Idee oder einen Ausdruck handelt.

5. Die Fair Use-Beurteilung ist aus schweizerischer Sicht zwar spannend, aber nicht unmittelbar relevant. Das schweizerische Urheberrechtsgesetz verfügt nicht über einen allgemeinen Fair Use-Artikel. Vielmehr hat der Gesetzgeber konkrete Schranken des Urheberrechts in das Gesetz implementiert, welche Fair Use-Überlegungen als Basis haben. Die Schrankenregelung ist abschliessend. Im Zusammenhang mit Computerprogrammen stellt Art. 21 URG eine Schranke auf. Art. 21 URG befasst sich mit der Entschlüsselung von Computerprogrammen, welche der betreffende Nutzer rechtmässig durchführen darf, um Informationen über Schnittstellen zu anderen, unabhängig entwickelten Programmen zu beschaffen (Abs. 1). Die Schnittstelleninformationen dürfen gemäss Abs. 2 nur zur Entwicklung, Wartung sowie zum Gebrauch von interoperablen Computerprogrammen verwendet werden, soweit dadurch weder die normale Auswertung des Programmes noch die rechtmässigen Interessen der Rechteinhaber und -inhaberinnen unzumutbar beeinträchtigt werden. Ob Art. 21 URG vorliegend anwendbar wäre, ist nicht leicht zu entscheiden. Es handelt sich bei den Java API nicht um die Art von Schnittstellen, an welche der Gesetzgeber bei Art. 21 URG gedacht hat und mit welchen sich die Literatur zu Art. 21 URG befasst. Die Java API stellt vielmehr eine «Schnittstelle» innerhalb des Java Systems dar. Der Court of Appeals hat die API auch als Shortcuts für die Programmierung bezeichnet. Eine Anwendung von Art. 21 URG auf Java API ist deshalb allerdings nicht von vornherein ausgeschlossen. Dies auch deshalb, weil die Interpretation der einzelnen Elemente von Art. 21 URG in der schweizerischen Literatur umstritten ist.