1

Fachausschuss Vertragsrecht der DGRISitzung am 16.4.2010 in München

Moderne Vertragsgestaltung vs. BGB (und BGH?)

Beitrag J. Schneider

Was bleibt bei modernen Projektmethoden von den in der Rspr.entwickelten Positionen?

Lösungsmöglichkeiten in der Vertragsgestaltung

Berücksichtigung von- BGH v. 23.7.2009 - VII ZR 151/08 bei Projektverträgen,

zusammen mit- BGH v. 9.2.2010 – X ZR 82/07 – Tiefladesattelauflieger, und- BGH v. 4.3.2010 - III ZR 79/09 Web-Design-Vertrag.

2

Gliederung

VORWEG Thesen ..................................................................................................................3I. Moderne Projektmethoden ......................................................................................4

1. Manifesto for Agile Software Development ...........................................................42. Principles behind the Agile Manifesto.....................................................................43. SCRUM ......................................................................................................................54. Prototyping ...............................................................................................................65. V-Modell.................................................................................................................7

II. Typische Merkmale moderner Projektmethodik, v.a. bei Extreme Programming .81. Versuch Schema zu Extreme Programming ..........................................................82. Projektverträge in der Rspr., BGB a.F. - Werkvertrag ........................................103. Abgleich Projektvorgehensmodelle und Rspr. Positionen ..................................10

III. BGH – intervenierende Variable über § 651 BGB? ...............................................141. BGH v. 23.7.2009 – Silowände .............................................................................142. BGH v. 9.2.2010 - Tiefladesattelaufleger.............................................................163. BGH v. 4. März 2010 - III ZR 79/09 Web-Design-Vertrag .................................16

IV. OLG München v. 23.12.2009 „gegen“ BGH, Lit.....................................................181. OLG München v. 23.12.2009 – 20 U 3515/09, CR 2010, 156 ...........................182. Lit. Stellen zu Projektvertrag und § 651 .............................................................18

V. Argumentationen gegen § 651-Anwendung aus den BGH-Urteilen .....................191. Argumentations-Ansatz aus 23.7.2009:...............................................................192. Argumentations-Ansatz aus 9.2.2010 ..................................................................193. Argumentations-Ansatz aus 4.3.2010 ..................................................................19

VI. Was ändert sich für die Diskussion um § 651 – Anwendung im Hinblick aufneue Methoden?.............................................................................................................19

1. Diskussion Software und Sachqualität .................................................................192. Thesen: ...................................................................................................................20

VII. Lösung: Planungsanteil, Gemischter Vertrag .......................................................201. Zwischenüberlegung ..............................................................................................202. Gemischte Verträge, Auswirkungen der Theorien dazu? ...................................203. „Vorschläge“, Alternativen.....................................................................................204. „Freigabe“ als Kompromiss für Spirale, Iteration, Teilabnahme … ...................22

Literaturhinweise ............................................................................................................23

3

VORWEG ThesenAls erkenntnisleitende Frage wird unterstellt: Bei welcher Argumentation bzw. Lösungvermeidet man am ehesten Widersprüche bzw. erzeugt die wenigsten Widersprüche oderzweifelhafte bis unbrauchbare Ergebnisse? Der folgende Reißverschluß-artig gedachteVortrag kombiniert die Agile- und die § 651-er Problematik.

These 1:Die drei BGH-Entscheidungen zwingen nicht, über § 651 BGB Kaufrecht auf die Erstellungund Anpassung von Software anzuwenden.Die Entscheidung des OLG München würde allerdings dazu führen, § 651 BGB strikt nichtanzuwenden mit einer Begründung, die zu unbrauchbaren Verjährungsregelungen führt,zumindest, was AGB des Auftragnehmers betrifft:

Bei Ablehnung der Sachqualität und Anwendung Wv-Recht kommt § 634a Abs. 1 Nr. 1 nichtmehr als Verjährungsregelung in Betracht (im Verbund mit § 634a Abs. 2 Verjährung vonzwei Jahren beginnend mit der Abnahme). D.h., dass zwar eine Abnahme durchauserforderlich ist, diese jedoch nicht für die Verjährung maßgeblich ist. Vielmehr gilt dieregelmäßige Verjährungsfrist und diese beginnt nicht mit Abnahme, sondern nach denallgemeinen Regeln. Dieses Ergebnis erscheint dann nicht umgehbar, v.a. nicht i.V.m. OLGMünchen.

Für Pflegeverträge, die bei Systemverträgen die Standardsoftware gegen Pauschale und dieangepassten Teile gegen Aufwand (oder auch gegen Pauschale) zum Gegenstand haben,wird noch fragwürdiger, ab wann eine Vergütung bzw. die volle Vergütung verlangt werdenkann.

These 2:Die "modernen" Vorgehensmodelle unterlaufen/konterkarieren die Argumentations-bemühungen für eine Rechtfertigung der Anwendung von § 631 ff. unter Hinweis auf den(hohen) und damit auch separierbaren bzw. darleg- und beweisbaren Planungsanteil. DieFrage ist, was überhaupt von diesem Planungsanteil bleibt.

These 3:Die Verneinung der Sachqualität ist nicht europarechtskonform und schafft zusätzlicheProbleme bei „Lizenz“, weil Mietrecht nicht anwendbar ist.

4

I. Moderne Projektmethoden1

1. Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping othersdo it. Through this work we have come to value2:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the leftmore.

2. Principles behind the Agile Manifesto

We follow these principles3:

1. Our highest priority is to satisfy the customer through early and continuousdelivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processesharness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple ofmonths, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout theproject.

5. Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the jobdone.

6. The most efficient and effective method of conveying information to and within adevelopment team is face-to-face conversation.

7. Working software is the primary measure of progress.

1 Aus Skript des Autors für Tagung Kölner Tage 2010; übrige Abschnitte z.T. Erweiterung Vortrag Kölner Tage2010.2 http://agilemanifesto.org/; Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungenhinzugefügt .3 http://agilemanifesto.org/principles.html; Typo und Absatz-Anordnung geändert, Nr.und Hervorhebungen hinzugefügt

5

8. Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constantpace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizingteams.

12. At regular intervals, the team reflects on how to become more effective, thentunes and adjusts its behavior accordingly.

Xtreme Programming

Ruby on rails u.ä.

3. SCRUMScrum (engl. für Gedränge) ist ein Vorgehensmodell mit- Meetings,- Artefakten,- Rollen,- Werten und- Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agilerSoftwareentwicklung hilfreich ist. Teammitglieder organisieren ihre Arbeit weitgehend selbstund wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden. .......4

Oder:5Scrum is an iterative, incremental framework for developing any product or managing anywork. It allows teams to deliver a potentially shippable set of functionality every iteration,providing the agility needed to respond to rapidly changing requirements.The Scrum framework constantly challenges its users to focus on improvement, and itssprints provide the stability to address the ever-changing needs that occur in any project.These characteristics have led to Scrum becoming the most popular method in the world ofagile software development.

Rollen:

- Product Owner- Team- Scrum Master- Zusammenspiel- Zertifizierung

Artefakte:

4 http://de.wikipedia.org/wiki/Scrum ; s.a. http://scrum-master.de/;5 http://www.scrumalliance.org/; s.a. Auer-Reinsdorff, ITRB 2010, i.E.,

6

- Product Backlog - Sprint Backlog - Burndown Chart, (täglich) aktualisiert der je Sprint noch zu erbringende Aufwand - Impediment Backlog

Zyklusmodell

- Sprint – Umsetzung eines Iterationsschritts- Review- Retrospektive

Der Prozess:

