Open Source – zwischen Fluch und Segen

 

Frei verfügbare Software für eigene Projekte nutzen und so Zeit und Geld sparen? Eine verlockende Aussicht, etwa für Agenturen, die Entwicklungsleistungen für Ihre Kunden erbringen oder junge Startups, die eine Software zur Produktreife entwickeln wollen. Eine schlechte Planung kann jedoch erhebliche Mehraufwände verursachen oder sogar ein ganzes Projekt zum Scheitern bringen.

Die gute Nachricht: auch Open Source-Software kann in bestimmten Konstellationen kommerziell verwertet werden, einige Open-Source-Lizenzen lassen sogar die Nutzung von Komponenten in proprietärer Software zu. Die schlechte Nachricht: viele Lizenzen verhindern klassische Software-Lizenzierungsmodelle, z.B. indem sie die Beschränkung von Nutzungsrechten verbieten, die Offenlegung des Quellcodes oder die Einräumung von Bearbeitungsrechten verlangen.

Wofür brauche ich die Software?

Will man Open-Source-Komponenten verwenden, gilt die erste Frage dem beabsichtigten Ergebnis. Soll eine proprietäre Software entwickelt werden, die ohne Einschränkung kommerziell verwertet werden kann oder wird auf bestimmte Verwertungsmöglichkeiten verzichtet, weil die Software für den „Eigenbedarf“ beabsichtigt ist oder weil es z.B. unerheblich ist, ob Dritte den Quellcode der Software erhalten?

Die Frage nach dem Ergebnis sollte am Anfang stehen, weil dann effektiv nach Open-Source-Komponenten gesucht werden kann, die die gewünschte Nutzung erlauben. Legt man zuerst mit dem Programmieren los und stellt dann fest, dass die Lizenzen der verwendeten Komponenten die beabsichtigte Nutzung gar nicht ermöglichen, entstehen erhebliche Mehraufwände.

Einige Lizenzen erlauben die Nutzung, Bearbeitung und den Vertrieb von mit ihnen entwickelter Software beinahe ohne Einschränkungen, etwa die MIT- oder BSD-Lizenzen. Andere Lizenzen wiederum – insbesondere solche mit Copyleft-Effekt wie die GPL in ihren verschiedenen Versionen – greifen weitreichend in die Bestimmungshoheit des Entwicklers über die weitere Nutzung seiner Software ein und verhindern so etliche Vertriebsmodelle, da bei mit einem Copyleft belegter Open-Source-Software die bearbeitete Software meist unter den gleichen Bedingungen weitergegeben werden muss.

Gleichzeitig können bestimmte Verwertungsmodelle auch unter Copyleft-Lizenzen möglich sein. So erlaubt z.B. die GPLv3.0 für die Bereitstellung einer Software eine einmalige Vergütung zu erzielen, oder für Dienstleistungen, wie etwa die Wartung der Software, ein Entgelt zu verlangen. Auch wenn eine Software nur unternehmensintern genutzt, aber nicht vertrieben werden soll, kann eine Lizenz mit Copyleft interessant sein, weil sich die Problematik der Veröffentlichung des Quellcodes nur stellt, wenn die Software auch an Dritte verbreitet wird.

Nutzen, Bearbeiten, Vertreiben? Was erlauben die einzelnen Lizenzen?

Ist festgelegt, wie die Software genutzt werden soll, gilt das Augenmerk den Open-Source-Komponenten, die in der geplanten Software verwendet werden sollen. Es ist genau zu prüfen, ob die Lizenzen, unter denen die Open-Source-Komponenten veröffentlicht sind, die geplante Nutzung ermöglichen. Da hier der Teufel im Detail liegt, sollte an dieser Stelle unbedingt ausreichend Planungszeit investiert werden.

Einen Überblick über erlaubte Nutzungen ergibt sich direkt aus den Lizenztexten. Sammlungen von Lizenztexten finden sich z.B. hier

http://opensource.org/, zentrale Seite der Open Source Initiative.

https://www.gnu.org/philosophy/license-list.html, Übersichtsseite, bereitgestellt von der Free Software Foundation.

Viele der Texte und kurze Erläuterungen finden sich auch auf Wikipedia.

Daneben gibt es eine Reihe von Projekten, die es sich zur Aufgabe gemacht haben, die Inhalte der Lizenzen etwas anschaulicher darzustellen, z.B.

