computerwoche.de

Software-Infrastruktur

Auch Open Source braucht Lizenz-Management

03.04.2008
Von Sven Euteneuer und Frank Simon

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.

Die Zahl der in Sourceforge.net verwalteten Open-Source-Projekte ist in den vergangenen Jahren regelrecht explodiert. Damit steigt allerdings auch die Komplexität in Sachen Lizenzfragen.
Die Zahl der in Sourceforge.net verwalteten Open-Source-Projekte ist in den vergangenen Jahren regelrecht explodiert. Damit steigt allerdings auch die Komplexität in Sachen Lizenzfragen.

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.