- Product Backlog (Produktanforderung des Kunden >- Sprint backlog >

- Sprint >- Working Increment.

4. Prototyping

Die typischen moderneren Projektmethoden, charakterisiert etwa als Agile Programmingoder Extreme Programming haben als eine Art Vorläufer das Prototyping.6 DasInteressante dabei ist und damit auch das Vergleichbare mit den moderneren Methoden,dass dem Kunden in einem relativ frühen Stadium ein in bestimmtenKernfunktionalitäten bereits vorhandenes Programm gezeigt werden kann, auch wenndas Programm vielleicht noch nicht alle Funktionen aufweist, die es später,möglicherweise auch auf den Kunden zugeschnitten, benötigt und aufweisen soll.

Allerdings gibt es wohl auch Prototypen, die die Funktionalität noch nicht echt aufwei-sen, die also auch noch nicht mit z.B. Vorführdaten arbeiten können, hier handelt essich dann um einen sogenannten Demonstrationsprototypen.7

Arten von Softwareprototypen:

- Demonstrationsprototyp- Prototyp im engeren Sinne- Prototyp als Entwurfsmuster- Horizontaler Prototyp- Vertikaler Prototyp

_____________________________________________________________

Arten des Prototyping:

- Exploratives Prototyping- Evolutionäres Prototyping- Experimentelles Prototyping- Rapid Controll Prototyping- Vertikales Prototyping- Horizontales Prototyping

6 S. z.B: Söbbing, ITRB 2008, 145; Müller-Hengstenberg/Kirn, CR 2010, 8.7 S. zu den Arten von Prototypen bei Software und überhaupt zu Arten des Prototyping: Müller-Hengstenberg/Kirn, CR 2010, 8 und 9.

7

Das Prototyping ist insofern für die hier zu behandelnden Fragen von Interesse, als dieFolgend der neuen Projektmethoden bezüglich Dokumentation, spiralförmigen Vorgehensu.ä. vergleichbar sind, während die Voraussetzungen durchaus verschieden sind, indemnämlich beim Prototyp etwas im Kern funktionsfähiges vorliegt, zumindest vorliegensollte.

5. V-ModellDas V-Modell XT ist seit dem 1. Februar 2009 in der Version 1.3 erhältlich. Das V-Modell XT hat seit dem letzten Release nur wenige inhaltliche Änderungen erfahren,darunter die maßgebliche Überarbeitung des Vorgehensbausteins zurSystemsicherheit. Das V-Modell XT orientiert sich nun stärker an den Empfehlungendes Bundesamtes für Sicherheit in der Informationstechnik (BSI).

Darüber hinaus ist jedoch viel 'unter der Haube' geschehen. DieWerkzeugunterstützung durch den Projektassistenten wurde in vielerlei Hinsichtüberarbeitet, um eine bessere Tailorbarkeit und Planbarkeit zu erreichen. Die beliebtenExport-Funktionen wurden um weitere Dateiformate erweitert: DOC und ODT fürProduktvorlagen, MS Project XML für Pläne. Für den Anwender unsichtbar wurde einVariantenkonzept realisiert, mit dem Anpassungen des Vorgehensmodells anorganisationsspezifische Besonderheiten werkzeuggestützt durchgeführt werdenkönnen.

Zum V-Modell und dessen Struktur: www.cio.bund.de,

http://www.cio.bund.de/cln_155/DE/IT-Methoden/V-Modell_XT/v-modell_xt_node.html

8

II. Typische Merkmale moderner Projektmethodik, v.a. bei ExtremeProgramming

1. Versuch Schema zu Extreme ProgrammingZu den Zielen von Agile Programming: Manifesto for Agile Software Development undPrinciples behind the Agile Manifesto8, s. oben Zitat

Es folgt der Versuch einer Zusammenfassung der Charakteristika „moderner“ Projektmethoden undihrer Wirkung im Verbund mit Stichworten zur vertragsrechtlichen Beurteilung, orientiert an ExtremeProgramming:

Sarre/Schmidt 9

CharakteristikaBisherigeInstitution

Urteile Anm./Fragen

1. Die Funktionalität desSystems wird inUsers Stories10

zusammengefasst(GUI,Funktionalitäten,Testfälle und -szenarien),= lfd.Grobspezifikation„Wünschdirwas“ +Redaktion

„Pflichtenheft“entfällt als corpusmit einheitlichemVersionsstandderFeinspezifikation,das Vorgehenähnelt aberZurufprojekt undFall mitfehlendemPflichtenheft

BGH zum mittlerenAusführungsstandard11 und zurAusführungsart12,

Worauf beruhtKalkulation?13

Initial GUI als Ober-flächenbeschreibung,Funktionalitäten,Testszenarien,laufenderVerfeinerung erstspäter

2. SW-QualitätQualitätssicherung,

Sache desAuftragnehmers

„MittlererAusführungsstandard“14

In klassischenVerträgen im Vertragnicht geregelt, wirderst bei Abnahme(frühestens) geprüft

2.a Jeweils zweiEntwicklerprogrammierengemeinsam(„programming inpairs“)

DienstvertragaufgrundgemeinsamerEntwicklung derVorgaben undderErgebnisse?15

Absicherung, v.a.wenn 2. EntwicklerMitarbeiter des AGist.

Nutzungsrechtestehen beidenVertragspartner(gemeinsam) zu.16

2.b Gemeinsamer Code-Besitz (collectivecode ownership)

Quellcode fürAG?

BGH v. 16.12.2003zu Umständen einerHerausgabepflicht

Wenn nicht beideVertragspartner einExemplar des Codehaben, sollte er zuGunsten beider,also 2- fach,hinterlegt werden

2.c StändigeRefaktorisierung

Qualitätssicherung,Konfigurationsfähig

8 www.agilemanifesto.org; vom Verfasser auch auf Kölner Tagen 2010 angesprochen, ebenso das folgendeSchema9 Linke Spalte stammt – ohne Verweise - aus Vortrag Sarre/Schmidt, Folie 8: Wesentliche Merkmale, Habel IT-Gesprächskreis, München 19.11.2009, erweitert für Tagung Kölner Tage 201010 S. z.B. Mike Cohn, User Stories Applied: For Agile Software Development, 200411 BGH v. 16.12.2003 - X ZR 129/01, CR 2004, 490.12 S. oben BGH v. 13.6.2006 – X ZR 167/04,13 Wichtig für Risikoverteilung bei Änderung der Ausführungsart, s. BGH v. 16.7.1998, NJW 1998, 370714 BGH 16.12.2003 - X ZR 129/01, CR 2004, 490.15 S. eher abl. Schneider Handbuch des EDV-Rechts, 4. Aufl. 2009, H. Rz. 7 f.16 S. a. zum Problem OLG Frankfurt v. 17.9.2002, CR 2003, 50.

9

(continuousrefactoring)17

-keit wird verbessert

2.d Schnelle Code-Reviews (rapid codereviews)

AktuelleBerücksichtigungvon Korrektur-Bedarf

3. Vor der Entwicklungwerden(automatisierbare)Tests erstellt, > Nr. 1= Teil der Vorgaben,es wird festgelegt,wie getestet wird,ermöglicht, dass sichdie Entw. derTestfälle bedienenkönnen

Bisher Testsnachträglich„proof of ...“? mitAusstiegsszenarien undAnschärfen derFolgen je nachabsolvierterPhase

Vor Abnahme istAuftragnehmer fürMangelfreiheitverantwortlich undBeweis-belastet, evtl.>>>Machbarkeit und>>Zwischenabnahme, Freigabe fürweiteres Vorgehen?

4. Auf unnötigeFeatures wirdverzichtet (YAGNI -you aren‘t gonnaneed it)

CR -Management

OLG Düsseldorf v.10.6.1992, Gitteroste(Deltapflichtenheftreicht nicht);OLG Köln v.6.3.1998, CR 1998,459 proaktiver AN

BGH 16.12.2003,„MittlererAusführungsstandard“ revidieren, mehrauf Vertragszweckabstellen

5. Kunde ist bei dergesamtenEntwicklung dabei(„on-site customer“),

Realisierung istSache des AN,AG ist nichtverpflichtet, dieAusführungsartdes AN zu prüfen(BGH v.13.6.2006 - X ZR167/04 , s.a.BGH zuFunktionsmangel

Mitwirkung alsHauptleistung?,Kooperationsvertrag

Wem „gehören“ dieErgebnisse?

6. Extrem kurze Zyklenfür („Schraube“)Anforderungsanalyse, Design,Implementierungund Test. DasErgebnis pro Zyklusist immer einlauffähigesProgramm („smallreleases“).

Keine Pflichtdes AN zuprüfung derAusführungsartund zuTeilabnahmen

Freigaben,Teilabnahmen,Gesamtabnahme

7. Insgesamt entstehtkeine oder nur sehrwenig Dokumentationseitens AN

Bedienungs-Handbücher(+Installationsanleitung)

BGH v. 22.12.1999OLG Karlsruhe v.16.8.2002, CR 2002,802; BGH v.20.2.2001- X ZR 9/99

8. Resumee /Frage BGH 23.7.2009,BGH 9.2.2010 undBGH 4.3.2010, ./.OLG München23.12.2009

Obwohl „Planung“verschwindet, passt651 nicht (?).

17 S. z.B. Martin Fowler u.a., Refactoring: Improving the Design of Existing Code, 1999

10

2. Projektverträge in der Rspr., BGB a.F. - Werkvertrag

(Übersicht, Auflistung, BGB a.F., weggelassen)

3. Abgleich Projektvorgehensmodelle und Rspr. Positionen

a) Planungsphase

Der Schwerpunkt zumindest des Projektvertrages wird, auch wenn andereLeistungen hinzutreten, durch die „Erstellung“ der Software geprägt. Der Vertragenthält unter Umständen noch die Erstellung der fachlichen Vorgaben (Gewinnungdes „Pflichtenhefts“) und zerteilt sich insofern grob in die Phasen

- Planung und- Realisierung.

Das Argument für die Nichtanwendung ist gerade die beinhaltete, aber vor dieRealisierung („Herstellung“) geschaltete Planung.

Im Hinblick auf § 651 BGB wäre andererseits wichtig, den Hardwareanteil zuberücksichtigen bzw. ins Verhältnis zu setzen. Systemverträge müssten demnacheher nach Kaufrecht beurteilt werden.18 Entsprechendes gilt für die „Services“, alsoInstallation, Einrichten, Einführungsunterstützung usw., wenn sie nichteigenständigen Charakter haben.

b) Erfolgsverantwortung beim AN

