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

Du lässt eine Software bauen und willst sie später unabhängig nutzen und betreiben können. Ob du Quellcode, Nutzungs- und Verwertungsrechte, Datenzugriff und Betriebswissen erhältst, hängt vom Vertrag ab. Hier erfährst du, was du vor Projektstart und bei der Übergabe klären solltest.

Jan-Hendrik Heuing

Wem gehört der Code?

Du beauftragst eine Agentur mit der Entwicklung einer Software. Du bezahlst die Rechnungen. Also gehört dir am Ende alles, oder? So einfach ist es leider nicht.

Bei Softwareprojekten treffen mehrere rechtliche und praktische Fragen aufeinander: Wer ist Urheberin oder Urheber? Wer darf den Code nutzen, ändern, weitergeben oder verkaufen? Wer erhält den Quellcode und die Zugänge? Wer kontrolliert die im System verarbeiteten Daten und kann sie exportieren? Wenn der Vertrag diese Punkte nicht ausdrücklich regelt, entstehen Abhängigkeiten, die später teuer werden können.

Dieser Artikel gibt dir eine praktische Orientierung für Projekte in der Schweiz. Er ersetzt keine Rechtsberatung. Für die konkrete Vertragsgestaltung und komplexe Rechtefragen solltest du eine juristische Fachperson beiziehen.

Urheberschaft, Nutzungsrechte und Art. 17 URG

Nach Schweizer Urheberrecht ist Urheberin oder Urheber die natürliche Person, die ein Werk geschaffen hat. Der Schutz entsteht grundsätzlich mit der Schöpfung. Davon zu unterscheiden sind die vermögensrechtlichen Nutzungs- und Verwertungsrechte: Sie können vertraglich übertragen oder lizenziert werden. Urheberpersönlichkeitsrechte bleiben dagegen an die schöpferische Person gebunden.

Für Computerprogramme von Angestellten gilt eine besondere Regel. Werden sie im Rahmen der dienstlichen Tätigkeit und in Erfüllung vertraglicher Pflichten geschaffen, ist nach Art. 17 URG grundsätzlich der Arbeitgeber allein zur Ausübung der ausschliesslichen Verwendungsbefugnisse berechtigt, sofern nichts anderes vereinbart wurde. Diese Regel lässt sich nicht pauschal auf externe Agenturen oder Freelancer übertragen.

Bei einem Auftragsprojekt muss der Vertrag deshalb festlegen, welche Rechte du erhältst. Die Bezahlung der Entwicklung bedeutet nicht automatisch, dass sämtliche Nutzungs- und Verwertungsrechte, der Quellcode und alle technischen Zugänge ohne Einschränkung übergehen. Für den Projektalltag zählt weniger ein pauschales Etikett wie Eigentum am Code als die konkrete Antwort auf diese Fragen:

  • Darfst du die Software zeitlich und räumlich unbeschränkt nutzen?
  • Darfst du den Code ändern oder durch Dritte ändern lassen?
  • Darfst du die Software vervielfältigen, weitergeben oder kommerziell verwerten?
  • Erhältst du den vollständigen aktuellen Quellcode und die Build-Anleitung?
  • Welche vorbestehenden Komponenten der Agentur und welche Drittkomponenten sind enthalten?
  • Welche Open-Source-Lizenzen und weiteren Lizenzbedingungen gelten?

Je genauer diese Rechte beschrieben sind, desto kleiner ist das Risiko, dass beide Seiten unter demselben Vertrag etwas anderes verstehen.

Nutzungsrecht oder Rechteübertragung?

In Verträgen begegnen dir meist zwei Grundmodelle.

Beim Nutzungsrecht oder einer Lizenz darfst du die Software im vereinbarten Umfang verwenden. Dieses Recht kann zeitlich, räumlich oder sachlich beschränkt sein. Es kann exklusiv oder nicht exklusiv sein. Die Agentur kann Rechte an eigenen, vorbestehenden Komponenten behalten und diese auch in anderen Projekten einsetzen.

Bei einer Übertragung von Verwertungsrechten erhältst du weitergehende Befugnisse, soweit sie vertraglich und rechtlich übertragbar sind. Entscheidend bleibt der genaue Wortlaut: Welche Rechte werden übertragen, für welche Nutzungsarten und mit welchen Einschränkungen? Urheberpersönlichkeitsrechte werden dadurch nicht einfach beseitigt.

