Ein Angebot von

7 Fragen und Antworten zur GNU GPL

| Autor / Redakteur: Jeff Luszcz * / Stephan Augsten

Quelloffenheit entbindet nicht von der Erfüllung bestimmter Lizenzvorgaben, wie die GNU GPL sie vorsieht.
Quelloffenheit entbindet nicht von der Erfüllung bestimmter Lizenzvorgaben, wie die GNU GPL sie vorsieht. (© ar130405 - stock.adobe.com)

Embedded Linux und ähnliche Open-Source-Projekte unterliegen häufig den Bestimmungen der GNU General Public License, kurz GNU GPL. Dies wirft immer wieder Compliance-Fragen auf. Sieben besonders wichtige Punkte wollen wir im Folgenden klären.

250.000 Euro Ordnungsgeld oder 6 Monate Haft – das drohte einem deutschen Elektronikhersteller, der nach Meinung des ehemaligen Kernel-Entwicklers Patrick McHardy gegen die Lizenzbestimmung von Linux verstoßen hatte. Letztendlich zog McHardy den Antrag zurück, doch wirft die GNU General Public License (GNU GPL) immer wieder Fragen auf.

Mit dem Internet der Dinge (IoT) und der wachsenden Verbreitung von neuen Technologien wie Machine Learning und KI wird die Compliance für Sicherheits-, Entwicklungs- und Rechtsabteilungen zur obersten Priorität. Immerhin basiert die Mehrzahl von IoT-Geräten und Embedded Systems auf Linux und unterliegt damit der GLP-Lizenz.

Um die Compliance einzuhalten, sind fest etablierte Prozesse nötig, eine klare Verteilung der Zuständigkeiten innerhalb von Entwicklungs- und Produktteams sowie die Vorhaltung entsprechender Ressourcen. Dabei empfiehlt es sich, die Software-Compliance im Vorfeld, also vor der Veröffentlichung der Produkte, gründlich zu überprüfen, um nach der Bereitstellung keine kostspieligen Rechtsstreitigkeiten oder Rufschädigungen zu riskieren.

Im Folgenden sind sieben grundsätzliche Fragen und Antworten zur GPL zusammengefasst.

1. Was ist die GPL?

Die GPL ist eine Open-Source-Software-Lizenz, die weitreichende Rechte für die Nutzung der Software einräumt – auch für kommerzielle Projekte. Entwickler können kostenfrei und legal den GPL-lizenzierten Quellcode nutzen, kopieren, weiterverbreiten und ändern.

Mit GPL sind jedoch auch Verpflichtungen verbunden, in erster Linie das sogenannte „Copyleft“. Es besagt, dass Veränderungen und Weiterentwicklungen, die auf einer frei zugänglichen Software basieren, ebenfalls offengelegt werden und frei zugänglich sein müssen.

Dieses grundlegende Konzept ermöglicht es der Open Source-Community, sämtliche Verbesserungen in eigene, wiederum frei zugängliche Projekte einfließen zu lassen und auf diesem Weg Innovationen zu fördern. GPL ist die wohl am weitesten verbreitete Software-Lizenz und wird sowohl vom Linux-Kernel und GNU-Tools als auch von vielen anderen populären Open-Source-Projekten genutzt.

2. Was bedeutet GPL-Compliance?

GPL-Compliance ist der Prozess, ordnungsgemäße Software-Objekte zu entwickeln und dabei allen von GPL festgelegten Lizenzvorgaben zu folgen. Diese umfassen 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.

Der Quellcode enthält alle Verknüpfungen entweder zur ursprünglichen Bibliothek oder den unter GPL-lizenzierten bereitgestellten Programmen. Dabei ist es wichtig, die richtige Version der GPL anzugeben. Drei gängige Versionen stehen zur Verfügung: GPLv1, GPLv2 und GPLv3. Darüber hinaus kann es bei jeder Lizenz Ausnahmen geben, die verstanden, respektiert und weitergegeben werden müssen.

Open-Source-Lizenzmodelle
AGPL 3.0
Die Quelle muss offengelegt werden, sobald die Anwendung einem Netzwerk zugänglich gemacht wird.
Apache 2.0
Bei Nutzung muss ein Verweis auf die Bibliothek erfolgen und beibehalten werden.
GPL v3
Die Quelle muss offengelegt werden, wenn das Produkt veröffentlicht wird; Nutzer müssen die die Möglichkeit haben, den Code in einem "User Product" zu verändern.
BSD oder MIT
Bei Nutzung muss ein Verweis auf die Bibliothek erfolgen und beibehalten werden.
GPL v2
Die Quelle muss offengelegt werden, wenn das Produkt veröffentlicht wird.
Creative
Commons
Vorgaben sind von der Art der CC-Lizenz abhängig.
LGPL v3
Die Quelle der Bibliothek muss offengelegt werden, wenn sie mit dem Produkt zusammen veröffentlicht wird; Nutzer müssen die die Möglichkeit haben, den Code in einem "User Product" zu verändern.
Public
Domain
Open Source Code ist uneingeschränkt nutzbar.
LGPL v2.1
Die Quelle der Bibliothek muss offengelegt werden, wenn sie mit dem Produkt zusammen veröffentlicht wird.
Commercial
Die kommerziellen Lizenz-vereinbarungen müssen beachtet werden (geht für gewöhnlich mit Zahlungen und Geheimhaltungs-vereinbarungen einher).
EPL oder MPL
Die ursprüngliche Quelle der Bibliothek und die an ihr vorgenommenen Änderungen müssen offengelegt werden, wenn sie mit dem Produkt veröffentlicht wird.

