Teil 2: FAQ zu GPL und Open-Source-LMS

1. Allgemeine Fragen zur GPL

a) Müssen Änderungen an einer GPL-lizenzierten Software dem ursprünglichen Anbieter zur Verfügung gestellt werden?

Nein. Die GPL enthält keine Pflicht, nach der Änderungen wieder veröffentlicht oder anderen zur Verfügung ­gestellt werden müssen. Sie besagt lediglich, dass wenn Änderungen der GPL-Software veröffentlicht oder ­verbreitet ­werden, dies unter der GPL zu erfolgen hat.

b) Müssen Änderungen an einer GPL-lizenzierten Software der allgemeinen Öffentlichkeit zur Verfügung gestellt werden?

Nein, s. Antwort zu a)

c) Welche Änderungen an GPL-lizenzierter Software werden vom Copyleft erfasst? 

Wird ein GPL-Programm geändert, z. B. umgeschrieben oder weiterentwickelt, greift die Copyleft-Verpflichtung. Dies gilt für jede Art der Umarbeitung oder Bearbeitung. Die geänderte Fassung ist somit ein derivative work und muss, wenn sie wieder in Umlauf gebracht werden soll, unter die GPL gestellt werden. Darüber hinaus können auch Code-Kombinationen das Copyleft auslösen (siehe hierzu unten Teil 1, 3.)

d) Unter welchen Umständen muss ich meine Software unter die GPL stellen, wenn ich Code aus GPL-lizenzierter Software einbinde?

Wird GPL-Code in ein anderes Programm eingebunden, greift das Copyleft nur dann, wenn hierdurch ein ­derivative work (abgeleitetes Werk) entsteht. Dies wird bei der Einbindung von Code-Fragmenten in aller Regel der Fall sein. Dies gilt jedenfalls, soweit der GPL-Code in den anderen Code integriert wird und damit nicht mehr formal getrennt ist. Etwas anderes kann bei der Einbindung als Bibliothek oder über eine Schnittstelle gelten (s. Teil 1, 4.).

e) Unter welchen Umständen muss ich meine Software unter die GPL stellen, wenn ich sie mit einer GPL-lizenzierten Software verbinde?

Eine Verbindung zweier eigenständiger Programme löst an sich den Copyleft-Effekt nicht aus¹⁵. Ob er wirksam wird, hängt aber von der technischen Art und Weise der Verbindung ab. Werden beide Programme auf eine ­Weise verbunden (und gemeinsam vertrieben), dass aus den zwei separate works ein derivative work entsteht, darf das entstehende Ganze nur unter der GPL vertrieben werden. Bei dieser Beurteilung sind formale und inhaltliche Faktoren zu berücksichtigen. Um das Copyleft zu vermeiden, müssen beide Programme formal getrennt gespeichert sein, damit eindeutig ersichtlich ist, welcher Code der GPL untersteht (und das Werk von Dritten darstellt) und welcher nicht. Hierfür kann man beispielsweise sorgen, indem die eigenständigen Programme/Module beim Vertrieb in unterschiedlichen Dateien überlassen werden. Zudem müssen beide Programme inhaltlich voneinander unabhängig sein. Die eigene Software darf kein vom GPL-Programm abgeleitetes Werk sein. Ob dies der Fall ist, muss im Einzelfall beurteilt werden. Die Rechtsliteratur hat Fallgruppen gebildet, die Anhaltspunkte für die Beurteilung bieten (s. Teil 1, 4.).

f) Inwiefern hat die Anbindung einer GPL-lizenzierten Software über eine Schnittstelle an eine andere Software Einfluss darauf, ob ich die andere Software unter die GPL stellen muss?

Die Anbindung einer GPL-Software an ein anderes Programm führt für sich genommen nicht dazu, dass ein ­derivative work entsteht, das nur unter der GPL vertrieben werden darf (s. hierzu Teil 1, 4.).

g) Welche Kriterien können zur Bewertung dienen, ob eine Software, die auf irgendeine Weise an eine GPL-lizenzierte Software angebunden ist, ebenfalls unter die GPL gestellt werden muss?

