Open Source als Motor der Digitalisierung
Lizenzmanagement ist Pflicht
Kostenaspekte spielen beim Einsatz quelloffener Software immer eine grosse Rolle. Allerdings gilt es dabei zu bedenken, dass Open Source nicht zwingend billiger ist 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.
Drei verschiedene Lizenz-Modelle
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.
Vereinheitlichte Lizenzweitergabe
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.
Ärger rund um MongoDB
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 Verstoss gegen das Open-Source-Prinzip und entfernten die Datenbank aus ihren Repositories. Auch die OSI missbilligte die Lizenzbestimmungen der SSPL.
Open Decision Framework
Fünf Prinzipien vor allem sind es, die für eine Open-Source-Unternehmenskultur wichtig sind.
- Offenheit: Mitarbeiter werden ermutigt, Ideen zu entwickeln und diese mit anderen zu teilen. Der freie Austausch von Meinungen ohne Angst vor Hierarchien oder Nachteilen ist entscheidend für ein offenes Umfeld.
- Zusammenarbeit: Gute Teamarbeit ist ein wesentlicher Faktor, um Probleme leichter zu lösen, neue Ideen zu entwickeln und überkommene Denkweisen zu hinterfragen. Führungskräfte sollten die Kommunikation und Zusammenarbeit in Teams entsprechend fördern.
- Meritokratie: In einer offenen Kultur zählt, was ein Mitarbeiter leistet, nicht auf welcher Hierarchiestufe er steht. Jeder hat Zugang zu denselben Informationen und kann Vorschläge einbringen. Schlussendlich werden die Projekte, umgesetzt, die aus der Gemeinschaft den größten Rückhalt erhalten.
- Gemeinschaft: Menschen unterschiedlichster Erfahrungen und Fachkenntnisse schließen sich zusammen, um an einem gemeinsamen Ziel zu arbeiten.
- Kurze Release-Zyklen: Produkte werden schnell auf den Markt gebracht und häufig aktualisiert. Mitarbeiter können experimentieren und alternative Wege suchen. Wenn etwas nicht funktioniert, wird dies schnell erkannt und geändert.
