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.