Transcript

Torsten:
[0:36] Ja, hallo und herzlich willkommen zur 149.
Ausgabe des E-Government Podcast. Ich bin Thorsten Frenzel und heute geht es mal wieder um eins meiner Lieblingsthemen, Open Source, und zwar ganz speziell um Lizenzen. Und weil ich das Ganze nicht so alleine bewerkstelligen kann, habe ich mir einen Experten eingeladen. Hallo Falk, ich grüße dich.

Falk:
[0:55] Hallo, schön, dass ich da sein darf.

Torsten:
[0:57] Ja, sehr schön, dass du da bist. Und vielleicht stellst du dich noch mal ganz kurz vor.

Falk:
[1:01] Ja, mache ich gerne. Ich habe zwei Herzen in meiner Brust.
Also zum einen bin ich seit über 25 Jahren Softwareentwickler und Consultant und habe ganz schön viel IT-Erfahrung damit gesammelt.
Und auf der anderen Seite berate ich als Rechtsanwalt und mache da vor allem agile Projekte, Open Source, Datenschutz, Vertragsgestaltung und dergleichen.

Torsten:
[1:22] Also du bist Entwickler und Jurist? Genau.

Falk:
[1:26] Das ist die Schnittstelle zwischen beiden.

Torsten:
[1:29] Wunderbar, also es ist eine tolle Kombination.

Falk:
[1:31] Dankeschön.

Torsten:
[1:34] Wir wollen uns heute mit dem Thema Open-Source-Lizenzen beschäftigen.

Was sind Lizenzen?

[1:40] Und bevor wir damit anfangen, erst mal die Frage, was sind denn überhaupt Lizenzen, wozu sind die überhaupt gut?

Falk:
[1:50] Ja, das führt uns so ein bisschen zurück zum Urheberrecht. Also du hast ja grundsätzlich das Problem, dass Software und auch egal, was du eben geistig schaffst, erstmal keine Sache ist im Sinne vom Gesetz.
Also Sachen, sowas wie ein Notebook beispielsweise oder was auch immer, sind ja über sogenanntes Sachenrecht geschützt.
Und genau so etwas, in der Art zumindest, bekommst du über das Urheberrecht.
Da werden dir quasi für deine geistigen Rechte, für dein geistiges Guter Leben so eigentumsähnliche Rechte geschaffen.
Und diese Rechte, die sich daraus dann ergeben, die wiederum entstehen dann automatisch, wenn du ein Werk erschaffst, also wenn du eben anfängst, deinen Programmcode zu schreiben, und zwar dann, wenn du die sogenannte Schöpfungshöhe erreichst, überschreitest.
Also sprich, wenn dein Code quasi so etwas Unverwechselbares, beziehungsweise, ne, bestreiten wir es mal anders, so etwas Eigenständiges eben mit drin hat.
Also sprich, so ein Hello World oder dergleichen ist es noch nicht.
Aber sobald du halt eben dann bei If-Clauses oder sowas halt eben schon mit drin hast, kommst du schon durchaus in diese Richtung.
So, und wenn nun also dein Code geschützt ist, dann wiederum hast du ja entsprechende Rechte drauf, also halt eben die Nutzungsrechte, Vervielfältigungsrechte, welcher Art auch immer.
Und damit nun andere das nutzen können oder nutzen dürfen von dir, musst du anderen diese Rechte erteilen. Das tust du über eine Lizenz.

Torsten:
[3:18] Genau, das ist das, was dann auch immer von Softwareherstellern mitverkauft wird, die Lizenz.

Falk:
[3:23] Ja, genau so ist es. Also die Lizenzbedingungen, die du ja dann halt eben typischerweise auch akzeptieren musst.

Torsten:
[3:30] Genau, und wir wollen uns ja generell um das Thema Open Source und Open Source-Lizenzen kümmern.
Da ist ja ein Stück weit was anders als bei den Lizenzen, die man so kaufen kann. Open Source-Lizenzen kann man ja nicht kaufen. Oder ist das auch falsch, oder? Nein, das ist richtig.

Falk:
[3:49] Könnte es theoretisch. Also viele Open-Source-Lizenzen sind diesbezüglich ja gar nicht eingeschränkt.
Das heißt also prinzipiell könnte man auch zum Beispiel als Teil eines anderen Werkes so ein Open-Source-Produkt dann mitkaufen.
Also das ist tatsächlich keine Einschränkung, die die Lizenzen mitbringen. Die ist ganz häufig.

Torsten:
[4:12] Und welche Arten gibt es von Open-Source-Lizenzen?

Welche Arten von OSS-Lizenzen gibt es?