Die typische vertragstyplogische Einordnung des „klassischen“ Projekts istWerkvertrag und zwar wohl in der Regel ungeachtet der Anteile der Hardware. AlsErfolg wird die Erstellung des betriebsfertigen Systems („schlüsselfertig“) gesehen.

Die Projektverantwortung folgt selbstverständlich aus der Erfolgsverantwortungseitens des Auftragnehmers und somit verbleibt nur Mitwirkungsleistung desAuftraggebers. Ist der Erfolg nicht in einem Pflichtenheft definiert, gilt ein mittlererAusführungsstandard nach Stand der Technik und orientiert amVertragszweck19.

c) Pflichtenheft

Die Beibringung des Pflichtenhefts als fachliche Anforderungen ist Sache desAuftraggebers. Dies gehört zu seinen genuinen Mitwirkungspflichten.20

“Kann der Softwarehersteller die Verpflichtung zur Programmierung nur sinnvoll unterMitwirkung des Kunden erfüllen, so besteht aus in der Natur der Sache liegenden

18 BGH v. 23.7.2009 a.a.O., anders gerade die EVB-IT System.19 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490.20 BGH v. 13.7.1988, CR 1989, 102 – Registierkassen – und BGH v. 23.1.1986, CR 1996, 467 –Service-RZ II –.

11

Gründen, auch ohne ausdrückliche Regelung, eine entsprechendeMitwirkungspflicht.”21

Unmittelbar auch heute noch passend für diese Entscheidung, v.a. 13.07.1988,hinsichtlich der Parametrierung, da es um das Ausfüllen von „Programmblättern“bzw. die Spezifikation von Warengruppe, Preis und einer Kurzbeschreibung derWare ging. Man könnte dies auf heutigeVerhältnisse also als Kurzbeschreibung des Produkts bzw. des Geschäftsprozessesansehen.

Gemäß diesen Entscheidungen bedarf es nicht einmal einer expliziten Regelung derMitwirkungspflichten im Vertrag, obwohl dies sicher empfehlenswert ist (auch imRahmen des Aktivitäten- und Fristenplans).

d) Dokumentation(en)Möglicher Umfang, Katalog der Dokumenationen-

Anwenderdokumentation (nur dazu hat der BGH entschieden). - Installationsbeschreibung (ergibt sich aus den BGH-E.)

- 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 Pflege-Dokumentation.

Zur systematisch geführten Softwareentwicklungsdokumentation gehören22:- Fachkonzept,- DV-Feinspezifikation,- Quellprogramme mit zugehöriger Dokumentation,- Datenbank-Modelle- Beschreibung der Testverfahren,- Testdokumentation,- Beschreibung der Abnahmeverfahren,- Abnahmeprotokolle,- Softwaredokumentation (System- und Anwenderhandbuch),- Darstellung des Vorgehensmodells bei der Entwicklung,- Dokumentation der Entwicklungsumgebung.23

Die modernen Projektmethoden sind auch dadurch gekennzeichnet, dass es – zumindestnach Auffassung der Anbieter –- entweder keine Dokumentation gibt, oder- die "Dokumentation" vom Anwender selbst (mit-) erstellt wird (s.a. II.1).Sehr wohl kann sich aber aus dem Vertrag anderes ergeben.

21 BGH v. 13.7.1988, CR 1989, 102, 104 (LS 2) – Registrierkassen – und Bestätigung durch BGH v.10.3.1998, CR 1998, 393, 395 – Warentermingeschäft.22 Hoppen/Hoppen, Bewertung und Bilanzierung selbst erstellter Software, CR 2009, 761, 766 mit Auflistung was zurSoftwareentwicklungsdokumentation gehört.23 Zusätzlich nennen Hoppen/Hoppen, CR 2009, 761, noch, aber wichtig wohl nur für die Bewertung:Aufstellung der beteiligten Mitarbeiter mit Aufgaben und angefallenem Entwicklungsaufwand.

12

Anm./These: Stories, Cases sind zwar Anforderungen/Forderungen, jedoch kein„Pflichtenheft“, auch keine Bestandteile, wenn sie nicht über die zuständigenInstanzen aufgegriffen und in den Design-/Entwicklungsprozess integriert werden;sie taugen auch später nicht als Basis für die Dokumentation, wenn sie nichtsystematisch aufbereitet und bearbeitet werden. Sie können aber zur näher zukonkretisierenden Leistungsbeschreibung, auch für Tests dienen. Die Relevanzergibt sich aus vertraglichen Regelungen.

Die Möglichkeit der Erstellung durch den Anwender erscheint hinsichtlich derEntwicklungsdokumentation äußerst fraglich. Des weiteren wird angenommen,jedenfalls von vielen Auftragnehmern, dass die Bedienungsanleitung Bestandteil derSoftware selbst wäre und zwar über die Onlinehilfe. Dies ist zwar insofern richtig, alses Tendenzen gibt, große Teile dessen, was früher in der Bedienungsanleitungstand, in die Onlinehilfen zu verlagern. Dies enthebt jedoch nicht insgesamt derNotwendigkeit einer Benutzerdokumentation zumindest in einer grundsätzlichenDarstellungsform. Dabei ist wenig relevant, ob es sich um eine ausdruckbare oderausgedruckte Fassung handelt.

Vielmehr ist zu beachten, dass mindestens die Installationsanleitung und ein gewis-ser Kern von Anweisungen in schriftlicher Form so vorliegt, dass der Kunde damitauch dann umgehen kann, wenn er evtl. erneut die Software zu installieren bzw. zumAnlaufen zu bringen hat bzw. wenn er sich selbst ansonsten helfen soll.

Im klassischen Projekt ist eine in der Praxis häufig diskutierte Frage, die aber selten(offensichtlich) zu Gericht kommt, wie genau die Dokumentation auszusehen hat undwann sie im einzelnen zu erstellen ist.

Hypothese: Ist die Frequenz der Änderungsverlangen nicht hoch und sind dieÄnderungsverlangen nicht gravierend, dürfte ökonomisch gesehen eineprojektsynchrone bzw. leicht zeitversetzte Erstellung der Entwicklungsdokumentationeinschließlich auch der Anwendungsdokumentation einfacher und damitkostengünstiger sein. Bei höherer Änderungsrate und bei tiefergreifendenÄnderungen dürfte eine Erstellung der Dokumentation im nachhinein diekostengünstigere sei. Der BGH hat diese Überlegungen nicht so angestellt, abervielleicht indirekt berücksichtigt. Jedenfalls gehört zum typischen Projekt zum eineneine gewisse Änderungsrate und zum anderen ist die Dokumentation erst fällig, wennnach einer angemessenen Frist (die bei einer evtl. Fristsetzung nach altem Recht imRahmen von § 326 zu berücksichtigen war) nach Ende der Fertigstellung incl. derAbarbeitung der Änderungsverlangen der Auftragnehmer noch genügend Zeit hat,die Dokumentation zu erstellen.

