1.3 Lektion 1

Zunächst einmal hat “frei” im Kontext freier Software nichts mit “kostenlos” zu tun, oder wie der Gründer der Free Software Foundation (FSF), Richard Stallman, es prägnant ausdrückt:

Unabhängig davon, ob Sie für die Software bezahlen müssen oder nicht, gibt es vier Kriterien, die freie Software ausmachen. Richard Stallman beschreibt diese Kriterien als “die vier wesentlichen Freiheiten”, deren Zählung bei Null beginnt:

Die Betonung des Freiheitsgedankens ist auch insofern konsequent als sich jede Freiheitsbewegung gegen etwas richtet, nämlich einen Gegner, der die postulierten Freiheiten unterdrückt, der Software als Eigentum betrachtet und unter Verschluss halten will. Im Gegensatz zu freier Software wird solche Software als proprietär (proprietary) bezeichnet.

Für viele sind freie Software und Open Source Software Synonyme. Die häufig verwendete Abkürzung FOSS für Free and Open Source Software betont genau diese Gemeinsamkeit. FLOSS für Free/Libre and Open Source Software ist eine weitere beliebte Begriffsvariante, die den Freiheitsgedanken auch für andere Sprachräume als den englischen unmissverständlich herausstellt. Betrachtet man allerdings Entstehung und Entwicklung beider Begriffe, lohnt sich eine Differenzierung.

Der Terminus freie Software mit der Definition der beschriebenen vier Freiheiten geht auf Richard Stallman und das bereits 1985 — also beinahe 10 Jahre vor der Entstehung von Linux — von ihm gegründete Projekt GNU zurück. Der Name “GNU is not Unix” beschreibt augenzwinkernd die Intention: GNU startete als Initiative, eine technisch überzeugende, aber bis dahin allein der Kontrolle von Konzernen unterliegende Lösung — nämlich das Betriebssystem Unix — von Grund auf neu zu entwickeln, der Allgemeinheit zur Verfügung zu stellen und mit der Allgemeinheit laufend zu verbessern. Die Offenheit des Source Code war dafür lediglich eine technisch-organisatorische Notwendigkeit — in ihrem Selbstverständnis ist die Free-Software-Bewegung aber bis heute eine soziale und politische — manche sagen auch ideologische — Bewegung.

Mit dem Erfolg von Linux, den kollaborativen Möglichkeiten des Internet und den Tausenden Projekten und Firmen, die in diesem neuen Software-Kosmos entstanden, trat der soziale Aspekt immer öfter in den Hintergrund. Die Offenheit des Quellcodes wurde von einer technischen Voraussetzung selbst zu einem Definitionsmerkmal: Sobald der Quellcode einsehbar war, galt die Software als Open Source. Die sozialen Motive wichen einem eher pragmatischen Ansatz der Softwareentwicklung.

Dieses Spannungsverhältnis besteht bis heute: Freie Software und Open Source Software arbeiten an derselben Sache, mit denselben Methoden und in einer weltweiten Community aus Einzelpersonen, Projekten und Firmen. Aber da sie soz. aus verschiedenen Richtungen — nämlich einer sozialen und einer pragmatisch-technischen — zusammengefunden haben, kommt es bisweilen zu Konflikten. Diese Konflikte entstehen, wenn die Ergebnisse der gemeinsamen Arbeit nicht den ursprünglichen Zielen beider Bewegungen entsprechen. Das geschieht vor allem dann, wenn eine Software zwar ihre Quellen offenlegt, aber nicht zugleich die vier Freiheiten der freien Software respektiert, wenn es also bespielsweise bei der Offenlegung, bei der Veränderung oder bei der Verbindungen mit anderen Software-Komponenten Beschränkungen gibt.

Welchen Bedingungen eine Software hinischtlich Nutzung, Weitergabe und Veränderung unterliegt, bestimmt die Lizenz, unter der die Software steht. Und weil Anforderungen und Motive sehr unterschiedlich sein können, sind im FOSS-Bereich zahllose verschiedene Lizenzen entstanden. Aufgrund des deutlich fundamentaleren Ansatzes der Free-Software-Bewegung nimmt es nicht Wunder, dass sie viele Open-Source-Lizenzen nicht als “frei” anerkennt und darum abgelehnt. Umgekehrt ist das aufgrund des deutlich pragmatischeren Open-Source-Ansatzes naturgemäß kaum der Fall.

