Recht interessant

In dieser Folge haben wir Laurent Meister, Partner IT & Privacy Law bei RSM Ebner Stolz, zu Gast und reden über Datenschutz (DSGVO), (Open Source-)Lizenzen und dem bald kommenden AI Act. Es gibt sicherlich deutlich spannendere und technischere Themen als Entwickler, kann dieses Wissen in der Praxis aber auch nicht schaden. Jura und Programmierung sind doch irgendwie näher miteinander verwandt, als man denkt. Viel Spaß bei dieser Folge ✌️

Lasst uns gerne mal Feedback zukommen – über Instagram, LinkedIn oder per E-Mail an [e-mail]. Du möchtest gerne mit uns über ein Thema sprechen? Sehr gerne!

Laurents Profil auf LinkedIn: https://www.linkedin.com/in/lmeister/

Nachtrag: In der ersten Version war die Sound-Qualität z.T. schlecht. Das ist jetzt bestmöglich nachgearbeitet.

Creators & Guests

Host

Jan van Heesch

Host

Raphael Jasjukaitis

Guest

Laurent Meister

What is Entwicklerleben?

Entwicklerleben ist ein Podcast, der tief in die vielschichtige Welt des Softwareentwicklers eintaucht. In jeder Folge erkunden wir ein neues Thema, das direkt aus dem Alltag von Entwicklern stammt. Ob es um die Herausforderungen beim Kodieren, die neuesten Trends in der Technologiebranche oder um Work-Life-Balance geht – hier wird alles besprochen.

Hörer können Einblicke in verschiedene Programmiersprachen erwarten, von Python bis Java, sowie Diskussionen über Softwarearchitektur, Frameworks und Tools, die Entwickler im Arbeitsalltag nutzen. Wir sprechen auch über die weicheren Aspekte des Berufs, wie Teamarbeit, Projektmanagement, und den Umgang mit Stress und Deadlines.

Neben technischen Themen beleuchten wir auch die Karrierewege in der Softwareentwicklung. Interviews mit erfahrenen Entwicklern bieten Inspiration und Ratschläge, wie man in dieser sich schnell verändernden Branche erfolgreich sein kann.

Egal, ob du ein erfahrener Entwickler bist oder gerade erst mit dem Programmieren beginnst, "Entwicklerleben" bietet wertvolle Einblicke, Tipps und Geschichten, die dich sowohl unterhalten als auch informieren werden.

So, es ist mal wieder Zeit für eine neue Folge Entwicklerleben.

Herzlich willkommen zurück.

Ja, wir sind euch eigentlich ein Thema schuldig vom letzten Mal,

aber wir haben heute spontan einen Gast da und deswegen kleine Änderungen im Fahrplan.

Wir dachten uns, lass uns doch mal über etwas sehr, sehr Spannendes reden. Thema Jura.

Jan und ich haben da einen gewissen Background im privaten Sinne und ich glaube,

es ist ein bisschen so gefährliches Halbwissen angeeignet in den letzten paar Jahren.

Sehr gefährliches Halbwissen.

Und ja, aber wir haben jetzt Laurent als Gast, der sich tatsächlich auf IT-Recht

spezialisiert hat und es gibt eigentlich so mittlerweile einige verschiedene

Themen, wo ich der Meinung bin als Entwickler, dass man die auch mal im Mittagkopf behalten sollte.

Heute sicherlich jetzt nicht das tägliche Geschäft, aber ja,

es hat sich ja doch einiges geändert.

Stichwort Cookie-Beiner zum Beispiel, was man irgendwie beachten sollte.

Und ich würde mal sagen, herzlich willkommen, Laurent.

Hallo, vielen Dank für die Einladung. Freut mich.

Magst du dich vielleicht mal ganz kurz vorstellen?

Ja, gerne. Also vielleicht kurz zu mir. Ich bin auch Meister.

Ich bin Rechtsanwalt bei RSM Ebner-Stolz im Büro in Stuttgart.

Und wie du schon gesagt hast, Schwerpunkt IT-Recht, Datenschutz,

alles, was mit Digitalisierung zu tun hat und damit auch, ich sag mal,

viel mit Softwareentwicklern zu tun und eben bei Unterstützern,

so geht es, sich eigentlich Themen zu klären oder zu prüfen,

ist eine Software rechtskonform oder nicht.

Das sind so meine Schwerpunkt-Themen, die ich so Tag ein, Tag aus tatsächlich bearbeite.

Ich würde mal das erste Thema anfangen, bevor es nachher vielleicht ein bisschen zu trocken wird.

Thema Side-Projects. Das betrifft ja auf der einen Seite Open-Source,