Daraus ließe sich auch ein Modell rekonstruieren, wie ein Zeitplan für einenProjektvertrag aussehen könnte, in dem es einen Zeitpunkt gibt, der als relativerTermin das Ende der Änderungswünsche und deren Realisierung markiert, ab demdann die vereinbarte Frist für die Erstellung der Dokumentation läuft. Diese Fristmüsste evtl. noch angepasst werden, wenn durch die Änderungswünsche einerheblicher Mehraufwand auch bei der Dokumentation (wegen Erweiterung derFunktionalitäten usw.) entstehen würde.

Der Katalog der Dokumentationen ist offen. Im juristischen Bereich hat allerdingsbislang v.a. die Anwendungsdokumentation und allenfalls die Installationsanleitung

13

eine Rolle gespielt. Die weiteren Dokumentationen wären und sind wohl imwesentlichen Vereinbarungssache:

e) Änderungen, Üblichkeit und Häufigkeit

In mehreren Entscheidungen hat der BGH sinngemäß die Üblichkeit vonÄnderungsverlangen und deren Ausführung festgestellt.24

„Der Projektunternehmer hat für eine der vertragsgemäßen Software angepasste Auslegung derHardware einzustehen (also veraltet), „muss dabei auch ‚in gewissem Umfang’ möglichennachträglichen Änderungen und Ausweitungen der Programme Rechnung tragen. Die Grenzedes ‚gewissen Umfangs’ bemisst sich nach den zu erwartenden Mehrkosten, den Umfang, denZeitpunkt und der Wahrscheinlichkeit einer Programmerweiterung sowie den Möglichkeiten undSchwierigkeiten einer späteren Erweiterung.“25 LS 3

Indirekt bestätigt auch die Entscheidung vom 20.02.2001 die Üblichkeit vonÄnderungsverlangen und deren Ausführung (im Hinblick auf die Fälligkeit derSoftware-Dokumentation besonders relevant). 26

f) Zur Abnahme

Typisch für Projekte ist, dass der Abnahmeerklärung eine ausführliche Erprobungzwecks Feststellung der Abnahmefähigkeit vorausgeht. Ausführliche Verträge regelnin einer Reihe von Phasen den schrittweisen Übergang bis hin zum Probebetrieb alsAbnahmetest einschließlich einer gewissen fehlerfreien Zeit. Soweit schon vorherAbnahmen vorgesehen sind, wird in der Regel eine Gesamtabnahme vereinbart, diemöglicherweise einen eingeschränkten Gegenstand hat, etwa noch Performance,während die Funktionalität der einzelnen Module bereits vorher getestet wäre, nunaber noch die Gesamtfunktionalität ansteht, also die Interoperabilität innerhalb desSystems u.ä.. Als typisch für die Verbindung mit Outsourcing bzw. überhaupt fürOutsourcingverträge ist die Regelung auch der Phase nach der Abnahme, etwa imSinne einer Anlauf-/Einarbeitungsphase incl. „“Einschwingen“ hinsichtlich der Skillsauf Seiten des Auftragnehmers. Dies gilt insbesondere, wenn nicht das selbePersonal, das das Projekt betrieben hat, für den Betrieb verantwortlich wird.

g) Rechtzeitiger Abruf als Voraussetzung für Mitwirkungsverzug

Wie erwähnt, ist der Auftraggeber generell zur Mitwirkung verpflichtet, auch wennkeine besonderen Regelungen hierfür im Vertrag zu finden sind. Allerdings empfiehltes sich natürlich, diese Mitwirkung im einzelnen zu regeln.Dies betrifft z.B. auch den Bereich der Abnahme, also, wer der Testsystem stellt,wann die Testcases/Szenarien zu liefern sind, welche Verbindlichkeit diese bzw. dieErgebnisse haben u.ä. Evtl. enthält der Vertrag noch Regelungen, dass dieMitwirkung rechtzeitig abzurufen ist. Damit ist die Schwäche der gesetzlichen

24 S. als Beispiel zu kurzer Fristsetzung i.V.m. den Änderungs- und Ergänzungsarbeiten BGH v23.6.1992 – X ZR 92/90, CR 1993, 424. Noch deutlicher: BGH v. 24. 6.1986 – X ZR 16/85, CR 1986,977 – Reservekapazität im Hardware-Mengengerüst (soweit auf Hardware bezogen wohl veraltet).25 BGH v. 24. 6.1986 – X ZR 16/85, CR 1986, 977, LS 326 BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367.

14

Regelung der Mitwirkung nicht kompensiert, dass es sich insoweit nicht umHauptpflichten handelt. Dies dürfte sich auch nach Schuldrechtsmodernisierung nichtanders darstellen. Umso wichtiger wäre die exakte Regelung möglichst vielerMitwirkungspflichten im Rahmen des Aktivitäten- und Fristenplans.

III. BGH – intervenierende Variable über § 651 BGB?

1. BGH v. 23.7.2009 – Silowände

BGH, Urteil vom 23. Juli 2009 - VII ZR 151/08 - OLG Nürnberg LG Weiden i.d. OPf.

a) Kaufrecht ist auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzu-stellender oder zu erzeugender beweglicher Sachen anzuwenden, also auch aufVerträge zwischen Unternehmern.b) Verträge, die allein die Lieferung von herzustellenden beweglichen Bau- oder An-lagenteilen zum Gegenstand haben, sind nach Maßgabe des § 651 BGB nachKaufrecht zu beurteilen. Die Zweckbestimmung der Teile, in Bauwerke eingebaut zuwerden, rechtfertigt keine andere Beurteilung.c) Eine andere Beurteilung ist auch dann nicht gerechtfertigt, wenn Gegenstand desVertrages auch Planungsleistungen sind, die der Herstellung der Bau- undAnlagenteile vorauszugehen haben und nicht den Schwerpunkt des Vertrages bilden.

Rz. 16 c) Allerdings hat die Anknüpfung an den Begriff der beweglichen Sache in der Literatur erheblicheKritik erfahren, soweit sie sich auf Verträge im Zusammenhang mit der Errichtung von Bauwerken auswirkt.....Diese Kritik vermag nichts daran zu ändern, dass der Wille des Gesetzgebers eindeutig dahin geht, diejenigenWerklieferungsverträge, die nach altem Recht noch dem Werkvertragsrecht unterstellt waren, nunmehr alsKaufverträge einzuordnen, was auch mit einer Angleichung an das UN-Kaufrecht begründet worden ist (BT-Drucks. 14/6040, S. 268). Dieser Wille ist durch die unmissverständliche Formulierung des Gesetzesausreichend zum Ausdruck gekommen. Das Gesetz kann nicht unter Hinweis darauf umgangen werden, dassdie alte Rechtslage vermeintlich zu angemessenen Ergebnissen geführt hat (so auch Messerschmidt/Voit-Messerschmidt/Leidig, aaO, Rdn. 28).

Rz. 17 Zu Recht wird darauf hingewiesen, dass die von der Literatur angeführten Wertungswidersprüchesystematisch in der Regelung des § 651 Satz 1 BGB angelegt sind (Rudolph, aaO). Es mag alsWertungswiderspruch empfunden werden, dass ein Vertrag mit demjenigen, der die Errichtung des Bauwerksschuldet und dazu die Bauteile herstellt und anliefert, nach Werkvertragsrecht zu beurteilen ist, während einVertrag mit demjenigen, der die Bauteile herstellt und lediglich anliefert, grundsätzlich nach Kaufrecht zubeurteilen ist. Dieser vermeintliche Wertungswiderspruch ist jedoch allgemein in § 651 BGB angelegt, weil dieAnwendung von Kaufrecht auf im Kern erfolgsbezogene Verträge angeordnet und vom Gesetzgeber in derMeinung akzeptiert worden ist, Kauf- und Werkvertragsrecht unterschieden sich nicht wesentlich. Das ....

