Herzlich willkommen zurück bei der Froscon Cloud Edition 2021. Hier im Development Track, jetzt mit dem Motto nicht verzagen, eine Juristenfragen. Es geht um Contribution zur Open Source Software und eigene Software, Open Source und insbesondere zu den rechtlichen Fragen.

Erhält mit uns Falk Müller, seines Zeichens IT-Konsultant und Jurist, also zwei zum Preis von einem. Und damit übergebe ich das Wort und wünsche viel Spaß. Wenn ihr Fragen habt, kommt gerne in die Videokonferenz und schreibt die Frage in den Chat, da lese ich die nachher im Stream vor

und machen das in dem Q&A zusammen mit allen. Super, ganz herzlichen Dank für die Einleitung. Ich hoffe, ihr könnt mich gut hören und sehen. Hören ist vor allem das Wichtige. Entschuldigt bitte die Verspätung. Das mit Rechtsanwälten ist ja immer so,

dass die, was die Technik betrifft, irgendwie nicht so begabt sein sollen. Bei mir ist ja nun beides, also tatsächlich ITler und Anwalt, aber irgendwie hat scheinbar heute die Rechtsanwaltsgeschichte da eher durchgeschlagen. Tut mir leid, wir versuchen es aufzuholen. Kurz erst mal zu mir selbst.

Mein Name ist Falk, ich bin knappe 40 inzwischen, auch schon. Ich habe einen kleinen Sohn, der ist knappe drei, Jura studiert, mit damals noch Fachrichtung Rechtenformatik. Bin allerdings auch schon seit gefühlt Jahrhunderten, also seit knapp einem Viertel Jahrhundert Softwareentwickler. So komme ich tatsächlich auch zu euch.

Das heißt, also ich bin tatsächlich nicht einfach nur Rechtsanwalt, der auch mal, und das soll gar nicht abwertend klingen, mal in WordPress irgendwas gemacht hat, sondern ich mache das tatsächlich schon seit Ewigkeiten und habe angefangen, oh Gott, mit Visual Basic dann rübergegangen auf C++, irgendwann Richtung Java weiterentwickelt,

PHP ganz viel gemacht auch, und über die Jahre dann auch recht viel im Frontend-Bereich mit JavaScript und dort halt eben mit den bekannten Frameworks. Angular.js angefangen, dann Angular, React und Vue. Und das auch tatsächlich hands-on zum einen als Entwickler, sprich halt eben mit tatsächlicher Erfahrung,

dann halt eben später auch als Architekt und inzwischen als IT-Consultant im Wesentlichen. Ich arbeite seit mittlerweile über elf Jahren bei der Stuttgarter Firma Dikonium, bin dort zum einen Expert-IT-Consultant und habe eine Doppelrolle als Syndikus-Rechtsanwalt und bin aber davon abgesehen auch Aktivtätiger,

Rechtsanwalt und Fachanwalt für IT-Recht und berate da tatsächlich auch bundesweit Mandanten. Wir fangen das Thema an mit einer kleinen Einführung und vor allem der Frage der Praxisrelevanz. Ich meine, klar, Open-Source,

das verwendet jeder, gar keine Frage. Die Frage ist aber, was hat man denn so üblicherweise für Konstellationen, wenn man in Open-Source-Software an sich contributen möchte. Und so der ganz klassische Fall ist ja, man hat eine Open-Source-Software bei sich, die man halt verwendet, eine Library

oder dergleichen, und möchte da dann was zurückgeben. Also sprich halt eben irgendwas pushen und da halt eben quasi teilhaben an einem Projekt. Vielleicht möchte man aber auch tatsächlich hergehen und etwas ganz neu entwerfen und überlegt sich halt eben das dann tatsächlich direkt als eine Open-Source-Software dann freizugeben. Oder die dritte Variante,

auch immer wieder mal, man hat schon eine Close-Source-Bibliothek fürs Unternehmen beispielsweise erarbeitet, überlegt sich, dass man die entweder ausschließlich oder halt eben dann zusätzlich unter einer Open-Source-Software dann vertreiben möchte. Und dann hat man ja üblicherweise

so Wünsche wie, naja, ich als Unternehmen möchte aber die Software dann schon auch gerne kommerziell weiterverwenden können. Ich möchte natürlich auch die Nutzungs- und Änderungsrechte daran haben und möchte vor allem auch selbst weiterentwickeln können. Das sind alles Fragestellungen, die wir jetzt behandeln werden in dem Vortrag hier. Urheberrechte im Allgemeinen ist ja eine Sache, die

also ich halte tatsächlich auch Wochenend-Workshops mit drei Tagen drüber rein zu Open-Source und da kann man tatsächlich so viel dazu erzählen. Wundert euch also nicht, dass es hier tatsächlich sehr komprimiert, quasi aufdestilliert ist. So wie so ein starker Kaffee, wie so ein Mokka quasi, könnt ihr euch das vorstellen hier.

So ganz kurz, warum möchte man denn als Unternehmen überhaupt Open-Sourcen und früher, also vor einigen Jahren noch ist das ja tatsächlich mit einiger, einiger Skepsis wahrgenommen worden. Aber inzwischen gilt ja für Open-Source-Software als Türöffner für Konferenzen, also für Vorträge, die man drüber halten kann, wie so eine

Art Visitenkarte eben auch nach außen. Das soll eben andere Entwickler und das ist, wenn wir ehrlich sind, auch so das tatsächlich Entscheidende dahinter sehen können, was man im Unternehmen so macht. Und ist nämlich tatsächlich auch ganz viel ein Recruiting-Ansatz, dass man eben nicht nur über die klassischen Wege, also sprich halt eben auch LinkedIn oder Xign oder was auch immer geht, sondern dass man eben auch sagt

naja schau mal her, bei GitHub haben wir halt eben dann auch noch die Möglichkeit als Entwickler da halt eben zu contributen und man bekommt halt eben auch die Zeit bei uns, was für viele Kollegen dann auch tatsächlich interessant ist. Insbesondere ist es aber eben auch, und das haben die Unternehmen früher nicht erkannt, für das Unternehmen selbst, das eben in

Open-Source publiziert, interessant, weil er durchaus je nach dem, was es für ein Paket ist, Dinge wieder zurückkommen. Auf diese grundsätzlichen Risiken bei Technischer Natur gehe ich tatsächlich nicht näher drauf ein. Ich gehe davon aus, dass ihr die Folien im Nachgang runterladen könnt. Wenn nicht, meine E-Mail-Adresse steht am Ende,

dann schreibt mich einfach kurz an, ich senze euch gern zu, weil ihr kennt die Risiken, braucht man nicht drauf eingehen. Entscheidend ist nur eins. Ganz am Ende der Absatz, ich habe in meiner Beratungspraxis und zwar sowohl als Rechtsanwalt, als auch als IT-ler festgestellt, dass tatsächlich

wenig Unternehmen die Probleme, die für ihren Open-Source-Software so mit sich bringt, auch tatsächlich vollumfänglich beherrscht. Also es wird tatsächlich recht hemsärmelig gehandhabt und das kann man natürlich machen, keine Frage, aber es gibt einige Dinge, die man zumindest beachten sollte und auch da gehen wir jetzt drauf ein.

So eine ganz grundsätzliche Frage, wer soll mich denn überhaupt verklagen? Und ja, ist tatsächlich eine gute Frage. Open-Source, in der kleinen Projekte stehen ja dann oft das weiß ich, Einzelpersonen, vielleicht mal zwei, drei Leute. Es gibt aber eben sehr wohl auch, und das wisst ihr besser als ich, große Gemeinschaften, wie halt eben Mozilla

beispielsweise oder halt eben ganz bekannt halt eben alles so rund um Linux insgesamt, Angular und dergleichen. Das Spannende dabei ist aber, wenn man nicht eine Gemeinschaft ist, sondern eben nur bei einem Projekt mitmacht, dann ist trotzdem jeder Urheber, der eben mitmacht an dem Projekt selbst auch

sogenannt aktiv legitimiert, also kann eben tatsächlich klagen. Und, und jetzt kommt der tatsächlich interessante Teil, Anwaltskanzleien in den USA kann man zumindest beauftragen und bezahlen lassen nach Erfolg. Das heißt also, anders als jetzt in Deutschland beispielsweise, wo man das nur in einem Ausnahmefall machen kann, muss man dem Anwalt nicht vorab schon etwas bezahlen,

sondern eben nur dann, wenn er Erfolg hat und das macht es dann wiederum zu einem entsprechend spannenden Umfeld. Das heißt also, die Wahrscheinlichkeit ist zumindest gegeben. Und ja, das Risiko an sich ist zwar schon überschaubar, aber es ist gleichwohl tückisch, denn wenn es denn tatsächlich zu einer,

muss nicht mal eine Klage sein, kann auch eine reine Abmahnung sein, kommt, dann muss man eben tatsächlich schnell und überstürzt entsprechende Open-Source-Prozesse bei sich einführen, hat dann Haftungsfragen, dann kommt möglicherweise auch ins Neben-Strafrecht rein, über den Paragraph 106 Urhebergesetz, gehen wir später noch drauf ein. Und dann halt eben auch so ganz grundsätzliche

Fragen, wie habe ich denn wirklich alles so lizenziert, wie es eigentlich erforderlich wäre. Dann gibt es noch den Patrick McHardy, ich gehe nicht näher drauf ein aus Zeitgründen, wenn ihr ihn nicht kennen solltet, gebt den Namen tatsächlich mal bei Google ein und schaut mal, was da in der Vergangenheit um McHardy passiert ist, hat so mit Linux-Kernel zu tun,

bei dem er teilweise zeitweise Kultibüter war. Dann so ganz allgemein mal die Frage, klar, jedes Unternehmen nützt Open-Source, die Frage ist nur, wie viel Open-Source ist es denn tatsächlich. Viele Mandanten kommen auf mich zu und sagen, ey Müller,

