Fachausschuss Vertragsrecht der DGRI Sitzung am in München. Moderne Vertragsgestaltung vs. BGB (und BGH?) Beitrag J.

Transkript

1 Fachausschuss Vertragsrecht der DGRI Sitzung am 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 VII ZR 151/08 bei Projektverträgen, zusammen mit - BGH v X ZR 82/07 Tiefladesattelauflieger, und - BGH v III ZR 79/09 Web-Design-Vertrag. 1

2 Gliederung VORWEG Thesen...3 I. Moderne Projektmethoden Manifesto for Agile Software Development Principles behind the Agile Manifesto SCRUM Prototyping V-Modell...7 II. Typische Merkmale moderner Projektmethodik, v.a. bei Extreme Programming.8 1. Versuch Schema zu Extreme Programming Projektverträge in der Rspr., BGB a.f. - Werkvertrag Abgleich Projektvorgehensmodelle und Rspr. Positionen...10 III. BGH intervenierende Variable über 651 BGB? BGH v Silowände BGH v Tiefladesattelaufleger BGH v. 4. März III ZR 79/09 Web-Design-Vertrag...16 IV. OLG München v gegen BGH, Lit OLG München v U 3515/09, CR 2010, Lit. Stellen zu Projektvertrag und V. Argumentationen gegen 651-Anwendung aus den BGH-Urteilen Argumentations-Ansatz aus : Argumentations-Ansatz aus Argumentations-Ansatz aus VI. Was ändert sich für die Diskussion um 651 Anwendung im Hinblick auf neue Methoden? Diskussion Software und Sachqualität Thesen:...20 VII. Lösung: Planungsanteil, Gemischter Vertrag Zwischenüberlegung Gemischte Verträge, Auswirkungen der Theorien dazu? Vorschläge, Alternativen Freigabe als Kompromiss für Spirale, Iteration, Teilabnahme...22 Literaturhinweise

3 VORWEG Thesen Als erkenntnisleitende Frage wird unterstellt: Bei welcher Argumentation bzw. Lösung vermeidet man am ehesten Widersprüche bzw. erzeugt die wenigsten Widersprüche oder zweifelhafte bis unbrauchbare Ergebnisse? Der folgende Reißverschluß-artig gedachte Vortrag kombiniert die Agile- und die 651-er Problematik. These 1: Die drei BGH-Entscheidungen zwingen nicht, über 651 BGB Kaufrecht auf die Erstellung und Anpassung von Software anzuwenden. Die Entscheidung des OLG München würde allerdings dazu führen, 651 BGB strikt nicht anzuwenden 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 nicht mehr als Verjährungsregelung in Betracht (im Verbund mit 634a Abs. 2 Verjährung von zwei Jahren beginnend mit der Abnahme). D.h., dass zwar eine Abnahme durchaus erforderlich ist, diese jedoch nicht für die Verjährung maßgeblich ist. Vielmehr gilt die regelmäßige Verjährungsfrist und diese beginnt nicht mit Abnahme, sondern nach den allgemeinen Regeln. Dieses Ergebnis erscheint dann nicht umgehbar, v.a. nicht i.v.m. OLG München. Für Pflegeverträge, die bei Systemverträgen die Standardsoftware gegen Pauschale und die angepassten 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 werden kann. These 2: Die "modernen" Vorgehensmodelle unterlaufen/konterkarieren die Argumentationsbemühungen für eine Rechtfertigung der Anwendung von 631 ff. unter Hinweis auf den (hohen) und damit auch separierbaren bzw. darleg- und beweisbaren Planungsanteil. Die Frage ist, was überhaupt von diesem Planungsanteil bleibt. These 3: Die Verneinung der Sachqualität ist nicht europarechtskonform und schafft zusätzliche Probleme bei Lizenz, weil Mietrecht nicht anwendbar ist. 3

4 I. Moderne Projektmethoden 1 1. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value 2 : 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 left more. 2. Principles behind the Agile Manifesto We follow these principles 3 : 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development 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 Tage Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungen hinzugefügt. 3 Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungen hinzugefügt 4

5 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace 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-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Xtreme Programming Ruby on rails u.ä. 3. SCRUM Scrum (engl. für Gedränge) ist ein Vorgehensmodell mit - Meetings, - Artefakten, - Rollen, - Werten und - Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich ist. Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden Oder: 5 Scrum is an iterative, incremental framework for developing any product or managing any work. 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 its sprints 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 of agile software development. Rollen: - Product Owner - Team - Scrum Master - Zusammenspiel - Zertifizierung Artefakte: 4 ; s.a s.a. Auer-Reinsdorff, ITRB 2010, i.e., 5

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 Programming oder Extreme Programming haben als eine Art Vorläufer das Prototyping. 6 Das Interessante dabei ist und damit auch das Vergleichbare mit den moderneren Methoden, dass dem Kunden in einem relativ frühen Stadium ein in bestimmten Kernfunktionalitäten bereits vorhandenes Programm gezeigt werden kann, auch wenn das 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 aufweisen, die also auch noch nicht mit z.b. Vorführdaten arbeiten können, hier handelt es sich 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. 6

