Compliance in der Cloud Das SaaS-Schlupfloch in der GNU GPL

Anbieter zum Thema

Windhoff Group

Hebt ein Software-Anbieter seine Lösungen in die Cloud hebt, verändert sich nicht nur das Bereitstellungsmodell. Im Zweifelsfall gelten auch andere Richtlinien bei der Nutzung von Open-Source-Software-, kurz OSS-Komponenten. Das betrifft zum Beispiel SaaS und die GNU General Public License (GNU GPL).

Die Frage, wie die freie Nutzung von OSS auch innerhalb neuer Anwendungsszenarien sichergestellt bleibt, beschäftigt die Open Source Community schon länger. Gerade in Hinblick auf die Cloud wurde viel über mögliche Regelungslücken in bestehenden Copyleft-Lizenzen diskutiert.

Nach glasklaren Bestimmungen in Lizenztexten sucht man vergeblich. Das liegt zum einen daran, dass die Cloud zum Zeitpunkt des Verfassens schlichtweg noch keine Rolle spielte. Zum anderen knüpft die Offenlegung des Quellcodes in OSS-Lizenzen an die sogenannte „Distribution“ an.

In den englischen Originalfassungen ist dieser Begriff nicht näher definiert und ermöglicht je nach Übersetzung unterschiedliche Interpretationsweisen. Typischerweise ist damit die Übergabe des Objektcodes an den Kunden gemeint. Beim Cloud Computing läuft der Code jedoch nicht auf den Rechnern der Nutzer ab, sondern auf den Servern des Cloud-Anbieters.

Was ist die GNU General Public License?

Können also Unternehmen, die eine Software hosten bzw. diese als Application Service Provider (ASP) anbieten, entsprechende Lizenzbestimmungen umgehen? Hier lohnt sich ein genauer Blick auf die jeweiligen Bestimmungen der GNU General Public License (kurz GNU GPL).

Die GPL ist eine Open-Source-Software-Lizenz, die es Entwicklerinnen und Entwicklern erlaubt, Quellcode zu nutzen, zu kopieren, zu verbreiten und zu ändern – auch für kommerzielle Produkte. Diese weitreichenden Rechte sind allerdings an Verpflichtungen geknüpft, in erster Linie der sogenannten „Copyleft“.

Die Klausel besagt, dass Veränderungen und Weiterentwicklungen, die auf einer frei zugänglichen Software basieren, ebenfalls offengelegt werden und frei zugänglich sein müssen. Dazu zählt die Offenlegung des GPL-Lizenztextes, einschließlich des Quellcodes, oder eines für drei Jahre gültigen, schriftlichen Angebots, den Quellcode zur Verfügung zu stellen.

GPL gilt als die wohl am weitesten verbreitete Software-Lizenz überhaupt. Sie wird sowohl vom Linux-Kernel und GNU-Tools als auch von vielen anderen populären Open-Source-Projekten genutzt. Für Software-Anbieter, die mit proprietärer Software Geld verdienen wollen und ihr geistiges Eigentum schützen müssen, ist die GPL hingegen mit Risiken verbunden.

Gilt GPL bei SaaS?

„Distribution“ ist, wie bereits erwähnt, das Schlüsselwort der GPL, welches im Bereitstellungsmodell von SaaS grundsätzlich keine Rolle spielt. Denn hier wird der Quellcode nicht an den Nutzer weitergeben oder auf seinem Rechner installiert. Dies macht SaaS-Produkte bis zu einem gewissen Grad immun gegenüber GPL – zumindest, wenn man im SaaS-Modell lediglich das Ausführen („Running“) bzw. das Vervielfältigen der Software sowie der darin enthaltenen OSS-Komponenten sieht.

Wie so oft bei Software-Lizenzen gibt es auch hier Ausnahmen zu beachten – zum Beispiel SaaS-Anwendungen, die eine JavaScript-Bibliothek verwenden. Animation und grafische Elemente der Software basieren auf einem Code, der auf dem Computer heruntergeladen und dort ausgeführt wird.

Juristisch ist dies durchaus als Weitergabe zu werten und fällt damit unter GPL. Angesichts der Dominanz von Javascript in der Webentwicklung gibt es wohl nur wenige SaaS-Produkte, die tatsächlich zu 100-prozentig Javascript-frei sind und damit das SaaS-Schlupfloch nutzen können.

Warum gibt es die GNU Affero General Public License (AGPL)?

Um Unsicherheiten in Bezug auf GPL und Cloud Computing zu beseitigen, entwickelte die Free Software Foundation daher die GNU Affero General Public License (AGPL). AGPL-3.0 basiert auf dem Lizenztext der GPL, wurde aber um den entscheidenden Abschnitt 13 erweitert.

Anbieter müssen den Quelltext einer Software demnach auch dann offenlegen, wenn diese lediglich auf einem Server als Dienst betrieben wird. „Distribution“ bzw. die Weitergabe des Codes ist also nicht mehr alleiniger Auslöser für die Gültigkeit der Lizenzregelung. AGPL zielt damit explizit auf Anwendungsszenarien innerhalb des Cloud Computings und schließt effektiv die SaaS-Lücke.

Welche Risiken bleiben bei der Nutzung von OSS-Komponenten?

Unabhängig von der Debatte um das GPL-SaaS-Schlupfloch sollten Software-Anbieter die Lizenzen von OSS-Komponenten genau im Blick behalten. Denn die Lizenzen sind komplex, teilweise schwer verständlich und verändern sich im Laufe der Zeit. Dadurch entstehen unterschiedliche Risiken:

Compliance-Risiken

