Checkliste: Projektverträge rechtlich richtig gestalten

Christoph Kappes , Geschäftsführer der auf Digital Business spezialisierten Unternehmensberatung Fructus  , hat nachfolgend Praxistipps zur Gestaltung Projektverträgen im Hinblick auf Software-Nutzungsrechte gelistet:

A. Nutzungsrechte allgemein
1. Zu unterscheiden sind ausschließliche von nicht-ausschließlichen Nutzungsrechten. Wichtig zum Verständnis der Unterscheidung ist, dass bei nicht-ausschließlichen Nutzungsrechten ein Dritter vom Urheber Nutzungsrechte erhalten kann - das ist nicht immer gut für den Auftraggeber, da die Software vom Auftragnehmer mehrfach übertragen werden kann (unjuristisch formuliert) und dies seine Interessen berühren kann. In der Praxis werden dennoch häufig nicht-ausschließliche Nutzungsrechte vereinbart, da erstens Teile der Software nicht nur für das konkrete Projekt entwickelt wurden, zweitens dieser Aufwand nicht oder kaum in den bezahlten Projektaufwand einfließt und drittens mitunter wirklich pfiffige Lösungen erdacht werden, die mit Standardtagessätzen allein nicht abgegolten sind (man denke z.B. an unsichtbare Wasserzeichen, eine kleine Geheimwissenschaft).
Wer als Auftraggeber mit nicht-ausschließlichen Rechten nicht leben kann, sollte sehen, dass auch ein Verbot seinem wirtschaftlichen Interesse genügt, eine gleichartige Software nicht für einen Wettbewerber des Auftraggebers zu erstellen. Beispiel: An einer X-Plattform für die Z-Zielgruppe erhält der Auftraggeber zwar nur nicht-ausschließliche Rechte, der Auftragnehmer darf jedoch während einer Periode von einem Jahr ab Abnahme keinem direkten Wettbewerber Nutzungsrechte einräumen.

2. Das darf mit übertragbaren bzw. nicht-übertragbaren Nutzungsrechten nicht verwechselt werden. Bei übertragbaren Rechten darf der Auftragnehmer die Nutzungsrechte Dritten übertragen, sonst nicht. Bei Auftragsentwicklung von Softwareprodukten ist das ein Muss, wenn z.B. Data Becker eine Software entwickeln lässt und diese über den Einzelhandel im Laden "verkauft". In vielen anderen Fällen ist die Übertragbarkeit jedoch verzichtbar, da der Auftraggeber die Software nur selbst verwenden möchte. Dennoch sollte man als Kunde darauf achten, dass die Software als ganze übertragen werden darf, z.B. wenn der Auftraggeber einen Geschäftsbereich schließen möchte und einen Interessenten zur Nutzung hat. In diesem Zusammenhang sind gegebenenfalls auch Klauseln vorzusehen, welche die Nutzung im Konzern des Auftraggebers regeln (also von vornherein die Nutzungsrechtseinräumung an verbundene Unternehmen i.S. des AktG oder zumindest die entgeltfreie Übertragbarkeit an solche Unternehmen.)

Exkurs für Verträge mit Konzernen: Sehr beliebt ist eine Klausel, wonach die Rechteübertragung an "verbundene Unternehmen" sofort erfolgt oder später erlaubt ist. Ein "verbundenes Unternehmen" meint aber nicht "irgendwie wirtschaftlich verflochten", sondern ist ein Fachbegriff und im Aktiengesetz in § 15 ff geregelt. Dies sind keineswegs alle Unternehmen, die im Konzerndiagramm auftauchen, sondern nur Mehrheitsbeteiligungen sowie Beherrschungsverhältnisse und wechselseitig beteiligte Unternehmen. Eine Minderheitsbeteiligung oder sogar ein 50-prozentiges Joint-Venture fällt also nicht darunter (sofern die Beteiligung nicht wechselseitig zwischen Mutter und Tochter ist) - ganz wichtig! Wer sich auf solche Klauseln einlässt oder sie durchsetzen möchte, sollte sich erstens das Konzerndiagramm genau ansehen und zweitens sollten beide Seiten - je nach dem, was gewollt ist - eine zusätzliche (Positiv-)Liste oder eine Ausschlussliste vereinbaren.

