Open Source als Motor der Digitalisierung
Lizenzmanagement ist Pflicht
von Thomas Hafen - 10.02.2020
Auch wenn Unternehmen beim Einsatz quelloffener Software vornehmlich Kostenaspekte im Blick haben, ist Open Source nicht zwingend billiger als proprietäre Lösungen. Zwar lassen sich die Programme oft zumindest in einer Basisversion ohne Lizenzkosten nutzen, Installation, Konfiguration und Verwaltung können aber erhebliches Know-how erfordern und hohe Personalkosten nach sich ziehen.
Es darf auch nicht vergessen werden, dass der Begriff Open Source nicht rechtlich geschützt ist. Häufig ist zudem nur der Kern eines Systems Open Source, während für den Unternehmenseinsatz wichtige Erweiterungen oder Plug-ins kostenpflichtig lizenziert werden müssen. Unternehmen sollten daher darauf achten, dass die Lizenz einer Open-Source-Software von der FSF oder der Open Source Initiative (OSI) zertifiziert wurde, und welche Leistungen tatsächlich enthalten ist.
Bei den Lizenzen lassen sich prinzipiell drei Modelle unterscheiden: „starke“ Copyleft-Lizenzen, „schwache“ Copyleft-Lizenzen sowie permissive Lizenzen. Starke Copyleft-Lizenzen, wie die GNU General Public License (GNU GPL) und die Affero General Public License (AGPL), verlangen, dass Produkte, die die so lizenzierte Software enthalten, unter denselben Bedingungen lizenziert werden müssen. Entwickeln Unternehmen auf dieser Basis Software, müssen sie deren Quellcode der Allgemeinheit zur Verfügung stellen und damit gegebenenfalls Alleinstellungsmerkmale und geistiges Eigentum aufgeben.
Schwache Copyleft-Lizenzen wie die GNU Lesser General Public License (LGPL) erlauben die Nutzung quelloffener Software in proprietären Produkten, sofern diese Bestandteile weiterhin als Open Source zur Verfügung stehen.
Lösungen unter LGPL nutzen meist dynamische Software-Bibliotheken zur Einbindung der Open-Source-Bestandteile, um eine Trennung von offenen und geschlossenen Programmbereichen zu gewährleisten.
Wie der Name schon andeutet, sind permissive Lizenzen, zu denen beispielsweise die Apache License (APL), die BSD License (BSDL) oder die MIT License gehören, wesentlich weniger streng. Entwickler dürfen im Prinzip mit dem quelloffenen Code machen, was sie wollen, so lange sie sich nicht als dessen Autor ausgeben.
Der kollaborative Charakter von Open-Source-Projekten bringt es mit sich, dass Produkte oft aus zahlreichen Komponenten bestehen. Deren jeweilige Lizenzbedingungen und Urheber müssen bei der Weiterentwicklung und Weitergabe in einer für Menschen lesbaren Form dokumentiert werden. Die Linux Foundation hat dazu das Format SPDX (Software Data Package Exchange) entwickelt, das die Lizenzweitergabe vereinheitlichen und erleichtern soll.
Mit dem „REUSE“-Tool der FSFE lässt sich überprüfen, ob alle Komponenten in einem Projekt korrekt lizenziert und alle Compliance-Vorgaben eingehalten wurden (https://reuse.software). Weitere Tools zur Lizenzüberprüfung quelloffener Software sind beispielsweise FOSSology und Ninka.
Unternehmen sollten OSS-Lizenzen genauso zentral verwalten wie alle anderen Software-Verträge. Vor dem Einsatz einer Open-Source-Software ist genau zu prüfen, welche Lizenzbedingungen mit ihr verbunden sind und welche Konsequenzen die Nutzung und Weiterentwicklung für selbst entwickelte Software-Produkte hat. Das ist alles andere als trivial, denn die Lizenzwerke sind umfangreich und ihre Interpretation oft umstritten.
Wohin der Lizenzwirrwarr führen kann, veranschaulicht sehr schön das Beispiel der quelloffenen NoSQL-Datenbank MongoDB, die sich mit ihrer Server Side Public License (SSPL) Ende 2018 erheblichen Ärger in der Open-Source-Community einhandelte. Der Hersteller wollte sich mit der SSPL eigentlich nur gegen die in seinen Augen unseriöse Praxis einiger Cloud-Provider wehren, die mit Datenbank-Services auf Basis der kostenlosen MongoDB-Version gute Geschäfte machten, ohne etwas an die Gemeinschaft zurückzugeben. Sie sollten nach den Bestimmungen der SSPL den kompletten Service-Code als Open Source zur Verfügung stellen müssen.
Linux-Distributionen wie Debian und Red Hat Enterprise Linux (RHEL) sahen darin jedoch einen Verstoß gegen das Open-Source-Prinzip und entfernten die Datenbank aus ihren Repositories. Auch die OSI missbilligte die Lizenzbestimmungen der SSPL.
In deutschen Unternehmen ist die oft unklare rechtliche Situation einer der meistgenannten Gründe gegen OSS. Mit 41 Prozent liegt sie nach fehlenden personellen Ressourcen (59 Prozent) und strategischen Erwägungen (58 Prozent) auf Platz drei der Nennungen. Juristische Auseinandersetzungen sind allerdings die Ausnahme. Nur 3 Prozent der Befragten waren schon einmal von rechtlichen Schritten betroffen, weitere 3 Prozent haben selbst rechtliche Schritte gegen andere Unternehmen eingeleitet.