GEISTWERT’s Max Mosing hat eine Präsentation zum Thema „Geld verdienen mit Open Source Software – Einführung in Rechtsfragen zu Open Source Software in Österreich“ gegeben. Aus diesem Anlass hat er diese einführende Zusammenfassung der sich aus der (österreichischen) Praxis stellenden Fragen, die sich rund um „Freie Software“ ergeben, verfasst.
Der Begriff Open Source Software wurde „erst“ am 3.2.1998 von der „Open Source Initiative“ eingeführt. Um Open Source Software zu sein, müssen (insbesondere) folgende Kriterien vorliegen:
- Die Lizenz muss die unbeschränkte Weiterverbreitung der Software gestatten. Daher dürfen auch keine Lizenzgebühren für die Nutzung verlangt werden.
- Die Software muss im Source Code vorliegen und darf im Source Code oder in kompilierter Form als Object Code verbreitet werden. Im zweiten Fall muss der Source Code aber zugänglich sein.
- Die Lizenz muss die Veränderung und Weiterentwicklung der Software erlauben. Sie muss die Weiterverbreitung der veränderten Software unter den gleichen Lizenzbedingungen erlauben.
Der letzte Bullet macht eine praktisch essenzielle Unterscheidung bei Open Source Software möglich, nämlich die Modelle des „copyleft“ und des „non-copyleft“:
Manche Open Source Software Lizenzmodelle – prominentestes Beispiel die GNU General Public License (GPL) unter welcher ua LINUX steht – verlangen zwingend die Weiterverbreitung der veränderten Software unter identischer Lizenz. Damit wird, anders als bei non-copyleft – prominentestes Beispiel die Berkeley Software Distribution (BSD) – verhindert, dass geänderte Programme „proprietär“ vertrieben werden können, also „unfrei“ werden. Wenn Open Source Software Lizenzmodelle verlangen, dass veränderte Software zwingend unter der gleichen Lizenz weitervertrieben werden müssen, spricht man von „copyleft“, „viral“ oder „reciprocal“.
Praktisch relevante Rechtsfragen bei Open Source Software
Open Source Software ist international – sowohl Programmierer, Distributoren, Nutzer als auch etwaige Verletzungen. Welches Recht anwendbar ist, ist praktisch bei jeder Fallkonstellation rund um Open Source Software zu prüfen, wobei es auch auf den Sitz der beteiligten Parteien ankommen kann. Dabei kann die Vertragsrechtsanknüpfungen, also insbesondere Fragen rund um Vertragspflichten und Haftungen daraus udgl, und Schutzrechtsanknüpfungen, also Fragen des Urheberrechts, durchaus auseinanderfallen. Das macht die rechtliche Beurteilung natürlich nicht leichter.
Relevant für den Nutzer von Open Source Software ist natürlich die Frage, seiner Rechte an der Software. Open Source Software-Modelle erlauben es grundsätzlich, die Open Source Software (stichwortartig)
- beliebig zu kopieren und zu verbreiten; und
- das Programm oder Teile davon zu bearbeiten und die Bearbeitung zu verbreiten.
- Die Software darf auch als Objekt Code in Embedded-Systems genutzt werden.
Urheberrechtlich erhält der Nutzer somit eine sachlich, zeitlich und örtlich unbeschränkte Werknutzungsbewilligung (§ 24 Urheberrechtsgesetz – UrhG), einschließlich des Bearbeitungsrechts.
Für die Nutzer beschränkend kommen neben obigen Rechten aber auch zahlreiche Pflichten hinzu, wobei sich diese entscheidend unterscheiden, je nachdem, ob ein copyleft- oder ein non-copyleft-Modell vorliegt.
Copyleft am Beispiel GPL
Die GPL (2.0 und 3.0 unterscheiden sich hier zum Teil praxisrelevant) enthält eine Reihe von Pflichten für den Fall, dass die Software weitervertrieben wird. Die Pflichten unterscheiden sich danach, ob der Vertrieb eines veränderten oder eines unveränderten Programms erfolgt.
Stichworte der Pflichten beim Vertrieb unveränderter Software:
- Lizenzgebührenverbot;
- Mitlieferungspflicht des Lizenztextes;
- Zugänglichmachung des Source Code;
- Aufrechterhaltung der Urhebervermerke;
- Aufrechterhaltung des Haftungsausschluss (Disclaimer);
- (grundsätzliches) Verbot von technischen Schutzmaßnahmen
- (grundsätzlicher) Rechtewegfall bei Lizenzverletzung,
Beim Vertrieb veränderter Software unter GPL kommen noch folgende Pflichten stichwortartig hinzu:
- Pflicht zu Änderungsvermerken;
- Aufrechterhaltung und Ergänzung der Anzeige bei interaktiven Kommandos;
- Copyleft! Wer ein Programm verändert, das unter der GPL-2.0 steht, oder in sein Programm GPL-2.0-Code einfügt, oder ein Programm aus einem GPL-2.0-Programm ableitet, der darf das veränderte/ abgeleitete Programm nur unter den Bestimmungen der GPL-2.0 vertreiben. D.h. aber, dass keine Verpflichtung besteht, die veränderten Programme zu vertreiben, „Firmenintere“ Änderungen und Kombinationen mit GPL-2.0 sind daher nicht viral. Sehr wohl aber, sobald ein Vertrieb erfolgt.
Die wohl meist diskutierte Frage im Zusammenhang mit GPL’s copyleft ist, was ein „aus GPL-2.0-Code abgeleitetes Programm“ („derivative work“) ist, weil dieses ausschließlich unter GPL-2.0 vertrieben werden darf. Der Lizenztext selbst versucht zwar Abgrenzungskriterien festzuschreiben, ist dabei aber nur bedingt bestimmt, wenn er negativ abgrenzt: Ein identifizierbarer, nicht abgeleiteter und selbstständig verbreiterter Teil, der vernünftigerweise als eigenständig betrachtet werden kann, ohne Teil eines Ganzen zu sein, ist nach dem Lizenztext der GPL-2.0 nämlich kein abgeleitetes Programm.
Non-copyleft am Beispiel BSD (Berkeley Software Distribution)
Da kein „copyleft“ kann veränderter BSD-Code auch in proprietäre Software übergeführt werden oder unter andere Open Source Lizenzen gestellt werden; für den vorbestehenden BSD-Code gelten aber die unten aufgezählten Pflichten.
Der Schwerpunkt dieses Lizenzmodells liegt in der Einräumung von Nutzungsrechten. Die Lizenzen enthalten daher relativ wenige Pflichten, sodass auch die rechtlichen Probleme durchwegs geringer sind.
Die Rechte des Lizenznehmers werden im Weg der Direktlizenzierung durch die Rechteinhaber eingeräumt. Die Einräumung umfasst ein einfaches unbeschränktes Nutzungsrecht, die Software zu vervielfältigen, zu verbreiten, zu verändern und auch in veränderter Form zu vertreiben.
Folgende Pflichten bestehen beim Weitervertrieb unter BSD:
- Mitverbreitung des Urhebervermerks;
- Mitverbreitung der Lizenzbestimmungen;
- Mitverbreitung der Haftungs- und Gewährleistungsausschlüsse.
Die Mitverbreitung hat bei Object Code Vertrieb in der Dokumentation und/ oder im anderen mitgelieferten Material zu erfolgen.
Das Problem der OSS-Lizenzkombination
Aufgrund der üblich gewordenen modularen Entwicklung unter Nutzung unterschiedlicher Open Source Software (Modelle) kommt in der Praxis dem Problem der fast grundsätzlich bestehenden Inkompatibilität der verschiedenen Lizenzmodelle besondere Bedeutung zu. Es ist im Einzelfall zu prüfen, ob die Open Source Software-Kombination überhaupt lizenzrechtlich genutzt werden darf.
Dual Licensing: Softwareindustrie parallel zu Open Source
Dual Licensing ist insbesondere im Copyleft-Umfeld mit vielen Rechtsfragen behaftet: Die Aufspaltung in einen Copyleft- und einen Proprietär-Zweig geht immer dann, wenn ausschließlich Code in „nullter Vertriebsstufe“ besteht, also in der Regel ausschließlich eigener Code oder eigener Code + non-copyleft. Natürlich darf in der Folge eine Weiterentwicklung, die im Copyleft-Zweig erfolgt, nicht ohne Weiteres in den Proprietär-Zweig einkopiert werden, weil dies im Zweifel viral wäre.