hier ist ein Excel-Sheet, sag mir, ist das denn tatsächlich auch lizenzkonform, was wir da tun. Dann bekommst du halt eine Liste mit, was weißt du ja nicht, so 17 JavaScript-Packages aus Angular beispielsweise raus und wenn du dann zurückkommst und fragst, naja, nutzt ihr jetzt, was weiß ich, NPM oder dergleichen, dann kommt dann zurück, naja, machen wir schon, dann sagst du dann

ja, das heißt also, ihr habt dann halt eben dann Dependencies und Sub-Dependencies und Sub-Sub-Dependencies, naja, das wissen wir jetzt nicht so genau und hier und da und das, was hier steht, bedeutet nämlich dann, was tatsächlich an Open-Source-Software eingesetzt wird und an der Stelle wiederum wird es dann tatsächlich haarig, weil man nämlich nicht weiß, welche Lizenzen da tatsächlich

bei so einem Produkt vorhanden sind. Da kommen wir auch noch drauf zu sprechen. Das zur Einführung, das, was wir jetzt machen, ist tatsächlich auch eine Einführung und zwar zunächst ins Urheberrecht. Da braucht ihr zumindest so einen gewissen Grundsatz, um das Nachfolgende verstehen zu können. Nehmen wir mal folgenden

Fall an. Ihr entwerft eine Bibliothek. Ist völlig egal, was da drin ist. Ich komme von Mountainbiken. Deswegen habe ich mir gedacht, ach komm, für Garmin könntest du mal so eine Bibliothek für Fahrraddaten entwerfen und die dann halt eben Open-Sourcing, damit halt eben dann auch noch andere entsprechend beitragen können. Dann kommen so ganz typische Fragestellungen, wie habe ich denn da an sich schon Urheberrecht auf und wenn, ja wann

und was für eins und wie überhaupt. Dann halt nächste Frage, bin ich haftbar für irgendwas? Kann ich dafür in den Knast gehen? Weiß man ja nie. Und dann halt eben vielleicht auch noch eine Frage, was kann ich denn überhaupt dafür tun, damit meine Software halt eben dann unabhängig ist und dann kommt halt gern mal so ein Passwort, Open Copy Left oder dergleichen mit rein.

Ich hatte mir dann ursprünglich mal überlegt, naja, mein Gott, erklärst du halt eben Urheberrecht im Stil von der Sendung mit der Maus. Mein Kleiner ist sehr riesengroße Sendung mit der Maus-Fan. Eines der Lieblings-T-Shirts ist auch tatsächlich das mit Maus und Elefant drauf und der Ente auch noch. Jetzt dumm nur, ich kann euch Maus und Elefant nicht zeigen, weil die sind urheberrechtlich geschützt.

Urheberrechtsgesetz ist tatsächlich kein besonders umfangreiches Gesetz, ist auch verhältnismäßig leicht zu verstehen. Das hat folgenden Hintergrund, das geistige

Geist ist gut, aber nicht. Und jetzt ist der Gedanke, über die Rechtsordnung, die schöpferige Tätigkeit,

dann auch so ähnlich halt eben wie eine Sache zu schützen und so kommt man eben auf das Urheberrechtsgesetz. Und das wiederum gewährt dann halt eben ein quasi eigentumsähnliches Recht an dem Gut. Das ist übrigens weltweit ganz sicher nicht gleich, aber hat eine gewisse Ähnlichkeit zumindest.

Natürlich, USA hat da wiederum Spezialkonstrukte mit drin, kommen wir auch noch drauf zu sprechen, aber das, was man in Deutschland oder im kontinentaleuropäischen Raum hat, das funktioniert so verhältnismäßig ähnlich, zumindest im westlichen Bereich der Welt auch. Wie steht denn das Urheberrecht?

Da gilt zunächst mal das Schöpferprinzip, bedeutet Urheber ist der Schöpfer als eine natürliche Person. Das heißt also, wenn ich jetzt beispielsweise im Arbeitsverhältnis etwas entwickle, dann bin ich zunächst einmal Urheber. Die Frage ist dann aber konsequent, warum steht dann aber trotzdem drüber

Copyright-Namen meines Arbeitsgebers, was weiß ich, Microsoft oder dergleichen. Und das liegt daran, weil man im Arbeitsvertrag ganz typischerweise eine entsprechende Regelung hat, dass man alles, was man eben im Arbeitsverhältnis tut, auch tatsächlich exklusiv an seinen Arbeitgeber abtritt. Und selbst wenn das nicht so sein sollte, dann wird etwas ganz ähnliches

per deutschem Gesetz zumindest ausdefiniert. Übrigens, Copyright-Symbol ist keine Pflicht. Auch ohne das Copyright-Symbol entsteht ein Urheberrecht. Das macht man tatsächlich nur, um quasi so einen Hint darauf zu geben, wer denn der Rechteinhaber ist, sei es eben ein Nutzungsrechteinhaber. Dann die Frage,

wann entsteht das Urheberrecht? Und dafür muss man die sogenannte Schöpfungshöhe erreichen. Und das wiederum gilt als die Untergrenze des Urheberrechtschützers, die im Übrigen sehr niedrig anzusetzen ist. Klar, es gibt so Dinge wie ein Hallo-Welt-Code oder dergleichen oder etwas, das eben tatsächlich

so allgemein ist, dass man da keine wirkliche geistige Anstrengung dafür benötigt. Also was weiß ich zum Beispiel, etwas, was man halt eben dann, was weiß ich halt eben, if, this, then oder sowas in der Richtung. Aber wenn es, sobald es halt eben schon etwas höher geht, also sprich, sobald halt eben eine entsprechende geistige Leistung dahinter ist,

dann hat man typischerweise auch schon die Schöpfungshöhe erreicht. Ich hatte vor schon erwähnt, wenn mehrere Personen gemeinsam an einem Werk arbeiten, dann hat jeder eine entsprechende Miturheberschaft eben über das, was er selbst geschaffen hat. Und wie ich vorher schon gesagt habe, die Urheberschaft wird durch eine Kennzeichnung

auf dem Werk vermutet, ist aber wie gesagt nicht entsprechend verpflichtend, das zu machen. Schutzfähig sind tatsächlich alle Formen von Computerprogrammen, sprich halt eben geschriebener, aber sehr wohl eben auch kompilierter, sprich binärer Codern. Allerdings nur dann, wenn es tatsächlich von Menschen

geschrieben worden ist. Das heißt also, wenn es ein Code ist, der automatisiert erstellt worden ist, dann ist dieser automatisierte Code typischerweise nicht schutzfähig, aber wiederum das, was dahinter steht, also sprich halt eben dann beispielsweise etwas, was man zusammenklicken musste oder halt eben als Vorarbeit leisten musste, um diesen automatisierten Code generieren zu können.

HTML-Code und SQL-Statements, da ist es umstritten, aber tatsächlich eher nicht schutzfähig und zwar mit dem Argument, dass man sagt, das seien beides keine Programmiersprachen, sondern halt eben beschreibende Sprachen und deswegen fallen die halt eben nicht in diese Schutzfähigkeit drunter. Ich persönlich sehe es anders. HTML, genauso wie

SQL-Statements, können beides sehr kompliziert werden, aber sei es drum, ihr wisst jetzt, es ist typischerweise eher nicht schutzfähig, ihr könnt auch dazu mal im Internet recherchieren, gibt es die eine oder andere interessante Ausführungen dazu. Sehr wohl schutzfähig sind Benutzeroberflächen und selbstverständlich eben auch Datenbanken. Da habe ich jetzt in Klammern Datensammlungen genommen, weil eben nicht jede Datensammlung

auch zwangsläufig eine Datenbank sein muss. Nehmt einfach mit, was ihr als Code schreibt, ist typischerweise schutzfähig, in Klammern außer HTML und SQL. Wobei wiederum, wenn man jetzt entsprechende Statements hat, also spezifunktionsaufrufe in SQL-Code, die könnten sehr wohl wieder schutzfähig sein, den Fall hatte ich tatsächlich noch nie.

Maximale Schutzdauer sind 70 Jahre nach Tod des Urhebers. Bei Datenbanken deutlich kürzer, sind es eben insgesamt maximal 30 Jahre. So kommt das auch, dass ihr bei Amazon beispielsweise von die Sherlock Holmes Bücher kostenlos runterladen könnt, weil

die Urheberrechte des damaligen Urhebers eben jetzt aufgehoben sind, also nicht mehr gelten und das deswegen Gemeingut wird, wie man das so schön nennt. So, jetzt das tatsächlich interessante. Wenn ich ein Urheber bin, dann habe ich zunächst mal das ausschließliche Recht zu verbreiten, zu vervielfältigen und auch das Programm

zu bearbeiten. Solche Nutzungs- und Verwertungsrechte, das sind dann sowas wie halt eben auch Rechte öffentlich zugänglich machen oder dergleichen. Wenn einer von euch mal abgemeint sein worden sollte, also gerade halt eben Zuge von File-Sharing oder dergleichen, da kommen solche Begriffe typischerweise vor. Dann gibt es die

sogenannten einfachen oder ausschließlich Nutzungsrechte. Ausschließlich so viel wie exklusiv bedeutet eben, man gibt Nutzungsrechte an jemanden einzelnen ab und hat die dann selbst nicht mehr und auch sonst kein anderer mehr, so wie es im Arbeitsverhältnis ganz oft der Fall ist. So, mit diesem Basissatz können wir

dann tatsächlich auch zu den Lizenzen und dem Lizenzrecht kommen. Der Begriff Lizenzrecht, da denkt man halt eben, es gibt bestimmt irgendwie ein Gesetzbuch, wie es BGB oder dergleichen, in dem drin steht, was Lizenzrecht ist. Aber nein, mit Lizenzrecht meint man das,

was der Lizenznehmer tun darf. Das heißt also das, was eben letzten Endes im Lizenzvertrag drinsteht. So, jetzt kommen wir tatsächlich schon so in den Bereich rein, warum das alles spannend ist für diejenigen, die zu Open Source Software contributen möchten, beziehungsweise die halt eben selber eine Software veröffentlichen

