GPL-Compliance – Copyleft und andere Aspekte

7 Fragen und Antworten zur GNU GPL

Seite: 2/2

Firmen zum Thema

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
  • 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?

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.

(ID:45453419)