Original-URL des Artikels: https://www.golem.de/news/oracle-vs-google-dieses-urteil-darf-nicht-bleiben-1804-133721.html    Veröffentlicht: 10.04.2018 12:00    Kurz-URL: https://glm.io/133721

Oracle vs. Google

Dieses Urteil darf nicht bleiben

Im Fall Oracle gegen Google fällt ein eigentlich nicht zuständiges Gericht ein für die IT-Industrie eventuell katastrophales Urteil. Denn es kann zu Urhebertrollen, Innovationsblockaden und noch mehr Milliardenklagen führen. Einzige Auswege: der Supreme Court oder Open Source.

Das jüngste Urteil im Rechtsstreit zwischen Oracle und Google um die Verwendung von Java-APIs in Android ist nicht nur ziemlich fragwürdig. Bleibt es bestehen, könnte es darüber hinaus auch eine ähnlich katastrophale Auswirkung auf die IT-Industrie der USA haben, wie es das extrem verworrene Patentsystem des Landes jetzt schon hat - und damit wohl auch auf den Rest der Welt. Dass es überhaupt so weit kommen konnte, liegt an einer unerwarteten und vergeigten Übernahme, einem eigentlich nicht zuständigen Berufungsgericht und einem grundsätzlichen Unverständnis in Bezug auf Programmcode. Einzige Auswege aus dieser Misere wären wohl ein Grundsatzurteil des Supreme Court oder ein vollständiger Wandel der IT-Industrie hin zu Open-Source-Software. Beides erscheint zurzeit nicht gerade wahrscheinlich.

Der Beginn der Auseinandersetzung zwischen Oracle und Google waren die Übernahme von Sun und damit der Rechte an der Java-Technik durch Oracle im Jahr 2009 sowie die folgenden Genehmigungen der Kartellbehörden in den USA und Europa und letztlich der Abschluss des Kaufs im Jahr 2010. Als möglicher Käufer für das defizitäre Unternehmen Sun ist Anfang des Jahres 2009 vielfach IBM genannt worden. IBM hatte aber wohl kurz vor einem Abschluss sein Angebot auf 7 Milliarden US-Dollar reduziert und der damalige Sun-CEO Jonathan Schwartz, der sich für eine Übernahme durch IBM einsetzte, konnte sich nicht gegen den restlichen Vorstand durchsetzen. Am Ende reichte Oracle ein Angebot über 7,4 Milliarden US-Dollar, um Sun relativ überraschend zu kaufen.

Keine API-Lizenz für Google

Die Übernahmeverhandlungen liefen mit Blick auf den laufenden Java-Rechtsstreit aus Sicht von Google nicht gut. Das von Google übernommene aufstrebende Smartphone-Betriebssystem Android setzte nicht nur auf die Programmiersprache Java, sondern auch auf die massiv von IBM vorangetriebene freie Java-Implementierung Apache Harmony. IBM und die Apache Foundation konnten in einer Auseinandersetzung mit Sun allerdings keine Einigung erzielen, um Harmony als kompatibel zu Suns Java zu bezeichnen. Sun veröffentlichte schließlich unter der Führung von CEO Schwartz das unter der GPL stehende OpenJDK für Java. Möglicherweise wollte IBM Sun unter anderem wegen dieser Lizenzprobleme übernehmen.

Für Google hätte ein Kauf durch IBM bedeutet, eine lizenzkostenfreie Java-Version in Android verwenden zu können, die vom Besitzer von Java stammt. Auch ein Rechtsstreit über einen möglicherweise rechtswidrigen Nachbau der API, wie ihn Oracle nun Google vorwirft, wäre bei einer Übernahme durch IBM wohl nie entstanden. Denn spätestens seit den IBM-kompatiblen PC-Nachbauten und hier insbesondere den Nachbauten des IBM-Bios Anfang der 80er Jahre war der gesamten IT-Industrie klar, dass IBM diese akzeptiert. So ist es aber nicht gekommen und Oracle setzte schnell eine Klage gegen Google um.

