Rechtliche Stolperfallen in Softwareverträgen

Werkverträge und Dienstleistungsverträge unterscheiden sich darin, was geschuldet wird: beim Werkvertrag ein fertiges Ergebnis, beim Dienstleistungsvertrag die Leistung selbst. Agile Softwareverträge gelten vor Gericht oft als Werkverträge, weil das Backlog das Werk definiert. Wenige gezielte Vertragsklauseln verhindern Haftungsrisiken, die Unternehmen in den Konkurs treiben können.

Das Wichtigste in Kürze

• Agil entwickelte Software gilt vor Gericht fast immer als Werkvertrag, auch wenn der Vertrag “Dienstleistungsvertrag” heißt, weil Gerichte die Intention beider Parteien und nicht die Überschrift bewerten.
• Freelancer haften für Fehler in ihrer Arbeit bis zu zwei Jahre lang, ohne dafür zusätzlich bezahlt zu werden, sofern keine gegenteilige Vertragsklausel vereinbart ist.
• Wer im Vertrag keine Warn- und Hinweispflicht erfüllt und den Auftraggeber nicht auf unvermeidbare Softwarefehler hinweist, riskiert, das gesamte bereits gezahlte Honorar zurückzuerstatten.
• Der Stand der Technik gilt zum Zeitpunkt der Produktübergabe, nicht zum Zeitpunkt der Beauftragung, was bei langen Projekten erhebliche technische und juristische Konsequenzen hat.
• KI-gestützte Testmethoden entsprechen derzeit nicht dem Stand der Technik, weil wissenschaftliche Studien zu ihrer Effektivität noch fehlen.

Selbstständige schulden einen Erfolg, kein Bemühen

Wer als Freelancer arbeitet, schuldet rechtlich etwas grundlegend anderes als ein Angestellter. Ein Selbstständiger schuldet einen Erfolg, nicht nur die aufgewendete Mühe. Es reicht nicht, viele Stunden in ein Projekt gesteckt zu haben. Es muss ein Projekterfolg entstanden sein.

Das gilt für Informatiker genauso wie für einen Fliesenleger oder Tischler. Legt der Fliesenleger in fünf Stunden die Fliesen und etwas geht kaputt, muss er den Fehler ohne zusätzliche Bezahlung beheben. Übertragen auf Software heißt das: Wer als Freelancer Bugs in eine Software einbaut, hat rechtlich keinen Anspruch darauf, für deren Behebung bezahlt zu werden.

In der Praxis läuft es anders. Freelancer werden meist auch dafür bezahlt, ihre eigenen Fehler zu fixen. Dieser Anspruch existiert aber nur, wenn er vertraglich festgehalten ist. Ohne entsprechenden Passus fällt die Fehlerbehebung unter die Gewährleistung und damit auf eigene Kosten.

Wie sicherst du dich als Freelancer im Vertrag ab?

Schreib in den Vertrag, dass fehlerfreie Software technisch nicht möglich ist und dass die Behebung von Fehlern nicht unter die Gewährleistung fällt, sondern als normale Dienstleistung weiter abgerechnet wird. Dieser eine Satz verschiebt die Logik zu deinen Gunsten.

Das betrifft Entwickler und Tester gleichermaßen. Ein Kunde, der einen Tester bucht, erwartet, dass dieser die Fehler findet. Findet der Tester von 4521 Fehlern nur 4520, stellt sich die Haftungsfrage, gerade wenn dadurch ein Schaden entsteht. Auch hier hilft die Klarstellung, dass kein Mensch alle Fehler finden kann.

Ein praktischer Rat dazu: Verspich in deiner Werbung niemals, dass du alle Fehler findest. Solche Superlative wirken später vor Gericht gegen dich.

Bei der Haftung lässt sich differenzieren. Grobe Fahrlässigkeit kannst du nicht ausschließen. Leichte Fahrlässigkeit, also die alltäglichen Patzer, die jedem passieren, kannst du dagegen vertraglich ausnehmen.

Wie lange haftest du, wenn nichts geregelt ist?

Ohne abweichende Vereinbarung gilt in Deutschland und Österreich eine Gewährleistung von zwei Jahren. Im B2B-Bereich lässt sich diese Frist verkürzen, aber nicht unter sechs oder zwölf Monate.

