Wem gehört der Code? Übergabe und Verträge richtig regeln

Warum die Frage nach dem Eigentum so oft zu spät kommt

Solange ein Softwareprojekt gut läuft, redet niemand über Eigentum. Der Dienstleister liefert, du bezahlst, das Produkt wächst. Wem der Code eigentlich gehört, fragst du dich erst, wenn etwas kippt. Du willst den Anbieter wechseln. Die Zusammenarbeit endet im Streit. Ein Investor schaut bei der Due Diligence genauer hin. Genau dann zeigt sich, ob die Grundlagen geregelt waren. Wenn nicht, verhandelst du aus einer schwachen Position, und das wird schnell teuer.

Eine Sache vorweg, und sie ist die wichtigste: Eigentum an Software entsteht nicht automatisch dadurch, dass du dafür bezahlst. Wer die Rechte hat, wer an die Daten kommt und wer das Produkt im Ernstfall ohne den ursprünglichen Entwickler weiterbetreiben kann, steht im Vertrag und ergibt sich aus dem, was tatsächlich übergeben wurde. Dieser Artikel geht die Bausteine der Reihe nach durch, damit du weisst, worauf du achten musst, bevor du eine einzige Zeile Code in Auftrag gibst.

Eigentum an Code ist nicht dasselbe wie Urheberrecht

Der häufigste Denkfehler steckt schon im Wort. Umgangssprachlich sagen wir, jemandem gehöre der Code. Juristisch gibt es an Software aber kein Eigentum wie an einem Auto. Es gibt das Urheberrecht, und das entsteht beim Menschen, der den Code geschrieben hat. Entwickelt eine externe Agentur für dich, liegen die Rechte zunächst bei der Agentur und ihren Entwicklern. Nicht bei dir, auch wenn die Rechnung auf deinen Namen läuft.

Damit du die Software uneingeschränkt nutzen, verändern, weitergeben und von anderen weiterentwickeln lassen kannst, brauchst du eine Rechteübertragung oder zumindest eine umfassende, ausschliessliche und übertragbare Nutzungslizenz. Der Unterschied ist nicht akademisch. Mit einem einfachen Nutzungsrecht darfst du das Produkt vielleicht betreiben, aber nicht von einem dritten Team umbauen lassen und nicht als Teil eines Verkaufs übertragen. Achte deshalb darauf, dass die Rechteeinräumung alle bekannten und unbekannten Nutzungsarten abdeckt und das Recht zur Bearbeitung einschliesst. Sonst gehört dir das Ergebnis, aber anfassen darfst du es nicht.

Dazu kommt ein Punkt, den viele übersehen: Software besteht heute zu grossen Teilen aus fremden Bausteinen. Open-Source-Bibliotheken, Frameworks, eingekaufte Komponenten. Daran kann dir der Entwickler keine Rechte übertragen, weil sie ihm selbst nicht gehören. Das ist normal, solange die Lizenzen dieser Bausteine zu deinem Vorhaben passen. Lass dir zusichern, dass nur Komponenten verwendet werden, deren Lizenz deine geplante Nutzung erlaubt, und dass du eine Liste dieser Abhängigkeiten bekommst. Spätestens wenn ein Investor oder Käufer prüft, wird diese Liste wichtig.

Wem die Daten gehören, ist eine eigene Frage

Code und Daten landen oft im selben Topf, gehören aber getrennt geregelt. Bei den Daten stecken zwei Schichten drin. Die rechtliche zuerst: Die Inhalte deiner Kunden, ihre Profile, ihre Eingaben sind deine Geschäftsdaten. Der Vertrag sollte unmissverständlich festhalten, dass sie dir gehören und der Dienstleister sie nur zur Erbringung der Leistung verarbeitet. Sind personenbezogene Daten im Spiel, kommt in der Schweiz das Datenschutzgesetz dazu, und du brauchst einen Auftragsbearbeitungsvertrag, der regelt, was der Dienstleister mit diesen Daten tun darf und was nicht.

