von: Stefan Labesius
Android entwickelt sich zu einem fruchtbaren Boden für juristische Auseinandersetzungen. Erst vor einigen Tagen hat Microsoft bekannt gegeben, dass wegen möglicher Patentverletzungen bei der Implementierungen von Technologien in dem Mobilgerätebetriebssystem gerichtliche Schritte eingeleitet werden. Aber auch mögliche Verstöße gegen die GPL durch das unter der Federführung von Google entwickelte Betriebssystem wurden jüngst vorgebracht.
In diesem Zusammenhang wird Google nun vorgeworfen, Code des Linux-Kernels kopiert und in Android eingebaut zu haben, ohne eine entsprechende Lizenzierung vorzunehmen. Gegenstand des Vorwurfs ist Code der sog. bionic libc des Android-Betriebssystems, der Elemente aus ca. 750 sog. Header-Dateien des Linux-Kernels enthalten soll. Solche Header-Dateien finden in Programmiersprachen (z.B. C, C+) Verwendung, um Inline-Code, Variablen, Subroutinen oder generell Deklarationen zusammenzufassen, die wiederkehrend im Programmablauf verwendet und jeweils gesondert geladen werden. Die bionic libc stellt unter Android die Implementierung einer C Standard Libary (libc) dar, wofür unter Linux in der Regel die glibc verwendet wird. Während die glibc unter der LGPL steht, gilt für die bionic libc sowie die libc eine BSD-Lizenz. Von einem GPL-Verstoß kann somit noch nicht ausgegangen werden, soweit lediglich durch den Softwarecode Funktionen der libc in der bionic libc implementiert werden. Nun wird Google allerdings vorgeworfen, bei der Entwicklung der bionic libc aber auch Bestandteile von Header-Dateien übernommen zu haben, die ihrerseits unter LGPL bzw. GPL lizenziert sind.
Jedoch lässt sich die Frage nach der Einordnung der Header-Dateien bzw. davon abgeleitete Dateien unter der GPL bzw. LGPL lizenzierte Werke und damit die Frage nach einem Verstoß gegen die GPL nicht pauschal beantworten. Die GPL v2 geht beispielsweise davon aus, dass Code dann nicht unter die Lizenz fällt, wenn dieser nicht nur ein selbstständiges Softwaremodul darstellt, sondern auch als eigenständiges Werk weitergegeben wird bzw. werden kann (vgl. Ziff. 2 GPL v2). Eine derartige eigenständige Verbreitung liegt hierbei dann nicht vor, wenn ein solches selbstständiges Softwaremodul mit den GPL-Bestandteilen zusammen als „Teil des Ganzen“ verbreitet wird. Welche Auswirkungen dies konkret auf Code hat, der unter Einbeziehung von Header-Dateien, die unter (L)GPL stehen, ist im Einzelnen unklar. Jedenfalls in Bezug auf Linux-Code wird dies durch eine auf Linus Torvalds zurückgehende Ergänzung der GPL v2 für Linux klargestellt, in der es heißt:
"This copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel and does *not* fall under the heading of »derived work«."
Danach sind sog. system calls, also auch Zugriffe auf entsprechende Header-Dateien, und daraus resultierende Kompilate von Userspace-Programmen nicht als Bearbeitungen sondern als gewöhnliche Nutzung zu verstehen. Hintergrund dieser eingeschränkten Geltung, ist in der Begrenzung der GPL auf den sog. Kernelspace zu sehen, um so Programme, die um sog. Userspace ablaufen, nicht lizenzrechtlich zu beeinflussen. Im Übrigen bedarf es aber in jedem Fall einer urheberrechtlichen Schutzfähigkeit des jeweiligen Codes.
Damit sind auch die beiden Grenzlinien, zwischen denen eine Geltung der GPL bzw. LGPL für Header-Dateien in Betracht kommt, umrissen. Zum einen können solche Dateien unter Umständen auch GPL-abweichend lizenziert werden, soweit es sich um Softwarebestandteile handelt, die ein selbstständiges Modul bilden und als solche eigenständig verbreitet werden können. Ob dies bei dem Code aus den in Rede stehenden Header-Dateien der Fall ist, hängt somit davon ab, inwieweit diese Header-Dateien als Teil eines eigenständigen Programmbestandteils anzusehen und wie diese ihrerseits lizenziert sind. Zum anderen muss es sich aber bei dem relevanten Code in den Header-Dateien überhaupt um ein schutzfähiges Werk im Sinne des Urheberrechts handeln und dementsprechend eine Schöpfungshöhe aufweisen. Dies zeigt sich darin, ob der Code eine gewisse Eigenart besitzt, was zumindest bei der Implementierung schematisch formulierter (Rechen-) Operationen, der Festlegung und Beschreibung von Definitionen oder Parametern zweifelhaft sein dürfte. Bei Inlinefunktionen, die in den Header-Dateien definiert und damit erst beim Kompilieren verlinkt werden, wird es wohl auf den Einzelfall ankommen (vgl dazu: ifross GPL-Kommentar, S. 73 f, Rdnr. 40 ff.).