möchten. Nehmen wir mal an, man veröffentlicht eine als deutscher Entwickler oder deutsches Unternehmen und hat zunächst mal keine Lizenz drauf. Wozu man auch keine Pflicht hat, komme ich gleich noch dazu. Dann ist das nach deutschem Recht eine sogenannte Schenkung. Das heißt also

mit demjenigen, der dann diese Software nutzt, entsteht ein Verschenkungsvertrag nach § 516 fortfolgende BGB. Und der ist insofern sehr vorteilhaft, weil der Schenkende grundsätzlich nur in dem Fall haftet, den ich da angegeben hat, nämlich verschweigt der Schenker arglistig einen Fehler der Verschenkungssache. So ist er verpflichtet, dem

Beschenkten den daraus entstehenden Schaden zu ersetzen. Das heißt also, ihr haftet nur dann, wenn ihr wisst, dass es einen Fehler gibt und diesen Fehler dann mit entsprechender arglist auch tatsächlich dem gegenüber verschweigt. Das heißt also, wenn es halt eben ein Bug ist, der gefunden wird beispielsweise, dann hat man diesen Haftungsfall typischerweise nicht. Und in den arglist Fall kommt man halt eben

dann auch nur rein, wenn man es, wie schon gesagt, halt eben tatsächlich weiß und mit entsprechender arglist verschweigt gegenüber dem Beschenken. Das heißt also, wenn man beispielsweise bei einer Open Source Software ein Ticketsystem hintendran hat, wie es so bei GitHub, GitLab und dergleichenall eben ist, wo halt eben Fehler drinstehen,

dann ist das überhaupt kein Problem und haftet man tatsächlich eben nicht. Nach US-amerikanischem Recht funktioniert das tatsächlich anders. Das US-amerikanische Recht ist ja im Gegensatz zum Kontinentaleuropäischen kaum qualifiziert. Bedeutet, da ist der größte Teil tatsächlich basierend

auf Rechtsstreitigkeiten, also sprich halt eben dann auf einem Caseload, wie man das so schön nennt. Zum einen und zum anderen hat das Recht einen anderen Ansatz als unseres. Und zwar geht man dort davon aus, dass man erstmal ganz viel Privatautonomie hat, was es zugleich auch schwer vorhersehbar macht. Im Gegensatz zum Kontinentaleuropäischen

Recht sage ich jetzt bewusst, durch Brexit fällt ja UK mittlerweile raus, geht man eher davon aus, dass halt eben die Rechtsanwände im Verhältnis doof sind und deswegen eben alles ganz genau zu regeln und zu schützen ist. Ist grundsätzlich auch durchaus vorderhaft, weil man halt eben auf die Weise Verträge verhältnismäßig kurz halten kann und man auch

tatsächlich recht gut vorhersehen kann, was einen in der Rechtssituation erwartet. Wenn man so ganz grob US-amerikanische und deutsche Verträge vergleicht, ihr habt bestimmt schon US-amerikanische Verträge in der Hand gehabt, dann hat man erstmal irrsinnig lange Präambeln mit Definitionen, wo dann eben auch ganz alltägliche

Definitionen sind, wie Entwickler ist eine Person, die Code schreibt und so weiter und so fort, was wir Deutschen halt eben nicht haben. Präambeln haben wir zwar mittlerweile aus dem US-amerikanischen übernommen, da schreibt man bei uns aber tatsächlich nur so ein bisschen den Kontext rein, um halt eben dann einen Richter oder dergleichen halt eben dann sagen zu können, von welcher Idee halt eben der Vertrag entstanden ist. Dann haben wir in

USA halt eben auch ganz üblicherweise super umfassende Haftungsausschlüsse, was in Deutschland prinzipiell auch gemacht werden könnte, aber sofern es ein Vertrag ist, der unter AGB-Recht fällt, dann geht das tatsächlich üblicherweise nicht.

Unter AGB-Recht fällt im Übrigen all das an Verträgen, bei denen man davon ausgeht, dass man sie nicht nur einmalig verwendet, sondern mehrfach. Also sprich halt eben zum Beispiel auch Mietverträge sind typischerweise AGB-rechtliche Verträge, Lizenzverträge eigentlich auch immer. Und für die Tatsache, dass ein Vertrag individuell

gehandelt worden ist, ist man beweisenpflichtig. Das heißt, das macht man typischerweise, indem man halt eben protokolliert. Man hat individuell über diese oder jene Klausel halt eben gesprochen. So kommt das übrigens auch zu diesen, sieht man auf manchen Verträgen, dass auf jeder Seite halt eben einzeln unterschrieben worden ist, was grundsätzlich auch ein Indiz sein kann für eine Individualverhandlung.

US-Verträge können typischerweise auch jeden Sachverhalt darstellen, wie sie grundsätzlich möchten. Das ist im Deutschen tatsächlich nicht ohne Weiteres möglich, eben auch wiederum bedingt durch das AGB-recht und die AGB-Prüfung, bei der tatsächlich vieles dann flach fällt, wenn es halt eben dann beispielsweise gesetzeswidrig von der Formulierung her ist. Ab den Hintergrund, dass man sagt,

AGB ist typischerweise etwas, was man nicht liest oder halt eben dann nicht so ohne Weiteres wahrnehmen kann. Deswegen soll halt eben es hier zu keinen überraschenden Effekten kommen. Hat wiederum die Thematik, dass wenn man US-amerikanischer Entwickler ist,

man entsprechend viel Kreativität und vor allem Rechtskenntnis braucht, um einen solchen Lizenzvertrag samt Haftungsausschlüssen erstellen zu können. Und weil das so ist, kann man in der Vergangenheit eben dazu solche Verträge zu entwerfen und prüfen zu lassen und die auch dann tatsächlich einzusetzen. Als deutscher Entwicklerunternehmen, wie auch immer,

kann man sehr wohl solche US-amerikanisch formulierten Lizenstexte auch einsetzen und nutzen. Aber die Thematik ist, dass durch das AGB-recht die nur bedingt greifen. Also speziell die Haftungsausschlüsse sind zu weit gegriffen. Das heißt also, diese werden üblicherweise nicht greifen.

Und im AGB-recht funktioniert das so, ich habe diese salvatorische Klausel hier schon in Verträgen gelesen. Wenn die Klausel nicht gilt, dann gilt alles andere trotzdem, was Quatsch ist, weil sowieso schon der Fall. Aber sei es drum, bedeutet so viel wie, wenn eine Klausel nicht gilt, dann wird sie auch nicht geltungsreduzierend

verwendet, sondern sie gilt überhaupt nicht mehr. Das heißt also, man geht dann tatsächlich auf das Gesetz zurück, was in unserem Fall als deutscher Entwickler vorderläufig ist, weil die Schenkung ohne Haftung hat. Die anderen Definitionen, die in solchen Verträgen drin sind, werden dann auf deutsches Rechterleben versucht zu übertragen,

was im Regelfall recht gut funktioniert. Haftung ist so das Entscheidende, was man eigentlich hat. Und das bringt uns dann zu dem, weswegen wir uns eigentlich hier zusammensetzen, nämlich zu den Open-Source-Lizenzen und Wahlen, der Frage, was ist denn nun die Richtige für mich. Ich hatte vorher schon gesagt, dass die Wahl von Open-Source-Lizenzen nicht verpflichtend ist,

noch dass man tatsächlich unbedingt eine braucht. Es ist aber so, wenn man eine Open-Source-Software entwickelt, dann möchte man ja, dass die, möchte ich nicht, aber es macht halt eben Sinn zumindest, sie halt eben so zu publizieren, dass sie leicht eingesetzt werden kann. Und wenn man nun jedem Verwender

erklären muss, unter welcher Rechtslage man eben hat und welche nicht und dergleichen, dann ist das für die Verwender tatsächlich schwer einzuschätzen, was halt eben dann speziell bei Unternehmen dazu führt, dass sie halt eben diese Software vielleicht gar nicht nutzen möchten. Deswegen bietet es sich halt eben an, eine Lizenz draufzusetzen

und die dann in dem Open-Source-Paket auch tatsächlich zu nennen und logischerweise halt eben auch den Vertragstest mit reinzunehmen, damit dann wiederum der Verwender konkret weiß, unter welcher Lizenz die Software steht. Und da hat man wiederum drei Möglichkeiten. Zum einen, man kann tatsächlich eine proprietäre Lizenz erstellen.

Zweite Variante ist, man nimmt eine standardisierte USS-Lizenz, Apache 2.0 oder dergleichen. Und die dritte Variante ist, man passt halt eben noch eine entsprechend standardisierte Lizenz an oder fügt ihr halt eben noch entsprechende Zusatztexte hinzu. Alles drei tatsächlich möglich.

Jetzt hat man so typische Herausforderungen. Auf die meisten bin ich ja ganz am Anfang in der Einleitung schon eingegangen. Was man zumindest als Unternehmen quasi immer möchte, wenn man Open-Source-Software hat, dann ist die ja zumindest in meiner Beratungspraxis meistens Grundlage für etwas anderes. Also sprich, man entwirft eine Bibliothek und auf diese, also

das weiß ich, um das Rad nicht neu erfinden zu müssen bei Neuentwicklungen und auf diese drauf setzt man halt eben dann für Kunden nochmal so eine individuale Entwicklung mit entsprechender Geschäftslogik. Deswegen möchte man halt eben typischerweise eine Open-Source-Software kommerziell verwenden können und eben dann diese umfassenden Nutzungs- und Änderungsrechte daran haben. Möchte das Produkt auch weiterentwickeln dürfen, also auch unabhängig von

