Open Source: Freiheit, Verantwortung und Wahlmöglichkeiten

Quellcode ist die für Menschen lesbare Form von Software. Genau dieser Zugang unterscheidet Software, die man nur benutzen kann, von Software, die man untersuchen kann. Ohne die lesbare Form können Sie beobachten, wie ein Programm sich verhält, und den Autor um mehr bitten; mit ihr können Sie — oder jemand, den Sie beauftragen — sehen, warum es sich so verhält, welche Daten es überträgt, wo ein Fehler sitzt und wo eine Änderung hingehört.

Open Source beschreibt dabei nicht, wie Software entsteht, und ist auch kein Versprechen, dass der Code zufällig sichtbar ist. Es ist eine Reihe von Erlaubnissen, die eine Lizenz an die Software knüpft, und es gibt eine verbreitete schriftliche Definition dieser Erlaubnisse: Die Open Source Initiative pflegt sie und entscheidet damit, welche Lizenzen als Open Source gelten. Verlangt werden unter anderem die freie Weitergabe, die Verfügbarkeit des Quellcodes in der Form, die man zum Ändern tatsächlich braucht, das Recht auf veränderte und abgeleitete Fassungen, keine Einschränkung darauf, wer die Software wofür nutzt, und keine Bindung an eine bestimmte Technik oder Oberfläche.

Daraus folgt eine Unterscheidung, die in der Praxis wichtig ist: Eine Lizenz, die den Code lesbar macht, aber kommerzielle Nutzung oder das Teilen von Änderungen verbietet, ist quelloffen, aber nicht Open Source. Viel Software wird "offen" genannt, obwohl sie nur sichtbar ist.

Die Freiheitsbewegung formuliert dieselbe Idee konkreter, als vier Freiheiten: das Programm für jeden Zweck ausführen, seine Wirkungsweise untersuchen und es verändern, Kopien weitergeben und veränderte Fassungen verbreiten zu dürfen. Eine Lizenz gewährt diese Freiheiten und kann Bedingungen daran knüpfen — meist den Erhalt von Hinweisen oder dieselbe Lizenz für weitergegebene Änderungen.

Zwei Grundformen sind verbreitet. Permissive Lizenzen wie die hier verwendete Apache-Lizenz 2.0 stellen wenige Bedingungen: Nutzung, Veränderung und Weitergabe sind erlaubt, meist unter Erhalt der Urheberrechts- und Lizenzhinweise, und sie enthalten eine ausdrückliche Patentlizenz der Beitragenden. Copyleft-Lizenzen fügen eine Bedingung hinzu, die die Software für die Empfänger offen halten soll: Wer eine Fassung weitergibt, muss sie unter dieselbe Lizenz stellen. Die bekannteste Familie ist die GNU General Public License.

Copyleft ist nicht überall gleich, und die Unterschiede sind größer als das eine Etikett vermuten lässt. Meist löst die Weitergabe die Pflicht aus; bei einzelnen Lizenzen kann auch die Nutzung über ein Netzwerk sie auslösen — die GNU Affero General Public License verlangt dann zusätzlich, dass Nutzer den Quellcode der laufenden Fassung erhalten können. Das ist eine Eigenheit dieser Lizenzen, keine allgemeine Regel von Open Source. Was keine Open-Source-Lizenz verlangt, ist die Veröffentlichung Ihrer eigenen privaten Arbeit: Eine Änderung, die Sie für sich behalten und nicht weitergeben, löst keine dieser Pflichten aus.

Open Source wird oft so beschrieben, als hätte es in den späten 1990er-Jahren mit einer kleinen Gruppe begonnen. Genauer ist: Das Teilen und gemeinsame Verbessern von Quellcode ist fast so alt wie die Softwareentwicklung selbst. In den frühen Jahrzehnten der Datenverarbeitung wurde Software häufig von denen geschrieben, die sie nutzten, und Programme zirkulierten zwischen Anwendern; Forschungseinrichtungen behandelten geteilten Code als Normalfall. Erst als Rechner billiger und weiter verbreitet wurden und Software selbst zum Handelsgut wurde, verschwand diese Praxis: In den 1980er-Jahren war die überwiegende Mehrheit der Software proprietär.

Die Antwort darauf war das GNU-Projekt. Richard Stallman kündigte es im September 1983 an, die Arbeit begann im Januar 1984, und 1985 wurde die Free Software Foundation gegründet. Die GNU General Public License entstand aus einem konkreten Grund: Software sollte nicht in die Gemeinfreiheit entlassen werden, wo eine spätere Fassung proprietär werden könnte, sondern für alle Empfänger frei bleiben. 1991 begann Linus Torvalds mit einem Unix-ähnlichen Kernel, der zusammen mit dem fast vollständigen GNU-System ein frei nutzbares Betriebssystem ergab. Ein vergleichbarer Weg zeigt sich beim Webserver: Nachdem die Entwicklung des NCSA-HTTP-Daemons 1994 ins Stocken geraten war, koordinierten Webmaster ihre Patches, bildeten im Februar 1995 die Apache-Gruppe und veröffentlichten im April 1995 die erste Fassung — innerhalb eines Jahres war ihr Server der meistgenutzte der Welt. Das Projekt ging später in die Apache Software Foundation über, die seit 1999 einen gemeinnützigen Rahmen für solche Vorhaben bietet. Der Begriff "Open Source" selbst entstand am 3. Februar 1998 in Palo Alto, kurz nachdem Netscape am 22. Januar 1998 angekündigt hatte, seinen Browser-Quellcode freizugeben; veröffentlicht wurde er am 31. März 1998.