Falk:
[4:18] Bei Open-Source-Lizenzen, also die haben ja erstmal so ganz grundsätzlich einen großen Gedanken gemeinsam, also per Definition sind die ja offen für jede Verwendung und für jede Technologie, und du sollst halt eben auch tatsächlich die Nutzungsrechte typischerweise sehr umfassend halt eben erhalten, etwa Gepflichten, also zum Beispiel Copyright-Angaben drin lassen oder Dinge zurückspielen, wenn man halt eben Änderungen vornimmt, und dann sind vor allem eben auch umfassende Haftungsausschlüsse normalerweise enthalten.
Wie gesagt, das haben die tatsächlich normalerweise eben alle so an sich, egal welche Lizenz, mal mehr, mal weniger ausführlich.
Und jetzt gibt es da aber noch eine Unterteilung, die ganz wesentlich ist, nämlich die in sogenannte permissive Licenses und sogenannte copyleft Licenses.
Und bei den copyleft Lizenzen wiederum gibt es dann halt eben auch die Einstufung nach mehr oder weniger streng.

Torsten:
[5:09] Und was heißt copyleft?

Was heißt copyleft?

Falk:
[5:14] Das Copy Left steht so ein bisschen, ich weiß gar nicht, ob ich es Gegensatz nennen möchte, aber jedenfalls so rein wörtlich zumindest zum Copyright.
Das Copyright, also das Urheberrecht, das ist ja das Recht an dem Werk selbst, also sprich halt eben so diese Lizenzbedingungen, beziehungsweise die Nutzungsrechte, die du damit erhältst.
Und das Copy Left setzt dem quasi noch eins drauf, das gibt nämlich so bestimmte Pflichten mit, die du erfüllen musst, wenn du das auf eine bestimmte Art und Weise nutzt.
Das ist ganz grob erklärt.

Torsten:
[5:49] Sind solche sogenannte Share-alike-Lizenzen, Copy-Left-Lizenzen, das heißt, dass du mit der gleichen Lizenz wieder lizenzieren musst, das Produkt, was du da draus gemacht hast?

Falk:
[5:59] Ja, zum Beispiel. Also Copy-Left kennt man vor allem vor dem Hintergrund, dass man sich fürchtet, wenn man Open-Source-Software einsetzt, dass man seinen eigenen Code, den man noch zusätzlich schreibt, dann auch opensourcen oder veröffentlichen muss.
Das steht so in Verbindung damit.

Torsten:
[6:17] Okay, also das heißt, wenn ich jetzt eine Software schreibe unter einer Copy-Left-Lizenz, dann bleibt das eine Copy-Left-Lizenz für immer?

Falk:
[6:25] Kann, genau. Also, lass uns mal folgendes Beispiel nehmen. Ich glaube, dann wird es auch für alle klarer.
Nehmen wir mal an, du schreibst eine proprietäre Software. Als Unternehmen, als Verwaltung, wie auch immer.
Und bei dieser proprietären Software, für die du vielleicht Geld verlangen möchtest oder was auch immer, da nimmst du ein entsprechendes Open-Source-Produkt rein, vielleicht auch mehrere Open-Source-Produkte. Spielt dir jetzt erstmal keine Rolle. So.
Wenn nun eines dieser Open-Source-Produkte, die du reinnimmst, eine Bibliothek zum Beispiel, eine sogenannte Copy-Left-Lizenz hat und dieser Copy-Left-Effekt auch ausgelöst wird, kann ich gerne noch was dazu sagen nachher, dann bedeutet das, dass auch das Werk, das damit zusammenhängt, also das darauf aufbaut und das wird dann normalerweise halt eben deine Software sein, die du eigentlich proprietär weitergeben wolltest, auch unter diese Copy-Left-Lizenz fallen muss.
Und weil das dann normalerweise eben die gleiche Lizenz ist von der Bibliothek oder zumindest eine kompatible, bedeutet das halt im Umkehrschluss, dass du den kompletten Sourcecode, also auch den proprietären, veröffentlichen müsstest.

Torsten:
[7:36] Ah, das sind diese sogenannten infektiösen Lizenzen.

Falk:
[7:39] Ja, genau.

Torsten:
[7:40] Ah, okay.
Das heißt zu deutsch, aus einer proprietären Software kann ich durch unbedachtes Verwenden einer Bibliothek eine Open Source Software machen.

Falk:
[7:50] Das kann dir passieren, ganz genau.

Torsten:
[7:53] Dann macht ihr das ganze Thema.
Kontrolle meiner Lizenzen oder Kontrolle der eingesetzten Softwarekomponenten einen großen Sinn.

Lizenzscans

[8:05] Gibt es da Möglichkeiten, die mich irgendwie technisch unterstützen, also sowas wie Lizenz-Scanner oder ähnliches?

Falk:
[8:13] Das macht total Sinn. Und zwar deswegen, weil du ja, wenn du Open Source Software einsetzt, häufig gar nicht einschätzen kannst, welche Software, welche Lizenzen du dir da mit an Bord holst.
Wenn man jetzt in Entwickler-Augen schaut und dann beispielsweise mit Package-Managern wie MPM oder dergleichen arbeitet und dann sich zum Beispiel eine Bibliothek reinholt, wie Angular, React oder dergleichen, dann hast du ja häufig Abhängigkeiten und Unabhängigkeiten von, was weiß ich, 500.000, 1.500.000, Bibliotheken, die natürlich alle auch eigene Lizenzen dann mitbringen können.
Und da kann es durchaus passieren, dass eben nicht nur sogenannte Permissive-Licenses dabei sind, sondern eben auch Copy-Left-Lizenzen.
Jetzt kann man natürlich hergehen und kann versuchen, von jedem einzelnen Paket halt eben die Lizenz herauszufinden, ist aber tatsächlich oft nicht so einfach.
Und die Alternative dazu ist dann, wie du gerade gesagt hast, sogenannte Lizenz-Scanner zu verwenden, die dann dir letzten Endes eine Übersicht machen, welche Lizenzen du im Einsatz hast.

