Compliance Was Entwickler über den Umgang mit Open Source Software wissen sollten

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Continental Automotive GmbH

Wenn es um Open Source geht, herrscht bei vielen Entwicklern Unsicherheit über Rechte und Pflichten. Woher kommt der Open- Source-Gedanke und welche Regeln gilt es beim Einsatz zu befolgen?

Mit dem Siegeszug von Linux im industriellen Umfeld ist der Umgang mit Open Source Software für die meisten von uns zum Alltag geworden. Die Vorteile liegen auf der Hand und die Industrie hat mittlerweile gelernt, diese effizient zu nutzen. Doch neben den technischen Aspekten will auch der juristische Umgang mit Open Source Software gelernt sein. Als Fundament für deren korrekte Handhabung müssen in jedem Unternehmen die passenden Prozesse geschaffen werden.

Diese werden für jedes Unternehmen zwar unterschiedlich ausgeprägt, doch die Spielregeln, die bei der Arbeit mit Open Source befolgt werden müssen, sind stets dieselben. Dieser Artikel bietet einen Überblick zur Geschichte von Open Source, den rechtlichen Grundlagen und den wichtigsten Regeln zum Umgang mit Open Source Software.

Die Geschichte der „Open Source“ Software

Wer die zu Grunde liegenden Lizenzmodelle verstehen möchte, muss sich zunächst mit der Geschichte von Open Source Software beschäftigen; denn dies ist keine neue Idee! In den frühen Tagen der elektronischen Datenverarbeitung war die Weitergabe von Sourcecode eher die Regel.

Der Hintergrund ist ganz einfach: Im Gegensatz zu heute war Hardware sehr speziell und nur schwer erweiterbar und schon gar nicht austauschbar. Die Hardwarehersteller konzentrierten sich auf ihr Knowhow und überließen ihren Kunden die Software sozusagen als „notwendiges Beiwerk“. In der Regel wurde auch der Sourcecode weitergegeben, um Anwendern Anpassungen an ihre Umgebung zu ermöglichen. Auch Betriebssysteme wie UNIX wurden so über viele Jahre frei an die Nutzer weitergegeben.

Mit zunehmender Erweiterbarkeit und Austauschbarkeit von Hardware wurde aber auch die Software austauschbar und so auch für die Hersteller zu einem neuen Geschäftsmodell. Für viele Nutzer führte dies zu der unangenehmen Situation, dass Sie nun zum einen viel Geld bezahlen mussten, um die Software weiterzuverwenden, die sie bereits einsetzten und (für viele Anwender war dies noch viel schwerwiegender) mit den neuen Lizenzmodellen wurde nun auch kein Sourcecode mehr weitergegeben, was den bis dahin üblichen Wissensaustausch zwischen Softwareentwicklern massiv einschränkte.

Geprägt von dieser Erfahrung gründete Richard Stallman 1985 die Free Software Foundation (FSF) mit dem Ziel, das bis dahin weit verbreitete UNIX Betriebssystem frei nachzuimplementieren und es unter einer Lizenz bereitzustellen, die es dem Nutzer erlaubt, die Software zu analysieren, zu modifizieren und auch selbst wieder weiterzuverbreiten. Die einzige Bedingung, die in diesem Modell gefordert wird, ist, dass eine Weiterverbreitung nur unter denselben Lizenzbedingungen erfolgen darf. Die eingeräumten Rechte bleiben also immer erhalten. Dieses Konzept wird als Copyleft bezeichnet.

Das mag eine verwirrende Bezeichnung sein, weil man versucht sein könnte, Copyleft als das Gegenteil von Copyright zu verstehen. Dies wäre aber unsinnig; denn Copyleft basiert auf Copyright und ist sicher nicht dessen Gegenteil. Doch es könnte sich auch um ein Wortspiel basierend auf dem Verb „to leave, left, left“ handeln; im Sinne von „left to be copied“. Es bleibt also die Freiheit erhalten, zu analysieren, zu modifizieren und weiterzuverbreiten! Bild 1 verdeutlicht den Copyleft-Effekt bei der Weitergabe.

Dieses Konzept bildet die wichtigste Grundlage für die Regeln, die beim Umgang mit Open Source Software zu befolgen sind. Doch bevor wir uns näher mit den Open-Source-Lizenzmodellen und den daraus abzuleitenden Regeln beschäftigen, gilt es noch einige rechtliche Aspekte zu verstehen.

Open Source Software und Urheberrecht

Wie bei jedem Werk gibt es natürlich auch bei Open Source Software einen Urheber, das liegt in der Natur der Sache. Die Tatsache, dass der Sourcecode verfügbar und die Nutzung in der Regel mit keinen Lizenzkosten verbunden ist, lässt viele Anwender jedoch vergessen (oder gar bewusst verdrängen), dass es mit dem Urheber auch einen Inhaber der Rechte an dieser Software gibt.

