Internetworld 7/04, S. 48 – 50 (lokale Version)

Die prognostizierte Auflösung des seit Jahren bestehenden Investitionsstaus im IT-Bereich lässt hoffen, dass in diesem Jahr eine Vielzahl von neuen Softwareprojekten angegangen wird. Um diese wirtschaftlich erfreuliche Entwicklung auf rechtlich solide Füße zu stellen, empfiehlt es sich für Auftraggeber und Auftragnehmer, möglichst präzise Vereinbarungen des vertraglich Gewollten zu treffen.

Die Praxis zeigt, dass teilweise recht achtlos Aufträge oder Kooperationen mit erheblichen Volumina durchgeführt werden, ohne dass die Vertragsparteien ausreichend klare Regelungen getroffen haben, die ihren Interessen gerecht werden. Für häufige Konstellationen, bei denen Software individuell erstellt oder zumindest angepasst wird sowie für Kooperationen, soll dieser Beitrag eine Hilfestellung zur Beachtung der wichtigsten Aspekte bieten. Diese Vorschläge können wegen der regelmäßig individuell vorzunehmenden Anpassung nicht abschließend sein, geben indes eine Richtschnur, um gravierende Lücken zu vermeiden.

I. Vor dem Vertrag

Ein Softwarevertrag beginnt nicht erst mit Abschluss, sondern speziell bei innovativen IT-Projekten bereits im vorvertraglichen Stadium. Anders als bei einem einfachen Auftragsverhältnis zur Erstellung einer Software oder einer Homepage bedarf es bei innovativen Projekten oder gar beim Eingehen einer Kooperation der Sicherstellung des eigenen Know-how-Schutzes.

Müssen bei Vertragsverhandlungen nämlich technische Inhalte offenbart werden, besteht die Gefahr, dass bei einem Nichtzustandekommen die andere Vertragspartei die Erkenntnisse für eigene Projekte oder für Mitbewerber nutzt. Üblicherweise werden in solchen Konstellationen Geheimhaltungsvereinbarungen geschlossen, die sicherstellen, dass vertrauliche Inhalte nicht offenbart werden.

Darüber hinaus ist bei sensiblen Projekten ein zeitlich befristetes Wettbewerbsverbot ebenfalls denkbar, wobei die Intensität der Vereinbarung bis hin zu einer Verpflichtung zum Vertragsabschluss – dem „letter of intent“ – reichen kann. Um das Interesse an einer Verletzung der Geheimhaltsvereinbarung zu senken, empfiehlt sich die Festlegung einer empfindlichen Vertragsstrafe.

II. Vertragliche Inhalte

1. Vertragsgegenstand

Wichtig für den Auftraggeber ist zunächst eine möglichst präzise Definition, was der Auftragnehmer oder auch der Kooperationspartner zu leisten hat. Diese Leistungspflichten werden üblicherweise als Pflichtenheft in einer Anlage zum Vertrag näher spezifiziert. Wird im Rahmen des Vertragsprojektes eine Leistung nicht erbracht und fehlt es damit an einer vereinbarten Beschaffenheit, greifen Nacherfüllungsrechte des Leistungsgläubigers. Ohne die Festlegung bestimmter Spezifikationen wird dagegen nur ein „mittlerer Ausführungsstandard“ geschuldet (OLG Düsseldorf NJW-RR 1998, 345).

Nicht zuletzt das Projekt „Toll-Collect“ hat gezeigt, wie wichtig es sein kann, eindeutige und durchsetzbare Konsequenzen an Vertragsverstöße zu knüpfen.

Die im Pflichtenheft inhaltlich definierten Leistungselemente sollten daher zeitlich ebenfalls an bestimmte Zeitpunkte (Meilensteine) der Fertigstellung geknüpft sein. Werden diese nicht eingehalten, sollten einerseits eindeutige Nachfristen und andererseits Rechtsfolgen bei deren erneuten Nichteinhalten festgelegt werden.

Nach ganz herrschender Rechtsprechung gehört zur Hauptpflicht ebenfalls die Überlassung einer entsprechenden Benutzerdokumentation (BGH NJW 2001, 1718). Fehlt sie, ist der Auftraggeber berechtigt, die Abnahme zu verweigern (OLG Köln CR 2003, 95).