Versuche, die Gewährleistung darunter zu drücken oder grobe Fahrlässigkeit auszuschließen, scheitern. Schreibst du etwa nur drei Monate Gewährleistung und einen Ausschluss bei grober Fahrlässigkeit in den Vertrag, weist der Richter diesen Passus zurück. Er gilt dann, als stünde er nicht da, und die zwei Jahre greifen weiter.

Die Haftung reicht über die Gewährleistung hinaus. Sie betrifft nicht nur die Behebung eines Fehlers, sondern die Kosten des entstandenen Schadens. Bei großer Software kann das einen Freelancer schneller in den Bankrott treiben als die reine Nachbesserung.

Warn- und Hinweispflicht: ohne Warnung kein Geld

Kommt ein Selbstständiger seiner Warn- und Hinweispflicht nicht nach, kann das den gesamten Honoraranspruch kosten. Weist du einen Kunden nicht darauf hin, dass Software Fehler enthalten kann, lässt sich dieser Mangel später gegen dich verwenden, selbst wenn die Arbeit abgeschlossen ist.

Der Kunde kann dann argumentieren, er sei nie darüber aufgeklärt worden, dass die Software Fehler enthalten könnte, und das gesamte gezahlte Geld zurückverlangen. Ein einziger Warnpunkt im Vertrag genügt, um das zu verhindern.

Wie streng die Warnpflicht greift, hängt von der Erfahrung des Käufers ab. Kommt der Auftraggeber selbst aus der IT, gilt ein anderer Maßstab als bei einem Kunden, der noch nie Software hat entwickeln lassen. Maßgeblich ist das für den Käufer Erwartbare. Von einem Tischler erwartet jeder, dass der Tisch nicht zusammenbricht, wenn man darauf steigt.

In der Praxis trifft das Freelancer selten hart, weil sie meist nicht die ersten in einem eingespielten Projekt sind. Heikel wird es bei kleinen Projekten für IT-unerfahrene Kunden. Dort gehört der Warnhinweis zwingend in den Vertrag.

So bekommst du eine Vertragsänderung leicht durch

Zwischenhändler legen Freelancern oft fertige Verträge vor, ohne die dahinterliegenden rechtlichen Feinheiten zu kennen. Sie reichen die Dokumente nur weiter. Das macht die Sache einfacher, als viele denken.

Statt über einzelne Passagen zu diskutieren, ändere den Vertrag selbst, füge deinen Passus ein und schick ihn unterschrieben zurück. Ein unterschriebenes Dokument läuft erfahrungsgemäß glatter durch als eine offene Verhandlung über einzelne Klauseln.

Agile Verträge: warum die Überschrift nichts entscheidet

Der gefährlichste Irrtum bei agilen Projekten betrifft die Unterscheidung zwischen Werkvertrag und Dienstleistungsvertrag. Es gibt im Kern nur diese beiden Vertragsarten. Beim Werkvertrag schuldest du ein fertiges Werk, vorher durch ein Pflichtenheft definiert. Beim Dienstleistungsvertrag schuldest du die Leistung selbst.

Bei agiler Individualsoftware steht zu Beginn nicht fest, was die Software am Ende können soll. Genau das macht die vertragliche Einordnung schwierig. Viele Verträge tragen die Überschrift “Dienstleistungsvertrag” und rechnen nach Stunden ab, in der Annahme, damit sei die Sache geklärt.

Vor Gericht zählt das nicht. Weder die Überschrift noch die Abrechnung nach Stunden definieren einen Dienstleistungsvertrag. Steht im Vertrag, dass eine bestimmte Software entwickelt wird, ist es ein Werkvertrag. Entscheidend ist die Intention des Vertrags, und zwar so, wie ein nicht fachkundiger Auftraggeber sie interpretiert. Der versteht einen agilen Softwarevertrag typischerweise als Werkvertrag.

Das Backlog wird zur geschuldeten Leistung

Wird ein agiler Vertrag als Werkvertrag gewertet, schuldest du die definierten Inhalte vollständig. Und das Einzige, was in einem agilen Projekt definiert, was die Software können soll, ist das Backlog.

