Guten Morgen und herzlich willkommen zum ersten Talk der VSCON 2021 hier in Hörsaal 5. Hier ist jetzt der Falk Schaile, der erzählt euch was zum Lizenzwechsel bei freier und Open Source Software.

Und ich gehe jetzt mal kurz darauf ein, wie die Q&A hinterlaufen wird. Und zwar ist es so, dass es hier auf der Event-Seite gibt, könnt ihr auf den Vortrag klicken, ihr seht ja oben den Stream und unten gibt es diesen Knopf für die Videokonferenz. Das ist das, wo wir hier gerade drin sind, was ihr jetzt auf dem Bildschirm wahrscheinlich mehr oder weniger so seht.

Da könnt ihr reinkommen, da gibt es einen Chat, da könnt ihr die Fragen stellen. Und die werden dann am Ende moderiert und dem Falk gestellt, sodass ihr auf dem Stream auch mitbekommen, wenn die Leute oder was die Leute hier so fragen. Und ja, ich wünsche euch viel Spaß und ich stelle mich jetzt schon unter mein Video aus. Viel Spaß dabei.

Ja, recht vielen Dank. Herzlich willkommen hier am Samstagmorgen zu einem rechtlichen Thema. Ich hoffe, es wird nicht zu trocken. Ja, unser Thema ist jetzt Lizenzwechsel bei freier und offener Software,

cloudbasierte Betreibermodelle als Opfer des Marktes. Also es geht darum, welche Probleme wohl entstehen, wenn Open Source oder FOSS-Software in der Cloud genutzt wird.

Wer Heise Online regelmäßig liest, wird also da das eine oder andere mitbekommen haben. Wir gucken uns also nochmal an, so den Anlass am Anfang. Dann gibt es von mir nochmal eine kleine Druckbetankung, was sind freie und offene Lizenzen.

Und dann schauen wir uns mal an, in welchem Rahmen sich diese Projekte bewegt haben oder bewegen, die hier den Lizenzwechsel vorgenommen haben, weil sie irgendwie mit den Randbedingungen meinten, nicht klar zu kommen.

Ihr merkt schon, ich formuliere sehr vorsichtig. Und schließlich, dann wird es richtig trocken, gucken wir uns die einzelnen Aspekte in den Lizenzen nochmal an, um zu schauen, wie ist das mit der Einordnung in den FOSS-Bereich.

Und ja, welche Regeln treffen denn eigentlich diese einzelnen Lizenzen, um die es da geht. Okay, dann würde ich sagen, starten wir frischen Mutes in den Vortrag.

Zunächst also Einleitung und wir schauen uns an, was ist denn so geschehen. Den Anfang hat 2018 eine Firma mit Namen Neo Technology gemacht, die ein Produkt Neo4G herstellen

und haben da meinten, sie sind ein Open Source oder ein FOSS-Projekt und müssen ihre Lizenz ändern, und zwar zu der GNU AGPL und haben diese dann noch, und das ist der Knackpunkt, mit einer Commons-Close versehen.

Das schauen wir uns an. Wer sich aber bei GitHub mal die Lizenzgeschichte oder eben die License TXT anguckt, die haben da auch vorher schon sehr spezielle Sachen gemacht.

Da finden sich dann Sachen so, wir stellen unsere Daten oder unsere Software unter AGPL, aber wenn ihr mit uns eine Enterprise, einen Enterprise-Vertrag habt, also eine Softwarepflege oder so,

dann gilt für euch die GPL, die AGPL nicht. Ist schon mal sonderbar. Okay, dann geht es weiter. Redis Labs mit ihrer Software sagten auch,

nee, mit der GNU AGPL, APGPL kommen wir nicht so richtig klar. Wir wechseln zu einer Apache-Lizenz mit Commons-Close. Jedenfalls für ein paar Softwarebibliotheken.

Die eigentliche Datenbanksoftware, die haben sie weiter unter der BSD-Lizenz gelassen. So, das war so der Auftakt im Jahre 2018. Dann war etwas Ruhe oder ich hab die Artikel, nee, dann ging es noch weiter, 2018. Die Firma Mongo mit ihrem Produkt MongoDB sagt,

oh, mit GNU APGPL sind wir auch nicht so glücklich. Wir wechseln zur Surfersite Public License, eine neue Lizenzvariante auf dem Markt.

Die haben also Geld in die Hand genommen, den Anwalt bezahlt und haben gesagt, mach uns mal eine Lizenz, die uns besser gefällt. Gucken wir uns dann später nochmal an. Dann war längere Zeit Ruhe oder ich hab es bei Heise überlesen, dass es noch mehr Projekte gab.

Dann, Januar 2021, Elastic Search kündigt an, dass ihre bisher unter Apache lizenzierte Software künftig in Doppellizenzierung erscheinen wird. Und zwar eben wieder unter der oben schon genannten

Surfersite Public License und der Elastic License, also was ganz eigenes. Damit werden wir uns aber nicht weiter beschäftigen. Also mit der Elastic License. Gut, und schließlich als Reaktion auf diese Ankündigung von Elastic Search spaltet man,

gibt es einen Fog, der heißt jetzt Open Search ist auf GitHub veröffentlicht und ist weiter unter der Apache 2.0 Lizenz zu bekommen.

Gucken wir es uns also nochmal an. Was ist geschehen? Ein Datenbankhersteller ist von der GNU-GPL-AGPL zur APGL mit Commons Clause gewechselt. Redis ist von der APGL zu Apache mit Common Clause gewechselt.

MongoDB hat gesagt, die APGL passt für uns nicht mehr, wir machen was eigenes und ist mit der Surfersite Public License um die Ecke gekommen. Und auch die Firma Elastic mit Elastic Search hat gesagt,

