Wem gehört der Code? Quellcode-Eigentum im Softwarevertrag sicher regeln

“Der Code gehört dann uns, oder?” Die Frage kommt fast immer. Meistens am Ende des Erstgesprächs, halb nebenbei, als wäre sie längst geklärt. Ist sie nicht. Und ehrlich gesagt ist sie sogar die falsche Frage.

Eigentum am Code, so wie du Eigentum an einem Auto hast, gibt es im deutschen Recht nämlich nicht. Wer beim Quellcode über Eigentum im Vertrag verhandelt, verhandelt am Kern vorbei. Der Code “gehört” urheberrechtlich dem Menschen, der ihn geschrieben hat. Was du wirklich brauchst, sind Nutzungsrechte. Die entscheiden darüber, ob du die Software frei einsetzen, ändern und irgendwann den Anbieter wechseln kannst.

Klingt nach Wortklauberei? Ist es nicht. An diesem Unterschied hängt, ob du in drei Jahren noch handlungsfähig bist oder von einem Dienstleister abhängst, mit dem du längst nicht mehr zusammenarbeiten willst.

Warum Quellcode-Eigentum im Vertrag der falsche Fokus ist

Im Urheberrecht gilt das Schöpferprinzip: Urheber ist, wer ein Werk schafft. Software ist als Computerprogramm geschützt, geregelt in den §§ 69a folgende UrhG. Der Entwickler, der die Zeilen tippt, ist und bleibt also der Urheber.

Und dieses Urheberrecht kannst du nicht kaufen. § 29 UrhG sagt klipp und klar, dass das Urheberrecht nicht übertragbar ist. Es bleibt beim Entwickler, egal wie viel du zahlst. Übertragbar sind nur die Nutzungsrechte nach § 31 UrhG. Davon gibt es zwei Sorten. Ein einfaches Nutzungsrecht heißt: Du darfst die Software nutzen, andere aber auch. Ein ausschließliches Nutzungsrecht heißt: Du nutzt sie unter Ausschluss aller anderen, sogar des Urhebers selbst, und darfst Rechte an Dritte weitergeben.

Der Haken kommt, wenn im Vertrag nichts steht. Dann greift die Zweckübertragungsregel aus § 31 Abs. 5 UrhG. Im Zweifel räumt der Entwickler nur so viele Rechte ein, wie der Vertragszweck unbedingt erfordert. Laut IT-Recht Kanzlei landest du damit bei einem einfachen, nicht übertragbaren Nutzungsrecht. Mehr nicht. Kein Anspruch auf den Quellcode, kein Recht, die Software von jemand anderem umbauen zu lassen.

Das ist der wunde Punkt: Du hast die Entwicklung voll bezahlt und darfst die Software trotzdem nicht frei weiterentwickeln lassen. Kein Sonderfall, sondern der Normalfall, wenn niemand es sauber aufschreibt.

Der Sonderfall, den viele verwechseln: eigene Angestellte

Bei den eigenen Mitarbeitern sieht die Sache anders aus. Schreibt dein Angestellter ein Programm in Wahrnehmung seiner Aufgaben oder nach deiner Anweisung, bist laut § 69b UrhG allein du zur Ausübung aller vermögensrechtlichen Befugnisse berechtigt, ohne dass du extra etwas vereinbaren musst. Absatz 2 zieht dieselbe Regel auf Dienstverhältnisse.

Nur gilt das eben ausschließlich für Arbeitnehmer. Der externe Freelancer und die beauftragte Agentur sind keine Angestellten. Für sie greift § 69b nicht, und alle Rechte bleiben zunächst beim Entwickler. Wer diesen Unterschied nicht kennt, wähnt sich abgesichert und ist es nicht. Genau hier entstehen die teuren Missverständnisse.

Was in den Softwarevertrag gehört

Vier Punkte entscheiden, ob du frei bist. Geh sie mit deinem Anbieter Zeile für Zeile durch, am besten bevor die erste Rechnung kommt.

1. Umfang der Nutzungsrechte. Lass dir ein ausschließliches Nutzungsrecht einräumen, zeitlich und räumlich unbegrenzt, übertragbar und inklusive Bearbeitungsrecht. Das Bearbeitungsrecht ist der Punkt, der am häufigsten fehlt. Ohne es darfst du die Software zwar nutzen, aber nicht von einem Dritten anpassen lassen. Übertragbar heißt, du kannst die Rechte weitergeben, etwa wenn du den Betrieb verkaufst.