etwaiger Open-Source-Software und etwaigen Contributions. Und dann noch ein viertes Problem, auf das ich vorher nicht eingegangen bin, man braucht gegebenenfalls auch eine Kompatibilität zu bereits eingesetzten bekannten Verbauten. Also was weiß ich, wenn man zum Beispiel Stack-Overflow-Interhalte drin hat oder OpenJDK oder sowas verwendet und eben dann

eine Lizenz einsetzen möchte, dann muss die wiederum kompatibel sein mit dem, was man ohnehin schon hat. Das ist tatsächlich nicht so einfach. Also die Frage, wann möchte ich denn überhaupt eine proprietäre Lizenz verwenden? Und da gibt es für mich tatsächlich eigentlich nur einen relevanten Fall.

Und zwar nämlich genau dann, wenn man die Nützungs- und Verwertungsrechte so einschränken möchte, dass man das mit standardisierten Open-Source-Software-Lizenzen halt eben nicht abbilden kann. Ich persönlich hatte den Fall noch nicht. Es gibt sehr wohl Produkte, die das

nicht stoppt. Ich wollte gerade ein Beispiel nennen, nämlich die Qt-Library, die ja mittlerweile bei Nokia ist. Der hat aber keine proprietäre Open-Source-Lizenz, sondern die ist dreifach lizenziert. Die hat eine proprietäre kommerzielle Lizenz,

die hat GPL und LGPL. Von daher, die haben keine Open-Source-Lizenz angepasst. Sei es drum, den Fall, dass man eine proprietäre Lizenz entwerfen muss, den hat man üblicherweise eigentlich nicht. Vor allem hat man auch das Problem, wenn der Verwender Lizenzscanner einsetzt, wird die Software dort typischerweise nicht eingestuft

und wenn dann eben als rot. Das heißt, oft so viel wie man wird sie als Verwender nicht einsetzen können. Das wiederum kann dazu führen, dass die Open-Source-Software an sich weniger auf dem weltweiten Markt genutzt wird. Dann eben die Frage, standardisierte Open-Source-Lizenz, ja, macht man das? Ja, ich persönlich, meiner Rechtsberatung und auch

meinem Rechtsverständnis nach ist das durchaus und zwar einfach deswegen, weil diese Lizenzen halt eben auch bekannt sind und gut verstanden werden. Das heißt also auch im Grunde genommen, wenn man Software verwendet und man sagt, man hat unter GPL oder unter DSD oder MIT oder Apache lizenziert, das

weiß man. Man kennt vielleicht nicht die Inhalte, aber man weiß, Apache-Permissive-Lizenz, kein Problem. GPL, oh, muss ich aufpassen, aber man weiß zumindest, mit was man da halt eben arbeitet. Insbesondere nahezu alle Open-Source-Lizenzen, also auch gerade die bekannten, die ich gerade genannt habe, ermöglichen quasi immer eine kommerzielle

Verwendbarkeit und gestehen eben auch tatsächlich umfassend, also denkbar umfassenden Nutzungs- und Änderungsrecht dazu und zwar wirklich jedem, also auch Entwicklern, Nützern, wie auch immer. Insofern ist das tatsächlich normalerweise kein Problem, die zu verwenden. Man muss nur aufpassen, wenn man für einen Kunden eine Software implementiert

und die nicht open sourced werden soll. Also was weiß ich, so ein Zusatzpaket zu der eigenen Open-Source-Lizenz, eigenen Open-Source-Bibliothek, dann hat man ja oft den Fall, dass Package Manager nach der Lizenz fragen und nicht

erfahrene Entwickler sagen dann huju, nämlich halt eben auch MIT oder dergleichen. Das stimmt aber nicht, also kann man im Kundenverhältnis nicht machen, weil man ja typischerweise durch Werkvertrag oder was weiß ich, Einkaufsbedingungen des Kunden, dem Kunden da wiederum exklusiv C zusichert und deswegen mit einer MIT halt eben dann in den Rechtsmangel

reinläuft und folglich halt eben dann der Kunde etwaige Schadensersatzansprüche hätte. In dem Fall, also sprich, wenn man hier ein Paket hat, das für einen Kunden entwickelt werden soll, dann schreibt man einfach bei Lizenz rein, dann ist das auch kein Problem mehr.

Ihr kennt alle Open-Source-Lizenzen und die bekanntesten, die ich hier aufgelistet habe, kennt ihr auch alle. Gut, Eclipse vielleicht nicht jeder, davon ab, ob man halt eben aus dem Eclipse-Bereich kommt oder nicht, aber den Rest, das kennt man tatsächlich.

Gerade GPL und die ganzen Copyleft-Lizenzen sieht man zwar immer weniger, aber man sieht sie noch zumindest häufig, aber ganz, ganz häufig und ständig BSD, Apache, MIT und dergleichen ist da wirklich laufen. CDDL hat man gerne auch mal als Alternativlizenz zu GPL. Brauche ich nicht näher drauf eingehen.

Diese Lizenzen kann man in zwei Typen untergliedern, komme ich gleich noch dazu. Das eine sind eben die permissive licenses, also gerade BSD und dergleichen, die so viel sagen wie, nimm meine Software, mach mit der, was du möchtest, aber lass mich in Ruhe. Also verklag mich nicht vor allem. Und GPL und Derivate, die macht das auch so in der Art, aber die sagt wiederum,

ich hab meine Software Open Source gemacht und du solltest das auch tun. Oder, und das ist eben beides, ist das Copyleft, dieser Copyleft-Effekt, oder du mir zumindest die Freiheit lasst, mit meiner Software zu machen, was ich möchte. Und gerade mit dem Satz 2 daher kommt auch tatsächlich dieser Copyleft-Gedanke, der bei den Lizenzen da ist.

Lizenzen, egal zum Open Source oder nicht, haben typischerweise halt eben dann eine umfassende Beschreibung der Lizenzrechte drin. Da hat man bei Open Source Lizenzen üblicherweise halt eben die Möglichkeit der beliebigen, oft auch kostenpflichtigen Weitergabe, die halt eben zumindest möglich ist.

Und das wiederum wird dann eben geknüpft an etwaige Pflichten, wie zum Beispiel muss Copyright-Hinweise beibehalten. Oder man muss, wenn man Änderungen an der Software vornimmt, das mit einem Remark kennzeichnen oder Lizenztexte weitergeben, Quelltext weitergeben, was auch immer steht in der jeweiligen Lizenz drin. Wenn man die Lizenzen nicht durchlesen möchte oder sie nicht versteht, gibt es auch

zwei Websites. Da habe ich die Links in der Präsentation drin, aber auch am Ende der Präsentation nochmal, da werden die Lizenzen tatsächlich gut wiedergegeben, auch in einem einfach verständlichen Englisch. Open Source Lizenzen haben üblicherweise auch super umfassende Haftungsfreistellungen,

und zwar in denkt bei jeder Richtung, also halt eben bei Sachmängeln, also Bugs, wie halt eben auch Rechtsmängeln, sprich halt eben dann Lizenzrechtliche oder Patentrechtliche Fragestellungen. Und dann gibt es manchmal noch so Zusatzanforderungen oder dergleichen, wie halt eben bei der BSD.

Und jetzt so die Frage, da bin ich vorher schon darauf eingegangen ganz kurz, wodurch leiden sich denn die Lizenzen tatsächlich? Klar, natürlich sind die alle unterschiedlich von den Formulierungen und dergleichen, manche ausführlicher, manche weniger ausführlich. MIT, BSD ist ja verschwindend geringer Text, Apache ist halt so viel, GPL so viel und so weiter und so fort.

Das Entscheidende ist aber das Copy Left. Da gibt es Lizenzen, die eben rein permissive sind, also halt eben gar kein Copy Left haben und dann welche mit eingeschränktem und strengem Copy Left. Das bedeutet so viel wie, dass bei dem eingeschränkten Copy Left man

sehr wohl gute Möglichkeiten hat, um diesen Copy Left Effekt herumzukommen. Das können verschieden sein, MPL beispielsweise ist der Copy Left Effekt gleich Null, bei LGPL ist es eben sobald man statisch linked beispielsweise, GPL V2, V3 kommt man ins Copy Left eben tatsächlich auch bei dynamischem Linking schon rein und so weiter

und so fort. Zeitlich bedingt, ich kann es euch tatsächlich leider nicht genau erklären, was in den einzelnen Lizenzen drin steht, ist aber an der Stelle auch tatsächlich gar nicht entscheidend, weil auch das könnt ihr wiederum auf den Webseiten dann entsprechend recherchieren. Wichtig ist nur, dass ihr das Grundprinzip mal verstanden habt. Copy Left an sich,

was bedeutet das denn? Findet man auch im Internet ganz viel dazu, aber das Entscheidende ist, wenn man in einen Copy Left Fall reinläuft, dann bedeutet das so viel wie, dass Veränderungen nur dann erlaubt sind, wenn sie unter den gleichen oder kompatiblen Lizenzbedingungen weitergegeben werden. Der Gedanke

dahinter ist, dass das Urprogramm tatsächlich in seiner Entwicklung sich frei bleiben können soll, sprich halt eben dann ein Autor, sich nicht an etwaige andere Software anzupassen hätte. Das war nämlich so die ursprüngliche Angst, die halt eben ein Richard Stallman und andere Kollegen halt eben hatten. Die dachten sich damals

bestimmt auch berechtigt, dass beispielsweise, wenn ein Unternehmen wie eine Microsoft eine Open-Source-Bibliothek einsetzt, dann man möglicherweise als Entwickler das nicht mehr frei weiterentwickeln kann, einfach deswegen, weil die Software halt eben dann dort schon in irgendwelchen Paketen

drin ist und man das ja auch halt eben möchte, sprich halt man sich dann halt mit dem Verwender abzustimmen hätte. Wenn man aber diesen Copyleft mit diesem Copyleft-Teil war aber der Gedanke der, dass man die Entwicklung tatsächlich weiter frei hat und zwar deswegen, weil man genau diesen Aufsatz mit reingibt, nämlich wenn eine andere Software