Für die meisten massgeschneiderten Geschäftsanwendungen solltest du mindestens sicherstellen, dass du die Software dauerhaft betreiben, ändern und durch einen anderen Anbieter weiterentwickeln lassen kannst. Wenn du das Produkt als SaaS weiterverkaufen oder an Dritte lizenzieren willst, muss auch diese Verwertung ausdrücklich abgedeckt sein.

Eine faire Regelung kann so aussehen: Du erhältst die für dein Produkt nötigen, umfassenden Nutzungs- und Verwertungsrechte am projektspezifischen Code. Die Agentur behält Rechte an vorbestehenden Werkzeugen, allgemeinen Bibliotheken und wiederverwendbaren Bausteinen. Open-Source-Komponenten bleiben unter ihren jeweiligen Lizenzen. Diese Aufteilung schützt deine Handlungsfähigkeit, ohne der Agentur ihre allgemeine Arbeitsgrundlage zu entziehen.

Quellcode: Zugriff ist praktisch entscheidend

Rechte helfen dir wenig, wenn du den aktuellen Quellcode nicht erhältst. Der Quellcode ist die lesbare Version der Software, aus der die lauffähige Anwendung gebaut wird. Ohne ihn kann niemand das System sinnvoll warten oder weiterentwickeln.

Der Vertrag sollte regeln, wo der Code liegt und wer Zugriff hat. Ideal ist ein Repository bei einem unabhängigen Anbieter, etwa GitHub, GitLab oder Bitbucket, auf das du von Anfang an Zugriff hast. So bist du nicht darauf angewiesen, dass die Agentur bei Projektende einen Export erstellt.

Prüfe folgende Punkte:

  • Liegt der vollständige Code in einem Versionsverwaltungssystem?
  • Hast du administrativen Zugriff auf das Repository?
  • Sind alle Änderungen regelmässig eingecheckt?
  • Gibt es eine Dokumentation für Installation und Deployment?
  • Sind Abhängigkeiten und verwendete Versionen dokumentiert?
  • Sind Zugangsdaten sicher gespeichert und übertragbar?
  • Kann ein anderes Team die Software mit den vorhandenen Unterlagen starten?

Ein Quellcode-Archiv ohne Dokumentation kann wertlos sein. Wenn niemand weiss, welche Umgebungsvariablen nötig sind, wie die Datenbank aufgebaut ist oder welcher Build-Prozess gilt, dauert die Übernahme Wochen statt Tage.

Open Source: Frei nutzbar heisst nicht bedingungslos

Moderne Software besteht zu einem grossen Teil aus Open-Source-Komponenten. Das ist normal und sinnvoll. Niemand entwickelt jedes Rad neu. Diese Komponenten gehören aber nicht dir oder der Agentur. Sie werden unter bestimmten Lizenzen genutzt.

Die Lizenz bestimmt, was erlaubt ist. Manche Lizenzen wie MIT oder Apache 2.0 erlauben eine sehr freie Nutzung, solange Hinweise erhalten bleiben. Andere Lizenzen wie die GPL können verlangen, dass abgeleitete Werke ebenfalls unter derselben Lizenz veröffentlicht werden, wenn sie verteilt werden.

Für eine interne Webanwendung ist das Risiko oft überschaubar. Bei Software, die du verkaufen oder an Kunden ausliefern willst, kann die Lizenzwahl geschäftskritisch sein.

Verlange von der Agentur eine Liste der wesentlichen Open-Source-Komponenten und ihrer Lizenzen. Bei grösseren Projekten lohnt sich ein automatisierter Lizenzscan. So weisst du, welche Verpflichtungen gelten und vermeidest spätere Überraschungen.

Open Source ist kein Zeichen für minderwertige Entwicklung. Im Gegenteil: Gute Agenturen nutzen etablierte Bibliotheken, statt unnötig eigene Lösungen zu bauen. Entscheidend ist, dass die Auswahl bewusst erfolgt und die Lizenzbedingungen zu deinem Geschäftsmodell passen.

Daten: Kontrolle, Zugang und Rollen statt pauschales Eigentum