Daraus folgt eine unangenehme Logik: Die Software gilt erst als fertig, wenn das gesamte Backlog umgesetzt ist. Dazu zählen auch die Storys und Features, die der Product Owner erst vor zwei Tagen hineingeschrieben hat. Und den Product Owner stellt in vielen Projekten der Kunde.

Rechtlich ist es zulässig, dass sich der Projektinhalt erst im Lauf der Zeit herausstellt. Genau dieser Mechanismus kippt ein Projekt aber in einen Werkvertrag, bei dem du das Gesamte schuldest.

Ein konkreter Fall zeigt die Sprengkraft. Ein Auftraggeber reklamierte laufend neue Features ins Backlog, ganz im agilen Sinn. Irgendwann stellte er die Zahlungen ein und klagte auf Rückabwicklung sämtlicher Zahlungen, mit dem Argument, das Backlog sei noch voll und die Software damit nicht fertig. Es ging um mehrere Millionen Euro. Für ein kleines Unternehmen bedeutet so ein Urteil den Konkurs.

Diese Sätze machen aus dem Werkvertrag einen Dienstleistungsvertrag

Wenige präzise Formulierungen entscheiden, ob ein Gericht einen Vertrag als Dienstleistungs- oder als Werkvertrag wertet. Diese Punkte gehören hinein:

• Der Auftragsgegenstand ist zu Beginn nicht klar dargelegt.
• Der Auftraggeber arbeitet gemeinsam am Projekt und priorisiert die Features jederzeit neu.
• Der Auftraggeber ist entscheidend in den Prozess eingebunden und erteilt Weisungen.
• Im Vordergrund steht die Erbringung der Dienstleistung, nicht das fertige Softwareprodukt.
• Der Auftragnehmer trägt keine Verantwortung für den Erfolg, sondern für die Qualität der Leistungserbringung.

Der Punkt mit den Weisungen ist heikel, weil er an die Frage der Scheinselbstständigkeit rührt. Hier kollidieren zwei rechtliche Logiken, und das verlangt Sorgfalt bei der Formulierung.

Diese Passagen sind im Grunde die schriftliche Fassung des agilen Gedankens. Sie halten fest, dass du nicht den Projekterfolg schuldest, sondern die gemeinsame Arbeit am Produkt.

Was “Stand der Technik” im Vertrag wirklich bedeutet

In fast keinem Vertrag steht, was technische Qualität konkret heißt. Oft findet sich nur die Floskel “entspricht dem Stand der Technik”. Was darunter zu verstehen ist, klärt im Streitfall ein Sachverständiger, und sein Urteil hängt stark von der Vertragslage ab.

Vorsicht ist bei Superlativen geboten. Steht irgendwo “beste Qualität”, liest ein Gericht das als “keine Fehler”. Solche Formulierungen erhöhen deine Haftung, statt sie zu begrenzen.

Statt den Stand der Technik im Detail festzunageln, vereinbare einen Prozess. Schreib in den Vertrag, dass im Lauf des Projekts gemeinsam mit dem Auftraggeber nach festgelegten Regeln entschieden wird, was dem Stand der Technik entspricht. Dann haben Sachverständiger, Richter und gegnerischer Anwalt einen abgestimmten Prozess in der Hand, den sie nur noch auf Plausibilität prüfen müssen.

Definierst du in diesem Prozess etwa, dass eine Testabdeckung von 30 Prozent genügt, ist das verbindlich. Ohne solche Festlegung kommt ein Sachverständiger und fordert 80 Prozent Coverage, eine Zahl, die ohnehin fragwürdig ist.

Wie ein Sachverständiger den Stand der Technik bewertet

Eine einzelne Technik gilt dann als Stand der Technik, wenn die wissenschaftliche Literatur sie stützt. Die Bewertung läuft in Schritten ab. Zuerst die Frage, ob es überhaupt Literatur zu einer Technik gibt. Dann, ob diese Literatur belegt, dass die Technik effizienter und effektiver ist als bestehende Alternativen.

Das Beispiel Mob-Programming gegen Pair-Programming zeigt den Maßstab. Zu Pair-Programming existieren wissenschaftliche Untersuchungen, die belegen, dass es effizienter und effektiver ist als Solo-Programming. Zu Mob-Programming findet sich dagegen keine eindeutige wissenschaftliche Aussage über höhere Effizienz oder Effektivität.