Apache ist für uns nicht das geeignete, wir wechseln auch zur Surfersite Public License und machen gleichzeitig eine Doppellizenzierung noch unter unserer eigenen Lizenz. Gut, das bringt und was war jetzt der Aufreger?

Warum hat es dieser Lizenzwechsel zu einem Artikel oder jeweils zu einem Artikel bei Heise Online geschafft? Weil alle haben oder behaupten von sich, sie machen offene bzw. freie Software. Es sind alles Unternehmen, also hinter diesen jeweiligen Produkten steht federführend immer ein Unternehmen

und nicht ein organisch gewachsenes Projekt, wo sich also wild gewordene Entwickler zusammengefunden haben und einfach so zusammenarbeiten, wie das zum Beispiel bei Linux der Fall ist.

Sondern hier steht also ein Unternehmen dahinter und ein Unternehmen, das ist banal, aber ich sage es trotzdem nochmal, ist den Gesetzen des Marktes unterworfen, muss also irgendwie Geld verdienen, um die Ausgaben, die es hat, zu decken. Und das muss es eben, da wir uns im Bereich offener und freier Software bewegen,

unter den Bedingungen einer Fox-Lizenz tun. Und alle sagen quasi, wir wechseln die Lizenz, weil wir werden von den großen Cloud-Anbietern ausgenutzt.

Die nutzen unser Produkt, ohne sich an der Entwicklung oder überhaupt angemessen zu beteiligen. Wir fühlen uns ausgenutzt, alles blöd, wir müssen leider die Lizenz wechseln, aber wir machen natürlich weiter Open Source bzw. Free Software.

Gucken wir uns gleich nochmal an. So, jetzt nochmal Grundlagen, Druckbetankung, offene und freie Lizenzen. Was ist das?

Bei Lizenzen bei Software bewegen wir uns im großen Bereich der Informationen. Also ganz abstrakt gesehen handelt es sich auch bei einem Programm, bei einer Software, einfach um Informationen, wie ein bestimmtes Problem durch Abarbeiten von Befehlen gelöst wird.

Grundsätzlich haben wir recht, ich nenne es mal in Naturzustand, den Fall, dass Informationen keinen Schutz genießen. Informationen kann man frei weitergeben, die kann man frei kopieren, die verbrauchen sich nicht, also die haben auch ein paar besondere Eigenschaften, die sie von der dinglichen Welt,

also von körperlichen Gegenständen unterscheiden. Aber, und wenn man sagen will, eine Information, die also grundsätzlich frei ist, soll geheim bleiben, muss man sich im Urzustand quasi darum selber kümmern, man muss sie im Keller einschließen,

dann ist es ein Geschäftsgeheimnis oder man bastelt ein Digital Rights Management drumrum. Aber es gibt eine große Ausnahme in diesem Bereich der freien Informationen und eigentlich der Großteil der Bereich, in denen es um werthaltige Informationen gibt,

fällt eigentlich unter diese Ausnahmen. Das wird klar, wenn wir hier unten gucken, das gesamte Immaterialgüterrecht, also Urheberrechtsschutz, Datenbankschutz, Patentrechte, Markenrechte, Geschmacksmuster, also Designschutz etc., aber auch das Datenschutzrecht ist natürlich eine Form von Schutz bestimmter Informationen,

in dem Fall von personenbezogenen Informationen, interessiert uns hier aber nicht. Für uns ist der Schutz von Informationen im Bereich des Urheberrechts interessant, weil Software ist dem Grunde nach als urheberrechtliche Leistung geschützt.

So, jetzt müsste ich wieder da sein. Keine Ahnung, warum ich rausgeflogen bin. Das sieht gut aus. Ich kann dich wieder hören.

Wo waren wir stehen geblieben? Wir waren stehen geblieben. Grundsätzlich Informationen sind frei, aber wir bewegen uns mit Software im Bereich des Urheberrechts und Dutz sagt, das Urheberrecht, wer Software schafft, hat ein Urheberrecht drauf, ob wir das wollen oder nicht.

Also es ist jetzt quasi gesetzlich so geregelt, jeder der Code schreibt, bekommt darauf ein Urheberrecht, ob er jetzt sagt, ich wollte eigentlich Free und Open Software machen oder nicht, ist egal. Der hat dieses Ausschließlichkeitsrecht auf der Software. Und der Kern eines Ausschließlichkeitsrechts ist, derjenige, dem die Rechte zugewiesen sind,

das Urheberrecht kann sagen, wer dieses Produkt, dieses urheberrechtlich geschützte Werk nutzen darf oder wer nicht. Diese Nutzungsrechte sind nichts anderes als Lizenzen. Also wenn man ein Ausschließlichkeitsrecht hat, das heißt, der Gesetzgeber sagt, man darf es nur alleine nutzen, ein Werk, weil man eben alle Rechte daran hat,

dann kann man anderen die Rechte einräumen und diese rechte Einräumung an andere heißt Lizensierung. Das ist also so der Normalfall, wenn wir uns im proprietären Bereich bewegen.

So, normale Lizensierung, proprietärer Bereich, Ziel der Lizensierung ist es, eine optimale Nutzung des Wirtschafts, gutes Software zu erzielen und entsprechend werden nur so viele Rechte vergeben, wie man unbedingt will, vielleicht sogar noch zeitlich begrenzt, räumlich begrenzt. Da sind der Fantasie keine Grenzen gesetzt.

Und dann gab es eben die FOSS-Bewegung, die gesagt hat, ne, das finden wir eigentlich nicht in Ordnung. Software und die Gedanken dahinter sollte jeder frei nutzen können. Und dann gibt es da zwei Geschmacksrichtungen, nämlich einmal die offene Lizensierung, die eher den kollaborativen Ansatz in den Vordergrund stellt und sagt,

