Open Source Software

by Tobias Tretzmüller

Aktuelle News, IT-Recht24. Februar 20200 comments

Interessant für: Softwareentwickler, IT-Beschaffung, IT-Projektmanager, Open Source Anwender
In Kürze: Sie kennen den Begriff “Copyleft” und können diesen rechtskonform vermeiden

Was versteht man unter “Copyleft”?

Wer mit Open Source Elementen arbeitet, sollte den Begriff “Copyleft” kennen. Einleitend muss aber das Begriffspaar “Open Source Software” und “proprietäre Software” in Kürze beschrieben werden. Open Source Software ist dadurch charakterisiert, dass der Quellcode der Öffentlichkeit zur Verfügung steht (zB Linux Kernel, Android Betriebssystem). Bei einer proprietären Software hingegen, ist der Quellcode geheim (zB SAP, ALLPLAN, Microsoft 365).

Der Copyleft-Effekt führt dazu, dass die Lizenzbedingungen der Open Source Software auf jene der proprietären Software überspringen (sogenannter “viraler Effekt“). Dieser Effekt ist mit schwerwiegenden Konsequenzen verbunden. Wer nämlich unachtsam Open Source Elemente (zB Bibliotheksdateien oder Frameworks) in die proprietäre Software implementiert, riskiert, dass der gesamte Quellcode offengelegt werden muss.

Wann liegt ein “abgeleitetes Werk” vor?

Die entscheidende Frage ist dabei, wann der Copyleft “greift”. Dies hängt von den jeweiligen Lizenzbedingungen ab. Die GNU GPL Version 2 beispielsweise sieht den Copyleft-Effekt dann als gegeben an, wenn ein von der Open Source Software abgeleitetes Werk (“derivative” bzw “worked based on the program“) vorliegt. Wann dies genau der Fall ist, ist freilich schwierig zu beurteilen. Die folgenden Kriterien können dabei herangezogen werden.

Kriterien zu den Grenzen des Copyleft

Um die Frage zu beantworten, müssen verschiedene Kriterien geprüft werden:

• Formelle Kriterien: Die Ermittlung eines abgeleiteten Werkes mittels formeller Kriterien richtet sich danach, ob eigene Entwicklungen zu einem Open Source-Programm in separaten Dateien ausgelagert wurden;
• Inhaltlich-funktionale Kriterien: Hier steht die Frage im Mittelpunkt, ob die einzelnen Softwareelemente jeweils einen eigenständigen Charakter haben oder nicht. Dabei ist die Komplexität der Software, die Vielfältigkeit der Verwertungsmöglichkeiten und die technische Kombination rechtlicher ungeschützter Werke zu berücksichtigen [Quelle: Suchomski in Schneider, Handbuch EDV-Recht, S 1147];
• Wirtschaftliche Betrachtung: Bei der wirtschaftlichen Betrachtung stellt sich die Frage, ob die einzelnen Softwarekomponenten getrennt wirtschaftlich verwertbar sind.

Fazit und Handlungsempfehlung

Es ist sehr wichtig, dass Softwareentwickler über die “Gefahren” des Copyleft Bescheid wissen. Sofern Open Source Lizenzen mit einem “starken Copyleft” eingesetzt werden (siehe dazu: Übersicht über Open Source Lizenzen), sollte dies nur in Absprache mit einer übergeordneten Instanz (Geschäftsführung, IT-Projektmanager, Compliance-Officer) erfolgen. Ein diesbezüglicher Prozess sollte in den internen Programmierrichtlinien abgebildet werden.

Möglicherweise interessant: Wie ist Open Source konkret umzusetzen?