Inhaltliche und formale Kriterien (s. hierzu die Ausführungen in Teil 1, 3.-4.).

2. Fragen zum Hosting für Kunden

a) Grundkonstellation

Ein Anbieter hostet ein Open-Source-LMS für einen Kunden, das unter der GPL steht. Der Anbieter installiert die Software auf einem Server, der über das Internet erreichbar ist, aber nicht vom Kunden bereitgestellt wird. Der Kunde erhält den Zugriff auf die Oberfläche, nicht jedoch auf den Server selbst. In der Installation sind Patches, Plugins und Skins enthalten.

I. Muss der Anbieter im Sinne der GPL, abgesehen von weiteren vertraglichen Regelungen, dem Kunden den Quellcode der Installation des Open-Source-LMS übergeben? Umfasst dies auch den Code der Patches, Plugins und Skins?

In der Bereitstellung (hosting) eines Servers liegt nach der hier vertretenen – nicht unumstrittenen – Auffassung weder eine Distribution gem. GPLv2 noch eine conveyance nach der GPLv3 der Server-Software (Letzteres ist eindeutig, s. hierzu Teil 1, 2.). Entsprechend gelten die Lizenzpflichten der GPL (und auch der meisten anderen Open-Source-Lizenzen) hier nicht. Der Auftraggeber muss seinem Kunden keinen Quellcode übergeben und auch die anderen Vertriebspflichten nicht einhalten. Anders wäre dies, wenn das Open-Source-LMS unter einer speziellen SaaS-Lizenz (wie der AGPL oder der SSPL) stünde. Solche enthalten besondere Klauseln, nach denen die Lizenzpflichten u. U. auch einzuhalten sind, wenn die Software lediglich als Dienst angeboten, Dritten aber nicht als Kopie überlassen wird. 

II. Kann die Übergabe des Quellcodes eines Plugins oder Patches vertraglich ausgeschlossen werden? Wenn ja, gilt dies auch, wenn das Plugin im Auftrag des Kunden entwickelt wurde?

Nach der hier vertretenen Auffassung muss dem Kunden ohnehin kein Quellcode überlassen werden. Wäre dies aber der Fall, etwa, weil das System nicht nur als Service bereitgestellt, sondern auch als Download überlassen wird, hinge die Pflicht zur Quellcodeüberlassung zunächst davon ab, ob es sich bei dem Plugin/Patch um ein abgeleitetes Werk handelt. Wäre dies der Fall, würde das Copyleft greifen. Versuche, das Copyleft vertraglich zu umgehen, würden zum Erlöschen der Nutzungslizenz aus der GPL führen und gegen das Urheberrecht verstoßen (s. hierzu Teil 1, 5.)

III. Kann die Übergabe des Quellcodes eines Plugins oder Patches vertraglich für einen bestimmten Zeitraum ausgeschlossen werden?

Siehe Antwort zu a) II.

IV. Kann dem Kunden die Veröffentlichung/Verbreitung von Quellcode, insbesondere Plugins, untersagt ­werden?

Handelt es sich um ein Plugin, das Dritte als Open Source Software veröffentlicht haben (also nicht um eine ­eigene Software), würden hierdurch die durch dessen Open-Source-Lizenzen gewährten Freiheiten vertraglich ausgehebelt. Dies mag bei permissiven Lizenzen ohne Copyleft unter Umständen möglich sein. Bei strengen Copyleft-­Lizenzen, v. a. der GPL, läge hierin jedoch ein Lizenzverstoß. Hierdurch würden die Nutzungsrechte ­erlöschen und der Anbieter könnte wegen Urheberrechtsverletzung belangt werden (s. hierzu auch Antwort zu II. und Teil 1, 5.).

V. Muss auf explizite Anfrage, z.B. eines Nutzers der Plattform, der Quellcode veröffentlicht werden?
Gilt dies dann für alle Patches, Plugins und Skins?

Siehe Antwort auf Frage a) I.

VI. Kann der Quellcode der Patches, Plugins oder Skins unter einer anderen Lizenz als der GPL an den ­Kunden weitergegeben werden?

Wenn das Copyleft für diese Komponenten greift, ist das nicht gestattet (s. Antwort zu II.) 