hey, lasst uns gemeinsam eine tolle Software schreiben. Jeder darf sich eine Kopie davon ziehen und darf aber im Grunde, ich pauschalisiere ein bisschen damit tun und lassen, was er will. Wohingegen bei der freien Lizensierung, die sagt natürlich auch,

hey, guckt euch an, was ich tolles geschafft habe. Ihr dürft gern mitarbeiten, lasst uns auch zusammenarbeiten. Aber Vorsicht, wenn ihr meine Software benutzt und sie besser macht, dann erwarte ich von euch, dass ihr sie unter den gleichen Bedingungen freigebt,

dass auch das, was ihr verbessert habt, jeder andere auch nutzen darf. Stichwort copy left, share like, Nutzung unter gleichen Bedingungen. Der Gedanke dahinter ist, wenn ich euch etwas schenke, erwarte ich, dass ihr dieses Geschenk aufnehmt und wenn ihr was verbessert,

dann aber auch anderen weiter schenkt die Verbesserung. Wogegen das eben nicht Gegenstand einer offenen Lizensierung ist. Also, der Unterschied ist, oder nein, fangen wir noch anders an.

Grundsatz ist, wie gesagt, das Urheberrecht steht einem Softwareentwickler zu, ob der will oder nicht und im Bereich der FOSS Software versuchen wir jetzt quasi den Urzustand wieder herzustellen. Wieder das Ganze vom Kopf auf die Füße zu stellen,

aber da der Gesetzgeber eben sagt, ihr habt diese Urheberrechte, haben wir sie auch und müssen quasi extra regeln, dass wir die nicht haben wollen. Und das machen wir in offenen und freien Lizenzen. Und wenn wir es juristisch betrachten, ist der Kern von offenen und freien Lizenzen,

dass man das Werk, das geschaffen wurde, bearbeiten darf, man darf es verbreiten und man darf es vervielfältigen, Kopien anfertigen. Das sind alles Dinge, die man sonst mit normaler proprietärer Software

in der Regel nicht darf, weil man diese Rechte nicht eingeräumt bekommen hat. Und auch ein gemeinsames Kennzeichen ist, eben kostenfrei. Es wird für die Software keine Lizenzgebühr verlangt. Soweit die Gemeinsamkeiten zwischen offenen und freien Lizenzen.

Es gibt jedoch, also ich orientiere mich hier so ein bisschen an der Open Definition, optionale Zusätze, die weitere, die auch in offenen und freien Lizenzen erlaubt sind. Der ganze Bereich der Attributionen, also wer ist der Urheber oder wo ist die Quelle und der Bereich der Lizenzangaben.

Das ist ja auch wichtig, da eine Lizenzangabe irgendwie zu haben, weil man sieht ja eine Information sonst nicht an, was man mit ihr darf und was nicht. Und wir müssen ja eben aufgrund dieser gesetzlichen Grundregelung, dass erstmal alles, was irgendwie nach Urheberrecht aussieht, geschützt ist, davon ausgehen, dass wir gar nichts dürfen.

Also wir brauchen notwendig eine Lizenz. Eine ganz wichtige Grundregel, wenn man sich im urheberrechtlichen Bereich bewegt ist, wenn man ein Werk nutzen will und keine Lizenz findet, sollte man es nicht nutzen. Hände weg davon, sonst wird man unter Umständen wegen Urheberrechtsverletzung abgemahnt.

Okay, und der spannende Teil, wo sich also freie und offene Software fundamental unterscheiden, ist hier unten.

Diesen Punkt teilen unter gleichen Bedingungen gibt es nur für freie Software. Die gibt es bei offener Software nicht. Diese Bedingung stellt offene Software nicht. Also sie sagt nicht, du musst, wenn du offene Software verwendest, mich, wenn du Verbesserungen vornimmst, auch weiter verschenken.

Sondern eine offene Lizenzierung lässt vom Grundsatz eine Reprivatisierung zu, weil eben diese Bedingungen teilen unter gleichen Bedingungen fehlt.

So, was ist jetzt das Merkmal so von freien und offenen Lizenzen? Offene Lizenzen zeichnen sich dadurch aus, dass sie sehr kurz gehalten sind, sich dadurch einfach handhaben lassen, weil man einfach auch schon als, ja, ich sag mal, die Semantik besser versteht, was da von einem gewollt wird.

Und sie haben eben keine Share-Alike-Klausel, keine Weitergabe unter gleichen Bedingungen. Deswegen freuen sich Unternehmen insbesondere darüber, weil sie gegebenenfalls eben diesen Code reprivatisieren können.

Und diese kurzen Lizenztexte sind auch bei Entwicklern in der Regel beliebt. Die meisten haben irgendwie gelernt, ja, wenn ich Software entwickle, brauche ich irgendwie eine Lizenz, wenn das FOSS Software sein soll. Und da Software-Entwickler aber Software-Entwickler geworden sind, weil sie Jura vielleicht nicht so toll finden, nutzen sie dann eben gegebenenfalls auch die offenen Lizenzen,

weil die so schön kurze Lizenztexte haben, ohne sich zu vergegenwärtigen, was da vielleicht der Haken dran ist oder was das für Implikationen hat. Freie Lizenzen hingegen, die also irgendwie mit einem Share-Alike versehen sind, haben in der Regel viel längere Lizenztexte, ja,

weil gerade dieses Share-Alike und alles, was damit zusammenhängt, viel ausführlicher geregelt werden muss. Und man handelt sich automatisch auch schwierige Abgrenzungsfragen zur Reichweite so eines Share-Alikes, eines Copy-Lefts ein. Stichwort Einlinken von Bibliotheken bei der normalen GPL-Lizenz.

