Nutzungsrechte richtig einräumen

Die Software ist abgenommen, bezahlt und läuft im Produktivbetrieb. Dann soll ein anderer Dienstleister einen Fehler beheben, eine Tochtergesellschaft soll die Anwendung mitnutzen oder dein Team braucht Zugriff auf den Quellcode. Genau in diesem Moment zeigt sich, ob die Regelung zu den Nutzungsrechten trägt. Eine pauschale Formulierung wie „Der Kunde erhält die erforderlichen Rechte“ reicht dafür selten aus.

Bei Softwareverträgen musst du zwei Fragen sauber trennen: Wer bleibt Rechteinhaber und welche Nutzungsrechte erhält dein Unternehmen? Gerade bei Individualsoftware wird häufig angenommen, dass mit der Bezahlung automatisch alle Rechte übergehen. Das ist ein riskanter Irrtum. Urheberrechtlich geschützte Software bleibt grundsätzlich demjenigen zugeordnet, der sie geschaffen hat, soweit keine wirksame Rechteübertragung oder Rechtseinräumung geregelt ist.

Dein Vertrag muss deshalb nicht möglichst viele juristische Begriffe enthalten. Er muss den tatsächlichen Einsatz der Software präzise abbilden. Je konkreter dein Nutzungsmodell beschrieben ist, desto geringer ist das Risiko späterer Auslegungsstreitigkeiten.

Zuerst den tatsächlichen Nutzungsbedarf erfassen

Bevor du eine Rechteklausel verhandelst, solltest du klären, was dein Unternehmen mit der Software während ihrer gesamten vorgesehenen Lebensdauer tun können muss. Dabei reicht die erste Einführung nicht als Maßstab. Denke auch an spätere organisatorische, technische und wirtschaftliche Veränderungen.

Diese Fragen gehören auf deine Prüfliste:

• Welche Konzerngesellschaften, Betriebsstätten oder verbundenen Unternehmen sollen die Software nutzen dürfen?
• Soll die Nutzung nur intern erfolgen oder auch gegenüber Kunden, Lieferanten oder anderen Dritten?
• Wird die Software auf eigenen Systemen betrieben, in einer Cloud Umgebung oder durch einen externen Betreiber?
• Muss die Anwendung vervielfältigt werden, etwa für Test, Entwicklung, Sicherung und Notfallwiederherstellung?
• Soll dein internes Team Anpassungen vornehmen dürfen?
• Muss ein Drittanbieter die Software warten, analysieren oder weiterentwickeln können?
• Ist ein Verkauf, eine Umstrukturierung oder die Ausgliederung eines Geschäftsbereichs denkbar?
• Soll die Software in mehreren Ländern eingesetzt werden?
• Gibt es Schnittstellen, Erweiterungen oder individuelle Anpassungen, die getrennt nutzbar sein müssen?

Aus den Antworten entsteht der Rechtebedarf. Erst dann lässt sich beurteilen, ob ein einfaches Nutzungsrecht genügt oder ob du ein ausschließliches Nutzungsrecht benötigst.

Einfaches oder ausschließliches Nutzungsrecht

Ein einfaches Nutzungsrecht erlaubt dir, die Software in dem vereinbarten Umfang zu nutzen. Der Rechteinhaber darf die Software daneben grundsätzlich selbst weiter verwenden und weiteren Kunden Nutzungsrechte einräumen. Das ist bei Standardsoftware der Regelfall und meist auch wirtschaftlich nachvollziehbar.

Ein ausschließliches Nutzungsrecht geht deutlich weiter. Der Rechteinhaber darf die Software im eingeräumten Umfang grundsätzlich nicht mehr selbst nutzen oder Dritten entsprechende Rechte geben. Für individuell entwickelte Software kann das sinnvoll sein, wenn die Lösung einen Wettbewerbsvorteil abbildet oder speziell für dein Geschäftsmodell entwickelt wird.

Die Begriffe allein entscheiden aber nicht. Ein ausschließliches Nutzungsrecht kann zeitlich, räumlich oder inhaltlich eng begrenzt sein. Ebenso kann ein einfaches Nutzungsrecht sehr weit reichen. Entscheidend ist daher stets die Kombination aller Regelungsbestandteile.

Regelungspunkt	Einfaches Nutzungsrecht	Ausschließliches Nutzungsrecht
Nutzung durch den Anbieter	Grundsätzlich weiter möglich	Im eingeräumten Umfang grundsätzlich ausgeschlossen
Lizenzierung an Dritte	Grundsätzlich möglich	Im eingeräumten Umfang grundsätzlich ausgeschlossen
Typischer Einsatz	Standardsoftware, allgemein nutzbare Module	Strategische Individualsoftware, exklusive Branchenlösung
Verhandlungsaufwand	Häufig geringer	Regelmäßig höher, wirtschaftliche Folgen genau prüfen