Aus dieser Geschichte folgt, was Open Source verlangt. Weitergabe ist an Bedingungen geknüpft, etwa den Erhalt von Hinweisen. Wartung ist dauerhaft: Ein Projekt lebt, weil sich jemand darum kümmert. Kompetenz wird irgendwo gebraucht, denn eine Lizenz beseitigt keine Wissenslücke. Verantwortung bleibt bei Ihnen: Keine Lizenz verpflichtet jemanden, Fehler für Sie zu beheben. Sicherheit ist nicht automatisch gegeben — Lesbarkeit ist nicht dasselbe wie Gelesenwerden. Und die Freiheit zu ändern bedeutet, Ihre Kopie zu ändern und Ihre eigene Fassung weiterzugeben; sie ist kein Anspruch darauf, dass eine Änderung in das Ursprungsprojekt aufgenommen wird. Ob das geschieht, entscheiden die Menschen, die es pflegen.

In diesem Zusammenhang bedeutet „frei“ Freiheit und nicht Preis. Im Englischen fallen beide Bedeutungen in dasselbe Wort, und deshalb steht die Unterscheidung am Anfang der meisten Missverständnisse: Ein Programm kann kostenlos sein und trotzdem unfrei — etwa wenn seine Lizenz untersagt, es weiterzugeben oder zu verändern. Und ein Programm kann frei sein und trotzdem Geld kosten, wenn Entwicklung, Betrieb oder Betreuung bezahlt werden. Das ist keine Haarspalterei: Wer beides trennt, kann erklären, warum für Foundation keine Lizenzgebühr verlangt wird und warum trotzdem jemand Zeit, Arbeit und Kosten trägt.

Freie Software und Open Source bezeichnen in der Praxis nahezu dasselbe: dieselben Lizenzen, dieselben Programme, dieselbe Weitergabe. Der Unterschied liegt in der Betonung. Die Tradition der freien Software, geprägt von Richard Stallman und der Free Software Foundation, stellt die Freiheit der Nutzerinnen und Nutzer in den Mittelpunkt und begründet sie ethisch. Die Open-Source-Bewegung, seit 1998 mit der Open Source Initiative verbunden, betont die praktischen Vorteile: offene Entwicklung führt zu besser prüfbarer, anpassungsfähigerer und oft verlässlicherer Software, und diese Begründung lässt sich auch dort vertreten, wo ethische Argumente nicht den Ausschlag geben.

Beide Strömungen erkennen dieselben Lizenzen an, und ihr Streit betrifft nicht, was Sie mit der Software tun dürfen. Wer eine Entscheidung treffen will, muss deshalb nicht Stellung beziehen: Entscheidend ist, welche Lizenz der Software beiliegt und was sie verlangt.

Die meisten offenen Projekte beginnen klein und persönlich: Jemand stößt auf ein Problem, schreibt eine Lösung, die für die eigene Arbeit reicht, und stellt fest, dass andere dasselbe Problem haben. Dazu kommen Gründe, die mit dem Projekt selbst wenig zu tun haben — lernen wollen, die eigene Arbeit brauchbar machen, Anerkennung unter Fachleuten.

Bei Organisationen sind die Gründe nüchterner. Eine Bibliothek, die viele brauchen, lässt sich gemeinsam wirtschaftlicher pflegen, als sie in jeder Firma neu zu bauen. Hinzu kommen der Zugang zu Fachkräften, Einfluss auf die Richtung eines Standards, auf den man sich verlässt, und das Argument, dass mit öffentlichen Mitteln finanzierte Software öffentlich verfügbar sein sollte.

Ein weiterer Grund ist Unabhängigkeit. Wenn die Grundlage, auf der ein Betrieb arbeitet, von einem einzigen Anbieter abhängt, ist das ein Risiko. Offener Code und eine offene Lizenz erlauben, die Arbeit fortzusetzen, wenn sich die Umstände ändern.

Die erste Fassung eines Programms ist der kleinste Teil der Arbeit. Der größte Teil besteht aus dem, was danach kommt: Fehlerberichte lesen, Fragen beantworten, Abhängigkeiten aktualisieren, auf Sicherheitslücken reagieren, Dokumentation nachführen, Veröffentlichungen vorbereiten und prüfen, dass eine Aktualisierung nichts Bestehendes beschädigt. Diese Arbeit fällt unabhängig davon an, ob die Software Geld kostet, und sie ist der Grund, warum „kostenlos“ den Erwerb beschreibt und nicht den Betrieb.