aber dann auch, ja ich sag mal, arbeitsvertragstechnisch etwas.

Was wäre denn, wenn der Arbeitgeber sagt,

Man darf keine Projekte nebenbei machen, ist dann trotzdem so ein Open-Source-Projekt trotzdem möglich?

Wie sieht es dort mit Lizenzen aus?

Was muss man dabei beachten? Also ich zum Beispiel habe jetzt persönlich meistens

die MIT-Lizenz benutzt, auch eher so aus Copy-Paste-Sicht, würde ich mal sagen,

aber ohne jetzt zu überlegen, okay, was hat das für einen Impact?

Eine kommerzielle Nutzung, nicht kommerzielle Nutzung, muss ich dann selber

Support anbieten, genau.

Ja, ich glaube, das sind so ganz typische Fragen, die man sich als Entwickler

stellt oder die auch Unternehmen haben, die Entwickler in Festanstellung als

Freelancer oder wie auch immer tatsächlich beschäftigen.

Da kommt es, wie der Jurist so schön sagt, es kommt drauf an,

es kommt tatsächlich so ein bisschen drauf an, wie sieht eigentlich die Zusammenarbeit aus?

Gerade im Bereich der Festanstellung muss man bei Side-Projects natürlich so

ein bisschen aufpassen.

Wenn das noch in den Scope der eigentlichen Arbeitstätigkeit fällt,

dann wird das vielleicht schwierig.

Ich glaube, alles, was wirklich davon losgelöst ist, ist tatsächlich unkritisch zu sehen.

Ich glaube, das ist so ein bisschen die Trennlinie. Und ich sage mal,

je freier und unverbindlicher die Zusammenarbeit ist, Das heißt,

als Freelancer oder ganz klassisch als Dienstleister,

dann wird es sowieso unproblematisch, wenn man tatsächlich nebenher noch Themen entwickelt.

Die Grenzen können aber tatsächlich fließend sein. Insbesondere,

wenn man sagt, ich habe jetzt aus einem Projekt, aus der alltäglichen Arbeit

als Softwareentwickler irgendwie Know-how gewonnen und sage,

ich will auch tatsächlich in dem Bereich tätig werden.

Genau, dann muss man wahrscheinlich tatsächlich ein bisschen aufpassen,

ob das nicht tatsächlich die

geschuldete Entwicklungstätigkeit für den Arbeitgeber oder den Kunden ist.

Aber ansonsten ist man tatsächlich an der Stelle frei, auch wenn es in einem

anderen Zusammenhang ist, die Themen abzuschließen.

Zu entwickeln und zu treiben und möglicherweise auch tatsächlich dann,

ich glaube, das ist generell ein Thema, Open-Source-Software einzusetzen und

dann eben das möglicherweise auch unter entsprechenden Lizenzen zu veröffentlichen

oder auch kostenpflichtig zu veröffentlichen.

Da muss man natürlich immer noch schauen, tatsächlich, wie ist da der Arbeitseinsatz,

der dann dahinter steckt und kannabilisiert er möglicherweise die anderen Projekte

oder die eigentliche Arbeitszeit? Ja, das sollte natürlich nicht passieren.

Also das ist jetzt so ein bisschen der Hintergrund und ansonsten,

weil du es eben schon ansprachst, das Thema, gerade wenn man so freie Projekte

dann macht oder sagt, ich habe so ein Zeitprojekt, ich lanciere dann ein Stück

Software auch unter einer Open Source Software,

das spricht per se erstmal nichts dagegen.

Du musst natürlich tatsächlich dann sehen, was ist da alles eingeflossen,

was ist dann das Ergebnis möglicherweise auch,

was die Lizenz tatsächlich dann von dir verlangt, Auflegung des Quellcodes oder

ähnliches, insbesondere wenn da natürlich welche Know-how anderer reinfließt,

wird es vielleicht ein bisschen schwieriger,

aber tatsächlich, du bist natürlich freier, weil jeder kann es verwenden und

du musst jetzt nicht zwingend da irgendwie großen Support und Pflegeaufwand mitbringen,

wie das halt bei einem kommerziellen Produkt ist, dass du dann vertreibst,

lizenzierst, irgendwie ein Entgelt verlangst,

und dann natürlich immer das doch das thema hast dass du möglicherweise mängel

beseitigen muss wenn es die software dann doch mal nicht tut in europa wir auch

bereich der software anders als in den usa doch einen relativ strengen gewährleistungsrahmen

was welche mängel oder zielfunktionen in,

Aber das ist halt die größte Ausforderung.

