Open-Source-Software zeichnet sich im Wesentlichen durch folgende Merkmale aus:
- Eine unbeschränkte und kostenlose Weiterverbreitung der Software ist zulässig;
- Die Software liegt im Quellcode vor;
- Veränderungen der Software und deren Weiterverbreitung unter derselben Lizenz sind grundsätzlich zulässig;
- Die Nutzung der Software untersteht je nach OSS-Lizenz unterschiedlichen Bedingungen.
Der entscheidende Unterschied zu Closed-Source-Software besteht in der umfassenden Einräumung urheberrechtlicher Nutzungsrechte am Quellcode, die das freie Kopieren, Bearbeiten, Untersuchen und Verbreiten der Software ermöglichen.
Gemäss einigen üblicherweise verwendeten OSS-Lizenzen, z.B. der GNU General Public License Version 3 (GPL-3.0)1, müssen Nutzende des Software-Sourcecodes Änderungen an diesem wieder unter denselben Bedingungen anbieten, wie diese für den ursprünglichen Code bestanden (sogenannter «Copyleft» Effekt). Wer m.a.W. beispielsweise GPL-lizenzierte Software selber verändert und den veränderten Code Dritten anbietet, ist verpflichtet, diesen Dritten den veränderten Quellcode wiederum unter der jeweiligen GPL-Lizenz anzubieten. Dabei dürfen dem Dritten keine Restriktionen auferlegt werden2, die über die bestehenden Restriktionen der GPL hinaus gehen.3
Der «virale» Copyleft-Effekt hindert Rechteinhaber an proprietärer Software daran, ein abgeleitetes Werk der OSS in eigene proprietäre Software zu integrieren, da der gesamte Code unter der gleichen Lizenz veröffentlicht werden müsste.4
Das Copyleft wird ausgelöst, wenn die Software «conveyed», d.h. in einer Art und Weise weitergegeben wurde, die es anderen Parteien ermöglicht, Kopien zu erstellen oder zu erhalten.5
Nun stellt sich die Frage, ob eine Weitergabe zwischen Konzerngesellschaften ebenfalls als Weitergabe in diesem Sinn zu verstehen ist und damit das Copyleft auslöst.
Während Konzerngesellschaften wirtschaftlich unter derselben Kontrolle stehen und von der Konzernmutter abhängig sind, sind sie aus rechtlicher Sicht unabhängig. Die Literatur sieht diese rechtliche Unabhängigkeit als Grund dafür, die Weitergabe von unter einer Copyleft-Lizenz stehendem Code an eine Konzerngesellschaft als Auslöser für das Copyleft anzusehen.6
Konzernunternehmen erhalten Open Source Software vielfach nicht im Rahmen eines einheitlichen Vertriebsvorganges, sondern im Rahmen der Softwareentwicklung. Das Konzernunternehmen benötigt als rechtlich unabhängige Einheit jedenfalls ein eigenes Nutzungsrecht für die weitere Bearbeitung, so dass nicht ersichtlich wäre, warum die Weitergabe an eine Konzerngesellschaft von der Erfüllung der übrigen Lizenzpflichten zum Copyleft ausgeschlossen sein sollte.7 Überdies dient das Tatbestandsmerkmal «an die Öffentlichkeit» zur Abgrenzung von der privaten Weitergabe, die bei der Weitergabe innerhalb des Konzerns nicht betroffen ist. Es ist daher davon auszugehen, dass die Weitergabe an eine andere Konzerngesellschaft das Copyleft auslöst.8
Die nächste Frage ist, ob es zulässig bleibt, den Konzerntochterunternehmen durch konzerninterne Weisung zu verbieten, GPL-lizenzierte Software weiterzuverbreiten. Gemäss der anwendbaren GPL ist ihnen dies nicht erlaubt, denn über die GPL hinausgehende Restriktionen bezüglich der Weiterverbreitung sind wie gesagt unzulässig. Nach der hier vertretenen Meinung kann es nicht darauf ankommen, ob eine Restriktion formell in einem Lizenzvertrag oder in einem anderen – rechtlich verbindlichen – Dokument zu finden ist (eine konzerninterne Weisung dürfte in der Regel eine auftrags- und/oder gesellschaftsrechtlich verbindliche Weisung an die Organe der Tochtergesellschaft sein).
Abwägend stellt die hinter den GPL-Lizenzen stehende Free Software Foundation dies in den FAQ zur GPL dar. Allerdings ist zweifelhaft, ob diese FAQ, die nicht Bestandteil der Lizenzbestimmungen sind, bei einer Auslegung der Lizenzen wirklich von Bedeutung sein können. Dies wird nur dann der Fall sein, wenn die FAQ der allgemeinen Branchenauffassung entsprechen. Nachdem die Frage der konzerninternen Lizenzierung bislang soweit ersichtlich nicht Gegenstand erheblicher Auseinandersetzungen war, bleibt dies zumindest unklar. Damit besteht das Risiko, dass damit die – objektive – Auslegung der Lizenzbestimmungen gemäss Lizenztext zur Anwendung kommt, die nicht auf die Sondersituation im Konzern eingeht.
Zusammenfassend ist also bei einer Verwendung von GPL-lizenziertem Code im Konzern insofern Vorsicht geboten, als eine Weisung, die Software nicht konzernextern weiterzugeben, lizenzverletzend sein könnte.
- 1 Open Source Initiative, GPL-3.0, tinyurl.com/ycksdafs.
- 2 Siehe hierzu jedoch die Möglichkeit einer Ausnahme im «Linking Exceptions under OSS Licenses» von Daniel Ronzani.
- 3 Vgl. GPLv3, Abschnitte 7 und 10.
- 4 T. Jaeger/A. Metzger, Open Source Software, 5. A. 2020, N 45 f.; zum Ganzen bereits D. Ronzani, SaaS under GPLv3, TechLawNews 7 | November 2015.
- 5 GPLv3, Abschnitt 0.
- 6 Zum Ganzen insbesondere das «Standardwerk» von Jaeger/Metzger (FN 4), N 53, 169, m.H.; vorsichtig ist auch die Free Software Foundation in ihren FAQ, die auf das anwendbare Vertragsstatut verweist, http://www.gnu.org/licenses/gpl-faq.html#DistributeSubsidiary.
- 7 Jaeger/Metzger (FN 4), N 169.
- 8 So auch Jaeger/Metzger, a.a.O.; vorsichtig ist auch die Free Software Foundation in ihren FAQ, http://www.gnu.org/licenses/gpl-faq.html#DistributeSubsidiary.