Soweit nicht eine weitergehende Nutzungsrechteeinräumung erfolgt – dazu unten – muss der Auftragnehmer den Quellcode als besonders geheimhaltungsbedürftiges Wirtschaftsgut grundsätzlich nicht überlassen. Ist die Überlassung aber Vertragsgegenstand, sollte ebenfalls eine Programmdokumentation den Quellcode und den dahinter stehenden Aufbau detailliert erläutern. In jedem Falle empfiehlt sich, dieses Thema eindeutig zu regeln.

2. Projektkosten und Änderungsverlangen

Häufig vereinbaren Vertragsparteien im Falle einer Beauftragung einen Festpreis für die Erbringung des Vertragsgegenstandes. Zu regeln ist in diesem Zusammenhang, ob und gegebenenfalls wie Änderungsverlangen zu vergüten sind. Relevant ist hierbei, ab wann ein Änderungsverlangen nicht nur eine andere, sondern eine zusätzliche Leistung beinhaltet. Ebenfalls können in diesem Rahmen auch Zeitpunkte definiert werden, bis zu denen Änderungsverlangen vorzuliegen haben, um doppelten Aufwand durch Umprogrammierung zu vermeiden.

Im Falle größerer Projekte, die sich über einen längeren Zeitraum hinziehen, wird regelmäßig die Fälligkeit der Vergütung nach dem Erreichen von Meilensteinen, also die zeitgerechte und erfolgreiche Herbeiführung der im Pflichtenheft genannten Leistungsgegenstände, vereinbart. Zur Absicherung des Auftraggebers kann zusätzlich je nach Solvenz des Auftragnehmers sowohl eine Erfüllungsbürgschaft bei Ausfall des Auftragnehmers als auch Gewährleistungsbürgschaft und/oder ein Gewährleistungseinbehalt vereinbart werden.

3. Aufteilung in Projektphasen

Nicht neu ist die Erkenntnis, dass die Erstellung von Software kaum ohne Fehler erfolgt. Dies gilt umso mehr bei komplexen Systemen, bei denen neben der reinen Erstellung des Codes auch die Integration von unterschiedlichen Schnittstellen oder Modulen zu erfolgen hat. In diesem dynamischen Prozess macht es daher Sinn, differenzierte Rechtsfolgen und Fehlerbeseitigungsfristen an den jeweiligen Leistungsphasen auszurichten.

Üblicherweise geschieht dies in zwei oder drei Abschnitten, die von der Entwicklungsphase über den ersten Livebetrieb in der Piltophase bis zur Abnahme führen.

Wegen der angesprochenen Fehlerproblematik und Vielzahl dynamischer Parameter in Software- und Hardwarekonstellationen wird zunächst in einer Entwicklungsphase bestimmt, welche Leistungsziele erreicht werden müssen; in diesem Stadium sollten die Vertragsparteien darüber einig sein, dass beim Eintritt in die nachfolgende Pilotphase noch immer Fehler vorhanden sind. „KO-Kriterium“ für den Eintritt in die Pilotphase sind gravierende Fehler, deren Schwere üblicherweise von Fehlerklasse 1 (sehr schwer) bis Fehlerklasse 3 (leicht) klassifiziert werden. Vor Eintritt in die Pilotphase sollte regelmäßig ein Funktionstest erfolgen, wobei es sich empfiehlt, die Testfälle und -parameter im voraus vertraglich festzulegen. Soweit die Software grundsätzlich läuft und nicht mit schweren Fehlern behaftet ist, wird sie regelmäßig im Echt-Betrieb der Pilotphase über den vereinbarten Zeitraum getestet und auftretende Fehler bis zum Abschluss der Pilotphase beseitigt. Dies hilft regelmäßig, Fehler zu erkennen und zu beseitigen, die in den Tests unter „Laborbedingungen“ nicht erkannt wurden, indes speziell beim Zusammenspiel von Komponenten oder neuen Programmzuständen erst auftreten. Setzt man hierfür Pilotkunden ein, muss diesen gegenüber eine Mitwirkungspflicht geregelt werden, die einerseits Pflichten zur Ausfall- und Fehlertoleranz, andererseits zum Bericht von Fehlern beinhaltet.