Als Rechtsnachfolger von Sun wirft Oracle Google in der ersten Klageschrift vor, mit der Nutzung von Java in Android diverse Patent- und Urheberrechte verletzt zu haben - immerhin verwendete Google zu dem Zeitpunkt kein von Oracle lizenziertes Java. Google hat allerdings nur den Deklarationscode von 37 Java-API-Paketen übernommen und die eigentlichen Methoden in einem sogenannten Clean-Room-Design selbst erstellt. Darüber hinaus nutzt Android anfangs mit Dalvik und später mit der Android Runtime (ART) keine Java-VM, sondern eigene Technik.

Die Übernahme der API geschieht nach Ansicht Googles lediglich aus Gründen der Interoperabilität zu bestehenden Anwendungen. Außerdem ist diese Art API-Nachbau nicht erst seit den IBM-PCs übliche und akzeptierte Praxis. Diese Vorgehensweise ist sogar so inhärent Teil des Wettbewerbs in der IT, dass zumindest in Europa Unternehmen ihre Konkurrenz immer wieder erfolgreich auf die Offenlegung ihrer Schnittstellen verklagen, um sie nachbauen zu können. Die Annahme der Möglichkeit zum Nachbau ist auch die Krux, die zu der aktuell eher verfahrenen Situation in dem Rechtsstreit geführt hat und Google zu einer eher vagen Verteidigungsstrategie zwingt.

Fair Use als Notnagel

So haben sich die Unternehmen schon früh im Verfahren darauf geeinigt, nicht mehr über Patente zu verhandeln, sondern nur über Urheberrechte. In der ersten Instanz entschied das zuständige Bezirksgericht dann, dass die APIs nicht dem Copyright unterliegen - was dem Verständnis der jahrzehntelangen Nachbauten entspricht. Ein Berufungsgericht hat die Erstinstanz jedoch überstimmt und festgestellt, dass die APIs doch dem Urheberrecht unterliegen, was vom Supreme Court prinzipiell unterstützt worden ist.

Allein das ist aus Sicht vieler Kommentatoren schon ein Skandal und kam für Google wohl auch extrem unerwartet, ist aber zumindest im konkreten Fall geltende Rechtslage. Die einzige Möglichkeit für Google, das Verfahren gegen Oracle darauf aufbauend doch noch zu gewinnen, ist, sich auf die Fair-Use-Ausnahme im US-Urheberrecht zu berufen. In einem erneuten Prozess mit teilweise aberwitzigen Argumenten am Bezirksgericht ist Google diese Ausnahme auch zugesprochen worden. Das Berufungsgericht hat dieses Urteil nun aber gekippt.

Kurioserweise ist das betreffende Berufungsgericht, der US Court of Appeals for the Federal Circuit (Federal Circuit), gar nicht für Urheberrechtsfragen zuständig, sondern für Patentrechtsfragen. Bereits 2012 ist dem Federal Circuit in dieser Position vom US-Magazin Ars Technica vorgeworfen worden, das Patentsystem skrupellos zerstört zu haben und für die aktuelle verfahrene Situation des US-Patentwesens verantwortlich zu sein. Es besteht die Gefahr, dass das künftig auch für das Urheberrecht geschieht. Denn sowohl die Annahme des Urheberschutzes für APIs als auch die aktuelle Fair-Use-Entscheidung sind schwer nachvollziehbar und die Argumentation des Gerichts wirkt teilweise konstruiert.

Zufällig zuständig

Dass das Federal Circuit als Berufungsgericht überhaupt zuständig ist, liegt an der anfangs im Verfahren noch strittigen Nutzung von Patenten. Sämtliche Berufungsverfahren mit Bezug auf Patente müssen vor dem speziell dafür geschaffenen Federal Circuit verhandelt werden, unabhängig davon, wo der eigentliche Rechtsstreit seinen Ursprung hat. Eigentlich werden Berufungen in den USA in Abhängigkeit vom Standort des Bezirksgerichts in festgelegten Gerichtsbezirken verhandelt.