Da kann man Wochen und Tage und Stunden drüber streiten. Deswegen wird das auch von vielen Unternehmen als unternehmensunfreundlich empfunden, weil man eben alles, was man mit der Software macht, gegebenenfalls wieder freigeben muss.

Das finden manche Unternehmen, die sonst eigentlich sagen, finden eine gute Idee von oben so, ist dann doch nicht so toll. Gemeinsam ist offenen und freien Lizenzen, dass man das Geld nicht über die Software-Lizenz verdienen soll, deswegen auch von die Bedingungen oder zwingende Bedingungen kostenfrei,

sondern, dass man eben die notwendige Entwicklungsleistung dahinter gegebenenfalls vergütet, also einen Entwickler bezahlt oder sowas. Also wir haben bei FOSS-Lizenzen die Idee nicht Geld gegen Ware,

sondern Geld gegen Arbeitsleistung im weitesten Sinne oder Betreuung oder was auch immer. So viel Druckbetankung zu FOSS-Lizenzen. Nächster Punkt, jetzt noch ein kleiner Exkurs.

Ich hatte ja am Anfang schon gesagt, bei FOSS-Lizenzen bewegen wir uns im Bereich der Informationen und Informationen haben ganz besondere Eigenschaften, andere Eigenschaften als dingliche, als körperliche Gegenstände, also Dinge, die man anfassen kann. Und entsprechend geben sich auch neue Probleme daraus.

Das ist die Welt, wie sie ein Volkswirtschaftler sieht, ein Ökonom. Der sagt, bei privaten Gütern haben wir gar kein Problem, da funktioniert der Markt und private Güter haben wir im gesamten Bereich der dinglichen Gegenstände, die man anfassen kann.

Und der Bereich der Informationen oder öffentliche Infrastruktur, da sind wir bei öffentlichen Gütern, die kann jeder nutzen und da haben wir, aber die verbrauchen sich auch nicht. Immer da, wo man zwar niemanden von der Nutzung ausschließen kann,

aber sich die Dinge verbrauchen, haben wir ein Problem, ein ökonomisches Problem. Gehe ich jetzt nicht weiter drauf ein. Wir müssen bloß mitnehmen. Grundsätzlich sind unsere Informationen öffentliche Güter. Das heißt, man kann normalerweise niemanden davon ausschließen, aber das Gesetz hat es so geregelt, dass jetzt quasi ein privates Gut wird.

Und wir haben grundsätzlich keine Rivalität im Konsum, die verbrauchen sich nicht. Was das für Konsequenzen gleich hat im Bereich der FOSS-Software? Augenblick noch. Denn wir müssen erst noch eine sehr unangenehme Person kennenlernen,

nämlich den sogenannten Homo economicus. Das ist das Haustier der Ökonomen und ein ziemlich unsympathischer Mensch, den niemand von uns eigentlich mag, weil seine Handlungen orientieren sich ausschließlich am zweckrationalen Eigeninteresse. Also der handelt weder moralisch noch aus Freundschaft.

Das ist ihm völlig egal. Also Neoliberalismus quasi. Jeder denkt an sich selbst. Und die Ökonomen sagen, wenn jeder an sich selbst denkt, entsteht automatisch Gutes in der Welt. Außer eben, wir haben diese Probleme wie in der Tabelle vorher.

Und dass es nicht ganz so einfach ist, dieses Modell, ist zum Beispiel, dass also der Homo economicus kollaboratives Verhalten im Bereich von FOSS-Software überhaupt nicht gut erklären kann. Aber der Homo economicus kann, also dieses eigenrationale egoistische Menschenbild,

kann uns relativ gut erklären, was für Probleme wir im Bereich der Cloud bei FOSS-Software haben. Denke ich jedenfalls. Könnt ihr ja dann in der Diskussion sagen, ob es wirklich so ist. Denn immer dort, wo wir mit öffentlichen Gütern zu tun haben,

wo man also niemanden von der Nutzung ausschließen kann und quasi sagen, du musst auch für die Nutzung einen Beitrag zahlen oder für die Nutzung einen Beitrag leisten, haben wir das sogenannte Trittbrettfahrer-Problem. Nicht jeder ist bereit, für die Entstehung und Pflege eines Allgemeingutes, eines öffentlichen Gutes zu bezahlen.

Das ist ja auch das, was man in der normalen Welt, wenn man sich mit Leuten, die nicht im FOSS-Bereich unterwegs sind, fragt, ja, was ist denn deiner Meinung nach Open-Soft, und da kommt meistens als erstes das kostenlos.

Und da kommt der kleine Homo economicus in uns allen raus. Wir freuen uns natürlich immer, dass wir keine Lizenzgebühr an große amerikanische Konzerne zahlen müssen, sondern da auch irgendwelche Software kostenfrei für uns zur Verfügung steht.

Wenn es aber eben dann zu solchen Trittbrettfahrer-Problemen gibt, und genau darüber beschweren sich ja die Unternehmen, die wir eingangs kennengelernt haben, wird es halt problematisch. Die klassische neoliberale Ökonomie sagt, ja, also wenn wir ein öffentliches Gut haben

und man das Trittbrettfahrer-Problem hat, ist eigentlich gar kein Problem. Wir haben eine einfache Lösung, macht aus dem öffentlichen Gutkraftgesetzes einfach ein privates Gut. Das kann der Gesetzgeber ja machen. Urheberrecht ist ein sehr gutes Beispiel dafür, dass man aus einem öffentlichen Gut, aus einer öffentlichen Information ein privates Gut gemacht hat,

