Mittlerweile existiert eine fast unüberschaubare Anzahl von Open-Source-Produkten, die für eigene Anwendungen oder als Teil eigener Applikationen verwendet werden können (siehe auch: Die besten Open-Source-Produkte). Viele dieser Systeme bieten ihren Benutzern dabei eine mit kommerziellen Konkurrenten ebenbürtige oder teilweise sogar überlegene Qualität.

Die gestiegene Bekanntheit von Open Source und ein hoher Kosten- und Produktivitätsdruck machen OSS auch im kommerziellen Umfeld attraktiv. Wenn Systeme wie Linux-Server oder Apache-Webserver bereits als eigenständige Produkte ihren Dienst im Unternehmen tun, liegt es nahe, auch bei der Entwicklung oder Weiterentwicklung großer Softwaresysteme Open-Source-Komponenten zu verwenden (siehe auch: Wie Open Source die IT verändert).

Offen, aber nicht immer frei

Allerdings ist Open Source entgegen der landläufigen Auffassung keineswegs frei von Rechten. Zwar fallen für so genannte Copyleft-Produkte tatsächlich keine Lizenzgebühren an, es werden aber implizit andere Forderungen gültig, vor allem, dass jedes Derivat ebenfalls unter die freie Copyleft-Lizenz fällt. Die Definition, was hierunter zu verstehen ist, interpretieren die Anbieter von Lizenz zu Lizenz sehr unterschiedlich. Auch kommerzielle Produkte müssen deshalb - selbst wenn sie solche Software nur verwenden - in vielen Fällen ihren Quellcode offen legen.

Der ungesteuerte Einsatz von Open-Source in großen IT-Projekten ist also mit einem hohen Risiko verbunden. Aus Unternehmenssicht kann dies geschäftskritisch sein, da direkte monetäre Ansprüche beziehungsweise Forderungen nach kompletter Offenlegung des Quelltextes folgen können. Auch die damit verbundenen Imageschäden können den betroffenen Firmen schaden.

License-Compliance-Management bändigt Open Source

Um die Produktivitätsgewinne durch Einsatz fertiger Teilkomponenten aus Open-Source-Quellen dennoch mit vertretbarem Risiko nutzen zu können, ist ein aktives License Compliance Management (LCM) notwendig. Die Ausprägung dieses Managements unterscheidet sich nach Größe und Komplexität der Organisation und des Systems, aber auch nach der konkreten Risikoabwägung.

Für kleinere Organisationen oder Projekte mit einer überschaubaren Komplexität kann die Risikoeinschätzung so ausfallen, dass weder ein formeller LCM-Prozess noch einmalige oder regelmäßige Überprüfungen des Systems als notwendig erachtet werden. Die Entscheidung ein solches Risiko einzugehen, muss aber bewusst und unter Einbeziehung der relevanten Informationen erfolgen. Ein Bewusstsein für die rechtmäßige Verwendung von Open-Source sollte also in jedem Fall vorhanden sein.

Die Einführung eines License-Compliance-Management gliedert sich in vier Phasen:

1. Definition: Zunächst wird die Strategie für das zu prüfende Softwaresystem festgelegt. Diese orientiert sich in der Regel am Verwendungszweck und Einsatzumfeld. Aus der Strategie lassen sich konkrete Regeln zur Verwendung von Open-Source-Komponenten ableiten. Diese Regeln erlauben zum Beispiel bestimmte Komponenten oder ganze OSS-Lizenzen, schließen sie aus oder schreiben eine Prüfung vor ihrer Verwendung vor. Im nächsten Schritt wird der LCM-Prozess dann noch an die konkrete Organisation angepasst und es werden die zuständigen Rollen erzeugt und vergeben.

2. Screening: In einem zweiten Schritt ermitteln die Teams die Zusammensetzung des Softwaresystems. Mit Hilfe spezialisierter Werkzeuge ist es möglich, nicht nur die offenkundige Verwendung von Komponenten, sondern auch das heimliche Kopieren sogar auf der Ebene des Quellcodes zu ermitteln. Hierzu wird üblicherweise die Zusammensetzung des zu prüfenden Systems mit einer Datenbank von Open-Source-Komponenten abgeglichen.

3. Analysis: Liegen die Ergebnisse des Screenings vor, geht es an die Interpretation und Validierung der Befunde. Gegebenenfalls ist ein Abgleich der Befunde mit verschiedenen Open-Source-Komponenten notwendig, insbesondere da auch innerhalb der Open-Source-Gemeinschaft eine rege Wiederverwendung von Komponenten herrscht. Im Anschluss daran werden die Divergenzen zwischen geplanten und aufgefundenen OSS-Komponenten und die Auswirkungen der aufgefundenen Komponenten auf die festgelegte Strategie des Systems geprüft.

