© ifong, 123RF

“Struktur, Folge und Anordnung” eines API unterlägen dem Urheberrecht, so urteilte ein US-Gericht im Verfahren Oracle gegen Google – es ging um Java und Android. Aber wie sähe das in Deutschland aus?

Java hat auch bei Google eine lange Geschichte. Nach Werkzeugen wie dem Google Web Toolkit setzte der Suchmaschinenriese auch dann konsequent auf Suns Progammiersprache, als er sein Handy-Betriebssystem Android aus Open-Source- und eigenen Tools zusammenstellte.

Geschätzt: Java

Developer schätzen Eigenschaften wie die Garbage Collection, Sicherheitsaspekte, die große Anzahl von Bibliotheken, Portabilität, aber auch erprobte und umfangreiche Entwicklungsumgebungen wie Eclipse [1]. Die Programmiersprache bleibt auch dann bei Entwicklern beliebt, wenn ihr vielerorts Python den Rang abzulaufen scheint [2].

Abbildung 1: Auch die Java Micro Edition (ME) steht heute unter dem Dach von Oracle.

Java auf mobilen Geräten war zwar schon vor der Smartphone-Ära vorhanden, zum Beispiel in Form von Java ME [3]. Aber Google entschied sich dagegen, eine Java Virtual Machine (JVM) von Sun, der Rechtsvorgängerin von Oracle, zu lizenzieren, sondern entwickelte eine eigene Runtime Machine (JRE) und taufte sie Dalvik. Die Gründe blieben unklar, vielleicht spielte die Performance eine Rolle, möglicherweise konnte der Konzern sich auch damals einfach nicht mit Sun einigen.

Um in der Java-Welt ernsthaft mitspielen zu können, war es wichtig, dass sich Googles VM exakt so wie das Original von Sun handhaben ließ. Technisch bedeutet das: Klassen und deren Methoden müssen gleich benannt sein und die gleiche Vererbungshierarchie aufweisen [4]. Nur dann bleibt sichergestellt, dass sich der riesige Schatz von Java-Bibliotheken, die Entwicklungsumgebungen und die Java-Syntax eins zu eins übernehmen lassen. Um dieses Ziel zu erreichen, entwickelte Google das Java-API, mehr als 37 Pakete, die mit den Originalpaketen von Sun-Java zumindest äußerlich identisch waren, sodass sich ein Java-Entwickler ohne Weiteres zu Hause fühlt.

Doch an diesen 37 neu implementierten Paketen störte sich die Oracle America Inc. und reichte im August 2010 Klage ein wegen Urheber- und Patentverletzung und Schadenersatz. Vor allem ein Copy&Paste-Lapsus dürfte Google da ärgern: Neun Zeilen Code von der »rangeCheck()« -Methode sowie weitere acht Security-Testfiles haben die Entwickler vom Original-Sun-Java übernommen. Klar, dass Oracle auch dies im Rahmen der Klage als Urheberrechtsverletzung geltend machte.

Ein US-Gericht entschied im Mai 2012 [5], dass die Übernahme der »rangeCheck()« -Methode und der Dateien zwar eine Urheberrechtsverletzung darstellen, aber nicht gravierend und daher unbeachtlich sei.

Nachbau erlaubt

Bei der »rangeCheck()« -Funktion handele es sich lediglich um neun Zeilen Code, und die Testdateien hat Google nie in Produkten verwendet. Soweit es das Java-API betrifft, entschied sich das Gericht aber gegen eine Urheberrechtsverletzung mit der Begründung, dass es kein urheberrechtlich geschütztes Werk im Sinne des Copyright Act darstelle. Jeder könne ein API nachbauen, das die gleiche Funktion besitzt. Die gleiche Namensgebung bei Klassen, Methoden sowie bei Parameteraufrufen schade nicht.

Oracle ging mit Erfolg in Berufung [6]. Zwar teilte das Berufungsgericht in seiner Entscheidung vom 12. Mai 2014 die Auffassung bezüglich der neun Zeilen Code und der Testfiles, nämlich dass eine Urheberrechtsverletzung vorliege. Abweichend machte es aber auch deutlich, dass auch neun Codezeilen und die Testfiles nicht der De-minimis-Regel unterliegen, also nicht als gering anzusehen sind und somit keine Bagatelle darstellen. Auch beim Java-API war das Berufungsgericht anderer Meinung.

Abbildung 2: Einen guten Einstieg in die Dalvik-Interna gibt der Vortrag von Dan Bornstein [4].

Hier urteilte es, dass die “Struktur, die Folge und die Anordnung” des API selbst dem Urheberrecht unterliegt und eine Urheberrechtsverletzung durchaus vorliegen könne. Allerdings könne diese ausnahmsweise zulässig sein, wenn ein Fall von Fair Use, also eine Schranke des Urheberrechts, vorläge. Eine mögliche Schranke könnte etwa die Herstellung von Interoperabilität sein. Um dies klären zu lassen, verwies das Berufungsgericht den Fall an das Ausgangsgericht zurück, eine finale Entscheidung steht noch aus.

Deutsches Recht

