Licence to kill – Open Source Bibliotheken und Lizenzkontrolle

Die Nutzung von Open Source ist hilfreich bei der Entwicklung von Softwareprodukten. Jeder Entwickler kennt die gängigen Anbieter von Open Source, z.B. die Apache Software Foundation mit sehr vielen Produkten bzw. Libraries oder andere Open Source Plattformen bzw Anbieter. Nicht alles muss eigenständig entwickelt werden, sich bei der Produkterstellung auf das wesentliche zu konzentrieren, ist vernünftig und spart Zeit. Doch Open Source unterliegt meist bestimmten Lizenzen, die den Gebrauch bzw. die Nutzung oder Weitergabe beschränken können. Ein Verstoß dagegen ist rechtlich und ggf. auch finanziell risikoreich.

Achtung vor neuen Lizenzmodellen

An dieser Stelle möchte ich darauf hinweisen, dass manche Lizenzen sich über die Zeit, also bei neuen Versionen ändern können, weil sich die Lizenz-Politik mancher Open Source Anbieter ändert. Erinnern wir uns an die Oracle Lizenz-Umstellung für die Benutzung vom Java Development Kit (JDK) von der Oracle Binary Code License (BCL) auf eine kommerzielle Lizenz für das Oracle JDK. Es gab ein ‚Erdbeben‘ in der Java-Entwicklungslandschaft. Ähnliches kann auch bei verwendeten Open Source Bibliotheken vorkommen und schon wird das einfache Update auf eine neue Bibliotheksversion zum Alptraum.

Lizenzüberwachung als Daueraufgabe

Damit einher geht der Auftrag, die verwendeten Open Source Bibliotheken bzw. dessen Lizenzen kontinuierlich zu überwachen und ggf. Automatismen zu schaffen, die dies idealerweise schon im Build erkennen. An dieser Stelle möchte ich auf das hilfreiches Werkzeug Gradle License Report (natürlich Open Source, Apache 2.0 Lizenz) hinweisen. Dieses Tool ermöglicht es grundsätzlich die verwendeten Bibliotheken zu erkennen, die beinhalteten Lizenzen auszuwerten und als Report zur Verfügung zu stellen.

Beispiel eines Lizenz Reports für eine Softwarekomponente

Dabei löst das Werkzeug typische Probleme bei der Reporterstellung:

• Teils unterschiedliche Benennungen von inhaltlich gleichen Lizenzen können normalisiert werden,
• Die normalisierten Lizenzen können im Report zusammengefasst werden,
• Bestimmte Bibliotheken können bewusst ignoriert werden,
• Der Report kann in unterschiedlichen Formaten (HTML, CSV u. a.) ausgegeben werden.

Vertrauen ist gut – (automatisierte) Kontrolle ist besser

Was ist wichtiger, als nur Transparenz zu schaffen? Die Möglichkeit, alle zu akzeptierenden Lizenzen zu listen und dies automatisiert im Build zu überprüfen. Manuell kann dieser Vorgang schnell umfangreich werden, denn Fremdbibliotheken könnten weitere Abhängigkeiten mitbringen. Abweichungen von der Liste führen im Build einstellbar zum Fehler oder zur Warnung.

Einbindung einer Liste an erlaubten Lizenzen

Die Liste an Lizenzen ist einfach und übersichlich im JSON Format gehalten. Sie kann sowohl zentral vorgehalten werden oder lokal im Dateisystem des Builds abgelegt sein. Dies ist frei konfigurierbar.