Bei Daten ist die Formulierung Eigentum oft ungenau. Daten sind rechtlich nicht ohne Weiteres mit einer körperlichen Sache gleichzusetzen. Je nach Inhalt können Datenschutzrecht, Geheimnisschutz, Urheberrecht, Datenbankrechte oder vertragliche Ansprüche eine Rolle spielen. Für dein Projekt solltest du deshalb konkret regeln, wer welche Daten kontrolliert, darauf zugreifen darf, sie exportieren kann und wann sie gelöscht werden.

Bei Personendaten kommen zusätzlich die Rollen nach Datenschutzrecht hinzu. Zu klären ist insbesondere, wer als Verantwortlicher über Zweck und Mittel der Bearbeitung entscheidet und ob die Agentur oder ein Hosting-Anbieter Daten als Auftragsbearbeiter verarbeitet. Betroffene Personen haben gesetzliche Rechte an ihren Personendaten; das ist etwas anderes als ein pauschales Eigentum an einem Datenbestand.

Der Vertrag sollte praktisch festhalten:

  • welche Daten im System verarbeitet werden,
  • wer in welcher Rolle darauf zugreifen darf,
  • für welche Zwecke eine Bearbeitung zulässig ist,
  • wo die Daten gespeichert werden,
  • welche Unterauftragnehmer beteiligt sind,
  • in welchem gebräuchlichen Format du Daten vollständig exportieren kannst,
  • wie Aufbewahrung, Rückgabe und Löschung beim Vertragsende ablaufen,
  • welche Sicherungen nach dem Ende noch bestehen und wann sie gelöscht werden.

Besonders wichtig ist der vollständige Export. Ein PDF-Bericht reicht nicht, wenn du das System bei einem anderen Anbieter weiterbetreiben willst. Du brauchst die strukturierten Rohdaten in einem dokumentierten Format, einschliesslich Beziehungen und Metadaten.

Achte auch auf Hosting-Verträge. Wenn die Agentur das Hosting in ihrem Namen gebucht hat, muss geregelt sein, wie Daten und Infrastruktur übertragen werden. Besser ist oft, wenn zentrale Cloud- und Plattformkonten auf dein Unternehmen lauten und die Agentur nur die nötigen Zugriffsrechte erhält.

Dokumentation: Das Wissen hinter dem Code

Eine funktionierende Übergabe besteht nicht nur aus Dateien. Du brauchst das Wissen, um die Software zu verstehen und zu betreiben.

Zur technischen Dokumentation gehören mindestens:

  • Eine Übersicht der Systemarchitektur.
  • Eine Beschreibung der Entwicklungsumgebung.
  • Anleitungen für Installation, Tests und Deployment.
  • Eine Liste aller externen Dienste und Abhängigkeiten.
  • Zugangsdaten oder ein dokumentierter Prozess für deren Übertragung.
  • Informationen zu Backups und Wiederherstellung.
  • Bekannte Einschränkungen und technische Schulden.
  • Ansprechpartner bei externen Anbietern.

Die Dokumentation sollte während des Projekts entstehen, nicht erst am letzten Tag. Wenn sie Teil der laufenden Arbeit ist, bleibt sie aktuell. Nachträglich geschriebene Dokumentation ist oft lückenhaft, weil Details vergessen wurden.

Vereinbare konkrete Abnahmekriterien. Zum Beispiel: Ein technisch qualifiziertes Team kann die Anwendung anhand der Dokumentation lokal starten und in eine Testumgebung deployen. Das ist überprüfbar. Ausreichende Dokumentation ist es nicht.

Exit: Den Wechsel vorbereiten, bevor er nötig ist

Niemand beginnt eine Zusammenarbeit mit dem Plan, sie zu beenden. Trotzdem gehört eine Exit-Regelung in jeden Vertrag. Sie ist kein Zeichen von Misstrauen, sondern professionelle Vorsorge.

Eine gute Exit-Klausel regelt:

  • Welche Unterlagen und Zugänge werden übergeben?
  • In welchem Format erfolgt der Datenexport?
  • Wie viel Unterstützung leistet die Agentur bei der Übergabe?
  • Zu welchem Stundensatz wird zusätzlicher Aufwand verrechnet?
  • Wie lange läuft das System während der Übergangsphase weiter?
  • Wann werden Kopien der Daten gelöscht?
  • Was passiert mit laufenden Lizenzen und Verträgen?
  • Gibt es eine Kündigungsfrist für Hosting und Support?