No license Seen
Quellcode darf ohne explizite Erlaubnis des Urhebers nicht verwendet werden.

Ist die Lizenzierung einer Open-Source-Komponente nicht eindeutig, ist Vorsicht geboten. Entweder wird die Komponente nicht häufig genutzt oder der Kreis der Benutzer ist relativ klein. Das bedeutet jedoch nicht, dass keine Lizenzvorgaben zu erfüllen sind. So ist es denkbar, dass ein Mitentwickler im Rahmen des ursprünglichen Entwicklungsprojekts nachträglich einen Antrag stellt, um den Code unter eine Lizenz zu stellen oder die lizenzrechtliche Lage neu festzulegen.

3. Was passiert bei Compliance-Verstößen?

Egal wie komplex und unklar die Lizenzvorgaben scheinen mögen: Wer sich nicht an die Verpflichtungen hält, ist automatisch „Out of Compliance“ und muss mit entsprechenden Konsequenzen rechnen. Schlimmstenfalls können die Verstöße zu Rechtstreitigkeiten und Reputationsschäden führen.

Wird die Komponente bereits in einem Softwareprodukt verwendet, können zudem für den Softwarehersteller enorme Kosten entstehen. Die Entscheidung, ob eine profitable Software vom Markt genommen werden muss, hängt dann oft allein von der Reaktion des Autors/Urhebers der OSS oder des Projektverantwortlichen ab.

Noch komplexer wird es, wenn die Einhaltung von GPL – und damit die Weitergabe des Quellcodes an die Nutzer – mit anderen Lizenzverpflichtungen (z. B. für kommerzielle Software) im Widerspruch steht. Hier stehen die Hersteller oft vor einem Dilemma und sind möglicherweise dazu gezwungen, den kritischen Code zu entfernen und neu zu schreiben.

Geschieht dies nach der Produkteinführung besteht auch hier das Risiko, dass Anbieter den Vertrieb ihres Produkts so lange aussetzen müssen, bis die Verstöße behoben sind. Eine Garantie, dass die jeweiligen Urheber oder Open-Source-Projekte mit den dafür nötigen Schritten, dem Zeitplan oder dem Endergebnis zufrieden sind, besteht dabei nicht.

4. Was wird von den Entwicklern erwartet?

Auch die Open Source Community erwartet von Entwicklern, die sich Open Source Software bedienen, dass sie bestimmte Verhaltensgrundsätze befolgen. Das ist nicht immer der Fall. Wird an einem Projekt gearbeitet, das unter GPL vertrieben werden soll oder das Links zu GPL-lizenzierten Binärdateien enthält, nehmen Unternehmen häufig eine eher abwartende Haltung hinsichtlich Compliance-Fragen ein.

Leicht kann so der Eindruck entstehen, die Verantwortlichen würden GPL-Compliance nicht ernst nehmen oder vernachlässigen. Langfristig kann eine solche Haltung die Unternehmen jedoch in ernste Schwierigkeiten bringen, vor allem dann, wenn es zu mehreren lizenzrechtlichen Problemen kommt, für die Compliance-Artefakte vorzulegen sind.

Echte Compliance für bereits ausgelieferte Produkte zu garantieren ist damit schwierig. Dabei gehen Anwender in der Regel davon aus, den Quellcode für das aktuelle Binärprogramm einsehen zu können und nicht erst in einer künftigen, korrigierten Fassung.

5. Wie kommt es zu Compliance-Verstößen?

In den seltensten Fällen werden Compliance-Verstöße von GPL von Unternehmen tatsächlich bewusst in Kauf genommen. Viel häufiger ist es der Fall, dass Unklarheit und Unsicherheit darüber besteht, welche Vorgaben bei welchen Projekten wie eingehalten werden müssen. Oft sind bestehende Prozesse zur Einhaltung von Compliance auch schlichtweg veraltet oder sind über die Jahre hinweg eingeschlafen.

Ergänzendes zum Thema
 
Checkliste zur Open Source Compliance