Rz. 20 20Dem Gesetz kann keine Beschränkung derart entnommen werden, dass lediglich Verträge über die Lieferung vontypischen Massengütern oder zum Verbrauch bestimmten Gütern erfasst sein sollten (so aber Erman/Schwenker,BGB, 12. Aufl., § 651 Rdn. 5). Der Wortlaut des § 651 BGB und die dargestell-ten Motive geben dafür nichtsher. Die Beschränkung lässt sich auch nicht aus einer autonomen Auslegung der Verbrauchsgüterkaufrichtlinieentnehmen, die für die Auslegung des Gesetzes bei einer Lieferung an einen Verbraucher zu berücksichtigenwäre. Die Verbrauchsgüterkaufrichtlinie findet allerdings nur auf Verträge Anwendung, die die Lieferungherzustellender oder zu erzeugender Verbrauchsgüter an Verbraucher zum Gegenstand haben. Daraus ergibtsich jedoch ausweislich der Richtlinie keine Einschränkung der dargestellten Art. Denn Verbrauchsgüter sindgemäß Art. 1 Abs. 2 lit. b) der Richtlinie bewegliche körperliche Gegenstände mit Ausnahme der dort benannten

15

Gegenstände. Eine weitere Einschränkung enthält die Legaldefinition der Richtlinie nicht. Sie ergibt sich auchnicht aus dem Verfahren zur Richtlinie (vgl. Rudolph, aaO, S. 67). Insbesondere liegt kein Anhaltspunkt dafürvor, dass die schwierige Abgren-zung von typischen Massengeschäften oder zum Verbrauch bestimmten Güternvon anderen Gütern in irgendeiner Weise durch die Richtlinie eröffnet sein soll-

21 Von dem Anwendungsbereich des Werkvertragsrechts erfasst bleiben damit ausweislich derBegründung zum Entwurf des Gesetzes zur Modernisierung des Schuldrechts im Wesentlichen dieHerstellung von Bauwerken, reine Reparaturarbeiten und die Herstellung nicht-körperlicher Werke,wie zum Beispiel die Planung von Architekten oder die Erstellung von Gutachten (BT-Drucks. 14/6040,S. 268).

b) Das alles stellt das Berufungsgericht nicht in Frage. Es meint vielmehr auf der Grundlageeiner in der Literatur vertretenen Meinung zur Einordnung von Verträgen zwischen Unternehmern überdie Lieferung eines herzustellen-den typischen Investitionsgutes Werkvertragsrecht anwenden zumüssen. In der Literatur wird geltend gemacht, § 651 BGB sei nicht anzuwenden, wenn der Vertragzwischen Unternehmern über die Lieferung eines herzustellenden typi-schen Investitionsgutes anderezusätzliche wesentliche Leistungen enthalte, zu denen etwa Planungs-, Konstruktions-, Integrations-und Anpassungsleistungen gezählt werden. Dabei sind vor allem Leistungen im Zusammenhang mitder Lieferung von in den Produktionsprozess einzupassenden Maschinen oder Industrieanlagen oderProjektverträge im Mittelpunkt der Diskussion (vgl. Leistner, JA 2007, 81, 88; Metzger, AcP 204(2004), 231, 232 f.; Schumann, ZGS 2005, 250; Bamberger/Roth/Voit, BGB, 2. Aufl., § 651 Rdn. 12;Lapp in jurisPK-BGB, 3. Aufl., § 651 Rdn. 1). Seien diese Leistungen für den Gesamterfolg desVertrages von wesentlicher Bedeutung, bildeten sie den Schwerpunkt des Vertrages (MünchKomm-Busche, BGB, 5. Aufl., § 651 Rdn. 31) oder gäben ihm das Gepräge (Palandt/Sprau, BGB, 68. Aufl., §651 Rdn. 4), so sei Werk-vertragsrecht anwendbar. Werkvertragsrecht sei auch dann anwendbar,wenn ein Prototyp einer Maschine entwickelt werde, weil die dafür erforderliche geistige Leistung denSchwerpunkt des Vertrages bilde, während die Maschine selbst nur das Substrat dieser Leistung sei(Staudinger/Peters/Jacoby (2008), § 651 Rdn. 8, 16; Palandt/Sprau, aaO).

23 b) Der Senat muss nicht entscheiden, ob in den dargestellten Fällen § 651 BGB nicht anwendbar ist. Dennein solcher Fall liegt entgegen der Auffassung des Berufungsgerichts nicht vor.

24 Allerdings geht auch der Senat davon aus, dass die Beklagte im vom Berufungsgericht festgestellten UmfangPlanungsleistungen übernommen hat. Die dagegen gerichteten Verfahrensrügen der Klägerin hat er geprüft,jedoch nicht für durchgreifend erachtet, § 564 Satz 1 ZPO.

25 Jedoch sind die Leistungen der Beklagten nicht von solchem Gewicht, dass die Anwendung desWerkvertragsrechts gerechtfertigt wäre. Das Berufungsgericht verkennt die Bedeutung der Planungsleistung imAnwendungsbereich des § 651 BGB. Danach können solche Planungsleistungen, die als Vor stufe zu der im Mittelpunkt des Vertrages stehenden Lieferung herzustellender Anlagenteile anzusehen sind, derBeurteilung des Vertrages nach den Vorschriften über den Kauf regelmäßig nicht entgegenstehen. Wäre esanders, würde die Vorschrift des § 651 BGB weitgehend leer laufen, denn jeder Herstellung gehteine gewisse Planungsleistung voraus (Messerschmidt/Voit-Messerschmidt/Leidig, aaO, § 651 Rdn. 49; Motzke,in Bauträger-, Bau- und Maklervertrag in der Praxis der Wohnungsunternehmen und Immobilienverwaltungen,S. 22). Eine Ausnahme kann deshalb allenfalls dann gelten, wenn die Planungsleistung so dominiert, dass sieden Schwerpunkt des Vertrages bildet und deshalb die Anwendung des Werkvertragsrechts erfordert. Das kannz.B. dann der Fall sein, wenn es bei der Beauftragung im Wesentlichen um die allgemein planerische Lösungeines konstruktiven Problems geht.

Für IT-Rechts-Zwecke relevant sind die Aussagen zua) Generelle Anwendung § 651 BGB , auch B:B.b) Keine teleologische Begrenzung bzw. Auslegung. c) Beachtlichkeit des Planungsanteils27. Allerdings genügt nicht, dass der Unternehmer

als Vorstufe planerisch tätig wird: „Danach können solche Planungsleistungen, die als Vorstufe zu derim Mittelpunkt des Vertrages stehenden Lieferung herzustellender Anlagenteile anzusehen sind, der Beurteilung

27 Wobei noch zusätzlich zu berücksichtigen wäre: BGH v. 8.10.2009 – III ZR 93/09 – Video-Partnerportal –(dort Hauptleistung Betrieb) zur Beurteilung gemischter Verträge. S. aber eher noch restriktiver zur Relevanzdes Planungsanteils: BGH 9.2.2010, sogleich.

16

des Vertrages nach den Vorschriften über den Kauf regelmäßig nicht entgegenstehen. Wäre es anders, würde dieVorschrift des § 651 BGB weitgehend leer laufen, denn jeder Herstellung geht eine gewisse Planungsleistungvoraus ... (mwN).“, Rz. 25.

2. BGH v. 9.2.2010 - Tiefladesattelaufleger

BGH v. 9.2.2010 – X ZR 82/07 - Tiefladesattelauflieger

Leitsatze Stephan Lorenz:a) Kaufrecht ist auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zuerzeugender beweglicher Sachen anzuwenden, auch wenn mit der Herstellung eine Planungsleistung verbundenist (Bestätigung von BGH NJW 2009, 2877)b) § 377 HGB ist auch auf Werklieferungsverträge anwendbarc) Die Beweislast für das Vorliegen einer Beschaffenheitsvereinbarung im Rahmen des subjektivenFehlerbegriffs trägt der Käufer (§ 434 I S. 1 BGB)