die Urbibliothek nutzt und darauf aufbaut, nämlich auf eine Art und Weise, dass man die Urbibliothek nicht mehr ohne Weiteres gegen eine andere Version austauschen kann, dass man eben dann das andere Werk tatsächlich auch unter dieser Copyleft-Lizenz oder einer kompatiblen, das ist typischerweise eben eine Copyleft-Lizenz,

zu lizenzieren hat und deswegen, wie gesagt, das Urprogramm eben auch immer frei bleibt. Das ist das Entscheidende, was wir wissen möchten, vor allem auch als Entwickler, wenn ihr eine Review macht. Die ursprüngliche Software, die ich drunter habe, ist die tatsächlich so eng mit dem neuen Werk verbunden, dass ich sie nicht mehr raustrennen kann und wenn das der Fall ist, auch

je nachdem, wie die Lizenz das vorgibt, dann komme ich eben in diesen Fall eines darauf aufbauen, also Derivative Works und dann komme ich in den Copyleft-Fall rein. Beispiel, bei der GPL genügt dafür ein statisches oder dynamisches Linking, das ist insofern ein bisschen irrsinnig, weil bei dynamischem Linking

kann ich ja sehr wohl die Bibliothek austauschen, aber so einmal dahingestellt, wenn ich beispielsweise von der GPL-Bibliothek den Code reinkopiere in mein Werk, dann kann ich sie nicht mehr rausnehmen. PAP ist so ein anderer Fall wiederum, da kann ich es tatsächlich üblicherweise immer irgendwie rausnehmen, weil PAP eben an sich schon eine Skriptsprache ist und deswegen halt eben

es zu keinem kompilierten Werk üblicherweise zumindest kommt. Kommen wir zu den Unterbauten, die ich vorher erwähnt hatte. Ich sagte ja, wenn man ein neues Werk erstellt, das ist sprich eine Software open sourcen möchte, dann möchte man ja eine Lizenz auswählen können, die wiederum auch

zu den Unterbau-Lizenzen kompatibel ist. Nehmen wir jetzt OpenJDK, das ist GPL 2.0. Das heißt also ganz grundsätzlich, wenn man hier wiederum ein Linking, auch ein dynamisches vornehmen würde, wie es halt bei Java der Fall ist, dann würde man eigentlich auch in den GPL-Fall reinlaufen.

Jetzt hat aber OpenJDK so eine sogenannte Glass Pad Exception mit dabei, die gibt es als OpenJDK-Spezialvariante, gibt es aber auch als eine allgemein verfügbare und die wiederum sagt soviel wie, wenn es tatsächlich einfach nur dynamisch gelingt wird, dann muss das andere Werk auch nicht unter GPL lizenziert werden.

Das heißt also, das wiederum bedeutet, dass man halt eben bei OpenJDK, zumindest in den mir bekannten Dationen, keine Einschränkung der Lizenzwahl hat. Stack Overflow ist an sich ein spannender Fall.

Die wenigsten dürften wissen, dass wenn man bei Stack Overflow Code einstellt, der unter die Common Creatives Share-Alike 4.0-Lizenz gestellt wird. Share-Alike ist so eine Art Copy-Left-Lizenz, bedeutet eigentlich, wenn man jetzt sich Stack Overflow-Code in sein Programm mit rein nimmt, dann

könnte das so viel heißen, wie ich muss halt eben tatsächlich alles Open Source-Lizenzieren, weil ich halt in Copy-Left reinlaufe. Das ist tatsächlich umstritten in der Rechtswelt. Es ist mir persönlich auch bislang noch kein Rechtsurteil dazu bekannt. Vielleicht gibt es eines. Ich weiß, wie gesagt, zumindest von keinem. Ich meine aber auch zumindest meinem Verständnis nach, wenn man

in einen umfassenden Code eben dann, was weiß ich, eins, zwei, drei Zeilen von Stack Overflow reinkopiert, dass das nicht dazu führen kann, dass tatsächlich das komplette Werk auch zu Copy-Left, also sprich halt eben zu Open Source wäre. Es ist und bleibt aber halt eben trotzdem zumindest ein Risiko.

Jetzt mal ungeachtet dessen, wenn ihr Code von Stack Overflow oder allgemein Internet nehmt, bitte immer die Urheberrechtsangabe mit reinnehmen. Wenn keiner dabei steht, dann schreibt halt eben, was weiß ich dazu, Remark, Code von Stack Overflow, Com, Schräger und so weiter und so fort. Plus halt eben dann Copyright und dann halt eben das

Kürzel von demjenigen, unter dem es halt eben reingenommen worden ist. Das ist wieder peinlich, macht jeder von uns so, weil da steht oft gutes Zeug dabei. Und es ist vor allem halt eben dadurch rechtssicherer. Nicht mal aus lizenzrechtlichen Gründen, sondern aus urheberrechtlichen Gründen. Also macht das tatsächlich. So. Jetzt die Frage

wieder zurück. Was für eine Lizenz nehme ich denn tatsächlich? Ich habe hier eine schöne Übersicht gefunden im Internet, habe auch den Link hier mit reingenommen. Wenn man kein Copyleft haben möchte, dann fallen diese drei Lizenzen, die ich da

angegeben habe, mit rein, die man so typischerweise erleben nimmt. Es gibt sicherlich auch noch andere, aber das sind so die bekanntesten. Und da habe ich hier auch die entsprechende Übersicht mal mit reingenommen, die ihr euch dann in Ruhe anschauen könnt. Ich komme gleich noch dazu, welche ich

von denen hier am geschicktesten finde. Man kann die aber tatsächlich alle drei im Wesentlichen verwenden. Deswegen, wie gesagt, ist es im Wesentlichen Geschmackssache. Wenn man tatsächlich Copyleft haben möchte, aus welchen Gründen auch immer, kann man sich überlegen, also zum einen halt eben eine LGPL zu nehmen, dadurch, dass man eben dann dynamisch linken kann. Und, weil Lizenzscanner LGPL

nur als Orange und nicht als Rot kennzeichnen. Und man kann sich auch überlegen, ob man doppel lizenziert mit CDDL oder Aperture License beispielsweise, damit halt eben wiederum der Verwender entscheiden kann, welche von den Lizenzen er verwenden möchte. Und damit fällt man dann auch wieder in diesen grünen Bereich ran. Muss man sich einfach überlegen, was man daran möchte. Ich meine,

dass von den Lizenzen, die Aperture License 2.0 so typischerweise einen guten Kompromiss darstellt. Das heißt also, wenn nicht gefragt wird, ist auch die Lizenz, zu der ich üblicherweise rate. Und zwar deswegen. Die kennt man. Also geläufig. Die ist auch tatsächlich weitestgehend kompatibel zu GPL-Lizenzen. Gibt es im Internet gute Übersichten dazu.

Sie ist vor allem permissive. Sie schützt halt eben vor Patentrechtlichen Klagen, soweit das rechtlich möglich ist tatsächlich. Dann hat man halt eher noch den Vorteil, dass das zu einem Remarking von Änderungen an der Bibliothek verpflichtet. Finde ich tatsächlich gut, um halt eben gerade auch eine Visitenkarte für einen selbst ist.

Man auf die Weise unterscheiden kann, von wem kommt was. Und wenn es halt eben eventuell Kot ist, der nicht nach dem eigenen Geschmack ist, aber trotzdem irgendwie sinnvoll, macht es das Sinn, dass man halt eben sagen kann, das kommt von einem Dritten. Die Haftungsfreistellung, wie ich vorher schon erklärt hatte, greifen zwar nicht. Spielt aber wie gesagt durch den Schenkungsvertrag bei deutschen Entwicklern ohnehin keine Rolle.

Und deswegen braucht man tatsächlich auch zumindest meines Erachtens quasi nicht anpassen. Das hier sind die zwei Internetseiten. Die sind super. Und auch tatsächlich meiner Rechtskenntnis nach bei allen Lizenzen

bislang korrekt gewesen von der Übersicht her. Too long to read legal. Da gibt man einen GPL 2.0. Und dann sagt einem das Ding in ganz einfachem Englisch, was da drin steht. Das ist also quasi ein guter Anhaltspunkt. Natürlich steht da nicht alles drin. Und gerade GPL ist eine Lizenz, die ist ...

Habt ihr euch mal die FAQs von GPL angeguckt? Die ist ja endlos, endlos, endlos, endlos, endlos lang. Zu jedem Case 5 Millionen Möglichkeiten. Das ist gut und sinnvoll, aber im Alltag braucht man es halt eben nicht. Deswegen super Seite. Bookmarkt die euch. Und dann choose a license ist auch nicht schlecht.

Das Ding ist letzten Endes ein Wizard. Da sagt man, was man tun möchte. Und das Ding sagt einem, nimm Apache oder sowas in der Richtung. Natürlich ersetzt das kein Rechtsanwalt. Aber es ist ein Anhaltspunkt. Ist praktisch. Ich habe euch in der Vorschau,

in dem Beschreibungstext versprochen, dass wir uns Oracle gegen Google angucken. Ich gehe da tatsächlich nur kurz drauf ein. Die meisten, also ihr werdet den Fall verfolgt haben. Der Gedanke dahinter war folgender. Es war quasi gefühlt

der hundertelang akzeptierte Praxis, dass man proprietäre APIs nehmen kann, auch nachbauen kann und halt eben kompatible Software erstellen kann dazu. Das hat man einfach so gehandhabt. Das war nie ein Problem. So. Jetzt hat ja Oracle Sun aufgekauft und damit eben auch die Rechte an Java Technik.

Und Google wiederum hat bei Android nicht nur auf Java aufgebaut, sondern auf die IBM Apache Harmony Java Implementierung aufgebaut. Die wiederum tatsächlich die APIs von der Originallösung halt eben nachgebaut hat. So. Jetzt ist das Problem aber,