Torsten:
[9:17] So ein Scanner muss ja irgendwas haben, wo er angreifen kann.
Also das heißt, ich muss auch in meine Software irgendwo die Lizenz mit reinschreiben, oder?

Falk:
[9:29] Die Scanner machen das auf unterschiedliche Art und Weise. Es gibt ja teilweise recht teure kommerzielle Produkte.
Die machen das zum einen über die Lizenzen, die dann in dem Source Code mit drinstehen.
Zum anderen aber eben auch tatsächlich durch tatsächliches Source-Code-Scanning und versuchen das dann halt eben durch Abgleich mit einer Datenbank herauszufinden, ob das Produkt halt eben unter einer bestimmten Lizenz steht, auch wenn der Lizenztext nicht mit dabei ist. Das ist die eine Variante.
Und die zweite Variante, die deutlich einfachere, ist dann tatsächlich, dass einfach die Lizenzen verwendet werden, die bei dem jeweiligen Produkt, zum Beispiel in der Package-Json oder dergleichen, halt eben mit angegeben sind. Ja, genau.

Torsten:
[10:12] Und wenn man, wenn ich das so gescannt habe und es solche infektiösen Lizenzen gibt, habe ich ja auch ein Thema der Kompatibilität.
Sind Lizenzen untereinander kompatibel oder gibt es da noch mehr Abhängigkeiten außer dieses Copy Left?

Falk:
[10:30] Die können, müssen aber nicht kompatibel sein. Ja, völlig richtig.
Das ist tatsächlich ein großes Problem.
Die sogenannten Permissive Licensers, und wenn man da jetzt einfach mal Beispiele nimmt, damit es auch klarer wird, also sowas wie eine BSD-License, Apache-License, ganz klassische Permissive License, die, oder MIT ist so auch so ein Klassiker, die sind normalerweise weitgehend kompatibel und zwar deswegen, weil die wenig Einschränkungen, wenig Pflichten vorsehen.
Wenn man jetzt aber sich in dem Bereich von Copy-Left-Lizenzen begibt, dann hängt es meistens zumindest davon ab, ob der Copy-Left-Effekt als solcher ausgelöst wird oder nicht.
Wenn er nicht ausgelöst wird, wie gesagt, sage ich gleich noch gerne was dazu, dann sind diese Lizenzen normalerweise auch verhältnismäßig kompatibel, weil es eben Open-Source-Lizenzen sind.
Sobald aber der Copy-Left-Effekt ausgelöst wird, muss man wiederum typischerweise zumindest dafür sorgen, dass die Lizenz, die über dem neuen Werk, also sprich über der neuen Software, die ich da programmiert habe, drüberliegt, dass die damit kompatibel ist, was ich quasi an Copy Left Lizenz send oder Lizenz drunter habe.

Torsten:
[11:49] Jetzt hast du es schon zweimal angesprochen mit dem Auslösen des Copy Left Effekts. Was ist das konkret?

Der copyleft Effekt

Falk:
[11:56] Also bei Copy Left.
Das ist ja ein Thema, das ursprünglich kam mit der GPL-Lizenz.
GPL-Lizenz ist zu einer Zeit entstanden, als man davon ausgegangen ist, dass es böse, große Softwarekonzerne gibt, die sich möglicherweise so eine Open-Source-Software zunutze machen und dann aber die Open-Source-Entwickler unter Druck setzen und ihnen dann quasi die Freiheiten nehmen, ihre Software so weiterentwickeln zu können, wie sie es halt eben wollen.
Wie gesagt, das war so der Gedanke dahinter. Und deswegen war die Überlegung, dass man, sobald ein anderer Softwareentwickler, zum Beispiel der böse große Konzern, diese Software einsetzt, trotzdem der ursprüngliche Entwickler der Open Source Bibliothek noch die vollen Rechte haben muss, diese Software weiterentwickeln zu können.
Wenn man sich dieses Konstrukt merkt, dann kann man mit Copy Left auch tatsächlich ganz gut umgehen und versteht auch, was so der Gedanke dahinter ist.
Ich mache mal ein paar Beispiele dazu.

