FOSS-Lizenzen im Ăśberblick: Die feinen Unterschiede
Freie Software ist eine feine Sache – verschiedene Lizenztypen können aber ausbremsen, wenn die Auflagen nicht zum Einsatz passen. Ein Überblick.
(Bild: Midjourney, Collage: iX)
- Manuela Astrid Weixlbaumer
Die Vorteile von Free and Open Source Software (FOSS) sind schnell erläutert: Sie macht qualitativ hochwertige, von vielen Parteien getestete Softwarekomponenten verfügbar – die man im Optimalfall schnell in eigene Projekte einbauen kann. Darunter liegt ein idealistisches Fundament, welches Information zu einem Allgemeingut erklärt, das frei für alle verfügbar sein sollte. Richard M. Stallmann, Gründer der Free Software Foundation (FSF) und Initiatior des GNU-Projekts, kann als geistiger Vater der mittlerweile schon vierzig Jahre alten Bewegung gelten.
Für Entwickler und Entwicklerinnen ist das erst einmal eine praktische Sache – im Unternehmenskontext kann die Verwendung von FOSS aber anecken und Fragen aufwerfen. Die Lizenz-Landschaft für freie Software ist im Wandel, es gibt Abstufungen und Folgewirkungen. Immer wieder stand der Copyleft-Effekt im Schlaglicht: Offene Software, die gemeinsam mit proprietärer eingesetzt wird, "infiziere" mit ihrer Lizenz – die das Offenlegen von Quellcode erfordert – auch die geschlossenen Teile eines hybriden Produkts. In vielen Unternehmen wünscht man sich daher mittlerweile Safelists. Sie geben an, welche Lizenzen einzusetzen sind, worin sie sich unterscheiden und in welchen Bereichen erhöhte Sorgfalt geboten ist.
Eine kurze Definition
FOSS dient als der neutrale Sammelbegriff für Free and Open Source Software – er vereint den liberal-idealistischen Ansatz von Richard M. Stallman mit dem eher pragmatischen Einschlag von Linus Torvalds. FOSS bedeutet, dass Software frei und ohne Zahlung von Lizenzgebühren verwendet werden kann. Und der Source Code ist frei zugänglich, die Nutzer dürfen die Software verändern und weitergeben.
Nah verwandt mit FOSS sind Freeware, Shareware und Public Domain. Sie unterscheiden sich aber zum Teil signifikant von FOSS, insbesondere Free- und Shareware, die oft kommerzieller Software zugeordnet werden. Kommerzielle Software, proprietäre Software und Closed Source stehen FOSS dementsprechend gegensätzlich gegenüber. FOSS kennt drei Hauptkategorien von Lizenzen: strenge Copyleft-Lizenzen, Lizenzen mit eingeschränktem Copyleft und permissive Lizenzen.
Strenges Copyleft
Copyleft ist so etwas wie der kleine Bruder des Copyrights, wobei es im Gegensatz zum Copyright die Freiheit regelt, zu kopieren, zu verändern und zu verbreiten. Dabei taucht das Copyleft nicht nur im Softwarebereich, sondern auch generell im Bereich urheberrechtlicher Lizenzen auf. In Bezug auf FOSS bedeutet Copyleft, dass Software, die unter einer Copyleft-Lizenz steht oder von ihr abgeleitet ist (derivative work bzw. abgeleitetes Werk), ausschließlich unter den Lizenzbedingungen der FOSS-Lizenz weiterverbreitet werden darf. Der Begriff des abgeleiteten Werks ist dabei das maßgebliche Kriterium, ob Copyleft eintritt oder nicht.
In der Praxis heißt das, dass die Software wieder unter der gleichen Copyleft-Lizenz verbreitet werden muss. Je nach Lizenztext muss das dieselbe Lizenz sein oder kann auch eine spätere Version referenzieren – so ist es beispielsweise bei der GPL (GNU General Public License), die es mit "only"- oder "or-later"-Auflagen gibt.
Es ist somit nicht möglich, eine Copyleft-Software unter eine permissive oder proprietäre Lizenz zu stellen. Die Software bleibt für die Community erhalten – und letztere ist ebenfalls befugt, sie unter den Lizenzbedingungen zu modifizieren und weiterzuverbreiten.
In Unternehmen kann das erhebliche Auswirkungen haben, da mit Copyleft-Lizenzen auch Verpflichtungen wie die Offenlegung des Quellcodes einhergehen – der berüchtigte "virale Effekt". Je nach Umfang und Qualität der verbundenen proprietären Komponenten kann das für Unternehmen unverantwortlich sein, weil so potenziell Sicherheitslücken oder Betriebsgeheimnisse an die Öffentlichkeit gelangen könnten. Ein Paradebeispiel für eine Copyleft-Lizenz ist die GPL-2.0, ihre überarbeitete Version GPL-3.0, sowie die AGPL-3.0, die CPL-1.0 und die EPL-1.0.
Die GPL-2.0 als Standard
Der Klassiker – und besonders praxisrelevant – ist dabei die GPL-2.0, unter der auch der Linux Kernel lizenziert ist. Durch zahlreiche Judikaturbeispiele hat sie sich mittlerweile zu einem Standard entwickelt. Die erste bahnbrechende Entscheidung diesbezüglich war in Deutschland die des Landgerichts München I (Az. 21 O 6123/04 vom 19.5.2004), die der GPL-2.0 den Status von AGB zuerkannte und ihre Wirksamkeit in Deutschland bestätigte. Die 2007 eingeführte GPL-3.0 ergänzte daraufhin bestehende Lücken in der GPL-2.0, beispielsweise im Hinblick auf Tivoisierung, die mit der GPL-3.0 wesentlich erschwert wird. Dabei handelt es sich um das Verbauen von proprietärer Software auf Geräten, die ursprünglich mit freier Software liefen.
Die Anforderungen der GPL-2.0 und GPL-3.0 gelten für alle Versionen der Programme, die unter den Lizenzen vertrieben werden. Das bedeutet, dass jede Weitergabe eines Programms, ob unverändert oder modifiziert, den Lizenzbedingungen entsprechen muss. Zu den zentralen Verpflichtungen gehören:
- Die Auslieferung des Lizenztextes mit jeder Programmkopie. Das ist in Papierform oder als Textdatei möglich, ein Link auf den Lizenztext im Internet ist hingegen nicht ausreichend.
- Das Anbringen eines Copyright-Vermerks bei Weitergabe jeder Programmkopie. Hier sollte man sich am Beispieltext der GPL orientieren.
- Das Schaffen von Zugänglichkeit zum Quellcode. Wenn ein Programm kompiliert im Objektcode oder als Executable ausgeliefert wird, muss auch hier der entsprechende Quellcode zugänglich sein. Das kann durch Mitlieferung des vollständigen Quellcodes auf einem Datenträger, durch ein schriftliches Angebot zur Lieferung (written offer) oder durch die Bereitstellung des Codes auf der Website, auf der das Programm vertrieben wird, erfolgen.
Lizenzen mit eingeschränktem Copyleft
Unter Lizenzen mit eingeschränktem Copyleft fällt insbesondere die GPL mit ihren Ausnahmen wie der Linking Exception oder der Classpath Exception. Ein Paradebeispiel dafür ist die LGPL (Lesser General Public License), die es ebenfalls in mehreren Versionen gibt. Sie sieht Ausnahmen vom strengen Copyleft bei dynamischer Verlinkung von Programmbestandteilen, insbesondere von Bibliotheken, vor. Eine dynamische Verlinkung – im Gegensatz zur statischen Verlinkung – verhindert demnach, dass ein abgeleitetes Werk entsteht, die Klausel ist also entscheidend für das Auslösen des Copylefts.
Hier entsteht nur eine lose Verbindung zwischen zwei Softwarekomponenten, die für sich bestehen bleiben. Solche Ausnahmen können so ein starkes Copyleft zu einem schwachen Copyleft machen. Sie zeigen auch deutlich, wie ausschlaggebend die technische Umsetzung, beispielsweise in Form einer Verlinkung, für die Geltung von Lizenzbestimmungen sein kann.
Permissive Lizenzen
Die prominentesten Vertreter der permissiven Lizenzen sind unter anderem die MIT-Lizenz, die BSD-Clauses oder die Apache-Lizenzen. Es handelt sich dabei um Lizenzen ohne Copyleft-Klausel und mit geringeren Lizenzanforderungen. Die Apache-Lizenz ist in mehreren Versionen verfĂĽgbar. Sie ordnet bei abgeleiteten Werken kein Copyleft an, verpflichtet aber dennoch zum Einhalten von bestimmten Lizenzanforderungen wie dem Anbringen von Copyright-Vermerken, dem BeifĂĽgen des Lizenztextes und eines Haftungsausschlusses (Disclaimer).
Die MIT-Lizenz ist extrem liberal, ihre einzige Bedingung ist das Bereitstellen des Lizenztextes und des Copyright-Vermerks. Entwickler können die modifizierte Software also auch unter einer neuen Lizenz veröffentlichen, solange die Bedingungen der permissiven Lizenz erfüllt sind – wie die Beibehaltung des Copyright-Vermerks und Lizenztextes. Das kann eine andere Open-Source-Lizenz oder aber eine proprietäre Lizenz sein.
In der Regel lassen sich permissive Lizenzen auch untereinander kombinieren. Dabei hat Kompatibilität von Lizenzen eine erhebliche Praxisrelevanz: Wenn Lizenz A zum Beispiel etwas ermöglicht, was Lizenz B ausschließt, sind sie nicht miteinander vereinbar – insbesondere ist das wieder im Copyleft-Bereich häufig der Fall.
Praxistipps
Wenn sich ein Unternehmen nun damit auseinandersetzt, wie und welche Lizenzen es verwendet, dann ist eine genaue Dokumentation (Bill of Materials, BOM) im Vorhinein unerlässlich. Sie gibt schließlich die Auskunft über die eingesetzten FOSS-Komponenten in einem Produkt. Als Mindestanforderung gibt sie eine eigene Komponentenbezeichnung mit deren FOSS-Lizenzen in der jeweiligen Version an. Eine Safelist kann helfen, sollte aber nur als Orientierungshilfe dienen.
Wichtig ist natürlich auch die Instruktion des Personals: Juristisch betraute Personen im Betrieb bringen im Idealfall grundsätzliches Interesse am Programmieren mit, während zumindest eine Person im jeweiligen Entwicklerteam auch ein Auge auf die Lizenzierung der Komponenten hat, die das Team verwendet. Der Markt hält hier auch Scanning-Werkzeuge bereit, die dabei helfen, FOSS zu analysieren – im Zweifelsfall helfen solche Werkzeuge zwar, Rechtssicherheit herzustellen, sie sind aber nicht als alleiniges Entscheidungsinstrument geeignet. Die letzte Prüfung muss daher immer eine verantwortliche Person durchführen.
Es wird dabei stets auf die Frage hinauslaufen: "Wie können wir die FOSS-Komponente so in das Projekt einbauen, dass wir lizenzkonform agieren?" Und wenn das nicht möglich ist, dann spalten sich die Optionen in zwei Pfade auf: Gibt es eine Alternative unter Einbeziehung einer kommerziellen oder permissiven Lizenz? Oder sollen wir die benötigte Komponente selbst programmieren?
(kki)