dass die Google ja keine von Oracle lizenzierte Version verwendet hat, sondern halt eben da diese IBM Version. Jetzt sagt Google, na ja, wir haben doch wirklich nur den reinen Deklarationscode übernommen. Den Fall hat man tatsächlich immer wieder mal.

Ist ja auch gut und sinnvoll. Den Rest haben wir tatsächlich komplett selbst implementiert. Trotzdem ist inzwischen rausgekommen durch die höchstrichtliche Entscheidung der USA, dass man auch daran, also sprich an dem Deklarationscode, sehr wohl ein Urheberrecht hat. Das war in der Vergangenheit nicht so klar.

Ich sage bewusst, die USA in Deutschland ist an sich eine andere Situation, aber geht ja hier eben tatsächlich um genau diesen Fall. So. Jetzt ging das ja tatsächlich in USA hin und her zwischen halt eben den verschiedenen hohen und höchsten Gerichten und kam halt eben dann schlussendlich vor die höchstrichtliche Rechtsprechung. Und da wiederum ist Google mit seiner Argumentation

durchgekommen, nämlich der sogenannten Fair Use Ausnahme, die das US-Urheberrecht so vorsieht, bleibt auch tatsächlich. Das ist, wir haben bei uns im Urheberrecht sogenannte Schrankenbestimmungen, die aber nicht ganz so weit greifen wie Fair Use,

bedeutet aber so viel wie, wenn man die Werke halt eben dann beispielsweise in Wissenschaft oder dergleichen halt eben wiedergibt, man keine Urheberrechtsverletzung hat. Und vor allem ist die Fair Use Regelung in USA sehr viel freier als bei uns in Deutschland oder besser gesagt in Kontinentaleuropa heißt so viel,

wie man kann das auch tatsächlich entsprechend interpretieren. Und so kommt man letztendlich dazu, dass dieser Streit für Google positiv ausgegangen ist und man zumindest nach US-Recht dann die API-Deklaration übernehmen kann. So, in Deutschland wiederum hat man aber tatsächlich

einen recht unflexiblen Schrankenkatalog. Der ist umfangreich, also das sind tatsächlich 15 Regelungen, also es sind viele tatsächlich. In USA hat man nur eine, ich sagte ja vorher schon, USA Casler, bei uns halt eben CodeLaw.

Bei uns ist das unflexibel abgeschlossen und man versucht das vor Gericht hemmsärmelig halt eben durch Ventile dann irgendwie versucht zu erweitern, um tatsächlich, wenn man API-Definitionen übernimmt, die dann auch irgendwie verwenden zu können vielleicht. Das kann man argumentativ auch überlegen,

ist aber tatsächlich risikobehaftet in USA eben durch das dortige Urteil inzwischen nicht mehr risikobehaftet. So, ich weiß, es ist viel Stoff, das wie ich schon sagte, das Thema für zwei, drei Tage. Aber wie gesagt, schaut euch auch gerne nochmal die Präsentation danach an und wenn ihr mögt, könnt ihr mir auch gerne Fragen stellen

per E-Mail, wie auch immer. Wir kommen jetzt nach diesem großen Teil noch zur rechtssicheren Verwendung und Contribution. Da gibt es zum einen das Thema den sogenannten gutgläubigen Erwerbs. Gutgläubiger Erwerbs sagt vermutlich relativ wenigen von euch etwas. Nehmen wir mal an,

ich verkaufe ohne Berechtigung das Notebooks von meiner Freundin und verkaufe das auch sehr günstig und der Käufer findet das super und will das Notebook auch haben und möchte es auch gerne behalten. Jene Freundin sagt aber nö, du durftest das gar nicht verkaufen, das ist mein Notebook.

Und jetzt dann die Frage, an wen wendet die sich? Wendet die sich an mich als unberechtigter Verkäufer? Oder wendet die sich an den Käufer? So, und nachdem das schon gutgläubig heißt, blöde Frage, die muss ich tatsächlich an mich wenden. Der Käufer ist in dem Fall geschützt, das heißt also eher darf das Notebook tatsächlich behandelt. Klar, da gibt es Ausnahmefälle,

Hellerware oder möglicherweise so günstig, dass es halt eben nicht ein legitimes Angebot sein konnte, aber wie gesagt, im Regelfall gutgläubig erworben und deswegen kann sich jene Freundin dann nur an mich wenden und muss halt eben mit mir intern sich ausbreiten, sprich halt eben bei mir halt einen Schadenssatz verlangen. So, diesen gutgläubigen Erwerb gibt es im Urheberrecht aber nicht.

So, wenn man das jetzt wiederum konsequent weiterdenkt, bedeutet das. Schauen wir also mal an, ich habe eine Software entwickelt und verkaufe die weiter an meinen Kunden und irgendwo dazwischen bei mir oder vorher kam es zu einem Bruch in der Lizenzkette, dann bedeutet das, dass der letzte Verwender,

also mein Kunde, dafür auch vollhaftbar ist. Möglicherweise kann er sich auch wieder intern ausgleichen, vertraglich bedingt, aber er haftet tatsächlich anders als halt eben beim gutgläubigen Erwerb, wie gesagt, weil es den halt eben da nicht gibt. Und das wiederum bedeutet eben tatsächlich auch, dass das bei

Open-Source-Software immer irgendwie ein Risiko darstellt, und zwar sowohl wenn man sie halt eben selbst verwendet, als auch wenn man halt eben dazu beiträgt. Bedeutet im Umkehrschluss wiederum, so komme ich eben auch dazu, was ich vorher schon erwähnt hatte, mit den Sub- und Sub-Sub-Sub-Dependencies usw. Wenn man nicht weiß, was da tatsächlich

an Lizenzen vorhanden ist, dann mag es, dann ist da einfach ein gewisses Risiko da, dass es zu solchen Lizenzbrüchen kommt. Und genau deswegen macht es auch Sinn, dass man entsprechende Lizenzscanner oder dergleichen verwendet und bei sich halt eben einbettet. Open-Source-Software an sich kann man üblicherweise in jedem Umfeld verwenden.

Es gibt wenige Lizenzen, die einschränken, aber wie gesagt, das geht. Typischerweise muss man Kopieler Lizenz dem Quelltextpaket beilegen, also sprich GPL definiert das so, wenn man eben tatsächlich das Source-Code-Paket als solches rausgibt. Bei GPL ist strittig, ob der JavaScript-Code, den man im Browser rausgibt, auch schon ein Quelltextpaket ist.

Deswegen, wenn ihr Minification-Einsatz stellt, ist so ein, dass meistens auch das Copyrights drin bleiben und halt eben auch zumindest ein Link zum Lizenz-Stack drin steht. Das ist dann zwar wenn nicht ganz recht sicher, aber es ist zumindest halt eben ein Schritt in die richtige Richtung. Dann, je nach Lizenz, kommt wieder der Link zu der Internetseite, muss man manchmal Änderungen an den Lizenzgeber zurückschicken, zum Beispiel

halt eben dann als entsprechenden Pull-Request oder sowas. Dann kann man dann bei sich keine Git reinpushen. Das ist normalerweise kein Problem. Muss typischerweise auch die originale Urheberrechtsvermerke beibehalten und so weiter. Das könnte tatsächlich der Seite entnehmen und sind aber auch Dinge, die eigentlich halt eben dem

Menschenverstand halt eben so normal auch bekannt sind, wie man macht Urheberrechtsvermerke einfach nicht weg. Wo gebe ich verwendete Lizenzen an? Klar, im Quelltext eigentlich immer. Wenn man eine UI hat, dann macht man eine Lizenzübersicht mit dazu. Wenn man das wiederum hat, dann führt man

auch die, also unterteilt man typischerweise nach Lizenzen und sagt halt eben Apache License 2.0 hat, React, React JS und so weiter, also eben die Unterpakete. Und wenn man ein Gerät hat, das kein UI hat, dann kann man das machen mit einem Label auf dem Gerät. Es genügt aber tatsächlich auch schon, wenn man das in einer Benutzereinleitung

drin hat. Es gibt Lizenzen, bei denen man den Source Code tatsächlich der Open Source Bibliotheken tatsächlich zur Verfügung stellen muss und GPL und Derivate erlaubt, dass man hier ein sogenanntes Written Offer anbietet.

Also es gibt zwei Varianten. Die eine ist, dass man tatsächlich zu jeder Version halt eben dann auch einen entsprechenden Download zur Verfügung stellt oder man hat eben dieses sogenannte Written Offer, in dem man eben dann einschreibt, wenn du mich anschreibst, dann stelle ich dir ein solches Paket zur Verfügung. Letzteres macht tatsächlich meistens mehr Sinn, einfach deswegen, weil man auf die Weise nicht zu jeder Version dann entsprechend das Paket halt eben bei sich dann hosten muss.

So, das hier mit dem abgeleiteten Werk, dem Derivative Werk, da bin ich vorher schon drauf eingegangen, deswegen erkläre ich es hier nicht nochmal. Ihr könnt es euch aber hier nochmal entsprechend nachlesen, da wird es eigentlich ganz gut verständlich raus.

Und wie man mit sowas umgeht, könnt ihr euch denken, für Juristen ist es spannender hier, für Entwickler liegt es nahe, wenn man halt eben auf Linking verzichten kann, dann sollte man es halt eben tun, es sei denn mehr GPL. Wenn es erforderlich ist, dann ist der übliche Weg, mir ist kein besser eingefallen, den Code so abzuspalten, dass man halt eben dann eine Software um das GPL-Paket herumbaut

und dann halt eben dann einen eigenen API-Call halt eben dann dafür entwickelt, dass man halt eben seine eigene Geschäftslogik dann entsprechend nicht open sourcen muss. So, Sack overflow habe ich vorher auch schon erklärt, noch das hier,

aber bedingt dadurch, dass die Zeit jetzt ziemlich am Ende ist, ihr könnt euch den Paragraphen mal durchschauen. Dieser Paragraph hier ist aber immer ein gutes Argument für entsprechende Lizenzscanner, und zwar deswegen, weil man hier tatsächlich recht einfach in eine

