Luca-App versus Open Source
Die Luca-App enthält Code aus einem Open-Source-Projekt, hat aber dessen Lizenz verletzt. Die zugehörige Meldung bestimmte die Schlagzeilen der vergangenen Wochen. Doch was genau ist eigentlich Open Source, was ist der Unterschied zu Freier Software, und was lässt sich über Open Source lernen?
- Golo Roden
Die Luca-App enthält Code aus einem Open-Source-Projekt, hat aber dessen Lizenz verletzt. Die zugehörige Meldung bestimmte die Schlagzeilen der vergangenen Wochen. Doch was genau ist eigentlich Open Source, was ist der Unterschied zu Freier Software, und was lässt sich über Open Source lernen?
Die Luca-App, eigentlich als Ergänzung zur Corona-Warn-App und für das Nachverfolgen von Kontaktpersonen während der Pandemie gedacht, ist regelmäßig mit negativen Aspekten in den Schlagzeilen. Das betrifft nicht nur das fragwürdige Konzept der App, sondern auch den Datenschutz – und, besonders interessant für die Entwickler-Community, zuletzt auch Lizenzverletzungen.
Inzwischen wurden Fehler eingeräumt und am Code nachgebessert, doch die Frage ist: Was war überhaupt passiert? Der eigentliche Vorfall war aus technischer Sicht überschaubar, juristisch und moralisch hingegen kein Kavaliersdelikt: Die Entwickler der Luca-App haben Code aus einem Open-Source-Projekt übernommen, ohne deren Lizenz- und Quellenangaben regelkonform zu übernehmen.
Unter anderem wurde die ursprüngliche Open-Source-Lizenz entfernt, was nicht nur einer Lizenzverletzung entspricht, sondern auch dadurch einen besonders faden Beigeschmack erhält, da die App kommerziell vertrieben wird – allein das Bundesland Mecklenburg-Vorpommern hat die App für knapp eine halbe Millionen Euro lizenziert. Der Vorwurf war daher, dass man sich auf Kosten von Open Source bereichere.
Da ich kein Jurist bin, möchte ich den Vorfall nicht aus rechtlicher Sicht bewerten, aber ihn doch zum Anlass nehmen, um über Open Source und die damit verbundenen Lizenzen zu schreiben. Doch was ist Open Source überhaupt? Und was unterscheidet Open-Source-Software von Freier Software?
Ein Blick zurĂĽck
Für die Antworten auf diese Fragen muss man in den 1970er-Jahren beginnen. Damals war es üblich, dass Quellcode getauscht und weitergegeben wurde – auch an Anwenderinnen und Anwender von Software. Das änderte sich mit Beginn der 1980er-Jahre, als proprietäre Software mehr und mehr die Norm wurde.
Der inzwischen aufgrund verschiedener Aussagen bezüglich sexuellen Missbrauchs von Minderjährigen umstrittene US-amerikanische Informatiker Richard Stallman, der damals am MIT tätig war, beschloss, als Gegenbewegung ein freies, aber Unix-kompatibles Betriebssystem zu entwickeln. Dieses Betriebssystem nannte er "GNU" (ein rekursives Akronym, das für "GNU's Not Unix" steht).
1983 gründete er unabhängig vom MIT das GNU-Projekt, dessen wichtigstes Ziel das Bewahren der sozialen, ethischen und politischen Freiheit sein sollte – quasi eine gesellschaftliche Bewegung mit einem Schwerpunkt auf Software. Dafür definierte er vier Freiheiten für Anwenderinnen und Anwender:
- Die Freiheit, Programme auszufĂĽhren.
- Die Freiheit, Quellcode zu lesen und zu untersuchen.
- Die Freiheit, Code zu kopieren und weiterzugeben.
- Die Freiheit, Code zu verändern und weiterzugeben.
Software, die diesen vier Freiheiten genügt, nannte Stallman "Freie Software". Außerdem etablierte er den Begriff "Copyleft", der beschreibt, dass Veränderungen und Erweiterungen wiederum der ursprünglichen Lizenz unterliegen müssen – ein Effekt, der unter anderem dazu geführt hat, dass Microsoft die auf diesem Konzept basierende GPL-Lizenz im Jahr 2001 als "viral" bezeichnet hat.
Im Jahr 1985 gründete er schließlich zusätzlich die "Free Software Foundation" (FSF), eine Stiftung, die das GNU-Projekt juristisch, organisatorisch und letztlich auch finanziell unterstützen sollte. Vier Jahre später wurde dann die erste Fassung der "GNU General Public License" (GPL) veröffentlicht, deren wichtigstes Element das bereits angesprochen Copyleft ist.
Unabhängig davon erschien 1987 das Essay "The Cathedral And The Bazaar" des US-amerikanischen Informatikers Eric S. Raymond, in dem freie und proprietäre Software und deren jeweilige Vor- und Nachteile miteinander verglichen werden. Gemeinsam mit Tim O'Reilly und Bruce Perens prägte Eric S. Raymond den Begriff "Open Source", der zwar ähnliche Auswirkungen wie Freie Software anstrebt, das aber aus einer technischen und keiner gesellschaftlichen Motivation heraus macht.
1998 gründeten Eric S. Raymond und Bruce Perens die "Open Source Initiative" (OSI), für die schließlich auch die "Open Source Definition" (OSD) entwickelt wurde – eine Liste mit zehn Forderungen an Software. Vergleicht man diese zehn Forderungen mit den vier Freiheiten von Freier Software, stellt man fest, dass sie im Kern weitestgehend übereinstimmen.
Daher werden die Begriff "Freie Software" und "Open Source" heutzutage in der Regel als austauschbar angesehen, auch wenn sie es von den dahinter liegenden Idealen nicht sind. Beide Welten nutzen jedoch auch die gleichen Lizenzen, unter anderem die GPL. Mit diesen Lizenzen gehen für die Anwenderinnen und Anwender allerdings nicht nur Rechte, sondern auch Pflichten einher – und genau das haben die Entwickler der Luca-App ignoriert.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Was ist Open Source?
Wirft man einen näheren Blick auf die Definition des Begriffs "Open Source", stößt man zunächst auf drei charakteristische Merkmale, die von der OSI wie folgt festgelegt wurden:
- Anwenderinnen und Anwender erhalten Zugriff auf den Quellcode in menschenlesbarer Form.
- Anwenderinnen und Anwender erhalten das Recht, Code ohne Einschränkungen und ohne Zahlungsverpflichtung gegenüber dem Lizenzgeber kopieren, verbreiten und verwenden zu dürfen.
- Anwenderinnen und Anwender erhalten das Recht, Code verändern und weitergeben zu dürfen, unter anderem, um lernen und sich an der Weiterentwicklung beteiligen zu können.
Die zehn in der OSD enthaltenen zusätzlichen Anforderungen führen diese Merkmale noch weiter aus, lassen sich aber letztlich auf sie zurückführen. Wichtig zu beachten ist dabei, dass die OSD selbst keine Lizenz darstellt, sondern eher ein Maß für Lizenzen, um zu überprüfen, inwiefern diese tatsächlich dem Open-Source-Gedanken entsprechen.
Rechte und Pflichten zu definieren ist dabei eine Sache – es ist jedoch eine andere, sie auch rechtlich durchzusetzen. Wie das funktioniert, ist von Land zu Land unterschiedlich und lässt sich nicht pauschal beschreiben. Speziell in Deutschland spielt dabei das nicht übertragbare und stets an eine Person gebundene Urheberrecht eine wichtige Rolle – im angloamerikanischen Raum gibt es ein derartiges Recht hingegen nicht, dafür gilt dort das übertragbare Copyright.
Deshalb besteht im angloamerikanischen Rechtssystem der einfachste Weg, Code anderen als Open-Source-Software zur Verfügung zu stellen, darin, auf das eigene Copyright zu verzichten. Man spricht in diesem Fall davon, dass der Code "Public Domain", also sinngemäß "gemeinfrei" ist (wobei es den Begriff der "Gemeinfreiheit" im deutschen Rechtssystem ebenfalls gibt, der dort aber eine andere Bedeutung hat).
Letztlich lässt sich hier festhalten, dass es nicht ganz so einfach ist wie es zunächst scheint, einen rechtlich verbindlichen Rahmen zu schaffen, weshalb man sich dazu auf jeden Fall durch eine auf Open-Source-Recht spezialisierte Anwältin oder einen Anwalt beraten lassen sollte.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Lizenzen: GPL, MIT & Co.
In der Regel wird Code allerdings nicht als Public Domain, sondern unter einer der zahlreichen Open-Source-Lizenzen veröffentlicht. Diese Kategorien lassen sich im Wesentlichen in zwei Kategorien einteilen. Zum einen gibt es nämlich "freizügige", zum anderen auf dem Copyleft basierende Lizenzen.
Die bekannteste Copyleft-basierte Lizenz ist die bereits mehrfach erwähnte GPL, die inzwischen bereits in der dritten Version als GPLv3 vorliegt. Was die GPL erlaubt, ist dabei wenig überraschend, entspricht es doch im Wesentlichen den vier Freiheiten, die Richard Stallman für Freie Software definiert hat.
Ein interessanter Aspekt der GPL ist dabei, dass die kommerzielle Nutzung nicht verboten ist – es wird lediglich gefordert, dass Änderungen und Erweiterungen ihrerseits wiederum unter der GPL veröffentlicht werden. Genau das macht die GPL allerdings für die meisten Unternehmen eher uninteressant.
Einen "Ausweg" aus dem aus Sicht von Unternehmen bestehenden Dilemma, den Quellcode offenlegen zu müssen, besteht in einem unbeabsichtigten Schlupfloch in der Lizenz, dem sogenannten GPL Loophole: Wird Software nämlich ausschließlich über ein Netzwerk zur Verfügung gestellt, stellt das gemäß der GPL keine Verbreitung im eigentlichen Sinne dar, weshalb die GPL für SaaS-Angebote nicht im ursprünglichen Sinn greift.
Diese LĂĽcke schlieĂźt die Affero GPL (AGPL), die inzwischen ebenfalls in Version 3 vorliegt. Betrachtet man die Lizenzen aus der Perspektive der ursprĂĽnglich gewĂĽnschten gesellschaftlichen, moralischen und ethischen Forderungen nach Freiheit, ist die AGPL die "ehrlichste" Open-Source-Lizenz, da sie ein gegenseitiges Geben und Nehmen erzwingt: Wer von Open Source profitiert, muss der AGPL zufolge auch wieder Open Source anbieten.
Zusätzlich zur GPL und der AGPL sei noch die Lesser GPL (LGPL) erwähnt, die sich für den eigentlichen Code und dessen Erweiterungen wie die GPL verhält, die Nutzung aber in Verbindung mit anders lizenziertem Code gestattet. Die kommerzielle Nutzung von LGPL-Code ist dadurch in der Regel unproblematisch.
Im Gegensatz zu den bisher genannten Lizenzen stehen die sogenannten freizügigen Lizenzen, die auf das Copyleft verzichten, beispielsweise die MIT- und die BSD-Lizenzen. Insbesondere können abgeleitete Werke hier in aller Regel unter einer anderen Lizenz stehen, wobei diese explizit auch restriktiver sein können, zum Beispiel proprietär.
Aus dem Grund gelten MIT, BSD & Co. als unternehmensfreundlich, allerdings tragen sie auch nur bedingt dazu bei, Open Source zu fördern, da sie zwar erlauben zu nehmen, aber nicht auch fordern, etwas zu geben.
Während große Unternehmen sich das Entwickeln derartig lizenzierter Software durchaus erlauben können, sind diese Lizenzen gerade für kleinere Unternehmen häufig kein gangbarer Weg – denn in Open-Source-Projekte wird häufig viel Arbeit und Zeit investiert, und wenn dann ein größeres Unternehmen davon profitiert, ohne etwas zurückzugeben, ist das zumindest aus ethisch-moralischer Sicht durchaus fragwürdig.
Anders formuliert: Während es AGPL & Co. um das Fördern der Gemeinschaft geht, stehen MIT, BSD & Co. für kostenlose Software, auf Kosten derjenigen, die sie entwickeln.
Eine Möglichkeit, Open-Source zu machen und Software dennoch kommerziell zu vermarkten, besteht übrigens darin, den Code unter zwei Lizenzen zu veröffentlichen: Zum einen unter der AGPL, zum anderen unter einer proprietären Lizenz.
Tragen die Anwenderinnen und Anwender etwas zu Open-Source bei, können sie die AGPL-lizenzierte Variante wählen – verdienen sie Geld mit Closed-Source-Software (was ein durchaus legitimes Vorgehen ist), hat man über die proprietäre Lizenz aber einen Hebel, um Lizenzgebühren zu verlangen.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Warum Open-Source entwickeln?
Eine wichtige Frage bei alldem ist, warum man als Unternehmen oder als einzelne Entwicklerin oder einzelner Entwickler überhaupt Open Source entwickeln sollte. Natürlich gibt es auf diese Frage zahlreiche Antworten, die stark davon abhängen, wen man fragt.
Ein Grund kann beispielsweise sein, etwas zurückgeben zu wollen, da viele Unternehmen und die IT-Branche im Allgemeinen in einem Maß von Open-Source profitiert, dass es aus ethisch-moralischen Gründen schlichtweg das Richtige ist, sich aktiv zu beteiligen – ansonsten kippt das Verhältnis zwischen denen, die geben, und jenen, die nehmen, rasch und wandelt sich zu einem sehr einseitigen Ungleichgewicht.
Im Prinzip lässt sich festhalten, dass es etwas mit Demut und Respekt zu tun hat, Open-Source-Software zu entwickeln, und es eine Möglichkeit bietet, die Welt zu einem für alle besseren Ort zu machen (auch wenn sich das zugegebenermaßen sehr pathetisch anhört, schmälert das nicht den Wahrheitsgehalt der Aussage).
Ein weiterer Grund kann sein, dass man andere beflügeln und befähigen möchte, großartige Dinge umzusetzen. Im Idealfall entsteht so eine Aufwärtsspirale, weil jede und jeder einen Teil dazu beiträgt, dass andere vorankommen, wovon man letztlich selbst wieder profitiert.
Das Prinzip dahinter funktioniert ähnlich wie Bildung: Wer dazu beiträgt, Bildung zu verbreiten, befähigt die Gesellschaft, für alle mehr zu erreichen – und Code ist in dem Sinne nichts anderes als in eine strukturierte Form gebrachtes Wissen, das man mit anderen teilt.
Wenn man sich gegenseitig hilft und unterstützt, und jeder etwas nimmt, aber auch etwas gibt, schafft man Win-Win-Situationen für alle Beteiligten – und genau darum geht es letztlich bei einer Gemeinschaft, die fair und respektvoll miteinander umgeht. Jeder einzelne stellt dabei lediglich ein kleines Zahnrädchen dar, aber in der Summe macht sich diese Einstellung durchaus bemerkbar.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Was bei Open Source falsch läuft
Das Modell funktioniert gut, wenn es fair, ausgewogen und ausbalanciert ist, doch leider ist es das oft nicht. Es gibt viele Entwicklerinnen und Entwickler von großartigen und sehr erfolgreichen Open-Source-Projekten mit millionenfachen Downloads, die nach einigen Jahren erschöpft aufgeben, nicht mehr können und ausgebrannt sind. Dafür gibt es im Wesentlichen zwei Gründe, die sich allerdings auf die gleiche Ursache zurückführen lassen.
Das eine ist toxisches Verhalten durch einige Anwenderinnen und Anwender, die sich zum Beispiel bei auftretenden Fehlern im Ton vergreifen und Entwicklerinnen und Entwickler auf persönlicher Ebene angreifen, beschimpfen und im Extremfall sogar bedrohen. Das alles sind massive Grenzüberschreitungen, bei denen vergessen wird, dass es sich bei Open-Source um ein Geschenk handelt, dessen Nutzung auf anderer Menschen Arbeit und Zeit basiert.
Die Reaktion darauf sollten Dankbarkeit, Respekt und Demut sein – tatsächlich sind es jedoch häufig unverschämte Forderungen, Beschimpfungen und Hass. Wie so oft verhalten sich natürlich nur einige wenige so, aber die große Mehrheit der Community schweigt allzu oft und toleriert und fördert derartiges Verhalten dadurch implizit.
Der zweite Punkt sind Unternehmen, die von Open Source massiv profitieren, sich aber weigern, etwas zurückzugeben. Leider trifft man hier gelegentlich auf die Einstellung, dass das Produkt und auch der Support kostenlos zu sein hätten. Statt bei Problemen oder Wünschen im Zweifelsfall Geld für die Förderung von Open Source auszugeben, wird dann häufig lieber ein anderer kostenloser Ersatz gesucht.
Auch hier fehlen Dankbarkeit, Respekt und Demut. Das Paradoxe dabei ist, dass dieses Verhalten in der Regel nicht die kleinen und mittelständischen Unternehmen an den Tag legen, sondern viel eher große Konzerne, die es sich leisten könnten, Geld für Förderung von Open Source auszugeben. Hier wird dann in der Regel mit "Legal", "Compliance" & Co. argumentiert – nur um den Milliardengewinn ja nicht zu schmälern.
Auch hier gilt natürlich – und das soll explizit erwähnt sein – dass es nur einige wenige sind, die sich derart verhalten, seien es Konzerne oder KMUs. Bei immer mehr Unternehmen ist hingegen die Erkenntnis gereift, dass Open Source ein gegenseitiges Geben und Nehmen ist und nur derart langfristig und nachhaltig funktionieren kann.
Schöne Beispiele für derartige Förderung sind beispielsweise dediziert bereitgestellte Arbeitszeit zur Mitwirkung an Open-Source-Projekten, beispielsweise im Rahmen eines Open Source Friday, oder das Beauftragen von anderen Unternehmen, Open Source weiterzuentwickeln.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Fazit
Letztlich nützt es wenig, lediglich zu schimpfen. Der einfachste Hebel, um wirkungsvoll anzusetzen, ist, Open Source Ernst zu nehmen, und es aus Überzeugung zu machen – statt es nur als Marketingmaßnahme und als Aushängeschild zu sehen.
Das bedeutet zum einen, dass man sich den Entwicklerinnen und Entwicklern von Open-Source-Software gegenüber freundlich, höflich und respektvoll verhalten sollte, das man für deren Mühe und Zeit dankbar sein sollte, und dass man sich stets vergegenwärtigen sollte, dass das alles nicht selbstverständlich ist.
Zum anderen bedeutet es aber auch, die MIT & Co. nicht ohne nachzudenken als Lizenz für eigene Software zu wählen, weil es so bequem ist. Stattdessen wäre es eventuell ratsam, den Einsatz einer unbequemeren, aber der Gemeinschaft gegenüber vielleicht ehrlicheren Lizenz wie der AGPL den Vorzug zu geben. Das bedeutet nicht, dass das immer so sein muss – aber zumindest sollte die Wahl der Lizenz eine explizite und wohl überlegte Entscheidung sein und kein Zufallsprodukt.
Denn wenn das gegeben ist, dann kann eine Gemeinschaft plötzlich über sich selbst hinauswachsen und gemeinsam mehr erreichen – und das ist es letztlich, worum es bei alldem geht. ()