Mit der Berner Übereinkunft wurde 1886 die Grundlage dafür geschaffen, das Urheberrecht zwischen souveränen Nationen anzuerkennen. Bis heute ist diese Übereinkunft von mehr als 170 Ländern anerkannt, es gibt also eine praktisch weltweit gültige Übereinkunft zum Thema Urheberrecht. Nun muss ein Entwickler kein Experte im Umgang mit Urheberrecht sein, es ist aber sehr wichtig, folgende Punkte zu verstehen:

• Sobald ein Mensch ein literarisches oder künstlerisches Werk geschaffen hat, ist dieses automatisch geschützt, ohne dass es einer Registrierung bedarf.

• Dieser Schutz verbietet es allen anderen Menschen, das Werk zu nutzen.

Der Vollständigkeit halber sei an dieser Stelle erwähnt, dass Sourcecode als literarisches Werk gilt und entsprechend geschützt ist. Der Urheber kann Dritten die Nutzung seines Werkes mit einer Lizenz erlauben. Im Falle von Open Source Software erfüllen diese Lizenzen bestimmte Kriterien.

Verschiedene Open-Source-Lizenzen und was sie bedeuten

Um es vorwegzunehmen: Wer mit Open Source Software arbeitet, muss sich nicht nur mit einer, sondern mit vielen unterschiedlichen Lizenzen auseinandersetzen. Glücklicherweise liegen all diesen Lizenzen dieselben Ideen zu Grunde. Von der Open Source Initiative (OSI) existiert eine Definition, die verschiedene Anforderungen festlegt, die eine Open-Source-Lizenz erfüllen muss. Kriterien sind etwa die freie Weiterverbreitung und die Erlaubnis, Modifikationen durchzuführen und abgeleitete Werke zu erstellen. Die vollständige Definition findet sich online unter opensource.org/osd. Die Tatsache, dass grundsätzlich dieselben Regeln und Richtlinien angewendet werden, erlauben uns den Umgang mit vielen unterschiedlichen Lizenzen mit identischem Prozess.

Generell lassen sich Open-Source-Lizenzen in zwei Kategorien unterteilen: Copyleft-basiert und permissive. Der Unterschied zwischen den beiden zeigt sich bei der Weitergabe: Copyleft-behaftete Lizenzen schreiben zwingend vor, dass auch bei der Weitergabe die originäre Lizenz erhalten bleibt. Permissive-Lizenzen verzichten auf diese Verpflichtung bei der Weitergabe, während die grundlegenden Anforderungen an eine Open-Source-Lizenz selbstverständlich weiterhin gegeben sind. Permissive-Lizenzen garantieren also nach wie vor die Freiheit der Nutzung, Modifikation und Weiterverbreitung, können aber die Erstellung eines proprietären abgeleiteten Werkes erlauben.

Der Unterschied zwischen Copyleft basierten und permissiven Lizenzen kann man an einem einfachen Beispiel verdeutlichen: Der Linux Kernel ist unter GPLv2 (Copyleft behaftet) lizensiert. Wer Linux modifiziert und weiterverbreitet, muss die Lizenz beibehalten und somit zum Beispiel auch den Sourcecode weitergeben oder mindestens auf Anfrage verfügbar machen. Das Betriebssystem FreeBSD unterliegt einer Variante der BSD Lizenz und ist permissiv. FreeBSD ist zwar Open-Source, die Weitergabe darf aber auch in Binärform, ohne die Bereitstellung von Sourcecode, erfolgen. Soll heißen: Wer FreeBSD weiterverbreitet, darf den Sourcecode zwar weitergeben, muss dies aber nicht.

Wie so oft im Leben gibt es auch bei Open-Source-Lizenzen nicht nur Schwarz und Weiß, sondern auch etwas dazwischen. Bei Copyleft-behafteten Lizenzen wird zwischen einem starken und einem eingeschränkten Copyleft unterschieden. Lizenzen mit einem eingeschränkten Copyleft treffen eine Einschränkung, was als sogenanntes abgeleitetes Werk zu betrachten ist, also wofür die Ursprungslizenz verwendet werden muss, und wofür nicht. Ein Beispiel für eine Lizenz mit eingeschränktem Copyleft ist die LGPL. Bei einer mit der LGPL lizensierten Bibliothek fällt eine Modifikation an der Bibliothek selbst unter das Copyleft, während eine Komponente die zum Beispiel gegen die Bibliothek gelinkt wird, aber jederzeit wieder davon abgetrennt werden kann, nicht als abgeleitetes Werk gilt und somit nicht unter das Copyleft fällt. Diese Einschränkung ist zum Schutz des eigenen Knowhows in der Applikation sehr wichtig! Bild 2 veranschaulicht den Unterschied zwischen starkem und eingeschränktem Copyleft.