strafrechtliche, in eine Straftat reinfallen kann, und zwar dann, wenn man eben Werke bei sich einsetzt, deren Urheber man nicht kennt, und halt eben dann gegen deren Urheberrecht möglicherweise zumindest verstößt. Mit dem Lizenzscanner kann man zumindest nachweisen, dass man halt eben eine hohe Scantiefe hat, und dass man halt eben versucht hat halt eben die Urheber zu finden.

So, wir sind jetzt tatsächlich zeitlich am Ende angekommen. Ganz kurz nur... Ach, haben wir nicht? Noch besser. Dann ich bin trotzdem schnell,

aber ihr könnt es euch wie gesagt hier vor allem nochmal nachlesen, ausführlich und wie gesagt gegebenenfalls auch nachfragen bei mir. Als Unternehmen macht das tatsächlich Sinn, auf jeden Fall Open-Source-Prozesse bei sich einzuführen. Das heißt also, zum einen in CIACD-Prozessen

dann Lizenzscanner einzubauen. Es gibt sowohl Open-Source-Scanner als auch kostenpflichtige Schulungen intern zu veranstalten, möglicherweise auch unter Zuziehung von Rechtsanwälten, die dazu beraten. Ich weiß gar nicht, wie viel es da tatsächlich gibt. Ich mache es selber tatsächlich, aber darum geht es gar nicht, sondern es macht tatsächlich Sinn, sowas mal als

Workshop gemacht zu haben. Ich persönlich mit Unternehmen mache das tatsächlich üblicherweise als so ein eins bis zwei Tage Workshop, wo ich dann hergehe und mit dem Unternehmen zusammen eben dadurch, dass ich auch Entwickler bin, mal die Prozesse, die vorhanden sind, durchgehe und dann tatsächlich hier

dann mit dem Kollegen vor Ort gemeinsam so einen Prozess dann aufbaue, dass man halt eben dann tatsächlich auch eine ganz kurzweilige Geschichte, die man dann tatsächlich hinterher auch so effektiv einsetzen kann. Wenn man Verträge hat mit Kunden, ist ja immer so, dann bitte prüfen, ob da Rechtsmangelfreiheit zugesichert wird, was nicht gut ist, wenn das so sein sollte,

weil Open-Source-Software, da weiß man es einfach nicht, ob sie rechtsmangelfrei ist. Es gibt da aber tatsächlich auch gute Formulierungen für AGB oder Lizenztexte, in denen man Open-Source entsprechend rausnehmen kann. Und wenn man Dienstleister beauftragt, also Subunternehmer oder wenn man Nearshoring betreibt oder dergleichen, dann ist es auch sinnvoll, dass man von denen wiederum sich entsprechende

Lizenzübersichten geben lässt, um da halt eben einschätzen zu können, was man tatsächlich bekommt. Wo kann so ein Prozess dann aussehen? Das sieht jetzt tatsächlich recht einfach aus.

Das ist in der Praxis auch tatsächlich gar nicht so schwer, so ein Prozess bei sich einzubinden. Es sind so viele Kleinigkeiten, die man da entsprechend beachten muss. Also zum Beispiel auch welcher Kunde erlaubt, welche Lizenz. Es gibt viele, also gerade von Konzernen sind Einkaufsbedingungen oft so formuliert, dass man keine Copyleft-Lizenz verwenden darf. Heißt das dann, dass ich auch kein Linux verwenden darf?

Darf ich das dann bei Entwicklungswerkzeugen verwenden und so weiter und so fort? Ist jedenfalls wichtig und kann man halt eben in so einem Prozess dann tatsächlich auch erarbeiten und einbinden. Dann gibt es noch Openchain. Openchain ist ein Projekt, ist ein Zusammenschluss von vielen Großunternehmen,

bei denen der Gedanke war, dass man ein Compliance-Programm für viele Open-Source-Software definiert. Da hat man sechs Ziele mit reingenommen als gemeinsame Standards. Die könnt ihr euch hier entsprechend durchlesen und man kann sich dann auch tatsächlich zertifizieren lassen, dass man diesem Openchain-Standard folgt. Letzten Endes tut man das auch, indem man bei sich einen Prozess einführt.

Die PricewaterhouseCoopers bietet das zum Beispiel an, aber logischerweise auch andere. Bei PwC weiß es alle einfach nur, dass das gemacht wird. Das ist auch schon ein bisschen teuer. Wie auch immer, solche Prozesse machen eben an sich Sinn und Openchain auch, weil das ein Projekt ist, ein Standard ist, der sich tatsächlich

immer mehr durchzusetzen hat zumindest. Das haben wir schon besprochen mit Haftung und Haftungsfreistellung, wann die greift und wann nicht. Dann hier noch die Frage der Kompatibilität von Lizenzen. Da gehe ich tatsächlich auch nicht näher drauf ein. Aber ganz kurz gesagt,

Lizenzen wie GPL sind oft, also typischerweise, nicht mit anderen Lizenzen kompatibel. Das heißt, wenn man ein neues Werk kreiert und dort eben auf GPL aufbaut und dann in den Copy-Left-Fall reinläuft, dann ist es sehr schwer, dafür eine andere Lizenz zu finden, als halt eben GPL, eine etwaig kompatible.

Das ist ein Thema, auf das gehe ich wirklich nur noch ganz kurz ein, ist auch das letzte, das wir jetzt haben, nämlich Lizenzscanner. Das ist insofern wichtig, weil diese Informationen hier, die kriegt man nämlich ganz selten nur. Und zwar deswegen, weil es meiner Erfahrung nach zumindest nicht einfach ist, an diese Unternehmen ranzutreten und von

denen Informationen zu bekommen, was die einzelnen Lizenzscanner können. Die zwei bekanntesten sind Black Duck, hier Synopsis und White Source. Die anderen ziehen alle nach und sind auch gut am Nachziehen, aber White Source und Black Duck, also White Source war ursprünglich mal hinter

Black Duck, mittlerweile hat es es überholt, sind vom Funktionsumhang her halt eben tatsächlich ziemlich vergleichbar. Zugleich aber im Übrigen auch relativ ähnlich recht teuer. Unterschied bei Black Duck ist vor allem, das ist auch das, was häufiger bei Konzernen eingesetzt wird, so ganz nebenbei, die haben schlicht

ein gefälliges UI, das merkt man wirklich deutlich, White Source ist gut, hat tolle Features drin, keine Frage, wie zum Beispiel auch automatisiert das Update von Libraries, wenn sie veraltet sind, was das Sicherheitsaspekt ist, aber das UI ist nicht gut, wirklich nicht. Man kann damit arbeiten, aber

Black Duck ist ein gutes Juall, wirklich. Also, wenn ihr die Wahl habt zwischen den beiden, dann ist Black Duck typischerweise auch das, wofür man sich allein schon deswegen entscheiden möchte, weil man einfach Lust drauf hat, damit zu arbeiten. Beide kann man aber gut einbinden, in CI-CD-Prozesse, aber auch in die eigene Entwicklungsumgebung. Sprich also, was weiß ich,

zwischen Studio Code oder dergleichen, wird einem gleich gesagt, hey, setz den GPA-Bibliothek ein, pass auf, kannst halt eben dann auch beispielsweise mit entsprechenden Ausschlusskriterien verbinden. Kannst halt eben sagen, beim Kunden XY darf man das nicht einsetzen, deswegen darfst du das auch hier nicht mit reinnehmen. So als Beispiel nur. Also, es ist tatsächlich gut, das bei sich auch im Prozess drin zu haben.

Sieht dann bei White Source so aus, das durchsucht die ganzen Bibliotheken, im Übrigen auch Binärcode, und sagt einem dann letzten Endes, ob man was da gut ist und was nicht gut ist. Und hier diese ganzen Permissive-Licences werden halt eben dann als grün und unproblematisch angezeigt, während halt eben hier LGPL-CDDL halt eben dann als orange,

aber typischerweise verwendbar, und halt eben dann hier andere Lizenzen, wie halt eben der GPL dann als rot gekennzeichnet, bei Glasspath. Deswegen, weil man bei Glasspath nicht ohne weiteres weiß, ob man halt eben die Bedingungen dort reinhält. Bei Eclipse übrigens aus dem selben Grund, obwohl der Eclipse eigentlich auch eine schwache

Copy-Left-Lizenz ist. Genau. Das sind die Links. Könnt ihr euch einen Screenshot davon machen oder dann auch die Präsentationen von mir anfordern, die ich sinnvoll finde. Und das war's dann mit sechs Minuten Verspätung. Wir haben auch viele Späte angefangen. Entschuldigt noch mal, das sind meine Kontaktdaten, E-Mail-Adresse und meine Telefonnummer.

Und jetzt herzlichen Dank fürs Zuhören. Ja, vielen Dank für den Vortrag. Jura Wiski kannte ich schon, Jura Mocker war mir jetzt neu, aber war mal eine ganz spannende Erfahrung. Wir haben die Möglichkeit,

wenn ihr Fragen habt, kommt bitte in die Videokonferenz und schreibt sie da ins Chat. Dann lese ich die vor und stelle die. Dann können wir sie noch durchgehen. Wie gesagt, wir haben noch ein bisschen Zeit bis zum nächsten Vortrag. Der nächste Speaker war schon da. Da weiß ich auch, dass die Technik funktioniert. Da haben wir jetzt gerade nicht so wahnsinnig viel Stress. Es gibt eine Anmerkung im Chat von während des Vortrags.

Da sagt jemand, privat würde er ungern an dem Projekt mitarbeiten, da unter Permissive-Lizenz steht. Um zu vermeiden, dass der Code in proprietieren Produkten landet. Ist das denn so, dass ich dann wirklich davon ausgehen muss, dass der Code quasi geklaut wird und ich ihn gar nicht mehr sehe und der für irgendwas benutzt wird?

