Warum gibt es Lizenzen?

Computerprogramme und Code sind urheberrechtlich geschützt, in Deutschland lässt sich dieser Schutz nicht umgehen oder ausschalten. Das Urheberrecht gewährt grundsätzlich nur demjenigen, der das Werk geschaffen hat ("Urheber"), die Rechte an dem Werk. Mithin dürfte nur der Entwickler den von ihm geschriebenen Code verwenden, verändern und verbreiten.

Dieses Verwertungsrecht kann der Urheber jedoch ganz oder teilweise an andere Personen abtreten, zum Beispiel an den Arbeitgeber (welcher dadurch jedoch nicht Urheber wird). Daraus ergibt sich, dass Urheber/Autor und Rechteinhaber durchaus voneinander verschiedene Personen sein können.

Ausgangspunkt des derzeitigen Urheberrechts ist, dass niemand außer dem Rechteinhaber das Werk vervielfältigen, verbreiten, bearbeiten oder eine entsprechende Genehmigung an eine andere Person erteilen darf. Der Urheber müsste also mühsam individuelle Ausnahmen vereinbaren. Viele Menschen waren mit dieser strikten Regulierung unzufrieden, Code sollte frei und ohne Notwendigkeit für individuelle Kontaktaufnahme durch jeden oder aber zumindest die Nutzer des Programms veränderbar sein, so wie beispielsweise ein Fahrrad auch durch jeden, der berechtigten Zugriff auf dieses Fahrrad hat, veränderbar ist.

Da ein Verzicht auf das Urheberrecht jedoch u.a. in Deutschland nicht möglich ist, wurde das Tool des Urheberrechts, die Lizenzen, für den jeweiligen Code so ausgestaltet, dass jeder grundsätzlich alle Rechte eingeräumt bekommt (Free Software). Um Code überhaupt verbreiten und verändern zu können, ist jedoch auch die Veröffentlichung des Codes notwendig: Open Source ist die Lösung.

Free and Open Source Software

Open Source bedeutet im Wortsinne zunächst einmal, dass der Code öffentlich einsehbar ist. Nicht zwangsläufig muss dies über ein Versionsverwaltungstool geschehen, auch wenn dies häufig der Fall ist, auch die Bereitstellung des Codes auf Nutzeranfrage hin, ohne nennenswerte weitere Bedingungen erfüllen zu müssen, kann als Open Source verstanden werden. Ist der Code dauerhaft einsehbar, schauen viele Augen mit viel unterschiedlichem Wissen darüber, Sicherheitslücken aber auch allgemeiner Verbesserungsbedarf fallen schnell auf.

Während Hinweise von Externen auf Verbesserungsbedarf an proprietärem Code nicht selten mit rechtlichen Konsequenzen zulasten des Finders einhergehen, was offensichtlich der Fehlersuche entgegenwirkt, wird durch Offenlegung des Codes die Verbesserung des Programms gefördert.

Open Source betont über die Einsehbarkeit hinaus auch die Veränderbarkeit des Codes durch jederman, im Gegensatz zu nur Code-available-Programmen. Selbstverständlich folgt aus der Einsehbarkeit und Veränderbarkeit des Codes jedoch nicht, dass jemand ohne Genehmigung Veränderungen in den Ursprungscode einpflegen kann, lediglich eine eigene Version, ein Fork, ist möglich. Der Vorteil für den ursprünglichen Entwickler liegt darin, dass er die durch andere Personen vorgenommenen Optimierungen bei entsprechender Lizensierung auch wieder in den Ursprungscode übernehmen kann.

Free Software wiederum rückt die Freiheit der Anwender in den Mittelpunkt, für welche freie Software notwendig ist. Ein Entwickler von freier Software hat nicht vordergründig die technischen oder wirtschaftlichen Vorteile eines offenen Quellcodes im Blick, sondern möchte aktiv die Gesellschaftsordnung hin zu mehr Nutzungsfreiheit für Individuen gestalten. Für das letztlich entstehende Programm macht dies jedoch kaum einen Unterschied.