Sind etwaige Fehler bis zum vertraglich festgelegten Zeitpunkt – dem Abschluss der Pilotphase – beseitigt, wird der Auftragnehmer dem Auftraggeber den Vertragsgegenstand zur Abnahme vorstellen. Auch hier empfiehlt es sich, sowohl den Zeitraum, innerhalb dessen die Abnahme erfolgt, als auch das Procedere festzulegen, da im Gesetz dazu keine weiter gehenden Vorschriften enthalten sind.

Wichtig für den Erfolg eines Projektes ist, dass der Auftragnehmer seine Leistungsfähigkeit kennt und sich nicht in unrealistische Zeitpläne drängen lässt. Dies hilft weder ihm, da insoweit Konflikte vorprogrammiert sind, noch dem Auftraggeber, der bei Verzug seinerseits Planungsvorgaben nicht einhalten kann.

Um dennoch den Zuschlag für einen Auftrag zu erhalten, lohnt es sich, die jeweiligen Aspekte, die dem Zeitplan zugrunde liegen, detailliert darzulegen. Dies zeigt einem Auftraggeber die Auseinandersetzung mit seinen Belangen und dokumentiert Professionalität.

4. Nutzungsrechte und Wettbewerbsverbot

Zweites wesentliches Vertragselement neben der eigentlichen Softwareerstellung ist die Übertragung von Nutzungsrechten vom Auftragnehmer an den Auftraggeber.

Zu unterscheiden ist zunächst zwischen einfachen und ausschließlichen Nutzungsrechten.

Überträgt der Auftragnehmer einfache Nutzungsrechte, darf er die erstellten Werke neben dem Auftraggeber selbst nutzen und auch regelmäßig an weitere Kunden übertragen. Nur einfache Nutzungsrechte werden vielfach vor allem für immer wiederverwendbare Teile von Programmbibliotheken übertragen.

Ausschließliche Nutzungsrechte schließen dagegen den Urheber von der Nutzung seines eigenen Werkes aus. Mit Übertragung fallen dem Auftraggeber damit die alleinigen Rechte zu, mit dem Werk weitgehend nach Belieben zu verfahren.

Für den Auftragnehmer bedeutet dies gleichzeitig, dass der entsprechende Programmcode nicht einmal mehr für zukünftige Projekte verwendet werden darf. Ein Auftragnehmer sollte sich daher diesen Schritt ganz genau überlegen und im Rahmen seiner Kalkulation mit erheblichem Gewicht berücksichtigen.

Spiegelbildlich dazu sollte sich der Auftraggeber überlegen, ob er tatsächlich sämtliche Rechte benötigt oder ob ihm bereits damit gedient ist, einfache Rechte zu erhalten. Flankierend kann ein Verbot vereinbart werden, Softwarelösungen oder innovative Designelemente Mitbewerbern nicht zur Verfügung zu stellen, um gerade ein positives Differenzierungskriterium nutzen zu können. Indessen dürfte es den Anbieter von Lebensmitteln im Internet kaum stören, wenn Stilelemente auf der Unternehmens-Homepage eines Nutzfahrzeugeherstellers verwendet werden.

Denkbar ist auch hier eine technische Differenzierung, wonach für technische Werke einfache, dagegen für das Grafikdesign ausschließliche Nutzungsrechte übertragen werden.

Ein weiterer, ganz wesentlicher Gesichtspunkt ist die Frage der Einräumung von Bearbeitungsrechten und damit einhergehend die Herausgabe des Quellcodes. Räumt ein Auftragnehmer Bearbeitungsrechte ein, nimmt er sich zum einen die Möglichkeit, Folgeaufträge zu erhalten, zum anderen offenbart er bei Neuentwicklungen Know-how gegenüber Mitbewerbern, da Folgeaufträge dann teilweise von (günstigeren) Agenturen umgesetzt werden.

Darauf hinzuweisen ist hierbei, dass ohne die ausdrückliche Einräumung von Bearbeitungsrechten grundsätzlich keine Veränderung des Werkes ohne Einwilligung des Auftragnehmers erfolgen darf. In diesem Zusammenhang entschied jüngst das Landgericht Frankfurt, dass die unerlaubte Bearbeitung einer in Flash erstellten Webseite das Bearbeitungsrecht der Internetagentur verletzt (LG Frankfurt, Az.: 2-03 O 299/03).