ACHTUNG: Die GPL ist eine Lizenz mit einem starken Copyleft und trifft keine Einschränkung. Somit würde auch beim Linken das Resultat als abgeleitetes Werk betrachtet werden und es greift das Copyleft. Es geht also nicht nur um die Einhaltung von Lizenzpflichten, sondern auch um den Schutz des eigenen Knowhows. Die hier zu sehende Tabelle zeigt eine einfache Übersicht gängiger Open-Source-Komponenten, eingeteilt in Lizenzen und Lizenzkategorien.

Neben eingeschränktem und starkem Copyleft zeigt die Aufstellung zusätzlich noch die Kategorie „Network Protective“. Beim Umgang mit Lizenzen aus dieser Kategorie ist große Vorsicht geboten, denn hier wird explizit auch eine Nutzung via Netzwerk als Verbreitung der Software definiert! Dieser Lizenztyp wird gerade bei heute sehr aktueller Cloud-Software häufig verwendet.

Welche Lizenzpflichten müssen eingehalten werden?

Der wichtigste Aspekt zur Erfüllung der konkreten Lizenzpflichten wurde im vorhergehenden Abschnitt bereits indirekt angesprochen: Sie greifen bei der Weitergabe. Also jeder, der die Software weiterverbreitet, muss diese Verpflichtungen erfüllen. In einer Lieferkette kann also nicht an einen Dritten verwiesen werden. Verantwortlich ist, wer die Software weitergibt!

Bild 3 veranschaulicht ein typisches Szenario bei der Weitergabe: Ein Hersteller liefert ein Produkt, welches Open-Source-Komponenten beinhaltet an einen OEM. Dieser vertreibt das Produkt an eine große Anzahl von Endkunden. Verantwortlich gegenüber den Endkunden ist in diesem Szenario der OEM, auch wenn die Nichterfüllung einer Lizenzpflicht auf einem Fehler des Herstellers beruht. Zulieferungen, die Open Source Software beinhalten, müssen daher zwingend darauf geprüft werden, ob alle Informationen vorliegen, die für eine Weiterverbreitung notwendig sind.

Hierfür ist es grundsätzlich sinnvoll, eine Übersicht bzw. Bill of Material der verwendeten Open-Source-Komponenten, der Lizenzen und der bereitgestellten Informationen einzufordern (und bei einer Weiterverbreitung auch selbst bereitzustellen)!

Doch welche Randbedingungen sind nun genau einzuhalten und was muss bei der Weitergabe von Open Source Software genau beigelegt werden? Aus praktischen Gründen wird dringend empfohlen, für jede Datei den Copyright-Inhaber und die verwendete Lizenz zu vermerken. Das ist nicht spezifisch für Open Source, sondern ist eine generelle Empfehlung. Denn wir erinnern uns: Wenn der Urheber die Nutzung nicht explizit erlaubt, ist diese untersagt!

Weiterhin sehen die meisten Lizenzen vor, dass die Lizenztexte, die Hinweise auf den Rechteinhaber und ein Gewährleistungsausschluss bei der Verbreitung beigelegt werden müssen. GPL und LGPL sehen zudem vor, dass Änderungen am Originalcode kenntlich gemacht und dass bei der Verbreitung von Binaries die Skripte zur Kompilierung und Installation bereitgestellt werden müssen. Im letzteren Fall muss zusätzlich noch entweder der komplette korrespondierende Sourcecode oder ein Angebot, diesen nachzuliefern, dem Produkt mitgegeben werden.

Handlungsrichtlinien für Entwickler

Im vorangegangenen Kapitel wurde bereits beschrieben, dass jede Datei mit einem Copyright und einem Lizenzvermerk versehen werden muss. Für beides gibt es eine eindeutige Syntax. Beginnen wir mit dem Copyright: Ein Copyright muss in jeder neuen Datei und bei signifikanten Änderungen an einer bestehenden Datei vermerkt werden. Folgende Beispiele zeigen, wie dies erfolgen kann:

• Copyright 2018, Example GmbH

• Copyright 2017-2019, Example GmbH

• Copyright 2017,2019, Example GmbH

• Copyright 2014-2017,2019, Example GmbH

Dem Schlüsselwort Copyright folgt die Jahreszahl und mit einem Komma separiert der Copyright Holder. Optional kann dann noch der Autor genannt werden, wenn dieser wie zum Beispiel bei einem angestellten Software-Entwickler nicht der Copyright-Inhaber ist; dies könnte dann so aussehen:

• Copyright 2019, Example GmbH, author: Jan Altenberg