Was bedeutet jetzt Gewährleistung in dem Sinne auch jetzt im Bereich Open Source

oder sobald man es kommerziell macht?

Weil wenn ich jetzt irgendwie an Gewährleistung denke, denke ich an Werkvertrag,

das ist aber schon wieder im Dienstleistungsbereich.

Das heißt, wir haben eine gewisse Abnahme oder sind noch irgendwelche Mängel,

die im Nachhinein da sind.

Das hat man ja schon eher dann, ich sag mal, früher eher festgelegt als heute,

wenn man eher agil arbeitet. Das ist halt auch nochmal, glaube ich, so ein Ding.

Da kann man ja gleich nochmal drauf zurückkommen. Aber wie ist das dann mit

Gewährleistungen in Open Source? Weil eigentlich ist ja dann Fix doch selbst.

Genau, also tatsächlich, das ist ja der Vorteil von der Open Source Software.

Ganz häufig werden sie zumindest mal auch nach diesen amerikanischen Lizenzen

oder amerikanisch geprägten Lizenzen, Gewährleistungsrechte und Haftungsthemen

weitestgehend ausgeschlossen.

Da kann man sich mal überlegen, ist das in Deutschland oder Europa?

War eigentlich zu wirksam, aber der Charme ist natürlich tatsächlich,

der Nutzer kriegt das Recht, die Software selbst zu bearbeiten und im Zweifel

eben hat alle Werkzeuge, er kann die Open-Source-Software selbst verändern.

Also deshalb tatsächlich da ist das Gewerkschaftsthema nicht ganz so dramatisch,

eben ich bezog mich da mehr auf die Fälle, wo du sagst, ich lizenziere das gegen

ein Entgelt, sei es als Kauf, sei es als Miete, aber wie auch immer das dann tatsächlich ist.

Und da ist natürlich dann immer die Pflicht tatsächlich, wenn die Software eben

tatsächlich nicht tut oder bei einem Software-as-a-Service-Dienst,

der Server irgendwie steigt und das Tool irgendwie nur zwei Stunden am Tag statt,

acht oder was auch immer erreichbar ist, dann hat man natürlich tatsächlich

irgendwie die Verpflichtung da, ich sag mal, aufzuräumen und zu sehen,

dass der Fehler möglicherweise beseitigt wird.

Das ist möglicherweise dann zeitaufwendiger, als man eigentlich beabsichtigt.

Du hattest gerade schon angeschnitten, dass Open Source,

die sagen wir mal aus Europa oder Deutschland kommt und unter einer amerikanisch

angehauchten Lizenz, also MIT oder Apache oder sowas, dass das vielleicht gar

nicht unbedingt so passen könnte.

Habe ich das richtig verstanden? Also, dass es tatsächlich Fälle gibt,

wo darüber gesprochen wird, ob denn die Veröffentlichung aus Deutschland unter

so einer Lizenz richtig ist?

Richtig würde ich gerne nochmal sagen. Ich glaube, richtig ist sie im Zweifel

schon. Die Frage ist nur tatsächlich, ob das, was in den Lizenzen so drinsteht,

insbesondere selbst wenn man so eine kurze Lizenz wie die MIT nimmt,

irgendwo steht natürlich drin, die Software wird, es ist, bereitgestellt.

Das heißt, ohne oder ausschluss jeglicher Gewährleistung und Garantie.

Für den Juristen sind solche Bedingungen natürlich allgemeine Geschäftsbedingungen,

weil die vorformuliert sind, weil die massenhaft verwendet werden und dementsprechend

sind da hohe Anforderungen nach deutschem Recht geknüpft in anderen Ländern.

Und es gibt wenig Rechtsprechung, gewisse Gründe zur Open-Source-Software,

aber zumindest mal die GPL ist schon mal eindeutig als AGB eingestuft worden

und wo auch schon wirklich Teile einfach nach deutschem Recht,

ich sage mal in Anführungszeichen, für unwirksam erklärt wurden.

Also das ist so ein gewisses Risiko, wenn man Open-Source-Software veröffentlicht.

Auf der anderen Seite, man verdient damit ja im Zweifel kein Geld oder man nicht

durch die Lizensierung zumindest.

Und damit sind auch die Risiken de facto relativ gering.

Das ist auch der Grund, warum es tatsächlich wenig Rechtsprechung dazu gibt, weil...

Eine MIT-Lizenz landet am Ende des Tages ganz selten vor Gericht.

Bei einer GPL oder einer Copy-Left-Lizenz schon eher, weil jemand sagt,

hey, ich will aber auch die Quellcode haben, obwohl du die nicht veröffentlicht hast.