Für den Fall, dass Open-Source-Elemente eingesetzt werden sollen, muss auch hier ganz genau darauf geachtet werden, wie deren Nutzung und Einbeziehung erfolgt. Nach der häufig geltenden General Public License (GPL) besteht zum einen die Gefahr, dass die vom Auftragnehmer erstellte Software ebenfalls unter diese Bestimmungen fällt. Dies hätte zur Folge, dass die Software unentgeltlich und unter Offenbarung des Quellcodes an Dritte weiterzugeben ist, was zu erheblichen Haftungsproblemen gegenüber dem Auftraggeber führen kann.

Zum anderen befindet sich in den angloamerikanischen Lizenzbedingungen der GPL regelmäßig ein Haftungsausschluss für Sachmängel, infolgedessen der Auftragnehmer bei Einsatz von GPL-Softwareelementen gegenüber dem Auftraggeber haftet, ihm andererseits keine Rückgriffsansprüche zustehen.

Wegen der Vielfältigkeit der Einräumungs- und Begrenzungsmöglichkeiten von Rechten kann hier aus Platzgründen nur eine grobe Skizzierung erfolgen. Zu erwähnen bleibt, dass der Urheber grundsätzlich ein Namensnennungsrecht hat, sodass ebenfalls zu überlegen ist, ob und in welchem Umfang dies abbedungen werden soll.

5. Mängelhaftung und Haftungsbegrenzung

Weist die Software Fehler auf, ergibt sich deren Beseitigungspflicht aus dem Gesetz. Der Gesetzgeber hat hier vergleichsweise auftraggeberfreundliche Regelungen geschaffen. Aus Auftragnehmersicht sollte versucht werden, möglichst lange Nachbesserungsfristen vertraglich festzulegen und außerdem sich nicht auf nur einen Nacherfüllungsversuch beschränken zu lassen. Im Interesse des Auftraggebers liegen demgegenüber kurze Reaktions- und Fehlerbeseitigungsfristen, sowie möglichst weit gehende Rechte, die nach dem Scheitern von Nachbesserungsversuchen Rücktritt oder Kündigung und Schadensersatz sowie gegebenenfalls auch Vertragsstrafe vorsehen.

Ein Ausgleich beider Interessen dürfte darin zu sehen sein, für geringfügigere Fehler, die der Fehlerklasse 3 zugeordnet werden, ein Rücktritts- oder Kündigungsrecht auszuschließen und hierfür lediglich ein Recht auf Minderung der Vergütung einzuräumen. Von Auftragnehmerseite ist vor allem bei Individualvereinbarungen an eine Haftungsbegrenzung zu denken, die sowohl im Grad des Verschuldens als auch der Höhe Beschränkungen enthalten kann. Bei AGB ist hier die Rechtsprechung zu beachten, wonach beispielsweise der Ausschluss der Haftung für eine fahrlässige Verletzung wesentlicher Vertragspflichten (sog. Kardinalpflichten) unwirksam ist.

Die Verjährung für Mängel beträgt nach dem Gesetz zwei Jahre, die im unternehmerischen Verkehr durch AGB auf ein Jahr verkürzt werden darf. Für beide Seiten sinnvoll kann hier die Ergänzung gesetzlicher Rechte durch ein vergütungspflichtiges Service-Level-Agreement sein, das Elemente von Wartung und Reaktionszeiten bei Fehlern ebenso enthalten kann, wie die Bereithaltung von Hotlines oder sogar Verfügbarkeitsgarantien für Systeme.

Sämtliche dargestellten Positionen sind freilich Verhandlungssache. Erklärt ein Auftragnehmer, eine bestimmte Leistung zu einem festgelegten Preis bis zu einem definierten Zeitpunkt leisten zu können, muss er sich daran genauso festhalten lassen, wie der Auftraggeber an seiner Pflicht zur Mitwirkung und pünktlichen Zahlung. Streitigkeiten, die sich aus unklaren Pflichten ergeben, können indes im Vorfeld durch deren eindeutige Festlegung vermieden werden.