Google vs. Oracle: Das wichtigste Urteil der IT seit Jahrzehnten
Jahrzehntelang war es allgemein akzeptierte Praxis für Entwickler, auch proprietäre APIs von anderen Herstellern und Konkurrenten nachzubauen und kompatible Software zu erstellen, notfalls auch durch Reverse Engineering. Das hat etwa erst den Boom der IBM-kompatiblen PCs in der 80er Jahren ermöglicht. Angezweifelt wurde diese Vorgehensweise des Nachbaus erst durch die Rechtsabteilung von Oracle nach dessen Übernahme von Sun. Daraus entspann sich ein Rechtsstreit , der inzwischen mehr als zehn Jahre andauert und in diesem Jahr wohl endlich letztinstanzlich vom Supreme Court der USA entschieden wird. Fest steht schon jetzt, dass die Praxis des API-Nachbaus nicht wie bisher weitergehen kann. Denn diese wird mit dem Urteil entweder komplett verboten, falls Oracle gewinnt, oder sehr stark eingeschränkt, falls Google gewinnt.
Die Auseinandersetzung zwischen Oracle und Google begann wie erwähnt mit der Übernahme von Java-Erfinder Sun und damit den Rechten an der Java-Technik durch Oracle im Jahr 2009 sowie den folgenden Genehmigungen der Kartellbehörden in den USA und Europa und letztlich dem Abschluss des Kaufs im Jahr 2010. 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. Eigentlich wurde IBM lange als möglicher Käufer von Sun gehandelt, was wohl dazu geführt hätte, dass die Java-Technik von Sun selbst mit jener von IBM zusammengeführt worden wäre.
Nicht lizenziertes Java in Android
Google erweiterte die Java-Implementierung von Harmony für Android weiter und passte diese in der Frühphase von Android stark an seine Bedürfnisse an. Als Rechtsnachfolger von Sun wirft Oracle Google aber in der ersten Klageschrift aus dem Jahr 2010 vor, mit seiner Nutzung von Java in Android diverse Patent- und Urheberrechte verletzt zu haben – immerhin verwendete Google zu dem Zeitpunkt kein von Oracle lizenziertes Java.
Die Übernahme der API geschieht nach Ansicht von Google lediglich aus Gründen der Interoperabilität zu bestehenden Java-Anwendungen. Darüber hinaus hat Google auch lediglich den Deklarationscode von 37 Java-API-Paketen übernommen, die eigentlichen Methoden aber in einem sogenannten Clean-Room-Design selbst erstellt. Genau das ist die eingangs erwähnte gängige Praxis.
Schon früh im Verfahren haben sich die beiden Unternehmen darauf geeinigt, nicht mehr über Patente zu verhandeln , sondern nur noch über die Urheberrechte an den APIs. In der ersten Instanz 2012 entschied das zuständige Bezirksgericht in Kalifornien dann, dass die APIs nicht dem US-Copyright unterliegen – was dem Verständnis der jahrzehntelangen Nachbauten entspricht. Ein Berufungsgericht hat die Erstinstanz jedoch 2014 überstimmt und festgestellt, dass die APIs doch dem Urheberrecht unterliegen, was bereits 2015 vom Supreme Court prinzipiell unterstützt wurde .
In der nun quasi zweiten Runde des Verfahrens versucht Google, den Rechtsstreit mit Hilfe eines Kniffs doch noch für sich zu gewinnen und beruft sich auf eine Fair-Use-Ausnahme im US-Urheberrecht(öffnet im neuen Fenster) . Diese Ausnahme hat wiederum ein Berufungsgericht im Frühjahr 2018 verneint , was damit die aktuell gültige Rechtsprechung ist. Google versucht nun, dieses Urteil vor dem US-Supreme-Court zu revidieren und die Fair-Use-Ausnahme zugesprochen zu bekommen. Eine erste Anhörung dazu hat bereits stattgefunden, das Urteil wird für den Frühsommer 2021 erwartet.
Welche der beiden Seiten gewinnt, ist zwar ungewiss, mögliche Lösungen für die damit zahlreich entstehenden neuen Probleme und das Ende einer jahrzehntelangen Praxis müssen aber auch erst gefunden werden. Der Umgang mit dem Urteil wird kommende Softwareprojekte entsprechend beschäftigen und die gesamte IT-Industrie prägen.
Google vs. Oracle: keine Gewinner, nur Verlierer im Java-Streit
Die weitreichenderen Konsequenzen des Urteils sind zu erwarten, falls der US-Supreme-Court im Sinne von Oracle entscheidet und eine Fair-Use-Ausnahme verneint. Das wäre im Prinzip auch eine erzwungene Niederlage für Google. Denn wie wir bereits in einer ausführlichen Analyse zu dem Urteil des Berufungsgerichts geschrieben haben, nutzt Google den Weg der Fair-Use-Ausnahme lediglich als Notnagel, um den Rechtsstreit doch noch für sich entscheiden zu können.
Es wäre aber auch eine Niederlage für eine über Jahrzehnte gelebte und akzeptierte Praxis, die die IT-Industrie insgesamt vorangebracht hat. So haben wir den Boom der ersten echten Heimcomputer und damit den Aufstieg von kleinen Software-Unternehmen zu weltweiten Konzernen letztlich auch den IBM-kompatiblen PC-Nachbauten und hier insbesondere den Nachbauten des IBM-Bios zu verdanken.
Auch die vielen Probleme des aktuellen Urteils bei der Betrachtung einer möglichen Fair-Use-Ausnahme haben wir bereits beschrieben. Die wohl wichtigste Frage dabei ist, ob die Übernahme der Java-APIs in Android "transformativ" ist, wie es das Gesetz fordert. In der Berufungsinstanz hieß es dazu, dass Google die APIs "wörtlich kopiert" habe. Bestätigt der Supreme Court diese enge Auslegung, könnten APIs eigentlich nie im Sinne der Fair Use nachgebaut werden. Denn ihren Zweck zu ändern, würde ja das Ziel des Nachbaus völlig unterlaufen.
Schlimmstenfalls könnte das eine riesige Klagewelle nach sich ziehen, die gegen entsprechende Nachbauten vorgeht. Ironischerweise könnte das auch Oracle selbst treffen, das für sein Cloud-Angebot Teile der AWS-API nachbaut. Im Prinzip wären dann aber sämtliche Nachbauten in Gefahr.
Das gilt insbesondere für jene, die eigentlich bereits durch gesetzliche Ausnahmen auch in den USA erlaubt sein sollten, wie etwa jene zu Kompatibilitätszwecken. API-Implementierungen entstehen mangels Alternativen teils auch durch Reverse Engineering. All dies könnte bei einer Entscheidung zugunsten Oracles in einer rechtlichen Grauzone landen oder eben direkt illegal sein.
Fair Use nur kleiner Schutz
Doch auch falls Google den Rechtsstreit gewinnen und dem Unternehmen eine Fair-Use-Ausnahme gebilligt werden sollte, sind die Auswirkungen nur wenig geringer. Immerhin gilt auch dann weiterhin, dass APIs generell dem Urheberrecht unterliegen und nicht einfach kopiert werden dürfen, sofern dies nicht explizit erlaubt ist.
Im Zweifel müssten auch dann wieder Gerichte Einzelfallentscheidungen dazu treffen, ob und inwiefern eine Fair-Use-Ausnahme für einen spezifischen API-Nachbau gilt oder eben nicht. Wie beschrieben, führt das zu einigen rechtlichen Problemen, was große Unsicherheiten für Projekte bergen könnte.
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ßerte in einem Interview(öffnet im neuen Fenster) die Befürchtung, dass bestimmte Innovationen künftig aus Furcht vor Klagen nicht umgesetzt würden. Dennoch gibt es natürlich weiter legale, kreative und vielleicht auch ungewöhnliche Wege aus eben dieser Lage.
API-Nachbau: Nichtangriffspakte und Open Source als Lösung
Die offensichtliche Lösung, APIs künftig weiter legal nachzubauen, ist, eine lizenzierte Version einer API zu nehmen und darauf ein eigenes Produkt aufzubauen, was auch unabhängig von der Entscheidung über die Fair-Use-Regeln möglich sein wird. Interessanterweise hat auch Google mit dem in Android genutzten Java selbst bewiesen, wie dies geht.
So hat das Unternehmen bereits vor Jahren den aus Apache Harmony stammenden Code gegen das unter der GPL stehende OpenJDK ausgewechselt , wobei es sich um die offizielle Java-Implementierung handelt, an der Oracle die Rechte hält. Im konkreten Fall ist das Problem also längst gelöst.
Für viele bestehende Projekte wird es solch eine einfache Lösung aber wohl nicht geben können. Hinzu kommt das Problem, dass zwar auch proprietäre APIs theoretisch durch Dritte lizenziert werden könnten. Es ist aber völlig unklar, ob sich künftig tatsächlich Unternehmen finden werden, die ihre Schnittstellen freiwillig der direkten Konkurrenz zur Verfügung stellen werden.
Dass dies auch anders gehen kann, zeigen bereits verschiedene IT-Projekte und Konsortien. So sind für Techniken wie den Webstandards des W3C oder den Internetstandards der IETF die APIs immer legal verfügbar. Auch weil deren Urheberrechtsrichtlinien dies eben von Anfang an so vorgesehen haben.
Für viele etwa von Industriekonsortien erstellte Standards gibt es derartige Lizenzen aber nicht kostenfrei. Andere verbieten selbst bei einer bezahlten Lizenznahme eine Open-Source-Implementierung. Das war bisher immer noch durch einen API-Nachbau möglich, was künftig aber deutlich schwerer werden könnte.
Große Kollaboration notwendig
Weitere Kollaborationsprojekte der Industrie in Bezug auf Patente zeigen ebenfalls, wie eine offene Zusammenarbeit auch von Konkurrenten funktionieren kann. Besonders wichtig ist hier vor allem das Open Invention Network (OIN) für Linux-Systeme oder die Alliance for Open Media (Aomedia), die für AV1 zuständig ist.
Bestenfalls lässt sich der Weg zu einer lizenzierten Nutzung einer API künftig also durch einen großangelegten Wandel der IT-Industrie erreichen. So könnten Konsortien ihre APIs sammeln und explizit allen anderen zur Verfügung stellen, wie dies bei den Patenten des OIN geschieht. Darüber hinausgehend wären auch Nichtangriffspakte für neue APIs denkbar.
Letzteres setzt aber wohl einen ebenso großen Wandel voraus wie die Öffnung von Techniken für Standards oder gar das direkte Offenlegen als Open-Source-Software. Die vergangenen Jahrzehnte haben gezeigt, dass das ein zäher und mühsamer Prozess ist.