Kurz gesagt fasst man unter Open Source die Beschreibung eines Programms, nämlich mit einsehbarem und abwandelbarem Code, und unter Free Software eine ethische Idee, die dahinter stehen kann - jedoch nicht muss. Als gemeinsamen Begriff kann FOSS, was für Free and Open Source Software steht, sowie FLOSS, welches noch Libre hinzufügt, verwendet werden. Für den Verwender von FOSS-Programmen machen diese Unterschiede in den Definitionen jedoch de facto keinen Unterschied.

Damit eine FOSS-Lizenz jedoch gültig ist, muss sie von dem Rechteinhaber ausgestellt worden sein. Ein unter Verletzung der proprietären Lizenz veröffentlichtes Programm wird nicht durch die bloße Veröffentlichung zu einem FOSS-Programm und mithin für die Allgemeinheit nutzbar, und eine durch die illegal veröffentlichende Person angefügte Lizenz ist auch nicht bindend, sodass das Programm allgemein verwendbar wäre. So wie eine proprietäre Lizenz natürlich auch Bestand hat, selbst wenn das Programm unerlaubt veröffentlicht wird, bleibt auch eine FOSS-Lizenz bestehen, auch wenn beispielsweise die Betreuung des Programms beendet wird. Eine Lizenzänderung ist zwar möglich, macht die bisher lizenzkonforme Verwendung jedoch nicht nachträglich rechtswidrig und betrifft daher nur zukünftige Verwendungen.

Embedded Linux

Bei Embedded Linux handelt es sich um Embedded Betriebssysteme, welche auf dem Linux-Kernel basieren. Grundsätzlich lassen sich drei Ebenen unterscheiden:

• die Hardware,
• der Kernel sowie das grundlegende Betriebssystem,
• die individuelle Anwendungssoftware.

Der Linux-Kernel ist Open Source (GPL-v2) und daher einsehbar, veränderbar, weiterverbreitbar. FOSS-Embedded-Systeme bieten den großen Vorteil, dass sie aufgrund ihrer Flexibilität sehr genau auf die konkreten Bedürfnisse zugeschnitten werden können, dadurch effizienter sind sowie auf eine Vielzahl von intellektuellen Ressourcen zurückgegriffen werden kann. Bei regelmäßigen Updates lässt sich sagen, dass ein FOSS-System grundsätzlich sicherer ist als ein vergleichbares System mit größtenteils proprietärer Software.

Gerade im gewerblichen Umfeld ist ebenfalls relevant, dass bei Verwendung von FOSS-Systemen kein Vendor-Lock-In entsteht, also nicht dauerhaft auf einen bestimmten Dienstleister zurückgegriffen werden muss, und mit der Zeit sogar genügend Know-How zusammengetragen worden sein kann, sodass Inhouse-Betreuung möglich ist. Nichtsdestotrotz ist die Betreuung und vor allem die initiale Entwicklung aufwendig, weshalb es sich empfiehlt, einen spezialisierten Dienstleister zu beauftragen. Ganz so, wie zwar jeder ein Fahrrad zusammenbauen könnte, jedoch nur der Fachmann auch weiß, welche Bauteile für welchen Zweck sinnvoll sind und wie man sie nicht nur so zusammensetzt, dass nichts auseinanderfällt, sondern so, dass das Fahrrad auch den Bedürfnissen entsprechend gut benutzbar ist.

Lizenzmanagement

Mit einsehbarem Quellcode einher geht jedoch eine weitere Besonderheit: diverse Lizenzen, die jeweils beachtet werden müssen. Während auch proprietäre Software Lizenzen beinhaltet, muss man sich über die Erfüllung selten Gedanken machen, da mit Anschaffung der Software für gewöhnlich bereits klar ist, dass die Software für den angedachten Zweck auch die Rechte bereitstellt (obwohl die meisten Lizenzverletzungen wohl gerade im proprietären Bereich auftreten, da kein Bewusstsein für Lizenzen besteht).

Im Falle von Open-Source-Code liegt erst einmal alles, völlig unabhängig von den Lizenzbedingungen, offen und kann theoretisch verwendet werden. Ob man ein Programm jedoch verwenden darf, steht auf einen anderen Blatt - nämlich den Lizenzbedingungen.

Es gibt eine handvoll weit verbreiteter Lizenzen, deren Bedingungen nach einiger Zeit der Verwendung von FOSS-Programmen im Schlaf bekannt sind.

