Open-Source-Software hat sich in der IT-Branche mehr als etabliert und begegnet uns im Alltag in vielen Facetten. Was bei Weiterentwicklungen dazu rechtlich zu beachten ist.
Ein Gastkommentar von Tobias Tretzmüller.

Schätzungen zufolge besteht proprietäre Standard- und Individualsoftware aus bis zu 98 % Fremdkomponenten. Nach Erhebungen des Scantool-Anbieters Synopsys basiert durchschnittlich über 57 % einer Codebasis auf Open-Source-Software. Die wirtschaftliche und rechtliche Bedeutung von Open-Source-Software ist daher hoch.

Doch was hat es mit dem Copyleft-Effekt auf sich? Diese Klausel soll sicherstellen, dass Weiterentwicklungen der Software unter denselben Bedingungen der Lizenz wieder freigegeben werden. Damit birgt der Copyleft-Effekt ein erhebliches Risiko für die (eigene) proprietäre Software.

Der Copyleft-Effekt ist insofern problematisch, weil regelmäßig der Quellcode der von Open Source Software abgeleiteten Softwareelemente offengelegt werden muss. Die Open-Source-Lizenzbedingungen springen gleichsam auf die proprietäre Software über.

Man spricht in diesem Zusammenhang anschaulich auch vom »viralen Effekt«. Die Open-Source-Software »infiziert« also die proprietäre Software.
Das Heiligtum eines jeden Softwareunternehmens, der Quellcode, muss damit offengelegt werden.

Für Entwickler von proprietärer Software besteht diese Gefahr insbesondere dann, wenn Bibliothek-Dateien (Plugins) auf Basis von Open-Source-Lizenzen in die proprietäre Software integriert werden – was häufig der Fall ist.

»Open-Source- und proprietäre Software sollten keine strukturelle Einheit bilden.« - Tobias Tretzmüller ist Rechtsanwalt mit Schwerpunktthemen IT-Vertragsrecht, Urheberrecht und Lizenzrecht, Datenschutzrecht, IT-Sicherheit und IT-Litigation.


Copyleft ist nicht gleich Copyleft

Je nachdem, wie »aggressiv« der Copyleft-Effekt in den einzelnen Lizenzbestimmungen formuliert wird, wird differenziert zwischen einem »starken Copyleft«, einem (normalen) »Copyleft« und »Permissive Lizenzen«. Dazu zwei Beispiele zur besseren Veranschaulichung.

Die aktuell am weitest verbreitete Lizenz ist die GNU General Public License: »You must cause any work…that in whole or in part contains or is derived from the (open source) program…to be licensed as a whole…under the terms of this license«.

Hingegen sehen die Lizenzen BSD Copyright License und MIT License gar keine diesbezüglichen Verpflichtungen vor (womit sie als Permissive Lizenzen zu qualifizieren sind).
Dies macht die Nutzung lizenzrechtlich deutlich unkomplizierter als bei Copyleft-Software.

Wenn man weiß, dass 57 % des weltweit programmierten Codes auf Open-Source-Lizenzen beruht und die GNU General Public License, Version 2, die am häufigsten eingesetzte Open-Source-Lizenz ist, wird deutlich, welche »Gefahr« Open-Source-Software für proprietäre Software begründet.


»Derived or not derived«

Die springende Frage in diesem Zusammenhang ist, wann liegt eine (von Open-Source-Software) abgeleitete Software »derived work« vor?
Auch wenn Vertreter der Free Software Foundation und mit ihr das LG Berlin davon ausgehen, dass fast jede Art der Verknüpfung von proprietärer Software mit Copyleft-Open-Source-Software einen viralen Effekt auslösen soll, erscheint eine differenzierende Betrachtung geboten. Folgende Prüfungsschritte sind in diesem Zusammenhang zu empfehlen:

- Prüfung anhand formeller Kriterien: Sind die eigenen Entwicklungen von den Open-Source-Code-Elementen separat abgrenzbar? Wird dies bejaht, spricht dies gegen ein abgeleitetes Werk und somit gegen den Copyleft-Effekt.

- Prüfung anhand kommerzieller Kriterien: Wie wird die Software nach außen auf dem Markt vertrieben? Eine »einheitliche« Vermarktung spricht eher für ein »derived work« und somit für den Copyleft-Effekt. Die Eigenständigkeit liegt dann nicht vor, wenn die proprietäre Software mit der Open-Source-Software als »Teil eines Ganzen« verbreitet wird.

- Prüfung anhand funktioneller Kriterien: Sind die einzelnen Elemente jeweils für sich eigenständig nutzbar? Wenn also die proprietäre Software ohne die OS-Elemente nicht genutzt werden kann, spricht dies für ein abgeleitetes Werk und für den Copyleft-Effekt.


Handlungsempfehlung

Zur Vermeidung des viralen Effekts ist es erforderlich, dass die proprietäre Software unabhängig und formal von der OS-Software abgegrenzt werden kann und sowohl OS-Software als auch die proprietäre Software keine strukturelle Einheit bilden.

Auf diese Abgrenzung ist sowohl während der Entwicklung als auch im Vertrieb der Software zu achten. Vertraglich sollte darauf geachtet werden, dass das Softwareunternehmen hinsichtlich der OS-Bibliotheken nicht der direkte Vertragspartner des Kunden wird. In diesem Fall würde das Softwareunternehmen für einen Mangel in den OS-Elementen haften.