Zum „klassischen“ IT-Vertragsrecht, insbesondere bei Erstellungs-  und Anpassungsverträgen, gehört die Frage nach der Behandlung von drei spezifischen „Gegenständen“, nämlich „Pflichtenheft“, „Dokumentationen“ und „Quellcode“. Bei allen drei Gegenständen handelt es sich um fest im „EDV-Recht“ verankerte Institute. In den letzten Jahren hat sich jedoch einerseits unter organisatorisch/technischen Aspekten sehr viel getan. Andererseits sind kaum Entscheidungen zu Pflichtenheft, Dokumentationen und Quellcode bekannt geworden. Man könnte meinen, diese „Saurier“ wären ausgestorben. Dies verwundert angesichts der Tatsache, dass viele Projekte nach wie vor darunter leiden, dass keine fachliche Feinspezifikation als „Pflichtenheft“ zu Grunde gelegt wurde bzw. der Pfad der Tugend durch Change Request (oft unkontrolliert) verlassen wurde.

Ich möchte die Diskussion anregen, im größeren Rahmen dieses Blogs zu diskutieren, was aus diesen „Instituten“ geworden ist, bzw. wie diese heute im Rahmen neuerer technischer Entwicklungen zu sehen sind.

Die wohl bekannteste Entscheidung zur Pflicht des Auftraggebers, die fachlichen Vorgaben beizustellen, ist die des BGH v. 13.7.1988 – VIII ZR 292/ 87, CR 1989, 102 (Zur Thematik Mitwirkung bzw. Verantwortung s. aber auch BGH v. 28.6.1994 – X ZR 95/92, CR 1995, 265, und BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543. Die „jüngste“ ist BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422 m. Anm. Bartsch, CR 2010, 777– allerdings nur indirekt. Danach genügt vor Abnahme die einfache Aufforderung, die durch die Software zu bewirkende Funktion herbeizuführen. Eine Bezugnahme auf das Pflichtenheft, welche Leistung daraus noch fehlt, ist also nicht erforderlich. Ganz anders noch die Entscheidung v. 9.10.2010 zur Portierung: Dort spielte das Pflichtenheft gerade für die Mangeldefinition bzw. Gewährleistung eine herausragende Rolle:

In § 7 des Vertrages (war) geregelt, daß Nachbesserungswünsche, die sich auf die Funktionsfähigkeit nach dem Pflichtenheft beziehen, vom Auftraggeber innerhalb von vier Wochen nach Lieferung der Endversion geltend gemacht werden müssen (Nr. 1); eine darüber hinausgehende Gewährleistung jeglicher Art ist nach Nr. 2 der gleichen Bestimmung ausgeschlossen. (BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93)

Die letzte große Entscheidung zum Quellcode war wohl die vom 16.12.2003 – X ZR 129/01, CR 2004, 490 -, wonach dieser auch dann herauszugeben ist, wenn nichts Besonderes vereinbart ist. Allerdings müssen besondere Umstände vorliegen, die der BGH vage gelassen hat.

Dies war auch die letzte große Entscheidung mit Berücksichtigung der Dokumentation als Liefergegenstand. Allerdings war die Frage der Mitlieferungspflicht nicht besonders behandelt worden. Insofern ist auf BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367 m. Anm. Hoene, zurückzugreifen, v.a. auch was Fälligkeit der Dokumentation bei einem Projekt mit (zahleichen) Änderungen betrifft.

Bei den Dokumentationen steht nach wie vor im Raum, dass zu jeder Software (eigentlich auch Hardware) Benutzerhandbücher gehören. Wahrscheinlich gehört auch eine Installationsanleitung dazu. Die übrigen Dokumentationen – s. Liste – können jedoch nach Umständen zur Lieferungspflicht/Leistungspflicht gehören. In der Regel müsste dies aber im Einzelnen vereinbart werden. Evtl. ist unter Usability-Aspekten Dokumentation bei einem Großteil der Standardsoftware entbehrlich (Stiemerling, ITRB 2009, 154), dagegen für Anpassung und Erstellung unabweisbar (Stiemerling, ITRB 2011, 286)?

Ein Auftraggeber, der als Softwarehaus die zu erstellende Software vertreiben, o­­der ein Großanwender, der sich vom Auftragnehmer unabhängig machen will, wird u.a. verlangen (Zum Spektrum bei Eigenentwicklung s. Hoppen/Hoppen, CR 2009, 761, zur neueren technischen Entwicklung und Sichtweise s. Stiemerling, ITRB 2011, 286):

• Anwenderdokumentation („Handbücher“)

…………..(nur dazu hat der BGH entschieden)……………………………………………

• Installationsbeschreibung, wahrscheinlich wie Anwenderdokumentation,

• Administratoranweisungen

• Quellcode mit Programmbeschreibung + Kommentierung

• Beschreibung der Entwicklungsumgebung, evtl. die Entwicklungsumgebung selbst,

• Entwicklungsdokumentation, stand aller Einstellungen / Parameter bei Ãœbergabe/Ablieferung/Abnahme

• Die bei Generierung/Kompilierung entstandenen Ergebnisse sowohl in Text als auch in elektronischer Form

• Geschäftsmodell, Datenreferenzen, Datenmodell,

• „Wartungs-“ oder Pflegedokumentation.

Ohne Mitlieferung solcher geschuldeter Gegenstände (wenn sie denn geschuldet sind) wäre nicht erfüllt. Zwar müsste der Kunde eine Frist setzen. Er würde jedoch noch in üblicher Weise nicht Mängel rügen, sondern nicht gehörige Erfüllung, so dass insoweit auch nicht die kürzere Verjährungsfrist des Mängelrechts laufen würde. Es wäre noch nicht „abgeliefert“ bzw. noch nicht „abgenommen“.

Nebenbei zu Diskussion Software als Sache – wie verhält es sich mit den Dokumentationen?

II. Die einzelnen Themen

1. Pflichtenheft

Beim Pflichtenheft hat sich wohl die Erkenntnis durchgesetzt, dass der Begriff nicht ganz passend ist, weil die Sachverständigen und Techniker diesen anders verstehen, dass jedoch damit gemeint ist, dass der Kunde als Mitwirkungsleistung seine Anforderungen bekannt gibt. Insofern handelt es sich um eine Vorleistung bzw. Mitwirkungspflicht des Kunden (BGH v. 28.6.1994 – X ZR 95/92, CR 1995, 265 und v.a. – ohne den Begriff zu benutzen – BGH v. 13.7.1988 – VIII ZR 292/ 87, CR 1989, 102). Ohne Pflichtenheft gilt ein mittlerer Ausführungsstandard (BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543 und BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490). Und damit ist das Problem angedeutet: Was ist, wenn die Methodik – bei agil bzw. scrum – auf ein Pflichtenheft zu verzichten scheint, weil die Planung als eigene, vorgeschaltete Phase entfällt? Gilt dann auch – s. BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 – der „mittlere Ausführungsstandard“? Oder wird der Anforderungslevel anders bestimmt, etwa bei „agiler Methodik“, bei der der Kunde intensiver, ja gleichberechtigt in einer Weise leistet, was z.B. durch Einnahme diverser Rollen bei  Scrum weit über den Charakter der Obliegenheit hinausgeht?

2. Dokumentation

Gemäß der BGH-Entscheidung zur Dokumentation hat dieser u.a. die ganz wesentliche Aufgabe als „Handbücher“ per Perpetuierungswirkung zu entfalten: Die Handbücher sollen  in der Lage sein, neue Mitarbeiter des Anwenders selbst durch den Anwender einweisen zu lassen und zwar durch einen Mitarbeiter, der seinerseits vom Auftragnehmer anhand der Dokumentation eingewiesen worden war. So kann man den BGH (BGH v. 5.7.1989 – VIII ZR  157/88; s.a. Schneider, Handbuch des EDV-Rechts, 4. Aufl., D, Rz. 299 ff.) verstehen. Wenn die Software keiner Einweisung mehr „bedarf“, wenn der Selbsterklärungswert wesentlich höher ist bzw. die eigentliche Funktion der Dokumentation als Hilfestellung in die Onlinehilfe gewandert ist, bleibt dann noch Raum für die Dokumentation im Sinne der „Handbücher“? Schon immer war klar, dass die Dokumentation in sehr geringem Umfang als Handbücher aufweisen muss, wenn die Onlinehilfe besonders komfortabel ist. Wie ist dieses Verhältnis heute zu sehen?

Bei manchen Produkten ist die Mitlieferung einer Dokumentation völlig illusorisch, insbesondere bei Apps. Welche Funktionalität tritt an die Stelle der Handbücher? Gibt es überhaupt noch vergleichbare Funktionen?

Von den aufgelisteten Dokumentationen wäre nur die Installationsanleitung noch als eine Art Annex von der Rechtsprechung des BGH erfasst. Die Anwenderdokumentation müsste also eigentlich die Installationsanleitung enthalten. Ansonsten wäre die Installationsanleitung gesondert geschuldet. Wenn nun die Anwenderdokumentation als Handbücher entfällt, verbleibt es dann bei der Pflicht zur Mitlieferung einer Installationsanleitung? Bei selbstinstallierenden Programmen scheidet dies natürlich aus. Was aber ist mit den übrigen Arten der Dokumentation?

3. Quellcode

Der Quellcode wird bei vielen modernen Programmiersprachen hinsichtlich Programmiertechniken intensiv dokumentiert und zwar in dem Sinne, dass „Inline“-Kommentare hinterlegt werden. Das kann von besonderem Einfluss auf die Notwendigkeit der Mitlieferung einer Dokumentation v.a. im Sinne einer Beschreibung der Software sein und die Übergabe einer Entwicklungsdokumentation erledigten(?).

Bei vielen Web-orientierten Leistungen spielt der Quellcode auch bei moderneren Programmiersprachen bzw. bei den entsprechenden Web-orientierten durchaus noch eine Rolle. Der Quellcode wird u.a. im Hinblick auf die Schnittstellen, die Möglichkeit der Konvertierung bzw. des Datenexports u.ä. unter Aspekten der Wahrung des proprietären Charakters zurückgehalten, nun die BGH-Entscheidung vom 16.12.2003 so verstehen, dass auch in diesen Fällen, wenn der Kunde für weitere Möglichkeiten und sei es im Rahmen des Exit-Strategie, so etwa der Portierung des Quellcodes bedarf, zumindest die Teile herauszugeben sind, mittels derer die Herrschaft erhalten bleibt? Das neue System, also der Re-Import wäre unter Umständen äußerst aufwendig, wenn er sich nicht automatisch bewerkstelligen ließe. Gibt es insoweit evtl. Bedarf an einer anderen Art von Dokumentation bzw. eine die in den letzten Jahren kaum eine Rolle gespielt hat, nämlich die Beschreibung der Datenformate, der Einstellung der Parameter und des Datenmodells bzw. der Datenreferenzen?