18.05.2021

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

Von Lizenzbedingung bis Urheberrecht: Startups treten immer wieder in dieselben rechtlichen Fallen, wenn es um den Code ihres Produkts geht.

/artikel/5-rechtliche-fehler-die-startups-beim-programmieren-vermeiden-sollten

✨ AI Kontextualisierung

GASTBEITRAG

„Das ist ein wirklich genialer Code, aber das Risiko, das wir uns damit einkaufen ist uns leider zu hoch. Wir haben uns daher für ein anderes Investment entschieden.“ Damit du bei der Verwertung deines Produktes oder einem Exit diesen oder einen ähnlichen Satz nicht hören musst, solltest du aus Legal-Sicht unter anderem die folgenden fünf Fehler beim Coding vermeiden.

1. Vorsicht beim Einsatz von Open Source.

Der Quellcode von Open Source Software wird kostenfrei zur Verfügung gestellt. Insbesondere für junge Programmier*innen ist diese daher interessant und wird häufig im eigenen Code integriert, doch hier ist Vorsicht geboten.

Lizenzen für Open Source Software enthalten oft sogenannte „Copyleft“ Klauseln. Durch solche Klauseln werden Lizenznehmer*innen verpflichtet Bearbeitungen des Quellcodes ebenfalls kostenlos zur Verfügung zu stellen. Die bekannteste Copyleft-Lizenz ist GNU General Public License (GPL).

Wenn du deinen Code also auf Open Source, die zB unter GPL steht, aufbaust, ist der Copyleft Effekt auf deinen Code anwendbar. Du müsstest deinen Quellcode daher kostenfrei zur Verfügung stellen und könntest Schwierigkeiten bei der Verwertung des Codes (zB beim Verlangen von Lizenzgebühren) bekommen.

Key Takeaway: Drum prüfe, wer (Open Source) Code in die eigene Software integriert.

Don’t forget: Selbstverständlich musst du auch bei bezahlter Software, die Lizenzbedingungen prüfen, um herauszufinden, ob eine Verwertung möglich ist.

2. Code documentation – mehr als nur „comments“

Ja, die Hauptsache ist, dass dein Code funktioniert, aber für Investor*innen oft genauso relevant ist eine exakte Dokumentation des Codes.

Um potentielle Investor*innen zu beeindrucken, empfiehlt es sich nicht nur comments zum Code hinzuzufügen, sondern die einzelnen Coding-Schritte ausführlicher zu dokumentieren, etwa in einem README file. Abhängig davon, was das Einsatzgebiet deines Codes ist, kann auch eine API Dokumentation angebracht sein.

Key Takeaway: Documentation is key – auch aus Legal-Sicht.

3. Coding together – ein smarter Move?

Gemeinsam Programmieren, ob in einem Angestelltenverhältnis oder als Business Partner – was so nett klingt, ist aus Legal-Sicht ohne „Sicherheitsvorkehrungen“ nicht immer ein smarter Move.

Das Urhebergesetz sorgt zwar grundsätzlich für Programmierer*innen vor, indem es (i) einen urheberrechtlichen Schutz für Computercode vorsieht und (ii) festlegt, dass, wenn Arbeitnehmer*innen für den Dienstgeber codieren, die Nutzungsrechte an dem Programmierten auf den Dienstgeber übergehen… Also alles easy? Leider nicht!

Das UrhG – und somit auch diese, für den Dienstgeber günstige Stellung gilt nämlich nur, wenn der Dienstnehmer ein Computerprogramm iSd UrhG programmiert. Wird nur ein Teil davon oder nur einzelne Algorithmen programmiert, könnte diese Bestimmung nicht anwendbar sein. In diesem Fall ist es notwendig eine ergänzende Vereinbarung mit dem Mitarbeiter oder der Mitarbeiterin zu treffen (das kann bspw. im Dienstvertrag passieren).

Wenn du mit deiner Business-Partnerin oder deinem Business Partner gemeinsam codierst, kann es möglich sein, dass ihr beide sogenannte „Miturheber“ des Codes seid. Den Code könntet ihr dann nur gemeinsam verwerten – das solltet ihr jedenfalls bedenken. Bei deiner Geschäftspartnerin oder deinem Geschäftspartner wird das häufig ohnehin so gewollt sein. Rechtlich tricky könnte es werden, wenn dir eine Freundin oder ein Freund beim Codieren maßgeblich hilft und ihr euch bis dahin keine Gedanken über die Zusammenarbeit/Rechte/Verwertung gemacht habt.

Key Takeaway: Mache dir bereits frühzeitig Gedanken, wer welche Rechte an dem Code haben soll und sichere diese Rechtsposition vertraglich ab.

4. Achtung im Zusammenhang mit Input-Daten

Für die Entwicklung und das Training von Algorithmen sind Daten erforderlich – nur durch Beispiele kann ein Algorithmus lernen, Muster in Daten zu erkennen.