3. Ich bin ein Freund klarer, kurzer und verständlicher Verträge, bei der Nutzungsrechtsklausel müssen aber alle Arten der Nutzung in allen Mediengattungen und einige andere Punkte geregelt werden. Das ist ein Zehnzeiler, leider, und den sollte ein Fachmann machen. Die beiden DAUs die ich erlebt habe: Eine Konzernrechtsabteilung regelt das "Eigentum am Datenträger", damit darf der Konzern dann die CD z.B. an die Wand nageln, Nutzungsrechte werden dadurch nicht übertragen. Ebenso beliebt ist es, ein bestimmtes Medium nicht zu "erwischen", deswegen quälen sich ganze Branchen mit der Nachverhandlung von Altverträgen, die keine Nutzung in neuen Medien erlauben.

4. Immer beliebter sind selbstentwickelte Frameworks und Komponenten des Auftragnehmers. Diese sollten von der Nutzungsrechtsklausel erfasst werden, soweit es um die Laufzeitversion der Software geht und diese Komponenten nicht isolierbar und verzichtbar sind.

B. Nutzungsrechte am Quellcode
1. Zunächst: Die Herausgabe von Quellcode (im Unterschied zur sog. Laufzeitversion, über die ich oben geschrieben habe) ist keine Selbstverständlichkeit. Mit einer Software kann man prima arbeiten, ohne den Quellcode zu haben. Auch wenn Sie ein Auto kaufen, brauchen Sie keine Konstruktionszeichnungen. Der Wunsch nach Quellcode ist daher prinzipiell nicht weniger sensibel als die Forderung nach Konstruktionszeichnungen. Wenn sich Auftraggeber und Auftragnehmer also nicht einig werden, sollte man über eine gesonderte Vergütung verhandeln, dies wird dann den Interessen beider Seiten gerecht. Je nach Knowhow sind 20 Prozent Aufschlag bis zu 200 Prozent Aufschlag (z.B. bei Finanzsoftware) nicht unüblich. Ich empfehle auch, gleich ein paar Personentage Einarbeitung im Vertrag festzulegen und diese marktüblich zu vergüten, denn auch der beste Quellcode ist nicht selbsterklärend. Ich erinnere mich gut, als ich mich vor Jahren in fremden Code einarbeiten musste, wie sich mir einige "selbsterklärende" Variablennamen partout nicht erschließen wollten und eine Zeichnung sehr geholfen hätte, wann eine ausgeklügelte Assemblerroutine welchen Pointer wohin setzt und was in diesem Adressbereich stehen sollte.

2. Die Herausgabe des Quellcodes für den Fall der Krise ist eine beliebte und berechtigte Forderung, die Herausgabe allein ist aber für den Auftraggeber nur begrenzt sinnvoll. Wenn man dies vereinbart, sollten dann auch Dokumentationsstandards geregelt werden (Inline-Doku, Objektmodell, Datenmodell, Architekturdiagramme etc.). Au?erdem gehören einige Dateien dazu, die man zur Nutzung in einer Entwicklungsumgebung braucht, hier projektspezifisch einen Tekkie fragen, um ganz sicher zu gehen.

3. Des weiteren ist die Frage, wann der Quellcode herauszugeben ist. Hier ist ein beliebter Standard, dass dies bei der Eröffnung des Insolvenzverfahrens gilt - und das ist zu spät! Entweder man knüpft dies an eine erhebliche Vermögensverschlechterung des Auftragnehmers oder gleich an einen Fakt, den man nicht diskutieren oder gar vor Gericht beweisen muss. Mehr dazu auf Anfrage.