7 Das Prototyping ist insofern für die hier zu behandelnden Fragen von Interesse, als die Folgend der neuen Projektmethoden bezüglich Dokumentation, spiralförmigen Vorgehens u.ä. vergleichbar sind, während die Voraussetzungen durchaus verschieden sind, indem nämlich beim Prototyp etwas im Kern funktionsfähiges vorliegt, zumindest vorliegen sollte. 5. V-Modell Das 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 zur Systemsicherheit. Das V-Modell XT orientiert sich nun stärker an den Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Darüber hinaus ist jedoch viel 'unter der Haube' geschehen. Die Werkzeugunterstützung durch den Projektassistenten wurde in vielerlei Hinsicht überarbeitet, um eine bessere Tailorbarkeit und Planbarkeit zu erreichen. Die beliebten Export-Funktionen wurden um weitere Dateiformate erweitert: DOC und ODT für Produktvorlagen, MS Project XML für Pläne. Für den Anwender unsichtbar wurde ein Variantenkonzept realisiert, mit dem Anpassungen des Vorgehensmodells an organisationsspezifische Besonderheiten werkzeuggestützt durchgeführt werden können. Zum V-Modell und dessen Struktur: 7

8 II. Typische Merkmale moderner Projektmethodik, v.a. bei Extreme Programming 1. Versuch Schema zu Extreme Programming Zu den Zielen von Agile Programming: Manifesto for Agile Software Development und Principles behind the Agile Manifesto 8, s. oben Zitat Es folgt der Versuch einer Zusammenfassung der Charakteristika moderner Projektmethoden und ihrer Wirkung im Verbund mit Stichworten zur vertragsrechtlichen Beurteilung, orientiert an Extreme Programming: Sarre/Schmidt 9 Charakteristika 1. Die Funktionalität des Systems wird in Users Stories 10 zusammengefasst (GUI, Funktionalitäten, Testfälle und - szenarien), = lfd. Grobspezifikation Wünschdirwas + Redaktion 2. SW-Qualität Qualitätssicherung, 2.a Jeweils zwei Entwickler programmieren gemeinsam ( programming in pairs ) 2.b Gemeinsamer Code- Besitz (collective code ownership) 2.c Ständige Refaktorisierung Bisherige Institution Pflichtenheft entfällt als corpus mit einheitlichem Versionsstand der Feinspezifikation, das Vorgehen ähnelt aber Zurufprojekt und Fall mit fehlendem Pflichtenheft Sache des Auftragnehmers Dienstvertrag aufgrund gemeinsamer Entwicklung der Vorgaben und der Ergebnisse? 15 Quellcode für AG? Urteile BGH zum mittleren Ausführungsstandard 11 und zur Ausführungsart 12, Mittlerer Ausführungsstandard 14 Absicherung, v.a. wenn 2. Entwickler Mitarbeiter des AG ist. BGH v zu Umständen einer Herausgabepflicht Anm./Fragen Worauf beruht Kalkulation? 13 Initial GUI als Oberflächenbeschreibung, Funktionalitäten, Testszenarien, laufender Verfeinerung erst später In klassischen Verträgen im Vertrag nicht geregelt, wird erst bei Abnahme (frühestens) geprüft Nutzungsrechte stehen beiden Vertragspartner (gemeinsam) zu. 16 Wenn nicht beide Vertragspartner ein Exemplar des Code haben, sollte er zu Gunsten beider, also 2- fach, hinterlegt werden Qualitätssicherung, Konfigurationsfähig 8 vom Verfasser auch auf Kölner Tagen 2010 angesprochen, ebenso das folgende Schema 9 Linke Spalte stammt ohne Verweise - aus Vortrag Sarre/Schmidt, Folie 8: Wesentliche Merkmale, Habel IT- Gesprächskreis, München , erweitert für Tagung Kölner Tage S. z.b. Mike Cohn, User Stories Applied: For Agile Software Development, BGH v X ZR 129/01, CR 2004, S. oben BGH v X ZR 167/04, 13 Wichtig für Risikoverteilung bei Änderung der Ausführungsart, s. BGH v , NJW 1998, BGH X ZR 129/01, CR 2004, S. eher abl. Schneider Handbuch des EDV-Rechts, 4. Aufl. 2009, H. Rz. 7 f. 16 S. a. zum Problem OLG Frankfurt v , CR 2003, 50. 8