Behandelte der Streit zwischen Oracle und Google nur das Urheberrecht, wäre das United States Court of Appeals for the Ninth Circuit (9th Circuit) zuständig. Das nun zuletzt ergangene Urteil stammt also von Richtern, die eigentlich nicht zuständig sind und darüber hinaus auch eigentlich keine Urheberrechtssachen verhandeln. Um diese Diskrepanz zu überbrücken, muss das Federal Circuit die Rechtsprechung des 9th Circuit anwenden. Dennoch liegt die Vermutung nahe, dass die Richter eventuell nicht die notwendige Erfahrung für den Fall haben und darüber hinaus den relativ engen Fokus ihrer Rechtsprechung auf Patente nun auch auf Urheberrechte anwenden.

Diese extrem enge Auslegung und auch offenbar ein Missverständnis in Bezug auf Unterschied von APIs zu Code zeigt sich bei einer näheren Analyse des Fair-Use-Urteils des Federal Circuit. Um mittels Fair Use urheberrechtlich geschützte Werke verwenden zu dürfen, müssen Gerichte vier festgelegte Faktoren bewerten und entsprechend gewichten. In der ersten Berufungsverhandlung konnten sich die Richter noch nicht darauf einigen, ob die Verwendung einem Fair Use entspricht und haben diese Frage wieder an ein Geschworenengericht verwiesen.

In dem aktuellen Urteil verweist das Gericht jedoch darauf, dass keine vernünftige Jury eine Verwendung im Sinne des Fair Use überhaupt hätte bejahen könnte und überstimmt somit die Entscheidung der Geschworenen. Das in seiner Wortwahl oft eher schnoddrige Blog Techdirt kommentiert hierzu, dass diese Tests den Gerichten zu viele Möglichkeiten lassen, sich für eine der beiden Parteien zu entscheiden und so die Tests auf ein bestimmtes Ergebnis hin zu verdrehen.

Vier kaputte Fair-Use-Tests

Der erste Fair-Use-Test fragt nach dem kommerziellen Nutzen der Übernahme. Dass Google mit der kostenlosen Verfügbarkeit von Android, und damit der Java-API, auch nicht kommerzielle Interessen verfolge, sei irrelevant. Denn auch die kostenlose Weitergabe von etwas, das Nutzer ansonsten kaufen müssten, könne eine kommerzielle Verwendung sein. Das Federal Circuit verweist hier als Präzedenz auf Verfahren gegen die Musiktauschbörse Napster im Jahr 2001.

Übertragen auf den konkreten Fall heißt das, allein schon deshalb, weil Oracle eine kommerzielle Java-Lizenz angeboten habe, könne der Nachbau kein Fair Use sein. Proprietäre APIs dürften bei einer derart engen Auslegung wohl so gut wie nie legal nachgebaut und weiterverteilt werden. Darüber hinaus verdiene Google zwar auch mit Android nicht direkt Geld, das sei für die Beurteilung eines kommerziellen Nutzens aber auch nicht relevant, da ein "direkter finanzieller Nutzen" dafür nicht notwendig sei. Dank des Erfolgs von Android habe Google offensichtlich einen indirekten finanziellen Nutzen.

Zu der Frage ob die Verwendung der Java-APIs in Android transformativ ist, diese also einer neuen Nutzung zuführt, schreiben die Richter, dass es schon vor Android Smartphones mit Java gegeben habe. Auch wenn die Frage hier wichtig wäre, ob etwa das als Beweis vorgebrachte Telefon Savaje als Smartphone gelten kann oder nicht, konzentrieren sich die Richter auf etwas anderes: So habe Google die APIs "wörtlich kopiert". Diese erfüllten überall die exakt gleiche Funktion wie Java, unabhängig davon, auf welcher Art Computer diese liefen. Der neue Kontext des Smartphones könne also auch nicht für eine Ausnahme herhalten.

Google hätte hier für eine Fair-Use-Ausnahme die Aussage oder Botschaft in der Verwendung der APIs ändern müssen. Mit einer Neuimplementierung des Methoden-Codes sowie einer Neuordnung anderer APIs um die von Oracle übernommen herum ist das aus Sicht von Google ja eigentlich auch geschehen. Das Gericht lässt dies aber nicht gelten, da eine Schnittstelle ja immer den gleichen Zweck erfüllt. Diese extrem enge Auslegung verweist wieder darauf, dass APIs eigentlich nie im Sinne des Fair Use nachgebaut werden könnten. Denn ihren Zweck zu ändern, würde ja das Ziel des Nachbaus völlig unterlaufen.

