Ohne Open-Source-Komponenten kommt heute kein betriebliches Informationssystem mehr aus. Über 80 Prozent des ausgelieferten Codes generischer und individueller Lösungen ist originär Open Source. Wenn die Entwickler von betrieblichen Informationssystemen zwar alle Lizenzverpflichtungen gegenüber ihren Kunden erfüllen, dies aber nicht auf die Anbieter der darin verbauten Open-Source-Komponenten zutrifft, kann das zu Problemen führen.

Verstoßen die Komponentenanbieter gegen eine Lizenz oder legen gar keine bei, dann sind in der Regel die Entwickler beziehungsweise Lösungsanbieter in der Pflicht, auf diesen Umstand zu reagieren. Es gibt mehrere Handlungsoptionen, um Risiken durch lizenzverletzende Komponenten zu senken.

Open-Source-Lizenzen erklärt

Steht Software oder eine Komponente unter einer Open-Source-Lizenz, dann heißt es weder, dass sie kostenlos noch beliebig einsetzbar ist. Open Source ist stattdessen eine Sammlung von Prinzipien. Open-Source-Lizenzen wiederum sollen diese Prinzipien rechtlich durchsetzen. Dazu räumen sie Rechte ein und erlegen Verpflichtungen auf. Welche Rechte und Verpflichtungen wann gelten, hängt davon ab, welche Open-Source-Lizenz die Anbietenden der Software oder der Softwarekomponente gewählt haben. Drei Lizenzen kommen besonders häufig zum Einsatz:

• die Apache-Lizenz,

• die GPL und

• die MIT-Lizenz.

Alle weisen gewisse Überschneidungen auf, differenzieren sich aber auch. Apache-Lizenz, GPL und MIT-Lizenz verlangen etwa, den vollständigen Lizenztext und den originalen Urheberrechtshinweis bereitzustellen. Sie untersagen Lizenzgebühren für die Verschaffung von Nutzungsrechten. Der Open Source Code darf eingesetzt, verändert und weiterverteilt werden. Gleichzeitig dürfen die Urheber der Open-Source-Komponente oder Open Source Software nicht für resultierende Schäden verantwortlich oder haftbar gemacht werden.

Lesetipp: Programm-Code und der Urheberrechtsschutz

Die Apache-Lizenz sieht zusätzlich vor, dass nichts andeuten darf, die Apache Software Foundation oder die University of California seien an der Entwicklung beteiligt oder anderweitig involviert gewesen. Änderungen am Quellcode müssen zudem in einer NOTICE-Datei dokumentiert sein und mitgeliefert werden.

Die GPL hingegen legt fest, dass wiederverteilte oder modifizierte Werke ebenfalls unter der GPL zu lizensieren sind. Auch der Quellcode muss dann offengelegt werden.

Auch wenn Unternehmen als Entwickler oder Nutznießer allen ihnen auferlegten Verpflichtungen aus der Lizenz nachkommen: Für die Anbieter der eingesetzten Software oder Komponenten gilt das nicht zwangsläufig. Auch sie müssen eventuell Verpflichtungen erfüllen, denen sie wiederum durch den Einsatz von Open Source unterliegen.

Open Source-Lizenzverstoß als Beispielfall

Ob Anbieter einer Open-Source-Komponente oder von Open Source Software selbst ihren Verpflichtungen nachgekommen sind, hängt also von drei Faktoren ab:

1. ihrem Verständnis der verschiedenen Open-Source-Lizenzen,

2. einem Überblick über die zum Einsatz kommenden Lizenzen und

3. ihrer Sorgfaltspflicht.

Folgendes Beispiel zeigt eine mögliche Situation und wie Entwickler von betrieblichen Informationssystemen darauf reagieren können:

Die fiktive Open-Source-Komponente PiCalculator steht unter der GPL in Version 3. Sie basiert selbst auf einer ebenfalls fiktiven Open-Source-Komponente MathLibrary, die unter der Apache-Lizenz steht. Im bereitgestellten Paket von PiCalculator fehlt allerdings die Datei NOTICE, in der alle Änderungen am Quellcode dokumentiert sein müssen. Hierbei handelt es sich um einen Verstoß gegen die Apache-Lizenz.