b) Fallvariante 

In einem ähnlichen Szenario gehört der Hosting-Server dem Kunden, wird aber ansonsten analog zum vorherigen Szenario verwaltet.

Auch in der Variante ist die zentrale Frage, ob der Anbieter des Open-Source-LMS dem Kunden die Quellcodes für das System, Patches, Plugins oder Skins überlassen muss. Dies wäre der Fall, wenn deren OS-Lizenzen entsprechende Pflichten enthielten (diese also beispielsweise unter der GPL stünden oder abgeleitete Werke darstellen) und die Installation auf dem Server des Kunden und/oder der Betrieb des Dienstes für den Kunden diese Lizenzpflichten auslösen würde. 

Nach den Ausführungen zum Ausgangsfall (s. o. unter Frage a) I.) liegt in der Bereitstellung einer Software als Dienst (ASP, SaaS) u. E. weder nach der GPLv2 noch der GPLv3 eine Distribution. Entsprechend löst das Hosting für einen Kunden für sich genommen weder eine Pflicht zur Offenlegung von Sourcecode noch andere Vertriebspflichten aus. 

Diese Bewertung würde sich u. U. ändern, wenn der Kunde die Software nicht nur als Dienst nutzen könnte, sondern sie ihm durch deren Installation auf seinem Server überlassen würde. Hierin liegt generell – außer in Sonderfällen– eine Distribution und der Quellcode für das Open-Source-LMS sowie abgeleitete Werke müssen ebenfalls überlassen werden.

Dies könnte wiederum anders zu beurteilen sein, wenn dem Kunden keinerlei Zugriff auf die Installation (also ­die Kopie der Software) ermöglicht wird. Hat nur der Anbieter Zugriff auf die Installation und kann nur er den Server ­administrieren, die Software löschen etc. würde der Kunde nicht anders stehen als wenn ihm die Software lediglich als Dienst vom Anbieter (von dessen Server) zur Verfügung gestellt würde. Er wäre, mit anderen Worten, auch hier darauf beschränkt, die Funktionen der Software als Dienst zu nutzen. 

In diesem Szenario könnte man argumentieren, dass dem Kunden faktisch keine Kopie der Software verschafft wird, da sie im ausschließlichen Herrschaftsbereich des Anbieters verbleibt. Der Umstand, dass die Hardware dem Kunden gehört, mag zwar grundsätzlich relevant sein. Auch in diesem Fall könnte jedoch durch vertragliche Vereinbarungen sowie die dementsprechend ausgestalteten faktischen Zugriffsmöglichkeiten auf die Infrastruktur (Ausgestaltung der Admin-Rechte etc.) sichergestellt werden, dass dem Kunden kein Zugriff auf die Kopie der Software möglich ist. Ob dies der Fall ist, hängt von der konkreten Ausgestaltung des Anbieter-Kunden-Verhältnisses ab. Von Bedeutung wird hierbei z. B. sein, ob die Software nach Ende der Vereinbarung und der Rückgabe des Servers gelöscht wird.

I. Muss der Anbieter im Sinne der GPL, abgesehen von weiteren vertraglichen Regelungen,  dem Kunden den Quellcode der Installation des Open-Source-LMS übergeben? Umfasst dies auch alle Patches, Plugins und Skins?

Das hängt entscheidend von den Vereinbarungen mit dem Kunden ab, siehe einleitende Betrachtung.

II. Kann die Übergabe des Quellcodes eines Plugins oder Patches vertraglich ausgeschlossen werden?
Wenn ja, gilt dies auch, wenn das Plugin im Auftrag des Kunden entwickelt wurde?

Das hängt entscheidend von den Vereinbarungen mit dem Kunden ab, siehe einleitende Betrachtung.
Siehe im Übrigen die Antwort auf Frage a) II. oben.

III. Kann die Übergabe des Quellcodes eines Plugins oder Patches vertraglich für einen bestimmten Zeitraum ausgeschlossen werden?

Das hängt entscheidend von den Vereinbarungen mit dem Kunden ab, siehe einleitende Betrachtung.
Siehe im Übrigen die Antwort auf Frage a) III oben.

