Einhaltung von Lizenzbestimmungen Oft vernachlässigte Risikoquelle: Open-Source-Lizenzen

Von Bernhard Lück Lesedauer: 5 min

Anbieter zum Thema

Schwachstellen in Open-Source-Code sorgen immer wieder für Schlagzeilen, z.B. Heartbleed und Log4Shell. Ein anderes Open-Source-Risiko bleibt oft unbemerkt – die Nichteinhaltung von Lizenzen. Palo Alto Networks beleuchtet die Hintergründe und gibt Tipps zur Risikominimierung.

Auch wenn der Quellcode für die ganze Welt offen ist, ist Open-Source-Code nicht frei von Nutzungsbeschränkungen.
Auch wenn der Quellcode für die ganze Welt offen ist, ist Open-Source-Code nicht frei von Nutzungsbeschränkungen.
(Bild: © – cacaroot – stock.adobe.com)

Open-Source-Softwarelizenzen stellen eine große Risikoquelle dar, da schon eine einzige nicht konforme Lizenz in der Software zu rechtlichen Schritten, zeitaufwendigen Abhilfemaßnahmen und Verzögerungen bei der Markteinführung eines Produkts führen kann.

Trotz des offensichtlichen Risikos ist die Einhaltung von Lizenzbestimmungen kein leichtes Unterfangen. Die Vielfalt der Open-Source-Lizenzen und das Problem festzustellen, welche Lizenzen für eine Software gelten, machen es schwierig, den Überblick zu behalten, um Lizenzen zu verstehen und zu verwalten.

Wie bei der Suche nach hochgradigen oder kritischen Schwachstellen müssen Unternehmen auch bei der Suche nach nicht konformen Lizenzen das Netz der Open-Source- und transitiven Abhängigkeiten entwirren, das häufig mehr als vier oder fünf Ebenen tief reicht. Diese Abhängigkeiten führen oft zu mehreren Versionen desselben Open-Source-Pakets, und es ist nicht ungewöhnlich, dass man in diesem Netz versteckt übermäßig restriktive Copyleft-Lizenzen findet.

Um sicherzustellen, dass Lizenzen konform sind, müssen Unternehmen eine fortschrittliche, kontextbezogene Analyse der Softwarezusammensetzung nutzen. Damit gelingt es, die nicht konformen Lizenzen, die das Unternehmen bedrohen, zu identifizieren, erkennen und priorisieren.

Eine Einführung in Open-Source-Lizenzen

Wenn Benutzer den Begriff „Open Source“ hören, gehen sie leicht davon aus, dass sie dieses Paket nach Belieben verwenden können, z.B. indem sie es für die Entwicklung eines kommerziellen Produkts nutzen. Aber auch wenn der Quellcode für die ganze Welt offen ist, ist Open-Source-Code nicht frei von Nutzungsbeschränkungen.

Für Open-Source-Pakete gibt es Lizenzen, die die Verwendung, Wiederverwendung, gemeinsame Nutzung, Änderung und Verteilung des Codes regeln. Hunderte von verschiedenen Open-Source-Lizenzen schreiben vor, wie Benutzer Open-Source-Code verwenden können, und die Strafe für die Nichteinhaltung ist real. Wenn ein Unternehmen ein Open-Source-Paket nutzt und die Lizenz nicht einhält, könnte es gezwungen sein, seinen proprietären Code als Open Source zu veröffentlichen oder den kostspieligen und zeitaufwendigen Prozess des Entfernens und Ersetzens des nicht konformen Pakets in der gesamten Codebasis zu durchlaufen.

Woher wissen also Verantwortliche, welche spezifischen Anforderungen sie erfüllen müssen, um konform zu bleiben? Hier wird es knifflig, da die Anforderungen je nach Lizenz sehr unterschiedlich sind. Einige Lizenzen – z.B. Copyleft – sind sehr restriktiv. Andere wiederum sind kostenpflichtig, und wieder andere sind bei korrekter Namensnennung frei verwendbar. Im Allgemeinen lassen sich Open-Source-Lizenzen jedoch in zwei Hauptkategorien einteilen: Copyleft und permissive Lizenzen:

  • 1. Copyleft-Lizenzen sind sehr restriktiv. Sie verlangen, dass Unternehmen jeden Code, der die betreffende Open-Source-Software nutzt, als Open Source zur Verfügung stellt. Diese Lizenzen verlangen außerdem, dass Unternehmen die Quellcode-Dateien ihrer Software weitergeben, die in der Regel eine Kopie der Lizenzbedingungen enthalten und die Autoren des Codes anerkennen. Die bekannteste Copyleft-Lizenz ist die GNU General Public License (GPL).
  • 2. Permissive Lizenzen enthalten nur minimale Einschränkungen, wie die Software verwendet, verändert und weitergegeben werden darf. Diese Lizenzen enthalten in der Regel einen Gewährleistungsausschluss. Einige Beispiele für permissive Lizenzen sind die GNU All-permissive License, MIT License, BSD-Lizenzen, Apple Public Source License und Apache License. Im Jahr 2016 ist die beliebteste Lizenz für freie Software die permissive MIT-Lizenz. Ein bemerkenswertes und erfolgreiches Open-Source-Softwarepaket, das die Apache-Lizenz verwendet, ist Kubernetes.