http://choosealicense.com/, ein Projekt des Portals Github

http://clipol.org/, ein Projekt der Samuelson-Glushko Canadian Internet Policy and Public Interest Clinic, angebunden an die University of Ottawa)

https://tldrlegal.com/, ein privates Projekt aus den USA.

Mehrere Lizenzen verbinden – Kompatibilitätsprobleme

Etwas komplizierter wird die Situation, wenn für die geplante Software mehrere Open-Source-Komponenten verwendet werden sollen, die unter verschiedenen Lizenzen veröffentlicht sind, weil diese dann miteinander kompatibel sein müssen. Ermöglichen sämtliche Lizenzen die geplante Nutzung der Software? Oder verhindern die Lizenzvorgaben, dass die Komponenten zu einem Arbeitsergebnis verbunden werden? Letzteres ist z.B. der Fall, wenn beide Lizenzen verlangen, dass die genutzten Bestandteile unter derselben Lizenz weitergegeben werden, jedoch das Arbeitsergebnis nur unter eine Lizenz gestellt werden kann.

Die zuvor benannten Seiten beschäftigen sich teilweise ebenfalls mit Kompatibilitätsfragen. Weitere Informationen finden sich auch hier:

http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses

http://opensource.telekom.net/oscad/request, ein Projekt der Telekom, das über verschiedene Fragen zu den erforderlichen Informationen führt.

Kompatibilitätsprobleme überwinden – Workarounds und Split-Lizenzen

Kompatibilitätsprobleme können, aber müssen nicht zum Scheitern eines Software-Projektes führen. Man kann nach alternativen Software-Modulen suchen, welche die gleiche Funktion bieten, aber unter kompatiblen Lizenzen stehen. Teilweise sind Software-Module sogar unter verschiedenen Open-Source-Lizenzen veröffentlicht.

Eine weitere Alternative kann die Erarbeitung von Split-Lizenzen sein. Dieses Modell basiert auf der Idee, die Software in verschiedene trennbare Komponenten aufzuteilen, die jeweils für sich genutzt und deshalb unter verschiedene Lizenzen gestellt werden können. Hier ist auch denkbar, klassische Lizenzmodelle mit Open-Source-Lizenzen zu verbinden. Da es am Ende unter anderem auf die praktische Beantwortung der Frage ankommt, ob die Komponenten wirklich getrennt voneinander sind oder die Trennung nur vorgetäuscht ist, um in den Genuss vorteilhafter Lizenzen zu gelangen, bedarf ist hier ebenso genauer rechtlicher wie technischer Planung bei der Umsetzung.

Open-Source-Software veröffentlichen – Vorsicht vor den Formerfordernissen

Ist die Software programmiert, steht die letzte Hürde an. Viele Open Source Lizenzen machen formelle Vorgaben für die Veröffentlichung von Software, etwa das Beifügen von Lizenztexten oder Dokumentationen. Diese variieren von Lizenz zu Lizenz und sollten ebenfalls sorgfältig geprüft werden.

Eine aktuelle Übersicht über die Anforderungen gängiger Lizenzen findet sich zum Beispiel in einem Kompendium, welches im bereits benannten Telekom-Projekt herausgegeben wurde: http://opensource.telekom.net/oscad/static/pdf/oslic-0.99.3.pdf

Schlussfolgerungen

• Der Einsatz von Open Source Software verhindert nicht zwingend auch eine kommerzielle Verwertung von Software.
• Es können sich aber deutliche Einschränkungen hinsichtlich der Vertriebsmodelle ergeben, so dass (nicht nur aus diesem Grund) von vornherein geplant sein sollte, wie die Software am Ende genutzt werden soll.
• Ist festgelegt, wie die Software genutzt werden soll, ist bei Beschaffung der Open-Source-Bestandteile darauf zu achten, dass diese die geplante Nutzung der Software auch ermöglichen.
• Werden verschiedene Open-Source-Komponenten genutzt, sind Kompatibilitätsfragen zu beachten.
• Ist eine bestimmte kommerzielle Nutzung vorgesehen, sollte genau geplant werden, welche Komponenten genutzt werden, um zu verhindern, dass ganze Projekte rückgängig gemacht und neu aufgesetzt werden müssen.