IV. Kann dem Kunden die Veröffentlichung/Verbreitung von Quellcode, insbesondere Plugins, untersagt werden?

Das hängt entscheidend von den Vereinbarungen mit dem Kunden ab, siehe einleitende Betrachtung.
Siehe im Übrigen die Antwort auf Frage a) IV. oben.

V. Muss auf explizite Anfrage, z.B. eines Nutzers der Plattform, der Quellcode veröffentlich werden?
Gilt dies dann für alle Patches, Plugins und Skins?

Das hängt entscheidend von den Vereinbarungen mit dem Kunden ab, siehe einleitende Betrachtung.
Siehe im Übrigen die Antwort auf Frage a) I. oben.

VI. Kann der Quellcode der Patches, Plugins oder Skins unter einer anderen Lizenz als der GPL
an den Kunden weitergegeben werden?

Das hängt entscheidend von den Vereinbarungen mit dem Kunden ab, siehe einleitende Betrachtung.
Siehe im Übrigen die Antwort auf Frage a) IV. oben.

3. Fragen zu Plugins

a) Grundfragen

Ein Anbieter erstellt ein Plugin für einen Pluginslot für ein Open-Source-LMS, das unter der GPL steht.

I.  Darf der Anbieter das Plugin an Kunden verkaufen?

Ja. Selbst wenn es als abgeleitetes Werk anzusehen wäre und daher aufgrund des Copylefts der GPL unter der GPL lizenziert werden müsste, dürfte es der Anbieter „verkaufen“. Die GPL untersagt es nicht, Software zu verkaufen (also kostenpflichtig zu überlassen), sondern lediglich für die Nutzung der Software Lizenzgebühren zu verlangen. „Free“ oder „Open“ bedeutet nicht „kostenfrei“, sondern „frei zur Nutzung“. Die Free Software Foundation drückt dieses Grundprinzip wie folgt aus: 

“Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”. We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.”¹⁶

Eine andere Frage ist, ob sich das Copyleft der GPL am Open-Source-LMS auf das Plugin erstreckt und es daher nur unter der GPL vertrieben werden darf. Das wäre der Fall, wenn das Plugin ein vom Open-Source-LMS abgeleitetes Programm (derivative work) wäre. Dies hängt von verschiedenen Faktoren ab. Grundsätzlich wird ein Plugin in der Regel ein eigenständiges Programm sein. Der Umstand allein, dass es dazu dient, einem anderen Programm zusätzliche Funktionen hinzuzufügen, ändert hieran per se nichts. Die konkrete Situation bedarf jedoch einer Einzelfallprüfung anhand der in Teil 1, 3. und 4. beschriebenen inhaltlich-funktionalen und formalen Kriterien.

Folgende Umstände würden dafür sprechen, dass das Plugin nur unter der GPL vertrieben werden darf: 

• • Es wird in einem Executable gemeinsam mit der GPL-Anwendung vertrieben. Wird der Sourcecode ­gemeinsam kompiliert, darf das entstehende Binary insgesamt nur unter der GPL vertrieben werden.
• • Es enthält Code aus der GPL-Anwendung (z. B. ein urheberrechtlich geschütztes Headerfile).
• • Es ist ausschließlich mit einem bestimmten GPL-Programm nutzbar und verfügt nicht über generische Funktionen. Dieser Faktor ist sehr vage und mit großer Vorsicht zu genießen, weil dies für die meisten Programme – abgesehen von Standard-Bibliotheken – zutreffen wird. Daher kann er auch nur unter ­Hinzutreten weiterer Anhaltspunkte zur Erkenntnis beitragen.

Siehe grundsätzlich zu dieser Frage Teil 1, 3.

II. Muss das Plugin öffentlich zur Verfügung gestellt werden?

Nein. Die GPL verpflichtet nicht dazu, Code zu veröffentlichen, auch nicht bei abgeleiteten Werken (s. Teil 1, 1.).

III.  Kann das Plugin unter eine andere Lizenz als GPL gestellt werden? Wenn ja, unter welche, bzw. welche Anforderungen bestehen an die andere Lizenz?