Plane für die Übergabe realistisch Zeit ein. Bei einer kleinen Anwendung können wenige Tage reichen. Bei komplexen Systemen dauert eine saubere Übergabe mehrere Wochen. In dieser Zeit arbeiten alte und neue Agentur idealerweise zusammen.

Eine Exit-Regelung schützt auch die Agentur. Sie verhindert, dass nach Vertragsende unbegrenzt kostenlose Unterstützung erwartet wird. Beide Seiten wissen, was geschuldet ist und was zusätzlich kostet.

Mehr zu den vertraglichen Grundlagen des laufenden Betriebs findest du in unserem Artikel Was gehört in einen Wartungsvertrag?.

Typische Warnsignale

Manche Vertragsformulierungen sollten dich aufmerksam machen:

  • Der Quellcode bleibt Eigentum der Agentur ohne ausreichende Nutzungsrechte für dich.
  • Nutzungsrechte gelten nur während der Vertragslaufzeit.
  • Die Agentur kann den Zugang zum System bei Zahlungsverzug sofort sperren, auch bei bestrittenen Rechnungen.
  • Datenexport ist nicht geregelt oder nur gegen angemessene Vergütung möglich.
  • Open-Source-Komponenten werden nicht dokumentiert.
  • Es gibt keine Verpflichtung zur Übergabe von Zugangsdaten.
  • Dokumentation wird nur nach Aufwand erstellt.
  • Die Agentur betreibt alle Konten in ihrem Namen und verweigert administrativen Zugriff.
  • Kündigungsfristen sind einseitig oder unverhältnismässig lang.

Nicht jede dieser Klauseln ist automatisch unfair. Es kann gute Gründe geben. Aber du solltest verstehen, was sie für deine Handlungsfähigkeit bedeutet, und bei Unsicherheit eine juristische Fachperson beiziehen.

Die Checkliste vor Projektstart

Kläre diese Punkte, bevor die Entwicklung beginnt:

  1. Urheberschaft und Rechte: Welche Nutzungs- und Verwertungsrechte werden übertragen oder lizenziert, und welche vorbestehenden Rechte bleiben bei der Agentur?
  2. Quellcode: Du erhältst von Anfang an Zugriff auf das Repository.
  3. Daten: Kontrolle, Zugriffsrechte, Datenschutzrollen, Export und Löschung sind vertraglich geregelt.
  4. Open Source: Verwendete Komponenten und Lizenzen werden dokumentiert.
  5. Dokumentation: Umfang und Qualitätskriterien sind festgelegt.
  6. Zugänge: Wichtige Konten laufen auf dein Unternehmen oder sind übertragbar.
  7. Exit: Übergabeprozess, Fristen und Kosten sind definiert.
  8. Weiterentwicklung: Du darfst andere Anbieter beauftragen.
  9. Hosting: Datenstandort, Backup und Übertragbarkeit sind geklärt.
  10. Rechtsprüfung: Die konkrete Vereinbarung wird bei relevanten Risiken fachlich geprüft.

Diese Klärungen kosten vor Projektstart wenig Zeit. Später können sie über Wochen Verzögerung und hohe Zusatzkosten entscheiden.

Handlungsfähigkeit statt Schlagworte

Die Frage Wem gehört der Code? lässt sich nicht mit einem einzigen Satz beantworten. Urheberschaft, Urheberpersönlichkeitsrechte, Nutzungs- und Verwertungsrechte, Quellcodezugriff und Datenkontrolle sind verschiedene Themen. Für deine Handlungsfähigkeit zählt, dass jedes davon klar geregelt ist.

Das Ziel ist nicht, der Agentur jede wiederverwendbare Zeile Code abzunehmen. Das Ziel ist, dein Produkt unabhängig betreiben, weiterentwickeln und zu einem anderen Anbieter übertragen zu können. Dazu brauchst du passende Rechte, den vollständigen Quellcode, geregelten Datenzugang und eine brauchbare Dokumentation.

Lass Verträge mit erheblichen rechtlichen oder geschäftlichen Folgen von einer spezialisierten Fachperson prüfen. Dieser Artikel kann die richtigen Fragen liefern, aber keine Beratung für deinen konkreten Fall ersetzen.

Wenn du ein Softwareprojekt planst und von Anfang an saubere technische und organisatorische Grundlagen schaffen willst, findest du mehr Informationen auf unserer Seite zur individuellen Softwareentwicklung.