Die zweite Schicht ist praktisch: Kommst du im Ernstfall überhaupt an deine Daten heran? Ein Anbieter, der dir das Eigentum an den Daten zusichert, aber keinen sauberen Export in einem brauchbaren Format anbietet, hat dir wenig gegeben. Lass dir das Recht auf einen vollständigen Datenexport schriftlich geben, in einem offenen oder zumindest dokumentierten Format, mit einer klaren Zusage, wie schnell der Export im Trennungsfall bereitsteht. Daten, die nur in einer proprietären Datenbankstruktur liegen, die ausser dem Anbieter niemand versteht, sind faktisch eingesperrt.

Geistiges Eigentum reicht weiter als der Quellcode

Wenn du an die Übergabe deines Produkts denkst, denkst du wahrscheinlich zuerst an den Quellcode. Der ist wichtig, aber nur ein Teil des geistigen Eigentums, das in einem Produkt steckt. Dazu gehören auch das Design und die Benutzeroberfläche, die Marke und der Name, Texte und Bilder, dazu konzeptionelle Arbeit wie Datenmodelle oder Schnittstellen. Jeder dieser Bestandteile kann eigene Rechte haben, und jeder gehört in den Vertrag.

Knifflig wird es an den Rändern. Hat eine Designagentur dein Logo entworfen, brauchst du auch daran die Rechte, nicht nur am Code, der es anzeigt. Wurden Stockfotos oder Schriftarten verwendet, gelten deren Lizenzbedingungen weiter, auch nach der Übergabe. Und wenn dein Dienstleister im Projekt etwas Allgemeines gebaut hat, das er auch für andere Kunden einsetzen will, etwa ein internes Framework, wird er dir daran kaum die exklusiven Rechte geben. Das ist legitim, muss aber klar benannt sein, damit du weisst, welche Teile nur dir gehören und welche du mit anderen teilst. Diese Trennlinie sauber zu ziehen, gehört zu den Dingen, die wir bei der SaaS-Produktentwicklung von Anfang an mitverhandeln, statt sie ans Ende zu schieben.

Was eine saubere Übergabe wirklich umfasst

Eine Übergabe ist nicht der Moment, in dem dir jemand einen Zugang zum Code-Repository schickt. Eine saubere Übergabe versetzt ein anderes, kompetentes Team in die Lage, das Produkt ohne Rücksprache mit dem ursprünglichen Entwickler zu betreiben und weiterzuentwickeln. Das ist der Massstab. Alles darunter ist eine halbe Übergabe, bei der du abhängig bleibst, ob du willst oder nicht.

Konkret gehört dazu der vollständige Quellcode samt Versionshistorie, damit nachvollziehbar bleibt, warum etwas so gebaut wurde, wie es gebaut wurde. Dann alle Zugänge und die Infrastruktur: Konten bei Hosting-Anbietern, Domains, Zertifikate, Schlüssel und Passwörter, registriert auf dich oder dein Unternehmen, nicht auf den Dienstleister. Ein Produkt, dessen Domain dem Entwickler gehört, fährt mit angezogener Handbremse. Dazu die Build- und Deployment-Anleitung, also das Wissen, wie aus dem Code eine laufende Anwendung wird. Und die laufenden Verträge und Abos mit Drittanbietern, damit nach der Trennung nicht plötzlich ein bezahlter Dienst ausfällt, weil die Kreditkarte des alten Entwicklers nicht mehr belastet wird.

Weil wir bei Wertstifter eigene Produkte wie Wortfreunde und Reazon nicht nur bauen, sondern selbst betreiben, kennen wir diese Liste aus der Betreiber-Perspektive. Genau hier liegt der Unterschied zu einer reinen Agentur. Wer ein Produkt über Jahre selbst am Laufen hält, weiss, welcher unscheinbare Zugang und welches stille Wissen im Ernstfall fehlt. Das sind die Punkte, die wir in eine Übergabe hineinschreiben, weil wir aus eigener Erfahrung wissen, wo es sonst klemmt.

Dokumentation entscheidet über Wochen oder Monate

Dokumentation klingt nach Pflichtübung. Tatsächlich entscheidet sie darüber, ob ein neues Team in Wochen statt Monaten produktiv wird. Gemeint ist kein dickes Handbuch, das niemand liest. Nützliche Dokumentation beantwortet die Fragen, die ein fremder Entwickler am ersten Tag stellt. Wie setze ich das Projekt lokal auf? Wie ist die Anwendung grob aufgebaut? Welche externen Dienste hängen dran und warum? Wo lauern die typischen Stolperfallen?