in dem man Ausschließlichkeitsrechte zuweist. Kann man so machen, Forstsoftware macht es anders. Die freie Software hat für dieses Trittbrettfahrer-Problem eine Lösung, und zwar die heißt copy left, share like, dass man eben sagt, also wenn du meine Software nutzt, musst du sie auch wieder freigeben, wenn du Verbesserungen dran vornimmst.

Die offene Software hat überhaupt keine Lösung dafür. Bei offener Software, also open source Software, gehört das quasi zum Betriebsrisiko, dass irgendjemand sich diese Software nimmt, sie wieder in seinen Rechner einsperrt und sagt,

ich gebe bloß noch den Objektcode frei, weise zwar darauf hin, da steckt freie Software-Lösung drin, aber die Verbesserungen, die ich habe, gebe ich nicht frei. Warum funktioniert das trotzdem einigermaßen? Ja, wenn sich viele Kleine zusammentun, die sagen, jeder Einzelne hat nicht die ökonomischen Ressourcen, um ein großes Softwareprojekt zu stemmen.

Aber wenn jeder einen kleinen Teilbeitrag leistet, unkoordiniert, dann schaffen wir trotzdem was Großes, Ganzes, Gutes. Und das haben wir in diesem open source Bereich ganz oft, dass es funktioniert, aber das sind wir offensichtlich hier möglicherweise an Grenzen geraten.

Weil jetzt sagen irgendwelche Cloud-Anbieter, nö, wir geben etwas nicht zurück. So viel aber nur zum Einstieg. Gucken wir uns jetzt an, wie ist die Organisationsstruktur dieser Unternehmen,

was haben die denn alles so gemeinsam? Und das Wichtigste, oder ein Kennzeichen, das haben wir auch schon festgestellt, es sind Unternehmen, das heißt, die beschäftigen unter Umständen selber Entwickler.

Wie ist dann, wir nehmen hier mal das Beispiel Deutschland, deutsches Recht, aber das ist in anderen Ländern nicht grundverschieden. Das nämlich nicht dem einzelnen, also wenn eine Software im Rahmen eines Unternehmens entwickelt wird, steht nicht mehr dem einzelnen Entwickler das Urheberrecht an der Software zu,

sondern dem Unternehmen. Das macht die ganze Sache auch relativ einfach, wenn man eine Lizenz wechseln muss. Dann muss man nämlich nicht alle einzelnen Urheber fragen, darf ich die Lizenz wechseln, oder sind wir alle Urheber damit einverstanden, die Lizenz zu wechseln,

sondern hier gibt es nur einen Akteur, das Unternehmen, bei dem liegen alle Urheberrechte. Und das kann dann also beschließen, wir machen eine Lizenzwechsel. Also deswegen wird so ein krasser Lizenzwechsel, wie die eingangs geschilderten, auch immer nur bei Unternehmen vorkommen. Wer sich vielleicht noch 2010 rum erinnert, Open-Street-Map-Projekt,

die haben ja auch mal die Lizenz gewechselt, das war ein Riesenaufriss, weil da musste jeder Mapper einzeln gefragt werden, ob er dem Lizenzwechsel zustimmt, und wenn das ein Mapper nicht getan hat, ist er gelöscht worden. Das ist hier im Bereich der Unternehmenssoftware, im Unternehmen entwickelten Software nicht notwendig.

Und das gilt auch, wenn das Unternehmen nicht nur Angestellte Entwickler hat, sondern auch Freelancer. Im 69b Absatz 1 Urheberrechtsgesetz steht drin, auch wenn die Softwareentwicklung im Dienstverhältnis, und nichts anderes ist das, was ein Freelancer macht, erbracht wird,

landet das Urheberrecht unmittelbar beim Unternehmen, das quasi den Auftrag erteilt hat. Deswegen ist das hier also der Lizenzwechsel deutlich einfacher als bei unkoordinierten Prozessen, zum Beispiel also Linux-Körner, die könnten nie ihre Lizenz wechseln,

oder nur unter so riesigen Verlusten im Programmcode, dass man es wahrscheinlich sein lässt, weil eben, wie gesagt, dort müsste dann jeder einzelne Entwickler, jede einzelne Entwicklerin gefragt werden, ob sie mit einem Lizenzwechsel einverstanden ist.

So, was haben noch diese Projekte alle gemeinsam? Alle Projekte haben irgendwie eine Software entwickelt, die für die Cloud nützlich ist. Datenbanksoftware, Suchsoftware. Und da kommt jetzt noch ein ganz neuer Effekt hinzu mit der Cloud.

Wenn wir uns das historisch angucken, hat jeder irgendwie die Software auf seinem Rechner betrieben, lokaler Betrieb, on-premise, und hatte dann entweder nur den Objektcode oder eben auch den Programmcode und hat dann selber kompiliert. Das Ganze wurde dann entweder lokal

oder wird lokal auf dem Rechner ausgeführt oder im hauseigenen Rechenzentrum. Das heißt, Nutzung und Betrieb sind noch relativ eng zusammen. Der Betreiber nutzt in der Regel auch das Produkt, was seine Software erzeugt, selber.

Und wenn wir jetzt in der normalen proprietären Welt sind, muss man für jede Software, die man einsetzt, natürlich auch eine Lizenz bezahlen. Also man braucht eine Lizenz, sonst darf man die Software überhaupt nicht nutzen, weil eben qua Gesetzes das immer geschützt ist, es sei denn die Lizenz sagt was anderes.

Es sei denn die Lizenz sagt was anderes. Punkt. Wie sieht das jetzt in der Cloud aus? Da sieht das ganz anders aus. Da werden Nutzung und Betrieb getrennt. Man hat quasi, wenn man eine Software in der Cloud nutzt, am eigenen Bildschirm