Für viele Individualentwicklungen ist eine abgestufte Lösung sinnvoll. Du erhältst beispielsweise ausschließliche Rechte an den kundenspezifischen Teilen, während der Dienstleister seine vorhandenen Frameworks, Bibliotheken und allgemeinen Entwicklungskomponenten weiterverwenden darf. Das setzt voraus, dass der Vertrag die Bestandteile eindeutig voneinander abgrenzt.

Umfang nach Zeit, Gebiet und Inhalt festlegen

Nutzungsrechte sollten immer entlang von vier Dimensionen beschrieben werden: zeitlich, räumlich, sachlich und persönlich.

Zeitliche Begrenzung

Bei gekaufter Individualsoftware erwartest du häufig ein dauerhaftes Nutzungsrecht. Dann sollte der Vertrag klar sagen, dass das Recht unbefristet eingeräumt wird. Formulierungen, die das Nutzungsrecht an die Vertragslaufzeit oder an fortlaufende Zahlungen knüpfen, können zu einer unerwünschten Abhängigkeit führen.

Anders kann es bei Mietsoftware oder cloudbasierten Leistungen aussehen. Dort besteht das Nutzungsrecht typischerweise nur während der Vertragslaufzeit. Wenn individuelle Anpassungen entwickelt werden, musst du dennoch prüfen, was nach Vertragsende mit diesen Anpassungen geschieht. Kannst du Daten exportieren? Darfst du entwickelte Schnittstellen weiter nutzen? Kann ein Nachfolger auf die Ergebnisse zugreifen?

Räumliche Begrenzung

Eine Beschränkung auf Deutschland kann unpassend sein, wenn Mitarbeitende international arbeiten, Server in anderen Ländern stehen oder ausländische Gesellschaften eingebunden werden. Bei einer globalen Unternehmensstruktur ist ein weltweites Nutzungsrecht häufig die praktikabelste Lösung.

Achte auch darauf, dass die räumliche Reichweite zum technischen Betrieb passt. Wird eine Anwendung über das Internet bereitgestellt, lässt sich eine rein nationale Nutzung oft kaum kontrollieren. Die Vertragsregelung sollte deshalb den realen Zugriff und die berechtigten Nutzergruppen beschreiben, nicht nur einen formalen Standort.

Inhaltliche Begrenzung

Der inhaltliche Umfang beantwortet die wichtigste praktische Frage: Was darfst du konkret tun? Dazu können insbesondere gehören:

• Installation, Laden und Ausführen der Software
• Vervielfältigung für Betrieb, Tests, Entwicklung und Datensicherung
• Nutzung in virtuellen Umgebungen und redundanten Systemen
• Fehleranalyse und Behebung von Störungen
• Bearbeitung, Weiterentwicklung und Anpassung
• Verbindung mit anderer Software und Schnittstellen
• Nutzung durch beauftragte Dienstleister
• Übertragung innerhalb des Konzerns oder im Rahmen einer Umstrukturierung

Vermeide unbestimmte Begriffe wie „vertragsgemäße Nutzung“, wenn der Vertrag an anderer Stelle nicht konkret erklärt, was das bedeutet. Besser ist eine Klausel, die die erlaubten Nutzungsarten ausdrücklich aufzählt und zugleich klarstellt, dass technisch notwendige Vervielfältigungen zulässig sind.

Persönlicher Umfang

Hier regelst du, wer die Rechte ausüben darf. Beschränkt sich die Lizenz auf eine einzelne Gesellschaft, darf eine Muttergesellschaft, Tochtergesellschaft oder ein Shared Service Center die Software unter Umständen nicht nutzen. Das kann besonders problematisch sein, wenn zentrale IT Funktionen konzernweit erbracht werden.

Formuliere deshalb, ob auch verbundene Unternehmen, Rechtsnachfolger, Erwerber eines Geschäftsbetriebs und beauftragte Dienstleister die Software im erforderlichen Umfang nutzen dürfen. Bei Dienstleistern sollte klargestellt werden, dass sie nur für dein Unternehmen handeln und keine eigenen Nutzungsrechte erhalten.

Individualsoftware sauber von vorbestehenden Bestandteilen trennen

Bei Individualsoftware besteht ein Projekt selten nur aus vollständig neuem Code. Häufig setzt der Auftragnehmer eigene Werkzeuge, Bibliotheken, Templates, Frameworks oder ältere Codebestandteile ein. Zusätzlich können Open Source Komponenten oder Software Dritter enthalten sein.

Der Vertrag sollte deshalb mindestens drei Gruppen unterscheiden:

1. Vorbestehende Komponenten des Auftragnehmers
2. Neu entwickelte, kundenspezifische Arbeitsergebnisse
3. Komponenten Dritter einschließlich Open Source Software