[12:58] Wenn ich ein neues Werk programmiere und in dieses Werk copy-paste ich Code rein von einer Bibliothek und kompiliere das dann, habe dann ein neues Binary, dann kann ich als ursprünglicher Entwickler der Open Source Bibliothek meine Bibliothek aber in dem neuen Werk nicht mehr tauschen, weil das Binary ist ja da, da kann ich nichts mehr dran tun.
Sowas löst typischerweise ein Copy Left Effekt aus. Wenn ich jetzt aber beispielsweise mein neues Werk nur benutze, um ein Open Source Produkt, eine Open Source Bibliothek zum Beispiel per API Call oder per Kommandozeilen Call aufzurufen, ist es kein Problem, weil dann kann ich als Open Source Entwickler mein Open Source Produkt beliebig austauschen, weil es ja unabhängig ist von der neuen Software.

Torsten:
[13:49] Okay, also wenn ich den Code copy-paste, dann löst es den Effekt nicht aus.
Doch, typischerweise nicht. Und wenn ich das aber so, wie man es eigentlich machen sollte, anbinde, sodass das auch jederzeit austauschbar ist, dann löst es nicht aus.

Falk:
[14:05] Normalerweise nicht, ganz genau. So, und jetzt kommen wir aber halt eben zu dem Problem, das man in der Praxis halt eben ganz häufig hat, nämlich, was machst du denn, wenn du linken musst eine Bibliothek?
Und das ist ja tatsächlich so im Fall von Java, C++ oder was auch immer halt eben ganz klassischerweise der Fall.
Und da hängt es eben wiederum davon ab, ob du statisch oder dynamisch linkst.
Bei statischem Linking ist es typischerweise so, dass der Copy Left Effekt auch ausgelöst wird.
Bei dynamischem Linking, also wie es Java ja zum Beispiel macht, da hängt es davon ab, welche Lizenz du hast.
Bei GPL wird davon ausgegangen, dass auch bei dynamischem Linking der Copy Left Effekt ausgelöst wird.

Torsten:
[14:49] Vielleicht sagst du noch mal ganz kurz, was statisches und dynamisches Linking ist.

Falk:
[14:56] Für Nichtentwickler, du kannst dir dynamisches Linking so vorstellen, dass du quasi von deiner Software, die du hast, nochmal ein getrenntes Programm hast.
Dieses getrennte Programm wird dann quasi einfach verknüpft, das heißt also, du kannst das getrennte Programm dann tatsächlich eigentlich auch beliebig austauschen, solange deine Aufrufe gleich bleiben.
Bei statischem Linking geht das tatsächlich nicht, weil du da auch wieder so ein bisschen Copy-Pasting betreibst.

Torsten:
[15:25] Okay. Das wäre auch dynamisches Linking, wenn du quasi die Bibliothek aus der Originalquelle quasi anbindest.

Falk:
[15:34] Könntest du machen, genau.

Torsten:
[15:35] Also zum Beispiel aus dem GitHub.

Falk:
[15:39] Ich könnte es genau. Also so ein Beispiel, wenn jemand mal bei sich solche .dll-Dateien, bei einem Windows-Rechner gesehen hat, das sind solche Bibliotheken, die normalerweise dann auch dynamisch eingelinkt sind mit dem Produkt.
Also muss nicht zwangsläufig, aber bei denen ist das regelmäßig der Fall.
Oder wie gesagt, Java, da wird auch normalerweise da habe ich gelähmt.

Torsten:
[16:02] Du hattest vorhin noch was von Pflichten, die aus Lizenzen entstehen können, gesagt.

Pflichten aus Lizenzen

[16:08] Also jetzt haben wir die ganze Zeit über Copy Left gesprochen.
Welche Pflichten können denn da noch entstehen?

Falk:
[16:16] Das hängt von den Lizenzen ab. Also jetzt allgemein muss man sagen, dass was wir jetzt hier gerade besprechen, ist tatsächlich immer sehr, sehr, sehr, sehr umfassend oder sehr, sehr high level.
Bei solchen Lizenzen an sich ist es wichtig, dass man den Lizenzinhalt gesehen und verstanden hat, also sprich, es ist nicht so, dass man halt eben für alle Open Source Lizenzen sagen kann, es ist so und so, sondern man muss tatsächlich die einzelnen Lizenzen sich dann entsprechend anschauen, die man in sein Produkt mit reinnimmt.
Aber es gibt natürlich trotzdem so übergreifende Dinge, die typischerweise solche Open Source Lizenzen als Pflichten mitbringen.
Ganz häufig ist es so, wenn nicht gar regelmäßig der Fall, dass man die Lizenzbedingungen weitergeben muss, also sprich, wenn man halt eben den Source-Code von dem neuen Werk veröffentlicht, dass man auch dort die jeweiligen Lizenz-Texte und halt eben Lizenz-Hinweise drin lassen muss.
Typischerweise müssen auch Urheberrechtsangaben, also zum Beispiel diese Software wurde programmiert von Thorsten oder sowas halt eben drin lassen.
Manchmal gibt es solche Pflichten, wie wenn man Änderungen an der Open-Source-Bibliothek vornimmt, dass man diese dann entsprechend markieren muss, Also sprich, dass man ein Remark in die Software reinschreiben muss oder dass man vielleicht eben auch die Änderungen dann zurückspielen muss an den ursprünglichen Urheber, also zum Beispiel halt eben dann auf dessen Git-Repo pushen oder dergleichen.
So was sind so ganz typische Pflichten, die damit einhergehen.

