Früher wurden Verträge über die Übertragung von Nutzungsrechten an neu durch den Auftragnehmer zu erstellender Software gerne so gestaltet, dass ausschließliche Nutzungsrechte an den neuen Bestandteilen übertragen wurden.Das war schon damals problematisch. Standard- und Individualsoftware lassen sich schlecht trennen, die Kosten für den Betrieb individualisierter Software liegen deutlich höher, etc.
Aber unter den heutigen Bedingungen produzieren Regelungen über die Übertragungen von ausschließlichen Nutzungsrechten für beide Seiten das falsche Ergebnis.
Die Kosten für die Entwicklung und den Betrieb von Individualsoftware werden noch höher. Wer heute Individualsoftware in Auftrag gibt und dabei den klassischen Vollrechte-Vertrag nutzt, kauft ein Asset, dessen Wartung und Weiterentwicklung auf Anbieterseite absehbar teurer wird, weil dem Anbieter der Zugang zu modernen Entwicklungswerkzeugen versperrt ist. Ich kann die Idee der Exklusivität an den Rechten einer Auftragsarbeit verstehen, aber der rechtliche Hebel der ausschließlichen Nutzungsrechte wird mehr und mehr zur falschen Idee.
I. Situation
Der Reflex ist alt und stammt aus einer nachvollziehbaren Überlegung. Wenn der Kunde die Entwicklung bezahlt, will er die Rechte an dem Ergebnis. Ausschließlich, damit der Anbieter dieselbe Lösung nicht an den Wettbewerb weiterverkauft. Umfassend, damit auch spätere Anpassungen unter der eigenen Kontrolle bleiben.
Mit KI wird aus dieser Konstruktion ein aktuelles Betriebsproblem. Die Bearbeitung eines Computerprogramms ist nach § 69c Nr. 2 UrhG dem Rechtsinhaber vorbehalten. Wenn der Rechtsinhaber der Auftraggeber ist, weil die ausschließlichen Rechte an dem Programm auf ihn übergegangen sind, dann darf der Anbieter das Programm nicht ohne Zustimmung bearbeiten. Und die Nutzung eines KI-Werkzeugs zur Codeänderung ist Bearbeitung im Sinne der Norm. Wer Cursor, Claude Code, Copilot oder ein vergleichbares Werkzeug einsetzt, um an einer Codebasis zu arbeiten, bearbeitet sie im urheberrechtlichen Sinne.
Für Auftragsentwicklungsverträge klassischer Bauart heißt das: Der Anbieter, dem die Rechte an einer Individuallösung nicht mehr zustehen, weil er sie an den Kunden übertragen hat, darf mit dem Code nicht mehr arbeiten wie mit Code, der ihm gehört. Für die Wartung bedeutet rechtlich saubere Arbeitsweise die Einwilligung des Kunden für jeden Einsatz von KI-Werkzeugen. Das war schon vor dem KI Zeitalter so, die Bearbeitung der Software kann nur mit Zustimmung des Berechtigten erfolgen.
Aber nun kommt etwas, was durch den Einsatz der KI bedingt und neu ist: Durch den Einsatz von KI zur Bearbeitung der Kundensoftware verliert der Kunde seine Nutzungsrechte an der Software. Das ist dadurch begründet, dass ein mit KI generierter Code eben keinen Urheberrechtsschutz genießt.
II. Aufgabenstellung
In dem Maß, in dem die alte Software durch eine KI generierte Entwicklung neu gestaltet wird, verliert diese Software für den Kunden bilanztechnisch an Wert. Das macht Diskussionen über den Einsatz von KI noch schwieriger.
Weil KI die Zukunft ist und kein Unternehmen um die Verwendung dieses Werkzeugs herumkommen wird, stellt sich die Frage nach alternativen Schutzkonzepten, die zwei Anforderungen erfüllen sollen, nämlich einerseits die Verwendung von KI zu ermöglichen und auf der anderen Seite dem Kunden in einem gewissen Umfang die Exklusivität der Nutzung der Ergebnisse einzuräumen. Da gibt es im wesentlichen zwei Wege.
III. Geheimhaltung als Entwicklungshemmnis
Eine typische Vertraulichkeitsklausel verbietet dem Anbieter, vertrauliche Informationen des Kunden für eigene Zwecke zu verwerten. Der Gedanke ist einfach: was der Anbieter im Projekt lernt, soll nicht in Konkurrenzsoftware fließen. Der Effekt ist weitreichender. Er verhindert das Rückspielen fachlicher Erkenntnisse in die eigene Produktlinie des Anbieters, auch dann, wenn diese Erkenntnisse längst keine Geheimnisse mehr sind.
Rechtlich ist die Klausel oft weniger belastbar, als sie wirkt. Das Geschäftsgeheimnisgesetz schützt in § 2 Nr. 1 nur Informationen, die den Personen in den einschlägigen Fachkreisen nicht allgemein bekannt oder ohne weiteres zugänglich sind. Sobald eine Software beim Kunden im produktiven Einsatz ist, wird das Verhalten der Software für ihre Anwender sichtbar. Prozesse, Regellogiken, Datenstrukturen: was der Nutzer sehen kann, ist im Sinne des Gesetzes zugänglich. § 69d Abs. 3 UrhG erlaubt jedem, der zur Verwendung des Programms berechtigt ist, dessen Funktionieren zu beobachten, um die zugrundeliegenden Ideen und Grundsätze zu ermitteln. § 69g Abs. 2 UrhG ordnet an, dass vertragliche Bestimmungen, die diesem Recht widersprechen, nichtig sind. Wer die Software beim Kunden im Einsatz sieht, darf sich die zugrundeliegenden Ideen aneignen. Es wäre systemwidrig, ausgerechnet den Anbieter der Software daran zu hindern.
Operativ wirkt die Klausel trotzdem. Entwickler werden vorsichtig, Vertriebe verzichten auf die naheliegende Verwertung des Gelernten, Weiterentwicklungen bleiben in der Schublade. Was rechtlich Papier ist, wird faktisch zum Bremsklotz. Und das schadet allen Beteiligten. Der Anbieter verliert die Rendite seiner Lernkurve, der Kunde bekommt eine langsamere Produktentwicklung, die Rechtsabteilung schützt am Ende Positionen, die außerhalb ihres Vertrags längst offen liegen.
Für Rechtsabteilungen der Kunden ist der interessante Punkt: Der scheinbare Schutzgewinn ist niedrig. Was wirklich schützenswert wäre, konkrete Datenbestände, konkrete Konfigurationen, konkret zusammengetragenes Prozessverständnis, das noch nicht in die Software eingeflossen ist, lässt sich präziser regeln und schadet dem Anbieter nicht in seiner Produktentwicklung. Was die Klausel in ihrer Standardform tatsächlich fixiert, ist eine unspezifische Bindungswirkung, die kaum durchsetzbar, aber operativ hinderlich ist. Der Gewinn ist gering, der Kollateralschaden hoch.
IV. Wettbewerbsverbot
Explizite Wettbewerbsverbote sind in Auftragsentwicklungsverträgen die Ausnahme. Die faktische Wettbewerbswirkung ist die Regel. Sie entsteht aus der Kombination der ersten beiden Fesseln. Wer über die Ausschließlichkeit an der eigenen Codeverwertung gehindert ist und über die Vertraulichkeit an der Verwertung des Gelernten, ist im Ergebnis daran gehindert, im gleichen Anwendungssegment eigene Standardlösungen anzubieten. Niemand hat das ausdrücklich vereinbart. Die Wirkung ist dieselbe.
Die kartellrechtlichen Grenzen sind bekannt, aber im Vertragsalltag selten präsent. Die Vertikal-Gruppenfreistellungsverordnung stellt Wettbewerbsverbote zwischen Unternehmen für die Dauer eines laufenden Vertragsverhältnisses bis zu fünf Jahren frei. Nachvertragliche Wettbewerbsverbote sind noch enger begrenzt. Die Technologietransfer-Gruppenfreistellungsverordnung setzt für Know-how-Bindungen vergleichbare Maßstäbe. Was zeitlich unbegrenzt wirkt, ist rechtfertigungsbedürftig und im Regelfall nicht tragbar. Klauseln, die eine solche Wirkung erzeugen, sind über Artikel 101 Absatz 2 AEUV, § 1 GWB und § 134 BGB angreifbar. § 305c Abs. 2 BGB verstärkt den Angriff, weil Zweifel bei der Auslegung ohnehin zulasten des Verwenders gehen.
Für den Anbieter ist der Punkt unangenehmer als für den Kunden. Selbst wenn die Klausel angreifbar ist: Wer sich ihr im Vertrag unterworfen hat, trägt das Risiko unternehmerisch. Er muss im Ernstfall prozessieren, um sich zu befreien, und in der Zwischenzeit verhält er sich vorsichtig. Für die Rechtsabteilung des Kunden ist es der Moment, in dem sie sich fragen sollte, ob das erreichte Ergebnis mit dem eigentlichen Schutzinteresse noch etwas zu tun hat. Die Antwort ist meistens nein.