Abhängig davon, welche Daten du deinem Code fütterst, musst du weitere Bestimmungen beachten. Sobald du zum Training personenbezogene Daten verarbeiten musst, sind die Bestimmungen der DSGVO anwendbar.

Personenbezogene Daten sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, wie zB Name, Alter, persönliche Vorlieben, E-Mailadresse oder Foto. Häufig ist nicht ganz klar, was alles ein personenbezogenes Datum darstellen kann (etwa hat der Europäische Gerichtshof vertreten, dass in bestimmten Fällen IP-Adressen auch personenbezogene Daten sind). Bevor ihr Daten verarbeitet ist es daher wichtig zu klären, ob diese Personenbezug aufweisen.

Eine Datenverarbeitung ist nur unter bestimmten Voraussetzungen rechtmäßig, insbesondere bei Einwilligung der betroffenen Person oder zur notwendigen Erfüllung eines Vertrags. Zudem treffen den Verarbeiter umfassende Pflichten (Datenlöschung, Berichtigung, organisatorische Vorkehrungen, etc). Die Nichteinhaltung der DSGVO ist mit hohen Geldstrafen bedroht.

Bereits im Vorfeld der Entwicklung sollte daher berücksichtigt werden, welche Daten durch einen Algorithmus verarbeitet werden und wie die Vorgaben der DSGVO ohne zusätzlichen Aufwand eingehalten werden können (Vertragliche Grundlage, Einholung von Einwilligung, etc). Ansonsten drohen später zusätzliche Kosten durch die nachträgliche Anpassung oder sogar Strafzahlungen.

Key Takeaway: Checke bereits bei der Entwicklung welche Daten du deinem Algorithmus fütterst, um später böse Überraschungen und aufwändiges Umprogrammieren zu vermeiden.

5. Vertragliche Geheimhaltung

Wie bereits zuvor gesagt, kann es sein, dass dein Code bzw Teile davon (etwa bloße Algorithmen) keinen urheberrechtlichen Schutz genießen; doch auch für solche Fälle gibt’s eine Lösung.

Programmcodes können nämlich ein „Betriebsgeheimnis“ darstellen und dadurch wettbewerbsrechtlich vor Mitbewerber*innen geschützt sein – doch aufgepasst, auch hier ist es wichtig bereits frühzeitig an den Schutz zu denken. Damit Code ein Betriebsgeheimnis iSd UWG sein kann, muss er folgende Voraussetzungen erfüllen: mangelnde Offenkundigkeit, Geheimhaltungswille und Geheimhaltungsinteresse.

Mangelnde Offenkundigkeit bedeutet, dass Informationen nicht allgemein bekannt sind und auch tatsächlich geheim gehalten werden. Sie dürfen nur einem beschränkten Personenkreis bekannt gemacht werden (zB Arbeitnehmer*innen, Tester*innen). Daher sollten Geheimhaltungsvereinbarungen mit Personen getroffen werden, die Zugriff auf den Code haben, um eine weitere Verbreitung zu verhindern. Häufig reicht eine bloße Geheimhaltungsvereinbarung im Dienstvertrag dazu nicht aus; das ist aber im Einzelfall zu klären.

Der Geheimhaltungswille muss aus den äußeren Umständen zum Ausdruck kommen. Geheimhaltungsvereinbarungen oder technische Schutzvorkehrungen (Zugangsbeschränkungen, etc) lassen den Geheimhaltungswillen erkennen.

Vertragliche oder technische Schutzvorkehrungen lassen auch das Geheimhaltungsinteresse erkennen.

Was bringt der Schutz als Betriebsgeheimnis? Die unlautere Verwertung von Betriebsgeheimnissen zu Wettbewerbszwecken ist strafbar. Zusätzlich können gegen Mitbewerber Schadenersatz- und Unterlassungsansprüche geltend gemacht werden. Gerade wenn Codes nicht die Voraussetzungen für urheberrechtlichen Schutz oder ein Patent erfüllen, ist das Wettbewerbsrecht von besonderer Bedeutung. Dafür sollten neben technischen Vorkehrungen auch vertragliche Geheimhaltungspflichten vorgesehen werden.

Key Takeaway: Insoweit du deinen Code (auch) als Betriebsgeheimnis schützen möchtest, überlege dir bereits frühzeitig, welche vertraglichen und nicht vertraglichen (zB technischen) Maßnahmen du setzen wirst, um einen solchen Schutz zu erreichen.

Um deinen Code bestmöglich schützen und anschließend verwerten zu können, gilt es also einiges zu beachten, wobei das wichtigste natürlich weiterhin die Funktionalität deines Codes und der Spaß am Programmieren bleibt.

Über den Autor