Torsten:
[17:43] Das heißt, wenn ich Open Source einsetze oder wenn ich mit Open Source Teilen

Wann ist SBOM verpflichtend?

[17:50] programmiere, dann muss ich zwingend eine sogenannte SBOM, also Software Bill of Materials, mitliefern, oder?
Das zu weit gegriffen.

Falk:
[18:03] Das hängt davon ab, wie ich die Software dann vertreibe.
Wenn man die Software herausgibt aus, auch da hängt es wieder von den jeweiligen Lizenzen ab, aber gehen wir mal davon aus, dass man halt eben sowas wie eine GPL oder sowas mit drin hat, die von den Pflichten da recht umfassend ist, dann hat man regelmäßig die Pflicht, dass man angeben muss, welche Lizenzen man verwendet hat, was man ja meistens in irgendwelchen About-Screens oder dergleichen sieht.
Und wenn man den Quellcode, also das Produkt als solches, dann halt eben vertreibt, dann eben dann durchaus dort auch nochmal eben so eine komplette Lizenzübersicht plus halt eben die jeweiligen Produkte mit den Lizenzen drin. Ja, das ist richtig.

Torsten:
[18:46] Das wird ja auch immer mehr, findet man es ja in Apps zum Beispiel, dass da nochmal eine Liste ist, diese Open-Source-Produkte sind im Einsatz.
Also das hängt auch tatsächlich mit den Lizenzen zusammen, oder?

Falk:
[18:59] Ja, ganz genau. Und ja, zum Beispiel, wenn man irgendwelche Windows, Apple-Programme oder sowas benutzt, völlig richtig, genau.
Oder mach dein Fernseher an, mach dein Handy an, da hast du ja normalerweise auch solche About-Screens, in denen dann auch die jeweiligen Lizenzen genannt sind, weil halt eben, nimm Android, ist ein Linux drunter. Oder halt eben Smart-TVs ist normalerweise auch ein Linux drunter.
Ergo halt eben ganz, ganz viel Open-Source-Software, die da wiederum genannt ist.

Torsten:
[19:25] Jetzt lebt ja Open Source nicht nur davon, dass ich es verwende,

Warum macht Contribution Sinn?

[19:29] sondern es lebt ja auch davon, dass ich hier mitarbeite. Das heißt, ich kontribuiere.
Fangen wir einfach mal mit dem Einfachsten an. Welche Vorteile hat das, wenn ich da mitkontribuiere?

Falk:
[19:44] Das kommt drauf an, aus welcher Sicht.
Hast du gerade irgendeine Sicht, die du gerne besprechen würdest?

Torsten:
[19:51] Naja, also ich arbeite ja für einen Softwarehersteller und auch die öffentliche Verwaltung wird ja Software einkaufen bzw.
Auch selbst herstellen und Sinn macht ja, dass die auch entsprechend die Bestandteile, die sie verwenden oder die Software, die sie verwenden, auch mit weiterentwickeln.
Nicht unbedingt durch Beauftragung des Originalherstellers, sondern vielleicht auch selbstständig Teile upstream geben.

Falk:
[20:22] Genau, also da gibt es ja verschiedene Blickwinkel drauf, worum Contribution Sinn macht.
Wenn du ein Unternehmen bist, dann stellt sich also die ganz grundsätzliche Frage, warum soll ich meine Entwickler bezahlen dafür, dass sie eben eine freie Software entwickeln.
Das ist tatsächlich auch eine neuere Entwicklung, die sich eben erst über die letzten.

[20:45] Jahre, vielleicht auch über das letzte Jahrzehnt ergeben hat.
Davor war das tatsächlich eher nicht so umfassend oder üblich wie heutzutage.

[20:53] Der Gedanke bei Unternehmen ist, zum einen, sich nach außen besser sichtbar zu machen, also sprich halt eben um diesen high zu kämpften Markt an Entwicklern auf die Weise eben auch noch besser abgreifen, besser beherrschen zu können.

[21:08] Das andere ist, um für Softwareentwickler auch dann tatsächlich so eine Art Incentive zu bieten, also sprich halt eben sich halt eben auch verwirklichen zu können außerhalb etwaiger interner Projekte.
Es gibt ja durchaus viele Softwareentwickler, die Produkte entwickeln, die gar nicht so wirklich an die Öffentlichkeit kommen, sondern auf irgendwelchen Geräten stecken und man nie wirklich halt eben dann die Leute halt in der Hand haben und aber dann dort die Möglichkeit haben, halt ihren Namen halt eben auch im Internet kundzutun, eben auch sich selber dadurch halt eben dann besser kundzutun.
Sehr wohl aber auch, um gerade von dem Kontakt zur zur Community zu profitieren, also sprich halt eben dann ein bestimmtes Framework oder sowas halt eben einzustellen und dann aber auch wieder etwas zurückzuerhalten, also sprich halt eben noch mehr, noch neuere Ideen.
Also das ist für Unternehmen tatsächlich ein ganz wesentlicher Punkt auch und für Verwaltung halt eben genau das Gleiche.
Eine Verwaltung, die ja ohnehin inzwischen ja eben durch Nachnutzung halt eben angehalten ist, ihre Software halt eben so zu entwickeln, dass sie also mindestens halt eben von anderen genutzt werden kann, Freeware, sei es eben auch Open Source, dann halt eben wiederum auch tatsächlich nicht nur sie an andere Verwaltungen abgeben zu können, das war es bei sich, verschiedene Gemeinden, verschiedene Länder oder sowas, sondern eben tatsächlich auch wieder von der Community halt eben dann Dinge zurückzuerhalten.
Ganz wesentlicher Punkt.