9 2.d (continuous refactoring) 17 Schnelle Code- Reviews (rapid code reviews) 3. Vor der Entwicklung werden (automatisierbare) Tests erstellt, > Nr. 1 = Teil der Vorgaben, es wird festgelegt, wie getestet wird, ermöglicht, dass sich die Entw. der Testfälle bedienen können Bisher Tests nachträglich proof of...? mit Ausstiegsszenari en und Anschärfen der Folgen je nach absolvierter Phase Vor Abnahme ist Auftragnehmer für Mangelfreiheit verantwortlich und Beweis-belastet, evtl. >>>Machbarkeit und >>Zwischenabnahme, Freigabe für weiteres Vorgehen? -keit wird verbessert Aktuelle Berücksichtigung von Korrektur- Bedarf 4. Auf unnötige Features wird verzichtet (YAGNI - you aren t gonna need it) 5. Kunde ist bei der gesamten Entwicklung dabei ( on-site customer ), 6. Extrem kurze Zyklen für ( Schraube ) Anforderungsanalys e, Design, Implementierung und Test. Das Ergebnis pro Zyklus ist immer ein lauffähiges Programm ( small releases ). 7. Insgesamt entsteht keine oder nur sehr wenig Dokumentation seitens AN CR - Management Realisierung ist Sache des AN, AG ist nicht verpflichtet, die Ausführungsart des AN zu prüfen (BGH v X ZR 167/04, s.a. BGH zu Funktionsmangel Keine Pflicht des AN zu prüfung der Ausführungsart und zu Teilabnahmen Bedienungs- Handbücher (+Installationsanl eitung) OLG Düsseldorf v , Gitteroste (Deltapflichtenheft reicht nicht); OLG Köln v , CR 1998, 459 proaktiver AN Mitwirkung als Hauptleistung?, Kooperationsvertrag Freigaben, Teilabnahmen, Gesamtabnahme BGH v OLG Karlsruhe v , CR 2002, 802; BGH v X ZR 9/99 8. Resumee /Frage BGH , BGH und BGH ,./. OLG München BGH , Mittlerer Ausführungsstanda rd revidieren, mehr auf Vertragszweck abstellen Wem gehören die Ergebnisse? Obwohl Planung verschwindet, passt 651 nicht (?). 17 S. z.b. Martin Fowler u.a., Refactoring: Improving the Design of Existing Code,

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 andere Leistungen hinzutreten, durch die Erstellung der Software geprägt. Der Vertrag enthält unter Umständen noch die Erstellung der fachlichen Vorgaben (Gewinnung des Pflichtenhefts ) und zerteilt sich insofern grob in die Phasen - Planung und - Realisierung. Das Argument für die Nichtanwendung ist gerade die beinhaltete, aber vor die Realisierung ( Herstellung ) geschaltete Planung. Im Hinblick auf 651 BGB wäre andererseits wichtig, den Hardwareanteil zu berücksichtigen bzw. ins Verhältnis zu setzen. Systemverträge müssten demnach eher nach Kaufrecht beurteilt werden. 18 Entsprechendes gilt für die Services, also Installation, Einrichten, Einführungsunterstützung usw., wenn sie nicht eigenständigen Charakter haben. b) Erfolgsverantwortung beim AN Die typische vertragstyplogische Einordnung des klassischen Projekts ist Werkvertrag und zwar wohl in der Regel ungeachtet der Anteile der Hardware. Als Erfolg wird die Erstellung des betriebsfertigen Systems ( schlüsselfertig ) gesehen. Die Projektverantwortung folgt selbstverständlich aus der Erfolgsverantwortung seitens des Auftragnehmers und somit verbleibt nur Mitwirkungsleistung des Auftraggebers. Ist der Erfolg nicht in einem Pflichtenheft definiert, gilt ein mittlerer Ausführungsstandard nach Stand der Technik und orientiert am Vertragszweck 19. c) Pflichtenheft Die Beibringung des Pflichtenhefts als fachliche Anforderungen ist Sache des Auftraggebers. Dies gehört zu seinen genuinen Mitwirkungspflichten. 20 Kann der Softwarehersteller die Verpflichtung zur Programmierung nur sinnvoll unter Mitwirkung des Kunden erfüllen, so besteht aus in der Natur der Sache liegenden 18 BGH v a.a.o., anders gerade die EVB-IT System. 19 BGH v X ZR 129/01, CR 2004, BGH v , CR 1989, 102 Registierkassen und BGH v , CR 1996, 467 Service-RZ II. 10