Eine Fallstudie zur Nichteinhaltung von Copyleft-Lizenzen

Im Jahr 2008 verklagte die Free Software Foundation (FSF) Cisco wegen des Verkaufs von Software der Marke LinkSys, die nicht mit dem verwendeten Open-Source-Code konform war. Wie so oft wurde die nicht konforme Software, die eine GPL-Urheberrechtsverletzung verursachte, im Zuge einer Übernahme in die Software von Cisco integriert.

Angesichts der allgegenwärtigen Open-Source-Software, der Zunahme von Übernahmen und der Tiefe der Abhängigkeitsstrukturen wird es immer schwieriger, Open-Source-Lizenzen zu identifizieren, die tief in den kommerziellen Softwareangeboten verankert sind. Die Nichteinhaltung kann jedoch die Bemühungen um die Geheimhaltung von kommerziellem, geistigem Eigentum zunichtemachen. So kann ein Unternehmen, das eine Lizenz nicht einhält, gezwungen werden, seine Software als Open Source zu veröffentlichen oder den Verkauf dieser Software einzustellen. Und selbst wenn eine Lizenz nicht so restriktiv ist wie eine Copyleft-Lizenz, kann es sein, dass Teams ihre Software neu entwickeln müssen, um eine wichtige Abhängigkeit zu lösen, was kostspielig ist und die Geschwindigkeit der Veröffentlichung dämpft.

Sich entwickelnde Risiken und kontinuierliche Überwachung der Lizenzkonformität

Als ob es nicht schon kompliziert genug wäre, alle Lizenzen zu identifizieren, kann sich eine Open-Source-Lizenz auch noch jeden Moment ändern. So wurde beispielsweise das weitverbreitete Open-Source-Paket Elasticsearch im Jahr 2021 von einer ehemals permissiven Lizenz auf eine restriktivere umgestellt. Die Überprüfung der Lizenzkonformität ist keine einmalige Angelegenheit. Stattdessen erfordert das Konformitätsmanagement einen kontinuierlichen Ansatz, der die gleiche Sorgfalt voraussetzt wie andere Open-Source-Sicherheitsprozesse, z.B. die Aktualisierung von Drittanbieterpaketen auf neuere und sicherere Versionen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Entwicklung einer umfassenden Open-Source-Management-Strategie

Auf den ersten Blick mag die Einhaltung von Open-Source-Lizenzen einfach erscheinen. In Wirklichkeit ist sie jedoch so komplex wie die Natur von Open Source selbst. Und die traurige Wahrheit ist: Selbst, wenn die bestehende Open-Source-Sicherheitsstrategie eine gründliche Überprüfung von Abhängigkeiten und Prozesse zur Verwaltung von Schwachstellen beinhaltet, bleiben möglicherweise immer noch erhebliche Open-Source-Risiken, die Unternehmen nicht angehen. Nur ein einziges nicht konformes Paket reicht, um eine gesamte Anwendung nicht konform mit den Lizenzanforderungen zu machen. Unternehmen müssen daher eine proaktive und umfassende Open-Source-Sicherheitsstrategie integrieren, um ihre Lieferkette angemessen zu schützen.

Durch einen proaktiven Ansatz, der Open-Source-Lizenzprobleme frühzeitig im Entwicklungszyklus identifiziert und behebt, können Unternehmen die Produktivität der Entwickler steigern. Gleichzeitig können sie den Stress verringern, der entsteht, wenn sie später im Entwicklungszyklus nicht konforme Pakete aus ihrer Software herausnehmen und ersetzen müssen.

Die Einführung umfassender Open-Source-Sicherheit kann entmutigend erscheinen, aber sie ist machbar. Wenn man es richtig angeht, kann es sogar entwicklerfreundlich sein. Durch die Integration von Open-Source-Tools wie Checkov in IDEs wie VSCode und PyCharm von Jetbrains können Anwendungsentwickler und DevOps-Teams so früh wie möglich im Entwicklungszyklus Einblicke in Schwachstellen und potenzielle Probleme mit der Lizenzkonformität erhalten. Auf diese Weise können sie proaktiv Probleme mit nicht konformen Paketen beheben und die Geschwindigkeit ihrer Veröffentlichungen aufrechterhalten.

(ID:49219948)