2. Herausgabe von Quellcode und Dokumentation. Ohne ausdrückliche Regelung bekommst du den Quellcode meistens nicht. Der Bundesgerichtshof hat das schon 2003 klargestellt, im Urteil vom 16. Dezember 2003 zum Aktenzeichen X ZR 129/01: Bei Individualsoftware entscheidet eine Interessenabwägung, und im Zweifel reicht es, dass du die Software nutzen kannst. Willst du sie später anpassen lassen, brauchst du den Code. Also schreib die Herausgabe hinein, samt Dokumentation und einer Anleitung, wie sich die Software neu bauen lässt.

3. Fremd- und Open-Source-Bibliotheken. Kaum eine Software entsteht heute ohne fertige Bausteine. Lass dir auflisten, welche Open-Source-Komponenten verbaut sind und unter welcher Lizenz. Manche sind harmlos, etwa MIT oder Apache. Andere haben es in sich. Bei starkem Copyleft wie der GPL kann die Verbindung mit deinem Code dazu führen, dass am Ende der gesamte Code offengelegt werden muss. Der Open-Source-Leitfaden des Bitkom bringt es auf den Punkt, dass ein Entwickler früh darüber aufklären sollte, welche Komponenten er einsetzt und welche Pflichten daran hängen.

4. Escrow als Rückversicherung. Manchmal willst du den Quellcode nicht selbst verwalten, der Anbieter will ihn aber auch nicht offenlegen. Dann gibt es die Quellcode-Hinterlegung, im Fachjargon Escrow. Ein neutraler Treuhänder verwahrt den Code und rückt ihn nur in vorab definierten Fällen heraus, etwa bei Insolvenz des Anbieters oder wenn er die Wartung einstellt. Der Knackpunkt ist die Insolvenzfestigkeit. Ein schlecht gebauter Escrow-Vertrag nützt im Ernstfall wenig, deshalb gehört so eine Konstruktion in fachkundige Hände.

Die häufigsten Fehler

Mündlich statt schriftlich. “Der Code gehört euch” beim Kaffee bringt dir gar nichts. Zählt nur, was im Vertrag steht.

Ausschließliches Recht ja, Bearbeitungsrecht vergessen. Halbe Miete. Du darfst nutzen, aber nicht umbauen lassen, und stehst beim ersten Änderungswunsch wieder beim ursprünglichen Anbieter Schlange.

Nur an Eigentum gedacht, nicht an Wechselfähigkeit. Der eigentliche Schmerz ist selten die Rechtsfrage, sondern der Vendor Lock-in. Wenn nur der Anbieter den Code versteht und die Doku fehlt, bist du gebunden, egal was im Vertrag steht. Wie du diese Abhängigkeit von Anfang an klein hältst, haben wir im Beitrag zur Abhängigkeit von Software und SaaS auseinandergenommen.

Die Open-Source-Frage überspringen. Wer nicht weiß, was in der eigenen Software steckt, erlebt später böse Überraschungen. Ein einziger Copyleft-Baustein an der falschen Stelle kann dir den ganzen Plan verhageln.

Diese Punkte hängen eng mit den teuersten Fehlern beim Beauftragen von Individualsoftware zusammen. Wer dort schludert, zahlt es an genau dieser Stelle nach.

Worum es wirklich geht

Hör auf, über Eigentum zu streiten. Kläre stattdessen drei Fragen. Darfst du die Software frei nutzen? Darfst du sie ändern lassen, auch von jemand anderem? Kommst du an Quellcode und Dokumentation, wenn du den Anbieter wechseln willst? Wer hier dreimal ja hat, dem kann das Wort Eigentum herzlich egal sein.

Und weil das ein Rechtsthema ist, die nötige Ehrlichkeit dazu: Das hier ist Praxiswissen, keine Rechtsberatung. Die Grundbegriffe stimmen, aber jeder Vertrag liegt anders. Sobald größere Summen im Spiel sind, lass den Entwurf von einer Fachanwältin oder einem Fachanwalt für IT-Recht prüfen, also von jemandem, der für seine Aussage haftet.

Willst du wissen, ob dein Vertragsentwurf dich wirklich handlungsfähig hält? Schau dir an, wie wir Software entwickeln, oder nimm dir einen Termin. Wir gehen die Punkte gemeinsam durch, ehrlich und ohne Verkaufsdruck.