4. Control: Mit Hilfe der in der vorangegangenen Phase ermittelten Informationen sind in dieser Phase notwendige kurzfristige Korrekturen und, falls nötig, langfristige Änderungen an Produkt- oder Unternehmensstrategie möglich.

Kontinuierliche Prüfungen mit LCM

Ist ein solches License Compliance Management implementiert, kann ein Unternehmen zur kontinuierlichen Prüfung übergehen. Hierzu überprüft es die Quelltexte des jeweiligen Systems in regelmäßigen Abständen, etwa bei jedem Release. Dieser Prozess kann nahezu vollständig automatisiert ablaufen.

Organisatorisch ist es sinnvoll, eine zentrale Instanz einzurichten, die das License Compliance Management verantwortet. Diese prüft nicht nur die organisationsinternen Systeme, sondern auch die von Outsourcing-Partnern oder anderen externen Zulieferern im Quelltext gelieferte Software. In solchen Vertragsbeziehungen ist es ebenfalls zwingend notwendig, die gelieferten Quellen auf Urheberrechtsverletzungen abzuklopfen.

In den wenigsten Fällen jedoch repräsentiert die volle Implementierung eines solchen Idealprozesses die strategischen Notwendigkeiten eines Unternehmens. Realität ist vielmehr, dass jede Organisation unterschiedlich hohe Risiken eingehen kann, die mit Open-Source-Lizenzen verbunden sind. Diese graduelle Schichtung ist bereits in der Software-Entwicklung verbreitet. So existiert eine Vielzahl von Prozessmodellen, die mit unterschiedlichen Reifegraden arbeiten, beispielsweise CMMI oder (Automotive) SPICE. Auch für die Produktqualität existiert ein Stufenmodell. Die Vorteile sind eine hohe Transparenz über den jeweiligen Stand der Entwicklung und das verbleibende Restrisiko. Darüber hinaus erhält ein Unternehmen ein konkretes Raster, über das es Risiken sukzessive reduzieren kann.

Reifestufen für die Open-Source-Verwendung

Die Messung von Prozessreife entlang eines Stufenmodells ist in der Praxis sehr weit verbreitet und bewährt. Damit bietet es sich auch für das License Compliance Management an. Einem Unternehmen ist es damit möglich, das aktuelle Lizenzrisiko zu bewerten und gleichzeitig die strategische Zielfindung voranzutreiben. Für den Bereich des License Compliance Managements sind folgende fünf Reifegrade sinnvoll:

Unsensibilisiert (Stufe 1): Auf dieser Stufe existiert innerhalb eines Unternehmens kein Bewusstsein dafür, dass OSS nur unter bestimmten Bedingungen in kommerziellen Systemen eingesetzt werden kann. Die Organisation ist sich weder im Fall einer offenen, noch im Fall einer heimlichen Verwendung von Open-Source-Komponenten dieser Tatsache bewusst. Es existiert weder eine Einschätzung über die rechtlichen Auswirkungen der Lizenzen der verwendeten Komponenten, noch eine Beurteilung der Art der Verwendung und ihrer Konsequenzen.

Folgende Verbesserungen empfehlen sich für ein solches Unternehmen:

• Einrichtung von Rollen in betroffenen Projekten, die Buch über freigegebene und verwendete externe Komponenten führen;

• Schulung der Mitarbeiter bezüglich der Verwendung von Open-Source;

• Erfassen aller verwendeten externen Komponenten in betroffenen Projekten

• Erstellen einer Bibliothek freigegebener Komponenten mit ihren Versionen, Bezugsquellen und der Art der Freigabe;

• Abgleich der freigegebenen Komponenten mit den verwendeten Komponenten.

Ungeprüft (Stufe 2): Auf dieser Stufe existiert innerhalb der Projekte ein Bauplan mit den vermeintlich verwendeten Komponenten und ihren Abhängigkeiten. Der Bauplan selbst ist allerdings nicht verifiziert und nicht auf Vollständigkeit geprüft. Es existieren lediglich konzeptuelle Regeln, die die Verwendung externer Komponenten in einigen Softwaresystemen festlegen. Diese Regeln unterliegen jedoch keiner Kontrolle. Ihre Verletzung bleibt also in der Regel ohne Konsequenz. Die Nutzung nicht korrekt verwendeter Komponenten kann nur zufällig entdeckt werden.

Mögliche Verbesserungsmaßnahmen sind:

• Einführung punktueller Prüfprozesse;

• Integration der Prüfungen in die projektspezifischen Vorgehensmodelle;

