GPL-Compliance – Copyleft und andere Aspekte 7 Fragen und Antworten zur GNU GPL

Autor / Redakteur: Jeff Luszcz * / Stephan Augsten

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.

Anbieter zum Thema

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)

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.

Ergänzendes zum Thema
Checkliste zur Open Source Compliance
  • Wo wird Open-Source Software einschließlich sämtlicher Versionen eingesetzt?
  • Wie genau sind die verfügbaren Informationen?
  • Wo genau in der Codebasis befindet sich die eingesetzte Open-Source Software?
  • Wie wird die Open-Source Software eingesetzt?
  • Sind in den verwendeten Versionen Schwachstellen vorhanden?
  • Werden die neuesten Versionen eingesetzt – und wenn nicht, warum?
  • Wird für alle OSS-Projekte in der Codebasis für eine kommerzielle Unterstützung gezahlt?
  • Falls nicht, wer ist für die Überwachung und Aktualisierung auf neuere Versionen zuständig?
  • Welche Nutzungsrichtlinien und Genehmigungsprozesse werden für unsere Open-Source Software eingesetzt?
  • Werden unternehmenseigene Richtlinien durchgesetzt und eingehalten?

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.

(ID:45453419)