11 Gründen, auch ohne ausdrückliche Regelung, eine entsprechende Mitwirkungspflicht. 21 Unmittelbar auch heute noch passend für diese Entscheidung, v.a , hinsichtlich der Parametrierung, da es um das Ausfüllen von Programmblättern bzw. die Spezifikation von Warengruppe, Preis und einer Kurzbeschreibung der Ware ging. Man könnte dies auf heutige Verhältnisse also als Kurzbeschreibung des Produkts bzw. des Geschäftsprozesses ansehen. Gemäß diesen Entscheidungen bedarf es nicht einmal einer expliziten Regelung der Mitwirkungspflichten im Vertrag, obwohl dies sicher empfehlenswert ist (auch im Rahmen 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ören 22 : - 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 zumindest nach 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 , CR 1989, 102, 104 (LS 2) Registrierkassen und Bestätigung durch BGH v , CR 1998, 393, 395 Warentermingeschäft. 22 Hoppen/Hoppen, Bewertung und Bilanzierung selbst erstellter Software, CR 2009, 761, 766 mit Auflistung was zur Softwareentwicklungsdokumentation 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. 11

12 Anm./These: Stories, Cases sind zwar Anforderungen/Forderungen, jedoch kein Pflichtenheft, auch keine Bestandteile, wenn sie nicht über die zuständigen Instanzen aufgegriffen und in den Design-/Entwicklungsprozess integriert werden; sie taugen auch später nicht als Basis für die Dokumentation, wenn sie nicht systematisch aufbereitet und bearbeitet werden. Sie können aber zur näher zu konkretisierenden Leistungsbeschreibung, auch für Tests dienen. Die Relevanz ergibt sich aus vertraglichen Regelungen. Die Möglichkeit der Erstellung durch den Anwender erscheint hinsichtlich der Entwicklungsdokumentation äußerst fraglich. Des weiteren wird angenommen, jedenfalls von vielen Auftragnehmern, dass die Bedienungsanleitung Bestandteil der Software selbst wäre und zwar über die Onlinehilfe. Dies ist zwar insofern richtig, als es Tendenzen gibt, große Teile dessen, was früher in der Bedienungsanleitung stand, in die Onlinehilfen zu verlagern. Dies enthebt jedoch nicht insgesamt der Notwendigkeit einer Benutzerdokumentation zumindest in einer grundsätzlichen Darstellungsform. Dabei ist wenig relevant, ob es sich um eine ausdruckbare oder ausgedruckte Fassung handelt. Vielmehr ist zu beachten, dass mindestens die Installationsanleitung und ein gewisser Kern von Anweisungen in schriftlicher Form so vorliegt, dass der Kunde damit auch dann umgehen kann, wenn er evtl. erneut die Software zu installieren bzw. zum Anlaufen 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 und wann sie im einzelnen zu erstellen ist. Hypothese: Ist die Frequenz der Änderungsverlangen nicht hoch und sind die Änderungsverlangen nicht gravierend, dürfte ökonomisch gesehen eine projektsynchrone bzw. leicht zeitversetzte Erstellung der Entwicklungsdokumentation einschließlich auch der Anwendungsdokumentation einfacher und damit kostengünstiger sein. Bei höherer Änderungsrate und bei tiefergreifenden Änderungen dürfte eine Erstellung der Dokumentation im nachhinein die kostengünstigere sei. Der BGH hat diese Überlegungen nicht so angestellt, aber vielleicht indirekt berücksichtigt. Jedenfalls gehört zum typischen Projekt zum einen eine gewisse Änderungsrate und zum anderen ist die Dokumentation erst fällig, wenn nach einer angemessenen Frist (die bei einer evtl. Fristsetzung nach altem Recht im Rahmen von 326 zu berücksichtigen war) nach Ende der Fertigstellung incl. der Abarbeitung 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 einen Projektvertrag aussehen könnte, in dem es einen Zeitpunkt gibt, der als relativer Termin das Ende der Änderungswünsche und deren Realisierung markiert, ab dem dann die vereinbarte Frist für die Erstellung der Dokumentation läuft. Diese Frist müsste evtl. noch angepasst werden, wenn durch die Änderungswünsche ein erheblicher Mehraufwand auch bei der Dokumentation (wegen Erweiterung der Funktionalitäten usw.) entstehen würde. Der Katalog der Dokumentationen ist offen. Im juristischen Bereich hat allerdings bislang v.a. die Anwendungsdokumentation und allenfalls die Installationsanleitung 12

13 eine Rolle gespielt. Die weiteren Dokumentationen wären und sind wohl im wesentlichen 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 der Hardware einzustehen (also veraltet), muss dabei auch in gewissem Umfang möglichen nachträglichen Änderungen und Ausweitungen der Programme Rechnung tragen. Die Grenze des gewissen Umfangs bemisst sich nach den zu erwartenden Mehrkosten, den Umfang, den Zeitpunkt und der Wahrscheinlichkeit einer Programmerweiterung sowie den Möglichkeiten und Schwierigkeiten einer späteren Erweiterung. 25 LS 3 Indirekt bestätigt auch die Entscheidung vom die Üblichkeit von Änderungsverlangen und deren Ausführung (im Hinblick auf die Fälligkeit der Software-Dokumentation besonders relevant). 26 f) Zur Abnahme Typisch für Projekte ist, dass der Abnahmeerklärung eine ausführliche Erprobung zwecks Feststellung der Abnahmefähigkeit vorausgeht. Ausführliche Verträge regeln in einer Reihe von Phasen den schrittweisen Übergang bis hin zum Probebetrieb als Abnahmetest einschließlich einer gewissen fehlerfreien Zeit. Soweit schon vorher Abnahmen vorgesehen sind, wird in der Regel eine Gesamtabnahme vereinbart, die möglicherweise einen eingeschränkten Gegenstand hat, etwa noch Performance, während die Funktionalität der einzelnen Module bereits vorher getestet wäre, nun aber noch die Gesamtfunktionalität ansteht, also die Interoperabilität innerhalb des Systems u.ä.. Als typisch für die Verbindung mit Outsourcing bzw. überhaupt für Outsourcingverträge ist die Regelung auch der Phase nach der Abnahme, etwa im Sinne einer Anlauf-/Einarbeitungsphase incl. Einschwingen hinsichtlich der Skills auf Seiten des Auftragnehmers. Dies gilt insbesondere, wenn nicht das selbe Personal, 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 wenn keine besonderen Regelungen hierfür im Vertrag zu finden sind. Allerdings empfiehlt es 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. die Ergebnisse haben u.ä. Evtl. enthält der Vertrag noch Regelungen, dass die Mitwirkung 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 v X ZR 92/90, CR 1993, 424. Noch deutlicher: BGH v X ZR 16/85, CR 1986, 977 Reservekapazität im Hardware-Mengengerüst (soweit auf Hardware bezogen wohl veraltet). 25 BGH v X ZR 16/85, CR 1986, 977, LS 3 26 BGH v X ZR 9/99, CR 2001,