Rechtliche Fragen zur Contribution

Torsten:
[22:26] Wir sprechen ja jetzt die ganze Zeit über Lizenzen und jetzt überlege ich mir gerade, Ich finde irgendeine Lösung für ein Problem in einer Open Source Software und ich entwickle diese Lösung und gebe die Upstream.
Jetzt entstehen ja daraus auch rechtskonstrukte hat das irgendwelche gefahren für mich als entwickler wenn ich jetzt da beitrage muss ich mich jetzt dann sklavisch der lizenz unterwerfen des originalprodukt zu dem ich beitrage oder trete ich alles komplett ab was ich was ich da gemacht habe oder kann ich da eigene lizenzen also fragen überfragen.

Falk:
[23:11] Wenn ich als Entwickler zu einem Produkt beitrage, dann werde ich unter der Lizenz gemessen werden, ja, von dem Produkt, zu dem ich beitrage.
Das ist tatsächlich so. Da kann ich auch nicht wirklich viel dagegen tun.
Nehmen wir mal an, ich mache keine Contribution zu einem anderen Produkt, sondern ich selber entwickle etwas und gebe das erstmal raus.
Beispielsweise, indem ich es halt eben in Git einstelle und anderen zur Verfügung stelle auf die Weise.
Und nehmen wir mal an, ich sitze da in Deutschland als Entwickler und habe da keine Lizenz drauf, dann wird halt eben nach deutschem Recht davon ausgegangen, dass das halt eben eine Schenkung ist.
Also tatsächlich ich halt eben, dass dann irgendwelchen anderen Personen, die es dann halt eben wieder benutzen, tatsächlich schenke.
Es steht tatsächlich auch im Schenkungsvertrag, brauche ich auch keine Lizenz dafür, sondern das wird halt eben dann einfach per Gesetz dann halt eben geregelt, dass du dann als Lizenznehmer oder besser gesagt als Benutzer halt eben dann zum Beispiel ein einfaches Nutzungsrecht darauf erhält, sofern das nicht weiter irgendwie angegeben ist.
So, wenn ich jetzt aber tatsächlich ein Produkt habe, auf das schon eine Lizenz drauf ist, dann wird man davon ausgehen müssen, dass ich mich halt eben dieser Lizenz dann auch zu unterwerfen hätte.

Torsten:
[24:23] Ja, es sei denn, ich baue irgendein Modul, was die Software quasi mitverwendet, oder?

Falk:
[24:30] Das könntest du machen. Also, nehmen wir mal an, du hast, nimm Wordpress, nimm Typo3 oder sowas in der Richtung. Das sind ja Open-Source-Produkte.
Und ja, richtig, für die kannst du ja dann etwaige Plug-Ins zum Beispiel entwickeln.
Und ja, völlig richtig, sofern du da nicht an einem bereits bestehenden Produkt, vielleicht sogar an bestehendem Code halt eben dann etwas änderst, etwas änderst, sondern halt eben dann ein davon unabhängiges Plug-in, das halt nur damit verbunden ist, einstellst, dann kannst du da tatsächlich eine völlig eigene Lizenz halt eben drauf vergeben. Ganz genau.

Torsten:
[25:02] Und jetzt betrachten wir mal die andere Seite. Ich stelle eine Software her, stelle die unter einer bestimmten Lizenz open source und ich bekomme ganz viele Beiträge aus der Community, die ich auch gewillt bin anzunehmen, weil ich bin ja auch nicht verpflichtet, jeden Beitrag anzunehmen, sondern ich kann ja selber als Eigentümer der Software, was ich ja weiterhin bleibe, kann ich ja entscheiden, welche Beiträge ich annehme.
Was kommt auf mich zu als Software-Eigentümer?