Wie wäre der Fall nach deutschem Recht zu beurteilen? Die »rangeCheck()« -Funktion mit ihren neun Zeilen wäre wohl gemäß §§ 2 Abs. I Nr. 1, 69a UrhG als Computerprogramm ein urheberrechtlich geschütztes Werk. Dies umfasst grundsätzlich auch den Quellcode und Entwürfe des Programms. Bei objektorientierten Programmen wird die Qualifizierung als Computerprogramm teilweise mit der Begründung verneint, dass Klassen erst dann zu einem Programm werden, wenn eine Instanz einer Klasse entsteht. Selbst die Anhänger dieser Auffassung würden aber möglicherweise einen Schutz nach § 2 Abs. 1 Nr. 7 UrhG als Darstellung technischer Art gewähren.

Schöpfungshöhe

Insgesamt wird der Schutzumfang gemäß § 69a UrhG aber eher weit ausgelegt. Eine besondere Schöpfungs- oder Gestaltungshöhe ist nicht vorausgesetzt, allerdings soll der Schutz entfallen, wenn das Programm durch seine völlige Trivialität oder Banalität gekennzeichnet ist. Ob dies bei der »rangeCheck()« -Methode der Fall ist, wäre dementsprechend zu prüfen. Da die Testfiles ja ebenfalls Programmcode enthalten, würde auch nach deutschem Recht eine Urheberrechtsverletzung vorliegen.

Abbildung 3: Die Google-Java-Variante sollte sich in der Bedienung nicht vom Original unterscheiden. © Dmitriy Shironosov, 123RF

Abbildung 4: Schon neun Zeilen Code und acht Dateien können Gegenstand einer Copyright-Klage sein. © Wilm Ihlenfeld, 123RF

Schwieriger gestaltet sich die Frage, ob das Java-API an sich Urheberrechtsschutz genießt. Der Gesetzgeber erwähnt Schnittstellen in § 69a Abs. 2 UrhG: Der gewährte Schutz gilt für alle Ausdrucksformen eines Computerprogramms. Ideen und Grundsätze, die einem Element eines Computerprogramms zugrunde liegen, einschließlich der den Schnittstellen zugrunde liegenden Ideen und Grundsätze, sind nicht geschützt.

Urheberrecht gilt auch für Schnittstellen

Aus dem Umkehrschluss dieses Absatzes wird jedoch gefolgert, dass die konkrete Implementierung einer Schnittstelle durchaus Urheberrechtsschutz genießen kann. Google hat das API weitestgehend selbst implementiert und die Hülle, also die Klassenhierarchie, die Namen von Klassen, Methoden und Eigenschaften, wörtlich übernommen.

Möchte man jedoch – wie die europäische Richtlinie zu fordern scheint – ein hohes Maß an Interoperabilität erreichen, wird man in der Auslegung eher dazu neigen, einen Urheberrechtsschutz zu verneinen. Ob allerdings das gesamte Java-API als Klon allein durch den Gedanken Interoperabilität gerechtfertigt werden kann, ist jedoch zweifelhaft und geht möglicherweise zu weit.

§ 69g UrhG stellt klar, dass die Anwendung sonstiger Rechtsvorschriften auf Computerprogramme unberührt bleibt. Besonders gilt dies für den Schutz von Erfindungen, Topographien von Halbleitererzeugnissen und Marken sowie den Schutz gegen unlauteren Wettbewerb einschließlich des Schutzes von Geschäfts-und Betriebsgeheimnissen sowie schuldrechtliche Vereinbarungen.

Abbildung 5: Das deutsche Recht stellt an die Schöpfungshöhe bei Programmen nur geringe Anforderungen. © alphaspirit, 123Rf

In seiner US-Klage hat Oracle darüber hinaus die Verletzung zweier Patente geltend gemacht. In Deutschland kommen selbst wettbewerbsrechtliche Ansprüche in Betracht, beispielsweise der ergänzende Leistungsschutz im Wettbewerbsrecht nach §§ 3, 4 Nr. 9 und Nr. 10 UWG in Form der unmittelbaren Leistungsübernahme.

Sun und später Oracle hatten viel Know-how und Software-Engineering in die Entwicklung von Java gesteckt, sodass es möglicherweise unlauter wäre, wenn Google die mit der Programmentwicklung hervorgebrachten Leistungen, beispielsweise die Ordnung der Klassen und die sonstige Gestaltung, von Java einfach übernimmt und so die Früchte abgreift, die eigentlich Oracle zustehen sollten.

Abbildung 6: Zum Copyright kommen auch noch Patentrecht und andere Regelungen. © Stuart Miles, 123RF

Fazit

Der Fall zeigt: Vorsicht ist angebracht. Schon die Übernahme von neun Zeilen Code kann eine Urheberrechtsverletzung darstellen, die zwar nicht automatisch eine Schadenersatzpflicht auslöst, jedoch angesichts von Abmahn- und eventuellen Gerichtskosten schnell ausufert. Auch Open-Source-Projekte sollten sich daher vor der Copy&Paste-Falle hüten und immer die Frage der Herkunft von Code und dessen Lizenz klären. Das Nachbauen von APIs ist problematisch und kann Urheberrecht, Patente, und Wettbewerbsrecht verletzen. (mfe)

Der Autor

Rechtsanwalt Dr. Christopher De Nicolo ist Mitglied der Rechtsanwaltskammer Nürnberg und berät eine Vielzahl von Open-Source-Firmen.