14 Regelung der Mitwirkung nicht kompensiert, dass es sich insoweit nicht um Hauptpflichten handelt. Dies dürfte sich auch nach Schuldrechtsmodernisierung nicht anders darstellen. Umso wichtiger wäre die exakte Regelung möglichst vieler Mitwirkungspflichten im Rahmen des Aktivitäten- und Fristenplans. III. BGH intervenierende Variable über 651 BGB? 1. BGH v Silowände BGH, Urteil vom 23. Juli 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 herzustellender oder zu erzeugender beweglicher Sachen anzuwenden, also auch auf Verträge zwischen Unternehmern. b) Verträge, die allein die Lieferung von herzustellenden beweglichen Bau- oder Anlagenteilen zum Gegenstand haben, sind nach Maßgabe des 651 BGB nach Kaufrecht zu beurteilen. Die Zweckbestimmung der Teile, in Bauwerke eingebaut zu werden, rechtfertigt keine andere Beurteilung. c) Eine andere Beurteilung ist auch dann nicht gerechtfertigt, wenn Gegenstand des Vertrages auch Planungsleistungen sind, die der Herstellung der Bau- und Anlagenteile 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 erhebliche Kritik 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, diejenigen Werklieferungsverträge, die nach altem Recht noch dem Werkvertragsrecht unterstellt waren, nunmehr als Kaufverträ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 Gesetzes ausreichend zum Ausdruck gekommen. Das Gesetz kann nicht unter Hinweis darauf umgangen werden, dass die 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üche systematisch in der Regelung des 651 Satz 1 BGB angelegt sind (Rudolph, aao). Es mag als Wertungswiderspruch empfunden werden, dass ein Vertrag mit demjenigen, der die Errichtung des Bauwerks schuldet und dazu die Bauteile herstellt und anliefert, nach Werkvertragsrecht zu beurteilen ist, während ein Vertrag mit demjenigen, der die Bauteile herstellt und lediglich anliefert, grundsätzlich nach Kaufrecht zu beurteilen ist. Dieser vermeintliche Wertungswiderspruch ist jedoch allgemein in 651 BGB angelegt, weil die Anwendung von Kaufrecht auf im Kern erfolgsbezogene Verträge angeordnet und vom Gesetzgeber in der Meinung akzeptiert worden ist, Kauf- und Werkvertragsrecht unterschieden sich nicht wesentlich. Das... Rz Dem Gesetz kann keine Beschränkung derart entnommen werden, dass lediglich Verträge über die Lieferung von typischen 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 nichts her. Die Beschränkung lässt sich auch nicht aus einer autonomen Auslegung der Verbrauchsgüterkaufrichtlinie entnehmen, die für die Auslegung des Gesetzes bei einer Lieferung an einen Verbraucher zu berücksichtigen wäre. Die Verbrauchsgüterkaufrichtlinie findet allerdings nur auf Verträge Anwendung, die die Lieferung herzustellender oder zu erzeugender Verbrauchsgüter an Verbraucher zum Gegenstand haben. Daraus ergibt sich jedoch ausweislich der Richtlinie keine Einschränkung der dargestellten Art. Denn Verbrauchsgüter sind gemäß Art. 1 Abs. 2 lit. b) der Richtlinie bewegliche körperliche Gegenstände mit Ausnahme der dort benannten 14