In Bezug auf die Art des urheberrechtlichen Werks stellt das Gericht wie zuvor bereits fest, dass Software explizit dem Urheberrecht unterliege. Zwar sei das originale Design der API ein kreativer Prozess und damit vom Urheberrecht geschützt, dennoch könnten die Geschworenen diese Arbeit als mehrheitlich funktional betrachten und so leicht eine Fair-Use-Ausnahme erlauben, schreiben die Richter und verwerfen das sofort wieder. Denn würde hier die Ausnahme angewandt, würde das Ziel, auch Software unter das Urheberrecht zu stellen, unterlaufen. Doch diese Argumentation zeigt eher, dass die Richter den grundlegenden Unterschied zwischen dem Deklarationscode und der Implementierung entweder nach wie vor nicht verstehen oder absichtlich keine Unterschiede gelten lassen wollen. Auch hier wäre ein Nachbau einer API im Sinne des Fair Use eigentlich nie möglich.

Zu viel kopiert

Zu Umfang und Bedeutung des übernommenen Werkes stellen die Richter fest, dass die Übernahme der APIs qualitativ bedeutend für die Erstellung von Android war. Google hat selbst zugegeben, wie wichtig die Verwendung gleichlautender APIs für den Erfolg war, statt eigene neue APIs mit gleicher Funktion zu erstellen. Zwar beruft sich Google hier auf die Rechtsprechung des 9th Circuit, nach der auch das gesamte Werk im Sinne des Fair Use kopiert werden dürfe, die Richter des Federal Circuit sagen jedoch, das gelte nur, wenn dies auch transformativ geschehe.

Eine Fair-Use-Ausnahme sei auch hier nicht gerechtfertigt. Der transformative Nachbau einer API, die ja immer den gleichen Zweck erfüllen soll, ist aber bei einer derart engen Auslegung wohl gar nicht möglich. Darüber hinaus sei das Kopieren der APIs im hier betrachteten Fall auch nicht "notwendig" gewesen. Denn das Erhöhen der Attraktivität, um externe Programmierer für Android zu gewinnen, sei eben nur einfacher gewesen, aber nicht notwendig.

Und statt der 170 Zeilen Code, die notwendig seien, um die Sprache Java zu erstellen, habe Google 11.500 Zeilen Code kopiert. Dass dies nur ein kleiner Umfang der fast 3 Millionen Zeilen in Java SE sei, spiele keine Rolle, da der Aufbau der API-Pakete in seiner Gesamtheit kopiert worden sei. Und auch das Hinzufügen anderer APIs sei kein Beweis dafür, dass der kopierte Teil einen geringen Umfang habe. Letztlich wird hier aber wieder der Unterschied zwischen Implementierung und Deklarationscode durch das Gericht aufgehoben.

Verlorenes Java-Lizenzgeschäft

Für den letzten der zu prüfenden Punkte stellen sich die Richter auf die Seite von Oracle. Letztlich sei Oracle, so die Entscheidung, nicht nur potenziell, sondern direkt um Einnahmen aus dem Lizenzgeschäft für Java gebracht worden, weshalb auch hier keine Fair-Use-Ausnahme gelten könne. So konkurrierte das kostenfreie Android direkt mit der lizenzkostenpflichtigen Java-Version von Oracle, die andere Hersteller wie das erwähnte Savaje oder Nokia in ihren Smartphones nutzten.

Da das Gericht ja schon festgestellt hat, das der API-Nachbau nicht transformativ ist, sondern die API überall gleiche Funktionen erfüllt, geht es hier wohl auch davon aus, dass das lizenzkostenfreie Java in Android in direkter Konkurrenz zu dem lizenzkostenpflichtigen Java von Oracle stand. Die tatsächlichen Unterschiede zwischen Oracles Java und Android sowie die möglichen Gründe der Hersteller, sich für die eine oder andere Option zu entscheiden, betrachtet das Gericht jedenfalls nur kurz. Immerhin handele es sich bei Android aus Sicht von Oracle um einen potenziell neuen Markt für Java in Smartphones, den aber eventuell auch andere Marktteilnehmer mit einer Lizenz von Oracle hätten besetzen können.