nur immer die Ergebnisse liegen. Und bei der Speicherung sieht es nicht anders aus. Man sieht nur, ja da ist irgendwas, aber gespeichert ist es nicht mehr lokal, sondern ganz anders. Wie ist das jetzt bei rechtlich proprietärer Software? Ja da kriegen Unternehmen, jedenfalls wenn sie proprietär unterwegs sind,

richtig leuchten in den Augen, weil sie müssen jetzt gar keine Lizenzen mehr einräumen, wenn sie die Software selber entwickeln, weil historisch gesehen knüpft das Ohrheberecht an die Software Kopie an. Das heißt immer wenn ich eine Kopie fertige und weitergebe, ist das lizenzpflichtig.

Aber in der Cloud entsteht ja für den Nutzer überhaupt keine Kopie mehr. Das heißt, wenn ich die Software selber entwickelt habe, kann ich einfach abschalten und muss nur ganz normale Verträge schließen. Und wenn ich jetzt als Cloud Betreiber Software mir von anderen einkaufe,

dann muss ich an denjenigen, von denen ich die Software eingekauft habe, muss ich von denen eine Lizenz erwerben und an denen Lizenzgebühren zahlen. Aber vom Nutzer, für den Nutzer, brauche ich keine oder der Nutzer, der dann den Cloud Service nutzt, der braucht keine Lizenz. Mit dem kann ich einfach einen normalen Dienstleistungsvertrag abschließen

und da kann ich dann eben auch schneller abdrehen. Der hat keine lokale Kopie mehr, die er irgendwie betreibt, bis es von der IT-Sicherheit überhaupt nicht mehr vertretbar ist. Der hat gar nichts mehr. Sehr schönes Modell im proprietären Bereich.

So, wie ist das jetzt in unserem Bereich, im FOSS-Bereich? Schauen wir uns das mal an. Zunächst gucken wir uns noch mal die GNU-GPL an. Und erinnern uns gerade an das, was ich gesagt habe,

historisch gesehen läuft immer lokal eine Kopie des Programmcodes. Entsprechend sagt auch die GNU-GPL, also eine Share-Like-Lizenz, eine Lizenz mit CopyLeft. Sie müssen das gesamte Werk als Ganzes unter diese Lizenz an jeden lizensieren, der in den Besitz einer Kopie gelangt.

Und dann wissen wir jetzt schon, worauf das hinausläuft. Ich wollte eigentlich einkringeln. Geht relativ schlecht. Kopie haben wir nicht in der Cloud. Das heißt, wenn wir die normale GNU-GPL nutzen würden,

müsste man den Code nicht freigeben. Sie dürfen einen Werk im Objektcode übermitteln, vorausgesetzt, sie übermitteln auch den maschinenlesbaren, korrespondierenden Quelltext. Aber wir haben gelesen oder gesehen oder gehört,

in der Cloud gibt es für den Nutzer überhaupt keine Kopie. Das heißt, wenn ich in meiner Cloud Änderungen am Code vornehme oder dann im Objektcode umwandel, ist egal. Ich muss nichts rausgeben. Ist doof, merken wir.

Jetzt, wenn wir an den Homo economicus denken, das lädt gerade dazu ein, auch den Gedanken von freier Software zu hintergehen, weil jetzt kann man rechtlich gedeckt von den Lizenzbedingungen sagen, hey, ich verändere den Quellcode,

aber ich muss sie nicht freigeben, weil verlangt ja die Lizenz nicht, weil ich liefere ja überhaupt keine Kopien aus. Dass das doof ist, insbesondere für eine freie Software, wo das dazugehört, ist klar.

Das Ding, dass man, wenn man freie Software in der Cloud betreibt, das CopyLeft nicht eingreift unter normalen Bedingungen bei der GPL, heißt Application Service Provider Lücke. Also das ist bekannt, dass das nicht funktioniert in der Cloud oder dass das Probleme gibt, weil es eben keine Programmkopie

an die Nutzer gibt. Also hat man sich herangemacht und hat gesagt, diese Lücke müssen wir schließen für den Bereich des Cloud-Betriebs. Wir wollen auch dieses Share Alike, dieses CopyLeft

auch in der Cloud erhalten. Und entsprechend hat man dann die GNU Affero General Public License und die Surferside Public License gefunden, weil man gesagt hat, wir müssen diese Lücke stopfen.

Wenn man aber guckt in diese Ziffer 5, stellt man fest, diese Kopieregel finden wir sowohl in der normalen GNU GPL, als auch in der GNU A-GPL, als auch in der Surferside Public License.

Aha, ist erstmal eigenartig. Aber das deckt nur den Bereich der Kopien ab, weil es ist ja auch denkbar, dass Objektcode oder das Quelltext mal weitergereicht wird, auch wenn die Software eigentlich für den Surferbetrieb gedacht ist.

Aber das Wichtige kommt dann in Ziffer 13, der A-GPL. If you modify, dann muss auch,

also auch wenn man das Programm über das Netz freigibt, auch dann muss der Programmcode freigegeben werden. Durch diese Ziffer 13 wird also die ASP-Lücke versucht zu schließen.

Und in der GNU A-GPL. Und wenn wir jetzt in die Surferside Public License gucken, dann steht das da genauso ähnlich drin. Also, wir können schon mal hier als Erkenntnis mitnehmen,

die Surferside Public License ist eigentlich eine ungeschriebene A-GPL. Also mit anderen Worten, da ist jemand, der mit der A-GPL irgendwie unzufrieden war, weil es da aus seiner Sicht doch eine Lücke gab in dieser Ziffer 13,