15 Gegenstände. Eine weitere Einschränkung enthält die Legaldefinition der Richtlinie nicht. Sie ergibt sich auch nicht aus dem Verfahren zur Richtlinie (vgl. Rudolph, aao, S. 67). Insbesondere liegt kein Anhaltspunkt dafür vor, dass die schwierige Abgren-zung von typischen Massengeschäften oder zum Verbrauch bestimmten Gütern von anderen Gütern in irgendeiner Weise durch die Richtlinie eröffnet sein soll- 21 Von dem Anwendungsbereich des Werkvertragsrechts erfasst bleiben damit ausweislich der Begründung zum Entwurf des Gesetzes zur Modernisierung des Schuldrechts im Wesentlichen die Herstellung 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 Grundlage einer in der Literatur vertretenen Meinung zur Einordnung von Verträgen zwischen Unternehmern über die Lieferung eines herzustellen-den typischen Investitionsgutes Werkvertragsrecht anwenden zu müssen. In der Literatur wird geltend gemacht, 651 BGB sei nicht anzuwenden, wenn der Vertrag zwischen Unternehmern über die Lieferung eines herzustellenden typi-schen Investitionsgutes andere zusätzliche wesentliche Leistungen enthalte, zu denen etwa Planungs-, Konstruktions-, Integrationsund Anpassungsleistungen gezählt werden. Dabei sind vor allem Leistungen im Zusammenhang mit der Lieferung von in den Produktionsprozess einzupassenden Maschinen oder Industrieanlagen oder Projektverträ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 des Vertrages 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 den Schwerpunkt 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. Denn ein 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 Umfang Planungsleistungen ü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 des Werkvertragsrechts gerechtfertigt wäre. Das Berufungsgericht verkennt die Bedeutung der Planungsleistung im Anwendungsbereich des 651 BGB. Danach können solche Planungsleistungen, die als Vor stufe zu der im Mittelpunkt des Vertrages stehenden Lieferung herzustellender Anlagenteile anzusehen sind, der Beurteilung des Vertrages nach den Vorschriften über den Kauf regelmäßig nicht entgegenstehen. Wäre es anders, würde die Vorschrift des 651 BGB weitgehend leer laufen, denn jeder Herstellung geht eine 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 sie den Schwerpunkt des Vertrages bildet und deshalb die Anwendung des Werkvertragsrechts erfordert. Das kann z.b. dann der Fall sein, wenn es bei der Beauftragung im Wesentlichen um die allgemein planerische Lösung eines konstruktiven Problems geht. Für IT-Rechts-Zwecke relevant sind die Aussagen zu a) Generelle Anwendung 651 BGB, auch B:B. b) Keine teleologische Begrenzung bzw. Auslegung. c) Beachtlichkeit des Planungsanteils 27. Allerdings genügt nicht, dass der Unternehmer als Vorstufe planerisch tätig wird: Danach können solche Planungsleistungen, die als Vorstufe zu der im Mittelpunkt des Vertrages stehenden Lieferung herzustellender Anlagenteile anzusehen sind, der Beurteilung 27 Wobei noch zusätzlich zu berücksichtigen wäre: BGH v III ZR 93/09 Video-Partnerportal (dort Hauptleistung Betrieb) zur Beurteilung gemischter Verträge. S. aber eher noch restriktiver zur Relevanz des Planungsanteils: BGH , sogleich. 15

16 des Vertrages nach den Vorschriften über den Kauf regelmäßig nicht entgegenstehen. Wäre es anders, würde die Vorschrift des 651 BGB weitgehend leer laufen, denn jeder Herstellung geht eine gewisse Planungsleistung voraus... (mwn)., Rz BGH v Tiefladesattelaufleger BGH v X ZR 82/07 - Tiefladesattelauflieger Leitsatze Stephan Lorenz: a) Kaufrecht ist auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender beweglicher Sachen anzuwenden, auch wenn mit der Herstellung eine Planungsleistung verbunden ist (Bestätigung von BGH NJW 2009, 2877) b) 377 HGB ist auch auf Werklieferungsverträge anwendbar c) Die Beweislast für das Vorliegen einer Beschaffenheitsvereinbarung im Rahmen des subjektiven Fehlerbegriffs trägt der Käufer ( 434 I S. 1 BGB) Kommentar SL:... Kernaussage: Ein Vertrag über herzustellende Sachen ist nach 651 BGB auch dann dem Kaufrecht zugewiesen, wenn mit der Herstellung eine gewisse Planungs- und Konzeptionsarbeit verbunden ist. Argument: Der Herstellung von zu liefernden Sachen gehen typischerweise gewisse Planungsleistungen voraus und die Vorschrift des 651 BGB würde weitgehend leer laufen, wenn dieser Umstand dazu führte, statt Kaufrecht Werkvertragsrecht anzuwenden. Offen bleibt weiter, ob dann Werkvertrag anzunehmen ist, wenn die Planungsleistung überwiegt. BGH : Rz. 7 II. Das hält der rechtlichen Nachprüfung nicht stand. Rz a) Die Einordnung des geschlossenen Vertrages als Werkvertrag ist rechtsfehlerhaft. Nach 651 Satz 1 BGB finden auf einen Vertrag, der, wie hier, die Lieferung herzustellender oder zu erzeugender beweglicher Sachen zum Gegenstand hat, die Vorschriften über den Kauf Anwendung. Werkvertrags-rechtliche Bestimmungen treten nur ergänzend, und nicht verdrängend neben das Kaufrecht, wenn der Vertrag die Lieferung einer nicht vertretbaren Sache zum Gegenstand hat ( 651 Satz 3 BGB). Kaufrecht ist mithin auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender beweglicher Sachen anzuwenden (BGH, Urt. v VII ZR 151/08, zur Veröffentlichung in BGHZ vorgesehen, Tz. 19 unter Hinweis auf BT-Drucks. 14/6040, S. 268). Unerheblich für die vertragsrechtliche Einordnung ist entgegen der Auffassung des Berufungsgerichts deshalb, dass der Auflieger nach den konkreten Vorstellungen und Vorgaben der Klägerin habe hergestellt werden sollen. Das mag die Annahme rechtfertigen, der Vertrag habe die Lieferung einer nicht vertretbaren Sache zum Gegenstand gehabt. Dies ändert ausweislich der gesetzlichen Regelung in 651 Satz 3 BGB aber nichts an der grundsätzlichen Anwendbarkeit von Kaufrecht (vgl. insoweit auch BGH, aao Tz. 18 ff.). Rz. 9 b) Ob ausnahmsweise Werkvertragsrecht anwendbar sein könnte, wenn ein zwischen Unternehmen geschlossener Vertrag die Lieferung typischer Investitionsgüter, namentlich in den Produktionsprozess einzupassender Maschinen oder Investitionsanlagen, und im Zusammenhang damit die Erbringung zusätzlicher wesentlicher Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten zum Gegenstand hat, bedarf im Streitfall 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 Konstruktionsleistungen erbringen 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 Beklagten sei die technische Dokumentation des herzustellenden Sattelaufliegers übergeben worden, handelt es sich ausweislich des Zusammenhangs der Entscheidungsgründe um ein Versehen. Bei den gegebenenfalls erbrachten Planungs- 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 zu liefernden Sachen gehen typischerweise gewisse Planungsleistungen voraus und die Vorschrift des 651 BGB würde weitgehend leer laufen, wenn dieser Umstand dazu führte, statt Kaufrecht Werkvertragsrecht anzuwenden. 3. BGH v. 4. März III ZR 79/09 Web-Design-Vertrag 16