Unwissenheit schützt vor Strafe nicht – oder zumindest nicht vor langwierigen und kostspieligen Rechtsstreitigkeiten. GPL mag SaaS-Anwendungen ein Schlupfloch bieten, AGPL jedoch verlangt klar Open-Source-Konformität. Anbieter müssen hier genau wissen, woher eingesetzte OSS-Komponenten stammen und welchen Lizenzen sie unterliegen. Bei jeder Lizenz kann es Ausnahmen geben, die verstanden, respektiert und weitergegeben werden müssen.

Vorsicht ist ebenfalls geboten, wenn hinsichtlich der Lizenzierung keine Angaben vorliegen. Nur weil die Lizenz einer OSS-Komponente nicht genannt wird, heißt das nicht, dass keine Lizenzvorgaben zu erfüllen sind. Eventuell wird die Komponente nicht häufig genutzt oder der Kreis der Benutzer ist relativ klein. So ist es zum Beispiel möglich, dass ein Entwickler nachträglich einen Antrag stellt, um seinen Code unter eine neue Lizenz zu stellen bzw. um die Lizenzbestimmungen zu ändern. Liegt keine klare Erlaubnis für die Verwendung einer OSS-Komponente vor, besteht also immer ein Risiko.

Sicherheitsrisiken

Frei verwendbar und sicher sind zwei Begriffe, die in der heutigen Zeit eher selten im selben Atemzug fallen. Wer OSS-Komponenten – egal ob unter GPL oder AGPL – in seinen Produkten verwendet, setzt sich immer den Risiken von Schwachstellen und Bugs aus. Das Gute an der Open-Source-Gemeinschaft ist, dass sie sich lautstark und aktiv für Schwachstellen einsetzt. Sobald Sicherheitslücken im Code identifiziert sind, findet sich in der Regel auch ein entsprechender Patch. Das CVE-System (Common Vulnerabilities and Exposures) bietet einen zuverlässigen Referenzrahmen für bekannt gewordene Schwachstellen.

Der schönste Patch hilft allerdings nur wenig, wenn Anbietern der Einblick und Überblick ihrer Software-Komponenten fehlt. Im Rahmen von Software-Audits wertete Revenera mehr als 2,6 Milliarden Codezeilen aus und entdeckte dabei insgesamt 230.000 kritische Fälle.

Im Durchschnitt stießen die Analysten alle 11.500 Codezeilen auf einen Compliance-Verstoß, eine Sicherheitsschwachstelle oder Ähnliches. Das eigentlich Fatale: 83 Prozent der in den Audits aufgedeckten Risiken waren den UntSucheSicheernehmen im Vorfeld der Untersuchung nicht bekannt.

Strategische Risiken

Unternehmen, die sich voll und ganz auf die Entwicklung von SaaS Anwendungen fokussieren und dabei das GPL-Schlupfloch ausnutzen, sollten sich zudem über die möglichen strategische Konsequenzen bewusst sein. Nicht alle Kunden wollen oder können den Weg in die Cloud gehen. In bestimmten Industrien und Anwendungsszenarien (z. B. KRITIS) sind On-Premises-Anwendungen weiterhin die bessere Wahl.

Basiert die Architektur einer Software jedoch zum Großteil auf GPL-lizenzierten Code, müssen Anbieter notgedrungen auf andere Bereitstellungsmodell und damit auf potenziell zahlungskräftige Kunden verzichten. Je stärker die Abhängigkeit von GPL, desto weniger Spielraum bleibt Anbietern in der späteren Weiterentwicklung und Ausbau ihrer Geschäftsstrategie.

OSS-Governance: Software Composition Analysis & SBOM

Um Compliance- und Sicherheitsrisiken von OSS zu managen, braucht es einen ganzheitlichen Ansatz für die Open-Source-Governance (OS-Governance). Rechtlich verbindliche Richtlinien zum Umgang mit OSS gibt es zwar bislang nur in Ansätzen. Trotzdem ist es für Software-Anbieter dringend notwendig, entlang der Software Supply Chain einheitliche Verfahren zu etablieren. Dazu gehört unter anderem die Integration von OSS-Scanning in den Build-Prozess von Anwendungen.

SCA-Tools (Software Composition Analysis) decken nicht nur auf, welche Source Libraries für ein Programm genutzt werden, sondern auch welche Drittanbieter-Bibliotheken standardmäßig damit verknüpft sind. Entwickler, Compliance-Manager und Sicherheitsteams können so den genauen Anteil des übernommenen Codes innerhalb des proprietären Quellcodes prozentual bestimmen.

Ein weiteres Kernelement der OS-Governance ist die Software-Bill-of-Materials (SBOM). Die Software-Stückliste liefert eine detaillierte Auflistung aller eingesetzten Code-Komponenten, einschließlich ihrer Lizenzierung. Automatisierte SBOM-Lösungen aggregieren Daten ganzheitlich über unterschiedliche Quellen hinweg – von vorgelagerten Upstream-Partnern und Drittanbieter, SCA-Scans, Open Source Software-Libraries und anderen Data Services. Die konsolidierte Sicht auf den Code macht es somit möglich, Sicherheits- und Compliance-Risiken frühzeitig zu erkennen und OSS in effektiver Weise für kommerzielle Anwendungen zu nutzen – egal ob für SaaS oder On-Premise.

* Nicole Segerer treibt als SVP and General Manager die Vision, Strategie und Roadmap von Revenera kontinuierlich voran. Sie ist für die Bereiche Produktmanagement, Marketing und Engineering verantwortlich, wobei ein besonderer Fokus auf der Analyse und Monetarisierung von Softwareprodukten sowie der Verbesserung der User Experience liegt.

(ID:49423467)