Werkvertrag oder Dienstvertrag
Verspricht der Auftragnehmer (im Gesetz: Unternehmer) ein bestimmtes Ergebnis, etwa eine lauffähige Anwendung mit festgelegten Funktionen, liegt ein Werkvertrag nahe. Er schuldet dann die Herstellung des versprochenen Werkes (§ 631 Abs. 1 BGB). Sagt er nur die Mitarbeit von Entwicklern zu, ohne für ein Ergebnis einzustehen, schuldet er die versprochenen Dienste (§ 611 Abs. 1 BGB). Ob nach Stunden abgerechnet wird, entscheidet über die Einordnung als Werk- oder Dienstvertrag nicht allein, denn beide Vorschriften knüpfen an das Versprochene an. Ob für eigens entwickelte Software als herzustellende bewegliche Sache Kaufrecht gilt, ist im Einzelfall zu prüfen (§ 650 Abs. 1 Satz 1 BGB).
Für den Werkvertrag regelt das Gesetz die Abnahme, mit der die Vergütung fällig wird, und die Mängelrechte des Auftraggebers (im Gesetz: Besteller); das Dienstvertragsrecht enthält keine solchen Mängelrechte.
Bei Verbraucherverträgen über die Herstellung digitaler Produkte treten an die Stelle von Abnahme und werkvertraglichen Mängelrechten die Vorschriften über digitale Produkte (§ 650 Abs. 2 Satz 1 und 2 BGB); dazu die Seite Digitale Produkte und Abos.
Lastenheft, Pflichtenheft und Mitwirkung
Ob die Software mangelfrei ist, misst das Gesetz zuerst an der vereinbarten Beschaffenheit (§ 633 Abs. 2 Satz 1 BGB). In Projekten heißen die Leistungsbeschreibungen häufig Lastenheft und Pflichtenheft: Das Lastenheft beschreibt dann, was der Auftraggeber braucht, das Pflichtenheft, wie der Auftragnehmer es umsetzen will. Gesetzlich festgelegt sind diese Begriffe nicht. Es kommt darauf an, was ein Dokument enthält, wer es erstellt und freigibt und welches bei Widersprüchen vorgeht.
Neben den Funktionen sollte die Beschreibung Antwortzeiten, Nutzer- und Datenmengen, Schnittstellen, Sicherheitsanforderungen und die Dokumentation festlegen. Die Aushändigung des Benutzerhandbuchs hat der Bundesgerichtshof (BGH) als wesentliche Vertragsleistung bezeichnet (BGH, Urteil vom 16.12.2003, X ZR 129/01, S. 15 f.). Soweit die Beschaffenheit nicht vereinbart ist, muss sich die Software für die nach dem Vertrag vorausgesetzte, sonst für die gewöhnliche Verwendung eignen (§ 633 Abs. 2 Satz 2 BGB). Eine Anforderung, die im Pflichtenheft fehlt, kann deshalb trotzdem geschuldet sein, etwa wenn beide Seiten erkennbar davon ausgingen, dass die Software Daten an ein vorhandenes System übergibt.
Unterlässt der Auftraggeber eine Handlung, die zur Herstellung erforderlich ist, etwa eine fachliche Entscheidung oder die Lieferung von Testdaten, und kommt er dadurch in Annahmeverzug, kann der Auftragnehmer eine angemessene Entschädigung verlangen (§ 642 Abs. 1 BGB). Bestimmt er eine angemessene Frist mit der Erklärung, bei Ausbleiben der Handlung zu kündigen, gilt der Vertrag nach fruchtlosem Ablauf als aufgehoben (§ 643 BGB). Der Vertrag sollte die Mitwirkung mit Terminen benennen und festlegen, wer fachlich entscheidet und wer Mehrkosten zusagen darf.
Agile Softwareentwicklung im Vertrag
Bei agiler Entwicklung, etwa nach Scrum, steht der Funktionsumfang anfangs nur grob fest. Das Team arbeitet in kurzen Abschnitten (Sprints) eine geordnete Anforderungsliste (Product Backlog) ab und stellt das Ergebnis jeweils im Sprint Review vor. Diese Begriffe stammen aus der Projektmethode und haben keine gesetzliche Bedeutung.
Den Vertragstyp bestimmt auch hier das Leistungsversprechen. Übernimmt der Auftragnehmer die Verantwortung für eine einsatzfähige Software, spricht das für einen Werkvertrag; stellt er nur Entwickler, die nach Vorgaben des Auftraggebers arbeiten, eher für einen Dienstvertrag.
Auch im agilen Werkvertrag schuldet der Auftragnehmer das versprochene Werk (§ 631 Abs. 1 BGB), sodass sich feststellen lassen muss, was versprochen ist. Der Vertrag sollte bestimmen, welche Fassung des Backlogs und welche Akzeptanzkriterien verbindlich sind, wann ein Ergebnis als fertig gilt (Definition of Done) und wer Einträge freigeben darf. Bei einem festen Budget gehört dazu, was geschieht, wenn es verbraucht ist, bevor das Backlog abgearbeitet ist.
Ob ein Sprint Review eine Abnahme ist, hängt davon ab, ob der Auftraggeber das Ergebnis dabei als im Wesentlichen vertragsgerecht billigt. Das ist nach dem BGH das Kernstück der Abnahme; eine Freigabe für weitere Tests lässt sich dem nicht ohne Weiteres gleichsetzen (BGH, X ZR 129/01, S. 15). Sollen Ergebnisse einzelner Sprints rechtlich abgenommen werden, muss der Vertrag Teilabnahmen vorsehen und bestimmen, wer sie erklären darf.
Abnahme, Abnahmeprotokoll und Vergütung
Der Auftraggeber ist verpflichtet, das vertragsmäßig hergestellte Werk abzunehmen, und kann die Abnahme wegen unwesentlicher Mängel nicht verweigern (§ 640 Abs. 1 BGB). Hat der Auftragnehmer nach Fertigstellung eine angemessene Frist zur Abnahme gesetzt und verweigert der Auftraggeber sie nicht innerhalb dieser Frist unter Angabe mindestens eines Mangels, gilt das Werk als abgenommen (§ 640 Abs. 2 Satz 1 BGB). Ist der Auftraggeber Verbraucher, tritt diese Folge nur nach einem Hinweis auf die Folgen in Textform ein (§ 640 Abs. 2 Satz 2 BGB); für die Herstellung digitaler Produkte gilt gegenüber Verbrauchern stattdessen § 650 Abs. 2 BGB.
Für die Abnahme sollte der Vertrag ein Verfahren festlegen, mit Testumgebung, Testdaten, Prüffrist, Fehlerklassen und der Person, die die Abnahme erklärt. Das Abnahmeprotokoll hält fest, welcher Softwarestand geprüft wurde, welche Mängel offen sind und ob die Abnahme erklärt oder verweigert wird. Nimmt der Auftraggeber ab, obwohl er einen Mangel kennt, stehen ihm Nacherfüllung, Selbstvornahme, Rücktritt und Minderung wegen dieses Mangels nur zu, wenn er sie sich bei der Abnahme vorbehält (§ 640 Abs. 3 BGB). Stehen Abnahmeregeln in Allgemeinen Geschäftsbedingungen (AGB), gelten die Grenzen, die die Seite AGB für IT-Anbieter beschreibt.
Die Vergütung ist bei der Abnahme zu entrichten (§ 641 Abs. 1 Satz 1 BGB). Ist das Werk in Teilen abzunehmen und die Vergütung für die einzelnen Teile bestimmt, wird sie für jeden Teil bei dessen Abnahme fällig (§ 641 Abs. 1 Satz 2 BGB). Ist ihre Höhe nicht bestimmt, so ist die übliche Vergütung als vereinbart anzusehen (§ 632 Abs. 2 BGB).
Schon während des Projekts kann der Auftragnehmer Abschlagszahlungen in Höhe des Wertes der erbrachten und nach dem Vertrag geschuldeten Leistungen verlangen. Die Leistungen muss er durch eine Aufstellung nachweisen, die eine rasche und sichere Beurteilung ermöglicht. Sind sie nicht vertragsgemäß, kann der Auftraggeber die Zahlung eines angemessenen Teils des Abschlags verweigern (§ 632a Abs. 1 Satz 1, 2 und 5 BGB).
Änderungen und Change Requests
Ein Recht des Auftraggebers, Änderungen einseitig anzuordnen, regelt das Gesetz für den Bauvertrag (§ 650b Abs. 2 BGB), also für Arbeiten an einem Bauwerk oder einer Außenanlage (§ 650a Abs. 1 BGB). Für die Softwareerstellung enthält das allgemeine Werkvertragsrecht keine entsprechende Vorschrift, sodass eine Änderung des Vertragsinhalts einen Vertrag beider Seiten erfordert (§ 311 Abs. 1 BGB).
Ein vertragliches Änderungsverfahren (Change Request) legt fest, wer Änderungen beantragen und annehmen darf, bis wann der Auftragnehmer Aufwand und Termine bewertet, ob diese Prüfung vergütet wird und ob bis zur Entscheidung weitergearbeitet wird. Was schon zur vereinbarten Beschaffenheit gehört, schuldet der Auftragnehmer ohnehin (§ 633 Abs. 1 und 2 Satz 1 BGB). Ob ein Änderungsantrag Mehrvergütung auslöst, hängt davon ab, ob er über das Vereinbarte hinausgeht oder davon abweicht, und sollte im Änderungsverfahren geregelt sein.
Nutzungsrechte am Code und Herausgabe des Quellcodes
Programme in jeder Gestalt einschließlich des Entwurfsmaterials sind urheberrechtlich geschützt, wenn sie eine eigene geistige Schöpfung ihres Urhebers sind (§ 69a Abs. 1 und 3 UrhG). Schafft ein angestellter Entwickler das Programm in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers, ist ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse berechtigt, sofern nichts anderes vereinbart ist (§ 69b Abs. 1 UrhG). Der Auftraggeber eines Entwicklungsvertrags erhält dagegen die Nutzungsrechte, die ihm eingeräumt werden (§ 31 Abs. 1 UrhG); mehr dazu auf der Seite Urheberrecht am Quellcode.
Sind die Nutzungsarten nicht ausdrücklich einzeln bezeichnet, bestimmt der von beiden Seiten zugrunde gelegte Vertragszweck, wie weit das Recht reicht und ob es einfach oder ausschließlich ist (§ 31 Abs. 5 UrhG). Der Vertrag sollte deshalb regeln, ob der Auftraggeber den Code bearbeiten, von Dritten pflegen lassen oder vermarkten darf und ob der Auftragnehmer eigene Bausteine weiterverwenden darf. Eine Agentur sollte von freien Mitarbeitern und Zulieferern die Rechte erwerben, die sie ihrem Kunden zusagt. Für eingebundene Komponenten mit offenem Quellcode gelten deren Lizenzen; dazu die Seite Open-Source-Lizenzen.
Ob der Auftragnehmer auch den Quellcode herausgeben muss, ist ohne ausdrückliche Vereinbarung nach den Umständen des Einzelfalls zu beurteilen. Neben der Höhe der Vergütung kann nach dem BGH insbesondere zählen, ob das Programm zur Vermarktung durch den Auftraggeber erstellt wird und ob er für Wartung und Fortentwicklung Zugriff auf den Quellcode braucht (BGH, X ZR 129/01, Leitsatz a). Wer den Code selbst weiterentwickeln oder von einem anderen Dienstleister pflegen lassen will, sollte Herausgabe, Zeitpunkt, Dokumentation und eine Anleitung zum Erstellen der lauffähigen Fassung ausdrücklich vereinbaren. Wie eine Hinterlegung bei einem Dritten den Zugriff absichert, beschreibt die Seite Source Code Escrow.
Kündigung und Mängelrechte nach der Abnahme
Bis zur Vollendung des Werkes kann der Auftraggeber jederzeit kündigen. Der Auftragnehmer kann dann die vereinbarte Vergütung verlangen, muss sich aber ersparte Aufwendungen und anderweitigen Erwerb anrechnen lassen (§ 648 BGB). Aus wichtigem Grund können beide Seiten ohne Einhaltung einer Frist kündigen; der Auftragnehmer erhält dann nur die Vergütung für den bis zur Kündigung erbrachten Teil (§ 648a Abs. 1 und 5 BGB). Für ein vorzeitiges Ende sollte der Vertrag regeln, welche Zwischenstände, Unterlagen und Rechte der Auftraggeber erhält.
Nacherfüllung, Selbstvornahme, Rücktritt, Minderung und Schadensersatz wegen Mängeln (§ 634 BGB) kann der Auftraggeber grundsätzlich erst nach der Abnahme mit Erfolg geltend machen (BGH, Urteil vom 19.01.2017, VII ZR 301/13, Rn. 31). Bis dahin hat er den Anspruch auf mangelfreie Herstellung (Rn. 32). Den Streit über Abnahme, Kündigung und Schadensersatz behandelt die Seite IT-Projekt im Streit.
Wobei ich unterstütze
- Softwareerstellungsverträge und Leistungsbeschreibungen entwerfe oder prüfe ich für Auftraggeber, Softwarehäuser und Agenturen.
- Für agile Projekte gestalte ich Regeln zu Backlog, Freigaben, Teilabnahmen, Budget und Change Requests.
- Abnahmeverfahren und Abnahmeprotokolle bereite ich vor und berate Sie zur Abnahme oder ihrer Verweigerung.
- Nutzungsrechte, Quellcodeherausgabe und Hinterlegung stimme ich auf die geplante Nutzung der Software ab.
- Gerät das Projekt in Streit, vertrete ich Sie außergerichtlich und vor Gericht.
Häufige Fragen
Ist ein Softwareerstellungsvertrag ein Werkvertrag?
Verspricht der Auftragnehmer ein bestimmtes Ergebnis, etwa eine lauffähige Anwendung mit festgelegten Funktionen, liegt ein Werkvertrag nahe. Sagt er nur die Mitarbeit von Entwicklern ohne Verantwortung für ein Ergebnis zu, spricht das für einen Dienstvertrag.
Ist das Sprint Review eine Abnahme?
Nicht ohne Weiteres. Zur Abnahme gehört, dass der Auftraggeber das Werk als im Wesentlichen vertragsgerecht billigt. Eine Vorführung oder die Freigabe für die weitere Arbeit enthält diese Erklärung nicht automatisch. Sollen Sprintergebnisse abgenommen werden, muss der Vertrag Teilabnahmen vorsehen.
Bekomme ich als Auftraggeber den Quellcode?
Ist nichts ausdrücklich vereinbart, kommt es auf die Umstände des Einzelfalls an, etwa auf die Höhe der Vergütung, auf eine geplante Vermarktung durch Sie und darauf, ob Sie den Quellcode für Wartung und Fortentwicklung brauchen. Klarheit schafft eine ausdrückliche Regelung zu Herausgabe, Dokumentation und Nutzungsrechten im Vertrag.
Stand: 18.10.2026