Für die neu entwickelten Ergebnisse brauchst du regelmäßig weitgehende Rechte. Für vorbestehende Komponenten genügt oft ein dauerhaftes, weitreichendes einfaches Nutzungsrecht, sofern du die Software unabhängig betreiben, warten und weiterentwickeln lassen kannst.

Kritisch wird es, wenn der Dienstleister zwar den individuell entwickelten Code übergibt, aber zentrale technische Bestandteile nur eingeschränkt lizenziert. Dann ist die Individualsoftware faktisch nicht unabhängig nutzbar. Prüfe deshalb nicht nur die Rechte am einzelnen Quelltext, sondern auch die Rechte an allen Abhängigkeiten.

Bei Open Source Komponenten reicht ein bloßer Hinweis im Vertrag nicht aus. Du brauchst eine vollständige und aktuelle Komponentenliste mit den jeweiligen Lizenzbedingungen. So kannst du beurteilen, ob Pflichten zur Offenlegung, Hinweisgebung oder Weitergabe von Lizenztexten entstehen.

Quellcode: Übergabe ist nicht gleich Nutzungsrecht

Der Quellcode ist die lesbare Form eines Programms. Ohne ihn sind Fehlerbehebung und Weiterentwicklung durch Dritte häufig nur eingeschränkt möglich. Die bloße Übergabe des Quellcodes löst aber nicht automatisch dein rechtliches Problem. Du musst auch die Befugnis erhalten, ihn zu vervielfältigen, zu bearbeiten, weiterzuentwickeln und durch Dritte bearbeiten zu lassen.

Für Individualsoftware sollte der Vertrag insbesondere festlegen:

• In welchem Format der Quellcode übergeben wird
• Ob Build Anleitungen, Entwicklungsumgebungen und technische Dokumentation dazugehören
• Ob der Quellcode dem tatsächlich produktiv eingesetzten Stand entspricht
• Wann Übergaben erfolgen, etwa bei Meilensteinen, Abnahme und Vertragsende
• Welche Rechte du an Änderungen und Weiterentwicklungen erhältst
• Ob ein Dritter den Quellcode für dich warten und bearbeiten darf
• Wie mit Zugangsdaten, Konfigurationsdateien und automatisierten Bereitstellungsprozessen umzugehen ist

Ein Hinterlegungsmodell kann sinnvoll sein, wenn der Dienstleister den Quellcode nicht laufend herausgeben will. Entscheidend sind dann klare Auslösefälle und ein praktikabler Zugriff. Eine Hinterlegung hilft nicht, wenn du nach der Herausgabe nur lesen, aber nicht bearbeiten lassen darfst.

Typische Klauseln mit hohem Risiko

Besondere Aufmerksamkeit verdienen Regelungen, die auf den ersten Blick harmlos wirken:

• „Nutzungsrechte erst nach vollständiger Zahlung“: Prüfe, ob Teilzahlungen, streitige Rechnungen oder geringfügige Restbeträge deine Nutzung gefährden können.
• „Nicht übertragbar“: Diese Klausel kann Umstrukturierungen, Outsourcing oder einen Unternehmensverkauf erschweren.
• „Keine Bearbeitung“: Dann darfst du die Software unter Umständen weder selbst anpassen noch durch einen Dienstleister weiterentwickeln lassen.
• „Nur für interne Zwecke“: Kläre, ob Testsysteme, Konzernnutzung, externe Administratoren und kundennahe Funktionen davon erfasst sind.
• „Rechte an Arbeitsergebnissen verbleiben beim Auftragnehmer“: Diese Aussage passt selten zu einer Individualentwicklung, wenn du langfristig unabhängig bleiben willst.
• „Soweit erforderlich“: Frage immer, wer später bestimmt, was erforderlich ist. Besser sind konkrete Nutzungsbefugnisse.

Wenn du Nutzungsrechte und Quellcodefragen systematisch prüfen möchtest, findest du passende Seminare und Termine bei uns auf cmt.de.

Eine praxistaugliche Schlussprüfung vor der Unterschrift

Lege den Vertragsentwurf einer einfachen Szenarioprüfung unter. Stelle dir vor, der bisherige Dienstleister fällt aus. Kann ein neuer Anbieter die Software rechtmäßig übernehmen, betreiben, analysieren und weiterentwickeln? Kann dein Konzern die Anwendung nach einer Umstrukturierung weiter nutzen? Darf dein Team Sicherungskopien, Testinstanzen und technische Anpassungen erstellen?

Wenn du diese Fragen nicht eindeutig mit „ja“ beantworten kannst, fehlt meist keine juristische Feinheit, sondern eine konkrete Nutzungsbefugnis im Vertrag. Rechteklauseln sollen nicht nur den Projektstart absichern. Sie müssen deinen Handlungsspielraum auch dann schützen, wenn sich Organisation, Technik oder Dienstleister ändern.