Ich habe in den Seminaren lange Zeit strikt vertreten, daß Softwarepflegeverträge als Werkverträge zu qualifizieren sind. Es gibt natürlich Möglichkeiten, Softwarepflegeverträge aus als Dienstverträge auszugestalten. Darum geht es in diesem Blog.
Seit den Entscheidungen Internetsystemvertrag I bis III und der Entscheidung „Schneeräumdienst“ des BGH´s ist klar, daß Softwarepflegeverträge als Werkverträge qualifiziert werden müssen. Der BGH geht davon aus, daß Verträge, die darauf gerichtet sind, daß die Funktionsfähigkeit eines technischen System aufrecht erhalten wird, als Werkverträge zu qualifizieren sind. Werkverträge zeichnen sich im Gegensatz zu Dienstverträgen dadurch aus, daß ein bestimmtes Ziel erreicht wird. Werkverträge können auch Dauerschuldverhältnisse sein. Also sind Verträge, mittels derer dem Kunden versprochen wird, daß Software funktionsfähig bleibt, als Werkverträge einzustufen. Folge: Jedes neue Release, das dem Kunden übersendet wird führt ebenso zu einer Verlängerung der Gewährleistungszeit von mindestens einem Jahr. Das gleiche gilt für Supportarbeiten. Da Werkverträge jederzeit nach § 649 I BGB gekündigt werden können, gilt daß Laufzeitregelungen in Softwarepflegeverträgen eigentlich jederzeit von dem Kunden konterkarriert werden könnten. Der Kunde kann jederzeit kündigen. Nur hat der BGH in den Entscheidungen Internetsystemvertrag II und III aber klargestellt, daß der ITler alle aufwandsbezogenen Kosten bei dem Kunden geltend machen kann, weshalb der vorzeitige Weg aus einem Softwarepflegevertrag für einen Kunden meistens wenig lukrativ ist.
Nun kann man argumentieren, daß dies alles nur dann gilt, wenn dem Kunden ein positives Versprechen gegeben wird, durch das dem Kunde offen versprochen wird, der ITler verspräche, daß die Software allzeit funktioniere. Aber man muß sich sehr klar darüber sein, welche Signale von den Juristen wie verstanden werden. Warnendes Beispiel sind hier die Unterscheidungen zwischen dem Fehlerreaktions SLA und dem Fehlerbehebungs SLA. Der Fehlerreaktions SLA sagt ja nur, daß mit der Behebung des Fehlers begonnen wird, nicht aber wann und vor allem ob überhaupt eine Fehlerbehebung realisiert werden kann. Der Fehlerreaktions SLA indiziert also nicht, daß ein Werkvertrag vorliegt. SLA´s die eine Fehlerbehebung versprechen, indizieren als Leistungsbeschreibung daß die Parteien einen Werkvertrag abschließen wollten. Im ersten Fall wird dem Kunden versprochen: Ich kümmere mich um den Fehler binnen folgender Zeiten. Im zweiten Fall wird versprochen: Ich behebe den Fehler in folgenden Zeitspannen.
Und ich gehe noch einen Schritt weiter: Da die Auslegeung der Verträge immer auch aus der Perspektive der Kunden erfolgt, muß der ITler klar artikulieren, welche Teile des Vertrags unter Dienstvertrags- und ggf. welche unter Werkvertragsrecht fallen. Die Abgrenzung funktioniert nicht durch Überschriften und noch weniger durch einen schwer verständlichen, von Anglizismen durchtränkten Jargon. Es funktioniert nur dadurch, daß in der Leistungsbeschreibung des Vertrags klargestellt, was für Leistungen eigentlich wirklich erbracht werden. Hier muß der ITler klarstellen, was er nicht will. Will er nur Hilfe leisten aber für den Erfolg der Fehlerbehebung nicht einstehen, muß das deutlich gesagt werden. Sätze wie: „Wir leisten Support “ sagen einem Richter am Landgericht nicht, was gemeint ist. Steht dort ein Satz wie: Wir unterstützen Sie bei der Fehlerbehebung, können aber aufgrund der Besonderheiten der Technik nicht dafür einstehen, daß jeder Fehler, der während der Laufzeit dieses Vertrags aufgrund von Umständen, die wir nicht verschuldet haben, auch überhaupt oder binnen XX Stunden behoben ist, führt dies zur KLarheit (daß ich mich damit wieder zum Feind des Marketings mache ist mir klar, aber Teil meines Berufs).
Grundsätzlich sollten Sie deutlich beschreiben, daß alle Faktoren, die nicht aus Ihrer Risikosphäre stammen und einen technischen Fehler verursachten können, nicht durch werkvertragliche Pflichten abgedeckt sein können. 70 bis 80% aller technischen Fehler entstehen nicht durch „Höhere Gewalt“, sondern durch Inkompatibilitäten zwischen der Anwendung und der Systemumgebung oder der Software von Drittherstellern. Solche Fallgruppen einmal klar zu formulieren, ist wichtig.