Zum Vermerk der Lizenzinformation gibt es verschiedene Möglichkeiten, empfohlen wird aber grundsätzlich das SPDX-Format. SPDX definiert zum einen ein Dateiformat zum Austausch von Software Bill of Material Information, zum anderen definiert SPDX eindeutige Kürzel für Open-Source-Lizenzen. Im Sourcecode wird hierfür das Schlüsselwort: „SPDX-License-Identifier:“, gefolgt vom passenden Lizenzkürzel verwendet (eine Übersicht aller verfügbaren Kürzel findet sich hier: spdx.org/licenses/).

Wichtig ist, dies direkt in jeder Sourcedatei zu tun. So bleibt auch beim Kopieren einer Datei die Lizenzinformation immer erhalten. Achtung: Die Entscheidung, welche Lizenz verwendet und vermerkt wird, ist keine Entscheidung des Entwicklers! Es handelt sich um eine juristische Entscheidung, die von den zuständigen Personen im Unternehmen getroffen werden muss!

Wir haben bereits erwähnt, dass einige Lizenzen (wie etwa die GPL) weitere Bedingungen vorsehen: So müssen Änderungen dokumentiert sein und es muss die Möglichkeit bestehen, die jeweiligen Komponenten (wie den Linux Kernel) selbst zu erzeugen und auch installieren zu können. Für die Dokumentation von Änderungen, empfiehlt es sich, dem Original-Sourcecode kommentierte Patches beizulegen. Sollte dies nicht möglich sein, kann eine Änderung auch durch einen Kommentar in der jeweiligen Sourcedatei erfolgen (mit Datum, Autor und einer kurzen Beschreibung der durchgeführten Änderung).

Weiterhin muss der Empfänger der Software in der Lage sein, das Binary, welches auf dem Zielsystem ausgeführt wird, selbst zu erzeugen. Bereitstellen müssen Sie die passenden Skripte und eine entsprechende Dokumentation, nicht jedoch alle benötigten Werkzeuge, wie zum Beispiel die Toolchain. Es muss lediglich dokumentiert sein, welche Werkzeuge benötigt werden. Denken Sie daran: Geben Sie eine komplette Entwicklungsumgebung (wie eine virtuelle Maschine oder eine Toolchain) weiter, so müssen Sie auch die Lizenzpflichten für die Entwicklungsumgebung erfüllen!

Unabhängig von speziellen Lizenzverpflichtungen zeigt die Erfahrung, dass ein Sachverhalt in Projekten oft vergessen wird: Bitte beachten Sie, dass auch kopierte Codesnippets (etwa aus dem Internet) üblicherweise unter einer Lizenz stehen. Die Verwendung von kopierten Snippets ist daher grundsätzlich mit den zuständigen Personen im Unternehmen abzuklären!

Generelle Empfehlung für den Umgang mit Open Source

Sie sehen, nicht alle Lizenzen legen dem Nutzer dieselben Verpflichtungen auf. Eine generelle Empfehlung lautet aber, alle Open-Source-Komponenten möglichst einheitlich zu handhaben! Legen Sie also die Verpflichtungen der restriktiven, Copyleft-basierten Lizenzen für den gesamten Prozess und den Umgang mit Open Source zu Grunde!

Bild 4 fasst die wichtigsten Punkte in einer Checkliste zusammen. Nehmen Sie die Verpflichtungen ernst! Fehlende Komponenten, die zur Weitergabe erforderlich sind (wie Lizenzinformation, Build-Skripte und Anleitung, Dokumentation von Änderungen, usw.) müssen im Releaseprozess als kritischer Fehler behandelt werden; so wie jeder andere Fehler in der Software!

Fazit: Klare Spielregeln für den Open-Source-Einsatz

Für den Umgang mit Open Source Software ist es wichtig, deren Geschichte und die dahinterliegenden Ideen zu verstehen. Wer Open Source Software einsetzt, muss zwar mit vielen unterschiedlichen Lizenzen umgehen, aufgrund einer klaren Definition lässt sich aber ein einheitlicher Prozess finden. Die Spielregeln sind klar, und viele Randbedingungen, wie das Dokumentieren von Änderungen oder das reproduzierbare und für einen Dritten nachvollziehbare Bauen der Komponenten, sind für die Softwareentwicklung ohnehin unerlässlich; auch ohne den Einsatz von Open Source.

Und vergessen Sie nicht: Der Umgang mit Lizenzen und die damit verbundenen Entscheidungen sind ein juristisches Thema und bedürfen daher auch immer einer juristischen Beratung!

Zehn Vorteile, die für Open Source Software in Unternehmen sprechen

7 Fragen und Antworten zur GNU GPL

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

Dieser Beitrag ist erschienen im Sonderheft Embedded Softwar Engineering der ELEKTRONIKPRAXIS (Download PDF)

* Jan Altenberg ist Open Source Compliance Officer und System Architect bei der Continental Automotive GmbH in Villingen-Schwenningen.

(ID:46165780)