Zwar reiche die Konkurrenzsituation allein schon als Argument für finanzielle Schäden auf Seiten von Oracle aus, verstärkt wird dies zusätzlich aber noch dadurch, dass Amazon für seine Kindle-Tablets offenbar massive Nachlässe bei den Lizenzkosten mit dem Argument erwirkt habe, dass Android ja gratis verfügbar sei. Amazon hat also eine Java-Lizenz von Oracle für seine Nutzung von Android erworben. In dieser Betrachtung stützt sich das Gericht aber noch mehr als bei jener der Konkurrenzsituation auf die Behauptung Oracles, dass für die Nutzung von Java Lizenzzahlungen zu leisten seien und die freie Verfügbarkeit von Android diese eben unterlaufe. Nur ist das ja eigentlich eine Behauptung, die das Gericht selbst überprüfen müsste.

Bekräftigt wird dies durch Googles Verweis auf die kostenlose Verfügbarkeit von Oracles OpenJDK unter der GPL. Hersteller potenzieller Geräte mit Java hatten damit die Möglichkeit zwischen dem Kauf einer Lizenz oder dem Einhalten der Copyleft-Lizenz GPL zu wählen, die das OpenJDK nutzt. Die Android-Java-APIs standen dagegen unter der Apache-Lizenz. Damit war Java in Android, anders als beim OpenJDK, nicht nur frei verfügbar, sondern auch von den vergleichsweise weitgehenden Bedingungen der GPL befreit, was Android für andere Hersteller kommerziell attraktiver gemacht habe, so das Gericht. Die Vermutung, dass Oracle die bei vielen Unternehmen nicht gern gesehene GPL nutzt, um proprietäre Lizenzen zu verkaufen, ist damit zumindest indirekt bestätigt.

Supreme Court als Ausweg

Trotz der beschriebenen Probleme mit dem Fair-Use-Urteil ist auch das nun vorerst geltende Rechtslage und das Berufungsgericht Federal Circuit hat das Verfahren für einen dritten Prozess an das Bezirksgericht zurück verwiesen. Dort soll dann eine Jury über die Höhe von Schadenersatzansprüchen entschieden. Laut bisherigen Medienberichten könnte Oracle etwa 8 Milliarden US-Dollar fordern. Je nachdem für welche Summe sich die Jury entscheidet, könnte Oracle im dann dritten Anlauf erneut eine Berufung vor dem Federal Circuit erwirken, um die Höhe der Zahlungen noch zu vergrößern.

Viele Möglichkeiten, die Zahlungen noch zu verhindern, bleiben Google nicht. Die nun zunächst übliche Vorgehensweise könnte sein, das Federal Circuit zu einer erneuten Anhörung en banc aufzufordern. Das heißt, alle oder zumindest eine große Mehrheit der Richter am Federal Circuit müssten sich erneut mit der Berufung beschäftigen. Dass die Richter dann zu einem anderen Urteil kommen, ist wohl aber nicht besonders wahrscheinlich.

Als letzte Instanz könnte lediglich noch der Supreme Court das nun getroffene Fair-Use-Urteil überstimmen. Inwiefern das oberste Gericht jedoch den Fall annimmt oder nicht, ist zurzeit wohl auch deshalb fraglich, weil es in der ersten Runde der Berufung nicht geschehen ist. Allerdings hat sich seitdem die Zusammensetzung bei dem Gericht selbst sowie das Personal der beteiligten und relevanten Behörden wie dem Librarian of Congress oder beim Patent- und Markenamt (USPTO) geändert. Darauf weist die Reporterin Sarah Jeong hin, die den Prozess sowie die einzelnen Verhandlungen vor dem Bezirksgericht seit Jahren eng verfolgt.

Gründe für eine Verhandlung vor dem Supreme Court gibt es außerdem einige. So ist Fair Use eine der grundlegenden Doktrinen des US-Urheberrechts, aber immer abhängig von einer Auslegung. Diese könnte der Supreme Court nun erneut treffen wollen, vor allem weil nicht nur die im US-Justizwesen besonders wichtigen Geschworenen überstimmt worden sind, sondern auch weil das Berufungsgericht die Sache so klar beschreibt, dass die Geschworenen eigentlich keine andere Auslegung hätten finden können.