Oft hängt ein Projekt, das viele nutzen, an wenigen Personen, manchmal an einer einzigen. Das ist kein theoretisches Risiko, sondern der häufigste Grund, warum Arbeit an offener Software ins Stocken gerät: Wer sie bisher getragen hat, tut es nicht mehr, und für die Nachfolge gibt es keinen Vertrag. Aus dieser Lage folgen zwei ehrliche Aussagen. Erstens kann niemand zusichern, dass ein Projekt in der vorliegenden Form weiterlebt; Lizenzen sichern die Weitergabe, nicht die Betreuung. Zweitens wirkt Unterstützung am stärksten, wo sie Zeit kauft: Eine verlässliche monatliche Unterstützung ermöglicht es jemandem, sich einen festen Teil der Arbeitszeit um das Projekt zu kümmern, statt nur die Reste zwischen anderen Aufgaben. Für Foundation heißt das konkret: Das Projekt veröffentlicht regelmäßig, prüft seine Veröffentlichungen und legt offen, was es kann und was nicht — und es lebt davon, dass diese Arbeit jemanden hat.

Wie jedes offene Projekt wird auch Foundation ohne Gewähr bereitgestellt. Keine Lizenz verpflichtet dazu, einen bestimmten Fehler zu beheben, eine Frage zu beantworten oder kommerziellen Support zu leisten. Was Sie dafür erhalten, ist die Möglichkeit, selbst zu handeln: selbst reparieren, jemanden beauftragen, etwas ersetzen, das nicht passt. Welche Fassung Sie einsetzen, wann Sie aktualisieren und wie Sie Sicherungen prüfen, entscheiden Sie — und genau daraus ergibt sich die Verantwortung, die zu dieser Freiheit gehört. Klare Wahlmöglichkeiten sind nützlicher als Zusagen, die niemand einhalten kann.

Mitwirken ist nicht an eine Rolle gebunden. Ein brauchbarer Fehlerbericht mit erwartetem und tatsächlichem Verhalten, Schritten zum Nachstellen und der verwendeten Fassung verkürzt den Weg zur Behebung. Ein Vorschlag, der die Aufgabe beschreibt statt nur eine Lösung, hilft bei der Einordnung. Verbesserungen an der Dokumentation und Übersetzungen erreichen unmittelbar die nächste Leserin, und wer anderen in offenen Diskussionen antwortet, nimmt allen denselben Aufwand ab. Code und Tests sind eine weitere Möglichkeit, keine Voraussetzung.

Auch Unterstützung ist freiwillig, und sie ist nicht dasselbe wie eine Dienstleistung. Eine Spende an das Projekt hilft der Arbeit, ohne einen Anspruch auf Leistung zu begründen; wer Umsetzung, Betrieb oder Beratung kauft, schließt dagegen einen klaren Auftrag mit Umfang und Verantwortung. Foundation funktioniert ohne beides. Wer das Projekt nutzt und nichts weiter tut, macht nichts falsch.

Foundation wird unter der Apache-Lizenz 2.0 veröffentlicht, und die Wahl folgt aus dem Zweck: eine wiederverwendbare Grundlage für informative Unternehmenswebsites. Dieser Zweck wäre mit einer Lizenz unvereinbar, die eine Übernahme erlaubt und dann einschränkt, was damit möglich ist. Apache-2.0 erlaubt die unabhängige, private und kommerzielle Nutzung, enthält eine ausdrückliche Patentlizenz und überträgt gerade kein ausschließliches Eigentum: Foundation bleibt für alle Open Source. Fremdes Material, das mitgeliefert wird, wird nicht umlizenziert, und an Name, Logos oder Branding von Provelopment entstehen keine Rechte.

Entscheidend ist dabei nicht das Versprechen, sondern die Bauweise. Eine Lizenz kann eine Website nicht verschiebbar machen; eine Plattform schon, oder eben nicht. Deshalb ist Foundation so gebaut, dass Inhalte, Konfiguration und Gestaltung als Dateien in Ihrem eigenen Repository liegen, dass Anpassungen nicht im Kern der Plattform stattfinden, dass Abhängigkeiten von Diensten hinter austauschbaren Schnittstellen sitzen und dass die Plattform selbst öffentlich dokumentiert ist. Das macht Unabhängigkeit nicht automatisch, aber ausübbar — und Unabhängigkeit, die man nicht ausüben kann, ist keine.

Die Wahl bleibt bei Ihnen: unabhängig nutzen, verbessern, weitergeben, mitwirken, fördern oder einfach daraus lernen. Es gibt keinen einzig richtigen Weg, und nichts davon ist verpflichtend. Wenn Sie Hilfe möchten, kann Provelopment sie anbieten — als Dienstleistung und nicht als Bedingung.