zu einem Rechtsanwalt gegangen und hat gesagt, hier überarbeitet das mal unter dem und dem Gesichtspunkt. Und rausgekommen ist dann die Surferside Public License. Die sind also im Kern sehr ähnlich, A-GPL und Surferside Public License. Die Formulierungen an verschiedenen Stellen sind so ein bisschen unterschiedlich,

aber das ist ja immer so, wenn ihr einem Kollegen irgendwie einen Text gibt, ein Memo und sagt, liest da nochmal drüber, hat er immer Anmerkungen und würde was anderes schreiben. Oder genauso gut bei Quelltext. Wenn man das einem anderen gibt, der würde immer irgendwas anderes machen und so ist das natürlich auch, wenn man einem Anwalt einen Lizenztext gibt,

würde sagen, ach Mensch, das kann man doch schöner formulieren, das können wir noch so formulieren, dann decken wir den Fall noch ab. Aber wenn man das so mit ein bisschen Abstand betrachtet, sind A-GPL und Surferside Public License sehr ähnlich.

Und das ist jetzt so die erste Quintessenz, wenn man von A-GPL zu Surferside Public License wechselt, da kann man juristisch drüber streiten, ob dieser Wechsel juristisch notwendig ist, ob die A-GPL in dieser Ziffer 13 nicht alles abgedeckt hat,

ob man das jetzt mit der SSPL schließen musste. Aber das ist eher so eine Detailfrage und ich kenne ja jetzt die genauen Hintergründe nicht, die die Unternehmen hatten. Aber so riesig sind die Unterschiede zwischen A-GPL und SSPL nicht.

Also riesig nicht, aber gegebenenfalls fein, da können wir aber hier jetzt nicht im Detail drauf auch hingehen. Also, im Kern sind die sehr ähnlich, das heißt, im Kern geht es auch nicht darum, jetzt das Copy Left irgendwie groß zu verschärfen oder nicht,

sondern es geht eher um die Frage bei A-GPL und Surferside Public License, wie weit reicht das Copy Left, das Share Like, was ist quasi außer dem eigentlichen Quellcode, der da irgendwie in der Cloud läuft, noch drumherum erfasst.

Und das ist, glaube ich, eher so das Problem, was die Unternehmen gewurmt hat, dass ihr Produkt in eine Umgebung eingebaut wurde, die dann den eigentlichen Nutzen gebracht hat und aber auf die dann der eigentliche Hersteller der Software keinen Zugriff hatte

oder den Mehrwert so nicht nutzen konnte oder kann, weil das seine Software nicht hergibt. Und man versucht da jetzt eben irgendwie ranzukommen, auch an diese Integration in die Umgebung in der Cloud. Und da kann man trefflich darüber streiten, wie weit das Copy Left denn noch geht,

was also drumrum verfasst ist. Und wer sich schon mal mit der GPL beschäftigt hat, kennt dieses Problem. Da hat man einen ähnlichen Streit. Wann greift dieses Copy Left noch ein bei den Verlinkten von Bibliotheken und so was? Da hat man auch riesige Abgrenzungsschwierigkeiten. Hier hat man nichts anderes, bloß auf einem anderen Niveau, dass man eben sagt, Cloud Integration.

Was muss jetzt noch von der Integration außer der Software selber freigegeben werden, wenn die Software in der Cloud betrieben wird? Ein bisschen anders ist die Sache bei der Apache License.

Da haben wir ja schon kennengelernt, oder wenn ich, falls ich es noch nicht gesagt habe, sage ich es nochmal, die Apache License ist keine freie Lizenz, sondern das ist eine Open Source Lizenz. Das heißt, der fehlt das Copy Left. Von daher besteht da von vornherein nicht die Not der Zwang,

ob man es jetzt lokal betreibt oder nicht, den Programmcode bei Veränderungen wieder freizugeben. Das steht so ausdrücklich in dieser Lizenz drin, in Ziffer 4 steht, Sie können Ihren Modifikationen, Ihre eigene Copyright-Erklärung hinzufügen. Das heißt, Sie können umlizensieren.

Es gibt noch ein paar Bedingungen, die müssen Sie trotzdem einhalten. Sie müssen sagen, da steckt Apache Code drin und so. Das ist ja auch kein Lizenzworkshop, was wir hier machen. Also um die Lektüre des gesamten Lizenztextes kommt man nicht rum, aber für uns entscheidend ist, hier darf man umlizensieren. Also Augen auf bei der Lizenzwahl.

Das heißt, wenn es eine Apache License ist, dann gibt es da von vornherein kein Copy Left. Und dann soll sich aber auch bitte eigentlich niemand beschweren, wenn er jetzt feststellt, oh, meine Apache License-Betriebe, freigegebene Software,

wird jetzt kostenlos in großem Umfang für die Mehrwerterzeugung in der Cloud eingesetzt. Weil das ist quasi in offenen Lizenzen eben mit angelegt. Das gehört zum Berufsrisiko bei der Verwendung von offenen Lizenzen. Wir erinnern uns ganz vorn,

als ich den ökonomischen Exkurs gemacht habe. Das heißt, wenn jetzt also irgendein Unternehmen zur Apache License noch irgendeine Common Close dazu packt,

weil ihm die Verwendung seiner Software in der Cloud nicht passt, dann ist das totale Unfug. Ja, also das passt nicht. Weil wenn man eine freie Lizenz hat, dann kann man eben drüber streiten, wenn die in der Cloud verwendet wird, wo sind die Grenzen, was noch freigegeben werden muss von der Infrastruktur

oder von der Integration in die Umgebung, das gibt es bei Apache License gar nicht. Da kann jeder mitmachen, was er will. Er muss bloß sagen, wir verwenden Apache License. Da gibt es kein Share Alike. Deswegen dann zu sagen, oh, die Verwendung in der Cloud passt uns nicht und wir packen da noch,