GPL-Binärdateien gelangen in der Regel zunächst über die Software Supply Chain in ein Unternehmen und werden, einmal ausgewählt und integriert, an das nächste Projekt und den nächsten Entwickler weiter vererbt – und zwar oft ohne erneute Überprüfung. Geht man der fehlenden Compliance auf den Grund, wird schnell klar, dass es vor allem an einer Übersicht der genutzten OSS-Komponenten mangelt.

Ohne die Herkunft und die Lizenzierung jeder Datei zu verstehen, ist es unmöglich, Lizenzvorgaben zu erfüllen. Software-Stücklisten (Bill of Materials, BOM), in denen sowohl die im Unternehmen ausgewählten und genutzten Komponenten als auch Komponenten von Drittanbietern dokumentiert sind, spielen hier eine wichtige Rolle.

6. Was ist der Unterschied zwischen Compliance erreichen und beibehalten?

Die für die Einhaltung von Open Source-Lizenzen nötigen Maßnahmen hängen davon ab, ob Unternehmen zunächst Open-Source-Compliance erreichen müssen oder bereits mit den Lizenzvorgaben konform sind und dies auch bleiben wollen. Der erste Schritt – nämlich Compliance herzustellen – kann sehr schwierig sein, insbesondere wenn Entwickler bereits seit längerer Zeit an einem Projekt arbeiten.

Soll nachträglich eine BOM erstellt werden, geht es an das Scannen und Analysieren des kompletten Codes, um Lizenzverstöße zu identifizieren und zu beheben. Dazu kann es nötig sein, den Code zu entfernen oder neu zu schreiben, Angaben für Dritte zu erstellen oder den Quelltext bei Copyleft-Code weiterzugeben.

Ist eine BOM erstellt und die Lizenzvorgaben erstmal erfüllt, fällt es oft leichter, die Compliance bei zu behalten – vor allem da weniger Unklarheiten über den Ursprung von OS-Code bestehen. In den meisten Fällen werden Ergänzungen und Änderungen in der Codebasis vom aktuellen Entwicklerteam vorgenommen. Das erlaubt es sämtliche Veränderungen direkt bei ihrer Durchführung, am selben Tag oder im selben Sprint, zu überprüfen.

7. Wie lässt sich GPL-Compliance sicherstellen?

Softwareentwickler können nur dann die Compliance ihres Codes gewährleisten, wenn die Nutzung von Open Source unmissverständlich geregelt ist. Eindeutige Richtlinien und feste Prozesse sowie Schulungen und Aufklärungsarbeit bilden die Grundlage, um innerhalb von Unternehmen das Bewusstsein zu schärfen und einen verantwortungsvollen Umgang mit OSS sicherzustellen.

Ist klar, welche Lizenzen für welche Anwendungsfälle herangezogen werden, können Entwickler schneller und einfacher die richtige Entscheidung treffen. Die Botschaft dahinter: Das Einhalten von GPL ist nicht optional, sondern zwingend erforderlich. Compliance ist als letzte Hürde zu verstehen, die Software auf ihrem Weg überwinden muss, ehe sie veröffentlicht und bereitgestellt werden kann.

Jeff Luszcz
Jeff Luszcz (Bild: 2014 - Roi Brooks)

Der Anspruch sollte es sein, lizenzrechtliche Vorgaben jedes Mal und auf Anhieb zu erfüllen. Darüber hinaus lohnt sich ein enger Austausch und Kontakt mit Open-Source-Community und dem damit verbundenen Ökosystem, um beispielsweise bei schwer zu erfüllenden oder kontroversen Lizenzvorgaben Meinungen zu rechtlichen Fragen und Best Practices einzuholen.

* Jeff Luszcz ist Vice President of Product Management bei Flexera und leitet das Professional Services Team, das für Open Source Compliance und Security Audits verantwortlich ist. Zuvor war er Gründer und CTO von Palamida, einem führenden Anbieter von Open Source Discovery und Vulnerability Management Tools. Er unterstützt seit über zehn Jahren Softwarefirmen, Open Source optimal zu nutzen und gleichzeitig ihre Lizenzverpflichtungen zu erfüllen und Sicherheitsfragen im Auge zu behalten.

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

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

26.04.18 - Wenn wir Flugzeuge so bauen wie wir Software entwickeln, würde kaum jemand noch fliegen. Software ist nie zu 100% sicher. Grund dafür ist auch die unkontrollierte und nicht verwaltete Nutzung von Open Source-Software (OSS). Darum ist auch bei Software eine gut geführte Bill of Materials (BOM) essentiell. lesen

Compliance: Die versteckten Risiken von Open-Source-Code

Compliance: Die versteckten Risiken von Open-Source-Code

05.04.17 - Bis zu 50 Prozent des gesamten Code-Bestandes bestehen aus Open-Source-Software (OSS)-Komponenten. Für Softwareentwickler bedeuten sie mehr Agilität und Effizienz, doch sie bergen auch Risiken. lesen

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

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45463216 / Open Source)