Martin Hanzl ist Senior Associate bei EY Law Pelzmann Gall Größ Rechtsanwälte und betreut dort Mandant*innen unter anderem zu Fragen rund um neue Technologien. Zudem ist er in der Projektleitung des Blockchain and Smart Contracts Projektes des European Law Institute tätig und publiziert regelmäßig zu rechtlichen Themen rund um neue Technologien, Blockchain, Smart Contracts und Digitalisierung.

LinktippZum LinkedIn-Profil LinktippIT-Rechts-Tipps auf Instagram LinktippMail an den Autor

Drei Milliarden Euro. Das ist die Summe, die der französische Anthropic- und OpenAI-Herausforderer Mistral in seiner heute verkündeten Series-D-Finanzierungsrunde aufnahm. Es ist die größte VC-Runde für ein Tech-Unternehmen in der europäischen Geschichte – und das für ein gerade einmal drei Jahre altes Unternehmen.

Den Lead in der Runde übernahm mit Samsung – wenig überraschend – ein außereuropäischer Player. Dazu kommen große US-Investoren wie PSG Equity als Co-Lead, a16z und Nvidia, aber auch eine ganze Reihe europäischer Kapitalgeber, darunter der Scaleup Europe Fund der schwedischen EQT als weiterer Co-Lead.

Keine normalen Umstände

Drei Milliarden Euro. Eine Bewertung von 21 Milliarden Euro. Das sollte unter normalen Umständen ein Garant für den großen Durchbruch sein. Zum Vergleich: Meta (damals Facebook) genügten vor seinem Börsengang insgesamt 2,27 Milliarden US-Dollar VC-Kapital, um sich im Social-Media-Wettlauf klar an die Spitze zu setzen und zum Tech-Giganten zu werden.

Doch die Umstände sind nicht normal. Der KI-Wettlauf hat die Volumina an VC-Kapital vor allem in den USA auf ein nie dagewesenes Level gehievt. Anthropic, das Unternehmen hinter Claude, hat allein in seiner Series-H-Runde im Mai dieses Jahres 65 Milliarden US-Dollar aufgenommen und steht bei einer Bewertung von 965 Milliarden Dollar. OpenAI, das Unternehmen hinter ChatGPT, hat diesen März in seiner Finanzierungsrunde sogar 122 Milliarden US-Dollar eingesammelt und steht bei einer Bewertung von 852 Milliarden Dollar.

Beim insgesamt aufgenommenen Kapital steht Mistral (ca. 6 Mrd. Euro inklusive Kredite) in einem Verhältnis von etwa 1:19 zu Anthropic (mindestens 130 Mrd. US-Dollar) und 1:26 zu OpenAI (mindestens 180 Mrd. US-Dollar). Das wird im beinharten internationalen Tech-Wettlauf vermutlich nicht ausreichen.

Digitale Souveränität als Verkaufsargument

Und das weiß man auch beim französischen Scaleup. Der größte Trumpf, den es in der Hand hat, ist, dass es aus Europa kommt. Punkten kann das Unternehmen vor allem bei den Themen Digitale Souveränität und Datensicherheit. Und das wiederum sind Fragen, die im B2B- und vor allem im öffentlichen Bereich deutlich schwerer wiegen als im B2C-Bereich, den aktuell Anthropic, OpenAI und Google dominieren.

„Während der ersten Welle der generativen KI lautete die zentrale Frage: Wer kann das leistungsstärkste Modell entwickeln? Unternehmen und Regierungen stellen sich nun eine andere Frage: „Wie können sie die Leistungsfähigkeit der KI für ihre geschäftskritischen Anforderungen nutzen, ohne die Kontrolle über die Infrastruktur und den Informationskreislauf abzugeben?“, heißt es von Mistral in der Presseaussendung zur aktuellen Kapitalrunde.

Die Frage will man freilich mit dem eigenen Produkt beantworten. „Die Nachfrage nach dieser Kombination aus Leistung, Kontrolle, Auswahlmöglichkeiten und Unabhängigkeit nimmt weltweit zu“, ist man sich sicher. Und Mistral sei das weltweit einzige KI-Unternehmen, das den gesamten Stack entwickle, der dafür erforderlich ist: „Open-Weight-Modelle, die Infrastruktur und die Rechenkapazität, auf der sie laufen, und die Produkte, mit denen sie in den Unternehmen wirksam werden“.

Ausstehender Beweis

Dass diese Argumente angesichts des europäischen Diskurses durchaus valide sind, liegt auf der Hand. Ob die Rechnung am Ende auch betriebswirtschaftlich aufgeht, steht auf einem anderen Blatt geschrieben. Mistral bekommt durch die Mega-Runde genug Luft, um sich innerhalb Europas weiterhin im öffentlichen und im Unternehmenssegment zu etablieren. Doch dass das ausreicht, um das eingesetzte Kapital (mehrfach) zurückzuspielen, muss erst bewiesen werden.