also wir wechseln zu Apache oder wir machen da noch eine Common Close drauf. Das ist total unfugrechtlich gesehen und auch ökonomisch gesehen. Da hat jemand das Prinzip überhaupt nicht verstanden. Und entsprechend komisch

liest sich dann auch diese Common Close, also auch eine Common Close im Zusammenhang mit der AGPL. Macht überhaupt keinen Sinn, weil die AGPL versucht das ja schon einzufangen und man macht auch, man sieht auch hier plötzlich, die Leute stören sich, die AGPL, nein, die Common Close verwenden

am Verkauf. Die sagen, wir sind eifersüchtig auf euch, dass ihr damit irgendwie Geld verdient mit dem Anbieten eurer Cloud und wir da nichts von abkriegen. Aber die haben sich einfach am Anfang keine Gedanken darüber gemacht, was Open Source und Free Software bedeutet.

Und entsprechend sollen sie sich also bitte hinterher nicht beschweren und diese Common Close ist meiner Meinung nach mit dem Gedanken von FOSS Software, also egal ob Open Source Software oder Free Software, nicht vereinbar, weil man eben eingeschnappt ist und sagt,

ja, ihr dürft die nicht verkaufen und verkaufen ist aber auch, wenn ihr sie einfach nur betreibt und für den Gesamtbetrieb der Cloud Geld bekommt. Und das ist mit einem Gedanken von Open Source in der Tat nicht vereinbart, da beschweren sich die

Interessenvertreter der FOSS Community zurecht. Weil, hier habe ich nochmal Open Definition, eine Lizenz darf keine Honorarvereinbarung, Lizenzgebühren und sowas haben, aber wenn man das jetzt

ausdehnt nach dem Motto, ihr dürft mit meiner Software überhaupt kein Geld verdienen, nicht mal für den Service, den ihr anbietet und den Speicherplatz drumrum, dann geht das weit über das hinaus, was die Open Definition mit, du sollst keine Gebühren nehmen, meint.

Hier habe ich das nochmal angeguckt, Common Close mit Apache License habe ich bereits gesagt, das ist aus meiner Sicht totaler Unfug, weil gerade eben Apache License, Open Source Lizenz, da gehört es dazu, dass sich alle anderen daraus bedienen,

das ist also eigentlich akzeptiertes Risiko und dann darf man sich nicht hinterher beschweren. Im Ergebnis macht die Common Close, sowohl mit der Apache License, als auch mit der AGPL überhaupt keinen Sinn meiner Meinung nach, beziehungsweise ist mit dem Gedanken,

der von FOSS Software nicht vereinbar, ja, Punkt. Und damit haben wir es auch geschafft, sogar noch einigermaßen in der Zeit. Was nehmen wir jetzt also aus der Sache mit,

ob der Wechsel QNU AGPL zu SSPL gerechtfertigt ist oder nicht, also ob jetzt der neue SSPL Artikel 13 besser ist, als der in der AGPL, darüber kann man streiten. Also das müsste ich mir auch noch viel vertiefter angucken

und mir insbesondere dann die Fälle angucken, die MongoDB dazu bewogen haben, das zu ändern. Also da liegen die Knackpunkte im Detail, nicht im groben. Also hier kann ich es durchaus nachvollziehen, kann ich nicht von vornherein sagen,

das ist unzulässig oder mit dem FOSS Gedanken nicht vereinbar. Weil, wie gesagt, hier geht es eher um die Problematik, wie weit reicht das CopyLeft, was muss noch von der Infrastruktur, von der Integration drumherum freigegeben werden.

Anders ist es hingegen bei dieser Commons-Clause. Also die ist definitiv mit dem Gedanken von FOSS nicht vereinbar, egal ob man sie jetzt mit AGPL kombiniert, da macht es überhaupt keinen Sinn.

Oder mit Apache License, da macht es noch weniger Sinn, weil diese Apache License ja noch nicht mal ein Share Alike hat, was man irgendwie retten müsste. Das heißt, im Kern haben sich vielleicht die Projektbeteiligten am Anfang, als sie angefangen haben mit entwickeln

und sich eine Lizenz ausgesucht haben, gar nicht so richtig mit der Funktionsweise und den Risiken von FOSS-Lizenzen auseinandergesetzt, wo da die Knackpunkte sind. Oder noch schlimmer, die haben gesagt, wir machen Open Source und haben trotzdem wie ein normales, proprietäres Softwareunternehmen agiert,

haben sich also über ihr Geschäftsmodell falsche Vorstellungen gemacht im FOSS-Bereich und haben das dann versucht, mit dieser Commons-Clause wieder einzufangen. Aber das passiert jetzt allen Zuhörern und Zuhörerinnen hier nicht mehr, denn sie wissen jetzt, wo hier die Fallstriche sind.

Also, wer im FOSS-Bereich unterwegs ist, sollte sich auch über die ökonomischen und rechtlichen Implikationen Gedanken machen und nicht bloß einfach sagen, wir wollen hier FOSS-Software entwickeln, weil das kann dann hinterher mächtig schiefgehen und wenn das Produkt erfolgreich ist, gibt es dann aus der Community und Umständen mächtig haue,

weil man von sich nicht klargemacht hat, was man eigentlich will und versucht das dann hinten raus wieder einzufangen, was schwierig ist. Okay, das war's von meiner Seite. Vielen Dank für die Aufmerksamkeit

und jetzt können gern noch Fragen gestellt werden und wer sich das alles nochmal ein bisschen angucken will, kann das hier mit den entsprechenden Literaturhinweisen tun.