Hierunter fallen die GPL-v2 und GPL-v3, die LGPL, BSD-Lizenz und noch weitere. Jedoch kann der Rechteinhaber selbstverständlich Bedingungen ganz nach Belieben festlegen. Daher ist es immer möglich, dass Code keine der bekannten Lizenzen verwendet, sondern individuelle Bedingungen aufstellt. Auch in diesem Fall sind die Bedingungen natürlich zu erfüllen, wenn man das Programm nutzen möchte.

Unerlässlich ist somit, bei allem verwendeten Code die Lizenz-Dateien (auch: Copying-Dateien) oder, bei anderer Herangehensweise der Entwickler, den Lizenz-Header auszulesen und mindestens bei unbekannten Lizenzen genau auf die Bedingungen hin zu prüfen. Eine Lizenzverletzung ist eine Rechtsverletzung, denn um ein Programm zu nutzen, muss man dessen Bedingungen akzeptieren, da ohne die Bedingungen das Programm allein dem Rechteinhaber zusteht. Lizenzpflege ist mithin notwendig und muss in Form eines fortlaufenden Lizenzmanagements geschehen. Wenn ehrliches Bemühen um Lizenzpflege erkennbar ist, fallen Reaktionen auf kleinere Ungenauigkeiten jedoch zumeist milder aus. Daher sollte, wie immer, gut dokumentiert werden, um stets zu wissen, an welchen Stellen man noch nacharbeiten muss. Durch eine gute Dokumentation kann man das eigene Bemühen nachweisen und erleichtert außerdem den Nachfolgern die Fortsetzung der Lizenzpflege.

Es gibt viele Einzelpersonen wie Unternehmen, die bereits seit vielen Jahren Übung im Lizenzmanagement haben und hilfreiche Werkzeuge bereitstellen. Um beispielsweise den Verwendern von PTXdist das Leben möglichst leicht zu machen, wirft der Befehl ptxdist make license-report eine Datei der für die jeweils im BSP verwendeten Programme geltenden Lizenzen in Kurzform und unter Umständen auch in Langform, sowie den Pfad zur Lizenzdatei in Langform aus.

Hat man sich den Lizenz-Report generiert und befolgt die gefundenen Lizenzbedingungen, ist man auf der sicheren Seite. Wird eine Lizenz nur mit ihrem Namen benannt oder bestehen Fragen bzgl. der Kompatibilität von Programmen mit jeweils unterschiedlichen Lizenzen, so ist SPDX (Software Package Data Exchange) hilfreich, wo alle gängigen Lizenzen mit ihrem Lizenztext gelistet sind.

Da viele Entwickler Skripte verwenden, welche Lizenztexte vergleichen, ist es sinnvoll, für gleichen Inhalt auch stets den gleichen Wortlaut zu verwenden. Es gibt bereits für so ziemlich jeden Anwendungsfall eine Lizenz, zum Beispiel gelistet bei choosealicence. Wann immer möglich, sollte eine bereits existierende Lizenz verwendet werden. Wenn eine individuelle Lizenz absolut notwendig ist, ist das Entwerfen des Lizenztextes jedenfalls der falsche Zeitpunkt, um mit einem originellen Wortlaut zu glänzen.

Und was sind die Folgen?

FOSS-Programme und all die daraus entstehenden Vorteile gibt es nur mit Lizenzen. Dies liegt schlicht an unserer Rechtsordnung, die für jede intellektuelle Leistung alle Rechte beim Urheber sieht. Es ist somit Sache des Urhebers, wenn er seine Leistung für andere verwertbar machen möchte, diese Rechte an einzelne Personen oder die Allgemeinheit durch eine Lizenz abzugeben. Gibt es zu einer Leistung keine Lizenzbedingungen, hat demnach allein der Urheber die Rechte daran - sie ist für niemanden sonst nutzbar.