Kommentar SL: ... Kernaussage: Ein Vertrag über herzustellende Sachen ist nach § 651 BGB auch danndem Kaufrecht zugewiesen, wenn mit der Herstellung eine gewisse Planungs- und Konzeptionsarbeit verbundenist. Argument: Der Herstellung von zu liefernden Sachen gehen typischerweise gewisse Planungsleistungenvoraus und die Vorschrift des § 651 BGB würde weitgehend leer laufen, wenn dieser Umstand dazu führte, stattKaufrecht Werkvertragsrecht anzuwenden. Offen bleibt weiter, ob dann Werkvertrag anzunehmen ist, wenn diePlanungsleistung überwiegt.

BGH 9.2.2010:Rz. 7 II. Das hält der rechtlichen Nachprüfung nicht stand.Rz. 8 1. a) Die Einordnung des geschlossenen Vertrages als Werkvertrag ist rechtsfehlerhaft. Nach § 651 Satz 1BGB finden auf einen Vertrag, der, wie hier, die Lieferung herzustellender oder zu erzeugender beweglicherSachen zum Gegenstand hat, die Vorschriften über den Kauf Anwendung. Werkvertrags-rechtlicheBestimmungen treten nur ergänzend, und nicht verdrängend neben das Kaufrecht, wenn der Vertrag dieLieferung einer nicht vertretbaren Sache zum Gegenstand hat (§ 651 Satz 3 BGB). Kaufrecht ist mithin aufsämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender beweglicherSachen anzuwenden (BGH, Urt. v. 23.7.2009 - VII ZR 151/08, zur Veröffentlichung in BGHZ vorgesehen, Tz. 19unter Hinweis auf BT-Drucks. 14/6040, S. 268). Unerheblich für die vertragsrechtliche Einordnung ist entgegender Auffassung des Berufungsgerichts deshalb, dass der Auflieger nach den konkreten Vorstellungen undVorgaben der Klägerin habe hergestellt werden sollen. Das mag die Annahme rechtfertigen, der Vertrag habedie Lieferung einer nicht vertretbaren Sache zum Gegenstand gehabt. Dies ändert ausweislich der gesetzlichenRegelung in § 651 Satz 3 BGB aber nichts an der grundsätzlichen Anwendbarkeit von Kaufrecht (vgl. insoweitauch BGH, aaO Tz. 18 ff.).

Rz. 9 b) Ob ausnahmsweise Werkvertragsrecht anwendbar sein könnte, wenn ein zwischen Unternehmengeschlossener Vertrag die Lieferung typischer Investitionsgüter, namentlich in den Produktionsprozesseinzupassender Maschinen oder Investitionsanlagen, und im Zusammenhang damit die Erbringung zusätzlicherwesentlicher Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten zum Gegenstand hat, bedarf imStreitfall keiner Entscheidung (vgl. insoweit auch BGH, aaO Tz. 22). Zwar kann davon ausgegangen werden,dass die Beklagte, um ihre Lieferungspflicht zu erfüllen, auch gewisse Planungs- oder Konstruktionsleistungenerbringen musste, worauf schon hindeutet, dass ihr vor Vertragsschluss die Dokumentation der Fräse W 1000 Fübergeben wurde. Soweit in den Gründen des angefochtenen Urteils insoweit davon die Rede ist, der Beklagtensei die technische Dokumentation des herzustellenden Sattelaufliegers übergeben worden, handelt es sichausweislich des Zusammenhangs der Entscheidungsgründe um ein Versehen. Bei den gegebenenfalls erbrachtenPlanungs- bzw. Konstruktionsleistungen kann es sich nach Lage des Streitfalls nur um solche gehandelt haben,die als Vorstufe zu der im Mittelpunkt des Vertrags stehenden Lieferung anzusehen sind. Der Herstellung von zuliefernden Sachen gehen typischerweise gewisse Planungsleistungen voraus und die Vorschrift des § 651 BGBwürde weitgehend leer laufen, wenn dieser Umstand dazu führte, statt Kaufrecht Werkvertragsrechtanzuwenden.

3. BGH v. 4. März 2010 - III ZR 79/09 Web-Design-Vertrag

17

Rz. 16 Die Qualifizierung des "Internet-System-Vertrags" als Werkvertrag im Sinne der §§ 631 ff BGB stehtim Einklang mit der Rechtsprechung des Bundesgerichtshofs zur Zuordnung von Internet-Verträgen zu denVertragstypen des Bürgerlichen Gesetzbuchs. Sie findet ihre maßgebliche Grundlage in dem von denParteien vereinbarten Vertragszweck, wie er in der vertraglichen Leistungsbeschreibung und dem hierananknüpfenden Parteiwillen, insbesondere auch in der verobjektivierten Kundenerwartung, zum Ausdruckkommt, und rechtfertigt sich letztlich auch aus einem Vergleich mit Verträgen, die ähnliche Gegenständebetreffen und als Werkverträge anerkannt sind.

Rz. 21 (d) Im "Webdesign-Vertrag" verpflichtet sich der Anbieter, für den Kunden eine individuelle Website zuerstellen. Ein solcher Vertrag dürfte - ebenso wie ein Vertrag über die Erstellung oder Bearbeitung einerspeziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software (s. BGHZ 102, 135, 140 f; BGH,Urteile vom 15. Mai 1990 - X ZR 128/88 - NJW 1990, 3008, vom 3. November 1992 - X ZR 83/90 - NJW1993, 1063, vom 9. Oktober 2001 - X ZR 58/00 - CR 2002, 93, 95 und vom 16. Dezember 2003 - X ZR129/01 - NJW-RR 2004, 782, 783) - regelmäßig als Werkvertrag im Sinne der §§ 631 ff BGB, unterUmständen auch als Werklieferungsvertrag im Sinne von § 651 BGB, anzusehen sein (s. dazu etwa BuscheaaO m.w.N.; Klett/Pohle aaO S. 201; Redeker aaO Rn. 980; Schneider, in: Handbuch des EDV-Rechts, 4.Aufl., Teil O Rz. 342 f = S. 2066; Schmidt, in: Spindler, Vertragsrecht der Internet-Provider, 2. Aufl., TeilVIII Rz. 4 = S. 659 ff; Cichon, Internet-Verträge, 2. Aufl., S. 117 ff; Härting, Internetrecht, 3. Aufl., Rn.334 ff = S. 83 ff).

Noch besonders zu erwähnen: RZ 26.

18

IV. OLG München v. 23.12.2009 „gegen“ BGH; Literaturhinweise

1. OLG München v. 23.12.2009 – 20 U 3515/09, CR 2010, 156 Ein Softwareentwicklungsvertrag ist Werkvertrag. „Dies gilt auch dann, wenn ein