Für eine Verhandlung vor dem Supreme Court spricht ebenfalls der Vorgang, dass das Federal Circuit für Urheberfragen nicht zuständig ist und die Rechtsprechung des 9th Circuit anwenden muss. Hier könnte es weitere relevante Fälle des 9th Circuit geben, die der Federal Circuit nicht oder nicht ausreichend betrachtet hat. Die Reporterin Jeong nennt hier etwa eine Verhandlung über den letztlich nicht zugesprochenen urheberrechtlichen Schutz auf das sogenannte Bikram- oder Hot-Yoga.

Urhebertrolle für APIs

Sollte das Fair-Use-Urteil aber bestehen bleiben, ist davon auszugehen, dass es analog zu den bisher als Patent-Trollen bezeichneten Klägern in den USA künftig auch Urheber- oder besser API-Trolle geben könnte. So wäre es für Kläger möglich, für die Beklagten eventuell extrem kostspielige Verfahren anzustreben, die neben dem Urheberrecht an APIs auch Patente betreffen. Wie der Fall zwischen Oracle und Google zeigt, ließe sich dann auf die strittigen Patente verzichten, und das Verfahren landet dennoch beim Federal Circuit. Das wiederum dürfte dann seine extrem enge Auslegung des Fair Use aufrechterhalten.

Wie beschrieben sollte ein Fair-Use-kompatibler API-Nachbau unter diesen Bedingungen aber extrem schwierig oder gar unmöglich sein. Das hätte wohl wie beim Patentsystem zur Folge, dass sehr schnell sehr viele gleichartige Verfahren angestrebt werden. Immerhin ist der Nachbau von APIs eine weit verbreitete und vor allem übliche Praxis. Auch Oracle hat damit offenbar kein Problem und bietet für seine Cloud-Dienste einen API-Nachbau von Amazons S3-Dienst an. Solch eine Nutzung müsste dann künftig wohl immer lizenziert werden.

Der ehemalige EFF-Angestellte Parker Higgins, der nun für die Freedom of the Press Foundation arbeitet und das Verfahren ebenfalls seit Jahren verfolgt, äußert in einem Interview die Befürchtung, dass bestimmte Innovationen künftig aus Furcht vor Klagen nicht umgesetzt werden. Ebenso könnten sich kleine neue Wettbewerber eventuell die API-Lizenzen auch gar nicht leisten.

Den einzigen legalen Ausweg aus dieser Situation nutzt Google bereits in Android. Denn seit Android 7 alias Nougat verwendet Android das OpenJDK. Google hat damit eine Lizenz von Oracle zur Verwendung der Java-APIs in Android, nämlich die GPL. Zum kostenfreien legalen Nachbau einer API müsste letztlich immer eine Open-Source-lizenzierte Originalversion als Grundlage genommen werden. Für Techniken wie den Web-Standards des W3C oder den Internet-Standards der IETF sind diese zwar immer verfügbar, für viele etwa von Industriekonsortien erstellte Standards gibt es derartige Lizenzen aber eben nicht. Sollte es tatsächlich zu den API-Troll-Klagen kommen, könnten große Teile der IT-Industrie analog zum Patentsystem künftig aber auch ihre APIs einfach frei zur Verfügung stellen oder ihre Rechte wiederum zur Verteidigung und gegenseitigen Hilfe untereinander frei lizenzieren.  (sg)


Verwandte Artikel:
Oracle gegen Google: Java-Nutzung in Android kein Fair Use   
(27.03.2018, https://glm.io/133557 )
Programmiersprache: Java startet in Sechs-Monats-Rhythmus mit JDK 10   
(21.03.2018, https://glm.io/133452 )
Android 8.1 im Test: Ein Besuch auf der Oreo-Baustelle   
(06.04.2018, https://glm.io/133635 )
KI: Oracle setzt auf maschinelles Lernen in der Cloud   
(04.10.2017, https://glm.io/130409 )
Urheberrecht: EU-Bürger könnten Fair-Use-Ausnahme bekommen   
(13.03.2017, https://glm.io/126674 )

© 1997–2019 Golem.de, https://www.golem.de/