Wem gehört Ihre Software? Zugänge, Accounts und Code-Eigentum nach dem Abgang eines Entwicklers

Eine Gründerin ruft drei Wochen nach dem Abgang des freiberuflichen Entwicklers, der ihre Plattform gebaut hat, bei ihrer Agentur an. Der Code läuft einwandfrei. Das Problem ist, dass niemand im Unternehmen sich im GitHub-Repository anmelden kann, das Stripe-Konto auf die private E-Mail-Adresse des Entwicklers registriert ist und die Benachrichtigung zur Domain-Verlängerung an ein Postfach zurückgeprallt ist, das es nicht mehr gibt. Sie stellt die naheliegende Frage: Wem gehört mein Software-Code? Für überraschend viele kleine und mittelständische Unternehmen lautet die ehrliche Antwort: Das kommt darauf an, wer die Passwörter hatte.

Das ist kein seltener Sonderfall. Es ist das, was passiert, wenn ein Unternehmen eine Entwickler-Beziehung als technische Angelegenheit behandelt statt als unternehmerische, und das Eigentum sich per Standardfall klärt statt per Vertrag.

Wem gehört mein Software-Code? Eigentum und Zugriff sind zwei verschiedene Probleme

Die meisten Dienstleistungsverträge enthalten eine Klausel, die das geistige Eigentum am Arbeitsergebnis dem Kunden zuweist, sobald es bezahlt wurde. Diese Klausel ist wichtig und gehört in jeden Vertrag. Aber sie beantwortet eine rechtliche Frage, keine praktische. Das Urheberrecht an Code zu besitzen, den man nicht erreichen kann, hilft niemandem dabei, einen Fix auszuliefern, einen geleakten Schlüssel zu rotieren oder ein Zertifikat vor dem Ablauf zu erneuern.

Zugriff ist eine eigene Ebene: Wer hat den Login, wer kontrolliert das Organisationskonto, auf wessen Namen läuft die Domain-Registrierung. Ein Vertrag kann ein Unternehmen vom ersten Tag an zum rechtlichen Eigentümer seines Codes machen und trotzdem jedes operative Konto unter der privaten E-Mail-Adresse einer einzelnen Person belassen. Genau in dieser Lücke entstehen die meisten Streitfälle über "wem gehört das eigentlich", und sie fällt selten auf, bevor jemand Zugriff braucht und feststellt, dass er ihn nicht hat.

Angestellte, Freelancer und der Eigentums-Standardfall

Der rechtliche Standardfall hängt davon ab, wer den Code geschrieben hat und unter welcher Vereinbarung, und das überrascht die meisten nicht-technischen Gründer. In vielen Rechtsordnungen gehört Code, den ein fest angestellter Mitarbeiter im Rahmen seiner Tätigkeit schreibt, automatisch dem Arbeitgeber, einfach aufgrund des Anstellungsverhältnisses. Für freiberufliche Arbeit und Auftragsarbeit gilt dieser Standardfall meist nicht. Ohne eine schriftliche Klausel, die das Urheberrecht zuweist, kann der Freelancer, der den Code geschrieben hat, dessen rechtlicher Eigentümer bleiben, selbst nachdem der Kunde vollständig bezahlt hat, wobei der Kunde dann nur eine implizite Nutzungslizenz hält.

Genau deshalb tauchen Streitigkeiten zum Code-Eigentum bei Freelancern so häufig bei Vertragsprüfungen auf. Die Lösung selbst ist nicht kompliziert: ein einzelner Satz, der alle Rechte am Arbeitsergebnis mit der Zahlung an den Kunden überträgt, geschrieben in den Vertrag, bevor die Arbeit beginnt. Kompliziert ist, überhaupt zu bemerken, dass diese Lücke existiert, da die meisten mündlichen Vereinbarungen und kurzen Leistungsbeschreibungen sie nie erwähnen, und die Auslassung erst dann relevant wird, wenn die Beziehung endet.

Die konkreten Regeln unterscheiden sich von Land zu Land und danach, ob die Vereinbarung nach lokalem Recht als Auftragswerk gilt, daher lohnt sich ein von einem mit Ihrer Rechtsordnung vertrauten Anwalt geprüfter Vertrag angesichts des Streits, den er später verhindern kann.

Wo Eigentum unbemerkt verloren geht

Eine Handvoll Konten verursacht fast jeden Streit dieser Art:

• Das Quellcode-Repository, wenn es unter dem privaten GitHub- oder GitLab-Konto des Entwicklers angelegt wurde statt unter dem des Unternehmens.
• Die Domain-Registrierung, oft schnell beim Projektstart eingerichtet und danach nie übertragen.
• Cloud-Hosting- und Infrastruktur-Konten wie AWS, Vercel, DigitalOcean oder Supabase, bei denen Abrechnungs- und Admin-Rechte meist an eine einzelne E-Mail-Adresse gebunden sind.
• Zahlungsabwicklungskonten wie Stripe oder PayPal, bei denen die Eigentumsübertragung eine Identitätsprüfung erfordert, die Wochen dauern kann.
• API-Schlüssel und kostenpflichtige Abonnements für Dienste, von denen die Anwendung abhängt, vom E-Mail-Versand über Analytics bis zum Error-Tracking.
• Ein Passwort-Manager-Tresor oder ein gemeinsames Credentials-Dokument, das nur der ausgeschiedene Entwickler entsperren konnte.

