Brief und Siegel, Software-Verträge,
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.
I.
Einführung als Videobeitrag
II.
Einführung zum Softwarerecht
III. IT Outsourcing und SLAs
IV. Online-Recht
|