Eine Methode bleibt erlaubt, auch ohne Studienlage. Wer Mob-Programming einsetzen will, sollte aber Erfahrungen sammeln, die über das Bauchgefühl hinausgehen: Zeiten messen, zwei Teams an derselben Aufgabe vergleichen. Dokumentierte Entscheidungen, etwa in Architecture Decision Records, geben jeder eingesetzten Technik eine nachvollziehbare Begründung.

Restfehlerrate statt Code Coverage

Geht es darum, ob ein Endprodukt brauchbar ist, zählt nicht die Code Coverage der automatisierten Tests, sondern die Restfehlerrate. Den Auftraggeber interessiert selten, ob er zu viel gezahlt hat. Ihn interessiert, ob er die Software überhaupt verwenden kann.

Die Restfehlerrate lässt sich berechnen. Liegt sie über 0,5 Bugs pro 1000 Lines of Code, gilt die Software als nicht fertig. Bei großer Software fällt die absolute Zahl naturgemäß höher aus als bei kleiner.

Die Realität ist ernüchternd. Im Schnitt liegt die Restfehlerrate laut Literatur deutlich höher, bei 20 bis 30 Bugs pro 1000 Lines of Code. Daraus folgt, dass die meiste verwendete Software hinsichtlich ihrer Restfehlerrate nicht dem Stand der Technik entspricht.

Wann landet ein Projekt bei der Frage nach den Techniken?

Die Techniken eines Projekts werden meist erst in zweiter Linie geprüft. Zuerst klärt ein Gutachten, ob die Software abnahmebereit ist. Erst wenn sie es nicht ist, geht es um die Schuldfrage: Lag es an schlechten Techniken im Test oder im Code?

Dann zählt, ob alles auf eine Karte gesetzt wurde. Im Testen ist es schlecht, sich allein auf End-to-End-Tests zu verlassen. Verschiedene Techniken nebeneinander sprechen für saubere Arbeit, ein einzelner Ansatz dagegen.

KI im Testen: derzeit dünnes juristisches Eis

Wer Software von künstlicher Intelligenz testen lässt, bewegt sich rechtlich auf unsicherem Grund. Es gibt so gut wie keine wissenschaftlichen Studien dazu, ob KI in Softwareentwicklung und Test dem Stand der Technik entspricht.

Das Argument “gute Coverage durch KI-generierte Tests” hilft deshalb nicht weiter. Solange die Studienlage fehlt, lässt sich der Einsatz von KI nicht als Stand der Technik belegen.

Stand der Technik und Wissenschaft hängen zusammen, sind aber nicht dasselbe. Solange die Wissenschaft zu einer neuen Methode schwammig ist, gilt weiter der alte Stand der Technik. Erst wenn Studien belegen, dass eine Methode qualitativ und produktiv mindestens gleich gut ist, wird sie automatisch zum neuen Stand der Technik.

Dieser Maßstab verschiebt sich laufend. Was zu Projektbeginn Stand der Technik ist, kann es am Ende nicht mehr sein. Entscheidend ist der Stand der Technik zum Zeitpunkt der Übergabe des Produkts, nicht zum Zeitpunkt der Beauftragung. Bei langen Projekten kann das einen Unterschied machen.

Verträge schreibt man für den Feind, nicht für den Freund

Ein Vertrag dient nicht dazu, festzuhalten, wie man zusammenarbeitet. Er dient dem Schadensfall.

Den Vertrag schreibt man immer für den Gegner. Also immer im Kopf halten: Der Vertrag ist nicht für einen Freund, sondern für einen Feind geschrieben.

Sebastian Dietrich

Auch wenn das Gegenüber heute ein netter Mensch ist, kann morgen ein neuer Jurist ins Unternehmen kommen und die Lage komplett verschieben. Diese Perspektive ändert, worauf man beim Lesen eines Vertrags achtet.

Der Aufwand für die Absicherung ist gering im Verhältnis zum Risiko. Bei einem konkreten Fall, in dem die Existenz eines Unternehmens am seidenen Faden hängt, hätten zwei Sätze in einem Vertrag mit hunderten Sätzen gereicht. Über viele Seiten stand, wie gut agile Softwareentwicklung ist. Die entscheidenden Passagen fehlten.