Dafür braucht es keine böse Absicht. Die meisten Entwickler versuchen nicht, einen Kunden als Geisel zu nehmen. Sie richten während eines Sprints schnell das verfügbarste Konto ein, in der Absicht, es später zu übertragen, und später kommt nie.

Was die meisten Verträge übersehen

Eine Standardklausel, die festlegt, dass Liefergegenstände mit der Endzahlung in das Eigentum des Kunden übergehen, deckt den Code selbst ab. Sie deckt fast nie die Konten ab, auf denen der Code läuft, und sie setzt fast nie eine Frist oder einen Prozess für die Übergabe. Ohne dieses Detail wird die Übertragung des Zugriffs zu einem Gefallen, den der ausscheidende Entwickler verzögern, vergessen oder bei einem Streit über Umfang oder Bezahlung als Druckmittel nutzen kann.

Die Freelancer und Agenturen mit der saubersten Erfolgsbilanz in diesem Punkt machen eine Sache anders: Sie behandeln Account-Eigentum als Teil des Liefergegenstands statt als Nachgedanken dazu, und sie schreiben das vor Projektbeginn fest.

Klauseln, die sich vor der Unterschrift lohnen

Ein paar Ergänzungen zu einem Standard-Entwicklungsvertrag beseitigen den Großteil des Repository-Zugriffsrisikos, das nach dem Abgang eines Entwicklers auftaucht:

• Verlangen Sie, dass Repository, Hosting-Konto und Domain von Beginn der Zusammenarbeit an unter firmeneigenen Konten angelegt werden, nicht erst am Ende übertragen.
• Falls vorübergehend ein privates Konto des Entwicklers genutzt werden muss, verlangen Sie, dass das Unternehmen innerhalb der ersten Woche als Owner oder Admin hinzugefügt wird, nicht erst beim Offboarding.
• Definieren Sie eine schriftliche Offboarding-Checkliste, die jedes Konto, jeden API-Schlüssel und jede Zugangsdaten im Geltungsbereich aufführt, als Bedingung für die Endzahlung statt als nachträgliche Höflichkeit.
• Setzen Sie eine konkrete Frist für den Abschluss der Übergabe nach Ende der Zusammenarbeit. Fünf bis zehn Werktage sind üblich.

Nichts davon erfordert Misstrauen gegenüber dem Entwickler. Es behandelt Zugriff so, wie ein Unternehmen bereits Büroschlüssel oder Zugangsausweise behandelt: gezielt ausgegeben, nachverfolgt und nach einem Plan zurückgegeben, statt einfach vorausgesetzt.

Wenn der Entwickler bereits weg ist

Wenn die Übergabe nicht stattgefunden hat und die Zusammenarbeit bereits beendet ist, ist eine Wiederherstellung meist möglich, dauert aber länger, als jeder erwartet.

Beginnen Sie mit dem, was Sie belegen können. Gewerbeanmeldung, der unterschriebene Vertrag und Zahlungsnachweise belegen, dass das Unternehmen, nicht die Einzelperson, die Arbeit beauftragt und bezahlt hat. GitHub, Domain-Registrare und die meisten Cloud-Anbieter haben einen dokumentierten Prozess zur Wiederherstellung eines Kontos oder einer Organisation, wenn der Antragsteller legitimes unternehmerisches Eigentum nachweisen kann, auch wenn das mehrere Tage dauern kann und länger, falls der ursprüngliche Kontoinhaber nicht reagiert.

Prüfen Sie zuerst die Commit-Historie und die Konfigurationsdateien des Repositorys. Sie enthüllen oft Kontonamen, verknüpfte E-Mail-Adressen und Dienstleister, die sonst niemand irgendwo aufgeschrieben hat. Ein kurzes technisches Audit an dieser Stelle, bevor ein neues Team anfängt, irgendetwas zu ändern, deckt auch andere Lücken auf wie hartkodierte Zugangsdaten, undokumentierte Abhängigkeiten oder Infrastruktur, die nur für die Person Sinn ergab, die sie aufgebaut hat. Die Arbeit an Legacy-Code-Optimierung von Wolf-Tech beginnt oft genau hier, mit der Kartierung dessen, wovon eine Codebasis tatsächlich abhängt, bevor jemand sie anfasst.

Wenn ein Anbieter nicht kooperiert und der Entwickler schlicht unerreichbar ist, reicht meist ein kurzes Anwaltsschreiben mit Verweis auf die unterschriebene IP-Übertragungsklausel zur Lösung aus. Eine pauschale Verweigerung der Zugriffsübergabe, die ein Vertrag bereits zuweist, ist selten, schon allein weil die wenigsten Entwickler diesen Streit aktenkundig haben wollen.

Das nächste Projekt so aufbauen, dass das nicht wieder passiert

Wenn Sie einen neuen Build starten statt einen alten wiederherzustellen, ist die Lösung einfacher. Richten Sie firmeneigene Konten für Repository, Hosting, Domain und Abrechnung ein, bevor überhaupt Code geschrieben wird, und fügen Sie den Entwickler oder die Agentur als Collaborator zu diesen Konten hinzu statt umgekehrt. Die Projekte für individuelle Softwareentwicklung von Wolf-Tech folgen standardmäßig dieser Struktur, sodass Zugriff und Eigentum nie ein separates Thema zum Build selbst sind.

Wenn Sie eine Codebasis geerbt haben und nicht sicher sind, was Sie tatsächlich kontrollieren, schauen wir uns das gerne an. Schreiben Sie an hello@wolf-tech.io oder erfahren Sie mehr darüber, wie wir arbeiten, auf wolf-tech.io.