Einsatz von quelloffenen Komponenten Stücklisten von Open-Source-Lizenzen pflegen

Anbieter zum Thema

msg systems ag

MicroConsult Academy GmbH

emlix GmbH

Welche Bedingungen für den Einsatz von Open-Source-Komponenten gelten, hängt von den zugrundeliegenden Lizenzen ab. Deshalb müssen die Verbauenden in Form einer Stückliste aller Open-Source-Komponenten sicherstellen, dass stets klar ist, wo welche Lizenz zum Einsatz kommt und welche Verpflichtungen sich damit ergeben.

Darum sind Lizenz-Stücklisten relevant

Es gibt zahllose unterschiedliche Open-Source-Lizenzen. Sie sollen die Prinzipien von quelloffener Software auf ein rechtliches Fundament setzen. Obwohl die Gemeinsamkeiten zwischen den Lizenzen groß sind, gibt es dennoch Unterschiede – mitunter nur Nuancen, die allerdings erhebliche Folgen haben können.

Um zwei Beispiele zu nennen: Kommt die Apache-Lizenz 2.0 zum Einsatz, dann müssen Änderungen am Quellcode dokumentiert und die Änderungen in Form einer NOTICE-Datei mitgeliefert werden. Die GPL v3 kann wiederum dazu führen, dass auch das neue Werk unter GPL veröffentlicht werden muss.

Das Problem ist dabei, dass es eine Open-Source-Komponente quasi im Vorbeigehen in ein Produkt schaffen kann. Der Entwickler benötigte eine schnelle Lösung für ein spezifisches Problem? Eine kurze Suche, die Lizenzbedingungen ignoriert, ein einzelner Kommandozeilenbefehl später und schon ist die Open-Source-Komponente integriert. Die transitiven Abhängigkeiten dieser Komponenten führen wiederum dazu, dass zahlreiche Open-Source-Komponenten im Projekt landen, die der Entwickler gar nicht berücksichtigt hat.

Wohl dem, der hier verantwortungsvolle Entwickler beschäftigt, die diesen Schritt absprechen und kommunizieren. Eine Stückliste der verwendeten Komponenten mitsamt den Lizenzen stellt dann die Ausgangsbasis dar, um diesen Umstand aufzudecken, Probleme zu erkennen und Lösungsmaßnahmen zu ergreifen.

Lizenz-Stücklisten erstellen

Die Lizenz-Stückliste lässt sich sowohl manuell als auch automatisiert erstellen. Schlussendlich bleibt allerdings nur eine Kombination aus beiden Maßnahmen übrig. Denn egal wie ausgefeilt der zum Einsatz kommende Automatismus ist: Es existieren einfach zu viele exotische Lizenzen und Sonderfälle, deren Konsequenzen nicht bekannt oder eindeutig sind. Eine gute Strategie besteht deshalb aus einem hohen automatisierten Anteil kombiniert mit den richtigen, manuellen Maßnahmen.

Automatisierte Maßnahmen

Automatisieren lassen sich sämtliche quantitativen Aufgaben. Zu denen gehört es, alle verbauten oder referenzierten Pakete, Quellen und Abhängigkeiten nach Lizenzen zu durchsuchen. Entsprechende Tools existieren bereits in großer Anzahl, etwa Scancode Toolkit.

Wichtig ist, dieses Tool nicht einmal auszuführen, sondern regelmäßig, spätestens vor jeder Auslieferung, idealerweise aber mit jedem erstellten Build oder Deployment. Das Ergebnis einer solchen Prüfung ist in der Regel eine Liste, die eine Übersicht aller Komponenten und Lizenzen bildet. Die verbreitetsten Open-Source-Lizenzen schreiben vor, dass die ursprüngliche Lizenz in abgeleiteten Werken mitgegeben werden muss.

Im nächsten Schritt muss die Liste paketiert und in das abgeleitete Werk integriert werden. Entweder alle Lizenztexte werden im Original beigefügt oder – einfacher und auch bei großen Projekten wie Chrome üblich – als Liste mit Verlinkungen, unter denen sich der Lizenztext nachlesen lässt und das Projekt finden lässt. Die Liste sollte dann alphabetisch nach Komponente sortiert sein.

Manuelle Maßnahmen

Nicht-automatisieren lassen sich hingegen die qualitativen Arbeiten. Hierzu gehört es, die Liste der gefundenen Lizenzen auf Ausreißer oder Exoten zu durchsuchen. Gibt es Exoten, dann müssen diese eingehend fachlich respektive juristisch geprüft werden. Exoten können dabei veraltete oder ungültige Lizenzen sein. Es können auch abgewandelte Lizenzen sein, die eine ganz spezifische Nutzung untersagen oder vorschreiben. Fehlt gar eine Lizenz, dann greift unter Umständen das Urhebergesetz, das je nach Land unterschiedlich geregelt ist.

Spätestens bei solchen Lizenzen sollte die gesamte Komponenten-Architektur überprüft werden. Aus diesem Audit muss klar hervorgehen, ob die Komponente direkt in das erstellte Produkt integriert und somit Bestandteil ist. Oder ob die Komponente lediglich aufgerufen wird. Bei einem bloßen Aufruf entfallen nämlich fast alle Restriktionen, die eine Open-Source-Lizenz normalerweise vorgibt.

Im Zuge des Audits – aber auch unabhängig davon – lassen sich verbaute Komponenten selbstverständlich auch durch solche ersetzen, die eine Lizenz nutzen, die einfacher einzuhalten ist. Das erfordert dann aber wiederum einen Umbau im Projekt, der wiederum zahlreiche weitere Maßnahmen notwendig machen kann.

Eine Frage der Pflege

Kurzum: Lizenz-Stücklisten sind eine Frage der Pflege, bestehend aus automatischen und manuellen Maßnahmen. Die Stückliste der Open-Source-Lizenzen ist kein optionales Element, es ist ein Pflichtbestandteil heutiger Software- und Hardware-Produkte. Denn in nahezu allen Produkten kommen Open-Source-Komponenten zum Einsatz. Nur wer einen klaren Überblick über die Lizenzen hat und sämtliche Konsequenzen kennt, kann guten Gewissens Produkte ausliefern.

Risiken bei Open-Source-Software: Warum eine Bill-of-Materials sinnvoll ist

Akteure, Taktiken und Abwehr von Supply Chain Attacks – Teil 2

Die Verteidigung der Softwarelieferkette

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

(ID:48392622)