Da kann das schon eher mal ein Thema sein. Nein, aber deshalb de facto,

also aus der einen juristischen Brille, würde man bei vielen der Lizenzen sagen,

ob das alles so hält, ob das alles so wirksam ist,

wäre eben in Europa, anders als in den USA, eher fraglich.

Aber rein praktisch spielt es im Zweifel keine Rolle. Und da ist tatsächlich,

glaube ich, auch aus der Open-Source-Sicht, oder wenn man mal die Open-Source-Denke

sich vornimmt, eher wirklich der Fokus auf den Nutzungsmöglichkeiten.

Also was kann ich denn damit machen?

Was habe ich denn für Einschränkungen? Und sind die eben tatsächlich wirksam?

Ja, ich glaube, da geht aber auch der Weg tatsächlich sehr stark,

dass immer mehr Projekte unter MIT auch veröffentlicht werden.

Wahrscheinlich, weil es am angenehmsten für alle ist. Da kann nicht viel passieren.

Diese Datei hat, weiß ich nicht, vier Zeilen oder so. Das ist überschaubar,

wenn man sich GPL oder Apache 2.0 oder sowas nimmt. Da muss man ja schon mal

eigentlich erstmal alles komplett durchlesen, weil man gar nicht weiß,

was da so großartig drin steht.

Klar, wenn man natürlich ein Projekt hat, was man sagt, ich will das mit allen

teilen, aber ich will halt nicht, dass das nachher in kommerzieller Software

eingesetzt wird, weil das wird MIT halt am laufenden Band. Ich kenne das ja

auch aus dem täglichen Geschäft.

Wir brauchen irgendeine Bibliothek oder sowas. Dann habe ich zwei Stück zur Wahl.

Einmal MIT ist nicht ganz so gut, aber MIT und die andere ist,

weiß ich nicht, GPL, da brauche ich gar nicht lange drüber nachdenken.

MIT, zack, gezogen. Ich brauche das nicht mal nachweisen.

Ich gebe das vielleicht irgendwo nochmal an, welche Bibliotheken ich habe und

dass die unter MITs Ende.

Ende, während bei allem anderen, man ja nochmal gucken muss,

darf ich das verwenden, ist das okay, muss ich meine eigene Software dann unter

einer bestimmten Lizenz veröffentlichen oder wie sieht's da aus,

Und zumindest ist mein Gefühl, dass in der Web-Welt, Web-Entwicklungswelt,

sehr, sehr, sehr, sehr, sehr viel MIT ist.

Und das Gefühl ist, dass das immer mehr wird.

Also ich glaube auch insgesamt ist die MIT-Lizenz oder die BSD,

je nachdem, welche Ausgestaltung man wieder hat, sind die weit verbreitetsten

Open-Source-Lizenzen.

Und auch das ist tatsächlich genau der Punkt, vielleicht auch das,

wo wir aus rechtlicher Sicht immer wieder die Berührungspunkte haben.

Ganz häufig ist es ja so, ich habe kein...

Rein rassiges Open-Source-Projekt, sondern ich habe im Zweifel einen Auftraggeber,

der sagt, ich will irgendwie ein Tool haben, das eine bestimmte Funktion ausführt,

möglicherweise kombiniert mit proprietärem Code, der möglicherweise eine Maschine

steuert oder irgendwelche Funktionen als Treiber,

als was auch immer, und dann eben kombiniert mit anderen Softwarekomponenten,

die dann meistens einfach aus Kostengründen Open-Source sind.

Und wenn man dann natürlich an der Stelle zwischen dieser Kombination aus einem

proprietären Code und einem Source-Komponent dann auf einmal in den Copy-Left-Effekt reinlaufen,

dann wird es natürlich kritisch, weil dann auf einmal die Gefahr da ist,

dass dieser eigentlich schützenswerte, proprietäre Code dann auf einmal möglicherweise

veröffentlicht werden müsste.

Und das ist ja immer der große Knackpunkt, warum tatsächlich dann man tunlichst

aufpassen sollte, eben, will man wirklich ja, Copyleft-Lizenzen wie GPL,

LGPL ja auch immer nutzen.

Ah, schwierig wird es natürlich immer, genau dann, wenn ich irgendwelche Bibliotheken

oder Treiber habe, die es halt nur in der Form gibt, ja.

Und es ist mittlerweile extrem schwer nachzuverfolgen, wenn ich jetzt irgendwie

an NPM oder irgendeinen anderen Packet-Manager denke, der halt 20.000 Dependencies

mittlerweile reinlädt.

Also es ist ja wirklich, man kann es ja eigentlich gar nicht mehr nachvollziehen.