Die Entwickler eines betrieblichen Informationssystems setzen PiCalculator ein und bei der Prüfung der Lizenzen stellen Sie fest, dass PiCalculator die Lizenzverpflichtungen nicht erfüllt. PiCalculator wird also zu einer lizenzverletzenden Komponente.

Folgende drei Handlungsoptionen stehen den Entwicklern nun zur Auswahl, von denen sie sich für eine entscheiden müssen:

1. Lizenzverletzende Komponente ersetzen

Die naheliegendste Option ist es, dass die Entwickler die lizenzverletzende Komponente PiCalculator entfernen und durch eine andere Komponente ersetzen. In einer gut aufgebauten Architektur sollten solche Komponenten generell einfach zu ersetzen sein. Technisch stellt dies potenziell keine Hürde dar.

Fachlich sieht es anders. Es kann schlichtweg vorkommen, dass es keine Alternativen gibt, die die benötigte Fachlichkeit der lizenzverletzenden Komponente abdecken. Eventuell ist die Komponente auch fachlich zu fest in das betriebliche Informationssystem integriert, um sie herauszulösen. Oder sie muss aufgrund bestimmter anderer Anforderungen zum Einsatz kommen.

2. Lizenzverletzende Komponente akzeptieren

Die lizenzverletzende Komponente lässt sich ignorieren und das potenzielle Risiko akzeptieren. So mag bei der Prüfung zwar aufgefallen sein, dass ein Lizenzverstoß vorliegt. Die Entwickler des betrieblichen Informationssystems kommunizieren diesen Fall aber nicht an ihre Kunden oder lassen es auf einen möglichen Rechtsstreit ankommen.

Lesetipp: Software Audit - So klappts mit der Lizenzprüfung

Allerdings fordern viele Auftraggeber mittlerweile eine Klärung der Lizenzsituation, erwarten eine Auflistung der Lizenzen und legen vertraglich fest, dass die Entwickler des betrieblichen Informationssystems die Haftung übernehmen müssen. Es verbliebe also bei einer Situation, die weder für die Kunden des betrieblichen Informationssystems noch für deren Entwickler im Sinne eines vertrauensvollen Geschäftsverhältnisses zufriedenstellend wäre.

3. Lizenzverletzende Komponente korrigieren

Als dritte Handlungsoption verbleibt eine, die sogar Open-Source-Prinzipien aufgreift und damit im Grunde die für alle Beteiligten Beste darstellt: die lizenzverletzende Komponente korrigieren. Open Source bedeutet schließlich auch offene Zusammenarbeit und offene Kommunikation. Eventuell hat der Anbieter der lizenzverletzenden Komponente schlicht übersehen, dass die Datei LICENSE nicht mitgeliefert wurde. Oder wusste selbst nicht, dass diese Verpflichtung besteht. Ein Hinweis, etwa per E-Mail oder als Issue im verwendeten Versionsverwaltungssystem, kann dann zu einem schnellen, sauberen und nachhaltigen Ergebnis führen.

Muss es schneller gehen, dann ist es auch vollkommen angemessen, dass die Entwickler des betrieblichen Informationssystems die lizenzverletzende Komponente korrigieren und diese Änderungen dann wiederum den Anbietern der Komponente zur Übernahme bereitstellen. Das ergibt ein für alle Betroffenen bereicherndes Ergebnis: sowohl für die Anbieter, die Entwickler, die Kunden aber auch alle Dritten, die auf die lizenzverletzende Komponente bislang zurückgegriffen haben oder noch zugreifen werden. Zudem vermeiden die Entwickler des betrieblichen Informationssystems, dass sie in Zukunft abermals über diese Komponente, mögliche Lizenzverstöße und rechtliche Risiken stolpern.

Lesetipp: Open-Source-Debatte - Wenn Offenzeit nicht mehr zählt

Ersetzen, akzeptieren und korrigieren - das sind die drei Handlungsoptionen, wenn ein Lizenzverstoß seitens eines Anbieters einer Open-Source-Komponente vorliegt. Welche in Betracht zu ziehen ist, hängt sowohl von internen und externen Faktoren als auch von technischen und fachlichen Gegebenheiten ab. Die fairste und nachhaltigste ist Korrigieren. (bw)