• Abgleich der durch Prüfung ermittelten Ist-Zustände mit den dokumentierten Soll-Zuständen;

• Falls nötig, Ableitung kurzfristiger und strategischer Maßnahmen zur Wiederherstellung juristisch einwandfreier Verwendung externer Komponenten.

Ad-Hoc geprüft (Stufe 3): Auf dieser Stufe existiert für einzelne Projekte ein geprüfter Bauplan mit den verwendeten Komponenten. Zugleich ist sichergestellt, dass diese gemäß den Lizenzbestimmungen eingesetzt sind. Die Ad-Hoc-Prüfung erfolgt zum Beispiel in von Kunden, Eigentümern oder Stakeholdern geforderten Due-Diligence-Analysen oder bei konkreten Vermutungen. Prüfungen erfolgen aber weder kontinuierlich, noch organisationsweit. Compliance kann also nicht für jeden Zeitpunkt und für jedes zu prüfende System zugesichert werden.

Mögliche Verbesserungsmaßnahmen sind:

• Unternehmensweiter Ausbau der bisher nur punktuell eingesetzten LCM-Prüfinfrastruktur für eine kontinuierliche Prüfung aller zu untersuchenden Softwaresysteme;

• Einbindung der Prüfprozesse in organisationsweite Stan-dardprozesse;

• Schaffung von Rollen und Kompetenzen für die Einhaltung der Regeln.

Kontinuierlich geprüft (Stufe 4): Auf dieser Stufe existiert eine automatisierte Infrastruktur innerhalb eines Unternehmens, die fortwährend die juristische Korrektheit der Art und Weise der Wiederverwendung von OSS sicherstellt. Ein zentrales Management der verwendeten Lizenzen findet jedoch nicht statt. Dadurch geht für die Komponenten, die unter kommerziellen Lizenzen stehen, Effizienz durch potenzielle Über- oder Unterlizenzierung verloren. Eine Rückverfolgung der Komponenten zu den Projekten, die sie verwenden, ist nicht oder nur mit erheblichem Aufwand möglich.

Mögliche Verbesserungsmaßnahmen sind:

• Aufbau eines umfassenden Lizenz-Managements mit LCM als Kernkomponente.

Strategisch geprüft (Stufe 5): Auf dieser Stufe macht es die kontinuierlich verfügbare Transparenz möglich, das Linzenz-Management im Rahmen einer Gesamtstrategie zu steuern. Diese Strategie stellt sicher, dass Software unternehmensweit entsprechend ihrer Lizenz verwendet wird. Dies schließt für Open-Source-Software die Prüfung auf Compliance ein, während für kommerzielle Software vorhandene und verwendete Lizenzen verwaltet und somit eine Unter- beziehungsweise Überlizenzierung vermieden wird.

Lizenz-Management muss organisiert werden

Die ersten Erfahrungen bei der Implementierung systematischen Lizenz-Managements zeigen, dass die Einführung flexibel und schrittweise erfolgen muss. Der LCM-Idealprozess, wie er insbesondere von den Werkzeugherstellern propagiert wird, überfordert die meisten Projekte. So ist alleine die für eine kontinuierliche Prüfung notwendige Werkzeuginfrastruktur mit teilweise erheblichen Kosten verbunden.

Darüber hinaus fehlen in den Unternehmen oft Rollen, die sich des Themas annehmen könnten. Die Qualitätssicherung fokussiert häufig fachliche Aspekte und ist daher - ebenso wie die Fachseite - mit LCM überfordert. Auf technischer Seite könnte diese Rolle durch einen Architekten realisiert werden, aber diese sind in aller Regel aufgrund ihrer Schnittstellenfunktion zur Fachseite meistens bereits überlastet. Die Entwickler selbst haben häufig nicht die nötige Gesamtsicht und können daher LCM nicht flächendeckend einsetzen.

Die Erfahrung dieser Projekte zeigt, dass viele dieser Probleme durch ein Reifestufenmodell deutlich reduziert werden können: Existiert in einer Organisation noch kein Bewusstsein für die rechtmäßige Verwendung von Open Source oder fehlt eine zutreffende Einschätzung der Risiken, genügen oft einführende Schulungen oder Workshops. Sie schaffen das notwendige Basisbewusstsein und befördern ein aktives Management der Risiken.

Während sich der idealtypische LCM-Prozess (Stufe 5) für große und komplexe IT-Landschaften eignet, wünschen sich Kunden mit kompakteren Systemen in der Regel einen kleinen Overhead. Mit einem Reifestufenmodell können sich Unternehmen darauf beschränken, nur ausgewählte Teile des Prozesses zu implementieren, dies aber gezielt. (ba)