4. Schließlich reicht der Quellcode allein nicht, denn das Recht zur Weiterbearbeitung, gegebenenfalls durch Dritte, muss geregelt werden. Ansonsten "hat" der Auftraggeber den (Besitz am) Code, darf damit aber nichts machen.

5. Die Bearbeitung von Quellcode durch einen anderen als den Urheber ist kritisch, weil sich bei Fehlern nicht ohne weiteres klären lässt, ob der Fehler durch den Urheber, den Bearbeiter oder durch das Zusammenwirken beider entstanden ist. Daher verliert der Bearbeiter häufig nach individueller Vereinbarung Gewährleistungsrechte gegen den Auftragnehmer. Ein ganz schlauer Mensch hat mir allerdings eine derartige Klausel schon einmal vorgelegt mit der Formulierung, die Gewährleistung entfalle mit "Übergabe des Quellcodes" - das ist natürlich nicht akzeptabel. Akzeptabel ist dies nur, wenn der Quellcode bereits vom Auftraggeber bearbeitet wurde und gegebenfalls, wenn sich die Fehlerquelle nicht feststellen lässt (Zweifelsregelung).

5. Ein Sonderthema ist in diesem Zusammenhang, dass Dienstverträge von Programmiereren fehlerhaft in Bezug auf die Nutzungsrechtsübertragung sein können, hier sollte der Auftraggeber einmal kurz draufschauen. In der Softwarebranche ungern erwähnt, aber leider Praxis, ist, dass Code von Firma zu Firma "mitgenommen" wird. Ein ganz heikles Thema, auf das ich hier im Blog nur aufmerksam machen möchte: Die Haftung hierfür hat beim Auftragnehmer zu liegen.

6. Ein Herausgabeanspruch ist gerichtlich nicht leicht durchsetzbar, wenn der Auftragnehmer die Herausgabe verweigert. Daher empfiehlt sich die notarielle Hinterlegung, sie kostet wenig (z.B. Geschäftswert 50.000 Euro -> weniger als 100 Euro) und sie geht heute sogar digital vom Desktop aus, siehe http://www.priormart.com/  . Da der Notar die Software nicht prüft, empfiehlt sich für sensible Fälle eine Escrow-Vereinbarung; Escrow-Institute begleiten den gesamten Prozess von technischer Prüfung bei Abgabe des Codes über Datensicherung und Aktualisierung bis Herausgabemanagement. Ein guter Einstieg sind hier die Webseiten des TÜV, der diesen Service bietet.

C. Vertragswerk
Viel Chaos entsteht in der Praxis dadurch, dass Musterverträge verschiedener Art miteinander kombiniert werden. Erstens Rahmenverträge und Einzelverträge - man muss natürlich beide durchsehen, damit die Rechtslage klar wird. In der Praxis werden Rahmenvereinbarung gern durch Einzelverträge ausgehebelt, insbesondere durch nicht-standardisierte Erstellungsscheine, hier bitte genau prüfen. Zweitens haben Verträge unterschiedliche Leistungsgegenstände: ein Lizenzvertrag für ein Softwareprodukt, ein Customizing-Vertrag vs. ein Vertrag über eine Individualentwicklung. Zudem noch der zugehörige Wartungsvertrag. Das sind, wenn es in allen diesen Fällen noch Rahmen- und Einzelverträge gibt, bis zu sechs Verträge. Hier kann leicht etwas durcheinander gehen, zumal im Dienstleistungsvertrieb mitunter "last minute" Anpassungen an Standards gemacht werden. Also bitte in allen diesen Verträgen die Rechteklauseln prüfen - sonst kann es passieren, dass am gewarteten Code das Recht der Weiterbearbeitung umstritten ist, weil genau dies im Wartungsvertrag nicht ausdrücklich geregelt ist. Das Ergebnis ist, dass der Auftraggeber nur die alte, ungewartete Software bearbeiten darf - ein wirtschaftlicher GAU.