Ja, das ist eine legitime Anmerkung. Absolut. Das ist so. Also, ich muss davon ausgehen, die Frage ist ja, vor welchem Hintergrund ich das mache. Und der Kollege sagt das ganz richtig. Das ist ja auch so der Gedanke bei einer Copy-Left-Lizenz, dass man eben genau das verhindern möchte. Und wenn man das tatsächlich möchte

und dann eben sagt, okay, ich nehme das in Kauf, dass mein Produkt dann gegebenenfalls weniger häufig verwendet wird oder halt eben dann umfangreiche Freigabeverfahren durchlaufen müsste in Konzernen beispielsweise. Dann ist das völlig legitim, das so zu sehen und zu machen.

Das macht im Übrigen GPL, der GPL dergleichen auch nicht schlechter. Also, wie gesagt, völlig legitim, das so zu machen. Auch noch die Anmerkung, dass er bei Unternehmen auch darauf zu raten würde, sich Gedanken darüber zu machen, gerade im Cloud-Umfeld

und da würde zu A-GPL beraten. Das geht vielleicht mit Konsequenzen wahrscheinlich auch. Die A-GPL ist im Vergleich zur GPL vor allem insofern unterschiedlich, weil die das sogenannte ASP-Schlupfloch der GPL behebt. Bei der GPL, wenn man eine Software einfach nur übers Internet ausspielt,

also was weiß ich als eine SAS-Software oder dergleichen, dann gilt das klassischerweise halt eben nicht als eine Verteilung im Sinne von GPL. Das heißt also, man fällt halt hier schon gar nicht in den Fall rein, dass man open sourcen muss. Bei der A-GPL hingegen ist das nicht so.

Bei der A-GPL ist auch schon eine SAS-Lösung verteilpflichtig. Das kann man auch machen, keine Frage. Aus der Erfahrung heraus, wenn man das tun möchte, Konzerne reagieren darauf sehr empfindlich.

Ich darf es namentlich nicht nennen, aber ich weiß von mehreren Konzernen, bei denen ich, egal wen es beratet, also egal ob Konzerne oder eben denjenigen, der für den Konzern entwickelt, da wird A-GPL nicht akzeptiert. Und deswegen fallen dann halt einfach diese Produkte raus. Das ist legitim, bedeutet aber eben genau das im Endeffekt, dass man möglicherweise die Software dort eben dann nicht eingesetzt bekommt,

nicht unterbekommt. Muss man einfach wissen, wenn man diese Lizenz dann eben einsetzt. Oder man sagt, man lizenziert doppelt. Kann man auch machen. Die nächste Frage und dreht sich jetzt darum, was man beachten muss, wenn man Floss-Software erstellen möchte.

Die Dateien verarbeitet, die aus proprietary Software kommen, oder die von proprietary Software erstellt wurde, der Lizenzgeber dieser proprietary Software verbietet Reverse Engineering. Aber die Daten werden in offenen Formaten gespeichert, also SQLite, XMLJS und CSV, eventuell komprimiert. Da ist die Frage, ob es Unterschiede gibt

beim Bearbeiten der ursprünglichen Daten oder Exporter des proprietary Schemas und erstellen von abgeleiteten Daten aus diesen Daten. Also sowas wie ein Dateityp-Converter aus proprietary Formaten zum Beispiel. Da kann ich spontan nicht drauf antworten. Das ist so.

Also ihr wünscht euch ja, wenn dann eine Antwort mit der ihr was anfangen könnt. Das muss ich echt nochmal reingucken. Vielleicht kann man das irgendwie nochmal offline klären. Ja, also ich muss ja irgendwie das Dateiformat für die Reverse Engineering eventuell oder so.

Ich verstehe es gerade nicht. Ich schaue es mir gerne offline an und Antwort kommt. Ich schreibe das dann gerne in den Chat rein. Oder an den Kollegen. Meine E-Mail-Adresse ist ja eingeblendet. Gerne auch mich kurz per E-Mail anschreiben.

Und bitte daran denken, das geht dann tatsächlich schon so ein Fall von Rechtsberatung rein. Da muss ich tatsächlich auch selber ein bisschen vorsichtig sein. Aber sei es so. Also ich kann es tatsächlich hier spontan nicht beantworten. Es tut mir leid. Ich habe noch eine Frage,

die mir im privaten Umfeld jetzt in letzter Zeit häufiger durch die Füße oder vor die Füße gefallen ist, dass Leute bei größeren Konzernen anfangen wollen zu arbeiten. Und in den Arbeitsverträgen stehen dann solche Closing, dass alles, was sie an das Software auch in ihrer Freizeit schreiben, zu lizenzieren ist an den Arbeitgeber. Und im Prinzip der Arbeitgeber erst mal alle Rechte daran hätte.

Gilt dann natürlich auch für Open Source-Projekte, in denen sie an ihrer Freizeit vielleicht weiterarbeiten und so. Ist da irgendwie eine Einschätzung, ob das legal ist, beziehungsweise was der Arbeitgeber eigentlich verlangen darf? Kein Arbeitsrechtler. Aber er macht sowas.

Ja, so größere Konzerne durchaus wohl. Da willst du ja nicht hingehen bei sowas. Ich halte es für bedenklich.

Also sagen wir es mal so. Konzerne nehmen sich viel raus. Die AIB von Konzernen sind bedenklich. Auch da wieder. Und Arbeitsvertrag ist typischerweise eben auch agb-rechtlich zu beurteilen. Also ich muss gestehen, ich halte das für bedenklich. Einfach vor dem Hintergrund,

dass man ja im Urhebergesetz hier schon eine sehr weitgehende rechte Abtretung hat, aber die halt eben ja bewusst nur im Arbeitsverhältnis stattfindet. Das heißt also, man hat da hier tatsächlich eine Regelung, die eigentlich gegen das geltende Recht spricht.

Und wenn ich eben privat eine Software entwickle und das wirklich in meinem privaten Umfeld, wenn das sowas ist wie, was weiß ich, ich habe bei meinem Arbeitgeber 80-20 Regelungen, also sprich, ich habe 20 Prozent der Zeit, wo ich nicht an Projekten arbeiten muss. Sowas gibt es ja. Dann ist es ja immer noch was, was mein Arbeitgeber bezahlt. Sowas ist ja völlig okay, dass man dann halt eben sagt,

naja, der Code, der da entsteht, gehört aber schon auch mir. Aber wenn ich es wirklich privat mache, dass dann auch tatsächlich an meinen Arbeitgeber abtreten zu müssen, ich halte es für bedenklich zumindest. Lizenzen eine Räume. Joa, das halte ich. Dann eine letzte Frage. Vielleicht eine einfache Lizenz.

Okay, das ist okay, aber exklusiv. Ein Kollege schreibt hier, was genau Mehrfachlizenzierung ist. Entschuldigung. Wenn man GPL mit MIT kombiniert, welches Copyright dann gelten würde, also wie das da genau

mit der Mehrfachlizenzierung aussieht. Das geht. Mehrfachlizenzierung bedeutet, dass ich mir als Verwender aussuchen kann, welche Lizenz ich akzeptiere, also sprich, welchen Lizenzvertrag ich abschließe. Und MIT hat da gar kein Copyright drin. Das heißt also, wenn ich sage,

ich verwende ein bestimmtes Produkt unter der MIT, dann gilt das Copyright einfach nicht. Dann kann ich das frei verwenden. Also das geht sehr wohl auch. Ob das dann für die Subdependencies von einem Produkt gilt, das sei mal dahingestellt. Aber an sich ist das möglich. Deswegen hat man das tatsächlich auch.

Ah, USA. Ja, okay. Da USA ist wieder ein anderer Fall. Aber gehe ich gleich noch drauf ein. Deswegen hat man das gerne auch. Deswegen hat man das auch gerne, dass man bei GPL zum Beispiel zwei oder drei Lizenzen noch dazu hat, wie halt eben eine CDDL oder dergleichen. Im Lizenzscanner dokumentiert man es dann so,

dass man halt eben dem Produkt eine entsprechende Lizenz zuweist. Und dann gilt dann diese tatsächlich. Also dann fällt man das Copyright nicht rein, was dann sehr vorteilhaft ist. Danke für den Hinweis. Das bei Heise hatte ich tatsächlich nicht gesehen. Das ist interessant zu wissen.

Meine Beispiele waren deutsche Arbeitsverträge, aber größere Konzerne. Aber gut, das ist egal. Danke für den Vortrag nochmal. Wenn ihr Zeit und Lust habt, gerne raten und Feedback geben. Da freuen sich die Vortragenden als auch die Organisation Organisatoren

der Froscon drüber. Hier geht es gleich um 16 Uhr weiter. Etwas techniklastiger wieder mit TermPaint, einer modernen Low-Level-Terminal-Abstraktionsschicht. Also Text-User-Interface wieder. Mir hat es Spaß gemacht. War mal was anderes und mal ein bisschen ein bisschen was zum Anfassen auf die andere Art.

Und mich gefreut. Und viel Spaß noch bei der Froscon allen. Bis nächstes Mal. Vielen Dank. Tschüss. Vielen Dank euch. Tschüss. So, damit ist der Stream dann aus.

Ich mache die Konferenz auch kurz zu. Dann haben wir nämlich eine Schnittmarke für den nächsten Vortrag. Dann ist das Chat allerdings kurz weg. Und alle sind draußen. Das heißt, Text-Schell, du bist es gleich nochmal neu reinkommen. Dann schalte ich dich wieder frei. Und dann geht es hier. Perfekt. Wunderbar. Ganz herzlichen Dank. Ich danke. Und sorry, dass ich dich auf den Telefonhörer

geschickt habe, der nicht da war. Alles super. Das entschuldigt, dass es bei mir auch so unkoordiniert war. Die fünf Minuten hätte man sich echt schenken können. Ach, da habe ich nichts von bemerkt. Das war okay. Alles gut.

Alles klar. Dann viel Erfolg noch. Und schönen Nachmittag. Bis dann.