Mir ist das aber auch, glaube ich, kein Tool bewusst. Ich weiß nicht,

also es gibt sicherlich Anbieter, aber die kosten wahrscheinlich auch wieder

nachher ein Schweinegeld, weil das ja in Richtung Enterprise geht,

die diese komplette Kette ja nachvollziehen.

Weil man kann es theoretisch einmalig machen.

So, dann updatet sich aber hier ein Paket, da ein Paket. Ist es immer noch die

gleiche Lizenz und so weiter? Ich meine, man hat das gleiche Problem auch aus

Security-Perspektive.

Aber moderne Softwareentwicklung ist so, da gibt es 20.000 Dinge.

Ich weiß gar nicht, was da alles mittlerweile drin ist, was ich mir ziehe,

wenn ich sage, ja, ich hätte nur dieses eine kleine Paket.

Das ist gar nicht mehr möglich und auch wahrscheinlich machen sich da auch viele

gar keine Gedanken, so das heißt, nicht jede Lizenz ist ja mit jeder kompatibel,

in der Theorie natürlich, aber es kann ja nicht geprüft werden, ne?

So, wie kann ich mich davor als Unternehmen schützen oder auch als Entwickler natürlich,

wobei der Entwickler selbst, der wird ja sicherlich nicht vom Arbeitgeber haftbar

gemacht werden, wenn er jetzt irgendwas einsetzt, müssen ja theoretisch ja andere

Prozesse da sein, dass dieses Problem halt ja nicht auftritt.

Genau, also das ist tatsächlich, glaube ich, eine, das ist die größte Herausforderung,

die wir im Bereich der Open-Source-Nutzung eigentlich haben.

Ich sage mal, die Dokumentation nach dem Motto, welche Open-Source-Komponenten

habe ich eigentlich verwendet oder wie wurden die denn eigentlich oder auch

möglicherweise zu welchem Zeitpunkt habe ich sie eigentlich möglicherweise in

das Projekt mit einbezogen,

um das irgendwie nachvollziehen zu können.

Ich glaube, der Arbeitgeber, der muss im Zweifel von seinem Direktionsrecht

Gebrauch machen und seinen Angestellten, den Entwicklern sagen,

hey, ihr dürft an der Stelle oder in der Art und Weise Open Source verwenden oder eben nicht.

Da muss man irgendwo in der Projektentwicklung sich immer mal wirklich die Glaubensfrage

stellen, was sind wirklich die schützenswerte Teile, die quasi nicht Open Source

sein sollen, die auch nicht Open Source werden dürfen,

um sich dann zu überlegen, wie kombiniere ich die mit dem Rest und was sind das für Konsequenzen.

Das heißt, habe ich möglicherweise Themen, die ich ausschließen muss?

Und wenn ja, dann muss ich eben...

Versuchen, möglichst sauber vorzugehen und zu vermeiden, dass eben dann bei

der GPL als Beispiel Komponenten, die unter der GPL lizenziert sind,

dann mit in das Projekt einrutschen.

Und das ist, glaube ich, tatsächlich die größte Herausforderung,

weil das Problem ist, der berühmte Black-Duck-Scan, der deckt quasi nur hinterher

auf, was denn am Ende des Tages alles in das Produkt reingerutscht ist.

Und dann ist das Kind theoretisch auch noch in den Boden gefallen.

Gibt es auch Fälle, Also du hast gerade gesagt, welche Komponenten sind schützenswert

und welche nicht. Und da denke ich jetzt aus technischer Perspektive an Microservices.

Ist das durch eine Microservice-Architektur halt auch abgedeckt?

Das heißt, ich habe jetzt einen Service, der kann Open Source sein,

wie auch immer, aber der kommuniziert dann über eine REST-API.

Ist es ausreichend genug, dass ja diesen Copyright-Verstoß dann quasi schützt,

obwohl es eigentlich damit sehr eng miteinander verbunden ist,

weil über ein Protokoll, aber nicht mehr in einem einzelnen Repository?

Das ist tatsächlich ein guter Punkt, weil tatsächlich das sehr stark auf die

einzelnen Lizenzen ankommt.

Und da sind auch tatsächlich, wir haben jetzt nur über den drei,

vier großen Lizenzen gesprochen, aber da gibt es tatsächlich wahnsinnig viele

Varianten, Variationen.

Also die, bleiben wir mal bei der GPL, die geht ja immer von einer funktionalen

und einer inhaltlichen Verknüpfung.

Das heißt, habe ich ein Executable, dann klar, habe ich ein Copy-Left-Effekt,

00:16:39.639 --> 00:16:42.879