Falk:
[25:34] Wenn du Beiträge annimmst, dann bist du nicht mehr alleiniger Urheber von der Software, sondern du hast noch weitere Mit-Urheber mit drin.
Per se erstmal kein Problem ist, aber ist halt eben nur mal so, ähm, bedeutet eben auch, dass diese Mieturheber, ähm, zumindest an dem, was sie beigetragen haben, eben, ähm, eigene Rechte halten, was ja völlig legitim und auch gut so ist.
Ähm, wenn du ein Unternehmen beispielsweise bist und, ähm, nehmen wir gerade wieder diesen Fall, du hast ein Framework von dir entwickelt, hast es open-sourced, ähm, und möchtest dieses Framework dann zum Beispiel auch bei Kunden einsetzen, dann wirst du darauf achten müssen, dass das, was du da einsetzt, eben tatsächlich auch rechtssicher eingesetzt werden kann.
Also sprich, dass halt eben die Contributions, die da vorhanden sind, dass die auch praktisch nicht irgendwie lizenzwidrig mit reinkommen oder irgendwelche anderen Rechte oder dergleichen verletzen.
Wenn du selber aber tatsächlich der quasi Entwickler bist und setzt diese Software sonst irgendwie ein, sehe ich jetzt gerade nicht, welche größeren Probleme da auf dich zukommen könnten.
Also es wird tatsächlich immer erst dann ein Problem, wenn du die Software dann auch tatsächlich einsetzt.

Torsten:
[26:45] Wie ist das jetzt mit der Haftung? Also ich bin Softwarehersteller und ich nehme einen ziemlich coolen Beitrag an.
Und es stellt sich irgendwann im Laufe des Betriebes raus, dass der eine dicke, fette Backdoor drin hat.
Wie sieht es da mit der Haftung an? Ist da Sorgfaltspflicht beim Hersteller oder ist dann die Haftung bei dem, der beigetragen hat?

Falk:
[27:07] Das ist ein Thema, das mit den jeweiligen Abhängigkeiten zusammenhängt.
Derjenige, der dazu beiträgt, trägt ja entweder bei unter der Lizenz, die man halt eben da vereinbart hatte für das Produkt, also eine MIT oder sowas in der Richtung.
Und wenn er das nicht tut, nehmen wir mal an, das wäre halt eben ein deutsches Produkt, dann halt eben über eine Schenkung. Bei einer Schenkung bist du als Schenkenwert tatsächlich in der Haftung sehr, sehr begünstigt.
Also da haftest du quasi nicht, also selbst bei Federn oder dergleichen haftest du im Regelfall nicht.
Nur einen Fall, der aber in der Praxis kaum Relevanz hat.
Wenn du als Unternehmen das dann weiterverwendest, also sprich diese Software entsprechend rausgibst, dann kommt es darauf an, was du mit deinem Kunden wiederum vereinbart hast.
Also ob du ihm halt eben Sachmangel, Rechtsmangel, Freiheit eben dann zugesichert hast.
Wenn ja, dann bist du halt eben sehr wohl dafür eben in der Haftung in diesem Verhältnis. Dann kannst du dich aber halt eben dann normalerweise nicht mehr guthalten an dem ursprünglichen Entwickler. Ist auch so ein bisschen das Risiko bei Open Source.

Torsten:
[28:08] Ja, weil es sorgt ja dafür, dass ich jede Kontribution mir anschauen muss, damit meine Software auch sicher und rechtssicher bleibt.

Falk:
[28:18] Das ist so. Ich muss dazusagen, in der Praxis halte ich es auch für ein überschaubares Risiko, also insbesondere eben auch, wenn man jetzt so ganze Frameworks einsetzt, also nimm gerade ein Angular oder React, wo du halt eben dann zwar theoretisch dir solche Risiken reinholen kannst, aber halt eben bedingt durch die riesige Entwicklergemeinschaft zum einen und halt eben häufig auch durch die Möglichkeit, irgendwelche Bibliotheken durch andere ersetzen zu können, du dann trotzdem immer noch Möglichkeiten offen hast normalerweise.

Torsten:
[28:44] Das ist zwar ein theoretisches Risiko, aber immer wieder Argumente, wenn ich mit Leuten diskutiere über Open Source, weil da könnte ja jeder böse Hacker beitragen zum Code. Das ist immer schwierig, da was entgegenzusetzen.

Falk:
[28:58] Das kannst du auch nicht vom Tisch wischen. Also ich meine, wenn du dir anschaust, LockJ war ja so ein Problem, OpenSSL war so ein Problem, das ist schon richtig, das hast du.
Also nicht, dass da jetzt irgendwelche Hacker beigetragen hätten, dazu ganz und gar nicht. Das halte ich für eher unwahrscheinlich, aber dass eben tatsächlich Backdoors vorhanden sind, weil man halt einfach nicht dran gedacht hat, ist ja möglich.
Dann aber auch die natürlich dann halt eben auch, offen einsehbar sind und wenn man halt eben dann weiß, okay, OpenSSL in der Version 1.2.5 oder sowas ist angreifbar, wird halt eben danach gesucht und dann halt eben alle, die das einsetzen, halt eben dann versucht anzugreifen.
Also die Möglichkeit besteht zumindest. Auf der anderen Seite wird aber halt eben auch zum einen relativ schnell gefixt, typischerweise, sofern die Software noch in Entwicklung ist.
Und zum anderen schauen halt eben auch trotzdem normalerweise ganz viele Leute schon mal drauf auf die Software. Von daher ist diese Gefahr, sie ist vorhanden, ja.
Aber auch die Vorteile, die du halt eben durch Open Source Software hast, wiegen das trotzdem absolut aus, meine ich.