Andererseits gibt es Lizenzen, die darüber hinausgehen und durch bestimmte, auf den ersten Blick beschränkende, Bedingungen zusätzliche Voraussetzungen der Verwendung schaffen. Verbreitet ist die Pflicht, ein den Code verwendendes Programm unter den gleichen (oder vorbestimmten vergleichbaren) Bedingungen zu veröffentlichen. Hervorzuheben hierbei sind die sogenannten Copyleft-Lizenzen, welche an die Verwendung des unter Copyleft lizenzierten Codes ein ebenfalls unter Copyleft lizenziertes Endprodukt knüpfen. Sie verpflichten also insbesondere dazu, den Quellcode des Endprodukts (und auch den Quellcode eines möglicherweise darauf beruhenden weiteren Endprodukts) der Allgemeinheit zugänglich zu machen. Ob dies die kommerzielle Weitergabe des Endprodukts einschließt oder nicht, ist den jeweiligen Lizenzbedingungen zu entnehmen.

In gewisser Weise trickst Copyleft das Copyright aus: Mit den Möglichkeiten des Copyright, mit dem eine Leistung eigentlich vor dem Zugang der Allgemeinheit geschützt werden soll, wird gerade die Zugangsmöglichkeit festgesetzt. So wie wir unter Hacking den kreativen Umgang mit Technik verstehen, so ist Copyleft kreativer Umgang mit dem Recht: die vorhandenen Möglichkeiten des Urheberrechts werden vollends und rechtlich einwandfrei genutzt, um einen durch den Gesetzgeber nicht beabsichtigten Zweck zu verfolgen.

Der Vorteil dieser Lizenzarten ist die stetige Weiterverbreitung von Open Source Code, sodass jeder auf eine stetig wachsende Basis von Programmen zurückgreifen kann. Der offensichtliche Nachteil ist, dass unter den gleichen Lizenzbedingungen veröffentlicht werden muss und Entwickler, welche proprietären Code entwickeln möchten, bewusst benachteiligt werden. Dies wird auch Copyleft-Effekt genannt und ist bei der Verwendung von FOSS-Code, welcher unter Umständen unter einer Copyleft-Lizenz lizenziert ist, unbedingt zu beachten.

Die obige Auflistung der Lizenzen soll als unvollständiges Beispiel verstanden werden.

Selbstverständlich kann man für Software Creative-Commons-Lizenzen oder für sonstige kreative Werke eine eher für Software typische Lizenz verwenden. Da es sich um vorgefertigte Lizenzen handelt, wären in dem Fall jedoch gegebenenfalls nicht alle typischen Problematiken abgedeckt und an anderer Stelle würden ausführlich Themen behandelt, die typischerweise gar nicht vorliegen.

Copyleft-Programme ergeben jedoch auch mit Verwendung von proprietärem Code keine Probleme, soweit nicht ein gemeinsamer Prozess erzeugt wird, denn lediglich bei der Vermischung mit fremdem Code liegt überhaupt ein bearbeitetes Werk (derivative work) im Sinne des Urheberrechts vor, über welches der ursprüngliche Rechteinhaber entscheiden darf. Technisch eigenständige Programme werden durch Copyleft-Lizenzen also nicht beeinflusst, selbst wenn sie gleichzeitig (aber unabhängig) und auf demselben System laufen. Gleiches gilt für sonstige zueinander inkompatible Lizenzen. Wichtig ist für Embedded-Systeme mit Open-Source-Komponenten also insbesondere, dass die proprietäre Software auf dem obersten Layer läuft, welches bei der die Lizenzverpflichtungen erfüllenden Veröffentlichung weggelassen wird, und das System somit auch ohne den proprietären Teil einwandfrei funktioniert. Sowohl PTXdist als auch Yocto beinhalten standardmäßig diese Layeroption. Entwickler sollten sicherstellen, dass das Layering entsprechend eingehalten wird. Keinesfalls darf auf die Veröffentlichung der Open-Source-Komponenten und daraus abgeleiteter Software verzichtet werden, um die proprietären Komponenten zu schützen. Dies stellt eine Rechtsverletzung dar und ist zudem leicht zu vermeiden.

Während Lizenzen zwar in der FOSS-Welt sehr präsent sind, sind sie bei weitem keine Eigenheit von Freier und Open-Source-Software. Lizenzen und das daraus folgenden Lizenzmanagement sind also stets notwendig, um überhaupt von fremdem Code zu profitieren. Dies muss die Sicherstellung der Kompatibilität von verwendeten Lizenzen untereinander und zu der beabsichtigten Endlizenz beinhalten. Aber letztlich ist all das kein Hexenwerk und ist mit den vorhandenen Werkzeugen gut umsetzbar.