Werfen wir im Folgenden einen kurzen Blick auf das tatsächlich sehr komplexe Gebiet der Lizenzen.

Die bereits erwähnte Free Software Foundation (FSF) hat mit der GNU General Public License (GPL) eine der wichtigsten Lizenzen für freie Software formuliert, die viele Projekte, z.B. auch der Linux-Kernel, nutzen. Darüber hinaus hat sie weitere Lizenzen mit fallspezifischen Anpassungen veröffentlicht, etwa die GNU Lesser General Public License (LGPL), die die Kombination von freier Software mit verändertem Code regelt, wobei der Quellcode für die Veränderungen nicht veröffentlicht werden muss, die GNU Affero General Public License (AGPL), die den Verkauf des Zugangs zu gehosteter Software regelt, oder die GNU Free Documentation License (FDL), mit der sie die freiheitlichen Grundsätze auf die Dokumentation von Software ausdehnt. Darüber hinaus spricht die FSF Empfehlungen für oder gegen Lizenzen Dritter aus, und angegliederte Projekte wie GPL-Violations.org gehen beispielsweise Verdachtsfällen nach, in denen es um die Verletzung freier Lizenzen geht.

Das Prinzip, nach dem sich eine freie Lizenz auch auf veränderte Varianten der Software überträgt, bezeichnet die FSF als Copyleft — im Gegensatz zu dem von ihr abgelehnten Prinzip des restriktiven Copyright. Die Idee ist also, die freiheitlichen Grundsätze einer Software-Lizenz möglichst uneingeschränkt auf künftige Bearbeitungen der Software zu übertragen, um nachträgliche Restriktionen zu verhindern.

Was naheliegend und einfach klingt, führt in der Praxis jedoch zu zum Teil erheblichen Komplikationen, weshalb das Copyleft-Prinzip von Kritikern häufig auch als “viral” bezeichnet wird, da es sich auf Folgeversionen überträgt.

Aus dem Gesagten folgt zum Beispiel, dass sich zwei Software-Komponenten, die unter verschiedenen Copyleft-Lizenzen stehen, nicht miteinander kombinieren lassen, da sich ja nicht beide Lizenzen gleichzeitig auf das Folgeprodukt übertragen lassen. Das kann sogar für verschiedene Versionen derselben Lizenz gelten!

Aus diesem Grunde fassen neuere Lizenzen oder Lizenz-Versionen das Copyleft oftmals nicht mehr so rigoros. Schon die genannte GNU Lesser General Public License (LGPL) ist in diesem Sinne ein Zugeständnis, um freie Software überhaupt mit “unfreien” Komponenten verbinden zu können, wie es zum Beispiel häufig bei (Programm-)Bibliotheken (engl. libraries) geschieht. Bibliotheken enthalten Unterprogramme oder Routinen, die wiederum von anderen Programmen genutzt werden. Das führt oftmals zu der Situation, dass proprietäre Software solche Routinen einer freien Bibliothek aufruft.

Eine weitere Möglichkeit zur Vermeidung von Lizenzkonflikten ist das Dual Licensing, bei dem eine Software unter verschiedenen Lizenzen steht, z.B. einer freien und einer proprietären. Ein typischer Anwendungsfall ist eine kostenlose Version einer Software, die nur unter Beachtung der Copyleft-Beschränkungen genutzt werden darf, und des alternativen Angebots, die Software unter einer anderen Lizenz zu beziehen, was den Lizenznehmer von bestimmten Einschränkungen befreit, und zwar gegen eine Gebühr, die zur Finanzierung der Entwicklung der Software verwendet werden könnte.

Es sollte also deutlich geworden sein, dass die Wahl der Lizenz für Software-Projekte mit viel Bedacht getroffen werden sollte, da davon die Zusammenarbeit mit anderen Projekten, die Kombinierbarkeit mit anderen Komponenten und auch die künfitge Ausgestaltung des eigenen Produkts abhängen. Das Copyleft stellt Entwickler dabei vor besondere Herausforderungen.

Auf Seiten der Open-Source-Bewegung ist es die 1998 von Eric S. Raymond und Bruce Perens gegründete Open Source Inititive (OSI), die sich maßgeblich mit Fragen der Lizenzierung beschäftigt. Sie hat auch ein standardisiertes Verfahren entwickelt, mit dem sie Software-Lizenzen auf ihre Übereinstimmung mit der von ihr formulierten Open Source Definition überprüft. Auf der Website der OSI finden sich aktuell mehr als 80 anerkannte Open-Source-Lizenzen.