Zunächst ist im Einzelfall zu prüfen, ob es sich bei dem Plugin um ein derivative work handelt (s. Antwort zu ­Frage I.). Sollte dies nicht der Fall sein, kann das Plugin unter jede beliebige Open-Source-Lizenz gestellt oder auch proprietär vertrieben werden. Greift dagegen das Copyleft der GPL, ist ein Vertrieb nur unter der GPL ­zulässig (s. Teil 1, 1.).

IV. Muss der Quellcode des Plugins öffentlich zur Verfügung gestellt werden?

Nein. Selbst wenn das Copyleft der GPL greifen würde, müsste kein Quellcode veröffentlicht werden. Gilt das ­Copyleft, muss jedoch – wenn die Software im Object Code überlassen wird – jedem Empfänger der complete ­corres­ponding machine-readable source code überlassen oder zumindest die Überlassung angeboten werden (s. Ziff.3a GPLv2, 6a GPLv3). 

b) Ergänzungsfragen

Ein Kunde kauft das Plugin zum Einsatz in seiner Installation des Open-Source-LMS.

I. Muss der Quellcode des Plugins dem Kunden zur Verfügung gestellt werden?

Wenn das Copyleft der GPL greift: ja (s. vorstehende Frage). 

II.  Kann die Weitergabe des Plugins vertraglich untersagt werden?

Wenn das Copyleft der GPL greift: nein (s. Teil 1, 5. und Frage 2. a. IV.). Wenn das nicht der Fall ist, ist dies ohne ­Weiteres möglich. 

III.  Kann die Weitergabe des Quellcodes des Plugins vertraglich untersagt werden?

Wenn das Copyleft der GPL greift: nein (vorstehende Frage). Wenn das nicht der Fall ist, ist dies ohne Weiteres ­möglich.

4. Fragen zu Schnittstellen

a) Konstellation 1

Ein Anbieter erstellt ein Programm. Dieses greift über eine im Kern des Open-Source-LMS implementierte Schnittstelle auf dieses zu. Muss das Programm unter der GPL stehen?

Grundsätzlich: Nein. Der Umstand, dass ein Programm über eine Schnittstelle mit einem GPL-Programm kommuniziert, sagt nichts darüber aus, ob es sich um ein abgeleitetes Werk handelt. Handelt es sich um eigenständige Programme, die auch technisch-formal eigenständig vertrieben werden, greift das Copyleft nicht (s. Teil 1, 3. und 4.).

b) Konstellation 2

In einem anderen Fall wird über eine spezifische, für die Anbindung des Programms geschaffene, Schnittstelle auf das Open-Source-LMS zugegriffen. Die spezifische Schnittstelle wurde als Plugin realisiert. Muss das Programm unter GPL stehen?

Siehe Antwort auf Frage a). Wie die Schnittstelle technisch realisiert wurde, ist für die Beurteilung, ob es sich bei dem Programm um ein derivative work des Open-Source-LMS handelt, irrelevant.

c) Weitere Fragen zu beiden Konstellationen

I.  Gilt dies auch für z.B. Apps, die in einem App-Store publiziert werden?

Auch hier gilt das in der Antwort auf Frage 4. a) Gesagte. Auf welchen Marktplätzen die Applikation angeboten wird, ist für die Frage nach der (Un-)Abhängigkeit derselben vom Open-Source-LMS nicht relevant.

II.  Kann die Verbreitung eines Programms, das über eine Schnittstelle auf das Open-Source-LMS zugreift, vertraglich unterbunden werden?

Sofern das Copyleft nicht greift (s. Antwort auf Frage a), ist das unproblematisch. Handelt es sich bei dem Programm um ein abgeleitetes Werk (-> Copyleft), ist das unzulässig (s. Antwort auf Frage 2. a) IV. und Teil 1, 3. und 4.).

III.  Ist die Art der Schnittstelle oder das Wesen der übertragenen Daten für diese Fragen relevant?

Grundsätzlich: Nein.

d) Konstellation 3

In einem dritten Szenario erstellt ein Anbieter ein Programm, welches nicht über eine Schnittstelle mit dem Open-Source-LMS kommuniziert, aber die durch das Open-Source-LMS erzeugte Datenbank verwendet.

I.  Gilt dies als Schnittstelle? Hat diese Art Zugriff Implikationen für die Lizenz des Programms?

Die von einem Open-Source-LMS erzeugten Daten werden vom Copyleft des Systems nicht erfasst. Sie können unter beliebigen Lizenzen veröffentlicht oder als public domain zur Nutzung freigestellt werden. Siehe hierzu Teil 1, 4.). Entsprechend hat das Copyleft des Open-Source-LMS in dieser Konstellation – abstrakt betrachtet – keinen Einfluss auf ein Programm, das lediglich dessen Output-Daten verwendet. 

II.  Wie verhält es sich, wenn das Open-Source-LMS auf Datenbanken anderer Programme zugreift?

Ob und unter welchen Bedingungen die Datenbanken oder darin enthaltene Daten verwendet werden können, wird sich meist aus der hierfür geltenden Lizenz ergeben. Diese ist auf etwaige Beschränkungen bei der Nachnutzung zu untersuchen. Davon abgesehen hat die Nutzung von Daten grundsätzlich keine Auswirkungen auf die Lizenzierung des nutzenden Programms.

5. Fragen zu 3rd Party Software

Ein Anbieter möchte Komponenten anderer Anbieter in seine Erweiterung integrieren. Beispielsweise wird in einem Plugin ein HTML-Editor integriert oder der HTML-Editor soll als Erweiterung im Kern integriert werden.

a) Welche Lizenz muss die Komponente haben, um in einem unter der GPL stehenden Open-Source-LMS ­eingebunden werden zu können? Sind folgende Lizenzen zulässig: MIT-Lizenz, MPL, Apache License, ...?

Zunächst stellt sich hier die Frage, ob die Erweiterung des Anbieters überhaupt Restriktionen aus der Lizenz des Open-Source-LMS unterliegt. Nur in manchen Konstellationen greift beim kombinierten Vertrieb von Software das Copyleft der GPL. Siehe hierzu Teil 1, 3. und die Fragen zu Plugins (3.). 

Handelt es sich bei der Erweiterung um ein abgeleitetes Werk, darf sie insgesamt (einschließlich der Fremdkomponenten) nur unter der GPL vertrieben werden. Hier gilt Folgendes: Bilden die Fremdkomponenten mit der Erweiterung eine Einheit, dürfen sie nur integriert werden, wenn sie unter einer mit der GPL kompatiblen Lizenz stehen. Die Kombination muss dann beim Vertrieb unter die GPL gestellt werden (s. zur Lizenzkompatibilität Teil 1, 5.).

Zu beachten ist v. a., dass die Lizenzkompatibilität immer anhand konkreter Lizenzversionen untersucht werden muss. So ist beispielsweise (nach Auffassung der FSF) die Apache Public License in Version 2 (APL 2.0) mit der GPLv3 kompatibel, nicht aber mit der GPLv2. Einzelheiten zur Kompatibilität mit den GNU-Lizenzen finden sich auf den Hilfeseiten der FSF: https://www.gnu.org/licenses/license-list.html.en#Introduction. 

b) Wie wirkt sich dies auf die Lizenz des Plugins aus?

Siehe die Antwort zu a). Wenn der Vertrieb des Plugins unter das Copyleft der GPL fällt, muss es entsprechend ­lizenziert werden. 

6. Fragen zu 3rd Party Services

Ein Anbieter greift in einem von ihm erstellten Plugin auf eine Schnittstelle eines weiteren Programms zu (z.B. ­Google Maps).

a) Darf vom Anbieter bereitgestellter Code (z. B. zur Implementierung der Schnittstelle) unter die GPL gestellt werden?

Solange der Anbieter nicht den Code des anderen Programms verwendet, ist das generell unproblematisch.
Der Anbieter kann grundsätzlich mit seinem eigenen Code „machen, was er will“.

b) Darf das Plugin weiterhin unter GPL stehen?

Siehe die Antwort zu 6. a).

Fußnoten:

(15) S. Ziff. 2 letzter Absatz der GPLv2: „In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.”

(16)  https://www.gnu.org/philosophy/free-sw.html.en.