Standardprogramm den individuellen Bedürfnissen des Anwenders angepasst wird (...MüKo BGB 5. Aufl. § 631, Rdnr. 254 m.w.N.“... Dem steht auch § 651 BGB nichtentgegen. „Selbst wenn man davon ausgeht, dass es sich bei dem Softwareprogrammum eine bewegliche Sache (Datenträger) handelt, besteht die eigentliche Leistung inder geistigen Schöpfung des Programms, und nicht in der Lieferung derherzustellenden beweglichen Sache. Darüber hinaus wurde die Individualsoftware perDatenfernübertragung übertragen, so dass auch von einer beweglichen Sache nichtausgegangen werden kann. ... Wie bereits ausgeführt, handelt es sich hier nicht umeinen Kaufvertrag, sodass die Entscheidung des BGH vom 23.7.2009 (NJW 2009,2877, Silowände) nicht einschlägig und vergleichbar ist.

2. Lit. Stellen zu Projektvertrag und § 651

- Palandt/Sprau, 69. Aufl., § 651 BGB Rz. 4 negiert trotz Zitat der E. deren Aussagenweitgehend: „Ein Werkvertrag fällt nicht unter § 651, wenn die Schöpfung einesGesamterfolges den Schwerpunkt ... bildet.“ Palandt/Sprau, 69. Aufl., Rz. 22 vor 631BGB: Programmierleistungen sind in der Regel Werkleistungen... § 651 ist in diesenFällen mangels Sacheigenschaft der Leistung nicht anwendbar.

- Anmerkung Schweinoch zu BGH v. 23. 7.2009, CR 2009, 637, 640;

- Schweinoch, Geänderte Vertragstypen in Softwareprojekten, CR 2010, 1.

- Anmerkung Hoffmann zu BGH vom 23.07.2009 in MMR 2009,

- Witte, Agiles Programmieren und § 651 BGB, ITRB 2010, 44;

- Maume/Wilser, Viel Lärm um nichts? Zur Anwendung des § 651 BGB auf IT-Verträge, CR 2010, 209

- Mankowski, CR 2010, 137 zu OLG München, Internationale Zuständigkeit, S. 138:- „Ob ein Softwareentwicklungsvertrag unter deutschem Recht ein Werkvertrag

wäre, spielt für die europäische Einordnung keinerlei Rolle.“ Und Fn. 9: „Diesübersieht OLG München …“.

- BGH v. 4.3.2010 – III ZR 79/09 Rz. 21 (d) Im "Webdesign-Vertrag" ..., s. oben

19

V. Argumentationen gegen § 651-Anwendung aus den BGH-Urteilen

1. Argumentations-Ansatz aus 23.7.2009:

Rz. 14 ... Verträge, die allein die Lieferung von herzustellenden Bau- oder Anlagenteilen zumGegenstand haben, sind gemäß § 651 BGB nach Kaufrecht zu beurteilen (Dauner-Lieb/Langen-Raab, Schuldrecht Teilband 2, § 651 Rdn. 14; Messerschmidt/Voit-Messerschmidt/Leidig, PrivatesBaurecht, § 651 Rdn. 28; Leupertz, BauR 2006, 1648 f.; Voit, BauR 2009, 369, 370). Inwieweitetwas anderes gilt, wenn der Lieferant eine Verpflichtung zum Einbau der Teile in ein Bauwerkeingegangen ist oder die Teile selbst nach den von der Rechtsprechung aufgestellten Kriterien alsBauwerk zu beurteilen sind, ist hier nicht zu klären.

Rz. 17 (oben) Es mag als Wertungswiderspruch empfunden werden, dass einVertrag mit demjenigen, der die Errichtung des Bauwerks schuldet und dazudie Bauteile herstellt und anliefert, nach Werkvertragsrecht zu beurteilen ist,während ein Vertrag mit demjenigen, der die Bauteile herstellt und lediglichanliefert, grundsätzlich nach Kaufrecht zu beurteilen ist.

Wie ist der Unterschied richtig auf Software und Systeme zu übertragen?

2. Argumentations-Ansatz aus 9.2.2010Werkvertrag, wenn Planungsleistung überwiegt. Die Ausnahme wäre Werkvertrag, die RegelKaufrecht. Für die Ausnahme – offen gelassen - , s. Rz. 9 oben, käme es darauf an obzusätzlich wesentliche Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten zumGegenstand gehören.Individual- Software zu schaffen oder Standardsoftware anzupassen und zu implementieren,könnte dem Umstand entsprechen, namentlich in den Produktionsprozess einzupassender Maschinenoder Investitionsanlagen, und im Zusammenhang damit die Erbringung zusätzlicher wesentlicher Planungs-,Konstruktions-, Integrations- und Anpassungsarbeiten.

3. Argumentations-Ansatz aus 4.3.2010! Rz 21: Unter Umständen >>> § 651 und Kauf, „regelmäßig ... Werkvertrag“.

Es ist zwar unklar, wie das „regelmäßig“, also die Regel und somit die Umstände alsAusnahme hergeleitet und begründet werden können. Immerhin wird ein Regel-/Ausnahmeverhältnis angenommen. Hoeren sieht dies als Zurückrudern des III. Senatsgegenüber dem VII (Silowände) (Beck-blog.de v. 7.4.2010). Die E. v. 9.2.2010 ist vom regel-/Ausnahmeverhältnis diametral (?) entgegengesetzt.

VI. Was ändert sich für die Diskussion um § 651 – Anwendung imHinblick auf neue Methoden?1. Diskussion Software und Sachqualität

Sachdiskussion bei Software unter evtl. Aufschlüsselung - Softwareerstellung Standardsoftware - Softwareerstellung Individualsoftware - Anpassung beim Kunden vorhandener Software - Anpassung beim Kunden vorhandener Software - Systemvertrag, Exkurs zu EVB-IT System und Systemlieferung

20

Ungelöst: Verjährung, wenn (zwecks Vermeidung der anwendung des § 651)Sachqualität abgelehnt wird.

2. Thesen:- Iteration und Spirale, erst recht Scrum mit einzelner Mini-Planung lassen eigenes

erhebliches Gewicht der Planung (allein) durch AN vermissen.- Das Ganze (Projekt) als „Planung“ erscheint auch im Hinblick auf Ziele (Manifesto)

und Vorgaben abwegig.- Teleologische Reduktion/Auslegung geht nicht (mehr).

VII. Lösung: Planungsanteil, Gemischter Vertrag

1. Zwischenüberlegung- Somit also erfolgt Anwendung von Kaufrecht auf IT-Realisierungs-Projekte? - aber

nicht auf – gesondert beauftragte - Planung/Erstellung „Pflichtenheft“,Projektleitung28. Was aber bewirkt ein Planungsanteil beim Erstellungs- undAnpassungsvertrag?29

- Bei Spiralförmigem vorgehen, Iterations-Mini-schritten, Scrum, Koop. u.ä. Momentenverliert sich die Möglichkeit der Trennung.

- Mankowski30, Europa-Rechts-konforme Auslegung lässt „Sachdiskussion“ praktischleerlaufen.

2. Gemischte Verträge, Auswirkungen der Theorien dazu?Aufbau der Leistungsbereiche, „Schleichender“ Wandel im Vertragstyp,OLG München v. 15.02.1989, CR 1990, 646OLG Düsseldorf v. 09.06.1989, NJW 1989, 2627, Installation ändert VertragstypOLG Köln v. 04.11.2002, CR 2003, 246;OLG Karlsruhe v. 16.08.2002, CR 2003, 95BGH v. 08.10.2009 – III ZR 93/09 VideoportalDienstvertrag bei Lieferung Standardsoftware und zusätzlich Anpassung, v.a. wennAnpassungsaufwand relativ gering?

a) Zur Anwendbarkeit von § 627 Abs. 1, § 628 Abs. 1 Satz 1, 3 BGB aufeinen Vertrag mit dem Betreiber eines sogenannten Video-Partnerportals.Stephan-lorenz.de : Der BGH sieht hier zu recht in der werkvertraglichenKomponente (Erstellung eines Videos) eine nur untergeordnete Leistung. Esliegt also ein gemischter Vertrag vor, der seinen Schwerpunkt aber imDienstvertragsrecht hat und daher zumindest für die Kündigungsmöglichkeitallein Dienstvertragsrecht unterliegt.

3. „Vorschläge“, AlternativenVorschlag 1: Analogie zu, Vergleich mit Maschinenlieferungs- und Aufstellungsvertrag. Statt Abnahme: Test der

Vertragsgemäßheit, proof of ... vor Auslieferung und SLA zur Performance.31

28 S.a. J. Schneider, in Schneider/von Westphalen (Hrsg.), Softwareerstellungsverträge, 2006, B. 1 ff., 4829 Nach Maume/Wilser, CR 2010, 209, bei Softwareerstellung sei „stets“ Planung vorausgehend.30 Zitat wie oben: CR 2010, 137 zu OLG München, Internationale Zuständigkeit, S. 138: „Ob einSoftwareentwicklungsvertrag unter deutschem Recht ein Werkvertrag wäre, spielt für die europäische Einordnungkeinerlei Rolle.“ Und Fn. 9: „Dies übersieht OLG München …“.31 BGH v. 22.08.1998 - VIII ZR 220/97 zu Kauf mit Montageverpflichtung und Rückabwicklung

21

Vorschlag 2: Evtl. ist aus Anbietersicht die beste „Neutralisierung“: LieferungStandard-Software und separater Vertrag zur Planung und Anpassung (mitAnpassung der Org./Geschäftsprozesse des AG32!). Jedenfalls könnte es sichempfehlen, Planung und Realisierung wieder stark zu trennen.

Die Gefahr ist allerdings bei AGB, dass die Gerichte wie bisher verfahren, eineKlammer sehen, die sich oft aus dem Angebot ergibt und somit eine Einheitannehmen.