Hier führt sie auch Lizenzen als “OSI-approved” auf, die dem Copyleft-Prinzip ausdrücklich widersprechen, allen voran die Gruppe der BSD-Lizenzen. Die Berkeley Software Distribution (BSD) bezeichnet eine ursprünglich an der Universität Berkeley entwickelte Variante des Betriessystems Unix, aus denen später wiederum freie Projekte wie NetBSD, FreeBSD und OpenBSD hervorgingen. Die diesen Projekten zugrundeliegenden Lizenzen bezeichnet man häufig als permissive (“freizügig”). Im Gegensatz zu Copyleft-Lizenzen verfolgen sie gerade nicht das Ziel, auch die Nutzungsbedingungen veränderter Varianten festzuschreiben. Das Höchstmaß an Freizügigkeit soll der Software vielmehr zu einer möglichst weiten Verbreitung verhelfen, indem allein den Bearbeitern der Software überlassen wird, wie sie mit den Bearbeitungen verfahren — ob sie sie beispielweise ebenfalls freigeben oder auch als Closed Source behandeln und kommerziell vertreiben.

Wie reduziert eine solch permissive Lizenz sein kann, beweist die 2-Clause BSD License, auch Simplified BSD License oder FreeBSD License genannt. Neben der standardisierten Haftungsklausel, mit der sich die Entwickler vor Haftungsansprüchen aus durch die Software verursachten Schäden schützen, besteht die Lizenz lediglich aus den folgenden zwei Regelungen (nicht offizielle Übersetzung):

Das erfolgreiche Entwicklungskonzept von FLOSS und die damit verbundenen technologischen Fortschritte sorgten dafür, dass man das Open-Source-Prinzip auch auf andere, nicht-technische Bereiche zu übertragen versuchte. Die Aufbereitung und Bereitstellung von Wissen wie auch das kreative Miteinander bei der Lösung komplexer Aufgaben gelten heute als Belege für das erweiterte, inhaltsbezogene Open-Source-Prinzip.

Damit entstand die Notwendigkeit, auch in diesen Bereichen verlässliche Grundlagen zu schaffen, nach denen Arbeitsergebnisse geteilt und bearbeitet werden können. Da die vorliegenden Software-Lizenzen dafür kaum geeignet waren, gab es zahlreiche Versuche, die die spezifischen Anforderungen von wissenschaftlichen Arbeiten bis hin zu digitalisierten Kunstwerken “im Geist von Open Source” in ähnlich griffige Lizenzen überführten.

Die heute mit Abstand wichtigste Initiative dieser Art ist Creative Commons (CC), die ihr Anliegen selbst wie folgt zusammenfasst:

Mit Creative Commons geht der Fokus der Rechtevergabe vom Distributor zurück auf den Urheber/Autor. Ein Beispiel: Im klassischen Verlagswesen überträgt ein Urheber meist sämtliche Verwertungsrechte (Druck, Übersetzung etc.) an einen Verlag, der im Gegenzug für die bestmögliche Verbreitung des Werks sorgt. Die deutlich veränderten Distributionswege des Internets versetzen nun den Urheber in die Lage, viele dieser Verwertungsrechte selbst auszuüben und selbst zu entscheiden, wie sein Werk genutzt werden darf. Creative Commons gibt ihm die Möglichkeit, dies einfach und juristisch verlässlich festzulegen, will aber mehr: Der Urheber wird ermutigt, sein Werk als Beitrag einem allgemeinen Prozess des Austauschs und der Zusammenarbeit zur Verfügung zu stellen. Anders als das traditionelle Copyright, das dem Urheber sämtliche Rechte sichert, die er nach Bedarf an andere überträgt, wählt der Creative-Commons-Ansatz den umgekehrten Weg: Der Urheber stellt sein Werk der Gemeinschaft zur Verfügung, kann aber aus einem Satz von Eigenschaften jene auswählen, die bei der Nutzung des Werks zu beachten sind — je mehr Eigenschaften er auswählt, desto restriktiver die Lizenz.

Und so fragt das “Wähle eine Lizenz”-Prinzip von CC einen Urheber schrittweise die einzelen Eigenschaften ab und generiert daraus die empfohlene Lizenz, die der Urheber zuletzt seinem Werk als Text und Icon zuweisen kann.

Zum besseren Verständnis, hier ein Überblick über die sechs von CC angebotenen Kombinationsmöglichkeiten bzw. Lizenzen: