try another color:
try another fontsize: 60% 70% 80% 90%
Institut für Rechtsfragen der Freien und Open Source Software

EXPORT_SYMBOL_GPL() vs. EXPORT_SYMBOL() - Oracles Ansatz.

Von: Lisa Käde

Oracle umgeht im Code der unter der CDDL stehenden Software DTrace die Barriere, dass bestimmte Funktionalitäten des unter der GPL v2 stehenden Linux-Kernels nur durch die Funktion EXPORT_SYMBOL_GPL() bereitgestellt werden und so nur für GPLv2-kompatible Module verfügbar sind.

In der Nachricht der Woche vom 04.11.2012 hat Dr. Catharina Maracke bereits die Funktionsweisen der Linux Kernelfunktionen EXPORT_SYMBOL() und EXPORT_SYMBOL_GPL() erklärt. Kurz zusammengefasst: Die Funktionen stellen Kernel-Schnittstellen dar, wobei eine per EXPORT_SYMBOL_GPL() bereitgestellte Funktionalität nur von Kernelmodulen genutzt werden soll, die selber unter mit der GPLv2 kompatiblen Lizenzen veröffentlicht sind. Die Verwendung einer über EXPORT_SYMBOL() bereitgestellten Funktionalität hingegen kann zwar unter Umständen auch zu abgeleiteten Werken führen, kann jedoch rein technisch betrachtet auch von nicht GPL-kompatiblen Modulen genutzt werden. Die Arbeitsweise dieser Funktionen und die in diesem Zusammenhang aufgeworfenen rechtlichen Fragestellungen werden im Kommentar zur GPLv2 ab Seite 71 erläutert.

Oracles Software DTrace, die ursprünglich als Teil von Solaris gedacht war, steht jetzt auch im Rahmen des Unbreakable Linux Projekts in einer Linux-Umgebung als Kernelmodul zur Verfügung. Dazu muss die Software eine Kernelfunktion verwenden, auf die nur von die nur mithilfe von EXPORT_SYMBOL_GPL() eingebunden werden kann. DTrace steht jedoch unter der GPL-inkompatiblen CDDL-Lizenz, kann EXPORT_SYMBOL_GPL() also aufgrund technischer Beschränkungen nicht aufrufen, da die Lizenz im Code angegeben werden muss, und diese Angabe wird dann mit der erforderlichen Angabe abgeglichen - es erfolgt also keine rechtliche Bewertung, sondern lediglich eine technische Überprüfung der Angaben, die dementsprechend einfach umgangen werden kann. Um trotzdem an die Kernel-Funktionalität zu kommen, die von DTrace benötigt wird, ohne die Lizenzangabe anzupassen, hat Oracle eine Umgehung entwickelt:

In Oracles Kernelabstraktionsschicht, die unter der GPL steht und folglich die entsprechende Funktion EXPORT_SYMBOL_GPL() aufrufen kann, hat Oracle eine Funktion integriert, die den benötigten Wert abfragt und ihn dann über EXPORT_SYMBOL() exportiert. Darüber kann das Kernelmodul dann auf den benötigten Wert zugreifen. Kurz: Oracle umgeht den Schutzmechanismus einfach, indem die selbe Funktion unter einem anderen Namen re-exportiert wird.

Ob eine Funktion mit EXPORT_SYMBOL() oder EXPORT_SYMBOL_GPL() bereit gestellt wird, liegt überwiegend im Ermessen des Entwicklers bzw. der entwickelnden Community, und Funktionen können auch im Nachhinein auf Antrag als GPL-Module markiert werden, sodass sie dann nur noch per EXPORT_SYMBOL_GPL() zur Verfügung stehen. Dies zeigt schon die große Unsicherheit, die hier entstehen kann. Folglich ist aber auch nicht sicher, dass per EXPORT_SYMBOL_GPL() exportierte Funktionen in jedem Fall zu einem abgeleiteten Werk führen. Die ausschließliche Verfügbarkeit über den Aufruf durch diese Schnittstelle spiegelt lediglich die subjektive Auffassung des Entwicklers wieder, dass die angebotene Funktion eine so wesentliche Funktionalität bereitstellt, dass das Modul davon abhängig und hochwahrscheinlich ein abgeleitetes Werk ist. Und umgekehrt ist die Tatsache, dass eine Funktionaliät über EXPORT_SYMBOL() verfügbar ist, keine Garantie dafür, dass bei Verwendung kein abgeleitetes Werk ensteht.

Kernelmodule, die nicht (ausschließlich) für den Linux-Kernel entwickelt wurden, sind in der Regel als funktional selbständig anzusehen. (GPL V2 Kommentar, S. 79 ff.) Es ist also nicht auszuschließen, dass DTrace, das ursprünglich für das Unix-basierte System Solaris entwickelt wurde, als funktional selbständiges Modul zu qualifizieren ist. Folglich kann auch nicht ausgeschlossen werden, dass durch die simple Anpassung an die Linux-Umgebung durch die Nutzung der entsprechenden Funktionen kein abgeleitetes Werk entsteht. Dagegen spricht jedoch, dass über EXPORT_SYMBOL_GPL() exportierte Funktionalitäten vom Entwickler als interne, sehr wesentliche Bestandteile betrachtet werden, weshalb eine Abhängigkeit eines Kernel-Moduls von der Verwendung dieser Funktionalität zumindest auf die Unselbständigkeit und damit das Entstehen eines abgeleiteten Werkes hindeutet.

In den Git Repositories von Oracle liegt seit März bereits eine neue Version der Datei vor, in der im Gegensatz zur bisher verwendeten Datei die fragliche, über EXPORT_SYMBOL_GPL() exportierte Funktion nicht mehr verwendet wird. Dafür wird direkt auf eine kernelinterne Funktion zugegriffen. Ob diese Variante rechtlich unbedenklicher ist, bedarf einer weiteren Prüfung, und wann sie endgültig umgesetzt wird, bleibt abzuwarten.

Oracle könnte also mit seiner Lösung ein abgeleitetes Werk geschaffen haben, das rechtswidrig unter einer inkompatiblen Lizenz steht. Endgültige Klarheit kann erst ein gerichtliches Verfahren schaffen.

Siehe dazu auch:
"Oracle continue to circumvent EXPORT_SYMBOL_GPL()" auf dreamwidth.org
"Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()" auf lwn.net