17 Rz. 16 Die Qualifizierung des "Internet-System-Vertrags" als Werkvertrag im Sinne der 631 ff BGB steht im Einklang mit der Rechtsprechung des Bundesgerichtshofs zur Zuordnung von Internet-Verträgen zu den Vertragstypen des Bürgerlichen Gesetzbuchs. Sie findet ihre maßgebliche Grundlage in dem von den Parteien vereinbarten Vertragszweck, wie er in der vertraglichen Leistungsbeschreibung und dem hieran anknüpfenden Parteiwillen, insbesondere auch in der verobjektivierten Kundenerwartung, zum Ausdruck kommt, und rechtfertigt sich letztlich auch aus einem Vergleich mit Verträgen, die ähnliche Gegenstände betreffen und als Werkverträge anerkannt sind. Rz. 21 (d) Im "Webdesign-Vertrag" verpflichtet sich der Anbieter, für den Kunden eine individuelle Website zu erstellen. Ein solcher Vertrag dürfte - ebenso wie ein Vertrag über die Erstellung oder Bearbeitung einer speziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software (s. BGHZ 102, 135, 140 f; BGH, Urteile vom 15. Mai X ZR 128/88 - NJW 1990, 3008, vom 3. November X ZR 83/90 - NJW 1993, 1063, vom 9. Oktober X ZR 58/00 - CR 2002, 93, 95 und vom 16. Dezember X ZR 129/01 - NJW-RR 2004, 782, 783) - regelmäßig als Werkvertrag im Sinne der 631 ff BGB, unter Umständen auch als Werklieferungsvertrag im Sinne von 651 BGB, anzusehen sein (s. dazu etwa Busche aao 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., Teil VIII 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

18 IV. OLG München v gegen BGH; Literaturhinweise 1. OLG München v 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 nicht entgegen. Selbst wenn man davon ausgeht, dass es sich bei dem Softwareprogramm um eine bewegliche Sache (Datenträger) handelt, besteht die eigentliche Leistung in der geistigen Schöpfung des Programms, und nicht in der Lieferung der herzustellenden beweglichen Sache. Darüber hinaus wurde die Individualsoftware per Datenfernübertragung übertragen, so dass auch von einer beweglichen Sache nicht ausgegangen werden kann.... Wie bereits ausgeführt, handelt es sich hier nicht um einen Kaufvertrag, sodass die Entscheidung des BGH vom (NJW 2009, 2877, Silowände) nicht einschlägig und vergleichbar ist. 2. Lit. Stellen zu Projektvertrag und Palandt/Sprau, 69. Aufl., 651 BGB Rz. 4 negiert trotz Zitat der E. deren Aussagen weitgehend: Ein Werkvertrag fällt nicht unter 651, wenn die Schöpfung eines Gesamterfolges den Schwerpunkt... bildet. Palandt/Sprau, 69. Aufl., Rz. 22 vor 631 BGB: Programmierleistungen sind in der Regel Werkleistungen ist in diesen Fällen mangels Sacheigenschaft der Leistung nicht anwendbar. - Anmerkung Schweinoch zu BGH v , CR 2009, 637, 640; - Schweinoch, Geänderte Vertragstypen in Softwareprojekten, CR 2010, 1. - Anmerkung Hoffmann zu BGH vom 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, 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 III ZR 79/09 Rz. 21 (d) Im "Webdesign-Vertrag"..., s. oben 18

19 V. Argumentationen gegen 651-Anwendung aus den BGH-Urteilen 1. Argumentations-Ansatz aus : Rz Verträge, die allein die Lieferung von herzustellenden Bau- oder Anlagenteilen zum Gegenstand haben, sind gemäß 651 BGB nach Kaufrecht zu beurteilen (Dauner-Lieb/Langen- Raab, Schuldrecht Teilband 2, 651 Rdn. 14; Messerschmidt/Voit-Messerschmidt/Leidig, Privates Baurecht, 651 Rdn. 28; Leupertz, BauR 2006, 1648 f.; Voit, BauR 2009, 369, 370). Inwieweit etwas anderes gilt, wenn der Lieferant eine Verpflichtung zum Einbau der Teile in ein Bauwerk eingegangen ist oder die Teile selbst nach den von der Rechtsprechung aufgestellten Kriterien als Bauwerk zu beurteilen sind, ist hier nicht zu klären. Rz. 17 (oben) Es mag als Wertungswiderspruch empfunden werden, dass ein Vertrag mit demjenigen, der die Errichtung des Bauwerks schuldet und dazu die Bauteile herstellt und anliefert, nach Werkvertragsrecht zu beurteilen ist, während ein Vertrag mit demjenigen, der die Bauteile herstellt und lediglich anliefert, grundsätzlich nach Kaufrecht zu beurteilen ist. Wie ist der Unterschied richtig auf Software und Systeme zu übertragen? 2. Argumentations-Ansatz aus Werkvertrag, wenn Planungsleistung überwiegt. Die Ausnahme wäre Werkvertrag, die Regel Kaufrecht. Für die Ausnahme offen gelassen -, s. Rz. 9 oben, käme es darauf an ob zusätzlich wesentliche Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten zum Gegenstand gehören. Individual- Software zu schaffen oder Standardsoftware anzupassen und zu implementieren, könnte dem Umstand entsprechen, namentlich in den Produktionsprozess einzupassender Maschinen oder Investitionsanlagen, und im Zusammenhang damit die Erbringung zusätzlicher wesentlicher Planungs-, Konstruktions-, Integrations- und Anpassungsarbeiten. 3. Argumentations-Ansatz aus ! 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 als Ausnahme hergeleitet und begründet werden können. Immerhin wird ein Regel- /Ausnahmeverhältnis angenommen. Hoeren sieht dies als Zurückrudern des III. Senats gegenüber dem VII (Silowände) (Beck-blog.de v ). Die E. v ist vom regel- /Ausnahmeverhältnis diametral (?) entgegengesetzt. VI. Was ändert sich für die Diskussion um 651 Anwendung im Hinblick 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 19

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, Projektleitung 28. Was aber bewirkt ein Planungsanteil beim Erstellungs- und Anpassungsvertrag? 29 - Bei Spiralförmigem vorgehen, Iterations-Mini-schritten, Scrum, Koop. u.ä. Momenten verliert sich die Möglichkeit der Trennung. - Mankowski 30, Europa-Rechts-konforme Auslegung lässt Sachdiskussion praktisch leerlaufen. 2. Gemischte Verträge, Auswirkungen der Theorien dazu? Aufbau der Leistungsbereiche, Schleichender Wandel im Vertragstyp, OLG München v , CR 1990, 646 OLG Düsseldorf v , NJW 1989, 2627, Installation ändert Vertragstyp OLG Köln v , CR 2003, 246; OLG Karlsruhe v , CR 2003, 95 BGH v III ZR 93/09 Videoportal Dienstvertrag bei Lieferung Standardsoftware und zusätzlich Anpassung, v.a. wenn Anpassungsaufwand relativ gering? a) Zur Anwendbarkeit von 627 Abs. 1, 628 Abs. 1 Satz 1, 3 BGB auf einen Vertrag mit dem Betreiber eines sogenannten Video-Partnerportals. Stephan-lorenz.de : Der BGH sieht hier zu recht in der werkvertraglichen Komponente (Erstellung eines Videos) eine nur untergeordnete Leistung. Es liegt also ein gemischter Vertrag vor, der seinen Schwerpunkt aber im Dienstvertragsrecht hat und daher zumindest für die Kündigungsmöglichkeit allein Dienstvertragsrecht unterliegt. 3. Vorschläge, Alternativen Vorschlag 1: Analogie zu, Vergleich mit Maschinenlieferungs- und Aufstellungsvertrag. Statt Abnahme: Test der Vertragsgemäßheit, proof of... vor Auslieferung und SLA zur Performance S.a. J. Schneider, in Schneider/von Westphalen (Hrsg.), Softwareerstellungsverträge, 2006, B. 1 ff., 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 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. 31 BGH v VIII ZR 220/97 zu Kauf mit Montageverpflichtung und Rückabwicklung 20