Es wäre das Vorgehensmodell zu wählen, das sich planen lässt, und sei es, dassdie Iterationsschritte und die je Schritt einzuhaltende/zu durchlaufende Schrittfolgeje Iterationsabschnitt (Srum-ähnlich) analog dem Meilensteinkonzept geplant undvereinbart werden.

Vorschlag 3: Alles individuell festlegen (Feinspezifikation/Vorgehensmodell) regeln,Tests, cases, Kriterien, Vorgehen, Aktivitäten, Fristen, Zusammenarbeit, Folgen derNichteinhaltung, ...

Vorschlag 3a: Dritt-AGB, auf die sich beide Partner einigen (EVB-IT?): orientiert anBGH v. 17.2.2010 – VIII ZR 67/09.

a) Ein Stellen von Vertragsbedingungen liegt nicht vor, wenn die Einbeziehung vorformulierterVertragsbedingungen in einen Vertrag auf einer freien Entscheidung desjenigen beruht, der vomanderen Vertragsteil mit dem Verwendungsvorschlag konfrontiert wird. Dazu ist es erforderlich,dass er in der Auswahl der in Betracht kommenden Vertragstexte frei ist und insbesondereGelegenheit erhält, alternativ eigene Textvorschläge mit der effektiven Möglichkeit ihrerDurchsetzung in die Verhandlungen einzubringen.

Vorschlag 3b: „Gegengewichte“ im Vertrag zur explizit gewählten Methodikangepasst an deren Eigenheiten,z.B.

- Schulungskonzept, Verantwortung für Transfer

- Relevanz der Tickets, kurzfristige Rückmeldung über deren Bearbeitung

- QS-Instrumente und daraus Gewinnung der Reports, gewinnung derKenndatenfür Fortschrittskennzeahlen und Abnahmereifegrade.

- Freigaben als Kompromiss, s. sogleich 4.

- Dokumentationen, evtl. im (elektronischen) Projektordner

Vorschlag 4: Übergewicht bei Planung, passt nicht zu modernenVorgehensmodellen! Der Planungsanteil wird intrgriert, die Phase vor Realsierungentfällt. Wäre aber mit V-Modell und Prototyping machbar.

These: Dazu fehlt bzw. ist zu entwickeln ein Konzept, wie bisherige Schritte undFestlegungen genehmigt werden, um auch eine Referenz für Änderungsmanagementzu schaffen, ohne (aus AG-Sicht also zu vermeiden) Teilabnahmen vorzunehmen odergar Abnahmen. Dazu s. „Freigaben“, s. 4.

Auch „ITIL“ enthält geeignete Institutionen und ist von der Phasenfolge her alsplanungsstark, wäre somit als §651-resistent interpretierbar, gehört aber eher zum

32 S.a. J. Schneider, ITRB 2008, 261

22

Outsourcing-Vorgehen33. Dies beachten Viele nicht, wenn sie ITIL auf denEntwicklungsvertrag anwenden wollen.

4. „Freigabe“ als Kompromiss für Spirale, Iteration, Teilabnahme …

Aus Anwendersicht wird es sich empfehlen, einerseits keine Teilabnahmen zu akzeptieren,andererseits eine Gesamtabnahme vorzusehen. Wenn aber der Gesamtumfang des Projektsvon Anfang nicht feststeht, fällt es schwer, dessen Ende zu ermitteln. Ein Festpreis für ein imErgebnis unklares Projektziel erscheint unangebracht. Ein Aufwandsprojekt droht aus demRuder zu laufen bzw. finanziell zu eskalieren.

Durch die Iterationsschritte kann es sich empfehlen, als Instrumentarium die „Freigabe“34

einzuführen, die eine Art Mittelding darstellen könnte zwischen bloßem zur Kenntnis nehmendes jeweiligen Entwicklungsstandes und einer (Teil-)Abnahme.

Der typische Fall, wo sich dieses Instrument bewähren dürfte, ist die Anpassung vonStandardsoftware über die Parametrierung hinaus. Der Kunde hat sich ein Paket ausgesuchtaufgrund einer Grobspezifiikation, die zwangsläufig deshalb grob ist, weil er sonst diegenauen Ergebnisse erst anhand der ausgewählten Software festlegen möchte. DieseKonkretisierungen ufern naturgemäß leicht auch in Änderungen bzw. Erweiterungen aus. DieVorgehensweise würde dann vertraglich dahingehend strukturiert, dass die Aufgabengebieteje Modul oder sonst unterteilbarem Bereich eine bestimmte Schrittfolge absolviert wird, diesehr nahe an dem Modell eines Change Managements ist:

- Identifizierung und Festlegung der zu präzisierenden/konkretisierenden Aufgabe- Referenzierung der durch die Standardsoftware abgedeckten

Bereiche/angesprochenen Funktionalitäten im Grobkonzept- Konkrete Beschreibung der entsprechenden Funktionen bzw. des

Funktionsbedarfs abgeleitet aus „Grobpflichtenheft“, Verifikation derProblemstellung

- Abgleich mit Standard/Gewinnung der detail der Anforderungen- Konkretisierung der Anforderungen, Beschreibung als Feinkonzept- Aufwandsschätzung und Priorisierung- 1. unbedingt- 2. möglichst- 3. „nett“- Feinkonzeption, Redaktion seitens des Auftragnehmers mit Angebot der

Durchführung/konkrete Planung der Durchführung- Präsentation der Ausarbeitungen mit Aufwandsermittlung- Abstriche/Streichkonzert, „Angebot“ mit Leistungsbeschreibung und (neuem)

Zeitplan- Freigabe

Die Freigabe würde juristisch/vertraglich dadurch relevant, dass sie neben dem Start für dieRealisierung des so gewonnenen Teil-Feinkonzepts eine Verpflichtung des Auftraggeberdarin enthält bzw. bewirkt, dass bei etwaigen späteren Änderungen seitens desAuftraggebers bezüglich seiner Anforderungen diese ihm zwar nicht verwehrt sind, jedochzusätzlich zu vergüten sind. Infolge dessen wäre es dem Auftragnehmer möglich, diesenTeilbereich zu einem Festpreis zu erarbeiten. Die Freigabe würde demnach eine Selbst-Beschränkung des Auftraggebers auch dahingehend bewirken, dass schon aus finanziellenGründen gegenüber nicht unbedingt erforderlichen Änderungswünschen ein Riegelvorgeschoben wird.

33 S.a. Söbbing, MMR 1010, 222.34 S.a. J. Schneider, Handbuch des EDV-Rechts, 4. Aufl., H. Rz. 86b.

23

Literaturhinweise

- Auer-Reinsdorff, Feststellung der versprochenen Leistung beim Einsatz agiler Projektmethoden,ITRB 2010, 93 (4).

- Anmerkung Hoffmann zu BGH vom 23.07.2009 in MMR 2009,

- Koch, Agile Softwareentwicklung – Dokumentation, Qualitätssicherung undKundenmitwirkung, ITRB 2010, 114 ff

- Lapp, Interaktion und Kooperation bei IT-Projekten, ITRB 2010, 69 (3)

- Maume/Wilser, Viel Lärm um nichts? Zur Anwendung des § 651 BGB auf IT-Verträge, CR 2010, 209

- Mankowski, Internationale Zuständigkeit am Erfüllungsort bei Softwareentwicklungsverträgen, CR2010, 137 zu OLG München, Internationale Zuständigkeit, S. 138

- Müller-Hengstenberg/Kirn, Welche Bedeutung haben Prototyp und pilot sowiePrototyping- und Pilotierungsphase bei IT-Projekten?, CR 2010, 8

- Müller-Hengstenberg, Ist das Kaufrecht auf alle IT-Projektverträge anwendbar? NJW 2010, 1.811181 (neu, nach Vortrag)

- Schneider, J., „Neue“ IT-Projektmethoden und „altes“ Vertragsrecht, ITRB 2010, 18 (1)

- Anmerkung Schweinoch zu BGH v. 23. 7.2009, CR 2009, 637, 640;

- Schweinoch, Geänderte Vertragstypen in Softwareprojekten, CR 2010, 1.

- Witte, Agiles Programmieren und § 651 BGB, ITRB 2010, 44 (2).