Dazu gehören die Entscheidungen, die nirgends im Code stehen. Warum fiel die Wahl auf diese Technologie? Welche Annahmen stecken hinter dem Datenmodell? Dieses Kontextwissen lebt sonst nur in den Köpfen der ursprünglichen Entwickler und verschwindet mit ihnen. Ein guter Vertrag macht Dokumentation deshalb zur Lieferleistung, nicht zum optionalen Extra. Halte fest, in welchem Umfang dokumentiert wird und dass die Dokumentation Teil der Abnahme ist. Fehlende Dokumentation ist einer der Gründe, warum Übergaben scheitern und Anschlussprojekte teurer werden als geplant. Woran Vorhaben sonst noch kippen, liest du im Artikel warum SaaS-Projekte scheitern.

Wann sich der ganze Aufwand nicht lohnt

Nicht jedes Projekt braucht den vollen Vertragsapparat. Baust du einen kleinen internen Prototypen, den du in drei Monaten ohnehin wegwirfst, wäre es übertrieben, um Quellcode-Hinterlegung und Lizenzlisten zu ringen. Der Aufwand muss zum Einsatz passen. Die Faustregel: Je länger ein Produkt leben soll und je mehr Geschäft davon abhängt, desto wichtiger werden diese Punkte. Bei einem Wegwerf-Experiment darf eine einfache Rechteübertragung und ein Zugang zum Code genügen.

Und manchmal ist der bessere Weg gar keine Übergabe, sondern ein Partner, der baut und danach selbst betreibt. Wenn du kein eigenes Entwicklungsteam aufbauen willst und auch nicht vorhast, das Produkt je intern weiterzuführen, ist die wichtigste Frage nicht, ob du den Code irgendwann sauber übernehmen kannst. Wichtiger ist dann, ob dein Partner das Produkt verlässlich am Laufen hält. Trotzdem solltest du die Eigentums- und Exit-Punkte vertraglich sichern, denn auch eine gute Zusammenarbeit kann enden. Der Unterschied: Du planst die Übergabe als Notausgang, nicht als Tag eins.

Diese Punkte regelst du am besten vor Projektstart

Dein Hebel ist vor dem Projekt am grössten, nicht danach. Vorher hast du Verhandlungsmacht, weil der Auftrag noch nicht vergeben ist. Danach bist du im schlechtesten Fall auf Goodwill angewiesen. Deshalb gehören die folgenden Punkte in den Vertrag, bevor die Arbeit beginnt.

• Rechteübertragung an Code und allen Arbeitsergebnissen, ausschliesslich und übertragbar, mit dem Recht zur Bearbeitung.
• Eigentum an den Daten plus das Recht, sie jederzeit vollständig zu exportieren.
• Zugänge und Domains, registriert auf dich, nicht auf den Dienstleister.
• Dokumentation als Lieferleistung und Bestandteil der Abnahme.
• Eine Liste der Abhängigkeiten und ihrer Lizenzen.
• Der Trennungsfall: Fristen, Mitwirkung bei der Übergabe, Herausgabe aller Unterlagen.
• Bei existenziellen Produkten eine Hinterlegung des Quellcodes bei einer neutralen Stelle, die im Notfall, etwa bei Insolvenz des Anbieters, ausgelöst wird.

Nichts davon ist ein Misstrauensvotum gegen deinen Dienstleister. Es ist die Grundlage, auf der eine Zusammenarbeit überhaupt belastbar wird. Ein seriöser Partner wehrt diese Punkte nicht ab, sondern schlägt sie selbst vor, weil sie auch ihn vor späteren Streitigkeiten schützen. Stehst du noch davor, die Bauform deines Produkts und damit deinen Partner zu wählen, hilft der Vergleich selbst bauen vs. Agentur vs. No-Code vs. Produktstudio, denn die Eigentumsfrage fällt je nach Weg unterschiedlich aus. Es bleibt eine einfache Faustregel: Du gehst nur dann ohne Reibung aus einer Zusammenarbeit, wenn der Ausgang schon beim Eingang geregelt war.