Torsten:
[30:04] Naja, bei proprietärer Software kannst du gar nicht reingucken und da weißt du überhaupt nicht, ob irgendwelche Backdoors drin sind.
Die findet dann irgendwann mal einer durch Zufall und nutzt es aus, weil es keiner nachvollziehen kann.

Falk:
[30:12] Du, ich meine, schau dir die OWASP-Listen oder sowas an.
Ich meine, diese Security-Listen sind ja tatsächlich voll mit solchen Fällen und zwar eben sehr wohl auch von proprietärer Software, die dann halt eben schon vielleicht halt eben auch gefixt wird. Aber ja, genau so ist es ja tatsächlich.

Torsten:
[30:28] Genau. Jetzt haben wir, glaube ich, die Basics schon so weit durch.
Vielleicht machen wir noch mal eine grobe Zusammenfassung.

Wie ist ein rechtssicherer EInsatz von OSS möglich?

[30:37] Wie ist denn ein rechtssicherer Einsatz von Open-Source-Software überhaupt möglich?

Falk:
[30:44] Wenn du Unternehmen bist, oder auch Verwaltung, spielt das erstmal keine Rolle, dann ist es wichtig, dass du entsprechende Prozesse bei dir eingeführt hast.
Mit Prozesse meine ich, dass du nicht nur Software, die du halt eben zukaufst, entsprechend inventarisierst, sondern eben auch die Open Source Software im Griff hast.
Das können dann solche Sachen sein, dass du Mitarbeiter entsprechend schulst, wie sie mit Open Source Software umzugehen haben, zum Beispiel auch, dass sie halt eben beachten müssen, dass es bestimmte Lizenzen gibt, die halt eben dann viral infizieren können, beispielsweise.

[31:23] Copy-Left-Probleme beispielsweise eben auch, oder allgemein halt eben solche urheberrechtlichen Fragestellungen einfach mal beigetragen hast dazu, beziehungsweise halt eben den Kolleginnen und Kollegen halt eben gesagt hast, welche es da grundsätzlich halt eben halt Probleme geben könnte.
Zum anderen eben aber auch dann tatsächlich zum Beispiel Lizenz-Scanner einzuführen, die ja teilweise eben auch schon solche Security-Scans eben mitbringen können, um eben tatsächlich eine solche Inventarisierung zu ermöglichen. Das ist so ein Thema.
Und das andere größere Thema ist dann eben auch tatsächlich zum einen sauber zu dokumentieren, was du verwendest und drittens dann eben auch zu prüfen, wie du im Außenverhältnis auftrittst, also sprich zum Beispiel Verträge mit Kunden zu prüfen, ob du halt eben etwaige Mangelfreiheiten halt eben zusicherst, was häufig der Fall ist.
Ob du dann deinen Kunden auch Open-Source-Listen geben kannst, solche Dinge eben.

Torsten:
[32:15] Okay, also rechtssicherer Einsatz ist natürlich möglich, muss man ein paar Sachen beachten.

Falk:
[32:18] Ja, genau. Also ich möchte es tatsächlich auch gar nicht zu weit fassen.
Also rechtssicher ist nicht hundertprozentig, aber du kannst es gut in den Griff kriegen, sagen wir es mal so. Ich meine, jeder setzt Open-Source-Software ein, im Übrigen auch zu Recht.
Wenn du aber das dann tatsächlich sauber prozessualisierst und halt eben zum Beispiel mit Lizenzgängern oder dergleichen arbeitest, dann kriegt man das im Regelfall auch ganz gut gelöst, ja.

Torsten:
[32:44] Ja, Falk, vielen Dank, dass du bei mir warst. Vielen Dank, dass du mich und die Hörerinnen und Hörer des eGarmin-Podcasts zum Thema Open-Source-Lizenzen so umfassend abgeholt hast.
Und schön, dass du da warst.

Falk:
[32:58] Ja, danke, dass ich dabei sein durfte. Und ja, den Hörerinnen und Hörern, ich hoffe, es hat Ihnen und euch was gebracht.

Torsten:
[33:04] Gibt es irgendeine Webseite oder ähnliches wo man dich erreichen kann wenn man Fragen hat?

Falk:
[33:09] Nein, tatsächlich nicht. Aber ich werde in Zukunft Teil von der Kanzlei Planet in Hamburg sein. Das heißt also prinzipiell da und ansonsten per E-Mail.

Torsten:
[33:20] Genau, per E-Mail und ihr könnt natürlich auch in die Kommentare zur Sendung reinschreiben und da wird Falk auch antworten, wenn er darauf antworten kann.

Falk:
[33:29] Genau, absolut, sehr gerne.

Torsten:
[33:31] Vielen Dank euch allen fürs Zuhören. Wir wünschen euch einen schönen Tag, schönen Abend und bis zum nächsten Mal.