Software-Erstellungsverträge [2. neu bearbeitete Auflage] 9783504380397

Citation preview

Schneider · Graf von Westphalen Software-Erstellungsverträge

SoftwareErstellungsverträge herausgegeben von

Prof. Dr. Jochen Schneider Prof. Dr. Friedrich Graf von Westphalen bearbeitet von

Elke Bischof

Dr. Mathias Lejeune

Rechtsanwältin, FA IT-Recht, München

Rechtsanwalt, München

Dr. Matthias Brandi-Dohrn Rechtsanwalt, Icking bei München

Dr. Sonja Fechtner, LL.M. Rechtsanwältin, München

Prof. Klaus Gennen Rechtsanwalt, FA IT-Recht, FA ArbR, Köln

Dr.-Ing. Peter Hoppen IT-Sachverständiger, Brühl

Dr. Lorenz Kaiser Fraunhofer-Gesellschaft, München

Dr. Michael Karger Rechtsanwalt, FA IT-Recht, München

Prof. Dr. Robert Koch, LL.M. (McGill)

Stephan Peter Rechtsanwalt, Niederkassel

Dr. Helmut Redeker Rechtsanwalt, FA IT-Recht, Bonn

Prof. Dr. Jochen Schneider Rechtsanwalt, München

Prof. Dr. Günther Strunk Steuerberater, Hamburg

Prof. Dr. Friedrich Graf von Westphalen Rechtsanwalt, Köln

Michaela Witzel, LL.M. (Fordham-University) Rechtsanwältin, München

Universität Hamburg

2. Auflage

2014

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek veiZeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Verlag Dr. Otto Schmidt KG Gustav-Heinemann-Ufer 58, 50968 Köln Tel. 02 21/9 37 38-01, Fax 02 21/9 37 38-943 info®otto-schmidt.de www.otto-schmidt.de ISBN 978-3-504-56038-6

©2.014 by Verlag Dr. Otto Schmidt KG, Köln

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlages. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen nnd die Einspeicherung nnd Verarbeitung in elektronischen Systemen. Das verwendete Papier ist aus chlorfrei gebleichten Rohstoffen hergestellt, holz- und säurefrei, alterungsbeständig nnd umweltfreundlich. Einbandgestaltung: Jan P. Lichtenford, Mettmann Satz: WMTP, Birkenau Druck nnd Verarbeitung: Kösel, Krugzell Printed in Gerrnany

Vorwort zur 2. Auflage

Im IT-Bereich sind die sieben Jahre seit Erscheinen der 1. Auflage eine lange Zeit, in der sich das Rechtsgebiet erheblich gewandelt hat. Allerdings fällt dieser Wandel im Bereich der Software-Erstellung, dem „klassischen“ Projektgeschäft, noch relativ gering und gleichmäßig aus. Die 2. Auflage berücksichtigt die neuen, zusätzlichen Themenkomplexe, die im Laufe der Zeit entstanden sind, ebenso wie die Entwicklungen innerhalb der einzelnen Rubriken. Die Gliederung wurde deshalb gegenüber der 1. Auflage erweitert. Deren Grundgedanke, vom Grundsätzlichen zum Speziellen und vom mehr Theoretisch-dogmatischen zum Praktischen vorzugehen, wurde beibehalten. Einige spezielle Themen wurden neu aufgenommen und als eigene Kapitel eingerichtet, so etwa die internationalen Software-Erstellungsverträge (F). Der noch weiter zunehmenden Bedeutung des Projektmanagements wurde durch Aufnahme eines eigenen Abschnitts Rechnung getragen (H); dies gilt ebenso für handels- und steuerrechtliche Aspekte (P), Bewertung von Software (Q) und Leasing bei Softwareprojekten (R). Das Themenspektrum wurde also stark erweitert. Interessanterweise gab es nicht allzu viele dogmatische Entwicklungen, die etwa eine völlige Neuerung mit sich gebracht hätten. Dies liegt u.a. wohl daran, dass die Neigung, Ansprüche auf dem Rechtsweg zu verfolgen, gerade bei Anwendung moderner Projektmethoden eher gering ist. Das führt z.B. dazu, dass die Diskussion um Vertragstyp und vertragliche Gestaltung bei agiler Projektmethodik in der Literatur zwar durchaus behandelt wurde (und auch in diesem Werk mehrfach angesprochen ist), es jedoch dazu keine Rechtsprechung gibt. Andererseits gibt es mit der EuGH-Rechtsprechung zur Erschöpfung neue Impulse zur Beurteilung von Software, die in verschiedenen Themenkomplexen zu berücksichtigen war. Als nahezu abgeschlossen kann man die Problematik der Handhabung des § 651 BGB ansehen, weshalb insoweit Kapitel B erheblich überarbeitet wurde. Hier hat sich durch die Rechtsprechung die prinzipielle Frage weitgehend geklärt, wenn auch einige Details und die Folgen der Nichtanwendung, die in den verschiedenen einschlägigen Abschnitten, etwa D und G, behandelt werden, offengeblieben sind und deshalb vertraglich angesprochen und geregelt sein sollten. Ergänzungen betreffen etwa die Themen Open Source und Auftragsdatenverarbeitung. Insgesamt ist festzuhalten, dass die Problematik des Scheiterns von Projekten, wie sie sich in jüngerer Zeit bei einigen Großprojekten gezeigt hat, durchaus weiter aktuell und typisch ist. Umso mehr wurde versucht, den Gründen, aus denen Projekte scheitern, sowohl mittels juristischer als auch organisatorischer Fragestellungen und Lösungsvorschlägen nachzugehen. V

Vorwort zur 2. Auflage

Der Kreis der Autoren wurde entsprechend der Ergänzung der Themenbereiche und der Vertiefung ebenfalls erweitert. Dabei wurde das Anliegen der 1. Auflage, möglichst Praxisnähe und wissenschaftliche Aufarbeitung zu verbinden, ausgebaut. Die Herausgeber danken den Autoren für ihre Beiträge. Auf Verlagsseite danken wir insbesondere Frau Rechtsanwältin Dr. Julia Beck und Frau Rechtsanwältin Stefanie Fuchs-Galilea für die Betreuung. München/Köln im September 2013 Prof. Dr. Jochen Schneider

VI

Prof. Dr. Friedrich Graf von Westphalen

Aus dem Vorwort zur 1. Auflage

Unter Software-Erstellung wurde früher verstanden, dass Software neu hergestellt wird, was vor mehr als 25–30 Jahren sogar der Normalfall war, weil es den Gegensatz, nämlich „Standard-Software“, lange Zeit noch nicht gab. In der Zwischenzeit gibt es zwar den Begriff Standard-Software, jedoch werden in bestimmten Marktsegmenten diese „Standard-Software“-Versionen kaum ohne zusätzliche Anpassungen beim Kunden eingesetzt. Andererseits gibt es kaum mehr den Fall, dass Software wirklich von Beginn an „neu“ hergestellt wird. Vielmehr greifen die Softwarehäuser in ihre Bibliothek bzw. bauen auf vorhandenen Modulen auf, verwenden Klassen – je nach Programmier- und Systemwelt. Dementsprechend wird in diesem Werk auch die Anpassung der Software behandelt. Der Markt für Software-Erstellung ist nicht leicht zu erfassen, was die Umsatzhöhe und Verbreitung betrifft. Dies hängt gerade damit zusammen, dass, wie schon angedeutet, die verschiedenen Arten der Herstellung auch in verschiedene Raster der Erfassung der auf dem Markt tätigen Unternehmen fallen. Bei vielen Anbietern gehört die „Anpassung“ im Sinne von Einstellen der Parameter unter Services, wobei tatsächlich noch eine ganze Reihe von Leistungen zusätzlich ebenfalls als Service bezeichnet werden (können), so etwa Einweisung, Schulung, Installation, Migration bzw. Datenübernahme. Software-Erstellungsverträge sind – u.a. – unter zwei aktuellen Gesichtspunkten besonders interessant. Der eine Aspekt resultiert aus der Handhabung des § 651 BGB in der Literatur, der andere aus Entwicklungen im Bereich des Urheberrechts. Beide Aspekte konvergieren in dem Komplex etwas, in dem es um die Frage der Sachqualität bei Software geht. (…) Den Aufbau des Werkes bildet im Groben ein Weg von den Grundlagen – mit dem Rechtsschutz für Software einschließlich UWG nebst Durchsetzung und der Sachqualität von Software (Kap. 1), über die wesentlichen Verträge (Kap. 2) und Besonderheiten bzw. besondere Ausprägungen (Kap. 3), über die Leistungsstörungen und spezifischen, typischen Vertragsthemen (Kap. 4) bis hin zu besonderen Themen und Gestaltungen wie Escrow, öffentliche Förderung und Vergabe sowie IT-Versicherung (Kap. 5). (…) Bekanntlich scheitern Projekte im IT-Bereich zu einem relativ hohen Prozentsatz. Dies lässt sich nicht nur mit Verträgen und deren besserer Ausgestaltung vermeiden. Jedoch sind Verträge eine wichtige Voraussetzung für das Projektgelingen. Die Autoren geben deshalb jeweils die Empfehlung, wie durch vertragliche Regelungen möglichst dem Scheitern vorgebaut werVII

Aus dem Vorwort zur 1. Auflage

den kann und, so dies nicht möglich ist, doch ein geordneter Weg für den Fall des Scheiterns besteht. Der Schwerpunkt des Buches liegt also bei der Durchdringung der typischen Probleme, die Software-Erstellungsverträge bieten, und den Vorschlägen, diese Probleme praktisch zu meistern. Dazu gehören auch die Kapitel, die sich mit besonderen Ausprägungen und Gestaltungsformen (Anpassung, Pflege und SLA) befassen. Das Buch wendet sich deshalb vor allem an die Beratungspraxis. Dies spiegelt sich auch bei der Autorenschaft wider, die ganz überwiegend aus Rechtsanwälten besteht. Es gibt bei Software-Projekten eine große Kluft zwischen dem üblichen Vorgehen und den Vorgaben des Gesetzes und der Theorie. Praktische Empfehlungen tendieren demnach oft zur Kollision mit den rechtlich „sauberen“ und klar einzuordenden Regeln. Das Buch versucht, diese Kluft zu überbrücken und dennoch die Kollision zu vermeiden. Dennoch bleibt es bei der Bandbreite der Autorenschaft nicht aus, dass die Tendenzen bzw. Haltungen divergieren. Dies kann für den Leser eine Anregung sein, sich seine eigene Meinung zu bilden. Umso mehr sind die Autoren und Herausgeber an Anregungen und konstruktiver Kritik interessiert. Deren Ausübung soll durch die am Ende des Werkes beigeheftete Hinweiskarte erleichtert werden. Eine größere Zahl von Personen hat bei der Verfertigung der Skripten, der Korrektur u.Ä. mitgewirkt. Auf deren Nennung wird verzichtet, gleichwohl ein kräftiger Dank pauschal ausgesprochen, auch an die Kollegen im Verlag. München/Köln im Mai 2006 Die Herausgeber Prof. Dr. Jochen Schneider

VIII

Prof. Dr. Friedrich Graf von Westphalen

Inhaltsübersicht

Seite

Vorworte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

V

Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . .

XI

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

XV

1. Kapitel Grundlagen A. Schutz und Realisierung der Software (Karger/M. Brandi-Dohrn/ Fechtner) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

B. Sachqualität der Software und § 651 BGB (Schneider) . . . . . . .

155

2. Kapitel Verträge C. Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft (Schneider) . . . . . . . . . . . . . . . . . . . . . . . .

193

D. Realisierung (Kauf-/Werkvertrag) (Redeker) . . . . . . . . . . . . .

319

E. Softwareentwicklung durch Dritte (Gennen/Karger/ M. Brandi-Dohrn) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

453

F. Internationale Softwareerstellungsverträge (Lejeune) . . . . . . . .

575

3. Kapitel Sonderregelungen G. Verträge zur Anpassung, Einführung und Implementierung von Standardsoftware (Witzel) . . . . . . . . . . . . . . . . . . . . .

601

H. Projektmanagement (Witzel) . . . . . . . . . . . . . . . . . . . . . .

783

I. Softwarepflege inklusive Service-Level-Agreement (Peter) . . . . .

849

4. Kapitel Leistungsstörungen J. Individualvereinbarung (Graf von Westphalen) . . . . . . . . . . .

973

K. Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln (Graf von Westphalen) . . . . . . . . . . . . . . . . . . . . . . . . . .

1011

IX

Inhaltsübersicht

5. Kapitel Einzelprobleme

Seite

L. Hinterlegung von Software, Escrow (Schneider) . . . . . . . . . .

1047

M. Öffentliche Förderung von Forschung und Entwicklung (Kaiser)

1101

N. Öffentliche Vergabe von IT-Leistungen (Bischof) . . . . . . . . .

1139

O. Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software (Koch) . . . . . . . . . . . . . . . . . . . . . . . . . .

1261

P. Handels- und steuerrechtliche Aspekte von Software (Strunk) .

1361

Q. Bewertung von Software, Due Diligence, Compliance (Hoppen)

1385

R. Leasing bei Softwareerstellungsprojekten (IT-Projektleasing) (Gennen) . . . . . . . . . . . . . . . . . . . . . .

1471

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1499

X

Abkürzungsverzeichnis

ABE ABl. AcP AG AGB AHB AktG AMB ArbEG ArbGG ARGE ASP AÜG BAG BAT BauR BB BBiG BBR BDSG BetrVG BGHZ BHO BHV-IT BMBF BSI BVB

CI CISG

Allgemeine Bedingungen für die Elektronikversicherung Amtsblatt Archiv für die christliche Praxis (Zeitschrift) Amtsgericht; Aktiengesellschaft; Die Aktiengesellschaft (Zeitschrift) Allgemeine Geschäftsbedingung(en) Allgemeine Versicherungsbedingungen für die Haftpflichtversicherung Aktiengesetz Allgemeine Maschinenversicherungs-Bedingungen Arbeitnehmererfindergesetz Arbeitsgerichtsgesetz Arbeitsgemeinschaft Application Service Providing Arbeitnehmerüberlassungsgesetz Bundesarbeitsgericht Bundesangestelltentarif Baurecht (Zeitschrift) Betriebs-Berater (Zeitschrift) Berufsbildungsgesetz Software Besondere Bedingungen und Risikobeschreibungen für die Haftpflichtversicherung von Softwarehäusern Bundesdatenschutzgesetz Betriebsverfassungsgesetz Entscheidungssammlung des Bundesgerichtshof in Zivilsachen Bundeshaushaltsordnung Betriebshaftspflichtversicherung für die Nutzer vom Internet-Technologie Bundesministerium für Bildung und Forschung und Technologie Bundesamt für Sicherheit in der Informationstechnik BUrlG Bundesurlaubsgesetz Besondere Vertragsbedingungen der öffentlichen Hand BWB Bundesamt für Wehrtechnik und Beschaffung Computerrecht Intern (Zeitschrift) Convention on International Sales of Goods

XI

Abkürzungsverzeichnis

CR CRI

Computer und Recht (Zeitschrift) Computer Law Review International (Zeitschrift)

DB DFG DGRI DPMA DuD DWiR

Der Betrieb (Zeitschrift) Deutsche Forschungsgesellschaft Deutsche Gesellschaft für Recht und Informatik e.V. Deutsches Patent- und Markenamt Datenschutz und Datensicherheit (Zeitschrift) Deutsche Zeitschrift für Wirtschaftsrecht (Zeitschrift)

EFZG EGKS EPA EPÜ ERP ESA EStG Eu-RL EuZW

EWR

Entgeltfortzahlungsgesetz Europäische Gemeinschaft für Kohle und Stahl Europäisches Patentamt Europäisches Patentübereinkommen Enterprise Resource Planning European Space Agency Einkommenssteuergesetz Europäische Richtlinie Europäische Zeitschrift für Wirtschaftsrecht (Zeitschrift) EVB-IT Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen Europäischer Wirtschaftsraum

FhG FS FuE

Fraunhofer-Gesellschaft Festschrift Forschung und Entwicklung

GD GDV

GPSG GPÜ GRUR GU GVO GWB

Generaldirektion Gesamtverband der Deutschen Versicherungswirtschaft GebO Gebührenordnung Gebrauchsmustergesetz Gewerbeordnung Gesetz betreffend die Gesellschaften mit beschränkter Haftung Geräte- und Produktsicherheitsgesetz Gemeinschaftspatentübereinkommen Gewerblicher Rechtsschutz und Urheberrecht (Zeitschrift) Gemeinschaftsunternehmen Gruppenfreistellungsverordnung Gesetz gegen Wettbewerbsbeschränkungen

HGB HGrG HintO

Handelsgesetzbuch Gesetz über die Grundsätze des Haushaltsrechts Hinterlegungsordnung

GebrMG GewO GmbHG

XII

Abkürzungsverzeichnis

HRG HTML

Hochschulrahmengesetz Hypertext Markup Language

InSO IntPatÜG ITIL ITRB

Insolvenzordnung Gesetz über internationale Patentübereinkommen IT Infrastructure Library Der IT-Rechts-Berater (Zeitschrift)

JZ

Juristenzeitung (Zeitschrift)

K&R KO KonTraG KSchG

Kommunikation & Recht (Zeitschrift) Konkursordnung Gesetz zur Kontrolle und Transparenz im Unternehmensbereich Kündigungsschutzgesetz

LG LHO LOI

Landgericht Landeshaushaltsordnung Letter of Internet

MDR MMR MOU MPG MuSchG

Monatsschrift für Deutsches Recht (Zeitschrift) Multimedia und Recht (Zeitschrift) Memorandum of Unterstanding Max-Planck-Gesellschaft Mutterschutzgesetz

NachwG

NVersZ NZA

Gesetz über den Nachweis der für ein Arbeitsverhältniss geltenden wesentlichen Bedingungen Neue Juristische Wochenschrift (Zeitschrift) Neubestimmungen für Zuwendung auf Kostenbasis des BMBF Neue Zeitschrift für Versicherungsrecht (Zeitschrift) Neue Zeitschrift für Arbeitsrecht (Zeitschrift)

OEM OHG OLG OSS ÖOGH

Original Equipment Manufacturer Offene Handelsgesellschaft Oberlandesgericht Open Source Software Österreichischer Obergerichtshof

PatG PCT PHI

Patentgesetz Patent Cooperation Treaty Produkt- und Umwelthaftpflicht international (Zeitschrift)

NJW NKBF

XIII

Abkürzungsverzeichnis

PPP ProdHaftG PVÜ

Public Private Partnership Produkthaftungsgesetz Pariser Verbandsübereinkunft

Rl.

Richtlinie

SaaS SGB SLA SOX

Software as a Service Sozialgesetzbuch Service Level Agreement Sarbanes-Oxley Act

TRIPS

Agreement on Trade Related Aspects of Intellectual Property Tarifvertragsgesetz Teilzeitbeschäftigungsgesetz

TVG TzBfG UfAB UmweltHG UrhG UWG VerbrGKRL VerglO VerlG VersR VgV VOF VOL/A

Unterlage für die Ausschreibung und Bewertung von ITLeistungen Umwelthaftungsgesetz Urheberrechtsgesetz Gesetz gegen den unlauteren Wettbewerb

VV VVG VwVfG

Verbrauchergüterkauf-Richtlinie Vergleichsordnung Verlagsgesetz Versicherungsrecht (Zeitschrift) Vergabeverordnung Verdingungsordnung für freiberufliche Leistungen Verdingungsordnung für Leistungen, ausgenommen Bauleistungen, Teil A Verdingungsordnung für Leistungen, ausgenommen Bauleistungen, Teil B Verwaltungsvorschrift Gesetz über den Versicherungsvertrag Verwaltungsverfahrensgesetz

WIPO WM WRP WTO

World Intellectual Property Organization Wertpapier-Mitteilungen (Zeitschrift) Wettbewerb in Recht und Praxis (Zeitschrift) World Trade Organisation

ZIP ZVB

Zeitschrift für Wirtschaftsrecht (Zeitschrift) Zusätzliche Vertragsbedingungen

VOL/B

XIV

Literaturverzeichnis

Altenburg/Bengelsdorf/Boewer et al., Münchener Anwaltshandbuch Arbeitsrecht, 3. Aufl. 2012 Auer-Reinsdorff/Conrad (Hrsg.), Beck’sches Mandatshandbuch IT-Recht, 2011 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 2009 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008 Balzert, Lehrbuch Grundlagen der Informatik, 2005 Balzert, Lehrbuch der Softwaretechnik – Softwareentwicklung, 2001 Balzert/Heide, Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML2, 2005 Bamberger/Roth, Kommentar zum Bürgerlichen Gesetzbuch, 3. Aufl. 2012 Bartenbach, Aktuelle Probleme des gewerblichen Rechtsschutzes, 1998 Bartenbach/Volz, Arbeitnehmererfindergesetz, 5. Aufl. 2012 Bartenbach/Volz, Arbeitnehmererfindervergütung, 3. Aufl. 2009 Bechtold, Kartellgesetz: GWB, 6. Aufl. 2010 Benkard, Patentgesetz, Gebrauchsmustergesetz, 10. Aufl. 2006 Benkard, Europäisches Patentübereinkommen, 2. Aufl. 2012 Berliner Vertrags Office (Stand 2011) Bernhard/Lewandowski/Mann, 2. Aufl. 2001

Service-Level-Management

in

der

IT,

Boehm, Software Engineering Economics, 1981 Boehm/Abts/Brown et al., Software Cost Estimation with Cocomo II, 1999 Boehm/Clark/Horowitz/Westland, The COCOMO 2.0 Software Cost Estimation Model, 1995 Bräutigam, IT-Outsourcing, 2. Aufl. 2009 Bundesministerium für Bildung und Forschung (Hrsg.), Bildung und Forschung in Zahlen, 2011 Bundesministerium für Bildung und Forschung (Hrsg.), Bundesbericht Forschung und Innovation, 2010 Bundschuh/Fabry, Aufwandsschätzung von IT-Projekten, 2004 Dietrich/Hanau/Schaub et al., Erfurter Kommentar zum Arbeitsrecht, 13. Aufl. 2013

XV

Literaturverzeichnis

Eckert, IT-Sicherheit, 2009 Emmerich, Kartellrecht, 12. Aufl. 2012 Erman, BGB, 13. Aufl. 2011 Expertenkommission Forschung und Innovation (Hrsg.), Föderalismus und Forschungs- und Innovationspolitik. Studien zum deutschen Innovationssystem Nr. 11, 2011 Expertenkommission Forschung und Innovation (Hrsg.), Research, Innovation and Technological Performance in Germany, 2011 Flämig/Kimminich/Krüger, Handbuch des Wissenschaftsrechts, 2. Aufl. 1996 Gamma/Helm/Johnson/Vlissides, Design Patterns – Elements of Reusable Object-Oriented Software, 1995 Garmus/Herron, Function Point Analysis – Measurement Practices for Successful Software Projects, 2000 Geiger/Khan/Kotzur, EUV/AEUV, 5. Aufl. 2010 Grabitz/Hilf, Das Recht der Europäischen Union (Stand Oktober 2009) Graf von Westphalen (Hrsg.), Der Leasingvertrag, 6. Aufl. 2008 Graf von Westphalen (Hrsg.), Vertragsrecht und AGB-Klauselwerke, 32. Aufl. 2013 Groß/Rohrer, Lizenzgebühren, 3. Aufl. 2012 Hanau/Röller/Macher/Schlegel, Personalrecht im Wandel – Festschrift für Wolfdieter Küttner zum 70. Geburtstag, 2006 Heidenhain (Hrsg.), Handbuch des Europäischen Beihilfenrechts, 2003 Heinrich, Die rechtliche Systematik der Forschungsförderung in Deutschland und den Europäischen Gemeinschaften unter Beachtung von Wissenschaftsfreiheit und Wettbewerbsrecht, Kölner Schriften zum Internationalen und Europäischen Recht Bd. 6, 2003 Hellebrand/Himmelmann, Lizenzsätze für technische Erfindungen, 3. Aufl. 2013 Honsell/Vogt/Wiegand (Hrsg.), Obligationenrecht I, 4. Aufl. 2007 Immenga/Mestmäcker, Wettbewerbsrecht, 5. Aufl. 2012 Jaeger/Metzger, Open Source Software, 3. Aufl. 2011 Jayme/Hausmann, Internationales Privat- und Verfahrensrecht, 15. Aufl. 2010 Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 2008 Juncker/Benecke, Computerrecht, 3. Aufl. 2003 XVI

Literaturverzeichnis

Karger, Beweisermittlung im deutschen und U.S.-amerikanischen Softwareverletzungsprozess, 1996 Kent, eXtreme Programming Explained, 2000 Kernighan/Plauger, The Elements of Programming Style, 1978 Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Loseblatt (Stand Mai 2012) Koch, IT-Projektrecht, 2007 Köhler/Bornkamm, Gesetz gegen den unlauteren Wettbewerb, 30. Aufl. 2012 Krämer/Schmidt, Zuwendungsrecht – Zuwendungspraxis (Stand 2011) Kühnen, Handbuch der Patentverletzung, 6. Aufl. 2013 Kulartz/Steding, IT-Leistungen, Fehlerfreie Ausschreibung und rechtssichere Vertragsinhalte, 2002 Le Tourneau, Droit de la Responsabilité et des Contrats, 7. Aufl. 2008 Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, 2. Aufl. 1993 Lehmann/Meents, Handbuch des Fachanwalts Informationstechnologierecht, 2. Aufl. 2011 Liebscher, Handbuch der EU-Gruppenfreistellungsverordnungen, 2. Aufl. 2012 Loewenheim, Kartellrecht, 2. Aufl. 2009 Malaurie/Aynès/Gautier, Les contrats speciaux, 4. Edition, 2009 Marly, Praxishandbuch Softwarerecht, 5. Aufl. 2009 Martin, Clean Code – A Handbook of Agile Software Craftsmanship, 2008 Meusel, Außeruniversitäre Forschung im Wissenschaftsrecht, 2. Aufl. 1999 Möhring/Nicolini, UrhG, 2. Aufl. 2000 Moritz/Dreier, Rechts-Handbuch zum E-Commerce, 2. Aufl. 2005 Moritz/Tybussek, Computersoftware, 2. Aufl. 1992 Münchener Kommentar zum BGB, 6. Aufl. ab 2012 Palandt, Bürgerliches Gesetzbuch, 72. Aufl. 2013 Redeker (Hrsg.), Handbuch der IT-Verträge, Loseblatt (Stand Juli 2013) Redeker, IT-Recht, 5. Aufl. 2012 Richardi/Wlotzke/Wißmann/Oetker, Münchener Handbuch zum Arbeitsrecht Bd. 1 und 2, 3. Aufl. 2009 Schlechtriem/Schwenzer, Kommentar zum Einheitlichen U3-Kaufrecht, 5. Aufl. 2008 XVII

Literaturverzeichnis

Schneider, Handbuch des EDV-Rechts, 4. Aufl. 2009 Schricker/Loewenheim, Urheberrecht, 4. Aufl. 2010 Schulte, Patentgesetz mit Europäischem Patentübereinkommen, 9. Aufl. 2013 Schüren, Arbeitnehmerüberlassungsgesetz, 4. Aufl. 2010 Schuster, Vertragshandbuch Telemedia, 2001 Schwarz/Kruspig, Computerimplementierte Erfindungen, Patentschutz von Software, 2011 Sneed, Software-Management, 1986 Sneed, Software-Entwicklungsmethodik, 1986 Sneed, Software-Projektkalkulation, 2005 Stauder/Singer, Europäisches Patentübereinkommen, 6. Aufl. 2013 Staudinger, BGB, 13. Aufl. ab 1999 Trute, Die Forschung zwischen grundrechtlicher Freiheit und staatlicher Institutionalisierung. Das Wissenschaftsrecht als Recht kooperativer Verwaltungsvorgänge, 1994 Ullrich/Lejeune (Hrsg.), Der Internationale Softwarevertrag, 2. Aufl. 2006 Wandtke/Bullinger, Praxiskommentar zum Urheberrecht, 4. Aufl. 2013 Weith/Wegener/Ehrlich, Grundzüge der Exportkontrolle, 2006 Weitnauer, Handbuch Venture Capital, 4. Aufl. 2011 Wiedemann, Lizenzen und Lizenzverträge in der Insolvenz, 2006 Wurzer/Kaiser (Hrsg.), 2. Aufl. 2011

Handbuch

Internationaler

Know-how-Schutz,

Zahrnt, Computervertragsrecht in Rechtsprechung und Praxis, 2004 Zahrnt, DV-Rechtsprechung, Bd. 3, 1989 Zahrnt, Entscheidungen zum Computerrecht-ECR, Bd. I und II, 2002 Zöller, ZPO, 30. Aufl. 2014

XVIII

1. Kapitel Grundlagen A. Schutz und Realisierung der Software Rz. I. Urheberrecht (Karger) . . . . . . . . 1. Arbeitsergebnisse bei Softwareerstellung . . . . . . . . . . . . . . . a) Phasen der Programmerstellung . . . . . . . . . . . . . . . . . b) Einzelne Arbeitsergebnisse . 2. Urheberrechtsschutz gemäß § 69a UrhG . . . . . . . . . . . . . . . . . . a) Computerprogramme . . . . . . aa) Maschinen-, Objektund Quellcode . . . . . . . . . bb) Funktionalität des Computerprogramms, Programmiersprache, Dateiformat. . . . . . . . . . . . cc) Grafische Benutzeroberflächen . . . . . . . . . . . . dd) Schnittstellen . . . . . . . . . . ee) Websites . . . . . . . . . . . . . . . ff) Multimediawerke . . . . . . gg) Datenbanken und Daten hh) Objektorientierte Computerprogramme. . . . . . . . ii) Customizing . . . . . . . . . . . b) Entwurfsmaterial . . . . . . . . . . aa) Pflichtenheft . . . . . . . . . . . bb) Konzeptionelle Vorgaben . . . . . . . . . . . . . . cc) Handbücher und Begleitmaterial . . . . . . . . . . . . . . . c) Kein Schutz von Ideen und Grundsätzen . . . . . . . . . . . . . . aa) Problemstellung . . . . . . . . bb) Geschützte Ausdrucksformen . . . . . . . . . . . . . . . . cc) Ungeschützte Ideen und Grundsätze; Frage der Schutzfähigkeit von Algorithmen . . . . . . . . . . . d) Schutzvoraussetzungen der eigenen geistigen Schöpfung und der Individualität . . . . . .

2 6 6 7 8 9 10

11 12 13 17 19 20 21 22 23 24 26 27 28 28 32

33

Rz. 3. Urheberrechtlicher Schutz gem. § 2 UrhG . . . . . . . . . . . . . . . 4. Schutz als Datenbankwerk bzw. als Datenbank . . . . . . . . . . . a) Urheberrechtlicher Schutz als Datenbankwerk. . . . . . . . . b) Leistungsschutz als Datenbank . . . . . . . . . . . . . . . . 5. Übersicht zur Schutzfähigkeit einzelner Arbeitsergebnisse. . . . 6. Urheberschaft bzw. Rechtsinhaberschaft . . . . . . . . . . . . . . . . a) Urheberrecht . . . . . . . . . . . . . . aa) Einzelurheber . . . . . . . . . . bb) Miturheberschaft . . . . . . . (1) Voraussetzungen der Miturheberschaft . . . . (2) Identifizierung der Beiträge . . . . . . . . . . . . . (3) Gesamthandsgemeinschaft . . . . . . . . . . . . . . . (4) Einwilligungserfordernis. . . . . . . . . . . . . . . (5) Verteilung der Erträgnisse. . . . . . . . . . . . . . . . (6) Anteilsverzicht . . . . . . b) Datenbankurheberrecht und Datenbankherstellerrecht . . . 7. Rechte aus dem Urheberrecht. . a) Urheberpersönlichkeitsrechte . . . . . . . . . . . . . . . . . . . . . aa) Veröffentlichungsrecht . . bb) Recht auf Anerkennung der Urheberschaft . . . . . . . cc) Recht auf Urhebernennung . . . . . . . . . . . . . . . dd) Entstellungsverbot . . . . . . ee) Änderungsverbot . . . . . . . ff) Rückrufrecht . . . . . . . . . . . gg) Zugangsrecht . . . . . . . . . . . b) Verwertungsrechte . . . . . . . . .

42 46 47 49 51 52 53 53 54 55 59 60 62 64 65 67 68 70 73 74 75 76 77 78 79 80

36

Karger

1

A

2

Grundlagen Rz.

Rz.

aa) Vervielfältigungsrecht. . . 81 bb) Umarbeitungsrecht . . . . . 82 cc) Verbreitungsrecht . . . . . . 86 (1) Verbreitung . . . . . . . . . 87 (2) Erschöpfung des Verbreitungsrechts . . . . . . 88 dd) Recht der öffentlichen Wiedergabe und Recht der öffentlichen Zugänglichmachung . . . . . . . . . . . 91 c) Zustimmungsfreie Maßnahmen, §§ 69d und 69e UrhG . 95 aa) Relevanz für die Softwareerstellung . . . . . . . . . 96 bb) Zustimmungsfreie Maßnahmen gem. § 69d UrhG . . . . . . . . . . . . . . . . . . 97 (1) Berechtigter Nutzer . . 98 (2) Vervielfältigung bzw. Umarbeitung . . . . . . . . 99 (3) Sicherungskopie . . . . . 101 (4) Beobachtung, Untersuchung und Testen . 102 cc) Dekompilierung gem. § 69e UrhG . . . . . . . . . . . . 106 (1) Dekompilierung . . . . . 108 (2) Berechtigter . . . . . . . . . 109 (3) Interoperabilität eines unabhängig geschaffenen Programms mit anderen Programmen . . . . . . . . 110 (4) Unerlässlichkeit der Dekompilierung . . . . . 113 (5) Verwendungsbeschränkungen . . . . . . . 114 8. Rechtseinräumung an den Arbeitsergebnissen . . . . . . . . . . . 115 a) Verpflichtungs- und Verfügungsgeschäft . . . . . . . . . . . 116 aa) Verpflichtungsgeschäft . . 117 (1) Werkvertrag bzw. „Werklieferungsvertrag“ i.S.v. § 651 BGB 118 (2) Dienstvertrag . . . . . . . 121 (3) Arbeitsvertrag und öffentlich-rechtliches Dienstverhältnis . . . . 122 (4) Gesellschaftsvertrag . 123 (5) Rechtsverschaffungspflicht . . . . . . . . . . . . . . 124

bb) Verfügungsgeschäft . . . . . . . 126 (1) Trennungsgrundsatz . . . 127 (2) Entbehrlichkeit einer rechtsgeschäftlichen Verfügung . . . . . . . . . . . . . 131 b) Zeitpunkt der Rechtseinräumung . . . . . . . . . . . . . . . . . 134 aa) Ausdrückliche Vereinbarung . . . . . . . . . . . . . . . . . . . 135 (1) Vertragsabschluss . . . . . . 137 (2) Entstehung der Software . . . . . . . . . . . . . . 139 (3) Übergabe bzw. Ablieferung . . . . . . . . . . . 140 (4) Abnahme, Recht zur Testnutzung und zur Funktionsprüfung. . . . . . 141 (5) Vollständige Bezahlung der Vergütung, Rechtsvorbehalt . . . . . . . . . . . . . 143 (6) Auslegung von „Eigentumsvorbehalts-Klauseln“ . . . . . . . . . . . . . . . . . 145 bb) Fehlen einer ausdrücklichen Vereinbarung. . . . . . . 147 c) Umfang der Rechtseinräumung . . . . . . . . . . . . . . . . . . . . . . . 151 aa) Urhebervertragsrechtliche Grundsätze. . . . . . . . . . . . . . . 151 bb) Ausdrückliche Vereinbarung . . . . . . . . . . . . . . . . . . . 154 (1) Pauschale Rechtseinräumung . . . . . . . . . . . 155 (2) Buy-Out-Vertrag . . . . . . . 156 cc) Fehlen einer ausdrücklichen Vereinbarung. . . . . . . 157 (1) Zweckübertragungsgrundsatz . . . . . . . . . . . . . 158 (2) Ausnahmen vom Zweckübertragungsgrundsatz . . . . . . . . . . . . . 159 (3) Ermittlung des Vertragszwecks . . . . . . . . . . . 160 (4) Erstellung zum Zwecke der Weitervermarktung . . . . . . . . . . 166 (5) Erstellung zum Zwecke der eigenen Nutzung . . . 168 (6) Nutzungsrechte am Quellcode . . . . . . . . . . . . . 169

Karger

A

Schutz und Realisierung der Software Rz.

Rz.

9. Vergütung . . . . . . . . . . . . . . . . . . . 173 a) Anspruch auf angemessene Vergütung . . . . . . . . . . . . . . . . . 180 b) Anspruch auf weitere Beteiligung (§ 32a UrhG) . . . . . . 188 aa) Anspruch gegen den Lizenznehmer . . . . . . . . . . 188 bb) Anspruch gegen einen Dritten . . . . . . . . . . . . . . . . 193 10. Rechtsfolgen bei Urheberrechtsverletzungen . . . . . . . . . . . 195

cc) Verhältnis zu anderen Fallgruppen unlauterer Wettbewerbshandlungen . . . . . . . 254 dd) Verhältnis zum Sonderrechtsschutz . . . . . . . . . . . . . 255 ee) Unterschiede zum Schutz durch das Urheberrecht. . . . 258 ff) Praxisrelevanz des ergänzenden wettbewerbsrechtlichen Leistungsschutzes . . 259 b) Voraussetzungen des ergänzenden wettbewerbsrechtlichen Leistungsschutzes . . . . . 263 aa) Wechselwirkung zwischen den einzelnen Kriterien. . . . 264 bb) Wettbewerbshandlung mit Mitbewerberbezug . . . . . . . . 265 (1) Wettbewerbshandlung. . 265 (2) Mitbewerberbezug . . . . . 270 cc) Wettbewerbliche Eigenart der nachgeahmten Ware bzw. Dienstleistung . . . . . . . 271 (1) Konkrete Gestaltung . . . 272 (2) Wettbewerbliche Eigenart. . . . . . . . . . . . . . . 273 dd) Nachahmung . . . . . . . . . . . . . 276 (1) Unmittelbare Leistungsübernahme. . . . . . . 277 (2) Fast identische Leistungsübernahme. . . . . . . 279 (3) Nachschaffende Leistungsübernahme. . . . . . . 280 ee) Besondere, die Unlauterkeit begründende Umstände . . . . . . . . . . . . . . . . . . . 283 (1) Behinderung durch Vereitelung der Amortisation des Entwicklungsaufwands . . . . . . . . . . . . . 285 (2) Behinderung durch die Beseitigung von Schutzmechanismen . . . . . . . . . 287 (3) Herkunftstäuschung . . . 289 (4) Verwendung unredlich erlangter Kenntnisse und Unterlagen . . . . . . . . 290 ff) Schutzdauer . . . . . . . . . . . . . . 291 c) Rechtsfolgen eines Wettbewerbsverstoßes . . . . . . . . . . . . 292

II. Patentrecht (M. BrandiDohrn) . . . . . . . . . . . . . . . . . . . . . . 202 1. Überblick über das Schutzsystem . . . . . . . . . . . . . . . . . . . . . . 202 a) Nationales Patentrecht Deutschland. . . . . . . . . . . . . . . 206 aa) Erteilung . . . . . . . . . . . . . . 206 bb) Einspruch. . . . . . . . . . . . . . 209 cc) Verletzung . . . . . . . . . . . . . 210 dd) Nichtigkeit . . . . . . . . . . . . 212 b) Europäische Patente. . . . . . . . 213 aa) Erteilung . . . . . . . . . . . . . . 214 bb) Einspruch. . . . . . . . . . . . . . 218 cc) Verletzung . . . . . . . . . . . . . 219 dd) Nichtigkeit . . . . . . . . . . . . 221 c) Patent Cooperation Treaty (PCT) . . . . . . . . . . . . . . . . . . . . . 222 2. Technischer Charakter . . . . . . . 225 a) Ältere BGH-Rechtsprechung. . . . . . . . . . . . . . . . . . . . . 225 b) Europäisches Patentamt . . . . 226 c) Neuere Rechtsprechung des BGH . . . . . . . . . . . . . . . . . . 232 3. Neuheit und Erfindungshöhe . . . . . . . . . . . . . . . . . . . . . . . . 235 a) Neuheit . . . . . . . . . . . . . . . . . . . 236 b) Erfindungshöhe . . . . . . . . . . . . 237 c) Zwischenergebnis. . . . . . . . . . 238 4. Ausland, insbesondere USA . . . 239 5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . 243 III. Wettbewerbsrecht (Karger) . . . . 247 1. Ergänzender wettbewerbsrechtlicher Leistungsschutz vor Nachahmung. . . . . . . . . . . . . 248 a) Allgemeines . . . . . . . . . . . . . . . 248 aa) Schutz vor unlauterer Nachahmung . . . . . . . . . . 248 bb) Gesetzliche Regelung . . . 250

Karger

3

A Rz. 1

Grundlagen Rz.

Rz.

2. Geheimnisschutz . . . . . . . . . . . . 296 a) Allgemeines . . . . . . . . . . . . . . . 296 b) Verrat von Geschäfts- und Betriebsgeheimnissen . . . . . . 299 aa) Geschäfts- oder Betriebsgeheimnis . . . . . . . . 300 (1) Begriff . . . . . . . . . . . . . . 300 (2) Unternehmensbezug, Geheimhaltungsinteresse und -wille. . . . . . 304 (3) Keine Offenkundigkeit . . . . . . . . . . . . . . . . 307 bb) Geheimnisverrat . . . . . . . 312 cc) Betriebsspionage. . . . . . . . 317 dd) Geheimnisverwertung . . 322 c) Vorlagenfreibeuterei. . . . . . . . 324 d) Rechtsfolgen eines Verstoßes . . . . . . . . . . . . . . . . . 325

g) Weitergabe der Lizenz . . . . . . 342 h) Keine Beschränkung auf ein bestimmtes Produktpaket . . . 343 i) Keine Einschränkung anderer Software . . . . . . . . . . . 344 Abgrenzung . . . . . . . . . . . . . . . . . . 345 a) Freeware . . . . . . . . . . . . . . . . . . 346 b) Public Domain-Software . . . . 347 c) Shareware . . . . . . . . . . . . . . . . . 348 d) Shared Source-Software . . . . . 349 „Copyleft“/„Non-Copyleft“-Software . . . . . . . . . . . . . . . . 350 Problemstellung: Rechtseinräumung. . . . . . . . . . . . . . . . . . . . . 354 a) Lizenzbedingungen ohne Copyleft-Effekt . . . . . . . . . . . . 354 b) Lizenzbedingungen mit Copyleft-Effekt . . . . . . . . . . . . 356 c) OSS-Code in proprietären Projekten . . . . . . . . . . . . . . . . . . 366 Problemstellung: Vertragstypen, Gewährleistung, Haftung . . . . . . . . . . . . . . . . . . . . . 368 Problemstellung: Patentrecht . . 372 Fazit . . . . . . . . . . . . . . . . . . . . . . . . 375

IV. Open Source-Software (Fechtner) . . . . . . . . . . . . . . . . . . . 330 1. Bedeutung von Open SourceSoftware bei Softwareerstellung und bei Softwareanpassung . . . . . . . . . . . . . . . . . . . . . 331 2. Begriff der „Open SourceSoftware“ . . . . . . . . . . . . . . . . . . . 335 a) Freie Weitergabe . . . . . . . . . . . 336 b) Freier Zugang zum Quellcode . . . . . . . . . . . . . . . . . 337 c) Abgeleitete Software . . . . . . . 338 d) Unversehrtheit des Quellcodes des Autors . . . . . . . . . . . 339 e) Keine Diskriminierung von Personen und Gruppen . . . . . 340 f) Keine Einschränkung bezüglich des Einsatzfeldes. . . . . . . 341

1

3.

4. 5.

6.

7. 8.

V. Durchsetzung (M. BrandiDohrn) . . . . . . . . . . . . . . . . . . . . . . 376 1. Das Durchsetzungsproblem . . . 376 2. Ausländisches Recht. . . . . . . . . . 378 3. Deutsches Recht bis 2002 . . . . . 382 4. Wandlungen im deutschen Recht ab 2002 . . . . . . . . . . . . . . . . 384 5. Durchsetzungsrichtlinie und Düsseldorfer Praxis . . . . . . . . . . . 386 6. Durchsetzung am Markt? . . . . . 398

Der Schutz von Computerprogrammen wird von unterschiedlichen materiell-rechtlichen Schutzsystemen gewährleistet, wobei dem Urheberrecht, dem Wettbewerbsrecht und dem Patentrecht in der Praxis die größte Bedeutung zukommen. Ergänzend zum Sonderrechtsschutz durch Urheber- und Patentrecht und zum Leistungsschutz durch das Wettbewerbsrecht kommt ein rechtlicher Schutz von Computersoftware u.a. durch das Markenrecht1,

1 Redeker, IT-Recht, Rz. 162 ff.; Harte-Bavendamm, in: Kilian/Heussen, Computerrechtshandbuch Abschnitt 56; Dreier, in: Dreier/Schulze, § 69a Rz. 10.

4

Karger

Schutz und Realisierung der Software

Rz. 4 A

das Vertragsrecht1, das Deliktsrecht2, sowie durch strafrechtliche Vorschriften3 in Betracht.

I. Urheberrecht Softwareerstellung ist ein komplexer und in zahlreiche Teilschritte zer- 2 fallender Prozess, in dem eine Vielzahl von Arbeitsergebnissen geschaffen wird. Im Zentrum steht das zu entwickelnde Computerprogramm. Daneben entstehen aber auch zahlreiche weitere Arbeitsergebnisse, die für die Konzipierung, das Verständnis und die Verwendung der Programme von großer Bedeutung sind, z.B. Konzepte, das Entwurfsmaterial, Dokumentationen und Handbücher. Die einzelnen Arbeitsergebnisse unterfallen unterschiedlichen urheberrechtlichen Regelungen. Die Sonderbestimmungen der §§ 69a ff. UrhG gelten – was oft verkannt wird – nicht für „Software“ schlechthin, sondern nur für Computerprogramme i.S.v. § 69a Abs. 1 UrhG. Dies sind „Programme in jeder Gestalt, einschließlich des Entwurfsmaterials“. Der Begriff der Software ist weiter zu verstehen als der des Computerprogramms. Er erfasst neben dem Programm und dem Entwurfsmaterial auch das Begleitmaterial und die Programmbeschreibung4. Für die Mehrzahl der Materialien, die nicht den Computerprogrammen und dem Entwurfsmaterial zuzuordnen sind, beurteilt sich die Schutzfähigkeit nach § 2 Abs. 1 Nr. 1 bzw. Nr. 7, § 2 Abs. 2 UrhG. Für Datenbankwerke bzw. Datenbanken kommt ein Schutz nach § 4 UrhG bzw. nach §§ 87a ff. UrhG in Betracht.

3

Die Anforderungen an die Schutzfähigkeit liegen für Computerprogramme 4 und das Entwurfsmaterial i.S.v. § 69a UrhG erheblich niedriger als die Anforderungen an andere Werke i.S.v. § 2 Abs. 1 UrhG, insbesondere an Schriftwerke bzw. Darstellungen wissenschaftlicher oder technischer Art gem. § 2 Abs. 1 Nr. 1 bzw. Nr. 7 UrhG. Für den Schutz von Computerprogrammen ist es gemäß § 69a Abs. 3 UrhG ausreichend, wenn diese „individuelle Werke in dem Sinne darstellen, dass sie ein Ergebnis einer eigenen geistigen Schöpfung ihres Urhebers sind.“ Es ist nicht erforderlich, dass eine besondere Schöpfungshöhe erreicht wird. Während damit Computerprogramme in aller Regel urheberrechtlichen Schutz genießen, müssen Schriftwerke bzw. 1 Redeker, IT-Recht, Rz. 203; Pagenberg/Geissler, Der Softwarelizenzvertrag in der Praxis, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, S. 629 ff. 2 Vgl. Redeker, IT-Recht, Rz. 202; Jersch, Ergänzender Leistungsschutz und Computersoftware, S. 183 ff. 3 Vgl. Haß, Der strafrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, S. 467 ff. 4 Vgl. Haberstumpf, Der urheberrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, II, Rz. 15 ff.

Karger

5

A Rz. 5

Grundlagen

Darstellungen wissenschaftlicher oder technischer Art i.S.v. § 2 Abs. 1 UrhG gemäß § 2 Abs. 2 UrhG einen gewissen Grad an „Gestaltungshöhe“ erreichen, der über den Anforderungen des § 69a UrhG liegt. Von einer Schutzfähigkeit dieser Materialien kann deshalb nicht ohne weiteres ausgegangen werden. 5

Im Rahmen der Softwareerstellung stellt sich zunächst die Frage, welche Arbeitsergebnisse entstehen1 und ob diese urheberrechtlichen Schutz beanspruchen können. Für Computerprogramme kommt ein Schutz nach § 69a UrhG2, für sonstige Arbeitsergebnisse ein Schutz nach § 2 UrhG3, für Datenbankwerke bzw. Datenbanken ein Schutz nach § 4 UrhG bzw. nach § 87a UrhG4 in Betracht. In diesem Zusammenhang ist auch zu klären, wer Urheber bzw. Rechtsinhaber im Hinblick auf die Arbeitsergebnisse ist5. Da die Software im Regelfall von einem Team erstellt wird, sind die Fragen der Miturheberschaft von besonderer Relevanz6. An einem schutzfähigen Werk erwachsen dem Urheber Rechte7. Hierbei ist zwischen den Urheberpersönlichkeitsrechten8 und den – für die Praxis der Softwareerstellung relevanteren – Verwertungsrechten9 zu unterscheiden. Die Verwertungsrechte umfassen das positive Benutzungsrecht und das negative Verbietungsrecht. Allerdings kann der Urheber dem berechtigten Nutzer eines Computerprogramms bestimmte Nutzungen nicht untersagen, sofern diese gem. § 69d und § 69e UrhG zustimmungsfrei sind10. Von entscheidender Bedeutung für den Urheber und für den Auftraggeber bzw. Lizenznehmer ist die Einräumung von Rechten an der Software11. Grundsätzlich sind aufgrund des Trennungsprinzips das der Rechtseinräumung zugrunde liegende Verpflichtungsgeschäft sowie das in der Rechtseinräumung selbst liegende Verfügungsgeschäft auseinanderzuhalten12. Aufgrund des Trennungsprinzips können der Abschluss des Verpflichtungsgeschäfts und das Verfügungsgeschäft in Gestalt der Rechtseinräumung zeitlich auseinanderfallen, so dass stets auch der Zeitpunkt der Rechtseinräumung zu betrachten ist13. Schließlich ist für die Praxis der Umfang der Rechtseinräumung von großer Wichtigkeit14. Empfehlenswert

1 2 3 4 5 6 7 8 9 10 11 12 13 14

6

S. Rz. 7 ff. S. Rz. 10 ff. S. Rz. 23 ff. S. Rz. 24 ff. S. Rz. 29 ff. S. Rz. 30 ff. S. Rz. 35 ff. S. Rz. 35 ff. S. Rz. 39 ff. S. Rz. 44 ff. S. Rz. 51 ff. S. Rz. 52 ff. S. Rz. 57 ff. S. Rz. 64 ff.

Karger

Schutz und Realisierung der Software

Rz. 6 A

ist es, hierzu eine ausdrückliche Vereinbarung zu treffen1. Fehlt es hieran, so bestimmt sich der Umfang der Rechtseinräumung nach dem Zweckübertragungsgrundsatz2. In engem Zusammenhang mit der Rechtseinräumung stehen auch die Fragen der Vergütung des Urhebers3. In der Praxis kommt es nicht selten vor, dass bei der Softwareerstellung Urheberrechte Dritter verletzt werden, z.B. durch eine unerlaubte Übernahme schutzfähiger Elemente in das zu entwickelnde Softwareprodukt. Deshalb müssen sich die Beteiligten auch der Rechtsfolgen etwaiger Verletzungen bewusst sein4. 1. Arbeitsergebnisse bei Softwareerstellung a) Phasen der Programmerstellung Bei der Ermittlung und Zuordnung der Arbeitsergebnisse zu den urheber- 6 rechtlich relevanten Kategorien sind zunächst die einzelnen Phasen der Softwareerstellung zu betrachten. Hierbei gibt es kein einheitliches und allgemein anerkanntes Modell. Ganz allgemein wird zwischen dem „klassischen“ Vorgehensmodell (sog. „Wasserfallmodell“) und „modernen“ Vorgehensmodellen unterschieden, zu denen insbesondere das agile Programmieren zählt (s. hierzu C Rz. 1 ff., 113 ff.) Zum klassischen Vorgehensmodell finden sich in Rechtsprechung und Literatur unterschiedliche Ansätze, die sich zwar oft in der Terminologie unterscheiden, vom Grundsätzlichen her aber viele Übereinstimmungen aufweisen. In der Entscheidung Inkassoprogramm5 hat sich der BGH mit einem Erstellungskonzept auseinandergesetzt und den Erstellungsprozess grob in drei Phasen unterteilt: (1) Problem- bzw. Systemanalyse, (2) Problemlösung und (3) Codierung. Das OLG Frankfurt unterscheidet in der Entscheidung Baustatik6 zwischen (1) Problemlösung, (2) Aufstellung des Datenflussplans, (3) Erstellung des Programmablaufplans und (4) Codierung. Die BVB-Planung und die BVB-Erstellung7 unterscheiden im Wesentlichen zwischen dem Planungs-, dem Realisierungs- und dem Einführungsabschnitt, wobei sich jeder Abschnitt wieder in eine oder mehrere Phasen gliedert:

1 2 3 4 5 6 7

S. Rz. 65 ff. S. Rz. 67 ff. S. Rz. 72 ff. S. Rz. 195 ff. BGH v. 9.5.1985 – I ZR 52/83, CR 1985, 22, 29 ff. OLG Frankfurt v. 6.11.1984 – 14 U 188/81, CR 1986, 13, 16 ff. S. Anhang 2 zu den Besonderen Vertragsbedingungen für die die Erstellung von DV-Programmen (BVB-Erstellung) bzw. Anhang 2 zu den Besonderen Vertragsbedingungen für die Planung von DV-gestützten Verfahren (BVB-Planung), abrufbar unter www.cio.bund.de. Die BVB-Erstellung wurden durch die EVB-IT Erstellung (Version 1.0 vom 8.7.2013) ersetzt.

Karger

7

A Rz. 6

Grundlagen

12-Phasenmodell der BVB (verkürzt): 1. Abschnitt: Verfahrensplanung Phase 1: Verfahrensidee Phase 2: Ist-Analyse Phase 3: Forderungen Phase 4: Grobkonzept Phase 5: Fachliches Feinkonzept 2. Abschnitt: Verfahrensrealisierung 1. Teilabschnitt: Systemrealisierung Phase 6: DV-technisches Feinkonzept Phase 7: Programmierung Phase 8: Integration und Systemtest 2. Teilabschnitt: Einführungsvorbereitung Phase 9: Technische/organisatorische Vorbereitung Phase 10: Schulung 3. Teilabschnitt: Verfahrenstest Phase 11: Verfahrenstest 3. Abschnitt: Verfahrenseinführung Phase 12: Einführung

Weitere, teilweise sehr differenzierte Varianten von Phasenmodellen werden in der Literatur beschrieben1. Üblicherweise wird der eigentliche Entwicklungsprozess in drei bzw. vier Phasen unterteilt. Ähnlich wie bei der BVB-Erstellung wird der Entwicklungsprozess häufig auch in die Anforderungsphase, die Konzeptionsphase, die Kodierungsphase und die Testphase gegliedert2. In der Anforderungsphase werden in der Regel die Ist-Analyse, eine Soll-Analyse sowie eine Machbarkeitsstudie durchgeführt. Die Ergebnisse werden im Pflichtenheft niedergelegt. In der Konzeptionsphase wird das Grobkonzept ausgearbeitet, das eine graphische Darstellung der Strukturen in einem sog. Datenflussplan (Flussdiagramm) beinhaltet. Anschließend wird im Feinkonzept der genaue Programmablauf definiert. In der Kodierungsphase wird das Feinkonzept mittels einer Programmiersprache in den Quellcode umgesetzt. Regelmäßig wird der Quellcode noch in den Objektcode umgewandelt (sog. Kompilation) und mit Funktionsbibliotheken so verbunden, dass er zum ausführbaren Maschinenprogramm wird3. 1 S. etwa Haberstumpf, Der urheberrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, II, Rz. 21 ff. und Ilzhöfer, Die Inkassoprogrammentscheidung des Bundesgerichtshofs aus informatik-technischer Sicht, CR 1988, 332. Zu den gängigen Phasenkonzepten auch Müller-Hengstenberg, Risikomanagement in DV-Projekten, CR 1999, 789 und Harte-Bavendamm/Wiebe, in: Kilian/Heussen Computerrechtshandbuch, Nr. 51 Rz. 9 ff. 2 Hierzu und zur Beschreibung der einzelnen Schritte innerhalb der einzelnen Phasen anschaulich Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 5 f. 3 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 5 f.

8

Karger

Schutz und Realisierung der Software

Rz. 7 A

b) Einzelne Arbeitsergebnisse Im Rahmen der Software-Entwicklung entsteht somit eine Vielzahl von Ar- 7 beitsergebnissen, wobei stets der konkrete Einzelfall zu untersuchen ist. In Betracht kommen insbesondere1: – – – – – – – – – – – – – – – – – – – – –

Lastenheft Ist-Analyse Soll-Analyse Pflichtenheft Idee zur Problemlösung Grobkonzept inklusive Datenflussplan (Flussdiagramm) Feinkonzept Programmablaufplan Quellcode Objektcode Unterprogramme, Programm-Module Schnittstellen Benutzeroberflächen (GUI) Datenbanken Software-Entwicklungs-Tools Testkonzept Abnahmekonzept Programmbeschreibung Bedienungsanleitung Handbücher Schulungsunterlagen

Erweitert man den Blick auf Materialien, die typischerweise im Vorfeld und bei der Durchführung eines Entwicklungsprojektes entstehen, kommen gegebenenfalls noch hinzu: – – – – – – – –

RFI (Request for Information) des Auftraggebers RFP (Request for Proposal) des Auftraggebers Ausschreibungsunterlagen des Auftraggebers Angebot des Auftragnehmers Workshop-Protokolle Projekt-Protokolle Projekt-Datenbank Daten, insbesondere Testdaten

Jedes der genannten Arbeitsergebnisse ist hinsichtlich seiner grundsätzlichen Schutzfähigkeit, der Schutzvoraussetzungen und der Reichweite des 1 Vgl. auch Karger, Rechtseinräumung bei Softwareerstellung, CR 2001, 357 f.

Karger

9

A Rz. 8

Grundlagen

Schutzes gesondert zu betrachten. Eine einheitliche Beurteilung ist nicht möglich. Insbesondere kann § 69a UrhG mit seinen vergleichsweise niedrigen Anforderungen an die Schutzfähigkeit nicht auf solche Materialien angewendet werden, die kein Computerprogramm bzw. Entwurfsmaterial i.S.d. Gesetzes darstellen1. 2. Urheberrechtsschutz gemäß § 69a UrhG 8

Nach § 69a UrhG sind alle Ausdrucksformen eines Computerprogramms geschützt. Computerprogramme sind Programme in jeder Gestalt unter Einschluss des Entwurfsmaterials. Vom Schutz ausgenommen sind die dem Computerprogramm zugrunde liegenden Ideen und Grundsätze. Schutzvoraussetzung ist, dass das Computerprogramm ein individuelles Werk darstellt, das Ergebnis der eigenen geistigen Schöpfung seines Urhebers ist. a) Computerprogramme

9

Der Begriff des Computerprogramms ist weder in den §§ 69a ff. UrhG noch in der Richtlinie über den Rechtsschutz von Computerprogrammen2 in ausreichender Weise definiert3. Dies und eine uneinheitliche Interpretation der Begriffe „Computerprogramm“ und „Computersoftware“ führen zu erheblichen Unsicherheiten, welche im Rahmen des Entwicklungsprozesses entstehenden Komponenten dem Schutzgegenstand des § 69a UrhG bzw. der Computerrichtlinie unterfallen. aa) Maschinen-, Objekt- und Quellcode

10 Bei Vorliegen der Voraussetzungen des § 69a UrhG sind Computerprogramme in jeder Gestalt geschützt. Computerprogramme sind das in jeder Form, Sprache und Notation oder in jedem Code gewählte Ausdrucksmittel für eine Folge von Befehlen, die dazu dient, einen Computer zur Ausführung einer bestimmten Aufgabe oder Funktion zu veranlassen4. Der Begriff des Computerprogramms erfasst den Maschinen- bzw. Quellcode sowie den Objektcode5. Dabei ist es unerheblich, ob das Programm auf einem mobilen Datenträger (USB-Stick, DVD, CD-ROM, Band) bzw. auf einer Festplatte gespeichert oder in die Hardware integriert ist6.

1 Vgl. Redeker, IT-Recht, Rz. 14. 2 Richtlinie des Rates v. 14.5.1991 über den Rechtsschutz von Computerprogrammen (91/250/EWG), ABlEG Nr. L 122 v. 17.5.1991, S. 42 f. 3 Hierzu Marly, GRUR 2012, 774 f.; ders., GRUR 2011, 204 f. 4 Marly, GRUR 2012, 773. 774 f. mit Hinweisen auf die Rspr. 5 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 4, 10 f.; Marly, GRUR 2012, 774, 776. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 4, 10 f.; Marly, GRUR 2012, 774, 776.

10

Karger

Schutz und Realisierung der Software

Rz. 12 A

Auch sämtliche Vor- und Zwischenstufen, die im Rahmen der Entwicklung in verkörperter Form entstehen, sind prinzipiell schutzfähig1. Der Schutz bezieht sich nicht notwendig auf das Programm in seiner Gesamtheit, sondern kann auch für einzelne Programmteile, Unterprogramme und Programmmodule gegeben sein2. bb) Funktionalität des Computerprogramms, Programmiersprache, Dateiformat In einer neueren Entscheidung hat der EuGH3 klargestellt, dass weder die 11 Funktionalität eines Computerprogramms noch die Programmiersprache oder das Dateiformat, die im Rahmen eines Computerprogramms verwendet werden, um bestimmte Funktionen des Programms zu nutzen, eine Ausdrucksform dieses Programms darstellen und daher nicht unter den Schutz des Urheberrechts an Computerprogrammen i.S.d. Richtlinie über den Rechtsschutz von Computerprogrammen4 fallen5. cc) Grafische Benutzeroberflächen Ob die die grafische Benutzeroberfläche (auch Graphical User Interface – 12 GUI) eines Computerprogramms dem Schutz des § 69a UrhG unterfällt, war lange Zeit umstritten. Die wohl h.M. lehnte einen Schutz nach § 69a Abs. 1 und 2 UrhG u.a. mit der Begründung ab, dass Benutzeroberflächen und Bildschirmmasken erst durch den Programmablauf generiert und damit sichtbar werden und damit keine Programme sind, sondern lediglich das Ergebnis des Programmbetriebs darstellen6. Der EuGH7 hat hierzu entschieden, dass eine grafische Benutzeroberfläche keine Ausdrucksform eines Computerprogramms i.S. der Richtlinie über den Rechtsschutz von Computerprogrammen darstellt. Sie könne deshalb nicht den urheberrechtlichen Schutz für Computerprogramme nach dieser Richtlinie genießen. Der EuGH führt zur Begründung aus, dass der durch die Richtlinie geschaffene Schutzgegenstand sich auf das Computerpro-

1 Redeker, IT-Recht, Rz. 4; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 4. 2 Vgl. BGH v. 23.1.2003 – I ZR 18/00, MDR 2003, 1306 = CR 2003, 800; OLG Hamburg v. 11.1.2001 – 3 U 120/00, CR 2001, 434, 435; Grützmacher, in: Wandtke/ Bullinger, § 69a Rz. 12. 3 EuGH (Große Kammer) v. 2.5.2012 – C-406/10 (SAS Institute Inc./World Programming Ltd.), GRUR 2012, 814. 4 Artikel 1 Absatz II der Richtlinie 91/250/EWG des Rates v. 14.5.1991 über den Rechtsschutz von Computerprogrammen. 5 Zu dieser Entscheidung s. Marly, GRUR 2012, 773 und Spindler, CR 2012, 417. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 14 m.w.N. 7 EuGH v. 22.12.2010 – C-393/09 (BSA/Kulturministerium), GRUR 2011, 220, hierzu ausführlich Marly, GRUR 2011, 204.

Karger

11

A Rz. 13

Grundlagen

gramm in allen seinen Ausdrucksformen bezieht, die es erlauben, es in den verschiedenen Datenverarbeitungssprachen, wie Quellcode oder Objektcode, zu vervielfältigen. Die grafische Benutzeroberfläche sei eine Interaktionsschnittstelle, die eine Kommunikation zwischen dem Computerprogramm und dem Benutzer ermögliche. Die grafische Benutzeroberfläche ermögliche es aber nicht, das Computerprogramm zu vervielfältigen, sondern stelle lediglich ein Element dieses Programms dar, mittels dessen die Benutzer das Programm nutzten. Eine solche Interaktionsschnittstelle kann jedoch nach Auffassung des EuGH urheberrechtlich als sonstiges Werk geschützt sein, wenn sie eine eigene geistige Schöpfung ihres Urhebers darstellt. Hierbei seien jedoch die Anordnung und die spezifische Konfiguration aller Komponenten zu berücksichtigen, aus denen sich die grafische Benutzeroberfläche zusammensetze, um bestimmen zu können, welche Komponenten das Kriterium der Originalität erfüllten. Dieses Kriterium sei dann nicht erfüllt, wenn der Ausdruck dieser Komponenten durch ihre technische Funktion vorgegeben sei, denn die verschiedenen Möglichkeiten der Umsetzung einer Idee seien dann so beschränkt, dass die (nicht schutzfähige) Idee und der Ausdruck zusammenfielen1. Damit kommt ein Schutz der grafischen Benutzeroberfläche als Sprachwerk gem. § 2 Abs. 1 Nr. 1 UrhG, als Werk der bildenden Künste gem. § 2 Abs. 1 Nr. 4 UrhG oder als Darstellung wissenschaftlicher oder technischer Art gem. § 2 Abs. 1 Nr. 7 UrhG in Betracht. Es müssen jedoch stets die Voraussetzungen des § 2 Abs. 2 UrhG erfüllt sein, d.h. der Schutz kann mangels des erforderlichen Gestaltungsspielraums u.U. an der nötigen Individualität scheitern2. dd) Schnittstellen 13 Problematisch ist, ob Schnittstellen dem Schutz des § 69a UrhG unterfallen. Mit Schnittstellen sind hier nicht die grafischen Benutzeroberflächen (Graphical User Interfaces) gemeint (s. hierzu vorstehend cc]), sondern technische Schnittstellen wie Software- und Programmierschnittstellen (Application Programming Interfaces – API). 14 Das Gesetz enthält keine Definition des Begriffs „Schnittstelle“. 69a Abs. 2 Satz 2 UrhG stellt lediglich klar, dass Ideen und Grundsätze, die einem Element zugrunde liegen, einschließlich der den Schnittstellen zugrundeliegenden Ideen und Grundsätze, nicht geschützt sind. Unter Schnittstellen werden allgemein die Teile einer Hard- oder Software verstanden, über die verschiedene Hard- und/oder Softwarekomponenten

1 EuGH v. 22.12.2010 – C-393/09 (BSA/Kulturministerium), GRUR 2011, 220, hierzu ausführlich Marly, GRUR 2011, 204. 2 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 14.

12

Karger

Schutz und Realisierung der Software

Rz. 17 A

miteinander kommunizieren1. § 69a Abs. 2 Satz 2 UrhG bezieht sich auf Software- und Programmierschnittstellen2. Softwareschnittstellen ermöglichen den Datenaustausch zwischen Programmen und einzelnen Modulen, während Programmierschnittstellen einen standardisierten Zugriff auf die Funktionalität des Betriebssystems oder eines sonstigen Programms erlauben3. Aus dem Gegenschluss zu § 69a Abs. 2 Satz 2 UrhG ergibt sich, dass der die 15 Schnittstellen umsetzende Code im Einzelfall schutzfähig sein kann4. Dies gilt aber dann nicht, wenn die Schnittstelle rein sachbedingt und funktional, also der Natur der Sache nach zwingend vorgegeben ist oder Ausdruck der fortschreitenden Normierung und Standardisierung ist5; dies ist bei technischen Schnittstellen in besonderem Maße der Fall6. Es ist daher davon auszugehen, dass der EuGH einen Urheberrechtschutz mangels Originalität verneinen würde7. Jedenfalls ist im Zweifelsfall bei der Bejahung der Schutzfähigkeit Zurückhaltung geboten8. Ungeschützt sind die den Schnittstellen zugrundeliegenden Ideen und 16 Grundsätze. Hierzu zählt insbesondere die Schnittstellenspezifikation, in der die Regeln und Methoden des Datenaustausches und der Zusammenarbeit der verschiedenen Programme und Module beschrieben werden9. ee) Websites Auf SGML (Standard Generalized Markup Language) sowie dessen Internet- 17 und WAP-Derivaten HTML (HyperText Markup Language), XHTML (Extensible HyperText Markup Language), XML (Extensible Markup Language) und WML (Wireless Markup Language) basierende Websites sind keine Computerprogramme10. Der Code macht nur Texte oder Grafiken sichtbar, so dass § 69a UrhG auf Webesites als grafische Oberfläche ebenso wie auf grafische Benutzeroberflächen nicht anzuwenden ist11. Entsprechend wird der Schutz von HTML-Code, der Schutz von XML-Code und auch der Schutz des sichtbaren Erscheinungsbilds einer Website als solches als Computerprogramm i.S.v. § 69a UrhG überwiegend abgelehnt12. 1 2 3 4 5 6 7 8 9 10 11 12

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31. Marly, GRUR 2012, 774, 779. Marly, GRUR 2012, 774, 779. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31; Spindler, in: Schricker/Loewenheim, § 69a Rz. 13. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 31. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 18. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 18. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 18 mit ausführlicher Darstellung des Streit- und Meinungsstands in Lit. und Rspr.

Karger

13

A Rz. 18

Grundlagen

Dagegen können Websites bzw. deren Kodierung in Teilen dann Schutz als Computerprogramm erlangen, wenn sie Flash, Java-Applets, Java-Script oder PHP enthalten, denn hierbei handelt es sich um ablauffähige bzw. interpretierbare Steuerbefehle1. 18 Einzelne Elemente einer Website können aber nach § 2 UrhG geschützt sein. Der Text als regelmäßiger Kernbestandteil kann unter den Voraussetzungen des § 2 Abs. 2 UrhG als Sprachwerk Schutz beanspruchen2. Eingestellte Bilder können als Lichtbildwerke i.S.v. § 2 Abs. 1 Nr. 5 UrhG oder als einfaches Lichtbild nach § 72 UrhG, einspielbare Videosequenzen als filmähnliche Werke i.S.v. § 2 Abs. 1 Nr. 6 oder als einfache Laufbilder nach § 95 UrhG geschützt sein3. Dagegen genießen grafische Gestaltungselemente wie Rahmen und strukturierte Seitenaufteilungen wegen der regelmäßig fehlenden Schöpfungshöhe keinen urheberrechtlichen Schutz4. Für eine Website oder Teile hiervon kommt darüber hinaus ein Schutz als Datenbankwerk i.S.d. § 4 Abs. 2 UrhG bzw. als Datenbank i.S.v. §§ 87a ff. UrhG in Betracht5. ff) Multimediawerke 19 Sog. Multimediawerke, bei denen mehrere urheberrechtlich geschützte Werke unterschiedlicher Gattungen, wie z.B. Text, Bild und Ton, zu einer Einheit verbunden werden, sind als solche in der Gesamtheit aller Elemente keine Computerprogramme6. Vielmehr sind grundsätzlich alle Komponenten hinsichtlich ihrer Schutzfähigkeit getrennt zu betrachten: So ist das Programm, das den Ablauf der einzelnen Bestandteile des Multimediawerks ermöglicht, für sich gesehen als Computerprogramm schutzfähig7. Daneben sind die einzelnen, in das Multimediawerk eingebundenen Bestandteile selbständig schützfähig, wenn sie die Schöpfungshöhe gem. § 2 Abs. 2 UrhG erreichen oder die Voraussetzungen eines der verwandten Schutzrechte erfüllen8. Nur ganz ausnahmsweise kann einem Multimediawerk ein mittelbarer Schutz über § 69a UrhG zukommen, wenn ein Computerprogramm in das Multimediaprodukt integriert ist9.

1 2 3 4 5

6 7 8 9

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 18. Bullinger, in: Wandtke/Bullinger, § 4 Rz. 14. Bullinger, in: Wandtke/Bullinger, § 4 Rz. 14. Bullinger, in: Wandtke/Bullinger, § 4 Rz. 14. Vgl. Schack, Urheberrechtliche Gestaltung von Webseiten unter Einsatz von Links und Frames MMR 2001, 9, 11; ausführlich hierzu auch Bullinger, in: Wandtke/Bullinger, § 4 Rz. 14 ff. LG Köln v. 15.6.2005 – 28 O 744/04, MMR 2006, 52, 55; Spindler, in: Schricker/ Loewenheim, § 69a Rz. 29; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 21. LG Köln v. 15.6.2005 – 28 O 744/04, MMR 2006, 52, 55 f.; Dreier/Schulze, § 69a Rz. 18. Dreier/Schulze, § 69a Rz. 18. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 21.

14

Karger

Schutz und Realisierung der Software

Rz. 22 A

gg) Datenbanken und Daten Datenbanken, Datenstrukturen und Daten sind keine Computerprogramme 20 i.S.v. § 69a UrhG1. Dies ergibt sich im Hinblick auf Datenbankwerke bzw. Datenbanken schon aus §§ 4, 87a UrhG. Reine Daten beinhalten keine Steuerbefehle, so dass sie nicht von der gängigen Definition eines Computerprogramms erfasst werden2. hh) Objektorientierte Computerprogramme Die Schutzfähigkeit von objektorientierten Computerprogrammen nach 21 § 69a UrhG wird unterschiedlich beurteilt. Objektorientierte Programme zeichnen sich durch einen hohen Grad an Vorfertigung und Abstraktion aus und basieren regelmäßig auf abstrakten, nicht für den konkreten Erstellungsvorgang geschriebenen Modulen bzw. Klassen, die aus vorgefertigten Klassenbibliotheken übernommen werden3. Korrespondierend zu dieser Abstraktion und Vorfertigung besteht zum Zeitpunkt der Erstellung entsprechender Klassen kein konkreter Bezug zur Erstellung eines bestimmten Programms4. Nach einer in der Literatur vertretenen Auffassung sind objektorientierte Computerprogramme als Computerprogramme bzw. Entwurfsmaterialien i.S.v. § 69a Abs. 1 UrhG schutzfähig5. Die Gegenmeinung lehnt einen Schutz nach § 69a Abs. 1 UrhG ab, da vorgefertigte Klassen mangels Maschinenbezug und Anbindung an ein bestimmtes Programm keine Computerprogramme bzw. Entwurfsmaterialien i.S.v. § 69a Abs. 1 darstellen, und geht von einem denkbaren Schutz als eigenständige Werke i.S.v. § 2 Abs. 1 Nr. 7 UrhG aus6. ii) Customizing Eine allgemein anerkannte Definition des „Customizing“ gibt es nicht. All- 22 gemein lässt sich Customizing als Anpassung einer Software an Kundenwünsche bzw. an betriebliche Anforderungen beschreiben7. Im Regelfall betrifft die Anpassung die Auswahl zwischen bereits in den Programmen vorgegebenen Grundeinstellungen. Die Auswahl dieser Grundeinstellung (uneinheitlich „parametrisieren“ oder „konfigurieren“ genannt) erfolgt ohne Veränderung der Programmstruktur. In diesen Fällen fehlt es an einer in-

1 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 16. 2 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 17. 3 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 19; zu den Details der objektorientierten Programmierung ausführlich Koch, Begründung und Grenzen des urheberrechtlichen Schutzes objektorientierter Software, GRUR 2000, 191. 4 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 19. 5 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 19. 6 Koch, GRUR 2000, 191, 192, 195 ff. 7 Vgl. Koch, Urheberrechtsschutz für das Customizing von Computerprogrammen, ITRB 2005, 140.

Karger

15

A Rz. 23

Grundlagen

dividuellen, eigenschöpferischen Werkerstellung i.S.v. § 69a Abs. 3 Satz 1 UrhG1. Zuweilen umfasst das Customizing aber auch eine ergänzende Programmierung. Dies ist insbesondere dann der Fall, wenn die im Programm vorgegebenen Grundeinstellungen den Anforderungen nicht genügen. Entsprechende nachträgliche und individuell programmierte Codeergänzungen können nach § 69a Abs. 1 UrhG geschützt sein, wenn sie eigenschöpferisch i.S.v. § 69a Abs. 3 Satz 1 UrhG sind2. b) Entwurfsmaterial 23 Neben dem Computerprogramm ist gemäß § 69a Abs. 1 UrhG auch das Entwurfsmaterial geschützt. Nicht alle Materialien, die im Vorfeld der Programmerstellung entstehen, sind als Entwurfsmaterial i.S.d. Gesetzes zu qualifizieren. Das Material muss zur Entwicklung des Computerprogramms bzw. zur Vorbereitung der Entwicklung dienen und seiner Art nach die spätere Entstehung eines Computerprogramms nach sich ziehen können3. Hierzu zählen das in der Konzeptionsphase erstellte Grobkonzept inklusive Datenflussplan (Flussdiagramm) und das Feinkonzept4. aa) Pflichtenheft 24 Umstritten ist, ob das Pflichtenheft zum Entwurfsmaterial zählt. Teilweise wird vertreten, dass das Pflichtenheft (ebenso wie das Lastenheft) zum Entwurfsmaterial gehört, und zwar unabhängig davon, ob es vom Auftraggeber oder vom Auftragnehmer erstellt wird, da ohne diese Unterlagen Programme gar nicht geschaffen werden können5. Nach der Gegenmeinung ist das Pflichtenheft nicht nach § 69a UrhG, sondern allenfalls nach § 2 Abs. 1 Nr. 1 bzw. Nr. 7 UrhG geschützt6. Die das Programm prägende intellektuelle Leistung stehe im Stadium der Problemanalyse und Erstellung des Pflichtenhefts gerade noch aus; das spätere Computerprogramm, das sich erstmalig im Grobkonzept verkörpere, sei die Lösung der im Pflichtenheft lediglich aufgeworfenen Probleme7. 25 Vor einer rechtlichen Zuordnung muss zunächst hinterfragt werden, was eigentlich unter einem Pflichtenheft zu verstehen ist und welchen Inhalt es im konkreten Fall aufweist. Eine allgemein anerkannte Definition des 1 Vgl. Koch, Urheberrechtsschutz für das Customizing von Computerprogrammen, ITRB 2005, 140 f.; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 34. 2 Vgl. Koch, Urheberrechtsschutz für das Customizing von Computerprogrammen, ITRB 2005, 140 f. 3 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 7. 4 Dreier/Schulze, § 69a Rz. 14; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 7. 5 Redeker, IT-Recht, Rz. 4. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 9; Dreier, in: Dreier/Schulze, § 69a Rz. 14. 7 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 9.

16

Karger

Schutz und Realisierung der Software

Rz. 27 A

Pflichtenheftes gibt es nicht, vielmehr finden sich hierzu zahlreiche unterschiedliche Auffassungen1. In der Praxis werden Dokumente unterschiedlichsten Inhalts als Pflichtenheft bezeichnet (s. zum Pflichtenheft detailliert C Rz. 1 ff.). Teilweise wird der Begriff synonym mit „Lastenheft“, „Leistungsbeschreibung“, oder „Statement of Work“ (SOW) verwendet. Vielfach – insbesondere, wenn das Pflichtenheft vom Auftraggeber erstellt wird – enthält das Dokument lediglich Festlegungen, was das zu erstellende Programm leisten soll. Die entsprechenden Anforderungen werden nur funktional umschrieben, konkrete Lösungswege aber nicht aufgezeigt. In diesem Fall kann das Pflichtenheft nicht dem Entwurfsmaterial zugeordnet werden. Häufig ist es aber so, dass der Auftraggeber nicht über die erforderliche Kompetenz zur Erstellung des Pflichtenheftes verfügt und die Ausarbeitung dem Auftragnehmer übertragen wird. In diesen Fällen kann das Pflichtenheft nicht nur die Beschreibung der zu lösenden Probleme, sondern u.U. auch die Beschreibung von Lösungsansätzen enthalten, etwa das fachliche Feinkonzept. Dann ist das Pflichtenheft insoweit bereits Grundlage der Programmierung und damit (insoweit) dem Entwurfsmaterial zuzuordnen. bb) Konzeptionelle Vorgaben Rechte nach § 69a UrhG kann nur derjenige innehaben, der bestimmte von 26 ihm selbst entwickelte oder von dritter Seite vorgegebene Vorstellungen in ein Computerprogramm umsetzt. Die rein konzeptionellen Vorgaben – etwa in kaufmännischer oder betriebswirtschaftlicher Hinsicht – sind kein nach § 69a UrhG geschütztes Entwurfsmaterial, auch wenn sie für die Erstellung eines funktionstüchtigen Programms unerlässlich sind. Sie können allenfalls Schutz nach § 2 Abs. 1 Nr. 1 und Nr. 7 UrhG beanspruchen und dann zur Miturheberschaft an dem Gesamtwerk führen2. cc) Handbücher und Begleitmaterial Handbücher, wie insbesondere Bedienungsanleitungen, Benutzerhand- 27 bücher oder Wartungshandbücher zu einem Computerprogramm und sonstiges Begleitmaterial fallen – auch wenn sie in digitaler Form vorliegen – weder unter den Begriff des Computerprogramms noch unter den des Entwurfsmaterials3. Sie können aber gem. § 2 Abs. 1 Nr. 1 oder Nr. 7 UrhG, § 2 Abs. 2 UrhG schutzfähig sein4. Hierbei ist davon auszugehen, dass viele Handbücher mit Ausnahme von Grafiken auf Grund der vielfältigen funk-

1 Vgl. Intveen/Lohmann, Das IT-Pflichtenheft, CR 2003, 640 ff.; Ihde, Das Pflichtenheft beim Softwareerstellungsvertrag, CR 1999, 409 ff. 2 OLG Köln v. 8.4.2005 – 6 U 194/04, CR 2005, 624. 3 Marly, GRUR 2012, 773, 778 unter Verweis auf die Rspr. des EuGH; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 13. 4 Spindler, CR 2012, 417, 422; Redeker, IT-Recht, Rz. 7; Dreier, in: Dreier/Schulze, § 69a Rz. 15.

Karger

17

A Rz. 28

Grundlagen

tionellen Vorgaben und technischen Sachzwänge nicht die notwendige Schöpfungshöhe erreichen1. c) Kein Schutz von Ideen und Grundsätzen aa) Problemstellung 28 Aus der Sicht des Softwareerstellers besteht das Interesse an einem möglichst weit gehenden Schutz seiner Arbeitsergebnisse. Dies gilt nicht nur hinsichtlich der konkret erstellten Materialien wie etwa des Programmcodes oder der Dokumentation, sondern auch für die dahinter stehenden Ideen. Oft besteht der eigentliche Wert einer Softwareentwicklung in der Umsetzung einer neuen Geschäftsidee, der Optimierung von Geschäftsprozessen oder der Kombination bereits bekannter Prozesse und Methoden mit neuen Lösungsansätzen, jeweils unter Nutzung der sich ständig erweiternden technischen Möglichkeiten. In der Praxis fragen Softwareersteller deshalb meist ebenso oft nach den Schutzmöglichkeiten für die hinter der Softwarelösung stehenden Ideen wie nach den Schutzmöglichkeiten für die konkreten Arbeitsergebnisse selbst. 29 Nicht alle in einem Programm verkörperten Schaffenselemente werden vom urheberrechtlichen Schutz erfasst: Nach § 69a Abs. 2 UrhG gilt der gewährte Schutz nur für Ausdrucksformen eines Computerprogramms. Die einem Element des Computerprogramms, einschließlich den Schnittstellen, zugrunde liegenden Ideen und Grundsätze sind hingegen nicht geschützt. § 69a Abs. 2 UrhG ist die gesetzliche Ausprägung des allgemein im Urheberrecht geltenden Grundsatzes, dass Ideen, Erkenntnisse und Informationen im Interesse der Allgemeinheit nicht monopolisiert werden dürfen2. 30 Die Frage nach der Schutzfähigkeit von Ideen und Grundsätzen scheint auf den ersten Blick durch § 69a Abs. 2 Satz 2 UrhG klar beantwortet zu sein. Bei einer genaueren Betrachtung stellt man jedoch fest, dass die Grenze zwischen der nach § 69a Abs. 1 Satz 1 UrhG geschützten Ausdrucksform des Computerprogramms und den gemäß § 69a Abs. 2 UrhG nicht schutzfähigen Ideen und Grundsätzen sehr schwer zu ziehen ist. Der Übergang von ungeschützten Ideen und Grundsätzen zur geschützten Ausdrucksform ist fließend3. 31 Der Gesetzgeber hat die Aufarbeitung dieser Problematik ausdrücklich der Rechtsprechung zugewiesen4. Dies bedingt eine weitgehende Rechtsunsicherheit, da eine Prognose, wo die Rechtsprechung im Einzelfall die Schutzgrenzen zieht, nach wie vor schwierig ist. Vielfach wird die Abgrenzung 1 2 3 4

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 13. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 22. Schricker/Loewenheim, § 69a Rz. 9. Begründung des Regierungsentwurfs BT-Drucks. 12/4022 v. 18.12.1992, S. 9.

18

Karger

Schutz und Realisierung der Software

Rz. 34 A

zwischen Idee und Ausdruck bzw. Form jeweils im Einzelfall aufgrund einer Wertung vorgenommen, ob ein Freihaltebedürfnis besteht oder nicht1. bb) Geschützte Ausdrucksformen Zu den geschützten Ausdrucksformen eines Computerprogramms zählen2:

32

– – – –

der Objektcode und der Quellcode in allen Entwicklungsstufen; die innere Struktur und Organisation des Computerprogramms; die Anordnung von Befehlsgruppen, Unterprogrammen und Modulen; auf der Ebene des Programmcodes die konkrete Sammlung, Auswahl und Gliederung der Befehle; – das sog. „Gewebe des Computerprogramms“, d.h. die Art, wie Unterprogramme und Arbeitsroutinen aufgeteilt und mit Verzweigungsanweisungen verknüpft werden. cc) Ungeschützte Ideen und Grundsätze; Frage der Schutzfähigkeit von Algorithmen Zu den ungeschützten Ideen zählen hingegen die abstrakte Problemstellung 33 und die Leitgedanken der mit Hilfe des Programms zu lösenden Probleme3. Demgemäß sind etwa die einem Programm zugrunde liegenden Geschäftsideen nicht schutzfähig. Im Hinblick auf dem Programm zugrunde liegende Grundsätze, die ebenfalls keinen Schutz beanspruchen können, wird insbesondere die Frage der Schutzfähigkeit von Algorithmen besonders kontrovers diskutiert. Streit besteht zum einen schon darüber, was unter einem Algorithmus zu verstehen ist4. Zum anderen ist umstritten, ob bzw. wie weit Algorithmen nach § 69a UrhG geschützt sein können. Teilweise wird unter einem Algorithmus eine Vorschrift verstanden, die für ein Verfahren eindeutig vorbestimmt, welche Schritte bei welchen Vorfällen durchgeführt werden müssen5. Nach einem ähnlichen Ansatz ist ein Algorithmus ein vollständiger Satz wohldefinierter Regeln zur Lösung eines Problems in einer endlichen Zahl von Schritten6. Demgemäß stellen nicht nur bloße „Rechenregeln“ sondern auch jedes Computerprogramm einen Algorithmus dar7. Da Computerprogramme aber schutzfähig sind, wäre die

1 Redeker, IT-Recht, Rz. 9. 2 S. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 23 ff. m.w.N. 3 Vgl. OLG Karlsruhe v. 13.6.1994 – 6 U 52/94 – Bildschirmmasken, CR 1994, 607 m. Anm. Günther = GRUR 1994, 726, 729; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 27. 4 S. hierzu Marly, Praxishandbuch Softwarerecht, Rz. 29 ff. 5 Redeker, IT-Recht, Rz. 8. 6 Vgl. Marly, Praxishandbuch Softwarerecht, Rz. 30 m.w.N. 7 Redeker, IT-Recht, Rz. 8.

Karger

19

34

A Rz. 35

Grundlagen

Aussage verfehlt, dass Algorithmen ganz generell keinen Schutz beanspruchen können. Nicht schutzfähig sind jedenfalls Algorithmen höherer Stufe, die für die Lösung bestimmter Arten von Aufgaben grundsätzlich geeignet und daher als wissenschaftliche Lehren zu behandeln sind1. Ungeschützt bleiben damit allgemeine Rechenregeln, mathematische Formeln oder abstrakte Lehrsätze, die einem Programm zugrunde liegen2. Demgegenüber kann ein Schutz für die Art und Weise der Implementierung und Zuordnung der Algorithmen zueinander in Betracht kommen3. 35 Insgesamt fehlen für die Praxis wirklich brauchbare Kriterien dafür, wie nicht schutzfähiger Grundsatz und schutzfähige Ausdrucksform von einander abzugrenzen sind4. Die Abgrenzung von Inhalt und Form ist im Bereich der Programmierung schwer zu treffen5. Ein Kriterium zur Abgrenzung ist sicherlich der Abstraktionsgrad: Je abstrakter das Leistungsergebnis ist, desto wahrscheinlicher ist es, dass es als Idee urheberrechtlich ungeschützt bleibt6. § 69b Abs. 2 Satz 2 UrhG stellt klar, dass auch die den Schnittstellen zugrunde liegenden Ideen und Grundsätze nicht geschützt sind. d) Schutzvoraussetzungen der eigenen geistigen Schöpfung und der Individualität 36 Nach § 69a Abs. 3 UrhG sind Computerprogramme geschützt, wenn sie individuelle Werke in dem Sinne darstellen, dass sie das Ergebnis einer eigenen geistigen Schöpfung ihres Urhebers sind. Zur Bestimmung der Schutzfähigkeit dürfen keine anderen Kriterien, insbesondere keine qualitativen oder ästhetischen Kriterien angewendet werden. Die vom BGH früher geforderte überragende Schöpfungshöhe kann deshalb nicht mehr als Kriterium für die Schutzfähigkeit herangezogen werden7. 1 Redeker, IT-Recht, Rz. 8. 2 OLG Celle v. 9.9.1993 – 13 U 105/93, CR 1994, 748; vgl. BGHZ 94, 276, 285 – Inkasso-Programm; BGHZ 112, 264, 277 – Betriebssystem; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 28. 3 BGH v. 4.10.1990 – I ZR 139/89 – Betriebssystem, BGHZ 112, 264, 277 = CR 1991, 150 m. Anm. Lehmann = MDR 1991, 503 = CR 1991, 80; OLG Frankfurt v. 6.11.1984 – 14 U 188/81 – Baustatikprogramme, CR 1986, 13 = GRUR 1985, 1049, 1050; OLG Celle v. 9.9.1993 – 13 U 105/93, CR 1994, 748, 749 f.; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 28; Dreier/Schulze, § 69a Rz. 22; Schricker/Loewenheim, § 69a Rz. 10, 12. 4 Redeker, IT-Recht, Rz. 9. 5 Redeker, IT-Recht, Rz. 9. Zu parallelen Problematik im U.S.-Recht und den dort diskutierten Lösungsansätzen s. Karger, Beweisermittlung im deutschen und U.S.-amerikanischen Softwareverletzungsprozess, S. 18, 176 f. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 27. 7 Vgl. BGH v. 9.5.1985 – I ZR 52/83 – Inkassoprogramm, MDR 1986, 121 = CR 1985, 22; BGH v. 4.10.1990 – I ZR 139/89 – Betriebssystem, MDR 1991, 503 = CR 1991, 80.

20

Karger

Schutz und Realisierung der Software

Rz. 39 A

Vor der Umsetzung der entsprechenden EG-Richtlinie über den Rechtsschutz von Computerprogrammen1 durch die Einführung der §§ 69a ff. UrhG war nach der Rechtsprechung des BGH ein Computerprogramm nur dann schutzfähig, wenn seine Erstellung das Können eines Durchschnittsprogrammierers erheblich überstieg2. Eine eigene geistige Schöpfung i.S.d. Gesetzes ist bereits dann gegeben, 37 wenn das betreffende Werk zum einen vom Autor selbst stammt, also nicht kopiert wurde, und zum anderen eine gewisse, wenn auch geringe Individualität aufweist, mithin nicht nur eine mechanisch-technische Aneinanderreihung von vorbekanntem Material ist, wenn es nicht zum Gemeingut gehört und nicht vollständig auf rein alltäglicher Programmierarbeit beruht3. Damit ist davon auszugehen, dass der Urheberrechtsschutz für Computerprogramme die Regel und fehlende Schöpfungshöhe die Ausnahme ist4. Eine geistige Schöpfung setzt voraus, dass das Computerprogramm von ei- 38 nem Menschen geschaffen wurde. Computergenerierte Programme sollen daher grundsätzlich ungeschützt bleiben5. Da gemäß § 69a UrhG nur eine „eigene“ und keine „persönliche“ geistige Schöpfung verlangt wird, ist auch die „kleine Münze“ geschützt6. Als weiteres zu prüfendes Kriterium verbleibt die Individualität des Werks. 39 Die Rechtsprechung stellt diesbezüglich auf eine „statistische Einmaligkeit“ in dem Sinne ab, dass mit hoher Wahrscheinlichkeit kein anderer das Werk schaffen wird7. Dies ist in der Literatur auf Kritik gestoßen8. Danach ist nötig aber auch ausreichend, dass ein bescheidenes Maß an Gestaltertätigkeit gegeben ist9. Für die erforderliche Individualität ist es nicht erforderlich, dass die Leistung aus dem Durchschnittlichen herausragt. Geschützt sind Computerprogramme, soweit deren Konzeption Eigentümlichkeiten aufweist, die nicht als trivial oder völlig banal und von der Sachlogik her zwingend vorgegeben sind10.

1 Richtlinie 91/250/EWG, ABl. Nr. L 122/42 ff. v. 17.5.1991. 2 Vgl. hierzu statt vieler Haberstumpf, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, S. 112 ff., Rz. 79 ff. 3 Vgl. Lehmann, CR 1993, 775 (Anm. zu BGH v. 14.7.1993 – I ZR 47/91, MDR 1994, 364 = CR 1993, 752 – Buchhaltungsprogramm). 4 Redeker, IT-Recht, Rz. 12. 5 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 32; Redeker, IT-Recht, Rz. 15. 6 Redeker, IT-Recht, Rz. 15. 7 Vgl. OLG München v. 25.11.1999 – 29 U 2437/97, CR 2000, 429, 430; OLG München v. 27.5.1999 – 6 U 5497/98, CR 1999, 688, 689; OLG Hamburg v. 12.3.1998 – 3 U 228/97, CR 1999, 298. 8 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 34. 9 So Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 34. 10 OLG München v. 25.11.1999 – 29 U 2437/97, CR 2000, 429, 430; OLG Düsseldorf v. 27.3.1997 – 20 U 51/96, CR 1997, 337, 338; Redeker, IT-Recht, Rz. 12; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 34.

Karger

21

A Rz. 40

Grundlagen

Nicht schutzfähig sind demgemäß bloß kopierte Computerprogramme1 und sog. Banalprogramme, d.h. kleine Programme, die nur aus wenigen Programmbefehlen oder dem Hintereinanderschalten allgemein bekannter Programmbausteine bestehen2. Bei komplexen Computerprogrammen spricht eine tatsächliche Vermutung für eine hinreichende Individualität der Programmgestaltung3. 40 Gemäß § 69a Abs. 3 Satz 2 UrhG dürfen für die Beurteilung der Schutzfähigkeit keine weiteren Kriterien herangezogen werden. Dies gilt ausdrücklich für qualitative oder ästhetische Kriterien jeder Art. Sonstige Kriterien, wie Effizienz und Funktionalität, Quantität i.S.d. Umfangs des Programms, Aufwand und Kosten, objektive Neuheit und gewerbliche Verwertbarkeit sind unbeachtlich4. Der Schutz hängt auch nicht von der Einhaltung bestimmter Förmlichkeiten ab, wie z.B. der Markierung des Arbeitsergebnisses mit dem ©-Zeichen5. In der Praxis führen die so abgesenkten Schutzanforderungen dazu, dass die Urheberrechtsfähigkeit von Computerprogrammen zwischen den Parteien zumeist unstreitig bleibt und die Gerichte die Schutzfähigkeit häufig unproblematisch annehmen6. 41 Die Darlegungs- und Beweislast für die Schutzfähigkeit trifft grundsätzlich den Rechtsinhaber7. Eine rechtliche Vermutung für die Schutzfähigkeit von Computerprogrammen gibt es nicht8. Grundsätzlich muss damit der Rechtsinhaber die schöpferischen Elemente darlegen, die das Programm urheberrechtsfähig machen. Teilweise wurde eine Darlegung der Individualität im Einzelnen verlangt9. Nach der Rechtsprechung des BGH spricht bei komplexen Computerprogrammen eine tatsächliche Vermutung für eine hinreichende Individualität der Programmgestaltung. In solchen Fällen ist es Sache des Gegners darzutun, dass das Programm nur eine gänzlich banale

1 Vgl. Marly, Praxishandbuch Softwarerecht, Rz. 93. 2 Marly, Praxishandbuch Softwarerecht, Rz. 93; Redeker, IT-Recht, Rz. 12. 3 BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 855. 4 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 41. 5 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 42; zur zivilprozessualen Relevanz des ©-Zeichens als „prima facie evidence“ im U.S.-amerikanischen Recht Karger, Beweisermittlung im deutschen und U.S.-amerikanischen Softwareverletzungsprozess, S. 173. 6 Redeker, IT-Recht, Rz. 13; zu den Darlegungs- und Beweisfragen im Einzelnen s. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 36 ff. 7 Redeker, IT-Recht, Rz. 219; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 36. S. auch Ulmer, Darlegungslast im Prozess um Urheberrecht an Software, ITRB 2006, 63. 8 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 36; Lehmann, CR 1993, 755. 9 LG München v. 28.8.1998 – 7 O 3114/98, CR 1998, 655, 656.

22

Karger

Schutz und Realisierung der Software

Rz. 43 A

Programmierleistung ist oder lediglich das Programmschaffen eines anderen Programmierers übernimmt1. 3. Urheberrechtlicher Schutz gem. § 2 UrhG Für Arbeitsergebnisse, die nicht als Computerprogramm bzw. Entwurfs- 42 material nach § 69a UrhG qualifiziert werden können, kommt unter Umständen ein Schutz nach § 2 UrhG in Betracht. Im Unterschied zu § 69a UrhG, der nur eine eigene geistige Leistung fordert und damit bereits die „kleine Münze“ schützt, ist nach § 2 Abs. 2 UrhG eine „persönliche geistige Schöpfung“ erforderlich. Das Werk muss deshalb die erforderliche Individualität aufweisen und eine bestimmte Gestaltungshöhe erreichen. Die Schutzvoraussetzungen nach § 2 UrhG sind folglich höher als die nach § 69a UrhG. In der Konsequenz kann dies z.B. bedeuten, dass das entwickelte Programm und das Entwicklungsmaterial urheberrechtlichen Schutz genießen, das auf das Programm bezogene Begleitmaterial, z.B. das Handbuch und die Programmbeschreibung wegen fehlender Individualität bzw. Gestaltungshöhe aber nicht. Ein Schutz nach § 2 UrhG kommt insbesondere für folgende Materialien in 43 Betracht: – Sofern man das Pflichtenheft nicht dem Entwurfsmaterial i.S.v. § 69a UrhG zuordnet, weil es gegebenenfalls nur Anforderungen bzw. Problembeschreibungen und keine Lösungsansätze enthält, kann es gem. § 2 Abs. 1 Nr. 1 UrhG als Sprachwerk bzw. § 2 Abs. 1 Nr. 7 UrhG als Darstellung wissenschaftlicher oder technischer Art geschützt sein2. – Für die grafische Benutzeroberfläche kommt – da ein Schutz nach § 69a UrhG ausscheidet3 – ein Schutz als Sprachwerk gem. § 2 Abs. 1 Nr. 1 UrhG, als Werk der bildenden Künste gem. § 2 Abs. 1 Nr. 4 UrhG oder als Darstellung wissenschaftlicher oder technischer Art gem. § 2 Abs. 1 Nr. 7 UrhG in Betracht. Allerdings müssen dann die Voraussetzungen des § 2 Abs. 2 UrhG gegeben sein, d.h. der Schutz kann mangels Gestaltungsspielraum an der nötigen Individualität scheitern4. – Das Begleitmaterial (also insbesondere Handbücher, Bedienungsanleitungen, Wartungsbücher und die Programmbeschreibung) ist kein Entwurfsmaterial i.S.v. § 69a Abs. 1 UrhG. Es kann ebenfalls als Sprach- bzw. Schriftwerk gem. § 2 Abs. 1 Nr. 1 UrhG oder als Darstellung technischer Art gem. § 2 Abs. 1 Nr. 7 UrhG geschützt sein. Auf den Schutz des 1 BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 855; vgl. auch LG Mannheim v. 17.12.1993 – 7 O 257/93, CR 1994, 627 = NJW-RR 1994, 1007; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 37. 2 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 9. 3 EuGH v. 22.12.2010 – C-393/09 (BSA/Kulturministerium), GRUR 2011, 220, hierzu Marly, GRUR 2012, 204 ff. 4 OLG Frankfurt/M., CR 2005, 705; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 14.

Karger

23

A Rz. 44

Grundlagen

zugrunde liegenden Programms, insbesondere auf die niedrigen Schutzvoraussetzungen des § 69a UrhG, kann bezüglich dieser Materialien nicht zurückgegriffen werden1. Deshalb ist davon auszugehen, dass viele Handbücher mit Ausnahme von Grafiken auf Grund der vielfältigen funktionellen Vorgaben und technischen Sachzwänge die notwendige Schöpfungshöhe nicht erreichen2. 44 Die im Einzelnen zu stellenden Anforderungen an die Individualität und an die Gestaltungshöhe sind umstritten3. Individualität bedeutet nicht, dass das Werk völlig neu sein muss4. Allerdings scheidet eine individuelle Schöpfung aus, wenn lediglich bereits vorhandene Ausdrucksformen wiederholt werden, ohne dem Werk persönliche Züge zu geben5. Das Merkmal der Individualität bedeutet deshalb, dass ein Werk sich von anderen, älteren Werken durch seine Formgestaltung unterscheiden muss6. So ist etwa ein Handbuch, das zum größten Teil aus schon bestehenden Textpassagen und Graphiken mittels „copy and paste“ zusammengefügt wird, keine individuelle Schöpfung. 45 Die Gestaltungshöhe bezieht sich auf den Grad der Individualität, den das Werk aufweisen muss, um eine persönliche geistige Schöpfung nach § 2 Abs. 2 UrhG zu sein7. Das urheberrechtlich geschützte Werk muss eine erhebliche individuelle Prägung besitzen. Damit werden einerseits einfache Alltagserzeugnisse ausgesondert, anderseits muss es sich aber auch nicht um ein herausragendes Werk handeln8. Durchschnittliche Werke werden geschützt, wenn sie den nötigen Grad an Individualität aufweisen. Der Grad der Gestaltungshöhe, den die Rechtsprechung verlangt, ist für die verschiedenen Werkarten nicht einheitlich und wird durch die Frage nach den konkreten Gestaltungsspielräumen und dem Freihaltebedürfnis im Bezug auf eine bestimmte Werkart mitbestimmt9. 4. Schutz als Datenbankwerk bzw. als Datenbank 46 Bei der Entwicklung komplexer Anwendungen, insbesondere im Multimedia-Bereich10, kommt auch der Schutz einzelner Arbeitsergebnisse als 1 2 3 4 5 6 7 8 9 10

24

Redeker, IT-Recht, Rz. 14. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 13. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 24. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 21. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 22. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 22. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 23. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 23. Bullinger, in: Wandtke/Bullinger, § 2 Rz. 25. Zu den Schutzmöglichkeiten von Multimedia-Anwendungen im Einzelnen z.B. LG Köln v. 15.6.2005 – 28 O 744/04, MMR 2006, 52; Ernst, Die Verfügbarkeit des Source Codes – Rechtlicher Know-how-Schutz bei Software und Webdesign, MMR 2001, 208; Schack, Urheberrechtliche Gestaltung von Webseiten unter Einsatz von Links und Frames, MMR 2001, 9; Leistner/Bettinger, Immaterialgü-

Karger

Schutz und Realisierung der Software

Rz. 48 A

Datenbankwerke gem. § 4 Abs. 2 UrhG bzw. ein Leistungsschutzrecht für Datenbanken gem. § 87a UrhG in Betracht. Das Datenbankurheberrecht nach § 4 Abs. 2 UrhG und das Datenbankherstellerrecht nach § 87a Abs. 1 UrhG entstehen selbständig und unabhängig voneinander. Wenn die jeweiligen Schutzvoraussetzungen erfüllt sind, können sie auch kumulativ bei ein und derselben Datenbank zusammentreffen1. Gem. § 4 Abs. 2 UrhG sind Datenbankwerke und Datenbanken strikt von dem zur Schaffung des Datenbankwerks oder zur Ermöglichung des Zugangs zu dessen Elementen verwendeten Computerprogramm zu unterscheiden. § 4 Abs. 2 UrhG findet auf Datenbanken entsprechende Anwendung2. Bei Datenbanken, bei denen sich die wesentliche Leistung in den entsprechenden Computerprogrammen verbirgt, kann es allerdings zu Abgrenzungsschwierigkeiten zwischen dem Urheberrecht am Computerprogramm einerseits und dem Datenbankurheber- und Datenbankherstellerrecht andererseits kommen3. a) Urheberrechtlicher Schutz als Datenbankwerk Gem. § 4 Abs. 2 Satz 1 UrhG ist das Datenbankwerk ein Sammelwerk, des- 47 sen Elemente systematisch oder methodisch angeordnet und einzeln mit Hilfe elektronischer Mittel oder auf andere Weise zugänglich sind. Hierbei muss die Auswahl oder Anordnung der enthaltenen Elemente auf einer persönlichen geistigen Schöpfung i.S.v. § 2 Abs. 2 UrhG beruhen4. Allerdings ist die Schutzschwelle niedrig anzusetzen: Geschützt ist die sog. „kleine Münze“, d.h., es muss lediglich ein Minimum an Gestaltungshöhe gegeben sein5. Erforderlich ist eine gewisse Originalität des Werks, nicht aber die Qualität oder der ästhetische Wert6. § 4 Abs. 2 UrhG erfasst insbesondere elektronische Datenbanken. Werkcha- 48 rakter haben bereits reine Datensammlungen, sobald ein gewisser Spielraum für eine individuelle Anordnung der Daten vorhanden ist7. Entscheidend ist damit, ob eine gewisse Auswahlmöglichkeit und ein Entscheidungsspiel-

1 2 3 4 5 6 7

terrechtlicher und wettbewerbsrechtlicher Schutz des Web-Designers, CR 1999, 921; Zscherpe, Urheberrechtsschutz digitalisierter Werke im Internet, MMR 1998, 404; Wiebe/Funkat, Multimedia-Anwendungen als urheberrechtlicher Schutzgegenstand, MMR 1998, 69; Koch, Software-Urheberrechtsschutz für Multimedia-Anwendungen, GRUR 1995, 459, 465 f. Thum, in: Wandtke/Bullinger, Vor §§ 87a ff. Rz. 20. Schricker/Vogel, Vor §§ 87a ff. Rz. 35. Thum, in: Wandtke/Bullinger, Vor §§ 87a ff. Rz. 34. Bullinger, in: Wandtke/Bullinger, § 4 Rz. 4, Rz. 5. Bullinger, in: Wandtke/Bullinger, § 4 Rz. 5. Bullinger, in: Wandtke/Bullinger, § 4 Rz. 5. Vgl. OLG Hamburg v. 22.2.2001 – 3 U 247/00 – medizinisches Lexikon im Internet, CR 2001, 704 m. Anm. Dieselhorst = MMR 2001, 533; LG Hamburg v. 12.7.2000 – 308 O 205/00 – medizinische Datenbank, CR 2000, 776 m. Anm. Metzger = MMR 2000, 761, 762.

Karger

25

A Rz. 49

Grundlagen

raum hinsichtlich der in die Datenbank aufzunehmenden Elemente bestehen. Für eine Website oder Teile hiervon kommt ein Schutz als Datenbankwerk i.S.d. §§ 4 Abs. 2 UrhG bzw. als Datenbank i.S.v. §§ 87a ff. UrhG in Betracht1. b) Leistungsschutz als Datenbank 49 Datenbank i.S.v. § 87a Abs. 1 Satz 1 UrhG ist eine Sammlung von Werken, Daten oder anderen unabhängigen Elementen, die systematisch oder methodisch angeordnet und einzeln mit Hilfe elektronischer Mittel oder auf andere Weise zugänglich sind und deren Beschaffung, Überprüfung oder Darstellung eine nach Art und Umfang wesentliche Investition erfordert. Einer persönlichen geistigen Schöpfung bedarf es hier nicht. 50 Zentrale Tatbestandsvoraussetzung ist die in den Datenbankaufbau getätigte wesentliche Investition2. Diesbezüglich ist eine zweistufige Prüfung vorzunehmen3: Zunächst ist zu prüfen, ob eine Investition überhaupt berücksichtigungsfähig ist. Berücksichtigungsfähig sind nur solche Investitionen, die in die Beschaffung, Überprüfung oder Darstellung des Datenbankinhalts getätigt worden sind. Sodann ist zu klären, ob die Summe der berücksichtigungsfähigen Investitionen die Schwelle der Wesentlichkeit erreicht. Hinsichtlich der Wesentlichkeit ist die Schutzuntergrenze ungeklärt, was insbesondere bei kleinen Datenbanken zu rechtlichen Unsicherheiten bzgl. der Schutzfähigkeit führt4. 5. Übersicht zur Schutzfähigkeit einzelner Arbeitsergebnisse 51

Arbeitsergebnis

Schutzfähig bei Vorliegen der gesetzlichen Voraussetzungen

Rechtliche Einordnung

Anwendbare Vorschriften

Ist-Analyse

Ja

Schriftwerk bzw. § 2 Abs. 1 Nr. 1 Darstellung wisbzw. Nr. 7 UrhG, senschaftlicher § 2 Abs. 2 UrhG oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe)

1 Vgl. Schack, Urheberrechtliche Gestaltung von Webseiten unter Einsatz von Links und Frames MMR 2001, 9, 11; ausführlich hierzu auch Bullinger, in: Wandtke/Bullinger, § 4 Rz. 14 ff. 2 Thum, in: Wandtke/Bullinger, § 87a Rz. 33. 3 Zum Ganzen ausführlich Thum, in: Wandtke/Bullinger, § 87a Rz. 34 ff. 4 Thum, in: Wandtke/Bullinger, § 87a Rz. 34.

26

Karger

Rz. 51 A

Schutz und Realisierung der Software Arbeitsergebnis

Schutzfähig bei Vorliegen der gesetzlichen Voraussetzungen

Rechtliche Einordnung

Anwendbare Vorschriften

Soll-Analyse

Ja

Schriftwerk bzw. § 2 Abs. 1 Nr. 1 Darstellung wisbzw. Nr. 7 UrhG, senschaftlicher § 2 Abs. 2 UrhG oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe)

Pflichtenheft (ent- Ja hält nur Anforderungen bzw. Problembeschreibung)

Schriftwerk bzw. § 2 Abs. 1 Nr. 1 Darstellung wisbzw. Nr. 7 UrhG, senschaftlicher § 2 Abs. 2 UrhG oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe)

Pflichtenheft (enthält bereits Lösungskonzepte)

Ja

Entwurfsmaterial

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Projektdatenbank

Ja

Datenbankwerk, bzw. Datenbank

§ 4 Abs. 2 UrhG; § 87a UrhG

Dem Programm zugrunde liegende Idee

Nein

§ 69a Abs. 2 Satz 2 UrhG

Dem Programm zugrunde liegende Grundsätze

Nein

§ 69a Abs. 2 Satz 2 UrhG

Grobkonzept inklusive Datenflussplan (Flussdiagramm)

Ja

Entwurfsmaterial

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Feinkonzept (Programmablaufplan)

Ja

Entwurfsmaterial

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Quellcode (in allen Ja Zwischen- und Endfassungen)

Computerprogramm

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Objektcode (in al- Ja len Zwischen- und Endfassungen)

Computerprogramm

§ 69a Abs. 1 Abs. 2, Abs. 3 UrhG

Karger

27

A Rz. 51

Grundlagen

Arbeitsergebnis

Schutzfähig bei Vorliegen der gesetzlichen Voraussetzungen

Rechtliche Einordnung

Anwendbare Vorschriften

Unterprogramme, Programmmodule

Ja

Computerprogramm

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Benutzeroberfläche Ja (GUI)

Nicht als Compu- § 2 Abs. 1 Nr. 1, terprogramm, u.U. Nr. 5, Nr. 7 UrhG, aber als sonstiges § 2 Abs. 2 UrhG Werk (bei ausreichender Individualität und Gestaltungshöhe)

(Technische) Schnittstelle

I.d.R. nein

Kein Computerprogramm

Software-Entwicklungs-Tools

Ja

Computerprogramm

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Patches, WorkArounds

Ja

Computerprogramm

§ 69a Abs. 1, Abs. 2, Abs. 3 UrhG

Programmbeschreibung

Ja

§ 2 Abs. 1 Nr. 1. Schriftwerk bzw. bzw. Nr. 7 UrhG, Darstellung wis§ 2 Abs. 2 UrhG. senschaftlicher oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe), str.

Bedienungsanleitung

Ja

§ 2 Abs. 1 Nr. 1 Schriftwerk bzw. bzw. Nr. 7 UrhG, Darstellung wis§ 2 Abs. 2 UrhG senschaftlicher oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe)

Handbücher

Ja

Schriftwerk bzw. § 2 Abs. 1 Nr. 1. bzw. Nr. 7 UrhG, Darstellung wissenschaftlicher § 2 Abs. 2 UrhG oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe), str.

28

Karger

Rz. 53 A

Schutz und Realisierung der Software Arbeitsergebnis

Schutzfähig bei Vorliegen der gesetzlichen Voraussetzungen

Rechtliche Einordnung

Anwendbare Vorschriften

Schulungsunterlagen

Ja

Schriftwerk bzw. § 2 Abs. 1 Nr. 1 Darstellung wisbzw. Nr. 7 UrhG, senschaftlicher § 2 Abs. 2 UrhG oder technischer Art (bei ausreichender Individualität und Gestaltungshöhe)

6. Urheberschaft bzw. Rechtsinhaberschaft Sofern das Arbeitsergebnis urheberrechtlich geschützt ist, gebühren die ent- 52 sprechenden Rechte dem Urheber. Im Regelfall erfolgt die Softwareerstellung durch mehrere Personen, so dass die Frage der Miturheberschaft eine besondere Rolle spielt. Die Rechte an schutzfähigen Datenbanken stehen dem Investor zu. a) Urheberrecht aa) Einzelurheber Urheber und damit originäre Rechtsinhaber sind gemäß § 7 UrhG die 53 Schöpfer eines Computerprogramms. Schöpfer können nur natürliche Personen sein. Damit scheiden juristische Personen bzw. Unternehmen als Urheber aus1. Dies gilt trotz § 69b UrhG auch für Computerprogramme2, da § 69b UrhG den eigentlichen Status des betreffenden Arbeitnehmers als Schöpfer nicht in Frage stellt; vielmehr begründet § 69b UrhG eine gesetzliche Lizenz, die eine Übertragung der Verwertungsrechte vom Arbeitnehmer auf den Arbeitgeber beinhaltet3. Schöpfer sind nur Personen, die einen individuellen, schöpferischen Beitrag geleistet haben. Lediglich finanzierende Auftraggeber kommen damit – anders als bei der Erstellung einer Datenbank i.S.v. § 87a UrhG – als Schöpfer nicht in Betracht4.

1 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 44. 2 Redeker, IT-Recht, Rz. 17. 3 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69b Rz. 1: Derivativer Erwerb, der das Schöpferprinzip anerkennt. 4 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 44.

Karger

29

A Rz. 54

Grundlagen

bb) Miturheberschaft 54 Software wird im Regelfall nicht von Einzelpersonen, sondern von mehreren Beteiligten entwickelt. Auf Auftragnehmerseite sind zumeist Projektteams mit der Entwicklung befasst. Häufig sind neben Arbeitnehmern auch freie Mitarbeiter eingebunden. In vielen Fällen sind auch Mitarbeiter des Auftraggebers an der Entwicklung beteiligt. Wirken die einzelnen Personen bei der Erstellung eines einheitlichen Werks i.S.v. § 8 UrhG zusammen, so sind sie Miturheber. (1) Voraussetzungen der Miturheberschaft 55 Voraussetzung für die Miturheberschaft ist eine einheitliche Schöpfung, die einen entsprechenden natürlichen Handlungswillen der beteiligten Urheber voraussetzt1. Die Miturheber müssen sich der Gesamtidee, ein gemeinschaftliches Werk zu schaffen, unterordnen2. Es müssen also ein gemeinsamer Plan, ein gemeinsamer Wille und ein gemeinsames Ziel bestehen, um die Software zu erstellen3. Hierdurch unterscheidet sich die Miturheberschaft von der Bearbeitung oder Fortsetzung eines bereits fertiggestellten oder von der Vollendung eines unfertigen Werks4. Die schöpferische Mitwirkung kann bei einem stufenweise bzw. in zeitlicher Staffelung entstehenden Werk – wie einem Computerprogramm – auch in einem Vorstadium erfolgen, wenn sie als unselbständiger Beitrag zum einheitlichen Schöpfungsprozess der Werkvollendung geleistet wird5. Die einzelnen Beiträge müssen also nicht nebeneinander stehen (horizontale Arbeitsteilung), sondern können als Vor-, Zwischen- und Hauptstufe aufeinander aufbauen (vertikale Arbeitsteilung)6. Die einzelnen Miturheber brauchen nicht jeden Beitrag zum gemeinsamen Werk auch gemeinsam zu erbringen; es reicht aus, dass jeder in Unterordnung unter die gemeinsame Gesamtidee einzelne (schöpferische) Beiträge selbst erbringt. Es ist nicht erforderlich, dass der Einzelne an allen schöpferischen Elementen mitgewirkt hat. Auch Umfang und Größe der Beiträge sind nicht ausschlaggebend, sofern sie nur schöpferischer Art sind7. Bei einer zeitlich gestaffelten Entwicklung ist allerdings genau zu prüfen, ob alle schöpferischen Beiträge in Unterordnung unter eine gemeinsame Gesamtidee erfolgen oder ob spätere Ergänzungen und Verbesserungen vom Handlungswillen des ursprünglichen 1 BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 856. 2 Dreier/Schulze, § 8 Rz. 2. 3 Dreier/Schulze, § 8 Rz. 2. 4 Dreier/Schulze, § 8 Rz. 2. 5 BGH v. 14.7.1993 – I ZR 47/91 – Buchhaltungsprogramm, MDR 1994, 364 = CR 1993, 752 ff.; BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 856. 6 Schricker/Loewenheim, § 8 Rz. 7. 7 BGH v. 14.7.1993 – I ZR 47/91 – Buchhaltungsprogramm, MDR 1994, 364 = CR 1993, 752 ff.

30

Karger

Schutz und Realisierung der Software

Rz. 58 A

Programmierers nicht mehr umfasst sind1. Ist Letzteres der Fall, liegt keine Miturheberschaft, sondern eine abhängige Bearbeitung vor2. Die zeitlich gestaffelte Weiterentwicklung eines Computerprogramms, z.B. im Rahmen der Entwicklung von neuen Releases im Zusammenhang mit der Pflege, spricht daher tendenziell für eine Bearbeitung des bestehenden Programms und gegen eine Miturheberschaft, sofern nicht die Unterordnung unter die gemeinsame Gesamtidee festgestellt wird3. Mitglieder eines Entwicklungsteams können unter den genannten Voraus- 56 setzungen unabhängig vom Zeitpunkt ihres Eintretens oder Ausscheidens aus dem Projektteam Miturheber sein, auch wenn sie nur einen vergleichsweise geringen Beitrag leisten. Je nach Ausgestaltung des Entwicklungsprojekts kommen auch die Mitarbeiter des Auftraggebers als Miturheber in Betracht. Dies ist insbesondere dann der Fall, wenn der Auftraggeber im Rahmen seiner Mitwirkung Entwicklungsleistungen schöpferischer Art beisteuert, z.B. wenn er detaillierte Vorgaben für die Konzeption macht4. Im Gegensatz zum Miturheber erwerben bloße Gehilfen, die dem Gestal- 57 tungswillen eines anderen untergeordnet sind, sowie bloße Ideenanreger5 keinen urheberrechtlichen Anteil am Werk. Urheber eines Programms kann i.d.R. nur derjenige sein, der bestimmte von ihm selbst entwickelte oder ihm von dritter Seite vorgegebene Aufgaben in ein Computerprogramm umsetzt. Demgegenüber ist derjenige, der nur die Aufgabe stellt, also – möglicherweise auch sehr ins Detail gehend – die Anforderungen vorgibt, die das Programm erfüllen soll, nicht gleichzeitig auch (Mit-)Urheber des Programms6. Es kann nicht jemand auch nur Miturheber eines Computerprogramms sein, der selbst keinerlei Programmierarbeit eigenverantwortlich geleistet hat; das gilt auch dann, wenn seine intellektuellen Vorarbeiten den Erfolg der Programmiertätigkeit erst ermöglicht haben7. Die Beiträge der Beteiligten müssen zur Schaffung eines einheitlichen 58 Werks geführt haben. Ein einheitliches Werk liegt vor, wenn sich die Anteile der einzelnen Urheber nicht gesondert verwerten lassen. Hierbei kommt es allein auf die fehlende Eignung zu gesonderter Verwertung in faktischer Hinsicht an. Dabei ist jedoch zu beachten, dass eine reale Trennbarkeit der Beiträge der einzelnen Urheber nicht in jedem Fall zu ihrer gesonderten Verwertbarkeit führt und damit der Einheitlichkeit des geschaffenen Werks

1 Vgl. BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 856. 2 Vgl. BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 856. 3 Dreier/Schulze, § 8 Rz. 2. 4 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 45. 5 Dreier/Schulze, § 8 Rz. 7. 6 OLG Köln v. 8.4.2005 – 6 U 194/04, CR 2005, 624, 625. 7 OLG Köln v. 8.4.2005 – 6 U 194/04, CR 2005, 624, 625.

Karger

31

A Rz. 59

Grundlagen

nicht notwendigerweise entgegensteht1. Maßgeblich für die Beurteilung ist der Zeitpunkt der Entstehung2. Werden hingegen mehrere selbständige, für sich gesondert verwertbare Werke verbunden, so liegt keine Miturheberschaft im Sinn von § 8 UrhG, sondern eine Werkverbindung i.S.v. § 9 UrhG vor3. (2) Identifizierung der Beiträge 59 Beim Zusammenwirken mehrerer Personen ist es oft schwierig, die Beiträge des Einzelnen zu identifizieren, um festzustellen, ob er Miturheber ist. Eine Möglichkeit hierzu ist die sorgfältige Dokumentation aller Schritte und Einzelbeiträge. Eine solche Dokumentation ist in der Praxis sehr aufwändig und wird häufig aufgrund von Zeit- und Ressourcenmangel nicht erstellt. Nach der Rechtsprechung kommt im Übrigen „Copyright-Vermerken“ auf den einzelnen Materialien besondere Bedeutung zu. Nach § 10 Abs. 1 UrhG wird derjenige, der auf den Vervielfältigungsstücken eines erschienenen Werks in der üblichen Weise als Urheber bezeichnet ist, bis zum Beweis des Gegenteils als Urheber angesehen. So können z.B. Initialen in der Kopfleiste von Maskenausdrucken und Copyright-Vermerke mit den Initialen in der Fußzeile eines Bedienungshandbuchs eine widerlegliche Vermutung der Urheberschaft begründen4. Auch digitale Wasserzeichen können die Bestimmung einzelner Beiträge erleichtern5. (3) Gesamthandsgemeinschaft 60 Den Miturhebern steht nach § 8 Abs. 2 UrhG das Recht zur Veröffentlichung und zur Verwertung des Werks zur gesamten Hand zu; Änderungen sind nur mit Einwilligung der anderen Miturheber zulässig, wobei diese nicht gegen Treu und Glauben verweigert werden darf. Sie sind damit kraft Gesetzes in einer als Gesamthandsgemeinschaft ausgestalteten „ZwangsGemeinschaft“6 verbunden. 61 Die Entstehung der Gesamthandsgemeinschaft gem. § 8 Abs. 2 UrhG ist zwingendes Recht. Die Gemeinschaft entsteht im Zeitpunkt der Schaffung des Werks durch den Realakt der gemeinschaftlichen Werkschöpfung7. Bei stufenweisen Prozessen wie der Softwareentwicklung entsteht die Gesamthand mit der ersten gemeinsamen Werkschöpfung und erweitert sich sukzessive um die später eingebrachten Beiträge. Die Gemeinschaft besteht 1 2 3 4

Thum, in: Wandtke/Bullinger, § 8 Rz. 7. Dreier/Schulze, § 8 Rz. 4. Thum, in: Wandtke/Bullinger, § 8 Rz. 13; Dreier/Schulze, § 8 Rz. 4. BGH v. 14.7.1993 – I ZR 47/91 – Buchhaltungsprogramm, MDR 1994, 364 = CR 1993, 752, 753. 5 Redeker, IT-Recht, Rz. 20. 6 Lehmann, CR 1993, 757 (Anm. zu BGH v. 14.7.1993 – I ZR 47/91, MDR 1994, 364 = CR 1993, 752). 7 Thum, in: Wandtke/Bullinger, § 8 Rz. 22.

32

Karger

Schutz und Realisierung der Software

Rz. 64 A

vom Entstehen der Software bis zu dem Zeitpunkt, zu dem 70 Jahre nach dem Tod des längstlebenden Miturhebers vergangen sind. Eine Auflösung der Gemeinschaft ist in diesem Zeitraum entgegen § 723 BGB nicht möglich; die Gemeinschaftsanteile sind auch nicht übertragbar1. (4) Einwilligungserfordernis Innerhalb der Gemeinschaft stehen dem Miturheber keine isolierten Ver- 62 wertungsmöglichkeiten zu. Die Veröffentlichung, Verwertung oder Änderung des gemeinsamen Werks bedarf gem. § 8 Abs. 2 UrhG grundsätzlich der Einwilligung, d.h. der vorherigen Zustimmung sämtlicher Miturheber i.S.v. § 183 BGB. Die nachträgliche Genehmigung hat der Gesetzgeber bewusst ausgeschlossen, um die rückwirkende Heilung einer bereits vollendeten und bei vorsätzlichem Handeln sogar strafbaren Rechtsverletzung sowie die schwebende Rechtsunwirksamkeit reiner Rechtshandlungen zu vermeiden2. Hat der betroffene Miturheber gegen die ohne sein Einverständnis durchgeführte Maßnahme nichts einzuwenden, so kann er im Nachhinein auf die Geltendmachung seiner Ansprüche aus der Rechtsverletzung verzichten3. Gem. § 8 Abs. 2 Satz 2 UrhG darf die Einwilligung nicht gegen Treu und 63 Glauben verweigert werden. Ob ein Verstoß gegen Treu und Glauben vorliegt, ist im Wege einer Interessenabwägung zu bestimmen. Zunächst sind die bestehenden vertraglichen Vereinbarungen heranzuziehen und erforderlichenfalls auszulegen. Daneben sind die Ziele und Zwecke zu berücksichtigen, die die Urheber mit der gemeinschaftlichen Werkschöpfung verfolgt haben4. Fehlen gegenteilige Absprachen, so ist von einem großzügigen, verwertungsfreundlichen Maßstab auszugehen, der dem Weigerungsrecht des einzelnen Miturhebers enge Grenzen setzt5. Ein Recht zur Verweigerung der Einwilligung kann sich vor allem aus einer Verletzung des Urheberpersönlichkeitsrechts des betroffenen Miturhebers ergeben6. (5) Verteilung der Erträgnisse Nach § 8 Abs. 3 UrhG gebühren die Erträgnisse aus der Nutzung den Miturhebern nach dem Umfang ihrer Mitwirkung an der Schöpfung des Werks, wenn nichts anderes zwischen ihnen vereinbart ist. Maßgeblich für die Errechnung des Beteiligungsverhältnisses ist nach § 8 Abs. 3 UrhG der quantitative Umfang der Mitwirkung, nicht die Bedeutung der einzelnen Anteile. Damit ist nicht nur der Umfang der einzelnen schöp-

1 2 3 4 5 6

Schricker/Loewenheim, § 8 Rz. 12. Thum, in: Wandtke/Bullinger, § 8 Rz. 31. Thum, in: Wandtke/Bullinger, § 8 Rz. 31. Thum, in: Wandtke/Bullinger, § 8 Rz. 33. Thum, in: Wandtke/Bullinger, § 8 Rz. 33. Thum, in: Wandtke/Bullinger, § 8 Rz. 33.

Karger

33

64

A Rz. 65

Grundlagen

ferischen Beiträge relevant, maßgeblich ist vielmehr der Gesamtumfang der Mitarbeit, d.h. beispielsweise auch eine etwaige Beteiligung an den notwendigen Vorarbeiten zu einem Werk1. Sofern sich der Umfang der Mitwirkung nicht bestimmen lässt, kommt ein Rückgriff auf Verteilungsgrundsätze, die sich in einzelnen Branchen herausgebildet haben, in Betracht. Möglich ist aber auch eine Schätzung nach Billigkeit, wenn ausreichende Anhaltspunkte vorliegen2. Sofern jegliche Anhaltspunkte für eine Schätzung fehlen, stehen allen Miturhebern im Zweifel gleiche Anteile an den Erträgnissen zu3. (6) Anteilsverzicht 65 Aus dem Vorstehenden ergibt sich, dass sich die Miturheber hinsichtlich der Verwertung durch vertragliche Regelung ihrer Innen- und Außenbeziehungen einigen müssen, um eine gegenseitige Blockade zu vermeiden. Zu beachten ist in diesem Zusammenhang § 8 Abs. 4 UrhG, wonach der Miturheber zugunsten der anderen auf seinen Anteil an den Verwertungsrechten verzichten kann. Ein Verzicht auf die Urheberpersönlichkeitsrechte ist allerdings nicht möglich. 66 Der Verzicht ist formfrei möglich. Bei stillschweigenden „Verzichtserklärungen“ ist allerdings angesichts der weitreichenden Folgen besonders sorgfältig zu prüfen, ob die erforderliche Ernstlichkeit der Verzichtserklärung gem. § 118 BGB vorliegt4. Mit Zugang der Verzichtserklärung wächst der Anteil des Verzichtenden gem. § 8 Abs. 4 Satz 3 UrhG den Anteilen der anderen Miturheber zu. Soweit nicht abweichend vereinbart, erfolgt die Anwachsung analog § 743 BGB nach dem Verhältnis der bisherigen Anteile der übrigen Miturheber5. Umstritten ist, ob der Verzicht sich auch auf die Vergütungsansprüche erstreckt6. b) Datenbankurheberrecht und Datenbankherstellerrecht 67 Liegt ein Datenbankwerk i.S.v. § 4 Abs. 2 UrhG vor, steht das entsprechende Datenbankurheberrecht dem Schöpfer des Datenbankwerks als natürlicher Person zu. Bei einer Datenbank i.S.v. § 87a UrhG ist Inhaber des Datenbankherstellerrechts gem. § 87a Abs. 2 UrhG der Investor, der nicht notwendig eine natürliche, sondern auch eine juristische Person sein kann7. Damit entstehen bei gleichzeitigem Vorliegen eines Datenbankwerks und einer Datenbank das Urheber- und Leistungsschutzrecht nicht stets originär in derselben Rechtspersönlichkeit. Die Rechtsinhaberschaft kann ausein-

1 2 3 4 5 6 7

Thum, in: Wandtke/Bullinger, § 8 Rz. 35. Thum, in: Wandtke/Bullinger, § 8 Rz. 35. Dreier/Schulze, § 8 Rz. 24. Thum, in: Wandtke/Bullinger, § 8 Rz. 50. Thum, in: Wandtke/Bullinger, § 8 Rz. 50. Hierzu Dreier/Schulze, § 8 Rz. 26. Thum, in: Wandtke/Bullinger, Vor §§ 87a ff. Rz. 21.

34

Karger

Schutz und Realisierung der Software

Rz. 71 A

anderfallen, wenn Werkschöpfer und Investor nicht identisch sind. Sofern nicht bei Arbeitnehmerurhebern bereits § 43 UrhG weiterhilft, müssen entsprechende ausdrückliche vertragliche Vereinbarungen getroffen werden, um die Verwertungsrechte in einer Hand zu bündeln1. 7. Rechte aus dem Urheberrecht Das Urheberrecht an einem Softwareprodukt entsteht mit der Werkschöp- 68 fung, also dann, wenn das Programm und das Entwurfsmaterial in einer sinnlich wahrnehmbaren Form vorliegen, die eine hinreichende Individualität erkennen lässt. Aus dem Urheberrecht erwachsen für den Urheber die Urheberpersönlichkeitsrechte gemäß §§ 12 ff. UrhG und die Verwertungsrechte gemäß §§ 15 ff. UrhG. Praxisrelevanz haben in erster Linie die Verwertungsrechte, namentlich das 69 Vervielfältigungsrecht gemäß § 16 UrhG, das Verbreitungsrecht gemäß § 17 UrhG und das Bearbeitungs- und Umgestaltungsrecht nach § 23 UrhG. Die allgemeinen Vorschriften der §§ 15 ff. UrhG werden im Hinblick auf Computerprogramme durch §§ 69c bis 69e UrhG präzisiert und teilweise abgewandelt. Im Einzelfall können auch Urheberpersönlichkeitsrechte Bedeutung erlangen, da sie – anders als die Verwertungsrechte – vom Urheber nicht übertragen werden können und dem Programmierer begrenzte Rechte an der Software sichern. a) Urheberpersönlichkeitsrechte Der Urheber hat an allen urheberrechtlich geschützten Arbeitsergebnissen Urheberpersönlichkeitsrechte. Hierzu gehören2: – – – – – – –

70

das Veröffentlichungsrecht gem. § 12 UrhG das Recht auf Anerkennung der Urheberschaft gem. § 13 Satz 1 UrhG das Recht auf Urheberbezeichnung gem. § 13 Satz 2 UrhG das Entstellungsverbot gem. § 14 UrhG das Änderungsverbot gem. § 39 UrhG das Rückrufrecht gem. § 41 UrhG das Zugangsrecht gem. § 25 Abs. 1 UrhG

Der urheberpersönlichkeitsrechtliche Schutz für Computerprogramme ist 71 allerdings im Vergleich zu sonstigen Werken stark reduziert3. Bei der kleinen Münze des Urheberrechts, zu denen in aller Regel auch Computerprogramme zählen, besteht in der Regel nur ein sehr eingeschränktes persönlichkeitsrechtliches Schutzbedürfnis, da es an ausgeprägten ideellen

1 Thum, in: Wandtke/Bullinger, Vor §§ 87a ff. Rz. 21. 2 Vgl. Dreier/Schulze, Vor § 12 Rz. 2 f. 3 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 48.

Karger

35

A Rz. 72

Grundlagen

Interessen fehlt1. Die Bestimmungen zu den Urheberpersönlichkeitsrechten werden deshalb nur teilweise angewendet bzw. teleologisch reduziert2. 72 Wird das Computerprogramm im Rahmen eines Arbeitsverhältnisses erstellt, so gehen die diesbezüglichen vermögensrechtlichen Befugnisse gem. § 69b Abs. 1 UrhG im Wege einer gesetzlichen Lizenz auf den Arbeitgeber über. Die Urheberpersönlichkeitsrechte werden hiervon nicht erfasst, da sie nicht zu den „vermögensrechtlichen Befugnissen“ i.S.v. Verwertungsrechten gehören3. Im Rahmen von Arbeitsverhältnissen werden die Urheberpersönlichkeitsrechte allerdings besonders stark eingeschränkt, um die vermögensrechtliche Zuordnung der Verwertungsrechte zum Arbeitgeber gem. § 69b UrhG nicht zu unterlaufen4. aa) Veröffentlichungsrecht 73 Dem Urheber steht grundsätzlich das Veröffentlichungsrecht gem. § 12 UrhG zu. Im Hinblick auf Computerprogramme wird allgemein unterstellt, dass der Urheber in der Regel mit der Übergabe des Werkes bzw. bei der Einräumung von Nutzungsrechten konkludent auf das Recht verzichtet5. bb) Recht auf Anerkennung der Urheberschaft 74 Gemäß § 13 Satz 1 UrhG kann der Urheber auf das Recht auf Anerkennung der Urheberschaft nicht verzichten. Ob eine Herstellerangabe, die keinen Hinweis auf den Urheber bzw. die Urheber enthält, insbesondere eines Copyright-Vermerks, der nur das vertreibende Unternehmen benennt, eine Rechtsverletzung darstellt, ist umstritten6. Für den Anbieter eines Computerprogramms kann es empfehlenswert sein, sich vom Urheber schuldrechtlich das Recht einräumen zu lassen, neben diesem gegen die Urheberbehauptung Dritter vorgehen zu können7. cc) Recht auf Urhebernennung 75 Gem. § 13 Satz 2 UrhG besteht ein Recht zur Urheberbenennung. Bei Software ist es in der Praxis nicht üblich, den Namen des Urhebers beim Programmstart im Programm bzw. auf den Oberflächen oder im Begleitmaterial zu nennen. In der Regel findet sich allenfalls ein Hinweis auf das Unternehmen, das im Markt als Hersteller auftritt. Eine konsequente Beachtung des Rechts auf Urheberbenennung stößt auf praktische Probleme: So wären bei einer Mehrzahl von mitwirkenden Personen lange Aufzählungen der (Mit-)Urheber erforderlich, die bei Aktualisierung der Programme (z.B. im 1 2 3 4 5 6 7

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 48. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 48. Vgl. Redeker, IT-Recht, Rz. 30. Vgl. hierzu Grützmacher, in: Wandtke/Bullinger, § 69b Rz. 38 ff. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 49. Vgl. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 50 m.w.N. Vgl. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 50.

36

Karger

Schutz und Realisierung der Software

Rz. 77 A

Rahmen der Pflege) stets revidiert und gegebenenfalls erweitert werden müssten. Diese Probleme können allerdings bei entsprechender Organisation der Prozesse durch den Hersteller überwunden werden. Gleichwohl sind durch das Recht auf Urhebernennung nach wohl h.M. die wirtschaftlichen Interessen des Programmherstellers so erheblich beeinträchtigt, dass es als ausreichend erachtet wird, wenn der Urheber beispielsweise nur im Handbuch genannt wird1. Teilweise wird ein Namensnennungsrecht für den Bereich der Computerspiele bejaht, für die sonstigen Bereiche aber ganz abgelehnt2. Das Recht auf Namensnennung ist in Übrigen verzichtbar3. Ein stillschweigender Verzicht wird angenommen, wenn eine entsprechende Branchenübung besteht und der Urheber hiervon Kenntnis hat. Eine solche Branchenübung wird für kommerzielle Programme bejaht, und zwar nicht lediglich nur innerhalb eines bestehenden Arbeitsverhältnisses, sondern auch für den Bereich von freien Mitarbeitern und Subunternehmern4. dd) Entstellungsverbot Nach § 14 UrhG hat der Urheber das Recht, Entstellungen oder Beeinträch- 76 tigungen zu verbieten, wenn diese geeignet sind, seine berechtigten Interessen am Werk zu gefährden. Nach einer in der Literatur vertretenen Auffassung ist § 14 UrhG nicht auf Computerprogramme anwendbar. Jedenfalls dürfte § 14 UrhG der Weiterentwicklung, Aktualisierung oder der Portierung von Programmen nicht entgegenstehen5. ee) Änderungsverbot Nach § 39 Abs. 2 UrhG sind nur solche Änderungen des Werks zulässig, zu 77 denen der Urheber seine Einwilligung nach Treu und Glauben nicht versagen kann. Dieses Änderungsverbot findet grundsätzlich auch auf Computerprogramme Anwendung. Regelmäßig wird der Urheber die Änderungsbefugnis gemäß § 39 Abs. 2 UrhG jedoch auf Grund der Branchenüblichkeit einräumen6; dies erfolgt im Arbeitsverhältnis grundsätzlich stillschweigend, im Übrigen konkludent z.B. durch die Einräumung ausschließlicher Nutzungsrechte oder durch die Überlassung des Quellcodes zur Nutzung7. Im Übrigen darf in Ansehung von § 69d Abs. 1 UrhG die Fehlerberichtung durch den zur Verwendung des Programms Berechtigten nicht untersagt

1 2 3 4

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 51. Redeker, IT-Recht, Rz. 40. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 51. Vgl. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 51; Redeker, IT-Recht, Rz. 40. 5 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 52. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 71. 7 Redeker, IT-Recht, Rz. 39.

Karger

37

A Rz. 78

Grundlagen

werden; insoweit besteht eine Duldungspflicht des Urhebers nach § 39 Abs. 2 UrhG1. ff) Rückrufrecht 78 Gemäß § 41 UrhG hat der Urheber ein Rückrufrecht wegen Nichtausübung, wenn der Inhaber eines ausschließlichen Nutzungsrechts dieses nicht oder nur unzureichend ausübt und dadurch berechtigte Interessen des Urhebers erheblich verletzt werden. Im Fall des Rückrufs erlischt das eingeräumte Nutzungsrecht. Bei Programmerstellung im Arbeitsverhältnis steht das Recht dem Urheber regelmäßig deshalb nicht zu, weil sämtliche wirtschaftlichen Entscheidungen und Befugnisse gemäß § 69b UrhG auf den Arbeitgeber übergehen und er seine Bezüge für die erbrachten Leistungen erhält. Ähnlich ist die Interessenlage zu beurteilen, wenn die Leistungen des Programmierers durch eine Einmalvergütung abgegolten wurden2. Ein Rückrufrecht kann allerdings dann bestehen, wenn z.B. eine Umsatzbeteiligung vereinbart wurde und der Auftraggeber das Programm nicht bzw. nicht in der gebotenen Art und Weise vermarktet3. Ein Recht zum Rückruf besteht gem. § 41 Abs. 1 Satz 1 UrhG, wenn der Vertreiber sein ausschließliches Nutzungsrecht an der Software überhaupt nicht ausübt, weil er seinen Geschäftsbetrieb vollständig eingestellt hat4. Ein berechtigtes Interesse des Urhebers, das von ihm entwickelte Programm wieder selbst zu nutzen, ist jedenfalls dann zu bejahen, wenn der Vertreiber die ihm eingeräumten Nutzungsrechte seit viereinhalb Jahren nicht mehr ausübt5. Das Rückrufrecht wegen gewandelter Überzeugung gem. § 42 UrhG spielt bei der Erstellung von Computerprogrammen regelmäßig keine Rolle, da in der Regel keine Beeinträchtigung ideeller Interessen vorliegt6. gg) Zugangsrecht 79 Gem. § 25 UrhG kann der Urheber Zugang zu Werkstücken verlangen, soweit dies zur Herstellung von Vervielfältigungstücken oder zur Bearbeitung erforderlich ist und keine berechtigten Interessen des Herstellers entgegenstehen. Bei der Übertragung ausschließlicher Nutzungsrechte sowie Rechtsübergang im Rahmen eines Arbeitsverhältnisses dürfte ein Zugangsrecht entfallen, da in diesen Fällen i.d.R. kein Recht des Programmierers zur Vervielfältigung bzw. Bearbeitung mehr besteht7. Im Übrigen begründet der Schutz von Betriebs- und Geschäftsgeheimnissen regelmäßig ein berechtig1 Redeker, IT-Recht, Rz. 39. 2 Hoeren, Die Kündigung von Softwareerstellungsverträgen und deren urheberrechtliche Auswirkungen, CR 2005, 773, 775; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 72. 3 Redeker, IT-Recht, Rz. 41. 4 OLG Köln v. 8.4.2005 – 6 U 194/04, CR 2005, 624 f. 5 OLG Köln v. 8.4.2005 – 6 U 194/04, CR 2005, 625. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 54. 7 Redeker, IT-Recht, Rz. 43.

38

Karger

Schutz und Realisierung der Software

Rz. 81 A

tes Interesse des Auftraggebers i.S.v. § 25 UrhG, so dass dem Urheber insbesondere bei auf dem Markt erhältlicher Software regelmäßig der Zugang verwehrt werden kann1. Auf das Recht aus § 25 UrhG kann im Übrigen verzichtet werden2. b) Verwertungsrechte Die Verwertungsrechte für Computerprogramme sind in § 69c UrhG aus- 80 drücklich geregelt. Diese Bestimmung geht – soweit es um Computerprogramme geht – den §§ 16, 17, 19a und 23 UrhG als Sonderregelung vor. § 69c UrhG gewährt dem Rechtsinhaber ausschließliche Rechte. Diese umfassen das positive Benutzungsrecht sowie das negative Verbietungsrecht3. Dem Urheber vorbehaltene Rechte sind das Recht der Vervielfältigung, das Recht der Übersetzung und Bearbeitung, das Verbreitungsrecht einschließlich des Vermietrechts und das Recht der öffentlichen Wiedergabe. Rechtsinhaber ist der Urheber, d.h. der Schöpfer der Software i.S.v. § 7 UrhG. Dies gilt auch für die Erstellung von Computerprogrammen durch Arbeitnehmer; allerdings bewirkt hier § 69b Abs. 1 UrhG, dass der Arbeitnehmer zwar originärer Rechtsinhaber im Zeitpunkt der Erstellung ist, die Verwertungsrechte aber eine logische Sekunde später aufgrund einer gesetzlichen Lizenz auf den Arbeitgeber übergehen, so dass dieser Rechtsinhaber wird4. Bei Miturheberschaft sind alle Miturheber Rechtsinhaber gem. § 8 UrhG. aa) Vervielfältigungsrecht Nach § 69c Nr. 1 UrhG bedarf die dauerhafte oder vorübergehende vollstän- 81 dige oder teilweise Vervielfältigung eines Computerprogramms mit jedem Mittel und in jeder Form der Zustimmung des Urhebers. Der Begriff der Vervielfältigung wird in § 69c Nr. 1 UrhG nicht definiert. Vorrangig ist an den technischen Vorgang der Vervielfältigung anzuknüpfen. Nach allgemeiner Auffassung wird unter einem Vervielfältigungsstück jede körperliche Festlegung eines Werks verstanden, die dazu geeignet ist, das Werk den menschlichen Sinnen mittelbar oder unmittelbar wahrnehmbar zu machen5. Damit stellen jedenfalls das Kopieren des Computerprogramms auf einen selbständigen verkehrsfähigen Datenträger (etwa auf Festplatte, Memory-Stick, DVD, CD-ROM, Diskette oder Magnetband) und das Ausdrucken des Programmcodes eine Vervielfältigung dar6. Nach h.M. ist auch das 1 2 3 4 5

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 54. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 54. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 2. Vgl. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 3. Vgl. Haberstumpf, Der urheberrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, 2. Aufl. 1993, II, Rz. 116 m.w.N. 6 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 4.

Karger

39

A Rz. 82

Grundlagen

(vorübergehende) Laden des Programms in den Arbeitsspeicher ein Vervielfältigungsvorgang1. Das Ablaufenlassen des Programms im Rechner ist nach h.M. keine Vervielfältigung2. Die Darstellung auf dem Bildschirm stellt mangels Verkörperung ebenfalls keine Vervielfältigung dar3. bb) Umarbeitungsrecht 82 Nach § 69c Nr. 2 UrhG hat der Rechtsinhaber das ausschließliche Recht zur Übersetzung, Bearbeitung, zum Arrangement und zu anderen Umarbeitungen eines Computerprogramms sowie zur Vervielfältigung der erzielten Ergebnisse. Übersetzungen sind vor allem die Übertragung eines Programms in eine andere Programmiersprache sowie vom Quellcode in den Objektcode und umgekehrt4. 83 Bearbeitungen und sonstige Umarbeitungen sind insbesondere die Ergänzung des Quellcodes oder Objektcodes; auch neue Releases, Updates, Upgrades und sonstige Aktualisierungen, sofern der Code verändert wird5. Eine Bearbeitung bzw. Umarbeitung setzt grundsätzlich einen Eingriff in den Code voraus6. Keine Bearbeitung stellt das Customizing auf Basis der im Programm bereits vorhandenen Einstellungsoptionen dar, wenn hierfür keine Eingriffe in die Programmsubstanz erforderlich sind7. 84 Gem. § 69c Nr. 2 Satz 2 UrhG kann den Personen, die das Computerprogramm bearbeiten, ein eigenes Urheberrecht aus dieser Bearbeitung erwachsen. Diesbezüglich ist keine persönliche, sondern in Anlehnung an § 69a Abs. 3 UrhG lediglich eine eigene geistige Schöpfung erforderlich8. Als abhängiges Urheberrecht gestattet das Bearbeiterurheberrecht die Verwertung nur bei Zustimmung sowohl des Inhabers der Rechte am Originalprogramm als auch des Inhabers der Rechte an der Bearbeitung9. 85 Zulässig bleibt die sog. freie Bearbeitung gem. § 24 UrhG, d.h. die Schaffung und Verwertung eines selbständigen Werkes unter freier Benutzung des Originals. Eine freie Benutzung liegt vor, wenn das benutzte Werk nicht mehr 1 Schricker/Loewenheim, § 69c Rz. 7; Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 5. 2 Marly, Praxishandbuch Softwarerecht, Rz. 159 ff., 161; Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 7. 3 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 8. 4 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 18. 5 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 20. 6 Weiterführend zur Reichweite des Begriffs „Bearbeitung“ Spindler, CR 2012, 417, 418 ff. 7 Vgl. Koch, Urheberrechtsschutz für das Customizing von Computerprogrammen, ITRB 2005, S. 140 f.; Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 20. 8 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 22; str. 9 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 22; Dreier/Schulze, § 69c Rz. 18.

40

Karger

Schutz und Realisierung der Software

Rz. 87 A

als nachgeahmtes Vorbild, sondern lediglich als Anregung fungiert und gegenüber der Individualität des neu geschaffenen Werks in den Hintergrund tritt1. Die Grenzziehung zwischen freier Bearbeitung i.S.v. § 24 UrhG und zustimmungsbedürftiger unfreier Bearbeitung gem. § 69c Nr. 2 UrhG bereitet bei Computerprogrammen erhebliche Schwierigkeiten2. Die Abgrenzung wird nicht alleine im Weg eines Vergleichs beider Werke auf tatsächliche Übereinstimmungen, sondern auch anhand einer Güterabwägung vorgenommen, in welche die Interessenlage der Parteien, die Schöpfungshöhe des benutzten Werks und das Allgemeininteresse am wissenschaftlich-technischen Fortschritt mit eingestellt werden3. Wie weit der Schutz eines Softwareprogramms vor einer Umarbeitung reicht, hängt maßgeblich von der Individualität des Programms ab. Von besonders originellen Werken ist ein überdurchschnittlich weiter Abstand zu halten4. cc) Verbreitungsrecht Nach § 69c Nr. 3 Satz 1 UrhG steht dem Rechtsinhaber jede Form der Verbreitung des Originals eines Computerprogramms oder von Vervielfältigungsstücken einschließlich der Vermietung zu.

86

(1) Verbreitung Die Verbreitung i.S.v. § 69c Nr. 3 UrhG umfasst gem. § 17 UrhG sowohl das Anbieten gegenüber der Öffentlichkeit als auch das Inverkehrbringen. Unter Anbieten ist jedes Auffordern zum Eigentums- oder Besitzerwerb zu verstehen. Ein Anbieten liegt bereits dann vor, wenn das öffentliche Angebot abstrakt und unbestimmt bleibt5. Es ist unerheblich, ob das Anbieten erfolgreich war oder das Vervielfältigungsstück bereits erstellt ist6. Inverkehrbringen ist jede Handlung, durch die das Computerprogramm aus einem abgeschlossenen persönlichen oder betrieblichen Bereich in die Öffentlichkeit gebracht wird7. Entscheidend ist die Besitzüberlassung. Die Veräußerung ist nicht erforderlich. Auch das Vermieten und das Verleihen werden erfasst8.

1 Vgl. Haberstumpf, Der urheberrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, II, Rz. 141. 2 Redeker, IT-Recht, Rz. 62. 3 Vgl. Haberstumpf, Der urheberrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, II, Rz. 141; Redeker, IT-Recht, Rz. 62; Schricker/Loewenheim, § 69c Rz. 16 f. 4 Vgl. Haberstumpf, Der urheberrechtliche Schutz von Computerprogrammen, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, II, Rz. 141. 5 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 26. 6 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 26. 7 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 25. 8 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 25.

Karger

41

87

A Rz. 88

Grundlagen

Erforderlich ist die Verbreitung eines Originals oder eines Vervielfältigungsstücks. (2) Erschöpfung des Verbreitungsrechts 88 Wird ein Vervielfältigungsstück eines Computerprogramms mit Zustimmung des Rechtsinhabers im Weg der Veräußerung im Gebiet der Europäischen Gemeinschaften oder eines anderen Vertragsstaats des Abkommens über den Europäischen Wirtschaftsraum in Verkehr gebracht, so erschöpft sich das Verbreitungsrecht in Bezug auf dieses Vervielfältigungsstück mit Ausnahme des Vermietrechts, § 69c Nr. 3 Satz 2 UrhG. Dieser Erschöpfungsgrundsatz besagt, dass entsprechende legitim erworbene Vervielfältigungsstücke vom Erwerber ohne Zustimmung des Rechtsinhabers weiter veräußert werden dürfen1. Lange Zeit war umstritten, ob es sich bei den „Vervielfältigungsstück“ um ein auf einem Trägermedium verkörperte Kopie des Programms handeln musste oder ob auch eine „unkörperliche“ Veräußerung des Programms (insbesondere im Wege des „Downloads“) zu einer Erschöpfung des Verbreitungsrecht führt2. Nach der Rechtsprechung des EuGH tritt die Erschöpfung sowohl bei körperlicher als auch bei unkörperlichem Erwerb ein, die Online-Programmkopie und die Kopie auf materiellem Datenträger werden also einander gleichgestellt3. Weiter ist ein „Verkauf“ der Programmkopie erforderlich. Nach der Rechtsprechung des EuGH liegt ein Verkauf vor, wenn der Nutzer ein unbefristetes Recht an der Programmkopie gegen Zahlung eines Entgelts erhält4. Eine lediglich zeitweise Nutzungsüberlassung im Wege Miete reicht damit nicht aus. Die Veräußerung muss mit Zustimmung des Rechtsinhabers erfolgt sein. Diese muss sich auf das konkrete Werkstück bzw. den konkreten Datenbestand und auf die konkrete Nutzungsart beziehen5. Die Zustimmung zu einem Inverkehrbringen außerhalb von EU und EWR reicht nicht aus6. 89 Von der Erschöpfung ist gem. § 69c Nr. 3 Satz 2 UrhG das Recht zur Vermietung explizit ausgenommen. Vermieten ist die entgeltliche und zeitlich

1 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 34; Redeker, IT-Recht, Rz. 55. 2 Hierzu Schneider/Spindler, CR 2012, 489 ff. 3 EuGH v. 3.7.2012 – Rs. C-128/11 – UsedSoftGmbH vs. Oracle International Corp., CR 2012, 498; hierzu Schneider/Spindler, CR 2012, 489 ff.; Moritz, K&R 2012, 2102, 456; Senftleben, NJW 2012, 2924; Marly, EuZW 2012, 654, hierzu auch BHG v. 17.7.2013 – I ZR 129/08 – UsedSoft II. 4 EuGH v. 3.7.2012 – Rs. C-128/11 – UsedSoftGmbH vs. Oracle International Corp., CR 2012, 498, 499. 5 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 33. 6 Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 33.

42

Karger

Rz. 92 A

Schutz und Realisierung der Software

befristete körperliche Gebrauchsüberlassung1. Hierzu zählt typischerweise die Softwaremiete bzw. die Gebrauchsüberlassung auf Basis eines zeitlich befristeten Lizenzvertrags mit regelmäßig wiederkehrenden Lizenzgebühren. Allerdings präjudiziert die vertragsrechtliche Typisierung die urheberrechtliche Zuordnung nicht; entscheidend ist vielmehr, dass eine zeitliche Befristung gegeben ist2. So kann insbesondere bei Kaufverträgen mit Umtausch- oder Rückgabeoptionen, u.U. auch beim Kauf auf Probe gem. § 454 BGB, urheberrechtlich ein Vermieten vorliegen3. Unter die Kategorie der „Vermietung“ fällt grundsätzlich auch das Software-Leasing. Erwirbt damit der Leasinggeber die Software zum Zweck der zeitlich befristeten Überlassung an den Leasingnehmer, muss er sicherstellen, dass er vom Rechteinhaber auch das erforderliche Vermietrecht („Rental Rights“) eingeräumt erhält4.

90

dd) Recht der öffentlichen Wiedergabe und Recht der öffentlichen Zugänglichmachung Gem. § 69c Nr. 4 UrhG hat der Rechtsinhaber das ausschließliche Recht der drahtgebundenen oder drahtlosen öffentlichen Wiedergabe eines Computerprogramms einschließlich der öffentlichen Zugänglichmachung in der Weise, dass es Mitgliedern der Öffentlichkeit von Orten und zu Zeiten ihrer Wahl zugänglich ist. Die Vorschrift gilt speziell für Computerprogramme, für alle sonstige Werke gilt § 19a UrhG.

91

Eine öffentliche Wiedergabe liegt vor, wenn das Computerprogramm einer Vielzahl von nicht persönlich verbundenen Nutzern gleichzeitig oder sukzessive in unkörperlicher Form wahrnehmbar oder zugänglich gemacht wird5. Maßgeblich hierfür ist die Definition des § 15 Abs. 3 UrhG. Das Recht der öffentlichen Zugänglichmachung ist eine spezielle Ausprä- 92 gung des Rechts der öffentlichen Wiedergabe. Es bezieht sich von seiner praktischen Bedeutung her im Wesentlichen auf die Nutzung von Werken in elektronischen Netzen, insbesondere im Internet6. Das Recht der öffentlichen Zugänglichmachung unterscheidet sich vom Recht der öffentlichen Wiedergabe dadurch, dass es interaktive Übertragungen auf Abruf erfasst, da es auf die Wahlmöglichkeit des Nutzers abstellt, von welchem Ort und zu welchem Zeitpunkt er auf das Programm zugreift7. § 69c Nr. 4 UrhG erfasst die interaktive Zugänglichmachung von Computerprogrammen über Netzwerke. Dies kann ein Local Area Network (LAN), z.B. ein betriebseigenes Intranet sein. Erfasst sind auch Wide Area Networks 1 2 3 4 5 6 7

Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 43. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 43. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 43. Weiterführend hierzu Vander, CR 2011, 77. OLG München v. 7.2.2008 – 29 U 3520/07 (ASP), CR 2009, 500. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 51. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 51.

Karger

43

A Rz. 93

Grundlagen

(WAN), insbesondere auch das Internet bzw. das WWW, da eine räumliche Verbundenheit der Nutzer gem. § 69c Nr. 4 UrhG nicht erforderlich ist1. 93 Maßgebliche, dem Rechtsinhaber vorbehaltene Verwertungshandlung ist das „Zugänglichmachen“: Geschützt wird dadurch als ausschließliches Verwertungsrecht jedes Verhalten, das geschützte Werk zum Abruf im Netz anzubieten, bzw. bereitzuhalten2. Die Übertragungshandlung selbst, also insbesondere der Upload bzw. der Download, stellt ebenfalls ein Zugänglichmachen und damit eine urheberrechtsrelevante Handlung i.S.v. § 69c Nr. 4 UrhG dar3. 94 Das Computerprogramm muss gem. § 15 Abs. 3 UrhG einer Vielzahl von Personen zugänglich gemacht werden. Dies bedeutet, dass eine zielgerichtete Zugänglichmachung eines Computerprogramms an eine bestimmte Person nicht unter § 69c Nr. 4 UrhG fällt4. § 69c Nr. 4 UrhG unterfällt damit z.B. die Zugänglichmachung von Patches oder Updates durch das unbeschränkte Bereitstellen von Programmen im Internet5. Der Personenkreis darf nicht persönlich verbunden sein. Eine persönliche Verbindung wird z.B. verneint für die Beschäftigten eines Betriebs6 bzw. bezüglich der Nutzer von konzernweiten internationalen Netzen7. c) Zustimmungsfreie Maßnahmen, §§ 69d und 69e UrhG 95 Nach den §§ 69d und 69e UrhG bedürfen bestimmte Maßnahmen – bei Vorliegen der entsprechenden gesetzlichen Voraussetzungen – nicht der Zustimmung des Rechtsinhabers. aa) Relevanz für die Softwareerstellung 96 Die Bestimmungen sehen zum einen Beschränkungen der Rechte des Urhebers an dem von ihm selbst geschaffenen Programm und damit zugleich Mindestrechte des berechtigten Nutzers vor. Zum anderen haben die Bestimmungen aber auch Relevanz im Hinblick auf von anderen Herstellern erstellte Computerprogramme, die dem Softwareentwickler als „Vorbild“ für das eigene Entwicklungsprojekt dienen sollen. Diesbezüglich stellt sich die Frage, inwieweit ein Programmierer ein erworbenes Werkstück analysieren und die so gewonnenen Erkenntnisse für die zu erstellende Software verwenden darf. Insoweit sind primär § 69d Abs. 3 UrhG und § 69e UrhG von Interesse. Danach darf der Berechtigte in Grenzen das Funktio1 2 3 4 5 6 7

Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 51. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 52. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 53. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 54. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 54. Grützmacher, in: Wandtke/Bullinger, § 69c Rz. 54. Lehmann, Die IT-relevante Umsetzung der Richtlinie Urheberrecht in der Informationsgesellschaft, CR 2003, 553, 556.

44

Karger

Schutz und Realisierung der Software

Rz. 99 A

nieren des Programms beobachten, untersuchen oder testen, um die einem Programmelement zugrunde liegenden Ideen und Grundsätze zu ermitteln, bzw. das Programm dekompilieren, um Informationen zur Herstellung der Interoperabilität des Programms mit anderen Programmen zu gewinnen. Vorab ist jedoch bereits festzuhalten, dass diese Bestimmungen dem Softwareersteller nur sehr eng begrenzte Möglichkeiten geben und keinesfalls eine vollständige Analyse des Fremdprogramms oder gar die Übernahme von Elementen dieses Programms legitimeren. Vielmehr bringt jede „Anleihe“ an Fremdprogrammen gleich welcher Art stets die Gefahr einer Rechtsverletzung mit sich, wobei nicht nur das Urheberrecht, sondern auch das Wettbewerbsrecht und andere Schutzrechtssysteme zu berücksichtigen sind. bb) Zustimmungsfreie Maßnahmen gem. § 69d UrhG Die Rechte des Rechtsinhabers an dem Computerprogramm werden all- 97 gemein durch § 69d UrhG begrenzt. § 69d UrhG gewährt dem berechtigten Nutzer bestimmte Mindestbefugnisse, die nicht der Zustimmung des Rechtsinhabers bedürfen. Die Rechtsnatur des § 69d UrhG ist umstritten. Teilweise wird die Vorschrift in erster Linie als Schrankenvorschrift verstanden1, teilweise als gesetzliche Lizenz2. Die Bestimmungen des § 69d UrhG sind gem. § 69e UrhG zwingendes Recht und können nicht wirksam abbedungen werden. (1) Berechtigter Nutzer Berechtigter Nutzer i.S.v. § 69d UrhG ist sowohl der Käufer bzw. der sons- 98 tige Erwerber eines Vervielfältigungsstücks des Computerprogramms als auch der Lizenznehmer3. (2) Vervielfältigung bzw. Umarbeitung Gem. § 69d Abs. 1 UrhG bedarf die Vervielfältigung oder eine Umarbeitung dann nicht der Zustimmung des Rechtsinhabers, wenn sie für eine bestimmungsgemäße Benutzung des Computerprogramms einschließlich der Fehlerberichtigung durch einen zur Verwendung eines Vervielfältigungsstücks Berechtigten notwendig ist. Was die bestimmungsgemäße Nutzung ausmacht, ist im Einzelfall oft schwer festzustellen. Der Begriff umfasst sowohl lediglich schuldrechtliche Einwilligungen bzw. Beschränkungen als auch dinglich wirkende Einräumungen der Nutzungsrechte4. Im Prinzip kann die bestimmungsgemäße 1 Schricker/Loewenheim, § 69d Rz. 1. 2 Redeker, IT-Recht, Rz. 63, ähnlich wohl auch Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 3; Dreier/Schulze, § 69d Rz. 2: „Mischform zwischen gesetzlicher Lizenz und vertraglicher Auslegungsvorschrift“. 3 Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 24. 4 Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 6.

Karger

45

99

A Rz. 100

Grundlagen

Nutzung auch vertraglich festgelegt werden, wobei es aber einen zwingenden Kern von Mindestbefugnissen gibt, der nicht abbedungen werden kann1. Im konkreten Fall sind der Überlassungszweck und sonstige vertragliche Umstände zu berücksichtigen2. 100

Laden, Anzeigen und Ablaufenlassen, Übertragen oder Speichern des Computerprogramms im Arbeitsspeicher sind als notwendige Vervielfältigungshandlungen regelmäßig zulässig und können dem berechtigten Nutzer hinsichtlich der Nutzung an einem Einzelplatzrechner nicht wirksam untersagt werden3. Eine Mehrfachnutzung des Computerprogramms, z.B. in einem Netzwerk oder in Form einer Rechenzentrumsnutzung darf der Rechtsinhaber hingegen vertraglich beschränken4. Unabdingbar ist grundsätzlich auch das Recht zur Fehlerberichtigung5. Hierzu gehört z.B. die Beseitigung von Viren. Aus § 69d Abs. 1 UrhG ergibt sich allerdings grundsätzlich kein Recht zur Dekompilierung zum Zweck der Fehlerberichtigung. Im Schrifttum wird aber die Auffassung vertreten, dass ausnahmsweise aufgrund schwerer, nutzungsverhindernder Fehler eine punktuelle Dekompilierung zulässig ist, wenn der Hersteller die zur Fehlerbeseitigung erforderlichen Informationen trotz Anfrage nicht bereitstellt6. Erlaubte Umarbeitungen können in bestimmten Grenzen notwendige Programmverbesserungen sowie Anpassungen an gesetzliche Änderungen sein7. (3) Sicherungskopie

101

Gem. § 69d Abs. 2 UrhG darf die Erstellung einer Sicherungskopie durch eine Person, die zur Benutzung des Programms berechtigt ist, vertraglich nicht untersagt werden, wenn sie für die Sicherung künftiger Benutzung erforderlich ist. Unter einer Sicherungskopie ist eine Kopie eines Programms auf einem beliebigen Datenträger zu verstehen, auf die zurückgegriffen wird, wenn das Originalprogramm aus irgendwelchen Gründen nicht mehr nutzbar ist8. An der Erforderlichkeit fehlt es, wenn der Nutzer vom Hersteller eine brauchbare und dauerhafte Sicherheitskopie erhalten hat9. (4) Beobachtung, Untersuchung und Testen

102

Im Rahmen der Softwareerstellung wird § 69d Abs. 3 UrhG praxisrelevant, wenn der Softwareentwickler andere Computerprogramme analysiert, um Erkenntnisse für das eigene Projekt zu gewinnen. 1 2 3 4 5 6

Redeker, IT-Recht, Rz. 63; Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 33 ff. OLG Düsseldorf v. 29.5.2001 – 20 U 166/00, CR 2002, 95, 96 f. Redeker, IT-Recht, Rz. 64; Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 9. Redeker, IT-Recht, Rz. 64; Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 10 ff. Redeker, IT-Recht, Rz. 65. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 22; ähnlich Redeker, IT-Recht, Rz. 68. 7 Redeker, IT-Recht, Rz. 66; Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 21. 8 Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 53. 9 Redeker, IT-Recht, Rz. 73.

46

Karger

Schutz und Realisierung der Software

Rz. 104 A

Nach § 69d Abs. 3 UrhG darf ein zur Verwendung eines Vervielfältigungsstücks Berechtigter das Funktionieren des Programms beobachten, untersuchen oder testen, um die einem Programmelement zugrunde liegenden Ideen und Grundsätze zu ermitteln, wenn dies durch Handlungen zum Laden, Anzeigen, Ablaufen, Übertragen oder Speichern des Programms geschieht, zu denen er berechtigt ist. Die Analyse darf nur von einem zur Verwendung des Vervielfältigungsstücks Berechtigten vorgenommen werden. Berechtigter Nutzer i.S.v. § 69d UrhG ist sowohl der Käufer bzw. der sonstige Erwerber eines Vervielfältigungsstücks des Computerprogramms als auch der Lizenznehmer1. Der Berechtigte braucht die Analyse nicht selbst vorzunehmen, er kann sie auch durch Dritte vornehmen lassen2. Das Recht ist aber nicht übertragbar3. Außerdem dürfen nur Handlungen vorgenommen werden, zu denen der Handelnde auch berechtigt ist4. Beobachten ist der rein passive Vorgang der Wahrnehmung des Programms 103 bei der Benutzung; Testen erlaubt seiner Bedeutung nach lediglich, dass Testdaten zur genauen Ergründung des Funktionierens des Programms benutzt werden dürfen5. Das Untersuchen darf nur durch Handlungen zum Laden, Anzeigen, Ablaufen, Übertragen oder Speichern des Programms erfolgen; weiter gehende Maßnahmen, insbesondere eine Änderung oder Bearbeitung sind hingegen unzulässig6. Die Handlungen sind zulässig, wenn sie zur Ermittlung der einem Programmelement zugrunde liegenden Ideen und Grundsätze dienen; nicht erlaubt ist die Ermittlung und Untersuchung des Programmcodes selbst7. Anders als das Recht zur Dekompilierung gem. § 69e UrhG8 ist die Pro- 104 grammanalyse gem. § 69d UrhG nicht auf bestimmte Zwecke beschränkt. Die zugrunde liegenden Ideen und Grundsätze dürfen zu unterschiedlichen Zwecken genutzt werden, z.B. zur Ermittlung inoffizieller und undokumentierter Schnittstellen, zur Dokumentation von Alt-Programmen oder zur Fehlersuche9. Die Ergründung der Ideen und Grundsätze kann insbesondere auch zur Know-how-Gewinnung erfolgen10. Erlaubt sind grundsätzlich auch Handlungen, die der funktionellen Imitation eines Programms dienen, sofern dabei nicht Vervielfältigungen des schöpferischen Teils des Programms vorgenommen werden11. Allerdings birgt jede Imitation die Gefahr 1 2 3 4 5 6 7 8 9 10 11

Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 24. Schricker/Loewenheim, § 69d Rz. 24. Schricker/Loewenheim, § 69d Rz. 24. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 66. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 63. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 63. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 65. Dazu nachfolgend Rz. 106 ff. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 65. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 65. Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 65.

Karger

47

A Rz. 105

Grundlagen

in sich, dass der Softwareentwickler die Grenzen des rechtlich Zulässigen überschreitet. Hierbei sind nicht nur das Urheberrecht, sondern gegebenenfalls auch das Wettbewerbsrecht1 und andere Schutzbestimmungen zu beachten. Außerdem zieht die Rechtsprechung die Grenzen des nach § 69d Abs. 3 UrhG Erlaubten eher eng. So wurde etwa die Nachprogrammierung der inneren Struktur eines Programms mit der Begründung für unzulässig gehalten, dass aus der Befugnis gem. § 69d Abs. 3 UrhG nicht folgt, dass man die so gewonnenen Ergebnisse dazu einsetzen darf, ein Konkurrenzprodukt zu schaffen, das inhaltlich eine in einer anderen Programmsprache geschaffene nahezu identische Nachbildung ist2. In der Literatur ist diese Rechtsprechung allerdings auf Ablehnung gestoßen3. 105

Bei der Softwareerstellung ist folglich darauf zu achten, dass sich das zu erstellende Programm nicht in unzulässiger Weise an vorbestehende Werke anlehnt und dass nachweisbar ein eigenständiger Lösungsweg beschritten wird. Zu diesem Zweck ist das sog. Clean-Room-Verfahren entwickelt worden4. Hierbei handelt es sich um unternehmensinterne Vorkehrungen, durch die sichergestellt wird, dass die Merkmale eines Konkurrenzprodukts nicht verbatim übernommen werden. Die dem vorbestehenden Programm zugrunde liegenden Ideen und Grundsätze des Originalprogramms werden von einem untersuchenden Team analysiert. Die mit der Erstellung des neuen Programms beauftragten Mitarbeiter erhalten lediglich diese Informationen über das grundlegende Design. Der Programmcode selbst wird ihnen aber vorenthalten, so dass vom Entwicklungsteam selbständige Lösungswege gesucht werden müssen. Der bei der Programmentwicklung zur Verfügung stehende Spielraum zur Erarbeitung verschiedener Lösungswege ist regelmäßig so groß, dass die eigenständige Nachschaffung einer praktisch identischen Software mehr als unwahrscheinlich ist. Das gesamte Verfahren muss sorgfältig dokumentiert werden, um in einem möglichen Verletzungsprozess ausreichende Beweise für eine eigenständige Entwicklung zu haben5.

1 S. dazu Harte-Bavendamm, Wettbewerbsrechtliche Aspekte des Reverse Engineering von Computerprogrammen, GRUR 1990, 657. 2 LG Mannheim v. 17.12.1993 – 7 O 257/93, CR 1994, 627 = NJW-RR 1994, 1007, 1008. 3 Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 65. 4 S. zu Clean Room Procedures bei der Software-Entwicklung in Deutschland: Sucker, CR 1989, 468, 471 f.; Schnell/Fresca, CR 1990, 157, 159; Vinje, GRUR Int. 1992, 250, 259; zur Vorgehensweise in den USA: Soma, A Comparison of German and U.S. Experiences in Software Copyrights, ICC 1987, 751; Elkins, NEC v. Intel: A Guide To Using Clean Room Procedures As Evidence, 10 Computer/ Law Journal 453 (1990). 5 Grützmacher, in: Wandtke/Bullinger, § 69d Rz. 65.

48

Karger

Schutz und Realisierung der Software

Rz. 109 A

cc) Dekompilierung gem. § 69e UrhG Nach § 69e UrhG sind unter bestimmten Voraussetzungen Vervielfältigun- 106 gen bzw. Übersetzungen im Rahmen der Dekompilierung ohne Zustimmung des Rechtsinhabers zulässig. Die hierdurch gewonnenen Informationen dürfen jedoch nur zu eng definierten Zwecken verwendet werden. § 69e UrhG ist gem. § 69g Abs. 2 UrhG zwingendes Recht und kann nicht wirksam abbedungen werden. Die Vervielfältigung des Codes oder die Übersetzung der Codeform i.S.d. 107 § 69c Nr. 1 und 2 UrhG muss unerlässlich sein, um die erforderlichen Informationen zur Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen zu erhalten. Des Weiteren müssen folgende Bedingungen erfüllt sein: (1) Die Handlungen werden von dem Lizenznehmer oder von einer anderen zur Verwendung eines Vervielfältigungsstücks des Programms berechtigten Person oder in deren Namen von einer hierzu ermächtigten Person vorgenommen; (2) die für die Herstellung der Interoperabilität notwendigen Informationen sind für die genannten Personen noch nicht ohne Weiteres zugänglich gemacht und (3) die Handlungen beschränken sich auf die Teile des ursprünglichen Programms, die zur Herstellung der Interoperabilität notwendig sind. Nach § 69e Abs. 1 UrhG sind nur Vervielfältigungen und Übersetzungen zulässig, nicht aber sonstige Umarbeitungen1. (1) Dekompilierung Dekompilierung ist die Rückübersetzung von maschinenlesbarem Code in 108 eine höhere Programmiersprache oder in sonstigen Fachleuten verständlichen Code2. Im Kern geht es um die Rückübersetzung aus dem Objektcode in den Quellcode3. Hingegen fällt das sog. „Reverse Engineering“, nämlich Testläufe, Speicherabzüge und die Protokollierung der Signalkommunikation, nicht unter § 69e UrhG4. (2) Berechtigter Die handelnde Person muss zur Dekompilierung berechtigt sein. Berechtig- 109 ter ist nur der Lizenznehmer oder eine andere zur Verwendung eines Vervielfältigungsstücks des Computerprogramms berechtigte Person, also der Käufer oder ein sonstiger Erwerber. Der Berechtigte kann auch Fachleute beiziehen, die die Dekompilierung in seinem Namen vornehmen; ein eigenes Nutzungsrecht benötigen diese Dritten nicht5. 1 Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 4. 2 Vgl. hierzu und zu den Begriffen der Disassemblierung und Rekompilierung Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 4 f.; zum technischen Hintergrund anschaulich Marly, Praxishandbuch Softwarerecht, Rz. 223 ff. 3 Schricker/Loewenheim, § 69e Rz. 4; Redeker, IT-Recht, Rz. 96. 4 Schricker/Loewenheim, § 69e Rz. 6; Redeker, IT-Recht, Rz. 96. 5 Schricker/Loewenheim, § 69e Rz. 12.

Karger

49

A Rz. 110

Grundlagen

(3) Interoperabilität eines unabhängig geschaffenen Programms mit anderen Programmen 110

Anders als bei den nach § 69d UrhG erlaubten Handlungen ist die Dekompilierung nur für einen beschränkten Zweck zulässig: Sie muss zur Gewinnung der für die Herstellung der Interoperabilität mit anderen Programmen erforderlichen Informationen dienen.

111

Interoperabilität ist die Fähigkeit von Computerprogrammen zum Austausch von Informationen und zu deren wechselseitiger Verwendung1. Eine Dekompilierung zu anderen Zwecken, etwa zur Erforschung der dem Programm zugrunde liegenden Ideen und Grundsätze, zur Forschung, zur Anpassung, zur Fehlerbeseitigung bzw. zur Pflege ist ohne Zustimmung des Rechtsinhabers unzulässig2.

112

Zweck muss es sein, die Interoperabilität des geschaffenen Programms mit „anderen Programmen“ herzustellen. Damit ist zunächst die Interoperabilität zwischen dem neuen Programm und dem dekompilierten Programm erfasst, darüber hinausgehend aber auch die Interoperabilität des neuen Programms mit Drittprogrammen. Gem. § 69e UrhG ist damit auch eine Dekompilierung zulässig, wenn ein konkurrierendes, das dekompilierte Programm ersetzendes Produkt geschaffen werden soll3. Bei dem zu erstellenden Computerprogramm muss es sich um ein unabhängig geschaffenes Programm handeln. Unabhängig geschaffen ist ein Programm nur dann, wenn es nicht mit Hilfe des durch die Dekompilierung gewonnenen Codes und sonstiger Informationen und Erkenntnisse erstellt wurde4. Grundsätzlich unzulässig sind demgemäß die Übernahme des die Schnittstellen realisierenden Codes und von Elementen, die zur Herstellung der Interoperabilität nicht erforderlich sind5. Umstritten ist, ob sonstige urheberschutzfähige Elemente zur Herstellung der Interoperabilität übernommen werden dürfen6. (4) Unerlässlichkeit der Dekompilierung

113

Die Dekompilierung muss unerlässlich sein. Dies bedeutet, dass (1) die für die Herstellung der Interoperabilität erforderlichen Informationen noch nicht ohne Weiteres zugänglich gemacht sind und (2) sich die Handlungen auf die Teile des ursprünglichen Programms beschränken, die zur Herstellung der Interoperabilität erforderlich sind.

1 Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 6. 2 Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 7; Redeker, IT-Recht, Rz. 97. 3 OLG Düsseldorf v. 16.1.2001 – 20 U 142/00, CR 2001, 371, 372; Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 8; Schricker/Loewenheim, § 69e Rz. 12. 4 Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 10. 5 Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 10 f. 6 Für die Zulässigkeit im Einzelfall Schricker/Loewenheim, § 69e Rz. 18; gegen die Zulässigkeit Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 11.

50

Karger

Schutz und Realisierung der Software

Rz. 115 A

Eine Dekompilierung ist unzulässig, da nicht „unerlässlich“, wenn die erforderlichen Informationen bereits ohne Weiteres zugänglich sind. Dies ist der Fall, wenn sie dem Berechtigten bereits bekannt sind oder ihm kostenlos zur Verfügung gestellt werden, wenn sie also beispielsweise auf der Website des Herstellers veröffentlicht, oder in der Begleitdokumentation enthalten sind1. Dem Berechtigten ist auch eine Nachfrage beim Hersteller zuzumuten, sofern er die Informationen kurzfristig und ohne Komplikationen (z.B. ohne langwierige Suche nach einem Ansprechpartner) erhält2. (5) Verwendungsbeschränkungen Nach dem Verwertungsverbot3 des § 69e Abs. 2 UrhG dürfen die gewonne- 114 nen Informationen (1) nicht zu anderen Zwecken als zur Herstellung der Interoperabilität des unabhängig geschaffenen Programms verwendet werden, (2) nicht an Dritte weitergegeben werden, es sei denn, dass dies für die Interoperabilität des unabhängig geschaffenen Programms notwendig ist, und (3) nicht für die Entwicklung, Herstellung oder Vermarktung eines Programms mit im Wesentlichen ähnlicher Ausdrucksform oder für irgendwelche anderen das Urheberrecht verletzenden Handlungen verwendet werden. 8. Rechtseinräumung an den Arbeitsergebnissen Sofern die Software nicht von ihrem Schöpfer, z.B. dem Programmierer, son- 115 dern von dessen Auftraggeber, z.B. einem Softwarehaus, vermarktet wird, muss sich der Auftraggeber die erforderlichen Nutzungsrechte an den Arbeitsergebnissen einräumen lassen4. Hinsichtlich der Rechtseinräumung im Rahmen der Softwareerstellung sind verschiedene Themen von Relevanz: Grundsätzlich sind aufgrund des Trennungsprinzips das der Rechtseinräumung zugrunde liegende Verpflichtungsgeschäft sowie das in der Rechtseinräumung selbst liegende Verfügungsgeschäft auseinander zu halten5. Aufgrund des Trennungsprinzips können der Abschluss des Verpflichtungsgeschäfts und das Verfügungsgeschäft in Gestalt der Rechtseinräumung zeitlich auseinander fallen, so dass stets auch der Zeitpunkt der Rechtseinräumung zu betrachten ist6. Schließlich ist für die Praxis der Umfang der Rechtseinräumung von großer Wichtigkeit7. Sofern es hierzu an ei-

1 Redeker, IT-Recht, Rz. 98. 2 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69e Rz. 15; Redeker, IT-Recht, Rz. 98. 3 Redeker, IT-Recht, Rz. 100. 4 Die Rechtseinräumung durch das Softwarehaus an den Endkunden wird an dieser Stelle nicht weiter erörtert; s. hierzu etwa Redeker, IT-Recht, Rz. 75 ff. 5 S. im Folgenden Rz. 116 ff. 6 S. im Folgenden Rz. 134 ff. 7 S. im Folgenden Rz. 151 ff.

Karger

51

A Rz. 116

Grundlagen

ner ausdrücklichen Regelung1 fehlt, bestimmt sich der Umfang der Rechtseinräumung nach dem Zweckübertragungsgrundsatz2. a) Verpflichtungs- und Verfügungsgeschäft 116

Bei der Rechtseinräumung ist in zweifacher Hinsicht zu unterscheiden: Zum einen erfordert das im Sachenrecht wie im Urheberrecht gleichermaßen geltende Trennungsprinzip3 die Trennung zwischen Verpflichtungsund Verfügungsgeschäft. Anders als bei der Überlassung von Standardsoftware fallen bei der Softwareerstellung beide Geschäfte häufig zeitlich auseinander. Zum anderen gilt auf der Ebene des Verfügungsgeschäfts das „sachenrechtliche Trennungsprinzip“4. Danach sind das Sachenrecht des BGB und das „Urheber-Sachenrecht“ strikt auseinanderzuhalten. Dies bedeutet, dass die Übertragung des Eigentums an den verkörperten Arbeitsergebnissen und die Einräumung von Nutzungsrechten unterschiedlichen Regeln folgen und auch vertraglich getrennt voneinander zu behandeln sind. aa) Verpflichtungsgeschäft

117

Das schuldrechtliche Verpflichtungsgeschäft begründet eine Rechtsverschaffungspflicht des Auftragnehmers. Diese Pflicht bezieht sich in der Regel auf die Verschaffung des sachenrechtlichen Eigentums an verkörperten Arbeitsergebnissen, z.B. an den Handbüchern, sowie auf die Einräumung der vereinbarten Nutzungsrechte i.S.d. Urheberrechts an der Software. Als vertragliche Grundlage der Softwareerstellung kommen insbesondere ein Werkvertrag, ein Vertrag i.S.v. § 651 BGB, ein Dienst- bzw. ein Arbeitsvertrag sowie bei enger Kooperation ohne Austauschcharakter auch ein Gesellschaftsvertrag in Betracht. Maßgeblich für die Bestimmung des einschlägigen Vertragstyps sind die vereinbarten Hauptleistungspflichten. (1) Werkvertrag bzw. „Werklieferungsvertrag“ i.S.v. § 651 BGB

118

Umstritten ist, ob die Erstellung von Software dem Werkvertragsrecht unterfällt oder ob es sich hierbei um eine Leistung i.S.v. § 651 BGB handelt. Letzteres hätte zur Konsequenz, dass auf die Softwareerstellung nicht das Werkvertragsrecht, sondern überwiegend das Kaufrecht zur Anwendung kommt, was u.a. wegen des dann fehlenden Abnahmeerfordernisses im Regelfall erhebliche Probleme aufwirft5. Nach wohl überwiegender Auffassung im Schrifttum fällt die Softwareerstellung, insbesondere die individuelle Programmierleistung, nicht in den Anwendungsbereich von § 651 BGB,

1 2 3 4

Hierzu Rz. 154 ff. Hierzu Rz. 157 ff. Hierzu Schricker/Loewenheim, Vor §§ 28 ff. Rz. 98. Witte, Eigentumsanspruch und Urheberrecht bei Standardsoftware, DStR 1996, 1049, 1051. 5 S. hierzu ausführlich Schneider unter Kap. B.

52

Karger

Schutz und Realisierung der Software

Rz. 121 A

sondern unterfällt §§ 631 ff. BGB1. Diesbezüglich wird u.a. argumentiert, dass es sich bei der Softwareerstellung um eine geistige Leistung handelt, die lediglich ihre Verkörperung in einer beweglichen Sache, nämlich im Speichermedium findet. Der Vertrag erhalte sein Gepräge durch die Erbringung der geistigen Leistung und nicht durch die Herstellung und Lieferung der Sache, in der die Leistung verkörpert sei2. Im Hinblick auf den hier zu betrachtenden Gesichtspunkt der Rechts- 119 verschaffung besteht zwischen einem Werkvertrag und Vertrag i.S.v. § 651 BGB kein Unterschied: Beim Vertrag i.S.v. § 651 BGB, der in das Kaufrecht verweist, ist die Rechtsverschaffungspflicht (jedenfalls hinsichtlich des Eigentums) ausdrücklich in § 433 Abs. 1 Satz 1 BGB normiert. Für das Werkvertragsrecht fehlt es an einer ausdrücklichen Regelung zur Rechtseinräumungspflicht. Gleichwohl ergibt sich aus dem Vertragszweck eine grundsätzliche Verpflichtung zur Rechtsverschaffung3. Gelegentlich ist der Fall anzutreffen, dass der Anbieter die Software für die 120 Bedürfnisse des Auftraggebers erstellt und sie ihm anschließend nur auf Zeit überlässt, z.B. im Rahmen eines ASP-Modells. Hier liegt ein kombinierter Werk- und Mietvertrag vor4. (2) Dienstvertrag Grundlage der Softwareentwicklung kann auch ein Dienstvertrag gem. 121 § 611 BGB sein. Dies ist der Fall, sofern vom Auftragnehmer lediglich die Entwicklungs- bzw. Programmiertätigkeit, nicht aber ein Erfolg in Gestalt der Lieferung der fertigen Software geschuldet ist5. Für einen Dienstvertrag spricht, dass der Auftragnehmer in erster Linie beratende oder unterstützende Tätigkeit erbringt6, die Projektleitung beim Auftraggeber liegt und der Auftragnehmer nur unselbständige Beiträge liefert7. Für einen Dienstvertrag kann weiter sprechen, dass der Auftragnehmer in erheblichem Umfang weisungsabhängig ist oder die Entwicklung innerhalb eines größeren Teams mit mehreren Beteiligten erfolgt8. Demgegenüber bedingt die Bezeichnung des Vertrags als „Dienstleistungsvertrag“ oder die Vereinbarung einer Vergütung nach Aufwand für sich alleine noch keine Zuordnung zum Dienst1 Palandt/Sprau, Einf v § 631 Rz. 22. 2 Münchener Kommentar zum BGB/Busche, § 631 Rz. 254 m.w.N. 3 Vgl. Palandt/Sprau, § 631 Rz. 12: Verpflichtung zu Verschaffung des Eigentums; Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 169. 4 Vgl. LG Freiburg v. 29.1.1987 – 12 O 46/85, CR 1988, 382; Köhler/Fritzsche, Herstellung und Überlassung von Software, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, XIII, Rz. 136. 5 Redeker, IT-Recht, Rz. 498. 6 Vgl. OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732; OLG Köln v. 22.10.1987 – 1 U 41/84, CR 1988, 734. 7 Redeker, IT-Recht, Rz. 498. 8 LG München I v. 28.9.1995 – 7 O 534/95, CR 1996, 232; OLG München CR 1997, 27.

Karger

53

A Rz. 122

Grundlagen

vertragsrecht1. In der Rechtsprechung finden sich allerdings nur wenige Entscheidungen, in denen ein Softwareerstellungsvertrag als Dienstvertrag angesehen wird2. (3) Arbeitsvertrag und öffentlich-rechtliches Dienstverhältnis 122

Vom „freien“ Dienstvertrag sind der Arbeitsvertrag und öffentlich-rechtliche Dienstverhältnisse zu unterscheiden. Für diese gilt die für die Nutzungsrechtseinräumung wichtige Sondervorschrift des § 69b UrhG. Zuweilen ist sich der Auftraggeber nicht bewusst, dass zwischen ihm und einem vermeintlich „freien“ Programmierer anstelle eines Dienst- bzw. Werkvertrags ein Arbeitsvertrag zu Stande gekommen ist. Sog. „freie Mitarbeiter“ sind als Arbeitnehmer zu qualifizieren, wenn sie zum Auftraggeber in „persönlicher Abhängigkeit“ stehen. Aber auch Mitarbeiter des mit der Entwicklung beauftragten Unternehmens können kraft Gesetzes (§ 10 AÜG) zu Arbeitnehmern des Auftraggebers werden, wenn die Voraussetzungen einer unerlaubten Arbeitnehmerüberlassung vorliegen3. (4) Gesellschaftsvertrag

123

Vereinbaren die Parteien, die Software gemeinsam zu entwickeln und zu vermarkten, kommt als Grundlage der Zusammenarbeit ein Gesellschaftsvertrag gem. §§ 705 ff. BGB in Betracht4. Bei einer engen Kooperation ist die Grenze zum Gesellschaftsrecht leicht überschritten. Nur selten treffen die Parteien in Projekten eine ausdrückliche Regelung dazu, ob ein Austauschverhältnis oder eine gesellschaftsrechtliche Bindung gewollt ist. Die gemeinschaftliche Softwareerstellung wirft Sonderfragen auf, denen an dieser Stelle nicht weiter nachgegangen werden soll5. (5) Rechtsverschaffungspflicht

124

Liegt ein Werkvertrag bzw. ein Vertrag i.S.v. § 651 BGB vor, so ist der Auftragnehmer verpflichtet, dem Auftraggeber das (Sach-)Eigentum an den verkörperten Werkelementen zu verschaffen6. Die Pflicht bezieht sich insbesondere auf die Datenträger mit den hierauf verkörperten Programmen7. Der Auftraggeber erhält mit dem Eigentum an dem auf dem Datenträger verkörperten Programm die sachenrechtliche Verfügungsbefugnis über das 1 OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732. S. zum Ganzen auch Redeker, Abgrenzung zwischen Werk- und Dienstvertrag, ITRB 2001, 109. 2 S. hierzu Redeker, IT-Recht, Rz. 500 m.w.N. 3 S. zur Arbeitnehmerüberlassung bei Softwareentwicklung BAG v. 9.11.1994 – 7 AZR 217/94, NZA 1995. 572 sowie Feuerborn, Einsatz von Fremdfirmenpersonal in der Datenverarbeitung, CR 1995, 91. 4 Vgl. OLG München v. 3.2.1999 – 7 U 1892/98, DB 1999, 1057. 5 S. hierzu ausführlich Heppner, Softwareerstellungsverträge. 6 Palandt/Sprau, § 631 Rz. 12; Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 162 f.; Malzer, Der Softwarevertrag, S. 271. 7 Malzer, Der Softwarevertrag, S. 271.

54

Karger

Schutz und Realisierung der Software

Rz. 127 A

Werkstück1. Daneben trifft den Auftragnehmer die Pflicht zur Einräumung von urheberrechtlichen Nutzungsrechten2. Er hat dem Auftraggeber das Nutzungsrecht in dem sich aus der Vereinbarung oder dem Vertragszweck ergebenden Umfang zu übertragen. Dieselben Grundsätze gelten für den (freien) Dienstvertrag und den Arbeitsvertrag, wobei im Arbeitsverhältnis die Sonderregelung des § 69b UrhG Anwendung findet. Ob die Rechtsverschaffungspflicht als Hauptleistungspflicht3 oder als Ne- 125 benleistungspflicht4 zu qualifizieren ist, wird unterschiedlich beurteilt. Die Hauptleistungspflichten sind insbesondere maßgeblich für die Bestimmung des Vertragstyps5. Vergegenwärtigt man sich bei der Erstellung von Software die Bedeutung der Rechtsverschaffungspflicht für den Auftraggeber, so dürfte regelmäßig von einer Hauptleistungspflicht auszugehen sein6. Ohne Rechtseinräumung ist das Werk für ihn ohne Wert, da er die Software nicht in der erforderlichen Weise nutzen darf. Deshalb steht die Pflicht zur Rechtsverschaffung regelmäßig im Vordergrund des Vertrags. bb) Verfügungsgeschäft Hinsichtlich des Verfügungsgeschäfts ist zwischen der sachenrechtlichen 126 Einräumung des Eigentums und der urheberrechtlichen Nutzungsrechtseinräumung zu unterscheiden. Eine rechtsgeschäftliche Verfügung ist entbehrlich, sofern auf Grund gesetzlicher Sonderbestimmungen ein Rechtserwerb kraft Gesetzes erfolgt. (1) Trennungsgrundsatz Die sachenrechtliche Übereignung der verkörperten Arbeitsergebnisse und 127 die Einräumung der urheberrechtlichen Nutzungsrechte folgen unterschiedlichen Bestimmungen. Grundsätzlich sind das Sachenrecht des BGB und das „Urheber-Sachenrecht“ strikt voneinander zu trennen7. Für die sachenrechtliche Übertragung des Eigentums gelten die §§ 929 ff. BGB, für die Einräumung des Besitzes die §§ 854 ff. BGB. Demgegenüber werden auf urheberrechtliche Verfügungsgeschäfte, die auf die Einräumung von Nutzungsrechten gerichtet sind, die Grundsätze der Forderungsabtretung (§§ 413, 398 BGB) zumindest sinngemäß angewandt8. Ein gutgläubiger Erwerb der Nut1 Malzer, Der Softwarevertrag, S. 271. 2 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 169. 3 So Pres, Gestaltungsformen urheberrechtlicher Softwarelizenzverträge, CR 1994, 520, 522. 4 So LG Karlsruhe CR 1997, 401; Malzer, Der Softwarevertrag, S. 80, 100. 5 Palandt/Sprau, § 241 Rz. 5; Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 166. 6 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 166. 7 Schricker/Loewenheim, Einleitung Rz. 29; Witte, Eigentumsanspruch und Urheberrecht bei Standardsoftware, DStR 1996, 1049. 8 Palandt/Grüneberg, § 413 Rz. 2; Grunert, in: Wandtke/Bullinger, Vor §§ 31 ff. Rz. 22.

Karger

55

A Rz. 128

Grundlagen

zungsrechte vom Nichtberechtigten ist nicht möglich1. Übertragbar sind nur die Nutzungsrechte, grundsätzlich aber nicht das Urheberrecht selbst, § 29 UrhG. 128

Das Verfügungsgeschäft kommt jeweils durch formlose Einigung, die auch stillschweigend erklärt werden kann, zustande. Allerdings muss der auf die Rechtseinräumung gerichtete Wille bei der urheberrechtlichen Übertragung ebenso wie bei der sachenrechtlichen Übereignung unzweideutig zum Ausdruck kommen2.

129

Grundsätzlich bestehen zwischen dem sachenrechtlichen und dem urheberrechtlichen Verfügungsgeschäft keine Wechselwirkungen3. Aus der Auslegungsregel des § 44 Abs. 1 UrhG lässt sich entnehmen, dass die Einräumung von Eigentum am Werkstück keine Einräumung von urheberrechtlichen Nutzungsrechten an dem hierin verkörperten Werk beinhaltet. Umgekehrt ergibt sich aus der Einräumung von Nutzungsrechten noch kein Eigentumsrecht am Werkstück4.

130

Dies bedeutet für die Vertragsgestaltung, dass die Verfügung über das Eigentum und die Einräumung von Nutzungsrechten jeweils gesondert berücksichtigt werden müssen. In der Praxis finden sich aber häufig Verträge, in denen bezüglich der Rechtsübertragung entweder nur auf das Eigentum5 oder nur auf die Übertragung von Nutzungsrechten6 abgestellt wird. Um Unsicherheiten zu vermeiden, empfiehlt es sich, zur Klarstellung im Vertrag entsprechende Klauseln differenziert nach urheberrechtlichen Nutzungsrechten und sachenrechtlichem Eigentum zu formulieren. (2) Entbehrlichkeit einer rechtsgeschäftlichen Verfügung

131

Eine Verfügung ist entbehrlich, wenn eine Zuordnung der Rechte kraft Gesetzes erfolgt. In diesem Zusammenhang sind im Hinblick auf Computerprogramme § 69b UrhG und im Hinblick auf Datenbanken § 87a UrhG zu beachten.

132

Wird die Software von einem Arbeitnehmer in Erfüllung der arbeitsvertraglichen Pflichten entwickelt, so erhält der Arbeitgeber an den erstellten Computerprogrammen einschließlich des Entwurfsmaterials eine gesetzliche Lizenz gem. § 69b Abs. 1 UrhG7. Einer Verfügung des Arbeitnehmers

1 Grunert, in: Wandtke/Bullinger, Vor §§ 31 ff. Rz. 47 f. 2 Grunert, in: Wandtke/Bullinger, Vor §§ 31 ff. Rz. 45; s. auch BGH v. 22.4.2004 – I ZR 174/01, NJW 2005, 151. 3 Grunert, in: Wandtke/Bullinger, Vor §§ 31 ff. Rz. 56. 4 Wandtke, in: Wandtke/Bullinger, § 44 Rz. 2. 5 S. den vom OLG Düsseldorf v. 21.8.1998 – 22 U 8/98, NJW-RR 1999, 851 entschiedenen Fall zum Eigentumsvorbehalt bei Entwicklung von Software. 6 So z.B. § 6 BVB Erstellung. 7 Grützmacher, in: Wandtke/Bullinger, § 69b Rz. 1, a.A. Schricker/Loewenheim, § 69b Rz. 11: Gesetzliche Auslegungsregel.

56

Karger

Schutz und Realisierung der Software

Rz. 134 A

zur Übertragung der Rechte bedarf es somit nicht1. Allerdings ist hierbei zu beachten, dass § 69b UrhG nur für Computerprogramme i.S.d. Gesetzes, nicht aber für die sonstigen Elemente der Software gilt. Des Weiteren findet § 69b UrhG auf Programme, die außerhalb des Arbeitsverhältnisses geschaffen werden, keine Anwendung2. Schließlich ist § 69b UrhG vertraglich – auch konkludent3 – abdingbar. Der Arbeitgeber sollte sich aus diesen Gründen keinesfalls auf § 69b UrhG verlassen, sondern vorsorglich eine ausdrückliche vertragliche Regelung mit dem Arbeitnehmer zur Rechtseinräumung treffen. Sofern Gegenstand der Erstellung eine Datenbank i.S.v. § 87a UrhG ist, be- 133 stimmt sich die Rechtsinhaberschaft nach § 87a Abs. 2 UrhG. Originärer Inhaber des Schutzrechts ist danach der Datenbankhersteller. Dies ist diejenige natürliche oder juristische Person, die die wesentlichen Investitionen i.S.v. § 87a Abs. 1 UrhG getätigt hat. Datenbankhersteller ist derjenige, der die einschlägigen Finanzierungs-, Beschaffungs- und Personalverträge in eigenem Namen und für eigene Rechnung schließt, die Nutzungsrechte an den in die Datenbank aufgenommenen Werken und Leistungen in seiner Hand vereinigt bzw. andere unabhängige Elemente zur Eingabe in eine Datenbank von Datenbasenherstellern, Informationsbrokern oder anderen Anbietern von Daten oder anderen Informationsgütern erwirbt4. Demgegenüber fallen der Arbeitnehmer, der die sammelnde, sichtende und prüfende Tätigkeit selbst vornimmt, oder der Unternehmer, der im Lohnauftrag tätig wird, nicht unter den Begriff des Datenbankherstellers. § 87a UrhG findet keine Anwendung auf urheberrechtlich geschützte Datenbankwerke i.S.v. § 4 Abs. 2 UrhG. b) Zeitpunkt der Rechtseinräumung Aufgrund des Trennungsprinzips können Verpflichtungsgeschäft und Ver- 134 fügungsgeschäft bei einem sich über einen längeren Zeitraum hinziehenden Entwicklungsprojekt zeitlich auseinanderfallen. Um Unsicherheiten über den Zeitpunkt des Rechtserwerbs zu vermeiden, sollten die Parteien ausdrückliche vertragliche Vereinbarungen zum Zeitpunkt der Rechtseinräumung treffen. Fehlt es an einer ausdrücklichen Vereinbarung, muss zur Bestimmung des Zeitpunkts auf allgemeine Grundsätze zurückgegriffen werden.

1 Vgl. Buchner, Der Schutz von Computerprogrammen und Know-how im Arbeitsverhältnis, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, 2. Aufl. 1993, XI, Rz. 16. 2 Vgl. hierzu Schricker/Loewenheim, § 69b Rz. 5 ff. 3 Vgl. hierzu Schricker/Loewenheim, § 69b Rz. 20. 4 Schricker/Vogel, § 87a Rz. 69 ff.

Karger

57

A Rz. 135

Grundlagen

aa) Ausdrückliche Vereinbarung 135

Die Parteien können den Zeitpunkt der Rechtseinräumung im schuldrechtlichen Vertrag verbindlich festlegen. Je früher der Rechtsübergang erfolgt, desto vorteilhafter für den Auftraggeber, je später, desto vorteilhafter für den Auftragnehmer. Im Sinne größtmöglicher Klarheit ist es ratsam, in den entsprechenden Vertragsklauseln wiederum zwischen der Übertragung des Eigentums und der Übertragung von Nutzungsrechten zu unterscheiden.

136

In der Praxis wird, soweit die Frage überhaupt geregelt ist, ohne Verwendung einer präzisen Terminologie und der für den konkreten Vertragstyp einschlägigen Regelungen insbesondere auf die folgenden Zeitpunkte abgestellt: – – – – – –

Vertragsschluss Entstehen des Werks Übergabe des Werks Ablieferung des Werks Abnahme des Werks Vollständige Zahlung der Vergütung

(1) Vertragsabschluss 137

Frühest denkbarer Zeitpunkt für die Übertragung von Nutzungsrechten an der erst künftig zu erstellenden Software ist der Zeitpunkt des Abschlusses des Verpflichtungsgeschäfts. Eine Vorausverfügung in Form der Einräumung von Nutzungsrechten an künftigen Werken ist grundsätzlich zulässig, sofern die betreffenden Werke bestimmt oder bestimmbar sind1. Die Vorausverfügung kann zeitgleich mit dem zugrundeliegenden Verpflichtungsgeschäft vorgenommen werden. Sie hat sofort dingliche Wirkung und begründet ein Anwartschaftsrecht zugunsten des Auftraggebers, das mit Schaffung des Werks zum Vollrecht erstarkt2. Die schuldrechtliche Verpflichtung des Urhebers zur Einräumung von Nutzungsrechten an künftigen Werken, die überhaupt nicht näher oder nur der Gattung nach bestimmt sind, bedarf gem. § 40 UrhG der Schriftform.

138

Demgegenüber ist eine Vorausverfügung hinsichtlich des Sacheigentums an einer künftig entstehenden Sache unwirksam. Eigentum kann nur an existierenden körperlichen Gegenständen eingeräumt werden. Frühest möglicher Zeitpunkt für einen Rechtsübergang ist deshalb der Zeitpunkt, zu dem die zu übereignende Sache entsteht.

1 Schricker/Loewenheim, Vor §§ 28 ff. Rz. 79 m.w.N.; vgl. zur bedingten Rechtseinräumung auch BGH v. 17.11.2005 – IX ZR 162/04, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg = NJW 2006, 915. 2 Schricker/Loewenheim, Vor §§ 28 ff. Rz. 79 m.w.N.

58

Karger

Schutz und Realisierung der Software

Rz. 140 A

(2) Entstehung der Software Gelegentlich finden sich in Projektverträgen Bestimmungen, wonach der 139 Auftraggeber im Zeitpunkt der Entstehung der Software Eigentum und Nutzungsrechte in einem näher spezifizierten Umfang erhält. Der Begriff der „Entstehung“ ist so auszulegen, dass die Software zumindest in verkörperten Vorstufen oder Zwischenergebnissen vorliegen muss. Teilweise werden Klauseln verwendet, die nicht nur auf das Entstehen der Software und der Arbeitsergebnisse als solche, sondern ausdrücklich auch auf die jeweiligen Vor- und Zwischenstufen hierzu abstellen. Urheberrechtlich begegnet dies keinen Bedenken, da bei der Software-Entwicklung nicht nur das vollendete Werk, sondern auch Vor- und Zwischenstufen schutzfähig sind1. Eine solche Regelung ist insbesondere dann sinnvoll, wenn sich der Auftraggeber die Fertigentwicklung der Software durch Dritte vorbehalten möchte, da diese gegebenenfalls auf Vor- oder Zwischenstufen aufsetzen müssen. (3) Übergabe bzw. Ablieferung Die Begriffe der Übergabe und Ablieferung sind eigentlich dem Kaufrecht 140 entnommen, werden aber unabhängig vom Vertragstyp auch bei Verträgen werk- oder dienstvertraglichen Charakters verwendet. Fraglich ist, wie Bestimmungen auszulegen sind, die eine Rechtseinräumung bei „Übergabe“ bzw. bei „Ablieferung“ vorsehen. Sofern keine anderen Anhaltspunkte gegeben sind, bietet es sich an, auf die vom Gesetz – wenn auch im Kontext des Kaufrechts – vorgesehene Bedeutung abzustellen. Danach sind beide Begriffe nicht synonym zu verstehen. Übergabe ist die bloße Verschaffung des unmittelbaren Besitzes gem. § 854 BGB2. Die Ablieferung ist demgegenüber der Vorgang, durch den der Auftraggeber in die Lage versetzt wird, die Sache so in Besitz zu nehmen, dass er sie untersuchen kann3. Nach wohl überwiegender Meinung setzt die Ablieferung nicht nur die Übergabe der Programme, sondern auch der zugehörigen Dokumentation voraus4. Unklar ist, ob auch noch weitere Kriterien erfüllt sein müssen, namentlich die Einweisung und die Durchführung eines Probebetriebs5. Sofern das letztgenannte Kriterium zu erfüllen wäre, nähert sich die Ablieferung bereits weitgehend der Abnahme an. Aufgrund der unklaren Bedeutung insbesondere des Begriffs der Ablieferung sind die Parteien eines Softwareerstellungsvertrags gut beraten, die Bedeutung gegebenenfalls vertraglich zu definieren.

1 2 3 4

Schricker/Loewenheim, § 2 Rz. 22. Palandt/Weidenkaff, § 433 Rz. 13. Palandt/Weidenkaff, § 433 Rz. 15. Schneider, „Ablieferung“ bei Softwareüberlassungsverträgen, CR 1994, 385, 386. 5 Schneider, „Ablieferung“ bei Softwareüberlassungsverträgen, CR 1994, 385, 386.

Karger

59

A Rz. 141

Grundlagen

(4) Abnahme, Recht zur Testnutzung und zur Funktionsprüfung 141

Häufig finden sich vertragliche Bestimmungen, wonach eine Einräumung von Nutzungsrechten und eine Eigentumsübertragung mit Erklärung der Abnahme der Software durch den Auftraggeber erfolgt1. Diese Konstruktion dürfte jedenfalls bei Werkverträgen den Wertungen des BGB am ehesten entsprechen. Abnahme ist die körperliche Hinnahme des Werks im Weg der Besitzübergabe verbunden mit der Anerkennung als in der Hauptsache vertragsgemäße Leistung.

142

In aller Regel geht der Abnahme eine Testnutzung und Funktionsprüfung der Software durch den Auftraggeber voraus. Da der Auftraggeber hierfür urheberrechtlich relevante Nutzungshandlungen vornehmen muss, stellt sich die Frage, ob es hierfür bereits einer (ausdrücklichen oder stillschweigenden) Nutzungsrechtsübertragung bedarf. Sofern dem Auftraggeber vor Erklärung der Abnahme ein Vervielfältigungsstück eines Computerprogramms überlassen wird, kann dem Auftragnehmer nicht ohne Weiteres unterstellt werden, dass er dem Auftraggeber zugleich Nutzungsrechte am Programm einräumt. Vielmehr ist durch Auslegung zu ermitteln, ob eine bloße schuldrechtliche Gestattung vorliegt oder bereits eine dinglich wirkende Nutzungsrechtseinräumung erfolgt ist. Grundsätzlich ist die rein schuldrechtliche Gestattung der Werknutzung ohne Gewährung eines gegenständlichen Rechts möglich2. Eine solche schuldrechtliche Gestattung kommt insbesondere bei nur vorübergehendem Charakter und geringer wirtschaftlicher Bedeutung der Nutzung in Betracht3 – Kriterien, die auf einen bloßen Testbetrieb zutreffen. Sofern man dagegen eine stillschweigende Nutzungsrechtsübertragung annimmt, ist diese jedenfalls inhaltlich auf die reine Testnutzung und zeitlich auf die vereinbarte, jedenfalls aber auf eine angemessene Testphase beschränkt. Die nach § 69d UrhG zulässigen Nutzungen beschränken sich auf die für den Testbetrieb erforderlichen Handlungen. Eine „Produktivnutzung“ der Software im Echtbetrieb ist nur insoweit und solange zulässig, als der Echtbetrieb Bestandteil des vereinbarten Testbetriebs ist. Verweigert der Auftraggeber nach Abschluss des Testbetriebs die Abnahme, so ist eine weitere Produktivnutzung der Software unzulässig. (5) Vollständige Bezahlung der Vergütung, Rechtsvorbehalt

143

Häufig wird zugunsten des Auftragnehmers vereinbart, dass die Nutzungsrechte an der Software und das Eigentum an den verkörperten Arbeitsergebnissen erst nach vollständiger Zahlung der Vergütung übergehen4. Bei entsprechenden Rechtseinräumungsvorbehalten ist hinsichtlich der Eigen-

1 2 3 4

Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 169. Schricker/Loewenheim, Vor §§ 28 ff. Rz. 55. Schricker/Loewenheim, Vor §§ 28 ff. Rz. 56. Vgl. Redeker, Eigentumsvorbehalte und Sicherungsklauseln in Softwareverträgen, ITRB 2005, 70.

60

Karger

Schutz und Realisierung der Software

Rz. 145 A

tumsübertragung an den zu liefernden Sachen und der Einräumung von Nutzungsrechten zu unterscheiden. Ein Eigentumsvorbehalt i.S.v. § 449 BGB kann sich nur auf Sachen, also verkörperte Arbeitergebnisse wie Datenträger und Handbücher, nicht aber auf die Einräumung von Nutzungsrechten beziehen1. Bei Softwareerstellung auf der Basis eines Vertrages i.S.v. § 651 BGB findet bezüglich des Eigentumsvorbehalts § 449 BGB auf Grund der Verweisung des § 651 Satz 1 BGB Anwendung. Auch bei einem Werkvertrag kann zumindest individualvertraglich ein Eigentumsvorbehalt vereinbart werden. Hinsichtlich der Nutzungsrechtseinräumung ist die Vereinbarung einer auf- 144 schiebenden Bedingung möglich2. Für das Rechtsgeschäft der Einräumung von Nutzungsrechten gelten die Regelungen im Allgemeinen Teil des BGB; damit können hierfür auch Bedingungen i.S.v. § 158 BGB vereinbart werden3. Hierbei ist aber zu berücksichtigen, dass der Besteller bei einem vollumfänglichen Rechtsvorbehalt die Software vor vollständiger Bezahlung der Vergütung nicht nutzen darf. Er dürfte deshalb die Software z.B. auch nicht testen – was ihm im Rahmen einer Abnahmeprüfung nach § 640 BGB oder bei Anwendbarkeit des § 377 HGB aber obliegen würde4. Deshalb sollte vertraglich sichergestellt werden, dass der Besteller auch schon vor dem Zeitpunkt der vollständigen Bezahlung aufgrund schuldrechtlicher Gestattung bzw. auf Grund einer entsprechend beschränkten Nutzungsrechtseinräumung einen Testbetrieb durchführen kann5. (6) Auslegung von „Eigentumsvorbehalts-Klauseln“ Teilweise unterschiedlich werden die immer noch häufig zu findenden 145 Klauseln interpretiert, die pauschal einen „Eigentumsvorbehalt“ oder einen „Eigentumsvorbehalt für die Software“ vorsehen und nicht zwischen Vorbehalt des Eigentums und Vorbehalt der Nutzungsrechte differenzieren: So hat das OLG Düsseldorf in einer Entscheidung aus dem Jahr 19986 eine vertragliche Eigentumsvorbehaltsklausel bezüglich der gelieferten Software nur nach dem Wortlaut interpretiert und nicht geprüft, ob der Vorbehalt des Eigentums möglicherweise auch einen Vorbehalt der Nutzungsrechte impli-

1 OLG Düsseldorf v. 21.8.1998 – 22 U 8/98, NJW-RR 1999, 851, 852; Redeker, Eigentumsvorbehalte und Sicherungsklauseln in Softwareverträgen, ITRB 2005, 70. 2 Vgl. Bauer/Bischof, Rechtseinräumungsklauseln, ITRB 2003, 256, 258; vgl. auch BGH v. 17.11.2005 – IX ZR 162/04, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg = NJW 2006, 915. 3 Vgl. Schricker/Schricker, Vor §§ 28 ff. Rz. 77; Palandt/Weidenkaff, § 453 Rz. 13: Bedingung der vollständigen Zahlung der Vergütung entsprechend § 449 BGB beim Rechtskauf ist zulässig. 4 Bauer/Bischof, Rechtseinräumungsklauseln, ITRB 2003, 256, 258. 5 Vgl. Bauer/Bischof, Rechtseinräumungsklauseln, ITRB 2003, 256, 258. 6 OLG Düsseldorf v. 21.8.1998 – 22 U 8/98, NJW-RR 1999, 851, 852.

Karger

61

A Rz. 146

Grundlagen

ziert. Demgegenüber hatte das OLG Nürnberg in einer Entscheidung aus dem Jahr 19921 eine Klausel, wonach das Eigentum an der Vertragssoftware beim Auftragnehmer verbleiben sollte, als „juristisch missglückt“ bewertet. Das Gericht ist hier aber nicht beim Wortlaut stehen geblieben, sondern hat die Klausel dahingehend ausgelegt, dass der Auftragnehmer sich alle Nutzungsrechte vorbehalten wollte, die über die ausdrückliche vertragliche Nutzungserlaubnis hinausgehen2. Der BGH hat in der Entscheidung Holzhandelsprogramm aus dem Jahr 19943 eine Klausel, die eine „Sicherungsübereignung“ vorsah, nach ihrem Zweck ebenfalls so ausgelegt, dass damit nicht nur die Übertragung des Sacheigentums am Datenträger, sondern auch die Sicherungsabtretung der Nutzungsrechte an der Software gemeint war. Allerdings hat der BGH darauf abgestellt, dass der zugrundeliegende Vertrag aus dem Jahr 1976 stammte und zu diesem Zeitpunkt die exakte Trennung zwischen der sachenrechtlichen und der urheberrechtlichen Terminologie noch nicht die Regel war4. 146

Mittlerweile ist davon auszugehen, dass der Rechtsverkehr die grundsätzliche urheberrechtliche Schutzfähigkeit von Software rezipiert hat und sich deshalb auch das Vertragsrecht bei der Überlassung von Software in der exakten urheberrechtlichen Terminologie bewegen muss5. Unter Berücksichtigung der in § 44 UrhG getroffenen Wertung, dass Sacheigentum und Nutzungsrecht grundsätzlich nicht aneinander gekoppelt sind, wird man „Eigentumsvorbehaltsklauseln“ im Regelfall nicht mehr so auslegen können, dass sie auch eine aufschiebend bedingte Einräumung von Nutzungsrechten beinhalten. bb) Fehlen einer ausdrücklichen Vereinbarung

147

Die Rechtsübertragung kann auch stillschweigend erfolgen6. Allerdings muss der auf die Rechtseinräumung gerichtete Wille bei der urheberrechtlichen Übertragung ebenso wie bei der sachenrechtlichen Übereignung unzweideutig zum Ausdruck kommen7. Bezüglich des maßgeblichen Zeitpunkts ist bei Fehlen einer ausdrücklichen Vereinbarung zwischen den einzelnen Vertragstypen zu differenzieren:

1 OLG Nürnberg v. 20.10.1992 – 3 U 2087/92, CR 1993, 359, 360. 2 Ähnlich auch die Interpretation von Eigentumsvorbehaltsklauseln durch Malzer, Der Softwarevertrag, S. 138. 3 BGH v. 20.1.1994 – I ZR 267/91, MDR 1994, 462 = CR 1994, 275, 277. 4 BGH v. 20.1.1994 – I ZR 267/91, MDR 1994, 462 = CR 1994, 275, 277. 5 Lehmann, CR 1994, 277, 279 (Anm. zu BGH v. 20.1.1994 – I ZR 267/91 – Holzhandelsprogramm, MDR 1994, 462 = CR 1994, 275); Redeker, Eigentumsvorbehalte und Sicherungsklauseln in Softwareverträgen, ITRB 2005, 70. 6 Schricker/Loewenheim, Vor §§ 18 ff. Rz. 78. 7 Grunert, in: Wandtke/Bullinger, Vor §§ 31 ff. Rz. 45; s. auch BGH v. 22.4.2004 – I ZR 174/01, NJW 2005, 151.

62

Karger

Schutz und Realisierung der Software

Rz. 150 A

Beim Werkvertrag ist maßgeblicher Zeitpunkt für eine stillschweigende 148 Rechtsübertragung grundsätzlich der Zeitpunkt der Abnahme1. Erst dann kann dem Auftragnehmer ein entsprechender Einigungswille im Hinblick auf das Verfügungsgeschäft unterstellt werden, da zuvor in Ansehung von § 641 BGB nicht feststeht, ob er für die Rechtsübertragung auch vergütet wird. Bei Abnahmeerklärung ist regelmäßig von einer konkludenten Verfügung auszugehen2. Bei einem Vertrag i.S.v. § 651 BGB ist als maßgeblicher Zeitpunkt regelmäßig der Zeitpunkt der Ablieferung anzunehmen. Beim Dienstvertrag ist der maßgebliche Zeitpunkt ebenfalls der Zeitpunkt der Ablieferung3. Die Ablieferung ist der Vorgang, durch den der Auftraggeber in die Lage versetzt wird, die Sache so in Besitz zu nehmen, dass er sie untersuchen kann4. Nach wohl überwiegender Meinung setzt die Ablieferung nicht nur die Übergabe der Programme, sondern auch der zugehörigen Dokumentation voraus5. Generell ist die Rechtseinräumung damit grundsätzlich nicht von der Zahlung der Vergütung abhängig6. Für die Softwareerstellung im Rahmen eines Arbeitsverhältnisses gilt: So- 149 weit es sich um Computerprogramme handelt, erwirbt der Arbeitgeber die gesetzliche Lizenz nach § 69b UrhG im Zeitpunkt der Entstehung des Programms. Dies dürfte auch hinsichtlich der einzelnen Vorstufen und Zwischenergebnisse gelten7. Bezüglich der übrigen urheberrechtlich geschützten Arbeitsergebnisse gilt § 43 UrhG. Als spätester Zeitpunkt der stillschweigenden Rechtsübertragung im Rahmen von § 43 UrhG wird allgemein die Übergabe des Werks gesehen8. Teilweise wird vertreten, dass eine Rechtseinräumung durch schlüssiges Verhalten schon bei Vertragsschluss erfolgt9. Eine stillschweigende Vorausverfügung des Arbeitnehmers bei Beginn des Projekts ist wirksam, da das Schriftformerfordernis des § 40 Abs. 1 UrhG für den im Arbeitsverhältnis stehenden Urheber grundsätzlich nicht gilt10. Für sonstige Dienstverhältnisse i.S.d. §§ 611 ff. BGB, insbesondere für die 150 freie Mitarbeit, findet § 69b UrhG keine Anwendung. Anders als beim Werkvertrag erfolgt beim Dienstvertrag keine Abnahme. Als maßgeblicher Zeitpunkt für eine stillschweigende Rechtsübertragung dürfte daher der Zeitpunkt der Ablieferung des Werks in Betracht kommen. Eine still1 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 67; Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 168. 2 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 168. 3 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 67. 4 Palandt/Weidenkaff, § 433 Rz. 15. 5 Schneider, „Ablieferung“ bei Softwareüberlassungsverträgen, CR 1994, 385, 386. 6 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 67. 7 Anders – wohl unzutreffend – OLG Celle v. 1.4.1993 – 13 U 39/90, CR 1994, 681. 8 Vgl. Schricker/Rojahn, § 43 Rz. 41; Wandtke, in: Wandtke/Bullinger, § 43 Rz. 51. 9 Wandtke, in: Wandtke/Bullinger, § 43 Rz. 51. 10 Schricker/Rojahn, § 43 Rz. 44.

Karger

63

A Rz. 151

Grundlagen

schweigende Vorausverfügung bereits bei Vertragsschluss bzw. bei Aufnahme der Tätigkeit dürfte – anders als beim Arbeitsverhältnis – i.d.R. an der Formvorschrift des § 40 Abs. 1 UrhG scheitern. c) Umfang der Rechtseinräumung aa) Urhebervertragsrechtliche Grundsätze 151

Die Parteien können den Umfang der Rechtseinräumung gem. § 31 UrhG grundsätzlich frei regeln. Im Hinblick auf Computerprogramme sind jedoch die nicht abdingbaren Bestimmungen der §§ 69d und 69e UrhG zu beachten1. Gem. § 31 Abs. 1 UrhG kann der Urheber das Recht einräumen, das Werk auf einzelne oder alle Nutzungsarten zu nutzen. Das Nutzungsrecht kann als einfaches oder ausschließliches Recht sowie räumlich, zeitlich oder inhaltlich beschränkt eingeräumt werden. Dingliche Wirkung kommt der Rechtseinräumung nur zu, wenn eine eigenständige Nutzungsart vorliegt2. Unter einer eigenständigen Nutzungsart wird jede nach der Verkehrsauffassung wirtschaftlich-technisch selbständige und abgrenzbare Art und Weise der Verwendung des Werks angesehen3.

152

Nach der zwischenzeitlich aufgehobenen Bestimmung des § 31 Abs. 4 UrhG war die Einräumung von Nutzungsrechten für noch nicht bekannte Nutzungsarten unwirksam. Stattdessen können nunmehr nach Maßgabe von § 31a UrhG auch Verträge über unbekannte Nutzungsarten wirksam geschlossen werden. Allerdings ist hierbei das Schriftformerfordernis des § 31a Abs. 1 UrhG zu beachten. Des Weiteren besteht ein Widerrufsrecht des Urhebers4. Zu § 31a UrhG korrespondiert die Vergütungsvorschrift des § 31c UrhG.

153

Die Zweckübertragungsregel nach § 31 Abs. 5 UrhG findet auf Computerprogramme5 sowie auf die übrigen schutzfähigen Elemente der Software Anwendung. Liegt keine ausdrückliche Vereinbarung über die einzeln zu bezeichnenden Nutzungsarten vor, so räumt der Urheber gemäß der Zweckübertragungsregel keine weitergehenden Nutzungsrechte ein, als es der Zweck des Vertrags erfordert. Grundsätzlich handelt es sich hierbei um eine Auslegungsregel. Sie geht jedoch in ihrer Bedeutung darüber hinaus und begründet eine Spezifizierungslast für den Rechtserwerber, der die Nutzungsarten, auf die sich die Rechtseinräumung erstrecken soll, einzeln bezeich-

1 S. hierzu Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 56. 2 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 59. 3 BGH v. 19.5.2005 – I ZR 285/02, MDR 2006, 165 = CR 2006, 209 = WRP 2005, 1542, 1544 (Der Zauberberg); Grunert, in: Wandtke/Bullinger, § 31 Rz. 2. 4 Weiterführend Schricker/Spindler, § 31a UrhG; zur gesetzlichen Neuregelung auch Grunert, in: Wandtke/Bullinger, § 31 Rz. 38. 5 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 59.

64

Karger

Schutz und Realisierung der Software

Rz. 155 A

nen muss1. Unterlässt er dies, so wird die Auslegung zwingend auf den Vertragszweck fixiert, was tendenziell einen Rechtsnachteil für den Erwerber bedeutet. Hieraus folgt, dass insbesondere der Erwerber bzw. Lizenznehmer besonders genau darauf achten muss, dass ihm zumindest alle für seine Zwecke notwendigen Nutzungsrechte für entsprechende bekannte Nutzungsarten eingeräumt werden2. bb) Ausdrückliche Vereinbarung Aus Gründen der Rechtssicherheit empfiehlt es sich, die Rechtseinräumung 154 hinsichtlich der einzelnen Nutzungsarten und Nutzungsrechte ausdrücklich zu regeln. In der Praxis finden sich in vielen Verträgen entsprechende Klauseln. Problematisch sind hierbei insbesondere Klauseln, die ohne weitere Differenzierung nach den Nutzungsarten eine pauschale Rechtseinräumung vorsehen. Der Trend geht daher zu detaillierten und umfangreichen Klauseln, die sich am Ansatz sog. Buy-out-Verträge orientieren. Um Unklarheiten zu vermeiden, sollte stets auch geregelt werden, ob sich die eingeräumten Nutzungsrechte nur auf den Objektcode oder auch auf den Quellcode beziehen3. (1) Pauschale Rechtseinräumung In der Praxis finden sich in vielen Verträgen Klauseln, in denen die betref- 155 fenden Nutzungsarten nicht einzeln aufgezählt werden, sondern eine pauschale Einräumung aller Nutzungsrechte für alle Nutzungsarten vorgesehen ist. Vor solchen Klauseln ist primär der Auftraggeber zu warnen, da sie trotz ihres vermeintlich umfassenden Charakters die von ihm gewünschte umfassende Rechtseinräumung gerade nicht absichern4. Bei Vereinbarungen, nach deren Wortlaut der Urheber in pauschaler Weise Nutzungsrechte einräumt, kommt die Zweckübertragungslehre zum Tragen. Gemäß § 31 Abs. 5 UrhG bestimmt sich der Umfang eines eingeräumten Nutzungsrechts nach dem mit seiner Einräumung verfolgten Zweck, wenn bei der Rechtseinräumung die Nutzungsarten, auf die sich das Recht erstrecken soll, nicht einzeln bezeichnet sind. Bei pauschalen Vereinbarungen über die Einräumung von Nutzungsrechten wird danach der Umfang des Nutzungsrechts durch den Vertragszweck bestimmt und im Allgemeinen beschränkt, selbst wenn der Wortlaut der vertraglichen Regelung eindeutig ist5. Nach dem Schutzgedanken der allgemeinen Zweckübertragungslehre, der in § 31 Abs. 5 UrhG zum Ausdruck gekommen ist, be1 Schricker/Loewenheim, § 31 Rz. 69. 2 Grützmacher, in: Wandtke/Bullinger, Vor §§ 69a ff. Rz. 13. 3 Vgl. Karger, Rechtseinräumung bei Softwareerstellung, CR 2001, 357, 365; s. auch die Formulierungsmuster von Bauer/Bischof, ITRB 2003, 256, 257. 4 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 62. 5 BGH v. 27.9.1995 – I ZR 215/93, MDR 1996, 815 = CR 1996, 82 m. Anm. Hoeren = GRUR 1996, 121, 122 – Pauschale Rechtseinräumung.

Karger

65

A Rz. 156

Grundlagen

stimmt der Vertragszweck bei pauschal formulierten Rechtseinräumungen nicht nur, welche Nutzungsrechte im Einzelnen eingeräumt sind, sondern auch, ob diese inhaltlich, räumlich oder zeitlich beschränkt eingeräumt worden sind1. Damit muss der Besteller darlegen und beweisen, dass die von ihm benötigten Nutzungsarten dem Vertragszweck entsprechen; kann er dies nicht, so hat er die entsprechende Befugnis nicht erworben2. (2) Buy-Out-Vertrag 156

Zur Absicherung einer möglichst umfassenden Rechtseinräumung werden auch im Softwarebereich zunehmend so genannte Buy-Out-Verträge abgeschlossen3. Bei diesen Verträgen, die bislang vor allem in der Film- und Fernsehindustrie, aber beispielsweise auch in der Berufsgruppe der freiberuflichen Übersetzer und Journalisten gängig waren, begibt sich der Urheber gegen ein Pauschalhonorar aller seiner Rechte4. In den entsprechenden Verträgen werden umfassende Kataloge aller denkbaren Nutzungsrechte und Nutzungsarten aufgenommen, die konkret die Nutzungsbefugnisse des Erwerbers bezeichnen, aber weit über den jeweiligen Vertragszweck hinausreichen. Diese Praxis widerspricht dem Schutzzweck des § 31 Abs. 5 Satz 1 UrhG, weil sie den teilweise zwingenden Regelungsinhalt zu beseitigen versucht, wird nach der h.M. wegen des Grundsatzes der Vertragsfreiheit aber gleichwohl anerkannt5. Mit den Vergütungsregelungen der §§ 32 und 32a UrhG ist zumindest das Risiko verringert, dass der Urheber für seine Schöpfung und die eingeräumten Rechte keine angemessene Vergütung erhält. Ist ein Anspruch auf angemessene Vergütung im Vertrag vorgesehen, steht der Schutzzweck des § 31 Abs. 5 Satz 1 UrhG der „Buy-Out“ Regelung nicht mehr entgegen6. Im Schrifttum werden folglich entsprechende Vereinbarungen im Fall der Softwareerstellung unter Abwägung der beiderseitigen Interessen grundsätzlich als gerechtfertigt angesehen7. Allerdings zeichnet sich ein Trend ab, wonach die Gerichte Buy-Out-Klauseln zunehmend einer restriktiven AGB-Kontrolle unterziehen8.

1 BGH v. 27.9.1995 – I ZR 215/93, MDR 1996, 815 = CR 1996, 82 m. Anm. Hoeren = GRUR 1996, 121, 122 – Pauschale Rechtseinräumung. 2 Grunert, in: Wandtke/Bullinger, § 31 Rz. 41. 3 Grützmacher, in: Wandtke/Bullinger, Vor §§ 69a Rz. 14. 4 Vgl. Stickelbrock, Ausgleich gestörter Vertragsparität durch das neue Urhebervertragsrecht?, GRUR 2001, 1087, 1089. 5 Grunert, in: Wandtke/Bullinger, § 31 Rz. 42. 6 Grunert, in: Wandtke/Bullinger, § 31 Rz. 44. 7 Schricker/Spindler, Vor §§ 69a ff. Rz. 63. 8 Hierzu Dorner, MMR 2011, 780.

66

Karger

Schutz und Realisierung der Software

Rz. 160 A

cc) Fehlen einer ausdrücklichen Vereinbarung Sofern es an einer ausdrücklichen Vereinbarung fehlt, bestimmt sich der Umfang der Rechtseinräumung grundsätzlich nach dem Zweckübertragungsgrundsatz1.

157

(1) Zweckübertragungsgrundsatz Haben die Parteien keine ausdrückliche Vereinbarung über die Nutzungs- 158 rechtseinräumung an den urheberrechtlich geschützten Elementen getroffen, so findet sowohl auf das Verpflichtungsgeschäft als auch auf das Verfügungsgeschäft prinzipiell der Zweckübertragungsgrundsatz des § 31 Abs. 5 UrhG Anwendung. Danach wird der Umfang der Nutzungsrechtseinräumung durch den Vertragszweck bestimmt. Es gilt das Prinzip, dass der Urheber im Zweifel keine weitergehenden Rechte überträgt, als es der Zweck des Vertrages zwingend erfordert. Die Beweislast dafür, dass eine Rechtseinräumung vom Vertrag gedeckt wird, trägt der Auftraggeber2. Das Versäumnis einer ausdrücklichen vertraglichen Regelung wirkt sich in dieser Hinsicht für den Auftraggeber deutlich nachteiliger aus als für den Auftragnehmer. (2) Ausnahmen vom Zweckübertragungsgrundsatz Allerdings gilt der Zweckübertragungsgrundsatz nicht einschränkungslos: 159 Hinsichtlich der Computerprogramme greifen zugunsten des Auftraggebers die §§ 69d und 69e UrhG als Sonderregeln zu § 31 Abs. 5 UrhG ein3. Die dort festgelegten Mindestrechte stehen ihm unabdingbar zu, sobald er erst einmal „zur Verwendung eines Vervielfältigungsstücks Berechtigter“ geworden ist. Im Arbeitsverhältnis oder im öffentlichen Dienstverhältnis ist zusätzlich § 69b UrhG anwendbar, der dem Auftraggeber die umfassenden Nutzungs- und Verwertungsbefugnisse an den erstellten Programmen sichert. Im Rahmen des § 69b UrhG findet die Zweckübertragungslehre keine Anwendung4. (3) Ermittlung des Vertragszwecks Der im Rahmen des Zweckübertragungsgrundsatzes zu ermittelnde Vertrags- 160 zweck ist entsprechend §§ 133, 157 BGB zu bestimmen. Hierbei können Rückschlüsse aus den Vorverhandlungen, Begleitumständen, ähnlichen Vertragsverhältnissen, Geschäftszuschnitt und dem gewöhnlichen Geschäftsgang der Beteiligten gezogen werden.

1 Vgl. hierzu auch Karger, Softwareentwicklung – Rechtseinräumung bei fehlender ausdrücklicher Vereinbarung, ITRB 2001, 67; Karger, Rechtseinräumung bei Softwareerstellung, CR 2001, 357. 2 Schricker/Loewenheim, § 31 Rz. 70. 3 S. dazu oben Rz. 95 ff. 4 Schricker/Loewenheim, § 69b Rz. 12.

Karger

67

A Rz. 161

Grundlagen

161

Der Vertragstyp alleine lässt nur begrenzt Folgerungen auf den von den Parteien verfolgten Vertragszweck zu. Beim Werkvertrag bzw. beim Vertrag i.S.v. § 651 BGB ist zwar grundsätzlich davon auszugehen, dass das Werk dem Auftraggeber zur Nutzung überlassen wird. Dies heißt jedoch nicht ohne Weiteres, dass diese Nutzung ausschließlich und ohne Einschränkungen erfolgen soll1. Es ist vielmehr möglich und auch üblich, dass lediglich bestimmte Nutzungsrechte eingeräumt werden. Der Auftraggeber kann also nicht von vorneherein davon ausgehen, dass er einen Anspruch auf Einräumung der umfassenden, ausschließlichen und auf Dritte übertragbaren Nutzungsrechte hat2. Auch beim Dienstvertrag kann nicht von vorneherein unterstellt werden, dass der Auftraggeber die umfassenden Nutzungsrechte an den Arbeitsergebnissen erhält, zumal § 69b UrhG auf „freie“ Dienstverträge keine Anwendung findet.

162

Aus der Regelung der Vergütung können grundsätzlich keine zwingenden Rückschlüsse auf den Umfang der Rechtseinräumung gezogen werden. Auch wenn der Auftraggeber die Entwicklung der Software voll finanziert, bedeutet dies nicht, dass er automatisch die umfassenden, insbesondere die ausschließlichen Rechte hieran erhält und der Auftragnehmer die Software nicht auch anderweitig – u.U. auch durch Lizensierung an einen Konkurrenten – vermarkten darf3. Allerdings kann je nach Kostenkalkulation des Auftragnehmers die Überlassung des Quellcodes geschuldet sein4.

163

Anhaltspunkte für den Umfang der Rechtseinräumung können sich aus Folgendem ergeben: Sofern der Auftragnehmer anbietet, die Software „exklusiv“ für den Auftraggeber zu erstellen, spricht dies für eine Übertragung der ausschließlichen Nutzungsrechte5. Wird der Quellcode dem Auftraggeber überlassen, so räumt der Auftragnehmer dem Auftraggeber in der Regel ein Änderungsrecht an den Programmen ein6.

164

Der Umfang der Rechtseinräumung hängt maßgeblich davon ab, ob die Software nach dem Vertragszweck vom Besteller nur zur eigenen (unternehmensinternen) Nutzung oder aber zur Weitervermarktung an Dritte erstellt wird7. Eine Erstellung zum Zweck der Weitervermarktung ist tendenziell dann anzunehmen, wenn Standardsoftware für ein Softwarehaus erstellt wird8. Demgegenüber ist bei der Erstellung von Individualsoftware eher von einer beabsichtigten Nutzung durch den Auftraggeber nur zu eigenen Zwe1 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 164; vgl. auch Karger, Softwareentwicklung – Rechtseinräumung bei fehlender ausdrücklicher Vereinbarung, ITRB 2001, 67, 68. 2 Sucker, Lizenzierung von Computersoftware, CR 1989, 468, 476. 3 Redeker, IT-Recht, Rz. 36. 4 BGH v. 16.12.2003 – X ZR 129/01 – Individualsoftwareerstellung, CR 2004, 490, 491. 5 BGH v. 9.5.1985 – I ZR 52/83, MDR 1986, 121 = CR 1985, 22, 24. 6 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 165. 7 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 63. 8 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 63; Redeker, IT-Recht, Rz. 34.

68

Karger

Schutz und Realisierung der Software

Rz. 166 A

cken auszugehen1. Wird ein Programmierer als freier Mitarbeiter auf der Basis eines Dienstvertrags mit der Entwicklung eines Programms beauftragt, um den Auftraggeber in die Lage zu versetzen, das Programm optimal zu vermarkten, und erhält er für seine Tätigkeit ein monatliches Entgelt, so ist die konkludente Einräumung umfassender Nutzungsrechte an den Auftraggeber vom Zweck des Dienstvertrags ohne Weiteres erfasst2. Fehlt es an jeglichen Anhaltspunkten zur Ermittlung des Vertragszwecks, 165 so ist bei einer konsequenten Anwendung der Zeckübertragungslehre von einer in jeder Hinsicht limitierten Rechtseinräumung auszugehen. Der Auftraggeber erhält demgemäß lediglich ein einfaches, auf sich bzw. sein Unternehmen beschränktes Nutzungsrecht am Objektcode. Das Recht ist nicht auf Dritte übertragbar, da dem Urheber nicht unterstellt werden kann, er sei mit einer Übertragbarkeit einverstanden3. Eine Übertragbarkeit des Nutzungsrechts auf Dritte berührt potentiell die wirtschaftlichen Interessen des Auftragnehmers, da der Dritte die Software bei Nichtübertragbarkeit noch einmal gesondert bei ihm erwerben müsste. Änderungsrechte bzw. Rechte zur Umarbeitung werden nicht eingeräumt. Allerdings erhält der Auftraggeber im Hinblick auf die Computerprogramme die in §§ 69d, 69e UrhG vorgesehenen Mindestrechte. (4) Erstellung zum Zwecke der Weitervermarktung Bei einer Erstellung zum Zwecke der Weitervermarktung ist grundsätzlich 166 anzunehmen, dass die umfassenden, für den Vertrieb und für die Einräumung der Rechte gegenüber dem Anwender notwendigen Rechte zur Vervielfältigung, Verbreitung und öffentlichen Wiedergabe einschließlich der Zugänglichmachung eingeräumt werden4. Grundsätzlich wird man auch davon ausgehen können, dass das Bearbeitungsrecht mit eingeräumt wird, weil sonst eine Pflege der Software nicht möglich wäre5. Die Rechtseinräumung erstreckt sich bei Weitervermarktung durch den Auftraggeber grundsätzlich auch auf den Quellcode6. Allerdings umfasst die Rechtseinräumung nicht von vorneherein alle Nutzungsarten wie z.B. Einzel-, Mehrplatz-, OEM-, Demo-, Shareware-, Outsourcing- und ASP-Versionen7. Welche Nutzungsarten konkret von der Rechtseinräumung erfasst werden, ist bezogen

1 Vgl. Redeker, IT-Recht, Rz. 35. 2 BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 855; s. hierzu die kritische Anm. von Heymann, CR 2005, 856 ff. 3 A.A. Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 165. 4 Vgl. BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, MDR 2006, 166 = CR 2005, 854, 855. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 63; Redeker, IT-Recht, Rz. 34. 5 Vgl. auch Redeker, IT-Recht, Rz. 34. 6 Vgl. BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490, 491. 7 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 63.

Karger

69

A Rz. 167

Grundlagen

auf jede einzelne Nutzungsart nach dem Vertrag, dem Vertragszweck und der Branchenübung zu beurteilen1. 167

Ob bei der Erstellung zum Zwecke der Weitervermarktung einfache oder ausschließliche Nutzungsrechte eingeräumt werden, bestimmt sich ebenfalls nach § 31 Abs. 5 UrhG2. Hierbei ist grundsätzlich davon auszugehen, dass die ausschließlichen Nutzungsrechte übertragen werden3. (5) Erstellung zum Zwecke der eigenen Nutzung

168

Handelt es sich bei dem Auftraggeber um einen Anwender, der die Software nur für eigene Zwecke beauftragt hat, so erwirbt dieser im Regelfall nur einfache Nutzungsrechte, u.U. auch das Umarbeitungsrecht4. Da der Auftraggeber die Software nur selbst nutzen will, benötigt er im Regelfall kein ausschließliches Nutzungsrecht bzw. die Befugnis, Dritten Nutzungsrechte einzuräumen5. Probleme ergeben sich für den Auftraggeber, wenn sich die von ihm ursprünglich verfolgten Ziele nach Vertragsschluss ändern. So wird z.B. häufig bei der Erstellung von Individualsoftware erst während des Erstellungsprozesses das Marktpotential des Produkts erkannt. Sofern der Auftraggeber dann die ursprünglich als Individualsoftware geplante Software als Standardsoftware auf den Markt bringen will, stellt sich die Frage, ob er die hierfür erforderlichen Rechte erworben hat. Maßgeblich ist hierfür der von den Parteien bei Abschluss des Vertrags vorausgesetzte Vertragszweck6. Dieser umfasst im beschriebenen Fall die Vermarktung des Produkts durch den Auftraggeber nicht. Auch der Umstand, dass der Auftraggeber die Entwicklung des Produkts durch seinen Auftrag erst ermöglicht hat und diese voll finanziert, begründet für sich gesehen noch keine umfassende Rechtseinräumung. Zu prüfen ist in diesen Fällen, ob die Parteien im Verlauf des Entwicklungsprojekts den ursprünglichen Vertragszweck einvernehmlich abgeändert haben und sich daraus auch Konsequenzen hinsichtlich des Umfangs der eingeräumten Rechte ergeben. Dies setzt aber voraus, dass der Auftragnehmer sich zumindest konkludent damit einverstanden erklärt hat, dass die Software vom Auftraggeber weiter vermarktet werden soll. (6) Nutzungsrechte am Quellcode

169

Im Interesse beider Parteien empfiehlt es sich, vertraglich klar zu regeln, ob der Auftraggeber Rechte nur am Objektcode oder auch am Quellcode erhält7. 1 2 3 4 5 6 7

Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 63. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 64. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 64; Redeker, IT-Recht, Rz. 34. Redeker, IT-Recht, Rz. 35. Redeker, IT-Recht, Rz. 35. Schricker/Loewenheim, § 31 Rz. 89. Vgl. hierzu die Formulierungsvorschläge von Witte, Erstellung von Individualsoftware, in: Redeker, Handbuch der IT-Verträge, § 5 Rechtsübertragung.

70

Karger

Schutz und Realisierung der Software

Rz. 171 A

In der Praxis fehlt es jedoch häufig an eindeutigen vertraglichen Regelungen. Entweder fehlen entsprechende Bestimmungen ganz1 oder die Klauseln sind nicht ausreichend klar formuliert. Wird z.B. ohne weitere Klarstellung für den Liefergegenstand nur der Begriff „Programm“ verwendet, kann davon sowohl der Objektcode als auch der Quellcode umfasst sein2. Die Rechtsprechung hat sich mit den Ansprüchen des Anwenders auf Überlassung des Quellcodes wiederholt beschäftigt, ohne hierbei zu einer einheitlichen Linie zu finden3. Bei der Softwareerstellung kann bei einer fehlenden ausdrücklichen Vereinbarung nicht von vorneherein davon ausgegangen werden, dass die Überlassung des Quellcodes und eine diesbezügliche Rechtseinräumung geschuldet sind4. Allerdings bejahen die Instanzgerichte eine Überlassungspflicht dann, wenn 170 besondere Umstände vorliegen: Eine Herausgabepflicht soll z.B. bestehen, wenn der Auftragnehmer mit dem Auftraggeber keinen langfristigen Wartungsvertrag abgeschlossen hat, die Mängelrechte verjährt sind und eine Fehlerbeseitigung durch Dritte erforderlich wird5. Des Weiteren soll eine Herausgabepflicht bestehen, wenn dem Auftraggeber nach dem Vertrag Änderungen einer Individualsoftware selbst oder durch Dritte möglich sein sollen und kein Wartungsvertrag abgeschlossen wird6. Unter bestimmten Voraussetzungen soll die Pflicht zur Überlassung der Dokumentation eine Pflicht zur Herausgabe des Quellcodes begründen7. Nach der Rechtsprechung des BGH scheidet ein Herausgabeanspruch aus, wenn der Anwender den Quellcode zur Nutzung des Programms nicht benötigt, weil der Anbieter die Vornahme von Änderungen und Fehlerbeseitigungen durch einen langfristigen Pflegevertrag übernommen hat8. Nach einer Entscheidung des BGH aus dem Jahr 20039 ist bei einer fehlenden Vereinbarung die Übergabe des Software – und damit wohl auch eine 1 Vgl. etwa den Sachverhalt zu BGH v. 16.12.2003 – X ZR 129/01 – Individualsoftwareerstellung, CR 2004, 490. 2 BGH v. 30.1.1986 – I ZR 242/83, MDR 1986, 910 = CR 1986, 377, 378 f. 3 S. hierzu Conrad, Wege zum Quellcode, ITRB 2005, 12, 13 ff. m.w.N. 4 Vgl. Hoeren, Die Pflicht zur Überlassung des Quellcodes, CR 2004, 721, 724; Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 65; Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 169 ff.; Burkart, Softwareerstellung – Anspruch auf Herausgabe des Quellcodes, ITRB 2003, 53, Ernst, Die Verfügbarkeit des Source Codes, MMR 2001, 208, 210; Schneider, Projektsteuerung – Projektrisiken bei Software, LG Duisburg v. 2.12.1999 – 8 O 219/99, CR 2000, 27, 30. 5 LG München I v. 18.11.1988 – 21 O 11130/88, CR 1989, 990; ablehnend dazu u.a. Hoeren, CR 2004, 721, 723. 6 LG Köln v. 3.5.2000 – 20 S 21/99, CR 2000, 505. 7 OLG Karlsruhe CR 1999, 11. 8 BGH v. 30.1.1986 – I ZR 242/83, MDR 1986, 910 = CR 1986, 377; ablehnend Malzer, Der Softwarevertrag, S. 296 ff. 9 BGH v. 16.12.2003 – X ZR 129/01 – Individualsoftwareerstellung, CR 2004, 490.

Karger

71

171

A Rz. 172

Grundlagen

entsprechende Nutzungsrechtseinräumung – geschuldet, wenn der Auftraggeber die Software weiter vermarkten will, er den Quellcode für Fehlerbeseitigungs-, Wartungs- und Änderungsarbeiten an der Software benötigt und dies dem Auftragnehmer bei Vertragsschluss bekannt war1. Offen bleibt hierbei, ob es sich bei „Vermarktung und Wartung“ um ein einheitliches Kriterium oder um zwei Kriterien handelt2. Wesentliche Bedeutung misst der BGH auch der vereinbarten Vergütung bei. Maßgeblich ist dabei, ob die Kostenkalkulation des Anbieters dafür oder dagegen spricht, dass die Überlassung des Quellcodes vereinbart war3. Hierbei ist aber unklar, inwieweit in der Praxis die Kostenkalkulation des Anbieters wirklich Rückschlüsse auf die Quellcodefrage ermöglicht4. 172

Im Schrifttum ist im Übrigen die Frage aufgeworfen worden, ob der Anbieter von Individualsoftware aus kartellrechtlichen Gründen zur Herausgabe des Quellcodes gezwungen werden kann5. Der Softwarehersteller hat das technische Monopol am Quellcode und damit eine marktbeherrschende Stellung. Bei Missbrauch dieser marktbeherrschenden Stellung ist eine Herausgabepflicht für den Quellcode denkbar. Ein solcher Missbrauch kommt etwa in Betracht, wenn sich der Anbieter weigert, eine Fehlerbeseitigung gegen angemessene Vergütung im Einzelfall zu übernehmen. 9. Vergütung

173

Bei Softwareerstellungsverträgen wird hinsichtlich der Vergütung häufig nur auf die Bestimmungen des Schuldrechts abgestellt. Je nach einschlägigem Vertragstyp kommen folgende Vorschriften in Betracht: Beim Werkvertrag die §§ 631 Abs. 1, 632, 632a, 640 BGB, beim Werklieferungsvertrag (i.S.d. § 651 BGB) § 433 Abs. 2 BGB und beim Dienstvertrag die §§ 612, 614 BGB.

174

Soweit es aber um die Einräumung urheberrechtlicher Nutzungsrechte geht, sind zusätzlich als vorrangige Spezialvorschriften die §§ 32, 32a, 32b und 32c UrhG zu beachten6.

175

Diese Bestimmungen gelten für alle Vertragstypen, die zumindest auch die Einräumung von Nutzungsrechten zum Gegenstand haben, insbesondere also für Werk- und Dienstverträge im Bereich der Softwareerstellung7. In1 BGH v. 16.12.2003 – X ZR 129/01 – Individualsoftwareerstellung, CR 2004, 490, 491, 492. 2 Conrad, Wege zum Quellcode, ITRB 2005, 12, 14. 3 BGH v. 16.12.2003 – X ZR 129/01 – Individualsoftwareerstellung, CR 2004, 490, 491. 4 Hoeren, Die Pflicht zur Überlassung des Quellcodes, CR 2004, 721, 724. 5 Moritz, Der Softwarepflegevertrag – Abschlusszwang und Schutz vor Kündigung zur Unzeit, CR 1999, 541, 545. 6 Zur Abgrenzung urheberrechtlicher Vergütungsansprüchen zu werk- und dienstvertraglichen Vergütungsansprüchen s. Hertin, GRUR 2011, 1065. 7 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 70.

72

Karger

Schutz und Realisierung der Software

Rz. 180 A

wieweit die §§ 32 und 32a UrhG auf Softwareprogrammierer im Arbeitsverhältnis anwendbar sind, ist allerdings streitig1. Die Bestimmungen des Urheberrechts gehen inhaltlich über die Bestimmungen des Schuldrechts hinaus, indem sie dem Urheber den Anspruch auf eine angemessene Vergütung bzw. auf eine zusätzliche Beteiligung sichern und ihm bei Vorliegen der gesetzlichen Voraussetzungen einen Anspruch gegen den Auftraggeber bzw. Verwerter auf Einwilligung zur Vertragsänderung zubilligen.

176

§ 32 Abs. 1 Satz 3 UrhG korrigiert die Angemessenheit der vertraglichen 177 Vergütung für den Normalfall der vertraglichen Nutzung, während der „Bestsellerparagraph“ § 32a UrhG dem Urheber im Nachhinein zusätzliche Beteiligungsansprüche gewährt, wenn seine Vergütung in ein auffälliges Missverhältnis zu den Erträgen des Verwerters gerät. Die Ansprüche der §§ 32 und 32a UrhG stehen selbständig mit jeweils eigenem Anwendungsbereich nebeneinander2. Auf eine Vereinbarung, mit der von § 32 Abs. 1 und 2 UrhG zum Nachteil 178 des Urhebers abgewichen wird, kann sich der Vertragspartner gem. § 32 Abs. 3 UrhG nicht berufen. Auch Umgehungsgestaltungen sind unwirksam. Auf Ansprüche gem. 32a Abs. 1 und 2 UrhG kann gem. § 32a Abs. 3 UrhG nicht im Voraus verzichtet werden. §§ 32 und 32a UrhG finden gem. § 32b UrhG zwingende Anwendung, wenn auf den Nutzungsvertrag mangels Rechtswahl deutsches Recht anzuwenden ist oder soweit Gegenstand des Vertrags maßgebliche Nutzungshandlungen in Deutschland sind. Die §§ 32 und 32a UrhG können für den Auftraggeber bzw. Verwerter erheb- 179 liche wirtschaftliche Belastungen mit sich bringen, so dass teilweise Überlegungen angestellt werden, ob und inwieweit hier durch entsprechende Vertragsgestaltung gegengesteuert werden kann, etwa durch Regelungen zur Verjährung oder zur Rechtswahl3. a) Anspruch auf angemessene Vergütung Nach § 32 Abs. 1 Satz 2 UrhG gilt eine angemessene Vergütung als vereinbart, wenn die Höhe der Vergütung nicht bestimmt ist. Soweit die vereinbarte Vergütung nicht angemessen ist, kann der Urheber nach § 32 Abs. 1 Satz 3 UrhG von seinem Vertragspartner die Einwilligung in die Änderung des Vertrags verlangen, durch die dem Urheber die angemessene Vergütung gewährt wird. § 32 Abs. 4 UrhG bestimmt, dass der Urheber keinen An1 Ausführlich zum Streitstand Grützmacher, in: Wandtke/Bullinger, § 69b Rz. 22 ff. m.w.N. Für eine zurückhaltende Anwendung des § 32 UrhG und eine vollumfängliche Anwendung des § 32a UrhG Schricker/Loewenheim, § 69b Rz. 18 f. 2 Grunert, in: Wandtke/Bullinger, § 32 Rz. 47. 3 S. hierzu etwa Hertin, Urhebervertragsnovelle 2002: Up-Date von Urheberrechtsverträgen, MMR 2003, 16, 18 ff.

Karger

73

180

A Rz. 181

Grundlagen

spruch nach § 32 Abs. 1 Satz 3 UrhG hat, soweit die Vergütung für die Nutzung seiner Werke tarifvertraglich bestimmt ist. 181

Der Gesetzgeber hat den Begriff der Angemessenheit nicht definiert und es im Wesentlichen der Vertragspraxis und den Gerichten überlassen, die Kriterien näher zu definieren1. Teilweise wird hier eine Drei-Stufen-Prüfung vorgenommen2. In diesem Zusammenhang kann nicht alleine die „übliche Vergütung“ i.S.v. §§ 612 Abs. 2, 632 Abs. 2 BGB als Maßstab herangezogen werden, denn was üblich ist, muß nicht immer angemessen i.S.v. § 32 UrhG sein3. Im Übrigen erfassen diese Ansprüche nur die Tätigkeiten des Urhebers an sich, nicht aber die Einräumung von Nutzungsrechten4.

182

Eine gesonderte Ermittlung der Angemessenheit ist gem. § 31 Abs. 2 UrhG entbehrlich, wenn eine gemeinsame Vergütungsregel i.S.v. § 36 UrhG besteht. Fehlt es – wie bei im Regelfall bei der Softwareerstellung5 – an solchen gemeinsamen Vergütungsregelungen, ist nach § 32 Abs. 2 UrhG zu prüfen, ob die Vergütung im Zeitpunkt des Vertragsschlusses dem entspricht, was im Geschäftsverkehr nach Art und Umfang der eingeräumten Nutzungsmöglichkeiten unter Berücksichtigung aller Umstände üblicherweise und redlicherweise zu leisten ist. Neben der Üblichkeit ist also auch die Redlichkeit zu prüfen; hierin liegt ein wesentlicher Unterschied zu den §§ 612 Abs. 2, 632 Abs. 2 BGB, die nur auf die Üblichkeit abstellen. Redlich ist eine Vereinbarung, die auf eine kontinuierliche Beteiligung des Urhebers angelegt ist und diesem unter Berücksichtigung seiner Arbeitsleistung prinzipiell ein angemessenes Auskommen auf Grund der Erträgnisse seiner Leistungen ermöglicht6. Unredlich ist hingegen jedenfalls, was unter treuwidriger Ausnutzung der schwachen Verhandlungsposition des Urhebers zu dessen Nachteil vereinbart wird7.

183

Kann keine Branchenübung festgestellt werden oder ist eine festgestellte Übung nicht redlich, so ist die angemessene Vergütung nach billigem Ermessen festzusetzen8. Als relevante Umstände können dabei z.B. die Marktverhältnisse, die getätigten Investitionen, die Risikotragung, die angefallenen Kosten und die zu erzielenden Einnahmen herangezogen werden9.

184

Die Vereinbarung von Einmalzahlungen einer Pauschalabgeltung in sog. Buy-Out-Verträgen widerspricht nicht von vorneherein dem Gebot der 1 2 3 4 5 6 7

Grunert, in: Wandtke/Bullinger, § 32 Rz. 22. Grunert, in: Wandtke/Bullinger, § 32 Rz. 24 ff. Schack, Urhebervertragsrecht im Meinungsstreit, GRUR 2002, 853, 855. Grunert, in: Wandtke/Bullinger, § 32 Rz. 35. Vgl. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 70. Vgl. Grunert, in: Wandtke/Bullinger, § 32 Rz. 29. Grunert, in: Wandtke/Bullinger, § 32 Rz. 29 mit Hinweis auf BVerfG v. 27.7.2005 – 1 BvR 2501/04 – Xavier Naidoo, GRUR 2005, 880, 882. 8 Schricker/Haedicke, § 32 Rz. 32; Erdmann, Urhebervertragsrecht im Meinungsstreit, GRUR 2002, 923, 926. 9 Erdmann, Urhebervertragsrecht im Meinungsstreit, GRUR 2002, 923, 926.

74

Karger

Schutz und Realisierung der Software

Rz. 187 A

angemessenen Vergütung. Allerdings stößt eine Einmalzahlung für alle erdenklichen Nutzungsarten und Nutzungsrechte regelmäßig schnell an die Grenzen des Angemessenen, so dass erlösanteilige Vergütungen vorzugswürdig sind1. Ist die Vergütung unangemessen, so hat der Urheber gem. § 32 Abs. 1 Satz 3 185 UrhG einen Anspruch auf Einwilligung in die Änderung des Vertrags, durch die ihm eine angemessene Vereinbarung gewährt wird. Der Anspruch richtet sich nur gegen den Vertragspartner. Ob dieser die Leistung tatsächlich nutzt bzw. Erträge erwirtschaftet, ist unbeachtlich2. Die Vertragsanpassung wirkt für den gesamten vergangenen und künftigen Zeitraum, in dem die Vergütungsabrede unangemessen war bzw. ist3. Bei Fälligkeit der Vergütungsansprüche kann der Urheber unmittelbar auf Zahlung klagen4. Im Schrifttum wird dem Vertragsanpassungsanspruch für den Bereich der Softwareerstellung tendenziell eine geringere Bedeutung zugemessen als für andere Branchen (z.B. Übersetzer im Verlagsbereich), da die Vergütungen in der Softwarebranche vergleichsweise hoch liegen5. Allerdings ist diese Einschätzung nicht allgemeingültig, es ist stets der konkrete Einzelfall zu prüfen. § 32 UrhG gewährt bei Unangemessenheit der Vergütung nur einen Ver- 186 tragsanpassungsanspruch, nicht aber die Möglichkeit, vom Vertrag insgesamt Abstand zu nehmen. Allein die Tatsache der Unangemessenheit dürfte dem Urheber noch kein Kündigungsrecht aus wichtigem Grund geben, wobei es auf die Umstände des Einzelfalls ankommt6. Allerdings kommt bei einer gravierenden Unangemessenheit eine Kündigung aus wichtigem Grund nach § 314 BGB in Betracht7. Nach § 32 Abs. 3 Satz 1 und 2 UrhG kann von den Bestimmungen der § 32 187 Abs 1 und 2 UrhG nicht zum Nachteil des Urhebers abgewichen werden. Allerdings gibt es eine praxisrelevante Ausnahme vom Grundsatz der angemessenen Vergütung: Gem. § 32 Abs. 3 Satz 3 kann der Urheber unentgeltlich ein einfaches Nutzungsrecht für jedermann einräumen. Diese sog. „Linux-Klausel“ ermöglicht die gemeinsame Schaffung und Verwertung urheberrechtlich geschützter Erzeugnisse, die auf dem gemeinschaftlichen Verzicht auf eine gewinnbringende Verwertung beruhen8 und wurde als Sonderregelung für die Open Source-Modelle geschaffen9.

1 2 3 4 5 6 7 8 9

Grunert, in: Wandtke/Bullinger, § 32 Rz. 38. Grunert, in: Wandtke/Bullinger, § 32 Rz. 14. Grunert, in: Wandtke/Bullinger, § 32 Rz. 19. Zur Rechtsdurchsetzung s. Schricker/Haedicke, § 32 Rz. 46. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 70. Grunert, in: Wandtke/Bullinger, § 32 Rz. 53. Grunert, in: Wandtke/Bullinger, § 32 Rz. 53. Grunert, in: Wandtke/Bullinger, § 32 Rz. 45. Erdmann, Urhebervertragsrecht im Meinungsstreit, GRUR 2002, 923, 927.

Karger

75

A Rz. 188

Grundlagen

b) Anspruch auf weitere Beteiligung (§ 32a UrhG) aa) Anspruch gegen den Lizenznehmer 188

Hat der Urheber einem anderen ein Nutzungsrecht zu Bedingungen eingeräumt, die dazu führen, dass die vereinbarte Gegenleistung unter Berücksichtigung der gesamten Beziehungen des Urhebers zu dem anderen in einem auffälligen Missverhältnis zu den Erträgen und Vorteilen aus der Nutzung des Werks steht, so ist der andere gem. § 32a Abs. 1 UrhG auf Verlangen des Urhebers verpflichtet, in eine Änderung des Vertrags einzuwilligen, durch die dem Urheber eine den Umständen nach weitere angemessene Beteiligung gewährt wird. Ob die Vertragspartner die Höhe der erzielten Erträge oder Vorteile vorhergesehen haben oder hätten vorhersehen können, ist dabei unerheblich.

189

§ 32a Abs. 1 UrhG gewährt dem Urheber wie § 32 Abs. 1 Satz 3 UrhG lediglich einen Vertragsanpassungsanspruch. Der Anspruchsinhaber hat keinen direkten Anspruch auf eine weitere Beteiligung, sondern nur einen Anspruch auf Einwilligung in eine Vertragsänderung. In der Praxis kann aber jedenfalls für abgeschlossene Sachverhalte in der Vergangenheit gleich dasjenige verlangt und eingeklagt werden, was sich aus der angepassten Vertragslage ergeben würde1.

190

Erträge des Werks sind die vom Lizenznehmer erzielten Bruttoerlöse, wobei dessen Unkosten außer Betracht bleiben2. Zu den Vorteilen zählen alle sonstigen Vermögensvorteile, z.B. Zuschüsse, Fördergelder, Umsatzsteigerungen und Kostensenkungen im Betrieb des Lizenznehmers3.

191

Ein „auffälliges Missverhältnis“ besteht nach einer in der Literatur vertretenen Auffassung schon dann, wenn die Gegenleistung 20–30 % unter dem liegt, was bei einer üblichen und redlichen Beteiligung des Urhebers zu leisten wäre4. Allerdings wird diskutiert, ob bei der Softwareentwicklung insoweit Einschränkungen zu machen sind, da Softwareentwickler weder wirtschaftlich noch ideell besonders schutzwürdig seien5.

192

Der Anspruch gegen den Lizenznehmer ist gem. § 32a Abs. 2 Satz 2 UrhG ausgeschlossen, wenn die Erträgnisse und Vorteile nicht beim Lizenznehmer, sondern bei einem Unterlizenznehmer anfallen. bb) Anspruch gegen einen Dritten

193

Hat der andere das Nutzungsrecht einem Dritten übertragen oder weitere Nutzungsrechte eingeräumt und ergibt sich das auffällige Missverhältnis 1 2 3 4

Grunert, in: Wandtke/Bullinger, § 32a Rz. 3. Grunert, in: Wandtke/Bullinger, § 32a Rz. 11. Grunert, in: Wandtke/Bullinger, § 32a Rz. 12 f. Grunert, in: Wandtke/Bullinger, § 32a Rz. 20; s. auch Schricker/Haedicke, § 32a Rz. 20. 5 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 70.

76

Karger

Schutz und Realisierung der Software

Rz. 197 A

aus den Erträgnissen oder Vorteilen eines Dritten, so haftet gem. § 32a Abs. 2 UrhG der Dritte dem Urheber unter Berücksichtigung der vertraglichen Beziehungen in der Lizenzkette. Die Vorschrift begründet eine unmittelbare gesetzliche Durchgriffshaftung des Dritten unabhängig von den Vertragsbeziehungen1. Vergleichsmaßstab für die Ermittlung des auffälligen Missverhältnisses 194 nach den gleichen Grundsätzen wie im Rahmen des § 32a Abs. 1 UrhG sind nur die Erträgnisse und Vorteile, die der Dritte selbst aus der Nutzung erzielt hat. In einer längeren Kette von Verwertern haftet jeder dem Urheber grundsätzlich nur für diejenigen Erträge, die auf der eigenen Stufe angefallen sind2. 10. Rechtsfolgen bei Urheberrechtsverletzungen In der Praxis kommt es nicht selten vor, dass bei der Softwareerstellung Ur- 195 heberrechte Dritter verletzt werden, z.B. durch eine unerlaubte Übernahme schutzfähiger Elemente in das zu entwickelte Softwareprodukt. Deshalb müssen sich die Beteiligten auch über die Rechtsfolgen etwaiger Verletzungen bewusst sein. Die Sanktionen bei der Verletzung des Urheberrechts oder verwandter Schutzrechte richten sich nach den allgemeinen Bestimmungen. Für Computerprogramme gilt darüber hinaus § 69f UrhG3. Die §§ 97 ff. UrhG finden auch auf Computerprogramme Anwendung4. Der 196 Rechtsinhaber kann bei Verletzungshandlungen gem. § 97 Abs. 1 UrhG die Beseitigung der Beeinträchtigung, bei Wiederholungsgefahr Unterlassung und bei Verschulden auch Schadensersatz bzw. die Herausgabe des Verletzergewinns und Rechungslegung über den Gewinn verlangen5. Bei Verschulden sieht § 97 Abs. 2 UrhG eine Entschädigung auch für immaterielle Schäden vor, die aber im Bereich der Softwareerstellung nur ausnahmsweise in Betracht kommen dürften. Unabhängig vom Vorliegen eines Verschuldens kann der Kläger nach §§ 812, 818 Abs. 2 BGB den objektiven Gegenwert für die unberechtigte Nutzung verlangen. Nach § 69f Abs. 1 Satz 1 UrhG kann der Rechtsinhaber vom Eigentümer 197 oder Besitzer die Vernichtung aller rechtswidrig hergestellten, verbreiteten oder zur rechtswidrigen Verbreitung bestimmten Vervielfältigungsstücke eines Computerprogramms verlangen6. § 69f UrhG geht der allgemeinen Vorschrift des § 98 UrhG als Spezialregelung vor. Die Vorschrift ist weiter 1 Erdmann, Urhebervertragsrecht im Meinungsstreit, GRUR 2002, 923, 927. 2 Grunert, in: Wandtke/Bullinger, § 32a Rz. 28. 3 Zu den Rechtsfolgen von Softwareverletzungen s. Redeker, IT-Recht, Rz. 204 ff.; Karger, Beweisermittlung im deutschen und U.S.-amerikanischen Softwareverletzungsprozess. 4 Grützmacher, in: Wandtke/Bullinger, § 69a Rz. 77. 5 S. hierzu weiterführend Redeker, IT-Recht, Rz. 204 ff. 6 S. hierzu u.a. Raubenheimer, Vernichtungsanspruch gemäß § 69f UrhG, CR 1994, 129.

Karger

77

A Rz. 198

Grundlagen

gefasst als § 98 UrhG, da sich § 98 UrhG nur gegen den Verletzer richtet, während bei § 69f UrhG das bloße Eigentum oder Besitz an einem rechtswidrig erstelltem bzw. verbreiteten Vervielfältigungsstück ausreicht, ohne dass der Anspruchsgegner zugleich Verletzer sein muss. 198

Gemäß § 69f Abs. 1 Satz 2 UrhG i.V.m. § 98 Abs. 2 UrhG kann der Verletzte auch die Überlassung der Vervielfältigungsstücke des Computerprogramms gegen Erstattung der Herstellungskosten verlangen.

199

Nach § 69f Abs. 2 UrhG kann der Verletzte außerdem die Vernichtung derjenigen Mittel verlangen, die allein dazu bestimmt sind, die unerlaubte Beseitigung oder Umgehung technischer Programmschutzmechanismen zu erleichtern. Im Übrigen steht dem Rechtsinhaber nach § 99 UrhG ein Anspruch auf Vernichtung oder Überlassung sämtlicher ausschließlich oder nahezu ausschließlich zur rechtswidrigen Herstellung von Vervielfältigungsstücken benutzten oder hierzu bestimmten Vorrichtungen zu.

200

Erfolgt die widerrechtliche Verletzung in einem Unternehmen durch einen Arbeitnehmer oder einen Beauftragten, so stehen dem Verletzten gem. § 100 UrhG die Ansprüche gem. §§ 97 bis 99 UrhG auch gegen den Inhaber des Unternehmens zu; ausgenommen ist allerdings der Anspruch auf Schadensersatz.

201

Zu beachten ist auch § 106 UrhG, der die unerlaubte Verwertung urheberrechtlich geschützter Werke unter Strafe stellt. Gem. § 108 Abs. 1 Nr. 8 UrhG ist die entgegen § 87b Abs. 1 UrhG erfolgende Verwertung einer Datenbank strafbar.

II. Patentrecht 1. Überblick über das Schutzsystem 202

Technische Schutzrechte sind Patente und Gebrauchsmuster. Patente und Gebrauchsmuster werden vom Staat als zeitlich begrenzte Ausschließlichkeitsrechte gewährt zum Lohn dafür, dass der Erfinder seine Erfindung der Allgemeinheit mitteilt. Patente und Gebrauchsmuster werden nur für „technische Erfindungen“ gewährt. So heißt es bspw. in Art. 27 TRIPS1, dass Patente auf allen Gebieten der Technik erhältlich sein sollen. Streitig ist aber, was „Technik“ ist, etwa im Unterschied zu bloßen Geschäftsmethoden. Dieser Streit spielt eine große Rolle bei der Frage, inwieweit Software dem Patentschutz zugänglich ist.

1 TRIPS = Trade Related Aspects of Intellectual Property im Rahmen von Gatt/ WTO am 15.4.1994 abgeschlossen, BGBl. II 1994, 1730; Text (englisch) (deutsch) in PatR, Beck-Texte im dtv 5563 unter Nr. 63.

78

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 205 A

Im Patentrecht gilt, wie für alle gewerblichen Schutzrechte, das Territoriali- 203 tätsprinzip. Deutsche Patente genießen nur in Deutschland Schutz, umgekehrt genießen ausländische Patente in Deutschland keinen Schutz. Das Territorialitätsprinzip ist in allen Rechtsordnungen anerkannt. Daraus folgt, dass das inhaltlich gleiche Patent in verschiedenen Ländern für verschiedene Inhaber geschützt sein kann. Es müssen also Patente für alle Länder erworben werden, in denen der Schutz von Interesse ist. Auch wenn es fallweise wirtschaftlich ausreichend sein kann, nur einige Kernländer schutzrechtlich zu sperren, um den Konkurrenten überregional auszuschalten, so bedeutet das gleichwohl im Regelfall für ein auch im Ausland tätiges Unternehmen, dass es grundsätzlich in jedem einzelnen Staat das nationale Anmeldeverfahren mit seinen jeweiligen formalen und materiellen Anforderungen durchlaufen müsste. Umgekehrt ist eine in einem Territorium veröffentlichte Patentanmeldung neuheitsschädlich für spätere Anmeldungen in anderen Territorien. Der Wunsch nach Harmonisierung hat zum Abschluss internationaler Abkommen geführt, die zumindest in Einzelbereichen Angleichungen und Erleichterungen für die Schutzrechtsinhaber bewirken. Damit ein Unternehmen überhaupt einen auskömmlichen, geschützten 204 Zeitrahmen für Anmeldungen in mehreren Staaten hat, ist die Pariser Verbandsübereinkunft zum Schutz des gewerblichen Eigentums vom 20.3.1883 (PVÜ)1 zwischen den Staaten geschlossen worden und ist jetzt fast weltweit gültig. Die meisten Länder sind der letzten Fassung beigetreten, der Stockholmer Fassung vom 14.7.1967. Artikel 4 PVÜ regelt die Priorität: Eine innerhalb von 12 Monaten nach der 205 in einem Verbandsstaat vorgenommenen Erstanmeldung erfolgende Zweitanmeldung erhält die Priorität der Erstanmeldung, wenn es sich um die gleiche Erfindung und den gleichen Nachanmelder oder seinen Rechtsnachfolger handelt. Art. 4 B PVÜ bestimmt die Wirkung des Prioritätsrechts: die Folgeanmeldung in einem anderen Territorium wird nicht unwirksam gemacht durch in der Prioritätsfrist eingetretene Tatsachen, etwa Zwischenanmeldungen oder Veröffentlichungen oder offenkundige Vorbenutzungen in einem Staat. Die Priorität muss jedoch rechtzeitig förmlich in Anspruch genommen werden. Nach Art. 4 F PVÜ kann bei der Nachanmeldung auch die Priorität mehrerer Voranmeldungen in Anspruch genommen werden, wenn sie in dem 12-Monats-Zeitraum liegen. Auf diese Weise ist sichergestellt, dass der Anmelder einen ausreichenden Zeitraum hat, um in verschiedenen Territorien überhaupt wirksam anmelden zu können und um auch in seinem Heimatland durchgeführte und angemeldete Verbesserungen in die Folgeanmeldungen einfließen lassen zu können.

1 Pariser Verbandsübereinkunft zum Schutz des gewerblichen Eigentums v. 20.3.1883, in der für Deutschland verbindlichen Stockholmer Fassung v. 14.7.1967, BGBl. 1970 II 391; Text (englisch) (deutsch) in PatR, Beck-Texte im dtv 5563 unter Nr. 60.

M. Brandi-Dohrn

79

A Rz. 206

Grundlagen

a) Nationales Patentrecht Deutschland aa) Erteilung 206

Für technische Erfindungen werden nach § 1 Abs. 1 PatG1 in Deutschland nach einem patentamtlichen Prüfungsverfahren auf Neuheit und Erfindungshöhe Patente erteilt. In der Anmeldung muss die Erfindung ausführbar offenbart werden. Für die ausführbare Offenbarung wird aber keine Offenlegung des Quellcodes gefordert2. Das Programm wird auch in den Ansprüchen generell mit Funktionen und Aufgaben der Mittel wie Speicher, Eingabemittel, Verarbeitungsmittel usw. definiert. Für den Vorrang gilt, vorbehaltlich des Prioritätsrechts, das first to file-Prinzip in § 6 PatG. Das first to file-Prinzip gilt weltweit bis auf USA, die das first to inventPrinzip pflegen. Wird das Patent versagt, so hat der Anmelder dagegen die Möglichkeit der Beschwerde zum Bundespatentgericht (BPatG).

207

Gebrauchsmuster werden in Deutschland und auch in Österreich ohne Vorprüfung registriert, in Deutschland aber nicht für Verfahren, in Österreich hingegen auch für Computerprogramme. Die Abgrenzung zwischen nicht gebrauchsmusterfähigem Verfahren und gebrauchsmusterfähiger Sachen kann fließend sein, so hat der BGH einer nur als Programm sinnvollen Signalfolge die Gebrauchsmusterfähigkeit zugesprochen3.

208

Jede Patentanmeldung wird nach 18 Monaten ab Prioritätsdatum offengelegt. Will man die Anmeldung als Know-how wahren, muss man sie also rechtzeitig vorher zurücknehmen. Ab Offenlegung genießt der Anmelder einen reduzierten einstweiligen Schutz nach § 33 PatG: er hat einen Anspruch auf angemessene Vergütung nach der Lizenzanalogie, er hat jedoch noch keine Unterlassungsansprüche. Die kann er sich jedoch schaffen, indem er aus dem vor der Erteilung stehenden Patent ein Gebrauchsmuster nach § 5 GebrMG abzweigt und ohne langwierige Prüfung kurzfristig eintragen lässt. Die erteilten Patente und die registrierten Gebrauchsmuster gewähren ihrem Inhaber ab Veröffentlichung der Erteilung ein absolutes Ausschließlichkeitsrecht für eine Laufzeit bis zu 20 Jahren bei Patenten und bis zu 10 Jahren bei Gebrauchsmustern. Die Laufzeit rechnet ab Anmeldetag, bei abgezweigten Gebrauchsmustern ab Anmeldetag des Mutterschutzrechts. Über die PVÜ hinaus kann der Anmelder nicht nur die Priorität einer Erstanmeldung in einem anderen Staat in Anspruch nehmen, sondern nach § 40 PatG auch die Priorität einer früheren Patent- oder Gebrauchsmusteranmeldung in Deutschland.

1 Patentgesetz in der Fassung des Gesetzes zur Umsetzung der Richtlinie über den rechtlichen Schutz biologischer Erfindungen v. 21.1.2005, BGBl. I 2005, 146 und des Gesetzes zur Vereinfachung und Modernisierung des Patentrechts v. 31.7.2009, BGBl. I 2009, 2521, zuletzt geändert 24.11.2011, BGBl. 1, 2302. 2 BPatG v. 8.7.2004 – 17 W (pat) 8/02 – Quellcode, CR 2004, 810 = GRUR 2004, 934. 3 BGH v. 17.2.2004 – X ZB 9/03 – Signalfolge, GRUR 2004, 495.

80

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 211 A

bb) Einspruch Innerhalb von 3 Monaten nach Veröffentlichung der Erteilung kann jeder- 209 mann beim Deutschen Patent- und Markenamt (DPMA) Einspruch einlegen, § 59 PatG. Ein solches Einspruchsverfahren gibt es auch z.B. in Österreich, nicht aber in der Schweiz oder Frankreich. Der Einspruch kann nur auf eine exklusive Liste von Gründen, die in § 21 PatG aufgezählt sind, gestützt werden. Die wichtigsten darunter sind mangelnde Neuheit, mangelnde Erfindungshöhe und mangelnde Offenbarung. Die Einspruchsgründe müssen im Einzelnen substantiiert werden, andernfalls ist der Einspruch nicht zulässig. Wird das Patent ganz oder teilweise widerrufen, so kann der Patentinhaber dagegen Beschwerde zum BPatG (Frist: 1 Monat) einlegen und, soweit es aufrecht erhalten wird, auch der dadurch beschwerte Einsprechende. cc) Verletzung Das absolute Ausschließlichkeitsrecht ist in § 9 PatG definiert und umfasst 210 das Herstellen, Anbieten und Inverkehrbringen, bei Verfahren die Anwendung des Verfahrens und das Anbieten oder Inverkehrbringen der unmittelbaren Verfahrenserzeugnisse, auch wenn das Verfahren selbst im Ausland ausgeübt worden ist. Verboten ist nach § 10 PatG auch das Inverkehrbringen von wesentlichen Mitteln an nichtberechtigte Dritte im Inland, wenn die Mittel geeignet und bestimmt sind zur Benutzung des Patents (sog. mittelbare Patentverletzung). Die Verletzungshandlungen sind international ziemlich weitgehend harmonisiert, zuerst im Vorgriff auf Art. 25–27 des dann nicht in Kraft getretenen Gemeinschaftspatentübereinkommens (GPÜ)1, und sodann durch Art. 28 des TRIPS-Übereinkommens und neuerdings wieder durch Art. 25–27 des unterzeichneten, aber 2013 noch nicht ratifizierten „Übereinkommens über ein einheitliches Patentgericht“2 der EU-Mitgliedsstaaten bis auf Spanien und Italien. Das Ausschließlichkeitsrecht wirkt, anders als das Urheberrecht, auch gegen spätere unabhängige Doppelerfindungen, ja sogar gegen die frühere Erfindung, wenn diese nicht vor dem Anmelde- bzw. Prioritätstag des nachfolgenden Patents in Benutzung genommen oder wenigstens Veranstaltungen dazu getroffen wurden (Vorbenutzungsrecht nach § 12 PatG). Die Durchsetzung ist erleichtert worden durch die EU-Enforcement-Richtlinie3, die zu einem speziellen Besichtigungs- und Vorlageanspruch in § 140c PatG, entsprechend in § 101a UrhG, geführt hat. Der sachliche Schutzumfang wird, übereinstimmend mit europäischem 211 Recht in § 14 PatG bestimmt. Das Verletzungsgericht, spezialisierte Land1 GPÜ v. 15.12.1975, revidiert 15.12.1989, EG ABl. 1989 L 401/10, abgedruckt bei Beck, Textsammlung Gewerblicher Rechtsschutz, Nr. 670. 2 EU-Ratsdokument 16351/12, abrufbar über www.consilium.europa.eu dort unter der Rubrik „Dokumente“ (documents). 3 EU Richtlinie 2004/48 EG v. 29.4.2004, ABl. EG 2004, L 157, 45 = Beck Texte im dtv 5563, PatR. 2010, Nr. 59.

M. Brandi-Dohrn

81

A Rz. 212

Grundlagen

gerichte, prüft nach der Rechtsprechung des BGH, ob eine angegriffene Ausführungsform im Schutzumfang des Patents liegt, in einem Zwei-StufenVerfahren: liegt sie im funktional verstandenen Wortlaut, liegt sie darüber hinaus im Äquivalenzbereich1? Das deutsche Verletzungsgericht prüft, anders als in den meisten anderen europäischen Staaten, nicht den Rechtsbestand des Patents. Es kann nur nach § 148 ZPO aussetzen, wenn ein Einspruch oder eine Nichtigkeitsklage mit hoher Erfolgswahrscheinlichkeit anhängig sind. Mit solchen Aussetzungen sind die Gerichte zurückhaltend im Hinblick auf die ohnehin begrenzte Laufdauer von Patenten. Ein eigenes Überprüfungsrecht haben die Verletzungsgerichte nach § 13 GebrMG jedoch in Gebrauchsmusterverletzungssachen. dd) Nichtigkeit 212

Ein Patent kann auch nach seiner unbeanstandeten Erteilung, selbst nach einem letztinstanzlich erfolglosen Einspruchsverfahren durch jedermann, auch durch den erfolglosen Einsprechenden, mit einer Nichtigkeitsklage nach § 81 PatG beim BPatG angegriffen werden. Nichtigkeitsgründe sind die gleichen wie die Einspruchsgründe. Gegen die Urteile des BPatG in Nichtigkeitssachen ist das Rechtsmittel der Berufung zum BGH als Tatsacheninstanz nach §§ 110 ff. PatG gegeben. Dabei gibt es keine Einschränkung durch Zulassung und Nichtzulassungsbeschwerde und freies Vertretungsrecht durch jeden inländischen Patentanwalt oder Rechtsanwalt. b) Europäische Patente

213

1973 haben sieben europäische Staaten das Europäische Patentübereinkommen mit Ausführungsordnung2 abgeschlossen, das am 1.5.1978 in Kraft trat. Eine revidierte Fassung, das EPÜ 2000, mit neuer Ausführungsordnung trat am 13.12.2007 in Kraft. Die europäische Patentorganisation (EPO) hat heute 38 Mitglieder3. Das Europäische Patentübereinkommen – EPÜ – ist ein zen1 BGH v. 29.4.1986 – X ZR 28/85 – Formstein, MDR 1986, 1023 = GRUR 1986, 803; BGH v. 2.3.1999 – X ZR 85/96 – Spannschraube, MDR 1999, 1215 = GRUR 1999, 909; BGH v. 12.3.2002 – X ZR 168/00 – Schneidmesser I, GRUR 2002, 515; BGH v. 12.3.2002 – X ZR 135/01 – Schneidmesser II, GRUR 2002, 519. 2 Übereinkommen über die Erteilung europäischer Patente (EPÜ) v. 5.10.1973 mit Ausführungsordnung, BGBl. II 1976, 826, in Kraft gesetzt für Deutschland durch das Gesetz über internationale Patentübereinkommen (IntPatÜG) v. 21.6.1976, BGBl. II 1976, 649, beide in fast allen patentrechtlichen Kommentaren und Gesetzessammlungen über gewerblichen Rechtsschutz abgedruckt, das EPÜ samt Nebenbestimmungen auch herausgegeben vom Europäischen Patentamt (EPA). Das EPÜ wird gemeinhin zitiert als Art. X EPÜ, die Ausführungsordnung nach ihren Regeln R Y EPÜ. 3 Mitgliedsstaaten sind (August 2011) nach der Webseite des EPA (http://www. epo.org/): Albanien (AL ab 1.5.2010), Belgien (BE), Bulgarien (BG ab 1.7.2002), Dänemark (DK ab 1.1.1990), Deutschland (DE), Estland (EE ab 1.7.2002), Finnland

82

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 215 A

traler Erteilungsverband und ein zentraler Einspruchsverband. Das EPÜ ist ein Sonderabkommen unter Art. 19 PVÜ. Der Verband hat eine eigene, supranationale Organisation, die Europäische Patentorganisation (EPO) mit dem Europäischen Patentamt (EPA) in München und Den Haag. Verletzung und Nichtigkeit bleiben, in einem vom EPÜ gesetzten Rahmen, national. aa) Erteilung Europäische Patente können entweder über das DPMA oder direkt beim EPA 214 angemeldet werden. Das EPÜ enthält in Art. 87, 88 EPÜ eine vollständige aber erweiterte parallele Prioritätsregelung zur PVÜ, naturgemäß beschränkt auf die technischen Schutzrechte. Erweitert ist die Prioritätsregelung, indem nicht nur die Priorität aus einem PVÜ Mitgliedsland, sondern auch aus WTOMitgliedsländern in Anspruch genommen werden kann und um die für Sonderabkommen zur PVÜ erlaubte günstige Ergänzung der „inneren“ Priorität: Auch das Land der Ursprungsanmeldung darf für eine EP-Nachanmeldung benannt werden. Das EPA nimmt nach Eingang eine doppelte Formalprüfung vor: erstens die Eingangsprüfung nach Art. 90 EPÜ, ob den in Art. 80, R. 40 EPÜ genannten Mindestanforderungen für die Zuerkennung eines europäischen Anmeldetags genügt ist, und zweitens eine Formalprüfung nach Art. 91 EPÜ, ob den sonstigen Formerfordernissen nach Art. 78 EPÜ und R. 38 ff. EPÜ entsprochen worden ist. Durch die Formalien führt ein Anmeldeformblatt, dessen Benutzung auch vorgeschrieben ist. Nach Art. 79 EPÜ und Art. 2 Nr. 3 GebO gelten seit 2009 alle Vertragsstaaten für eine Pauschgebühr von derzeit 500 Euro als benannt. Nicht benötigte Staaten kann man ausdrücklich ausnehmen oder später das Patent in diesem Staat nicht validieren (= häufig: Übersetzung und nationale Gebühren). Gleichzeitig mit der Formalprüfung erstellt die Recherchenabteilung einen 215 Recherchenbericht, den es in dieser obligatorischen Form im deutschen PatG nicht gibt. Es werden neuheitsschädliche oder erfindungsbedeutsame Druckschriften ermittelt und nach ihrer Relevanz für die Anmeldung klassifiziert mit kurzer Angabe der relevanten Fundstellen im Dokument, Art. 92 EPÜ, R. 61 EPÜ. Im Zuge der Zusammenführung von Recherche und Prüfung (Bringing Examination and Search Together = BEST) führt der Sachprüfer auch schon die Recherche durch. Seit dem 1.3.2003 ist der erwei(FI ab 1.3.1996), Frankreich (FR), Griechenland (GR ab 1.10.1986), Irland (IE ab 1.8.1992), Italien (IT ab 1.12.1978), Island (IS ab 31.8.2004), Kroatien (HR ab 1.1.2008), Lettland (LV ab 1.7.2005); Liechtenstein (LI ab 1.4.1980), Litauen (LT ab 1.12.2004), Luxemburg (LU), Malta (MT ab 1.3.2007), Monaco (MC), Niederlande (NL), Norwegen (NO ab 1.1.2008), Österreich (AT ab 1.5.1979), Polen (ab 1.3.2004), Portugal (PT ab 1.1.1992), Rumänien (RO ab 1.3.2003), Schweden (SE), Schweiz (CH), Serbien (RS ab 1.10.2010), Slowakei (SK ab 1.7.2002), Slowenien (SI ab 1.12.2002), Spanien (ES), Tschechien (CZ ab 1.7.2002), Türkei (TR) ab 1.11.2000, Ungarn (HU ab 1.1.2003), United Kingdom (GB), Zypern (CY ab 1.4.1998). Erstreckungsstaaten, für die ebenfalls vom EPA ein Patent erteilt werden kann, sind: BA – Bosnien/Herzegowina, und Montenegro (ME).

M. Brandi-Dohrn

83

A Rz. 216

Grundlagen

terte europäische Recherchenbericht (EESR = Extended European Search Report) als Pilotprojekt eingeführt worden und ist durch R. 62 EPÜ Standard geworden. Mit dem erweiterten europäischen Recherchenbericht erhält der Anmelder entweder den 1. Prüfungsbescheid, der die Einwände gegen die Patenterteilung enthält, oder eine positive Erklärung enthält, dass ein Patent erteilt werden kann. Mit der Offenlegung 18 Monate nach dem Prioritätsdatum erhält der Anmelder diesen Recherchenbericht = ersten Prüfungsbescheid. Der Anmelder hat alsdann sechs Monate Zeit, um den Prüfungsantrag zu stellen, zu dem vorläufigen ersten Prüfungsbescheid Stellung zu nehmen, die Prüfungsgebühr einzuzahlen und auch die Benennungsgebühr, Art. 94–96 EPÜ, Art. 79 EPÜ1. 216

Es schließt sich das sachliche Prüfungsverfahren an auf Patentfähigkeit nach Art. 52 EPÜ – Patentfähigkeit des Gegenstands, Art. 54 EPÜ – Neuheit, Art. 56 EPÜ – Erfinderische Tätigkeit, Art. 83 EPÜ – befähigende Offenbarung, Art. 84 EPÜ – Klarheit der Ansprüche und Stützung durch die Beschreibung. Das Neuheitserfordernis im EPÜ gilt nach Art. 54 EPÜ weltweit und ohne Neuheitsschonfrist außer, nach Art. 55 EPÜ bei missbräuchlichen Veröffentlichungen und dann mit 6 Monaten Schonfrist nur vor dem Anmeldetag2. Dass irgendeine Vorbenutzung, mündliche oder schriftliche Verlautbarung irgendwo auf der Welt zählt, ist patentrechtlich internationaler Standard. Das ist aber unterschiedlich zu § 3 DE-GbrMG: dort zählen zwar weltweite schriftliche Veröffentlichungen, aber nur inländische Vorbenutzungen. Das Fehlen einer Neuheitsschonfrist unterscheidet das europäische und die kontinentalen Patentrechte vom US-Recht, wo es eine einjährige grace period gibt, aber auch vom DE-Gebrauchsmusterrecht, das in § 3 eine 6-Monats-Neuheitsschonfrist vor der Prio-Anmeldung gegen eigene Vorveröffentlichungen gibt.

217

Der Anmelder darf im materiellen Prüfungsverfahren, um Beanstandungen des Prüfers Rechnung zu tragen, den Anspruch wenigstens einmal ändern. Am Ende versagt entweder das EPA, nach rechtlichem Gehör, Art. 113 EPÜ, die Anmeldung3 oder teilt dem Anmelder in einem Bescheid nach R. 71 (3) 1 Nach Art. 2 Nr. 3 GebO-EPÜ beträgt sie 500 Euro. 2 Ob sechs Monate vor der Priorität oder nur vor dem Tag der Nachanmeldung war streitig. Für den Tag der Nachanmeldung haben entschieden: EPA v. 12.7.2000, G 3/98 und G 2/99 – Sechsmonatsfrist, ABl. EPA 2001/62/83 = GRUR Int. 2001, 340: BGH v. 5.12.1995 – X ZB 1/94 – Corioliskraft, MDR 1996, 814 = GRUR 1996, 349; CH-BG v. 19.8.1991, GRUR Int. 1992, 293 = ABl. EPA 1993, 170. Entscheidungen der EPA-Beschwerdekammern werden vorwiegend nach dem ABl. EPA zitiert weil sie dort ggf. dreisprachig veröffentlicht sind, auch wenn die Verfahrenssprache Englisch war. Das ABl. EPA ist auf der Webseite des EPA (EPO), dort unter „Recht & Praxis“ fi „Amtsblatt“ ggf. dort im „Archiv“ erhältlich. 3 Dagegen hat der Anmelder alsdann ein Beschwerderecht zu der zuständigen Beschwerdekammer des EPA, Art. 106 EPÜ.

84

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 219 A

EPÜ die erteilungsfähige Fassung mit und fordert ihn auf, binnen zwei Monaten die Erteilungsgebühr und die Druckkosten einzuzahlen und eine Übersetzung der Ansprüche in die zwei anderen Amtssprachen1 einzureichen. Schlägt der Anmelder weitere Änderungen vor, wird die Prüfung fortgesetzt. Nachdem Einverständnis mit der vorgeschlagenen oder geänderten Fassung hergestellt ist, wird die Europäische Patentschrift nach Art. 98 EPÜ veröffentlicht und hat damit nach Art. 64 EPÜ in den Staaten, in denen sie es validiert worden ist, die gleichen Ausschlusswirkungen wie ein dort erlangtes nationales Patent. Früher musste bei einer Europäischen Patentschrift in Englisch oder Französisch nach Art. 65 EPÜ i.V.m. II § 3 IntPatÜG eine deutsche Übersetzung beim DPMA binnen drei Monaten eingereicht werden, die das DPMA veröffentlicht. Dieses Übersetzungserfordernis ist nach Inkrafttreten des Londoner Sprachenabkommens2 für Deutschland entfallen. bb) Einspruch Mit der Veröffentlichung der Erteilung wird für Dritte eine 9-monatige Ein- 218 spruchsfrist in Gang gesetzt, Art. 99 EPÜ. Der Einspruch ist schriftlich beim EPA einzureichen, substantiiert zu begründen und eine Einspruchsgebühr ist zu bezahlen3. Die Einspruchsgründe sind weitgehend die gleichen4 wie im deutschen Recht und sind erschöpfend gelistet in Art. 100 EPÜ. Über den Einspruch wird dann in einem kontradiktorischen Verfahren mit Beschwerdeinstanz zu den Beschwerdekammern des EPA zentral entschieden. Der Widerruf bedeutet Verlust des Patents für alle benannten EPÜ-Staaten, die Aufrechterhaltung schließt ein späteres nationales Nichtigkeitsverfahren nicht aus. cc) Verletzung Die Offenlegung der Anmeldung führt nach Art. 67 Abs. 2 EPÜ i.V.m. Art. II § 1a IntPatÜG in Deutschland nur zu Entschädigungsansprüchen in Höhe einer angemessenen Lizenz, in anderen Vertragsstaaten durchaus auch zu vollen Schadensersatzansprüchen. Die Veröffentlichung der Erteilung bringt nach Art. 64 EPÜ die vollen nationalen Ausschlusswirkungen, also auch Unterlassungsansprüche und Schadensersatzansprüche nach den drei Berechnungsarten. Durch den Ver1 Die Amtssprachen des EPA sind Deutsch, Englisch und Französisch. Anmeldungen aus anderssprachigen Ländern, z.B. Italien, können auch in der Heimatsprache eingereicht werden, müssen alsdann aber binnen drei Monaten in eine Amtssprache des EPA übersetzt werden. 2 Übereinkommen v. 17.10.2000 über die Anwendung des Art. 65 EPÜ, BGBl. II 2003, 1666 = PMZ 2004, 55. 3 Derzeit nach Art. 2 GebO EPÜ 670 Euro. 4 Es fehlt im EPÜ der Einspruchsgrund der widerrechtlichen Entnahme, da dieser Komplex in Art. 61 EPÜ und dem Anerkennungsprotokoll den nationalen Gerichten zugewiesen ist.

M. Brandi-Dohrn

85

219

A Rz. 220

Grundlagen

weis in Art. 64 EPÜ auf nationales Recht sind die Verletzungshandlungen die in §§ 9, 10 PatG genannten, wobei der Schutz des unmittelbaren Verfahrenserzeugnisses auch in Art. 64 Abs. 2 EPÜ direkt statuiert ist. 220

Der Schutzumfang ist im EPÜ selbst nach Art. 2 Abs. 2, 69 EPÜ geregelt in Verbindung mit dem Auslegungsprotokoll: Artikel 69 – Schutzbereich (1) Der Schutzbereich des europäischen Patents und der europäischen Patentanmeldung wird durch den Inhalt der Patentansprüche bestimmt. Die Beschreibung und die Zeichnungen sind jedoch zur Auslegung der Patentansprüche heranzuziehen. Auslegungsprotokoll. Art. 1: Artikel 69 ist nicht in der Weise auszulegen, dass unter dem Schutzbereich des europäischen Patents der Schutzbereich zu verstehen ist, der sich aus dem genauen Wortlaut der Patentansprüche ergibt, und dass die Beschreibung sowie die Zeichnungen nur zur Behebung etwaiger Unklarheiten in den Patentansprüchen anzuwenden sind. Ebenso wenig ist Artikel 69 dahingehend auszulegen, dass die Patentansprüche lediglich als Richtlinie dienen und der Schutzbereich sich auch auf das erstreckt, was sich dem Fachmann nach Prüfung der Beschreibung und der Zeichnungen als Schutzbegehren des Patentinhabers darstellt. Die Auslegung soll vielmehr zwischen diesen extremen Auffassungen liegen und einen angemessenen Schutz für den Patentinhaber mit ausreichender Rechtssicherheit für Dritte verbinden. EPÜ 20001, Art. 2: Bei der Bestimmung des Schutzbereichs des europäischen Patents ist solchen Elementen gebührend Rechnung zu tragen, die Äquivalente der in den Patentansprüchen genannten Elemente sind.

Diesem Europäischen Schutzumfang ist auch der deutsche in § 14 PatG nachgebildet, wobei auch das Auslegungsprotokoll gilt2. Die einheitliche europäische Schutzumfangsregelung führt derzeit immer noch zu national unterschiedlicher Auslegungspraxis: Zwar wird einheitlich die Maßgeblichkeit des funktional ausgelegten Anspruchswortlauts betont, aber Divergenzen bestehen darüber, ob es über den Wortlaut hinaus einen Äquivalenzschutzbereich gibt3 oder ob Äquivalenz nur fallweise ein Auslegungsgesichtspunkt ist4. Auslegung + Äquivalenz oder nur Auslegung ist der höchstrichterliche europäische Methodenstreit. dd) Nichtigkeit 221

Auch ein europäisches Patent kann national für nichtig erklärt werden, jedoch nur aus den Gründen, die Art. 138, 139 EPÜ zulassen. Das aber sind 1 Die EPÜ-Revision 2000 ist am 13.12.2007 in Kraft getreten. 2 BGH v. 29.4.1986 – X ZR 28/85 – Formstein, MDR 1986, 1023 = GRUR 1986, 803. 3 BGH v. 12.3.2002 – XZR 168/00 – Schneidmesser I, GRUR 2002, 515; BGH v. 12.3.2002 – X ZR 135/01 – Schneidmesser II, GRUR 2002, 519; BGH v. 12.3.2002 – X ZB 12/00 und X ZR 73/01 – Custodiol I und II, GRUR 2002, 523 und 527. 4 House of Lords v. 21.10.2004 – [2004] UKHL 46 – Kirin Amgen ./. TKT, GRUR Int. 2005, 343 entsprechend Mitt. 2005, 82.

86

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 224 A

die gleichen Gründe, die auch in § 21 PatG gelistet sind. Ein europäisch in der Einspruchsbeschwerde aufrecht erhaltenes europäisches Patent kann also, in Extremfällen, wegen des gleichen, schon europäisch berücksichtigten Stands der Technik national vernichtet werden1. Aber natürlich sind die separaten nationalen Nichtigkeitsverfahren wesentlich kostspieliger als das zentrale europäische Einspruchsverfahren. c) Patent Cooperation Treaty (PCT) Der PCT ist ein internationaler Patentanmeldeverband: eine internationale 222 Anmeldung, die in einem zuständigen Verbandsland durch einen Verbandsberechtigten eingereicht ist, gilt als gleichzeitige Anmeldung für die darin bestimmten Staaten, die endgültige Prüfung und Erteilung ist dann aber Sache der Bestimmungsstaaten. Das PCT-Verfahren teilt sich in eine internationale Phase auf mit dem 223 Pflichtprogramm: Anmeldung bei dem zuständigen internationalen Anmeldeamt, internationale Recherche, Veröffentlichung durch WIPO nach 18 Monaten und optional internationaler vorläufiger Prüfungsbericht. Nach 30 Monaten (beim EPA 31 Monate) endet die internationale Phase2 und die Anmeldung wird in den Bestimmungsstaaten in die nationale Phase mit weiteren Gebührenzahlungen und mit endgültiger, territorialer Erteilung oder Versagung überführt, z.B. in eine amerikanische oder japanische Anmeldung. Vor Ablauf der 30 Monate darf kein Bestimmungsstaat die Anmeldung behandeln oder dafür Gebühren verlangen, außer der Anmelder verlangte vorzeitig Übertritt in die nationale Phase. Allerdings sind PCT- und nationale Gebühren zusammen höher. Der Anmelder kauft sich mithin auf dem PCT Weg zusätzliche Zeit. Die nationale Phase kann auch eine regionale sein. Die PCT-Anmeldung 224 kann z.B. in die regionale EPÜ-Erteilung beim EPA (so genannte Euro-PCTAnmeldung) einmünden. Mit der Bestimmung „EP“ kann sich der PCT-Anmelder mit einer Bestimmung und entsprechend nur einer Bestimmungsgebühr alle EPÜ-Länder reservieren. Bei Eintritt in die regionale Phase beim EPA kommt dann die effektive Pauschalbenennung aller EPÜ-Staaten durch die eine Benennungsgebühr. Das auf die PCT-Anmeldung hin erteilte Patent gilt dann nach Nationalisierung (z.B. Übersetzung) für die entsprechenden europäischen Staaten.

1 BGH v. 24.3.1998 – X ZR 57/96 – Regenbecken, GRUR 1998, 895, weil der BGH den gegen den Stand der Technik zu prüfenden Anspruch breiter verstand als die EPA-Beschwerdekammer im vorangegangenen Einspruchsverfahren. 2 Früher nach Art. 20 PCT zweistufig: 20 (21) Monate ohne internationalen Prüfungsantrag, 30 (31) nach frühzeitig gestelltem internationalen Prüfungsantrag.

M. Brandi-Dohrn

87

A Rz. 225

Grundlagen

2. Technischer Charakter a) Ältere BGH-Rechtsprechung 225

In den 60er und 70er Jahren wurde ein Patentschutz für Software überwiegend abgelehnt, denn Patentschutz stehe nur für technische Gegenstände zur Verfügung. Programme seien aber nicht technische Anweisungen an den menschlichen Geist. In seiner damals richtungsweisenden Entscheidung „Dispositionsprogramm“1 definierte der BGH Technizität als Erfordernis der Patentierbarkeit: Als patentierbar anzusehen sei eine Lehre zum planmäßigen Handeln unter Einsatz beherrschbarer Naturkräfte zur Erreichung eines kausal übersehbaren Erfolgs. Zum Einsatz beherrschbarer Naturkräfte gehöre nicht die menschliche Verstandestätigkeit. Das Softwareprogramm stelle nur die menschliche Denktätigkeit nach. Auf welchem Gebiet der Erfolg liege, ob auf ästhetischem oder geschmacklichem2 oder auf technisch industriellem3, sei gleichgültig: die eingesetzten Lösungsmittel müssten technisch sein, nämlich Naturkräfte zu einem kausal übersehbaren Erfolg. Auf dieser Linie blieb der BGH in etwa bis zur Entscheidung „Flugkostenminimierung“4, in der der technische Charakter eines Programms zur fortlaufenden Berechnung von Fluggeschwindigkeit und Spritkosten zur betriebswirtschaftlichen Optimierung eines Flugs abgelehnt wurde: Würden bei einem Verfahren (hier: Verfahren zur Minimierung von Flugkosten) sowohl von Naturkräften abgeleitete Messwerte als auch betriebswirtschaftliche Faktoren rechnerisch in der Weise miteinander verknüpft, dass das Ergebnis der Rechnung einen Steuervorgang auslöst (hier: Änderung des Treibstoffdurchsatzes), so sei das Verfahren dann keine der Patentierung zugängliche technische Lehre, wenn die markt- und betriebswirtschaftlichen Faktoren den entscheidenden Beitrag zur Erreichung des erstrebten Erfolgs liefern und die eingesetzten Naturkräfte demgegenüber an Bedeutung zurücktreten. Der Kern der Lösung (sog. Kerntheorie) müsse auf technischem Gebiet liegen.

1 BGH v. 22.6.1976 – X ZB 23/74 – Dispositionsprogramm, BGHZ 67, 22 = GRUR 1977, 96, im Anschluss an BGH v. 27.3.1969 – X ZB 15/67 – Rote Taube, BGHZ 52, 74 = GRUR 1969, 672. 2 BGH v. 23.11.1965 – X ZB 210/63 – Suppenrezept, GRUR 1966, 249: Beim Kochen werden chemische Vorgänge eingesetzt, so dass das Rezept technisch war, mag auch der Erfolg auf ästhetisch geschmacklichen Gebiet liegen. Das Patent wurde mangels Fortschritt damals versagt. 3 BGH v. 16.9.1980 – X ZB 6/80 – Walzstabteilung, MDR 1981, 137 = GRUR 1981, 39: Ein Programm zur Unterteilung von Walzstäben auf Kühlbettlänge mit möglichst wenig Rest war nicht technisch; BGH v. 21.4.1977 – X ZB 24/74 – Straken, GRUR 1977, 657: Ein Programm zur Berechnung der Linienschar einer komplexen Körperoberfläche (Straken) war nur ein nicht technischer Algorithmus. 4 BGH v. 11.3.1986 – X ZR 65/85 – Flugkostenminimierung, GRUR 1986, 531; ebenso zu § 1 PatG 1981; BGH v. 1.6.1991 – X ZB 24/89 – Chinesische Schriftzeichen, GRUR 1992, 36.

88

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 227 A

b) Europäisches Patentamt Die verbreitete Meinung, dass Computerprogramme als nicht technisch 226 nicht patentfähig seien, fand 1973 ihren Niederschlag in Art. 52 EPÜ: (1) Europäische Patente werden für Erfindungen erteilt, die neu sind, auf einer erfinderischen Tätigkeit beruhen und gewerblich anwendbar sind. (2) Als Erfindungen im Sinn des Absatzes 1 werden insbesondere nicht angesehen: a) Entdeckungen sowie wissenschaftliche Theorien und mathematische Methoden; b) ästhetische Formschöpfungen; c) Pläne, Regeln und Verfahren für gedankliche Tätigkeiten, für Spiele oder für geschäftliche Tätigkeiten sowie Programme für Datenverarbeitungsanlagen; d) die Wiedergabe von Informationen. (3) Absatz 2 steht der Patentfähigkeit der in dieser Vorschrift genannten Gegenstände oder Tätigkeiten nur insoweit entgegen, als sich die europäische Patentanmeldung oder das europäische Patent auf die genannten Gegenstände oder Tätigkeiten als solche bezieht.

In Anlehnung an Art. 27 TRIPS wurden im EPÜ 2000 in Art. 52 (1) EPÜ die Worte „für Erfindungen auf allen Gebieten der Technik erteilt, die …“ eingefügt. Damit fand im Gesetz Niederschlag, was zuvor schon national weitgehende und beim EPA allgemeine Meinung war, dass nämlich patentfähige „Erfindung“ deren technischen Charakter impliziere. Eine weitergehende Vereinheitlichung durch eine Europäische Richtlinie1 ist 2005 gescheitert. Nach einheitlicher Auffassung des EPA liegt ein nicht schutzfähiges Com- 227 puterprogramm als solches vor, wenn es nur abstrakte Daten erzeugt oder ändert; anderes gilt für so genannte funktionelle Daten2. Britischer Auffassung entsprechend muss vielmehr eine Änderung in der physischen Erscheinungswelt oder eine neue Betriebsweise der Hardware hervorgebracht werden. War das aber der Fall, so konnte und kann die eigentliche erfinderi-

1 Vorschlag einer Richtlinie des EU-Parlaments und des Rates über die Patentierbarkeit computerimplementierter Erfindungen v. 20.2.2002, KOM (2002) 92 endgültig, mit Ergänzung in ABl. EG 2002 C 151 S. 129 ff.; http://www. europa.eu.int/ comm/internal_market/en/indprop/comp/com02-92e.pdf; dargestellt und besprochen von Röttinger, CR 2002, 616; kritisch Metzger, CR 2003, 313; Wiebe, CR 2004, 881. 2 EPA v. 15.7.1986 – T 208/84 – computerbezogene Erfindung/VICOM, ABl. EPA 1987, 14/19 = GRUR Int. 1987, 173: Ein Algorithmus zur Verarbeitung großer Datenmengen war, weil er insoweit nur beliebige Daten betraf, nicht schutzfähig, wohl aber der gleiche Algorithmus zur Verarbeitung von Bilddaten. EPA v. 26.4.1991 – T 107/87 – Datenkompressionsverfahren, CR 1993, 26: Ein Verfahren zur Datenkompression ist untechnisch, weil es sich mit abstrakten Daten begnügt. Speicherung unter Kompression ist hingegen technisch.

M. Brandi-Dohrn

89

A Rz. 228

Grundlagen

sche Leistung auch durchaus auf ansonsten ausgeschlossenem Gebiet liegen, z.B. in VICOM in einem mathematischen Algorithmus. 228

Aufgrund von Art. 52 EPÜ differenzierte die Rechtsprechung der EPA-Beschwerdekammern von Anfang an zwischen „technischen“ und damit patentfähigen Programmen und nicht patentfähigen „Computerprogrammen als solchen“. In der EPA-Entscheidung „Zusammenfassen und Wiederauffinden von Dokumenten/IBM“1 wurde ein Programm zum Zusammenfassen, Speichern und Wiederauffinden von Dokumenten als nicht technisch und daher nicht als patentfähig angesehen mit der Begründung: „Das Erfordernis, dass eine Erfindung technischen Charakter aufweisen muss … bildet zumindest in den meisten Vertragsstaaten des EPÜ seit jeher die Grundlage der Rechtspraxis … und wird durch R 27 und 29 EPÜ gestützt. R 29 (1) b) EPÜ schreibt vor, dass der kennzeichnende Teil eines Anspruchs die technischen Merkmale bezeichnen muss …“. Anders als der BGH haben die EPA-Beschwerdekammern aber über Jahrzehnte weg keine Definition dessen gegeben, was als technisch anzusehen sei. Anders als der BGH haben sie auf ein technisches Resultat Wert gelegt, während es für den BGH früher nur die Lösungsmittel sein mussten, die technisch zu sein hatten. Die meisten EPA-Entscheidungen begnügen sich bisher mit der Tautologie, technischer Charakter sei gegeben, wenn eine technische Aufgabe mit technischen Mitteln gelöst werde; zum Teil werden auch „technische Überlegungen“ für ausreichend gehalten2. Am inhaltsreichsten ist die Bemerkung in der Entscheidung „Textverarbeitung/IBM“ dort in Rz. 12 „… zielt das EPÜ wohl darauf ab, eine Patentierung nur in den Fällen zuzulassen, in denen die Erfindung einen Beitrag zum Stand der Technik auf einem vom Patentschutz nicht ausgeschlossenen Gebiete leistet.“3 Die in Art. 52 (2) EPÜ ausgeschlossenen Gegenstände werden als eine Liste von nichttechnischen Beispielen angesehen. Man kann also näherungsweise sagen, dass nach der Entscheidungspraxis des EPA eine Erfindung oder Anspruchsmerkmale technisch und mithin schutzbegründend waren, wenn sie ein physisches Artefakt außerhalb der Gedankenwelt schaffen, ändern oder steuern, und wenn – so die Mehrzahl der Entscheidungen – das Artefakt nicht auf einem der durch Art. 52 (2) EPÜ ausgeschlossenen Gebiete liegt. Erst 2010 1 EPA v. 5.10.1988 – T 22/85 – Zusammenfassen und Wiederauffinden von Dokumenten/IBM, ABl. EPA 1990, 12 = GRUR Int. 1990, 465; Bestätigt durch EPA v. 19.3.1992 – T 854/90 – Kartenleser/IBM, GRUR Int. 1994, 236 – ABl. EPA 1993, 669 und EPA v. 1.7.1998 – T 1173/97 – Computerprogrammprodukt/IBM, ABl. EPA 1999, 609; EPA v. 8.9.2000 – T 931/95 – Pensionssystem/PBS, ABl. EPA 2001, 441. 2 EPA v. 31.5.1994 – T 769/92 – universelles Verwaltungssystem/SOHEI, ABl. 1995, 525/536 = GRUR Int. 1995, 909; EPA v. 9.7.2002, T 1177/97, referiert in der Rechtsprechungsübersicht ABl. Sonderausgabe 2004, 16 – Translating natural languages/SYSTRAN. 3 EPA v. 14.2.1989 – T 38/86 – Textverarbeitung/IBM, ABl. EPA 1990, 384/391 = GRUR Int. 1991, 118; im Prinzip ebenso EPA v. 17.3.2005 – T 531/03 – Discount certificates/CATALINA bei Tz. 2.2 und 2.3.

90

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 230 A

hat die Große Beschwerdekammer (GB) in der Biologie, in Abgrenzung dessen, was nach Art. 53b EPÜ ein nicht patentfähiges „im wesentlichen biologisches Verfahren“ sei, den Begriff der Technik definiert. Sie hat dabei die Definition des BGH aus der Entscheidung „Rote Taube“ aufgegriffen: „Einsatz beherrschbarer Naturkräfte zur Erreichung eines kausal übersehbaren Erfolgs“1. Nicht explizit übernommen hat die Große Beschwerdekammer die beim BGH zugehörige Einschränkung „unter Ausschluss der menschlichen Verstandestätigkeit“. Im Übrigen ist die Reichweite der nicht technischen Ausschlüsse in Art. 52 229 Abs. 2 EPÜ schrittweise eingeschränkt worden. Von Anfang an bis heute besteht Übereinstimmung, dass abstrakte Daten und Algorithmen nicht technisch bzw. Computerprogramme „als solche“ nach Art. 52 Abs. 3 EPÜ sind. Darüber hinaus wurde der sog. Beitragsansatz entwickelt, wonach ein Gegenstand nur dann nach Art. 52 EPÜ technisch war, wenn er eine erfinderische Neuerung auf technischem, also nicht ausgeschlossenem Gebiet brachte2. Die Beschwerdekammern suchten damit, ebenso wie gleichzeitig der BGH, eine Ausgrenzung der bloßen, bestimmungsgemäßen Verwendung von Datenverarbeitungsanlagen3. Der Beitragsansatz wurde in seiner Neuheitsprüfung 1998 definitiv aufgegeben4. Technischer Charakter bei Art. 52 EPÜ sei ein absolutes Erfordernis, während die relativen Erfordernisse der Neuheit und erfinderischen Tätigkeit erst unter Art. 54, 56 EPÜ zu prüfen seien, und diese Prüfungen seien strikt voneinander zu trennen. Technizität begründende Merkmale unter Art. 52 EPÜ könnten also durchaus bekannt sein. Zugleich wurde die Abgrenzung zur bloß bestimmungsgemäßen Verwen- 230 dung eines Computers oder Speichermediums für ein Programm darin gesucht, dass solche üblichen technischen Mittel nicht genügten, sondern das Programm einen sog. weiteren technischen Effekt aufweisen müsse. Dieser könne entweder darin bestehen, dass durch das Programm die Arbeitsweise des Computers geändert werde oder dass eine technische Aufgabe, insbesondere Maschinensteuerung gelöst werde5. Auch dieser Ansatz wurde, beginnend 2000, aufgegeben. Der technische Beitrag sollte nicht besonders qualifiziert sein, was zu der abgelehnten Kerntheorie geführt hätte, sondern 1 EPA GB v. 9.12.2010 – G 2/07 – Broccoli/PLANT BIOSCIENCES, ABl. EPA 2010, 456 = GRUR Int. 2011, 266, dort Abschnitt 6.4.2.1 unter Bezugnahme auf BGH v. 27.3.1969 – X ZB 15/67 – Rote Taube, BGHZ 52, 74 = GRUR 1969, 672. 2 EPA v. 14.2.1989 – T 38/86 – Textverarbeitung/IBM – ABl. EPA 1990, 384 Rz. 12, GRUR Int. 1991, 118. 3 Vgl. EPA v. 12.12.1989 – T 158/88 – Schriftzeichenform/SIEMENS – ABl. EPA 1991, 566. 4 EPA v. 1.7.1998 – T 1173/97 – Computerprogrammprodukt/IBM – ABl. EPA 1999, 609 bei Rz. 8, insoweit gebilligt von EPA GB v. 12.5.2010 – G 3/08 – Computerprogramme – ABl. EPA 2011, 10. 5 EPA v. 1.7.1998 – T 1173/97 – Computerprogrammprodukt/IBM – ABl. EPA 1999, 609 bei Rz. 6.4–6.6.

M. Brandi-Dohrn

91

A Rz. 231

Grundlagen

der Einsatz beliebiger, natürlich auch bekannter technische Mittel sollte bei Art. 52 EPÜ genügen. 231

Dieser nunmehr herrschende Ansatz, der schlagwortartig bisweilen auch als „any technical means“ oder „any hardware“ gekennzeichnet wurde, hat sich in einer Reihe von Entscheidungen herausgebildet1. Dieser Ansatz wurde als Fortentwicklung der Rechtsprechung von der Großen Beschwerdekammer gebilligt2. Danach genügt der bestimmungsgemäße Einsatz von Computern und/oder Speichermedien, seien sie auch bekannt und üblich, um einem Gegenstand technischen Charakter für Art. 52 EPÜ zu verleihen. Die Anwesenheit, auch überwiegende Anwesenheit nichttechnischer Merkmale beseitigt alsdann den einmal hergestellten technischen Charakter nicht. Für den engen Ausschluss nach Art. 52 EPÜ verbleiben damit nur noch abstrakte Algorithmen, Daten und Programme ohne Änderung irgendwelcher physische Größen. Die Eigentliche Ausgrenzung findet bei der relativen Neuheitsprüfung nach Art. 54 EPÜ und Prüfung auf erfinderische Tätigkeit nach Art. 56 EPÜ statt Art. 52 (1) Europäische Patente werden für Erfindungen erteilt, die neu sind, auf einer erfinderischen Tätigkeit beruhen und gewerblich anwendbar sind. Art. 54 (1) Eine Erfindung gilt als neu, wenn sie nicht zum Stand der Technik gehört. (2) Den Stand der Technik bildet alles, was vor dem Anmeldetag der europäischen Patentanmeldung der Öffentlichkeit durch schriftliche oder mündliche Beschreibung, durch Benutzung oder in sonstiger Weise zugänglich gemacht worden ist.

1 EPA 8.9.2000 – T 931/95 – Pensionssystem/PBS, ABl. EPA 2001, 441; EPA v. 9.7.2002 – T 1177/97 – Translating natural languages/SYSTRAN; EPA v. 26.9.2002 – T 641/00 – Zwei Kennungen/COMVIK, ABl. EPA. 2003, 352; und ganz pointiert in EPA v. 21.4.2004 – T 258/03 – Auktionsverfahren/HITASCHI, ABl. 2004, 575 in Tz. 4.6 „Der Kammer ist bewusst, dass ihre vergleichsweise breite Auslegung des Begriffs der „Erfindung“ in Art. 52 (1) EPÜ auch Tätigkeiten einschließt, die so vertraut sind, dass ihr technischer Charakter leicht übersehen wird, wie etwa das Schreiben mit Stift und Papier“; EPA v. 23.2.2006 – T 424/03 – Clipboard formats I/MICROSOFT; EPA v. 15.11.2006 – T 154/04 – Schätzung des Absatzes/DUNS, ABL. EPA 2008, 46. Die EPA-Rechtsprechungslinie erläutert Steinbrenner, „Die Auslegung der Art. 52 (1)-(3) EPÜ in der neueren Rechtsprechung der Beschwerdekammern“, FS Barbenbach (2005), S. 313; Steinbrenner auf dem Symposium Europäischer Patentrichter 2004, ABl. EPA 2005, Sonderheft S. 82 „Patentierbarkeit computerimplementierter Erfindungen“ und in Singer/Stauder, EPÜ-Kommentar (5. Aufl.) Rz. 7 ff. zu Art. 52 EPÜ; Rees, Patentierbarkeit computerimplementierbarer Erfindungen im EPA, ABl. EPA Sonderheft 1, 2011, 93. 2 EPA GB v. 12.5.2010 – G 3/08 – Computerprogramme, ABl. EPA 2011, 10 = GRUR Int. 2010, 608; obiter bestätigt in EPA GB v. 9.12.2010 – G 2/07 – Broccoli/ BIOSCIENCE bei Tz. 6.3.

92

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 232 A

Art. 56 – Erfinderische Tätigkeit Eine Erfindung gilt als auf einer erfinderischen Tätigkeit beruhend, wenn sie sich für den Fachmann nicht in naheliegender Weise aus dem Stand der Technik ergibt.

Bei dieser relativen Prüfung im Vergleich zum Stand der Technik wird ausgeklammert bzw. als bekannt fingiert, was auf einem der in Art. 52 Abs. 2 EPÜ ausgeschlossenen Gebiete liegt, die als Beispiele für nicht technische Gebiete angesehen werden1. Die Große Beschwerdekammer2 hat dafür folgendes Beispiel gebildet: Eine Tasse mit einem neuen Dekor ist ein technischer Gegenstand im Sinne des Art. 52 EPÜ – anders der Beitragsansatz, da die Tasse altbekannt ist und das Dekor keinen Beitrag auf technischem Gebiet leistet –, für die Prüfung auf Neuheit und Erfindungshöhe scheidet aber das Dekor als nur ästhetische Formschöpfung aus, und dann bleibt nur die altbekannte und deshalb nichts schutzfähige Tasse. Das EPA hat also zwei Prüfungshürden: die erste, fast nicht mehr vorhandene, auf technischen Charakter nach Art. 52 EPÜ und sodann die eigentlich auf Neuheit und Erfindungshöhe der technischen Merkmale. Die Schutzunfähigkeitsergebnisse über Erfindungshöhe, Art. 54, 56 EPÜ, sind nicht sonderlich abweichend von denen über patentfähige technische Erfindung nach Art. 52 EPÜ, der Weg dazu, mag er auch patentrechtlich handlicher sein, entspricht aber weniger dem, was der Bürger unbefangen dem Art. 52 EPÜ entnimmt. c) Neuere Rechtsprechung des BGH § 1 Abs. 1, 3 und 4 PatG lauten gleich wie Art. 52 EPÜ. Der BGH ist der Rechtsprechung der EPA-Beschwerdekammer aber nur teilweise und mit zeitlichem Abstand gefolgt. Die vom EPA nie übernommene Kerntheorie hat der BGH in „Steuereinrichtung für Untersuchungsmodalitäten“3 beerdigt, nachdem er sie schon in „Tauchcomputer“4 1992 nicht mehr ange1 EPA v. 26.9.2002 – T 641/00 – Zwei Kennungen/COMVIK, ABl. EPA 2003, 352, Tz. 6; EPA v. 21.4.2004 – T 258/03 – Auktionsverfahren/HITACHI, ABl. EPA 2004, 575; EPA v. 15.11.2006 – T 154/04 – Schätzung des Absatzes/DUNS LICENSING, ABl. EPA 2008, 46 Abschnitt 5 F. 2 EPA GB v. 12.5.2010 – G 3/08 – Computerprogramme, ABl. EPA 2011, 10 = GRUR Int. 2010, 608. 3 BGH v. 20.1.2009 – X ZB 22/07 – Steuereinrichtung für Untersuchungsmodalitäten, GRUR 2009, 479. 4 BGH v. 4.2.1992 – X ZR 43/91 – Tauchcomputer, GRUR 1992, 430 = BGHZ 117, 144 = MDR 1992, 571 = CR 1992, 600 m. Anm. Betten, Eine Computeruhr, die dem Taucher abhängig von den durchtauchten Tiefen die erforderliche Auftauchzeit mit den erforderlichen Dekompressionsstufen anzeigt, wurde im Ganzen als technisch gewertet und zur Ermittlung der Erfindungshöhe an das BPatG mit der Weisung zurückgewiesen, dabei die Lehre als ganzes zu bewerten unter Einschluss der Rechenregel. Eine Computeruhr, die dem Taucher abhängig von den durchtauchten Tiefen die erforderliche Auftauchzeit mit den erforderlichen Dekompressionsstufen anzeigt, wurde im Ganzen als technisch gewertet und

M. Brandi-Dohrn

93

232

A Rz. 233

Grundlagen

wandt hatte. Der BGH hat auch die erste Hürde der Technizität nach § 1 Abs. 1 PatG = Art. 52 Abs. 1 EPÜ wie das EPA abgesenkt und ist dabei dem „any hardware-Ansatz“ gefolgt. Zwar mache der Ablauf auf einem Computer und die Eignung des Programms dazu das Programm noch nicht zu einem technischen Verfahren1. Wie in „Pensionssystem“2 soll aber auch der programmierte Computer als Vorrichtung nach „Sprachanalyseeinrichtung“3 ein technischer und als Vorrichtung patentfähiger Gegenstand sein, denn nach § 1 Abs. 2 Nr. 3 PatG (= Art. 52 Abs. 2 Nr. 3 EPÜ) sind nur Computerprogramme als solche, mithin Verfahren vom Patentschutz ausgeschlossen, nicht aber Vorrichtungen. Auch bei dem Schutz für computerimplementierte Verfahren genüge es, wenn das Verfahren der Speicherung oder Übermittlung von Daten mittels eines technischen Geräts diene4. Dabei reicht es, wenn ein Teilaspekt der Erfindung in dieser Weise auf technischem Gebiet liege (Hürde 1). Der BGH teilt auch die spätere Hürde 2, bzw. 3 beim BGH, der relativen Schutzfähigkeitsprüfung auf Neuheit und Erfindungshöhe, §§ 3, 4 PatG, anhand der technischen Merkmale unter Ausklammerung der in § 1 Abs. 3 PatG ausgeschlossenen Merkmale soweit sie nicht auf die Lösung des technischen Problems mit technischen Mitteln Einfluss nehmen5. 233

Der BGH hat aber eine ganz problematische Zwischenhürde eingefügt, so dass er im Unterschied zum EPA zu drei statt zwei Hürden kommt. Da das Gesetz Computerprogramme als solche vom Patentschutz ausschließe, müsse die beanspruchte Lehre über die für die Patentfähigkeit unabdingbare Technizität hinaus Anweisungen enthalten, die der Lösung eines konkreten

1

2 3

4

5

zur Ermittlung der Erfindungshöhe an das BPatG mit der Weisung zurückgewiesen, dabei die Lehre als ganzes zu bewerten unter Einschluss der Rechenregel. BGH v. 17.10.2001 – X ZB 16/00 – Suche fehlerhafter Zeichenketten, CR 2002, 88 m. Anm. Sedlmaier = GRUR 2002, 143; BGH v. 24.5.2004 – X ZB 20/03 – Elektronischer Zahlungsverkehr, GRUR 2004, 667; BGH v. 19.10.2004 – X ZB 33/03 – Anbieten interaktiver Hilfe, CR 2005, 93 = GRUR 2005, 141; BGH v. 19.10.2004 – X ZB 34/03 – Rentabilitätsermittlung, CR 2005, 95 = GRUR 2005, 143. EPA v. 8.9.2000 – T 931/95 – Pensionssystem/PBS, Abl. EPA 2001, 441. BGH v. 11.5.2000 – X ZB 15/98 – Sprachanalyseeinrichtung, GRUR 2000, 1007 = BGHZ 144, 282 = MDR 2000, 1447 = CR 2000, 500; bestätigt in BGH v. 19.10.2004 – X ZB 33/03 – Anbieten interaktiver Hilfe, CR 2005, 93 = GRUR 2005, 141; BGH v. 19.10.2004 – X ZB 34/03 – Rentabilitätsermittlung, CR 2005, 95 = GRUR 2005, 143. BGH v. 20.1.2009 – X ZB 22/07 – Steuerungseinrichtung für Untersuchungsmodalitäten, GRUR 2009, 479; BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613; BGH v. 26.10.2010 – X ZR 47/07 – Wiedergabe topographischer Information, GRUR 2011, 125; BGH v. 24.2.2011 – X ZR 121/09 – Webseitenanzeige, GRUR 2011, 610. BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613; BGH v. 26.10.2010 – X ZR 47/07 – Wiedergabe topographischer Information, GRUR 2011, 125.

94

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 234 A

technischen Problems mit technischen Mitteln dienen1. Diese Forderung entspricht der aufgegebenen Beschwerdekammer-Rechtsprechung über den „weiteren technischen Effekt.“ Die zusätzliche Hürde beim BGH soll ebenfalls eine niedrige sein, während die eigentliche Prüfung auf dem Gebiet der Neuheit und Erfindungshöhe liege. Immerhin ist die „Webseitenanzeige“2, bei der man nicht nur zurückblättern, sondern auch gezielt mit Hilfe einer Anzeige zurückspringen kann, an dieser Hürde gescheitert. Ob ein konkretes technisches Problem mit technischen Mitteln gelöst wird, ist danach zu bestimmen, was die Erfindung tatsächlich leistet3. Was eine Erfindung leistet, kann man aber nur im Vergleich zum Stand der Technik ermitteln. Das impliziert aber gerade die Neuheitsprüfung, die eigentlich in der dritten Stufe erfolgen sollte, und die das EPA mit der Aufgabe des Beitragsansatzes bei der Technizitätsprüfung verlasse hatte. Demzufolge bleiben in „Webseitenanzeige“ auch einige Merkmale als nicht genügend technisch außer Betracht, weil sie gängig seien. Wenn man, wie der BGH, zwei Technizitätshürden aufbaut und bei der 3. 234 Hürde, der relativen Erfindungsprüfung auf Neuheit und Erfindungshöhe die nichttechnischen Merkmale ausklammert, kommt man naturgemäß zu einem hoch differenzierten Begriff der „Technik“. Dabei ist der BGH in der Grundlage bei seinem alten Begriff von „Technik“ geblieben: Einsatz beherrschbarer Naturkräfte zur Herbeiführung eines kausal übersehbaren Erfolgs4. Er erlaubt aber Abweichungen davon, sofern die technologische Entwicklung und ein daran angepasster Patentschutz bei wertender Betrachtungsweise dies erfordern. Das war der Fall für einen Zwischenschritt in der Herstellung hochintegrierter Chips, deren Millionen von Schaltelementen auf richtige Verbindung zu prüfen waren. Das dazu erforderliche Prüfprogramm wurde vereinfacht durch Zusammenfassung von Bauteilen mit vergleichbarer Funktion. Das sei zwar letztlich eine rationalisierte Denkarbeit, wurde aber als technisch anerkannt, weil es ein notwendiger Schritt in einem technischen Chip-Produktionsprozess war5. Ansprüche zur Lösung von Problemen auf den Gebieten der herkömmlichen Ingenieurwissenschaften, der Physik, der Chemie oder der Biologie mit Hilfe von 1 BGH v. 24.5.2004 – X ZB 20/03 – Elektronischer Zahlungsverkehr, BGHZ 159, 197, GRUR 2004, 667; BGH v. 20.1.2009 – X ZB 22/07 – Steuerungseinrichtung für Untersuchungsmodalitäten, GRUR 2009, 479; BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613; BGH v. 26.10.2010 – X ZR 47/07 – Wiedergabe topographischer Information, GRUR 2011, 125; BGH v. 24.2.2011 – X ZR 121/09 – Webseitenanzeige, GRUR 2011, 610; erläutert von Meier-Beck auf dem Symposium europäischer Patentrichter, Sonderheft EPA 2011, 156. 2 BGH v. 24.2.2011 – X ZR 121/09 – Webseitenanzeige, GRUR 2011, 610. 3 BGH v. 24.2.2011 – X ZR 121/09 – Webseitenanzeige, GRUR 2011, 610, Tz. 22. 4 Wiederholt z.B. in BGH v. 19.10.2004 – X ZB 33/03 – Anbieten interaktiver Hilfe, CR 2005, 93 = GRUR 2005, 141 (142), unter II 4c. 5 BGH v. 13.12.1999 – X ZB 11/98 – Logikverifikation, GRUR 2000, 498 = BGHZ 143, 255 = MDR 2000, 1266 = CR 2000, 281 = CR 2000, 360.

M. Brandi-Dohrn

95

A Rz. 235

Grundlagen

Computerprogrammen sind indiziell technisch, während auf anderen Gebieten es darauf ankommt, ob die Lösung durch technische Überlegungen und deren Umsetzung geprägt ist1. Für die erste Stufe genügt es, wenn irgendwelche künstlichen Mittel (Speichermedien, Computer, any hardware) eingesetzt werden. Für die zweite Stufe, der Lösung eines konkreten technischen Problems mit technischen Mitteln, macht aber der bloße Ablauf auf einem Computer ein Programm noch nicht technisch2, auch nicht das bloße Speichern, übliche Verarbeiten und Übermitteln der Daten; patentfähig wird ein Programm erst, wenn es einen besonderen Aufbau, Funktion oder Gebrauch, etwa grundsätzlich anderer Adressierung des Rechners lehrt3, oder wenn das Programm durch externe „technische“ Gegebenheiten gesteuert oder solchen Gegebenheiten des Computers speziell angepasst ist4. Auf der dritten Stufe sei eben diese Lösung des konkreten technischen Problems auf Neuheit und Erfindungshöhe zu untersuchen. Dabei genügen außerhalb der Technik liegende Anweisungen grundsätzlich nicht, es sei denn sie hätten auf die Lösung des konkreten technischen Problems Einfluss, prägten sie also5. 3. Neuheit und Erfindungshöhe 235

Software muss, um patentiert zu werden, in ihren technischen Merkmalen neu und erfinderisch sein. a) Neuheit

236

Neu ist eine softwarebezogene Erfindung nach § 3 PatG, Art. 54 EPÜ, wenn wenigstens ein technisches Merkmal von jeder Vorveröffentlichung, je einzeln und für sich genommen, abweicht.

1 BGH v. 17.10.2001 – X ZB 16/00 – Suche fehlerhafter Zeichenketten, CR 2002, 88 m. Anm. Sedlmaier = GRUR 2002, 143. 2 BGH v. 17.10.2001 – X ZB 16/00 – Suche fehlerhafter Zeichenketten, CR 2002, 88 m. Anm. Sedlmaier = GRUR 2002, 143; BGH GRUR 2004, 667 – Elektronischer Zahlungsverkehr; BGH v. 19.10.2004 – X ZB 33/03 – Anbieten interaktiver Hilfe, CR 2005, 93 = GRUR 2005, 141; BGH v. 19.10.2004 – X ZB 34/03 – Rentabilitätsermittlung, CR 2005, 95 = GRUR 2005, 143. 3 BGH v. 11.6.1991 – X ZB 13/88 – Seitenpuffer, GRUR 1992, 33 = BGHZ 115, 11 = MDR 1991, 1049 = CR 1991, 658 unter Berufung auf BGH GRUR 1977, 96 = BGHZ 67, 22 – Dispositionsprogramm. 4 BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613; BGH v. 24.2.2011 – X ZR 121/09 – Webseitenanzeige, GRUR 2011, 610. 5 BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613.

96

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 237 A

b) Erfindungshöhe Das größere Problem ist meist die erfinderische Tätigkeit nach § 4 PatG, Art. 56 EPÜ, also ob die beanspruchte Software vom Stand der Technik, auch mosaikartig zusammengesetzt, für einen Softwarefachmann mit seinen Fachkenntnissen nicht nahe lag. Hier haben sich die Beurteilungsmethoden gewandelt. Der BGH wurde früher kritisiert, dass er eine Auftrennung in technische und nicht technische Merkmale vornehme1. Der BGH hat sich in „Tauchcomputer“ zu einer Gesamtbetrachtung bekannt2. Wie gezeigt, nimmt die neuere Rechtsprechung der Beschwerdekammern des EPA eine Scheidung von nicht technischen Gegenständen, insbesondere Geschäftsmethoden, vor und zwar bei der Prüfung der Neuheit und der erfinderischen Tätigkeit nach Art. 56 EPÜ3. Dabei wird der Problem-SolutionAnsatz4 modifiziert. In seiner Grundform enthält er zwei Schritte: (1) Worin bleibt der objektiv nächstliegendste Stand der Technik hinter dem zurück, was die Anmeldung erreicht? = Aufgabe oder Problem. (2) War es für den Fachmann auf Grund gegebener Veranlassung nach dem Stand der Technik naheliegend, diese Aufgabe anmeldegemäß zu lösen? Dieser Ansatz wird für comuterimplementierte Erfindungen modifiziert: (1) Alles, was Geschäftsmethode ist oder sonstiger nach Art. 52 Abs. 2 EPÜ ausgeschlossener Gegenstand (Regeln, mathematische Methoden, gedankliche Tätigkeit, Geschäftsmethoden) wird als vorgegeben angesehen. (2) Worin bleibt der Stand der Technik in den dann noch verbleibenden technischen Aspekten hinter dem zurück, was die Anmeldung technisch erreicht? (3) War die Schließung dieser Lücke für den Computerfachmann naheliegend? Damit werden für die erfinderische Tätigkeit nur diejenigen Merkmale berücksichtigt, die zum technischen Charakter beitragen5. Dem ist der BGH gefolgt6. Die frü1 So z.B. von EPA v. 21.5.1987 – T 26/86 – Röntgeneinrichtung/STERZEL & KOCH, ABl. EPA 1988, 19 = GRUR Int. 1988, 585. 2 BGH v. 4.2.1992 – X ZR 43/91 – Tauchcomputer, MDR 1992, 571 = CR 1992, 600 m. Anm. Betten = GRUR 1992, 430 – LS 3 „Enthält eine Erfindung technische und nicht technische Merkmale, so ist bei deren Prüfung auf erfinderische Tätigkeit der gesamte Erfindungsgegenstand unter Einschluss einer etwaige Rechenregel zu berücksichtigen.“ 3 EPA v. 9.7.2002 – T 1177/97 – Translating natural languages/SYSTRAN; EPA v. 26.9.2002 – T 641/00 – Zwei Kennungen/COMVIK, ABl. EPA. 2003, 352; EPA v. 21.4.2004, T 258/03 – Auktionsverfahren/HITACHI, ABl. 2004, 575; gebilligt von EPA GB v. 12.5.2010 – G 3/08 – Computerprogramme, ABl. 2011, 10. 4 EPA T 24/81, ABl. 1983, 133 = GRUR Int. 1983, 650 – Metallveredelung/BASF. 5 EPA v. 21.4.2004 -T 258/03 – Auktionsverfahren/HITACHI, ABl. 2004, 575; Bezug nehmend auf EPA T 641/00, ABl. 2003, 352 – Zwei Kennzeichnungen/COMVIK; EPA v. 17.3.2005, T 531/03, Tz. 3.5 – Discount Certificates/CATALINA. 6 BGH v. 24.5.2004 – X ZB 20/03 – Elektronischer Zahlungsverkehr, BGHZ 159, 197, GRUR 2004, 667; BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613; BGH v. 26.10.2010 – X ZR 47/07 – Wiedergabe topographischer Information, GRUR 2011, 125; BGH v. 18.12.2012 – X ZR 3/12 – Routenplanung, GRUR 2013, 275.

M. Brandi-Dohrn

97

237

A Rz. 238

Grundlagen

her geforderte Gesamtbewertung aller Merkmale, auch der nicht technischen, findet sich noch insoweit als die nicht technischen mitgewertet werden, wenn sie von Einfluss auf die technische Lösung des „konkreten technischen Problems“ sind. Dabei ist es auch bedeutsam, ob die technischen oder die untechnischen Merkmale die Erfindung „prägen“1. Die Auftrennung oder Wertung, was insgesamt prägend ist, erscheint sachlich notwendig, entweder bei der Patentfähigkeit oder bei der Erfindungshöhe, weil man sonst zu Patenten für ästhetische oder geschäftliche Leistungen kommen würde. Das Gesetz schreibt in Art. 52 EPÜ und in § 1 PatG die Berücksichtigung schon bei der Patentfähigkeit vor. Daher würde die deutsche BGH-Rechtsprechung den Vorzug vor der europäischen der Beschwerdekammern verdienen, diese ist aber in sich folgerichtiger, einfacher und dominiert inzwischen2. Kritik sowohl am BGH wie auch am EPA wegen zu weitgehender Patentierungspraxis wird in einer interfraktionellen Entschließung des deutschen Bundestags vom 16.4./7.6.2013 geübt3. Programmschutz nur für Äquivalente zu mechanischen oder elektromechanischen Komponenten. c) Zwischenergebnis 238

EPA und BGH bejahen zwar das Erfordernis des technischen Charakters für die Patentfähigkeit nach Art. 52 Abs. 1 EPÜ = § 1 Abs. 1 PatG, haben aber diese erste technische Hürde auf praktisch Null reduziert, da „any hardware“ zur Ausführung eines Verfahrens oder bei einem Produktanspruch genügt. Beide stimmen darin überein, dass die wesentliche Prüfung bei Neuheit und Erfindungshöhe stattfindet, und dass dabei nur die technischen Merkmale, regelmäßig also die nicht in der Liste von Art. 52 Abs. 2 EPÜ = § 1 Abs. 3 PatG ausgeschlossenen zählen. Beide erlauben auch im Sinne einer Gesamtbetrachtung die Berücksichtigung für sich ausgeschlossener Merkmale, wenn sie zur technischen Lösung beitragen. Anders als das EPA fordert der BGH noch die Zwischenhürde der Lösung eines konkreten technischen Problems mit technischen Mitteln, und nur diese zählen alsdann bei der Neuheits- und Erfindungsprüfung. Diese Zwischenhürde entspricht dem früheren „weiteren technischen Zweck“ in der EPA-Rechtsprechung.

1 BGH v. 22.4.2010 – Xa ZB 20/08 – Dynamische Dokumentengenerierung, GRUR 2010, 613 Tz. 24. 2 Gegen den BGH und für den EPA-Beitragsansatz: Wiebe/Heidinger, GRUR 2006, 177. 3 Interfraktioneller Antrag v. 16.4.2013 – BT-Ds. 17/13086, Bericht Weiden, GRUR 2013, 699; dazu Ensthaler, GRUR 2013, 666: nur zweckgebundener Programmschutz.

98

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 242 A

4. Ausland, insbesondere USA Die englischen Gerichte lehnen den „any hardware-Ansatz“ in ständiger 239 Rechtsprechung ab. Nach Sec. 1 (2) Patents Act 1977, der inhaltlich dem Art. 52 (2) EPÜ entspricht, müsse für die Patentfähigkeit nach Art. 52 EPÜ zunächst untersucht werden, ob sich die erfinderische Tätigkeit allein auf den ausgeschlossenen Gegenstand, z.B. die Geschäftsmethode, gründet; dann ist die Anmeldung nicht patentfähig, auch nicht wenn sie im Gewand einer Diskette oder sonstigen Computerprogrammprodukts daher kommt. Schon für die grundlegende Patentfähigkeit muss daher untersucht werden, ob die nicht ausgeschlossenen Merkmale bereits bekannt oder naheliegend sind. Sind sie das, so liegt keine patentfähige Erfindung vor. Dazu sind in Aerotel und Macrossan1 folgende Testfragen aufgestellt worden: (1) Ordentliche Auslegung des Patentanspruchs, (2) Identifizierung des tatsächlichen Beitrags, (3) fage, ob er nur zu einem ausgeschlossenen Gegenstand gehört, (4) prüfe ob der tatsächliche Beitrag wirklich technischer Natur ist. In Frankreich knüpft man an die gewerbliche Anwendbarkeit an und es 240 herrschte unter dem alten Recht vor 1978 eine extrem restriktive Beurteilung: Computerprogramme sind ohne Rücksicht auf ihren Zweck oder ihr Ergebnis als nicht gewerbliche Erfindungen anzusehen2. Später wurde aber Computerprogrammen im Rahmen eines Bohrverfahrens gewerbliche Anwendbarkeit und Schutzfähigkeit zuerkannt3. In den Niederlanden nahm die Beschwerdekammer des niederländischen 241 Patentamts den Standpunkt ein, ein Verfahren zur Verarbeitung von Information durch einen Computer sei grundsätzlich patentfähig4. Auf technischen Charakter kam es daher im Ergebnis nicht an. Schon die Verarbeitung im Computer lieferte den technischen Charakter. In USA gibt es keinen Katalog ausgeschlossener Gegenstände wie in Art. 52 242 (2) EPÜ. Das US-Patentgesetz bestimmt vielmehr in 35 USC § 101 „Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent thereof, subject to the conditions and requirements of this title.“

Daraus hat der US Supreme Court abgeleitet, der Kongress habe gewollt, dass „alles unter der Sonne, was von Menschenhand gemacht worden ist“ patentfähig sein solle5. Auf diesem Hintergrund hat der Court of Appeals

1 Court of Appeal of 27.10.2006 – [2006] EWCA Civ. 1371 – Aerotel v. Telco and Macrossan’s Application, Mitt. 2007, 19. 2 Cour de Paris GRUR Int. 1974, 279 – Pigmentauswahl. 3 Cour de Paris PIBD 1982 III 7 – Schlumberger; auch berichtet von Jonquieres, GRUR Int. 1987, 465. 4 Beschwerdekammer Octrooiraad Niederlande v. 12.9.1985 – Nr. 15495/Art. 24 A (Patentanmeldung Nr. 7612743), CR 1986, 541 und Beschwerdekammer v. 11.5.1987 – Nr. 7803679, CR 1988, 29 – Dekodieren eines Strichcodes. 5 US Supreme Court v. 3.3.1981 – Diamond v. Diehr, GRUR Int. 1981, 646 (648).

M. Brandi-Dohrn

99

A Rz. 243

Grundlagen

for the Federal Circuit (CAFC)1 entschieden, dass zwar abstrakte Ideen und mathematische Methoden nicht patentfähig sind, wohl aber Geschäftsmethoden, „wenn sie zu einem nützlichen, konkreten und greifbaren Ergebnis führen“ wie z.B. ein zentrales System der Verwaltung mehrerer Fonds, bei denen ein Computerprogramm die schnelle Bewertungsinformation für die einzelnen Fonds besorgt. Im Fall Bilski gab der CAFC den State Street Test auf und schränkte ein: ein Verfahren könne dann patentfähig sein, wenn es (1) an eine besondere Maschine oder Vorrichtung geknüpft ist, oder (2) einen bestimmten Gegenstand in eine andere Sache oder Zustand versetzt, (machine or transformation test). Dieser Test sei zwingend und exklusiv. Der Supreme Court korrigierte. Nach dem weiten Gesetzeswortlaut von § 101 seien nur Naturgesetze, physikalische Phänomene und abstrakte Ideen nicht patentfähig. Als positiver Test, dass im Zweifel nicht bloß eine abstrakte Idee vorliege, sei der machine or transformation Test nützlich, nicht aber als abschließendes Kriterium. Die Mehrheit befand auch, dass Geschäftsmethoden nicht von vornherein, kategorisch von der Patentfähigkeit ausgeschlossen seien. Alle Richter und beide Gerichte stimmten aber im Ergebnis überein, dass Bilskis Geschäftsmethode des Hedging als abstrakte Idee nicht patentfähig sei2. In der Frage, ob Geschäftsmethoden patentfähig sind, wenn sie mit einem Computerprogramm abgewickelt werden, besteht immer noch ein deutlicher Unterschied zwischen USA und der älteren, insbesondere von Deutschland, Frankreich und Großbritannien vertretenen europäischen Auffassung. 5. Fazit 243

Konsens besteht weltweit, dass abstrakte Algorithmen und Gedankentätigkeit nicht patentschutzfähig sind. Dissens besteht zwischen einer herrschenden europäischen Auffassung und USA hinsichtlich der Patentfähigkeit von Geschäftsmethoden – Europa: nein, USA: nicht ausgeschlossen, aber erschwert. Überwiegender Konsens besteht in Europa, dass eine Erfindung technischen Charakter haben muss, um patentfähig zu sein. Verwirrung herrscht darüber, was „technischer Charakter“ ist und wie er methodisch zu prüfen ist. In Deutschland und Großbritannien besteht im Gegensatz zum EPA Konsens, dass die bestimmungsgemäße Nutzung eines Computers ein Verfahren, insbesondere ein Programm noch nicht technisch und patentfähig macht. Ebenso besteht Uneinigkeit darüber, ob ein mit nicht technischer Software, z.B. einem Text- oder Geschäftsprogramm programmierter Computer als technisch patentfähig ist.

1 CAFC v. 23.7.1998 – State Street Banc v. Signature – Finanzdienstleistungssystem, GRUR Int. 1999, 633 = CRI 2000, 19. 2 US Supreme Court v. 28.6.2010 – 08-964 – Re Bilski, Mitt. 2010, 430, erläutert von judge Rader (CAFC) in ABl. EPA Sonderheft 2011, 103.

100

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 248 A

Das EPA und der BGH in seiner ersten Hürde stellen in ihrer neueren 244 Rechtsprechung in der Eingangsprüfung auf Patentfähigkeit nach Art. 52 EPÜ praktisch keine Anforderungen mehr an Technizität. Wohl aber stellt der BGH in seiner zweiten Hürde, technische Lösung eines besonderen technischen Problems, Anforderungen an die Technizität, die dem „weiteren technischen Effekt“ der früheren EPA-Rechtsprechung entsprechen. Die hauptsächliche Prüfung auf Technizität verlagern EPA und BGH zur Erfindungshöhe nach Art. 56 EPÜ, § 4 PatG. Dort zählen nur noch die Merkmale, die einen technischen Beitrag leisten oder die Lösung des technischen Problems beeinflussen. Der BGH unterscheidet in der Eingangsprüfung nach § 1 (1) PatG zwischen 245 technischem Charakter (erste, niedrige Hürde) und in der zweiten Hürde der technischen Lösung eines besonderen technischen Problems, mit dem ausgeschlossenen Gegenstände als solche eliminiert werden – § 1 (3) (4) PatG. Technik als Einsatz beherrschbarer Naturkräfte ist als Richtschnur beibehalten, aber eine wertend flexible Beurteilung ist eröffnet. Die Abgrenzung, insbesondere bei gemischten Gegenständen, zwischen ei- 246 ner Prüfung auf Patentfähigkeit nach Art. 52 EPÜ von einer auf Erfindungshöhe nach Art. 56 EPÜ ist schwierig. Umgeht man diese Schwierigkeiten, wie es das EPA und der BGH tun, indem sie die hauptsächliche Prüfung in die erfinderische Tätigkeit nach Art. 56 EPÜ hin verlagern, so wird man dem Gesetz, Art. 52 EPÜ, nicht gerecht und eine Gesamtbetrachtung, bei der auch die nichttechnischen Merkmale zählen, wird zumindest stark eingeschränkt.

III. Wettbewerbsrecht Der Schutz für Arbeitsergebnisse der Software-Entwicklung, insbesondere 247 auch der Schutz von Computerprogrammen durch das Wettbewerbsrecht basiert im Wesentlichen auf zwei Säulen: Zum einen gewährt das Gesetz dem Hersteller gem. §§ 3, 4 Nr. 9 UWG sog. ergänzenden wettbewerbsrechtlichen Leistungsschutz vor unlauterer Nachahmung (nachfolgend Ziff. 1). Zum anderen sehen die Straftatbestände der §§ 17 bis 19 UWG einen weitgehenden Schutz von Unternehmensgeheimnissen vor (nachfolgend Ziff. 2). 1. Ergänzender wettbewerbsrechtlicher Leistungsschutz vor Nachahmung a) Allgemeines aa) Schutz vor unlauterer Nachahmung Der ergänzende wettbewerbsrechtliche Leistungsschutz wird gegen die un- 248 lautere Verwertung der Nachahmung eines Leistungsergebnisses gewährt. Hierbei unterscheidet man die Fallgestaltungen der unmittelbaren LeisKarger

101

A Rz. 249

Grundlagen

tungsübernahme, die auch die identische oder fast identische Nachbildung einschließt, und der nachschaffenden Übernahme, bei der das Leistungsergebnis als Vorlage für die Nachbildung verwendet wird. 249

Nachahmungen sind durch das Wettbewerbsrecht grundsätzlich gestattet. Außerhalb der gesetzlichen Sonderrechtsschutzregelungen gilt für geistige Leistungen der Grundsatz der Nachahmungsfreiheit1. Das bloße Nachahmen eines nicht unter Sonderrechtsschutz stehenden Leistungsergebnisses ist daher nicht von vornherein, sondern nur unter bestimmten Umständen unlauter und wettbewerbsrechtlich unzulässig2. Liegt ein Wettbewerbsverstoß vor, so kann der Anspruchsberechtigte u.a. Unterlassung bzw. Beseitigung, bei Verschulden auch Schadensersatz verlangen. Software ist allgemein als grundsätzlich schützenswerter wettbewerblicher Besitzstand anerkannt3, so dass der ergänzende Leistungsschutz auch im Rahmen der Software-Erstellung Relevanz hat4. bb) Gesetzliche Regelung

250

Vor der UWG-Novelle im Jahre 2004 war der ergänzende wettbewerbsrechtliche Leistungsschutz eine Fallgruppe im Rahmen der Generalklausel des § 1 UWG a.F. Das UWG regelt den ergänzenden Leistungsschutz nunmehr ausdrücklich in § 3 UWG i.V.m. § 4 Nr. 9 UWG. Durch die Novelle hat sich jedoch bis auf einige Akzentverschiebungen nichts Grundlegendes geändert5. Dies gilt auch für das Problem der Abgrenzung zu den Sonderschutzrechten6.

251

Ausgangspunkt ist die Generalklausel des § 3 UWG. Nach § 3 UWG sind unlautere Wettbewerbshandlungen unzulässig, die geeignet sind, dem Wettbewerb zum Nachteil der Mitbewerber, der Verbraucher oder der sonstigen Marktteilnehmer nicht unerheblich zu beeinträchtigen.

252

§ 4 Nr. 9 UWG definiert die wichtigsten Fälle der Unlauterkeit im Zusammenhang mit der Nachahmung von Leistungsergebnissen: Danach handelt insbesondere unlauter, wer Waren oder Dienstleistungen anbietet, die eine Nachahmung von Waren oder Dienstleistungen eines Mitbewerbers sind, wenn er – eine vermeidbare Täuschung der Abnehmer über die betriebliche Herkunft herbeiführt, oder 1 Köhler/Bornkamm, 31. Aufl. 2013 § 4 UWG Rz. 9.3. 2 Vgl. Köhler/Bornkamm, § 4 UWG Rz. 9.3. 3 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 6; Harte-Bavendamm, in: Kilian/Heussen, Computerrechtshandbuch, 57 Rz. 10. 4 S. allgemein zum Rechtsschutz für Software durch das UWG: Jersch, Ergänzender Leistungsschutz und Computersoftware (1993) und Wiebe, Know-howSchutz von Computersoftware (1993). 5 Henning-Bodewig, GRUR 2004, 713 (717). 6 Henning-Bodewig, GRUR 2004, 713 (717).

102

Karger

Schutz und Realisierung der Software

Rz. 256 A

– die Wertschätzung der nachgeahmten Ware oder Dienstleistung unangemessen ausnutzt oder beeinträchtigt, oder – die für die Nachahmung erforderlichen Kenntnisse oder Unterlagen unredlich erlangt hat. Die Aufzählung in § 4 Nr. 9 UWG erfasst nur Beispielstatbestände und ist 253 nicht abschließend; Daher kann auch der allgemeine Grundsatz der Mitbewerberbehinderung zur Beurteilung der Unlauterkeit einer Produktnachahmung herangezogen werden1. cc) Verhältnis zu anderen Fallgruppen unlauterer Wettbewerbshandlungen Neben dem ergänzenden Leistungsschutz gem. § 3 UWG i.V.m. § 4 Nr. 9 254 UWG kommen im Kontext der Software-Erstellung auch noch andere Tatbestände in Betracht. Soweit es hierbei um illegale Nachahmung oder Übernahme bzw. um Raubkopien geht, ist auch an die gezielte Behinderung von Mitbewerbern gem. § 3 UWG i.V.m. § 4 Nr. 10 UWG sowie an den Rechtsbruch gem. § 3 UWG i.V.m. § 4 Nr. 11 UWG zu denken. Ein und dasselbe Marktverhalten kann auch mehrere der in § 4 UWG genannten Beispielsfälle erfüllen; diese schließen sich gegenseitig nicht aus2. dd) Verhältnis zum Sonderrechtsschutz Rechtsprechung und die wohl noch h.M. gehen traditionell davon aus, dass 255 der Urheberrechtsschutz aufgrund seiner Spezialität dem wettbewerbsrechtlichen Schutz nach dem UWG vorgeht. Nach der sog. Vorrangthese wird ein ergänzender wettbewerbsrechtlicher Leistungsschutz nicht gewährt, wenn bereits ein Sonderrechtsschutz – insbesondere nach dem Urheberrecht oder dem Patentrecht – besteht, da insoweit kein Bedürfnis für einen ergänzenden Schutz vorliege3. Dieser Ansatz ist im Schrifttum auf Kritik gestoßen4. Sowohl im urheberrechtlichen als auch im wettbewerbsrechtlichen Schrifttum wird zunehmend dafür plädiert, das Vorrangprinzip jedenfalls für bestimmte Fälle (Vorsprung durch Rechtsbruch) einzuschränken5 oder das Vorrangprinzip ganz grundsätzlich durch das Gleichrangprinzip zu ersetzen6. Der ergänzende Leistungsschutz kann jedenfalls dann eingreifen, wenn be- 256 sondere, außerhalb der Sonderschutztatbestände liegende Umstände vorliegen, die das Verhalten als unlauter erscheinen lassen7. Erfüllt etwa eine 1 Köhler/Bornkamm, § 4 UWG Rz. 9.4a. 2 Köhler/Bornkamm, § 4 UWG Rz. 04. 3 S. hierzu Schricker/Loewenheim, Urheberrecht, Einleitung Rz. 53; Köhler/Bornkamm, § 4 UWG Rz. 9.6. 4 S. insbesondere Köhler, GRUR 2007, 548. 5 Schricker/Loewenheim, Urheberrecht, Einleitung Rz. 53. 6 Köhler, GRUR 2007, 548 (550 ff.). 7 BGH GRUR 2002, 629 (631) – Blendsegel; BGH v. 10.12.1998 – I ZR 100/96 – Elektronische Pressearchive, CR 1999, 213 m. Anm. Lütje = GRUR 1999, 325 (326).

Karger

103

A Rz. 257

Grundlagen

Handlung nicht den Tatbestand einer Urheberrechtsverletzung, ist sie also urheberrechtlich unbedenklich, ist die Anwendung von §§ 3, 4 Nr. 9 oder Nr. 10 UWG nicht ausgeschlossen, wenn außerhalb der Sondertatbestände des Urheberrechts liegende Umstände hinzutreten, um die Unlauterkeit zu begründen1. 257

Der urheberrechtliche Schutz von Computerprogrammen per se verdrängt einen etwaigen wettbewerbsrechtlichen Schutz nicht. Dies ergibt sich aus der ausdrücklichen Regelung des § 69g Abs. 1 UrhG. Nach dem sog. Kumulationsprinzip im gewerblichen Rechtsschutz gelten die Schutzsysteme des Urheberrechts, des Patentrechts und des Wettbewerbsrechts grundsätzlich nebeneinander, überlagern und ergänzen sich2. Die Abgrenzung zwischen dem Sonderrechtsschutz und dem ergänzenden wettbewerbsrechtlichen Leistungsschutz ist deshalb nicht immer einfach zu treffen3. ee) Unterschiede zum Schutz durch das Urheberrecht

258

Urheberrechtlicher Schutz und ergänzender wettbewerbsrechtlicher Leistungsschutz weisen erhebliche Unterschiede zueinander auf: Zum einen schützt das Urheberrecht das Arbeitsergebnis als solches, während das Wettbewerbsrecht einen Schutz gegen die Art und Weise der Ausnutzung fremder Arbeitsergebnisse bietet4. Damit schützt das Wettbewerbsrecht die Software nur mittelbar, indem es unlautere Wettbewerbshandlungen sanktioniert5. Das Urheberrecht gewährt einen absoluten Ausschließlichkeitsschutz gegenüber jedermann. Der wettbewerbsrechtliche Schutz wirkt dagegen nur relativ: Die Leistung wird gegen eine unlautere Nutzung im geschäftlichen Verkehr zu Zwecken des Wettbewerbs geschützt6. Ein Ausschließlichkeitsrecht an Leistungsergebnissen wird damit nicht begründet7. Der Schutz des Wettbewerbsrechts bleibt hinter dem urheberrechtlichen Schutz auch insoweit zurück, als er die Handlungen Privater zu persönlichen Zwecken nicht erfasst8. Im Gegensatz zum Urheberrecht ist die Schutzdauer für den wettbewerbsrechtlichen Schutz nicht gesetzlich festgelegt. Sie ist in der Regel wesentlich kürzer als im Urheberrecht9. 1 BGH v. 17.7.2003 – I ZR 259/00 – Paperboy, CR 2003, 920 = MDR 2004, 346 = GRUR 2003, 958 (962); Köhler/Bornkamm, § 4 UWG Rz. 9.7. 2 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 1. 3 Hierzu Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 1. 4 Junker/Benecke, Computerrecht, Rz. 109. 5 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 7; Junker/Benecke, Computerrecht, Rz. 111. 6 Vgl. Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 7. 7 Köhler/Bornkamm, § 4 UWG Rz. 9.4. 8 Redeker, IT-Recht, Rz. 178; Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 8. 9 Junker/Benecke, Computerrecht, Rz. 91; Redeker, IT-Recht, Rz. 184.

104

Karger

Schutz und Realisierung der Software

Rz. 261 A

ff) Praxisrelevanz des ergänzenden wettbewerbsrechtlichen Leistungsschutzes Vor dem Inkrafttreten des sondergesetzlichen Schutzes für Computerpro- 259 gramme gem. §§ 69a ff. UrhG bzw. gem. §§ 87a ff. UrhG für Datenbanken bereitete der Nachweis der Schutzfähigkeit entsprechender Arbeitsergebnisse aufgrund der durch die Rechtsprechung gestellten strengen Anforderungen große Probleme. Vor diesem Hintergrund wurde dem ergänzenden wettbewerbsrechtlichen Leistungsschutz von Software eine vergleichsweise große Bedeutung zugemessen1. Seitdem das Urheberrecht im Hinblick auf Computerprogramme mit den 260 §§ 69a ff. UrhG auch die „kleine Münze“ schützt und auch der Datenbankschutz gesetzlich normiert ist, kann der Rechtsinhaber den Nachweis der Schutzfähigkeit wesentlich leichter führen, so dass aus diesem Grunde nunmehr nicht mehr auf das Wettbewerbsrecht zurückgegriffen werden muss. Angesichts des relativ umfangreichen Schutzes von Software durch das Urheberrecht hat die praktische Bedeutung des wettbewerbsrechtlichen Leistungsschutzes für Software zwischenzeitlich deutlich abgenommen2. Sofern sich aber die im Vordringen befindliche Auffassung durchsetzen sollte, wonach der urheberrechtliche Sonderrechtsschutz dem wettbewerbsrechtlichen Schutz nicht vorgeht und diesen verdrängt, sondern beide Schutzsysteme gleichrangig nebeneinander stehen3, dürfte dem wettbewerbsrechtlichen Schutz von Software künftig wieder mehr Praxisrelevanz zuwachsen. Ohnehin ist der wettbewerbsrechtliche Schutz von Software bzw. sonstigen 261 Arbeitsergebnissen im Rahmen der Software-Erstellung nicht völlig obsolet. So kann der ergänzende wettbewerbsrechtliche Schutz von Software und sonstigen Arbeitsergebnissen insbesondere dann relevant werden, wenn das Urheberrecht Schutzlücken offen lässt4. Entsprechende Lücken können gegeben sein, wenn die Schutzvoraussetzungen nach dem Urheberrecht nicht vorliegen, z.B. das Computerprogramm die Anforderungen des § 69a Abs. 3 UrhG nicht erfüllt oder weil Ausnahmeregelungen (z.B. §§ 69d und 69e UrhG) eingreifen5. Bei Arbeitsergebnissen, die nicht unter den Begriff des Computerprogramms i.S.v. § 69a UrhG fallen, sind die Anforderungen an die erforderliche Individualität und Gestaltungshöhe wesentlich höher, so dass hier u.U. ein ergänzender Leistungsschutz über das Wettbewerbsrecht leichter zu erreichen ist. Dies gilt z.B. für Benutzeroberflächen, bei denen

1 Vgl. hierzu Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 1 ff.; Redeker, IT-Recht, Rz. 178. 2 Redeker, IT-Recht, Rz. 178. 3 Köhler, GRUR 2007, 548 (550 ff.). 4 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 22; Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 1. 5 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 22.

Karger

105

A Rz. 262

Grundlagen

die urheberrechtliche Schutzfähigkeit stark umstritten ist1 oder für die Gestaltung von Websites und Multimediawerken2. 262

Den wettbewerbsrechtlichen Bestimmungen kommt für Software-Ersteller eine Doppelfunktion zu: Sie schützen zum einen die erzielten Arbeitsergebnisse vor unlauterer Nachahmung und Verwertung. Umgekehrt setzen sie dem Software-Ersteller in gleicher Weise Grenzen bei der Beschaffung und Verwendung von Arbeitsergebnissen Dritter. b) Voraussetzungen des ergänzenden wettbewerbsrechtlichen Leistungsschutzes

263

Der ergänzende wettbewerbsrechtliche Leistungsschutz setzt voraus, dass3 – eine Wettbewerbshandlung mit Mitbewerberbezug vorliegt, indem ein Unternehmer eine Ware oder Dienstleistung eines Mitwerbers nachahmt und auf dem Markt anbietet, – die nachgeahmte Ware oder Dienstleistung wettbewerbliche Eigenart aufweist, sowie – besondere Umstände vorliegen, die dieses Verhalten des Nachahmers als unlauter erscheinen lassen. Die unlautere Nachahmung muss des Weiteren geeignet sein, den Wettbewerb zum Nachteil insbesondere des betroffenen Mitbewerbers nicht nur unerheblich zu beeinträchtigen. aa) Wechselwirkung zwischen den einzelnen Kriterien

264

Zwischen der Art und Weise und der Intensität der Übernahme, dem Grad der wettbewerblichen Eigenart des nachgeahmten Leistungsergebnisses sowie den die Unlauterkeit des Verhaltens begründenden besonderen wettbewerblichen Umständen besteht eine Wechselwirkung. Dies bedeutet, dass die Anforderungen an eines der Merkmale davon abhängen, in welchem Maß die beiden anderen Merkmale verwirklicht sind4: Je größer die wettbewerbliche Eigenart und je höher der Grad der Übernahme ist, desto geringer sind die Anforderungen an die besonderen Umstände, die die Wettbewerbswidrigkeit begründen.

1 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 25; zum wettbewerbsrechtlichen Schutz von Bildschirmmasken s. auch OLG Karlsruhe v. 14.4.2010 – 6 U 46/09, MMR 2010, 622 und LG Frankfurt a.M. v. 21.8.2006 – 2-06 O 272/06, ZUM-RD 2006, 530. 2 S. hierzu etwa Heutz, MMR 2005, 567. 3 S. Köhler/Bornkamm, § 4 UWG Rz. 9.17. 4 Köhler/Bornkamm, § 4 UWG Rz. 9.69.

106

Karger

Schutz und Realisierung der Software

Rz. 269 A

bb) Wettbewerbshandlung mit Mitbewerberbezug (1) Wettbewerbshandlung Voraussetzung für den ergänzenden wettbewerbsrechtlichen Leistungsschutz ist zunächst das Vorliegen einer Wettbewerbshandlung i.S.v. § 2 Abs. 1 Nr. 1 UWG.

265

Wettbewerbshandlung ist jede Handlung einer Person mit dem Ziel, zugunsten des eigenen oder eines fremden Unternehmens den Absatz oder den Bezug von Waren oder die Erbringung oder den Bezug von Dienstleistungen zu fördern. Im Rahmen des ergänzenden Leistungsschutzes gem. § 3 UWG i.V.m. ei- 266 nem der Beispielsfälle von § 4 Nr. 9 UWG ist als maßgebliche Wettbewerbshandlung das „Anbieten“ eines Nachahmungsproduktes vordefiniert. Das Angebot von Nachahmungsprodukten muss zur Förderung des Absatzes zugunsten des eigenen oder eines fremden Unternehmens erfolgen1. Dies ist beim Handeln eines Unternehmens stets zu bejahen2. Demgegenüber erfüllt das bloße Herstellen den Tatbestand noch nicht3. 267 Das Herstellen ist notwendige Vorbereitungshandlung für das unlautere Anbieten. Es begründet die Gefahr eines unlauteren Anbietens, so dass ein vorbeugender Unterlassungsanspruch besteht, der aber nur auf die Unterlassung des Anbietens und nicht auch des Herstellens gerichtet ist4. Diese Regelung ist für den Hersteller des Originals unbefriedigend, weil er nicht bereits gegen die Herstellung vorgehen kann; der Gesetzeswortlaut des § 4 Nr. 9 UWG ist aber diesbezüglich eindeutig5. Sofern bei einer unmittelbaren Leistungsübernahme keiner der in § 4 Nr. 9 UWG erwähnten Beispielsfälle einschlägig ist, kann der Tatbestand des § 3 UWG erfüllt sein6. In diesem Fall ist auch die Vervielfältigung der Software selbst als relevante Wettbewerbshandlung in Betracht zu ziehen7, zumal § 3 UWG nicht konkret auf das „Anbieten“ abstellt.

268

Werden im Rahmen der Erstellung eines Plagiats technische Schutzmecha- 269 nismen des Originals – insbesondere Programmsperren – umgangen oder beseitigt, so stellt dies eine Form des Behinderungswettbewerbs i.S.v. § 3 UWG dar, da sowohl die in der Erstellung des Programms liegenden Leistungen des Herstellers ausgenutzt als auch der weitere Absatz des Originalprogramms beeinträchtigt werden8. Wird der Kopierschutz überwunden, so 1 2 3 4 5 6 7

Köhler/Bornkamm, § 4 UWG Rz. 9.18. Köhler/Bornkamm, § 4 UWG Rz. 9.18. Köhler/Bornkamm, § 4 UWG Rz. 9.39. Köhler/Bornkamm, § 4 UWG Rz. 9.39. Köhler/Bornkamm, § 4 UWG Rz. 9.80. Sack, WRP 2005, 531 (536). Vgl. Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 9; Junker/Benecke, Computerrecht, Rz. 119. 8 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 30.

Karger

107

A Rz. 270

Grundlagen

stellt dies eine Art „geistigen Einbruch“ dar, da eine bewusste Schutzmaßnahme des Ersterstellers beseitigt wird1. Keine Wettbewerbshandlung ist das Nachahmen und das Anbieten zu rein privaten Zwecken, z.B. als Geschenk2. (2) Mitbewerberbezug 270

Bei den angebotenen nachgeahmten Waren oder Dienstleistungen muss es sich gem. § 4 Nr. 9 UWG um Waren oder Dienstleistungen eines Mitbewerbers handeln. Mitbewerber ist gemäß der Definition des § 2 Abs. 1 Nr. 3 UWG jeder Unternehmer, der mit einem oder mehreren Unternehmern als Anbieter oder Nachfrager von Waren oder Dienstleistungen in einem konkreten Wettbewerbsverhältnis steht. Ein potentielles Wettbewerbsverhältnis reicht hierbei aus, wenn die konkrete Wahrscheinlichkeit eines Marktzutritts besteht3. cc) Wettbewerbliche Eigenart der nachgeahmten Ware bzw. Dienstleistung

271

Gegenstand des ergänzenden wettbewerbsrechtlichen Leistungsschutzes sind nur solche Erzeugnisse, die eine gewisse wettbewerbliche Eigenart aufweisen. Gem. § 4 Nr. 9 UWG muss es sich hierbei um „Waren oder Dienstleistungen“ handeln, wobei diese Begriffe weit zu verstehen sind4. In Betracht kommen Leistungsergebnisse aller Art, unabhängig davon, ob für sie ein möglicher Sonderrechtsschutz besteht oder nicht5. Hierzu zählen grundsätzlich auch die Arbeitsergebnisse der Software-Erstellung, insbesondere Computerprogramme und Begleitmaterialien6. (1) Konkrete Gestaltung

272

Der ergänzende wettbewerbsrechtliche Leistungsschutz bezieht sich nur auf die konkrete Gestaltung eines Erzeugnisses, nicht aber auf die dahinter stehende abstrakte Idee. Entsprechendes gilt für sonstige allgemeine Gedanken oder Lehren, Techniken oder Methoden7. Für die Software-Erstellung bedeutet dies, dass ebenso wie im Urheberrecht die dem Programm zugrunde liegenden Ideen und allgemeinen Algorithmen8 sowie allgemeine gestalterische Elemente bzw. Motive9 nicht schutzfähig sind.

1 2 3 4 5 6 7 8 9

Redeker, IT-Recht, Rz. 190. Köhler/Bornkamm, § 4 UWG Rz. 9.18. Köhler/Bornkamm, § 4 UWG Rz. 9.19. Köhler/Bornkamm, § 4 UWG Rz. 9.21. Köhler/Bornkamm, § 4 UWG Rz. 9.21. Redeker, IT-Recht, Rz. 182. Köhler/Bornkamm, § 4 UWG Rz. 9.23. Redeker, IT-Recht, Rz. 182. Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 15.

108

Karger

Schutz und Realisierung der Software

Rz. 275 A

(2) Wettbewerbliche Eigenart Das nachgeahmte Erzeugnis muss eine gewisse wettbewerbliche Eigenart 273 aufweisen. Im Gesetz findet sich dieses Kriterium nicht. Das Merkmal wurde von der Rechtsprechung zu § 1 UWG a.F. entwickelt und findet auch nach neuem Recht im Rahmen von § 3 UWG und § 4 Nr. 9 UWG Anwendung1. Wettbewerbliche Eigenart liegt vor, wenn die konkrete Ausgestaltung oder bestimmte Merkmale des Erzeugnisses geeignet sind, die interessierten Verkehrskreise auf seine betriebliche Herkunft oder seine Besonderheiten hinzuweisen2. Grundsätzlich kann sich die wettbewerbliche Eigenart aufgrund ästheti- 274 scher bzw. technischer Merkmale ergeben3. Bei der Software-Erstellung, insbesondere bei der Erstellung von Computerprogrammen hat der Programmierer trotz gewisser Vorgaben eine große Vielfalt von Lösungs- und Gestaltungsmöglichkeiten. Bereits aus dieser Gestaltungsvielfalt folgt in der Regel eine für den Software-Experten erkennbare Besonderheit und Individualität und damit eine wettbewerbliche Eigenart4. Nicht erforderlich ist es hierbei, dass die urheberrechtlichen Kategorien der Schöpfungshöhe bzw. der persönlich-geistigen Schöpfung erfüllt werden5. Die erforderliche wettbewerbliche Eigenart ist vielmehr immer dann schon gegeben, wenn die Software mit einem nicht unerheblichen Aufwand an Zeit, Mühe und Kosten entwickelt worden ist6. Wettbewerbliche Eigenart kann z.B. einer Gesamtkonzeption von Befehlssät- 275 zen und Hilfstexten zukommen7. Im Regelfall weisen nicht nur komplexe, sondern auch einfachere Anwendungsprogramme wettbewerbliche Eigenart auf8. Dass die Software eine wettbewerbliche Eigenart aufweist, kann in der Regel auch bereits daraus abgeleitet werden, dass die Software überhaupt kopiert wurde, da der Mitwerber ein völlig wertloses und unbrauchbares Programm nicht übernommen hätte9.

1 Köhler/Bornkamm, § 4 UWG Rz. 9.24. 2 BGH v. 6.5.1999 – I ZR 199/96 – Tele-Info-CD, CR 1999, 496 m. Anm. Wuermeling = GRUR 1999, 923 (926), st. Rspr. 3 Köhler/Bornkamm, § 4 UWG Rz. 9.27 f. 4 LG Oldenburg v. 31.1.1996 – 5 O 3578/93 – Subventions-Analyse-System, CR 1996, 217 = GRUR 1996, 481, 487. 5 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 10. 6 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 10. 7 LG Hamburg v. 22.7.1988 – 74 O 253/88, CR 1989, 697. 8 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 24. 9 Redeker, IT-Recht, Rz. 182.

Karger

109

A Rz. 276

Grundlagen

dd) Nachahmung 276

Der Begriff der Nachahmung wird vom Gesetz nicht definiert. In Anknüpfung an die frühere Rechtsprechung sind drei Formen der Nachahmung zu unterscheiden1: – Die unmittelbare Leistungsübernahme, – die fast identische Leistungsübernahme und – die nachschaffende Leistungsübernahme. (1) Unmittelbare Leistungsübernahme

277

Eine unmittelbare Leistungsübernahme liegt vor, wenn die fremde Leistung unverändert übernommen wird2. Die Übernahme erfolgt zumeist mit Hilfe technischer Vervielfältigungsverfahren, z.B. durch das Kopieren des Programmcodes. Das Vorliegen einer unmittelbaren Übernahme begründet in aller Regel bereits das Merkmal der Unlauterkeit i.S.v. § 3 UWG. Die Wettbewerbswidrigkeit liegt in der Behinderung des Originalherstellers, der seinen wettbewerblichen Vorsprung aufgrund der kopierten Software nicht realisieren kann und um die Amortisation seines Aufwands gebracht wird, während der Mitbewerber sich eigenen Aufwand an Zeit, Kosten und Mitteln erspart3. Wettbewerbsrechtlich geschützt wird damit der als Produktionsanreiz notwendige „head start“4.

278

Der ergänzende Leistungsschutz erfordert nicht zwingend, dass die Software bzw. das Programm im Ganzen übernommen werden. Auch eine Teilübernahme ist unzulässig, wenn es sich um einen wesentlichen Teil handelt und dieser Teil eine wettbewerbliche Eigenart aufweist5. (2) Fast identische Leistungsübernahme

279

Eine fast identische Leistungsübernahme liegt vor, wenn die Nachahmung nur geringfügige, im Gesamteindruck unerhebliche Abweichungen vom Original aufweist6. Die fast identische Übernahme wird im Wesentlichen wie die unmittelbare Leistungsübernahme behandelt. Auch hier gilt, dass die Anforderungen an die wettbewerbliche Eigenart und an die besonderen unlauterkeitsbegründenden Umstände geringer sind als bei der nur nachschaffenden Leistungsübernahme7. 1 Köhler/Bornkamm, § 4 UWG Rz. 9.34b. 2 BGH v. 6.5.1999 – I ZR 199/96 – Tele-Info-CD, CR 1999, 496 m. Anm. Wuermeling = GRUR 1999, 923 (927). 3 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 27. 4 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 27. 5 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 28. 6 BGH v. 8.12.1999 – I ZR 101/97 – Modulgerüst, GRUR 2000, 521 (524); BGH v. 26.10.1989 – I ZR 216/87, MDR 1990, 513 = CR 1990, 188 (189). 7 Vgl. Köhler/Bornkamm, § 4 UWG Rz. 9.36; Redeker, IT-Recht, Rz. 185.

110

Karger

Schutz und Realisierung der Software

Rz. 282 A

(3) Nachschaffende Leistungsübernahme Eine nachschaffende Leistungsübernahme liegt vor, wenn die fremde Leistung nicht unmittelbar oder fast identisch übernommen, sondern lediglich als Vorbild benutzt und nachschaffend unter Einsatz eigener Leistung wiederholt wird1.

280

Eine freie, nur nachschaffende Übernahme eines fremden Leistungsergeb- 281 nisses stellt von sich aus keinen Wettbewerbsverstoß dar. Bei der nachschaffenden Leistungsübernahme werden im größeren Umfang eigene Mittel zur Nachahmung eingesetzt, so dass hier eine als selbständig erbracht anzuerkennende Eigenleistung eines Wettbewerbers vorliegen kann2. Die nachschaffende Leistungsübernahme kann aber im Einzelfall wettbewerbswidrig sein, wenn weitere, besondere Umstände hinzutreten, die eine Unlauterkeit begründen. Als solche, die Unlauterkeit indizierende Begleitumstände kommen insbesondere die Tatbestände des § 4 Nr. 9 UWG, also die Herkunftstäuschung, die Rufausbeutung bzw. Rufbeeinträchtigung und die Verwendung unredlich erlangter Kenntnisse und Unterlagen in Betracht. Allerdings dürfte im Bereich die Software-Erstellung eine eigenschöpferi- 282 sche Nachahmung nur selten in Betracht kommen. Der Spielraum möglicher Ergebnisse ist zu groß, als dass unterstellt werden könnte, eine praktisch identische Software sei nur nachgeschaffen und nicht kopiert3. Die Behauptung des Nachschaffens dürfte in der Regel eine Schutzbehauptung sein4. Bei vermeintlichen nachschaffenden Leistungsübernahmen handelt es sich in Wahrheit oft nur um Versuche der Verschleierung des Vorliegens einer Kopie oder sonstiger Manipulationen zur Verdeckung einer wettbewerbswidrigen unmittelbaren Leistungsübernahme5. Liegt ausnahmsweise tatsächlich eine nachschaffende Leistungsübernahme vor, kann eine Wettbewerbswidrigkeit nur dann bejaht werden, wenn das nachgeahmte Produkt einen höheren Grad der wettbewerblichen Eigenart aufweist und auch eine höhere Stufe der Unlauterkeit erreicht ist, als bei der unmittelbaren Leistungsübernahme6.

1 BGH v. 21.3.1991 – I ZR 158/89 – Betonsteinelemente, MDR 1991, 1153 = GRUR 1992, 523 (524). 2 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 14. 3 Redeker, IT-Recht, Rz. 187. 4 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 15; Redeker, IT-Recht, Rz. 187. 5 Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 15. 6 Redeker, IT-Recht, Rz. 187.

Karger

111

A Rz. 283

Grundlagen

ee) Besondere, die Unlauterkeit begründende Umstände 283

Die Übernahme der fremder Leistungen ist nur dann wettbewerbswidrig, wenn zum Tatbestand der Nachahmung besondere wettbewerbliche Umstände hinzu treten. Der Umstand, dass die angebotenen Produkte Nachahmungen sind, begründet für sich allein nicht die Unlauterkeit1.

284

Neben dem Merkmal der Behinderung kann eine erforderliche Unlauterkeit auch dann vorliegen, wenn einer der in § 4 Nr. 9 UWG genannten Tatbestände einschlägig ist, wobei hierbei der Herkunftstäuschung (§ 4 Nr. 9 lit. a UWG) und der Verwendung unredlich erlangter Kenntnisse (§ 4 Nr. 9 lit. c UWG) im Kontext der Software-Erstellung eine höhere Bedeutung zukommen dürfte als der Rufausbeutung (§ 4 Nr. 9 lit. b UWG). Auf letztere wird im Folgenden nicht weiter eingegangen2. (1) Behinderung durch Vereitelung der Amortisation des Entwicklungsaufwands

285

Im Falle der unmittelbaren Leistungsübernahme sind nur geringe Anforderungen an die besonderen unlauterkeitsbegründenden Umstände zu stellen, da die denkbar größte Intensität der Nachahmung erreicht ist3. Diese Umstände liegen hier regelmäßig in der Behinderung des Software-Erstellers, der um die Amortisation seines Aufwands gebracht wird, wenn der Mitbewerber durch seine identische Nachbildung den vom Ersteller erzielten Wettbewerbsvorsprung ohne eigenen Aufwand und Zeitkosten zunichte macht4.

286

Bei der nachschaffenden Leistungsübernahme kann sich die Unlauterkeit ebenfalls aus dem Gesichtspunkt der Behinderung ergeben, wobei hierbei zu beachten ist, dass ein wesentlich geringerer Grad der Nachahmung vorliegt als bei der unmittelbaren Leistungsübernahme und deshalb die Anforderungen an die wettbewerbliche Eigenschaft des nachgeahmten Produkts bzw. an den Grad der Behinderung aufgrund der Wechselwirkung der Merkmale entsprechend höher sind5.

1 Köhler/Bornkamm, § 4 UWG Rz. 9.40. 2 S. hierzu, insbesondere zu dem möglicherweise relevanten aber kontrovers diskutierten Tatbestand des „Einschiebens in eine fremde Serie“ Köhler/Bornkamm, § 4 UWG Rz. 9.56 ff., 9.56 ff.; Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 31. 3 BGH v. 6.5.1999 – I ZR 199/96 – Tele-Info-CD, CR 1999, 496 m. Anm. Wuermeling = GRUR 1999, 923 (927); Köhler/Bornkamm, § 4 UWG Rz. 9.69. 4 Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 27 m.w.N.; Redeker, ITRecht, Rz. 183. 5 Zu den einzelnen bei der Feststellung der Unlauterkeit zu berücksichtigenden Maßstäben im Überblick siehe Sack, WRP 2005, 531 (537 f.).

112

Karger

Rz. 290 A

Schutz und Realisierung der Software

(2) Behinderung durch die Beseitigung von Schutzmechanismen Die unerlaubte Beseitigung oder Umgehung von Schutzmechanismen, ins- 287 besondere von Programmsperren, stellt eine Form des Behinderungswettbewerbs dar, der sowohl die in der Erstellung des Programms liegenden Leistungen des Herstellers ausnutzt als auch den weiteren Absatz des Programms beeinträchtigt1. Wird der Kopierschutz überwunden, so stellt dies eine Art „geistigen Einbruch“ dar, da eine bewusste Schutzmaßnahme des Ersterstellers beseitigt wird2. In diesem Zusammenhang sieht bereits das Urheberrecht Sanktionsregelun- 288 gen in § 69f UrhG für Computerprogramme sowie in § 95a UrhG für sonstige geschützte Werke oder Schutzgegenstände, insbesondere für Datenbanken, vor3. Der wettbewerbsrechtliche Leistungsschutz gem. § 3 UWG ist jedoch auch neben den urheberrechtlichen Bestimmungen des § 69f Abs. 2 UrhG4 bzw. § 95a UrhG5 anwendbar. (3) Herkunftstäuschung Nach § 4 Nr. 9 lit. a UWG ist eine Unlauterkeit gegeben, wenn der Nach- 289 ahmer eine vermeidbare Täuschung der Abnehmer über die betriebliche Herkunft des nachgeahmten Erzeugnisses herbeiführt. Bei Computerprogrammen können Ansatzpunkt für eine Herkunftstäuschung grundsätzlich nur die äußeren Gestaltungsmerkmale eines Computerprogramms sein6. Hierzu zählen die graphische Benutzeroberfläche, insbesondere die Bildschirmmasken, die Menüaufteilung, die Benennung der Befehle, die Belegung der Funktionstasten sowie sonstige erkennbare Programmeigenschaften7. Eine Herkunftstäuschung kann u.U. auch bei ergänzender Software vorliegen, z.B. bei der Lieferung von Add-ons, sofern der Eindruck erweckt wird, es handele sich um Originalprogramme des Herstellers und nicht nur um passende Ergänzungen8. (4) Verwendung unredlich erlangter Kenntnisse und Unterlagen Gem. § 4 Nr. 9 lit. c UWG ist eine Unlauterkeit dann zu bejahen, wenn der 290 Übernehmer die für die Nachahmung erforderlichen Kenntnisse oder Unterlagen unredlich erlangt hat. Der Begriff der Unredlichkeit erfasst zum einen alle Fallgestaltungen der strafbaren Erlangung entsprechender Kenntnisse und Unterlagen. Hierzu gehören insbesondere die Tatbestände der §§ 17 und 18 UWG. Eine Unredlichkeit ist aber auch dann gegeben, wenn die 1 2 3 4 5 6 7 8

Grützmacher, in: Wandtke/Bullinger, § 69f UrhG Rz. 26. Redeker, IT-Recht, Rz. 190. Ausführlich hierzu Arlt, MMR 2005, 148 ff. Grützmacher, in: Wandtke/Bullinger, § 69f UrhG Rz. 26. Wandtke/Ohst, in: Wandtke/Bullinger, § 95a UrhG Rz. 6. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 25. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 25. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 26.

Karger

113

A Rz. 291

Grundlagen

Kenntnisse und Unterlagen unter Vertrauensbruch erlangt wurden. Ein Vertrauensverhältnis wird insbesondere durch die Anbahnung bzw. Durchführung eines Vertragsverhältnisses, wie bspw. eines Arbeits-, Dienst-, Werk-, Lizenz- oder Gesellschaftsvertrags, begründet1. ff) Schutzdauer 291

Der ergänzende Leistungsschutz nach dem UWG hat, anders als der Sonderrechtsschutz, keine feste zeitliche Begrenzung. Grundsätzlich dauert der ergänzende Leistungsschutz solange an, wie die wettbewerbliche Eigenart des nachgeahmten Erzeugnisses fortbesteht und die besonderen unlauterkeitsbegründenden Umstände nicht weggefallen sind2. Im Hinblick auf den Nachahmungsschutz für Software bedeutet dies, dass der Schutz nur solange bestehen kann, wie sich der Investitionsaufwand des Entwicklers nicht amortisiert hat und dieser einen angemessenen Gewinn erwirtschaften konnte3. Diesbezüglich werden je nach Softwareprodukt unterschiedliche Zeitgrenzen diskutiert: Bei Computerspielen soll die Zeitgrenze bereits bei einem Jahr liegen, bei komplexeren Betriebssystemen wird von einer längeren Schutzdauer ausgegangen4. Teilweise werden die zeitlichen Schutzgrenzen der anderen gesetzlichen Schutzsysteme, etwa nach dem Patentgesetz oder dem Urheberrechtsgesetz, herangezogen5. c) Rechtsfolgen eines Wettbewerbsverstoßes

292

Liegen die Voraussetzungen einer unlauteren Nachahmung i.S.v. § 3 UWG i.V.m. § 4 Nr. 9 UWG vor, so hat der Anspruchsberechtigte Anspruch auf Beseitigung und bei Wiederholungsgefahr Anspruch auf Unterlassung gem. § 8 UWG.

293

Da der Tatbestand des § 4 Nr. 9 UWG nach seinem Wortlaut nur das „Anbieten“ einer Nachahmung erfasst, kann nur die Unterlassung des Anbietens, nicht aber auch die Unterlassung des Herstellens verlangt werden6. Auch der Beseitigungsanspruch ist inhaltlich deutlich begrenzt: Er kann nur darauf gerichtet werden, dass die Nachahmungsstücke vom Markt genommen werden, soweit sie noch in der Verfügungsgewalt des Anbieters stehen7. Demgegenüber kann ihre Vernichtung nicht verlangt werden, da die Herstellung als solche noch nicht unlauter ist8. 1 2 3 4 5

Köhler/Bornkamm, § 4 UWG Rz. 9.62. Köhler/Bornkamm, § 4 UWG Rz. 9.70. Redeker, IT-Recht, Rz. 184; Köhler/Bornkamm, § 4 UWG Rz. 9.75. Vgl. Redeker, IT-Recht, Rz. 184 m.w.N. Lehmann, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, IX, Rz. 18; kritisch Redeker, IT-Recht, Rz. 184; s. auch Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 29. 6 Köhler/Bornkamm, § 4 UWG Rz. 9.80. 7 Köhler/Bornkamm, § 4 UWG Rz. 9.81. 8 Köhler/Bornkamm, § 4 UWG Rz. 9.81.

114

Karger

Schutz und Realisierung der Software

Rz. 296 A

Bei einem vorsätzlichen oder fahrlässigen Verstoß gegen § 3 UWG kann der 294 Mitbewerber gem. § 9 UWG den Ersatz des hieraus entstehenden Schadens verlangen. Vorsatz fordert das Bewusstsein der Rechtswidrigkeit, bei § 4 Nr. 9 UWG also auch das Bewusstsein der Unlauterkeit1. Weitaus häufiger als Vorsatz wird in der Praxis Fahrlässigkeit vorliegen. Gem. § 276 Abs. 2 BGB handelt fahrlässig, wer die im Verkehr erforderliche Sorgfalt nicht beachtet. An die Sorgfaltsanforderungen sind – wie generell im gewerblichen Rechtsschutz – strenge Anforderungen zu stellen2. Der Verletzer kann sich insbesondere nicht darauf berufen, er habe sein Verhalten unverschuldet für zulässig gehalten3. Fahrlässig handelt, wer sich erkennbar in einem Grenzbereich des rechtlich Zulässigen bewegt, in dem er eine von der eigenen Einschätzung abweichende Beurteilung der rechtlichen Zulässigkeit des fraglichen Verhaltens in Betracht ziehen muss4. Der Verletzte hat die Möglichkeit der dreifachen Schadensberechnung5. 295 Dies bedeutet, dass er nach seiner Wahl entweder – den konkreten Schaden einschließlich des entgangenen Gewinns oder – eine angemessene (fiktive) Lizenzgebühr oder – die Herausgabe des Verletzergewinns verlangen kann. Anspruchsberechtigt ist grundsätzlich nur der Hersteller des Originals, dessen Leistung wettbewerbswidrig nachgeahmt wird6. Daneben kann der Verletzte auch einen verschuldensunabhängigen Bereicherungsanspruch gem. § 812 Abs. 1 Satz 1, 2. Alt. BGB geltend machen7. 2. Geheimnisschutz a) Allgemeines Gem. § 17 UWG sind der Geheimnisverrat durch einen Beschäftigten, die 296 Betriebsspionage, d.h. das Ausspähen eines Geheimnisses durch bestimmte Mittel und Methoden und die Geheimnisverwertung, d.h. die unbefugte Verwertung eines durch Verrat oder Ausspähung erlangten Geheimnisses, strafbar. Gem. § 18 UWG ist die unbefugte Nutzung anvertrauter Geheimnisse, die sog. Vorlagenfreibeuterei strafbar. Durch § 19 UWG wird der strafrechtliche Schutz der §§ 17 und 18 UWG auf bestimmte Handlungen erweitert. 1 Köhler/Bornkamm, § 4 UWG Rz. 9.82. 2 BGH v. 6.5.1999 – I ZR 199/96 – Tele-Info-CD, CR 1999, 496 m. Anm. Wuermeling = GRUR 1999, 923 (928). 3 BGH v. 6.5.1999 – I ZR 199/96 – Tele-Info-CD, CR 1999, 496 m. Anm. Wuermeling = GRUR 1999, 923 (928). 4 BGH v. 6.5.1999 – I ZR 199/96 – Tele-Info-CD, CR 1999, 496 m. Anm. Wuermeling = GRUR 1999, 923 (928). 5 Köhler/Bornkamm, § 4 UWG Rz. 9.83. 6 Köhler/Bornkamm, § 4 UWG Rz. 9.85. 7 Köhler/Bornkamm, § 4 UWG Rz. 9.84.

Karger

115

A Rz. 297

Grundlagen

297

Die Bestimmungen sind dem Wirtschaftsstrafrecht zuzuordnen, das UWG ist insoweit ein strafrechtliches Nebengesetz1.

298

Software und ihre Elemente unterfallen grundsätzlich dem Schutz der §§ 17 ff. UWG. Dies ist in der Praxis von besonderer Relevanz, da Computerprogramme und EDV-Technik zu den besonders gefährdeten Gruppen der Wirtschaftsgeheimnisse zählen2. Die Vorschriften schützen einerseits geheime Arbeitsergebnisse des Software-Erstellers, setzen diesem aber umgekehrt auch deutliche Grenzen bei der Beschaffung und Verwendung von Materialien Dritter. b) Verrat von Geschäfts- und Betriebsgeheimnissen

299

§ 17 UWG enthält drei unterschiedliche Straftatbestände: Den Geheimnisverrat (§ 17 Abs. 1 UWG), die Betriebsspionage (§ 17 Abs. 2 Nr. 1 UWG) sowie die Geheimnisverwertung (§ 17 Abs. 2 Nr. 2 UWG). aa) Geschäfts- oder Betriebsgeheimnis (1) Begriff

300

Zentraler Begriff bei allen drei Tatbeständen ist das „Geschäfts- oder Betriebsgeheimnis“. Dieser Begriff wird im Gesetz nicht definiert. Die Anforderungen sind jedoch von Rechtsprechung und Literatur herausgearbeitet worden.

301

Unter einem Geschäfts- oder Betriebsgeheimnis ist jede im Zusammenhang mit einem Geschäftsbetrieb stehende, nicht offenkundige, sondern nur einem begrenzen Personenkreis bekannte Tatsache zu verstehen, an deren Geheimhaltung der Unternehmensinhaber ein berechtigtes wirtschaftliches Interesse hat und die nach seinem bekundeten oder durch erkennbaren Willen auch geheim bleiben sollen3.

302

Geschäftsgeheimnisse beziehen sich dabei auf den kaufmännischen Bereich einer Firma, während unter Betriebsgeheimnissen Tatsachen und Kenntnisse technischer Art verstanden werden4. Eine genaue Abgrenzung der Begriffe ist jedoch entbehrlich, da beide Unterarten des Unternehmensgeheimnisses gleich behandelt werden5. Die Terminologie ist in der Praxis

1 Többens, WRP 2005, 552 f. 2 Többens, WRP 2005, 552 (555). 3 Köhler/Bornkamm, § 17 UWG Rz. 4 m.w.N.; Többens, WRP 2005, 552 (555); Harte-Bavendamm/Henning-Bodewig, § 18 UWG Rz. 1; Kiethe/Groeschka, WRP 2005, 1358 (1363 f.). 4 Köhler/Bornkamm, § 17 UWG Rz. 4a; Többens, WRP 2005, 552 (555). 5 Többens, WRP 2005, 552 (555).

116

Karger

Schutz und Realisierung der Software

Rz. 307 A

uneinheitlich: Vielfach wird von Betriebsgeheimnis, von Know-how1, von Wirtschafts- oder Unternehmensgeheimnis gesprochen2. Insbesondere Software bzw. Computerprogramme können Betriebsgeheimnisse darstellen bzw. solche beinhalten oder abbilden3. Der urheberrechtliche Schutz nach §§ 69a ff. UrhG schließt gem. § 69e Abs. 1 UrhG eine Anwendung der §§ 17 ff. UWG nicht aus4.

303

(2) Unternehmensbezug, Geheimhaltungsinteresse und -wille Eine Tatsache muss, um ein Betriebsgeheimnis zu sein, einem Unterneh- 304 men zuzuordnen sein. Das Geheimhaltungsinteresse liegt vor, wenn die Tatsache für die Wettbewerbsfähigkeit des Unternehmens von Bedeutung ist5. Ein Geheimhaltungswille ist grundsätzlich für alle Betriebsinterna zu vermuten, die nicht offenkundig sind6. Sofern die an einem Entwicklungsprojekt beteiligten Personen oder Unter- 305 nehmen sich vertraglich zur Geheimhaltung verpflichtet haben – häufig durch ein sog. Non-Disclosure Agreement (NDA) – ist der Geheimhaltungswille ausdrücklich dokumentiert. Häufig werden im Rahmen der SoftwareErstellung entstehende oder ausgetauschte Dokumente und Materialien, etwa Pflichtenhefte oder Konzepte mit dem Vermerk „Vertraulich“ oder „Confidential“ versehen, so dass auch diesbezüglich der Geheimhaltungswille deutlich geworden ist. Bei Software wird ein Geheimhaltungswille im Übrigen etwa dann an- 306 genommen, wenn die entsprechenden Computerprogramme mit einem Programmschutzmechanismus ausgestattet sind, nur der maschinenlesbare Objektcode – und nicht der Quellcode – zur Verfügung gestellt wird oder die Software in ein Gehäuse integriert ist7. (3) Keine Offenkundigkeit Die Tatsache darf nicht offenkundig, sondern nur einem begrenzten Per- 307 sonenkreis bekannt sein. Offenkundig ist eine Tatsache, wenn sie allgemein bekannt ist oder die Kenntnis darüber von jedem Interessierten auf normalem Wege ohne größere Schwierigkeiten erlangt werden kann8. Die Offenkundigkeit einer Tatsache nimmt ihr den Geheimnischarakter und der Geheimnisschutz entfällt. Computerprogramme können auch durch häufige

1 Zur Abgrenzung zwischen Betriebsgeheimnis und Know-how s. Köhler/Bornkamm, § 17 UWG Rz. 4b. 2 Kiethe/Groeschke, WRP 2005, 1358 (1363). 3 Köhler/Bornkamm, § 17 UWG Rz. 12 m.w.N.; Taeger, CR 1991, 441 ff. 4 Köhler/Bornkamm, § 17 UWG Rz. 12, Rz. 57. 5 Köhler/Bornkamm, § 17 UWG Rz. 9. 6 Köhler/Bornkamm, § 17 UWG Rz. 10. 7 Junker/Benecke, Computerrecht, Rz. 126. 8 Többens, WRP 2005, 552 (556).

Karger

117

A Rz. 308

Grundlagen

Raubkopien offenkundig werden, wobei es unerheblich ist, dass dies gegen den Willen des Geheimnisinhabers erfolgt1. 308

Welche Größe und Zusammensetzung der Kreis der eingeweihten Personen haben darf, damit eine Offenkundigkeit ausgeschlossen ist, hängt von den Umständen ab. Es muss sich jedenfalls um einen im Wesentlichen in sich geschlossenen Personenkreis handeln2. Hierzu gehören zum einen die Betriebsangehörigen, aber auch externe Programmierer, freie Mitarbeiter und Kunden3. Wichtig ist hierbei, dass nach den Umständen mit einer Geheimhaltung durch diese Personen gerechnet werden kann. Dies ist insbesondere dann der Fall, wenn rechtlich bindende Geheimhaltungspflichten auferlegt werden, z.B. in einem Softwareerstellungs- oder Lizenzvertrag oder in gesonderten Geheimhaltungsvereinbarungen4.

309

Im Hinblick auf Arbeitsergebnisse bei der Software-Erstellung ist regelmäßig davon auszugehen, dass diese jedenfalls zunächst Geschäfts- und Betriebsgeheimnisse darstellen. Zu den geschützten Geheimnissen zählen insbesondere der nicht offenkundige Quellcode, die Konzeption, Algorithmen, Datenformate, Ein- und Ausgabeformate, besonders wichtige Programmdaten und sonstiges technisches Know-how5. Ob Schnittstellen Geschäftsoder Betriebsgeheimnisse darstellen können, ist streitig. Jedenfalls scheidet eine Anwendung des § 17 UWG aus, wenn die Ermittlung einer Schnittstelle im Wege einer nach § 69e UrhG erlaubten Dekompilierung erfolgt6. Dies gilt auch dann, wenn die Dekompilierung vertraglich verboten wurde7.

310

Im Hinblick auf Individualsoftware wird vertreten, dass diesbezüglich in der Regel von einer fehlenden Offenkundigkeit auszugehen sei. Individualsoftware stelle im Regelfall ein Geschäftsgeheimnis des anwendenden Unternehmens dar8. Ob dies allgemein so zutrifft, dürfte aber zweifelhaft sein.

311

Bei Standardsoftware wird differenziert: Sie kann allenfalls ein Geschäftsgeheimnis des Programmherstellers, nicht jedoch ein Geschäftsgeheimnis des Anwenders sein9. Bei im Verkehr befindlicher Software stellt der Objektcode grundsätzlich kein Betriebsgeheimnis dar10. Demgegenüber ist davon auszugehen, dass der Quellcode grundsätzlich ein Betriebsgeheimnis des Herstellers darstellt, wenn er dem Anwender nicht überlassen wird11. 1 2 3 4 5 6 7 8 9 10 11

Köhler/Bornkamm, § 17 UWG Rz. 8. Köhler/Bornkamm, § 17 UWG Rz. 7a. Köhler/Bornkamm, § 17 UWG Rz. 7a. Vgl. BGH v. 9.5.1985 – I ZR 52/83 – Inkassoprogramm, MDR 1986, 121 = CR 1985, 22 = GRUR 1985, 1041 (1044); Köhler/Bornkamm, § 17 UWG Rz. 7a. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 33 m.w.N. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 35. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 35. Junker/Benecke, Computerrecht, Rz. 127. Junker/Benecke, Computerrecht, Rz. 127. Redeker, IT-Recht, Rz. 199. Redeker, IT-Recht, Rz. 199.

118

Karger

Rz. 315 A

Schutz und Realisierung der Software

Wird der Quellcode – wie bei interpretierenden Programmen nötig und häufiger üblich – mit verbreitet, unterliegt er keinem Geheimnisschutz1. Das Betriebsgeheimnis bleibt auch gewahrt, wenn der Quellcode zugunsten des Anwenders bei einem Escrow-Unternehmen hinterlegt wird und sowohl der Escrow-Agent wie auch der begünstigte Anwender im Herausgabefall einer Geheimhaltungsverpflichtung unterliegen. bb) Geheimnisverrat Nach § 17 Abs. 1 UWG ist strafbar, wer als eine bei einem Unternehmen 312 beschäftigte Person ein Geschäfts- oder Betriebsgeheimnis, das ihr im Rahmen des Dienstverhältnisses anvertraut worden oder zugänglich geworden ist, während der Geltungsdauer des Dienstverhältnisses unbefugt an jemand zu Zwecken des Wettbewerbs, als Eigennutz, zugunsten eines Dritten oder in der Absicht, dem Inhaber des Unternehmens Schaden zuzufügen, mitteilt. Die Norm erfasst alle Beschäftigten eines Unternehmens. Der Begriff ist 313 weit auszulegen2. Neben den Arbeitnehmern zählen hierzu auch Vorstandsund Aufsichtsratsmitglieder und GmbH-Geschäftsführer. Keine Beschäftigten sind hingegen selbständige Gewerbetreibende, Freiberufler oder freie Mitarbeiter. Tatgegenstand ist ein Geschäfts- oder Betriebsgeheimnis, das dem Beschäf- 314 tigten im Rahmen des Dienstverhältnisses anvertraut worden oder zugänglich gemacht worden ist. Das Dienstverhältnis muss somit ursächlich für die Kenntniserlangung sein3. Das Geheimnis ist anvertraut, wenn der Beschäftigte auf die Geheimhaltung ausdrücklich oder konkludent hingewiesen wurde. Das Geheimnis wird dem Beschäftigten zugänglich gemacht, wenn er es irgendwie im Zusammenhang mit seiner betrieblichen Tätigkeit in Erfahrung bringt4. Vom Beschäftigten i.S.v. § 69b UrhG entwickelte Software stellt ebenso wie eine Diensterfindung gem. §§ 4, 24 ArbEG ein Geheimnis des Unternehmens dar und unterliegt der Geheimhaltungspflicht5. Tathandlung ist die unbefugte Mitteilung des Betriebsgeheimnisses an ei- 315 nen Dritten. Hierbei muss die Tat während der Geltungsdauer des Dienstverhältnisses begangen werden. Verletzungshandlungen nach Ablauf des Dienstverhältnisses lösen allenfalls eine zivilrechtliche Haftung aus6. Diese zeitliche Begrenzung ist problematisch, da insbesondere im Softwarebereich viele Verratsfälle mit einem Arbeitsplatzwechsel in Zusammenhang ste-

1 2 3 4 5 6

Redeker, IT-Recht, Rz. 199. Köhler/Bornkamm, § 17 UWG Rz. 14. Köhler/Bornkamm, § 17 UWG Rz. 15. Többens, WRP 2005, 552 (556). Többens, WRP 2005, 552 (556); Köhler/Bornkamm, § 17 UWG Rz. 17. Köhler/Bornkamm, § 17 UWG Rz. 22.

Karger

119

A Rz. 316

Grundlagen

hen1. Allerdings ist in diesem Fall eine Strafbarkeit nach § 17 Abs. 2 UWG zu prüfen2. 316

Unbefugt ist die Mitteilung, wenn keine Einwilligung des Berechtigten vorliegt. Der subjektive Tatbestand erfordert, dass der Täter hinsichtlich der objektiven Tatbestandsmerkmale vorsätzlich und im Übrigen aus einem der in § 17 Abs. 1 UWG genannten Beweggründe gehandelt haben muss3. cc) Betriebsspionage

317

Nach § 17 Abs. 2 Nr. 1 UWG macht sich strafbar, wer zu Zwecken des Wettbewerbs, aus Eigennutz, zugunsten eines Dritten oder in der Absicht, dem Inhaber eines Unternehmens Schaden zuzufügen, sich ein Geschäftsoder Betriebsgeheimnis durch Anwendung technischer Mittel, Herstellung einer verkörperten Wiedergabe des Geheimnisses oder Wegnahme einer Sache, in der das Geheimnis verkörpert ist, unbefugt verschafft oder sichert. Die Vorschrift erfasst typische und besonders gefährliche Begehungsformen der Betriebsspionage. Täter kann jedermann, also ein Beschäftigter ebenso wie ein Dritter sein4.

318

Die Tat muss unter Einsatz der drei im Gesetz genannten Tatmittel begangen werden. Für die Anwendung technischer Mittel i.S.v. § 17 Abs. 2 Nr. 1 lit. a UWG genügt bereits das Abrufen von Daten, die Verwendung von Computern und auch das „Anzapfen“ von EDV-Anlagen und Datenfernleitungen5.

319

Die Dekompilierung des Codes ist tatbestandsmäßig, es sei denn, sie ist gem. § 69e UrhG erlaubt6.

320

Die Herstellung einer verkörperten Wiedergabe des Geheimnisses erfolgt in der Regel durch Anfertigung von Fotokopien, Computerausdrucken sowie durch Übertragung von Daten auf Datenträger7.

321

Die Wegnahme einer Sache, in der das Geheimnis verkörpert ist, liegt vor, wenn z.B. ein Datenträger entwendet wird. Die Verkörperung kann das Original oder eine Kopie sein. Wegnahme bedeutet das Ansichbringen in einer Weise, die eine Weitergabe oder Verwertung ermöglicht. Einen typischen Verstoß gegen § 17 Abs. 2 Nr. 1 lit. c UWG stellt die Mitnahme des Quellcodes durch einen Arbeitnehmer dar8. Dies gilt auch, wenn der Quellcode noch zu Zeiten des Beschäftigungsverhältnisses befugt auf einem privaten

1 2 3 4 5 6 7 8

Junker/Benecke, Computerrecht, Rz. 130. Junker/Benecke, Computerrecht, Rz. 130. Hierzu näher Többens, WRP 2005, 552 (557). Redeker, IT-Recht, Rz. 201. Köhler/Bornkamm, § 17 UWG Rz. 33. Redeker, IT-Recht, Rz. 201. Köhler/Bornkamm, § 17 UWG Rz. 34. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 36.

120

Karger

Schutz und Realisierung der Software

Rz. 324 A

Rechner gespeichert wurde1. Indiz für einen Verstoß kann sein, dass schon kurze Zeit nach dem Ausscheiden eines Mitarbeiters ein Konkurrenzprogramm erhältlich ist2. Eine Wegnahme liegt nicht vor, wenn der Täter die Verkörperung bereits besitzt, d.h. Alleingewahrsam hat3. dd) Geheimnisverwertung Nach § 17 Abs. 2 Nr. 2 UWG macht sich strafbar, wer zu Zwecken des 322 Wettbewerbs, aus Eigennutz, zugunsten eines Dritten oder in der Absicht, dem Inhaber eines Unternehmens Schaden zuzufügen, ein Geschäfts- oder Betriebsgeheimnis, das er durch eine der in § 17 Abs. 1 UWG bezeichneten Mitteilungen oder durch eine eigene oder fremde Handlung nach § 17 Abs. 2 Nr. 1 UWG erlangt oder sich sonst unbefugt verschafft oder gesichert hat, unbefugt verwertet oder jemandem mitteilt. Täter kann jedermann, auch ein Beschäftigter bzw. ein ehemaliger Beschäf- 323 tigter sein4. Die Verwertung umfasst jede Art der wirtschaftlichen Nutzung5. Eine Mitteilung ist die Weitergabe an einen beliebigen Dritten. Unbefugt ist die Tathandlung, wenn sie ohne die Einwilligung des Berechtigten ohne einen anderen Rechtfertigungsgrund geschieht6. Der Täter muss das Geheimnis, das er verwertet oder weitergibt, auf eine der im Gesetz bestimmten drei Varianten an sich gebracht haben7. c) Vorlagenfreibeuterei § 18 UWG ergänzt den Geheimnisschutz nach § 17 UWG und dient ebenfalls dem Schutz des Geheimnisbereichs eines geschäftlichen Betriebs. Täter kann jeder Dritte mit Ausnahme eines Beschäftigten des Anvertrauenden sein8. Nach § 18 UWG ist strafbar, wer die ihm im geschäftlichen Verkehr anvertrauten Vorlagen oder Vorschriften technischer Art, insbesondere Zeichnungen, Modelle, Schablonen, Schnitte, Rezepte zu Zwecken des Wettbewerbs oder aus Eigennutz unbefugt verwertet oder jemandem mitteilt. Tatobjekte sind Vorlagen oder Vorschriften technischer Art. Hierunter fallen auch Computerprogramme9. Tathandlung ist das unbefugte Verwerten oder Mitteilen. Diesbezüglich gelten die Ausführungen zu § 17 UWG entsprechend. 1 2 3 4 5 6 7

Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 36. Grützmacher, in: Wandtke/Bullinger, § 69g UrhG Rz. 36. Köhler/Bornkamm, § 17 UWG Rz. 35. Köhler/Bornkamm, § 17 UWG Rz. 49. Köhler/Bornkamm, § 17 UWG Rz. 41. Többens, WRP 2005, 552 (558). Näher hierzu Köhler/Bornkamm, § 17 UWG Rz. 44 ff.; Többens, WRP 2005, 552 (558). 8 Köhler/Bornkamm, § 18 UWG Rz. 14. 9 Köhler/Bornkamm, § 18 UWG Rz. 10.

Karger

121

324

A Rz. 325

Grundlagen

d) Rechtsfolgen eines Verstoßes 325

Eine Verletzung der §§ 17 bis 19 UWG zieht primär strafrechtliche Konsequenzen nach sich. Daneben kommen zivilrechtliche Ansprüche gegen den Täter in Betracht.

326

Die strafrechtlichen Sanktionen sind einschneidend. Die Strafandrohung bewegt sich je nach Tatbestand zwischen bis zu drei Jahren oder Geldstrafe im Regelfall und bis hin zu fünf Jahren oder Geldstrafe in besonders schweren Fällen.

327

Wettbewerbsrechtliche Ansprüche kommen nur in Betracht, sofern die Handlung auch einen Verstoß gegen § 3 UWG darstellt1. Die Handlung muss eine Wettbewerbshandlung i.S.v. § 2 Abs. 1 Nr. 1 UWG darstellen. Dies dürfte allerdings im Regelfall zutreffen, weil Zuwiderhandlungen gegen die §§ 17 ff. UWG den Tatbestand des Rechtsbruchs gem. § 3 UWG i.V.m. § 4 Nr. 11 UWG (Rechtsbruch) erfüllen. In Betracht kommt auch ein Verstoß gegen § 3 i.V.m. § 4 Nr. 9 lit. c UWG2.

328

Daneben können sich Ansprüche aus § 823 BGB oder § 826 BGB, aus § 280 BGB und aus § 812 Abs. 1 Satz 1, 2. Alt. BGB ergeben. Sofern das Geschäftsoder Betriebsgeheimnis sondergesetzlich geschützt ist, wie insbesondere Computerprogramme nach den §§ 69a ff. UrhG, kommen auch die sondergesetzlichen Ansprüche in Betracht.

329

Abwehransprüche, d.h. Unterlassungs- und Beseitigungsansprüche, können sich aus den §§ 17 ff. UWG i.V.m. §§ 823 Abs. 2, 1004 BGB analog, aus § 823 Abs. 1, § 826 i.V.m. § 1004 BGB analog und bei gleichzeitigem Wettbewerbsverstoß aus § 3 i.V.m. § 8 UWG ergeben3.

IV. Open Source-Software 330

Bei Erstellung von Software wird mehr und mehr auf vorbestehende Komponenten zurückgegriffen. Das bedeutet, dass in ein Produkt Softwarekomponenten einfließen, die ihren eigenen Lizenzbedingungen unterliegen. Für die Vertragsgestaltung entstehen dadurch weitere Herausforderungen, besonders dann, wenn es nicht um die Verwendung proprietärer Komponenten geht, sondern um solche Komponenten, die hinsichtlich des Quellcodes besondere Bedingungen enthalten. Im Hinblick auf Open Source-Komponenten besteht für Entwickler vor allen Dingen die Gefahr, dass der eigene Quellcode durch den Open Source-Quellcode „infiziert“ wird4. Insofern ist 1 2 3 4

Köhler/Bornkamm, § 17 UWG Rz. 52. Köhler/Bornkamm, § 17 UWG Rz. 52. Köhler/Bornkamm, § 17 UWG Rz. 63 ff. Vgl. Hoppen/Thalhofer, CR 4/2010, 275, die unter „Infektion“ verstehen, dass der proprietäre Quellcode so mit der Open Source-Software verbunden wird, dass Entwickler ihren Code offenzulegen haben.

122

Fechtner

Schutz und Realisierung der Software

Rz. 333 A

es von hoher Bedeutung, dass Entwickler zwischen den Bestandteilen mit Open Source-Basis und den übrigen Bestandteilen trennen und die Open Source-Lizenzbedingungen einhalten. Im Übrigen muss sich die Geschäftsleitung eines Softwarehauses überlegen, ob generell die Verwendung von Open Source-Komponenten gewollt oder gewünscht ist und welche Open Source-Lizenzbedingungen als „unschädlich“ erachtet werden. Es muss auch bewerten, wie sich die vielfältigen Open Source-Bedingungen miteinander vereinbaren lassen und welche Auswirkungen die Verwendung von Open Source-Komponenten auf proprietäre Komponenten und Lizenzbedingungen hat. 1. Bedeutung von Open Source-Software bei Softwareerstellung und bei Softwareanpassung Die Verwendung von Open Source-Software ist unter wirtschaftlichen Ge- 331 sichtspunkten auf den ersten Blick oftmals besonders attraktiv. Dies ist vor allen Dingen der Tatsache geschuldet, dass Open Source-Software in der Regel kostenlos zur Verfügung steht. Softwarehäuser können sich bei der Produktentwicklung erhebliche finanzielle Mittel sparen. Wenn auch die Einnahmen von Lizenzgebühren weitgehend entfallen, ist Open SourceSoftware eine nicht wegzudenkende Komponente in der Softwareindustrie1. Die ursprünglich vornehmlich altruistischen Motive sind hierbei allerdings zum großen Teil durch ökonomische Interessen ersetzt worden. Dabei findet Open Source-Software immer mehr Anwendungsfelder. Große Bedeutung erlangt Open Source-Software etwa im Bereich der sog. value-added-Produkte, aber auch im Markt der Embedded Services. Es existiert mittlerweile eine breite Palette an Open Source-Software, die mehr und mehr in Konkurrenz zur übrigen Anwendungssoftware tritt2. Die Einbeziehung großer Technologieanbieter und auch die vermehrte Akzeptanz in öffentlichen Einrichtungen führt zu einem Wachstum im Bereich Open Source. In der Softwareentwicklung sind insbesondere solche Entwicklungen inte- 332 ressant, bei denen Unternehmen proprietäre Anwendungen entwickeln, die auf Open Source-Programme aufbauen, weil dadurch auch Kosteneinsparungen erzielt werden können3. Durch die Einsparung von Lizenzentgelten wird Open Source-Software zu- 333 nehmend genutzt, in der Wirtschaft wie auch in der Verwaltung. Ob dies aus betriebswirtschaftlicher Sicht immer sinnvoll ist, ist dabei zumindest zu hinterfragen. Denn in einigen Fällen treten an die Stelle von Lizenzkos1 Open Source Software ist insbesondere in den Gebieten Datenbanken, Entwicklungssysteme, Web Browser und -Server sowie Content Management Systeme präsent. Mit zunehmender Ausgereiftheit werden auch andere Einsatzgebiete relevant, z.B. Betriebssysteme, Grafik Software und Office Produkte. 2 Ein prominentes Beispiel ist etwa Open Office als Alternative zum Office-Paket von Microsoft, vgl. http://www.openoffice.org. 3 Vgl. dazu unten Rz. 366 f.

Fechtner

123

A Rz. 334

Grundlagen

ten erhebliche Kosten im Bereich von Wartung und Betrieb. Distributoren bieten vielfach neben der kostenfrei weitergegebenen Software Zusatzleistungen und Support gegen Entgelt an. 334

Mit den gestiegenen Einsatzbereichen einher geht der Trend, sich gegen Lizenzverletzungen zu wehren1. Demzufolge sind Unternehmen zunehmend gezwungen, eine Einhaltung der für sie maßgeblichen Lizenzvorschriften sicherzustellen. Rechtlich problematisch ist dies insbesondere, wenn proprietäre Anwendungen auf Open Source-Programmen aufbauen und diese Programme unter einer Copyleft-Lizenz stehen. Schwierigkeiten bereitet hier insbesondere die Abgrenzung von Open Source-Software zu proprietärer Eigenentwicklung. Die genaue Grenzziehung zwischen einer zustimmungsbedürftigen Modifikation eines Open Source-Programms und der Erstellung eines eigenständigen Programms, welches unabhängig von den Voraussetzungen einer Open Source-Lizenz vertrieben werden darf, ist mitunter problematisch. Ob eine Copyleft-Klausel greift, hängt stark von der technischen Ausgestaltung der Einbindung der Open Source-Software in das Endprodukt ab2. 2. Begriff der „Open Source-Software“

335

Der Inhalt des Begriffs der „Open Source-Software“ lässt sich relativ konkret umschreiben. Eine inzwischen allgemein anerkannte Definition wurde von der Free Software Foundation (FSF) entwickelt3. Die Anforderungen, die die FSF aufstellt, ergeben sich aus der jeweiligen Softwarelizenz. Nach der vorherrschenden „Open Source-Definition“4 müssen die Lizenzbedingungen folgende Kriterien erfüllen: a) Freie Weitergabe

336

Für die Nutzung dürfen keine Lizenzgebühren verlangt werden. Zu beachten ist, dass damit allerdings nicht die kommerzielle Nutzung und Verwertung ausgeschlossen wird. Denn die Verwendung der Software darf nicht begrenzt werden, auch nicht auf eine nicht-kommerzielle Nutzung. Demzufolge kann für alle Leistungen ein Entgelt verlangt werden, lediglich nicht für die Einräumung von Nutzungs- und Verwertungsrechten.

1 Beispiele hierfür sind die „Freedom Task Force“, vgl. http://www.germany.fsfeu rope.org/projects/ftf/ sowie des gpl-violations-Projekt, vgl. http://www.gpl-viola tions.org. 2 Ausführlich zu den unterschiedlichen Integrations- bzw. Nutzungsszenarien vgl. Hoppen/Thalhofer, CR 4/2010, 275 ff., im Übrigen vgl. Rz. 366 f. 3 Die FSF hat auch Lizenzen wie die GNU General Public License, GPL, erstellt. 4 http://www.opensource.org/docs/definition.html, übersetzt: http://www.debian anwenderhandbuch.de/freiesoftware.html#osid.

124

Fechtner

Schutz und Realisierung der Software

Rz. 343 A

b) Freier Zugang zum Quellcode Die Software muss im Quellcode vorliegen und eine Weitergabe muss sowohl für den Quellcode als auch für die kompilierte Form zulässig sein. Sollte das Programm ohne Quellcode weitergegeben werden, so muss dieser zumindest zugänglich gemacht werden.

337

c) Abgeleitete Software Die Lizenzbedingungen müssen Weiterentwicklungen und Veränderungen 338 der Software zulassen. Zudem muss die veränderte Software unter den gleichen Bedingungen wie das Original weiterverbreitet werden können. d) Unversehrtheit des Quellcodes des Autors Die Möglichkeit, den Quellcode in veränderter Form weiterzugeben, darf 339 nur dann eingeschränkt sein, wenn die gesonderte Weitergabe mit sog. „Patchdateien“ gestattet ist, die den Programmcode bei der Kompilierung verändern. Der Quellcode soll so von fremdem Code getrennt gehalten werden. Demzufolge kann auch verlangt werden, dass die abgeleiteten Programme (d.h. die Bearbeitungen) einen anderen Namen oder eine andere Versionsnummer als die Ausgangssoftware tragen müssen. e) Keine Diskriminierung von Personen und Gruppen Die Lizenz darf keine Personen oder ganze Gruppen benachteiligen.

340

f) Keine Einschränkung bezüglich des Einsatzfeldes Die Nutzung und Verwertung darf nicht auf bestimmte Bereiche beschränkt 341 werden oder bspw. kommerzielle Nutzung ausschließen. g) Weitergabe der Lizenz Die Rechte, die die Lizenz gewährt, müssen für alle Personen gelten, die das Programm erhalten haben, ohne dass die Notwendigkeit dazu besteht, eine weitere Lizenz zu erwerben.

342

h) Keine Beschränkung auf ein bestimmtes Produktpaket Die Rechte zur Softwarenutzung dürfen nicht davon abhängen, dass das 343 Programm Teil eines bestimmten Software-Pakets ist. Wird das Programm aus einem Paket herausgenommen und weitergegeben, so erhalten die Personen, die das Programm erhalten, diejenigen Rechte, die auch in Verbindung mit dem ursprünglichen Software-Paket gewährt wurden.

Fechtner

125

A Rz. 344

Grundlagen

i) Keine Einschränkung anderer Software 344

Wird andere Software zusammen mit der lizenzierten Software weitergegeben, so darf die Lizenz keine Einschränkung bezüglich der anderen Software enthalten. Insbesondere darf die Lizenz nicht verlangen, dass sämtliche Software, die auf demselben Medium weitergegeben wird, Open Source-Software sein muss. 3. Abgrenzung

345

Der offensichtliche Unterschied zur proprietären Software ist der Umfang der Rechtseinräumung, der weitere Nutzungsmöglichkeiten eröffnen und sichern soll1. Eine Abgrenzung zu anderen Lizenzmodellen ist mangels einheitlicher Terminologie mitunter schwierig, daher sollten die Begriffe „Open Source-Software“ und „Freie Software“ nur im Sinne der genannten Definition gebraucht werden. Zur Vermeidung von Verwechslungen und Begriffsunklarheiten wird „Open Source-Software“ im Folgenden zu weiteren Lizenzmodellen abgegrenzt, wobei hierbei die gebräuchlichen und häufig eingesetzten Begrifflichkeiten verwendet werden. a) Freeware

346

Die Ähnlichkeit der Begriffe „Freeware“ und „freie Software“ (Open SourceSoftware) birgt viel Potential für Missverständnisse. Während die Open Source-Software nicht immer kostenlos zu vertreiben ist, handelt es sich bei der „Freeware“ um tatsächlich kostenlose Überlassung von Software2. Vornehmlich wird mit der „Freeware“ eine Weiterverbreitung, nicht aber eine Weiterentwicklung von Programmen angestrebt. Anders als bei der Open Source-Software liegt der Freeware in aller Regel kein Quellcode bei und dem Nutzer werden nicht notwendig besondere Nutzungsbefugnisse eingeräumt3. b) Public Domain-Software

347

Bei der Public Domain-Software handelt es sich um Software, die der Urheber oder ein sonstiger Berechtigter zur allgemeinen Nutzung freigibt, d.h. er gestattet jedermann die unentgeltliche Benutzung und Weitergabe des Programms4. In Deutschland ist hier indes zu beachten, dass ein vollständiger Verzicht auf das Urheberrecht wegen der persönlichkeitsrechtlichen Kom-

1 Jaeger/Metzger, Open Source Software, 3. Aufl. 2011, Rz. 3 mit dem Hinweis darauf, dass freie Software nicht automatisch kostenlos ist. 2 http://www.linfo.org/freeware.html. 3 Jaeger/Metzger, Open Source Software, 3. Aufl. 2011, Rz. 9. 4 Loewenheim/Spindler, in: Schricker/Loewenheim, Urheberrecht, Kommentar, 4. Aufl., vor §§ 69a ff. Rz. 19.

126

Fechtner

Schutz und Realisierung der Software

Rz. 351 A

ponente nicht möglich ist1. Erst nach Ablauf einer Schutzfrist ist ein Übergang für urheberrechtlich geschützte Werke denkbar. c) Shareware Shareware ist eine Art von Software, die mit einer bestimmten Methode ge- 348 werblich vertrieben wird. In aller Regel darf der Benutzer ein Programm für eine bestimmte Zeit kostenlos zur Probe testen, bevor die Benutzung technisch behindert wird, solange nicht gegen Entgeltzahlung eine Freischaltung erfolgt2. Nutzer der Shareware bekommen oftmals ein Vertriebs-, nicht aber ein Bearbeitungsrecht eingeräumt. In der Praxis handelt es bei der Shareware häufig um Demoversionen, die vor dem Kauf einer Vollversion getestet werden. Für die Vollversion muss sodann eine Gebühr entrichtet werden. d) Shared Source-Software „Shared Source“ ist ein Lizenzmodell, das im Jahr 2001 von Microsoft ent- 349 wickelt wurde und mit welchem dem Lizenznehmer Zugang zum Quellcode gewährt wird. Für den kommerziellen Weitervertrieb von Produkten war eine Lizenzgebühr an Microsoft zu zahlen. Zu beachten ist, dass Shared Source-Lizenzen die Anforderungen der Open Source-Definition erfüllen können, dies aber nicht zwangsläufig der Fall ist. Nach der Intention von Microsoft soll den Geschäftskunden die Mitarbeit ermöglicht werden, während gleichzeitig das herkömmliche Geschäftsmodell und die eigenen Immaterialgüterrechte gewahrt bleiben3. 4. „Copyleft“/„Non-Copyleft“-Software Heutzutage existiert eine Vielzahl an Open Source-Software-Lizenzbedin- 350 gungen4. Allen Lizenzbedingungen von Open Source-Software ist im Gegensatz zur proprietären Software gemeinsam, dass sie die uneingeschränkte Weiterverbreitung gestatten; sie erlauben das freie Verbreiten, Untersuchen, Bearbeiten und Kopieren, gestatten die Weiterentwicklung und gewähren so weitgehende Nutzungsrechte. Nichtsdestotrotz gibt es erhebliche Unterschiede, die sich vor allen Dingen durch Einteilung in zwei grobe Subkategorien darlegen lassen. So gibt es einerseits Open Source-Lizenzbedingungen mit strengem „Copyleft“-Effekt: Sofern es sich um ein abgeleitetes Werk handelt, darf eine Weitergabe grundsätzlich nur unter den gleichen Lizenzbedingungen erfolgen.

1 2 3 4

Jaeger/Metzger, Open Source Software, 3. Aufl. 2011, Rz. 8. Marly, Praxishandbuch Softwarerecht, 5. Aufl., 2009, Rz. 883. http://www.microsoft.com/resources/sharedsource/Initiative/Initiative.mspx. Thalhofer, CRi 2008, 129 ff.

Fechtner

127

351

A Rz. 352

Grundlagen

Der Quellcode der abgeleiteten Software muss dabei in jedem Fall offengelegt werden. Die derzeit wohl am weitesten Verbreitete dieser Lizenzen ist die GNU General Public License (GPL), die mittlerweile in der dritten Version veröffentlicht ist1. Der praktische Effekt bei dieser Art von Lizenzierung ist, dass verhindert wird, dass abgeänderte Programme „unfrei“ werden2. In einer abgeschwächten Form gibt es auch Lizenzen mit sog. „beschränkten Copyleft“: Diese erlauben die Kombination der ursprünglichen Software mit Erweiterungen unter abweichenden Lizenzbedingungen3. 352

Demgegenüber ist der Nutzer bei der „Non-Copyleft“-Software frei, Weiterentwicklungen der Software unter eigener Lizenz zu vertreiben; diese muss dabei nicht die Charakteristika von Open Source-Software erfüllen4. Dies hat zur Folge, dass „Non-Copyleft“-Software „unfrei“ werden kann.

353

Im Bereich von Open Source-Software ist derzeit ein Anstieg der Nutzung solcher Lizenzen zu beobachten, die auf eine Copyleft-Klausel verzichten5. Beispiele hierfür sind z.B. die BSD-, Apache- oder MIT-Lizenz. Wenn auch der Pool an GPL-lizensiertem Software-Code weiterhin ansteigt, so ist bereits seit den Jahren 2000/2001 ein stärkerer Anstieg von Open Source-Software ohne Copyleft zu verzeichnen. Zu erklären ist dieser Trend mit einer Zunahme an kommerziell finanzierter Open Source-Softwareentwicklung6. Es beteiligen sich vermehrt große Unternehmen an der Entwicklung von Open Source-Software, die sie durch eigene Produkte erweitern. Diese wiederum werden aus Konkurrenzgründen unter eigene Lizenzen gestellt, was bspw. unter der GPL nur bedingt erlaubt ist7.

1 Weiteres Beispiel ist die Common Public License (CPL). Eine Liste weiterer Lizenzen mit strengem „Copyleft“ ist abrufbar unter http://www.ifross.org/li zenz-center#term-219. 2 Stallmann, Copyleft: Pragmatischer Idealismus, abrufbar unter: http:// www.fsf.org/licensing/essays/pragmatic.html. 3 Beispiel hierfür ist die Mozilla Public License (MPL). 4 Lizenzen ohne Copyleft-Klauseln werden auch „Permissive-Lizenzen“ genannt. 5 Hofmann/Riehle/Kolassa/Mauerer, A Dual Model of Open Source License Growth, 2013, abrufbar unter http://dirkriehle.com/wp-content/uploads/2013/ 04/oss2013.hofmann.pdf. 6 Riehle, The Economic Case for Open Source Foundations, IEEE Computer, Vol. 43, Nr. 1, Januar 2010, S. 86–90 (2010); Corbet, Who wrote 2.6.20?, abrufbar unter http://lwn.net/Articles/222773; Hofmann/Riehle/Kolassa/Mauerer, A Dual Model of Open Source License Growth, 2013, S. 13, abrufbar unter http://dirkriehle. com/wp-content/uploads/2013/04/oss2013.hofmann.pdf. Die Autoren verweisen hier auch auf weitere, noch unpublizierte Forschungsergebnisse, die diese Ansicht stützen würden. 7 Thoma, Der Rückgang der GPL, 18.4.2013 abrufbar unter http://www.golem. de/news/lizenzen-der-rueckgang-der-gpl-1304-98809.html.

128

Fechtner

Schutz und Realisierung der Software

Rz. 357 A

5. Problemstellung: Rechtseinräumung a) Lizenzbedingungen ohne Copyleft-Effekt Die Vorteile der Lizenzbedingungen ohne den sog. Copyleft-Effekt liegen da- 354 rin, dass der Lizenznehmer weitgehend keinen Beschränkungen ausgesetzt ist. Die Rechtseinräumung ist hinsichtlich Bearbeitung und Verbreitung inhaltlich, zeitlich und räumlich unbeschränkt. Es müssen nur bei der Weitergabe regelmäßig die enthaltenen Urheberrechtsvermerke sowie die Lizenzbedingungen und etwaige Haftungs- und Gewährleistungsausschlüsse „weitergegeben“ werden. Bearbeitungen (d.h. Weiterentwicklungen) von Softwarekomponenten, die unter Lizenzbedingungen ohne Copyleft-Effekt stehen, können unter proprietären Lizenzbedingungen an weitere Lizenznehmer verbreitet werden. Daher sind sämtliche Softwarekomponenten, die unter den sog. BSD-arti- 355 gen Lizenzbedingungen stehen, zu bevorzugen, da Bearbeitung und Verbreitung unproblematisch erfolgen können, wenn die (überschaubaren und machbaren) Vorgaben eingehalten werden. Diese Vorgaben sollten allerdings auch beachtet werden, da sich anhand der bisherigen Rechtsprechung gezeigt hat, dass Open Source-Lizenzbedingungen generell als rechtlich durchsetzbar erachtet werden und die in der Literatur zu findende Diskussion der AGB-Rechtswidrigkeit bei diversen Klauseln von den Gerichten weitgehend ignoriert wird. b) Lizenzbedingungen mit Copyleft-Effekt Eines der Hauptprobleme bei der Verwendung von Open Source-Komponen- 356 ten, die unter Lizenzbedingungen mit Copyleft-Effekt fallen, ist der sog. „virale Effekt“. Dieser kann gegebenenfalls dazu führen, dass die „Einbindung“ von Open Source-Komponenten in das proprietär lizenzierte Produkt dazu führt, dass dieses insgesamt unter einer Open Source-Lizenz zu verbreiten ist. Welche Voraussetzungen vorliegen müssen, damit ein viraler Effekt eintritt, 357 ist anhand der einzelnen Versionen der Copyleft-Lizenzen zu beurteilen. Die Bewertung der erforderlichen Voraussetzungen ist in der Literatur sehr unterschiedlich. In Deutschland publizieren zu diesem Thema vor allem einige Autoren, die als starke Befürworter der Open Source-Lizenzbedingungen gelten und die sich dementsprechend vage in ihren Ausführungen halten1. In diversen Standardwerken sind Ausführungen eher neutraler Autoren enthalten, die allerdings immer nur Teilaspekte aufgreifen und leider auch keine komplette Analyse einzelner Open Source-Lizenzbedingungen liefern2. 1 Jaeger/Metzger, Open Source Software, Rechtliche Rahmenbedingungen der Freien Software, 3. Auflage 2011. 2 Auer-Reinsdorff/Kast, in: Auer-Reinsdorff/Conrad, Beck’sches Mandatshandbuch IT-Recht 2011, § 7; Nordmeyer, in: Lehmann/Meents, Handbuch des Fachanwalts Informationstechnologierecht 2011, Kapitel 3.I.

Fechtner

129

A Rz. 358 358

Grundlagen

Am 8.11.2011 erging das erste deutsche Urteil, nämlich des LG Berlin1, in dem der Copyleft-Effekt eine Rolle spielte. Das LG Berlin hält den CopyleftEffekt der GPL v2 bei „Sammelwerken mit einheitlicher Funktionalität“ für nicht zu beanstanden, wenn das Sammelwerk maßgeblich von den Open Source-Bestandteilen abhängt. Die urheberrechtlichen Kernaussagen des Gerichts lassen sich wie folgt zusammenfassen: – Die streitgegenständliche Firmware2 sei ein Sammelwerk i.S.v. § 4 Abs. 1 UrhG, da die Firmware aus zahlreichen einzelnen Dateien bestünde, die die Grundlage der einzelnen Funktionen der Firmware bildeten3. – Für Sammelwerke bestimme Ziffer 2 GPL, dass Werke, die Open SourceSoftware enthielten, als Ganzes den Bedingungen der GPL unterlägen. – Das Sammelwerk würde insgesamt durch die Nutzung nur einzelner Open Source-Bestandteile infiziert. – Diese Infizierung begegne keinen Bedenken, da das Sammelwerk eine einheitliche Funktionalität aufweise und maßgeblich von den Open Source-Bestandteilen abhinge. – Aufgrund der Nutzung von unter der GPL lizenzierten Open Source-Bestandteilen (Linux Kernel) stünden der Klägerin an der Firmware als Ganzes keine urheberrechtlichen Unterlassungsansprüche zu.

1 LG Berlin v. 8.11.2011 – 16 O 255/10. 2 Es handelt sich um eine Fritzbox! mit einer Firmware, die Teile des Linux-Kernels enthält. 3 S.a. LG Berlin v. 8.11.2011 – 16 O 255/10: „… Teil dieses Sammelwerks ist der so genannte Kernel, der auf dem Linux-Betriebssystem basiert und der als so genannte Open-Source-Software den Bedingungen der GNU General Public License (GPL), Version 2, unterliegt. Hiernach ist jedem aufgrund einer eingeräumten Lizenz die Benutzung und Bearbeitung gestattet und jedem Nutzer auferlegt, Dritten dieselben Rechte an seiner Bearbeitung einzuräumen (Wandtke/Bullinger, a.a.O., § 69c UrhG Rz. 74 und 81 m.w.N.). Nach dem so genannten Copyleft-Prinzip des § 3 GPL besteht bei der Inanspruchnahme von Open Source Software-Bestandteilen und einfacher Nutzungsrechte die Verpflichtung, Umgestaltungen bzw. Bearbeitungen ebenfalls der GPL zu unterstellen. Hierdurch soll eine Weiterentwicklung des Betriebssystems Linux und der darauf basierenden Programme der Software sichergestellt werden, wobei die Ergebnisse der Bearbeitungen bzw. Umgestaltungen wiederum der Allgemeinheit frei zugänglich sein sollen. Nach § 4 GPL fallen danach die Nutzungsrechte an die Urheber der Open Source Software zurück. Für Sammelwerke bestimmt § 2 GPL, dass Werke, die Open Source Software enthalten, als Ganzes den Bedingung der GPL unterliegen (Determann, GRUR Int 2006, 645, 648 f. m.w.N.). Hintergrund dieser Regelung ist, dass derjenigen Nutzer, der von den Vorteilen der freien Software in einem maßgeblichen Umfang profitiert, sich auch an den Bedingungen der GPL festhalten lassen muss. Die Infizierung eines Sammelwerks insgesamt bei Verwendung von Open-Source-Software in einzelnen Teilen eines Sammelwerks begegnet keinen Bedenken, da das Sammelwerk eine einheitliche Funktionalität aufweist und maßgeblich von den Open-Source-Bestandteilen abhängt.“

130

Fechtner

Schutz und Realisierung der Software

Rz. 363 A

Wenn auch am Urteil diverse Kritikpunkte geäußert worden sind1 und die 359 Argumente nicht allesamt als überzeugend eingestuft werden können, kann man das Urteil jedoch nicht völlig außer Acht lassen. Dennoch sind folgende Anmerkungen zu bedenken: Zum einen setzt sich das Gericht nicht mit einer möglichen Intransparenz der Copyleft-Lizenzbedingungen auseinander, die nach deutschem Recht zur Unwirksamkeit gem. § 307 BGB führen könnten2. Gerade aber die Bestimmungen der GPL sind in allen Versionen selbst mit Hilfe von Erläuterungen und der deutschen Übersetzungen sehr schwer verständlich. Dies würde eigentlich für eine Intransparenz, d.h. gegen die erforderliche AGBKonformität und mithin auch gegen einen viralen Effekt sprechen. Zum anderen ist zu bedenken, dass der Sachverhalt nicht zu einer umfas- 360 senden Bewertung der Voraussetzungen des viralen Effekts geeignet ist. Gegenstand der Entscheidung des LG Berlin war keine Anwendungssoftware, sondern eine Firmware für DSL Router. Einer der wohl entscheidenden Komponenten dieser Firmware ist der unter GPL v2 lizenzierte Linux Kernel. Die für eine Firmware aufgestellten Grundsätze sind nicht pauschal auf Anwendungssoftware zu übertragen. Im Übrigen bezieht sich das Gericht bei seiner Entscheidung weder auf den konkreten Lizenztext der GPL noch auf den der inoffiziellen deutschen Übersetzung. Hier wäre eine durchgängige Prüfung des konkreten Sachverhalts anhand des konkreten Wortlauts der GPL notwendig gewesen3.

361

Ein weiterer Kritikpunkt ist, dass das Gericht in seinen Entscheidungsgrün- 362 den die Hauptvoraussetzung für den viralen Effekt ignoriert, nämlich die Bearbeitung des unter der GPL lizenzierten Werks. Ziffer 2 der GPL besagt, dass der virale Effekt greift, wenn der Lizenznehmer das Werk bearbeitet. Aus dem Sachverhalt des Urteils ergibt sich zwar, dass die streitgegenständliche Firmware eine Bearbeitung des Linux Kernels enthält, es ist aber nicht feststellbar, wer diese Bearbeitung vorgenommen hat. Wäre sie von der Klägerin in diesem Verfahren vorgenommen worden, hätte das Gericht prüfen müssen, ob die Firmware mit all ihren unterschiedlichen Modulen und Dateien als einheitliches, abgeleitetes Werk i.S.v. Ziffer 2b GPL anzusehen ist und somit vom viralen Effekt erfasst wird. Diese Prüfung erfolgt indes nicht. Ebenfalls nicht einleuchtend ist die Einschätzung des LG Berlin, dass Zif- 363 fer 2 GPL für Sammelwerke bestimme, dass Werke, die Open Source-Software enthielten, als Ganzes den Bedingungen der GPL unterliegen. Aus 1 Schäfer, Kommentar zum Urteil des LG Berlin, Firmware mit OSS-Bestandteilen, K&R 2012, 124 ff. (127). 2 Spindler, Rechtsfragen der Open Source Software, Rechtsgutachten im Auftrag des Verbandes der Softwareindustrie Deutschlands e.V. (VSI), S. 59; Determann, GRUR 2006, 645 (652). 3 Kreutzer, Firmware, Urheberrecht und GPL, CR 2012, 146 (150).

Fechtner

131

A Rz. 364

Grundlagen

dem Wortlaut der GPL ist diese Einschätzung nicht zu entnehmen, weil Ziffer 2 GPL nicht von einer „compilation“, sondern von einem „work based on the program“ spricht. 364

Die Annahme des Gerichts, dass die Firmware ein Sammelwerk sei, wird darüber hinaus nicht begründet. Insbesondere findet eine Subsumtion unter § 4 Abs. 1 UrhG nicht statt1. Der Umstand, dass der Firmware eine modulare Entwicklungsform zugrunde liegt und sie dergestalt aus zahlreichen Dateien besteht, reicht zur Begründung eines Sammelwerks nicht aus2. Vielmehr hätte es dazu einer Auseinandersetzung mit den tatsächlichen technischen Gegebenheiten bedurft.

365

Schließlich ist die pauschale Aussage, dass der Copyleft-Effekt generell gilt, wenn eine Firmware Bestandteile von GPL-Komponenten enthält, nicht zutreffend. Es gibt keinen Grundsatz, dass ein Werk, das GPL-Komponenten enthält, generell durch den Copyleft-Effekt infiziert wird. Hier ist stets eine Einzelfallbetrachtung erforderlich, die das LG Berlin jedoch gerade nicht vornimmt3. In einem jüngeren Verfahren entschied das LG Hamburg, dass Anbieter von GPL-Binärprogrammen passende Quellen bereitstellen müssen4. Nach Ansicht des Gerichts sind die Lizenzbedingungen der GNU General Public License Version 2 nur dann erfüllt, wenn ein Anbieter von Binärprogrammen auch den vollständigen Quellcode bereitstellt. Mit dem Angebot zum Download sei die Software öffentlich zugänglich gemacht worden. Dies hätte nur unter Einhaltung der Lizenzbedingungen der GPL V 2 erfolgen dürfen5. c) OSS-Code in proprietären Projekten

366

Bei der Softwareentwicklung erscheint eine Einbeziehung von nicht proprietären Open Source-Software-Bibliotheken aus wirtschaftlichen Gründen attraktiv. Sie ist rechtlich allerdings nicht unproblematisch, wenn proprietäre Anwendungen auf Open Source-Programmen aufbauen und diese Programme unter einer Copyleft-Lizenz stehen6. Die Abgrenzung von Open Source1 Kreutzer, Firmware, Urheberrecht und GPL, CR 2012, 146: „Für komplexe Computerprogramme, die aus einer Vielzahl einzelner Komponenten und Module bestehen, kommt ein Schutz als Sammelwerk in aller Regel nicht in Betracht. Die Zusammenstellung von Softwarekomponenten zu einem Zweck dient nämlich der Funktionalität des Programms und nicht einer besonderen Auswahl und Anordnung, die den Urheberrechtsschutz nach § 4 Abs. 1 UrhG rechtfertigen würde.“. 2 Schäfer, Kommentar zum Urteil des LG Berlin, Firmware mit OSS-Bestandteilen, K&R 2012, 124 ff. (128). 3 Kreutzer, Firmware, Urheberrecht und GPL, CR 2012, 146. Vgl. Rz. 366 f. 4 LG Hamburg v. 14.6.2013 – 308 O 10/13. 5 LG Hamburg v. 14.6.2013 – 308 O 10/13, S. 5. 6 Vgl. Jaeger, in: Redeker, Handbuch der IT-Verträge, 1.20, Rz. 10.

132

Fechtner

Schutz und Realisierung der Software

Rz. 367 A

Software zu proprietärer Eigenentwicklung, d.h. die Grenzziehung zwischen einer zustimmungsbedürftigen Modifikation eines Open Source-Programms und der Erstellung eines eigenständigen Programms, welches unabhängig von den Voraussetzungen einer Open Source-Lizenz vertrieben werden darf, ist mitunter schwierig. Ob eine Copyleft-Klausel greift, hängt stark von der technischen Ausgestaltung der Einbindung der Open Source-Software in das Endprodukt ab. – Die Verwendung von Entwicklungsumgebungen, die unter Open Source 367 stehen, ist unproblematisch1. Hier wird kein Code in das erstellte Programm übernommen und es findet keine Modifikation statt. D.h., dass das Programmieren von proprietären Programmen unter Einsatz von Open Source-Entwicklungsumgebungen möglich ist, hier greift der Copyleft-Effekt nicht. – Häufig erfolgt auch eine Einbindung von fertigen Komponenten, wo die Software als eigenständiges Subsystem der kommerziellen Anwendung zu sehen ist. Den Einsatz von eigenständigen Open Source-Komponenten, die als Subsysteme verwendet werden, bezeichnet die GPL v3 als sog. „Aggregat“, bei dem der Copy-Left-Effekt auf andere Teile ausdrücklich ausgeschlossen wird2. Die Folge ist, dass sowohl der proprietäre Teil der Software wie auch der nicht proprietäre Teil jeweils eigenständige Werke bleiben. – Problematischer sind die Fälle, in denen eine dynamische Verlinkung zwischen dem proprietären Programm und dem nicht proprietären Open Source-Code vorgenommen wird. Dynamische Verlinkung bedeutet, dass das ausführbare Programm und die Bibliothek, auf die zugegriffen wird, erst im Zeitpunkt der Ausführung des Programms verbunden werden3. Die Open Source-Software wird erst im Moment der Laufzeit der Software in den Code der kommerziellen Anwendung eingebunden. Hier ist eine Abgrenzung zwischen eigenständig unabhängigem Werk und einer dauerhaft verbundenen Einheit schwierig. Theoretisch ist die Klassifizierung als eigenständig ausführbares Werk bei einer sauberen technischen Abgrenzung der Open Source-Komponenten und der kommerziellen Anwendung möglich, etwa durch Nutzung der von der Open Source-Software vorgegebenen Schnittstellen. Es verbleibt indes ein unbestimmbarer Graubereich und das nicht zu unterschätzende Risiko eines möglicherweise durchgreifenden Copyleft-Effekts4. 1 Hoppen/Thalhofer, CR 4/2010, 275 (277). 2 Vgl. GPL v 3 Ziffer 5: „Inclusion of a covered work in an aggregate does not cause this License to apply tot he other parts of the aggregate.“. 3 Heidinger, Nutzung von Open Source Software in proprietären Softwareprojekten – eine Analyse aus urheberrechtlicher Sicht, GI Jahrestagung 2005, S. 121 (123), abrufbar unter http://subs.emis.de/LNI/Proceedings/Proceedings67/GI-Pro ceedings.67-24.pdf. 4 Funk/Zeifang, CR 2007, 617 (620 ff.); Thalhofer, CRi 2008, 129 ff., a.A.: Metzger, Freiheit den Bibliotheken, abrufbar unter www.ifross.de/ifross_html/art9.html.

Fechtner

133

A Rz. 368

Grundlagen

– Wird der Open Source-Code statisch verlinkt, liegt eine noch engere Integration vor. Bei statischen Verlinkungen der unter der GPL lizenzierten Programmbibliothek und proprietärer Software wird man davon ausgehen müssen, dass der Copyleft-Effekt greift1. Differenzierter betrachtet werden kann der Fall, wenn die Open Source-Programmbibliothek unter der GNU Lesser General Public (LGPL) steht: Wird hier die Einhaltung von Ziffer 4d der LGPL v3 sichergestellt, d.h. das Programm greift mit einer vorhandenen Kopie der Bibliothek zur Laufzeit zu und läuft auch noch mit einer modifizierten Version der Bibliothek, so wird der Source Code einer Bibliothek, die der LGPL unterliegt, unverändert eingebunden. Anders ist der Fall zu bewerten, wenn die LGPL Open Source-Bibliothek modifiziert wird. Hier unterliegen jedenfalls die Modifikationen dem Copyleft2. – Werden Quelltext-Fragmente in den Quelltext der kommerziellen Anwendung eingebunden, so kann nicht mehr abgegrenzt werden zwischen Funktionalitäten der kommerziellen Anwendung und solchen des Open Source-Quelltexts. Das hat zur Folge, dass der Copyleft-Effekt voll eingreift. 6. Problemstellung: Vertragstypen, Gewährleistung, Haftung 368

Nicht nur dort, wo Open Source-Software erstellt oder angepasst wird, stellt sich die Frage nach der Gewährleistung und der Haftung, sondern auch dort, wo Nutzungsrechte an der Software eingeräumt werden oder wo Service und Support geleistet wird. Dabei können – abhängig von der Ausgestaltung der vertraglichen Beziehungen – Haftung und Gewährleistung unterschiedlichen gesetzlichen Maßstäben unterliegen3. Maßgeblich ist zum einen die vereinbarte Beschaffenheit des Vertragsprodukts. Hier wird man etwa bei „Entwicklerversionen“ andere Maßstäbe anlegen als bei „Endanwenderversionen“. Weiterhin entscheidend ist die vertragstypologische Einordnung des Vertrags. So gelten etwa bei unentgeltlichen Verträgen weitreichende Gewährleistungs- und Haftungserleichterungen, während dies bei entgeltlichen Verträgen nicht der Fall ist. Natürlich können abweichend von gesetzlichen Regelungen die Parteien innerhalb bestimmter Grenzen Abreden über den Umfang der Gewährleistung treffen. Anzuraten sind solche Abreden vor allen Dingen da, wo der Umfang bestehender Pflichten umstritten ist, wie bspw. bei der individuellen Herstellung und Anpassung von Open Source-Software. 1 Es liegt insofern eine „modification“ i.S.d. GPL vor, vgl. dazu auch Jaeger/Metzger, Open Source Software, Rechtliche Rahmenbedingungen der Freien Software, 3. Aufl. 2011, S. 46 f. 2 Hoppen/Thalhofer, CR 4/2010, 275 (280). 3 Die „Gewährleistung“ erfasst die Vertragsgemäßheit des Programms, während man mit Haftung das Einstehen müssen für Schäden, die sich an sonstigen Rechtsgütern beim Vertragspartner ergeben, bezeichnet sowie auch jedes sonstige außervertragliche Einstehen müssen.

134

Fechtner

Schutz und Realisierung der Software

Rz. 372 A

Werden allerdings hier die zulässigen Grenzen überschritten, hat dies zur 369 Folge, dass entsprechende Gewährleistungsklauseln für nichtig eingestuft werden. Hier gibt es auch keine geltungserhaltende Reduktion, d.h. an die Stelle der nichtigen Klausel tritt die gesetzliche Regelung. So sind vollständige Gewährleistungsausschlüsse nichtig, wie sie etwa in manchen u.s.amerikanischen Open Source-Lizenzen vorgesehen sind. Neben der vertraglichen kann auch die außervertragliche Haftung bedeut- 370 sam sein. Zu nennen ist hier insbesondere der Bereich der Produkt- und Produzentenhaftung. Sowohl bei der vertraglichen als auch bei der außervertraglichen Haftung 371 ist zudem zu berücksichtigen, dass Ansprüche wegen Mitverschulden ganz entfallen (wegen „überwiegendem“ Mitverschulden) oder zumindest begrenzt sein können. In der Praxis häufig ist dabei die Haftung für den Verlust von Datenbeständen; eine regelmäßige, zuverlässige und umfassende Sicherung muss demzufolge gewährleistet werden. Über die Frage, ob ein Betreiber einer Open Source-Plattform jede Änderung auf Rechtmäßigkeit überprüfen muss, hat derzeit das Landgericht Hamburg zu entscheiden1. 7. Problemstellung: Patentrecht Im Hinblick auf die Entwicklung und Distribution von Open Source-Soft- 372 ware werden häufig Bedenken laut, dass eine Patentvergabe im Bereich von Computerprogrammen ein Risiko darstelle2. Folgende Punkte werden dabei als problematisch erachtet: – Zum einen ist es möglich, dass Dritte ein Patent auf eine Erfindung anmelden, die bereits im Bereich von Open Source existiert und nichtsdestotrotz ein Patent an den Dritten erteilt wird. – Je mehr Patente angemeldet werden, desto größer ist das Risiko, dass Ersteller und Verwender von Open Source Codes solche Patente verletzen. – Außerdem besteht bei vermehrter Patentierung von Open Source-Software die Gefahr, dass Patente von Rechtsinhabern von Open Source-Entwicklern angemeldet werden und mit diesen Patenten Druck ausgeübt wird, Software unter restriktiveren Bedingungen zu vertreiben3. Hierbei wird primär befürchtet, dass Bearbeiter von Open Source-Software Paten1 Das LG Hamburg untersagte am 25.4.2013 im Wege einer einstweiligen Verfügung den Vertrieb einer Version des Open-Source-Download-Managers JDownloader 2, Az 310 O 144/13. Der Verhandlungstermin ist auf den 12.9.2013 angesetzt. 2 So wird etwa in der Einleitung zum Lizenztext der GPL ausgeführt: „Finally, any free program is threatened constantly by software patents.“ 3 Vgl. Jaeger/Schulz, Gutachten zu ausgewählten rechtlichen Aspekten der Open Source Software, Februar 2005, S. 15, abrufbar unter http://www.ifross.org/if ross_html/art47.pdf.

Fechtner

135

A Rz. 373

Grundlagen

te auf solche Verfahren anmelden, die sie in Weiterentwicklungen der Software implementiert haben. 373

Dagegen ist indes anzumerken, dass der Patentinhaber bei Weitergabe eines weiterentwickelten Programms zugleich sein Patent lizenzieren muss1.

374

Im Übrigen sind die angesprochenen Befürchtungen nicht open-source-spezifisch und lassen sich durch eine gründliche Patentrecherche zum größten Teil vermeiden. Möglicherweise besteht das Problem bei Open Source-Software, dass der aktuelle Stand der Technik (noch) nicht ausreichend dokumentiert wurde. Allerdings ist dabei einzuwenden, dass bereits heute schon vielfach Funktionalitäten in Datenbanken eingetragen und CVS-Systeme eingesetzt werden2. 8. Fazit

375

Trotz umfangreicher Literatur sind im Open Source-Umfeld nach wie vor viele Fragen offen und werden kontrovers diskutiert. Es ist leider auch so, dass in Literatur und Rechtsprechung die Bedingungen teilweise nur dürftig analysiert werden. Oftmals werden Probleme andiskutiert (insbesondere der virale Effekt bei GPL und LGPL), wirkliche Lösungen werden jedoch nicht angeboten. Die Vielzahl der unterschiedlichen Meinungen kann allerdings vielfach schon aus Gründen des Umfangs nicht erschöpfend dargestellt werden. Da es bislang immer noch verhältnismäßig wenig, vor allen Dingen noch keine höchstrichterliche Rechtsprechung gibt und die vorliegende Rechtsprechung sich mit Detailfragen nicht (bzw. nur sehr selten) auseinandersetzt, ist es angeraten, das Thema regelmäßig wieder aufzugreifen, da zu erwarten ist, dass weitere Urteile ergehen werden, die durchaus auch neue Aspekte und Risiken aufwerfen können.

V. Durchsetzung 1. Das Durchsetzungsproblem 376

Der Softwareschutz sowohl durch Urheberrecht wie auch durch Patentierung wird breit diskutiert. Der Schutz nutzt aber nur, wenn er auch durchsetzbar ist. Die Durchsetzung wiederum ist schwierig, weil selten die Verletzung in einer identischen oder plagierten geschützten Benutzeroberfläche besteht, sondern häufiger in gleichen oder ähnlichen Funktionen. Dann stellt sich die Frage, ob der Ersteller den gleichen oder im Wesentlichen gleichen Quellcode, an dem er etwa exklusive Rechte an einen früheren Auftraggeber eingeräumt hat, auch für den Zweiten verwendet hat. Das 1 Jaeger/Schulz, Gutachten zu ausgewählten rechtlichen Aspekten der Open Source Software, Februar 2005, S. 16, abrufbar unter http://www.ifross.org/if ross_html/art47.pdf. 2 Jaeger/Metzger, Open Source Software, Rechtliche Rahmenbedingungen der Freien Software, 3. Aufl. 2011, S. 253.

136

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 378 A

wäre dann seitens des Erstellers und seitens des ladenden zweiten Auftraggebers urheberrechtliche Vervielfältigung in identischer oder möglicherweise unfrei bearbeiteter Form. Bei patentrechtlichem Schutz könnte eine Verletzung durch Herstellen beim Ersteller und Gebrauchen beim zweiten Auftraggeber im Wortlaut des Patentanspruchs oder in äquivalenter Form vorliegen. Nach § 14 PatG, Art. 69 EPÜ wird der Schutzbereich eines Patents durch den Inhalt der Patentansprüche bestimmt, ausgelegt aus der Sicht des EDV-Fachmanns durch Beschreibung und Zeichnungen. Dabei ist nach dem Auslegungsprotokoll zu Art. 69 EPÜ weder einerseits nur auf den genauen Wortlaut noch andererseits auf ein nur aus Beschreibung und Zeichnungen ermitteltes Schutzbegehren abzustellen, sondern die Auslegung soll die Mitte halten mit angemessenem Schutz für den Patentinhaber bei ausreichender Rechtssicherheit für Dritte. Daher bezieht die deutsche Rechtsprechung über den ausgelegten Wortlaut hinaus auch äquivalente Abwandlungen in den Schutzbereich ein, also Abwandlungen die gleichwirkend sind, und die der am ausgelegten Anspruchswortlaut orientierte Fachmann als naheliegend auffinden kann1. Um aber beurteilen zu können, ob sich der urheberrechtliche oder pa- 377 tentrechtliche Schutz der ersten Software auf die zweite erstreckt, muss man den gegnerischen Quellcode kennen2. Man muss ihn auch deswegen kennen, um überhaupt einen bestimmten Klageantrag auf Unterlassung, Schadensfeststellung und Auskunft über den Umfang der Verletzungshandlungen formulieren zu können3. Denn es reicht für einen bestimmten Klageantrag weder, Dateibezeichnungen im Antrag zu nennen, noch, wenn ein abgewandeltes Programm angegriffen wird, eine Kopie des eigenen Programms beizugeben. Der gegnerische Quellcode ist aber des Gegners wohl gehütetes Betriebsgeheimnis. Damit stellt sich seltener im allgemeinen Patentrecht, wohl aber dominierend bei der Softwareverletzung das Problem, wie eine verborgene, vermutete Verletzung aufgeklärt werden kann. 2. Ausländisches Recht In den USA wird das Verfahren durch eine ziemlich allgemein gehaltene 378 complaint eingeleitet, die nur den Streitgegenstand umreißt, z.B. das gegnerische Programm seinem Marktnamen Y nach benennt und es als copy 1 BGH v. 29.4.1986 – X ZR 28/85 – Formstein, MDR 1986, 1023 = GRUR 1986, 803; BGH v. 12.3.2002 – X ZR 43/01 – Kunststoffrohrteil, GRUR 2002, 511; BGH v. 12.3.2002 – X ZR168/00 – Schneidmesser I, GRUR 2002, 515; BGH v. 12.3.2002 – X ZR 135/01 – Schneidmesser II, GRUR 2002, 519; BGH v. 12.3.2002 – X ZB 12/00 – Custodiol I, GRUR 2002, 523; BGH v. 12.3.2002 – X ZR 73/01 – Custodiol II, GRUR 2002, 527. 2 KG v. 17.3.2010 – 24 U 117/08 – Binärcode-Vergleich, CR 2010, 424: Nur ein Binärcodevergleich reicht nicht zur Beurteilung, ob urheberrechtsfähige Teile vervielfältigt sind. 3 BGH v. 23.1.2003 – I ZR 18/00 – Innungsprogramm, MDR 2003, 1306 = CR 2003, 800 = GRUR 2003, 786.

M. Brandi-Dohrn

137

A Rz. 379

Grundlagen

right-Verletzung des eigenen Programms X oder des Softwarepatents X1 bezeichnet. Anders als in Deutschland löst die einfache Klage noch keine besonderen Gebühren und Kosten aus. Nach einer ebenso kurzen Beantwortung schließt sich die pretrial discovery an, in der jede Partei von der anderen Unterlagen verlangen kann (production of documents), von der Gegenseite Aufklärung fordern kann (interrogatories) und Angestellte der Gegenseite vernehmen kann (depositions). Mittels der Discovery kann Vorlage des gegnerischen Quellcodes verlangt werden. Der Gegner kann für diesen als sein Betriebsgeheimnis bei Gericht eine protective order erwirken, dass der Quellcode vertraulich zu behandeln ist (confidentiality order), z.B. nur bestimmten zur Verschwiegenheit verpflichteten Personen zugänglich gemacht werden darf. Nach dieser umfassenden Sachverhaltsermittlung beginnt erst der eigentliche Prozess vor Gericht, das Trial, und endet mit einem Jury-Urteil oder einem summary judgement allein durch den Richter1. Das US-Recht bietet damit weitgehende aber auch kostspielige Aufklärungsmöglichkeiten vor Beginn des eigentlichen Verfahrens. 379

In Frankreich, und ähnlich in Belgien und Italien, gibt es das Verfahren der saisie contrefaçon. Die saisie contrefaçon geht der Klage voraus und dient sowohl der Erforschung, ob eine Verletzung vorliegt wie auch der Beweissicherstellung. Auf der bloßen Grundlage der formalen Rechtsinhaberschaft wird sie vom Rechtsinhaber beim Gerichtspräsidenten des Landgerichts (Tribunal de Grande Instance) beantragt und von ihm ohne Nachprüfung einer Verletzungswahrscheinlichkeit und ohne Anhörung des Gegners bewilligt. Es handelt sich also um ein reines ex parte-Verfahren, mit dem der Gegner überrascht wird, bevor er etwas beiseite schaffen kann. Der Kläger oder sein Patentanwalt begibt sich mit dem Gerichtsbeschluss und mit einem Gerichtsvollzieher, huissier de justice, und zweckmäßig einem EDVFachmann, in die Geschäftsräume des Gegners. Dort kann der huissier die geeigneten Ermittlungen anstellen und Angestellte befragen, um den Verletzungssachverhalt aufzuklären, z.B. den Quellcode und andere verletzungsrelevante Dokumente zu beschlagnahmen. Auch Muster können beschlagnahmt werden. Dokumente werden zwei Mal kopiert, einmal für die Gerichtsakten, einmal für den Antragsteller. Ein Vertraulichkeitsschutz ist kaum gewährleistet. Allerdings kann der Antragsgegner während der Durchsuchung den diensthabenden Richter versuchen anzurufen und eine Beschränkung oder Aushändigung nur an einen unabhängigen Experten erwirken. Die Saisie wird unverwertbar und der Antragsteller schadensersatzpflichtig, wenn er den Hauptsacheprozess danach nicht binnen 15 Tagen (in Belgien einen Monat) einleitet. Die saisie contrefaçon ist die übliche Einleitung eines französischen Verletzungsverfahrens2. 1 Vgl. dazu Karger, Beweisermittlung im deutschen und amerikanischen Softwareverletzungsprozess, S. 231 ff.; Mayer/Schlenk, Das US-Patent (4. Aufl. 2012), Rz. 951 ff. 2 Vgl. zur saisie contrefaçon: Binn/Dupuis-Latour, Patentverletzungsverfahren in Frankreich, VPP-Rundbrief 1998, 72; Stauder, GRUR Int. 1978, 230; Treichel,

138

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 381 A

In England ist die Aufklärung ähnlich wie in den USA: nach einer Klage, die 380 nur knapp den Streitgegenstand umreißt und die technischen Merkmale des zu unterlassenden Programms nicht bezeichnen muss, und nach einer Phase des unstreitig Stellens auf Anforderung, schließt sich eine disclosure an, in der jede Partei von der anderen relevante Unterlagen anfordern kann. Das ist seit 1998 detailliert geregelt in Rule 31 der Civil Procedurs Rules (CPR)1. Anders als in den USA gibt es aber keine pretrial depositions, also keine vorherige Zeugeneinvernahmen. Bei geheimhaltungsbedürftigen Unterlagen, wie z.B. dem Quellcode, kann das Gericht auf Antrag der betroffenen Partei anordnen, dass er nur den Mitgliedern eines Vertraulichkeitsclubs zugänglich gemacht wird, etwa den zur Verschwiegenheit verpflichteten Anwälten und Parteigutachtern. Anders als in Deutschland werden Gutachter nicht vom Gericht bestellt, sondern jede Partei bietet ihre eigenen Gutachter auf: diese erstellen ein schriftliches Gutachten, das der Gegenseite zwei Monate vor der Verhandlung zugänglich gemacht wird. Dann schließt sich vor der Verhandlung eine Phase des Austauschs von Gutachtensergänzungen an, in denen die Gutachter wechselseitig zu den im anderen Gutachten besonders relevanten Punkten Stellung nehmen. Der Barrister der Gegenpartei kann dann in der mündlichen Verhandlung den/die Gutachter der anderen Partei kritisch befragen, quasi in ein einseitiges Kreuzverhör nehmen. Die gewöhnlich einige Tage dauernde Verhandlung wird durch sog. „skeleton arguments“ der Barrister kurz vorher vorbereitet. Das sind heutzutage in komplexen Angelegenheiten ausführliche, argumentative Schriftsätze. Außerdem hat der Richter natürlich alle zwischen den Parteien ausgetauschten Dokumente, Gutachten und Gutachtensergänzungen. Vorprozessual gibt es außerdem, mit der saisie contrefaçon entfernt verwandt 381 aber längst nicht so häufig praktiziert, die Anton Piller Order2. Sie ist eine vorprozessuale Durchsuchungs- und Beschlagnahmeanordnung über rechtsverletzende Gegenstände oder Schriftstücke. Sie wird naturgemäß angeordnet ohne vorherige Anhörung des Gegners, setzt aber im Unterschied zur französischen saisie contrefaçon einen prima facie überzeugenden Verletzungsfall voraus, einen ohne die Anordnung eintretenden schweren Schaden für den Antragsteller und eindeutigen Beweis, dass der Antragsgegner im Besitz inkriminierender Gegenstände oder Dokumente ist mit der Wahrscheinlichkeit, dass er sie vernichtet oder beiseite schafft. Der Betroffene kann dem Antragsteller zwar den Zutritt verweigern, muss das aber dann in Die französische Saisie-contrefaçon im europäischen Patentverletzungsprozess, GRUR Int. 2001, 690; Werner, Beweissicherungsverfahren bei Schutzrechtsverletzungen in Belgien, Frankreich und Deutschland, VPP-Rundbrief 2003, 76; Veron, Der Patentverletzungsprozess in Frankreich, ein Vergleich mit der Rechtslage in Deutschland, Mitt. 2002, 386. 1 Vgl. Enchelmaier, Die Durchsetzung von Immaterialgüterrechten vs. Schutz von Betriebsgeheimnissen im englischen Zivilprozessrecht, GRUR Int. 2012, 503 mit detaillierten Zitaten der CPR. 2 Die Bezeichnung kommt aus dem Fall Anton Piller KG v. Manufacturing Process Ltd, (1976) R.P.C. 719; vgl. dazu Götting, GRUR Int. 1988, 729.

M. Brandi-Dohrn

139

A Rz. 382

Grundlagen

einem Verfahren wegen contempt of court rechtfertigen. Außerdem kann der Richter Schutzmaßnahmen verfügen, wie z.B. die Aushändigung nur an einen Sachverständigen1. 3. Deutsches Recht bis 2002 382

Im deutschen Recht gab es traditionell keinen verfahrensrechtlichen Offenlegungsanspruch über die prozessuale Wahrheitspflicht und gewisse, begrenzte prozessuale Mitwirkungspflichten hinaus. Einen materiell-rechtlichen Besichtigungsanspruch bejahte der BGH jedoch im Grundsatz aus § 809 BGB: „Wer gegen den Besitzer einer Sache einen Anspruch in Ansehung der Sache hat oder sich Gewissheit verschaffen will, ob ihm ein solcher Anspruch zusteht, kann, wenn die Besichtigung der Sache aus diesem Grund für ihn von Interesse ist, verlangen, dass der Besitzer ihm die Sache zu Besichtigung vorlegt oder die Besichtigung gestattet.“

383

Diesen Besichtigungsanspruch hatte der BGH in der Druckbalkenentscheidung2 bis zur Unbrauchbarkeit eingeengt: es muss eine sehr hohe Verletzungswahrscheinlichkeit dargetan sein, der Sachverständige darf keine Substanzeingriffe vornehmen, insbesondere nicht Teile aus- und einbauen oder die Vorrichtung in Betrieb setzen, und er darf nur eine bestimmte Verletzungsbehauptung verifizieren nicht aber begutachten, ob eine nicht konkret benannte abweichende Ausführungsform vorliegt und diese eine äquivalente Verletzung darstellt. Das Verfahren lief zeitraubend in drei Verfahrenszügen ab: einstweilige Verfügung auf Beschlagnahme, dazu Hauptsacheprozess über Gutachtensfreigabe, dann erst Hauptsacheverletzungsprozess. Dieser Zeitaufwand und die Einschränkungen des Besichtigungsanspruchs sind überwiegend kritisiert worden3.

1 Stauder, GRUR Int. 1982, 226; Enchelmaier, GRUR Int. 2012, 503. 2 Druckbalkenverfahren über die innere Ausgestaltung einer ausgestellten, vermutlich patentverletzenden Holzbearbeitungsmaschine: OLG Düsseldorf v. 17.8.1981 – 2 U 102/81 – Besichtigungsanspruch I, GRUR 1983, 741: direkter Besichtigungsanspruch durch den Patentinhaber selbst abgelehnt; OLG Düsseldorf v. 8.4.1982 – 2 U 176/81 – Besichtigungsanspruch II, MDR 1982, 671 = GRUR 1983, 745: Besichtigung und Verletzungsgutachten durch einen zur Verschwiegenheit verpflichteten Sachverständigen gebilligt; BGH v. 8.1.1985 – X ZR 18/84 – Druckbalken, MDR 1985, 579 = BGH GRUR 1985, 518 = CR 1985, 77 = NJWRR 1986, 480: OLG Besichtigungsanspruch II aufgehoben wegen zu weitgehender Untersuchungsbefugnisse für den Sachverständigen. 3 Bork, NJW 1997, 1665; M. Brandi-Dohrn, CR 1985, 67 und CR 1987, 835; Fritze/ Stauder, Bericht der deutschen Landesgruppe der AIPPI in GRUR Int. 1986, 342; Karger, Beweisermittlung im deutschen und amerikanischen Softwareverletzungsprozess, S. 138 ff.; Stürner/Stadler, JZ 1987, 1101; Kröger/Bausch, GRUR 1997, 321; Borck, NJW 1997, 1665.

140

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 384 A

4. Wandlungen im deutschen Recht ab 2002 1994 wurde das TRIPS-Abkommen abgeschlossen1. Es sieht in Art. 43 384 Abs. 1 vor: „Hat eine Partei alle vernünftigerweise verfügbaren Beweismittel zur hinreichenden Begründung ihrer Ansprüche vorgelegt und rechtserhebliche Beweismittel zur Begründung ihrer Ansprüche, die sich in der Verfügungsgewalt der gegnerischen Partei befinden, bezeichnet, so sind die Gerichte befugt anzuordnen, dass diese Beweismittel der gegnerischen Partei vorgelegt werden, gegebenenfalls unter Bedingungen, die den Schutz vertraulicher Informationen gewährleisten.“

und Art. 50 Abs. 1 lit. b) TRIPS: (1) Die Gerichte sind befugt, schnelle und wirksame einstweilige Maßnahmen anzuordnen, a) … b) um einschlägige Beweise hinsichtlich der behaupteten Rechtsverletzung zu sichern. (2) Die Gerichte sind befugt, gegebenenfalls einstweilige Maßnahmen ohne Anhörung der anderen Partei zu treffen, insbesondere dann, wenn durch eine Verzögerung dem Rechtsinhaber wahrscheinlich ein nicht wiedergutzumachender Schaden entstünde, oder wenn nachweislich die Gefahr besteht, dass Beweise vernichtet werden. (3) Die Gerichte sind befugt, dem Antragsteller aufzuerlegen, alle vernünftigerweise verfügbaren Beweise vorzulegen, um sich mit ausreichender Gewissheit davon überzeugen zu können, dass der Antragsteller der Rechtsinhaber ist und dass das Recht des Antragstellers verletzt wird oder dass eine solche Verletzung droht, und anzuordnen, dass der Antragsteller eine Kaution zu stellen oder eine entsprechende Sicherheit zu leisten hat, die ausreicht, um den Antragsgegner zu schützen und um einem Missbrauch vorzubeugen. (4) Wenn einstweilige Maßnahmen ohne Anhörung der anderen Partei getroffen wurden, sind die betroffenen Parteien spätestens unverzüglich nach der Vollziehung der Maßnahmen davon in Kenntnis zu setzen. Auf Antrag des Antragsgegners findet eine Prüfung, die das Recht zur Stellungnahme einschließt, mit dem Ziel statt, innerhalb einer angemessenen Frist nach der Mitteilung der Maßnahme zu entscheiden, ob diese abgeändert, aufgehoben oder bestätigt werden soll. (5) … (6) Unbeschadet des Absatzes 4 werden auf Grund der Absätze 1 und 2 ergriffene Maßnahmen auf Antrag des Antragsgegners aufgehoben oder auf andere Weise außer Kraft gesetzt, wenn das Verfahren, das zu einer Sachentscheidung führt, nicht innerhalb einer angemessenen Frist eingeleitet wird, die entweder von dem die Maßnahme anordnenden Gericht festgelegt wird, sofern dies nach dem Recht des Mitgliedsstaats zulässig ist, oder, wenn es nicht zu einer solchen Festlegung kommt, 20 Arbeitstage oder 31 Kalendertage, wobei der längere der beiden Zeiträume zählt, nicht überschreitet. (7) Schadensersatz bei Aufhebung. 1 Agreement on Trade Related Aspects of Intellectual Property (TRIPS) – Übereinkommen über handelsbezogene Aspekte der Rechte des geistigen Eigentums, BGBl. 1994 II, 1730 = ABl. EG 1994 L 336/221 = Beck’sche Textausgabe Gewerblicher Rechtsschutz, vor 5001.1.

M. Brandi-Dohrn

141

A Rz. 385

Grundlagen

TRIPS gibt ohne Umsetzung dem Einzelnen keine unmittelbaren Rechte. Das nationale Recht ist jedoch im Licht von TRIPS auszulegen, und das gilt EG-rechtlich auf allen TRIPS-Gebieten, auf denen auch die EG als TRIPSPartei Rechtsakte erlassen hat1. Im Gegensatz zur Literatur2 sah der deutsche Gesetzgeber keinen Umsetzungsbedarf3. Er schuf jedoch im Zuge der ZPO-Reform zum 1.1.2002 erstmals eine eigenständige prozessuale Vorlegungsvorschrift in § 142 ZPO: „(1) Das Gericht kann anordnen, dass eine Partei oder ein Dritter die in ihrem oder seinem Besitz befindlichen Urkunden oder sonstigen Unterlagen, auf die sich eine Partei bezogen hat, vorlegt. Das Gericht kann hierfür eine Frist setzen sowie anordnen, dass die vorgelegten Unterlagen während einer von ihm zu bestimmenden Zeit auf der Geschäftsstelle verbleiben. (2) Dritte sind zur Vorlegung nicht verpflichtet, soweit ihnen dies nicht zumutbar ist oder sie zur Zeugnisverweigerung gemäß den §§ 383 bis 385 berechtigt sind …“.

„Unterlagen“ über „Urkunden“ hinaus kann auch ein Datenträger mit dem Quellcode und kann auch die Dokumentation dazu sein. Die Vorschrift ist eine Kann-Bestimmung, aber der BGH hat das Ermessen ausgerichtet an den Vorschriften von TRIPS und der Durchsetzungsrichtlinie zur Vorlage von Dokumenten4. § 142 ZPO greift primär im anhängigen Verfahren, für das in Deutschland mit Eingangsgebühren und bestimmtem Antrag die Anforderungen vergleichsweise hoch sind. Eine vorprozessuale Ermittlungsmöglichkeit blieb daher notwendig. 385

Die BGH-Entscheidung Faxkarte5 hat, auch wenn sie aktuell die innerprozessuale Vorlegungspflicht betraf, gegenüber „Druckbalken“ Erleichterung geschaffen. Die hohe Verletzungswahrscheinlichkeit wurde auf eine „gewisse Verletzungswahrscheinlichkeit“ herabgestuft. Die Wahrung berechtigter Betriebsgeheimnisse führt nicht zu einer Heraufsetzung der Stufe der Verletzungswahrscheinlichkeit sondern zur Einschaltung eines zur Geheimhaltung verpflichteten Dritten. Diese Lockerung ist auch mit einer 1 EuGH v. 16.6.1998 – Rs. C-53/96 – Hermès, Slg. 1998 I 3606, NJW 1999, 2103 = GRUR Int. 1998, 697; EuGH v. 14.12.2000 – Rs. C 300/98 u. C 392/98 – Dior, Slg. 2000 I 307 = GRUR 2001, 235; EuGH v. 13.9.2001 – Rs 89/99 – Route 66, GRUR Int. 2002, 41, jeweils zur verneinten unmittelbaren Anwendbarkeit von Art. 50 Abs. 6 TRIPS – automatische Hauptsacheklagefrist. 2 Dreier, TRIPS und die Durchsetzung der Rechte des geistigen Eigentums, GRUR Int. 1996, 205 (217); Fritze, Durchsetzung von Rechten des geistigen Eigentums, Verfahren und Sanktionen bei einer Verletzung von Patenten und Marken (TRIPS und das deutsche Recht) Bericht für die deutsche Landesgruppe der AIPPI, GRUR Int. 1997, 143 (145). 3 BT-Drucks. 1994, 12/7655 (neu). 4 BGH v. 1.8.2006 – X ZR 114/03 – Restschadstoffentfernung, GRUR 2006, 962. 5 BGH v. 2.5.2002 – I ZR 45/01 – Faxkarte, MDR 2003, 167 = CR 2002, 791 = GRUR 2002, 1046 – zum Vorlageanspruch nach § 809 BGB für den zugrunde liegenden Quellcode bei Verletzungsverdacht, aufhebend zu OLG Hamburg v. 11.1.2001 – 3 U 120/00, CR 2001, 434, das einen Vorlageanspruch mangels hinreichender Verletzungswahrscheinlichkeit verneint hatte; BGH v. 18.12.2012 – X ZR 7/12 – Rohrmuffe, GRUR 2013, 316.

142

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 386 A

TRIPS-konformen Auslegung begründet. Die Einschränkungen hinsichtlich der Substanzeingriffe werden kritisch vermerkt, brauchten aber letztlich nicht entschieden zu werden. Das Urteil ist in der Literatur als Signal eines Aufbruchs in eine bessere und Europa-konformere Richtung gewürdigt worden1. Unverändert ist das Erfordernis geblieben, dass die Besichtigung nur das letzte fehlende Glied einer ansonsten lückenlosen Beweiskette für den Klageerfolg darstellen darf. Daran fehlte es dann letztlich im Fall „Faxkarte“, weil die Schadensersatzansprüche rechtskräftig abgewiesen waren und für die Unterlassungsansprüche keine Wiederholungs- oder Begehungsgefahr mehr bestand2. 5. Durchsetzungsrichtlinie und Düsseldorfer Praxis Die EG hat am 29.4.2004 die Richtlinie 2004/48/EG zur Durchsetzung der Rechte des geistigen Eigentums erlassen3. Sie ist durch das Gesetz zur Verbesserung der Durchsetzung von Rechten des geistigen Eigentums vom 7.7.2008, in Kraft ab 1.9.2008, in Deutschland umgesetzt worden. Art. 6 und 7 der Durchsetzungsrichtlinie sehen vor: Artikel 6 Beweise (1) Die Mitgliedstaaten stellen sicher, dass die zuständigen Gerichte auf Antrag einer Partei, die alle vernünftigerweise verfügbaren Beweismittel zur hinreichenden Begründung ihrer Ansprüche vorgelegt und die in der Verfügungsgewalt der gegnerischen Partei befindlichen Beweismittel zur Begründung ihrer Ansprüche bezeichnet hat, die Vorlage dieser Beweismittel durch die gegnerische Partei anordnen können, sofern der Schutz vertraulicher Informationen gewährleistet wird. Für die Zwecke dieses Absatzes können die Mitgliedstaaten vorsehen, dass eine angemessen große Auswahl aus einer erheblichen Anzahl von Kopien eines Werks oder eines anderen geschützten Gegenstands von den zuständigen Gerichten als glaubhafter Nachweis angesehen wird. (2) Im Falle einer in gewerblichem Ausmaß begangenen Rechtsverletzung räumen die Mitgliedstaaten den zuständigen Gerichten unter den gleichen Voraussetzungen die Möglichkeit ein, in geeigneten Fällen auf Antrag einer Partei die Übermittlung von in der Verfügungsgewalt der gegnerischen Partei befindlichen Bank-, Finanz- oder Handelsunterlagen anzuordnen, sofern der Schutz vertraulicher Informationen gewährleistet wird. Artikel 7 Maßnahmen zur Beweissicherung (1) Die Mitgliedstaaten stellen sicher, dass die zuständigen Gerichte, selbst vor Einleitung eines Verfahrens in der Sache, auf Antrag einer Partei, die alle vernünftigerweise verfügbaren Beweismittel zur Begründung ihrer Ansprüche, dass ihre Rechte an geistigem Eigentum verletzt worden sind oder verletzt zu werden drohen, vorgelegt hat, schnelle und wirksame einstweilige Maßnahmen zur Sicherung der rechtserheblichen Beweismittel hinsichtlich der behaupteten Verletzung anordnen 1 Tilmann/Schreibauer, GRUR 2002, 1015; kritisch Schneider, CR 2003, 1. 2 OLG Hamburg v. 29.4.2004 – 3 U 120/00, CR 2005, 558 in vierter Instanz. 3 Richtlinie 2004/48/EG des europäischen Parlaments und des Rates v. 29.4.2004 zur Durchsetzung der Rechte des geistigen Eigentums, ABl. EG L 2.6.2004 S. 195/16 (berichtigte Fassung) = GRUR Int. 2004, 615.

M. Brandi-Dohrn

143

386

A Rz. 387

Grundlagen

können, sofern der Schutz vertraulicher Informationen gewährleistet wird. Derartige Maßnahmen können die ausführliche Beschreibung mit oder ohne Einbehaltung von Mustern oder die dingliche Beschlagnahme der rechtsverletzenden Ware sowie gegebenenfalls der für die Herstellung und/oder den Vertrieb dieser Waren notwendigen Werkstoffe und Geräte und der zugehörigen Unterlagen umfassen. Diese Maßnahmen werden gegebenenfalls ohne Anhörung der anderen Partei getroffen, insbesondere dann, wenn durch eine Verzögerung dem Rechtsinhaber wahrscheinlich ein nicht wieder gutzumachender Schaden entstünde, oder wenn nachweislich die Gefahr besteht, dass Beweise vernichtet werden. Wenn Maßnahmen zur Beweissicherung ohne Anhörung der anderen Partei getroffen wurden, sind die betroffenen Parteien spätestens unverzüglich nach der Vollziehung der Maßnahmen davon in Kenntnis zu setzen. Auf Antrag der betroffenen Parteien findet eine Prüfung, die das Recht zur Stellungnahme einschließt, mit dem Ziel statt, innerhalb einer angemessenen Frist nach der Mitteilung der Maßnahmen zu entscheiden, ob diese abgeändert, aufgehoben oder bestätigt werden sollen. (2) Die Mitgliedstaaten stellen sicher, dass die Maßnahmen zur Beweissicherung an die Stellung einer angemessenen Kaution oder entsprechenden Sicherheit durch den Antragsteller geknüpft werden können, um eine Entschädigung des Antragsgegners wie in Absatz 4 vorgesehen sicherzustellen. (3) Die Mitgliedstaaten stellen sicher, dass die Maßnahmen zur Beweissicherung auf Antrag des Antragsgegners unbeschadet etwaiger Schadensersatzforderungen aufgehoben oder auf andere Weise außer Kraft gesetzt werden, wenn der Antragsteller nicht innerhalb einer angemessenen Frist – die entweder von dem die Maßnahmen anordnenden Gericht festgelegt wird, sofern dies nach dem Recht des Mitgliedstaats zulässig ist, oder, wenn es nicht zu einer solchen Festlegung kommt, 20 Arbeitstage oder 31 Kalendertage, wobei der längere der beiden Zeiträume gilt, nicht überschreitet bei dem zuständigen Gericht das Verfahren einleitet, das zu einer Sachentscheidung führt. (4) Werden Maßnahmen zur Beweissicherung aufgehoben oder werden sie auf Grund einer Handlung oder Unterlassung des Antragstellers hinfällig, oder wird in der Folge festgestellt, dass keine Verletzung oder drohende Verletzung eines Rechts des geistigen Eigentums vorlag, so sind die Gerichte befugt, auf Antrag des Antragsgegners anzuordnen, dass der Antragsteller dem Antragsgegner angemessenen Ersatz für durch diese Maßnahmen entstandenen Schaden zu leisten hat. (5) Die Mitgliedstaaten können Maßnahmen zum Schutz der Identität von Zeugen ergreifen.

387

Das deutsche Umsetzungsgesetz hat materielle Vorlegungsansprüche in § 140c PatG, § 101a UrhG und entsprechende Vorschriften in andere Gesetze des geistigen Eigentums eingefügt. Stellvertretend für diese im wesentlichen gleich lautenden Vorschriften bestimmt § 101a UrhG: (1) Wer mit hinreichender Wahrscheinlichkeit das Urheberrecht oder ein anderes nach diesem Gesetz geschütztes Recht widerrechtlich verletzt, kann von dem Verletzten auf Vorlage einer Urkunde oder Besichtigung einer Sache in Anspruch genommen werden, die sich in seiner Verfügungsgewalt befindet, wenn dies zur Begründung von dessen Ansprüchen erforderlich ist. Besteht die hinreichende Wahrscheinlichkeit einer in gewerblichem Ausmaß begangenen Rechtsverletzung, erstreckt sich der Anspruch auch auf die Vorlage von Bank-, Finanz- oder Handelsunterlagen. Soweit der vermeintliche Verletzer geltend macht, dass es sich um ver-

144

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 388 A

trauliche Informationen handelt, trifft das Gericht die erforderlichen Maßnahmen, um den im Einzelfall gebotenen Schutz zu gewährleisten. (2) Der Anspruch nach Absatz 1 ist ausgeschlossen, wenn die Inanspruchnahme im Einzelfall unverhältnismäßig ist. (3) Die Verpflichtung zur Vorlage einer Urkunde oder zur Duldung der Besichtigung einer Sache kann im Wege der einstweiligen Verfügung nach den §§ 935 bis 945 der Zivilprozessordnung angeordnet werden. Das Gericht trifft die erforderlichen Maßnahmen, um den Schutz vertraulicher Informationen zu gewährleisten. Dies gilt insbesondere in den Fällen, in denen die einstweilige Verfügung ohne vorherige Anhörung des Gegners erlassen wird. (4) § 811 des Bürgerlichen Gesetzbuchs sowie § 101 Abs. 8 gelten entsprechend. (5) Wenn keine Verletzung vorlag oder drohte, kann der vermeintliche Verletze von demjenigen, der die Vorlage oder Besichtigung nach Absatz 1 begehrt hat, den Ersatz des ihm durch das Begehren entstandenen Schadens verlangen.

Schon vor dem Umsetzungsgesetz ist am LG Düsseldorf eine Praxis zur 388 Aufdeckung der verborgenen Verletzung entwickelt worden. Bei der verborgenen Merkmalsverwirklichung werden selbständiges Beweisverfahren mit vertraulicher Behandlung bis zur Gerichtsentscheidung und einstweilige Verfügung auf Duldung kombiniert, und zwar nach folgendem Beschlussmuster1.

I.

II.

Auf Antrag der Ast. vom … wird, da ein Rechtsstreit noch nicht anhängig ist und die Ast. ein rechtliches Interesse daran hat, dass der Zustand einer Sache festgestellt wird, die Durchführung des selbständigen Beweisverfahrens gem. § 485 ff. ZPO angeordnet. Beweisbeschluss 1. Es soll durch Einholung eines schriftlichen Sachverständigengutachtens Beweis darüber erhoben werden, ob die in der Verfügungsgewalt der Ag. … befindliche Software zur Finanzbuchhaltung, insbesondere die Software X Y, Version 4,2 und/oder frühere oder spätere … eine identische oder bearbeitete Kopie2 der Software U V, Anlage … der Antragstellerin ist, insbesondere in den Modulen … Bei Übereinstimmungen und Abwandlungen möge der Sachverständige erläutern, ob diese übliche Routinen darstellen, ob sie funktionell bedeutsame Teile darstellen oder zersplittert vorliegen und ob ungewöhnliche Eigenheiten übernommen scheinen. 2. Zum Sachverständigen wird … bestellt.

1 Entnommen und für Software modifiziert (kursiv gesetzte Teile) aus Kühnen, GRUR 2005, 185, vgl. auch Kühnen, Handbuch der Patentverletzung, 6. Aufl. 2013, Rz. 377 ff. 2 Der bei Kühnen, GRUR 2005, 185 vorgestellte Beweisbeschluss ist auf die Patentverletzung abgestellt. Die hier vorgenommene Abwandlung für die SoftwareUrheberrechtsverletzung bedarf hinsichtlich der „Bearbeitung“ regelmäßig noch einer rechtlichen Präzisierung.

M. Brandi-Dohrn

145

A Rz. 388

Grundlagen

3. Dem Sachverständigen wird – im Interesse der Wahrung etwaiger Betriebsgeheimnisse der Ag., die bei der Begutachtung zu Tage treten könnten – aufgegeben, jeden unmittelbaren Kontakt mit der Ast. zu vermeiden und notwendige Korrespondenz entweder über das Gericht oder mit den nachfolgend unter III 1 bezeichneten anwaltlichen Vertretern der Ast. zu führen. Der Sachverständige hat darüber hinaus auch gegenüber Dritten Verschwiegenheit zu wahren. 4. Auf Verlangen der Ag. hat der Sachverständige die Begutachtung für die Dauer von maximal zwei Stunden zurückzustellen, um der Ag. Gelegenheit zu geben, ihrerseits einen anwaltlichen Berater hinzuzuziehen. Der Sachverständige hat die Ag. vor Beginn der Begutachtung auf dieses Recht hinzuweisen. 5. Die Begutachtung soll – wegen der besonderen Eilbedürftigkeit1 – ohne vorherige Ladung und Anhörung der Ag. erfolgen. III. Im Wege der einstweiligen Verfügung werden darüber hinaus folgende weitere Anordnungen getroffen: 1. Neben dem Sachverständigen hat die Ag. folgenden anwaltlichen Vertretern der Ast. die Anwesenheit während der Begutachtung zu gestatten: – Patentanwalt …, – Rechtsanwalt … 2. Patentanwalt … und Rechtsanwalt … werden verpflichtet, Tatsachen, die im Zuge des selbständigen Beweisverfahrens zu ihrer Kenntnis gelangen und den Geschäftsbetrieb der Ag. betreffen, geheim zu halten, und zwar auch gegenüber der Ast. und deren Mitarbeitern. 3. Der Ag. wird – mit sofortiger Wirkung und für die Dauer der Begutachtung – untersagt, eigenmächtig Veränderungen an der zu begutachtenden Software vorzunehmen, insbesondere Datenbestände zu löschen oder zu verändern … 4. Für jeden Fall der Zuwiderhandlung gegen das unter 3. bezeichnete Verbot werden der Ag. ein Ordnungsgeld bis zu 250 000 Euro – ersatzweise Ordnungshaft – oder eine Ordnungshaft bis zu sechs Monaten angedroht, wobei die Ordnungshaft an dem Geschäftsführer der Ag. zu vollstrecken ist. 5. Der Ag. wird aufgegeben, den Quellcode der Fibu Software X Y dem Sachverständigen in allen Versionen und mit der Softwarentwicklungsdokumentation wie Fachkonzept, Lastenheft, Feinkonzept und DV-Konzept, soweit vorhanden, zugänglich zu machen und Zugriff auf alle Systeme, auch auswärtige, durch Herausgabe der Passworte und Angabe der Datenpfade zu ermöglichen. Sie hat es ferner zu dulden, dass der Sachverständige die zu begutachtenden Software untersucht, Screenshots nimmt und, sofern der Sachverständige dies für geboten hält, in den Arbeitspeicher eines Computers lädt und ablaufen lässt und eine Kopie

1 Zutreffender wäre: „wegen allgemein besorgender Vereitelungsgefahr“.

146

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 390 A

des vorgenannten Materials nimmt. Der Ag. wird geboten, selbst und durch ihre Mitarbeiter die volle Untersuchung durch aktive Mitwirkung zu unterstützen. IV. Nach Vorlage des schriftlichen Gutachtens wird die Ag. Gelegenheit erhalten, zu etwaigen Geheimhaltungsinteressen, die auf ihrer Seite bestehen, Stellung zu nehmen. Die Kammer wird alsdann darüber entscheiden, ob der Ast. das Gutachten zur Kenntnis gebracht wird. V. Die Durchführung des selbständigen Beweisverfahrens ist davon abhängig, dass die Ast. vorab einen Auslagenvorschuss von … Euro bei der Gerichtskasse in Düsseldorf einzahlt. VI. Der Wert des Streitgegenstandes für das selbständige Beweisverfahren wird auf … Euro festgesetzt, derjenige für das einstweilige Verfügungsverfahren auf … Euro. VII. Die Kosten des einstweiligen Verfügungsverfahrens trägt die Ag.

Der vorstehende Musterbeschluss von Kühnen1 kombiniert einen Beschluss 389 über ein selbständiges Beweisverfahren nach §§ 485, 490 ZPO mit einem Beschluss über eine einstweilige (Duldungs)verfügung nach §§ 935, 940 ZPO. Vorgeschlagene Abweichungen zur Anpassung an die Untersuchung eines Quellcodes und der dazu nötigen stärkeren Mitwirkung des Ag. sind kursiv gesetzt. Beide Beschlüsse unterliegen zum Teil unterschiedlichen Verfahrensregeln. Gleich ist die Zuständigkeit: das Gericht der kommenden Hauptsache, des Verletzungsprozesses. Die einstweilige Verfügung bedarf aber der Zustellung nach §§ 936, 922 Abs. 2 ZPO durch einen mitgenommenen Gerichtsvollzieher, § 192 ZPO. Das ist wichtig, weil das Veränderungsverbot nach III/3 Teil der einstweiligen Verfügung ist. Für den Beweisbeschluss genügt irgendeine Bekanntgabe. Zum selbständigen Beweisverfahren gehört die Entscheidung nach IV über die Bekanntgabe des Gutachtens. Dagegen ist auch die zugelassene Rechtsbeschwerde nach § 574 ZPO möglich, nicht aber gegen Teile des Verfügungsbeschlusses, §§ 574 Abs. 2, 542 Abs. 2 ZPO. Daher wird befürwortet zwei getrennte Beschlüsse zu beantragen und zu erlassen2. Das selbständige Beweisverfahren ist unabhängig von einer Verletzungs- 390 wahrscheinlichkeit, es sei denn, diese wäre so entfernt, dass das rechtliche Interesse fehlt. Es genügt vielmehr eine gewisse Verletzungswahrscheinlichkeit, wofür der Ast. konkrete Anhaltspunkte vortragen muss. Die begleitende Vorlage- und Duldungsverfügung bedarf jedoch eines Verfügungsgrundes. Nach § 935 ZPO ist es ein Verfügungsgrund, wenn zu besorgen ist, dass durch Veränderung des bestehenden Zustands das Recht einer Partei 1 Kühnen, Handbuch der Patentverletzung Rz. 323, und Kühnen, GRUR 2005, 185. 2 BGH v. 16.11.2009 – X ZB 37/08 – Lichtbogenschnürung, GRUR 2010, 318, insbesondere bei Tz. [8].

M. Brandi-Dohrn

147

A Rz. 391

Grundlagen

vereitelt oder erschwert werden könnte. Das sehen die Düsseldorfer gewerblichen Rechtsschutzkammern regelmäßig als gegeben an1, abweichend vom OLG Köln, das ein längeres Zuwarten für schädlich hält2. Für die Düsseldorfer Praxis spricht, dass die Zuspitzung der Gegnerrolle im Konflikt eine Vereitelung, und zwar eine unwiederbringliche, neu besorgen lässt. 391

Zu dem, was der Sachverständige soll und darf, ist oben Rz. 388 in II/1 und III/5 in einer ungesicherten Abweichung von dem Musterbeschluss eine erhebliche Erweiterung für die Quellcodebegutachtung vorgeschlagen worden. Ob eine Urheberrechtsverletzung in z.B. bearbeiteter Form vorliegt, entscheidet trotz II/1 der Richter und nicht der Sachverständige. Aber in einem noch nicht kontradiktorisch fokussierten Streitfall kann der Richter noch gar nicht wissen, wonach er genau fragen soll. Der Sachverständige braucht aber eine Richtung. Die gibt II/1 an. Die Angaben mögen in anderen Fällen anders lauten. Der zu untersuchende Quellcode liegt regelmäßig in einer sehr komplexen, für einen Außenstehenden, und sei er auch sachverständig, schwer kurzzeitig zu durchschauenden Umgebung. Er mag bei einem Drittunternehmen oder in einer „Cloud“ gesichert sein, geschützt durch Passworte. Inhaltlich erschließt er sich meist erst durch die Begleitdokumentation und die Entwicklung in fortschreitenden Versionen, also die Entstehungsgeschichte. Diese Umgebung muss aufgeschlossen und der Quellcode zugänglich gemacht werden. Alsdann ist es mit einer bloßen Besichtigung regelmäßig nicht getan, sondern der Sachverständige braucht eine Kopie des relevanten Materials, um die Materialmenge gründlich untersuchen zu können3. Die Juristen sehen aber bislang beim Besichtigungsschuldner nur eine Duldungspflicht und keine aktive Mitwirkungspflicht4. Zwar ist in § 101a UrhG nur von „Vorlage einer Urkunde oder Duldung der Besichtigung“ die Rede, aber das Umsetzungsgesetz ist im Lichte der Durchsetzungsrichtlinie auszulegen5, und deren Art. 7 verlangt „schnelle und wirksame einstweilige Maßnahmen zur Sicherung der rechtserheblichen Beweismittel“. Das umfasst auch und gerade in komplexen Software-Situationen die Anordnung derjenigen aktiven Mitwirkung, die zur Sicherung der rechtserheblichen Beweismittel geboten ist. Das gilt auch kraft der sekundären Darlegungslast, die für jedes Zivilverfahren gilt. Danach muss die verpflichtete Partei bei einer gewissen Verletzungswahrscheinlichkeit die Aufklärung geben, die in 1 Kühnen, GRUR 2005, 185 (193); OLG Düsseldorf v. 17.3.2011 – I-2 W 5/11 – Pohlschuhbleche. 2 OLG Köln v. 9.1.2009 – 6 W 3/09, CR 2009, 289. 3 Das hat Hoppen, CR 2008, 407, detailliert auseinander gesetzt. 4 Im Anschluss an BGH v. 13.11.2003 – I ZR 187/01 – Kontrollbesuche, GRUR 2004, 420; Kühnen, Handbuch der Patentverletzung Rz. 307, der aber bei Maschinensteuerung in Fn. 344 in einem begrenzten Maß auch positives Tun als Inhalt einer Duldungspflicht ansieht. 5 Unionsrechtliches Auslegungsprinzip aus Art. 4 Abs. 3 EUV nach ständiger BGH- und EuGH-Rechtsprechung, vgl. z.B. EuGH v. 19.1.2010 – Rs. C 555/07 – Kücükdeveci/Swedex, NJW 2010, 427 insbes. Tz. [47] zu § 622 Abs. 2 Satz 2 BGB.

148

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 394 A

ihrem Bereich liegt und ihr zumutbar ist. Die komplexe Umgebung ihrer Software und deren Begleitmaterial kennt der Ag. vorzugsweise. Die Aufklärung ist ihm zumutbar, denn es war eine gewisse Verletzungswahrscheinlichkeit bejaht worden und der Schutz von Betriebsgeheimnissen ist durch das Freigabeverfahren nach IV gesichert. Allerdings ist die Darlegungslast bislang nur mit einer negativen Beweiswürdigung bewehrt, aber § 142 ZPO gestattet es auch, die Vorlage von Urkunden aufzugeben1. Die Formulierung eines Antrags mit sinnvoller Ermächtigung an den Sach- 392 verständigen erfordert eine enge und aufgeschlossene Zusammenarbeit zwischen Anwalt des Ast. und den technisch kundigen Mitarbeitern des Ast. Keine Lösung ist hingegen im Stadium der Antragstellung eine enge Zusammenarbeit zwischen Ast. und zur Begutachtung benanntem Sachverständigen2, denn der Sachverständige ist Gehilfe des Gerichts und erhält auch vom Gericht die Antragsschrift mit näheren Details. Sein Gutachten soll in einem nachfolgenden Verletzungsverfahren verwertbar sein. Das ist es aber nicht, wenn sich der Sachverständige durch engen Kontakt mit dem Ast. der Besorgnis der Befangenheit aussetzt und nach § 406 ZPO abgelehnt wird. Es mag wohl sein, dass der in der Pause herbeigerufene Anwalt des Ag. den Sachverständigen detailliert nach Kontakten mit dem Ast. befragt. Harmlos sind lediglich Kontakte zur Kompetenz und Verfügbarkeit des Sachverständigen, den der Ast. benennen will. Gegen den Verschwiegenheitsclub bei der Untersuchung und gegen die Ab- 393 lieferung des Berichts vorerst nur an das Gericht, das dann nach IV des Musterbeschlusses über die Freigabe entscheidet, sind Bedenken erhoben aber vom BGH verworfen worden3, und zwar auch für den Fall, dass das Gutachten sogleich den zur Verschwiegenheit verpflichteten Anwälten des Ast. übergeben wird. Die Verschwiegenheitsverpflichtung auch gegen indirekte Preisgabe ist nach § 203 StGB strafbewehrt. Will die Ag. die anschließende Offenlegung des Berichts verhindern, so muss sie Tatsachen dafür vortragen, dass schützenswerte Betriebsgeheimnisse berührt sind. Alsdann entscheidet das Gericht unter Abwägung aller Umstände und des Gewichts der beiderseitigen Interessen über die Freigabe. Dabei ist es ein sehr wichtiger Umstand, ob nach dem Bericht eine Verletzung gegeben ist. Darüber entscheidet letztlich nicht der Sachverständige sondern anhand seiner Begründung das Gericht. Dieses kombinierte Beweissicherungs- und Verfügungsverfahren bietet vor 394 allem die bei „Druckbalken“ bemängelte zeitliche Rationalisierung und Abkürzung, dass noch im Beweis-/Verfügungsverfahren über die Freigabe 1 BGH v. 1.8.2006 – X ZR 114/03 – Restschadstoffentfernung, GRUR 2006, 962. 2 Das befürwortet Popper, CR 2009, 407. 3 Wegen Beeinträchtigung des rechtlichen Gehörs gegen ein Verfahren mit Verschwiegenheitsclub OLG München v. 11.8.2008 – 6 W 1380/08 – Laser-Hybridschweißverfahren, GRUR RR 2009, 191; aufgehoben von BGH v. 16.11.2009 – X ZB 37/08 – Lichtbogenschnürung, GRUR 2010, 318.

M. Brandi-Dohrn

149

A Rz. 395

Grundlagen

des Gutachtens nach Anhörung des Antragsgegners entschieden wird. Auch dagegen sind zwar Bedenken erhoben worden1, aber diese Bedenken lagen vor dem Inkrafttreten des § 101a UrhG und sind auch durch die neuere BGH-Rechtsprechung überholt2. 395

Bejaht das Gericht die „gewisse Wahrscheinlichkeit“ der Verletzung, so ist die Duldungsverfügung begründet und dem Verfügungsbeklagten werden insoweit die Kosten auferlegt. Die Beweissicherungskosten trägt vorerst der Antragsteller und sie werden anschließend nach dem Ergebnis des Hauptsacheverfahrens verteilt. Ähnliches gilt aber auch für die vorerst dem Ag. auferlegten Kosten des flankierenden Verfügungsverfahrens. Liegt letztlich keine Verletzung vor, so kann er die Kosten materiell nach § 101a Abs. 5 UrhG ersetzt verlangen. Insoweit ist die Ansicht des OLG Frankfurt3 überholt, die Kosten des Besichtigungsverfahrens habe bei Bejahung der gewissen Verletzungswahrscheinlichkeit ohne Rücksicht auf den Ausgang eines Hauptsacheverletzungsverfahrens immer der Ag. zu tragen. Der letztlich Unterliegende trägt die Kosten, der Unterschied ist nur, dass der Kostenerstattungsanspruch für die Besichtigung nicht im Kostenfestsetzungsverfahren geltend gemacht werden kann, sondern ggf. gesondert eingeklagt werden muss. Dazu wird es aber selten kommen.

396

Sowohl für den Besichtigungsanspruch und die Freigabe des Gutachtens, wie auch für den prozessualen Vorlegungsanspruch nach § 142 ZPO als auch für die sekundäre Darlegungslast sind jedes Mal maßgeblich, eine gewisse Wahrscheinlichkeit für das verfolgte Verfahrensziel wie auch eine Interessenabwägung, im Hinblick auf die Zumutbarkeit für den Verpflichteten4.

397

Offenlegung, auch nur an einen zur Verschwiegenheit verpflichteten Sachverständigen, kann der vermeintlich Verletzte nur verlangen, wenn er seinerseits alle vernünftigerweise verfügbaren Beweismittel vorgelegt hat. Dazu gehört bei der Urheberrechtsverletzung sein eigener Quellcode als eine der Grundlagen für den sachverständigen Quellcodevergleich. Ob der Kläger, der den vielleicht unschuldigen Beklagten angreift, seinen Code voll offen legen muss, damit der Beklagte volle Verteidigungsmöglichkeiten hat, ist im Hinblick auf das rechtliche Gehör des Überfallenen nicht unzweifelhaft. Es wird hier aber befürwortet, dass auch der Kläger seinen Quellcode nur dem zur Verschwiegenheit verpflichteten Sachverständigen geben oder sich dazu bereit erklären muss, denn vom Kläger wird in TRIPS und in der DurchsetzungsRL nur gefordert, dass er alle vernünftigerweise verfügbaren Beweismittel zur Verfügung stellt. Es wäre nicht vernünftig, dem ver1 OLG Frankfurt v. 17.1.2006 – 11 W 21/05 – Quellcode-Besichtigung, GRUR-RR 2006, 295, das aber andeutet, eine Freigabe des Berichts könne vielleicht auch am Ende des Verfügungsverfahrens erfolgen. 2 BGH v. 16.11.2009, GRUR 2010, 318 – Lichtbogenschnürung. 3 OLG Frankfurt v. 17.1.2006 – 11W 21/05, CR 2007, 145. 4 Vgl. BGH v. 1.8.2006 – X ZB 114/03 – Restschadstoffverwertung, GRUR 2006, 962 Tz. [43], [47].

150

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 398 A

meintlich verletzten Rechtsinhaber sofort die Auslieferung seines Betriebsgeheimnisses zuzumuten. Man würde ihm dadurch den Weg zu einem geordneten Gerichtsverfahren mit unvernünftigen Hürden verbauen. Der BGH1 hat einen Programmbesichtigungsanspruch durch einen Sachverständigen aus § 809 BGB schon gegeben, wenn nur Komponenten übernommen waren. Der Berechtigte müsse nicht darlegen, dass sein Quellcode in allen Komponenten schutzfähig sei, denn das werde, ausreichend für die hinreichende Verletzungswahrscheinlichkeit, vermutet. Kommt der Sachverständige in seinem vertraulichen Gutachten zu dem Ergebnis, dass eine Urheberrechtsverletzung vorliege, so wird alsdann das Gericht in aller Regel die Offenlegung des Gutachtens samt des zugrunde liegenden Materials anordnen, denn der Kläger muss dem Beklagten, der das Verletzungsgutachten kritisiert, antworten können, und umgekehrt muss der Beklagte alle Gutachtensgrundlagen haben, um das Gutachten angreifen und sich rechtlich voll zu Gehör bringen zu können. 6. Durchsetzung am Markt? Es sind in der Vergangenheit nur wenige Softwarepatentverletzungs- und nur wenige Softwareurheberrechtsverletzungsprozesse zu beobachten gewesen2. Das hat wahrscheinlich mehrere Gründe. Zum einen war die Durchsetzung bei einer verborgenen Verletzungsform in der Vergangenheit unter der „Druckbalkenentscheidung“ sehr aufwendig und brauchte Zeit, während der sich die verletzende Softwareversion längst änderte. Auch heute noch ist die gerichtliche Aufklärung über einen zur Verschwiegenheit verpflichteten Gutachter zeitaufwendig und in den einzelnen Beurteilungsschritten vom ausgeschlossenen Verletzten kaum zu überprüfen. Er ist es aber, der die besonderen Softwaredetailkenntnisse hat, über die regelmäßig auch seine zum „Vertraulichkeitsclub“ gehörigen Anwälte nicht verfügen. Es kommt hinzu, dass aus Gründen des rechtlichen Gehörs die Offenlegung des klägerischen Quellcodes an den Beklagten dann unvermeidbar erscheint, wenn der Gutachter eine Urheberrechtsverletzung bejaht und daher das Gericht die Offenlegung des Gutachtens anordnet, damit es voll zur Diskussion gestellt werden kann. Bei der behaupteten Verletzung eines Softwarepatents stellt sich dieses Problem nicht, weil das tertium comparationis die Patentschrift ist, und die ist öffentlich. Der Kläger zahlt in der gerichtlichen Durchsetzung von Urheberrecht mit seinem Betriebsgeheimnis „Quellcode“ einen hohen Preis. 1 BGH v. 20.9.2012 – I ZR 90/09, Unibasic-IDOS, GRUR 2013, 509. 2 Unter den wenigen Urheberrechtsverletzungsentscheidungen sind bekannt: BGH v. 9.5.1985 – I ZR 52/83 – Inkassoprogramm, MDR 1986, 121 = BGHZ 94, 279 = CR 1985, 5 = GRUR 1985, 1041; OLG Frankfurt v. 6.11.1984 – 14 U 188/81 – Baustatikprogramm, CR 1986, 13; BGH v. 14.7.1993 – I ZR 47/91 – Buchhaltungsprogramm, MDR 1994, 364 = CR 1993, 752 = NJW 1993, 3137, OLG Frankfurt a.M. v. 17.1.2006 – 11 W 21/05 – Quellcode-Besichtigung, GRUR-RR 2006, 295 = CR 2007, 145.

M. Brandi-Dohrn

151

398

A Rz. 399

Grundlagen

399

In der Praxis ist daher in der Vergangenheit mit Unsicherheit und einer hohen Dunkelziffer beobachtet worden, dass der verletzte Rechtsinhaber sein Recht am Markt durchzusetzen suchte, indem er die Kunden seines behaupteterweise verletzenden Konkurrenten warnte, ein rechtsverletzend erstelltes Programm zu erwerben und zu installieren1. Die Kunden stehen dann vor dem Problem, eine regelmäßig nicht unerhebliche Investition vergeblich zu tätigen, wenn ihnen womöglich hinterher die Nutzung des Programms gerichtlich untersagt wird. Wenn die Software des Verwarners in etwa die gleichen Zwecke auch erfüllt, ist es für sie vernünftig weil risikoloser, die Software des Verwarners zu erwerben.

400

Zum Rechtsschutz gegen Abnehmerverwarnungen hat das Reichsgericht 1904 das „Recht am eingerichteten und ausgeübten Gewerbebetrieb“ als „sonstiges Recht“ im Rahmen von § 823 Abs. 1 BGB geschaffen2. Auf dieser Grundlage hat die Rechtsprechung bislang Unterlassungsansprüche gegen Abnehmerverwarnungen, aber auch gegen Verwarnungen des Herstellers selbst gewährt, und bei Verschulden auch Schadensersatzansprüche3. Dabei ist der Verschuldensmaßstab ein strenger bei der Abnehmerverwarnung4 und bei der Verwarnung aus ungeprüften Schutzrechten5, also strenger bei Verwarnung aus einem ungeprüften Gebrauchsmuster als aus einem geprüften Patent. Der Unterlassungsanspruch erfordert kein Verschulden, sondern bloße Rechtswidrigkeit. Rechtswidrig ist die Verwarnung, wenn entweder keine Verletzung vorliegt oder das Recht nicht besteht. Liegt aber Verletzung eines rechtsbeständigen Schutzrechts vor, so ist es kein zusätzliches Erfordernis, vor einer Verwarnung von Abnehmern zuerst erfolglos den Hersteller verwarnt zu haben6.

401

Als Rechtsgrundlage gegen die Abnehmerverwarnung ist auch § 4 Nr. 8 UWG – nicht erweisliche wahre, abträgliche Tatsachenbehauptungen im Wettbewerbsverhältnis – diskutiert, aber überwiegend abgelehnt worden, weil Verletzungsbehauptungen Werturteile seien7. § 4 Nr. 8 UWG bietet 1 Vgl. z.B. LG Stuttgart v. 27.9.1990 – 17 O 460/90, CR 1991, 157: Verwarnung eines Dritten, der einen wechselnden Programmierer einstellte. 2 RG v. 27.2.1904, RGZ 58, 24 – Juteplüsch. 3 BGH v. 5.11.1962 – I ZR 39/61 – Kindernähmaschinen, BGHZ 38, 200 = GRUR 1963, 255; BGH v. 11.12.1973 – X ZR 14/70 – maschenfester Strumpf, GRUR 1974, 290; BGH v. 19.1.1979 – I ZR 166/66 – Brombeerleuchte, GRUR 1979, 334; BGH v. 23.2.1995 – I ZR 15/93 – Abnehmerverwarnung, MDR 1995, 813 = GRUR 1995, 424/425; BGH v. 17.4.1997 – X ZR 2/96 – Chinaherde, GRUR 1997, 741. 4 BGH v. 19.1.1979 – I ZR 166/66 – Brombeerleuchte, GRUR 1979, 334. 5 BGH v. 5.11.1962 – I ZR 39/61– Kindernähmaschine, GRUR 1963, 255: Herstellerverwarnung aus einem ungeprüften Gebrauchsmuster. Der die Produktion einstellende Hersteller muss sich aber ein Mitverschulden nach § 254 BGB zurechnen lassen; BGH v. 17.4.1997 – X ZR 2/96 – Chinaherde, GRUR 1997, 741. 6 BGH v. 23.2.1995 – I ZR 15/93 – Abnehmerverwarnung, MDR 1995, 813 = GRUR 1995, 424/425. 7 Hesse, GRUR 1979, 438; M. Brandi-Dohrn, GRUR 1981, 679; Dagegen für Haftung wegen falscher Tatsachenbehauptung aus § 4 Nr. 8 UWG: Sack, WRP 2005,

152

M. Brandi-Dohrn

Schutz und Realisierung der Software

Rz. 403 A

den Vorteil einer klaren Beweislastregel zu Lasten des Verwarners und den Nachteil einer sehr kurzen Verjährungsfrist von sechs Monaten in § 11 UWG. Aber die Beweislast für die Berechtigung der Abnehmerverwarnung hat die Rechtsprechung auch bei § 823 Abs. 1 BGB dem Verwarner auferlegt, so wie sie ihm auch auferlegt wäre, wenn er sein Recht in einem ordentlichen Verletzungsprozess suchen würde1. Das gilt auch für den Rechtsschutz gegen Abnehmerverwarnungen im Wege der einstweiligen Verfügung, wenn es zur mündlichen Verhandlung kommt. Ohne mündliche Verhandlung muss der Antragsteller alles gegen den nicht gehörten verwarnenden Rechtsinhaber glaubhaft machen, wird dieser aber in mündlicher Verhandlung gehört, so tritt die ursprüngliche Beweislast als Glaubhaftmachungslast wieder ein2. Als formal sittenwidrige Wettbewerbshandlung ist die Abnehmerverwarnung nach § 3 UWG zu unterlassen, wenn die Behauptung der Schutzrechtsverletzung zu pauschal ist oder wesentliche Umstände, wie etwa, dass ein mitgeteiltes Urteil nicht rechtskräftig ist, verschwiegen werden3.

402

Gegen das Verbot von materiell nicht berechtigten Abnehmerverwarnungen 403 waren im Anschluss an Ullmann4 Bedenken erhoben worden, und es ist vorgeschlagen worden, Abnehmerverwarnungen ohne Rücksicht auf inhaltliche Richtigkeit der Verletzungsbehauptung zuzulassen, wenn sie nicht formal den Sachverhalt falsch oder wesentlich unvollständig darstellen5. Der Große Senat für Zivilsachen des BGH6 hat entschieden, dass die unbegründete Schutzrechtsverwarnung unter dem Gesichtspunkt des rechtswidrigen und schuldhaften Eingriffs in das Recht am eingerichteten und ausgeübten Gewerbebetrieb zum Schadensersatz verpflichten kann, insbesondere bei der Abnehmerverwarnung. Für unser Thema heißt das: die Durchsetzung vermeintlicher Urheberrechte am Markt ist haftungsträchtig.

1 2

3

4 5

6

253; LG Stuttgart v. 27.9.1990 – 17 O 460/90, CR 1991, 157; öOGH v. 1.6.1999 – 4 OB 72/79 – Abnehmerverwarnung, GRUR Int. 2000, 558. RG v. 8.7.1933 – I 95/33 – Apreturmittel, RGZ 141, 336/341; OLG Düsseldorf v. 6.6.1958 – 2 U 175/57 – Heuerntemaschinen, GRUR 1959, 606 (607). So gegen OLG Düsseldorf v. 6.6.1958 – 2 U 175/57 – Heuerntemaschinen, GRUR 1959, 606/607; mit Recht: OLG Karlsruhe v. 27.5.1987 – 6 U 9/87 – Schutzrechtsverwarnung, CR 1987, 763 = GRUR 1987, 845; OLG Nürnberg v. 18.7.1995 – 3 U 1166/95 – Lizenzbereitschaftserklärung und Abnehmerverwarnung, GRUR 1996, 48. BGH v. 23.2.1995 – I ZR 15/93 – Abnehmerverwarnung, MDR 1995, 813 = GRUR 1995, 424/425; KG GRUR-RR 2004, 258 – Unvollständiger Entscheidungshinweis in Abnehmerverwarnung. Ullman, GRUR 2001, 1027. LG Düsseldorf v 3.12.2002 – 4 O 446/01 – Hochdruckreiniger, InstGE 3, 86; Düsseldorf v. 20.2.2003 – 2 U 135/02 – unberechtigte Abnehmerverwarnung, GRUR 2003, 814. BGH v. 15.7.2005 – GSZ 1/04 – Unberechtigte Schutzrechtsverwarnung, GRUR 2005, 882 = NJW 2005, 3141.

M. Brandi-Dohrn

153

A Rz. 404 404

Grundlagen

Ganz problematisch ist die Abgrenzung zwischen haftungsträchtiger Abnehmerverwarnung und Berechtigungsanfrage. Erstere ist verboten, wenn materiell unbegründet und soll sich dadurch auszeichnen, dass sie ein ernsthaftes und endgültiges Unterlassungsbegehren ausspricht1. Letztere ist als vorprozessualer Meinungsaustausch erlaubt und soll keine Haftungsfolgen auslösen2. Die sog. „Berechtigungsanfrage“ hat meist die Form, dass nach einer Darlegung der Schutzrechtsposition und der Verletzungshandlung die drohende Aufforderung angeschlossen wird: „Wir bitten Sie uns bis zum … zu erklären, warum Sie sich für berechtigt halten, unsere Schutzrechte nicht beachten zu müssen“3. Die Gerichte lieben es nicht, Schutzrechtsverletzungsprozesse aus Anlass von Verwarnungen und noch dazu im einstweiligen Verfügungsverfahren austragen zu müssen. Es besteht daher eine beklagenswert große Bereitschaft, in die folgenlose Berechtigungsanfrage auszuweichen. Aber die an den Abnehmer gerichtete Berechtigungsanfrage, sei sie auch honigsüß aber auf Anwaltsbriefbogen formuliert, erreicht bei dem Abnehmer, der risikoloser auch anderswo beziehen kann, regelmäßig den gleichen Wechsel der Bezugsquelle wie eine bestimmte Unterlassungsaufforderung. Es sollte daher zwischen der Abnehmerverwarnung und der Abnehmerberechtigungsanfrage im Regelfall kein Unterschied gemacht werden, wenn sie an den Sekundärverletzer gerichtet sind4: beide sind Eingriffe in den eingerichteten und ausgeübten Gewerbebetrieb des Herstellers, wenn materiell unbegründet. Die Einschränkung „im Regelfall“ dient der Berücksichtigung der Stellung des Abnehmers. Als Besteller oder erster Importeur kann er auch die primäre inländische Tatherrschaft haben und in Wahrheit der Primärverletzer sein. Die Gleichsetzung von Berechtigungsanfrage mit Abnehmerverwarnung entspricht aber derzeit nicht der herrschenden Meinung. Es bleibt aber die Durchsetzung am Markt für den Rechtsinhaber gefährlich.

1 BGH v. 10.7.1997 – I ZR 42/95 – Mecki-Igel III, MDR 1998, 359 = GRUR 1997, 896, zu einem Fall der Abnehmerverwarnung LS b): „Ein Schadensersatzanspruch wegen des Anspruchs einer unberechtigten Schutzrechtsverwarnung setzt ein ernsthaftes und endgültiges Unterlassungsbegehren voraus; ein nur der Rechtswahrung dienender Meinungsaustausch über die Rechtslage begründet einen solchen Anspruch noch nicht.“ Bestätigt in BGH v. 12.7.2011 – X ZR 56/09, Besonderer Mechanismus, GRUR 2011, 995 mit der Modifikation, dass das Einfordern einer strafbewehrten Unterlassungserklärung für eine Verwarnung mit allen Folgen nicht nötig sei, wenn sich noch keine Verletzung ereignet habe, sondern nur drohe. 2 BGH v. 10.7.1997 – I ZR 42/95 – Mecki-Igel III, MDR 1998, 359 = GRUR 1997, 896; OLG Karlsruhe v. 12.10.1983 – 6 U 119/83 – Berechtigungsanfrage, GRUR 1984, 143: es komme zwar auf den Sinn an, den der Adressat der Anfrage beimesse, trotz Vorbehalt von gerichtlichen Schritten aber erlaubte Berechtigungsanfrage OLG München Mitt. 1998, 117 – Berechtigungsanfrage – begründet kein rechtliches Interesse für eine negative Feststellungsklage. 3 Entnommen aus OLG München Mitt. 1998, 117 – Berechtigungsanfrage. 4 M. Brandi-Dohrn, GRUR 1981, 679.

154

M. Brandi-Dohrn

B. Sachqualität der Software und § 651 BGB Rz. I. Einführung in die Diskussion . II. Software-unspezifische Interpretationen des § 651 BGB im Lichte der „EU-KaufrechtsRichtlinie“ . . . . . . . . . . . . . . . . . . 1. Um-Interpretationen . . . . . . . . . 2. Entstehung der neuen Fassung des § 651 BGB. . . . . . . . . . . . . . . . 3. EU-rechtliche Auslegung . . . . . 4. „Verbrauchsgut“ . . . . . . . . . . . . . 5. Auslegungshilfe: Entstehungsgeschichte . . . . . . . . . . . . . . . . . . . 6. Waren- und Sachbegriff bei Software. . . . . . . . . . . . . . . . . . . . . 7. Einheitliche Auslegung . . . . . . . 8. Chronologie BGH-Entscheidungen zu Sachqualität unabhängig von § 651 BGB. . . . . . . . .

1

6 6 14 24 25 29 32 50

55

III. Relevanz konkreter Anwendung und Handhabung des § 651 BGB . . . . . . . . . . . . . . . . . . . 56 1. Verjährung . . . . . . . . . . . . . . . . . . 57

Rz. 2. 3. 4. 5. 6. 7. 8.

§ 649 BGB . . . . . . . . . . . . . . . . . . . §§ 642, 643 BGB . . . . . . . . . . . . . . Mängelrechte . . . . . . . . . . . . . . . . Abnahme . . . . . . . . . . . . . . . . . . . . Dokumentation . . . . . . . . . . . . . . Überprüfung der Ergebnisse . . . Hinterlegung . . . . . . . . . . . . . . . . .

64 70 72 75 78 80 90

IV. Rechtsprechung zu § 651 BGB n.F. . . . . . . . . . . . . . . . . . . . . . 92 1. Überblick über Entscheidungen v.a. des BGH . . . . . . . . . . . . . 92 2. Bestehende bzw. verbleibende „Lücken“ für die Anwendung des § 651 BGB . . . . . . . . . . . . . . . . 106 3. Stellungnahmen der Literatur. . 110 V. Folgen für die Vertragsgestaltung . . . . . . . . . . . . . . . . . . . 122 1. Abbedingen des § 651 BGB . . . . 122 2. Abnahme . . . . . . . . . . . . . . . . . . . . 123 3. Einheitliche Bewertung als Kaufvertrag . . . . . . . . . . . . . . . . . . 125

I. Einführung in die Diskussion Drei verschiedene Diskussionsstränge haben in jüngerer Zeit eine Entwick- 1 lung genommen, die erneut die Grundsatzfrage nach dem Rechtscharakter der Software aufwirft. Einmal geht es um die Frage der Qualität der Software als „Sache“ und zwar zunächst i.S.d. § 651 BGB und dann erweitert ggf. i.S.d. § 90 BGB. Die Verneinung der Sachqualität hat dogmatisch auch Auswirkungen auf den Bereich der Anwendung des Mietrechts, nicht jedoch direkt im Bereich des Kaufrechts (im Hinblick dort auf § 453 BGB). Das Hauptmotiv für die Ablehnung der Sachqualität ist, die Anwendung des § 651 BGB auszuschließen. Eine weitere Entwicklung betrifft genau diesen Gedanken, also die Anwen- 2 dung von § 651 BGB auf die Erstellung und Anpassung von Software abzulehnen, allerdings direkt und auf anderem Wege, also ohne die Sachqualität zu thematisieren. Die dritte Entwicklung bezieht sich auf den Online-Vertrieb von Software, 3 aufgrund der wirtschaftlichen Bedeutung auch oft unter dem Stichwort „Gebrauchtsoftware“ abgehandelt, insofern als es um die Frage geht, ob beim Online-Vertrieb Erschöpfung möglich ist und mithin dann die WeiterSchneider

155

B Rz. 4

Grundlagen

gabe erlaubt wäre (bei kaufrechtlichem Ersterwerb). Diese Frage wird im folgenden Abschnitt nicht näher behandelt. Besonders strukturiert wurde die Diskussion hierzu durch den Beschluss des BGH in der Sache Oracle gegen UsedSoft1 und die EuGH-Entscheidung dazu2. Im Ergebnis gilt es, nicht nur die Online-Erschöpfung zu registrieren, sondern vor allem die Qualifikation des Vertrags als Kauf i.V.m. Eigentum3. 4

Die beiden ersten Entwicklungsstränge sind insofern für diesen Dritten von Relevanz, als die Bejahung der Sachqualität auch der unkörperlichen Software, also unabhängig von Datenträgern, von Bedeutung dafür ist, was das „Werkstück“ betrifft. Jedoch soll die urheberrechtliche Problematik des Handels mit Gebrauchtsoftware bzw. die Frage der Erschöpfung im Online-Vertrieb hier in dem folgenden Abschnitt nicht näher vertieft werden4. Es geht also generell um die Sachqualität i.S.d. Vertragsrechts, insbesondere i.S.d. § 651 BGB, und dann speziell die Anwendbarkeit des § 651 BGB auf die verschiedenen Ausprägungen der Erstellung und Anpassung von Software.

5

Folgende Differenzierung hinsichtlich des Vertragsgegenstandes dient als Raster für die mögliche Anwendung des § 651 BGB: 1. Erstellung der fachlichen (Fein-)Spezifikation als „Pflichtenheft“ im juristischen Sinne5. 2. Erstellung von Standardsoftware, also etwa der Fall, dass ein Softwarehaus die Erstellung von Software, die das Softwarehaus vertreiben will, an einen Auftragnehmer vergibt (oder mehrere). Die Variante wird kaum bei der Diskussion berücksichtigt. 3. Erstellung von Individualsoftware für den Anwender6. 4. Die Anpassung von Software, wobei genauer zu unterscheiden sein wird zwischen: 4.1 Die Software wird in einem verbundenen Vertrag vom gleichen Auftragnehmer beschafft7, oder 4.2 die Software hat der Auftraggeber bei einem Dritten beschafft bzw. vom Auftragnehmer in einem gesonderten, nicht weiter zu beachtenden Vertrag oder, etwa als Eigenentwicklung, schon im Hause8. 1 BGH v. 3.2.2011 – I ZR 129/08, CR 2011, 223. 2 EuGH v. 3.7.2012 – C 128/11, CR 2012, 498. S.a. BGH v. 17.7.2013 – I ZR 129/08 – UsedSoft II –. 3 EuGH v. 3.7.2012 – C 128/11, CR 2012, 498; Rz. 42 f., Rz. 46 f; s.a. OLG Hamm v. 28.11.2012 – 12 U 115/12, CR 2013, 214. 4 S. hierzu Kap. A Rz. 88 und z.B. Leistner, CR 2011, 209 zu BGH; Schneider/ Spindler, CR 2012, 489; kritisch Haberstumpf, CR 2012, 561. 5 S. Kap. C, v.a. Rz. 29 ff 6 S. Kap. D. 7 S. BGH v. 14.7.1993 – VIII ZR 147/92 – Verkaufsabrechnung, CR 1993, 681, ausdrücklich nicht erfasst von BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422. 8 Typisch bei Anpassung und Portierung, s. z.B. BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422.

156

Schneider

Sachqualität der Software und § 651 BGB

Rz. 8

B

5. Als eigener Gegenstand kommt auch in Betracht die Lieferung von Standardsoftware i.V.m. weiteren Leistungen, insbesondere Installation und Einrichten. 6. Pflege1, und zwar im Hinblick auf die ggf. vereinbarte Aktualisierungspflicht. 7. System2. In Rz. 106 ff. wird gemäß diesem Schema dargestellt, ob und inwieweit eine Anwendung des § 651 BGB unter Berücksichtigung der weiteren Darstellung (noch3) in Betracht zu ziehen ist.

II. Software-unspezifische Interpretationen des § 651 BGB im Lichte der „EU-Kaufrechts-Richtlinie“ 1. Um-Interpretationen Die wohl herrschende Meinung in der Literatur vor der Rechtsprechung des 6 BGH ging dahin, § 651 BGB n.F. nicht auf Herstellung von Individualsoftware und Anpassung von Standardsoftware anzuwenden4. Gemeinsam war den Begründungen bei Ablehnung, dass sie die Vorschrift 7 des § 651 BGB nicht konform mit der Kaufrechts-Richtlinie und den sich daraus ergebenden Maßgaben sowie im Gegensatz zu der generalisierenden Art, wie der deutsche Gesetzgeber die Umsetzung vorgenommen hat, interpretierten. Dass dies kein gangbarer Weg war, ergibt sich aus den seit Mitte 2009 ergangenen BGH-Entscheidungen5. Im Ergebnis allerdings ändert sich nicht allzu viel (s. Rz. 106 ff.). Die unten (Rz. 92 ff.) näher behandelten BGH-Entscheidungen ergeben kein 8 klares Bild. Zumindest bestehen für bestimmte Konstellationen noch Lücken, die die Rspr. im Laufe der Zeit noch schließen könnte6. Bevor die Entstehung der neuen Fassung des § 651 BGB skizziert wird, werden im Folgenden kurz die Ansätze bis zum Ergehen der BGH-Entscheidungen angesprochen.

1 S. Kap. I zur Pflege mit den verschiedenen Leistungsspektren und Leistungsgegenständen. 2 Bislang gibt es noch keine Entscheidung zu „System“ incl. Softwareerstellung. Es läge nahe, hierauf entsprechend der zitierten Abgrenzung in BGH v. 25.3.2010 (– VII ZR 224/08, CR 2010, 422) § 651 BGB anzuwenden. 3 Also enger als in der 1. Aufl. dargestellt. 4 S.a. zum Überblick Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 625 ff., 627. 5 Beginnend mit BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637 – Siloanlage, m. Anm. Schweinoch; s.a. Schweinoch, CR 2010, 1; BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327 – Internetsystemvertrag. 6 S. dazu unten Rz. 32 ff. und 106 ff.

Schneider

157

B Rz. 9 9

Grundlagen

Der „frontale“ Ansatz ging über die (Nicht-)Anwendbarkeit des § 651 BGB hinaus: es wurde die Diskussion wiederbelebt, ob Software eine Sache sei1. Abgelehnt wurde die Sachqualität von der größeren Zahl von Autoren2. Die restriktivere Meinung will zumindest die durch Erstellung und Bearbeitung entstehende Software nicht als Sache sehen3.

10 Der zweite Ansatz nimmt eine reduzierende, teleologische, final orientierte Interpretation des § 651 BGB vor. Danach führen die Folgen der Anwendung des Kaufrechts zu unpraktikablen Ergebnissen. Deshalb sei auf den Erfolgscharakter des Vertrages bzw. den immateriellen Charakter des erfolgsorientierten Teils des Vertrages abzustellen und nach wie vor Werkvertragsrecht hierauf anzuwenden – entgegen dem Wortlaut des § 651 BGB, der aber insoweit dann nicht beachtet wird. Typische Vertreter waren etwa Palandt/ Sprau und Müller-Hengstenberg4. 11 Die hier genannte zweite Variante war bei Thewalt dahingehend gekennzeichnet, dass sie „auf den Schwerpunkt der Leistung abstellt, die der Auftragnehmer eines Softwareerstellungsvertrages zu erbringen hat“5. Daraus ist im Laufe der Zeit die Ansicht entstanden, es komme darauf an, ob ein „Gesamterfolg“ geschuldet ist, der über die rein technische Herstellung hinausgeht6. 12 Die vermittelnde Ansicht nahm Differenzierungen vor und stellte auf die unterschiedlichen Fallgestaltungen ab. Als Hauptvertreter kann Redeker genannt werden7. Redeker unterschied, ob der Besteller das Softwarehaus ist oder ein Anwender und stellte des Weiteren darauf ab, ob die Verwertungsrechte beim Besteller liegen werden oder beim Unternehmer verbleiben8. 13 Das Ergebnis bei Redeker war, dass das Werkvertragsrecht durchaus weiterhin Anwendung finden kann, jedoch nicht bei solchen Verträgen, die auf die Erstellung von einem einzelnen Exemplar zum einzelnen Einsatz bei einem Anwender gerichtet sind, woran der Besteller nur ein einfaches Nutzungsrecht zur Nutzung für eigene Zwecke erhält (also nicht etwa im Falle 1 Grundlegend: Bydlinski, Der Sachbegriff im elektronischen Zeitalter: zeitlos oder anpassungsbedürftig?, AcP 198 (1998), 287. 2 S. z.B. Kilian, CR 1986, 187, 193; Heussen, GRUR 1987, 779; Moritz, CR 1994, 257; Moritz/Tybussek, Computersoftware; Redeker, Wer ist Eigentümer von Goethes Werther?, NJW 1992, 1739 f.; Hilty, MMR 2003, 1. 3 S. v.a. Hilty, MMR 2003, 3. 4 Palandt/Sprau, 64. Aufl., § 651 BGB Rz. 5, wobei sich die Akzente mit weiteren Auflagen verschoben, s. 72. Aufl. § 651 BGB Rz. 4 und 5 i.V.m. Einf v § 631 Rz. 22; Müller-Hengstenberg, CR 2004, 161; ebenso Müller-Hengstenberg, NJW 2010, 1181 (zu BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637 – Siloanlage); s.a. zu den beiden Argumentationslinien Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 33; s.a. Kap. A Rz. 118 ff. 5 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 33. 6 Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 4; s.a. Zitat unten Rz. 16. 7 Redeker, CR 2004, 88; s.a. Kap. D Rz. 71 ff. 8 Redeker, CR 2004, 88 (89 f.).

158

Schneider

Sachqualität der Software und § 651 BGB

Rz. 17

B

der Bank, die die Software weiter verbreiten will). Des Weiteren soll § 651 BGB auf Verträge über die Überlassung von individuell angepasster Standardsoftware Anwendung finden. Alle anderen, über die beiden Fälle hinausgehenden Verträge „dürften § 651 BGB nicht unterfallen“1. 2. Entstehung der neuen Fassung des § 651 BGB Die Umsetzung der Kaufrechts-Richtlinie erfolgte in Deutschland zugleich 14 mit einer einheitlichen Regelung im BGB, also etwa betreffend die §§ 433 ff., 631 ff. BGB und hierbei auch § 651 BGB. Nur einige Besonderheiten, die das Verbrauchsgüterkaufrecht betreffen, §§ 474 ff. BGB, wurden speziell geregelt. Damit steht argumentativ schon fest, dass alle übrigen Regelungen, also die, die nicht von §§ 474 ff. BGB erfasst werden, grundsätzlich auch für Verträge gelten, die zwischen Unternehmern geschlossen werden, und nicht nur zwischen einem Unternehmer und einem Verbraucher2. Speziell § 651 BGB wurde deshalb neu geregelt, weil die Kaufrechts-Richt- 15 linie dies im Hinblick auf einen Verbraucher als Kunden zwingend erforderlich machte (Art. 1 Abs. 4 Kaufrechts-Richtlinie). Art. 1 Abs. 4 KaufrechtsRichtlinie lautet: „Als Kaufverträge im Sinne dieser Kaufrechts-Richtlinie gelten auch Verträge über die Lieferung herzustellender oder zu erzeugender Verbrauchsgüter.“ Dass es sich nur um Sachen im Sinne des nationalen Sachenrechts handeln soll, „ist nicht ersichtlich“3. Der deutsche Gesetzgeber war nicht verpflichtet, seine Umsetzung im Hin- 16 blick auf Verträge mit Kaufleuten zu verallgemeinern. Da er jedoch eine einheitliche Regelung geschaffen hat, wird bei der Auslegung keine Aufspaltung erfolgen dürfen4. Sprau drückt dies so aus: „§ 651 erstreckt sich … jedenfalls auf alle von der Richtlinie erfassten Verträge. Aus Gründen der Vereinfachung und Übersichtlichkeit werden auch alle anderen Verträge (nicht nur Verbraucherverträge) über die Lieferung herzustellender oder zu erzeugender beweglicher Sachen in die Regelung einbezogen (überschießende Umsetzung …).“5 Die Interpretation, § 651 BGB gelte nicht im Verhältnis zwischen Kaufleu- 17 ten bzw. Unternehmern, ist demnach nicht haltbar. In der Folge suchten die Autoren, die im Ergebnis § 651 BGB nicht für anwendbar hielten, einen anderen Lösungsweg, insbesondere den, es handele sich bei der Software

1 Redeker, CR 2004, 88, 91. 2 S. auch zur Entstehung des § 651 BGB n.F. und der Absicht der am Gesetzgebungsverfahren Beteiligten, eine umfassende Regelung für die Lieferung herzustellender Sachen zu schaffen, Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 626 und zu Literatur Rz. 627. 3 BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637 – Siloanlage – Rz. 10 m.w.N. 4 Sog. Ausstrahlungswirkung, s. Grundmann, in: Grundmann/Bianca (Hrsg.), EUKaufrechts-Richtlinie, Einl. Rz. 39. 5 Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 1.

Schneider

159

B Rz. 18

Grundlagen

nicht um eine Sache i.S.d. § 651 BGB i.V.m. § 90 BGB, oder aber, § 651 BGB finde aus anderen Gründen keine Anwendung. 18 Keine Anwendung soll etwa § 651 BGB finden bzw. es soll bei Werkvertragsrecht bleiben, wenn „ein über die bloße technische Herstellung der beweglichen Sache hinausgehender Gesamterfolg den Schwerpunkt der Verpflichtung des Unternehmers bildet …“1. 19 Der Gesetzgeber hatte bei der Schuldrechtmodernisierung allerdings an Software „gedacht“, so dass insoweit wenig Spielraum für Um-Interpretationen besteht: Zum einen wurde eine schon bestehende Regelung im Bereich des Fernabsatzes implementiert, die Software zum Gegenstand hat, allerdings „Software, sofern die gelieferten Datenträger vom Verbraucher entsiegelt worden sind“, also typischerweise Massensoftware, Standardsoftware (§ 312d Abs. 4 Nr. 2 BGB). 20 Sodann ist Software zwar ansonsten nicht explizit im Gesetz ausgewiesen, aber in den Materialien erwähnt worden. § 453 BGB besagt zudem ausdrücklich, dass die Vorschriften über den Kauf von Sachen auf den Kauf von Rechten und sonstigen Gegenständen entsprechende Anwendung finden (§ 453 Abs. 1 BGB). 21 Die Begründung der Bundesregierung zum Entwurf eines Gesetzes zur Modernisierung des Schuldrechts zeigt2, dass man insoweit unter anderem gedacht hat an: „Entgeltliche Übertragung von Unternehmen oder Unternehmensteilen, von freiberuflichen Praxen, von Elektrizität und Fernwärme von (nicht geschützten) Erfindungen, technischen Knowhow, Software, Werbe-Ideen“. Also wurde an Software „gedacht“, auch wenn dieser Gedanke, wie sich aus dem Umfeld der Nennungen ergibt, nicht mit § 312d Abs. 2 Nr. 2 BGB abgestimmt ist. 22 In der Regierungsbegründung heißt es dazu ausdrücklich3: „§ 651 BGB wird deshalb völlig neu gefasst und stark vereinfacht. Künftig finden ausschließlich die Vorschriften über den Kauf Anwendung, wenn die Lieferung herzustellender oder zu erzeugender beweglicher Sachen Gegenstand des Vertrags ist. Der bisherige § 651 BGB hat seinen Grund in den erheblichen Unterschieden zwischen Kauf- und Werkvertrag bei der Haftung für Sachmängel. Der fehlende Nacherfüllungsanspruch beim Kaufvertrag, die nicht sofort mögliche Wandelung und Minderung beim Werkvertrag sowie die unterschiedlichen Gewährleistungsfristen bei Bauwerken geben der Zuordnung zu einem der Vertragstypen erhebliche Bedeutung. Da der Entwurf diese Unterschiede beseitigen will, entfällt das Bedürfnis nach einem besonderen Typus des Werklieferungsvertrags. Es ist deshalb gerechtfertigt, Kaufrecht auf sämtliche Verträge mit einer Verpflichtung zur Lieferung herzustellender oder zu erzeugender Sachen an1 Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 4. 2 BT-Drucks. 6857/BR-Drucks. 338/01 zu § 453 BGB. 3 BT-Drucks. 6857/BR-Drucks. 338/01 zu § 651 BGB.

160

Schneider

Sachqualität der Software und § 651 BGB

B

Rz. 25

zuwenden. Die Fälle der zu erzeugenden Sachen dürften ohnehin regelmäßig auch ohne besondere Regelung dem Kaufrecht unterfallen. Es dürfte sich nahezu ausschließlich um Gattungskäufe handeln. Aber auch bei der Herstellung nicht vertretbarer Sachen, auf die nach bisherigem Recht Werkvertragsrecht anzuwenden wäre, kann Kaufrecht zur Anwendung kommen. Dies ist nach bisherigem Recht problematisch, weil die Herstellungsverpflichtung im Kaufrecht insbesondere bei der Sachmängelhaftung keine angemessene Berücksichtigung findet. Es fehlt v.a. ein Nachbesserungsanspruch. Die weitgehende Angleichung der Mängelhaftung bei den Vertragstypen Kauf- und Werkvertrag, wie sie der Entwurf vornimmt, nimmt der Einordnung eines Vertrages ihre Bedeutung und belässt es in weit größerem Umfang als nach bisherigem Recht zu, auch Verträge mit einer Herstellungsverpflichtung dem Kaufrecht zu unterstellen. § 651 RE trägt damit auch Art. 1 Abs. 4 der Verbrauchsgüterkaufrichtlinie Rechnung; danach gelten als Kaufverträge im Sinne der Richtlinie auch Verträge über die Lieferung herzustellender oder zu erzeugender Verbrauchsgüter (…)“. Der weitgehende Wechsel im Vertragstyp war bei § 651 BGB also geplant.

23

3. EU-rechtliche Auslegung EU-rechtlich ist es verboten, die Auslegung eines Bereichs, bei dem eine 24 Umsetzung der Richtlinie nicht erforderlich war, parallel nicht ebenso vorzunehmen, wie für den Bereich, bei dem die Umsetzung Pflicht war. Wenn also der deutsche Gesetzgeber die einheitliche Regelung des § 651 BGB für alle „Werklieferungsverträge“ schafft, die allerdings jetzt nicht mehr so heißen, so muss sie nicht nur einheitlich interpretiert werden, weil sie als einheitliche Vorschrift so geschaffen wurde, sondern weil die Maximen des EU-Rechts und hier also der Kaufrechts-Richtlinie dann auch für diese Umsetzung, die nicht Pflicht war, gelten. Gerade die Einrichtung der §§ 474 ff. BGB zeigt, wie ggf. eine Sonderrechtsregelung bzw. eine Umsetzung in dem Bereich, wo speziell die Pflicht zur Umsetzung bestand, erfolgen könnte. 4. „Verbrauchsgut“ Es muss aber auch bei der inhaltlichen Interpretation, also bei der Frage, ob 25 ein Vertragsgegenstand bzw. ein Vertrag unter § 651 BGB fällt, auf Grund der einheitlichen deutschen Regelung EU-konform interpretiert werden. Die Voraussetzung, es müsse sich um ein Verbrauchsgut handeln, ist durch die deutsche Regelung entfallen. Dadurch entfällt zwar insoweit der spezielle Adressatenkreis, es bleibt aber dabei, dass für alle Vertragsgegenstände, die unter die Verbrauchsgüterkaufrichtlinie fallen würden, auch § 651 BGB anzuwenden ist. Nicht unter den Anwendungsbereich von § 651 BGB fallen insoweit nur unbewegliche Sachen und Immaterialgüter.

Schneider

161

B Rz. 26

Grundlagen

26 Nach § 1 Abs. 2b Kaufrechts-Richtlinie sind „Verbrauchsgüter“ bewegliche körperliche Gegenstände mit Ausnahme von – „Gütern, die auf Grund von Zwangsvollstreckungsmaßnahmen oder anderen gerichtlichen Maßnahmen verkauft werden, – Wasser und Gas, wenn sie nicht in einem begrenzten Volumen oder in einer bestimmten Menge abgefüllt sind, – Strom.“

Dementsprechend gehört Software bzw. die Erstellung von Software nicht zu den Ausnahmen: „Bei speziell für den Kunden entwickelter Software, d.h., bei Werkverträgen über die Entwicklung konkreter Software, liegt es nahe, dass der objektive Anwendungsbereich der Kaufrechts-Richtlinie (Verkauf sowie Garantie) eröffnet ist, weil Art. 1 Abs. 4 dies vorsieht“1, wobei Software, die speziell für den Nutzer ausgearbeitet wurde, unter den Warenbegriff der KaufrechtsRichtlinie fällt2. 27 Im Zusammenhang der Begriffswahl könnte interessant sein, worauf Thewalt hinwies, dass der europäische Richtliniengeber, ebenso wie der deutsche Gesetzgeber eine engere Anlehnung an die Regeln des UN-Kaufrechts, CISG, erreichen wollte3. 28 Allerdings ist auch hier zu beachten, dass zum einen inhaltlich keine Übereinstimmung besteht, zum anderen aber auch der Adressatenkreis nicht gleich ist. Im Ergebnis hat Thewalt allerdings recht, wenn er festhält, dass der Software-Erstellungsvertrag nach wohl überwiegender, nach seiner Meinung zutreffender Meinung, wegen Art. 3 Abs. 2 CISG nicht dem UN-Kaufrecht unterfällt. Art. 1 Abs. 4 der Kaufrechts-Richtlinien stimmt nicht mit Art. 1 und Art. 3 CISG überein. Aus dieser Abweichung kann gefolgert werden, dass insoweit bei Vergleich zwischen der Kaufrechts-Richtlinie und CISG kein zwingender Schluss für die Auslegung von Art. 1 Abs. 4 der Kaufrechts-Richtlinie im Hinblick auf das CISG erlaubt bzw. notwendig wäre4.

1 Serrano, in: Grundmann/Bianca (Hrsg.), EU-Kaufrechts-Richtlinie, Art. 1 Rz. 33. 2 Serrano, in: Grundmann/Bianca (Hrsg.), EU-Kaufrechts-Richtlinie, Art. 1 Rz. 33, Fn. 3. 3 S. Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 94 ff. m.w.N.; zu § 651 im Lichte der Verbrauchsgüterkaufrichtlinie s.a. Schuhmann, ZGS, 2005, 250; zur „Kompatibilität“ mit CISG, hier „wesentlicher Teil“ i.S.d. Art. 3 Abs. 1 s. Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 633 und unten Rz. 28a. Zum Anwendungsbereich von CISG s. Lejeune, ITRB 2011, 20. 4 Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, S. 96; zum Warenbegriff des CISG im Vergleich s.a. Mankowski, Werkvertragsrecht – Die Neuerungen durch § 651 BGB und der Abschied vom Werklieferungsvertrag, MDR 2003, 854 (857).

162

Schneider

Sachqualität der Software und § 651 BGB

Rz. 34

B

5. Auslegungshilfe: Entstehungsgeschichte Die Umsetzung der Richtlinie im Rahmen der Schuldrechtsmodernisierung 29 spiegelt historisch diese Auffassung nur unzureichend wieder. Der Diskussionsentwurf des Bundesministeriums der Justiz sah keine Änderungen hinsichtlich § 651 BGB a.F. vor1. In der konsolidierten Fassung des Diskussionsentwurfs – vom Bundes- 30 ministerium der Justiz mit Datum 6.3.2001 erstellt (einschl. Anmerkungen) –, wurde die neue Fassung des § 651 BGB bereits mit „Anwendung des Kaufrechts“ überschrieben und eine Regelung vorgesehen, die bis auf kleinere redaktionelle Aspekte schon der endgültigen entspricht, also eine vollständige Verweisung des Vertrages über die Lieferung herzustellender oder zu erzeugender beweglicher Sachen ins Kaufrecht. Der spätere Satz 3 des § 651 BGB fehlt noch. Über die „Beschlüsse des Rechtsausschusses“ kam es dann zu der Ergän- 31 zung des § 651 BGB mit Satz 3, also der speziellen Regelung hinsichtlich einer nicht vertretbaren Sache. 6. Waren- und Sachbegriff bei Software Die Herausnahme bzw. die Abgrenzung von Vertragsgegenständen, die nicht 32 unter § 651 BGB fallen (sollen), ist auf Grund der Umsetzung der KaufrechtsRichtlinie im Rahmen einer – beabsichtigt – einheitlichen Regelung, die aber über den Anwendungsbereich der Kaufrechts-Richtlinie hinausgeht, nur insoweit möglich, als auch die Kaufrechts-Richtlinie den Gegenstand nicht erfasst. Die Erwähnung des Begriffs „der Sache“ in § 651 BGB kann auf Grund des Umsetzungscharakters nicht anders erfolgen, als es der Gegenstand der Kaufrechts-Richtlinie erfordert2. „Voraussetzung ist nur, dass Verbraucher durch den Vertrag eine Ware erhält, die unter die Bestimmungen der Kaufrechts-Richtlinie fällt, unabhängig davon, ob sie vor Vertragsschluss zur allgemeinen Veräußerung (dann Kaufvertrag) oder danach auf seine konkrete Bestellung hin hergestellt wurde (dann Werk- oder Werklieferungsvertrag) … Damit steht nun fest, dass sich die Kaufrechts-Richtlinie auch auf einfache ‚Verbrauchsgüterwerkverträge‘ … erstreckt.“3

33

In Deutschland hat sich der Streit an der Begrifflichkeit der körperlichen Ware bzw. der Körperlichkeit, wie diese gemäß der Definition gefordert ist, entzündet. In den Erwägungsgründen selbst ist fast überwiegend von „Waren“ bzw. „Gütern“ die Rede. Klassischerweise wird in diesem Zusammenhang auf den Datenträger rekurriert. Demnach wäre das Computerprogramm „als solches“ ein immaterielles Gut, während Computerprogramme

34

1 Entwurf des Bundesministeriums der Justiz, Stand: 4.8.2000. 2 S.a. Mankowski, CR 2010, 137 (138), zur Interpretation von „beweglichen Sachen“ als Äquivalent von „Goods“, Waren. 3 Serrano, in: Grundmann/Bianca (Hrsg.), Art. 1 Rz. 16 m.w.N. unter Hinweis zu „Verbrauchsgüterwerkverträgen“ auf Hänlein, DB 1999, 1641 (1642).

Schneider

163

B Rz. 35

Grundlagen

auf einem festen Datenträger eine Sache darstellen würden1. Diese Thematik hat auch im Urheberrecht ihre Bedeutung allerdings mit anderen Lösungen, etwa der Trennung von „Information“ und deren „Träger“-Medium2. 35 Die Frage ist allerdings, ob überhaupt der Sachbegriff des BGB in § 90 für die Interpretation des § 651 BGB herangezogen werden darf. BGH-Senate sowie OLG vertreten unterschiedliche Auffassungen hinsichtlich der SoftwareQualität, die z.T. nicht in dieses Schema passen3. 36 Nach Meinung von Serrano ist entscheidend für die Frage, ob Software unter den Geltungsbereich der Kaufrechts-Richtlinie fällt, die Art des Programms sowie der Datenträger. Grundsätzlich sei ein Computerprogramm ein immaterielles Gut, wozu auf BGHZ 102, 135 verwiesen wird4. 37 Dieses Zitat zeigt schon, wie problematisch der Umgang mit den BGH-Entscheidungen in diesem Zusammenhang ist. Bekanntlich besagt die Entscheidung vom 4.11.1987 im Wesentlichen, dass es für die „zumindest entsprechende“ Anwendbarkeit des Kauf-Gewährleistungsrechts, §§ 459 ff. BGB, auf das Einmalentgelt und die Überlassung auf Dauer ankommt5. 38 In dieser Entscheidung zitiert der BGH6 im Hinblick auf die Frage des anwendbaren Rechts auch die diversen Meinungen zum damaligen Diskussionsstand. Als Ausgangspunkt erwähnt der BGH einerseits seine Entscheidung vom 11.2.19717, gemäß derer sich die Verpflichtung zur Herstellung eines den speziellen Bedürfnissen des Anwenders entsprechenden Programms nach werkvertraglichen Regelungen beurteilt8. 39 Schwerer wiegt, dass der BGH, wie auch von ihm selbst zitiert, im Urteil vom 5.10.1981 die entgeltliche Gebrauchsüberlassung eines Computers mit Programmen als einheitlichen Mietvertrag angesehen hat. Insofern war implizit 1 S.a. Serrano, in: Grundmann/Bianca (Hrsg.), Art. 1 Rz. 33 unter Hinweis auf Hohloch, in: MünchKomm BGB, § 90 Rz. 24 m.w.N. S.a. Redeker, Information als eigenständiges Rechtsgut, CR 2011, 635, 637. 2 S. im Hinblick auf Weiterveräußerung (auch im Hinblick auf Online-Bezug von Software und „Erschöpfung“, Vorlage des BGH v. 3.2.2011 – I ZR 129/08, CR 2011, 223); s. aber EuGH v. 3.7.2012 – C-128/11, CR 2012, 498 und BGH v. 17.7.2013 – I ZR 129/08 – UsedSoft II. S.a. Redeker, Information als eigenständiges Rechtsgut, CR 2011, 635, 637. Zu „Eigentum“ auch bei Software s. nun aber OLG Hamm v. 28.11.2012 – 12 U 115/12. 3 S. nur OLG Düsseldorf v. 1.9.2009 – I-20 U 89/09, CR 20010, 24 zum Rechner als Datenträger, OLG München v. 23.12.2009 – 20 U 3515/09, CR 2010, 156 m. Anm. Mankowski, und BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 75 – ASP, Software als Sache i.S.d. Mietrechts; s. dazu a. Marly, Softwarevertragsrecht, 5. Aufl., Rz. 695, und unten Rz. 55 zum Übbl. über die BGH-Rspr. 4 Serrano, in: Grundmann/Bianca, Art. 1 Rz. 33 m. Fn. 2 (BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 124). 5 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 124, LS 1. 6 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 124. 7 BGH v. 11.2.1971 – VII ZR 170/69, WM 1971, 615. 8 Ebenso wie auch BGH WM 1977, 390.

164

Schneider

Sachqualität der Software und § 651 BGB

Rz. 44

B

entschieden, dass Software eine Sache sein muss, weil andernfalls Mietvertragsrecht nicht anwendbar gewesen wäre, jedenfalls nicht unmittelbar1. In der Entscheidung vom 3.6.1981 wandte der BGH auf die Überlassung ei- 40 nes Computerprogramms im Rahmen eines von den Parteien als „Lizenzvertrag“ bezeichneten Vertrages Pachtrecht an und zwar analog einem Know-how-Vertrag und dies wiederum deshalb, weil das Programm einem Fertigungsverfahren glich2. Zwar hat sich der BGH im weiteren Verlauf der Rspr.-Kette auch mit dem 41 Datenträger insofern befasst, dass Kaufgegenstand ein „Datenträger mit den darin verkörperten Programmen“ sei und „insofern also eine körperliche Sache …, die – entsprechend dem vertraglich vorausgesetzten Gebrauch – als Instrument zur Datenverarbeitung dienen soll.“3 Jedoch spielt der Datenträger ersichtlich keine weitere Rolle. Es ist aber kei- 42 neswegs so, dass der BGH sich hier darauf festgelegt hat, dass ein Computerprogramm ein immaterielles Gut sei. Vielmehr hat er sinngemäß gesagt, dass es sich um eine Sache i.S.d. §§ 459 ff. BGB a.F. handeln kann, was allerdings von der Literatur teilweise bestritten wird, und insofern immerhin und jedenfalls aber von ihm dieses Gewährleistungsrecht der §§ 459 ff. „zumindest entsprechend“ angewandt wird4. Allerdings hat sich der BGH dann in der weiteren Begründung auch mit dem Argument auseinandergesetzt, dass es „Besonderheiten des teilweise immateriellen Charakters von Softwareleistungen“ gibt5. Ein Meilenstein zur „Sachqualität“ war die Entscheidung des BGH vom 10.3.19986.

43

„Zwar ist nach der rechtsfehlerfreien tatrichterlichen Würdigung im Revisionsverfahren davon auszugehen, dass die Vereinbarung zwischen den Parteien einen einheitlichen Werklieferungsvertrag darstellt, auf den – da er eine nicht vertretbare Sache betrifft – Werkvertragsrecht anzuwenden ist.“7

Die vielleicht wichtigste Entscheidung bis zur Schuldrechtsmodernisierung betraf eine Portierung8. Der Gegenstand waren „Arbeiten an einem (von der anderen Seite) zur Verfügung gestellten Computerprogramm und dessen Umgestaltung in Form der Portierung auf andere Betriebssysteme und auf der Basis anderer als der ursprünglich verwendeten Programmiersprachen“, um darauf „reinen“ Werkvertrag anzuwenden9. 1 BGH v. 5.10.1981 – VIII ZR 259/80, WM 1981, 1358. 2 BGH v. 3.6.1981 – VIII ZR 153/80, MDR 1982, 222 = WM 1981, 954 = NJW 1981, 2684. 3 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 124 (127). 4 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 124, LS 1. 5 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 124 (127). 6 BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft I, CR 1998, 393. 7 BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft I, CR 1998, 393 (394). 8 BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93. 9 BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93.

Schneider

165

44

B Rz. 45

Grundlagen

45 Diese Entscheidung sieht sich selbst in klarer Abgrenzung zur Entscheidung des BGH vom 14.7.1993, weil es dort um „Standardsoftware des Unternehmers“ ging, „die dieser nach den Bedürfnissen des Bestellers modifizieren und ihm dann endgültig überlassen sollte“. Im Hinblick auf diese Entscheidung sagen die Entscheidungsgründe vom 9.10.2001 weiter, dass die Anwendung von § 377 HGB nicht erfolgte, da es dort um die „Herstellung einer nicht vertretbaren Sache aus vom Unternehmer zu beschaffenden Stoffen“ ging. Und weiter dann: „Es kann insoweit dahinstehen, ob das Ergebnis der von der Klägerin geschuldeten Programmierleistungen eine Sache i.S.d. § 381 Abs. 2 HGB betrifft“1. 46 Bei solchen Individual-Leistungen am vom Kunden beigestellter Software steht nicht die Herstellung einer Sache, sei sie vertretbar oder nicht, im Vordergrund, sondern die Programmierleistung als solche, die demnach dann als Werkvertrag (allenfalls als Dienstvertrag) zu qualifizieren wäre, ohne dass § 651 BGB zur Anwendung käme. Praktisch führen die BGH-Entscheidungen aus der Zeit vor § 651 BGB n.F. zur Differenzierung: – BGH v. 14.7.1993, Lieferung der Standardsoftware und deren Anpassung, Anwendung des § 651 BGB, Herstellung einer nicht vertretbaren Sache2 und – BGH v. 9.10.2001: Individuelle Programmierleistungen, auf die § 651 BGB keine Anwendung findet, wobei die Sachqualität der Software offen gelassen wird3. Diese Differenzierung deckt sich auch mit BGH v. 25.3.2010, Anpassung der Software als Werkvertrag4. Dort hat der BGH ausdrücklich offen gelassen, wie der Vertrag zu beurteilen wäre, der dort bezeichnet wurde als „Vertrag für ein P. Software-System“ (und nicht nur isoliert die Anpassung)5. 47 In der BGH-Entscheidung v. 9.10.2001 findet sich noch der Hinweis, dass das Ergebnis dieser Arbeiten eigentlich Standardsoftware sein sollte. Diese wollte die Beklagte ohne konkrete Anpassungen an die Bedürfnisse der eigenen Kunden weiter vertreiben. Nach Meinung des BGH berührt dies die Einordnung nicht. „Diese Standardsoftware sollte das Ergebnis der Arbeiten der Klägerin sein, bezeichnet aber nicht den Gegenstand der von ihr zu erbringenden Leistung.“6 48 Dies würde wiederum bedeuten, dass Verträgen, in denen jemand sich als Auftraggeber Software individuell anpassen lässt, über die er bereits verfügt und die er auch später weiter vertreiben will, normales Werkvertragsrecht 1 BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93 (95) i.V.m. BGH v. 14.7.1993 – VIII ZR 147/92 – Verkaufsabrechnung, CR 1993, 681. 2 BGH v. 14.7.1993 – VIII ZR 147/92 – Verkaufsabrechnung, CR 1993, 681. 3 BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93, 95; s. ausführlich dazu in Rz. 55. 4 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422, m. Anm. Bartsch, CR 2010, 777. 5 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422, Rz. 14; s.a. unten Rz. 104 f. 6 BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93 (95).

166

Schneider

Sachqualität der Software und § 651 BGB

Rz. 51

B

zugrunde liegt, allenfalls der Besteller sich bei einer Rechtseinräumung alle Rechte insofern einräumen lässt, dass er das Ergebnis dann weiter vertreiben kann, während bei einem Vertrag, bei dem der Gegenstand genau die Herstellung der Standardsoftware ist, sich nach Kaufrecht über § 651 BGB richten würde1. Keine Rolle hat bisher in der Debatte um die Sachqualität allgemein und 49 auch die Anwendung des § 651 BGB speziell gespielt, dass zu jeder Software auch Dokumentation, zumindest das Anwenderhandbuch, gehört2. Diese dürfte als Sache anzusehen sein und als mit-geschuldete Leistung wichtig für die Vertragscharakteristik. Allerdings besteht diese große Bedeutung der Dokumentation(en) zwar weiterhin bei Software-Projekten, jedoch nicht mehr bei Standardsoftware-Überlassung bis hin zu „Apps“. Zudem wird die Dokumentation bei modernen Projektmethoden ggf. von beiden Parteien oder sogar vom Besteller selbst erstellt3. Dieser Aspekt des materiellen Charakters der Dokumentation als mitgeschuldete Leistung tendiert, eher schwächer zu werden. Dies liegt auch daran, dass die entsprechende Kommentierung häufig (nur) Inline, am Code, erfolgt. 7. Einheitliche Auslegung Die Notwendigkeit einer einheitlichen Auslegung müsste im Hinblick auf die Kaufrechts-Richtlinie unstreitig sein4. Das Gegenteil ist der Fall5.

50

Dennoch tendiert die überwiegende Meinung zu einem Ergebnis, das prakti- 51 sche eine Spaltung bewirkt. Für die Frage der Herstellung (und wohl auch Anpassung) würde Software als immaterielles Gut, nicht als Sache i.S.d. § 651 BGB eingeordnet. Wohl aber wäre Software eine Sache i.S.d. Mietrechts6, während die gleiche Software bei Kauf als „sonstiger Gegenstand“ i.S.d. § 453 BGB gewertet würde. Es war nicht nur klare Absicht des Gesetzgebers, keine Beschränkung auf Verbrauchsgüter vorzunehmen, sondern man legte auch Wert darauf und betonte, dass mit der neuen Fassung des

1 Was sich in Einklang bringen ließe mit BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327, dazu Rz. 100. 2 S. nur BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681 und BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207. 3 Zu Agiler Methodik, insbes. SCRUM, s. Kap. C Rz. 124 ff., 131 ff.; zur aktuellen Behandlung von Dokumentation s. Stiemerling, ITRB 2011, 286 und unten Rz. 78 sowie Kap. D Rz. 119 ff., Kap. H Rz. 95 ff.; Kap. I Rz. 424 ff. und Kap. Q Rz. 205 ff. 4 S.a. Mankowski, CR 2010, 137. 5 S. etwa Bartsch, Software als Rechtsgut, CR 2010, 553; Heydn, CR 2010, 765; vermittelnd Redeker, CR 2011, 635 (638); s.a. Kap. D Rz. 71 ff. 6 BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 75 – ASP, dazu sogleich Zitat in Rz. 55 am Ende, und unten Rz. 55a, Kap. E Rz. 112 ff.

Schneider

167

B Rz. 52

Grundlagen

§ 651 BGB weitgehende Übereinstimmung mit Art. 3 Abs. 1 CISG erreicht werde, an dem sich auch die Verbrauchsgüterkauf-RL orientierte1. 52 Marly hatte schon auf die Konsequenzen hingewiesen, die diese Auffassung hätte, „dass nämlich dann die Software-Überlassung auf Zeit nicht mehr mietvertraglich qualifiziert werden könne, weil § 535 Abs. 1 Satz 1 BGB eine Mietsache voraussetzt“2. Auch weist Marly darauf hin, dass bei der Überlassung von Individualsoftware dann lediglich § 634a Abs. 1 Nr. 3 BGB für die Verjährung der Mängelansprüche in Betracht kommt, nicht die verkürzte Verjährungsfrist des § 634a Abs. 1 Nr. 1 BGB, wenn man überhaupt trotz der Verweisung gemäß § 651 BGB diese Vorschriften anwendet. Schließlich sei unklar, „ob und nach welchen Vorschriften Computerprogramme zu übereignen wären“3. 53 Unter Einbeziehung des CISG und dessen Entstehung lässt sich die Nichtanwendung des § 651 BGB (wegen der ausdrücklichen Anlehnung der RL an CISG) EU-konform argumentieren: Nach Sprau soll der „über die Herstellung der Sache hinausgehende Gesamterfolg“ maßgeblich für die Nichtanwendung sein4. Dies wäre korrekt, wenn es sich bei dem „hinausgehenden Erfolg“ nicht nur um den „wesentlichen Teil“ der Leistung i.S.v. Art. 3 Abs. 1 CISG handelt, sondern dieser als „überwiegend“ gelten kann5. Im Sinne der Einheitlichkeit bei der Auslegung wäre es vorzuziehen, wenn statt über die Ablehnung der Sachqualität die Auslegung des § 651 im Hinblick auf diesen überwiegenden Anteil der „kauffremden Leistung“ abgestellt würde. Dieser Anteil könnte etwa auch in Planung, Organisation u.ä. bestehen. 54 Als weiterer Ansatz i.S. der Harmonisierung sei noch kurz erwähnt: danach ist das „Werkstück“ und damit auch Gegenstand der urheberrechtlichen Beurteilung der Objektcode bzw. der Datenstrom6. Ob dies allerdings bei Softwareerstellung und -anpassung „hilft“, wäre noch zu prüfen, wenn sich dieser Ansatz durchsetzt7. Soweit bei Erstellung der Erfolg auf Herstellung des Quellcodes gerichtet ist, würde der Ansatz mangels (ausführbaren) Datenstroms nicht tragen. Allerdings wäre gerade der vielbeschworene Gesamterfolg8 auf eine ablauffähige, für den Besteller passende Software auch bei Anpassung nur über Parameter gerichtet.

1 So Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 626 unter Hinweis auf u.a. Mankowski, MDR 2003, 854 (855). 2 Marly, Softwareüberlassungsverträge, 4. Aufl., Rz. 116; nun Praxishandbuch Softwarerecht, 5. Aufl., Rz. 695. 3 Marly, Softwareüberlassungsverträge, 4. Aufl., Rz. 116 a.E.; nun Praxishandbuch Softwarerecht, 5. Aufl., Rz. 695 a.E. 4 S. Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 4; s.a. Zitat in Rz. 120. 5 S. Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 633 m.w.N. 6 S. Ulmer/Hoppen, CR 2008, 681. 7 Abl. z.B. Bartsch, CR 2010, 553. 8 S. nur Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 4 und Einf. Vor § 631 BGB Rz. 22.

168

Schneider

Sachqualität der Software und § 651 BGB

B

Rz. 55

8. Chronologie BGH-Entscheidungen zu Sachqualität unabhängig von § 651 BGB 55

Datum

Az.

Fundstelle

25.3.1987

XIII ZR 43/86

CR 1987, 358: vertragstypologische Einordnung bei SoftwareÜberlassung noch offen.

4.11.1987

XIII ZR 314/86 CR 1988, 124: „§§ 159 ff. BGB (a.F.) zumindest entsprechend anwendbar“ auf Mängel bei Software (Standardsoftware).

18.10.1989

XIII ZR 325/88 CR 1990, 24: Nunmehr: Überlassung von Standardsoftware auf unbegrenzte Zeit gegen einmaliges Entgelt = Kaufvertrag (unter ausdrücklichem Verweis auf 4.11.1987 und 25.3.1987) und zudem: Auf die Übergabe auf einem Datenträger kommt es nicht an. Die Software kann sogar unkörperlich überspielt werden. Entscheidend ist nur, dass sie schließlich auf dem Massenspeicher des Käufers landet.

3.11.1992

X ZR 83/90

4.11.1992

XIII ZR 165/91 CR 1993, 203: Die Lieferung der Hard- und Softwarehandbücher gehört zur Hauptleistungspflicht des Verkäufers (einer Computeranlage, bestehend aus Hard- und Software).

14.7.1993

VIII ZR 147/92 CR 1993, 681: Wenn Software im Wege des Werklieferungsvertrages dem Besteller endgültig überlassen wird, ist § 377 HGB anwendbar (plus Bestätigung der Rechtsprechung zur Vollendung erst mit Auslieferung der Handbücher). Und weiter wörtlich: „Der Senat hat, woran festzuhalten ist, bereits mehrfach entschieden, dass eine Standardsoftware als bewegliche Sache anzusehen ist (BGHZ 102, 135, 144 [4.11.1987]; 109, 97, 100 f. [18.10.1987]). Gleiches hat zu gelten, wenn eine Standardsoftware den speziellen Wünschen des Käufers/des Bestellers angepasst und diesem in kauf- oder werkvertraglichen Formen endgültig überlassen wird. Entscheidend ist allein, dass es sich auch in diesem Fall um ein auf einem Datenträger verkörpertes

CR 1993, 352: Auch bei Erstellung von Software ist erst erfüllt bzw. ist das Werk erst vollendet, wenn auch das Benutzerhandbuch ausgehändigt wurde.

Schneider

169

B Rz. 55 Datum

Grundlagen Az.

Fundstelle Programm und damit um eine körperliche Sache (§ 90 BGB) handelt.“ Naturgemäß befasst sich die Literatur besonders mit dieser Textstelle, weil die getroffene Feststellung – mehrfach so entschieden – nicht richtig ist. Heussen z.B. interpretiert die Stelle dahingehend, dass es um Software unter dem Aspekt des § 377 HGB ging1.

22.12.1999

XIII ZR 299/98 CR 2000, 207: Zumindest entsprechende Anwendbarkeit der kaufrechtlichen Vorschriften einschl. § 377 HGB auf die Lieferung fertig entwickelter Standard-Software nebst dazugehörigem Quellcode.

24.2.2000

I ZR 141/97

CR 2000, 656: Programmfehlerbeseitigung als bedingungsfester Kern der Nutzerrechte.

6.7.2000

I ZR 244/97

CR 2000, 651: Zur Verkehrsfähigkeit der Werkstücke im Zusammenhang mit „Veräußerung“/Erschöpfung und im Gegensatz dazu auch „Vermietung“.

9.10.2001

X 58/04

CR 2002, 93: In Abgrenzung zu BGH v. 14.7.1993 findet § 377 HGB gem. § 381 Abs. 2 HGB auf einen Vertrag keine Anwendung, bei dem der Unternehmer die Portierung der Software des Bestellers für diesen übernommen hat. Dabei kann es „dahinstehen, ob das Ergebnis der von der Klägerin geschuldeten Programmierleistungen eine Sache i.S.d. § 381 Abs. 2 HGB betrifft.“ (Es folgen Verweise der oben bereits zitierten BGH-Entscheidung) „Auch wenn von einer Sacheigenschaft ausgegangen wird, ist Gegenstand der Leistungspflicht der Klägerin hier nicht die Herstellung eines Werkes aus von ihr zu beschaffenden Programmen und Programmteilen; geschuldet werden vielmehr Arbeiten an einem von der Beklagten zur Verfügung gestellten Programm und dessen Umgestaltung in Form der Portierung auf andere Betriebssysteme und auf der Basis anderer als der ursprünglich verwendeten Programmiersprachen. Die Vereinbarung der Parteien betraf damit nur noch individuelle Programmierleistungen. Dass das Ergebnis dieser Arbeiten eine Standardsoftware sein sollte, die die Beklagte ohne konkrete Anpassungen an die Bedürfnisse ihrer Kunden vertreiben wollte, berührt diese Einordnung nicht. Diese

1 Heussen, CR 2004, 1 (7), Fn. 48.

170

Schneider

Sachqualität der Software und § 651 BGB Datum

Az.

B

Rz. 57

Fundstelle Standardsoftware sollte das Ergebnis der Arbeiten der Klägerin sein, bezeichnet aber nicht den Gegenstand der von ihr zu erbringenden Leistungen.“

24.10.2002

I ZR 3/00

CR 2003, 323: Unproblematische Anwendung von Mietrecht auf einen „Softwarelizenzvertrag“.

15.11.2006

XII ZR 120/04

CR 2007, 75: „Der Bundesgerichtshof hat wiederholt entschieden, dass eine auf einem Datenträger verkörperte Standardsoftware als bewegliche Sache anzusehen ist, auf die je nach der vereinbarten Überlassungsform Miet- oder Kaufrecht anwendbar ist (BGHZ 143, 307, 309; 109, 97, 100 f.; 102, 135, 144; BGHUrt. v. 4.3.1997 – X ZR 141/95, MDR 1997, 913; v. 14.7.1993 – VIII ZR 147/92, NJW 1993, 2436 [2437 f.]; v. 7.3.1990 – VIII ZR 56/89, NJW 1990, 3011; v. 6.6.1984 – VIII ZR 83/83, ZIP 1984, 962 [963]; Beschl. v. 2.5.1985 – I ZB 8/84, NJW-RR 1986, 219; vgl. auch Schweizerisches Bundesgericht BGE 124 III 456, 459).“

EuGH v. 3.7.2012

C 128/11

CR 2012, 498: Zum Eigentum auch bei Online erworbener Software Rz. 40 ff., v.a. 46; dazu auch OLG Hamm v. 28.11.2012 – 12 U 115/12.

BGH v. 17.7.2013

I ZR 129/08

Rückverweisung u.a. wg. Voraussetzungen für Kauf.

III. Relevanz konkreter Anwendung und Handhabung des § 651 BGB In Abschnitt IV. wird unten (Rz. 92 ff.) anhand der Rspr. dargelegt, dass eine 56 Anwendung des § 651 BGB durchaus in Betracht kommt, wobei die „Lücken“ nicht h.M. sind. Im Folgenden wird aufgezeigt, welche Relevanz diese Anwendung hinsichtlich einiger Details hätte, so dass es sich als notwendig ergibt, die Entwicklung v.a. der Rspr. zur Anwendbarkeit genau zu beobachten. 1. Verjährung Gerade bei Nichtanwendung des § 651 BGB stellt sich das Problem richtiger 57 Behandlung der Verjährungsfrage massiv: Das Problem entsteht v.a. dadurch, dass sich konsequenterweise bei Ablehnung der Anwendung des § 651 BGB, weil Software keine Sache sei, die Verjährung nach § 634a Abs. 1 Nr. 3 BGB ohne festen Beginn beurteilt. Daraus resultiert ein erhebliches AGB-rechtliches Problem, das aber bislang in der Rspr. nicht thematisiert wurde. Schneider

171

B Rz. 58

Grundlagen

58 Würde man auf die Erstellung von Software im Wesentlichen Kaufrecht anwenden, ergänzt um einige werkvertragliche Vorschriften, wenn es sich um eine nicht vertretbare Sache handelt, so entfällt die Abnahme. Ob eine solche dann in AGB wirksam vorgesehen werden könnte, erscheint zweifelhaft. An deren Stelle tritt die Ablieferung. Damit ist der Verjährungsbeginn klar ermittelbar. 59 Wird Werkvertragsrecht angewandt, bleibt es beim Abnahmeerfordernis, ist aber unklar, welche Verjährungsvorschrift (§ 634a Abs. 1 Nr. 1 oder 3 BGB) Anwendung zu finden hat. Dies gilt insbesondere, wenn der Gegenstand evtl. aus verschiedenen Leistungsbereichen stammt. Richtigerweise müsste die Ablehnung der Sachqualität zur Anwendung von Nr. 3 führen1, was neben der längeren Frist vor allem zur Folge hat, dass der Beginn nicht mit Abnahme eintritt2. AGB-rechtlich scheint keine Lösung in Sicht. Maume/Wilser empfehlen deshalb individualvertragliche Regelung3. 60 AGB-rechtlich scheitert eine entsprechende Regelung schon daran, dass die Wirksamkeit einer solchen Klausel erst geprüft werden kann, wenn der Vertragstyp feststeht und dieser nicht anhand der später zu prüfenden Klauseln ermittelt werden darf4. 61 Es ist also zwecklos, über den Vertrag einfach die Bezeichnung „Werkvertrag“ zu schreiben. Individualvertraglich könnte man vielleicht noch etwas gewinnen, indem man einvernehmlich festlegt, dass der Vertrag sich nach Werkvertragsrecht beurteilen soll. Dies ist dann immerhin einer Auslegung zugänglich, die auf den Parteiwillen abstellt, auch wenn dann im Übrigen doch Kaufrecht Anwendung finden sollte. Als AGB nutzt dieser Text ohnehin nichts. 62 Im Einzelnen überschneiden sich die Rechtsfolgen bei Mängeln so, dass auch insoweit die Gestaltung von AGB nicht ganz unproblematisch ist, je nach dem, welcher Vertragstyp Anwendung finden soll. S. zum Überblick unten Rz. 73. 63 Die Frage, unter welchen Voraussetzungen bzw. für welche Güter eine Anwendung des § 651 BGB zu erfolgen hat, ist durch eine Reihe von Entscheidungen des BGH in den Jahren 2009 und 2010 weitgehend geklärt. Soweit diese Entscheidungen sich mit Software-Erstellung bzw. -Anpassungen befassen, geben sie zwar der herrschenden Meinung nicht in der Begründung und deren Methodik5, aber im Ergebnis und in der die Anwendung von 1 S.a. Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 695. 2 S.a. Mankowski, Werkvertragsrecht – Die Neuerungen durch § 651 BGB und der Abschied vom Werklieferungsvertrag, MDR 2003, 854, 857. 3 Maume/Wilser, Viel Lärm um nichts? Zur Anwendung von § 651 BGB auf ITVerträge, CR 2010, 209; s.a. schon Schmidl, MMR 2004, 590. 4 BGH v. 4.3.1997 – X ZR 141/95 – BVB-Überlassung II, CR 1997, 470. 5 V.a. hinsichtlich der teleologischen Auslegung, die abgelehnt wird, s. BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637; s.a. BGH v. 4.3.2010 – III ZR 79/09.

172

Schneider

Sachqualität der Software und § 651 BGB

Rz. 67

B

§ 651 auf Software ablehnenden Tendenz recht. Die Entscheidung, aus denen sich dies so ergibt, werden im Folgenden unter Rz. 92 ff. dargestellt. Dass sich die Fragestellung der Anwendbarkeit des § 651 BGB nicht ganz erledigt bzw. geklärt hat, liegt daran, dass die in Rz. 92 ff. darzustellenden Entscheidungen des BGH nicht sämtliche in Betracht kommenden Fallgestaltungen und Vertragsgegenstände erfassen (s. Rz. 106 ff.). 2. § 649 BGB Eine Besonderheit des Werkvertragsrechts ist § 649 BGB – eine Kündigungsmöglichkeit für den Besteller ohne Frist und Grund, die diesen aber grundsätzlich nicht von der Zahlungsverpflichtung befreit. Das Problem des Unternehmers ist allerdings, dass ihm praktisch (über Darlegungs- und Beweislastregeln) das Risiko überbürdet wird, seinen Zahlungsanspruch zu substantiieren. Nach Satz 2 wird vermutet, dass „dem Unternehmer 5 vom Hundert der auf den noch nicht erbrachten Teil der Werkleistung entfallenden vereinbarten Vergütung zustehen“1.

64

Der BGH hat in jüngerer Zeit mehrfach zu § 649 BGB entschieden, womit 65 wichtige Maßgaben für Projekt- und Provider-, aber auch Wartungs- und v.a. Pflege-Verträge verbunden sind: „a) Der Besteller darf einen Werkvertrag, mit dem sich der Unternehmer für eine Mindestvertragslaufzeit von 36 Monaten zur Bereitstellung, Gestaltung und Betreuung einer Internetpräsenz verpflichtet hat, jederzeit gemäß § 649 Satz 1 BGB kündigen. Dieses Kündigungsrecht wird nicht dadurch ausgeschlossen, dass der Vertrag ein außerordentliches Kündigungsrecht vorsieht. b) Die Bemessung der nach § 649 Satz 2 BGB zu zahlenden Vergütung orientiert sich nicht an den vereinbarten Zahlungsmodalitäten, wie etwa Ratenzahlungen. Maßgebend ist der Betrag, der dem auf die erbrachten Leistungen entfallenden Teil der vereinbarten Vergütung entspricht.“2 „a) Der Besteller darf einen Werkvertrag, mit dem sich der Unternehmer für eine Mindestvertragslaufzeit von 48 Monaten zur Bereitstellung, Gestaltung und Betreuung einer Internetpräsenz verpflichtet hat, jederzeit gemäß § 649 Satz 1 BGB kündigen. b) Der Unternehmer muss zur Begründung seines Anspruchs aus § 649 Satz 2 BGB grundsätzlich vortragen, welcher Anteil der vertraglichen Vergütung auf die erbrachten und nicht erbrachten Leistungen entfällt und darüber hinaus vertragsbezogen darlegen, welche Kosten er hinsichtlich der nicht erbrachten Leistungen erspart hat.“3

66

„a) Prüfungsmaßstab für die Wirksamkeit einer vom Unternehmer gestellten Klausel, die die Höhe der Vergütung des Unternehmers nach § 649 Satz 2 BGB bei vorzeitiger Vertragsbeendigung mit einer Pauschale regelt, ist § 308 Nr. 7a BGB in entsprechender Anwendung. Wegen der vergleichbaren Interessenlage ist

67

1 § 649 BGB passt insoweit auf Softwareverträge und deren Kalkulationsspanne mit der 5 %-Regelung überhaupt nicht, s. Redeker, ITRB 2012, 42. 2 BGH v. 27.1.2011 – VII ZR 133/10, LSe, NJW 2011, 915. 3 BGH 24.3.2011 – VII ZR 146/10, LSe.

Schneider

173

B Rz. 68

Grundlagen

auch § 309 Nr. 5b BGB entsprechend anzuwenden (vgl. BGH-Urt. v. 10.10.1996 – VII ZR 250/94, MDR 1997, 139). b) Ist dem Besteller durch eine solche Klausel der Nachweis gestattet, dass die dem Unternehmer nach § 649 BGB zustehende Vergütung wesentlich niedriger ist als die Pauschale, so kommt dadurch hinreichend klar und den Anforderungen des Gesetzes genügend zum Ausdruck, dass auch der Nachweis gestattet ist, dem Auftragnehmer stehe überhaupt keine Vergütung zu. c) Eine Klausel, die den entgangenen Gewinn und die bis zur Kündigung getätigten Aufwendungen pauschaliert, hält einer Überprüfung anhand des § 308 Nr. 7a BGB nur stand, wenn sie sich im Rahmen der gemäß § 649 Satz 2 BGB typischerweise zu beanspruchenden Vergütung hält. Werden mit der Pauschale 15 % des vereinbarten Werklohns geltend gemacht, sind für die Angemessenheitskontrolle dazu konkrete tatsächliche Feststellungen zu treffen.“1

68 „Der Unternehmer kann seinen Anspruch auf Vergütung nach einer freien Kündigung des Werkvertrags nur dann auf die Vermutung in § 649 Satz 3 BGB stützen, wenn er den Teil der vereinbarten Vergütung darlegt, der auf den noch nicht erbrachten Teil der Werkleistung entfällt. Denn dieser Teil und nicht die gesamte vereinbarte Vergütung ist Bemessungsgrundlage für die Pauschale von 5 %.“2

69 Die Rspr. des BGH führt bei Software-Projekten wegen der speziellen Verhältnisse bei der Kalkulation zu Ergebnissen, die für den Auftragnehmer schwer erträglich sind3. Eine entsprechende Regelung gibt es bei Kaufrecht selbst nicht. Kaufrecht wäre für die Projekt-Unternehmer insofern „attraktiv“. Die Verweisung in § 651 Satz 3 BGB wonach auch § 649 BGB gilt, würde nicht bei Herstellung von Individualsoftware greifen. 3. §§ 642, 643 BGB 70 Es wird also ausführlicher Regelungen bedürfen, dass zum einen die Mitwirkung möglicherweise in den Rang von Hauptleistungspflichten aufsteigt (so dass die Zweifel vermieden werden, ob vielleicht doch noch Nebenleistungen vorliegen, wie dies im Hinblick auf §§ 642, 643 BGB nahe liegen würde), und klar ist, welche Pflichten der Auftragnehmer hat, diese Mitwirkungsleistungen einzufordern, rechtzeitig zu präzisieren und zu überwachen (etwa anhand des Aktivitäten- und Fristenplans). 71 Soweit es sich um Standardsoftware handelt, würde zudem bei Anwendung von Kaufrecht keine Mitwirkungsregel greifen. Ist im Vertrag dazu nichts vorgesehen, stellt sich die Frage, wie man die rechtliche Grundlage für diese Mitwirkungspflichten, wie sie jeder Auftragnehmer für selbstverständlich gegenüber dem Auftraggeber hält, begründen könnte. Bei Individualsoftware würde sich die Mitwirkungspflicht aus § 651 Satz 3 BGB ergeben, ebenso auch das Kündigungsrecht des Auftragnehmers nach § 643 BGB.

1 BGH v. 5.5.2011 – VII ZR 161/10, LSe, CR 2011, 639. 2 BGH v. 28.7.2011 – VII ZR 45/11, CR 2011, 752. 3 S. Redeker, Der Entschädigungsanspruch des Unternehmers nach einer Kündigung nach § 649 BGB, ITRB 2012, 42.

174

Schneider

Sachqualität der Software und § 651 BGB

B

Rz. 73

4. Mängelrechte Auch die Anwendung des § 377 HGB bei Kaufrecht ist für den Unternehmer 72 günstig: Diese Regelung würde den Auftraggeber voll treffen. Die Frage, ob § 377 HGB Anwendung finden kann, ist von sehr praktischer Relevanz1. Nicht zuletzt, um gerade die Untersuchungs- und Rügepflicht zu vermeiden, wird die Nicht-Anwendung des § 651 BGB angestrebt2. Das Arsenal der Mängelrechte des Auftraggebers ist bei Werkvertrag noch 73 insofern wesentlich bedrohlicher für den Unternehmer, als der Auftraggeber zur Selbstvornehme schreiten kann. Zum Vergleich folgende Übersicht: Kaufvertrag

Werkvertrag

Vertragsgegenstand

– Übergabe und Übereignung einer Sache frei von Sach- und Rechtsmängeln – diesbezüglich keine Mitwirkung des Käufers vorgesehen

– Herstellung eines Werkes bzw. Herbeiführung eines bestimmten Erfolges frei von Sach- und Rechtsmängeln – Mitwirkung des Bestellers dabei geregelt, s. § 642 BGB

Mangelbegriff

– vorrangig vereinbarte Beschaffenheit ausschlaggebend – vertraglich vorausgesetzte Verwendung – gewöhnliche Verwendung, übliche Beschaffenheit; – diese wird auch durch öffentliche Äußerungen (insbes. Werbeangaben) des Verkäufers/Herstellers/Gehilfen bestimmt

– vorrangig vereinbarte Beschaffenheit ausschlaggebend – vertraglich vorausgesetzte Verwendung – gewöhnliche Verwendung, übliche Beschaffenheit – Keine Haftung für Werbeangaben

Nacherfüllung (Wahl zwischen Nachbesserung oder Nachlieferung)

– Wahlrecht des Käufers – Verkäufer kann die vom Käufer gewählte Art der Nacherfüllung bei unverhältnismäßigen Kosten verweigern

– Wahlrecht des Unternehmers – Unternehmer kann die Nacherfüllung bei unverhältnismäßigen Kosten verweigern

1 S. schon bejahend für Werklieferungsvertrag BGB a.F. BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681 (Herstellung des Werkes aus vom Unternehmer zu beschaffenden Programmen), abgegrenzt in BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93 (Arbeiten an bereits beim Auftraggeber vorhandener Software, die dieser zur Verfügung stellt). 2 S. Fritzemeyer, Die rechtliche Einordnung von IT-Verträgen und deren Folgen, NJW 2011, 2918 (2919) m.w.N.

Schneider

175

B Rz. 73

Grundlagen Kaufvertrag

Werkvertrag

– Verkäufer hat grds. inner- – grds. keine Beschränkung halb einer angemessenen der Zahl der NachbesseFrist 2 Nacherfüllungsverrungsversuche suche, es sei denn, es ergibt sich etwas anderes insbesondere aus der Art der Sache, des Mangels oder aus den sonstigen Umständen Mängelrechte des Käufers/Bestellers bei Scheitern der Nacherfüllung

– keine Regelung der Selbstvornahme – Rücktritt vom Vertrag (grds. erst nach Fristsetzung des Käufers) oder – Minderung des Kaufpreises und – Schadensersatz (grds. erst nach Fristsetzung des Käufers) oder – Ersatz vergeblicher Aufwendung

– Selbstvornahme (Besteller kann den Mangel selbst beseitigen) i.V.m. Ersatz der erforderlichen Aufwendungen – Rücktritt vom Vertrag (grds. erst nach einer Fristsetzung des Bestellers) oder – Minderung des Kaufpreises und – Schadensersatz (grds. erst nach Fristsetzung des Bestellers) oder – Ersatz vergeblicher Aufwendung

Verjährungsfristen – grds. 2 Jahre bei mangelhaften IT-Leistungen von Mängelan(§ 438 Abs. 1 Nr. 3 BGB) sprüchen (ungeachtet evtl. – 3 Jahre, wenn der VerkäuVerkürzung) fer den Mangel arglistig verschwiegen hat (§ 438 Abs. 3 BGB)

– 2 Jahre bei Werken, deren Erfolg in der Herstellung, Wartung oder Veränderung einer Sache oder in Planungs- und Überwachungsleistungen hierfür besteht, § 634a Abs. 1 Nr. 1 BGB – 3 Jahre bei anderen ITLeistungen (§ 634a Abs. 1 Nr. 3 BGB) – 3 Jahre, wenn der Unternehmer den Mangel arglistig verschweigen hat (§ 634a Abs. 3 BGB)

Beginn der Verjährung

– mit Abnahme des Werkes (§ 634a Abs. 2 BGB) hinsichtl. § 634a Abs. 1 Nr. 1 BGB, nicht hinsichtlich § 634a Abs. 1 Nr. 3 BGB! – Abnahme in § 640 BGB geregelt

176

Schneider

– mit Ablieferung der Sache (§ 438 Abs. 2 BGB) – Ablieferung nicht geregelt

Sachqualität der Software und § 651 BGB

Rz. 76

B

Kaufvertrag

Werkvertrag

Regress

Regress in der Lieferkette (§§ 478 f. BGB)

Grds. kein Regress

§ 377 HGB Untersuchungs- und Rügepflicht

auf einen beiderseitigen Handelskauf (d.h. vereinfacht auf einen Kaufvertrag zwischen Unternehmern) anwendbar

auf den „reinen Werkvertrag“ (auch zwischen Kaufleuten) nicht anwendbar (BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93).

Bei Anwendung des § 651 BGB beurteilt sich ein Vertrag über neu herzu- 74 stellende Sachen nicht nach Werk-, sondern nach Kaufvertragsrecht. Das Kaufrecht wird ergänzt um einige werkvertragliche Vorschriften, z.B. Mitwirkung des Bestellers, wenn eine nicht vertretbare neue bewegliche Sache (Spezialanfertigung) hergestellt wird. Die Unterschiede zwischen den beiden Vertragstypen sind zwar nicht mehr so groß wie nach altem Schuldrecht, aber in der Praxis und im Detail durchaus gravierend. Wäre etwa Kaufrecht für die Softwareerstellung anwendbar, müssten öffentlichen Äußerungen des Anbieters i.S.v. § 434 Abs. 1 Satz 3 BGB bei der Beurteilung eines Mangels der Software berücksichtigt werden. 5. Abnahme Es fehlen häufig schon in traditionell gestalteten Verträgen Regelungen, 75 nach welchen Kriterien und welchem Verfahren die Abnahme durchzuführen ist. Regelungen zu Testsystem, parallelem Betrieb, Inbetriebnahme als Abnahmevoraussetzung (und nicht als konkludente Abnahmeerklärung), unterbrechungsfreie Erprobung ohne die Abnahmeprüfung hindernde Mängel und ohne Nachbesserungen fehlen häufig. Stattdessen enthalten viele Verträge eine Klausel, wonach sich die Parteien noch im Laufe des Projekts auf Abnahmekriterien einigen (sollen). Dies ist äußerst riskant. Die Performance und andere Kriterien (z.B. Fehlerklassen) gehören zum Pflichtenheft bzw. den Anlagen zum Vertrag, anhand derer die Leistung und somit die Abnahmefähigkeit ermittelt werden kann1. Die praktische Empfehlung geht also dahin, Testsystem, Testverfahren bis Produktivsetzung, Test- und Abnahmekriterien, Verfahren zur Gewinnung

1 BGH v. 3.11.1992 – X ZR 83/90, CR 1993, 352 – Vorauss. stillschweigender Werkabnahme trotz expliziter Abnahmeregelung; BGH v. 12.3.1992 – VII ZR 5/91 – Ablieferungskontrolle, MDR 1992, 675 = NJW 1992, 1754; BGH v. 2.11.1995 – X ZR 93/93, CR 1996, 667 – Keine Abnahme, wenn Funktionsfähigkeit erst im Laufe der Benutzung feststellbar und AG Mängel sofort gerügt hat; BGH v. 13.3.1996 – VIII ZR 333/94, MDR 1996, 697 = DB 1996, 1275; BGH DB 1996, 2924 – Befundsicherungspflicht/Beweislast bei Nichtfunktion der Datensicherung; s.a. OLG Hamm v. 10.5.1999 – 13 U 95/98, CR 2000, 289.

Schneider

177

76

B Rz. 77

Grundlagen

i.V.m. Abnahmeverfahren rechtzeitig vor Vertragsschluss festzulegen, dabei auch Fehlerklassen i.V.m. SLA, Schadenspauschalierungen u.Ä. Anstatt „Abnahme“ sollte es vorsorglich heißen Feststellung ordnungsgemäßer Leistungserbringung o.Ä. 77 Die wichtigste Maßgabe dürfte sein, dass anstatt der bei deutschen Verträgen durchaus üblichen Kurzfassung der Regelungen mit direkter oder indirekter Bezugnahme auf bestimmte Paragraphen eine ausführliche Darstellung des Gewollten erfolgt. Statt des schönen Satzes „Die Verjährungsfrist für Sach- und Rechtsmängel beginnt mit der Abnahme des vollständigen Werkes“ wird man im Einzelnen regeln: – Tests des Auftragnehmers1, – Schulungen, Einweisungen (i.V.m. Vorliegen der Dokumentationen), – Abnahmeprüfung durch den Auftraggeber2, – Abnahmekriterien einschließlich Testkriterien, – Testverfahren und Testvoraussetzungen einschließlich Datenübernahme, – Kriterien für das Vorliegen der Voraussetzungen für die Feststellung der „Vertragsgemäßheit“ im Sinne der Übereinstimmung mit dem Pflichtenheft, Kap. C Rz. 69 ff.) – evtl. Ausgrenzung oder explizite Einbeziehung von Werbeaussagen (Rz. 73 f. u. Kap. C Rz. 65), – Leistungsbeschreibung und – deren im Laufe des Projekts erfolgten Änderungen – Verjährungsregelung für Mängelrechte (Rz. 72), v.a. zu – Beginn, Kriterien für klare Befunde wie Ablieferung, Echtbetrieb, – Dauer, – Wahlrecht und Unzumutbarkeit sowie Folgen, – Beweislast für Vertragsgemäßheit bzw. Mängel nach Phasen (s. Kap. C Rz. 357 ff.) i.V.m. – Übergabe Dokumentationen (mit Verbindung zu Schulung,), Quellcode u.Ä. 6. Dokumentation3 78 Eine der klassischen Arten der Prüfung der Vertragsgemäßheit („Abnahmereife“) ist, die Software gegen die Leistungsbeschreibung, dann die Do1 S.a. ausführlich Kap. G Rz. 1 ff. 2 S.a. Kap. D Rz. 194 ff.; Kap. G Rz. 317 ff. 3 Beckmann, CR 1998, 519; zu Beurteilungskriterien (str.) s. Brandt, CR 1998, 571; s.a. Bergmann, CR 1999, 455 speziell zu Handbüchern für Softwareanwender, Bericht vom 7. Deutschen EDV-Gerichtstag; Ulmer, ITRB 2001, 61 (Elektronischer Ersatz für Handbücher); Backu, ITRB 2001, 48; Stopp, ITRB 2000, 17; s. Kap. D Rz. 119 ff.

178

Schneider

Sachqualität der Software und § 651 BGB

Rz. 84

B

kumentation gegen Software und Leistungsbeschreibung zu prüfen. Dies betrifft nicht nur die Anwendungshandbücher. Die Erstellung der Dokumentation als expliziter Vertragsgegenstand verstärkt, wenn gewünscht, das werkvertragliche Moment. Zu diesem Zweck sollte ausdrücklich und möglichst plastisch beschrieben werden, welche Arten von Dokumentation wann zu übergeben sind.

79

7. Überprüfung der Ergebnisse (1) Eine rein dogmatische Lösung, nämlich die Sachqualität abzulehnen 80 und/oder eine teleologische Auslegung vorzunehmen bzw. eine Reduktion zur Umgehung von § 651 BGB ist zwar möglich, aber kaum mit einer vernünftigen Verjährungsfrist für die Mängelhaftung vereinbar. Infolgedessen sind diese Bemühungen dogmatischer Art eher problematisch. Man handelt sich sozusagen mit einer eleganten Lösung auf der einen Ebene ein äußerst ungünstiges wirtschaftliches Ergebnis, zumindest was die Anbieterseite betrifft, auf der anderen ein. Was die Anwenderseite betrifft, führt dieses Vorgehen zumindest zu einer erheblichen Rechtsunsicherheit. (2) Erfolgversprechender erscheint es deshalb, den Weg zu gehen, den Vertrag möglichst neutral unabhängig von dieser Problematik zu gestalten.

81

(2.1) Die Vertragsgegenstände

82

– Planung und – Realisierung werden in verschiedenen Vertragsteilen, ggf. in gesonderten Verträgen geregelt. Der Vertragsgegenstand Planung lässt sich sehr gut, wenn dies gewünscht wird, vertragstypologisch als Werkvertrag einordnen. Die Alternative ist, je nach Erfolgsabhängigkeit, der Dienstvertrag, nicht der Kauf. (2.2) Dieser Vertrag über die Planung kann ggf. auch erweitert werden. Die 83 Endstufe ist nicht etwa nur die Gewinnung und Erstellung des fachlichen Feinkonzepts, sondern vielleicht sogar die Erstellung des technischen Feinkonzepts durch den Auftragnehmer. Dies überschreitet dann schon die Grenze zur Realisierung, erscheint aber unschädlich. Es kann als Planungsleistung immer noch bei der vertragstypologischen Einordnung als Werkvertrag verbleiben. (2.3) Unabhängig von den beiden vorstehenden Lösungen erstellen die Ver- 84 tragspartner neben der Leistungsbeschreibung einen Aktivitäten- und Fristenplan1, der im Einzelnen festlegt, wer was wann von den beiden macht und zwar auch, wer dabei die Federführung hat, wenn beide es gemeinsam zu tun haben. Ein solches „Pflichtenprogramm“ kann auch dann wirksam vereinbart werden, wenn der Vertrag sich nach Kaufvertragsrecht beurteilt. Es handelt sich insoweit um ein Pflichtenprogramm, das zu erfüllen erfor1 S.a. Kap. G Rz. 199, 203; Kap. H Rz. 76 f.

Schneider

179

B Rz. 85

Grundlagen

derlich ist, um das Vertragsziel zu erreichen. Dass beim Kauf dann, wenn Standardsoftware herzustellen wäre und die §§ 433 ff. BGB angewandt werden, keine gesetzlichen Mitwirkungsvorschriften bestehen, ist dabei unschädlich. 85 (2.4) Als Argument kann wohl herangezogen werden, dass bei äußerst aufwändigen Gegenständen, wie z.B. Maschinen für die Produktion zunächst häufig der Kauf dieser Maschine im Vordergrund steht und dem Vertrag das monitäre Gewicht gibt. Der Aufstellungsteil, auf Software übertragen die „Installation“, kann werkvertraglich beurteilt werden. Es verstand sich schon bisher, dass nicht nur im Hinblick auf die Aufstellung, sondern schon im Hinblick auf die Anlieferung und Platzierung der Maschine im Gebäude den Käufer erhebliche Vorleistungspflichten treffen1. 86 Das Gesetz selbst geht davon aus, dass durchaus in Verbindung mit dem Kauf eine Montageverpflichtung bestehen kann, ohne dass dadurch der Vertragstyp „kippt“. Dies ergibt sich aus § 434 Abs. 2 BGB, in dem der Montagefehler als Sachmangel qualifiziert wird (Satz 1). 87 (2.5) Bei vielen Verträgen, in denen es um die Einstellung der Parameter oder um das mit Tools unterstützte Anpassen an die Belange des Kunden geht, und an der Software wenig oder nichts verändert wird (jedenfalls nicht mehr, als bei einem Schrank der aufgebaut wird und in den alle Schrauben und Nägel eingebaut werden, wo vielleicht sogar wesentliche Arbeiten hierzu von den Mitarbeitern des Kunden ausgeführt werden), könnte nicht nur der Schwerpunkt wie oben bereits angedeutet in der Planungsleistung liegen, was den eigentlichen Vertragskern betrifft, sondern auch in der Projektleitung. Auch diese, als „Überwachung“ qualifiziert, kann werkvertraglich eingeordnet werden (sie kann auch vertraglich als Dienstvertrag ausgestaltet werden). Der Aktivitäten- und Fristenplan regelt diese Aufgaben unter Umständen vertragstypunabhängig. So gesehen kann der Aktivitätenund Fristenplan auch das Ergebnis der Planungsleistung sein, was die weitere Vorgehensweise betrifft. 88 (2.6) Wenn man auf dem vorbezeichneten Wege der vorstehenden Maßnahmen den Kern dessen, was bei der Realisierung zu leisten ist, auf das Einstellen der Parameter entsprechend dem Ergebnis der Planungsleistungen praktisch eingrenzt, bei neu zu erstellender Software auf die eigentliche Programmierung, so ist Folgendes nicht zu vergessen: Ein wesentlicher Teil dieser Arbeiten besteht dann in der Erstellung mehrerer Dokumentationen, nämlich der Anwender-Dokumentation, der Operator-Anweisung, der Quellcode-Dokumentation und vielleicht auch dem Datenmodell bzw. den Strukturmodellen. Infolgedessen entsteht mit der Software auch ein erheblicher Anteil körperlicher Gegenstände, wenn man diese nicht wie Archi1 Zum Vertragstyp Kaufvertrag bei einer umfangreicheren Anlage s. z.B. BGH v. 22.7.1998 – VIII ZR 220/97, MDR 1998, 1274 = NJW 1998, 3197 – wobei es in der Entscheidung um die Rückabwicklung eines Kaufvertrages mit Montageverpflichtung ging.

180

Schneider

Sachqualität der Software und § 651 BGB

Rz. 91

B

tekturleistungen behandelt. Da sie letzten Endes nicht die Planungsvorgabe sind, wie etwa beim Architekten, sondern das Ergebnis der Umsetzung der Planung (also der Bauleistung analog), erscheint die Betonung der Sachqualität in diesem Zusammenhang unproblematisch. Soweit also Parteien besonderen Wert darauf legen, dass ihr Vertrag über die Realisierung als Werkvertrag qualifiziert wird, können sie dies am besten über diese Betonung der Dokumentationen und andere, auf Erstellung einer „Sache“ gerichtete Leistungen erreichen. (2.7) Kriterien, deren Erfüllung die Voraussetzung für

89

– weiteres Vorgehen – Zahlungen, – Vermeidung von Kündigung, Strafen und Schadensersatz ist, umschreiben den „Erfolg“, ohne dass es auf den Werkvertrag ankommt, auch in SLA. 8. Hinterlegung Auch die Hinterlegungs-Vereinbarung sollte schließlich diesen „ding- 90 lichen“ Charakter des Gegenstandes betonen bzw. berücksichtigen1. Dazu kann die Übereignung des Quellcodes gehören und zwar in einer absoluten Form, die nur durch schuldrechtliche Vereinbarungen korrigiert wird. Es ist möglicherweise so, dass eine solche Konstruktion der einzig insolvenzfeste Weg der Softwarehinterlegung ist. Auch in diesen Fällen manifestiert sich ein erheblicher Teil in Form von Unterlagen/Materialien, die an der Übereignung teilnehmen. Oben war schon auf Marly hingewiesen worden, der wiederum seinerseits auf den misslichen Umstand hindeutet, dass eine Übereignung nicht mehr denkbar ist, wenn man Software die Sachqualität abstreitet2. Mit den vorstehenden Vertragstypen und Konstruktionen lässt sich ein für 91 die Praxis durchaus adäquater Weg mit genau dem Ergebnis herstellen, das die Befürworter einer Anwendung von Werkvertragsrecht wollen, ohne dass an den Grundlagen, nämlich der Interpretation des § 651 BGB besondere Abstriche gemacht werden müssten, insbesondere keine Umgehung vorgenommen werden muss. Insofern erscheint dieser Weg als der letztlich erfolgreichere. Er entspricht sogar einer Intention der Schuldrechtmodernisierung, nämlich eine Intensivierung der Verhandlungen der Vertragspartner über ihr „Pflichtenprogramm“.

1 S.a. ausführlich Kap. L. 2 Marly, Praxishandbuch Softwarerecht, 5. Aufl., Rz. 695.

Schneider

181

B Rz. 92

Grundlagen

IV. Rechtsprechung zu § 651 BGB n.F. 1. Überblick über Entscheidungen v.a. des BGH 92 Die bislang zu § 651 BGB n.F. ergangenen Entscheidungen, die als wichtige Auslegungs- bzw. Anwendungshilfen heranzuziehen sind, haben sich nur zum Teil mit den vorstehenden Gegenständen befasst. Zum besseren Verständnis werden diese Entscheidungen nun chronologisch aufgeführt. 93 Der BGH hat in einer Entscheidung vom 23.7.2009 einen Vertrag über die Lieferung von Bauteilen, die der Errichtung einer Siloanlage dienten, beurteilt. Generell, ohne IT-Bezug, hat der BGH typischen Argumentationen, wie § 651 BGB und dessen Anwendung zu umgehen ist, eine klare Absage erteilt. Dazu gehörte auch die Methodik der sog. teleologischen Reduktion1. 94 Der BGH zieht in Betracht, dass ggf. die Planung bei dem Vertragsinhalt eine so große Rolle spielt, dass die Anwendung des Werkvertragsrechts darauf zu erfolgen hat, auch wenn der zu planende Gegenstand selbst sich nach § 651 BGB beurteilen würde, nämlich als neu herzustellende Sache. Im konkreten Fall war der Planungsanteil als nicht genügend gewichtig angesehen worden, um diese andere Einordnung vorzunehmen. 95 V.a. Schweinoch hat sich dafür ausgesprochen, diese Entscheidung des BGH auf IT-Verträge, speziell Softwareverträge anzuwenden2. Die überwiegende Meinung lehnte aber die Anwendung dieser Entscheidung rigoros mit unterschiedlichen Argumenten bereits ab3. Für die Erstellung von Software scheidet die Anwendung dieser Entscheidung nach Meinung mancher Autoren allein deshalb schon aus, weil Software insoweit oder keine Sache sei4. 96 Das OLG München hatte die Entscheidung des BGH v. 9.7.2009 zwar berücksichtigt, als es um einen Softwareentwicklungsvertrag ging, jedoch entschieden, dass § 651 BGB bzw. die BGH-Entscheidung nicht auf Softwareerstellung anwendbar sei: „Dies gilt auch dann, wenn ein Standardprogramm den individuellen Bedürfnissen des Anwenders angepasst wird (…) … . 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, so dass 1 BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637 m. Anm. Schweinoch, Rz. 16. 2 Schweinoch, CR 2010, 1 unter Berücksichtigung der Erweiterung seines Anmerkungs-Beitrags zu BGH v. 23.7.2009, CR 2009, 637. 3 S. Maume/Wilser, CR 2010, 209; Müller-Hengstenberg, NJW 2010, 1181; s.a. Bartsch, CR 2010, 553; Heydn, CR 2010, 765. 4 S. v.a. Bartsch, CR 2010, 553; Heydn, CR 2010, 765.

182

Schneider

Sachqualität der Software und § 651 BGB

Rz. 101 B

die Entscheidung des BGH v. 23.7.2009 (NJW 2009, 2877 – Silowände) nicht einschlägig und vergleichbar ist.“1 Eine zirkuläre Argumentation, es handle sich nicht um einen Kaufvertrag 97 und deshalb sei die Entscheidung des BGH nicht anwendbar, ist nicht zu verkennen. Jedoch ist der Trend i.V.m. der zitierten Literatur erkennbar, nämlich Softwareerstellung nicht als die Herstellung einer beweglichen Sache anzusehen. Eine Fortsetzung der BGH-Entscheidung v. 23.7.2009 ergab sich insofern 98 mit der Entscheidung v. 9.2.2010, als dort das Thema Planungsleistungen aufgegriffen wurde2. Auch in dieser Entscheidung befasste sich der BGH mit der Frage, inwieweit Planungs- und Konzeptionsarbeiten, die mit der Herstellung der Sache einhergehen, zu berücksichtigen sind. Noch klarer als in der vorausgehenden Entscheidung sagt der BGH, dass typische Planungsleistungen nichts an der Anwendung des § 651 BGB ändern3. Festzuhalten ist, dass bis dahin die Diskussion sich also sehr stark um den Sachbegriff herum kristallisiert hatte. Dabei wurde mehrfach übersehen, dass die Fragestellung, inwieweit die Sachqualität gegeben ist bzw. wie sie zu beurteilen ist, europarechtskonform zu erfolgen hat4.

99

Der 3. Senat nahm eine Entscheidung zu einem Internetsystemvertrag als 100 Gelegenheit, einen Großteil der oben genannten Vertragsgegenstände jeweils mit der Internet-basierten Variante zu vergleichen und daraufhin zu untersuchen, inwieweit eine Anwendung des § 651 BGB in Betracht kommt. Der BGH befasst sich u.a. mit dem Internetsystemvertrag selbst und gibt sodann die Meinungsbilder zu weiteren, verwandten Gegenständen wieder, da dieser Vertrag zum „Kreis der Internetproviderverträge“ gehöre. Es wird also abgehandelt der Access-Provider-Vertrag5, der Application-Service-Vertrag und der Webhostingvertrag, dann schließlich der Webdesignvertrag6. Der Webdesignvertrag wird als vergleichbar mit dem „Vertrag über die Er- 101 stellung und Bearbeitung einer speziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software“ angesehen7. Und dazu heißt es nun: Ein solcher Vertrag „dürfte regelmäßig als Werkvertrag i.S.d. §§ 631 ff. BGB, unter Umständen auch als Werklieferungsvertrag i.S.v. § 651 BGB anzusehen“ sein8. Welche Umstände dies sind bzw. sein könnten, wird nicht aus1 OLG München v. 23.12.2009 – 20 U 3515/09, CR 2010, 156, 157; s. dazu a. kritisch: Mankowski, CR 2010, 137. 2 BGH v. 9.2.2010 – X ZR 82/07 – Tiefladesattelaufleger, CR 2010, 580. 3 BGH v. 9.2.2010 – X ZR 82/07 – Tiefladesattelaufleger, CR 2010, 580 (LS). 4 S.a. Mankowski, CR 2010, 137. 5 BGH v. 4.3.2010 – III ZR 78/09 – Internetsystemvertrag, CR 2010, 327, Rz. 18 m.w.N.: Dienstvertrag. 6 BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327. 7 BGH v. 4.3.2010 – III ZR 78/09, CR 2010, 327, Rz. 21 m. zahlr. N. 8 BGH v. 4.3.2010 – III ZR 78/09, CR 2010, 327, Rz. 21.

Schneider

183

B Rz. 102

Grundlagen

geführt. Es bleibt offen bzw. dunkel, welche Kriterien solche „Umstände“ bilden, deren Vorliegen zur Ausnahme führen würde1. Jedoch ist dies vielleicht nicht so gravierend, da der BGH zuvor im Zusammenhang mit der Zuordnung von Internet-Verträgen zu den Vertragstypen des BGB herausgestellt hat, dass die Qualifizierung als Werkvertrag im konkreten Fall „… ihr maßgebliche Grundlage in dem von den Parteien vereinbarten Vertragszweck, wie er in der vertraglichen Leistungsbeschreibung und dem hieran anknüpfenden Parteiwillen, insb. auch in der verobjektivierten Kundenerwartung, zum Ausdruck kommt …“2. 102

Wenig später hatte der BGH einen IT-Vertrag zu beurteilen, der eine besondere Vertragsgestaltung aufwies und auch eine ungewöhnliche inhaltliche Gestaltung, was also die Begründung betrifft. Es ging um einen Vertrag, bei dem ein Nutzungskonzept zu erstellen, ein Prototyp und später ein Pilotsystem zu entwickeln und zu installieren waren. Man hätte also vielleicht über das (Über-)Gewicht der Planung spekulieren können. Es handelt sich laut Vorinstanz3 zu BGH v. 25.3.20104 um ein „Software-Projekt“. Dabei wurde das Thema § 651 BGB weder vom OLG noch in der I. Instanz behandelt bzw. aufgebracht. Auch der BGH erwähnte diese Vorschrift nicht und zieht erst recht nicht in Betracht, ob § 651 BGB anzuwenden sei. D.h. also, das Thema spielt keine Rolle. Es ging nur um die Frage der Leistungsaufforderung. Dies im Rahmen des § 281 Abs. 1 BGB. Die werkvertragliche Einordnung war insofern kein für die Frage der Fristsetzung kritischer Gegenstand. Dennoch ist für die Frage der Anwendung des § 651 BGB die Entscheidung relevant, allerdings im Sinne eines „Orakels“. Entweder die Frage bedurfte nicht einmal der Erwähnung, so klar ist bereits die Antwort5. Oder aber, der besondere Charakter der Fallgestaltung gab keinen Anlass zur Prüfung: die Software war beim Auftraggeber und sollte für diesen angepasst werden.

103

Insofern kann man diese Entscheidung in zweierlei Richtung interpretieren. Die eine ist, dass das Thema offen blieb, was die Einordnung nach § 651 BGB betraf, weil insoweit kein Anlass dazu bestand. Auch bei einer Leistung, die im übrigen als Kaufvertrag zu beurteilen wäre, würde sich die Leistungsaufforderung bzw. deren Kriterien an eine richtige Leistungsaufforderung nach § 281 Abs. 1 Satz 1 BGB beurteilen.

104

Die Alternative wäre, dass der BGH durch Schweigen die Variante, dass überhaupt § 651 BGB zur Anwendung kommen könnte, ausgeschlossen hat 1 S.a. Fritzemeyer, Die rechtliche Einordnung von IT-Verträgen und deren Folgen, NJW 2011, 2918 (2920). 2 Hierauf weist auch Fritzemeyer hin (Die rechtliche Einordnung von IT-Verträgen und deren Folgen, NJW 2011, 2918 [2921]). 3 OLG Düsseldorf v. 2.10.2008 – I-7 U 82/07, Rspr.-DB NRW 20081002. 4 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422. 5 Die Einstufung als Werkvertrag sei so richtig: Bartsch, CR 2010, 777 zu BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 423.

184

Schneider

Sachqualität der Software und § 651 BGB

Rz. 106 B

und dies auch ausschließen wolle. Dies erscheint aber eine etwas übertriebene Interpretation der in der Regel eher restriktiv zu interpretierenden BGH-Entscheidungen. Das besondere an dieser Entscheidung ist der Sachverhalt, der sich in Tz. 14 versteckt: „1. Zutreffend und von der Revision nicht beanstandet, hat das Berufungsgericht die als „Dienstleistungsvertrag für ein P.Softwaresystem“ bezeichnete vertragliche Vereinbarung vom 28.7.2004 als Werkvertrag qualifiziert. Gegenstand dieses Vertrags war eine umfangreiche Anpassung der P.Software der Beklagten an die Bedürfnisse der Klägerin und die Schöpfung von Schnittstellen zur CWL. Welche rechtliche Qualität dem ‚Vertrag für ein P.Softwaresystem‘ zukommt, kann dahingestellt bleiben, weil die Klägerin auch dessen Grundlage keine Ansprüche geltend macht.“1 Die für die Würdigung dieser Entscheidung wichtige Besonderheit besteht 105 also darin, dass der Beschaffungsvertrag ausdrücklich ausgeklammert und ihm keinerlei Gewicht bei der Beurteilung des Vertrags beigemessen werden konnte und wurde. Andererseits ist richtig, dass der BGH ausdrücklich den Vertrag hinsichtlich der umfangreichen Anpassungen als Werkvertrag qualifiziert hat. Der BGH hat aber nicht einmal angedeutet, wie er dem hier in Frage stehenden Anpassungsvertrag in Kombination mit diesem Beschaffungs-Vertrag beurteilen würde. Diese Konstellation wurde ausdrücklich nicht zu behandelt2. 2. Bestehende bzw. verbleibende „Lücken“ für die Anwendung des § 651 BGB Aus den zitierten BGH-Entscheidungen ergeben sich folgende „Lücken“ – 106 Fälle, in denen doch § 651 BGB und in der Folge Kaufrecht anwendbar ist bzw. sein kann – und Impulse für die Anwendung des § 651 BGB bei Software-Erstellung und -Anpassung: 1. Die Herstellung von Standardsoftware – war (noch) nicht Gegenstand von BGH-Entscheidungen. Sie könnte sich über § 651 BGB nach Kaufrecht beurteilen3. 2. Die Herstellung von Individualsoftware wird grundsätzlich als Werkvertrag zu qualifizieren sein, unter besonderen Umständen allerdings über

1 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422. 2 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422, Rz. 14: „1. Zutreffend und von der Revision nicht beanstandet hat das Berufungsgericht die als „Dienstleistungsvertrag für ein P. Software-System“ bezeichnete vertragliche Vereinbarung vom 28. Juli 2004 als Werkvertrag qualifiziert. Gegenstand dieses Vertrags war eine umfangreiche Anpassung der P. Software der Beklagten an die Bedürfnisse der Klägerin und die Schaffung von Schnittstellen zur CWL. Welche rechtliche Qualität dem „Vertrag für ein P. Software-System“ zukommt, kann dahingestellt bleiben, weil die Klägerin auf dessen Grundlage keine Ansprüche geltend macht.“ 3 Rückschluss aus vorzitierter Entscheidung: BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422, Rz. 14; s.a. dazu Rz. 102.

Schneider

185

B Rz. 107

Grundlagen

§ 651 BGB nach Kaufrecht1. Worin die „besonderen Umstände“ bestehen, erschließt sich allenfalls über die insoweit zitierte Literatur, s. oben Rz. 101. 3. Die Anpassung ohne Beschaffungsvertrag beurteilt sich nur nach Werkvertragsrecht2. 4. Die Anpassung von Software in Kombination mit dem Beschaffungsvertrag – offen3. 5. Der Planungsvertrag ist reines Werkvertragsrecht, wenn der Vertrag wie die Erstellung eines Gutachtens beurteilt wird. Ansonsten käme hier v.a. Dienstvertrag in Betracht, was auch für die übrigen Verträge gilt, wenn jeweils kein Erfolg geschuldet wurde. Insofern stellt sich dann aber das Problem § 651 BGB nicht. 107

Dies ist ein Zwischenergebnis. Es gilt v.a. für das konventionelle Vorgehen (prototypisch „Wasserfallmodell“), mit strikter Trennung von Planung und Realisierung. Bei getrennter Beurteilung4 würde die Planung als Erstellung des „Pflichtenhefts“ im juristischen Sinne als Werkvertrag zu qualifizieren sein, die Realisierung als Werkvertrag bzw. über § 651 BGB – wenn man dem vorstehenden Schema folgt – in den Fällen 1., evtl. 2 und 4.

108

Bei moderner Projektmethodik, etwa Agiler Methodik5, lässt sich die Planung nicht oder kaum vom Realisieren trennen. Wenn man diese Leistung aber anteilsmäßig stark veranschlagt6, käme in der Folge § 651 BGB noch weniger in Betracht7.

109

Mit BGH v. 27.1.20118 wurde die Anwendung von Werkvertragrecht unter ausdrücklichem Bezug auf BGH v. 4.3.20109 bestätigt, indirekt auch noch durch BGH v. 24.3.201110.

1 BGH v. 4.3.2010 – III ZR 78/09, CR 2010, 327. 2 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422. 3 Rückschluss aus BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422, Rz. 14 i.V.m. BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681 – Verkaufsabrechnung, s. oben Rz. 102. 4 S. Kap. C Rz. 195 ff. 5 S.a. Kap. C Rz. 113 ff. 6 Wofür das Vorgehen bei SCRUM spricht, s.a. Kap. C Rz. 131 ff. 7 Zur Relevanz des Planungsanteils s. oben Rz. 94 zu BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637 m. Anm. Schweinoch, und v. 9.2.2010 – X ZR 82/07 – Tiefladesattelaufleger. 8 BGH v. 27.1.2011 – VII ZR 133/10, Rz. 9, NJW 2011, 915 – Internetsystemvertrag II. 9 BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327. 10 BGH v. 24.3.2011 – VII ZR 146/10, MDR 2011, 648; hier wurde nur auf BGH v. 27.1.2011 Bezug genommen, der Vertragstyp (Werkvertrag) nicht weiter angesprochen.

186

Schneider

Sachqualität der Software und § 651 BGB

Rz. 112 B

3. Stellungnahmen der Literatur Die vorstehende Auffassung zu verbleibenden „Lücken“ für die Anwendung 110 des § 651 BGB ist nicht „herrschende Meinung“ In Kenntnis der BGH-Entscheidungen und damit der oben angedeuteten „Lücken“, für die auch angesichts der Rspr. des BGH eine Anwendung des § 651 BGB in Betracht kommt, sind die Autoren überwiegend der Meinung, auch insoweit verbleibe es bei Werkvertragsrecht1 bzw. wird die Sachqualität für Software generell verneint2. Vor allem aber wurde das Thema der datenträgerlosen Verbreitung aufgegriffen, also auf einer abstrakteren Ebene das Thema „Gebrauchtsoftware“ mit abgehandelt3. Über diese Beiträge und unter Verwertung der dort jeweils zitierten Quellen4 könnte man sagen, dass diese weitgehend abschließend die Frage nach der Sachqualität im Ergebnis verneinen. Diese Frage sei falsch gestellt und insbesondere das Ergebnis, die Anwendung von § 651 BGB sei nicht sachgerecht – grob zusammengefasst5. Da die Diskussion über die Entwicklung wohl doch nicht ganz abgeschlos- 111 sen ist und es neue Erscheinungsformen von Software gibt, die noch genauer auszuloten wären, sei vorsorglich auf Folgendes hingewiesen: Es scheint weitgehend unstreitig zu sein, dass Software die als Sache, aber unvollkommen qualifizierte Maschine „Computer“ – wie vorgesehen – zu Ende konstruiert6. Software ist andererseits immer dafür gedacht und darauf angewiesen, auf einem Konstrukt, das vereinfacht „Rechner“ genannt werden kann, gespeichert zu sein und abzulaufen7. Aufgrund der vielfältigen Varianten an Erscheinungsformen des „Rechners“ ist eine strikte Trennung zwischen „Rechner“ einerseits und „Datenträger“ andererseits nicht möglich8. Für Mietrecht und somit eine Vielzahl Lizenzen ist wichtig, dass Software ei- 112 ne Sache darstellt, weil ansonsten die Anwendung von Mietrecht nicht möglich wäre, jedenfalls nicht die unmittelbare. Mit der überwiegenden Meinung im Schrifttum (die sich aber insoweit nicht mit § 651 BGB befasste) bejahte der BGH für den ASP-Vertrag mit der Gewährung der Online-Nutzung von

1 A.M. Schweinoch, CR 2010, 1. 2 S. etwa Bartsch, Software als Rechtsgut, CR 2010, 553; Heydn, CR 2010, im Vorfeld zu BGH v. 3.2.2011 – I 129/08, CR 2011, 223 – Oracle; anders aber nun EuGH v. 3.7.2011 – C-128/11, CR 2012, 498. 3 S. schon Mäger, CR 1996, 522 und Ulmer/Hoppen, CR 2008, 681, zum „Werkstück“ des Software-Objektcodes. Ablehnend: BGH v. 3.2.2011 – I ZR 129/08, CR 2011, 223, Rz. 25 – UsedSoft I. 4 Etwa Redeker, NJW 1992, 1739. 5 S. Bartsch, CR 2010, 553; Heydn, CR 2010, 765. 6 Software wird insoweit als Ergänzung zu sehen sein, was Heussen wiederum als „gefrorene Idee“ bezeichnet, GRUR 1987, 779 (789), worauf Bartsch hinweist, CR 2010, 553 (556). 7 Von Neumann-Prinzip; s.a. BGH v. 15.11.2006 – XII ZR 120/04 – ASP, CR 2007, 79. 8 S. BGH v. 15.11.2006 – XII ZR 120/04 – ASP, CR 2007, 75.

Schneider

187

B Rz. 113

Grundlagen

Software einen Mietvertrag, „der die entgeltliche Gebrauchsüberlassung einer beweglichen oder unbeweglichen Sache zum Gegenstand hat“1. 113

Des Weiteren zitiert der BGH in Rz. 152 die BGH-Entscheidungen der Vergangenheit, wonach jeweils entweder Kauf- oder Mietrecht je nach der vereinbarten Überlassungsform anzuwenden ist3. Beim ASP-Vertrag hätte man vermutet, dass das Gericht nicht mit dem Datenträger argumentiert, auf dem die Software verkörpert sei, weil es insoweit nicht um einen klassischen Datenträger geht, mit dem die Übertragung oder Zurverfügungstellung erfolgt. Dazu führt das Gericht aus: „Denn die der Steuerung des Computers dienenden Programme müssen, um ihre Funktion erfüllen zu können, d.h., um überhaupt nutzbar zu sein, in verkörperter Form vorhanden sein, sei es auf einem Excel-Speichermedium (z.B. auf Diskette, CD, USB-Stick) oder auf einer Festplatte oder auch nur auf einem flüchtigen (stromabhängigen) Speichermedium (vgl. hierzu Marly, a.a.O., Rz. 102 m.w.N., 119). Gegenstand des ASP-Vertrages ist somit stets die verkörperte geistige Leistung. Dabei ist es ohne Bedeutung, auf welchem Informationsträger das Computerprogramm verkörpert ist.“4

114

Im Hinblick auf den Vergleich mit dem Buch verweist das Gericht auch noch außerdem darauf, dass dessen Sachqualität nicht angezweifelt werde, das ebenfalls Ergebnis einer schöpferischen Geistestätigkeit ist. Dieses „wird ausschließlich wegen seines geistigen Inhalts und nicht wegen seines Informationsträgers, des Papiers, erworben. Dadurch verliert es jedoch nicht seine Sachqualität (Marly, a.a.O., Rz. 98 m.w.N.)“5.

115

Bartsch bemängelt, dass es in Rz. 15 des zitierten Urteils heißt, der BGH habe wiederholt entschieden, dass eine auf einem Datenträger verkörperte Software als bewegliche Sache anzusehen ist, während in der zitierten Rz. 16 im Hinblick auf die Frage der Verkörperung als vergleichbar mit dem elektronischen Datenträger das Buch erklärt wird6. Insoweit korrigiert Bartsch aber diese Frage der Analogie dahingehend, dass nicht das Buch, „sondern der in ihm abgedruckte Roman zur Sache erklärt werden“ müsse.

1 BGH v. 15.11.2006 – XII ZR 120/04, Rz. 13 unter Hinweis auf Koch, ITRB 2001, 39 (40); Bettinger/Scheffelt, CR 2001, 729 (731); Röhrborn/Sinhardt, CR 2001, 69 (70 f.); Sedlmeier/Kolb, MMR 2002, 75 (78); von Westerholt/Berger, CR 2002, 81 (84); Junker, NJW 2003, 2792 (2797); Marly, Softwareüberlassungsverträge, 4. Aufl., Rz. 563, 567, nun Praxishandbuch Softwarerecht, 5. Aufl., Rz. 1084 und 1088. 2 BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 79. 3 BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 79; s. kritisch Lejeune, Anm. zu BGH v. 15.11.2006, CR 2007, 75, 78; s.a. Müller-Hengstenberg/Kirn, NJW 2007, 2370. 4 BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 79, Rz. 16. 5 BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 79, Rz. 16; s. aber schon Redeker, NJW 1992, 1739. 6 Bartsch, CR 2010, 553 (555).

188

Schneider

Sachqualität der Software und § 651 BGB

Rz. 119 B

Deshalb geht es Bartsch darum, einen anderen Ansatz zur Diskussion zu finden1. Heydn nimmt an der Entscheidung des BGH insofern Anstoß, dass rich- 116 tigerweise der BGH hätte argumentieren müssen, dass aus den zitierten Entscheidungen sich nicht ergebe, dass Software als Sache einzuordnen sei, „sondern lediglich, dass im Einzelfall bestimmte, für Sachen geltende schuldrechtliche Vorschriften auf Software entsprechend anzuwenden sind“2. Hier sei schon angemerkt, dass bei solchen Argumentationen ein gewisser 117 Widerspruch entsteht: Will man versuchen, dem eigentlichen Charakter von Software gerecht zu werden, so ist aufgrund deren Unvollkommenheit und auch „Ideenhaftigkeit“3, der Sachcharakter eher zu verneinen bzw. nicht erkennbar, weshalb es unsinnig erscheint, auf Software „allein“ oder „als solche“ abzustellen. Genau dies verlangt aber z.B. das Patentrecht, jedenfalls für den Fall, dass Software allein betrachtet wird. Nun könnte man sagen, dass genau das Patentrecht eigentlich die sachgerechte, dem eigentlichen Charakter entsprechende Vorgabe macht, nach der es nicht sinnvoll ist, Software „als solches“ zu betrachten. Zwar hat nicht § 651 BGB, jedoch das Urheberrecht in gewissem Sinne diesen „Fehler“ gemacht. Weiter ist noch zu bedenken, dass die Diskussion um die Sachqualität 118 wahrscheinlich relativ begrenzt auf Deutschland ist. Somit kann auch angenommen werden, dass der deutsche Einfluss so gering war, dass dieser Gedanke bei der Rechtsschutzrichtlinie keine Rolle gespielt hat. Die Überlegung ist, dass die Block-Implementierung, wie sie in Deutschland vollzogen worden ist, zwar unter rechtspolitischen Aspekten der Integration in die internationalen Bezüge der Berner Übereinkunft sinnvoll war, gleichwohl aber der Qualität der Software als solchen im oben behandelten Sinn keinen Gefallen getan hat. Dies zeigt sich in besonderem Maße i.V.m. der Frage der Online-Erschöpfung mit der unglücklichen Gleichsetzung von Werkstück und Datenträger, was mit der oben bereits angedeuteten Natur der Software eigentlich nicht vereinbar wäre. Gleichwohl kämpft nun die unveränderbare Weigerung zum Werkstück mit der Eigenheit, dass bei Software ein solches eigentlich nicht existiert, weil dort der Datenträger etwas ganz anderes ist als der typische bei anderen Medien (so etwa beim Buch). Insofern ist, wie auch Bartsch einräumt4, die Vorstellung von Ulmer/Hoppen5 – der Datenstrom als „Werkstück“ – durchaus in der Ausgangspositi1 Zur Buch-Analogie i.V.m. dem Quellcode s. schon Redeker, NJW 1992, 1739. 2 Heydn, CR 2010, 765, 770 zu BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 79. 3 Etwa Heussen, GRUR 1987, 779 (789) folgend, „gefrorene Idee“, worauf auch Bartsch verweist (CR 2010, 553 [556]). 4 Bartsch, CR 2010, 553. 5 Ulmer/Hoppen, Was ist das Werkstück des Software-Objekt-Codes?, CR 2008, 681; s. dazu a. BGH v. 3.2.2011 – I ZR 129/08 (Vorlage zu Gebrauchtsoftware bei Online-Bezug), Rz. 25.

Schneider

189

119

B Rz. 120

Grundlagen

on1 richtig, auch wenn man mit Bartsch die Konsequenzen, die die Autoren aus der Auffassung ziehen, nicht richtig findet. 120

Sprau behandelt die Anwendbarkeit des § 651 BGB weiterhin restriktiv2: „Ein Werkvertrag fällt nicht unter § 651 BGB, wenn nach dem Vertragsinhalt nicht die mit dem Warenumsatz verbundene Übertragung von Eigentum und Besitz im Vordergrund steht (s.a. BGH, WM 1977, 79 (a.R.)), sondern ein über die bloße technische Herstellung der beweglichen Sache hinausgehender Gesamterfolg den Schwerpunkt der Verpflichtung des Unternehmers bildet (für funktionale Abgrenzung auch Thode, NZBau 2002, 360 [362] unter Hinweis auf die VerbrGKRL; s.a. BGH, NJW 2006, 904). Das ist vor allem der Fall, wenn für diesen Gesamterfolg weitere für die Pflicht zur rein technischen Herstellung der Sache hinausgehende Leistungen erforderlich sind, die den Schwerpunkt des Vertrages bilden …“ Und weiter: „Das können von der Herstellung unabhängige Leistungen sein, soweit sie nicht nur in Montageverpflichtungen gemäß § 434 Abs. 2 BGB bestehen.“ (m.w.N.). … Mit der Herstellung zusammenhängende Leistungen genügen in der Regel nicht, z.B. eine planerische Tätigkeit des Unternehmers als Vorstufe der Herstellung (BGH, NJW 2009, 2877). Jedoch kann auch hier ein über die Herstellung hinausgehender Erfolg derart im Vordergrund stehen, dass er dem Vertrag das Gepräge gibt, etwa durch eine besondere geistige oder künstlerische Leistung (z.B. Entwickeln einer komplexen Maschine unter Anpassung an die Bedürfnisse des Bestellers, Einbau). Dann ist die Anwendung des Werkvertragsrechts gerechtfertigt (offen BGH, NJW 2009, 2877; s.a. § 634a I Nr. 1 BGB, der gerade für bewegliche Sachen gedacht ist).“

121

Im Ergebnis wird man wohl der die Anwendung des § 651 BGB ablehnenden Literatur-Meinung zu folgen haben3. Allerdings wird die weitere Diskussion hinsichtlich der Sachqualität eine andere Richtung nehmen, wenn die EuGH-Entscheidung zu Gebrauchtsoftware rezipiert wird4. Vermutlich wird es dennoch bei der ablehnenden Haltung gegenüber § 651 BGB – mit neuer Begründung – verbleiben. Immerhin wird es sich empfehlen, das verbleibende „Restrisiko“ möglichst durch die Vertragsgestaltung schon abzuwehren bzw. abzufangen.

V. Folgen für die Vertragsgestaltung 1. Abbedingen des § 651 BGB 122

Sollte § 651 BGB im konkreten Fall Anwendung finden, würde bei Individualverträgen eine gegensätzliche Vereinbarung zum Werkvertrag führen 1 2 3 4

Bartsch, CR 2010, 553, Fn. 34. Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 4, Hervorhebung fett v. Verf. S.a. Redeker, Kap. D, Rz. 71 ff. EuGH v. 3.7.2012 – C-128/11, CR 2012, 498 – Oracle vs. UsedSoft; s. schon OLG Hamm v. 28.11.2012 – 12 U 115/12 zu „Eigentum“ bei Software.

190

Schneider

Sachqualität der Software und § 651 BGB

Rz. 125 B

können1. In AGB wäre eine solche Klausel unwirksam2. Insofern wird es sich empfehlen, „Substitute“ bzw. Regelungen zu vereinbaren, die den gewünschten konkreten Effekt, notfalls auf anderem Wege erreichen lassen. Das betrifft vornehmlich den Vertragszweck (einschließlich Planung), etwa Abnahme, Mitwirkung u.ä. Vorsorglich sollte der Planungsanteil, soweit zutreffend, besonders hervorgehoben, zumindest geregelt werden3. 2. Abnahme In der Praxis ist das Erfordernis einer Abnahme und damit zusammenhän- 123 gender Vorgänge tief verwurzelt. Abnahmeregelungen und -verfahren gehören zu einer sachgerechten Handhabung. Es erscheint unproblematisch, Regelungen zu treffen, denen zu Folge in einer bestimmten Abfolge Installationen, Tests verschiedener Art und Feststellungen zu treffen sind. Z.B. gehört bei Internationalen Maschinen-Lieferungs- und Aufstellungsverträgen typischerweise auch eine Regelung zum testweisen Hochfahren, evtl. einschließlich Erprobungen bestimmter Art, von deren Erfolg Zahlung abhängt. Entsprechend wird es sich empfehlen, Installationen (zwecks Test, zwecks Erprobung (im Echtbetrieb …), unterbrechungsfreier Laufzeit) u.Ä. zu regeln4. Evtl. kann auch das Institut der „Freigaben“ implementiert werden, insbesondere wenn eine flexible, agile form des Vorgehens gewählt wird5.

124

3. Einheitliche Bewertung als Kaufvertrag Einer der Vorteile der neuen Regelung ist, dass es auf die feinsinnige Ab- 125 schichtung, ob es sich noch um einen Kaufvertrag mit Montageverpflichtung (wobei bei Software die Montage etwa in Portierung, Implementierung und Installation bestünde) handelt, oder ob es sich vielleicht um zwei selbständige Verträge handeln könnte, nämlich die Überlassung von Standardsoftware und deren Anpassung, oder aber um einen einheitlichen Vertrag, der insgesamt als Werkvertrag zu betrachten sei, hinfällig ist bzw. hinfällig

1 S. Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 1, als „str.“ bezeichnet bei Hinweis auf Palandt/Grüneberg, Übbl. vor § 311 BGB Rz. 15. 2 Palandt/Grüneberg, 72. Aufl. Übbl. vor § 311 BGB Rz. 15; s. dazu krit. Fritzemeyer, Die rechtliche Einordnung von IT-Verträgen und deren Folgen, NJW 2011, 2918 (2921). 3 Um BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327, Rz. 16 (s.a. oben Rz. 102) zu entsprechen und den vereinbarten Vertragszweck zu verdeutlichen; s.a. zu entsprechender Empfehlung Fritzemeyer, Die rechtliche Einordnung von IT-Verträgen und deren Folgen, NJW 2011, 2918 (2921). 4 S.a. Kap. G. 5 S. zum Konzept Kap. C Rz. 358 ff.; s.a. J. Schneider, Handbuch, 4. Aufl., H. Rz. 86b.

Schneider

191

B Rz. 126

Grundlagen

sein kann1. Wenn die Vertragspartner genügend klar machen, dass es ihnen um den einheitlichen Erfolg geht, dass eine bestimmte Software entsprechend geändert oder eine Software neu herzustellen ist, die ein bestimmtes Leistungsergebnis zeigt, wozu auch weitere Leistungen gehören wie etwa die Parameter-Einstellung, die Implementation und die Installation, kann dies einheitlich als Kaufvertrag gewürdigt werden. Die Vertragsparteien sind frei, an das Erfordernis der Ablieferung i.V. auch mit Fälligkeit der Zahlungen bestimmte Kriterien zu stellen, die in einem gemeinsamen Verfahren oder nach einem bestimmt festzulegenden Verfahren geprüft werden2. 126

Es ist davon auszugehen, dass § 651 BGB nicht einfach zur Partei-Disposition steht. Nicht einmal individualvertraglich wird man wirksam die Verweisung ins Kaufrecht aufheben können. Lediglich innerhalb des Vertragstyps Kauf lassen sich Änderungen und Erweiterungen vorstellen3.

127

Die Hierarchie beim Mangel-Begriff lädt dazu ein, dem Vorrang der Beschaffenheitsvereinbarung dadurch zur Geltung zu verhelfen, dass die Beschaffenheit auch tatsächlich – umfassend, richtig – beschrieben wird4. Allerdings wird dadurch nicht die Haftung für Funktionsmängel ausgeschlossen5.

128

Unabhängig vom Vertragstyp kann es sich empfehlen, auch die Abnahmekriterien in die fachliche Feinspezifikation mit aufzunehmen und an deren Erfüllung bestimmte Folgen zu knüpfen (wie z.B. die Produktivsetzung oder die Fälligkeit von Zahlungen).

129

Das Thema der Anwendung des § 651 BGB wird in mehreren Kapiteln dieses Werkes angesprochen und noch differenziert beleuchtet, s.v.a. Kap. D Rz. 67 ff., Kap. A Rz. 118; Kap. G Rz. 71 ff. Daran zeigt sich, dass noch keine völlig abgesicherte, einheitliche Meinung besteht, aber auch, dass der „Trend“ weiterhin sehr stark ist, für Software die Anwendung des § 651 BGB (weitgehend) abzulehnen, – wenn auch mit unterschiedlichen Begründungen. Die Ablehnung der Sachqualität erscheint angesichts neuerer Rspr. nicht mehr opportun.

1 S. zur rechtlichen Einordnung nach altem Recht BGH v. 3.3.2004 – VIII ZR 76/03 – Solaranlage, MDR 2004, 737 = DB 2004, 1421: abzustellen (vor allem) auf die Art des zu liefernden Gegenstandes, das Wertverhältnis von Lieferung und Montage sowie auf die Besonderheiten des geschuldeten Ergebnisses; s.a. BGH v. 22.7.1998 – VIII ZR 220/97, MDR 1998, 1274 = NJW 1998, 3197. 2 Ob die pauschale Berechnung in den Nutzerhinweisen zu EVB-IT System (Ziff. 2 Anwendungsbereich) haltbar ist, ab dem niedrigen Satz von 16 % des Erstellungspreises für die sog. Anpassungsleistungen (Individualsoftware, Migration, Herbeiführung Betriebsbereitschaft Gesamtsystem) ist stark anzuzweifeln und erscheint kein geeigneter Lösungsweg. Solche Hinweise liegen für die Version 2.0 derzeit nicht vor. 3 S. Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 1. 4 S.a. Lapp, ITRB 2003, 42; M. Intveen, ITRB 2010, 238. 5 S. dazu Kap. C Rz. 71, 148.

192

Schneider

2. Kapitel Verträge C. Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft Rz.

Rz.

I. Die Zweiteilung des Projekts in „Planung“ und Realisierung 1 1. Typische Projektstruktur. . . . . . 1 2. Ziel des Planungsprozesses: Das „Pflichtenprogramm“ des Auftragnehmers/das „Pflichtenheft“ . . . . . . . . . . . . . . . . . . . . . 13 a) Einführung . . . . . . . . . . . . . . . . 13 b) Vertragstyp . . . . . . . . . . . . . . . . 22 c) Das Pflichtenheft in der Rechtsprechung – v.a. des des BGH . . . . . . . . . . . . . . . . . . 29 d) Extrapolation der Maßgaben des BGH . . . . . . . . . . . . . . . . . . 49 e) Versuch der Bestimmung der Funktion und der Aufgabe des Pflichtenhefts als fachliche Feinspezifikation . 69 f) Abgleich des Begriffs des Pflichtenhefts mit EVB-IT/ BVB und DIN . . . . . . . . . . . . . . 80 g) Transparenzgebot für Leistungsbeschreibungen und Vergütungsregelungen . . . . . . 94 3. Besonderheiten bei modernen Vorgehensmodellen, v.a. agiler Methodik. . . . . . . . . . . . . . . . . . . . 113 a) Methode gegen das Scheitern von Projekten . . . . . . . . . 113 b) Anwendungsvoraussetzungen . . . . . . . . . . . . . . . . . 117 c) Prototyping . . . . . . . . . . . . . . . 120 d) AGIL . . . . . . . . . . . . . . . . . . . . . 124 aa) Manifest . . . . . . . . . . . . . . . 124 bb) Prinzipien, Prioritäten . . 125 cc) Grundlagen . . . . . . . . . . . . 126 dd) Extreme Programming . . 128 ee) Scrum . . . . . . . . . . . . . . . . . 131 e) Blick auf das Pflichtenheft und den „mittleren Ausführungsstandard“ . . . . . . . . . 142

4. Der explizite Beratungsvertrag zur Unterstützung des Auftraggebers bei der Gewinnung des Pflichtenhefts . . . . . . . . . . . . . . . . 158 a) Einführung . . . . . . . . . . . . . . . . 158 b) Vertragstyp bei Unterstützung . . . . . . . . . . . . . . . . . . 177 c) Anpassungs- und Implementierungsplanung für bereits vom Auftraggeber ausgewählte Software . . . . . . . . . . 183 5. Die Übernahme des Planungsprozesses durch den Auftragnehmer bis einschließlich Gewinnung des Pflichtenhefts (Werkvertrag) . . . . . . . . . . . . . . . . 195 a) Schritte, Projektmethoden . . 195 b) Teilabnahme, Abnahme . . . . 203 c) Mitwirkung des Auftraggebers, Prüfungspflichten des Anbieters . . . . . . . . . . . . . . 210 d) Besonderheiten bei Anpassung von Standardsoftware und gleichzeitiger Anpassung der Organisation des Kunden . . . . . . . . . . . . . . . . . . . 223 6. Prüfung des Pflichtenhefts, Prüfungspflichten . . . . . . . . . . . . 232 a) Prüfungspflichten des Auftraggebers . . . . . . . . . . . . . . 232 b) Prüfungspflicht des Auftragnehmers . . . . . . . . . . . . . . . 240 c) Änderungsmanagement, Change Request. . . . . . . . . . . . 253 7. Der konkludente Beratungsvertrag . . . . . . . . . . . . . . . . . . . . . . 256 8. Besonderheiten bei Fehlen des Pflichtenhefts . . . . . . . . . . . . . . . . 261 a) „Mittlerer Ausführungsstandard“? . . . . . . . . . . . . . . . . . 261

Schneider

193

C Rz. 1

Verträge Rz.

Rz.

b) Risiken bei fehlendem Pflichtenheft aus dem Mangelbegriff. . . . . . . . . . . . . . 265 9. Besonderheiten zur „Dokumentation“ . . . . . . . . . . . . . . . . . . 269 10. Quellcode . . . . . . . . . . . . . . . . . . . 290

V. Datenschutz, Auftragsdatenverarbeitung . . . . . . . . . . . . . . . . . 378 1. Datenschutzrechtliche Zulässigkeit, personenbezogene Daten . . . . . . . . . . . . . . . . . . . . . . . 378 a) Anwendung des BDSG . . . . . . 378 b) Einbeziehung des Auftragnehmers. . . . . . . . . . . . . . . . . . . 382 c) Auftrag. . . . . . . . . . . . . . . . . . . . 384 d) § 11 BDSG bei Projekten . . . . 386 e) Outsourcing . . . . . . . . . . . . . . . 393 f) Cloud . . . . . . . . . . . . . . . . . . . . . 394 g) Typische Situationen/Aufgaben . . . . . . . . . . . . . . . . . . . . . 396 h) Geheimnisse . . . . . . . . . . . . . . 398 i) Kein Konzernprivileg . . . . . . . 401 j) Funktionsübertragung . . . . . . 402 k) Verschlüsselung/Anonymisierung . . . . . . . . . . . . . . . . . . . . 404 2. Anforderungen der Auftragsdatenverarbeitung (analoge Anwendung) . . . . . . . . . . . . . . . . . 405 a) Vertrag über Auftragsdatenverarbeitung . . . . . . . . . . . . . . . 405 b) Prüfungsaufgaben . . . . . . . . . . 406 c) Checkliste. . . . . . . . . . . . . . . . . 409 3. Eckpunkte des Vertrags . . . . . . . 410 4. Prüfungspflichten . . . . . . . . . . . . 413 5. Anlage zu § 9 BDSG . . . . . . . . . . 417 6. Echtdatentest . . . . . . . . . . . . . . . . 425 7. Vertragliche Regelung, Einzelfragen . . . . . . . . . . . . . . . . . 427 8. Einwilligung, Datenschutzerklärung . . . . . . . . . . . . . . . . . . . . 437 9. Auftragnehmer im Nicht-EU-/ -EWR-Ausland . . . . . . . . . . . . . . . 439 10. Geheimhaltungsvereinbarung . 443

II. Die einzelnen Projektschritte und deren Besonderheiten . . . . . 296 1. Vorstudie, Ist-Analyse . . . . . . . . 297 2. Machbarkeitsstudien, Marktstudien . . . . . . . . . . . . . . . . . . . . . . 302 3. Grobkonzept. . . . . . . . . . . . . . . . . 305 4. Aktivitäten- und Fristenplan . . 328 III. Verjährung, Leistungsstörungen . . . . . . . . . . . . . . . . . . . 332 1. Differenzierungen hinsichtlich des Gesamtumfangs des Vertrages . . . . . . . . . . . . . . . . . . . . . . . 332 2. Werkvertragliche Einordnung . 337 3. Leistungsstörungen bei dienstvertraglichen Regelungen . . . . . 340 4. Die Rechtseinräumung beim Planungsvertrag und bei agilem Vorgehen . . . . . . . . . . . . . 343 5. Anlagen, Rangfolge der Anlagen . . . . . . . . . . . . . . . . . . . . . 350 6. Folgeschäden . . . . . . . . . . . . . . . . 352 IV. Vorschläge zur Vertragsgestaltung, Beispiele . . . . . . . . . . . . 357 1. Gesetzliche Vertragstypen und individuelle Ergänzungen . . . . . 357 2. Abnahme/Freigabe . . . . . . . . . . . 358 a) Anwenderinteresse. . . . . . . . . 359 b) Anbieterinteresse . . . . . . . . . . 361 3. Leistungsstörungen/Freigabe . . 367 4. Zur Vergütung . . . . . . . . . . . . . . . 370 5. Abnahme/Verjährungsfristen . . 374

I. Die Zweiteilung des Projekts in „Planung“ und Realisierung 1. Typische Projektstruktur 1

Eine der vordringlichsten Empfehlungen für IT-Projekte ist die Strukturierung in – mindestens – Planung und Realisierung. Dementsprechend ist ein Kardinalfehler bei Projekten zur Erstellung und Anpassung von Software – immer noch –, das Projekt nicht zu planen und insbesondere nicht die Schrittfolge zu absolvieren, die zu einer ausführlichen, detaillierten Leistungsbeschreibung führt. Diese Schritte, deren genaue Ausprägung noch nä194

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 2

C

her zu beschreiben ist1, bilden zusammenfassend die „Planung“ im Gegensatz bzw. in Abgrenzung zur anschließenden „Realisierung“. Oft sehen AGB Planung und Realisierung in einem einheitlichen Vertrag vor, während in Mustern eher die Trennung vorgeschlagen wird2. Die BVB etwa gingen von einer klaren Trennung aus3. Die EVB-IT System und EVB-IT Erstellung sehen die Trennung nicht vor. Idealerweise erfolgt das Projekt bei klassischer Methodik in Schritten, die 2 jeweils klar abgegrenzt aufeinander folgen und aufbauen4. Ein typisches phasenweises Vorgehen, das sich an der Zweiteilung von Planung und Realisierung orientiert, kann – angelehnt auch an das „Phasenkonzept“ der BVB-Erstellung – wie folgt als lineares Phasenschema dargestellt werden5: (I) Planung – Dienst-6 oder Werkvertrag7 (1) Idee, Gründung des Projekts, (2) Vorstudie, (3) Grobkonzept, (4) Machbarkeitsstudie (Machbarkeit I), (5) Ist-Analyse, (6) Schwachstellenanalyse, (7) Machbarkeit II (?), (8) Fachliche Grobkonzeption, (9) Technische Grobkonzeption (?8), (10) Fachliche Feinspezifikation (= „juristisches“ Pflichtenheft, richtig: Lastenheft9) (11) Technische Feinspezifikation (Realisierung)10

1 S. unten Rz. 296 ff. 2 S. mit klarer Trennung im einheitlichen Vertrag Witte, in: Redeker, Handbuch der IT-Verträge, Kap. 1.4, § 1 mit Planungsphase I, Planungsphase II und Realisierungsphase; s. anders Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4 mit einem Vertrag der auf dem gemeinsam erstellten Pflichtenheft (i.S. der technischen Spezifikation) aufbaut. 3 S. sogleich Rz. 2 und unten Rz. 89, 182, 189. 4 S.a. Redeker, IT-Recht, 5. Aufl., Rz. 306. 5 S.a. Müller-Hengstenberg, BVB/EVB-IT-Computersoftware, 7. Aufl.; MüllerHengstenberg/Kirn, CR 2008, 755; Kap. H Rz. 43 ff., v.a. 48, 52; Kap. M Rz. 48 ff. 6 S. unten Rz. 158 ff. 7 S. Kap. B Rz. 56 ff., 122 ff. und v.a. unten Rz. 195 ff. 8 Gehört schon zur Realisierung. 9 S. unten Rz. 80 ff., insbes. 84, 89. 10 Gehört richtig schon zur Realisierung, s. nächste Seite. Zur exakten Trennlinie zwischen Planung und Realisierung s. Rz. 80 ff., 89.

Schneider

195

C Rz. 3

Verträge

(II) Realisierung – Werkvertrags-, nach h.M. (s. B Rz. 92 ff.) nicht Kaufrecht (11) Technische Feinspezifikation/technisches Pflichtenheft Realisierungsplanung, (12) „Programmierung“ Quellcode, (13) Einzeltests/Schreibtischtest, (14) Kompilierung/Object-Code, (15) Integrationstests, (16) Dokumentation, Implementierung, (17) Tests auf Testsystem (des Auftraggebers (?), (18) Tests auf Produktivsystem (?), (19) Abnahme-/Abschlussprüfung. Die vorstehenden Phasen veranschaulichen, wie lange der Weg zum Pflichtenheft sein kann (zu weiteren Details s. unten Rz. 313 zu den einzelnen Schritten). 3

Die EVB-IT System und Erstellung lassen diese klare Trennung vermissen. Der EVB-IT Systemvertrag sieht in Nr. 1.2.1 vor, dass Dokumente zur Leistungsbeschreibung in Bezug genommen werden1. Gemäß Nr. 2.1 ergeben sich Ziele, Art und Umfang der Leistungen „insbesondere“ aus den in Nr. 1.2.1.1 bis 1.2.1.3 genannten Dokumenten. Nr. 2.3 sieht die Bestimmung des Vorgehensmodells, ausgehend vom V-Modell XT, vor, bietet aber auch die Möglichkeit, ein anderes Vorgehensmodell zu bestimmen2.

4

Die Realisierung eines Projektes, gleich ob zu Erstellung, Anpassung oder nur Einstellung der Parameter, ohne geeignete Pläne i.S.v. „Pflichtenheft“ und Projektplan (Aktivitäten und Fristen beinhaltend), lässt sich zwar juristisch – mit Hilfe eines Sachverständigen – einer Beurteilung mit dem Maßstab eines mittleren Ausführungsstandards zuführen3, oft jedoch nicht mit praktisch verwertbaren Ergebnissen.

5

Die „Planung“ beinhaltet als Phase vor der Realisierung mindestens zweierlei, nämlich einmal die echte Planung i.S.v. methodischem Vorgehen bei der Entwicklung, Terminierung und Ausgestaltung der verschiedenen zu durchlaufenden Schritte und sodann die konkrete Arbeit an dem, was als Vorgabe für die Leistung später dienen soll, was in der juristischen Begriffswelt „Pflichtenheft“ genannt wird. Im Folgenden ist nicht so sehr von dem ersten Ansatz, der methodischen Gestaltung der verschiedenen zu absolvierenden Schritte die Rede, als vielmehr von dem Gesamtleistungspaket innerhalb der Planungsphase bis zur Erstellung des Pflichtenhefts. Die Reihe typischer Projektfehler lässt die kardinale Rolle der Strukturierung mit dem Ziel der Gewinnung einer Leistungsbeschreibung erkennen, die möglichst 1 1.2.1.1 Dokumente des Auftraggebers, 1.2.1.1 Dokumente des Auftragnehmers, 1.2.1.3 weitere Anlagen. 2 Zu den Vorgehensmethoden s. Balzert, Lehrbuch der Softwaretechnik, 3. Aufl.; Sommerville, Software Engineering, 9. Aufl. 3 S. dazu unten Rz. 142 ff.

196

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 7

C

eine Beschreibung bzw. Regelung des Vorgehens und die Festlegung auch der Pflichten des Auftraggebers enthält. Eine hohe Anzahl von IT-Projekten scheitert1, ohne dass dies zu gericht- 6 lichen Auseinandersetzungen führen würde. Das heißt, dass sich die Vertragspartner außergerichtlich irgendwie einigen. Möglicherweise kann man dies auch so deuten, dass beide Seiten das Gefühl haben, an dem Scheitern beteiligt gewesen zu sein, jedenfalls was eine Reihe dieser „Projekt-Ruinen“ betrifft. Dem steht gegenüber, dass bei Gericht weit überwiegend die Verantwortung (für das Scheitern) von Projekten beim Auftragnehmer gesehen wird, was daran liegt, dass die Gerichte die werkvertragliche Erfolgsverantwortung des Unternehmers annehmen bzw. aus den vorgelegten Unterlagen ableiten. Die Mitwirkungspflichten sind als bloße Obliegenheit nicht gleichwertig, ihre Verletzung oft nicht gerügt („Behinderungsanzeige“) und zudem oft nicht als kausal für das Scheitern nachweisbar2. Als typische „Projektsünden“, die zum Scheitern von IT-Projekten führen, 7 haben sich bislang – wohl überwiegend auf klassische Vorgehensweise bezogen – herausgestellt3: 1. 2. 3. 4.

Unklare Vertragstypologie Fehlende Projektstruktur Fehlendes, unvollständiges Pflichtenheft Übernahme der Verantwortung für das Pflichtenheft durch den Auftragnehmer 5. Unrichtiges Pflichtenheft/Prüfungspflicht des Auftragnehmers 1 S.a. Frank, CR 2011, 138 mit Hinweis auf Untersuchungen/Publikation der „Standish International Group“, konkret Report 2009, wonach weltweit 24 % vollständig abgebrochen werden; s.a. Computerwoche Ausgabe 38/11 mit mehreren Beiträgen hierzu; s.a. Bericht von Matt Asey 21.3.2008, zu einer Marktstudie 2008 (http://news.cnet.com/8301-13505_3-9900455-16.html) „of 800 IT managers, reporting that 62 percent of IT projects fail to meet their schedules. … 49 percent suffered budget overruns, 47 percent had higher-than-expected maintenance costs, and 41 percent failed to deliver the expected business value and ROI. This wouldn’t be so bad, CIO.com notes, if it weren’t for the fact that the numbers haven’t appreciably improved over the past decade. In some cases, they’ve gotten worse. Why? Why do 25 percent of all IT projects get canceled before completion? CIO.com cites two reasons: IT departments don’t take into account the time required between design and development and QA is not adequately understood and budgeted into projects’ timelines. One other thing that I’ve seen fairly often is a disconnect between the IT department and the business owners who sponsor IT projects. The two often have very different ideas as to what they want.“ 2 Zu den Ausnahmen s. etwa BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft, CR 1998, 393 und unten Rz. 210 ff. 3 Frank, CR 2011, 138, nennt neben Fehlern im Projektmanagement u.ä. auch „unzureichendes Pflichtenheft“ und „sich verändernde Vorgaben“. Er bezieht sich dabei auf Berichte aus ManagerMagazin und CW sowie Reports der Standish Group (s. etwa auch Marcus Raitner, www.misc.Raitner.de/2010).

Schneider

197

C Rz. 8 6. 7. 8. 9.

Verträge

Fehlende Abnahmekriterien Fehlende Mitwirkung Fehlendes Änderungsmanagement Fehlende Dokumentation1.

Die einzelnen Gründe hängen untereinander zusammen. 2., 3. und 5. bedingen weitgehend 6. und 8. Die starke Rolle des Pflichtenhefts lässt sich insoweit klar ablesen: Bis auf 9. hängen alle Ziffern mit dem Pflichtenheft zusammen. 8

McKinsey nennt im Rahmen einer Zusammenarbeit mit der Universität von Oxford Projekte „Black Swan“, ironischerweise definiert als „seltenes unvorhersehbares Ereignis, das eine unverhältnismäßig große negative Wirkung hervorruft“2. Bei IT-Projekten handelt es sich dann um solche, die ihr Budget um mindestens 200 % überziehen und 70 % mehr Zeit kosten als geplant3.

9

Dabei werden vier Arten „schwarzer Schwäne“ unterschieden, nämlich: 1. der „frühe schwarzer Schwan“4: – Kostenexplosion der Spezifizierungsphase, ohne dass ein Auffangen möglich wäre. Das Projekt müsste in diesem frühen Stadium gestoppt werden. 2. der typische „schwarze Schwan“5: – erst in der Designphase bemerkt. Die Kosten steigen durchschnittlich um das Dreifache des geplanten Budgets. „Das bedeutet am Ende immer noch exorbitante Überschreitungen um die 300 %.“ 3. Das „umgedrehte hässliche Entlein“6: – Sieht am Anfang hübsch aus, zeigt erst in der Entwicklungsphase, dass am Anfang nicht richtig bzw. nicht „sauber“ gearbeitet worden war. Typisch ist, dass sich Randbedingungen ändern oder die Integration in die IT-Umgebung ansteht. 4. Der „verhungernde schwarze Schwan“7: – bleibt zwar unter Budget, „aber nur, weil die angepeilten Ziele kontinuierlich verringert werden.“ 1 Neuerdings wird die Notwendigkeit der Dokumentationen in der Lit. anders als noch von der Rspr. gesehen, s. z.B. Stiemerling, Software Usability. Veränderte Ansprüche an Programm und Dokumentation: Berücksichtigung im IT-Vertrag und Bewertung im Rechtsstreit, ITRB 2009, 154; Stiemerling, ITRB 12/2011; s.a. Hoppen, Kap. Q. 2 S.a. wikipedia.org zu „black swan theory“, „unerwartetes Ereignis“. 3 S. Quack, Computerwoche 38/11, S. 14. 4 Quack, Computerwoche 38/11, S. 14. 5 Quack, Computerwoche 38/11, S. 15. 6 Quack, Computerwoche 38/11, S. 15. 7 Quack, Computerwoche 38/11, S. 15; s.a. www.computerwoche.de/a/das-risikoist-groesser-als-sie-denken, 2494703 (v. 6.12.2011)

198

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 12

C

Zwei Gründe werden von Quack angeführt, warum solche Fehleinschät- 10 zungen erfolgen, nämlich – „übertriebener Optimismus“ und – mangelnde Fokussierung auf die strategischen Ziele. Dazu gibt es Empfehlungen, für die aber erst noch geprüft werden muss, ob Agile Methodik dazu passt1. „10 Probleme – und wie sie zu meistern sind“2

11

Die Überschriften3: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Unmissverständlicher Projektauftrag. Binden Sie den künftigen Anwender ein. Unterteilen Sie das Projekt in sinnvolle Arbeitspakete. Halten Sie das Projekt-(Kern)Team möglichst klein. Definieren Sie den Umgang mit Change Requests. Formalisieren Sie den Abnahmeprozess. Das Projektmanagement muss in der Praxis gelebt werden. Holen Sie die Anwender dort ab, wo sie stehen. Stellen Sie Übergabe in den Betrieb sicher. Ziehen Sie Ihre Lehren aus dem Projekt.

Sehr vereinfachend könnte man sagen: Auch komplexe Projekte müssen 12 übersichtlich gestaltet und möglichst einfach gehalten werden4. Der eine Weg dazu führt über die klare Strukturierung mit dem Ziel der Gewinnung des Pflichtenhefts im Rahmen klassischer (sequentieller5) Vorgehensweise („Wasserfallmodell“). Die andere „iterative“ – evtl. spiralförmige6 – Art der Vorgehensweise ersetzt die Spezifikation durch eine strikte Regelung und v.a. Handhabung des Vorgehens (etwa „Agile“ bzw. „Scrum“). Zunächst erfolgt unter 2. (Rz. 13 ff.) die Darstellung der „klassischen“ Vorgehensweise zur Gewinnung des Pflichtenhefts. Unter 3. (Rz. 113 ff.) erfolgt eine knappe Skizzierung alternativen Vorgehensweisen, die in F. konkretisiert wird.

1 2 3 4

S. dazu unten Rz. 117 ff. Verspohl, Computerwoche 38/11, S. 20. Verspohl, Computerwoche 38/11, S. 20 f. Dazu die passende Meldung: „Briten stoppen Milliarden-IT-Projekt: Die britische Regierung will das seit 2002 laufende IT-Vorhaben für den National Health Service (NHS) stoppen. Bislang kostete das Projekt fast 15 Milliarden Euro.“ Bericht in CW 40/11, S. 6; s. grundlegend bzw. allgemein zu Großprojekten: Peter Mertens, Fehlschläge bei IT-Großprojekten der öffentlichen Verwaltung, ein Beitrag zur Misserfolgsforschung in der Wirtschaftsinformatik – Arbeitspapier 1/2009. 5 S. Müller-Hengstenberg/Kirn, MMR 2012, 3 (5). 6 S. Müller-Hengstenberg/Kirn, MMR 2012, 3 (5 f.).

Schneider

199

C Rz. 13

Verträge

2. Ziel des Planungsprozesses: Das „Pflichtenprogramm“ des Auftragnehmers/das „Pflichtenheft“ a) Einführung 13 Eine wesentliche Errungenschaft der Schuldrechtsmodernisierung ist die zentrale Funktion des „Pflichtenprogramms“1. Die jeweiligen MängelRegelungen bei Kauf- und Werkvertrag hinsichtlich der Sekundäransprüche (nach Scheitern der Nacherfüllung) bestehen aus Verweisungen auf §§ 280 ff. und 320 ff. BGB. Zudem umfasst § 280 BGB auch die „Nichterfüllung“2. 14 So zentral hat die Rechtsprechung das Pflichtenprogramm bislang nicht gesehen3. Für den Bereich der Software-Erstellung und -Anpassung ist die Interpretation des Instituts bzw. dessen Projektion auf die konkreten Sachverhalte in jedem Fall von zentraler Bedeutung4. Es ist streitig, ob bzw. unter welchen Voraussetzungen § 651 BGB und damit Kaufrecht anzuwenden ist5. Etwa könnte eine „Lücke“ der bisherigen, eher abzulehnenden Rechtsprechung dahingehend bestehen, bei Erstellung von Standardsoftware Kaufrecht anzuwenden. Dies würde dann bedeuten, dass gesetzlich keine Mitwirkungspflichten des Kunden bestünden. Angesichts von Rechtsprechung und Literatur kann man jedoch davon ausgehen, dass weit überwiegend § 651 BGB nicht auf Software-Erstellung und -Anpassung angewandt wird. Dies führt dazu, dass grundsätzlich von dem Pflichtengefüge des Werkvertragsrecht – jedenfalls für diesen Abschnitt – auszugehen ist. Besonderheiten, etwa spezielle Vorgehensmodelle, können allerdings zur Anwendung von Dienstvertragsrecht führen, s.a. Rz. 153 f. 15 Das Pflichtengefüge zwischen Auftraggeber und Auftragnehmer lässt sich auch anhand einiger Urteile, v.a. des BGH, so qualifizieren, dass für die Beibringung des Pflichtenhefts i.S.d. Rechtsprechung prinzipiell der Auftraggeber verantwortlich ist, während der Auftragnehmer für die technische Beschreibung verantwortlich ist. Dieses Verhältnis soll näher untersucht werden, auch daraufhin, was im Falle des Fehlens des Pflichtenhefts gelten soll. Es sei schon angemerkt, dass sich die Mitwirkungspflichten des Auftraggebers nicht mit der Beibringung des Pflichtenhefts erschöpfen. Zu diesen gehört vielmehr auch die Anpassung der internen Organisation an die Sollbeschaffenheit – was oft außer acht bleibt6. 1 S. z.B. zur spiegelbildlichen „Pflichtverletzung“ als zentraler Kategorie des Leistungsstörungsrechts Palandt/Grüneberg, 72. Aufl., § 280 BGB Rz. 2. S.a. Kap. K. 2 Palandt/Grüneberg, 72. Aufl., § 280 BGB Rz. 3. 3 S. aber Schollmeyer, NJW 2009, 2724 zu BGH v. 15.7.2008 – VIII ZR 211/07, NJW 2008, 2837, Rz. 18 und nunmehr EuGH v. 16.6.2011 – C-65/09 und C-87/09, NJW 2011, 2269. 4 S. Graf v. Westphalen, CR 2000, 73. 5 S. Kap. B Rz. 92 ff. 6 S.a. Schneider, ITRB 2008, 261; Schneider, Handbuch des EDV-Rechts, H. Rz. 365 ff.

200

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 20

C

Die Anforderungen des Auftraggebers werden in einem Pflichtenheft als 16 fachlicher Feinspezifikation nicht abschließend beschrieben. Unter technischen Aspekten ist festzuhalten, dass meist nur die funktionalen Anforderungen aufgenommen sind, nicht die sog. nicht funktionalen Anforderungen, Rz. 144. Unter juristischen Aspekten ist festzuhalten, dass auch bei „abschließender“ Leistungsbeschreibung ein sog. Funktionsmangel nicht ausgeschlossen ist, also die Pflicht des Auftragnehmers zur Herstellung eines funktionsfähigen Werkes nicht durch die Leistungsbeschreibung verdrängt wird, s.a. Rz. 66, 71, 148, 152. Im konkreten Fall des Scheiterns kann sich die brisante Frage stellen, ob 17 dem Auftraggeber als Kunden die Notwendigkeit und der Umfang einer solchen Planung und Erstellung der Vorgaben bei der Beschaffung klar waren. Es gibt genügend Anbieter, die in ihren Angeboten bzw. Produktscheinen nicht deutlich zum Ausdruck bringen, dass die angebotene Software nicht schon die „Gesamtlösung“ darstellt. In der Regel ist nicht nur deren Anpassung erforderlich (bzw. Einstellung der Parameter), sondern evtl. sogar die Beschaffung weiterer Softwarekomponenten, weil es sich nur um eine „Basislösung“ handelt1, mit der der Vertragszweck noch nicht erreicht ist. Grundsätzlich könnte man dieses Problem der Spezialsoftware oder Sonder- 18 software, die noch zu erwerben ist, auch über „Verschulden bei Vertragsabschluss“ – § 311 Abs. 2 Nr. 1 BGB – lösen2. Besonders virulent kann diese evtl. Aufklärungspflicht werden, wenn es um die Anwendung neuer Verfahren geht, die dem Kunden nicht vertraut sind. Deren Inhalt kann darin bestehen, dass der Kunde über die Folgen aufzuklären ist, wenn an die Stelle des „statischen“ Pflichtenhefts die prozess-orientierte Vorgehensmethodik tritt (s. dazu Rz. 149 ff.). Eine zentrale Funktion des Pflichtenhefts als fachliche Vorgabe liegt naturgemäß darin, als Maßstab für die Realisierung zu dienen, also die Grundlage für die Realisierung zu sein. Im Störungsfall dient das Pflichtenheft als Referenz dafür, zu beurteilen, ob die Leistung vertragsgemäß ist, insbesondere bei Abnahme bzw. der Ermittlung/Beurteilung von Mängeln. Deshalb muss das „Pflichtenheft“ auch Referenz für etwaige Änderungen (CR) sein, s.a. Rz. 253.

19

Auch im Hinblick auf die Vergütung spielt das Pflichtenheft eine erhebliche Rolle, wenn nämlich zusätzliche Leistungen vergütet werden sollen.

20

1 S. beispielhaft hierfür OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246; s. Zitat unten Rz. 174. 2 S. – nach BGB a.F. – BGH v. 15.5.1990 – X ZR 128/88, CR 1991, 86 im Hinblick auf Zusatzwünsche, die im allgemeinen nicht Vertragsinhalt werden, auch wenn sie zwar als selbstverständlich besprochen wurden, aber nicht in die schriftliche Vertragsurkunde aufgenommen worden sind.

Schneider

201

C Rz. 21

Verträge

Dazu ist es aber erforderlich, dass ermittelbar ist, inwieweit es sich hier um zusätzliche Leistungen handelt1. 21 Die Bedeutung des Pflichtenhefts für das weitere Projektgeschehen (Realisierung und deren Beurteilung durch Abnahme) und dessen ordnungsgemäßen Abschluss ist kaum zu unterschätzen. Praktisch erscheint eine Abnahme ohne die konkrete Referenz des „Soll“ in Form des Pflichtenhefts kaum erfolgreich, so dass der Umweg über Beweislast und Ausführungsstandards genommen werden muss. Umso mehr verwundert es, dass in der Praxis diesem Komplex so wenig Beachtung im Gegensatz zu dessen wichtiger Funktion gewidmet wird. b) Vertragstyp 22 Die Anwendung bzw. Anwendbarkeit des § 651 BGB und damit die Frage des anzuwendenden Rechts sind für Software-Erstellung und -Anpassung strittig2. Die Anwendung von Werk- oder Kaufrecht auf einen konkreten Vertrag steht gemäß § 651 BGB auch nicht zur Disposition der Parteien3. Ob Werkoder Dienstvertrag vorliegt, hängt vom Parteiwillen ab, wie er im Vertrag zum Ausdruck kommt4. „… Es kommt darauf an, ob auf dieser Grundlage eine Dienstleistung als solche oder als Arbeitsergebnis deren Erfolg geschuldet wird. Bei der tatrichterlichen Feststellung, was bei Fehlen einer ausdrücklichen Regelung Vertragsgegenstand ist, sind die gesamten Umstände des Einzelfalls zu berücksichtigen; die vertragliche Beschreibung eines Ziels ist allein kein hinreichendes Indiz für die Annahme eines Werkvertrags.“5 Für die prozessorientierten Vorgehensmodelle (vgl. Rz. 113 ff.) kommt mangels konkreter Leistungsbeschreibung in Betracht, dass diese zumindest bei Vertragsschluss nur das Ziel angeben und somit als Dienstvertrag zu qualifizieren sind. Bei Agile kommt sogar eine Zweiteilung in Betracht: Der 1. Teil betrifft die Grundfunktionen, wäre Werkvertrag, der 2. wird v.a. von Kunden beeinflusst, wäre Dienstvertrag (s.a. Rz. 154). 23 Die für die Anwendung von § 651 BGB noch in Frage kommenden Konstellationen6 können die Parteien durch geeignete Vertragsgestaltung neutrali-

1 Zur Vergütung von ursprünglich nicht vorgesehenen zusätzlichen Werkleistungen s. vor allem BGH v. 8.1.2002 – X ZR 6/00, DB 2002, 1710 und BGH v. 13.12.2001 – VII ZR 28/00, MDR 2002, 634 = NJW 2002, 1492 im Hinblick auf die Abgrenzung der Zusatzleistungen vom selbständigen Auftrag. 2 S. Kap. B, insbes. Rz. 92 ff., Rz. 110 ff. 3 S.a. Palandt/Sprau, 72. Aufl., § 651 BGB Rz. 1: Abweichungen können auch individuell nur innerhalb des jeweiligen Vertragstyps, also ggf. des Kaufrechts, nicht aber dessen Zuweisung vereinbart werden. A.A. Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4, s. dort § 1 Abs. 4 Anm. 7. 4 BGH v. 16.7.2002 – X ZR 27/01, NJW 2002, 3323. 5 BGH v. 16.7.2002 – X ZR 27/01, NJW 2002, 3323, LS 2. 6 S. Kap. B Rz. 106: Neuherstellung von Standardsoftware und Anpassung vom Auftragnehmer mitzuliefernder Software.

202

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 26

C

sieren. Ein Ansatz dazu ist – neben Abreden zu Abnahme und Mitwirkung – die explizite und betonte Ausgestaltung der Planung1. Betonen die Parteien die Planungsphase besonders und bauen diese aus2, 24 spricht dies dafür, den gesamten Vertrag, wenn diese Planung in Verbindung z.B. mit der Erstellung des technischen Feinkonzepts den Schwerpunkt bildet, auch dann werkvertraglich einzuordnen, wenn man ansonsten § 651 BGB anwenden würde3. Bei iterativen Verfahren ist die Planung nicht einer einzelnen, vorgeschalte- 25 ten Phase zuzuordnen, sondern wird Bestandteil einzelner, insoweit durchaus formalisierter Schritte des spiralförmigen Vorgehens, etwa bei Scrum. Allerdings fragt sich zugleich, ob nicht eine gemeinsame Projektverantwortung bzw. eine geteilte Verantwortung zu anderen Einordnungen als zu Werkvertrag führt4, 5. Nach altem Recht war es aus der Perspektive der Anbieter empfehlenswert, 26 die Planungsphase im Rahmen eines Dienstvertrages zu absolvieren, also den Kunden während der Planungsphase nur zu „unterstützen“6. Nach der Schuldrechtsmodernisierung erscheint die erhoffte Absicherung zweifelhaft. Die §§ 280 ff. BGB finden auf Dienstvertrag unmittelbar Anwendung, ohne dass eine Pufferung durch die Nacherfüllung, wie sie bei Kauf- und Werkvertrag vorgesehen ist, erfolgen würde. Nur das Fristsetzungs-Erfordernis für die Geltendmachung von Schadensersatz bietet einen gewissen „Schutz“ (§ 281 Abs. 1 Satz 1 BGB)7. Individualvertraglich könnte man ein Erfordernis analog der Nacherfüllung zwischenschalten. Ob dies in AGB des Anbieters halten würde, erscheint fraglich. Dies gilt insbesondere im Hinblick auf § 626 BGB, der lex specialis gegenüber § 314 BGB ist8. 1 Im Hinblick insbesondere auf BGH v. 23.7.2009 – VII ZR 151/08 – Silowände, CR 2009, 637, und BGH v. 9.2.2010 – X ZR 82/07 – Tiefladesattelaufleger, CR 2010, 580; s. dazu Kap. B Rz. 92 ff., 98 f. 2 S.a. Kap. B Rz. 83, 87, 94. 3 S.a. Kap. B Rz. 92 ff., 120; BGH v. 23.7.2009 – VII ZR 151/08 – Silowände, CR 2009, 637, und BGH v. 9.2.2010 – X ZR 82/07 – Tiefladesattelaufleger, CR 2010, 580. 4 S. Rz. 337 ff. zum Werkvertrag, Rz. 340 ff. zum Dienstvertrag; zur Zweiteilung Rz. 154. 5 Wohl aus diesem Grund fehlen bei EVB-IT System die iterativen Methodiken bzw. sind diese nicht einbezogen; s.a. Müller-Hengstenberg/Kirn, MMR 2012, 3, 6: nur indirekt, über V-Modell XT Version 1.3, Teil 8, Anhang S. 8.34 bestehe ein Bezug durch Verweis. 6 Etwa gestützt auf OLG Köln v. 22.10.1987 – 1 U 41/84, CR 1988, 734: Organisationsberatung ist Dienstvertrag; s. aber auch OLG Frankfurt v. 12.7.1989 – 9 U 61/88, CR 1990, 585 und dazu unten Rz. 309 ff. 7 S. aber zu den geringen Anforderungen an die Leistungsaufforderung (dort allerdings bei Werkvertrag) BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422. 8 S. zu BGH v. 23.3.2005 – III ZR 338/04 – Access-Providing als Dienstvertrag, CR 2005, 816 m. Anm. Schuppert; Bischof/Schneider, ITRB 2005, 214; BGH v. 11.11.2010 – III ZR 57/09, CR 2011, 163 lässt das Verhältnis von § 314 und § 626

Schneider

203

C Rz. 27

Verträge

27 Die BVB-Planung, die mangels sie ersetzender EVB1 noch gelten, enthalten in § 10 eine Klausel zur „Gewährleistung“, die dem Werkvertragsrecht angenähert ist. Dies hängt auch damit zusammen, dass eine Abnahme vorgeschaltet ist (§ 9 BVB-Planung). Dies ist aber gerade nicht die Konstruktion, die der Anbieter verfolgt, wenn er auf Dienstvertrag abzielt. Infolge dessen wäre ein Dienstvertrag seitens des Anbieters nur dann anzustreben, wenn sein Leistungsvolumen und seine Anstrengungen zumindest in Minimalform beschrieben sind. Ansonsten läuft er Gefahr, dass er letztlich eine Leistung ohne Pflichtverletzungen schuldet, die darin besteht, den Planungsprozess zu bewerkstelligen. Dass darin zwar schon ein Erfolgsmoment liegt bzw. ein solches hineininterpretiert werden kann, ist klar. Jedoch wurde im Zusammenhang mit Pflege von Bartsch sehr deutlich gemacht, dass der Kunde für die pauschale Pflegevergütung zu Recht etwas erwarten darf, was sich im Ergebnis nicht viel von dem unterscheidet, was als werkvertraglich orientierte Pflege geschuldet wäre, wie etwa die Gebrauchstauglichkeit der Software und deren Erhaltung2. 28 Im Folgenden wird nun die Behandlung des Pflichtenhefts in der Rechtsprechung dargestellt, wobei in der Regel der Vertrag, der das Pflichtenheft voraussetzt und bei dem dann das Pflichtenheft umzusetzen war, als Werkvertrag qualifiziert wurde, so dass eigentlich diese Phase „Planung“ als gesonderte, vorgeschaltete Phase, die auch gesondert in Auftrag zu geben ist, in den seltensten Fällen ins Blickfeld geriet. c) Das Pflichtenheft in der Rechtsprechung – v.a. des des BGH3 29 Der BGH hat in einer Reihe von Entscheidungen dem Pflichtengefüge beim Pflichtenheft eine ziemlich klare Kontur gegeben. Demnach ist primär und grundsätzlich der Auftraggeber dazu verpflichtet, das Pflichtenheft beizubringen. Dem liegt eine Konzeption des Pflichtenhefts zugrunde, die stark den fachlichen Aspekt betont und weniger den technischen (den Ausführungsaspekt)4. Durch diese Rechtsprechung hat sich auch die begriffliche Zuordnung im juristischen Sprachgebrauch eingebürgert, wonach das Pflichtenheft die fachlichen Anforderungen des Kunden enthält. Dem entspricht im Informatik-Sprachgebrauch und gemäß Normen das „Lastenheft“5.

1 2 3 4 5

BGB wegen des im konkreten Fall gleichen Erfordernisses – wichtiger Grund – offen; ebenso unter Verweis auf diese Entscheidung BGH v. 7.3.2013 – III ZR 231/12, Rz. 15 f. Palandt/Grüneberg, 72. Aufl., § 314 BGB Rz. 4: § 626 (u.ä. Vorschriften) hat als Sondervorschrift Vorrang. S. ggf. aktuell zu den geplanten „EVB-IT Planung“ unter http://www.cio.bund. de/DE/IT-Beschaffung/EVB-IT-und-BVB/evb-it_bvb_node.html. S. Bartsch, NJW 2002, 1526. Ihde, Das Pflichtenheft beim Softwareerstellungsvertrag, CR 1999, 409. Dazu noch unten Rz. 69 ff. Zur Klarstellung s. unten Rz. 82 f.

204

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

C

Rz. 33

Die Terminologie im juristischen Bereich ist uneinheitlich1. Gelegentlich 30 ist nur von den „Vorgaben“2 die Rede. Weitgehend klar scheint aber zu sein, dass solche Vorgaben, Anforderungen oder Ähnliches nicht automatisch das Pflichtenheft oder die Leistungsspezifikation bilden3. Die Erstellung des Pflichtenhefts gehört zur Phase der Planung. Die Phasen- 31 bildung impliziert die Vorstellung einer Abfolge verschiedener Schritte bei der Erstellung der Software. Eine der ältesten Entscheidungen hierzu betrifft primär den urheberrechtlichen Schutz (vor der entsprechenden EU-Richtlinie und deren Umsetzung)4. Der BGH hat die Phasen wie folgt gebildet: 1. generelle Problemlösung, auch Problem- oder Systemanalyse genannt. „Das Ergebnis der Analysephase ist der Lösungsweg, der in einer Studie (auch Pflichtenheft genannt), beschrieben wird.“

2. in der zweiten Phase erfolgt die nähere Projektion der Problemlösung5. Diese Entscheidung legte bereits nahe (was häufig unbeachtet bleibt), dass 32 man innerhalb des Pflichtenhefts zwischen den fachlichen Vorgaben als der einen Stufe und deren Umsetzung in technische Problemlösung als der weiteren Stufe differenzieren muss6. Ohne zeitliche Abfolge kann eine entsprechende Einteilung dahingehend getroffen werden, dass einerseits die fachlich/organisatorischen (u.a. die Geschäftsabläufe betreffenden) Vorgaben, andererseits die „EDV-technischen“ Maßgaben und Anforderungen beizubringen sind. Diese Einteilung erlaubt die einfache Zuordnung der fachlich/organisatorischen Vorgaben als Aufgabe des Auftraggebers, die EDVtechnischen als Aufgabe des Auftragnehmers7. Eine weitere Vorstufe zu der Rechtsprechungskette kann man in der Ent- 33 scheidung v. 24.6.1986 sehen, in der es primär um Reservekapazitäten im Mengengerüst ging. Laut Sachverhalt hat bei Vertragsabschluss noch keine, alle Einzelheiten berücksichtigende Dokumentation (sog. Pflichtenheft)

1 Dazu sogleich Rz. 34 ff. 2 Z.B. OLG Köln v. 8.4.2005 – 6 U 194/04, CR 2005, 624, im Zusammenhang mit der Prüfung, inwieweit „Entwurfsmaterial“ i.S.d. § 69a UrhG vorliegt. 3 S. etwa OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95, wo der Auftraggeber zunächst neue Anforderungen zur Anpassung stellte und später erst im Laufe des Projekts ein „Lastenheft“ erstellt wurde. 4 BGH v. 9.5.1985 – I ZR 52/83, CR 1985, 22 – Inkassoprogramm (Problem- oder Systemanalyse, Datenflussplan, Programmablaufplan, Codierung); s.a. Kap A Rz. 8 ff. 5 BGH v. 9.5.1985 – I ZR 52/83, CR 1985, 22, 29 – Inkassoprogramm, Hervorhebung v. Verfasser. 6 Die Entscheidung v. 9.5.1985 stammt vom 1. Senat, der für das Urheberrecht zuständig ist, die wichtigen Entscheidungen zum Pflichtenheft stammen ansonsten vom VIII. und X. Senat, die hinsichtlich dieser Phaseneinteilung nicht weiter differenzieren. 7 S.a. Redeker, IT-Recht, 5. Aufl., Rz. 304.

Schneider

205

C Rz. 34

Verträge

vorgelegen. Gleichwohl garantierte die Klägerin einen festen Termin für die Einführung des Projekts1. 34 Die grundlegende Entscheidung stammt aus dem Jahr 1988. Ohne den Begriff des Pflichtenhefts zu erwähnen – die konkrete Situation gab hierzu wenig Anlass, da es sich um eine Registrierkasse und die Menü-Belegung handelte –, entschied der BGH, dass die Beistellung der Programmvorgaben in die Sphäre des Kunden fällt. „3. Kommt der Kunde mit den notwendigen Programmvorgaben nicht zurecht, so muss er den Softwareersteller um Unterstützung bitten, die vorzugsweise durch praktische Unterweisung eines Sachkundigen zu leisten ist. 4. Leistet der Kunde einfache Programmiervorgaben auch dann nicht, so genügt er seiner Mitwirkungspflicht nicht. …“2

35 Diese Entscheidung verdeutlicht, wie eng die beiderseitigen Pflichten hinsichtlich der Vorgaben verzahnt sind: Evtl. ist eine Unterstützung des Auftragnehmers erforderlich, um die aber der Auftraggeber bitten sollte, wenn er nicht „zurecht kommt“, er also Hilfe braucht. 36 Bei der wichtigsten Entscheidung ging es um das „Vergessene Pflichtenheft“3. Der Auftragnehmer war damit beauftragt, auch das Pflichtenheft zu erstellen. Dies hat er nicht getan. Vielmehr haben sich beide Vertragspartner einvernehmlich an die Durchführung des Projekts gemacht. Sie haben die Erstellung des Pflichtenhefts „vergessen“4. Damit haben die Parteien praktisch auf dieses Erfordernis verzichtet, so dass sich der Auftraggeber später nicht auf das Fehlen berufen konnte. Es galt das Erfordernis des mittleren Ausführungsstandards – so als ob die Erstellung des Pflichtenhefts nicht vereinbart gewesen wäre5. 37 Der BGH hat die Erstellung des Pflichtenhefts als eine Phase angesehen, die man überspringen kann. Die Folge ist, dass dann neue, diesen Umstand des fehlenden Pflichtenhefts berücksichtigende Regeln gelten. Das „vergessene“ Pflichtenheft wird als Leistungspflicht durch die tatsächliche Auftragsdurchführung hinfällig6. Dies wird erst recht gelten, wenn gar nicht erst die Erstellung des Pflichtenhefts durch den Auftragnehmer vertraglich vereinbart wird. 38 Was aber soll dann anstelle der Maßgaben des Pflichtenhefts gelten? Kann der Kunde einfach bestimmen, indem er nachträglich seine Anforderungen formuliert, wie die Software beschaffen sein soll und erforscht der Anbieter diese Wünsche7? 1 BGH v. 24.6.1986 – X ZR 16/85 – S-Projekt I, CR 1986, 799. 2 BGH v. 13.7.1988 – VIII ZR 292/87 – Registrierkassen, CR 1989, 102, LS 3, 4 Satz 1. 3 BGH v. 24.9.1991 – X ZR 85/90– Zugangskontrollsystem, CR 1992, 543. 4 BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543. 5 BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543, LS 1. 6 BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543, LS 3. 7 S. etwa OLG Köln v. 18.6.1993 – 19 U 215/92, CR 1993, 624, und OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459; OLG Düsseldorf v. 10.12.1993 – 17 U

206

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 42

C

Genuin beibringungspflichtig für die fachlichen Anforderungen ist der Auf- 39 traggeber, da es sich um seine Sphäre und Disposition handelt. Jedoch kann es sein, dass der Auftraggeber Unterstützung benötigt, die der Auftragnehmer deshalb vorsorglich anbieten sollte, deren Anforderung aber ebenfalls Sache des Auftraggebers ist1. Sachnäher und fairer als OLG Köln und Düsseldorf2 erscheint die Vorstel- 40 lung des OLG Stuttgart von einem intensiven Dialog zwischen Anbieter und Kunden3. Hat der Auftraggeber sich nicht geäußert, der Auftragnehmer nicht nach- 41 gefragt, könnte es sein, dass der Kunde sich negativ äußert, indem er, spätestens bei der Aufforderung zur Abnahme sagt, dass ihm die Software so „nicht gefällt“. Dagegen hilft die bereits zitierte BGH-Entscheidung: „Bei einem Entwicklungsauftrag ist mangels Pflichtenheft oder anderer konkreter Absprachen ein Ergebnis geschuldet, das dem Stand der Technik bei mittlerem Ausführungsstandard entspricht“4.

Ausdrücklich besagt LS 2, dass dies auch dann gelte, wenn die Parteien zwar vorgesehen hatten, dass der Auftragnehmer ein Pflichtenheft unterbreitet, „es dann aber zur Durchführung der Entwicklung ohne Pflichtenheftfestlegungen“ kommt5. Daraus konnte man schließen, dass erst recht dann, wenn nicht ausdrück- 42 lich vereinbart ist, dass der Auftragnehmer das Pflichtenheft erstellt, ein mittlerer Ausführungsstandard geschuldet ist – was auch immer dies sei. Die Frage bleibt allerdings, ob nicht der Auftragnehmer gut daran tut, den Auftraggeber rechtzeitig, nämlich vor Vertragsschluss, spätestens – wenn auch dann mit Risiko – zu Beginn des Projekts aufzufordern, die Anforderungen beizubringen. Häufig wird dies deshalb unterlassen worden sein, weil man trotz fehlendem Pflichtenheft einen Festpreis ausgemacht hat. Insofern passt „mittlerer Ausführungsstandard“ mit Festpreis wesentlich besser zusammen als mit Aufwandsprojekt. Das Unterlassen der Nachforschungen nach den Anforderungen des Kunden macht dabei Sinn.

1 2

3 4 5

33/93, CR 1994, 351; OLG Karlsruhe v. 11.8.1998 – 8 U 241/97, CI 1999, 113; Schneider, Handbuch des EDV-Rechts, D. Rz. 575 ff. und vor allem Rz. 592 ff. m.w.N. S. Rz. 29 ff., 34 i.V.m. BGH v. 13.7.1988 – VIII ZR 292/87 – Registrierkassen, CR 1989, 102; s.a. zum zitierten LS 3 oben Rz. 34. S. OLG Köln v. 18.6.1993 – 19 U 215/92, CR 1993, 624; OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459; OLG Düsseldorf v. 10.12.1993 – 17 U 33/93, CR 1994, 351. OLG Stuttgart v. 18.10.1988 – 6 U 64/88, CR 1989, 498; etwas in diese Richtung OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459. BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543, LS 1. BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543, LS 2.

Schneider

207

C Rz. 43

Verträge

43 Die bisherigen Entscheidungen wurden in den weiteren indirekt bestätigt. Es ging um die Pflicht zur Nachlieferung einer Kopie des Pflichtenhefts, nachdem das Pflichtenheft durch einen Brand beschädigt worden war und der Auftragnehmer deshalb nochmals eine Kopie benötigte1. Dieses Urteil bestätigt, dass der Auftraggeber für die Beibringung des Pflichtenhefts genuin verantwortlich ist, wenn sogar die Nachlieferung nach dem Verlust des Pflichtenhefts noch zu seinen Pflichten gehört. 44 Dass die Vorgaben vom Auftraggeber nicht nur im Rahmen eines bei Vertragsschluss vorliegenden Pflichtenhefts beizubringen, sondern auch, wenn dies unterblieb, später nachzuholen sind, ergibt sich aus einer weiteren Meilenstein-Entscheidung des BGH. Dem äußeren Anschein nach und nach Meinung der Vorinstanz befand sich der Auftragnehmer bereits in Verzug, weil er nicht die geschuldete Dokumentation geliefert hatte. Dieser Verzug bestand nach Ansicht des BGH jedoch nicht, weil der Auftraggeber seinerseits seine Mitwirkungshandlungen nicht erbracht hatte2. Die auftraggebende Klägerin hatte ihrerseits für die Bearbeitung notwendige Unterlagen über das Geschäftssystem der Klägerin, das in die Software integriert werden und auf dem diese aufbauen sollte, nicht beigebracht. Es wurde auch nicht der für die Finanzbuchhaltung erforderliche Kontenrahmen übermittelt. Zudem waren für den fraglichen Geschäftsbetrieb wichtige Parameter nicht bezeichnet worden, so insbesondere hier die Provisionsstruktur3. Daraus lässt sich, was allerdings der LS so nicht besagt, ableiten, dass kein Verzug des Auftragnehmers bei fehlender Vorgabe des Auftraggebers eintritt. Dies weist eindeutig die Beibringung der Vorgaben der Sphäre des Auftraggebers zu. 45 Eine Fortführung der oben dargelegten Entscheidung des BGH4 behandelt nochmals das Problem, was bei fehlendem Pflichtenheft, hier ohne dass der Auftragnehmer damit beauftragt worden sei, gelten solle. „Haben die Vertragsparteien nicht im Einzelnen vereinbart, was das zu erstellende Programm zu leisten hat, schuldet der Unternehmer ein Datenverarbeitungsprogramm, das unter Berücksichtigung des vertraglichen Zwecks des Programms dem Stand der Technik bei einem mittleren Ausführungsstandard entspricht. Welche Anforderungen sich hieraus im Einzelnen ergeben, hat der Tatrichter ggf. mit sachverständiger Hilfe festzustellen.“5

Im konkreten Fall war streitig, ob das Programm diesem Stand der Technik bei mittlerem Ausführungsstandard entsprach. 46 Der Entscheidung lässt sich u.a. entnehmen, dass auch dann, wenn ein Pflichtenheft erstellt wurde, jedoch Einzelheiten noch nicht festgelegt sind (und man keine Vereinbarung getroffen hat, wie diese zu gewinnen sind), 1 2 3 4 5

BGH v. 28.6.1994 – X ZR 95/92, CR 1995, 265. BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft, CR 1998, 393. BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft, CR 1998, 393. BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543, s. Rz. 41. BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490, LS 2.

208

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 50

C

ein mittlerer Ausführungsstandard gilt. Dies öffnet für den ausführenden Auftragnehmer gewisse Interpretationsmöglichkeiten, allerdings auch das Risiko, was ebenfalls diesem Urteil zu entnehmen ist, dass der Richter über die richtige Interpretation dieser nicht genau festgelegten Vorgaben – i.V.m. einem Sachverständigen-Gutachten – entscheidet. Vorläufig lässt sich das Ergebnis wie folgt zusammenfassen: Nach den zi- 47 tierten Entscheidungen betrifft das Pflichtenheft vor allem den Komplex bzw. die Stufe der „fachlichen Vorgaben“ (in Differenzierung zu den „technischen“). Die Beibringung der fachlichen Vorgaben gehört zu den Mitwirkungspflichten des Auftraggebers. Die Nichtbeibringung führt dazu, dass der Auftragnehmer insoweit, als es um die Umsetzung geht, nicht in Verzug kommen kann bzw. dass er ggf. ein Werk mit mittlerem Ausführungsstandard liefern darf. Präzisiert wird dies durch das Erfordernis, dass der vertragliche Zweck zu berücksichtigen ist und zudem dem Stand der Technik zu entsprechen hat. Die Schwierigkeiten der Feststellung gehen dann allerdings vor der Abnahme – wenn eine solche zu erfolgen hat – zu Lasten des Auftragnehmers, weil dieser beweisen muss, dass das Werk im Wesentlichen vertragsgemäß ist. Infolgedessen muss er auch den vertragsgemäßen Umfang entsprechend darlegen und nicht nur, dass dieser eingehalten ist. Ggf. wird der Kunde, wenn er nicht in der Lage ist, seine Anforderungen zu 48 formulieren, Unterstützung einfordern. Dies ist ein Komplex, der wohl vor allem für die Anpassung von Standardsoftware von Bedeutung ist, weil häufig der Kunde gar nicht weiß, was mit welchen Kosten bzw. Folgen hinsichtlich des Aufwands verbunden ist. Dies kann es sinnvoll machen, frühzeitig eine Einweisung/Schulung der Mitarbeiter des Kunden vorzunehmen. Es sei aber bedacht, dass die Einweisung/Schulung grundsätzlich möglichst nahe an der Abnahme stattfinden sollte, damit deren Wirkung noch möglichst frisch ist. Notfalls wäre sie nachzuholen1. d) Extrapolation der Maßgaben des BGH Die vorstehenden Urteile ergingen zu BGB a.F. Die Schuldrechtsmoderni- 49 sierung gibt keinen Anlass zu grundsätzlicher Änderung hinsichtlich der Verantwortungsverteilung. Allerdings könnte sich eine stärkere Betonung der Eignung zum (vereinbarten) Vertragszweck ergeben. Zudem gilt diese Aussage wohl nur für den Fall, dass den Kunden auch tatsächlich Mitwirkungspflichten treffen. Dies wäre vor allem bei Herstellung von Standardsoftware – als vertretbarer Sache – nicht der Fall, wenn man § 651 BGB anwendet2. Unabhängig davon aber würde, wenn die Parteien schlicht auf die Erstellung des Pflichtenhefts verzichten bzw. ein solches nicht Grundlage des Vertrages wird, gelten, was sich im Übrigen aus den BGH-Entscheidungen 1 S.a. Redeker, Kap. D Rz. 100, 121. 2 S. oben Kap. B Rz. 46, 74, 106.

Schneider

209

50

C Rz. 51

Verträge

ergibt, nämlich der mittlere Ausführungsstandard, genauer: Ein Programm, das unter Berücksichtigung des vertraglichen Zwecks des Programms dem Stand der Technik bei mittlerem Ausführungsstandard entspricht1. 51 Einige OLG nehmen als Gegengewicht zur Beibringungspflicht des Auftraggebers nicht etwa, wie der BGH, eine Hinweispflicht des Auftraggebers an, dass er Hilfe benötigt, sondern eine Erkundigungspflicht des Auftragnehmers. Nach Ansicht etwa des OLG Köln musste der Auftragnehmer von sich aus die innerbetrieblichen Bedürfnisse ermitteln und darauf drängen, dass der Anwender diese in einem Pflichtenheft niederlegt. Außerdem muss er die für ihn erkennbaren Unklarheiten und Bedürfnisse aufklären, bei der Formulierung der Aufgabenstellung mitwirken und sogar einen Organisationsvorschlag zur Problemlösung unterbreiten. Wenn dies nicht geschieht, hätte der Auftragnehmer eine Pflicht verletzt und er ist verantwortlich dafür, wenn dem Programm „die erforderliche Unkompliziertheit und Eignung für die individuellen Bedürfnisse des Anwenders fehlt“2. 52 Dass der Auftraggeber nicht in der Lage sei, seine Beibringung der Vorgaben ordnungsgemäß vorzunehmen, vielmehr also der Auftragnehmer an die Stelle des Pflichtenhefts seine Erkundigungspflicht zu setzen habe (wobei dies so explizit meist nicht gesehen wurde), ist ohnehin die Auffassung vieler Gerichte3. Die gilt aber eigentlich (nur) für die technische Spezifikation. 53 Nun könnte sich ein neues Anwendungsfeld für diese teilweise veraltet wirkende Auffassung von der fehlenden Kompetenz des Auftraggebers ergeben: Bei modernen Methoden arbeiten die Vertragspartner aufs Engste zusammen, s. Rz. 124 ff. Weiß aber der Auftraggeber, worauf genau er sich einlässt4? 54 Die Konsequenz aus der Verschränkung von Beibringungspflichten des Auftraggebers und Unterstützungs- und eventuellen Erkundigungspflichten des Auftragnehmers ist die Empfehlung, dass beide Vertragspartner eng zusammenzuarbeiten und „das Projekt nur bei gemeinsamer Anstrengung erfolgreich durchgeführt werden kann“5. Damit rückt das Vorgehenskonzept in die Nähe der „modernen“, insbesondere „agilen“ Methodik, s.a. unten Rz. 124. Damit nähert sich das Grundmodell der Kooperation, zumindest dem Dienstvertrag an. Aber auch bei Werkvertrag treten Probleme dort auf, wo 1 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490, s. oben Rz. 46 f. 2 OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459, LS des Vorsitzenden; s.a. schon zur Ermittlungspflicht OLG Köln v. 16.8.1993 – 19 U 215/92, CR 1993, 624 und dazu Rz. 38. 3 Zu den Nachweisen s. Schneider, Handbuch des EDV-Rechts, D. Rz. 540, 572, 592 ff. 4 Zur evtl. Aufklärungspflicht s. Rz. 190, Kap. D Rz. 4 ff.; zu nicht funktionalen Anforderungen Stiemerling, ITRB 2010, 289 (ITRB 2009, 154); Rz. 144, 147. 5 S. „Kooperationspflicht“ bei Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4, § 2 Abs. 1, und zum gemeinsam erstellten Pflichtenheft (hier technisch gemeint) § 4 Abs. 1c) und Anm. 14.

210

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 61

C

dieser Empfehlung zur Zusammenarbeit nicht gefolgt wird, mit Fragen wie folgt: 1) Kann der Auftragnehmer den Auftraggeber etwa i.V.m. einer Fristsetzung 55 auffordern, bestimmte Vorgaben zu machen bzw. Erläuterungen zu Vorgaben zu geben, anderenfalls – nach wie vor – den mittleren Ausführungsstandard wählen bzw. soweit arbeiten, wie er ohne diese Vorgaben kommt und dann seine Vergütung verlangen? 2) Muss der Auftraggeber, wenn er sich nicht in der Lage sieht, diese Anga- 56 ben/Vorgaben zu machen, von sich aus den Auftragnehmer um Unterstützung bitten bzw. diesem Gelegenheit geben, ihn zu unterstützen und geht, falls er dies nicht tut, dies allein zu Lasten des Auftraggebers? 3) Führt eine Leistungsbeschreibung, die vielleicht gemeinsam erstellt wur- 57 de, aber nicht vollständig bzw. genügend detailliert ist, dazu, dass damit unmittelbar die Realisierung vorgenommen werden kann? Ist der Maßstab bei der Ausfüllung und Konkretisierung der mittlere Ausführungsstandard oder greifen die übrigen Ebenen des Mangelbegriffs? Wann liegt keine Konkretisierung vor, sondern eine Erweiterung (als Änderung)1? Diese Frage stellen sich praktisch in der Phase und im Zusammenhang mit 58 der Realisierung und dort vor allem bei der Abnahme. Eine weitere Frage ist noch im Hinblick auf eine Abgrenzungsproblematik hinzuzufügen: 4) Besteht eine Aufklärungspflicht oder sogar Erkundigungspflicht2 seitens des Auftragnehmers, an die Stelle etwaiger Vorgaben des Auftraggebers solche Maßnahmen zu setzen, die ihm die nötigen Informationen vermitteln, ggf. auch zur Überprüfung der Angaben des Auftraggebers3?

59

Vor allem gemäß OLG Köln4 hat der Anbieter von sich aus die innerbetrieb- 60 lichen Bedürfnisse des Anwenders zu ermitteln und darauf zu drängen, dass der Anwender diese in einem Pflichtenheft niederlegt; ebenso hat er für ihn erkennbare Unklarheiten und Bedürfnisse aufzuklären, bei der Formulierung der Aufgabenstellung mitzuwirken und einen Organisationsvorschlag zur Problemlösung zu unterbreiten5. Gemäß OLG Köln6 ist zwar der Auftraggeber verpflichtet, dem „Program- 61 mierer die für die Erstellung notwendigen Angaben zu machen“, jedoch nur, um ihm „die Aufgabenstellung“ zu vermitteln. Wenn der Programmierer 1 Zum Risiko für den Auftragnehmer s. etwa OLG Köln v. 22.9.1994 – 19 U 65/94, CR 1996, 20; OLG Köln v. 3.12.1993 – 19 U 157/93, CR 1994, 229. 2 Bejahend etwa OLG Köln v. 18.6.1993 – 19 U 215/92, CR 1993, 624; OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459. 3 Indirekt zumindest zwecks Vermeidung des „Funktionsmangels“, aber auch grunds., s. Rz. 240 ff. 4 OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459. 5 OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459; s.a. OLG Köln v. 22.9.1995 – 19 U 65/94, CR 1996, 20. 6 OLG Köln v. 22.9.1995 – 19 U 65/94, CR 1996, 20.

Schneider

211

C Rz. 62

Verträge

die Angaben für unzureichend hält – was also eine Prüfungspflicht impliziert –, entlastet es den Programmierer nicht, wenn die von ihm erstellte Software Mängel aufweist, die auf unvollständigen Angaben des Bestellers beruhen. Praktisch ergibt sich daraus eine Prüfungspflicht des Anbieters. 62 Eine der Hauptfragen in diesem Zusammenhang, die für sämtliche Fragen oben eine wichtige Vorfrage ist, betrifft den Mangelbegriff. Diese Frage geht dahin, inwieweit die Ausführungs- bzw. Mängelkategorien durch die Vereinbarung der Leistung gemäß Pflichtenheft verdrängt oder ausgefüllt werden. 63 § 434 BGB – für den Fall, dass über § 651 BGB Kaufrecht Anwendung findet –, und ebenso § 633 BGB regeln – vom Wortlaut her – eine Hierarchie der Beschaffenheits-Ebenen1. 64 Den absoluten Vorrang genießt die „vereinbarte Beschaffenheit“. Als solche kann das gelten, was in der Leistungsbeschreibung, also im „Pflichtenheft“, wenn dies Vertragsgrundlage wurde oder wenn dies während des Vertrages erarbeitet wird, festgehalten ist. 65 Die übrigen Kategorien kommen nur in Betracht, „soweit die Beschaffenheit nicht vereinbart ist“, wobei es dann auf die nach dem Vertrag vorausgesetzte Verwendung ankommt, „sonst“, also als dritte Stufe, kommt „es auf die Eignung für die gewöhnliche Verwendung an und zudem die Beschaffenheit, die bei Werken der gleichen Art üblich ist und die der Besteller nach der Art des Werkes erwarten kann“2. Bei kaufrechtlicher Beurteilung würden noch die öffentlichen Äußerungen des Herstellers in die letzte Kategorie einfließen, wenn diese nicht ausdrücklich herausgenommen werden. Darauf kommt es aber gar nicht an, wenn schon mit dem „Pflichtenheft“ diese Ebene verdrängt wurde. 66 Dieses Rangverhältnis ergibt sich eindeutig aus dem Wortlaut der deutschen Regelung. Sie steht aber nicht im Einklang mit der Verbrauchsgüterkaufrichtlinie, um deren Umsetzung es sich insoweit handelt. Gemäß der EU-Richtlinie waren vier Voraussetzungen kumulativ erforderlich, um die Vermutung zu bewirken, dass die Sache mangelfrei ist, ohne dass es auf die hierarchische Abschichtung ankam. Im Gegenteil: Die Notwendigkeit der Kumulation der Merkmale und der daraus abzuleitenden Vermutung ergibt gerade, dass es keine klare, eindeutige Ja/Nein-Entscheidung im Hinblick auf die „Verdrängung“ der übrigen Leistungskategorien durch das Pflichtenheft gibt. Es stellt sich deshalb auf Dauer die Frage, ob im Hinblick auf die Verbrauchsgüterkaufrichtlinie die deutsche Umsetzung ausreichend war. Da man ohne Not die Umsetzung im allgemeinen Schuldrecht vorgenommen hat, also generell, ohne auf eine Beschränkung bzw. eine Spezialrege1 S. Schneider, ITRB 2010, 241, dazu sogleich und unten Rz. 152; s.a. Kap. D Rz. 245 zum Begriff des Mangels. 2 Zur Bestimmung der „gewöhnlichen“ Verwendung, auch unter dem Aspekt „Usability“ s. Schneider, ITRB 2010, 241 (243) und Stiemerling, ITRB 2009, 154.

212

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 69

C

lung hinsichtlich des Verbrauchsgüterkaufs abzustellen (etwa i.V.m. den Regelungen zu §§ 474 ff. BGB) wird einerseits eine Interpretation im Lichte der Verbrauchsgüterkaufrichtlinie auch bei solchen Verträgen möglich sein und erfolgen müssen, die nicht Verbrauchsgüterkauf sind. Andererseits stellt sich dann die Frage nach dem Rangverhältnis des Pflichtenhefts zu den übrigen Kategorien. Der BGH hat mit seiner Rechtsprechung zum Funktionsmangel1 deutlich gemacht, dass die Mangelhierarchie nicht besteht bzw. nicht abschließend ist. Einige Gerichte hatten eine Mangel-Kategorie der „Selbstverständlichkei- 67 ten“ entwickelt2. Diese griff auch dann, wenn die Parteien nichts vereinbart hatten. Diese Kategorie fällt am ehesten in die Ebene der „Eignung für die gewöhnliche Verwendung und Beschaffenheit, die bei Sachen der gleichen Art üblich ist und die der Käufer nach der Art der Sache erwarten kann“. Wenn man nun das Pflichtenheft als die übrigen Kategorien verdrängend ansehen würde, so würde dies bedeuten, dass für diese Selbstverständlichkeiten eigentlich kein Raum ist. Dies würde dann aber auch für den „mittleren Ausführungsstandard“ gelten. Angesichts der EU-rechtlich gebotenen offenen Interpretation der Mängelregelung erscheint es aber richtig, sowohl „Selbstverständlichkeiten“ als auch „mittleren Ausführungsstandard“ ergänzend, orientiert am Vertragszweck, heranzuziehen. Dies muss nicht identisch mit der gewöhnlichen Verwendung bzw. mit der Käufererwartung sein. Am nächsten kommt diese Kategorie wohl dem Merkmal der Beschaffenheit, die bei Sachen der gleichen Art üblich ist. Sie impliziert, dass – die Beschaffenheitsvereinbarung, etwa über das „Pflichtenheft“, nicht abschließend ist, – in der Hierarchie der Mangelebenen die untere greift, wenn die obere keine Regelungen zu der fraglichen Eigenschaft enthält. Individualvertraglich ist deshalb zu empfehlen, hinsichtlich des in den Ver- 68 trag einbezogenen Pflichtenhefts klar zu stellen, ob dessen Anforderungen vollständig sind bzw. abschließend gelten sollen3. Vor allem wäre aber besonders Augenmerk auf die nicht-funktionalen Anforderungen zu verwenden. S. Rz. 144 ff. e) Versuch der Bestimmung der Funktion und der Aufgabe des Pflichtenhefts als fachliche Feinspezifikation Einer der Hauptanwendungsfälle für die Fragestellung, welche Pflichten den 69 Auftraggeber – ohne gesonderte Vereinbarung im Vertrag – während des Pro1 BGH v. 8.11.2007 – VII ZR 183/05, NJW 2008, 511; BGH v. 29.9.2011 – VII ZR 87/11, NJW 2011, 3780. 2 S. Schneider, Handbuch des EDV-Rechts, D. Rz. 952, 958 ff., 1060 ff. 3 Zur Pflicht der Über-Kompensation eines vereinbarten Delta-Pflichtenhefts durch den Auftragnehmer s. OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 361.

Schneider

213

C Rz. 70

Verträge

jektes treffen, ist die Anpassung von Standardsoftware. Ein weiterer Hauptanwendungsfall dürfte der der vertragstypologischen Einordnung sein. 70 Ist nichts Konkretes vereinbart, kommt zwar grundsätzlich immer noch Werkvertragsrecht (nach alter und neuer Auffassung) in Betracht1, der geschuldete Erfolg ist jedoch nur schwer ermittelbar. Wenn der geschuldete Erfolg nicht genügend klar ist, dürfte es sich entweder um ein Entwicklungs-Projekt oder um einen reinen Dienstvertrag handeln. Dies gilt insbesondere für so genannte Zurufprojekte, bei denen also die Mitarbeiter einfach dem Programmierer sagen, was sie wollen, ohne dass es ein konkretes Pflichtenheft und eine Maßgabe gibt, welcher Zustand endgültig erreicht werden soll2. 71 Die Kategorie des „mittleren Ausführungsstandards“ wird zumindest bewirken, dass der Auftraggeber bei einem Projekt ohne vorherige Festlegung des Leistungsumfangs in einem Pflichtenheft keine anderen Anforderungen als solche stellen kann, die noch im Fokus dieses Ausführungsstandards liegen. Das bedeutet in der Regel, dass gerade die Besonderheiten des jeweiligen Kunden nicht von diesem als Vorgabe verlangt werden können, jedenfalls nicht im Rahmen des „mittleren Ausführungsstandards“. Es findet eine Art Vergabelung statt. Soweit ein Pflichtenheft vorliegt, werden durch die „vereinbarte Beschaffenheit“ die übrigen Mangelkategorien (§ 633 Abs. 2 Satz 2 BGB) verdrängt – nicht aber der Funktionsmangel3. Soweit keines vorliegt, kommen zwar die übrigen Mangel-Kategorien ggf. zur Anwendung, aber nur, soweit diese sich mit dem „mittleren Ausführungsstandard“ als Referenz kombinieren lassen. Da der Mangelbegriff insofern je Ebene immer allgemeiner wird, werden gerade die speziellen Anforderungen des Kunden insoweit sowohl über den „mittleren Ausführungsstandard“ orientiert am Vertragszweck und am Standard als auch über den Mangelbegriff ausgeblendet bzw. durch diese Kategorien begrenzt. 72 Dem kann als Argument entgegengesetzt werden, dass der Kunde ja Laie sei. Es gibt in der Tat eine Rechtsprechung, die besonders darauf abstellt, welche Pflichten den Vertragspartner im Hinblick darauf treffen, dass sein Kunde ein solcher so genannter Laie ist. Dieses Kompetenzgefälle führt dazu, dass der Verkäufer, der ein besonderes Interesse an dem Abschluss des Vertrages hat, in besonderer Weise aufklärungspflichtig wird. Dies gilt erst recht, wenn der Verkäufer von sich aus bereits in gewissem Sinne schon informativ tätig geworden ist, etwa indem er eine Vorstudie erstellt hat, eine

1 S. Kap. B Rz. 92 ff., 106. 2 A.M. OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95 und dazu auch Schneider, CR 2003, 317. 3 BGH v. 8.11.2007 – VII ZR 183/05, NJW 2008, 511; BGH v. 29.9.2011 – VII 87/11, NJW 2011, 3780.

214

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 76

C

Präsentationsunterlage speziell für den Auftraggeber erarbeitet hat und ähnliche Planungsarbeiten liefert1. Bevor es aber zur Frage des Kompetenzgefälles zwischen fachkundigem Ver- 73 käufer und laienhaftem Kunden kommt, sollte genauer geprüft werden, um welche Art der Fachkunde und welches Gebiet es sich handelt. Konkret gibt es niemanden, der die Anforderungen des Kunden besser kennt, als dieser selbst. Es wird deshalb eine ganz wesentliche Aufgabe sein, den fachlichen, aufgaben-spezifischen Teil des Pflichtenhefts als Sphäre des Kunden herauszuschälen und von der Realisierung und auch eventuell dem technischen Teil abzugrenzen, der möglicherweise noch zu den Vorgaben gehört. Bei agilen Verfahren, vor allem bei Scrum, ist es typisch, dass die Nutzer ih- 74 re Forderungen zunächst ungefiltert aus ihrer Sphäre heraus formulieren. Für solche „Wünsche“ steht der Nutzer als Fachmann, ein Gefälle besteht insofern, als der Auftragnehmer diese Wünsche und die Welt, aus der sie stammen, nicht versteht. Zur Vermeidung von Missverständnissen, die erst bei Besichtigung der Ergebnisse eines Sprints auftreten, empfehlen sich Redaktionsteams und -sitzungen2. Diese behandeln etwa „Ereignisse“: „Vorgeschriebene Ereignisse werden in Scrum verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit für andere Besprechungen zu minimieren. Für alle Ereignisse sind in Scrum Zeitfenster („time-boxes“) vorgesehen, durch welche die maximale Dauer jedes Ereignisses begrenzt wird. Dadurch wird ein angemessener Zeitanteil für Planungszwecke vorgesehen, der keine Verschwendung zulässt. Anders als der Sprint, der ein Container für alle anderen Scrum Ereignisse ist, bieten die übrigen Ereignisse in Scrum eine formale Möglichkeit, Sachverhalte zu beobachten und anzupassen („inspect and adapt“). Die Ereignisse sind speziell dazu entworfen, kritische Transparenz zu erzeugen und eine Untersuchung zu ermöglichen. Werden Ereignisse ausgelassen, führt das zu reduzierter Transparenz und es wird eine Chance zur Überprüfung und Anpassung vergeben.“3

75

Nimmt man eine Erkundigungspflicht des Auftragnehmers an, wie oben 76 angedeutet4, könnte diese nur hinsichtlich der fachlichen Anforderungen darin bestehen, die Themen anzugeben, zu denen der Auftraggeber sich äußern soll, während die Inhalte und vor allem auch die Besonderheiten hinsichtlich dieser Inhalte allein vom Auftraggeber kommen können. Je mehr die Vorgaben auf bereits bestehende Software zu beziehen sind (die dann entsprechend anzupassen ist), um so wichtiger wird allerdings sein, dass der Auftragnehmer diese Themen vorgibt und den Auftraggeber bzw. dessen

1 Zu den Grundsätzen s. hierzu vor allem BGH v. 6.6.1984 – VIII ZR 83/83, CR 1986, 79. 2 Soweit diese Funktion nicht durch die Product Owner und Scrum Master aufgefangen werden. 3 S. Scrum Guide Okt. 2011, S. 8. http://www.scrum.org/storage/scrumguides/ Scrum_Guide%20-%20DE.pdf. 4 S. Rz. 54, 59; s.a. OLG Köln v. 18.6.1993 – 19 U 215/92, CR 1993, 624; OLG Düsseldorf v. 10.12.1993 – 17 U 33/93, CR 1994, 351; OLG Karlsruhe CI 1998, 113.

Schneider

215

C Rz. 77

Verträge

Mitarbeiter in den Möglichkeiten dieser Software unterweist, so dass die Mitarbeiter des Auftraggebers wissen, „was sie wollen dürfen“. Die Projektion der Kundenforderungen auf bestehende Software oder der Einstellungsmöglichkeiten dieser Software auf die Belange des Kunden wäre der „technischen“ Ausprägung des Pflichtenhefts als Schritt der Realisierung der Sphäre des Anbieters zuzurechnen. Tatsächlich lassen sich die Forderungen des Kunden mit Blick auf bestehende Software und deren Anpassung einerseits nur schwer von der Aufgabe des Anbieters trennen, andererseits die Möglichkeiten der Software und deren Einstellungen/Parameter im Hinblick auf die Belange des Kunden darzustellen. Die beiderseitigen Darlegungen und Hinweise sind miteinander verflochten bzw. bedingen sich. 77 So gesehen hat die Auffassung des OLG Stuttgart weiterhin Relevanz, wonach die Parteien das Pflichtenheft bzw. die Anforderungen „in einem intensiven Dialog“ gemeinsam erstellen1, aber auch eine Aufklärung dazu seitens des Auftragnehmers zu erfolgen hat2. Erst recht lässt sich diese Rechtsprechung heranziehen, wenn das Projekt agil, insbesondere mit Scrum realisiert werden soll: Zum einen erfolgt die Artikulation der „Wünsche“ des Auftraggebers in unredigierten Wünschen/Tickets, eventuell im Rahmen eines speziellen Ticketverwaltungssystems zur Überführung in das Backlog, zum anderen werden sie turnusmäßig zu Backlog-Einträgen (dort mit klarer Formulierung)3 bzw. Sprint-Logs verarbeitet und umgesetzt. 78 In den vorstehenden Äußerungen deutet sich an, dass eventuell als eine Art Pendant zur Erkundigungspflicht des Auftragnehmers eine Informationspflicht des Auftraggebers treten sollte – vor allem wenn und soweit dieser nicht nur „mittleren Ausführungsstandard“ wünscht4. Diese Pflicht allerdings wird von der Rechtsprechung bislang kaum gesehen, was mit dem viel bemühten Fachmann/Laie-Gefälle zu tun haben dürfte. 79 Das Pflichtenheft als eine fachliche Vorgabe gehört aber nicht nur zum typischen Pflichtenkreis des Auftraggebers. Es gehört auch genau zu dem Komplex, für den diese Offenbarungspflicht bestehen wird. f) Abgleich des Begriffs des Pflichtenhefts mit EVB-IT/BVB und DIN 80 Der Begriff des Pflichtenhefts ist leider, obwohl er sich eingebürgert hat, für die notwendige Synchronisierung des unterschiedlichen Verständnisses bei Juristen und Sachverständigen eher hinderlich. Die unterschiedlichen, ja gegensätzlichen Äußerungen hinsichtlich der Risikosphäre aus juristischer

1 OLG Stuttgart v. 18.10.1988 – 6 U 64/88, CR 1989, 598; so auch OLG Köln v. 18.6.1993 – 19 U 215/92, CR 1993, 624. 2 OLG Stuttgart v. 18.10.1988 – 6 U 64/88, CR 1989, 598, LS 1. 3 Scrum Guide 2011, http://www.scrum.org/storage/scrumguides/Scrum_Guide% 20-%20DE.pdf. Zu „Redaktion“ s.a. Rz. 74 f. 4 S.a. zum fehlenden Pflichtenheft Rz. 261 ff.

216

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 86

C

Sicht (Auftraggeber hat Pflichtenheft beizubringen) und aus Sachverständigensicht (der Kunde ist dazu gar nicht in der Lage, der Projekt(struktur)plan ist Sache des Auftragnehmers1) resultieren mit hoher Wahrscheinlichkeit aus einem unterschiedlichen Verständnis dessen, was das Pflichtenheft ausmacht2. Dies wird nur abgemildert durch die angedeutete Rechtsprechung, wonach der Auftragnehmer unter näher jeweils zu prüfenden Umständen dem Auftraggeber die Unterstützung seinerseits anzubieten hat3. Der Hauptgrund ist, dass sich dieses Verständnis des Pflichtenhefts aus ju- 81 ristischer Sicht nicht mit dem Verständnis von technischer Seite deckt. Dort ist Pflichtenheft etwa in VDI 2519 definiert. Es handelt sich um „die Beschreibung der Realisierung des Lastenhefts“, in dem definiert wird, „Wie und Womit“ die Anforderungen zu realisieren sind4. Gem. DIN 66901 ist das Pflichtenheft „die ausführliche Beschreibung der Leistungen (…) die erforderlich sind oder gefordert werden, damit die Ziele des Projekts erreicht werden“5. Demnach erscheint „Lastenheft“ i.S.d. DIN/VDI-Vorschriften, also in tech- 82 nischem Sinne, sehr viel näher dem zu sein, was die Juristen unter „Pflichtenheft“ auf Grund der BGH-Rechtsprechung verstehen, als an dem „Pflichtenheft“ in technischem Sinne. „Lastenheft“ ist auch in VDI 2519 definiert:

83

„Im Lastenheft sind alle Anforderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Sie sollten quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, ‚Was und Wofür‘ zu lösen ist. Das Lastenheft wird vom Auftraggeber oder in dessen Auftrag erstellt. Es dient als an Ausschreibungs-, Angebots- oder Vertragsgrundlage.“6

Demnach dürfte das Lastenheft im technischen Sinne weitestgehend der fachlichen Spezifikation und damit der Bedeutung des Pflichtenhefts im juristischen Sinne entsprechen. Das Ergebnis der Planungsphase wäre demnach technisch gesehen das „Lastenheft“, der erste Schritt zu dessen Umsetzung das „Pflichtenheft“, jeweils im technischen Sinne.

84

Die einfache Regel als Zwischenergebnis würde demnach lauten: Wenn in 85 juristischen Zusammenhängen von „Pflichtenheft“ für IT-Leistungen die Rede ist, so ist damit die fachliche Spezifikation gemeint und somit das, was im technischen Bereich als „Lastenheft“ bezeichnet wird. Diese Zuordnung – Lastenheft in technischem Sinne = Pflichtenheft in juristischem Verständnis als fachliche Spezifikation – erlaubt nicht nur eine 1 S. z.B. OLG München v. 22.12.1988 – 1 U 5606/87, CR 1989, 803. 2 S.a. Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4, Anm. 14. 3 S. BGH v. 13.7.1988 – VIII ZR 292/87 – Registrierkassen, CR 1989, 102 und dazu oben Rz. 34. 4 S. Jaeger/Lenzer/Schneider/Wißner, Begutachtung, S. 210. 5 S. Jaeger/Lenzer/Schneider/Wißner, Begutachtung, S. 12. 6 S. Jaeger/Lenzer/Schneider/Wißner, Begutachtung, S. 204.

Schneider

217

86

C Rz. 87

Verträge

klare Abgrenzung gegenüber der technischen Spezifikation, sondern auch eine weitere Differenzierung, nämlich in fachliches Grobkonzept und fachliches Feinkonzept. Um die oben angedeuteten Schwierigkeiten hinsichtlich der „Selbstverständlichkeiten“ bzw. des gewöhnlichen Gebrauchs u.Ä. zu lösen, ist diese Differenzierung besonders geeignet. So unterscheiden die BVB-Erstellung und BVB-Planung – die noch immer Gültigkeit beanspruchen – zwischen dieser Detaillierung, also zwischen einem Grob- und einem Feinkonzept und zwar jeweils über die fachliche und für die technische Ausprägung. Die BVB-Planung gilt demnach (noch) gem. § 1 für a) vorbereitende Maßnahmen für ein Grobkonzept, b) die Erarbeitung des Grobkonzeptes, c) die Erarbeitung des fachlichen Feinkonzeptes. 87 Dies eröffnet folgende Harmonisierung: Beim Grobkonzept muss noch nicht zwischen den Detaillierungsgraden unterschieden werden (auch wenn dies durchaus Sinn macht). Demnach wäre bereits ein fachliches Grobkonzept als Pflichtenheft i.S.d. BGH zu bezeichnen, würde dessen Inhalt/Funktion aber nicht erschöpfen, indem es die Einzelheiten noch offen und somit den endgültigen Detaillierungsgrad vermissen lässt. 88 Dagegen ist das fachliche Feinkonzept der endgültige Abschluss der Planungsphase. Im Wesentlichen bleiben keine Spezifizierungsaufgaben mehr übrig, was die fachliche Seite betrifft. 89 Im Ergebnis verläuft die Trennungslinie zwischen Planung und Realisierung demnach bei strikter phasenweiser Abfolge der Schritte und Stufen (die allerdings in der Praxis nie eingehalten werden) zwischen dem fachlichen Feinkonzept und dem technischen. Dies ergibt sich auch aus dem Phasenschema der BVB. Dieses Phasenschema ist jeweils Bestandteil der BVB-Planung und -Erstellung. Dementsprechend beginnt der Geltungsbereich der BVB-Erstellung mit dem „BVB-technischen Feinkonzept“ auf der „Grundlage eines fachlichen Feinkonzepts“ (§ 1 Ziff. 1 Satz 1 BVB-Erstellung). 90 Eigentlich sollte sich der Auftragnehmer de lege artis bei schrittweiser Abfolge des Projekts nicht an das Werk der Realisierung machen und damit die Trennungslinie von der Planung her überschreiten, bevor ihm nicht ein fachliches Feinkonzept vorliegt, wozu er ggf. gesondert bzw. zusätzlich einen Auftrag erhalten kann. Erhält er diesen Auftrag nicht und liefert der Auftraggeber das Pflichtenheft nicht, liegt eigentlich Behinderung wegen fehlender Mitwirkung vor. Macht der Auftragnehmer diese Behinderung nicht geltend, macht er sich vielmehr an das Werk der Realisierung, liegt Dienstvertrag nahe, da der angestrebte bzw. Erfolg nicht erkennbar und nicht vereinbart ist. Will man dennoch den Vertragstyp Werkvertrag heranziehen (und zudem nicht § 651 BGB und damit Kaufrecht anwenden), ist

218

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 95

C

nur der mittlere Ausführungsstandard, orientiert am Vertragszweck, geschuldet1. Dagegen wäre der Auftragnehmer nicht verpflichtet, im Rahmen der Reali- 91 sierung die Gewinnung des Pflichtenhefts selbst nachzuholen. Hier sind allerdings IT- Sachverständige eher anderer Meinung. Eine Besonderheit des Kaufrechts könnte aber noch greifen, falls dieses 92 (über § 651 BGB) Anwendung findet, wonach im Kaufrecht auch die öffentlichen Äußerungen des Herstellers in die übliche Beschaffenheit Eingang finden2. Solche können auch schon die Standardsoftware und deren Eignung betreffen, die der Unternehmer „beistellt“ und an die Kundenbelange anpassen will. Häufig werden in Produktscheinen, aber auch im Pflichtenheft die nicht- 93 funktionalen Anforderungen nicht aufgeführt3. Aus dem Fehlen solcher Angaben wird man also nicht darauf schließen können, dass diese Kategorien in das Belieben des Auftragnehmers/Lieferanten gestellt seien. g) Transparenzgebot für Leistungsbeschreibungen und Vergütungsregelungen Auf den ersten Blick bereiten die Vergütungsregeln ebenso wenig Probleme wie die Leistungsbeschreibung hinsichtlich ihrer Transparenz, was Software-Überlassung, also Standardsoftware, betrifft.

94

Dieses Bild ändert sich bei näherer Betrachtung. Zum einen gibt es eine 95 Vielzahl von Vertragsgestaltungen, denen spezifische Vergütungsregeln zugrunde liegen (sollen), die AGB-rechtlich durchaus problematisch sind (z.B. Update-, Upgrade-, CPU-, Server-/Client-Klauseln4, Drittsysteme und „technische“ User5). Zum anderen beurteilen sich, je nachdem, wie man § 651 BGB interpretiert6, auch Softwareerstellungs- und Anpassungsverträge (soweit nicht der Kunde die Software stellt) nach Kaufrecht. Im Rahmen von Kaufrecht war es bisher nicht üblich, Leistungsbeschreibungen i.S.e. „Pflichtenhefts“ in den Vertrag einzubeziehen. Tatsächlich sind aber bei Anpassungsprojekten die Standard-Software-Module wesentliche Teile der Leistung7. 1 S. oben Rz. 36 ff. vor allem zu BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543, und BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490. 2 S. oben Kap. B Rz. 74. 3 S. als Beispiel für das (richtige) Vorgehen bei Festlegung des Antwortzeitverhaltens Stiemerling/Schneider, CR 2011, 345. 4 S. z.B. Grützmacher, CR 2011, 485, 697; als Trend den „Abschied von der Softwarelizenz“ Koch, ITRB 2011, 42. 5 Grützmacher, ITRB 2012, 135. 6 S. Kap. B Rz. 92 ff. 7 Zu den Auswirkungen der Lizenzregelungen auf Projekte s. Grützmacher, ITRB 2012, 135.

Schneider

219

C Rz. 96

Verträge

96 Vielmehr findet sich häufig der Verweis in den Verträgen/AGB, dass sich die Gewährleistung (Rechts- und Sachmängel) danach orientiert, welche Maßgaben die Dokumentation, vor allem die Bedienungsanleitung enthält. Abgesehen davon, dass in vielen Fällen die Bedienungsanleitung mehr als unzureichend ist, ist diese Selbst-Referenzierung für eine Leistung, die erst nach Vertragsschluss dem Kunden zugeht, äußerst problematisch. Die Sollbeschaffenheit könnte auch im Rahmen der Dokumentation auf diese Weise herabgesenkt/verändert werden. Dieses einseitige Leistungsbestimmungsrecht wäre unwirksam1. 97 Es wird sich von daher empfehlen, in Zukunft auch bei Standardsoftware stärker zu Leistungsbeschreibungen überzugehen bzw. diese zum Vertragsbestandteil zu machen. Damit wird, wie schon angedeutet, der Versuch zu unternehmen sein, die zweite und dritte Ebene des Mangelbegriffs möglichst „auszuschalten“, es also gar nicht erst zu dem Thema der nach dem Vertrag vorausgesetzten Verwendung oder der gewöhnlichen Verwendung der Eignung hierzu kommen zu lassen. Die Leistungsbeschreibung stellt möglichst abschließend die „vereinbarte Beschaffenheit“ dar. 98 Damit dies erfolgreich ist, muss die Leistungsbeschreibung transparent sein. Schon bisher hatte der BGH (wie auch einige andere Gerichte, so z.B. OLG Frankfurt zu CPU-Klausel (s. Rz. 107) das Transparenzgebot insoweit auf Nicht-AGB erstreckt. Durch die Schuldrechtsmodernisierung ist nun explizit bestimmt, dass auch Leistungsbestimmungen und Vergütungsregelungen unwirksam sein können, wenn sie nicht klar und verständlich sind (§ 307 Abs. 3 Satz 2 i.V.m. § 307 Abs. 1 Satz 2 BGB). 99 Der BGH hatte sich vor der Schuldrechtsmodernisierung in einer bekannten Entscheidung mit zwei Klauseln aus einem Onlinevertrag zu befassen. Die Vorinstanz hatte sich bereits mit dem Transparenzgebot befasst (OLG Köln). Das OLG Köln hatte eine Klausel nicht beanstandet, die lautete: „Aus technischen und betrieblichen Gründen sind zeitweilige Beschränkungen und Unterbrechungen des Zugangs zum … Bank-Online-Service möglich.“2

100

Der BGH erachtete die klauselmäßige Zugangsbeschränkung dieser Klausel Nr. 9 als unwirksam wegen Verstoßes gegen § 11 Nr. 7 AGBG. Dabei spielte auch eine Rolle, dass die fragliche Klausel den Fall groben Verschuldens umfasst3.

101

Die hier entscheidende Aussage des BGH ist, dass die fragliche Klausel nicht lediglich der Beschreibung eines tatsächlichen Zustands dient, sondern den Umfang der vertraglichen Leistungspflicht betrifft und einschränkt. Dem1 Analog einem einseitigen Änderungsrecht hinsichtlich der Leistung, s. dazu BGH v. 23.6.2005 – VII ZR 200/04, DB 2005, 2521; BGH v. 11.10.2007 – III ZR 63/07, CR 2008, 104; BGH v. 15.11.2007 – III ZR 147/08, NJW 2008, 360 (AGB Pay-TV). 2 OLG Köln v. 14.4.2000 – 6 U 135/99, CR 2000, 537. 3 BGH v. 12.12.2000 – XI ZR 138/00, CR 2001, 181.

220

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 106 C

zufolge enthielt die fragliche Klausel keine kontrollfreie Beschreibung der geschuldeten Hauptleistung. „Vielmehr wird die versprochene Hauptleistung, der nach der Feststellung des Berufungsgerichts rund um die Uhr eröffnete Zugang der Kunden zum Onlineservice, zeitweise eingeschränkt.“1

Aussagen wie „Software ist nie fehlerfrei“ oder „Trotz intensiven Testens 102 kann nicht sichergestellt sein, dass die Software nicht fehlerfrei ist“ sind, abgesehen davon, dass es sich um AGB-rechtliche „Bumerangs“ handelt, unter diesem Aspekt zu sehen. Wenn in der Werbung andererseits die Leichtigkeit des Umgangs mit dem Produkt hervorgehoben wird, kann hier sogar ein unmittelbarer Widerspruch entstehen. Eine etwaige Einschränkung des Leistungsumfangs auf diesem Wege wäre also nicht möglich bzw. wäre unter dem Gesichtspunkt der Transparenz zu beurteilen und ggf. unwirksam. Angewandt auf die Planungsleistung: Dort werden ähnliche Formulierun- 103 gen benutzt. Vor allem enthalten die AGB zur Softwareerstellung und -anpassung solche Regeln, die auch den Planungsteil umfassen. Die eigentliche Besonderheit ist aber, dass der Natur des schrittweisen Planungsprozesses bzw. dem Stufenkonzept häufig nicht Rechnung getragen wird, so dass unklar ist, wie der Prozess beginnt und aufgesetzt wird. Dem entsprechend werden die Mitwirkungsleistungen des Kunden in dieser Phase häufig nicht oder nur unzureichend geregelt. Ein weiteres Transparenzproblem kann speziell bei Anpassungsprojekten 104 darin liegen, dass die Aussagen des Planungsprozesses nicht klar ergeben, welche Funktion dem Standard (bereits) eignet, welche durch Einstellung der vorhandenen Parametrisierungsmöglichkeiten gewonnen werden und welche durch zusätzliche Leistungen (Miniprogramme, Ergänzungen, Änderungen am Code, Zusatzprogramme) erst zu gewinnen sind2. Bei Vergütungsklauseln für Standardsoftware wird sich das Problem vor al- 105 lem im Bereich der Regeln stellen, die eine Nachvergütung für den Fall vorsehen, dass der Kunde irgendwelche Handlungen vornimmt, die angeblich von der Einmalvergütung nicht gedeckt sind (wenn es sich nicht um eine Einmalvergütung, sondern etwa um eine periodische Vergütung handelt, wird, wenn dies wirksam wäre, nicht Kaufrecht anzuwenden sein). Klauseln also, wonach nach Verbringung der Software auf eine größere Anlage in jedem Falle eine weitere Vergütung anfallen soll, wären zumindest problematisch. AGB-rechtlich könnte darin zunächst das Recht gesehen werden, die Software auch auf eine größere Anlage zu verbringen (sie naturgemäß dann auf der „alten“ nicht mehr weiter zu verwenden bzw. zu löschen). Ob tatsächlich eine zusätzliche Vergütung anfällt, hängt von der richtigen Formulierung ab. 1 BGH v. 12.12.2000 – XI ZR 138/00, CR 2001, 181. 2 S. für „Gesamtlösung“ OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246, wörtlich zitiert unten Rz. 174.

Schneider

221

106

C Rz. 107

Verträge

107

Die höhere Vergütung soll sich, wie etwa auch im Beispiel des Urteils des OLG Frankfurt1 aus einer Preisliste ergeben. In vielen Fällen ist diese Preisliste nicht beigefügt bzw. operiert, selbst wenn sie beigefügt und eindeutig identifiziert ist, mit Begriffen und technischen Aussagen, die nicht unbedingt mit dem Vertragsgegenstand kompatibel sind. So wird eventuell das Nutzungsrecht auf einen bestimmten Typ einer Maschine gewährt, während die Preisliste eine Differenzierung hinsichtlich der Zentraleinheit u.Ä. vornimmt, dazu Bezeichnungen verwendet, die herstellertypisch, für den Kunden aber nicht verständlich sind.

108

Die Transparenz kann jetzt insoweit fehlen, als für den Kunden gar nicht klar ist, wann er welche Vergütung zu zahlen hat. Die Intransparenz kann aber auch insoweit bestehen, dass nicht klar ist, welches Dokument referenziert wird. Dies gilt insbesondere dann, wenn die Preisliste nicht datumsmäßig festgelegt ist. Wenn noch dazu dann in den AGB steht, dass die Preisliste gilt, die jeweils zum Zeitpunkt des Upgrade gültig ist, wird die Sache besonders problematisch, weil insoweit dann eine Preisgleitklausel, ohne dass dies ausgewiesen wäre, entsteht.

109

Die Transparenz bzw. deren Fehlen kann sich aber vor allem auch darauf erstrecken, dass für den Kunden gar nicht klar ist, wofür er die Mehrvergütung zahlt. Dies hat z.B. das OLG Frankfurt für den Fall der Partitionierung entschieden, wo der Kunde trotz Verbringung auf eine größere Anlage die Software praktisch im gleichen Umfang genutzt hat wie bisher, so dass die Klausel unwirksam war, weil sie diesen Fall nicht berücksichtigt hat. Ansonsten wäre die Upgradeklausel wohl nach Ansicht des Gerichts als wirksam angesehen worden2.

110

Die Relevanz des Transparenzgebots liegt in der Kombination der praktischen Notwendigkeit einer Vereinbarung und Ausformulierung der vereinbarten Beschaffenheit mit dem Bemühen – zumindest aus Auftragnehmersicht – möglichst die anderen Mängelkategorien zu verdrängen3 und es nicht auf die Beantwortung der Frage, was mittlerer Ausführungsstandard jeweils sei, von dritter Seite (Sachverständiger) ankommen zu lassen. Also sollten beide Parteien ihre Interessen wahren und für die Leistungsbeschreibung den erforderlichen Aufwand erbringen. Die Auftraggeber, die unbedingt Werkvertrag haben wollen, erreichen das relativ sicher über die Vergabe des Auftrags zur Erstellung des Pflichtenhefts.

111

Die separate Vergabe der Erstellung des Pflichtenhefts ist, etwa auch als „BVB-Planung“ für den öffentlichen Sektor, seit langem empfohlen. Praktisch erfolgt jedoch die Beauftragung sehr häufig im Verbund von Planung und Realisierung. Dies hängt auch damit zusammen, dass die Software 1 OLG Frankfurt v. 10.3.1994 – 6 U 18/93, CR 1994, 398. 2 OLG Frankfurt v. 14.12.1999 – 11 U 7/99, CR 2000, 146; a.M. allerdings: BGH v. 24.10.2002 – I ZR 3/00, CR 2003, 323. 3 S. Kap. I Rz. 473 ff.

222

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 115 C

nicht von Grund auf neu hergestellt werden soll, sondern aus Modulen, mit Hilfe von Bausteinen und Generatoren sowie durch Anpassung des Code und Parametrierung. Die neutrale Vergabe der Erstellung des Pflichtenhefts, losgelöst von der Zielsoftware, erscheint kaum sinnvoll, weil das Verfahren sehr aufwändig und das Ergebnis dann doch nicht passend ist. Schwierigkeiten bereitet vor allem, den möglichen und den erforderlichen 112 Grad der Anpassung des Kunden vorher zu bestimmen, bevor eine konkrete Software als Referenz bzw. „Projektionsfläche“ ausgewählt ist. Andererseits ist auch die Anpassung der Organisation des Kunden Gegenstand des Planungsprozesses1. 3. Besonderheiten bei modernen Vorgehensmodellen, v.a. agiler Methodik a) Methode gegen das Scheitern von Projekten Oben (Rz. 6 ff.) wurden typische Gründe für das Scheitern von IT-Projekten 113 angeführt. Agil zielt nicht unmittelbar auf diese. Im Gegenteil: die Grundprinzipien scheinen eher den als typisch angesehenen Fehlern zu entsprechen: etwa keine vorgeschaltete, gesonderte Planungsphase mit Erstellung der Spezifikation, keine klare Verantwortungstrennung, keine klare Übergabe der Projektverantwortung. Die Planung und die Spezifikation werden in den Prozess der Realisierung integriert und Teil der Realisierungsleistung2. Agile Methodik erscheint gegenüber den typischen Empfehlungen (oben 114 Rz. 11) besonders problematisch hinsichtlich Ziffern 1., 5., 6., 9. Eventuell trügt aber der Eindruck, wenn man den Wechsel von dem Institut des statischen Pflichtenhefts zum Vorgehensmodell der dynamischen, iterativen prozess-orientierten Methodik als Äquivalent akzeptiert. Schon bisher erschien das Pflichtenheft als ergänzungsbedürftig insofern, als es ein prozedurales Pendant im (aus dem Pflichtenheft abgeleiteten) Aktivitäten- und Fristenplan haben soll3. Die neuen Projektmethoden verzichten weitgehend oder gänzlich auf Pflich- 115 tenhefte und ersetzen diese durch „gemeinsame Erarbeitung des Leistungskatalogs“, teils auch direkt am System selbst. Dies scheint die vorgenannten Projektsünden noch weiter zu verstärken. Der Liste (Rz. 7) kann man als 10. Problemvariante hinzufügen, dass die Vertragspartner zwar einen „guten Vertrag“ geschlossen haben, diesen aber in der Praxis nicht umsetzen bzw. anders leben4. Ebenso kommt es vor, dass sich zwar die Projektleiter beider Seiten über das „faktische Doing“, z.B. „agil“, einig sind, die vertragsschließenden Geschäftsführer/Vorstände hingegen mit dem geschlossenen Ver1 S. unten Rz. 223 ff.; s.a. Schneider, CR 2005, 695 (697 f.). 2 S.a. Kap. H Rz. 43 ff.; Kap. M Rz. 56 ff. zu Vorgehensmodellen; Redeker, ITRecht, 5. Aufl., Rz. 311c. 3 S.a. Rz. 328 ff. 4 S. z.B. Stiemerling, ITRB 2010, 289.

Schneider

223

C Rz. 116

Verträge

trag anderes (insbesondere, was die Verantwortlichkeit anbelangt), etwa „Wasserfall“, intendiert haben. Es muss geklärt werden, – ob insoweit nicht die einvernehmliche Durchführung das fehlende Pflichtenheft ersetzt, also ein „mittlerer Ausführungsstandard …“1 gilt; – selbst bei alleiniger Kalkulation der formell vereinbarten Ausführungsart durch den Auftragnehmer das Ausführungsrisiko sich durch die Art der faktischen Durchführung zumindest hinsichtlich der Kalkulation auf beide Parteien verlagert. 116

Auch hier ist Streit vorprogrammiert, falls es – wie meist – zu Problemen im Projektverlauf kommt. Eine stringente Abnahme als Vergleich SOLL/ IST erscheint kaum möglich. b) Anwendungsvoraussetzungen

117

118

Eventuell lässt sich jeweils die Typik der modernen Methodik, die sich in den Detailplanungen der Sprints „atomisiert“ findet, als Geschäftsgrundlage sehen. Die verschiedenen agilen Projektmethoden haben unterschiedliche Zielsetzungen, aber auch unterschiedliche Anwendungsvoraussetzungen. Für agile Projekte könnten gemeinsame Voraussetzungen sein: – das Projekt soll schnell Ergebnisse liefern, – die aber nicht (genau) feststehen2; – der Auftraggeber ist in der Lage, intensiv mitzuarbeiten (z.B. auch beim programming in pairs, bei der Dokumentation)3; – das Projekt ist noch überschaubar, sowohl was die Anzahl der Mitarbeiter als auch die Laufzeit betrifft; – Projektabschnitte lassen sich durch fachliche/funktionelle Differenzierungen schaffen, so dass „SOW“s (scope of work) abgrenzbare, aufeinander aufbauende Abschnitte regeln können. – Weiter wird hinzukommen, dass der Auftraggeber (vom Management über die Ansprechpartner bis zu den Mitgliedern des Projektteams) Vertrauen in das Vorgehen und den Anbieter hat, die notwendige Zeit für in1 Zu BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 m.w.N. s. Rz. 142 ff., 261 ff. 2 S. Stiemerling, ITRB 2010, 289 f.: „Anforderungsunsicherheit“. 3 http://en.wikipedia.org/wiki/Pair_programming: „Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, types in code while the other, the observer (or navigator[…]), reviews each line of code as it is typed in. The two programmers switch roles frequently. While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the „tactical“ aspects of completing the current task, using the observer as a safety net and guide.“. Zu agiler Methodik s.a. Kap. H Rz. 61 ff.; Kap. Q Rz. 131 ff. und sogleich Rz. 124 ff.

224

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 121 C

tensive Mitarbeit vor Ort im Projekt vorhanden ist und entsprechende Entscheidungskompetenzen bei den Projektmitgliedern bestehen1. Zu den Contra-Indikatoren, wann die agilen Methoden besser nicht einzusetzen sind, gehören2: – Zwingend dokumentierte Erfüllung bestimmter IT-Prozessabläufe und Vorgaben für die Qualität und insbesondere für die IT-Sicherheit (oder gar lebenskritische Funktionen etwa in der Medizin oder Flugüberwachung). – Budgetmäßig, terminlich, qualitätsbezogen und vom Umfang her klar fixierte Projekte. – Langwierige Change Request-Verfahren und lange oder formalisierte Entscheidungswege beim Kunden. – Kein oder nur unregelmäßiger Kontakt zum Kunden oder Kunden, die an Lastenhefterstellung gewöhnt sind. – Keine Möglichkeit der Arbeit vor Ort beim Kunden. – Lange Entwicklungs(-Build)-Zeiten.

Besonders augenfällig sind die Unterschiede im Vergleich Wasserfall-Modell 119 mit den zwei Hauptphasen – Planung und Realisierung – einerseits und agiler Methodik andererseits: Die Phase „Planung“ entfällt insgesamt3. Statt einer eigenen, vorgeschalteten Phase wird Planung zu einer in das Vorgehen bei der Realisierung integrierten, einzelnen Schritten zugeordnete Funktion. Besonders gut zeigt sich diese Integration bei Scrum, s. Rz. 131 ff. c) Prototyping4 Die typischen moderneren Projektmethoden, charakterisiert etwa als Agile 120 Programming oder Extreme Programming haben als eine Art Vorläufer das Prototyping5. Methodisch6 würde man Prototyping wohl nicht als eigene Projektmethode ansehen, sondern eher als einen möglichen Baustein für die verschiedenen existierenden Projektmethoden (nicht für alle, aber für einige). Arten von Softwareprototypen:

121

– Demonstrationsprototyp – Prototyp im engeren Sinne 1 Aufwand bzw. Dauer des Projekts lassen sich naturgemäß – was als Nachteil berücksichtigt werden muss – bei Vorliegen der vorgenannten Voraussetzungen kaum einschätzen, geschweige denn exakt bestimmen, s.a. Stiemerling, ITRB 2010, 189 (290), unter Hinweis auf Sommerville, Software Engineering, 8. Aufl., S. 391 ff. 2 So aufgezählt in Koch, ITRB 2010, 114 (119) unter Verweis auf bzw. mit Nachweisen aus Bleek/Wolf, Agile Softwareentwicklung, 2008, S. 160 ff. 3 Zur Abgrenzung von Planung und Realisierung s. Frank, CR 2011, 138 (141). 4 S. zu Prototyping Kap. H Rz. 56 ff. z.B. Söbbing, ITRB 2008, 212; zu den Arten von Prototypen bei Software und überhaupt zu Arten des Prototyping: MüllerHengstenberg/Kirn, Welche Bedeutung haben Prototyp und Pilot sowie Prototyping und Pilotierungsphase bei IT-Projekten?, CR 2010, 8. 5 S. z.B. Söbbing, ITRB 2008, 145; Müller-Hengstenberg/Kirn, CR 2010, 8. 6 Hinweis Frank Sarre, IT-Sachverständiger, projective expert group, München.

Schneider

225

C Rz. 122

Verträge

– Prototyp als Entwurfsmuster – Horizontaler Prototyp – Vertikaler Prototyp 122

Arten des Prototyping: – – – – – –

123

Exploratives Prototyping Evolutionäres Prototyping Experimentelles Prototyping Rapid Control Prototyping Vertikales Prototyping Horizontales Prototyping

Das Prototyping ist insofern für die hier zu behandelnden Fragen von Interesse, als die Folgen der neuen Projektmethoden bezüglich Dokumentation, spiralförmigen Vorgehens u.Ä. vergleichbar sind, während sich die Voraussetzungen durchaus unterscheiden, indem nämlich beim Prototyp etwas im Kern Funktionsfähiges vorliegt, zumindest vorliegen sollte. d) AGIL aa) Manifest

124

Als eine Art neue Geschäftsgrundlage – weg von Vertrag und Beschreibungen/Festlegungen, hin zu hautnaher Produktgenerierung als Prozess – könnte man das Agile Manifest sehen: „We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation 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.“1

bb) Prinzipien, Prioritäten 125

„We follow these principles: 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. 1 http://agilemanifesto.org/; Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungen hinzugefügt. S.a. Auer-Reinsdorff, ITRB 2010, 93; Koch, ITRB 2010, 114; s.a. Kap. H Rz. 61; Kap. Q Rz. 132.

226

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 127 C

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. 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.“1

cc) Grundlagen Agiles Vorgehen wird wie folgt beschreiben2:

126

„Im Kern geht es bei agiler Softwareentwicklung um möglichst häufige Rückkopplungsprozesse und zyklisches (iteratives) Vorgehen auf allen Ebenen: bei der Programmierung, im Team und beim Management. Anders als in der klassischen Vorgehensweise wird das neue System nicht im Voraus in allen Einzelheiten genau geplant und dann in einem einzigen langen Durchgang entwickelt, denn schließlich können sich die Anforderungen während der Projektlaufzeit noch ändern, und oft sind sie zu Projektbeginn noch gar nicht vollständig bekannt. Stattdessen wechseln sich beim agilen Vorgehen kurze Planungs- und Entwicklungsphasen ab. Nachdem eine Vision für das neue System entwickelt wurde, also die Ziele festgelegt und gewichtet wurden, die mit der Software erreicht werden sollen, wird ein Plan für eine erste Version ausgearbeitet, und die Entwicklung beginnt. Danach werden notwendige Anpassungen vorgenommen.“

Das impliziert eine intensive und konstruktive Zusammenarbeit der Ver- 127 tragspartner3, für die die Kategorie „Mitwirkung“ auf Seiten des Auftraggebers eher zu schwach erscheint4. Dies gilt umso mehr, als die Feststellung dessen, was als geschuldete Leistung und vor allem als vereinbartes Ergebnis gelten soll, sehr schwierig wird5, wenn man nicht auf die Vorgehensweise als solche abstellt. 1 http://agilemanifesto.org/principles.html; Typo und Absatz-Anordnung geändert, Nr. und Hervorhebungen hinzugefügt. 2 S. unter www.it-agile.de. Zu den „Ereignissen“ als Themen der Redaktion s. Rz. 75. 3 S. Lapp, ITRB 2010, 69 (Interaktion und Kooperation). 4 S.a. unten Rz. 162. 5 Zum Problem und konkreten Vorschlägen zur Lösung s. Auer-Reinsdorff, ITRB 2011, 93.

Schneider

227

C Rz. 128

Verträge

dd) Extreme Programming 128

Extreme Programming ist die wohl bekannteste und meist verbreitete agile Methodik1. Wikipedia führt hierzu folgendes aus2: „Extreme Programming (XP), auch Extremprogrammierung, ist eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung stellt und dabei einem formalisierten Vorgehen geringere Bedeutung zumisst. Diese Vorgehensweise definiert ein Vorgehensmodell der Softwaretechnik, das sich den Anforderungen des Kunden in kleinen Schritten annähert. Die Wirksamkeit des Ansatzes ist umstritten.“3

129

Zu den Grundlagen: „XP ist ein durch fortlaufende Iterationen und den Einsatz mehrerer Einzelmethoden strukturierendes Vorgehensmodell. XP entstand durch die Synthese … bewährten Methoden, auch Best Practices genannt. XP folgt einem strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stete Kommunikation zwischen allen Beteiligten in den Vordergrund. Kommunikation ist dabei eine Grundsäule. Die Methode geht davon aus, dass der Kunde die Anforderungen an die zu erstellende Software zu Projektbeginn noch nicht komplett kennt und nicht hinreichend strukturieren kann beziehungsweise das mit der Realisierung betraute Entwicklerteam nicht über alle Informationen verfügt, um eine verlässliche Aufwandsschätzung über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich nicht selten Prioritäten und Gewichte. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder im Laufe der Zeit sogar komplett hinfällig. Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt werden, sowie eine höhere Softwarequalität und Zufriedenheit des Kunden als mit traditionellen Ansätzen zu erreichen sein. Der Kunde soll ein einsatzbereites Produkt erhalten, an dessen Herstellung er aktiv teilgenommen hat. Neue Funktionalität wird permanent entwickelt, integriert und getestet. Um zu der zu entwickelnden Funktionalität zu gelangen, werden jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (Prototyping) und ein Akzeptanztest durchgeführt.“4

130

Im Gegensatz zu Scrum sind die Rollen nicht so strikt verteilt und geregelt. Gleichwohl handelt es sich um eine strikt geregelte Methodik des Vorgehens. Es erfolgt eine explizite Planung und zwar je „release“. Die Anforderungen seitens des Kunden werden als „user stories“ geäußert, die (wesentlich) knapper und einfacher gehalten sind, als „case stories“. Insofern ist auch hier eine Redaktion zur Umsetzung erforderlich, die aber in meist nicht so stark betont wird, wie etwa die Priorisierung und die Abschätzung 1 Sommerville, Software Engineering, S. 64; s.a. Kap. H Rz. 64 ff.; Kap. Q Rz. 131 ff. 2 http://de.wikipedia.org/wiki/Extreme_Programming, S. 1; s.a. dort zur Geschichte, S. 2. 3 http://de.wikipedia.org/wiki/Extreme_Programming, S. 1. 4 http://de.wikipedia.org/wiki/Extreme_Programming, S. 2.

228

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 133 C

des Realisierungsaufwands sog. „story points“1. Jedenfalls besteht bei dieser Methodik ein wesentlicher Teil der – gemeinsamen und tendenziell spiralförmigen – Vorgehensweise in deren jeweiliger Planung. Planung und Realisierung werden wesentlich enger verknüpft, als beim Wasserfall- bzw. Stufenmodell. ee) Scrum Scrum ist eine besondere Ausprägung agiler Methodik, die immer häufiger Einsatz findet. Sie ist stark auf Rollen und deren Aufgaben konzentriert2.

131

Scrum (engl. für Gedränge) ist ein Vorgehensmodell mit – – – – –

Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, die beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich sind. Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden3.

Oder4:

132

„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.“

Bei Scrum-Vorgehensmodellen sind folgende Begrifflichkeiten von wesentlicher Bedeutung: – Rollen: Bei Scrum gibt es drei klar getrennte Rollen, die von Mitarbeitern ausgefüllt werden können, die im selben Projekt zusammen arbeiten. – Product Owner – Team – Scrum Master

1 S. http://de.wikipedia.org/wiki/Extreme_Programming, S. 8. 2 Zu den Inhalten s.a. Computerwoche Ausgabe 12/2011 mit mehreren Beiträgen hierzu; Beardwood/Shoer, CRi 2010, 164; Frank, CR 2011, 138; zum Scrum Guide, etwa deutsch Oktober 2011, s. www.scrum.org; Kap. H Rz. 67; Kap. Q Rz. 134. 3 http://de.wikipedia.org/wiki/Scrum; s.a. http://scrum-master.de/. 4 http://www.scrumalliance.org/; s.a. Auer-Reinsdorff, ITRB 2010, 93.

Schneider

229

133

C Rz. 134

Verträge

Hierbei ist wiederum zu beachten: – Zusammenspiel – Zertifizierung und – wer hat durch Einnahme welcher Rolle welche Verantwortung i.S.d. Erfolgsverantwortung? – Artefakte: – Product Backlog1 – 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 134

Das Vorgehensmodell2 besagt hinsichtlich der Entwicklungsmethodik, dass es auf dem Agilen Manifest aufbaut, also den oben (s. Rz. 124) zitierten vier Grundkategorien des Manifestes.

135

Es wird eine Projektstruktur eingeführt, bei der lose und ggf. unkoordinierte Anforderungen des Auftraggebers zu relativ überschaubaren Teilschritten und deren Realisierungen zusammengefasst werden. Der Prozess ist – anders als beim klassischen V-/Wasserfall-Modell – nicht linear, sondern iterativ, tendenziell spiralförmig. Die Konsequenz davon ist, dass an die Stelle der inhaltlichen Ausgestaltung eines Pflichtenhefts (= technisch-funktionelle Vorgabe) die Einrichtung von bestimmten Gremien/Prozessen und Aufgaben auf einer Ebenen (= nicht-hierarchische organisatorische Vorgaben) treten und zu vereinbaren sind, insbesondere – Steuerungsausschuss – Projektleiter – Zuteilung von Rollen und Aufgaben auf die einzelnen Personen und auf Auftraggeber- und Auftragnehmerseite und schließlich – die Organisation.

1 Hengstler, ITRB 2012, 113: „Übersicht aller Elemente des zu entwickelnden Produkts.“ 2 Diese Darstellung folgt im Wesentlichen der bei Wikipedia.de wiedergegebenen Beschreibung, http://de.wikipedia.org/wiki/scrum.

230

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 140 C

Hinzu kommt die klare Zuweisung der Rollen, nämlich der

136

– Product Owner, der das Ziel definiert, das ein Team erreichen muss, und auch das Budget „zur Verfügung stellt“. – Das Team selbst, das die Aufwände für die einzelnen Backlog-Elemente abschätzt. – Der Scrum Master, der die Aufgabe hat, Prozesse der Entwicklung und Planung durchzuführen und die Aufteilung der Rollen und Rechte zu implementieren und zu überwachen. Er behält sozusagen die Transparenz über das gesamte Vorgehen. Er ist aber nicht dafür verantwortlich, dass Team und Product Owner miteinander kommunizieren. Dies geschieht vielmehr direkt (was dann auch eine der größeren Gefahren ist). Die wesentliche Grundlage bilden die so genannten Artefakte, darunter das erwähnte Product Sprint Backlog. Es werden die Funktionalitäten bzw. Anforderungen für das zu entwickelnde Programm mit den Funktionalitäten, die der Kunde wünscht, über eine Art „tickets“ geäußert und gesammelt, wobei die Kunden-Mitarbeiter aber nicht verpflichtet sind, eine Systematik einzuhalten oder einzubauen. Im Gegenteil äußern sie sich in „Wunschlisten“. Wichtig ist deshalb eine kräftige redaktionelle Selektion und Bearbeitung (je Sprint). Dies gilt auch aus folgendem Grund:

137

Die Detail-Genauigkeit der Anforderungen kann sehr unterschiedlich sein.

138

– Der Sprint Backlog enthält die Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen1. Man geht davon aus, dass der Sprint Backlog nicht länger als eine bestimmte Zeit dauern soll, ansonsten eine Zerlegung erfolgen müsste. Die häufig (auch in Wikipedia) angegebene Zahl von 16 Stunden als Maximum resultiert daraus, dass zwei Tage daran gearbeitet wird. Die acht Stunden sind zuzüglich eines Puffers von einer Stunde zu verstehen. – Der Burn down Chart ist eine grafische, pro Tag zu erfassende Darstellung des noch zu erbringenden Restaufwands. Das wesentliche Element des gesamten Vorgehens ist dann der Sprint, der in einem Entwicklungszyklus durchlaufen wird. Dieser Sprint hat ebenfalls eine begrenzte Zeit, die mit maximal 30 Tagen angenommen wird. Hierfür wird aus dem Product Backlog die Aufgabe für den jeweiligen Sprint gesammelt. Es wird dann für den Sprint ein spezielles Backlog zusammengestellt. Dann erfolgt der Sprint und realisiert sozusagen diese für ihn speziell zusammengestellten Anforderungen, die dann anschließend in ein funktionsfähiges Produkt mit eingebaut werden.

139

Der Ausdruck Scrum erklärt sich vor allem daraus, dass an jedem Tag eine 140 vom Scrum Master moderierte Teamsitzung stattfinden soll, bei dem bestimmte Fragen, die der Arbeit im Wege stehen könnten, diese fördern u.Ä.,

1 Hengstler, ITRB 2012, 113.

Schneider

231

C Rz. 141

Verträge

besprochen werden sollen, um so möglichst allen Hindernissen frühzeitig aus dem Wege zu gehen. 141

Working Increment: „Das Inkrement ist die Summe aller im Sprint und aller vorherigen Sprints fertig gestellten Product Backlog Einträge. Am Ende eines Sprints muss das neue Inkrement „done“ sein, was bedeutet, dass es in einsatzfähigem Zustand sein und der „Definition of Done“ des Scrum Teams entsprechen muss. Es muss in einsatzfähigem Zustand sein, unabhängig davon ob der Product Owner entscheidet, es tatsächlich auszuliefern oder nicht.“1

Um dieses Inkrement ggf. abnehmen zu können, wäre eine Abgleich mit dem für die Sprints erstellten Backlogs möglich. Diese bilden aber aber keine statische Referenz wie ein Pflichtenheft. e) Blick auf das Pflichtenheft und den „mittleren Ausführungsstandard“ 142

Den vorgeschilderten Methoden ist gemeinsam, dass einerseits die Mitwirkung des Kunden wesentlich intensiver gefordert ist, andererseits das Pflichtenheft entfällt – jedenfalls dessen Erstellung als eigene vorgeschaltete Stufe. Während das Thema Mitwirkung sich nur graduell, nicht grundsätzlich verändert2, besteht im Streitfall, etwa bei Abnahme, das Problem der Referenz, gegen die geprüft wird. Bei fehlendem Pflichtenheft wäre mangels anderer Festlegungen ein „mittlerer Ausführungsstandard“ orientiert am Stand der Technik und dem Vertragszweck geschuldet3.

143

Tatsächlich finden sich bei den diversen Methoden funktionale Gegenstücke, etwa in Form der User stories, der Tickets und der daraus entwickelten Backlogs bzw. Sprint logs u.Ä. Die Frage ist, ob sie vertragsrechtlich gleichen Rang wie das Pflichtenheft haben (können).

144

Andererseits deckt ein Pflichtenheft die Anforderungen meist nicht komplett ab4, weshalb folgende Differenzierung5 vor allem bei klassischer Vorgehensweise mit Pflichtenheft wichtig ist, obwohl das Pflichtenheft aus

1 Scrum-Guide 2011, S. 16. 2 „Kann der Softwarehersteller die Verpflichtung zur Programmierung nur sinnvoll unter Mitwirkung des Kunden erfüllen, so besteht aus in der Natur der Sache liegenden Gründen, auch ohne ausdrückliche Regelung, eine entsprechende Mitwirkungspflicht.“ BGH v. 13.7.1988 – VIII ZR 292/87 – Registrierkassen, CR 1989, 102 (104), LS 2, und Bestätigung durch BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft, CR 1998, 393 (395). 3 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 unter Verweis auf BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543. 4 Zu Funktionsmangel s. Rz. 20, 148, 152, 240; BGH v. 8.11.2007 – VII ZR 183/05 – Heizungsanlage, NJW 2008, 511, und BGH v. 29.9.2011 – VII ZR 87/11 – Elektrodüker; zu Selbstverständlichkeiten Rz. 67, 86, 144, 228, 259. 5 Die Unterscheidung ist wohl allgemein üblich. Die Umschreibung ist angelehnt an Sommerville, Software Engineering, Chapter 4.1, S. 84 f.

232

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 145 C

juristischer Sicht gerade alle die Anforderungen aus Anwendersicht einschließlich aller Randbedingungen beschreiben soll: aa) Konkrete fachliche Anforderungen/funktionale Anforderungen: Funktionale Anforderungen betreffen „Statements of Services“, die das System realisieren soll, wie das System auf bestimmte Eingaben reagieren soll und wie das System sich in bestimmten Situationen im Einzelnen verhalten soll. In bestimmten Fällen bzw. unter besonderen Voraussetzungen kann es sich auch um Forderungen handeln, die besagen, was das System in bestimmten Fällen nicht tun soll. Es wird mehr oder weniger aus Anwendersicht beschrieben, was das System/die Software leisten soll. Dabei kann es sich um Funktionen des Systems handeln, aber auch um Aufgaben, die das System zu bewältigen/zu lösen hat. bb) Nicht-funktionale Anforderungen1 Bei nicht funktionalen Anforderungen geht es vor allem um das Reaktions- und Zeitverhalten, um Verfügbarkeiten, auch Einflüsse von Standards, auch salopp „Selbstverständlichkeiten“. Eventuell sind auch bestimmte typische Arten des Gesamtverhaltens des Systems gemeint, über die mit relativ allgemeinen Begriffen gesprochen wird, die aber unter Umständen auch einen messbaren Kerngehalt haben (nicht zuletzt über Standards), möglicherweise etwa Hochverfügbarkeit im Zusammenhang mit bestimmten Anwendungen aus dem Bereich von Fertigung, Militär oder Flug-Industrie. Erstaunlich ist der Katalog nicht-funktionaler Anforderungen, wenn man 145 sie etwa nur ganz grob zusammenfasst2 wie etwa – Qualitätsanforderungen (Inhalt, Korrektheit, Verlässlichkeit, Benutzerfreundlichkeit, Genauigkeit, Sicherheit, Robustheit) und – Leistungsanforderungen, also Performance bzw. Antwortzeiten und Durchsatz – Fehlverhalten und die Reaktion des Systems hierauf, Handling, wie also das System im Ausnahmefall reagiert bzw. hilft durch Dialoge, Logdateien, Protokolle, Recovery u.Ä. – Dokumentationen für die verschiedenen Bereiche bzw. Adressaten wie – Anwender – Betrieb/Rechenzentrum – Wartung/Pflege – Fachbereichsleitung3. 1 Stiemerling, Das IT-Projekt im Konflikt mit dem vertraglich definierten Regelwerk, ITRB 2010, 289; s. v.a. Sommerville, Software Engineering, 9. Aufl., S. 85, 87–91. 2 In Anlehnung an Brugger, IT-Projekte strukturiert realisieren, 1. Aufl. 2003, S. 110, 112. 3 S.a. zu Dokumentationen Rz. 269 ff; Kap. D Rz. 119 ff.; Kap. H Rz. 95 ff. (projektbegleitend) und Kap. I Rz. 424 ff.

Schneider

233

C Rz. 146 146

Verträge

Interessanter wird dieser hohe Anteil von nicht-funktionalen Anforderungen noch, wenn man diese aufteilt1 und zwar nach – Nicht-funktionale Anforderungen aus Benutzersicht – Fehlerfreiheit, Korrektheit, – Effizienz/Performance – Zuverlässigkeit – Bedienerfreundlichkeit – Sicherheit – Benutzerdokumentation – Nicht-funktionale Anforderungen aus Anwendersicht – Entwicklerdokumentation – Erweiterbarkeit – Änderbarkeit – Verständlichkeit – Testbarkeit – Wartbarkeit – Portierbarkeit – Wiederverwendbarkeit.

147

Im Zusammenhang mit der Qualität relativ grober Begriffe und deren Ausfüllbedarf war schon das Problem angedeutet worden, dass Nutzer-Anforderungen unter Umständen wesentlich zu pauschal sind. Hinzu kommt also, dass oft ein ganzer Komplex von Anforderungen fehlt, etwa weil er von den Usern als selbstverständlich empfunden wurde. Die Unterscheidung funktional/nicht-funktional hat sich auch aus der Rechtsprechung im Zusammenhang mit der Frage der Vollständigkeit bzw. dem abschließenden Charakter von Pflichtenheften2 etabliert, die auch auf agile Programmierung angewandt wird.

148

Es könnte sich das Problem des Funktionsmangels erledigen: Aus dem „Funktionsmangel“ ergeben sich spezielle Risiken auch bei vorhandenem Pflichtenheft und verbindlichen Anweisungen des Auftraggebers; es kann sich dennoch die Mangelhaftigkeit einer Software/eines Systems ergeben, wenn der Auftragnehmer den Auftraggeber nicht darauf hingewiesen hat, dass die Funktionalitäten bei Befolgung der Anweisungen nicht erreicht werden können. Wird die Hinweispflicht, dass die vereinbarte Funktionalität bei Befolgung der Anweisungen des Bestellers nicht erreicht wird, nicht erfüllt, liegt trotz etwa beigestelltem Leistungsverzeichnis ein Mangel vor3. 1 Brugger, IT-Projekte strukturiert realisieren, 1. Aufl. 2003, S. 113. 2 S. zum Funktionsmangel BGH v. 8.11.2007 – VII ZR 183/05– Heizungsanlage, NJW 2008, 511, und sogleich BGH v. 29.9.2011 – VII ZR 87/11, NJW 2011, 3780 – Elektrodüker –. 3 BGH v. 29.9.2011 – VII ZR 87/11. S. Stephan Lorenz: „… Ein Werk ist mangelhaft, wenn es die vereinbarte Funktion nicht erfüllt. Das gilt auch dann, wenn

234

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 153 C

Bei agilem Vorgehen fehlt in der Regel „bewusst“ ein Pflichtenheft. Dessen Nicht-Beibringung sollte dann vorsorglich explizit geregelt sein, damit möglichst auch die Hinweispflicht zur Vermeidung des Funktionsmangels obsolet wird. Bei neuen Methoden wie agile gilt: Der Auftraggeber sollte über das Kon- 149 zept und seine herausragende Rolle hinsichtlich seiner Mitwirkung gut aufgeklärt sein, etwa bei Iterations-, Aktivitäten- und Fristenplan, Meetings, Workshops, Teams, Freigabe u.Ä. Thesenartig wäre zu fordern, dass eine Art Fortschreibung erfolgt, wonach sich der Ausführungsstandard stärker am „vereinbarten Vertragszweck“ nach dem Stand der Technik ergibt. Der Vertragszweck muss also beschrieben werden, völlig unabhängig von der verwendeten Projektmethodik und egal was die Methodik sagt. Zu dieser Beschreibung gehören auch die Beziehungen zu der Infrastruktur, in der das System laufen soll (dies ist vor allem wichtig wegen des „Funktionsmangels“, siehe hierzu Rz. 66).

150

Aber der „mittlere Ausführungsstandard“ bedarf der Ergänzung, da der 151 Mangelbegriff (vgl. § 434 Abs. 1, § 633 Abs. 2 Satz 2 BGB) hinsichtlich der Sollbeschaffenheit v.a. auf die vereinbarte Beschaffenheit abstellt. Bedeutsam wird insoweit der Zusatz in Kauf- und Werkvertragsrecht „und die der Käufer/Besteller nach der Art der Sache/des Werkes erwarten kann“. Diese stärkere Subjektivierung gebietet, nicht auf den mittleren Ausführungsstandard abzustellen. Der Mangelbegriff birgt diese Subjektivierung durch die Formulierungen zur „Erwartbarkeit“. Da die vereinbarte Beschaffenheit – entgegen dem Wortlaut – nicht die übrigen Mangelhierarchien verdrängt1, haftet der Unternehmer bei Funktionsmängeln nicht etwa wegen Verletzung vorvertraglicher Aufklärungs- und Beratungspflichten, sondern aus Mangelrecht. Es setzt sich die vierte Kategorie der Mangelebenen durch und insofern der „mittlere Ausführungsstandard“.

152

Allerdings setzt dieser Befund die Anwendung von Werkvertragsrecht vo- 153 raus. Welche genaue Ausprägung der agilen Methoden welche Wirkung auf den Vertragstyp hat, ist noch wenig untersucht: Dass etwa bei Scrum und Extreme Programming zu Projektbeginn der Erfolg noch nicht genau beschrieben ist, lässt Dienstvertrag als durchaus möglich erscheinen. Allerdings wurden schon bisher auch die Erstellungs- und Anpassungsverträge, die im Vertrag vereinbarten Leistungen erbracht wurden: Maßgebend ist alleine, ob das Ziel, d.h. die Funktionalität des Werks erreicht wird. Der Senat bestätigt seine Rspr., dass ein Sachmangel auch dann vorliegt, wenn der Unternehmer den Anweisungen des Bestellers folgt, damit aber die vereinbarte Beschaffenheit des Werks nicht erreicht werden kann. Er haftet … nur dann nicht für den Werkmangel, wenn er den Besteller darauf hingewiesen hat, dass unter Beachtung der Anweisungen des Bestellers das Werk nicht die vereinbarte Beschaffenheit, nämlich die geschuldete Funktion, aufweisen wird, …“ stephan-lorenz.de. 1 BGH v. 8.11.2007 – VII ZR 183/05, NJW 2008, 511.

Schneider

235

C Rz. 154

Verträge

bei denen das Pflichtenheft nach Vertragsschluss erstellt wurde, als Werkvertrag qualifiziert1. 154

„Das Product Backlog (Übersicht aller Elemente des zu entwickelnden Produkts) ist niemals vollständig und dient in Verbindung mit einem Projektplan lediglich als eine Ausgangsschätzung der Anforderungen.“2 Deshalb sind „sowohl Sprint Backlog als auch Product Backlog … als Lasten- oder Pflichtenheft ungeeignet“3.

Die Wahl agiler Methodik heißt dennoch nicht, dass mangels Vorarbeiten auf ein Pflichtenheft verzichtet würde. Dass das Erstellen des Pflichtenhefts mit agilen Verfahren kombinierbar ist, zeigen die Fälle, in denen das Pflichtenheft nachträglich erstellt wird. Dabei wird das Pflichtenheft also nicht zu Beginn des Projekts bzw. als Stufe davor erstellt, sondern synchron zur Projektentwicklung. D.h., dass – ähnlich der Dokumentation, die Inline als Kommentierung des Codes entsteht – eine Beschreibung der Anforderungen parallel erfolgt, zu denen die Antworten bereits als Software insoweit realisiert werden. Allerdings ist das Haupt-Verständnis des sog. Product Backlogs, dass dieses nicht vollständig ist, dass zudem im Rahmen der agilen Methodik die jederzeitige Veränderbarkeit besteht, so dass es sich dann in neuen bzw. in den jeweiligen Sprint Backlogs manifestiert. Damit wäre einerseits klar, dass bei Scrum zu Beginn und auch im weiteren Projektverlauf zunächst kein Erfolg abschließend bzw. feststehend beschrieben ist. Ob dies dann reicht, um eine werkvertragliche Typisierung vorzunehmen, ist zweifelhaft. Die Ähnlichkeit zu einem Entwicklungsvertrag erscheint erheblich, der nach der BGH-Rechtsprechung durchaus alternativ als Dienstvertrag – je nachdem, was die Parteien wollten – qualifiziert werden kann4. Die Informationswege bzw. der Informationsaustausch zwischen den beiden Vertragspartnern ist im Rahmen des agilen Projekts, v.a. im Rahmen des Scrum-Projekts sehr intensiv. Die Institutionen hierfür sind die Meetings verschiedener Frequenz immer unter dem Motto, dass gerade die Interaktion Vorrang vor Verfahrensordnung und Werkzeugen hätte. Dies erschwert die Einordnung als Werkvertrag, würde viel eher noch für eine Kooperation i.S. einer ARGE sprechen, also auch zur Ablehnung von Dienstvertrag führen. Andererseits ist für Dienstverträge die Flexibilität ähnlich, nur beruht sie auf der Weisungshoheit des Auftraggebers und der Verpflichtung des Auftragnehmers, diesen zu entsprechen. Da aber nicht einseitig der Auftraggeber Weisungen gibt, sondern – auch je nach Besetzung der Positionen – etwa als Scrum-Master ein Mitarbeiter des Auftraggebers, liegt die Weisungshoheit zum Teil oder fallweise beim Auftragnehmer. Dass damit auch der Auftraggeber sowohl durch die jederzeitige Bestimmung des Gewünsch1 S. z.B. OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 361. 2 Hengstler, ITRB 2012, 113 (114). S.a. Rz. 133. 3 Hengstler, ITRB 2012, 113 (114). Sprint Backlog ist die jeweilige Zusammenstellung der für einen Sprint vorgesehenen Arbeiten, s.a. Schneider, ITRB 2010, 18 und Rz. 133. 4 S. zu F&E-Projekt BGH v. 16.7.2002 – X ZR 27/01, CR 2003, 244.

236

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 155 C

ten als auch durch die Mitsteuerung des Verfahrens das Risiko übernimmt, ist eine automatische Folge1. Soweit diese bewusst eingegangen wird, also dem Auftraggeber mit dem Vertrag klar ist, worauf er sich einlässt, wäre die Annahme eines Dienstvertrages im Hinblick auf diese Risiko-Übernahme durchaus adäquat2. Es wird also ganz wesentlich sein, im Detail feststellen zu können, ob die Parteien wollten, dass der Auftraggeber das Realisierungsrisiko mitübernimmt. Eine Besonderheit der agilen Methoden, insbesondere auch bei Scrum, ist, dass sich die Parteien u.a. über die Qualifikation der Mitarbeiter, ggf. auch über die Personen als solche verständigen, die die jeweiligen Funktionen ausführen sollen. Da zudem auch die einzelnen Arbeitsabläufe, soweit sie nicht strukturell durch die Methodik vorgegeben sind, im Detail von den Parteien bestimmt werden, erscheint der Gedanke des Kooperationsvertrages insgesamt durchaus naheliegender als der des Werkvertrages oder auch des Dienstvertrages3. Im Hinblick auf die übliche vertragstypologische Einordnung erscheint folgende Einteilung bei Koch durchaus interessant: Der Vertrag wäre insoweit, als es um die erste, prototypähnliche (s.a. Rz. 120 ff.) Erstellung der Grundfunktionalität geht, was häufig bei agiler Methodik der erste erreichbare Entwicklungsstand ist, um Werkvertrag gehen4. Bei der dann besonders stark auf Basis mündlicher Kommunikation („Zuruf“)5 basierenden Zusammenarbeit würde es sich um Dienstvertrag handeln6. Kritischer erscheint auch folgender Aspekt: Die modernen Projektmetho- 155 den lassen es zu, dass der Kunde unmittelbar in das laufende Projektgeschehen hinein seine Anforderungen artikuliert, wieder ändert und – geordnet sowie umgesetzt – relativ kurzfristig als Ergebnisse wieder präsentiert bekommt. Ebenso pflegen aber manche Vertragspartner die sog. Change Requests (s. Kap. G Rz. 260 ff.), die tatsächlich „Änderungswünsche“ genannt werden. Die kurzfristige Rückkopplung der Ergebnisse mit ggf. weiteren Iterationen legt Kooperation und Dienstvertrag nahe, nicht jedenfalls alleinige Projekt und Erfolgsverantwortung des Bestellers. 1 Zu den diversen Aktivitäten und dem Aspekt des Verbleibs der herkömmlichen Zuständigkeiten s. Witte, ITRB 2010, 44. 2 A.M. offensichtlich Fuchs/Meierhöfer/Morsbach/Pahlow, MMR 2012, 427 (429). 3 Allerdings ist dies nicht h.M. Diese tendiert wohl – trotz der vorstehend aufgezeigten Aspekte – zu Werkvertrag. So insbesondere auch Frank, CR 2011, 138; für Dienstvertrag dagegen z.B. Koch, ITRB 2010, 114. 4 Koch, ITRB 2010, 114. 5 S. Koch, ITRB 2010, 114 (118 f.); zur Kooperation i.V.m. „gemeinsamen Rechten am Code“ s.a. Lapp, ITRB 2010, 69, worauf Koch auch hinweist. Zum Zurufprojekt als Werkvertrag OLG Karlruhe v. 16.8.2002 – 1 U 250/01 und dazu Rz. 30, 70, 170. 6 Zu der vertragstypologischen Einordnung und zu diesen Überlegungen von Koch s.a. Hengstler, ITRB 2012, 113.

Schneider

237

C Rz. 156

Verträge

156

Es passt auch nicht zum Werkvertrag, wenn der Besteller laufend die Ausführungsart prüft und ggf. ändert1. Mangelnde Konkretisierung der Anforderungen wird dagegen bei agiler Methodik meist kurzfristig erkannt, wenn nicht sogar schon bei der Redaktion für die Releaseplanung bzw. die blogs vermieden. Das Ticketsystem bewirkt allerdings, dass kein einheitliches Pflichtenheft entsteht, dafür aber eine Fülle von zunächst unsortierten und nicht logischen „Tickets“. Es wäre Sache des Vertrags, sowohl die fachliche Überprüfung der Tickets als auch die Überprüfung der ersten Umsetzungsansätze genauer zu regeln. Unter Umständen soll die Art und Weise, wie die Umsetzung erfolgen könnte, in erster Annäherung Prototyp-ähnlich vorgeführt werden.

157

Eventuell lässt sich dieses Verfahren aber durchaus mit einem probaten Mittel bei „klassischen“ Projektverträgen mit grober Spezifikation vergleichen, so dass es doch gerechtfertigt ist, bei Werkvertrag zu bleiben: Für das „klassische“ Vorgehen wird als eine Art Kompromiss angeboten, modulweise erstellte Feinspezifikationen je spezifischer Funktion freizugeben, mit der Folge, dass später durch Änderungen entstehender Aufwand als Change Request (s.a. Kap. G Rz. 260 ff.) behandelt werden kann und zusätzlich zu vergüten ist2. Das scheint nicht grundlegend verschieden von agilem Vorgehen, so dass auch insoweit Werkvertrag noch anwendbar erscheint3. 4. Der explizite Beratungsvertrag zur Unterstützung des Auftraggebers bei der Gewinnung des Pflichtenhefts a) Einführung

158

Gemäß dem hier vertretenen Konzept werden die Phasen des Projekts, die auf dem Weg zur Erstellung des fachlichen Feinkonzepts in linearer Abfolge zu durchlaufen sind, pauschal als Planung – im Gegensatz zur Realisierung – bezeichnet. Es ist das Verdienst der BVB-Planung, die besondere Bedeutung dieser Phase herauszustellen. Oft genug allerdings wird die Beratung nicht explizit beauftragt, so dass eine Art Vakuum entsteht, indem mit der Realisierung unmittelbar nach Vertragsschluss begonnen wird. Erforderlich ist eine Abgrenzung zur Beratung als vertragliche (Neben-)Pflicht.

159

Im Zusammenhang mit dem Pflichtenheft war schon dargelegt worden, dass den Auftragnehmer eine Pflicht treffen kann, dem Kunden Unterstützung bei der Artikulation von dessen Anforderungen anzubieten4.

1 Bei Werkvertrag ist gerade typisch, dass der Besteller nicht die Ausführungsart prüft und mitbestimmt, s. zu „Konstruktionsansatz“ BGH v. 13.6.2006 – X ZR 167/04, Rz. 14. 2 S. zum Vorgehen bei „Freigaben“ unten Rz. 334. 3 S. ähnlich Frank, CR 2011, 138; a.M. wohl Hengstler, ITRB 2012, 113. 4 BGH v. 13.7.1988 – VIII ZR 292/87 – Registrierkassen, CR 1989, 102; s. dazu oben Rz. 34 ff.

238

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 163 C

Auch insoweit kann es sich um ein Beratungsverhältnis handeln, wobei dann die Frage ist, wenn man die alten Kategorien anwendet, ob es sich insoweit um eine Nebenpflicht handeln würde. Auf diese Unterscheidung kommt es zumindest in manchen Fällen nicht an1.

160

Mit der Schuldrechtsmodernisierung erschien die bisherige Unterscheidung 161 in Haupt- und Nebenpflichten und bei letzteren in leistungs- und in verhaltensbezogene weitgehend im Hinblick auf § 280 BGB obsolet. Zum einen hat aber die Literatur diese Differenzierungen weiter aufrecht erhalten2. Zum anderen ist es bei den §§ 642 und 643 BGB geblieben, auf die in § 651 162 Satz 3 BGB verwiesen wird. Nach herrschender Meinung handelt es sich hierbei um so genannte Obliegenheiten, was die Mitwirkungsleistung des Kunden betraf, deren Verletzung den Verzug des Auftragnehmers ausschloss (wenn rechtzeitig angefordert und für die Weiterarbeit notwendig). Infolge dessen wird man wohl davon auszugehen haben, dass es nach wie vor Nebenpflichten gibt, deren Verletzung sich allerdings ebenfalls nach § 280 BGB richtet, zumindest soweit es sich um leistungsbezogene Nebenpflichten handelt. Soweit es sich um nicht leistungsbezogene Pflichten handelt, wäre § 241 Abs. 2 BGB einschlägig. Es ist wohl allgemeine Meinung, dass die Unterscheidung im Hinblick auf § 280 BGB irrelevant ist3. Das spezielle Problem in diesem Zusammenhang dürfte sein, ob eine 163 Vergütungspflicht insoweit besteht bzw. ob insoweit eine zusätzliche Beauftragung, die etwa nach §§ 612, 632 BGB vergütungspflichtig wäre, anzunehmen ist. Würde der Auftragnehmer die entsprechende Leistung vor Vertragsschluss erbringen, etwa im Rahmen der Erstellung eines Konzepts, so stellt sich dies grundsätzlich nicht schon als Beauftragung dar, sondern vielmehr als eine notwendige Maßnahme, um eben das Angebot sachgerecht erstellen zu können. Die Gefahr besteht allerdings, dass die beiden Aufgaben ineinander übergehen bzw. der Aufwand einen Umfang annimmt, wohl auch die Intensität der Beratung, der eigentlich typisch für die Phase nach Vertragsschluss ist. Lediglich als Ausnahme wird man die Entscheidung des OLG Nürnberg ansehen können, wonach die Leistungen noch im Rahmen der Angebotsphase vergütungspflichtig waren, aber nur bezogen auf den konkreten Fall4. Grenzfälle entstehen bei Letter of Intent, Vorverträgen u.Ä.5. Eventuell entsteht ein gesonderter Vertrag, der gilt, bis der intendierte Hauptvertrag geschlossen wird. Die Vergütung, soweit nicht gere-

1 S. etwa BGH v. 8.12.2011 – VII ZR 198/10. 2 S. Palandt/Grüneberg, 72. Aufl., § 280 BGB Rz. 22 f. 3 S. Palandt/Grüneberg, 72. Aufl., § 280 BGB Rz. 24: „im Rahmen des § 280 I ohne Bedeutung“. 4 OLG Nürnberg v. 18.2.1993 – 12 U 1663/92, CR 1993, 553 m. Anm. Bartsch hinsichtlich der Vergütungspflicht; s.a. Alpert, CR 2001, 213 zu „Vorvertraglichen“ Vergütungsansprüchen bei Webdesignern, Werbeagenturen und EDV-Dienstleistern beim Werkvertrag. 5 S. Redeker, ITRB 2007, 208; zu LoI s. Söbbing, ITRB 2005, 240.

Schneider

239

C Rz. 164

Verträge

gelt, kann sich nach §§ 612, 632 BGB richten, wobei die verhandelten Stunden-/Tagessätze einen Maßstab bilden können. 164

Im Hinblick auf die Vergütung wäre es nahe liegend, davon auszugehen, dass grundsätzlich entsprechende Beratungsleistungen im IT-Bereich als vergütungspflichtig gelten können, so dass dieses Erfordernis nach §§ 612, 632 BGB in der Regel erfüllt sein würde. Dies klingt so, als ob eine Vermutung für die Vergütungspflichtigkeit bestehen würde. Allerdings ist in jedem Falle Voraussetzung, dass tatsächlich ein Vertrag geschlossen wurde. Es genügt dann aber des Weiteren, dass „durchgreifende Zweifel bestehen, dass die Herstellung des Werks nur gegen Vergütung zu erwarten war“, um den Vergütungsanspruch zu verweigern1.

165

Geht man zum einen davon aus, dass mangels expliziter Vereinbarung ein mittlerer Ausführungsstandard geschuldet ist, zum anderen aber die Pflicht besteht, den Vertragserfolg zu fördern bzw. alles zu tun, damit dieser nicht behindert wird, wird die Unterstützungsleistung auch dann vom Auftragnehmer anzubieten sein, wenn er spezielle Angaben seitens des Auftraggebers benötigt, insbesondere, wenn er weiß, dass dieser eigentlich spezielle Forderungen hat. Um zu vermeiden, dass hier ein eventuell erheblicher Aufwand nicht vergütungspflichtiger Art entsteht, wird sich folgendes Vorgehen empfehlen:

166

1) Der Auftragnehmer wird den Auftraggeber auffordern, ihm die erforderlichen Angaben bis zu einem bestimmten Termin zu machen, die erforderlich sind, um die Anpassung (die Parametrisierung) vorzunehmen.

167

2) Gleichzeitig wird der Auftragnehmer anbieten, falls der Auftraggeber diese Information nicht liefert bzw. nicht innerhalb der Frist liefert, ihn im erforderlichen Umfang bei der Gewinnung dieser Information, etwa im Rahmen von Interviews oder Workshops zu unterstützen, wobei es erlaubt sein wird, dass der Auftragnehmer gleichzeitig

168

3) darauf hinweist, dass dann, wenn diese Arbeit mehr als eine Art Mitschrift der Vorgaben des Auftraggebers ist, eine zusätzliche Vergütung geltend gemacht werden wird und dies als Zusatzauftrag insoweit behandelt wird.

169

4) Anderenfalls werde man die Ausführung so weit betreiben, wie dies möglich sei und dort, wo Wahlmöglichkeiten bestehen, einen mittleren Ausführungsstandard erhält.

170

Es gibt noch einen ganz anderen Aspekt bei der Frage der Planungsphase und deren vertragstypologischer bzw. vergütungsrechtlicher Beurteilung: Mangels expliziter Vereinbarung kann aus dem Projekt ein „Zurufprojekt“ werden. Das heißt, dass die Mitarbeiter des Kunden mehr oder weniger vorbereitet ihre Wünsche äußern und diese vom Auftragnehmer registriert werden, der daraus die entsprechende technische Umsetzung, etwa im Rah1 BGH v. 8.6.2004 – X ZR 211/02, MDR 2004, 1105 = ITRB 2005, 5.

240

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 174 C

men der Parametereinstellung macht. In solchen Fällen ist die Projektleitung und die Projektsteuerung in den Händen des Auftraggebers mit der Folge, dass schon vom Ansatz her kein Werkvertrag, aber auch kein Vertrag über die „Herstellung“ einer neuen Sache vorliegt, wozu sich der Auftragnehmer verpflichtet hätte, sondern die Unterstützungsleistung als solche in den Vordergrund tritt. Typischerweise würde es sich dann, auch wenn ein Festpreis vereinbart ist, um einen Dienstvertrag handeln1. Dieses Ergebnis kann sich auch unter der Hand durch Änderung vom ur- 171 sprünglichen Vertragstyp, wenn sich diese Beratungsleistung so in den Vordergrund schiebt, bei der der Auftraggeber die Projektsteuerung innehat, ergeben2. Das oben erwähnte Problem, die Erstellung des Pflichtenhefts zwecks Anpas- 172 sung von Software schwerlich neutral vergeben zu können, wird ggf. durch Beratung hinsichtlich der Auswahl der Standardsoftware zu lösen versucht. Bei vielen Projekten übernimmt es ein Dienstleistungsunternehmen, das 173 nicht einmal die Standardsoftware selbst vertreibt, den Auftraggeber bei deren Auswahl und ggf. richtiger Dimensionierung (im Hinblick auf die Auswahl der Module u.Ä.) zu unterstützen. Die Eignung der Standardsoftware für den Kunden ist natürlich von ausschlaggebender Bedeutung hinsichtlich des anschließend erforderlichen Aufwands an Anpassung. Dies ist hauptsächlich ein wirtschaftlicher Aspekt. Häufig bleibt allerdings auch ein ganz wichtiger juristischer Aspekt offen, nämlich der Umfang, in dem sich die Organisation des Auftraggebers der Software anzupassen hat, damit diese „passt“ bzw. weniger zu ändern ist. Bei ausschreibungsähnlichen Verfahren legen Auftraggeber häufig schematisierte Anforderungskataloge vor und lassen die Beratungsunternehmen diese ausfüllen. Dann bedeutet ein „Haken“, dass die jeweils abgefragte Funktion in der Software enthalten ist. Hier wäre es nicht nur empfehlenswert, zwischen ja/nein wählen zu können, sondern als weitere Maßgaben bzw. Aussagen vorzusehen: – Im Standard innerhalb einer klaren Release-Planung vorgesehen bis … (der Auftraggeber setzt ein bestimmtes Datum), – erreichbar bzw. machbar durch Anpassung/Erweiterung der Software, also individuelle Anteile, eventuell auch Eingriffe am Code, was besonders wichtig sein kann für die Frage der Kompatibilität im Verhältnis zu den zukünftigen Updates bzw. der Releasefestigkeit dieser Änderungen. Es liegt nahe, einen Gedanken, der vor allem vom OLG Köln aufgebaut wor- 174 den ist, nicht nur bezüglich des Softwareanbieters/Gesamtsystem-Anbieters, sondern auch auf den Berater bei der Auswahl der Software anzuwenden: 1 A.M. OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95. 2 Zum Wandel vom Kauf- zum Werkvertrag s. BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäft, CR 1998, 393, wonach sich durch Änderung beim Vertragsgegenstand der Vertragstyp von Kauf zu Werkvertrag wandeln kann (im konkreten Fall im Zusammenhang mit dem Verzug bei der Dokumentation).

Schneider

241

C Rz. 175

Verträge

„Verspricht ein Unternehmer, dass die in seinen einzelnen Produktscheinen angebotene Soft- und Hardware die gesamte für den Betrieb des Bestellers erforderliche Anwendersoftware enthalte, so schuldet er auf Grund des mit der Unterzeichnung dieser Produktscheine geschlossenen Vertrages eine Gesamtlösung und kann sich nicht darauf berufen, der Besteller habe zunächst als Basislösung lediglich die in den einzelnen Produktscheinen aufgeführte Hard- und Software bestellt und für etwaige Ergänzungen hätte dieser zusätzliche Sondersoftware erwerben müssen.“1

175

Für den Berater könnte die Übertragung im Prinzip bedeuten, dass er seine Beratungspflichten verletzt, wenn durch seine Auswahlempfehlung beim Kunden eine Erwerbsentscheidung getroffen wird, bei der der Kunde sich vorstellt, die Software würde seine wesentlichen Funktionen abdecken, während dies erst nach entsprechendem Anpassungsaufwand möglich ist. Dabei impliziert die Erwerbsempfehlung wohl auch, dass die Software überhaupt die Eigenschaft hat, sich an die Kunden-Belange anpassen zu lassen. Probleme hat dies z.B. bei Umstellung von für bestimmte Branchen konzipierter Software auf die Belange anderer Branchen bereitet. Bei den PilotKunden, die aus der anderen Branche zuerst mit dieser Software befasst waren, stellte sich dann heraus, dass etwa die Umstellung von Geräte- und Stück-orientierten Systemen auf Prozess-orientierte nicht ohne weiteres möglich ist und dass auch der Behelf über eine „Auftragsschiene“ oder Ähnliches gerade im Hinblick auf die Pflege bzw. die Aufwärtskompatibilität dieser Hilfslösung kaum tragbar ist.

176

Hier manifestiert sich möglicherweise auch ein Generalproblem bei dem an sich für die Auftragnehmerseite durchaus empfehlenswerten Dienstvertrag: Der Dienstvertrag sieht im BGB keine irgendwie geartete Nacherfüllung vor. Entweder besteht die Vertragsverletzung oder nicht. Der einzige Schutz vor unmittelbarer Inanspruchnahme wegen Falschberatung ist das Verschulden, allerdings mit der Maßgabe, dass sich hier der Auftragnehmer entlasten muss. Vor dem oben angedeuteten Hintergrund der Entscheidung des OLG Köln – bei entsprechender Anwendung – kann dies durchaus erhebliche Schwierigkeiten bereiten. AGB des Anbieters hätten § 626 BGB zu berücksichtigen, nicht § 314 BGB. Aus § 281 BGB ergibt sich aber die grundsätzliche Notwendigkeit einer Fristsetzung. b) Vertragstyp bei Unterstützung

177

Grundsätzlich liegt bei einer Vereinbarung, den Auftraggeber bei der Gewinnung von dessen Anforderungen zu unterstützen, kein Werk-, sondern ein Dienstvertrag vor2. Dieser Dienstvertrag ist darauf gerichtet, dass am Ende zwar ein Pflichtenheft entsteht, jedoch unter der Federführung/Projektlei1 So OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246. 2 S. schon zu „Organisationsberatung“ OLG Köln v. 22.10.1987 – 1 U 41/81, CR 1988, 734; s.a. Brandi-Dohrn, CR 1998, 645; s.a. Schneider, Handbuch des EDVRechts, E. Rz. 38 ff. zur Abgrenzung Unterstützung gegenüber Erfolgsübernahme (auch einzelner Phasen).

242

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 179 C

tung und -Steuerung des Auftraggebers. Allerdings ist diese vertragstypologische Einordnung durch die praktische Ausgestaltung in vielen Verträgen gefährdet, wenn man dies aus der Sicht des Auftragnehmers betrachtet: Häufig wird explizit dieser Beratungsvertrag insbesondere in Verbindung mit Software-Anpassung im Angebot bereits mit Leistungen verbunden, die ihrerseits durchaus Erfolgscharakter haben1. Bei genügender auch rechtlicher Verbindung zu diesen Leistungen nutzt die Ausformulierung, der Auftragnehmer unterstütze den Auftraggeber, auch die explizite Beauftragung als solche nichts mehr. Diese Querverbindung kann dazu führen, dass der Gesamtvertrag einschließlich der Planung als Werkvertrag qualifiziert wird. In diesem Falle wird also eine Einheitlichkeit der Planungsleistung mit der Anpassung bzw. Lieferung der Software mit der Wirkung angenommen, dass bei mangelhafter Leistung im Rahmen des Projektvertrages selbst bzw. im Rahmen der Anpassung und Lieferung auch die Planungsleistung davon erfasst wird2. Die angedeutete Problematik wird ganz konkret, wenn die Planungsleis- 178 tung z.B. in einzelnen Scheinen festgelegt werden soll, die als Einzelverträge durchaus das Erfordernis erfüllen würden, reine Beratungs-, also Unterstützungsverträge und damit Dienstvertrag zu sein. Der Projektvertrag dient insoweit dann als Rahmenvertrag, auf den diese Einzel-Verträge Bezug nehmen. Das Problem besteht darin, dass der Hauptvertrag eventuell schon eine Leistung zum Gegenstand hat bzw. verspricht, die keinen bzw. nicht genügend Raum lässt, um die einzelne Beratung überhaupt zu rechtfertigen und diese noch gesondert vergütungspflichtig zu machen. In einem konkreten Fall hatte etwa der Anbieter sich bereits wie folgt geäußert: „Die Software enthält die gesamte für die … Branche, insbesondere die Bedürfnisse des Auftraggebers notwendige Anwendersoftware“. Hierin kann eine Gesamtlösung liegen, die der Auftragnehmer versprochen hätte und die dann zugleich auch die Zusicherung enthalten dürfte, dass die von ihm in den beigefügten „Produktscheinen“ oder „Anhängen“ beschriebenen Leistungen ausreichend und geeignet seien, um die nach den Bedürfnissen der Beklagten ausgerichtete Gesamtlösung zu verwirklichen3. Die Folge ist in dem konkreten Fall gewesen, dass dann die etwa noch für 179 Ergänzungen notwendige Sondersoftware nicht noch vom Kunden zu erwerben bzw. zusätzlich zu vergüten war. Dies lässt sich, vielleicht sogar mit einem „erst recht“-Argument, auf die Beratungsleistung übertragen: Bietet der Auftragnehmer bereits im Angebot bzw. im Hauptvertrag die „Gesamtlösung“ an, auch wenn dort die Beratungsleistung als solche nicht mehr explizit erwähnt ist, so wird er Schwierigkeiten haben, darzulegen und zu 1 S. Intveen, ITRB 2010, 238 (240): Werkvertrag, v.a. wenn Aufgabe darin besteht, nicht nur Pflichtenheft zu erstellen, sondern auch für dessen fachliche Eignung, Richtigkeit und Vollständigkeit für die spätere Realisierung zu sorgen. 2 S. z.B. OLG Köln v. 8.12.2000 – 19 U 184/00, CR 2001, 437, wobei in diesem konkreten Fall auch die Planung Gegenstand des Vertrages war. 3 So OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246 (248); s. Zitat Rz. 174.

Schneider

243

C Rz. 180

Verträge

beweisen, dass die zusätzlichen Beratungsleistungen, die vielleicht von ihrem Aufwand her unabsehbar waren, gesondert zu beauftragen vorgesehen (und zu vergüten) waren, obwohl er bereits die Gesamtlösung versprochen hatte. So gesehen wäre eine Beratungsleistung im Rahmen einer „Voruntersuchung“, die feststellt, ob überhaupt geeignete Software vorhanden ist bzw. auf dem Markt beschaffbar ist und welchen Zusatzaufwand die Anpassung verursachen würde, wesentlich besser dazulegen, und nicht schon Gegenstand einer „Gesamtlösung“. 180

Möglicherweise kollidieren in diesem Beratungsverhältnis auch die diversen Vorgehensweisen und Projektmethoden. Während der Kunde sich seinerseits über das Angebot konkreter Software, erst recht in Verbindung mit einer Gesamtlösung vorstellt, wesentliche Teile des Planungsprozesses entweder vernachlässigen zu können oder zumindest einzubeziehen, dreht sich für den Auftragnehmer eigentlich der Prozess, wie er sich klassischerweise von der Vorstudie bis zur Abnahme hinziehen würde, nur um. Das bedeutet, dass die Phasen, die gewöhnlich vor der Gewinnung der Anforderungen liegen, erst nach Beschaffung der Software zwecks Ermittlung der Anpassungsbedürfnisse durchgeführt werden. Aus der Kundensicht ist der Beschaffungsvorgang dann allerdings bereits abgeschlossen. AGB-rechtlich wird sich empfehlen, diese Umkehrung der Phasenabfolge, insbesondere aber auch die Verschränkung der beiderseitigen Leistungen (Anpassung der Software und Anpassung der Organisation des Kunden) genügend deutlich zu machen, am besten aber gar nicht in die AGB zu verlagern, sondern in das besagte Pflichtenheft und in den parallel auszubringenden Aktivitätenund Fristenplan. Letzterer stellt eine Art procedurale Version des Pflichtenhefts dar, in die die inhaltliche, fachliche Leistungsbeschreibung, die – bis auf Change Requests – statisch ist, übersetzt wird1.

181

Bei den „modernen“ Projektmethoden ist diese Umkehrung der Schrittfolge typisch, etwa schon bei Prototyping anhand der bereits beschafften Software2. Auch agil zu steuernde Projekte setzen häufig auf anzupassender Software auf, die bereits beschafft wurde3.

182

Die Abnahme/Freigabe der fachlichen Feinspezifikation stellt das Ende der Planungsphase dar. Die technische Feinspezifikation ist eigentlich der Beginn der Realisierung4. Bei den BVB-Erstellung galt noch: die Programmierung als nächstfolgender Schritt kann (darf) – gemäß Erläuterungen in der Fußnote – „nur dann gleichzeitig mit der Erstellung der technischen Feinspezifikation vergeben werden, wenn die Anforderungen an die Programme so genau bezeichnet sind, dass die Vergütung … und die Ausführungsfristen … für die gesamten geforderten Leistungen festgelegt werden können (§ 8

1 2 3 4

S. zum Aktivitäten- und Fristenplan Rz. 212, 328 ff. S. oben Rz. 120 ff. und sogleich Rz. 183 ff. Zum Integrieren der Planung in die Realisierung s. oben Rz. 130, 135. So auch das Schema der BVB oben Rz. 2.

244

Schneider

Rz. 188 C

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Nr. 1 VOL/A); andernfalls sind DV-technisches Feinkonzept und Programmierung gesondert zu vergeben“1. c) Anpassungs- und Implementierungsplanung für bereits vom Auftraggeber ausgewählte Software Besteht bereits die Auswahl-Entscheidung hinsichtlich konkreter Software, 183 so scheint es eine klare Referenz für die Planungsarbeiten zu geben. Dabei sollte aber berücksichtigt werden, dass die Standardsoftware – je nach Hersteller – durchaus beachtlichen Änderungen während der Planungsphase schon unterliegen kann, ebenso wie dann auch in der Realisierungsphase. Je nach Releasefestigkeit der Anpassungen/Änderungen kann mit Updates während der Projektlaufzeit ein erheblicher Aufwand verbunden sein. Wer diesen Aufwand zu tragen hat, insbesondere, wenn noch kein Pflegevertrag besteht, welcher genaue Endstand auch bei Gesamtabnahme geschuldet ist, sollten die Vertragspartner ausdrücklich festlegen. Aber auch die Organisation des Kunden ändert sich im Laufe dieses Pro- 184 jekts, wobei noch ein nahezu unauflöslicher Widerspruch hinsichtlich verschiedener Befunde häufig die eigentliche Ursache für das Scheitern von Projekten ist: 1. Die Geschäftsleitung gibt bestimmte Ziele bzw. Anforderungen vor, die 185 auch bestimmte organisatorische Strukturen bzw. Entscheidungen beinhalten, die aber erst noch im Unternehmen des Kunden vollzogen werden müssen. 2. Auf Befragen insbesondere auf Seiten des Auftragnehmers gegenüber den 186 Fachabteilungen äußern diese sich häufig mit Vorstellungen/Wünschen, die nicht mit diesen Zielvorgaben übereinstimmen, sondern eher aus der täglichen Arbeit stammen und dort Verbesserungen bringen sollen. 3. Die IT-Abteilung des Kunden hat auch noch ihre besonderen Vorstellungen, die aber am ehesten noch in die der Geschäftsleitung integrierbar sind. Jedenfalls können diese Vorstellungen abweichen, so insbesondere hinsichtlich der Qualität des auszuwählenden Produkts.

187

4. Der Ist-Zustand des Unternehmens, der häufig zuerst erhoben wird („Ist- 188 Analyse“), wird dann nicht des Weiteren einer Bedarfsanalyse unterzogen, um daraus das Grobkonzept nach Schwachstellenanalyse zu erstellen, sondern als gegeben angenommen. Insofern ist eine der wichtigsten Beratungsleistungen seitens eines Auftragnehmers, wenn die Software bereits ausgewählt ist, diese verschiedenen Standpunkte und Sichtweisen so zu vereinigen, dass daraus eine realistische, detaillierte Anforderung an die Anpassung und Einstellung der Software entsteht. Ein Erfolgsmoment ist schwer zu erkennen, auch wenn am Schluss ein brauchbares Pflichtenheft bzw. eine detaillierte Anforderungs-Beschreibung entstehen soll. Diese ent1 BVB-Erstellung § 1 Nr. 1; s.a. unten Rz. 314 ff.

Schneider

245

C Rz. 189

Verträge

hält aber auch zu einem erheblichen Teil und zwar nach Maßgabe auch des finanziell Machbaren, Änderungen der Organisation des Kunden, wenn sie richtig ausgeführt ist. Der Berater makelt so gesehen zwischen den Möglichkeiten der Software und den Anforderungen des Kunden. Infolgedessen erscheint dieser Vertrag tendenziell eher als Dienstvertrag zu qualifizieren zu sein. Dies wird jedenfalls dann gelten, wenn nicht der Auftrag darin besteht, die Software zu begutachten bzw. das Pflichtenheft zu erstellen oder den genauen Projektplan zu erarbeiten. 189

Im Sinne der Gewinnung von „handhabbaren Portionen“ kann es sich empfehlen, nicht nur einzelne Schritte zur Verfeinerung hintereinander zu schalten, sondern diese einzelnen Schritte jeweils auch nur bezüglich bestimmter Funktionalitäten oder Module oder beidem vorzunehmen. Dadurch wäre es möglich, jeweils eine bestimmte Abfolge von Schritten nicht für das ganze Projekt, sondern für Teilbereiche zu absolvieren und die einzelnen Portionen handhabbarer zu machen. Dieses Vorgehen empfiehlt sich nicht grundsätzlich. Es hat aber den Vorteil, praktisch handhabbar zu sein, vor allem wenn schon die Software beschafft bzw. die Beschaffungsentscheidung gefallen ist. Ansonsten besteht das Problem, dass kein einheitlicher Planungsprozess entsteht und vor allem die Leistungen weder insgesamt vom Aufwand kalkulierbar sind, noch untereinander abgestimmt sind bis hin zu Fragen der mangelnden Integration und Performance.

190

5. Die Beratung zur Auswahl geeigneter Hardware war früher oft unselbständiger Teil des Vertrages oder gehörte zur Verhandlung. Früher war wohl der Auftrag an einen Auftragnehmer speziell zur Beratung bei der Auswahl der geeigneten Hardware häufiger. Heute ist der entsprechende Auftrag unter Umständen Bestandteil eines Systemvertrages, bei dem die Hardware noch nicht feststeht, aber auch und vor allem vorvertragliche Aufklärung. Die Entscheidungen insbesondere in den 80-er Jahren betrafen häufig sog. Unterdimensionierung1.

191

Das Hauptproblem dürfte heutzutage seltener das Thema der Unterdimensionierung bzw. überhaupt der Kapazität sein, als vielmehr die Eignung der Hardware für die vorgesehenen Zwecke und die erforderliche Kompatibilität mit anderen Komponenten, insbesondere im Zusammenhang mit Netzwerken.

192

6. Sonstige Services gehören zunehmend zu Projektverträgen. Selbst wenn die Vergabe der Erstellung der Planungsunterlagen extern vergeben wird und auch als Werkvertrag ausgeprägt wird, also der Auftragnehmer die Projektverantwortung hierfür trägt, „hat“ der Auftraggeber nach wie vor ein Projekt im Hause. Er muss im Rahmen der Mitwirkung gemäß Gesetz und im Rahmen der vereinbarten Mitwirkungspflichten den Auftragnehmer „unterstützen“. Dazu gehören neben der Informationshingabe unter Umständen auch 1 S. z.B. im Hinblick auf c.i.c. BGH v. 6.6.1984 – VIII ZR 83/83, CR 1986, 79; BGH v. 24.6.1986 – X ZR 16/85, CR 1986, 799.

246

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 197 C

Tests u.Ä. Viele Kunden sind auf diese Querschnittsaufgabe weder organisatorisch noch personell eingestellt. In der Folge kann es sich empfehlen, einen internen Projektmanager (der gegenüber dem Auftragnehmer dann nicht „Projektleiter“ heißen sollte) einzusetzen. Dieser koordiniert die Mitwirkungsleistungen des Kunden, ist der Ansprechpartner für den Auftragnehmer und gleichzeitig auch das Scharnier für die Information des Vorstands/ der Geschäftsführung, das Projektcontrolling und ähnlichen Institutionen. Solches Projektmanagement auf Zeit wird typischerweise stark dienstver- 193 traglich ausgerichtet sein. Gleichwohl können einzelne Aufgaben daraus auch als Werkverträge ausgestaltet sein. Für diesen Fall wird es sich empfehlen, entsprechende Vorkehrungen im Vertrag vorzusehen, die den beiden Vertragstypen hinsichtlich der Einzelaufträge Rechnung tragen. Die Konsequenz ist, dass zusätzlich zum entsprechenden Projektmanagementvertrag „Leistungsscheine“ erstellt bzw. gezogen werden, in denen die einzelnen Leistungen näher umschrieben werden, insbesondere auch im Hinblick auf Zeit und Vergütung. Zu den näher werkvertraglich orientierten Leistungen könnte z.B. gehören, dass der Projektmanager die Leistungsangaben von Bietern überprüft, Tests mit Prototyping durchführt und gutachterliche Stellungnahmen hierzu abgibt. Falls er die Migration bewirken soll, etwa indem die Altdaten in entsprechend aufgemachter Form dem Auftragnehmer zur Verfügung gestellt werden, kann hierin auch ein Werkvertrag liegen. Weitere solche Services könnten sein das Projektcontrolling, die Qualitätssicherung und, insbesondere bei größeren Projekten, noch besonders auszuweisen die Projektrevision.

194

5. Die Übernahme des Planungsprozesses durch den Auftragnehmer bis einschließlich Gewinnung des Pflichtenhefts (Werkvertrag) a) Schritte, Projektmethoden Sehr vereinfacht wird insbesondere im Hinblick auf die Rolle des Pflichtenhefts zwischen den „klassischen“ und den „modernen“ Projektmethoden unterscheiden1.

195

Die vor allem im öffentlichen Bereich auch praktizierte bzw. vorgeschlage- 196 ne Vorgehensweise im V-Modell kann vereinfacht dahingehend zusammengefasst werden, dass sich aus dem jeweils vorausgehenden Verfahrensschritt der nächst folgende entwickelt. Insofern bauen die Schritte nicht nur aufeinander auf, sondern können jeweils die folgenden Schritte als Verfeinerungen der vorausgehenden angesehen werden2. Bei dem V-Modell fehlt in den Überschriften die explizite Nennung der 197 „Schwachstellenanalyse“. Dies sollte nicht darüber hinweg täuschen, dass 1 S. oben Rz. 2 zu der klassischen Vorgehensweise mit zentraler Rolle des (juristischen) Pflichtenhefts. 2 S. dazu auch Rz. 315 f.

Schneider

247

C Rz. 198

Verträge

inhaltlich z.B. im Rahmen der Verfahrensidee bereits im Zusammenhang mit der Erstellung der Problembeschreibung auch die bereits erkannten Schwachstellen aufzuführen sind (s. schon BVB-Planung und -Erstellung, Rz. 2). Zudem war nach dem BVB-Schema eine Bewertung des Ist-Zustandes, wie er zuvor (s.a. zur Vorstudie Rz. 298) ermittelt worden ist, vorzunehmen. Dazu gehörte neben der Prüfung der Notwendigkeit der Arbeiten und der Ermittlung konventioneller Rationalisierungsmöglichkeiten auch die Ermittlung von Engpässen. Die BVB verteilten die Schwachstellenanalyse auf verschiedene Phasen. Bei anderen Phasenschemata werden in der Praxis der Schwachstellenanalyse eigene Unterpunkte in der oben genannten Abschnittsfolge zugewiesen. Wenn man das Verfahrensschema entsprechend erweitert bzw. ergänzt, dann wären dies also die beiden Phasen „Machbarkeit“ und „Schwachstellenanalyse“. 198

Bei den BVB bildete die Schnittstelle zwischen den beiden Haupt-Phasen, Planung und Erstellung, das erwähnte Feinkonzept, das sich noch im Rahmen der Planung aufsplittet in das fachliche Feinkonzept und im Rahmen der Realisierung in das DV-technische Feinkonzept. Der Planung und der Sphäre des Auftraggebers ist noch das fachliche Feinkonzept zuzurechnen, der Phase der Realisierung und der Sphäre des Auftragnehmers das zechnische Feinkonzept. Somit erweist sich das (juristische) Pflichtenheft als funktional äquivalent dem „fachlichen Feinkonzept“1.

199

Die EVB-IT System enthalten als Vor-Einstellung das V-Modell, ermöglichen aber auch die Wahl anderer Vorgehensmodelle. Das Vorliegen der Leistungsbeschreibung wird aber praktisch vorausgesetzt: Nr. 1.2 EVB-IT Systemvertrag sieht vor, dass die Dokumente zu Leistungsbeschreibung aufgelistet und so in den Vertrag einbezogen werden.

200

In der Praxis besteht häufig das Problem, dass der Kunde Planungssicherheit auch i.S.v. Budget/Vergütungsobergrenzen haben will, am besten Festpreis mit Generalunternehmerschaft. Bei Vertragsschluss in einer frühen Phase fällt dies dem Auftragnehmer erfahrungsgemäß sehr schwer. Es tut sich dann bei den Alternativen folgendes Dilemma auf: Einigt man sich hinsichtlich der weiteren Arbeiten (deren Umfang aber noch gar nicht feststeht), insbesondere der Realisierung, bereits auf einen Festpreis, birgt dies ein erhebliches Risiko für den Auftragnehmer. Er wird, je nach Marktlage, versuchen, dieses Risiko durch Einplanung von Reserven bei der Vergütung abzufedern bzw. zu berücksichtigen. Dadurch entsteht ein eventuell sehr viel höherer Preis als es unbedingt, bei strikter Einhaltung der Vorgaben, erforderlich wäre. Wird der Preis nicht festgelegt, erfolgt die Bepreisung der Realisierung erst am Ende der Planung. So kann es dem Auftraggeber sehr wohl passieren, dass ihm dann ein tatsächlich doch sehr hoher Preis, dessen Rechtfertigung er aber schlecht überprüfen kann, angeboten wird und er auf Grund der Vorarbeiten auf diesen Auftragnehmer angewiesen ist.

1 S. bereits oben Rz. 80 ff.

248

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 203 C

Eine gewisse Abhilfe könnte in diesem Zusammenhang eine weitere Phase, 201 die noch zwischengeschoben wird, bieten. Sie wäre dann das Endstadium des Planungsprozesses: Gerade wenn der Auftragnehmer den Kundenwünschen besonders nachgeht und die Anforderungen der Mitarbeiter ausführlich aufnimmt und darstellt, dürfte eine gewisse Prozentzahl an Forderungen einfließen, die in ihrer Priorität nicht so hoch einzuschätzen sind, deren Realisierung aber sehr viel kosten kann. Es kann sich sogar um solche Varianten oder Spezifika handeln, die eigentlich die Geschäftsleitung gar nicht (mehr) zulassen möchte. Es kann sich deshalb empfehlen, wenn die Gesamt-Forderungen in einer Feinspezifikation im Entwurf vorliegen, die eigentlich verabschiedet werden könnte, gemeinsam eine abschließende Revision vorzunehmen, salopp genannt „Streichkonzert“, bei der alle nicht unbedingt erforderlichen Forderungen, insbesondere Zusatzforderungen, „Arabesken“ und Besonderheiten auf den Prüfstand gestellt und ggf. gestrichen werden. Einer Faustformel nach sollen bei 10 % Streichungen bis zu 30 % und mehr 202 vom Aufwand, ganz zu schweigen von der Dauer des Projekts, einzusparen sein. In diesem Zusammenhang könnte der Auftragnehmer gefordert sein, seine Kalkulation parallel zu diesem Streichkonzert anzupassen, somit offen zu legen und zu rechtfertigen, was dazu führt, dass eine Transparenz hinsichtlich des Zusammenhangs zwischen dem Umfang der Forderungen und der exakten Vergütung entsteht und der Auftragnehmer die Chance hat, einen sachgerechten Preis anzugeben, aber der Auftraggeber auch, diesen zu überprüfen. Erst wenn diese Revision abgeschlossen ist, wird auf Grund des dann verbindlichen Angebots des Auftragnehmers endgültig der Vertrag über die Realisierung geschlossen. Theoretisch könnte dies auch ein anderer Auftragnehmer sein, als der, der die Voruntersuchung/Planung durchgeführt hat1. b) Teilabnahme, Abnahme Bei vertragstypologischer Einordnung als Werkvertrag gehört zum Ab- 203 schluss des Planungsprozesses die Abnahme der fachlichen Feinspezifikation. Bei stufenweiser Gliederung des Planungsprozesses würde es nahe liegen, jede Phase und vielleicht auch die Spezifikation einzelner Abschnitte/Funktionen einer Teilabnahme zu unterziehen. Aus Auftragnehmersicht würde sich sogar empfehlen, jeden einzelnen Abschnitt, also die einzelnen Stufe des Planungsprozesses, abnehmen zu lassen. Dies hätte u.a. auch Wirkungen im Hinblick auf die Fälligkeit der Vergütung bzw. lässt eine projektsynchrone Vergütungsregelung zu, die dann für den Fall der Abnahme nicht nur à-cto.-Zahlungen vorsieht. 1 Es sei allerdings vermerkt, dass im Zusammenhang mit öffentlicher Vergabe eine Kollision entstehen kann, wonach das Beratungsunternehmen dann, wenn es die Ausschreibungsunterlagen mit erarbeitet und den Kunden insoweit beraten hat, für die Beteiligung am Verfahren selbst ausscheidet. Zur Ausschreibung s. Kap. N.

Schneider

249

C Rz. 204 204

Verträge

Aus Auftraggebersicht ist allerdings zu beachten, dass erhebliche Schwierigkeiten bestehen, die Tragweite bzw. Vollständigkeit und Ordnungsmäßigkeit der bisherigen Planungsleistungen zu verstehen und erkennen zu können. Infolgedessen kann es von erheblicher Brisanz sein, wenn die Abnahme vorbehaltlos erfolgt. Es läuft ab diesem Zeitpunkt eine separate Verjährungsfrist für Mängel (wobei sich diese Mängel der Planung im Rahmen der Realisierung manifestieren müssten und bei genügend langer Verjährungsfrist dies dann kein Problem mehr für den Auftraggeber darstellt). Eine Untersuchungs- und Rügepflicht nach § 377 HGB kommt bei werkvertraglicher Einordnung nicht in Betracht. Allerdings sehen viele AGB der Anbieter dies vor.

205

Die Forderung nach den Abnahmen bzw. den Teilabnahmen seitens der Auftragnehmer resultiert in vielen Fällen aus bilanzrechtlichen Überlegungen (die hier nicht weiter vertieft, insbesondere nicht auf ihre Richtigkeit hin überprüft werden sollen). Jedenfalls drängt es eigentlich beide Parteien dahin, eine Regelung zu finden, die für jeden Abschnitt auch den Abschluss bildet, ohne dass der Auftraggeber vielleicht schon mehr unterschreibt, als er selbst überhaupt prüfen bzw. überblicken kann und insofern überfordert wird. Die Lösung könnte in einem Verfahren ähnlich dem der BVB-Planung bestehen. Die BVB-Planung besagt etwa: „Entsprechen die Planungsleistungen des Auftragnehmers den vertraglichen Abmachungen einschließlich Ausführungsprotokollen (§ 3 Nr. 5 Abs. 1 Satz 4), erklärt der Auftraggeber unverzüglich schriftlich die Abnahme, spätestens einen Monat nach Übergabe und Besprechung der Dokumentation.“ (§ 9 Abs. 1 Satz 1).

Die „Ausführungsprotokolle“ entstehen durch Auskünfte der Ansprechstelle. Sie sind gemäß dem zitierten Abschnitt der BVB-Planung nur verbindlich, „wenn sie in einem von dem beiderseitigen Ansprechstellen unterzeichneten Ausführungsprotokoll niedergelegt sind; dies hat ebenfalls unverzüglich zu erfolgen“. 206

Aus Anwendersicht wird es sich empfehlen, einerseits keine Teilabnahmen zu akzeptieren, andererseits eine Gesamtabnahme vorzusehen. Wenn aber der Gesamtumfang des Projekts von Anfang nicht feststeht (wie dies nun gerade bei agiler Vorgehensweise der Fall ist), fällt es schwer, dessen Ende zu ermitteln. Ein Festpreis für ein im Ergebnis unklares Projektziel erscheint unangebracht. Ein Aufwandsprojekt droht aus dem Ruder zu laufen bzw. finanziell zu eskalieren. Durch die Iterationsschritte kann es sich empfehlen, als Instrumentarium die „Freigabe“1 einzuführen, die eine Art Mittelding darstellen könnte zwischen bloßem Zur-Kenntnis-nehmen des jeweiligen Entwicklungsstandes und einer (Teil-)Abnahme.

207

Der typische Fall, in dem sich dieses Instrument bewähren dürfte, ist die Anpassung von Standardsoftware über die Parametrierung hinaus. Der 1 S.a. Schneider, Handbuch des EDV-Rechts, 4. Aufl., H. Rz. 86b.

250

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 209 C

Kunde hat sich ein Paket ausgesucht aufgrund einer Grobspezifikation, die zwangsläufig deshalb grob ist, weil er die genauen Ergebnisse erst anhand der ausgewählten Software festlegen möchte. Diese Konkretisierungen ufern naturgemäß leicht auch in Änderungen bzw. Erweiterungen aus. Die Vorgehensweise würde dann vertraglich dahingehend strukturiert, dass die Aufgabengebiete je Modul oder sonst unterteilbarem Bereich in einer bestimmten Schrittfolge absolviert werden, die sehr 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 der Problemstellung – Abgleich mit Standard/Gewinnung der Details der Anforderungen – Konkretisierung der Anforderungen, Beschreibung als Feinkonzept – Aufwandsschätzung und Priorisierung – unbedingt – möglichst – „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 208 dem Start für die Realisierung des so weit fertigen und verabschiedeten TeilFeinkonzepts eine Verpflichtung des Auftraggebers enthält bzw. bewirkt, dass bei etwaigen späteren Änderungen seitens des Auftraggebers bezüglich seiner Anforderungen diese ihm zwar nicht verwehrt, jedoch zusätzlich zu vergüten sind. Infolge dessen wäre es dem Auftragnehmer möglich, diesen Teilbereich zu einem Festpreis zu erarbeiten und spätere Änderungswünsche sachgerecht hinsichtlich deren Umfangs zu beurteilen. Die Freigabe würde demnach eine Selbst-Beschränkung des Auftraggebers auch dahingehend bewirken, dass schon aus finanziellen Gründen gegenüber nicht unbedingt erforderlichen Änderungswünschen ein Riegel vorgeschoben wird. Bei agilen Verfahren wäre eine entsprechende Regelung zwar nicht konform mit dem Grundkonzept (Änderungen erwünscht), würde aber klare Lösungen bei der Vergütung (nach Zeitaufwand) ermöglichen Wenn die Vertragspartner hinsichtlich der Verjährungsfrist für Mängel- 209 ansprüche keine besondere Regelung treffen, stellt sich zu Lasten des AufSchneider

251

C Rz. 210

Verträge

tragnehmers das Problem, dass grundsätzlich wohl die Frist nach § 634a Abs. 1 Satz 1 Nr. 3 BGB in Betracht kommt und nur diese1. c) Mitwirkung des Auftraggebers, Prüfungspflichten des Anbieters2 210

Die Mitwirkungsleistungen gem. §§ 642, 643 BGB haben den Rang von Nebenpflichten (s.a. Rz. 162). Diese Vorschriften wurden nicht durch die Schuldrechtsmodernisierung geändert. Sie enthalten nicht nur eine besondere Ausprägung der Mitwirkung des Auftraggebers im Rahmen des Werkvertragsrechts, was dessen Pflichten, sondern auch, was die Rechte des Auftragnehmers betrifft, wenn der Auftraggeber diese Pflichten verletzt.

211

Eine Änderung in der Qualität wäre in Individualvereinbarungen nicht in AGB des Auftragnehmers zu erreichen. Offen erscheint das Verhältnis zu § 314 BGB. Für beide Regelungen gilt allerdings, dass für den Auftraggeber bei Abmahnung klar erkennbar sein muss, dass widrigenfalls die fristlose Kündigung droht3.

212

Der relativ niedrige Grad in der Bewertung ist insofern misslich, als zwischen den Hauptleistungspflichten des Auftragnehmers und den Mitwirkungspflichten des Kunden/Auftraggebers eine sehr enge Verbindung besteht, ja sogar eine Art Verzahnung in der Weise, dass häufig der nächste Schritt vom Auftragnehmer gar nicht richtig bzw. vollständig ausgeführt werden kann, wenn nicht der Zwischenschritt zuvor vom Auftraggeber ausgeführt wurde. Dies führt zu Notwendigkeit und Funktion des „Aktivitäten- und Fristenplans“4.

213

Die Urteile, die oben im Zusammenhang mit der Pflicht des Auftragnehmers zur Erforschung der Belange des Kunden zitiert wurden, verstärken noch diese Verzahnung5. Diese lässt sich etwa bei Analyse der BVB-Planung, noch mehr allerdings der BVB-Erstellung erkennen6.

214

Den Parteien wird zu empfehlen sein, ein entsprechendes Schema individuell auf ihre Belange des konkreten Projekts zuzuschneiden und jeweils auch zu vermerken, bis wann welche Leistung von welchem der beiden Vertragspartner zu erbringen ist. Eventuell lässt sich dies noch dadurch verfeinern, 1 S. dazu B. Rz. 57 ff. und unten Rz. 311, 332 ff., 337 ff., 374 ff. (Abnahme). 2 Müglich/Lapp, CR 2004, 801, u.a. mit Verweis auf BGH v. 11.5.2001 – V ZR 14/00, MDR 2001, 982 = NJW 2001, 2326 bezüglich Zuweisung von Mitwirkungspflichten allgemein; zur Folge der Umkehr der Beweislast in Fällen der Mitwirkungsverpflichtung s. BGH v. 31.1.1991 – IX ZR 124/90, MDR 1991, 727 = NJW-RR 2002, 1280. 3 S. BGH v. 12.10.2011 – VIII ZR 3/11. 4 S. dazu näher Rz. 328 ff.; Kap. G Rz. 197 ff. 5 S. Rz. 38 und OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459; s.a. OLG Stuttgart v. 18.10.1988 – 6 U 64/88 – Beratungspflichten gegenüber EDV-Einsteiger, CR 1989, 598. 6 S. Schema bei Schneider, Handbuch des EDV-Rechts, H. Rz. 146.

252

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 218 C

dass man nicht nur die ausführende Stelle dabei vermerkt bzw. vielleicht sogar die Funktion, die die betreffende Person ausübt, sondern auch durch die entsprechende Kennzeichnung, wenn beide Vertragspartner daran beteiligt sind, wer dabei federführend ist. Dass dies im Ergebnis möglicherweise dann auch dem Charakter das Gepräge gibt, sei hier vermerkt. Wird der Auftraggeber ständig als federführend gekennzeichnet, dürfte bei ihm auch die Projektverantwortung liegen und mithin könnte es sich nicht mehr um einen Werkvertrag handeln. Dem Auftragnehmer wird zu empfehlen sein, die Qualifikation zumindest 215 der wichtigsten Mitwirkungspflichten als Hauptpflichten im Vertrag zu verankern. Dies würde sich implizit bereits daraus ergeben, dass statt „Mitwirkung“ im Vertrag sogar „Kooperation“ statuiert wird, dem entsprechend beide Vertragspartner das Projekt leiten bzw. einen Gesamtprojektleiter stellen1. Dies wertet zwar die „Mitwirkung“ auf, verwässert aber die Erfolgs- bzw. Risikozuordnung des Werkvertrags bis zur Unkenntlichkeit – eine große Schwäche bei gerichtlichen Auseinandersetzungen2. Zu den Mindest-Pflichten aus der Projektsicht gehört, auch wenn die Par- 216 teien nichts miteinander vereinbart haben, dass der Auftragnehmer einen „Ansprechpartner“ auf Seiten des Kunden genannt bekommt, der dafür verantwortlich ist, die entsprechenden Mitwirkungsleistungen beim Auftraggeber zu koordinieren und rechtzeitig bereitzustellen. In der Regel wird dafür Voraussetzung sein, dass der Auftragnehmer wiederum diese Mitwirkungsleistungen rechtzeitig abruft – was entbehrlich wird, wenn der Aktivitäten- und Fristenplan dies bereits deutlich macht. Der Abruf würde dann dadurch geschehen, dass der Auftragnehmer das Ende eines Schrittes, für den er verantwortlich war, mitteilt und daraufhin der Auftraggeber wieder an der Reihe ist. Bei mehr paritätisch ausgerichteten Projekten wird nicht nur der Auftrag- 217 nehmer dies gerne sehen, sondern sogar der Kunde darauf bestehen, dass er auch einen Projektleiter stellt, vielleicht sogar den Projektleiter. Welche Konsequenzen dies dann für die vertragstypologische Einordnung hat, soll hier nicht weiter vertieft werden3. Je stärker die Projektleitung auf Seiten des Auftraggebers ausgeprägt ist, um- 218 so eher handelt es sich insoweit um einen Dienstvertrag. Manche Projektverträge sehen ungeachtet dieser Frage vor, dass beide Parteien einen Pro1 S. z.B. das Muster von Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4, § 2 Abs. 1: „Die Vertragspartner verpflichten sich zu einer engen und fairen Kooperation. Sie wissen, dass das Projekt nur bei gemeinsamer Anstrengung erfolgreich durchgeführt werden kann.“ § 12 des Beispiels regelt in Abs. 2 die Pflicht zu Beistellung je eines Gesamtprojektleiters durch jeden der beiden Vertragspartner. 2 S. Schneider, CR 2003, 317 (im Zusammenhang mit OLG Karlsruhe v. 16.8.2002, dazu Rz. 30, 70, 154). 3 S. Rz. 170 f.

Schneider

253

C Rz. 219

Verträge

jektleiter bestellen und diese gemeinsam das Projekt leiten, ggf. auch gleich als „Eskalationsebene“ bzw. „Eskalationsinstanz“, an die die Teil-Projektleiter und die einzelnen Mitarbeiter offene Fragen verweisen können1. 219

Speziellere Mitwirkungsleistungen des Kunden können auch im Vorfeld der Realisierung darin bestehen, die Altdaten, vor allem deren Struktur bereitzustellen. Es ist für den Auftragnehmer keineswegs trivial, möglichst frühzeitig, also auch schon während der Planungsphase, insbesondere als Anforderung an eventuelle Migrationswerkzeuge u.Ä., vor allem auch Bestimmung von Schnittstellen, die Struktur der Daten richtig aufzunehmen und analysieren zu können, die später in das neue System ggf. zu übernehmen sind.

220

Im Rahmen der Planungsphase wird die Beibringung von Testdaten noch eine geringere Rolle spielen. Dennoch kann es sich hierbei um eine sehr wichtige Aufgabe auch schon in der Planungsphase handeln. Dies betrifft vor allem den Fall, dass der Kunde/Auftraggeber beabsichtigt, seine Geschäftsprozesse zu ändern, so dass eine Ist-Aufnahme des Ablaufs beim Kunden nicht ausreichend wäre, um die Anforderungen an die Software, die noch zu erstellen bzw. anzupassen ist, formulieren zu können. Die verbale oder diagrammartige Ausprägung solcher Geschäftsprozesse ist zwar notwendig, oft aber nicht ausreichend. Details können ggf. nur so festgelegt, vor allem auch widerspruchsfrei ermittelt werden, dass sie anhand von Testdaten durchgespielt und auf ihre Plausibilität hin überprüft werden können. Dies wäre dann unter Umständen noch kein automatischer Ablauf im System, sondern ein so genannter Schreibtischtest.

221

Insbesondere bei den Projekten zur Anpassung von Standardsoftware, aber auch bei dem Softwareerstellungsprojekt, spielt auch die Bereitstellung der Mitarbeiter des Auftraggebers, die die Anforderungen formulieren, ggf. auch deren Aufnahme zu kontrollieren haben, eine besondere Rolle. Diese Aufgabe wiederum ist eng verbunden mit einer Schulung, wenn es um die Anpassung der Standardsoftware geht. Der Schulungsplan dürfte Bestandteil der Regelung der Mitwirkungsleistungen sein. Beispiele2: – Beibringung der fachlichen Anforderungen, – Mengen-/Bedarfsmitteilung im Hinblick auf erwartete Entwicklung des Geschäftsvolumens, – Mitteilung der vorhandenen Systeme und deren Leistungsdaten,

1 Zum gemeinsamen „Projektmanagement“, wo beide Vertragspartner einen Projektleiter und einen Stellvertreter bestellen, s. etwa die Vorschläge von Witte, in: Redeker, Handbuch der IT-Verträge, Kap. 1.4, Rz. 78 ff. und Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4. 2 S.a. mit weiteren Beispielen Müglich/Lapp, CR 2004, 801 (803); Schneider, Handbuch des EDV-Rechts, 4. Aufl., D. Rz. 407 ff., H. Rz. 147 ff.; Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4.

254

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 224 C

– Beistellung von näher zu bestimmender Software, wenn diese nicht vom Unternehmer stammt, – Bereitstellung von Testdaten, evtl. in Form von Testfällen und Echtdaten, – Räume, IT- und TK-Infrastruktur, – Echtdaten für Migration, zuvor evtl. die Beschreibung deren Beschaffenheit, wenn Format nicht vereinbart, – Ansprechpartner, – Mitarbeiter für Tests, Schulung.

In vielen Projekten erfolgt die notwendige Verfeinerung des Pflichtenhefts erst im Realisierungsstadium. Bei dieser Nachholung will der Auftragnehmer einerseits keine Erweiterung seiner Aufgaben, etwa durch Erweiterung des Fokus der Anforderungen1, andererseits aber eine Freigabe, wenn nicht Abnahme der nachträglich, eventuell gemeinsam erarbeiteten Konzepte durch den Auftraggeber2.

222

d) Besonderheiten bei Anpassung von Standardsoftware und gleichzeitiger Anpassung der Organisation des Kunden Unter „Mitwirkung“ wird normalerweise diejenige Projektförderung ver- 223 standen, die der Besteller/Auftraggeber erbringen muss, damit der Auftragnehmer seinen genuinen Leistungspflichten nachkommen kann. Dazu kann, wie oben dargelegt, z.B. die Lieferung der Altdaten, die Stellung eines Testsystems, die Gewährung des Zutritts zu Räumlichkeiten, die Abhaltung von Workshops unter Beteiligung von Mitarbeitern des Kunden u.Ä. gehören3. Je nach Dimensionierung der Mitwirkungsleistungen gehen diese auch bis hin zur Stellung von Mitarbeitern, die aber nach Weisungen des Auftragnehmers arbeiten4. Eine besondere Problematik, besonders in Verbindung mit Werkvertrag und 224 Festpreis, beinhaltet die Anpassung der Organisation des Auftraggebers und deren Umfang bzw. Regelung.

1 S. aber OLG Köln CR 1994, 229, LS 1 zu Zusatzwünschen: „1. Verpflichtet sich der Hersteller einer Individualsoftware, alsbald nach Vertragsschluss ein Pflichtenheft mit Realisierungsplan zu liefern, so wird er von dieser Verpflichtung nicht frei, wenn der Besteller bei einer Programmbesprechung von seinen früheren Wünschen abweichende Vorstellungen äußert; das Pflichtenheft ist dann fortzuschreiben.“ S. aber andererseits BGH v. 15.5.1990 – X ZR 128/88, CR 1991, 86, LS 3: „Zusatzwünsche sind im allgemeinen nicht Vertragsinhalt geworden, wenn sie zwar als selbstverständlich besprochen, dann aber nicht in die schriftliche Vertragsurkunde aufgenommen worden sind.“ (evtl. pVV). 2 S. zu Prüfung/Abnahme durch den Auftraggeber unten Rz. 232 ff., 358 ff.; Schneider, Handbuch des EDV-Rechts, 4. Aufl., H. Rz. 171 Prüfung durch den Auftragnehmer; dazu a. Rz. 240 ff. 3 S. Rz. 158 ff. 4 S. BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467.

Schneider

255

C Rz. 225

Verträge

225

Häufig wird übersehen, dass der Auftraggeber sich in vielen Fällen bereits die Standardsoftware danach ausgesucht hat, was er an Software in Zukunft bei sich einsetzen will1, wie er seine Prozesse in Zukunft gestalten will und dass er somit in einem häufig nicht näher definierten Umfang seine eigene Organisation insofern zur Disposition stellt, als sie an die Belange der Standardsoftware anzupassen ist2. Das Verhältnis von Anpassung der Standardsoftware und Anpassung der Organisation des Kunden ist bei vielen Projekten dunkel in dem Sinne, dass dies vorher nicht genau ausgelotet und erst recht nicht im Vertrag genau festgelegt wird3.

226

Gerade die Auffassungen, die davon ausgehen, dass der Auftragnehmer den Auftraggeber rechtzeitig auf den Projektaufwand hinzuweisen hätte, berücksichtigen zu wenig, dass der Auftraggeber es seinerseits in der Hand hat, wie hoch der Aufwand ist, in dem er nämlich, anstatt Ergänzungen und Anpassungen der Software zu fordern, seine eigene Organisation der Software anpasst. Gerade die angedeuteten Workshops dienen häufig dazu, einerseits den Mitarbeitern des Kunden vorzustellen, was man mit der Software alles machen kann, gleichzeitig aber auch deutlich zu machen, welcher Aufwand mit etwaigen Änderungen verbunden ist und so dem Kunden und seinen Mitarbeitern Gelegenheit zu geben, festzustellen, wo sie sich an die Software anpassen könnten. Wird im Vertrag bzw. im Pflichtenheft i.V.m. dem Aktivitäten- und Fristenplan diese Anpassung des Kunden an die Belange der Software vereinbart und festgehalten, könnte es sich sogar um eine Hauptpflicht des Kunden handeln. Dies hängt damit zusammen, dass praktisch als Äquivalent für die Leistungen des Auftragnehmers, die unstreitig Hauptpflicht sein würden, Anpassungen des Kunden anstehen bzw. anfallen (können).

227

Mindestens genauso wichtig ist aber, dass mit dieser Option die vertragstypologische Einordnung als Werkvertrag eher problematisch wird. Es handelt sich noch nicht einmal um das Abschwächen der werkvertraglichen Erfolgshaftung bei Entwicklungsverträgen, bei denen der eigentliche Erfolg nicht feststeht bzw. sicher ansteht. Vielmehr ist überhaupt unklar, in welchem Umfang die Software zu ändern ist und in welchem Umfang die Mitarbeiter des Kunden bereit sind, sich an die Software anzupassen. Daraus, dass während des Projektes dann anhand der einzelnen Module jeweils der Anpassungsgrad beider Seiten festgestellt und dann geplant wird, lässt sich eine vertragstypologische Einordnung nicht festmachen, da ja gerade die 1 Zur Evaluierung s. Witzel, ITRB 2011, 293; Kap. G Rz. 1, 59. S.a. oben Rz. 183 ff. 2 S. zu diesem oft vergessenen Aspekt Schneider, ITRB 2008, 261; Schneider, Handbuch des EDV-Rechts, 4. Aufl., H. Rz. 358 f., 369 f.; zur Notwendigkeit der Bereitschaft, (zwecks Optimierung) die eigenen Geschäftsprozesse zu ändern, s. Witzel, ITRB 2011, 164 (165). 3 S. zu organisatorischen Änderungen beim Kunden als Mitwirkungspflichten Schneider, ITRB 2008, 261; Schneider, Handbuch des EDV-Rechts, 4. Aufl., H. Rz. 358 f., 369 f.

256

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 231 C

entsprechenden Abmachungen, die zum Teil auch aufwandsabhängig sein dürften, erst im Laufe der Vertragsabwicklung erfolgen, ohne dass bei Vertragsschluss ein genügend klarer Erfolg geregelt wäre. Wenn also Gerichte annehmen, dass schließlich, auch wenn nichts Beson- 228 deres und Genaueres vereinbart ist, der Auftragnehmer („selbstverständlich“) schulde, die Software an die Belange des Kunden anzupassen, so übersieht dies häufig die Dispositionen des Auftragnehmers seinerseits, die Organisation an die Software anzupassen. Allerdings ist diese Disposition innerhalb der Hierarchie beim Kunden in 229 der Regel sehr unterschiedlich ausgeprägt. Während die Geschäftsleitung durchaus beim Vertragsschluss im Hinblick auf die Vergütung des Auftragnehmers bereit ist, die Organisation erheblich anzupassen (um auch die Vorteile der Software nutzen zu können), neigen die Mitarbeiter eher dazu, möglichst wieder genau eine Software so zu bekommen, wie sie sie bisher gewohnt sind. Es kann aber nicht angehen, das Risiko, ob sich der Kunde genügend an die Software anpasst, dem Auftragnehmer zu überbürden. Insofern ist eigentlich der Aufwand des Projektes bis zu einem gewissen Grade Risiko des Auftraggebers und zwar um so mehr, je weniger Anforderungen an die Software primär von ihm gestellt werden. Diese Wechselbeziehung des Umfangs der Anpassungsleistungen auf der Seite des Kunden gegenüber dem Aufwand beim Auftragnehmer sollte der Anbieter sehr deutlich machen1. In einem konkreten Fall enthielt die Software des Auftragnehmers eine be- 230 stimmte Art der Ausführung der Kommissionierung nicht, wie sie dann aber der Kunde wünschte bzw. auf der der Kunde bestand. Man vereinbarte dann sogar, den weiteren Lösungsweg durch den Auftragnehmer erarbeiten zu lassen und auch den entsprechenden Vorschlag vom Auftraggeber absegnen zu lassen. Dennoch war offensichtlich das Gericht der Meinung, dass hierin kein Auftrag zur Anpassungsprogrammierung der Software bestand2. Der Auftragnehmer hätte also sinnvollerweise schreiben müssen, dass die 231 Standardsoftware bestimmte Lösungen für die Branche standardmäßig enthält, aber nicht alle Varianten, die in der Branche vorkommen. Wenn dagegen der Kunde andere Varianten wünscht, so wäre dies mit Zusatzaufwand zu vergüten. Die Software habe lediglich die grundsätzliche Eigenschaft, auch an die anderen Varianten angepasst zu werden. Dies hatte offensichtlich der Auftragnehmer verabsäumt. Soweit ersichtlich spielt diese Disponibilität der Organisation beim Kunden in der Rechtsprechung und Literatur bislang keine Rolle.

1 Etwa verabsäumt im Falle des OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246. S. dazu Rz. 174. 2 OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246.

Schneider

257

C Rz. 232

Verträge

6. Prüfung des Pflichtenhefts, Prüfungspflichten a) Prüfungspflichten des Auftraggebers 232

Aus der Darstellung der Mitwirkungspflichten des Auftraggebers ergibt sich bereits, dass zahlreiche Informationen vom Auftraggeber an den Auftragnehmer geliefert werden und von diesem aufzubereiten sind. Das Ergebnis sind, je nachdem welche Schritte explizit durchlaufen werden, die verschiedenen Konzepte/Studien und am Ende das Pflichtenheft i.S.d. fachlichen Feinspezifikation.

233

Während des gesamten Herstellungsprozesses dieser Konzepte ist in der Regel der Kunde/Auftraggeber nicht in der Lage, mit vertretbarem Aufwand die eventuell bereits leicht technisch umgesetzte Darstellung dieser Anforderungen, weil sie auf eine Software oder eine bestimmte Software-Methodik projiziert sind, zu verifizieren. Dies macht die Forderung nach Teilnahmen und Abnahmen der Konzepte für den Auftraggeber schwierig.

234

Aber selbst wenn der Kunde seinerseits das Pflichtenheft beibringt bzw. Konzepte, die der Auftragnehmer dann weiter ausarbeitet, stellt sich ein ganz ähnliches Problem spiegelbildlich auf Seiten des Auftragnehmers. Die Frage ist, inwieweit den Auftragnehmer insoweit, als die Anforderungen des Kunden ihm übermittelt werden, sowohl beim ursprünglichen Informationsstadium als auch nach Niederlegung in einer solchen Spezifikation, eine Prüfungspflicht trifft.

235

In diesem Zusammenhang wird häufig das Baurecht herangezogen bis hin zur Untersuchungspflicht vor Ort. Hintergrund dieser möglichen Pflicht des Auftragnehmers, die man auch als „Vorprüfung“ bezeichnen kann, ist aber eine entsprechende spezielle Vorschrift in der VOB, für die es im BGB selbst kein Pendant gibt. Diese Vorprüfung könnte im EDV-Bereich bei Entwicklung von Konzepten für die Softwareerstellung und -anpassung darin bestehen, sich vor Ort beim Kunden sowohl hinsichtlich der fachlichen als auch der technischen Ausgestaltung und Infrastruktur so vertraut zu machen, dass der Auftragnehmer etwa die Machbarkeit und die Besonderheiten der Anforderungen ohne weiteres feststellen kann. Für die Installation von IT-Anlagen könnte man wieder in Analogie zu VOB oder sogar in unmittelbarer Anwendung, wenn sie vertraglich vereinbart ist, eine solche Vorprüfungspflicht annehmen. Für Software ist sie aber nicht selbstverständlich1.

236

Soweit der Auftragnehmer damit betraut ist, die Funktionalität der zu erstellenden Software aus Anforderungen des Auftraggebers zu erarbeiten, wird er verpflichtet sein, die Darstellung des Kunden auf ihre Plausibilität hin zu prüfen. Dies bedeutet vor allem, dass mit zunehmender Informationsmenge und Abarbeitung verschiedener Funktionen immer wieder die internen Querverbindungen in der Logik bzw. im Geschäftsprozess vom Auftragnehmer berücksichtigt werden müssen. Dies ist im Rahmen einer Beurteilung 1 S. aber den Vorschlag von Witte, der allerdings stark technisch orientiert ist (auf Hardware bezogen), in: Redeker, Handbuch der IT-Verträge, Kap. 1.4. Rz. 86.

258

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 240 C

von Konzeptionen, also letztlich Papier-orientierten Darstellungen, noch nicht ohne weiteres möglich. Schreibtischtests sind insoweit sicher wesentlich fehleranfälliger als Tests mit Echtdaten bzw. Testdaten und echten programmgesteuerten Abläufen. Insofern wird man aber zumindest vom Auftragnehmer eine Art Sichtprüfung fordern können, also dass der Auftragnehmer zumindest offenkundige Fehler, solche die man bei Durchsicht der Unterlagen erkennen kann, auch tatsächlich erkennt und ggf. rügt. Natürlich stellt sich die Frage, ob und inwieweit eine Untersuchungs- bzw. 237 Prüfungspflicht im Detail besteht. Hier wird oft damit argumentiert, dass der Auftragnehmer der Fachmann sei, etwa für die Branche. Vielleicht lässt sich daran auch der Pflichtenkreis orientieren: Dort, wo es um die Plausibilitäten innerhalb der Branche bzw. branchenspezifischer Gegebenheiten geht (Bank, Versicherung usw.), wird man eine entsprechende Prüfungspflicht seitens des Auftragnehmers annehmen können. Dort, wo es gerade um die Besonderheiten beim Kunden geht, wie dieser etwa diese branchenspezifischen Funktionen ausprägt, wird der Auftraggeber offenbarungspflichtig sein. Dieser wird natürlich einwenden, dass das, was für ihn normal ist, er überhaupt nicht daraufhin beurteilen kann, ob es etwas Besonderes ist. Dies wiederum würde aber dazu führen, dass der Auftraggeber eigentlich bei den Konzepten die Besonderheiten, die vielleicht auch gesondert auszuweisen wären, seinerseits prüft. Ein Einwand wird sein, dass er dazu gar nicht in der Lage ist. Je nach Vertragsgestaltung kann es sich aber empfehlen, auch wenn dies vielleicht den weiteren Projektfortgang etwas hemmt, dass eine dritte Stelle jeweils die entsprechende Prüfung vornimmt, sei dies im Rahmen der Qualitätssicherung, sei dies im Rahmen des Projektcontrolling1. Beim späteren Projekt wird allerdings wohl einer der Hauptfälle von Proble- 238 men nicht in der totalen Unvollständigkeit oder der völlig unkorrekten Darstellung im Konzept liegen. Viel häufiger wird es wohl sein, dass die Funktionalität angesprochen, weitgehend auch richtig wiedergegeben ist, jedoch nicht genügend detailliert. Bei einem „fachlichen Feinkonzept“ wäre es aber so, dass der Detaillierungsgrad so sein muss, dass die Umsetzung unmittelbar in das technische Feinkonzept möglich ist. Allerdings wird man häufig erst bei dieser Umsetzung dann den mangeln- 239 den Detaillierungsgrad feststellen. In dieser Phase wäre das Feinkonzept „abgenommen“, abgeliefert, falls nur Kaufrecht zur Anwendung käme. b) Prüfungspflicht des Auftragnehmers Es sind verschiedene Fallkonstellationen zu unterscheiden:

240

– Vorvertragliche Übergabe des Pflichtenhefts Nach wie vor dürfte dann, wenn der Auftraggeber das Pflichtenheft stellt, das Problem bestehen, ob insoweit der Auftragnehmer eine Pflicht hat, die1 S. dazu Rz. 192 ff.

Schneider

259

C Rz. 241

Verträge

se Vorgaben des Auftraggebers zu prüfen, etwa auch dann, wenn sie ihm nachvertraglich übergeben werden. Das Problem stellt sich meist bei vorvertraglicher Übergabe des Pflichtenhefts und Einbeziehung in den Vertrag nicht so stark, weil die Kalkulation des Auftragnehmers dann auf diesem Pflichtenheft beruhen dürfte, er es insoweit geprüft hat und die Erschwerungen und Hindernisse, die sich dann ggf. im Laufe des Projekts ergeben, eher zu seinen Lasten gehen, nicht zuletzt, wenn es um die Änderung der Ausführungsart und deren Erschwernisse geht1. Voraussetzung der Vergütungspflichtigkeit des Mehraufwands bei alternativer Ausführung ist, dass die Kalkulation nicht allein auf den Vorstellungen des Auftragnehmers beruht2. 241

Auch ohne dass dies im Vertrag ausdrücklich geregelt ist3, soll der Auftragnehmer nach Auffassung einiger Gerichte verpflichtet sein, das Pflichtenheft auf die Eignung für das geplante Vorhaben zu prüfen4. Auch wird eine Pflicht angenommen, eventuell fehlende Informationen rechtzeitig zu beschaffen, wenn der Auftragnehmer die Angaben des Auftraggebers für unzureichend hält5.

242

Schematisch lässt sich der Grad an Anspannung der Pflichten des Auftragnehmers wie folgt staffeln: – Offensichtliche „Fehler“ des Pflichtenhefts des Auftraggebers, etwa unzureichende Detaillierung, – Erkennbare „Fehler“, die sich bei einfacher Durchsicht dem Auftragnehmer erschließen, – versteckte „Fehler“, die sich gewöhnlich erst mit der Umsetzung bzw. dem Versuch hierzu zeigen. Die „offensichtlichen“ Fehler wird der Auftragnehmer rügen müssen, noch bevor ein solches Pflichtenheft Vertragsbestandteil wird.

243

Bei den erkennbaren Fehlern wird es auf den Grad der Erkennbarkeit ankommen, wobei die Gefahr besteht, dass indirekt über die sonst drohenden

1 S. BGH v. 16.7.1998 – VII ZR 350/96, MDR 1998, 1475 = NJW 1998, 3707 – Erfolgshaftung auch für alternative Ausführungsarten. 2 BGH v. 16.7.1998 – VII ZR 350/96, MDR 1998, 1475 = NJW 1998, 3707. 3 Entsprechend baurechtlicher Regeln und Usancen: § 3.3 VOB/B: Die vom Auftraggeber zur Verfügung gestellten Geländeaufnahmen und Absteckungen und die übrigen für die Ausführung übergebenen Unterlagen sind für den Auftragnehmer maßgebend. Jedoch hat er sie, soweit es zur ordnungsgemäßen Vertragserfüllung gehört, auf etwaige Unstimmigkeiten zu überprüfen und den Auftraggeber auf entdeckte oder vermutete Mängel hinzuweisen; s.a. BGH v. 11.10.1990 – VII ZR 228/89, CR 1991, 467 m. Anm. Brandi-Dohrn. 4 S. OLG Celle v. 5.10.1994 – 13 U 17/94, CR 1995, 152; OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459. 5 S. OLG Köln v. 22.9.1995 – 19 U 65/94, CR 1996, 20.

260

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 246 C

Folgen eine Prüfungspflicht besteht1. Analog VOB/B § 3.3. könnte es noch die Kategorie der „vermuteten“ Mängel der Unterlagen geben. Indizien könnten bestimmte Arten der Ausführung der Unterlagen sein, die auf eine nicht-fachmännische Erstellung und damit eine gewisse Wahrscheinlichkeit der Mangelhaftigkeit schließen lassen. Zum einen gibt es für Softwareerstellung keine entsprechende Vorschrift. Die BVB-Erstellung sahen in § 3 Nr. 1 Abs. 2 nur vor, dass der Auftragnehmer unverzüglich schriftlich mitteilen muss (unter Angabe der Folgen!), wenn er erkennt, dass die Leistungsbeschreibung oder eine Forderung des Kunden – – – –

„fehlerhaft, unvollständig, nicht eindeutig oder objektiv nicht ausführbar ist“.

Man kann ohne vertragliche Regelung also nicht davon ausgehen, dass der Auftragnehmer die Pflichten analog VOB/B hinsichtlich vermuteter Mängel hätte, nachdem selbst die BVB/EVB-IT System nichts Vergleichbares enthalten. Die Verletzung der Hinweispflicht kann Schadensersatzansprüche des Auf- 244 traggebers auslösen. Schlimmer noch für den Auftragnehmer kann sein, dass er das Ausführungsrisiko behält und die sich aus den offensichtlichen und erkennbaren Fehlern des Pflichtenhefts ergebenden Leistungserschwerungen doch zu dessen Lasten gehen2. – Fehlendes Pflichtenheft

245

Was aber gilt, wenn das Pflichtenheft nicht vorvertraglich vorlag oder dieses Pflichtenheft nicht ohne weiteres erkennbar lückenhaft und/oder mangelhaft ist? Grundsätzlich wird man aus der Beibringungspflicht des Auftraggebers schließen können, dass den Auftragnehmer keine Pflicht zur Substitution fehlender Mitwirkung des Kunden trifft. Daraus resultierende Risiken gehen eigentlich zu Lasten der individuellen Anforderungen des Auftraggebers. Eventuell will der Auftragnehmer aber nicht darauf vertrauen und die potentielle Unsicherheit nicht bestehen lassen. In der Folge ersetzt er aber, wenn der nicht das Pflichtenheft zurückweist, die fehlenden Angaben des Kunden durch eigene Recherchen. Dann ist er für deren Richtigkeit verantwortlich3. Nimmt man Werkvertragsrecht an, wird man, anders als bisher, davon auszugehen haben, dass ein nicht richtiges Pflichtenheft eine Pflichtverletzung

1 Sehr weitgehend bei dieser Hinweispflicht OLG Celle v. 20.2.1991 – 6 U 15/90, CR 1991, 610; OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459: Auftragnehmer muss von sich aus ermitteln und für ihn erkennbare Unklarheiten und Bedürfnisse aufklären. 2 Entsprechend BGH v. 16.7.1998 – VII ZR 350/96, MDR 1998, 1475 = NJW 1998, 3707. 3 So jedenfalls OLG Köln v. 22.9.1995 – 19 U 65/94, CR 1996, 20.

Schneider

261

246

C Rz. 247

Verträge

des Auftraggebers darstellt, die den Katalog der Rechte auslöst, wie dies allgemein bei einer Pflichtverletzung der Fall ist1. 247

Grundsätzlich hat der Auftraggeber das Pflichtenheft zu stellen und dafür einzustehen2. Deshalb trägt der Auftraggeber auch die Verantwortung für dessen Richtigkeit. Dennoch kann es bei leicht erkennbaren Indizien auf mangelnde Qualität und Eignung des Pflichtenhefts eine Pflicht des Auftragnehmers geben, dieses Pflichtenheft auf dessen Richtigkeit hin zu prüfen, etwa i.S.e. Schadensminderungspflicht. Besser noch trifft vielleicht die Analogie zur Pflicht des Auftragnehmers im Baubereich, vom Auftraggeber gestellte Materialien auf ihre Eignung zu prüfen3. Bei Anwendung von Kaufrecht wird diese Vorleistungspflicht nur gelten können, wenn sie vereinbart ist. Dazu gehört die Einbeziehung von Vorgehensmodellen und eines Aktivitätenplans in den Vertrag.

248

– Übersicht Prüfungspflicht Schematisch lassen sich wohl eine Reihe von Situationen abschichten, die unterschiedliche Pflichten bzw. Konsequenzen nach sich ziehen: Der Auftragnehmer wird verpflichtet sein, die Vorgaben des Auftraggebers einer Art Sichtprüfung spiegelbildlich der Prüfung im Hinblick auf offenkundige Fehler i.S.v. § 377 HGB zu unterziehen4. Verletzt der Auftragnehmer diese Pflicht, kann er sich einerseits selbst schadensersatzpflichtig machen, andererseits daran gehindert sein, den evtl. Mehraufwand, der daraus resultiert, erfolgreich geltend machen zu können.

249

Ist der Mangel der Vorgabe derart, dass er erst im Laufe der Realisierung erkennbar wird bzw. ist er nicht bei einer Grobdurchsicht erkennbar, dann wird der Auftragnehmer verpflichtet sein, unverzüglich nach Kenntnis entsprechende Mitteilung zu machen, den Auftraggeber zur Beseitigung bzw. Klarstellung aufzufordern. Etwaige Erschwernisse bzw. Mehraufwand hieraus werden zu Lasten des Auftraggebers gehen.

250

Die Anforderungen des Auftraggebers sind zwar nicht falsch, bedürfen aber der Konkretisierung: Der Auftraggeber wird verpflichtet sein, diese Konkretisierung nachzuholen (Mitwirkung). Probleme bereitet dies, wo § 642 BGB nicht explizit über § 651 BGB anzuwenden ist bzw. dies nicht individualvertraglich vereinbart ist. Den Mehraufwand auf Seiten des Unternehmers wird wahrscheinlich der Auftraggeber zu tragen haben, etwa i.S.e. Zusatzauftrages auf Unterstützung, also nach § 612 BGB.

251

Hier nun könnte sich die Schuldrechtsmodernisierung insofern auswirken, als stärker noch als bisher bei der Konkretisierung mangels eventueller spe1 S. Rz. 332 ff. und Kap. D Rz. 150 ff., 429; vor allem Risiko aus OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459. 2 S. Schneider, Handbuch des EDV-Rechts, 4. Aufl., H. Rz. 159 ff. 3 BGH DB 2000, 1859 und NJW 2000, 280. 4 S. für Baurecht BGH v. 11.10.1990 – VII ZR 228/89, CR 1991, 467.

262

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 255 C

zifischer Vorgaben des Auftraggebers die übliche Verwendung bzw. die berechtigte Erwartungshaltung eine Rolle spielen könnte. Vielleicht wäre es dann insofern richtiger, statt von einem „mittleren“ von einem „üblichen“ Ausführungsstandard zu sprechen. Im Hinblick auf die Vertragsgestaltung wird es sich empfehlen, einerseits 252 die Prüfung etwaiger Vorgaben des Auftraggebers explizit zu regeln, gleichzeitig hieraus auch die eventuelle Vergütung, aber auch die Verantwortung für diese Vorgaben und die damit verbundene „Ausführungsart“. c) Änderungsmanagement, Change Request Noch mehr als bisher empfiehlt es sich, in den Vertrag eine klare Regelung 253 hinsichtlich des Verfahrens bei möglichen Änderungen/Änderungswünschen des Auftraggebers aufzunehmen. Besonders zu beachtende Punkte (s.a. Kap. G Rz. 260 ff.) sind: – – – – – – –

Differenzierungen bei der Dringlichkeit/Priorisierung; Entsprechende Differenzierung bei der Reaktion des Auftragnehmers; Einstellen der laufenden Arbeiten je nach Art des Änderungsverlangens; Eventuell bereits während der Prüfung; Vergütungspflicht für umfangreichere Prüfung; Wegfall/entsprechende Verschiebung von Fristen/Terminen; Klare Regelung, was bei Nicht-Einigung passieren soll (Fortführung, Beendigung); – Vorbereitung für diese Entscheidung: klares Angebot des Auftragnehmers; – Klare Dokumentation der einzelnen Tools und deren Behandlung, einschließlich Fortschreibung des „Pflichtenhefts“, des Termin- und Aktivitätenplans; – Einbettung in das Eskalationsverfahren1. Im Planungsverfahren spielen die Change Request noch keine große Rolle. 254 Eine wichtige Anforderung an ein Pflichtenheft ist aber, dass es als Referenz für das Änderungsverfahren in der Realisierungsphase taugt. Dazu gehört, Minderungen und Mehrungen feststellen zu können, die sich aus der Änderung ergeben. Aber auch während der Planungsphase können sich Änderungen ergeben, 255 die jedoch häufig nicht nur ungeregelt sind, sondern auch unerkannt bleiben, bis es zur Realisierung kommt. Gedacht ist vor allem an den Fall, dass der jeweilige einzelne Schritt nicht den vorausgehenden konkretisiert, sondern dessen Focus ausdehnt. Das Problem entsteht etwa bei Entwicklung

1 S.a. Rz. 218; Kap. G Rz. 34 ff. mit Fallbeispielen; Kap. H Rz. 114 ff.; Kap. J Rz. 515 ff. Kap. M Rz. 114 ff. mit Textvorschlag.

Schneider

263

C Rz. 256

Verträge

verschiedener „Anforderungslisten“ des Auftraggebers zum Grobkonzept und des Grobkonzepts zum Feinkonzept. 7. Der konkludente Beratungsvertrag 256

Die dargestellten Probleme bei fehlendem oder unzureichendem Pflichtenheft resultieren in der Regel gerade daraus, dass der Auftraggeber es verabsäumt oder nicht leisten will, den Auftragnehmer oder einen Dritten mit der Planung bzw. Unterstützung bei dem Projekt zu beauftragen. Es fehlt dann ein expliziter Beratungsvertrag, der etwa dem bei Bau hinsichtlich des richtigen Vertrages entsprechen könnte. Die Parteien eines System- oder Erstellungsvertrages, die sich ohne die entsprechenden Vorarbeiten ans Werk machen, „verzichten“ auf die Planung1, ohne dass diese Beratungsleistung tatsächlich entbehrlich wäre, wie sich häufig in der Praxis zeigt. Das bedeutet, dass der Auftragnehmer gerade bei Projekten nach Festpreis einen nicht unerheblichen zusätzlichen Aufwand generiert, der letzten Endes durch das Nachholen der Planung entsteht. Akzeptiert man, dass auch dann, wenn nur eine Delta-Spezifikation vereinbart ist, der Auftragnehmer das gesamte Planungsprogramm angefangen von der Ist-Analyse schuldet2, bestünde erst recht eine solche implizite (vergütungsfreie) Beratungspflicht, wenn nichts vereinbart ist. Dazu kann auch gehören, dass der Auftragnehmer sich vorgestellt hatte, er bräuchte keinen expliziten Projektleiter.

257

Die Frage ist, ob bzw. unter welchen Voraussetzungen ggf. ein Beratungsvertrag konkludent mit der Wirkung entsteht bzw. vereinbart wird, dass der Auftragnehmer bestimmte Leistungen erbringt und der Auftraggeber diese – zusätzlich – zu vergüten hat. Grundsätzlich handelt es sich um einen zusätzlichen Auftrag, der – bei entsprechendem Vorbehalt – vergütungspflichtig ist3. Bei einem Aufwandsprojekt ist dieses Problem durchaus auch gegeben, lässt sich allerdings etwas leichter „lösen“, indem nämlich die entsprechenden Leistungen mit abgerechnet werden, ohne die Erforderlichkeit gesonderter Beauftragung aufzuweisen. Am Prinzip, nämlich der Frage, ob ein entsprechender Beratungsvertrag konkludent zustande gekommen ist, ändert sich dadurch aber nichts.

258

Grundsätzlich wird man also den Auftrag zur Beratung genauso sehen können wie jeden anderen Zusatzauftrag, auch was die entsprechenden Voraussetzungen betrifft. Das bedeutet, dass auf die ganz allgemeinen Voraus1 Was sogar bei eigentlich vereinbarter Erstellung eines Pflichtenhefts möglich ist (s. oben Rz. 41 zu BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543), somit erst recht bei fehlender Vereinbarung (Rz. 42). 2 S. OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993 361. 3 BGH DB 2002, 1321 – Zum konkludenten Anerkenntnis von Zusatzleistungen. Zur Abgrenzung der Zusatzleistungen eines Werkvertrages zum selbständigen Auftrag s. v.a. BGH NJW 2002, 1432; zu dem anders gelagerten Fall selbständige Beratung zum Kaufgegenstand s. BGH v. 16.6.2004 – VIII ZR 258/03, MDR 2004, 1174 = DB 2004, 2472.

264

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 262 C

setzungen für solche Zusatzaufträge in der BGH-Rechtsprechung zurückgegriffen werden kann. Die Problematik wird dann deutlicher, wenn man sich die Frage stellt, ob 259 die zusätzliche Leistung bzw. Zusatzbeauftragung, die evtl. konkludent erfolgt sei, tatsächlich selbständiger Leistungsteil oder nicht vielmehr ein selbstverständlicher Leistungsbestandteil ist. Bei der Projektleitung etwa ist es so, dass diese Leistung „automatisch“ als Folge der Projektverantwortung demjenigen, der diese innehat, obliegt. Hat der Auftragnehmer also im Rahmen einer werkvertraglichen Beauftragung das Erfolgsrisiko und damit die Projektverantwortung übernommen, obliegt ihm auch die Projektleitung. Es kann deshalb, wenn er nicht einen entsprechenden Vorbehalt bzw. eine 260 entsprechende Vergütungsposition in den Vertrag mit aufgenommen hat, keine zusätzliche Vergütung insoweit in Betracht kommen, weil auch keine zusätzliche Beauftragung denkbar ist. Anders wäre es, wenn man etwa unterscheidet zwischen der Projektleitung, die auf mehrere Personen verteilt ist und einer explizit eingerichteten Stelle, die als solche ständig vor Ort etwa verfügbar wäre. 8. Besonderheiten bei Fehlen des Pflichtenhefts a) „Mittlerer Ausführungsstandard“? Aus der oben zitierten BGH-Rechtsprechung würde sich zwanglos ergeben, 261 dass bei Nichtvorliegen eines Pflichtenhefts ein „mittlerer Ausführungsstandard“ geschuldet ist1. Die Frage ist allerdings, ob sich mit diesem Ergebnis beide Parteien zufrieden geben bzw. zufrieden geben müssen. So könnte etwa der Auftragnehmer ungeachtet dieser Maßgabe den Auftraggeber auffordern, ihm seine Anforderungen rechtzeitig, bevor er sich ans Werk macht, bekannt zu geben. Wenn sich allerdings im Vertrag dazu keine Anhaltspunkte finden, wäre die Frage, woraus sich ein solcher Anspruch ergeben würde. Soweit es sich um Werkvertrag handelt, wird sich der Auftragnehmer unmittelbar auf §§ 642, 643 BGB berufen können. Dies gilt auch dann, wenn über § 651 BGB Kaufrecht Anwendung findet und es sich um die Herstellung einer nicht vertretbaren Sache handelt2. In diesem Falle gelten die §§ 642, 643 über § 651 Satz 3 BGB. Sehr wohl denkbar ist aber auch, dass der Auftraggeber den Auftragnehmer 262 auffordert, doch zunächst, bevor er sich ans Werk macht, die Anforderungen zu untersuchen, zumindest ihm, dem Auftraggeber, bei deren Gewinnung zu helfen. Letzteres hätte seine Grundlage in der mehrfach zitierten BGHEntscheidung vom 24.9.19913. Allerdings setzen dieses Unterstützungsan1 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 m.w.N. 2 Zum Problem s. Kap. B Rz. 22, 43, 45 f., 58, 74. 3 BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543.

Schneider

265

C Rz. 263

Verträge

gebot – was eigentlich vom Auftragnehmer auszugehen hätte – und die daraus resultierende Unterstützungsleistung zum einen wohl voraus, dass überhaupt eine Gewinnung der Anforderungen des Kunden noch vorgesehen ist, wozu es normalerweise einer Vereinbarung bedürfte. Zum anderen wäre es erforderlich, die Vergütungsfrage zu klären. Hierüber besagt die BGH-Entscheidung bekanntlich nichts. 263

Möglicherweise ist dies sogar bei Verträgen, in denen überhaupt nicht vorgesehen ist, dass die Anforderungen des Kunden zunächst ermittelt werden, das Hauptproblem: Wenn der Auftragnehmer sich insoweit ans Werk macht, und dies über bloße Anfragen und Hinweise, wie hier zu verfahren ist, hinausgeht, wird der Auftragnehmer für die Arbeit, die er anstelle der Arbeit des Auftraggebers erledigt, normalerweise einen zusätzlichen Auftrag erhalten müssen, der auch zusätzlich zu vergüten ist. Hierüber gibt es kaum Rechtsprechung und zwar wohl deshalb, weil sehr viele Auftragnehmer es verabsäumen, auf diese Umstände hinzuweisen, also einen entsprechenden Vorbehalt wegen Behinderung und Aufwand der Ersatzvornahme anzubringen, wohl aber auch deshalb, weil die Sachverständigen der Auffassung sind, die Gewinnung dieser Anforderungen sei Sache des Auftragnehmers1.

264

Die fehlende Abrede über die Handhabung bei der Gewinnung der Anforderungen, genauer: ob diese Voraussetzung für die Leistungen des Auftragnehmers sein sollen, führt also nicht automatisch dazu, dass keine solche Erhebung der Anforderungen des Auftraggebers zu erfolgen hat. Das Mindeste wäre, dass bei entsprechender Aufforderung seitens des Auftraggebers es sich insoweit um einen Zusatzauftrag handelt, den der Auftragnehmer aber nicht abweisen kann. Allerdings ließe sich argumentieren, dass insoweit eine Vertragsänderung vorliegt (nicht nur ein Zusatzauftrag). Die Vertragsänderung besteht darin, dass statt eines Projektes mit dem Ergebnis „mittleren Ausführungsstandards“ nun ein Projekt gefordert wird, bei dem das Ergebnis den Anforderungen des Kunden entspricht. Dies wäre eigentlich sachgerecht. Die überwältigende Zahl der OLG-Entscheidungen ist allerdings einen völlig anderen Weg gegangen und hat eine Art doppelten In-Sich-Schluss vollzogen. Zum einen wurde aus der Tatsache, dass kein Pflichtenheft vorlag, nicht etwa geschlossen, dass insoweit ein mittlerer Ausführungsstandard geschuldet sei, sondern vielmehr gerade dann eine an die – unbekannten – Anforderungen des Kunden angepasste „Problemlösung“, was sodann zur Einordnung als Werkvertrag herangezogen wurde2. Teils wurde umgekehrt zunächst der Vertragstyp gewonnen und daraus dann der Schluss abgeleitet, dass ein an die Belange des Kunden angepasstes Ergebnis geschuldet sei3.

1 S. etwa OLG München v. 22.11.1988 – 25 U 5810/86, CR 1989, 283. 2 S. etwa OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95. 3 Zur „Gesamtlösung“ unabhängig vom Vertragstyp s. OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246 und dazu Rz. 174.

266

Schneider

Rz. 269 C

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

b) Risiken bei fehlendem Pflichtenheft aus dem Mangelbegriff Der Mangelbegriff hat sich geändert und stellt hinsichtlich der Sollbeschaf- 265 fenheit vor allem auf die vereinbarte Beschaffenheit ab. Im Übrigen gilt beim Werkvertrag eine entsprechende Abstufung, wie sie oben zum Mangelbegriff beim Kauf dargestellt worden ist mit der Ausnahme, dass es hier die Einbeziehung der öffentlichen Äußerungen im Rahmen der Erwartungshaltung bzw. des Üblichen nicht gibt. Andererseits heißt es in § 633 Abs. 2 Satz 2 BGB ganz klar:

266

„Soweit die Beschaffenheit nicht vereinbart ist, ist das Werk frei von Sachmängeln, 1. wenn es sich für die nach dem Vertrag vorausgesetzte, sonst 2. für die gewöhnliche Verwendung eignet und eine Beschaffenheit aufweist, die bei Werken der gleichen Art üblich ist und die der Besteller nach der Art des Werkes erwarten kann.“

Funktionell neu ist der Zusatz „Beschaffenheit aufweist, die bei Werken der gleichen Art üblich ist und die der Besteller nach der Art des Werkes erwarten kann“. Diese Einbeziehung der Üblichkeit und zugleich stärkere Subjektivierung 267 kann es gebieten, dass nicht allein auf den mittleren Ausführungsstandard abzustellen ist. Zum Beispiel könnte der Vertrag besondere Anforderungen des Auftraggebers explizit oder zumindest implizit ergeben, vor allem wenn etwa die Präsentation des Anbieters schon ergibt, dass diese Ziele und Anforderungen wie etwa Hoch-Verfügbarkeit, Durchgängigkeit aller Prozesse (Interoperabilität) vom Anbieter erkannt und akzeptiert worden waren. Bislang hatte der Unternehmer im Rahmen eines Werkvertrags die Möglich- 268 keit, den Besteller dazu aufzufordern, ihm die nötigen Anforderungen zu geben. Die Nicht-Lieferung solcher Angaben wäre eine Verletzung von Mitwirkungsleistungen des Bestellers gewesen, §§ 642, 643 BGB, die allerdings nicht als „Hauptpflichten“ galten und insofern auch nicht den Unternehmer zum Vorgehen nach § 326 BGB a.F. berechtigten1. Nunmehr ergibt sich eine andere Situation, entsprechend dem oben dargestellten Raster bezüglich der am Wortlaut orientierten Auslegung des § 651 BGB. Deshalb muss im Hinblick auf die evtl. Anwendung von Kaufrecht das Fehlen der gesetzlichen Regeln zur Mitwirkung kompensiert werden. 9. Besonderheiten zur „Dokumentation“ Grundsätzlich scheint das Thema „Dokumentation“ allein der Phase der 269 Realisierung zuzurechnen sein. Dies verkennt aber, dass zum einen das Leistungsergebnis der Planung schließlich in einer Art Dokumentation besteht, als die man das „Pflichtenheft“, genauer als die Feinspezifikation, be-

1 S. zur Rspr. BGB a.F. Ihde, Das Pflichtenheft beim Softwareerstellungsvertrag, CR 1999, 409.

Schneider

267

C Rz. 270

Verträge

zeichnen kann. Deren genaue Ausgestaltung gilt es also als „Vertragsgegenstand“ möglichst genau und umfänglich zu beschreiben. 270

Sodann gehört zu einem gut geführten Projekt aber auch eine Projektdokumentation1. Diese belegt den Verlauf des Projekts, so insbesondere, wenn Anforderungen vom Kunden bzw. dessen Mitarbeiter abgefragt (z.B. „Interviews“, Workshops), Tests durchgeführt, Prototypen vorgestellt werden u.Ä. Dabei ist jeweils nicht nur der Verlauf, sondern das Ergebnis auch dann festzuhalten, wenn damit keine Freigabe seitens des Kunden verbunden sein soll.

271

Erst recht gilt dies naturgemäß dann, wenn der Kunde die einzelnen präsentierten Ergebnisse etwa freigeben soll, was eine Art Minimum gegenüber einer Abnahme darstellen würde. Die Wirkung wäre nicht eine Beweislastverschiebung. Es kann jedoch eine Mitwirkungspflicht des Kunden bestehen, die sogar eine Hauptpflicht darstellen könnte, nämlich den Prozess des Projektes in seinem Fortgang zu fördern. Wenn der Auftraggeber bei der Informationsgewinnung und Festlegung der Anforderungen mutwillig etwas freigibt, von dem er weiß, dass er es so nicht will, könnte er etwa wegen einer Pflichtverletzung später auf Schadensersatz belangt werden. Näherliegend ist es, ihm den Mehraufwand anzulasten.

272

Weiter spielt das Thema Dokumentation bei der Planung insofern noch eine Rolle, als genau festgelegt werden sollte, welche Dokumentation dann schließlich im Rahmen der Realisierung erstellt werden soll und wann.

273

Schließlich entsteht ein Problem der Dokumentation bei bereits existierender Standardsoftware, die angepasst und erweitert werden soll. In diesem Fall kann ein erheblicher Bedarf an Klarstellungen und Festlegungen dahingehend bestehen, wie die Dokumentation und Änderung der Software beschaffen sein soll.

274

Die Frage ist, ob mangels spezieller Vereinbarungen zur Ausgestaltung der Planungsleistung nicht eine Anforderung an diese gestellt werden darf, die denen analog ist, die der BGH zur Dokumentation bei Software entwickelt hat. So hat der BGH vor allem die Perpetuierungswirkung einer eventuellen Einweisung (oder Schulung) und des in der Anlage verkörperten Wissens für eine EDV-Anlage betont2. Für Software hat er auf diese Entscheidung verwiesen3.

1 S. z.B. zur „Planungsdokumentation“ LG Köln v. 16.7.2003 – 90 O 68/01, CR 2003, 724. 2 BGH v. 5.7.1989 – VIII ZR 334/88, CR 1990, 189. 3 BGH v. 4.11.1992 – VIII ZR 165/91CR 1993, 422 und BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207 für Standardsoftware und für Individualsoftware bzw. angepasste Software BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681, vor allem wegen Fälligkeit bei Softwareerstellung: BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367.

268

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 277 C

Ein Mangel der Montageanleitung ist ein Mangel der Sache, ebenso eine un- 275 sachgemäße Durchführung einer vereinbarten Montage (§ 434 Abs. 2 BGB). Dies wird sich auf Installation, Installationsanweisung und Bedienungsanleitung anwenden lassen. Deren Fehlen wäre Nichterfüllung bzw. „nicht vertragsgemäß erbrachte Leistung“ (§ 323 BGB). Auf Pflichtenheft bzw. Planung übertragen kann dies bedeuten, dass die Konzepte und Anleitungen zur Realisierung, etwa bei Anpassung die Parameter-Einstellungen und die Migrations-Informationen, ebenfalls vorliegen sollten. Anders aber als bei Softwareerstellung wird es einer ausdrücklichen Vereinbarung bedürfen, wenn zusätzlich zum Pflichtenheft weitere Dokumentationen geschuldet sein sollen1. Eine Programmbeschreibung ist bei Erstellung der Software regelmäßig, au- 276 ßer wenn sich dies unmittelbar aus dem Vertrag ergeben würde, nicht geschuldet2. Es kann sich aber aus den Umständen ergeben, dass z.B. ein Datenmodell mitgeliefert werden müsste. Die Anforderungen an solche Dokumentationen sind um so größer, je mehr der Auftraggeber vom Vertragszweck her selbst die Weiterentwicklung der Software vornehmen will und soll. Ist etwa vereinbart, dass der Auftraggeber die Software selbst pflegen will, sind die entsprechenden Dokumentationen mit Vertragsbestandteil, auch wenn sie nicht explizit aufgeführt sind. Angewandt auf die Planung heißt das, dass dann, wenn der Auftraggeber durch deren Ergebnisse in die Lage versetzt werden soll, selbst oder durch Dritte die Planung umzusetzen, auch die Beschreibung der entwickelten Vorgaben mitzuliefern ist. Wenn im Vertrag zur Gestaltung des Pflichtenhefts nichts Besonderes gere- 277 gelt ist, so könnte doch der Zweck beschrieben werden, etwa dass der Auftraggeber in die Lage versetzt werden soll, wenn nicht selbst, so doch durch Dritte die Realisierung auf Basis des Pflichtenhefts vorzunehmen. Daraus ergibt sich, dass das Planungsergebnis für den Auftraggeber verständlich sein muss, wobei sich dies nicht auf einen Laien beziehen wird, sondern den „normalen“ Entwickler bzw. Programmierer. Zusätzlich wird sich – auch bei expliziter Regelung – empfehlen, wenige Seiten eines „Musters“ beizufügen, womit allerdings die Gefahr für den Auftragnehmer und der Vorteil für den Auftraggeber verbunden sein kann, dass es sich hierbei im Zweifel um eine Zusicherung bzw. nach Schuldrechtsmodernisierung um eine Garantie handelt3.

1 Zum Umfang der Dokumentationspflichten in Abhängigkeit von der typischen Vertragsleistung s. Stiemerling, ITRB 2011, 286, mit Zuordnungsmatrix 290. 2 Im Fall, den OLG Köln v. 12.2.1999 – 19 U 119/98, CR 2000, 212 zu beurteilen hatte, hatten die Parteien ausdrücklich vereinbart, dass eine „Programmbeschreibung“ bis zu einem bestimmten Termin zu erstellen sei. Tatsächlich handelte es sich um die Leistungsbeschreibung/das Pflichtenheft als Beschreibung des Soll-Zustandes. 3 Im Sinne verschuldensunabhängigen Einstehens für die Eignung zur Realisierung.

Schneider

269

C Rz. 278 278

Verträge

Die BVB-Planung nehmen praktisch eine Gleichsetzung von Arbeitsergebnissen i.S.d. Pflichtenhefts (Planungsleistungen) und Dokumentation vor. Es gibt aber zusätzlich Ausführungsprotokolle, die als Dokumentation im vorherigen Sinne, etwa analog der Programmbeschreibung bei Realisierung gelten könnten. Dazu regelt § 3 Nr. 5: „… Der Auftragnehmer hat die ihm vom Auftraggeber benannte Ansprechstelle für verbindliche Auskünfte zu Forderungen des Auftraggebers zur Vertragsausführung sowie für alle sich aus der Vertragserfüllung ergebende Fragen einzuschalten, wenn und soweit die Ausführungen den Auftrags dies erfordert sowie in den Fragen, in denen sich der Auftraggeber die Mitwirkung vorbehalten hat. Die Ansprechstelle wird unverzüglich die zur Vertragsausführung erforderlichen Auskünfte erteilen und Forderungen stellen. Sie sind nur verbindlich, wenn sie in einem von den beiderseitigen Ansprechstellen unterzeichneten Ausführungsprotokoll niedergelegt sind; dies hat ebenfalls unverzüglich zu erfolgen.“ (§ 3 Nr. 5 Satz 2 ff. BVB-Planung)

279

Unter § 9 Abnahme heißt es dann in den BVB-Planung in Abs. 1: „Entsprechen die Planungsleistungen des Auftragnehmers den vertraglichen Abmachungen einschließlich Ausführungsprotokoll (§ 3 Nr. 5 Abs. 1 Satz 4), erklärt der Auftraggeber unverzüglich schriftlich die Abnahme, spätestens einen Monat nach Übergabe und Besprechung der Dokumentation.“ (Satz 1) „Kommt die Besprechung der Dokumentation aus im Einflussbereich des Auftraggebers liegenden Gründen nicht innerhalb …“ (§ 9 Abs. 3 Satz 1 BVB-Planung)

280

Gemäß § 3 Nr. 2 hat der Auftragnehmer über die Ergebnisse seiner Arbeiten „eine ausführliche, schriftliche Dokumentation“ vorzulegen. Sofern im Planungsschein nichts anderes vereinbart ist, muss die Dokumentation folgenden Anforderungen genügen: „a) Dokumenten, die die Grundlagen für die Entscheidungen des Auftraggebers zur Weiterführung des Verfahrens beinhalten, sind Kurzfassungen der entscheidungsrelevanten Informationen voran zu stellen. b) Der Ist-Zustand ist in dem Umfang darzustellen, wie das für die Verständlichkeit der Dokumentation erforderlich ist. c) Das Grobkonzept muss entsprechend seiner Funktion als Vorgabe für die Erarbeitung des fachlichen Feinkonzepts sowie des technischen Feinkonzeptes einen gesonderten fachlichen und DV-technischen Teil enthalten.“

… (es folgt eine Vorgabe hinsichtlich des Grobkonzepts bzw. der dafür erforderlichen Entscheidungen) „d) Sofern das fachliche Feinkonzept die Beschaffung von DV-Leistungen vorsieht, sind die dafür erforderlichen Vorgaben gesondert darzustellen und eindeutig und erschöpfend zu beschreiben, so dass sie als Leistungsbeschreibung für ein wettbewerbliches Vergabeverfahren verwandt und von allen Bewerbern im gleichen Sinne verstanden werden können.“ (§ 3 Nr. 2 BVB-Planung)

281

Diese Vorschrift wird ergänzt durch die Maßgabe, dass der Auftragnehmer nach Übergabe der Dokumentation zu einer eingehenden Besprechung mit dem Auftraggeber verpflichtet ist (§ 3 Nr. 2 Abs. 2 BVB-Planung). Diese Besprechung ist wiederum ausdrücklich hinsichtlich des Verzugs in § 9, Abnahme, berücksichtigt. Sie ist insofern Voraussetzung für die Abnahme, 270

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 287 C

wie oben zitiert („spätestens einen Monat nach Übergabe und Besprechung der Dokumentation“). Diese Grundsätze aus den BVB-Planung sind auch geeignet, bei nicht-öf- 282 fentlichen Planungsvorhaben verwendet zu werden. An die Stelle der Eignung für ein Vergabeverfahren tritt dann die Eignung für die eventuelle Fremdvergabe oder Selbstvornahme, wie oben erwähnt. Quellcodedokumentation: Der Quellcode gehörte bisher nach wohl noch 283 herrschender Meinung nicht zum Vertragsgegenstand, wenn dies nicht ausdrücklich vereinbart war. Ist aber der Quellcode mit geschuldet, gehört auch eine entsprechende Beschreibung bzw. Kommentierung dazu. Vor Abnahme bzw. bei Ablieferung, vor allem bei „Besprechung“, muss die 284 Dokumentation vorliegen. Ansonsten kann der Auftraggeber nach §§ 320 ff. BGB vorgehen. Voraussetzung ist jedoch, dass der Auftraggeber – rechtzeitig – seinen Mitwirkungspflichten nachgekommen ist1. Andererseits muss bei einem Projekt die Dokumentation nicht schon immer je (Änderungs-)Schritt vorliegen, sondern kann erst verlangt werden, wenn die Arbeiten an der Software fertig sind2. Auf Pflichtenheft angewandt wird dies heißen, dass aus der fachlichen Spezifikation abgeleitete Dokumente wie etwa der weitere Projektplan erst fertiggestellt werden können, wenn die Spezifikation „steht“, also keine Änderungen mehr erfolgen (sollen). Bei komplexeren Projekten und insbesondere bei solchen, wo der Auftrag- 285 geber häufig Änderungswünsche geäußert hatte, die dann auch realisiert wurden, wird man nicht zeitgleich mit der Fertigstellung der fachlichen Spezifikation auch von der Fertigstellung der übrigen Dokumente ausgehen können. Allerdings wird sich vertreten lassen, dass bei Zeitaufwandprojekten der Zeitaufwand unverhältnismäßig stark ansteigt, wenn die Dokumentation nicht synchron mit entwickelt wird. Dies begegnet dann dem Einwand, dass dieser Aufwand bei weitem nicht so hoch sein würde, als wenn die Dokumentation bei den Änderungen immer mitgezogen werden muss. Der BGH hat für ein Softwareerstellungs-Projekt entschieden, bei dem viele 286 Änderungen vorgenommen worden waren, dass die Dokumentation nicht immer schon mit jedem Schritt und insbesondere nicht mit jedem Änderungsschritt vorliegen muss, sondern erst verlangt werden kann, wenn die Arbeiten an der Software fertig sind3. Dies gibt dem Auftragnehmer insbesondere dann, wenn dies im Vertrag ir- 287 gendwie seine Grundlage gefunden hat, die Chance, den Auftraggeber aufzufordern, nunmehr hinsichtlich der bisherigen Resultate zu erklären, dass keine Änderungen mehr kommen. Dann muss ihm noch angemessene Zeit 1 BGH v. 10.3.1998 – X ZR 70/96 – Warentermingeschäfte, CR 1998 393 i.V.m. BGH CR 1996, 567 und BGH v. 29.3.1996 – II ZR 263/94, MDR 1996, 804 = NJWRR 1996, 989; BGH v. 2.11.1995 – X ZR 93/93, CR 1996, 667. 2 BGH v. 20.2.2001 – X ZR 9/99 – Warentermingeschäft II, CR 2001, 367. 3 BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367.

Schneider

271

C Rz. 288

Verträge

bleiben, die Dokumentation zu erstellen. Im Aktivitäten- und Fristenplan müsste dies berücksichtigt sein. Fehlt es dann an Mitwirkungsleistungen des Auftraggebers, kann sich der Auftragnehmer damit entlasten. Dies macht es um so problematischer, dass bei der Herstellung von Standardsoftware die Mitwirkungsleistungen im Gesetz gar nicht mehr vorgesehen sind. 288

Das OLG Köln hat es1 als zu spät angesehen, wenn der Besteller einer Computeranlage sich erstmals nach geraumer Zeit darauf beruft, dass ihm ein Handbuch für eines der Programme fehle. Es sei dann Verwirkung eingetreten2. Demgegenüber sah es das OLG Hamm nur ausnahmsweise als treuwidrig an, wenn sich der Auftraggeber auf die Nichtlieferung eines Handbuchs beruft3.

289

Relevant wird die Analogie dieser Rechtsprechung zur Realisierung in der Planungsphase, wenn etwa der Auftragnehmer zwar den Auftrag hatte, das Pflichtenheft zu erstellen, dieses aber nicht abliefert und weiter arbeitet. „Vergessen“ wurde das Pflichtenheft nicht4, eventuell wurde dessen Erstellung sogar bereits bezahlt. Die Dokumentation dieses Prozesses steht noch aus. Im Hinblick auf die Rechtsprechung des BGH5 wird man erhebliche Vorsicht walten lassen, bevor man trotz Fehlen der Dokumentation eine konkludente Abnahme annehmen will6. 10. Quellcode

290

Der Quellcode spielt auf den ersten Blick bei der Planung eines Projekts keine Rolle. Auf den zweiten Blick zeigt sich jedoch, dass bei vielen Projekten bereits Software vorliegt bzw. die Auswahlentscheidung getroffen ist und etwa im Rahmen des Prototyping schon mit dieser Software „gearbeitet“ wird, um nämlich den Planungsprozess zu verdeutlichen und Entscheidungen über Varianten zu treffen. Möglicherweise gehen trennbare Bereiche schon in Produktion. Insofern hängt der Kunde bereits von einer auch aus Haftungsgründen näher zu verifizierenden Version der Software ab.

291

Eventuell spielt auch die Qualität des Quellcodes der vorhandenen Software bzw. deren Qualität selbst eine Rolle in dem Sinne, dass der Aufwand, den der Auftragnehmer für das weitere Vorgehen zu planen hat, davon abhängig ist, wie geeignet die Software für Änderungen und Ergänzungen ist7. 1 Orientiert an der Entscheidung des BGH v. 4.11.1992 – VIII ZR 165/91, CR 1993, 203. 2 OLG Köln v. 26.8.1994 – 19 U 278/93, CR 1995, 16. 3 OLG Hamm v. 27.7.1994 – 31 U 57/94, CR 1995, 20. 4 Wie bei BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543 und dazu oben Rz. 36 ff. 5 BGH v. 4.11.1992 und 14.7.1993. 6 Allgemein ohne diese Problematik s.a. OLG München CR 1991, 19 zu Rügepflichten und konkludenter Abnahme). 7 Zur Bewertung der Software unter auch dem Aspekt der „Wartbarkeit“ s. Hoppen, Kap. Q, u.a. Rz. 49, 65 ff., 73, 76, 212 ff.; s.a. Hoppen, CR 2009, 761, 766.

272

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 295 C

Viele Anbieter stellen für solche Zwecke auch Werkzeuge zur Verfügung, 292 mit denen etwas tiefer als an der Oberfläche, aber nicht im eigentlichen Kern der Software, Anpassungen an typische Vorgaben des einzelnen Kunden vorgenommen werden können. Um später belegen zu können, von welchen Prämissen ausgehend die Feinspezifikation vorgenommen worden ist, ggf. auch die damit verbundenen weiteren Planungen, kann es sich empfehlen, den Quellcode sicherzustellen und dafür vorher auch zu analysieren. Dies gilt insbesondere dann, wenn die Software nicht von dem Anbieter stammt, der die Planungsleistung erbringt und auch zu erwarten ist, dass nicht der Hersteller selbst diese Anpassung später realisieren wird. In solchen Fällen empfiehlt sich ggf. dann zumindest nach Offenlegung des Quellcodes eine anschließende Hinterlegung1 und zwar weniger, um darauf später zwecks Bearbeitung Zugriff zu nehmen, als vielmehr zwecks „Beweissicherung“, besser vielleicht „Befundsicherung“. Dabei geht es dann weniger um die Frage des Zustands der Software zum Zeitpunkt der Übergabe (was gleichwohl eine Rolle spielen kann)2, als mehr um die Zuordnung der späteren Veränderungen und der Folgeschäden bei Nutzung. In der Phase der Planung ist bei linearer Phasenabfolge die Frage des Quellcodes noch nicht akut. Bei Anpassung von Software, Erweiterungen und ähnlichen Situationen, die das Vorliegen des Quellcodes implizieren, stellt sich gleichwohl dieses Problem von Beginn.

293

Damit ist noch nicht genau geregelt, was wann herauszugeben ist. Es wäre jedoch innerhalb eines relativ breiten Spektrums Fachleuten klar, was erforderlich ist. Notfalls ist dies mit einem Sachverständigengutachten festzustellen. Besser wäre es, den Quellcode hinsichtlich

294

– – – – –

Umfang und Version(en), Ausgestaltung (Muster) und den Grad an Kommentierung sowie die gegenständlichen Repräsentationen (Datenträger, Listen) zwecks Bestimmtheit auch für evtl. förmliche Verfahren

genau zu beschreiben. Im Ergebnis wird dies dann auf eine Versionsverwaltung hinauslaufen. Auf- 295 grund der während eines Projektes laufend erfolgenden Änderungen bei der Standardsoftware wird sich diese auch dazu empfehlen, bestimmte Leistungspflichten des Auftragnehmers und Mitwirkungen des Auftraggebers bis zur Abnahme nicht zuletzt im Hinblick auf möglichen Mehraufwand und die Mängelhaftung zuordnen und prüfen zu können.

1 S. Kap. L. 2 S. etwa BGH v. 2.7.1996 – X ZR 64/94 – Optikfachgeschäft, CR 1996, 663.

Schneider

273

C Rz. 296

Verträge

II. Die einzelnen Projektschritte und deren Besonderheiten 296

Wie schon mehrfach angedeutet, durchläuft das normale Projekt in der Praxis keineswegs die in der Literatur und auch in den BVB vorgesehenen Stufen, schon gar nicht in linearer Abfolge, allenfalls zirkulär, spiralförmig und häufig unter Weglassung einzelner Stationen. Deshalb wird auch empfohlen, erst gar nicht das Wasserfall-Modell der aufeinanderfolgenden Schritte zu unterlegen, sondern in Meilensteinen zu projektieren und vorzugehen1. Dennoch sollen im Folgenden idealtypisch die einzelnen Stationen/Schritte kurz skizziert werden. 1. Vorstudie, Ist-Analyse

297

Es handelt sich um eine der Phasen, die typischerweise der Auftraggeber im eigenen Hause, vielleicht angeregt durch eine personelle Veränderung oder Anforderungen von Kunden-/oder Lieferantenseite, veranlasst. Gemäß den BVB hat diese Phase einen relativ klar umrissenen Inhalt, nämlich:

298

Die Vorstudie lässt sich wohl leicht mit der Phase der „Verfahrensidee“ bei den BVB-Planung und -Erstellung vergleichen. Diese Phase (1.1 in der BVBNummerierung) umfasst: 1.1.1 Erstellung der Problembeschreibung – auslösende Momente für das Vorhaben – bereits erkannte Schwachstellen – Randbedingungen (finanziell, gesetzlich, personell) 1.1.2 Abgrenzung – zu bearbeitende/nicht zu bearbeitende Aufgaben – Einbettung in die organisatorische und technische Umgebung 1.1.3 Festlegung von Zieldefinition und -bewertung – Geschäftspolitische Ziele – Verfahrenstechnische Ziele – DV-technische Ziele – Prioritätenvergabe für die Ziele Die Phase Ist-Analyse ist bei diesem Schema eine gesonderte Phase, also nachgeschaltet und in der BVB-Nummerierung die Nummer 1.2.

299

Der Begriff „Vorstudie“ klingt gegenüber „Verfahrensidee“ wesentlich anspruchsvoller. Gemeint ist in jedem Falle etwas vorläufiges, rudimentäres und bei weitem nicht so detailliertes, wie dies später dann in der Phase der „Konzepte“ erforderlich sein wird. Was an den Untertiteln bei BVB einleuchtet, ist, dass hier zwei Themenbereiche bereits angeschnitten sind und zwar als die ganz wesentlichen Punkte und gleichzeitig eine „Abgren1 S. z.B. das Muster von Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4, § 1 zu Terminplan.

274

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 302 C

zung“ erfolgt. Eine Problembeschreibung erscheint als Start für das Projekt deshalb besonders einleuchtend, weil in vielen Fällen irgendeine Art von Problemdruck der Auslöser ist, wie dies auch die BVB vorsehen. Dies ist deshalb bemerkenswert, weil in vielen Fällen der eigentliche Auslöser für das Aufsetzen eines neuen Projekts später aus dem Blickfeld gerät. Dabei wäre es bei dieser Art des Starts relativ einfach, dieses Moment mitzunehmen und z.B. in die Präambel des Vertrages zu verpflanzen, am besten schon in die Leistungsbeschreibung. Eng damit verbunden ist der nächste Bereich, die bereits bekannten bzw. er- 300 kannten Schwachstellen. Die Schwachstellenanalyse selbst ist einer späteren Phase vorbehalten, jedenfalls wäre dies eine der möglichen Vorgehensweisen. Sie setzt voraus, dass die Ist-Verhältnisse bereits klar definiert bzw. erhoben sind. Die Angaben, die zu den jeweiligen Eckpunkten erhoben werden, können 301 in diesem frühen Stadium nur relativ vage sein. Übereinstimmung wird in diesem Zusammenhang aber bestehen, dass Einsparungen bzw. Sparpotentiale ermittelt werden, mit denen sich der Aufwand begründen lässt, ebenso auch häufig Vorteile im Zusammenhang mit den angestrebten Zielen, bei BVB unter 1.1.3. Wenn es später dann häufig dazu kommt, dass das Projekt überfrachtet wird, indem schwer miteinander zu vereinbarende bzw. zusätzliche Anforderungen gestellt werden, so hängt dies häufig damit zusammen, dass die in diesem frühen Stadium geäußerten Ziele eher einem Wunschdenken entspringen. Dies macht die Angelegenheit für Berater einerseits sehr attraktiv, weil sie der Geschäftsleitung ökonomisch gut darstellbare Projekt-Pläne vorlegen können, andererseits entsteht zwangsläufig eine gewisse „Weltfremdheit“ des Ausgangspunktes. Dies zeigt sich z.B. in Forderungen wie, dass die neue Software alles können muss, was die bisherige Software konnte, nur besser und schneller. 2. Machbarkeitsstudien, Marktstudien Nicht zuletzt um eine Ausschreibung vorzubereiten oder eine Wahl zwi- 302 schen verschiedenen Konzepten zu ermöglichen, wird es sich empfehlen, sowohl den Markt als auch die möglichen Wege der Zielerreichung zu untersuchen. Letzteres wird vor allem auch den Aspekt erfassen müssen, dass die neue Lösung ggf. mit alten Daten, die zu migrieren sind, arbeiten soll, also vor allem auf den Aspekt der Umstellung abzuheben haben. Wenn es sich um neue Konzepte, schließlich auch neue technische Verfahren handelt, die eingesetzt werden sollen, wird die Machbarkeit auch einzubeziehen haben, inwieweit dies z.B. genügend sicher (gegen Abhören, Ausfälle u.Ä.) ist, inwieweit es schon Erfahrungen auf diesem Gebiet, etwa bei Pilotinstallation, gibt. Die größten Vergleiche können dann dazu verhelfen, abzuschätzen, inwieweit die dort bekannt gewordenen Probleme sich auch bei der eigenen Umstellung ereignen werden. Als besonderer Problempunkt kann sich dabei erweisen, dass die Projektarbeit erfahrungsgemäß länger Schneider

275

C Rz. 303

Verträge

dauert als erwartet und infolgedessen sich über einen längeren Zeitraum hinzieht, was es sehr erschwert, Umstellungen auf einen bestimmten Termin mit kompletter Palette aller Anwendungen vorzunehmen („Big Bang“), während das allmähliche Umstellen mit zum Teil ganz erheblichem Mehraufwand verbunden ist. Wenn neue und alte Systeme miteinander verbunden bzw. verflochten werden sollen, stellen sich ähnliche Probleme. 303

Es dürfte typisch sein, dass solche Studien besonders dann erforderlich werden, wenn sich eine Art Generationswechsel technologisch vollzogen hat und sich nun für die Anwender das Problem stellt, ihrerseits mitzuziehen. Die „Ablöse“ der alten Systeme verursacht ganz andere „Sprünge“ als die allmähliche Entwicklung innerhalb der jeweiligen Technologien. Typisch sind etwa die Umstellungen von den Großrechnern auf Client-/Serversystem u.Ä. gewesen. Für den Auftragnehmer stellt sich diese Phase insofern als vorteilhaft dar, als er hier auf Standard-Recherchen seinerseits, vor allem was den Markt betrifft, zurückgreifen kann. Wenn er schon mehrere entsprechende Umstellungen vorgenommen hat, kann er auch seine Werte einbringen, die er daraus ermittelt hat, um so gewisse Zeitabschätzungen vornehmen zu können. Die so entstehenden Phasen- bzw. Zeitpläne leiden jedoch unter dem Mangel, dass naturgemäß die Besonderheiten der eigenen Unternehmung selbst dann noch nicht richtig berücksichtigt sind, wenn bereits die Schwachstellen analysiert werden. Es fehlt noch an dem Umsetzungskonzept, das hinsichtlich seiner zeitlichen Risiken überhaupt erst noch zu analysieren wäre.

304

Unterstellt man etwa, dass die Vorstudie auch bereits extern vergeben wurde, bietet sich an, die Vorstudie und die Machbarkeitsstudie später auch zur Vertragsgrundlage zu machen. Die Frage, die sich dann vertraglich stellt, ist vor allem, wie sich das spätere Pflichtenheft als Konkretisierung der Anforderungen zu solchen früheren Studien mit ihrem wesentlich allgemeineren Charakter verhält. 3. Grobkonzept

305

Bei den BVB ist das Grobkonzept die Phase nach der Gewinnung der „Forderungen“. Zu dieser Phase gehört nach den BVB in 1.3.1 auch die Bewertung des Ist-Zustandes. Die Ist-Aufnahme selbst dagegen ist Gegenstand einer früheren Phase, die eigens als 1.2 ausgebracht ist.

306

Es dürfte aber wohl inzwischen anerkannt sein, dass in ganz seltenen Fällen die Software für ein Unternehmen völlig neu hergestellt wird. In diesen Fällen wird es sich – nach wie vor – empfehlen, zunächst nach BVB vorzugehen, also zunächst nach der Vorstudie bzw. der Verfahrensidee die Ist-Analyse durchzuführen und dann die Forderungen aufzustellen. Dies verfehlt jedoch in vielen Fällen den Rahmen, der durch die eventuell doch favorisierte Standardsoftware, die dann angepasst werden könnte, gesteckt wird. Es macht wenig Sinn, erst Forderungen aufzustellen, die zwangsläufig hinter-

276

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 310 C

her nicht zu den auf dem Markt befindlichen Softwarepaketen passen, wenn man sich nicht die Software völlig neu entwickeln lassen will. Die Abfolge bzw. die genaue Ausprägung der einzelnen Stufen hängt also ganz wesentlich davon ab, ob etwa bei der Verfahrensidee und der Machbarkeit darauf abgestellt wird, was die Zielsoftware sein soll (völlig neu herzustellen, Standardsoftware mit Anpassungen oder vielleicht nur mit Parametrisierung). Infolgedessen kann es sich auf Grund der Marktgegebenheiten bzw. der heu- 307 tigen technischen Entwicklungen empfehlen, die Grobkonzeption unter Einbeziehung der wesentlichen eigenen Forderungen relativ früh vorzunehmen, was in diesem Fall dann zu einem Zusammenlegen der Phasen 1.3 Forderungen und 1.4 Grobkonzept bezogen auf die BVB bewirken würde. Bei vielen Projekten wird nicht zwischen dem Grob- und dem Feinkonzept 308 unterschieden. Das bedeutet, es gibt nur eine Stufe/einen Schritt, der „Konzept“ genannt werden könnte. Im Sinne der allmählichen, stufenweisen Annäherung an die Konkretisierung macht natürlich ein Grobkonzept Sinn. Auch dieses könnte schon in einen fachlichen und einen technischen Teil zerlegt werden. Der fachliche Teil wäre naturgemäß derjenige, der vom Auftraggeber stammt und dessen Anforderungen ausformuliert, ggf. aber auch schon auf konkrete Software-Pakete projiziert. Das Grobkonzept würde es seinem Anbieter bereits erlauben, den Aufwand und den Weg für die Realisierung zu planen, auch wenn noch ein Konkretisierungsschritt, das Feinkonzept, erforderlich ist. Bleibt es bei dem Grobkonzept als Vorgabe für die Realisierung, wäre der 309 wohl erste Schritt des Auftragnehmers, das fachliche Feinkonzept nachzuholen. Die besondere Schwierigkeit bei Erstellung des Feinkonzepts erst durch den Auftragnehmer, eventuell sogleich in Form des technischen Feinkonzepts besteht darin, festzustellen, inwieweit es sich um Konkretisierungen, also folgerichtige Verfeinerungen der Anforderungen des Auftragnehmers handelt, inwieweit es sich um Erweiterungen bzw. sogar Änderungen – mit der Folge nicht vereinbarter Mehraufwendungen – handelt. Diese Gefahr besteht besonders, wenn die entsprechende Unterlage, also etwa das technische Feinkonzept, nicht noch vom Auftraggeber geprüft werden kann. Einmal scheitert dies häufig an den tatsächlichen Handhabungen, häufig aber wohl noch daran, dass überhaupt nicht eine solche Prüfung vorgesehen ist. Sie würde auch das Risiko in sich bergen, dass eine Art Abnahme stattfindet, was wiederum im Hinblick auf die Folgewirkungen nicht unproblematisch wäre1. Intveen/Lohmann setzen dem Grobkonzept das so genannte „Anforderungsprofil“ gleich2. Sie weisen auch ausdrücklich darauf hin, dass dieses 1 S. OLG Frankfurt v. 12.7.1989 – 9 U 61/88, CR 1990, 585; kritisch dazu Kemper, CR 1991, 641. 2 Intveen/Lohmann, Das IT-Pflichtenheft, CR 2003, 640 (644).

Schneider

277

310

C Rz. 311

Verträge

vom Auftraggeber zu prüfen und gemäß § 640 BGB abzunehmen ist, wenn die Vereinbarung eines Werkvertrages vorliegt1. 311

In der Phase des Grobkonzepts wird es schon häufiger vorkommen, dass ein konkreter Erfolg mit dem Auftragnehmer vereinbart wird, der nämlich darin besteht, eine für die weitere Ausführung durch einen anderen Auftragnehmer oder durch eben diesen Auftragnehmer tragfähige Grundlage zu erstellen. Hier stellt sich nun wieder, sozusagen in Miniform, das Problem des § 651 BGB i.V.m. der passenden Verjährungsregelung. Eine solche Erstellung eines Grobkonzepts – wie auch des so genannten „Pflichtenhefts“ oder auch des „Feinkonzepts“ – wäre ohne weiteres mit den Leistungen gleichzusetzen bzw. unter diese zu subsumieren, wie sie in § 634a Abs. 1 Nr. 1 BGB genannt sind. Allerdings besteht das Problem, dass die Planung für Software erfolgt und insofern wieder das Problem auftaucht, ob es sich insoweit um eine Sache handelt. Es kommt also zunächst die Differenzierung in Betracht, ob ein Erfolg geschuldet ist oder nicht. In letzterem Falle wird Dienstvertragsrecht anzuwenden sein. Ist ein Erfolg geschuldet, kommt Werkvertragsrecht zur Anwendung. Fraglich ist jedoch, welche der Verjährungsregelungen greift, wenn man diese werkvertragliche Planungsleistung als einen nicht als Sache zu qualifizierenden Gegenstand ansieht. Bejaht man, wie oben2, die Sachqualität für Software aber, so ergibt sich der insoweit pragmatisch durchaus wünschenswerte Effekt, dass die Planungsleistungen mit Erfolgscharakter als Werkvertrag zu qualifizieren ist, wenn sie etwa in Form der Erstellung des Grobkonzepts erfolgt. Gleiches gilt für die Erstellung des Feinkonzepts bzw. sonstiger Leistungsbeschreibung.

312

Den werkvertraglichen Charakter wird das Pflichtenheft vor allem dann erhalten, wenn eine bestimmte Struktur bzw. die Themen, zu denen konkrete Ergebnisse vorzulegen und auszuformulieren sind, vereinbart werden. Wie nun ein solches Pflichtenheft, hier in der Form des Grobkonzepts auszusehen hat, ist nicht so recht klar. Einschlägig wäre DIN 699013.

313

Nach Meinung der zitierten Autoren soll aber diese Norm wenig im Hinblick auf die genaue Ausgestaltung nützen, weshalb regelmäßig, wie auch hier, auf die BVB rückverwiesen wird. Diese enthalten in Ziff. 1.5 als eigene Phase das fachliche Feinkonzept und regeln dazu bestimmte Themen, eine Strukturierung, die auch für das Grobkonzept bereits vorbildlich sein könnte, nämlich: 1.5.1 Festlegung des Informationsbedarfs – Umfang des Bedarfs – Zeitpunkt des Bedarfs

1 Intveen/Lohmann, CR 2003, 640 (644). 2 S. Kap. B Rz. 32 ff.; s. aber zur Lit. Kap. B Rz. 110 ff. 3 S.a. Intveen/Lohmann, CR 2003, 640 unter Hinweise auf Müller/Hengstenberg, OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 689 und Lesshaft, CR 1989, 146 (147).

278

Schneider

Rz. 314 C

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

1.5.2

1.5.3

1.5.4

1.5.5

1.5.6

– Ort des Bedarfs – Abstufung des Bedarfs nach Prioritäten – Grobbeschreibung der Datenerhebungsmaßnahmen – Erstdaten – Datenpflege Festlegung der Informationsbasis – Strukturierung der Informationsbasis (logisch) – Mengengerüste – Zusammenhänge/Verknüpfung zwischen Datenbasen Festlegung des Informationsflusses – Definition von Quellen, Zielen und Verzweigungen – Datenschutz-/Datensicherungsmaßnahmen Festlegung der Verarbeitungsregeln – Organisatorische Aspekte des Datenflusses (nicht maschinenbezogene Verarbeitungsschritte) – Transformationsregeln/Algorithmen – Schnittstellen Mensch/Verfahren (Formulare, Bildschirminhalte) Festlegung sonstiger Eigenschaften – Zuverlässigkeit – Benutzerfreundlichkeit – Zeitverhalten – Pflegefreundlichkeit – Übertragbarkeit Festlegung der Verfahrenstest-Spezifikationen – Festlegung der Teststrategie – Festlegung der am Test beteiligten Bereiche – Ermittlung kritischer Stellen im Gesamtverfahren – Festlegung von Testfällen einschließlich erwarteter Resultate – Standardfälle – Extreme, aber korrekte Fälle – Fehlerhafte Fälle1.

Die BVB-Planung und BVB-Erstellung haben nach wie vor Geltung, weil sie 314 noch nicht vollständig durch EVB-IT abgelöst sind. Für komplexere Projekte, die also mehrere Vertragsgegenstände in sich vereinen, bietet sich dadurch ein etwas eigenartiges Bild, dass nämlich die Planung nach der BVBPlanung, die Beschaffung der Software nach den EVB-IT Überlassung erfolgen würde. Die Anpassung der Software hingegen wäre wieder in der BVB-Erstellung geregelt. Es gibt also, jedenfalls bezogen auf EVB-IT, noch kein neues Phasenschema. 1 Zu dieser Aufzählung s.a. Intveen/Lohmann, CR 2003, 640 (645).

Schneider

279

C Rz. 315

Verträge

315

Andererseits gibt es aber seit Februar 2005 das so genannte V-Modell, Vorgehensmodell ursprünglich des Bundesverteidigungsministeriums, also so genanntes V-Modell XT, das das V-Modell 97 ablöst. Die Phasen, die in dem V-Modell beschrieben sind, sind im Wesentlichen solche des Beschaffungsvorgangs. Das V-Modell differenziert im Übrigen, ob der Verwender seinerseits ein Auftraggeber bzw. Anwender oder ein Softwarehaus/Projekteur ist1.

316

Das V-Modell integriert auch die Phasen einer Ausschreibung bzw. der behördlichen Handhabung, Vorgänge, die bei Unternehmungen in etwas anderer Weise ausgestaltet und organisiert werden können. Dadurch ergibt sich zunächst einmal eine äußere Phasenabfolge für das Projekt und dessen Realisierung in groben Zügen aus der Sicht des Managements wie folgt: – – – – – – – –

Genehmigung des Projekts Projektdefinition Anforderungen festgelegt Projekt ausgeschrieben Projekt beauftragt ggf. Änderungsplan festgelegt Abnahme erfolgt Projekt abgeschlossen.

Im Zusammenhang mit dem Änderungsplan können sich Auswirkungen auf die Anforderungen, also insofern Rückkopplungen ergeben. 317

An wesentlichen Festlegungen bzw. Dokumenten ergeben sich2 – Ausschreibung, in Kombination mit den allgemeinen Informationsausschreibungen, Anhängen zu Anforderungen an das zu erstellende (Teil-) System – Vorgaben für das Projekthandbuch und – Vorgaben für das QS-Handbuch, – Angebot mit den jeweiligen Vorgaben zu den oben genannten Themen, – Vertrag – Projektstatus (Bericht) – Lieferung und – Abnahme als Pendant zu den oben genannten Phasen. Nach der Abnahmeerklärung folgt noch ein Projektabschlussbericht.

1 Zum V-Modell XT s. die Dokumentation der Auftaktveranstaltung an der TUMünchen, Broy/Rausch/Sihling/Kuhrmann, Tagungsband TUM-10508, Mai 2005; s.a Kap. H Rz. 53 ff., Kap. Q Rz. 125. 2 Zur Methodik für Anlagen und bestimmte Management-Ebenen unter ITIL (IT Infrastructure Library) s. Söbbing, Die Bedeutung der ITIL für die Vertragsgestaltung, ITRB 2005, 97.

280

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 321 C

Aus der Sicht des Auftragnehmers stellt sich das V-Modell etwas anders dar:

318

Ab der Beauftragung wird unterschieden bzw. werden folgende Schritte durchlaufen: – Projektbeauftragung – Projektspezifizierung – Systementwurf – Feinentwurf – Realisierung der Systemelemente – Integration als System – Lieferung – Abnahme Wobei wieder spiegelbildlich auch ein Änderungsplan bzw. dessen Festlegung vorgesehen ist, der Rückwirkungen auf die Spezifizierungen des Systems hat. Damit wird nicht nur eine andere Terminologie geschaffen, sondern auch 319 eine strukturell etwas andere Vorgehensweise vorgeschlagen, die sich allerdings nicht grundlegend von den der BVB zugrunde liegenden Schritten unterscheidet. Was aber bei dem V-Modell wesentlich stärker hervortritt, ist die Dynamik des Projekts, in dem im jeweiligen Projektstatus die Themen zu behandeln sind: – – – – – – –

Problem- und Änderungsstatistik Aktuelle Risiken und Risikomaßnahmen Planung für den nächsten Berichtszeitraum Planungsabweichungen Management-Übersicht Projektergebnisse Projektbewertung

Mit diesen Informations-Werkzeugen ist es möglich, auch wenn man nicht 320 das V-Modell zugrunde legt, in einem Vertrag der dynamischen Komponente des Projekts, insbesondere in Kombination mit dem Aktivitäten- und Fristenplan, mehr Informationsgehalt zu verleihen und damit auch während des Projekts bereits zu festgelegten Schritten festzustellen, inwieweit bereits Abweichungen vom Projektplan, der Vertragsgrundlage wurde, bestehen und wie die Aussichten im weiteren Vorgehen sind, dass das Projekt Erfolg hat bzw. noch im Termin- und Finanzrahmen bleibt. Die Gefahr, die allerdings damit verbunden ist, ist, dass man dann etwa auf 321 der Projektebene den Plan den Gegebenheiten anpasst. Auf Dauer kann auf diese Weise eine Art zweiter Vertrag entstehen, der mit dem ursprünglichen Vertrag nicht mehr konform ist. In diesem zweiten Vertrag sind die Fristen disponibel, werden auch eventuell Budgets erweitert, wobei unklar ist, inwieweit hierzu Autorisationen bestehen. Im Extremfall kann, wenn es etwa Schneider

281

C Rz. 322

Verträge

um das gerichtliche Einklagen von entweder Honorarforderungen oder Schadensersatz geht, sich das Gericht auf den Standpunkt stellen, dass man einvernehmlich den ursprünglichen Vertrag angepasst bzw. verlassen und einen neuen kreiert und gelebt habe. Wenn dieser Effekt vermieden werden soll, so sind unausweichlich im Anschluss an bestimmte Klassen von Mitteilungen im Rahmen des Projektstatusberichts auch Eskalations-Prozeduren einzuleiten, die auf zuständiger Ebene dann die Entscheidung herbeiführen und evtl. auch zu Vereinbarungen führen, ob und wie der Vertrag fortgesetzt werden soll. 322

Insoweit, als ggf. vertragliche Vorgaben oder auch Verpflichtungen der Auftraggeberseite oder selbst Verpflichtungen der Auftragnehmerseite die Einhaltung von ISO 9100 verpflichten, ist das V-Modell als Vorgehensmodell konform. Das heißt, dass das V-Modell als Prozessmodell angesehen wird, mit dessen Hilfe Projekte gemäß dieser Norm auch abgewickelt werden können1.

323

Das vielleicht Besondere auch für den Projektplan i.S.e. Netzplanes ist, dass die entsprechenden Vorgaben nicht nur mit einer einheitlichen Terminologie verbindlich gemacht werden, sondern auch jeweils eingeteilt sind in die Aktivitäten und deren Ergebnisse, die hier „Produkte“ genannt werden. Die oben genannten Phasen entsprechen den Aktivitäten des so genannten Submodells Systemerstellung und können insofern nochmals aufgelistet werden als – – – – – – – – –

324

System-Anforderungsanalyse System-Entwurf Software-Hardware-Anforderungsanalyse Software-Grobentwurf Software-Feinentwurf Software-Implementierung Software-Integration Systemintegration Überleitung in die Nutzung

Bei der Qualitätssicherung gibt es ebenfalls noch eine weitere Unterteilung, nämlich – – – –

QS-Initialisierung Prüfungsvorbereitung Prozessprüfung von Aktivitäten Produktprüfung

1 Zu entsprechenden Einschätzungen s.a. die Nachweise bei IABG, Adresse: www.v-modell.iabg.de; bei GI gibt es eine Fachgruppe zu Vorgehensmodellen, die auch auf ihrer Homepage regelmäßig berichtet: www.vorgehensmodelle.de; s.a. bei Fraunhofer Gesellschaft: www.iese.fhg.de/Vmodell.

282

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 328 C

– QS-Berichtswesen – Weitere Submodelle umfassen das Konfigurationsmanagement und speziell noch das Projektmanagement. Diese zusätzliche Komponente erscheint ganz wesentlich auch im Hinblick auf eine eventuell externe Vergabe. Die Aktivitäten, die hierbei zu leisten sind: – – – – – – – – – – – – – –

325

Projektinitialisierung Vergabe/Beschaffung Auftragnehmer-Management Scheinplanung Kosten-/Nutzenanalyse Durchführungsentscheidung Risikomanagement Projektkontrolle und -steuerung Informationsdienst/Berichtswesen Schulung/Einarbeitung Bereitstellung der Ressourcen Vergabe von Arbeitsaufträgen Einweisung der Mitarbeiter Projektabschluss

Für jedes dieser Submodelle sind dann die Produkte noch im Einzelnen festgelegt bzw. festzulegen, also deren Ergebnisse1. Mit diesen Einteilungen lässt sich auch das V-Modell noch für die Privatwirtschaft konkretisieren und auch im Hinblick auf Entwicklungsaufträge noch etwas anreichern. Dazu gehört zudem, dass Bedrohungs- und Risikoanalyse sowie die IT-Sicherheit jeweils in einzelnen Anwenderforderungen noch explizit ausgeführt werden.

326

Die Projektmethodik und die Komplexität des Projekts müssen natürlich 327 letztlich im Hinblick auch auf den Aufwand in einem angemessenen Verhältnis zueinander stehen. Insofern variieren zumindest dort, wo nicht starre Muster vorgegeben sind, also insbesondere in der Privatwirtschaft, die benutzten Modelle. Bei diesem Pragmatismus lassen sich wiederum aber einige „Todsünden“ des Projekts, die immer wieder vorkommen und die wahrscheinlich zu einem hohen Prozentsatz am Scheitern von Projekten beteiligt sind, feststellen. 4. Aktivitäten- und Fristenplan Entsprechend den vorgestellten Schemata wird sich gleich zu Beginn der Vergabe der Erstellung des Pflichtenhefts bzw. des Planungsprojekts emp1 Hier aufgelistet nach iese.fhg.de.

Schneider

283

328

C Rz. 329

Verträge

fehlen, einen solchen Aktivitäten- und Fristenplan aufzustellen (s.a. Kap. G Rz. 197 ff., Kap. H). Dieser setzt sich dann auch in der Realisierungsphase fort. Ein wichtiges Ergebnis der Planungsphase könnte gerade sein, einen solchen Projektplan aufzustellen, der naturgemäß von einem noch unbekannten Anfangsdatum (nämlich der Vergabe der Realisierung) ausgeht, wenn diese nicht schon beauftragt ist. 329

Dieser Projektplan würde neben den einzelnen Schritten zur Umsetzung des Pflichtenhefts als „Aktivitäten“ des Auftragnehmers auch die Mitwirkung des Kunden bereits umschreiben können. Insofern würde sich dieser Plan auch dafür eignen, zusätzlich zum Pflichtenheft als Vertragsbestandteil bei der Realisierung verwendet zu werden.

330

Naturgemäß ist der Präzisionsgrad eines solchen Planes für die erste Zeit, also die in naher Zukunft liegenden Schritte besser und höher als für die dann folgenden. Insofern muss bei einem solchen Projektplan auch eine gewisse Verfeinerung im Laufe des Projekts erst erfolgen. Dies ist eine wichtige vertragliche Regelung, wie genau diese Verfeinerung während des Projektes stattfindet und wer die „Oberherrschaft“ über die Führung dieses Aktivitäten- und Fristenplans hat. Dabei verkennen manche Anbieter, dass sie dann, wenn sie ohnehin die werkvertragliche Erfolgshaftung für die Realisierung übernommen und insofern das Projekt zu steuern haben, eigentlich auch die Hoheit über den Projektplan und dessen weitere Gestaltung wahrnehmen können. Umgekehrt übersehen manche Auftraggeber, dass sie sich zwar im Vertrag die Oberhoheit über den Projektplan als Aktivitätenund Fristenplan ausbedingen können, möglicherweise auch zugleich die Etablierung von gemeinsamen Entscheidungsgremien oder sogar einem allein entscheidenden Gremium des Auftraggebers, womit sie aber gleichzeitig die Erfolgshaftung dem Auftragnehmer wieder abnehmen. Insofern sind solche Wünsche des Auftraggebers für ihn im Ergebnis oft eher kontraproduktiv. Am Ende gar besteht eine Kooperation i.S.e. BGB-Gesellschaft und die Rechte würden beiden Parteien zustehen.

331

Es wandelt sich zumindest der werkvertragliche zum dienstvertraglichen Charakter. Dies ist nicht unerheblich im Hinblick auch auf die Frage, wie das Leistungsstörungsrecht ausgeprägt sein kann, dazu sogleich.

III. Verjährung, Leistungsstörungen 1. Differenzierungen hinsichtlich des Gesamtumfangs des Vertrages 332

Die Frage der Abnahme bzw. Abnahmefähigkeit der Leistungen des Auftragnehmers hängt stark davon ab, ob die Erstellung des Pflichtenhefts/der fachlichen Feinspezifikation ein eigener Vertrag ist, der separat von der Realisierung vereinbart wird. Dies kann etwa in der Form geschehen, dass man dem Auftraggeber eine Art Ausstiegsrecht gewährt, nämlich das Projekt mit der Fertigstellung der fachlichen Feinspezifikation und deren Beprei284

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 334 C

sung zu beenden. In diesen Fällen wären dann die gesamten Aufwendungen gemäß Vereinbarung vom Auftraggeber voll zu zahlen. Weiterhin wird aber vereinbart, dass bei Vergabe der Realisierung an den Auftragnehmer – ggf. nach „Abspecken“ i.S.v. oben Rz. 201 f. – ein Teil der Leistungen auf den Preis, der dann angegeben wird, angerechnet wird. Jedenfalls wird es auf die Vertragsgestaltung ankommen, ob also eine separate Abnahme als Ergebnis des Planungsprozesses vorzusehen bzw. erforderlich ist oder nicht. Hierbei besteht ein Dilemma im Bereich des Auftraggebers. Die Abnahme 333 der fachlichen Feinspezifikation führt dazu, dass im Verhältnis zum Auftragnehmer als konkreten Vertragspartner die Beweislast „kippt“. In der Folge ist der Auftraggeber ggf. verpflichtet, das Vorliegen von Mängeln nachzuweisen. Dies ist bei Pflichtenheften, die noch nicht ausgeführt sind, sehr schwer. Infolgedessen führt die Abnahme, die an sich folgerichtig aus der werkvertraglichen Konstruktion abzuleiten ist, zu einer Rechtsstellung des Auftraggebers, die dieser eigentlich nicht wünscht. Für ihn wäre Maßstab der Abnahmefähigkeit, dass die Realisierung des Pflichtenheftes erfolgreich ist, dass also die Umsetzung des Pflichtenhefts möglich ist und die Realisierung nicht durch Mängel des Pflichtenhefts behindert oder unmöglich ist. Dies könnte auch so individuell vereinbart werden. In diesem Zusammenhang würde es sich empfehlen, wenn erst noch etwa 334 im laufenden Projekt der Softwareerstellung zunächst im obigen Sinne eine Feinspezifikation zu erstellen wäre, und sei sie auch nur als Delta-Pflichtenheft als Änderungen gegenüber vorhandener Software im Rahmen der Anpassung, dass der Auftraggeber sich nur die Freigabe ausbedingt bzw. der Auftragnehmer nur diese fordert. Freigabe ist kein juristischer Terminus. Er sollte ausdrücklich von der „Abnahme“ abgesetzt werden. Mit der Freigabe wäre Folgendes verbunden: Der Auftraggeber lässt sich, etwa ähnlich dem oben zitierten Modell der BVB-Planung in einer Besprechung, besser vielleicht in einem Workshop die Einzelheiten des Planungsergebnisses vortragen, so dass die Leistungen für ihn möglichst verständlich sind. Auch kann eine für das Management geeignete Kurzfassung vorangestellt werden, die das Verständnis erleichtert. Der Auftraggeber kann, soweit hier fachliche Äußerungen festgehalten sind, die Übereinstimmung mit seinen Forderungen prüfen. Dies wird umso schwieriger, je detaillierter die Planungsergebnisse sind und je mehr sie sich schon i.S. technischer Spezifizierung auf die projizierte Software erstrecken. In diesem Sinne bedeutet die Freigabe, dass die Erläuterungen des Auftragnehmers ergeben haben, dass der Auftraggeber keine erheblichen Abweichungen gegenüber seinen Forderungen, die Vertragsgrundlage geworden waren bzw. die im Rahmen der Besprechungen verbindlich geworden sind, feststellen konnte. Sie bedeuten aber nicht, dass hier eine Abnahme i.S.v. § 640 BGB mit deren Wirkungen erfolgt. Den Beweis sozusagen, dass die Umsetzbarkeit des Pflichtenhefts gegeben ist, erbringt dann der jeweilige Auftragnehmer durch die Realisierung.

Schneider

285

C Rz. 335

Verträge

335

Lässt sich der Auftragnehmer auf diese Herabsetzung der Pflichten des Auftraggebers nicht ein, nimmt der Auftraggeber also ab, wäre es für diesen wünschenswert, eine solche Abnahme auf die Mängel zu begrenzen, die im Rahmen einer Erläuterung für den Auftraggeber erkennbar waren. Zumindest die Verjährungsfrist für die Mängel des Pflichtenhefts sollte so lange nicht laufen bzw. sollte so erstreckt werden, bis durch die Fertigstellung sich die Eignung des Pflichtenhefts erwiesen hat. Wenn man die oben angedeutete verschuldensunabhängige Aussage, dass das Pflichtenheft zur Realisierung geeignet ist, berücksichtigt, käme es dann für die Dimensionierung des Schadensersatzes bei Scheitern der Realisierung nicht auf die Abnahme des Pflichtenhefts an. Diese wäre also kein Hindernis bei der Geltendmachung des eventuellen Schadens.

336

Ergänzend oder auch in gewissem Sinne alternativ könnte sich der Auftraggeber gerade dann, wenn derselbe Auftragnehmer auch die Realisierung vornehmen soll, der für ihn das abzunehmende Pflichtenheft erstellt hat, ausbedingen, dass zwischen den beiden Leistungsbereichen eine nicht nur wirtschaftliche, sondern auch juristische Einheit besteht. 2. Werkvertragliche Einordnung1

337

Das Problem zu Lasten des Auftragnehmers ist, dass aller Wahrscheinlichkeit nach bei der Einordnung als Werkvertrag für die Planung hinsichtlich der Verjährungsfrist für Mängelansprüche § 634a Abs. 1 Nr. 3 BGB gilt. Damit verjähren die Ansprüche innerhalb der regelmäßigen Verjährungsfrist. Dies ist grundsätzlich deshalb nicht so problematisch, weil selbst in AGB die Frist als solche auf ein Jahr verkürzt werden könnte (§ 309 Nr. 8b ff. BGB). Das Problem besteht darin, dass die Verjährung nicht mit der Abnahme bzw. Teilabnahme beginnen kann. Eine abweichende Vereinbarung dürfte in AGB des Auftragnehmers zu Lasten des Auftraggebers unwirksam sein. Individualvertraglich ließe sich dies natürlich vereinbaren.

338

Der Auftraggeber hat jedoch ein völlig anderes Interesse. Für ihn ist die Mangelhaftigkeit des Planungswerks grundsätzlich wesentlich schwerer zu erkennen als die Mangelhaftigkeit der Software, die anhand dieses Planungswerks erstellt bzw. angepasst werden soll. Infolgedessen hat der Auftraggeber hier das Interesse, eine längere Verjährungsfrist zu erhalten bzw. auch dann noch Mängel des Planungswerkes geltend machen zu können, wenn man sich hinsichtlich der Software bereits ans Werk gemacht hat. Bei der regelmäßigen Verjährungsfrist beginnt die Mangelhaftigkeit im Prinzip ab Kenntnis bzw. Kennen müssen. Dieses Kennen müssen könnte zugunsten des Auftraggebers wohl erst dann bestehen, wenn sich etwa auf Grund des Realisierungsprozesses diese offen zeigt.

339

Infolgedessen wird wiederum der Auftragnehmer gut daran tun, einerseits in seinen AGB nicht auf die Abnahme des Planungsprozesses abzustellen, 1 Ulmer, Verjährung der Mängelansprüche beim Werkvertrag, ITRB 2003, 162.

286

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 342 C

sondern zu versuchen, Individualvereinbarungen diesbezüglich zu erlangen, andererseits durch entsprechende Vorführung, Präsentation u.Ä. dem Auftraggeber deutlich zu machen, was das Ergebnis des Planungsprozesses ist, so dass insoweit eine volle Kenntnis des Umfangs der Planung beim Auftraggeber erzeugt wird. Dies dürfte allerdings in der Praxis nicht unerhebliche Schwierigkeiten bereiten, da eine Schulung im Rahmen der Planungsunterlagen selten vorgenommen wird. Diese wäre aber wohl Voraussetzung für eine entsprechende „Kenntnis“ und dann Zurechnung im Rahmen einer Abnahme der Planung (§ 640 Abs. 2 BGB). 3. Leistungsstörungen bei dienstvertraglichen Regelungen1 Die vertragstypologische Einordnung des Vertrages zur Erstellung des 340 Pflichtenhefts ist offen. Bei Vergleichbarkeit mit Baurecht und Architektenplanung wird Werkvertrag anzunehmen sein2. Für den IT-Bereich ist dies nicht so klar3. Bis zur Schuldrechtsmodernisierung konnte davon ausgegangen werden, dass der Dienstvertrag eine für den Auftragnehmer wesentlich günstigere Regelung ist als etwa Werkvertrag. Dies hat sich mit der Schuldrechtsmodernisierung insofern geändert, als die Nacherfüllung eine Art Puffer bei Schlechtleistung bzw. mangelhafter Leistungen darstellt. Diesen Puffer gibt es aber nur i.V.m. den Regelungen bei Kauf- und Werkvertrag (bei Miete ist er anders geregelt). Bei Dienstvertrag fehlt eine entsprechende Regelung. Infolgedessen greifen die Regeln der §§ 275 ff. bzw. 280 ff., 320 ff. BGB unmittelbar. Fristen bzw. Nachfristen muss danach der Auftraggeber nur in ganz begrenzten Fällen setzen. Bei der vertragstypologischen Einordnung als Dienstvertrag realisiert sich 341 das bereits angesprochene Problem, dass Dienstvertragsrecht keine dem Kauf- und Werkvertragsrecht entsprechende Verweisung in das allgemeine Leistungsstörungsrecht enthält. Demnach sind einerseits die §§ 280 ff. bzw. 320 ff. BGB heranzuziehen, andererseits die Spezialregelungen, vor allem § 626 BGB. Dieser hat Vorrang gegenüber § 314 BGB. Im Hinblick auf eine Schadenersatzforderung kann erforderlich sein, gem. § 281 Abs. 1 Nr. 1 BGB, noch eine Frist zu setzen, die aber gerade den Lauf der Frist nach § 626 BGB hemmen würde. Der Vorrang des Anspruchs auf Nacherfüllung entfällt bei Dienstvertrag, 342 weshalb oben die Rede davon war, dass die Ansprüche des Kunden ungepuffert bestehen. Der Lieferant/Auftragnehmer würde sich deshalb gerne in seinen AGB ein entsprechendes Recht der weiteren Andienung zumindest in den Fällen ausbedingen, in denen dies für den Kunden zumutbar wäre. In 1 S. für Pflege Bartsch, NJW 2002, 1526. 2 S. Palandt/Sprau, 72. Aufl., Einf. vor § 631 BGB Rz. 17, nur ausnahmsweise Dienstvertrag, s.a. Palandt/Sprau, 72. Aufl., Einf. vor § 611 BGB Rz. 17. 3 OLG Köln v. 22.10.1987 – 1 U 41/84, CR 1988, 734: Organisationsberatung ist Dienstvertrag; OLG Frankfurt v. 12.7.1989 – 9 U 61/88, CR 1990, 585 Werkvertrag, ablehnend Mehrings, CR 1990, 587, kritisch Kemper, CR 1991, 641.

Schneider

287

C Rz. 343

Verträge

Fällen, die nicht als wichtiger Grund i.S.d. § 626 BGB anzusehen sind, würde dies im Hinblick auf den Schadenersatz „passen“. Fraglich ist die Kompatibilität mit Rücktritt, weil insoweit das Dienstvertragsrecht mit der ordentlichen und der außerordentlichen Kündigung Spezialregelungen vorsieht. Solange kein wichtiger Grund vorliegt, wäre es wohl akzeptabel, in AGB wirksam, wenn der Anbieter sich eine entsprechende Frist ausbedingt. Für den Fall eines wichtigen Grundes erscheint dies nicht mehr akzeptabel. 4. Die Rechtseinräumung beim Planungsvertrag und bei agilem Vorgehen 343

Die Rechtseinräumung darf als eines der Stiefkinder betrachtet werden, was den Planungsvertrag betrifft. Dies liegt wohl u.a. daran, dass beide Parteien gar nicht so sehr darüber nachdenken, wem das Pflichtenheft gehört, da es ohnehin in Software umgesetzt werden soll und die Rechte an der Software geregelt sind. Je stärker die beiden Prozesse/Phasen voneinander getrennt werden und umso wahrscheinlicher es ist, dass der Auftraggeber die Ergebnisse des Planungsprozesses eventuell auch gegenüber Dritten verwenden will oder nur gegenüber diesem (etwa im Rahmen der Ausschreibung bzw. Fremdbeauftragung), umso wichtiger wird für ihn, dass er dafür die erforderlichen Rechte erhält.

344

Wenn keine expliziten Regelungen getroffen sind, wird man im Rahmen der Zweckübertragungslehre davon ausgehen müssen, dass anhand der vorhandenen Anhaltspunkte zu interpretieren ist, wie groß wohl der Umfang der mit der Leistung einhergehenden Rechtseinräumung sein könnte. Wird etwa ausdrücklich die Verwendung zu Ausschreibungszwecken erwähnt, dann würde sich die Rechtseinräumung auch hierauf erstrecken. Ob allerdings eine Ausschließlichkeit der Rechtseinräumung damit verbunden wäre, darf bezweifelt werden. Eine Publikation über die Ausschreibung hinaus wäre eventuell auch nicht gestattet. Es besteht die Gefahr zu pauschaler Formulierungen, evtl. auch zu umfassend1. Das Pflichtenheft wird nicht vom Schutzumfang der §§ 69a ff. UrhG erfasst2, wohl aber als Sprachwerk und technische Darstellung.

345

Manche Anbieter scheuen sich auch, weitergehende Rechte an den Ergebnissen einzuräumen, weil sie in die Arbeiten Standardtexte einfließen lassen, die sie bei anderen Projekten wieder verwenden wollen. Insofern könnte sich eine sehr ausdifferenzierte Regelung empfehlen, wonach der Auftragnehmer deutlich macht, welche Standards er einbringt bzw. welche Leistungen er auch anderweitig verwenden will, vorausgesetzt, der Auftraggeber ist damit so einverstanden. Zusätzlich wäre zu regeln, an welchen 1 S. etwa LG Mannheim v. 5.12.2011 – 7 O 442/11, schließt sich an OLG Hamburg v. 1.6.2011 – 5 U 113/09, K&R 2011, 598; s.a. BGH v. 20.1.2011 – I ZR 19/09, ZUM 2011, 735 (Übersetzer); BGH v. 7.10.2009 – I ZR 38/07, ZUM 2010, 61 – Talking to Addison; BGH v. 23.2.2012 – I ZR 6/11 – Kommunikationsdesigner. 2 S.a. Schricker/Loewenheim, 4. Aufl., § 69a UrhG Rz. 5.

288

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 349 C

Teilen der Auftragnehmer keine Rechte besitzen soll bzw. keine Rechte mehr außer dem Persönlichkeitsrecht bei ihm verbleiben. Eventuell wäre auch klarzustellen, dass selbst dann, wenn der Auftraggeber nicht alle Rechte an der Software erhält, jedenfalls der Auftragnehmer den Gesamttext auch seinerseits nicht anderweitig verwenden kann. Schließlich wäre auch daran zu denken, dass die Frage des Übergangs der Rechte noch genauer bestimmt wird. Danach hätte der Kunde zunächst nur am einzelnen Exemplar des Pflichtenhefts ein einfaches Nutzungsrecht, so dass er eine Abnahme nach entsprechender Lektüre vornehmen kann. Die gesamten sonstigen im Vertrag noch geregelten Rechte gehen aber erst dann auf ihn über, wenn die Vergütung voll bezahlt ist1. Die Formulierung ist keineswegs trivial, weil die Gefahr besteht, dass der Auftraggeber bei schlechter Regelung sich darauf beruft, dass er keine Abnahme vornehme, solange ihm nicht alle Rechte an dem Pflichtenheft zustehen.

346

Die für die öffentliche Hand konzipierten und damit bei ihren Forderungen 347 eher zurückhaltenden BVB-Planung, sehen in § 5 eine Regelung der Nutzungsrechte vor, die relativ weitgehend ist. Die Regelung ist besonders interessant, weil sie nicht zuletzt auf den Zeitpunkt der Entstehung oder Bearbeitung abstellt: „1. Der Auftraggeber erhält mit der Entstehung oder Bearbeitung, soweit im Ausnahmefall nichts anderes vereinbart ist, das ausschließliche, unwiderrufliche und übertragbare Recht, die im Rahmen dieses Vertrags erbrachten Leistungen auf sämtliche Nutzungsarten zu nutzen. Er hat insbesondere das Recht zu vervielfältigen und ändern. Das Verfügungsrecht des Auftragnehmers an eingebrachten oder entwickelten Modellen, Methoden, Bausteinen u.Ä. bleibt unberührt.“

Diese Rechtseinräumung berechtigt den Auftraggeber allerdings nur, ande- 348 ren Stellen wie öffentliche Verwaltung und privatrechtlich organisierte Datenzentralen nach der Abnahme ein einfaches, nicht übertragbares Nutzungsrecht an diesen Planungsleistungen einzuräumen. Die Restriktionen der öffentlichen Verwaltung erstrecken sich also zunächst nicht auf den Umfang der Rechtseinräumung, sondern auf dessen Ausübung. Wenig beachtet wird aber, dass hier auch bereits auf die Entstehung ab- 349 gestellt wird, was nicht zuletzt auch im Hinblick auf insolvenzrechtliche Überlegungen von erheblichem Interesse ist. Ist diese Leistung auch schon vergütet, ist eigentlich insoweit das Gegenseitigkeitsverhältnis bereits nicht mehr zur Disposition des Insolvenzverwalters.

1 Zu diesem Ansatz im Hinblick auf Software s. vor allem Karger, ITRB 2001, 67; Karger, CR 2001, 357; Karger, ITRB 2004, 208; zu Rechtseinräumung s. Kap. A Rz. 151 ff.

Schneider

289

C Rz. 350

Verträge

5. Anlagen, Rangfolge der Anlagen 350

Auf ein relativ trivial erscheinendes Problem sei eingangs hingewiesen. Es geht um das Verhältnis von Anlagen im Vertrag und dem Vertrag selbst. Es ist üblich, vorsorglich hinsichtlich des Vertrages den Vorrang von dessen Geltung gegenüber den Anlagen festzulegen1. Praktisch bedeutet dies aber, dass die Leistungsbeschreibung, die „nur“ Anlage ist, Nachrang gegenüber dem Vertrag hat. Damit kann unklar sein bzw. werden, welche Regelung den Rang einnimmt, der im Gesetz für die vertragliche Beschaffenheit vorgesehen ist, die entsprechende Klausel im Vertrag mit „Vertragsgegenstand“ oder die Anlage hierzu, das „Pflichtenheft“.

351

Bei einzelner schrittweiser Vergabe von Leistungen aus dem Gesamt-Planungsprozess wäre jeweils das Ergebnis der Stufe davor die Grundlage für die Leistungserbringung. Da sich die Schritte in der Abfolge jeweils konkretisieren, wäre das Pflichtenheft i.S.d. fachlichen Feinspezifikation das Ergebnis des Planungsprozesses und die richtige Vorlage für die Realisierung. Die einzelnen Stufen lassen sich eigentlich nicht als Vorgabe koppeln. Nicht i.S.d. Stufenfolge wäre es also, sowohl das Pflichtenheft als auch – beispielsweise – die Bedarfsanalyse als Leistungsbeschreibung zu referenzieren. Die Idee, auch der Bedarfsanalyse noch zu Wirkung bei der Realisierung zu verhelfen, weil man als Auftraggeber nicht sicher ist, ob die Feinspezifikation alles abdeckt, leuchtet ein. Richtigerweise bildet der Ersatz für diese Überfrachtung die Gewähr, dass der Auftragnehmer die Bedarfsanalyse und die darauf folgen Schritte richtig und vollständig gestaltet hat. Dementsprechend wäre ein Leistungsmerkmal jeder Stufe, die vorige richtig und vollständig, etwa noch modifiziert durch Workshop-Ergebnisse und CR, umzusetzen. Eine Abnahme durch den Auftraggeber wäre zwar für den Auftragnehmer wünschenswert, verwässert aber den Gedanken. 6. Folgeschäden

352

Die Beratung mit Empfehlung zur Auswahl eines EDV-Systems war vom OLG Frankfurt2 gleich einem Gutachten als Werkvertrag eingeordnet worden. Die Verjährung der Ansprüche des Kunden wegen der Falschberatung erfolgte gemäß OLG Frankfurt nach § 638 BGB a.F. Tatsächlich hat das Gericht aber diesen Schaden als Mangelfolgeschaden und zwar als „nächsten“ Mangelfolgeschaden angesehen. Dies stieß auf erhebliche Kritik etwa bei Mehrings3, der darauf hinweist, dass der BGH in der auch vom OLG Frankfurt zitierten Entscheidung im 67. Band auf Seite 8 f. für Mangelfolgeschäden aus Schätzungen, Gutachten und Auskünften, wenn auch nur eher beiläufig, die Anwendung der §§ 635, 638 BGB a.F. ausgeschlossen hat, weshalb insoweit nur eine Haftung wegen positiver Vertragsverletzung und da1 S. vor allem zur besonderen Reihenfolge Bartsch, Vertrag über ein Softwareprojekt, 9. Aufl., III.H.4; § 1 (3); Redeker, ITRB 2006, 242. 2 OLG Frankfurt v. 12.7.1989 – 9 U 61/88, CR 1990, 585. 3 Mehrings, CR 1990, 587.

290

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 356 C

mit die 30-jährige Verjährung, § 195 BGB, in Betracht kam. Diese BGH-Entscheidung lässt sich zwar relativ leicht auf neues Recht „hochrechnen“. Die Kardinalfrage bleibt aber, ob es sich tatsächlich um „Mangelfolgeschäden des Gutachtens“ handelt und wie solche ggf. nach neuem Recht beurteilt werden. Folgt man der Ansicht des OLG Frankfurt hinsichtlich § 638 BGB a.F., so 353 bestünde grundsätzlich bzw. auf den ersten Blick kein Hindernis, insoweit § 634a Abs. 1 Nr. 1 BGB anzuwenden („Erbringung von Planungs- oder Überwachungsleistungen“). Allerdings würde dabei übersehen, dass diese Leistungen „hierfür“ erfolgen müssen, also es sich insoweit um eine Sache handeln muss, als der Gegenstand der Planungsleistung eine Sache ist. Somit stellt sich wieder die Problematik, ob überhaupt Werkvertragsrecht anwendbar ist, auch wenn man den Erfolgscharakter bejaht, da insoweit, bei Bejahung der Sachqualität, Kaufrecht Anwendung finden würde (§ 651 BGB1). Die Unterschiede sind nicht mehr so enorm, was die Dauer der Verjäh- 354 rungsfrist als solche betrifft, nämlich zwei Jahre nach § 634a Abs. 1 Nr. 1 BGB, drei Jahre nach Abs. 1 Nr. 3 i.V.m. § 199 BGB. Beachtlich ist jedoch der Unterschied hinsichtlich des Beginns der Laufzeit. Über die völlig andersartige Regelung des Beginns kann sich die Verjährungsfrist erheblich verlängern. Dieses ist möglicherweise von besonderer Bedeutung, wenn – wie häufig – die Verjährungsfrist als solche vom Anbieter verkürzt wird, etwa in AGB auf ein Jahr, was grundsätzlich möglich ist (§ 309 Nr. 8b ff. BGB). Typische Varianten der Falschberatung können sein: – – – – – –

355

falsche Dimensionierung der Hardware ungeeignete Software erhöhter Wartungsaufwand erhöhter Pflegeaufwand unwirtschaftliche Bedienung Inkompatibilität.

Die beiden letzten Varianten sind nicht nur als solche schwer zu verifizie- 356 ren, sondern auch schwerlich in ihrer Wirkung, was evtl. Schaden betrifft, quantifizierbar. Der Maßstab wird in der Regel der Differenzschaden der Ersatzbeschaffung sein, was aber eher Mangelschaden als Mangelfolgeschaden darstellen würde.

1 S. Kap. B Rz. 1 ff., 106 ff.

Schneider

291

C Rz. 357

Verträge

IV. Vorschläge zur Vertragsgestaltung, Beispiele 1. Gesetzliche Vertragstypen und individuelle Ergänzungen 357

Anbieterseitig werden typischerweise im Hinblick auf die Beratung des Anwenders dienstvertraglich orientierte AGB-Texte verwendet, die eine Unterstützung des Anwenders bei seinen Planungsarbeiten vorsehen. Für die Anbieterseite ist dies durchaus in Ordnung. Es sollte dabei aber nicht übersehen werden, dass Dienstvertragsrecht, sollte es hierauf Anwendung finden, keine Nacherfüllung vorsieht, und der Anwender gegebenenfalls unmittelbar Schadensersatz statt der Leistung wegen nicht oder nicht wie geschuldet erbrachter Leistungen fordert und/oder aus gleichem Grund vom Vertrag zurücktritt. Einen Schutz vor dieser unmittelbaren Inanspruchnahme bei Leistungsstörungen gewährt dem Anbieter nur die Fristsetzung, wie sie in den §§ 281 und 323 BGB vorgesehen ist. Infolgedessen kann es sich empfehlen, einige Maßgaben so einzubauen, dass der Vertrag schließlich doch in der Mechanik sich dem Werkvertragsrecht annähert. Als Beispiel wären hier insbesondere Leistungsstörungen, aber auch etwaige „Freigaben/ Abnahmen“ zu nennen. 2. Abnahme/Freigabe

358

Aus der Sicht des Anbieters wäre es sehr wünschenswert, wenn die einzelnen Stufen, s. oben Rz. 195 ff., einzeln „abgenommen“ würden. a) Anwenderinteresse

359

Der Anwender wird kaum in der Lage sein, zu erkennen, ob Konzepte richtig, vollständig und in ein fachliches Feinkonzept übersetzbar sind.

360

Aus Anwendersicht kann sich empfehlen, Folgendes ausdrücklich vertraglich zu vereinbaren: – Die Verjährungsfrist beginnt erst mit dem Abschluss des gesamten Projekts, allerdings nicht später als mit der Beendigung der Arbeiten durch den Auftragnehmer (z.B. bei Kündigung o.Ä.). – Eine Freigabe steht unter der Voraussetzung, dass der Auftraggeber mit Workshops oder anderen Präsentationen den relevanten Personen nachweist, den entsprechenden Arbeitsschritt erledigt zu haben. b) Anbieterinteresse

361

Viele Auftragnehmer drängen jedoch auf eine „echte“ Abnahme. Sie versprechen sich davon eine Absicherung gegenüber der Rückforderung der Vergütung.

362

Der Anbieter ist aber dem Risiko ausgesetzt, dass der Anwender die Erklärung der Abnahme verweigert, etwa weil er sich nicht in der Lage sieht, ei292

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 367 C

ne Beurteilung vorzunehmen. Damit läuft der Anbieter zum einen Gefahr, die vereinbarte (Teil-)Vergütung nicht zu erhalten, zum anderen wird der Beginn der Verjährungsfrist verzögert. Unter Umständen kann die mangelnde Abnahmeerklärung im Rahmen des Anpassungsprojektes sogar auf den Beginn der Zahlungspflicht aus einem Pflegevertrag für die Standardsoftware fortwirken. Es ist daher ratsam, die möglichen Risiken zu identifizieren und durch entsprechende vertragliche Regelungen möglichst auszuschalten, jedenfalls aber zu mildern. So könnten beispielsweise folgende Regelungen angestrebt werden:

363

– Die Realisierung einzelner Stufen/Meilensteine wird an die Abnahme eines vorherigen geknüpft, – die Vergütungspflicht im Rahmen des Pflegevertrages für die Standardsoftware wird an deren Auslieferung oder erfolgreiche Installation geknüpft. Aber auch die detaillierte Festlegung der Abnahmekriterien und des Szenarios kann das Risiko minimieren. Denkbar wäre auch eine Art gesplittete Freigabe/Abnahme, sinngemäß da- 364 hingehend, dass die fachliche Seite bzw. die fachlichen Inhalte vom Auftraggeber auf Richtigkeit und Vollständigkeit geprüft werden, während deren Projektion auf die zukünftig anzupassende Software nicht mehr davon erfasst wäre. Diese Verteilung wird auch dem Umstand gerecht, dass die Umsetzung der Anforderungen des Kunden durch die Anpassung der Software normalerweise schon die Realisierung darstellen würde. Insofern würde dieser mehr technische Aspekt nicht von der Freigabe/Abnahme des Pflichtenheftes umfasst. Wenn der Anbieter auf „Abnahme“ besteht, sollte er jedoch auch bedenken, 365 dass er sich in gewissen Widerspruch zu seiner Idee des Dienstvertrages mit nur Unterstützungsleistung setzt. Dies wäre aus Sicht des Anbieters eines der wichtigsten Argumente, die Abnahme zu verweigern. Bei der werkvertraglich orientierten Variante würde sich das vorstehend an- 366 gedeutete Problem seitens des Anbieters noch verstärkt darstellen, wenn er Teilabnahmen je Stufe wünscht. Das inhaltliche Problem des Anwenders, nämlich die Richtigkeit und die Folgen evtl. Unrichtigkeiten nicht übersehen zu können, bleibt. Gegenüber Teilabnahmen kann der Anwender vor allem auch einwenden, dass er dazu nicht verpflichtet sei. 3. Leistungsstörungen/Freigabe Die Lösung im Hinblick auf (zunächst) nicht ausreichend erbrachte (Bera- 367 tungs-)Leistungen und daraus folgende finanzielle Auswirkungen durch eventuell notwendige Konkretisierungs- und Ergänzungsleistungen könnte wie folgt aussehen:

Schneider

293

C Rz. 368

Verträge

Der Auftragnehmer erläutert dem Auftraggeber jeweils gegen Ende eines Abschnitts, also bei Erreichen eines Meilensteins bzw. eines Projektschrittes die Arbeitsergebnisse, indem er sie ihm vorlegt und in einem Workshop präsentiert und mit ihm durchspricht. Eine ähnliche Regelung ist z.B. in BVB-Planung vorgesehen. Der Auftraggeber prüft dabei im Rahmen seiner Möglichkeiten die Aussagen im Hinblick auf seine fachlichen Anforderungen. Bei dieser Beurteilung geht er davon aus, dass die fachlichen Ergebnisse aus der vorigen Stufe abgeleitet sind, wenn er es nicht sogar selbst beurteilen kann. Sofern eine richtige Ableitung bzw. der Nachweis, dass die fachlichen Vorgaben aus den jeweiligen Interviews, Workshops u.Ä. stammen, seitens des Auftragnehmers erbracht ist, erklärt der Auftraggeber die Freigabe. Da dies kein im BGB vorgesehener Begriff ist, wäre im Vertrag näher zu erläutern, was die Folgen sind. 368

Beispiel: Bei der Freigabe geht es um die Vollständigkeit, Richtigkeit und genügende Detailliertheit der Vorgaben und nicht etwa um die Frage der Mangelfreiheit i.S.d. „Gewährleistung“. Nach der Freigabe kann der Auftragnehmer darauf vertrauen, dass die Ausgestaltung des Konzepts, z.B. des Grobkonzepts, den fachlichen Anforderungen des Kunden entspricht. Wenn die Angaben jetzt noch zu vage sind und späterer Konkretisierung bedürfen, liegt dies in der Natur der Sache und gehört mit zur Arbeit bei der Übersetzung eines Grobkonzepts in ein Feinkonzept. Stellt sich heraus, dass noch zusätzliche (neue) Anforderungen bestehen, Querverbindungen oder Änderungen vom Auftraggeber gewünscht werden, so wird der dadurch entstehende zusätzliche Aufwand zumindest unter erleichterten Bedingungen, wenn nicht sogar generell vom Auftragnehmer verlangt werden können.

369

Die vorstehenden Überlegungen gelten also vor allem auch für den Fall, dass der Auftragnehmer stufenweise vorgeht, und die nächstfolgende Stufe tatsächlich auf die vorherige aufbaut. Gleiches gilt, wenn modulweise abgearbeitet wird und die Module untereinander entsprechend zusammenhängen, so dass in gewissem Sinne auch hier ein „Aufbau“ zu berücksichtigen wäre, auch wenn es sich eher um eine Querverbindung handelt. Dementsprechend müssen sich falsche bzw. nicht mehr zutreffende Angaben des Auftraggebers bei der späteren Bearbeitung weiterer Module als hinderlich auswirken. 4. Zur Vergütung

370

Beim typischen Software-Erstellungsprojekt, bei dem die Planung und die Realisierung ein Paket bilden, sind projektfortschrittsabhängige Abschlagszahlungen, die etwa bis zur Abnahme 70 bis 80 % und dann noch bis auf den Gewährleistungseinbehalt die Restzahlung umfassen, relativ weit verbreitet. Dahinter steckt nicht nur ein Festtermin, sondern auch ein Festpreis.

371

Bei einem Vertrag, der „nur“ die Erstellung des Pflichtenhefts zum Gegenstand hat, lässt sich bis zu einem gewissen Grade diese fortschrittsabhängi294

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 376 C

ge Vergütung einsetzen. Allerdings ist es häufig so, dass hierbei die Kalkulation des Auftragnehmers noch nicht steht, noch kein Festpreis vereinbart ist und mithin die Dimensionierung durchaus Schwierigkeiten bereiten kann. Es werden deshalb häufiger Obergrenzen oder Budgets vereinbart. Hinsicht- 372 lich der Obergrenzen wäre klarzustellen, ob mit deren Erreichung das Projekt zu Ende sein soll, wenn nicht eine neue Beauftragung seitens des Auftraggebers erfolgt oder aber, ob dies die Obergrenze des Aufwands ist, den der Auftraggeber bezahlt, auch wenn das Pflichtenheft noch nicht fertig ist, und der Auftragnehmer den Rest dann ohne weitere Vergütung leisten müsste. Auch hier zeigt sich wieder die Thematik „Dienstvertrag kontra Werkvertrag“, denn im erstgenannten Fall wäre ein bestimmter Leistungsumfang geschuldet, im zweiten Fall dagegen ein Erfolg. Eine weitere Möglichkeit wäre eine gesplittete Vergütung, die sowohl ein 373 zeitabhängiges als auch ein fortschrittsabhängiges Moment enthält. Auf diese Weise könnte die Liquidität auf Seiten des Auftragnehmers gefördert werden, ohne dass der Gedanke der fortschrittsabhängigen Zahlung ganz aufzugeben ist. Unüblich erscheint es dagegen bislang, diese Zahlungen deutlich als Abschlagszahlungen zu gestalten und gleichzeitig auch deren Besicherung zu bewerkstelligen, insbesondere durch Bankbürgschaft. 5. Abnahme/Verjährungsfristen Oben war schon die Problematik der Verjährungsfristen angedeutet worden, 374 je nachdem, wie die vertragstypologische Einordnung vorgenommen wird. Es ist nicht ganz unüblich, dass die späteren Projekte zur Umsetzung zum einen länger als zwei Jahre dauern und sich zum anderen dann erst im Laufe des Projekts herausstellt, dass die Umsetzbarkeit des Pflichtenhefts aufgrund technischer Mängel (nicht der Vorgaben des Auftraggebers) Schwierigkeiten bereitet. Zumindest individualvertraglich kann es sich daher empfehlen, etwa aus 375 Auftraggebersicht, zwar eine Abnahme zu akzeptieren, gleichwohl die Haftung des Auftragnehmers für etwaige Mängel des Pflichtenhefts auszuformulieren und zwar vor allem dahingehend, dass der Auftragnehmer die Ausführbarkeit des Pflichtenhefts, etwa im Rahmen der Anpassung bestimmter Software, „garantiert“. Diesen Begriff wird der Auftragnehmer nicht akzeptieren. Es würde aber wahrscheinlich schon für eine verschuldensunabhängige Schadensersatzhaftung reichen, wenn der Auftragnehmer eindeutig erklärt, für die Umsetzbarkeit, ähnlich wie für „Kompatibilität“ einzustehen zu wollen. Es könnte sich weiterhin als hilfreich erweisen, wenn die Verjährungsfrist vorsorglich zumindest nicht verkürzt, ggf. aber sogar verlängert würde. Man könnte zum einen, wie dies auch in § 634a Abs. 1 Nr. 3 BGB ohnehin vorSchneider

295

376

C Rz. 377

Verträge

gesehen ist, über die allgemeine Verjährungsregelung auf Kenntnis abstellen, zum anderen aber, wenn auf die Abnahme abgestellt wird, die Frist verlängern. 377

Theoretisch ließe sich auch vereinbaren, dass bei Vorliegen von Mängeln des Pflichtenhefts selbst dann, wenn etwa Verjährung eingetreten wäre, der Mehraufwand bei der Umsetzung zu Lasten des Auftragnehmers geht. Solche Überlegungen allerdings setzen stets voraus, dass es dieselbe Person ist, die die Pflichtenhefterstellung vorgenommen hatte und die dann die Realisierung vornimmt.

V. Datenschutz, Auftragsdatenverarbeitung 1. Datenschutzrechtliche Zulässigkeit, personenbezogene Daten a) Anwendung des BDSG 378

Im Zusammenhang mit Projekten kann es sein, dass der Auftraggeber mit personenbezogenen Daten umgehen muss oder dass der Auftragnehmer Kontakt bzw. Zugriff auf personenbezogenen Daten des Auftraggebers erhält oder zumindest diese Gefahr besteht. Um die Anwendbarkeit des BDSG auszulösen, genügt es, dass die Person „bestimmbar“ ist, um deren Daten es geht (§ 3 Abs. 1 BDSG).

379

Ein weiteres Erfordernis ist, dass die Daten entweder unter Einsatz von Datenverarbeitungsanlagen (DVA) oder in oder aus nicht automatisierten Dateien verarbeitet, genutzt oder dafür erhoben werden (§§ 1 Abs. 2 Nr. 3 i.V.m. 27 Abs. 1 BDSG, der für nicht-öffentliche Stellen gilt). Dieses Erfordernis ist in Zusammenhang mit Softwareprojekten regelmäßig gegeben. Greift also das BDSG, weil der Auftraggeber personenbezogene Daten in DVA verarbeitet, muss jeder Umgang mit solchen Daten, insbesondere auch durch den Auftragnehmer, den Zulässigkeitsvoraussetzungen genügen. Es gilt das Verbotsprinzip mit Erlaubnisvorbehalt1. Die – weiten – Ausnahmen sind gesetzliche Erlaubnisse oder Einwilligung (§ 4 BDSG).

380

Eine gesetzliche Erlaubnis findet sich für den Bereich der Unternehmen als nicht-öffentliche Stellen v.a. in § 28 BDSG, Datenerhebung und -speicherung für eigene Geschäftszwecke. Die Prüfung der Zulässigkeit und die Voraussetzungen für vertragliche Vorkehrungen sind primär Sache des Auftraggebers. Dieser muss also darauf achten, dass seine Datenverarbeitung und ggf. auch die Ausgestaltung, die der Auftragnehmer im Rahmen des Projekts für ihn herstellen soll, zulässig ist. Dies ist nicht trivial, da die einschlägige Regelung in § 28 Abs. 1 Satz 1 Nr. 2 BDSG sehr vage ist: … soweit die Erhebung, Speicherung, Veränderung, Übermittlung oder Nutzung „zur Wahrung berechtigter Interessen der verantwortlichen Stelle erforderlich ist und kein Grund zu der Annahme besteht, dass das schutzwürdige Interesse 1 § 4 BDSG; s.a. Gola/Schomerus, BDSG, 11. Aufl., Rz. 3.

296

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 384 C

des Betroffenen an dem Ausschluss der Verarbeitung oder Nutzung überwiegt“. In der Regel wird die Zulässigkeit im Rahmen von Projekten nicht ohne Weiteres, also besondere Umstände gegeben sein, wenn man davon ausgeht, dass der Auftraggeber den Personenbezug der Daten beseitigen kann. Insofern gilt es, die Gefahr des Kontakts mit personenbezogenen Daten seitens des Auftragnehmers rechtzeitig zu beachten und abzusichern. Mangels Konzernprivilegs sind verschiedene Gesellschaften desselben Konzerns jeweils wie Dritte zu behandeln. Die Einschaltung einer Service-Tochter-Gesellschaft unterscheidet sich datenschutzrechtlich im Prinzip nicht von der Einschaltung einer Fremdfirma (s. unten Rz. 401).

381

b) Einbeziehung des Auftragnehmers Die Gefahrensituation, dass der Auftragnehmer mit personenbezogenen 382 Daten des Auftraggebers in Kontakt kommen kann, tritt etwa bei Voruntersuchungen zum Datenvolumen und Datenformaten (z.B. bei Migrationsfragen), zu Geschäftsprozessen und später v.a. bei Tests, Probebetrieb und Einführungsunterstützung, schließlich bei Wartung und Pflege auf. Die Notwendigkeit der Prüfung, ob ein solcher Umgang mit personenbezogenen Daten bzw. deren Offenbarung gegenüber Dritten zulässig ist, kann sich also auch schon vor dem Vertragsschluss, etwa bei Ermittlungen zur Angebotsabgabe, ergeben. Die Zulässigkeit richtet sich grundsätzlich nach dem BDSG. Es können 383 noch je nach Anwendungsgebiet besondere Regeln gelten, etwa aus dem Bereich TMG oder TKG. Auch können spezielle Schutzpositionen wie Anwalts- oder Patientengeheimnis zu beachten sein. Das BDSG verbietet den Umgang mit personenbezogenen Daten, um ihn in Ausnahmefällen zuzulassen. Die Zulässigkeit ist für bestimmte Phasen bzw. Vorgänge geregelt. Die Phasen sind das Erheben, Verarbeiten (umschließt Speichern, Verändern, Übermitteln, Sperren, Löschen) und Nutzen der Daten. Diese Phasen und Vorgänge sind näher in § 3 BDSG definiert. Die Überlassung der Daten an den Auftragnehmer bzw. dessen Zugriff ist als Übermittlung jeweils auf Zulässigkeit zu untersuchen. c) Auftrag Eine Auftragserteilung zur Verarbeitung personenbezogener Daten an einen 384 Auftragnehmer ist gemäß § 11 BDSG privilegiert und bedarf keiner eigenen Zulässigkeitsprüfung für die Übermittlung zwischen Auftraggeber und Auftragnehmer, aber besonderer Voraussetzungen und Maßnahmen. Die Privilegierung greift nicht, wenn der Aufragnehmer im Nicht-EU-/-EWR-Ausland sitzt1. 1 Ergibt sich aus der Definition in § 3 Abs. 8 BDSG; zu Standardvertragsklauseln der EU und Safe Harbor s. Rz. 439.

Schneider

297

C Rz. 385 385

Verträge

Typisch hierfür ist der Rechenzentrumsvertrag, auch der Betreibervertrag und immer mehr das Outsourcing, neuerdings in die Cloud. Das Erfordernis, die Voraussetzungen des § 11 BDSG zu erfüllen und entsprechende vertragliche Abmachungen sowie die technisch/organisatorischen Maßnahmen zu treffen, stellt sich aber auch bei Projekten, deren Vorbereitung und bei Wartung und Pflege. d) § 11 BDSG bei Projekten

386

In der Regel bildet das Thema Datenschutz nicht den Schwerpunkt der Überlegungen zu Softwareerstellung bzw. Projektverträgen. Es wird sicher eine Reihe von Projekten geben, bei denen weitgehend auf den Einsatz personenbezogener Daten verzichtet werden kann und datenschutzrechtlich allenfalls virulent ist, dass die Kontaktdaten der beteiligten Personen ausgetauscht werden. Sobald aber Tests, Vorbereitungsarbeiten oder auch Feststellungen zu Machbarkeit, Migrierbarkeit, Abnahmefähigkeit, Belastbarkeit/Performance, Integrität u.ä. stattfinden, besteht die Möglichkeit, dass dies mit Echtdaten und insofern personenbezogenen Daten geschieht oder auch geschehen muss (um realistische Verhältnisse zu erhalten), also etwa bei Lasttests. Im Prinzip ergeben sich bei Projekten zu Erstellung und Anpassung von Software ähnliche Datenschutzprobleme wie bei Betriebsübergang (nebst Vorbereitung)1, Due Diligence2 und Lizenzaudits3.

387

Gibt es Kontakt mit personenbezogenen Daten, stellt sich die Frage, ob deren Erhebung, Verarbeitung und Nutzung (Definitionen in § 3 BDSG) datenschutzrechtlich zulässig ist. Soweit es sich um Fremddaten bzw. Daten Dritter handelt (z.B. Kundendaten, Lieferantendaten u.ä.), richtet sich die Frage der Zulässigkeit v.a. nach § 28 BDSG. Sobald Mitarbeiterdaten betroffen sind, was etwa bei HR-Modulen und letztlich auch bei jeder Einbeziehung der User der Fall sein wird, also z.B. auch bei der Messung, wie viele Lizenzen benötigt werden bzw. im Einsatz sind u.ä., richtet sich die Zulässigkeit prinzipiell nach § 32 BDSG. Es ist strittig, ob und inwieweit der Arbeitgeber ggf. auch, wenn § 32 BDSG keine ausreichende Möglichkeiten bietet, ergänzend auf § 28 BDSG zurückgreifen darf bzw. inwieweit § 32 BDSG lex specialis ist4. 1 Woerz, ArbR 2011, 502; s.a. Woerz, Arbeitnehmerdatenschutz beim Betriebsübergang, 2011 (Diss.). 2 S. z.B. Göpfert/Meyer, NZA 2011, 486; Scheja/Mantz, CR 2009, 413. 3 Zum Vorgehen – ohne Datenschutzbezug – Bierekoven, ITRB 2008, 88. 4 Der „Wille des Gesetzgebers“ hat – so Seifert, in: Simits (Hrsg.), BDSG, 7. Aufl., § 32 Rz. 17 – „… insoweit in der Beschlussempfehlung und im Bericht des Innenausschusses zum Gesetz der Änderung datenschutzrechtlicher Vorschriften seinen Ausdruck gefunden“, als § 32 „den gesamten § 28 Abs. 1!“ verdrängt und „diesem als lex specialis“ solange „vorgeht“ wie die Erhebung, Verarbeitung oder Nutzung von personenbezogenen Daten für ‚Zwecke des Beschäftigungsverhältnisses‘ erfolgt.“ BT-Drucks. 16/13657, 34; s.a. Gola/Jaspers, RDV 2009, 212.

298

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 390 C

Die entscheidende Frage ist also, ob die in Rede stehenden Arbeiten, so etwa 388 die Tests, „für Zwecke des Beschäftigungsverhältnisses“ verarbeitet werden. Grundsätzlich wird dies allenfalls mittelbar insofern der Fall sein, als das spätere Projektergebnis möglicherweise der Verarbeitung der Personaldaten dient. Diese Mittelbarkeit reicht aber wohl nicht aus, um zwingend eine Einordnung unter § 32 BDSG zu begünden. Infolge dessen kann sich der Anwender/Arbeitgeber wohl auf § 28 Abs. 1 BDSG berufen. Allerdings muss dabei eine Reihe von Anforderungen erfüllt sein, etwa Erforderlichkeit. Es sei aber daran erinnert, dass die Anwendbarkeit der Datenschutzregeln 389 dann nicht mehr gegeben ist, wenn die Daten anonymisiert sind. Bei Pseudonymisierung ist anzunehmen, dass das Potential zur Re-Identifizierung, also der Personenbeziehbarkeit, relativ groß ist. Selbst bei objektiver Betrachtungsweise kann man davon ausgehen, dass bei vielen Pseudonymisierungsverfahren die Re-Identifikation möglich ist. § 3 Abs. 6a BDSG definiert das Pseudonymisierung als „das Ersetzen des Namens und anderer Identifikationsmerkmale durch ein Kennzeichen zu dem Zweck, die Bestimmung des Betroffenen auszuschließen oder wesentlich zu erschweren“. Sobald also der betreffende Anwender bzw. dessen Mitarbeiter über die Zuordnung der Kennzeichen Zugang zu echten Identifikationsdaten haben, wäre die Re-Identifikation möglich und somit der Personenbezug gegeben1. Weiter ist zu beachten, dass möglicherweise genau diese Verhältnisse Anlass geben können, weitere Datenschutzprinzipien ins Feld zu führen und beachten zu müssen, so insbesondere die Prinzipien der Datenvermeidung und Datensparsamkeit, § 3a BDSG. Diese könnten dazu führen, dass der Anwender zunächst einmal mit Material zu arbeiten hat, das anonymisiert bzw. zumindest pseudonymisiert ist, evtl. sogar überhaupt Echtdaten ausgeschlossen werden. Erst in besonders dringenden Fällen bzw. in sehr begrenzten Anwendungsbereichen könnte dann teilweise die Arbeit mit Echtdaten erfolgen. Letzten Endes wäre aber diese Arbeit nur insoweit zulässig, als sie auch im Produktivbetrieb zulässig wäre. Dies wäre also im Vorhinein immer zu prüfen2. Ist die Verarbeitung zulässig und ist dies auch für die Tests zu bejahen, ist 390 des Weiteren § 9 BDSG zu beachten, der die technisch-organisatorischen Maßnahmen i.V.m. der Anlage regelt. Dazu ist eine sehr wichtige konstruktive Aufgabe zu leisten, nämlich diese Gebote, die dort als Kontrolle niedergelegt sind, auf den Einzelfall herunter zu brechen und Maßnahmen daraus zu gestalten, die für den konkreten Anwendungsfall greifen. Datenschutzregeln sind insoweit über technische Ausgestaltung, orientiert am konkreten Schutzbedarf, zu erfüllen. Ansonsten bleibt § 9 BDSG eine Leerformel, 1 Zu den Datenschutzanforderungen in Testverfahren s. im Übrigen Conrad, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, 2011, § 16 Rz. 225 ff. m.w.N. 2 Zur Frage der Zulässigkeit der Verarbeitung personenbezogener Daten nach § 28 s. z.B. Simitis, BDSG, 7. Aufl., und zu Mitarbeiterdaten s. Seifert, in: Simitis (Hrsg.), BDSG, 7. Aufl., Rz. 12 ff. (Geltungsbereich), Rz. 16.

Schneider

299

C Rz. 391

Verträge

wie sie häufig in Verträgen zu finden ist („Der Auftragnehmer trifft die technisch/organisatorischen Maßnahmen, die erforderlich sind, um die Ausführung der Vorschriften des BDSG zu gewährleisten.“)1. 391

Diese technisch-organisatorischen Maßnahmen können in engem Zusammenhang mit dem gesamten Projekt stehen, d.h. also auch Eigenschaften bzw. Funktionalitäten des geplanten/zu realisierenden Systems ansprechen bzw. voraussetzen. Unter diesem Aspekt ist es wichtig, dass diese Maßnahmen bereits durch ein evtl. erstelltes Pflichtenheft abgedeckt und dessen Bestandteil werden2.

392

Als eine Art Zwischenergebnis ist festzuhalten, dass sich die Frage der datenschutzrechtlichen Zulässigkeit der Tests insbesondere mit Echtdaten bereits stellt, wenn der Auftraggeber selbst die Tests durchführt und der Auftragnehmer überhaupt nicht damit in Berührung kommt und insofern auch kein zusätzliches datenschutzrechtliches Problem entsteht. Es tritt allerdings dann auf, wenn der Dritte eingeschaltet wird und diese Zugriffsmöglichkeit besteht. Dann greift der ganze Regelungsbereich des Gesetzes über die Auftragsdatenverarbeitung, was häufig übersehen wird. e) Outsourcing

393

Die Auslagerung von Datenbeständen und/oder der Verarbeitung von Daten ist oft Ziel und Gegenstand des Projekts selbst3. In diesen Fällen ist die Notwendigkeit, § 11 BDSG zu beachten, evident, wenn es sich um personenbezogene Daten handelt4. Dass aber während der Projektlaufzeit auch Outsourcingvorgänge stattfinden, wird oft weniger beachtet. Typisch ist etwa die vorübergehende Backup-Funktion im Rahmen der Umstellung oder die Einführungsunterstützung mit Support. Auch die Einschaltung Dritter etwa bei Tests, Datenumwandlung und Hinterlegung kann mit Bekanntgabe personenbezogener Daten verbunden sein. f) Cloud

394

Bei der Arbeit in der Cloud5 sticht hervor, dass der Auftraggeber zwar nicht die logische Datenherrschaft verliert, wohl aber letztlich die „physikalische“. Und v.a., dass eine genauere Bestimmung, wo sich die Daten jeweils befinden, nicht mehr möglich ist. Es ist aber gleichzeitig anzumerken, dass 1 S. Zuck, in Conrad (Hrsg.), Liber amicorum, 2008, S. 145, zum Konkretisierungsbedarf bei den acht Geboten der Anlage zu § 9. Zur geringen Verzahnung von Datenschutz und „Datensicherheit“ s.a. Schneider, ZD 2011, 6. 2 Zur Pflichtenhefterstellung generell s. oben Rz. 1 ff. 3 S. z.B. Hartung, VersR 2012, 400. 4 Zu weiteren Aspekten s.a. Checkliste unten Rz. 409 f. 5 Zur Vertragsgestaltung beim Cloud Computing mit Hinweisen zu § 11 s. z.B. Splittgerber/Rockstroh, BB 2011, 2179.

300

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 396 C

sich dies nicht wesentlich von anderen virtuellen „Maschinen“ bzw. Betriebssystemen unterscheidet. Praktisch trat dieses Phänomen bisher schon auf. Allerdings schien es so, dass eine gewisse physikalische Herrschaft dadurch gegeben war, dass sich die Daten auf einem bestimmten Rechner in einem bestimmten Rechenzentrum an einem bestimmten Ort befanden. Diese scheinbare Gewissheit entfällt bei der Cloud. Es ist deshalb einerseits stets zu fragen, ob Cloud Computing vorliegt und noch als im Rahmen der Auftragsdatenverarbeitung liegend gesehen werden kann, also insofern „beherrschbar“ ist, und andererseits, welche besonderen Vorkehrungen insoweit zu treffen sind. I.V.m. Projekten kommt naturgemäß in Betracht, dass das ganze Projekt darauf ausgerichtet ist, später die Software in der Cloud zur Verfügung zu stellen bzw. zu nutzen, so dass schon vorher Übergänge erfolgen, die unter diesem Datenschutzaspekt zu sehen sind. Des Weiteren kommt in Betracht, dass während des Projekts Hilfestellungen, Übergangslösungen u.ä. sich so vollziehen, dass der Auftragnehmer oder ein Dritter Systeme zur Verfügung stellt und hierzu Cloudtechnik einsetzt. In all diesen Fällen insbesondere während des Projekts sind auch § 11 BDSG bzw. § 9 BDSG zu berücksichtigen. Von der unmittelbaren Anwendung des § 11 BDSG zu unterscheiden ist die 395 Notwendigkeit analoger Anwendung, die im Folgenden ausführlicher dargestellt wird. Das bedeutet, dass dann, wenn der Auftragnehmer etwa auch Cloudtechniken zur Erbringung von Pflegeleistungen, Umgehungen u.ä. einsetzt, u.U. die sog. Funktionsübertragung vorliegt. In diesen Fällen wäre dann jeder einzelne Übermittlungsvorgang auf seine Zulässigkeit zu überprüfen. g) Typische Situationen/Aufgaben Um zu erkennen, ob es sich noch um die typische Auftragsdatenverarbei- 396 tung handelt, kann das folgende Schema helfen. Gemäß der bayerischen Aufsichtsbehörde sind als typische Aufgaben für Auftragsdatenverarbeitung anzusehen1: – – – –

Konzeption von DV-Systemen und Netzwerken Entwicklung, Wartung und Pflege von Software Wartung von Hardware Bereitstellung, Administration und Betrieb einzelner Rechnersysteme (z.B. Firewall Rechner) bzw. ganzer Netzwerke – Bereitstellung und Betrieb des kompletten Rechenzentrums – Beschaffung, Installation und Betreuung der Bürokommunikation (UserHelp-Desk) – Bereitstellung von Backup-Systemen 1 Laut Hinweisen der Datenschutzbehörde in Bayern kommen für eine Auftragsdatenverarbeitung insbesondere die aufgezählten Aufgaben infrage (http://www. datenschutz-bayern.de/technik/orient/oh_auftragsdatenverarbeitung.html).

Schneider

301

C Rz. 397

Verträge

– Abwicklung einzelner DV-Arbeiten (z.B. Programmierarbeiten, Datenerfassung, Datenpflege – Erledigung von Massenarbeiten wie Mailingaktionen, Erhebung und Auswertung von Daten) – vollständige Abwicklung aller DV-Tätigkeiten – Transport von Informationen und Datenträgern – Lagerung, Archivierung und Verfilmung von Unterlagen – Vernichtung von Datenträgern 397

Es ist zu empfehlen, die Vorgänge, die während der Projektrealisierung in Bezug auf den Umgang mit personenbezogenen Daten (auch) durch den oder die Auftragnehmer erforderlich sind, unter dem Aspekt der vorstehenden Aufgaben, die nach § 11 BDSG zu regeln sind, zu analysieren. Konkret kommen etwa bei Softwareerstellung bzw. Projekten in Betracht: – Hotlineverträge, evtl. als Teil der Einführungsunterstützung, des SLA oder der Pflege1, evtl. auch … line support o.Ä. genannt; – Remoteservices, etwa zwecks Analyse für Nachbesserung, Workaround, Monitoring; – Tests, Abnahmeprüfungen; – Parallelbetrieb mit Vergleich der Ergebnisse; – Notfallübungen, Kontrolle Backup; – Lizenzaudits. h) Geheimnisse

398

Die personenbezogenen Daten unterliegen dem Datengeheimnis, § 5 BDSG. Dementsprechend hat eine Verpflichtung auf das Datengeheimnis zu erfolgen, deren Nachweis der Auftraggeber vom Auftragnehmer verlangen kann. Für spezielle Daten gelten besondere Vorschriften, auch was die Offenbarung gegenüber Dritten (hier: gegenüber dem Auftragnehmer) betrifft, etwa Sozialdaten, Krankenhäuser2, Ärzte, Rechtsanwälte. Die Verletzung ist u.a. strafbewehrt, v.a. durch § 203 StGB.

399

Es ist ein weit verbreiteter Irrtum anzunehmen, dass man mittels des Vertrags zur Auftragsdatenverarbeitung die Zulässigkeit einer Verarbeitung erreichen kann. Wenn diese aber dem Grunde nach (beim Auftraggeber) nicht gegeben ist, kann sie auch nicht über einen entsprechenden Vertrag „geheilt“ werden. Dies betrifft insbesondere das Problem, dass eine Reihe von Spezialgesetzen die Geheimhaltung von Daten vorschreibt, die nur nach ausdrücklicher Einwilligung des Betroffenen gegenüber Dritten offenbart werden dürfen, wie z.B. das Arzt- und Anwaltsgeheimnis.

1 S. Roth, Muster, in: Redeker (Hrsg.), Handbuch der IT-Verträge, 1.9. 2 Paul/Gendelev, ZD 2012, 315.

302

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 402 C

Des Weiteren haben Bundesländer spezielle Regelungen geschaffen, die etwa für Krankenhäuser gelten. I.V.m. Sozialdaten gelten zudem spezielle Regelungen, denen sich wiederum auch Private, die mit den Einrichtungen des öffentlichen Bereichs zusammenarbeiten, unterwerfen müssen. Aktuelle Fragen ergeben sich insoweit auch im Hinblick auf die Entsorgung des Datenmaterials, sobald dieses nicht mehr benötigt wird, was häufig nach Tests u.ä. der Fall ist. Insoweit wird es sich empfehlen, stets genau zu prüfen, welche Vorausset- 400 zungen hinsichtlich der Zulässigkeit im Hinblick auf Geheimnisse beim Auftraggeber vorliegen, sodann klarzustellen, dass dieser für deren Einhaltung verantwortlich ist und schließlich durch geeignete technische und organisatorische Maßnahmen sicherzustellen, dass eine Wahrung dieses Geheimnisses erfolgt. Ganz generell ist zu beachten, dass für personenbezogene Daten das Datengeheimnis gilt, auf das die Mitarbeiter zu verpflichten sind. i) Kein Konzernprivileg Das BDSG adressiert die einzelne Stelle, also die einzelne juristische bzw. 401 natürliche Person, die als Unternehmer im privatrechtlichen Bereich agiert (im öffentlichen Bereich die einzelne öffentliche Stelle). Es gibt keine Spezialregelungen und insbesondere keine Privilegierungen für den Konzern1. Das bedeutet, dass der Datenverkehr zwischen konzernangehörigen Unternehmen den gleichen Voraussetzungen unterliegt wie zwischen dem Unternehmen und Dritten. Für die Frage der Auftragsdatenverarbeitung heißt das wiederum, dass auch eine Konzerntochter, die die Auftragsdatenverarbeitung bzw. das Projekt übernimmt, die gleichen Voraussetzungen erfüllen und einen entsprechenden Vertrag schließen muss, wie dies bei der Einschaltung außenstehender Firmen erforderlich wäre. j) Funktionsübertragung Die Privilegierung nach § 11 BDSG greift nicht, wenn der Auftraggeber 402 nicht (mehr) Herr der Daten ist, sondern dem Auftragnehmer ein Spielraum im Umgang mit den Daten verbleibt2. Auf diese Unterscheidung, ob also ganze Funktionen übertragen werden, wird es bei den meisten Projekten nicht ankommen. Hier wird, wenn überhaupt ein Fall der Verarbeitung personenbezogener Daten gegeben ist, in der Regel die projektbezogene reine Hilfsfunktion mit Weisungshoheit des Auftraggebers vorliegen. Anders wird dies sein, wenn das ganze Projekt auf Auslagerung ausgerichtet ist. Dann werden schon im Vorfeld eine Reihe von Auslagerungen stattfinden 1 S.a. Gola/Schomerus, BDSG, 11. Aufl., § 11 Rz. 4 f. Zur Datenübermittlung und -verarbeitung im Konzern s. Legerlotz, ArbR 2012, 190. 2 Zur Abgrenzung s. etwa Grützmacher, ITRB 2007, 183, 185; zur „Vertragstheorie“ als Abgrenzungsmethodik: Taeger/Gabel/Gabel, § 11 BDSG Rz. 14–16.

Schneider

303

C Rz. 403

Verträge

und es ist somit die Klärung erforderlich, ob evtl. im Ergebnis bzw. bei Echtbetrieb Funktionsübertragung vorliegt, also die Privilegierung des § 11 BDSG nicht greift. 403

Im Folgenden geht es um die Beachtung der Anforderungen, die sich aus dem Umstand ergeben, dass bei Erfüllung des Hauptvertrags auch ein Kontakt mit personenbezogenen Daten erfolgen kann, also etwa bei den erwähnten Vorarbeiten, Tests und Migrationen sowie bei Support, auch im Rahmen der Pflege. k) Verschlüsselung/Anonymisierung

404

Gemäß der Anlage zu § 9 BDSG wird zur Erfüllung der dort vorgeschriebenen Kontrollnummern 2 bis 4, also für Zugangs-, Zugriffs- und Weitergabekontrolle die Verschlüsselung „empfohlen“1. Bei der entsprechenden „Empfehlung“ handelt es sich um eine Art Klarstellung, dass eine Maßnahme nach Satz 2 Nr. 2 bis 4 Anlage zu § 9 BDSG insbesondere die Verwendung von dem Stand der Technik entsprechenden Entschlüsselungsverfahren ist. Es wird sich also nicht nur empfehlen, sondern als nahezu unabwendbar herausstellen, diese Technik anzuwenden, wo nicht ein unverhältnismäßiger Aufwand entstehen würde. Es entsteht auf diese Weise eine Art Rechtfertigungsdruck, wenn das Verfahren nicht eingesetzt wird. Andererseits ist festzuhalten, dass dann, wenn es gelingt, die Daten so zu anonymisieren, dass der Personenbezug nicht mehr gegeben ist, das BDSG im Übrigen keine Anwendung mehr findet. Dies würde die Lösung zahlreicher Probleme mit sich bringen. Insbesondere bei Testmaterial wird sich diese Methodik empfehlen2. 2. Anforderungen der Auftragsdatenverarbeitung (analoge Anwendung) a) Vertrag über Auftragsdatenverarbeitung

405

Neben einer Geheimhaltungs- und Vertraulichkeitsvereinbarung sind Vereinbarungen im Hinblick auf § 11 Abs. 5 BDSG wichtige Ergänzungen der Verträge zu Softwareerstellung und -anpassung3. Schon 2001 war eine entsprechende Vorschrift in § 11 BDSG aufgenommen worden. Danach ist § 11 BDSG im Übrigen auch dann anzuwenden, wenn „die Prüfung oder Wartung automatisierter Verfahren oder von Datenverarbeitungsanlagen durch andere Stellen im Auftrag vorgenommen wird und dabei ein Zugriff auf personenbezogene Daten nicht ausgeschlossen werden kann“. 2009 wurde im Rah1 So die Interpretation bei Gola/Schomerus, BDSG, 11. Aufl., § 9 Rz. 29a. 2 Zu der Frage der Personenbezugs und wann genau Anonymität vorliegt, s. z.B. Plath/Schreiber, BDSG, 2013, § 3 Rz. 12 ff. m.w.N. 3 Bierekoven, Muster Auftragsdatenverarbeitung in: Redeker (Hrsg.), Handbuch der IT-Verträge, 7.2. Zu Formulierungsvorschlag mit Verweis auf eine Anlage s. Roth-Neuschild, in: Redeker (Hrsg.), Handbuch der IT-Verträge, 1.19, § 156 Rz. 146.

304

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 409 C

men der BDSG-Novelle II § 11 BDSG erheblich ausgebaut. Abs. 2 enthält seit 2009 einen Katalog von zehn Punkten, die ein Datenverarbeitungsauftrag zu enthalten hat. Zudem treffen den Auftraggeber besondere Pflichten bei Auswahl des Auftragnehmers und Prüfung der von diesem getroffenen technisch-organisatorischen Maßnahmen. Die Notwendigkeit der ausführlichen Ausgestaltung des Vertrags über die Auftragsdatenverarbeitung bei unmittelbarer Anwendung des § 11 BDSG ist erst in jüngerer Zeit allgemein bewusst geworden1, im Bereich der analogen Anwendung, um die es hier geht, also über § 11 Abs. 5 BDSG, erfolgt dieser Prozess erst allmählich. b) Prüfungsaufgaben Im Zusammenhang mit Outsourcing im engeren und im weiteren Sinne, al- 406 so z.B. auch schon bei Pflege, schließlich sogar bei Tests, kann sich die Konstellation ergeben, dass der Auftragnehmer Prüfungsaufgaben wahrnimmt. Dies könnten etwa Tests, aber auch Begutachtungen zum Zweck der Angebotsabgabe u.ä. sein. Schließlich ist es denkbar, dass für Übergangszeiten, wenn nicht im Weg des „Big Bang“ umgestellt wird, der Auftragnehmer den vorläufigen Betrieb entweder unterstützt oder sogar übernimmt. Vom Wortlaut her wäre in diesen Fällen wohl § 11 Abs. 5 BDSG nicht erfüllt2. Es ist aber eher die Tendenz festzustellen, diese Begrifflichkeit extensiv aus- 407 zulegen. So spricht z.B. Gola/Schomerus von Wartungs- und Serviceaufgaben3. Im Rahmen der weiten Auslegung des Begriffs der Prüfung gehört hierzu auch die sogenannte Online-Überwachung, also etwa das Monitoring von Systemen4. Ebenso zählt zu Wartung auch die Fernwartung und insofern auch die Fernpflege bzw. der Remote-Service. Vor diesem Hintergrund empfiehlt es sich für die Vertragspartner, entweder 408 die Gefahr auszuschließen, dass der Auftragnehmer bzw. dessen Personal Zugriff auf personenbezogene Daten des Auftraggebers erhält. Dies muss tatsächlich ausgeschlossen sein. Oder aber – und dies empfiehlt sich – es sollte vorsorglich eine entsprechende Auftragsdatenverarbeitungsvereinbarung evtl. sogar vor Vertragsschluss gesondert vereinbart werden. c) Checkliste Deren Eckdaten sollen im Folgenden kurz skizziert werden5. Bevor dies geschieht, noch einige Hinweise auf die Situationen, in denen insbesondere

1 S. aber zu Defiziten bei der Vertragsgestaltung Vander, K&R 2010, 292. 2 Zur Vertragsgestaltung des Übergangs von der Projekt- in die Betriebsphase s.a. Gennen, ITRB 2011, 213; zu Einführung und Implementierung s.a. Kap. G Rz. 128a ff. 3 Gola/Schomerus, BDSG, 11. Aufl., § 11 Rz. 14 ff. 4 S.a. Gola/Schomerus, BDSG, 11. Aufl., § 11 Rz. 15. 5 S. sogleich Rz. 410.

Schneider

305

409

C Rz. 409

Verträge

an eine solche Vereinbarung gedacht werden kann und welche Aspekte dann bei der Vereinbarung hierzu besonders beachtet werden sollten1. – Beteiligungsrechte des Betriebsrats vorher klären (gilt auch für das Endprodukt des Projekts): – Mitbestimmungsrecht gem. § 87 Abs. 1 Nr. 6 BetrVG bei technischen Überwachungseinrichtungen – Unterrichtungs- und Beratungsrecht gem. § 90 BetrVG u.a. bei technischen Anlagen sowie Anspruch auf Berücksichtigung der Bedenken des Betriebsrats bei der Planung – §§ 90, 87 Abs. 1 Nr. 6, BetrVG gelten grds. bei der Neueinführung, Änderung, Erweiterung von IT-Systemen – keine neue BV erforderlich, wenn bei einem Update weder Frontend/ Funktionsumfang noch Art/Umfang der personenbezogenen Beschäftigtendaten, die mit dem System erhoben, verarbeitet oder genutzt werden, geändert werden – zur Klarstellung in (Rahmen-)Betriebsvereinbarung regeln, ob/wie der Betriebsrat bei Änderungen (v.a. Updates/Upgrades)/Tests zu unterrichten und bei welchen Änderungen neue Beratung mit Betriebsrat erforderlich ist. – Problem: § 32 noch vor § 11 BDSG2? – BDSG: keine Unterscheidung Echtdaten/Testdaten. – Testdaten können personenbezogen sein, wenn nicht ausreichend anonymisiert (Entfernung von Name und Personalnummer reicht regelmäßig nicht) – (Einführungs-)Tests von IT-Systemen im BDSG nicht ausdrücklich geregelt – Einschwingphase, Einführungsunterstützung, Monitoring, Parallelbetrieb – § 4d Abs. 5 BDSG (Vorabkontrolle vor Inbetriebnahme): keine Erlaubnis, sondern Rechtmäßigkeitskontrolle evtl. schon vor Beginn von Tests mit „Echtdaten“ – § 9 BDSG: keine Erlaubnisnorm; aber Tests können technische Sicherheitsmaßnahme sein (v.a. im Rahmen von § 11 BDSG). – § 31 Fall 3 BDSG (Speicherung von Daten zur Sicherstellung eines ordnungsgemäßen Betriebs einer Datenverarbeitungsanlage): nur bereits gespeicherte Daten, nicht neue Datenerhebungen/- verarbeitungen – § 32 Abs. 1 Satz 1 BDSG: Sicherheitstests von IT-Systemen als Maßnahme zur Sicherung von Betriebsmitteln (der Arbeitsgrundlage)? Einfüh1 Die folgende Auflistung entstand in Anlehnung an und unter Verwendung von Conrad, Vortragsskript Kölner CR-Tage, 12.3.2010: Profilbildung und Datenabgleich im Konzern. 2 Gola/Jaspers, § 32 BDSG – eine abschließende Regelung?, RDV 2009, 212. S.a. Gola/Schomerus, BDSG, 11. Aufl., § 32 Rz. 32, keine abschließende Regelung.

306

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 410 C

rungstests als Maßnahme zur Begründung von neuen Beschäftigungsverhältnissen? Wohl eher abzulehnen wegen restriktiver Auslegung der Erforderlichkeit. – Sind die Testdaten Echtdaten? Sind sie anonymisiert? Dann gilt das BDSG im Übrigen nicht mehr. – Reicht pseudonymisiert? Dabei ist zu differenzieren: – „Normale“ Daten, nicht Mitarbeiterdaten – Mitarbeiterdaten (§ 32): Erforderlichkeit/Zulässigkeit hängt vom Einzelfall ab, insbesondere – ob das zu testende Datenverarbeitungsverfahren im Produktivbetrieb zulässig ist, – in welcher Phase des Projekts und zu welchem Zweck der Test durchgeführt wird (z.B. zur Auswahlentscheidung für eine IT-System vor Einführung oder Machbarkeitstest vor Produktivstart), – ob der Test mit Echtdaten erforderlich ist oder ob ein Test mit anonymisierten oder zumindest pseudonymisierten Daten ausreicht, – welche Personen/Abteilungen/Konzernunternehmen/externe Stellen den Test durchführen und Zugriff auf getestete Daten/Testergebnisse haben (dazu Vertrag nach § 11 BDSG erforderlich). – ob die erforderlichen technischen und organisatorischen Sicherheitsmaßnahmen eingehalten werden (strikte Trennung von Testund Echtdaten), – ob sichergestellt ist, dass die für den Test erhobenen, verarbeiteten und genutzten Echtdaten nur für den Testzweck verwendet und nicht zweckentfremdet werden (etwa zur Leistungs- und Verhaltenskontrolle). – Besondere Arten von Daten (typisch etwa Krankheitsdaten): s. im Einzelnen § 28 Abs. 6–8 BDSG. 3. Eckpunkte des Vertrags Nach § 11 Abs. 2 Satz 2 BDSG ist der Auftrag schriftlich zu erteilen. Sodann 410 sind „insbesondere“ die zehn im Gesetz genannten Einzelpunkte im Vertrag festzulegen. D.h., dass das Gesetz ein Minimum an vertraglicher Gestaltung gemäß diesen zehn Punkten verlangt, das bei besonderen Konstellationen aber noch zu ergänzen ist. Im Einzelnen sind festzulegen: 1. der Gegenstand und die Dauer des Auftrags, 2. der Umfang, die Art und der Zweck der vorgesehenen Erhebung, Verarbeitung oder Nutzung von Daten, die Art der Daten und der Kreis der Betroffenen, 3. die nach § 9 zu treffenden technischen und organisatorischen Maßnahmen 4. Die Berichtigung, Löschung und Sperrung von Daten,

Schneider

307

C Rz. 411

Verträge

5. die nach Satz 4 bestehenden Pflichten des Auftragnehmers, insbesondere die von ihm vorzunehmenden Kontrollen. 6. die etwaige Berechtigung zur Begründung von Unterauftragsverhältnissen, 7. die Kontrollrechte des Auftraggebers und die entsprechenden Duldungsund Mitwirkungspflichten des Auftragnehmers, 8. mitzuteilende Verstöße des Auftragnehmers oder der bei ihm beschäftigten Personen gegen Vorschriften zum Schutz personenbezogener Daten oder gegen die im Auftrag getroffenen Festlegungen, 9. der Umfang der Weisungsbefugnisse, die sich der Auftraggeber gegenüber dem Auftragnehmer vorbehält, 10. die Rückgabe überlassener Datenträger und die Löschung beim Auftragnehmer gespeicherter Daten nach Beendigung des Auftrags. 411

Die zehn Punkte sind zu konkretisieren und an die jeweiligen Gegebenheiten anzupassen. Entsprechendes gilt für die implizit über Ziffer 3 angesprochenen Kontrollen der Anlage zu § 91.

412

Bei Pflegeverträgen kann eine weitere Regel des § 11 erhebliche praktische Probleme bereiten: Der Auftraggeber ist hinsichtlich der Auswahl der Auftragnehmer zumeist auf den Lieferanten/Hersteller der Standardsoftware, bei Anpassung an auf dessen Vertriebs-Partner (VAR o.ä.) angewiesen, hat also kaum Auswahl. Nach § 11 Abs. 2 Satz 1 BDSG ist aber der Auftragnehmer „unter besonderer Berücksichtigung der Eignung der von ihm getroffenen technischen und organisatorischen Maßnahmen sorgfältig auszuwählen“. Nach § 11 Abs. 2 Satz 4 BDSG hat der Auftraggeber sich vor Beginn der Datenverarbeitung und sodann regelmäßig von der Einhaltung der beim Auftragnehmer getroffenen technischen und organisatorischen Maßnahmen zu überzeugen. Dazu nun in 4. 4. Prüfungspflichten

413

Bei der Auswahl wird es demzufolge auch auf die „Überprüfbarkeit des Auftragnehmers“ ankommen – ein Problem, das insbesondere bei Cloud-Computing zusätzlich entsteht.

414

Im Rahmen von § 11 BDSG obliegen dem Auftraggeber in zwei Situationen Prüfungspflichten. Einmal ist der Auftragnehmer bereits unter besonderer Berücksichtigung der Eignung der von diesem getroffenen technischen und organisatorischen Maßnahmen sorgfältig auszuwählen (§ 11 Abs. 2 Satz 1 BDSG). Auch diese Regelung ist durch § 11 Abs. 5 BDSG pauschal „entsprechend“ anzuwenden. In der Regel wird aber der Auftragnehmer, der Software zu planen und zu erstellen, ggf. zu pflegen hat, keineswegs unter diesen Aspekten ausgewählt.

1 Zu den Defiziten bei der Vertragsgestaltung s.a. Vander, K&R 2010, 292.

308

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 418 C

Zudem hat der Auftraggeber sich vor Beginn der Datenverarbeitung und so- 415 dann regelmäßig von der Einhaltung der beim Auftragnehmer getroffenen technischen und organisatorischen Maßnahmen zu überzeugen (§ 11 Abs. 2 Satz 4 BDSG). Das bedeutet, dass es u.U. besonders wichtig sein kann, die Arbeiten des Auftragnehmers zeitlich genau zu fixieren, so dass vorher eine entsprechende Überprüfung möglich ist. Soweit es sich hierbei um gemeinsame Tests handelt, wird dies in der Regel einfach sein. Soweit der Auftragnehmer die Arbeiten alleine durchführt, wären insofern Pflichten zur rechtzeitigen Anzeige sinnvoll und nötig. Die Überprüfung des Auftragnehmers kann aufgrund räumlicher Entfernung 416 und evtl. fehlender Sachkunde seitens des Auftraggebers ein erhebliches wirtschaftliches Problem darstellen. Insofern stellt sich die Frage, ob Dritte, die ihrerseits wiederum Auftragnehmer des Auftraggebers sind, für diesen die Erstkontrolle und ggf. auch die weitere Kontrolle durchführen können1. 5. Anlage zu § 9 BDSG Zu § 9 BDSG enthält das Gesetz eine Anlage. Nach § 9 Satz 1 BDSG sind 417 „insbesondere die in der Anlage“ genannten Anforderungen zu gewährleisten. Satz 2 besagt wiederum, dass Maßnahmen nur erforderlich sind, „wenn ihr Aufwand in einem angemessenen Verhältnis zu dem angestrebten Schutzzweck steht“. Dieses spezifische Erforderlichkeitsprinzip ist also auf die acht sog. Kontrollen der Anlage anzuwenden. Die Anlage selbst besagt in Satz 2, dass insbesondere Maßnahmen zu treffen sind, die je nach der Art der zu schützenden personenbezogenen Daten oder Datenkategorien geeignet sind, die dann jeweils aufgeführten Kontrollen zu realisieren. Zusätzlich zu den acht Kontrollen ist in Abs. 2 vorgeschrieben, dass eine Maßnahme nach Satz 2 Nr. 2 bis 4 insbesondere die Verwendung von dem Stand der Technik entsprechenden Verschlüsselungsverfahren darstellt. Insofern sind also insgesamt neun Anforderungen zu erfüllen. Die Formulierung dieser Anforderungen entspricht weitgehend der alten 418 Konzeption eines Rechenzentrums, was sich darin äußert, dass es z.B. eine „Zutrittskontrolle“ (Nr. 1) und eine „Zugangskontrolle“ (Nr. 2) gibt. Insofern ist es den Adressaten weitgehend selbst überlassen, die längst überfällige „Modernisierung“ als Anpassung an die technische Entwicklung selbst vorzunehmen. Insofern gibt es zwei Maßgaben, die bei der Auswahl und Gestaltung der Maßnahmen zu beachten sind, nämlich einmal das geschriebene Merkmal der „Art der zu schützenden personenbezogenen Daten oder Datenkategorien“ und zum anderen das der technischen Ausgestaltung und Entwicklung (als ungeschriebenes Merkmal). Dieses zweite Merkmal lässt sich daraus ableiten, dass ansonsten die Maßnahmen ihren Zweck verfehlen würden. 1 S.a. Bergt, ITRB 2012, 45 zum Verfahren der „Überzeugung“ von der Datensicherheit beim Auftragsdatenverarbeiter.

Schneider

309

C Rz. 419

Verträge

419

Weiter ist den Interpretationsspielraum des Adressaten betreffend zu beachten, dass die Maßnahmen untereinander in einem konkreten Wirkungsverhältnis stehen. So wird eine organisatorische Maßnahme zusammen mit baulichen dafür sorgen können, dass gewisse Schranken gegenüber Zugang und Zutritt realisiert werden können, was wiederum das Risiko sonstigen Zugriffs, wenn die Daten nicht in einer Datenbank zur Verfügung stehen, verringern würde. Andererseits würde, wenn die Daten an jedem Arbeitsplatz zur Verfügung stehen, die Ausprägung personeller Maßnahmen nur bedingt greifen.

420

Von besonderer Bedeutung sind aber in jedem Fall neben den erwähnten Zutritts- und Zugangskontrollen die Anforderungen daran, dass eine Zugriffskontrolle zu erfolgen hat, ebenso eine Weitergabekontrolle und eine Eingabekontrolle sowie die so genannte Auftragskontrolle. Letztere hat zu gewährleisten, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers bearbeitet werden können. Das heißt, dass es neben den allgemeineren Vorgaben zu den Kontrollen auch eine ganz spezifische Maßgabe gibt, die Weisungen des Auftraggebers auch technisch zu realisieren. Wie schon oben angedeutet könnte es durchaus Probleme bereiten, dies in physikalische Kategorien umzusetzen, wenn es etwa um virtuelle Systeme, insbesondere Cloud Computing geht.

421

Heruntergebrochen auf das übliche Projektgeschehen heißt dies aber, dass etwa die Anforderungen von Testdaten, von Daten, mittels derer Mängel begutachtet werden können u.ä., jeweils spezifisch zu erfolgen haben und normalerweise ein permanenter Zugriff oder Zugang überhaupt nicht erforderlich sein dürfte. Die Auftragskontrolle könnte also dazu führen, dass stets erst ausdrückliche, technisch unterstützte Freigaben seitens des Auftraggebers mit Freischaltung es dem Auftragnehmer ermöglichen, die jeweilige Handhabung der Daten vorzunehmen.

422

Den Parteien ist allerdings anzuempfehlen, solche Handhabungen nicht nur im Vertrag festzulegen, sondern auch die Praxis entsprechend zu dokumentieren, so dass ggf. ein Nachweis möglich ist.

423

Hinsichtlich der Ausgestaltung können sich die Parteien auch an solchen Vorgaben, so insbesondere denen des BSI zum Grundschutz orientieren. Insofern ist die Grenze und Sicherung fließend, auch wenn diese unter einem anderen Aspekt bzw. einer anderen Zielsetzung erfolgt. Dazu werden in der Literatur durchaus die allgemeinen Kriterien bzw. Kategorien für die Datensicherung mit herangezogen, um die Auswahl der Maßnahmen mit beurteilen zu können, so etwa – Verfügbarkeit – Authentizität – Integrität1. 1 S. z.B. bei Gola/Schomerus, BDSG, 11. Aufl., § 9 Rz. 2.

310

Schneider

Rz. 426 C

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Was in der Praxis eigentlich erhebliche Schwierigkeiten bereiten müsste, 424 ist das Thema der Verhältnismäßigkeit bzw. der Erforderlichkeit. Hier wird dem Adressaten eine Last aufgebürdet, die der Gesetzgeber nicht übernehmen wollte, nämlich eine Kategorisierung der Daten und deren „Sensibilität“ sowie die Relevanz der einzelnen Vorgänge zu regeln, und sei dies anhand eines Schutzmodells der Persönlichkeit. Diese Aufgabe bleibt also dem Auftraggeber als „Herr der Daten“ überlassen. Seinen Ausdruck findet dies in entsprechend ausgefeilten Berechtigungskonzepten, Abschottungen, Penetrationstests u.ä. Ob solche im Rahmen eines Projektes schon erforderlich sind, wäre im Einzelfall zu prüfen, insbesondere, wenn der Kontakt bzw. die Gefahr des Kontakts mit den personenbezogenen Daten auf ein Minimum reduziert wird. 6. Echtdatentest Die evtl. sich aus dem Projekt ergebende Notwendigkeit, auch oder nur mit 425 Echtdaten zu testen, um bestimmte Fragen und Anforderungen zu klären, ist für sich gesehen kein ausreichender Grund, um personenbezogene Daten zu verarbeiten, insbesondere, wenn es sich um Mitarbeiterdaten handelt. Die Zulässigkeit hängt davon ab, ob eine entsprechende Norm, insbesondere § 28 BDSG, greift. Dem steht zum einen entgegen, dass § 32 BDSG, wie erwähnt, Spezialgesetz ist. Mit der wohl h.M. wird man aber weiterhin von einer Anwendbarkeit des § 28 BDSG ausgehen können, soweit es nicht um die Verarbeitung im Rahmen des Mitarbeiterverhältnisses geht. Dies wird zwar später bei der Anwendung des Systems der Fall sein, bei den Tests aber noch nicht. Voraussetzung ist aber des Weiteren, dass eine der Varianten des § 28 Abs. 1 BDSG einschlägig ist, so z.B., dass die Verarbeitung zur Wahrung berechtigter Interessen der verantwortlichen Stelle erforderlich ist. Dann darf aber als zusätzliches Erfordernis „kein Grund zu der Annahme bestehen, dass das schutzwürdige Interesse des Betroffenen an dem Ausschluss der Verarbeitung und Nutzung überwiegt“. Dies muss also im Einzelfall geprüft werden. Ansonsten ist der Echtdatentest unzulässig. Zugleich sind wieder die Gebote der Datenvermeidung und Datensparsamkeit zu berücksichtigen. Es stellt sich also auch insofern die Frage, ob ein Massentest erforderlich ist, mithin sämtliche Daten aller Mitarbeiter eingegeben und verarbeitet werden müssen. Falls ein Echtdatentest erforderlich ist, ist zu berücksichtigen1:

426

– Das zu testende IT-System muss vorab nach den Regeln der Softwaretechnik umfassend mit nicht personenbezogenen Testdaten getestet worden sein (insbesondere hin sichtlich Programmverzweigungen, Fehler-

1 Conrad, Kölner CR-Tage, 12.3.2010: Profilbildung und Datenabgleich im Konzern. Weiterführende Hinweise. 3. Tätigkeitsbericht des LDSB Mecklenburg-Vorpommern, 1996/1997; Bericht des Berliner LDSB 1999, 4.4.3 und Stellungnahme des Senats, Drucks. 14/1328, S. 18.

Schneider

311

C Rz. 427

– – –

– –

–

Verträge

robustheit etwa bei falschen Eingaben, Fehlerbehandlung und Zusammenspiel mit anderen Programmen/Modulen). Die Gründe, warum ein Test mit Testdaten nicht ausreicht und Echtdaten benötigt werden, sind detailliert zu dokumentieren. Der Test ist zeitlich auf das notwendige Minimum zu beschränken. Die Originaldatenbank darf nur dann für Testzwecke genutzt werden, wenn eine vollständige Sicherungskopie unmittelbar vor Testbeginn angelegt worden ist. Die personenbezogenen Daten müssen genauso gegen unberechtigte Zugriffe und Manipulation geschützt sein wie im Produktivbetrieb. Zugriffsrechte für den Test dürfen nur solche Personen erhalten, die auch im Echtbetrieb z.B. mit der Finanzsoftware arbeiten. Ihre Zugriffsrechte für den Test dürfen die ihnen für den Echtbetrieb eingeräumten Rechte nicht übersteigen. Andere Personen dürfen nur unter Aufsicht Zugriff auf die Anlagen haben. Fernzugriff, etwa Fernwartung, ist für diese Personengruppe ausgeschlossen. Unverzüglich nach Testende müssen alle beim Test eingesetzten personenbezogenen Daten gelöscht und der ursprüngliche Zustand durch Einspielen der Sicherungskopie wieder hergestellt werden.

7. Vertragliche Regelung, Einzelfragen 427

Bei Betreuung durch den Auftragnehmer, wie dies etwa bei Einführungsunterstützung oder bei vorweggenommener, paralleler Pflege u.ä. der Fall sein kann, sollte der Versuch unternommen werden, zunächst den RemoteZugriff zu regeln. Damit kann dem Datenvermeidungsgebot weitgehend Rechnung getragen werden, indem ein Verfahren gewählt wird, aufgrund dessen der Kontakt praktisch vermieden wird, der Auftragnehmer also grundsätzlich nicht mit personenbezogenen Daten in Berührung kommen muss, und wenn doch, dann unter sehr kontrollierten Bedingungen. Der folgende Vorschlag will vorsorglich die nötigen Voraussetzungen schaffen1: – Der Auftraggeber räumt dem Auftragnehmer im Rahmen seiner Mitwirkung die Berechtigung für den Fernzugriff/Remote-Zugriff ein, soweit der Auftragnehmer zur Durchführung seiner Leistungen dieses Zugriffs bedarf. Der Auftragnehmer kann diese Rechte nur dann durch Dritte ausüben lassen, also Subunternehmer, wenn deren Einschaltung der Auftraggeber vorher zugestimmt hat. Diese Vereinbarung hat schriftlich zu erfolgen. – Der Umfang dieser Zugriffsberechtigungen ist grundsätzlich auf die bloße Kenntnisnahme des Inhalts von Daten, nicht auf deren Änderung, Löschung o.ä. bezogen. Diese Berechtigung darf der Auftragnehmer nur zu dem Zweck der Erfüllung seiner Aufgaben aus dem Hauptvertrag, also 1 Formulierungsvorschlag in Anlehnung an Conrad, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 9 Rz. 95 (S. 511 f.).

312

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

–

–

–

–

Rz. 428 C

dem Vertrag zu Planung, Erstellung, Anpassung und Pflege, ausüben und dies nur, soweit unbedingt erforderlich. Bevor der Auftragnehmer seinerseits den Fernzugriff ausübt, wird er dem Auftraggeber hiervon Mitteilung machen und diese Ausübung ankündigen. Insofern reicht E-mail (zu den Kontaktdaten der Ansprechpartner beider Parteien, deren Verbindlichkeit und evtl. Änderung s. …). Diese Ankündigung hat so rechtzeitig zu erfolgen, dass dem Auftraggeber die Zeit bleibt, ggf. erforderliche Sicherungsmaßnahmen vor diesem Zugriff durchzuführen und nach Möglichkeit auch den geplanten Zugriff sämtliche personenbezogene Daten bzw. weitmöglich zu entziehen. Des weiteren wird dem Auftraggeber Gelegenheit gegeben, den ggf. zu erfolgenden Zugriff seinerseits zu beobachten und zu dokumentieren/zu protokollieren. Weitere Handlungen im Umgang mit personenbezogenen Daten, so insbesondere das Herunterladen der Daten auf Datenträger bzw. Rechner des Auftragnehmers, das Überspielen kompletter Files oder Datenbanken oder auch nur einzelner Datensätze mit personenbezogenen Daten sind grundsätzlich nicht erlaubt. Wenn dies, so insbesondere zum Zwecke der Fehleranalyse erforderlich ist, wird der Auftragnehmer hiervon den Auftraggeber rechtzeitig vorher in Kenntnis setzen und von diesem schriftlich die Zustimmung einholen. Hierfür wird der Auftragnehmer genau beschreiben, welchen Gebrauch er von diesen Daten machen will. Dem Auftragnehmer ist es nur erlaubt, insgesamt von seinen Zugriffsrechten, seien diese pauschal eingeräumt, seien diese im Einzelfall gewährt, nur in dem für die Durchführung seiner Aufgaben gemäß (Haupt-)Vertrag vom …1 und im tatsächlich erforderlichen Umfang Gebrauch zu machen. Die Daten unterliegen strikter Zweckbindung. Für andere Zwecke dürfen diese Daten nicht verwendet werden. Dies gilt auch für nicht-personenbezogene Daten. Soweit die Daten dazu geeignet sind bzw. das Datenträgermaterial, wird der Auftragnehmer nach Beendigung der Arbeiten die entsprechenden Daten dem Auftragnehmer samt diesem Material wieder zurück geben, ansonsten die Daten bei sich löschen.

Etwaige Betretungs- und Besichtigungsrechte im Übrigen, so etwa für das 428 Rechenzentrum des Auftragnehmers oder ein Backup-Rechenzentrum bei Dritten wären gesondert zu regeln. Hier greift insbesondere die Anlage zu § 9 BDSG etwa mit der Zutrittskontrolle. Solche Rechte sind zudem notwendiger Inhalt im Hinblick auf die Betretungsrechte der Aufsichtsbehörde (§ 38 Abs. 4 BDSG).

1 Es kommen verschiedene Verträge als in Bezug zu nehmende Hauptverträge in Betracht. Wird der Vertrag zur Auftragsdatenverarbeitung schon bei Beginn des Projekts geschlossen, können sich die folgenden Verträge, etwa zur Planung (s. Kap. C), zur Erstellung (s. Kap. G), Anpassung (s. Kap. G) und Pflege (s. Kap. I) darauf beziehen.

Schneider

313

C Rz. 429

Verträge

429

Am besten ist es, wenn einzelne Zugriffe jeweils streng wie eine einzelne Weisung behandelt werden, also insofern auch das übliche Verfahren greift. Somit kann man für diese einzelnen Zugriffe „Tickets“ vergeben, denen der Auftraggeber entsprechend zustimmt, und diese Tickets dann auch zum Zweck des Nachweises einsetzen. Damit wären auch regelmäßige Kontrollen bzw. Nachforschungen, ob im Nachgang zu konkreten Zugriffen auch die Löschungen erfolgen, möglich.

430

Zu beachten ist auch, dass evtl. zwar der Auftrag bzw. der generelle Vertrag zwischen Auftraggeber und Auftragnehmer zivilrechtlich geregelt ist, der Auftraggeber aber dem Recht der öffentlichen Stellen unterliegt. Für diese gelten je nach Bundesland leicht unterschiedliche Maßgaben gemäß dem jeweiligen Landesdatenschutzgesetz, die evtl. zu beachten sind. Grundsätzlich ist es Sache des Auftraggebers, auf diese Besonderheiten zu achten und sie durchzusetzen1.

431

Insgesamt muss der Vertrag zur Auftragsdatenverarbeitung daran ausgerichtet sein, dass der Auftraggeber „Herr der Daten“ bleibt und dieses Prinzip nicht durch anderweitige Bestimmungen, die möglicherweise in einem anderen Zusammenhang stehen, ausgehöhlt wird. Ein kritischer Punkt bei Outsourcingprojekten ist u.U. die Herausgabe der Daten während des laufenden Betriebs bzw. des laufenden Vertrags. Es kann, nicht zuletzt auch zur Vorbereitung des Umstiegs auf einen anderen Auftragnehmer, erforderlich sein, die Daten schon vor Vertragsende zurück zu erhalten. Dies muss gewährleistet sein. Evtl. Mehrkosten sollten allerdings auch geregelt sein. Das Thema tritt in der Regel bei Projekt- und Pflegeverträgen seltener auf. Wichtig ist aber, dass auch hier immer klar ist, dass der Auftraggeber Herr der Daten ist. Ein Widerspruch dazu könnte entstehen, wenn es etwa um Rechte an Datenbanken, Datenbanksystemen u.ä. geht. Hier ist stets zwischen dem Content, also den Daten, und den entsprechenden Rechten des Auftraggebers und evtl. Rechten an der Software seitens des Auftragnehmers zu unterscheiden. Dies gilt insbesondere dann, wenn etwa für Übergangszeiten (vor Abnahme, vor endgültiger Einführung u.ä.) der Betrieb des Systems durch den Auftragsnehmer (evtl. sogar parallel) erfolgt.

432

Weiter ist im Hinblick auf die Laufzeit dieser Verträge zu beachten, dass keine schlichte Synchronisierung erfolgen sollte. Die Auftragsdatenverarbeitung regelt etwa das Datengeheimnis, das auch nach Ende des Hauptvertrags weiter gilt.

433

Kritisch kann es zudem sein, dass die Leistungen zu einem Gesamtsystem im Rahmen eines Projekts von mehreren Auftragnehmern erbracht werden,

1 Zu den evtl. Abweichungen im Bereich der Landesdatenschutzgesetze insofern s. Conrad, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 9 Rz. 100, mit weiteren Praxistipps und einem tabellarischem Vergleich des landesdatenschutzgesetzlichen Anforderungen an die Auftragsdatenverarbeitung, Wartung und Pflege.

314

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 437 C

die sämtlich entsprechende Auftragsdatenverarbeitungsverträge abgeschlossen haben. Beim „Zusammenfügen“ der verschiedenen Bausteine übergibt dann ggf. der eine Auftragnehmer datenschutzrelevantes Material an den anderen Auftragnehmer. Insofern wäre klarzustellen, dass dies im Rahmen einer entsprechenden Weisung des Auftraggebers geschieht, wenn dies nicht ohnehin im Vertrag ausdrücklich geregelt ist. Ein besonderes Problem im Hinblick auf den Datenschutz könnte die Kon- 434 stellation agiler Programmierung bzw. des Einsatzes entsprechender Werkzeuge hervorrufen: Für solche Methoden ist typisch, dass ganze User-Gruppen bzw. einzelne User ihre „Wünsche“ in Tickets äußern und diese gespeichert werden, um sie dann – nach einer gewissen Selektion und Bearbeitung – für die Umsetzung aufzubereiten und schließlich in den typischen Verfahren wie etwa Scrum zu realisieren und vorzuführen. In diesen Fällen ist es durchaus möglich, dass der jeweilige Autor zwar nicht mehr bei der einzelnen Umsetzung genannt ist, die Tickets jedoch, nicht zuletzt wegen der Erstellung des Pflichtenhefts bzw. dessen Kontrolle, aufbewahrt werden. So entsteht im Laufe der Zeit eine Art Katalog der Wünsche verschiedener User. Dass es sich hierbei auch um personenbezogene Daten handelt, nicht nur Tickets als Anforderungen an das System, liegt auf der Hand. Ganz ähnlich verhalten sich die Dinge auch mit Files bzw. Systemfunktionen, die es den Mitarbeitern erlauben, ein System mit ihren eigenen persönlichen Geräten zu nutzen (Bring your own Device – BoyD)1. Hier stellt sich u.U. die Frage, inwieweit es sich um Daten im Rahmen des Mitarbeiterverhältnisses handelt. Wie auch bei Scrum können zudem Aufzeichnungen vorliegen, die eine Verhaltenskontrolle ermöglichen. Die objektive Eignung genügt. Dies löst Mitbestimmungstatbestände aus2.

435

Zu beobachten wird weiter sein, ob die Novelle des Beschäftigtendaten- 436 schutzes, also die Ausdifferenzierung zu § 32 BDSG erfolgt und wenn ja, ob dies wie geplant geschieht. Es liegt ein Entwurf vom 25.8.2010 vor, der allerdings heftig kritisiert wurde. Auch wird sich wieder die Frage stellen, in welchem Verhältnis § 28 BDSG dazu steht. 8. Einwilligung, Datenschutzerklärung Als Kardinal-„Heilmittel“ für die datenschutzrechtliche Zulässigkeit, seien 437 es eigene Tests, seien es Tests durch Dritte oder anderweitige Weitergaben der Daten, insbesondere, wenn nicht sichergestellt ist, dass § 11 BDSG voll erfüllt ist, erscheint die Einwilligung der Betroffenen. Allein schon deshalb, weil häufig in einem Betrieb nicht sämtliche Mitarbeiter zustimmen, ist

1 S. dazu z.B. Conrad/Schneider, ZD 2011, 153. 2 S. zur Frage der Überwachung der Mitarbeiter und der Mitbestimmung insofern: Conrad, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 25 Rz. 159 ff.

Schneider

315

C Rz. 438

Verträge

dies jedoch gerade kein probates Mittel. Zudem muss die Einwilligung bestimmte Bedingungen erfüllen, insbesondere ausreichend transparent sein. Der Einwilligende muss genau wissen, worin er einwilligt. Diese Bestimmtheitsanforderungen können mit den Eventualitäten, die bei einem komplexen Projekt auftreten können, durchaus in Kollision geraten. 438

Es wird sich also empfehlen, eine Datenschutz-Geheimhaltungsvereinbarung zusätzlich zu treffen und die Zulässigkeit der Verarbeitung strikt an § 11 BDSG zu orientieren, soweit Auftragsdatenverarbeitung direkt oder analog einzuhalten ist. 9. Auftragnehmer im Nicht-EU-/-EWR-Ausland

439

Wenn der Auftragnehmer im Nicht-EU-Ausland sitzt, ist dies so nicht machbar. Dann müssen andere Instrumente, wie die EU-Standardvertragsklauseln oder, wenn der Auftragnehmer in USA sitzt, das Safe Harbor-Konzept gewählt werden.

440

Theoretisch kommt auch die Verwendung von Binding Corperate Rules (BCR) in Betracht1. Wichtige Handreichung für BCR ist das „Arbeitsdokument mit einer Übersicht über die Bestandteile und Grundsätze verbindlicher unternehmensinterner Datenschutzregelungen (BCR)“ v. 24.6.2008, Working Paper 153 der Art. 29 Datenschutzgruppe (for Controllers)2. Gemäß diesem Working Paper haftet die Hauptniederlassung in der EU bzw. ein von der Unternehmensgruppe benanntes Gruppenmitglied, das in der EU ansässig ist, für evtl. Verstöße aller verbundenen Unternehmen außerhalb der EU3. BCR sind im Ergebnis Erleichterungen für die Datentransfers mit Drittländern unsicheren Datenschutzniveaus4. BCR sind aber in ihrer Handhabung bzw. Durchsetzung einschließlich Genehmigung äußerst aufwendig.

441

Insofern ist es wesentlich einfacher, wenn der Auftragnehmer in USA sitzt, sich über Safe Harbor abzusichern5. Gegenüber Safe Harbor bestehen aller-

1 S.a. Grapentin zur Haftung und zum anwendbaren Recht im internationalen Datenverkehr, CR 2011, 102, und zu den Binding Corporate Rules, CR 2009, 693. S.a. Hoeren, RDV 2012, 271. 2 Zum Überblick und als Checkliste der Elemente und Prinzipien s. WP 195 (Working Doc. 02/2012) mit „tools to faciliate the use of BCR für Processors“, und WP 204. 3 S. zu BCR Grapentin, Datenschutz und Globalisierung – BCR als Lösung?, CR 2009, 693; Grapentin, Haftung und anwendbares Recht im internationalen Datenverkehr, CR 2011, 102 (104 f.). 4 S. – vor dem Hintergrund des Entwurfs zu einer DS-GVO – Traung, CRi 2012, 33 (47), v.a. Fn. 97. 5 S. Hennrich, CR 2011, 546 m.w.N. (Fn. 26); „bewährtes“ Instrument: Greer, RDV 2011, 267.

316

Schneider

Beratung bei Projekt-Verträgen bis einschließlich Pflichtenheft

Rz. 443 C

dings wegen der eingeschränkten Aussagekraft der Zertifikate erhebliche Bedenken bei den Aufsichtsbehörden, insbesondere bei Cloud1. Ansonsten dürfte die Alternative v.a. zu BCR sein, die EU-Standardvertrags- 442 klauseln für die Auftragsdatenverarbeitung zu verwenden2. 10. Geheimhaltungsvereinbarung Bei sämtlichen Vereinbarungen im genannten Rahmen ist darauf zu achten, 443 dass neben dem Datenschutz auch das Interesse des Auftraggebers an Geheimhaltung zu erfüllen ist. Für viele Auftraggeber ist die Geheimhaltungsvereinbarung wichtiger als die Datenschutzthematik. Wesentlich ist, dass sie einerseits als gleichwertig zu sehen und andererseits zu harmonisieren sind. Die Überprüfung der Geheimhaltung setzt nämlich gewisse Kontrollmechanismen in Gang, die wiederum mit dem Datenschutz in Konflikt geraten können. Damit sind auch arbeitsrechtliche Probleme, so etwa unter dem Aspekt des sog. Screenings, verbunden. Auch stellt sich die arbeitsrechtliche Frage, ob die Mitarbeiter der Auftragnehmers es etwa hinnehmen müssen, in solche Screenings einbezogen zu werden. Dies betrifft unter Umständen auch die Überwachung des E-Mail-Verkehrs u.ä., womit erhebliche Datenschutzfragen, aber auch Fragen des Rechts auf informationelle Selbstbestimmung bis hin zum Fernmeldegeheimnis verbunden sind3.

1 S. z.B. www.datenschutzzentrum.de/cloud-computing, Ziff. 11. S. dazu z.B. Niemann/Hennrich, CR 2010, 686. Zu den Anforderungen an Cloud s. Schröder/ Haag, ZD 2011, 147; Schröder/Haag, ZD 2012, 362; Schuppert/von Reden, ZD 2013, 210. Zu Problemen wg US Patriot Act s. Becker/Nikolaeva, CR 2012, 170. 2 Entscheidung der Kommission v. 5.2.2010 über Standardvertragsklauseln für die Übermittlung personenbezogener Daten an Auftragsdatenverarbeiter in Drittländern nach der RL 95/46/EG des Europäischen Parlaments und des Rates (Standardvertragsklauseln für Auftragsdatenverarbeiter), ABl. EU-Nr. L 39 v. 12.2.2010, 5. Dazu Moos, CR 2010, 281. 3 Zum Thema der Überwachung in diesem Sinne s. Wybitul, ZD 2011, 69; Greening/Weigl, CR 2012, 787.

Schneider

317

D. Realisierung (Kauf-/Werkvertrag)

I. Vorvertragliche Beziehungen . . 1. Aufklärungs- und Beratungspflichten . . . . . . . . . . . . . . . . . . . . a) Hinweis auf Leistungsbeschreibung . . . . . . . . . . . . . . b) Beratung zur Systemumgebung. . . . . . . . . . . . . . . . . c) Weitere Beratungspflichten . 2. Gescheiterte Vertragsverhandlungen . . . . . . . . . . . . . . . . . . . . . . 3. Absichtserklärung (insbesondere „Letter of Intent“). . . . . . . . II. Vertragliche Pflichten . . . . . . . . 1. Übersicht über mögliche Leistungen . . . . . . . . . . . . . . . . . . a) Erstellung von Software . . . . b) Lieferung und Anpassung von Software . . . . . . . . . . . . . . c) Lieferung und Parametrisierung von Standardsoftware . . d) Anpassung von Standardsoftware . . . . . . . . . . . . . . . . . . e) Parametrisierung von Standardsoftware . . . . . . . . . . f) Installation, Einweisung und Schulung. . . . . . . . . . . . . . g) Übernahme von Altdaten (Migration) . . . . . . . . . . . . . . . . h) Verantwortungsbereiche . . . . 2. Rechtliche Einordnung . . . . . . . a) Problemstellung . . . . . . . . . . . b) Werk- oder Dienstvertrag . . . aa) Grundsätze . . . . . . . . . . . . bb) Einfluss der Verantwortungsbereiche . . . . . . . . . . c) § 651 BGB . . . . . . . . . . . . . . . . . d) Sacheigenschaft von Software . . . . . . . . . . . . . . . . . . e) Einordnung der Softwareerstellungsverträge . . . . . . . . . aa) Erstellung von Software. . . . . . . . . . . . . . . . . . . bb) Lieferung und Anpassung von Standardsoftware. . . . . . . . . . . . . . . . . . .

Rz.

Rz.

1

cc) Lieferung und Parametrisierung von Standardsoftware . . . . . . . . . . . . . . . 90 dd) Anpassung von Standardsoftware . . . . . . . . . . . 95 ee) Parametrisierung von Standardsoftware . . . . . . . 98 ff) Installation, Einweisung und Schulung . . . . . . . . . . 99 gg) Altdatenübernahme (Migration) . . . . . . . . . . . . . 101 hh) Agile Softwareentwicklung . . . . . . . . . . . . . . . . . . . 108 Nebenpflichten . . . . . . . . . . . . . . 119 a) Lieferung von Dokumentationen. . . . . . . . . . . . . . . . . . . . . 119 aa) Benutzerhandbuch und Programmhilfen . . . . . . . . 119 bb) Weitere Dokumentationen . . . . . . . . . . . . . . . . . 126 cc) Rechtsfolgen der Nichtlieferung . . . . . . . . . . . . . . . 134 b) Lieferung von Quellcode und Datenmodellen . . . . . . . . 136 c) Beratungspflichten . . . . . . . . . 139 Fehlen des Pflichtenheftes . . . . . 146 a) Grundsätzliches . . . . . . . . . . . 146 b) Fehlende Mitwirkung des Auftraggebers . . . . . . . . . . . . . . 148 c) Pflichtverletzung des Softwareerstellers . . . . . . . . . . . . . . 150 Änderung des Pflichtenprogramms . . . . . . . . . . . . . . . . . . . . . 156 a) Grundproblem . . . . . . . . . . . . . 156 b) Vereinbartes Verfahren . . . . . 162 c) Stillschweigende Änderungen . . . . . . . . . . . . . . . . . . . . 167 d) Zustimmungspflicht des Softwareerstellers . . . . . . . . . . 174 Fälligkeitsregelungen . . . . . . . . . 178 Abnahme . . . . . . . . . . . . . . . . . . . . 194 a) Abnahmeverfahren . . . . . . . . . 194 b) Stillschweigende Abnahme . 207 c) Fiktion einer Abnahme . . . . . 215 d) Wirksamkeit von Abnahmeklauseln . . . . . . . . . . . . . . . . 217

4 4 16 18 21 34 42

3.

42 42 46 47 48 50 51 52 53 55 55 56 56

4.

5.

60 67 71 73 73

81

6. 7.

Redeker

319

D

Verträge Rz.

Rz.

8. Mitwirkung des Bestellers. . . . . 223 a) Umfang der Mitwirkungshandlungen . . . . . . . . . . . . . . . 223 b) Gesetzliche Regelung . . . . . . 232 c) Pflichten statt Obliegenheiten . . . . . . . . . . . . . . . . . . . . 237

cc) Sonstige Pflichten. . . . . . . 425 d) Obliegenheiten und Pflichten des Bestellers . . . . . . . . . . . 428 aa) Obliegenheitsverletzungen . . . . . . . . . . . . . . 428 bb) Pflichtverletzungen . . . . . 429 cc) Fehlende Abnahme . . . . . 431 e) Kündigung und Rücktritt . . . 432

III. Leistungsstörungen . . . . . . . . . . 245 1. Mangelhafte Leistung. . . . . . . . . 245 a) Definition des Mangels . . . . . 246 b) Einzelne Beispiele von Mängeln . . . . . . . . . . . . . . . . . . 260 c) Gleichgestellte Probleme . . . 275 2. Rechtsfolgen von Mängeln . . . . 277 a) Werkvertrag . . . . . . . . . . . . . . . 277 aa) Bedeutung der Abnahme 277 bb) Nacherfüllungsansprüche . . . . . . . . . . . . . 282 cc) Voraussetzungen weiterer Mängelansprüche . . 291 dd) Selbstvornahmerecht . . . 295 ee) Minderung und Rücktritt . . . . . . . . . . . . . . . . . . . 296 ff) Schadensersatz . . . . . . . . . 310 gg) Verjährung . . . . . . . . . . . . . 326 (1) Herstellung von Software . . . . . . . . . . . . 326 (2) Bearbeitung von Software . . . . . . . . . . . . 342 hh) Garantien . . . . . . . . . . . . . . 346 ii) Insbesondere: Rechtsmängel . . . . . . . . . . . . . . . . 351 b) § 651 BGB . . . . . . . . . . . . . . . . . 362 aa) Nacherfüllungsanspruch 362 bb) Minderung und Rücktritt . . . . . . . . . . . . . . . . . . . 369 cc) Schadensersatz . . . . . . . . . 370 dd) Verjährung . . . . . . . . . . . . . 371 ee) Rügeobliegenheit . . . . . . . 373 ff) Insbesondere Rechtsmängel . . . . . . . . . . . . . . . . 377 3. Sonstige Leistungsstörungen . . 380 a) Nichterfüllung und Unmöglichkeit . . . . . . . . . . . . 380 b) Verzug . . . . . . . . . . . . . . . . . . . . 388 c) Verletzung sonstiger Pflichten des Lieferanten . . . . . . . . . 414 aa) Beratungspflichten. . . . . . 414 bb) Geheimhaltungspflichten . . . . . . . . . . . . . . . 418

320

Redeker

IV. Gestaltungsvorschläge . . . . . . . . 454 1. Vorvertragliche Regelungen . . . 455 a) Grundsätzliche Bemerkungen . . . . . . . . . . . . . . . . . . . . 455 b) Formulierungen. . . . . . . . . . . . 457 aa) Geheimhaltungsvereinbarung . . . . . . . . . . . 457 bb) Aufwandsvereinbarung . . 459 2. Organisationsregeln . . . . . . . . . . 466 a) Umfassende Regeln . . . . . . . . 466 b) Vereinfachte Regelungen für einfache Projekte. . . . . . . . . . . 473 3. Change-Request-Verfahren . . . . 474 a) Bedeutung der Regelung . . . . 474 b) Möglichkeiten von Schriftformklauseln . . . . . . . . . . . . . . 477 4. Geltendmachung von Rechten durch Dritte . . . . . . . . . . . . . . . . . 481 a) Problemstellung . . . . . . . . . . . 481 b) Regelungsmöglichkeiten . . . . 484 aa) Prozessuale Situation ohne Regelung. . . . . . . . . . 484 bb) Regelungsmöglichkeiten 487 5. Abnahmeklauseln . . . . . . . . . . . . 494 6. Verjährungsklauseln . . . . . . . . . . 499 a) Bei der Erstellung von Software . . . . . . . . . . . . . . . . . . 500 b) Bei Anwendung des § 651 BGB . . . . . . . . . . . . . . . . . . . . . . 503 7. Mängelrechte . . . . . . . . . . . . . . . . 505 a) Umfassende Klauseln. . . . . . . 506 b) Klauseln zur Nacherfüllungspflicht . . . . . . . . . . . . . . . 507 aa) Inhalt der Nacherfüllungspflicht . . . . . . . . . . . . 507 bb) Wahlmöglichkeiten . . . . . 511 8. Schadensersatzansprüche . . . . . 513 9. Vergütungsregelung nach Kündigung . . . . . . . . . . . . . . . . . . . 519

Realisierung (Kauf-/Werkvertrag)

Rz. 6

D

I. Vorvertragliche Beziehungen Rechtliche Beziehungen zwischen zwei künftigen Vertragsparteien beginnen nicht erst mit dem Vertragsschluss. Mit der ersten Kontaktaufnahme gibt es gegenseitige Pflichten, deren Umfang mit sich verstärkendem Kontakt zunimmt. Zu diesen Pflichten gehören Schutzpflichten, aber vor allem auch Aufklärungs- und Beratungspflichten.

1

Ihre Verletzung kann gem. § 311 Abs. 2 i.V.m. § 241 Abs. 2 BGB einen Schadensersatzanspruch zur Folge haben.

2

Im Zusammenhang mit Softwareerstellungsverträgen ergeben sich hier spezielle Probleme insbesondere im Hinblick auf die Verletzung von Aufklärungs- und Beratungspflichten.

3

1. Aufklärungs- und Beratungspflichten a) Hinweis auf Leistungsbeschreibung Die Grundlage der eben angesprochenen Aufklärungs- und Beratungspflich- 4 ten als vorvertragliche Pflichten des jeweiligen Softwareerstellers ist die Tatsache, dass hauptsächlich dieser über die entsprechende Sachkunde in DV-technischer Hinsicht verfügt und er besser als der Auftraggeber einschätzen kann, wozu die von ihm herzustellende oder anzupassende Software in der Lage ist bzw. welche Unterlagen und Darstellungen er braucht, um eine den Wünschen des Auftraggebers entsprechende Software herzustellen oder eine vorhandene Standardsoftware an die Bedürfnisse des Auftraggebers anzupassen. Dieser Gesichtspunkt der überlegenden Kenntnis hat eine zentrale Rolle in allen Entscheidungen gespielt, in denen solche Aufklärungs- und Beratungspflichten angenommen worden sind1. Im Rahmen von Softwareerstellungsverträgen kann man auch davon ausgehen, dass der Softwareersteller sachkundig ist. Dass es solche Aufklärungs- und Beratungspflichten im vorvertraglichen 5 Stadium gibt, ist im Prinzip unstreitig. Äußerst streitig ist freilich, in welchem Umfang sie bestehen und welche Leistungen ein potentieller Softwareerwerber nur dann erwarten kann, wenn er einen entgeltlichen Beratungsvertrag abgeschlossen hat2. Hier wird viel auf den Einzelfall ankommen. Für den Umfang der Aufklä- 6 rungs- und Beratungspflichten kommt es dabei nicht nur auf die oben schon erwähnte Fachkunde des Anbieters oder den Umfang des möglichen Auf1 Grundlegend BGH v. 6.6.1984 – VIII ZR 83/83, CR 1986, 79 = MDR 1985, 316 = NJW 1984, 2938; beispielhaft OLG Celle Zahrnt, ECR OLG 175; OLG Koblenz v. 11.11.1998 – 2 U 4/86, CR 1990, 41 (43); aus der Literatur Marly, Praxishandbuch Softwarerecht, Rz. 1116 ff.; Schneider, Handbuch des EDV-Rechts, D Rz. 226 ff.; Hörl, ITRB 2004, 39. 2 Dazu insbesondere Schneider, Handbuch des EDV-Rechts, D Rz. 227 ff.; Marly, Praxishandbuch Softwarerecht, Rz. 1116 ff.

Redeker

321

D Rz. 7

Verträge

trags an, vielmehr spielt auch die Fachkunde des Kunden eine wichtige Rolle. Je fachkundiger der Kunde ist, desto weniger gibt es Aufklärungs- und Beratungspflichten. Dabei kommt es darauf an, ob der Kunde im Hinblick auf das konkrete Projekt fachkundig ist. So wird ein Unternehmen, das sich seit Jahren mit einer speziellen Form von Softwareanwendung beschäftigt und eine entsprechende Abteilung unterhält, möglicherweise keine Sachkunde in der Kommunikationssteuerung haben und deswegen bei Erwerb eines Kommunikationssteuerungsprogramms bzw. einer dazugehörigen Hardware möglicherweise nicht viel sachkundiger sein als ein Unternehmen ohne eigene EDV-Abteilung1. 7

Bei der Frage, ob bestimmte Aufklärungs- und Beratungspflichten bestehen, kommt es ferner auf den Inhalt der Pflichten an. Der Kunde kann sicher eher erwarten, dass Hinweise auf fehlende Unterlagen, fehlende Untersuchungen u.Ä. erteilt werden, als dass ihm ohne entsprechenden entgeltlichen Auftrag umfangreiche Ausarbeitungen darüber gemacht werden, ob die anzustrebende Softwarelösung überhaupt möglich ist.

8

Im Allgemeinen muss davon ausgegangen werden, dass der Softwarelieferant verpflichtet ist, den Kunden auf die Tatsache hinzuweisen, dass für die Softwareerstellung und auch für die Erstellung seines Angebots zentrale Unterlagen fehlen und noch erstellt werden müssen. In der Rechtsprechung und der Literatur ist insbesondere davon die Rede, dass der Lieferant darauf hinweisen muss, dass eine Softwareerstellung ohne Pflichtenheft sinnvollerweise nicht möglich ist2. Gemeint ist damit, dass insbesondere darauf hingewiesen werden muss, dass die Erarbeitung eines Dokuments (meist Pflichtenheft, gelegentlich auch Lastenheft genannt)3, erforderlich ist, mit dem der Kunde funktionell beschreibt, welche Anforderungen die vom Lieferanten herzustellende Software in seinem Betrieb erbringen muss.

9

Die Rechtsprechung ist oft schon viel weiter gegangen und hat verlangt, dass der Lieferant systematisch Fragen stellt, z.B. den Umfang der anfallenden Daten ermittelt, wenn es auf diese Frage ankommen kann4. Auch ist schon entschieden worden, dass der Softwarelieferant einen Organisationsvorschlag unterbreiten soll, wenn der Besteller eine Umorganisationen seines Betriebes beabsichtigt5.

1 Ausführlich zu den verschiedenen Gesichtspunkten, die den Umfang der Aufklärungs- und Beratungspflichten betreffen: Marly, Praxishandbuch Softwarerecht, Rz. 1116 ff.; Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 21 ff. 2 Hörl, ITRB 2004, 39 (40); Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 16; zum Inhalt eines Pflichtenheftes vgl. Müller-Hengstenberg, CR 2005, 385 (389 f.). 3 Zur Begrifflichkeit vgl. Kap. C Rz. 80 ff. 4 OLG Koblenz v. 11.11.1988 – 2 U 4/86, CR 1990, 41 (43); ähnlich auch OLG Köln v. 6.3.1998 – 19 U 228/97, CR 1998, 459 = NJW-RR 1999, 51. 5 OLG Hamm v. 23.11.1988 – 31 U 63/88, CR 1989, 498 (LS).

322

Redeker

Realisierung (Kauf-/Werkvertrag)

D

Rz. 12

Insbesondere die Anforderungen der Entscheidung des OLG Hamm1 über- 10 schreiten aber den Umfang dessen, was ein Unternehmen ungefragt tun muss, wenn Verhandlungen über Softwareerstellung beginnen. Unzweifelhaft muss der Softwareunternehmer darauf hinweisen, dass zur Erarbeitung der Software, möglicherweise auch schon zur Erstellung eines entsprechenden Angebots der Kunde bestimmte Datenmengen, einen bestimmten Datendurchsatz u.Ä. ermitteln muss, die bei ihm anfallen. Ohne solche Angaben kann die Software, die erstellt werden soll, ihre Aufgaben nicht erfüllen. Ohne entsprechenden Auftrag, diese Informationen schon im Vorfeld zu ermitteln, kann es aber üblicherweise nicht zu den Pflichten des Lieferanten gehören, diese Informationen selbst zu ermitteln. Ungefragt einen Vorschlag zur Umorganisation des Unternehmens des Kunden zu unterbreiten, gehört ebenfalls nicht zu den Aufgaben eines Softwareunternehmens. Selbst bei hervorragender Sachkunde bezüglich der Branche des Kunden bedarf es dazu umfangreicher Ermittlungen im Betrieb des Kunden, die ohne entsprechenden Auftrag nicht zu erbringen sein werden. Auch hier mag ein Hinweis notwendig sein, dass die von dem Kunden erkennbar beabsichtigten Vorteile, die sich aus dem Einsatz der Software ergeben, die der Hersteller herstellen soll, sich nur dann realisieren lassen, wenn eine entsprechende Umorganisation des Betriebes erfolgt. Mehr als ein solcher Hinweis muss aber ungefragt nicht erfolgen2. Gelegentlich wird der Kunde auch darauf hinzuweisen sein, dass er zur Erfüllung seiner Projektaufgaben sachkundiges Personal oder sachkundige Berater einstellen muss (vgl. Rz. 472). Hinweise auf fehlende Unterlagen, ungenaue Leistungsbeschreibung u.Ä. 11 sind dann zu erteilen, wenn der Softwareersteller feststellt, dass die ihm erteilten Auskünfte nicht ausreichend sind, um die Software zu erstellen oder auch nur ein entsprechendes Angebot zu unterbreiten. Dies kann schon in einem sehr frühen Stadium von Vertragsverhandlungen der Fall sein. Der Softwareersteller muss darauf hinwirken, dass fehlende Unterlagen erstellt und ihm unterbreitet, ggf. auch von ihm (gegen Entgelt) erstellt werden. Darüber hinausgehende Pflichten stellen in diesem Stadium eine Überforderung dar. Ein wichtiger Gesichtspunkt spielt aber – möglicherweise – in den angesprochenen Entscheidungen eine Rolle. Sobald der Hersteller eine Beratung durchführt oder auch nur ohne nähere Nachfrage erklärt, dass seine Software die gestellten Erwartungen erfüllt, haftet er dafür3. Wer erklärt, dass die von ihm herzustellende Software die Erwartung des Kunden erfüllen wird, ist dem Kunden gegenüber verpflichtet, vorher zu prüfen, ob diese Versprechungen einen realistischen Kern haben. Demgemäß muss sich der Hersteller, bevor er solche Versprechungen abgibt, Gewissheit über die Anforderungen verschafft haben, die die von 1 OLG Hamm v. 23.11.1988 – 31 U 63/88, CR 1989, 498 (LS). 2 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 157. 3 Schneider, Handbuch des EDV-Rechts, D Rz. 239.

Redeker

323

12

D Rz. 13

Verträge

ihm herzustellende Software erfüllen muss. Dazu muss er auch die entsprechenden Ermittlungen über Datenumsätze, möglicherweise Zahl der Dateizugriffe für die Erfüllung einzelner Aufgaben u.Ä. mehr anstellen. Tut er dies nicht und gibt später nicht haltbare Versprechungen ins Blaue hinein ab, haftet er dafür. 13 Geht der Hersteller gar so weit, dass er sich mit der Organisation des Betriebes beschäftigt und macht konkrete Vorschläge, wie die Software zu gestalten und wie die Betriebseinheiten einzurichten sind, dürfte er auch eine Beratungspflicht zur Ermittlung notwendiger Organisationsumstellungen haben. Grund für die eben genannten Pflichten ist die Inanspruchnahme von Vertrauen durch tatsächliche Erstellung von Beratung und sei es auch nur durch relativ lauthalsige Versprechungen. Wer sich zu bestimmen Eigenschaften äußert und die entsprechende Sachkunde hat, muss vorher sorgfältig prüfen, ob er Versprechungen abgeben kann oder nicht. Fehlt ihm die Sachkunde für bestimmte Aspekte seiner Aufgaben, muss er auch darauf hinweisen1. 14 Die Haftung für fehlerhafte Auskünfte gilt im Hinblick auf die Leistungsfähigkeit der herzustellenden Software insgesamt, insbesondere aber auch im Hinblick auf die Leistungsfähigkeit der anzupassenden Standardsoftwarebestandteile der zu erstellenden Software bzw. der entsprechenden Bibliotheksprogramme und zwar nicht nur im Hinblick auf die Funktionalität, sondern auch im Hinblick auf den Umfang der anfallenden Daten, Transaktionen usw. 15 Praktisch muss man bei der Herstellung von Individualsoftware auch unterscheiden, ob der Herstellungsprozess im Wesentlichen – wie heute üblich – in einer Anpassung vorhandener Standardsoftware auf Bedürfnisse des Kunden besteht, die mehr oder minder umfangreich sein kann, bei der aber die Standardsoftware im Kern unverändert bleibt, oder ob die Individualsoftware komplett neu hergestellt wird. Die Pflichten zur Überprüfung der Leistungsfähigkeit der eingesetzten Werkzeuge entfällt natürlich, wenn keine Standardwerkzeuge eingesetzt werden, sondern eine komplette Individualentwicklung erfolgt. Um so mehr muss in diesem Fall darauf hingewiesen werden, dass sehr umfangreiche Ermittlungen erforderlich sind, um ein hinreichend konkretes Lasten- bzw. Pflichtenheft zu erstellen. b) Beratung zur Systemumgebung 16 Oft muss geprüft werden, ob die Systemumgebung, in der die beauftragte Software eingesetzt werden soll, tatsächlich ausreicht, um die von der Software zu erwartenden Leistungen überhaupt möglich zu machen. Dabei sind die Hardwarebestandteile einschließlich der Kommunikationskomponenten und der Netzwerksoftware ebenso zu prüfen wie die eingesetzte systemnahe Software. Auch hier kann es schon frühzeitig zu Beratungs- und Hin1 Marly, Praxishandbuch Softwarerecht, Rz. 1121.

324

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 18

D

weispflichten kommen. Allerdings gilt auch hier: Ungefragt muss der Softwareersteller nur darauf hinweisen, dass diese Umgebung ganz entscheidend für die Leistungsfähigkeit der zu liefernden Software ist und er ggf. prüfen muss, ob die Software und die Systemumgebung für die vom Kunden gewünschte Funktionalität und Leistungsfähigkeit der herzustellenden Software ausreichend ist oder sie erweitert werden muss1. Ungefragt muss er darüber nicht hinausgehen, insbesondere die Systemumgebung von sich aus nicht prüfen. Geht er allerdings von sich aus darüber hinaus und weist darauf hin, dass die Systemumgebung ausreichend ist oder in gewisser Weise aufgerüstet werden muss, müssen dies Hinweise auch stimmen. Dies setzt in aller Regel eine umfangreiche Ermittlungstätigkeit voraus, insbesondere dann, wenn die Individualsoftware ganz oder in großem Umfang neu entwickelt werden soll. Der Softwareersteller muss insbesondere auch prüfen, was der Kunde denn 17 wirklich will. Geht es um die Optimierung von vorhandenen Datenverarbeitungsprozessen oder um ihre Portierung auf eine neue Systemumgebung, müssen auch diese schon vorhandenen Prozesse und die ihnen zugrunde liegende Software genau geprüft werden. Es stellt sich nämlich immer wieder heraus, dass der Ressourcenverbrauch der vorhandenen Datenverarbeitungsprozesse vom außenstehenden Lieferanten unterschätzt wird. Auch hier besteht zumindest eine Hinweis- und Prüfpflicht, dass man diese Prozesse genau untersuchen muss, bevor man zur Leistungsfähigkeit der zu liefernden Software etwas sagen kann. c) Weitere Beratungspflichten Über die bislang dargestellten Pflichten hinausgehende Beratungspflichten 18 können durchaus vorkommen, sind aber seltener. Es kann in Einzelfällen sein, dass die im Zusammenhang mit der geplanten Softwareentwicklung eingesetzten Standardsoftwareprodukte vom Kunden zu umfangreich und damit zu teuer ausgewählt wurden. Auf diese Tatsache muss das Softwareunternehmen jedenfalls dann hinweisen, wenn es selbst für den Kunden geeignete Produkte liefern kann, die zwar weniger leistungsfähiger, damit aber auch preiswerter sind2. Dies gilt freilich dann nicht, wenn der Kunde schon mit festen Vorstellungen über den Umfang seiner Bestellung zum Softwareunternehmen kommt3. Nach der Rechtsprechung soll eine Spezialfirma den Hinweis geben müssen, der Erfolg des geschuldeten Datenaustauschs könne von Änderungen abhängen, die die Hersteller der Softwareprodukte durchführen müssten, zwischen denen die Daten ausgetauscht werden sollen4.

1 2 3 4

Vgl. auch Hörl, ITRB 2004, 39 (40). OLG Köln v. 22.10.1993 – 19 U 62/93, CR 1994, 212 = NJW 1994, 1355. OLG Köln v. 8.1.1993 – 19 U 187/92, CR 1993, 563. OLG Hamm v. 8.8.2007 – 12 U 26/07, CR 2008, 77.

Redeker

325

D Rz. 19

Verträge

19 Muss die Software rechtliche Vorgaben erfüllen, um überhaupt eingesetzt werden zu können, muss der Softwareersteller auch darauf hinweisen. Dies gilt z.B. bei Abrechnungssoftware für Ärzte oder bei Buchhaltungssoftware1. Man wird diese Problematik aber eher dem Bereich der Leistungsbeschreibung und der Mängelhaftung als dem Bereich der Beratungspflichten zuordnen können. Es kann auch sein, dass das Softwareunternehmen darauf hinweisen muss, dass die Software für ihren Einsatz der Nutzung von Bibliotheksprogrammen bedarf, an denen Rechte erworben müssen. 20 Darüber hinausgehende rechtliche Beratungspflichten hat das Softwareunternehmen aber nicht. Es muss z.B. nicht darüber beraten, ob die Einführung etwa eines Personalinformationssystems der Mitwirkung des Betriebsoder Personalrats bedarf. Ein Softwareunternehmen muss keine Kenntnisse des Betriebsverfassungsrechts oder des Personalvertretungsrechts haben. Darüber hinaus dürfte eine solche Beratungspflicht auch gegen das Rechtsdienstleistungsgesetz verstoßen. 2. Gescheiterte Vertragsverhandlungen 21 Vorvertraglich ist weiter der Bereich der gescheiterten Vertragsverhandlungen von Bedeutung. Immer wieder kommen in der Praxis Fälle vor, in denen Vertragsverhandlungen scheitern, nachdem beide Seiten schon umfangreiche Aufwendungen in die Vertragsvorbereitungen gesteckt haben. Wenn dann eine der Seiten die Vertragsverhandlungen abbricht, besteht ein massives ökonomisches Interesse des anderen Partners am Ersatz seiner Aufwendungen. 22 Man kann über diese Fragen schon im Vorfeld explizit oder implizit2 vertragliche Regelungen treffen, nach denen sich die Rechtsfolgen dann richten. Dies geschieht in aller Regel aber nicht. Auch in den gelegentlich ausgetauschten „Letters of Intent“ (vgl. Rz. 34 ff.), finden sich in aller Regel keine Regelungen zu den Rechtsfolgen eines Abbruchs der Vertragsverhandlungen. 23 Gibt es solche vertraglichen Regelungen nicht, ist zunächst als Grundsatz festzuhalten, dass es bis zum Abschluss des Vertrages prinzipiell allen beteiligten Parteien freisteht, auf den Vertragsschluss zu verzichten. Für den Abbruch der Vertragsverhandlungen muss kein Grund angegeben werden, schon gar nicht ist ein wichtiger Grund erforderlich. Den Abbruch der Vertragsverhandlungen muss der Vertragspartner hinnehmen. Seine Aufwendungen muss er selbst tragen3.

1 LG Münster v. 13.2.1991 – 1 S 383/90, CR 1991, 665. 2 So z.B. in der Entscheidung LG Stuttgart v. 22.3.2002 – 8 O 420/99, CR 2002, 644. 3 Erman/Kindl, § 311 BGB Rz. 34.

326

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 28

D

Nur in Ausnahmefällen ergibt sich auch nach der Rechtsprechung und Leh- 24 re eine andere Bewertung. Es kann dann einen Schadensersatzanspruch aus § 311 BGB (ehemals culpa in contrahendo) i.V.m. § 280 Abs. 1 BGB geben. Es handelt sich hier aber um ausgesprochene Ausnahmefälle. Voraussetzung ist, dass derjenige, der die Vertragsverhandlungen abbricht, durch sein Verhalten bei seinem Verhandlungspartner Vertrauen darauf begründet hat, dass ein Vertrag abgeschlossen werde und dass der Abbruch ohne zureichenden Grund erfolgt1. Bei der Annahme dieser Voraussetzungen wird man sehr vorsichtig sein 25 müssen, weil die Parteien noch keinen Vertrag geschlossen haben. Der Grundsatz der Vertragsfreiheit darf nicht auf dem Wege über Schadensersatzansprüche ausgehebelt werden. In Einzelfällen mag eine solche Situation aber einmal vorkommen, insbesondere dann, wenn der eine Vertragspartner den anderen im Vorfeld des Vertragsschlusses zu erheblichen Investitionen ermuntert hat und dabei immer wieder zum Ausdruck gebracht hat, dass der kommende Vertragsschluss eine reine Förmelei sei. Verzögert sich dann freilich der Vertragsschluss längere Zeit, wird das Vertrauen wieder entfallen, wenn der Aufwendende wegen dieser Verzögerungen ernsthaft mit der Möglichkeit rechnen muss, dass der Vertragsschluss nicht erfolgt. Zum Schutz der Vertragsfreiheit wird man darüber hinaus an das Vorliegen 26 eines Grundes für den Abbruch der Vertragsverhandlungen keine zu hohen Anforderungen stellen dürfen. Ein (technisch oder finanziell) besseres Angebot eines anderen Lieferanten oder auch die Verschlechterung der durch den Vertrag erzielten Vorteile des Abbrechenden reichen aus. Speziell im Softwarebereich dürfte es auch ausreichen, wenn der Softwarebesteller seine Organisationspläne begründet ändert und die noch nicht bestellte Software daher entbehrlich wird. Für einen Schadensersatzanspruch ist nach dem Gesetzeswortlaut Vertretenmüssen Voraussetzung (§§ 280 Abs. 1 Satz 2, 276 BGB). Praktisch dürfte Vertretenmüssen Verschulden bedeuten. In Einzelfällen kann es nach § 276 BGB aber auch ein Vertretenmüssen ohne Verschulden geben2.

27

Ein besonderer Fall vorvertraglicher Schadensersatzansprüche kann sich auch aus dem Vergaberecht ergeben, wenn ein Vergabeverfahren entgegen § 17 VOL/A unberechtigt abgebrochen wird. Auf diese Spezialproblematik kann an dieser Stelle nur hingewiesen werden3.

28

1 BGH v. 20.9.1984 – III ZR 47/83, BGHZ 92, 164 (175 f.) = MDR 1985, 298; BGH v. 18.7.2001 – XII ZR 183/98, NJW-RR 2001, 1524; Erman/Kindl, § 311 BGB Rz. 34. 2 Näher Erman/H.P. Westermann, § 276 BGB Rz. 2, 17 ff. 3 Dazu noch zu der Vorgängervorschrift § 26 VOL/A a.F. BGH v. 8.9.1998 – X ZR 48/97, BauR 1998, 1232; BGH v. 8.9.1998 – X ZR 99/96, BauR 1998, 1238; Leinemann, Die Vergabe öffentlicher Aufträge, Rz. 776.

Redeker

327

D Rz. 29

Verträge

29 Kann man im Ausnahmefall einen Schadensersatzanspruch dem Grunde nach bejahen, stellt sich immer noch die Frage, welche Schäden der Höhe nach überhaupt ersetzt werden können. Man wird verschiedene Schadensarten unterscheiden müssen. 30 Zunächst muss man die Aufwendungen, die zu einem Zeitpunkt entstanden sind, bevor überhaupt ein berechtigtes Vertrauen auf den Vertragsschluss vorlag, von den Aufwendungen unterscheiden, die danach erfolgt sind. Aufwendungen die schon entstanden sind, bevor ein Partner berechtigt auf den Vertragsschluss vertrauen konnte, sind nicht erstattungsfähig. Dies gilt z.B. für Kosten, die für die Durchführung von Präsentationen zu einem Zeitpunkt angefallen sind, zu dem das jeweilige Unternehmen überhaupt noch nicht als möglicher Vertragspartner ausgewählt war, sondern noch unterschiedliche Unternehmen zur Wahl als Vertragspartner in Frage kamen. 31 Ferner sind nach der Rechtsprechung – und dies auch bei entsprechenden vertraglichen Vereinbarungen – nur die Aufwendungen zu ersetzen, die nach Lage des Falles für die Vertragsvorbereitung erforderlich waren und mit denen der mögliche Vertragspartner auch rechnen musste. Diese Beschränkung war in einer gerichtlichen Entscheidung von großer Bedeutung1. 32 Das Gericht hat ausgeführt, dass z.B. Kosten ersatzfähig sind, die zur Ermittlung eines Mengengerüsts dienten. Die dabei ermittelten Informationen seien für ein realistisches Angebot erforderlich gewesen. 33 Nicht ersetzbar seien aber Kosten, die für den Kauf eines Programms durch das Softwareunternehmen aufgewandt worden sind, das dem Kunden erst noch verkauft werden sollte. Mit einem solchen Einkauf muss gewartet werden, bis der Vertragsschluss erfolgt ist. Umgekehrt sind beim Besteller Kosten notwendig, die für die Überprüfung der Angebote des ausgewählten potentiellen Vertragspartners anfallen. Nicht ersatzfähig sind solche Kosten, die schon für den Erwerb der Infrastruktur angefallen sind, bevor der Auftrag für die Erstellung des Softwareprodukts überhaupt erfolgt ist. Auch hier muss gewartet werden, bis der Vertragsschluss denn erfolgt ist. 3. Absichtserklärung (insbesondere „Letter of Intent“) 34 Im Vorfeld vertraglicher Vereinbarungen gibt es häufig beiderseitige Absichtserklärungen im Hinblick darauf, dass ein späterer Vertragsschluss beabsichtigt ist. Oft werden solche Vereinbarungen mit „Letter of Intent“ überschrieben. Welche Rechtspflichten sich aus solchen Vereinbarungen ergeben, richtet sich im Wesentlichen nach ihrem Inhalt. In der Praxis anzutreffende Inhalte sind äußerst vielfältig. Von relativ vagen, rechtlich im Ergebnis unverbindlichen Good-Will-Erklärungen, in denen beide Seiten zum 1 LG Stuttgart v. 22.3.2002 – 8 O 420/99, CR 2002, 644 (646).

328

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 37

D

Ausdruck bringen, man wolle konstruktive Vertragsverhandlungen führen, bis hin zu sehr detaillierten Erklärungen, in denen schon alle wesentlichen Vertragsinhalte festgelegt sind und die inhaltlich zumindest einen Vorvertrag1 bilden, kann man nahezu alles finden. Die Erklärungen haben auch verschiedene praktische Funktionen. Oft verständigen sich hier zunächst die Geschäftsleitungen über wesentliche Züge der Verträge, ohne dass die Einzelverhandlungen schon so weit gekommen sind, dass man einen wirklichen Vertrag schließen kann, weil z.B. die Leistungsbeschreibung und darauf aufbauend auch das Preisangebot noch nicht im Einzelnen abgestimmt werden konnte. Manchmal werden so freilich auch Mitzeichnungsbefugnisse von Abteilungen vermieden, die möglicherweise dem Vertragsschluss nicht zustimmen würden. Rechtliche Pflichten ergeben sich in dem Umfang, wie sie dem Vertragstext 35 und den sonstigen Umständen des Vertragsschlusses im Wege der Auslegung mit den allgemein üblichen Auslegungsmethoden zu entnehmen sind. Es können sehr umfangreiche Pflichten vereinbart werden. Es kann aber auch sein, dass so gut wie überhaupt keine Pflichten entstehen. Ist die Erklärung mit „Letter of Intent“ überschrieben, geht die Literatur – so sich aus dem Erklärungsinhalt nichts anderes ergibt – im Zweifel nicht von einem Rechtsbindungswillen aus2. Möglicherweise kann bei Vorliegen eines „Letter of Intent“ ein unmotivierter Verhandlungsabbruch, insbesondere, wenn ernsthafte Verhandlungen überhaupt nicht beabsichtigt waren, aber zu Schadensersatzansprüchen führen3. Will man solche Vereinbarungen schließen, muss man überlegen, welchen 36 Zweck man mit den Vereinbarungen verfolgt. Will man eine nicht unerhebliche Bindung erreichen, müssen entsprechend detaillierte Pflichten vereinbart werden. Solche Pflichten können zum einen darin bestehen, dass man bis zu einem bestimmten Zeitpunkt einen Vertrag mit den im Wesentlichen bestimmten Inhalten abschließt. Man sollte dann aber zum einen überlegen, warum man den Vertrag jetzt noch nicht abschließen kann, und zum anderen Bedingungen formulieren, die zum Vertragsschluss verpflichten, und solche, die einen Vertragsschluss vielleicht noch verhindern können. Klare Regelungen sind nötig – unklare Regelungen können zur Unwirksamkeit des Vertrages führen4. Im Übrigen ist in den Fällen auch zu überlegen, wer im Hinblick auf den 37 Vertragsschluss möglicherweise umfangreiche Aufwendungen trifft und wie diese Aufwendungen u.U. ersetzt oder auch nicht ersetzt werden sollen. 1 Dazu Staudinger/Bork, Vor §§ 145 BGB Rz. 51 ff. 2 Staudinger/Bork, § 145 BGB Rz. 14; Palandt/Ellenberger, Einf. vor § 145 BGB Rz. 18. 3 Staudinger/Bork, § 145 BGB Rz. 14. 4 Staudinger/Bork, Vor § 145 BGB Rz. 57 f.; Palandt/Ellenberger, Einf. vor § 145 BGB Rz. 20.

Redeker

329

D Rz. 38

Verträge

38 Solche Vorvereinbarungen können auch den Zweck haben, sich für eine gewisse Zeitdauer Exklusivität in den Vertragsverhandlungen über ein Projekt zu sichern. Dann müsste dies klar und deutlich zum Ausdruck kommen. 39 Es empfiehlt sich nahezu immer, über die schon erwähnten Vereinbarungen hinaus eine Geheimhaltungsvereinbarung zu treffen1, weil insbesondere bei der Erstellung von Individualsoftware im Laufe der Vertragsverhandlungen Betriebsgeheimnisse ausgetaucht werden müssen, ohne deren wechselseitige Kenntnis das Projekt überhaupt nicht vernünftig geplant werden kann. 40 Insgesamt können solche vorvertraglichen Vereinbarungen eine wichtige Bedeutung auch für umfangreiche Vertragsverhandlungen haben. Man muss sie allerdings sehr gezielt einsetzen. Noch weniger als sonst haben in diesem Zusammenhang Überschriften eine Bedeutung, weil bislang sich gerade in diesem Bereich überhaupt kein Vertragstyp entwickelt hat und auch gesetzliche Regelungen als Standards fehlen. Weder kann man durch Überschriften vermeiden, dass in Wirklichkeit schon ein endgültiger Vertrag geschlossen ist, wenn denn nur die entsprechenden Pflichten und Gegenleistungen hinreichend detailliert beschrieben sind und sich aus den Vertragsunterlagen der Wille zum endgültigen Vertragsschluss ergibt, noch kann man dann, wenn sich im Vertragstext praktisch nur ein Absichtserklärung im Hinblick auf mögliche Vertragsverhandlungen ergibt, aus einer Überschrift allein schon auf eine zwingende Verpflichtung zum Vertragsschluss schließen. 41 Ergibt sich aus den Vereinbarungen ein Anspruch auf Vertragsschluss, kann auch auf Abschluss des Vertrages geklagt werden. Die klagende Partei bestimmt dabei im Rahmen der vorvertraglichen Verpflichtungen den Vertragsinhalt2.

II. Vertragliche Pflichten 1. Übersicht über mögliche Leistungen a) Erstellung von Software 42 Unter einem Softwareerstellungsvertrag können sich recht unterschiedliche Leistungen verbergen, sowohl was den Leistungsumfang, als auch was den einzelnen Inhalt der Leistung betrifft. Erster wesentlicher Teil ist die Erstellung von Software. 43 Traditionell ist das Leitbild dieses Vertrages die vollständige Neuerstellung eines neuen Softwarepakets. Dies hat in der Frühzeit der Softwarenutzung sicherlich die Hauptrolle gespielt. Auch heute kommt dies in Einzelfällen noch vor, insbesondere dann, wenn einzelne Leistungspakete für eine neu 1 Muster bei Redeker, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 6.4; vgl. dazu auch Intveen, ITRB 2007, 359. 2 BGH v. 12.5.2006 – V ZR 97/05, NJW 2006, 2843.

330

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 45

D

zu erstellende Standardsoftware eines Herstellers hergestellt werden soll und dieser großen Wert darauf legt, dass kein Code von Drittseite einbezogen wird. Diese Situation dürfte heute dennoch eher der seltenere Fall sein. Vielmehr wird heute in aller Regel auch die Neuerstellung unter Einbeziehung von von vorhandenen, insbesondere von Bibliotheksprogrammen erfolgen1. Allerdings gibt es hier auch zwei wesentliche Unterschiede. Zum einen kann es so sein, dass Bibliotheksprogramme jeweils nur dynamisch bei der Durchführung des Programms mit in das Programm einbezogen werden und im Programmcode selbst nur ein entsprechender Aufrufbefehl enthalten ist. In diesem Fall gehören die Bibliotheksprogramme selbst nicht zur Software. Sie werden auch nicht vom Hersteller mitgeliefert. Das Vorhandensein der entsprechenden Programmbibliothek beim Kunden gehört dann zu der vom Kunden zu stellenden Systemumgebung. Dies ist im Hinblick auf die Rechteübertragung von nicht unerheblicher Bedeutung. Andererseits können einzelne Bibliotheksprogramme auch statisch in dem Programmcode direkt eingebunden werden. Es kann auch sonstiger Standardcode, den der Hersteller nutzt, in den Programmcode eingebunden werden. Im Bereich der projektorientierten Programmierung gehört dies auch zu einer ordnungsgemäßen Programmerstellung. Hier ergeben sich insbesondere Probleme mit der Rechteübertragung, die 44 noch besonders erhöht werden, wenn die Bibliotheksprogramme einbezogen werden, die urheberrechtlich den Regeln der Open-Source-Software, insbesondere der GPL oder der LGPL unterliegen. Auf die sich daraus ergebenden rechtlichen Probleme kann an dieser Stelle nur verwiesen werden2. Der Leistungsumfang kann sich neben diesen technischen Unterscheidun- 45 gen auch noch dahingehend unterscheiden, in welchem Umfang die Rechte an der neu erstellten Software auf den Kunden übertragen werden. Grundmodell der normalen Vertragsüberlegung ist die vollständige Übertragung sämtlicher Rechte an der neu erstellten Software auf den Kunden. Ist der Kunde ein Softwarehaus, das die Software im Rahmen seiner eigenen Entwicklung – sei es als Standardprogramm, sei es als Individualprogramm – einsetzen will, ist dies auch notwendig. In anderen Fällen kann es auch sein, dass der Kunde nur einfache Nutzungsrechte erwirbt, deren Umfang dann im Detail bestimmt werden muss. In diesem Fall sollte geklärt werden, ob das Softwareunternehmen die erstellte Software ganz oder teilweise, verändert oder unverändert, an Dritte vertreiben darf. Dabei ist zu beachten, dass eine Weitergabe der Software unter Aufgabe der eigenen Nutzung jedenfalls zulässig und wahrscheinlich nicht zu verhindern ist3.

1 Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 1; Witte, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 1.4, Rz. 8. 2 Zu Open Source: Redeker, IT-Recht, Rz. 90 ff. 3 EuGH, Urt. v. 3.7.2012 – C-128/11, GRUR 2012, 904 (m. Anm. Hansen/WolffRojczyk) = CR 2012, 498.

Redeker

331

D Rz. 46

Verträge

b) Lieferung und Anpassung von Software 46 Ein weiterer Bereich der Softwareerstellung liegt darin, dass ein wesentlicher Teil des Leistungsprogramms in der Lieferung einer vorhandenen Standardsoftware durch den Lieferanten besteht. Diese Standardsoftware löst wesentliche Probleme des Kunden. Zur vollständigen Lösung der Programme benötigt dieser aber eine umfangreiche Anpassung dieser Software durch Umprogrammierung oder Zusatzprogrammierung. Technisch wird man versuchen, einen größeren Teil durch Zusatzprogrammierung zu lösen, weil dies die Erstellung, insbesondere aber die Pflege vereinfacht. In manchen Fällen wird dies aber nicht ausreichen1. c) Lieferung und Parametrisierung von Standardsoftware 47 Eine dritte Gruppe von Leistungen ist die Lieferung von Standardsoftware, die außerdem parametrisiert wird. In diesem Fall werden vorher ausgewählte Stellen im Programm auf den Kunden eingestellt, bei denen für den Einzelfall mehr oder minder große Wahlmöglichkeiten im Hinblick auf die Einstellung der Software bestehen. Es wird nichts am Code geändert. Es werden nur im Programm vorhandene Wahlmöglichen durch Eingabe individueller Parameter ausgenutzt. Es kann sich um dabei um die Eingabe einiger weniger Variablen handeln. Es kann sogar so sein, dass lediglich Briefköpfe eingestellt werden. Es kann allerdings auch um sehr umfangreiche Arbeiten gehen, die von der Größenordnung her sechsstellige Eurosummen wert sind. d) Anpassung von Standardsoftware 48 Es gibt auch in der Praxis durchaus Modelle, wo der Kunde Standardsoftware besorgt hat und Aufgabe des jetzigen Lieferanten nur deren Anpassung i.S.d. Kunden ist. Vertragsgegenstand ist dann nur die Anpassung von dritter Seite bezogener, beim Kunden schon vorhandener Standardsoftware. 49 Im Bereich eines großen Herstellers spricht man hier von Customizing. Was dies gegenüber der Anpassung von Standardsoftware besonders ist, lässt sich im Einzelnen auch der EDV-technischen Literatur nicht entnehmen. Customizing umfasst nach einigen Literaturstimmen auch die Änderung des vorhandenen Quellcodes. Dazu kann auch Zusatzprogrammierung gehören. Die Begrenzung besteht wohl darin, dass die Anpassung nicht so weit gehen kann, dass die Strukturen des Programms berührt sind. Eine irgendwie geartete Definition des Begriffs, die diese von der generellen Anpassung von Software, die sowohl die Zusatzprogrammierung als auch die Codeänderung umfasst, abgrenzt, ist in der Literatur nicht zu finden. Customizing und Anpassung werden weitgehend gleichgesetzt2. Angesichts des 1 Zu den Leistungen b–f vgl. auch die ausgiebige Darstellung unten bei Kap. G. 2 Sarre, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 1 Rz. 56 ff.

332

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 53

D

Fehlens klarer Abgrenzungskriterien wird man sich dieser Auffassung anschließen müssen. e) Parametrisierung von Standardsoftware Auch die Leistung der Parametrisierung kann als Einzelauftrag vergeben 50 werden. In diesem Fall hat der Kunde die Standardsoftware von Dritten bezogen und beauftragt das jeweilige Softwareunternehmen nur noch mit ihrer Parametrisierung. f) Installation, Einweisung und Schulung In einem weiteren Bereich beschränkt sich die Leistung des Softwarehauses auf die Installation des Programms, die Einweisung des Kunden und möglicherweise die Schulung seiner Mitarbeiter in der Bedienung des Programms. Auch dies kann getrennt von der Softwarelieferung erfolgen. Auch diese Leistungen sollen einer kurzen Betrachtung unterzogen werden.

51

g) Übernahme von Altdaten (Migration) Ein in der Praxis sehr häufiges Problem ist noch die Übernahme der Altdaten aus einem früher vorhandenen Programmsystem, auch als Migration von Daten bezeichnet1. Diese Leistung kann sowohl im Zusammenhang mit der Lieferung des neuen Programms als auch getrennt davon angeboten werden. In aller Regel macht es Sinn, diese Leistung zumindest in Zusammenhang mit der Anpassungsleistung zu bestellen und für beide Leistungsteile einen einheitlichen Vertrag zu schließen.

52

h) Verantwortungsbereiche Eine letzte wichtige Frage bei umfangreicheren Softwareprojekten besteht 53 darin, zu klären, wer letztendlich für die Durchführung des Projekts verantwortlich ist. Es kann so sein, dass der Kunde, insbesondere ein Kunde, der nicht über eine EDV-Abteilung verfügt oder dessen EDV-Abteilung für das konkrete Projekt keine Sachkenntnis hat, zwar Leistungen bereitstellt, aber dem Softwareunternehmen die Verantwortung dafür zuweist, dass das Softwareprojekt insgesamt erfolgreich ist, also die Software erstellt, möglicherweise auch installiert und lauffähig gemacht wird. Es kann aber auch sein, dass die EDV-Abteilung des Bestellers sich – möglicherweise unter Koordinierung mehrerer Lieferanten – die Verantwortung selbst vorbehält und das Projekt letztendlich verbindlich durchführt. Dies ist insbesondere bei sachkundigeren EDV-Abteilungen durchaus nicht ungewöhnlich.

1 Schneider, Handbuch des EDV-Rechts, D Rz. 128 ff.; Conrad/Schneider, in: AuerReinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 9.

Redeker

333

D Rz. 54

Verträge

54 Letztlich kann es auch dazu kommen, dass beide Parteien eine gemeinsame Projektgruppe gründen, in der Entscheidungen auch gleichberechtigt getroffen werden und sie das Projekt sozusagen gemeinsam durchführen. Wer die Projektverantwortung in welcher Weise trägt, sollte vertraglich eindeutig geklärt sein. Eine ungeklärte Verantwortung ist eine zusätzliche Fehlerquelle. 2. Rechtliche Einordnung a) Problemstellung 55 Unter der Geltung des alten Schuldrechts war es im Wesentlichen unstreitig, dass die hier betrachteten Verträge Werkverträge sind. Es gab Diskussionen über die Frage, wann es sich nicht um Werk-, sondern um Dienstverträge handelte. Diese Problematik besteht weiterhin. Nach der Schuldrechtsreform kommt aber ein neues Problem hinzu, nämlich die Frage, in welchem Umfang auf die hier betrachteten Verträge Kaufrecht Anwendung findet. b) Werk- oder Dienstvertrag aa) Grundsätze 56 Zunächst soll auf die Abgrenzung zwischen Werk- und Dienstvertrag eingegangen werden. Das Grundprinzip der Abgrenzung zwischen Werk- und Dienstvertrag ist dem Gesetz zu entnehmen. Werkverträge sind erfolgsbezogen. Ein Werkunternehmer schuldet daher die Herstellung eines bestimmten Werkes, das aus einem körperlichen Gegenstand, aber auch aus jeder anderen Art von Endprodukt bestehen kann. Wesentlich ist nicht, in welcher Weise das Werk hergestellt wird, wichtig ist nur, dass es (mit den geschuldeten Eigenschaften) hergestellt wird1. Ein Dienstverpflichteter schuldet demgegenüber ausschließlich die Erbringung von Diensten. Diese können erfolgreich sein, müssen dies aber nicht. Für den Erfolg der Dienstleistung ist der Dienstverpflichtete nicht haftbar. Er ist allerdings verpflichtet, seine Dienste ordnungsgemäß in geschuldetem Umfang mit den dafür notwendigen Kenntnissen und Fähigkeiten zu erbringen2. 57 Man wird daher bei der Abgrenzung zwischen Werk- und Dienstverträgen zunächst überprüfen, was der jeweilige Auftragnehmer eigentlich schuldet. Schuldet er die Erbringung eines konkreten Werkstücks, handelt es sich um einen Werkvertrag. Soll er lediglich Arbeiten erbringen, handelt es sich um einen Dienstvertrag. Die entscheidenden Kriterien für eine solche Abgrenzung ergeben sich sehr oft aus der Leistungsbeschreibung. Ist z.B. vom Auftragnehmer ein konkretes Programm, z.B. ein Buchhaltungsprogramm, zu 1 OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732. 2 Staudinger/Peters/Jacoby, Vor §§ 631 ff. BGB Rz. 26; Junker/Benecke, Computerrecht, Rz. 167.

334

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 59

D

erstellen, so handelt es sich eindeutig um einen Werkvertrag. Geht die Leistungsbeschreibung dahin, dass der Auftragnehmer im Rahmen eines Gesamtprojekts zusammen mit anderen Programmierern Leistungen erbringen soll, die Einzelheiten dieser Leistung aber von einem Projektleiter bestimmt werden, der nicht der Auftragnehmer ist, sondern vom Auftraggeber oder irgendeinem Dritten beigestellt wird, handelt es sich ebenso eindeutig um einen Dienstvertrag1. Dabei wird das Ergebnis in den hier geschilderten Fällen nicht davon beeinflusst, in welcher Art und Weise die Vergütung geschuldet ist. Eine Aufwandsvergütung ist zwar für den Dienstvertrag typisch. Es gibt aber auch Dienstverträge, die pauschal vergütet werden wie z.B. ein Prozessauftrag für Rechtsanwälte, die nach dem RVG vergütetet werden. Umgekehrt gibt es sehr viele Werkverträge, die nicht pauschal vergütet werden, sondern nach Aufwand. Dies gilt z.B. für ganz viele Bauverträge, die nach lfd. Meter oder nach Quadratmeterflächen vergütet werden. Das in der Praxis häufig herangezogene Kriterium der Vergütungsart, nach dem bei Pauschalvergütung ein Werkvertrag, bei Aufwandsvergütung ein Dienstvertrag vorliege, ist daher ein in aller Regel wenig aussagekräftiges Indiz. Hat man den Vertrag anhand der Leistungsbeschreibung oder anderer Kriterien rechtlich als Dienst- oder Werkvertrag eingeordnet, kann die Art der Vergütung dieses Ergebnis nicht ernsthaft beeinflussen2. Fehlt es allerdings an einer klaren Einordnung, kann eine Aufwandsvergütung ein Indiz für das Vorliegen eines Dienstvertrages sein. Es kommt aber immer auf die Gesamtwürdigung aller Umstände des Vertrages an3. Dabei spielen Nebenleistungen wie die Übernahme von Schulungen für die Einordnung keine Rolle4. Kein Kriterium ist die bloße Überschrift eines Vertrages oder die sonstige 58 Wortwahl der Parteien5. Man kann einen Werkvertrag nicht durch Überschrift zum Dienstvertrag und umgekehrt einen Dienstvertrag nicht durch Überschrift zu einem Werkvertrag machen. Nur in wenigen Ausnahmefällen, in der die Leistungsbeschreibung wenig ergiebig ist, kann eine Überschrift ein Auslegungsindiz sein. Festzuhalten ist, dass zentrale Abgrenzungskriterien zwischen Werk- und Dienstvertrag der Erfolgsbezug des Leistungsversprechens des Auftragnehmers ist. Allerdings gibt es in der Praxis zahlreiche unklare Situationen. Insbesondere gibt es zahlreiche Gemeinschaftsprojekte, in denen einzelne Projektteile, 1 Schneider, Handbuch des EDV-Rechts, D Rz. 118, 154; Staudinger/Peters/Jacoby, Vor §§ 631 ff. BGB Rz. 29; Funk/Wenn, ITRB 2004, 118 (119); OLG München v. 23.4.1996 – 5 U 5708/95, CR 1997, 27. 2 BGH v. 25.3.1993 – X ZR 17/92, CR 1993, 759; OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732; teilweise a.A. Junker/Benecke, Computerrecht, Rz. 167. 3 Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 15. 4 OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95. 5 Staudinger/Peters/Jacoby, Vor §§ 631 ff. BGB Rz. 30 a.E.; OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732.

Redeker

335

59

D Rz. 60

Verträge

die Auftragnehmer oder Auftraggeber zugeordnet werden könnten, nur schwer erkennbar sind. Eine solche Situation spricht freilich dafür, dass ein Dienstvertrag vorliegt, weil man keine Erfolgshaftung des Auftragnehmers erkennen kann. bb) Einfluss der Verantwortungsbereiche 60 Gerade in den zuletzt betrachteten Fällen wird die vertragstypologische Einordnung der Leistungsbeziehung zwischen Parteien auch von der Frage beeinflusst, wer im Projekt die Verantwortung für das Ergebnis trägt. Wie oben schon dargestellt worden, kann dies zum einen das Softwareunternehmen, zum anderen aber auch der Kunde sein. Es kann auch eine gemeinsame Verantwortung geben. 61 Hat das Softwareunternehmen die Verantwortung für das Ergebnis, ist dies ein sehr starkes Indiz dafür, dass es sich um einen Werkvertrag handelt. In diesem Falle liegt ja die Verantwortung dafür, dass das beabsichtigte Produkt auch fehlerfrei erstellt wird, beim Softwareunternehmen. Es hat insoweit die Projektleitung. Der Kunde wirkt zwar in der Bearbeitung der Aufgabe mit. Das Softwareunternehmen hat aber ein eigenes klar abgegrenztes Verantwortungsprofil. Es muss das beabsichtigte Produkt fehlerfrei herstellen. In diesem Falle dürfte in aller Regel ein Werkvertrag vorliegen. 62 Liegt die Verantwortung beim Kunden, spricht dies hingegen dafür, dass kein Werkvertrag vorliegt. Hat der Kunde die Projektleitung und hat er die Verantwortung dafür, dass das Projekt letztendlich erfolgreich ist, kann das Softwareunternehmen keine Erfolgsverantwortung übernehmen. Schließlich wird das Projekt ja vom Kunden gesteuert. Das Softwareunternehmen stellt nur einzelne Leistungen zur Verfügung, für die es nur insoweit die Verantwortung übernimmt, als dass sie fachgerecht erbracht werden. Mangels Projektleitung kann das Softwareunternehmen keine Verantwortung für den Gesamterfolg haben. Der Vertrag wird in aller Regel dienstvertraglichen Regelungen folgen. Das Gleiche gilt, wenn das Softwareunternehmen ohne Pflichtenheft im Wesentlichen auf Grund von Einzelweisungen des Kunden programmiert1. 63 Zu beachten ist nur, dass auch dann, wenn in einem großen Projekt der Kunde die Gesamtverantwortung trägt, es sehr wohl sein kann, dass das Softwareunternehmen einzelne Teilaspekte selbstverantwortlich erstellt und dafür ihm ein konkreter Auftrag erteilt wird, zumindest ein Teilprogramm zu erstellen. In diesem Falle liegt ein Werkvertrag über das Teilprogramm vor2. Es kommt in diesem Zusammenhang nur auf die Frage an, wer die konkrete Verantwortung für die Erstellung des Teilprodukts, nicht jedoch, wer die Verantwortung für das Gesamtprodukt hat. Notwendige Vo-

1 Schneider, CR 2003, 317 (321). 2 Schneider, Handbuch des EDV-Rechts, E Rz. 232.

336

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 66

D

raussetzung dieser Aufgliederung ist allerdings ein klar abgrenzbares Teilprodukt, das genau definiert ist. In der Praxis immer wieder tauchen Verträge auf, in denen Unternehmen 64 durch sog. Rahmenverträge die Verpflichtung auferlegt wird, in bestimmten zeitlichen Umfang an einem Gesamtsoftwareprojekt des Auftraggebers mitzuwirken. Im Rahmen dieses Auftrags werden dann einzelne Teilaufträge erteilt, die mehr oder minder genau definiert sind. Diese Vertragsbeziehung dürfte in aller Regel insgesamt Dienstvertragsrecht unterliegen, insbesondere dann, wenn die Aufträge jeweils im Rahmen einer dauernden Tätigkeit vor Ort den Mitarbeitern des Unternehmens erteilt werden. Nur in ganz wenigen Fällen werden die Leistungsbeziehungen im Einzelnen so detailliert konkretisiert werden können, dass einzelne Teilaufträge auch Werkverträge darstellen. In der Realität werden die Mitarbeiter solcher Unternehmen im Rahmen des Gesamtprojekts gemeinsam mit den Mitarbeitern des Auftraggebers eingesetzt, so dass beim besten Willen nicht von einem Werkvertrag ausgegangen werden kann. Der letzte oben genannte Fall ist der der gemeinsamen Verantwortung bei- 65 der Vertragsparteien. Hier ist die Indizwirkung der Verantwortungszuordnung geringer. Allerdings ist es auch hier so, dass dem Softwarehaus kein eigenverantworteter Bereich zugewiesen wird. Die gemeinsame Verantwortung bedeutet, dass der Kunde immer Einfluss auf das Ergebnis nehmen kann und soll. Auch hier wird man in aller Regel eher von einem Dienstals von einem Werkvertrag ausgehen können1. Es kommt aber auch Gesellschaftsrecht in Frage2. Dabei ist aber zu beachten, dass die bloße Einrichtung gemeinsamer Projektgremien alleine nicht zu einer gemeinsamen Verantwortung für das Projekt führt. Solche Gremien sind oft zur Kontrolle des Projekts ebenso nötig wie zur Verzahnung evtl. interner Arbeiten des Auftraggebers („Organisationsprojekt“3) mit der Softwareentwicklung, lenken aber nicht das Projekt zur Softwarerealisierung. Von einer gemeinsamen Verantwortung ist nur auszugehen, wenn nicht nur die Projektüberwachung, sondern auch einzelne Teile der Projektdurchführung beiden Seiten obliegen und es keine eindeutige Zuordnung der Gesamtverantwortung oder der Verantwortung für einzelne Teilprodukte gibt. Alle hier dargestellten Abgrenzungskriterien gelten im Übrigen ohne Einschränkungen auch bei der Entwicklung hoch komplexer Software. Für diesen Bereich gibt es keine Sonderregeln, wenn die Parteien diese nicht vereinbaren4. 1 Dazu Redeker, ITRB 2001, 109; vgl. auch BGH BB 2002, 2039 = NJW 2003, 3323; BGH v. 25.6.2002 – X ZR 83/00, MDR 2002, 1183 = NJW 2002, 3317 und Karger, CR 2001, 357 (359). 2 Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 34. 3 Zahrnt, Richtiges Vorgehen bei Verträgen über IT-Leistungen, S. 2. 4 Näher Karger, ITRB 2004, 208; Redeker, IT-Recht, Rz. 482 ff.; teilweise a.A. Brandi-Dohrn, CR 1998, 645.

Redeker

337

66

D Rz. 67

Verträge

c) § 651 BGB 67 Das durch die Schuldrechtsreform neu entstandene Problem ergibt sich aus § 651 BGB. Nach dieser Vorschrift gilt für Werkverträge über die Herstellung beweglicher Sachen in weiten Bereichen Kaufrecht. Nur hinsichtlich der Mitwirkungsobliegenheiten verbleibt es für die Herstellung nicht vertretbarer Sachen auch bei diesen Verträgen bei den Regeln des Werkvertrages (§ 651 Satz 3 BGB). Dogmatisch handelt es sich bei dieser Vorschrift um eine Rechtsfolgenverweisung. Der Vertrag über die Herstellung beweglicher Sachen ist kein Kaufvertrag, sondern ein Werkvertrag, der im Wesentlichen kaufrechtlichen Vorschriften unterliegt. Mit dieser Regelung, die auf Vorgaben der EU-Verbrauchsgüterrichtlinie1 beruht, hat der Gesetzgeber insoweit Neuland geschaffen, als dass er im Gegensatz zum früheren Recht der Werklieferungsverträge einen umfassenden Verweis auf das Kaufrecht geschaffen und auch die Herstellung unvertretbarer beweglicher Sachen in die Regelung mit einbezogen hat. Im früheren Recht der Werklieferungsverträge galten wichtige kaufrechtliche Regelungen zwar für die Herstellung vertretbarer Sachen, nicht jedoch für die Herstellung unvertretbarer Sachen. 68 Zwischen den Regelungen des Kauf- und des Werkvertragsrechts herrscht zwar nach der Schuldrechtsreform größere Übereinstimmung als vor der Schuldrechtsreform. In einigen wesentlichen Punkten bestehen aber weiterhin deutliche Unterschiede. Zum einen ist bei der Annahme von Kaufrecht weder für die Fälligkeit der Vergütung noch für den Beginn der Verjährungsfrist für Sachmängel eine Abnahme erforderlich. Zum anderen ist die Regelung der Gewährleistung unterschiedlich. Wie im Einzelnen noch darzustellen sein wird, ergibt sich bei der Anwendung von Kaufrecht eine Verjährung von zwei Jahren ab Ablieferung der Software. Gilt kein Kaufrecht, gilt die gesetzliche Verjährungsfrist. Diese beträgt drei Jahre ab Entstehen des Anspruchs und Kenntnis der anspruchsbegründenden Tatsachen, also bei Gewährleistungsansprüchen ab Kenntnis des Mangels, höchstens jedoch zehn Jahre. Außerdem hat der Besteller im Werkvertragsrecht bei mangelhaften Werken ggf. das Recht, das Werk auf Kosten des Unternehmers selbst nachzubessern (§ 637 BGB). Eine entsprechende Vorschrift fehlt im Kaufrecht. Ein weiterer gewichtiger Unterschied besteht darin, dass im Werkvertragsrecht Gewährleistungsansprüche ausgeschlossen sind, wenn der Kunde die Mängel bei der Abnahme kannte, sich aber keine Rechte vorbehalten hat (§ 640 Abs. 2 BGB). Demgegenüber stellt die entsprechende Vorschrift im Kaufrecht darauf ab, ob der Kunde die Mängel bei Vertragsschluss kennt (§ 442 Abs. 1 Satz 1 BGB). Bei einem noch herzustellenden Gegenstand greift dieser Ausschluss aber nicht ein, weil der Kunde die Mängel bei Vertragsschluss gar nicht kennen kann. Erkennt er sie bei Ablieferung und nimmt die Sache dennoch vorbehaltlos als Erfüllung an, fehlt es an einer entsprechenden Ausschlussvorschrift2. Ferner sieht das Werkvertragsrecht 1 Richtlinie 99/44/EG v. 25.5.1999, ABl. EG Nr. L 171. 2 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 82 f.

338

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 71

D

Abschlagszahlungen in bestimmten Fällen auch ohne Vereinbarung vor (§ 641 Abs. 1 Satz 2 BGB). Eine entsprechende Regelung fehlt im Kaufrecht. Die ersten beiden unterschiedlichen Rechtsfolgen haben mit Sicherheit mit 69 dazu beigetragen, dass eine sehr umfangreiche Diskussion über die Einordnung der Verträge über die Erstellung von Software in das System des § 651 BGB entbrannt ist. Das Selbstvornahmerecht spielt bei Software keine Rolle, weil es praktisch kaum realisierbar ist. Die Frage des Ausschlusses von Gewährleistungsrechten bei Mangelkenntnis erscheint sehr wichtig, hat aber bislang in der Diskussion kaum eine Rolle gespielt. Die Frage der Abschlagszahlungen ist wieder weniger gewichtig, weil man Abschlagszahlungen umfassender als gesetzlich vorgesehen auch in AGB vereinbaren kann (vgl. dazu Rz. 185 ff.). In der Diskussion fällt auf, dass die nicht softwarerechtliche Literatur nahe- 70 zu einhellig1 – unterstützt auch von vielen Stimmen in der softwarerechtlichen Literatur2 – von der Annahme ausgeht, Softwareverträge seien reine Werkverträge, auf die kein Kaufrecht anzuwenden ist, während in der softwarerechtlichen Literatur sehr wesentliche Stimmen für die Einordnung der Softwareerstellungsverträge als Werklieferungsverträge i.S.d. § 651 BGB sprechen3. Der Streitstand wird oben (Kap. B) von Schneider im Detail dargestellt. d) Sacheigenschaft von Software Ausgangspunkt der Auseinandersetzung ist die Frage, ob Software eine Sa- 71 che ist. Nach der Vorschrift des § 651 BGB ist Kaufrecht nämlich dann anwendbar, wenn es um die Herstellung einer körperlichen Sache handelt. Im früheren Recht ist diese Frage umfangreich im Zusammenhang mit der Anwendung von Sachmängelrecht auf Verträge über die Lieferung von Standardsoftware diskutiert worden. Die Reform des Schuldrechts hat dieser Auseinandersetzung im Hinblick auf diese Frage die Basis entzogen, weil sich mittlerweile unmittelbar aus § 453 Abs. 1 BGB ergibt, dass auch auf 1 Palandt/Sprau, Einf. vor § 631 BGB Rz. 22; Staudinger/Peters/Jacoby, § 651 BGB Rz. 16; Derleder/Zänker, NJW 2003, 2777 (2781); Metzger, AcP 204 (2004), 231 (247). 2 Bartsch, CR 2001, 649 (653); Diedrich, CR 2002, 473 (475); Spindler/Klöhn, CR 2003, 81 (83); Stichtenoth, K&R 2003, 105; Heussen, CR 2004, 1 (7); Junker/Benecke, Computerrecht, Rz. 156; Hoeren, in: Dauner-Lieb/Konzen/Schmidt (Hrsg.), Das neue Schuldrecht in der Praxis, S. 515, 519; Witte, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 1.4, Rz. 14; Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 31, Rz. 56; Müller-Hengstenberg, CR 2004, 161 (164 f.); Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 96 f. 3 Schweinoch/Roas, CR 2004, 326; Zahrnt, Vertragsrecht für IT-Fachleute, S. 237; Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 25; auch noch Thewalt, CR 2002, 1 (4), aber aufgegeben in: Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 96 f.

Redeker

339

D Rz. 72

Verträge

Kaufverträge über andere Gegenstände als körperliche Sachen die Regeln über Sach- und Rechtsmängel Anwendung finden. Umso wichtiger ist die Frage jetzt für die Anwendung des § 651 BGB. Außerdem sind auch die Regeln über den Verbrauchsgüterkauf gem. § 474 Abs. 1 Satz 1 BGB nur auf Kaufverträge über bewegliche Sachen anwendbar. 72 In der Rechtsprechung hat sich der BGH ohne irgendeine Begründung in einem vertragsrechtlichen Urteil auf die Seite derjenigen gestellt, die Software als Sache behandeln1, während in einem urheberrechtlichen Urteil die Einräumung eines Eigentumsvorbehalts an Software als Sicherungsabtretung entsprechender urheberrechtlicher Nutzungsrechte behandelt wurde, Software also gerade nicht als Sache behandelt wurde2. In neuerer Zeit ist der BGH in einer Entscheidung zu ASP von der Sacheigenschaft von Software ausgegangen3. In seiner letzten Entscheidung zu diesen Fragen hat er dieses Thema nicht berührt, geht aber für den Regelfall bei Softwareerstellung von einem Werkvertrag aus4. Der Verfasser geht – wie an anderer Stelle näher dargelegt5 – davon aus, dass weder das Gesamtwerk „Software“ noch einzelne Vervielfältigungen Sachen sind. Das Thema wird an anderer Stelle von Schneider näher dargelegt (vgl. Kap. B Rz. 32 ff.). Auf diese Ausführungen soll an dieser Stelle verwiesen werden. Für die folgenden Ausführungen wird davon ausgegangen, dass Software keine Sache ist. e) Einordnung der Softwareerstellungsverträge aa) Erstellung von Software 73 Bei der vertragsrechtlichen Einordnung von Verträgen über die Erstellung von individueller Software soll zunächst von dem Fall ausgegangen werden, dass ein vollständiges Softwarepaket neu erstellt werden soll. Ist dies geschuldet, kann kein Zweifel bestehen, dass es sich um einen Werkvertrag handelt. Dies gilt auch dann, wenn die Bibliotheksprogramme miteinbezogen werden, insbesondere bei der oben dargestellten dynamischen Einbindung von Bibliotheksprogrammen. Irgendwelche Standardprodukte werden nicht mitgeliefert. Die dynamische Einordnung von Bibliotheksprogrammen führt ja nur dazu, dass diese bei der Abarbeitung der Programme aufgerufen und dann in die Durchführung einbezogen werden. Die Programme selber sind nicht Liefergegenstand. Vertragsrechtlich dürfte auch bei der statischen Einbindung solcher Programme nichts anderes gelten. Jedenfalls ist ein Erfolg geschuldet. Es liegt daher ein Werkvertrag und kein Dienstvertrag vor. 1 BGH v. 14.7.1993 – VIII ZR 147/92, MDR 1993, 950 = NJW 1993, 2436 (2437) = CR 1993, 681. 2 BGH v. 20.1.1994 – I ZR 267/91, CR 1994, 275 = MDR 1994, 462 = GRUR 1994, 363 = Beilage Nr. 7 zu BB 1994, S. 2 = DuD 1994, 518. 3 BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 75. 4 BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327. 5 IT-Recht, Rz. 278 ff.; vgl. früher schon NJW 1992, 1739.

340

Redeker

Realisierung (Kauf-/Werkvertrag)

D

Rz. 77

§ 651 BGB bleibt dann unanwendbar, weil es sich nicht um die Herstellung 74 von körperlichen Sachen handelt. Dieses Ergebnis muss allerdings noch einer differenzierten Analyse unterzogen werden, weil neben der dogmatischen Frage, ob Software eine Sache ist oder nicht, noch zu erörtern ist, ob nicht der Rechtsgedanke, der hinter § 651 BGB steht, dazu zwingt, die Vorschrift in bestimmten Fallkonstellationen analog auf einen Auftrag zur Erstellung von Individualsoftware anzuwenden. Ein zentraler Gedanke des § 651 BGB ist es, dass die Vorschriften des Kauf- 75 vertrages zur Verjährung von Mängelansprüchen geeignet sind, bei der Lieferung von Gegenständen, die – wie die meisten beweglichen Gegenstände – relativ raschem Verschleiß unterliegen, frühzeitig Rechtsfrieden herzustellen. Aufgrund dieser Tatsache ist in der Verbrauchsgüterrichtlinie die Herstellung körperlicher Gegenstände dem Kaufrecht unterworfen worden. Deswegen spricht die Verbrauchsgüterrichtlinie auch von körperlichen Sachen und nicht von geistigen Produkten. Insbesondere bei der Herstellung geistiger Produkte besteht demgegenüber 76 oft ein ganz anderes Bedürfnis, weil die tatsächlichen Konsequenzen von Mängeln oft erst spät eintreten, weil sie sich in Schäden in anderen, auf Grund der geistigen Leistung hergestellten Produkten manifestieren. Im Übrigen ist die Abgrenzung zum Dienstvertragsrecht bei der Herstellung geistiger Produkte wesentlich schwieriger als im Bereich der Herstellung körperlicher Sachen. Wegen beider Gesichtspunkte hat der Gesetzgeber die Anwendung von Kaufrecht auf Werkverträge bei der Herstellung körperlicher Gegenstände angeordnet, wobei er dabei auch die Verbrauchsgüterrichtlinie umsetzen wollte. Er hätte dies für Verträge zwischen Unternehmern nicht tun müssen, hat sich allerdings – wie bei der gesamten Schuldrechtsreform – dahingehend entschieden, dass im Wesentlichen die Grundregeln des BGB für Verträge sowohl zwischen Unternehmern und Verbrauchern als auch zwischen Unternehmern und Unternehmern gelten sollen, so dass die eigentlich nur für den Verbrauchervertrag notwendigen europarechtlichen Auswirkungen auch im Zwischenunternehmensverkehr zu berücksichtigen sind. Geht man nun von den unterschiedlichen Fallgestaltungen aus, die oben 77 erörtert worden sind, so ist der Auftrag zur Entwicklung von Software und der Übertragung umfangreicher Nutzungsrechte an den Auftraggeber, der die Software erwirbt, um sie zu verändern, zu vertreiben und sonst auf alle erdenkliche Art und Weise zu nutzen, nicht vergleichbar mit einem Kaufvertrag über eine körperliche Sache. Es muss vielmehr ein Produkt erzeugt werden, dass in erster Linie geistigen Charakter hat und bei dem körperliche Implementierungen nur Hilfsmittel für die Erfüllung sind. Die Übertragung eines körperlichen Exemplars ist nur notwendig, damit die Rechte überhaupt vom Erwerber ausgenutzt werden können1. Hier dient keine der oben genannten Überlegungen dazu, entgegen dem Gesetzeswortlaut § 651 1 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 62 f.

Redeker

341

D Rz. 78

Verträge

BGB analog anzuwenden. Ob der Kunde die gelieferte Software nur für sich verwenden oder als Standardsoftware vertreiben will, ist irrelevant. Es bleibt daher bei dieser Vertragsgestaltung und bei der alleinigen Anwendung von Werkvertragsrecht. 78 Die gegenteilige Fallgestaltung ist die, dass die Individualsoftware in Auftrag gegeben wird, der Unternehmer aber alle Rechte behält und der Erwerber lediglich ein einfaches Nutzungsrecht erwirbt. Für den Erwerber ist eine solche Fallgestaltung dann von Interesse, wenn er auf diese Weise ein Softwareprodukt zu einem weit geringeren Preis erhält. Für den Unternehmer besteht der Vorteil darin, dass er die hier bestellte Software auch für andere Kunden verwenden kann, möglicherweise daraus auch ein Standardsoftwareprodukt herstellen kann, das er umfassend vertreiben kann. In diesem Fall erhält der Kunde letztendlich nichts anderes, als er auch bei dem Erwerb von Standardsoftware erwirbt. Er erhält ein einziges Exemplar der Software, das er in vorher definiertem, sehr eingeschränktem Umfang selbst nutzen kann. In aller Regel wird er die Software weder verändern noch verbreiten dürfen und auch sonst mit der Software außer der eigenen Nutzung nichts anstellen können, was er nicht auch mit einem per Kaufvertrag erstandenen Standardsoftwareprodukt anstellen dürfte. Seine Interessenlage entspricht der eines Standardsoftwarekäufers. In diesem Falle spricht viel für eine analoge Anwendung des § 651 BGB, um die wirtschaftlich gleiche Interessenlage rechtlich abzubilden und in diesem Falle auch relativ raschen Rechtsfrieden zu erreichen. Insbesondere bei der Länge der Verjährungsfrist ist zu bemerken, dass für denjenigen, der umfassende Rechte an einem Produkt erwirbt, das er in eigene Produkte mit einbeziehen, verarbeiten und weiterverbreiten will, es von einer ganz zentralen Bedeutung ist, dass eventuelle Ansprüche wegen Mängeln, seien es Nacherfüllungsansprüche, seien es Schadensersatzansprüche, noch über einen langen Zeitraum zur Verfügung stehen, weil das Produkt erfahrungsgemäß ja über einen längeren Zeitraum eingesetzt und an Dritte veräußert wird. Dies gilt auch für Software, auch wenn ein einmal von einem Endkunden erworbenes Softwareprodukt von diesem oft nur wenige Jahre eingesetzt wird. Demgegenüber steht bei der einfachen Nutzung auch die Gewährung von Rechtsfrieden deutlich im Vordergrund. Der Gesetzgeber hat diese gerade im Hinblick auf die Rechtsfolgen des § 651 BGB wichtige Differenz nicht gesehen, so dass man von einer planwidrigen Regelungslücke sprechen muss, die durch die analoge Anwendung des § 651 BGB geschlossen werden muss. 79 Ein dritter Fall besteht darin, dass zwar nur einfache Nutzungsrechte an den Erwerber übertragen werden, dieser aber dem Veräußerer die Weiterverarbeitung verbietet, bzw. diese von einer Genehmigung – möglicherweise auch von der Beteiligung an den Erlösen – abhängig macht. Dies kann verschiedene Hintergründe haben. In aller Regel spricht für diese Lösung auf Erwerberseite der Konkurrenzschutz. Der Vorsprung, den die neu entwickelte Software bietet, soll dem Konkurrenten verwehrt werden. Möglicherweise ist auch die Vorstellung, dass man zwar zunächst Zeit gewinnen, 342

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 82

D

aber im Einzelfall auch an den Erlösen mitverdienen möchte, eine Motivation. Diese Situation in diesem Fall weicht deutlich von der eines üblichen Vertrages bei dem Erwerb von Standardsoftware ab. Es ergibt sich für diesen Fall keine zwingende Argumentation für eine planwidrige Regelungslücke und damit für eine analoge Anwendung des § 651 BGB. Auch für diesen Fall verbleibt es daher beim reinen Werkvertragsrecht. Nach alledem ergibt sich, dass Software dann, wenn sie nur unter Über- 80 tragung eines einfachen Nutzungsrechts geliefert wird, dem Kaufrecht unterliegt und ansonsten Kaufrecht keine Anwendung findet1. bb) Lieferung und Anpassung von Standardsoftware Der zweite, oben näher dargestellte mögliche Leistungsinhalt der hier be- 81 trachteten Verträge besteht darin, dass das Softwarehaus eine Standardsoftware – sei es eine eigene, sei es eine fremde – liefert und diese an die Bedürfnisse des Kunden anpasst. Zu diesen Anpassungsarbeiten können sowohl die Erstellung von Zusatzprogrammen als auch Veränderungen im Quellcode des Standardprogramms gehören. Das Softwarehaus liefert jedenfalls beide Produkte. Der Erwerb des Standardsoftwareprodukts ohne Anpassungsarbeiten unter- 82 liegt nach ständiger Rechtsprechung dem Kaufrecht2. Die Anpassungsarbeiten als solche würden Werkvertragsrecht unterliegen und zwar sowohl was die Neuerstellung von Codes (vgl. Rz. 73 ff.) als auch was Anpassungsarbeiten an der Standardsoftware betrifft (vgl. Rz. 95 ff.). Es handelt sich also bei den hier geschuldeten Leistungen um verschiedene Leistungsinhalte eines einheitlichen Vertrages, die jeweils einzeln betrachtet verschiedenen vertragsrechtlichen Einordnungen unterliegen. Dies gilt jedenfalls dann, wenn es über Lieferung und Anpassung der Software ein einheitliches Vertragsdokument gibt. Die rechtliche Einordnung solcher typengemischter Verträge ist streitig. Üblicherweise folgt die Einordnung des Gesamtvertrages der vertragsrechtlichen Einordnung des Vertragsteils, der dem Gesamtvertrag sein Gepräge gibt. Dabei spielen Wertanteile der einzelnen Leistungen zwar eine Rolle, sind aber nicht zentral. So wird in aller Regel der Anteil der Anpassungsleistungen vom Wert her deutlich unterhalb der Standardsoftware liegen. Dennoch wird in Rechtsprechung und Literatur häufig davon ausgegangen, dass jedenfalls nach altem Recht der gesamte Vertrag als Werkvertrag zu behandeln ist, wenn die Anpassungsleistungen über die bloße Parametrisierung hinausgehen3. Durch die Anpassungsleistungen wird die 1 Marly, Praxishandbuch Softwarerecht, Rz. 60 ff., vertritt eine i.E. ähnliche Differenzierung. 2 Grundlegend BGH v. 4.11.1987 – VIII ZR 314/86, BGHZ 102, 135 = CR 1988, 124 = CR 1988, 994 m. Anm. Ruppelt; BGH v. 18.10.1989 – VIII ZR 325/88, BGHZ 109, 97 = CR 1990, 24 = CR 1990, 112 m. Anm. Heymann. 3 BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681 = MDR 1993, 950 = NJW 1993, 2436 (2437); OLG Düsseldorf v. 13.4.1988 – 19 U 62/87, CR 1989, 696; OLG München v. 24.1.1990 – 27 U 901/88, CR 1991, 19 (20 f.); OLG Koblenz v.

Redeker

343

D Rz. 83

Verträge

Standardsoftware zu einem individuellen Werkstück1. Dies wird z.B. bei einem Wertanteil der Anpassungsleistungen von einem Viertel des Gesamtwertes angenommen2. Handelt es sich allerdings nur um kleine Anpassungsleistungen, steht der Standardsoftwarekauf so im Vordergrund, dass der Gesamtvertrag als Kaufvertrag mit Anpassungsleistungen behandelt wird3. 83 Die Wertungen sind allerdings in Einzelfällen äußerst unterschiedlich, wobei die Rechtsprechung oft ohne nähere Gewichtung die bloße Tatsache von Anpassungsleistungen zur Annahme eines Werkvertrags ausreichen lässt. In der Literatur wird ganz im Gegensatz dazu die Meinung vertreten, ein Vertrag über den Erwerb von Standardsoftware mit individuellen Anpassungen sei immer ein Kaufvertrag mit Nebenpflichten4. Thewalt geht erst ab einem Anteil von 50 % der Anpassungsleistungen von einem Werkvertrag aus5. Für die im Rahmen dieses Beitrags zu behandelnden Verträge wird man allerdings von einem einheitlichen Werkvertrag ausgehen dürfen. Der bloße Erwerb von Standardsoftware mit kleineren Anpassungsleistungen ist nicht Gegenstand der Untersuchung. Lediglich, wenn man Thewalt folgte, wäre dies zweifelhaft. Die von Thewalt benutzte Wertgrenze ist aber eindeutig zu hoch. Schon bei einem weit geringeren Wertanteil der Anpassungsleistungen erhält der Kunde ein auf ihn angepasstes individuelles Werkstück. Die an dieser Stelle diskutierten Verträge sind daher Werkverträge. 84 Geht man bei der Lieferung von Standardsoftware mit Anpassungsleistungen von einem Werkvertrag aus, stellt sich nach neuem Recht die Frage, ob hier nun § 651 BGB eingreift und der gesamte Vertrag dem Kaufrecht unterstellt wird, wobei zusätzlich insbesondere Mitwirkungsobliegenheiten des Kunden vorgesehen sind, oder ob es sich um einen reinen Werkvertrag handelt. In der Literatur wird für Fälle dieser Art außerhalb des Softwarebereichs etwa bei umfangreichen Montageverpflichtungen bei komplexen Werkmaschinen die Anwendung des § 651 BGB (analog) abgelehnt6.

1 2 3

4 5 6

4.10.1991 – 2 U 403/88, CR 1992, 154 = NJW-RR 1992, 688; OLG Köln v. 11.11.1991 – 19 U 87/91, CR 1992, 153; OLG Frankfurt v. 12.3.1993 – 10 U 76/92, CR 1994, 97 = NJW-RR 1994, 122; OLG Karlsruhe v. 30.9.1994 – 15 U 89/94, CR 1995, 397; OLG Celle v. 5.10.1994 – 13 U 17/94, CR 1995, 152; LG Trier v. 2.12.1992 – 5 O 1/92, CR 1995, 221. Marly, Praxishandbuch Softwarerecht, Rz. 48. LG Augsburg v. 5.5.1988 – HKO 3588/87, CR 1989, 22; OLG Nürnberg v. 30.1.1990 – 11 U 893/88, Beil. 7 zu BB 1991, S. 10. Schneider, Handbuch des EDV-Rechts, H Rz. 345; Marly, Praxishandbuch Softwarerecht, Rz. 49; LG Landshut v. 20.8.2003 – 2 HK O 2392/02, CR 2004, 19 (20). Junker/Benecke, Computerrecht, Rz. 176. Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 105 f. Bamberger/Roth, § 651 BGB Rz. 12; a.A. Staudinger/Peters/Jacoby, § 651 BGB Rz. 15.

344

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 88

D

Geht man von den bisherigen Überlegungen aus, ist das Ergebnis aber klar: 85 § 651 BGB ist anwendbar. Der Gesamtvertrag wird unabhängig von der sonstigen vertraglichen Einordnung vom Leistungsgefüge her von der Standardsoftware geprägt. Es wird in aller Regel auch an den Anpassungsleistungen nur ein einfaches Nutzungsrecht übertragen, da der Kunde mit weitgehenden Rechten wenig anfangen kann. Daher gilt für diesen Vertrag einheitlich § 651 BGB. Auch hier mag es einzelne Fälle geben, in denen anders entschieden werden 86 kann, insbesondere dann, wenn die Anpassungsleistungen in der Herstellung eines völlig unabhängig von der Standardsoftware benutzbaren Softwareproduktes besteht, an dem der Kunde dann auch noch alle Rechte erwirbt. Der Regelfall dürfte dies nicht sein. Verträge über die Lieferung und Anpassung von Standardsoftware dürften Werklieferungsverträge i.S.v. § 651 BGB sein1. In einer Reihe von Fällen werden die Lieferung der Standardsoftware und 87 die Anpassungsleistungen zwischen den gleichen Vertragsparteien zur gleichen Zeit in zwei verschiedenen Vertragsdokumenten geregelt. Diese Aufspaltung einer von beiden Parteien so gesehenen einheitlichen Leistung in zwei Vertragsformulare dürfte rechtlich ohne Belang sein. Es soll einheitlich Standardsoftware geliefert und diese an die Bedürfnisse des Kunden angepasst werden. Für den Lieferanten ersichtlich kann der Kunde in aller Regel nur mit dem Gesamtprodukt, bestehend aus Standardsoftware und Anpassungsleistung, etwas anfangen. Die Teilprodukte nützen ihm nichts. Man wird daher in aller Regel auch dann, wenn zwei Vertragsurkunden vorliegen, von einem einheitlichen Vertrag ausgehen können2. Dies gilt allerdings nur dann, wenn die beiden Vertragsparteien in beiden Verträgen die gleichen sind und der Vertragsschluss gleichzeitig oder in ganz engem zeitlichen Abstand erfolgt. In allen anderen Fällen spricht eher vieles für zwei verschiedene Verträge. 88 Es kann freilich sein, dass auf Grund der zwei verschiedenen Vertragsurkunden die beiden Leistungen in der Abwicklung unterschiedlichen Rechtsregelungen unterfallen, obwohl es sich um einen einheitlichen Vertrag handelt; sei es, weil in beiden Verträgen einzelne Vertragsbedingungen anders geregelt sind, sei es, weil man aus der Gestaltung der Rechtsbeziehungen in Form zweier Vertragsurkunden schließen kann, dass der vorhandene einheitliche Vertrag als typengemischter Vertrag dahingehend behan1 Zu altem Recht: BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681 = MDR 1993, 950 = NJW 1993, 2436 (2437); BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93 (94 f.); OLG Düsseldorf v. 13.4.1988 – 19 U 62/87, CR 1989, 696; OLG Celle v. 5.10.1994 – 13 U 17/94, CR 1995, 152. 2 Vgl. in einem vergleichbaren Fall BGH v. 9.7.1993 – V ZR 144/91, NJW-RR 1993, 1421; aber auch die eher gegensätzlichen Entscheidungen BGH v. 6.12.1979 – VII ZR 313/78, BGHZ 76, 43 und BGH v. 6.11.1980 – VII ZR 12/80, BGHZ 78, 346, beide zur Verbindung von Grundstückskauf und Bauvertrag für ein aufstehendes Gebäude.

Redeker

345

D Rz. 89

Verträge

delt werden kann, dass jeder Vertragsteil in allen wesentlichen Aspekten den Rechtsregeln unterliegt, die bei einem isolierten Vertrag über nur diese Leistungen gelten würden. Die Lieferung der Standardsoftware unterfiel dann dem reinen Kaufvertragsrecht, die Anpassungsleistungen unterfielen dem reinen Werkvertragsrecht (vgl. Rz. 95 ff.). 89 Allerdings können sich Störungen in einem Vertragsteil sehr wohl auch auf den anderen Vertragsteil auswirken, weil es sich um einen einheitlichen Vertrag handelt. cc) Lieferung und Parametrisierung von Standardsoftware 90 Der nächste hier betrachtete Fall betrifft die Lieferung und Parametrisierung von Standardsoftware. 91 Nach den oben genannten Ausführungen dürfte die vertragsrechtliche Einordnung auch hier relativ einfach erfolgen können. Soweit die Standardsoftware geliefert und durch Parametrisierung eingestellt wird, indem einzelne Parameter geändert werden, handelt es sich um einen Kaufvertrag mit Nebenleistungen1. Ein Problem besteht allerdings dann, wenn der Wert der Parametrisierungsleistungen so umfangreich wird, dass die Parametrisierung fast nahezu das Gleiche kostet wie die Standardsoftware und auch der Arbeitsaufwand sowohl beim Lieferanten als auch beim Kunden im Hinblick auf die Ermittlungen der Voraussetzungen der Parametrisierung und die Umsetzung der ermittelten Ergebnisse in die Programmeinstellung so groß werden, dass die Parametrisierungsarbeiten für beide Seiten im Vordergrund stehen. In diesem Falle gebietet die Interessenlage auch ohne vertragliche Regelung, Mitwirkungsobliegenheiten des Kunden in großem Umfang anzunehmen, weil sonst die Parametrisierung gar nicht funktionieren kann. 92 Außerdem wird auf diesem Wege ein individuelles Produkt erzeugt. Man wird daher in diesem Fall zu erwägen haben, ob nicht Werkvertragsrecht gilt, allerdings unter analoger Anwendung des § 651 BGB. Gerade bei umfangreichen Parametrisierungsarbeiten wird man daher einen Werkvertrag annehmen können, auf den allerdings § 651 BGB analog anzuwenden ist. Wie in allen Fällen gemischter Vertragsleistungen dürfte die Einordnung in starkem Umfang von den Umständen des Einzelfalls abhängen. Die Wertgrenze, ab der ein einheitlicher Werkvertrag anzunehmen ist, dürfte bei Parametrisierungsarbeiten, die nicht zu einer Änderung oder Ergänzung des Programmcodes führen, höher liegen als bei Anpassungsleistungen, die das Werkstück verändern. In diesem Fall könnte die Wertgrenze von 50 %, die Thewalt2 vertritt, ein Anhaltspunkt sein. 93 Da aber hier wie bei der Lieferung und Anpassung von Standardsoftware letztendlich für den Kunden ein einzelnes Produkt erzeugt werden soll, soll1 LG Nürnberg v. 16.12.1991 – 9 O 5720/90, CR 1992, 336 (338). 2 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 105 f.

346

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 98

D

te man jedenfalls von einem einheitlichen Vertrag ausgehen, der einem einheitlichen Rechtsregiment unterworfen wird. Auch im Fall der Parametrisierung kann die Parametrisierungsleistung in 94 einem getrennten Vertragstext geregelt werden. Hier gelten die Ausführungen oben unter Rz. 87 ff. sinngemäß. dd) Anpassung von Standardsoftware Eine nächste hier näher darzulegende Leistung besteht darin, dass das Soft- 95 wareunternehmen Software, die der Kunde anderweitig bezogen hat, lediglich anpasst. Die Standardsoftware kann der Kunde von einem dritten Unternehmen oder weit früher von gleichen Unternehmen bezogen haben. Jedenfalls gehört die Lieferung der Standardsoftware im hier betrachteten Fall nicht mehr zum Leistungsumfang des Softwarevertrages. Auch diese Anpassungsleistungen sind erfolgsbezogen. Es geht daher in aller Regel um einen Werkvertrag. Nur in einzelnen Fällen kann hier ein Dienstvertrag angenommen werden, nämlich dann, wenn es an einer konkreten Ergebnisbeschreibung fehlt und letztendlich die Anpassungsleistung in ständigem Dialog mit dem Unternehmen unter der Verantwortung des Auftraggebers erstellt wird. Dieses kann gerade bei der Frage der isolierten Anpassungsleistung in der konkreten Vertragsgestaltung durchaus vorkommen. Die Abgrenzung zwischen Dienst- und Werkvertrag richtet sich nach den oben dargestellten allgemeinen Regeln (vgl. Rz. 56 ff.). Ist die Aufgabe erfolgsbezogen, so liegt jedenfalls ein Werkvertrag vor. Auf 96 diesen findet § 651 BGB unter keinen Umständen Anwendung. § 651 BGB beschäftigt sich nämlich nur mit der Neuherstellung von Produkten, nicht jedoch mit Anpassungsarbeiten und Reparaturen. Auch die Reparatur beweglicher Sachen ist Werkvertrag, der uneingeschränkt Werkvertragsregeln unterliegt1. Daher ist die Anwendung des § 651 BGB hier auch dann nicht geboten, wenn man Software für eine Sache hält. Die vertragsrechtliche Einordnung ist also klar. Allerdings spielt die Frage, ob Software eine Sache ist, sehr wohl noch eine Rolle bei der Frage der Verjährung von Mängelrechten. Darauf ist an anderer Stelle zurückzukommen (vgl. Rz. 342 ff.).

97

ee) Parametrisierung von Standardsoftware Für die Parametrisierung von Standardsoftware, die anderweitig erworben 98 ist, gelten die gleichen Überlegungen. Zunächst muss geklärt werden, ob die Leistung erfolgsbezogen oder tätigkeitsbezogen ist. In einem Fall handelt es sich um Werk- und im anderen Fall um einen Dienstvertrag. § 651 BGB findet keine Anwendung.

1 Vgl. dazu BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93 (94 f.); Junker, Computerrecht, Rz. 175; Schneider, Handbuch des EDV-Rechts, H Rz. 347.

Redeker

347

D Rz. 99

Verträge

ff) Installation, Einweisung und Schulung 99 Die Installation einer Software ist, wenn sie nicht die Dimension einer Parametrisierung erreicht, eine vertragliche Nebenleistung. Wird sie – ausnahmsweise – als getrennte Leistung vereinbart, handelt es sich um einen Werkvertrag, weil die erfolgreiche Installation als vertragliche Nebenleistung geschuldet ist. 100

Einweisung und Schulung sind oft ebenfalls Nebenleistungen. Werden sie getrennt beauftragt, handelt es sich – entgegen der Ansicht des OLG Frankfurt1 – um Dienstverträge. Man kann nicht davon ausgehen, dass der Schulende als Erfolg verspricht, dass die Mitarbeiter seines Kunden etwas sinnvolles lernen. Dieser Erfolg hängt zu sehr von der Vorbildung, Aufnahmefähigkeit und Lernbereitschaft dieser Mitarbeiter ab. Geschuldet ist nur ein inhaltlich und didaktisch korrektes Vorgehen der Schulenden. gg) Altdatenübernahme (Migration)

101

Eine weitere Ergänzungsleistung ist die Altdatenübernahme, oft auch als Migration von Daten bezeichnet. Inhaltlich geht es darum, Daten, die der Kunde bei Anwendung früherer Software in einem für diese Software geeigneten Format in seiner Datenverarbeitungsanlage gespeichert hat, so umzuformatieren, dass sie auch von dem neu eingesetzten Programm benutzt werden können. Je nach Art der verwendeten Programme kann die Aufgabe sehr umfangreich sein. Sie kann immer dadurch gelöst werden, dass alle Daten sozusagen per Hand in das neue System eingegeben werden. Möglicherweise zuverlässiger, jedenfalls aber schneller, kann eine Übernahme durch ein Übernahmeprogramm sein. Die Altdatenübernahme besteht dann darin, dieses Programm zu entwickeln und es auf die vorhandenen Daten anzuwenden. Ist ein Programm vorhanden, ist die Aufgabe relativ einfach. Ist kein solches Programm vorhanden, sondern muss es neu entwickelt werden, kann es sich um sehr umfangreiche Aufgaben handeln, insbesondere bei ungewöhnlichen Datenbanken und Dateiformaten entweder im Altoder Neuprogramm. In Einzelfällen können die Entwicklungsarbeiten für das Programm so umfangreich sein, dass die Übernahme per Hand schneller geht. Es kann natürlich auch sein, dass die Dateiformate im Detail nicht so bekannt sind, dass überhaupt ein Übernahmeprogramm geschrieben werden kann. Dann geht ohnehin nur die Datenübernahme per Hand.

102

Vertragsgegenstand der Altdatenübernahme ist allerdings in der Regel nicht Entwicklung des Programms, sondern die komplette Übernahme der alten Daten in das neue Programm. Ist die Leistung so formuliert, handelt es sich um eine erfolgsbezogene Arbeit. Damit liegt ein Werkvertrag vor2. Ist die Aufgabe so wie eben beschrieben formuliert, nämlich Umformatierung der 1 OLG Frankfurt v. 2.2.1994 – 23 U 25/92, in: Zahrnt, ECR OLG 152. 2 OLG Köln v. 21.6.1991 – 19 U 40/91, CR 1991, 671; Koch, Handbuch Softwareund Datenbank-Recht, § 1 Rz. 114; Schneider, Handbuch des EDV-Rechts, D Rz. 129.

348

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 107 D

Daten, kann § 651 BGB unter keinem Aspekt eine Anwendung finden. Irgendeine Herstellung irgendeines beweglichen Gegenstandes ist nicht geschuldet. Bis jetzt wird von niemandem vertreten, dass die Daten bewegliche Sachen sind. Selbst wenn man dies so sehen würde, würden ja bewegliche Sachen (nämlich gespeicherte Daten) nur bearbeitet und in neuer Form neu gespeichert. Es ging dann nicht um die Neuerstellung, so dass unter diesem Aspekt § 651 BGB keine Anwendung findet, weil es sich lediglich um eine Bearbeitung und nicht um eine Neuerstellung beweglicher Sachen handelt. Insgesamt ist daher auf diese Vertragsgestaltung Werkvertragsrecht ohne Anwendung des § 651 BGB anzuwenden. Wichtig ist, dass der Auftragnehmer nur Verantwortung dafür übernimmt, 103 dass die Altdaten sauber aus der Formatierung im Altsystem in die Formate des neuen IT-Systems migriert und in das neue System eingespeichert werden. Diese Verantwortung gilt auch bei ungewöhnlichen Formaten von Altdaten1. Eine inhaltliche Korrektur fehlerhafter oder lückenhafter Daten muss der Auftragnehmer dagegen nicht vornehmen, wenn er diese Tätigkeit nicht ausdrücklich übernommen hat. Solche inhaltlich falschen Altdaten werden damit ohne besondere Vereinbarung von ihm in inhaltlich falsche Neudaten migriert2. Besteht die Pflicht nur darin, ein für die Datenübernahme geeignetes Pro- 104 gramm zu schreiben, gilt für diese Arbeit das oben zur Erstellung von Software Ausgeführte (vgl. Rz. 73 ff.). Lediglich dann, wenn schlicht Hilfe bei der Datenübernahme o.Ä. zusagt 105 wird, können auch Dienstverträge in Betracht kommen. In aller Regel würden dann die betroffenen Unternehmen eigene Mitarbeiter oder für diesen Fall speziell von ihnen eingestellte Mitarbeiter einsetzen und nicht das Softwareunternehmen beauftragen. Wird dem Kunden lediglich ein Standardprogramm zur Datenübernahme 106 geliefert, handelt es sich um eine Software-Überlassung, die Kaufrecht bzw. bei zeitweiliger Überlassung Mietrecht unterliegt3. Altdatenübernahme als isolierte Aufgabe ist allerdings eher ein ausge- 107 sprochener Ausnahmefall. Üblicherweise wird diese Aufgabe von dem Unternehmen mitübernommen, das die Software auch im Übrigen liefert. Es handelt sich dann um einen zusätzlichen Leistungsaspekt, der im Prinzip Werkvertragsregeln unterliegt. In aller Regel dürfte es sich um eine – oft sehr wichtige – Nebenaufgabe handeln, die dem Vertrag nicht sein einheitliches Gepräge gibt, aber bei der Behandlung von Fehlern den Regeln über dem Werkvertragsrecht auch dann unterliegt, wenn der Vertrag im Übrigen Kaufvertragsregeln unterliegt. 1 OLG München v. 15.2.1989 – 27 U 386/08, CR 1990, 646. 2 Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 96 f. 3 OLG Köln v. 8.5.1992 – 19 U 234/91, CR 1992, 607; vgl. auch Schneider, Handbuch des EDV-Rechts, D Rz. 129.

Redeker

349

D Rz. 108

Verträge

hh) Agile Softwareentwicklung 108

Besonderer Betrachtung bedürfen moderne Softwareentwicklungsmethoden, die in der Praxis zunehmend zum Einsatz kommen. Bei diesen Entwicklungsmethoden, die unter dem Begriff „Agile Softwareentwicklung“ zusammengefasst werden, wird die der bisherigen rechtlichen Bewertung zugrunde liegende Entwicklungsmethodik aufgegeben, nach der zunächst ein Lasten- bzw. Pflichtenheft erstellt und dann erst auf der Basis dieses Pflichtenheftes programmiert wird. Vielmehr wird zwar zunächst die Zielrichtung der Softwareentwicklung bestimmt, also z.B. festgelegt, dass es um eine Finanzbuchhaltung oder einen Internetauftritt geht. Danach werden aber Prototypen entwickelt, bei denen mit jeweils relativ kurzfristigen Zwischenzielen mit dem Kunden die Weiterentwicklung regelmäßig abgestimmt wird. Die Entwicklung wird also nicht von einem von vornherein definierten Leistungsverzeichnis bestimmt. Vielmehr entstehen immer wieder neue Prototypen in einzelnen kurzen Entwicklungsphasen (sog. Sprints). Nach einer hinreichenden Menge von Sprints ist die Software dann einsatzfähig1.

109

In der Praxis soll sich insbesondere bei kleineren Projekten eine solche Methode durchaus bewährt haben. Sie greift die praktische Erfahrung der regelmäßigen Änderungsbedürfnisse auch in der Methodik auf und unterscheidet nicht mehr zwischen ursprünglicher Definition und Leistungsanpassung, sondern greift die Erstellung der Software als einen dauernden Prozess immer neuer Leistungsdefinitionen anhand der Grobziele und der bisherigen Entwicklung.

110

Das juristische Problem – ggf. auch das kalkulatorische Problem – liegt darin, dass am Anfang gar nicht so ganz genau klar ist, was denn nun als Leistung geschuldet ist. Demgemäß lässt sich auch der notwendige Aufwand zur Erreichung des Ziels nicht wirklich bestimmen. Dokumente, die den Entwicklungsprozess beschreiben, geben nicht etwa das Ergebnis wieder wie beim Pflichten- bzw. Lastenheft, sondern beschreiben Projektabläufe und Fristenpläne. Die Planung des Entwicklungsprozesses stellt sich bei diesen Projektmethoden als Teil der Leistung dar und nicht als getrennt abtrennbare Leistungsphase. Änderungsanforderungen sind Teil des Prozesses und keine Ausnahme. Konsequent ist es im Übrigen, dass der Auftraggeber sehr umfangreich Mitwirkungsobliegenheiten, ggf. auch Mitwirkungspflichten hat2.

111

Die in der Literatur aufgestellte Behauptung, auch eine Benutzerdokumentation sei nicht geschuldet3, ist aber nicht zutreffend. Eine Benutzerdokumentation ist bei agiler Entwicklung der Software in gleichem Umfang wie 1 Vgl. zum Ganzen: Auer-Reinsdorff, ITRB 2010, 93; Kremer, ITRB 2010, 283; Hengstler, ITRB 2012, 113; Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 131 ff. 2 Lapp, ITRB 2010, 69 (71 f.); Koch, ITRB 2010, 114 (118 f.). 3 So Kremer, ITRB 2010, 283 (287).

350

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 117 D

bei anderer Software geschuldet (dazu unten Rz. 119 ff.), weil ja die Nutzer der Software mit dem Entwicklungsprozess nichts zu tun haben und die Software in gleicher Art und Weise nutzen können müssen wie jede anders entwickelte Software. Anders mag dies bei der Entwicklungsdokumentation sein. Nur durch diese ist aber eine Wartbarkeit und Änderbarkeit der Software gewährleistet. Vergleichbare Dokumente muss es auch bei agil entwickelter Software geben.

112

Auch bei der agilen Entwicklung muss natürlich das Projektziel so genau 113 wie möglich definiert werden. Darüber hinaus ist es so, dass konzerninterne und gesetzliche Vorschriften selbstverständlich auch von Software eingehalten werden müssen, die agil entwickelt worden ist. Es kann sein, dass aufgrund dieser Vorgaben eine agile Entwicklung nur sehr schwer möglich ist oder gar nicht in Betracht kommt1. Mangels genauer Definition ist auch schwer zu entscheiden, wie denn eine 114 Abnahme durchzuführen ist. Hier wird teilweise empfohlen, die Abnahme gegen den Projektplan sowie im Rahmen der Entwicklung erstellte Dokumentation durchzuführen2. Was genau wie gemacht wird und welches Abnahmeverfahren gewählt wird, muss ebenfalls vereinbart werden. Als juristische Grundfrage stellt sich die Frage, ob ein Softwareprojekt, das 115 nach agilen Projektentwicklungsmethoden entwickelt werden soll, überhaupt werkvertraglich geregelt werden kann3. Das fertigzustellende Softwareprodukt wird ja nicht sehr konkret beschrieben. Es gibt aber wenn auch vage Beschreibungen dessen, was die Software leisten soll. Ist diese Beschreibung – vernünftigerweise – Gegenstand des Auftrages, reicht dies zur Annahme eines Werkvertrages. Ein weiteres Problem besteht darin, dass der Kunde sehr umfangreich mit- 116 wirkt und auch einen sehr starken Einfluss auf den Inhalt des Werkes nimmt. Dies kann in Einzelfällen zur Annahme von Dienstverträgen oder gar gesellschaftsrechtlichen Regelungen führen4. Wenn aber sich aus den Vertragsunterlagen explizit oder implizit ergibt, dass die Herstellungsverantwortung für die Software beim Unternehmer verbleibt, wird man wohl von einem Werkvertrag ausgehen können. Es gibt aber auch anderweitige Vertragsgestaltungen, die auch z.B. dienstvertragliche Elemente mit einem Werkvertrag oder andersherum verbinden. Es empfiehlt sich daher dringend bei Softwareentwicklungsprojekten mit 117 agilen Methoden genaue Regelungen zu treffen, wie das Projekt im Einzelnen durchgeführt werden soll und wer für was verantwortlich ist. Hier sind

1 2 3 4

Koch, ITRB 2010, 114 (119). Kremer, ITRB 2010, 283 (287). Dagegen Hengstler, ITRB 2012, 113 (116). Frank, CR 2011, 138; Söbbing, ITRB 2008, 212 (214).

Redeker

351

D Rz. 118

Verträge

möglicherweise auch Regelungen zu Teilabnahme und Qualifikationen der Mitarbeiter nötig. 118

In individuellen Vereinbarungen ist dies alles regelbar. Bei kleineren Projekten macht dies aber wenig Sinn. Hinsichtlich von AGB wird aber – soweit man hier von einem Werkvertrag ausgehen kann – die an anderer Stelle (Rz. 231, 466 ff.) bezeichneten Grenzen zu beachten sein. 3. Nebenpflichten a) Lieferung von Dokumentationen aa) Benutzerhandbuch und Programmhilfen

119

Neben dem Programm als solchem gehört auch die Lieferung von Dokumentationen in aller Regel zum Lieferumfang. Was hier geschuldet ist, ergibt sich wie üblich zunächst aus den konkreten Vereinbarungen zwischen den Parteien. Ohne solche Vereinbarungen gilt Folgendes:

120

Auf jeden Fall geschuldet ist eine Anwenderdokumentation, die man auch als Benutzerhandbuch bezeichnen kann. Diese Dokumentation muss dem Benutzer alle Informationen geben, die dieser benötigt, um die Software nutzen zu können. Dargestellt werden müssen also die Einsatzmöglichkeiten der Software und auch die Art und Weise, wie man diese Möglichkeiten tatsächlich einsetzen kann1. Konkretisiert sind diese Anforderungen in der Norm DIN ISO/IEC 26514 aus 2008, die allerdings sehr umfangreich ist und deshalb nicht notwendig von allen Benutzerhandbüchern eingehalten werden muss2. Die Benutzerdokumentation muss die Funktionen des Programms vollständig, richtig, widerspruchsfrei, vollständig und übersichtlich beschreiben3. Sie muss die Systemfunktionen ebenso beschreiben wie sie eine Liste der Fehlermeldungen und notwendiger Benutzeraktionen enthalten muss. Je nach Einzelfall muss sie auch die Belege und Auswertungen darstellen. Diese Pflicht erstreckt sich bei individuell erstellter oder angepasster Software auf die vertraglich vereinbarten Funktionen, die oft durch Nutzungsfälle beschrieben werden. Bei angepasster Software sollte die Dokumentation der individuellen Software die Abweichungen von der Standardsoftware beschreiben. Daneben muss ein Handbuch zur Standardsoftware geliefert werden4. Der EDV-Gerichtstag hat 1999 einen sog. Saar-

1 OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95 (96); kritisch Krebber, AcP 201 (2001), 333 (341 f.); BGH v. 4.11.1992 – VIII ZR 165/91, Beilage Nr. 13 zu BB 1993, S. 2; Schneider, Handbuch des EDV-Rechts, D Rz. 799 ff.; Junker/ Benecke, Computerrecht, Rz. 193; Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 181 ff. 2 Stiemerling, ITRB 2011, 286 (287). 3 Sarre, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 1 Rz. 120 f. 4 Stiemerling, ITRB 2011, 286 (287 f.).

352

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 123 D

brücker Standard vorgeschlagen, der Kriterien zur Bewertung der Benutzerdokumentation beinhaltet1. Grundsätzlich ist es aber so, dass die Benutzerdokumentation so beschaffen 121 sein muss, dass die Softwarenutzer und nicht nur EDV-Fachleute sie verstehen können. Aus dieser generellen Regel ergeben sich unterschiedliche Anforderungen im Einzelfall, je nachdem, von welchen Nutzern die Software tatsächlich eingesetzt wird. Systemsoftware, die kundige EDV-Fachleute als Nutzer hat, bedarf eines anderen Benutzerhandbuchs als Programme, die von EDV-Laien benutzt werden. Grundsätzlich sollte die Dokumentation auch einen Laien in die Lage versetzen, das Programm nutzen zu können. Der Benutzer darf nicht auf marktübliche Einführungsbücher verwiesen werden, die es bei Individualsoftware ohnehin nicht gibt. Eine Schulung kann ein Benutzerhandbuch allerdings ebenso wenig ersetzen wie die Schulung das Benutzerhandbuch. Schulung und Benutzerhandbuch ergänzen sich und ersetzen sich (wie auch sonst Lehrer und Lehrbuch) nicht. Allerdings geht die Tendenz insbesondere bei Software, die hauptsächlich von Gelegenheitsbenutzern verwendet wird, zu selbsterklärenden Benutzeroberflächen – die zunehmend auch vertraglich geschuldet sind2. Hier gibt es kein Benutzerhandbuch für Gelegenheitsbenutzer. Die Benutzerdokumentation muss ferner ohne abweichende Regelung in der Regel in deutscher Sprache gehalten sein3. Ist freilich das Programm selbst zweisprachig, ist u.U. auch eine zweisprachige Benutzerdokumentation geschuldet4. Dagegen führt eine englische Benutzeroberfläche nicht ohne weiteres dazu, dass auch die Benutzerdokumentation auf englisch erstellt werden muss. Abweichende vertragliche Regelungen sind allerdings möglich.

122

In der Praxis haben sich neben der Benutzerdokumentation weitere Hilfe- 123 stellungen für den Benutzer entwickelt. Dieser kann in vielen Programmen online Benutzungshilfen benutzen, die bei konkreten Fragestellungen weiterhelfen. Es gibt auch sog. Rundtouren und andere während der Programmnutzung aufrufbare Schulungsmittel, die den Benutzer in das jeweils konkrete benutzte Programm einführen. Diese Hilfestellungen ersetzen aber ein ordentliches Benutzerhandbuch nicht. Auch die beste Rundtour kann einen mit Stichwortverzeichnis und Gliederung erschlossenen Text nicht ersetzen. Sowohl der Überblick über die gebotenen Möglichkeiten als auch die gezielte Aufarbeitung spezifischer Problemfelder ist praktisch nur mit 1 Dazu Bergmann/Potter/Streitz, CR 2000, 555. 2 Dazu Stiemerling, ITRB 2009, 154; ITRB 2011, 286 (287). 3 OLG Karlsruhe v. 21.2.1991 – 12 U 147/90, in: Zahrnt, ECR OLG 73; OLG Düsseldorf v. 18.8.1994 – 2 U 245/93, CR 1994, 753 = GRUR 1994, 902 (904); OLG Köln v. 20.1.1995 – 19 U 115/93, MDR 1995, 244 = NJW-RR 1996, 44; Beckmann, CR 1998, 519 (521); Junker/Benecke, Computerrecht, Rz. 196; Marly, Praxishandbuch Softwarerecht, Rz. 965; LG Koblenz v. 27.4.1995 – 12 S 163/94, CR 1995, 667 = NJW-RR 1995, 942. 4 OLG Köln v. 3.9.1999 – 19 U 54/99, CR 2000, 585.

Redeker

353

D Rz. 124

Verträge

einem entsprechend ausgestalteten Papierprodukt möglich. Der Umfang des auf dem Bildschirm lesbaren Textes ist gegenüber einer Papierseite deutlich begrenzt. Demgemäß zeigen alle praktischen Erfahrungen, dass die Lektüre im Papiertext nicht allein durch elektronische Medien ersetzt werden kann. Die bloße Lieferung elektronische Hilfehinweise reicht daher nicht. Ein Handbuch muss immer geliefert werden1. 124

Mittlerweile ist allerdings das Suchen in elektronischen Systemen oft so erleichtert, dass man im Hinblick auf Stichwortsuche u.Ä. mit elektronischen Suchmitteln besser fährt als mit den herkömmlichen Inhalts- oder Stichwortverzeichnissen. Insofern bietet sich eine doppelte Fassung der Dokumentation, elektronisch und gedruckt an. Es dürfte in aller Regel ausreichen, die Dokumentation elektronisch zu liefern mit der Möglichkeit für den Kunden, diese bei Bedarf oder vorsorglich auszudrucken und zwar nicht nur bei herunter geladener Software2. Die elektronische Version sollte dann aber in einem gängigen, auch die Nutzung von Suchfunktion erlaubenden Format (z.B. pdf) erfolgen. Eine Installationsanleitung muss – soweit zur Installation erforderlich – immer schriftlich vorliegen3. Dies gilt jedenfalls für die hier betrachteten umfangreichen Softwareprogramme. Ob die Beschränkung auf die Möglichkeit, die Dokumentation auszudrucken, im Bereich der Privatanwendungen (etwa für Computerspiele) auch gilt, ist wegen der für Verbraucher ggf. nicht unerheblichen zeitlichen und finanziellen Aufwände für den Druck zweifelhaft, bedarf aber hier keiner endgültigen Entscheidung4.

125

Die Benutzerdokumentation ist erst mit Abschluss der Programmierarbeiten zu liefern, nicht vorher. Vorher ist das Programm noch gar nicht fertiggestellt, Teile der Benutzeroberfläche können sich noch ändern. Eine Benutzerdokumentation kann daher noch gar nicht fertiggestellt werden5. bb) Weitere Dokumentationen

126

Neben der Benutzerdokumentation gibt es weit umfangreichere Dokumentationen, die für die Pflege und Weiterentwicklung des Programms von zentraler Bedeutung sind. Man spricht hier von Programm- und Entwicklungsdokumentationen oder auch Wartungsdokumentationen. Normen für diese 1 Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 28; OLG Frankfurt v. 17.12.1991 – 5 U 265/90, CR 1993, 93 (LS); a.A. OLG Karlsruhe v. 25.7.2003 – 14 U 140/01, CR 2004, 493. 2 LG Heilbronn v. 16.12.1993 – 1 KfH O 262/89, Beil. 7 zu BB 1994, S. 7; Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 195 f.; vgl. auch Schneider, ITRB 2010, 241. 3 Junker/Benecke, Computerrecht, Rz. 195; Beckmann, CR 1998, 519 (520 f.); a.A.: gedruckte Dokumentation erforderlich: Marly, Praxishandbuch Softwarerecht, Rz. 963 f. 4 Eine vergleichbare Einschränkung macht Beckmann, CR 1998, 519 (521). 5 BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367 = NJW 2001, 1718; Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 190.

354

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 128 D

Dokumentationen gibt es nicht. Die Normen DIN 66230 (Programm-Dokumentation), DIN 66231 (Programmentwicklung-Dokumentation) und DIN 66232 (Datenbeschreibung) sind aufgehoben worden. Viele Systemhäuser haben auch eigene Richtlinien für die Führung der oben genannten Dokumentationen. Ist freilich im Vertrag von den hier genannten Dokumentationen die Rede, ohne dass es irgendwelche Hinweise auf die Art und Weise der Gestaltung gibt, dürfte der Inhalt schwer zu bestimmen sein1. Allerdings ist fraglich, ob ohne konkrete Vereinbarung die hier genannten 127 weitergehenden Dokumentationen vom Softwareersteller überhaupt seinem Kunden geliefert werden müssen. Die Rechtsfrage ist wegen der gleichen Interessenlage der Parteien in gleicher Weise wie die Frage zu entscheiden2, ob der Quellcode des zu liefernden Programms herauszugeben ist, der auch ein Teil dieser Dokumentation ist3. Daher ist die Rechtsprechung zu dieser Rechtsfrage auch an dieser Stelle heranzuziehen. In einer alten Entscheidung bestätigte der BGH4 eine restriktive Vertragsauslegung der Vorinstanz, die trotz der Übertragung ausschließlicher Nutzungsrechte den Vertrag so ausgelegt hatte, dass keine Änderungsbefugnis übertragen und daher auch kein Quellcode zu liefern sei. Diese sehr einzelfallbezogene Entscheidung führte zu keiner klaren Linie in der Rechtsprechung. Vielmehr ergaben sich unterschiedliche, sehr einzelfallbezogene Entscheidungen von Instanzgerichten. So hat das LG München I in einer ebenfalls recht alten Entscheidung5 aus- 128 geführt, der Hersteller einer Individualsoftware schulde schon dann die Herausgabe des Quellcodes, wenn er weder aus einem Wartungsvertrag noch aus Gewährleistungsrechte zur Mängelbeseitigung verpflichtet sei6. Mit der Tatsache, dass Kunde nur einfache Nutzungsrechte erworben hatte, beschäftigte sich das LG München I nicht. Das LG Aschaffenburg7 nahm eine Herausgabepflicht jedenfalls für den Fall an, dass die Individualsoftware für die Weitervermarktung bestimmt war und kein langfristiger Pflegevertrag geschlossen wurde. Das OLG Köln8 führte – allerdings in einem obiter dictum – aus, dass eine Herausgabepflicht grundsätzlich dann bestehe, wenn nicht 1 Generelle Hinweise bei Sarre, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 1 Rz. 121. 2 Junker/Benecke, Computerrecht, Rz. 191. 3 Koch, Handbuch Software- und Datenbank-Recht, § 1 Rz. 81; Schneider, Handbuch des EDV-Rechts, H Rz. 76 ff.; OLG Karlsruhe v. 14.5.1998 – 11 U 39/96, CR 1999, 11 (12). 4 BGH v. 30.1.1986 – I ZR 242/83, CR 1986, 377. 5 LG München I v. 18.11.1988 – 21 O 11130/88, CR 1989, 990; kritisch Hoeren, CR 2004, 721 (723). 6 Ähnlich OLG Saarbrücken v. 22.9.1994 – 8 U 64/91, Beil. Nr. 16 zu BB 1995, S. 12 (13). 7 LG Aschaffenburg v. 16.12.1997 – 1 O 354/93, CR 1998, 203 (206). 8 LG Köln v. 3.5.2000 – 20 S 21/99, CR 2000, 505.

Redeker

355

D Rz. 129

Verträge

zugleich ein Pflegevertrag geschlossen werde, ohne auf den Gesichtspunkt des Weitervertriebs einzugehen. 129

Auch eine neuere Entscheidung des BGH1 hat an dieser Situation wenig geändert, weil auch sie eine einzelfallbezogene Interessenabwägung verlangt2. Es bleibt also bei der Auslegung des jeweils individuell geschlossenen Vertrages unter Berücksichtigung der Interessenlage beider Parteien.

130

Geht man von diesen Interessen aus, ist Folgendes festzuhalten: Die hier diskutierten Dokumentationen verraten sehr viel über die Programmstruktur und enthalten daher wichtiges Know-how, das die Softwareersteller nicht gerne aus der Hand geben3. Umgekehrt kann eine Weiterentwicklung und Pflege des Programms ohne diese Dokumentationen auf keinen Fall durchgeführt werden. Von der Interessenlage her muss man daher sagen, dass der Kunde dann, wenn er sämtliche Rechte an der Software erhält und auch Weiterentwicklung und Pflege übernimmt, auch ohne konkrete vertragliche Vereinbarung die weitergehenden Dokumentationen vom Softwareersteller erhalten muss4. Anderenfalls ist der mit dem Vertrag beabsichtigte Zweck, dem Kunden ein Softwareprogramm zu liefern, das dieser selbst weiterentwickelt und pflegt, nicht zu erreichen. Ein statisches Softwareprogramm, bei dem weder Pflege noch Weiterentwicklung möglich ist, ist für die Praxis ernsthaft nicht brauchbar. Demgemäß sind diese Dokumentationen in diesem Falle vom Softwareersteller zu liefern. Dies gilt ganz besonders dann, wenn vom Kunden die Vermarktung der Software beabsichtigt ist. Ob daneben das vom BGH5 ebenfalls genannte Preisargument eine Rolle spielen kann, ist eher zweifelhaft. Ohne sich aus den Vertragsverhandlungen ergebende weitere Anhaltspunkte vermag ein geringer Preis in aller Regel den sich aus den sonstigen Umständen ergebende Anspruch auf Lieferung von Herstellungs- und Wartungsdokumentation nicht auszuschließen.

131

Angesichts der vielen Unwägbarkeiten ist allerdings dringend zu raten, über die Frage, welche Dokumentationen in welcher Art und Weise geliefert werden sollen, im Einzelfall konkrete vertragliche Vereinbarungen zu treffen6.

132

Eine Regelung in AGB dürfte dafür in aller Regel nicht ausreichen. Weicht sie nämlich von dem konkreten Inhalt des Vertrages ab, greift der Vorrang der Individualabrede (§ 305b BGB) ein7. Auch als Indiz für die Vertragsausle1 2 3 4

BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490. Wie hier Hoeren, CR 2004, 721 (724); Junker/Benecke, Computerrecht, Rz. 191. Marly, Praxishandbuch Softwarerecht, Rz. 636. Ähnlich Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 35. 5 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490; ähnlich auch OLG Saarbrücken v. 22.9.1994 – 8 U 64/91, Beil. Nr. 16 zu BB 1995, S. 12 (13). 6 Ebenso Burkart, ITRB 2003, 53 (57). 7 A.A. LG Köln v. 15.4.2003 – 85 O 15/03, CR 2003, 484.

356

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 135 D

gung ist eine Klausel in AGB in aller Regel ungeeignet. Ist daher z.B. nach den individuellen Absprachen zwischen den Parteien klar, dass der Kunde alle Rechte an der Software erhält, diese gar weitervertreiben will, und übernimmt er außerdem Fehlerbeseitigung und Weiterentwicklung der Software, kann die sich daraus ergebene Pflicht zur Herausgabe der Herstellungs- und Wartungsdokumentation nicht durch eine Klausel in den allgemeinen Geschäftsbedingungen ausgeschlossen werden. Erhält umgekehrt der Kunde nur ein einfaches Nutzungsrecht und übernimmt der Hersteller neben den Gewährleistungspflichten langjährig die Pflege, kann der Kunde nicht durch seine AGB die nach den individuellen Vereinbarungen nicht gegebene Pflicht zur Herausgabe der Herstellungs- und Wartungsdokumentationen erzwingen. Geliefert werden muss die Herstellungs- und Wartungsdokumentation erst 133 mit der Lieferung des vollständigen Programms und nicht vorher1. Davon unabhängig ist es aus Qualitätssicherungsgründen notwendig, sie schon während der Programmerstellung (ggf. auch unter Verwendung entsprechender Tools) zu erstellen. Soweit bei einem vorzeitigen Abbruch eines Projekts ein Anspruch auf Lieferung schon fertiggestellter Teile der ursprünglich geschuldeten Software besteht, gibt es daher auch einen Anspruch auf die Lieferung der zu diesem Teil erstellten Dokumentation. cc) Rechtsfolgen der Nichtlieferung Wird eine notwendige Dokumentation nicht geliefert, handelt es sich um 134 eine teilweise Nichterfüllung2. Es fehlt schlicht ein Teil der zu liefernden Sachgesamtheit. Damit bleiben Nichterfüllungsregeln anwendbar. Daran ändert auch die Vorschrift des § 633 Abs. 3 BGB nicht, die eine Minuslieferung einem Sachmangel gleichstellt. Diese Vorschrift betrifft nur die Abweichung in der Menge, nicht jedoch die Nichtlieferung eines Teils eines einzelnen Leistungsgegenstands3. Wird eine fehlerhafte Dokumentation geliefert, gelten demgegenüber die gleichen Regeln wie auch sonst bei Mängeln4. Nimmt freilich der Kunde die Software ab, benutzt sie und rügt die Nichtlieferung des Benutzerhandbuchs nicht, kann der Erfüllungsanspruch nach

1 Marly, Praxishandbuch Softwarerecht, Rz. 1498. 2 BGH v. 3.11.1992 – X ZR 83/90, CR 1993, 352 = MDR 1993, 421 = NJW 1993, 1063; BGH v. 4.11.1992 – VIII ZR 165/91, Beil. Nr. 13 zu BB 1993, S. 2; OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95; Schneider, Handbuch des EDVRechts, D Rz. 778; Junker/Benecke, Computerrecht, Rz. 192; Marly, Praxishandbuch Softwarerecht, Rz. 604; Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 195; Schneider, ITRB 2007, 24. 3 Ebenso Koch, Handbuch des Software- und Datenbank-Rechts, § 1 Rz. 94 zu § 434 Abs. 3 BGB. 4 Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 30.

Redeker

357

135

D Rz. 136

Verträge

einer gewissen Zeit verwirkt sein1. Mit einer solchen Annahme muss man aber vorsichtig sein. Für Herstellungs- und Wartungsdokumentationen kann eine Verwirkung erst ab dem Zeitpunkt eintreten, in dem der Kunde die Weiterentwicklung und Fehlerbeseitigung tatsächlich übernimmt. b) Lieferung von Quellcode und Datenmodellen 136

Ein ähnliches Problem wie bei der Herstellungs- und Wartungsdokumentation stellt sich bei der Lieferung von Quellcode und Datenmodellen. Diese Unterlagen sind in aller Regel in weiten Teilen in der Herstellungs- und Wartungsdokumentation zu ersehen oder vollständig in diesen enthalten. Demgemäß stellen sich die gleichen Probleme wie oben. Ist nichts Konkretes im Vertrag geregelt, muss in jedem Einzelfall entschieden werden, ob Quellcode und Datenmodell des Programms geliefert werden müssen oder nicht. Das Ergebnis dürfte sich im Wesentlichen nach den oben (Rz. 126 ff.) dargestellten Ergebnissen richten. Erwirbt der Kunde umfassende Rechte an der Software und ist klar, dass er Weiterentwicklung und Pflege durchführt, muss ihm auch der Quellcode und das Datenmodell geliefert werden. Ist dies nicht der Fall, dürfte eine solche Pflicht ohne konkrete vertragliche Vereinbarung nicht bestehen.

137

Zu bemerken ist, dass es in einer Reihe von Fällen heute praktisch so ist, dass der Quellcode aus technischen Gründen mitgeliefert werden muss, weil das Programm sonst nicht ablauffähig ist. Dies gilt für alle interpretierten Programme. In diesen Fällen muss man über die Lieferung des Quellcodes naturgemäß nicht streiten. Er muss geliefert werden, weil das Programm sonst nicht ablauffähig ist. Streitig kann allenfalls sein, in welchem Umfang der Quellcode vom Kunden genutzt werden darf.

138

Ist die Lieferung des Quellcodes geschuldet, gehören zum Lieferumfang auch eventuell benutzte Link-Bibliotheken, weil nur so die Wartbarkeit der Software gesichert ist2. Allerdings gilt dies nur dann, wenn die Link-Bibliotheken mit zum individuellen Leistungsprogramm gehören. Sind sie Standardsoftware, die vom individuellen Programm nur genutzt wird, muss ihr Quellcode im Zweifel nicht geliefert werden. Wird im Quellcode Bezug genommen auf Bibliotheksprogramme, die anderweitig erworben werden müssen, so muss im Vertrag oder in der Leistungsbeschreibung klargestellt werden, dass das Programm nur nach Erwerb dieser Programmbibliothek nutzfähig ist. Dies gehört in den Bereich der Beratungspflichten über die Systemumgebung.

1 Schneider, Handbuch des EDV-Rechts, D Rz. 808 ff.; Marly, Praxishandbuch Softwarerecht, Rz. 1498; OLG Köln v. 20.1.1995 – 19 U 115/93, CR 1995, 334 = MDR 1995, 244 = NJW-RR 1996, 44. 2 LG Köln v. 3.5.2000 – 20 S 21/99, CR 2000, 505.

358

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 144 D

c) Beratungspflichten Auch nach Vertragsschluss kann es Hinweis- und Beratungspflichten geben. 139 In erster Linie werden sich die Beratungspflichten auf Probleme erstrecken, deren Vorliegen sich erst während der Durchführung des Projekts herausstellt. Insoweit ist ein Mitdenken des Softwareerstellers – wie das jedes Werkunternehmers – während der gesamten Vertragsdauer für den Projekterfolg nötig1. So kann es sein, dass das beauftragte Programm in der vereinbarten System- 140 umgebung möglicherweise nicht so erstellt werden kann, dass es mit der wünschenswerten Performance läuft, und daher konzeptionelle Änderungen des Programms oder Änderungen in der Systemumgebung vorgenommen werden müssen, um die gewünschte Performance zu erreichen. Über das Vorliegen dieser Probleme muss aufgeklärt und beraten werden. Nur so kann der Auftraggeber entscheiden, ob er mit der erreichbaren geringeren Performance zufrieden ist oder ob er Änderungen wünscht, die dann im vorgesehenen Änderungsverfahren zu diskutieren sind. Es kann auch sein, dass sich in der Systemumgebung während der Pro- 141 grammerstellung Entwicklungen ergeben. Es können z.B. vom Hersteller der Betriebssoftware neue Versionen dieser Betriebssoftware herausgebracht worden sein. Es muss dann entschieden werden, ob diese neuen Versionen in der Programmerstellung berücksichtigt werden sollen oder ob man die Entwicklung zunächst auf Basis der alten Versionen der Betriebssoftware zu Ende führt und die Anpassung des Programms an die neuen Versionen der Betriebssoftware erst als Pflegeleistung erbringt. Während der Projektdauer können auch Fehler oder Widersprüche im Pflichtenheft auftauchen, auf die der Unternehmer hinweisen muss (vgl. auch oben Rz. 8 f.)2.

142

Auch gesetzgeberische Änderungen können den Leistungsumfang und den 143 Inhalt der zu erstellenden Software beeinflussen, insbesondere dann, wenn die Software – wie etwa Abrechnungssoftware von Ärzten oder Buchhaltungssoftware – gesetzlichen Anforderungen entsprechen muss. Auch über diese Änderung muss der Softwareersteller aufklären. Diese Änderungen müssen während der Softwarereerstellung auf jeden Fall berücksichtigt werden. Beratungsprobleme können sich auch dann ergeben, wenn Entwicklungen innerhalb des Betriebs des Auftraggebers Änderungen der beauftragten Software wünschenswert erscheinen lassen. Auf Nachfrage des Auftraggebers muss der Auftragnehmer auch hier beraten – allerdings nur gegen ein angemessenes Zusatzentgelt. 1 Staudinger/Peters/Jacoby, § 633 BGB Rz. 63. 2 OLG Celle v. 20.2.1991 – 6 U 15/90, Zahrnt, ECR OLG 71; Intveen/Lohmann, CR 2003, 640 (643); Heussen, CR 2004, 1 (5).

Redeker

359

144

D Rz. 145 145

Verträge

Der Umfang der Beratungspflichten hängt – ähnlich wie bei den vorvertraglichen Beratungspflichten (vgl. Rz. 4 ff.) – von den Kenntnissen der Beteiligten ab1. Jedenfalls Hinweise auf bestehende Probleme muss der Auftraggeber aber immer geben. 4. Fehlen des Pflichtenheftes a) Grundsätzliches

146

Immer wieder kommt es vor, dass ein Programm erstellt wird, obwohl kein Pflichtenheft und keine anderweitige ordnungsgemäße Leistungsbeschreibung vorliegt. Daraus ergeben sich erhebliche rechtliche Probleme. Ein wichtiges Problem besteht darin, dass dann möglicherweise der Leistungsumfang gar nicht festgestellt werden kann. Darauf ist im Zusammenhang mit den Ansprüchen aus Mängeln näher einzugehen. Klar ist allerdings, dass ein Pflichtenheft Voraussetzung für eine ordnungsgemäße Programmerstellung ist (vgl. Rz. 8 f.).

147

Fehlt ein Pflichtenheft und wird das Programm trotzdem hergestellt, muss zunächst gefragt werden, wer denn das Pflichtenheft erstellen soll. Das Pflichtenheft ist Teil der Leistungsbeschreibung, so dass im Prinzip die Herstellung des Pflichtenheftes Sache des Auftraggebers ist, genauso wie für die Beauftragung eines Bauunternehmers die Baupläne vorher vom Auftraggeber bzw. in seinem Auftrag vom Architekten hergestellt werden müssen2. Im Softwarebereich ist dies teilweise allerdings anders. Zunächst weiß nicht jeder Auftraggeber, dass ein Pflichtenheft erforderlich ist. Fehlt ein solches, muss demgemäß der Unternehmer darauf hinweisen, dass ohne ein solches Pflichtenheft die Aufgabe nicht ordnungsgemäß erfüllt werden kann. Diese Hinweispflicht ist ein Teil der vorvertraglichen Beratungspflichten (oben Rz. 8)3. In aller Regel wird der Auftraggeber auf Grund dieser Vorschläge den Auftragnehmer bitten, das Pflichtenheft zunächst zu erstellen. Vielfach gehört dies auch zum Leistungsumfang der Programmerstellung. Kommt es zu einem solchen Auftrag, muss die Erstellungspflicht sorgfältig von der Programmerstellung getrennt und das Pflichtenheft zunächst erstellt werden. In aller Regel wird es auch getrennt vom Programm abgenommen werden. Erst ab diesem Zeitpunkt ist eine endgültige Leistungsbeschreibung hergestellt. b) Fehlende Mitwirkung des Auftraggebers

148

Der Auftraggeber kann die Erstellung des Pflichtenheftes auch selbst übernehmen oder es einem Dritten in Auftrag geben. Dann muss der Softwareersteller erst abwarten, dass der Dritte liefert. Danach kann er programmie1 Marly, Praxishandbuch Softwarerecht, Rz. 1116 ff. 2 Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 16. 3 Zum Ganzen auch Intveen/Lohmann, CR 2003, 640 (642 ff.).

360

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 151 D

ren. Bei einer solchen Aufgliederung wird der Softwareersteller in der Regel nicht mit der Programmerstellung anfangen, bevor nicht das Pflichtenheft vorliegt. Vielmehr wird der Softwareersteller die Herstellung des Pflichtenheftes durch den Kunden nach § 642 BGB anmahnen und danach seine Rechte aus §§ 642 ff. BGB wahrnehmen1. Möglicherweise kann der Softwareersteller sich – bei Handelsgeschäften – auch auf § 375 HGB berufen und nach Fristsetzung das Pflichtenheft selbst erstellen2 – ein Weg, der in vielen Fällen aber praktisch schwer zu beschreiten sein wird, weil der Softwareersteller die internen Organisationsstrukturen und Bedürfnisse des Kunden und seiner Mitarbeiter zu schlecht kennen wird. Wird die Software dennoch einvernehmlich – und nach einem entsprechend 149 deutlichen Hinweis des Softwareunternehmens –, ohne Pflichtenheft erstellt, muss versucht werden, den Vertragsinhalt auch ohne Pflichtenheft näher zu bestimmen. Dies wird oft schwer fallen. Im Interesse des vertragsgetreuen Softwareerstellers muss man dann aber in besonders großem Umfang auf die Anforderungen abstellen, die nach Stand der Technik durchschnittlich üblich sind. Mehr kann der Auftraggeber jedenfalls nicht erwarten3. Kann man aber auch unter Zuhilfenahme solcher Regeln den Vertragsinhalt nicht feststellen, gibt es keinen wirksamen Vertragsschluss. Hier muss der Unternehmer auf die Regeln über die mangelnde Mitwirkung des Auftraggebers zurückgreifen. c) Pflichtverletzung des Softwareerstellers Immer wieder kommt es aber vor, dass entweder der Hinweis des Software- 150 erstellers unterbleibt oder dieser den Auftrag zur Herstellung des Pflichtenhefts erhält und es nicht herstellt, sondern gleich die Software erstellt. Diese Fälle sollen näher betrachtet werden. Erste Probleme treten dann auf, wenn die Software erstellt, vom Kunden 151 aber wegen Mängeln, die dieser sieht, oder aus anderen Gründen nicht abgenommen wird. Fehlt jetzt das Pflichtenheft oder eine vergleichbare Leistungsbeschreibung, so muss zunächst festgestellt werden, ob man bei Fehlen dieses Pflichtenheftes überhaupt feststellen kann, was Inhalt des Vertrages ist. Kann man dies aus den sonstigen Unterlagen feststellen, so kann anhand dieser Unterlagen dann auch geprüft werden, ob das Programm mangelhaft ist oder nicht. Ist das Programm mangelfrei, bedarf es keiner Erstellung des Pflichtenheftes mehr. Das Programm ist abnahmefähig. In aller Regel wird man aber den Leistungsinhalt nicht genau feststel1 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 140 f. 2 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 141 ff., eher zweifelhaft. 3 Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 16; vgl. auch BGH v. 29.9.1991 – X ZR 85/90, Beilage Nr. 3 zu BB 1993, 2; OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732.

Redeker

361

D Rz. 152

Verträge

len können. Ohne Pflichtenheft werden sich viele Details dessen, was das Programm leisten muss und wie es ausgestaltet sein muss, nicht feststellen lassen. Demgemäß dürfte in aller Regel der Vertrag unvollständig sein1. Es besteht dann die Pflicht des Softwareerstellers, das Pflichtenheft noch nachträglich herzustellen. Es handelt sich insoweit um eine Hauptpflicht2. Das fehlende Pflichtenheft ist eine teilweise Nichterfüllung. Für den Kunden ergeben sich damit die Rechte aus § 323 BGB. Der Kunde kann dann noch eine entsprechende Frist setzen und danach ggf. vom Vertrag zurücktreten. Ggf. kann er auch Schadensersatz nach § 281 Abs. 1 BGB verlangen3. Wird das Pflichtenheft nachträglich erstellt, muss das erstellte Programm den Anforderungen des Pflichtenheftes entsprechen. Natürlich muss auch das Pflichtenheft mangelfrei sein. 152

Ferner kann es sein, dass der Kunde das Programm abnimmt und in Produktivbetrieb nimmt bzw. dort, wo § 651 BGB anwendbar ist, das Programm abgeliefert und vom Kunden dann in Betrieb genommen wird. Erst danach erhebt er Mängelrügen. Nach Abnahme und Billigung wird man in aller Regel nicht mehr davon ausgehen können, dass das Pflichtenheft notwendig ist, um festzustellen, was Leistungspflicht des Softwareerstellers ist. Vielmehr ergibt sich der Leistungsumfang aus dem laufenden Programm, das ja konkretisiert und abgeliefert oder sogar abgenommen und in Betrieb genommen wurde, also im Wesentlichen als mangelfrei akzeptiert worden ist. Dies geschieht meist ja auch nur, wenn ein zumindest rudimentäres Benutzerhandbuch vorliegt. Aus Programm und Benutzerhandbuch wird man den geschuldeten Leistungsumfang herleiten können. Anstelle vertraglicher Konkretisierungen tritt in Zweifelfällen das, was dem üblichen Gebrauch entspricht (vgl. dazu Rz. 247). Es macht jedenfalls keinen Sinn, jetzt noch ein Pflichtenheft erstellen zu lassen, wenn schon andere Dokumente der Leistungsbeschreibung existieren.

153

Das Problem ist insgesamt von den Instanzgerichten und dem Bundesgerichtshof teilweise unterschiedlich gesehen worden, wobei in der Rechtsprechung wohl nicht immer klar die beiden unterschiedlichen Fälle getrennt werden. Jedenfalls der BGH hat entschieden, dass nach Fertigstellung eines Programms die Pflicht zur Erstellung des Pflichtenheftes entfällt4. Das Programm war freilich nach dem Sachverhalt noch nicht abgenommen worden.

1 A.A. OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732. 2 OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 361; wohl auch OLG Köln v. 3.12.1993 – 19 U 157/93, CR 1994, 229 (LS). 3 OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 361; Ihde, CR 1999, 409 (413) noch zu § 326 BGB a.F.; Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 30, Rz. 17. 4 BGH v. 29.9.1991 – X ZR 85/90, Beilage Nr. 3 zu BB 1993, 2; LG Berlin zitiert bei Ihde, CR 1999, 409 (412).

362

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 157 D

In der Literatur wird teilweise auch vertreten, dass selbst dann, wenn man 154 den Leistungsumfang aus anderen Produkten feststellen kann, es eine Nebenpflicht zur Herstellung des Pflichtenheftes gibt. Dies kann man aber so nicht sagen. Entweder muss ein Pflichtenheft neu erstellt werden, weil dies zur Erstellung der Leistungsbeschreibung erforderlich ist. Dann ist die Erstellung Hauptpflicht. Oder das Pflichtenheft ist nicht mehr erforderlich. Dann gibt es keine Pflicht zu seiner Erstellung, auch nicht als Nebenpflicht. Zusammenfassend ist festzuhalten, dass dann, wenn das Pflichtenheft er- 155 stellt werden soll, aber nicht erstellt ist und dies vor Ablieferung und Billigung bzw. Abnahme der Leistung erfolgt, das Pflichtenheft noch erstellt werden muss und zwar als Hauptpflicht aus dem Vertrag. Erfolgt die Billigung bzw. Abnahme der Leistung, entfällt eine solche Pflicht in aller Regel. Der Leistungsumfang lässt sich dann aus den anderen gelieferten Dokumenten, insbesondere dem Benutzerhandbuch und eventuell sonstigen Dokumentationen und aus dem erstellten und gebilligten Programm selbst erschließen. 5. Änderung des Pflichtenprogramms a) Grundproblem Je umfangreicher das zu erstellende Programm ist, desto wichtiger werden 156 Änderungsverfahren. Auch bei noch so genauer Erstellung von Leistungsbeschreibungen, Pflichtenheften, DV-technischen Feinkonzepten und ähnlichen Dokumenten vor Beginn der Programmierarbeiten ergeben sich in der Praxis sehr häufig Notwendigkeiten für solche Änderungen. Dabei muss es sich nicht immer um Änderungen im materiellen Sinne handeln. Es kann auch sein, dass das Pflichtenheft oder die sonstige Leistungsbeschreibung an der einen oder anderen Stelle noch präzisiert werden muss. Unabhängig davon ergeben sich aber durchaus auch Änderungsbedürfnisse. Dies kann zunächst daran liegen, dass manche Probleme im Vorhinein nicht erkannt worden sind, aber im Laufe der Programmerstellung auftreten und gelöst werden müssen. Es kann auch daran liegen, dass sich im Laufe der Zeit durch eine Änderung der Unternehmenspolitik das Bedürfnis ergeben kann, die Software zu ändern. Änderungsbedarf kann sich auch ergeben, wenn die Systemumgebung sich ändert, sei es auf speziellen Wunsch des Kunden, sei es, weil der Hersteller die Systemumgebung ändert. Letztlich können auch gesetzgeberische Änderungen auf die Programmerstellung einwirken. Es kann immer wieder Änderungsbedarf geben. So verständlich dieser Änderungsbedarf ist, so müssen doch zwei Dinge beachtet werden. Zunächst muss sich der Unternehmer prinzipiell auf Änderungswünsche 157 seines Kunden nicht einlassen. Er ist nur verpflichtet, das Werk so zu erstellen, wie es zwischen ihm und seinem Kunden vereinbart ist. Allerdings gibt es Ausnahmen. Auf diese wird unten (Rz. 174 ff.) näher eingegangen. In der

Redeker

363

D Rz. 158

Verträge

Softwarebranche wird allerdings auch ohne solchen rechtlichen Zwang Änderungswünschen oft stattgegeben. Viele Softwareerstellungsverträge enthalten darüber hinaus Regelungen, die ein Verfahren zur Vereinbarung von Änderungen vorsehen und damit implizit davon ausgehen, dass es solche Änderungen geben wird („Change-Reqest-Vereinbarungen“; zum Ganzen auch unten Rz. 474 ff.)1. 158

Gleichgültig, ob es einen Rechtsanspruch auf Änderung gibt oder eine Änderung vom Softwareunternehmen freiwillig akzeptiert wird, gilt weiterhin Folgendes: Wenn man sich auf Änderungen verständigt, müssen diese klar definiert und dokumentiert sein. Es muss auch geklärt sein, ob die Änderungen am Leistungsumfang und an der Software zur Änderung anderer Bedingungen, z.B. des Preises, der Fertigstellungstermine oder der Systemanforderungen führen. Werden diese Rahmenbedingungen nicht beachtet, kann es zu erheblichen Problemen allein wegen der vereinbarten Änderungen kommen. Es kann auch streitig sein, ob bestimmte Änderungen vereinbart sind. Auch kann es sein, dass ein geänderter Code erstellt wird, dadurch sich aber Termine zur Fertigstellung verändern, ohne dass dies klar vereinbart worden ist. All diese Fragen müssen durch klare Vereinbarungen im Vorfeld geklärt werden.

159

Darüber hinaus muss man darauf achten, dass sich Zahl und Umfang der Änderungen in Grenzen halten. Werden zu viele Änderungen vereinbart, führt dies zu erheblichen Zusatzaufwendungen. In aller Regel müssen ja auch schon erstellte Programmteile wieder verändert und dadurch zusätzlicher Aufwand betrieben werden. Außerdem steigt das Fehlerrisiko. Man muss sich daher bei jedem Änderungsbegehren sorgfältig überlegen, ob das Änderungsbegehren so gewichtig ist, dass es trotz dieser Probleme berücksichtigt werden muss. Es wird in der Literatur immer wieder festgestellt, dass alle gescheiterten Projekte einen besonders hohen Änderungsbedarf aufweisen. Dies kann auch an einer von vornherein fehlenden oder fehlerhaften Pflichtenhefterstellung liegen. Es kann aber auch daran liegen, dass der Kunde bei seinen Änderungswünschen nicht bedenkt, dass jeder Änderungswunsch zu zusätzlichen Komplikationen und zu zusätzlichem Aufwand führt.

160

Es muss dem Kunden auch klar sein, dass zusätzlicher Aufwand vergütet werden muss. In anderen Bereichen ist dies selbstverständlich. So können bei der Errichtung von Gebäuden durchaus Zusatzwünsche und Änderungswünsche des Kunden aufgenommen werden. Es versteht sich aber von selbst, dass der zusätzliche Aufwand vergütet werden muss.

161

Der immaterielle Charakter der Software führt in der Praxis dazu, dass die ja nur in zusätzlicher Arbeitsleistung bestehenden zusätzlichen Aufwendungen häufig unterschätzt werden. Softwarefirmen neigen auch dazu, hier

1 Dazu Müller-Hengstenberg, CR 2005, 385 (390 f.).

364

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 165 D

Zugeständnisse zu machen, die die Projektkalkulation durchaus gefährden können. Ein ordentliches Änderungsverfahren, muss diesen Gefahren vorbeugen. b) Vereinbartes Verfahren Zur Vorbeugung und Aufarbeitung der hier angesprochenen Probleme ist 162 zunächst ein klar definiertes Verfahren notwendig, indem Änderungswünsche bearbeitet werden. Dieses Problem ist nicht neu. Schon die BVB-Erstellung enthielt einen § 5, 163 der sich mit der Änderung der Leistung beschäftigte. Es wurde hier ein stark formalisiertes Verfahren eingeführt, indem der Auftraggeber schriftlich Änderungswünsche äußern konnte. Der Auftragnehmer konnte die Änderungen als unzumutbar ablehnen, konnte aber allerdings auch verlangen, dass eine umfangreiche Prüfung durchgeführt wird, zu welchen Bedingungen die Änderung durchführbar sei. Diese Prüfung musste dann der Auftraggeber wiederum vergüten. Dies konnte der Auftraggeber seinerseits wieder ablehnen. Wurde das Änderungsverlangen nicht binnen einer Frist abgelehnt oder eine Prüfung verlangt, galt es als zugestanden. Während der gleichen Frist musste der Auftragnehmer auch klarstellen, dass er die Änderungen zwar durchführen wollte, aber dafür vertragliche Bedingungen, z.B. Preis, Ausführungsfristen, Abnahme o.Ä. geändert werden müssten. Es wurde sogar geregelt, dass der Auftraggeber verlangen konnte, die Arbei- 164 ten zu unterbrechen, bis das Änderungsverlangen geklärt wird, jedenfalls soweit es Teile betraf, die vom Änderungsverlangen berührt werden konnten. Konnte man sich nicht auf eines der oben beschriebenen Verfahren einigen, wurde das Änderungsbegehren als abgelehnt behandelt. Dies ist nur ein Beispiel für ein definiertes Änderungsverfahren. Andere Verfahren sind möglich. Man kann auch gemeinsame Gremien gründen, in denen über Änderungsverlangen diskutiert wird und in denen sodann eine eventuelle Vereinbarung über eine Leistungsänderung protokolliert wird. Vorschläge zu möglichen Vereinbarungen werden unten gemacht (vgl. Rz. 474 ff.). Gibt es keine solche Vereinbarung, muss einem klar sein, dass in aller Regel 165 Änderungsvereinbarungen konkludent zustande kommen können. Allerdings müssen die jeweils Handelnden für solche Änderungsbegehren die entsprechende Vollmacht haben. Sind freilich solche Änderungsbegehren von Technikern vereinbart worden und mehrfach dies dann auch von der Projektleitung gebilligt und die Programme entsprechend umgestellt und abgenommen worden, dürfte sich sogar eine Anscheins- oder Duldungsvollmacht für die entsprechenden Techniker ergeben. Änderungen werden so unkoordiniert und oft auch ohne Gedanken an die kaufmännischen Folgen vereinbart. All dies kann auch nicht ohne weiteres durch eine Schriftformklausel verhindert werden, an deren Wirksamkeit in AGB ohnehin Zweifel bestehen (dazu unten Rz. 477 ff.) und die selbst in individuellen

Redeker

365

D Rz. 166

Verträge

Vereinbarungen großer Sorgfalt bedarf1. Um solchen chaotischen Änderungen vorzubeugen, sind definierte Verfahren sinnvoll. 166

Auch die Vereinbarung von Änderungsverfahren hilft freilich dann nicht, wenn in der Praxis des Projekts anders gehandelt wird als vereinbart. Die Vorteile des vereinbarten Änderungsverfahrens gehen dann verloren. c) Stillschweigende Änderungen

167

Wird ein Änderungsverfahren nicht vereinbart, oder hält man sich im Projekt regelmäßig nicht an das Änderungsverfahren und ist daher die Vereinbarung des Änderungsverfahrens wohl als obsolet zu betrachten, stellt sich oft die Frage, wie Zusatzaufwendungen des Auftragnehmers zu behandeln sind. Wird hier nichts Konkretes vereinbart, muss zunächst festgestellt werden, ob überhaupt eine Änderung vorliegt oder ob lediglich Mängel beseitigt oder das Pflichtenheft präzisiert wird.

168

Schon an dieser Stelle zeigt sich wieder die Bedeutung des Pflichtenheftes. Ohne ein solches kann überhaupt nicht festgestellt werden, ob das, was oft der Hersteller als Änderung bezeichnet, überhaupt eine Änderung ist oder ob nicht nur vorher lediglich grob vereinbarte Leistungen lediglich nur präzisiert werden. Gilt das Letztere, ist ein Zusatzaufwand vom Unternehmer zu tragen. Die Rechtsprechung verlangt außerdem, dass dann, wenn ohne Pflichtenheft Software entwickelt wird, ein gewisser Anpassungs- und Änderungsaufwand von vornherein mit einzukalkulieren ist2. Der dabei entstehende Aufwand gilt daher als in einem Festpreis enthalten. Sich daraus ergebende zeitliche Verzögerungen müssen bei der Vereinbarungen von Terminen von vornherein berücksichtigt werden.

169

Hat man festgestellt, dass eine Änderung vorliegt und ist ein Festpreis vereinbart, ohne dass gleichzeitig mit der Änderung der Leistung auch der Festpreis geändert wird, wird der alte Festpreis als der weiterhin vereinbarte Preis für das geänderte Programm feststehen. Dies kann freilich nicht unbegrenzt gelten. Die Rechtsprechung hat im Baurecht bei einer vergleichbaren Rechtslage anerkannt, dass bei Überschreitung einer bestimmten Schmerzgrenze dem Bauunternehmer, bei deren Unterschreitung jedoch dem Bauherrn ein Festpreis als Pauschalpreis nicht mehr zugemutet werden kann. Die Grenze liegt etwa im Bereich von 20 bis 25 %3. Man wird auch für das EDV-Recht das Gleiche annehmen können, ohne dass dies bisher in der Rechtsprechung relevant geworden ist. Es muss aber immer um unvorher-

1 Karger, ITRB 2009, 18. 2 KG v. 1.6.1990 – 14 U 4238/86, CR 1990, 768. 3 BGH v. 20.10.1960 – VII ZR 126/89, Schäfer/Finnern, Z 2, 311 Bl. 5 (Erhöhung um 20 % noch zumutbar); OLG Stuttgart v. 9.3.1992 – 5 U 164/91, BauR 1992, 639 (Veränderung unter 20 % zumutbar); OLG München v. 16.1.1987 – 23 U 3869/86, MDR 1987, 407 = NJW-RR 1987, 598 (Risikorahmen etwa bei 20 %).

366

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 173 D

sehbaren Aufwand gehen. Ist der Aufwand an sich vorhersehbar, sind auch die Zusatzleistungen mit dem Festpreis abgegolten. Auch ohne Überschreitung der oben genannten Grenzen kann sich im Ein- 170 zelfall ergeben, dass auch ohne Vereinbarung eine Zusatzvergütung geschuldet ist. Dies gilt insbesondere dann, wenn die Änderung nicht eine bloße Modifikation der Leistung darstellt, sondern eine Ergänzung betrifft, so z.B. dann, wenn der Kunde ein zusätzliches Modul bestellt, dass im ursprünglichen Softwareauftrag nicht enthalten war und das ihm zusätzliche Funktionen zur Verfügung stellt. Dies ist ein Zusatzauftrag, von dem er annehmen muss, dass der Unternehmer ihn nicht kostenfrei erbringt (§ 632 BGB)1. Wird nur ein Aufwandsentgelt bezahlt, ergeben sich die dargestellten Pro- 171 bleme nicht. Allerdings muss ein zusätzlicher Aufwand für eine Mängelbeseitigung vom Kunden in der Regel nicht vergütet werden. Gleiches gilt dann, wenn Zusatzaufwand durch mangelhaftes Projektmanagement des Softwareerstellers verursacht wurde. Ist freilich das Projektmanagement des Kunden mangelhaft und verursachen diese Mängel Zusatzaufwand durch Änderungen, müssen diese wiederum vergütet werden. Ist der Zusatzaufwand auf mangelnde Aufklärung bei Vertragsabschluss 172 oder verspäteter Beratung im Projektverlauf zurückzuführen, muss der Zusatzaufwand vom Kunden in der Regel nicht vergütet werden. Etwas anderes gilt allerdings dann, wenn auch bei rechtzeitiger Aufklärung der Zusatzaufwand, hätte erbracht werden müssen. Dann muss dieser Zusatzaufwand wieder vom Auftraggeber getragen werden (so genannte Ohnehin-Kosten). Für die Tatsache, dass Ohnehin-Kosten vorliegen, ist freilich der Auftragnehmer darlegungs- und beweispflichtig. Wie man aus den vorstehenden Ausführungen sieht, stellen sich eine ganz 173 erhebliche Reihe von Fragen, wenn es keine klare Regelung über die Vergütung des Zusatzaufwandes zur Änderung gibt. Weitere Probleme stellen sich dann, wenn sich durch die Änderung notwendigerweise Fertigstellungstermine verzögern, dies aber nicht gesagt worden ist. Die Änderungen solcher Termine können jederzeit vereinbart werden. Der Unternehmer kann sogar in seinen AGB regeln, dass Änderungen in der Leistungen zu Änderungen in den Terminen führen2. Diese Regelungen müssen nur getroffen werden. All dieses zeigt noch einmal deutlich, warum Vereinbarungen zwingend erforderlich sind3.

1 BGH v. 8.1.2002 – X ZR 6/00, JurPC Web-Dok. 98/2002 = BB 2002, 648 (LS); Schneider, Handbuch des EDV-Rechts, H Rz. 192; vgl. dazu auch die Unterscheidung zwischen Massenerhöhung und Ergänzung des Leistungsverzeichnisses bei OLG Stuttgart v. 9.3.1992 – 5 U 164/91, BauR 1992, 639. 2 BGH v. 23.6.1992 – X ZR 92/90, CR 1993, 424. 3 Dazu ausgiebig Koch, ITRB 2008, 61.

Redeker

367

D Rz. 174

Verträge

d) Zustimmungspflicht des Softwareerstellers 174

Ein letztes Problem stellt sich im Zusammenhang mit Vertragsänderungen. Es kann sein, dass der Unternehmer Änderungswünsche des Kunden ablehnt. Dazu ist er rechtlich prinzipiell berechtigt. Niemand hat einen Anspruch auf Änderung des Vertrages. Vielmehr müssen Verträge mit dem Inhalt durchgeführt werden, der ursprünglich vereinbart war. Auch hier kann im Bereich des Änderungsverfahrens genau geregelt werden, wann es einen solchen Anspruch auf Zustimmung zu einem Änderungsverlangen gibt oder nicht. Gibt es eine solche Regelung nicht, gibt es grundsätzlich keinen Anspruch auf Änderung des Vertrages. Ein Anspruch auf Zustimmung zur Vertragsänderung kann sich freilich aus den Regeln über die Veränderung der Geschäftsgrundlage (§ 313 BGB) ergeben. Ein solcher Fall ist insbesondere dann denkbar, wenn Rechtsvorschriften in unvorhergesehener Weise geändert werden oder möglicherweise auch im Bereich der Systemumgebung überraschend grundlegende Änderungen der Betriebssysteme vom Hersteller des Betriebssystems vorgenommen werden und dem Kunden nicht zugemutet werden kann, auf die weiterentwickelte und grundsätzlich geänderte Version der Systemumgebung zu verzichten. In diesen Fällen dürfte eine Pflicht des Softwareerstellers bestehen, in eine Vertragsänderung – zu zumutbaren Bedingungen – einzuwilligen, wenn eine solche mit vertretbarem Aufwand durchgeführt werden kann1. Das Gleiche gilt dann, wenn sich das Änderungsbegehren aus einem zu ungenauen Pflichtenheft ergibt, auf das das Softwareunternehmen nicht oder nicht rechtzeitig hingewiesen hat2.

175

Daneben kann es sein, dass die Ablehnung eines Änderungswunsches dem Kunden auch das Recht gibt, den gesamten Erstellungsvertrag aus wichtigem Grund zu kündigen, ohne dass er auch bereits erstellte Leistung abnehmen muss. Dies kann insbesondere dann der Fall sein, wenn aus zwingenden betrieblichen oder sonstigen Gründen eine Änderung notwendig ist und von ihm nicht vermieden werden kann, die Änderung technisch für den Softwareersteller machbar ist – auch mit dem vorhandenen Personal oder mit leicht zu beschaffenden zusätzlichen Mitarbeitern – und der Kunde für die Änderung zumutbare Konditionen sowohl was den Preis, als was auch andere Rahmenbedingungen des Vertrages betrifft, anbietet. Verlangt dann der Softwareersteller im Hinblick auf die Zwangsposition des Kunden unangemessene weitere Vergütungen, zu lange Fertigungstermine o.Ä. oder lehnt er die Vertragsänderung generell ab, kann in wichtigen Einzelfällen ein wichtiger Grund für eine Kündigung des gesamten Vertrages vorliegen.

176

Liegt auch ein solcher Fall nicht vor, kann der Kunde nur eine Kündigung nach § 649 BGB aussprechen, die allerdings für ihn die – zumindest theoretisch – unangenehme Folge hat, dass er dann den vollen Werklohn abzüglich möglicher Ersparnisse des Unternehmens zahlen muss (dazu unten Rz. 434 ff.) 1 Marly, Softwareüberlassungsverträge, Rz. 1355. 2 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 158.

368

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 184 D

Alle vorstehenden Ausführungen gelten sowohl für den Fall, dass die Ände- 177 rungen einer Ergänzung oder Weiterung als auch für den Fall, dass die Änderungen einer Einschränkung des Softwareerstellungsprodukts bedürfen. 6. Fälligkeitsregelungen Im Rahmen von Softwareerstellungsverträgen ist das Softwareunternehmen vorleistungspflichtig. Dies gilt sowohl für Werkverträge als auch für Werkverträge, auf die § 651 BGB Anwendung findet.

178

Gilt reines Werkvertragsrecht, ist die Zahlung der Vergütung für den Unter- 179 nehmer erst nach Abnahme zu erbringen (§ 641 Abs. 1 Satz 1 BGB). Eine Ausnahme ergibt sich nur dann, wenn es Teilabnahmen mit gleichzeitiger Vereinbarung von Teilzahlungen gibt (§ 641 Abs. 1 Satz 2 BGB). Ist die erstellte Software abnahmereif i.S.d. § 640 Abs. 1 BGB, erklärt der Be- 180 steller aber nichts oder verweigert die Abnahme unberechtigt, kann das Softwareunternehmen ihm eine Frist zur Abnahmeerklärung setzen. Verstreicht diese ohne Erklärung, gilt die Software als abgenommen (§ 640 Abs. 1 Satz 3 BGB). Die Vergütung wird fällig. Lehnt der Besteller die Abnahme unberechtigt nach Fristsetzung ab, ist spätestens mit dieser Verweigerung die Vergütung fällig. Dies gilt freilich auch bei einer unberechtigten Abnahmeverweigerung ohne Fristsetzung1. Es empfiehlt sich dennoch, in Streitfällen die Frist nach § 640 Abs. 1 Satz 3 BGB zu setzen, um Klarheit über die Abnahme zu erhalten. Fälligkeit tritt außerdem dann ein, wenn der Kunde zwar die Abnahme be- 181 rechtigt verweigert, allerdings nur Minderungs- oder Schadensersatz und keine Erfüllung des Werkvertrages verlangt und auch nicht etwa vom Vertrag zurücktritt2. Für Verträge, für die Kaufrecht gilt, gilt Ähnliches. Die Vergütung ist dann 182 zwar prinzipiell bei Vertragsschluss fällig. Dem Kunden steht aber das Zurückbehaltungsrecht des § 320 Abs. 1 Satz 1 BGB zu. Praktisch muss er daher Zug um Zug mit der Ablieferung der Software zahlen. Immerhin ist der Unternehmer nicht in dem Sinne vorleistungspflichtig, 183 als dass er das Werk aus der Hand geben muss, bevor gezahlt werden muss. Er muss es nur geben, wenn er Zahlung erhält. Dennoch muss er seine ganze Leistung vor Zahlungspflicht erbringen. Diese Situation ist für den Unternehmer in aller Regel unbefriedigend, 184 meist finanziell auch gar nicht zu bewältigen, da die Mitarbeiter ebenso regelmäßig und in Zeitabschnitten entlohnt werden müssen, wie dies auch 1 Erman/Schwenker, § 641 BGB Rz. 4: Staudinger/Peters/Jacoby, § 640 BGB Rz. 44; § 641 BGB Rz. 6. 2 BGH v. 16.5.2002 – VII ZR 479/00, MDR 2002, 1188 = NJW 2002, 3019; BGH v. 10.10.2002 – VII ZR 315/01, NJW 2003, 288; OLG Hamm v. 19.12.1990 – 31 U 129/90, CR 1991, 411.

Redeker

369

D Rz. 185

Verträge

für die Miete entsprechender Räumlichkeiten und alle sonstigen Aufwendungen des Unternehmens gilt. Es ist für die meisten Unternehmer unmöglich, für den Rest wirtschaftlich untragbar, hier in einem großen Projekt über Monate und Jahre hinweg große Summen vorzufinanzieren und sie erst am Ende vergütet zu erhalten. 185

Wegen dieser Situation sind Vereinbarungen über Vorauszahlungen notwendig und auch üblich.

186

Die Regelungsmöglichkeiten sind groß. In aller Regel wird ein Vorschuss zu Beginn des Projekts gezahlt. Weitere Vorschüsse werden meist zum Abschluss definierter Zwischenschritte vereinbart. Gehört die Herstellung des Pflichtenheftes mit zum Leistungsumfang, ist der Abschluss einer Vereinbarung dringend anzuraten, in der eine Teilzahlung an die Fertigstellung des Pflichtenheftes geknüpft wird. Welche Projektfortschritte im Einzelnen dann weitere Teilzahlungen zur Folge haben, müssen die Parteien in aller Regel individuell aushandeln. Eine weitere Teilzahlung sollte dann fällig werden, wenn das Unternehmen die Software fertiggestellt hat, weitere größere Zahlungen nach Abnahme erfolgen.

187

Eine Restzahlung kann an den Ablauf der Verjährungsfrist für Mängel geknüpft werden. Eine solche Vereinbarung wäre jedenfalls nicht ungewöhnlich. Ersatzweise kann man zur Absicherung des Bestellers hier auch an Gewährleistungsbürgschaften denken. Mit einer solchen Vereinbarung kommt man den Interessen des Bestellers daran entgegen, dass das Softwareunternehmen Mängelbeseitigungsarbeiten nicht nur erbringen muss, sondern tatsächlich auch erbringt und ggf. ein noch durchsetzbarer Anspruch zur Verfügung steht.

188

Individuell sind Vereinbarungen dieses Inhalts unbegrenzt zulässig1.

189

Auch in AGB lassen sich solche Regelungen treffen. Handelt es sich um AGB des Softwareunternehmers, ist allerdings darauf zu achten, dass ein nennenswerter Teil der Vergütung jedenfalls erst nach Abnahme gezahlt werden muss und ggf. sogar für Mängelansprüche Vorsorge getroffen wird. In AGB des Unternehmens ist die Vereinbarung einer Vorfälligkeit der Zahlung in der Weise, dass schon vor Abnahme alles bezahlt werden muss, unzulässig, weil sie einseitig zu Lasten des Bestellers geht.

190

Soweit Teilzahlungsregelungen getroffen werden, müssen sie klar und deutlich sein. Dies erleichtert die Vertragsabwicklung. In AGB ist dies für den Verwender auch schon deswegen anzuraten, weil diese erfahrungsgemäß oft zu Lasten des Unternehmers ausgelegt werden. So hat ein Gericht schon bei einer vereinbarten Teilfälligkeit bei Installation unterstellt, dass für diese Zahlung auch die Abnahme Voraussetzung war, obwohl eine weitere Teilzahlung erst zu einem deutlich späteren Zeitpunkt, der jedenfalls nach Ab-

1 BGH v. 29.1.2002 – X ZR 231/00, JuR PC Web-Dok. 168/2002.

370

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 195 D

nahme lag, vorgesehen war1. Diese Annahme war aber falsch, weil der Text der AGB eindeutig war. Um solchen Fehlinterpretationen vorzubeugen, sollte man aber Klarheit schaffen, und vorsehen dass eine Vorauszahlung bei Installation und eine weitere, ggf. auch die Restvergütung, erst bei Abnahme fällig ist. Jedenfalls sollte man klarstellen, ob eine Zahlung zum Zeitpunkt der Installation (bzw. der Übergabe der Software) oder zum Zeitpunkt der Abnahme fällig ist. Man kann auch mit Teilabnahmen arbeiten, wie dies jetzt auch im Gesetz 191 vorgesehen ist. Allerdings müsste dann klargestellt werden, dass sich die Teilabnahmen nur auf die jeweils fertiggestellten Teile einer Software beziehen und die Gesamtabnahme nicht ersetzen. Weiterhin ist für eine solche Vereinbarung nötig, dass solche Teilabnahmen überhaupt technisch sinnvoll und auch möglich sind. Soweit der Vertrag kaufvertraglichen Regelungen unterliegt, was auch nach 192 hier vertretener Ansicht ja bei einigen Vertragsmodellen der Fall ist, gelten die oben genannten Ausführen im Prinzip in gleicher Weise. Individuell kann man hier vertraglich vielfältige Regelungen treffen. In AGB dürften hier sogar mehr Regelungen möglich sein als im Bereich 193 des Werkvertrages. Jedenfalls kann das Softwareunternehmen hier die Teilzahlung an die Übergabe knüpfen, weil dies ja der gesetzliche Zeitpunkt der Zahlung ist. Umgekehrt kann der Besteller Regelungen so treffen, dass die Zahlung teilweise zu Beginn, teilweise aber erst nach Ablieferung erfolgen muss. Jedenfalls dann, wenn er auch nicht einen unerheblichen Anteil der Vergütung im Vorhinein zahlt und damit den Interessen des Unternehmers entgegenkommt, kann er zum Ausgleich dafür zur Wahrung seiner Interessen eine weitere Teilzahlung erst an eine Abnahme und damit an eine durch ihn zu erbringende Billigungserklärung hinsichtlich der Software knüpfen. 7. Abnahme a) Abnahmeverfahren Die Abnahme der erstellten Software ist ein zentraler Schritt in der Ver- 194 tragsabwicklung. Dies gilt in der Praxis in allen Projekten auch dann, wenn nach dem Gesetz kaufvertragliche Regelungen Anwendung finden und daher eigentlich gar keine Abnahme vorgesehen ist. Auch dort wird in aller Regel eine Abnahme durchgeführt. Dies alles zeigt, dass eine Abnahme bei Software nicht etwa nach § 646 BGB entbehrlich ist2. Rechtlich ist Abnahme die Billigung der Software durch den Kunden. Sie 195 setzt eine vollständige Lieferung der Software einschließlich aller Dokumentation, ggf. auch die Installation und die Möglichkeit einer Erprobung 1 OLG Düsseldorf v. 27.10.1995 – 22 U 66/95, in: Zahrnt, ECR OLG 208. 2 So schon OLG Hamburg v. 9.8.1985 – 11 U 209/84, CR 1986, 83; heute unstr.

Redeker

371

D Rz. 196

Verträge

voraus1. In aller Regel wird sie daher nicht sofort nach Übergabe bzw. Installation der Software ausgesprochen werden können. Vielmehr wird der Kunde die Software prüfen müssen. Meist geschieht dies in einem mehr oder minder förmlichen Verfahren. 196

In allen größeren Projekten werden solche Abnahmeverfahren vertraglich geregelt und zwar in aller Regel bewusst sowohl durch AGB des Bestellers als auch durch AGB des Unternehmers. Allein diese Tatsache zeigt, dass der Gesetzgeber mit dem Nichtrückverweis auf die Abnahmeregelung im Rahme des § 651 BGB den Interessen der Vertragsparteien nicht gerecht geworden ist. Dies gilt für sämtliche größere Projekte und dabei sicherlich nicht nur für Softwareprojekte, sondern auch etwa für Herstellung von Spezialmaschinen oder anderen größeren beweglichen Gegenständen.

197

Angesichts der Unsicherheit über die anzuwendende Norm ist eine Regelung des Abnahmeverfahrens auch zwingend erforderlich. Ohne solche konkreten Regelungen wird niemand vorhersehen können, ob nach dem Gesetz nun eine Abnahme erforderlich ist oder nicht und in welcher Art und Weise sie denn erfolgen muss. Im Rahmen der Regelung sollte im Detail festgelegt werden, wer abnimmt, wie die Abnahme durchzuführen ist und welche Kriterien Voraussetzungen für eine erfolgreiche Abnahme sind. All diese Regelungen sind von zentraler Bedeutung2.

198

Nach dem Gesetz muss bei Werkverträgen der Kunde abnehmen. Die Erklärung muss daher auf jeden Fall von ihm ausgehen. Es ist allerdings die Frage, ob die der Abnahme vorausgehende Funktionsprüfung von den Parteien gemeinsam vorgenommen oder nur vom Kunden durchgeführt wird. Der Softwareersteller wird eine interne Funktionsprüfung vernünftigerweise schon vor Anzeige der Fertigstellung der Software durchführen. Dies ist aber nur eine interne Prüfung ohne rechtliche Relevanz. Praktisch ist es oft sinnvoll, nach Fertigstellung und Übergabe sowie Installation der Software die Funktionsprüfung gemeinsam durchzuführen, damit auftretende Probleme und Mängel sofort bearbeitet und Unklarheiten sofort aufgeklärt werden können.

199

Dies können die Parteien, je nach Interessenlage, Marktstärke u.Ä. unterschiedlich vereinbaren. Die Entscheidung, ob die Abnahme durchgeführt wird oder nicht, liegt letztendlich beim Kunden. Man kann allerdings auch hier vorsehen, dass ein gemeinsames Abnahmeprotokoll aufgestellt und dann abgezeichnet wird. Diese gemeinsamen Protokolle haben den Vorteil, dass sie größere Klarheit über das, was vereinbart ist, schaffen können. Jedenfalls ist es für alle Parteien nicht ganz einfach, zum Inhalt solcher klaren Protokolle Abweichendes nachträglich zu behaupten oder vorzutragen.

1 Marly, Praxishandbuch Softwarerecht, Rz. 1345. 2 Zu solchen Regelungen vgl. Bartsch, CR 2006, 7; Bischof/Witzel, ITRB 2006, 95; Witzel, ITRB 2008, 160.

372

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 204 D

Neben der Frage, wer die Abnahme erklären soll, ist wichtig, zu regeln, wie 200 sie durchgeführt wird. Jedenfalls bei größeren Projekten wird eine umfangreiche Prüfung auch vom Kunden in aller Regel zunächst in einem Probebetrieb vorgenommen und erst danach der Produktivbetrieb begonnen. Es macht durchaus Sinn, hier auch zwei verschiedene Abnahmeverfahren durchzuführen, wobei klargestellt werden muss, dass die rechtlich relevante Abnahme diejenige ist, die nach Installation und entsprechenden Erfahrungen im Realbetrieb erklärt wird. Immerhin soll die Software real mit den realen Datenmengen in der realen 201 Systemumgebung die Leistung erbringen können. Aus Sicht des Softwareunternehmers kann es allerdings auch sinnvoll sein, die Abnahme nach dem Probebetrieb für rechtlich relevant zu erklären, weil nur im Probebetrieb einigermaßen sichergestellt werden kann, dass irgendwelche auftretenden Probleme nicht von der Überlastung des Gesamtsystems abhängt, die die gelieferte Software nicht beeinflusst hat und für die der Unternehmer auch nichts kann. Dennoch ist bei einem normal vorbereitenden Projekt ja vorher immer überlegt worden, in welcher Umgebung die Software läuft. Sie muss dann zur Abnahme auch unter diesem System lauffähig sein. Ferner muss geklärt werden, welche Probeläufe in welcher Art und Weise 202 und in welchem Umfang durchgeführt werden müssen, bevor die Abnahme erklärt werden muss. Diese Art und Weise der verschiedenen Verfahren schafft zwischen den Parteien Klarheit und ist auch für die internen Tests des Unternehmens wichtig. Wird nichts vereinbart, steht es im Belieben des Bestellers, einen möglichen 203 Test mit der Software durchzuführen. Getestet werden darf allerdings nur das, was vertraglich geleistet werden soll. Der Umfang dessen ist allerdings meist so groß, dass auch in einem sehr umfangreichen Abnahmeverfahren nicht alles getestet werden kann. Die Auswahl, die dann getestet wird, ist Sache des Unternehmens. Dieses kann sehr umfangreich testen, so dass sich das Abnahmeverfahren sehr lange hinzieht. Es kann auch sehr oberflächlich testen, so dass die Abnahme schneller erklärt wird, letztendlich dann aber möglicherweise spätere Mängelrügen in größerem Umfang erhoben werden, weil sich viele Mängel erst weit später herausstellen. Um beide Risiken zu vermeiden, sollte versucht werden, den Umfang der Tests vorher festzulegen. Ein dritter wesentlicher Punkt ist die Festlegung der Abnahmekriterien1. 204 Das Gesetz sieht vor, dass die Abnahme immer erklärt werden muss, wenn das Werk keine wesentlichen Mängel vorsieht. Auch hier kann man versuchen, durch Vereinbarungen im Detail festzulegen, was denn als wesentlicher Mangel gilt und was nicht. Auch dies führt zu mehr Klarheit zwi1 Dazu Conrad/Schneider, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 8 Rz. 93.

Redeker

373

D Rz. 205

Verträge

schen den Parteien. Wird dies nicht vereinbart, liegt es in der Hand des Bestellers, festzulegen, was aus seiner Sicht wesentlich oder unwesentlich ist. Ob seine Bewertung richtig ist oder nicht, wird im Streitfall gerichtlicher Nachprüfung unterliegen. Auch hier dient es sicherlich der Befriedung und der vernünftigen Abwicklung des Projekts, solche Kriterien im Vorhinein festzulegen. In aller Regel wird sich anbieten, diese Definition möglicherweise schon am Anfang in groben Zügen festzulegen und sie im Laufe der Projektentwicklung auch noch zu präzisieren. Die Festlegung konkreter Abnahmekriterien beugt auch Versuchen vor, das Scheitern eines ungeliebten Projekts mit Hilfe für das Projekt nicht so wichtiger, dennoch aber nicht unwesentlicher Probleme herbeizuführen. 205

Im Individualvertrag sind all diese Regelungen möglich. In AGB gibt es Einschränkungen. Kein Unternehmer wird in seinen AGB festlegen können, dass eine Abnahmeprüfung von beiden Parteien gemeinschaftlich erfolgt und gemeinschaftliche Erklärungen dazu abgegeben werden. Schon gar nicht wird er die Abnahmekriterien in AGB festlegen können, soweit dadurch Einschränkungen in der Freiheit der Bewertung für den Besteller festgelegt werden. Rein praktisch empfiehlt sich so etwas auch nicht, weil generelle Regeln, wie ein Abnahmeverfahren durchzuführen ist und welche Mängel denn nun wesentlich und welche unwesentlich sind, gar nicht aufgestellt werden können. Eine Vereinbarung, dass die Abnahme bei nicht wesentlichen Mängeln nicht verweigert werden darf, kann in AGB aufgenommen werden, da sie der gesetzlichen Regelung des Werkvertragsrechts entspricht.

206

Abschließend sei noch bemerkt, dass der Unternehmer in seinen AGB die Abnahme nicht so regeln kann, der Kunde diese schon bei bloßer Entgegennahme der Software ohne jede Prüfmöglichkeit erklären soll. Solche Erklärungen stellen keine Abnahme dar1. b) Stillschweigende Abnahme

207

Trotz aller häufig vorhandenen Vereinbarungen über die Notwendigkeit einer Abnahme und Details ihrer Durchführung und trotz der Tatsache, dass es sich bei Softwareprojekten um die Erstellung relativ komplexer Produkte handelt, taucht in der Praxis immer wieder das Problem auf, dass entweder kein Abnahmeverfahren vereinbart wird oder das vereinbarte Abnahmeverfahren von den Parteien nicht eingehalten wird. Die Software wird irgendwann in irgendeiner Weise in Betrieb genommen. Mängelrügen gibt es dennoch immer wieder. Die Vergütung wird dann auch irgendwann ganz oder teilweise gezahlt und später gibt es dann weitergehende Mängelrügen. Irgendwann beruft sich das Unternehmen dann auf Verjährung der Mängelansprüche oder verlangt den letzten Rest des Erwerbspreises.

1 Junker/Benecke, Computerrecht, Rz. 233.

374

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 211 D

Es stellt sich dann die Frage, ob durch das Verhalten der Parteien die Soft- 208 ware konkludent abgenommen worden ist. Ob und wann dieser Fall bei erstellter Software vorliegt, ist im Einzelnen umstritten. Grundsätzlich bedeutet Abnahme die körperliche Hinnahme des Werkes in Verbindung mit der Erklärung des Bestellers, dass er das Werk als im Wesentlichen vertragsgemäß anerkennt. Die bloße Installation der Software ist daher keine Abnahme und kann diese auch nicht ersetzen1. Betrachtet man diese Definition genau, setzt eine stillschweigende Abnah- 209 me zunächst voraus, dass die beauftragte Leistung zumindest in vollem Umfang erbracht worden ist. Dazu kann je nach Vereinbarung auch die Installation gehören. Jedenfalls gehört dazu auch die Fertigstellung und Übergabe des Benutzerhandbuchs2. Vor Übergabe des Benutzerhandbuchs und ggf. Installation kann die Software ja gar nicht vernünftig geprüft werden. Ferner muss der Kunde natürlich eine gewisse Zeit haben, um die Software auf Ordnungsgemäßheit zu prüfen. Hat der Kunde die Installation übernommen, muss er ferner auch Gelegenheit gehabt haben, die Installation tatsächlich durchzuführen. Wird dann allerdings die Software nach Übergabe des Benutzerhandbuchs und entsprechenden Testläufen in den Produktivbetrieb übernommen und wird gar die gesamte Vergütung oder ein Großteil gezahlt, wird man nach einigen Wochen, spätestens nach einigen Monaten von einer stillschweigenden Abnahme der Software ausgehen müssen3. Wann dieser Zeitpunkt im Einzelnen vorliegt, wird immer den Umständen des Einzelfalls abhängen. Die bloße Zahlung der vollständigen Vergütung ohne sonstige Hinweise wird nicht immer eine Abnahme darstellen4. Ferner wird man eine Abnahme unterstellen können und müssen, wenn die 210 Installation Aufgabe des Bestellers ist und dieser die Software einfach nicht installiert, sondern in den Schrank legt, weil möglicherweise zwischenzeitlich im Unternehmen andere Dispositionen für die Softwareverwendung getroffen wurden. Der Kunde kann sich der Abnahmewirkung nicht dadurch entziehen, dass er die Software einfach nicht testet. Die Rechtsprechung hat immer wieder so formuliert, dass eine konkludente 211 Abnahme erst dann anzunehmen ist, wenn die Software nach einer gewissen Nutzungs- und Erprobungszeit mängelfrei gelaufen ist5. 1 LG München I v. 27.10.1986 – 7 O 1314/85, CR 1986, 803. 2 BGH v. 3.11.1992 – X ZR 83/90, CR 1993, 352 = MDR 1993, 421 = NJW 1993, 1063; OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95. 3 Junker/Benecke, Computerrecht, Rz. 231; OLG München v. 24.1.1990 – 27 U 901/88, NJW 1991, 2158. 4 BGH v. 11.11.2008 – VIII ZR 265/07, NJW 2009, 580. 5 Zur Formulierung vgl. Schneider, Handbuch des EDV-Rechts, H Rz. 220 f. unter Berufung auf OLG Hamburg v. 9.8.1985 – 11 U 209/84, CR 1986, 83; ebenso OLG Düsseldorf v. 7.12.1988 – 17 U 27/87, CR 1989, 689 (690); OLG Hamm v. 8.3.1989 – 31 U 12/88, CR 1989, 1091 = NJW 1990, 1609 f.; OLG Köln v. 11.6.1999 – 19 U 7/99, CR 1999, 747; LG Aachen v. 29.9.1992 – 41 O 69/92, CR 1993, 767.

Redeker

375

D Rz. 212

Verträge

212

Ein Großteil der Rechtsprechung ist allerdings noch zu Zeiten ergangen, wo das Gesetz noch die Abnahmeverweigerung auch bei unwesentlichen Mängeln jedenfalls nicht ausdrücklich ausgeschlossen hat. Angesichts der heute klaren Formulierungen, dass eine Abnahme auch ausgesprochen werden muss, wenn lediglich unwesentliche Mängel vorliegen, wird man eine lange Nutzungs- und Erprobungszeit in diesem Umfang heute nicht mehr verlangen können. Die Software muss dann abgenommen werden, wenn sie als vertragsgemäß gelten kann und zwar auch dann, wenn möglicherweise noch Mängel, jedoch nicht wesentliche Mängel vorliegen1. Im Übrigen wird man auch dann von einer Abnahme ausgehen müssen, wenn die Software trotz Mängelrügen über längere Zeit (z.B. ein Jahr) produktiv eingesetzt, der Kaufpreis bezahlt und Änderungen in Auftrag gegeben worden sind2. Viel hängt hier von den Umständen des Einzelfalls ab, die auch viele in den Formulierungen etwas widersprüchliche Entscheidungen in der Rechtsprechung bei genauerem Lesen als gar nicht so widersprüchlich erkennen lassen.

213

Angesichts der weitreichenden Wirkung der Abnahme ist aber verständlich, dass eine stillschweigende Abnahme erst bei Vorliegen klarer Hinweise des Einverständnisses seitens des Kunden angenommen werden kann.

214

Liegt in der konkludenten Abnahme zugleich auch der Verzicht auf eine vertraglich vereinbarte förmliche Abnahme, so ist dies zwar möglich. Man muss aber in diesem Fall strenge Anforderungen an die Annahme einer konkludenten Abnahme stellen. Ein solcher Verzicht kann vor allem nicht vermutet werden3. Nur bei klaren Indizien wird man hier von einer konkludenten Abnahme ausgehen können. c) Fiktion einer Abnahme

215

Soweit gesetzliche Regelungen gelten, kann die Abnahme auch fiktiv erfolgen. Dies ergibt sich aus § 640 Abs. 1 Satz 3 BGB. Ist die Software im Wesentlichen vertragsgemäß, kann der Unternehmer vom Kunden die Abnahmeerklärung verlangen. Weist der Kunde dann das Begehren nicht sachlich begründet zurück, gilt die Abnahme als erteilt. Auf diesem Wege kann auch ein Stillschweigen letztendlich in eine Abnahme umgedeutet werden. Voraussetzung ist aber, dass die Software abnahmefähig ist, also im Wesentlichen vertragsgemäß erstellt wurde.

1 Für fehlende Restarbeiten so schon BGH v. 3.11.1992 – X ZR 83/90, CR 1993, 352 = MDR 1993, 421 = NJW 1993, 1063. 2 OLG München v. 24.1.1990 – 27 U 901/88, CR 1991, 19 = VR 1991, 9 = NJW 1991, 2158; OLG Karlsruhe Beil. 9 zu BB 1996, S. 5; wohl a.A. OLG Düsseldorf v. 7.12.1988 – 17 U 27/87, CR 1989, 689. 3 BGH v. 3.11.1992 – X ZR 83/90, CR 1993, 352 = MDR 1993, 421 = NJW 1993, 1063.

376

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 219 D

Eine entsprechende Regelung sollte man jedenfalls als Unternehmer dann 216 in AGB bei Abnahme aufnehmen, wenn die Abnahme Voraussetzung für nicht unwesentliche Zahlungen ist. Diese Regelung findet sich auch sonst in den Regelungen über AGB. Es kann allerdings auch ein Hinweis auf die gesetzliche Regelung erfolgen. AGB-rechtlich ist dann noch die Frage interessant, ob man die gesetzliche Regelung tatsächlich so in AGB übernehmen kann. Immerhin ist in Regelungen über AGB gemäß § 308 Nr. 5 BGB eine Fiktion nur dann wirksam, wenn dem Kunden eine ausreichende Frist zur Abgabe der Erklärung gewährt und zusätzlich der AGB-Verwender bei Beginn der Frist auf die fehlende Frist ausdrücklich hinweist. Angesichts der abweichenden Regelung in § 640 Abs. 1 Satz 3 BGB dürfte dies Abnahmefiktionen so nicht mehr gelten und zwar auch nicht im nichtunternehmerischen Verkehr. d) Wirksamkeit von Abnahmeklauseln Abnahmeklauseln gab und gibt es im großen Umfang in den Verträgen über 217 die Lieferung sowohl von Standardsoftware als auch über die Erstellung von Software. Sie sind in der Vergangenheit auch für den Kauf von Standardsoftware als wirksam angesehen worden1. Als AGB unwirksam sind allerdings Klauseln, die Abnahmefiktionen festlegen, die zugunsten des jeweiligen Verwenders deutlich von der gesetzlichen Regelung abweichen, also etwa auf Kundenseite eine Abnahme erst nach einem längeren Probelauf und einem Produktivbetrieb ohne Beanstandung binnen einer bestimmten Zeit zulassen oder auf Lieferantenseite die Abnahme durch eine Formbestätigung bei Ablieferung vorsehen. Solche Klauseln weichen jeweils zugunsten des jeweiligen Verwenders so stark von der gesetzlichen Regelung ab, dass sie wegen § 307 Abs. 2 Nr. 1 BGB nicht wirksam sind. Problematisch ist im neuen Recht auch die Wirksamkeit von Abnahme- 218 klauseln, die in Verträgen, die § 651 BGB unterliegen, eine Abnahme anordnen. Abnahmeklauseln, die lediglich eine Abnahme vorsehen, daran aber keine 219 weitergehenden Konsequenzen knüpfen, sind jederzeit zulässig. Es liegt im Interesse beider Parteien, eine Abnahme des Produkts vorzusehen, weil die Komplexität des hier fraglichen Produktes es gebietet, durch Nachprüfen der gelieferten Software festzustellen, ob sie den vom Besteller verlangten Bedingungen im Wesentlichen genügt. Fraglich sind solche Klauseln dann, wenn an die Abnahme die im Werkvertragsrecht an die Abnahme geknüpften Konsequenzen angebunden sind. Im Wesentlichen geht es dabei um die Fälligkeit und die Verjährung. Nach Werkvertragsrecht wird erst nach Abnahme die Vergütung fällig, während dies im Kaufrecht schon deutlich früher (i.d.R. Zug um Zug mit der Ablieferung) der Fall ist. Hier kann selbstverständlich der Unternehmer vorsehen, dass die Fälligkeit der Vergütung 1 Z.B. LG Aachen v. 29.9.1992 – 41 O 69/92, CR 1993, 767.

Redeker

377

D Rz. 220

Verträge

erst bei Abnahme eintritt. Er schiebt damit die Fälligkeit zu seinen Lasten hinaus. Ein Besteller kann dies in AGB so generell nicht, weil er sonst die Fälligkeit der Vergütung an eine von ihm selbst durch Erklärung gesetzte Fristsetzung knüpft. Allerdings dürfte es möglich sein, Klauseln einzufügen, bei denen ein Teil der Vergütung im Gegensatz zur gesetzlichen Regelung schon vor Abnahme, nämlich zu Beginn des Projekts, bei einzelnen Projektfortschritten gezahlt wird, eine weitere Teilzahlung aber an die Abnahme geknüpft wird (vgl. Rz. 189 ff.). 220

Was die Verjährung betrifft, so kann wiederum der Unternehmer den Verjährungsbeginn jederzeit auf die Abnahme verlegen. Damit wird die Verjährung zu seinen Lasten verlängert, da ja dann, wenn keine Abnahme erforderlich und Kaufvertragsrecht anwendbar ist, die Verjährung von Gewährleistungsansprüchen bereits mit der Ablieferung beginnt. Aus eben diesem Grunde kann der Kunde in seinen AGB möglicherweise die Abnahme nicht mit der Folge verbinden, dass die Verjährung erst bei Abnahme und nicht bei Ablieferung beginnt. In diesem Fall wird ja die Verjährungsfrist unbestimmt verlängert. Vergleichbare Klauseln hat der BGH im Bereich der Subunternehmerverträge häufig für unwirksam erklärt1. Wer hier sicher gehen will, wird solche Klauseln in AGB unterlassen und schlichtweg nur eine Abnahme regeln. Enthalten die AGB dann Verjährungsvorschriften, müssen diese für den Beginn der Verjährungsfrist zur Vermeidung von Missverständnissen ausdrücklich regeln, dass die Frist mit dem gesetzlichen Verjährungsbeginn anfängt. Stellt man in solchen Klauseln nämlich zur Klarstellung auf die Ablieferung als Verjährungsbeginn ab, ist der Verwender an diesen Verjährungsbeginn auch dann gebunden, wenn die Auslegung des konkreten Vertrags dazu führt, dass es sich um einen Werkvertrag handelt und daher die Verjährungsfrist erst mit Abnahme beginnt. Da der Kunde im Übrigen durch die gesetzlichen Regeln ohnehin gut gestellt ist, sollte er auf Verjährungsregeln, die Mangelansprüche betreffen, am besten gänzlich verzichten.

221

Will der Besteller jedoch den Beginn der Verjährung der Gewährleistungsansprüche doch an die Abnahme knüpfen, so muss er auf jeden Fall hier auch die Regelung des § 640 BGB aufnehmen. In diesem Bereich empfiehlt es sich aber in der Tat, auf diese Klausel zu verzichten, um die sehr wichtige Abnahmeklausel, die ganz unabhängig von Verjährungsfragen hinsichtlich vieler Mängel Klarheit für beide Seiten und damit auch für den Besteller schafft, rechtswirksam zu halten.

222

In der Literatur wird häufig empfohlen, statt einer Abnahme eine Funktionsprüfung oder etwas Ähnliches zu regeln, um die oben geschilderten Probleme der Wirksamkeit von Abnahmeklauseln zu umgehen. Eine solche Umbenennung führt aber nicht weiter. Allenfalls kann dadurch erreicht werden, dass bei unklarer Regelung davon ausgegangen werden muss, dass 1 BGH v. 23.2.1989 – VII ZR 89/87, BGHZ 107, 75 = MDR 1989, 627; BGH v. 10.10.1996 – VII ZR 224/95, MDR 1997, 238 = BB 1997, 176.

378

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 225 D

die Funktionsprüfung die Wirkung einer Abnahme hat, während dann, wenn man undifferenziert von Abnahme spricht, und nicht regelt, dass Verjährung und Fälligkeit davon nicht beeinflusst werden, man an die Abnahme die gesetzlichen Funktionen im Werkvertragsrecht knüpft. Hier sollten aber klare vertragliche Regelungen, die Verjährung und Fälligkeit betreffen, vorbeugen. Die bloße Umbenennung der Abnahme in Funktionsprüfung ändert ansonsten am Inhalt einer Klausel nichts. 8. Mitwirkung des Bestellers a) Umfang der Mitwirkungshandlungen Bei jedem größeren Softwareprojekt muss nicht nur der Unternehmer han- 223 deln, der Besteller muss ebenfalls zum Erfolg beitragen. Das kann sogar so weit gehen, dass der Erfolg eines Softwareprojekts von einer Organisationsänderung des Kunden abhängt1. Deswegen sieht jeder Vertrag über die Softwareerstellung auch vor, dass der Besteller Mitwirkungshandlungen erbringen muss. Meist werden auch viele Einzelheiten im Vertrag geregelt. Zu den Mitwirkungshandlungen gehört es, dass der Besteller Informationen 224 erteilt. Dazu gehören insbesondere Informationen über die eigene Betriebsorganisation, die für die Erstellung des Programms erforderlich sind. Dazu können auch Informationen über die Systemumgebung, über geplante Weiterentwicklungen, über gesetzgeberische Vorgaben, über Betriebsvereinbarungen, die Auswirkungen auf die Gestaltung des Programms haben usw. gehören. Diese Informationen müssen zum Teil vom Besteller eigenverantwortlich und aus eigener Initiative erteilt werden2. Der Unternehmer muss aber diese Informationen ggf. auch beim Besteller abfragen. Es kann durchaus sein, dass der Besteller gar nicht genau weiß, was der Softwareersteller an Informationen für die Erstellung des Programms braucht. In diesem Fall muss dann der Softwareersteller seinen Kunden genau befragen, um die für ihn notwendigen Informationen zu erhalten. Dazu kann auch die Ausarbeitung umfangreicher Fragebogen gehören. Es empfiehlt sich aber, über diese Fragebogen hinaus auch durch Gespräche und im Dialog die Informationen gemeinsam zu erarbeiten. Hält der Softwareersteller die vom Kunden gegebenen Informationen für unzulänglich, muss er ebenfalls nachfragen3. All diese Informationen müssen vom Besteller notwendigerweise erteilt 225 werden. Dies liegt im eigenen Interesse des Bestellers, weil nur so gesichert werden kann, dass das Projekt auch erfolgreich ist. Auch der Softwareersteller benötigt natürlich die Informationen, um die Software im geschuldeten Umfang und dem geschuldeten Inhalt zu erstellen. Diese Informationen müssen auch ohne ausdrückliche vertragliche Verinbarung erteilt werden. 1 Schneider, ITRB 2008, 261. 2 Müglich/Lapp, CR 2004, 801 (804). 3 Marly, Praxishandbuch Softwarerecht, Rz. 1305; Junker/Benecke, Computerrecht, Rz. 223.

Redeker

379

D Rz. 226

Verträge

226

Neben den geschilderten Informationspflichten gibt es u.U. auch die Notwendigkeit, dem Ersteller Arbeitsräume und/oder Systeme zur Verfügung zu stellen, damit dieser das von ihm erstellte Produkt auch austesten kann1. Ob und in welchem Umfang dies alles erforderlich ist, ist allerdings sehr projektabhängig. Es kann durchaus Fälle geben, in denen sich weder das eine noch das andere als notwendig erweist.

227

Hier werden vertragliche Regelungen notwendig. Inwieweit ohne konkrete Vereinbarungen der Besteller solche Leistungen zur Verfügung stellen muss, ist darüber hinaus weit fraglicher als dies bei der Bereitstellung notwendiger Informationen der Fall ist. Wenn klar ist, dass ein Teil der Arbeiten im Hause des Bestellers erfolgen muss, muss er sicher Arbeitsräume zur Verfügung stellen. Soll die Software beim Besteller installiert werden, muss er natürlich auch dafür die notwendigen Räumlichkeiten und insbesondere den Zugang zu seinem System gewähren. Über solche Selbstverständlichkeiten hinaus dürfte die Annahme von rechtlichen Verpflichtungen zur Bereitstellung von Räumen, Personal oder Systemen ohne konkrete Vereinbarung in aller Regel nicht bestehen2.

228

Details der notwendigen Mitwirkungshandlungen des Bestellers sollten im konkreten Vertrag geregelt werden. Dabei empfehlen sich projektbezogene individuelle Vereinbarungen, weil nur so konkret geregelt werden kann, was im jeweiligen Projekt notwendig und für den Besteller auch möglich ist3. Solche Präzisierungen sind auch für die Aufwandskalkulation beider Parteien von zentraler Bedeutung. Notwendige Unterstützungsleistungen des Auftraggebers können nach Untersuchungen in komplexen Projekten den Umfang von 30–50 % des Auftragsumfangs erreichen4. Bei den dabei erreichten finanziellen Dimensionen ist die Verteilung der Mitwirkungshandlungen für den Projektverlauf sehr wichtig.

229

Das Softwareunternehmen sollte im Rahmen der hier angesprochenen Regelungen zwar das Notwendige verlangen, aber seine Mitwirkungsforderungen auch nicht überziehen. Insbesondere muss es darauf achten, was dem Kunden im Rahmen von dessen Kenntnissen und Fähigkeiten überhaupt zugemutet werden kann. Wird diese Grenze überschritten, kann dies sogar bei individuellen Vereinbarungen zur Unwirksamkeit wegen Sittenwidrigkeit führen. Jedenfalls wird aber der Projekterfolg gefährdet, wenn einer der Vertragspartner Leistungen erbringen soll, die er nicht erbringen kann5.

230

Bei größeren Projekten sind ferner Verfahrensregelungen sinnvoll. Dabei geht es insbesondere darum, festzuhalten, welche Mitwirkungshandlungen von wem bei wem angefordert werden müssen und welche evtl. auch ohne Aufforderungen erbracht werden müssen. Je nach Umfang werden auch 1 2 3 4 5

Müglich/Lapp, CR 2004, 801 (805). Zu weit Marly, Praxishandbuch Softwarerecht, Rz. 1216. Näher Witzel/Stern, ITRB 2007, 107. Müglich/Lapp, CR 2004, 801 (804). Zum Ganzen Müglich/Lapp, CR 2004, 801 (803).

380

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 232 D

Fristen zu regeln sein, binnen derer Mitwirkungshandlungen nach entsprechender Anforderung zu erbringen sind. Die Mitarbeiter, die der Besteller zur Erfüllung seiner Mitwirkungspflichten einsetzt, müssen ja vorübergehend ganz oder teilweise von ihren eigentlichen Aufgaben freigestellt werden. Dies erfordert zum einen, dass die Anforderungen in aller Regel über die Projektleiter beider Seiten erfolgt, und zum anderen, dass die Anforderungen so rechtzeitig erfolgt, dass der Besteller seinerseits entsprechende Dispositionen bzgl. seiner Mitarbeiter treffen und diese in notwendigem Umfang freistellen kann1. Häufig werden Mitwirkungshandlungen des Kunden auch in AGB der Soft- 231 wareunternehmen konkretisiert. Wenn man dabei über die eingangs geschilderten Informationspflichten hinausgeht, dürften die Klauseln relativ schnell an § 307 Abs. 2 BGB scheitern. Die Übertragung zusätzlicher Leistung an den Vertragspartner ist oft mit den Grundgedanken der gesetzlichen Regelung nicht vereinbar (§ 307 Abs. 2 Nr. 1 BGB). Darüber hinaus wird in vielen Fällen das Pflichtenprogramm des Vertrages verändert mit der Konsequenz, dass wesentliche Rechte des Kunden oder wesentliche Pflichten des Softwareunternehmens eingeschränkt werden (§ 307 Abs. 2 Nr. 2 BGB). Das Softwareunternehmen muss bei der Formulierung solcher Klauseln auch deswegen vorsichtig sein, weil auf die Kenntnisse und Fähigkeiten aller Kunden, auch der von Kleinunternehmen und Privatkunden, Rücksicht zu nehmen ist. Schon wenn solche Kunden überfordert werden, dürften entsprechende Klauseln unwirksam sein. Darüber hinaus droht bei zu weitgehender Pflichtüberwälzung auch die Gefahr, dass eine entsprechende Klausel in AGB als überraschend i.S.d. § 305c Abs. 1 BGB gewertet wird2. Demgemäß dürfte es schon fraglich sein, ob in AGB die Regelung enthalten sein darf, dass der Kunde eine auch EDV-technisch sachkundige Person als Ansprechpartner zur Verfügung stellen muss (vgl. Rz. 472). Schließlich lassen sich in AGB die Pflichten auch nicht auf das konkrete Projekt feinsteuern, sondern müssen im Globalen bleiben. Alles in allem sind AGB für die Konstituierung von Mitwirkungsnotwendigkeiten von Kunden nur wenig geeignet. b) Gesetzliche Regelung Ist im Vertrag nichts näher geregelt, erbeben sich die oben genannten 232 Mitwirkungsverpflichtungen aus §§ 642 ff. BGB. Diese Vorschriften gelten auch dann, wenn auf den Werkvertrag im Prinzip Kaufrecht Anwendung findet. Dies ist im Gesetz in § 651 Satz 2 BGB für die Herstellung unvertretbarer Sachen ausdrücklich vorgesehen. Die Herstellung individueller Software ist – wenn § 651 BGB überhaupt Anwendung findet – die Herstellung einer unvertretbaren Sache.

1 Zum Ganzen Müglich/Lapp, CR 2004, 801 (805). 2 Roth, ITRB 2001, 194 (197).

Redeker

381

D Rz. 233

Verträge

233

Nach dem Gesetz handelt es sich allerdings nicht um Pflichten, sondern ausschließlich um Obliegenheiten1. Dies bedeutet, dass der Unternehmer nicht etwa die Erfüllung der Information des Bestellers einklagen und bei Unterlassung Schadensersatz verlangen kann. Fehlen allerdings die erforderlichen Mitwirkungshandlungen, kommt der Besteller in Annahmeverzug (§ 295 Satz 2 BGB) mit den sich daraus ergebenden Konsequenzen2. So reduziert sich insbesondere die Haftung des Unternehmers auf grobe Fahrlässigkeit. Der Unternehmer kommt auch nicht in Verzug, wenn der Kunde die erforderlichen Mitwirkungshandlungen nicht erbringt3. Ferner kann der Unternehmer den Kunden auf Zahlung seiner Vergütung Zug um Zug gegen Erbringung der Werkleistung (§ 322 Abs. 1 BGB) bzw. auf Zahlung nach Empfang der Gegenleistung (§ 322 Abs. 2 BGB) verklagen. Wird gleichzeitig der Annahmeverzug des Kunden im Urteil festgestellt, kann dieses Urteil ohne Erbringung der Gegenleistung vollstreckt werden (§§ 274 Abs. 2 BGB, 756 ZPO).

234

Außerdem kann der Unternehmer dann, wenn die erforderlichen Mitwirkungshandlungen trotz entsprechender Aufforderung nicht erbracht werden, nach § 642 BGB eine angemessene Entschädigung verlangen und nach einer Fristsetzung gem. § 643 BGB auch vom Vertrag zurücktreten4. Die Entschädigung nach § 642 BGB soll die dem Unternehmer durch die Verzögerung entstehenden Belastungen auffangen. Kann Personal und Material zeitweise nicht eingesetzt werden, muss der Besteller dem Unternehmer die dafür entstehenden Selbstkosten ersetzen5. Tritt der Unternehmer vom Vertrag zurück, erhält er die Vergütung für die bis zur Kündigung durchgeführten Arbeiten und Aufwendungsersatz für in dieser Vergütung nicht enthaltene Aufwendungen (§ 645 Abs. 1 BGB) – anders als im Falle des § 649 BGB also nicht die volle Vergütung abzüglich ersparter Aufwendungen6. Es gibt sogar Situationen, wo nach der Rechtsprechung der volle Werklohn ohne Zug-um-Zug-Titel vom Unternehmer gefordert werden kann, obwohl die Software noch nicht fertiggestellt ist7. Zu beachten ist aber, dass bei einer 1 Müglich/Lapp, CR 2004, 801 f.; Ihde, CR 1999, 409 (413); Marly, Praxishandbuch Softwarerecht, Rz. 1350; Schneider, Handbuch des EDV-Rechts, D Rz. 407. 2 BGH v. 28.6.1994 – X ZR 95/92, CR 1995, 265 (266); Junker/Benecke, Computerrecht, Rz. 218; Ihde, CR 1999, 409 (413); zum Ganzen auch Redeker, ITRB 2011, 656. 3 OLG Stuttgart CR 1994, 222 (LS); Marly, Praxishandbuch Softwarerecht, Rz. 1339. 4 Junker/Benecke, Computerrecht, Rz. 219; Schneider, Handbuch des EDV-Rechts D Rz. 411; Ihde, CR 1999, 409 (413); Roth, ITRB 2001, 194 f. 5 BGH v. 21.10.1999 – VII ZR 185/98. BGHZ 143, 32 (40); a.A.: volle Vergütung für diese Zeit zusätzlich: Staudinger/Peters/Jacoby, § 642 Rz. 25. 6 Palandt/Sprau, § 643 Rz. 2; a.A. Staudinger/Peters/Jacoby, § 643 Rz. 19: volle Vergütung abzgl. ersparter Aufwendungen. 7 BGH v. 15.5.1990 – X ZR 128/88, CR 1991, 86 m. Anm. Brandi-Dohrn = NJW 1990, 3008; OLG Köln v. 9.8.1995 – 19 U 69/95, CR 1996, 25 = NJW-RR 1996, 624; Junker/Benecke, Computerrecht, Rz. 219.

382

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 238 D

Kündigung des Vertrags seitens des Bestellers der Unternehmer nicht den vollen Werklohn fordern kann, sondern er sich ersparte Aufwendungen anrechnen lassen muss (§ 649 BGB). Dies muss sinngemäß auch dann gelten, wenn der Unternehmer wegen mangelnder Mitwirkung des Auftraggebers die Software nicht fertig stellen kann. Das Kündigungsrecht nach § 649 BGB ist durch eine fehlende Mitwirkungshandlung des Unternehmers auch nicht ausgeschlossen. Die oben genannten Konsequenzen ergeben sich freilich nur dann, wenn 235 der Unternehmer – wie oben schon geschildert – den Besteller auch aufgefordert hat, seine Mitwirkungsobliegenheiten zu erfüllen. Insbesondere im Hinblick auf die Informationspflichten muss die Aufforderung so sein, dass der Besteller die Fragen des Unternehmers überhaupt verstehen kann. Der Unternehmen muss die Fragen schon so stellen, dass der Besteller in der Lage ist, sie auch ordentlich zu beantworten. Fragt der Unternehmer unverständlich oder fragt er überhaupt nicht, kann er sich auf die mangelnde Mitwirkung des Bestellers nicht berufen1. Problematisch ist der Fall, dass der Unternehmer sich nach Kräften bemüht, 236 verständlich Fragen zu stellen, dazu aber nicht in der Lage ist und auch der Besteller auf Grund der gestellten Fragen nicht erkennen kann, welche Informationen geliefert werden sollen bzw. was der Unternehmer braucht. In diesem Fall muss rein praktisch ein Sachkundiger sozusagen als „Dolmetscher“ für die Parteien beauftragt werden. Auch auf dieses Problem muss der Unternehmer hinweisen und auf die Bestellung des „Dolmetschers“ hinwirken. In aller Regel hätte dann aber der Unternehmer das Problem schon vor Vertragsschluss sehen müssen, weil die auftretenden Probleme bei vernünftigen Vertragsverhandlungen schon vorher hätten erkennbar sein müssen. Dies mag dann nicht der Fall sein, wenn die Erstellung des Pflichtenhefts auch Teil des Leistungsumfangs des Softwareunternehmens ist. Zu den Fähigkeiten, die ein Unternehmen haben muss, das ein Pflichtenheft erstellt, gehört allerdings auch, dass es in der Lage ist, die normale Sprache der Branche zu verstehen, für die es das Pflichtenheft wie ein Softwareprogramm schreiben muss. c) Pflichten statt Obliegenheiten Die gesetzliche Regelung sieht die Mitwirkungshandlungen des Kunden als Obliegenheiten an2. In der Softwarebranche besteht ein starker Wunsch, sie als Pflichten zu behandeln.

237

Ohne ausdrückliche Vereinbarung dürften allerdings Mitwirkungspflichten 238 nur in ganz seltenen Fällen gegeben sein. Möglich ist dies dann, wenn beide Parteien die Entwicklung in der Individualsoftware als Pilotprojekt für eine mögliche Nutzung des Ergebnisses als Standardsoftware ansehen oder wenn 1 OLG Stuttgart v. 23.8.1994 – 6 U 57/94, Zahrnt, ECR OLG 168. 2 Bamberger/Roth/Voit, § 642 Rz. 6 m.w.N.

Redeker

383

D Rz. 239

Verträge

– auch für den Vertragspartner erkennbar – die Entwicklung der Individualsoftware beim Unternehmer eine große Anzahl von Arbeitskräften bindet, die dieser in anderer Weise nicht einsetzen kann1. Thewalt2 will dies auch annehmen, wenn die fehlende Mitwirkung die Fertigstellung der Software verhindert, weil dann die Hauptpflichten des Kunden (Abnahme und Bezahlung) gefährdet würden. Dies geht aber zu weit, weil dies dem gesetzlichen Modell nicht entspricht. Der Unternehmer ist durch die oben genannten Rechte, insbesondere nach § 322 BGB, ausreichend gesichert. 239

Von diesen seltenen Ausnahmefällen abgesehen, sieht das Gesetz nun einmal Obliegenheiten und keine Pflichten vor. Es ist auch nicht erkennbar, warum dies anders sein soll. Ein Interesse an der Fertigstellung der Software hat nur der Besteller. Das Softwareunternehmer hat ein Interesse daran, für seine Leistungen den Werklohn zu erhalten. Insoweit unterscheidet sich ein Softwareerstellungsvertrag nicht von jedem anderen Werkvertrag. Die gesetzlichen Regelungen sichern nur das Vergütungsinteresse des Softwareunternehmens, das in voller Höhe Vergütung verlangen kann, wenn die Mitwirkungspflichten nicht erfüllt werden und dass darüber hinaus eine Entschädigung verlangen kann, wenn die mangelnde Mitwirkung des Bestellers zu höheren Kosten bei der Softwareerstellung führt. Ein gemeinsames Interesse der Parteien an der Softwareerstellung ist im Prinzip nicht erkennbar. Die Softwareunternehmer betonen zwar dieses gemeinsame Interesse immer wieder. Psychologisch mag dies auch richtig sein, weil jeder Softwareunternehmer auch gerne ein fertiges Werk vorweist. Rechtlich gesprochen ist dies aber nicht so. Ein wirkliches gemeinsames Interesse würde auch die Annahme eines Werkvertrages gefährden. Man käme dann relativ schnell zu einem Gesellschaftsvertrag, bei dem die Erstellung der Software dann der gemeinsame Gesellschaftszweck ist. Dieses Vertragsmodell dürfte aber den wirtschaftlichen Interessen der Parteien in aller Regel nicht entsprechen. Man wird in aller Regel von einem Werkvertrag ausgehen, in dem es Mitwirkungsobliegenheiten der Kunden gibt. Die Annahme von Mitwirkungspflichten scheidet in aller Regel aus.

240

In vielen Softwareverträgen werden – den Wünschen der Branche entsprechend – die Obliegenheiten der Kunden in Pflichten verwandelt. Individualvertraglich ist dies auch unproblematisch möglich, allerdings3 müssen die Pflichten konkretisiert werden. Man muss bei entsprechenden Vereinbarungen nur der Gefahr eines Gesellschaftsvertrages vorbeugen.

241

Geht man allerdings von dem oben dargestellten gesetzgeberischen Leitbild aus, ist die Verwandlung sämtlicher Mitwirkungsobliegenheiten des Kunden in Pflichten durch AGB des Softwareerstellers mit dem gesetzlichen

1 Vgl. auch Roth, ITRB 2001, 194 f. 2 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 217. 3 Roth, ITRB 2001, 194 (197); ein Beispiel bei OLG Köln v. 12.2.1999 – 19 U 119/98, CR 2000, 212; detailliert Witzel/Stern, ITRB 2007, 167 (168).

384

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 246 D

Leitbild des Vertrages nicht vereinbar. Sie ist daher gem. § 307 Abs. 2 Nr. 1 BGB auch im Unternehmensverkehr unwirksam1. Ob die Verwandlung einzelner Mitwirkungsobliegenheiten in Pflichten 242 durch AGB möglich ist, soll nicht ganz ausgeschlossen werden2. Da aber eine Abwägung im Einzelfall vorzunehmen ist, dürfte auch dies in AGB kaum möglich sein. Dies gilt z.B. auch von einer Klausel, in der dem Besteller die Pflicht auferlegt wird, eine sachkundige Betreuung des Projekts zu gewährleisten. Als Konkretisierung einer Obliegenheit mag diese Vereinbarung zulässig sein, soweit die Sachkunde sich auf betriebliche Probleme des Bestellers bezieht. Diese Obliegenheit in eine Vertragspflicht des Kunden zu verwandeln, erscheint überzogen, weil es eine ganze Reihe von Fällen gibt, wo die sachkundige Betreuung zwar im Interesse des Bestellers liegt, die Interessen des Unternehmens aber durch die vorhandene gesetzliche Regelung ausreichend gewahrt sind. Verletzt der Besteller Mitwirkungspflichten, greifen die Vorschriften der 243 §§ 280, 286 BGB (Schuldnerverzug) ein. Der Unternehmer kann sich nach § 323 BGB nach Fristsetzung vom Vertrag lösen, wenn diese Mitwirkungspflichten sich sogar als Pflicht im Gegenseitigkeitsverhältnis darstellen. Im Übrigen bestehen Schadensersatzansprüche. Diese können bei Pflichten im Gegenseitigkeitsverhältnis sogar so weit 244 gehen, dass der Besteller bei zu vertretener Unmöglichkeit der Mitwirkungspflicht vom Vertrag zurücktreten und den vollen Werklohn abzüglich evtl. Ersparnisse im Wege des Schadensersatzes statt der Leistung verlangen kann. Unabhängig davon könnte der Unternehmer den Besteller auf Erfüllung der Pflichten verklagen.

III. Leistungsstörungen 1. Mangelhafte Leistung Die meisten Auseinandersetzungen bei der Durchführung von Softwarever- 245 trägen beruhen darauf, dass die erbrachten Leistungen nach Ansicht des Kunden nicht, nicht ordentlich oder nicht rechtzeitig erbracht worden sind. Die sich daraus ergebenden Probleme werden in der Folge dargestellt. Zunächst geht es um mangelhafte Leistungen. a) Definition des Mangels Der Begriff des Mangels ist in § 633 Abs. 2 bzw. § 434 Abs. 1 Satz 1 BGB nä- 246 her definiert. Das Gesetz formuliert dabei negativ. Nach der gesetzlichen Definition ist das erstellte Werk und somit auch die erstellte Software dann 1 Ebenso i.E. Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 213 f., weil es sich um eine überraschende Klausel handele. 2 Roth, ITRB 2001, 194 (197) ist großzügiger.

Redeker

385

D Rz. 247

Verträge

frei von Sachmängeln, wenn sie eine zwischen den Parteien vereinbarte Beschaffenheit hat. Fehlt es an konkreten Vereinbarungen, so ist das Werk dann frei von Sachmängeln, wenn es sich für die nach dem Vertrag vorausgesetzte, ohne eine solche Voraussetzung für die gewöhnliche Verwendung eignet und eine Beschaffenheit aufweist, die bei Werken der gleichen Art üblich ist und die der Besteller nach Art des Werkes erwarten kann. In aller Kürze kann man sagen, dass ein Mangel dann vorliegt, wenn das Werk, also die Software, negativ von den für sie geltenden Vorgaben abweicht. Mithin ist entscheidend, dass die Ist-Beschaffenheit der Software negativ von ihrer Soll-Beschaffenheit abweicht. 247

Zwischen den Parteien ist dabei in aller Regel nicht nur die Ist-Beschaffenheit, sondern auch die Soll-Beschaffenheit streitig. Voraussetzung dafür, dass überhaupt ein Mangel festgestellt werden kann, ist, dass man eine SollBeschaffenheit feststellen kann. Hier gilt zunächst der Vorrang einer vertraglichen Vereinbarung. An dieser Stelle wird wieder klar, wie wichtig ein Pflichtenheft für die Vertragsabwicklung im Softwarerecht ist1. Nur bei Vorliegen eines Pflichtenheftes wird man in aller Regel relativ leicht feststellen können, welche Soll-Beschaffenheit die Software aufweist. Fehlt es an einem Pflichtenheft, ist zunächst auf sonstige Vertragsunterlagen, Angebote, Anforderungsschreiben der Parteien u.Ä. zu verweisen. Auch frühere Vertragsentwürfe können eine wichtige Rolle spielen2. Erst wenn auch solche Unterlagen fehlen oder unergiebig sind, wird man auf die übliche Verwendung der Software zur Definition ihrer Soll-Beschaffenheit zurückgreifen können. Dies ist insbesondere bei Individualsoftware allerdings oftmals ein schwieriges Problem, insbesondere dann, wenn es sich um eine spezielle Software für spezielle Anforderungen des bestellenden Unternehmens oder für ganz spezielle Probleme handelt und die Mängel gerade in dem Bereich spezieller Anwendungen oder spezieller Anforderungen der Systemumgebung liegen. Die Definition zeigt aber auch deutlich, dass nicht notwendigerweise eine konkrete vertragliche Vereinbarung vorliegen muss, um die Soll-Beschaffenheit feststellen zu können. Man kann auch aus anderen Umständen und generellen Vorgaben auf die Beschaffenheit schließen. Auch die sich daraus ergebenden Anforderungen sind zu erfüllen.

248

Soweit Kaufrecht gilt, können sich im Übrigen Anforderungen auch aus der Leistungsbeschreibung des Herstellers ergeben (§ 433 Abs. Satz 3 BGB). Im Bereich der Individualsoftware spielt dies keine Rolle, weil der Hersteller mit dem Softwareersteller identisch ist. Im reinen Kaufrecht ist dies deswegen wichtig, weil der Hersteller und sonstige dritten Gehilfen andere Personen als der Verkäufer sein können. Wichtig kann diese Frage aber auch dann werden, wenn eine Standardsoftware mit Softwareentwicklungsleistungen kombiniert wird und das gemeinsame Produkt gekauft wird. 1 Marly, Praxishandbuch Softwarerecht, Rz. 1370; Junker/Benecke, Computerrecht, Rz. 261. 2 OLG Köln v. 20.5.1996 – 19 U 204/95, CR 1996, 536.

386

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 253 D

In diesem Falle gilt ja für den Gesamtvertrag, jedenfalls hinsichtlich der 249 Mängelregeln, Kaufrecht. Für die sich für die mitüberlassene Standardsoftware erforderlichen Eigenschaften können daher auch die Beschreibungen des Herstellers und seiner Gehilfen i.S.d. § 434 Abs. 2 Satz 3 BGB wichtig sein. Zu diesen Beschreibungen gehören neben Äußerungen in Fachzeitschriften1 auch Darstellungen in Internetauftritten2 und zwar – außer in hier nicht interessierenden Sonderfällen3 – auch Äußerungen in englisch auf *.com-Seiten. So wichtig im Übrigen ein Pflichtenheft für die Beschreibung der Soll-Be- 250 schaffenheit ist, vollständig wird es nie sein. Es werden immer wieder Dinge im Pflichtenheft nicht stehen, die entweder übersehen wurden oder von beiden Parteien für so selbstverständlich gehalten wurden, dass sie nicht aufgenommen wurden. Besteht später Streit über genau diese Probleme, wird man hier für die Fül- 251 lung der Lücken wieder auf die gewöhnliche Verwendung der Software zurückgreifen oder darauf, dass die Software die Beschaffenheit aufweisen muss, die bei Werken der gleichen Art üblich ist und die der Besteller nach Art des Werkes verlangen kann. Ist z.B. Stand der Technik, dass ein normales Betriebssystem die Möglichkeit vorsehen muss, den Zugang zum System nur demjenigen zu gestatten, der ein Passwort benutzt, so wäre ein Betriebssystem, das diese Möglichkeit nicht vorsieht, auch dann mangelbehaftet, wenn die Möglichkeit des Passwortschutzes im Pflichtenheft nicht ausdrücklich vereinbart ist. Ebenso ist es so, dass gesetzliche Vorgaben von der Software auch dann er- 252 füllt werden müssen, wenn dies nicht ausdrücklich vereinbart ist, jedenfalls dann, wenn die Software zur Erfüllung gesetzlicher Pflichten vorgesehen ist, wie dies z.B. bei einer Arztabrechnungssoftware der Fall ist4. Auch sonst geht die Rechtsprechung davon aus, dass das Werk die Beschaffenheit aufweisen muss, die es für den vertraglich vorausgesetzten Gebrauch haben muss – sogar dann, wenn es dazu mehr leisten muss als die anerkannten Regeln der Technik verlangen5. Insgesamt ist grundsätzlich festzuhalten, dass ein Mangel dann vorliegt, 253 wenn die Software in ihrer Ist-Beschaffenheit von der aus den Vertragsunterlagen, ggf. aus technischen Normen oder allgemein üblichen Gebrauch ermittelten Soll-Beschaffenheit negativ abweicht.

1 2 3 4

Marly, Praxishandbuch Softwarerecht, Rz. 1376. Erman/Grunewald, § 434 BGB Rz. 22. Z.B. Massenverkauf über die Ladentheke. OLG Koblenz v. 4.10.1991 – 2 U 403/88, Beilage Nr. 10 zu BB 1992, S. 4 (zum Weinrecht); Moritz, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Nr. 31, Rz. 121. 5 BGH v. 15.10.2002 – X ZR 69/01, MDR 2003, 408 = NJW 2003, 200 (201) m.w.N.

Redeker

387

D Rz. 254 254

Verträge

Die Softwareunternehmen weisen freilich immer wieder darauf hin, dass Software nie mangelfrei sei und deswegen die Definition so generell nicht gelten soll. Dies ist aus verschiedenen Gründen falsch. Die Aussage ist technisch sicherlich richtig. Sie gilt allerdings für viele andere kompliziertere Werkstücke genauso. Auch ein größeres Gebäude wird in aller Regel nicht ganz fehlerfrei errichtet. Das Gleiche dürfte für komplexe Spezialmaschinen gelten1. Dennoch ist in diesem Bereich völlig unstreitig, dass mangelfrei geliefert werden muss. Sogar dann, wenn die geschuldete Eigenschaft technisch überhaupt nicht erreichbar ist, liegt ein Mangel vor2. Rechtlich ist die Aussage also irrelevant.

255

Allerdings führt nicht jede fehlerhafte oder auch nur suboptimale Programmgestaltung gleich zur Annahme eines Mangels im rechtlichen Sinne. Vielmehr muss sich der technische Mangel dahingehend auswirken, dass vereinbarte Anforderungen nicht erfüllt sind, also z.B. Funktionalitäten gar nicht erfüllt werden, Antwortzeiten zu lang werden oder Ähnliches geschieht. Die bloße Tatsache, dass das Programm vielleicht nicht so elegant programmiert ist, wie dies sich Programmierer wünschen oder dass der modulare Aufbau nicht so gut ist, wie dies nach den Vorgaben einer Richtlinie zur Softwareerstellung erforderlich ist, führt nicht ohne weiteres zu einem Mangel. Dies kann allenfalls dann der Fall sein, wenn entweder einer der Funktionalitäten fehlt oder die möglicherweise in der Leistungsbeschreibung vereinbarte besonders leichte Wartbarkeit des Programms unter der mangelhaften Modularität der Programmerstellung leidet. Möglicherweise liegt auch dann ein Mangel vor, wenn die Parteien es als Soll-Beschaffenheit der Software vereinbart haben, dass diese gemäß einer Richtlinie zur Softwareerstellung erstellt wurde, und dies nur mangelhaft geschehen ist.

256

Der rechtliche Mangelbegriff ist insoweit funktional. Die negative Abweichung der Ist-Beschaffenheit von der Soll-Beschaffenheit muss sich aus den vertraglichen Vereinbarungen ergeben. Diese setzen in aller Regel nicht voraus, dass ein optimales Programm schuld ist, geschuldet ist vielmehr auch in diesem Zusammenhang in aller Regel ein Programm mittlerer Art und Güte – es sei denn, es wird etwas anderes konkret vereinbart.

257

Diskutiert wird dieses Problem oft unter dem Aspekt der Unterscheidung des rechtlichen und technischen Mangelbegriffs3. Ausgangspunkt ist eine Feststellung von Bons in einem jetzt schon Jahrzehnte alten, grundlegenden Werk zu Sachmängelhaftung im EDV-Bereich4.

1 Marly, Praxishandbuch Softwarerecht, Rz. 1363. 2 OLG Köln v. 14.7.1995 – 19 U 293/94, CR 1996, 344; vgl. dazu auch Roth/Dorschel, ITRB 2008, 189 (190). 3 Marly, Praxishandbuch Softwarerecht, Rz. 1360 f. 4 Fehler und Fehlerauswirkungen in: Gorny/Kilian (Hrsg.), Computersoftware und Sachmängelhaftung, 1985, S. 35.

388

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 260 D

Bons definiert so: „Ein Fehler beinhaltet jegliche Abweichung in Inhalt, Aufbau und Verhalten eines Objekts zwischen ermittelten, beobachteten, gemessenen Daten einerseits und den entsprechenden, in den Zielvorgaben spezifizierten oder theoretisch gültigen Daten andererseits“.

Diese Definition liest sich sehr umfassend. Aber auch sie bezieht sich schon auf Zielvorgaben, allerdings erweitert sie die Zielvorgaben noch um theoretisch gültige Daten. Fasst man unter diese doppelte Definition auch, dass ein Programm technisch ordnungsgemäß programmiert wird und alle Abläufe vollständig ungestört verlaufen, wird man bei komplexeren Systemen nie zu einer fehlerfreien Software gelangen. Die Definition ist aber auch in der Informatik nicht so abstrakt zu sehen. 258 Wie schon erwähnt, spielen schon in der Definition selbst Zielvorgaben eine Rolle. Andere Informatiker sehen dies auch sehr viel funktionaler. So spricht Belli in einem grundlegenden Aufsatz im Jahr 1986 hinsichtlich Fehlerbeschreibungen ausdrücklich davon, dass für eine Fehlerbeschreibung mitgeteilt werden muss, aus welchem Subsystem der Fehler stammt, aber auch, in welcher Weise die Funktion des Subsystems durch den Fehler beeinträchtigt wird. Wird die Funktion des Subsystems durch den Fehler nicht beeinträchtigt, liegt gar kein Fehler vor. Auch Belli geht also von einer funktionellen Betrachtung des Fehlerbegriffs aus1. Dies wird auch in anderen Veröffentlichungen aus der Informatik ähnlich 259 gesehen. Das Versagen und der Ausfall eines Systems wird in aller Regel definiert als nicht spezifikationsgemäßes Reagieren des Systems auf eine Eingabe2. Auch die Informatik geht daher insgesamt eher von einem funktionalen Fehlerbegriff aus, der daran anknüpft, dass das informatische System nicht die Anforderungen erfüllt, die an das System gestellt werden. Insoweit unterscheidet sich die Funktion letztendlich gar nicht mehr vom rechtlichen Mangelbegriff. Entscheidend ist freilich, worin man die Soll-Beschaffenheit sieht. Dieses festzustellen ist eine der wesentlichen Voraussetzungen, wenn man feststellen will, ob eine Software mangelhaft ist. b) Einzelne Beispiele von Mängeln Angesichts der bunten Vielfalt, die Softwaremängel in der Realität aufwei- 260 sen, hat es immer wieder Versuche gegeben, Softwaremängel zu systematisieren3. Auf einen solchen Systematisierungsversuch soll an dieser Stelle

1 Belli/Echtle/Görke, Informatikspektrum 1986, 68 (70). 2 Vgl. auch Belli/Grochtmann/Jack, Informatikspektrum 1998, 131 (133); Liggesmeyer/Rothfelder/Rettelbach/Ackermann, Informatikspektrum 1998, 249 (259). 3 Junker/Benecke, Computerrecht, Rz. 270 ff.; Marly, Praxishandbuch Softwarerecht, Rz. 1397 ff.

Redeker

389

D Rz. 261

Verträge

verzichtet werden. Für die Praxis, insbesondere der vertraglichen Gestaltung, spielt nur die Einteilung der Mängel nach ihren Auswirkungen eine Rolle. Es werden oft betriebsverhindernde, erheblich betriebsbehindernde und lediglich lästige Mängel unterschieden. Je nach Stärke der Mängel richten sich dann auch Reaktionsnotwendigkeiten im Bereich von Nachbesserungsklauseln und Pflegeverträgen. Auch ohne vertragliche Vereinbarung können solche Unterscheidungen im Hinblick darauf von Bedeutung sein, dass einzelne Rechtsfolgen nur bei nicht unwesentlichen Mängeln eintreten. Darauf wird einzugehen sein. Eine vom konkreten Projekt absehende abstrakte Klassifizierung erheblicher und unerheblicher Fehler ist kaum möglich. Andere Einteilungen als diese sind rechtlich irrelevant. Sie mögen im Zusammenhang mit der technischen Behebung von Mängeln von Bedeutung sein. Für die juristische Betrachtung sind sie ohne Belang. Deswegen wird hier nur eine Liste von Beispielen von Fehlern vorgestellt, wie sie in der Rechtsprechung als Mängel angesehen wurden1. Ebenso sollen in einer weiteren Aufzählung Fälle dargestellt werden, in denen die Rechtsprechung keinen Mangel angenommen hat. 261

Ein Mangel ist es nach der Rechtsprechung, wenn bei einem Überlaufen von Dateien die Anlage dies weder anzeigte noch den Betrieb einstellte und es dadurch zu Folgefehlern kam2. Ein Fehler soll es auch sein, wenn bei Fehleingaben durch Überschreibung von Datenbereichen Dateninkonsistenzen erzeugt wurden3. Im Gegensatz zu einer älteren Rechtsprechung muss auch bei Billigprodukten heute bei Fehlbedienungen ein Hinweis gegeben, Fehlbedienungen also kontrolliert werden4.

262

Generell ist es ein Mangel, wenn Fehleingaben nicht zurückgewiesen werden, weil Plausibilitätsprüfungen fehlen5. Ein Mangel liegt auch vor, wenn ein Programm bei geringfügigen Bedienungsfehlern abstürzt und im Handbuch Angaben dazu fehlen, wie dies zu vermeiden ist6. Ebenso ist es ein Mangel, wenn Sicherungsläufe nicht durchgeführt und Daten daher nur begrenzt gespeichert werden können7. Eine Software, die nach Angaben des Herstellers auf IBM-kompatiblen Rechnern lauffähig ist, ist mangelbehaftet, wenn das Programm auf üblicherweise als IBM-kompatibel zu bezeichnenden Geräten nicht funktionsfähig ist8. Mängel sind auch zu lange Ausdruck-

1 2 3 4 5 6 7 8

Ausführlich: Schneider, Handbuch des EDV-Rechts, D Rz. 832 ff. LG Duisburg v. 18.3.1988 – 18 O 1/87, CR 1989, 494 (495). LG Flensburg v. 21.5.1986 – 6 O 98/85, CR 1988, 132 (133). A.A. OLG Karlsruhe v. 7.10.1983 – 15 U 11/83, CR 1986, 549 (550) m. zust. Anm. Seitz. LG Heilbronn v. 11.10.1988 – 2 O 17/85 I, CR 1989, 603 (604) m. krit. Anm. Schnell; ähnlich LG Flensburg v. 21.5.1986 – 6 O 98/85, CR 1988, 132 (133). OLG Köln v. 22.6.1988 – 13 U 113/87, CR 1989, 391. LG Frankfurt v. 17.11.1986 – 3/1 O 18/85, CR 1988, 922. LG Karlsruhe v. 9.3.1990 – 9 S 426/89, CR 1990, 719 (LS) zu einer „Speedcard“; einschränkend OLG Köln DuD 1994, 341.

390

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 265 D

zeiten für Listen1 oder ein zu langsames Antwortzeitverhalten2. Gerade im Hinblick auf das Antwortzeitverhalten dürften sich aber konkrete Vereinbarungen in den Verträgen in besonderem Umfang empfehlen, weil die Frage, was das geforderte Antwortzeitverhalten ist, zwischen den Vertragsparteien durchaus umstritten sein kann. Problematisch ist die Frage, wie viel Ausfälle in welcher Zeit die Software 263 haben darf, ohne mangelhaft zu werden. Dies dürfte eine Frage des Einzelfalls sein und auch von den konkreten Einsatzbedingungen der Software abhängen. Die Rechtsprechung ist uneinheitlich. So hat das OLG Nürnberg3 10 % fehlerbedingte Ausfallzeit als noch tolerierbar angesehen und keinen Mangel angenommen. Demgegenüber geht das OLG Hamm4 bei 32 Mängelrügen in 1 1/2 Jahren nicht nur von einem Mangel, sondern sogar davon aus, dass der Kunde ohne Nachfristsetzung vom Vertrag zurücktreten kann. Auch die Lieferung virenbefallener Programme stellt einen Mangel dar5. Bei 264 der Lieferung installierter Betriebssysteme oder gar vorinstallierter PCs stellt auch das Fehlen von Firewalls und Antivirenprogrammen oder sonstigen Schutzvorkehrungen gegen Schadsoftware einen Mangel dar6. Ein Mangel liegt auch dann vor, wenn man ihn mit einem gängigen Programm korrigieren kann. Für die Erheblichkeit des Mangels kann es nicht darauf ankommen, mit welchem Aufwand er beseitigt werden kann7. Soll die Software auf einer bestimmten DV-Anlage, die im Vertrag bezeich- 265 net ist, laufen, ist sie mangelhaft, wenn sie dort wegen Speicherplatzmangel nicht lauffähig ist8. Auch die Notwendigkeit häufigen Wechsels zwischen Anwenderprogrammen und Betriebssystemebene ist bereits als Mangel angenommen worden9. Ebenso stehen fehlende10 oder schwer verständliche Fehlermeldungen11 oder das Abspeichern leerer Sätze auf Grund zu langen 1 KG v. 1.6.1990 – 14 U 4238/86, CR 1990, 768 (769). 2 OLG Koblenz v. 28.11.1986 – 2 U 89/84, CR 1988, 463 (466 f.); LG München v. 21.10.1986 – 7 O 1314/85, CR 1986, 803; LG Ravensburg v. 31.5.1990 – 5 O 109/90, Beilage Nr. 7 zu BB 1991, S. 12 f.; LG Karlsruhe v. 9.12.1992 – 1 S 72/92, CR 1993, 499; KG v. 1.6.1990 – 14 U 4238/86, Beil. 18 zu BB 1991, S. 16. 3 OLG Nürnberg v. 6.8.1985 – 3 U 2466/83, CR 1986, 545. 4 Vgl. OLG Köln v. 22.6.1988 – 13 U 113/87, CR 1989, 391 (392 f.). 5 So schon LG Stuttgart v. 22.5.1991 – 18 O 109/90, in: Zahrnt, ECR LG 92; LG Regensburg v. 17.6.1997 – 2 S 168/96, NRW-RR 1998, 1353; Rombach, CR 1990, 101 (103); Redeker, CR 1993, 193 (196); Schneider/Günther, CR 1997, 389 (390); ebenso Rössel, ITRB 2002, 214; Mankowski, in: Ernst (Hrsg.), Hacker, Cracker & Computerviren, Rz. 425. 6 Mankowski, in: Ernst (Hrsg.), Hacker, Cracker & Computersoftware, Rz. 442 f.; vgl. dazu auch Schimmer, DuD 2006, 616; Paulus/Tegge, DuD 2006, 623. 7 A.A. LG Regensburg v. 17.6.1997 – 2 S 168/96, NRW-RR 1998, 1353; widersprüchlich Erman/Westermann, § 323 Rz. 27. 8 OLG Karlsruhe v. 30.9.1994 – 15 U 89/94, CR 1995, 397. 9 OLG Hamm v. 22.8.1991 – 31 U 260/90, in: Zahrnt, ECR OLG 81. 10 OLG Köln v. 22.6.1988 – 13 U 113/87, CR 1989, 391 (392). 11 OLG Hamm v. 11.12.1989 – 31 U 37/89, CR 1990, 715 (716).

Redeker

391

D Rz. 266

Verträge

Festhaltens einer Taste ohne Warnanzeige Mängel dar. Soweit es um Textverarbeitung geht, ist bei Programmen, die Texte verarbeiten können, heute davon auszugehen, dass die Software in der Lage sein muss, den normalen Buchstabensatz der deutschen Sprache einschließlich aller Umlaute darzustellen. So dürfen nicht anstelle von Umlauten Fragezeichen gedruckt werden1. Soll Quellcode geliefert werden, stellt es einen Mangel dar, wenn er für einen Fachmann nicht verständlich und verwertbar kommentiert ist2. 266

Ein Programm muss auch einen Bedienungskomfort aufweisen, wie er dem Stand der Technik entspricht. Gerade hier können Normen durchaus eine Rolle spielen, namentlich ISO 9241 (Ergonomie der Mensch-System-Interaktion), Teil 11–17, 110 (Software). Programme, die diesen Anforderungen nicht entsprechen, sind mangelhaft3.

267

Auch ansonsten müssen die jeweils geschuldeten Programme die von ihnen zu erwartenden Funktionalitäten erbringen. So ist ein Rechnungsprogramm fehlerhaft, wenn Rechnungen falsch ausgedruckt werden oder eine Auftragsbestätigung nicht erstellt werden kann4. Bei Arztprogrammen ist es ein Mangel, wenn die Quartalsabrechnung nicht erstellt wird5 oder wenn entsprechende Unterlagen von der kassenärztlichen Vereinigung nicht akzeptiert werden6. Der BGH geht sogar davon aus, dass ein Mangel unabhängig davon vorliegt, ob die Weigerung der abrechnenden Stelle zu recht erfolgt oder nicht7. Dies ist aber fehlerhaft. Es kann nur auf die objektive Eignung ankommen, nicht jedoch darauf, ob eine staatliche Stelle rechtswidrigerweise die Abrechnung nicht anerkennt.

268

Bei Finanzbuchhaltungsprogrammen liegt ein Fehler darin, dass die Buchungskapazität im Verhältnis zu dem bei Vertragsabschluss vorausgesetztem Umfang zu gering ist8, wenn das Finanzbuchhaltungsprogramm nicht in der Lage ist, einen Scheckbetrag aus mehreren Rechnungen zusammenzusetzen9 oder wenn der Kontenrahmen nicht den gesetzlichen Vorschriften entspricht10.

1 LG Augsburg v. 5.5.1988 – HKO 3588/87, CR 1989, 22 (24); bestätigt von OLG München v. 15.2.1989 – 27 U 386/88, CR 1990, 646 (648); vgl. auch OLG Stuttgart v. 29.10.1986 – 3 U88/86, CR 1988, 296. 2 AG Pforzheim v. 7.7.1987 – 3 C 540/86, CR 1989, 497. 3 OLG Karlsruhe v. 30.9.1994 – 15 U 89/94, CR 1995, 397; a.A. LG Oldenburg v. 24.4.1991 – 12 O 204/90, CR 1992, 26 = NJW 1992, 1771; LG Heilbronn v. 16.12.1993 – 1 KfH O 262/89, Beil. Nr. 7 zu BB 1994, S. 7. 4 LG München I v. 23.1.1985 – 8 HKO 11785/83, CR 1987, 364 (365). 5 BGH v. 20.6.1984 – VIII ZR 131/83, MDR 1985, 315 = NJW 1985, 129 (130). 6 BGH v. 5.10.1981 – VIII ZR 259/80, MDR 1982, 400 = NJW 1982, 696 f. 7 BGH v. 5.10.1981 – VIII ZR 259/80, MDR 1982, 400 = NJW 1982, 696 f. 8 LG Siegen, zitiert bei Brandi-Dohrn, CR 1986, 63 (70). 9 LG Bielefeld v. 1.3.1988 – 14 S 108/87, Beilage 5 zu BB 1989, S. 6 (7). 10 OLG Hamm v. 14.11.1994 – 31 U 105/94, CR 1995, 341 = MDR 1995, 245 = NJW-RR 1995, 941 (942) zum Bilanzrichtliniengesetz.

392

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 272 D

Zeigt ein Lagerverwaltungsprogramm bei einer Suche nach Artikeln zwar 269 den geforderten Artikel an, aber nicht die Artikelnummer und weist es auch Textfehler auf, ist auch dies ein Mangel1. Ein Zeiterfassungssystem, das an einen Gastronomiebetrieb veräußert wird, muss in der Lage sein, die geschuldeten Funktionen auch am Sonntag zur Verfügung zu stellen2. Ist Parametrisierung geschuldet, sind auch Fehler in der Parametrisierung Mängel3. Eine Software für die Abwicklung von Zulieferern durch ein Großunternehmen muss den Datenexport für alle Zulieferer korrekt vornehmen können4. In einzelnen Fällen kann darüber hinaus auch die bloße Gefahr von Dis- 270 funktionalitäten einen Mangel darstellen, wenn etwa Fertigungstoleranzen bei sicherheitsrelevanten Systemen nicht eingehalten sind. Auch dann, wenn die Software längere Zeit störungsfrei läuft, relativiert sich dieser Mangel nicht5. Ein besonderes Problem stellen technische Probleme und Nutzungs- 271 beschränkungen dar. Wird die Nutzbarkeit der Software durch eine Programmsperre beeinträchtigt, liegt ein Mangel vor6. Dies gilt insbesondere dann, wenn die Programmsperre den säumigen Kunden zur Zahlung zwingen soll7. Ebenso ist es ein Mangel, wenn eine Programmsperre eingebaut wird, die nur durch eine Registrierung beim Programmhersteller, der möglicherweise noch nicht einmal der Verkäufer ist, überwunden werden kann8. Dieses gilt für technische Sicherungsmaßnahmen, die nicht vereinbarte Nutzungsbeschränkungen durchsetzen und auf die nicht im Zusammenhang mit dem Softwareerwerbsvertrag hingewiesen wird, z.B. Sperren, die es verhindern, die Software nach Weitergabe an einen Dritten oder einem sonstigen Rechnerwechsel neu zu installieren oder dies sogar nach Löschen der Festplatte verhindern oder von einer Handlung des Herstellers abhängig machen9. Auch dann, wenn das Programm auf Dauer nur nach Aktivierung seitens des Herstellers genutzt werden kann, obwohl eine solche Einschränkung nicht zuvor vereinbart war, liegt ein Mangel vor10. Mängel liegen auch dann vor, wenn sich Probleme der Nutzung der Software erst in der Zukunft abzeichnen. Dies galt z.B. für vor 2000 erworbene, 1 2 3 4 5 6 7 8

9 10

OLG Karlsruhe v. 10.7.1991 – 6 U 87/90, in: Zahrnt, ECR OLG 78. OLG Köln v. 19.8.1992 – 19 U 17/92, CR 1993, 282. OLG Hamm v. 12.11.1990 – 31 U 53/90, Beil. 23 zu BB 1991, S. 2. LG Bonn v. 31.10.2006 – 11 O 170/05, CR 2007, 767 (768). A.A. OLG Düsseldorf v. 22.12.1995 – 22 U 180/95, in: Zahrnt, ECR OLG 219. OLG Celle v. 3.3.1992 – 20 U 69/90, CR 1994, 217; OLG Köln v. 29.10.1999 – 19 U 94/99, CR 2000, 354. LG Wiesbaden v. 4.4.1989 – 3 O 13/88, CR 1990, 651 f. Nach LG München I v. 4.4.2000 – 7 O 115/00, CR 2000, 506 und OLG München v. 12.10.2000 – 29 U 3680/00, CR 2001, 11 ist der Vertrieb solcher Programme sogar wettbewerbswidrig. Koch, CR 2002, 629 f. Näher auch Runte, CR 2001, 657 (660 f.).

Redeker

393

272

D Rz. 273

Verträge

nicht „Jahr 2000“-feste Software, weil der Besteller zu jeder Zeit erwarten konnte, dass er eine auf Dauer erworbene Software auch nach 1999 noch benutzen konnte1. Ähnliches galt für die Eurofähigkeit. Ab dem Zeitpunkt, wo klar, dass und wann der Euro eingeführt wurde, musste ein auf Dauer erworbene und zur dauerhaften Nutzung bestimmte Software, die mit Geldbeträgen hantierte auch Eurobeträge realisieren. Ähnliches gilt – und dies ist für die Zukunft wichtig – auch für sonstige Gesetzesänderungen. Eine Software, die Aufgaben erfüllen soll, die gesetzlichen Vorgaben unterliegen, ist mangelhaft, wenn sie diese Anforderung nicht erfüllt. Sie ist aber auch dann mangelhaft, wenn eine Gesetzesänderung absehbar ist und die Software zum Zeitpunkt der Übergabe diese Anforderung nicht erfüllen kann. Auch dann muss sie zum Zeitpunkt der Übergabe die notwendigen Eigenschaften aufweisen2. 273

Kein Mangel soll das Vorliegen einer Programmsperre zum Schutz vor unbefugter Nutzung sein, wenn dadurch die Nutzbarkeit des Programms nicht beeinträchtigt wird3. Auf diese Sperre muss aber vor Programmerwerb hingewiesen werden4.

274

Keinen Mangel soll es darstellen, wenn die Einsortierung von Umlauten in einem Programm zur Listenverarbeitung hinter dem Buchstaben „z“ erfolgt5. Diese Entscheidung ist aber fraglich. Klar ist, dass es keinen Mangel darstellt, wenn die von einem Programm (im entschiedenen Fall von einem Programm, dass eine Scannerkasse steuerte) mittels eines standardisierten Übertragungsprotokolls gelieferten Daten von einem von Dritter Seite bezogenen Warenwirtschaftssystem nicht bearbeitet werden können6. Hier hätte die Kompatibilität der Programme vom Kunden selbst geprüft werden müssen. Für Standardprogramme hat die Rechtsprechung auch schon entschieden, dass ein konzeptionell veraltetes Programm unter Umständen mangelfrei sein soll7. Dies mag für Standardprogramme bei nicht zu starker Überalterung zutreffend sein, weil sonst etwas ältere Programme immer mangelhaft sind. Für individuell hergestellte Programme gilt dies nicht. Diese müssten konzeptionell nach der aktuellen Programmiertechnik erstellt werden.

1 Ebenso Hoene, CR 1999, 281; ähnlich auch LG Leipzig, CR 1999, 620 f.; Hoerl, CR 1999, 605 (607); Graf von Westphalen, in: Graf von Westphalen/Langheid/ Streitz, Der Jahr 2000-Fehler, Rz. 404 ff., 413 ff. 2 Orthwein/Bernhard, CR 2009, 354. 3 BGH v. 3.6.1981 – VIII ZR 153/80, NJW 1981, 2684; OLG Köln v. 9.6.1985 – 19 U 294/94, OLGReport Köln 1995, 285. 4 Etwas unklar BGH v. 3.6.1981 – VIII ZR 153/80, NJW 1981, 2684; OLG Köln v. 9.6.1985 – 19 U 294/94, OLGReport Köln 1995, 285. 5 LG Heilbronn v. 16.12.1993 – 1 KfH O 262/89, Beilage Nr. 7 zu BB 1994, S. 7 m. Anm. Zahrnt. 6 OLG Köln v. 21.2.1992 – 19 U 220/91, CR 1992, 468 = NJW 1992, 1772. 7 LG Oldenburg v. 24.4.1991 – 12 O 204/90, CR 1992, 26 = NJW 1992, 1771; LG Köln v. 22.10.1992 – 86 O 103/92, CR 1993, 564.

394

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 279 D

c) Gleichgestellte Probleme Zunächst ist festzuhalten, dass auch eine Zuweniglieferung und eine Aliudlieferung Sachmängel darstellen (§ 633 Abs. 3 BGB). Diese Problematik dürfte im Bereich der Erstellung von Software keine Rolle spielen, so dass auf diese Problematik nicht einzugehen sein wird.

275

Anders ist dies mit den Rechtsmängeln. Rechtsmängel stehen seit 2002 276 Sachmängeln gleich. Dies gilt auch für die Rechtsfolgen. Dadurch sind gravierende Änderungen auf der Rechtsfolgenseite im Hinblick auf Rechtsmängel eingetreten und eine Reihe von Rechtsfragen aufgeworfen worden, die es früher nicht gegeben hat1. Auf die sich daraus ergebenden Probleme wird an einzelnen Stellen noch einzugehen sein (vgl. dazu Rz. 351 ff.). 2. Rechtsfolgen von Mängeln a) Werkvertrag aa) Bedeutung der Abnahme Liegt bei dem Vertrag, der konkret zu beurteilen ist, ein Werkvertrag vor, 277 gelten bei Vorliegen von Mängeln die §§ 633 ff. BGB. Dies gilt allerdings erst ab Abnahme des Werks. Vor Abnahme gibt es einen Herstellungsanspruch. Erfolgt die Herstellung nicht mängelfrei, stehen dem Besteller auch im Hinblick auf die Beseitigung der Mängel die Rechte nach §§ 288 ff., 323 ff. BGB zu. Dies bedeutet insbesondere, dass er dem Unternehmer eine Frist zur mangelfreien Herstellung des Werkes setzen kann. Nach Verstreichen der Frist gerät der Unternehmer in Verzug. Das Gleiche gilt auch ohne Fristsetzung, wenn der Fertigstellungstermin kalendermäßig bestimmt oder anderweitig berechenbar ist. Allerdings bedarf eine solche kalendermäßige Bestimmung oder anderweitige Berechnungsmöglichkeit einer entsprechend konkreten vertraglichen Vereinbarung. Gerät der Unternehmer in Verzug, kommt auch ein Rücktrittsrecht seines Kunden in Betracht. Dies geht allerdings immer erst nach Fristsetzung (§ 323 BGB). Ferner gibt es Schadensersatzansprüche nach §§ 280 ff. BGB. Außerdem sind die Regelungen des § 326 BGB anwendbar. Mit der Abnahme gehen diese Erfüllungsansprüche unter. An ihre Stelle tre- 278 ten die Ansprüche wegen Sachmängeln. Diese zentrale Bedeutung verbleibt der Abnahme. Sowohl vor als auch nach der Abnahme muss der Kunde freilich Fristen set- 279 zen. Nach einer Entscheidung des BGH aus dem Jahre 19882 soll die Fristsetzung vor Abnahme aber in sehr allgemeiner Form erfolgen können. Es soll ausreichen, lediglich die Fertigstellung eines mangelfreien Werks zu verlangen, ohne in irgendeiner Weise darauf einzugehen, in welcher Weise 1 Dazu Roth, ITRB 2003, 231; Redeker, ITRB 2004, 84, Bartsch, CR 2005, 1. 2 BGH v. 7.7.1987 – X ZR 23/86, NJW-RR 1988, 310 (311).

Redeker

395

D Rz. 280

Verträge

ein eventuell aus Sicht des Herstellers schon fertiggestelltes Werk überhaupt Mängel aufweist. Die Fristsetzung kann auch eine Liste von Mängelrügen enthalten und zum Schluss den allgemeinen Satz aufweisen, man verlange auch ein im Übrigen mangelfreies Werk. Wenn der Hersteller dann alle gerügten Mängel beseitigt und ein anderer Mangel gefunden wird, tritt dennoch Verzug (mit der Rücktrittsmöglichkeit) ein. Demgegenüber muss nach Abnahme die Nacherfüllung jeweils für konkrete Mängel verlangt und insoweit eine Frist gesetzt werden. Werden danach noch weitere Mängel entdeckt, muss eine neue Fristsetzung erfolgen. 280

Diese Rechtsprechung soll auch im neuen Recht im Wesentlichen weiter gelten1. Allerdings verlangt der BGH in seiner Entscheidung zumindest eine Darlegung der fehlenden Funktionalität in der Fristsetzung, damit der Lieferant, der seine Leistung nach seiner Ansicht vollständig erbracht hat, weiß, worum es geht. Insoweit greift er eine Literaturmeinung auf, die für das neue Schuldrecht schon längere Zeit vertreten wird und nach der § 323 bei jedem Leistungshindernis, das nur einen Teil oder nur einen qualitativen Aspekt der Leistung betrifft, verlangt, dass der Gläubiger in seiner Mahnung konkret bezeichnet, was nach seiner Ansicht fehlt oder mangelhaft ist2. Sowohl diese Meinung als auch die Begründung des BGH in der oben genannten Entscheidung spricht dafür, dass Rechtsfolgen nicht auf Mängel gestützt werden können, die nicht zumindest pauschal gerügt wurden. Diese Frage musste aber in der angesprochenen Entscheidung nicht entschieden werden. Jede andere Rechtsauffassung als diese wäre allerdings auch für den Unternehmer kaum zumutbar. Komplexe Softwareprojekte würden dann, wenn sie der Besteller zum Scheitern bringen will, zu einem kaum noch kontrollierbaren Risiko für den Unternehmer werden, vor allem dann, wenn keine Abnahmekriterien vereinbart wurden. Der Besteller kann ja dann immer nach Neulieferung wieder anfangen nach – sicher vorhandenen – Mängeln zu suchen und deswegen die Abnahme verweigern. Nach mehreren Fristsetzungen dürfte er dann auch zum Rücktritt berechtigt sein. Eine Entscheidung des BGH zu dieser Frage steht freilich noch aus.

281

Die rechtlichen Konsequenzen der verschiedenen Fristsetzungen sind allerdings unterschiedlich. Eine Minderung ist nämlich nur möglich, wenn eine Abnahme erfolgt ist, weil die Minderung nur im Rahmen der Sachmängelansprüche im Gesetz vorgesehen ist. Insoweit wird in der Rechtsprechung ein Minderungsverlangen faktisch der Abnahme gleichgestellt3. Die nach der Abnahme bestehenden Ansprüche wegen Mängeln werden in der Folge dargestellt.

1 BGH v. 25.3.2010 – VII ZR 224/08, CR 2010, 422 m. krit. Anm. Bartsch, CR 2010, 777. 2 Vgl. Erman/Westermann, § 323 BGB Rz. 22. 3 BGH v. 16.5.2002 – VII ZR 479/00, MDR 2002, 1188 = NJW 2002, 3019; BGH v. 10.10.2002 – VIII ZR 315/01, NJW 2003, 288.

396

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 284 D

bb) Nacherfüllungsansprüche Nach § 634 BGB kann der Kunde zunächst Nacherfüllung beanspruchen 282 (§ 634 BGB). Dieser Nacherfüllungsanspruch ist der primäre, zunächst ohne Einschränkung gegebene Anspruch des Kunden. Dies ist auch sachgerecht, weil sich in aller Regel die mit den Mängeln verbundenen Probleme am besten dadurch beseitigen lassen, dass der Ersteller der Software die Mängel beseitigt. Außerdem ist es angemessen, ihm eine Chance zu geben, sein Werk nachträglich noch mangelfrei herzustellen1. Er kann dies gerade bei Individualsoftware auch am einfachsten und schnellsten, da er allein das Programm kennt. Wie er den Nacherfüllungsanspruch erfüllt, kann er entscheiden2. Bevor er nacherfüllen kann, müssen ihm die Mängel ordnungsgemäß an- 283 gezeigt werden. Dabei kommt es nicht auf Überschriften an. Es muss nicht etwa von „Mangelanzeige“ die Rede sein. Es muss auch nicht förmlich gesagt werden, dass es um Nacherfüllungs- oder Mängelbeseitigungsansprüche geht. Ein Hinweis darauf, dass der Kunde mit dem Programm nicht zufrieden ist, reicht völlig aus. In der Praxis ist es oft auch so, dass beide Parteien gemeinsam versuchen, die Lösung des Problems zu finden, ohne dass förmlich von Mangelbeseitigung, Mängelrügen u.Ä. die Rede ist. Dies reicht als Mängelanzeige. Bei der Mangelanzeige muss nur das Mangelerscheinungsbild dargelegt wer- 284 den3. Was dies konkret bedeutet, ist freilich einzelfallabhängig. Fehlen bestimmte Funktionen, reicht es sicherlich aus, schlicht dies zu rügen. Detaillierte Angaben sind dann erforderlich, wenn es sich um unregelmäßig auftretende Abstürze oder Fehlfunktionalitäten handelt, da nur mit Hilfe der detaillierten Beschreibung überhaupt überprüft werden kann, worum es eigentlich geht. Gibt es Fehlermeldungen der Software, müssen auch diese dem Hersteller mitgeteilt werden4. Bei unregelmäßig auftretenden Problemen muss in aller Regel auch dargestellt werden, in welchem Benutzungszusammenhang der Fehler auftritt. Solche umfangreichen Angaben werden nicht immer leicht verfügbar sein. Es empfiehlt sich daher, die Mitarbeiter anzuweisen, bei Auftreten von Fehlern Fehlermeldungen zu notieren und auch festzuhalten, an welcher Stelle und bei welcher Eingabe Fehler auftreten. Solche Fehlermeldungen verschiedener Mitarbeiter sollten zu einem „Logbuch“ über auftretende Fehler führen, das im Detail festhält, welche Fehler wann eingetreten sind. Im Logbuch enthalten sein sollten, wer den Fehler gemeldet hat, in welchem Programm dieser gearbeitet hat, welche 1 Erman/Schwenker, § 634 BGB Rz. 3. 2 Junker/Benecke, Computerrecht, Rz. 317; Schneider, Handbuch des EDV-Rechts, D Rz. 586. 3 OLG Hamm v. 11.12.1989 – 31 U 37/89, CR 1990, 715 (717) (sogar zur Darstellung im Prozess); OLG Köln v. 18.8.1997 – 19 U 43/97, NRW-RR 1998, 1274; vgl. auch die Regelungen in § 12 Nr. 4 BVB-Erstellung. 4 Gaul, CR 2000, 570 (572 f.).

Redeker

397

D Rz. 285

Verträge

Daten oder Befehle er eingegeben hat, welche Fehleranzeigen erfolgten und was versucht worden ist, um den Fehler zu beheben oder zu umgehen1. 285

Je detaillierter eine Fehlermeldung ist, umso eher wird der Hersteller in der Lage sein, den Fehler zu beseitigen. Allerdings wird in vielen Fällen gar nicht mehr ohne weiteres rekonstruiert werden können, in welchem Zusammenhang welche Fehler aufgetreten sind. Hier ist es gefährlich, Nichtwissen durch Überpräzision zu ersetzen. Falsche Fehlerbeschreibungen sind schlimmer als ungenaue, weil dann überhaupt nicht systematisch nach Fehlerbeschreibungen gesucht werden kann. Der Kunde sollte daher bei der Fehlermeldung so präzise wie möglich sein, sich dabei aber nicht überfordern.

286

Im Übrigen gilt: Eine Fehlermeldung muss keinesfalls so genau sein wie eine Fehlerbeschreibung etwa in einem gerichtlichen Schriftsatz, der ja auch erst weit später nach meist umfangreichen Fehleruntersuchungen und Fehlerbehebungsversuchen ansteht. Es reicht aus, wenn der Hersteller erkennen kann, worum es geht und er einen ersten Anhaltspunkt dafür hat, zu entscheiden, ob er dem Fehler nachgehen muss oder es sich um Bedienungsfehler oder um zusätzliche Anforderungen handelt. Reicht ihm die Genauigkeit der Fehlerbeschreibung nicht aus, muss er nachfragen. Als Fehlermeldung ist es allerdings nicht ausreichend, schlicht zu behaupten, die Software funktioniere nicht2. Dies gilt aber nicht, wenn die Software überhaupt nicht läuft. Dann kann nicht mehr angegeben werden, als dass sie überhaupt nicht läuft.

287

Besondere Probleme bestehen dann, wenn die Software Teil eines Systems mehrerer Softwareprodukte ist und der Mangel nach seinem Erscheinungsbild von verschiedenen der eingesetzten Softwareprodukte verursacht worden sein kann. Sind die Softwareprodukte von unterschiedlichen Herstellern geliefert worden, muss der Kunde dem Hersteller plausibel machen, dass sein Produkt mangelhaft ist. Gegebenenfalls muss an dieser Stelle der Kunde auch Ursachenforschung betreiben und schon für die Fehlermeldung eine eigene Untersuchung anstellen. Solange das Verhältnis zwischen den Parteien einigermaßen in Ordnung ist, wird allerdings ausreichend sein, die Fehler zu melden und dem Hersteller zur Prüfung zu überlassen, ob der Fehler aus seinem Mangelbereich kommt. Dies ist aber mehr ein pragmatisches Argument. Im Auseinandersetzungsfall wird man auch als Kunde sehr genau prüfen müssen, wer der Verursacher ist.

288

Ist die Fehlermeldung hinreichend detailliert – ggf. auf Nachfrage hin –, muss der Unternehmer sofort reagieren und die notwendigen Maßnahmen ergreifen. Ist die Fehlermeldung zu verschwommen, muss er auf eine Präzisierung hinwirken. Sagt er gar nichts, kann er sich nicht auf eine mangelhafte Präzisierung der Fehlermeldung berufen. Auf eine Frist, binnen derer 1 Schneider, Handbuch des EDV-Rechts, P Rz. 31. 2 OLG Düsseldorf v. 25.9.1998 – 22 U 62/98, CR 1999, 145 f.

398

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 290 D

die Rüge zu erheben ist, kommt es auch bei einem kaufmännischen Geschäft nicht an. Die Rügepflicht des § 377 HGB gilt für Werkverträge angesichts der klaren Regelung des § 381 Abs. 2 HGB nur dann, wenn § 651 BGB Anwendung findet, also nicht im hier betrachteten Fall1. Es gibt im Übrigen auch Fälle, in denen eine Nachbesserung notwendig ist, wenn sich auch der Besteller an den Kosten beteiligt. Dies gilt insbesondere dann, wenn bei rechtzeitiger mangelfreier Erfüllung höhere Kosten entstanden wären. In diesem Fall muss der Besteller auf Verlangen des Unternehmens vor Durchführung der Nachbesserungen auch für diese Kosten eine Sicherheitsleistung in angemessener Höhe erbringen2. Nach dem Gesetz gibt es verschiedene Fälle, in dem der Softwareersteller 289 die Nacherfüllung berechtigt verweigern kann. Dies gilt nach § 635 Abs. 3 BGB insbesondere dann, wenn die Nacherfüllung nur mit unverhältnismäßig hohen Kosten möglich ist. Die Kosten der Nacherfüllung sind mit dem Wertverlust durch den Mangel zu vergleichen3. Stehen diese beiden Positionen außer Verhältnis, kann der Hersteller die Nacherfüllung verweigern. Auf andere Umstände kommt es nicht an. Für die Auslegung des § 635 Abs. 3 BGB gibt es noch keine bekannte Rechtsprechung. Allerdings enthielt das alte Recht in § 633 Abs. 3 Satz 3 BGB a.F. eine vergleichbare Regelung. Dort war freilich von unverhältnismäßigem Aufwand und nicht von unverhältnismäßigen Kosten die Rede. Ein Verweigerungsrecht wurde damals nur angenommen, wenn der Beseitigungsaufwand in keinem vernünftigen Verhältnis zum Nutzen stand4. Diese restriktive Auslegung dürfte auch für das neue Recht gelten. Das Recht zur Verweigerung der Nacherfüllung dürfte nur in seltenen Ausnahmefällen eintreten. Daneben steht ein weiteres Leistungsverweigerungsrecht, nämlich das nach 290 den allgemeinen Unverhältnismäßigkeitsregelungen der §§ 275 Abs. 2 und 3 BGB. Diese Regelungen dürften neben § 635 Abs. 3 BGB nur selten eine Rolle spielen. Die Leistungsverweigerungsrechte muss der Unternehmer nicht geltend machen. Er kann dies nur tun. Es handelt sich um ein Recht, keine automatische Rechtsfolge5. Das Leistungsverweigerungsrecht muss der Unternehmer darüber hinaus ausüben, bevor der Kunde zurücktritt6 oder Schadensersatzansprüche geltend macht.

1 Junker/Benecke, Computerrecht, Rz. 247; vgl. BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93 (94 f.) zum alten Schuldrecht. 2 BGH v. 22.3.1984 – VII ZR 50/82, NJW 1984, 1676; BGH v. 16.7.1998 – VII ZR 350/96, NJW 1998, 3707; Mankowski, NJW 2011, 1026 (1028). 3 Lorenz, NJW 2007, 1 (5). 4 Köhler/Fritzsche, in: Lehmann (Hrsg.), Rechtsschutz und Verwertung von Computerprogrammen, S. 513 (593); vgl. auch die (nicht unmittelbar einschlägigen) Anmerkungen des EuGH v. 16.6.2011 – C 65-09, V 87-09, BB 2011, 1934 m. Anm. Ayad/Schell. 5 BGH v. 21.12.2005 – VIII ZR 49/05, BB 2006, 686. 6 OLG Celle v. 28.6.2006 – 7 U 235/05, NJW 2007, 353.

Redeker

399

D Rz. 291

Verträge

cc) Voraussetzungen weiterer Mängelansprüche 291

Wird vom Kunden Nacherfüllung verlangt und wird sie trotz Fristsetzung nicht rechtzeitig durchgeführt, treten die weiteren Gewährleistungsrechte ein. Die Nacherfüllungsfrist muss besonders in der Anfangsphase wegen der dort bekanntermaßen häufig auftretenden Schwierigkeiten recht lang sein. Diese Anfangsphase kann aber – insbesondere dann, wenn die Abnahme erst nach einer umfangreichen Funktionsprüfung erfolgt – nur wenige Wochen dauern. Im Übrigen richtet sich die Länge der Frist nach den Umständen des Einzelfalls, wobei sich die Frist z.B. auf Grund von Änderungswünschen des Kunden verlängern kann, wenn diese für den Mangel mit ursächlich waren und die Beseitigung schwieriger machen1. Eine zu kurz bemessene Frist ist nicht unwirksam. Sie setzt vielmehr eine angemessene Frist in Lauf. An eine zu lange Frist ist der Kunde gebunden2.

292

Die Fristsetzung muss – wie auch im Verzugsfall – keine Ablehnungsandrohung enthalten. Sie soll aber als ernsthafte Fristsetzung erkennbar sein. Ein Zuvielverlangen in der Fristsetzung schadet in der Regel nicht. Nur dann, wenn sich aus der Fristsetzung ergibt, dass der Kunde eine vertragsgerechte Lieferung nicht akzeptieren würde, ist dies anders3.

293

Auch ohne Fristsetzung kann der Kunde auf die anderen Mängelrechte zurückgreifen, wenn die Nachbesserung fehlgeschlagen ist (§§ 636, 637 Abs. 1, 638 Abs. 1 BGB), z.B. weil mehrere Nachbesserungsversuche erfolglos verlaufen sind. In der Regel dürfte ein Fehlschlagen nach zwei vergeblichen Nachbesserungsversuchen vorliegen. § 440 Satz 2 BGB dürfte auch im Werkvertragsrecht als Maßstab heranzuziehen sein, zumal wenn – wie im Softwarerecht – die Nähe zu Werkverträgen gegeben ist, die nach § 651 BGB über Kaufrecht abzuwickeln sind4. Je nach den Umständen des Einzelfalls kann ein Fehlschlagen der Nachbesserung freilich auch bei nur einem oder erst bei drei erfolglosen Nachbesserungsversuchen vorliegen. Die Nachbesserung ist außerdem auch dann fehlgeschlagen, wenn zwar der Mangel beseitigt, die Funktionalität der Software aber durch die Nachbesserung eingeschränkt worden ist. Dem Fehlschlagen steht auch die Unmöglichkeit der Nachbesserung gleich. Auf eine Fristsetzung kann der Kunde auch dann verzichten, wenn ihm, z.B. wegen zahlloser früherer Mängel, weitere Nach-

1 Vgl. KG v. 1.6.1990 – 14 U 4238/86, CR 1990, 768 (769); LG München I v. 21.3.1991 – 7 O 3919/89, CR 1992, 474. 2 Erman/Westermann, § 323 BGB Rz. 15. 3 BGH v. 5.10.2005 – X ZR 276/02, NJW 2006, 7769; OLG Köln v. 10.3.2006 – 19 U 160/05, CR 2006, 440. 4 Bischoff, ITRB 2004, 66 (68 f.); zurückhaltender Schneider, Handbuch des EDVRechts, D Rz. 650; Staudinger/Peters/Jacoby, § 634 BGB Rz. 70; a.A. Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 247 f.

400

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 295 D

besserungsbemühungen nicht mehr zumutbar sind1. Wann dies der Fall ist, wird aber in der Rechtsprechung sehr unterschiedlich beurteilt. So hat das OLG Nürnberg2 10 % fehlerbedingte Ausfallzeit als noch tolerierbar angesehen und eine weitere Fristsetzung verlangt. Demgegenüber geht das OLG Hamm3 bei 32 Mängelrügen in 1 1/2 Jahren eine weitere Fristsetzung für unzumutbar gehalten. Die weiteren Mängelrechte – mit Ausnahme des Selbstvornahmerechts – hat der Kunde im Übrigen auch dann, wenn der Lieferant die Nachbesserung berechtigt verweigert.

294

dd) Selbstvornahmerecht Ein erstes an die Stelle des Nacherfüllungsanspruchs tretendes Recht des 295 Kunden ist das Recht, die Nacherfüllung auf Kosten des Unternehmers durch einen Dritten durchführen zu lassen oder auch selbst durchzuführen. Dafür kann er auch einen Vorschuss fordern (§ 637 Abs. 3 BGB, Selbstvornahme). Dieser Anspruch kann in der Praxis außerhalb des Softwarerechts an vielen Stellen sehr hilfreich sein. Bei Software dürfte er nur in seltenen Fällen eine nützliche Alternative darstellen. Selbst wenn der Kunde den Quellcode und die entsprechenden Dokumentationen erhalten und ein Änderungsrecht erworben hat, was im Bereich von Individualsoftware ja durchaus möglich ist, ist rein praktisch die Verwendung dieser Codes mit erheblichem Zusatzaufwand verbunden. Sie erfordert sachkundige Programmierer. Sie erfordert aber auch von den sachkundigsten Programmierern, die nicht selbst an der Erstellung des Programms beteiligt waren, einen erheblichen Einarbeitungsaufwand, der nur in seltenen Fällen gerechtfertigt ist. Auf dieses Recht wird daher im Softwarebereich selten zurückgegriffen. Ist das Recht gegeben, ist die Mangelbeseitigung auch ohne explizit vereinbartes Änderungsrecht urheberrechtlich zulässig (§ 69d Abs. 1 UrhG)4. Welche Aufwendungen der Kunde für erforderlich halten kann, bemisst sich danach, was ein verständiger Mensch auf Grund sachkundiger Beratung bei einer Betrachtung ex ante für notwendig halten darf5. Ein solches Selbstvornahmerecht gibt es dann nicht, wenn der Unternehmer die Nacherfüllung berechtigt nach § 636 BGB oder § 275 Abs. 2 BGB verweigern kann6. In diesen Fällen besteht nämlich kein Nacherfüllungsanspruch, der Voraussetzung eines Selbstvornahmerechts ist.

1 OLG Düsseldorf v. 18.10.1990 – 6 U 71/87, CR 1992, 724; OLG Hamm v. 26.10.1992 – 31 U 81/92, CR 1994, 358. 2 OLG Nürnberg v. 6.8.1985 – 3 U 2466/83, CR 1986, 545. 3 Vgl. OLG Köln v. 22.6.1988 – 13 U 113/87, CR 1989, 391 (392 f.). 4 Marly, Praxishandbuch Softwarerecht, Rz. 1320. 5 Erman/Schwenker, § 637 BGB Rz. 10. 6 Erman/Schwenker, § 637 BGB Rz. 2 unter Verweis auf § 635 BGB Rz. 12 ff.; Staudinger/Peters/Jacoby, Anm. zu § 637 BGB.

Redeker

401

D Rz. 296

Verträge

ee) Minderung und Rücktritt 296

Weitere, praktisch wichtigere Rechte des Kunden, die an die Stelle der Nacherfüllung treten, sind die Möglichkeiten des Kunden, vom Vertrag zurückzutreten oder den Erwerbspreis zu mindern.

297

Das Rücktrittsrecht scheidet dann aus, wenn die in dem Mangel zum Ausdruck kommende Pflichtverletzung unerheblich ist (§ 323 Abs. 5 Satz 2 BGB). Die unerhebliche Pflichtverletzung wird weitgehend mit der Unerheblichkeit des Mangels gleichgesetzt1. Das wird in der Literatur dann angenommen, wenn der Mangel zwar die Funktionsfähigkeit beeinträchtigt, aber leicht zu beseitigen ist2. Davon kann aber nicht ausgegangen werden, weil der Unternehmer diesen Mangel dann leicht hätte beseitigen können und dies nicht getan hat. Es kann nicht Aufgabe des Kunden sein, hier den Beseitigungsaufwand zu ermitteln3. Man wird vielmehr darauf abstellen müssen, dass der Mangel sich hinsichtlich der Funktionsfähigkeit nur unerheblich auswirkt. Wann dies der Fall ist, ist Frage des Einzelfalls.

298

Ein zweites Problem besteht dann, wenn ein umfangreicheres Softwarepaket bestellt wird, das aus verschiedenen abgrenzbaren Teilleistungen besteht, die auch unterschiedlich genutzt werden können. Sind dann einzelne Teilleistungen mangelfrei, andere aber mangelbehaftet und läuft eine Fristsetzung ins Leere, stellt sich die Frage, ob auf das Rücktrittsrecht dann § 323 Abs. 5 oder § 323 Abs. 6 BGB Anwendung findet, mithin, ob es um eine teilweise Erfüllung oder um eine qualitative Nichterfüllung geht.

299

Richtigerweise wird man hier differenzieren müssen. Soweit es sich um abgrenzbare Teilleistungen handelt, ist zunächst festzustellen, ob für die vom Mangel betroffene Teilleistung ein Rücktrittsrecht evtl. nach § 323 Abs. 5 Satz 2 BGB ausscheidet oder nicht. Scheidet es aus, stellen sich keine weiteren Probleme. Ist im Hinblick auf die Teilleistung ein Rücktrittsrecht gegeben, stellt sich dann weiter die Frage, ob sich aus dem Rücktrittsrecht für die Teilleistung ein Rücktrittsrecht für die Gesamtleistung entfaltet, weil dann, wenn die Teilleistung entfällt, am Rest kein Interesse mehr für den Käufer besteht. Nur wenn man auch die zweite Frage bejaht und davon ausgeht, dass der Käufer kein Interesse an der mangelfreien Leistung hat, kommt ein Gesamtrücktritt in Betracht4.

300

Der Rücktritt ist weiterhin dann ausgeschlossen, wenn der Kunde für den Umstand, der ihn zum Rücktritt berechtigen würde, allein oder weit überwiegend verantwortlich ist oder wenn ein vom Hersteller nicht zu vertretender Umstand zu einer Zeit eintritt, zu welcher der Kunde in Annahmeverzug ist (§ 323 Abs. 6 BGB). Diese Regelung versucht, den Grundgedanken des Mitverschuldens auch im Rahmen des Rücktrittsrechts fruchtbar zu ma1 2 3 4

Palandt/Sprau, § 636 BGB Rz. 6. Staudinger/Peters/Jacoby, § 634 BGB Rz. 98. Vgl. dazu auch BGH v. 15.6.2011 – VIII ZR 139/09, NJW 2011, 3708. Lorenz, NJW 2003, 3097 (3098 f.).

402

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 303 D

chen. Dies geschieht allerdings nur ganz eingeschränkt. Das Rücktrittsrecht ist nach dieser Regelung wohl nur dann ausgeschlossen, wenn eventuelle Schadensersatzansprüche nach § 254 BGB ganz ausgeschlossen sein würden. Dies setzt eine Mitverantwortungsquote des Rücktrittsberechtigten von mindestens 80 % voraus1. Das Rücktrittsrecht kann daneben auch bei schwerwiegender sonstiger Vertragsuntreue des Rücktrittsberechtigten ausgeschlossen sein2. Dies gilt z.B. bei fehlerhaften und deutlich verspäteten Mitwirkungshandlungen des Kunden. Wählt der Kunde den Rücktritt, so muss er die schon erhaltene Software zu- 301 rückgeben und die gezogene Nutzungen herausgeben (§ 346 Abs. 1 BGB). Sobald die gezogenen Nutzungen nicht herausgegeben werden können, ist Wertersatz zu leisten. Die Rückgabe der Software vollzieht sich zunächst durch die Rückgabe der 302 erhaltenen Softwarekopien, soweit sie auf Datenträgern noch vorhanden sind. Gegebenenfalls muss von der installierten Software eine weitere Kopie gefertigt werden. Dazu muss der Softwareersteller seinem Kunden neue Datenträger überlassen. Auch die Kosten für die Erstellung der Kopie muss der Softwareersteller übernehmen3. Der Unternehmer kann auf diese Rückgabe auch verzichten, wenn er ohnehin Softwarekopien hat. Wichtig für ihn ist in aller Regel, dass der Kunde alle bei ihm verbliebene Kopien der Software sowohl auf seinem Datenverarbeitungssystem als auch auf den Datensicherungsmedien löscht. Dazu ist der Kunde auch verpflichtet. Es ist Teil der Rückgabeverpflichtung4. Eventuell gezogene Nutzungen müssen in aller Regel in Geld entschädigt 303 werden. Insoweit ist auf die bisherige Rechtsprechung zur Nutzungsentschädigung zurückzugreifen. In Literatur und Rechtsprechung wird in aller Regel bei der Berechnung des Wertverlustes davon ausgegangen, dass die Nutzungszeit von Software drei bis fünf Jahre beträgt. Die Nutzungsentschädigung wird dann mit Hilfe linearer oder degressiver Abschreibungen berechnet5. Dabei wird im Wesentlichen auf steuerliche Vorschriften zurückgegriffen. Die erscheint jedoch nicht zweckmäßig, da die steuerlichen Abschreibungsvorschriften nur in sehr typisierten Umfang die tatsächlichen Nutzungsvorteile des Kunden wiedergeben und neben sachlichem auch steuerpolitischen Hintergrund haben. Es empfiehlt sich daher, die übliche Nutzungsdauer vergleichbarer Software heranzuziehen, die je nach Komplexität deutlich höher als drei bis fünf Jahre liegt, und daraus die Nut1 Palandt/Grüneberg, § 323 BGB Rz. 29. 2 Palandt/Grüneberg, § 323 BGB Rz. 29. 3 Teilweise a.A. von Gravenreuth, BB 1989, 1925 ff., der auch weitere Fallkonstellationen untersucht. 4 Marly, Praxishandbuch Softwarerecht, Rz. 1238; Junker/Benecke, Computerrecht, Rz. 351. 5 OLG München v. 16.1.1987 – 23 U 4988/86, CR 1989, 288 (5 Jahre linear); LG München I v. 14.1.1988 – 7 O 12497/87, Beil. Nr. 11 zu BB 1989, S. 8 (4 Jahre degressiv); ähnlich Junker/Benecke, Computerrecht, Rz. 334 (linear).

Redeker

403

D Rz. 304

Verträge

zungsentschädigung abzuleiten1. Dies kann wie eine lineare Abschreibung erfolgen2. Möglicherweise kann man aber auch den höheren Wertverlust im ersten Jahr berücksichtigen3. Da es aber um den Wert der Nutzungen und nicht um Schadensersatz geht, dürfte die lineare Berechnung vorzuziehen sein. 304

Soweit die Software trotz Abnahme nie produktiv eingesetzt wurde, wird man kaum von Nutzungsvorteilen ausgehen können. Soweit die Software wegen der Mängel nur einen begrenzten Nutzungsumfang hat, muss man fiktiv von einer Minderung des Wertes der Software wegen der Mängel ausgehen und von dem dann verminderten Entgelt die Nutzungsentschädigung berechnen.

305

Eine Nutzungsentschädigung kann längstens für den Nutzungszeitraum berechnet werden, der der Berechnung der Nutzungsentschädigung zugrunde gelegt wird. Anderenfalls würde der Unternehmer im Falle der Nutzungsentschädigung mehr erhalten, als ihm als Vergütung zusteht. Dieses Ergebnis kann nicht richtig sein.

306

Die weitere Nutzung der Software nach einer Rücktrittserklärung verwirkt das Rücktrittsrecht nicht und stellt auch keinen Verzicht auf den Rücktritt dar. Dies ergibt sich schon daraus, dass für die Nutzung auch nach der Rücktrittserklärung weiterhin Nutzungsentschädigung zu zahlen ist und gilt insbesondere dann, wenn der Rücktritt gerichtlich durchgesetzt werden muss und die entsprechenden Schritte zu seiner Durchsetzung in angemessenem zeitlichem Umfang erfolgen4.

307

Schwierig ist die Rückabwicklung anderer Vorteile. Insbesondere bei der Herstellung von Individualsoftware werden während der Projektdauer Informationen ausgetauscht, die auch Betriebsgeheimnisse darstellen können. Es kann auch um neue Kenntnisse und Fähigkeiten beider Seiten gehen, die im Zusammenhang mit dem Projekt gewonnen wurde. Diese Kenntnisse und Fähigkeiten können nach einem Rücktritt nicht zurückgegeben werden. Im Hinblick auf Betriebsgeheimnisse kann ein Verwertungsverbot vereinbart werden. Unabhängig davon lassen sich auch Betriebsgeheimnisse schlechterdings nicht zurückgegeben. Auch die Wertersatzregelung des § 346 Abs. 1 BGB passt nicht. Praktische Lösungen im Einzelfall sind zu erarbeiten, die den Gedanken des § 242 BGB heranziehen5. Wird freilich nicht durch entsprechende Vereinbarungen Vorsorge getroffen worden, kann das Fehlen 1 So auch BGH v. 26.6.1991 – VIII ZR 198/90, CR 1992, 147; LG Tübingen v. 19.10.1992 – 1 S 413/91, CR 1993, 772 (LS) (6 Jahre). 2 So auch BGH v. 26.6.1991 – VIII ZR 198/90, CR 1992, 147; LG Tübingen v. 19.10.1992 – 1 S 413/91, CR 1993, 772 (LS). 3 So Schneider, Handbuch des EDV-Rechts, P Rz. 58. 4 OLG München v. 16.1.1987 – 23 U 4988/86, CR 1989, 288; OLG Karlsruhe v. 12.1.1995 – 11 U 61/93, in: Zahrnt, ECR OLG 199; OLG Köln v. 18.6.1999 – 19 U 216/98, OLG-Report 1999, 362. 5 Zum Expertensystem vgl. Koch/Schnupp, CR 1989, 393 ff.

404

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 310 D

solche Regelungen nicht im Rahmen der Rückabwicklung nach einem Rücktritt über ergänzende Vertragsauslegung oder die weite Interpretation gesetzlicher Vorschriften kompensiert werden. Auch die Minderung stellt ein Gestaltungsrecht dar. Besondere Probleme 308 ergeben sich nicht. Die Vergütung ist gemäß § 638 Abs. 3 BGB in dem Verhältnis herabzusetzen, in welchem zur Zeit des Vertragesschlusses der Wert des Werks in mangelfreiem Zustand zu dem wirklichen Wert gestanden hat. Hier muss ggf. geschätzt werden (§ 638 Abs. 3 Satz 2 BGB). In der Rechtsprechung wird entgegen dem Wortlaut auch von § 472 Abs. 1 BGB a.F. eine Minderung teilweise sogar durch Abzug von Reparaturkosten berechnet1. Diese können aber allenfalls Ansatzpunkt für eine Schätzung sein2. Auch dies dürfte aber im Softwarebereich selten richtig sein, jedenfalls was die Reparaturkosten durch einen Dritten betreffen. Diese sind wegen der für Außenstehende schwer nachzuvollziehenden Strukturen des Quellcodes in aller Regel exorbitant hoch und stehen in keinerlei Relation zu den anteiligen Kosten bei einer kompletten Neuprogrammierung. Sie können daher kein vernünftiger Ansatz für die Bemessung einer Wertminderung sein. Dies können allenfalls die von einem Dritten kaum zu schätzenden Kosten der Reparatur durch den Softwareersteller sein. Minderung und Rücktritt sind – wie erwähnt – Gestaltungsrechte. Dies 309 bedeutet, dass der Gläubiger nach ihrer Ausübung an seine Wahl gebunden ist. Er kann anders als teilweise im früheren Recht nicht mehr von der Minderung zum Wandlung und umgekehrt wechseln3. Evtl. unerwünschten Folgen dieser Rechtslage kann in begrenztem Umfang durch die Ausgestaltung von Schadensersatzansprüchen entgegengewirkt werden4. Dennoch sollte sich der Kunde vor Ausübung der Gestaltungsrechte sorgfältig überlegen, welches Recht für ihn günstiger ist. Er ist an seine Wahl gebunden. ff) Schadensersatz Ein letztes Recht des Kunden nach fehlgeschlagener Nacherfüllung ist das 310 Recht, Schadensersatz zu verlangen. Schadensersatzansprüche setzen nach § 280 BGB Pflichtverletzungen voraus, und zwar zu vertretende Pflichtverletzungen. Hat der Schuldner die Pflichtverletzung nicht zu vertreten, haftet er nicht. Die Herstellung mangelbehafteter Software dürfte in aller Regel eine schuldhafte Pflichtverletzung darstellen5. Hinsichtlich des Verschuldens kann sich der Hersteller exkulpieren, aber nur dann, wenn er sehr umfangreich darlegt, dass er eine umfangreiche Qualitätssicherung durchgeführt hat, die allen technischen Voraussetzungen entspricht. Von einer 1 LG Düsseldorf v. 16.12.1986 – 8 O 347/84, CR 1988, 133 (134). 2 BGH v. 17.12.1996 – X ZR 76/94, NJW-RR 1997, 688 (689); Staudinger/Peters/Jacobys, § 634 BGB Rz. 115. 3 Palandt/Sprau, § 634 BGB Rz. 5; Derleder, NJW 2003, 998 (1003). 4 Derleder, NJW 2003, 998 ff. 5 Lorenz, NJW 2007, 1 f.

Redeker

405

D Rz. 311

Verträge

solchen Exkulpation wird man selten ausgehen können. Möglich ist sie allenfalls dann, wenn der Hersteller Qualitätssicherung nicht nur durchführt, sondern ihre Anwendung im konkreten Fall auch ausreichend dokumentiert. In diesem Zusammenhang spielen insbesondere Standardisierungen im Hinblick auf Verfahrensabläufe (DIN 9000 etc.) eine wichtige Rolle. Zu den Pflichten des Auftragnehmers gehört selbstverständlich eine Produktkontrolle vor Ablieferung, zu der z.B. auch eine Kontrolle auf Virenbefall gehört1. 311

Ob man beim Verschuldensmaßstab auch die Wirtschaftlichkeit in dem Sinn berücksichtigen muss, dass unwirtschaftliche Maßnahmen des Herstellers unterbleiben können, ist zweifelhaft. Sicher ist nur, dass Maßnahmen unterbleiben können, die dann, wenn sie alle Hersteller treffen, die Software auch unter Berücksichtigung der möglicherweise eintretenden Schäden unvertretbar teuer machen. Insoweit ist auf einen objektiven Maßstab abzustellen. Auf die Kosten für den konkreten Softwareersteller kommt es nicht an. Drohen Körper- und Gesundheitsschäden, wird man auch einen solch wirtschaftlichen Maßstab ohnehin nicht anwenden können. Ungeeignet ist jedenfalls die sog. Leaned-Hand-Theorie2. Man kann aber davon ausgehen, dass die erwähnten Standards und Normen auch die Kosten der vorgeschriebenen Maßnahmen berücksichtigen und muss daher dann, wenn man sie als Maßstab gelten lässt, nicht noch zusätzlich wirtschaftliche Faktoren berücksichtigen. Darüber hinaus gelten wirtschaftliche Faktoren dann nicht, wenn der Softwareersteller bestimmte Leistungen vertraglich übernommen hat.

312

Festzuhalten ist, dass prozessual der Kunde die Pflichtverletzung und der Hersteller das mangelnde Verschulden darlegen und beweisen muss (§ 280 Abs. 1 Satz 2 BGB)3.

313

Allerdings gibt es für spezielle Schadensersatzansprüche besondere Voraussetzungen.

314

Die erste Fallgruppe ist die der Verzögerungsschäden. Hier gibt es dem Wortlaut des Gesetzes Schadensersatzansprüche nur bei Verzug (§ 280 Abs. 2 BGB), also in der Regel erst nach einer vergeblichen Fristsetzung. Nur dann, wenn ein konkreter oder berechenbarer Liefertermin vereinbart ist, tritt Verzug mit Überschreiten dieses Termins ein (§ 286 BGB). Dies müsste eigentlich auch für eine zunächst mangelhafte Lieferung gelten. Erst ab Verzug dürfte es Schadensersatzansprüche für Verzögerungsschäden (z.B. Nutzungsausfall) geben4. Dies gilt für Verzögerungsschäden entgegen einer Literaturmeinung5 auch dann, wenn zunächst nur eine mangelhafte und erst verspätet 1 2 3 4 5

Schneider/Günther, CR 1997, 389 (394). A.A. Heussen, CR 2004, 1 (9). Erman/Westermann, § 280 BGB Rz. 26. Oechsler, NJW 2004, 1825 (1828). Lorenz, NJW 2002, 2497 (2502); Palandt/Grüneberg, § 280 BGB Rz. 18; Ebert, NJW 2004, 1761 (1762); Tiedtke/Schmitt, BB 2005, 615 (619).

406

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 319 D

eine mangelfreie Sache geliefert wurde1. Verzögerungsschäden können auch neben einem Rücktritt oder einer Minderung geltend gemacht werden. Weitere Voraussetzungen gelten auch dann, wenn der Kunde durch den 315 Schadensersatzanspruch so gestellt werden will, als wäre der Vertrag erfüllt worden, er also Schadensersatz anstelle der Erfüllung haben will (sog. Schadensersatz statt der Leistung). Ein solcher Anspruch setzt eine Fristsetzung voraus (§ 281 Abs. 1 Satz 1 316 BGB). Erst dann, wenn trotz Ablauf der Frist keine erfolgreiche Nacherfüllung durchgeführt wird, gibt es Schadensersatz statt Leistung (§§ 634 Nr. 4, 280, 281 BGB). Die Fristsetzung ist in den Fällen entbehrlich, in denen sie auch bei Rücktritt oder Minderung entbehrlich ist (vgl. Rz. 293). Dieser Schadensersatzanspruch soll nur in den Fällen gegeben sein, in denen es auch ein Rücktrittsrecht gibt. Er setzt freilich Vertretenmüssen voraus und gibt als Rechtsfolge mehr als das Rücktrittsrecht, weil er auch den entgangenen Gewinn oder höhere Kosten eines Deckungsgeschäfts umfasst. Er besteht auch neben dem Rücktrittsrecht. Wie bisher kann man zwischen kleinem und großem Schadensersatzanspruch wählen. Letzterer scheidet aus, wenn die Pflichtverletzung, die diesem Anspruch zugrunde liegt, unerheblich ist (§ 281 Abs. 1 Satz 3 BGB). Wichtig ist auch die Vorschrift des § 284 BGB. Dieser gibt an Stelle des 317 Schadensersatzes statt Leistung einen Anspruch auf den Ersatz vergeblicher Aufwendungen, die im Hinblick auf den fehlgeschlagenen Erwerbsvorgang getätigt wurden, ohne dass weitere schadensersatzrechtliche Voraussetzungen vorliegen müssen. Zu diesen Aufwendungen können auch Erwerbskosten gehören, nicht aber der entgangene Gewinn. Die Vorschrift ist auch im geschäftlichen Bereich anwendbar. Neben einem Anspruch nach § 284 BGB kann zwar ein Anspruch auf Schadensersatz statt Leistung nicht verfolgt werden, wohl aber Schadensersatzansprüche für Schäden, die auch bei erfolgreicher Nacherfüllung angefallen wären2. Dies bedeutet, dass Kosten eines Deckungsgeschäfts oder entgangener Gewinn nicht geltend gemacht werden können, wenn man nach § 284 vorgeht, wohl aber auf Grund der Mängel entstandene Schäden an anderen Sachen des Erwerbers. Bei Softwareerstellungsverträgen kann man hier verschiedene Fallgruppen 318 unterscheiden. Wird eine Software verspätet mangelfrei geliefert oder wird die Nacherfüllung verzögert, können allein durch die Verspätung Schäden entstehen. Diese müssen nur ersetzt werden, wenn Verzug vorliegt (vgl. dazu Rz. 314). Darüber hinaus kann das Geschäft scheitern, weil der Kunde die nacherfüllte mangelhafte Software nicht akzeptiert oder ihm die Nacherfüllung zu lange dauert. Dann kann der Kunde vom Vertrag zurücktreten oder den großen Schadensersatz verlangen. Er kann höhere Kosten der Ersatzbeschaf1 Ebert, NJW 2004, 1761 (1762). 2 Lorenz, NJW 2004, 26 (27 f.); Reim, NJW 2003, 3662 (3667).

Redeker

407

319

D Rz. 320

Verträge

fung oder entgangenen Gewinn als Schaden nach § 281 BGB geltend machen oder auch nur seine vergeblichen Aufwendungen nach § 284 BGB ersetzt verlangen. Darüber hinaus kann der Kunde auch vergebliche Aufwendungen gemacht haben, weil er versucht hat, die Software bei sich einzusetzen. Sind diese im Hinblick auf weitere Erwerbe nutzlos gewesen, gehören auch diese zum Schaden. 320

Die mangelhafte Software kann auch Schäden an anderen Rechtsgütern und Vermögensschäden beim Kunden verursachen. Diesbezüglich gibt es ohne weiteres einen Anspruch auf Schadensersatz aus § 280 BGB1. Wie sich der Schadensersatz im Einzelnen berechnet, ergibt sich aus den allgemeinen Regeln (§§ 249 ff. BGB).

321

Im Einzelnen gibt es umfangreiche Streitigkeiten, welche Schäden unter welchen Voraussetzungen geltend gemacht werden können2. Man muss z.B. beachten, dass Kosten einer Selbstvornahme, die nach § 637 BGB nicht ersatzfähig sind, auch keine Schadenspositionen sein können. Nach dem BGH steht dem Kunden auch kein Anspruch auf Ersatz der Kosten zu, die der Hersteller deswegen erspart hat, weil er nicht mehr nachbessern muss3.

322

Kommt es zu Körper- oder Gesundheitsschäden, was möglicherweise bei spezieller Software denkbar ist, kommt auch bei rein vertraglichen Ansprüchen Schmerzensgeld in Betracht (§ 243 Abs. 2 BGB).

323

Der Kunde muss seinerseits im Rahmen des § 254 BGB Vorkehrungen zur Schadensbekämpfung treffen. Dazu gehört jedenfalls eine regelmäßige Datensicherung4. Allerdings muss der Unternehmer bei Installation die Funktionsfähigkeit der Datensicherungsroutine fachgemäß überprüfen5.

324

Es ist sogar ein Fall vorgekommen, in dem der Unternehmer ein Datenverlust für endgültig erklärt hat, obwohl dies nicht stimmte. Schon diese Erklärung kann Schadensersatzansprüche auslösen6.

325

Zuletzt sei darauf hingewiesen, dass dann, wenn schon bei Vertragsschluss keine mangelfreie Software hergestellt werden kann, ein Fall der anfängli-

1 So auch Lorenz, NJW 2002, 2497 (2499 ff.). 2 Umfassend zum Streitstand: Tiedtke/Schmitt, BB 2005, 615. 3 BGH v. 23.2.2005 – VIII ZR 100/04, MDR 2005, 673 = NJW 2005, 1348; kritisch dazu Lorenz, NJW 2005, 1321; Herresthal/Riem, NJW 2005, 1457; a.A. auch Oechsler, NJW 2004, 1825 (1827 f.). 4 OLG Karlsruhe v. 20.12.1995 – 10 U 123/95, CR 1996, 348 = NJW-RR 1997, 554; LG Kleve v. 23.3.1990 – 3 O 356/89, Beil. Nr. 10 zu BB 1992, S. 4; OLG Hamm v. 1.12.2003 – 13 U 133/03, CR 2004, 654; Schneider, Handbuch des EDV-Rechts, G Rz. 108. 5 BGH v. 2.7.1996 – X ZR 64/94, CR 1996, 663 = MDR 1997, 26 = NJW 1996, 2924; OLG Köln v. 2.2.1996 – 19 U 223/95, CR 1996, 407 = NJW-RR 1997, 558; einschränkend OLG Köln v. 22.4.1994 – 19 U 253/93, NJW RR-1994, 1262. 6 BGH v. 11.4.2000 – X ZR 19/98, CR 2000, 424.

408

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 331 D

chen Unmöglichkeit vorliegt. Eventuelle Schadensersatzansprüche richten sich dann nach § 311a Abs. 2 BGB. gg) Verjährung (1) Herstellung von Software Die Verjährung von Mängelansprüchen in Softwareerstellungsverträgen ist 326 differenziert geregelt. Grundlage der Verjährung werkvertraglicher Mängelansprüche ist § 634a BGB. Bei seiner Anwendung muss man zwischen der Herstellung von Software und der Bearbeitung von von Dritten gelieferter Software unterscheiden. Ein Vertrag über die Lieferung eigener, bearbeiteter Software führt nach hier vertretener Ansicht zur Anwendung des § 651 BGB (vgl. Rz. 85) und muss daher nicht betrachtet werden (vgl. dazu unten Rz. 362 ff.). Der erste zu betrachtende Fall ist der der Herstellung von Software. In die- 327 sem Fall liegen die Voraussetzungen des § 634a Abs. 1 Nr. 1 und 2 BGB nicht vor, da Software keine Sache ist. Für die Herstellung von Software gilt in diesem Fall die Regelung des § 634a Abs. 1 Nr. 3. Es gilt die regelmäßige Verjährungsfrist des § 195 BGB. Diese Verjährungsfrist beträgt drei Jahre. Diese Verjährungsfrist beginnt allerdings gemäß § 199 Abs. 1 BGB dann, wenn der Anspruch entstanden ist und der Gläubiger von den den Anspruch begründenden Umständen und der Person des Schuldners Kenntnis erlangt oder ohne grobe Fahrlässigkeit erlangen müsste. Für alle Ansprüche außer den Schadensersatzansprüchen gibt es dann eine 328 weitere Begrenzung auf zehn Jahre ohne Rücksicht auf die Kenntnis oder grob fahrlässige Unkenntnis und zwar von zehn Jahren von ihrer Entstehung an. Für Schadensersatzansprüche gibt es hier weitere Differenzierungen (§ 199 Abs. 2 und 3 BGB). Maximalfrist sind zehn Jahre ab Entstehung bzw. 30 Jahre von der Begehung der Handlung der Pflichtverletzung oder dem sonstigen den Schaden auslösenden Ereignis an. Für Mängelansprüche aus Werkverträgen heißt dies, dass üblicherweise die 329 Verjährungsfrist drei Jahre beträgt, allerdings erst mit Kenntnis des Mangels beginnt, weil der Kunde vorher von den an sich schon gegebenen Sachmängelansprüchen keine Kenntnis hatte. Eine Ausnahme gilt nur dann, wenn der Kunde grob fahrlässig den Sachmangel übersieht. Dies dürften ausgesprochene Ausnahmefälle sein. Unabhängig davon gibt es eine Höchstgrenze von zehn Jahren. Damit verjähren alle wesentlichen Ansprüche in zehn Jahren ab Abnahme. Zu diesem Zeitpunkt verjähren die Gewährleistungsansprüche unabhängig von der Kenntnis.

330

Bei Schadensersatzansprüchen ist diese Regelung differenzierter. Auch hier dürfte zwar in der Regel die Zehnjahresfrist eingreifen. Sollten aber Spätschäden eintreten, gilt eine Frist von 30 Jahren. Diese gilt gemäß § 199 Abs. 2 BGB auch bei Schadensersatzansprüchen wegen Verletzung des Le-

331

Redeker

409

D Rz. 332

Verträge

bens, des Körpers, der Gesundheit und der Freiheit, also eher bei Ausnahmefällen im Bereich des Softwarerechts. 332

Alles in allem ist die Verjährungsfrist für Schadensersatzansprüche ausgesprochen lang. Auch die allgemeine Verjährungsfrist für Mängelansprüche ist deutlich länger als im Kaufrecht. Diese Tatsache dürfte auch der Haupthintergrund für die Meinung sein, den Softwareerstellungsvertrag unter § 651 BGB fallen zu lassen.

333

Folgt man dem hier vertretenen Ansatz der mittlerweile wohl herrschenden Meinung und wendet § 651 BGB weitgehend nicht an (vgl. Rz. 67 ff.), kann man aber den dargestellten Verjährungsfristen nicht ausweichen. Einzelne Stimmen in der Literatur wollen hier eine Verkürzung auf eine Zweijahresfrist ab Abnahme gemäß § 634a Abs. 1 Nr. 1 BGB erreichen1. Argumentationsbasis ist teilweise, dass die Herstellung von Software eine Bearbeitung der Sache, nämlich der Hardware ist. Diese Argumentation verfängt aber nicht. Die Softwareherstellung ist keine Bearbeitung der Hardware, sondern die Herstellung eines eigenständigen Produktes.

334

Der Gesetzgeber hat die lange Verjährungsfrist – auch bei Software – auch aus zwei Gründen eingeführt.

335

Zum einen sagte seine Erfahrung, dass bei nicht körperlichen Gegenständen Mängel erst sehr spät entdeckt werden. Dieses Argument dürfte im Hinblick auf die Zweijahresfrist für Software nicht sehr relevant sein. Der zweite Punkt war aber, dass oft eine Abgrenzung zwischen Werkverträgen und Dienstverträgen schwierig ist und im Dienstvertragsrecht seit je her die regelmäßige Verjährungsfrist greift, so dass dies auch für Werkverträge gelten soll.

336

Die Abgrenzungsschwierigkeiten bestehen in der Tat. Auch im Softwarerecht waren und sind sie Gegenstand vieler Diskussionen in der Literatur und der Rechtsprechung (vgl. Rz. 56 ff.). Insoweit greift dieses gesetzgeberische Argument ein2. Ob das gesetzgeberische Argument allerdings im Hinblick auf verschuldensunabhängige Gewährleistungsansprüche wirklich zutreffend ist, erscheint zweifelhaft3. Der Gesetzgeber hat sich aber so entschieden. Mit den Verjährungsfristen wird man leben müssen4 und kann sie auch nicht etwa im Wege teleologischer Reduktion verkürzen5.

337

Es stellt sich ferner die Frage, ob man die gesetzliche Verjährungsregelung abbedingen kann. Der Kunde kann dies sowohl individualvertraglich als 1 So auch Marly, Praxishandbuch Softwarerecht, Rz. 1337, aber von einer anderen Systematik aus. 2 Redeker, ITRB 2002, 119 (121). 3 Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 257. 4 I.E. ebenso Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 257 ff. 5 A.A. Lenhard, Vertragstypologie von Softwareüberlassungsverträgen, 2006, S. 178 ff.

410

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 342 D

auch durch AGB unproblematisch. Regelungen zu seinen Lasten kann er auch in AGB aufnehmen. Problematisch ist die Frage dann, wenn dies der Softwareersteller tun möchte. In individuellen Verträgen kann dies auch auf Veranlassung des Herstellers geschehen. Wichtig ist, dass die Regelung tatsächlich individuell ausgehandelt ist. Fraglich ist aber, ob insoweit eine Verkürzung durch AGB vorgenommen werden kann. Hier ist zunächst zu beachten, dass gemäß § 309 Nr. 8b ff. BGB die Verkürzung der Verjährung in AGB unter einem Jahr verboten ist. Diese Regelung wird auch im Unternehmensverkehr anzuwenden sein1.

338

Angesichts der Verjährungsfrist von zehn Jahren stellt sich aber die Frage, 339 ob eine Verkürzung z.B. auf zwei Jahre ab Abnahme möglich ist. Angesichts der klaren gesetzlichen Regelung, dass die Verjährung nicht ab Abnahme, sondern kenntnisabhängig eintreten soll, ist eine solche Regelung in AGB aber unwirksam. § 309 Nr. 8b ff. BGB erlaubt nur eine Verkürzung der Verjährungsfrist, nicht aber eine Vorverlagerung des Verjährungsbeginns. Diese ist zwar dennoch grundsätzlich möglich, aber nur, wenn sie in allen Einzelfällen die Regeln des § 309 Nr. 8b ff. einhält2. Praktisch scheidet sie daher meist aus. Daher ist es nur möglich, die Verjährungsfrist ab Kenntnis zu verkürzen und vorzusehen, dass Mängelansprüche in einem Jahr ab Kenntnis verjähren. Eine Regelung, die als Verjährungsbeginn die Abnahme festlegt, ist dagegen unzulässig3. Eine mögliche Regelung verkürzt daher zwar in Einzelfällen die Verjährung. Rein praktisch dürfte sich aus ihr aber nur begrenzt etwas gewinnen lassen, da in aller Regel Debatten über den Mangel sofort beginnen und durch die Auseinandersetzung darüber ja die Verjährung gehemmt wird. Insgesamt wird die Verjährungsfrist in AGB des Softwareerstellers substantiell nur begrenzt zu verkürzen sein.

340

Rücktritt und Minderung stellen im Übrigen keine Ansprüche, sondern Ge- 341 staltungsrechte dar. Sie verjähren daher nicht. Durch §§ 634 Abs. 4 und 5, 218 BGB wird aber sichergestellt, dass sie faktisch auch verjähren. Ist nämlich der Nacherfüllungsanspruch verjährt oder wäre er verjährt, wenn er noch durchsetzbar wäre, kann der Unternehmer die Wirksamkeit von Rücktrittsoder Minderungserklärung durch einen Widerspruch verhindern. (2) Bearbeitung von Software Soweit es um die Bearbeitung von Software geht, die von einem dritten Hersteller geliefert worden ist, stellt sich die Frage, ob hier die Regelung des § 634a Abs. 1 Nr. 1 BGB Anwendung finden soll.

1 MünchKomm/Wurmnest, § 309 Nr. 8b Rz. 76; Schumacher, MDR 2002, 973 (980). 2 Ulmer/Brandner/Hensen/Christensen, § 309 Nr. 8 Rz. 102. 3 Ulmer, ITRB 2003, 162 (163 f.).

Redeker

411

342

D Rz. 343

Verträge

343

Danach gibt es eine Verjährung von zwei Jahren ab Abnahme (§ 634a Abs. 2 BGB) dann, wenn das Werk in der Veränderung einer Sache besteht. Dass die Bearbeitung von Software eine Veränderung ist, ist klar. Ob es sich um die Veränderung einer Sache handelt, könnte zweifelhaft sein. Immerhin wird Software nach hier vertretener Meinung nicht als eine Sache betrachtet (vgl. Rz. 71 f.).

344

Allerdings wird hier die Auffassung vertreten, dass dann, wenn die Software hergestellt wird und die Rechtsübertragung an den Kunden nur in dem Umfang erfolgt wie bei der Lieferung von Standardsoftware, § 651 BGB analog Anwendung finden soll (vgl. Rz. 78). Konsequenterweise muss man auch die Software im Rahmen des § 634a Abs. 1 Nr. 1 BGB als Sache betrachten, soweit es sich um Standardsoftware oder -pakete handelt, die mit einem einfachen Nutzungsrecht geliefert werden. Demgemäß wäre auf die Bearbeitung von Standardsoftware die Vorschrift des § 634a Abs. 1 Nr. 1 BGB anzuwenden. Die Sachmängelansprüche verjähren binnen zwei Jahren ab Abnahme.

345

Diese Frist kann in AGB auch des Softwareerstellers auf ein Jahr verkürzt werden. hh) Garantien

346

Nach § 639 BGB kann sich der Unternehmer auf eine Vereinbarung, durch welche die Rechte des Bestellers wegen eines Mangels ausgeschlossen oder beschränkt werden, nicht berufen, wenn er eine Garantie für die Beschaffenheit des Werks übernommen hat.

347

Nach dem Text bedeutet dies, dass dann, wenn eine Beschaffenheitsgarantie übernommen worden ist, auch ein individuell vereinbarter Haftungsausschluss nicht möglich ist. Freilich ist damit noch nicht geklärt, ob eine im konkreten Fall gegebene Garantie auch die Übernahme von Haftung ohne Verschulden bedeutet oder nicht. Dies ist durch Auslegung im Einzelfall zu klären. Ob eine solche Auslegung naheliegt1 oder die Auslegung offen ist2, wird in der Literatur unterschiedlich gesehen. In der EDV-rechtlichen Literatur wird sogar davon ausgegangen, dass eine Garantieerklärung immer zu einer verschuldensunabhängigen Haftung führt3. Dem kann so nicht gefolgt werden. Die Diskussion zwingt aber zur Vorsicht sowohl bei der Vertragsformulierung als auch bei der – möglichen – Annahme stillschweigender Garantien. Die Gerichte sind hier in Einzelfällen aber zugunsten des Kunden großzügig4.

1 Für Erman/Schwenker, § 639 BGB Rz. 8 ist die verschuldensunabhängige Haftung Definitionsmerkmal der Garantie. 2 So Staudinger/Peters/Jacoby, § 633 BGB Rz. 171. 3 Junker/Benecke, Computerrecht, Rz. 304. 4 Vgl. LG Kleve v. 27.8.2004 – 5 S 57/04, NJW-RR 2005, 422.

412

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 352 D

Die Formulierung des § 639 BGB ist noch weitergehend als in der viel dis- 348 kutierten Vorschrift der §§ 443 Abs. 1, 444 BGB, wo auf die Garantiebedingungen Bezug genommen worden ist. Eine § 443 BGB entsprechende Regelung fehlt im Werkvertragsrecht. Unter diesen Umständen ist es sicher sinnvoll, mit Garantien für die Be- 349 schaffenheit eines Werks ausgesprochen vorsichtig zu sein1. Allerdings hat der Gesetzgeber durch eine Novellierung den § 639 BGB dahingehend geändert2, dass der Haftungsausschluss nur gilt, soweit der Hersteller eine Garantie für die Beschaffenheit des Werks übernommen hat. Damit wollte der Gesetzgeber – ebenso mit der parallelen Änderung in § 444 BGB – erreichen, dass die Regelungen, die in der Garantie selbst enthalten sind, jedenfalls auch die Haftung begrenzen können. Aufgrund dieser Novellierung des Gesetzgebers wird man davon ausgehen können, dass Garantiebedingungen und Haftungsbegrenzungen, die in der Garantie selbst enthalten sind, die Haftung tatsächlich begrenzen. Es ist nur nicht möglich, eine Garantie zu geben und diese durch eine Haftungsbegrenzung im Rahmenvertrag oder gar in AGB zu begrenzen. Dies verbietet sich auch auf der Grundlage der Rechtsfigur des widersprüchlichen Verhaltens. Wer eine Garantie geben will, soll im Rahmen der Garantieerklärung erklären, in welchem Umfang und mit welchen Konsequenzen er die Garantie übernimmt. Er kann nicht einerseits eine Garantie erklären und diese andererseits versteckt einschränken. Nach der Rechtsprechung des BGH gilt dies im Übrigen nicht nur für Garantien, sondern auch für konkrete Beschaffenheitsvereinbarungen. Auch diese setzen sich gegenüber generellen Gewährleistungsausschlüssen durch und zwar auch dann, wenn sie individuell vereinbart sind3. Unter diesen Umständen ist eine Garantie möglich. Es muss aber davor gewarnt werden, die Garantie einfach mit dem Satz „Wir garantieren folgende Eigenschaften …“ zu erteilen. Dies kann schwerwiegende Folgen haben, insbesondere greifen sämtliche Haftungsausschlüsse oder Verjährungsverkürzungen nicht ein. Der Umfang der Garantie muss von vornherein in der Garantieerklärung beschränkt werden.

350

ii) Insbesondere: Rechtsmängel Wirklich neu in den Regelungen der Schuldrechtsreform ist die Gleichstellung der Rechtsmängel mit Sachmängeln. Dies ergibt sich für den Werkvertrag aus § 633 Abs. 1 BGB. Gerade im Bereich der Software können Rechtsmängel von großer Bedeutung sein.

351

Dazu ist zunächst zu klären, was überhaupt Rechtsmängel sind. Sachlich 352 geht es um die Frage, dass der Softwareersteller dem Kunden Nutzungsrechte einräumt, die er gar nicht einräumen kann. Da es dabei um nicht übertra1 Ähnlich Hengstler/Staffelbach, ITRB 2012, 21. 2 Art. 1 Gesetz v. 2.12.2004 (BGBl. I S. 3102). 3 BGH v. 29.11.2006 – VIII ZR 92/06, BB 2007, 573.

Redeker

413

D Rz. 353

Verträge

gene urheberrechtliche Rechtspositionen geht, gibt es keinen gutgläubigen Erwerb. Der Kunde erhält die ihm geschuldeten Nutzungsrechte vom Hersteller nicht. 353

Es kann dabei sein, dass ein Großteil des gelieferten Produkts schwarzkopiert ist und damit letztendlich der Kunde überhaupt keine Rechte erhält. Daraus könnte man den Schluss ziehen, dass überhaupt kein Rechtsmangel vorliegt. Schließlich erhielte der Kunde letztendlich gar kein Recht an der Software. Es liege ein Fall der Nichterfüllung vor. Rechtsmängelhaftung könne erst dann eingreifen, wenn dem Kunden irgendetwas übertragen werde, wenn auch nicht in geschuldetem Umfang.

354

Dies ist jedoch nicht richtig. Der Erwerber erhält in aller Regel ja eine tatsächliche Nutzungsmöglichkeit, die er auch nutzt, bis ihm das Problem bewusst wird – in aller Regel durch Ansprüche, die ein Dritter ihm gegenüber stellt. Damit erlangt der Erwerber wirtschaftlich durchaus etwas Bedeutendes. Fehlt dafür die rechtliche Befugnis, entsteht daraus ein Rechtsmangel. Es liegt kein Fall der Nichterfüllung, sondern ein Fall der Schlechterfüllung vor. Auf diesen Fall sind die Regeln über Rechtsmängel anwendbar1.

355

Im Bereich der Softwareerstellung dürfte auch die erstgenannte Meinung im Übrigen häufig zur Anwendung der Rechtsmängelhaftung kommen. Dort sind Fälle, in denen der Kunde überhaupt keine Rechte erhält, eher selten, weil ein Teil der überlassenen Software ja immer vom Lieferanten hergestellt worden ist.

356

Solche Rechtsmängel werden nun vom Gesetz den Sachmängeln gleichgestellt. Damit ergeben sich für die Kunden die gleichen Rechte auch wie beim Sachmangel.

357

Durch diese neue Regelung können freilich auch im Werkvertragsrecht Verjährungsprobleme auftreten. Bei der Softwareerstellung ist der – eher seltene – Fall denkbar, dass elf Jahre nach Software-Überlassung ein Dritter Unterlassungsansprüche geltend macht. Diese können dann noch bestehen, während Gewährleistungsansprüche verjährt sind. Diese Rechtslage muss aber – wie bei unerkannten Sachmängeln – hingenommen und kann allenfalls durch vertragliche Regelung abbedungen werden2.

358

Schwerwiegender können solche Probleme bei der Softwarebearbeitung sein, weil dort die Verjährung bereits zwei Jahre nach Abnahme eintritt, also u.U. schon abläuft, bevor Kenntnis von den Rechtsmängeln besteht. Umgekehrt sind die Ansprüche des Dritten ja insbesondere auf Unterlassung zeitlich unbefristet und können von diesem dauernd geltend gemacht werden, so dass hier Probleme für den Kunden entstehen können.

1 So auch Eidenmüller, NJW 2002, 1625 (1626); Marly, Praxishandbuch Softwarerecht, Rz. 1177; Glossner, in: Bräutigam (Hrsg.), IT-Outsourcing, Teil 3 Rz. 37. 2 A.A. Bartsch, CR 2005, 1 (6); zur Begründung sogleich näher.

414

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 363 D

Das Problem könnte man u.U. durch eine analoge Anwendung von § 438 359 Abs. 1 Nr. 1a BGB lösen. Nach dieser Vorschrift verjähren Rechtsmängelansprüche auf Grund dinglicher Rechte eines Dritten im Kaufrecht erst nach dreißig Jahren. Diese Vorschrift lässt sich aber auf urheberrechtliche Ansprüche nicht anwenden. Der Begriff „dingliches Recht“ wird im Allgemeinen nur im Zusammenhang mit sachenrechtlichen Ansprüchen und nicht im Hinblick auf Ansprüche nach dem UrhG oder dem PatG verwendet. Dies gilt gerade im Hinblick auf Verjährungsvorschriften auch für das Urheberrecht. So verweist § 102 UrhG für die Verjährung urheberrechtlicher Ansprüche auf die Vorschriften des BGB. Auch in der urheberrechtlichen Literatur wird dieser Verweis als Bezug auf die regelmäßige Verjährungsfrist des § 199 BGB und nicht auf die besondere Verjährungsfrist für dingliche Ansprüche in § 197 Abs. 1 Nr. 1 BGB aufgefasst1. Trotz mancher Interessengleichheiten kommt daher die Anwendung der dreißigjährigen Verjährungsfrist des § 438 Abs. 1 Nr. 1a BGB in Fällen fehlender urheberrechtlicher Befugnisse nicht in Betracht2. Es stellt sich dennoch die Frage, ob der Kunde dafür sorgen kann, dass die 360 Verjährung zumindest kenntnisabhängig geregelt wird. Im Individualvertrag ist dies möglich. Im hier vorliegenden Fall entspricht dies auch wegen der Möglichkeit, Drittansprüchen auch nach Ablauf der Gewährleistungsfrist ausgesetzt zu sein, durchaus den Interessen beider Seiten. Wegen dieser Interessenlage dürfte es allerdings auch möglich sein, die Ver- 361 jährungsfrist in AGB zu verlängern. Man kann hier auf die Kenntnis des Kunden abstellen und danach eine eher kurze Frist von sechs Monaten oder einem Jahr vorsehen3. Zusätzlich muss dafür Sorge getragen werden, dass bei früher Kenntnis des Kunden die Verjährungsfrist für Mängelansprüche nicht unzulässig unter ein Jahr verkürzt wird. Rechtsprechung zu den Fragen existiert noch nicht. b) § 651 BGB aa) Nacherfüllungsanspruch Soweit § 651 BGB auf den zwischen den Parteien geschlossenen Vertrag anwendbar ist, gelten die Sachmängelrechte des Kaufrechts. Auch bei Geltung des Kaufrechts muss im Rahmen der Sachmängelgewährleistung zunächst Nacherfüllung verlangt werden (§ 437 Nr. 1 BGB).

362

Es gibt dann unter den gleichen Voraussetzungen wie beim Werkvertrags- 363 recht Rücktritts- und Minderungsrechte (§ 437 Nr. 2 BGB) und die Möglich-

1 Wandtke/Bullinger/Bohne, § 102 UrhG Rz. 6; vgl. auch Palandt/Ellenberger, § 197 BGB Rz. 2 f. 2 Näher Redeker, ITRB 2004, 84 (85); Jaeger, in: Wiebe/Leupold, Recht der elektronischen Datenbanken, III B Rz. 54; a.A. Bartsch, CR 2005, 1 (5). 3 Vgl. dazu näher Redeker, ITRB 2004, 84 (85 f.).

Redeker

415

D Rz. 364

Verträge

keit, Schadensersatz zu verlangen (§ 437 Nr. 3 BGB). Es gibt allerdings kein Selbstvornahmerecht. 364

Was den Nacherfüllungsanspruch betrifft, so ist es nach dem Gesetz so, dass der Käufer, also der Kunde und nicht der Hersteller, die Art und Weise der Nacherfüllung wählen kann (§ 439 Abs. 1 BGB). Der Kunde kann entscheiden, ob der Hersteller ein neues Programm liefern oder das alte ausbessern soll. Praktisch dürfte dies Wahlrecht im Bereich der Softwarelieferung keine sehr große Rolle spielen, weil sich die beiden Formen technisch kaum unterscheiden lassen1.

365

Ob man die gelieferte Software bearbeitet oder eine neue Kopie liefert, dürfte keine allzu großen Unterschiede machen. Insbesondere dürften die Aufwandsunterschiede gering sein. Auch die Installation einer Neuversion dürfte in der Regel schlichtweg durch ein Update erfolgen. Für den Kunden wird es technisch zwischen der Nachbesserung durch Patches und der Nachlieferung einer vollständigen Version kaum gewichtige Unterschiede geben2. Jedenfalls kann man auch die Lieferung von Patches in Form der Lieferung einer neuen Version durchführen. Insgesamt spricht viel dafür, das Wahlrecht sachlich dem Hersteller zu überlassen, weil dieser weit besser als der Kunde entscheiden kann, welche Mangelbeseitigungsmöglichkeit angemessen ist, zumal die Mangelursachen ja in aller Regel für den Kunden mangels Kenntnis des Quellcodes nicht einsehbar sind.

366

Man kann daher auch in AGB das Wahlrecht dem Hersteller zuweisen3. Dies geht nur dann nicht, wenn es um Verbrauchsgüterkauf geht (§ 475 Abs. 1 BGB).

367

Hinzu kommt, dass der Hersteller die vom Kunden gewählte Art der Nacherfüllung zurückweisen kann, wenn sie nur mit unverhältnismäßigen Kosten durchführbar ist. Die Regelung ist so zu verstehen, dass bei der Entscheidung darüber, ob ihre Voraussetzungen vorliegen, neben dem Wert der Sache im mangelfreien Zustand und der Bedeutung des Mangels insbesondere zu berücksichtigen ist, ob ohne erhebliche Nachteile für den Kunden auf die andere Art der Nacherfüllung zurückgegriffen werden kann (§ 439 Abs. 3 BGB).

368

Wann und wie unter Berücksichtigung der hier genannten Kriterien das Verweigerungsrecht des Herstellers besteht, wird in der Literatur intensiv diskutiert. Es werden in gewissen Bereichen absolute Obergrenzen gesetzt. So sollen Nacherfüllungskosten in Höhe von 150 % des Werts der Sache die Nacherfüllung grundsätzlich ausschließen4. Es soll auch eine Nachliefe1 Junker/Benecke, Computerrecht, Rz. 319; mit anderer Begründung ebenso Koch, ITRB 2003, 87 (89). 2 Ebenso Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 248. 3 Skeptisch Schneider, Handbuch des EDV-Rechts, D Rz. 654 f. 4 Vgl. Huber, NJW 2002, 1004 (1007 f.).

416

Redeker

Rz. 371 D

Realisierung (Kauf-/Werkvertrag)

rung unzumutbar sein, wenn sie 20 % teurer ist als die Nachbesserung1. Demgegenüber soll eine Nachbesserung nicht unzumutbar sein, wenn der Reparaturaufwand unter 3 % des Kaufpreises liegt2. Solche absoluten Grenzen sind aber problematisch. Man wird vermutlich erst langfristig Fallgruppen bilden können und dann eine Entscheidung nach diesen Fallgruppen treffen können. Der EuGH geht eher von seltenen Ausnahmefällen aus3. Diese Rechtsprechung gilt allerdings unmittelbar nur im Verbraucherbereich. bb) Minderung und Rücktritt Hinsichtlich Minderung und Rücktritt gilt bei der Anwendung des § 651 BGB das Gleiche wie im Werkvertragsrecht.

369

cc) Schadensersatz Zum Schadensersatz kann auf die obigen Ausführungen (vgl. Rz. 310 ff.) verwiesen werden. Besonderheiten gelten hier nicht.

370

dd) Verjährung Anders als im Werkvertragsrecht ist freilich die Verjährung geregelt. Die 371 Verjährung tritt in zwei Jahren ab Ablieferung ein (§ 438 Abs. 1 Nr. 3 und Abs. 2 BGB). Es gilt hier also eine besonders kurze Verjährungsfrist, weil es noch nicht einmal auf die Abnahme, sondern auf die Ablieferung ankommt. Ablieferung liegt nach der Rechtsprechung des BGH4 dann vor, wenn die Sache dem Erwerber so übergeben wird, dass er sie prüfen kann. Es kommt also nur auf die Prüfbarkeit, nicht auf die Prüfung an. Damit ist die Ablieferung in aller Regel die Übergabe der Software. Ist die Installation geschuldet, muss die Software außerdem installiert werden. Dazu gehört auch die Übergabe der Handbücher und der Benutzungsanleitung. Auch eine Einweisung muss vor Verjährungsbeginn wohl noch erfolgen5. Insoweit kann sich der Verjährungsbeginn deutlich hinausziehen. Dennoch bleibt die Verjährungsfrist angesichts der Komplexität von Software recht kurz. Es stellt sich daher die Frage, ob der Kunde den Verjährungsbeginn etwa auf den Zeitpunkt einer Abnahme verlegen kann. In einer individuell ausgehandelten Vereinbarung ist dies möglich. Ob dies auch in AGB geht, ist allerdings fraglich, weil der Beginn der Verjährungsfrist bei Verlegung auf eine Abnahme letztendlich von einer in der Willkür des Verkäufers liegenden Handlung abhängig gemacht wird. Zumindest müsste bei einer Regelung, die die Verjährung an die Abnahme knüpft und die eine AGB des Kunden darstellt, die Regelung zur Abnahme des Werkvertragsrecht vollständig übernommen 1 2 3 4 5

LG Ellwangen v. 13.12.2002 – 3 O 219/02, NJW 2003, 517. OLG Düsseldorf v. 27.2.2004 – 3 W 21/04, NJW-RR 2004, 1060. EuGH v. 16.6.2011 – C 65-09, V 87-09, BB 2011, 1934. BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207 (208 f.). OLG Nürnberg v. 28.7.1994 – 8 U 2581/93, in: Zahrnt, ECR OLG 186.

Redeker

417

D Rz. 372

Verträge

werden, einschließlich der Möglichkeit der Fristsetzung und der Abnahmefunktion. Nur dann scheint ein Hinausschieben des Beginns der Verjährung auf den Abnahmezeitpunkt evtl. möglich (vgl. auch oben Rz. 220)1. 372

Im Übrigen kann die Verjährungsfrist auch in AGB des Herstellers auf ein Jahr ab Ablieferung verkürzt werden (vgl. Rz. 345). ee) Rügeobliegenheit

373

Besonders wichtig für den Kunden ist, dass dann, wenn der Fall des § 651 BGB vorliegt, bei beiderseits kaufmännischem Geschäft gemäß § 381 Abs. 2 HGB die Untersuchungs- und Rügepflicht des § 377 Abs. 1 HGB Anwendung findet.

374

Der Gesetzgeber hat hier die Vorschrift des § 651 BGB in ihren Voraussetzungen praktisch wortwörtlich übernommen und in § 381 Abs. 2 BGB den Rückverweis auf § 377 BGB konstruiert. Damit ist in den Fällen, in denen § 651 BGB Anwendung findet, der Kunde gezwungen, die Software zu prüfen und Mängel unverzüglich zu rügen. Mängel, die bei einer ordnungsgemäßen Prüfung gefunden werden können und nicht gefunden werden, können später ohne Rüge nicht mehr geltend gemacht werden. Werden später Mängel gefunden, die noch rügefähig sind, muss auch unverzüglich gerügt werden. Die Rügefrist dürfte zwei Wochen nicht übersteigen, kann in Einzelfällen allerdings sogar kürzer sein2. So ist in Fällen mangelnder Kompatibilität die Rüge schon nach 13 Tagen verfristet3. Teilweise werden noch kürzere Fristen angenommen4. Allerdings wird dann, wenn eine komplexe Software untersucht werden muss, für die (sofort zu beginnende) Untersuchung auch eine Dauer von vier Wochen noch als angemessen angesehen5. Viel hängt damit von Umständen des Einzelfalls ab.

375

Die Rügefrist gilt auch dann, wenn der Kunde selbst die Software gar nicht erhält, sondern die Software an einen Dritten ausgeliefert wird und zwar selbst dann, wenn dieser Dritte kein Kaufmann ist und daher die Rügefrist für ihn selbst nicht gilt. Diese Vorschrift hat insbesondere für Leasingunternehmen, die Software an Freiberufler verleasen, eine gewisse Bedeutung. Die Rechtslage ist insoweit aber eindeutig.

376

Die Rügefrist beginnt mit der vollständigen Ablieferung der Software. Dazu gehört immer auch die Lieferung eines Benutzerhandbuchs. Je nach den

1 Näher dazu Redeker, ITRB 2002, 119 (120 f.). 2 LG München I v. 29.11.1984 – 5 HKO 12218/84, CR 1987, 20 (21); LG München I v. 22.12.1986 – 8 HKO 8974/86, CR 1988, 218 (219). 3 Thamm, BB 1994, 2223 (2224). 4 Zehn Tage zu lang: Marly, Praxishandbuch Softwarerecht, Rz. 1882; elf Tage zu lang: OLG München CR 1991, 19. 5 Junker/Benecke, Computerrecht, Rz. 250; vgl. auch OLG Hamm v. 31.8.2004 – 29 U 19/04, OLGReport Hamm/Düsseldorf/Köln 2005, 136: Rügefrist bei Thermodrucker: drei Wochen.

418

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 380 D

Umständen des Einzelfalls kann dazu auch die Installation gehören1. Für Einzelheiten sei auf die obigen Ausführungen verwiesen (vgl. Rz. 371). Wird nach Rüge nachgeliefert, muss der Käufer nach Erhalt der Nachlieferung erneut prüfen und ggf. unverzüglich rügen. Es beginnt eine neue Rügefrist2. Die Rüge muss den Mangel nicht detailliert beschreiben, aber so individualisieren, dass der Lieferant reagieren kann3. So wird die Rüge: „Der Drucker funktioniert nicht.“ zwar reichen, wenn der Drucker gar nicht angeht, nicht jedoch dann, wenn er falsch druckt. Technische Ursachen muss der Kunde in aller Regel nicht nennen. Auch insoweit sei auf die Ausführungen oben zur Mangelrüge verwiesen (vgl. Rz. 284 ff.). Für Rechtsmängel gilt die Rügeobliegenheit nicht4. ff) Insbesondere Rechtsmängel Im Bereich der Anwendung des § 651 BGB sind die Probleme der Haftung 377 für Rechtsmängel praktisch wichtiger als im Bereich des reinen Werkvertragsrechts. Dies liegt daran, dass hier die Verjährung grundsätzlich zwei Jahre ab Ablieferung beträgt. Damit ist die Verjährung noch etwas kürzer als sie im Bereich der Bearbeitung von Software auftritt, wo die Frist zwei Jahre nach Abnahme beträgt (vgl. Rz. 358). Die Fälle, in denen ein Unterlassungsanspruch von einem Dritten geltend gemacht wird, nachdem die Zweijahresfrist abgelaufen ist und daher Mängelansprüche gegen den Softwareersteller nicht mehr geltend gemacht werden können, dürften häufiger auftreten als in den oben diskutierten Fällen. Dennoch verbleibt es hier bei den oben (Rz. 359) näher genannten Gründen bei dieser zweijährigen Verjährungsfrist. Eine Verlängerung der Verjährung durch Anwendung des § 438 Abs. 1 Nr. 1a BGB kommt auch hier nicht in Betracht.

378

Durch entsprechende individuelle Vereinbarung und in gewissem Rahmen auch durch AGB ist hier aber eine gewisse Änderung möglich. Auch hier ist auf das oben Dargestellte (Rz. 360 f.) zu verweisen.

379

3. Sonstige Leistungsstörungen a) Nichterfüllung und Unmöglichkeit Eher selten, aber möglich ist, dass in einem Softwareerstellungsprojekt die 380 Software gar nicht hergestellt wird und dies daran liegt, dass der Unternehmer sie nicht mehr fertig stellen kann. Als Grund ist denkbar, dass er die erforderlichen Rechte für einen wesentlichen Teil der Software nicht erhalten 1 Junker/Benecke, Computerrecht, Rz. 249. 2 BGH v. 22.12.1999 – VIII ZR 299/98, = CR 2000, 207 m. Anm. Chrocziel = MDR 2000, 442 = NJW 2000, 1415 (1417); Mankowski, NJW 2006, 865. 3 Junker/Benecke, Computerrecht, Rz. 253. 4 Bartsch, CR 2005, 1 (4).

Redeker

419

D Rz. 381

Verträge

hat oder dass sämtliche sachkundigen Mitarbeiter bei ihm ausgeschieden sind und er auch keine neuen einstellen kann. Diese Fälle sind Fälle der nachträglichen subjektiven Unmöglichkeit. In diesem Fall ist der Anspruch auf Leistung ausgeschlossen (§ 275 Abs. 1 BGB). 381

Hat der Unternehmer allerdings die mangelnde Leistungsfähigkeit zu vertreten, ist er nach §§ 283, 280 Abs. 1 BGB zum Schadensersatz statt der Leistung verpflichtet. Dies bedeutet, dass er im Prinzip den Nichterfüllungsschaden ersetzen muss. In den oben genannten Fällen dürfte ein Vertretenmüssen vorliegen, weil derjenige, der sich zu einer Leistung verpflichtet, schon dafür Sorge tragen muss, dass ihm die notwendigen Rechte zustehen oder er sie zumindest erwerben kann und dass er das notwendige Personal zur Erfüllung der Aufgabe zur Verfügung hat und als Angestellte bzw. Subunternehmer jedenfalls einschalten kann. Es kann allerdings einzelne seltene Fälle geben, in denen der Lieferant sich auf die Berechtigung von Vorlieferanten zur Rechtsübertragung verlassen konnte und ihn deshalb kein Verschulden trifft. Da er aber in der Regel umfangreiche Prüfungspflichten hat, dürften dies sehr seltene Ausnahmefälle sein1.

382

Möglich sind auch Fälle von anfänglicher subjektiver oder objektiver Unmöglichkeit, in denen die Software entweder so wie vereinbart überhaupt nicht oder jedenfalls nicht vom Ersteller hergestellt werden kann. In der Rechtsprechung hat es einen Fall gegeben, in denen anfängliche subjektive Unmöglichkeit angenommen worden war2. Hier hatte der Lieferant eine Hardware mit Betriebssoftware sowie zusätzlich ein Finanzbuchhaltungsund ein Lohnbuchhaltungssystem bestellt. Die bestellte Hardware war aber nicht in der Lage, ein den Anforderungen des deutschen Marktes entsprechendes Finanzbuchhaltungs- und Lohnbuchhaltungssystem überhaupt zu verarbeiten, weil sie dazu nicht die notwendige Kapazität aufwies. Dies bewertete das OLG Frankfurt als anfängliche subjektive Unmöglichkeit. Für den Fall der Softwareerstellung sieht dies Marly freilich anders, wenn es eine problemlos verwendbare andere Hardware gibt3. Ein Fall der anfänglichen Unmöglichkeit liegt in der Verpflichtung zur Lieferung einer Software, die einem öffentlich-rechtlichen Lieferverbot ohne Dispensmöglichkeit (z.B. einem Exportverbot) unterliegt und dem Schuldner deswegen von niemandem geliefert werden kann4.

383

Auch in solchen Fällen des anfänglichen subjektiven oder objektiven Unmöglichwerdenseins besteht keine Leistungspflicht (§ 275 Abs. 1 BGB).

384

Gemäß § 311a Abs. 2 Satz 1 BGB hat allerdings der Erwerber dann Schadensersatzansprüche. Eine Ausnahme gilt nur dann, wenn der Schuldner das Leistungshindernis bei Vertragsschluss nicht kannte und seine Un1 2 3 4

A.A. für diesen Fall (Garantiehaftung): Sutschet, NJW 2005, 1404 (1406). OLG Frankfurt v. 23.11.1983 – 21 U 236/82, BB 1984, 300. Marly, Praxishandbuch Softwarerecht, Rz. 1176. Marly, Praxishandbuch Softwarerecht, Rz. 1175.

420

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 388 D

kenntnis auch nicht zu vertreten hat (§ 311a Abs. 2 Satz 2 BGB). Die Rechtslage ist also so, dass im Prinzip Schadensersatzansprüche immer bestehen, der Schuldner allerdings bei nicht fahrlässiger Unkenntnis nicht haftet. Für die nicht fahrlässige Unkenntnis ist er darlegungs- und beweisbelastet. Besteht ein Schadensatzanspruch, geht es wieder um Schadensersatz anstel- 385 le der Leistung, ggf. kann aber auch Aufwendungsersatz verlangt werden (§§ 311a Abs. 2 Satz 3, 284 BGB). In allen hier vorliegenden Fällen stellt sich freilich die Frage, ob bei einer 386 mangelbehaftete Software, deren Mängel nicht beseitigt werden können, Fälle der Unmöglichkeit vorliegen oder nicht doch das Sachmängelrecht eingreift. Die Abgrenzung zwischen dem allgemeinen Leistungsstörungsrecht und dem Mängelgewährleistungsrecht ist gesetzlich nicht näher geregelt. Teilweise wird die Ansicht vertreten, das Mängelrecht gehe vor1. Dies kann aber vor Fertigstellung der Sache schon deshalb schwerlich gelten, weil dann der Leistungsgegenstand noch gar nicht konkretisiert ist und daher Sachmängelrechte gar nicht gegeben sind. Daher stellt eine weitere Meinung auf den Gesichtspunkt der Fertigstellung ab: Bis zur Fertigstellung der Sache gilt allgemeines Leistungsstörungsrecht, danach Mängelgewährleistungsrecht2. Es dürfte aber richtiger sein, auf die Akzeptanz des Erwerbers abzustellen3: Nimmt er die Lieferung der Software (im Falle des § 651 BGB) an als Erfüllung (§ 363 BGB) oder nimmt er sie gar ab, gilt ab diesem Zeitpunkt Mängelgewährleistungsrecht. Bis zu diesem Zeitpunkt gelten im Prinzip die allgemeinen Leistungsstörungsrechte, also auch die Unmöglichkeitsregeln. Die bloße unbegründete Leistungsverweigerung durch den Unternehmer 387 stellt im Übrigen keine Unmöglichkeit dar. In diesen Fällen kann der Unternehmer auch auf Fertigstellung des Programms verklagt werden. Allerdings bietet sich in aller Regel an, über § 281 BGB zum Schadensersatz zu kommen. In einzelnen Fällen mag dann auch eine Fristsetzung gem. § 281 Abs. 2 BGB entbehrlich sein. Eine Klage auf Programmerstellung ist in der Mehrheit der Fälle unpraktikabel, obwohl theoretisch auch eine Vollstreckung in Betracht kommt. § 888 Abs. 2 ZPO ist auf den hier vorliegenden Werkvertrag nicht anwendbar. b) Verzug Praktische Probleme ergeben sich bei der Softwareerstellung oft deswegen, 388 weil die Software nicht zu dem Zeitpunkt fertiggestellt wird, den sich der Kunde vorstellt. Je nach vertraglicher Vereinbarung kann bei einer solchen

1 Marly, Praxishandbuch Softwarerecht, Rz. 1177. 2 Erman/Schwenker, § 633 BGB Rz. 21. 3 Palandt/Grüneberg, § 275 BGB Rz. 9.

Redeker

421

D Rz. 389

Verträge

Terminsüberschreitung ohne weitere Umstände ein Verzug eintreten. In anderen Fällen bedarf es aber erst einer Mahnung. 389

Verzug tritt dann mit Ablauf des Termins ein, wenn zwischen den Parteien dieser Termin als konkreter Fertigstellungstermin für die Software vereinbart ist. Dies kann im ursprünglichen Vertrag bzw. seinen Anlagen vereinbart worden sein. Dies kann aber auch im Laufe des Projekts durch einvernehmliche Vereinbarung von Projektfortschritten vereinbart worden sein.

390

Verzug tritt allerdings erst dann ein, wenn ein endgültiger Fertigstellungstermin entweder der Gesamtsoftware oder eines als eigenständige Leistung vereinbarten Teilprojekts überschritten ist. Die bloße Überschreitung von Zwischenterminen, in denen einzelne Teilaspekte fertiggestellt oder Berichte erstellt worden sind, führt juristisch nicht zum Verzug, auch wenn die Überschreitung solcher Termine für die Projektdurchführung ein Alarmzeichen darstellen kann.

391

Ist ein vereinbarter Fertigstellungstermin überschritten, tritt ohne weitere Umstände Verzug ein. Allerdings kann sich der Hersteller damit entlasten, dass er an der Verzögerung kein Verschulden trage und daher kein Verzug im juristischen Sinne vorliege. Für diesen Einwand ist der Hersteller aber darlegungs- und beweispflichtig.

392

Es dürften nur wenige Fälle vorstellbar sein, in denen es am Verschulden des Softwareerstellers fehlt, wenn die Software nicht fristgemäß fertiggestellt ist. Auf jeden Fall kann der Hersteller nicht mit dem Einwand gehört werden, der Terminplan sei von vornherein unrealistisch und das Projekt in der gewünschten Zeit überhaupt nicht fertigstellbar gewesen. Wer eine bestimmte Frist zur Fertigstellung verspricht, muss sich vorher vergewissern, dass er sie einhalten kann. Wenn er dies dann nicht kann, hat er die Verzögerung zu vertreten.

393

Anderes gilt allenfalls dann, wenn sich im Laufe des Projekts unvorhersehbare Schwierigkeiten und Verzögerungen herausgestellt haben, die den Projektumfang deutlich erhöhen und dadurch eine Verzögerung hervorrufen. Wird dann zu dem Zeitpunkt, wo diese Verzögerungen absehbar sind, auf das Problem vom Hersteller auch noch hingewiesen, kann es in Einzelfällen sehr wohl sein, dass ihn kein Verschulden trifft. In der Praxis dürfte aber in den meisten Fällen der Terminplan dann verändert werden, jedenfalls dann, wenn auch der Vertragspartner davon überzeugt ist, dass die Schwierigkeiten nicht vorhersehbar waren.

394

Ein zweites in der Praxis auftretendes Problem könnte im zeitweiligen oder dauernden Ausscheiden von Personal liegen. Zeitweiliges Ausscheiden liegt bei Erkrankungen vor, dauerndes Ausscheiden etwa dann, wenn das Personal kündigt oder vom Hersteller entlassen wird.

395

Entlässt der Hersteller Personal und verzögert sich dadurch das Projekt, liegt offenkundig Verschulden vor. Kündigt jedoch das Personal selbst, liegt

422

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 398 D

in diesem Vorgang zunächst kein Verschulden des Herstellers. Es stellt sich aber die Frage, ob er nicht eine Vorsorgeplanung für den Fall der Kündigung von Mitarbeitern treffen muss. Dies ist jedenfalls bei größeren Softwarehäusern sicherlich notwendig und betrifft neben der Kündigung auch den Krankheitsfall. Bei kleineren Softwarehäusern werden solche Vorhaltekosten kaum finanzierbar sein, was auch dem Vertragspartner klar sein dürfte, so dass hier der Vorwurf nicht darin bestehen kann, dass man kein hinreichend geschultes und eingeführtes Ersatzpersonal vorgehalten hat. Hier muss der Hersteller sich nur auf dem Markt bemühen, möglichst schnell Ersatzpersonal zu beschaffen. Verzögerungen, die dann, wenn Ersatzpersonal vorgehalten und dann auch möglichst zeitnah eingesetzt wird bzw. neues eingestellt wird, eintreten, weil die neuen Mitarbeiter in das Projekt erst eingeführt und auf den aktuellen Stand des Projekts werden müssen, sind dann unverschuldet. Kommen solche Vorgänge nicht allzu oft vor, wird es wohl auch in der Praxis in der Regel Verständnis beim Kunden für die Probleme geben. Es gibt aber Fälle häufigen Personalwechsels mit dauernden Verzögerungen, die allein schon das Projekt stören und daher zum Abbruch führen können1. Ein weiterer Grund für Verzögerungen sind fehlende Mitwirkungshandlungen des Kunden. Wird auf diese vom Hersteller hinreichend hingewiesen und sie abverlangt und erbringt der Kunde sie daraufhin nicht, obwohl er sie erbringen müsste, sind daraus sich ergebende Verzögerungen unverschuldet und führen nicht zum Verzug (vgl. oben Rz. 223 ff.). Es ist aber zu betonen, dass der Hersteller die Mitwirkungshandlungen auch in der Tat einfordern muss. Anderenfalls wird er mit dem Hinweis auf fehlende Mitwirkungshandlung nicht gehört werden können.

396

Ein sehr wichtiges praktisches Problem ist die Frage, was denn bei Ände- 397 rungen des Auftragsinhalts passiert. Diese müssten zunächst vertraglich vereinbart sein, und zwar durch nachträgliche Vereinbarung im zwischen den Parteien vorhergesehenen Verfahren oder auch außerhalb dessen, wenn sie denn von entsprechend bevollmächtigten Personen abgeschlossen werden. Es liegt nahe, anzunehmen, dass dann, wenn bei Vereinbarungen solcher 398 Vertragsänderungen die Lieferzeiten nicht geändert werden, die geänderte Software in der vereinbarten Lieferzeit geliefert werden muss. Wenn der Hersteller diesen Effekt vermeiden will, muss er bei den Vertragsänderungen auf entsprechende Fertigstellungsverzögerungen hinweisen und dafür Sorge tragen, dass diese Veränderungen auch vereinbart werden. Er kann sich nicht nachträglich darauf berufen, dass es klar sei, dass Inhaltsänderungen auch zu Leistungsverzögerungen führen. Dies muss keinesfalls zwingend zusammenhängen.

1 Dies ist eine der vielen plastischen Aspekte in der Entscheidung OLG Köln v. 9.5.2003 – 19 U 166/02, CR 2004, 331 = OLGReport Köln 2004, 113.

Redeker

423

D Rz. 399

Verträge

399

Geänderte Fertigstellungszeiten können auch konkludent vereinbart werden. Dies gilt z.B. dann, wenn der Hersteller auf notwendige Lieferverzögerungen hinweist, der Kunde nicht widerspricht und dann die Veränderungen vereinbart werden. Unterlässt man in diesem Fall die Vereinbarung eines konkreten Leistungstermins, ist es sogar so, dass ein Verzug erst mit Mahnung eintritt, weil kein konkretes Lieferdatum vereinbart ist. Es entsteht eine bewusste Vertragslücke. Will der Kunde in den Fällen, wo der Hersteller auf die Verzögerung hingewiesen hat, darauf bestehen, dass der alte Fertigstellungszeitraum eingehalten wird, muss er dies deutlich machen. Ferner muss der Hersteller sein Einverständnis erklären.

400

Sind keine korrekten Leistungszeitpunkte vereinbart, kommt der Hersteller nach Mahnung des Kunden in Verzug. Es stellt sich mangels konkreter Vereinbarung allerdings die Frage, wann der Kunde überhaupt mahnen kann. Bei einem komplexen Softwareerstellungsvertrag kann niemand erwarten, dass die Erstellung kurzfristig nach Auftragserteilung erfolgt. Wann diese denn erfolgen muss, wenn überhaupt keine Anhaltspunkte für Leistungszeitpunkte vereinbart sind, dürfte schwer zu entscheiden sein. Es dürfte angesichts der bewussten Vertragslücke sehr auf die Umstände des Einzelfalls ankommen.

401

Mahnungen dürften vor allen Dingen dann in Betracht kommen, wenn bei einer Änderung des Leistungsinhalts klar war, dass der Fertigstellungszeitpunkt sich verzögert, ein konkreter neuer Fertigstellungszeitpunkt aber nicht verbindlich vereinbart wurde.

402

Kommt der Unternehmer in Verzug, so kann der Kunde zunächst den Verzugsschaden geltend machen (§§ 280, 286 BGB). Dieser Verzugsschaden kann z.B. im entgangenen Gewinn liegen, wenn die Software bei rechtzeitiger Fertigstellung im Betrieb produktiv hätte eingesetzt werden können und dadurch der Gewinne erhöht würde. Dies lässt sich leicht darlegen, wenn die Software für die Aufnahme eines neuen Betriebsteils oder überhaupt eines neuen Betriebs erforderlich ist und der Betrieb zunächst nicht aufgenommen werden kann, weil die Software nicht vorliegt. Daran ist zu denken, wenn ein neues Geschäft aufmacht und die Kassensoftware nicht pünktlich geliefert wird, so dass das Geschäft nicht betrieben werden kann, weil ohne Kassensoftware das Kassensystem nicht funktioniert. Komplizierter ist dies zu belegen, wenn durch die Software nur eine Kostenersparnis gegenüber dem bisherigen Betrieb erstrebt werden soll und der Betrieb ansonsten mit der vorhandenen Software oder mit einer sonstigen vorhandenen Betriebseinrichtung bis zur verspäteten Fertigstellung fortgeführt werden kann.

403

Der Verzugsschaden kann aber auch in der nutzlosen Miete schon angeschaffter Hardware oder anderer Anlagen liegen, die nicht genutzt werden können, weil die Software nicht vorliegt. Auch eventuell vergeblich gezahlte Gehälter für Personal, das nicht vernünftig eingesetzt werden kann, weil die Software fehlt, könnte als Schaden in Betracht kommen. 424

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 408 D

Solche Verzögerungsschäden sind allerdings erst ab Verzug, damit in Einzelfällen erst ab Ablauf der Frist, die in der Mahnung enthalten ist, geltend zu machen.

404

Im Übrigen kann der Kunde bei verspäteter Herstellung (und nicht nur bei 405 Verzug) eine Frist zur Fertigstellung setzen und nach Ablauf der Frist vom Vertrag zurücktreten. Er muss allerdings nicht nach Ablauf der Frist zurücktreten, sondern kann auch weiterhin auf Erfüllung drängen oder auch Schweigen. Das Gesetz setzt keine zeitliche Grenze, binnen derer er das Wahlrecht ausüben kann. Solange der Kunde nicht zurücktritt, kann der Softwareersteller auch noch erfüllen. Erfüllt er, geht das Rücktrittsrecht unter. Allerdings kann der Gläubiger die Annahme der verspäteten Leistung verweigern und zurücktreten1. In allen anderen Fällen bleibt es bestehen, sogar dann, wenn der Kunde nach Fristablauf Erfüllung verlangt2. Es wird in einzelnen Fällen versucht, eine zeitliche Grenze in den AGB 406 zu setzen. Dies geschieht z.B. in der EVB-IT3. Diese sieht z.B. in Ziff. 3.1 EVB-IT-Kauf vor, dass der Unternehmer während des Fristverlaufs vom Besteller eine Erklärung verlangen kann, ob dieser zurücktritt oder nicht. Bis zur Beantwortung dieser Frage läuft die Frist weiter und läuft nicht ab. Eine solche Klausel kann der Kunde in seinen AGB als Klausel zu seinen Lasten vorsehen. Der Hersteller dürfte dies nicht können, weil dies eine klare Abweichung von der gesetzlichen Regelung ist. Ob der Hersteller freilich nach Ablauf der Frist eine solche Frage stellen kann und dann nach Ablauf einer weiteren Frist bei Schweigen des Kunden die Rechtsfolge eintreten kann, dass dieser ohne erneute Fristsetzung nicht zurücktreten kann, ist noch offen. Bei einigermaßen angemessenen Fristen dürfte dies aber möglich sein, weil sonst der Hersteller unbegrenzt an der Fertigstellung der Software arbeiten muss und dennoch kurz vor Fertigstellung der Kunde noch zurücktreten kann. Erbringt der Hersteller nach Fristsetzung nur einen Teil der Leistung fristgemäß, kann der Kunde vom Gesamtvertrag zurücktreten, wenn er kein Interesse an der gelieferten Teilleistung hat (§ 323 Abs. 5 BGB).

407

Neben dem Rücktritt oder auch an seiner Stelle kommt im Übrigen bei Ver- 408 schulden des Unternehmers an der trotz Fristablauf nicht erbrachten Leistung sogar Schadensersatz statt Leistung in Betracht. Zu diesen Schadensersatzansprüchen gehören die vergeblichen Aufwendungen des Bestellers im Zusammenhang mit der Vertragsdurchführung für die Anmietung von Räumen oder die Schulung von Mitarbeitern. Ggf. können auch Mehrkosten für eine Ersatzbeschaffung als Schaden geltend gemacht werden. § 284 BGB ist anwendbar.

1 Vgl. Erman/Westermann, § 323 BGB Rz. 22. 2 BGH v. 20.1.2006 – V ZR 124/05, NJW 2006, 1198. 3 Dargestellt bei Feil/Leisten, CR 2002, 407 ff.

Redeker

425

D Rz. 409

Verträge

409

All diese Schäden sind oft sehr schwer nachweisbar. Deswegen gibt es in der Praxis oft Klauseln, die bei Verzug des Herstellers Vertragsstrafen vorsehen, die an den Herstellungswert anknüpfen und für jeden Tag des Verzugs einen bestimmten Prozentsatz ausweisen. Die Vertragsstrafe muss der Höhe nach auf einen Maximalprozentanteil der geschuldeten Leistung begrenzt werden. Ferner darf auch die Vertragsstrafe pro Tag nicht zu hoch liegen.

410

Der BGH hat zunächst festgehalten, dass eine Vertragsstrafe von 0,5 % des Auftragswerts für jeden Tag der Verzögerung zu hoch ist, auch wenn eine Höchstsumme der Vertragsstrafe festgesetzt wird1. Für Bauverträge hat er ferner entschieden, dass eine Vertragsstrafenhöchstsumme von 5 % sicherlich zulässig ist, auch wenn die Auftragssumme sehr hoch ist. Eine Vertragsstrafe von 10 % hat er für Bauverträge generell als zu hoch bezeichnet2.

411

Da die Vertragsstrafe auch in Bauverträgen unabhängig vom Auftragswert des Bauvertrags auf 5 % begrenzt wird, kann die Einhaltung dieser Grenze bei Softwareverträgen sicherlich ausreichend für eine Wirksamkeit der AGB sein. Möglicherweise ist aber auch eine Grenze von 10 % zulässig, weil Softwareverträge grundsätzlich im Prinzip niedrigere Auftragswerte als Bauverträge haben und im Übrigen der Anteil eigener Arbeitsleistung deutlich höher als bei Bauverträgen ist. Bei Bauverträgen spielen Materialkosten eine wesentlich höhere Rolle als bei Softwareerstellungsverträgen, so dass das Verhältnis zwischen Vertragsstrafe und eigenem Unternehmerverdienst nach Abzug möglicher Kosten für die Beschaffung der verwendeten Materialien bei Softwareerstellungsverträgen deutlich günstiger als bei Bauverträgen sein dürfte. Bei kombinierten Verträgen aus Beschaffung von Standardsoftware und Anpassungsleistungen kann dies aber manchmal auch wieder anders sein, so dass eine sichere Prognose für solche Klausel nicht gegeben werden kann. Rechtsprechung zu Softwareverträgen gibt es allerdings nicht.

412

Wer eine Vertragsstrafe wegen verspäteter Lieferung geltend machen will, muss sich dies bei Annahme der Leistung vorbehalten (§ 341 Abs. 3 BGB)3.

413

Gelegentlich, vor allem in den BVB, wurden und werden auch Klauseln über Schadenspauschalen verwendet. Diese haben aber die Problematik, dass sich die Höhe der vereinbarten Schadenspauschale am voraussehbaren Schaden orientieren müssen (§ 309 Nr. 5a BGB). Da es oft zwischen den Schäden und den Auftragswerten nur begrenzte Korrelationen gibt, dürften pauschalen Schadensersatzversprechungen, die an Auftragssummen anknüpfen, in aller Regel unwirksam sein. Solche Klauseln sind daher bei Verzugsschäden im Allgemeinen nicht zu empfehlen. 1 BGH v. 20.1.2000 – VII ZR 46/98, MDR 2000, 827 = NJW 2000, 2106; BGH v. 17.1.2002 – VII ZR 198/00, BB 2002, 698; BGH v. 7.3.2002 – VII ZR 41/01, MDR 2002, 1005 = NJW 2002, 2322. 2 BGH v. 23.1.2003 – VII ZR 210/01, CR 2003, 647 = MDR 2003, 804 = NJW 2003, 1805 (1808). 3 Näher Erman/Schader, § 341 BGB Rz. 3.

426

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 417 D

c) Verletzung sonstiger Pflichten des Lieferanten aa) Beratungspflichten Neben den bislang erörterten Leistungsstörungen und Sachmängelproble- 414 matiken gibt es eine Reihe von weiteren Pflichten des Softwareerstellers, aus deren Verletzung sich Schadensersatzansprüche gem. § 280 Abs. 1 BGB ergeben. In Frage kommen hier Ansprüche wegen Verletzung vertraglicher Nebenpflichten (früher positive Vertragsverletzung) oder Ansprüche wegen der Verletzung von Pflichten aus dem sich aus § 311 BGB ergebenden gesetzlichen Schuldverhältnis, das durch die Aufnahme von Vertragsverhandlungen entsteht (früher culpa in contrahendo). Hier sind insbesondere die Hinweis- und Beratungspflichten zu nennen, die oben (Rz. 4 ff.) schon im Detail erörtert worden sind. Solche Beratungspflichten bestehen allerdings nicht nur in der vorvertraglichen Phase, sondern können je nach Umständen auch während der Programmerstellung und/oder sogar nach Fertigstellung und Übergabe der Software bestehen. Dies gilt insbesondere dann, wenn nachträglich dem Unternehmer nicht ohne weiteres entdeckbare Mängel bekannt werden oder sonstige Umstände eintreten, die für die Nutzung der Software relevant sind. Diese Beratungspflichten bestehen unabhängig von einem eventuell abgeschlossenen Pflegevertrag. Allerdings dürfen hier keine allzu großen Anforderungen an den Unternehmer gestellt werden, jedenfalls keine weit größeren, als die nach dem Produkthaftungsgesetz ohnehin bestehen1. Werden diese Hinweis- und Beratungspflichten verletzt, ergeben sich 415 Schadensersatzansprüche aus § 280 Abs. 1 BGB. Diese unterliegen in aller Regel der regelmäßigen Verjährungsfrist. Eine ungeklärte Rechtsfrage ist, ob dann, wenn sich die Beratungspflichten auf Sachmängel beziehen, die Ansprüche aus der Verletzung von Beratungspflichten und die Ansprüche aus Mängelrecht nebeneinander bestehen2. Hier gehen nach h.M. die Mängelansprüche vor3. Diese Frage kann sich wegen der unterschiedlichen Verjährungsfristen in Einzelfällen durchaus stellen, insbesondere in dem Bereich, wo die Sachmängel der gesetzlichen Regelverjährung unterliegt, also insbesondere den Fällen des § 651 BGB und im Bereich der Bearbeitung von Software.

416

Ein Schadensersatzanspruch kann in Einzelfällen bei der Verletzung von Beratungspflichten auch auf Rückgängigmachung des Vertrages gerichtet sein4.

417

1 Hörl, CR 1999, 605 (608 f.). 2 Näher Häublein, NJW 2003, 388. 3 Staudinger/Peters/Jacoby, § 634 BGB Rz. 161; Staudinger/Löwisch, § 311 BGB Rz. 129; Erman/Kindl, § 311 BGB Rz. 45; Hörl, ITRB 2004, 87. 4 OLG Koblenz v. 11.11.1988 – 2 U 4/86, CR 1990, 41 (43).

Redeker

427

D Rz. 418

Verträge

bb) Geheimhaltungspflichten 418

Eine zweite Gruppe von Pflichten, deren Verletzung durchaus umfangreiche Schadensersatzansprüche auslösen kann, sind die Geheimhaltungspflichten. Wer Software für einen Kunden erstellen muss, muss in aller Regel zwangsläufig mit Details der Organisations- und Betriebsgestaltung des Bestellers vertraut werden. Beschäftigt er sich damit nicht, kann er die Software oft gar nicht erstellen. Dies gilt selbst dann, wenn die eigentliche Organisationsstruktur möglicherweise aus Anlass des Softwareprojektes vom Kunden überarbeitet wird. Auch dann muss sich der Hersteller mit der vom Kunden beabsichtigten Organisationsänderung (möglicherweise sogar mit den Fortschritten der Realisierung) näher vertraut machen, um die Software zu erstellen1.

419

Wer sich mit der Organisation und den Betriebsstrukturen des Kunden beschäftigen muss, erhält zwangsläufig häufig Kenntnis von Betriebs- und Geschäftsgeheimnissen des Kunden. Diese sind sogar ohne vertragliche Vereinbarung vertraulich zu behandeln. In aller Regel werden aber vertragliche Regelungen darüber geschlossen (oben Rz. 39). Dies kann den Parteien nur dringend angeraten werden. Aus Sicht des Kunden ist es zwingend, dass auch festgehalten wird, in welcher Art und Weise der Softwareersteller die Geheimnisse seiner Kunden schützt und dass er auch seine Arbeitnehmer (und ggf. auch die Subunternehmer) zur Wahrung der Betriebs- und Geschäftsgeheimnisse verpflichtet2.

420

In seltenen Fällen wird auch der Kunde durch den Inhalt der Software Kenntnis von Betriebs- und Geschäftsgeheimnissen des Herstellers erwerben. Dies gilt hauptsächlich in den Fällen, in denen er Quellcode und sonstige Unterlagen erhält, die bestimmte Know-how-Vorsprünge des Erstellers enthalten und die dieser nicht allgemein öffentlich verbreitet. Sind solche Fälle vorstellbar, müsste auch der Kunde sich auch zur entsprechenden Geheimhaltung verpflichten. Solch eine Verpflichtung ist auch sinnvoll, wenn der Kunde während des Softwareerstellungsprozesses Kontroll- und Einsichtsrechte beim Softwareunternehmen erhält3.

421

Bei Verletzung der Geheimhaltungspflicht muss der Verletzter Schadensersatz leisten (§ 280 Abs. 1 BGB).

422

Die Höhe des Schadensersatzes lässt sich allerdings in vielen Fällen nicht klar bestimmen. Deswegen ist es üblich und auch geboten, im Fall der Verletzung von Geheimhaltungspflichten eine Vertragsstrafe zu vereinbaren. Solche Vereinbarungen sind auch in AGB zulässig. Die Höhe der Vertragsstrafe muss freilich angemessen sein. 1 Vgl. dazu ausführlich (aus der Sicht eines Projektleiters) Zahrnt, Richtiges Vorgehen bei Verträgen über IT-Leistungen, S. 18 ff., zum sog. Organisationsprojekt des Kunden. 2 Dazu Intveen, ITRB 2007, 259. 3 Schneider, Handbuch des EDV-Rechts, E Rz. 253.

428

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 427 D

Werden die Geheimhaltungspflichten verletzt, kann in vielen Fällen, ins- 423 besondere bei nachhaltiger oder vorsätzlicher Verletzung, ein Grund vorliegen, vom Softwareerstellungsvertrag nach § 324 BGB zurückzutreten, weil eine weitere Vertragserfüllung für den Kunden nicht mehr zumutbar ist. In diesem Falle müssten freilich auch die schon erbrachten Teilleistungen zurückgegeben werden. Es hat sich deswegen immer wieder die Frage gestellt, ob neben diesem Rücktrittsrecht auch ein Kündigungsrecht besteht. Dies ist im alten Recht von der Rechtsprechung dem Kunden zugebilligt worden. Er konnte auch einen Werkvertrag außerordentlich kündigen und die Teilleistung behalten, wenn er sie denn bezahlte.

424

Dies dürfte sich insbesondere bei komplexen Entwicklungsaufträgen für das neue Recht aus § 314 BGB ergeben. In Einzelfällen können auch Werkverträge Dauerschuldverhältnisse sein (vgl. unten Rz. 432 ff.)1. cc) Sonstige Pflichten Neben den oben genannten Pflichten aus dem Beratungsbereich und der Ge- 425 heimhaltung gibt es immer wieder Fälle, in denen der Softwareersteller andere Pflichten aus dem Schuldverhältnis verletzt. Bemerkenswert ist immer der Fall des nachträglichen Einbaus der Pro- 426 grammsperre. Es geht dabei nicht um die Fälle, wo Programmsperren bereits mit der Software geliefert wurden. Dies ist ein Fall des Sachmängelgewährleistungsrechts (vgl. Rz. 271, 273). Es hat aber immer wieder Fälle gegeben, in denen Programmsperren nach- 427 träglich nach Abnahme eingebaut wurden, etwa im Zuge von Nachbesserungsarbeiten oder im Zuge von Wartungsarbeiten. Für den hier vorliegenden Fall interessant ist es dann, wenn es um Nachbesserungsarbeiten geht. Wird bei Nachbesserungsarbeiten eine Programmsperre eingebaut, so handelt es sich entweder um eine mangelhafte Nachbesserungsarbeit oder um eine eigenständige Vertragsverletzung, die sich aus den weiter geltenden Treupflichten während der Vertragsabwicklung hinsichtlich des ursprünglichen Softwareerstellungsvertrages ergibt. Liegt ein solcher Fall vor, ist der Einbau der Sperre also eine Vertragsverletzung, so ergibt sich ein Schadensersatzanspruch aus § 280 Abs. 1 BGB. Der Schadensersatzanspruch umfasst zum einen die Pflicht zur Beseitigung der vom Unternehmer bewusst eingebauten Mangels und zum anderen auch einen Anspruch über eventuell darüber hinausgehende Schäden, etwa wegen der zeitweiligen Nichtnutzbarkeit des Programms.

1 Palandt/Grüneberg, § 314 BGB Rz. 2.

Redeker

429

D Rz. 428

Verträge

d) Obliegenheiten und Pflichten des Bestellers aa) Obliegenheitsverletzungen 428

Dem Besteller obliegen eine ganze Reihe von Mitwirkungshandlungen, die im Einzelnen oben schon näher dargelegt worden sind (vgl. Rz. 223 ff.). Es handelt sich nach dem Gesetz um Obliegenheiten. Welche Rechtsfolgen sich bei der Nichterfüllung solcher Obliegenheiten ergeben, ist oben (vgl. Rz. 233 ff.) schon dargelegt worden. bb) Pflichtverletzungen

429

Es kann in Einzelfällen auch sein, dass statt der Mitwirkungsobliegenheiten Mitwirkungspflichten vorliegen, entweder, weil dies zwischen den Parteien so vereinbart ist oder weil sich das aus einer besonderen tatsächlichen Situation so ergibt (vgl. Rz. 237 ff.).

430

Werden solche Pflichten verletzt, kann es zunächst Verzug mit der Erfüllung dieser Pflichten geben. Es greifen dann die Vorschriften der §§ 280, 286 BGB (Schuldnerverzug) ein. Es kommt sogar ein Schadensersatzanspruch des Erstellers in Betracht1. Es kann sogar sein, dass der Unternehmer sich nach § 323 BGB vom Vertrag lösen kann, wenn sich diese Mitwirkungspflichten als Pflichten im Gegenseitigkeitsverhältnis darstellen. Der Unternehmer kann dann bei zu vertretender Nichterfüllung der Mitwirkungspflichten vom Vertrag zurücktreten und den vollen Werklohn abzüglich eventueller Ersparnisse im Wege des Schadensersatzes statt Leistung verlangen. Im Einzelfall kann es über diese Verletzung von Mitwirkungspflichten hinaus noch weitergehende Pflichtverletzungen des Bestellers geben, bei deren Verletzung ebenfalls Schadensersatzansprüche denkbar sind. cc) Fehlende Abnahme

431

Auch eine rechtswidrigerweise nicht durchgeführte Abnahme stellt eine Pflichtverletzung (und zwar einer Hauptplicht) dar2. Diese Pflichtverletzung kann bei Verschulden Schadensersatzansprüche auslösen, die der Unternehmer gegenüber dem Besteller geltend machen kann. Darüber hinaus kommt der Besteller, der seiner Abnahmepflicht nicht genügt, in Annahmeverzug3. Ferner geht die Leistungsgefahr gemäß § 644 BGB auf ihn über. e) Kündigung und Rücktritt

432

Auch beim Werkvertrag gelten für den Rücktritt die allgemeinen Vorschriften. Insbesondere der Kunde kann daher bei Nichtlieferung nach Fristsetzung oder wegen Unmöglichkeit bei Verweigerung der Lieferung zurücktre1 Vgl. Schneider, ITRB 2008, 261 (262 f.). 2 Marly, Praxishandbuch Softwarerecht, Rz. 1348. 3 Marly, Praxishandbuch Softwarerecht, Rz. 1348.

430

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 437 D

ten und auch der Unternehmer kann zurücktreten, wenn der Kunde nach entsprechender Fristsetzung nicht zahlt. Es gibt zudem ein Kündigungsrecht für den Unternehmer gem. § 643 BGB 433 bei mangelnder Mitwirkung des Bestellers (vgl. Rz. 234). Im Falle der Kündigung nach § 643 BGB hat der Unternehmer dann einen Teilvergütungsanspruch für die schon erbrachten Leistungen gem. § 645 Abs. 1 Satz 2 BGB. Der Besteller hat im Werkvertragsrecht ferner das spezielle Kündigungs- 434 recht nach § 649 BGB. Er kann kündigen, ohne dass er dafür einen Grund angeben kann. Der Unternehmer behält in diesem Fall seinen Vergütungsanspruch. Soweit er möglicherweise abnahmefähige Teilleistungen erbracht hat, ist die Abnahme dieser Leistungen allerdings Fälligkeitsvoraussetzung des Vergütungsanspruchs1. Er muss sich nach der Vorschrift allerdings das anrechnen lassen, was er durch die Aufhebung des Vertrages an Aufwendungen erspart oder durch anderweitige Verwendung seiner Arbeitskraft erwirbt oder zu erwerben böswillig unterlässt. Prinzipiell ist das Vorliegen dieses Abzugspostens vom Besteller darzulegen und zu beweisen. Die anderweitige Verwendung der Arbeitskraft betrifft auch die Arbeit der Mitarbeiter. Die Darlegung und der Beweis dieses Abzugspostens ist für den Kunden 435 dann schwierig, wenn es um Festvergütungsvereinbarung geht. In aller Regel werden ja in solchen Fällen die Kalkulationsgrundlagen des Unternehmers dem Kunden nicht aufgedeckt. Der Kunde kann dann nicht vernünftigen darlegen, was sich der Unternehmer wegen der Nichtfertigstellung des Vertrages erspart. Für diesen Fall hat der BGH in einer Reihe von Entscheidungen die Darlegungs- und ggf. auch die Beweislast abgeändert. Der Unternehmer muss zunächst darlegen, wie die Grundlagen seiner Kal- 436 kulation sind und welche Ersparnisse oder Nichtersparnisse sich aus dieser Kalkulation im Hinblick auf die erfolgte und wirksame Kündigung nach § 649 BGB ergeben. Er muss dazu notfalls auch die maßgeblichen Preisermittlungsgrundlagen nachträglich zusammenstellen und auf Grundlage dieser nachträglich zusammengestellten Preisermittlungsgrundlagen die ersparten Aufwendungen konkret vortragen2. Hat dies der Unternehmer anhand vorhandener oder nachträglich erstellter Kalkulationsgrundlagen im Einzelnen dargelegt, muss dann der Besteller ggf. darlegen, dass die Kalkulation nicht zutrifft oder etwa von der üblichen Kalkulation in vergleichbaren Fällen abweicht. Das bloße Bestreiten der Kalkulationsgrundlagen mit Nichtwissen reicht nicht3. 1 BGH v. 11.5.2006 – VII ZR 146/04, NZBau 2006, 569. 2 BGH v. 21.12.1995 – VII ZR 198/94, BGHZ 131, 362 = MDR 1996, 581. 3 Vgl. dazu BGH v. 14.1.1999 – VII ZR 277/97, MDR 1999, 672 m. Anm. Hertwig = BB 1999, 926; OLG Oldenburg v. 21.7.1998 – 5 U 36/98, NJW-RR 1999, 1575; OLG München v. 22.6.2004 – 13 U 2315704, NJW-RR 2005, 573.

Redeker

431

437

D Rz. 438

Verträge

438

Diese BGH-Rechtsprechung hat die teilweise den Unternehmern sehr großzügig gegenüberstehende Rechtsprechung der Instanzgerichte deutlich modifiziert. Ein Gericht hat einmal sogar schlicht unterstellt, dass Softwareunternehmer immer an Auftragsüberhang leiden und dadurch überhaupt keine Aufwendungen erspart werden, wenn ein dem Unternehmen erteilter Auftrag gekündigt wird1. Diese Annahme hat so grundsätzlich für alle Unternehmen sicherlich noch nie gegolten. Je nach wirtschaftlicher Situation der Branche insgesamt mag sie für eine Reihe Unternehmen gelten, für die meisten jedoch nicht. Im Übrigen stellt sich bei komplexeren Softwareprodukten immer noch die Frage, ob weitere Aufträge für einen Zeitraum hätte angenommen werden können, zu dem der erste Auftrag nach ursprünglicher Planung noch hätte durchgeführt werden müssen, weil möglicherweise die personellen und sonstigen Kapazitäten des Softwarehauses es nicht erlaubt hätten, den weiteren Auftrag anzunehmen.

439

Als anderweitige Verwendung der Arbeitskraft, die zu abzugsfähigen Erlösen führt, zählen allerdings nur solche Aufträge, die entweder konkret als Ersatzaufträge für den gekündigten Auftrag eingeworben wurden oder wenn sonst Aufträge hätten abgelehnt werden müssen, die nach der Kündigung angenommen werden konnten2. Wird die Arbeitskraft der Mitarbeiter in ohnehin schon vorhandenen Projekten eingesetzt, dürfte als abzugsfähige Aufwendung nicht der Erlös aus diesen Projekten, sondern nur die Allgemeinkosten der Mitarbeiter zu betrachten sein, weil diese ja da nicht fürs Nichtstun bezahlt werden müssen.

440

Die sich aus der oben zitierten Rechtsprechung des BGH ergebenen Konsequenzen für den Unternehmer sind misslich. Nicht nur, dass ein Auftrag ohne Angaben von Gründen vom Auftraggeber gekündigt werden kann – im Bereich der gegenseitigen Verträge außerhalb von Dauerschuldverhältnissen einmalige Rechtsfolge –, vielmehr muss der Unternehmer, will er seine Restvergütung wirksam einklagen, seiner Kalkulationsgrundlagen darlegen. Darüber hinaus muss er noch erwähnen, dass er seine Arbeitnehmer oder auch seine eigene Arbeitskraft nicht anderweitig eingesetzt hat. Damit werden Betriebsgeheimnisse offenbart.

441

Der Gesetzgeber hat durch die Einführung des § 649 Satz 3 BGB versucht, den Unternehmer aus dieser misslichen Lage zu befreien. Er erhält 5 % der Restvergütung ohne weitere Darlegungen. Diese 5 % sind allerdings bei Softwareerstellungsverträgen wenig befriedigend. Die Vorschrift des § 649 BGB soll ja bewirken, dass dem einseitigen Kündigungsrecht des Auftraggebers eine Regelung gegenüber gestellt wird, nach der der Unternehmer die sich aus dem Geschäft ergebenden Gewinne behalten kann. Die Gewinnspanne bei normalen Softwareprojekten liegt sicherlich weit höher als 5 %. Wer als Softwareersteller auch nur annähernd die Rechtsfolge nach dem 1 So LG München I v. 30.4.1992 – 7 O 3607/91, Anlage 3 zu BB 1993, S. 14. 2 Staudinger/Peters/Jacoby, § 649 BGB Rz. 40; OLG Hamm v. 20.11.2003 – 24 U 195/01, BauR 2006, 1310 (1312).

432

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 445 D

Grundgedanken der Regelung des § 649 BGB erhalten will, mithin seinen Gewinnanspruch behalten will, muss daher weiterhin im Prozess seine Kalkulationsgrundlagen in der vom BGH geforderten Weise darlegen. Hilfreich kann eine Regelung in AGB sein, die eine höhere als 5 %ige Pau- 442 schale für den Fall der Kündigung nach § 649 BGB für die Restvergütung festsetzt. Eine solche Pauschale ist zulässig. Die Regelung des § 649 Satz 3 BGB ist hier kein Leitbild1. Der BGH hat aber auch bei Bauverträgen 10 % akzeptiert, bei 18 % aber große Fragezeichen gesetzt. Bei Softwareverträgen dürfte eine Vergütung von 40–50 % vereinbar sein. Notwendig ist nur, dass die Pauschale im Rahmen der normalerweise nach § 649 Satz 2 BGB zu erwartenden Vergütung liegt. Die Klausel muss ferner dem Kunden die Möglichkeit eröffnen, darzulegen, dass die an sich nach § 649 Satz 2 BGB geschuldete Vergütung niedriger liegt als die in der Klausel vereinbarte Pauschale. Insgesamt muss sie den Voraussetzungen der §§ 308 Nr. 7a, 309 Nr. 5b BGB genügen2. Im Werkvertragsrecht ist daneben immer noch erörtert worden, ob im Falle 443 von Leistungsstörungen neben den dann sicherlich gegebenen Rücktrittsmöglichkeiten aus § 323 BGB auch Kündigungsmöglichkeiten bestehen3. Darin besteht aus Sicht des Kunden ein Interesse dann, wenn er schon erbrachte Teilleistungen behalten möchte. Interessant ist hier insbesondere das Kündigungsrecht aus wichtigen Grund des § 314 BGB (vgl. Rz. 424). Dieses Kündigungsrecht besteht nach ständiger Rechtsprechung in Fällen länger andauernder werkvertraglicher Beziehungen auch neben eventuell bestehenden Rücktrittsrechten. Dies gilt insbesondere auch für komplexe Softwareprojekte4. Will der Kunde die erbrachte Teilleistung nicht behalten, dürfte es in aller 444 Regel sinnvoller sein, zurückzutreten. Es wird sogar gefragt, ob ein Kündigungsrecht in einem solchen Fall überhaupt besteht und der Kunde nicht zurücktreten muss, wenn er keine Teilleistung behalten will. Eine entsprechende Erklärung kann allerdings auch ggf. umgedeutet werden. Wann eine Kündigung aus wichtigem Grund möglich und begründet ist, ist 445 im Einzelnen streitig. In der BGH-Rechtsprechung geht es in aller Regel um Fälle, in denen auch ein Rücktritt berechtigt wäre. Einzelne Gerichte haben aber auch schon den bloßen Einbau einer Programmsperre als Kündigungs-

1 BGH v. 5.5.2011 – VII ZR 161/10, BB 2011, 1873 m. Anm. v. Westphalen. 2 Zum Ganzen vgl. auch Redeker, ITRB 2012, 42. 3 Einzig Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 283 f. schließt den Rücktritt aus. 4 BGH v. 25.3.1993 – X ZR 17/92, CR 1993, 759 = MDR 1994, 35 = NJW 1993, 1972; OLG Frankfurt v. 15.12.2000 – 24 U 240/98, CR 2001, 503; Palandt/Sprau, § 649 BGB Rz. 10; kritisch Schmidt, NJW 1995, 1313; Marly, Praxishandbuch Softwarerecht, Rz. 1353; i.E. auch Thewalt, Der Software-Erstellungsvertrag nach der Schuldrechtsreform, S. 276 ff.

Redeker

433

D Rz. 446

Verträge

grund angesehen1. Andere Gerichte haben unter gleichen Voraussetzungen eine Kündigung jedoch abgelehnt2. 446

Für den Fall der Programmsperre dürfte gelten, dass eine Kündigung möglich ist, wenn nach Abmahnung die Programmsperre nicht entfernt wird. Ohne eine solche Abmahnung dürfte ein Kündigungsgrund nur in seltenen Ausnahmefällen vorliegen. Ist die Sperre freilich nach Abmahnung entfernt worden, besteht kein Kündigungsgrund mehr3. Besteht keine Gefahr, dass die Programmsperre bei ordnungsgemäßer Benutzung des Programms aktiviert wird und liegt deswegen nach der Rechtsprechung des BGH schon gar kein Mangel vor, dürfte auch ein nachträglicher Einbau eine Kündigung aus wichtigem Grund nicht begründen.

447

Ein Kündigungsgrund könnte – wie schon erörtert – auch bei der Aufdeckung von Betriebsgeheimnissen vorliegen (vgl. Rz. 424).

448

Die Rechtsprechung neigt im Übrigen dazu, eine Kündigung aus wichtigem Grund bei Nichtvorliegen eines wichtigen Grundes als Kündigung nach § 649 BGB zu behandeln4. Ob dies geht, ist aber streitig5. Die Meinung der Rechtsprechung ist allerdings meist zweckmäßig, weil eine Fortsetzung des Vertrages zum Zeitpunkt der Entscheidung des Rechtsstreits nicht mehr möglich ist. Es geht aber um sehr unterschiedliche Rechtsfolgen, so dass im Einzelfall die Entscheidung sehr genau abgewogen werden muss6.

449

In der Vertragsgestaltung empfiehlt es sich, die Rechtsfolgen von Kündigungen bei komplexen Projekten ausgiebig zu regeln und eventuell je nach Projektfortschritt auch über die gesetzlich gegebenen Möglichkeiten hinaus Teilkündigungsmöglichkeiten, insbesondere unter Verzicht des Unternehmers auf die Rechte aus § 649 BGB vorzusehen. Die Gestaltungsmöglichkeiten sind zahlreich.

450

Ausgeschlossen ist freilich ein völlig freies Kündigungsrecht, das sich der Besteller in seinen eigenen AGB vorbehält. Ein solches Kündigungsrecht war in § 9 Nr. 4 BVB-Überlassung vorgesehen. Es wurde von der Rechtsprechung nicht anerkannt7.

451

Möglich sind freilich Klauseln in AGB, die beiderseitig freie Kündigungsmöglichkeiten nach Fertigstellung einzelner Teilabschnitte vorsehen. Es geht hier um definierte Zeitpunkte und beidseitige Rechte, so dass keine 1 2 3 4 5 6

OLG Düsseldorf v. 30.1.1992 – 5 U 193/90, Beilage Nr. 13 zu BB 1993, S. 6 f. OLG Köln v. 9.8.1985 – 19 U 294/94, OLGReport 1995, 285. A.A. OLG Düsseldorf v. 30.1.1992 – 5 U 193/90, Beilage 13 zu BB 1993, S. 6 f. Z.B. OLG Düsseldorf v. 16.1.1996 – 23 U 78/95, in: Zahrnt, ECR OLG 228. Näher Schmidt, NJW 1995, 1313. Erman/Schwenker, § 649 BGB Rz. 3; vorsichtig Staudinger/Peters/Jacoby, § 649 Rz. 18 f. m.w.N. 7 BGH v. 4.3.1997 – X ZR 141/95, CR 1997, 470 (471 ff.) = MDR 1997, 913 = NJW 1997, 2043 (2044); OLG Köln v. 28.2.1997 – 19 U 194/95, CR 1998, 82 zu einer ähnlichen Klausel.

434

Redeker

Rz. 456 D

Realisierung (Kauf-/Werkvertrag)

unangemessene Benachteiligung vorliegt, auch wenn die Vergütungspflicht des Bestellers nach § 649 BGB ausgeschlossen wird. Immerhin geben diese Klauseln auch klar an, welche Voraussetzungen vorliegen müssen, damit überhaupt eine Kündigung möglich ist. Die Klauseln genügen damit auch den Anforderungen des § 308 Nr. 3 BGB. Ein Werkvertrag mit solchen Klauseln nähert sich allerdings einem Dauerschuldverhältnis an. Wird freilich in den individuellen Vereinbarungen des konkreten Vertrages 452 entweder explizit oder durch den Inhalt klargemacht, dass ein solches Kündigungsrecht nicht besteht, geht diese Individualabrede in den Klauseln den AGB vor. Selbstverständlich kann im Übrigen der Unternehmer seinem Besteller in seinen AGB ein allgemeines und freies Kündigungsrecht gewähren1 oder auch nur auf seinen Verjährungsanspruch für noch nicht erbrachte Leistungen verzichten.

453

IV. Gestaltungsvorschläge Bislang sind zahlreiche Rechtsfragen bei der Gestaltung und Auslegung von 454 Softwareerstellungsverträgen behandelt worden. Sie sollen jetzt ergänzt werden durch Formulierungsvorschläge für einzelne wichtige Probleme. Die jetzt folgenden Formulierungsvorschläge können kein Formularbuch ersetzen, in denen umfassende Vertragswerke dargestellt und kommentiert sind2. Sie sollen nur einzelne wichtige Teilaspekte aufgreifen, die vorstehend behandelt worden sind. 1. Vorvertragliche Regelungen a) Grundsätzliche Bemerkungen Hier ist zunächst auf die ausführlichen Darlegungen im Textteil hinzuweisen (vgl. Rz. 34 ff.).

455

Kurz zusammengefasst muss Folgendes gelten: Will man vorvertragliche For- 456 mulierungen wählen, muss man zunächst wissen, was man damit erreichen will. Es muss geklärt werden, ob man tatsächlich eine vertragliche Bindung erreichen will oder ob es ganz i.S.e. „Letter of intent“ lediglich darum geht, dass eine oder beide Seiten ihre Absichten erklären, ernsthaft zu verhandeln. Ferner muss man wissen, worüber man eine Einigung erzielen möchte. Wichtig sind hier in aller Regel zunächst einmal Geheimhaltungsvereinbarungen (vgl. Rz. 39, 419). Darüber hinaus kann es wichtig sein, bestimmte Absichtserklärungen zu erhalten oder auch schon eine Verpflichtung, dass zunächst Untersuchungen über die Realisierbarkeit des Projektes stattfinden und die sich daraus ergebenden Kosten zwischen den Parteien verteilt werden. Viele 1 OLG Düsseldorf v. 22.9.1994 – 5 U 162/93, in: Zahrnt, ECR OLG 172. 2 Dazu z.B. Redeker (Hrsg.), Handbuch der IT-Verträge, Loseblatt.

Redeker

435

D Rz. 457

Verträge

weitere Gestaltungen sind denkbar. Wichtig ist auch, dass dann, wenn keine Vertragsbindung beabsichtigt ist, sondern wirklich nur die Absicht erklärt wird, ernsthaft zu verhandeln, dies auch formuliert wird. b) Formulierungen aa) Geheimhaltungsvereinbarung 457

Der folgende Vorschlag enthält eine sehr knappe und kurze Geheimhaltungsvereinbarung. Man kann dies auch sehr viel ausführlicher und umfassender formulieren1: Die Parteien stimmen darüber überein, dass der Unternehmer (U) für den Kunden (K) eine Software zur Steuerung der Produktion und Lagerverwaltung herstellt. Um die betriebliche Notwendigkeiten und den Umfang des K zu erteilenden Auftrags zu erkunden, werden zunächst Informationen über bei U schon vorhandenen Softwareprodukte und die Betriebsstrukturen von K ausgetauscht. In diesem Zusammenhang werden wesentliche Betriebsgeheimnisse der jeweiligen Vertragsparteien offenbart.

Beide Parteien verpflichten sich, die Informationen, die sie wegen der beabsichtigten Tätigkeit im Zusammenhang mit der Erstellung der Software von der Gegenseite erhalten, vertraulich zu behandeln und nur zur Prüfung des notwendigen Umfangs und der Kosten eines Softwareerstellungsvertrages zu verwenden. Keine Partei ist berechtigt, die Informationen ganz oder teilweise zu anderen als den soeben genannten Zwecken zu nutzen oder diese Dritten zugänglich zu machen. Die vorstehende Verpflichtung gilt nicht für Informationen, die eine der Parteien nachweisbar von Dritten erhalten hat, ohne zur Geheimhaltung verpflichtet zu sein, oder die öffentlich bekannt sind.

458

Diese grundsätzliche Verpflichtung kann man z.B. durch eine Vertragsstrafenvereinbarung ergänzen, die lauten könnte:

Beide Parteien verpflichten sich, für jeden Fall schuldhaften Verstoßes gegen eine der in dieser Vereinbarung genannten Verpflichtungen eine Vertragsstrafe in Höhe von … Euro zu zahlen.

bb) Aufwandsvereinbarung 459

Schon aus der vorstehenden Vereinbarung ergibt sich, dass beide Parteien im Wege der Vertragsvorbereitungen Aufwand betreiben, der natürlich Kos1 Ein weiteres Formular bei Redeker, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 6.4; vgl. auch Intveen, ITRB 2007, 259.

436

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 462 D

ten verursacht. Es bietet sich daher an, zu regeln, wer für den Fall, dass eine Zusammenarbeit nicht zustande kommt, die Kosten trägt. Hier sind vielerlei Vereinbarungen möglich. Eine Vereinbarung, nach der jede Partei ihren Aufwand selbst tragen soll, kann wie folgt lauten:

460

Für den Fall, dass kein Softwareerstellungsvertrag zwischen den Parteien zustande kommt, trägt jede Partei den im Rahmen der Vertragsvorbereitung angefallenen Aufwand selbst.

Selbstverständlich kann auch vereinbart werden, dass ein bestimmter Auf- 461 wand bis zu einer bestimmten Größenordnung oder gar der gesamte Aufwand vom Kunden zu tragen ist. Es wäre dann allerdings sinnvoll, dass der Kunde auch die Rechte an eventuell entstandenen Materialien, Aufwandsschätzungen und Ähnlichem erhält. Eine Klausel könnte wie folgt lauten:

Dem Unternehmer entstehen im Zusammenhang mit den Vertragsverhandlungen im Hinblick auf die Ermittlung des notwendigen Aufwands zur Erstellung der für den Kunden relevanten Software erhebliche Aufwendungen. Sollte es nicht zu einer Auftragserteilung kommen, erhält der Unternehmer daher vom Kunden eine Entschädigung für den betriebenen Aufwand bis zu einer Höchstgrenze von … Euro. Dabei wird der Personentag mit … Euro vergütet. Eventuell entstehende Fahrtkosten und sonstige berechtigte Auslagen werden getrennt ersetzt. Der Kunde erhält Zug um Zug gegen Zahlung dieser Vergütung sämtliche speziell im Rahmen der beabsichtigten Zusammenarbeit mit dem Kunden entstandenen Unterlagen des Unternehmers.

Auch im Hinblick auf den Hauptvertrag können folgende verschiedene Regelungen zustande kommen. Man könnte z.B. wie folgt formulieren:

Durch die Zusammenarbeit im Rahmen der Aufwandsermittlung für eine eventuell beauftragte Softwareerstellung verpflichten sich die Parteien nicht dazu, einen Softwareerstellungsvertrag untereinander abzuschließen.

Redeker

437

462

D Rz. 463 463

Verträge

Man kann auch so formulieren:

Ergibt sich bei der Aufwandsschätzung, dass die Erstellung der Software zu dem Preis von bis zu … Euro möglich ist und bietet das Unternehmen die Erstellung der Software mit einer vom Kunden akzeptierten Leistungsbeschreibung zu einem Preis von bis zu … Euro an, ist der Kunde verpflichtet, ein auf dieser Basis vom Unternehmer erstelltes Angebot anzunehmen.

464

Bei letztgenannter Formulierung gibt es allerdings erhebliche Probleme. Hier sind die Rahmenbedingungen des Vertrages mit Ausnahme von Leistung und Preis nicht genannt. Dies gilt z.B. für eventuelle Gewährleistungsregelungen, Haftungsbegrenzungen und Ähnliches.

465

Will man insoweit eine Bindung erzielen, müsste man in die Anlage zu einem solchen Vorvertrag detaillierte Vertragsklauseln, im Prinzip einen fertigen Vertragsentwurf, aufnehmen und erklären, dass der Kunde dann, wenn der Unternehmer auf Basis einer vom Kunden akzeptierten Leistungsbeschreibung und der in der Anlage beigefügten Vertragsbedingungen ein Angebot für einen Preis von bis zu … Euro abgibt, zur Annahme des Angebots verpflichtet ist. Auch solche Klauseln sind selbstverständlich denkbar. 2. Organisationsregeln a) Umfassende Regeln

466

Auch die Organisation des Projektes sollte vertraglich vereinbart werden. Auch hier können in dem hier gebotenen Rahmen nur Standardorganisationsstrukturen vorgeschlagen werden. In der Praxis haben sich eine Vielzahl verschiedenster Organisationsmodelle entwickelt. Welche man im Projekt auch immer wählt; sie sollte im Vertrag abgebildet werden. Die getroffene Organisationsregelung sollte dann auch eingehalten werden.

467

Eine etwas längere Klausel könnte wie folgt lauten:

Jede der Vertragsparteien benennt für die Dauer des Projektes einen Projektleiter sowie dessen Stellvertreter. Scheidet eine der vorgenannten Personen aus dem Unternehmen aus oder fällt sie auf absehbar lange Zeit aus, ist eine Ersatzperson zu benennen. Die Realisierung des Projektes wird zwischen den Projektleitern abgestimmt. Die Projektverantwortung liegt jedoch beim Auftragnehmer. Die jeweiligen Projektleiter sind binnen einer Frist von einer Woche nach Vertragsschluss dem jeweiligen Vertragspartner gegenüber schriftlich zu benennen. Auch die Ersatzbenennung erfolgt schriftlich. Die Projektleiter überprüfen mindestens wöchentlich gemeinsam den Projektfortschritt.

438

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 471 D

Die Projektleiter der Parteien und deren Stellvertreter sind zur Entgegennahme sämtlicher Erklärungen im Zusammenhang mit diesem Vertrag befugt. Demgegenüber sind sie nicht zur Abgabe sämtlicher Erklärungen befugt. Sie sind aber berechtigt, die im laufenden Betrieb notwendig werdenden Entscheidungen zu fällen, soweit damit keine Änderungen des Vertragsumfangs, der Vertragsbedingungen oder der Gegenleistungen verbunden sind. Sie bereiten notwendige Entscheidungen vor und sorgen für eine möglichst rasche Herbeiführung der Entscheidungen in den Bereichen, wo sie selbst nicht vertretungsberechtigt sind. Soweit Entscheidungen nicht auf der Ebene der Projektleiter gefällt werden können, werden sie in einem Projektlenkungsausschuss gefällt. Diesem Projektlenkungsausschuss gehört ein Mitglied der Geschäftsleitung beider Seiten oder ein für das Softwareerstellungsprojekt entscheidungsbefugter sonstiger Mitarbeiter der jeweiligen Vertragsparteien an. Der Projektlenkungsausschuss tritt zu jeder Zeit auf Wunsch eines der Projektleiter zusammen. Abstimmungen können auch telefonisch erfolgen. Alle Beschlüsse sollen schriftlich festgehalten und von den Mitgliedern des Projektlenkungsausschusses unterzeichnet werden.

Eine solche Organisationsstruktur kann in jedem Vertrag – auch in AGB – 468 vereinbart werden. Die Klauseln werden in der Praxis oft ergänzt durch Klauseln, die die Qualifikation der Projektleiter festlegen und dem Vertragspartner (insbesondere dem Kunden) einen Anspruch auf Abberufung von Projektleitern bei mangelnder Qualifikation oder sonstigen Gründen geben1.

469

Eine solche Klausel sollte allerdings sorgfältig bedacht werden. Die Erfolgs- 470 verantwortung in einem normalen Softwareerstellungsvertrag liegt beim Unternehmer, da es sich um Werkverträge oder Werkverträge mit kaufrechtlichem Einschlag handelt. Demgemäß sollte die Verantwortung für die Qualifikation seiner Mitarbeiter letztendlich auch beim Unternehmer verbleiben. Es macht sachlich oft keinen Sinn, hier zusätzliches Konfliktpotential aufzubauen, in dem Nachweise über Qualifikationen verlangt werden, die dann auch noch prüfbar werden. In sehr großen Projekten, in denen beiderseits ein erheblicher Aufwand betrieben wird, mag dies für Schlüsselpositionen allerdings gelegentlich anders sein. Eine entsprechende Klausel in AGB des Kunden dürfte angesichts der Verantwortungsverteilung und des Kostenrisikos, die bei Werkverträgen nun einmal auf Unternehmerseite sind, unangemessen i.S.v. § 307 BGB sein2. In AGB sind diese Klauseln daher unwirksam.

1 Vgl. die Klausel von Witte, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 1.4, § 6. 2 Redeker, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 11 Rz. 188.

Redeker

439

471

D Rz. 472 472

Verträge

Umgekehrt kann natürlich auch das Unternehmen verlangen, dass die Mitarbeiter des Kunden besonders sachkundig sind. Hier gilt sinngemäß das Gleiche. In Einzelfällen mag eine Individualvereinbarung sinnvoll sein. In AGB sind solche Klauseln schon deswegen nicht vereinbar, weil keinesfalls bei allen Kunden entsprechend sachkundige Mitarbeiter vorhanden sind und man allenfalls im Vorfeld überlegen muss, wie man mit dem vorhandenen Mitarbeiterstamm die Mitwirkungsnotwendigkeiten erreichen kann, die notwendig sind, damit das Projekt ordnungsgemäß abgewickelt werden kann. Hier entstehen ggf. sogar Beratungspflichten des Softwareerstellers (vgl. Rz. 10). Hier dem Kunden einseitig durch AGB besonders qualifizierte Mitarbeiter vorschreiben zu wollen, ist eindeutig unzulässig. b) Vereinfachte Regelungen für einfache Projekte

473

In der Folge eine relativ kurze Regelung, die für einfache Projekte sicher ausreichend ist:

Beide Parteien benennen zu Beginn des Projekts schriftlich einen Projektleiter. Die Projektleiter treffen sich regelmäßig, beurteilen den Projektfortschritt und treffen notwendige Projektentscheidungen. Getroffene Entscheidungen sollen tunlichst schriftlich festgehalten werden.

Hier wird das Verfahren eindeutig vereinfacht. Ein solches Vorgehen bietet sich insbesondere bei nicht so großen und wichtigen Projekten an, wo den Projektleitern die letzte Entscheidung übertragen werden kann. 3. Change-Request-Verfahren a) Bedeutung der Regelung 474

Wie schon dargestellt, ist kein Softwareprojekt mit Vertragsabschluss abgeschlossen (vgl. Rz. 156 ff.). Immer wieder wird es im Laufe des Vertragsabschlusses Wünsche auf Änderung des Vertragsinhalts geben. Zur Abstimmung solcher Wünsche muss zwischen den Parteien ein Verfahren vereinbart werden. Dies wird in der Praxis als Change-Request-Verfahren bezeichnet. Auch hier kann man unterschiedlich lange, teilweise sehr umfangreiche, teilweise sehr kurze Regelungen treffen.

475

In der oben erwähnten Regelung 2b (vgl. Rz. 473) ist bei einfachen Projekten das Change-Request-Verfahren insoweit geregelt, als die Projektleiter gemeinsam jederzeit Vertragsänderungen beschließen können. Bei komplexeren Projekten bedarf es weitergehender Entscheidungen. Eine, nicht allzu komplizierte Klausel könnte wie folgt lauten:

440

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 477 D

Änderungen im Umfang der Leistungen, im Preis oder in sonstigen Vertragsbedingungen können jederzeit einvernehmlich zwischen den Projektleitern vereinbart werden. Entsprechend können Änderungen auch im Projektlenkungsausschuss vereinbart werden. Werden in diesen Fällen keine Preisänderungen und keine Änderungen der Vertragsbedingungen vereinbart, müssen die geänderten Leistungen im Rahmen der bis dahin vereinbarten Vertragsbedingungen durchgeführt werden.

Jedenfalls hier sollte eine Schriftformklausel hinzukommen (sogleich Rz. 477 ff.). Ein etwas komplizierteres, möglicherweise neben dieses einfache Ände- 476 rungsverfahren tretendes weiteres Änderungsverfahren könnte wie folgt lauten:

Der Auftraggeber kann bis zur Abnahme schriftlich die Änderung der vereinbarten Anforderung an die Programme verlangen. Zu diesem Änderungsverlangen wird sich der Auftragnehmer binnen einer Frist von zwei Kalendertagen ab Zugang des Änderungsverlangens äußern. Äußert er sich nicht, verbleibt es bei der bisherigen Regelung.

Auch hier sind zahlreiche verschiedene Variationen dieser Klausel denkbar1. b) Möglichkeiten von Schriftformklauseln Über die Möglichkeiten von Schriftformklauseln ist schon verschiedenes 477 ausgeführt worden. Der BGH hat in mehreren Entscheidungen festgehalten, dass Klauseln in AGB, die für Änderungen in der Zukunft die Schriftform vorsehen, unwirksam sind2. Sie sollen die Vertragsfreiheit zu sehr beschneiden und auch im Übrigen nicht wirksam sein. Marly3 hält unter expliziter Verwendung einzelner Formulierungen des BGH Schriftformklauseln u.a. dann für unwirksam, wenn sie den Eindruck erwecken, mündliche Abreden seien unwirksam. Da dies der Zweck von Schriftformklauseln ist, dürften sie nach Ansicht von Marly immer unwirksam sein. 1 Eine andere bei Redeker, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 1.6, § 2 Abs. 3 oder bei Schmidt, in: Redeker (Hrsg.), Handbuch der ITVerträge, Abschn. 1.5, § 28; sehr umfassend auch die Klausel in Nr. 16 EVB-IT System. 2 BGH v. 31.10.1984 – VIII ZR 226/83, NJW 1985, 320 (321); BGH, Urt. v. 21.9.2005 – XII ZR 312/02, MDR 2006, 508. 3 Marly, Praxishandbuch Softwarerecht, Rz. 984; ebenso BGH v. 27.9.2000 – VIII ZR 155/99, MDR 2001, 144 = NJW 2001, 292.

Redeker

441

D Rz. 478

Verträge

478

Im Zwischenunternehmensverkehr bei großen Softwareprojekten ist die Argumentation des BGH (und auch die Ansicht von Marly) allerdings wenig überzeugend. Es spricht die Projektsicherheit dafür, dass jedenfalls es nicht unangemessen ist, wenn man solche Klauseln aufnimmt. Schließlich soll durch solche Klauseln Sorge dafür getragen werden, dass in umfangreichen Projekten Klarheit über die getroffenen Vereinbarungen entsteht. Angesichts der Rechtsprechung des BGH, die von der Begründung her keinerlei Einschränkung auf Verbraucherschutz oder ähnliche Dinge enthält, ist es aber höchst zweifelhaft, ob solche Klauseln wirksam sind1.

479

Als individuell ausgehandelte Vereinbarungen sind diese Klauseln wirksam. Man müsste dann allerdings eine Vereinbarung über die Aufhebung der Schriftform auch dem Schriftformerfordernis unterwerfen, weil die Rechtsprechung sonst dazu neigt, jede mündlich getroffene Vereinbarung inhaltlich mit einer konkludent geschlossenen Vereinbarung über die Aufhebung der Schriftformklausel zu verbinden und damit diese mündliche Vereinbarung trotz Schriftformklausel für wirksam zu erklären2.

480

Die Schriftformklausel könnte – soweit man sie vereinbaren will oder sie in AGB für zulässig hält – wie folgt lauten:

Vereinbarungen, die den Vertragsinhalt, die Leistungsbeschreibung oder andere Vertragsumstände betreffen, sind zwischen den Parteien schriftlich zu treffen. Dieses Schriftformerfordernis gilt auch für die Aufhebung der Schriftform.

4. Geltendmachung von Rechten durch Dritte a) Problemstellung 481

Schutzrechtsprobleme sind eine typische Situation beim Softwareerwerb. Es kann immer wieder sein, dass ein Kunde die von ihm erworbene Software bei sich einsetzt, ein Dritter davon Kenntnis erhält und dem Kunden gegenüber geltend macht, ihm stehe ein Nutzungsrecht an der ganzen Software oder an Teilen der Software zu. Der Kunde kann sich nicht auf gutgläubigen Erwerb abstützen, weil es einen solchen bei Urheberrechten nicht gibt. Er ist damit Ansprüchen Dritter ausgesetzt.

482

Sollten diese Ansprüche berechtigt sein, hat er Ansprüche gegen seinen Lieferanten, in aller Regel wegen Rechtsmängelhaftung, ggf. aber auch noch aus Unmöglichkeitsgesichtspunkten (vgl. Rz. 351 ff.). Sollten allerdings die

1 So auch BAG v. 20.5.2008 – 9 AZR 382/07, DB 2008, 2365. 2 Ähnlich Graf von Westphalen, in: Graf von Westphalen, Vertragsrecht und AGBKlauselwerke, Schriftformklauseln, Rz. 5; zum Ganzen ausführlich Redeker, ITRB 2004, 15.

442

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 487 D

Ansprüche des Dritten nicht bestehen, hat er gegen seinen Lieferanten keine Ansprüche. Er selbst wird die Situation oft nicht beurteilen können. Dies ist schon bei 483 einfachen Schwarzkopien oft schwierig, wenn nicht anhand der Lizenzdokumente klar erkennbar ist, ob es sich um Fälschungen handelt oder nicht. In anderen Fällen ist zunächst nicht klar, ob dem Dritten überhaupt Rechte an der Software zustehen und wie die Lizenzsituation in der gesamten Kette der Vorlieferanten ist. All dieses kann auch bei Softwareerstellung geschehen, wenn es um Bibliotheksprogramme oder um Standardteile anderer Art in der gelieferten Software gehen kann. In dieser Situation ist es zweckmäßig, dass der Kunde und der Lieferant miteinander zusammenarbeiten, um angemessen auf die Ansprüche des Dritten zu reagieren. b) Regelungsmöglichkeiten aa) Prozessuale Situation ohne Regelung Gibt es zwischen dem Lieferanten und dem Kunden keinerlei Vereinbarun- 484 gen, stellt sich die prozessuale Situation so dar: Der Dritte kann gegen den Kunden unmittelbar mit Unterlassungsansprüchen, in Einzelfällen auch mit Schadensersatzansprüchen vorgehen. Der Kunde kann in diesem Prozess dem Lieferanten den Streit verkünden mit dem Bemerken, dass dann, wenn der Dritte gewinnt, er ja Ansprüche gegen den Lieferanten hat. Sollte der Kunde unterliegen, wird er die Ansprüche gegen den Lieferanten dann in einem weiteren Prozess durchsetzen müssen. Der Kunde kann auch den Unterlassungsansprüchen des Dritten zunächst 485 nachgeben und die Software aus dem Produktivbetrieb nehmen. Er kann dann den Lieferanten im Hinblick auf eigene Ansprüche verklagen und dabei dem Dritten den Streit verkünden. Sollte er dem Lieferanten gegenüber unterliegen, weil dem Dritten keine Rechte zustehen, kann er den Dritten dann wegen unberechtigter Schuldrechtsverwarnung1 in Anspruch nehmen. In jedem Fall muss der Kunde aber zwei Prozesse führen, wobei es bei Unsi- 486 cherheit über die Rechtslage oft einfacher ist, die erste Konstellation auszuhalten, wobei allerdings dabei das Schadensersatzrisiko dem Dritten gegenüber höher ist. Die doppelte Prozessführung ist in diesem Zusammenhang aber unvermeidlich. bb) Regelungsmöglichkeiten Um eine solche doppelte Prozessführung möglichst zu vermeiden, sollte 487 zwischen Lieferanten und Kunden ein Verfahren vereinbart werden, das in Fällen der Drittansprüche gilt.

1 Dazu Baumbach/Hefermehl/Köhler, Wettbewerbsrecht, § 4 Rz. 10.169 ff.

Redeker

443

D Rz. 488 488

Verträge

Eine Formulierung könnte wie folgt lauten1:

Macht ein Dritter wegen der vom Lieferanten gelieferten Software dem Kunden gegenüber Ansprüche aus Patenten, Urheberrechten oder sonstigen gewerblichen Schutzrechten geltend, übernimmt der Lieferant auf seine Kosten die Vertretung des Kunden in jedem gegen diesen geführten Rechtsstreit und stellt den Kunden hinsichtlich der Drittansprüche frei. Dies gilt allerdings nur dann, wenn der Kunde den Lieferanten über entsprechende Anspruchsschreiben Dritter und Einzelheiten etwaiger Rechtsschritte unverzüglich in Kenntnis setzt und dem Lieferanten sämtliche Entscheidungen hinsichtlich der weiteren Verwendung der vom Dritten angegebenen Software, der Rechtsverteidigung sowie eines Vergleichsabschlusses überlässt und bei Unterrichtung des Lieferanten Ansprüche des Kunden gegenüber dem Lieferanten wegen Rechtsmängeln oder aus anderen Gründen nicht schon verjährt sind.

489

Die vorstehende Formulierung enthält ein Angebot an den Kunden, mit dem dieser dann, wenn er dies möchte, mit dem Lieferanten gemeinsam die Ansprüche Dritter abwehrt. Dazu gehört auch die Möglichkeit, diese Ansprüche als berechtigt anzuerkennen. Die Entscheidung hierüber trifft der Lieferant. Prozesse werden aber auf seine Kosten geführt. Erkennt der Lieferant die Ansprüche an oder wird der Prozess verloren, ist er zur Freistellung unabhängig vom Verschulden verpflichtet. Dies geht freilich über die gesetzliche Regelung hinaus. Insoweit könnte man eine Freistellung auch entsprechend auf Fälle des Vertretenmüssens beschränken.

490

Demgegenüber ist eine Einschränkung im Hinblick auf die Verjährung aufgenommen worden. Sollte man die Verjährungsfrist für Rechtsmittel im Gegensatz zur hier vertretenen Ansicht für länger halten, führt die Klausel ja auch nur dazu, dass die längere Verjährungsfrist gilt.

491

Die Klausel schließt nicht aus, dass der Kunde nicht informiert und die Möglichkeiten der doppelten Prozessführung mit der Streitverkündung ausnutzt.

492

Wegen dieser zusätzlichen Möglichkeiten dürfte eine solche Klausel in AGB des Lieferanten jederzeit möglich sein. Will der Kunde eine solche Klausel verwenden, ist dies im Prinzip auch möglich. Er muss diese so formulieren, dass der Lieferant nicht auf diesem Wege zusätzlichen Ansprüchen ausgesetzt ist. Insbesondere kann hier eine Haftung des Lieferanten nur bei Verschulden oder anderer Art des Vertretenmüssen gegeben sein.

493

Gelegentlich findet man in Klauseln der vorliegenden Art auch das Recht des Lieferanten, die Prozessvertreter des Kunden auszuwählen. Eine solche Klausel ist allerdings zweifelhaft, weil die Auswahl seiner Anwälte wohl 1 Dazu näher Redeker, ITRB 2004, 69.

444

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 496 D

dem Kunden überlassen bleiben muss, obwohl die Anwälte des Kunden auf dessen Wusch die Regelung der Klausel zu akzeptieren haben1. 5. Abnahmeklauseln Klauseln über Abnahmen haben neben den oben genannten Wirksamkeitsproblemen bestimmte Inhalte, die im Einzelnen schon oben (Rz. 196 ff., 217 ff.) dargelegt worden sind.

494

Eine umfassende Klausel kann an dieser Stelle nicht dargestellt werden. 495 Wohl aber kann folgende Formulierung vorgeschlagen werden, die zumindest Grundstrukturen der Abnahme regelt:

Nach Fertigstellung und Installation der Software wird die Software abgenommen. Der Auftraggeber wird die Software binnen einer Frist von einem Monat nach dem Zeitpunkt abnehmen, zu dem der Unternehmer die Funktionsfähigkeit der Software schriftlich mitgeteilt hat. Sollte der Unternehmer auch die Installation der Software schulden, beginnt die Frist mit fertiger Installation der Software und einer entsprechenden schriftlichen Anzeige darüber. Die Abnahme der Leistung setzt eine Funktionsprüfung voraus. Die Funktionsprüfung ist erfolgreich durchgeführt, wenn die Software die vereinbarten Anforderungen erfüllt. Art, Umfang und Dauer der Funktionsprüfung werden von den Projektleitern vor Durchführung festgelegt, soweit eine entsprechende Vereinbarung nicht schon in der Leistungsbeschreibung oder anderen Anlagen zum Vertrag dargestellt ist. Während der Funktionsprüfung wird der Auftraggeber dem Auftragnehmer alle auftretenden Abweichungen der gelieferten Anpassungsleitung von den Leistungsanforderungen unverzüglich mitteilen. Wird die Funktionsprüfung erfolgreich durchgeführt, ist die Abnahme unverzüglich zu erklären. Eine Funktionsprüfung ist dann erfolgreich, wenn entweder keine Mängel, nur unwesentliche Mängel oder sämtliche Abnahmekriterien vorliegen, die zwischen den Projektleitern vor Durchführung der Abnahme vereinbart wurden. Erklärt der Auftraggeber nicht fristgerecht die Abnahme, kann der Auftragnehmer eine angemessene Frist zur Abgabe der Erklärung setzen. Die Software gilt mit Ablauf der Frist als abgenommen, wenn der Auftragnehmer weder die Abnahme schriftlich erklärt noch dem Auftragnehmer schriftlich darlegt, welche Mängel noch zu beseitigen sind. Auf diese Rechtsfolge wird der Auftraggeber den Auftragnehmer bei Fristsetzung hinweisen.

Diese Klausel greift neben den oben genannten grundsätzlichen Problemen 496 die Möglichkeit auf, dass das Verfahren der Funktionsprüfung und die 1 Näher dazu Redeker, ITRB 2004, 69 (71).

Redeker

445

D Rz. 497

Verträge

Abnahmekriterien zwischen den Projektleitern oder auch in den Anlagen zum Vertrag vorher vereinbart wird. Dies erscheint äußerst wichtig (vgl. Rz. 204 f.). 497

In einer solch allgemeinen Klausel lassen sich allgemeine Kriterien zur Abnahme oder auch nur Verfahrensarten nicht generell regeln. Die Klausel ist in dieser Formulierung prinzipiell als AGB denkbar. Denkbar wäre es auch, etwa eine gemeinsame Abnahme durch beide Parteien festzulegen. Dies dürfte aber in AGB nicht gehen (vgl. Rz. 205).

498

In der Klausel enthalten ist ferner noch der Hinweis, dass auf die Folgen der Fristsetzung bei (bei Schweigen gilt Abnahme als erteilt) hingewiesen wird. Ob diese sich aus § 308 Nr. 5 BGB ergebende AGB-rechtliche Voraussetzung angesichts der inhaltlich gleichen Regelung des § 640 Abs. 1 Satz 3 BGB notwendig ist, ist unklar (vgl. Rz. 216). Aus Vorsichtsgründen sollte eine solche Formulierung aber aufgenommen werden. Es muss dann allerdings sichergestellt werden, dass der entsprechende Hinweis bei Fristsetzung dem Vertragspartner gegenüber auch erklärt wird. 6. Verjährungsklauseln

499

Verjährungsklauseln verfolgen in aller Regel den Zweck, auf Seiten des Lieferanten die Verjährung zu verkürzen. Gelegentlich wird in Einkaufsbedingungen auch die Verjährung verlängert. Eine solche Verlängerung ist in Maßen möglich. Der BGH hat eine Verlängerung auf 36 Monate im Kaufrecht zugelassen1. a) Bei der Erstellung von Software

500

Bei der Erstellung von Software kann die Verjährungsfrist wie üblich auf ein Jahr ab Verjährungsbeginn verkürzt werden. Dies hilft allerdings praktisch kaum weiter, da das Problem nicht in der zweijährigen Verjährungsfrist, sondern darin liegt, dass der Beginn der Verjährung erst bei Kenntnis des Mangels eintritt, genauer gesagt mit Ende des Jahres, in dem der Kunde den Mangel erkennt. Dass er dann binnen eines Jahres verjährungshemmende Maßnahmen ergreift, dürfte Normalfall sein. Das Problem besteht, dass die Kenntnis ja erst nach vier oder fünf Jahren eintreten kann. Dass sich daraus ergebende Problem lässt sich nicht generell lösen. Bei einer Regelung in allgemeinen Geschäftsbedingungen kann zwar theoretisch auch der Beginn der Verjährung geregelt werden. Dies muss aber so erfolgen, dass diese Regelung in keinem Fall zu einer übermäßigen Verkürzung der Verjährung führt. Praktisch macht diese Situation Regelungen zum Beginn der Verjährung kaum möglich (vgl. oben Rz. 339).

501

Es wird daher nur eine Verkürzung der Verjährung auf ein Jahr ab gesetzlichem Verjährungsbeginn vorgeschlagen. Dabei werden wiederum Schadens1 BGH v. 5.10.2005 – VIII ZR 16/05, NJW 2006, 47.

446

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 504 D

ersatzansprüche ausgenommen, weil die Verkürzung der Verjährung bei Schadensersatzansprüchen wiederum eine Einschränkung des Schadensersatzanspruchs darstellen kann, der den Regelungen zur Begrenzung von Schadensersatzansprüchen unterliegt1. Der Text könnte wie folgt lauten:

502

Ansprüche wegen Mängeln an der Software, seien es Sach- oder Rechtsmängel, verjähren in einem Jahr ab gesetzlichem Verjährungsbeginn. Dies gilt nicht für Schadensersatzansprüche.

b) Bei Anwendung des § 651 BGB Kommt man zur Anwendung des § 651 BGB, ist der Beginn der Verjährung 503 kein Problem mehr, jedenfalls nicht für Sachmängel. Bei Rechtsmängeln gibt es aber ein Problem. Wie schon oben (Rz. 361) ausgeführt, kann jedoch bei Rechtsmängeln die Frist auch von Kundenseite dahingehend verlängert werden, dass die Verjährungsfrist zwar verkürzt wird, aber der Verjährungsbeginn hinausgeschoben wird auf den Fall der Kenntnis. Diese Situation ist interessengerecht, weil der Kunde in vielen Fällen sonst schutzlos Ansprüchen Dritter ausgesetzt ist. Ob die Klausel freilich einer AGB-rechtlichen Prüfung standhält, ist offen2. Die Klausel für die Kürzung der gesetzlichen Verjährung auf ein Jahr kann genauso formuliert werden wie beim Werkvertragsrecht. Hinsichtlich von Rechtsmängeln kann man folgende Klausel formulieren:

Die Verjährung hinsichtlich von Rechtsmängeln beginnt sechs Monate ab dem Zeitpunkt, zu dem ein Dritter Ansprüche wegen Rechtsmängeln gegenüber dem Besteller geltend macht oder der Besteller sonst von dem Rechtsmangel erfährt. Die Verjährungsfrist endet allerdings frühestens ein Jahr nach Ablieferung der Software.

Eine Klausel zur Verlängerung der Verjährung für Rechtsmängel könnte wie folgt lauten:

Die Verjährungsfrist für Rechtsmängel beträgt 36 Monate.

1 Ulmer/Brandner/Hensen/Christensen, § 309 Nr. 7 BGB Rz. 28. 2 Näher Redeker, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 11 Rz. 89.

Redeker

447

504

D Rz. 505

Verträge

7. Mängelrechte 505

Hinsichtlich von Mängelrechten gibt es Klauseln in großem Umfang. a) Umfassende Klauseln

506

Es ist allerdings nicht empfehlenswert, nach neuem Recht umfassende Sachmängelklauseln zu formulieren. Wie oben dargelegt, gibt es relativ differenzierte Mängelgewährleistungsrechte. Es gibt zwei Formen der Nacherfüllung, nämlich Nachbesserung und Nachlieferung. Es gibt Fälle, in denen eine der beiden Nacherfüllungsfälle wegen Unzumutbarkeit nicht gegeben ist. Es gibt Fragen des Wahlrechts. Es gibt Unmöglichkeitsregeln auch im Hinblick auf Nacherfüllungsansprüche. Diese gesamte gesetzliche Regelung abzubilden, ist so komplex, dass eine entsprechende Klausel vermutlich an der Unklarheitenregelung des § 307 Abs. 1 Satz 2 BGB scheitert1. Man kann die Klauseln auch einfacher fassen. In diesem Fall besteht allerdings die Gefahr, dass sich der Unternehmer selbst einzelner Rechte begibt, die ihm die gesetzliche Regelung zur Verweigerung einzelner Nacherfüllungsansprüche gibt. Es macht daher aus Unternehmersicht keinen Sinn, die Sachmängelgewährleistungsansprüche in AGB umfassend zu regeln. Dennoch sind einzelne Regelungen sinnvoll. b) Klauseln zur Nacherfüllungspflicht aa) Inhalt der Nacherfüllungspflicht

507

Was genau Inhalt der Nacherfüllungspflicht ist, ist im Softwarerecht zweifelhaft. Wichtig ist hier immer die Frage der Fehlerumgehungsmöglichkeiten. Keine Software wird ganz mangelfrei sein. Viele Fehler lassen sich aber durch einen etwas anderen Einsatz der Software so umgehen, dass die Software vernünftig und ohne größere Einschränkungen genutzt werden kann, ohne dass umfassende Neuprogrammierungen erforderlich sind, die dann wiederum möglicherweise zu Mängeln und Problemen an anderen Stellen führen.

508

Es ist daher empfehlenswert, folgende Klausel in den Vertrag aufzunehmen:

Ist der Hersteller zur Mangelbeseitigung oder fehlerfreien Neulieferung nicht in der Lage, wird er dem Auftraggeber Fehlerumgehungsmöglichkeiten aufzeigen. Soweit diese dem Auftraggeber zumutbar sind, gelten sie als Nacherfüllung.

1 Dazu Redeker, ITRB 2004, 163.

448

Redeker

Realisierung (Kauf-/Werkvertrag)

Rz. 514 D

Als individuelle Vereinbarung ist diese Klausel wirksam. Ob sie auch als 509 AGB wirksam ist, ist zweifelhaft. Aus hier vertretener Sicht ist es so, dass eine Mangelbeseitigung i.S.d. Gesetzes auch im Aufzeigen zumutbarer Umgehungsmöglichkeiten besteht. Alles andere ist mit der Realität der Softwareerstellung nicht vereinbar. Wichtig ist allerdings, dass die Umgehungsmöglichkeiten zumutbar sind, d.h. den Kunden nicht zu Umorganisationen in seinem Betrieb zwingen und nicht zu mehr als unerheblichen Verzögerungen in der Sachbearbeitung führen. Folgt man dieser Meinung, gibt die Vereinbarung nur die Rechtssituation wieder und kann daher auch als AGB vereinbart sein. Möglicherweise hilft es, die Umgehungslösung nur als Zwischenlösung bis zum nächsten Update vorzusehen, mit dem der Fehler dann behoben wird1. Geht man aber davon aus, dass es sich hier um eine Einschränkung des 510 Nachbesserungsanspruchs handelt, ist die Klausel gem. § 309 Nr. 8b bb BGB unwirksam. bb) Wahlmöglichkeiten Wichtig ist auch, dass der Softwareersteller das Wahlrecht über die Art der 511 Nacherfüllung hat, also darüber wählen kann, ob er die Software nachbessert oder eine neue nachliefert. Rein technisch gibt es viele Situationen, wo sich die beiden Nacherfüllungsarten nicht unterscheiden. Im Einzelfall kann dies aber anders sein. Soweit Werkvertragsrecht gilt, liegt das Wahlrecht ohnehin beim Softwareersteller. Soweit Kaufvertragsrecht gilt, liegt es eigentlich beim Kunden. Außerhalb des Verbrauchsgüterkaufes kann das Wahlrecht aber auch durch AGB dem Hersteller übertragen werden. Es gibt keinen Anlass anzunehmen, dass dies beim Werkvertragsrecht der gesetzliche Regelfall ist und in einem praktisch gleich gelagerten Fall, bei dem nur wegen der Regelung des § 651 BGB Kaufrecht gilt, ein solches Wahlrecht auf Seiten des Unternehmers plötzlich so unverhältnismäßig sein kann, dass es in AGB nicht vereinbart werden kann (vgl. Rz. 365 f.). Die Klausel kann daher wie folgt lauten:

512

Das Wahlrecht über die Art der Nacherfüllung steht dem Unternehmer zu.

8. Schadensersatzansprüche Wichtig in der Praxis sind Klauseln über Schadensersatzansprüche. Jedenfalls wird in der Beratungspraxis darüber immer gesprochen.

513

Hier ist es dringend zu empfehlen, individuelle Vereinbarungen zu treffen. Diese sind jederzeit möglich. Hier kann man insbesondere Haftungshöchst-

514

1 Stadler, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Abschn. 1.3, Rz. 114 ff.

Redeker

449

D Rz. 515

Verträge

grenzen festlegen, auf Versicherungen des Herstellers verweisen oder ähnliche Dinge tun. 515

Bei AGB geht dies nur äußerst eingeschränkt. Hier ist insbesondere die Rechtsprechung des BGH zu Kardinalpflichten zu nennen. Hinzu kommen die besonderen Aussagen in § 307 BGB.

516

Eine mögliche Klausel kann wie folgt lauten:

Schadensersatzansprüche gegen Lieferanten bestehen nicht, wenn der Lieferant und seine Erfüllungsgehilfen fahrlässig gegen nicht wesentliche Vertragspflichten verstoßen haben. Haben der Lieferant oder seine Erfüllungsgehilfen fahrlässig gegen wesentliche Vertragspflichten verstoßen, beschränkt sich ihre Haftung auf den vorhersehbaren typischen Schaden. Diese Haftungsbeschränkungen gelten nicht für eventuelle Schadensersatzansprüche wegen Verletzung von Leben, Körper oder Gesundheit und für die Haftung nach dem Produkthaftungsgesetz. Die Haftung für die Wiederherstellung von Daten des Kunden wird der Höhe nach auf die Kosten beschränkt, die notwendig sind, um die Daten wieder herzustellen, wenn sie in der von dem Lieferanten oder einem anderen Dritten angegebenen Art und Weise regelmäßig gesichert werden oder in sonstiger Weise aus maschinenlesbarem Datenmaterial mit vertretbarem Aufwand rekonstruiert werden können.

517

Zur Begründung der Klausel wird im Einzelnen verwiesen auf die weiteren unten stehenden Teile zu den AGB (Kap. K). Es handelt sich um eine allgemeine Schadensersatzklausel. Diese ist hier nur erwähnt, weil sie im Zusammenhang mit Softwaregewährleistungsrechten ebenfalls Verwendung finden müsste. Möglicherweise lässt sich die Verjährungsfrist im Bereich einfacher Fahrlässigkeit auch für den Bereich der Kardinalpflichten verkürzen1. Möglicherweise muss auch näher beschrieben werden, was wesentliche Vertragspflichten sind.

518

Der letzte Absatz ist im Bereich von Softwareverträgen wichtig. Er gibt nur den Inhalt des § 254 BGB wieder, weil eine regelmäßige Datensicherung eine selbstverständliche Pflicht eines jeden Softwareanwenders ist2. Wer die Daten nicht sichert und hinterher hohen Schadensersatz wegen Datenverlust beklagt, kann diesen schon nach der Gesetzeslage nicht durchsetzen. Dies kann auch in AGB festhalten werden.

1 Näher Redeker, in: Auer-Reinsdorff/Conrad (Hrsg.), IT-Recht, § 11 Rz. 120 f. 2 Zuletzt OLG Hamm v. 1.12.2003 – 13 U 133/03, CR 2004, 654; aus der Literatur z.B. Schneider, Handbuch des EDV-Rechts, G Rz. 172, vgl. auch oben Rz. 323.

450

Redeker

Rz. 519 D

Realisierung (Kauf-/Werkvertrag)

9. Vergütungsregelung nach Kündigung Sinnvoll ist es auch, eine Klausel vorzusehen, die die Vergütung nach einer Kündigung nach § 649 BGB pauschaliert, um den Darlegungslasten für eine Restvergütung nach § 649 Satz 2 BGB zu entgehen. Diese ist unter Berücksichtigung von rechtlichen Rahmenbedingungen zulässig (näher oben Rz. 435 ff.). Sie könnte wie folgt lauten:

Kündigt der Kunde den Vertrag ohne Gründe nach § 649 BGB, kann der Lieferant nach seiner Wahl die Ansprüche nach § 649 BGB oder stattdessen für seine Aufwendungen und den entgangenen Gewinn neben der Vergütung für die schon erbrachten Leistungen einen Pauschbetrag in Höhe von 40 % seiner für die zum Zeitpunkt der Kündigung noch nicht erbrachten Leistungen geschuldeten Vergütung verlangen. Dem Kunden bleibt es vorbehalten, nachzuweisen, dass der dem Lieferant nach § 649 BGB zustehende Betrag niedriger liegt1.

1 Zur Formulierung: BGH v. 5.5.2011 – VII ZR 161/10, BB 2011, 1873.

Redeker

451

519

E. Softwareentwicklung durch Dritte

I. Arbeitnehmer . . . . . . . . . . . . . . . . 1. Vertragliche Rechte und Pflichten . . . . . . . . . . . . . . . . . . . . a) Arbeitsvertrag (Gennen) . . . . b) Leistungspflichten (Gennen). c) Rechtseinräumung an urheberrechtlich geschützten Arbeitsergebnissen (Karger) . aa) Überblick . . . . . . . . . . . . . . bb) Rechtserwerb gem. § 69b UrhG für geschaffene Computerprogramme . . . . . . . . . . . . . . . (1) Schaffung eines Computerprogramms . . . . . . . . . . . . (2) Schaffung durch einen Arbeitnehmer . . . (3) Schaffung in Wahrnehmung der Aufgaben aus dem Arbeitsverhältnis . . . . . . (4) Schaffung nach den Anweisungen des Arbeitgebers . . . . . . . . (5) Schaffung während der Dauer des Arbeitsverhältnisses . . . (6) Rechtsübergang aller vermögensrechtlichen Befugnisse auf den Arbeitgeber . . . . . (7) Zeitpunkt des Rechtsübergangs . . . . (8) Abweichende Vereinbarungen . . . . . . . . cc) Rechtseinräumung an sonstigen urheberrechtlich geschützten Arbeitsergebnissen . . . . . . . . (1) Schöpferprinzip und Rechtseinräumung . . (2) Rechtseinräumung bei Pflichtwerken. . . . (a) Pflichtwerk . . . . . .

Rz.

Rz.

1

(b) Schuldrechtliche Verpflichtung zur Rechtseinräumung im Arbeitsvertrag . . . . 60 (c) Fehlen einer ausdrücklichen Regelung . . . . . . . . . . . . . . . . 65 (d) Urheberpersönlichkeitsrechte. . . . . . . . . . 76 dd) Freie bzw. außervertragliche Werke . . . . . . . . . . . . . . . 77 d) Arbeitnehmererfindervergütung (M. Brandi-Dohrn) . . . . . 79 aa) Überblick über das Arbeitnehmererfindergesetz (ArbEG) . . . . . . . . . . . . . . . . . . 80 bb) Besonderheiten beim vertikalen Entwicklungsvertrag . . . . . . . . . . . . . . . . . . . 90 cc) Arbeitnehmervergütung bei Softwareerstellung im Kooperationsverhältnis . . . . 95 dd) Besonderheiten beim Geschäftsführer oder Gesellschafter . . . . . . . . . . . . . 102 ee) Besonderheiten bei Hochschulentwicklungen . . . . . . . 105 e) Vergütung (Karger) . . . . . . . . . . . . 109 aa) Zivilrecht bzw. Arbeitsrecht . . . . . . . . . . . . . . . . . . . . . 109 bb) Ansprüche gem. §§ 32, 32a UrhG . . . . . . . . . . . . . . . . . 110 (1) Regelungsinhalt . . . . . . . . 112 (2) Anwendbarkeit bei Rechtsübertragungen nach § 69b UrhG . . . . . . . 115 (3) Anwendbarkeit im Bereich des § 43 UrhG. . . . . 118 f) Geheimhaltung (Gennen) . . . . . 119 aa) Einführung/Interessenlage. . 119 bb) Geheimhaltungsverpflichtung . . . . . . . . . . . . . . . . . . . . . . 120 cc) Nachvertragliche Geheimhaltungsverpflichtungen . . . 126 dd) Geheimhaltungspflicht nach § 24 ArbEG . . . . . . . . . . 130

1 1 11

20 20

23

24 25

30

37

39

42 50 51

52 55 57 57

Gennen

453

E

Verträge Rz.

Rz.

ee) Geheimhaltungspflicht bei Datenverarbeitung . . 135 g) Konkurrenzverbot . . . . . . . . . 136 aa) Wettbewerbsverbote während des Arbeitsverhältnisses . . . . . . . . . . . 137 bb) Nachvertragliches Wettbewerbsverbot. . . . . . . . . . 147 2. Leistungsstörungen im Arbeitsverhältnis (Gennen) . . . 158 a) Leistungsstörungen auf Seiten des Arbeitnehmers . . . . . 159 aa) „Nichtleistung“ . . . . . . . . 159 bb) Erfolgsunabhängigkeit . . 163 b) Leistungsstörungen auf Seiten des Arbeitgebers . . . . . 166 aa) Verzögerte Entgeltzahlung. . . . . . . . . . . . . . . . 166 bb) Annahmeverzug des Arbeitgebers . . . . . . . . . . . 170 3. Beendigung des Arbeitsverhältnisses (Individualarbeitsrecht) (Gennen) . . . . . . . . . . 173 a) Befristung . . . . . . . . . . . . . . . . . 174 b) Beendigung durch Kündigung . . . . . . . . . . . . . . . . . . . . 178 c) Aufhebungsvertrag . . . . . . . . . 197 d) Fortbestand der Rechte an Arbeitsergebnissen im Falle einer Beendigung des Arbeitsverhältnisses . . . . . . . . . . 207

III. Freie Mitarbeiter (Gennen) . . . . 241 1. Begriff, Abgrenzung zur arbeitnehmerähnlichen Person . . . . . . 241 2. Konsequenz bei Statusverfehlung (Scheinselbständigkeit) . . . 245 3. Vertragliche Rechte und Pflichten . . . . . . . . . . . . . . . . . . . . 251 a) Gestaltung als Dienstvertrag oder Werkvertrag . . . . . . . . . . . 251 b) Rechtsübertragung . . . . . . . . . 258 aa) Das materielle Ergebnis . 259 bb) Das immaterielle Ergebnis . . . . . . . . . . . . . . . 261 cc) Vergütung für die Rechteübertragung . . . . . . . . . . 271 c) Geheimhaltung . . . . . . . . . . . . 273 d) Konkurrenzverbot . . . . . . . . . . 274 4. Leistungsstörungen . . . . . . . . . . . 275 a) Leistungsstörungen im Dienstvertrag . . . . . . . . . . . . . . 276 b) Leistungsstörungen im Werkvertrag . . . . . . . . . . . . . . . 279 5. Beendigung . . . . . . . . . . . . . . . . . . 290 a) Beendigungsmöglichkeiten. . 290 b) Fortbestand der Nutzungsrechte an Computerprogrammen und anderen Arbeitsergebnissen bei Beendigung des Vertrages über die freie Mitarbeit . . . . . 293

II. Softwareentwicklung und Arbeitnehmerüberlassung (Gennen) . . . . . . . . . . . . . . . . . . . . 214 1. Begriffsbestimmung . . . . . . . . . . 214 a) Ausgangssituation . . . . . . . . . 214 b) Abgrenzung der Arbeitnehmerüberlassung zu Dienstund Werkvertrag . . . . . . . . . . . 218 c) Gewerbliche Arbeitnehmerüberlassung. . . . . . . . . . . . 221 2. Leistungspflichten . . . . . . . . . . . 226 3. Rechteübertragung . . . . . . . . . . . 228 4. Leistungsstörungen . . . . . . . . . . 231 a) Leistungsstörungen im Verhältnis ArbeitnehmerVerleiher . . . . . . . . . . . . . . . . . . 232 b) Leistungsstörungen im Verhältnis Verleiher-Entleiher . . 234 5. Vergütung . . . . . . . . . . . . . . . . . . . 238

454

Gennen

IV. Subunternehmer (Gennen) . . . . 295 1. Interessenlage von Generalunternehmer und Subunternehmer . . . . . . . . . . . . . . . . . . . . . . 295 2. Leistungspflichten . . . . . . . . . . . . 301 3. Rechteübertragung . . . . . . . . . . . 308 4. Sonstiges . . . . . . . . . . . . . . . . . . . . 309 V. Konsortium (M. BrandiDohrn) . . . . . . . . . . . . . . . . . . . . . . 312 1. Begriff; Abgrenzung zum Austauschvertrag . . . . . . . . . . . . . 312 2. Ausprägung . . . . . . . . . . . . . . . . . . 314 3. Überblick zu den gesellschaftsrechtlichen und schutzrechtlichen Fragen . . . . . . . . . . . . . . . . 317 4. Vertragsverhältnis . . . . . . . . . . . . 319 5. FuE-Verträge, Gruppenfreistellungsverordnung . . . . . . . . . . 323 a) Deutsches Kartellrecht . . . . . 324 b) Art. 101 AEUV . . . . . . . . . . . . . 328

Softwareentwicklung durch Dritte

Rz. 3

E

Rz.

Rz.

c) Von der konstitutiven Freistellung zur Legalausnahme 332 d) Die Gruppenfreistellungsverordnungen. . . . . . . . . . . . . . 335 6. Materielles und immaterielles Ergebnis . . . . . . . . . . . . . . . . . . . . . 347 a) Urheberrecht . . . . . . . . . . . . . . 348

b) Patentrecht . . . . . . . . . . . . . . . . 353 c) Übliche Sondervereinbarungen . . . . . . . . . . . . . . . . . . 363 7. Leistungsstörungen . . . . . . . . . . . 368 8. Beendigung und Auseinandersetzung . . . . . . . . . . . . . . . . . . . . . . 370

I. Arbeitnehmer 1. Vertragliche Rechte und Pflichten a) Arbeitsvertrag Der Arbeitsvertrag ist ein gegenseitiger, dem BGB sowie zahlreichen ar- 1 beitsrechtlichen Sondergesetzen unterfallender zivilrechtlicher Vertrag. Durch den Arbeitsvertrag wird ein Schuldverhältnis über die entgeltliche Erbringung der Arbeitsleistung begründet (§§ 611 ff. BGB). Der Arbeitnehmer verpflichtet sich durch den Arbeitsvertrag, die vertragsmäßig geschuldete Arbeitsleistung zu erbringen. Daneben trifft ihn eine Treuepflicht gegenüber dem Arbeitgeber. Als Gegenleistung hat der Arbeitgeber die vereinbarte Vergütung zu zahlen; ihn treffen auch gewisse Fürsorgepflichten gegenüber dem Arbeitnehmer. Im Unterschied zum freien Mitarbeiter bzw. zum Dienstnehmer oder 2 Werkunternehmer (zur Abgrenzung vgl. unten Rz. 251 ff.) verrichtet der Arbeitnehmer in persönlich abhängiger Beschäftigung weisungsgebundene Tätigkeiten1. Er ist in den Betrieb des Arbeitgebers eingegliedert und zur persönlichen Erbringung der Arbeitsleistung verpflichtet. Im Hinblick auf Arbeitszeit, Arbeitsort, Durchführung und Inhalt der Arbeit unterliegt er den Weisungen des Arbeitgebers. Grundsätzlich besteht Abschlussfreiheit und Vertragsfreiheit, d.h. die Par- 3 teien können den Inhalt des Arbeitsvertrages frei bestimmen. Die Vertragsfreiheit findet ihre Grenze jedoch (insbesondere) in den arbeitsrechtlichen, vielfach nicht abdingbaren Gesetzen und Verordnungen2, in geltenden Tarifverträgen und Betriebsvereinbarungen3. Hintergrund der oft weitreichenden gesetzlichen Regelungen zum Schutz des Arbeitnehmers ist die Intention des Gesetzgebers, die naturgemäß gegebene Disparität der Vertragsparteien auszugleichen. Aufgrund der sehr weiten Verbreitung tariflicher und betrieblicher Bestimmungen einschließlich Gesamtzusagen und vergleichba1 BAG DB 2010, 788. 2 Wie etwa dem Bundesurlaubsgesetz, dem Entgeltfortzahlungsgesetz, dem Kündigungsschutzgesetz, dem Arbeitszeitgesetz etc. 3 Zur zwingenden Wirkung von Tarifverträgen vgl. § 4 TVG, zur zwingenden Wirkung von Betriebsvereinbarungen vgl. § 77 Abs. 4 BetrVG.

Gennen

455

E Rz. 4

Verträge

ren Regelungen, finden sich in manchen Branchen nur mehr rudimentäre Arbeitsverträge, die im Wesentlichen auf bestehende Normen und Handhabungen verweisen und nur noch einen sehr geringen eigenständigen Regelungsgehalt aufweisen. Im Bereich der mittelständischen und kleineren Softwarehersteller sind jedoch Tarifbindungen und – mangels Betriebsrat – Betriebsvereinbarungen in geringerem Umfang zu finden, so dass es hier eher ausführlicher Arbeitsverträge bedarf. Da Arbeitsverträge i.d.R. arbeitgeberseits gestellt und dort einheitlich gehandhabt werden, darf man davon ausgehen, dass Arbeitsverträge regelmäßig Allgemeine Geschäftsbedingungen i.S.d. §§ 305 ff. BGB darstellen (s.u. Rz. 10 ff.). 4

Eine schriftliche Fixierung des Arbeitsvertrages vor Arbeitsantritt ist nicht notwendig; zumeist ist die Schriftform tarifvertraglich oder über Betriebsvereinbarungen zwingend gefordert. Im Übrigen muss der Arbeitgeber gem. § 2 Abs. 1 NachwG spätestens einen Monat nach dem vereinbarten Beginn des Arbeitsverhältnisses die wesentlichen Vertragsbedingungen schriftlich niederlegen, die Niederschrift unterzeichnen und dem Arbeitnehmer aushändigen, für Ausbildungsverhältnisse vgl. auch § 4 BBiG. Das NachwG verlangt bei Inlandsbeschäftigung bestimmte Informationen im Arbeitsvertrag, nämlich Name und Anschrift der Vertragsparteien, Zeitpunkt des Beginns des Arbeitsverhältnisses, bei befristeten Arbeitsverhältnissen die vorhersehbare Dauer des Arbeitsverhältnisses, den Arbeitsort oder, falls der Arbeitnehmer nicht nur an einem bestimmten Arbeitsort tätig sein soll, einen Hinweis darauf, dass der Arbeitnehmer an verschiedenen Orten beschäftigt werden kann, die vom Arbeitnehmer zu leistende Tätigkeit, die Zusammensetzung und Höhe des Arbeitsentgelts einschließlich der Zuschläge, Zulagen, Prämien und Sonderzahlungen sowie anderer Bestandteile des Arbeitsentgelts und deren Fälligkeit, die vereinbarte Arbeitszeit, die Dauer des jährlichen Erholungsurlaubs, die Fristen für die Kündigung des Arbeitsverhältnisses sowie einen in allgemeiner Form gehaltener Hinweis auf die Tarifverträge, Betriebs- oder Dienstvereinbarungen, die auf das Arbeitsverhältnis anzuwenden sind. Damit ist zugleich der Mindestinhalt eines üblichen Arbeitsvertrages umrissen.

5

Selbstverständlich wird in einem Bereich wie der Softwareerstellung, in dem wesentliche Arbeitsergebnisse in geistigen Schöpfungen bestehen, aus Arbeitgebersicht auch eine Regelung im Arbeitsvertrag enthalten sein, die sich mit den Rechten an den Arbeitsergebnissen und einer evtl. besonderen für die Überlassung oder Nutzung schöpferischer Leistungen zu zahlenden Vergütung befasst, und das ungeachtet der Tatsache, dass im Bereich der Softwareerstellung mit § 69b UrhG eine Norm existiert, die die Nutzungsund Verwertungsrechte an während der Dauer des Arbeitsverhältnisses geschaffener Software in weitem Umfang regelt (vgl. unten Rz. 20 ff.) und ferner im Bereich technischer Erfindungen in Gestalt des ArbEG zwingende Normen existieren, von denen kaum abgewichen werden kann (vgl. § 22 ArbEG). Dabei werden insbesondere Arbeitsergebnisse, die weder unter §§ 69a ff. UrhG noch unter das ArbEG fallen, von der arbeitsvertraglichen 456

Gennen

Rz. 10 E

Softwareentwicklung durch Dritte

Regelung erfasst werden. Soweit der Arbeitnehmer bspw. eine Dokumentation zu Computerprogrammen schreibt, die nicht unter den Begriff des Computerprogramms fällt, ist dies ein (ggf.) unter § 2 UrhG fallendes Werk, so dass wegen § 43 UrhG Regelungen im Arbeitsvertrag notwendig sind. Die dem Arbeitnehmer geschuldete Vergütung kann entweder individuell 6 vertraglich, oder aber durch Tarifvertrag und/oder Betriebsvereinbarung oder andere betriebliche Regelungen bestimmt sein. Auch Kombinationen sind denkbar, z.B. in der Form, dass neben einer tariflichen Zahlung ergänzende Zahlungen auf der Grundlage anderweitig geschlossener Vereinbarungen dem Arbeitnehmer zugesagt werden oder die vertraglich vereinbarte Zahlung optional nur dann gilt, wenn und soweit es keine tarifliche Zahlung gibt. Wurde keine Regelung zur Vergütung getroffen, besteht Anspruch auf die übliche Vergütung, § 612 Abs. 2 BGB. Gerade die Vergütungsfrage wird aber in den wenigsten Fällen offen bleiben. Besonderer Aufmerksamkeit bedarf auch die Vereinbarung der Dauer des 7 Arbeitsverhältnisses. Neben dem eher typischen Fall des unbefristeten Arbeitsverhältnisses kann auch eine zeitlich oder von der Zweckbestimmung her begrenzte Vertragslaufzeit vereinbart werden, z.B., wenn Softwareprogrammierer nur für ein bestimmtes Projekt zeitweise (zeitlich befristet) oder bis zu dessen Vollendung (zweckbefristet) eingestellt werden sollen. Das Arbeitsverhältnis kann ohne Vorliegen eines sachlichen Grundes auf bis zu zwei Jahre befristet werden (vgl. § 620 Abs. 3 BGB, § 14 Abs. 2 TzBfG). In den ersten vier Jahren nach einer Unternehmensgründung ist eine solche Befristung sogar für bis zu vier Jahre zulässig (§ 14 Abs. 2a TzBfG; Einzelheiten vgl. unten Rz. 174 ff.). Bei Neueinstellungen sollte zudem eine Probezeit vereinbart werden. Wäh- 8 rend der Probezeit kann das Arbeitsverhältnis beiderseitig ohne Angabe eines Grundes innerhalb einer kurzen Frist gekündigt werden. Nach § 622 Abs. 3 BGB beträgt diese Kündigungsfrist bei einer Probezeit von nicht länger als sechs Monaten zwei Wochen. Im Softwareentwicklungsbereich ist auch Teilzeitbeschäftigung an der 9 Tagesordnung. Hier ist das TzBfG zu beachten. Insbesondere Arbeitszeitmodelle, bei denen eine Arbeit „auf Abruf“ erfolgt, also entsprechend dem Arbeitsanfall, bedürfen besonderer Regelungen, damit für beide Seiten verlässliche Rahmenbedingungen gelten; hier gibt § 12 TzBfG die zulässigen Grenzen vor. Zu beachten sind §§ 305 ff. BGB bei der Verwendung vorformulierter all- 10 gemeiner Arbeitsbedingungen, Einheitsregelungen, Gesamtzusagen und betrieblicher Übungen, die Allgemeine Geschäftsbedingungen (AGB) nach § 305 Abs. 1 BGB sein können1. Nach der Rechtsprechung ist immer dann von AGB auszugehen, wenn – wie zumeist – zwischen den Vertragsparteien die Bestandteile des Vertrages nicht ausgehandelt wurden, d.h. der Arbeitge1 Melms, in: Münchener Anwaltshandbuch Arbeitsrecht, § 10 Rz. 93.

Gennen

457

E Rz. 11

Verträge

ber die Vertragsbedingungen für eine Mehrzahl von Verträgen vorgesehen hat, nicht ernsthaft zur Disposition stellt und dem Arbeitnehmer keine tatsächliche Einflussmöglichkeit zugesteht1, insbesondere die Arbeitsbedingungen nicht im Einzelnen „ausgehandelt“ (nicht nur „verhandelt“2) werden. Handelt es sich um AGB, ist § 310 Abs. 4 Satz 2 BGB zu beachten, nach dem die im Arbeitsrecht geltenden Besonderheiten angemessen zu berücksichtigen sind und § 305 Abs. 2 und 3 BGB keine Anwendung finden. Besonderheiten bestehen bei Verweisungsklauseln für Tarifverträge, insbesondere dynamische Verweisungen. So dürften z.B. Vereinbarungen, die im Hinblick auf den sachlichen Anwendungsbereich signifikant über § 69b UrhG hinausgehen, indem sie versuchen, sämtliche Arbeitsergebnisse – und nicht nur Computerprogramme – auf dem Vereinbarungswege dem sachlichen Anwendungsbereich des § 69b UrhG zu unterwerfen, oder weiter gehend versuchen, die in § 69b UrhG genannten Fälle („… in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers …“) auszudehnen und auch Computerprogramme und Arbeitsergebnisse zu erfassen, die außerhalb der Arbeitsaufgabe oder in der Freizeit erstellt wurden, einer Inhaltskontrolle anhand von § 307 BGB kaum standhalten. b) Leistungspflichten 11 Für die Arbeitsvertragsparteien von besonderer Bedeutung ist eine Beschreibung der Reichweite der Verpflichtungen des Arbeitnehmers. Der Arbeitnehmer hat ein natürliches Interesse daran, eine Vorstellung davon zu erhalten, was im Einzelnen der Inhalt seiner Arbeitspflicht ist, welche Arbeiten er nicht oder nur bei gesonderter Vereinbarung erbringen muss, welche unternehmensinternen Richtlinien er zu beachten hat usw. Der Arbeitgeber hat ein Interesse daran, einen – aus seiner Sicht möglichst weiten – Rahmen abzustecken, innerhalb dessen er nach seiner Wahl (billiges Ermessen, § 315 BGB) den Arbeitnehmer mit Aufgaben betrauen kann, in der Gewissheit, dass einerseits der Arbeitnehmer diese Tätigkeiten erbringen muss und diese andererseits mit der vereinbarten Vergütung abgegolten sind. Es entspricht zumeist dem Wunsch des Arbeitgebers, sein Direktionsrecht im Hinblick auf die Einzelheiten der Leistungserbringung nicht durch eine zu detaillierte Regelung im Arbeitsvertrag einzuschränken, so dass typischerweise eine Versetzungsklausel3 in den Vertrag aufgenommen wird, die sich jedenfalls auf den Arbeitsinhalt, den Arbeitsort und andere Einzelheiten der Leistungserbringung bezieht. Zu beachten ist auch, dass sich ein Arbeitsverhältnis durch Ablauf einer längeren Zeitspanne auf einen bestimmten Arbeitsplatz 1 S. Palandt/Heinrichs, § 305 BGB Rz. 21. 2 BAG NZA 2006, 40 (44). 3 Dabei darf die Versetzungsklausel aus AGB-rechtlichen Gründen nicht so gestaltet sein, dass sie es dem Arbeitgeber ermöglicht, den Arbeitnehmer auf einen Arbeitsplatz mit geringerer Entlohnung zu versetzen; dies dürfte der Inhaltskontrolle nach § 307 BGB nicht standhalten; s.a. BAG NZA 2010, 1355.

458

Gennen

Softwareentwicklung durch Dritte

Rz. 13 E

näher konkretisieren kann1; demnach sollte die Versetzungsklausel eine Regelung enthalten, die dem Arbeitgeber auch nach Ablauf einer längeren Zeitspanne, in der der Arbeitnehmer die gleiche Tätigkeit ausübt, das Recht zugesteht, diesen mit anderen Aufgaben zu betrauen2. Der Begriff der „Arbeitsaufgabe“ wird weit interpretiert und ergibt sich 12 nicht allein aus dem Arbeitsvertrag, sondern (u.a.) auch aus Tarifverträgen/ Betriebsvereinbarungen, der betrieblichen Funktion, Einzelweisungen des Arbeitgebers, dem konkreten Betätigungsfeld, dem Berufsbild und der Branchenübung. Grundsätzlich darf der Arbeitgeber erwarten, dass der Arbeitnehmer seine gesamte Kraft und sein gesamtes Wissen in den Dienst des Betriebes stellt, auch auf Gebieten, die nicht im unmittelbaren Aufgabenbereich liegen. Je verantwortungsvoller der Aufgabenbereich des Arbeitnehmers und je höher sich dieser in der Unternehmenshierarchie befindet, desto mehr erweitert sich dessen Arbeitsbereich3. Die Verbesserung des Arbeitsplatzes und -umfeldes gehört i.d.R. ebenfalls zu den allgemeinen Aufgaben eines Arbeitnehmers4. Auch ist irrelevant, ob der Arbeitnehmer seiner Arbeitstätigkeit daheim nachgeht, solange dies noch in Erfüllung seiner arbeitsvertraglichen Pflichten geschieht. Da der Arbeitsvertrag einen Unterfall des Dienstvertrages (§§ 611 ff. BGB) 13 darstellt, wird vom Arbeitnehmer kein bestimmter Arbeitserfolg, sondern allein die Arbeitsleistung als solche geschuldet. Das bedeutet für die Softwareentwicklung, dass der Arbeitnehmer keine funktionsfähigen und „fehlerfreien“ Computerprogramme und zugehörige Dokumentation als Arbeitsergebnis schuldet, sondern – vorbehaltlich einer weiter gehenden Privilegierung bei der Haftung – nur sein Bemühen im Rahmen des § 276 Abs. 2 BGB. Der Arbeitnehmer hat also bei Erfüllung seiner Arbeitspflichten die 1 Zu den Anforderungen an eine solche Konkretisierung des Arbeitsplatzes s. LAG Hamm NZA-RR 2005, 462 ff. 2 Allerdings ist zu beachten, dass solche weitergehenden Weisungsbefugnisse des Arbeitgebers bei der betriebsbedingten Kündigung eine Rolle spielen können, da der Kreis der vergleichbaren Arbeitnehmer bei der Sozialauswahl (§ 1 Abs. 3 Satz 3 KSchG) vom Umfang des Weisungsrechts mitbestimmt wird. Generell gilt: Je enger das Weisungsrecht des Arbeitgebers, desto leichter wird es ihm fallen, im Falle der betriebsbedingten Kündigung dem Vorwurf eine zutreffende Sozialauswahl nicht durchgeführt zu haben, entgegentreten zu können, da sich diese entweder auf nur wenige vergleichbare Arbeitnehmer beschränkt oder gar ganz entfallen kann. Wird also ein hoch spezialisierter Softwareentwickler für eine bestimmte Tätigkeit eingestellt, für den es von vornherein keine anderweitige Beschäftigungsmöglichkeit innerhalb des Betriebes gibt und geben wird, kann es sich empfehlen, den Aufgabenbereich dieses Mitarbeiters so genau wie möglich im Arbeitsvertrag zu beschreiben, um eine Vergleichbarkeit mit anderen Mitarbeitern von vornherein auszuschließen. Vgl. auch BAG v. 17.2.2000 – 2 AZR 142/99, NZA 2000, 822 ff. Zur betriebsbedingten Kündigung s. unter Rz. 185 ff. 3 Bartenbach/Volz, § 4 ArbEG Rz. 23. 4 Möhring/Nicolini, § 69b UrhG Rz. 9.

Gennen

459

E Rz. 14

Verträge

im Verkehr erforderliche Sorgfalt zu beachten. Ihn treffen neben der eigentlichen Arbeitsaufgabe der Entwicklung von Computerprogrammen und Dokumentation auch Sorgfaltspflichten, wie bspw. die Speicherung von Arbeitsergebnissen, Aufzeichnungen über den Entwicklungsstand etc. 14 Da es in einigen Bereichen schöpferischer Leistungen für die Frage, ob und inwiefern der Arbeitgeber (ausschließliche) Nutzungs- und Verwertungsrechte an den Arbeitsergebnissen oder diese gar auf dinglicher Ebene übertragen erhält, auch darauf ankommt, ob der Arbeitnehmer in Ausführung seiner arbeitsvertraglichen Verpflichtungen (§ 69a UrhG, § 4 Abs. 2 Nr. 1 ArbEG) handelt, empfiehlt sich eine Dokumentation der erteilten Weisungen bzw. der Ausübung des Direktionsrechts sowie eine vertragliche Verpflichtung des Arbeitnehmers zur genauen Dokumentation seiner Tätigkeiten – bspw. über nachträgliche Entwicklungsaufgaben oder Forschungsaufträge sowie deren Verwirklichung – damit im Zweifelsfall zumindest ein enger innerer Zusammenhang zwischen der vom Arbeitnehmer erstellten Software oder sonstigen Arbeitsergebnissen und den arbeitsvertraglichen Pflichten nachgewiesen werden kann. Die Dokumentationsverpflichtung kann dem Arbeitnehmer auferlegt werden, was dem Arbeitgeber bei Zuwiderhandeln ein zusätzliches Zurückbehaltungsrecht an der geschuldeten Vergütung nach § 320 BGB oder aber eine Aufrechnungsmöglichkeit wegen vergeblicher Lohnaufwendungen nach § 284 BGB ermöglichen kann. Solche Verpflichtungen sollten auch unabhängig davon auferlegt werden, ob man technisch die Einzeltätigkeiten eines Arbeitnehmers auf einem Rechner nachvollziehen kann oder nicht. Selbstverständlich ist insoweit die Auferlegung der Verpflichtung nur sinnvoll, wenn zumindest in Ansätzen auch eine regelmäßige Kontrolle der Einhaltung der Verpflichtung erfolgt. 15 Wichtigste Nebenpflicht des Arbeitnehmers ist die Treuepflicht. Aus dieser Treuepflicht wird z.B. – auch wenn keine ausdrückliche Abrede im Arbeitsvertrag besteht – die Geheimhaltungsverpflichtung während der Dauer des Arbeitsverhältnisses abgeleitet. 16 Die Hauptleistungspflicht des Arbeitgebers ist die Lohnzahlungspflicht. In Bereichen mit tariflicher Bindung und/oder bestehenden Betriebsvereinbarungen wird die Höhe der Vergütung maßgeblich durch tarifliche bzw. betriebliche Normen bestimmt. Auch der Gleichbehandlungsgrundsatz, betriebliche Übungen und Gesamtzusagen haben Einfluss auf die Vergütungshöhe. Im Übrigen ist die Höhe der Vergütung – in der Softwareentwicklungsbranche – frei verhandelbar, von Fragen der Sittenwidrigkeit und des Wuchers abgesehen (§ 138 BGB). 17 Vergütung wird regelmäßig als Geldleistung erbracht; als Naturalvergütung kommen aber die Überlassung von Firmenwagen auch zur privaten Nutzung, die Gewährung von Personalrabatten (bei Softwarebezug), besondere Risikovorsorge bei Krankheit, Finanzdienstleistungen oder – gerade im Bereich der Softwareentwicklungsbranche nicht unübliche – Mitarbeiterbeteiligungen bzw. Aktienoptionen in Betracht. Unmittelbare leistungsbezogene 460

Gennen

Softwareentwicklung durch Dritte

Rz. 20 E

Entgelte („Akkordarbeit“) sind wegen der besonderen Arbeitsinhalte wenig verbreitet. Hier sind eher besondere Prämien denkbar für den Fall, dass bestimmte Projekte im Zeitplan abgewickelt werden konnten. Möglich sind auch Provisionsmodelle im Vertriebsbereich, als Tantiemen anzusehende Erfolgsbeteiligungen des Arbeitnehmers am Geschäftsergebnis, variable Vergütungsbestandteile, deren Gewährung von der Erreichung in einer Zielvereinbarung formulierter Ziele abhängt, oder Jahressonderzahlungen, „Urlaubsgeld“, „Weihnachtsgeld“, oder das „13. Gehalt“. Neben der eigentlichen Lohnzahlungsvereinbarung sollte auch geregelt werden, inwiefern eine besondere Vergütung für geleistete Überstunden gezahlt wird. Bei Zahlungen, die nicht in einer regelmäßigen monatlichen Vergütung be- 18 stehen, ist besonderes Augenmerk auf die Gewährungs- und ggf. Rückzahlungsvoraussetzungen zu richten. Wird dem Arbeitnehmer eine Sondervergütung gezahlt, sollte der Arbeitgeber besonders die Freiwilligkeit einer solchen Zahlung betonen, um keine betriebliche Übung im Hinblick auf zukünftige Zahlungen zu begründen. Bei Vereinbarung eines Zahlungsvorbehaltes sollte beachtet werden, dass dieser bei Verwendung von AGB nur dann nach der Rechtsprechung des BAG zulässig ist, wenn der Widerruf nicht in den Kernbereich des Arbeitsverhältnisses eingreift1. Unproblematisch ist dagegen, die Zahlung einer Sondervergütung von dem Bestehen eines Arbeitsverhältnisses am Auszahlungstag abhängig zu machen2. Zur Vergütung von schöpferischen Sonderleistungen vgl. unten Rz. 80 ff., 95 ff., 110 ff. Nebenpflichten des Arbeitgebers sind insbesondere die Fürsorgepflicht nach 19 § 242 BGB, die Beschäftigungspflicht, die Pflicht zur Urlaubsgewährung, die Gleichbehandlungspflicht, die Pflicht zum Ersatz von Aufwendungen und Schäden des Arbeitnehmers an seinen bei der Arbeit benutzten Sachen, die Pflicht zur Gewährung von Einblick in die Personalakte, die Informationspflicht und die Pflicht zur Zeugniserteilung. c) Rechtseinräumung an urheberrechtlich geschützten Arbeitsergebnissen aa) Überblick Die Rechtseinräumung an von einem Arbeitnehmer geschaffenen Software folgt je nach Art des Arbeitsergebnisses unterschiedlichen rechtlichen Regeln. An den im Rahmen der arbeitsvertraglichen Pflichten erstellten Computerprogrammen i.S.v. § 69a UrhG erwirbt der Arbeitgeber gem. § 69b UrhG ein ausschließliches Recht zur Ausübung aller vermögensrechtlichen 1 BAG v. 7.10.1982, BB 1983, 1368 ff. Rückzahlung von Beträgen unter 100 Euro kann nicht verlangt werden. Zudem würden übermäßige Rückzahlungen in AGB wohl gegen §§ 307, 309 Nr. 6 BGB verstoßen, so dass bei Unwirksamkeit eine geltungserhaltende Reduktion ausscheidet. 2 BAG v. 10.5.1995 – 10 AZR 648/94, NZA 1995, 1096 ff.; BAG v. 5.6.1996 – 10 AZR 883/95, NZA 1996, 1028 ff.

Karger

461

20

E Rz. 21

Verträge

Befugnisse. Allerdings verbleiben auch im Rahmen des § 69b UrhG gewisse Unsicherheiten, insbesondere was die räumliche Reichweite der Rechtseinräumung in Bezug auf eine Nutzung im Ausland und was die grundsätzlich beim Arbeitnehmer verbleibenden Urheberpersönlichkeitsrechte anbelangt. 21 Zahlreiche Arbeitsergebnisse bei der Softwareentwicklung stehen zwar im engen Zusammenhang mit der Programmentwicklung, fallen aber nicht unter § 69b UrhG, da sie keine Computerprogramme i.S.v. § 69a UrhG sind. Diese Arbeitsergebnisse können gleichwohl urheberrechtlichen Schutz genießen. In diesem Fall richtet sich die Rechtseinräumung nach dem allgemeinen Arbeitnehmer-Urheberrecht gem. § 43 UrhG. Dieses sieht keinen gesetzlichen Rechtserwerb vor, sondern erfordert eine Rechtseinräumung durch den Arbeitnehmer. Ist hierzu vertraglich nichts Ausdrückliches geregelt, erhält der Arbeitgeber nach Maßgabe der Zweckübertragungsregel nur diejenigen Nutzungsrechte, die nach dem betrieblichen Zweck erforderlich sind. Sofern der Arbeitgeber nicht durch ausreichende Regelungen im Arbeitsvertrag sichergestellt hat, dass die Rechtseinräumung an den sonstigen Arbeitsergebnissen im Wesentlichen mit der Rechtseinräumung am Computerprogramm gem. § 69b UrhG synchronisiert ist, läuft er Gefahr, dass er an den einzelnen Elementen der Software unterschiedlich weitreichende Rechte erwirbt, die ihm eine einheitliche und unbeschränkte Verwertung erschweren oder gar unmöglich machen. 22 Aus den vorgenannten Gründen ist es vor allem für den Arbeitgeber empfehlenswert, im Arbeitsvertrag die Frage der Rechtseinräumung hinsichtlich aller Arbeitsergebnisse ausdrücklich zu regeln und sich nicht nur auf § 69b UrhG zu verlassen. bb) Rechtserwerb gem. § 69b UrhG für geschaffene Computerprogramme 23 Wird ein Computerprogramm von einem Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers geschaffen, so ist gem. § 69b Abs. 1 UrhG ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse an dem Computerprogramm berechtigt, sofern nichts anderes vereinbart ist. Grundsätzlich gehen die Rechte nach ganz h.M. unabhängig von einer Gegenleistung des Arbeitgebers auf diesen über1. (1) Schaffung eines Computerprogramms 24 § 69b UrhG gilt nur für Computerprogramme i.S.v. § 69a UrhG, d.h. Programme in jeder Gestalt einschließlich des Entwurfsmaterials. Auf andere urheberrechtlich geschützte Arbeitsergebnisse ist § 69b UrhG nicht, auch nicht analog anwendbar2. Diesbezüglich erfolgt die Rechtseinräumung im 1 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 22; Schricker/Loewenheim, § 69b UrhG Rz. 16. 2 Redeker, IT-Recht, Rz. 25.

462

Karger

Softwareentwicklung durch Dritte

Rz. 30 E

Rahmen eines Arbeitsverhältnisses nach den allgemeinen Grundsätzen des Arbeitnehmer-Urheberrechts i.S.v. § 43 UrhG. (2) Schaffung durch einen Arbeitnehmer Arbeitnehmer i.S.v. § 69b UrhG ist jeder weisungsgebundene, in abhängiger Tätigkeit Beschäftigte. Hierbei gilt der Arbeitnehmerbegriff des Arbeitsrechts1.

25

Mitarbeiter eines mit der Entwicklung beauftragten Unternehmens können kraft Gesetzes (Art. I § 10 AÜG) zu Arbeitnehmern des Auftraggebers werden, wenn die Voraussetzungen einer unerlaubten Arbeitnehmerüberlassung vorliegen2.

26

Auch vermeintlich „freie Mitarbeiter“, die nach den Bestimmungen des § 7 SGB IV als Scheinselbständige zu qualifizieren sind, sind Arbeitnehmer des Auftraggebers3.

27

Demgegenüber gilt § 69b UrhG nicht für „echte“ freie Mitarbeiter, also selbständige Dienstleister i.S.v. § 611 BGB. Die Vorschrift des § 69b Abs. 2 UrhG, die vom Wortlaut hier auf „Dienstverhältnisse“ abstellt, ist insofern missverständlich. „Dienstverhältnisse“ i.S.v. § 69b Abs. 2 UrhG sind nur öffentlich-rechtliche, nicht aber privatrechtliche Dienstverhältnisse4. Keine Anwendung findet § 69b UrhG auf arbeitnehmerähnliche Personen5, auf selbständige Werkunternehmer i.S.v. § 631 BGB6 sowie für Geschäftsführer und Vorstände einer Gesellschaft7.

28

§ 69b UrhG gilt nur für Arbeitnehmer, die ihre Tätigkeit gewöhnlich in Deutschland verrichten8.

29

(3) Schaffung in Wahrnehmung der Aufgaben aus dem Arbeitsverhältnis Mit der Formulierung „in Wahrnehmung seiner Aufgaben“ erfasst § 69b 30 UrhG alle Computerprogramme, deren Herstellung durch den dem Arbeitnehmer im Rahmen des Arbeitsverhältnisses übertragenen Aufgabenbereich veranlasst worden ist.

1 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 2. 2 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 2; s. zur Arbeitnehmerüberlassung bei Softwareentwicklung LAG Stuttgart CR 1991, 740 sowie Feuerborn, CR 1995, 91. 3 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 2. 4 Schricker/Loewenheim, § 69b UrhG Rz. 3. 5 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 3; Schricker/Loewenheim, § 69b UrhG Rz. 3. 6 Schricker/Loewenheim, § 69b UrhG Rz. 2. 7 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 3. 8 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 4.

Karger

463

E Rz. 31

Verträge

31 Die Aufgaben des Arbeitnehmers ergeben sich aus Art und Umfang der geschuldeten Arbeitsleistung unter Berücksichtigung des Betriebszwecks, d.h. aus dem Arbeitsvertrag, aus Weisungen, Betriebsvereinbarungen, betrieblicher Übung sowie aus Tarifverträgen, aber auch aus der betrieblichen Funktion, dem Betätigungsfeld, dem Berufsbild und der Branchenübung1. 32 Der Umfang der arbeitsvertraglichen Aufgaben wird nicht nur durch den Arbeitsvertrag in seiner ursprünglichen Fassung bestimmt. Zu berücksichtigen sind auch nachträgliche Änderungen und Erweiterungen der arbeitsvertraglichen Aufgaben des Arbeitnehmers2. 33 In Wahrnehmung seiner Aufgaben handelt ein Arbeitnehmer, der Computerprogramme als Ergebnis der Arbeitstätigkeit gerade schuldet3. Schwieriger sind diejenigen Fälle zu entscheiden, in denen die Erstellung des Programms sich nicht oder nicht eindeutig mit den arbeitsvertraglichen Verpflichtungen des Arbeitnehmers deckt. In diesem Zusammenhang genügt es aber für die Anwendbarkeit des § 69b UrhG, wenn die Programmerstellung in einem engen inneren Zusammenhang mit den arbeitsvertraglichen Pflichten steht4. Eine Entwicklung aufgrund der Eigeninitiative des Arbeitnehmers ist nicht ausreichend, wenn keine konkrete Anweisung oder Beauftragung durch den Arbeitgeber vorliegt5. 34 Andere Kriterien sind hingegen grundsätzlich von geringer Relevanz. Maßgeblich ist immer, ob die Entwicklung zum arbeitsvertraglichen Aufgabenbereich gehört: 35 Art und Umfang der in Anspruch genommenen Betriebsmittel, z.B. der Hardware des Arbeitgebers oder die Nutzung von betrieblichem Know-how führen nicht zur Anwendbarkeit des § 69b UrhG, wenn die Programmerstellung nicht arbeitsvertraglich geschuldet war6. Hier kann allenfalls eine Andienungspflicht des Arbeitnehmers bestehen7. 36 Auch Ort und Zeitpunkt des Schaffens sind kein maßgebliches Merkmal. So kann § 69b UrhG auch dann Anwendung finden, wenn die Arbeitnehmer die Software in seiner Freizeit und zu Hause geschaffen hat. Der Arbeitgeber, der seinen Arbeitnehmer zur Erstellung eines Computerprogramms

1 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 6. 2 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, 3. Aufl. 2009, § 91 Rz. 37. 3 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 11 m.w.N. 4 OLG München v. 25.11.1999 – 29 U 2437/97, CR 2000, 429 (430); Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 12;Schricker/Loewenheim, § 69b UrhG Rz. 6. 5 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 12. 6 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 7 m.w.N.; Schricker/Loewenheim, § 69b UrhG Rz. 9. 7 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 35; Redeker, IT-Recht, Rz. 27; a.A. wohl Schricker/Loewenheim, § 69b UrhG Rz. 9.

464

Karger

Rz. 41 E

Softwareentwicklung durch Dritte

von sonstigen Tätigkeiten sowie der betrieblichen Anwesenheitspflicht zeitweilig freigestellt hat, ist auch dann Inhaber der in § 69b UrhG beschriebenen Rechte an dem Programm, wenn dessen Entwicklung überwiegend außerhalb der regulären Arbeitszeiten im „Home-Office“ des Arbeitnehmers vorangetrieben wurde1. Die Rechte an einem Computerprogramm, das ganz oder teilweise in der Freizeit geschaffen wurde, stehen dem Arbeitgeber zu, wenn die Erstellung der Wahrnehmung der sich aus dem Arbeitsverhältnis ergebenden Aufgaben diente oder eine Weisung des Arbeitgebers bestand, ein solches Computerprogramm herzustellen2. Allerdings kann eine Programmierung in der Freizeit oder zu Hause auch ein gewisses Indiz dafür sein, dass der Arbeitnehmer nicht in Wahrnehmung seiner Aufgaben gehandelt hat3. (4) Schaffung nach den Anweisungen des Arbeitgebers Soweit die Weisung des Arbeitgebers sich im Rahmen des Direktionsrechts 37 des Arbeitgebers hält, hat das in § 69b Abs. 1 UrhG vorgesehene Tatbestandsmerkmal „nach den Anweisungen“ nur deklaratorischen Charakter, weil der Arbeitnehmer in diesem Fall schon „in Wahrnehmung“ seiner arbeitsvertraglichen Aufgaben handelt4. Eigenständige Bedeutung hat das Merkmal für Weisungen, die über das 38 Direktionsrecht hinausgehen. § 69b UrhG findet damit zulasten des Arbeitnehmers Anwendung, wenn er das Programm freiwillig aufgrund einer Weisung des Arbeitgebers entwickelt hat, obwohl diese Tätigkeit arbeitsvertraglich nicht geschuldet war5. Allerdings hat der Arbeitgeber hierfür eine Sondervergütung, insbesondere eine Überstundenvergütung zu leisten6. (5) Schaffung während der Dauer des Arbeitsverhältnisses Aus der Formulierung „in Wahrnehmung seiner Aufgaben oder nach den 39 Anweisungen seines Arbeitgebers“ folgt, dass das Computerprogramm während der Dauer des Arbeitsverhältnisses hergestellt worden sein muss7. Computerprogramme, die der Arbeitnehmer schon vor Beginn des Arbeitsverhältnisses geschaffen hat, fallen nicht unter § 69b UrhG8.

40

Wechselt der Arbeitnehmer vor Fertigstellung des Programms den Arbeitsplatz, so liegen alle Rechte an den bis zum Zeitpunkt der Beendigung des

41

1 2 3 4 5 6 7 8

OLG Köln v. 25.2.2005 – 6 U 132/04 (rechtskräftig), CR 2005, 557. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 8. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 8. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 16. Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 39. Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 39. Schricker/Loewenheim, § 69b UrhG Rz. 8. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 10.

Karger

465

E Rz. 42

Verträge

ersten Arbeitsverhältnisses erstellten Programmen, Programmelementen bzw. schutzfähigen Vorstufen oder Zwischenergebnissen beim früheren Arbeitgeber1. (6) Rechtsübergang aller vermögensrechtlichen Befugnisse auf den Arbeitgeber 42 Gem. § 69b Abs. 1 UrhG ist der Arbeitgeber bei Vorliegen der gesetzlichen Voraussetzungen „zur Ausübung aller vermögensrechtlichen Befugnisse“ an dem vom Arbeitnehmer erstellten Computerprogramm berechtigt. 43 Gegenstand des § 69b UrhG ist ein umfassender Übergang der Nutzungsrechte auf den Arbeitgeber, der die ausschließliche Befugnis zur alleinigen Benutzung des Programms einschließt. Nach h.M. erfolgt die Rechtseinräumung im Wege einer gesetzlichen ausschließlichen Lizenz2. Nach anderer Auffassung handelt es sich bei § 69b UrhG um eine gesetzliche Auslegungsregel3. 44 Der Rechtsübergang auf den Arbeitgeber erfolgt automatisch und umfassend, einer einseitigen Erklärung der Inanspruchnahme durch den Arbeitgeber wie nach dem ArbEG bedarf es dazu nicht4. 45 Der Arbeitgeber erhält sämtliche Nutzungsrechte exklusiv, unwiderruflich und unbeschränkt zur Verwertung. Hierzu gehört auch das Bearbeitungsrecht5, so dass der Arbeitgeber die Programme weiterentwickeln und neuen Anforderungen anpassen kann. Der Arbeitgeber erwirbt die Nutzungsrechte zeitlich unbeschränkt. Insbesondere bleibt das Nutzungsrecht auch nach Beendigung des Arbeitsverhältnisses bestehen6. Der Arbeitgeber darf Dritten Nutzungsbefugnisse einräumen oder seine Nutzungsrechte auf Dritte übertragen7. 46 Eine Beschränkung des Rechtsübergangs unter dem Gesichtspunkt der Zweckübertragungslehre erfolgt nicht, da diese im Geltungsbereich von § 69b UrhG unanwendbar ist8. Damit stehen dem Arbeitgeber die Nutzungsrechte inhaltlich unbeschränkt für betriebliche wie außerbetriebliche Nutzungen sowie für alle bekannten Nutzungsarten zu9.

1 2 3 4 5 6 7 8 9

Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 10. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 1 m.w.N. Schricker/Loewenheim, § 69b UrhG Rz. 11. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 18. Redeker, IT-Recht, Rz. 30; Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 18. Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 41. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 18. BGH v. 24.10.2000 – X ZR 72/98, CR 2001, 223 = GRUR 2001, 155 (157). Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 19.

466

Karger

Softwareentwicklung durch Dritte

Rz. 50 E

Die Rechtseinräumung umfasst auch neue, im Zeitpunkt der Schaffung des Computerprogramms noch unbekannte Nutzungsarten1.

47

Ob der Arbeitgeber gem. § 69b UrhG auch eine räumlich unbeschränkte Li- 48 zenz zur Nutzung der Software im Ausland erhält, ist zweifelhaft2. Das deutsche Recht kann aufgrund des geltenden Territorialitätsprinzips eine gesetzliche Urheberrechtslizenz nur für seinen Geltungsbereich vorsehen3. Teilweise wird aber argumentiert, dass das Arbeitsvertragsstatut dem urheberrechtlichen Territorialitätsprinzip vorgehe und deshalb eine räumlich unbegrenzte Rechtseinräumung auch im Hinblick auf Nutzungen im Ausland erfolge4. Die Urheberpersönlichkeitsrechte des Arbeitnehmers fallen – da grundsätz- 49 lich unübertragbar – nicht unter § 69b UrhG5. Allerdings muss der Arbeitnehmer Abstriche in persönlichkeitsrechtlichen Positionen hinnehmen, soweit diese zur Sicherung der ausschließlichen Verwertung des Urheberrechts durch den Arbeitgeber geboten sind6. So wird ein stillschweigender Verzicht des Arbeitnehmers auf ein Veröffentlichungsrecht gem. § 12 UrhG angenommen, der spätestens mit Fertigstellung und Werkübergabe eintritt7. Bei Kenntnis einer entsprechenden betrieblichen Übung oder Branchenübung kann ein stillschweigender Verzicht des Arbeitnehmers auf die Urheberbezeichnung gem. § 13 Satz 2 UrhG vorliegen8. Bezüglich des Entstellungsverbots gem. § 14 UrhG, des Zugangsrechts gem. § 25 UrhG, des Änderungsverbots gem. § 39 UrhG und der Rückrufrechte gem. §§ 41, 42 UrhG werden die Rechte des Arbeitnehmers jedenfalls restriktiv interpretiert9. (7) Zeitpunkt des Rechtsübergangs Für die Software-Erstellung im Rahmen eines Arbeitsverhältnisses gilt: Soweit es sich um Computerprogramme i.S.v. § 69a UrhG handelt, erwirbt der Arbeitgeber bei Vorliegen der Voraussetzungen die gesetzliche Lizenz nach § 69b UrhG im Zeitpunkt der Entstehung des Programms. Dies gilt auch hinsichtlich der einzelnen Vorstufen und Zwischenergebnisse10. 1 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 19; Schricker/Loewenheim, § 69b UrhG Rz. 12; Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 102 Rz. 84. 2 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 20. 3 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 102 Rz. 86; Dreier/ Schulze, § 69b UrhG Rz. 9. 4 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 41. 5 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 26, Rz. 38. 6 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 26, Rz. 38. 7 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 39. 8 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 40. 9 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 42 ff.; Schricker/Loewenheim, § 69b UrhG Rz. 14 f. 10 Schricker/Loewenheim, § 69b UrhG Rz. 11; Anders – wohl unzutreffend – OLG Celle v. 1.4.1993 – 13 U 39/90, CR 1994, 681.

Karger

467

50

E Rz. 51

Verträge

(8) Abweichende Vereinbarungen 51 Die Rechtsfolgen des § 69b UrhG können vertraglich abbedungen werden. Dies ist auch konkludent möglich1. An die Annahme einer konkludenten Vereinbarung sind allerdings hohe Anforderungen zu stellen2. Der Verzicht auf die Inanspruchnahme einer Erfindung nach dem ArbEG kann regelmäßig nicht zugleich auch als abweichende Vereinbarung i.S.v. § 69b UrhG interpretiert werden3. cc) Rechtseinräumung an sonstigen urheberrechtlich geschützten Arbeitsergebnissen 52 Sofern es sich bei dem geschaffenen Werk nicht um in Computerprogramm i.S.v. § 69b UrhG handelt, ist § 69b UrhG unanwendbar. Ist das Arbeitsergebnis schutzfähig, so bestimmt sich die Rechtseinräumung an den Arbeitgeber nach dem allgemeinen Arbeitnehmer-Urheberrecht. Dieses ist im Gesetz nur rudimentär geregelt. Eine ausdrückliche Regelung findet sich lediglich in § 43 UrhG. Danach sind die Vorschriften der §§ 31 bis 44 UrhG „auch anzuwenden, wenn der Urheber das Werk in Erfüllung seiner Verpflichtungen aus einem Arbeits- oder Dienstverhältnis geschaffen hat, soweit sich aus dem Inhalt oder dem Wesen des Arbeits- oder Dienstverhältnisses nichts anderes ergibt“. 53 § 43 UrhG lässt die entscheidenden Fragen des Arbeitnehmer-Urheberrechts offen. Die Lücken können nach ganz überwiegender Meinung nicht durch entsprechende Anwendung des wesentlich detaillierter geregelten Arbeitnehmer-Erfinderrechts geschlossen werden4. 54 Im Wesentlichen bleibt es Rechtsprechung und Schrifttum überlassen, die Rechtsstellung des Arbeitnehmerurhebers und damit auch die Frage zu klären, inwieweit dem Arbeitgeber die Rechte an den Arbeitsergebnissen zustehen5. Für den Arbeitgeber bedeutet dies, dass er sich angesichts der bestehenden Unsicherheiten hinsichtlich der Rechtseinräumung an allen Arbeitsergebnissen, die nicht unter § 69b UrhG fallen, vertraglich besonders sorgfältig absichern muss. (1) Schöpferprinzip und Rechtseinräumung 55 Auch bei Werken von Arbeitnehmerurhebern gilt nach ganz h.M. das Urheber- oder Schöpferprinzip. Danach erwirbt der Werkschöpfer originär das gesamte Urheberrecht an einem Werk in allen seinen Ausstrahlungen, d.h. al-

1 Schricker/Loewenheim, § 69b UrhG Rz. 20. 2 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 17. 3 Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 17; Schricker/Loewenheim, § 69b UrhG Rz. 20. 4 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 1. 5 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 2.

468

Karger

Softwareentwicklung durch Dritte

Rz. 60 E

le Urheber-Persönlichkeits- und Urheber-Nutzungsrechte. Dieses Urheberprinzip wird durch § 43 UrhG nicht eingeschränkt. Der Arbeitgeber kann die benötigten Urheber-Nutzungsrechte nur im Wege 56 der rechtsgeschäftlichen Übertragung durch den Arbeitnehmer erlangen. Bei sog. Pflichtwerken besteht eine schuldrechtliche Verpflichtung zur Rechtseinräumung. Hinsichtlich sog. freier Werke ist umstritten, ob der Arbeitnehmer eine Anbietungspflicht hat. (2) Rechtseinräumung bei Pflichtwerken (a) Pflichtwerk Ein Pflichtwerk setzt voraus, dass der Urheber das Werk in Erfüllung der 57 Verpflichtungen aus dem Arbeitsverhältnis geschaffen hat. Maßgeblich ist, welche Tätigkeit vereinbart wurde, wobei die Art der zu leistenden Tätigkeit regelmäßig aus dem Arbeitsvertrag zu entnehmen ist1. Unproblematisch sind die Fälle, in denen der Arbeitnehmer in Erfüllung seiner Hauptpflicht aus dem Arbeitsvertrag Werke zu erstellen hat, die sich schon aus seiner Berufsbezeichnung oder der Branchenüblichkeit ergeben2. Wird ein Arbeitnehmer als „Programmierer“ eingestellt, so ist davon auszugehen, dass seine vertraglichen Hauptpflichten die Erstellung von Software umfassen. Entsteht das Werk in Folge einer Weisung des Arbeitgebers, so ist es nur dann ein Pflichtwerk, wenn das Direktionsrecht im Rahmen des Arbeitsvertrags ausgeübt wurde3.

58

Ort und Zeit der Erstellung des Werkes sind in der Regel keine tauglichen 59 Abgrenzungskriterien4. Daher kann ein Pflichtwerk auch in der Freizeit und nicht am Arbeitsplatz entstehen, wenn es arbeitsvertraglich geschuldet ist. Das Werk muss aber während der Dauer des Arbeitsverhältnisses erstellt worden sein5. (b) Schuldrechtliche Verpflichtung zur Rechtseinräumung im Arbeitsvertrag Die schuldrechtliche Verpflichtung zur Einräumung der Nutzungsrechte ergibt sich aus dem Arbeitsvertrag6. Die schuldrechtliche Verpflichtung zur Rechtseinräumung ist von der Rechtseinräumung als Verfügung zu trennen7. 1 2 3 4 5 6 7

Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 18. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 18. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 19. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 20. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 21. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 47. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 47; Dreier/Schulze, § 43 UrhG Rz. 18; zum Trennungsprinzip auch Karger, Rechtseinräumung bei Softwareerstellung, CR 2001, 357 (358 f.).

Karger

469

60

E Rz. 61

Verträge

61 Grundsätzlich können Arbeitsverträge formlos abgeschlossen werden. Gleichwohl empfiehlt es sich, zur Absicherung beider Parteien arbeitsvertragliche Regelungen zur Rechtseinräumung schriftlich zu treffen. Im Bereich der Software-Erstellung ist es häufig nicht möglich, die von dem Arbeitnehmer zu erstellenden Werke präzise im Voraus zu bestimmen. In der Regel sind die Werke überhaupt nicht oder allenfalls der Gattung nach bestimmt. In diesem Zusammenhang ist § 40 UrhG zu beachten, der für die Einräumung der Nutzungsrechte an unbestimmten künftigen Werken die Schriftform fordert. Allerdings ist umstritten, ob § 40 UrhG auf Vorausverfügungen im Arbeitsverhältnis Anwendung findet. Nach einer im Schrifttum vertretenen Auffassung soll die Warnfunktion des § 40 UrhG auch den Arbeitnehmer schützen und eine Vorausverfügung bei fehlender Schriftform unwirksam sein1. Nach der Gegenmeinung ist die Schutzfunktion im Arbeitsverhältnis entbehrlich und das Schriftformerfordernis mit dem Zweck des Arbeitsverhältnisses nicht vereinbar2. 62 Vereinbarungen über zum Zeitpunkt des Vertragsschlusses unbekannte Nutzungsarten bedürfen hingegen gem. § 31a Abs. 1 UrhG auch im Arbeitsverhältnis der Schriftform3. 63 Im Arbeitsvertrag sollten aus Gründen der Rechtssicherheit insbesondere – die Arbeitsaufgabe, – die einzelnen Nutzungsarten, d.h. der Inhalt und Umfang der Rechtseinräumung, – die Rechtseinräumung auch für unbekannte Nutzungsarten i.S.v. § 31a UrhG, – die Übertragbarkeit der einräumten Nutzungsrechte an Dritte und – der Zeitpunkt der Rechtseinräumung möglichst konkret festgelegt werden. 64 Da sich verbleibende Unsicherheiten nie ganz ausschließen lassen, empfiehlt es sich auch, eine Aussage zum Betriebszweck zu treffen. Diesem Kriterium kommt bei fehlender oder unzureichender vertraglicher Regelung für die Ermittlung von Inhalt und Umfang der Rechtseinräumung anhand der Zweckübertragungsregel zentrale Bedeutung zu4. (c) Fehlen einer ausdrücklichen Regelung 65 Enthält der Arbeitsvertrag keine ausdrückliche Regelung zur Rechtseinräumung, so ist von einer stillschweigenden Rechtseinräumung auszugehen5. 1 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 48. 2 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 7. 3 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 8; Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 50. 4 Vgl. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 59. 5 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 50; Schricker/Rojahn, § 43 UrhG Rz. 51.

470

Karger

Softwareentwicklung durch Dritte

Rz. 70 E

Dies gilt nur dann nicht, wenn eine Rechtseinräumung ausdrücklich ausgeschlossen wurde1, was in der Praxis aber kaum vorkommen dürfte. Die stillschweigende Rechtseinräumung erfolgt grundsätzlich bereits mit 66 Abschluss des Arbeitsvertrages, spätestens aber im Zeitpunkt der Ablieferung des Werkes2. Geht weder aus dem Arbeitsvertrag noch aus einem ggf. geltenden Tarifver- 67 trag der Inhalt und Umfang der Rechtseinräumung hervor, ist der Zweckübertragungsgrundsatz anzuwenden3. Danach wird der Umfang der Nutzungsrechtseinräumung durch den Vertragszweck bestimmt. Es gilt das Prinzip, dass der Urheber im Zweifel keine weitergehenden Rechte überträgt, als es der Zweck des Vertrages zwingend erfordert. Der Zweckübertragungsgrundsatz gilt sowohl für einfache wie für ausschließliche Nutzungsrechte, für den räumlichen, zeitlichen und inhaltlichen Umfang der Rechtseinräumung, für die Weiterübertragung der Nutzungsrechte auf Dritte, für die Nutzungsarten und für die Übertragung der Ausübung von Urheberpersönlichkeitsrechten4. Der Zweckübertragungsgrundsatz ist auch im Bereich der Softwareerstel- 68 lung anzuwenden, soweit nicht Arbeitsergebnisse betroffen sind, die in den Anwendungsbereich des § 69b UrhG fallen5. Sofern arbeitsvertraglich nichts anderes vereinbart worden ist, werden dem Arbeitgeber demgemäß nur die Rechte eingeräumt, die er zur Erfüllung seiner betrieblichen Aufgaben benötigt6. Sofern im Arbeitsvertrag nichts geregelt ist, muss der betriebliche Zweck 69 im Einzelfall ermittelt werden. Als Anhaltspunkt können die Produktionsweise des Betriebes und dessen Aufgabenstellung herangezogen werden7. So liegt die Nutzung des Werkes im Rahmen des betrieblichen Zwecks, wenn Software eines angestellten Programmierers verkauft und durch die Allgemeinheit genutzt wird8. Hat der Arbeitgeber mehrere Betriebe, so ist umstritten, ob sich der Umfang 70 der Rechtseinräumung nur nach den Bedürfnissen des Betriebs richtet, für den der Arbeitnehmer tätig ist9, oder ob bei Arbeitnehmern eines Konzern-

1 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 51. 2 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 51; Schricker/Rojahn, § 43 UrhG Rz. 41 f. 3 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 55; Schricker/Rojahn, § 43 UrhG Rz. 48. 4 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 57. 5 Zur Unanwendbarkeit der Zweckübertragungslehre im Rahmen von § 69b UrhG siehe BGH v. 24.10.2000 – X ZR 72/98, CR 2001, 223 = GRUR 2001, 155 (157). 6 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 55. 7 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 59. 8 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 59. 9 So Schricker/Rojahn, § 43 UrhG Rz. 53.

Karger

471

E Rz. 71

Verträge

unternehmens der betriebliche Zweck auch die Nutzung des Werks durch alle dem Konzern angehörenden Unternehmen umfassen kann1. 71 Sofern sich der Betriebszweck nachträglich ändert oder sich neue Verwertungsmöglichkeiten ergeben, ist zu klären, ob der Arbeitgeber weitere Nutzungsrechte benötigt, da die entsprechenden Rechte nicht automatisch von der stillschweigenden Nutzungsrechtseinräumung umfasst sind2. 72 Eine stillschweigende Rechtseinräumung für zum Zeitpunkt des Abschlusses des Arbeitsvertrags unbekannte Nutzungsarten scheidet aufgrund des Schriftformerfordernisses des § 31a Abs. 1 Satz 1 UrhG aus3. 73 Bei Fehlen einer ausdrücklichen vertraglichen Regelung sowie anderer Anhaltspunkte erwirbt der Arbeitgeber im Zweifel die ausschließlichen Nutzungsrechte, die allerdings auf den Zweck des Betriebs beschränkt sind4. Je nach Betriebszweck können die Nutzungsrechte in räumlicher, zeitlicher oder inhaltlicher Hinsicht beschränkt sein5. 74 Nach der wohl h.M. erfolgt die Einräumung der Nutzungsrechte an arbeitsvertraglich geschuldeten Werken grundsätzlich nicht nur für die Dauer des Arbeitsverhältnisses, sondern zeitlich unbeschränkt, d.h. der Arbeitgeber darf die geschützten Werke auch nach dem Ausscheiden des Arbeitnehmers aus dem Arbeitsverhältnis weiter verwerten6. Nach dieser Auffassung kommt eine zeitliche Begrenzung nur bei Vorliegen besonderer Umstände in Betracht. Die Gegenmeinung geht davon aus, dass die Einräumung der Nutzungsrechte mit der Beendigung des Arbeitsverhältnisses endet und der Arbeitgeber sich eine weitere Nutzung durch den Abschluss einer Folgevereinbarung sichern muss7. 75 Eine Übertragung der Nutzungsrechte durch den Arbeitgeber auf Dritte ist nach h.M. gem. § 34 Abs. 1 UrhG grundsätzlich nur mit ausdrücklicher oder stillschweigender Zustimmung des Arbeitnehmers zulässig, es sei denn, der betriebliche Tätigkeits- und Aufgabenbereich umfasst die Weiterübertragung von Nutzungsrechten oder die Verweigerung der Zustimmung wäre rechtsmissbräuchlich8. Wenn sich die Notwendigkeit der Übertragung von Nutzungsrechten aus den dem Arbeitnehmer bekannten betrieblichen Zielsetzungen ergibt, ist von einer stillschweigenden arbeitsvertraglichen Zustimmung auszugehen. So ist bei einem Arbeitnehmer, der eine erkenn-

1 2 3 4 5 6 7 8

Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 12. Schricker/Rojahn, § 43 UrhG, Rz. 54. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 50. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 73. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 75. Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 13. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 76 ff. Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 12; vgl. auch BGH GRUR 2005, 860 (862) – Fash 2000.

472

Karger

Softwareentwicklung durch Dritte

Rz. 79 E

bar zur Weitervermarktung an Dritte bestimmte Software zu entwickeln hat, eine stillschweigende Zustimmung zur Übertragung von Nutzungsrechten anzunehmen. (d) Urheberpersönlichkeitsrechte Neben den Nutzungsrechten stehen dem angestellten Urheber auch Urhe- 76 berpersönlichkeitsrechte zu, die unveräußerlich und nicht übertragbar sind. Der Arbeitnehmer kann jedoch in gewissen Grenzen, auch im Voraus, auf ihre Geltendmachung verzichten bzw. dem Arbeitgeber die Wahrnehmung seiner persönlichkeitsrechtlichen Befugnisse übertragen1. dd) Freie bzw. außervertragliche Werke Ein freies Werk (auch „außervertraglich geschaffenes Werk“ genannt2) liegt 77 vor, wenn der Arbeitnehmer das Werk nicht „in Erfüllung der Verpflichtungen aus dem Arbeitsverhältnis“ sondern nur „bei Gelegenheit“ der Beschäftigung oder ganz außerhalb des Beschäftigungsverhältnisses schafft3. Anders als bei Pflichtwerken besteht bei freien Werken i.d.R. keine arbeits- 78 vertragliche Pflicht zur Rechtseinräumung. Eine Verpflichtung zur Rechtseinräumung kann sich aber u.U. aus Tarifverträgen oder Betriebsvereinbarungen ergeben. Im Übrigen hat der Arbeitnehmer nach wohl überwiegender Meinung im Schrifttum eine Andienungspflicht. Dies wird teilweise mit einer analogen Anwendung der §§ 18, 19 ArbEG, teilweise mit der arbeitsrechtlichen Treuepflicht oder mit dem arbeitsvertraglichen Wettbewerbsverbot begründet4. Nach der Gegenmeinung ist eine generelle Andienungspflicht bezüglich freier Werke abzulehnen, da es an einer entsprechenden vertraglichen Verpflichtung des Arbeitnehmers fehle und die Bestimmungen des ArbEG nicht ohne weiteres analogiefähig seien5. d) Arbeitnehmererfindervergütung In dem Maße wie Softwareentwicklungen dem Schutz durch Patentrecht 79 zugänglich werden, gewinnt auch das damit verbundene, zwingende deutsche Arbeitnehmererfindervergütungsrecht Bedeutung. Dieses Vergütungsrecht bewegt in Deutschland substantielle Summen, ist hoch komplex und

1 S. weiterführend Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 84 ff.; Schricker/Rojahn, § 43 UrhG Rz. 73 ff. 2 Schricker/Rojahn, § 43 UrhG Rz. 100. 3 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 22. 4 Zum Diskussionstand siehe Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 30 ff.; Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 32 ff.; Schricker/ Rojahn, § 43 UrhG Rz. 100 ff. 5 So vor allem Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 34 ff.

M. Brandi-Dohrn

473

E Rz. 80

Verträge

belastend für die Unternehmen. Im Ausland ist es in kaum oder nur in wenig bedeutenden Ansätzen vorhanden1. aa) Überblick über das Arbeitnehmererfindergesetz (ArbEG) 80 Nach deutschem (§ 6 PatG) und europäischem Recht (Art. 60 EPÜ) steht das Recht auf das Patent originär der oder den natürlichen Personen zu, die Erfinder ist oder sind. Der Unternehmer oder das Unternehmen als eine weitere (juristische) Person muss sein Recht vom Erfinder ableiten. Das geschieht in Deutschland bei technischen Erfindungen von Angestellten durch Meldung nach § 5 ArbEG und Inanspruchnahme nach § 6 ArbEG. Dabei wird die unbeschränkte Inanspruchnahme fingiert, wenn der Arbeitgeber nicht binnen vier Monaten nach ordnungsgemäßer Meldung freigibt. Dagegen stellt § 9 ArbEG einen Anspruch auf angemessene Vergütung. Diese beruht auf dem Monopolprinzip: nicht gesondert zusätzlich zum Arbeitslohn vergütungspflichtig ist das einfache Leistungsergebnis, wohl aber das als Erfindung qualifizierte und nicht freigegebene, durch das der Arbeitgeber ein Ausschlussrecht, ein Monopol, gewinnt. Ob das Gemeldete eine Erfindung ist, wird durch Anmeldung beim Patentamt festgestellt. Zu der Anmeldung ist der Arbeitgeber nach § 13 ArbEG berechtigt und verpflichtet. 81 Unter Aufgabe viel weitergehender Reformvorschläge von 2001 ist das Arbeitnehmererfindergesetz 2009 mit dem Patentrechtsmodernisierungsgesetz vereinfacht worden: die zuvor geltende Schriftform ist durchweg – außer im Verfahren vor der Schiedsstelle – durch die Textform, also die lesbare auch unterschriftslose Erklärung ersetzt worden. Die schriftliche beschränkte oder unbeschränkte Inanspruchnahme ist ersetzt worden durch die Fiktion der unbeschränkten Inanspruchnahme, wenn der Arbeitgeber nicht binnen vier Monaten nach ordnungsgemäßer Meldung freigibt. Das beseitigt insbesondere bei der Meldung und Inanspruchnahme ab 1.10.2009 viele Probleme, denn bis dahin mussten sie schriftlich, also als Text mit eigenhändiger Unterschrift aller Erfinder bzw. des Arbeitgebers erfolgen. In der betrieblichen Praxis wird oft formlos, mündlich mitgeteilt und der Arbeitgeber meldet dann ohne weiteres an. Nach der Rechtsprechung des BGH2 ist die Meldung eine Wissenserklärung und der Arbeitgeber hat ausreichendes Wissen durch die Patentanmeldung bekundet. Hat er aber nicht innerhalb der früheren Vier-Monats-Frist schriftlich in Anspruch genommen, so war die Erfindung in Wirklichkeit frei und der Arbeitgeber war teuren Unterlassungsansprüchen seines Arbeitnehmers ausgesetzt. Die Schiedsstelle für Arbeitnehmererfinderstreitigkeiten beim DPMA hat diese

1 Zum ausländischen ArbNerf-Recht: Bartenbach/Volz, Komm. ArbEG Einleitung Rz. 10; Franke, Darstellung der Iat-Situation ArbEG – Internationaler Vergleich, VPP-Rundbrief 1999, 28. 2 BGH v. 4.4.2006 – X ZR 155/03 – Haftetikett, GRUR 2006, 755, folgend für das früheren Recht vor dem 1.10.2009: OLG Karlsruhe v. 28.4.2010 – 6 U 147/08 – formlose Meldung einer Initialidee, GRUR 2011, 318.

474

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 83 E

Rechtsprechung vehement kritisiert1. Nach ihr setzt die formlose Meldung die Inanspruchnahmefrist nicht in Gang, so dass auch später noch, wenn der Formfehler aufkommt, übergeleitet werden kann. Durch die Inanspruchnahmefiktion ist das Formfehlerproblem weitgehend entschärft, es besteht aber noch bei streitig werdenden formlosen Altfällen vor dem 1.10.2009. Zwischen der technischen Erfindung und dem einfachen Leistungsergebnis 82 stehen, schwer abgrenzbar, die qualifizierten technischen Verbesserungsvorschläge nach § 3 Abs. 1 ArbEG: Sie müssen einerseits technischen Charakter haben, so dass bloß kaufmännische Softwareentwicklung dafür nicht qualifiziert sind, bleiben aber unter der Schwelle der Schutzfähigkeit als Patent oder Gebrauchsmuster, sollen jedoch gleichwohl nach § 20 Abs. 1 ArbEG eine ähnliche Vorzugsstellung gewähren wie ein gewerbliches Schutzrecht. Die bloße Wahrung als Betriebsgeheimnis reicht für diese Vorzugsstellung nicht, sondern sie muss mit dem technischen Verbesserungsvorschlag selbst verbunden sein. Das kann bei technischer Software geradezu exemplarisch der Fall sein, denn der entscheidende Source Code gibt sich im Produkt nicht zu erkennen und ist ohne dem Betrieb entnommenen Datenträger auch kaum vermittelbar. Der technische Verbesserungsvorschlag ist ab Benutzung zu vergüten. Der technische qualifizierte Verbesserungsvorschlag ist eine Alternative zur Erfindung, die wegen entlegener Vorveröffentlichung nicht mehr schutzfähig ist aber aufgrund ihrer Komplexität, wie sie typisch für Software ist, eine ähnliche Vorzugsstellung gewährt. Wird eine Neuerung als technischer Verbesserungsvorschlag gemeldet und 83 behandelt und wird die gleiche Neuerung nachfolgend nochmals als Erfindung gemeldet und patentiert, so ergeben sich strittige Konkurrenzfragen. Die Schiedsstelle ist der Auffassung, mit der Meldung als Verbesserungsvorschlag sei dieser Charakter der Neuerung festgelegt, dem Arbeitgeber stehe ein unverlierbares Nutzungsrecht daran als Arbeitsergebnis zu und er habe nur nach dem betrieblichen Vorschlagswesen zu vergüten2. Im Fall des LG und OLG München3 hatte der Arbeitnehmer auf die erste Meldung als Ver1 Schiedsstelle v. 6.11.2008 – ArbErf 039/07, in: Bartenbach, Gewerbl. Rechtsschutz, 2009 I 254; Schiedsstelle v. 1.10.2009 – ArbErf 036/06, in: Bartenbach, Gewerbl. Rechtsschutz, 2010 I 206; Schiedsstelle v. 21.10.2010 – ArbErf 021/09, in: Bartenbach, Gewerbl. Rechtsschutz, 2011 I 211. 2 Schiedsstelle v. 21.6.2006 – ArbErf 038/05, in: Bartenbach, Gewerbl. Rechtsschutz, 2007 I 347, und Bartenbach/Himmelmann in ihrer Kritik zu LG München in: Bartenbach, Gewerbl. Rechtsschutz, 2008 I 226; Im Fall der Schiedsstelle hatte der Arbeitgeber den zuerst gemeldeten Verbesserungsvorschlag mit 9900 DM prämiiert, auf die spätere Erfindungsmeldung ein Patent angemeldet, das auch erteilt wurde, und hat an Erfindervergütung ca. 14 000–9900 DM geleistet. Der Arbeitnehmer hielt das für zu wenig, die Schiedsstelle für schon zu viel, weil überhaupt keine Erfindervergütung mehr geschuldet sei. 3 LG München I v. 12.7.2007 – 21 O 17880/05 – Keramikschneidwerkzeug, InstG 8, 136, berichtet auch in: Bartenbach, Gewerbl. Rechtsschutz, 2008 I 224; OLG München v. 26.6.2008 – 6 U 2022/07, Mitt. 2009, 417 mit Anm. Eck, Mitt. 2009, 367.

M. Brandi-Dohrn

475

E Rz. 84

Verträge

besserungsvorschlag 40 000 DM Prämie erhalten, die zweite Meldung als Erfindung hatte der Arbeitgeber abgelehnt, mithin freigegeben unbeschadet der Behandlung der Verbesserungserfindung. Der Arbeitgeber hat daraufhin selbst angemeldet, und sein Lizenznehmer hat den Arbeitgeber wegen Benutzung seines, des Arbeitnehmers Patent auf vollen Schadensersatz verklagt. LG und OLG München haben der Klage ohne ein Benutzungsrecht des Arbeitgebers stattgegeben. LG und OLG München ist zuzustimmen, denn der technisch orientierte Arbeitnehmer hat oft nicht die Kenntnis, um seine Neuerung zwischen Verbesserungsvorschlag und Erfindung richtig anzusiedeln. Bessert er oder auch sein Arbeitgeber durch Anmeldung den Rang nach und kommt der Neuerung tatsächlich der bessere Rang der Erfindung zu, so ist sie nach diesem spezielleren Rang zu behandeln, also als Erfindung zu vergüten unter Anrechnung (str.) der schon auf den Charakter als Verbesserungsvorschlag gezahlten Vergütung, und im spezielleren Rang der Erfindung verdrängt ein nach Freigabe durch den Arbeitnehmer erlangtes Patent das Benutzungsrecht des Arbeitgebers am allgemeinen oder besonderen Arbeitsergebnis. 84 Was als Vergütung angemessen ist, ist näher geregelt in den Arbeitnehmererfindervergütungsrichtlinien (RL) von 19591, die jedoch nicht gesetzlich verbindlich sind. Die Bemessung der angemessenen Vergütung ist durch eine Jahrzehnte lange Spruchpraxis der Schiedsstelle beim DPMA sehr verfeinert worden. Dabei fällt die Vergütung für ein geprüftes Patent höher aus als für ein ungeprüftes Gebrauchsmuster oder einen ungeprüften, qualifizierten technischen Verbesserungsvorschlag; letztere müssen einen Abschlag von ca. 1/3 hinnehmen2. 85 Für die angemessene Vergütung wird zuerst einmal der Erfindungswert (E) ermittelt. Bei durch Außenumsatz genutzten Erfindungen geschieht das regelmäßig nach der Lizenzanalogie, RL 6–11. Diese Frage spaltet sich: – in die nach der betriebsüblichen oder ansonsten üblichen Lizenz für solche Fälle3, – und in die nach dem Umsatz und nach der Bezugsgrundlage, denn bei komplexen Vorrichtungen, z.B. einer Maschine mit einer patentierten Steuerung, kann es sein, dass nur ein Teil durch das erfindungsgemäße Patent geschützt ist. Dann wird es bei der Erfindervergütung ebenso wie 1 Abgedruckt z.B. Beck Texte im dtv, Patent- und Musterrecht unter Nr. 16; kommentiert von Bartenbach/Volz, ArbEG; Bartenbach/Volz, Arbeitnehmererfindervergütung, Kommentar zu den Richtlinien (KommRL (3), 2009). 2 Bartenbach/Volz, § 9 ArbEG Rz. 250 für Gebrauchsmuster und § 20 ArbEG Rz. 40 für qualifizierte technische Verbesserungsvorschläge; Schiedsstelle v. 1.12.2010 – ArbErf 074/08, in: Bartenbach, Gewerbl. Rechtsschutz, 2011 I 327 (340 ff.) und v. 23.2.2011 – ArbErf 045/08 in: Bartenbach, Gewerbl. Rechtsschutz 2011 II 797, 819. 3 Gesammelte Erfahrungssätze bieten Bartenbach/Volz, KommRL (3), 2009, 10 Nr. 91–144; Groß/Rohrer, Lizenzgebühren (3) 2012; Hellebrand/Himmelmann, Lizenzsätze für technische Erfindung, 4. Aufl. 2011.

476

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 86 E

beim Schadensersatz nach der Lizenzanalogie oft streitig, ob Lizenzbasis die mit einem Aufschlag, Regelfaktor 1,6, versehenen Herstellkosten des patentierten Teils sind oder der Umsatz des ganzen Wirtschaftsguts. Nach dem BGH ist die sachgerechte Bezugsgröße im Einzelfall nach Verkehrsüblichkeit und Zweckmäßigkeit zu bestimmen, wobei es eine Rolle spielen kann, ob das Ganze durch den geschützten Teil eine Wertsteigerung erfährt1. Außerdem müsse der Lizenzsatz ausgleichend für den Teil höher und für das Ganze niedriger sein. Die Schiedsstelle ist da einschränkend präziser. Sie knüpft grundsätzlich an die kleinste funktionelle, technisch wirtschaftliche Einheit nach dem Patent an und schätzt von da aus, welche Problemkreise der Gesamtvorrichtung durch die Erfindung wertsteigernd beeinflusst sind2 und nimmt dann deren Umsatz entweder ganz oder geschätzt teilweise. Beim Umsatz ist weiterhin nicht selten streitig, ob die in RL 11 vorgeschlagene Abstaffelung bei hohen Umsätzen anzuwenden ist. Die Schiedsstelle staffelt bei hohen Umsätzen aus dem Gesichtspunkt der Kausalitätsverschiebung regelmäßig ab, weil für besonders hohe Umsätze zunehmend die Erfindung weniger kausal werde als Goodwill, Vertriebsorganisation und Werbung des Arbeitgeberunternehmens, während die Gerichte entsprechend RL 11 nur bei nachgewiesener Üblichkeit abstaffeln3. Die übliche Lizenz hätte ungeschmälert ein freier Erfinder als hypothetischer Lizenzgeber vereinbart. Bei einem Angestellten wird dieser Erfindungswert alsdann mit einem Anteilsfaktor (A %) multipliziert, der dem Umstand Rechnung tragen soll, dass der Arbeitnehmer nicht das Verwertungsrisiko und nicht die Schutzrechtskosten trägt und von vornherein gegen Vergütung für den Dienstherrn tätig ist. Der Anteilsfaktor ergibt sich aus den Wertzahlen a) für Stellung der Aufgabe (RL 31), b) für Lösung der Aufgabe (RL 32) und c) für Stellung im Betrieb (RL 33–36): Eigeninitiative bei der Aufgabe zählt mehr, als wenn der Arbeitgeber sie vorgibt, und die Putzfrau bekommt mehr als der Forschungsleiter. Für die

1 BGH v. 18.2.1992 – X ZR 8/90 – Steuereinrichtung I, GRUR 1992, 599; BGH v. 30.5.1995 – X ZR 54/93 – Steuereinrichtung II, GRUR 1995, 578: Lizenzgrundlage nicht nur die geschützte Steuereinrichtung und die Wechselventile, in denen sie wirkt, sondern der gesamte gesteuerte Teleskopzylinder. 2 Z.B. Schiedsstelle v. 4.3.2010 – ArbErf 059/08, in: Bartenbach, Gewerbl. Rechtsschutz, 2010 II 742: Problem war, inwieweit ein Teil des Hardwareumsatzes auch einer der beteiligten Software Erfindungen zuzurechnen war. 3 BGH v. 4.10.1988 – X ZR 71/86 – Vinylchlorid, GRUR 1990, 271: Abstaffelung nur bei festgestellter Üblichkeit; dagegen Hellebrand’s Doktrin der Kausalitätsverschiebung in GRUR 1993, 449, der die Schiedsstelle nachdrücklich folgt: Schiedsstelle v. 8.12.2010 – ArbErf 006/09 – Batterieseparatoren, in: Bartenbach, Gewerbl. Rechtsschutz, 2011 I 307.

M. Brandi-Dohrn

477

86

E Rz. 87

Verträge

addierten Wertzahlen wird aus einer Tabelle in RL 37 der Anteilsfaktor (A)1 abgelesen bzw. interpoliert. a+b+c = 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 (20) A = 2 4 7 10 13 15 18 21 25 32 39 47 55 63 72 81 90 (100) % Die jährliche, zusätzliche Erfindervergütung (V) ist dann: V = E × A %. Der Erfindungswert E ist dabei U × L (Umsatz × hypothetischer Lizenzsatz in %) 87 Zur Durchsetzung hat der Arbeitnehmer gegen den Arbeitgeber einen Auskunftsanspruch nach Treu und Glauben, § 242 BGB. Diesen „drangsalierenden“ Auskunftsanspruch hat der BGH in der Vergangenheit sehr weit gefasst und auch auf den Gewinn des Arbeitgebers mit erfindungsgemäßen Produkten erstreckt2. Das ist bedeutend entschärft worden. Nach BGH – Türinnenverstärkung, ist eine Gewinnauskunft grundsätzlich nicht mehr geschuldet3. 88 In der Industrie werden in weitem Umfang Abkaufregelungen für die sog. „lästigen Rechte“ praktiziert: der Anmeldepflicht, § 13 ArbEG, der Anbietungspflichten bei Aufgabe, §§ 14, 16 ArbEG, und der Zusatzvergütung bei geänderten Umständen, § 12 Abs. 6 ArbEG. Zum Teil wird dabei auch die im Streitfall besonders belastende Auskunftspflicht auf eine einfache Umsatzauskunft4 und nur auf Auskunft seitens des Wirtschaftsprüfers des Unternehmens beschränkt. Die Abkaufvergütungen schwanken dabei von Betrieb zu Betrieb und, zum Teil auch nach Wertigkeit des Schutzrechts, zwischen 100–1200 Euro5. Abkaufregelungen sind als Vereinbarungen nach Meldung der Diensterfindung, § 22 ArbEG, also nicht vorher als generelle Regelung im Arbeitsvertrag, zulässig, müssen sich aber am Unbilligkeitsverbot des § 23 ArbEG messen lassen6. Gerichtsentscheidungen dazu sind bislang nur marginal vorhanden7. 1 Der Anteilsfaktor A liegt relativ am häufigsten bei 11–23 %. Der Durchschnittswert ist 19 %, Dänner, Studie BDI/BDA zum ArbEG; Industrieposition, Kritik am Ist-Stand, VPP-Rundbrief 1999, 31. 2 BGH v. 13.11.1997 – X ZR 132/95 – Copolyester II, GRUR 1998, 689; BGH v. 13.11.1997 – X ZR 6/96 – Spulkopf, GRUR 1998, 689. 3 BGH v. 17.11.2009 – X ZR 137/07 – Türinnenverstärkung, GRUR 2010, 223. 4 Vgl. Schiedsstelle v. 21.6.2001, PMZ 2002, 230 – Ansprüche des Arbeitnehmererfinders auf Auskünfte und Rechnungslegung – beschränkt auf Nettoumsätze, Stückzahlen und Nettoverkaufspreise i.d.R. ohne Abnehmernamen und ohne Gewinnauskunft, auch nicht zur Bestimmung der angemessenen Lizenzhöhe. 5 Bartenbach, Gewerbl. Rechtsschutz, 2003 I 188 ff.; Franke, FS Bartenbach (2004), S. 127; Franke/Steiling, Novellierung des ArbEG – kein Ende in Sicht, Die Industrie reagiert mit Incentive-Systemen, FS 50 Jahre VPP (2005), S. 281. 6 Trimborn, Mitt. 2006, 160, empfiehlt daher, das Anpassungsrecht nicht von vornherein ganz abzukaufen, sondern eine Zusatzvergütung offen zu halten für spätere hohe Umsätze. 7 Der BGH hat im Urt. v. 4.10.1988 – X ZR 71/86 – Vinylchlorid, GRUR 1990, 271 befunden, dass eine Pauschalvergütung von 300 000 + 180 000 DM unbillig

478

M. Brandi-Dohrn

Rz. 90 E

Softwareentwicklung durch Dritte

Zur außergerichtlichen Streitregelung für dieses komplexe Vergütungssys- 89 tem ist beim DPMA die Schiedsstelle für Arbeitnehmererfindervergütungen nach §§ 37–39 ArbEG gebildet worden. Bei bestehendem Arbeitsverhältnis muss sie vor einer Vergütungsklage beim ordentlichen Gericht angerufen werden mit einer Wartefrist von sechs Monaten für die Zeit eines Schiedsstellenverfahrens, § 37 ArbEG. Bei Werkverträgen kann zwar eine Vergütung für Erfindungen nach dem ArbEG schuldrechtlich vereinbart werden, das begründet aber nicht die sachliche Zuständigkeit der Schiedsstelle1. Die Schiedsstelle wird grundsätzlich gebildet aus einem ständigen Vorsitzenden und zwei Ad-hoc-Beisitzern aus dem DPMA, davon einer aus dem betreffenden technischen Gebiet. Sie fällt keine schiedsrichterliche Entscheidung, sondern unterbreitet einen Einigungsvorschlag zur Annahme. Lehnt binnen einem Monat keine Seite ab, so gilt der Einigungsvorschlag als angenommen. Lehnt eine Seite ab oder ist die Wartefrist verstrichen, so bleibt es jeder Seite offen, das ordentliche Gericht (Kammer für Patentstreitsachen) anzurufen. Durch Erfahrung, Mäßigung, Gründlichkeit, cooling off und das Annahmeerfordernis hat die Schiedsstelle einen sehr hohen Grad von Akzeptanz. Das Verfahren vor der Schiedsstelle ist kostenfrei und es gibt grundsätzlich keine Kostenerstattung. bb) Besonderheiten beim vertikalen Entwicklungsvertrag Beim vertikalen Entwicklungsvertrag ist der Erfindungswert problematisch. 90 Das entwickelnde Unternehmen bekommt oft keine laufende Lizenzgebühr, sondern seine Auftragsvergütung und wird im Allgemeinen vertraglich verpflichtet, das Ergebnis einschließlich etwaiger Erfindungen auf den Auftraggeber zu übertragen. Nach RL 16 ist Erfindungswert die Gegenleistung, die der Arbeitgeber für die Entwicklung vom Auftraggeber erhält, hier also ein Quasi-Kaufpreis. Wenn die Vergütung neben Selbstkostenerstattung einen kalkulatorischen Gewinnanteil ausweist, was bei Entwicklungsaufträgen der öffentlichen Hand oft der Fall ist, dann ist dieser Gewinnanteil die Vergütungsbasis2. Bei einem einheitlichen Vergütungsbetrag steht ist, wenn sie die aus der zur Zeit ihrer Vereinbarung absehbaren wirtschaftlichen Entwicklung und der danach geschuldeten „richtigen“ Vergütung um 32 % unterschritt. Die Schiedsstelle bezeichnet eine umfassende Abkaufregelung im Einigungsvorschlag v. 4.3.2010 – ArbErf 059/08, in: Bartenbach, Gewerbl. Rechtsschutz, 2010 I 744 (768), als in der Regel gültig, wenn vereinbart und nicht einseitig auferlegt. Incentive-Zahlungen seien auf Erfindervergütungsansprüche nicht anrechenbar. In verschiedenen Vorschlägen hat sich die Einigungsstelle auf den Standpunkt gestellt, Abkaufvereinbarungen seien dann nicht unbillig, wenn sie eine industrieübliche Gegenleistung, ca. 300 t, enthielten. Diese Spruchpraxis hat die Einigungsstelle aufgegeben. Sie verlangt kein Regelentgelt mehr, sondern prüft im Einzelfall. Schiedsstelle v. 18.7.2012 – ArbErf 030/10 in: Bartenbach, Gewerbl. Rechtsschutz 2012 II 727. 1 Schiedsstelle v. 5.2.2009 – ArbErf 025/08, in: Bartenbach, Gewerbl. Rechtsschutz, 2009 I 211. 2 LG Hamburg in EGR ArbEG § 5 Nr. 34.

M. Brandi-Dohrn

479

E Rz. 91

Verträge

diese Gegenleistung nur zu einem Bruchteil für anfallende Immaterialgüterrechte zur Verfügung. Hier setzt die Schiedsstelle im allgemeinen 1 % der Gesamtauftragssumme als Erfindungswert für sämtliche im Rahmen des Auftrags entwickelten Erfindungen an, dabei 0,5 % wenn der Auftraggeber nur ein einfaches Nutzungsrecht erhält1. Da das ein fiktiver Bruttokaufpreis für die Veräußerung ist, wird er durch Umrechnung mit einem Regelfaktor von 40 % auf den Nettokaufpreis heruntergerechnet, weil ein Erfinderverkäufer nie den gesamten Kaufpreiserlös weitergeben würde sondern allemal einen Abzug für Kosten, kalkulatorische Kosten und Eigengewinn machen würde, Nr. 16 RL2. Bei mehreren zu übertragenden Erfindungen, teilt sich der Betrag folglich auf die Erfindungen und die daran jeweils beteiligten Erfinder auf. Unerheblich ist, welchen Umsatz und Nutzen ein Dritter, insbesondere der Auftraggeber aus der ihm übertragenen Entwicklung samt Erfindungen zieht. 91 Baut das arbeitgebende Entwicklungsunternehmen die Entwicklung anschließend in Serie und liefert die Serienprodukte an den Entwicklungsauftraggeber oder an Dritte, so nimmt die Schiedsstelle bei Lieferungen an den Auftraggeber an, dass die Produkte, z.B. Maschinen, die von der erfundenen Software gesteuert werden, zur freien Benutzung und ohne eine Lizenzpflicht an den Auftraggeber zu liefern sind. Daher gelte für den Arbeitnehmer nicht die Lizenzanalogie aus dem Maschinenumsatz, sondern aus dem Maschinenumsatz die 1 %-Regelung mit 40 % Abschlag davon3 als Entgelt für die Übertragung der Erfinderrechte auf den Auftraggeber4. Liefert der Entwickler an Dritte, so ist, wenn die Steuerung prägend ist, der Maschinenumsatz die Basis nach der Formel U × L × A. Das führt zu stoßend ungleichen Ergebnissen. Liefert das Entwicklungsunternehmen erfindungsgemäße Güter, so sollte dieser Umsatz immer die Vergütungsbasis sein. Sind Arbeitnehmer des Auftraggebers an der erfinderischen Entwicklung beteiligt, so sollen sich nach einer Entscheidung des OLG Frankfurt5 die Ar1 Bartenbach/Volz, § 9 ArbEG Rz. 197; Schiedsstelle v. 4.4.1995 – ArbErf 053/93, ArbEG-CD-Rom; Schiedsstelle v. 12.8.1997 – ArbErf 084/95, ArbEG-CD-Rom; Schiedsstelle v. 22.5.2003 – ArbErf 70/00, in: Bartenbach, Gewerbl. Rechtsschutz, 2004 I 281 (287); Schiedsstelle v. 24.10.2002 – ArbErf 29/01, in: Bartenbach, Gewerbl. Rechtsschutz, 2003 I 331: ausnahmsweise 5 % bei einem patentträchtigen Forschungsinstitut als Auftragnehmer; Schiedsstelle v. 6.10.2006 – ArbErf 10/06, in: Bartenbach, Gewerbl. Rechtsschutz, 2007 I 309; Schiedsstelle v. 25.11.2008 – ArbErf 003/08, in: Bartenbach, Gewerbl. Rechtsschutz, 2009 II 738; Schiedsstelle v. 23.11.2010 – ArbErf 033/09 in: Bartenbach, Gewerbl. Rechtsschutz 2011 II 820/828. 2 Schiedsstelle v. 25.11.2008 – ArbErf 003/08, in: Bartenbach, Gewerbl. Rechtsschutz, 2009 II 738. 3 Siehe vorstehend Rz. 90. 4 Schiedsstelle v. 23.11.2010 – ArbErf 033/90, Medizinprodukte, in: Bartenbach, Gewerbl. Rechtsschutz, 2011 II 820. 5 OLG Frankfurt v. 30.4.1992 – 6 U 98/89 – Simulation für Radioaktivität, GRUR 1992, 852 (854).

480

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 93 E

beitnehmer im Verhältnis ihrer Beteiligung den Erfindungswert U × L teilen. Nach der Schiedsstelle übertragen die miterfindenden Arbeitnehmer die Miterfinderbruchteilsgemeinschaft auf ihre Arbeitgeber, und diese dürfen nach § 743 Abs. 2 BGB jeweils die ganze Erfindung frei nutzen. Der Erfindervergütungsanspruch richtet sich aber immer nur gegen den eigenen Arbeitgeber, also bei Entwicklungsangestellten gegen den entwickelnden Auftragnehmer mit dem bei ihm geringen Erfindungswert von 1 %, auch wenn der Auftraggeber die Erfindervergütung übernommen hat, denn er übernimmt sie nur so gering wie sie gegenüber dem entwickelnden Auftragnehmer besteht1. Dementsprechend wären Mitarbeiter des Auftraggebers an dessen Umsatz U beteiligt, zu 100 %, aber mit einem der Mitinhaberschaft entsprechenden reduzierten Lizenzsatz L in der Lizenzanalogie2. Forschungsfördermittel der öffentlichen Hand werden für die Entwicklung gegeben. Da sie keinen Verwertungsnutzen repräsentieren, sind sie grundsätzlich auch keine Vergütungsbasis3.

92

Bei Gemeinschaftsentwicklungen bestehen zwischen den Muttergesellschaf- 93 ten und dem Gemeinschaftsunternehmen vertikale Entwicklungsaufträge. Das Forschungs- und Entwicklungspersonal wird von dem Entwicklungs-Gemeinschaftunternehmen angestellt und vergütet. Die Arbeitnehmererfindervergütungansprüche richten sich gegen die Tochtergesellschaft4, prinzipiell nicht aber gegen die Muttergesellschaft. Da die Entwicklungstochter regelmäßig keinen Produktionsumsatz hat, sie die Erfindungen vielmehr im Allgemeinen kostenlos zur Nutzung den Muttergesellschaften überlässt, ist die Bezugsgrundlage für die Vergütung ein Problem. Der BGH hat es der tatrichterlichen Bewertung der Umstände überlassen, ob der Konzern bei wirtschaftlicher Betrachtung ausnahmsweise als Einheit mit der Folge der Vergütung nach Konzernaußenumsatz zu nehmen sei, oder ob eine fiktive Unterlizenz der nutzenden Konzerngesellschaften anzunehmen sei5. Bei einer ausgeprägt arbeitsteiligen Konzernstruktur und bei der Ausgründung der Entwicklungsabteilung in eine 1 Schiedsstelle v. 6.10.2006 – ArbErf 010/06, in: Bartenbach, Gewerbl. Rechtsschutz, 2007 I 309. 2 Schiedsstelle v. 19.4.2012 – ArbErf 023/10, Bremsbelag, in: Bartenbach, Gewerbl. Rechtsschutz, 2012 II 610. 3 Schiedsstelle v. 13.8.1978 – ArbErf 307/75, PMZ 1977, 53 – Zuwendung ist kein fiktiver Umsatz; Schiedsstelle v. 28.6.21994 – ArbErf 054/93, ArbEG-CD-ROM. 4 OLG München v. 8.2.2001 – 6 U 5650/99 – Verankerungsmittel, GRUR-RR 2001, 103, die deutsche Entwicklungs-GmbH übertrug die bei ihr gemachten Entwicklungen gegen Unkosten + 4 % an die Liechtensteinische Holding. Der Anspruch des Erfinders, am Konzernaußenumsatz beteiligt zu werden, wurde abgelehnt; Schiedsstelle v. 22.4.2004 – ArbErf 43/02, in: Bartenbach, Gewerbl. Rechtsschutz, 2004 II 642; Schiedsstelle v. 17.6.2010 – ArbErf 014/09 – Fruchtgummi, in: Bartenbach, Gewerbl. Rechtsschutz, 2010 I 816 (840). 5 BGH v. 16.4.2002 – X ZR 127/99 – Abgestuftes Getriebe, GRUR 2002, 801, aus Anlass einer Auskunftsklage des Arbeitnehmererfinders über den Konzernaußenumsatz. BGH v. 6.3.2012 – X ZR 104/09, antimykotischer Nagellack, GRUR

M. Brandi-Dohrn

481

E Rz. 94

Verträge

GmbH ohne Umsatz, um auf diese Weise die Vergütungsansprüche zu unterlaufen, liegt wirtschaftliche Konzerneinheit mit Zurechnung anderweiter Umsätze nahe1. 94 Bei der oft anzutreffenden kostenlosen Übertragung auf die Konzernmutter kalkuliert die Schiedsstelle im allgemeinen einen fiktiven Verkaufspreis als Vergütungsbasis, nämlich 1–2 % aus dem Zehnjahresumsatz mit der an die Muttergesellschaft übertragenen Erfindung, wovon alsdann noch 60 % für kalkulatorische Kosten, Unternehmerlohn und Gemeinkosten abgezogen werden2. cc) Arbeitnehmervergütung bei Softwareerstellung im Kooperationsverhältnis 95 Jedes Unternehmen, das im Auftragsverhältnis oder in Kooperation mit anderen Partnern entwickelt, ist sowohl für die Überleitung von Erfindungen seiner Arbeitnehmer auf sich und zur Weitergabe an Auftraggeber oder Kooperationspartner verantwortlich wie auch für etwaige Erfindervergütungen nach § 9 ArbEG an seine Arbeitnehmer3. Vorbehaltlich des AÜG bleibt auch der entsandte Arbeitnehmer eigener Arbeitnehmer des Entsenderunternehmens4. In § 11 Abs. 7 AÜG ist jedoch geregelt, dass bei gewerblicher, erlaubter Leiharbeit für die Arbeitnehmererfindervergütung der Entleiher als Arbeitgeber gilt. 96 Außerhalb des AÜG wird vergütungspflichtig für Erfindungen grundsätzlich nicht der Kooperationspartner, bei dem entwickelt wird, sondern der entsendende Kooperationspartner, mit dem das Arbeitsverhältnis besteht. Basis für die Vergütung ist der geldwerte Nutzen, den derjenige Kooperationspartner zieht, dessen Arbeitnehmer Vergütung beansprucht5.

1

2

3 4 5

2012, 605: i.d.R. sind die konzerninternen Abgabepreise des Arbeitgebers anzusetzen. Angedeutet in OLG München – Verankerungsmittel; Schiedsstelle v. 31.1.2002 – ArbErf 090/99 berichtet in: Bartenbach, Gewerbl. Rechtsschutz, 2002 583; Schiedsstelle v. 12.1.2011 – ArbErf 012/08 – Reinigung von Kreislaufwasser, in: Bartenbach, Gewerbl. Rechtsschutz, 2011 I 407. Schiedsstelle v. 10.12.1998 – ArbErf 073/96 und 115/96, berichtet in: Bartenbach, Gewerbl. Rechtsschutz, 1999, 223; Schiedsstelle v. 22.2.2001 – ArbErf 069/98 – Kaufpreisschätzungsmethode, in: Bartenbach, Gewerbl. Rechtsschutz, 2001, 632. Bartenbach/Volz, § 9 ArbEG Rz. 191. Schiedsstelle v. 19.6.1991 – ArbErf 070/90 – Entsendung zur spanischen Tochtergesellschaft, ArbEG-CD-ROM. Schiedsstelle v. 9.9.1993 – ArbErf 155/92 – Vergütung bei Auftragsentwicklung – referiert bei Bartenbach, Gewerbl. Rechtsschutz, 1994, 143; Schiedsstelle v. 22.1.2004 – ArbErf 60/02, LS 3 bei Bartenbach, Gewerbl. Rechtsschutz, 2004 I 322; Schiedsstelle v. 12.10.2010 – ArbErf 023/09 – Löschen von Koks, in: Bartenbach, Gewerbl. Rechtsschutz, 2011 I 357; Bartenbach/Volz, § 9 ArbEG Rz. 192 ff.

482

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 100 E

Verwerten beide durch Herstellung und Lieferung an Dritte, so ist Bezugs- 97 grundlage der jeweilige Umsatz. Machen z.B. die Kooperationspartner A und B durch ihre Arbeitnehmer A’ (50 %) und B’ (50 %) eine patentfähige Entwicklung, und liefert A an C für 1 Mio. Euro und B an D für 500 000 Euro, so berechnet sich die Vergütung, wenn man annimmt, der Anteilsfaktor bei A’ sei 25 %, der von B’ 20 % und der angemessene Lizenzsatz 5 %, nach der Vergütungsformel V = E × A wie folgt: A’ ist an dem 50 %-Anteil des A, den dieser mit 1 Mio. realisiert, beteiligt mit 25 % × 5 % = 12 500 Euro Vergütungsanspruch gegen A. B’ ist an dem 50 %-Anteil des B, den dieser mit 500 000 Euro realisiert, beteiligt mit: × 20 % × 5 % = 5000 Euro gegenüber B. Erzielt ein Partner Umsatz und zahlt an den anderen für dessen Erfindungsbeitrag eine Ausgleichslizenz, so ist diese die Vergütungsbasis. Würde z.B. B 1000 Stück an A zum Vorzugspreis von 1000 minus 50 liefern, wobei 50 als abgegoltene Nutzung von A’s Schutzrechtsanteil kalkuliert sind, würde also B einen Lizenzausgleich von 50, entsprechend L = 5 %, an A leisten, so ändert sich das Berechnungsbeispiel wie folgt:

98

B’ (50 %): 950 000 Euro × 20 % × 5 % = 9500 Euro A’ (50 %): 50 000 (Bruttolizenz), das entspricht etwa 15 000 Euro Nettolizenz × 25 % = 2500 Euro.1 Zur Erklärung der „Nettolizenz“ folgendes: Da A als fiktiver freier Lizenz- 99 geber Gemeinkosten, Lizenzkosten und Schutzrechtserhaltungskosten haben würde und Gewinn erzielen soll, sind die Bruttolizenzeinannahmen auf eine Nettolizenz herunterzuschleusen, RL 14. Im Allgemeinen ist auch noch ein Know-How-Lizenzanteil abzuschätzen und abzuziehen, RL 14 Abs. 2. Nach der Praxis der Schiedsstelle entspricht die der Vergütung etwa 30 % der nach Abzug konkreter Kosten zugrunde zu legende Nettolizenz oder etwa 20 % der Bruttolizenz2. Erzielt nur ein Partner Verwertungsumsatz an Dritte und der andere nichts, 100 so ist zu prüfen, ob der nicht verwertende Partner wirklich keinerlei Nutzen hat, oder ob nicht ein mittelbarer Nutzen zu schätzen ist. Sind nutzender und leer ausgehender Kooperationspartner gesellschaftlich verbunden, so kann eine teilweise Zuordnung des Umsatzes vom nutzenden Partner zum nur entwickelnden Partner in Betracht kommen. Richtiger ist es aber wohl, eine fiktive Lizenz anzusetzen. Liefert der eine Kooperationspartner 1 Vgl. Schiedsstelle v. 29.7.2009 – ArbErf 029/06, CD-ROM Rechtsprechung zum ArbEG, wegen kalkulatorischer Kosten und Unternehmergewinn ist der Erfindungswert in der Regel 20 % der Bruttolizenz. Vergütungen aus dem Lizenzanteil bei A/A’ vgl. Schiedsstelle v. 23.11.2010 – ArbErf 033/90 – Medizinprodukte in: Bartenbach, Gewerbl. Rechtsschutz, 2011 II 820. 2 Schiedsstelle v. 29.10.1997 – ArbErf 013/96, in: Bartenbach, Gewerbl. Rechtsschutz, 1998, 146: fiktive Lizenz minus Kosten, davon minus 70 % für kalkulatorischen Unternehmerlohn und Gemeinkosten.

M. Brandi-Dohrn

483

E Rz. 101

Verträge

nicht nur erfinderische Ideen, sondern ein nutzbares Produkt zur Eigenverwendung an den anderen, im Beispielsfall also A für 1 Mio. Euro an B, so legt das OLG Frankfurt den Verwertungsumsatz als gemeinsamer Nutzen bei beiden für die Vergütung zugrunde1. Also: A’ (50 %): 1 Mio. Euro × 50 % × 25 % × 5 % = 6500 Euro B’ (50 %): 1 Mio. Euro × 50 % × 20 % × 5 % = 5000 Euro Dieses Ergebnis ist angemessen, denn aus 1 Mio. wäre auch dann sowohl an A’ als auch an B’ Vergütung zu zahlen gewesen, wenn beide bei A angestellt gewesen wären. Der Umsatz wird also letztlich nicht doppelt belastet. Nach der Schiedsstelle2 soll hingegen A’ 40 % von 1 % (Immaterialgüterentgelt) aus 1 Mio. Euro × A = 25 % also 10 000 Euro bekommen. 101

Wird eine Softwareerfindung im Rahmen eines Konsortial-Projektvertrags durch einen Gesellschafter der Arbeitsgemeinschaft genutzt, so ist das eine dem Arbeitgeber-Gesellschafter zuzurechnende Nutzung, ist also vergütungspflichtige Nutzung, wenn und soweit sie beim Arbeitgeber zu geldwerten Vorteilen führt. Vergütungsbasis ist dabei der Vergütungsanteil, der auf den Arbeitgeber-Projektkonsorten entfällt3. dd) Besonderheiten beim Geschäftsführer oder Gesellschafter

102

Erfindungen der Organe und aktiven Gesellschafter einer OHG, die mit Mitteln des Betriebs zustande gekommen sind, unterliegen nicht dem ArbEG. Diese Erfindungen sind aber im Allgemeinen – die Vertragsauslegung, auch ergänzende Vertragsauslegung mag anderes ergeben – aufgrund der dienstvertraglichen Treuepflicht nach § 611 BGB dem Unternehmen stillschweigend übertragen4.

103

Der Geschäftsführer kann eine Sondervergütung nach § 612 Abs. 2 BGB verlangen, wenn eine solche sich durch Vertragsauslegung, auch ergänzende, hilfsweise nach billigem Ermessen, § 315 BGB, ergibt. Und das kann der Fall sein, wenn er eine überobligationsmäßige, nicht vertraglich abgegoltene Son1 OLG Frankfurt v. 30.4.1992 – 6 U 98/89 – Simulation von Radioaktivität, GRUR 1992, 852. 2 Schiedsstelle v. 23.11.2010 – ArbErf 033/09, Medizinprodukt in: Bartenbach, Gewerbl. Rechtsschutz, 2011 II 820. 3 Bartenbach/Volz, § 9 ArbEG Rz. 195; Schiedsstelle v. 20.4.2004 – ArbErf 70/02, in: Bartenbach, Gewerbl. Rechtsschutz, 2004 II 612. 4 BGH GRUR 1955, 286 – Schnellkopierer – Vorausverfügung über Erfindungen zugunsten der Gesellschaft nach Inhalt und Zweck des Gesellschaftsvertrages; BGH GRUR 1965, 302 – Schellenreibungskupplung – Stillschweigende Übertragung aus dienstvertraglicher Treuepflicht für einen kaufmännischen Geschäftsführer; OLG Düsseldorf v. 10.6.1999 – 2 U 11/98 – Geschäftsführererfindung, GmbHR 1999, 1093 = GRUR 2000, 49 – Mangels ausdrücklicher Vereinbarung Anbietungs- und Übertragungspflicht oder Lizenzierungspflicht nach hypothetischem Parteiwillen nach den Gesamtumständen.

484

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 107 E

derleistung erbracht hat1. Eine Sonderleistung erbringt der kaufmännische oder der Finanzvorstand eher als der technische Entwicklungsvorstand. Kann der Gesellschafter oder Geschäftsführer eine Sondervergütung verlan- 104 gen, so berechnet sich diese zwar nicht nach dem ArbEG analog, aber die Wertungen des ArbEG bei der Begrenzung von Vergütungen für Dienstpflichtige sind zu berücksichtigen2. ee) Besonderheiten bei Hochschulentwicklungen Nach dem alten § 42 ArbEG waren die Erfindungen von Professoren und 105 wissenschaftlichen Assistenten deren freies geistiges Eigentum. Auftraggeber mussten also (auch) mit den Professoren abschließen, um Rechte auf sich überzuleiten. Nach dem neuen § 42 ArNErfG, das für Erfindungen nach dem 7.2.2002 gilt, 106 müssen die an den Hochschulen Beschäftigten, also auch Professoren und wissenschaftliche Mitarbeiter, ihre Diensterfindungen zur Inanspruchnahme melden, wenn sie sie überhaupt im Rahmen ihrer Lehr- und Forschungstätigkeit offenbaren wollen. Wollen sie publizieren, so müssen sie ihre Erfindung melden und die Publikationsabsicht zwei Monate zuvor der Universität anzeigen (§ 42 Nr. 1 ArbEG), damit die Universität Gelegenheit hat, vor der neuheitsschädlichen Publikation eine Patentanmeldung zu hinterlegen (positive Publizierfreiheit). Wollen sie aus Gründen ihrer Lehr- und Forschungsfreiheit nicht veröffentlichen, so müssen sie nicht melden (negative Publizierfreiheit – § 42 Nr. 2 ArbEG). Ob die zweimonatige Anzeigefrist verfassungsgemäß ist, ist mit einer Vorlage an das BVerfG in Zweifel gezogen worden3. Das BVerfG4 hat die Vorlage als unzulässig verworfen, dabei aber ziemlich klar angedeutet, dass es die Verfassungsbedenken nicht teile. Dem ist der BGH gefolgt5. Die Professoren und wissenschaftlichen Mitarbeiter erhalten für ihre ge- 107 meldeten Erfindungen eine hohe Vergütung, nach § 42 Nr. 4 ArbEG 30 %

1 BGH v. 24.10.1989 – X ZR 58/88 – Auto-Kindersitz, CR 1990, 403 = GRUR 1990, 193; OLG Düsseldorf v. 10.6.1999 – 2 U 11/98 – Geschäftsführer-Erfindung, GmbHR 1999, 1093 = GRUR 2000, 49: Erfindung sei Sonderleistung gegenüber allgemeiner Leitungsfunktion, es sei denn die Produktentwicklung gehöre konkret zu den dienstvertraglichen Aufgaben; BGH v. 26.9.2006 – X ZR 181/03 – Rollenantriebseinheit II, GRUR 2007, 52. 2 BGH v. 24.10.1989 – X ZR 58/88 – Autokindersitz, CR 1990, 403 = GRUR 1990, 193; BGH v. 26.9.2006 – X ZR 181/03 – Rollenantrieb II, GRUR 2007, 52; detailliert obwohl außerhalb ihrer Zuständigkeit, Schiedsstelle ArbErf 049/97 – ArbEG-CD-ROM und Bartenbach, Gewerbl. Rechtsschutz, 1999, 419. 3 LG Braunschweig Mitt. 2004, 74 – selbststabilisierendes Knie. 4 BVerfG v. 12.3.2004 – 1 BvL 7/03, NVwZ 2004, 974; OLG Braunschweig Mitt. 2006, 41 – selbststabilisierendes Knie II: § 42 ArbEG ist verfassungskonform. 5 BGH v. 18.9.2007 – X ZR 167/05 – Selbststabilisierendes Knie, GRUR 2008, 150.

M. Brandi-Dohrn

485

E Rz. 108

Verträge

der erzielten Einnahmen, also der Bruttoeinnahmen. Diese umfassen alle geldwerten Vorteile, auch vom Industriepartner übernommene Patentanmeldekosten1. 108

Auch nach dem neuen § 42 ArbEG bleibt es ratsam im Hinblick auf eine Abbedingung der negativen Publizierfreiheit und gegebenenfalls anderweitigen Regelung der Warnfrist, dass das auftraggebende, Drittmittel zur Verfügung stellende Unternehmen auch mit dem Professor und, ggf. über ihn als Vertreter, mit seinen wissenschaftlichen Mitarbeitern abschließt2. e) Vergütung aa) Zivilrecht bzw. Arbeitsrecht

109

Der Arbeitnehmer erhält für seine Tätigkeit die vertraglich vereinbarte Vergütung. Diesbezüglich gelten zunächst die zivil- bzw. arbeitsrechtlichen Bestimmungen und Grundsätze. Für Entwicklungsleistungen, die außerhalb der arbeitsvertraglichen Verpflichtungen oder aufgrund einer vom Arbeitsvertrag nicht gedeckten Weisung des Arbeitgebers erbracht werden, kann der Arbeitnehmer nach arbeitsrechtlichen Grundsätzen eine gesonderte Vergütung, insbesondere eine Vergütung für geleistete Überstunden verlangen3. bb) Ansprüche gem. §§ 32, 32a UrhG

110

Neben den zivil- bzw. arbeitsrechtlichen Vergütungsgrundsätzen sind bei der Erstellung urheberrechtlich geschützter Software die besonderen Vergütungsvorschriften des Urheberrechts zu beachten, namentlich die §§ 32, 32a, 32b UrhG. § 32c UrhG sieht nunmehr eine Vergütungsregelung für neue, zum Zeitpunkt des Vertragsschlusses unbekannte Nutzungsarten vor4.

111

Diese Bestimmungen gehen inhaltlich deutlich über die Bestimmungen des Schuldrechts hinaus, indem sie dem Urheber den Anspruch auf eine angemessene Vergütung bzw. auf eine zusätzliche Beteiligung sichern und ihm bei Vorliegen der gesetzlichen Voraussetzungen einen Anspruch gegen den Auftraggeber bzw. Verwerter auf Einwilligung in eine Vertragsänderung zubilligen. Die §§ 32, 32a, 32b UrhG finden auf alle Vertragstypen Anwendung, die zumindest auch die Einräumung von Nutzungsrechten zum Gegenstand haben, insbesondere also auf Werk- und Dienstverträge im Bereich der Softwareerstellung5. Ob bzw. inwieweit die §§ 32 und 32a UrhG auch

1 BGH v. 5.2.2013 – X ZR 59/12, Genveränderung, GRUR 2013, 498. 2 Bartenbach/Volz, § 42 ArbEG Rz. 193. 3 Bayreuther, in: Münchener Handbuch zum Arbeitsrecht, § 91 Rz. 39; s. hierzu auch Benecke, NZA 2002, 883 (885 f.); Bayreuther, GRUR 2003, 570. 4 S. hierzu Kreile, ZUM 2007, 682. 5 Grunert, in: Wandtke/Bullinger, § 32 UrhG Rz. 4, § 32a UrhG Rz. 2; Grützmacher, in: Wandtke/Bullinger, § 69a UrhG Rz. 70.

486

Karger

Softwareentwicklung durch Dritte

Rz. 114 E

auf angestellte Softwareprogrammierer anwendbar sind, ist allerdings umstritten1. § 32c UrhG gilt jedenfalls auch in Arbeitsverhältnissen2. (1) Regelungsinhalt § 32 Abs. 1 Satz 3 UrhG korrigiert die Angemessenheit der vertraglichen 112 Vergütung für den Normalfall der vertraglichen Nutzung, während der „Bestsellerparagraph“ § 32a UrhG dem Urheber im Nachhinein zusätzliche Beteiligungsansprüche gewährt, wenn seine Vergütung in ein auffälliges Missverhältnis zu den Erträgen des Verwerters gerät3. § 32c UrhG gewährt dem Urheber einen Anspruch auf eine gesonderte angemessene Vergütung, wenn der Vertragspartner eine neue Art der Werknutzung nach § 31a UrhG aufnimmt, die im Zeitpunkt des Vertragsschlusses zwar (schriftlich) vereinbart, aber noch unbekannt war. Die Ansprüche der §§ 32 und 32a UrhG stehen selbständig mit jeweils eigenem Anwendungsbereich nebeneinander4. § 32c UrhG geht § 32 UrhG teilweise vor5 und steht in Anspruchskonkurrenz zu § 32a UrhG6. Auf eine Vereinbarung, mit der von § 32 Abs. 1 und 2 UrhG zum Nachteil 113 des Urhebers abgewichen wird, kann sich der Vertragspartner gem. § 32 Abs. 3 UrhG nicht berufen. Auch Umgehungsgestaltungen sind unwirksam. Auf Ansprüche gem. § 32a Abs. 1 und 2 UrhG kann gem. § 32a Abs. 3 UrhG nicht im Voraus verzichtet werden. §§ 32 und 32a UrhG finden gem. § 32b UrhG zwingende Anwendung, wenn auf den Nutzungsvertrag mangels Rechtswahl deutsches Recht anzuwenden wäre oder soweit Gegenstand des Vertrags maßgebliche Nutzungshandlungen in Deutschland sind. Gem. § 32c Abs. 3 UrhG kann auf die Rechte nach § 32c Abs. 1 und 2 UrhG im Voraus nicht verzichtet werden. Der Urheber kann aber unentgeltlich ein einfaches Nutzungsrecht für jedermann einräumen. Die §§ 32, 32a und 32c UrhG können für den Auftraggeber bzw. Verwerter 114 erhebliche wirtschaftliche Belastungen mit sich bringen, so dass teilweise Überlegungen angestellt werden, ob und inwieweit hier durch entsprechende Vertragsgestaltung gegengesteuert werden kann, z.B. durch Regelungen zur Verjährung oder zur Rechtswahl7. Bezüglich des Regelungsinhalts der §§ 32, 32a und 32b UrhG im Einzelnen kann im Übrigen auf oben Kap. A Rz. 173 ff. verwiesen werden. 1 Für eine Anwendbarkeit Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 145 f.; Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 22; a.A. Wimmers/Rode, CR 2003, 399; vgl. hierzu auch Benecke, NZA 2002, 883; Bayreuther, GRUR 2003, 570. 2 Grunert, in: Wandtke/Bullinger, § 32c UrhG Rz. 3. 3 Grunert, in: Wandtke/Bullinger, § 32 UrhG Rz. 47. 4 Grunert, in: Wandtke/Bullinger, § 32 UrhG Rz. 47. 5 Grunert, in: Wandtke/Bullinger, § 32c UrhG Rz. 23. 6 Grunert, in: Wandtke/Bullinger, § 32c UrhG Rz. 25. 7 S. hierzu etwa Hertin, MMR 2003, 16 (18 ff.).

Karger

487

E Rz. 115

Verträge

(2) Anwendbarkeit bei Rechtsübertragungen nach § 69b UrhG 115

Die Frage, ob die Bestimmungen der §§ 32, 32a, 32b, 32c UrhG neben § 69b UrhG anwendbar sind, wird uneinheitlich beantwortet1.

116

Nach der Rechtsprechung des BGH ist grundsätzlich davon auszugehen, dass der Arbeitnehmer für seine Leistung und die Überlassung von deren Ergebnis, soweit die Erstellung solcher Werke zu seinen arbeitsvertraglichen Pflichten gehört, regelmäßig mit dem Arbeitslohn bezahlt worden ist. Für eine weitere Vergütung ist in diesem Rahmen regelmäßig kein Platz mehr2. Diese Rechtsprechung entspricht der im überwiegenden Schrifttum vertretenen Abgeltungstheorie, nach der mit dem Gehalt jeweils auch die Einräumung der Nutzungsrechte abgegolten ist.

117

Allerdings hat der BGH die Anwendbarkeit des alten „Bestsellerparagraphen“ § 36 UrhG a.F. neben § 69b UrhG nicht ausgeschlossen3. Dies könnte als Indiz dafür gesehen werden, dass die Rechtsprechung auch die §§ 32, 32a UrhG neben § 69b UrhG anwenden wird4. Teilweise wird vertreten, dass eine Anwendbarkeit neben § 69b UrhG ausgeschlossen ist5. (3) Anwendbarkeit im Bereich des § 43 UrhG

118

Die Anwendbarkeit der §§ 32, 32a, 32b, 32c UrhG im Bereich des § 43 UrhG ist ebenfalls umstritten. Nach einer im Schrifttum vertretenen Auffassung steht der Anspruch auf angemessene Vergütung gem. § 32 UrhG grundsätzlich auch dem Arbeitnehmerurheber zu. Auch § 32a und § 32c UrhG finden nach dieser Auffassung uneingeschränkt Anwendung6; dies soll auch für den Zeitraum nach Beendigung des Arbeitsverhältnisses gelten7. Die Gegenmeinung räumt ein, dass der Wortlaut des Gesetzes für die Anwendbarkeit der §§ 32, 32a, 32b UrhG auf Arbeitsverhältnisse spricht. Sie kommt jedoch im Wege einer teleologischen Auslegung zu einem anderen Ergebnis: Danach soll § 32 UrhG im Arbeitsverhältnis unanwendbar sein. Der „Bestsellerpragraph“ § 32a UrhG müsse restriktiv i.S.d. § 36 UrhG a.F. ausgelegt werden und könne letztlich nur in den seltenen Ausnahmefällen des Vorliegens eines „groben Missverhältnisses“ zur Anwendung kommen8.

1 Ausführlich zum Diskussionsstand bzgl. §§ 32 und 32a UrhG Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 22 ff. 2 BGH v. 23.10.2001 – X ZR 72/98 – Wetterführungspläne II, CR 2002, 249 (251). 3 BGH v. 23.10.2001 – X ZR 72/98 – Wetterführungspläne II, CR 2002, 249 (252). 4 Vgl. Grützmacher, in: Wandtke/Bullinger, § 69b UrhG Rz. 24. 5 Wimmers/Rode, CR 2003, 399 (403 ff.). 6 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 145. 7 Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 149. 8 Wimmers/Rode, CR 2003, 399 (401 ff.).

488

Karger

Softwareentwicklung durch Dritte

Rz. 120 E

f) Geheimhaltung aa) Einführung/Interessenlage Software und softwarebezogene Dokumentationen stellen wertvolles tech- 119 nisches und fachliches Wissen dar. Fachliches Wissen ist, jenseits der Programmierung als solcher, in Software und Dokumentation oft in der Form enthalten, dass bestimmte betriebliche Arbeitsabläufe in der Software abgelegt sind bzw. durch diese unterstützt werden. Es ist daher ein natürliches Bestreben des Arbeitgebers, den Arbeitnehmer dazu zu verpflichten, im Arbeitsverhältnis zur Kenntnis erhaltenes oder erworbenes technisches bzw. fachliches Wissen gegenüber jedem Unbefugten geheim zu halten, auch nach der Beendigung des Arbeitsverhältnisses. Entsprechendes gilt für alle anderen Arten von Geschäfts- und Betriebsgeheimnissen wie z.B. Kundendaten, Kalkulationsunterlagen, Marketingkonzepte, Vertragsverhandlungen und deren Stand, Preislisten und dergleichen, aber auch für sonstige Betriebsinterna, die der Arbeitgeber schon aus grundlegenden Erwägungen (vertraglich) geschützt sehen möchte. Mit zunehmendem technischen Fortschritt sind die Mittel, mithilfe derer eine Kopie von geheimzuhaltenden Unterlagen/Informationen erstellt werden kann, immer leichter zu handhaben: Wo man früher großformatige Pläne mühsam kopieren oder abfotografieren musste, ist heute die Mitnahme entsprechender Daten einfacher zu handhaben – sofern nicht der Arbeitgeber in technischer Hinsicht Vorsorge getroffen hat, um gerade solche einfachen Datenmitnahmen zu verhindern. Zwar hat ein redlich handelnder Arbeitnehmer während des bestehenden Arbeitsverhältnisses ebenfalls ein Interesse daran, dass Betriebs- und Geschäftsgeheimnisse seines Arbeitgebers nicht nach außen dringen; es ist aber ebenso ein natürliches Interesse des ausscheidenden Arbeitnehmers, sich bei einem Arbeitsplatzwechsel gegenüber dem neuen Arbeitgeber als dort dringend benötigter Know-how-Träger darstellen zu können. In diesem Spannungsfeld sind Geheimhaltungsabreden zu sehen, die in keinem Arbeitsvertrag der Softwarebranche fehlen sollten. bb) Geheimhaltungsverpflichtung Während des bestehenden Arbeitsverhältnisses besteht eine Geheimhal- 120 tungsverpflichtung stets auch ohne ausdrückliche vertragliche Vereinbarung, schon aufgrund der allgemeinen arbeitsrechtlichen Treuepflicht. Gleichwohl finden sich in Arbeitsverträgen vielfach Abreden, die ausdrücklich eine Geheimhaltung auch während des laufenden Arbeitsverhältnisses anordnen. Problematisch ist dabei weniger der Umstand der Geheimhaltung als solcher, sondern oft die sachliche Reichweite. Indirekt ergibt sich arbeitsrechtlicher Geheimnisschutz auch aus § 17 Abs. 1 UWG, der bestimmte Fälle des Geheimnisverrats während des bestehenden Arbeitsverhältnisses unter Strafe stellt. Anwendbar ist in einigen Fällen auch § 203 StGB, der das „Ausspähen von Daten“ unter Strafe stellt. Gennen

489

E Rz. 121 121

Verträge

Von der arbeitsvertraglichen Geheimhaltungspflicht umfasst werden zunächst sog. „Betriebs- und Geschäftsgeheimnisse“ des Arbeitgebers. Hierunter sind alle Tatsachen, gleich ob technischer oder wirtschaftlicher Art, zu verstehen, die mit dem Geschäftsbetrieb im Zusammenhang stehen, nur einem eng begrenzten Personenkreis zugänglich sind, also noch nicht offenkundig sind, über den Stand der Technik hinausgehen und für deren Geheimhaltung ein begründetes (wirtschaftliches) Interesse besteht1. Als geheimhaltungswürdige Tatsachen hat die Rechtsprechung u.a. Unterlagen über neue technische Verfahren, Mängel der hergestellten Waren, Konstruktionspläne, Herstellungsverfahren oder Versuchsergebnisse angesehen2. Hierunter fallen auch Anwendungssoftware ebenso wie Steuerungssoftware für Maschinen, Know-how enthaltende Maschinen (z.B. Rechner, Hardwarekomponenten), Kalkulationsunterlagen, Kundenlisten usw. Der Unwertgehalt eines Verstoßes gegen §§ 17, 18 UWG geht über das bloße „Nicht-Schweigen“ hinaus und stellt auch das Ausspähen oder die unberechtigte Verwertung von Betriebs- und Geschäftsgeheimnissen unter Strafe, und zwar auch über die Dauer des Arbeitsverhältnisses hinaus, § 17 Abs. 2 UWG. Die Ausspähung muss allerdings durch die in § 17 Abs. 2 UWG näher beschriebene Art und Weise, d.h. durch die Anwendung technischer Mittel, Herstellung einer verkörperten Wiedergabe des Geheimnisses oder Wegnahme einer Sache, in der das Geheimnis verkörpert ist (z.B. ein Datenträger), erfolgt sein. Unter der Verwertung eines Geschäfts- und Betriebsgeheimnisses versteht man mehr als das bloße Innehaben des Geheimnisses. Umfasst wird jede Art der wirtschaftlichen Nutzung zur Gewinnerzielung (z.B. Produktionsaufnahme oder -umstellung, Veräußerung, Lizenzerteilung, Werbung). Ein Verwerten liegt auch vor, wenn die unbefugte Kenntniserlangung nur teilweise oder mittelbar die Verwertungshandlung ermöglicht hat, sofern nicht das Geheimnis dabei eine völlig unbedeutende Rolle gespielt hat. Modifikationen oder Weiterentwicklungen ändern daher nichts am Vorliegen des Verwertungstatbestands, solange für das Geheimnis entscheidende Grundelemente beibehalten worden sind und dasselbe technische Ergebnis ohne Kenntnis des Vorbilds nicht oder nicht in derselben Zeit oder mit derselben Zuverlässigkeit hätte erreicht werden können.

122

Nach § 18 UWG ist auch strafbar, wenn der Arbeitnehmer ihm im geschäftlichen Verkehr anvertraute Vorlagen oder Vorschriften technischer Art, insbesondere Zeichnungen, Modelle, Schablonen, Schnitte, Rezepte, zu Zwecken des Wettbewerbs oder aus Eigennutz unbefugt verwertet oder jemandem mitteilt. Hier bietet es sich an, eine Verpflichtung des Arbeitnehmers in 1 BAG v. 16.3.1982 – 3 AZR 83/79, BB 1982, 1792 ff., zuletzt BAG v. 10.3.2009 – 1 ABR 87/07, NZA 2010, 180, Kauffmann-Lauven, in: Münchener Anwaltshandbuch Arbeitsrecht, § 57 Rz. 32. 2 BAG v. 16.3.1982, AP Nr. 1 zu § 611 BGB („Betriebsgeheimnis“); BAG v. 26.2.1987, AP Nr. 2 zu § 79 Betriebsverfassungsgesetz 1972; Kauffmann-Lauven, in: Münchener Anwaltshandbuch Arbeitsrecht, § 60 Rz. 36.

490

Gennen

Softwareentwicklung durch Dritte

Rz. 125 E

den Arbeitsvertrag aufzunehmen, nach Beendigung des Arbeitsverhältnisses alle im Eigentum des Arbeitgebers stehenden Gegenstände, Dokumente, Daten einschließlich seiner eigenen Aufzeichnungen auszuhändigen. Des Weiteren sollte überlegt werden, ob der Arbeitnehmer eine schriftliche Versicherung abgeben sollte, alle relevanten Unterlagen an den Arbeitgeber herausgegeben zu haben. Neben diesen „Betriebs- und Geschäftsgeheimnissen“ kann der Arbeitgeber 123 auch ein berechtigtes Interesse an der Geheimhaltung bestimmter anderer, von ihm als vertraulich bezeichneter Tatsachen haben, z.B. persönlichkeitsrelevante Tatsachen. Hierbei kann es sich auch um Informationen aus anderen Konzernunternehmen handeln, d.h. Informationen bestimmter, rechtlich selbständiger Dritter. Es empfiehlt sich eine Klarstellung im Arbeitsvertrag, dass auch solche Informationen Dritten nicht zugänglich zu machen sind. Unwirksam wäre jedoch eine Geheimhaltungsverpflichtung, die sich als sog. „Allklausel“ unterschiedslos auf alle betrieblichen Angelegenheiten bezieht, sich also auf „alle während der Betriebszugehörigkeit erhaltenen Kenntnisse und Tatsachen“ erstreckt, denn hierunter werden auch Kenntnisse/Tatsachen sein, an deren Geheimhaltung der Arbeitgeber kein berechtigtes Interesse hat1. Wird bei bestehendem Arbeitsverhältnis gegen eine wirksame Geheimhal- 124 tungsverpflichtung in Bezug auf Betriebs- und Geschäftsgeheimnisse verstoßen, hat der Arbeitgeber einen Unterlassungsanspruch, einen Anspruch auf Auskunft über die Umfänge der Verratshandlungen, einen Schadensersatzanspruch und unter den Voraussetzungen der §§ 17, 18 UWG einen Anspruch auf Bestrafung (Antragsdelikt). Fester Bestandteil einer Geheimhaltungsverpflichtung sollte auch eine Vertragsstrafenabrede für den Fall der Zuwiderhandlung sein; eine solche Abrede ist als Standardabrede in Arbeitsverträgen trotz § 309 Nr. 6 BGB für den Fall des Geheimnisverrats wirksam2. Dann kann der Arbeitgeber, zumal ein Schadensersatz vielfach nicht leicht nachzuweisen sein wird, jedenfalls die Vertragsstrafe fordern. Und schließlich dürfte ein Geheimnisverrat für den Bestand des Arbeitsvertrages ernste Konsequenzen haben – es ist an eine Kündigung aus wichtigem Grund zu denken (§ 626 Abs. 1 BGB), jedenfalls an eine ordentliche Kündigung aus verhaltensbedingten Gründen; eine Abmahnung kann im Einzelfall entbehrlich sein. Bei Führungskräften kann sogar schon der bloße (dringende) Verdacht des Geheimnisverrats zur Kündigung aus wichtigem Grund ohne Abmahnung berechtigen3. Die Aufnahme einer Geheimhaltungsverpflichtung in den Arbeitsvertrag 125 ist nach alledem, soweit sie für den Zeitraum des Bestehens des Arbeitsverhältnisses gelten soll, nicht zwingend erforderlich, aber aus Gründen des Signalcharakters sehr empfehlenswert. 1 BAG NZA 2000, 199. 2 Vgl. BAG v. 4.3.2004 – 8 AZR 196/03, MDR 2004, 1062 = NZA 2004, 727. 3 Vgl. LAG Köln v. 17.8.2001, EzA-SD 4/2002, 14.

Gennen

491

E Rz. 126

Verträge

cc) Nachvertragliche Geheimhaltungsverpflichtungen 126

Typischerweise werden arbeitsvertragliche Geheimhaltungsverpflichtungen auch über das Ende des Arbeitsverhältnisses hinaus vereinbart. Jedoch gilt nach wohl h.M. auch ohne besondere Vereinbarung über dieses Ende hinaus eine Geheimhaltungsverpflichtung1. Hier befindet man sich in einem der schwierigsten Bereiche zivilrechtlichen Geheimnisschutzes. Ein Arbeitnehmer darf grundsätzlich nach Beendigung des Arbeitsverhältnisses seine rechtmäßig (d.h. nicht unter Verletzung von Dienstpflichten, Geheimhaltungspflichten Dritter etc.) erlangten beruflichen Kenntnisse und Erfahrungen offenbaren und verwerten und dabei auch zu seinem ehemaligen Arbeitgeber in Wettbewerb treten2. Andererseits endet das – anerkennenswerte – Interesse des Arbeitgebers an der Geheimhaltung von dem Unternehmen zuzuordnenden Betriebs- und Geschäftsgeheimnissen nicht mit dem Ausscheidenszeitpunkt.

127

Zwar lässt sich in Bezug auf die Betriebs- und Geschäftsgeheimnisse aus Entscheidungen des BAG ableiten, dass diese auch ohne ausdrückliche Abrede nach der Beendigung des Arbeitsverhältnisses geheim gehalten werden müssen3, aber es ist insoweit gleichwohl empfehlenswert, eine ausdrückliche Regelung in den Vertrag aufzunehmen, zum einen wegen des Signalcharakters, zum anderen, weil nicht sicher sein kann, dass die Rechtsprechung des BAG Bestand hat.

128

Eine nachvertragliche Geheimhaltungsverpflichtung, die den Arbeitgeber nichts kostet, darf im Ergebnis nicht zum Wettbewerbsverbot werden, denn ein solches wäre nur gegen Zahlung von Karenzentschädigung zu haben, siehe dazu Rz. 151. Wo hier die Trennlinie zu ziehen ist, ist und bleibt umstritten. Die Rechtsprechung des BAG geht wohl dahin, nicht nur eine Verpflichtung zur Wahrung eines bestimmten, in der Abrede näher bezeichneten Geheimnisses als wirksam anzusehen, sondern auch eine Abrede, die den Arbeitnehmer verpflichtet, alle Betriebs- und Geschäftsgeheimnisse weiterhin geheim zu halten; verhindert werden aber nicht die Wettbewerbstätigkeiten des Arbeitnehmers als solche4. So soll ein Arbeitnehmer zwar gehindert sein, Kundenlisten des ehemaligen Arbeitgebers an Dritte zu verraten, nicht aber, die auf dieser Liste stehenden Kunden des ehemaligen Arbeitgebers selbst zu umwerben. Verallgemeinert man dies, ist der Arbeitnehmer zwar gehindert, Betriebsgeheimnisse Dritten mitzuteilen, nicht 1 Vgl. etwa Bartenbach, FS Küttner, S. 113 ff. (kritisch); Erfurter Kommentar/Preis, § 611 BGB Rz. 718 (dafür) u.a. 2 BAG v. 15.6.1993, AP Nr. 40 zu § 611 BGB Konkurrenzklausel. Zum Wettbewerbsverbot s. unten unter Rz. 147 ff. 3 BAG v. 15.12.1987, AP Nr. 12 zu § 611 Betriebsgeheimnis BAG v. 16.3.1982, AP Nr. 1 zu § 611 BGB Betriebsgeheimnis. 4 Vgl. BAG v. 16.3.1982, AP Nr. 1 zu § 611 BGB Betriebsgeheimnis; BAG v. 15.12.1987, AP Nr. 12 zu § 611 Betriebsgeheimnis; BAG v. 15.6.1993, AP Nr. 40 zu § 611 BGB Konkurrenzklausel; BAG v. 19.5.1998 – 9 AZR 394/97, NZA 1999, 200.

492

Gennen

Softwareentwicklung durch Dritte

Rz. 133 E

aber, diese – in wohl noch von der Rechtsprechung herauszuarbeitendem Umfang – selbst in einer Weise auszuwerten, die es Dritten nicht möglich macht, hierauf Zugriff zu nehmen. „Redlich erworbenes Erfahrungswissen“ darf nach dem Ende des Arbeitsverhältnisses eingesetzt werden, auch für einen Wettbewerber. Der BGH geht davon aus, dass Wissen, das der ausgeschiedene Mitarbeiter in seinem Gedächtnis behält, weiter verwendet werden darf, nicht jedoch darf er Aufzeichnungen aus der Zeit eines Mitarbeiterverhältnisses, die ein Geschäftsgeheimnis enthalten, z.B. handschriftliche Notizen oder in einem Computer gespeicherte Daten, nach dem Ende des Beschäftigungsverhältnisses weiter verwenden; dies wäre eine unbefugte Verschaffung nach § 17 Abs. 2 Nr. 2 UWG1. Die möglichen Folgen eines Verstoßes gegen eine wirksame Geheimhal- 129 tungsabrede sind im Wesentlichen dieselben wie bei bestehendem Arbeitsverhältnis. Bestimmte Formen der Zuwiderhandlung gegen § 17 UWG sind auch nach dem Arbeitsverhältnis möglich; auch im Übrigen kann das UWG eingreifen, wenn wettbewerbswidrige Handlungen erfolgen. Selbstverständlich scheidet eine Kündigung aus, da das Arbeitsverhältnis bereits beendet ist; allerdings kommen in eng begrenzten Ausnahmefällen Sanktionen wie z.B. der Widerruf einer Ruhegeldzusage in Betracht2. dd) Geheimhaltungspflicht nach § 24 ArbEG Eine spezialgesetzliche Geheimhaltungspflicht der Arbeitsvertragsparteien 130 im Hinblick auf bestimmte Arbeitsergebnisse findet sich in § 24 ArbEG. Nach Abs. 1 hat der Arbeitgeber die ihm gemeldete oder mitgeteilte technische Erfindung so lange geheim zu halten, wie es die berechtigten Belange des Arbeitnehmererfinders erfordern. Nach Abs. 2 hat der Arbeitnehmer eine Erfindung so lange geheim zu halten, bis sie nach § 8 Abs. 1 ArbEG frei geworden ist. Die in § 24 ArbEG normierte Pflicht bezieht sich allein auf technische Er- 131 findungen. Computerprogramme sind „als solche“ mangels technischen Charakters nicht patentfähig (§ 1 Abs. 2 PatG); jedoch existiert eine Unzahl technischer Erfindungen, bei denen Software ein wesentlicher Bestandteil ist. Das ArbEG und mithin § 24 ArbEG hat dementsprechend auch erhebliche Bedeutung in der Informationstechnologiebranche. Geheimhaltung i.S.d. § 24 ArbEG bedeutet, die in der Erfindung verkörperte 132 technische Lehre Dritten nicht in irgendeiner Form mitzuteilen oder sonst wie zur Kenntnis zu bringen bzw. deren Kenntnisnahme zu ermöglichen3. Die Geheimhaltungspflicht des Arbeitgebers kann sich über die Dauer des 133 Arbeitsverhältnisses hinaus erstrecken (vgl. § 26 ArbEG), da nach § 24 Abs. 1 ArbEG nur auf die „berechtigten Belange des Arbeitnehmers“ abge1 BGH NJW 2006, 3424. 2 Vgl. z.B. BAG v. 15.6.1993, AP Nr. 40 zu § 611 BGB Konkurrenzklausel. 3 Bartenbach/Volz, § 24 ArbEG Rz. 6.

Gennen

493

E Rz. 134

Verträge

stellt wird. Grundsätzlich wird man eine Geheimhaltungspflicht so lange annehmen müssen, wie dem Arbeitnehmer die Möglichkeit der prioritätsbegründenden Schutzrechtsanmeldung und/oder der Nutzung des Erfindungsgegenstandes unter Ausschaltung Dritter verbleibt. Dies ist auf jeden Fall nicht mehr bei Offenkundigkeit der Erfindung oder Überholung durch den Stand der Technik gegeben1. Sollte der Arbeitgeber seine Geheimhaltungspflicht verletzen, steht dem Arbeitnehmer nach § 823 Abs. 2 BGB i.V.m. § 24 Abs. 1 ArbEG ein Schadensersatzanspruch zu. Daneben besteht ein Schadensersatzanspruch aus dem Arbeitsverhältnis wegen Verletzung einer arbeitsvertraglichen Fürsorgepflicht nach §§ 611, 280 Abs. 1 BGB. 134

Die Geheimhaltungspflicht des Arbeitnehmers nach Abs. 2 erstreckt sich grundsätzlich nur auf Diensterfindungen i.S.d. § 4 Abs. 2 ArbEG. Eine weiter gehende Verpflichtung kann sich unter Umständen aber aus allgemeinen arbeitsvertraglichen Nebenpflichten ergeben. Die zeitliche Dauer dieser Geheimhaltungsverpflichtung aus § 24 Abs. 2 ArbEG bestimmt sich nach § 8 Abs. 1 ArbEG und kann sich insoweit auch über die Dauer des Arbeitsverhältnisses hinaus erstrecken, § 26 ArbEG. Wie auch bei der den Arbeitgeber treffenden Geheimhaltungspflicht besteht die Geheimhaltungsverpflichtung nicht mehr, wenn die Erfindung offenkundig geworden ist. Gleiches gilt im Falle des Verzichts des Arbeitgebers auf eine Geheimhaltung oder aber dem Zeitpunkt der ersten Offenlegung der Patentanmeldung nach § 32 Abs. 1 PatG. Im Gegensatz zum Arbeitgeber trifft den Arbeitnehmer jedoch immer noch eine Geheimhaltungspflicht, auch wenn die Erfindung technisch bereits überholt ist2. Verletzt der Arbeitnehmer seine Geheimhaltungspflicht, besteht ein Anspruch des Arbeitgebers nach § 823 Abs. 2 BGB i.V.m. § 24 Abs. 2 ArbEG oder auch §§ 611, 280 Abs. 1, 619a BGB. Sollte durch die Verletzung der Geheimhaltungspflicht des Arbeitnehmers ein Schaden bei einer anderen Person, bspw. einem Lizenznehmer des Arbeitgebers, entstanden sein, kann dieser ggf. den Schadensersatzanspruch im Wege der Drittschadensliquidation geltend machen3. ee) Geheimhaltungspflicht bei Datenverarbeitung

135

Mit Datenverarbeitung beschäftigte Arbeitnehmer sind i.d.R. nach § 5 BDSG zur Geheimhaltung der ihnen zur Kenntnis gelangten personenbezogenen Daten verpflichtet. Sie dürfen personenbezogene Daten nicht unbefugt entnehmen, verarbeiten oder nutzen. Eine solche Kenntniserlangung ist im Bereich der Softwareerstellung nicht selten. Vielfach werden die abschließenden Tests neu erstellter Individualsoftware auf einem System durchgeführt, auf dem ein kopierter und nicht anonymisierter oder pseudonymisierter Echtdatenbestand verarbeitet wird. Auch im Bereich der (Fern-)Wartung von Systemen findet die Verarbeitung personenbezogener 1 Bartenbach/Volz, § 24 ArbEG Rz. 15. 2 Bartenbach/Volz, § 24 ArbEG Rz. 36. 3 S. BAG v. 24.6.1986, AP Nr. 4 zu § 611 BGB („Betriebsgeheimnis“); Bartenbach/ Volz, § 24 ArbEG Rz. 44.

494

Gennen

Softwareentwicklung durch Dritte

Rz. 139 E

Daten statt. Die Verpflichtung auf das Datengeheimnis gilt auch über das Ende des Arbeitsverhältnisses hinaus. g) Konkurrenzverbot Wettbewerbsverbote können zum einen während der Dauer des Arbeitsver- 136 hältnisses und zum anderen nach Beendigung des Arbeitsverhältnisses bestehen. Von besonderer Relevanz sind Wettbewerbsverbote im Bereich der Softwareerstellung auch bei bestehendem Arbeitsverhältnis, denn in dieser Branche gibt es nicht wenige Personen mit mehreren parallel laufenden Teilzeitbeschäftigungsverhältnissen. aa) Wettbewerbsverbote während des Arbeitsverhältnisses Eine gesetzliche Konkretisierung des während des Arbeitsverhältnisses be- 137 stehenden Wettbewerbsverbotes findet sich in (dem unmittelbar eigentlich nur für Handlungsgehilfen geltenden) § 60 HGB. Demnach ist dem Arbeitnehmer untersagt, während der Dauer des Arbeitsverhältnisses im Arbeitszweig des Arbeitgebers ein konkurrierendes Handelsgewerbe zu betreiben oder für eigene oder fremde Rechnung konkurrierende Geschäfte zu machen. Unter dem Begriff des Geschäftemachens i.S.d. § 60 HGB versteht man jede, 138 wenn auch nur spekulative, auf Gewinnerzielung gerichtete Teilnahme am geschäftlichen Verkehr, die nicht nur der Befriedigung eigener privater Bedürfnisse des Arbeitnehmers dient1. Hierunter fallen alle Aktivitäten des Arbeitnehmers, die geeignet sind, den Betrieb des Arbeitgebers zu beeinträchtigen, wodurch sich indirekt auch eine gewisse Bagatellgrenze ergibt2. Insbesondere gehören zu den untersagten Handlungen die Unterstützung ehemaliger, vertragsbrüchiger Kollegen bei einer Konkurrenztätigkeit3 oder auch die Abwerbung von vertraglich gebundenen Kollegen4. Nicht erfasst wird allerdings die reine Kapitalbeteiligung an einem Konkurrenzunternehmen, sofern der Arbeitnehmer keinerlei Einflussmöglichkeiten auf die Geschäftstätigkeit dieses Unternehmens hat5. Es empfiehlt sich, diese eben dargestellten Grundsätze auch in einem ver- 139 traglichen Wettbewerbsverbot festzuhalten, um jeglichen Fehlvorstellungen des Arbeitnehmers über die Zulässigkeit von Wettbewerbstätigkeit vorzubeugen. Im Rahmen dieses Wettbewerbsverbotes kann auch eine Vertragsstrafe für den Fall der Zuwiderhandlung vereinbart werden. 1 BAG v. 15.2.1962, AP zu § 61 Nr. 1 HGB. 2 Zu „Freundschaftsdiensten“ im Arbeitsbereich des Arbeitgebers vgl. LAG Schleswig-Holstein v. 3.12.2002, LAGE HGB Nr. 9 zu § 60. 3 BAG v. 16.1.1975, AP Nr. 8 zu § 60 HGB; Reinfeld, in: Münchener Anwaltshandbuch Arbeitsrecht, § 28 Rz. 4. 4 Reinfeld, in: Münchener Anwaltshandbuch Arbeitsrecht, § 30 Rz. 4. 5 Reinfeld, in: Münchener Anwaltshandbuch Arbeitsrecht, § 30 Rz. 6.

Gennen

495

E Rz. 140

Verträge

140

Verstößt der Arbeitnehmer gegen das Wettbewerbsverbot des § 60 HGB, stehen dem Arbeitgeber verschiedene Rechte zu. Zum einen kann er vom Arbeitnehmer Auskunft nach § 242 BGB über dessen vermeintlich wettbewerbswidrige Tätigkeit verlangen1. Daneben bestehen auch Schadensersatzansprüche nach § 61 Abs. 1 HGB, §§ 280, 611, 823, 826 BGB.

141

Dem Arbeitgeber steht nach § 61 Abs. 1 HGB auch das Recht zu, die für eigene Rechnung gemachten Geschäfte des Arbeitnehmers an sich zu ziehen. Demnach muss der Arbeitnehmer bei Geltendmachung des Eintrittsrechts seine erlangte Vergütung herausgeben oder aber entsprechende Vergütungsansprüche an den Arbeitgeber abtreten. Auch kann der Arbeitgeber in alle einzelnen Geschäfte des Arbeitnehmers eintreten, sofern diese in seinem Geschäftszweig liegen und er sie auch in gleichem Umfang gemacht hätte2. Für die Geltendmachung dieser Ansprüche ist allerdings die kurze Verjährungsfrist des § 61 Abs. 2 HGB zu beachten, die im Übrigen auch für Schadensersatzansprüche nach §§ 611, 280, 823 oder 826 BGB gilt.

142

Unerlaubte Wettbewerbstätigkeit des Arbeitnehmers stellt darüber hinaus einen (verhaltensbedingten) Kündigungsgrund dar, der nach Schwere des Verstoßes auch zu einer Kündigung aus wichtigem Grund berechtigen kann, ggf. auch ohne Abmahnung. Vielfach werden Wettbewerbsverbote auch durch Vertragsstrafen abgesichert; eine solche Abrede ist aber nach Ansicht des BAG3 wegen Verstoßes gegen das Transparenzgebot unwirksam, wenn sie für jeden Fall der Zuwiderhandlung gegen das Wettbewerbsverbot eine Vertragsstrafe von zwei Bruttomonatsgehältern vorsieht und zudem bestimmt, dass bei Dauertatbeständen jeder angebrochene Monat als erneute Verletzung anzusehen ist.

143

In der Praxis problematisch sind Fälle, in denen teilzeitbeschäftigte Arbeitnehmer mehrere parallele Arbeitsverhältnisse in derselben Branche innehaben. Bei einem bestehenden Wettbewerbsverbot ist ein auf eine bestimmte Art der Software spezialisierter Programmierer gehindert, für einen Konkurrenten einer seiner Arbeitgeber tätig zu sein. Für ein Unternehmen, das eine für vollkommen andere Zwecke vorgesehene Software herstellt – Reisebuchungssoftware einerseits, Textverarbeitung andererseits – dürfte der Arbeitnehmer wohl tätig sein, nicht aber in derselben Teilbranche.

144

Besteht eine (nicht formbedürftige) Einwilligung des Arbeitgebers, liegt eine unerlaubte Konkurrenztätigkeit nicht vor. Eine Nebentätigkeitsgenehmigung als solche entbindet jedoch nicht von dem Konkurrenzverbot. Erteilt der Arbeitgeber eine Einwilligung, sollte er sich den Widerruf (nach billigem Ermessen, § 315 BGB) vorbehalten.

1 BAG v. 21.10.1970, AP Nr. 13 zu § 242 BGB. 2 BAG v. 15.2.1962, AP Nr. 1 zu § 61 HGB; Reinfeld, in: Münchener Anwaltshandbuch Arbeitsrecht, § 31 Rz. 32. 3 BAG NZA 2008, 170.

496

Gennen

Softwareentwicklung durch Dritte

Rz. 149 E

Im Einzelfall problematisch ist die Abgrenzung zwischen einer während des 145 Arbeitsverhältnisses verbotenen Konkurrenzhandlung und einer erlaubten1 Vorbereitungshandlung. Denn die Folgen einer arbeitnehmerseitigen Fehleinschätzung können weitreichend sein – das noch bestehende Arbeitsverhältnis kann aus wichtigem Grund gekündigt werden, evtl. bereits ausgehandelte Zuwendungen in einem schon bestehenden Aufhebungsvertrag können ersatzlos wegfallen. Anmietung von Räumen, Anwerbung von Mitarbeitern, Abschluss von Ge- 146 sellschaftsverträgen, Anschaffung von Waren, Bewerbungsgespräche bei Konkurrenzunternehmen sind grundsätzlich zulässige Vorbereitungshandlungen. Maßnahmen, die jedoch bereits dazu führen, dass der Arbeitgeber nachteilig betroffen ist, dürften als Konkurrenzmaßnahmen anzusehen sein. In Einzelfällen kann auch der bloße Umstand, dass die Vorbereitungsmaßnahmen nach außen dringen, insbesondere eine Kontaktaufnahme zu Lieferanten oder Kunden des Arbeitgebers erfolgt, eine solche nachteilige Betroffenheit auslösen2. bb) Nachvertragliches Wettbewerbsverbot Ein nachvertragliches Wettbewerbsverbot kann für Arbeitnehmer nach 147 §§ 74 ff. HGB i.V.m. § 110 GewO vereinbart werden; wirksam ist es vorbehaltlich weitergehender Voraussetzungen nur bei Gewährung einer sog. Karenzentschädigung in Höhe von mindestens 50 % der zuletzt bezogenen Vergütung. Typischerweise werden nachvertragliche Wettbewerbsverbote bereits bei Begründung des Arbeitsverhältnisses vereinbart; denkbar ist aber auch der Abschluss der Wettbewerbsabrede erst während des laufenden Arbeitsverhältnisses oder aus Anlass der Beendigung bzw. „im Zusammenhang mit dem Arbeitsverhältnis und seiner Abwicklung“3. Wird ein Wettbewerbsverbot erst nach dem rechtlichen Ende des Arbeitsverhältnisses vereinbart, wird man eher von einer entschädigungslos möglichen Wettbewerbsabrede ausgehen können. Für arbeitnehmerähnliche freie Mitarbeiter, die mit einer Arbeitszeit von 148 40 Wochenstunden Dienstleistungen bei Dritten erbringen (oder nur für ein einziges Unternehmen tätig sind4), gilt § 74 HGB entsprechend5. Das nachvertragliche Wettbewerbsverbot ist von der nachvertraglichen Geheimhaltungsverpflichtung des Arbeitnehmers abzugrenzen, siehe oben Rz. 128. Die Wettbewerbsabrede bedarf der Schriftform und der Aushändigung der Urkunde an den Arbeitnehmer. Vielfach üblich war die Einbindung der 1 Vgl. schon BAG v. 30.5.1978, AP HGB Nr. 9 zu § 60. 2 Vgl. LAG Köln v. 19.1.1996, LAGE BGB Nr. 93 zu § 626. 3 Vgl. BAG v. 3.4.1994, AP HGB Nr. 65 zu § 74; insoweit ist umstritten, ob § 74 ff. HGB Anwendung finden oder ob – so verschiedene Stimmen in der Literatur – dann eine entschädigungslose Vereinbarung möglich ist. 4 OLG München v. 18.10.1996 – 21 U 3748/96, BB 1997, 224. 5 LAG Köln v. 2.6.1999, NZA 2000, 65.

Gennen

497

149

E Rz. 150

Verträge

Wettbewerbsabrede in den (Formular-)Arbeitsvertrag selbst; das wird man in Zeiten der AGB-Kontrolle im Arbeitsverhältnis (vgl. § 310 Abs. 4 Satz 2 BGB) wohl eher ändern. 150

Nach § 74a Abs. 1 Satz 3 HGB kann ein nachvertragliches Wettbewerbsverbot nur für die Dauer von maximal zwei Jahren nach dem rechtlichen Ende des Arbeitsverhältnisses vereinbart werden. Im Übrigen ist das Wettbewerbsverbot nur soweit verbindlich, wie es von einem berechtigten Interesse des Arbeitgebers gedeckt ist (§ 74a Abs. 1 Satz 1 HGB) und nicht zu einer unbilligen Fortkommenserschwerung des Arbeitnehmers führt (§ 74a Abs. 1 Satz 2 HGB). Das Interesse des Arbeitgebers am Wettbewerbsverbot dürfte mit steigender Qualifikation des Arbeitnehmers bzw. mit der hierarchischen Position des Arbeitnehmers im Unternehmen steigen – je qualifizierter und höherrangiger ein Arbeitnehmer ist (z.B. leitender Angestellter), umso eher wird er, bei der Konkurrenz beschäftigt, aufgrund seiner Kenntnisse dem Arbeitgeber schaden können, so dass insoweit ein Wettbewerbsverbot auch wirksam sein kann, das über den unmittelbaren Arbeitsbereich des Arbeitnehmers hinaus geht. Geht die Wettbewerbsklausel über die berechtigten Belange des Arbeitgebers hinaus, ist sie nicht insgesamt unwirksam, sondern wird im Wege der geltungserhaltenden Reduktion entsprechend zurückgeführt. Ferner darf ein Wettbewerbsverbot das berufliche Fortkommen des Arbeitnehmers nicht unbillig erschweren, so dass im konkreten Fall stets über die zweijährige Maximalfrist, über den räumlichen und den gegenständlichen Verbotsumfang nachgedacht werden muss. Denkbar ist, bei „schnelllebigen“ Branchen wie bspw. der Softwarebranche unter Umständen ein kürzeres Wettbewerbsverbot zu vereinbaren. Aber auch hier gilt, dass ein – z.B. räumlich – zu weit reichendes Wettbewerbsverbot nicht insgesamt unwirksam ist, sondern geltungserhaltend ausgelegt wird, mit der Folge, dass eine Konkurrenzhandlung in einem räumlichen Gebiet erlaubt sein kann, von dem das Gericht feststellt, dass es gar kein Vertriebsgebiet des Arbeitgebers ist. In Zeiten, in denen Software über das Internet weltweit (zumindest bundesweit) vertrieben wird, dürften allerdings solche räumlichen Beschränkungen zunehmend geringere Bedeutung haben.

151

Wird für die Laufzeit der Wettbewerbsabrede keine Karenzentschädigung vereinbart, ist das Wettbewerbsverbot nichtig. Erreicht die vereinbarte Karenzentschädigung nicht 50 % der zuletzt bezogenen vertragsmäßigen Leistungen, steht dem Arbeitnehmer ein Wahlrecht zu: Er kann entweder das Wettbewerbsverbot ignorieren oder aber unter Beachtung desselben die vereinbarte Entschädigung erhalten. Eine Aufstockung der Entschädigung auf den gesetzlichen Mindestumfang des § 74 Abs. 2 HGB findet jedoch nicht statt1.

152

Die (unbedingte) Vereinbarung einer Karenzentschädigung sollte mit einer Auskunftsverpflichtung des Arbeitnehmers über die Höhe seiner zukünftigen Bezüge verbunden werden (§ 74c Abs. 2 HGB), da eine Anrechnung an1 BAG v. 9.1.1990 – 3 AZR 110/88, MDR 1990, 853 = NZA 1990, 519 ff.

498

Gennen

Softwareentwicklung durch Dritte

Rz. 156 E

derweitiger Verdienste auf die Karenzentschädigung erfolgt, § 74c Abs. 1 HGB. Ebenso sollte aus Arbeitgebersicht in dem Wettbewerbsverbot eine Ver- 153 tragsstrafe für den Fall des Zuwiderhandelns vorgesehen werden. Die Rechtsprechung akzeptiert im Allgemeinen eine Vertragsstrafenhöhe von einer monatlichen Karenzentschädigung pro Verstoß. Bei einem Dauerverstoß, d.h. einer länger als einen Monat andauernden wettbewerbswidrigen Tätigkeit des Arbeitnehmers, entfällt die Karenzzahlungspflicht ganz, so lange der Verstoß anhält. Daneben sollte vereinbart werden, dass dem Arbeitgeber die Geltendmachung eines darüber hinausgehenden Schadens unbenommen bleibt. Vor der vertraglichen Vereinbarung eines nachvertraglichen Wettbewerbs- 154 verbotes sollte sich der Arbeitgeber über die dadurch entstehenden Kosten der Karenzentschädigung Gedanken machen. Aus diesem Grund sollte ein Wettbewerbsverbot nur für Arbeitnehmer vereinbart werden, die eine sehr spezialisierte Aufgabe im Betrieb des Arbeitgebers besaßen und deren Tätigkeit bei der Konkurrenz zu einer grundlegenden Entwertung des Unternehmens des Arbeitgebers führen würde. Ein nach § 75a HGB möglicher einseitiger Verzicht des Arbeitgebers auf ein einmal vereinbartes Wettbewerbsverbot kann diesen vor Auszahlung der Karenzentschädigung nur nach Ablauf eines Jahres schützen. Verstößt der Arbeitgeber gegen seine Karenzzahlungspflicht, kann der Ar- 155 beitnehmer Zahlungsklage erheben. Da die Karenzentschädigung nach § 74b Abs. 1 HGB immer monatlich zum Ende eines Monats hin fällig wird, gerät der Arbeitgeber nach § 286 Abs. 2 BGB bei Nichtzahlung automatisch in Verzug, ohne dass es einer Mahnung durch den Arbeitnehmer bedurfte. Demnach kann der Arbeitnehmer nach § 288 Abs. 4 BGB neben weiteren Verzugsschäden auch Verzugszinsen verlangen. Der Arbeitnehmer kann auch nach § 323 Abs. 1 BGB eine Nachfrist zur Zahlung der ausstehenden Karenzentschädigung setzen. Lässt der Arbeitgeber diese ungenutzt verstreichen, kann der Arbeitnehmer von dem Wettbewerbsverbot zurücktreten und zusätzlichen Schadensersatz verlangen, §§ 323 Abs. 1, 325 BGB. Daneben ist – zumindest bei nachhaltigem Pflichtverstoß des Arbeitgebers und einer Abmahnung durch den Arbeitnehmer – eine Kündigung des Wettbewerbsverbotes möglich, stellt dieses doch ein Dauerschuldverhältnis nach § 314 BGB dar. Verstößt der Arbeitnehmer gegen das vereinbarte Wettbewerbsverbot, wird 156 der Arbeitgeber nicht nur von der Zahlung der Karenzentschädigung für die Dauer des Verstoßes befreit1. Er kann darüber hinaus bei Verschulden des Arbeitnehmers Schadensersatz verlangen, der sich nach den §§ 249 ff. BGB auf den Ausgleich jedes Nachteils bezieht, den der Arbeitnehmer in Folge des Wettbewerbsverstoßes erlitten hat. Im Gegensatz zu sonstigen Pflicht1 BAG v. 5.8.1968, AP Nr. 29 zu § 74 HGB.

Gennen

499

E Rz. 157

Verträge

verletzungen findet hier § 619a BGB keine Anwendung, so dass der Arbeitgeber von der Beweislast für das „Vertretenmüssen“ des Arbeitnehmers befreit wird. Hat der Arbeitnehmer im Zeitpunkt des Verstoßes weiterhin ein berechtigtes Interesse an der Aufrechterhaltung des Wettbewerbsverbotes, kann er auch einen Unterlassungsanspruch entsprechend § 1004 BGB geltend machen. Dem Arbeitgeber steht unter den gleichen Voraussetzungen wie dem Arbeitnehmer ein Kündigungsrecht zu. 157

Von dem Bestehen eines nachvertraglichen Wettbewerbsverbots schon aufgrund bloßer arbeitsvertraglicher Treuepflichten kann nicht ausgegangen werden. Eine Grenze findet sich lediglich bei Überschreitung der §§ 17, 18 UWG, §§ 823 und 826 BGB.

157a Zu unterscheiden von einem Wettbewerbsverbot sind Abreden, die indirekt die Wirkung eines solchen Wettbewerbsverbots entfalten oder dem nahe kommen. So sind Kundenschutzabreden in der Softwareerstellungsbranche üblich. Damit versucht der Arbeitgeber, seinen Arbeitnehmern oder den von ihm beschäftigten arbeitnehmerähnlichen Personen zu untersagen, für einen bestimmten Zeitraum nach dem Ende eines Projekts für den Auftraggeber unmittelbar tätig zu sein. Eine solche unmittelbare Tätigkeit ist für den Kunden/Auftraggeber preiswerter, spart er doch die Marge, die der Arbeitgeber/Auftraggeber des Programmierers einzustreichen gedenkt. Solche Regelungen unterfallen unmittelbar den §§ 74 ff. HGB. Anders kann das bei Kundenübernahmeklauseln sein, bei denen sich der Arbeitgeber für den Fall, dass der Mitarbeiter einen Kunden übernimmt, für einen bestimmten Zeitraum einen bestimmten Anteil des mit dem Kunden erwirkten Umsatzes als Entschädigung zahlen lässt1. Solche Regelungen können wirksam sein, sie sind jedoch insbesondere dann kritisch, wenn die Laufzeit zwei Jahre (wesentlich) überschreitet2. 2. Leistungsstörungen im Arbeitsverhältnis 158

Leistungsstörungen – Nicht- und Schlechtleistung – im Arbeitsverhältnis werden grundsätzlich nach den allgemeinen Regeln über Leistungsstörungen im allgemeinen Schuldrecht behandelt. Modifikationen finden sich im Rahmen der Haftung des Arbeitnehmers, die auf seine besondere wirtschaftliche und soziale Abhängigkeit von dem Arbeitgeber zurückzuführen sind. a) Leistungsstörungen auf Seiten des Arbeitnehmers aa) „Nichtleistung“

159

Die „Nichtleistung“ des Arbeitnehmers führt i.d.R. unmittelbar zur Unmöglichkeit, da es sich bei der Arbeitsverpflichtung um eine absolute Fixschuld handelt. Der Arbeitnehmer hat seine Leistung zu einer bestimmten 1 Vgl. BAG v. 7.8.2002, EzA HGB § 74 Nr. 62. 2 S.a. BGH BB 1990, 11 f.

500

Gennen

Softwareentwicklung durch Dritte

Rz. 163 E

(Arbeits-)Zeit zu erbringen; erbringt der in Vollzeit tätige Arbeitnehmer die Tätigkeit nicht oder auch nur verspätet, ist eine Nachholung nicht möglich (anders ggf. bei Teilzeittätigkeit, dann ggf. relative Fixschuld). Ist die Unmöglichkeit auf von außen auf den Betrieb des Arbeitgebers ein- 160 wirkende Umstände (wie etwa den Ausfall des kompletten Datenverarbeitungssystems auf Grund Stromausfalls) zurückzuführen, fallen diese also in das Betriebsrisiko des Arbeitgebers1, oder trägt der Arbeitgeber gar das Verschulden an den die Unmöglichkeit begründenden Umständen, behält der Arbeitnehmer seinen Anspruch auf Arbeitslohn. Er selbst wird aber von der Erbringung der Arbeitsleistung frei, § 275 Abs. 1 BGB. Hat der Arbeitnehmer die Unmöglichkeit seiner Arbeitsleistung zu vertre- 161 ten2, stehen dem Arbeitgeber verschiedene Handlungsmöglichkeiten zur Verfügung. Er kann zum einen Klage auf Arbeitsleistung erheben, wobei jedoch i.d.R. bei einem Softwareentwickler eine unvertretbare, da höher qualifizierte Arbeitsleistung vorliegen wird, so dass eine Vollstreckung des Urteils an § 888 Abs. 3 ZPO scheitert. Der Arbeitnehmer verliert des Weiteren bei einer durch ihn zu vertretenden Unmöglichkeit seinen Lohnanspruch nach §§ 611, 275 Abs. 4, 326 Abs. 1 BGB, bzw. §§ 611, 275 Abs. 4, 326 Abs. 1 Satz 1 i.V.m. § 441 Abs. 3 BGB. Daneben kann er sich auch nach §§ 611, 275 Abs. 4, 280 Abs. 1, 283 BGB schadensersatzpflichtig machen3. Die Beweiserleichterung des § 619a BGB greift hier nicht ein, so dass der Arbeitnehmer sein Nichtverschulden zu beweisen hat. Der Umfang des Schadensersatzanspruches des Arbeitgebers gegen seinen Arbeitnehmer richtet sich nach den §§ 249 ff. BGB und kann bspw. entgangenen Gewinn, Mehrvergütungen, Kosten für Anwerbung einer Ersatzkraft und Entgeltdifferenzen umfassen. Abweichend von dem Grundsatz, dass es Entgelt nur für geleistete Arbeit 162 gibt, sehen verschiedene Normen eine Lohnzahlungspflicht des Arbeitgebers auch bei Nichtleistung vor. Das betrifft u.a. die Entgeltfortzahlung im Krankheitsfall (§ 3 EFZG) und an Feiertagen (§ 2 EFZG), Freistellungen nach dem BetrVG, dem MuSchG, dem BUrlG und den Bildungsurlaubsgesetzen der Länder. bb) Erfolgsunabhängigkeit Der Arbeitnehmer schuldet dem Arbeitgeber grundsätzlich nur die Erbrin- 163 gung seiner Arbeitsleistung, keinen Erfolg. Im Bereich der Softwareentwick1 Zum Betriebsrisiko des Arbeitgebers s. exemplarisch BAG v. 9.3.1983, AP Nr. 31 zu § 615 BGB Betriebsrisiko; BAG v. 28.9.1972, AP Nr. 28 zu § 615 BGB Betriebsrisiko; BAG v. 30.1.1991, AP Nr. 33 zu § 615 BGB Betriebsrisiko. 2 D.h. es liegt ein von ihm zu vertretendes Verschulden vor und das Risiko der Unmöglichkeit wurde nicht – wie bspw. bei Schwangerschaft der Arbeitnehmerin – durch ein Spezialgesetz auf den Arbeitgeber verlagert. 3 Für die anfängliche, d.h. bereits bei Abschluss des Arbeitsvertrages vorliegende Unmöglichkeit bildet § 311a BGB eine eigene Anspruchsgrundlage.

Gennen

501

E Rz. 164

Verträge

lung bedeutet dies, dass der angestellte Entwickler nur das Bemühen um Erreichen der von dem Arbeitgeber vorgegebenen Aufgaben schuldet, nicht jedoch einen bestimmten Erfolg in Form einer bestimmten, funktionsfähigen oder gar mangelfreien Software. 164

Dennoch kann auch den schuldhaft – mindestens fahrlässig – mangelhaft arbeitenden Arbeitnehmer eine Haftung wegen Schlechtleistung treffen. Eine solche Schlechtleistung liegt vor, wenn der Arbeitnehmer aus von ihm zu vertretenden Gründen flüchtig oder ungenau arbeitet und auf diese Weise z.B. fehlerhafte Software erstellt. Bei der Verletzung von Nebenpflichten kommt insbesondere die Beschädigung von dem Arbeitnehmer im Rahmen seiner Tätigkeit überlassenen Gerätschaften, wie Computern, Software etc. in Betracht.

165

Der Arbeitgeber kann auf verschiedene Weise gegen den (fahrlässig) schlecht arbeitenden Softwareentwickler vorgehen: – Er kann z.B. einen Teil der Vergütung einbehalten, indem er mit einem ihm gegen den Arbeitnehmer zustehenden Schadensersatzanspruch aufrechnet, §§ 387 ff. BGB. – Ein solcher Schadensersatzanspruch kann sich aus §§ 611, 280 Abs. 1 BGB bei Verletzung der Pflicht zur ordnungsgemäßen Erbringung der Arbeitsleistung und §§ 611, 280 Abs. 1, 282, 241 Abs. 2 BGB bei Verletzung einer Nebenpflicht ergeben. Die vom Arbeitgeber nachzuweisende Pflichtverletzung muss den Schaden kausal verursacht haben. Nach der Rechtsprechung des BAG findet insoweit jedoch eine Haftungserleichterung zugunsten des Arbeitnehmers statt1. Demnach haftet der Arbeitnehmer bei leichter bzw. leichtester2 Fahrlässigkeit gar nicht, bei „normaler“3 oder mittlerer Fahrlässigkeit anteilig und bei grober4 Fahrlässigkeit oder Vorsatz voll. Diese Haftungsaufteilung wird von der Rechtsprechung allerdings durch das Heranziehen weiterer Umstände, wie etwa der Höhe der Vergütung (in der eine Art Risikoprämie enthalten sein kann), der Position des Arbeitnehmers innerhalb des Betriebes, der Gefahrgeneigtheit seiner Tätigkeit, der Höhe des Schadens, ein vom Arbeitgeber einkalkulierbares oder versicherbares Risiko ggf. auch den persönlichen Umständen des Arbeitnehmers wie die Dauer der Betriebszugehörigkeit etc. modifiziert. So ist es bspw. möglich, dass auch der grob fahrlässig handelnde Programmierer nur anteilig haftet, wenn er mit einem seine Fähigkeiten eigentlich 1 BAG GS v. 25.9.1957, AP Nr. 4 zu §§ 898, 899 RVO; BAG GS v. 27.9.1994, AP Nr. 103 zu § 611 BGB Haftung des Arbeitnehmers. 2 Leichte Fahrlässigkeit liegt bei „typischem Abirren“ der Arbeitsleistung, wie etwa Verschreiben vor. 3 Der Begriff der „normalen“ Fahrlässigkeit bestimmt sich nach § 276 Abs. 1 BGB. 4 Grobe Fahrlässigkeit ist die Außerachtlassung der im Verkehr gebotenen Sorgfalt in einem so hohen Maße, dass jedem besonnenen Durchschnittsmenschen sich die Schwere des Pflichtverstoßes sofort erschließt.

502

Gennen

Softwareentwicklung durch Dritte

Rz. 168 E

übersteigenden Projekt betraut wurde und einen im Verhältnis zu seiner Vergütung ungleich höheren Schaden verursacht hat. Wird allerdings durch den Arbeitnehmer ein mit dem Arbeitgeber vertraglich verbundener Dritter (Kunde) bzw. dessen Eigentum geschädigt, haften Arbeitgeber und Arbeitnehmer ggf. nebeneinander (§§ 276, 278, 823 ff., 831 BGB). Ist der Schaden im Rahmen einer betrieblich veranlassten Tätigkeit entstanden, hat der Arbeitnehmer im Innenverhältnis zu seinem Arbeitgeber einen Freistellungsanspruch im Rahmen der oben aufgezeigten Haftungserleichterung. Der Dritte kann auch direkt gegen den Arbeitgeber vorgehen, indem er sich den Freistellungsanspruch des Arbeitnehmers gegen seine Arbeitgeber nach §§ 829 Abs. 2 und 3, 835 Abs. 3 ZPO pfänden und überweisen lässt1. Die Haftung für Personenschäden bei Dritten (§§ 104 bis 113 SGB VII) dürfte im Bereich der Softwareentwicklung nicht virulent werden. – Nicht zuletzt kann eine schwerwiegende oder dauerhafte Schlechtleistung des Arbeitnehmers früher oder später zur Kündigung führen2, je nach Sachlage als verhaltens- oder personenbedingte Kündigung. b) Leistungsstörungen auf Seiten des Arbeitgebers aa) Verzögerte Entgeltzahlung Als vom Arbeitgeber zu vertretende Leistungsstörung kommt zunächst das verzögerte Auszahlen des Entgelts in Betracht. Normalerweise finden sich in Arbeitsverträgen Bestimmungen über den Fälligkeitszeitpunkt der Vergütung; im Übrigen ist das Entgelt nach § 614 BGB zum Ende des Vergütungszeitraumes zu zahlen. Nach § 288 BGB ist das Entgelt mit 5 Prozentpunkten über dem jeweiligen Basiszinssatz zu verzinsen.

166

Kommt der Arbeitgeber mit der Zahlung in Verzug, bedarf es wegen des fi- 167 xierten Fälligkeitszeitpunkts keiner Mahnung des Arbeitnehmers um den Verzug zu begründen (§ 286 Abs. 2 Nr. 1 BGB). Nach § 280 BGB hat der Arbeitgeber für alle durch den Verzug entstandenen Schäden des Arbeitnehmers grundsätzlich einzustehen. Insoweit ergibt sich die Besonderheit, dass dies aufgrund entsprechender Anwendung von § 12a ArbGG nicht für die Kosten einer vorprozessualen anwaltlichen Vertretung gilt; hier muss der Arbeitnehmer die Anwaltskosten selber tragen. Kommt der Arbeitgeber für einen längeren Zeitraum (wohl mindestens zwei 168 Monate3) in Verzug, kann der Arbeitnehmer nach vorheriger Ankündigung ein Zurückbehaltungsrecht an seiner Arbeitsleistung ausüben, d.h. die Arbeit einstellen. Der Arbeitgeber ist allerdings weiterhin zur Zahlung des Lohns verpflichtet. Auch wenn dem Arbeitgeber nachträglich der gesamte Lohn 1 BAG v. 11.2.1969, AP Nr. 45 zu § 611 BGB Haftung des Arbeitnehmers. 2 Generell BAG v. 28.9.1961, DB 1961, 1651 ff. 3 Vgl. BAG v. 25.10.1984, AP Nr. 3 zu § 273 BGB.

Gennen

503

E Rz. 169

Verträge

ausgezahlt wird, muss er die während des Bestehens seines Zurückbehaltungsrechts eingestellte Arbeitsleistung nicht nachholen. 169

Ein erheblicher Zahlungsrückstand des Arbeitgebers kann den Arbeitnehmer darüber hinaus zur Kündigung aus wichtigem Grund berechtigen1. Der Arbeitgeber hat in diesem Fall dem Arbeitnehmer den durch die fristlose Kündigung entstehenden Lohnausfall bis zum Ablauf der ordentlichen Kündigungsfrist zu ersetzen. bb) Annahmeverzug des Arbeitgebers

170

Der Arbeitgeber kann hierneben auch in Annahmeverzug geraten, wenn er das Arbeitsangebot des Arbeitnehmers nicht annimmt, §§ 611, 293 ff. BGB. Nach § 615 BGB ist er allerdings weiterhin zur Zahlung des Arbeitslohnes verpflichtet, ohne dass eine korrespondierende Nacharbeitungsverpflichtung des Arbeitnehmers für den Verzugszeitraum besteht. Ein konkretes Arbeitsangebot des Arbeitnehmers kann dann unterbleiben, wenn der Arbeitgeber deutlich zu verstehen gegeben hat, dass er an der Arbeitsleistung des Arbeitnehmers kein Interesse hat (bspw. bei einer ausgesprochenen Kündigung). Erzielt der Arbeitnehmer allerdings während der Zeit des Annahmeverzugs des Arbeitgebers andere Einkünfte, muss er sich diese auf seinen Lohnanspruch anrechnen lassen, § 615 Satz 2 BGB.

171, 172

Einstweilen frei.

3. Beendigung des Arbeitsverhältnisses (Individualarbeitsrecht) 173

Arbeitsverhältnisse als Dauerschuldverhältnisse lassen sich auf verschiedene Weise beenden, jedoch ist eine Beendigung i.d.R. nur für die Zukunft möglich und ein Rücktritt insoweit aus rechtlichen Gründen ausgeschlossen. In Betracht kommen als Beendigungstatbestände vor allem eine Befristung/ Zweckbefristung/Bedingung (vgl. hierzu das TzBfG, das § 620 BGB näher ausgestaltet hat), eine Kündigung (außerordentlich/aus wichtigem Grund bzw. ordentlich) und die einvernehmliche Beendigung in Form des Aufhebungsvertrags. Andere Beendigungstatbestände wie z.B. Anfechtung des Arbeitsvertrages sind in der Praxis von untergeordneter Bedeutung. a) Befristung

174

Ein befristetes Arbeitsverhältnis ist ein Arbeitsverhältnis, das für eine bestimmte Zeit eingegangen wird; eine Befristung kann zum einen durch Vorgabe des Endzeitpunktes („befristeter Arbeitsvertrag“), zum anderen durch Zweckvorgabe (bspw. Schwangerschaftsvertretung, Projektabwicklung, sog. 1 Vgl. BAG v. 26.7.2001, AP Nr. 13 zu § 628 BGB, wonach schon ein geringer Lohnrückstand zu einem außerordentlichen Kündigungsrecht des Arbeitnehmers führen kann, wenn der Arbeitgeber die Lohnauszahlung ohne nachvollziehbare Begründung verweigert.

504

Gennen

Softwareentwicklung durch Dritte

Rz. 176 E

„zweckbefristeter Arbeitsvertrag“) erfolgen, vgl. § 3 Abs. 1 TzBfG. Das Arbeitsverhältnis endet in einem solchen Fall, ohne dass es einer weiteren Erklärung einer Partei bedarf, mit dem vereinbarten Endzeitpunkt bzw. mit Zweckerreichung bzw. mit Ablauf von zwei Wochen ab der Mitteilung des Arbeitgebers an den Arbeitnehmer über den Umstand der Zweckerreichung, § 15 TzBfG. Wird das Arbeitsverhältnis nach Ablauf der Zeit oder nach Erreichung des Zwecks mit Wissen des Arbeitgebers fortgesetzt, so gilt es als auf unbestimmte Zeit verlängert, wenn der Arbeitgeber nicht unverzüglich widerspricht oder dem Arbeitnehmer die Zweckerreichung nicht unverzüglich mitteilt, vgl. § 15 Abs. 5 TzBfG. Nach § 14 Abs. 2 TzBfG kann der Arbeitgeber ein Arbeitsverhältnis ohne 175 das Vorliegen eines sachlichen Grundes auf bis zu (insgesamt) zwei Jahre kalendermäßig befristen1 (nicht jedoch zweckbefristen), sofern mit dem Arbeitnehmer zuvor kein Arbeitsverhältnis bestand. In den ersten vier Jahren nach einer Unternehmensneugründung (außerhalb reiner Konzernumstrukturierungen) ist eine solche kalendermäßige Befristung für bis zu vier Jahre zulässig2 (§ 14 Abs. 2a TzBfG). Bei einem Arbeitnehmer, der das 52. Lebensjahr bei Beginn der Befristung vollendet hat und unmittelbar vor Beginn des befristeten Arbeitsverhältnisses mindestens vier Monate beschäftigungslos im Sinne des § 138 Abs. 1 Nr. 1 SGB III gewesen ist, Transferkurzarbeitergeld bezogen oder an einer öffentlich geförderten Beschäftigungsmaßnahme nach dem SGB II oder III teilgenommen hat, ist eine Befristung bis zu fünf Jahren möglich, vgl. § 14 Abs. 3 TzBfG. Soll eine über den oben angegebenen Zeitraum hinaus gehende Befristung 176 vereinbart werden oder ist zwar der Eintritt des Befristungsgrundes sicher, nicht aber der Zeitpunkt (Zweckbefristung), muss der Arbeitgeber einen der in § 14 Abs. 1 Nrn. 1–8 TzBfG aufgezählten sachlichen Gründe oder einen vergleichbaren sachlichen Grund nachweisen können: 1. der betriebliche Bedarf an der Arbeitsleistung besteht nur vorübergehend, 2. die Befristung erfolgt im Anschluss an eine Ausbildung oder ein Studium, um den Übergang des Arbeitnehmers in eine Anschlussbeschäftigung zu erleichtern, 3. der Arbeitnehmer wird zur Vertretung eines anderen Arbeitnehmers beschäftigt, 4. die Eigenart der Arbeitsleistung rechtfertigt die Befristung, 5. die Befristung erfolgt zur Erprobung, 6. in der Person des Arbeitnehmers liegende Gründe rechtfertigen die Befristung,

1 Oder bis zu insgesamt vier, für sich jeweils kürzere befristete Arbeitsverhältnisse mit insgesamt der Dauer von nicht mehr als zwei Jahren hintereinander schalten. 2 Bzw. die mehrfache Hintereinanderschaltung befristeter Verträge für einen insgesamt vier Jahre nicht überschreitenden Zeitraum.

Gennen

505

E Rz. 177

Verträge

7. der Arbeitnehmer wird aus Haushaltsmitteln vergütet, die haushaltsrechtlich für eine befristete Beschäftigung bestimmt sind, und er entsprechend beschäftigt wird oder 8. die Befristung beruht auf einem gerichtlichen Vergleich. 177

Im Rahmen von Softwareentwicklungsprojekten dürften insbesondere die Gründe mit den Nrn. 1, 3 und 4 eine Rolle spielen. Die Aufzählung in § 14 Abs. 1 TzBfG ist nicht abschließend, so dass auch weitere, von der Rechtsprechung anerkannte sachliche Gründe eine Befristung rechtfertigen können. Erfolgt eine unwirksame Befristung des Arbeitsvertrages, gilt dieser nach § 16 TzBfG als auf unbestimmte Zeit geschlossen. Unter bestimmten Kautelen kann das Arbeitsverhältnis auflösend bedingt sein (§ 21 TzBfG). Bei der Vereinbarung einer Befristung ist das Schriftformerfordernis des § 14 Abs. 4 TzBfG zu beachten. b) Beendigung durch Kündigung

178

Die Kündigung ist eine einseitige, empfangsbedürftige, rechtsgestaltende Willenserklärung. Eine wirksame Kündigung beendet das Arbeitsverhältnis daher auch gegen den Willen des Erklärungsempfängers. Als einseitige Willenserklärung muss die Kündigung dem anderen Vertragsteil wirksam zugegangen sein; die Beweislast für den Zugang trägt der Kündigende. Regelmäßig ist die Übermittlung von Hand zu Hand durch einen als Zeugen für Erklärungsinhalt und Übermittlung taugenden Boten die beste Zugangsform. Nach § 623 BGB bedarf jede Kündigungserklärung der Schriftform (§ 126 BGB). Eine „Rücknahme“ der Kündigung kommt nicht in Betracht; ist sie einmal zugegangen, kann sie nur einvernehmlich beseitigt werden. Nimmt der Arbeitgeber die Kündigung „einseitig zurück“, ist das nicht mehr als ein Angebot auf Fortsetzung des Arbeitsverhältnisses, das der Annahme bedarf.

179

Durch eine ordentliche Kündigung wird das Arbeitsverhältnis mit dem Ablauf der Kündigungsfrist beendet. Die Berechnung der Frist ergibt sich zunächst aus der Grundregel des § 622 BGB, wonach die Kündigungsfrist in den ersten beiden Jahren des Arbeitsverhältnisses vier Wochen zum 15. des Monats bzw. zum Monatsende beträgt. Mit länger andauerndem Arbeitsverhältnis und abhängig vom Lebensalter des Arbeitnehmers verlängert sich die arbeitgeberseitige Kündigungsfrist; die gesetzliche Maximalfrist bei 20 Jahren Betriebszugehörigkeit und 45 Jahren Lebensalter beträgt sieben Monate zum Monatsende. Denkbar ist eine Vereinbarung, wonach diese verlängerten arbeitgeberseitigen Fristen auch für die arbeitnehmerseitige Kündigung gelten (§ 622 Abs. 6 BGB). Vielfach werden tarifvertraglich oder arbeitsvertraglich abweichende längere Kündigungsfristen für die arbeitgeberseitige Kündigung vereinbart; eine Verkürzung der Fristen ist hingegen nur in wenigen gesetzlich geregelten Ausnahmefällen möglich (§ 622 Abs. 4 und 5 BGB). Für die Softwarebranche mit ihren vielen kleineren Unterneh506

Gennen

Softwareentwicklung durch Dritte

Rz. 181 E

men ist insoweit ggf. die Kleinbetriebsklausel in § 622 Abs. 5 Satz 1 Nr. 2 BGB interessant. Hiernach kann in Kleinbetrieben mit i.d.R. nicht mehr als 20 Arbeitnehmern die Kündigungsfrist auch für länger Beschäftigte auf (nicht unter) vier Wochen abgekürzt werden. Die Wirksamkeit einer ordentlichen Kündigung unterliegt – auch außerhalb 180 des nachstehend angesprochenen KSchG – gewissen Grenzen. Zunächst können gesetzliche Kündigungsverbote oder -erschwernisse bestehen (Sonderkündigungsschutz), z.B. bei schwangeren Arbeitnehmerinnen (§ 9 KSchG), betrieblichen Funktionsträgern der Interessenvertretung (§ 15 KSchG), Schwerbehinderten (§ 85 SGB IX), Arbeitnehmern in der Elternzeit (§ 18 BErzGG), Auszubildenden (§ 15 BBiG), langjährig Beschäftigten aufgrund tarifvertraglicher Regelung oder beim Betriebsübergang (§ 613a BGB). Hierneben können besondere oder allgemeine Diskriminierungs- bzw. Benachteiligungsverbote greifen (vgl. §§ 611a, 612a BGB) oder es sind auch vertragliche Kündigungsausschlüsse denkbar. Eine denkbar allgemeine privatrechtliche Grenze stellt schließlich die Sittenwidrigkeitsgrenze dar (§ 138 BGB); in Kleinbetrieben ist ein Verstoß gegen § 242 BGB denkbar1. Unterliegt der Arbeitnehmer2 dem KSchG, besteht allgemeiner Kündi- 181 gungsschutz und daher bedarf die Kündigung der sozialen Rechtfertigung, deren Vorliegen gerichtlich überprüfbar ist. Eine solche Rechtfertigung ist nur gegeben, wenn der Arbeitgeber – dringende betriebliche Erfordernisse oder Gründe, die – entweder in der Person – oder dem Verhalten des Arbeitnehmers liegen, geltend machen und im Streitfall gerichtsfest beweisen kann3. Weitere Gründe für eine mögliche Sozialwidrigkeit ergeben sich aus § 2 Abs. 2 Satz 2 und 3 KSchG4. Mischtatbestände, bei denen ein und derselbe Sachverhalt mehrere Gründe berührt, sowie das gleichzeitige Vorliegen mehrerer Kündigungsgründe, sind denkbar. 1 Vgl. z.B. BAG v. 6.2.2003, AP KSchG 1969 § 23 Nr. 30. 2 Zur eingeschränkten Anwendung ggü. Geschäftsführern, Betriebsleitern und ähnlichen leitenden Angestellten, die zur selbständigen Einstellung und Entlassung von Arbeitnehmern berechtigt sind, vgl. § 14 Abs. 2 KSchG. Zur Nichtanwendung auf Organmitglieder u.a. vgl. § 14 Abs. 1 KSchG. 3 Vgl. § 2 Abs. 2 Satz 4 KSchG. Dabei gilt der Grundsatz der abgestuften Beweislast; wie viel der Arbeitgeber im Einzelnen vorzutragen hat, richtet sich auch danach, wie detailliert der Arbeitnehmer zu den zunächst substanziiert vom Arbeitgeber vorzutragenden kündigungsbegründenden Tatsachen vorträgt. 4 Für Betriebe des privaten Rechts gem. Satz 2 Ziff. 1: Verstoß der Kündigung gegen eine Richtlinie nach § 95 BetrVG oder Möglichkeit der Weiterbeschäftigung in einem anderen Betrieb, jeweils, soweit der Betriebsrat der Kündigung nach § 102 BetrVG aus einem dieser beiden Gründe widersprochen hat. Satz 3 behandelt die Weiterbeschäftigungsmöglichkeit nach zumutbaren Umschulungs- und Fortbildungsmaßnahmen und den Vorrang der einvernehmlichen (verschlechternden) Änderung von Arbeitsbedingungen vor der Beendigungskündigung.

Gennen

507

E Rz. 182

Verträge

182

Das KSchG ist anwendbar, wenn der Betrieb i.d.R. mehr als zehn Arbeitnehmer, ausschließlich der Auszubildenden, beschäftigt und wenn das Arbeitsverhältnis im Zeitpunkt des Zugangs der Kündigung in demselben Betrieb bzw. Unternehmen mindestens sechs Monate bestanden hat.

183

Im KSchG gilt der Verhältnismäßigkeitsgrundsatz; die Kündigung muss die ultima ratio zur Behebung des Problems sein. Daher hat z.B. auch die Änderungskündigung Vorrang vor der Beendigungskündigung.

184

Entscheidender Zeitpunkt für das Vorliegen der Kündigungsgründe ist grundsätzlich der Zeitpunkt des Zugangs der Kündigungserklärung1, allerdings kann sich bei Wegfall der Gründe nach Ausspruch der Kündigung in bestimmten Konstellationen ein Wiedereinstellungsanspruch ergeben. Je nach Verhalten des Arbeitgebers nach der Kenntnis von den Kündigungsgründen kann sich eine Unwirksamkeit der im Grundsatz gerechtfertigten Kündigung auch aus einem Verzeihen, einem Verzicht, einer Verwirkung oder einem Verbrauch der Kündigungsgründe ergeben.

185

Eine betriebsbedingte Kündigung i.S.d. § 1 Abs. 2 KSchG ist wirksam, wenn dringende betriebliche Erfordernisse einer Weiterbeschäftigung des Arbeitnehmers entgegenstehen, wenn also aufgrund einer unternehmerischen Entscheidung (z.B. Aufgabe der weiteren Wartung einer bestimmten Software) der betroffene Arbeitsplatz wegfällt, die Gründe, die zum Wegfall führen, dringend sind und es an einer anderweitigen Beschäftigungsmöglichkeit fehlt.

186

Im Hinblick auf die unternehmerische Entscheidung ist der Arbeitgeber nach h.M. an die Grenze der offenbaren Unsachlichkeit, der Unvernünftigkeit oder Willkür frei; offenbar unsachlich ist z.B. eine Entscheidung, die zu Verstößen gegen geltendes Tarifrecht führt.

187

Im Hinblick auf die Dringlichkeit eines betrieblichen Erfordernisses haben sich Fallgruppen herausgebildet, die deutlich machen, dass die Beendigungskündigung die ultima ratio sein muss. Ein dringendes betriebliches Erfordernis fehlt, wenn eine anderweitige Beschäftigungsmöglichkeit zu unveränderten Arbeitsbedingungen auf einem freien Arbeitsplatz besteht, eine Weiterbeschäftigungsmöglichkeit unter Änderung der Arbeitsbedingungen besteht oder wenn sonstige mildere Mittel vorhanden sind, z.B. Einführung von Kurzarbeit oder der Abbau von Überstunden. Nach § 1 Abs. 2 Satz 3 trifft den Arbeitgeber auch dann eine Pflicht zur Weiterbeschäftigung, wenn letztere erst nach zumutbaren Umschulungen oder Fortbildung möglich ist. Diese Umstände sind vom Arbeitgeber im Kündigungsschutzprozess darzulegen und zu beweisen. 1 Jedoch ist ein „Nachschieben“ von Kündigungsgründen insoweit möglich, als dies Gründe sind, die vor dem Zeitpunkt des Zugangs objektiv vorlagen, dem Kündigungsberechtigten aber subjektiv nicht bekannt oder (bis zur Grenze der Verwirkung) beim Ausspruch der Kündigung bereits bekannt waren. Problematisch dürfte dann allerdings die Betriebsratsanhörung nach § 102 BetrVG werden; betriebsverfassungsrechtlich sollen nur solche Gründe nachgeschoben werden können, die dem Arbeitgeber unbekannt waren.

508

Gennen

Softwareentwicklung durch Dritte

Rz. 191 E

Kommen für eine betriebsbedingte Kündigung mehrere Arbeitnehmer in Be- 188 tracht, fallen z.B. von 20 Programmiererarbeitsplätzen wegen der Einstellung der Wartung einer Software oder wegen des Wegbrechens eines großen Kunden lediglich fünf Arbeitsplätze weg, ist zwischen den 20 betroffenen Arbeitnehmern eine Sozialauswahl nach § 1 Abs. 3 KSchG vorzunehmen, wobei die Dauer der Betriebszugehörigkeit, das Lebensalter, die Unterhaltspflichten und eine mögliche Schwerbehinderung zu berücksichtigen und zu gewichten sind. In der Praxis gebräuchlich sind Punktesysteme, nach denen je Kriterium verschiedene Punktzahlen vergeben werden können und – vorbehaltlich einer wertenden Schlussbetrachtung – die Arbeitnehmer mit den geringeren Punktzahlen vor den Arbeitnehmern mit den höheren Punktzahlen zu kündigen sind. Von vornherein nicht in die Sozialauswahl einbezogen werden nach § 1 Abs. 3 Satz 2 KSchG Arbeitnehmer, deren Weiterbeschäftigung insbesondere wegen ihrer Kenntnisse, Fähigkeiten und Leistungen oder zur Sicherung einer ausgewogenen Personalstruktur des Betriebs, im berechtigten betrieblichen Interesse liegt. So ist z.B. denkbar, dass ein hoch spezialisierter Programmierer, der als einziger noch eine komplizierte „alte“ Programmiersprache beherrscht, auf die der Arbeitgeber angewiesen ist, von vornherein nicht in die Sozialauswahl einbezogen wird, weil seine Kenntnisse dem Unternehmen unbedingt erhalten bleiben müssen. Einstweilen frei.

189, 190

Nach § 1 Abs. 2 Satz 1 KSchG kann eine Kündigung auch als verhaltensbe- 191 dingte Kündigung sozial gerechtfertigt sein; gemeint ist ein vertragswidriges (Pflicht verletzendes) Verhalten des Arbeitnehmers. Dem Arbeitnehmer muss also vorgeworfen werden können, dass er sich anders hätte verhalten können. Das kann der Fall sein (Abwägung im Einzelfall) z.B. bei Geheimnisverrat, Zuwiderhandlungen gegen Alkohol- oder Rauchverbot im Betrieb, Arbeitsverweigerung, andauerndes Zuspätkommen, Vortäuschen einer Arbeitsunfähigkeit („Krankfeiern“), Beleidigungen gegen Vorgesetzte, Kollegen oder Kunden, Konkurrenztätigkeit bei bestehendem Arbeitsverhältnis, Straftaten bzw. Tätlichkeiten im Betrieb, in besonderen Fällen auch nachhaltige Schlechtleistung oder auch der bloße (dringende) Verdacht eines Vertrauensbruchs bzw. einer Straftat1. Fehlt es an der Vorwerfbarkeit des Verhaltens bzw. ist das Verhalten des Arbeitnehmers nicht steuerbar, kann eine personenbedingte Kündigung in Betracht kommen, s. nachfolgende Rz. 192. Die Prüfung erfolgt vierstufig: – – – –

Vorliegen einer Vertragsverletzung, Vorliegen einer negativen Prognose für das künftige Verhalten, die Anwendung milderer Mittel darf nicht Erfolg versprechend sein und schließlich wird eine Interessenabwägung vorgenommen.

1 Zum Sonderfall der Verdachtskündigung vgl. z.B. BAG v. 3.7.2003 – 2 AZR 437/02, NZA 2004, 307.

Gennen

509

E Rz. 192

Verträge

Die negative Prognose ist in aller Regel erst erfüllt, wenn vor dem kündigungsrelevanten Verhalten bereits wegen gleichartigen Fehlverhaltens in nicht allzu ferner Vergangenheit (je nach Schwere der Pflichtwidrigkeit in den letzten zwei bis fünf Jahren vor dem kündigungsrelevanten Verhalten) eine Abmahnung erteilt wurde. 192

Liegt ein vorwerfbares Verhalten nicht vor, ist aber der Verlust von Fähigkeiten oder die mangelnde Eignung zur Erfüllung der geschuldeten Arbeitsleistung eingetreten, kann ggf. personenbedingt gekündigt werden. Bisweilen ist die Abgrenzung zur verhaltensbedingten Kündigung schwierig, insbesondere bei Schlechtleistung. Auch bei der personenbedingten Kündigung ist eine Prognoseentscheidung zu treffen und zu prüfen, ob mildere Mittel als die Kündigung denkbar sind. Eine wesentliche Fallgestaltung ist die krankheitsbedingte Kündigung, die keine Kündigung wegen der Krankheit (vgl. § 8 Abs. 1 Satz 1 EFZG), sondern wegen der durch die Krankheit bedingten Folgen ist. Diese Folgen müssen zu einer erheblichen Beeinträchtigung der betrieblichen oder wirtschaftlichen Belange des Arbeitgebers führen und sollen eine Kündigung rechtfertigen. Eine krankheitsbedingte Kündigung kommt bei häufigen Kurzerkrankungen1, Langzeiterkrankungen2 oder krankheitsbedingten Leistungsminderungen3 in Betracht.

193

Nach § 4 KSchG besteht eine dreiwöchige Klagefrist. Diese Frist berechnet sich ab dem Zugang der Kündigungserklärung und ist eine nicht verlängerbare Ausschlussfrist. Sie muss gewahrt werden, wenn Kündigungsschutz nach dem KSchG begehrt werden soll, anderenfalls wird die Kündigung vorbehaltlich der Zulassung einer verspäteten Klage wirksam (§ 7 KSchG).

194

Steht am Ende des Prozesses fest, dass die Kündigung unwirksam ist, ist dem Arbeitnehmer aber eine Fortsetzung des Arbeitsverhältnisses nicht zuzumuten, oder macht der Arbeitgeber geltend, dass eine den Betriebszwecken dienliche weitere Zusammenarbeit der Arbeitsvertragsparteien nicht zu erwarten ist, kann das Gericht auf den Antrag der entsprechenden Partei hin das Arbeitsverhältnis auflösen und eine Abfindung festsetzen, die in der Höhe von der Dauer der Betriebszugehörigkeit und dem Lebensalter des Arbeitnehmers abhängt (§§ 9, 10 KSchG). Sie kann i.d.R. bis zu 12 Bruttomonatsverdienste, bei älteren Arbeitnehmern mit längerer Betriebszugehörigkeit bis zu 18 Bruttomonatsverdienste betragen.

195

§ 2 KSchG behandelt die Änderungskündigung4. Dies ist eine Kündigung, verbunden mit dem Angebot des Arbeitgebers, zu veränderten Arbeitsbedingungen weiter zu arbeiten. Änderungskündigungen werden i.d.R. ausgespro-

1 2 3 4

Vgl. z.B. BAG v. 20.1.2000, AP KSchG 1969 § 1 Krankheit Nr. 38. BGH v. 29.4.1999, AP KSchG 1969 § 1 Krankheit Nr. 36. BGH v. 29.1.1997, AP KSchG 1969 § 1 Krankheit Nr. 32. Dem Wortlaut nach erfasst ist nur die ordentliche; das BAG wendet § 2 KSchG aber entsprechend auf die außerordentliche Änderungskündigung an, vgl. z.B. BAG v. 27.9.2001, NZA 2002, 815.

510

Gennen

Softwareentwicklung durch Dritte

Rz. 196 E

chen, wenn der Arbeitgeber Änderungen herbeiführen möchte, die mithilfe seines Direktionsrechts nicht durchzusetzen sind; Änderungskündigungen sind auch das mildere Mittel gegenüber Beendigungskündigungen. Der Arbeitnehmer kann auf eine Änderungskündigung auf verschiedene Weise reagieren: – Nimmt der Arbeitnehmer das mit der Kündigung verbundene Angebot vorbehaltlos an, wird das Arbeitsverhältnis mit dem neuen Inhalt fortgesetzt. Die Kündigung verliert ihre Wirkung. – Nimmt der Arbeitnehmer das Angebot nach § 2 KSchG unter dem – rechtzeitig erklärten – Vorbehalt der Nachprüfung auf soziale Rechtfertigung an, kann er seinen Arbeitsplatz nicht verlieren, weil bei Unterliegen im Prozess immer noch der Arbeitsvertrag zu neuen Bedingungen besteht. Gewinnt er den Prozess, gilt die Änderungskündigung als von Anfang an unwirksam (§ 8 KSchG). Bis zur Entscheidung über die Wirksamkeit der Kündigung muss der Arbeitnehmer zunächst unter den neuen Bedingungen arbeiten. – Lehnt der Arbeitnehmer das Angebot definitiv ab bzw. nimmt er es nicht einmal unter dem Vorbehalt der Nachprüfung gem. § 2 KSchG an oder erklärt er den Vorbehalt zu spät, wehrt er sich aber gegen die Kündigung, führt er im Ergebnis einen Prozess um die Beendigung des Arbeitsverhältnisses. Verliert er diesen, ist das Arbeitsverhältnis insgesamt beendet. Lehnt er das Angebot ab und wehrt er sich nicht gegen die Kündigung, ist das Arbeitsverhältnis mit Ablauf der Kündigungsfrist beendet. Eine außerordentliche Kündigung (ohne oder mit Auslauffrist) ist nach 196 § 626 Abs. 1 BGB ohne Einhaltung einer Kündigungsfrist möglich, sofern ein wichtiger Grund vorliegt. Ein solcher wichtiger Grund ist zu bejahen, „wenn Tatsachen vorliegen, die aufgrund der Umstände des Einzelfalles unter Abwägung der Interessen beider Vertragsparteien die Fortsetzung des Arbeitsverhältnisses bis zum vorgesehenen Zeitpunkt bzw. dem Ablauf der Kündigungsfrist nicht zugemutet werden kann“. Im Streitfall ist zunächst zu prüfen, ob ein bestimmtes Vorkommnis „an sich geeignet ist“, einen wichtigen Grund darzustellen. Wichtige Gründe können z.B. grobe Vertragspflichtverletzungen oder Treuwidrigkeiten sein. Ist die Geeignetheit zu bejahen, erfolgt die Interessenabwägung im Einzelfall; einander gegenüber gestellt werden die Umstände, die der Arbeitgeber für eine Auflösung ins Feld führen kann und das Interesse des Arbeitnehmers an der Aufrechterhaltung des Arbeitsplatzes. Entscheidend sind u.a. Art und Schwere der Verfehlung, Verschuldensgrad, Wiederholungsgefahr, Lebensalter, Betriebsgröße, Unterhaltspflichten, Lebensalter des Arbeitnehmers, Dauer der Betriebszugehörigkeit. Die außerordentliche Kündigung muss die ultima ratio sein. Hat ein Arbeitnehmer die ordentliche Unkündbarkeit erreicht, z.B. aufgrund gesetzlichen Ausschlusses der ordentlichen Kündigung (vgl. z.B. § 9 Abs. 1 Satz 1 MuSchG) oder aufgrund Betriebszugehörigkeit und Lebensalter über tarifliche oder vertragliche Regelungen, kommt zur einseitigen

Gennen

511

E Rz. 197

Verträge

Beendigung nur noch die außerordentliche Kündigung in Betracht. Die Kündigung ist nach § 626 Abs. 2 BGB nur möglich (Zugang beim Arbeitnehmer) innerhalb einer Ausschlussfrist von zwei Wochen, nach dem der Kündigungsberechtigte von den Tatsachen erfahren hat, die die Kündigung rechtfertigen sollen. Die außerordentliche Kündigung unterliegt, wenn der Arbeitnehmer Klage erhebt, der gerichtlichen Überprüfung. Auch bei einer außerordentlichen Kündigung kann – wenn das KSchG im Übrigen eingreift – Kündigungsschutzklage nach dem KSchG erhoben werden, nach § 13 Abs. 1 KSchG jedoch nur nach Maßgabe der § 4 Satz 1, §§ 5 bis 7 KSchG. c) Aufhebungsvertrag 197

Ferner ist die Beendigung des Arbeitsverhältnisses auch durch einen sog. Aufhebungsvertrag möglich. Gerade für den Arbeitgeber kann der Aufhebungsvertrag sinnvoll sein, da hier keine Kündigungsfristen eingehalten werden müssen und ein oftmals langwieriger Kündigungsschutzprozess unterbleibt.

198

Unter einem Aufhebungsvertrag versteht man die einvernehmliche Beendigung des Arbeitsverhältnisses durch zwei übereinstimmende Willenserklärungen, ohne dass zuvor seitens des Arbeitgebers eine Kündigung ausgesprochen wurde. Der Vertrag über die Beendigung des Arbeitsverhältnisses nach zuvor ausgesprochener Kündigung wird Abwicklungsvertrag genannt; hier beendet i.d.R. nicht der Vertrag, sondern die Kündigung das Arbeitsverhältnis. Nach § 623 BGB bedarf der Aufhebungsvertrag der Schriftform. Als Mindestinhalt muss der Aufhebungsvertrag die Einigung der Vertragsparteien, das Arbeitsverhältnis mit sofortiger Wirkung oder zu einem späteren Zeitpunkt zu beenden, beinhalten. Weitere mögliche Vertragspunkte können sein – die Vereinbarung der vertragsgemäßen Abwicklung bis zur Beendigung des Arbeitsverhältnisses, – eine Abfindung (einschl. Entstehen, Fälligkeit, Höhe, Abtretungsmöglichkeiten, Aufrechnung, Anrechnung, Vererblichkeit), – die ausdrückliche Regelung von auf größere Zeiträume oder auf Ereignisse bezogenen Zahlungen (Provisionen, Tantiemen, Sonderzahlungen), – die Überleitung bestehender Versicherungen, – die Rückzahlung von Arbeitgeberdarlehen, – Verrechnungsabreden, – Freistellung von der Arbeitsverpflichtung, – Urlaubsgewährung, – Wettbewerbsverbote, – Rückzahlung von Aus-/Fortbildungskosten, – Dienstwagen,

512

Gennen

Softwareentwicklung durch Dritte

Rz. 207 E

– – – – – – –

Rechte an Arbeitsergebnissen, Behandlung einer Werkswohnung, betriebliche Altersversorgung, Rückgabe von Geschäftsunterlagen und Arbeitsmitteln, Aushändigung von Arbeitspapieren, evtl. offene Schadensersatzansprüche, Hinweise zu steuerlichen und sozialrechtlichen Konsequenzen der Beendigung und schließlich – eine umfassende Erledigungs- und Ausgleichsklausel. Da der Aufhebungsvertrag in aller Regel die zeitlich letzte Vereinbarung 199 zwischen den Arbeitsvertragsparteien ist und zudem eine Ausgleichsklausel arbeitgeberseits gewünscht wird, muss der ausscheidende Arbeitnehmer darauf achten, dass in der Tat alle Abreden, die aus seiner Sicht noch zu treffen sind, in dem Aufhebungsvertrag enthalten sind. Wie jede andere Willenserklärung auch kann eine Vertragspartei den Auf- 200 hebungsvertrag nach den allgemeinen Regeln der §§ 119, 123, 143 BGB anfechten. Dagegen ist die Ausübung eines Rücktritts- oder Widerrufsrechts nur möglich, wenn entsprechende gesetzliche, kollektiv- oder individualvertragliche Regelungen bestehen. Als gesetzliches Rücktrittsrecht kommt bspw. §§ 320, 323 Abs. 1 BGB in Betracht, wenn der Arbeitgeber mit der Zahlung der vereinbarten Abfindung in Verzug gerät und der Arbeitnehmer ihm eine Frist mit Ablehnungsandrohung gesetzt hat. Der Aufhebungsvertrag hat über die Beendigung des Arbeitsverhältnisses 201 hinaus im Einzelfall möglicherweise noch weitere nachteilige Konsequenzen. Er kann unter den Voraussetzungen der §§ 143 ff. SGB III zu einem Ruhen des Anspruchs auf Arbeitslosengeld bzw. zu einer Sperrzeit führen, zum Verlust einer Versorgungsanwartschaft, zu steuerlichen Folgen usw. Aus diesem Grund geht man mehrheitlich davon aus, dass der Arbeitgeber – in allerdings im Einzelnen umstrittenen Umfang – den Arbeitnehmer vor Abschluss des Aufhebungsvertrages über solche Folgen aufzuklären hat, anderenfalls der Arbeitnehmer einen Schadensersatzanspruch gegen den Arbeitgeber haben kann. Einstweilen frei.

202–206

d) Fortbestand der Rechte an Arbeitsergebnissen im Falle einer Beendigung des Arbeitsverhältnisses Mit der Beendigung des Arbeitsverhältnisses stellt sich die Frage, ob die an 207 Software bestehenden Nutzungs- und Verwertungs- sowie Nebenrechte, die im Rahmen des bestehenden Arbeitsverhältnisses entweder vertraglich oder durch eine gesetzliche Lizenz auf den Arbeitgeber übertragen wurden, wieder dem Arbeitnehmer zufallen, ob die Rechtseinräumung zugunsten des

Gennen

513

E Rz. 208

Verträge

Arbeitgebers die Beendigung des Arbeitsverhältnisses übersteht oder ob die eingeräumten Rechte sich aufgrund der Beendigung verändern. 208

Computerprogramme i.S.d. § 69a UrhG werden von § 69b UrhG nur erfasst, sofern ein Arbeitsverhältnis besteht1. Die nach § 69b UrhG auf den Arbeitgeber übergegangenen Rechte werden von der Beendigung des Arbeitsverhältnisses nicht berührt. Daher stehen auch die Nutzungs- und Verwertungsrechte an Computerprogrammen, die vor Beginn des neuen Arbeitsverhältnisses bei einem früheren Arbeitgeber fertig gestellt worden sind, weiter diesem zu und nicht dem neuen Arbeitgeber2.

209

Umstritten ist die Frage, wem die Nutzungs- und Verwertungsrechte an einem Computerprogramm zustehen, dessen Erstellung bei dem alten Arbeitgeber begonnen, aber erst während des neuen Arbeitsverhältnisses beendet wurde. Die Rechte an den bis zur Beendigung des alten Arbeitsverhältnisses entwickelten Teilen müssen im Umfang des § 69b UrhG dem früheren Arbeitgeber zustehen3; er hat dann auch das Recht, diese Teile nach dem Ausscheiden des Arbeitnehmers weiter zu verwerten und weiter zu entwickeln4. Dem neuen Arbeitgeber können solche Rechte nur bezogen auf die nach dem Beginn des neuen Arbeitsverhältnisses neu programmierten Teile zustehen, wobei fraglich ist, inwiefern hier selbständig funktionierende Teile der Software nutzbar sind oder nicht. Im Einzelfall ist daran zu denken, dem neuen Arbeitgeber jedenfalls ein einfaches Nutzungsrecht am gesamten Programm zuzugestehen, dessen Reichweite allerdings bereits fraglich sein dürfte. Sinn und Zweck des § 69b UrhG, dem begünstigten Arbeitgeber ausschließliche Nutzungs- und Verwertungsrechte zuzugestehen, würde es jedenfalls widersprechen, die nach der Norm vorgesehenen Rechte für die bis zur Beendigung des ersten Arbeitsverhältnisses fertig gestellten Teile dem ersten Arbeitgeber einzuräumen und dieselben Rechte am dann insgesamt fertig gestellten Programm (auch) dem zweiten Arbeitgeber.

210

Alle übergeleiteten Rechte an Arbeitnehmererfindungen, die in den Anwendungsbereich des ArbEG fallen, stehen nach § 26 ArbEG auch nach Beendigung des Arbeitsverhältnisses weiter dem Arbeitgeber zu, sofern diese Erfindungen zum Zeitpunkt der Beendigung fertig gestellt waren. Der Arbeitnehmer muss auch nach Ausscheiden aus dem Dienstverhältnis die während der Dauer desselben fertig gestellten Erfindungen dem Arbeitgeber melden (§ 5 ArbEG) oder mitteilen (§ 18 ArbEG) und diesen bei einer Schutzrechtsanmeldung unterstützen (§ 15 Abs. 2 ArbEG). Bei einem pflichtwidrigen Unterlassen des Fertigstellens einer Erfindung während der Dauer des 1 BGH v. 10.5.1984 – I ZR 85/82, MDR 1985, 120 = GRUR 1985, 129 ff.; LAG München v. 16.5.1986 – 4 Sa 28/86, CR 1987, 509 ff.; Hoeren, in: Möhring/Nicolini, § 69b UrhG Rz. 9. 2 BGH v. 10.5.1984 – I ZR 85/82, MDR 1985, 120 = GRUR 1985, 129 ff. 3 Schweyer, CR 1994, 684 ff.; Ullmann, GRUR 1987, 6 ff.; Grützmacher, in: Wandtke/Bullinger, 2002, § 69b UrhG Rz. 10. 4 Sack, BB 1991, 2165 ff.

514

Gennen

Softwareentwicklung durch Dritte

Rz. 213 E

Arbeitsverhältnisses, aber alsbaldiger Fertigstellung derselben unmittelbar nach Beendigung, kann der Arbeitgeber unter Umständen nach §§ 611, 280 Abs. 1, 619a BGB die Schutzrechtsübertragung an dieser Erfindung verlangen1. Rechte an urheberrechtlich geschützten Arbeitsergebnissen des Software- 211 entwicklers, die nicht nach § 69a UrhG als Computerprogramme zu qualifizieren sind, können nach § 43 UrhG auf den Arbeitgeber zu übertragen sein. Umstritten ist allerdings, inwiefern eine solche Übertragung mit Beendigung des Arbeitsverhältnisses erlischt. Vor allem in der arbeitsrechtlichen Literatur2 und Rechtsprechung3 wird vertreten, dass im Arbeitsverhältnis eine zeitlich unbeschränkte Rechteeinräumung erfolgt4. Das Ausscheiden aus dem Arbeits- oder Dienstverhältnis begründet keinen Wegfall der Geschäftsgrundlage für die Übertragung der Rechte, denn der Arbeitslohn sei ein Entgelt für die Schaffung des Arbeitsergebnisses, nicht für dessen Nutzung durch den Arbeitgeber5. Nur bei Vorliegen besonderer Umstände komme eine zeitliche Begrenzung der Rechtsübertragung in Betracht6. Die Gegenansicht geht davon aus, dass mit der Beendigung des Arbeitsverhältnisses auch die Einräumung der Nutzungsrechte endet7. So wie der Arbeitgeber die Nutzungsrechte erst durch das den Arbeitsvertrag begleitende Verfügungsgeschäft erwerbe, sei den Nutzungsrechten nach Beendigung des Arbeitsverhältnisses der Boden entzogen. Der Urheber als vormaliger Arbeitnehmer habe nunmehr das Recht, seine Werke wieder selbst zu nutzen, wenn nichts anderes vereinbart worden sei8. Um jeglichen rechtlichen Unsicherheiten vorzubeugen, sollte der Arbeit- 212 geber sich auf jeden Fall arbeitsvertraglich alle Nutzungs- und Verwertungsrechte an den Arbeitsergebnissen des Arbeitnehmers, die während der Dauer des Arbeitsverhältnisses geschaffen wurden, zeitlich unbefristet, weltweit und ausschließlich einräumen lassen. Hierzu bedarf es einer differenzierten und umfassenden Rechtseinräumungsklausel im Arbeitsvertrag. Auch die Gegenansicht räumt insofern ein, dass mit einer Abgeltung für die künftige Nutzung der Werke nach Beendigung des Arbeitsverhältnisses eine zeitlich unbeschränkte Rechtseinräumung gewollt sein wird. Ob und inwiefern Nutzungs- und Verwertungsrechte, die der Arbeitnehmer dem Arbeitgeber außerhalb der §§ 43, 69b UrhG vertraglich eingeräumt hat,

1 BGH v. 21.10.1980 – X ZR 56/78, GRUR 1981, 128 ff.; Bartenbach/Volz, § 26 ArbEG Rz. 22. 2 Schack, in: Münchener Handbuch des Arbeitsrecht, § 102 Rz. 21. 3 BAG v. 13.9.1983 – 3 AZR 371/81, MDR 1984, 521 = GRUR 1984, 429 ff. 4 Speziell für den Softwarebereich: Buchner, in: Lehmann, Rechtsschutz und Verwertung von Computerprogrammen, Rz. 42; Buchner, GRUR 1985, 1 ff. 5 Hunziker, Ufita 101 (1985), 49 ff.; früher: Wandtke, GRUR 1992, 139 ff. 6 Schack, in: Münchener Handbuch Arbeitsrecht, § 102 Rz. 21. 7 Wandtke/Bullinger, § 43 UrhG Rz. 77; Wandtke, GRUR 1999, 390 ff. 8 Wandtke/Bullinger, § 43 UrhG Rz. 77.

Gennen

515

213

E Rz. 214

Verträge

mit der Beendigung des Arbeitsverhältnisses ebenfalls enden, ist in erster Linie Vereinbarungssache.

II. Softwareentwicklung und Arbeitnehmerüberlassung 1. Begriffsbestimmung a) Ausgangssituation 214

Im Rahmen der Softwareentwicklung nutzen viele Unternehmen vorübergehend Fremdpersonal bei größeren und anspruchsvolleren, jedoch zeitlich befristeten Projekten. Hinter dem Einsatz von Fremdpersonal steht nicht zuletzt der Wunsch nach flexibler Gestaltung der Personal- und Personalnebenkosten1. Weitere Gründe können der Mangel an ausreichend qualifiziertem Personal oder auch das nur vorübergehende Erfordernis des Einkaufens bestimmten Wissens sein.

215

Eine der Möglichkeiten zum Einsatz von Fremdpersonal ist die Arbeitnehmerüberlassung. Es ist zwischen einer echten und einer unechten Arbeitnehmerüberlassung zu unterscheiden. Ein echtes Leiharbeitsverhältnis liegt vor, wenn der Verleiher den Arbeitnehmer nur vorübergehend an ein anderes Unternehmen ausleiht2, wie das bspw. zwischen Konzernunternehmen (§ 18 AktG) erfolgen kann (vgl. § 1 Abs. 3 AÜG). Dagegen liegt ein unechtes Leiharbeitsverhältnis vor, wenn der Arbeitnehmer gerade mit dem Ziel eingestellt wurde, seine Arbeitsleistung gegenüber Dritten zu erbringen und er gewerbsmäßig an Dritte überlassen wird. Indizien für eine solche gewerbsmäßige Arbeitnehmerüberlassung, die dem AÜG unterfällt, und für deren Durchführung eine behördliche Erlaubnis bestehen muss (§ 1 Abs. 1 Satz 1 AÜG), sind: – Integration in die Arbeitsorganisation des Einsatzunternehmens, – Koordination des Einsatzes mit der Arbeit des Einsatzunternehmens, – Übernahme von Tätigkeiten von bisherigen Arbeitnehmern des Einsatzunternehmens, – Mitverfolgung des Betriebszwecks bei dem Einsatzunternehmen, – Zusammenarbeit mit den Arbeitnehmern des Einsatzunternehmens, – Zuweisung von anderen als den geschuldeten Tätigkeiten durch das Einsatzunternehmen3.

216

Bei der gewerblichen (unechten) Arbeitnehmerüberlassung überlässt ein gewerbliches Arbeitnehmerüberlassungsunternehmen (Verleiher) einem Unternehmen mit vorübergehendem Personalbedarf (Entleiher) einen oder 1 Leitner, NZA 1991, 293 ff. 2 Steinkühler, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 25; Schüren, Einleitung zum AÜG, Rz. 77. 3 Steinkühler, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 26; BAG v. 14.6.1984, EzAÜG Nr. 154, Dauner-Lieb, NZA 1992, 817 ff.

516

Gennen

Softwareentwicklung durch Dritte

Rz. 218 E

mehrere Arbeitskräfte auf Zeit (Leiharbeitnehmer). Im Rahmen dieser gewerblichen Arbeitnehmerüberlassung bestehen dementsprechend verschiedene Rechtsverhältnisse zwischen den Betroffenen: – Zwischen dem Leiharbeitnehmer und dem Verleiher besteht ein Arbeitsverhältnis; daraus ist der Leiharbeitnehmer verpflichtet, seine Arbeitsleistung bei von dem Verleiher bestimmten Entleihern zu erbringen1. – Verleiher und Entleiher haben einen Arbeitnehmerüberlassungsvertrag geschlossen. Der Verleiher erhält von dem Entleiher, in dessen Betrieb der oder die Leiharbeitnehmer ihre Arbeitsleistung nach seinen Weisungen erbringt/erbringen, ein Entgelt für die Überlassung des/der Arbeitnehmer/s. – Zwar besteht keine arbeitsvertragliche Beziehung2 zwischen Entleiher und Leiharbeitnehmer, dem Entleiher wurde aber durch den Verleiher die Befugnis eingeräumt, die verschafften Arbeitnehmer nach eigenen Weisungen einzusetzen. Die Arbeitgeberbefugnisse und -verpflichtungen, insbesondere das Direktions- oder Weisungsrecht sowie die Schutz- und Fürsorgepflichten des Arbeitgebers, sind dadurch zwischen Verleiher und Entleiher aufgespalten. Besonderheiten gelten in Kleinbetrieben mit weniger als 50 Beschäftigten 217 (§ 1a AÜG). Von dieser Norm dürften viele Softwareunternehmen betroffen sein. Hier bedarf die Arbeitnehmerüberlassung keiner Erlaubnis, wenn die Überlassung 12 Monate Dauer nicht übersteigt und zur Vermeidung von Kurzarbeit oder Entlassungen erfolgt. Dann bedarf es nur der vorherigen Anzeige der Überlassung an die Bundesagentur für Arbeit. b) Abgrenzung der Arbeitnehmerüberlassung zu Dienst- und Werkvertrag Eine weitere Möglichkeit der Beschäftigung von Dritten im Unternehmen 218 ist die Beschäftigung auf der Basis von Dienst- oder Werkverträgen. So ist denkbar, dass ein Softwarehersteller einen Entwicklungsunterauftrag an einen Dritten vergibt (zum Subunternehmervertrag siehe unten Rz. 295 ff.), weil er den ihm erteilten Auftrag aufgrund mangelnder Kapazitäten oder fehlenden Know-hows allein nicht abwickeln kann. In der Praxis mischen sich die Entwicklungsteams dann oft und es werden auf der Arbeitsebene die Aufgaben an Personen mit gerade freien Kapazitäten verteilt, ohne dass ein Unterschied zwischen den eigenen Arbeitnehmern und den Arbeitnehmern des Subunternehmers gemacht wird. Da gerade in solchen Situationen die Abgrenzung zwischen Arbeitnehmerüberlassung und der vorübergehenden Entsendung eines Arbeitnehmers im Rahmen eines Dienst- oder Werkvertrages zwischen Auftraggeber und Entsender schwierig ist, hat die Bun1 Kokemoor, NZA 2003, 238 ff. 2 Wie die rechtliche Beziehung zwischen Leiharbeitnehmer und Entleiher rechtlich zu qualifizieren ist, ist umstritten; s. hierzu nur exemplarisch Reiserer, in: Münchener Anwaltshandbuch Arbeitsrecht, § 65 Rz. 64 f.; Schüren, Einleitung zum AÜG, Rz. 83 ff.; Ulber, § 1 AÜG Rz. 18 f.

Gennen

517

E Rz. 219

Verträge

desagentur für Arbeit eine Geschäftsanweisung zum AÜG1 erlassen, der jedoch als Verwaltungsvorschrift nur interne Wirkung zukommt. Nach Ziff. 1.1.6.5 Abs. 4 liegt im Bereich der Softwareentwicklung grundsätzlich keine Arbeitnehmerüberlassung vor, wenn ein Unternehmen, das selbst Software-Programme erstellt, eigenes Stammpersonal in einen Betrieb entsendet, um ein Programm dort aufzuspielen oder zu entwickeln oder um aus einem Teilprogramm ein Gesamtprogramm zu entwickeln und zu erproben, sofern das entsendende Unternehmen das Unternehmerrisiko trägt. Die kontinuierliche Anwendung eines Programms durch Fremdkräfte ist demgegenüber in der Regel Arbeitnehmerüberlassung. Um den Arbeitnehmerüberlassungsvertrag von einem Dienst- oder Werkvertrag abgrenzen zu können, kommt es folglich auf den konkreten Vertragsgegenstand und die tatsächliche Ausgestaltung und Durchführung des Vertragsverhältnisses an. Wie die Parteien dagegen das Vertragsverhältnis selber bezeichnen, ist irrelevant. 219

Ein Dienstvertrag mit dem Entsender von Arbeitnehmern eines anderen Betriebes liegt immer dann vor, wenn dieser nur den Einsatz der Arbeitskraft seiner Arbeitnehmer, nicht aber einen bestimmten Erfolg schuldet. Ein weiteres Indiz ist, dass die Beseitigung nicht verschuldeter Fehler nicht zu den Leistungen des Entsenders gehört. Von einem Arbeitnehmerüberlassungsvertrag unterscheidet sich der Dienstvertrag vor allem dadurch, dass der entsendete Arbeitnehmer nicht den Weisungen des Auftraggebers unterliegt und nicht in dessen Betrieb eingegliedert wird. Gerade das letzte Kriterium kann im Bereich der Softwareentwicklung – wie dargestellt – aber gewisse Schwierigkeiten bereiten, da oftmals eine gewisse Eingliederung notwendig ist, wenn mit anderen Arbeitnehmern des Auftraggebers an einem gemeinsamen Projekt zusammengearbeitet werden soll. Aus diesem Grund sollte dem entsendeten Arbeitnehmer die Organisation seiner eigenen Arbeit, bspw. seine Arbeitszeiten überlassen werden, wenn das Vorliegen einer Arbeitnehmerüberlassungssituation vermieden werden soll.

220

Bei einem Werkvertrag schuldet der Entsender einen konkreten Erfolg, zu dessen Erreichung er sich eigener Mitarbeiter bedient, die von ihm eingesetzt und überwacht werden. Vielfach wird vom Eintreten des Erfolgs auch die Vergütung maßgeblich bestimmt. Bei Auftreten von Fehlern ist der Entsender grundsätzlich zur kostenlosen Mängelbeseitigung verpflichtet (Sachund Rechtsmangelhaftung nach §§ 631 ff. BGB). Wie auch beim Dienstvertrag dürfen die Arbeitnehmer des Entsenders nicht in die betriebliche Organisation des Auftraggebers eingebunden werden und unterliegen allein den Weisungen des Entsenders, der über die Art und Weise der Erreichung des vertraglich von ihm geschuldeten Erfolges entscheidet. Als Indiz für das Vorliegen eines Werkvertrages wurde von der Rechtsprechung bspw. angesehen, wenn ein Unternehmer in Eigenverantwortung durch seine Arbeitnehmer Standardsoftware auf die individuellen Bedürfnisse des Auftraggebers 1 Gültig ab dem 20.4.2013, OS12 – 7160.4(1).

518

Gennen

Softwareentwicklung durch Dritte

Rz. 223 E

anpassen und das Personal des Auftraggebers einarbeiten lässt1. Ein weiterer Hinweis auf das Vorliegen eines Werkvertrages ist der allein projektbezogene Einsatz der Arbeitnehmer des Entsenders, der eigenverantwortlich über die Anzahl der von ihm eingesetzten Arbeitnehmer und über deren Arbeitszeiten entscheidet2. c) Gewerbliche Arbeitnehmerüberlassung Nach § 1 Abs. 1 Satz 1 AÜG ist für das Betreiben gewerbsmäßiger Arbeitnehmerüberlassung erforderlich, dass der Verleiher eine Erlaubnis nach § 2 AÜG besitzt. Eine gewerbsmäßige Arbeitnehmerüberlassung liegt vor, wenn der Hauptzweck eines Betriebs oder Betriebsteils darauf gerichtet ist, aus der Arbeitnehmerüberlassung einen wirtschaftlichen Gewinn zu erzielen. Versagungsgründe für die Erteilung der Erlaubnis finden sich in § 3 AÜG.

221

Nach § 12 Abs. 1 Satz 1 AÜG muss der Arbeitnehmerüberlassungsvertrag 222 schriftlich geschlossen werden. Nach Satz 2 und 3 muss der Verleiher in dem Vertrag ausdrücklich versichern, die nach § 1 Abs. 1 AÜG erforderliche Erlaubnis zu besitzen. Der Entleiher hat anzugeben, welche besonderen Merkmale die für den Leiharbeitnehmer vorgesehene Tätigkeit hat und welche berufliche Qualifikation dafür erforderlich ist, sowie welche im Betrieb des Entleihers für einen vergleichbaren Arbeitnehmer des Entleihers wesentlichen Arbeitsbedingungen einschließlich des Arbeitsentgelts gelten. Wird gegen das Schriftformerfordernis des § 12 Abs. 1 AÜG verstoßen, ist der Vertrag nach § 125 BGB nichtig und nach den bereicherungsrechtlichen Vorschriften der §§ 812 ff. BGB rückabzuwickeln. Sollte der Verleiher die nach § 1 Abs. 1 AÜG erforderliche Erlaubnis nicht 223 besitzen oder diese nachträglich wegfallen, liegt eine illegale Arbeitnehmerüberlassung vor. Nach § 9 Nr. 1 AÜG ist dann sowohl der Vertrag zwischen Leiharbeitnehmer und Verleiher, als auch der Vertrag zwischen Verleiher und Entleiher unwirksam. Der unwirksame Arbeitnehmerüberlassungsvertrag begründet keine Primäransprüche auf Leistung (Anspruch auf Vergütung bzw. Anspruch auf Überlassung des Arbeitnehmers), sondern ist nach Bereicherungsrecht rückabzuwickeln3. Daneben bestehen Schadensersatzansprüche des Entleihers gegen den Verleiher nach §§ 280 Abs. 1, 241 Abs. 2, 311 Abs. 2 Nr. 1 BGB. Der Leiharbeitnehmer hat einen Schadensersatzanspruch nach § 10 Abs. 2 AÜG gegen den Verleiher. Verstöße gegen die §§ 1 Abs. 1, 2 AÜG können zudem nach den §§ 15, 16 Abs. 1 Nr. 1 und 1 Buchst. a als Ordnungswidrigkeit oder Straftatbestand geahndet werden.

1 S. OLG Karlsruhe v. 30.9.1994, CR 1997, 397 f. 2 Weitere Indizien für das Vorliegen eines Werkvertrages werden von Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 33 genannt. 3 BGH v. 8.11.1997, § 10 EzAÜG, AP Nr. 2; Reiserer, in: Münchener Anwaltshandbuch Arbeitsrecht, § 66 Rz. 100.

Gennen

519

E Rz. 224

Verträge

224

Nach § 10 AÜG wird bei der illegalen Arbeitnehmerüberlassung ein Arbeitsverhältnis zwischen Arbeitnehmer und Entleiher fingiert. Auf diese Weise wollte der Gesetzgeber den Arbeitnehmer absichern, der damit die ihm eigentlich gegen den Verleiher zustehenden Vergütungsansprüche nunmehr gegen den Entleiher geltend machen kann. Nach Satz 2 bestimmt sich die Dauer dieses fiktiven Arbeitsverhältnisses, welches entweder mit Unwirksamkeit des Arbeitsvertrages oder mit Aufnahme der Tätigkeit im Betrieb des Entleihers beginnt (§ 10 Abs. 1 Satz 1 AÜG), nach der Dauer der zwischen Verleiher und Entleiher vereinbarten Arbeitnehmerüberlassung. Bis auf die Arbeitszeit (§ 10 Abs. 1 Satz 3 AÜG) gelten für das fingierten Arbeitsverhältnis zwischen Entleiher und Leiharbeitnehmer alle Bestimmungen (also nicht nur arbeitsrechtliche Gesetze und Verordnungen, sondern auch tarifvertragliche Regelungen, Betriebsvereinbarungen, betriebliche Übungen etc.), die im Betrieb des Entleihers für dessen Arbeitnehmer gelten.

225

Von der illegalen Arbeitnehmerüberlassung zu unterscheiden ist die illegale (d.h. ohne vorherige Anmeldung durchgeführte) Arbeitsvermittlung nach § 1 Abs. 2 AÜG, die immer dann vorliegt, wenn der Arbeitgeber hinsichtlich des konkreten Arbeitsverhältnisses nicht die üblichen Arbeitgeberpflichten oder das Arbeitgeberrisiko übernimmt, § 3 Abs. 1 Nr. 1–3 AÜG. Sanktionsmöglichkeiten bestehen allerdings bei einer illegalen Arbeitsvermittlung nicht1. Das Arbeitsverhältnis zwischen Arbeitnehmer und Verleiher bleibt im Gegensatz zur illegalen Arbeitnehmerüberlassung bestehen2. 2. Leistungspflichten

226

Zwischen dem Leiharbeitnehmer und dem Verleiher wird ein herkömmlicher Arbeitsvertrag geschlossen. Besonderheiten ergeben sich nur insoweit, als dass der Arbeitsvertrag nach § 11 Abs. 1 Satz 1 AÜG den Formerfordernissen nach § 2 NachwG genügen muss. Als besondere Pflicht des Arbeitnehmers muss in den Vertrag aufgenommen werden, dass dieser seine Arbeitsleistung an verschiedenen Orten und in verschiedenen Betrieben erbringt3. Sollten Auslandseinsätze des Arbeitnehmers geplant sein, so müssen die verschiedenen Einsatzstaaten und auch das anwendbare Recht besonders benannt sein4. Die genaue Angabe der dem Arbeitnehmer zu zahlenden Vergütung ist dagegen nicht möglich, da nach § 10 Abs. 4 AÜG allen Leiharbeitnehmern der gleiche Lohn zu zahlen ist wie vergleichbaren Arbeitnehmern im Betrieb des Entleihers.

1 Reiserer, in: Münchener Anwaltshandbuch Arbeitsrecht, § 66 Rz. 101 ff. 2 Reiserer, in: Münchener Anwaltshandbuch Arbeitsrecht, § 66 Rz. 106; Säcker/ Kühnast, ZfA 2001, 117 ff. 3 Schüren, § 11 AÜG Rz. 31 f. 4 Schüren, § 11 AÜG Rz. 32; Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 58.

520

Gennen

Softwareentwicklung durch Dritte

Rz. 229 E

Die Hauptleistungspflicht des Verleihers besteht darin, dem Entleiher ent- 227 sprechend der vertraglichen Anforderungen geeignete Arbeitnehmer fristgerecht und für die gesamte Dauer des Vertrages zur Verfügung zu stellen1. Die Geeignetheit der zu überlassenden Arbeitnehmer bezieht sich nicht nur auf rein tatsächliche Umstände, wie etwa fachliche Qualifikationen, sondern auch auf rechtliche Faktoren, wie bspw. das Vorliegen einer Arbeitserlaubnis bei einem ausländischen Arbeitnehmer. Dem steht als Hauptleistungspflicht des Entleihers die Zahlung der vereinbarten Vergütung an den Entleiher sowie die Annahme der Arbeitsleistung des überlassenden Arbeitnehmers gegenüber. Dem Entleiher wird darüber hinaus die Befugnis (und Pflicht) zugewiesen, den Leiharbeitnehmer wie einen eigenen Arbeitnehmer in die betriebliche Organisation einzubinden und diesem gegenüber Weisungen zu erteilen. Der Entleiher hat, um dem Verleiher die Erfüllung seiner Hauptleistungspflicht der Überlassung geeigneter Arbeitnehmer zu ermöglichen, nach § 12 Abs. 1 Satz 3 AÜG eine Informationspflicht bzgl. der von ihm gewünschten Qualifikationen und des für den überlassenen Arbeitnehmer vorgesehenen Tätigkeitsfeldes. 3. Rechteübertragung Da der Leiharbeitnehmer bei einer erlaubten Arbeitnehmerüberlassung Ar- 228 beitnehmer des Verleihers ist, erfolgt bei der Erstellung von Software kein gesetzlicher Rechteübergang auf den Entleiher, sondern nach § 69b UrhG auf den Arbeitgeber, den Verleiher. Die Nutzungs- und Verwertungsrechte an sonstigen Werken des Leiharbeitnehmers, z.B. an von ihm verfassten Handbücher, stehen diesem zu, d.h. er erwirbt als Schöpfer nach § 7 UrhG sämtliche Urhebernutzungs- und Urheberpersönlichkeitsrechte, die er allerdings im Rahmen seiner arbeitsvertraglichen Pflichten gegenüber dem Verleiher als seinem Arbeitgeber zu übertragen hat (§ 43 UrhG). Ihn trifft insofern eine Übertragungspflicht2, der u.U. auch ohne ausdrückliche arbeitsoder tarifvertraglicher Regelung stillschweigend nachgekommen werden muss3. Der Umfang der Rechteübertragung bestimmt sich dann nach § 31 Abs. 5 UrhG, wonach der Vertragszweck für die Einräumung der Rechteeinräumung entscheidend ist. Im Rahmen des Arbeitnehmerüberlassungsvertrages zwischen Verleiher 229 und Entleiher wird der Verleiher sich regelmäßig verpflichten, alle Nutzungs- und Verwertungsrechte an der von seinem Arbeitnehmer erstellten Software und anderen urheberrechtlich geschützten Werken auf den Entlei1 BGH v. 13.5.1975, § 12 AÜG, AP Nr. 1; Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 106. 2 BAG v. 13.9.1983 – 3 AZR 371/81, MDR 1984, 521 = NJW 1984, 1579 f.; BAG v. 24.11.1960, GRUR 1961, 491 ff. 3 So bereits RGZ 110, 393 ff.; seitdem ständige Rechtsprechung, vgl. nur BAG v. 12.3.1997 – 5 AZR 669/95, NZA 1997, 765 ff.; BAG v. 24.11.1960, GRUR 1961, 491 ff.; BGH v. 22.2.1974, GRUR 1974, 480 ff.

Gennen

521

E Rz. 230

Verträge

her zu übertragen. Um eine solche Rechteübertragung wirksam vereinbaren zu können, müssen dem Verleiher die dem Arbeitnehmer zustehenden Rechte von diesem zunächst mit der Maßgabe eingeräumt worden sein, diese auch an Dritte übertragen zu dürfen. Obschon es dem Zweck eines mit einem Leiharbeitnehmer geschlossenen Arbeitsvertrages entsprechen sollte, dass der Verleiher alle Rechte erhält damit er diese im Zweifel an den Entleiher/Auftraggeber abtreten oder lizenzieren kann, sollte zur Vermeidung von rechtlichen Unklarheiten eine umfassende Rechteeinräumungsregelung zugunsten des Verleihers in den mit dem Arbeitnehmer geschlossenen Vertrag aufgenommen werden1. Je nach den Umständen des Einzelfalles kann der Verleiher dann mit dem Entleiher entweder eine einfache oder eine ausschließliche Rechteeinräumung vereinbaren. 230

Im Bereich der technischen Verbesserungsvorschläge und Arbeitnehmererfindungen gibt es eine besondere Vorschrift in § 11 Nr. 7 AÜG. Hiernach gilt der Entleiher als Arbeitgeber, wenn der Leiharbeitnehmer während der Dauer der Tätigkeit bei dem Entleiher eine Erfindung oder einen technischen Verbesserungsvorschlag gemacht hat. 4. Leistungsstörungen

231

Im Bereich der Leistungsstörungen ist wiederum zwischen den verschiedenen vertraglichen Beziehungen der Parteien untereinander zu unterscheiden. a) Leistungsstörungen im Verhältnis Arbeitnehmer-Verleiher

232

Das Arbeitsverhältnis folgt den normalen Regelungen (siehe oben Rz. 158 ff.). Im Rahmen eines Arbeitsvertrages zur Arbeitnehmerüberlassung sollte aber eine Meldepflicht des Arbeitnehmers vereinbart werden, die es diesem auferlegt, eine Verhinderung der Ausübung seiner Tätigkeit – gleich aus welchem Grund – dem Verleiher unverzüglich mitzuteilen2. Eine solche Vereinbarung dient dem Schutz des Verleihers, der dem Entleiher gegenüber für die ununterbrochene Personalbeschaffung haftet. Diese Anzeigeverpflichtung sollte bei Nichteinhaltung auch sanktioniert werden.

233

Der Arbeitnehmer kann sich ggf. schadensersatzpflichtig machen, wenn er an Arbeitskampfmaßnahmen innerhalb des Betriebes des Entleihers teilnimmt. Da hier keine in Bezug auf seine Person tariflich regelbaren Ziele erreicht werden können, ist ihm eine Teilnahme an einem solchen Arbeitskampf untersagt3. Bei Arbeitskampfmaßnahmen im Betrieb des Entleihers 1 Als Beispiel für eine solche Rechteeinräumungsregelung s. Bartenbach/Gennen, in: Münchener Anwaltshandbuch Arbeitsrecht, § 14 Rz. 196. 2 S. die bei Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 49, 80 vorgeschlagene Klausel. 3 Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3, Rz. 81; Schüren, Einleitung zum AÜG, Rz. 253 ff.

522

Gennen

Softwareentwicklung durch Dritte

Rz. 237 E

befindet sich dieser mit Annahme der durch den Arbeitnehmer angebotenen Arbeitsleistung im Annahmeverzug nach §§ 293 ff. BGB, so dass dem Arbeitnehmer ein Zurückbehaltungsrecht an seiner Arbeitsleistung bei gleichzeitiger Fortzahlung der Vergütung zusteht, vgl. § 11 Abs. 5 AÜG. Hier läge eine Regelung im Interesse des Verleihers, die den Arbeitnehmer in einem solchen Fall verpflichtet, seine Arbeitskraft dem Verleiher unverzüglich neu anzubieten, damit dieser an andere Kunden vermittelt werden kann1. b) Leistungsstörungen im Verhältnis Verleiher-Entleiher Leistungsstörungen seitens des Verleihers können vor allem im Bereich der 234 Personalauswahl und -überlassung auftreten. Der Verleiher hat die kontinuierliche Besetzung des Arbeitsplatzes durch geeignete Arbeitnehmer zu gewährleisten. Verstößt er hiergegen entweder durch Schlechtleistung (ungeeigneter Arbeitnehmer) oder Nichtleistung (kein Arbeitnehmer), haftet er nach § 280 Abs. 1 oder § 281 BGB, ohne dass ein Verschulden seinerseits vorzuliegen braucht. Folglich erstreckt sich eine Haftung des Verleihers auch auf die Fälle, in denen ein Leiharbeitnehmer plötzlich erkrankt oder stirbt2. Stellt der verliehene Leiharbeitnehmer seine Tätigkeit vor Ablauf endgültig ein, ohne dass dies der Verleiher verschuldet hat und steht kein anderer Leiharbeitnehmer zur Verfügung, so wird der Verleiher von der Leistungspflicht frei (§ 275 Abs. 1 BGB), verliert aber auch den Anspruch auf die Arbeitnehmerüberlassungsvergütung, § 323 Abs. 1 BGB. Dagegen besteht nur dann eine Haftung des Verleihers für durch den Arbeit- 235 nehmer bei dem Entleiher verursachte Schäden, wenn diese Schäden kausal auf einem Auswahlfehler des Verleihers beruhen3, d.h. wenn ein Arbeitnehmer durch den Verleiher ausgewählt wurde, der den Leistungsanforderungen des Entleihers nicht gerecht wurde und gerade aufgrund seiner fehlenden Leistungsfähigkeit den entsprechenden Schaden verursacht hat. Es kann sich anbieten, dem Entleiher eine Austauschmöglichkeit für Ar- 236 beitnehmer vertraglich einzuräumen, wenn diese nicht zur Zufriedenheit desselben arbeiten sollten. Eine solche Austauschverpflichtung sollte zum Schutz des Verleihers mit einer bestimmten Frist gekoppelt sein, um verspätete Einwendungen des Entleihers auszuschließen. Auf diese Weise wird dem Verleiher ein bereits aus dem Werkvertrag bekanntes vorrangiges Nacherfüllungsrecht unter Beibehaltung seines Vergütungsanspruches eingeräumt. Dem Entleiher wird oftmals auch eher an einer Nacherfüllung, als an der Liquidierung wegen Schlechterfüllung gelegen sein. Pflichtverletzungen des Entleihers sind vor allem in der verspäteten oder 237 nicht erfolgten Zahlung der vereinbarten Vergütung zu sehen. Daneben sind 1 S. hierzu die von Werxhausen vorgeschlagene Klausel in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 49, 80. 2 Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 110. 3 Werxhausen, in: Redeker, Handbuch der IT-Verträge, Kap. 5.3 Rz. 110.

Gennen

523

E Rz. 238

Verträge

Nebenpflichtverletzungen im Rahmen der den Entleiher treffenden Informationspflicht nach § 12 Abs. 1 Satz 3 AÜG denkbar, die unter Umständen den Verleiher zu einer Kündigung berechtigen können. 5. Vergütung 238

Der Verleiher ist gegenüber dem Arbeitnehmer vergütungspflichtig, wobei sich die Höhe der jeweils zu entrichtenden Vergütung nach den Regelungen innerhalb des Entleiherbetriebs richtet. Demnach richtet es sich auch nach den Bestimmungen innerhalb des Betriebes des Entleihers, ob dem Arbeitnehmer neben dem Lohnanspruch ein zusätzlicher Anspruch auf Vergütung zusteht (Trennungstheorie), oder ob mit dem Lohn grundsätzlich auch die Einräumung der Urhebernutzungsrechte und die Verwertung arbeitsvertraglich geschuldeter Werke abgegolten ist (Abgeltungstheorie)1.

239

Empfehlenswert ist die Aufnahme einer Klausel in den Arbeitsvertrag, die den Arbeitnehmer verpflichtet, einen Stundennachweis zu erstellen, diesen vom Entleiher unterzeichnen zu lassen und dem Verleiher unverzüglich vorzulegen. Dieser Stundennachweis erlangt vor allem im Hinblick auf die Vergütungszahlungen des Entleihers an den Verleiher Bedeutung, sofern eine Abrechnung nach tatsächlich geleisteter Arbeit des Arbeitnehmers erfolgen soll.

240

Zwischen Entleiher und Verleiher sind verschiedene Abrechnungsmöglichkeiten denkbar. So kann ein Festpreis für die gesamte Dauer der Überlassung vereinbart werden. Denkbar ist auch eine Abrechnung nach gewissen Zeitspannen unter dem Nachweis einer Stundenauflistung der durch den Arbeitnehmer tatsächlich geleisteten Arbeit. Letztere Möglichkeit wird insbesondere im Rahmen von Projektarbeiten interessant sein, in denen nur unterschiedliche Teilbereiche durch den Leiharbeiter wahrgenommen werden und bei denen sich eine Dauer der Arbeitnehmerüberlassung nicht absehen lässt. Zur Sicherung seiner Ansprüche sollte der Verleiher die Zahlung eines Abschlags jeweils zu Anfang eines Teilzeitraumes vereinbaren.

III. Freie Mitarbeiter 1. Begriff, Abgrenzung zur arbeitnehmerähnlichen Person 241

Der freie Mitarbeiter ist begrifflich der Gegensatz zum abhängig beschäftigten Arbeitnehmer. Vielfach wird diese Person auch als „Freelancer“, „Freischaffender“, „Honorarkraft“ oder „Dienstleister“ bezeichnet, wobei alle diese Begriffe in rechtlicher Hinsicht inhaltlich unbestimmt sind. Die beiden erstgenannten Begriffe sollen lediglich klarstellen, dass das Beschäftigungsverhältnis in Abgrenzung zum Arbeitsverhältnis ein „freies“ ist, der 1 Zu diesem Meinungsstreit s. Wandtke, in: Wandtke/Bullinger, § 43 UrhG Rz. 134 ff.

524

Gennen

Softwareentwicklung durch Dritte

Rz. 242 E

dritte soll zeigen, dass der freie Mitarbeiter kein Arbeitsentgelt bezieht, sondern Honorar in Rechnung stellt, und der letztgenannte lehnt sich an den Dienstvertrag nach §§ 611 ff. BGB an, in Abgrenzung zu dem ebendort (auch) in Teilen geregelten Arbeitsverhältnis. Ein Beschäftigungsverhältnis ist ein freies Mitarbeiterverhältnis, wenn die 242 Person nicht persönlich und wirtschaftlich abhängig und in den Betrieb des Dienstherrn eingegliedert ist (das kennzeichnet vielmehr das Arbeitsverhältnis), sondern wenn sie im Wesentlichen frei ihre Tätigkeit gestalten und ihre Arbeitszeit bestimmen kann, wie es § 84 Abs. 1 Satz 2, Abs. 2 HGB für den selbständigen Handelsvertreter vorsieht. Diese Vorschrift wird auf Beschäftigungsverhältnisse außerhalb des Handelsvertreterrechts entsprechend angewendet1. Der Begriff des „freien Mitarbeiters“ entzieht sich einer scharfen Definition, er verlangt eine Wertung in Abgrenzung zum Arbeitsverhältnis. Wertungsfaktoren sind dabei, wie erwähnt, der Grad der persönlichen Abhängigkeit oder Unabhängigkeit und die Eigenbestimmung oder Fremdbestimmtheit im Rahmen einer von Dritten bestimmten Organisation. Arbeitnehmer, also nicht freier Mitarbeiter, ist, wer seine vertraglich geschuldete Leistung im Rahmen einer von einem Dritten bestimmten Arbeitsorganisation zu erbringen hat und in dieser eingegliedert ist, weil er hinsichtlich Ort, Zeit und Ausführung seiner Tätigkeit einem umfassenden Weisungsrecht seines Vertragspartners (Arbeitgebers) unterliegt2. § 7 Abs. 1 Satz 2 SGB IV definiert abhängige Beschäftigung als „eine Tätigkeit nach Weisungen und eine Eingliederung in die Arbeitsorganisation des Weisungsgebers.“ Fachliche Weisungsgebundenheit spielt keine erhebliche Rolle für die Abgrenzung zwischen Werk- oder abhängigem Dienstvertrag, wohl aber persönliche und zeitliche Weisungsgebundenheit. Bei der Eigen- oder Fremdbestimmung spielt das Tätigkeitsniveau und die damit verbundene Individualität der Tätigkeit eine Rolle. Sie ist bei der geistigen Tätigkeit der Softwareerstellung naturgemäß größer in Richtung auf freie Mitarbeit als bei manueller Tätigkeit. Andererseits bringt es die Entwicklung beim Kunden zur Anpassung der Software an den konkreten Einsatzbedarf mit sich, dass der Softwareentwickler mehr oder weniger stark in die betriebliche Organisation des Auftraggebers eingebunden ist, was in Richtung abhängiger Ar1 BAG v. 29.5.2002 – 5 AZR 161/01, NZA 2002, 1232 – Arbeitsrechtlicher Status eines VHS-Dozenten, mit Anm. Hromadka in NJW 2003, 1847. 2 BAG v. 30.1.1991 – 7 AZR 497/89, MDR 1991, 1179 = CR 1992, 284 = BB 1991, 2375 – Abgrenzung von Arbeitnehmerüberlassung und zu Werk- und Dienstverträgen; BAG v. 13.2.2003, NJW 2003, 2931 – Marketingberatervertrag: Beraterverträge sind typischerweise freie Mitarbeiterverträge; BGH v. 25.6.2002 – X ZR 83/00, MDR 2002, 1183 = NJW 2002, 3317 – Auskeimer von Rindervierteln in fremden Schlachthöfen waren nicht freie Subunternehmer, sondern eingegliederte Angestellte. Personen, die Kunden ihres Dienstherrn in der Bedienung von Geräten (das können auch Computer oder Software sein) gemäß den Wünschen des Kunden in deren Räumen nach inhaltlichen Vorgaben des Dienstherrn unterrichten, sind i.d.R. Arbeitnehmer; BAG v. 6.5.1988 – EzA Nr. 73 zu § 611 Arbeitnehmerbegriff.

Gennen

525

E Rz. 243

Verträge

beit weist. Indizien für ein Rechtsverhältnis als freier Mitarbeiter sind z.B. eine eigene Betriebsstätte, eigene Betriebsmittel, der Einsatz eigenen Kapitals, die Beschäftigung von Mitarbeitern (die vertraglich festgelegte Befugnis, diese auch einsetzen zu dürfen), eigene Werbemaßnahmen und Kundenakquisition, ein unternehmerisches Risiko, projektbezogene Vergütung bzw. eine Vergütung mit Erfolgskomponente (Zahlung eines nicht unwesentlichen Anteils an der Vergütung „nach Erledigung des Auftrags“ oder „nach Abnahme“). 243

Gleichsam zwischen dem Arbeitnehmer und dem steuerlich, arbeitsrechtlich und sozialversicherungsrechtlich selbstständigen freien Mitarbeiter stehen die sog. arbeitnehmerähnlichen Personen. Sie sind zwar wirtschaftlich, aber nicht persönlich abhängig. So kann auch die Softwareentwicklung im Rahmen von Rechtsverhältnissen arbeitnehmerähnlicher Personen erfolgen, wenn zwar Selbstständigkeit in dem vorgenannten Sinne gegeben ist, die Person aber nur sehr wenige Auftraggeber hat und von diesen dementsprechend wirtschaftlich abhängig ist. Das kann bei Softwareentwicklungsprojekten des Öfteren der Fall sein, insbesondere deswegen, weil man als Auftraggeber einer bestimmten Person vertraut und diese unbedingt in Vollzeit in einem Projekt eingesetzt sehen will, z.B. als Programmierer oder als Projektleiter. Wer auf diese Weise zeitlich ausgelastet in ein- und demselben Projekt viele Monate oder gar mehrere Jahre eingesetzt ist, dürfte ohne weiteres arbeitnehmerähnliche Person im Rechtssinne sein. Folge der Einordnung als arbeitnehmerähnliche Person ist, dass verschiedene (wenige) arbeitsrechtliche Normen Anwendung finden, z.B. § 2 Satz 2 BUrlG. Hiernach haben arbeitnehmerähnliche Personen Anspruch auf den (bezahlten) gesetzlichen Mindesturlaub. Gem. § 12a TVG gelten bestimmte tarifvertragliche Rechte, Bsp.: Tarifvertrag für arbeitnehmerähnliche freie Journalistinnen und Journalisten an Tageszeitungen vom 1.8.2005. Nach § 5 Abs. 1 Satz 1 ArbGG ist das Arbeitsgericht zuständig, Entgeltfortzahlung im Krankheitsfall gibt es aus § 615 BGB, nicht anwendbar ist das EFZG.

244

Entwicklungsverträge sind ihrem Rechtscharakter nach nicht definiert. Es kann sich um Werk-, Dienst- oder gemischt-typische Verträge handeln1. Schon hieraus ergibt sich, dass das Verhältnis als „freier Mitarbeiter“ lediglich eine Abgrenzung zu abhängiger Beschäftigung darstellen kann, jedoch hierdurch keinesfalls der Rechtscharakter des Vertrages im Übrigen festgelegt ist, auch wenn „IT-Dienstleister“ sich gern als Dienstnehmer gem. §§ 611 ff. BGB sehen mit (u.a.) der Folge, dass eine Erfolgshaftung wie beim Werkvertrag nicht geschuldet ist, sondern lediglich ein Tätigwerden2. Die Einordnung hat damit erhebliche Konsequenzen hinsichtlich der Leistungspflichten und der Haftung. Maßgeblich für die Abgrenzung zwischen 1 LG Hannover v. 13.7.1998 – 20 O 200/97, NJW-RR 1999, 1655; LG Lübeck v. 29.6.2004 – unveröffentlicht, Az: 4069/04, ferner Zirkel/Schmeisser, MDR 2003, 849 ff. 2 S. oben Kap. A Rz. 177 ff. allgemein zur Abgrenzung von Werkvertrag und Dienstvertrag bei der Softwareentwicklung.

526

Gennen

Softwareentwicklung durch Dritte

Rz. 246 E

Dienst- und Werkvertrag ist die Parteivereinbarung nach ihrem wirklichen Inhalt und insbesondere gemäß der tatsächlichen Durchführung des Vertragsverhältnisses, nicht bloß nach ihrer Bezeichnung im Vertrag selbst. Fehlen ausdrückliche Vereinbarungen oder fallen vertragliche Vereinbarungen und tatsächliches Verhalten auseinander, so sind die Gesamtumstände maßgeblich, wie sie sich aus Sicht eines Dritten darstellen. Einzelumstände wie Vergütung nach Zeitaufwand oder in einer Pauschalsumme sind je einzeln nicht maßgeblich. Beide Vergütungsarten kommen bei beiden Vertragsarten vor. Auch die Nennung des Entwicklungsziels ist bei beiden Verträgen normal, allein der Grad an Verbindlichkeit bei der Erreichung desselben unterscheidet den Dienst- vom Werkvertrag. Als besonders wichtiges Indiz sieht der BGH1 es daher an, mit welcher Erfolgswahrscheinlichkeit verständige Vertragsparteien rechnen konnten. Er bemerkt aber, dass die Parteien nicht gehindert sind, auch risikoträchtige Entwicklungsverträge, bei denen die Zielerreichung keinesfalls sicher ist, als Werkverträge abzuschließen. Hier wird dann i.d.R. die Erfolgskomponente bedeutsam sein, die ausgekehrt wird, wenn das Ziel erreicht wird. 2. Konsequenz bei Statusverfehlung (Scheinselbständigkeit) Ist die beschäftigte Person nach dem tatsächlichen Erscheinungsbild in die 245 Betriebsorganisation eingegliederter abhängiger Arbeitnehmer, so steht ihr z.B. der betriebliche Kündigungsschutz nach KSchG zu und sie bekommt eine Entgeltfortzahlung im Krankheitsfall. Sie bekommt das in dem Betrieb vorgesehene, übliche Arbeitsentgelt und grundsätzlich nicht das etwa höhere Honorar. Während § 613a BGB auf den freien Mitarbeiter keine Anwendung findet, bei einem Betriebsübergang also das Beschäftigungsverhältnis nicht übergeht, geht das Arbeitsverhältnis eines Arbeitnehmers in dem von § 613a BGB gezogenen Rahmen über2. Die Konsequenzen einer fehlerhaften Einordnung eines Arbeitnehmers als 246 freier Mitarbeiter führt im Sozialversicherungs- und Steuerrecht zu komplizierten Folgen, die im Ergebnis zumeist den Dienstherrn, der sich rechtlich als Arbeitgeber herausstellt, belasten. Zunächst muss der Arbeitgeber bei Scheinselbständigkeit die Sozialversicherungsbeiträge für die Vergangenheit 1 BGH v. 16.7.2002 – X ZR 27/01, MDR 2003, 144 = NJW 2002, 3323 = CR 2003, 244 – PBC-Immunoassay – Entwicklungsauftrag an ein Forschungsinstitut für einen Immunoassay zur Diagnose von bei PBC auftretenden Antikörpern. Da die Entwicklung nicht zeitgerecht zum Erfolg kam, trat der Auftraggeber zurück und klagte auf Rückzahlung von Werklohn. Der BGH verwies zurück mit der Maßgabe für die Vorinstanz, einen Dienstvertrag ohne Erfolgsgewähr wegen der Unsicherheit des Erfolgs besonders zu prüfen. BGH v. 21.3.1961, GRUR 1996, 432 – Klebemittel: Ein Beratervertrag mit einem wissenschaftlichen Hochschulassistenten mit dem Ziel der Herstellung eines Kunstleims wurde als Dienstvertrag gewertet. 2 BAG v. 13.2.2003 – 8 AZR 59/02, NJW 2003, 2930 – Betriebsübergang.

Gennen

527

E Rz. 246

Verträge

nachentrichten und kann dabei den Arbeitnehmeranteil nach § 28g Satz 2 SGB IV nur zeitlich befristet in den nächsten drei Lohnzahlungen von dem Arbeitnehmer zurückfordern (Aufrechnung gegen die Lohnforderung)1. Die Verjährungsfrist für Nachforderungen des Sozialversicherungsträgers gegenüber dem Arbeitgeber beträgt demgegenüber vier Jahre, bei Vorsatz sogar 30 Jahre. Um die Konsequenzen einer Fehleinordnung zu vermeiden, stellt § 7a SGB IV ein Antragsverfahren bei der Deutschen Rentenversicherung Bund zur Verfügung, in dem ein Betroffener, notfalls auch ohne Zustimmung seines Vertragspartners, durch eine Anfrage die Einordnung klären lassen kann. Wird die Anfrage nicht später als einen Monat nach Tätigkeitsbeginn gestellt, so wirkt bei entsprechendem Einverständnis des Beschäftigten und wenn er ferner für den Zeitraum zwischen Aufnahme der Beschäftigung und der Bekanntgabe der Entscheidung der Deutschen Rentenversicherung Bund eine Absicherung gegen das finanzielle Risiko von Krankheit und zur Altersvorsorge vorgenommen hat, die der Art nach den Leistungen der gesetzlichen Krankenversicherung und der gesetzlichen Rentenversicherung entspricht, die Einordnungsentscheidung wirkt nicht zurück, sondern ex nunc mit Eintritt der Unanfechtbarkeit. Die Versicherungspflicht in der Sozialversicherung aufgrund einer Beschäftigung beginnt im Übrigen, wird ein Antrag erst nach Ablauf eines Monats nach Aufnahme der Beschäftigung gestellt, grundsätzlich mit dem Tag des Eintritts in das Beschäftigungsverhältnis. Die Möglichkeit einer davon abweichenden Bestimmung des Beginns der Versicherungspflicht ist nämlich bei Statusfeststellungsanträgen, die erst nach Ablauf eines Monats nach Aufnahme der Tätigkeit beantragt werden, im Zusammenhang mit dem Wegfall des § 7b SGB IV i.d.F. bis 31.12.2007 zum späteren Beginn der Versicherungspflicht bei Statusentscheidungen außerhalb eines Anfrageverfahrens nach § 7a SGB IV seit 1.1.2008 nicht mehr vorgesehen. Führt ein solcher Statusfeststellungsantrag zur Feststellung eines sozialversicherungspflichtigen Beschäftigungsverhältnisses, beginnt die Versicherungspflicht demnach mit dem Eintritt in das Beschäftigungsverhältnis. Dann ergibt sich, dass nach § 23 Abs. 1 SGB IV die Gesamtsozialversicherungsbeiträge rückwirkend spätestens am drittletzten Bankarbeitstag des Monats fällig werden, in dem die Beschäftigung, mit der das Arbeitsentgelt erzielt wird, ausgeübt worden ist (oder als ausgeübt gilt). Die Gesamtsozialversicherungsbeiträge sind demnach nachzuzahlen, wobei der unterbliebene Abzug des Arbeitnehmerbeitragsanteils, wie erwähnt, nur für die letzten drei Lohn- oder Gehaltsabrechnungen nachgeholt werden kann (§ 28g Satz 3 SGB IV). Auf die nachzuzahlenden Gesamtsozialversicherungsbeiträge werden für die Vergangenheit Säumniszuschläge erhoben (§ 24 Abs. 1 SGB IV). Derlei Folgen gilt es durch eine zutreffende Einordnung tunlichst zu vermeiden.

1 Reiser/Freckmann, Scheinselbständigkeit – heute noch ein schillernder Rechtsbegriff, NJW 2003, 180.

528

Gennen

Softwareentwicklung durch Dritte

Rz. 251 E

Wird ein freier Mitarbeiter in steuerlicher Hinsicht zu Unrecht als solcher 247 behandelt und ist er tatsächlich abhängig beschäftigter Arbeitnehmer, sind – ähnlich wie im Bereich der Sozialversicherung – Nachzahlungsansprüche die Folge sowie die Verpflichtung zur Einbehaltung und Abführung der Einkommensteuer in der Zukunft. Lohnsteuerrückstände verjähren nach vier Jahren, bei grober Fahrlässigkeit nach fünf, bei Vorsatz nach zehn Jahren. Zwar ist der Arbeitnehmer der Steuerschuldner nach § 38 Abs. 2 EStG, aber nach § 42 Abs. 1 Nr. 1, Abs. 3 Satz 1 EStG haftet der Arbeitgeber als Gesamtschuldner. Die Haftung erlischt, wenn der Arbeitnehmer seine Einkünfte ordnungsgemäß versteuert hat. War der freie Mitarbeiter tatsächlich Arbeitnehmer, der Auftraggeber damit tatsächlich Arbeitgeber, so durfte der Arbeitnehmer keine Umsatzsteuer in Rechnung stellen und der Arbeitgeber durfte diese Umsatzsteuer nicht als Vorsteuer von der eigenen Umsatzsteuer abziehen. Grundsätzlich haftet der Arbeitnehmer in Höhe der unberechtigt erhaltenen Umsatzsteuer auf Schadensersatz und nach bereicherungsrechtlichen Vorschriften. Wurde die Einstufung als freier Mitarbeiter aber vom Arbeitgeber durchgeführt, entfallen Schadenersatzansprüche regelmäßig. Problem des Bereicherungsrechts ist die Entreicherung, da der Arbeitnehmer die Umsatzsteuer regelmäßig an das Finanzamt abgeführt haben wird. Der Arbeitnehmer kann jedoch die zu Unrecht abgeführte Umsatzsteuer im Rahmen des § 14c Abs. 2 UStG zurück verlangen; hierzu ist er gegenüber dem Arbeitgeber aus vertraglichen Schadensminderungsgesichtspunkten verpflichtet. Es verbleibt dann aber jedenfalls das Insolvenzrisiko des Arbeitnehmers beim Arbeitgeber. Das Finanzamt kann gegenüber dem Arbeitnehmer den Rückzahlungsanspruch aus § 14c Abs. 2 UStG mit rückständigen Steuern verrechnen. Einstweilen frei.

248–250

3. Vertragliche Rechte und Pflichten a) Gestaltung als Dienstvertrag oder Werkvertrag Im Dienstvertrag wird nicht ein bestimmtes Ergebnis geschuldet, sondern 251 die Tätigkeit als solche, wenn auch auf das Ergebnis hin. Hierbei wird jedoch oft außer Betracht gelassen, dass auch „ein durch … Dienstleistung herbeizuführender Erfolg“ geschuldet sein kann (§ 631 Abs. 2, letzte Alt. BGB); insoweit ist die Abgrenzung zwischen Dienst- und Werkvertrag von besonderer Bedeutung. Die Vergütung wird im Dienstverhältnis entweder als Zeitvergütung oder als Pauschalvergütung, in einer Summe oder in mehreren Teilbeträgen, fällig nach Fortschrittsberichten oder anderen Parametern (jedoch i.d.R. nicht als erfolgsbezogene Parameter), vereinbart. Wenn ein Dienstvertrag vorliegt, handelt es sich bei Softwareentwicklung regelmäßig um Dienstleistungen höherer Art, also um Dienstverträge, die – vorbehaltlich abweichender Vereinbarungen – nach § 627 BGB jederzeit kündbar sind, seitens des dienstver-

Gennen

529

E Rz. 252

Verträge

pflichteten Programmierers jedoch nicht zur Unzeit. Alsdann ist für geleistete Dienste zeitanteilig bis zur Kündigung zu zahlen. 252

Wie schon angeführt, ist im Dienstvertrag nicht eine bestimmte funktionsfähige Software geschuldet sondern nur bestes Bemühen zum Erfolg nach der im Verkehr erforderlichen Sorgfalt, § 276 Abs. 2 BGB. Mit dieser Sorgfalt ist, vorbehaltlich abweichender Vereinbarungen, insbesondere auch die häufig vernachlässigte Dokumentation des Computerprogramms für die Zwecke des Auftraggebers geschuldet. Für eine schlechte Leistung haftet der Dienstverpflichtete bei vorsätzlichem oder fahrlässigem Handeln auf Schadensersatz nach § 280 BGB (Schadensersatz wegen Pflichtverletzung), wobei die Beweislast dafür, dass Vertretenmüssen nicht vorliegt, beim Auftragnehmer liegt. Der Auftraggeber hat also die Schlechtleistung zu beweisen, der dienstleistende, freie Mitarbeiter mangelndes Verschulden, § 280 Abs. 1 Satz 2 BGB.

253

Eine (insbesondere verschuldensunabhängige) Haftung für richtige und brauchbare Ergebnisse besteht nicht. Es wird lediglich tätigkeitsbezogen für bestes Bemühen gehaftet. Unsorgfältige Arbeit führt grundsätzlich nicht zur Minderung des Honoraranspruchs (lediglich eine durchgehend unbrauchbare Leistung kann ggf. dazu führen, dass bereits der Honoraranspruch entfällt), kann aber Gegenansprüche des Auftraggebers aus positiver Vertragsverletzung auslösen, §§ 276, 280 BGB. Dazu muss der Auftraggeber einen konkreten Schaden nachweisen. Nach Nachfristsetzung kann der Auftraggeber aber auch mit vergeblichen Lohnaufwendungen nach § 284 BGB aufrechnen und damit im wirtschaftlichen Ergebnis zu einer Minderung kommen. Bei mangelhafter Dienstleistung höherer Art kann auch ein Zurückbehaltungsrecht hinsichtlich der Vergütung nach § 320 BGB bestehen, wenn die Dienste quantitativ unzureichend erbracht werden, etwa bei nicht hinreichender Dokumentation des erstellten Programms.

254

Werkvertragsrecht ist demgegenüber anwendbar, wenn der freie Mitarbeiter durch seine vertraglichen Leistungen einen Erfolg im Sinne des § 631 Abs. 2 BGB schuldet1. Da im Werkvertrag nicht bloß zielgerichtete Tätigkeit, sondern der Erfolg selbst geschuldet wird, haftet der freie Softwareentwickler auf rechtzeitige Herbeiführung des vereinbarten Erfolges. Der auf konkrete neue Anwendungen gerichtete und damit ergebnisorientierte Erstellungsvertrag liegt zwar in der Richtung Werkvertrag, kann aber auch ein bloßer Dienstvertrag sein. Da viele Softwareerstellungsverträge daran kranken, dass eine vernünftige Leistungsbeschreibung nicht besteht, ist aus Sicht der Parteien oft der herbeizuführende Erfolg nur mäßig gut beschrieben, was entsprechende Probleme bei der Abnahme (§ 640 BG) aufwirft, die vonseiten des Anwenders dann aus taktischen Gründen bzw. bei unklarer Mangellage zunächst gern verweigert wird, insbesondere freien Mitarbeitern gegenüber, die rasch in wirtschaftliche Zwänge geraten. Sofern und soweit die 1 BGH v. 10.6.1999 – VII ZR 215/98, MDR 1999, 1260 = NJW 1999, 3118 – Projektsteuerungsvertrag – Anwendbarkeit von Werkvertragsrecht.

530

Gennen

Softwareentwicklung durch Dritte

Rz. 258 E

Leistung nicht beschrieben ist, wird eine Leistung von mittlerer Art und Güte nach dem Stand der Technik geschuldet, also etwas, was bei Auseinandersetzungen bisweilen erst im Nachhinein durch einen gerichtlich bestellten Sachverständigen festgestellt wird. Der Werkvertrag kann nach § 649 BGB vonseiten des Bestellers jederzeit 255 vor Vollendung des Werkes gekündigt werden. Kündigt der Besteller, so ist der Unternehmer berechtigt, die vereinbarte Vergütung zu verlangen. Er muss sich jedoch dasjenige anrechnen lassen, was er infolge der Aufhebung des Vertrags an Aufwendungen erspart oder durch anderweitige Verwendung seiner Arbeitskraft erwirbt oder zu erwerben böswillig unterlässt. Nach § 649 Satz 3 BGB besteht die (widerlegliche) Vermutung, dass dem Unternehmer lediglich 5 % der auf den im Zeitpunkt der Kündigung noch nicht erbrachten Teil der Werkleistung entfallenden vereinbarten Vergütung zustehen – das ist nicht viel. Da beim Werkvertrag der Erfolg geschuldet ist, sind Leistungspflichten und 256 Haftung ungleich rigider als beim Dienstvertrag. Der werkvertraglich tätige freie Mitarbeiter haftet insbesondere: – wegen Verzugs mit der Leistung (Fertigstellung des geschuldeten Computerprogramms und/oder der geschuldeten Dokumentation) nach §§ 323, 281 BGB, – auf Mangelfreiheit nach §§ 633 ff. BGB, – oder, wenn eine neue Sache, z.B. eine Maschinensteuerung herzustellen ist, nach §§ 651, 432 BGB (früher: Werklieferungsvertrag mit Verweisung in das Kaufrecht). Mitwirkungspflichten des Auftraggebers (Obliegenheiten) und die Folgen bei Nichterbringung sind ausdrücklich normiert, §§ 642, 643 BGB. Im Werkvertragsrecht kommen Vergütungsregelungen sowohl als Zeit- wie 257 auch als Pauschalvergütung vor, zahlbar in einer Summe oder in fortschrittsabhängigen („Meilensteine“ in Form von in sich abgeschlossenen und funktionierenden Leistungspaketen/ggf. nach Teilabnahme) Teilbeträgen. Sie wird, teils offen, teils verdeckt, i.d.R. kalkuliert als Vollkostenerstattung mit Gewinnaufschlag für die Entwicklung selbst, oder sie wird als Teilkostenerstattung für die Entwicklung mit einem Amortisationsaufschlag bei späterer Lieferung bei Subunternehmern vereinbart, die teils fest verabredet ist, teils als Chance in Aussicht gestellt ist. b) Rechtsübertragung Zu unterscheiden sind die Rechte am materiellen Ergebnis und am immate- 258 riellen. Das materielle Ergebnis ist das Eigentum an der Verkörperung in einer Sache, z.B. die ausgedruckte Version einer Dokumentation, das Computerprogramm oder der Prototyp einer Maschinensteuerung; das immaterielle Ergebnis ist das Nutzungs- und Verwertungsrecht, bezogen auf Ausschlie-

Gennen

531

E Rz. 259

Verträge

ßungsrechte (technische Schutzrechte, Urheberrechte) und/oder geheimes technisches/fachliches Wissen (Know-how). aa) Das materielle Ergebnis 259

Eine entwickelte Sache bzw. der Gegenstand, in dem sich das Ergebnis materialisiert, steht im Zweifel auch ohne besondere Abrede dem Auftraggeber, d.h. dem Dienstgeber (§§ 611 ff. BGB) bzw. dem Besteller (§§ 631, 651, 433 BGB) zu. Für den Werklieferungsvertrag gilt auch die kaufmännische Untersuchungsund Rügepflicht, und zwar schon für den Prototypen1.

260

Bei der Softwareentwicklung besteht ein besonderes Problem hinsichtlich des Quellcodes des Computerprogramms. Entwickelt der freie Mitarbeiter ein Programm, das aus seiner Sicht Standardsoftware im Verhältnis zum Auftraggeber ist, entspricht es der einhelligen Meinung, dass ohne besondere, ausdrückliche oder sich aus den Umständen ergebende Vereinbarung die Übergabe des Quellcodes nicht geschuldet ist. Bei im Auftrag entwickelter Individualsoftware hängt es von den Umständen ab, ob dem Auftraggeber auch die Übergabe des Quellcodes geschuldet ist. Nach Ansicht des BGH soll der Preis dabei eine Rolle spielen, insbesondere aber, ob der Auftraggeber den Quellcode für Kundenanpassungen im Weitervertrieb benötigt2. Vielfach werden einzelne freie Mitarbeiter auch in Konstellationen eingesetzt, in denen der Auftraggeber ein ursprünglich im eigenen Haus erzeugtes, intern genutztes Computerprogramm, dessen Programmierer das Unternehmen verlassen haben, weiter warten und pflegen muss oder zu dem Anpassungen zu programmieren sind. Hier wird man von der Überlassung des Quellcodes auch ohne besondere Vereinbarung ausgehen können. Ist die Überlassung einer Wartungsdokumentation vereinbart, so schließt das nach OLG Karlsruhe auch die Überlassung des Quellcodes mit ein3. Zumeist wird aber der Auftraggeber, um sich künftig nicht abhängig zu machen von der Verfügbarkeit einer einzelnen Person, die Herausgabe des Quellcodes ausdrücklich vereinbaren. bb) Das immaterielle Ergebnis

261

Das immaterielle Leistungsergebnis kann bestehen in Know-how für den Nachbau oder die Anwendung, in urheberrechtlichen Nutzungs- und Verwertungsrechten, insbesondere bei entwickelter Software, oder in Rechten auf oder aus technischen Erfindungen bzw. Patenten für die Software. Nach 1 OLG München v. 11.3.1998 – 7 U 2964/97, MDR 1998, 978 = NJW-RR 1999, 331 – Versäumte Rügepflicht bei einem Vorserienmuster bei der Entwicklung eines Datenerfassungssystems. 2 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 = NJW-RR 2004, 782 – von einem Rechenzentrum für seine Genossenschafsbanken bestelltes Individualprogramm, ähnlich auch LG Köln v. 3.5.2000 – 20 S 21/99, CR 2000, 505. 3 OLG Karlsruhe v. 4.5.1999, CR 1999, 11.

532

Gennen

Softwareentwicklung durch Dritte

Rz. 264 E

deutscher und in Europa wohl ziemlich einheitlicher Auffassung entstehen alle diese geistigen Eigentumsrechte zunächst in der oder den Person(en), die als Individuen das jeweilige Werk geschaffen haben (Schöpferprinzip). In welchem Ausmaß und mit welcher Exklusivität – nicht zuletzt gegenüber dem Werkschöpfer selbst – sie auf den Auftraggeber der Entwicklung übergehen, ist eine komplexe Materie. Das erarbeitete Know-how muss der freie Mitarbeiter, sofern und soweit es 262 in der hergestellten Sache bzw. im Werk verkörpert ist, dem Dienstherrn aufgrund des Dienstverhältnisses bzw. dem Besteller des Werkes zugänglich machen und zur Verfügung stellen. Soweit es sich um darüber hinaus gehendes Know-how handelt, wird man, soweit nicht eine besondere Vereinbarung vorliegt, in Anlehnung an die urheberrechtliche Zweckübertragungslehre von einer stillschweigenden Einräumung einfacher Nutzungsrechte für diejenigen Anwendungszwecke ausgehen können, die der Dienstherr/Besteller mit dem Gegenstand nach Sinn und Zweck des Vertrages typischerweise auszuführen pflegt. Technische Erfindungen des freien Mitarbeiters unterliegen nicht dem nur 263 auf Arbeitnehmer und Beamte anwendbaren Gesetz über Arbeitnehmererfindungen1. Seine Erfindungen gehören daher im Grundsatz ihm. Sie können aber ausdrücklich oder implizit vertraglich auf den Auftraggeber übertragen sein (dingliche Vorausabtretungsregelung) oder werden (Abtretung im Nachhinein als gesonderter Rechtsakt) oder es können dem Auftraggeber ausschließliche oder einfache Nutzungsrechte eingeräumt sein. Dabei sind Beschränkungen der Rechtseinräumung in vielerlei Hinsicht denkbar, insbesondere mit Blick auf die räumliche und zeitliche Ausdehnung oder auch mit Blick auf bestimmte Einsatzzwecke (Field-of-Use-Beschränkung). Wird insoweit keine ausdrückliche Abrede getroffen und liegen auch sonst keine besonderen Umstände vor, gelten nach Ansicht des BGH in Entwicklungsverträgen die in Rz. 262 beschriebenen Grundsätze entsprechend: Der Auftraggeber erhält lediglich ein einfaches Nutzungsrecht für die nach dem Vertrag vorausgesetzten Zwecke. Verträge über vom Auftraggeber vollständig bezahlte Entwicklungen wer- 264 den überwiegend einseitig vom Auftraggeber vorgegeben (i.d.R. AGB des Auftraggebers), was zur Folge hat, dass sich der Auftraggeber dort die dingliche Übertragung von technischen Erfindungen und die Einräumung sachlich sehr weitgehender ausschließlicher Nutzungsrechte an Urheberrechten, die aus der Entwicklung resultieren, ausbedingt, i.d.R. verbunden mit dem Recht der Weiterübertragung und Unterlizenzierung2. Wenn man davon ausgeht, dass i.d.R. trotz vollständiger Bezahlung einer Entwicklung 1 Allgemein vgl. Bartenbach/Volz, § 1 ArbEG Rz. 44. 2 BMBF, Allgemeine Bestimmungen für Forschungs- und Entwicklungsverträge der Zuwendungsempfänger (BMBF-ZE 98), § 11 Rechte des AG am Arbeitsergebnis; BGH v. 9.5.1985 – I ZR 52/83, MDR 1986, 121 = CR 1985, 22 = GRUR 1985, 1041 = BGHZ 94, 279 – Inkassoprogramm – vertragliche Enthaltungspflicht des

Gennen

533

E Rz. 265

Verträge

durch den Auftraggeber diesem ohne eine besondere Abrede lediglich ein einfaches Nutzungsrecht zusteht, kann die AGB-rechtlich herbeigeführte vollständige Rechtsübertragung ggf. kritisch sein. Eine vollständige Rechtsübertragung steht i.d.R. nicht im Interesse des freien Mitarbeiters, der die gezeigte Leistung gern in späteren, ähnlichen Projekten mit anderen Auftraggebern wieder zu verwenden gedenkt bzw. im Laufe der Zeit aus den verschiedenen gleichartigen Lösungen, die er in Projekten erarbeitet hat, eine Standardlösung zum Vertrieb an Dritte entwickeln könnte („vom Projekt zum Produkt“). 265

Wenn der Auftraggeber nur einen Zuschuss zu den Entwicklungskosten leistet, was beim selbst industriell tätigen freien Mitarbeiter als Subunternehmer der (eher seltene) Fall sein kann, verbleiben meist die Schutzrechte beim Entwickler. Dieser räumt dem Auftraggeber eine einfache Lizenz ein oder fertigt für ihn, um aus den Lizenzgebühren oder Fertigungslöhnen die restlichen Entwicklungskosten zu amortisieren. Außerdem darf der Entwickler aufgrund seiner Rechtsinhaberschaft Dritte beliefern oder an Dritte lizensieren, entweder frei oder gemäß vertraglichen Bestimmungen lediglich eingeschränkt (z.B. nicht für Anwendungsfälle des Erstauftraggebers). Eine solche Field-of-use-Beschränkung dürfte kartellrechtlich zulässig sein: es handelt sich zwar um eine Wettbewerbsbeschränkung für den Entwickler nach Art. 101 Abs. 1 AEUV, sie fällt aber unter die GVO-FuE1 Art. 1 (1) lit. a (iii) (Gemeinsame Forschung und Entwicklung von Produkten oder Verfahren ohne gemeinsame Verwertung) und genügt der Freistellungsbedingung Art. 3 GVO-FuE: das freie Verwertungsrecht jedes Partners darf auf einzelne Anwendungsbereiche beschränkt werden, wenn die Vertragsparteien keine Konkurrenten sind. Im vertikalen Auftragsverhältnis sind sie das selten.

266

Einstweilen frei.

267

Ist keine ausdrückliche Vereinbarung getroffen, so ist es der Grundsatz, dass im Zweifel die Erfinder- und Urheberrechte beim Erfinder verbleiben und er nicht mehr überträgt, als er ausdrücklich vergibt oder als es dem Geschäftszweck entspricht. Dies ist Kern der Zweckübertragungstheorie nach § 31 Abs. 5 UrhG2. Eine im Entwurf der EG-Softwareschutzrichtlinie in Art. 2 Abs. 2 früher enthaltene Bestimmung, dass die Nutzungsrechte auch im freien Entwicklungsauftrag im Zweifel dem Auftraggeber zustehen, ist fallen gelassen worden.

Programmentwicklers aus Äußerungen bei Vertragsschluss, das Programm gehöre ausschließlich dem Auftraggeber. 1 Verordnung (EU) Nr. 1217/2010 der Kommission vom 14. Dezember 2010 über die Anwendung von Artikel 101 Absatz 3 des Vertrags über die Arbeitsweise der Europäischen Union auf bestimmte Gruppen von Vereinbarungen über Forschung und Entwicklung (Amtsblatt Nr. L 335 vom 18/12/2010 S. 0036–0042). 2 Zur Parallelwertung bei Know-how und technischen Erfindungen bzw. Nutzungsrechten hieran s. Rz. 262 bzw. 263.

534

Gennen

Softwareentwicklung durch Dritte

Rz. 270 E

Ob ohne ausdrückliche Vereinbarung eine Übertragung oder ausschließ- 268 liche Nutzungsrechtseinräumung stattgefunden hat, ist eine Auslegungsfrage. Die bei Softwareentwicklung vonseiten des Auftraggebers oft geäußerte Meinung, bei der Auftragsentwicklung gebührten dem Auftraggeber die ausschließlichen Rechte am Arbeitsergebnis und mithin auch an Computerprogramm und Dokumentation1, erscheint so allgemein nicht richtig. Es bedarf dafür vielmehr einer ergänzenden Vertragsauslegung unter Berücksichtigung aller Umstände, insbesondere dem Verwendungszweck aufseiten des Auftraggebers, die Eigenfertigungsmöglichkeit des Entwicklers2, der Vergütungshöhe3, wobei es insbesondere relevant ist, ob die Entwicklungskosten voll bezahlt sind oder ob es sich um ein teilvergütetes oder gar nicht vergütetes Pilotprojekt handelt, das sich erst im weiteren Vertrieb amortisieren muss. Ferner ist der Aufgaben- und Pflichtenkreis des freien Mitarbeiters wichtig4, insbesondere ob auch mit erfinderischen Leistungen zu rechnen war5. Ein erheblicher Faktor ist auch, ob die Leistung zur Nutzung seitens des Auftraggebers in Geschäften mit Dritten bestimmt war, denn solche sind gegenüber Durchkreuzung mit Konkurrenzerzeugnissen besonders absicherungsbedürftig, oder nur innerbetrieblich6. Anhaltspunkte bieten auch die bisherigen vertraglichen Vereinbarungen und Handhabungen7. Auf jeden Fall wird dem Auftraggeber – schon mit der Zweckübertragungs- 269 lehre – ein einfaches Nutzungsrecht für die nach dem Vertrag vorausgesetzten Zwecke eingeräumt, weil er sonst ein patent- oder urheberrechtsgeschütztes Entwicklungsergebnis gar nicht nutzen könnte8. In ergänzender Vertragsauslegung kommen auch nach verschiedentlich ver- 270 tretener Meinung fallweise nachvertragliche Enthaltungspflichten nach §§ 241 Abs. 2, 242 BGB für eine begrenzte Zeitdauer in Betracht. Sie können dann ausschließliche Nutzungsrechte bzw. die Ausschließlichkeit an leicht entstehenden Schutzrechten mit überlanger Schutzfrist (70 Jahre pma.) ersetzen. Da ein solcher Schutz auch gegen Eigenplagiate wirkt, d.h. für Fälle, in denen der inhaltsorientierte Autor, der aus Gründen der Arbeitsökonomie bei Neuprogrammierung einer fachlichen Lösung dazu neigen wird, ein strukturgleiches oder stark strukturähnliches Programm zu schaffen und demnach sein erstes Werk unbewusst unfrei nach § 23 UrhG zu bearbeiten, würde der freie Mitarbeiter bei Einräumung ausschließlicher 1 So auch OLG Frankfurt v. 24.6.1994 – 6 W 77/94, NJW-RR 1995, 684 = CR 1995, 81 – Schriftformerfordernis bei Softwareerstellungsverträgen. 2 BGH v. 9.5.1985, GRUR 1985, 1041/1043 – Inkassoprogramm. 3 BGH v. 24.6.1952, GRUR 1953, 29 – Plattenspieler. 4 BGH GRUR 1953, 29 – Plattenspieler. 5 BGH v. 21.3.1961, GRUR 1961, 432/435 – Klebemittel. 6 LG Karlsruhe v. 7.12.1989, CR 1990, 592 – Mitgenommene Programme und Wettbewerb: was der freie Mitarbeiter für seinen Auftraggeber schafft und wofür er bezahlt wird, darf er nicht gegen ihn vermarkten. 7 LG Aschaffenburg v. 6.12.1997, CR 1998, 203 – Herausgabe des Quellcodes. 8 BGH GRUR 1953, 29 – Plattenspieler.

Gennen

535

E Rz. 271

Verträge

Nutzungsrechte seine Schaffensfreiheit auf seinem Fachgebiet gegen Null reduzieren. Stattdessen ist die Einräumung einfacher Nutzungsrechte, verbunden mit einer begrenzten nachvertraglichen Enthaltungspflicht, als sachgerecht anzunehmen. In den meisten Fällen wird eine Enthaltungspflicht, entsprechend den relativ kurzen Pflegezyklen bei Software, bei zwei bis maximal vier Jahren liegen. Diese nachvertragliche Enthaltungspflicht würde nur bei einem identischen oder eng angelehnten Nachschaffen greifen, nicht aber bei einer freien Leistung zum gleichen oder besseren Ergebnis. Einen Kompromiss aus Sicht beider Vertragspartner zur Vermeidung des Rückgriffs auf solche, alles andere als unumstrittenen, nachvertraglichen Enthaltungspflichten stellt ggf. eine zeitlich begrenzte Ausschließlichkeit von Nutzungsrechten dar, nach deren Ablauf sich die ausschließlichen Nutzungsrechte ohne weitere Erklärung in einfache Nutzungsrechte umwandeln. cc) Vergütung für die Rechteübertragung 271

Bei Entwicklung von Software durch freie Programmierer gilt § 69b UrhG nicht, wonach die Nutzungsrechte grundsätzlich ausschließlich dem Arbeitgeber ohne weitere Vergütung zustehen. Der Auftraggeber muss vielmehr die Nutzungsrechte erwerben. In der Regel vereinbart er, wenn er die Vertragsgestaltung allein in der Hand hat, eine vertragliche Vorauseinräumung der ausschließlichen Nutzungsrechte, abgegolten mit dem vereinbarten Entgelt. Wenn insoweit eine gesonderte Vergütung für das immaterielle Leistungsergebnis bzw. für die Übertragung oder Einräumung von Nutzungsrechten nicht vereinbart ist und auch sonst keine Abreden bestehen, ist zunächst anzunehmen, dass die Vergütung hierfür im Entgelt enthalten sein soll, also eine gesonderte Vergütung nicht geschuldet ist. Das gilt im Zweifel auch dann, wenn im Hinblick auf technische Erfindungen eine Vollrechtsübertragung stattfindet und im Hinblick auf urheberrechtlich geschützte Arbeitsergebnisse eine ausschließliche Rechteübertragung stattfindet. Eine solche Abrede wird sich jedoch an § 32 UrhG messen lassen müssen, kann aber i.d.R. jedenfalls dann als wirksam angesehen werden, wenn das Programmierentgelt nach allen Umständen der redlichen Üblichkeit entspricht, insbesondere die Honorarsätze für die Aufwandsprogrammierung bzw. die Gesamtvergütung nicht nennenswert hinter dem zurückbleiben bzw. -bleibt, was branchenüblich ist. Bezogen auf eine etwaige Übertragung technischer Erfindungen auf dinglicher Ebene ist Wirksamkeitsvoraussetzung für die (Voraus-)Abtretung grundsätzlich nicht, dass hierzu eine besondere Vergütung vereinbart ist. Ist die vereinbarte Vergütung nach § 32 UrhG unangemessen, so kann der Programmierer Auffüllung auf die volle angemessene Vergütung verlangen, nicht nur den Betrag, der die Unangemessenheit gerade eben beseitigt1. Bei der Angemessenheit steht die redliche Geschäftsüblichkeit nach § 32 Abs. 2 Satz 2 UrhG im Vordergrund. 1 BGH v. 21.6.2001, GRUR 2002, 153 – Kinderhörspiele.

536

Gennen

Softwareentwicklung durch Dritte

Rz. 273 E

Ergibt die Auslegung des Vertrages, dass eine sehr weit gehende Rechtsübertragung nicht geschuldet ist, sondern sich die eingeräumten Rechte eher knapp bemessen oder nur Rechte entsprechend den vorstehend erläuterten Grundsätzen der Zweckübertragungslehre übertragen worden sind, kann der freie Mitarbeiter für eine etwaige nachträgliche Ausweitung solcher Rechte eine gesonderte angemessene Vergütung verlangen. Ist eine gesonderte Vergütung für eine Rechteübertragung, gleich ob für die 271a ursprüngliche Rechteeinräumung oder für etwaige Erweiterungen, zwar dem Grunde nach vereinbart, ist die Vergütungshöhe aber offen geblieben, so kann der freie Mitarbeiter nach den Rechtsgrundsätzen der §§ 32 UrhG, 612, 316, 315 BGB für schöpferische Leistungen im Rahmen des Auftragsverhältnisses eine angemessene Vergütung bestimmen und fordern, die sich, was technische Erfindungen betrifft, nach der Bedeutung der Leistung und nach dem mit dem Ergebnis erzielten Umsatz richtet1. War die technische Erfindung eine außerhalb des Rahmens liegende Zusatzleistung, so kann der Mitarbeiter eine angemessene Sondervergütung nach §§ 612, 632 BGB verlangen, wenn sie dem Auftraggeber eine wertvolle Bereicherung gebracht hat2. Neben der Vergütung für die ursprüngliche Rechteeinräumung nach § 32 272 UrhG steht der im Voraus nicht verzichtbare Anspruch nach § 32a UrhG für den Fall, dass der Auftraggeber unter Einsatz der eingeräumten Rechte erhebliche, nicht absehbare Gewinne bzw. Vorteile erzielt, an denen der Urheber nach der ursprünglichen Vergütungsregelung nicht beteiligt ist, wie das bei einer Pauschalabgeltung durch Aufwandsvergütung auch der Fall ist. An diesen Vorteilen ist der Urheber ebenfalls zu beteiligen. Eine Parallelregelung hierzu im Bereich der technischen Schutzrechte besteht insoweit nicht, daher wird man ggf. mit der Störung der Geschäftsgrundlage argumentieren können. Dies gilt naturgemäß nicht, wenn die Vergütung für die Rechtseinräumung im Hinblick auf die technischen Erfindungen eine umsatzbezogene Lizenz und keine Pauschalvergütung war. c) Geheimhaltung Auch wenn und sofern der freie Mitarbeiter das zu seiner Werk- oder 273 Dienstleistung gehörige Know-how dem Auftraggeber zur Verfügung stellen muss, so gilt doch andererseits für ihn, dass er das, was er an eigenem Know-how im Kopf hat, im Allgemeinen frei mit sich tragen und nachvertraglich frei verwerten kann3. An der freien Verwertung ist er gehindert bei einem wirksamen Wettbewerbsverbot nach §§ 74 ff. HGB, das auch beim 1 BGH v. 21.3.1961, GRUR 1961, 432 – Klebemittel, mit Anm. Schippel. 2 BGH v. 13.7.1956, GRUR 1956, 500 – Capysal. 3 BAG v. 15.6.1993, BB 1994, 1078 = ZiP 1994, 642; BAG AP Nr. 1 zu § 611 Betriebsgeheimnis; BGH v. 21.12.1962, GRUR 1963, 367 – Industrieböden; BGH v. 3.5.2001, GRUR 2002, 91 – Spritzgießwerkzeuge.

Gennen

537

E Rz. 274

Verträge

freien Mitarbeiter entschädigungspflichtig ist, wenn er wirtschaftlich abhängig ist, was insbesondere sein kann, wenn er vollzeitig tätig ist1. Möglich sind auch punktuelle Geheimhaltungsvereinbarungen ohne Entschädigungspflicht. Eine implizite punktuelle Geheimhaltung bringt die verschiedentlich vertretene, begrenzte nachvertragliche Enthaltungspflicht mit sich, vgl. oben Rz. 270. Wie beim abhängigen Arbeitnehmer gilt ferner als Grenze § 3 UWG und § 17 UWG, wenn der Mitarbeiter verkörperte Know-how-Unterlagen zur nachvertraglichen Verwertung mitnimmt2. Insoweit ist darauf zu achten, dass auch während der Beschäftigung redlich erlangte Informationen, die der freie Mitarbeiter auf seinem Rechner speichert, nach Beendigung des Beschäftigungsverhältnisses Informationen sind, bei deren Benutzung § 17 UWG verwirklicht werden kann, weil die Rechtsprechung auch im Nachhinein erfolgende Entnahmen sanktioniert3. Unlauter und auch ein Verstoß gegen § 18 UWG – Vorlagenfreibeuterei – wäre die Mitteilung oder Verwertung von Auftraggeber-Know-how. Bei Verwendung eines unter Verstoß gegen § 17 UWG erlangten Know-hows ist grundsätzlich der gesamte Verletzergewinn herauszugeben d) Konkurrenzverbot 274

Der wirtschaftlich abhängige freie Mitarbeiter unterliegt im Allgemeinen keinem Konkurrenzverbot, wenn ein solches nicht mit Karenzentschädigung nach §§ 74 ff. HGB mit ihm vereinbart worden ist4. Bei voll bezahlter Softwareentwicklung kann allerdings der Umstand nicht außer Betracht bleiben, dass Software ein leicht reproduzierbares Gut ist und der Quellcode regelmäßig ein wertvolles Betriebsgeheimnis darstellt. Diese Leistung für den ersten Auftraggeber würde der Mitarbeiter stark entwerten, wenn er sie alsbald in gleicher Form oder unter Nutzung wesentlicher Teile auch für Dritte erbringen dürfte. Mit der verschiedentlich vertretenen, zeitlich begrenzten nachvertraglichen Enthaltungspflicht, vgl. oben Rz. 270, ist daher ein gewisses Konkurrenzverbot auch ohne Entschädigung verbunden; diese Enthaltungspflicht stand aber noch nicht auf dem Prüfstand der Rechtsprechung der Obergerichte.

1 BAG v. 15.6.1993, NZA 1994, 502; BGH v. 10.4.2003 – III ZR 196/02, CR 2005, 254 – Übertragbarkeit der für kaufmännische angestellte geltenden Wettbewerbsregeln auf freie Mitarbeiter (Subunternehmer); OLG Düsseldorf v. 21.1.1997, NJW-RR 2005, 119. 2 BGH NJW-RR 2003, 618 – Präzisionsmessgeräte; BGH v. 18.2.1977, GRUR 1977, 539 – Prozessrechner. 3 BGH v. 19.3.2008 – I ZR 225/06, NJOZ 2009, 301; vgl. auch BGH v. 23.2.2012 – I ZR 136/10, MDR 2012, 1240 = GRUR 2012, 1048 – MOVICOL-Zulassungsantrag. 4 BAG v. 21.1.1997, NJW 1998, 99; BGH v. 10.4.2003 – III ZR 196/02, CR 2005, 254 – Übertragbarkeit der für kaufmännische angestellte geltenden Wettbewerbsregeln auf freie Mitarbeiter (Subunternehmer).

538

Gennen

Softwareentwicklung durch Dritte

Rz. 279 E

4. Leistungsstörungen Im Rahmen der Ansprüche wegen Leistungsstörungen ist zwischen den ver- 275 schiedenen Vertragsformen zu unterscheiden, unter denen eine freie Mitarbeit begründet werden kann. Üblicherweise wird der Vertrag des freien Mitarbeiters als Dienstvertrag abgegrenzt vom Arbeitsvertrag des abhängig beschäftigten Arbeitnehmers. Begreift man unter einem „freien Mitarbeiter“ jedoch auch, wie dies in der betrieblichen Praxis vielfach geschieht, rechtsuntechnisch alle Einzelpersonen, die nicht in abhängiger Beschäftigung stehen, also weder Arbeitnehmer noch arbeitnehmerähnliche Personen sind, dann kann auch ein Werkvertrag in Betracht kommen. a) Leistungsstörungen im Dienstvertrag Es sind hier als Leistungsstörungen auf Seiten des Auftraggebers vor allem 276 der Verzug mit der Zahlung der vereinbarten Vergütung nach §§ 611, 280 Abs. 1, 283 ff. BGB in Betracht zu ziehen, der dem freien Mitarbeiter zum einen Schadensersatzanspruch für alle ihm während des Verzugs entstandenen Schäden, zum anderen aber auch ein Zurückbehaltungsrecht an seiner Arbeitsleistung gewährt. Weiterhin sind der Annahmeverzug des Auftraggebers und eine Verletzung von nebenvertraglichen Pflichten denkbar, die dem freien Mitarbeiter wiederum einen Schadensersatzanspruch zugestehen. Die besonderen Regelungen der §§ 8, 104 SGB VII geltend im Rahmen einer freien Mitarbeit nicht. Als durch den freien Mitarbeiter verursachte Leistungsstörungen kommen 277 wiederum die Nicht- oder die Schlechtleistung in Betracht. Bei einer von dem freien Mitarbeiter zu vertretenden Unmöglichkeit verliert dieser seinen Vergütungsanspruch nach §§ 611, 275 Abs. 4, 326 Abs. 1 BGB, bzw. §§ 611, 275 Abs. 4, 326 Abs. 1, Satz 1 i.V.m. § 441 Abs. 3 BGB. Daneben kann er sich auch nach §§ 611, 275 Abs. 4, 280 Abs. 1, 283 BGB schadensersatzpflichtig machen. Der Umfang des dem Auftraggeber zustehenden Schadensersatzanspruchs bestimmt sich in diesen Fällen wiederum nach den §§ 249 ff. BGB. Arbeitet der freie Mitarbeiter in zu vertretender Weise, also vorsätzlich oder 278 fahrlässig (§ 276 Abs. 1 BGB), schlecht, steht dem Auftraggeber ein Schadensersatzanspruch zu (§§ 280 ff. BGB); denkbar ist auch eine Aufrechnung der Vergütungszahlung mit dem Schadensersatzanspruch. Insoweit ist dem Dienstvertragsrecht eine Nachbesserung fremd. Arbeitet der freie Mitarbeiter unverschuldet schlecht, bestehen Schadensersatzansprüche nicht. b) Leistungsstörungen im Werkvertrag Der Werkunternehmer ist bei einem Werkvertrag nach § 633 BGB verpflichtet, die Software frei von Mängeln herzustellen. Ein Mangel liegt nach § 633 Abs. 2 BGB vor, wenn die Software nicht die vereinbarte Beschaffenheit hat.

Gennen

539

279

E Rz. 280

Verträge

Soweit die Beschaffenheit nicht vereinbart ist, ist das Werk frei von Sachmängeln, wenn es sich für die nach dem Vertrag vorausgesetzte, sonst für die gewöhnliche Verwendung eignet und eine Beschaffenheit aufweist, die bei Werken der gleichen Art üblich ist und die der Besteller nach der Art des Werks erwarten kann. Ein typischer Mangel von Software kann bspw. die Inkompatibilität mit anderen, bei dem Auftraggeber bzw. Besteller bereits vorhandenen Softwarekomponenten oder eine Virenverseuchung sein. Es ist auch möglich, dass die Software nicht ablauffähig ist, d.h. in sich nicht funktioniert, oder dass vereinbarte Funktionalitäten nicht vorhanden sind. Neben solchen Sachmängeln sind auch Rechtsmängel, bspw. das Bestehen von Rechten Dritter an der Software, denkbar. 280

Vor der Abnahme ist die Vertragsgemäßheit der Software im Zweifel vom Werkunternehmer zu beweisen. Liegt bei der Abnahme ein Mangel vor, so wird die Abnahme der Software nach § 640 BGB nicht erteilt. Eine Zahlungspflicht besteht bei einer berechtigten Abnahmeverweigerung nicht (§ 641 Abs. 1 Satz 1 BGB). Entspricht die Software nicht der vertraglichen Vereinbarung, kann der Besteller auch nach §§ 634 Nr. 1, 635 BGB Nacherfüllung verlangen, sofern seinen Interessen durch eine Nachbesserung Genüge getan wird. Reicht eine Nacherfüllung nicht aus, kann der Besteller auch Erfüllung durch die Herstellung einer neuen Software verlangen.

281

Hat der Besteller die Software bereits nach § 640 Abs. 1 BGB abgenommen, bleibt zwar sein Anspruch auf mangelfreie Herstellung der vertraglich vereinbarten Software erhalten. Sein Erfüllungsanspruch wird aber dahingehend modifiziert, dass er grundsätzlich nur noch Nacherfüllung nach §§ 634 Nr. 1, 635 BGB, aber nicht mehr Neuherstellung verlangen kann. Dem Werkunternehmer steht insofern nach § 635 Abs. 1 BGB ein Wahlrecht zu, ob er die Nacherfüllung durch Nachbesserung oder Neuherstellung bewirken möchte. Der Besteller kann nach §§ 634 Nr. 2, 637 Abs. 1 BGB auch dem Werkunternehmer eine angemessene Frist zur Nacherfüllung bestimmen und bei erfolglosem Ablaufen dieser Frist den Mangel selbst beseitigen und Ersatz der erforderlichen Aufwendungen verlangen. Die Erforderlichkeit der Aufwendungen bestimmt sich nach der Rechtsprechung des BGH danach, ob ein vernünftiger, wirtschaftlich denkender Mensch aufgrund sachkundiger Beratung oder Feststellung die tatsächlichen Aufwendungen des Bestellers aufgewendet hätte1. Nach § 637 Abs. 3 BGB ist der Besteller auch berechtigt, einen Vorschuss zu verlangen.

282

Grundsätzlich kann der Besteller den Rücktritt vom Vertrag erklären oder Minderung nur verlangen, wenn er dem Werkunternehmer eine Frist zur Nachbesserung gesetzt hat und diese erfolglos abgelaufen ist. Unter den Voraussetzungen der §§ 636, 281 Abs. 1, 323 Abs. 2, 326 Abs. 5 BGB kann unter Umständen auf eine solche Fristsetzung verzichtet werden, ebenso bei einer Weigerung, eine Nachbesserung vorzunehmen, § 635 Abs. 3 BGB, wenn eine Nachbesserung fehlgeschlagen ist oder aber das Vertrauen des 1 BGH v. 31.1.1991 – VII ZR 63/90, MDR 1991, 970 = NJW-RR 1991, 789 ff.

540

Gennen

Softwareentwicklung durch Dritte

Rz. 287 E

Softwarebestellers infolge berechtigter Zweifel an der Leistungsfähigkeit und Zuverlässigkeit des Werkunternehmers erschüttert ist1. Gleiches gilt, wenn der Besteller das Werk sofort benötigt und ein Abwarten eine nicht unerhebliche Störung für ihn darstellen würde2. Rücktritt und Minderung müssen dem Werkunternehmer gegenüber erklärt 283 werden. Bei einem Rücktritt wandelt sich das Schuldverhältnis in ein Rückgewährschuldverhältnis um; Besteller und Werkunternehmer haben sich Zug um Zug die bereits erbrachten Leistungen (evtl. gezahlte Vergütung gegen die mangelhafte Software) zurückzugewähren. Neben dem Rücktritt kann nach § 325 BGB Schadensersatz geltend gemacht werden, alle anderen Mangelhaftungsrechte des Bestellers erlöschen. Ausschlussgründe für ein Rücktrittsrecht des Bestellers finden sich in §§ 323 Abs. 5 und 6, 640 Abs. 2 BGB. Das Minderungsrecht kann im Gegensatz zum Rücktritt zwar auch bei unerheblichen Mängeln ausgeübt werden, jedoch erlöschen daneben alle weiteren Mangelhaftungsansprüche.

284

Der Besteller kann einen Schadensersatzanspruch nach §§ 634 Nr. 4, 636, 285 280, 281, 283, 311a geltend machen oder nach § 284 Ersatz vergeblicher Aufwendungen verlangen. Beides setzt jedoch das Vorliegen von Verschulden voraus, § 280 Abs. 2 BGB. Der Verschuldensmaßstab bestimmt sich nach § 276 Abs. 2 BGB. Da die Herstellung einer mangelhafte Software eine Pflichtverletzung nach § 280 BGB darstellt, kann der Besteller als Schadensersatz alle kausal auf dieser Pflichtverletzung beruhenden Mängel geltend machen, einer Unterscheidung in Mangel- und Mangelfolgeschäden bedarf des demnach nicht. Die Gewährleistungsrechte des Bestellers verjähren nach § 634a Abs. 1 Nr. 1 BGB zwei Jahre nach Abnahme des Werkes (str.)3.

286

Neben der mangelhaften Herstellung von Software haftet der Werkunter- 287 nehmer auch für deren verspätete Herstellung, sofern Fristen vereinbart wurden oder ein Fixgeschäft vorliegt. Bei Verzug des Softwareherstellers kann der Besteller nach §§ 631, 323 Abs. 1 BGB vom Vertrag zurücktreten, sofern eine angemessene Frist zur Nacherfüllung bestimmt wurde oder diese nach § 323 Abs. 2 BGB entbehrlich war. Dieser Rücktritt ist verschuldensunabhängig möglich. Dagegen muss ein Verschulden nach § 280 Abs. 2 BGB vorliegen, wenn der Besteller darüber hinaus den Verzugsschaden nach § 286 BGB ersetzt bekommen möchte. Schadensersatz statt der Leistung ist nach § 281 BGB erst nach einer angemessenen Fristsetzung möglich.

1 BGH v. 3.3.1998, NJW-RR 1998, 1268 ff. 2 BGH v. 26.1.1993 – X ZR 90/91, MDR 1993, 1058 = CR 1994, 91 = NJW-RR 1993, 560 ff. 3 Schmidl, MMR 2004, 590 ff.; dagegen für eine dreijährige Verjährungsfrist nach §§ 634 Abs. 1 Nr. 3, 195 BGB; Mansel, NJW 2002, 89; Redeker, ITRB 2004, 84 ff.

Gennen

541

E Rz. 288

Verträge

288

Die bei Mängeln der Software aufgeführten Rechte des Bestellers bestehen in gleicher Weise, wenn die mit der Software zu liefernde Benutzerdokumentation, deren Verfassung ebenfalls eine Hauptpflicht des Werkunternehmers ist1, Mängel aufweist.

289

Auch den Besteller treffen neben der Zahlung der vereinbarten Vergütung weitere Pflichten. So ist er nach § 640 BGB verpflichtet, das vertragsmäßig hergestellte Werk abzunehmen, d.h. körperlich hinzunehmen mit der ausdrücklichen oder stillschweigenden Erklärung, dass er das Werk als in der Hauptsache vertragsgemäß annehme2. Bei Software wird die Abnahme, sofern möglich, in der Übergabe der Speichermedien, wie etwa CDs, Disketten und Ähnlichem liegen. Weigert sich der Besteller, das ordnungsgemäß hergestellte Werk abzunehmen, kann der Softwarehersteller nach § 640 Abs. 1 Satz 3 BGB eine Abnahmefrist setzen und bei erfolglosem Fristverstreichen so die Abnahme fingieren. Daneben kommt der Besteller in Schuldnerverzug nach §§ 280 Abs. 1 und 2, 286 BGB, so dass der Softwarehersteller auch den ihm entstandenen Verzugsschaden ersetzt verlangen kann. 5. Beendigung a) Beendigungsmöglichkeiten

290

Je nachdem, ob mit dem freien Mitarbeiter ein Dienst- oder Werkvertrag begründet wurde, kommen unterschiedliche Beendigungsformen für das Vertragsverhältnis in Betracht.

291

Wurde ein Dienstverhältnis geschlossen, kann dieses vor allem durch Befristung oder Kündigung beendet werden. Eine Befristung in sachlicher Hinsicht wird sich gerade bei freien Mitarbeitern anbieten, die oftmals für einzelne, im Vertrag näher bestimmte Aufgaben bzw. Projekte beschäftigt werden. Bei einer Kündigung ist zu beachten, dass die allgemeinen und besonderen arbeitsrechtlichen Kündigungsschutzvorschriften für freie Mitarbeiter nicht gelten. Auch das Schriftformerfordernis des § 623 BGB gilt nicht. Soll eine ordentliche Kündigung ausgesprochen werden, ergeben sich die Kündigungsfristen abweichend aus § 621 BGB; hiernach ist die Kündigungsfrist abhängig von der Zeitspanne, für die die Vergütung bestimmt ist: Wird nach Tagen bezahlt, ist eine Kündigung an jedem Tag zum Ablauf des folgenden Tages möglich, bei einer Bemessung nach Wochen spätestens am ersten Werktag einer Woche für den Ablauf des folgenden Samstags, bei Bemessung nach Monaten spätestens am 15. des Monats zum Monatsende, bei Bemessung nach Quartalen oder längeren Zeitabschnitten mit einer Frist von sechs Wochen zum Quartalsende. Ist die Vergütung nicht nach Zeitabschnitten bemessen, ist eine jederzeitige Kündigung möglich, aller1 BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207 ff. 2 BGH v. 27.2.1996 – X ZR 3/94, MDR 1996, 893 = NJW 1996, 1749 ff.; BGH v. 25.3.1993 – X ZR 17/92, MDR 1994, 35 = CR 1993, 759 = NJW 1993, 1972 ff.

542

Gennen

Softwareentwicklung durch Dritte

Rz. 294 E

dings ist eine Frist von zwei Wochen einzuhalten, wenn das Dienstverhältnis den Verpflichteten vollständig oder hauptsächlich in Anspruch nimmt. Diese kurzen Fristen führen dazu, dass bei einer Vergütung eines freien Mitarbeiters nach Tagessätzen dieser versuchen wird, eine längere Kündigungsfrist zu vereinbaren, um höhere Sicherheit bei dem Einkommen zu haben. Soll einem Softwareentwickler fristlos gekündigt werden, bedarf es nach § 626 BGB eines wichtigen Grundes für die Kündigung, sofern nicht ausnahmsweise § 627 BGB greift. Bei Vorliegen eines Werkvertrages wird ein bestimmter Erfolg, mithin die 292 Erstellung einer bestimmten Software geschuldet. Das Vertragsverhältnis endet somit automatisch mit Zweckerreichung. Beendigungszeitraum bei einem Werkvertrag ist die Abnahme der geschuldeten Leistung durch den Besteller, § 640 BGB. Der Werkvertrag ist jedoch auch nach § 649 BGB kündbar, wobei der Werkunternehmer dann berechtigt ist, die vereinbarte Vergütung zu verlangen; er muss sich jedoch dasjenige anrechnen lassen, was er infolge der Aufhebung des Vertrags an Aufwendungen erspart oder durch anderweitige Verwendung seiner Arbeitskraft erworben hat oder böswillig unterlässt zu erwerben. Nach § 649 Satz 2 BGB wird ein Anteil von 5 % der Vergütung als angemessene Entschädigung vermutet. b) Fortbestand der Nutzungsrechte an Computerprogrammen und anderen Arbeitsergebnissen bei Beendigung des Vertrages über die freie Mitarbeit Da bei freien Mitarbeitern keine gesetzliche Lizenz zugunsten eines Auf- 293 traggebers nach §§ 69b, 43 UrhG für die auftragsgemäß zu fertigende Software besteht, gibt es erheblichen Regelungsbedarf im Vertrag zur Frage der Nutzungs- und Verwertungsrechte und Nebenrechte. Aus Sicht des Auftraggebers sollten alle Nutzungs- und Verwertungsrechte und alle Nebenrechte auf ihn übergeleitet werden, auch und gerade für den Zeitraum nach Abschluss des Projekts bzw. Beendigung des Vertrages. Es ist unter keinen Umständen empfehlenswert, den Umfang der Nutzungs- und Verwertungsrechte und deren Dauer offen zu lassen. Fehlt es an einer ausdrücklichen Rechteübertragung, kann nach § 31 Abs. 5 294 Satz 1 UrhG und dem dahinter stehenden allgemeinen Prinzip davon ausgegangen werden, dass (nur) diejenigen Nutzungsarten, welche die Erreichung des Vertragszwecks erst ermöglichen, stillschweigend eingeräumt werden, es sei denn, der freie Mitarbeiter hat einen entgegenstehenden ausdrücklichen Vorbehalt geltend gemacht1. Es ist dann auf den von den Parteien übereinstimmend gewollten Vertragszweck abzustellen und zu fragen, ob und in welchem Umfang zur Erreichung dieses Vertragszwecks ein Nutzungsrecht erforderlich ist. Die Zweckübertragungstheorie garantiert folglich dem Werknutzer einen zwingenden Kern von urheberrechtlichen Nutzungsbefugnissen, die für die vereinbarte Verwertung unerlässlich sind. 1 Grunert, in: Wandtke/Bullinger, § 31 UrhG Rz. 76.

Gennen

543

E Rz. 295

Verträge

Dies wird sich auch auf eine über die Beendigung des Vertragsverhältnisses hinausgehende Nutzungsübertragung erstrecken, sofern diese zur Erreichung des Vertragszieles erforderlich ist. Man stelle sich bspw. vor, dass die zu erstellende Software von dem Besteller/Auftraggeber an Dritte vertrieben werden soll. In einem solchen Fall kann von zweierlei ohne Weiteres ausgegangen werden: Dem Auftraggeber stehen die entsprechenden Rechte auch nach der (ordentlichen regelgerechten) Beendigung des Vertrages zu und er hat Anspruch auf eine Kopie des Quellcodes, denn diesen benötigt er zur Wartung und Pflege.

IV. Subunternehmer 1. Interessenlage von Generalunternehmer und Subunternehmer 295

Mit dem Begriff des „Subunternehmervertrages“ wird die Situation umschrieben, in der ein mehrstufiges Vertragsverhältnis besteht, also ein Lebenssachverhalt, an dem zumindest ein Hauptauftraggeber, ein Unternehmer als Auftragnehmer (und gleichzeitig als Auftraggeber des/der Subunternehmer/s) und einer oder mehrere Unterauftragnehmer als Subunternehmer beteiligt sind. Die Ausgangssituation stellt sich typischerweise wie folgt dar: Der Hauptauftraggeber beauftragt einen Unternehmer mit der Durchführung bestimmter Lieferungen und Leistungen, z.B. einem komplexen IT-Projekt, bei dem Hard- und Software erworben bzw. erstellt werden soll und ggf. auch noch eine Datenverbindung zwischen Rechnern über ein Netz herzustellen ist. Ferner sind Schulungen durchzuführen, die gelieferte Software und die Rechner sind zu warten und zu pflegen und es sind noch verschiedene andere Tätigkeiten durchzuführen wie z.B. die Migration/Konvertierung von Altdaten usw. Ein Teil in diesem Kontext ist die Softwareerstellung.

295a Dem Unternehmer ist es in einer solchen Konstellation oft nicht möglich, die gesamten an ihn beauftragten Lieferungen und Leistungen selbst zu erbringen, sei es aus Kapazitätsgründen oder aus dem Grund, dass die an ihn beauftragten Lieferungen und Leistungen nicht vollständig zu seinem Leistungsspektrum gehören. Insoweit beauftragt der Unternehmer dann ggf. einen Subunternehmer bzw. erwirbt bestimmte Vorleistungen von einem Vorlieferanten, die der Unternehmer dann wiederum an den Hauptauftraggeber weiterreicht, und zwar typischerweise als seine eigenen Lieferungen und Leistungen. Selbstverständlich sind Subunternehmerkonstellationen auch mehrstufig denkbar. 295b

Zwar ist für den Subunternehmervertrag nicht kennzeichnend, dass der Unternehmer Generalunternehmer und damit einziger Vertragspartner des Hauptauftraggebers in Bezug auf das gesamte Projekt ist, aber dies ist zumindest eine typische Fallgestaltung. Sie hat für den Hauptauftraggeber den Vorteil, dass er für alle vertraglichen und fachlichen Fragen, insbesondere für das Leistungsbild, die Sach-/Rechtsmangelhaftung und Haftung im Üb544

Gennen

Softwareentwicklung durch Dritte

Rz. 295e E

rigen nur einen Ansprechpartner und nur einen Anspruchsgegner/Schuldner hat. Der Generalunternehmervertrag ist aus Sicht des Hauptauftraggebers dem- 295c nach erst erfüllt, wenn alle Tätigkeiten erbracht und ihre Vertragsgemäßheit bestätigt ist. Eine vertragliche Beziehung zwischen Subunternehmer und Hauptauftraggeber existiert vorbehaltlich vertraglich besonders ausgestalteter Konstellationen nicht. Somit bestehen zwei verschiedene Verträge zum einen zwischen Hauptauftraggeber und Generalunternehmer und zum anderen zwischen Generalunternehmer und Subunternehmer. Im Grunde ist es auch so, dass zwischen dem Subunternehmervertrag und dem Hauptvertrag, der den wirtschaftlichen Hintergrund für den Abschluss des Subunternehmervertrages bildet, ebenfalls keine unmittelbaren rechtlichen Verbindungen bestehen. Das rechtliche Schicksal von Hauptvertrag und Subunternehmervertrag ist trotz des engen wirtschaftlichen Zusammenhangs weitestgehend unabhängig1. Bestand, Inhalt und Rechtsfolgen des Generalunternehmervertrags haben also rechtlich gesehen – vorbehaltlich besonderer Vereinbarungen – grundsätzlich keinen Einfluss auf Vertragsschluss, -beendigung und -inhalt des Subunternehmervertrags sowie auf die Rechtsfolgen im Fall von Leistungsstörungen. Sowohl für den Auftragnehmer erster Ordnung, ggf. als Generalunterneh- 295d mer als auch den Subunternehmer birgt der Subunternehmervertrag nicht unerhebliche Risiken; daraus entstehen in wesentlichen Gesichtspunkten unterschiedliche Interessenlagen. Bei einer solchen „Mehreckskonstellation“ entstehen bereits durch die bloße Anzahl der Beteiligten Schwierigkeiten: – Dies betrifft vor allem den Bereich der Kommunikation miteinander, auch wenn dies kein Kennzeichen der Subunternehmerkonstellation ist, sondern schon aufgrund der Anzahl der Beteiligten in einem IT-Projekt zwangsläufig der Fall ist. Der Informationsfluss zwischen den Beteiligten bedarf einer Regelung, um Unklarheiten und fehlende Informationen zu vermeiden. Die Klärung von Fragen aufgrund mangelhafter oder unerwünschter Kommunikation kann ein Projekt wesentlich verzögern. Eine besondere Konstellation besteht, wenn, wie es des Öfteren der Fall ist, Subunternehmer und Auftragnehmer Konkurrenten sind und die Subunternehmerkonstellation nur deswegen entsteht, weil der Kunde/ Hauptauftraggeber sie fordert, sie also aus Sicht der Leistungserbringerseite nur eine Art „Zwangsehe auf Zeit“ ist. In solchen Fällen wird der Subunternehmer ungern einen ihm vorgeschriebenen Kommunikationskanal bedienen, in den auch der Auftragnehmer, der sein Konkurrent ist, eingebunden ist, weil so Know-how vom Subunternehmer zum Auftragnehmer fließt. Hier wird ggf. der Subunternehmer versuchen, bestimmte

1 Rammig, BB 1994, 518; Redeker, CR 1999, 137; Schlünder, NJW 1995, 1057.

Gennen

545

295e

E Rz. 295f

Verträge

Informationen nur dem Hauptauftraggeber (unmittelbar) zukommen zu lassen, der eigentlich gar nicht sein Vertragspartner ist. – Probleme treten auch auf, wenn mehrere Subunternehmer eingeschaltet werden, deren Leistungen aufeinander abgestimmt werden müssen und deren Leistungserbringung voneinander abhängig ist. Diese wechselseitigen Abhängigkeiten in fachlicher Hinsicht sind vielfältig und müssen vertraglich abgebildet werden. Jedenfalls ist durch entsprechende Vertragsgestaltung Vorsorge dahingehend zu treffen, dass eine Abstimmung auch der Subunternehmerleistungen erfolgen kann und nicht jeder sein eigenes Produkt entsprechend der Leistungsanforderung herstellt, welches später mit den übrigen Produkten gar nicht kompatibel ist. 295f Aus Auftragnehmersicht sollten im Vertrag mit dem Auftrag übernommene rechtliche und vertragliche Risiken an den Subunternehmer weitergereicht werden, zumindest, soweit dieser diejenige Leistung erbringt, mit der das Risiko verknüpft ist. Hintergrund ist: Der Auftragnehmer bedient sich zur Erfüllung seiner gegenüber dem Auftraggeber bestehenden Verpflichtungen des Subunternehmers, bleibt jedoch gegenüber dem Auftraggeber für die rechtzeitige und ordnungsgemäße Leistung voll verantwortlich1. Der Auftragnehmer ist damit von der Erbringung der ordnungsgemäßen Leistung durch den Subunternehmer abhängig. Daher wird es Ziel des Auftragnehmers sein, rechtlich einen unmittelbaren Bezug zu den Regelungen des Generalunternehmervertrages bzw. Hauptvertrages herzustellen und die Verträge zu „synchronisieren“ und zu verknüpfen. Es gibt daher viele Subunternehmerverträge, in denen eine „1:1-Durchreichung“ der Bedingungen des Hauptvertrages erfolgt, auch wenn dies – gleich aus welcher Sicht der am Subunternehmervertrag Beteiligten – nicht immer die angemessene Lösung ist. 295g Diese Weiterreichung von Risiken beginnt bereits im vorvertraglichen Stadium und mit der Frage nach dem Zeitpunkt des Vertragsschlusses. Der Auftragnehmer kann den Subunternehmervertrag im Grunde erst dann zu einem verbindlichen Abschluss bringen, wenn der Hauptvertrag wirksam zustande gekommen ist und dessen Konditionen so weit feststehen, dass der Auftragnehmer im Verhältnis zum Subunternehmer seine Konditionen ebenfalls festmachen kann. Andererseits benötigt der Auftragnehmer bereits bei den Verhandlungen über den Hauptvertrag eine verlässliche Grundlage für seine Kalkulationen und Leistungszusagen. Dies bedingt also in der Phase der Vertragsverhandlungen eine permanente Abstimmung der Beteiligten, in der Person des Auftragnehmers eine mehr oder minder gleichzeitige Versicherung der Leistungsfähigkeit in zwei Richtungen. Während der Vertragsdurchführung wird der Auftragnehmer das Anliegen haben, bei nicht vorhersehbaren Vorfällen im Verhältnis zum Auftraggeber auch auf der Ebene des Subunternehmervertrages gegenüber dem Subunter1 Schlünder, NJW 1995, 1057, spricht von „Zwei-Fronten-Stellung“; Schneider, Handbuch des EDV-Rechts, H Rz. 220 von einer „Sandwich-Situation“.

546

Gennen

Softwareentwicklung durch Dritte

Rz. 295h E

nehmer flexibel reagieren zu können und den Subunternehmervertrag den neuen Bedingungen und Anforderungen anzupassen. Dazu ist erforderlich, dass der Subunternehmervertrag für solche Änderungen offen ist und der Auftragnehmer sie gegenüber dem Subunternehmer durchsetzen kann. Dies gilt auch für ein bei umfangreichen IT-Projekten übliches „Change-Request-Verfahren“. Weiter wird der Auftragnehmer das Ziel haben, dass der Subunternehmer seine Verpflichtungen aus dem Subunternehmervertrag auch erst dann ordnungsgemäß erfüllt hat, wenn der Auftragnehmer seinerseits von der Leistungspflicht gegenüber dem Auftraggeber frei geworden ist. Optimal aus der Sicht des Auftragnehmers ist es daher, dass er den Subunternehmer bis zur „Abnahme“ durch den Auftraggeber bzw. bis zur „Ablieferung“, d.h. bis zu dem Zeitpunkt, in dem er im Verhältnis zum Auftraggeber seine Verpflichtungen erfüllt hat, seinerseits auf Erfüllung in Anspruch nehmen kann. Ist mit der Nichterbringung der Leistung zu einem bestimmten Termin z.B. eine Vertragsstrafe verknüpft, so wird es im Interesse des Auftragnehmers sein, dass ein Subunternehmer, dessen verspätete Leistung das Anfallen der Vertragsstrafe (allein) verursacht, diese im wirtschaftlichen Ergebnis auch zu tragen hat. Auch im Falle von Leistungsstörungen besteht ein Interesse des Auftragnehmers an einer Verknüpfung des Subunternehmervertrages mit dem Hauptvertrag. Wenn sich durch die Schlecht- oder Nichtleistung des Subunternehmers Schäden ergeben, können diese weiterreichende Folgen haben. Das Projekt kann ins Stocken geraten oder sogar scheitern. Das Risiko der ordnungsgemäßen Leistung trägt der Auftragnehmer, der versuchen wird, die Schäden als Schadensersatz oder Vertragsstrafe an den Subunternehmer weiterzugeben. Im Hinblick auf Mängel wird der Auftragnehmer in den meisten Fällen wollen, dass diese in beiden Vertragsverhältnissen nach den gleichen Regelungen qualifiziert werden bzw. dass die vom Auftraggeber vorgegebenen Regelungen auch im Subunternehmervertrag Anwendung finden. So soll eine Leistung, die nach dem Hauptvertrag mangelhaft ist, auch nach dem Subunternehmervertrag einen Mangel darstellen. Auch die Verjährung der Sachund Rechtsmangelhaftungsansprüche und die Verpflichtung zur Zahlung von Vertragsstrafen soll aus Sicht des Auftragnehmers mit dem Hauptvertrag abgestimmt sein. Die Perspektive des Subunternehmers ist im Grunde die gegensätzliche 295h Sicht auf die vorstehend angesprochenen Gesichtspunkte, insbesondere: – Der Subunternehmer hat grundsätzlich das Interesse, nicht die (gesamten) vertraglichen und wirtschaftlichen Risiken tragen zu müssen, die der Auftragnehmer gegenüber dem Auftraggeber eingegangen ist, sondern lediglich solche Risiken zu tragen, die in einem angemessenen Verhältnis zu seiner Leistung stehen. Er möchte nicht, dass solche nicht von ihm beeinflussbaren Risiken an ihn weitergegeben werden und er daGennen

547

E Rz. 295i

Verträge

durch belastet wird. Vertragsstrafen aus dem Hauptvertrag, die in dem Subunternehmervertrag an ihn weiter gereicht werden sollen, sollen in vernünftigem Verhältnis zu seinem Leistungsanteil und zu seiner Vergütung stehen, und dies selbst dann, wenn er den Anfall einer Vertragsstrafe allein verursacht hat. – Sein Ziel ist es, dass die Vertragsgemäßheit seiner Leistung nur an den Vereinbarungen des von ihm beeinflussbaren Subunternehmervertrages gemessen und bewertet wird. So möchte er auch seine Leistungen isoliert von Leistungen anderer im Projekt Beteiligter geprüft wissen und seine Leistungsverpflichtungen sollen als erfüllt angesehen werden unabhängig davon, wann welcher andere Beteiligte im Projekt Leistungen mit welcher Qualität erbringt. Nur von der eigenen Leistungserfüllung soll auch die eigene Vergütung abhängen. – Der Subunternehmer möchte darüber hinaus nicht, dass sich sonstige Abreden aus dem Hauptvertrag, auf die er keinen Einfluss nehmen konnte, oder Bedingungen, deren Eintreten er nicht oder nicht allein beeinflussen kann, zu seinen Lasten auswirken. 295i Hieraus resultiert, dass die Parteien des Subunternehmervertrages in besonderer Weise in folgenden Feldern Verhandlungen zu führen und Abstimmungen zu treffen haben: – Bestimmung des Leistungsumfangs und des Verfahrens zur evtl. Konkretisierung oder Änderung des Leistungsumfangs, – zum Leistungsumfang gehören neben der Hauptleistung auch „Nebenleistungen“ wie evtl. Schulung und andere Leistungen, – Projektmanagement und Informationsfluss zwischen den Beteiligten, – Prüfung der Lieferungen und Leistungen auf Vertragserfüllung (Abnahme bzw. Ablieferung), – Mangelhaftungsfristen und Art und Weise der Mangelhaftung einschließlich der Begrenzung, – Vergütung und Zahlungstermine, – Rechte zur Beendigung des Vertrages einschließlich der Abwicklung bei Vertragsbeendigung. 296

Für den Generalunternehmer birgt der Subunternehmervertrag ein nicht unerhebliches Risiko, da er zwar seine Verpflichtungen aus dem Vertrag mit dem Hauptauftraggeber an den Subunternehmer „abgibt“, dem Hauptauftraggeber jedoch weiterhin gegenüber für jede Leistungsstörung haftet.

297

Aus diesem Grund wird er insbesondere daran interessiert sein, dass der Subunternehmer seine Verpflichtungen aus dem Subunternehmervertrag erst dann ordnungsgemäß erfüllt hat, wenn der Generalunternehmer seinerseits von seiner Leistungspflicht gegenüber dem Hauptauftraggeber befreit ist. Demgegenüber besteht das Interesse des Subunternehmers, eine Bestätigung der Vertragsgemäßheit seiner Leistungen und die Vergütung dafür bereits mit Abschluss der Erbringung der eigenen Leistungen zu erhalten und 548

Gennen

Softwareentwicklung durch Dritte

Rz. 302 E

nicht darauf warten zu müssen, dass auch andere Subunternehmer oder der Generalunternehmer selbst ihre bzw. seine Leistung erbracht haben. Entsprechendes ergibt sich bei der Haftungssituation: Wenn sich Schäden durch eine Nicht- oder Schlechtleistung eines Subunternehmers ergeben, können diese weiter reichende Folgen haben als nur für die Leistung dieses Subunternehmers, das Projekt kann ins Stocken geraten oder ganz scheitern. Dieses Risiko trägt der Generalunternehmer, und er versucht bisweilen, die betragsmäßigen Haftungsgrenzen der Subunternehmer und die zu ersetzenden Schäden möglichst weit herauszuschieben, um für den Fall der Verantwortlichkeit eines Subunternehmers für das Scheitern des Gesamtprojekts auch möglichst viel Schadensersatz dort liquidieren zu können. Auch im Hinblick auf Mängel besteht ein Interesse des Generalunterneh- 298 mers daran, dass diese in den beiden von ihm eingegangenen Vertragsverhältnissen nach den gleichen Regelungen qualifiziert werden, d.h. dass eine Leistung, die nach dem Generalunternehmervertrag als mangelhaft zu beurteilen ist, auch nach dem Subunternehmervertrag als mangelhaft gilt. Sachund Rechtsmangelhaftungsansprüche des Hauptauftraggebers und deren Verjährung oder die Verpflichtung zur Zahlung von Vertragsstrafen möchte der Generalunternehmer ebenfalls an den Subunternehmer „weitergeben“. Auch die Möglichkeiten zur Beendigung des Subunternehmervertrages sollen nach dem Willen des Generalunternehmers von der Beendigung des Generalunternehmervertrags abhängen, während der Subunternehmer zumeist an einer solchen Abhängigkeit kein Interesse hat. Der Subunternehmer hat demgegenüber ein Interesse daran, dass er gerade 299 nicht die gesamten vertraglichen Risiken trägt, die der Generalunternehmer gegenüber dem Hauptauftraggeber eingegangen ist. Für ihn wird von Bedeutung sein, dass Abreden aus dem Generalunternehmervertrag, auf die er keinen Einfluss nehmen konnte, wie bspw. Vertragsstrafen, sich nicht zu seinem Nachteil auswirken. Einstweilen frei.

300

2. Leistungspflichten Im Folgenden sollen nur die bei einem Subunternehmervertrag auftretenden Besonderheiten dargestellt werden, sofern sich diese von den allgemeinen Leistungspflichten im Rahmen eines Werkvertrages unterscheiden können.

301

In Subunternehmerverträgen über die Entwicklung von Individualsoftware 302 stehen – ebenso wie bei einem gewöhnlichen Werkvertrag über Softwareerstellung – die Erstellung und Lieferung eines Softwareprogramms nebst Dokumentation sowie die Einräumung von Nutzungs- und Verwertungsrechten mit der Zahlung der vereinbarten Vergütung im Gegenseitigkeitsverhältnis. Die Leistungspflichten des Subunternehmers bestimmen sich hier allerdings üblicherweise nach denen des Generalunternehmers gegenüber dem Hauptauftraggeber, da der Generalunternehmervertrag die Gennen

549

E Rz. 303

Verträge

technische und wirtschaftliche Grundlage für den Subunternehmervertrag bildet. Es empfiehlt sich daher aus Sicht des Generalunternehmers, bei Abschluss eines Subunternehmervertrages, die mit dem Hauptauftraggeber ausgehandelte Leistungsbeschreibung aus dem Generalunternehmervertrag zu übernehmen. Aus Sicht des Generalunternehmers muss aber die erforderliche Flexibilität erhalten bleiben – wünscht der Hauptauftraggeber vom Generalunternehmer Änderungen und lässt sich dieser auf solche Änderungen ein, muss er sie auch im Verhältnis zum Subunternehmer durchsetzen können, ohne nachteilige finanzielle Folgen zu haben. Daher ergibt sich mehrfacher Abstimmungsbedarf im Dreiecksverhältnis, denn im Grunde kann der Generalunternehmer dem Hauptauftraggeber die Erbringung bestimmter zusätzlicher oder veränderter Leistungen erst sicher zusagen, wenn er zuvor mit seinem Subunternehmer verhandelt hat, dass dieser die Leistungen auch erbringen kann. Vielfach ist der Generalunternehmer, wenn es sich um Leistungen handelt, die nicht zu seinem Portfolio gehören, gar nicht in der Lage, hierzu belastbare Aussagen zu treffen, ohne dies zuvor mit dem Subunternehmer abgestimmt zu haben. Dieser erhöhte Aufwand des Generalunternehmers wird mit dem sog. Generalunternehmerzuschlag abgegolten, und dies ist auch der Aufwand, den der Hauptauftraggeber auf Grund der Wahl der Generalunternehmerkonstellation selbst nicht betreiben muss. 303

Bei einem Subunternehmervertrag über eine Softwareentwicklung sollte insbesondere geregelt werden, dass die Herausgabe des Quellcodes der Software eine Leistungsverpflichtung des Subunternehmers darstellt. Der Quellcode gehört zur Software selbst und nicht zu den Materialien des Entwicklungsstadiums1. Dennoch ist seine Herausgabe nach der Rechtsprechung des BGH nicht ohne weiteres geschuldet, sondern richtet sich nach dem Vertragszweck2. So ist denkbar, dass eine Quellcodeherausgabe im Verhältnis Generalunternehmer – Hauptauftraggeber geschuldet ist, wenn der Vertragszweck sich darauf richtet, dass der Hauptauftraggeber die Software selbst weiter vertreiben und mithin auch warten und pflegen will. Aber auch in einer Konstellation, in der der Generalunternehmer über die bloße Erstellung der Software hinaus weitere Verpflichtungen gegenüber dem Hauptauftraggeber angenommen hat, so etwa die Anpassung der entwickelten Software an sich ändernde Gegebenheiten bei dem Hauptauftraggeber, und diese als unmittelbar und persönlich wahrzunehmen schuldet, besteht ein Interesse daran, den Quellcode zu erhalten. Auch wenn eine Einräumung eines umfassenden und ausschließlichen Nutzungsrechts für eine Pflicht zur Überlassung des Quellcodes spricht3, sollte dennoch eine aus1 Schneider, CR 2003, 1 ff. 2 BGH v. 30.1.1986 – I ZR 242/83, MDR 1986, 910 = CR 1986, 377 ff.; BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 ff. Vgl. zur uneinheitlichen Rechtsprechung hinsichtlich einer Pflicht zur Herausgabe des Quellcodes Schneider, CR 2003, 1 ff. 3 Seffer/Horter, ITRB 2005, 169 ff.

550

Gennen

Softwareentwicklung durch Dritte

Rz. 306 E

drückliche vertragliche Regelung zur Vermeidung von Rechtsstreitigkeiten getroffen werden. Durch eine solche Herausgabeverpflichtung des Subunternehmers ist der Generalunternehmer zudem in der Lage, auch nach Beendigung des Subunternehmervertrages etwaige Mängel der Software selbst auszubessern oder aber durch Dritte ausbessern zu lassen. Ist eine unmittelbare Herausgabe nicht zu erlangen, bietet sich das sog. Es- 304 crow Agreement an1. Hier wird der Quellcode bei einem Treuhänder hinterlegt und von diesem nur bei Eintritt bestimmter Bedingungen, wie etwa der Weigerung des Subunternehmers, eine Fehlerbeseitigung vorzunehmen, freigegeben. Solche Konstellationen empfehlen sich aber nur, wenn der Subunternehmer auch nach dem Projektende dauerhaft Leistungen erbringt und seine Einschaltung nicht mit dem Projektende ebenfalls endgültig beendet sein soll (weil der Generalunternehmer die weiteren Verpflichtungen wie z.B. Wartung, Pflege und Weiterentwicklung unmittelbar erbringen will). Es können im Rahmen eines Subunternehmervertrages – wie bei jedem an- 305 deren Vertrag über die Erstellung einer Software auch – weitere Leistungspflichten von Subunternehmer und Generalunternehmer vereinbart werden. Denkbar ist bspw. eine Überprüfungspflicht des Subunternehmers, wenn diesem Informationen oder bereits vorhandene Software2 des Hauptauftraggebers vom Generalunternehmer überlassen werden. Dazu korrespondierend kann dem Generalunternehmer aufgegeben werden, dem Subunternehmer alle erforderlichen Informationen zu beschaffen, die zur Erstellung der Software (auch vom Auftraggeber) benötigt werden. Vielfach wird auch der Subunternehmer mit einem Vertreter in den Projektgremien vertreten sein, allein schon wegen der überlegenen Sachkunde in Bezug auf den von ihm zu erbringenden Leistungsbereich. Auch verkürzen sich auf diese Weise Kommunikationswege. Vielfach bedingt sich der Hauptauftraggeber, wenn er die Sachkunde des 306 Subunternehmers zu schätzen beginnt, aus, Kommunikation zu fachlichen Fragen unmittelbar mit dem Subunternehmer führen zu können. Dies führt dann vielfach zu Problemen, wenn die Subunternehmer zu starke Positionen erhalten, die Klärung von Fachfragen am Generalunternehmer vorbei laufen und Subunternehmer Zusagen machen, die Auswirkungen auf das Gefüge von Leistung und Gegenleistung haben. Dies betrifft insbesondere die Fehlerbehebung und die Zusage von Leistungen, mit der sich der Generalunternehmer bei unterstellter Vereinbarung eines Pauschalfestpreises schwer tut. Hier sind klare Regelungen im Subunternehmervertrag erforderlich, die die Kommunikation und die Vertretungsbefugnis regeln und klarstellen, dass der Subunternehmer Zusagen unmittelbar gegenüber dem Hauptauftraggeber auf eigenes wirtschaftliches Risiko macht. Auch der Hauptauftraggeber tut gut daran, sich Zusagen der Subunternehmer vom 1 S. hierzu näher Kast/Meyer/Peters, CR 2004, 147 ff. 2 Denkbar ist bspw., dass der Hauptauftraggeber bereits ein Softwaresystem benutzt, in das dann die in Auftrag gegebene Software eingepasst werden soll.

Gennen

551

E Rz. 307

Verträge

Generalunternehmer bestätigen zu lassen, weil sonst die Konstellation eintritt, die er mit einem Generalunternehmervertrag eigentlich vermeiden wollte: Die hauptsächlichen Leistungen sind ihm vom Generalunternehmer zugesagt worden und einige Zusatzleistungen, über die er mit den Subunternehmern unmittelbar gesprochen hat, werden von diesen als seinen unmittelbaren Vertragspartnern erbracht, so dass der Hauptauftraggeber im Ergebnis doch eine Mehrheit von Leistungserbringern vorfindet. 307

Der Generalunternehmer wird bei Leistungsstörungen oftmals weniger an Schadensersatzansprüchen gegen den Subunternehmer, als vielmehr an einer Nachbesserung der erstellten Software interessiert sein, um seinerseits seiner Leistungsverschaffungspflicht gegenüber dem Auftraggeber nachkommen zu können. Dies gilt jedenfalls in Konstellationen, in denen der Generalunternehmer die Behandlung der Software, bspw. weil es nicht zu seinem Leistungsspektrum gehört, dauerhaft dem Subunternehmer überlässt, auch in der sich an das Projekt anschließenden Wartungs- und Pflegephase. Aus diesem Grund werden oftmals Klauseln in den Subunternehmervertrag aufgenommen, die den Subunternehmer detailliert zur Nachbesserung verpflichten, einschließlich der Vereinbarung von mit Vertragsstrafen bewehrten Reaktions- und Fehler-/Störungsbehebungszeiten. 3. Rechteübertragung

308

Wie bei jedem Softwareentwicklungsprojekt ist auch in einer Subunternehmerkonstellation eine klare Regelung zur Rechteübertragung erforderlich. Mit der Zweckübertragungstheorie zu arbeiten ist insoweit vielfach schwierig, weil es Konstellationen geben kann, in denen der Generalunternehmer den Subunternehmer gar nicht über alle Details aufklärt, die im Verhältnis Hauptauftraggeber/Generalunternehmer eine Rolle spielen. Dann kann der Generalunternehmer gegenüber dem Subunternehmer bzgl. der von diesem zu übertragenden Rechte auch nicht oder nur eingeschränkt mit dem Zweck des Generalunternehmervertrages argumentieren. Jedenfalls in solchen Konstellationen ist es notwendig, die im Generalunternehmervertrag zugesagten Nutzungs- und Verwertungsrechte vertraglich vom Subunternehmer auf den Generalunternehmer überzuleiten. Bei der Ausformulierung einer solchen vertraglichen Übertragungsklausel im Subunternehmervertrag sollte mit Bedacht vorgegangen werden, da der Generalunternehmer dem Auftraggeber regelmäßig im Rahmen der Übertragung aller Nutzungsrechte an der erstellten Software dafür haftet, dass diese frei von Rechten Dritter ist. 4. Sonstiges

309

Da der Subunternehmervertrag lediglich die Regelung eines besonderen Lebenssachverhalts über eine Dreieckskonstellation und keine besondere Rechtsform ist, gelten für den Subunternehmervertrag über Softwareent-

552

Gennen

Softwareentwicklung durch Dritte

Rz. 311a E

wicklungsleistungen im Übrigen auch alle Anmerkungen, die sich auf einen normalen Softwareentwicklungsvertrag beziehen, stets mit dem besonderen Aspekt, dass die von dem Subunternehmer erbrachten Leistungen von vornherein dazu gedacht sind, im Ergebnis als Leistungen gegenüber einem Dritten erbracht zu werden. Das kann sich z.B. auch auf der Vergütungsseite bemerkbar machen. Der 310 Generalunternehmer wird ein Interesse daran haben, keine Zwischenfinanzierungen vornehmen zu müssen, sondern seine Subunternehmer stets nur aus Zahlungstranchen bedienen zu können, die er von dem Hauptauftraggeber erhält, während der Subunternehmer ein Interesse daran hat, gerade unabhängig von Zahlungstranchen des Hauptauftraggebers bezahlt zu werden und Zahlungen dann zu erhalten, wenn er sie für angemessen hält, also z.B. entsprechend den von ihm erfüllten Entwicklungsschritten (Abnahme des Feinkonzepts, Erstellung des Prototyps usw.). Auch wird es im Interesse des Generalunternehmers sein, bei einer Beendi- 311 gung des Vertrages durch den Hauptunternehmer die Verträge mit den Subunternehmern beenden zu können, ohne dass er diesen noch (wesentliche) Zahlungen schuldet, während es ein veritables Interesse der Subunternehmer ist, gegenüber dem Generalunternehmer nur für die eigenen Leistungen und deren Erbringung verantwortlich zu sein und gegen alle anderen Einflüsse aus dem Projekt, insbesondere gegen für den jeweiligen Subunternehmer nicht vorhersehbare Gründe einer Beendigung des Projekts, gefeit zu sein. Dies schlägt sich denn auch in den Subunternehmerverträgen entsprechend nieder. Insoweit ist es originäre Aufgabe des Generalunternehmers, diese Verhandlungen und Risiken zu übernehmen bzw. auf die Subunternehmer zu verlagern. Das ist der Grund, weswegen man einen Generalunternehmer einschaltet, und hierfür erhält er auch seinen Generalunternehmerzuschlag auf die Leistungen der Subunternehmer. Wer sich als Auftraggeber diesen Generalunternehmerzuschlag sparen will, muss die gesamte Koordination, die angesprochenen Risiken usw. selbst übernehmen. Insbesondere in Unternehmen mit einer IT-Abteilung mit niedriger Personalstärke empfiehlt sich dies nicht. Subunternehmerverträge können für ein einzelnes Projekt oder auch als 311a Rahmenvertrag abgeschlossen werden. Der Abschluss eines Rahmenvertrags bietet sich an, wenn die Parteien beabsichtigen, in verschiedenen ähnlich gelagerten Projekten in der Konstellation Generalunternehmer/Subunternehmer (mit jeweils gleichen oder ggf. auch umgekehrten Parteirollen) zusammenzuarbeiten1. Im Rahmenvertrag werden dann die Regelungen über wichtige wiederkehrende Vertragspunkte getroffen und ggf. wirtschaftliche Rahmenkonditionen (Tagessätze/Spesensätze, Festpreise für gleichbleibende Leistungspakete usw.) festgelegt. Der Generalunternehmer erteilt dann auf Grundlage der im Rahmenvertrag getroffenen Vereinbarungen Einzelaufträge an den Subunternehmer. 1 Vgl. dazu Schneider, Handbuch des EDV-Rechts, E Rz. 208.

Gennen

553

E Rz. 311b 311b

Verträge

In der Praxis wird der Subunternehmervertrag überwiegend zwischen den Parteien individuell ausgehandelt. Dennoch sind Fallkonstellationen denkbar, in denen eine Vertragspartei vorformulierte Regelwerke verwendet und der anderen Partei stellt. – Naheliegend ist der Fall, dass der Auftragnehmer in seiner Eigenschaft als Generalunternehmer innerhalb eines Projektes mit mehreren parallel arbeitenden Subunternehmern vertragliche Beziehungen eingeht und dazu Verträge verwendet, deren Inhalt im Wesentlichen deckungsgleich ist. Dabei entstehen trotz des Umstands, dass der Vertrag zwischen Hauptauftraggeber und Auftragnehmer/Generalunternehmer individuell ausgehandelt wird, im Verhältnis zwischen Auftragnehmer und Subunternehmern Allgemeine Geschäftsbedingungen i.S.d. §§ 305 ff. BGB, auch wenn sich diese Deckungsgleichheit der parallelen Verträge aus dem bloßen Umstand ergibt, dass der Auftragnehmer einen mit dem Auftraggeber zunächst individuell ausgehandelten Vertrag (unter Aufteilung der zu erbringenden Leistungen) an verschiedene Subunternehmer „weiterreicht“. Entschärft wird diese Fragestellung aber dadurch, dass sich der Auftragnehmer während der Verhandlungen mit dem Auftraggeber in dauernder „Rückversicherung“ bei seinen Subunternehmern darüber befindet, ob, inwiefern und unter welchen wirtschaftlichen und juristischen Randbedingungen er bestimmte Leistungen (die im Innenverhältnis von den Subunternehmern zu erbringen sind) überhaupt zusagen kann. Das wird auch auf der Ebene des Subunternehmervertrags vielfach zu individuell ausgehandelten Verträgen führen, wenn es sich bei den Subunternehmern um spezialisierte Unternehmen mit einer im konkreten Fall gewissen Marktmacht handelt. – Ebenso ist es möglich, dass der Auftragnehmer/Generalunternehmer für mehrere Projekte das Projektmanagement übernommen hat und den Subunternehmern der verschiedenen Projekte vorformulierte Verträge stellt. – Außerdem mag es vorkommen, dass sich der Auftragnehmer/Generalunternehmer vorformulierter Subunternehmer-Rahmenverträge bedient. – Schließlich kann auch der Subunternehmer/Vorlieferant allgemeine Geschäftsbedingungen stellen. Braucht z.B. der Auftragnehmer zur Durchführung des IT-Projekts Programme von bekannten bzw. marktmächtigen Herstellern, werden diese ihm die Server bzw. Software wahrscheinlich nur zu ihren Verkaufs-AGB bzw. Lizenz-AGB zur Verfügung stellen und er hat kaum eine andere Wahl, als den Versuch zu unternehmen, diese ihm verbindlich vorgegebenen Bedingungen an den Auftraggeber weiter zu reichen, gleich, wie der Hauptvertrag im Übrigen aussieht. In einem solchen Fall wäre es eine eher unrealistische Erwartungshaltung des Hauptauftraggebers, mit dem Auftragnehmer einen Hauptvertrag nach eigenem Gusto zu schließen und den Auftragnehmer im Innenverhältnis die vollständigen Risiken tragen zu lassen, die aus evtl. für ihn schlechteren Bedingungen im Verhältnis zwischen Auftragnehmer und Subunternehmer/Vorlieferant resultieren. Vielfach werden in solchen Fallgestaltungen 554

Gennen

Softwareentwicklung durch Dritte

Rz. 313 E

spätestens in der Wartungs-/Pflegephase ohnehin Verträge unmittelbar zwischen dem Hauptauftraggeber und dem (früheren) Subunternehmer geschlossen.

V. Konsortium 1. Begriff; Abgrenzung zum Austauschvertrag Konsortialverträge (Joint Ventures, ARGE) sind Zusammenarbeiten zu ei- 312 nem gemeinsamen Zweck, hier zu einer gemeinsamen Entwicklung oder Realisierung eines Software-Projekts. Sie sind mithin Gesellschaften bürgerlichen Rechts nach § 705 BGB, denn § 705 BGB bestimmt: „Durch den Gesellschaftsvertrag verpflichten sich die Gesellschafter gegenseitig, die Erreichung eines gemeinsamen Zwecks in der durch den Vertrag bestimmten Weise zu fördern, insbesondere die vereinbarten Beiträge zu leisten.“ Bei der OHG besteht der gemeinsame Zweck im Betrieb eines Handelsgewerbes. Im Allgemeinen fehlt es an einem dauerhaft gemeinsam betriebenen Gewerbebetrieb nach § 1 HGB1. Beim Austauschvertrag verfolgen die Parteien regelmäßig auch einen „gemeinsamen“ wirtschaftlichen Zweck, aber er herrscht nicht zwischen ihnen, sondern ist nur beiderseits bekannte Zielsetzung, etwa die Realisierung eines Softwareprojekts durch werkvertragliche Zuarbeit seitens eines Subunternehmers. Das Verhältnis zwischen den Parteien wird durch einen werk- oder dienstvertraglichen Austausch geprägt: Leistung gegen Vergütung. Der Austauschvertrag ist ein „vertikales“ Auftragsverhältnis. Der Konsortialvertrag zur gemeinschaftlichen Zweckerreichung ist eine „horizontale“ Zusammenarbeit. Die Abgrenzung spielte unter dem alten deutschen Kartellrecht eine Rolle, weil Verträge zu einem gemeinsamen Zweck nach § 1 GWB strenger behandelt wurden als Austauschverträge2. Auch sind die Haftungsregeln im vertikalen Werkvertrag strenger als im horizontalen Gesellschaftsvertrag. Eine scharfe Abgrenzung gibt es aber nicht; im Grenzbereich muss wertend festgestellt werden, ob horizontaler gemeinsamer Zweck oder vertikaler Leistungsaustausch prägend ist. Konsortialverträge spielen auch bei der EU-Forschungsförderung eine Rolle, denn die „indirekte“3 Förderung an Unternehmen wird grundsätzlich nur gewährt, wenn sich mindestens drei Unternehmen aus drei EU-Mitgliedsstaaten zu einem Forschungs- und/oder Entwicklungsprojekt zusammen-

1 Bei einer großen Bau-ARGE war das streitig. Der BGH hat sie aber auch als BGBGesellschaft eingeordnet, BGH v. 21.1.2009 – Xa ARZ 273/08, NJW-RR 2009, 173. 2 BGH v. 14.1.1997 – KZR 41/95 – Druckgussteile, NJW 1997, 2324. 3 „Direkte“ Maßnahme oder Förderung ist Förderung einer EU-eigenen Forschungseinrichtung; „indirekte“ Förderung ist die Förderung von FuE-Projekten von Industriekooperationen untereinander und ggf. mit Hochschulen.

M. Brandi-Dohrn

555

313

E Rz. 314

Verträge

tun, Art. 5 EU-Beteiligungsregeln1. Ausnahmen sind aber vorgesehen. Für die geförderte FuE-Zusammenarbeit sind zwar Konsortialverträge empfohlen2, aber es reichen auch Subunternehmerverhältnisse, also vertikale Auftragsverhältnisse. 2. Ausprägung 314

Die Verfolgung des gemeinsamen Zwecks kann unterschiedlich ausgestaltet sein: – Softwareentwickler der Partner arbeiten zusammen unter einer Projektleitung, gemeinsam (§ 709 BGB) oder federführend durch einen Partner (Geschäftsführender Gesellschafter: §§ 710, 713, 716 BGB). – Jeder Partner übernimmt einen sachlich abgegrenzten Projektteil und entwickelt ihn bei sich als Beitrag für das gemeinsame Projekt §§ 706, 718 BGB, also abgestimmte Spezialisierung jedes Partners mit einem gemeinsamen Ergebnisaustausch. – Es kann auch sein, dass ein Partner nur finanzielle Beiträge und der andere Softwareentwicklung leistet; dann bedarf es aber besonderer gesellschaftsvertraglicher Ausgestaltung, um nicht in ein vertikales Auftragsverhältnis abzugleiten. – Gemeinsame Gründung und Haltung einer Tochtergesellschaft, also eines Gemeinschaftsunternehmens (GU), – das entweder nur entwickelt, – oder entwickelt und für die vertreibenden Mütter produziert (bei leicht kopierbarer Software wohl eher selten), – oder entwickelt und selbst vertreibt, um beim Vertrieb auch Installation und Pflege zu leisten.

315

Diese Konsortialverhältnisse zwischen den Partnern können oder müssen begleitet sein von vertikalen Auftragsverhältnissen (Werk- oder Dienstverträgen) zu einem Auftraggeber, bei dem oder für den das Software-Erstellungsprojekt verwirklicht werden soll, oder nach unten zum Gemeinschaftsunternehmen, das für die Mütter in deren Auftrag die Software entwickelt. Für das vertikale Auftragsverhältnis gelten dann die dargestellten dienst- oder – häufiger – werkvertraglichen Regeln.

316

Schließlich kann die Entwicklung auch unterhalb des planmäßig gemeinsamen Zwecks angesiedelt sein. Es können Entwicklungsbeiträge mehreren auch gemeinsam in der Form der Bruchteilsgemeinschaft nach § 741 BGB zustehen. Das kann z.B. im vertikalen Auftragsverhältnis eintreten, wenn 1 VO (EG) Nr. 1906/2006 v. 18.12.2006 über Regeln für die Beteiligung von Unternehmen, Forschungszentren und Hochschulen an Maßnahmen der Durchführung des Siebten Rahmenprogramms sowie für die Verbreitung der Forschungsergebnisse, ABl. EU 2006 L 391/1. 2 Art. 24 der EU-Beteiligungsregeln.

556

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 319 E

der Auftraggeber über die bloße Aufgabenstellung hinaus auch so weitgehende Lösungsansätze liefert, dass er Miturheber wird. Ein Gemeinschaftsverhältnis kann sich auch bilden, wenn ein zweiter Entwickler auf den Arbeiten eines früheren ersten Entwicklers aufbaut, so dass das Endergebnis sich aus Beiträgen beider zusammensetzt. Rechtlich gleich mit der Gesellschaft ist, dass keiner über den gemeinsamen Gegenstand verfügen kann, §§ 747 Satz 2, 719 Abs. 1 BGB, jeder ihn aber nutzen darf; ungleich ist, dass der Gemeinschafter, nicht aber der Gesellschafter, über seinen Anteil an der Gemeinschaft/Gesellschaft verfügen darf, § 747 BGB für die Gemeinschaft, § 719 BGB für die Gesellschaft. 3. Überblick zu den gesellschaftsrechtlichen und schutzrechtlichen Fragen Wenn nichts anderes vereinbart ist – häufig wird aber bei trennbaren Beiträ- 317 gen anderes vereinbart – werden die Beiträge der Gesellschafter Gesamthandsvermögen nach §§ 718, 719 BGB, die Gegenstände des Gesamthandsvermögens darf grundsätzlich jeder kostenlos nutzen1, darüber darf aber keiner allein verfügen §§ 743 Abs. 2, 747 Satz 2 BGB. Bei trennbaren Beiträgen und bei vorbestehender, zur Entwicklung genutz- 318 ter Software, behält sich im allgemeinen jeder seine Urheberrechte oder sonstigen Immaterialgüterrechte vor und bringt sie nicht in die Gesellschaft ein. Er muss aber, wenn er sich nach § 705 BGB zur Förderung des gemeinsamen Zwecks, nämlich Verwirklichung des gemeinsamen Projekts verpflichtet hat, Nutzungsrechte für die Entwicklung einräumen. Jeder Partner muss auch die Nutzung des gemeinsamen Projekts ermöglichen. Auch das gehört zur Erreichung des gemeinsamen Zwecks. 4. Vertragsverhältnis Das Vertragsverhältnis unter den Konsorten ist regelmäßig ein Gesell- 319 schaftsvertrag zu dem gemeinsamen Zweck (§ 705 BGB), z.B. der Softwareerstellung zur Nutzung durch die Beteiligten oder für einen gemeinsamen Auftraggeber. Dazu muss ein ARGE-ähnlicher Gesellschaftsvertrag geschlossen werden mit Regelung der Geschäftsführung. Zweckmäßig benennen die Konsorten auch projektverantwortliche Ansprechpartner, damit die Abstimmung über das Projekt im Zuge seiner Entwicklung in geordneten Bahnen verläuft. Die einzelnen sachlichen Beiträge müssen umschrieben und verteilt werden mit einer Regelung, ob die jeweiligen Entwicklungsbeiträge ins Gesellschaftsgesamthandvermögen als echte Beiträge 1 § 743 Abs. 2 BGB: „Jeder Teilhaber ist zum Gebrauch des gemeinschaftlichen Gegenstands insoweit befugt, als nicht der Mitgebrauch der übrigen Teilhaber beeinträchtigt wird“, Insoweit aber auch ohne eine Nutzungsausgleichsgebühr, BGH v. 22.3.2005 – X ZR 152/03 – Gummielastische Masse II, GRUR 2005, 663. Bei der Gesellschaft bestimmt § 733 Abs. 2 Satz 2 BGB, dass bei der Auseinandersetzung Nutzungen grundsätzlich nicht zu vergüten sind.

M. Brandi-Dohrn

557

E Rz. 320

Verträge

(quoad dominium) eingebracht oder nur Nutzungsrechte (quoad usum) eingebracht werde. Das Konsortium, die Gesellschaft, schließt durch ihren vertretungsberechtigten Geschäftsführer (§§ 710, 714 BGB) den vertikalen Dienst- oder Werkvertrag über die Realisierung des Projekts mit dem Auftraggeber ab. Dieser Vertrag verpflichtet das Konsortium1 und über die Vertretungsmacht nach §§ 714, 164 BGB jeden einzelnen Gesellschafter zur Erbringung seines Beitrags mit voller bzw. vereinbarter Haftung nach außen. 320

Bei einem Gemeinschaftsunternehmen (GU) müssen die Mütter unter sich in einem BGB-Gesellschaftsvertrag Aufgabengebiet des GU, Beiträge, Beteiligung und Verwaltungsrechte im GU und fallweise die jeweiligen Verwertungsgebiete der Softwareentwicklung durch das GU regeln. Sie müssen weiterhin die Satzung des GU aufstellen mit Geschäftsführerregelung und Kontrollrechten, häufig durch einen von beiden Müttern beschickten Beirat. Sie müssen den Anstellungsvertrag des Geschäftsführers für das GU aufsetzen, aushandeln und abschließen. Sie müssen die Beteiligungsquoten und etwaige Minderheitsrechte, z.B. durch einen Katalog zustimmungspflichtiger Geschäfte, regeln. Oder sie müssen bei einem 50:50 Beirat die Auflösung von Patt-Situationen durch einen Stichentscheid regeln. Das ist individuelle Verhandlungssache.

321

Ein Verbot konkurrierender Entwicklung kann kartellrechtlich vereinbart werden. In Art. 5a) der FuE-GVO2 ist ein solches Verbot dann nicht freistellungsschädlich, wenn die Konkurrenzentwicklung im Zusammenhang mit der laufenden, vereinbarten Entwicklung stehen würde. Nicht freigestellt ist das Verbot von nicht im Zusammenhang stehenden oder nachvertraglichen Entwicklungen.

322

Wird nichts vereinbart, so gilt bei der BGB-Gesellschaft nicht das Konkurrenzverbot der OHG aus § 112 HGB. Ein Konkurrenzverbot aus gesellschaftlicher Treuepflicht gilt nur ausnahmsweise, etwa dann, wenn eine Parallelentwicklung eine sehr aufwendige Gemeinschaftsentwicklung vor ihrer Amortisation unverwertbar macht. Das kann auch unlauterer Wettbewerb nach §§ 3, 4 Nr. 9 UWG (sklavische Nachahmung) sein, wobei eine Wechselwirkung zwischen wettbewerblicher Eigenart, Art und Weise und Intensität der Übernahme und den wettbewerbswidrigen Umständen besteht3. Bei einer von der gemeinsamen Entwicklung inspirierten Konkurrenzentwicklung ist das Gesellschaftsverhältnis immer ein Faktor gegen den konkurrierenden Gesellschafter. Im Allgemeinen sind aber, wenn nichts Besonderes vereinbart ist oder sich aus den Umständen ergibt, Konkurrenzent-

1 Seit BGH v. 29.1.2001 – II ZR 331/00 – Rechtsfähigkeit der Außen-GbR, MDR 2001, 459 = NJW 2001, 1056 ist das Konsortium oder die ARGE auch als solche rechtsfähig. 2 FuE-GVO 1217/2010 v. 14.12.2010, ABl. EU 2010 L 335/36. 3 Diese Wechselwirkung ist st. Rspr., z.B. BGH v. 28.5.2009 – I ZR 124/06 – LIKEaBIKE, GRUR 2010, 80 (21).

558

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 327 E

wicklungen erlaubt1, sofern sie nicht Urheberrechte oder Patentrechte verletzen. 5. FuE-Verträge, Gruppenfreistellungsverordnung Gemeinschaftsentwicklungen sind einerseits nützliche, wechselseitige Er- 323 gänzungen von individuellen Fähigkeiten, Know-how und Ressourcen und laden andererseits dazu ein, sich auch bei der Verwertung, insbesondere beim Vertrieb und bei den Preisen zu koordinieren. Daher sind die kartellrechtlichen Beschränkungen und Erlaubnisse kritisch. a) Deutsches Kartellrecht Inhaltlich gab es bis 2005 für Lizenzverträge eine Regelung in §§ 17, 18 324 GWB (noch früher: §§ 20, 21 GWB) nach folgendem Prinzip: Was innerhalb des Schutzumfangs verboten werden konnte, kann auch lizenzweise gegen Gebühren erlaubt werden – § 17 Abs. 1 GWB. Darüber hinaus sind noch bestimmte weitere Beschränkungen, z.B. Qualitäts- und Bezugsbindungen, erlaubt – § 17 Abs. 2 GWB. Was darüber hinausgeht, ist verboten und nichtig, es sei denn, es sei dafür eine Einzelerlaubnis eingeholt worden – § 17 Abs. 3 GWB. Im Zuge der absoluten Vorrangregelung ab 1.5.2004 für das Europäische 325 Kartellrecht nach der neuen EU-KartellVO ist für kartellvertragliche nationale Sonderregelungen kein Platz mehr. Es gilt für Lizenzverträge nur noch das EU-Kartellrecht, jedoch ohne Bezugnahme auf den zwischenstaatlichen Handel. Das GWB ist seit 1.7.2005 grundlegend umgestaltet. Im Europäischen Recht ist der alte EG-Vertrag durch den Vertrag von Lissabon in „Vertrag über die Arbeitsweise der Europäischen Union“ (AEUV) umbenannt, ergänzt und in der Folge der Artikel neu nummeriert worden und am 1.12.2009 in Kraft getreten. Ohne Änderung des Wortlauts findet sich das vorrangige Europäische Kartellrecht nun nicht mehr in Art. 85 ff. EG, sondern in Art. 101 ff. AEUV. § 1 GWB entspricht – bis auf den zwischenstaatlichen Handel – voll dem Art. 101 AEUV, beide erfassen gleichermaßen sowohl horizontale wie vertikale Verträge.

326

§ 2 Abs. 1 GWB entspricht dem Art. 101 Abs. 3 AEUV und § 2 Abs. 2 GWB 327 enthält eine dynamische Verweisung auf das EU-Recht: „(2) Bei der Anwendung von Absatz 1 gelten die Verordnungen des Rates oder der Kommission der europäischen Gemeinschaft über die Anwendung von Artikel 81 Abs. 3 des Vertrages zur Gründung der Europäischen Gemeinschaft (Anm: jetzt Art. 101 Abs. 3 AEUV) auf bestimmte Gruppen von Vereinbarungen, Beschlüsse von Unternehmensvereinigungen und aufeinander abgestimmte Verhaltensweisen 1 LG Bielefeld v. 13.10.1992, ECR LG 1929 – Kooperationspartner entwickelt Konkurrenzprodukt.

M. Brandi-Dohrn

559

E Rz. 328

Verträge

(Gruppenfreistellungsverordnungen) entsprechend. Dies gilt auch, soweit die dort genannten Vereinbarungen, Beschlüsse und Verhaltensweisen nicht geeignet sind, den Handel zwischen den Mitgliedstaaten der Europäischen Gemeinschaft zu beeinträchtigen.“

b) Art. 101 AEUV 328

Nach Art. 101 Abs. 1 und 2 AEUV sind wettbewerbsbeschränkende Vereinbarungen verboten, die geeignet sind, den zwischenstaatlichen Handel zu beeinträchtigen.

329

Es folgen in Art. 101 Abs. 2 AEUV Verbotsbeispiele, und diese Beispiele stellen i.d.R. die per se verbotenen Kernbeschränkungen dar, nämlich Preisbindungen, Marktaufteilungen und diskriminierende Bedingungen gegenüber Handelspartnern.

330

Art. 101 Abs. 3 AEUV sieht Freistellung vom Kartellverbot für nützliche Vereinbarungen vor, wenn sie zwar Wettbewerbsbeschränkungen enthalten, diese aber – der Verbesserung der Warenerzeugung oder -verteilung dienen oder zur Förderung des technischen oder wirtschaftlichen Fortschritts beitragen, – dazu unerlässlich sind, – die Verbraucher angemessen beteiligt werden und – wenn die Vereinbarungen nicht die Möglichkeit eröffnen, für einen wesentlichen Teil der betreffenden Waren den Wettbewerb auszuschließen.

331

Zu Art. 101 Abs. 3 AEUV gab es bisher die konstitutiven Einzel- bzw. Pauschalfreistellungen in Gruppenfreistellungsverordnungen (GVO). Es war das Vorrecht der Kommission, konstitutiv die Freistellung individuell oder gruppenweise zu erteilen. In der Praxis wurde aber die Masse der Freistellungsanträge nur noch mit sog. „Comfort Letters“ beschieden, nämlich nicht förmlichen Erlaubnissen, sondern lediglich Mitteilungen, dass die Kommission derzeit keinen Anlass zum Einschreiten sehe. c) Von der konstitutiven Freistellung zur Legalausnahme

332

Beginnend 1999 und formal in Kraft getreten am 1.5.2004 mit der neuen KartellVO wurden die konstitutiven Einzelfreistellungen durch ein System der Legalausnahmen ersetzt. Art. 101 Abs. 3 AEUV wirkt von Gesetzes wegen, wenn die dort genannten Voraussetzungen der Nützlichkeit und Erforderlichkeit erfüllt sind, und die betroffenen Unternehmen müssen selbst einschätzen, ob das der Fall ist, was sie also dürfen. Dazu helfen Leitlinien der Kommission.

333

Dieser Wandel ist formell durch die neue Kartellverordnung 1/2003 vom 16.12.20021 eingeführt. Sie ersetzt die frühere Kartellverordnung No. 17, die 1 ABl. EG 2003, L 1/1.

560

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 336 E

das Verfahren der konstitutiven Freistellung im Einzelnen regelte. Die Hauptpunkte der neuen KartellVO sind: – Art. 1 (2): Die Freistellung nach Art. 101 (3) AEUV wirkt von selbst, ohne vorherige Entscheidung, als Legalausnahme vom Kartellverbot. – Art. 3 (1), 5, 6: Die nationalen Kartellbehörden (BKartA in Bonn) und Gerichte wenden Art. 101 (1) = Verbot und Art. 101 (3) = Erlaubnis unmittelbar an. – Art. 3 (2): Vorrang des EU-Kartellrechts, keine Zwei-Schranken-Lehre mehr1. – Art. 2 – Beweislast: Für das Verbot ist der Kläger bzw. die Behörde beweispflichtig, für die Legalausnahme des Art. 101 (3) AEUV das betroffene Unternehmen. – Art. 10: Freistellungsentscheidungen auf Einzelantrag gibt es nicht mehr, allenfalls Freistellungen im öffentlichen Interesse. – Art. 5: Es gibt nur noch Comfort Letters. Im Hinblick auf den Vorrang des EU-Kartellrechts musste das nationale GWB mit eigenen Regelungen abdanken und verweist nunmehr dynamisch auf das EU-Kartellrecht und die darin erlassenen Gruppenfreistellungsverordnungen (GVO).

334

d) Die Gruppenfreistellungsverordnungen Für die vertikalen Austauschverträge, also selektive Vertriebssysteme, Al- 335 leinvertriebs- und Alleinbezugsvereinbarungen und Franchisesysteme ist die Vertikal-GVO2 mit vertikalen Leitlinien ergangen. Sofern die Vereinbarungen keine „schwarzen Klauseln“ enthalten, insbesondere keine Preisbindung und keinen absoluten Gebietsschutz, sind Austauschverträge, insbesondere Alleinvertriebs- und -bezugsvereinbarungen freigestellt, wenn der Lieferant oder Käufer nicht mehr als 30 % Marktanteil besitzt. Bei höheren Marktanteilen ist weder pauschal freigestellt noch verboten. Die Beteiligten müssen ihren Vertrag hinsichtlich der kartellrechtlichen Erlaubtheit selbst einschätzen. Sodann gibt es im vertikalen Verhältnis noch die Gruppenfreistellungsverordnung für Patent- und Know-How-Lizenzverträge, die GVTT3, die in ganz 1 Früher galt, dass eine Vereinbarung sowohl die Schranke des nationalen Kartellrechts wie auch die des EG-Kartellrechts überwinden musste: BGH v. 21.2.1978 – KVR 4/77 – Sachs/GKN, BGHZ 71, 102 (107): Fusion war EG-kartellrechtlich erlaubt, scheiterte aber am nationalen Kartellrecht. 2 Vertikal-GVO 330/2010 v. 20.4.2010, ABl. EU 2010 L 102,1, auch Beck Texte dtv 5009 WettbR Nr. 13. 3 Gruppenfreistellungsverordnung für Technologietransfer-Vereinbarungen (GVTT) v. 27.4.2004, ABL. EG 2004 L 123/11 mit Leitlinien dazu gemäß Bekanntmachung der Kommission über Leitlinien zur Anwendung von Art. 81 EG-Vertrag auf Technologie-Transfervereinbarungen in ABl. EG 2004 C 101/2.

M. Brandi-Dohrn

561

336

E Rz. 337

Verträge

engen Grenzen auch Softwarelizenzen (Lizenzen zur Vervielfältigung) umgreift. 337

Für die horizontale FuE-Zusammenarbeit und für die Aufteilung in der Produktion gelten die Gruppenfreistellungsverordnungen – FuE-GVO 1217/2010 vom 14.12.20101, die die alte FuE-GVO vom 29.11.2000 ersetzt, – Spezialisierungs-GVO 1218/2010 v. 14.12.20102, anstelle der alten Spezialisierung-GVO 2658/2000 vom 29.11.2000 mit den horizontalen Leitlinien dazu3.

338

Beide GVO stellen gemeinsame Verwertung unter gewissen Bedingungen pauschal frei. „Gemeinsame Verwertung“ umfasst kooperative und planmäßig aufgeteilte Verwertung, wie auch den Fall der Auftragsforschung und -entwicklung mit oder ohne gemeinsame Verwertung – Art. 1 A) iv, vi und Art. 1m) FuE-GVO, Definitionenkatalog: „Forschungs- und Entwicklungsvereinbarung“ und „gemeinsam“. Ob auch vertikale Forschungs- und Entwicklungsvereinbarungen den FuE-GVO-Freistellungsbedingungen unterfallen oder nur den liberaleren der Vertikal-GVO, war nach der alten FuE-GVO-2000 zweifelhaft. Die FuE-GVO ist dabei die speziellere und daher vorrangige Privilegierung: Liegt gemeinsame Forschung und Entwicklung als „Förderung des technischen und wirtschaftlichen Fortschritts“ – Art. 101 Abs. 3 AEUV – vor, so wird die gemeinsame oder aufgeteilte Verwertung unter Wettbewerbern, bzw. der finanzierenden Partei und ihren Auftragnehmern solange pauschal frei gestellt, als diese beteiligten Unternehmen nicht gemeinsam 25 % Marktanteil mit dem Entwicklungsprodukt oder mit konkurrierenden Produkten überschreiten – Art. 4 FuE-GVO. Spezialisieren sie sich nur in der Produktion ohne vorangegangene gemeinsame Forschung oder Entwicklung, so endet die Pauschalfreistellung bei einem kumulierten Marktanteil von 20 %. Im vorliegenden Themenbereich müssen wir uns also der FuE-GVO bei der horizontalen und vertikalen Zusammenarbeit zuwenden.

339

Werden die Marktanteile überschritten, so sind die Vereinbarungen zwar nicht pauschal freigestellt, aber auch noch nicht automatisch verboten. Es bedarf vielmehr einer Selbsteinschätzung – im Streitfall also einer Einschätzung durch die Gerichte, ob die Vereinbarung überhaupt unter Art. 101 Abs. 1 AEUV fällt, und wenn ja, ob die Legalausnahme nach Art. 101 Abs. 3 AEUV greift. Letzteres soll im Zweifel nicht der Fall sein, wenn die Vereinbarung eine der in einer GVO als „Kernbeschränkung“, hier also als in Art. 5 FuE-GVO schwarz gelisteten Klauseln enthält.

340

Nach Art. 2, 3 FuE-GVO 1217/2010 ist die Vereinbarung gemeinsamer Forschung und Entwicklung samt notwendigen Hilfsklauseln, auch bei aufge1 ABl. EU 2010 L 335/36. 2 ABl. EU 2010 L 335/43. 3 ABl. EU 2011 C 11/1.

562

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 345 E

teilter oder gemeinsam vergebener Produktion, unter gewissen Größenkriterien freigestellt, wenn nach Art. 3 FuE-GVO alle Vertragsparteien Zugang zu den Entwicklungsergebnissen für weitere Forschung oder auch für die Verwertung haben, und bei gemeinsamer oder aufgeteilter Verwertung die FuE-Ergebnisse durch Schutzrechte oder wesentliches Know-how ausgewiesen sind. „Zugang“ bedeutet einfache Nutzungslizenz und zugehörige Information. Der Zugang kann entsprechend vereinbarten Verwertungsbeschränkungen beschränkt werden, und bei Hochschulen auf Verwertung nur für weitere Forschung. Der Zugang, also die Nutzungserlaubnis, darf von einer Vergütung abhängig gemacht werden, wenn diese nicht prohibitiv für den Zugang ist. Ist die Verwertung in der Weise beschränkt, dass nur eine beteiligte Partei produziert, so muss sie alle Aufträge der anderen Kooperationspartner erfüllen, Art. 3 Abs. 5 FuE-GVO Nach Art. 4 Abs. 1 und 3 der FuE-GVO 1217/2010 ist die horizontale FuE- 341 Zusammenarbeit zwischen Nichtwettbewerbern zeitlich unbegrenzt freigestellt und gilt auch in der Verwertung wenigstens für sieben Jahre und solange weiter als die beteiligten Unternehmen keinen gemeinsamen Anteil von über 25 % am relevanten Markt der Vertragserzeugnisse erreichen. Gehören zu den Vertragspartnern Wettbewerber und Auftraggeber, die nicht 342 sonderlich stark sind – zusammen nicht mehr als 25 % Marktanteil auf dem FuE-Gebiet haben –, so gilt die Freistellung für die Dauer der Forschung und Entwicklung plus sieben Jahre nach Art. 4, Abs. 1, 2 FuE-GVO 1217/2010. Handelt es sich um marktstarke FuE-Partner – über 25 % Marktanteil auf dem FuE-Gebiet –, so müssen sie anhand der horizontalen Richtlinien selbst einschätzen, ob eine Wettbewerbsbeschränkung nach Art. 101 Abs. 1 und 3 AEUV trotz Größe zu verneinen ist.

343

Bei den Marktanteilen gilt nach Art. 7d) FuE-GVO eine Toleranzgrenze von 5 Prozentpunkten, also 25 %–30 % für zwei weitere Jahre, darüber ein weiteres Jahr.

344

Die FuE-GVO 1217/2010 enthält, wie die Vorgänger-FuE-GVO keine Liste 345 „weißer Klauseln“. Sie stellt also alle FuE-Vereinbarungen frei, wie kritisch man ihre Klauseln wettbewerblich auch halten mag, sofern sie den Freistellungskriterien in Zugang und Marktanteilsschwelle genügen und keine schwarzen Klauseln nach Art. 5 FuE-GVO enthalten. Nach den allgemeinen Leitlinien zur Anwendung von Art. 81 Abs. 3 EG Tz. 461 sollen die „schwarzen Klauseln“ in den GVO’s einen guten Hinweis darauf darstellen, was nicht notwendig sei. Im Gegenschluss heißt das: Was nicht schwarz gelistet ist, ist gruppenfreigestellt, wenn die Marktanteilsgrenzen nicht überschritten sind, und kann darüber hinaus bei der Selbsteinschätzung im allgemeinen als von Rechts wegen freigestellt angesehen werden. 1 Bekanntmachung der Kommission, Leitlinien zur Anwendung von Art. 81 Abs. 3 EG-Vertrag, ABl. EG 2004 C 101/97.

M. Brandi-Dohrn

563

E Rz. 346 346

Verträge

Schwarze Klauseln, die einer Gruppenfreistellung entgegenstehen, wenn auch nur eine enthalten ist, sind nach Art. 5 FuE-GVO 1217/2010: – Verbot von Forschung in nicht verwandten Gebieten oder nach Auslaufen des gemeinsamen FuE-Projekts, – Beschränkungen der Produktion oder des Absatzes, also Mengenbeschränkungen, mit einer Reihe von Ausnahmen für Produktions- und Absatzziele bei gemeinsamer Verwertung und für die Spezialisierung. – Preisbindungen, – Beschränkungen, passive Verkäufe in Gebiete oder an Kunden zu tätigen oder Lizenzen zu erteilen, wobei aber die Lizensierung der Ergebnisse ausschließlich an die andere Partei ausgenommen ist. Erlaubt ist damit die übliche ausschließliche Lizenz des Auftragnehmers an den Auftraggeber. – Gebietsbeschränkungen für aktive Verkäufe außer im Fall der gebietsmäßigen Spezialisierung, – Verbot passiver Verkäufe an Gebietsfremde und Verhinderung von Parallelimporten zweiter Hand. „Passive“ Verkäufe sind Bedienung von nicht aufgesuchten und beworbenen Bestellungen aus fremdem Gebiet. „Parallelimporte“ sind Importe von Waren, die im fremden Gebiet vom Importeur gekauft worden sind; – Verboten ist auch die Beschränkung des Bezugs von anderen Wiederverkäufern. 6. Materielles und immaterielles Ergebnis

347

Das materielle Ergebnis bei der Softwareentwicklung, die Verkörperung auf einem Datenträger, ist zwar für die Kontrolle der Fertigstellung und für die Übergabe wichtig, aber nicht als werthaltiges Eigentum wie ein gemeinsam errichtetes Bauwerk. Diente das Konsortium der Softwareerstellung für einen Dritten, so ist dem Dritten der verkörpernde Datenträger zu übergeben. Dient die Softwareerstellung eigenen Zwecken der Konsorten, so hat jeder in Verfolgung dieses Zwecks einen Anspruch gegen den anderen auf einen verkörpernden Datenträger. Das sind Hilfsansprüche zum Anspruch auf Nutzungsrechte. a) Urheberrecht

348

Wenn die Konsorten in der Kooperationsform der gemeinsamen Entwicklungstätigkeit ihrer Softwareingenieure und/oder Programmorganisatoren tätig werden, um ein Programm entstehen zu lassen, so sind die Angestellten Miturheber des gemeinsamen Programms nach § 8 UrhG. Miturheberschaft entsteht, wie der BGH in „Buchhaltungsprogramm“1 ausgeführt hat, 1 BGH v. 14.7.1993 – I ZR 47/91 – Buchhaltungsprogramm, CR 1993, 752 = GRUR 1994, 39.

564

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 351 E

durch gemeinsames Schaffen der Beteiligten, bei dem jeder einen schöpferischen Beitrag leistet, der in das gemeinsame Werk einfließt. Die Beiträge können auch stufenweise geleistet werden, z.B. der eine wird in der Planungsphase eines Programms und der andere bei der Implementierung tätig. Die Implementierung muss aber auch ein eigenständig kreativer Beitrag sein. Werden die Beiträge aber zeitlich nacheinander geleistet, so scheiden sich spätere Bearbeitung nach § 23 UrhG von Miturheberschaft nach § 8 UrhG daran, ob auch der frühere Bearbeiter sein Werk als ergänzungsbedürftig gesehen hat1. Die Miturheber müssen auch nicht jeden schöpferischen Beitrag gemeinsam erbringen. Es reicht aus, dass jeder in Unterordnung unter die gemeinsame Gesamtidee einzelne schöpferische Beiträge erbringt. Entsprechend § 69b UrhG stehen die mit dem Miturheberrecht verbundenen vermögensrechtlichen Befugnisse an dem Computerprogramm den jeweiligen Arbeitgebern, also den Consortialunternehmen zu, und zwar, wenn nicht anderes vereinbart ist, als gemeinsame Beiträge also als BGBGesamthandsvermögen nach § 718 BGB. Nach § 8 Abs. 2 UrhG stehen den Konsortialmitgliedern die Verwer- 349 tungsrechte grundsätzlich nur gemeinsam zu. Unabgesprochene Einzelveräußerung des Programms ohne den anderen ist Verletzung des Gesellschaftsvertrags und Urheberrechtsverletzung2. Die Miturheber bzw. die vermögensrechtlichen Nachfolger nach § 69b UrhG dürfen aber ihre Zustimmung zur Verwertung nach § 8 Abs. 2 UrhG nicht wider Treu und Glauben verweigern. Die Erträge aus der Verwertung gebühren den Miturhebern nach § 8 Abs. 3 UrhG nach ihrem schöpferischen Beitrag, wenn nichts anderes vereinbart ist. Wird die Kooperation so durchgeführt, dass jeder Partner bei sich ein Pro- 350 gramm oder Programmmodul schafft, das für sich ein Werk darstellt, so sind sie Alleinurheber der jeweiligen Werke, die zur gemeinsamen Verwertung verbunden sein mögen. Es handelt sich dann um ein verbundenes Werk nach § 9 UrhG, bei dem jeder vom anderen Einwilligung nach Treu und Glauben in die Verwertung und auch zu zweckmäßigen Änderungen, z.B. zu Updates des verbundenen Werks verlangen kann. Das verbundene Werk wird wiederum, sei es auch nur im Durchgang zum Drittauftraggeber, Gesamthandsvermögen der Konsortialgesellschaft nach § 718 BGB. Schließlich kann es auch so sein, dass die Kooperationspartner für die Softwareentwicklung ein Gemeinschaftsunternehmen eingesetzt haben. Dieses hat dann von seinen Angestellten über § 69b UrhG allein die vermögensrechtlichen Befugnisse an dem Programm, und es ist eine Frage der getroffe1 BGH v. 3.3.2005 – I ZR 111/02 – Fash 2000, CR 2005, 854 = GRUR 2005, 860 (863). 2 Im Fall BGH v. 14.7.1994 – I ZR 47/91 – Buchhaltungsprogramm, CR 1993, 752 = GRUR 1994, 39, hatte die eine an der Entwicklung beteiligte Firma gegen die andere wegen Urheberrechtsverletzung geklagt, weil sie das Programm bei einem ihrer Kunden installiert hatte.

M. Brandi-Dohrn

565

351

E Rz. 352

Verträge

nen Vereinbarungen, welche Nutzungsrechte die Tochtergesellschaft an wen einzuräumen hat. 352

In all diesen Fällen ist bei Auftragsentwicklungen der angestellte Softwareentwickler mit seinem Arbeitslohn abgefunden. Die Vermögensrechte an dem Programm stehen nach § 69b UrhG dem Arbeitgeber ohne die Bedingung zu, eine zusätzliche Vergütung zahlen zu müssen1. b) Patentrecht

353

Das Recht auf das Patent nach § 6 PatG, Art. 60 EPÜ entsteht zuerst einmal in der oder den Personen der Erfinder/Miterfinder und wird von da auf das Arbeitgeber-Konsortialunternehmen übergeleitet werden. Das geschieht in Deutschland mit den Mitteln der Meldung und der fingierten Inanspruchnahme, wenn nicht bis vier Monate nach Meldung freigegeben wird, und gegen angemessene Arbeitnehmererfindervergütung nach dem ArbEG2. Im Ausland stehen die Verwertungsbefugnisse meist von Gesetzes wegen ohne weitere Vergütung dem Arbeitgeber zu.

354

Arbeiten die Softwareingenieure und Programmorganisatoren der Konsortialpartner in der Entwicklung tätig zusammen, so ist jeder Miterfinder, der einen kreativen Beitrag leistet, welcher für sich genommen nicht unbedingt erfinderisch sein muss. Lediglich nur ausführende Arbeiten auf Anweisung scheiden als qualifizierte Beiträge aus3. Auf das Arbeitgeberunternehmen im Konsortium geht dann als Rechtsnachfolger auf dem Weg über die fingierte Inanspruchnahme nach dem ArbEG die Miterfinderstellung über und fließt als Konsortialbeitrag in das Gesamthandsvermögen des BGB Konsortiums nach § 718 BGB ein, wenn nichts anderes vereinbart ist.

355

Arbeiten die Konsorten arbeitsteilig so, dass jeder einen abgegrenzten Teil entwickelt, und fallen innerhalb dieser Teilentwicklungen Erfindungen an, so verbleiben die abgeleiteten Erfinderrechte auf das Patent und die Patentrechte bei dem jeweiligen Konsorten und werden, wenn nicht anders vereinbart, nicht quoad dominium voll in die Gesellschaft eingebracht, sondern nur quoad usum. Es werden also nur Nutzungsrechte eingeräumt. Das ergibt sich aus dem Zweckübertragungsgrundsatz in § 31 Abs. 5 UrhG, weil in aller Regel die Nutzung durch die Gesellschafter für die Entwicklung ausreicht, und aus dem allgemeinen Grundsatz im Immaterialgüterrecht, dass im Zweifel der Rechtsinhaber nicht mehr Rechte vergibt als er ausdrücklich vereinbart4. 1 BGH v. 24.10.2000 – X ZR 72/98 – Wetterführungspläne I, GRUR 2001, 155 = CR 2001, 223 mit Anm. A. Brandi-Dohrn CR 2001, 285. 2 Vgl. oben Kap. E Rz. 80 ff. 3 BGH v. 5.5.1966 – Ia ZR 110/64 – Spanplatten, GRUR 1966, 558; BGH v. 17.1.1995 – X ZR 130/93 – Gummielastische Masse, DB 1995, 1661 = Mitt. 1996, 16; BGH v. 16.9.2003 – X ZR 142/01– Verkranzungsverfahren, GRUR 2004, 50. 4 Vgl. BGH v. 11.4.2000 – X ZR 185/97 – Gleichstromsteuerschaltung, GRUR 2000, 788, vgl. oben Kap. E Rz. 100.

566

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 361 E

Vollzieht sich die Zusammenarbeit im Konsortium über die Beauftragung einer gemeinsamen Tochtergesellschaft als Gemeinschaftsunternehmen, so ist dieses erster Rechtsnachfolger kraft fingierter Inanspruchnahme von seinen Angestellten in die Erfinderrechte auf das Patent und später ggf. der Rechte aus dem Patent. Nicht selten ist es aber so, dass die Entwicklungstochter die Patentrechte auf die Muttergesellschaften zu übertragen hat.

356

Jedes Unternehmen, das in Kooperation mit anderen Partnern oder als Ge- 357 meinschaftsunternehmen im Auftragsverhältnis entwickelt, ist sowohl für die Überleitung von Erfindungen seiner Arbeitnehmer auf sich zur Weitergabe an Auftraggeber oder Kooperationspartner verantwortlich wie auch für etwaige Erfindervergütungen nach § 9 ArbEG an seine Arbeitnehmer. Vorbehaltlich des AÜG bleibt auch der zum anderen Kooperationspartner entsandte Arbeitnehmer eigener Arbeitnehmer des Entsenderunternehmens1. Vergütungspflichtig für Erfindungen wird nicht der Kooperationspartner, 358 bei dem entwickelt wird, sondern der entsendende Kooperationspartner, mit dem das Arbeitsverhältnis besteht. Basis für die Vergütung ist grundsätzlich der geldwerte Nutzen, den derjenige Kooperationspartner zieht, dessen Arbeitnehmer Vergütung beansprucht2. Erzielt nur ein Partner Verwertungsumsatz an Dritte und der andere nichts, 359 so ist zu prüfen, ob der nicht verwertende Partner wirklich keinerlei Nutzen hat oder ob nicht ein mittelbarer Nutzen zu schätzen ist. Sind nutzender und leer ausgehender Kooperationspartner gesellschaftlich verbunden, so kann eine teilweise Zuordnung des Umsatzes vom nutzenden Partner zum nur entwickelnden Partner in Betracht kommen. Richtiger ist es aber wohl, eine fiktive Lizenz anzusetzen3. Liefert der eine Kooperationspartner nicht nur erfinderische Ideen, sondern ein nutzbares Produkt zur Eigenverwendung an den anderen, so legt das OLG Frankfurt den Verwertungsumsatz als gemeinsamen Nutzen bei beiden für die Vergütung zugrunde4.

360

Bei der Entwicklungstochter ist es der Gewinnzuschlag über die Entwick- 361 lungskosten, falls nicht unangemessen niedrig, der als Kaufpreis für die 1 Schiedsstelle v. 19.6.1991 – ArbErf 070/90 – Entsendung zur spanischen Tochtergesellschaft, ArbEG-CD-ROM. 2 Vgl. oben Kap. E Rz. 95 ff.; Schiedsstelle v. 22.2.1991, – Arb.Erf. 79/89, GRUR 1992, 390 – Medikalprodukte; Schiedsstelle v. 9.9.1993 – ArbErf 155/92 – Vergütung bei Auftragsentwicklung – referiert bei Bartenbach, Aktuelle Probleme des gew. Rechtsschutzes 1994, 143; Schiedstelle v. 22.10.2010 – ArbErf 023/09 – Löschen von Koks, bei Bartenbach, Aktuelle Probleme des gew. Rechtsschutzes 2011 I 357/368; Bartenbach/Volz, ArbEG, Rz. 192 ff. zu § 9 ArbEG. 3 Schiedsstelle v. 29.10.1997 ArbErf 013/96, Bartenbach, Gew. Rechtsschutz 1998, 146: fiktive brutto Lizenz minus 60 % für kalkulatorischen Unternehmerlohn und Gemeinkosten. 4 OLG Frankfurt v. 30.4.1992 – 6 U 98/89 – Simulation von Radioaktivität, GRUR 1992, 852; vgl. oben Kap. E Rz. 100.

M. Brandi-Dohrn

567

E Rz. 362

Verträge

Schutzrechte, reduziert auf den Nettoanteil von 30–40 %, den Erfindungswert als Vergütungsbasis bildet1, denn auch freie Unternehmer hätten nicht Weitergabe des vollen Gewinnanteils vereinbart. Der „Verkäufer“ hätte Schutzrechtskosten, Gemeinkosten und kalkulatorischen Unternehmerlohn abgezogen. 362

Entscheidendes Kriterium, insbesondere bei freier Nutzung durch andere Konzerngesellschaften oder bei Schutzrechtsübertragungen auf die Konzernmutter/Konzernmütter ist nach BGH „Abgestuftes Getriebe“2 immer: was hätten vernünftige freie Lizenzvertragsparteien als Bemessungsgrundlage vereinbart. c) Übliche Sondervereinbarungen

363

Bei untrennbar verwobenen Beiträgen der Konsortialpartner bzw. ihrer zusammenarbeitenden Angestellten zu entstehenden Immaterialgüterrechten (Urheberrechten oder Patenten) werden diese zu gemeinsam gehaltenem Gesamthandsvermögen. Dieses wird gemeinsam verwaltetet und die Aufrechterhaltungskosten (Erteilungskosten und Jahresgebühren bei Patenten) tragen die Gesellschafter des BGB-Konsortiums anteilig. Tunlichst schließt man aber Vereinbarungen, um diese dauerhafte Aneinanderkettung zu vermeiden.

364

Die Ipal als Patentverwertungsstelle der Berliner Universitäten hat in Zusammenarbeit mit der Industrie Musterverträge (sog. Berliner Verträge3) entwickelt, in denen die Zuordnung, selbst bei untrennbaren Beiträgen nach dem Grad des Beitrags separiert wird: – Beitrag der Universität # 50 %: Schutzrechte gehören dem Industriepartner, die Universität hat aber ein einfaches Nutzungsrecht für Forschung und Lehre. – Beitrag der Universität $ 50 %: Schutzrechte gehören der Universität aber der Industriepartner hat eine Option auf eine ausschließliche Lizenz vorbehaltlich eines einfachen Nutzungsrechts für die Universität für Forschung und Lehre. 1 OLG München v. 8.2.2001, GRUR-RR 2001, 103 – Verankerungsmittel: 4–4,5 % Gewinnaufschlag angemessen. Die geschätzte Reduktion auf den Nettoanteil nimmt die Schiedsstelle deshalb vor, weil Schutzrechtskosten und nicht vergütungspflichtiges Know-how abgehen und weil auch bei einem Erwerb von einem freien Erfinder der Unternehmer bei der Preisvereinbarung einen kalkulatorischen Unternehmerlohn abgezogen hätte. Schiedsstelle v. 8.9.1995, Mitt 1996, 176 – Patentkauf; Bartenbach/Volz, Rz. 252 zu § 9 ArbEG; vgl. dazu auch oben Kap. E Rz. 90. 2 BGH v. 16.4.2002, GRUR 2002, 801 – Abgestuftes Getriebe – zur Frage der Auskunftspflicht gegenüber dem Arbeitnehmer über den Konzernaußenumsatz; dazu auch Meier-Beck, FS Tilmann (2003), S. 539. 3 Erhältlich auf der Webseite der Humboldt-Universität http://www.hu-berlin.de/ forschung/administration/ad_vertraege_forschung_html/0000bvfk3.pdf.

568

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 366 E

Es sind eine Reihe weiterer Musterverträge entwickelt worden, z.B. der 365 Hamburger Vertrag1. Das ist ein Vertrag zwischen industriellem Partner, Hochschule und Professor als Projektleiter, der auf einen unmittelbaren Rechtsübergang aller Ergebnisse, ob schutzfähig oder nicht, auf den industriellen Partner gegen eine gesplittete Vergütung abzielt: zwei Teile an die Hochschule für personelle und materielle Ressourcen und für den Vorausverzicht auf Schutzrechte, ein Teil an den Projektleiter und sein Team für die Rechte. Die Hochschule verzichtet im Voraus auf die Inanspruchnahme und der Projektleiter und jedes Mitglied seines Teams übertragen die etwaigen, somit frei gewordenen Erfindungen an den industriellen Partner. Der leistet damit freilich eine „Erfindervergütung“ für künftige Ergebnisse, die vielleicht gar keine Erfindungen sind. Sind es von vornherein separate Beiträge, die dem Konsortialzweck dienen, 366 so werden Schutzrechte im Allgemeinen nicht Gesellschaftsgesamthandsvermögen, sondern der einzelne Konsorte bleibt Schutzrechtsinhaber und vergibt Nutzungsrechte (Lizenzen) an die anderen. Was hier üblich ist, zeichnen die Art. 47–51 der Beteiligungsregeln bei EU-FuE-Förderung2 nach: Artikel 48 Grundsätze 1. Die Einräumung von Zugangsrechten wird schriftlich beantragt. 2. Zugangsrechte schließen nicht das Recht ein, Unterlizenzen zu vergeben, es sei denn, der Inhaber der bestehenden oder neuen Kenntnisse hat dem zugestimmt. 3. Die Vergabe ausschließlicher Lizenzen für neue oder bestehende Kenntnisse und Schutzrechte ist möglich, sofern alle anderen Teilnehmer schriftlich auf ihre diesbezüglichen Zugangsrechte verzichten. 4. Unbeschadet der Regelung in Absatz 3 wird in jeder Vereinbarung, mit der Teilnehmern oder Dritten Rechte auf Zugang zu bestehenden oder neuen Kenntnissen und Schutzrechten eingeräumt werden, sichergestellt, dass potenzielle Zugangsrechte für andere Teilnehmer gewahrt bleiben. 5. Unbeschadet der Artikel 49 und 50 sowie der Finanzhilfevereinbarung unterrichten sich Teilnehmer derselben Maßnahme so rasch wie möglich gegenseitig über Beschränkungen der Einräumung von Rechten auf Zugang zu bestehenden Kenntnissen und Schutzrechten oder jede andere Beschränkung, die die Einräumung von Zugangsrechten wesentlich berühren kann. 6. Beendet ein Teilnehmer seine Teilnahme an einer indirekten Maßnahme, so hat dies keinerlei Auswirkungen auf die Verpflichtung dieses Teilnehmers, den verbleibenden Teilnehmern derselben Maßnahme Zugangsrechte gemäß den Bedingungen der Finanzhilfevereinbarung zu gewähren.

1 Klawitter/Zintler, Mitt. 2006, 116. 2 VO (EG) 1906/2006 v. 18.12.2006 über Regeln für die Beteiligung von Unternehmen … an Maßnahmen des Siebten Rahmenprogramms sowie für die Verbreitung der Forschungsergebnisse (2007–2013), ABl. EU 2006 L 391/1.

M. Brandi-Dohrn

569

E Rz. 366

Verträge

Artikel 49 Zugangsrechte für die Durchführung einer indirekten1 Maßnahme 1. Den anderen Teilnehmern derselben indirekten Maßnahme sind Zugangsrechte zu neuen Kenntnissen und Schutzrechten einzuräumen, soweit dies erforderlich ist, um diese Teilnehmer in die Lage zu versetzen, ihre Arbeit im Rahmen dieser indirekten Maßnahme durchzuführen. Solche Zugangsrechte sind unentgeltlich einzuräumen. 2. Den anderen Teilnehmern derselben indirekten Maßnahme sind Zugangsrechte zu bestehenden Kenntnissen und Schutzrechten einzuräumen, soweit dies erforderlich ist, um diese Teilnehmer in die Lage zu versetzen, ihre Arbeit im Rahmen dieser indirekten Maßnahme durchzuführen und soweit der betreffende Teilnehmer zur Einräumung der Rechte befugt ist. Solche Zugangsrechte sind unentgeltlich einzuräumen, soweit keine andere Vereinbarung zwischen allen Teilnehmern vor ihrem Beitritt zur Finanzhilfevereinbarung getroffen wurde. FTE-Akteure2 räumen indes Zugangsrechte zu bestehenden Kenntnissen und Zugangsrechten unentgeltlich ein. Artikel 50 Zugangsrechte für die Nutzung 1. Die Teilnehmer derselben indirekten Maßnahme haben ein Recht auf Zugang zu neuen Kenntnissen und Schutzrechten, wenn dies für die Nutzung ihrer eigenen neuen Kenntnisse und Schutzrechte erforderlich ist. Solche Zugangsrechte sind zu fairen und angemessenen Bedingungen oder unentgeltlich einzuräumen; dies bedarf einer Vereinbarung. 2. Teilnehmer derselben indirekten Maßnahme haben ein Recht auf Zugang zu bestehenden Kenntnissen und Schutzrechten, wenn dies für die Nutzung ihrer eigenen neuen Kenntnisse und Schutzrechte erforderlich ist und soweit der betreffende Teilnehmer zur Einräumung der Zugangsrechte befugt ist. Solche Zugangsrechte sind zu fairen und angemessenen Bedingungen oder unentgeltlich einzuräumen; dies bedarf einer Vereinbarung. 3. Eine in einem Mitgliedstaat oder assoziierten Land ansässige verbundene Rechtsperson hat ebenfalls die in den Absätzen 1 und 2 genannten Rechte auf Zugang zu neuen und bestehenden Kenntnissen und Schutzrechten, und zwar zu den gleichen Bedingungen wie der Teilnehmer, mit dem sie verbunden ist, es sei denn, in der Finanzhilfevereinbarung oder der Konsortialvereinbarung ist etwas Anderes bestimmt. 4. Ein Ersuchen um Zugangsrechte nach den Absätzen 1, 2 und 3 kann bis zu einem Jahr nach dem Eintritt eines der folgenden Ereignisse gestellt werden:

1 „Indirekte Maßnahmen“ sind Förderungen von Industriekooperationen. Der Fördersatz beträgt regelmäßig bis 50 %. „Direkte Maßnahmen“ sind unmittelbare Finanzierung (regelmäßig 100 %) von EU-Forschungseinrichtungen. 2 „FTE-Akteure“ meint beteiligte Universitäten und öffentliche Forschungseinrichtungen nach Art. 2 Nr. 18 der Definitionen in der BeteiligungsVO 1906/2006, die ihrerseits auf Annex III des 7. Rahmenprogramms verweist, wo in Ziff. 6 bei der Förderung für bestimmte Gruppen, insbesondere kleine und mittlere Unternehmen, solche Institutionen genannt werden.

570

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 368 E

a) der Beendigung der indirekten Maßnahme; b) der Beendigung der Teilnahme durch den Eigentümer der betreffenden bestehenden oder neuen Kenntnisse und Schutzrechte. Die betreffenden Teilnehmer können jedoch abweichende Fristen vereinbaren. 5. Vorbehaltlich der Zustimmung aller betroffenen Eigentümer werden FTE-Akteuren zum Zwecke der Verfolgung weiterer Forschungsaktivitäten Rechte auf Zugang zu neuen Kenntnissen und Schutzrechten zu fairen und angemessenen Bedingungen eingeräumt, die zu vereinbaren sind. 6. FTE-Akteure räumen unentgeltlich oder zu fairen und angemessenen Bedingungen, die vor der Unterzeichnung der Finanzhilfevereinbarung zu vereinbaren sind, Zugangsrechte zu bestehenden Kenntnissen und Schutzrechten ein, die für die Nutzung der aus der indirekten Maßnahme entstandenen neuen Kenntnisse und Schutzrechte erforderlich sind.

Zusammengefasst: üblich sind kostenlose Lizenzen an die Konsorten zur 367 Entwicklung und zu fairen und angemessenen Bedingungen am Entwicklungsergebnis zur Nutzung des Ergebnisses. Werden vorbestehende Rechte zur kommerziellen Nutzung benötigt, so werden sie entgeltlich lizenziert. Bei der EU-Förderung gilt, dass vorbestehende Rechte auch dann unentgeltlich oder entgeltlich zu fairen und angemessenen Bedingungen genutzt werden dürfen, wenn sie nicht bei Vertragsschluss ausgenommen worden sind. Bemerkenswert ist, dass unter dem 7. Rahmenprogramm EU-geförderte Entwicklungsergebnisse auch exklusiv an einen Teilnehmer oder einen Außenstehenden lizensiert werden dürfen, wenn alle Teilnehmer an der Kooperation zustimmen. Außerhalb der EU-Förderung gelten die vorzitierten Regelungen nicht von Gesetzes wegen, wenn nichts anderes vereinbart ist, sondern die Rechtseinräumung richtet sich nach dem Zweckübertragungsgrundsatz in § 31 Abs. 5 UrhG, nämlich nach dem Zweck der Konsortialzusammenarbeit. Auch dabei sind aber die vorzitierten üblichen Nutzungsrechte aus den EU-Beteiligungsregeln eine Hilfestellung. 7. Leistungsstörungen Jeder Gesellschafter hat nach § 705 BGB die vereinbarten Beiträge, z.B. Ent- 368 wicklungsarbeiten zu leisten. Eine Erhöhung der vereinbarten Beiträge schuldet er ohne seine Zustimmung nach § 707 BGB nicht. Bestehen die Beiträge der Gesellschafter zur Gesellschaft in Softwareerstellungsleistungen und sind diese mangelhaft, so haften sie, wenn nichts anderes vereinbart ist, gesellschaftlich nicht nach Dienst- oder Werkvertrag, sondern die Einlage ist mit ihrem gemeinen, etwa mangelgeminderten Wert anzusetzen und entweder nach § 705 BGB wertmäßig aufzufüllen oder in der Auseinandersetzung nach § 733 Abs. 2 Satz 2 BGB mit ihrem tatsächlichen, geminderten Wert anzusetzen1. 1 BGH v. 2.5.1966, BGHZ 45, 338/345; BGH v. 24.6.1985 – II ZR 255/84, FamRZ 1985, 1232 = NJW 1986, 51 – Auseinandersetzung einer nichtehelichen Lebensgemeinschaft – mit drei Häusern, für die ein Partner stark mangelhafte Eigenleistungen erbracht hatte.

M. Brandi-Dohrn

571

E Rz. 369 369

Verträge

Der Haftungsmaßstab unter den Gesellschaftern ist vermindert. Nach § 708 BGB wird nicht für jede Fahrlässigkeit gehaftet, sondern nur für die Sorgfalt wie in eigenen Angelegenheiten (diligentia quam in suis). Im ARGE-Softwareprojektvertrag für einen Dritten hat das wenig Auswirkung: Jeder Gesellschafter haftet im vertikalen Auftragsverhältnis dem Auftraggeber voll für jede Fahrlässigkeit und ist nach Maßgabe des Außenvertrages gewährleistungspflichtig für seinen Leistungsteil. Leistet einer nicht, so müssen die anderen als Gesamtschuldner einspringen und haben dann unabgemilderte Ausgleichsansprüche gegen den Ausgefallenen und anteilsmäßig gegen die übrigen Konsorten, § 426 BGB. Dabei bleibt die Erfüllungsforderung des durch sie befriedigten Dritten erhalten und geht auf die leistenden Gesamtschuldner zum Rückgriff über1. 8. Beendigung und Auseinandersetzung

370

Die Gesellschaft als Projekt-Konsortium oder ARGE endigt nach § 726 BGB, wenn der Zweck erreicht, das Projekt also ausgeführt ist, oder wenn die Zweckerreichung unmöglich geworden ist, etwa weil der Drittauftraggeber nach § 649 BGB gekündigt hat. Die Projekt-Konsorten können eine werkvertragliche Softwareentwicklung dem Drittauftraggeber grundsätzlich nicht aufkündigen, denn ein solches Entweichen aus der Erfüllungspflicht sieht das Werkvertragsrecht nicht vor, und alle Konsorten sind nach § 714 BGB gesamtschuldnerisch zur Erfüllung verpflichtet. Bei einem dienstvertraglichen Auftragsverhältnis mag eine Kündigung nach § 627 Abs. 2 BGB denkbar sein, vor Vollendung des Softwareprojekts ist sie aber in aller Regel zur Unzeit.

371

Mit Beendigung = Auflösung tritt die Gesellschaft in das Abwicklungs- oder Auseinandersetzungsstadium nach §§ 730–735 BGB ein. Nach § 733 BGB sind vorab die Außenschulden zu begleichen. Alsdann sind, wenn nichts anderes vereinbart ist, § 731 BGB, die nur zur Nutzung überlassenen Gegenstände zurückzugeben. Bei im Konsortium eingeräumten Softwarenutzungsrechten werden diese aber regelmäßig dauerhaft entgeltlich oder unentgeltlich eingeräumt sein. Auch bei untrennbaren Gemeinschaftsentwicklungen ist es äußerst kontraproduktiv, die Immaterialgüterrechte nach §§ 731, 753 BGB durch Verkauf zu versilbern, um dann den Erlös zu teilen. Besser ist die Vereinbarung, sie als einfache Gemeinschaft nach §§ 741 BGB zu halten mit Nutzungsbefugnissen durch die beteiligten Konsorten zu einem Einmal-Schätzpreis. Aus dem verbleibenden Gesellschaftsvermögen sind dann nach § 733 Abs. 2 BGB die Einlagen nach ihrem wahren Wert zurückzuerstatten. Nach § 733 Abs. 2 Satz 3 BGB kann dabei für eine Einlage, die in der Leistung von Diensten oder in der Einräumung eines Nutzungs1 BGH v. 20.1.1990, NJW 1991, 97 – Gesamtschuldnerausgleich bei Konkurs eines Gesamtschuldners: Auf das ARGE-Mitglied, das die Leistung des wegen Konkurses ausgefallenen Mitglieds erbringt, geht nach §§ 426 Abs. 2, 401 BGB auch eine vom ausgefallenen Unternehmen gestellte Gewährleistungsbürgschaft über.

572

M. Brandi-Dohrn

Softwareentwicklung durch Dritte

Rz. 372 E

rechts bestand, keine Vergütung verlangt werden, wenn sie sich nicht als bleibender Wert im Gesellschaftsvermögen niedergeschlagen haben. Diese abweichende Gestaltung kommt besonders in Betracht bei einem gemeinsam für die Konsorten erstellten Softwareprogramm, das sie als einfache Gemeinschaft jeweils weiter nutzen. Der Rest des Gesellschaftsvermögens wird alsdann nach vereinbarten Gewinnanteilen nach § 734 BGB verteilt. Betreiben die Beteiligten nicht nur Forschung und Entwicklung, sondern 372 auch die Verwertung gemeinschaftlich, so setzen sie die BGB-Gesellschaft mit einem gemeinsamen Zweck fort1. Werden nach der gemeinsamen FuEPhase die gemeinsamen Schutzrechte nur noch individuell genutzt, so fragt es sich, ob die FuE-Gesellschaft nach § 705 BGB fortbesteht (kein freier Partnerwechsel), oder ob sie auf die tiefere Stufe der Gemeinschaft nach §§ 741 ff. BGB zurücksinkt (freier Partnerwechsel)2. Da das Gesamthandsvermögen der Gesellschaft sich nicht ohne einen rechtsgeschäftlichen Akt in Bruchteilseigentum der Gemeinschaft wandeln kann, besteht auch nach Erreichen des ursprünglichen Hauptzwecks die Gesellschaft im Auseinandersetzungsstadium fort, solange sie nicht liquidiert ist. Die Fortsetzung der Partnerbindung entspricht der früheren aktiven Zusammenarbeit besser. Vorsorgliche Regelungen des Rechts zur Anteilsübertragung sind empfehlenswert. Ist die Anteilsübertragung frei, so sollte vereinbart werden, dass der bisherige Partner die Vorhand (first right of refusal) zur Übernahme des Anteils erhält.

1 RG v. 30.1.1911, MuW 1910/11, 243 – Tantalinstrumente; RG v. 11.11.1914, MuW 1914/15, 328 – Gemeinsame Erlangung und Ausnutzung von Patenten über eine bühnentechnische Erfindung. 2 Axster, in: Gesetz gegen Wettbewerbsbeschränkungen und Europäisches Kartellrecht, Gemeinschaftskommentar, Anh. zu §§ 20, 21 GWB Rz. 24, für Fortsetzung als Gemeinschaft; a.A. Bruchhausen, in: Benkard, PatG, GebrMG, 9. Aufl. 1993, § 6 PatG Rz. 36 unter Hinweis auf RG: Die Gesellschaft besteht im Zweifel auf die Dauer des Patents.

M. Brandi-Dohrn

573

F. Internationale Softwareerstellungsverträge Rz.

Rz.

I. Urheberrechtliche Aspekte . . . . 2 1. Anwendbares Recht, Nutzungsrechte, Urheberpersönlichkeitsrechte . . . . . . . . . . . . . . . 2 2. Patentschutz für Software . . . . . 10

1. Internationale Zuständigkeit, Prorogation sowie Anerkennung und Vollstreckung ausländischer Urteile . . . . . . . . . . . . 40 2. Schiedsgerichtsbarkeit . . . . . . . . 50 3. Mediation . . . . . . . . . . . . . . . . . . . 56

II. Vertragsrechtliche Aspekte. . . . 1. Erfolgsverpflichtung des Auftragnehmers. . . . . . . . . . . . . . 2. Haftungsregelungen . . . . . . . . . . 3. Grenzen des AGB-Rechts . . . . . 4. Anwendbarkeit des UN-Kaufrechts . . . . . . . . . . . . . . . . . . . . . . .

14

IV. Insolvenz des Auftragnehmers . 59 14 21 29 33

V. Datenschutz . . . . . . . . . . . . . . . . . 70 VI. Exportkontrolle . . . . . . . . . . . . . . 74 Sonderproblem: Copyleft Effekt nach der GNU GPL . . . . . 90

III. dispute resolution clauses (Streitlösungsklauseln) . . . . . . . 40

In den Zeiten der Globalisierung ist internationale Zusammenarbeit üblich. In diesem Beitrag sollen einige typische Aspekte erläutert werden, die sich bei der Verhandlung und beim Abschluss von Softwareerstellungsverträgen im internationalen Umfeld stellen, d.h wenn Auftraggeber und Auftragnehmer aus unterschiedlichen Ländern kommen und deshalb eine grenzüberschreitende Konstellation gegeben ist.

1

I. Urheberrechtliche Aspekte 1. Anwendbares Recht, Nutzungsrechte, Urheberpersönlichkeitsrechte Das Urheberrecht gehört zu den Rechtsbereichen, die international gesehen, 2 schon sehr früh durch die sog. Revidierte Berner Übereinkunft aus dem Jahre 1886 und dann etwa ein Jahrhundert später durch weitere Abkommen1 eine gewisse Rechtsvereinheitlichung erlebt haben. In der EU ist insoweit natürlich die grundlegende Computerrechtsrichtlinie2 aus dem Jahre 1991 zu nennen, durch die das Urheberrecht für Computerprogramme stark vereinheitlicht wurde. Grundsätzlich ist das Territorialitäts- bzw. Schutzlandprinzip nach h.M.3 für die Frage maßgeblich, welches Urheberrecht bei internationalen Sachverhalten Anwendung findet. Da das Urheberrecht als vom 1 WIPO Urheberrechtsvertrag v. 20.12.1996, TRIPS Übereinkommen v. 15.4.1994, siehe dazu bei Schricker/Katzenberger, Urheberrecht, 4. Aufl. 2010, vor §§ 120 ff. Rz. 50 ff. bzw. Rz. 13 ff. 2 Richtlinie 91/250/EWG ABl. Nr. L 122 v. 17.5.1991. 3 Schricker/Katzenberger, Urheberrecht, Vor §§ 120 ff. Rz. 120 ff.; BGHZ 136, 380 ff. – Spielbankaffaire.

Lejeune

575

F Rz. 3

Verträge

Staat gewährt gilt, entzieht sich die Frage des anwendbaren Urheberrechts insbesondere der Verfügungsbefugnis der Parteien, so dass insoweit keine Rechtswahl zulässig wäre1. 3

Unabhängig davon, welches Urheberrecht im Einzelfall maßgeblich sein wird, dürften die folgenden Fragestellungen beim Abschluss von internationalen Softwareerstellungsverträgen immer zu klären sein.

4

Für den Auftraggeber eines Softwareerstellungsvertrages sind in erster Linie die vermögensrechtlichen Nutzungsrechte von Bedeutung. Insofern versucht der Auftraggeber in der Regel, den Auftragnehmer dazu zu bewegen, ihm an der erstellten und vom Auftraggeber bezahlten Software ausschließliche Nutzungsrechte einzuräumen. Gerade bei komplexen Projekten im internationalen Umfeld gestaltet sich dies oft als schwierig. Sofern Standardsoftware von Dritten Teil der erstellten Software ist, vermag der Auftragnehmer schon deshalb keine ausschließlichen Nutzungsrechte einzuräumen, weil er selbst von seinen Lizenzgebern in der Regel nur nicht-ausschließliche Nutzungsrechte an derartiger Standardsoftware erhalten hat und nur die Rechte weitergeben kann, die ihm selbst zustehen. In der Praxis wird man dann im Vertrag unterscheiden zwischen dem eigentlichen Entwicklungsergebnis, insoweit wären ggf. ausschließliche Nutzungsrechte zu vereinbaren, und den damit zusammenhängenden weiteren Softwaremodulen, für die dann ggf. nur nicht-ausschließliche Nutzungsrechte eingeräumt werden.

5

Häufig will der Auftragnehmer aber keine ausschließlichen Rechte einräumen, weil in der erstellten Software Know-how und Techniken erfasst sind, die der Auftragnehmer für andere Kunden benötigt. Man kann dann versuchen, im Vertrag nach bereits bei Vertragsabschluss bestehendem Knowhow bzw. Rechten und den im Rahmen der Erstellung neu entstehenden Rechten zu unterscheiden2.

6

Ein besonderes Problem könnten insofern diejenigen Lizenzierungsmodelle der Open-Source-Software schaffen, die den sog. Copyleft Effekt beinhalten, also bei Änderungen einer Open-Source-Software und Weitergabe dieser geänderten Software an Dritte eine Offenlegung des Source Code erfordern, 1 Das Territorialitätsprinzip ist jetzt in Art. 8 der sog. ROM II-VO gesetzlich verankert worden, vgl. Verordnung über das auf außervertragliche Schuldverhältnisse anzuwendende Recht, ABl. EU 2007 L 199/40. 2 Abhängig von den Marktverhältnissen sollte man bei der Vereinbarung ausschließlicher Nutzungsrechte nicht die kartellrechtlichen Grenzen vergessen, siehe hierzu Konrad/Timm-Goltsch/Ullrich in Ullrich/Lejeune, Der Internationale Softwarevertrag, 2. Aufl. 2006, Teil I Rz. 758 ff. Da die Gruppenfreistellungsverordnung für Forschungs- und Entwicklungsvereinbarungen (VO (EU) Nr. 1217/2010 Abl. L 335 v. 18.12.2010 S. 36 nunmehr auch die Auftragsentwicklung erfasst, ist diese Verordnung zu beachten, soweit die Verordnung im Einzelfall anwendbar ist. Dies gilt insbesondere auch für Exklusivitätsregelungen, siehe dazu Wolf, WRP 2013, 683 ff. und Rosenberger, GRUR 2012, 721 ff.

576

Lejeune

Internationale Softwareerstellungsverträge

Rz. 8

F

wie z.B. die GNU GPL1. In diesen Fällen lässt sich logischerweise keine „Ausschließlichkeit“ begründen. Sofern der Auftragnehmer eine Open-Source-Software ausschließlich für den Auftraggeber erstellt, soll der Copyleft-Effekt aber nach einer in der Literatur vertretenen Auffassung2 so lange nicht eingreifen, als der Auftragnehmer das Programm nicht auch einem Dritten zur Verfügung stellt. Dies hängt sicher von den Umständen, insbesondere von der beabsichtigten Nutzung der Software durch den Auftraggeber bzw. den Wettbewerbsverhältnissen und von dem jeweiligen Lizenzmodell einer Open-Source-Software ab, denn bekanntlich sieht nicht jedes Lizenzierungsmodell den (strengen) Copyleft Effekt vor. Die Open-Source-Lizenzmodelle dürften wohl zumindest, soweit die urheberrechtlichen Regelungen betroffen sind, in den meisten Ländern inzwischen anerkannt sein3. Alle Länder, die der Revidierten Berner Übereinkunft4 beigetreten sind, ha- 7 ben sich mit dem Beitritt verpflichtet, die Urheberpersönlichkeitsrechte zu schützen (vgl. Art. 6 bis RBÜ). In den meisten Ländern sind die Urheberpersönlichkeitsrechte nicht übertragbar5, sondern verbleiben beim Urheber, der lediglich Nutzungsrechte an den betroffenen Werken einräumen kann. Allerdings gibt es gerade im Hinblick auf Softwareprogramme erhebliche Unterschiede im Schutzumfang6. Deshalb muss der Auftraggeber einer Softwareerstellung entsprechende Urheberrechtsvermerke berücksichtigen. Das ist nur in den Ländern anders, in denen die sog. Work-for-hire-Doktrin7 8 gilt und deshalb bei Arbeits- und Auftragsverhältnissen in bestimmtem Rahmen eine Übertragung der Urheberrechte auf den Arbeit- bzw. Auftraggeber zulässig ist. Sofern ein Unternehmen für einen Auftraggeber eine Software erstellt, ist ansonsten darauf zu achten, dass dem Unternehmen die wirtschaftlichen Verwertungsrechte zustehen. In vielen Ländern gibt es Rechtsvorschriften, die dem deutschen § 69b UrhG ähneln8. Ansonsten sind die Unternehmen gut beraten, sich gegenüber ihren Mitarbeitern ver-

1 Vgl. Ziffer 2a GPL Version 2 unter www.gnu.org oder bei Jaeger/Metzger, Open Source Software, 2. Aufl. 2006, im Anhang abgedruckt. 2 Jaeger/Metzger, Open Source Software, Rz. 46 a.E. 3 Siehe zu USA Jacobsen v. Katzer 535 F. 3d 1373 (9th Cir. 2008), abgedruckt auch in CRI 2009, 15 ff. m. Anm. Lejeune, zu Frankreich bei Hauser in Ullrich/Lejeune, Der Internationale Softwarevertrag, Rz. 417 ff. sowie S.A. EDU 4 v. Association AFPA, CA Paris Arret du 16 Septembre 2009, No. 04/24298. 4 Insbesondere die USA sind erst spät nämlich im Jahre 1988 der RBÜ beigetreten, vgl. den sog. Berne Convention Implementation Act, Staatsgesetz 100-568, 17 U.S.C. 101 v. 31.10.1988. 5 Vgl. die Auflistung bei Lejeune, in: Meents/Lehmann, Handbuch des Fachanwalts IT-Recht, 2. Aufl. 2011 unter Kap. 4K Rz. 856. 6 Vgl. die Auflistung bei Lejeune, in: Meents/Lehmann, Handbuch des Fachanwalts IT Recht, unter Kap. 4K Rz. 852. 7 Z.B. § 201b Copyright Act der USA, 17 U.S.C. § 201b. 8 Vgl. die Auflistung bei Lejeune, in: Meents/Lehmann, Handbuch des Fachanwalts IT Recht, Kap. 4K Rz. 858.

Lejeune

577

F Rz. 9

Verträge

traglich abzusichern. Aus Sicht des Auftraggebers sind entsprechende Zusicherungen und Haftungsfreistellungsklauseln zu vereinbaren. 9

Die Vereinbarungen bezüglich der einzuräumenden Nutzungsrechte sind das Kernstück eines jeden Softwareerstellungsvertrages im internationalen Umfeld. Deshalb sollte man insoweit keinen Aufwand scheuen, die Rechtslage genau zu prüfen und entsprechende Vereinbarungen zu treffen. 2. Patentschutz für Software

10 Inwieweit Softwareprogramme patentierbar sind, ist nicht nur in Deutschland bzw. in der EU, sondern in vielen anderen Ländern, insbesondere in den USA nicht ganz klar. Einzelheiten hierzu können an anderer Stelle nachgelesen werden1. Gerade für Softwareerstellungsverträge, bei denen individuelle Softwarelösungen erstellt werden, sollte man die patentrechtliche Situation im Auge behalten, auch wenn der immaterialgüterrechtliche Schutz von Software primär durch das Urheberrecht sichergestellt wird. Das gilt zunächst für den Auftragnehmer, der bei seiner Tätigkeit im Wege einer Patentrecherche sicherstellen sollte, dass er bei der Erstellung der Software nicht etwa Patente Dritter verletzt. Das gilt aber auch für den Auftraggeber, der sicherstellen sollte, dass bei der Einräumung der Nutzungsrechte Patente mit erfasst sind. Dies ist dann unproblematisch, wenn bei der Einräumung der Nutzungsrechte nicht auf die zugrundeliegenden Schutzregelungen Bezug genommen wird, und dann gefährlich, wenn dies erfolgt. Formulierungen wie z.B.

der Auftragnehmer räumt dem Auftraggeber auf Basis der ihm zustehende Urheberrechte die folgenden Nutzungsrechte ein …

sind dann aus Sicht des Auftraggebers nicht akzeptabel. 11 Des Weiteren muss der Auftraggeber sicherstellen, dass der Auftragnehmer bei einem Verstoß gegen Patente Dritter angemessen haftet. In internationalen Verträgen wird meistens versucht, keine Gewährleistung für die Rechtsmängelfreiheit einzuräumen, weil dies in vielen Rechtsordnungen als wesentliche Vertragsverletzung ein Kündigungsrecht des Auftraggebers begründen kann, was der Auftragnehmer ausschließen möchte. Stattdessen sind Haftungsfreistellungen, sog. indemnification clauses üblich. Dabei ist aber aufzupassen, dass ein Verstoß gegen Patente Dritter überhaupt erfasst wird; oft wird nur auf Urheberrechtsverletzungen Bezug genommen.

1 Moufang, in: Ullrich/Lejeune, Der Internationale Softwarevertrag, Teil I Rz. 73 ff. und speziell zur Rechtslage in den USA Lejeune, in: Kilian/Heussen, Computerrechtshandbuch, Kap. 12 Rz. 87 sowie Sieckmann/Lejeune, MMR 2010, 741 ff.

578

Lejeune

Internationale Softwareerstellungsverträge

Rz. 16

F

Ferner ist zu beachten, dass Patente länderbezogen sind. Es nützt z.B. einem deutschen Auftraggeber, der die vom Auftragnehmer erstellte Software in Deutschland und der EU vertreiben will, gar nichts, wenn der zugrunde liegende Vertrag eine Entschädigungsverpflichtung des US-amerikanischen Auftragnehmers nur an die Verletzung US-amerikanischer Patente knüpft.

12

Bei internationalen Softwareerstellungsverträgen sollten also beide Parteien 13 die patentrechtliche Situation im Auge behalten, u.U. Patentrecherchen in Auftrag geben und ggf. entsprechende vertragliche Regelungen vorsehen.

II. Vertragsrechtliche Aspekte 1. Erfolgsverpflichtung des Auftragnehmers Seit der Schuldrechtsreform im Jahre 2002 wird in Deutschland darüber dis- 14 kutiert, ob Softwareentwicklungs- bzw. -erstellungsverträge wie bis zur Schuldrechtsreform nach Werkvertragsrecht oder neuerdings über § 651 BGB n.F. nach Kaufrecht zu beurteilen sind1. Unabhängig davon, wie diese Frage zu beantworten sein mag, ist der Auftragnehmer eines Softwareentwicklungs- bzw. -erstellungsvertrages jedenfalls sowohl beim Werk- als auch beim Kaufvertrag verpflichtet, einen bestimmten Erfolg, d.h. eine Software mit bestimmten Eigenschaften, Funktionen etc. zu entwickeln/erstellen, m.a.W. der Auftragnehmer hat in beiden Fällen eine Erfolgsverpflichtung. Dies ist im deutschen Recht bekanntlich anders, sofern ein Dienstvertrag gegeben ist. Der BGH prüft für die Abgrenzung zwischen Werk- und Dienstverträgen die wesentlichen Vertragspflichten und lässt Nebenbestimmungen in AGB dabei außer Acht2. Eine derart klare Trennung gibt es nicht überall. In Frankreich3 wird zwar 15 auch danach unterschieden, ob eine „obligation de résultat“, d.h. eine Erfolgsverpflichtung oder nur eine „obligation de moyens“ d.h. eine Tätigkeitsverpflichtung gegeben ist. Es ist aber grundsätzlich möglich, eine vertragliche Festlegung dahingehend zu treffen, ob eine bestimmte Vertragspflicht erfolgsbezogen oder tätigkeitsbezogen vereinbart werden soll4. In den USA als dem für die Softwarebranche vielleicht wichtigsten Land 16 geht man bei reinen Softwareerstellungs- bzw. -entwicklungsverträgen von einem Vertragsmodell aus, das dem deutschen Dienstvertrag entspricht. Der Auftragnehmer muss über entsprechende Kenntnisse und Erfahrungen verfügen und angemessene Sorgfalt bei der Bearbeitung walten lassen. Der 1 Siehe dazu ausführlich in diesem Buch bei Schneider in Kap. B insbes. Rz. 55 ff. zur BGH-Rspr. 2 BGH v. 4.3.1997 – X ZR 141/95, CR 1997, 470; Schneider, Handbuch des EDV Rechts, 4. Aufl. 2009, Teil J Rz. 84 ff. 3 Le Tourneau, Droit de la Responsabilité et des Contrats, 7ième édition, Dalloz 2008 Nr. 3214 ff. S. 829 ff. 4 Le Tourneau, Droit de la Responsabilité et des Contrats, Nr. 3241.

Lejeune

579

F Rz. 17

Verträge

Auftraggeber hat aber keinen Anspruch darauf, dass bestimmte Ergebnisse oder Funktionen erreicht werden („no perfect tender rule“)1. Man kann auch nach US-Recht eine hiervon abweichende, vertragliche Festlegung treffen, der zufolge der Auftragnehmer das Erfolgsrisiko tragen und entsprechend haften soll. Sofern allerdings keine eindeutigen Vertragsvereinbarungen vorliegen, wird ein US-Gericht sich immer auf die gesetzliche Rechtslage zurückziehen; im Zweifel „Dienstvertragsrecht“ anwenden und eine Erfolgshaftung des Auftragnehmers verneinen. 17 In England sieht Section 13 des „Supply of Goods and Services Act 1982“ vor, dass eine Dienstleistung („Service“) mit „reasonable care and skills“ erbracht werden muss2. 18 Die Frage, ob der Auftragnehmer das Erfolgsrisiko zu tragen hat, dürfte eine der, wenn nicht die entscheidende Frage bei der Abfassung eines Softwareentwicklungs- bzw. -erstellungsvertrages sein. Deshalb sollte man jede erdenkliche Sorgfalt bei der Abfassung entsprechender Verträge aufwenden, um klare vertragliche Festlegungen zu treffen. 19 In den letzten Monaten sind in Deutschland neuere Vertragsmodelle wie z.B. „Scrum“ und „agiles Programmieren“ bekannt geworden3. Diese Modelle vermischen die Verantwortlichkeiten von Auftraggeber und Auftragnehmer in einer Art und Weise, dass die Erfolgsverpflichtung des Auftragnehmers nicht mehr uneingeschränkt besteht4. Aus Sicht eines Auftragnehmers mag dies ein Vorteil sein, aus Sicht des Auftraggebers eines Softwareentwicklungs- bzw. -erstellungsvertrages ist dies klarer Weise abzulehnen, zumal es bisher offenbar weder in Deutschland noch in anderen Ländern Rechtsprechung hierzu gibt. Im Zweifel führen derartige Vertragsmodelle zu einer dienstvertraglichen Ausgestaltung, bei der der Auftragnehmer keine oder nur eine sehr begrenzte Erfolgsverpflichtung übernimmt.

1 Vgl. § 552 Restatement of Torts 2nd; Milau Associates Inc. v. North Avenue Development Corp. 368 N.E. 2d 1247 unter Berufung auf § 299A Restatement of Torts; Micro Managers v. Gregory 434 N.W. 2d 97 (Wiss. App. 1988); Data Processing v. L.H. Smith Oil Comp. 492 N.E. 2d 314 (Ind. App. 4 Dist. 1986); eine strengere Haftung nach dem Recht der unerlaubten Handlungen („tort law“) wird nur zugelassen, sofern Berater aufgrund gesetzlicher Pflichten eine besondere Vertrauensstellung inne haben, wie dies bei Ärzten oder Anwälten der Fall ist. Für Consultants in der EDV Industrie gelten diese Grundsätze aber nicht, vgl. Picker Intern. Inc. v. Mayo Foundation, 6 F. Supp. 2d 685 (N.D. Ohio 1998). 2 Stephen E. Blythe, Journal of Business Administration Online, Spring 2005, Vol.4 No.1, der das US-amerikanische und das englische IT-Vertragsrecht im Hinblick auf Haftungs- und Gewährleistungsfragen vergleicht. 3 Siehe Schneider, ITRB 2010, 18; Auer-Reinsdorff, ITRB 2010, 93; Lapp, ITRB 2010, 69; Kremer, ITRB 2010, 283. 4 Siehe dazu Frank, Bewegliche Vertragsgestaltung für agiles Programmieren, CR 2011, 138.

580

Lejeune

Internationale Softwareerstellungsverträge

Rz. 24

F

Daher ist Vorsicht bei einer Vertragsgestaltung geboten, die keine klare Trennung bzw. Zuordnung des Erfolgsverantwortung bzw. des Erfolgsrisikos trifft.

20

2. Haftungsregelungen Haftungsregelungen spielen bei der Verhandlung und dem Abschluss von 21 Softwareerstellungsverträgen immer eine große Rolle, das gilt insbesondere bei internationalen Verträgen, in denen ein anderes als deutsches Recht als Vertragsstatut vereinbart wird. In diesem Zusammenhang sollen folgende Punkte angesprochen werden, die in der Praxis besonders wichtig sind. In den meisten Ländern ist eine Haftung für Vorsatz und grobe Fahrlässig- 22 keit im Voraus nicht abdingbar. Beispiele hierfür sind Frankreich1 und die Schweiz2. Es gibt aber auch Länder, wie z.B. England, in denen von Gesetzes wegen 23 keine Unterscheidung zwischen „grober“ und „einfacher“ Fahrlässigkeit gemacht wird. Der englische High Court3 hatte sich vor einiger Zeit mit einem Vertrag zu beschäftigen, der eine Haftungsbegrenzung auf grobe Fahrlässigkeit unter Geltung englischen Rechts vorsah. Da es keine gesetzliche Regelung gibt, musste das Gericht eigene Abgrenzungskriterien entwickeln. Ähnliches gilt für die Abgrenzung von „willful misconduct“ zu „deliberate conduct“ unter englischem Vertragsrecht4. Es dürfte einleuchten, dass eine derartige Vertragsgestaltung unter den in England geltenden rechtlichen Bedingungen gefährlich ist, weil die Entscheidung des Gerichts de facto nicht vorhersehbar ist. Im deutschen Recht gilt bekanntlich das Verbot der geltungserhaltenden 24 Reduktion, d.h. Haftungsklauseln, die über den zulässigen Inhalt hinausgehen, z.B. bei einer bestimmten Auslegung, werden vom BGH5 strikt als unwirksam angesehen. Im internationalen Geschäft sollte man nicht davon ausgehen, dass dieses Prinzip überall gilt. In der Schweiz werden z.B. Haf-

1 Le Tourneau, Droit de la Responsabilité et des Contrats, S. 387 No. 1177; Malaurie in Malaurie/Aynès/Gautier, les Contrats spéciaux, Defrénois, 4ième édition 2009, No. 753 ausdrücklich für den Werkvertrag, insoweit auch kein Ausschluss der Haftung für eine „inexecution d’une obligation essentielle“; Cass.Com. 9.9.2010 n. 09-66477, Ste. Groupama transport c/La Poste, F. P+B. Siehe zu Haftungsbeschränkungen im französischen Recht Niggemann/Jonglez de Ligne, RIW 2011, 351 sowie Kupferberg/Göcke, RIW 2011, 337. 2 Art. 100 Abs. 1 OR. 3 Camarata Property Inc. v. Credit Suisse Securities (Europe) Ltd. (2011) EWHC 479 (Comm). 4 De Beers UK Limited v. Atos Origin IT Services Limited (2010) EWHC 3276 (TCC) 16. December 2010. 5 BGH NJW 1999, 1031 ff.; BGH NJW-RR1998, 1426; Palandt/Grüneberg, vor § 307 BGB Rz. 8.

Lejeune

581

F Rz. 25

Verträge

tungsbegrenzungsklauseln für „jedes Verschulden“ nur insoweit nicht anerkannt, als Vorsatz und grobe Fahrlässigkeit mit erfasst werden1. 25 Ausgehend von den Gepflogenheiten in den USA hat es sich in der Praxis durchgesetzt, dass man indirekte und Folgeschäden („indirect and consequential damages“) soweit als möglich auszuschließen sucht. Nur im Vertragsrecht der USA2 gibt es allerdings eine gesetzliche Regelung, aus der eine vernünftige Definition sog. „indirekter“ oder „mittelbarer“ Schäden zu entnehmen wäre. In anderen Ländern, in denen es keine derartige Festlegung gibt, wie z.B. auch in England, obliegt es dann dem Richter im Einzelfall eine Abgrenzung zu finden. Dort wird im Übrigen anders als in den USA (!) „loss of profits“, also entgangener Gewinn, nicht als Folgeschaden, sondern als Teil des direkten Schadens verstanden3. Die Unterscheidung zwischen Mangel- und Mangelfolgeschäden wird seit der Schuldrechtsreform auch in Deutschland, nicht mehr benötigt4. 26 In einigen Ländern wie z.B. in Frankreich5 besteht eine vertragliche Haftung (anders im Deliktsrecht) von vorneherein nur für direkte und bei Vertragsabschluss vorhersehbare Schäden, wobei der Richter dann mangels gesetzlicher Präzisierung entscheidet, ob oder inwieweit ein konkret eingetretener Schaden noch als „direkt“ anzusehen ist. 27 In den USA können die Gerichte neben dem kompensatorischen Schadensersatz in bestimmten Fällen zusätzlich sog. Strafschadensersatz („punitive damages“) verhängen. Obwohl der US-amerikanische Supreme Court in zwei grundlegenden Entscheidungen6 die Befugnis der Gerichte beschränkt und insbesondere angeordnet hat, dass der Betrag der punitive damages maximal das Neunfache des kompensatorischen Schadensersatzes betragen darf, kann dies für den Schädiger weitreichende Konsequenzen haben. In Deutschland sind punitive damages nicht vollstreckbar7, in Frankreich8 dagegen aufgrund einer erst kürzlich ergangenen Entscheidung des Cour de Cassation schon. 28 Für die Praxis bei internationalen Softwareerstellungsverträgen leiten sich daraus folgende Empfehlungen ab: Man kann nicht vermeiden, sich im Detail mit den haftungsrechtlichen Regelungen desjenigen Landes auseinander 1 Wiegand, in: Honsell/Voigt/Wiegand, Obligationenrecht, 4. Aufl. 2007, Helbing/ Lichtenhahn, Rz. 4 zu Art. 100 OR. 2 Art. 302 Art. 2 UCC, siehe dazu im Detail unten unter II.3. 3 British Sugar Plc. v. NEI Power Projects Ltd. (1998) 14 Const. L. J. 365. 4 Palandt/Sprau, § 634 BGB Rz. 6. 5 Civ. 1ère, 25 janv. 1989, no 87-13.640, Bull. civ. I, no 43; D. 1989, IR 47; Gaz. Pal. 1990, 1, 16, note Panhaleux; Le Tourneau, Droit de la Responsabilité et des Contrats, 7ième édition, Dalloz 2008, S. 361 No. 1034. 6 BMW of North America v. Gore 517 U.S. 559 (1996) und State Farm Mutual Automobile Insurance Co. v. Campbell 123 S.Ct. 1513 (2003). 7 BGHZ 118, 312 ff. 8 Cass. Arret No. 1090 du 1 décembre 2010 (09-13.303).

582

Lejeune

Internationale Softwareerstellungsverträge

Rz. 30

F

zu setzen, dessen Recht für den abzuschließenden Softwareerstellungsvertrag Anwendung finden soll. Vor der pauschalen Abbedingung von indirekten und/oder Folgeschäden ist zu warnen, auch wenn die erforderlichen Ausnahmen, wie z.B. hinsichtlich der Haftung für Vorsatz und grobe Fahrlässigkeit oder der Haftung für Personenschäden Dritter gemacht werden. Sofern man eine derartige Haftungsbegrenzung überhaupt anstreben sollte, sollte man in der entsprechenden Haftungsklausel detailliert beschreiben, welche Schäden die Parteien als indirekte oder als Folgeschäden ansehen, z.B. entgangenen Gewinn, Betriebsunterbrechung, Datenverluste oder Schäden an anderen Rechtsgütern des Auftraggebers, um dem Richter Anhaltspunkte für die Vertragsauslegung zu geben. Ansonsten lässt sich vielfach nicht im Voraus beurteilen, ob ein geltend gemachter Anspruch anerkannt wird oder nicht, von Rechtssicherheit ist dann keine Rede mehr. Letztlich hängt es davon ab, ob man die Position des Auftragnehmers oder die des Auftraggebers vertritt, um zu prüfen, welches Recht im Hinblick auf Haftungsfragen im Einzelfall günstiger ist. 3. Grenzen des AGB-Rechts In der Praxis wird fast ausschließlich mit Allgemeinen Geschäftsbedingun- 29 gen oder vorformulierten Vertragsmustern gearbeitet. Individualvereinbarungen sind relativ selten, zumindest im Hinblick auf die juristischen Regelungen. Als deutscher Jurist ist man an die rigiden Grenzen gewöhnt, die das AGB-Recht der Vertragsgestaltung setzt und zwar auch im B2B-Geschäft1. Derart strenge Regelungen wie im deutschen Recht findet man in den meis- 30 ten anderen für die Softwarebranche interessanten Staaten nicht. Dies gilt insbesondere für die USA. In den USA sieht Section 302 des Art. 2 des Uniform Commercial Code2 zwar die Unwirksamkeit von Klauseln vor, die als „unscionable“ einzustufen sind. Sofern man sich allerdings die Rechtsprechung ansieht, wird schnell klar, dass die Vertragsfreiheit unvergleichlich größer ist als in Deutschland. Klauseln, die nach US-Recht als „unscionable“ eingestuft werden, würde man unter deutschem Recht als sittenwidrig im Sinne des § 138 BGB ansehen3. Der dort geltende Maßstab ist mit unseren auf dem strengen AGB-Recht beruhenden Vorstellungen schlicht und ergreifend nicht vereinbar.

1 Nach BGH v. 19.9.2007 – VIII ZR 141/06, NJW 2007, 3774 indiziert eine der in §§ 308 und 309 BGB aufgeführten Klauseln im Zweifel auch im B2B-Geschäft deren Unzulässigkeit; wer sich im B2B-Geschäft auf eine Klausel, die in §§ 308 und 309 aufgeführt ist, berufen will, hat die Beweislast dafür, dass eine derartige Klausel aufgrund der besonderen Umstände des Falls akzeptabel und nicht nach § 307 BGB unwirksam ist. 2 Abrufbar unter www.nccusl.org. 3 Lejeune, in: Kilian/Heussen, Computerrechtshandbuch, Nachl. 2011 Kap. 12 Rz. 87.

Lejeune

583

F Rz. 31

Verträge

31 Auch in England und Frankreich gibt es keine klaren Vorgaben zum AGBRecht. In Frankreich1 hat der Richter das Recht, aufgrund eigenen Ermessens unangemessene Klauseln für unwirksam zu erklären. In England2 ist der „Reasonablenes Standard“ maßgebend, d.h. es wird aufgrund der Umstände des Falls geprüft, ob eine Vertragsklausel im Einzelfall zulässig ist. Dabei wird auch, anders als in den USA, die Marktmacht der Parteien, also die sog. bargaining power als eines der abzuwägenden Kriterien berücksichtigt. Selbst in der Schweiz3 gibt es keine dem deutschen AGB-Recht vergleichbaren, restriktiven Vorschriften, sondern die Rechtsprechung kontrolliert den Inhalt des Vertrages von Amts wegen auf der Grundlage der in Art. 20 Obligationenrecht dargelegten Kriterien (Art. 20 Abs. 1 OR lautet: „Ein Vertrag, der einen unmöglichen oder widerrechtlichen Inhalt hat oder gegen die guten Sitten verstößt, ist nichtig.)4. 32 Je nachdem welche Position man vertritt, die des Auftragnehmers, der eine Software zu erstellen oder die des Kunden, der die Erstellung in Auftrag gegeben hat, kann dieser Punkt bei der Abwägung des anwendbaren Rechts im Rahmen der Vertragsgestaltung bei Softwareerstellungsverträgen also durchaus eine Rolle spielen. 4. Anwendbarkeit des UN-Kaufrechts 33 In vielen internationalen Verträgen wird inzwischen im Rahmen der Rechtswahlklausel das UN-Kaufrecht, d.h. das Übereinkommen der Vereinten Nationen über Verträge über den internationalen Warenkauf vom 11.4.1980 (BGBl. 1989 II S. 588), im englischen Recht als „CISG“ (Convention on the International Sale of Goods)5 bezeichnet, ausdrücklich aus1 Vgl. Hauser, in: Ullrich/Lejeune, Der Internationale Softwarevertrag, Teil II Rz. 457; Malaurie, in: Malaurie/Aynès/Gautier, Les Contrats spéciaux, No. 683 und dort Fn. 57 m.w.N.; Dujardin/Lejeune, ITRB 2011, 209. 2 Nicky Hartwell, The Application of the Reasonableness Test under the UCTA 1977: a schism between certainty and fairness, Herfortshire Law Journal 3 (2), 55–60; St. Albans City Council v. International Computers Ltd., (1995) FSR 686; Salvage Association v. CAP Financial Services Ltd. (1995) FSR 654 und MacKenzie Patten & Co v. British Olivetti Ltd. (1984) 1 C L & P 22. Der englische High Court hat entschieden, dass die weit verbreiteten „all reasonable endeavours“ Klauseln die verpflichtete Vertragspartei dazu zwingen, auch Anstrengungen zu unternehmen, die ihren wirtschaftlichen Interessen widersprechen, vgl. Jet2.com Ltd. v. Blackpool Airport Ltd. (2011) EWHC 1529. 3 Huguenin, in: Honsell/Voigt/Wiegand, Obligationenrecht, 4. Aufl. 2007; Helbing/Lichtenhahn, Rz. 25 zu Art. 20. 4 Siehe Huguenin, in: Honsell/Voigt/Wiegand, Obligationenrecht, Rz. 27, prinzipiell werden AGB nach denselben Regeln wie individuell verfasste Abreden ausgelegt. 5 Siehe hierzu generell bei Piltz, NJW 2011, 2261, NJW 2009, 2258; NJW 2007, 2159; NJW 2005, 2126; NJW 2003, 2056; NJW 2000, 553; NJW 1996, 2768; NJW 1994, 1101 und Schlechtriem/Schwenzer, Kommentar zum Einheitlichen UNKaufrecht, 5. Aufl. 2008.

584

Lejeune

Internationale Softwareerstellungsverträge

Rz. 35

F

geschlossen. Ein derartiger vertraglicher Ausschluss ist gemäß Art. 6 des Übereinkommens zulässig, aber auch erforderlich, sofern man die Geltung des Übereinkommens ausschließen will, weil die bloße Wahl des deutschen Rechts allein nicht als stillschweigender Ausschluss des UN-Kaufrechts verstanden werden kann1. Sollte kein ausdrücklicher Ausschluss erfolgen, kann dies auch bei bloßer Geltung des deutschen Rechts in internationalen Verträgen, d.h. mit ausländischen Vertragspartnern bei Vorliegen der sachlichen und räumlichen Voraussetzungen des UN-Kaufrechts dazu führen, dass das Übereinkommen anwendbar ist, ohne dass diese Konsequenz den Parteien bekannt bzw. von ihnen beabsichtigt ist2. Es stellen sich im Hinblick auf Softwareerstellungsverträge allerdings Fra- 34 gen nach dem sachlichen Anwendungsbereich des Übereinkommens. Insofern sind zwei Themen anzusprechen: (1) Anknüpfungspunkt des Übereinkommens sind Waren (englisch 35 „goods“). Inwieweit Software als Ware im Sinne des Übereinkommens angesehen werden kann, wird bereits seit Jahren diskutiert. Dabei scheint sich inzwischen eine h.M.3 herausgebildet zu haben, die Standardsoftware als Ware im Sinne des Übereinkommens anerkennt. Schwieriger ist dagegen die Frage zu beantworten, inwieweit die für Softwareerstellungsverträge in erster Linie bedeutsame Individualsoftware als Ware im Sinne des Übereinkommens anzusehen ist. Die Befürworter4 der Frage argumentieren mit Art. 3 Abs. 1 und vertreten die Auffassung, die Lieferung der Software stehe im Vordergrund, daher könne auch Individualsoftware unter das Übereinkommen fallen. Die Vertreter der Gegenmeinung5 beziehen sich auf Art. 3 Abs. 2 und argumentieren, dass bei der Erstellung von Individualsoftware in der Regel die Ausführung der Arbeiten, also die Erstellungsleistung im Vordergrund stehe, so dass Individualsoftware nicht unter das Übereinkommen falle. Die in Deutschland seit langem geführte Diskussion, ob Software als Sache im Sinne des BGB anzusehen sei, die seit der Schuldrechtsreform in Zusammenhang mit § 651 BGB wieder aufgelebt ist, kann m.E. insoweit keine Rolle spielen, weil das Übereinkommen autonom auszulegen ist. Im Hinblick auf die Individualsoftware sind die Auffassungen offenbar nach wie vor gespalten. Richtig dürfte es sein, darauf abzustellen ob das kaufrechtliche Element überwiegt oder mit anderen Worten ob Lieferung und

1 Vgl. Piltz, NJW 2003 (2056, 2059) m.w.N. aus der Rechtsprechung dort in Fn. 42. 2 Das Übereinkommen ist eine nach Art. 3 Abs. 2 EGBGB vor den Vorschriften des EGBGB vorrangige Regelung. 3 Marly, Praxishandbuch Software-Recht, 5. Aufl. 2009, Rz. 1004; Schmitt, CR 2001, 145; Endler/Daub, CR 1993, 601; LG München 8.2.1995 – 8 HKO 24667/93 – Graphiplus; Diedrich, RIW 1993, 441; siehe auch Lejeune, ITRB 2011, 20 ff. 4 Schmitt, CR 2001, 145; Schmitt, MMR 2000, 256, 258: immaterielle Leistungen sind Waren im Sinne des Übereinkommens. 5 Endler/Daub, CR 1993, 601; OLG Köln RIW 1994, 970.

Lejeune

585

F Rz. 36

Verträge

Entgeltzahlung die vertragswesentlichen und überwiegenden Elemente des Vertrages darstellen1. 36 (2) Falls man die Auffassung vertreten wollte, dass Individualsoftware, zumindest unter bestimmten Umständen als Ware im Sinne des Übereinkommens angesehen werden kann, ist das Übereinkommen nur dann anwendbar, wenn Softwareerstellungsverträge unter das Übereinkommen subsumiert werden können. 37 Nach Art. 3 Abs. 1 stehen den Kaufverträgen Verträge über die Lieferung herzustellender oder zu erzeugender Ware gleich, es sei denn dass der Besteller einen wesentlichen Teil der für die Herstellung oder Erzeugung notwendigen Stoffe selbst zur Verfügung stellt. Von der Auslegung dieser Vorschrift hängt die Frage ab, inwieweit Werklieferungsverträge unter das UN-Kaufrecht fallen. Nach der h.M.2 ist entscheidend, ob die Lieferung und Entgeltzahlung die vertragswesentlichen Pflichten darstellen oder ob das werkvertragliche Element so im Vordergrund steht, dass die Lieferung der Ware als notwendige Konsequenz dahinter zurückstehen muss3. Die Diskussion wird also mit ähnlichen Argumenten geführt, wie oben bei der Frage, inwieweit Software als Ware im Sinne des Übereinkommens anzusehen ist. und erinnert an die seit langem geführte Diskussion zur Rechtsnatur von Softwareentwicklungsverträgen im deutschen Recht. Eine pauschale Antwort wird man indes nicht geben können, sondern es ist erforderlich, die Umstände des jeweiligen Einzelfalls zu bewerten. Eindeutig ist aber, dass Verträge, die reine Planungsleistungen zum Gegenstand haben, nicht unter das Übereinkommen fallen, z.B. Verträge über die reine Planung von Anlagen oder Rechenzentren ebenso wie Verträge, die Gutachten zum Gegenstand haben4. 38 Als Ergebnis lässt sich deshalb feststellen, dass der sachliche Anwendungsbereich des Übereinkommens bei Softwareerstellungsverträgen zweifelhaft sein kann5. Sofern man das Übereinkommen ausschließen will, sollte man deshalb bei der Vertragsgestaltung einen entsprechenden Passus in die Rechtswahlklausel aufnehmen, wie z.B.:

1 So Marly, Praxishandbuch Software-Recht, 5. Aufl. 2009, Rz. 631; Ferrari, in: Schlechtriem/Schwenzer, Kommentar zum Einheitlichen UN-Kaufrecht, 5. Aufl. 2008, Art. 3 Rz. 15; siehe zur Problematik der Individualsoftware ausführlich Diedrich, RIW 1993, 441. 2 Marly, Praxishandbuch Software-Recht, Rz. 632. 3 Piltz, NJW 2009, 2258 will dabei auf den prozentualen Anteil an der Gesamtvergütung für nicht verkäufertypische Leistungen abstellen. 4 Marly, Praxishandbuch Software-Recht, Rz. 1004. 5 Zum räumlich-persönlichen Anwendungsbereich nach Art. 1 Abs. 1 1a) (sog. autonome Anwendungsalternative) bzw. Art. 1 Abs. 1 1b) (sog. kollisionsrechtliche Anwendungsalternative) siehe bei Schlechtriem/Schwenzer, Kommentar zum Einheitlichen UN-Kaufrecht, Art. 3 Rz. 15 sowie bei Lejeune, ITRB 2011, 20 ff.

586

Lejeune

Internationale Softwareerstellungsverträge

Rz. 44

F

Die Anwendbarkeit des Übereinkommens der Vereinten Nationen über Verträge über den internationalen Warenkauf vom 11.4.1980 (BGBl.1989 II S. 588) wird ausdrücklich ausgeschlossen.

Nach den Erfahrungen des Verfassers wird dies auch regelmäßig in der Praxis so gemacht.

39

III. dispute resolution clauses (Streitlösungsklauseln) 1. Internationale Zuständigkeit, Prorogation sowie Anerkennung und Vollstreckung ausländischer Urteile Die Frage nach der Anerkennung und Vollstreckung ausländischer Urteile 40 hängt eng mit der internationalen Zuständigkeit sowie der vertraglichen Festlegung eines Gerichtsstandes (Prorogation) zusammen, denn ohne entsprechenden Gerichtsstand kann ein Gericht kein Urteil fällen. Sofern die Parteien eines internationalen Softwareerstellungsvertrages kei- 41 ne Regelung zur internationalen Zuständigkeit getroffen haben, entscheidet das Prozessrecht am Ort der jeweiligen Vertragspartei über die sog. internationale Zuständigkeit. In der deutschen ZPO finden sich insoweit keine speziellen Regelungen, so dass die Regelungen zur örtlichen Zuständigkeit indirekt auch für die internationale Zuständigkeit gelten1. Nicht nur nach deutschem Zivilprozessrecht (vgl. §§ 12, 13 ZPO) dürfte ein Gerichtsstand am Sitz des Beklagten ohne größere Schwierigkeiten in Betracht kommen. Ein entsprechendes Urteil kann dann gegen den Beklagten nach dem lokalen Prozessrecht ohne Schwierigkeiten vollstreckt werden. Schwieriger wird es, wenn ein Gerichtsstand an einem anderen Ort als dem 42 Sitz des jeweiligen Beklagten vertraglich vereinbart wurde oder aufgrund zivilprozessualer Vorschriften zulässig wäre. Dann kommt es ggf. auf Möglichkeiten der Anerkennung und Vollstreckung ausländischer Urteile an. Im deutschen Recht beurteilt sich die Anerkennung ausländischer Urteile 43 nach § 328 ZPO. Insofern ist insbesondere auf § 328 Abs. 1 Nr. 5 ZPO hinzuweisen; dort wird das Prinzip der Gegenseitigkeit festgelegt, d.h. es muss auch umgekehrt ein deutsches Urteil in dem Land dessen Urteil in Deutschland anerkannt werden soll, anerkannt werden. Innerhalb der Europäischen Union ist die Anerkennung und Vollstreckung 44 ausländischer Urteile durch die EuGVVO2 relativ gut geregelt. Diese ver-

1 Zöller/Vollkommer, 29. Aufl. 2012, § 1 ZPO Rz. 8. 2 Verordnung (EG) Nr. 44/2001 vom 22.12.2000 EG 2001 ABl. Nr. L 12 S. 1; siehe dazu bei Lejeune, ITRB 2006, 65 ff. und Dietze/Schnichels, EuZW 2009, 33 ff.

Lejeune

587

F Rz. 45

Verträge

drängt in ihrem Anwendungsbereich die ZPO. Bei der Auslegung der EuGVVO hat eine autonome Auslegung zu erfolgen, so dass Begriffe wie z.B. „Erfüllungsort“ oder „Dienstleistungen“ nicht entsprechend dem deutschen Verständnis ausgelegt werden dürfen1. Gemäß Art. 23 EuGVVO können die Parteien, von denen mindestens eine ihren Sitz im Hoheitsgebiet eines Mitgliedsstaats haben muss, eine Gerichtsstandsvereinbarung zugunsten eines Gerichts eines Mitgliedsstaats auch für eine zukünftige Rechtsstreitigkeit treffen2. Anders als in der ZPO führt eine derartige Vereinbarung gemäß Art. 23 Abs. 1 Satz 2 EuGVVO zu einer ausschließlichen Zuständigkeit, auch wenn die Vereinbarung dies nicht ausdrücklich festlegt. Gemäß Art. 22 Nr. 4 EuGVVO gibt es eine ausschließliche Zuständigkeit für Klagen, welche die Eintragung oder Gültigkeit von Patenten, Marken, Mustern etc. zum Gegenstand haben. Diese Regelung findet bei Software aber nur Anwendung, wenn ein Softwareprodukt patentiert wurde und eine entsprechende Klage Gegenstand des Rechtsstreits ist. 45 Außerhalb der Europäischen Union ist zunächst zu prüfen, ob es zwischen Deutschland und dem Staat, in dem die andere Vertragspartei ansässig ist, ein bilaterales Abkommen über die Anerkennung und Vollstreckung von Urteilen aus dem jeweils anderen Staat gibt3. 46 Sollte ein Abkommen nicht existieren, ist die Rechtslage schwierig. Dies gilt insbesondere für die USA. Mit den USA gibt es kein Abkommen über die Anerkennung und Vollstreckung ausländischer Urteile und zwar auch nicht seitens anderer EU Mitgliedsstaaten. Lediglich in denjenigen US-amerikanischen Bundesstaaten, in denen der sog. Uniform Foreign Country Money Judgements Recognition Act4 erlassen wurde, ist die Vollstreckung ausländischer Urteile, die zur Zahlung von Geldbeträgen verpflichten, unter den dort festgelegten Bedingungen möglich. 47 Gerade im Rechtsverkehr mit den USA ist aber die Festlegung eines Gerichtsstandes wichtig, weil nach US-amerikanischem Prozessrecht eine Klage gegen eine ausländische Partei von der US-amerikanischen Partei in den USA nach der sog. Minimum-Contacts-Lehre immer schon dann angestrengt werden kann, wenn die ausländische Partei über ausreichende Ge-

1 EuGH v. 25.2.2010 – C-381/08 – Car Trim GmbH/Key Safety Systems Srl, NJW 2010, 1059, und OLG München v. 23.12.2009 – 20 U 3515/09, CR 2010, 156 ff. 2 Siehe zu internationalen Gerichtsstandsvereinbarungen nach der EuGVVO Mark/Gärtner, MDR 2009, 837 ff. 3 So z.B. das Deutsch-Schweizerische Abkommen über die gegenseitige Anerkennung und Vollstreckung von gerichtlichen Entscheidungen und Schiedssprüchen vom 2.11.1929 oder das entsprechende Abkommen mit dem Staat Israel vom 26.7.1977, diese und andere vergleichbare Abkommen sind aufgeführt bei Jayme/ Hausmann, Internationales Privat- und Verfahrensrecht, 14. Aufl. 2008, unter Nr. 188 bzw. 189. 4 Abrufbar unter http://www.uniformlaws.org.

588

Lejeune

Internationale Softwareerstellungsverträge

Rz. 51

F

schäftstätigkeiten in den USA verfügt1. Die gilt sowohl für den Vertrieb als auch den Einkauf in den USA. Da die Voraussetzungen vage und die entscheidenden, unbestimmten 48 Rechtsbegriffe einer weiten Interpretation zugänglich sind, sollte man im Rechtsverkehr mit den USA unbedingt eine vertragliche Festlegung treffen, um keine Überraschungen zu erleben2. In der Praxis behilft man sich mit einer sog. home forum rule, d.h. einer Vereinbarung, nach der jede Partei nur am Ort ihrer Niederlassung von der anderen Partei verklagt werden darf. Auf diese Weise können deutsche Unternehmen vermeiden, gegen ihren Willen ein Verfahren vor US-Gerichten führen zu müssen. Um Unwägbarkeiten zu vermeiden, kann jedenfalls nur dringend angeraten werden, bei internationalen Softwareerstellungsverträgen eine vertragliche Festlegung zum Gerichtsstand zu treffen.

49

2. Schiedsgerichtsbarkeit Die Vorteile der Schiedsgerichtsbarkeit gegenüber der streitigen Gerichts- 50 barkeit liegen zunächst darin, dass die Parteien durch die Ernennung der Schiedsrichter Einfluss auf die Zusammensetzung des Schiedsgerichts, insbesondere auf Kenntnisse und Erfahrungen der zu benennenden Personen in dem technischen Umfeld nehmen können. Ferner ist es anders als in einem öffentlichen Gerichtsverfahren möglich, das Schiedsverfahren durch Vertraulichkeitsvereinbarungen vor der Öffentlichkeit bzw. Dritten, z.B. Konkurrenten, geheim zu halten. Schließlich entscheidet das Schiedsgericht relativ schnell und endgültig, d.h. ein langjähriger Instanzenzug ist nicht möglich. Nachteilig ist die Kostenseite, denn ein Schiedsverfahren kann schnell sehr teuer werden, insbesondere dann, wenn das Schiedsgericht wie bei größeren Streitigkeiten üblich aus drei Schiedsrichtern besteht. Ein weiterer Vorteil des Schiedsverfahrens gegenüber der streitigen Ge- 51 richtsbarkeit besteht aber bei internationalen Streitigkeiten darin, dass die Anerkennung und Vollstreckung ausländischer Schiedsurteile durch das 1 Da sowohl die sog. due process clause der Verfassung (XIV. Amendment der US Constitution) als auch die meisten der sog. long arm statutes der US-amerikanischen Bundesstaaten keine konkreten Vorgaben zur internationalen Gerichtsbarkeit machen, sah sich der US Supreme Court gezwungen, die sog. Minimumcontacts-Lehre zu begründen, vgl. die grundlegende Entscheidung in Sachen International Shoe v. State of Washington 326 U.S. 310 (1945), siehe zur „personal jurisdiction“ über ausländische Unternehmen in den USA im Detail Lejeune, RIW 1998, 8 ff. 2 Analog zur EuGVVO hatte man im Rahmen der Haager Konferenzen im Jahre 2005 ein internationales Gerichtsstandsübereinkommen abgeschlossen, die sog. „Convention on choice of court Agreements“, abrufbar unter www.hcch.net. Dieses Übereinkommen ist aber noch nicht in Kraft getreten, weil die erforderliche Ratifizierung durch die erforderliche Zahl von Staaten zum Zeitpunkt der Druckregelung noch nicht erfolgt ist, siehe Lejeune, ITRB 2006, 65 ff.

Lejeune

589

F Rz. 52

Verträge

New Yorker Übereinkommen über die Anerkennung und Vollstreckung ausländischer Schiedssprüche vom 10.6.1958 geregelt ist1. Es gibt nur wenige Staaten, die im internationalen IT-Geschäft von Bedeutung sind, die der New Yorker Übereinkunft nicht beigetreten sind. Eigentlich ist in diesem Zusammenhang nur Taiwan zu nennen, das wegen der völkerrechtlichen Probleme mit China nicht beigetreten ist. 52 Bei der Formulierung einer Schiedsklausel kann man entweder auf eine anerkannte Schiedsordnung, z.B. die der Internationalen Handelskammer („ICC arbitration rules“)2 oder eine der beiden Schiedsordnungen der American Arbitration Association („AAA“)3 verweisen oder im Wege der sog. konstitutionellen Schiedsgerichtsbarkeit alle wesentlichen Fragen direkt in der Klausel regeln. In der Praxis wird nach den Erfahrungen des Verfassers fast ausschließlich auf eine bestehende Schiedsordnung verwiesen. 53 Bei internationalen Sachverhalten ist wichtig, in der Klausel festzulegen, in welcher Sprache das Schiedsverfahren durchgeführt werden bzw. in welcher Sprache das Schiedsurteil abgefasst werden soll. 54 Von großer Bedeutung und deshalb in der Praxis oft umstritten, ist die Frage, an welchem Ort das Schiedsverfahren durchzuführen ist. Der Grund hierfür liegt darin, dass dann das an diesem Ort geltende Prozessrecht anzuwenden ist, sofern die Schiedsordnung insoweit keine ausreichenden oder abschließenden Regelungen treffen sollte. Insoweit muss man bei einem in den USA durchzuführenden Schiedsverfahren also ggf. mit den Besonderheiten des US-amerikanischen Zivilprozessrechts leben. Sofern man dies verhindern möchte, ergibt sich die Empfehlung, möglichst einen Ort außerhalb der USA zu vereinbaren. 55 Sofern man bei der Verhandlung eines internationalen Softwareerstellungsvertrages keine Einigung über den Gerichtsstand erzielen kann, ist die Vereinbarung einer Schiedsklausel also eine echte Alternative. 3. Mediation 56 In den letzten Jahren wird viel über Mediation gesprochen. Der entscheidende Unterschied und der m.E. entscheidende Nachteil einer Mediation gegenüber einem Schiedsverfahren liegt darin, dass der Mediator lediglich einen unverbindlichen Vorschlag machen kann, wie ein bestimmter Streit zu lösen sein könnte. Sofern nicht beide Parteien aufgrund autonomer Ent1 Abgedruckt bei Jayme/Hausmann, Internationales Privat- und Verfahrensrecht, Nr. 240. 2 http://iccwbo.org. Die ICC hat am 12.9.2011 eine überarbeitete Version der Rules of Arbitration veröffentlicht, die am 1.1.2012 in Kraft getreten ist. Die neue Version beinhaltet die Erfahrungen, die die ICC mit den bisherigen Rules aus dem Jahre 1998 gemacht hat. 3 www.adr.org/, die American Arbitration Association bietet die sog. commercial und die sog. international arbitration rules an.

590

Lejeune

Internationale Softwareerstellungsverträge

Rz. 59

F

scheidung bereit sind, diesen Vorschlag anzunehmen, führt eine Mediation daher zu keiner Lösung des Streitfalls1. Vor diesem Hintergrund hält der Verfasser eine Mediation für keine wirkliche Alternative zu einem Gerichts- oder Schiedsverfahren. Schon lange bevor die Mediation in Mode gekommen ist, war es aber im in- 57 ternationalen Geschäft üblich, bei Streitfällen zwischen den Parteien eines Softwareerstellungsvertrages ein internes „Eskalationsverfahren“ zu vereinbaren, das zunächst durchzuführen ist, bevor eine der Parteien ein Gerichtsoder Schiedsgerichtsverfahren einleiten kann. Üblich ist, dass zunächst Vertreter des höheren Managements der Parteien eingeschaltet werden müssen und versuchen sollen, ggf. innerhalb einer im Vertrag festgelegten Frist eine Lösung für den Streit zu finden, bevor weitere Maßnahmen eingeleitet werden dürfen. Derartige Regelungen sind m.E. sehr sinnvoll, denn häufig findet man auf diese Weise einen für beide Seiten gangbaren Kompromiss. In der IT-Branche können die Parteien oft nicht einschätzen, ob sie nicht zu einem späteren Zeitpunkt bei einem anderen Projekt wieder aufeinander angewiesen sind. Ist das Tischtuch erstmal durch ein Gerichts- oder Schiedsverfahren durchschnitten, ist es im Nachhinein deutlich schwieriger, sich wieder zu einer gedeihlichen Zusammenarbeit zusammen zu finden. Daher wird in der Praxis auch nur dann ein entsprechendes Gerichts- oder Schiedsverfahren eingeleitet, wenn man trotz beiderseitiger Bereitschaft zum Kompromiss keine Lösung finden kann. Eine Mediation sollte als einzige Streitbeilegungsform im Rahmen von in- 58 ternationalen Softwareerstellungsverträgen nicht vereinbart werden und kann nur als eine einem Gerichts- oder Schiedsverfahren vorgeschaltete Methode zur Streitbeilegung in Betracht kommen.

IV. Insolvenz des Auftragnehmers Nach deutschem internationalen Insolvenzrecht (§ 335 InsO) unterliegt ein 59 Insolvenzverfahren dem Recht des Staats, in dem das Verfahren eröffnet worden ist2. Nach deutschem Verständnis gilt das sog. Universalitätsprinzip, d.h. auch im Ausland befindliches Vermögen des Schuldners wird von der Insolvenz erfasst. Aus Sicht des deutschen internationalen Insolvenzrechts gilt dieses Prinzip auch umgekehrt, d.h. sofern ein Insolvenzverfahren in einem anderen Staat eröffnet wurde, wird in Deutschland befindliches Vermögen des Schuldners mit erfasst. Im Ausland gelten im Übrigen die jeweiligen Vorschriften des dortigen nationalen und internationalen Insolvenzrechts3. 1 Siehe ausführlich zur Mediation Unberath, NJW 2011, 1320; zu Mediationsklauseln auch Lapp, ITRB 2002, 165 ff. 2 Sog. lex fori concursus, vgl. MüKo/Kindler, 5. Aufl. 2010, Band 11, Rz. 1 zum Internationalen Insolvenzrecht. 3 Vgl. MüKo/Kindler, Band 11, Rz. 1 zum Internationalen Insolvenzrecht.

Lejeune

591

F Rz. 60

Verträge

60 Innerhalb der Europäischen Union gibt es eine eigene Regelung. Gemäß Art. 3 Abs. 1 und Art. 4 Abs. 1 der EUInsVO1 sind die Gerichte des Mitgliedsstaats der EU international zur Eröffnung des Insolvenzverfahrens zuständig, in dem der Schuldner den Mittelpunkt seiner hauptsächlichen Interessen hat. Bei Gesellschaften und juristischen Personen wird bis zum Beweis des Gegenteils vermutet, dass der Ort des satzungsmäßigen Sitzes maßgeblich ist. Bei internationalen Softwareerstellungsverträgen kommt deshalb der Frage, in welchem Land der Auftragnehmer, der die Software erstellen soll, seinen Sitz hat, insoweit eine nicht zu unterschätzende Bedeutung zu. 61 Im deutschen Recht ist seit der Entscheidung des BGH im Jahre 20052 unstreitig, dass das Wahlrecht des Insolvenzverwalters nach § 103 InsO grundsätzlich auch für Softwareverträge Anwendung findet. Sofern der Auftragnehmer, der für den Kunden die Software erstellt und deshalb dem Kunden die entsprechenden Nutzungsrechte einräumen muss, nach der Erstellung in Insolvenz fällt, kann dies unter Umständen dazu führen, dass der Kunde die bereits bezahlte Software nicht mehr nutzen darf, sofern der Insolvenzverwalter den Softwareerstellungsvertrag nach § 103 InsO nicht mehr erfüllen will. Diese Gefahr besteht bei Erstellungsverträgen allerdings weniger als bei zeitlich befristeten Überlassungsverträgen, weil beide Parteien nach Übergabe der erstellten Software durch den Auftragnehmer und Zahlung durch den Kunden den Vertrag vollständig erfüllt haben dürften. Es wird aber teilweise3 vertreten, dass auch bei vollständiger Zahlung des Lizenznehmers die Lizenzeinräumung nachwirkt und deshalb der Auftragnehmer seine Verpflichtungen dennoch nicht vollständig erfüllt habe. Ob diese Auffassung überzeugen kann, muss an dieser Stelle nicht geprüft werden. Jedenfalls sollte man sich bei internationalen Softwareerstellungsverträgen sicherheitshalber ansehen, wie dieses Problem in dem jeweiligen Land, in dem der Auftragnehmer seinen Sitz hat, nach dem lokalen Insolvenzrecht gelöst wird. Dabei kann es nämlich erhebliche Unterschiede geben. 62 In den USA als vielleicht wichtigstem Land der Softwarebranche ist der Kunde bei einer nachfolgenden Insolvenz des Auftragnehmers gut ge-

1 Verordnung (EG) Nr. 1346/2000 des Rates über Insolvenzverfahren v. 29.5.2000, ABl. EG Nr. L 160 S. 1. 2 BGH v. 17.11.2005 – CR 2006, 151 m. Anm. Plath/Scherenberg; dazu auch Berger, CR 2006, 505. 3 So z.B. die Argumentation des LG Mannheim, CR 2004, 811 ff. mit Anm. Grützmacher; einem endgültigen Rechtserwerb könnte bei Werkverträgen ferner das Kündigungsrecht gemäß § 649 Abs. 1 BGB entgegen stehen, vgl. Schneider, Handbuch des EDV Rechts, Kap. J Rz. 44. Der BGH hat in zwei neueren Entscheidungen (BGH v. 19.7.2012 – I ZR 70/10, CR 2012, 572 ff. – M2 Trade, und BGH v. 19.7.2012 – I ZR 24/11, GRUR 2012, 914 – Take Five, entschieden, dass eine Unterlizenz bei Erlöschen der Hauptlizenz nicht wegfällt. In der Literatur wird derzeit diskutiert, ob diese Entscheidungen auch für den Fall der Insolvenz anwendbar sind, vgl. Koch, ITRB 2012, 250 ff.

592

Lejeune

Internationale Softwareerstellungsverträge

Rz. 67

F

schützt. Nach Section 365n des US-amerikanischen Bancruptcy Acts1 sind dem Insolvenzverwalter ausdrücklich sämtliche Handlungen untersagt, die dem Lizenznehmer die Nutzung der erteilten Lizenz unmöglich machen bzw. die Nutzung behindern könnten. In anderen Ländern wie z.B. in Frankreich ist die Rechtslage derjenigen in 63 Deutschland ähnlich. Diese Frage stellt sich natürlich dann nicht, wenn der Auftraggeber den 64 Source Code bereits bei Ablieferung der erstellten Software erhalten hat. Ein bloßer Anspruch auf Herausgabe, sofern dieser vertraglich vereinbart wurde2, reicht dagegen nach deutschem Recht u.U. nicht, weil dies ein Indiz dafür ist, dass der nunmehr insolvente Schuldner den Vertrag bei Eintritt der Insolvenz noch nicht vollständig erfüllt hatte; eine derartige Vertragsgestaltung wäre wohl im Hinblick auf § 103 InsO nicht hilfreich. Dies kann aber in anderen Ländern anders sein und wäre deshalb ggf. vor Vertragsabschluss zu prüfen. In den Niederlanden z.B. kann der Auftraggeber bei einer Insolvenz des Auf- 65 tragnehmers den Source Code herausverlangen, sofern es sich um einen Werkvertrag zur Erstellung einer Individualsoftware handelt3. Aus Sicht des Auftraggebers sollte bei der Verhandlung eines internationalen Softwareerstellungsvertrages geprüft werden, wie solvent der Auftragnehmer ist und welche Rechte dem Auftraggeber ggf. im Falle einer nach Übergabe der erstellten Software eintretenden Insolvenz des Auftragnehmers dem Auftraggeber zustehen bzw. welche Gefahren dann drohen.

66

Der vorsichtige Kunde wird deshalb überlegen, ob es nicht ratsam sei, den 67 Auftragnehmer zur Hinterlegung des Source Code bei einer Hinterlegungs1 11 U.S.C. § 365n; siehe zur Hinterlegung nach US-Recht Lochner, Intellectual Property & Technology Law Journal, Vol. 14, 2002, sowie Paulus, CR 1990, 1 ff. und Kochinke/Fraune, CR 1992, 7 ff. In re Qimonda, Case No. 09-14766-SSM, abgedruckt in CR 2012, 26 ff. m. Anm. Lejeune. Der Insolvenzverwalter der Qimonda AG hatte gegenüber einigen US-amerikanischen Lizenznehmern der insolventen Gesellschaft von seinem Wahlrecht nach § 103 InsO Gebrauch gemacht und die Nichterfüllung der betroffenen Lizenzverträge gewählt. Die USamerikanischen Lizenznehmer wollten diese Entscheidung nicht akzeptieren und klagten dagegen vor einem US-amerikanischen Gericht. Das Gericht gab den Lizenznehmern recht, weil die Anerkennung der Nichterfüllung der betroffenen Lizenzverträge dem Regelungsmodell des § 365n Bankruptcy Act widerspreche und damit im Fall der Anerkennung ein Verstoß gegen die öffentliche Ordnung („public policy“) gegeben sei. Der Fall zeigt sehr plastisch, welche Auswirkungen die unterschiedlichen Regelungsmodelle bei international gelagerten Sachverhalten in der Praxis haben können. 2 Der BGH sieht nach wie vor keinen allgemeinen Herausgabeanspruch bezüglich des Source Code als gegeben, sofern die Parteien keine ausdrückliche Vereinbarung getroffen haben, vgl. BGH v. 16.12.2003 – CR 2004, 7 ff. 3 Quaedvlieg/Fleury/van Andel, in: Ullrich/Lejeune, Der Internationale Softwarevertrag, Teil II Rz. 1160 m.w.N.

Lejeune

593

F Rz. 68

Verträge

stelle („Escrow Agent“) zu verpflichten (s. Kap. L). Als Hinterlegungsstelle kommen vor allem Firmen in Betracht, die sich auf die Hinterlegung von Source Code spezialisiert haben und die im Zweifel prüfen können, ob das hinterlegte Material auch tatsächlich dem zu hinterlegenden Material entspricht. Eine Hinterlegung bei Banken, Notaren oder Rechtsanwälten sollte daher nur im Notfall in Erwägung gezogen werden. Entsprechend spezialisierte Unternehmen findet man inzwischen in allen wesentlichen Industriestaaten. Es spricht aus rechtlicher Sicht aber nichts dagegen, den Source Code bei einer qualifizierten Hinterlegungsstelle in einem anderen als dem Land in dem der Auftragnehmer ansässig ist, zu hinterlegen, falls dies sinnvoll erscheint. 68 Allerdings ist zumindest in Deutschland nicht ganz klar, inwieweit Hinterlegungsvereinbarungen insolvenzfest sind1. Des Weiteren nützt der schönste Source Code nichts, wenn man nicht damit umgehen kann; m.a.W. ohne qualifiziertes Personal hilft der Source Code nicht weiter. In einigen Musterverträgen der auf die Hinterlegung von Software spezialisierten Unternehmen ist gerade für den Fall der Insolvenz immer noch die Zustimmung des insolventen Unternehmens für die Herausgabe erforderlich, die lediglich durch ein Schieds- oder Gerichtsurteil ersetzt werden kann. Eine derartige Regelung ist de facto nutzlos, da man in der Praxis nicht die Zeit hat, zunächst ein entsprechendes Verfahren gegen den Insolvenzverwalter zu betreiben, sondern sofort Zugriff auf den Source Code benötigt, um z.B. Fehler zu beheben. Oft wird in der Praxis vergessen, dass neben dem Abschluss einer Hinterlegungsvereinbarung entsprechende Nutzungsrechte im Softwarevertrag vereinbart werden müssen. Es sollte auch geregelt werden, dass der hinterlegte Quellcode spätestens mit Herausgabe an den Auftraggeber eines Softwareerstellungsvertrages in dessen Eigentum übergeht2. 69 Eine Hinterlegung des Source Code ist daher bei wichtigen Softwareprogrammen sinnvoll, aber u.U. kein Allheilmittel.

V. Datenschutz 70 Sofern im Rahmen von internationalen Softwareerstellungsverträgen personenbezogene Daten von Deutschland in andere Länder übermittelt und dort gespeichert oder weiter verarbeitet werden, ergeben sich besondere Anforderungen des Datenschutzes3.

1 Pro: Fezer, WRP 2004, 793 ff.; Paulus, CR 1990, 1 ff.; Kast/Meyer/Wray, CR 2002, 379 ff.; Kast/Meyer/Peters, CR 2004, 147 ff.; ähnlich zur Rechtslage bei Patentlizenzverträgen Schmoll/Hölder, GRUR 2004, 743 ff.; contra: dezidiert a.A. Hoeren, CR 2004, 721, und Redeker, ITRB 2005, 263 ff. 2 Roth, ITRB 2005, 284 ff. 3 Siehe hierzu Grapentin, CR 2011 102 ff.

594

Lejeune

Internationale Softwareerstellungsverträge

Rz. 74

F

Es ist dann zunächst zu prüfen, ob das Land, in das die Daten übermittelt 71 werden, aus Sicht des deutschen bzw. europäischen Datenschutzrechts über ein angemessenes Schutzniveau verfügt (vgl. § 4b Abs. 2 Satz 2 BDSG). Sollte dies nicht der Fall sein, sind weitere Maßnahmen wie z.B. die Vereinbarung besonderer Vertragsklauseln zum Schutz der Daten erforderlich1. Dies wäre insbesondere im Verhältnis zu den USA der Fall, denn die USA sind aus EU-Sicht nach wie vor kein Land mit angemessenem Datenschutzniveau. Zwar ist der Datentransfer dann unkritisch, wenn US-Unternehmen betroffen sind, die dem sog. Safe-Harbour-Programm beigetreten sind. Allerdings müsste in einem derartigen Fall sichergestellt sein, dass diese Unternehmen dann auch in der Praxis die entsprechenden, für Safe Harbour vorgesehenen Schutzmaßnahmen durchführen2.

72

Sofern eine Auftragsdatenverarbeitung gegeben sein sollte3, müsste eine 73 entsprechende Vereinbarung nach § 11 BDSG vereinbart werden. Dies gilt im Übrigen auch dann, wenn der zugrundeliegende Softwareerstellungsvertrag anderem als deutschem oder europäischen Recht folgen sollte, weil das Datenschutzrecht ebenfalls zwingend, d.h. Teil des Ordre Public ist und deshalb für deutsche Unternehmen unabhängig davon gilt, welches Recht mit einem ausländischen Vertragspartner für einen bestimmten Vertrag vereinbart wurde.

VI. Exportkontrolle Das Thema der Exportkontrolle stellt sich sowohl beim Export von Soft- 74 ware ins Ausland, dann sind vor allem die deutschen Regelungen bzw. die EU-Vorschriften zu beachten, als auch beim Import von Software aus dem Ausland, dann sind primär die Vorschriften des „exportierenden“ Landes zu beachten, allerdings kann auch die Einfuhr bestimmter Güter nach deutschem Recht einer besonderen Genehmigung unterliegen, vgl. § 10 Abs. 1 Satz 2 AWG i.V.m. §§ 27 ff. AWV.

1 Siehe zu den Standardvertragsklauseln Scholz/Lutz, CR 2011, 424 ff. und Grapentin, CR 2011, 102 ff. 2 Sitzung des Düsseldorfer Kreises am 28./29. April 2010 in Hannover („Prüfung der Selbst-Zertifizierung des Datenimporteurs nach dem Safe Harbor Abkommen durch das datenexportierende Unternehmen“) abrufbar unter http://www.bfdi. bund.de/SharedDocs/Publikationen/Entschliessungssammlung/Duesseldorfer Kreis/290410_SafeHarbor.html?nn=409242. 3 Nicht eindeutig ist die Frage zu beantworten, ob § 11 BDSG auch bei der Weitergabe von personenbezogenen Daten an Auftragsdatenverarbeiter außerhalb des EWR einzuhalten ist, was de facto zu einer Änderung der Standard Vertragsklauseln führen müsste, vgl. bei Scholz/Lutz CR 2011, 424 ff.

Lejeune

595

F Rz. 75

Verträge

75 Rechtsgrundlagen des deutschen Exportkontrollrechts sind die unmittelbar geltende europäische „Dual-use-Verordnung1 (nachfolgend als „EG-DualUse-VO“ bezeichnet), das Außenwirtschaftsgesetz (AWG)2, die Außenwirtschaftsverordnung (AWV)3 und das Kriegswaffenkontrollgesetz (KWKG)4. Das KWKG wird in diesem Beitrag nicht erläutert; stattdessen sollen die allgemeinen Vorschriften im Hinblick auf sog. Dual-use-Güter in den wesentlichen Grundzügen kurz dargestellt werden. 76 Sofern exportkontrollrechtliche Tatbestände gegeben sind, muss in der Regel eine besondere Genehmigung eingeholt werden, bevor eine Ausfuhr, Einfuhr oder Durchfuhr5 entsprechender Güter erfolgen darf. Zuständige Behörde ist das Bundesamt für Wirtschaft und Ausfuhrkontrolle, das dem Geschäftsbereich des BMWi angehört6. 77 Dual-use-Güter, d.h. Güter mit doppeltem Verwendungszweck sind gemäß der Definition in Art. 2 Nr. 1 der EG-Dual-Use-VO „Güter, einschließlich Datenverarbeitungsprogramme und Technologie, die sowohl für zivile als auch für militärische Zwecke verwendet werden können; darin eingeschlossen sind alle Waren, die sowohl für nicht explosive Zwecke als auch für jedwede Form der Unterstützung bei der Herstellung von Kernwaffen oder sonstigen Kernsprengkörpern verwendet werden können“. 78 Das Problem besteht hierbei darin, dass es sich nicht um speziell für kritische Zwecke konstruierte Güter handeln muss, es reicht aus, dass es sich um Schlüsselkomponenten z.B. zur Herstellung von Massenvernichtungswaffen handelt. In der Öffentlichkeit bekannt geworden ist das Beispiel von sog. Gaszentrifugen, die beim Bau von Atomanlagen erforderlich sind, aber von ihrem eigentlichen Einsatzzweck für unkritische Anwendungen z.B. in 1 Verordnung (EG) Nr. 1334/2000 v. 22.6.2000, ABL. EG L 159 S. 1, berichtigt durch VO (EG) 1167/2008 v. 24.10.2008 ABL. L 325 S. 1 und gültig bis 27. August 2009; neugefasst durch VO (EG) 428/2009 v. 5.5.2009, ABL L 134 S. 1; Informationen zum Exportkontrollrecht können der Internetseite des BAFA unter http:// www.ausfuhrkontrolle.info entnommen werden. 2 Außenwirtschaftsgesetz v. 28.4.1961, BGBl. I S. 481. Das Außenwirtschaftsrecht und die Außenwirtschaftsverordnung sollen in naher Zukunft geändert werden. Am 31.1.2013 hat der Bundestag das neue Gesetz zur Modernisierung des Außenwirtschaftsrechts beschlossen (Entwurf eines Gesetzes zur Modernisierung des Außenwirtschaftsrechts BT-Drucks. 17/12101). Durch dieses Gesetz wurden zunächst die Struktur des Außenwirtschaftsrechts und die Begrifflichkeiten geändert. Die Grundkonzeption und Systematik der Exportkontrolle blieben zunächst unberührt und sollen wohl durch weitere Gesetze geändert werden, vgl. Haellmigk/Vulin, CR 2013, 350. 3 Außenwirtschaftsverordnung v. 18.12.1986, BGBl. I S. 1934. 4 Kriegswaffenkontrollgesetz v. 22.11.1990, BGBl. L S. 2506. 5 Die Begriffe sind in § 4 AWG definiert. 6 Art. 28 Abs. 3 Nr. 1 AWG i.V.m. § 1 VO zur Regelung von Zuständigkeiten im Außenwirtschaftsverkehr v. 18.7.1997; zur Überprüfung der Vorschriften können auch Zollbehörden, Oberfinanzdirektionen und Staatsanwaltschaften eingeschaltet werden.

596

Lejeune

Internationale Softwareerstellungsverträge

Rz. 81

F

der Forschung vorgesehen sind. Grundsätzlich gilt, dass der Verwendungszusammenhang nicht feststehen muss, es genügt eine gewisse Wahrscheinlichkeit (Verwendungsprognose der Behörde)1. Art. 3 Abs. 1 EG-Dual-Use-VO stellt die Ausfuhr der im Anhang I auf- 79 geführten Güter mit doppeltem Verwendungszweck unter einen pauschalen Genehmigungsvorbehalt. In Anhang I sind die Güter in 9 Kategorien unterteilt, zu jeder Kategorie sind die betroffenen Güter genau aufgeführt. Software und Technologien werden jeweils am Ende einer Kategorie separat aufgeführt und den in der jeweiligen Kategorie aufgeführten Gütern zugeordnet. In der Kategorie 7 „Luftfahrtelektronik und Navigation“ wird z.B. unter Ziffer 7D002 „Software (nur ‚Quellcode‘) für die ‚Verwendung‘ aller Trägheitsnavigationssysteme, einschließlich Trägheitsnavigationsgeräten, die von Nummer 7A003 oder 7A004 nicht erfasst werden, sowie für Fluglage- und Steuerkursreferenzsysteme (AHRS Systeme)“ aufgeführt. Allerdings findet man in Anhang I eine „Allgemeine Software-Anmerkung“, aus der sich ergibt, dass frei erhältliche und allgemein zugängliche Software, die dazu entwickelt wurde ohne umfangreiche Unterstützung durch den Anbieter installiert zu werden, generell nicht unter den Anhang I fällt. Art. 4 Abs. 1 der EG-Dual-Use-VO sieht für Güter, die nicht in Anhang I 80 aufgeführt sind, aber dennoch kritischen Verwendungen, z.B. Waffen oder Flugkörpern für Waffen dienen können, eine allgemeine verwendungsbezogene Genehmigungspflicht vor (sog. „catch-all“-Klausel), sofern die zuständigen Behörden eines Mitgliedsstaates die betroffenen Güter entsprechend eingestuft haben2. Art. 4 Abs. 2 EG-Dual-Use-VO sieht weiter eine Genehmigungspflicht für Lieferungen in ein Land vor, gegen das von der EU ein Waffenembargo verhängt wurde. Nach Art. 9 Abs. 1 EG-Dual-Use-VO i.V.m. Anhang 2 wird für bestimmte Ausfuhren eine allgemeine Ausfuhrgenehmigung der Gemeinschaft erteilt. Art. 22 Abs. 1 EG-Dual-Use-VO i.V.m. Anhang IV und § 7 AWV sieht für bestimmte, besonders kritische und bereits in Anhang I erfasste Güter Beschränkungen der Verbringung auch innerhalb der EU vor. Gemäß Art. 4 Abs. 5 und Art. 8 EG-Dual-Use-VO können die Mitgliedsstaaten weitergehende Genehmigungspflichten einführen, wenn Güter zwar nicht in Anhang I aufgeführt sind, aber die Wahrscheinlichkeit gegeben ist, dass diese für entsprechende Verwendungszwecke bestimmt sein können oder wenn die öffentliche Sicherheit bzw. Menschenrechtserwägungen dies erfordern. Aufgrund dieser Rechtsgrundlagen geht das deutsche Recht z.T. über das 81 EU-Recht hinaus, insoweit als zusätzliche Genehmigungspflichten betroffen sind. Die sog. Ausfuhrliste bestimmt als Anlage zur Außenwirtschafts-

1 Weith/Wegener/Ehrlich, Grundzüge der Exportkontrolle, Rz. 86. 2 Siehe auch die ergänzenden nationalen Vorschriften der §§ 5c und 5d AWV, die allerdings die Ausfuhr in die dort bzw. der Länderliste K aufgeführten Länder beschränken.

Lejeune

597

F Rz. 82

Verträge

verordnung den Umfang dieser zusätzlichen (nur nationalen) Genehmigungspflichten für Dual-Use- und für Rüstungsgüter1. 82 In Art. 2 Nr. 2 iii) der EG-Dual-Use-VO wird im Übrigen auch die Übertragung von Software oder Technologie mittels elektronischer Medien, Telefax oder Telefon nach einem Bestimmungsziel außerhalb der Gemeinschaft als Ausfuhr definiert2. 83 Bei den vorgenannten 9 Kategorien in Anhang I handelt es sich um kerntechnische Materialien, Anlagen und Ausrüstung (Kategorie 0), besondere Werkstoffe und Materialien und zugehörige Ausrüstung (1), Werkstoffbearbeitung (2), Allgemeine Elektronik (3), Rechner (4), Telekommunikation und „Informationssicherheit“ (5), Sensoren und Laser (6), Luftfahrtelektronik und Navigation (7), Meeres- und Schiffstechnik (8), Luftfahrt, Raumfahrt und Antriebe (9). 84 §§ 45 ff. AWV sehen Sondervorschriften bezüglich technischer Unterstützung vor. Der Begriff ist in § 4c Nr. 7 AWV dahingehend definiert, dass jede technische Unterstützung in Verbindung mit der Reparatur, Entwicklung, Herstellung, Montage, Erprobung, Wartung oder jeder anderen technischen Dienstleistung erfasst sind; erfasst sind auch mündliche, fernmündliche oder elektronische Formen der Unterstützung. Hervorzuheben ist insbesondere § 45d AWV, danach ist technische Unterstützung durch nicht gebietsansässige Deutsche. ebenfalls ein genehmigungspflichtiger Tatbestand. Mit dieser Regelung soll eine Umgehung durch Wohnsitzverlagerung ins Ausland vermieden werden. Allgemein zugängliche Informationen oder Grundlagenforschung sind generell nicht erfasst3. 85 Kapitel VIIa ff. AWV sehen spezielle Länderembargos vor, die auf entsprechenden Resolutionen des Sicherheitsrates der Vereinten Nationen beruhen. 86 Bei der Einfuhr von Software nach Deutschland sind vor allem die jeweiligen nationalen Regelungen des exportierenden Landes anzusprechen. In diesem Zusammenhang ist insbesondere das US-amerikanische Recht von Bedeutung. Im Mittelpunkt steht dabei der Export Administration Act ergänzt durch die Export Administration Regulations4. Jeweils einschlägige Kontrollansätze hängen von Ausfuhrgut, Zielland, Endverwendung und Endanwender ab. Insofern entsprechen die amerikanischen Anknüpfungspunkte der deutschen Systematik. Eine mittelbare extraterritoriale Wirkung der Bestimmungen wird aber durch die Einbeziehung von Exporten des Empfän1 Allerdings entspricht Teil I Abschnitt C der Ausfuhrliste weitgehend dem Anhang I der VO, mit Ausnahme der nationalen Listenpositionen. 2 Siehe auch § 4 Nr. 4 AWG, die Parallelvorschrift im deutschen Recht. 3 Weith/Wegener/Ehrlich, Grundzüge der Exportkontrolle, Rz. 118. 4 Export Administration Regulations 17 CFR Parts 730–744, abrufbar unter http://www.access.gpo.gov/bis/ear/ear_data.html. Siehe zu den geplanten Änderungen im US-Recht Hölscher, RIW 2011, 523.

598

Lejeune

Internationale Softwareerstellungsverträge

Rz. 90

F

gers von US-Lieferungen in Drittländer erzeugt (sog. Re-Export). Sanktionen gegen im Ausland ansässige Personen oder Unternehmen können entweder über den Konzernverbund oder aber mittels Entzug der Belieferungsfähigkeit (Aufnahme des Unternehmens in die Denied Persons List) umgesetzt werden. Verstöße gegen die US-amerikanischen Bestimmungen können u.U. auch Auswirkungen auf das politische Klima zwischen den USA und Deutschland haben, deswegen sollte jedes Unternehmen hier besonders vorsichtig sein. Verstöße gegen die Exportkontrollvorschriften sind in der Regel strafbe- 87 wehrt, vgl. §§ 34 AWG und 70a AWV. Vorsätzliche Verstöße werden mit Freiheitsstrafe von bis zu fünf Jahren bestraft. Für die exportkontrollrechtliche Beurteilung sollte man immer drei Punkte 88 prüfen: (1) Um was für ein Produkt handelt es sich (exportkontrollrechtliche Einstufung durch den Lieferanten erfragen), welche Nutzungen sind mit dem Produkt möglich oder sogar wahrscheinlich. (2) Aus welchem Land kommt oder in welches Land soll das Produkt verbracht werden. (3) Bestehen in Anbetracht des Vertragspartners Bedenken? Ist dieser Vertragspartner zuverlässig, sind Verstöße gegen das Exportkontrollrecht aus der Vergangenheit bekannt oder befindet sich der Vertragspartner sogar auf einer Liste der unzulässigen Firmen? Im Zweifelsfall sollte man eine Vorab-Prüfung durch die zuständigen Be- 89 hörden gemäß Art. 4 Abs. 4 der EG-Dual-Use-VO veranlassen. Verstöße gegen das Exportkontrollrecht können nämlich u.a. auch dazu führen, dass das betreffende Unternehmen von der Vergabe öffentlicher Aufträge in Deutschland ausgeschlossen werden kann.

Sonderproblem: Copyleft Effekt nach der GNU GPL Nach Section 2c der GNU GPL Version 2 von Juni 19911 besteht unter be- 90 stimmten Umständen die Pflicht, den Source Code eines Open-Source-Programms und ggf. den Source Code eines damit verbundenen proprietären Programms offen zu legen, d.h. der Allgemeinheit zur Verfügung zu stellen, wenn das Produkt an Dritte z.B. Kunden weitergegeben werden und nicht nur im eigenen Unternehmen genutzt werden soll. Dies bedeutet insbesondere, dass der jeweilige Softwarecode überall auf der Welt verfügbar sein muss. Eine derartige Freigabe steht aber im Widerspruch zu den exportrechtlichen Genehmigungsvorbehalten. Sofern zum Beispiel aufgrund der exportrechtlichen Restriktionen der Export einer Software in ein bestimmtes Land oder an einen bestimmten Kunden in einem Land unzulässig ist, 1 www.gnu.org; siehe bereits oben unter Rz. 6.

Lejeune

599

F Rz. 91

Verträge

dann darf auch der Source Code der betroffenen Software dort nicht verfügbar sein. Da die GNU GPL in Ziffer 6 das „alles oder nichts“-Prinzip verfolgt, d.h. sofern man die Bedingungen der GNU GPL nicht vollständig erfüllen kann, darf man das der GUN GPL unterliegende Softwareprodukt nicht nutzen, können exportkontrollrechtliche Vorbehalte dazu führen, dass Open-Source-Produkte nach der GNU GPL für die Entwicklung und den Vertrieb entsprechender Produkte nicht genutzt werden dürfen. 91 Es liegt auf der Hand, dass diese Problematik bei umfassenden Produkten, insbesondere bei Industrieanlagen zu großen Abgrenzungsproblemen führen kann. Man wird in diesen Fällen zu prüfen haben, ob die Open-Source-Software Teil des exportkontrollpflichtigen Teils des Produkts bzw. der Kundenlösung ist oder ob diese Software eine allgemeine Anwendung betrifft, die zwar Teil des Produkts ist, aber nicht der Exportkontrolle unterfällt (Bsp.: speziell zur Steuerung einer Industrieanlage verwendete Open-Source-Software kann kritisch sein, Open-Source-Software nur zum Betrieb eines hierzu verwendeten Standard Notebooks dürfte unkritisch sein). Soweit bekannt, gibt es zu diesem Themenkreis noch keine offiziellen Empfehlungen der Exportkontrollbehörden.

600

Lejeune

3. Kapitel Sonderregelungen G. Verträge zur Anpassung, Einführung und Implementierung von Standardsoftware Rz. I. Vorvertragliche Probleme – aus dem Verhandlungsstadium resultierende Pflichten der Vertragspartner . . . . . . . . . . . . . . 1. Vertriebliche Zusagen, Angebotsphase . . . . . . . . . . . . . . . 2. Verletzung von Aufklärungspflichten, technisch und wirtschaftlich nicht haltbare Zusagen . . . . . . . . . . . . . . . . . . . . . 3. Verletzung von Geheimhaltungspflichten . . . . . . . . . . . . 4. Schutz und Haftung Dritter . . . 5. Abbruch von Vertragsverhandlungen . . . . . . . . . . . . . . . 6. Letter of Intent/Memorandum of Understanding . . . . . . . . . . . . . II. Typischer Vertragsgegenstand von Verträgen zur Anpassung, Einführung und Implementierung von Standardsoftware und rechtliche Gestaltungsmöglichkeiten . . . . . . . . . . . . . . . 1. Gegenstand eines IT-Projekts über (Lieferung,) Anpassung, Einführung und Implementierung von Standardsoftware . . . . a) Vorbemerkung . . . . . . . . . . . . . aa) Pflichtverletzung nach der Schuldrechtsreform und vertragliches Pflichtenprogramm . . . . . . . . . . bb) Auswirkungen für die Vertragsgestaltung . . . . . . cc) Orientierung an Projekten im Bereich Enterprise Ressource Planning . . . . . . . . . . . . . . . . . . . b) Fallstudien . . . . . . . . . . . . . . . . c) Standardsoftware . . . . . . . . . .

1 1

4 10 15 22 23

27

27 27

27 28

34 35 37

Rz. aa) Terminologie . . . . . . . . . . . bb) Technische Möglichkeiten zur Anpassung . . . . . . cc) Open-Source-Komponenten . . . . . . . . . . . . . . . . . d) Gegenstand der Anpassung, Einführung und Implementierung von Standardsoftware . . . . . . . . . . . . . . . . . . . . . . aa) Anpassungsbedarf. . . . . . . bb) Feststellung des Anpassungsbedarfs . . . . . . . . . . . cc) Einführung und Implementierung . . . . . . . . . . . . (1) Aufgaben während der Einführung . . . . . . (2) Aufgaben während der Implementierung . e) Wirtschaftliche Auswirkungen der Einführung und Implementierung von Standardsoftware für den Anwender . . . . . . . . . . . . . . . . . aa) Vorteile gegenüber der Individualentwicklung . . bb) Komplexität und Aufwand . . . . . . . . . . . . . . . . . . cc) Nachteile von Standardsoftware . . . . . . . . . . . . . . . dd) Konsequenzen für die Vertragsgestaltung . . . . . . 2. Denkbare Gestaltungsmöglichkeiten und rechtliche Einordnung von Verträgen über Anpassung, Einführung und Implementierung von Standardsoftware . . . . . . . . . . . . . . . . . a) Unterschiedliche Interessen von Softwareanbieter und -anwender . . . . . . . . . . . . . . . . .

Witzel

37 41 44

46 47 49 50 50 54

56 56 57 59 60

63

63

601

G

602

Sonderregelungen Rz.

Rz.

b) Anpassung einer Standardsoftware durch den Lieferanten (Hersteller) der Standardsoftware . . . . . . . . . . . . . . 66 aa) Abschluss eines einheitlichen Vertrags oder mehrerer verbundener Verträge . . . . . . . . . . . . . . . 66 bb) Getrennte Verträge über Software-Überlassung und Anpassung und Einführung . . . . . . . . . . . . 67 c) Anpassung einer Standardsoftware durch einen anderen Softwareanbieter als den Lieferanten: Vertrag ausschließlich über Anpassung und Einführung . . . . . . . . . . . . 69 d) Rechtliche Einordnung von Verträgen über die Anpassung und Einführung von Standardsoftware . . . . . . . . . . 71 aa) Gesetzliche Grundlagen: Vertragstypen und ihre Leistungen . . . . . . . . . . . . . 71 bb) Unterschiede der einzelnen Vertragstypen . . . . . . 79 cc) Meinungsstand zu § 651 BGB . . . . . . . . . . . . . 80 dd) BGH-Entscheidung vom 23.7.2009. . . . . . . . . . 87 ee) Weitere Entscheidungen. 94 ff) Konsequenzen: Rechtliche Qualifikation von Verträgen über die Anpassung und Einführung von Standardsoftware . . . 98 (1) Leistungen bei Anpassung, Einführung und Implementierung . . . . . . . . . . . . . . . . 99 (2) „Anpassung“ der Standardsoftware . . . . 106 (3) Weitere Leistungen im Rahmen der Einführung und Implementierung . . . . . . . . . 109

gg) Verträge über die Anpassung, Einführung und Implementierung von Standardsoftware als gemischte Verträge. . . . . . 112 3. Probleme in Projekten über die Einführung und Implementierung von Standardsoftware und Konsequenz für die Vertragsgestaltung . . . . . . . . . . . . . . . . . . . 122 a) Ursachen für das Scheitern eines Projekts . . . . . . . . . . . . . . 122 b) „Das Schicksal von Großprojekten … oder warum sie scheitern“ . . . . . . . . . . . . . . 128

Witzel

III. Leistungen des Softwareanbieters im Rahmen der Anpassung und Einführung (Implementierung) von Standardsoftware . . . 128a 1. Sondierung und Projektumsetzung . . . . . . . . . . . . . . . . . . . . . 128a 2. Einzelne Leistungen des Anbieters im Rahmen von Anpassung und Implementierung . . . . 129 a) Einzelne Leistungen im Überblick . . . . . . . . . . . . . . . . . 130 b) Einzelne Leistungen im Detail . . . . . . . . . . . . . . . . . . . . . 133 aa) Lieferung der Standardsoftware . . . . . . . . . . . . . . . 133 bb) Erstellung eines Pflichtenhefts/einer Feinspezifikation über erforderliche Änderungen und/oder Ergänzungen der Standardsoftware . . . . 135 cc) „Customizing“ der Standardsoftware . . . . . . . 139 dd) Integration der Standardsoftware in die Systemumgebung des Anwenders, Implementierung in die Organisationsstruktur. . . . . . . . . . . . . . . . 142 ee) Altdatenübernahme, Migration . . . . . . . . . . . . . . 144 ff) Installation. . . . . . . . . . . . . 146

G

Implementierung von Standardsoftware Rz.

Rz.

gg) Einweisung und Schulung . . . . . . . . . . . . . . 148 hh) Einführungsunterstützung, Go-Life Support . . . 151 c) Leistungsbeschreibung, Pflichtenheft, Feinspezifikation . . . . . . . . . . . . . . . . . . . . 152 aa) Begrifflichkeiten. . . . . . . . 152 bb) Bedeutung von Leistungsbeschreibung und Anforderungsbeschreibung (Pflichtenheft oder Feinspezifikation) für die Vertragsgestaltung. . . 155 cc) Abgrenzung Leistungsbeschreibung/Garantie . . 165 dd) Verantwortlichkeit des Anwenders für die Beibringung der Anforderungen . . . . . . . . . . . . . . . . 170 ee) Fehlendes und unzureichendes Pflichtenheft . . . 175 (1) Fehlendes Pflichtenheft . . . . . . . . . . . . . . . . 175 (2) Unzureichendes Pflichtenheft . . . . . . . . 178 d) Inhalt und Aufbau einer Anforderungsbeschreibung/eines Pflichtenhefts . . . . . . . . . . 180 aa) Aufbau und Inhalt . . . . . . 180 bb) Beschreibung der funktionalen Anforderungen . 182 cc) Allgemeine Bestimmungen zur „Qualität der Software“: Nicht-funktionale Anforderungen/ qualitative Anforderungen . . . . . . . . . . . . . . . . 188 dd) Kriterien für die Beschreibung funktionaler und nicht funktionaler Kriterien . . . . . . . . . . . . . . . 195

V. Mitwirkung des Auftraggebers . 204 1. Vorbemerkung . . . . . . . . . . . . . . . 204 2. Gesetzliche Bestimmungen zur Mitwirkung . . . . . . . . . . . . . . 212 3. Erforderlichkeit der Mitwirkung des Anwenders bei Anpassung und Einführung (Implementierung) von Standardsoftware . . . . . . . . . . . . . . . . . 215 a) Mitwirkung des Anwenders als Voraussetzung für den Projekterfolg . . . . . . . . . . . . . . . 215 b) Vertragliche Vereinbarungen zur Mitwirkung . . . . . . . . . . . . 217 aa) Notwendigkeit klarer Vereinbarungen zu Inhalt und Umfang der Mitwirkung . . . . . . . . . . . . 217 bb) Umfang der Mitwirkungsleistung als Grundlage für Kalkulation und Zeitplanung. . . . 222 cc) Rechtliche Qualifizierung der Mitwirkungsleistungen im Vertrag . . . 226 c) Folgen unzureichender Mitwirkung . . . . . . . . . . . . . . . 227

IV. Projektplanung: Fristen- und Aktivitätenplan . . . . . . . . . . . . . . 197 1. Notwendigkeit einer konkreten Projektplanung . . . . . . . . 197 2. Vereinbarte Termine, Nichteinhaltung und deren Konsequenzen, Gestaltungsmöglichkeiten . . . . . . . . . . . . . . . 201

VI. Weitere Leistungen des Softwareanbieters . . . . . . . . . . . . 231 1. Dokumentation, Form und Art der Dokumentation . . . . . . . . . . . 231 a) Grundsätzliches zur Bedienungsanleitung (Anwenderdokumentation) . . . . . . . . . 231 b) Einzelheiten zur Bedienungsanleitung aus der Rechtsprechung . . . . . . . . . . . . 233 d) Offene Fragen, insbesondere weitere Arten der Dokumentation . . . . . . . . . . . . . . . . . 234 d) Fälligkeit und Mangelhaftigkeit der Bedienungsanleitung . . . . . . . . . . . . . . . . . . . . 238 aa) Fälligkeit . . . . . . . . . . . . . . 238 bb) Mangelhafte Bedienungsanleitung . . . . . . . . . 240 e) Beschreibung der Dokumentation im Vertrag . . . . . . . . . . . 241 2. Quellcode-Hinterlegung, Quellcode-Herausgabe . . . . . . . . 248

Witzel

603

G

Sonderregelungen Rz.

Rz.

a) Quellcode-Herausgabe. . . . . . 248 b) Softwarehinterlegung: Escrow . . . . . . . . . . . . . . . . . . . . 252 3. Einhaltung von Qualitätsstandards, Maßnahmen zur Qualitätssicherung . . . . . . . . . . . 254 a) Pflicht des Anbieters zur Qualitätssicherung. . . . . . . . . 254 b) Qualitätssicherung hinsichtlich der Software . . . . . . 256 c) Regelungen zur Qualitätssicherung im Vertrag . . . . . . . 257 4. Einzusetzendes Personal, Mitarbeiterqualifikation, Anzahl der Mitarbeiter . . . . . . . . . . . . . . . 258

bb) Mögliche Phasen des Änderungsverlangens . . . 282 g) Bewertungsgrundlage für Mehraufwände: Aufwandskalkulation . . . . . . . . . . . . . . . . 288 h) Ungeeignete Ausführungsart . . . . . . . . . . . . . . . . . . . . . . . . 289 i) Empfehlungen für die Vertragsgestaltung . . . . . . . . . 292

VII. Änderungen des Leistungsumfangs (Change Request) . . . . 260 1. Typische Änderungssituationen . . . . . . . . . . . . . . . . . . 260 a) „Was lange währt, wird endlich anders“ . . . . . . . . . . . . 260 b) Kategorisierung von Änderungen . . . . . . . . . . . . . . . . . . . . 265 c) Rechtsprechung bei fehlendem Änderungsverfahren . . . 267 d) Auswirkungen von Änderungen auf Termine . . . . . . . . 268 aa) Berücksichtigung von Änderungen bereits bei der Terminplanung . . . . . 268 bb) Anpassung der Terminplanung während des Projekts . . . . . . . . . . . . . . . 270 e) Auswirkungen von Zusatzwünschen und Änderungen auf die Vergütung . . . . . . . . . . 271 aa) Konsequenzen des Vertragstyps, Festpreis- und Zeitaufwandsprojekte . . . 271 bb) Vergütung von Mehraufwand . . . . . . . . . . . . . . . 274 cc) Nachweis des Mehraufwands . . . . . . . . . . . . . . 277 f) Praktische Handhabung von Änderungsverlangen . . . . . . . 280 aa) Zumutbarkeit der Durchführung von Änderungen, Erfordernis eines vertraglichen Änderungsverfahrens . . . . . . 280

604

Witzel

VIII. Rechtseinräumung, Nutzungsund Verwertungsrechte . . . . . . . 293 1. Unterscheidung zwischen Standardkomponenten und individuellen Ergänzungen/ Erweiterungen . . . . . . . . . . . . . . . 293 a) Differenzierung zwischen den Liefergegenständen, insbesondere „Standard“ und „Anpassungen“ . . . . . . . . . . . . 293 b) Standardkomponenten. . . . . . 294 c) Individuelle Erweiterungen/ Ergänzungen („Add-ons“) . . . 298 d) Parameter und Parametrisierung . . . . . . . . . . . . . . . . . . . . . . 300 e) Sonstige Arbeitsergebnisse . . 301 f) Spezifizierungslast bei Gestaltung der Rechtseinräumung . . . . . . . . . . . . . . . . . . 302 2. Formulierungsvorschläge. . . . . . 303 IX. Vergütungsmodelle . . . . . . . . . . . 306 1. Vergütung und Vertragstypen . . 306 a) Festpreis contra Aufwandsabrechnung . . . . . . . . . . . . . . . . 306 b) „Übliche“ Vergütung bei fehlender Vergütungsabrede . 308 c) Widerstreitende Interessen von Anwender und Softwareanbieter. . . . . . . . . . . . . . . 310 2. Festpreisabreden . . . . . . . . . . . . . 311 a) Aufwandsabreden, Vergütungsobergrenzen . . . . . . . . 313 b) Fälligkeitsregelungen . . . . . . . 316 X. Ablieferung, Abnahme und Tests . . . . . . . . . . . . . . . . . . . . . . . . 317 1. Gesetzliche Regelungen zur Abnahme und Konsequenzen des § 651 BGB . . . . . . . . . . . . . . . . 318 a) Begrifflichkeiten und Terminologie . . . . . . . . . . . . . . . . . . . . 318

G

Implementierung von Standardsoftware

2.

3. 4. 5.

Rz.

Rz.

b) Wirkungen der Abnahme . . . 321 c) Auswirkungen des § 651 BGB . . . . . . . . . . . . . . . . . . . . . . 327 Testverfahren, Testverpflichtung . . . . . . . . . . . . . . . . . . . . . . . . 329 a) Notwendigkeit vertraglicher Regelungen. . . . . . . . . . . . . . . . 329 aa) Erarbeitung von Testprozeduren . . . . . . . . . . . . . 329 bb) Weiterer Regelungsbedarf . . . . . . . . . . . . . . . . . 332 cc) Gestaltungsvorschlag . . . 337 Stillschweigende Abnahme . . . 338 Fiktionen . . . . . . . . . . . . . . . . . . . . 340 Datenschutzrechtliche Aspekte bei Tests und Abnahme . . . . . 341

c) Gesetzlicher Mangelbegriff im Kauf- und Werkvertragsrecht . . . . . . . . . . . . . . . . . . . . . . 367 aa) Vertraglich vereinbarte Beschaffenheit . . . . . . . . . . 368 bb) Vertraglich vorausgesetzte Verwendung . . . . . . 369 cc) Gewöhnliche Verwendung . . . . . . . . . . . . . . . . . . . 371 dd) Typische Softwaremängel . . . . . . . . . . . . . . . . 373 d) Mögliche vertragliche Ausgestaltung des (Sach-)Mangelbegriffs . . . . . . . . . . . . . . . . . 374 aa) Bedeutung der Leistungsbeschreibung (Pflichtenheft) . . . . . . . . . . 374 bb) Lücken der Leistungsbeschreibung (Pflichtenheft) . . . . . . . . . . . . . . . . . . . 381 e) Mängelanzeige des Kunden, Anwendbarkeit von § 381 Abs. 2 HGB . . . . . . . . . . . . . . . . 382 aa) Untersuchungs- und Rügepflicht . . . . . . . . . . . . 382 bb) Mängelanzeige . . . . . . . . . 383 f) Verjährung von Mängelansprüchen . . . . . . . . . . . . . . . . 385 g) Rechtsfolgen von Mängeln . . 391 aa) Überblick . . . . . . . . . . . . . . 391 bb) Nacherfüllung . . . . . . . . . 391a cc) Rücktritt. . . . . . . . . . . . . . . 393 h) Schadensersatz statt der Leistung. . . . . . . . . . . . . . . . . . . 394 i) Besonderheiten bei Rechtsmängeln. . . . . . . . . . . . . . . . . . . 395 aa) Vorliegen eines Rechtsmangels. . . . . . . . . . . . . . . . 395 bb) Unterschiedliche Interessenlage im Verhältnis zum Sachmangel . . . . . . . 396 cc) Formulierungsvorschläge . . . . . . . . . . . . . . . . 403 j) Sonstige Schlechtleistung . . . 406 5. Sonstige Vertragsgestaltung bei Leistungsstörungen, insbesondere Haftungsbegrenzungen . . . 407 a) Vorbemerkung . . . . . . . . . . . . . 407 b) Haftungsbeschränkungen in AGB . . . . . . . . . . . . . . . . . . . . . . 411

XI. Leistungsstörungen . . . . . . . . . . 342 1. Vorbemerkung . . . . . . . . . . . . . . . 342 2. Überblick zu den durch die Schuldrechtsmodernisierung bedingten Änderungen im Leistungsstörungsrecht . . . . . . . 345 a) Begriff der Leistungsstörung 345 b) Rechtsfolgen einer Pflichtverletzung. . . . . . . . . . . . . . . . . 348 aa) Schadensersatz . . . . . . . . . 348 bb) Rücktritt . . . . . . . . . . . . . . 353 cc) Ersatz vergeblicher Aufwendungen . . . . . . . . . 354 3. Verzug . . . . . . . . . . . . . . . . . . . . . . 355 a) Verbindlichkeit der vereinbarten Termine . . . . . . . . . . . . 356 b) Mahnung . . . . . . . . . . . . . . . . . 359 c) Fristsetzung . . . . . . . . . . . . . . . 361 aa) Verbrauchte Fristsetzungen. . . . . . . . . . . . . . 361 bb) „Ablehnungsandrohung“ . . . . . . . . . . . . . . 362 d) Verzugsschäden. . . . . . . . . . . . 363 4. Mangelhafte Leistungen bei Anpassung, Einführung und Implementierung von Standardsoftware: Sach- und Rechtsmängel und sonstige Schlechtleistung . . . . . . . . . . . . . 364 a) Vorbemerkung . . . . . . . . . . . . . 364 b) Gleichstellung von Sachund Rechtsmängeln im Kauf- und Werkvertragsrecht. . . . . . . . . . . . . . . . . . . . . . 366

Witzel

605

G Rz. 1

Sonderregelungen Rz.

Rz.

c) Haftungsbeschränkungen in individuellen Vereinbarungen . . . . . . . . . . . . . . . . . . . . . . . 415

d) Außerordentliche Kündigung . . . . . . . . . . . . . . . . . . . . . . 426 e) Sonderkündigungsrechte . . . . 431 2. Gestaltungsmöglichkeiten zur Kündigung . . . . . . . . . . . . . . . 433 3. Pflichten nach Vertragsbeendigung . . . . . . . . . . . . . . . . . . 435 a) Unterstützungsleistungen („Termination Assistance“) . 435 b) Datenmigration, Datenherausgabe . . . . . . . . . . . . . . . . 436

XII. Beendigung des Anpassungs-, Einführungs- und Implementierungsprojekts, insbesondere nach § 649 BGB . . . . . . . . . . . . . . 418 1. Beendigungstatbestände . . . . . . 418 a) Rücktritt . . . . . . . . . . . . . . . . . . 419 b) Ordentliche Kündigung beim Werkvertrag . . . . . . . . . . 421 c) Ordentliche Kündigung beim Dienstvertrag . . . . . . . . 425

I. Vorvertragliche Probleme – aus dem Verhandlungsstadium resultierende Pflichten der Vertragspartner 1. Vertriebliche Zusagen, Angebotsphase 1

Nicht selten wird übersehen, dass bereits im Verhandlungsstadium, und sogar dann, wenn die Verhandlungen erfolglos abgebrochen werden, Pflichten und Rechte für die (intendierten) Vertragsparteien und Dritte begründet werden1. Dies spielt auch bei Projekten zur Anpassung von Standardsoftware eine Rolle, insbesondere deshalb, weil Softwareanbieter gerade in der Vertriebsphase dazu neigen, die Vorteile (insbesondere den Funktionsumfang und die daraus resultierenden Möglichkeiten für den Anwender) ihres Produkts anzupreisen2, ohne sich dessen bewusst zu sein, dass sie sich im Verlauf des Projekts an ihren Aussagen festhalten lassen müssen. Anwender, die gut beraten wären, vor ihrer Entscheidung, ein Projekt zu starten, eine Machbarkeitsstudie durchführen zu lassen, um basierend auf deren Ergeb1 Witzel, Projektvorbereitung, ITRB 2011, 164; Witzel, Evaluierungsprojekte, ITRB 2011, 293. 2 Sontow, Computerwoche v. 11.1.2012, http://www.computerwoche.de/mittel stand/2501634/: So finden Sie das ideale ERP-System: „Neben der Komplexität, der Tragweite der Aufgabenstellung sowie dem sehr unübersichtlichen ERP-Angebot, macht vor allem ein Umstand den Suchenden das Leben schwer: Alles auf einmal gibt es nicht, auch wenn die Hersteller in die Marketing-Trickkiste greifen, um anderes zu suggerieren. Die berühmte „eierlegende Wollmilchsau“, die alle Anforderungen erfüllt, ist nicht in Sicht.“; Hülsbömer, Computerwoche v. 24.1.2011, http://www.computerwoche.de/mittelstand/1906617/: Die schmutzigen Tricks der Hersteller: „Es fängt alles ganz harmlos an – mit einer Produktdemo, die reibungslos funktioniert und gut aussieht. Der Hersteller kommuniziert einen Preis, der zu gut klingt, um wahr zu sein – der Fehlbetrag wird später über die Gebühren für Änderungsaufträge oder Wartung und Support ausgeglichen …“; Bischof, Die Gestaltung von Präambeln in IT-Projekten unter Einbeziehung von Presales-Präsentationen der IT-Unternehmen, ITRB 2006, 289.

606

Witzel

Implementierung von Standardsoftware

Rz. 2 G

nis einen Softwareanbieter auszuwählen, wollen die dadurch entstehenden Kosten gerne sparen und nicht sehen, dass am falschen Ende gespart wird. Die Kostenfallen, die durch falsche Versprechungen entstehen, sind wesentlich höher als die Kosten einer Machbarkeitsstudie oder Evaluierung. Eine Machbarkeitsstudie wird idealerweise Auskunft darüber geben, ob sich ein geplantes System „lohnen“ wird und ob es überhaupt realisierbar ist. Im Rahmen einer solchen Studie sind typischerweise folgende Themen relevant: – grobe Definition der Ziele des Vorhabens, – Ist-Analyse der bestehenden Prozesse, Systeme und organisatorischen Gegebenheiten, – Erhebung der groben Anforderungen, – Vergleich verschiedener Lösungsansätze, – Formulierungen von Annahmen zur zu verwendenden Technologie, – Feststellung des erforderlichen Budgets, – Kosten-/Nutzenanalyse, – mögliche Projektstruktur, – grobe Planung. Zu beachten ist, dass durch die Verhandlungen, Gespräche und Präsentatio- 2 nen1 ein besonderes Vertrauensverhältnis mit eigenen Ansprüchen aus § 280 BGB entstehen kann. Blumige, vertriebliche Formulierungen, wie etwa „Der Auftragnehmer bietet dem Auftraggeber eine konkurrenzlose Kombination von Technologie, Dienstleistungen, Commitment und Qualität für die Abdeckung des aktuellen Anforderungsspektrums und die Erreichung der Geschäftsziele des Auftraggebers sowie einen sicheren Pfad für die Zukunft.“

oder „Die angebotene Lösung stellt einzigartige Fähigkeiten bereit, die das komplette Anforderungsspektrum des Auftraggebers abdeckt.“

oder „Die angebotene Lösung basiert auf anerkannten Industriestandards und Technologien, wie beispielsweise (…), um eine nahtlose Integration in die unternehmensweite Infrastruktur des Auftraggebers zu ermöglichen.“

oder „Der Funktionsumfang der angebotenen Lösung deckt 1:1 den Funktionsumfang des beim Auftraggeber eingesetzten Altsystems ab.“

können – wenn auch sehr unbestimmt – den Softwareanbieter zu einem späteren Zeitpunkt in erhebliche Schwierigkeiten bringen, vor allem dann, 1 Hülsbömer, Computerwoche 2011, http://www.computerwoche.de/mittel stand/1906617/index2.html. Im März 2008 verklagte Waste Management, der größte Müllentsorgungsbetrieb der USA, den deutschen Hersteller SAP auf 100 Millionen Dollar wegen einer fehlgeschlagenen ERP-Implementierung. Waste Management warf der SAP vor, die Produktdemonstration während der Verkaufspräsentation gefälscht zu haben …“.

Witzel

607

G Rz. 3

Sonderregelungen

wenn der Anwender dafür sorgt, dass das abgegebene Angebot Anlage zum Vertragsbestandteil wird oder sich ggf. durch weitere vertragliche Formulierungen absichert: „Der Auftragnehmer hat im Auftrag und gemeinsam mit dem Auftraggeber Machbarkeitsanalysen durchgeführt, nach deren Auswertung der Auftraggeber das (…)-System als technisch, betrieblich und wirtschaftlich günstige und geeignete Lösung für die betrieblichen Aufgaben im Bereich (…) auf Empfehlung des Auftragnehmers ausgewählt hat.“

3

Werden vor Abschluss des Vertrags Verhandlungen darüber geführt, ob und in welcher Weise sich eine Standardsoftware zur softwaretechnischen Lösung der Probleme des Anwenders anbietet, so ist der Softwareanbieter, der meist sachkundiger ist, verpflichtet, die Bedürfnisse des Anwenders sorgfältig zu analysieren und ggf. Nachfragen zu stellen1. Der Anwender sollte solche Analysen nicht wegen mangelnder Ressourcen abwehren, sondern Zeit – und ggf. auch Geld – investieren. Nur Klarheit über den Leistungsumfang vermeidet spätere Enttäuschungen im Projekt2. Sämtliche Unterlagen, die Bestandteil der vertraglichen Vereinbarungen werden, sollten von beiden Vertragspartnern vor Unterzeichnung kritisch darauf geprüft werden, ob der Inhalt zutreffend und etwaige Zusagen realistisch sind. 2. Verletzung von Aufklärungspflichten, technisch und wirtschaftlich nicht haltbare Zusagen

4

Durch die Aufnahme von Vertragsverhandlungen entsteht zwischen den Verhandlungspartnern ein Schuldverhältnis mit Pflichten nach § 241 Abs. 2 BGB. Zu den im Rahmen dieses vorvertraglichen Schuldverhältnisses bestehenden Pflichten gehört auch die sachgerechte Aufklärung über solche Umstände, die für die andere Partei von erkennbar entscheidender Bedeutung sind und über die nach allgemeiner Anschauung redlicherweise Aufklärung erwartet werden darf3. Wer gegen eine solche Aufklärungspflicht verstoßen 1 OLG Celle, in: Zahrnt, ECR OLG 175. 2 Gebhardt, Computerwoche v. 4.1.2013, http://www.computerwoche.de/a/so-pla nen-sie-ihr-erp-system,1936026: So planen Sie Ihr ERP-System: Empfehlenswert „ist es, […] im ersten Schritt die kritischen Geschäftsprozesse zu identifizieren. […] Nur wer die Arbeitsabläufe in allen Unternehmensbereichen genau kennt, vermag am Ende zu beurteilen, welches ERP-System sie am besten abbildet. […] Erfahrene Sourcing-Berater können dabei hilfreiche Tipps geben, um in der Vielzahl der Angebote die am besten geeignete Software zu finden. Sie verfügen nicht nur über einen aktuellen ERP-Marktüberblick, sondern wissen in der Regel auch, wie Ausschreibungen formuliert werden müssen, damit Unternehmen bei der Implementierung und im Application-Support die richtige Unterstützung von einem technisch versierten Realisationspartner erhalten. 3 S. vor allem Kap. D Rz. 4 ff. Zahrnt, Aufklärungspflichten und Beratungsverhältnisse vor Computer-Beschaffungen, NJW 2000, 3746; Zahrnt, Die Rechtsprechung zu Aufklärungs- und Beratungspflichten vor Computerbeschaffungen, NJW 1995, 1785. Die Reichweite einer Aufklärungspflicht und das Vorliegen einer Pflichtverletzung ist eine Frage des Einzelfalls und bestimmt sich entschei-

608

Witzel

Implementierung von Standardsoftware

Rz. 7 G

hat, haftet auf Schadensersatz gemäß §§ 280 Abs. 1, 311 Abs. 2 Nr. 1, 241 Abs. 2 BGB1. Schwierig sind die Fälle zu beurteilen, in denen der Anwender aufgrund einer 5 derartigen Aufklärungspflichtverletzung des Anbieters einen inhaltlich nachteiligen Vertrag abgeschlossen hat. Was passiert also, wenn ein Softwareanbieter dem Anwender zusagt, er könne mit seiner angepassten Standardlösung in jedem Fall die Funktionalität des beim Anwender implementierten Altsystems abbilden und sich im Verlauf des Projekts entweder erhebliche Qualitätsmängel oder erhebliche Mehrkosten durch die Entwicklung zusätzlicher Funktionalität herausstellen. Es bleibt die Entwicklung der Rechtsprechung abzuwarten, ob der Kunde dann unter den Voraussetzungen des § 123 BGB (also bei Täuschung durch den Anbieter) den Vertrag anfechten kann. Voraussetzung für eine Anfechtung nach § 123 BGB wäre die Arglist des Softwareanbieters, die bei übertriebenen Äußerungen ohne fundierte Analysen durchaus nahe liegt. Dem entgegenhalten lässt sich, dass nicht nur in der juristischen Literatur Warnungen vor oberflächlichen und schlagwortartigen Zusagen des Vertriebs zu finden sind und Anwender ausreichende Informationsmöglichkeiten haben. Das Vorliegen der Voraussetzungen des § 123 BGB wird sich nur im Einzelfall feststellen lassen, die Hürden sind hoch. Möglicherweise kann der Anwender daneben Rückgängigmachung des Vertrages verlangen (§§ 280, 311 Abs. 2, 241 Abs. 2 BGB)2. Auch sind bei Standardsoftware in Ausnahmefällen Verträge denkbar, in de- 6 nen die Vertragspartner bestimmte Änderungen und Ergänzungen vereinbart haben, die technisch nicht oder nur unter erheblichem wirtschaftlichem Aufwand durchführbar sind, so z.B.: „Die vom Auftragnehmer zu erstellenden Zusatzentwicklungen sind stets uneingeschränkt aufwärtskompatibel mit zukünftigen Versionen und Releases der Standardsoftware des (…)-Systems und nutzen vorhandene Schnittstellen vollständig und ordnungsgemäß.“

Aufgrund der Schuldrechtsreform ist das Institut der anfänglich objektiven 7 Unmöglichkeit (§§ 307, 309 BGB a.F.) gestrichen worden. Haben die Vertragspartner ein bestimmtes Projektergebnis vereinbart, das nach gegenwärtigem Stand der Technik von keinem Softwareanbieter oder nur unter völlig unverhältnismäßigen Anstrengungen erzielt werden kann, so ist nunmehr nach § 311a Abs. 1 BGB n.F. der geschlossene Vertrag wirksam. dend nach dem konkreten Informationsmöglichkeiten und dem Informationsbedarf. Nach Auffassung des LG Köln (v. 26.2.2008 – 5 O 106/07) „müssen sich die Parteien allerdings nicht gegenseitig das Vertragsrisiko abnehmen, denn es ist zunächst Sache jeder Partei, sich selbst über die Marktverhältnisse und die daraus resultierenden Risiken und Chancen zu informieren.“ 1 OLG Stuttgart v. 14.12.2011 – 9 U 11/11, WM 2012, 890; OLG Karlsruhe v. 2.8.2011 – 12 U 173/10, VuR 2011, 397 (LS); LG Münster v. 18.1.2011 – 6 S 93/10, K&R 2011, 359. 2 BGH v. 6.6.1984 – VIII ZR 83/83, CR 1986, 79 = MDR 1985, 316 = NJW 1984, 2938; OLG Dresden, NJW-RR 1998, 1352.

Witzel

609

G Rz. 8 8

Sonderregelungen

Konnte der Anwender diesen Umstand nicht erkennen – etwa weil er vom Anbieter nicht ausreichend aufgeklärt worden ist –, so kann er gemäß § 311a Abs. 2 BGB wählen zwischen – Ersatz der Aufwendungen, die der Auftraggeber billigerweise gemacht hat und die nunmehr vergeblich sind (§ 284 BGB) oder – Schadensersatz statt der Leistung in Höhe seines Interesses an der Erfüllung des Vertrags (positives Interesse).

9

Eine Bagatellgrenze sowie die Rückgewährpflicht und der Umfang des Ersatzanspruchs bei bereits erbrachten Teilleistungen des Anbieters ergeben sich aus § 281 Abs. 1 Satz 2 und 3, Abs. 5 BGB. 3. Verletzung von Geheimhaltungspflichten

10 Die Einführung einer Standardsoftware, die den Geschäftsablauf eines Unternehmens erheblich effektivieren soll, verlangt in aller Regel kombiniertes Auftraggeber-Auftragnehmer-Know-how. Ohne tiefere Einblicke in die Unternehmensorganisation des Anwenders wird der Softwareanbieter dem Anwender kein maßgeschneidertes Programm liefern können. Andererseits findet gerade bei größeren Projekten ein Auswahlverfahren unter verschiedenen Anbietern statt, die dabei ihrerseits ihr Know-how vor Mitbewerbern schützen wollen. Bereits die Aufnahme von Vertragsverhandlungen kann also den Zutritt zur betrieblichen „Intimsphäre“ erfordern. Daher können, gerade wenn ein Vertragsschluss nicht oder erst zu einem späteren Zeitpunkt zustande kommt, der Schutz von Betriebsgeheimnissen und Kundendaten und andere Geheimhaltungspflichten relevant sein1. 11 Über §§ 311 Abs. 2, 241 Abs. 2 BGB bestehen derartige Schutzpflichten, auch ohne ausdrückliche Vereinbarung, bereits im Verhandlungsstadium bzw. im Stadium der Vertragsanbahnung. Hat eine Partei entsprechende Pflichtverletzungen zu vertreten, stehen dem Geschädigten Schadensersatzansprüche zu. 12 Gerade im Bereich der Geheimhaltung kommt einer umfassenden Aufklärung und Warnung des Geschäftspartners besondere Bedeutung zu. Denn dem Vertragspartner, dessen Geschäftsgeheimnisse verraten sind, ist mit einem Schadensersatz in Geld in der Regel wenig gedient. Hinzu kommt, dass sich Kausalität und ein konkreter Schaden in den meisten Fällen nicht nachweisen lassen. 13 Auch wenn also eine explizite Geheimhaltungsvereinbarung für den Schadensersatzanspruch nicht erforderlich wäre, sollte der Anwender eine solche schriftlich fixieren und sich unterschreiben lassen, bevor der Software-

1 Intveen, Geheimhaltungsvereinbarungen bei IT-Projekten, ITRB 2007, 239.

610

Witzel

Implementierung von Standardsoftware

Rz. 18 G

anbieter mit sensiblen Geschäftsbereichen in Berührung kommt1. Eine entsprechende AGB-Klausel zum erst noch abzuschließenden Projektvertrag käme zu spät. Möglich ist es jedoch, Geschäftsbedingungen zum vorvertraglichen Schuldverhältnis formularmäßig zu vereinbaren. Mittels solcher „AGB für das Verhandlungsstadium“ kann der Anwender den Softwareanbieter über entsprechende Risiken informieren und dies im Schadensfall nachweisen. Außerdem verkleinert der Anwender mit einer schriftlichen Schutzvereinbarung den Beurteilungsspielraum der Gerichte hinsichtlich des Umfangs der Schutzpflicht, des Kreises der geschützten Personen und des Vertretenmüssens des Pflichtverletzers.

14

4. Schutz und Haftung Dritter Gerade wenn ein neues Softwaresystem eingeführt oder angepasst wird, 15 kann der Softwareanbieter in Kontakt mit Kundendaten seines Geschäftspartners kommen. Der Schutz von Dritten, die von vornherein nicht selbst Parteien des intendierten Vertrags werden sollten, ist vor der Schuldrechtsmodernisierung über das Institut des Vertrags mit Schutzwirkung für Dritte gelöst worden. Inwieweit dieser Fall nun durch den neuen § 311 Abs. 3 Satz 1 BGB ge- 16 setzlich geregelt wird, ist strittig. Zwar besagt diese Vorschrift, dass „ein Schuldverhältnis mit Pflichten nach § 241 Abs. 2 BGB auch zu Personen entstehen (kann), die nicht selbst Vertragspartei werden sollen.“ Allerdings schweigt das Gesetz darüber, unter welchen Voraussetzungen Dritte diesen Schutz genießen können. Da ausweislich der Gesetzesbegründung2 in diesem Bereich durch die 17 Schuldrechtsreform keine Änderung der bisherigen ungeschriebenen Rechtslage herbeigeführt werden sollte, werden wohl weiterhin die Voraussetzungen des Vertrags mit Schutzwirkung für Dritte vorliegen müssen. Es bleibt die Entwicklung der Rechtsprechung abzuwarten, ob es dennoch zu einer Ausweitung des Schutzes von Dritten kommen wird. Umgekehrt können sich Schadensersatzansprüche auf Grund einer Verletzung der oben erwähnten Pflichten im Verhandlungsstadium gem. § 311 Abs. 3 BGB auch gegen eine Person richten, die nicht selbst Vertragspartei werden soll, also gegen einen sog. „Dritten“. Gemäß § 311 Abs. 3 Satz 2 BGB und der bisherigen Entscheidungspraxis der Gerichte ist dafür erforderlich, dass der Dritte Vertrauen für sich in Anspruch genommen und damit das Ergebnis der Verhandlungen erheblich beeinflusst hat.

1 Hörl, Persönliche Geheimhaltungsverpflichtungen der Projektmitarbeiter, ITRB 2007, 47; Söbbing, Der Letter of Intent (LOI) – Risikoabsicherung im Vorfeld des IT-Hauptvertrages, ITRB 2005, 240. 2 S. BT-Drucks. 14/6040, S. 163.

Witzel

611

18

G Rz. 19

Sonderregelungen

19 Der Dritte darf also nicht lediglich Verhandlungsgehilfe gewesen sein, sondern muss eine eigenständige Funktion erfüllt haben. Wenn sich der Dritte für eine Partei quasi „verbürgt“, ist unerheblich, ob er tatsächlich Vertreter dieser Partei ist, oder gar nicht an den Verhandlungen teilgenommen hat. 20 Bei der sog. Sachverständigen- und Sachwalterhaftung, also der Haftung wegen Expertenwissens, haben sich durch die Schuldrechtsreform möglicherweise die Anspruchsgrundlagen geändert (nunmehr §§ 241 Abs. 2, 311 Abs. 3, 280 Abs. 1 BGB statt Vertrag mit Schutzwirkung für Dritte oder cic). An den Voraussetzungen dieser Haftung, wie sie der BGH entwickelt hat, dürfte sich wohl wenig ändern1. 21 Ob daneben noch eine Haftung wegen besonderen wirtschaftlichen Eigeninteresses möglich ist, bleibt abzuwarten. § 311 Abs. 3 BGB zählt das besondere Vertrauen nur als Beispiel einer Dritthaftung auf. Würde die bisherige Rechtsprechung fortgeführt, käme eine derartige Haftung des Dritten in Betracht, wenn dieser zwar kein eigenes Vertrauen in Anspruch nimmt, aber wirtschaftlich gesehen gleichsam in eigener Sache tätig wird. Dafür genügt ein bloß mittelbares wirtschaftliches Interesse, z.B. eines Angestellten der Vertragspartei, nicht. 5. Abbruch von Vertragsverhandlungen 22 Der Abbruch von Vertragsverhandlungen2 ist auch im neuen Schuldrecht nicht ausdrücklich geregelt. Allerdings wird man in Fortsetzung der bisherigen Rechtsprechung davon ausgehen müssen, dass zu den von §§ 311 Abs. 2 Nr. 1, 241 Abs. 2 BGB im Stadium der Vertragsverhandlung erfassten Pflichten auch das Gebot gehört, nicht unberechtigt das Vertrauen des Verhandlungspartners auf einen Vertragsabschluss hervorzurufen oder aufrecht zu erhalten. Strittig ist jedoch, ob ein entsprechender Schadensersatz nur bei Vorsatz oder auch bei Fahrlässigkeit des anderen Teils zu zahlen ist. Ein verschuldensunabhängiger Schadensersatzanspruch ist denkbar, wenn der Ersatzpflichtige gleichsam eine Garantie für den Vertragsschluss übernommen hat. Für Verzögerungen bei der Vertragsannahme oder -ablehnung wird dagegen nur in engen Grenzen gehaftet3. 6. Letter of Intent/Memorandum of Understanding 23 Um die Verhandlungspartner vor Vertragsschluss stärker aneinander zu binden und wegen der Flut von Verhandlungspunkten, die ein Projekt mit sich bringt, wird häufig eine Absichtserklärung bezüglich der künftigen Zusammenarbeit, ein sog. Letter of Intent (LOI) oder Memorandum of Understan-

1 Zu c.i.c. s. BGH v. 6.6.1984 – VIII ZR 83/83, CR 1986, 79; BGH v. 15.5.1990 – X ZR 128/88, CR 1991, 86. 2 S. Kap. D Rz. 21. 3 S. BT-Drucks. 14/6040, S. 162 f.

612

Witzel

Implementierung von Standardsoftware

Rz. 25 G

ding (MOU)1, verfasst. Sind noch mehrere Standardsoftwareanbieter im Auswahlverfahren, hoffen diese mit einer solchen „Vorvereinbarung“ auch ein schriftlich manifestiertes Druckmittel für eine spätere endgültige Entscheidung in der Hand zu haben. Sinn und Zweck ist es, die ausgehandelten Vertragspunkte schriftlich niederzulegen, um sich später auf dieses Verhandlungsergebnis berufen zu können, ohne sich bereits vertraglich binden zu müssen. Im amerikanischen Recht ist ein Letter of Intent nur das, was die deutsche Übersetzung besagt, nämlich eine Absichtserklärung. Eine Absichtserklärung ist gerade kein Vertrag. Der Inhalt vieler LOI zeigt, dass die Vertragspartner gerade entgegen der Überschrift eine vertragliche Bindung wollen. Denn häufig gibt es beispielsweise Geheimhaltungsregelungen und andere Vereinbarungen, die die Verhandlungen strukturieren sollen. Das BGB kennt den LOI/MOU nicht. Es gibt traditionell einen Vorvertrag, 24 der zum Abschluss eines Hauptvertrags nach vorangegangenen Verhandlungen verpflichtet2. Für ein solches Konstrukt müssen allerdings die wesentlichen Eckpunkte bereits geklärt sein, was in vielen Fällen schon tatsächlich ein Problem ist. Stünde nämlich der wesentliche Inhalt des Hauptvertrags bereits fest, würde sich der Abschluss eines Vorvertrags erübrigen. Zudem wollen sich die potentiellen Vertragspartner meist eine Ausstiegsmöglichkeit offen halten, sollten sich während der Verhandlungen unwägbare Risiken herausstellen. Es bleibt also beim Gedanken der bloßen Absichtserklärung, ohne dass deren 25 Tragweite klar ist. Die Bezeichnung einer Erklärung als LOI oder MOU schadet mehr als sie nützt, denn es bleibt völlig offen, inwieweit durch die Erklärung eine schuldrechtliche Bindung eintritt oder nicht3. Gerade dann, wenn der LOI detaillierte rechtliche Regelungen enthält, besteht die Möglichkeit, dass ein Gericht eine vertragliche oder vertragsähnliche Bindungswirkung annimmt, auch wenn dies von den Verhandlungspartnern nicht gewollt war. Wollen diese ein solches Konstrukt, empfiehlt es sich, bei den einzelnen Formulierungen danach zu differenzieren, welche den Charakter einer reinen Absicht hat und welche den jeweiligen Verhandlungspartner binden soll: – Die Zielsetzung, sich über den Umfang eines Projektvertrags und die jeweiligen Leistungspflichten zu verständigen, wird im Regelfall eine Absicht bleiben. – Regelungen zu Geheimhaltung und Vertraulichkeit müssen bindend sein, wenn die Betriebs- und Geschäftsgeheimnisse der Verhandlungspartner geschützt werden sollen. 1 S. auch Kap. D Rz. 34; Redeker, Vorvereinbarungen in IT-Projekten, ITRB 2007, 208. 2 S. Redeker, ITRB 2007, 208 m.w.N. 3 MüKo zum BGB, 6. Aufl. 2012, Vor § 145 Rz. 59: „Die tatsächliche Verwendung des Begriffs „letter of intent“ ist mithin vieldeutig, so dass der von den Beteiligten mit der Begriffsverwendung verfolgte Zweck durch Auslegung zu ermitteln ist.“

Witzel

613

G Rz. 26

Sonderregelungen

– Soweit Leistungen des Softwareanbieters bereits in der Vorphase des Projekts – etwa erste Leistungen zur Konzeptionierung – vergütungspflichtig sein sollen, müssen die diesbezüglichen Regelungen ausdrücklich als verbindliche Regelungen gestaltet sein. – Entstehen bereits durch die ersten Leistungen des Softwareanbieters schutzfähige Arbeitsergebnisse (Entwürfe von Konzepten und Spezifikationen), sollten die Vertragspartner regeln, welche Rechte daran eingeräumt werden. 26 Sinnvoll kann es auch sein, im Vorfeld eines Projektvertrages zu vereinbaren, welche Rechtsfolgen z.B. ein schuldhaftes Abweichen von Verhandlungsergebnissen, ein verschuldeter Verhandlungsabbruch oder die Verletzung von Schutzpflichten haben soll und ob die vorvertragliche Tätigkeit im Rahmen der Akquise des Auftragnehmers zu vergüten ist. Dies kann auch durch AGB, also vorformulierte Geschäftsbedingungen einer Partei, geschehen.

II. Typischer Vertragsgegenstand von Verträgen zur Anpassung, Einführung und Implementierung von Standardsoftware und rechtliche Gestaltungsmöglichkeiten 1. Gegenstand eines IT-Projekts über (Lieferung,) Anpassung, Einführung und Implementierung von Standardsoftware a) Vorbemerkung aa) Pflichtverletzung nach der Schuldrechtsreform und vertragliches Pflichtenprogramm 27 Bei der Gestaltung einer Vereinbarung, die die Anpassung, Einführung und Implementierung einer Standardsoftware beim Anwender regeln soll, stellt sich zunächst die Frage nach dem Gegenstand der Vereinbarung, nach dem zu erbringenden Leistungsumfang und damit nach dem eigentlichen Gegenstand des Projekts1. Nach der Schuldrechtsreform sind weitreichende Konsequenzen an eine Pflichtverletzung seitens der Vertragspartner geknüpft (§ 280 Abs. 1 BGB)2, so dass es bei der Gestaltung von Verträgen unumgäng-

1 Müller-Hengstenberg/Krcmar, Mitwirkungspflichten des Auftraggebers bei ITProjekten, CR 2002, 549; Müller-Hengstenberg, Vertragstypologie der Computersoftware-Verträge – Eine kritische Auswertung der höchstrichterlichen Rechtsprechung zum alten Schuldrecht für die Beurteilung nach neuem Schuldrecht, CR 2004, 161. 2 Lorenz, Schuldrechtsreform: 3 Jahre danach, NJW 2005, 1889 ff.; Altmeppen, Schadensersatz wegen Pflichtverletzung, anfänglicher Unmöglichkeit und Aufwendungsersatz im Entwurf des Schuldrechtsmodernisierungsgesetzes, DB 2001, 1821; Canaris, Das allgemeine Leistungsstörungsrecht im Schuldrechtsmodernisierungsgesetz, ZRP 2001, 499.

614

Witzel

Implementierung von Standardsoftware

Rz. 29 G

lich ist zu definieren, welche vertraglichen Pflichten überhaupt bestehen1, an die sich etwaige Sanktionen knüpfen. Pflichtverletzung im Sinne von § 280 Abs. 1 BGB ist jede objektive Abweichung eines Vertragspartners vom geschuldeten Pflichtenprogramm. Das Ausbleiben einer einmal geschuldeten Leistung stellt in jedem Fall eine Pflichtverletzung im Sinne von § 280 Abs. 1 BGB dar, die darin bestehen kann, dass der Schuldner eine geschuldete Leistung nicht, nicht rechtzeitig oder schlecht erbringt. bb) Auswirkungen für die Vertragsgestaltung Bei der Vertragsgestaltung ist sicherzustellen, dass das Pflichtenprogramm 28 beachtet wird2. Um eine objektive Abweichung eines Vertragspartners von seinem Pflichtenprogramm feststellen zu können, muss dieses erst einmal feststehen. Bei manchen Verträgen mag das Pflichtenprogramm nahezu selbsterklärend sein, ein komplexes IT-Projekt, das die Anpassung sowie die Einführung und Implementierung einer Standardsoftware zum Gegenstand hat, hat keinen selbstverständlichen Leistungskatalog, der „auf der Hand liegt“. Es entspricht auch nicht einem komplexen Projekt, von „Lieferung der Software mit einigen wenigen zusätzlichen Beratungsleistungen“ auszugehen. Aus Sicht des Anwenders mag es oberflächlich gesehen ausreichen, den Vertragsgegenstand von Anpassung, Einführung und Implementierung nur allgemein zu beschreiben, in etwa wie folgt: „Der Auftraggeber beabsichtigt, die Standardsoftware X an die Bedürfnisse seines Betriebes anzupassen. Der Auftragnehmer wird die in diesem Zusammenhang notwendige Anpassung vornehmen.“3

Derartig oberflächliche und zugleich umfassende Formulierungen führen 29 allerdings – unvermeidbar – dazu, dass sich die Vertragspartner über den Leistungsumfang, der geschuldet ist, und über die fachlichen Anforderungen an die Software schlimmstenfalls bis zum vorzeitigen Ende des Projekts auseinandersetzen. Viele Software-Einführungen, Umstellungen und Erweiterungen scheitern daran, dass die Anforderungen des Anwenders an die einzuführende Software nicht klar genug dargelegt wurden und der Leistungsumfang des Softwareanbieters weder hinsichtlich der von ihm zu realisierenden Funktionalität noch hinsichtlich der sonst zu erbringenden

1 Graf von Westphalen, DB 2001, 799. 2 So auch die Empfehlung bei Graf von Westphalen/Meier-Göring, Neues Schuldrecht, S. 1. 3 Nach Auffassung des OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246, 248, droht dem Softwareanbieter mit einer solch unbestimmten Verpflichtung die werkvertragliche Erfolgsverantwortung: „Verspricht ein Unternehmen, dass die in seinen einzelnen Produktscheinen angebotene Soft- und Hardware die gesamte für den Betrieb des Bestellers erforderliche Anwendersoftware enthalte, so schuldet er auf Grund des mit der Unterzeichnung der Produktscheine geschlossenen Vertrages eine Gesamtlösung und kann sich nicht darauf berufen, der Besteller habe zunächst als Basislösung lediglich die in den einzelnen Produktscheinen aufgeführte Hard- und Software bestellt …“.

Witzel

615

G Rz. 30

Sonderregelungen

Projektleistungen feststeht. Die Beschreibung des Pflichtenprogramms (Leistungsbeschreibung) besteht also aus zwei Komponenten: – Festlegung der Aktivitäten und Aufgaben, die der Softwareanbieter während des Projekts zu erbringen hat, ggf. mit Beschreibung der daraus resultierenden Arbeitsergebnisse, sowie – Darstellung des Standardfunktionsumfangs der einzuführenden Software und Beschreibung der zusätzlichen Anforderungen des Anwenders, die zu realisieren sind. Regelmäßig fehlt es an beiden Komponenten. 30 Bis zum Ende des Projekts herrschen daher unterschiedliche Vorstellungen beider Vertragspartner, die erst bei einer fehlgeschlagenen Abnahme zu Tage treten. Deshalb muss eine möglichst genaue Leistungsbeschreibung (die im Verlauf des Projekts zu detaillieren ist) Bestandteil eines Vertrags sein. Sie ist Voraussetzung für ein erfolgreiches Projekt. 31 Die Vertragspartner müssen sich Gedanken darüber machen, was eigentlich die Anpassung, Einführung und Implementierung von Standardsoftware an Leistungen umfasst, um den Rahmen des IT-Projekts und des dazugehörigen Vertrags abstecken zu können: – Was fällt eigentlich unter den Begriff Standardsoftware? – Was bedeutet Anpassung von Standardsoftware im technischen Sinne und welche rechtlichen Konsequenzen ergeben sich daraus für beide Vertragspartner? – Welche Leistungen (Aktivitäten) gehören zur Einführung und Implementierung von Standardsoftware? Welche Arbeitsergebnisse (gerne auch bezeichnet als „deliverables“ oder „artefacts“) entstehen im Laufe der Einführung? – Nach welcher Methode/nach welchem Vorgehensmodell führt man eine Einführung und Implementierung durch? – Welche Projektphasen oder Stufen sind notwendig? – Welche Aufgaben und Leistungen fallen in welcher Projektphase dem Anwender zu? 32 Während bei der Entwicklung von Individualsoftware der Vertragsgegenstand und die Leistungspflichten des Softwareanbieters hinsichtlich der Entwicklung relativ klar umrissen erscheinen1, ist keineswegs selbsterklärend, was unter „Anpassung“, „Customizing“, „Parametrisierung“, „Einführung“ und/oder „Implementierung“ zu verstehen ist. Da von Vertragsgegenstand und Leistungen des Softwareanbieters aber die Fragestellung der vertragsgemäßen Leistung, der Abnahme sowie der Sach- und Rechtsmängelhaftung abhängen, muss sich auch die Vertragsgestaltung mit diesen 1 Hierzu sei angemerkt, dass auch eine Individualsoftware eingeführt und implementiert werden muss, auch ein solches Projekt erfordert mehr als die reine Entwicklungsleistung, so auch in Kap. D.

616

Witzel

Implementierung von Standardsoftware

Rz. 34 G

Fragen auseinandersetzen. Auch für die vieldiskutierte Frage, ob nun § 651 BGB auf Verträge über die Anpassung von Standardsoftware Anwendung findet oder Anwendung finden kann, bleibt es unumgänglich zu bestimmen, welches Leistungsportfolio der Softwareanbieter im Rahmen von Anpassung, Einführung und Implementierung seines Standardprodukts überhaupt erbringen muss. Müller-Hengstenberg1 kommt zu dem Ergebnis, dass § 651 BGB2 kein aus- 33 gewogenes Bedingungswerk für die Implementierung von Computersoftwarelösungen darstellt. Dieser Auffassung ist nach der ersten Entscheidung des BGH zu § 651 BGB vom 23.7.20093 im Hinblick auf eine genaue Darstellung des Vertragsgegenstands einer Einführung und Implementierung im Ergebnis zu folgen4. Das Leistungsportfolio, das zur Einführung und Implementierung einer „angepassten“ Standardsoftware erforderlich ist, ist zu weitreichend, als dass die ausschließliche Anwendung kaufrechtlicher Bestimmungen zu einem sachgerechten Ergebnis käme. Aus dieser Einschätzung folgt nicht zwingend, dass allein eine werkvertragliche Gestaltung einem solchen Projekt gerecht werden würde. Ein Vertrag, der Leistungen zur Anpassung, Einführung und Implementierung von Standardsoftware regelt, besteht regelmäßig aus einer Vielfalt von Aufgaben, die unterschiedlichen Vertragstypen zugeordnet werden können. Es wird bis auf wenige Ausnahmefälle immer ein typengemischter Vertrag vorliegen und die Frage, die sich regelmäßig stellt, ist die nach dem Schwerpunkt. Der Schwerpunkt der vertraglichen Leistungen kann je nach Vorgehensmodell und Projektverantwortung dienstvertraglich oder werkvertraglich sein. cc) Orientierung an Projekten im Bereich Enterprise Ressource Planning Die Bandbreite der auf dem Markt angebotenen Standardsoftware ist groß, 34 die im Zuge der Anpassung, Einführung und Implementierung derselben notwendigen Leistungen ebenso. Einführungs- und Implementierungsprojekte können sich in mehreren Phasen über Jahre erstrecken. Die nachfolgenden Ausführungen orientieren sich an den Problemen der Vertragsgestaltung und Projektdurchführung im Bereich der betriebswirtschaftlichen Anwendungen, vor allem der Unternehmensplanungssoftware (Enterprise Resource Planning Software, ERP)5, deren Einführung auf Grund der Komplexität rechtzeitiger und qualifizierter Absicherung und Begleitung bedarf. 1 Müller-Hengstenberg, CR 2004, 161. 2 Zur vertragstypologischen Einordnung von Verträgen über Anpassung, Einführung und Implementierung von Standardsoftware s. Kap. B Rz. 1 ff. 3 BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 6. 4 Im Ergebnis wird nach der herrschenden Meinung Werkvertragsrecht zur Anwendung kommen. 5 Enterprise-Ressource-Planning (ERP) bezeichnet die unternehmerische Aufgabe, die in einem Unternehmen vorhandenen Ressourcen (z.B. Kapital, Betriebsmittel, Personal etc.) möglichst effizient für den betrieblichen Ablauf einzuplanen. Der ERP-Prozess wird in Unternehmen heute häufig durch mehr oder minder

Witzel

617

G Rz. 35

Sonderregelungen

Zur Illustration häufiger Problemkonstellationen vorab zwei Fallstudien1, aus denen sich typische rechtliche Risiken und Eskalationen in Anpassungs-, Einführungs- und Implementierungsprojekten ergeben. b) Fallstudien 35 Fallbeispiel 1: Projekt Das Unternehmen A aus dem Nahrungsmittelbereich beabsichtigte im Jahr 2005 ein neues System zur Auftragsabwicklung und Produktionssteuerung einzuführen. Bereits seit dem Jahr 2001 hat das Unternehmen eine Standardsoftware im Bereich Rechnungswesen des Unternehmens S im Einsatz; im Hinblick auf die positiven Erfahrungen mit S entscheidet sich A, die von S angebotenen Module zur Auftragsabwicklung und Produktionssteuerung zu erwerben und im Rahmen eines Projekts an seine individuellen Geschäftsprozesse anpassen zu lassen2. Angebot S bietet A die Überlassung und Pflege seiner Standardsoftware auf Basis der bei S aktuell gültigen AGB an. Daneben erhält A ein Angebot über die Durchführung einer Analyse und Studie der Geschäftsprozesse im Unternehmen A. Ziel der Analyse und Studie ist die Ermittlung der fachlichen Anforderungen von A an die Standardsoftware von S3. Die Ergebnisse der Analyse und Studie sollen in eine Leistungsbeschreibung fließen, die Grundlage für die Leistungen von S im Rahmen der Einführung der Auftragsabwicklung und Produktionssteuerung bilden soll. Daneben erhält A eine erste überschlägige Kalkulation für die Leistungen, die S im Rahmen der Einführung und Implementierung erbringen wird. Diese Leistungen umfassen insbesondere Projektmanagement, Parametrisierung und sog. Addon-Entwicklung4 sowie Schulung.

1 2

3 4

komplexe ERP-Systeme (www.sap.com; www.comarch.com; www.oracle.com; www.microsoft.com) unterstützt. ERP-Systeme sollten weitgehend alle Geschäftsprozesse abbilden. Typische Funktionsbereiche einer ERP-Software sind: Materialwirtschaft (Beschaffung, Lagerhaltung, Disposition, Bewertung), Fertigung, Finanz- und Rechnungswesen, Controlling, Personalwirtschaft, Forschung und Entwicklung, Verkauf und Marketing. Ähnliche Fallstudien und mögliche Lösungswege finden sich bei Streitz, IT-Projekte retten – Risiken beherrschen und Schieflagen beseitigen, 2004. Zum Vertragsgegenstand und den Leistungen eines Softwareanbieters im Rahmen von Anpassung und Implementierung einer Standardsoftware s. unten Rz. 39 ff. S. dazu Rz. 131 ff. Nach der Definition unter www.wikipedia.org ist ein Add-On (von engl. to add = hinzufügen) ein optionales Modul, welches bestehende Hard- oder Software ergänzt oder erweitert.

618

Witzel

Implementierung von Standardsoftware

Rz. 35 G

Vertrag A lehnt die Zusammenarbeit ausschließlich auf Basis der AGB von S ab und legt einen „Projektrahmenvertrag“ vor, der die Erarbeitung der Leistungsbeschreibung (Ermittlung der fachlichen Anforderungen von A) sowie die spätere Realisierung der Anforderungen in Teilprojekten vorsieht. Basis für Software-Überlassung und Pflege bilden Software und Softwarepflegeschein sowie die AGB von S. Als Termin für die erfolgreiche Einführung von Auftragsabwicklung und Produktionssteuerung sieht der Vertrag Anfang 2007 vor. Die Vertragspartner vereinbaren die erfolgreiche Durchführung eines Integrationstests als Voraussetzung für die erfolgreiche Einführung und Implementierung1. Eskalation 1 Die Vertragspartner führen über einen Zeitraum von sechs Monaten eine Analyse durch, S erstellt ein sog. Pflichtenheft. Bei A steigt während der Analysephase ein neuer Investor ein, der sich zunächst dazu entscheidet, das Projekt mit S nicht fortzuführen, sondern mit Ablieferung des Pflichtenhefts zu beenden. In der Folge streiten die Vertragspartner darum, ob A verpflichtet ist, die Vergütung für die Überlassung der Standardsoftware zu bezahlen oder ob nur ein Zahlungsanspruch hinsichtlich der für die Durchführung der Analyse und Erstellung der Leistungsbeschreibung anfallenden Vergütung besteht2. Die Vertragspartner einigen sich nach Einschaltung der Anwälte zunächst auf einen Vergleich. Nach Ablauf von einigen Monaten entscheidet sich A, das Projekt fortzusetzen. Die Vertragspartner beginnen mit der Realisierung auf Basis des erstellten Pflichtenhefts. Eskalation 2 Während der Realisierung stellen die Vertragspartner fest, dass das Pflichtenheft Lücken enthält. Die aus Sicht von A zwingend erforderliche Abwicklung der „Intercompany-Faktura“ war in der Standardfunktionalität der Auftragsabwicklung nicht enthalten, in dem von den Vertragspartnern erstellten Pflichtenheft fehlte die Funktionalität ebenfalls. A vertritt den Standpunkt, dass die Funktionalität „Intercompany-Faktura“ für ein Unternehmen vergleichbarer Struktur und Größe unumgänglich sei, das Fehlen der Funktion bereits einen Mangel der Standardsoftware begründe, S aber jedenfalls während der Analyse den Bedarf hätte erkennen können. Da S zugesagt habe, die für A erforderlichen Anpassungen an seiner Standardsoftware durchzuführen, sei die Umsetzung der Funktionalität mitgeschuldete Leistung, ohne dass der hierfür entstehende Mehraufwand vergütungspflichtig sei3.

1 S. Rz. 337 ff. 2 S. Rz. 306 ff. 3 Zu Beschreibung von funktionalen Anforderungen und Inhalt des Pflichtenhefts s. Rz. 180; zu Change Requests und Mehraufwand s. Rz. 260 ff.

Witzel

619

G Rz. 36

Sonderregelungen

Eskalation 3 S hat sich im Rahmen der Leistungsbeschreibung zur Entwicklung von Add-ons verpflichtet und A zugesagt, diese Add-ons „uneingeschränkt aufwärtskompatibel“ zu späteren Versionen der von S entwickelten Standardsoftware zu erstellen. Diese Zusicherung führt zu einer erheblichen Steigerung des Aufwands bei der Add-on-Entwicklung, den S vergütet haben möchte. Die Vertragspartner streiten darüber, was die zugesicherte „uneingeschränkte Aufwärtskompatibilität“ tatsächlich umfasst und welcher etwaige Mehraufwand dafür gerechtfertigt ist1. Eskalation 4 Ende 2008 sind die Leistungen zur Realisierung immer noch nicht abgeschlossen, der letzte von den Vertragspartnern gemeinsam festgelegte Termin zur Fertigstellung und „Bereitstellung zur Abnahme“ wurde von S um zwei Monate überschritten. A setzt S eine Frist von vier Wochen, mit dem im Vertrag festgelegten Integrationstest zu beginnen und anhand dessen nachzuweisen, dass die Auftragsabwicklung und Produktionssteuerung „abnahmefähig“ vorliegt. S erläutert A daraufhin, dass für eine Durchführung des Integrationstests erforderliche Echtdaten fehlen bzw. dass die S vorliegenden Echtdaten inkonsistent seien. S fordert A auf, die für die Durchführung der vereinbarten Integrationstests erforderlichen Echtdaten zur Verfügung zu stellen. A ist der Auffassung, dass S ausreichend Echtdaten vorliegen und es im Übrigen keine 100 % konsistenten Daten gebe2. Eskalation 5 Mit Hilfe eines Mediators können die Vertragspartner eine Einigung über den Umfang der für die Integrationstests erforderlichen Datenlieferungen erzielen. Im Zuge der Tests stellt sich dann heraus, dass wesentliche zugesagte Funktionalitäten bei Auftragsabwicklung und Produktionssteuerung nicht fehlerfrei vorhanden sind und im Übrigen die in der Leistungsbeschreibung festgelegten Performance-Kriterien nicht eingehalten werden3. 36 Fallbeispiel 2: Projekt Das Unternehmen U ist ein Online-Anbieter für Lebensmittel. Neben haltbaren Waren wird auch Frischware vertrieben, ein Markt der in Deutschland bislang noch nicht etabliert ist. Das Unternehmen benötigt eine neue ERP-Software, seine Wahl fällt auf den Softwareanbieter S, der eine webbasierte ERP-Lösung „Cleopatra“ auf Java-Technologie bietet. Die Lösung „Cleopatra“ verfügt über moderne Software-Architektur und Bedienerführung, ist aber funktional nicht so ausgereift wie Produkte, die auf älteren Technologien basieren. Das integrierte Rechnungswesenmodul ist erst zwei 1 Zu nicht-funktionalen Anforderungen s. Rz. 186. 2 Zu Tests und Datenlieferung s. Rz. 317. 3 S. Rz. 190.

620

Witzel

Implementierung von Standardsoftware

Rz. 36 G

Jahre auf dem Markt. S hat viele Referenzkunden im Bereich der Lebensmittelindustrie, aber keine Erfahrung im Onlinehandel. Die Vertragspartner einigen sich auf ein Pflichtenheft, in dem einige Funktionen als sog. „MussFunktionen“ und andere als „Soll-Funktionen“ gekennzeichnet sind. Ob in der Einführung nur die „Muss-Funktionen“ umgesetzt werden sollen, wird aus den Formulierungen nicht klar. Vertrag Mit seinem Angebot legt S seine AGB für Softwarekauf und -pflege sowie für Beratungs- und Anpassungsleistungen vor. U schlägt eine Zusatzvereinbarung vor, die auf das Angebot keinen Bezug nimmt, aber teilweise die Regelungen in den AGB abändert. Das Angebot enthält einen Preis in Höhe von 100 000 Euro für die Überlassung der Standardsoftware und die Projektleistungen, zu dem S erläutert, dass der Aufwand an Projektleistungen in Höhe von 60 Personentagen für Anpassung, Schulung und Projektmanagement auf Basis vergleichbarer Projekte geschätzt seien. Im ebenfalls im Angebot enthaltenen Zahlungsplan wird der Betrag jedoch als „Maximalsumme“ bezeichnet. U versteht den Betrag als Festpreis, bei S geht man davon aus, dass die Projektleistungen nach tatsächlichem Aufwand abgerechnet würden. Weder das Angebot noch die Zusatzvereinbarung treffen eine Regelung über einen Go-Life-Termin. In einer E-Mail aus dem Juni 2002, mit der die unterzeichnete Zusatzvereinbarung und die unterzeichneten AGB übersandt werden, teilt der zuständige Vertriebsmitarbeiter mit, dass man sich bemühen werde, den „Wunschtermin“ 1.10.2002 für die Einführung zu halten1. Projektverlauf bis zum Go-Life Im August 2002 steht fest, dass ein Go-Life zum 1.10. nicht möglich ist. Auf Ebene der Projektleitung wird offensichtlich der 1.11. diskutiert, eine schriftliche Vereinbarung dazu gibt es allerdings nicht. Es bleibt zwischen den Vertragspartnern offen, ob eine verbindliche Absprache erfolgt ist oder nicht. Im Februar 2003 wendet sich der Geschäftsführer von U an die Geschäftsleitung von S und erläutert, dass S nach seiner Auffassung bereits seit 1.10.2002 in Verzug sei und U durch diese Verzögerung bereits erhebliche Kosten (vor allem durch die Weiterbeschäftigung von Personal, das durch die Einführung der neuen Software abgebaut werden sollte, sowie durch fortlaufende Lizenzgebühren, die für das Altsystem anfallen)2 entstanden seien. S legt ausführlich dar, dass aus seiner Sicht keine verbindliche Terminvereinbarung getroffen worden sei. Im März einigen sich die Vertragspartner auf einen Go-Life zum 1.6.2003. U stellt einen externen Projektleiter ein, der die Projektleitung von S unterstützen soll. Im Mai 2003 verschieben die Vertragspartner den Go-Life erneut. U behauptet, die Verschiebung sei notwendig gewesen, da S die Anpassungen so spät aus1 Zur Verbindlichkeit von Terminen s. Rz. 201. 2 Zu Verzögerungsschäden s. Rz. 203.

Witzel

621

G Rz. 36

Sonderregelungen

geliefert habe, dass keine ausreichenden Tests möglich gewesen seien. S behauptet, U habe auf Grund der Arbeitsüberlastung seiner Mitarbeiter keine Zeit gefunden, die zwischen den Projektleitern vereinbarten Tests durchzuführen. Am 1.7.2003 findet schließlich der Go-Life statt. Projektverlauf nach dem Go-Life Bereits zwei Wochen nach dem Go-Life erhält S die erste Fristsetzung zur Bereitstellung eines funktionsfähigen Systems, laut U seien wesentliche Funktionen des Pflichtenhefts, insbesondere auch „Soll-Funktionen“ nicht umgesetzt. Die gesamte Software sei erheblich fehlerbehaftet und nicht geeignet, die Geschäftsprozesse von U abzubilden. Es sei keine durchgängige Funktion für das Reklamationsmanagement vorhanden, zurück gesandte Ware habe nur mit manuellem Zusatzaufwand verbucht werden können, durch den Zeitverlust verderbe zu viel Ware oder sie komme auf Grund des Mindesthaltbarkeitsdatums für den weiteren Versand nicht mehr in Betracht. Des Weiteren berechne die Software die bei der Versendung von Frischwaren erforderlichen Zuschläge nicht, wodurch U ein nicht unerheblicher Schaden entstehe. Die Projektleitung von S stellt die Situation als nicht so dramatisch dar. Es finden mehrere Gespräche auf Geschäftsleitungsebene statt. Die Vertragspartner versuchen, die gemeldeten Mängel/Störungen nach Dringlichkeit und Schwere zu priorisieren. S verpflichtet sich, innerhalb vereinbarter Termine Korrekturen zu liefern1. Es werden auch tatsächlich Korrekturen geliefert und eingespielt. U behauptet allerdings, dass die Korrekturen die bestehenden Mängel nicht beseitigen, sondern allenfalls zur Entstehung neuer Mängel führen würden. Die Projektleitung von S vertritt die Auffassung, dass Änderungen der Geschäftsprozesse und mangelndes Know-how der Mitarbeiter in der Bedienung von „Cleopatra“ wesentlich für die Störungen mitursächlich seien. Auf Geschäftsleitungsebene wird vereinbart, dass ein Lenkungsausschuss etabliert wird, in dem das weitere Vorgehen verbindlich festgelegt wird. Die Protokolle des Lenkungsausschusses werden zwischen den Parteien ausgetauscht, allerdings nie unterzeichnet oder final abgestimmt. Ungeachtet der Diskussionen im Lenkungsausschuss setzt U wiederholt Fristen zur Lieferung einer abnahmefähigen Leistung, die S mit dem Argument abwehrt, durch die produktive Nutzung sei stillschweigend abgenommen2 worden. Eskalation und Scheitern Aus Sicht von U scheint keine Verbesserung einzutreten, immer wieder gelieferte Korrekturen führen nicht zu dem aus seiner Sicht notwendigen Erfolg. Im November 2003 beginnt U mit der Suche nach einem Ersatzsystems3. S bemerkt davon nichts. Im Januar 2004 trifft U die Entscheidung für 1 S. zu Fristsetzungen und Rücktrittsvoraussetzungen Rz. 201. 2 Zur stillschweigenden Abnahme s. Rz. 338. 3 Zu den ersatzfähigen Mehrkosten eines Ersatzsystems s. Rz. 363.

622

Witzel

Implementierung von Standardsoftware

Rz. 39 G

einen neuen Anbieter, ohne in unmittelbarem zeitlichen Zusammenhang nochmals eine Frist an S gesetzt zu haben. Im März scheitert ein Mediationsversuch und S entscheidet sich zur außerordentlichen Kündigung, da aus seiner Sicht keinerlei konstruktive Kommunikation mehr möglich ist1. c) Standardsoftware aa) Terminologie Zunächst zu der Frage, was „Standardsoftware“2 überhaupt ist. Die Band- 37 breite ist weit, angefangen von im Internet und den Computerabteilungen der Kaufhäuser3 vertriebenen Produkten zur Textverarbeitung und Tabellenkalkulation über Datenbanksoftware bis zu unterschiedlichsten Anwendungen im Bereich des Enterprise Resource Planning (ERP) wie beispielsweise Rechnungswesen, Materialwirtschaft und Produktionssteuerungsplanung. Die Gemeinsamkeit: Bei Standardsoftware handelt es sich in der Regel um 38 Produkte für breite Anwenderkreise (teilweise auch branchenunabhängig), die allerdings jedenfalls bei komplexeren Anwendungen an die individuellen Bedürfnisse, d.h. an die organisatorischen und technischen Bedingungen des Anwenders, angepasst werden müssen. Die Software ist zu „customizen“4. Standardsoftware kann nach ihren Aufgabenstellungen grob etwa wie folgt klassifiziert werden: – Technische Systeme, die zur Unterstützung technischer Aufgaben innerhalb eines Unternehmens dienen, z.B. CAD-Systeme (Computer Aided Design) oder CAP-Systeme (Computer Aided Planning)5.

1 Zur außerordentlichen Kündigung wegen Verlust des Vertrauens s. Rz. 426. 2 Unter www.wikipedia.org findet sich folgende Erläuterung: „Das Gegenteil von Standardsoftware ist Individualsoftware. Abhängig vom Anwendungsbereich gehören zu Standardsoftware Branchensoftware, funktionsübergreifende Software wie Bürokommunikation, Workflow-Management, Dokumentenmanagement und funktionsbezogene Software wie ERP-Systeme, CAD, Vertriebssoftware, Lagerverwaltung, Rechnungswesen, Personalabrechnungssoftware, Personalwirtschafts- und Personalinformationssysteme. 3 Die Ausführungen dieses Kapitels konzentrieren sich auf die vertraglichen Anforderungen, die sich beim Erwerb von komplexer Standardsoftware ergeben und nicht auf den Kauf von Softwareprodukten „beim Händler an der Ecke“. 4 Zu den Möglichkeiten der Anpassung von Standardsoftware sowie zur Terminologie s. Kap. D Rz. 95 ff. 5 Beispiele für CAD-Systeme: CATIA der Dassault Systemes für Flugzeug- und Automobilbau, Maschinenbau, Werkzeugbau und Schiffbau; Pro/Engineer der Parametric Technology Corporation für Maschinenbau, Anlagenbau, Automobilbau oder Solid Edge der Siemens PLM Software, eine 3D-Modellier-Software für Maschinenbau, Apparatebau, Anlagenbau, Werkzeug und Formenbau.

Witzel

623

39

G Rz. 40

Sonderregelungen

– Betriebswirtschaftliche Systeme, die zur Unterstützung betriebswirtschaftlicher Geschäftsprozesse (Logistik, Rechnungs- und Personalwesen) innerhalb eines Unternehmens dienen. – Gemischte Systeme, etwa CIM-Systeme (Computer Integrated Manufacturing). Betriebswirtschaftliche Systeme können des Weiteren in Branchen-, Funktions-, und Spezialsoftware unterschieden werden. Typische Branchen-Anwendungen wären etwa sog. Bestandsführungssysteme für die Versicherungswirtschaft oder Kernbanksysteme für die softwaretechnische Abwicklung der Geschäftsprozesse einer Bank (etwa Kontoführung und Zahlungsverkehr, Geld- und Devisenhandel, Wertpapierabwicklung). 40 Laut Balzert prognostizieren Trenduntersuchungen, dass der Anteil von Individualsoftware bis auf 5 % sinken wird und dass sich solche Individualsoftware nur noch große Firmen leisten können. Aus diesem Trend ergäbe sich, dass der Anteil vollständig neu geschriebener Software abnimmt, Anpassungen aber immer wichtiger werden1. bb) Technische Möglichkeiten zur Anpassung 41 Komplexe Standardsoftware kann erst dann produktiv genutzt werden, wenn die Aufbau- und Ablauforganisation eines Unternehmens abgebildet ist. Die Anpassung (das „Customizing“)2 erfolgt entweder über vorhandene Parametrisierungsmechanismen3, die für diesen Zweck in der Anwendungssoftware vorgesehen sind, oder über explizite Ergänzungs-/Anpassungsprogrammierung (beispielsweise „Add-ons“), die durch den Softwareanbieter vorgenommen werden soll. Diese Programmierung besitzt den Charakter von Individualsoftwareentwicklung. 42 Der Softwareanbieter kann eigene Standardsoftware oder die Standardsoftware eines anderen Anbieters liefern und an die individuellen Wünsche des Kunden anpassen, in dem er die Standardsoftware (durch Eingriff in den Quellcode) abändert oder ggf. Ergänzungsprogrammierungen vornimmt. Es ist denkbar, dass der Anbieter eigene oder zugekaufte Standardsoftware liefert, für die er zusätzliche Leistungen wie Customizing, Implementierung,

1 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 14. Vgl. auch Quack, Computerwoche v. 28.3.2012, http://www.computerwoche.de/a/eigenentwicklungen-werden-immer-unattraktiver, 1234634: Eigenentwicklungen werden immer unattraktiver: „Insgesamt griffen aber fast alle Unternehmen vermehrt auf Standardsoftware zurück. Nur in jedem vierten der […] Betriebe beständen mehr als 20 Prozent der Softwarelandschaft aus Eigenentwicklungen.“ 2 S. auch Hesseler/Görtz, Basiswissen ERP-Systeme, 2008, S. 224 ff. 3 Parametrisierung: Veränderungen von Variablen in der Grundeinstellung der Software, mit denen den jeweiligen Branchen- und Unternehmensspezifika des Kunden Rechnung getragen wird.

624

Witzel

Implementierung von Standardsoftware

Rz. 44 G

Installation, Parametrisierung1 erbringt, die keinen Eingriff in den Quellcode der Software erfordern. Welche Leistungen im konkreten Fall tatsächlich zu erbringen sind, muss sich notwendigerweise aus dem Vertrag ergeben, vor allem, da die Begrifflichkeiten keineswegs eindeutig besetzt sind.

43

cc) Open-Source-Komponenten Die häufig exorbitanten Kosten bei IT-Projekten besagen noch lange nicht, 44 dass die Softwareanbieter allein mit dem Vertrieb ihrer Standardsoftware tatsächlich Gewinn erwirtschaften. Die Entwicklungskosten sind erheblich und die Gewinnmargen in vielen hart umkämpften Märkten gering. Um Kosten zu sparen, werden Entwicklungsleistungen häufig ins Ausland verlagert, um durch geringere Lohnnebenkosten die Rentabilität der Entwicklung eines Standardprodukts zu steigern. Darüber hinaus greifen die Softwareanbieter immer mehr auf Drittprodukte, insbesondere auch auf Open-Source-Softwarekomponenten2, zurück. Mit dem kostenfrei zur Verfügung stehenden Quellcode können erhebliche Kosten eingespart werden, zudem sparen sich die Softwareanbieter Zeit für die Entwicklung, in dem sie auf vorhandene Komponenten zugreifen. Es gibt kaum noch eine Standardsoftware auf dem Markt, die nicht zumindest Open-Source-Bibliotheken, pdf-Viewer, Kompressionstools, die bei der Installation benötigt werden, oder standardisierte Graphiken und Icons enthält. Ob und inwieweit sich diese Komponenten rechtlich unproblematisch in proprietäre Standardsoftware integrieren lassen, hängt von den jeweils zur Anwendung kommenden Open-Source-Lizenzbedingungen ab3. Während Komponenten, die unter Lizenzbedingungen ohne den sog. Copyleft-Effekt stehen, bei der Integration in proprietäre Komponenten keine oder kaum Schwierigkeiten bereiten, können die sog. Copyleft-Lizenzen (GNU General Public License, GNU Lesser Public License und Mozilla License) dazu führen, dass eine unter einer solchen Lizenz stehende Komponente eine proprietäre Software

1 Zu den Definitionen der einzelnen Begriffe s. unten Rz. 139 ff. 2 Auer-Reinsdorff/Kast, in: Auer-Reinsdorff/Conrad, Beck’sches Mandatshandbuch IT-Recht 2011, § 7; Jaeger/Metzger, Open Source Software, Rechtliche Rahmenbedingungen der Freien Software, 3. Aufl. 2011; Nordmeyer, in: Lehmann/ Meents, Handbuch des Fachanwalts Informationstechnologierecht, 2011, Kap. 3.I; Sobola, Haftungs- und Gewährleistungsregelungen in Open Source Softwarelizenzbedingungen, ITRB 2011, 168. 3 Gerlach, Open Source: Kommerzielle Nutzung von LGPL Libraries, http://www. it-rechts-praxis.de/meldungen/Open-Source-Kommerzielle-Nutzung-von-LGPLLibraries-1; Hoppen/Thalhofer, Der Einbezug von Open Source Komponenten bei der Erstellung kommerzieller Software, CR 2010, 275; Thalhofer, Commercial Usability of Open Source Software Licenses, CRI 2008, 129 ff.

Witzel

625

G Rz. 45

Sonderregelungen

insgesamt „infiziert“ („viraler Effekt“)1 und den Softwareanbieter zu Offenlegung seines Quellcodes zwingt. Auf die Details dieser Problematik einzugehen, würde den Rahmen dieses Kapitels sprengen; da jedoch kaum eine Standardsoftware denkbar ist, die keinerlei Open-Source-Komponenten verwendet, kann das Thema in einem Kapitel zur Anpassung, Einführung und Implementierung von Standardsoftware nicht gänzlich unerwähnt bleiben. Das Thema ist auch nicht nur bei den vertraglichen Regelungen zur Rechtseinräumung oder im Bereich der Haftung relevant, sondern auch beim Leistungsumfang. Dem Anwender muss bekannt sein, welche Open-SourceKomponenten Bestandteil der von ihm erworbenen Standardsoftware sind. Nur so ist es ihm möglich, etwaige Risiken zu beurteilen, die sich aus den jeweils zur Anwendung kommenden Open-Source-Lizenzbedingungen ergeben. In einer Funktionsbeschreibung der Standardsoftware sollten die jeweiligen Komponenten, ihre Funktion und die anwendbaren Lizenzbedingungen aufgelistet sein. 45 Anwender, die sich bei Einführung unternehmenskritischer Systeme, – verständlicherweise – den etwaigen Gefahren eines viralen Effekts nicht aussetzen wollen, verpflichten ihre Softwareanbieter gerne zu entsprechenden Zusicherungen, die etwa folgendermaßen lauten können:

Sofern nicht ausdrücklich in der Leistungsbeschreibung hiervon abweichend vereinbart, sichert der Auftragnehmer zu, dass die von ihm gelieferten Softwareprodukte keine Open-Source-Softwarekomponenten enthalten, die unter Lizenzbedingungen stehen, die den Nutzer dieser Komponenten verpflichten, dass Änderungen oder Bearbeitungen dieser Komponenten und der Vertrieb solcher Bearbeitungen oder Änderungen unter den gleichen Lizenzbedingungen erfolgen muss. Soweit nach der Leistungsbeschreibung die Nutzung oder Verwendung solcher Komponenten zulässig ist, müssen die zur Anwendung kommenden Lizenzbedingungen in der Leistungsbeschreibung vollständig aufgeführt sein.

1 Zum viralen Effekt der GPL gibt es ein erstes deutsches Urteil des LG Berlin v. 8.11.2011 – 16 O 255/10, CR 2012, 152, in dem das Gericht den viralen Effekt der GPL nicht beanstandet: „Die Infizierung eines Sammelwerks insgesamt bei Verwendung von Open-Source-Software in einzelnen Teilen eines Sammelwerks begegnet keinen Bedenken, da das Sammelwerk eine einheitliche Funktionalität aufweist und maßgeblich von den Open-Source-Bestandteilen abhängt.“ Die grundsätzliche Bedeutung dieses Urteils ist sehr zweifelhaft, so auch Schäfer, Komm. zum Urt. des LG Berlin, Firmware mit OSS-Bestandteilen, K&R 2012, 124 ff. (127). Das Urteil unterstreicht allerdings die Tendenz aller bisherigen Urteile zu Open-Source-Lizenzbedingungen, in denen weder die Wirksamkeit dieser Vertragsbedingungen noch deren Durchsetzbarkeit ernsthaft angezweifelt wird.

626

Witzel

Implementierung von Standardsoftware

Rz. 48 G

d) Gegenstand der Anpassung, Einführung und Implementierung von Standardsoftware Damit eine Standardsoftware vom Anwender produktiv genutzt werden 46 kann, bedarf es regelmäßig mehr als der Einstellung bestimmter Parameter. Die Standardsoftware muss in die Organisation und in die vorhandene Systemarchitektur des Anwenders implementiert werden1. Geschäftsprozesse2 und Geschäftsziele des Anwenders einerseits und Organisation, IT-Anwendungen, Daten und Kommunikation andererseits sind voneinander abhängig: Die (erfolgreiche) Implementierung einer Standardsoftware ist abhängig von den Geschäftsprozessen des Anwenders. Diese Abhängigkeit ist einer der Gründe für Schieflagen und Konflikte. Selbst eine bei einer Vielzahl von Anwendern eingesetzte Standardsoftware kann sich für einen Anwender ob seiner individuellen, ggf. nicht branchentypischen Geschäftsprozesse als ungeeignet erweisen. aa) Anpassungsbedarf Die Idealsituation, dass die von einem Softwareanbieter angebotene Stan- 47 dardsoftware exakt den Anforderungen des Anwenders entspricht, dürfte über die typischen Anpreisungen des Vertriebs hinaus Theorie bleiben: Standardsoftware leistet meist zu viel oder zu wenig. Sie muss also an die individuellen Bedürfnisse des jeweiligen Anwenders angepasst werden. Hieraus ergibt sich eine der wesentlichen Herausforderungen für das Pro- 48 jekt: Der Anwender muss sich zunächst über seine Anforderung im Klaren sein, damit ein Abgleich mit dem Funktionsumfang des vorhandenen Standards überhaupt erfolgen kann. Der Anwender muss sich weiterhin dessen bewusst sein, dass sich die Anforderungen im Verlauf des Projekts ändern, erweitern, aber auch reduzieren können. Bringt der Softwareanbieter während des Projekts ein neues Release seines Standards heraus, kann auch beim Anwender der Wunsch nach neuen Anforderungen wachsen. Daraus folgt: Das Ziel, vielmehr die genauen Details eines Anpassungs-, Einführungs-, und Implementierungsprojekts lassen sich bei Vertragsschluss noch nicht definitiv festlegen, das Ziel muss vielmehr im Verlauf des Projekts präzisiert werden. Diese Dynamik muss auch bei der Vertragsgestaltung berücksichtigt werden: Der Vertrag braucht Regelungen zur Feinspezifizierung („Detaillierung“) der Leistungsbeschreibung und vor allem zum Change Management.

1 Krcmar, Informationsmanagement, www.wikipedia.org. 2 Geschäftsprozess nach www.wikipedia.org: Beispiele für einen Geschäftsprozess sind die Auftragsabwicklung, die Kreditvergabe einer Bank oder die Ausbildung von Studenten in einer Universität. Nach Balzert, Lehrbuch der Softwaretechnik, Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 593 ist ein Geschäftsprozess „eine Abfolge von Funktionen (auch als Aktivitäten bezeichnet) zur Erfüllung einer betrieblichen Aufgabe, wobei eine Leistung in Form von Informations- und/oder Materialtransformation erbracht wird.“

Witzel

627

G Rz. 49

Sonderregelungen

bb) Feststellung des Anpassungsbedarfs 49 Die für den Anwender entscheidende Frage ist die, welche Funktionalität der Standardsoftware in seinem Unternehmen tatsächlich gebraucht wird. Da Standardsoftware in der Regel nur die in einer bestimmten Branche üblichen Geschäftsprozesse abdeckt, von denen die konkreten Geschäftsprozesse eines Anwenders abweichen können, stellt sich die Frage nach den Anpassungsmöglichkeiten. Dies bedeutet auch, dass auf Seiten des Anwenders eine Feststellung seiner organisatorischen Prozesse erfolgen muss1. Da die Anpassungsfähigkeit durch Parametrisierung bei Standardprodukten nicht unendlich ist, müssen unter Umständen die Prozesse des Anwenders an die von der Standardsoftware vorgegebenen Abläufe angepasst werden. Selbstverständlich verbirgt sich hinter der Anpassung und dem Umfang der Anpassung auch ein finanzieller Aspekt: Der Auftraggeber will die Anpassung idealerweise mit wenig Geld und in kürzester Zeit realisieren. Dabei übersehen Anwender häufig, dass es langfristig kostengünstiger ist, in die Analyse von Anforderungen und in die Konzeption der konkret umzusetzenden Anforderungen zu investieren. Unzureichende Analyse und Konzeption führen zwangsläufig zu höheren Kosten bei der Einführung und im worst case zum Scheitern des Projekts insgesamt: Stolze 43 % der im Betrieb festgestellten Fehler in Steuerungs- und Regelungssoftware sind auf Unzulänglichkeiten in der Analysephase oder Systemspezifikation zurückzuführen. Sie wirken sich viel später aus und kosten eine Menge Geld, wenn man sie beheben will2. cc) Einführung und Implementierung (1) Aufgaben während der Einführung 50 Neben der funktionalen Anpassung der Standardsoftware an die Bedürfnisse des Anwenders durch Parametrisierung oder erweiternde Programmierung ist bei der Einführung von Standardsoftware eine Anpassung an die beim Anwender bestehende IT-Infrastruktur und eine Integration in andere bereits operative Anwendungen durchzuführen. Für die Integration müssen bestehende (ggf. schon standardisierte) Schnittstellen angepasst oder erweitert werden, teilweise sind auch neue Schnittstellen zu entwickeln. 51 Die Aufgaben im Zusammenhang mit der Einführung bestehen aus einer Vorbereitung des neuen Systems für den Echtbetrieb, der Installation, der Durchführung von Tests, der Einspeisung von Daten in die Anwendung (Migration) und der Einweisung und Schulung der Anwender. Dazu gehören

1 Dieser Prozess wird heute typischerweise als „Requirements Engineering“ bezeichnet, Balzert, Lehrbuch der Softwaretechnik, Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 434. 2 Computerzeitung v. 23.10.2006: UML-Modelle können Rahmen für Fahrzeugarchitektur bilden.

628

Witzel

Implementierung von Standardsoftware

Rz. 55 G

auch das Projektmanagement mit Projektcontrolling und Risikomanagement1. Sind Daten bereits in größerem Umfang in einer älteren Anwendung vorhanden, muss bereits vor Umstellung ein Konzept zur Datenübernahme entwickelt werden, so dass der operative Betrieb direkt nach der Implementierung beginnen kann.

52

Während der Einführung werden Anwender-Schulungen durchgeführt, in 53 denen wesentliche Handhabungsschritte und ggf. wichtige Unterschiede zur Vorgänger-Anwendung aufgezeigt werden, um die Umstellungsphase so kurz wie möglich zu halten. Ist die Einführung erfolgreich abgeschlossen, geht die Anwendung in den operativen Betrieb (Go Life, Cut-over) über. Dieser beginnt regelmäßig mit einer Stabilisierungsphase, innerhalb derer der Anwender noch Unterstützungsleistungen des Softwareanbieters erhält (häufig bezeichnet als „Post-Go-Live-Betreuung“). (2) Aufgaben während der Implementierung Der Schritt der organisatorischen Implementierung ist nicht eine rein tech- 54 nische Integration in die bestehende Systemlandschaft, sondern betrifft auch die soziale Komponente eines „Gesamtsystems“ (hier des Unternehmens), denn Implementierungsprozesse vollziehen sich nicht in leblosen und menschenleeren Organisationsstrukturen. Die bestehenden Organisationsstrukturen des Anwenders müssen ggf. geändert werden, damit die angepasste Standardsoftware auch möglichst optimiert eingesetzt werden kann. Von den unterschiedlichsten Implementierungsaktivitäten sind immer 55 Personen direkt oder indirekt betroffen, die sich nicht einfach – wie es die „Implementierung per Geschäftsleitungsbeschluss“ implizit unterstellt – umprogrammieren lassen. Das heißt, dass die betroffenen Mitarbeiter in das Projekt einbezogen werden müssen2. Häufig stehen für die Mitarbeiter erhebliche Veränderungen an. Regelmäßig werden Systeme auch eingeführt, um durch die Automatisierung von Geschäftsprozessen Personal abbauen zu können. Dies kann auch bedeuten, dass die Einstellung gegenüber der einzuführenden und zu implementierenden Software negativ sein kann. Eine der Aufgaben des Projektmanagements ist es daher auch, die Mitarbeiter des Anwenders frühzeitig ins Boot zu holen3.

1 S. dazu im Detail Kap. H, Projektmanagement. 2 Vgl. Quack, Computerwoche v. 2.1.2013, http://www.computerwoche.de/a/ zum-projekterfolg-in-sieben-kommunikationsschritten,1236503: Zum Projekterfolg in sieben Kommunikationsschritten: „Kommunikation war und ist der kritische Erfolgsfaktor für das Projekt – um zu informieren, zu motivieren sowie Konfliktsituationen (basierend auf Missverständnissen) frühzeitig aufzuspüren und im Anfangsstadium zu beseitigen.“ 3 Tiemeyer, Handbuch IT-Projektmanagement, 2010, S. 26.

Witzel

629

G Rz. 56

Sonderregelungen

e) Wirtschaftliche Auswirkungen der Einführung und Implementierung von Standardsoftware für den Anwender aa) Vorteile gegenüber der Individualentwicklung 56 Welche wirtschaftlichen Vorteile hat der Anwender durch Erwerb und Nutzung einer Standardsoftware im Verhältnis zu einer für ihn individuell entwickelten Lösung? Die Softwareanbieter werben u.a. mit folgenden Argumenten: – optimierte Abläufe und Funktionalität durch die Abbildung vieler Kundenanforderungen; – automatische Anpassung der Standardsoftware an die neuesten Funktionalitäten und gesetzlichen Anforderungen durch den Softwareanbieter1; – hohe Flexibilität durch tabellen- und parametergesteuerte Systeme, die kundenspezifische Anpassungen im Rahmen der Einführung, aber auch bei späteren Änderungen in den Geschäftsprozessen des Anwenders erleichtern sollen; – weitgehende Unabhängigkeit und Auswechselbarkeit der IT-Basistechnologie wie Hardware, Betriebssysteme und Datenbanken; – standardisierte Schnittstellen zu anderen Systemen; – geringere Total Cost of Ownership2. bb) Komplexität und Aufwand 57 Diese Schlagworte sollten allerdings nicht darüber hinwegtäuschen, dass die Einführung einer Standardsoftware nicht zwingend schneller, einfacher und kostengünstiger ist, als die Entwicklung und Einführung einer Individuallösung für den Anwender. Es geht in beiden Fällen um die Einführung einer Software, die die individuellen Bedürfnisse eines konkreten Auftraggebers abbildet. Während eine Individualentwicklung „bei null“ anfängt,

1 Über die Frage der Kosten in Zusammenhang mit diesen automatischen Anpassungen im Rahmen des Projekts bzw. der Pflege finden sich in der Pre-Sales-Phase häufig keine Hinweise. Für die juristische Beratung auf beiden Seiten ergibt sich die Notwendigkeit festzulegen, in welchem – auch finanziellen – Umfang notwendige Änderungen umgesetzt werden. 2 Definition nach www.wikipedia.org: Total Costof Ownership (TCO) ist ein Berechnungsverfahren, das in den 80er Jahren entwickelt wurde. Der Ansatz dient dazu, Verbrauchern und Unternehmen dabei zu helfen, alle anfallenden Kosten von Investitionsgütern (insbesondere in der IT), wie beispielsweise Software und Hardware, abzuschätzen. Die Idee dabei ist, eine Abrechnung zu erhalten, die nicht nur die Anschaffungskosten enthält, sondern alle Aspekte der späteren Nutzung (Energiekosten, Reparatur und Wartung) der betreffenden Komponenten. Somit können bekannte Kostentreiber oder auch versteckte Kosten möglicherweise bereits im Vorfeld einer Investitionsentscheidung identifiziert werden. Wichtigste Grundlage für das weitere Verständnis der TCO ist die Unterscheidung zwischen direkten und indirekten Kosten.

630

Witzel

Implementierung von Standardsoftware

Rz. 60 G

werden bei der Anpassung und Implementierung von Standardsoftware bereits beim Softwareanbieter vorhandene Standardkomponenten genutzt. Die technischen Voraussetzungen und der Aufwand für den Einsatz von 58 Standardsoftware in bestehenden Systemumgebungen werden oft unterschätzt. Der Einsatz von Standardsoftware entspricht im Wesentlichen der Einführung einer eigens erstellten Anwendung. Je nach Branche und Größe des Unternehmens kann die Komplexität größer sein als bei einer Individualentwicklung. Für die erforderlichen Testverfahren setzt die Fachliteratur im Bereich Informationstechnik einen Testaufwand von etwa 35 % bis 45 % des Gesamtaufwands für die Implementierung einer erstellten oder angepassten Software in die Systemumgebung des Anwenders an1. Vorgehensmodelle verdeutlichen, dass die Implementierung von „Softwarelösungen“ in einer Kundenumgebung kein Austausch fertiger Ware ist, sondern einen Prozess und eine Entwicklung darstellt, die eine weitgehende Mitwirkung des Kunden erfordern2. cc) Nachteile von Standardsoftware Der Einsatz von Standardsoftware bringt auch Probleme mit sich, denn Unternehmen sind nie gleich, weshalb sich auch weiterhin Unternehmen für eine „Maßanfertigung“ entscheiden bzw. entscheiden müssen. Die Nachteile von Standardsoftware sind dementsprechend die folgenden:

59

– unvollständige Abdeckung unternehmensspezifischer Anforderungen; – unvollständige Integration in die Gesamtheit bereits im Unternehmen implementierter Anwendungen, z.B. wegen Schnittstellenproblemen, und – durch Orientierung an allgemeine Verwendbarkeit eventuell schlechtes Betriebsverhalten in unternehmensspezifischen Situationen. dd) Konsequenzen für die Vertragsgestaltung Daher sind auch bei der Vertragsgestaltung die Herausforderungen nicht ge- 60 ringer. Insbesondere bedarf es eines effizienten Projektmanagements, damit nicht über unkontrollierte Anforderungen der Endanwender, die vom Softwareanbieter – im Idealfall in dessen Sinne – nach „Time and Material“ umgesetzt werden, am Ende doch wieder eine Individualentwicklung aus der Standardsoftware entsteht, die die oben zitierten Vorteile wieder verliert. Bei unternehmensspezifischen Modifikationen stellt die Übernahme neuer Versionen (Releasewechsel) einen erheblichen Aufwand dar. Wird Standardsoftware nicht nur parametrisiert, sondern auch erheblich ergänzt, ergeben sich Fragen der Schnittstellengestaltung zum Standard und des Pflegemanagements. Egal, wie die Anpassungen einer Standardsoftware technisch durchgeführt werden, sie dienen alle zur Erhöhung des Abdeckungsgrads 1 Siedersleben, Softwaretechnik. 2 Zur Mitwirkung des Kunden s. Rz. 215 ff.

Witzel

631

G Rz. 61

Sonderregelungen

der individuellen Anforderungen des Anwenders. Sie führen aber auch alle zu einer Erhöhung der Kosten für die erste Einführung und zu wiederkehrenden Kosten für jeden späteren Releasewechsel1. Hierdurch kann sich der ursprüngliche Kostenvorteil einer Standardlösung ins Gegenteil verkehren. Der Return-on-Investment einer Einführung kann sogar gänzlich verhindert werden2. Dieser Problematik müssen sich die Vertragspartner auch bei der Gestaltung der Verträge stellen. 61 In Vertragsgestaltung und Projektorganisation muss deutlich werden, dass sich der Anwender gerade für die Vorteile entschieden hat, die eine Standardsoftware mit sich bringt, dafür aber auch bereit ist, die Nachteile gegenüber einer Eigenentwicklung zu akzeptieren. Notwendig ist eine Projektregelung, die vor jede (softwaretechnische) Änderung des Standards und vor jede ergänzende individuelle Entwicklung eine Eskalationshürde und eine wirtschaftliche Betrachtung (auch zur Kontrolle des Budgets) setzt. Ein Beispiel wäre folgende Formulierung: Die Einführung erfolgt im Rahmen der Standardfunktionalitäten der vom Auftragnehmer entwickelten Software auf Basis des vom Auftragnehmer freigegebenen Releasestandes und mit Mitteln des Standards. Erweiterungen des Standards sind möglich und teilweise berücksichtigt, nicht jedoch für Bereiche, die mit (…) gekennzeichnet sind. Sollten sich weitere Anpassungen als notwendig erweisen, wird über die Realisierung dieser Anpassungen im Rahmen des Lenkungsausschusses entschieden. Dabei sind zwei Wege möglich: 1. Der Auftraggeber sichert notwendige organisatorische Anpassungen seiner Geschäftsprozesse zu, um die Standards des Auftragnehmers optimal nutzen zu können. 2. Ist eine Modifikation des Standards unumgänglich, werden die Anforderungen aufgenommen, durch die Projektleitung bewertet und dem Lenkungsausschuss zur Entscheidung vorgelegt.

62 Diese (vertraglichen) Regelungen nützen natürlich nur, wenn sie allen Projektbeteiligten frühzeitig mitgeteilt werden und die Einhaltung eingefordert wird.

1 Capgemini-Studie IT-Trends 2012, Computerwoche v. 3.3.2012, http://www.com puterwoche.de/management/it-strategie/2504066/. 2 Hesseler/Görtz, Basiswissen ERP-Systeme, 2008, S. 233.

632

Witzel

Implementierung von Standardsoftware

Rz. 66 G

2. Denkbare Gestaltungsmöglichkeiten und rechtliche Einordnung von Verträgen über Anpassung, Einführung und Implementierung von Standardsoftware a) Unterschiedliche Interessen von Softwareanbieter und -anwender Werden die zur Einführung einer Standardsoftware erforderlichen Leistun- 63 gen vom Softwareanbieter im Zusammenhang mit der Überlassung von Standardsoftware erbracht, kann ein einheitlicher bzw. können mehrere getrennte Verträge über einzelne Leistungen abgeschlossen werden1. Inwieweit eine Aufteilung auf mehrere Verträge sinnvoll und zu empfehlen ist, kann u.a. auch abhängig vom Umfang der erforderlichen Änderungsleistungen sein. Aus Sicht des Anwenders empfiehlt es sich meist, einen einheitlichen Ver- 64 trag über die Lieferung der Standardsoftware und deren Anpassung, Einführung und Implementierung zu schließen oder durch andere Regelungen eine ausdrückliche Verbindung zwischen den Verträgen herzustellen. So kann der Anwender Regelungen schaffen, die es ihm ermöglichen, beim Scheitern des Projekts zu verhindern, dass er auf der erworbenen Standardsoftware ohne tatsächlichen Nutzen sitzen bleibt. Dies wird vor allem dann notwendig sein, wenn die Standardsoftware, die Gegenstand der Einführung ist, nur vom jeweiligen Hersteller angepasst und eingeführt werden kann. Auch die unterschiedlichen Anknüpfungszeitpunkte für den Beginn der Mängelverjährung im Kaufrecht (Ablieferung) und Werkvertragsrecht (Abnahme) sowie die etwaigen Schwierigkeiten, einzelne Mängel der angepassten Software einem bestimmten Leistungsteil zuzuordnen, sprechen für den Abschluss eines einheitlichen Vertrags. Dagegen dürfte es eher im Interesse des Softwareanbieters liegen, getrennte 65 Verträge abzuschließen. Für ihn ist von Bedeutung, dass die Verjährungsfrist für Mängelansprüche zumindest für die überlassene Standardsoftware möglichst schnell zu laufen beginnt und vor allem keinem Abnahmeerfordernis unterliegt. Die Aufteilung der Verträge ermöglicht darüber hinaus eine frühere Berechnung (und Buchung) der Vergütung. b) Anpassung einer Standardsoftware durch den Lieferanten (Hersteller) der Standardsoftware aa) Abschluss eines einheitlichen Vertrags oder mehrerer verbundener Verträge Der Anwender hat einen Vertragspartner: Der Softwareanbieter ist Hersteller der Standardsoftware, passt diese Software an die individuellen Bedürfnisse seines Kunden an und übernimmt die Einführung und Implementierung beim Anwender. Für den Anwender besteht ein erhebliches Interesse 1 Zu den Gestaltungsmöglichkeiten s. auch noch unten Fn. 4 zu Rz. 160, Vertragsbeispiele s. Redeker, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Kap. 1.6.

Witzel

633

66

G Rz. 67

Sonderregelungen

am Abschluss eines einheitlichen Vertrags oder an durch eine übergreifende Regelung verbundene Verträge. Der Anwender wird die Software nicht allein anpassen können, auch dann nicht, wenn er ausführlich geschult ist. Selbst wenn er über das erforderliche Know-how verfügen würde, steht er meist vor weiteren Hürden. Ihm steht kein Änderungsrecht im Sinne von § 69c Nr. 2 UrhG zu, im Übrigen verfügt er im Regelfall auch nicht über den Quellcode, der zur Durchführung von Eingriffen in die Software erforderlich wäre. Für den Anwender ist die Standardsoftware für sich allein demzufolge wirtschaftlich uninteressant und nahezu wertlos. bb) Getrennte Verträge über Software-Überlassung und Anpassung und Einführung 67 Auch hier hat der Anwender einen Vertragspartner, allerdings mehrere Verträge über unterschiedliche Leistungen: – Lieferung und Überlassung der Standardsoftware; – Anpassung der Standardsoftware an individuelle Anforderungen; – Beratungsleistungen, wie Schulung, Projektmanagement u.Ä. 68 Die Rechtsprechung neigt dazu, die vertraglichen Vereinbarungen über die Überlassung von Standardsoftware und deren Anpassung – auch bei getrennten Verträgen – als Einheit zu bewerten und insgesamt als Werkvertrag anzusehen. Daher ist der Nutzen der getrennten Verträge häufig begrenzt. Dies wird auch dadurch verstärkt, dass Softwareanbieter in ihren Vertragsunterlagen die Trennung der Leistungsbereiche „praktizieren“, aber ihren Vertrieb nicht an dieses Modell anpassen. Die Angebotstexte und die Zusagen des Vertriebs versprechen eine Einheit, die in den Verträgen wieder getrennt werden soll. Will ein Softwareanbieter seine Leistungsbereiche rechtlich getrennt halten, kann er dies nicht allein durch die Verwendung unterschiedlicher Vertragsdokumente erreichen, sondern muss dafür sorgen, dass sowohl der Vertrieb als auch die Projektdurchführung dieses Modell mit Leben füllt. c) Anpassung einer Standardsoftware durch einen anderen Softwareanbieter als den Lieferanten: Vertrag ausschließlich über Anpassung und Einführung 69 Hierbei ist der Anwender mit zwei Vertragspartnern konfrontiert: Die Leistungen zur Anpassung werden nicht vom Hersteller der Software, sondern von einem dritten Anbieter vorgenommen, der über entsprechende Verträge mit dem Hersteller über die erforderlichen Rechte verfügt. Für den Hersteller der Standardsoftware hat diese Konstellation den Vorteil, dass seine Vereinbarungen im Falle des Scheiterns der Anpassung und Einführung unberührt bleiben. Der Nachteil für den Anwender liegt auf der Hand: Er bleibt im Zweifel auf einer für ihn nicht produktiv einsetzbaren Standardsoftware sitzen, es sei denn, es ist ihm in Verhandlungen gelungen, die Verträge mit

634

Witzel

Rz. 72 G

Implementierung von Standardsoftware

dem Hersteller unter eine aufschiebende oder auflösende Bedingung zu stellen oder ein Rücktrittsrecht zu vereinbaren. Bei Scheitern einer solchen Einführung und Implementierung ohne entspre- 70 chende vertragliche Absicherung mit dem Hersteller wird der Anwender – sofern er die Kosten für die Standardsoftware nicht abschreiben will – allenfalls auf die Suche nach einem neuen Vertragspartner für Anpassung, Einführung und Implementierung gehen müssen. Etwa im Bereich etablierter ERP-Systeme wie SAP, Microsoft Dynamics NAV oder Oracle wird dies grundsätzlich möglich sein. Ob allerdings nach einem gescheiterten Projekt das Vertrauen eines Anwenders in die Standardsoftware an sich noch gegeben ist, darf durchaus bezweifelt werden. Ein Umstieg auf einen anderen Einführungs- und Implementierungspartner scheint allenfalls dann erfolgversprechend, wenn der Wechsel zu einem Zeitpunkt erfolgt, in dem noch keine Bedenken hinsichtlich der grundsätzlichen Einsetzbarkeit der Standardsoftware bestehen. d) Rechtliche Einordnung von Verträgen über die Anpassung und Einführung von Standardsoftware aa) Gesetzliche Grundlagen: Vertragstypen und ihre Leistungen Das BGB stellt folgende Vertragstypen zur Verfügung, die für die Leistungsgegenstände eines Projekts über die Anpassung, Einführung und Implementierung einer Standardsoftware eine wesentliche Rolle spielen1: – – – –

71

Kaufvertrag nach §§ 433 ff. BGB; Werkvertrag nach §§ 631 ff. BGB; Dienstvertrag nach §§ 611 ff. BGB; Herstellung und Lieferung beweglicher Sachen. § 651 BGB als Verweisungsnorm erklärt Kaufrecht für anwendbar.

Der Vollständigkeit halber zu erwähnen ist auch der Mietvertrag (§§ 535 ff. BGB), der bei neuen Lizenzmodellen (SaaS2, PaaS, ASP3) eine Rolle spielt. 1 Koch, Computervertragsrecht; Müller-Hengstenberg, CR 2004, 161; Schneider, Softwareerstellung und Softwareanpassung – Wo bleibt der Dienstvertrag?, CR 2003, 317; Schneider, Das neue Recht für Softwareerstellung/-anpassung (unter Mitarbeit von Bischof), ITRB 2002, 273; Schweinoch/Roas, Paradigmenwechsel für Projekte: Vertragstypologie der Neuerstellung von Individualsoftware, CR 2004, 326; Thewalt, Der Softwareerstellungsvertrag nach der Schuldrechtsreform, Rechtsnatur, Leistungsbestimmung und Mängelhaftung. Zur Darstellung der Vertragstypen s. Kap. D Rz. 56 ff. 2 Pohle/Amann, Über den Wolken … – Chancen und Risiken des Cloud Computing, CR 2009, 273; Schuster/Reichl, Cloud Computing & SaaS: Was sind die wirklich neuen Fragen?, CR 2010, 38; Stiemerling/Hirschmeier, Software as a Service in der Praxis, ITRB 2010, 146. 3 Müller-Hengstenberg/Kirn, Vertragscharakter des Application Service ProvidingVertrags, NJW 2007, 2370; Rössel, Vertragstypologie des ASP, ITRB 2007, 55.

Witzel

635

72

G Rz. 73

Sonderregelungen

Mehr und mehr komplexe Standardsoftware wird auf Basis solcher mietund dienstvertraglich gestalteten Lizenzmodelle angeboten. Leistungen zur Anpassung und ggf. Implementierung werden auch dabei benötigt, wenn auch vielleicht nicht in erheblichem Umfang, da Wesen solcher Lizenzmodelle eine weitgehende Standardisierung des Leistungsportfolios ist. Allerdings wird es auch Projekte geben, in denen eine Standardsoftware beim Anwender eingeführt und implementiert wird, die im Wege eines SaaS oder ASP überlassen wird. Möglicherweise verläuft sich bei einem solchen Konstrukt die Diskussion um § 651 BGB im Zusammenhang mit der Anpassung, Einführung und Implementierung von Standardsoftware, weil für die kaufrechtliche Einordnung bei einem Modell der zeitlich begrenzten Überlassung der Standardsoftware (und in der Konsequenz auch deren Anpassung) kein Raum mehr für die Annahme der Lieferung einer beweglichen Sache ist. 73 Im Rahmen eines Kaufvertrages verpflichtet sich der Verkäufer zur Übereignung eines fertigen Gegenstands oder zur Übertragung von Rechten (§ 453 BGB). Der Verkäufer schuldet nicht die Herstellung und Verschaffung eines Gegenstands, es sei denn, Kaufrecht kommt über die Verweisungsnorm des § 651 BGB zur Anwendung. Soweit der Kaufvertrag Montage-, Installations-, oder Inbetriebnahmeleistungen vorsieht, berührt dies die Qualifizierung als Kaufvertrag nicht1. Je bedeutender jedoch die „Nebenleistungspflichten“ sind, desto mehr wird die Anwendung reinen Kaufrechts auf einen Vertrag in Frage gestellt. Wie oben ausgeführt, gehören zur Anpassung, Einführung und Implementierung einer Standardsoftware im Regelfall umfangreiche Leistungen über die reine Lieferung der Standardsoftware hinaus; selbst die Installation kann nicht nur trivial sein. Ob daher bei einem komplexen Vertrag ausschließlich Kaufrecht – ob über § 433 BGB direkt oder über § 651 BGB – zur Anwendung kommen kann, ist fraglich. 74 Die werkvertragstypische Leistung ist die Herstellung und Verschaffung des versprochenen individuellen Werks, dh der Werkunternehmer ist zur Herbeiführung eines bestimmten Arbeitsergebnisses (Erfolgs) verpflichtet. Demgegenüber ist der Besteller zur Leistung der Vergütung verpflichtet. Der Werkunternehmer verpflichtet sich also zu einer entgeltlichen Wertschöpfung durch Arbeitsleistung für den Besteller, indem er das vereinbarte Werk schafft oder erfolgsbezogene Beiträge zu seiner Verwirklichung leistet. 75 Der Dienstvertrag hat wie der Werkvertrag eine entgeltliche Arbeitsleistung des Auftragnehmers zum Gegenstand. Dieser schuldet jedoch ein bloßes Wirken, nicht die Herbeiführung eines vereinbarten Erfolgs, wobei durchaus auch im Rahmen eines Dienstvertrags Arbeitsergebnisse entstehen können. Auch bei Anpassung, Einführung und Implementierung von Standardsoftware, die naturgemäß die erfolgreiche Einführung der Standardsoftware zum Ergebnis hat, kann der Auftragnehmer nur dienstvertragliche Leistun1 So auch Habel/Rauch, Technologieverträge, S. 10.

636

Witzel

Rz. 79 G

Implementierung von Standardsoftware

gen schulden: Dann nämlich, wenn der Auftragnehmer nach Maßgabe der Entscheidungen des Auftraggebers handelt und Anweisungen des Auftraggebers umsetzt. Erfolgen die entscheidenden Weichenstellungen im Rahmen eines Projekts durch den Auftraggeber, kann der Auftragnehmer keinen Erfolg schulden1. Der frühere Werklieferungsvertrag (§ 651 BGB a.F.) unterschied für die Ent- 76 scheidung über eine Zuordnung zu den Vertragstypen Kauf- oder Werkvertrag zwischen der Herstellung vertretbarer und nicht vertretbarer Sachen. Diese Unterscheidung ist nach der Schuldrechtsreform aufgegeben worden: 77 Auf die Verpflichtung zur entgeltlichen Herstellung beweglicher Sachen findet gemäß § 651 BGB Kaufrecht Anwendung. Sachen im Sinne des Gesetzes sind körperliche Sachen i.S.v. § 90 BGB. Die Sachqualität von Software ist seit der Neufassung des § 651 BGB erneut erheblich umstritten. (Noch) unverrückbare Tatsache ist, dass der BGH auf die dauerhafte Überlassung von Standardsoftware gegen Zahlung einer Einmalvergütung Kaufrecht anwendet. Die Neufassung des § 651 BGB führt mangels gesetzgeberischer Klarstellung nun zu dem Dilemma, dass je nach rechtlicher Qualifizierung von Software als Sache oder nicht, Kaufrecht auch auf die Verträge über die Anpassung von Standardsoftware zur Anwendung kommen kann. Die Folgen:

78

– Im Zweifel wird die Vergütung mit Vertragsschluss fällig. – Es bedarf keiner Abnahme. – Die Verjährungsfrist für Sach- und Rechtsmängel beginnt mit Ablieferung der Software zu laufen. – Der Anspruch auf Selbstvornahme aus dem Werkvertragsrecht entfällt. – Mängelansprüche verjähren in zwei Jahren ab Ablieferung. bb) Unterschiede der einzelnen Vertragstypen 79

Regelung

Kaufvertrag

Werkvertrag

Dienstvertrag

Gegenstand

§ 433 BGB: Lieferung einer beweglichen Sache, Verschaffung des Eigentums hieran

§ 631 BGB: Herstellung des vereinbarten Werkes

§ 611 BGB: Erbringung der vereinbarten Leistung

1 Die Tendenz der Rechtsprechung geht allerdings dahin, dass auch bei IT-Leistungen, in denen eine Verpflichtung des Auftragnehmers zur Herbeiführung eines Erfolgs nicht deutlich vereinbart wurde, Werkvertragsrecht anzuwenden (s. z.B. OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95). Auf die Vertragsgestaltung bei einer solchen dienstvertraglichen Konstellation ist also besonderes Augenmerk zu richten, mit einer AGB-rechtlichen Gestaltung wird man wohl nicht weiter kommen. Redeker stellt in Kap. D Rz. 60 ff. zutreffend dar, dass auch in einem Gesamtprojekt, in dem die Gesamtverantwortung beim Auftraggeber liegt, der Auftragnehmer die Erfolgsverantwortung für Teilleistungen haben kann.

Witzel

637

G Rz. 79

Sonderregelungen

Regelung

Kaufvertrag

Werkvertrag

Dienstvertrag

Gefahrübergang

§ 446 BGB: mit Übergabe

§ 644 BGB: mit Abnahme

Entfällt

Fälligkeit der Vergütung

§§ 433 Abs. 1, 271 Abs. 1 BGB: mit Entstehung der Forderung bei Vertragsabschluss, soweit nicht anderweitig vereinbart

§ 641 BGB: bei der Abnahme, aber möglicher Anspruch auf Abschlagszahlungen, § 632a BGB

§ 614 BGB: nach Leistung der Dienste, soweit nicht vertraglich anders vereinbart

Abnahme

Gesetzlich nicht § 640 BGB: wenn vorgesehen, kann das Werk vertragsaber individualver- gemäß erstellt ist traglich vereinbart werden

Gesetzlich nicht vorgesehen; eine entsprechende vertragliche Vereinbarung wäre ein Indiz, dass die Vertragspartner einen Werkvertrag vereinbaren wollten

Mängelansprüche

§ 437 BGB: zunächst Nacherfüllung, anschließend Rücktritt oder Minderung sowie Schadensersatz oder Ersatz vergeblicher Aufwendungen

§ 634 BGB: zunächst Nacherfüllung, anschließend Ersatzvornahme und Ersatz der erforderlichen Aufwendungen oder Rücktritt oder Minderung sowie Schadensersatz oder Ersatz vergeblicher Aufwendungen

Kein Mangelanspruch, aber Anspruch wegen Pflichtverletzung bei Schlechtleistung: §§ 280, 282 BGB: verschuldensabhängiger Anspruch auf Schadensersatz

§ 634a BGB: zwei Jahre bei der Herstellung einer beweglichen Sache, 3 Jahre bei geistigen Werken oder bei Arglist

§ 195 BGB: drei Jahre

Verjährungsfristen Zwei Jahre ab Abfür Mängel lieferung, bei Arglist 3 Jahre nach § 195 BGB (Beginn § 199)

Zugesicherte Eigenschaften/ Garantien

Zugesicherte Eigenschaften sind entfallen, dafür aber § 443 BGB Beschaffenheits- und Haltbarkeitsgarantie

Keine zugesicherte Keine vergleichEigenschaft mehr, bare Regelung aber § 639 BGB: Beschaffenheitsgarantie

Kündigung

Keine Regelung

§§ 649 BGB, 314 BGB

638

Witzel

§§ 620 ff. BGB, 314 BGB

Implementierung von Standardsoftware

Rz. 82 G

cc) Meinungsstand zu § 651 BGB Direkt nach Inkrafttreten der neuen Regelungen1 wurden die Auswirkun- 80 gen in der Literatur umfassend diskutiert, während die Gerichte die Existenz des § 651 BGB und dessen mögliche Anwendung bei Softwareprojekten zunächst zu ignorieren schienen2. Offensichtlich wollten sich die Gerichte nicht mit den detaillierten Analysen und Argumenten der jeweiligen Autoren zu § 651 auseinandersetzen. Ein Urteil des BGH, das § 651 auf einen baurechtlichen Sachverhalt anwendet, hat die Diskussion wieder aufleben lassen3. Von einer Klärung der offenen Fragen und damit von Rechtssicherheit ist man allerdings immer noch weit entfernt. Die Anwendbarkeit von § 651 BGB hängt vor allem davon ab, ob Software als Sache zu qualifizieren ist.

81

Der BGH hat Software einfach zur Sache „erklärt“4:

82

„Gemäß § 381 Abs. 2 HGB findet die für den Kauf getroffene Regelung des § 377 HGB auch Anwendung, wenn – wie hier für den unterstellten Fall des Abschlusses eines Werklieferungsvertrages – aus einem von dem Unternehmer zu beschaffenden Stoff eine nicht vertretbare bewegliche Sache herzustellen ist. Die Revision sieht dies im Ansatz nicht anders, meint jedoch, im vorliegenden Fall eines nach den individuellen Bedürfnissen des Bestellers umgearbeiteten Programmes könne von einer beweglichen Sache im Sinne des § 381 Abs. 2 HGB nicht gesprochen werden. Dies trifft nicht zu. Der Senat hat, woran festzuhalten ist, bereits mehrfach entschieden, dass Standardsoftware als bewegliche Sache anzusehen ist … Gleiches hat zu gelten, wenn eine Standardsoftware den speziellen Wünschen des Käufers/ Bestellers angepasst und diesem in kauf- oder werkvertraglichen Formen endgültig

1 Ausführlich zu § 651 BGB, s. Kap. B Rz. 14 ff. und Kap. D Rz. 67. § 651 BGB stellt eine Rechtsfolgenvereinbarung dar: Der Vertrag über die Herstellung beweglicher Sachen ist kein Kaufvertrag, sondern ein Werkvertrag, der im Wesentlichen kaufrechtlichen Vorschriften unterliegt, s. auch Kap. D Rz. 67 ff. 2 So etwa das OLG Köln im Urt. v. 10.3.2006 – 19 U 160/05, CR 2006, 440: „Zutreffend hat die Kammer die vertraglichen Beziehungen der Parteien den Vorschriften des Werkvertragsrechts unterworfen. Zwar findet beim Kauf und der Lieferung von Standardsoftware grundsätzlich auch dann die Vorschriften des Kaufrechts Anwendung, wenn die Software an die Bedürfnisse des Anwenders angepasst werden muss … Dies gilt aber dann nicht, wenn es sich bei der Anpassung um zahlreiche, teils im liefernden Programm gar nicht vorhandene Funktionen handelt. Bei einer solchen Fallgestaltung überwiegt das werkvertragliche Moment des individuell geschuldeten Erfolgs in einer Weise, dass die Anwendung von Werkvertragsrecht gerechtfertigt ist … Nach der ständigen Rechtsprechung des Senats gilt dies insbesondere für Verträge, die die Verpflichtung zur Herstellung bzw. zur Anpassung von Software zum Gegenstand haben …“. 3 BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637. 4 Wobei die Argumentation hier nicht durchgängig ist, so kommt nämlich der „Urheberrechtssenat“ in der Inkasso-Programm-Entscheidung zum Ergebnis, dass Software ein „immaterielles“ Gut sei, BGH v. 4.11.1987 – VIII ZR 314/86, BGHZ 102, 135 = CR 1988, 124 = CR 1988, 994 m. Anm. Ruppelt. In der der sog. ASP-Entscheidung, BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 75, wurde diese Einschätzung bestätigt.

Witzel

639

G Rz. 83

Sonderregelungen

überlassen wird. Entscheidend ist allein, dass es sich auch in diesem Fall um ein auf einem Datenträger verkörpertes Programm und damit eine körperliche Sache handelt.“1

83 In der Literatur hat es intensive Auseinandersetzungen mit dieser Frage gegeben. Die einen sehen Software als „immaterielles“ Gut und „geistige Schöpfung“2, das keine Sachqualität im Sinne des § 90 BGB hat3. Es fehle an dem nach § 90 BGB erforderlichen Zugang zur sinnlichen Wahrnehmung. Wahrgenommen werden könne allenfalls der Datenträger, auf dem die Software verkörpert ist, nicht die Software selbst. Die Verfechter4 der Sachqualität stellen demgegenüber darauf ab, dass auch bei Software eine Verkörperung grundsätzlich notwendig ist5. Je nachdem welche Auffassung man zur Sachqualität von Software einnimmt, ergibt sich für die Anwendung von § 651 BGB die entsprechende Konsequenz. 84 Im Ergebnis argumentieren die Befürworter der Anwendbarkeit des § 651 BGB im Wesentlichen mit der Sachqualität von Software, die vom BGH schließlich auch angenommen wurde, und kommen so an der Anwendung der kaufrechtlichen Vorschriften nicht vorbei. 85 Im Vordergrund steht für die Befürworter6 der Einschlägigkeit des Werkvertrags demgegenüber weniger ein dogmatischer als ein pragmatischer An1 BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681. In seiner Entscheidung v. 9.10.2001 erklärt der BGH allerdings im Kontrast dazu, „es könne dahin stehen, ob das Ergebnis der von der Klägerin geschuldeten Programmierleistung eine Sache im Sinne von § 381 Abs. 2 HGB betrifft“, BGH v. 9.10.2001 – X ZR 58/00, CR 2002, 93, 95. 2 Redeker, Software ist ein besonderes Gut, NJOZ 2008, 2917: „Software ist ein besonderes Gut: Datenträger, einzelnes Softwareexemplar und geistiges Werk müssen unterschieden werden. Datenträger sind Sachen, das geistige Werk Software ist es nicht. Im Gegensatz zur Meinung des Vertragssenats des BGH … ist auch das einzelne Softwareexemplar keine Sache. Es kann auch nicht generell wie eine Sache behandelt werden. In Einzelfällen sind aber Analogien möglich.“ 3 So Diedrich, CR 2002, 473; Redeker, IT-Recht in der Praxis, Rz. 286; Pres, Gestaltungsformen, S. 21. 4 U.a. Marly, Softwareüberlassungsverträge, Rz. 96 ff. Marly greift auf den „Buchvergleich“ zurück: „Auch das Buch ist Ergebnis einer schöpferischen Geistestätigkeit (und verschiedener weiterer überwiegend handwerklicher, technischer Tätigkeiten des Buchdrucks). Wenngleich vereinzelt darauf hingewiesen wird, dass der Inhalt des Buchs auch nach dessen Vernichtung im Bewusstsein des Lesers verbleiben und dadurch seinen Zweck erfüllen könne, was bei Vernichtung des Informationsträgers eines Computerprogramms nicht der Fall sei, vermag dies an der grundsätzlichen Notwendigkeit einer Verkörperung nichts zu ändern. Zweck eines Bucherwerbs ist nach herrschender Meinung neben der reinen Informationserlangung eine jederzeitige Rückgriffsmöglichkeit auf den Inhalt, die jedoch nur möglich ist, wenn der Inhalt verkörpert ist, so dass das Buch mitsamt seinem Inhalt einen körperlichen Gegenstand i.S.v. § 90 BGB darstellt.“ 5 Schweinoch/Roas, CR 2004, 326. 6 Diedrich, Typisierung von Softwareverträgen nach der Schuldrechtsreform, CR 2002, 473 ff.

640

Witzel

Implementierung von Standardsoftware

Rz. 88 G

satz: Die Vorschriften des Werkvertragsrechts „passen schlichtweg besser“. Für die Abnahme bzw. für ein Testverfahren – das die rechtlichen Wirkungen einer Abnahme haben kann – bestehe ein praktisches Bedürfnis. Im Übrigen sei der Anwender an einem Erfolg – nämlich der funktionierenden softwaretechnischen Abbildung seiner Geschäftsprozesse – interessiert und nicht an der bloßen Lieferung eines Datenträgers. Dem „pragmatischen Ansatz“ folgt offensichtlich auch Palandt/Sprau1 und erklärt § 651 BGB auf EDV-Verträge für nicht anwendbar. Wie diese Auffassung mit der Rechtsprechung des BGH in Einklang zu brin- 86 gen ist, bleibt offen. Insofern sind die Zweifel von Schneider2 berechtigt: Sachqualität hin oder her, die gewonnene Rechtssicherheit ist jedenfalls dahin. Des Weiteren ungelöst ist die Frage, welche Verjährungsregelungen denn zur Anwendung kommen. Richtigerweise müsste die Verneinung der Sachqualität zur Anwendung von § 634a Abs. 1 Nr. 3 BGB führen (regelmäßige Verjährung, also drei Jahre), die Verjährungsfrist würde also nicht mit Abnahme beginnen, sondern nach § 199 BGB mit Entstehung des Anspruchs und Kenntnis des Anspruchsinhabers. Auch die Frage, inwieweit § 377 HGB zur Anwendung kommt, ist streitig, wenn nicht die vertraglichen Vereinbarungen dazu Ausführungen enthalten. dd) BGH-Entscheidung vom 23.7.2009 In seiner Entscheidung vom 23.7.20093 hat der BGH festgestellt, dass Kauf- 87 recht immer dann anwendbar ist, wenn die Lieferung herzustellender oder zu erzeugender Sachen geschuldet ist. Dies gilt nach Auffassung des BGH auch dann, wenn die Sachen dazu bestimmt sind, in ein zu errichtendes Bauwerk eingebracht zu werden. Es ging in der streitgegenständlichen Entscheidung um die Lieferung von Bauteilen für eine Siloanlage. An der Anwendbarkeit von § 651 BGB ändert sich nach Einschätzung des BGH auch dann nichts, wenn Gegenstand des Vertrags auch Planungsleistungen sind, die der Herstellung der Bau- und Anlagenteile vorauszugehen haben und nicht den Schwerpunkt des Vertrags bilden. Der BGH stellt in Rz. 16 des Urteils deutlich klar, dass die vertragstypologische Einordnung von Leistungen im Anwendungsbereich von § 651 BGB neu vorzunehmen ist. Die Anwendung von Prinzipien, die vor der Neufassung von § 651 BGB entwickelt und angewandt wurden, wird ausdrücklich abgelehnt. Schweinoch sieht im Urteil des BGH vom 23.7.2009 eine klare Aussage da- 88 hingehend, dass es keine tragfähige Argumentation gibt, wonach § 651 BGB auf erfolgsbezogene Leistungen nur eingeschränkt oder gar nicht anwendbar 1 Palandt/Sprau, Vor § 631 BGB Rz. 22 sowie § 651 BGB Rz. 5. 2 Schneider, CR 2003, 322; s. Kap. B Rz. 32 ff. „Software-unspezifische Interpretationen des § 651 BGB im Lichte der ‚EU-Kaufrechtsrichtlinie‘“. 3 BGH v. 23.7.2009 – VII ZR 151/08, CR 2009, 637 m. Anm. Schweinoch; Schweinoch, Geänderte Vertragstypen in Software-Projekten, CR 2010, 1; Im Zweifel Kaufrecht?, NJW-Spezial 2009, 604.

Witzel

641

G Rz. 89

Sonderregelungen

ist. Der BGH habe den diversen Begründungen der Literatur für eine Nichtanwendung von § 651 BGB die Grundlagen entzogen1. Allein die Erfolgsbezogenheit von Leistungen würde nicht mehr zur Anwendung von Werkvertragsrecht führen. Der BGH hat damit der pragmatischen Argumentation, dass Werkvertragsrecht für Softwareprojekte nun einmal interessengerechter erschiene, eine Absage erteilt. 89 Müller-Hengstenberg argumentiert2, dass die Grundsätze für einen baurechtlichen Sachverhalt nicht ohne Weiteres auf IT-Projekte übertragen werden könnten. Nach seiner Auffassung sind anders als im Baubereich bei IT-Projekten essentielle Abhängigkeiten zwischen den Geschäftsprozessen des Anwenders und dem fachlichen bzw. technischen Design der zu entwickelnden oder anzupassenden Software gegeben. Bei Bauprojekten finde gerade keine fundamentale Integration des entwickelten Systems in die täglichen Geschäftsprozesse und Arbeitsabläufe des Anwenders statt. Auch nach den in der BGH-Entscheidung vom 23.7.2009 aufgestellten Kriterien dürfte die Anwendung des Werkvertragsrechts angebracht sein, wenn IT-basierte Anwendungslösungen in Form von Phasen und Vorgehensmodellen entwickelt würden, bei denen sogar Methoden wie das Prototyping3 zugrunde gelegt würden. 90 Maume/Wilser4 wollen der Entscheidung vom 23.7.2009 ebenfalls keine grundsätzliche Bedeutung zukommen lassen. Nach ihrer Auffassung können Verträge, die die Anpassung von Standardsoftware zum Gegenstand haben, jedenfalls dann dem Werkvertragsrecht unterstellt werden, wenn einer Standardsoftware neue, bislang nicht bestehende Funktionen hinzugefügt werden, da dabei wesentlich höhere Planungs- und Programmierleistungen zu erbringen sind und damit das werkvertragliche Element überwiegt. 91 Witte5 diskutiert die Anwendbarkeit von § 651 BGB vor allem vor dem Hintergrund neuer Projektmethoden6 und vertritt die Auffassung, dass sowohl beim Prototyping als auch beim agilen Programmieren die fertige Software viel eher als beim klassischen Softwareprojekt als bloßes Substrat eines vorausgegangenen, während der gesamten Vertragslaufzeit unabdingbaren und daher dominierenden Planungsprozesses anzusehen ist.

1 Schweinoch, CR 2010, 1. 2 Müller-Hengstenberg, Ist das Kaufrecht auf alle IT-Projektverträge anwendbar?, NJW 2010, 1181. 3 Nach Söbbing, Die rechtliche Betrachtung von IT-Projekten, MMR 2010, 222, ist ein Werkvertrag in der Regel beim Prototyping nicht möglich. 4 Maume/Wilser, Viel Lärm um Nichts? Zur Anwendung von § 651 BGB auf ITVerträge, CR 2010, 209. 5 Witte, Agiles Programmieren und § 651 BGB, ITRB 2010, 44. 6 Dazu auch Schneider, Neue Projektmethoden und altes Vertragsrecht, ITRB 2010, 18.

642

Witzel

Implementierung von Standardsoftware

Rz. 95 G

Nach Frank1 ist es bei IT-Projektverträgen, die weitere Leistungen wie Pro- 92 jektleitung, Implementierung, Integration, Betrieb, Pflege, Schulungen umfassen, ausreichend, einen Schwerpunkt abseits der Lieferung zu setzen. Sofern die Implementierung ins betriebliche Umfeld neben der Erstellung eines komplexen Systems geschuldet sei, sei Werkvertragsrecht anwendbar, dies jedenfalls dann, wenn der „Montageanteil“ deutlich überwiege. Die Literatur zeigt, dass die Entscheidung des BGH zu den Silo-Bauteilen 93 augenscheinlich mehr Probleme aufgeworfen als gelöst hat. Die zur Anwendbarkeit von § 651 BGB vertretenen Auffassungen sind unverändert kontrovers. Schneiders Auffassung (vgl. Rz. 86), die auf einer konsequenten Anwendung des Wortlauts von § 651 BGB basiert, wird durch die Entscheidung vom 23.7.2009 weitgehend bestätigt. ee) Weitere Entscheidungen Das OLG Frankfurt stuft einen Vertrag über die Installation und Anpassung eines bestimmten Softwaresystems (Implementierung) nebst Einweisung als gemischten Rechtskauf- und Dienstvertrag ein2.

94

Zwei Entscheidungen des BGH betreffen sog. Internet-System-Verträge. 95 Der dritte Senat kommt in seiner Entscheidung vom 4.3.20103 zu dem Ergebnis, dass die Qualifizierung eines Internet-System-Vertrags als Werkvertrag im Einklang mit der BGH-Rechtsprechung zur Zuordnung von Internetverträgen zu den Vertragstypen des BGB steht: Diese Zuordnung „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 an der verobjektivierten Kundenerwartung, zum Ausdruck kommt, und rechtfertigt sich auch aus einem Vergleich mit Verträgen, die ähnliche Gegenstände betreffen und als Werkverträge anzusehen sind.“ Gegenstand der vereinbarten Leistung im streitgegenständlichen Sachverhalt war die auf einen bestimmten Zeitraum festgelegte Gewährleistung der Abrufbarkeit der für den Kunden erstellten und betreuten Website, mithin die Herbeiführung eines Erfolgs. Der BGH erläutert in den Entscheidungsgründen die Vertragstypologie diverser Internet-bezogener Leistungen und erwähnt beinahe im Nebensatz, dass ein Vertrag über die Erstellung oder Bearbeitung einer speziellen, auf die Bedürfnisse des Auftraggebers abgestimmten Software regelmäßig als Werkvertrag im Sinne der §§ 631 ff. BGB, unter Umständen auch als Werklieferungsvertrag im Sinne von § 651 BGB anzusehen ist. Unter welchen konkreten Umständen § 651 BGB anwendbar ist, erläutert der BGH nicht.

1 Frank, IT-Projekt – § 651 BGB und kein Ende, ITRB 2011, 231. 2 OLG Frankfurt v. 22.9.2010 – 4 U 52/10. 3 BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327 = NJW 2010, 1449.

Witzel

643

G Rz. 96

Sonderregelungen

96 In einer Entscheidung vom 27.1.20111 kommt auch der siebte Senat zu dem Ergebnis, dass der zwischen Parteien geschlossene „Internet-System-Vertrag“ rechtlich als Werkvertrag zu qualifizieren ist und verweist dabei ohne weitergehende Begründung auf die Entscheidung vom 4.3.2010. Diese Entscheidung trägt folglich zur Vertragstypologie nichts Erhellendes bei. 97 Die Entscheidung vom 4.3.2010 scheint einen Weg zu eröffnen, die Kriterien der Siloabauteile-Entscheidung als alleiniges Kriterium für die Anwendbarkeit von § 651 BGB in Frage zu stellen. Der BGH stellt bei seiner Begründung vor allem auf den von den Parteien bestimmten Vertragszweck, der sich in der Leistungsbeschreibung niederschlägt, ab: „Nach dem vereinbarten Vertragszweck des ‚Internet-System-Vertrags‘, wie er in der Leistungsbeschreibung in der Anlage zum Vertrag sowie in dem darin anknüpfenden Willen der Vertragsparteien, insbesondere auch der verobjektivierten Kundenerwartung, zum Ausdruck kommt, hat die Klägerin auf ihren eigenen Servern für den Kunden unter der von ihm gewünschten Domain eine Website … einzurichten, diese Webseite für den vereinbarten Zeitraum zu unterhalten und sie über das Internet Dritten zugänglich zu machen. Auf diesen Leistungszweck beziehen sich sämtliche in der ‚Leistungsbeschreibung‘ aufgeführten Leistungspflichten, nämlich die Recherche und Registrierung einer … Internet-Domain, die Zusammenstellung der Webdokumentation … durch einen Webdesigner …, die Gestaltung und Programmierung einer individuellen Internetpräsenz nach bestimmten einzelnen aufgeführten Vorgaben, das ‚Hosting‘ der Websites und Mailboxen auf den Servern der Klägerin sowie die … weitere Beratung und Betreuung des Kunden über eine Hotline der Klägerin.“ Sofern sich also aus der Leistungsbeschreibung der Vertragspartner ein so prägender Zweck ergibt, dass der Schwerpunkt der Leistung ein bestimmter Erfolg ist, kann der Anwendungsbereich von § 631 BGB eröffnet sein. ff) Konsequenzen: Rechtliche Qualifikation von Verträgen über die Anpassung und Einführung von Standardsoftware 98 Voranzustellen ist Folgendes: § 651 BGB ist eine Verweisungsnorm, die nicht zur Parteidisposition steht2. Die Verweisung ins Kaufrecht wird man auch individualvertraglich nicht aufheben können, denkbar ist es allerdings, innerhalb des Vertragstyps Änderungen und Erweiterungen vorzunehmen oder einvernehmlich zu vereinbaren, dass der Vertrag nach Werkvertragsrecht beurteilt werden soll. In AGB stößt man mit solchen Vorhaben schnell an Grenzen, die bestehenden Rechtsunsicherheiten lassen sich allenfalls in individuellen Vereinbarungen in den Griff bekommen. Die seit der ersten Auflage dieses Werks ergangenen Urteile werfen mehr Probleme für die Bestimmung des Anwendungsbereichs auf, als sie gelöst haben.

1 BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176 = NJW 2011, 915. 2 Palandt/Sprau, § 651 BGB Rz. 1.

644

Witzel

Rz. 102 G

Implementierung von Standardsoftware

(1) Leistungen bei Anpassung, Einführung und Implementierung Welche Konsequenzen hat die Diskussion und die Entscheidungen des BGH 99 vom 23.7.2009 zu § 651 BGB sowie die Entscheidung vom 4.3.2010 für den „Internet-System-Vertrag“ für Projekte, die die Anpassung, Einführung und Implementierung1 von Standardsoftware zum Gegenstand haben? Welche Konsequenzen ergeben sich insbesondere für die vertragliche Gestaltung solcher Projekte? Ist im Ergebnis der Werkvertrag immer noch oder wieder die einzig denkbare Lösung? Könnten nicht vor allem neue Vorgehensmodelle (mit denen die Verantwortung für die Realisierung nicht überwiegend dem Softwareanbieter zugewiesen wird) mehr Raum für den Dienstvertrag schaffen, der den Anwender nicht so schlecht stellt, wie es häufig die Befürworter des Werkvertrags vermuten lassen? Über § 280 BGB ist auch beim Dienstvertrag die Schlechtleistung (Pflichtverletzung) sanktioniert. Bei individueller Vertragsgestaltung lassen sich auch Nacherfüllungs- und Minderungsrechte zu Gunsten des Anwenders gestalten. Während die Vertragstypologie für Softwareerstellungsverträge unter den 100 Auswirkungen der Schuldrechtsreform in der Literatur ausführlich diskutiert wird, werden Verträge über die Anpassung, Einführung und Implementierung von Standardsoftware auch in der neueren Literatur eher am Rande behandelt. Die Ausführungen konzentrieren sich überwiegend auf die rechtliche Bewertung von Verträgen über Individualentwicklung. Dies scheint nicht der Praxis zu entsprechen, da ein überwiegender Teil der ITProjekte auf vorhandenen Standardkomponenten aufsetzt. Nach Bartsch2 wird ein Projekt, bestehend aus Lieferung von Standardsoft- 101 ware, Anpassung und Ergänzungen dieser Software, Test und Installation sowie Schulung, „durch das gesetzliche Modell ‚Werkvertrag‘ nur unzureichend abgebildet. Denn beim Werkvertrag gibt es ein ‚versprochenes Werk‘, also eine Soll-Zustandsbeschreibung; der IST-Zustand des fertig gestellten Werkes wird dann diesem Soll-Zustand gegenübergestellt. Beim Projekt ist die Soll-Zustandsbeschreibung notwendig unvollständig; die Festlegung dessen, was realisiert worden ist, ist der wichtigste Teil des Projekts, nämlich die eigentliche Entwicklung.“ Müller-Hengstenberg3 kommt zum Ergebnis, „dass die gesetzlichen Vor- 102 schriften des § 651 BGB kein ausgewogenes Bedingungswerk für die Implementierung bzw. Entwicklungen von Computersoftware bieten, da diese zu sehr auf ein Warenaustauschgeschäft gerichtet sind. Die relativ lange Projektdauer, der hohe Voraufwand des Unternehmers, die Wichtigkeit der Integration der Computersoftware in die Kundenumgebung finden in den werkvertraglichen Regelungen der §§ 632a, 634a Abs. 2, 640, 641 BGB eine sachgerechte Berücksichtigung. Die Anwendung des Kaufrechts bei solchen 1 Ausführlich zu den einzelnen Leistungen, s. Kap. D Rz. 42 ff. 2 Bartsch, in: Beck’sches Formularbuch, Bürgerliches Handels- und Wirtschaftsrecht, III. H. 4, Anm. 2. 3 Müller-Hengstenberg, CR 2004, 165.

Witzel

645

G Rz. 103

Sonderregelungen

IT-Entwicklungsprojekten bzw. -verträgen führt dazu, dass die Vertragspartner alle fehlenden Regelungen des Werkvertragsrechts vereinbaren müssen, damit das Vertragsrecht wieder ausgewogen und sachgerecht ist.“ 103

Dieser grundsätzlichen Einschätzung bleibt Müller-Hengstenberg1 auch nach der BGH-Entscheidung vom 23.7.2009 treu. Er empfiehlt, bei IT-Projekten jeweils die Vertragsstruktur zugrunde zu legen, die dem Ziel und der Durchführung des Vertrags im Einzelfall am besten gerecht wird. Dieser Empfehlung ist bei allen Projekten, die Raum für eine individualvertragliche Gestaltung bieten, zu folgen. In AGB bleiben weiterhin erhebliche Risiken, dass ein Gericht einer anderen Rechtsauffassung zur Vertragstypologie folgt als die Verfasser der AGB. Dass man sich nicht darauf verlassen kann, dass sich die Auffassung der BGH aus der Entscheidung vom 23.7.2009 durchsetzt, zeigen die späteren Entscheidungen zum Internet-System-Vertrag.

104

Die Befürworter der überwiegend werkvertraglichen Einordnung von Projektverträgen zeigen, dass, was Projekte betrifft, die neben der reinen Anpassung der Standardsoftware auch umfangreiche Leistungen zur Einführung und Implementierung umfassen, weder durch reines Kaufvertragsrecht, noch durch modifiziertes Werkvertragsrecht der Praxis Rechnung getragen werden kann. Projekte mit unterschiedlichen Leistungen dürften allerdings der Normalfall sein, da dem Anwender eine nur angepasste Software wenig nutzt. Er braucht die für die Einführung und Implementierung der angepassten Standardsoftware erforderlichen Zusatzleistungen. Bei der überwiegenden Anzahl der Projekte liegt in diesen „Zusatzleistungen“ sogar der eigentliche Schwerpunkt des gesamten Projekts. Die zu liefernde und anzupassende Software muss in die IT-Infrastruktur beim Anwender integriert werden, wobei nicht nur Schnittstellen entwickelt oder erweitert werden müssen, sondern ggf. auch Datenmodelle und Datenformate anzupassen sind, um sicherzustellen, dass die unterschiedlichen Anwendungssysteme – zumindest im Wesentlichen – reibungslos miteinander funktionieren. Werden langjährig im Einsatz befindliche Systeme abgelöst, kommt auch der Implementierung in die Organisation des Anwenders hohe Bedeutung zu. Etablierte Geschäftsprozesse müssen analysiert und hinterfragt werden, in vielen Fällen haben sich bei den Mitarbeitern des Anwenders, die jahrelang ein bestimmtes System nutzen, Prozesse eingeschliffen, die nur bedingt effizient sind. Ziel der Einführung und Implementierung einer neuen Standardsoftware sollte es auch sein, die Schwachstellen zu erkennen und mit der Implementierung zu beseitigen. Jedes Projekt zur Anpassung, Einführung und Implementierung einer Standardsoftware ist daher auch immer ein Neuorganisations- oder Restrukturierungs-Projekt und erfordert weit mehr als die Entwicklung und Lieferung von Softwarekomponenten.

105

In einem wohl sehr theoretischen Fall könnte eine Standardanwendung von der CD-ROM weg als „Referenzmodell“ ohne Anpassungen gestartet wer1 Müller-Hengstenberg, NJW 2010, 1181.

646

Witzel

Implementierung von Standardsoftware

Rz. 108 G

den, dann müsste sich der Anwender allerdings an die Vorgaben der Standardsoftware anpassen. Wären im Verhältnis zu den Vorgaben des Modells nur relativ geringe Änderungen bzw. Spezifizierungen notwendig, könnte Kaufrecht zur Anwendung kommen1. Die Anwendung der kaufrechtlichen Vorschriften ist jedenfalls nicht interessengerecht, eine zwingende Notwendigkeit zur werkvertraglichen Gestaltung – als einzig denkbares Model – ist allerdings auch nicht erkennbar. Insofern überzeugt Bartsch2 mit der Einschätzung, dass ein Softwareprojekt keinen Vertrag rechtfertigt, der auf den reinen Austausch von Leistungen gerichtet ist. (2) „Anpassung“ der Standardsoftware Kritik an der Einordnung von Software als Sache scheint berechtigt. Die Er- 106 läuterungen zur Sacheigenschaft überzeugen letztlich nicht, insbesondere die Argumentation zur Verkörperung eines urheberrechtlich geschützten Werks passt nur bedingt. Die auf einem Datenträger gespeicherte Software ist anders als der gedruckte Roman trotz der Verkörperung nicht sinnlich wahrnehmbar. Hinzu kommt, dass die Überlassung von Standardsoftware auf einem Datenträger mehr und mehr die Ausnahme darstellt. Komplexe Anwendungssoftware wird im Regelfall per Remote-Zugriff auf den Systemen des Anwenders installiert oder ihm zum Download bereitgestellt. Davon losgelöst hilft die Frage für die konkrete Vertragsgestaltung jedoch nicht weiter. Mehr Rechtssicherheit ergibt sich jedenfalls aus einer Orientierung an den Aussagen des BGH zur Sachqualität. Aufgrund der klaren Aussage des BGH zur Sacheigenschaft erscheint die 107 Anwendung von § 651 BGB auch für die reine Anpassung von Standardsoftware an die individuellen Bedürfnisse des Anwenders weiterhin als konsequent. Die Erfolgsbezogenheit dieser Leistungen führt allein nicht zur Anwendung von Werkvertragsrecht: Ist als Erfolg eine nicht vertretbare bewegliche Sache geschuldet, ist grundsätzlich Kaufrecht anzuwenden3. Dass die Anpassung der Standardsoftware über § 651 BGB ins Kaufrecht fällt, bedeutet aber wohl nicht, dass zwangsweise für den gesamten Projektvertrag eine einheitliche kaufrechtliche Einordnung anzunehmen wäre. Eine stringente Anwendung des § 651 BGB führt zu folgendem Schema:

108

– Parametrisierung der Software ohne Änderungen am Code: Kauf (die Sache „Standardsoftware“ bleibt „vertretbar“); – Herstellung von Individualsoftware: Kauf und zusätzlich die Vorschriften §§ 642, 643, 645, 649 und 650 BGB und statt der Abnahme §§ 446 und 447 BGB (§ 651 Satz 3 BGB);

1 So auch Koch, Computervertragsrecht, Rz. 1092 sowie Müller-Hengstenberg, NJW 2010, 1181. 2 Bartsch, in: Beck’sches Formularhandbuch, Bürgerliches Handels- und Wirtschaftsrecht, III. H. 4, Anm. 6. 3 So auch Schweinoch/Roas, CR 2004, 326 (327) und Schweinoch, CR 2010, 1.

Witzel

647

G Rz. 109

Sonderregelungen

– Anpassung von Software, die vom Lieferanten gestellt wurde, mit Änderungen des Codes: Kauf, ebenso wie vorstehend mit den zusätzlichen Regelungen aus dem Werkvertragsrecht (§ 651 Satz 3 BGB); – Anpassung von einem Dritten beigestellter Software, die wohl dem Kunden zuzurechnen ist: Werkvertrag, § 631 BGB. Der Softwareanbieter verändert nur eine ihm zur Verfügung gestellte Software; – Anpassung von vom Kunden beigestellter Software mit Änderungen des Code: Werkvertrag, § 631 BGB. (3) Weitere Leistungen im Rahmen der Einführung und Implementierung 109

Die reinen Anpassungsleistungen fallen folglich über § 651 BGB ins Kaufrecht. Wie oben dargestellt1, umfassen Projekte zur Anpassung von Standardsoftware jedoch weit mehr als die reine Programmierung oder das reine Customizing. Selbst die auf seine Bedürfnisse angepasste Software nutzt dem Anwender wenig, wenn sie nicht in seine IT-Infrastruktur integriert und in seiner Unternehmensorganisation implementiert ist. Das wird auch häufig in den Testphasen eines Projekts deutlich: Der Softwareanbieter hat Funktionsbereiche (oder Module) der einzuführenden und zu implementierenden Software entsprechend den angenommenen Spezifikationen parametrisiert und auf seinen Entwicklungssystemen mit im Wesentlichen reibungsloser Funktionalität getestet. Nach der Einspielung auf dem Testsystem des Anwenders tauchen plötzlich Fehler auf. Der Hauptfokus eines Projekts liegt am Ende nicht darauf, ob es in einer „Reagenzglas“-Umgebung eine kundenspezifisch angepasste Software gibt, sondern es geht um ein in der Umgebung des Anwenders im Wesentlichen fehlerfreies System.

110

Der Softwareanbieter wird vielfältige Leistungen zur Einführung und Implementierung erbringen müssen, insbesondere: – Planungsleistungen, vor allem die Konzeptionierung der zu realisierenden Anforderungen des Anwenders, aber auch die komplette Integration und Implementierung, die Produktivsetzung und ggf. die sich daran anschließende Stabilisierung; – Organisationsberatung; – Projektmanagement- und Projektorganisationsleistungen, einschließlich der Koordinierung von beteiligten Subunternehmern und Drittunternehmen; – Leistungen zur Installation auf Test- und Produktivsystemen; – Beratungsleistungen zur Implementierung, d.h. zur notwendigen Anpassung von Organisationsstrukturen; – Schulungen; – Vorbereitung und Durchführung von Tests und Abnahmeprüfungen; – Erarbeitung von Konzepten zur Migration; 1 S. Rz. 46 ff.

648

Witzel

Implementierung von Standardsoftware

Rz. 113 G

– Leistungen zur Durchführung der Migration; – Betreuungsleistungen vor und nach Produktivsetzung. Es verbinden sich hier dienstvertragliche Pflichten (beispielsweise Un- 111 terstützung und Organisation der Bestandsaufnahme (Requirements Engineering), Planung, Schulung/Training) mit werkvertraglichen Bestandteilen (Installation, Realisierung von Schnittstellenanbindung). Mit der kaufrechtlich einzuordnenden Anpassungsleistung umfasst die vertragliche Gestaltung bei Anpassung, Einführung und Implementierung von Standardsoftware also kauf-, dienst-, und werkvertragliche Elemente. Ist auf eine solche Gemengelage dreifaches und unterschiedliches Recht anzuwenden oder gibt eine der vertraglichen Hauptleistungspflichten oder der vertraglichen Nebenleistungspflichten dem Vertrag das nachhaltige Gepräge? Diese Frage wird sich nicht pauschal beantworten lassen. gg) Verträge über die Anpassung, Einführung und Implementierung von Standardsoftware als gemischte Verträge Literatur und Rechtsprechung haben zu Verträgen, die nicht eindeutig ei- 112 nem Vertragstyp zuzuordnen sind, unterschiedliche Theorien entwickelt. Zu unterscheiden ist zunächst zwischen „zusammengesetzten“ und „gemischten Verträgen“1. Der zusammengesetzte Vertrag (Kombinationsvertrag) besteht aus mehreren an sich selbständigen und voneinander unabhängigen Einzelvereinbarungen, die zu einem einheitlichen Gesamtvertrag zusammengefasst und kraft Parteiwillens voneinander abhängig sind. Die rechtliche Würdigung des Kombinationsvertrags bestimmt sich nach dem Kombinationsprinzip, so dass für jede Leistung die ihr gemäßen Vertragsvorschriften gelten2. Gemischte Verträge unterscheiden sich von zusammengesetzten Verträgen 113 dadurch, dass die einzelnen Leistungspflichten so eng mit einander verknüpft sind, dass sie nicht voneinander getrennt werden können, ohne dass das Gesamtgefüge zerstört würde3. Die Abgrenzung ist im Einzelfall 1 Erman/Kindl, Vor § 311 BGB, Rz. 15 ff.; Palandt/Heinrichs, Überblick vor § 311 BGB Rz. 15 ff., s. Kap. D Rz. 81 ff. 2 Beck’scher Online Kommentar, 2012, § 311 Rz. 22. 3 Beck’scher Online Kommentar, 2012, § 311 Rz. 21: „Der gemischte Vertrag zeichnet sich durch eine nicht in selbstständige Abreden trennbare Verschmelzung mehrerer Vertragstypen in einen Vertrag neuer Art aus, weist also Elemente verschiedener (typischer und atypischer) Verträge auf. Die wesentliche Schwierigkeit ist in dem anwendbaren Recht zu erblicken, ob also in die Regeln der ein oder anderen Vertragsart den Vorzug verdienen. Die als Lösung entwickelten Konzepte – die Absorptionstheorie erklärt das Recht der Hauptleistung für alle Vertragsbestandteile verbindlich, während laut Kombinationstheorie die den jeweiligen Komponenten entsprechenden Normen heranzuziehen sind – werden den vielfältigen Problemstellungen nicht gerecht. Vielmehr ist je nach Mischform ausgehend von Parteiwille, Sinn und Zweck des Vertrages im Einzelfall ein interessengerechter Ausgleich zu suchen … Bei Normwidersprüchen ist auf den Schwerpunkt des Vertrages abzustellen.“

Witzel

649

G Rz. 114

Sonderregelungen

schwierig, auch mag der Parteiwille nicht immer in die gleiche Richtung gehen. Für den Anwender ist bei Anpassung, Einführung und Implementierung die Marschrichtung klar; aus seiner Sicht werden die unterschiedlichen Leistungen miteinander stehen und fallen. Kann die Software nicht funktional angepasst und nicht in seine Unternehmensstruktur implementiert werden, wird der Anwender kaum Interesse an sonstigen Leistungen des Softwareanbieters haben. 114

Der Softwareanbieter wird seine Leistungen rechtlich unabhängig voneinander regeln wollen, bevorzugt mit getrennten kaufrechtlichen, werkvertraglichen und dienstvertraglichen AGB. Eine Aufteilung in unterschiedliche Vertragsdokumente scheint aber wenig hilfreich zu sein, wenn sich die Auffassung des OLG Köln1 durchsetzt und aus einer Aufteilung vertraglicher Leistungen in verschiedene Programmscheine ein einheitlicher Werkvertrag wird. Die Abbildung eines komplexen Langzeitprojekts über standardisierte Vertragsbedingungen scheint ohnehin fraglich, die Tendenz der Gerichte zu einer undifferenzierten Anwendung des Werkvertragsrechts – gestützt auf die auch nach der Entscheidung des BGH vom 23.7.2009 unterschiedliche Meinungsbildung – empfiehlt eine möglichst individuelle Gestaltung des Vertrags2, in der sich die sich aus dem Werkvertrag ergebenden Risiken zu Lasten des Softwareanbieters abmildern lassen.

115

Die Leistungen im Rahmen eines Projekts über Anpassung, Einführung und Implementierung einer Standardsoftware sind eng miteinander verzahnt: Es mag Fälle geben, in denen der Anwender eine Standardsoftware in einer vom Softwareanbieter vorgegebenen Standardparametrisierung nutzen kann, aber der Regelfall wird der sein, dass zusätzliche Leistungen zwingend erforderlich sind, um die Standardsoftware für den Anwender einsatzfähig zu machen. Wie auch von Habel/Rauch3 zutreffend angenommen, ist bei der Frage, ob ein gemischter Vertrag oder ein zusammengesetzter Vertrag vorliegt, in erster Linie auf den Parteiwillen abzustellen. Soweit der Parteiwille nicht geäußert ist, wird man nach dem Zweck des Vertrags entscheiden und diesen sowohl aus den getroffenen Vereinbarungen, als auch aus den gesamten Umständen erschließen müssen. Dabei dürfen die einzelnen Verpflichtungen nicht isoliert betrachtet werden, vielmehr entscheidet die Gesamtrichtung des Vertrags4. Die Zielsetzung eines Projekts über Anpassung, Einführung und Implementierung einer Standardsoftware spricht dafür, in vielen Fällen von einem gemischten Vertrag auszugehen. Daran ändert auch die Entscheidung des BGH vom 23.7.2009 zu § 651 BGB nichts.

116

Darüber, wie ein gemischter Vertrag rechtlich zu typisieren ist, gibt es verschiedene rechtliche Theorien:

1 2 3 4

OLG Köln v. 4.11.2002 – 19 U 27/02, CR 2003, 246. So im Ergebnis auch Habel/Rauch, Technologieverträge, S. 5. S. Habel/Rauch, Technologieverträge, S. 10 ff. Erman/Kindl, Vor § 311 BGB Rz. 16 m.w.N.

650

Witzel

Implementierung von Standardsoftware

Rz. 117 G

– Die Absorptionstheorie, nach der das Recht der Hauptleistung insgesamt anwendbar sein soll. – Die Kombinationstheorie möchte die für den betreffenden Vertragsbestandteil maßgeblichen Rechtsnormen jeweils anwenden und bei sich ergebenden Gegensätzlichkeiten nach dem mutmaßlichen Parteiwillen ausgleichen. Dies kann zu erheblichen Abgrenzungsproblemen führen. – Die Theorie der analogen Rechtsanwendung nimmt an, dass das besondere Schuldrecht keine Regelung für Mischverträge enthält. Im Ergebnis soll deshalb wie bei der Kombinationstheorie vorgegangen werden, dies jedoch lediglich in analoger Anwendung. – Nach der Kommentierung bei Palandt/Heinrichs1 sollen für jede Leistung die Vorschriften des entsprechenden Vertragstyps herangezogen werden. Kollidieren die Vorschriften, soll das Recht des Vertragstyps heranzuziehen sein, der den rechtlichen Schwerpunkt bildet. Sind die Vertragstypen gleichwertig vertreten, sollen die Vorschriften entsprechend anzuwenden sein, die dem Vertragszweck am besten entsprechen. Dazu der BGH2: „Die Frage nach welchen Rechtsnormen ein gemischter Vertrag zu beurteilen ist, hängt von der besonderen Gestaltung der jeweiligen Interessenlage ab. Überwiegt ein Vertragsbestandteil und ist er deshalb für das Wesen dieses Vertrages prägend, so ist grundsätzlich das Recht dieses Bestandteil auch für den gesamten Vertrag entscheidend.“ Folgt man den Ausführungen des BGH, hat bei jedem gemischten Vertrag 117 eine individuelle Beurteilung des Schwerpunkts zu erfolgen. Für die Projekte zur Anpassung, Einführung und Implementierung von Standardsoftware hat dies folgende Konsequenzen: Je nach (individueller) Ausgestaltung des Vertrags kann der Schwerpunkt im Kauf-, Werk-, oder Dienstvertragsrecht liegen. Der Auffassung, dass der Softwareanbieter zwingend und unabhängig von der konkreten Struktur des Projekts einen Erfolg schuldet und auch zwingend die alleinige Projektverantwortung trägt, ist nicht zu folgen. Auch, wenn es unzweifelhaft ein Interesse des Anwenders an einer am Ende des Projekts lauffähigen Software gibt, muss dies nicht eine klare Zuordnung zum Werkvertrag bedeuten. Die Ausführungen zum Projektmanagement3, aber auch zur Mitwirkung des Anwenders4 machen deutlich, dass eine ausschließliche Risikozuweisung an den Auftragnehmer einem IT-Pro1 Palandt/Heinrichs, Überblick vor § 311 BGB Rz. 15 ff. 2 BGH v. 29.9.1994 – I ZR 172/92, MDR 1995, 711 = NJW 1995, 324 (326). Das OLG Düsseldorf führt in einer Entscheidung v. 13.1.2012 – 22 U 120/11, IBRRS 84967, Folgendes aus: 1. Wartungsverträge können als Werk-, Dienst- oder Mietverträge zu qualifizieren sein. Es handelt sich dabei stets um eine Einzelbetrachtung. 2. Teilweise ist es möglich, solche Verträge schwerpunktmäßig einem bestimmten Vertragstyp zuzuordnen. Teilweise ist es aber auch erforderlich, je nach betroffenem Regelungsgegenstand unterschiedliche Regelungen aus den Schuldverhältnissen anzuwenden. 3 S. Kap. H. 4 S. Rz. 215 ff.

Witzel

651

G Rz. 118

Sonderregelungen

jekt nicht gerecht wird. So setzt eine erfolgreiche Implementierung immer Änderungen in den organisatorischen Abläufen des Anwenders voraus; hier kann der Softwareanbieter beratend und unterstützend – also dienstvertraglich – tätig werden, eine ausschließliche Erfolgsverantwortung des Softwareanbieters ist nicht angemessen. 118

Gründe für die Annahme einer auch und in manchen Fällen überwiegend dienstvertraglichen Ausprägung eines Projekts gibt es viele: Der wohl überwiegende Teil der Projekte wird beherrscht von gemeinsamen Projektgremien, die paritätisch besetzt sind, und ist geprägt von einer gemeinschaftlichen Projektorganisation1. Anwender behalten sich als Auftraggeber auch das Letztentscheidungsrecht über Projektsteuerungsmaßnahmen und den tatsächlichen Leistungsumfang vor. Anpassungsprogrammierung erfolgt nach Weisung des Anwenders: Der Softwareanbieter arbeitet auf Zuruf. Der Softwareanbieter erklärt dem Anwender nur die in der Standardsoftware vorhandenen Möglichkeiten zum Customizing und zur Parametrisierung, die dazu eigentlich erforderlichen Leistungen werden von den Mitarbeitern des Anwenders erbracht. Ein besonderer Schwerpunkt in Projekten zur Anpassung, Einführung und Implementierung von Standardsoftware liegt im Bereich der Tests. Hier kann die Verantwortung ohne Weiteres beim Anwender liegen. Er muss die Testfälle beibringen und kann die Tests auch in eigener Regie – mit Beratung und Unterstützung des Softwareanbieters – durchführen.

119

Schneider bricht die Lanze für den Dienstvertrag2 – eine Auffassung, die überzeugen kann, da die Rolle des Anwenders in solchen Projekten wesentlich ausgeprägter sein muss als in normalen Werkverträgen. Auch Söbbing sieht zumindest bei Projekten, die einem Prototyping-Modell folgen, den Anwendungsbereich für den Dienstvertrag eröffnet3. Es ist weiterhin zu bedenken, dass die Schuldrechtsreform die Konsequenzen für die Schlechtleistung des Schuldners stark angeglichen hat. Es fehlt beim Dienstvertrag zwar an einer „Gewährleistungsregelung“, über die § 280 BGB hat der Anwender jedoch auch im Dienstvertragsrecht ein Instrumentarium, um den Softwareanbieter in die Pflicht zu nehmen. Bei Scheitern eines Projekts wird der Softwareanbieter auch über schlechte und unzureichende Beratung stol-

1 Aus der einschlägigen Literatur zum Projektmanagement ergibt sich, dass dies auch interessengerecht und dem Erfolg des Projekts zuträglich ist. 2 Schneider, Softwareerstellung und Softwareanpassung – Wo bleibt der Dienstvertrag?, Ein Plädoyer für die Einordnung von Verträgen zur Anpassung – Änderung von Software als Dienstvertrag und zugleich Anmerkungen zu OLG Karlsruhe CR 2003, 317. Eine weitere Entscheidung des OLG Karlsruhe v. 24.10.2007 – 7 U 214/06 – eröffnet Raum für die Anwendung von § 611 BGB: Auch für Verträge, in denen sich eine Partei zur Erbringung von Forschungs- und Entwicklungsleistungen verpflichtet hat, ist für die Abgrenzung zwischen einem Dienstvertrag und einem Werkvertrag maßgeblich darauf abzustellen, ob der Auftragnehmer einen bestimmten Erfolg versprochen hat. 3 Söbbing, Die rechtliche Aspekte von IT-Projekten, MMR 2010, 222.

652

Witzel

Implementierung von Standardsoftware

Rz. 122 G

pern, wenn keine Erfolgsverantwortung zu seinen (ausschließlichen) Lasten besteht. Die Diskussion zur vertragstypologischen Einordnung zeigt, dass die Ver- 120 tragspartner um eine individuelle Gestaltung ihrer Projektverträge nicht herum kommen, um eine interessengerechte und angemessene Lösung für ihr konkretes Projekt zu finden. Eine werkvertragliche Gestaltung kann passen, wenn die Steuerung überwiegend beim Softwareanbieter liegt. Eine solche Konstellation wird häufig bei mittelständischen Anwendern günstig sein, die weder über das Know-how noch über die Ressourcen zur eigenverantwortlichen Steuerung eines Projekts verfügen. Bei Großkonzernen als Anwendern kann der Schwerpunkt von vielen Projekten im Dienstvertrag liegen, da diese über eigene IT und eigenes Projektmanagement verfügen. Denkbar ist schließlich auch eine Regelung, die Dienst- und Werkvertrag vermischt: Der Anwender trägt die Verantwortung für die Leistungsbereiche, die nur in seiner Sphäre durchgesetzt werden können (Umsetzung der erforderlichen Implementierungsmaßnahmen), den Softwareanbieter trifft eine werkvertragliche Erfolgsverantwortung, beispielsweise bei der Add-onEntwicklung. Notwendig ist, dass die vertragliche Vereinbarung vor allem folgende Ele- 121 mente enthält: – Regelungen zur Festlegung, aber auch Fortschreibung der Definition und des Umfangs des Vertragsgegenstands, wie zum Beispiel Aufgaben und Aktivitäten des Softwareanbieters, Funktionalität der Standardsoftware, Anforderungen des Anwenders an die angepasste Software, Lieferumfang, Leistungsdaten, andere technische Eigenschaften, Nutzen, Qualitätskriterien, Nebenleistungen; – Regelungen zur Handhabung von Änderungen des Leistungsumfangs; – Definition des Projektverlaufs und der Projektorganisation wie Projektphasen, Termine, Projektgremien, Kommunikation, Abnahmen; – Regelungen zur kaufmännischen Projektabwicklung, z.B. zu Zahlungen, Bürgschaften, Versicherungen, Zinsregelungen; – Vertragsrechtliche und juristische Projektbegleitung, z.B. hinsichtlich Verzug, Mängeln, Selbstvornahmen, Abnahmen, Vertragsstrafen, Verjährung; – Verantwortungsabgrenzung, Abwicklung und Folgen bei Leistungsstörungen, Pönalen und Schadensersatz. 3. Probleme in Projekten über die Einführung und Implementierung von Standardsoftware und Konsequenz für die Vertragsgestaltung a) Ursachen für das Scheitern eines Projekts Nicht nur Projekte über Individualentwicklungen, sondern auch Projekte 122 über Anpassung, Einführung und Implementierung von Standardsoftware Witzel

653

G Rz. 123

Sonderregelungen

scheitern. Ein Projekt befindet sich in einer Schieflage, wenn eines der nachfolgenden Kriterien erfüllt ist1: – Fehlen wesentlicher Funktionen, die für die Erreichung der Projektziele notwendig sind; – Verfehlen der angestrebten Qualität; – Überschreitung von Terminen; – Überschreitung der Ressourcen. Im Chaos-Report wurde 1995 von der Standish-Group eine Untersuchung von 8000 IT-Projekten veröffentlicht: 31 % aller IT-Projekte wurden abgebrochen, 42 % aller IT-Projekte dauern doppelt so lange, kosten das Doppelte und liefern nur die Hälfte der geforderten Funktionalität (= Kostenfaktor 4), nur 16 % aller IT-Projekte sind termingerecht, im Budget und liefern annähernd das Gewünschte. 123

Eine neue Studie von McKinsey und der Saïd Business School der University of Oxford2 verwendet für gescheiterte Projekte den Begriff des „Schwarzen Schwans“ und bezeichnet damit Projekte, die ihr Budget um mehr als 200 % überziehen und 70 % mehr Zeit kosten als geplant. Während bei Projekten in anderen Bereichen ein solches „Aus-dem-Ruder-Laufen“ vielleicht eher die Ausnahme ist, ist die Wahrscheinlichkeit bei IT-Projekten um 30 % höher. Nach den Forschungsergebnissen der Universität und des Unternehmensberaters sind 12 % bis 18 % der IT-Projekte „Schwarze Schwäne“. Selbst von den IT-Projekten, in denen fast alles richtig gemacht wurde, endete jedes zehnte im „schwarzen Bereich“3.

124

Es sind keineswegs nur IT-Projekte kleinerer oder mittlerer Softwareanbieter oder IT-Projekte mittelständischer Auftraggeber, die scheitern. In der Presse finden sich vielfältige Beispiele, die prominente Unternehmen tref-

1 Kellner, Die Kunst, IT-Projekte zum Erfolg zu führen; Streitz, IT-Projekte retten; Zahrnt, Probleme bei DV-Projekten, CR 2000, 402; von Gersdorff, Was in IT-Projekten warum schief gehen kann, Computerwoche 38/11. 2 Quack, Zu viele IT-Projekte sind „Schwarze Schwäne“, Computerwoche 38/11. 3 Hierbei ist aber zu beachten, dass das Scheitern auch auf von der Software losgelösten Gründen beruhen kann, vgl. Quack/Hackmann, Computerwoche v. 9.5.2012, http://www.computerwoche.de/a/wenn-die-sap-einfuehrung-einfachverpufft,1234982: Wenn die SAP-Einführung einfach verpufft: „Eine Analyse zeigt, dass dafür [Anm: für das Scheitern] meistens nicht die Software verantwortlich ist, sondern die fehlende Konsequenz auf Seiten des Unternehmens. Denn nach wie vor sind viele SAP-Projekte IT-getrieben, und die Projektverantwortlichen verlieren aus den Augen, den angestrebten Nutzen zu realisieren.“ Oftmals scheitern Projekte auch an unzulänglicher Beratung im Vorfeld des Projekts, vgl. Kurzlechner, Computerwoche v. 4.2.2013, http://www.computer woche.de/a/warum-erp-projekte-scheitern,2532082: Warum ERP-Projekte scheitern: „38 Prozent der Befragten machen falsche Beratung für das Scheitern von ERP-Projekten verantwortlich.“

654

Witzel

Implementierung von Standardsoftware

Rz. 124 G

fen, allein ein Blick in die öffentliche Verwaltung offenbart etliche schwarze Schwäne1: – A2LL in der Arbeitsverwaltung: A2LL wurde von der T-Systems auf Basis einer Standardsoftware für die Sozialverwaltung der Prosoz Herten GmbH ab Anfang 2004 für die Bundesagentur für Arbeit entwickelt. Hintergrund waren die sog. Hartz-Reformen, in Folge derer die neu geschaffenen Arbeitsagenturen und Arbeitsgemeinschaften zwischen der Agentur und den Kommunen mit einem komplett neuen Softwaresystem ausgestattet werden mussten. Im ersten Jahr nach der Produktivsetzung (2005) brach A2LL ein- bis zweimal pro Woche zusammen. Dies führte dazu, dass die Sachbearbeiter das System entweder überhaupt nicht oder nur mit indiskutablen Antwortzeiten benutzen konnten. Es musste provisorisch gearbeitet werden, etwa mussten Schecks per Hand ausgefüllt und an Leistungsempfänger übergeben werden. Solche Vorgänge mussten dann im Nachgang erfasst werden. Der Bund der Steuerzahler berichtete in seinem Schwarzbuch „Die öffentliche Verschwendung 2006“, dass die fehlerhafte Software der Bundesagentur dazu geführt habe, dass monatelang den Krankenkassen zu hohe Beiträge für Arbeitslosengeldempfänger überwiesen wurden. Der Schaden betrug 23 Mio. Euro. – 2003 wurde DiPlaZ (Dienstplanungs- und Zeitwirtschaftssystem für die bayerische Polizei) ausgeschrieben. Mit dem System sollten 40 000 Anwender arbeiten, es wurde mit 1000 gleichzeitigen Benutzern gerechnet. Den Auftrag erhielt die Firma P&I AG in Wiesbaden im Februar 2004 mit dem Terminziel Mitte 2005. Im Januar 2005 plante man einen Start im ersten Quartal 2006. Im März 2005 musste der Flächenpilot verschoben werden. Nach dem Start eines Modellpiloten im Oktober 2005 wurden solche Mängel sichtbar, dass der Termin für den Flächenpilot erneut verschoben werden musste. Auch im Jahr 2006 kam es zu wiederholten Verschiebungen in Folge von Softwarefehlern und Instabilitäten. Im Testbetrieb gingen bereits erfasste Daten verloren. Im April 2007 kam man zu dem Ergebnis, dass das System für einen flächendeckenden Einsatz nicht geeignet ist. Das Projekt wurde beendet. – Die Metropolregion Nürnberg plante eine dritte fahrerlose U-Bahn-Linie mit der Besonderheit, dass diese streckenweise auf den gleichen Gleisen und in den gleichen Tunnels wie die fahrergesteuerte U-Bahn verkehren sollte. Das Projekt sollte von der Siemens AG realisiert werden, da diese sowohl Fahrzeuge als auch Leittechnik anbieten konnte. Anfang 2006 erkannte Siemens, dass die ursprüngliche Software-Architektur weitgehend neu gestaltet werden musste. Das Terminziel, das zunächst im März 2006 lag, wurde weit verfehlt. Erst Anfang 2008 fuhren die ersten Testzüge auf den dafür vorgesehenen Gleisen.

1 Mertens, Fehlschläge bei IT-Projekten in der öffentlichen Verwaltung, Arbeitspapier Nr. 1/2009, www.wi1-mertens.wiso.uni-erlangen.de/veroeffentlichungen/ download.

Witzel

655

G Rz. 125 125

Sonderregelungen

Auch im nicht-öffentlichen Bereich machen gescheiterte Projekte namhafter Anbieter regelmäßig Schlagzeilen1: – Der Technologie-Distributor Ingram Micro meldete für das erste Quartal 2011 einen massiven Gewinneinbruch von 70 auf 56 Millionen Dollar. Laut Unternehmen sei dies in erster Linie auf Schwierigkeiten mit einem neuen Enterprise System in Australien zurückzuführen, wo man gerade eine SAP-Software einführte. – Whaley Foodservice Repairs, ein auf Restaurant-Zulieferung und Kältetechnik spezialisiertes Unternehmen, sollte am Schluss einer ERP-Einführung von Epicor gleich fünfmal mehr bezahlen als zu Beginn budgetiert. Ursprünglich war ein Projektbudget von knapp 200 000 US-Dollar geplant, tatsächlich kostete die Einführung dann mehr als 1 000 000 USDollar. – In der kanadischen Provinz Nova Scotia erhielten die bei der Non-Profit Organisation Victorian Order of Nurses beschäftigten Krankenschwestern und Pfleger ein halbes Jahr lang falsche Gehaltsschecks. Die Ursache hierfür lag in einem Pay-Roll-System von SAP, das Berater von IBM fehlerhaft eingeführt hatten. Nachdem das Abrechnungssystem produktiv gesetzt worden war, bekamen einige Mitarbeiter doppelt so viel Geld wie erwartet, andere wiederum fühlten sich bei der Abrechnung übers Ohr gehauen. Die Lösung selbst war solide und stabil, doch offenbar hakte es bei der konkreten Einführung.

126

Anwaltliche Berater werden von Vertrieb und auch Einkauf gerne als „Umsatzverhinderer“ und „Reichsbedenkenträger“ in die Schranken verwiesen, aber die Beispiele prominenter Softwareanbieter und Anwender machen deutlich, dass die Warnhinweise eine handfeste Grundlage haben und Risiken sich nicht nur dann manifestieren, wenn kleine Unternehmer und weniger etablierte Produkte involviert sind.

127

Ursachenforschung für das Scheitern von Projekten zeigt, dass Schwierigkeiten in IT-Projekten auf einer mangelhaften Zusammenarbeit von Anwendern und Softwareanbieter beruht. Anwender unterliegen häufig dem Irrtum, ihre Mitarbeit sei nebensächlich und übersehen, dass gerade die Mitwirkung entscheidend für den Projekterfolg ist. Neben fehlenden vertraglichen Grundlagen, die Grundsätze zur Zusammenarbeit festschreiben, werden auftauchende Probleme insbesondere auf folgende Ursachen zurückzuführen sein: – unrealistische Aufwandsschätzungen durch den Projektsponsor; – Festpreisprojekte ohne Anpassungs- und/oder Ausstiegsmöglichkeit im Vertrag; – unrealistische Zeitvorgaben;

1 www.cio.de/knowledgecenter/erp/2299746/index.html: Die 10 größten ERP-Pannen 2011.

656

Witzel

Implementierung von Standardsoftware

Rz. 128 G

– mangelnde Erfahrung mit der anzupassenden/zu entwickelnden Software im Projektteam; – fehlende Qualitätssicherung; – fehlende Risk Management Prozeduren; – fehlendes Pflichtenheft und Systemarchitektur; – unrealistische Zusagen zum Funktionsumfang oder zur Möglichkeit zur Umsetzung von Anforderungen; – keine echten Meilensteinabnahmeprozesse im Projektverlauf; – Konflikte zwischen Projektsponsor und Projektteam; – schlechte Kommunikationskultur zwischen Projektteam, Projektleiter sowie dem Anwender; – keine dem Projekt ganz zugeordneten Mitarbeiter; – mangelnder Support durch das Top Management auf Seiten des Anwenders. b) „Das Schicksal von Großprojekten … oder warum sie scheitern“ Die aufgelisteten Schlagworte lassen sich mit dieser in IT-Kreisen bekannten Glosse anschaulich machen: Das Schicksal von Großprojekten … oder warum sie scheitern Die Entscheider (ob Manager/CEOs/COOs oder Politiker) sind keine EDVProjektleiter, sondern Theoretiker, die ihr Managementwissen aus BWL-Büchern haben. Sie denken sich etwas aus und lassen dies von irgendeiner Consultingfirma als Studie formulieren, die beweist, dass das Projekt für X Euro in Y Jahren machbar ist. Dann denken sie: Das kann doch nicht X Euro kosten und Y Jahre dauern! Das können wir besser. Wofür haben wir Managementbücher gelesen, „die Macht der Triade“ studiert, die Kriegsregeln der Chinesen studiert oder uns mit Feng Shui beschäftigt. Dann halbieren sie X und Y und erklären das zum „ambitionierten“ Projektziel. Dann machen sie eine Ausschreibung mit diesen Vorgaben. Wer sagt, dass das für X/2 Euro in Y/2 Jahren nicht geht, fliegt aus dem Bieterfeld. Dann starten sie das Projekt mit dem Bieter, der die besten Powerpointfolien gezeigt hat, die meisten Business-Buzzwords benutzt hat und außerdem versichert hat, dass er das Projekt zu den angegebenen Bedingungen auf jeden Fall „in time in budget according to specification“ abschließen wird, wie sämtliche Projekte, die man bisher bereits erfolgreichst zur höchsten Zufriedenheit der Kunden durchgeführt hat. Während des Projekts wird klar, dass die interne Vorbereitung denkbar unzureichend war, die Fachabteilung nicht richtig einbezogen wurde und die Vorstudie nicht zur realen Aufgabenstellung passt bzw. nur 30 % abdeckt. Die Anforderungen werden während der Projektlaufzeit erhöht. Teils mit dem Argument „das ist doch klar, dass wir das brauchen“ dem AuftragnehWitzel

657

128

G Rz. 128

Sonderregelungen

mer aufgedrückt, teils als Change Request eingebracht, wenn der Auftragnehmer die neuen Anforderungen sonst ums Verrecken nicht akzeptieren will. Wenn Y/2 erreicht ist und X/2 Euro verbraucht, aber erst 40 % der ursprünglichen und 25 % der erweiterten Anforderungen erfüllt sind, kommen die ersten Krisenzeichen: Projektbeteiligte, die ständig auf die Probleme hingewiesen haben, werden zu Schuldigen erklärt, gemaßregelt oder gefeuert. Es werden weitere Externe zur „Verstärkung“ und „Beschleunigung“ hinzugenommen. Wenn Y erreicht ist und 1,5 X Euro ausgegeben sind, muss der Projektmanager beim Topmanager antreten. Danach wird Beraterfirma C beauftragt, die Lage zu analysieren. Die stellt schwere Mängel fest, gibt die Schuld allen möglichen Beteiligten (Programmierer, Auftragnehmer, Fachabteilung etc.) außer den Auftraggebern (Manager) und schlägt vor, das Projekt funktional zu reduzieren sowie an einigen Stellen eigene Mitarbeiter zu platzieren, die den anderen „auf die Finger“ sehen. Nach 2Y Jahren und 3X Euro Kosten werden 60 % der Funktionspunkte erreicht. Die Software wird nun offiziell live gestellt, tatsächlich aber nur mit Workarounds oder gar nicht genutzt. Nach 2,5 Y Jahren und 4X Euro Kosten sind 65 % erreicht, die Software ist benutzbar und wird zu einem grandiosen Erfolg erklärt. Die internen Mitarbeiter haben zahlreiche Überstunden geleistet und schon lange keinen Urlaub mehr gemacht, sind ausgebrannt und kaputt. Das Management trifft sich und überlegt, wie die ineffiziente Bande der Angestellten, die sich auf Kosten des Unternehmens durchschmarotzt, mehr motiviert werden kann und wie man künftig solche Fiaskos vermeidet. Beschlossen werden einige oder alle der folgenden Maßnahmen: – Entlassung eines Teils der Mitarbeiter, um Kosten zu sparen. – Streichung des Weihnachtsgeldes und Beförderungsstopp auf den untersten zwei Ebenen. – Reduzierung der Beraterstundensätze um 10 %. – Vorgaben, dass beim nächsten Projekt gleich zu Beginn noch ambitionierter geplant werden muss, d.h. es müssen Y/3 Jahre und X/3 Euro Kosten angesetzt werden, da man ja nun weiß, dass der Planungsrahmen um 150 % überschritten werden wird. – Erhöhung der Gehälter des oberen Managements um 50 %.

658

Witzel

Implementierung von Standardsoftware

Rz. 130 G

III. Leistungen des Softwareanbieters im Rahmen der Anpassung und Einführung (Implementierung) von Standardsoftware 1. Sondierung und Projektumsetzung Entscheidet sich ein Anwender, seine Geschäftsprozesse durch Standard- 128a software zu unterstützen bzw. abzubilden, hat er ein Projekt1 vor sich, das in zwei „Grobphasen“ unterteilt werden kann: In einer ersten Phase der Sondierung wird der Anwender den Markt sondieren und die einzelnen potentiellen Softwareanbieter prüfen; dies in Eigenregie oder mit Unterstützung einer Unternehmensberatung. Nach einer Grobsichtung des Markts, Anfragen an die Softwareanbieter (ggf. mit Erstellung einer Machbarkeitsstudie), finden meist Präsentationen der in Betracht kommenden Bieter statt, die schließlich mit der Wahl eines Softwareanbieters enden. Dann schließt sich die Umsetzung, d.h. die Konzeptionierung, Anpassung, Einführung und Implementierung der ausgewählten Standardsoftware mit einer Abfolge an, die typischerweise aus den folgenden Phasen besteht: In einem ersten Schritt werden die Geschäftsprozesse des Anwenders analysiert. Dann wird entschieden, ob der Prozess wie gehabt beibehalten oder verändert werden soll. Erst wenn die Geschäftsprozesse samt ihrer Schnittstellen innerhalb des Unternehmens, zu Lieferanten und Kunden modelliert sind, werden die Geschäftsprozesse in der Software abgebildet, die Software wird angepasst. Nach einer Testphase kann der Echtbetrieb starten. Zu den einzelnen Projektphasen und der Vorgehensweise in Projekten s. Kap. H. 2. Einzelne Leistungen des Anbieters im Rahmen von Anpassung und Implementierung Ablauf und Leistungen der Sondierungsphase sind nicht Gegenstand dieses Kapitels, die Darstellungen zur Vertragsgestaltung beziehen sich ausschließlich auf die Umsetzungsphase; der Softwareanbieter ist bereits ausgewählt.

129

a) Einzelne Leistungen im Überblick Die vertraglichen Vereinbarungen müssen zur Vermeidung von Auseinan- 130 dersetzungen zum einen eine fachliche Beschreibung der Anforderungen an die anzupassende Standardsoftware (im Folgenden auch „Anforderungsbeschreibung“) umfassen, zum anderen eine Darstellung der Leistungen, die der Softwareanbieter zur Umsetzung dieser fachlichen Anforderungen zu erbringen hat (im Folgenden auch „Leistungsbeschreibung“). Da ein Projekt nicht nur die Anpassung der Standardsoftware an sich, sondern auch die erforderliche Einführung und Implementierung zum Gegenstand hat, 1 S. auch Kap. D Rz. 42 ff.

Witzel

659

G Rz. 131

Sonderregelungen

sind auch die Leistungen, die in diesem Zusammenhang anfallen, zu beschreiben. Eine abschließende Festlegung und Beschreibung der Leistungen ist im Hinblick auf Komplexität und Projektlaufzeit in der Regel nicht möglich. Die Beschreibung im Vertrag kann nur einen Überblick geben; auch die dem Vertrag beigefügte Leistungsbeschreibung ist zwangsläufig Gegenstand weiterer Detaillierung und Feinspezifizierung. 131

Eine den Interessen beider Seiten gerechter werdende Formulierung einer Leistungsbeschreibung, die von einem einheitlichen Vertrag ausgeht, könnte in etwa wie folgt aussehen:

Der Vertragsgegenstand umfasst insbesondere folgende Leistungen: – Lieferung, sowie – Konzeptionierung und Implementierung mit Parametrisierung, Anpassung und Erweiterung, und – Pflege eines (…)-systems, – zusammen mit den für den Betrieb eines solchen Systems erforderlichen Maßnahmen, zum Beispiel Projektmanagement, Durchführung von Schulungen etc., – Projektierung und Planung des erforderlichen Hardwareeinsatzes, und – die Optimierung von vorhandener Hardware bzw. Dimensionierung, Auswahl und Einführung noch zu beschaffender Hardware und Netzwerkstrukturkomponenten. Zu den Leistungen des Auftragnehmers gehört auch die Erstellung der folgenden Konzepte: – – – –

fachliches und (soweit erforderlich) technisches Feinkonzept Einführungskonzepte Migrationskonzept Schulungskonzept

Der genaue Umfang der vom Auftragnehmer zu erbringenden Leistungen ergibt sich aus Ziffer (…) des Vertrages sowie den in Bezug genommenen Anlagen.

132

Besonderes Augenmerk sollte auf der referenzierten detaillierten Leistungsbeschreibung für die Aktivitäten des Softwareanbieters sowie der Funktionalität des zu implementierenden Systems liegen1. Letztere Anforderungsbeschreibung sollte die Anforderungen des Anwenders so präzise wie möglich erfassen und Folgendes enthalten: – Beschreibung der funktionalen Anforderungen; – Beschreibung der nicht-funktionalen Anforderungen, wie Leistungswerte, Verfügbarkeit und Performance-Kriterien; 1 Dazu ausführlich unter Rz. 182.

660

Witzel

Implementierung von Standardsoftware

Rz. 134 G

– Meilensteine, falls diese sich nicht aus einem gesonderten Projektplan ergeben; – Abnahmekriterien, die auf den funktionalen und nicht-funktionalen Anforderungen beruhen sollten; – Testszenarien und Testfälle, die zur Feststellung dienen, ob die Abnahmekriterien erfüllt sind; – Details zur Projekt- und Produktdokumentation. b) Einzelne Leistungen im Detail aa) Lieferung der Standardsoftware Unabhängig von der Vertragskonstellation – die Lieferung der Standardsoft- 133 ware mag Gegenstand eines gesonderten Vertrags sein – spielt die Lieferung und Überlassung1 der Standardsoftware im Rahmen von Projekten über Anpassung, Einführung und Implementierung eine erhebliche Rolle. Die Standardsoftware stellt die Grundlage der einzuführenden und zu implementierenden Lösung dar. Des Weiteren bildet die Standardsoftware auch die Basis für die Abbildung der Geschäftsprozesse des Anwenders. Zu regeln ist, welcher Versionsstand (welches Release) Gegenstand der Lieferung sein soll. Des Weiteren sollte im Vertrag beschrieben werden, in welcher Form geliefert wird. Nach dem aktuellen Stand der Technik ist eine Lieferung auf Datenträger die Ausnahme und gilt als veraltet2. Meist wird die zu liefernde Software per Fernzugriff direkt auf den Systemen (im Regelfall Testsystemen) eingespielt oder der Anwender lädt sich die Software selbst vom FTPServer des Anbieters herunter. Teilweise wird Software auch als E-Mail-Anhang ausgeliefert. Die Form der Lieferung kann erhebliche Auswirkungen haben. Nach dem 134 Vorlagebeschluss des BGH vom 3.2.2011 zur Gebrauchtsoftware neigt der BGH3 der Auffassung zu, dass bei Online-Übertragung der Erschöpfungsgrundsatz nicht zur Anwendung kommt. Die Softwareanbieter können die Grundsätze, die der BGH in seinem Vorlagebeschluss aufstellt, in ihrem Interesse nutzen, zumal sich der BGH auch in einem Nebensatz dahingehend geäußert hat, dass die von Oracle verwendeten Weitergabeverbote greifen. Ein Anwender, der sich die Möglichkeit der Weitergabe der gelieferten Software vorbehalten will, sollte also in der vertraglichen Regelung darauf bestehen, dass er zumindest zusätzlich einen Datenträger mit der Software erhält.

1 Zur Rechtseinräumung s. Rz. 293 ff. 2 Komplexe Systeme sind häufig auch zu groß für die Speicherung auf DVDs oder CD-ROMs. 3 BGH v. 3.2.2011 – I ZR 129/08, CR 2011, 223 = MMR 2011, 305 m. Anm. Heyden; Rinkler, ITRB 2011, 234; Rössel, CR 2011, 227; Witzel, CRi 2011, 47; WolffRojczyk/Hansen, CR 2011, 228.

Witzel

661

G Rz. 135

Sonderregelungen

bb) Erstellung eines Pflichtenhefts/einer Feinspezifikation über erforderliche Änderungen und/oder Ergänzungen der Standardsoftware 135

An der Notwendigkeit eines Pflichtenhefts/einer Feinspezifikation1 besteht kein Zweifel, da hierin die Grundlage für die Bewertung einer vertragsgemäßen Leistung hinsichtlich der angepassten und implementierten Standardsoftware liegt. Für die Erstellung von Pflichtenheft und/oder Feinspezifikation gibt es keine festen Regeln, die genaue Gestaltung hängt vom individuellen Projekt ab2. Der zwischen Softwareanbieter und -anwender geschlossene Vertrag sollte die Aufgabenverteilung festlegen: Wer erstellt das Pflichtenheft und die Feinspezifikation und wer hat in welcher Vorgehensweise die fachlichen Vorgaben – sprich den Inhalt – zu liefern.

136

Eine Formulierung, mit der die Verantwortung für einzelne Aufgabenbereiche zugewiesen wird, könnte wie folgt aussehen:

Der Auftragnehmer erbringt in der Konzeptionierungsphase bis zur Erstellung des Pflichtenhefts folgende Leistungen: – Bereitstellung und Installation einer Testinstallation der Standardsoftware xy mit einer Grund-Parametrisierung als Basis für die Durchführung von Workshops mit den Mitarbeitern des Anwenders; – Durchführung einer Grundschulung in die Basisfunktionalität der Standardsoftware xy; – Organisation und Durchführung von Workshops zur Erarbeitung der Anforderungen des Anwenders; – Darstellung der Anforderungen des Anwenders in Workshop-Protokollen und Übermittlung der Workshop-Protokolle zur Freigabe an den Anwender; – Erstellung eines Entwurfs des Pflichtenhefts auf Basis der freigegebenen Workshop-Protokolle und Vorlage des Entwurfs an den Anwender zur Prüfung und Abnahme; – Übermittlung von Vorschlägen für Testfälle;

1 Zu Leistungsbeschreibung, Pflichtenheft und Feinspezifikation s. im Detail Kap. C Rz. 1 ff. 2 Zum Beispiel bei ERP-Systemen ist die Erstellung des Pflichtenhefts abhängig vom Grad der Komplexität des Gesamtprojekts. So Sontow, Computerwoche v. 19.3.2012, http://www.computerwoche.de/a/so-kommen-sie-auf-den-erp-trichter, 2494295,4: So kommen Sie auf den ERP-Trichter: „Je mehr Unternehmensbereiche und/oder Standorte mit der neuen Software arbeiten sollen, umso vielfältiger werden meist die Anforderungen an eine neue ERP-Lösung. Daher ist eine stärkere Systematisierung der ERP-Auswahl zu empfehlen, je komplexer sich ein ERPProjekt darstellt. Zentrale Bedeutung für die Abstimmung innerhalb des Unternehmens kommt in diesem Fall dem Lasten-/Pflichtenheft zu. Umgekehrt gilt, dass bei kleineren ERP-Projekten weniger formale Ansätze bei geringerem Aufwand in der Regel auch zum Ziel führen.“

662

Witzel

Implementierung von Standardsoftware

Rz. 138 G

– Durchführung von Workshops zum Datenmapping und falls erforderlich Prototyping einer rudimentären Datenmigration. Der Auftraggeber erbringt in der Konzeptionierungsphase bis zur Erstellung des Pflichtenhefts folgende Mitwirkungsleistungen: – Bereitstellung der vereinbarten IT-Infrastruktur für eine Testinstallation; – Teilnahme der Key-User an der Grundschulung zur Nutzung der Standardsoftware xy; – Teilnahme der Key-User an Workshops zur Erarbeitung der Anforderungen sowie an Workshops zum Datenmapping mit inhaltlich aktiver Beteiligung an allen Workshops; – Übermittlung von vollständigem und qualifiziertem Feedback in Textform zu allen Workshop-Protokollen mit Anforderungsbeschreibungen und Entwürfen des Pflichtenhefts; – Bereitstellung von aussagekräftige Vorlagen zu umzusetzenden Formularen, Berichten, Layouts, Templates und zur Corporate Identity zur Verfügung; – Prüfung und Freigabe von Workshop-Protokollen; – Prüfung und Abnahme des Pflichtenhefts; – Prüfung und Ergänzung der Testfälle.

Dabei haben die Vertragspartner Folgendes im Hinterkopf zu behalten: Der 137 Vertragsgegenstand – respektive der Leistungsumfang – ist bei Beginn des Projekts und somit bei Vertragsschluss nicht klar umrissen: der Vertragsgegenstand und der Leistungsumfang werden sich ähnlich dem iterativen Prozess der Softwarenentwicklung voraussichtlich bis zum Abschluss des Projekts weiterentwickeln. In der zur Pflichtenheft-Erstellung notwendigen Analyse und Konzeptionie- 138 rung kommen folgende Aufgaben in Betracht, die in einer Leistungsbeschreibung detailliert werden können, wobei nur ein Teil der Aufgaben in der Verantwortung des Softwareanbieters liegen wird1: Analyse: – – – – – –

Identifikation der betroffenen Unternehmensbereiche; Ermittlung der relevanten Geschäftsprozesse; Festlegung des Projektumfangs; Vorbereitung und Durchführung einer ersten Datenerhebung; Dokumentation des Ist-Zustands; Analyse von Schwachstellen.

Konzeption: – Erstellung des Entwurfs des Pflichtenhefts/Fachkonzepts/Feinkonzepts unter Einbeziehung aller betroffenen Unternehmensbereiche; 1 S. auch Hesseler/Görtz, Basiswissen ERP-Systeme, 2008, S. 123.

Witzel

663

G Rz. 139

Sonderregelungen

– Ermittlung des Abdeckungsgrads der einzuführenden Standardsoftware im Verhältnis zum Entwurf des Pflichtenhefts/Fachkonzepts/Feinkonzepts; – Identifikation von Abweichungen und daraus folgend die Festlegung der Art der erforderlichen Anpassungen; – Installation und Konfiguration der Entwicklungs- sowie der Testumgebung; – Einrichtung und Übernahme der Systemadministration; – Einrichten von Benutzern für das Projektteam. cc) „Customizing“ der Standardsoftware 139

Um bei einem Anwender eingesetzt werden zu können, muss die Standardsoftware „customized“ werden. Mit Customizing ist die kundenspezifische Anpassung an die Bedürfnisse einer Kundenorganisation gemeint. Die Anpassung kann durch Programmänderungen („Individualprogrammierung“) oder durch das Setzen von Parametern erfolgen, die Umfang und Aussehen (Konfigurierung) einerseits oder das Verhalten und die Ergebnisse (Parametrisierung) einer Standardsoftware andererseits beeinflussen (mit anderen Worten: die Systemeinstellungen können allein durch Eintragen von Parametern in eine Vielzahl von Tabellen erfolgen1). Klarheit kann eine solche vertragliche Formulierung schaffen: 0.1 Soweit die Standardsoftware des Auftragnehmers nicht die in der Feinspezifikation festgelegten Anforderungen im erforderlichen Umfang abdeckt, erfüllt der Auftragnehmer diese Anforderungen durch Parametrisierung, Anpassung oder – in Ausnahmefällen – Erweiterungen der Standardsoftware und – in Einzelfällen – durch Zusätze. 0.2 Das Verfahren zur Erstellung der Feinspezifikation ergibt sich aus Ziffer (…). 0.3 Parametrisierung bedeutet: kundenspezifisches Einstellen der software-eigenen Parameter. Anpassung bedeutet: kundenspezifische Änderungen am Source Code der Standardsoftware. Erweiterung bedeutet: Erstellen von Source Code, über den Umfang der bisher vorhandenen Standardsoftware hinaus, wobei der neu erstellte Source Code in den Standard wandern soll. Zusätze bedeuten: Selbständige Programmteile mit neuem Code, die kundenspezifisch die Standardsoftware ergänzen.

1 Tabelleneintragungen können „routinemäßig“ sein: Eintragungen zum Berechtigten, zur Anzahl der Arbeitsplätze oder zu Benutzernamen und Passworten. Durch die Tabelleneintragungen können aber auch individuelle Geschäftsprozesse des Anwenders abgebildet werden.

664

Witzel

Implementierung von Standardsoftware

Rz. 143 G

Wird der Standard um neue individuelle Erweiterungen und Zusätze er- 140 gänzt, müssen sich die Vertragspartner Gedanken darüber machen, ob diese Erweiterungen und Ergänzungen anwenderspezifisch bleiben sollen oder in den Standardfunktionsumfang der einzuführenden und zu implementierenden Standardsoftware aufgenommen werden. Zum „Customizing“ gehört auch die Erweiterung von bestehenden Schnittstellen oder die Entwicklung neuer Schnittstellen, die für die Integration der Standardsoftware in die bestehende Systemumgebung des Anwenders erforderlich sind. Erfolgt das Customizing der Funktionalität häufig über reine Parametrisierung, ist gerade bei der Erstellung von Schnittstellen meist Programmierung notwendig, wenn auch nicht in großem Umfang. Ebenfalls im Zusammenhang mit dem Customizing ist die Definition und 141 Erstellung der kundenspezifischen Reports zu erwähnen. Reports sind Berichte und Auswertungen sowie Formulare, die vor allem bei betriebswirtschaftlichen Anwendungen eine Rolle spielen. Unter Berichten werden für eine vorgegebene Zielsetzung zusammengefasste Informationen verstanden, etwa Lagerbestandslisten, Auftragsübersichten, Kundenlisten mit dazu gehörenden Umsatzauswertungen u.ä. Standardsoftware bietet Vorlagen für Berichte an, entweder über eigene Module oder über Drittprodukte (z.B. Crystal Reports), die individuell customized werden können. Es ist allerdings auch regelmäßig notwendig, das in einem Unternehmen bestehende Berichts- und Formularwesen zu analysieren und zu hinterfragen. Nicht jeder Bericht hat tatsächlich den Aussagewert, der ihm zugeschrieben wird. Auch bei Reports gilt die generelle Empfehlung bei der Einführung von Standardsoftware: Der Anwender ist gut beraten, wenn er prüft, ob sich sein etabliertes Berichtswesen verschlanken und optimieren lässt. dd) Integration der Standardsoftware in die Systemumgebung des Anwenders, Implementierung in die Organisationsstruktur Anwender nutzen verschiedene Anwendungen. Im Rahmen der Einführung 142 einer neuen Standardsoftware hat also auch eine Integration in die vorhandene Systemumgebung des Anwenders zu erfolgen1. Die Integration dient der Verknüpfung von verschiedenen beim Anwender vorhandenen Anwendungen, idealerweise über Schnittstellen. Die Implementierung2 ist die Umsetzung von festgelegten Strukturen und 143 Arbeitsabläufen in einer Organisation unter Berücksichtigung von Rahmenbedingungen, Regeln und Zielvorgaben – einer Spezifikation. Die Implemen1 Rechtsprechung zu Implementierung: BGH v. 2.7.1996 – X ZR 64/94, CR 1996, 663; OLG Köln, K&R 2003, 613; LG Köln v. 16.7.2003 – 90 O 68/01, CR 2003, 724. 2 Der Begriff „Implementierung“ hat in der Informatik auch eine engere Bedeutung: „Das Umsetzen eines Algorithmus oder Softwaredesigns in ein Computerprogramm nach Auswahl einer geeigneten Programmiersprache“, s. www.wikipe dia.org.

Witzel

665

G Rz. 144

Sonderregelungen

tation ist das Ergebnis der Implementierung. Die Standardsoftware muss in die Organisationsprozesse des Anwenders „implementiert“ werden: Betrifft die Standardsoftware die Kernprozesse des Unternehmens, führt deren Einführung zwangsläufig zu organisatorischen Änderungen. Die erforderlichen Änderungen sind zu analysieren und umzusetzen. Eine vertragliche Regelung könnte wie folgt aussehen: 0.1 Der Auftragnehmer integriert die Standardsoftware in die beim Auftraggeber vorhandene Systemumgebung. Er bindet die übrigen Systeme über Schnittstellen ein. 0.2 Der Auftragnehmer unterstützt den Auftraggeber mit der fachlichen und organisatorischen Implementierung der Vertragssoftware in die Organisation des Auftraggebers und analysiert die erforderlichen Anpassungen, Änderungen und Ergänzungen.

ee) Altdatenübernahme, Migration 144

Eine Migration spielt sowohl bei Erstellung einer Individualsoftware als auch bei Anpassung und Implementierung von Standardsoftware eine bedeutende Rolle. Die Migration meint den Transfer von Daten von einer Umgebung in eine andere: Zu einer erfolgreichen Einführung und Implementierung wird in der Regel auch die Übernahme der beim Anwender vorhandenen Altdaten gehören. Ohne besondere Vereinbarung schuldet der Softwareanbieter keine Datenübernahme. Er muss die vorhandenen Altdaten des Anwenders nicht konvertieren und übernehmen. Die Notwendigkeit einer Datenübernahme ist grundsätzlich zu klären, insbesondere die Frage, wie die Datenübernahme zu erfolgen hat. Die Altdatenübernahme kann einmalig im Rahmen der Migration erfolgen. Es gibt aber auch die Möglichkeit, einen permanenten Datentransfer zwischen dem neu einzuführenden System und der Altanwendung zu schaffen. Folgende vertragliche Formulierung wäre denkbar: 0.1 Der Auftragnehmer entwickelt für den Auftraggeber ein optimiertes Vorgehen für die Migration der in den Systemen des Auftraggebers vorhandenen Altdaten. Der Auftragnehmer konzipiert die für die Migration erforderlichen Leistungen und führt diese durch. 0.2 Im Rahmen des von ihm erstellten Migrationskonzepts übernimmt der Auftragnehmer die Daten, Dokumente und laufenden Prozesse aus den vorhandenen Systemen. 0.3 Der Auftragnehmer überprüft im Rahmen der Migration die ordnungsgemäße und vollständige Übernahme der Altdaten.

666

Witzel

Implementierung von Standardsoftware

Rz. 149 G

Die Qualität der zu übernehmenden Daten birgt regelmäßig Konfliktpoten- 145 tial. In jahrelang genutzten Systemen sammeln sich viele doppelte, unvollständige oder inkonsistente Datensätze an, die bei der Übernahme zu Fehlern führen können. Die Bereinigung der Daten kostet Aufwand, den die Vertragspartner gerne anfänglich übersehen. Außerdem führen inkonsistente Daten häufig zu Verzögerungen bei der Einführung und die Vertragspartner streiten darüber, wer für diese Verzögerungen verantwortlich ist. ff) Installation Bei der Installation1 wird die angepasste Software auf die vorhandene Hard- 146 ware kopiert und konfiguriert. Der Erfolg der Installation ist zwingende Voraussetzung für das Funktionieren der Software, schlägt die Installation fehl, kann die Software nicht genutzt werden. Die Installation kann im Einzelfall genauso komplex und aufwendig sein wie die Realisierung und Anpassung der Software, da komplexe Anwendungssysteme nicht aus einer ausführbaren Programmdatei bestehen, sondern aus unterschiedlichen Dateien, etwa den einzelnen Anwendungsmodulen, Datendateien (Datenbank, XML-Dokumente, Vorlagen), Online-Hilfe, Konfigurationsdateien, Bibliotheken, Client-Komponenten. Im Vertrag sollte unbedingt geregelt sein, wer die Installation vornimmt 147 und auf welchen Systemen – Testsystem und/oder Produktivsystem. Sofern der Anwender die Installation selbst vornimmt, muss sichergestellt sein, dass die richtigen Mitarbeiter die erforderlichen Berechtigungen haben. Die Installation auf nur einem System wird die Ausnahme sein; schon aus Sicherheitsgründen empfiehlt es sich, bei einer Einführung, aber auch später im laufenden Betrieb ein Entwicklungs- und Testsystem sowie ein Produktivsystem zu nutzen. Denkbar wäre auch, für Entwicklung und Test unterschiedliche Systeme einzurichten2. gg) Einweisung und Schulung Die Begriffe Schulung und Einweisung werden häufig in einem Atemzug 148 verwendet, ohne dass eine Abgrenzung erfolgt. Tatsächlich sind Schulung und Einweisung wohl unterschiedliche Leistungen3. Eine verbindliche Begriffsdefinition gibt es jedoch nicht, lediglich Orientierungshilfen. Während sich die Einweisung an die Lieferung bzw. Übergabe der Software 149 und deren Installation anschließt bzw. Teil der Installation ist und eine konkrete Einführung in bestimmte Funktionalitäten des Programms sein wird, ist die Schulung mehr als eine Kurzeinweisung, die auch für mehrere 1 Rechtsprechung zu Installation: LG Köln v. 13.2.1996 – 85 O 76/94, CR 1997, 27; LG Freiburg v. 22.7.1998 – 8 O 406/95, CR 1999, 417; LG Stuttgart v. 26.8.1998 – 2 KfH O 141/97, CI 1999, 66; LG Köln, CR 2000, 813. 2 S. auch Hesseler/Görtz, Basiswissen ERP-Systeme, 2008, S. 151 ff. 3 S. Schneider, Handbuch des EDV-Rechts, Kap. D Rz. 410; Zahrnt, Computervertragsrecht in Rechtsprechung und Praxis, 6.2.1 (3).

Witzel

667

G Rz. 150

Sonderregelungen

Benutzer auf einmal durchgeführt wird und sich auf die Anwendung bzw. auf die Handhabung der Software, der Technologie und der Werkzeuge allgemein bezieht. Möglicherweise richtet sich die Unterscheidung auch sinnvoll nach dem Produkt, in das eingewiesen bzw. auf das geschult werden soll. 150

Für die Schulung gibt es unterschiedliche Konzepte: Der Softwareanbieter kann alle Nutzer des Anwenders schulen, was bei großen Organisationen erheblichen Aufwand und Kosten verursachen wird. Alternativ kann er nur bestimmte Mitarbeiter schulen, die dann wiederum selbst die Schulung weiterer Nutzer übernehmen (Train-the-Trainer-Modell). Ferner können Schulungen anwenderspezifisch gestaltet werden und sich ausschließlich auf die konkreten Bedürfnisse der Anwender richten. Viele Softwareanbieter bieten jedoch auch Schulungen an, die allen ihren Kunden offen stehen. Die Bedeutung der Schulungen sollte für den Projekterfolg nicht unterschätzt werden. Anspruchsvolle Software ist ohne intensive Schulung entweder überhaupt nicht oder nicht optimal nutzbar1. Nicht ausreichend geschulte Mitarbeiter können nicht richtig testen und damit auch keine erfolgreiche Abnahme durchführen. Im Übrigen sind nicht ausreichend geschulte Mitarbeiter meist schnell frustriert und damit ein Hemmschuh für den Projekterfolg. hh) Einführungsunterstützung, Go-Life Support

151

Mit dem Beginn der produktiven Nutzung (Go-Life, Produktivsetzung, Echtstart, Big Bang, Cut-Over) ist die Einführung nicht unmittelbar beendet, auch wenn die Angebote der Softwareanbieter die Leistungen zur Einführungsunterstützung gerne unter den Tisch fallen lassen. Selbst, wenn im Vorfeld der produktiven Nutzung ausführlich geschult worden ist, brauchen die Mitarbeiter des Anwenders für die ersten Wochen zusätzliche Unterstützung, ggf. auch durch Mitarbeiter vor Ort, die Fragen beantworten und bei Bedienfehlern kurzfristig Abhilfe schaffen2. c) Leistungsbeschreibung, Pflichtenheft, Feinspezifikation aa) Begrifflichkeiten

152

Die juristische Literatur einerseits, die Rechtsprechung anderseits sowie die Literatur aus Sachverständigensicht, aber auch die verschiedenen Softwareanbieter verwenden verschiedene Begriffe in Zusammenhang mit der Beschreibung für eine einzuführende und zu implementierende Standardsoftware3: 1 Jungebluth, Das ERP-Pflichtenheft, 4. Aufl. 2008, S. 46: „Sparen an Schulung und Bildung ist Sparen am falschen Platz.“ 2 Gennen, Phänomene am Übergang vom Projekt zum Betrieb, ITRB 2011, 213. 3 Groh, Leistungsbeschreibungen und Abnahme von IT-Anwendungsystemen; Ihde, Das Pflichtenheft beim Softwareerstellungsvertrag, CR 1999, 409; Intveen/

668

Witzel

Implementierung von Standardsoftware

– – – – – –

Rz. 153 G

Lastenheft; Pflichtenheft; Fachkonzept; fachliche Feinspezifikation/technische Feinspezifikation; Business Blueprint; Einsatzstudie.

Lastenheft1

153

Im Lastenheft sind die Anforderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Die Anforderungen sollen quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, WAS und WOFÜR zu lösen ist. Das Lastenheft wird vom Auftraggeber oder in dessen Auftrag erstellt. Es dient als Ausschreibungs-, Angebots-, und Vertragsgrundlage. Pflichtenheft Nach VDI 2519 ist das Pflichtenheft2 die Beschreibung der Realisierung aller Anforderungen des Lastenhefts. Im Pflichtenheft wird definiert, WIE und WOMIT die Anforderungen zu realisieren sind. Das Pflichtenheft wird in der Regel nach Auftragserteilung vom Auftragnehmer erstellt, falls erforderlich unter der Mitwirkung des Auftraggebers. Der Auftragnehmer prüft bei der Erstellung des Pflichtenhefts die Widerspruchsfreiheit und Realisierbarkeit der im Lastenheft genannten Anforderungen. Das Pflichtenheft bedarf der Genehmigung durch den Auftraggeber. Nach DIN 66901 ist das Pflichtenheft3 die ausführliche Beschreibung der Leistungen (z.B. technische, wirtschaftliche, organisatorische Leistungen), die erforderlich sind oder gefordert werden, damit die Ziele des Projekts erreicht werden. Spezifikation4 Eine Spezifikation ist ein formaler Text, der die Syntax und Semantik (zum Beispiel einer Software in der Informatik) oder die Implementierung eines bestimmten Bestandteiles oder Produktes beschreibt, d.h. eine deklarative Beschreibung, was etwas ist oder bewerkstelligt. Anhand einer guten Spezi-

1 2 3 4

Lohmann, Das IT-Pflichtenheft, CR 2003, 640; Intveen, Einzelheiten zu Verträgen über die Erstellung von IT-Pflichtenheften, ITRB 2010, 238; Jungebluth, Das ERP-Pflichtenheft, 4. Aufl. 2008; Lapp, Vertragsgestaltung zwischen Leistungsbeschreibung, Garantie und sinnvoller Beschränkung der Gewährleistung, ITRB 2003, 42; Söbbing, IT-Leistungsbeschreibung, ITRB 2003, 155; Söbbing, ITLeistungsbeschreibung: Strukur und vertragstypologische Zuordnung, ITRB 2004, 91. VDI 2519; zur Abgrenzung „juristischer und technischer“ Gebräuche s. auch Rz. 152, 154. VDI 2519. DIN 66901. http://de.wikepedia.org/wiki/Spezifikation.

Witzel

669

G Rz. 154

Sonderregelungen

fikation lässt sich demnach ein detaillierter Vergleich zwischen Soll- und Ist-Zustand vornehmen. Business Blueprint1 (hier mit Bezug auf SAP) Der sog. Business Blueprint wird gemeinsam erarbeitet und besteht aus einer detaillierten Dokumentation der in Anforderungsworkshops erzielten Ergebnisse. Dazu gehören auch die Geschäftsprozessanforderungen des Unternehmens. Das Business-Blueprint-Dokument enthält das allgemeine Verständnis des Unternehmers darüber, wie die Geschäftsabläufe im künftigen SAP-System abgebildet werden. Anforderung Eine Anforderung ist etwas, was ein Produkt oder ein System leisten oder eine Qualitätseigenschaft, die es aufweisen soll2. Zu unterscheiden sind grob: – funktionale Anforderungen: was das System oder Produkt tut, welche Daten es verarbeitet, welches Verhalten vom System gewünscht wird; – nicht (non)-funktionale Anforderungen; – Qualitätsanforderungen: wie gut, wie schnell, wie zuverlässig, wie sicher, wie erweiterbar das gesamte System oder Teile davon sein sollen; – Geforderte Randbedingungen: unter welchen technischen oder organisatorischen Vorgaben das System entwickelt werden soll (Technologien, Wiederverwendung, Zeit- und Budgetvorgaben). 154

Die Begrifflichkeiten für die verwendeten Dokumente mögen sich unterscheiden und von Softwareanbieter zu Softwareanbieter variieren, im Ergebnis handelt es sich bei Lastenheft, Pflichtenheft, etc. um ein Dokument oder auch mehrere Dokumente3, in dem oder in denen die Anforderungen4 des Anwenders dokumentiert werden und das als Grundlage für die Umsetzung der Anforderungen dient, also um eine Beschreibung dessen, was das einzuführende und zu implementierende System können soll, nämlich um eine Anforderungsbeschreibung. Da sowohl der Inhalt des Dokuments/der Dokumente nicht zwingend selbsterklärend ist/sind, als auch hinsichtlich der Verantwortlichkeiten unterschiedliche Auffassungen herrschen5, muss 1 http://www.bci-consult.de/bportal/consulting/managementberatung.html. 2 Hruschka, in Tiemeyer: Handbuch IT-Projektmanagement, 2010, S. 413. 3 Gerne finden sich Anforderungsbeschreibungen auch in Protokollen von Workshops und Projektbesprechungen. 4 Gerade beim Erheben von Anforderungen im Projekt ergeben sich aber die ersten Probleme, da die Anwender nur selten wissen, was sie wirklich brauchen. Die Anforderungen werden in der der Fachabteilung eigenen Sprache beschrieben. In größeren Unternehmen können sich aus den unterschiedlichen Fachabteilungen widersprüchliche Anforderungen ergeben. Des Weiteren darf nicht übersehen werden, dass politische Faktoren innerhalb eines Unternehmens auch Einfluss auf die Anforderungen haben können. 5 S. dazu Rz. 135 ff.

670

Witzel

Implementierung von Standardsoftware

Rz. 157 G

der Vertrag eine Regelung darüber enthalten, welches Dokument in welcher Projektphase von wem zu erstellen ist. Basis für den Projekterfolg ist eine Anforderungsbeschreibung, die im Verlauf des Projekts fortzuschreiben und zu detaillieren ist. bb) Bedeutung von Leistungsbeschreibung und Anforderungsbeschreibung (Pflichtenheft oder Feinspezifikation) für die Vertragsgestaltung Zentral für die Vertragsgestaltung ist die Erarbeitung einer möglichst um- 155 fassenden Leistungsbeschreibung einerseits sowie einer Beschreibung der umzusetzenden Anforderungen, der Anforderungsbeschreibung (Pflichtenheft), andererseits1. Beide Dokumente können im Projektverlauf Gegenstand weiterer Feinspezifikation sein. Die Bedeutung einer Anforderungsbeschreibung oder des Pflichtenhefts wird bei der Projektrealisierung von beiden Seiten häufig unterschätzt: ein möglichst umfassendes Pflichtenheft wird in der Regel schlichten und damit auch zur Deeskalation und Projektfortsetzung beitragen können. Auch bei etwaigen Rechtsstreitigkeiten stellt es ein ganz maßgebliches Beurteilungskriterium für die zu klärenden Streitfragen dar. Da eine gute Anforderungsbeschreibung aber auch aufwendig zu erstellen ist, liegt hier häufig einer der Kardinalfehler, dass nämlich aus Zeit- und Ressourcengründen gespart wird. Aus Präsentationen und Vorschlägen des oder der Softwareanbieter versucht man, Ideen zu sammeln und schnell zu einer Anforderungsbeschreibung zu kommen. Dabei wird Folgendes übersehen: Wenn nicht alle Projektbeteiligten ein Verständnis dafür entwickeln, wel- 156 che Teile der Arbeit ein Softwaresystem übernehmen soll – also welche Anforderungen es erfüllen muss –, steht am Ende eines Projekts ein Softwaresystem, das nicht wirklich brauchbar ist und das das Leben der Nutzer nicht einfacher, sondern eher schwerer macht. Verschiedenste Statistiken belegen, dass 60 % der Fehler in Softwaresystemen auf mangelhafte Anforderungen zurückgehen. Solche Fehler wären bei entsprechender Aufmerksamkeit vermeidbar2. Die Anforderungsbeschreibung/das Pflichtenheft und die daraus resultieren- 157 den Feinspezifikationen sind Grundlage der (erfolgreichen) Projektdurchführung, aber auch Bewertungsgrundlage für Leistungsstörungen. Vertragsrechtlich legt die Leistungsbeschreibung die „vereinbarte Beschaffenheit“ im Sinne von §§ 434 Abs. 1 Satz 1, 633 Abs. 2 Satz 1 BGB fest. Anforderungsbeschreibung bzw. Pflichtenheft dienen als Leistungsmaßstab für Leistungsumfang und Sollbeschaffenheit und damit zugleich für den vertraglich vereinbarten bzw. vorausgesetzten Gebrauch. Gibt es keine Anforderungs1 Gemäß der von Juristen und Unternehmensberatern entwickelten IT Contract Library (ITCL) sollte eine Leistungsbeschreibung im weiteren Sinne folgende Punkte berücksichtigen: (1) Leistungsdefinition, (2) Leistungsübergabepunkte, (3) Leistungsprämissen, (4) Mitwirkungspflichten. 2 Hruschka, in: Tiemeyer, Handbuch IT-Projektmanagement, 2010, S. 413.

Witzel

671

G Rz. 158

Sonderregelungen

beschreibung, muss die Leistung „dem Stand der Wissenschaft und Technik“ entsprechen bzw. ist ein mittlerer Ausführungsstandard geschuldet1, was auch immer das sein mag. 158

Die Anforderungsbeschreibung und die auf ihrer Basis zu erstellenden Feinspezifikationen müssen als Grundlage für die Abnahme – unterstellt eine solche ist erforderlich – dienen. Die Bedeutung von Anforderungsbeschreibungen wird häufig unterschätzt, die Vertragspartner schreiten schnell zur Umsetzung von etwas, was noch nicht einmal im Detail feststeht. Ohne umfassende Anforderungsbeschreibung erscheint die Eskalation aber zumeist vorhersehbar, die entscheidende Frage ist nur der Zeitpunkt, wann sie auftritt.

159

Einige Beispiele aus der Rechtsprechung können dies verdeutlichen: Bei einem Computersystem für Ärzte stellte es nach Auffassung des KG Berlin2 einen Mangel dar, wenn auf Überweisungsformularen das maschinelle Ankreuzen bzw. Ausfüllen wesentlicher Teile des unteren Formularabschnitts nicht möglich ist, Arbeitsunfähigkeitsbescheinigungen nur teilweise und vertrauensärztliche Berichte gar nicht ausgedruckt werden, obwohl laut Anforderungsbeschreibung alle nach der ärztlichen Behandlung benötigten Formulare wie zum Beispiel Überweisungen und Arbeitsunfähigkeitsbescheinigungen im Original ausdruckbar sein sollten. Wird im Pflichtenheft angegeben, dass bei einem Stückzahlermittlungsprogramm für einen Gießereibetrieb im Eingabe-Mode alle artikelbezogenen Daten abgespeichert und jederzeit geändert werden können, so stellt es nach Ansicht des LG Düsseldorf3 einen Mangel dar, wenn die Stammdaten nur geändert werden können, wenn vor der Datenänderung eine Großauswertung der Daten vorgenommen wurde. Die Nichteinarbeitung von Besonderheiten in der Lohnbuchhaltung des Anwenders stellt nach Ansicht des OLG Schleswig4 einen Mangel gegenüber der vertraglich vereinbarten Leistung dar, wenn die Anpassung des Programms an die Bedürfnisse des Anwenders ohne Begrenzung zugesagt wurde.

160

Vertragsentwürfe von Anwendern enthalten teilweise Formulierungen dergestalt: „Der Auftragnehmer passt die Standardsoftware X an die fachlichen Anforderungen des Auftraggebers an. Die fachlichen Anforderungen ergeben sich aus der in Anlage (…) beigefügten Leistungsbeschreibung. Sofern die Anforderungsbeschreibung fachliche Anforderungen des Auftraggebers nicht umfasst, so gehören diese automatisch zum geschuldeten Leistungsumfang, wenn sie für den ordnungsgemäßen Geschäftsbetrieb des Auftraggebers erforderlich sind.“

1 LG Köln v. 21.10.1993 – 22 O 673/90, CR 1994, 624; BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543. 2 KG v. 24.1.1985 – 22 U 5919/83, CR 1986, 643. 3 LG Düsseldorf v. 29.4.1985 – 41 O 92/84, CR 1987, 292. 4 Fundstelle bei Marly, Softwareüberlassungsverträge, Fn. 782 zu Rz. 893.

672

Witzel

Implementierung von Standardsoftware

Rz. 163 G

Aus Sicht des Anwenders mag eine solche Formulierung Scheinsicherheit in 161 Bezug auf die Lieferung einer „eierlegenden Wollmilchsau“ begründen, in der Projektwirklichkeit wird die Eskalation damit nur vorprogrammiert. Die Notwendigkeit, eine detaillierte Anforderungsbeschreibung zur Grundlage der Einführung der Standardsoftware zu machen, ergibt sich auch unter rechtlichen Gesichtspunkten: Die Schuldrechtsmodernisierung hat die „Pflichtverletzung“ zum zentralen Institut des Leistungsstörungsrechts gemacht. Die Bedeutung der Anforderungsbeschreibung für ein erfolgreiches Projekt 162 kann auch unter Kostenaspekten nicht genug hervorgehoben werden. So haben zwei Studien der NASA in den Jahren 1997 und 2001 Folgendes ergeben: Wenn die NASA in ihre Projekte weniger als 5 % Vorbereitungsaufwand – insbesondere für die Anforderungen – investiert, dann kommt es zu starken Verzögerungen in den Projekten. Liegt der Vorbereitungsaufwand zwischen 10 % und 20 % des gesamten Projektaufwands, dann liegen die Terminverzüge unter 30 %. Projekte mit 5 % Aufwand für die Anforderungsermittlung führen zu Kostenüberschreitungen zwischen 80 % und 200 %. Liegt der Aufwand für die Anforderungsermittlung zwischen 8 % und 14 %, dann liegt die Kostenüberschreitung unter 60 %1. Die Bedeutung des Themas zeigt sich auch anhand der nicht-juristischen Literatur zu IT-Projekten, die sich umfassend mit der Anforderungsermittlung – dem Requirements Engineering2 – befasst. Als Aufgabenbereiche des Requirements Engineering gelten folgende Aktivitäten: – Es müssen zunächst alle Anforderungen ermittelt werden. Dies kann in gemeinsamen Workshops mit den Nutzern des Anwenders erfolgen, in Interviews oder durch Befragung der Nutzer mit Fragebogen. – Nach Ermittlung der Anforderungen sind diese schriftlich zu dokumentieren. Diese Dokumentation kann durch umgangssprachliche Texte, graphische Modelle oder Prototypen erfolgen. – Sämtliche Anforderungen sind zu definierten Zeitpunkten auf Vollständigkeit, Konsistenz und Widerspruchsfreiheit zu prüfen. – Da sich Anforderungen ändern, sind sie während der Laufzeit eines Projekts zu verwalten; sie sind mit Priorisierungen sowie Statusangaben zu versehen. 1 Balzert, Lehrbuch der Softwaretechnik, Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 440. 2 Balzert, Lehrbuch der Softwaretechnik, Basiskonzepte und Requirements Engineering, 3. Aufl. 2009; Hruschka, in: Tiemeyer, Handbuch IT-Projektmanagement, 2010, S. 413; Rupp, Requirements Engineering und – Management, Professionelle, iterative Anforderungsanalsye für die Praxis, 5. Aufl. 2009; Requirements Engineering ist „kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist, zu gewährleisten, dass (1) alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind, (2) die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen, (3) alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert sind [International Requrirements Engineering Board].

Witzel

673

163

G Rz. 164 164

Sonderregelungen

Checkliste zur Erstellung einer Anforderungsbeschreibung/ eines Pflichtenhefts1 Ausgestaltung und Inhalt eines Pflichtenhefts/einer Anforderungsbeschreibung müssen demzufolge auch bei der Vertragsgestaltung eine Rolle spielen. Daher im Folgenden Hinweise, zusammengestellt aus einschlägiger Literatur: Formalia – – – – –

Titel Ersteller Version/Datum Status Vertraulichkeitsstufe

Inhaltverzeichnis Einleitung – Darstellung des Unternehmensprofils

– – – – – –

Rahmendaten (Mitarbeiter insgesamt, Anzahl Standorte, Anzahl Lager/ggf. Produktionsstätten, Anzahl geführter Verkaufsartikel) Überblick über die Zielsetzung der Einführung, etwa die Ablösung bestehender Insellösungen, Optimierung bestimmter Geschäftsprozesse Unternehmenspräsentation mit Darstellung der betroffenen Geschäftsfelder Umfeld Projektbereich Definition des Zwecks des Pflichtenhefts Kernprozesse/Beschreibung besonderer Leistungsmerkmale, beispielhaft – „mittelfristig soll die gesamte Funktionalität eines leistungsfähigen PPSSystems genutzt werden“ – „die bestehenden Lösungen sollen stufenweise abgelöst werden, in einem ersten Schritt soll die Zeitwirtschaft realisiert werden“ – „Bestellvorschläge sollen zukünftig direkt vom Arbeitsplatz aus als Bestellungen per Fax versandt werden“ – „die zukünftige Kostenrechnung/Kalkulation soll auf der Finanzbuchhaltung aufbauen“

1 Mit Anregungen aus Jungebluth, Das ERP-Pflichtenheft, 4. Aufl. 2008, sowie Vorschlägen von Streitz, IT-Projekte retten, S. 205, siehe auch Jäger u.a., Begutachtung und rechtliche Bewertung von IT-Mängeln, S. 14.

674

Witzel

Implementierung von Standardsoftware

Rz. 164 G

Ziele und Nutzen – konkrete und messbare Ziele – erwarteter Nutzen – Erfolgsfaktoren Übersicht Preise Vorläufige Meilensteine für Einführung und Implementierung – – – –

Installationsdatum Phase 1 (Finanzbuchhaltung) Geplante produktive Nutzung Phase 1 (Finanzbuchhaltung) Installationsphase Phase 2 (Einkauf) Geplante produktive Nutzung Phase 2 (Einkauf)

Fachliche Anforderungen – Systemübersicht – Abgrenzung (Bezug zu bestehenden Anwendungen, mit dem Projekt nicht verfolgte Ziele) – Funktions- und Prozessbeschreibungen mit Abhängigkeiten und Informationsfluss – Daten: langfristig zu speichernde Daten aus Benutzersicht – Leistungen: Anforderungen bezüglich Zeit und Genauigkeit – Dokumentenfluss, Belege – Datenmodell – Leitung/Durchsatz – Mengengerüst, beispielhaft „Einkauf – Anzahl Mitarbeiter – Anzahl Lieferanten – Anzahl Bestellvorgänge pro Tag – Zukünftige Anzahl Abrufaufträge – Reklamationen/Jahr – Einkaufsvolumen/Jahr Verkauf – Anzahl Kunden (aktiv) – Angebote/Jahr – Aufträge/Jahr – Lieferscheine/Jahr – Rechnungen/Jahr – davon Auslandsrechnungen – Gutschriften/Jahr – Anzahl Handelsvertreter Witzel

675

G Rz. 164

Sonderregelungen

– Anzahl verschiedene Konditionen (Rabatt, Bonus, Skonto usw.)“ – Benutzeroberfläche: grundlegende Anforderungen und Zugriffsrechte – zu generierende Auswertungen/Reports/Berichte, beispielhaft – „Lager: Lieferterminübersichten, Übersicht Anzahl Fertigungsaufträge pro Produkt und Jahr“ – „Vertrieb: Übersicht durchschnittliche Anzahl Bestellung pro Artikel und Jahr, Verhältnis Reklamationen zu durchgeführten Bestellungen; Konditionenübersicht pro Lieferant“ – „Finanzbuchhaltung: OP-Listen, Zahlungseingangsjournal, Mahnstufen Kreditoren“ – Nicht-Funktionale Anforderungen: einzuhaltende Gesetze und Normen, Sicherheitsanforderungen, Plattformabhängigkeiten – Schnittstelle zu anderen Anwendungen Einsatz von Produkten – Produktangabe mit Version – Einsatzbereich Informationstechnische Anforderungen – – – – – – – – –

IT-Strategie Vorhandene Infrastruktur (Hard- und Software für Server und Arbeitsplätze) Ressourcenanforderungen, benötigte Infrastruktur Verfügbarkeit Releasefähigkeit Erweiterungsfähigkeit Dokumentation Sicherheit (einschließlich Berechtigungskonzept) Qualitätsvorgaben

Implementierungsaspekte – – – – – –

Testverfahren (mit Planung, Strategie, Testfällen und -daten) Abnahmeverfahren Übernahme der Daten aus bestehenden Anwendungen Pilotphase Migrations- und Einführungskonzept Schulungen

Risiken Anhang – Stichwortverzeichnis – Glossar (mit Erläuterung der verwendeten Abkürzungen)

676

Witzel

Implementierung von Standardsoftware

Rz. 167 G

cc) Abgrenzung Leistungsbeschreibung/Garantie Das Institut der zugesicherten Eigenschaft ist durch die Schuldrechtsreform 165 im Kauf- und Werkvertragsrecht weggefallen, dafür wurde der Begriff der Garantie1 neu aufgenommen. Nach § 444 Abs. 1 BGB ist eine Garantie eine Vereinbarung, in der der Verkäufer oder ein Dritter die Gewähr dafür übernimmt, dass die verkaufte Sache zur Zeit des Gefahrübergangs eine bestimmte Beschaffenheit aufweist (Beschaffenheitsgarantie) oder für eine bestimmte Dauer behält (Haltbarkeitsgarantie). Der Verkäufer kann sich auf einen Haftungsausschluss nicht berufen, wenn 166 er eine Garantie übernommen hat. Nicht zwingend erforderlich sein wird, dass das Wort „Garantie“ verwendet wird. Formulierungen wie „voll einsehbar“ oder „zusichern“ können genügen. Bereits eine besondere Betonung bestimmter Eigenschaften kann im Einzelfall für eine Garantieübernahme sprechen. Daraus kann sich folgende Konfliktsituation ergeben: Im Hinblick auf das neue Leistungsstörungsrecht (§ 280 BGB), aber auch im Hinblick darauf, dass eine Anforderungsbeschreibung/ein Pflichtenheft Voraussetzung für den Erfolg eines jeden IT-Projekts ist, wird der Softwareanbieter nicht umhin kommen, die funktionalen und non-funktionalen Anforderungen so genau wie möglich zu beschreiben. Die Gefahr ist, dass besonders strikt formulierte Leistungsbeschreibungen in die Nähe einer Garantie oder dessen rutschen, was früher als zugesicherte Eigenschaft interpretiert wurde: Insofern ist mutmaßlich die hierzu zahlreich ergangene Rechtsprechung heranzuziehen, nur dass zugesicherte Eigenschaft jetzt verschuldensunabhängiges Einstehenwollen genannt wird. Im Garantiefall stehen dem Anwender die in der Garantie genannten Rech- 167 te zu den dort genannten Bedingungen zu. Es ist also der Schluss zulässig, dass es im Bereich von Garantien Gestaltungsspielräume gibt. Ein Blick auf die Rechtsprechung zu zugesicherten Eigenschaften vor der Schuldrechtsreform macht deutlich, dass im Bereich der Garantie durchaus ein Gefahrenpotential liegt2. Andererseits ist zu bedenken, dass der Grund für die restriktive Rechtsprechung zu den zugesicherten Eigenschaften unter altem Recht auch darin lag, dass die Rechte des Käufers ansonsten sehr be1 Hengstler/Staffelbach, Garantien in Softwareerstellungsverträgen im deutschschweizerischen Rechtsvergleich, ITRB 2012, 21; Stadler, Garantien in IT-Verträgen nach der Schuldrechtsreform, CR 2006, 77; Stadler, Haftungsrisiken bei Übernahme von Beschaffenheitsgarantien in IT-Verträgen nach neuem Recht, ITRB 2004, 233. 2 KG v. 24.1.1985 – 22 U 5919/83, CR 1986, 643: „Die Beklagte beruft sich insoweit ohne Erfolg darauf, derartige Leistungen einer Computeranlage seien nicht zugesichert worden. Bei einer technisch so komplizierten Anlage, die eine Vielzahl von Funktionen erfüllen soll, dienen die vom Verkäufer dem Käufer zugänglich gemachten Produktbeschreibungen unmittelbar der Festlegung des Kaufgegenstands … Will der Verkäufer gegenüber den angegebenen Produktbeschreibungen Einschränkungen machen, so muss er hierüber eine Einigung mit dem Verkäufer erzielen …“.

Witzel

677

G Rz. 168

Sonderregelungen

schränkt waren, ihm insbesondere kein Schadensersatzanspruch zustand. Durch die Einführung von Schadensersatzansprüchen im „Gewährleistungsfall“ besteht kein besonderes Schutzbedürfnis nach einer Ausweitung der Garantiehaftung mehr. 168

Im Hinblick darauf, dass sowohl die Bewertung einer Schlechtleistung nach den Vorschriften des allgemeinen Leistungsstörungsrechts als auch die Bewertung eines Sachmangels entscheidend von der Anforderungsbeschreibung abhängt, wird es nicht zu empfehlen sein, die Anforderungsbeschreibung im Hinblick auf das Garantierisiko unter den Tisch fallen zu lassen. Auch nicht vor dem Hintergrund, dass in IT-Projekten gern und häufig über den Umfang der geschuldeten Leistung gestritten wird.

169

Der Vorschlag von Lapp1 ist daher überdenkenswert, in einer Anforderungsbeschreibung zumindest eine Garantie ausdrücklich zu formulieren, um deutlich zu machen, dass die Vertragspartner zwischen Beschaffenheitsangaben und Garantien unterscheiden wollten. Stadler2 schlägt dazu folgende Formulierung vor, die für AGB im Zweifel nicht tauglich ist:

„1. Der Auftragnehmer garantiert Folgendes: […] 2. Sollte die vorstehend unter Ziffer 1 garantierte Beschaffenheit nicht gegeben sein, so stehen dem Auftraggeber die in Ziffer … geregelten Mängelrechte zu, jedoch mit der Maßgabe, dass der Auftraggeber Schadensersatz statt der Leistung oder Ersatz vergeblicher Aufwendungen im Sinne des § 284 BGB auch ohne Verschulden des Auftragnehmers, jedoch nur im Rahmen der in Ziffer … geregelten Haftungsbeschränkung verlangen kann. 3. Die vorstehend unter Ziffer 2 bezeichneten in […] ab Abnahme.“

dd) Verantwortlichkeit des Anwenders für die Beibringung der Anforderungen 170

Immer noch ist die Meinung anzutreffen, dass der Softwareanbieter die Anforderungsbeschreibung (das Pflichtenheft) zu erstellen hat, sofern nichts besonderes vereinbart ist. Eine Auffassung, die auch von vielen Sachverständigen vertreten wird. Befasst man sich mit der neueren Literatur zum Requirements Engineering3, wird sich diese Auffassung langfristig nur noch 1 Lapp, ITRB 2003, 43. 2 Rz. 165 Fn. 1. 3 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009; Hruschka, in: Tiemeyer, Handbuch IT-Projektmanagement, 2010.

678

Witzel

Implementierung von Standardsoftware

Rz. 172 G

schwer begründen lassen. Die Autoren richten sich keineswegs nur an die Softwareanbieter. Die Auffassung, dass der Anwender seine Anforderungen beizubringen hat, 171 ergibt sich auch aus herrschender Ansicht in der juristischen Literatur und Rechtsprechung: Die Beibringung von Anforderungen ist typische Aufgabe aus der Sphäre des Anwenders1. Dem Anwender obliegt die Konkretisierung der Aufgabenstellung und es ist seine originäre Pflicht darzustellen, wie das zu verwirklichende Werk beschaffen sein soll und zu welchen Zwecken er es benötigt bzw. verwenden möchte. Die Konkretisierung der Aufgabenstellung und des Erwartungshorizonts stellen eine vom Anwender zu erbringende Mitwirkungsleistung dar, es ist eine Hauptpflicht des Anwenders klar zu stellen, wie das zu verwirklichende Werk beschaffen sein soll und zu welchen Zwecken er es benötigt2. Diese Rechtsauffassung entspricht auch den Erfordernissen der Praxis. Nur 172 der Anwender selbst kennt seine Anforderungen in der notwendigen Ausprägung, der Softwareanbieter kann auch nach mehrmonatiger Analyse nicht über den erforderlichen Kenntnisstand verfügen. Es ist Aufgabe des Anwenders, seine Geschäftsprozesse zu beschreiben, aber auch zu analysieren. Nur durch ein gesamtheitliches Durchdenken aller abzubildenden Abläufe können Abhängigkeiten zwischen einzelnen Komponenten (Modulen) und Querauswirkungen erkannt werden, um Fehler bei Erweiterung und Parametrisierung zu vermeiden. Der Softwareanbieter kann dabei unterstützen. Im Hinblick auf das Know-how, das der Anbieter bei dieser Unterstützung – auch im Hinblick auf die Kenntnisse seiner Standardsoftware – einbringt, wird sich die Erstellung von Leistungsbeschreibung, Pflichtenheft und Feinspezifikation als gemeinsamer Prozess beider Vertragspartner herausstellen. Notwendig ist zum einen eine vollständige Bestandsaufnahme („Ist-Analyse“) mit folgenden Zielen3: – Identifikation aller durch das System zu unterstützenden Geschäftsvorgänge; – Identifikation aller zu verarbeitenden Informationen und Anforderungen an Auswertungen; – Identifikation der zu verarbeitenden (Daten-)Volumina; – Identifikation der Kosten des existierenden Systems; 1 BGH v. 13.7.1988 – VIII ZR 292/87 – Registrierkassen, CR 1989, 102 (Pflichtenheft als Sphäre des Kunden, evtl. Unterstützung durch den Auftragnehmer); BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543 (mittlerer Ausführungsstandard, wenn Pflichtenheft fehlt oder vergessen wurde); BGH, CR 1995, 295; BGH, CR 1993, 393 – Warentermingeschäft (kein Verzug des Auftragnehmers bei fehlender Vorgabe des Auftragnehmers); BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 (mittlerer Ausführungsstandard, der ggf. mit SV-Hilfe zu ermitteln ist). 2 OLG Düsseldorf v. 18.7.1997 – 22 U 3/97, CR 1997, 732. 3 Koch, Computervertragsrecht, Rz. 1090 ff.

Witzel

679

G Rz. 173

Sonderregelungen

– – – –

Identifikation der betroffenen Unternehmensbereiche; Festlegung des Untersuchungsumfangs; Vorbereitung von Interviews, Erarbeitung von Fragebögen; Durchführung von Interviews: Ist-Zustand erheben, Schwachstellen hinterfragen und Änderungswünsche dokumentieren; – Dokumentation des Ist-Zustands: Funktionsabläufe, Formulare, Berichte, Dateien, Daten-/Informationsflüsse, DV-Anwendungen; – Analyse und Dokumentation von Schwachstellen. 173

Die Ist-Analyse ist so anzulegen, dass sie unter Beteiligung der Mitarbeiter der Fachabteilungen stattfindet. Die umfangreiche und intensive Mitwirkung des Anwenders ist hierbei unumgänglich.

174

Ziele des Soll-Konzepts sind folgende: – Definition von Funktionen und Informationen, die durch das neue System bereitgestellt werden; – Erstellung einer Arbeitsgrundlage für die weitere Detaillierung des Projekts; – Überprüfung ausgewählter Funktionen; – Festlegung der Einführungsreihenfolge; – Abstimmung mit den Fachabteilungen. ee) Fehlendes und unzureichendes Pflichtenheft (1) Fehlendes Pflichtenheft

175

Fehlt das vereinbarte Pflichtenheft bzw. wurde es, obwohl erforderlich, vom Anwender nicht rechtzeitig erstellt1, muss die Leistung des Anbieters zumindest dem Stand der Wissenschaft (Informatik/BWL etc.) und Technik (Software Engineering/Qualitätssicherung) bei einem „mittleren Ausführungsstandard“ entsprechen. Bei einem Entwicklungsauftrag ist mangels Pflichtenheft oder anderer konkreter Absprachen ein Ergebnis geschuldet, das dem Stand der Technik bei einem mittleren Ausführungsstandard entspricht2. Was dieser ist, kann allerdings auch von Sachverständigen selten festgestellt werden.

176

Der Softwareanbieter erbringt bei fehlendem Pflichtenheft dann keine fehlerfreie Leistung, wenn diese nicht eine den spezifischen Erwartungen des Kunden entsprechende, sondern nur eine gewöhnliche Tauglichkeit aufweist und allenfalls Minimalanforderungen entspricht.

177

Die Rechtsprechung zum mittleren Ausführungsstandard dürfte in der praktischen Durchführung eines Projekts wenig hilfreich sein. Vermutlich lässt sich selbst mit Hilfe eines Sachverständigen nur unter großem Auf1 S. Kap. D Rz. 179 ff. 2 BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543.

680

Witzel

Implementierung von Standardsoftware

Rz. 181 G

wand feststellen, was bei angepasster Standardsoftware und Leistungen zu deren Implementierung denn nun ein mittlerer Ausführungsstandard ist. Dieses Risiko können die Vertragspartner nur minimieren, indem auf das Pflichtenheft bzw. die Leistungsbeschreibung ein erheblicher Aufwand investiert wird. (2) Unzureichendes Pflichtenheft Ähnlich gelagert ist die Thematik beim „unzureichenden“ Pflichtenheft: Geschuldet wird im Zweifel ein mittlerer Ausführungsstandard hinsichtlich der fehlenden oder unzureichenden Funktionalität. Damit ist aber die Eskalation zwischen den Vertragspartnern vorprogrammiert1. Die Vertragspartner werden über den Umfang und die Ausprägung der Leistungen streiten.

178

Ein Aspekt, den man in jedem erfolgreichen Projekt findet und der in jedem 179 erfolglosen Projekt fehlt, ist genügend Aufmerksamkeit für die Anforderungen. Anforderungen sind mehr als ein Verständnis für das IT-System, das geschaffen werden soll. Sie umfassen auch Informationen, die jeder kluge Projektleiter extensiv nutzt, um seinen Projektverlauf zu steuern2. d) Inhalt und Aufbau einer Anforderungsbeschreibung/eines Pflichtenhefts aa) Aufbau und Inhalt In der Verhandlungspraxis wird die Erstellung von Anforderungsbeschrei- 180 bungen häufig ausschließlich „den Fachleuten“ überlassen, ohne dass rechtliche Hinweise dazu gegeben werden, welchen Inhalt eine Anforderungsbeschreibung haben sollte oder welche Formulierungen später zu vermeiden sind, da sie die Eskalation bereits in sich tragen. Im Hinblick auf die Bedeutung, die einer Anforderungsbeschreibung zukommt, sollten die rechtlichen Aspekte mehr in den Fokus der Verhandlungen geraten. Anwaltliche Berater sollten das Thema auch nicht ausklammern und auf die „Fachseite“ verlagern, sondern sich zu vorhandenen Dokumenten durchaus äußern. Zur Feststellung von Widersprüchen und Inkonsistenzen sowie Lücken braucht es nicht tiefgehende Kenntnis von den Geschäftsprozessen, sondern Sorgfalt und den Mut, kritische Fragen zu stellen. Den größten Raum in Anforderungsbeschreibung/Pflichtenheft nehmen die 181 fachlichen, die funktionalen und nicht-funktionalen Anforderungen ein. Diese sind stark abhängig vom konkreten Projekt und der individuellen unternehmensspezifischen Situation, so dass hier nur allgemeine Hinweise zusammengestellt werden können, die allerdings für eine Prüfung im konkreten Fall wertvoll sein können. Die juristischen Berater sollten hier – wie bereits ausgeführt – die Verantwortung nicht komplett von sich weisen. Die 1 Zum Inhalt des Pflichtenhefts s. ausführlich Rz. 155. 2 Suzanne Robertson/James Robertson, Requirements-Led Project Management – Discovering David’s Slingshot, 2005.

Witzel

681

G Rz. 182

Sonderregelungen

Beurteilung, ob funktionale Anforderungen vollständig und richtig wiedergeben sind, mag den rechtlichen Sachverstand selbstverständlich übersteigen. Es ist aber Aufgabe des Juristen, die ihn unterstützenden Fachabteilungen darauf hinzuweisen, genau zu überprüfen, ob funktionale Anforderungen korrekt und vollständig beschrieben sind. Ist dies nicht möglich, muss der Vertrag in der Konsequenz Regelungen enthalten, wie mit Änderungen und Erweiterungen von Anforderungen umzugehen ist. Hinsichtlich der nichtfunktionalen Anforderungen ergibt sich aus dem Tätigwerden im Rahmen von Projektsanierungen rasch, welche Formulierungen zu unspezifisch sind, um als Grundlage für eine brauchbare Bewertung einer etwaigen Schlechtleistung zu dienen. bb) Beschreibung der funktionalen Anforderungen 182

Die Anforderungsbeschreibung/das Pflichtenheft muss die funktionalen Anforderungen des Kunden an die Software1 so explizit wie möglich beschreiben. Die funktionalen Anforderungen des Kunden sind abhängig vom konkreten Projekt und der individuellen unternehmensspezifischen Situation. Nicht alle Wünsche der Fachabteilungen des Kunden sollten kritiklos in die Leistungsbeschreibung/das Pflichtenheft aufgenommen werden, sie sind vielmehr kritisch zu hinterfragen: – – – –

Von wem wird die Funktion genutzt und wie oft? Wer gibt die Daten dafür ein? Wie viel Aufwand entsteht für den Anwender? Was passiert, wenn die gewünschte Funktion nicht entwickelt wird?

183

Funktionale Anforderungen entstehen aus einer fachlichen Motivation seitens des Anwenders: Sie beziehen sich auf die Funktionalität der Software und somit auf den konkreten Anwendungsbereich einer geplanten Lösung. Funktionale Anforderungen beschreiben konkrete Aufgaben, die von der Software ausgeführt werden sollen bzw. die die Software dem Anwender zur Verfügung stellen soll. Die Anforderungen werden aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet. Die Beschreibung von funktionalen Anforderungen erfolgt beispielsweise in Form von Anwendungsfällen (Use Cases). Ein Anwendungsfall beschreibt dabei einen konkreten, fachlich in sich geschlossenen Teilvorgang. Die Gesamtheit der Anwendungsfälle definiert das Systemverhalten2.

184

Bei einem Verkaufssystem ergäben sich beispielhaft folgende fachliche/ funktionale Anforderungen3: 1 S. dazu sehr detailliert Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 433 ff. 2 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 489. 3 Beispiele entnommen aus Brugger, IT-Projekte strukturiert realisieren, S. 106 ff.

682

Witzel

Rz. 185 G

Implementierung von Standardsoftware

– Funktionen zur Angebotsabwicklung (Bearbeiten von Anfragen, Erstellen von Angeboten); – Funktionen für die Kundendaten (Verwaltung von Rechnungs- und Lieferanschrift, Zugriffsmöglichkeiten); – Funktionen für den Artikelstamm (Pflege von Preislisten, kundenbezogene Rabatte, gebietsbezogene Sonderpreise); – Funktionen für den Versand (Erstellen von Lieferscheinen, Bilden von Versandeinheiten); – Funktionen für die Fakturierung (Verwalten von unterschiedlichen Bezahlarten, Überwachung des Zahlungseingangs, automatische Generierung von Zahlungserinnerungen). Die in einer Anforderungsbeschreibung/einem Pflichtenheft enthaltenen 185 funktionalen Anforderungen müssen so strukturiert werden, dass sie im Falle einer Auseinandersetzung als Grundlage dafür taugen, ob und inwieweit der Softwareanbieter seine Leistungen erbracht hat. Bei Balzert1 finden sich sehr plastische Beispiele, anhand derer die Qualität von Anforderungsbeschreibungen deutlich wird:

Es wäre gut, wenn zu Seminarveranstaltungen vielfältige Auswertungen möglich wären.

Besser wäre folgende Formulierung: Das System soll dem Benutzer, die Möglichkeiten bieten, Seminarveranstaltungen nach den vorhandenen Attributen zu selektieren und zu sortieren.

Wir können jederzeit feststellen, wo sich ein Paket zurzeit befindet.

Besser wäre folgende Formulierung: Wir können zwischen 7:00 Uhr und 20:00 Uhr innerhalb von maximal fünf Minuten feststellen, wo sich ein Paket befindet. Wir können zwischen 7:00 Uhr und 20:00 Uhr innerhalb von maximal zehn Minuten feststellen, wo sich ein Paket befindet.

1 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 457 ff.

Witzel

683

G Rz. 186

Sonderregelungen

Die Software Seminarorganisation muss mit der Software Buchhaltung permanent über eine Netzwerkverbindung verbunden sein.

Besser wäre folgende Formulierung: Die Software Seminarorganisation muss mit der Software Buchhaltung in der Regel innerhalb von 24 Stunden einmal Daten austauschen können, mindestens aber einmal innerhalb von fünf Arbeitstagen.

Begründung: Aus fachlicher Sicht reicht diese Festlegung, da nach einer Seminaranmeldung nicht sofort eine Mitteilung an die Buchhaltung erfolgen muss. Außerdem ist eine Festlegung auf eine Netzverbindung nicht nötig. Es könnte auch sein, dass beide Programme auf einem System laufen.

Benutzerinteraktionen: – Das System muss dem Kunden die Möglichkeit bieten, sich über Seminare und Veranstaltungen zu informieren. – Das System soll dem Seminarsacharbeiter die Möglichkeit bieten, Seminare und Veranstaltungen mit selbst erstellten Suchanfragen auszuwerten. Selbstständige Systemaktivität – Das System muss die Kundendaten permanent speichern. – Falls ein Kunde in Zahlungsverzug ist, darf das System keine neuen Buchungen erlauben. Schnittstellenanforderung – Das System muss fähig sein, dem Buchhaltungssystem Rechnungsdatensätze mindestens einmal am Tag zur Verfügung zu stellen.

186

Das OLG Düsseldorf1 führt unter Bezugnahme auf ein Sachverständigengutachten Folgendes aus: „Ein ordnungsgemäßes Pflichtenheft enthalte mindestens eine allgemeine Zielbeschreibung, die Beschreibung des Ist-Zustands, in das das Datenverarbeitungssystem eingebettet werden solle, den genauen Funktionsumfang (für die Software/Eingabefunktionen und Eingabedaten, Ausgabefunktionen und Ausgabedaten und Dateien), Leistungsnachweise, Leistungsumfang sowie Test- und Abnahmebedingungen. Der Entwurf der Beklagten sei als grobes Pflichtenheft zu verstehen, da der vollständige Funktionsumfang im Sinne aller Leistungsanforderungen im Detail nicht beschrieben werde. Beispielhaft hat der Sachverständige die ausdrücklich nicht abschließende Aufführung projektbezogener Daten und die 1 OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 361.

684

Witzel

Implementierung von Standardsoftware

Rz. 189 G

ungenauen Angaben zu den Eingabefunktionen bei der Eingabe einer Achse (Strecke) und zu den geometrischen Grundfunktionen für Bögen genannt. Für eine zielgerichtete Softwareentwicklung war dies, wie der Sachverständige zu Recht bemerkt, nicht ausreichend, da sich dem Pflichtenheft nicht entnehmen ließ, welche Funktionen konkret zu entwickeln waren. Das Pflichtenheft konnte seine Aufgabe nicht erfüllen, den genauen Inhalt der von der Beklagten zu erbringenden Leistungen festzulegen, und ist demgemäß nicht geeignet einen brauchbaren Maßstab zu geben, anhand dessen die tatsächlich gelieferte Software als vertragsgemäß/mangelfrei oder nicht vertragsgemäß/mangelhaft zu beurteilen wäre.“1 Das OLG geht sogar soweit, dass das Pflichtenheft die allgemeinen Funktionen der vom Softwareanbieter im konkreten Fall eingesetzten Basissoftware beschreiben muss, da nur basierend auf einer solchen Beschreibung die spezifischen Funktionen des Anwenders verständlich sind.

187

cc) Allgemeine Bestimmungen zur „Qualität der Software“: Nicht-funktionale Anforderungen/qualitative Anforderungen Neben funktionalen Anforderungen gibt es regelmäßig auch die sog. nicht- 188 funktionalen Anforderungen. Nicht-funktionale Anforderungen sind alle restlichen an die Software gestellten Anforderungen. Sie sind unabhängig vom Anwendungsbereich und beziehen sich im Regelfall nicht auf konkrete Funktionen. Sie fixieren eher die qualitativen Eigenschaften einer zu entwickelnden Lösung und umfassen auch den Entwicklungsprozess. Nichtfunktionale Anforderungen haben in der Regel großen Einfluss auf die Softwarearchitektur. Sie betreffen Qualitätsaspekte wie – – – – – – – –

Benutzerfreundlichkeit; Stabilitätsanforderungen (Zuverlässigkeit); Leistungsanforderungen (Performance); Sicherheitsanforderungen; Wartungsanforderungen; Portierungsanforderungen; Service Levels; Zugriffsschutzanforderungen.

Folgende Merkmale werden häufig zur Bestimmung von Qualität bei Software genannt: – „tolerant und robust“ Das System soll bei fehlerhafter Eingabe nicht „sofort“ zusammenbrechen oder „unsinnig reagieren“.

1 OLG Düsseldorf v. 10.6.1992 – 19 U 23/91, CR 1993, 361.

Witzel

685

189

G Rz. 190

Sonderregelungen

– „gut dokumentiert“ Die Personen, die das System anwenden, und diejenigen, die es warten sollen, müssen aus der Dokumentation alle Informationen entnehmen können, die sie brauchen. – „wartungsfreundlich“ Es muss leicht sein, Fehler im System zu finden und zu beheben. Es muss auch leicht sein, das System zu verändern oder zu erweitern. – „zuverlässig“ Es muss stabil zur Verfügung stehen. – „nachvollziehbar“ Es muss in seiner Struktur, seinem Aufbau, so funktionieren und reagieren, dass es für die Anwender „logisch“ ist. Es muss leicht sein, das System zu verstehen. – „leicht bedienbar“ Das System darf keine umständlichen Eingaben verlangen und es muss möglich sein, das System auch dann noch bedienen zu können, wenn man es längere Zeit nicht angewendet hat. – „performant“ Abläufe müssen schnell bearbeitet werden. Die Antwortzeiten müssen gering sein. – „portabel“ Das System muss ohne Änderungen auf verschiedenen Plattformen ablauffähig sein. 190

Anwender schlagen Formulierungen vor, die in etwa so lauten: Diese Zusatzentwicklungen sind stets uneingeschränkt aufwärtskompatibel mit zukünftigen Versionen und Releases der Standardsoftware des (…)-systems und nutzen vorhandene Schnittstellen vollständig und ordnungsgemäß. Die Realisierung erfolgt im Rahmen einer Komponentenarchitektur. Dies bedeutet, dass Aufgaben, die häufig vorkommen und von verschiedenen Anwendungen genutzt werden können, als eigenständig gekapselte und wieder verwendbare Komponenten ausgestaltet werden. Die Bedieneroberfläche muss an die Bedürfnisse des jeweiligen Benutzers flexibel angepasst werden können. Die Integration der später bzw. parallel entstehenden erneuerten Randsysteme muss ohne Anpassung des (…)-systems möglich sein: Dies bedeutet, dass bereits bei der Konstruktion des (…)-systems die Schnittstellen zu den Umsystemen so umfassend und universell vorgesehen werden müssen, dass diese auch in der Lage sein werden, in den nächsten Jahren zum Einsatz kommende neue Umsysteme anzubinden.

686

Witzel

Implementierung von Standardsoftware

Rz. 194 G

Die Vertragspartner werden schon bei den funktionalen Anforderungen 191 schnell auf Konfliktpotential stoßen. Bei den nicht-funktionalen Anforderungen sind Widersprüche noch wahrscheinlicher. Beispiele1: Leistungsfähigkeit und Wartbarkeit. Werden hohe Anforderungen an die Wartbarkeit gestellt, so weiß man, dass eine Systemarchitektur mit kleinen, unabhängigen Komponenten, die schnell und ohne Nebenwirkungen geändert werden können, geeignet ist. Werden jedoch gleichzeitig hohe Anforderungen an die Leistungsfähigkeit gestellt, so ist dies nicht ohne Weiteres mit der Wartungsfreundlichkeit vereinbar. Leistungsfähigkeit wird begünstigt durch die Verwendung großer Komponenten, bei denen die Optimierungen durch ihre breite Abstützung tiefgreifende Performance-Verbesserungen ermöglichen. Sicherheit steht häufig in Konflikt mit Benutzbarkeit. Speichereffizienz ist meist gegenläufig zur Laufzeiteffizienz2. Den Verhandlungspartnern muss deutlich gemacht werden, dass sie sich 192 auch über die nicht-funktionalen Anforderungen (die teilweise als „Highlights“ im Vertragstext auftauchen) klar werden müssen, also prüfen müssen, ob die verwandten Begriffe eindeutig zuordnenbar und widerspruchsfrei sind. Nicht-funktionale Anforderungen zeichnen sich vor allem dadurch aus, dass sie subjektive Vorstellungen des Anwenders widerspiegeln und nur schwer greifbar sind. Es wird zu empfehlen sein, auch hier zu möglichst detaillierten Beschreibungen zu greifen:

193

Das System soll über folgenden Benutzerkomfort verfügen: – – – – –

Grafische Benutzeroberfläche Mausunterstützung Listengenerator (für individuelle Auswertungen) Konfigurierbare Symbolleisten User-Interface-Pre-Sets für Anfänger und Fortgeschrittene

Den Anwendern und ihren Vertretern sollte in diesem Zusammenhang 194 deutlich gemacht werden, dass unspezifische nicht-funktionale Anforderungen nicht größere Sicherheit, sondern größeres Potential für eine mögliche Eskalation mit sich bringen. Standardaussagen der Anwender wie „Das haben wir uns aber anders vorgestellt!“, „In einer Standard-Lösung muss das doch enthalten sein!“ oder „So können unsere Anwender das unmöglich bedienen!“ sollten mit einer guten Anforderungsbeschreibung im Interesse beider Vertragspartner vermieden werden. 1 S. Brugger, IT-Projekte strukturiert realisieren, S. 111. 2 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 463.

Witzel

687

G Rz. 195

Sonderregelungen

dd) Kriterien für die Beschreibung funktionaler und nicht funktionaler Kriterien 195

Die häufigste Fehlerquelle bei der Anforderungsbeschreibung1 sind mit 83 % sprachliche Fehler (Unverständlichkeit, Missverständlichkeit, Unquantifizierbarkeit). Logische Fehler (Widersprüchlichkeit, Redundanz) bei der Anforderungsbeschreibung treten mit 75 % auf. Inhaltliche Fehler (falsche Sachverhalte, Unvollständigkeit) machen 73 % aus2. Lösungsneutral Anforderungen dürfen keine impliziten Hinweise auf mögliche Lösungen enthalten. Alle Inhalte müssen lösungsneutral sein. Korrekt Insbesondere die funktionalen Anforderungen müssen fachlich und korrekt wiedergegeben werden. Potentielle Fehlerquellen entstehen durch einzelne Funktionen, die zwar in sich korrekt spezifiziert sind, aber zu ungültigen oder unbrauchbaren Kombinationen führen. Widerspruchsfrei Anforderungen dürfen sich weder direkt noch indirekt widersprechen. Auf Widersprüche muss man besonders zwischen funktionalen und nicht-funktionalen Anforderungen achten. Ggf. müssen Prioritäten festgelegt werden, um Widersprüche zu klären. Eindeutig Die Anforderungen müssen derart präzise und unmissverständlich spezifiziert sein, dass eine missverständliche oder mehrdeutige Interpretation während des Entwurfs und während der Realisierung ausgeschlossen werden kann. Testbar Jede Anforderung muss so spezifiziert sein, dass ihre erfolgreiche und fehlerfreie Realisierung durch einen Test eindeutig nachgewiesen werden kann. Es hat wenig Sinn, Anforderungen zu formulieren, die nicht getestet werden können. Pauschale Begriffe wie „flexibel“, „schnell“ und „sicher“ sind im Allgemeinen ein sicheres Zeichen für nicht testbare Anforderungen. In der Regel scheitert die Testbarkeit an der Quantifizierbarkeit von bestimmter Aussagen.

1 S. Brugger, IT-Projekte strukturiert realisieren, S. 107. 2 Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 3. Aufl. 2009, S. 440.

688

Witzel

Implementierung von Standardsoftware

Rz. 198 G

Relevant Nur die Aspekte, die explizit gefordert wurden, sollten als Anforderungen festgehalten werden. Optionale Anforderungen (Wünsche) sind separat aufzuführen. Vollständig Die Anforderungen müssen eine vollständige funktionale und nicht-funktionale Beschreibung des zu entwickelnden Systems darstellen. Für die Beschreibung von Anforderungen gibt es im Wesentlichen drei Mög- 196 lichkeiten: Anforderungen können umgangssprachlich dargestellt werden. Daneben können für die Beschreibung von Anforderungen graphische Modelle (etwa UML – Unified Modeling Language) genutzt werden. Zudem besteht die Möglichkeit, Anforderungen über Prototypen zu dokumentieren. Diese drei Möglichkeiten können natürlich auch kombiniert werden.

IV. Projektplanung: Fristen- und Aktivitätenplan 1. Notwendigkeit einer konkreten Projektplanung Auf Basis der vereinbarten Projektphasen oder entsprechend dem vereinbar- 197 ten Vorgehensmodell1 geht es für die Vertragspartner in den vertraglichen Regelungen noch darum, die konkrete Projektplanung2 zu regeln. Während das Vorgehensmodell das Ergebnis einer methodischen Analyse der Aufgabenstellung ist, aus der sich ein sinnvolles Raster für die Bewältigung eines konkreten Aufgabentyps ergibt, zeigt der Projektplan die inhaltlichen Aspekte eines konkreten Projekts im zeitlichen Kontext. Das Vorgehensmodell bildet die Grundlage für die Projektplanung. Die Projektplanung ist notwendig, um einen Überblick darüber zu bekommen, in welcher Abfolge die Arbeitsschritte sinnvollerweise durchgeführt werden sollen. Die Projektplanung gibt somit die Sicherheit, das Richtige zur richtigen Zeit zu tun. Eine fundierte und realistische Projektplanung ist auch die Basis für eine funktionierende Projektsteuerung. Die Projektplanung ist eine kontinuierliche Aktivität über das ganze Projekt hinweg, vom ersten Konzept über die Auslieferung des Systems bis hin zur Wartung. Die Projektplanung spielt auch bei der Vertragsgestaltung eine erhebliche 198 Rolle, da die Nichteinhaltung vereinbarter Termine und Meilensteine wiederum zur Anwendbarkeit des Leistungsstörungsrechts führt. Anlage zum Vertrag sollte ein Projektstrukturplan, ein Masterplan oder ein Fristen- und Aktivitätenplan sein, in dem festgelegt wird, wer wann welchen Schritt – evtl. gemeinsam mit dem anderen Vertragspartner – ausführt. Dabei müssen alle Abhängigkeiten zwischen den Aktivitäten erfasst werden.

1 S. dazu Kap. H. 2 Zur Projektplanung s. auch Kellner, S. 145 ff.

Witzel

689

G Rz. 199 199

Sonderregelungen

Ein Fristen- und Aktivitätenplan sollte auch die Abhängigkeiten der erforderlichen Schritte von der Ausführung der jeweils vorhergehenden transparent machen sowie in Kombination mit den vertraglichen Regelungen die Konsequenzen der Nicht- oder Schlechterfüllung darstellen. Folgende Fragen sollten durch die konkrete Planung geklärt werden: – Aktivitäten: – Was muss getan werden? – Wer macht was? – Wie wird die geforderte Qualität erreicht und wie sieht der Zeitplan dazu aus? – Ressourcen: – Wer wird gebraucht? – Wer kommt wann zu dem Projekt hinzu und wie sieht die Einarbeitung aus? – Was wird gebracht? – Budget: – Wann wird wie viel wofür ausgegeben? – Wie entwickeln sich die Kosten des Vorhabens im Laufe der Zeit? – Termine: – Wann ist was fertig? – Wann ist welcher Meilenstein erreicht? – Wer und was muss wann zur Verfügung stehen?

200

Die Projektplanung ist kein einmaliger, sondern ein permanenter Prozess: Die Vertragsgestaltung muss diese Dynamik berücksichtigen und Regelungen dafür treffen, wie die Vertragspartner mit sich ändernder Planung umgehen. Mit anderen Worten: der Vertrag muss regeln, wie Terminverschiebungen abzubilden sind. 2. Vereinbarte Termine, Nichteinhaltung und deren Konsequenzen, Gestaltungsmöglichkeiten

201

In den wenigsten Projekten werden alle vereinbarten Termine eingehalten1, die gesetzlichen Verzugsfolgen treten allerdings nicht bei jedem verschobenen Termin ein: Kein Verzug ohne Verschulden, daran ändert auch die Neufassung des § 286 BGB nichts. Verzugsschaden und Rücktritt infolge verspäteter Leistung sind künftig nicht mehr als Rechtsfolgen des Verzuges im Verzugsrecht, sondern als Rechtsfolgen des allgemeinen Tatbestands „Pflichtverletzung“ geregelt: einerseits „Schadensersatz statt der Leistung“ (§ 281 BGB), andererseits „Rücktritt wegen nicht oder nicht vertragsgemäß erbrachter Leistung“ (§ 323 BGB). Im Verzugsrecht weiterhin geregelt sind

1 Zum Verzug s. Rz. 355 ff.

690

Witzel

Implementierung von Standardsoftware

Rz. 203 G

der Verzögerungsschaden (§§ 280 Abs. 2, 286 BGB) und der Verzugszins (§ 288 BGB). Wird ein Termin im Rahmen eines Projekts nicht eingehalten und die Vertragspartner können sich nicht auf eine einvernehmliche Verschiebung einigen, sondern droht eine Eskalation, stehen folgende Fragen zur Klärung an:

202

– Liegen die Voraussetzungen des Verzugs vor, d.h. hat der Schuldner – in der Regel der Softwareanbieter – die Verzögerung ausschließlich im Sinne der § 276 BGB zu vertreten? – Oder ist die Verzögerung auf fehlende oder nicht rechtzeitige Mitwirkung des Auftraggebers zurückzuführen? – Ist dem Gläubiger ein nachweisbarer Verzögerungsschaden entstanden? – Wäre eine weitere Fristsetzung erforderlich, um dem Anwender den Weg zum Rücktritt oder zum Schadensersatz statt der Leistung zu eröffnen? Durch die Schuldrechtsreform ist die nach § 326 Abs. 1 BGB a.F. erforderli- 203 che Nachfristsetzung mit Ablehnungsandrohung entfallen. Allein aufgrund der hohen Anforderungen, die die Gerichte formell an diesen „letzten Warnschuss“ gestellt haben, hatte der in Verzug geratene Softwareanbieter noch einmal die Möglichkeit, seine Leistungen doch noch zu erbringen1. Die Schuldrechtsreform hat die Position des Anwenders wesentlich verbessert. Die Möglichkeiten ein Projekt zu beenden und Schadensersatz zu verlangen, wurden vereinfacht2. Losgelöst von den rechtlichen Implikationen, die diese Änderungen mit sich bringen, stellt sich das Problem, dass die gesetzlichen Regelungen einem komplexen Projekt nicht gerecht werden. Der Ausstieg aus einem Projekt dürfte für beide Seiten im Zweifel zu katastrophalen wirtschaftlichen Konsequenzen führen, so dass die Voraussetzungen für eine Projektbeendigung – aber auch für die Geltendmachung von Schadensersatzansprüchen – restriktiv gestaltet werden sollten. Die Vertragsgestaltung3 sollte weniger auf einen einfachen Ausstieg und Sekundäransprüche als auf Erreichung des Projekterfolgs gerichtet sein. Folgende – für AGB aufgrund von § 307 BGB nicht geeignete – Formulierungen sind denkbar:

Gerät der Auftragnehmer mit einem der im Fristen- und Aktivitätenplan definierten Meilensteine in Verzug, greift eine Karenzzeit von … Wochen, innerhalb derer der Auftraggeber dem Auftragnehmer keine (Nach-)Frist zur Leistungserbringung setzen wird und nicht zur Geltendmachung von Schadensersatz 1 BGH v. 10.3.1998 – X ZR 70/96, CR 1998, 393; BGH, CI 1999, 48. 2 Zu den Anforderungen an die Fristsetzung s. BGH v. 25.3.2010 – VII ZR 224/08, NJW 2010, 2200: Für eine Leistungsaufforderung i.S.d. § 281 Abs. 1 Satz 1 BGB reicht grundsätzlich die Aufforderung, die vertragliche Leistung zu bewirken. 3 Zu Vertragsstrafenregelungen: Auer-Reinsdorff, Vertragsstrafenregelungen in ITProjekten, ITRB 2005, 242.

Witzel

691

G Rz. 203

Sonderregelungen

(Verzögerungsschaden) berechtigt ist. Nach Ablauf der Karenzfrist ist der Auftraggeber berechtigt, dem Auftragnehmer eine angemessene Nachfrist zur Leistungserbringung zu setzen. Daneben kann der Auftraggeber Ersatz des Verzögerungsschadens verlangen, sofern der Auftragnehmer den Verzug ausschließlich zu vertreten hat. Im Übrigen gilt Ziffer … (Haftungsbegrenzung).

oder

0. Planung, Fristen- und Aktivitätenplan 0.1 Planung Der Auftragnehmer erstellt in Abstimmung mit dem Auftraggeber je Teilprojekt ein Detail-Einführungskonzept. Dieses Einführungskonzept enthält eine Spezifizierung des im vorliegenden Vertrag grob skizzierten Vorgehens von der Installation der Vertragssoftware, dem Nachweis deren Funktionsfähigkeit, Anpassungs- und Erweiterungsarbeiten, über Tests (Funktion, Integration, Performance) bis hin zum Nachweis der Abnahmereife in Verbindung mit Einweisung und Schulung. 0.2 Aktivitäten – und Fristenplan Der Auftragnehmer erstellt in Abstimmung mit dem Auftraggeber einen Aktivitäten- und Fristenplan, der das Projekt in einzelne Schritte aufgliedert und so zeitlich zuordnet, dass festgelegte Meilensteine sowie sonstige Termine eingehalten werden und sich daraus ergibt, welche Mitwirkungsleistungen seitens des Auftraggebers wann erforderlich sind, wann der Auftragnehmer welche Leistungen zu übergeben hat und bis wann welche Leistungen durch den Auftragnehmer erbracht werden. 0.3 Nichteinhaltung von Meilensteinen und Terminen 0.3.1 Nichteinhaltung von Meilensteinen Hält der Auftragnehmer vereinbarte Meilensteine (s. Ziff. 0.2) nicht ein und hat der Auftragnehmer diese Nichteinhaltung zu vertreten, greift eine Karenzzeit von vier Wochen. Erst nach Ablauf dieser Karenzzeit ist der Auftraggeber berechtigt, dem Auftragnehmer eine angemessene Frist zur Erbringung der vereinbarten Leistung zu setzen. Schlägt die Leistungserbringung auch innerhalb dieser Frist fehl, wird der Auftraggeber dem Auftragnehmer eine letzte Nachfrist zur Erbringung der Leistung setzen. Diese Nachfristsetzung hat schriftlich an die Geschäftsleitung des Auftragnehmers zu erfolgen und ist mit der Erklärung zu verbinden, dass nach erfolglosem Fristablauf weitere Leistungen abgelehnt werden. Nach erfolglosem Ablauf der Nachfrist ist der Auftraggeber zur Geltendmachung von Rücktritt oder Minderung nach Maßgabe der gesetzlichen Bestimmungen berechtigt. Diese Nachfristsetzung ist nicht erforderlich, sofern diese für den Auftraggeber unzumutbar ist. Die Geltendmachung von

692

Witzel

Implementierung von Standardsoftware

Rz. 205 G

Verzögerungsschäden bleibt dem Auftraggeber unbenommen, es gelten allerdings die Begrenzungen in Ziffer … 0.3.2 Nichteinhaltung von Terminen Hält der Auftragnehmer vereinbarte Termine nicht ein und hat der Auftragnehmer diese Nichteinhaltung zu vertreten, gelten die gesetzlichen Regelungen zum Verzug. 0.3.3 Nichteinhaltung von Meilensteinen und Terminen durch unzureichende Mitwirkung Kann sich der Auftragnehmer im Falle der Nichteinhaltung von Meilensteinen und Terminen darauf berufen, dass die Nichteinhaltung überwiegend auf verzögerte und/oder unzureichende Mitwirkung seitens des Auftraggebers zurückzuführen ist, werden sich die Vertragspartner einvernehmlich auf eine angemessene Terminverschiebung verständigen. Der Auftragnehmer kann sich auf verzögerte und/oder unzureichende Mitwirkung nicht berufen, wenn der Auftragnehmer die Mitwirkung nicht rechtzeitig eingefordert und der Auftraggeber auf die Konsequenzen bei Verzögerung und/oder unzureichender Erbringung der Mitwirkung hingewiesen hat.

V. Mitwirkung des Auftraggebers 1. Vorbemerkung Je komplexer die vom Softwareanbieter zu erbringende Leistung ist und je 204 mehr der Eintritt des Leistungserfolgs von der Integration der Leistung in bestehende betriebliche Strukturen des Anwenders abhängt, desto wichtiger ist die Frage, in welchem Umfang der Softwareanbieter auf die Mitwirkung des Anwenders angewiesen ist1. Die Mitwirkungspflicht wird als Pflicht zur gegenseitigen Unterstützung verstanden, die berücksichtigt, dass der auf die Mitwirkung angewiesene Vertragspartner weder den Verantwortungsbereich seines Vertragspartners einsehen, noch Geschehnisse in dessen Unternehmen unmittelbar beeinflussen kann. Im Vordergrund der Mitwirkung stehen Informationen über das Unterneh- 205 men des Anwenders, die notwendig sind, damit die Software vertragsgemäß angepasst, eingeführt und implementiert werden kann. Diese Informationen betreffen im Wesentlichen die Organisationsstruktur, die Geschäftsprozesse und die daraus resultierenden Anforderungen, Testfälle und Abnah1 Lapp, Interaktion und Kooperation bei IT-Projekten, ITRB 2010, 69; Müglich/ Lapp, Mitwirkungspflichten des Auftraggebers beim IT-Systemvertrag, CR 2004, 801; Müller-Hengstenberg/Krcmar, CR 2002, 549; Roth, Mitwirkungspflichten in EDV-Projekten, ITRB 2001, 194; s. Schneider, Mitwirkungspflichten des Auftraggebers bei Softwareanpassung, ITRB 2008, 261; Witzel/Stern, Mitwirkungspflichten des Auftraggebers im Softwareprojekt, ITRB 2007, 167, 168.

Witzel

693

G Rz. 206

Sonderregelungen

mekriterien, Altdaten und etwaige anzubindende Drittsysteme. Anwender haben häufig die irrige Vorstellung, dass der Softwareanbieter aufgrund seiner Projekterfahrung oder Branchenkenntnis nicht auf die Mitwirkung angewiesen ist. Dies ist jedoch ein Trugschluss, denn kein Unternehmen ist mit einem anderen identisch und selbst bei Wettbewerbern werden sich Geschäftsprozesse teilweise signifikant unterscheiden. 206–211 Einstweilen frei. 2. Gesetzliche Bestimmungen zur Mitwirkung 212

Die gesetzliche Ausprägung der Mitwirkung ist dünn. Mitwirkungspflichten können sich aus dem Grundsatz von Treu und Glauben (§ 242 BGB) und der Pflicht zur gegenseitigen Rücksichtnahme (§ 241 BGB) ergeben.

213

Im Kaufvertragsrecht gibt es nur über die Verweisung des § 651 BGB Mitwirkungspflichten, während sich im Dienstvertragsrecht keine solchen Pflichten finden. Das Werkvertragsrecht sieht folgerichtig die Mitwirkung des Bestellers in § 642 BGB vor, da das Ziel des Werks vom Besteller individuell vorgegeben ist. Allerdings hat das BGB diese Mitwirkung konzeptionell nicht als Schuldnerpflicht ausgestaltet, sondern als Obliegenheit1. Die Einstufung als Obliegenheit gilt allerdings nicht für die Zahlungsverpflichtung sowie für die Verpflichtung zur Abnahme (§ 640 BGB).

214

Im Wesentlichen ist die Mitwirkung jedoch nicht einklagbar und nicht erzwingbar. Auch Schadensersatzansprüche wegen Verschuldens bei Vertragsschluss oder positiver Vertragsverletzung respektive § 280 BGB können bei Verletzung der Mitwirkungspflichten durch den Besteller nicht geltend gemacht werden2. Diese Einordnung der Mitwirkung als reine Obliegenheiten erscheint ob der Tatsache, dass weder die Festlegung der erforderlichen Anpassungen an eine Standardsoftware noch die Umsetzung notwendiger Maß1 S. Kap. D Rz. 237: „Die gesetzliche Regelung sieht die Mitwirkungshandlungen des Kunden als Obliegenheiten an. In der Softwarebranche besteht ein starker Wunsch, sie als Pflichten zu behandeln.“ 2 Nach Urteilen des BGH zu altem Recht (u.a., NJW 2005, 1650) könnten die Grundsätze der positiven Vertragsverletzung bei schuldhaftem Unterlassen der Mitwirkung zur Anwendung kommen, s. dazu auch Beck’scher Online Kommentar, § 642 Rz. 7 ff., dessen Autor die endgültige Verweigerung der Erbringung der Mitwirkung einer Kündigung des Bestellers i.S.v. § 649 BGB gleich stellt. Der alten Rechtsprechung zur positiven Vertragsverletzung hat der BGH mit einer Entscheidung v. 27.11.2008 – VII ZR 206/06, NJW 2009, 167, allerdings eine Absage erteilt und für einen Bauvertrag wie folgt entschieden: „Zur Erfüllung des Bauvertrags sind in zahlreichen Fällen Mitwirkungshandlungen des Bestellers erforderlich. Sofern sich aus dem Gesetz oder den vertraglichen Vereinbarungen nichts anderes ergibt, handelt es sich bei diesen Mitwirkungshandlungen regelmäßig um Obliegenheiten“. Kritisch s. dazu Kappellmann, Die erforderliche Mitwirkung nach § 642 BGB, § 6 VI VOB/B – Vertragspflichten und keine Obliegenheiten, NZBau 2011, 193. Pro Obliegenheit s. Peters, Die Mitwirkung des Bestellers bei der Durchführung eines Bauvertrags, NZBau 2011, 641.

694

Witzel

Implementierung von Standardsoftware

Rz. 216 G

nahmen zur organisatorischen Implementierung ohne erheblichen Einsatz des Anwenders denkbar sind, nicht angemessen. Soweit in der Literatur andere Auffassungen vertreten werden1, wird dabei zu stark auf die reine Entwicklungs- oder Anpassungsleistung abgestellt, die aber nicht den entscheidenden Anteil der Leistungen ausmacht. Auch hier bleibt wiederum kein anderer Weg, als mit gestalterischen Maßnahmen einzugreifen und die Mitwirkungsobliegenheit zu einer Mitwirkungspflicht zu machen2. 3. Erforderlichkeit der Mitwirkung des Anwenders bei Anpassung und Einführung (Implementierung) von Standardsoftware a) Mitwirkung des Anwenders als Voraussetzung für den Projekterfolg Wie oben festgestellt, ist eine der Besonderheiten eines IT-Projekts die ge- 215 steigerte Informations- und Mitwirkungspflicht des Anwenders. Mitwirkungsleistungen werden zwar in den Verträgen meist erwähnt, aber nicht im Detail ausgestaltet und – schlimmer noch – im Projekt selbst erheblich vernachlässigt. Der Anwender stellt sich im Übrigen häufig vor, mit der Zahlung der Vergütung seinen wesentlichen Beitrag zum Gelingen des Projekts zu leisten. Dabei wird übersehen, dass der Softwareanbieter Leistungen des Anwenders zur Erfüllung der vertraglichen Ziele benötigt. Die Leistungen des Anwenders können unterschiedliche Ausprägungen haben: – inhaltliche Leistungen (Bekanntgabe und Erläuterung der Geschäftsprozesse und Unternehmensstruktur). Die Mitwirkung liegt insoweit auch in personellen Beistellungen; der Anwender muss Mitarbeiter zur Verfügung stellen, die den Softwareanbieter unterstützen. – organisatorische Leistungen (Vorbereitung von Meetings, Erteilung von Zugangsberechtigungen zu Räumen und vorhandenen Systemen) – Sachleistungen (IT-Infrastruktur, Hardware, Netzanbindungen, Kommunikationseinrichtungen, Räume, Software und Lizenzen, Testdaten und Testfälle) Ein IT-Projekt kann nur zum Erfolg führen, wenn die betriebswirtschaftli- 216 chen und organisatorischen Anforderungen des Anwenders umfassend berücksichtigt sind. Eine solche umfassende Berücksichtigung ist ohne intensive Mitwirkung des Anwenders nicht möglich. Ein IT-Projekt ist nicht erfolgreich zu realisieren, wenn der Anwender seine umzusetzenden Geschäftsprozesse nicht definiert, seine Datenstrukturen und sein Berichtswesen nicht festlegt oder anhand von ihm erstellter Testdaten und Testfälle nicht die Funktionsfähigkeit der Standardsoftware und ihrer Anpassungen prüft. Der Umfang der Leistungen des Anwenders wird häufig unterschätzt. Bei üblichen Einführungs-Projekten muss der Anwender häufig 30–50 % des extern vergebenen Aufwands zusätzlich selbst erbringen3: 1 Koch, IT-Projektrecht, Rz. 173 und Redeker, IT-Recht in der Praxis, Rz. 432. 2 S. dazu unten Rz. 217 ff. 3 Streitz, IT-Projekte retten, S. 57.

Witzel

695

G Rz. 217 Projektphase

Sonderregelungen Anteil des Anwenders in %

Idee, Planung, Studie

10 %

Angebotseinholung, Auswahl des Softwareanbieters, Vertrag

10 %

Definition der Anforderungen

20 %

Testumgebung, Tests und Abnahmen

15 %

Benutzereinweisung

5%

Projektmanagement

20 %

Qualitätssicherung

20 %

Summe

100 %

b) Vertragliche Vereinbarungen zur Mitwirkung aa) Notwendigkeit klarer Vereinbarungen zu Inhalt und Umfang der Mitwirkung 217

Umfang und Qualität der Mitwirkung werden – ohne explizite Regelung im Vertrag – von Seiten des Anwenders häufig unterschätzt. Ausdruck findet diese Haltung in allgemeinen, unbestimmten und unklar gehaltenen vertraglichen Regelungen und Vereinbarungen, beispielsweise: „Die Software wird entsprechend den besonderen Anforderungen des Kunden vom Anbieter entwickelt. Der Kunde stellt für die Unterstützung der erforderlichen Arbeiten ein eigenes Projektteam in einem zeitlich und qualitativ angemessenen Umfang zur Verfügung …“1

oder „Der Auftraggeber unterstützt den Auftragnehmer bei der Leistungserbringung in angemessenem und notwendigem Umfang, insbesondere auch durch kompetente Ansprechpartner für fachliche Fragen.“

218

Die Anforderungen an die Mitwirkung variieren und müssen je nach Einzelfall differenziert werden. Die Mitwirkung bei der Implementierung eines „fertigen“, branchenbezogenen Finanzbuchhaltungspakets kann sich deutlich einfacher gestalten als die Einführung von SAP ERP, MySAP.com oder vergleichbar komplexer unternehmenssteuernder Software. Im Interesse der Rechtssicherheit und der Klarheit der Mitwirkungspflichten ist es daher dringend ratsam, in einem Vertrag alle Mitwirkungspflichten des Anwenders festzulegen. Sonst kann der Anwender nicht ablesen, in welchem Umfang er bzw. seine Mitarbeiter in das Projekt eingebunden werden. Den Softwareanbieter trifft insoweit eine entsprechende Beratungspflicht. Sofern es nicht möglich ist, die Mitwirkungsleistungen im Zeitpunkt des Vertragsschlusses abschließend festzulegen, bietet es sich entweder an, im Rahmen 1 Witte, in: Redeker, Handbuch der IT-Verträge, Kap. 1.4, Rz. 18.

696

Witzel

Implementierung von Standardsoftware

Rz. 220 G

der Konzeptionierungsphase weitere Detaillierungen vorzunehmen oder auch für die Mitwirkung die Anwendbarkeit des Änderungsmanagements zu vereinbaren. Denkbare zu vereinbarende Mitwirkungsleistungen sind Folgende:

219

– Versorgung des Softwareanbieters mit allen Informationen, die zur Erbringung der Leistung erforderlich sind, etwa Beibringung von fachlichen Anforderungen, Abnahmekriterien und Testfällen1; – Mitwirken am Erstellen des Soll-Konzepts und beauftragter Pflichtenhefterstellung2; – Teilnahme an Workshops zur Ermittlung von Anforderungen; – Benennen und Bereitstellen eines Ansprechpartners für die Erteilung verbindlicher und fachlich richtiger Informationen zu allen Fragen des Softwareanbieters; – Mitteilung, in welche Datenfelder des neuen Programms (Alt-)Daten übernommen werden sollen3; – Bereitstellen von Testdaten in geeigneter Form4; – Durchführen eines Probelaufs5; – Durchführung von Tests und Abnahmeprüfungen; – Installation von Versionen und Releases auf den produktiven Systemen; – Einspielen von Korrekturversionen und Patches auf produktiven Systemen. Eine vertragliche Formulierung könnte wie folgt aussehen:

220

Für die reibungslose Abwicklung des Einführungsprojekts werden die folgenden Leistungen des Auftraggebers benötigt: – Der Auftraggeber stellt alle benötigten Unterlagen, Dokumente und Informationen kostenlos zur Verfügung. – Soweit es die einschlägigen Datenschutzgesetze zulassen, dürfen Unterlagen und Dokumente des Auftraggebers in die Geschäftsräume des Auftragnehmers mitgenommen werden. – Für Abstimmungen, Meetings oder Workshops stellt der Auftraggeber kostenlos Besprechungsräume zur Verfügung. – Für die im Rahmen der Erarbeitung und Erstellung der Einsatzstudie notwendigen Abstimmungen stellt der Auftraggeber zu den jeweils rechtzeitig vereinbarten Terminen fachkundige Ansprechpartner zur Verfügung.

1 2 3 4 5

OLG Köln v. 7.2.1992 – 19 U 117/91, CR 1992, 470 = NJW-RR 1992, 761. OLG Oldenburg v. 12.2.1986 – 3 U 43/85, CR 1986, 552. OLG Köln v. 21.1.1994 – 19 U 100/93, CR 1994, 538. BGH v. 13.7.1988 – VIII ZR 292/87, CR 1989, 102. LG Verden, CR 1986, 26.

Witzel

697

G Rz. 220

Sonderregelungen

– Der Auftraggeber stellt fachkundige Mitarbeiter zur Verfügung, die auf Grundlage der Festlegungen der Einsatzstudie in Abstimmung mit dem Auftragnehmer für den Systemtest Testfälle definieren und Testszenarien entwickeln, die zu einer ausreichenden Testabdeckung der Anwendungen geeignet sind. – Der Auftraggeber stellt zu den im Projektplan definierten Terminen Testdaten in ausreichender Menge und Vielfalt zur Verfügung. – Der Auftraggeber stellt einen zentralen Ansprechpartner zur Verfügung, der Projekt-relevante Fragen entscheiden kann. Des Weiteren benennt der Auftraggeber fachliche Ansprechpartner zur Klärung inhaltlicher Fragen. – Für den Integrationstest stellt der Auftraggeber über entsprechende Kommunikationsmechanismen die Anbindung an die in den Test einzubeziehenden Nachbarsysteme sicher. – Abnahmetests erfolgen mit der vom Auftraggeber bereitgestellten Infrastruktur beim Auftraggeber.

Ebenfalls denkbar wäre folgende Formulierung: Vorbehaltlich einer weitergehenden Festlegung im Pflichtenheft hat der Auftraggeber folgende Mitwirkungspflichten: – Teilnahme an sämtlichen Workshops und Besprechungen des Lenkungsausschusses; – Bereitstellung der erforderlichen Hardware; – Bereitstellung eines Datenbankservers, der den Hardwareempfehlungen des Auftragnehmers gemäß Pflichtenheft entspricht, mit einer ausreichenden Anzahl von Clients; – Bereitstellung von Datenfernzugang per SSH oder VPN Site2Site, wobei dieser nur auf Anforderung für einen vom Auftraggeber festgelegten Zeitraum zur Verfügung gestellt wird; – Bereitstellung von bis zu drei Arbeitsplätzen für die Mitarbeiter des Auftragnehmers; – Durchführung von Datensicherungen in regelmäßigen Abständen; – Anzeige von Sachmängeln; – Bereitstellung von Testdaten, die den vom Auftragnehmer mitgeteilten Anforderungen genügen; – Abstimmung und Abnahme der vom Auftragnehmer vorgeschlagenen Testfälle; – Abnahme der Vertragssoftware basierend auf den abgestimmten und abgenommenen Testfällen; – Sofern im Pflichtenheft festgelegt Durchführung der Altdatenübernahme.

698

Witzel

Implementierung von Standardsoftware

Rz. 221 G

Soweit dies ausdrücklich als Mitwirkungspflicht des Auftraggebers im Pflichtenheft festgelegt wird: – – – –

Entwicklung von Reports und statistischen Auswertungen; Bereitstellung/Entwicklung von Schnittstellen; Mitwirkung bei der Durchführung von Tests, basierend auf den Testfällen; Beseitigung von Anwenderfehlern und Unterstützung bei der Bereinigung von mangelhaften Daten; – Mängelbeseitigung bei vom Auftraggeber erstellten mangelhaften Reports und Schnittstellen; – Durchführung der Schulung der Endanwender.

Aus Sicht des Anwenders scheint eine detaillierte Regelung der Mitwirkung 221 auf den ersten Blick eher nachteilig zu sein. Auf den zweiten Blick wird jedoch klar, dass die Mitwirkungsleistungen bei detaillierter Beschreibung und Festlegung eines Terminplans auch rechtzeitig zur Verfügung stehen und damit unnötige Eskalationen im Projekt vermieden werden können. Ähnlich wie beim Leistungsumfang des Softwareanbieters wird auch bei der Mitwirkung des Anwenders erst Klarheit geschaffen, wenn der Vertrag darüber Aufschluss gibt, was zu leisten ist. Häufiges Thema – vor allem in Projekten mit Schieflage – sind Testdaten. Selbst wenn klar ist, dass der Anwender die Lieferung von Testdaten an sich schuldet, kann offen geblieben sein, welchen Umfang diese Testdaten haben sollen, in welcher Qualität und zu welchem Zeitpunkt sie geliefert werden müssen. Streitigkeiten darüber können nur vermieden werden, wenn der Vertrag – oder eine seiner Anlagen – bestimmt, was genau wann in welchem Umfang zu liefern ist. Folgende vertragliche Regelung erscheint nicht ausreichend: 0. Mitwirkung des Auftraggebers 0.1. Dem Auftraggeber obliegt die erforderliche Mitwirkung. Die Mitwirkung des Auftraggebers stellt in jedem Fall eine vertragliche Obliegenheit und keine vertragliche Leistungspflicht dar. 0.2. Der Auftragnehmer wird die aus seiner Sicht vom Auftraggeber zu erbringenden Mitwirkungsleistungen jeweils rechtzeitig einfordern und den Auftraggeber auf die Folgen einer unterbliebenen Mitwirkung hinweisen. Eine etwa unzureichende Mitwirkung wird der Auftragnehmer unverzüglich gegenüber dem Auftraggeber detailliert schriftlich rügen. Unterbleibt die Rüge, kann sich der Auftragnehmer auf eine unzureichende Mitwirkung nicht berufen.

Witzel

699

G Rz. 222

Sonderregelungen

bb) Umfang der Mitwirkungsleistung als Grundlage für Kalkulation und Zeitplanung 222

Die Mitwirkungsleistungen nehmen bei IT-Projekten einen über andere (Werk-)Verträge weit hinausgehenden Umfang an. Demzufolge braucht der Anwender eine konkrete Festlegung der Mitwirkungsleistungen, um die Projektkosten vollständig kalkulieren zu können.

223

Der Anwender muss eine zeitliche Kalkulation für die Erbringung der Mitwirkung vornehmen. Bei der Anforderungsermittlung müssen personelle Ressourcen abgestellt werden, die dann naturgemäß nicht für das Tagesgeschäft zur Verfügung stehen. Gerade bei kleineren Unternehmen und Organisationen stellt das Bereitstellen von Mitarbeitern im für das Projekt erforderlichen Umfang eine große Herausforderung dar. Wenn der Anwender seine Mitwirkung mit dem vorhandenen Personal nicht leisten kann, muss er Dritte beauftragen, was zu einer Erhöhung der Projektkosten führt.

224

Für Tests zu liefernde Echtdaten können von erheblichem Umfang sein, die von einem Unternehmen unter Umständen über mehrere Lieferungen hinweg aus einem laufenden Produktivsystem zu extrahieren und an den Softwareanbieter zu liefern sind. Die Daten können dem Softwareanbieter zudem nicht „einfach auf den Hof gekippt werden“, sondern sind auf Konsistenz und Aktualität zu prüfen, was ebenfalls Zeit kostet. Nur eine genaue Darstellung der Mitwirkungsleistungen ermöglicht die Ermittlung der Gesamtkosten des Projekts, eine realistische Zeitplanung sowie eine Kosten/Nutzen-Analyse und ein Controlling.

225

Der Beratungsaufwand und die Einhaltung der geplanten Termine für die einzelnen Anwendungen hängen jedoch entscheidend von der Intensität der Mitarbeit des Auftraggebers bei der Projektrealisierung ab. Es wird schon bei klassischen Vorgehensmodellen (vgl. Kap. H) vorausgesetzt, dass der Auftraggeber etwa den zweifachen Aufwand des Auftragnehmers durch eigene Kapazitäten einplant. Bei modernen agilen Methoden (vgl. Kap. H) wird der Anwender noch stärker eingebunden und muss daher sogar höhere Eigenaufwände einrechnen. cc) Rechtliche Qualifizierung der Mitwirkungsleistungen im Vertrag

226

Die Qualifikation der Mitwirkung als reine Obliegenheit im Sinne von § 642 BGB würde der Bedeutung der Mitwirkung im IT-Projekt nicht gerecht werden. Bei besonders wichtigen Mitwirkungspflichten ist es im Hinblick auf die schwache Ausgestaltung des § 642 BGB zu empfehlen, die Mitwirkung als vertragliche Hauptpflicht festzulegen und für den Fall des Verzugs, der Schlecht- oder Nichterfüllung vertragliche Sanktionen wie Vertragsstrafen oder Verzugsregelungen vorzusehen. Der Status der Mitwirkungsleistungen muss sich also aus dem Vertrag ergeben. Der oben dargestellte Formulierungsvorschlag1 schützt den Auftragnehmer nicht, wird 1 S. Rz. 220.

700

Witzel

Implementierung von Standardsoftware

Rz. 230 G

aber auch dem Auftraggeber nicht gerecht: Ohne intensive Mitarbeit wird der Projekterfolg ausbleiben. Wenn sich ein Anwender nicht darauf einlassen will, dass alle Mitwirkungsleistungen pauschal in den Status einer Hauptpflicht erhoben werden, bietet sich an, bei den einzelnen Mitwirkungsleistungen nach Einordnung als Hauptpflicht oder als Obliegenheit zu differenzieren. Mitwirkungsleistungen, die konkret und detailliert beschrieben werden können, sind eher als Hauptpflichten akzeptabel als solche, die noch sehr unbestimmt und vage sind. c) Folgen unzureichender Mitwirkung Erfüllt der Anwender seine Mitwirkungspflichten nicht, kommt er in Gläubigerverzug mit der Folge, dass sich die Haftung des Softwareanbieters für fehlende Arbeiten auf Vorsatz oder grobe Fahrlässigkeit beschränkt1.

227

Beruht die verspätete Leistung des Softwareanbieters darauf, dass der An- 228 wender eine notwendige Mitwirkung unterlassen hat, tritt kein Verzug des Softwareanbieters ein. Dies aber erst dann, wenn die Mitwirkung trotz Unterstützung unterbleibt. Wenn nicht explizit im Vertrag geregelt ist, dass die Mitwirkung mehr ist als eine Obliegenheit im Sinne von § 642 BGB, kann der Softwareanbieter keinen Schadensersatz statt der Leistung verlangen2. Der Softwareanbieter kann sich auf eine fehlende Mitwirkung des Anwen- 229 ders nur berufen, wenn er den Anwender zur Erteilung der erforderlichen Informationen aufgefordert und ihm eine Frist zur Mitwirkung unter Kündigungsandrohung nach § 643 BGB gesetzt hat. Der Softwareanbieter muss den Anwender darüber hinaus auf erkennbar unzureichende Vorgaben seitens des Anwenders hinweisen und ihn bei der Erfüllung der Mitwirkungsleistungen unterstützen, wenn er merkt, dass dieser mit der Erfüllung überfordert ist. Mögliche Formulierungen lauten3:

230

Kann sich der Auftragnehmer im Falle der Nichteinhaltung von Meilensteinen und Terminen darauf berufen, dass die Nichteinhaltung überwiegend auf verzögerte und/oder unzureichende Mitwirkung seitens des Auftraggebers zurückzuführen ist, werden sich die Vertragspartner einvernehmlich auf eine angemessene Terminverschiebung verständigen. Der Auftragnehmer kann sich auf verzögerte und/oder unzureichende Mitwirkung nicht berufen, wenn der Auftragnehmer die Mitwirkung nicht rechtzeitig eingefordert und den Auftrag-

1 BGH v. 28.6.1994 – X ZR 95/92, CR 1995, 265. 2 OLG Köln v. 31.1.1992 – 19 U 114/91, CR 1992, 333. 3 Der erste Formulierungsvorschlag ist mehr anwenderfreundlich, der zweite und dritte mehr anbieterfreundlich.

Witzel

701

G Rz. 230

Sonderregelungen

geber auf die Konsequenzen bei Verzögerung und/oder unzureichender Erbringung der Mitwirkung hingewiesen hat.

oder

Gerät der Auftraggeber mit der vereinbarten Mitwirkung in Verzug, wird der Auftragnehmer dem Auftraggeber eine angemessene Nachfrist zur Erbringung der Mitwirkungsleistungen setzen und ist im Übrigen berechtigt, Schadensersatz zu verlangen. Eine Nachfristsetzung hat schriftlich an die Projektleitung zu erfolgen und ist mit der Erklärung zu verbinden, dass nach erfolglosem Fristablauf Schadensersatz geltend gemacht wird. Gerät der Auftraggeber mit für die Einhaltung definierter Meilensteine erforderlichen Mitwirkungsleistungen in Verzug, ist der Auftragnehmer nach Ablauf einer Karenzzeit von … Tagen/ Wochen zur Geltendmachung einer Vertragsstrafe in Höhe von … Euro berechtigt. Dies gilt nicht, sofern der Auftraggeber die verzögerte Mitwirkung nicht zu vertreten hat. Eine Vertragsstrafe wird auf etwaige Schadensersatzansprüche angerechnet. Die Einrede des Fortsetzungszusammenhangs ist ausgeschlossen. Die mit dem Auftragnehmer vereinbarten Termine verschieben sich bei verzögerter Mitwirkung um angemessene Zeit, die Parteien werden den Projektstrukturplan entsprechend anpassen.

oder

Sofern der Auftraggeber, – bei einem verbindlichen Termin seine Mitwirkungs- und Kooperationspflichten trotz einer schriftlichen Aufforderung mit angemessener Fristsetzung nicht erfüllt oder – seine Mitwirkungs- und Kooperationspflichten nicht innerhalb der im Projektplan festgelegten Meilensteine erfüllt, verlängern sich die für die Leistungserbringung des Auftraggebers festgelegten Termine und Meilensteine entsprechend. Der Auftragnehmer wird den Auftraggeber über Anpassungen und Verlängerungen informieren und wird dabei auf die konkrete nicht erfüllte Mitwirkungs- und Kooperationspflicht Bezug nehmen. Sofern der Auftraggeber seine Mitwirkungs- und Kooperationspflicht nicht – innerhalb einer angemessener schriftlich gesetzter Frist oder – innerhalb der Meilensteine, wie im Projektplan festgelegt, erfüllt, ist der Auftragnehmer im Übrigen berechtigt, dem Auftraggeber eine angemessene Nachfrist zu setzen. Erfüllt der Auftraggeber seine Mitwirkungspflichten auch nicht innerhalb der Nachfrist, ist der Auftragnehmer berechtigt,

702

Witzel

Implementierung von Standardsoftware

Rz. 231 G

diesen Vertrag außerordentlich zu kündigen, wenn die Mitwirkungs- und Kooperationspflicht zur Erreichung des Vertragszwecks im Zeitpunkt der Kündigung notwendig ist. Darüber hinaus kann der Auftragnehmer nach der schriftlichen Nachfristsetzung oder dem Ablauf des entsprechenden Meilensteins eine Erstattung des Mehraufwands verlangen, der durch die Nichterfüllung der Mitwirkungspflichten entstanden ist. Die Erstattung wird auf Basis der aktuellen Preisliste des Auftragnehmers berechnet.

VI. Weitere Leistungen des Softwareanbieters 1. Dokumentation, Form und Art der Dokumentation a) Grundsätzliches zur Bedienungsanleitung (Anwenderdokumentation) Beim Thema Dokumentation1 klaffen die Vorstellungen der immer noch 231 zur Anwendung kommenden Rechtsprechung und die aktuellen technischen Gegebenheiten sehr weit auseinander. Es scheint noch Einigkeit zwischen Informatikern und Juristen zu bestehen, dass eine Dokumentation zu liefern ist. Spätestens bei der Frage, in welcher Form eine Dokumentation zu liefern ist, gehen die Auffassungen völlig auseinander. Es ist weitgehend unstreitig, dass sowohl zu Hardware als auch zu Software eine Dokumentation – zumindest eine Bedienungsanleitung – gehört. Dies gilt jedenfalls, wenn vertraglich nichts anderes vereinbart ist. Laut BGH2 ist ein Handbuch – ohne besondere Erwähnung – ein wesentlicher Teil der geschuldeten Leistung: „Handbücher, auch als Bedienungsanleitungen oder Dokumentationen bezeichnet, enthalten – in Wort oder graphischer Darstellung – eine Beschreibung des technischen Aufbaus der Anlage, ihrer Funktion, gegebenenfalls der Möglichkeiten der Kombination mit anderen Geräten sowie ihrer Veränderung oder Ergänzung. Sie vermitteln die Summe aller Kenntnisse, die erforderlich sind, um die Anlage bedienungsfehlerfrei und zur Verwirklichung des mit ihrer Anschaffung vertraglich vorgesehenen Zwecks nutzen zu können. Sie ergänzen und konservieren schon vorhandenes Wissen des Benutzers zum Gebrauch der Anlage und verleihen der dem Lieferanten obliegenden Einweisung in die Gerätehandhabung Dauer. Das verkörperte Nutzungswissen löst sich damit von der subjektiven Beziehung zum Lieferanten und wird gleichsam Teil der Anlage.“ Für Software hat der BGH auf diese Entscheidung verwiesen3. Unter Handbuch versteht die Rechtsprechung ein Dokument in ausgedruckter Form. 1 Bergmann, CR 1999, 455, speziell zu Handbüchern für Softwareanwender, Bericht v. 7. Deutschen EDV-Gerichtstag; Ulmer, ITRB 2001, 61. 2 BGH, CR 1989, 189 zu Hardware und Betriebssystem. 3 BGH v. 4.11.1992 – VIII ZR 165/91, CR 1993, 422; BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207 für Standardsoftware und für Individualsoftware: BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681 und BGH, JW 2001, 1718.

Witzel

703

G Rz. 232 232

Sonderregelungen

Fehlt die Dokumentation vollständig oder teilweise, ist die Leistung des Softwareanbieters insoweit (teilweise) nicht erfüllt und der Anwender kann Ansprüche aus (teilweiser) Nichterfüllung einer Hauptleistungspflicht des Vertrages geltend machen1. b) Einzelheiten zur Bedienungsanleitung aus der Rechtsprechung

233

Die Anforderungen an die zu liefernde Dokumentation können sehr vielfältig sein. Die von der Rechtsprechung aufgestellten Grundsätze beantworten einige der Fragen, aber nicht alle. – Auch ohne dass etwas Besonderes vereinbart ist, gehört zur Software ein Handbuch oder eine Bedienungsanleitung, und zwar mit einer Funktion, die kurz als Perpetuierungsfunktion bezeichnet werden kann. Dies bedeutet, dass Handbücher das vorhandene Wissen des Benutzers konservieren und ergänzen und der Einweisung Dauer verleihen.

– –

–

–

Die Benutzerdokumentation muss so beschaffen sein, dass sie vom Anwender und dessen Personal mit dessen EDV-Kenntnissen und ggf. einer Schulung verstanden werden kann2. Zumindest zentrale Teile sollten in deutscher Sprache gehalten sein3. Handbücher im Sinne der Bedienungsanleitung gehören sowohl zur Standardsoftware als auch zu „angepasster“ Software sowie zu Individualsoftware. Damit keine Dokumentation in diesem Sinne geschuldet ist, müsste dies explizit vereinbart werden. Meist steht eine Bedienungshilfe „online“ zur Verfügung: Es ist jedoch unklar, ob und inwieweit dies ausreicht. Daher sollten die Vertragspartner in Individualverträgen ausdrücklich festlegen, wie die Dokumentation beschaffen sein soll, wie sie aufzubauen ist und welchen Umfang sie haben soll. Dabei sollten die Vertragspartner auch regeln, wie sich die Online-Hilfen in die geschuldete Dokumentation einfügen, insbesondere, ob und inwieweit sich Papier-Hilfen erübrigen4. Eine Programmbeschreibung ist regelmäßig, außer wenn sich dies unmittelbar aus dem Vertrag ergeben würde, nicht geschuldet. Es kann sich aber aus den Umständen ergeben, dass z.B. ein Datenmodell mitgeliefert werden muss. Die Anforderungen an solche Dokumentationen sind umso größer, je mehr Veränderungen der Anwender an der Software selbst vornehmen will.

1 BGH v. 4.11.1992 – VIII ZR 165/91, CR 1993, 422. 2 OLG Hamm v. 11.12.1989 – 31 U 37/89, CR 1990, 715. 3 OLG Düsseldorf v. 18.8.1994 – 2 U 245/93, CR 1994, 753 = GRUR 1994, 902; OLG München, NJW-CoR 1999, 248. 4 Auslieferung auf einem Datenträger genügt nicht, wenn im Vertrag ein Handbuch erwähnt ist, LG München I, BB Beilage 14/1994; die auf Festplatte gespeicherte Dokumentation ersetzt nicht das gedruckte Exemplar, LG Stuttgart, CR 1992, 277.

704

Witzel

Implementierung von Standardsoftware

Rz. 236 G

d) Offene Fragen, insbesondere weitere Arten der Dokumentation Der BGH behandelt im Grunde nur die Anwenderdokumentation, d.h. die 234 Bedienungsanleitung. Es gibt allerdings weitere Arten von Dokumentation, die auch bei Anpassung, Einführung und Implementierung von Standardsoftware eine Rolle spielen können, insbesondere, wenn der Anwender die Software auch selbst customizen, bearbeiten und pflegen will: – – – – – – – – – –

Installationsbeschreibung; Quellcodedokumentation oder Kommentierung des Quellcodes; Beschreibung der Entwicklungsumgebung; Dokumentation der bei Generierung/Kompilierung entstandenen Ergebnisse sowohl in Text als auch in elektronischer Form; Dokumentation der bei Tests entstandenen Ergebnisse; Dokumentation der bei Anpassung/Einstellung entstandenen Zustände, Parametrisierungsdokumentation; Dokumentation des Geschäftsmodells bzw. der Datenreferenzen, des Datenmodells; „Wartungs“- oder Pflege-Dokumentation; Administrator-Anweisung; Betriebskonzept.

Auch hier gilt, dass die Begrifflichkeiten keineswegs selbsterklärend sind 235 und sich die Vertragspartner bei der Vertragsgestaltung Gedanken darüber machen sollten, welche Arten von Dokumentation Gegenstand der Lieferung sein sollen und was sich die Vertragspartner unter den einzelnen Dokumenten inhaltlich vorstellen. Die Erstellung guter Dokumentation ist aufwendig und zeitintensiv. Häufig bleibt dem Softwareanbieter für die Erstellung solcher Dokumente zu wenig Zeit, was dazu führt, dass sie entweder überhaupt nicht vorhanden sind oder nicht so selbsterklärend, dass ein Dritter damit arbeiten könnte. Die Vertragspartner sollten daher nicht nur vertragliche Regelung treffen, sondern ggf. die beim Softwareanbieter vorhandene Dokumentation auf Umfang und Inhalt überprüfen und festlegen, ob – im Zweifel gegen Vergütung – nachgebessert werden muss. Weiteres Thema ist die Form der Dokumentation. Im Bereich der Anwen- 236 derdokumentation dürfte es schwierig sein, einen Softwareanbieter zu finden, der noch Handbücher zur Verfügung stellt. Entweder findet sich die Dokumentation als pdf-Dokument auf einer mitgelieferten CD-ROM oder integriert als HMTL-Dokument (das sich vielleicht nur erschwert ausdrucken lässt) oder die Dokumentation findet sich bei web-basierten Anwendungen in sog. „Wikis“1. Selbst Anwender sind sich im Klaren, dass ihnen keine Handbücher mehr geliefert werden, im Konfliktfall berufen sich An1 Ein „Wiki“ ist ein Hypertext-System für Websites, deren Inhalte nicht nur vom Benutzer gelesen, sondern auch online direkt im Browser geändert werden können, www.wikipedia.org.

Witzel

705

G Rz. 237

Sonderregelungen

wälte allerdings gerne auf die Rechtsprechung zu Handbüchern, was bei Gerichten immer noch Gehör findet. 237

Ebenso Thema ist die Sprache der Dokumentation. Selbst bei deutschsprachigen Softwareanbietern wird Dokumentation häufig dann nur in Englisch erstellt, wenn ein internationaler Marktauftritt geplant ist. Im Hinblick auf die Kosten und den zeitlichen Aufwand werden Softwareanbieter versuchen den Aufwand für die Erstellung deutscher Versionen der Dokumentation zu vermeiden. d) Fälligkeit und Mangelhaftigkeit der Bedienungsanleitung1 aa) Fälligkeit

238

Bei komplexeren Projekten und insbesondere bei solchen, in denen der Anwender häufig Änderungswünsche geäußert hatte, die dann auch realisiert wurden, wird man vom Softwareanbieter nicht zeitgleich mit der Fertigstellung auch die Fertigstellung der Dokumentation verlangen können2: „Der Anspruch des Bestellers einer individuell auf seine Bedürfnisse zugeschnittenen Software auf Lieferung einer zum Betrieb der Software erforderlichen Dokumentation wird grundsätzlich erst mit dem Abschluss der Arbeiten an dem Programm fällig. Lässt sich eine abweichende Vereinbarung nicht feststellen, kann von einem Softwarehersteller nicht ohne weiteres erwartet werden, dass er ohne Rücksicht auf mögliche künftige Erweiterungen und Änderungen des Programms in jedem Stadium seiner Arbeiten eine diesen entsprechende Dokumentation gestaltet.“

239

Daraus darf aber nicht abgeleitet werden, dass der Softwareanbieter immer erst am Ende des Projekts mit der Erstellung der Dokumentation beginnen dürfte. Dies kann vielmehr nur für Funktionalitäten gelten, die Softwareanbieter und Anwender erst im Laufe des Projekts festlegen. bb) Mangelhafte Bedienungsanleitung

240

Ist die Dokumentation (die Bedienungsanleitung) falsch, ist das Programm selbst mangelhaft. Die Dokumentation kann dadurch Mängel aufweisen, dass sie unvollständig und/oder unklar abgefasst ist. Typische Mängel in der Dokumentation sind folgende: – Die Texte sind zu kurz und daher außer für Eingeweihte unverständlich. – Die Beschreibung eines Bilds ist erst durch Umblättern auf der nächsten Seite zu finden. – Es gibt zu viele Verweise auf andere Kapitel und Seiten.

1 Zur Mangelhaftigkeit der Dokumentation siehe auch ausführlich Koch, Computervertragsrecht, S. 656, Rz. 127 ff. 2 BGH v. 20.2.2001 – X ZR 9/99 – Warentermingeschäft II, CR 2001, 367.

706

Witzel

Implementierung von Standardsoftware

Rz. 246 G

– Funktionen werden wie in einem Nachschlagewerk ohne Angabe der funktionalen Zusammenhänge sequentiell beschrieben, so dass der Leser kein umfassendes Programmverständnis entwickeln kann. – Unübliche Eingaben, die programmtechnisch notwendig sind, werden nicht besonders herausgestellt. – Kürzel des Programms werden in die Beschreibung übernommen. – Die Dokumentation verwendet nur für Programmierer verständlichen Fachjargon. – Suchfunktionen werden erschwert, weil es zum Beispiel einmal heißt „Anforderung zum Druck“ und dann „Druckanforderung“. e) Beschreibung der Dokumentation im Vertrag Da die Anforderungen an die Dokumentation vielfältig sind, aber auch von 241 Projekt zur Projekt variieren, müssen die Vertragspartner entweder im Vertrag selbst oder in der Leistungsbeschreibung Vereinbarungen treffen, aus denen sich ergibt, welche Dokumentation in welcher Form und in welchem Umfang geschuldet ist. Ebenfalls sinnvoll können Vereinbarungen zu Qualitätskriterien, Lay-Out und Struktur der Dokumentation sein. Die Vertragspartner sollten darauf achten, dass sämtliche Vereinbarungen, 242 die insoweit getroffen werden, nicht nur die Standardsoftware in nicht individualisierter Form, sondern die angepasste Software betreffen. Anwenderdokumentation („Benutzerhandbuch“): Neben der Online-Hilfe 243 sollte auch eine gedruckte – oder zumindest ausdruckbare – Unterlage zur Verfügung stehen, die den Einstieg in die (angepasste) Software ermöglicht und Konzepte und Verfahren beinhaltet1. Die sog. Systemdokumentation umfasst Angaben technischer Natur, die für Wartung, Pflege und Betrieb der (angepassten) Software wichtig sind. Dies sind zum Beispiel Kennzahlen und Kapazitätsanforderungen oder die technische Ausgestaltung von Ressourcenanforderungen.

244

In der Betriebsdokumentation sollten die Angaben enthalten sein, die für die 245 Überwachung und Aufrechterhaltung des Betriebs der (angepassten) Software benötigt werden. Dazu zählen eine Prozessübersicht, eine Beschreibung des Verhaltens der Software in Ausnahmesituationen, durchzuführende Kontroll- und Überprüfungstätigkeiten, Durchsicht der Systemmeldungen und Kapazitätsaspekte. Mit der Installationsdokumentation wird der vom Softwareanbieter hinter- 246 lassene Zustand – einschließlich der erfolgten Parametrisierung – dokumentiert. Ist die Parametrisierung sehr umfangreich kann diese auch Gegenstand einer eigenen Parametrisierungsbeschreibung sein. 1 Zu den Anforderungen siehe www.edv-gt.de/Tagung99/ak99/Saarbrücker%20 Standard99.htm.

Witzel

707

G Rz. 247 247

Sonderregelungen

Eine Formulierung zur Dokumentation könnte lauten: Der Auftragnehmer erstellt die für die Durchführung des Projekts „…“ (einschließlich Parametereinstellung, Anpassung und Erweiterung sowie Zusätze) geeigneten Dokumentationen in deutscher und in englischer Sprache: – Projekt- und Ergebnisdokumentation („Projekthandbuch“) einschließlich Dokumentation der Befundsicherung, Dokumentation des Zustandes eines Gegenstandes der Leistung zum Zeitpunkt der Übergabe oder Produktivsetzung („Beweissicherung mit Datumsangaben und Versionsnummern“); – Anwendungsdokumentation (inklusive Online-Hilfe) und Systemadministrationsdokumentation; – Programmbeschreibungen, einschließlich Datenmodell; – Aufstellung der Entwicklungswerkzeuge. Die Ausgestaltung der Dokumentation im Detail wird zwischen den Vertragspartnern abgestimmt und schriftlich festgehalten. Die Dokumentationen sind für die Standardsoftware bei Installation zu übergeben. Bei der Lieferung von Updates wird die erweiterte Dokumentation zeitnah geliefert. Der Auftraggeber wird die Dokumentationen, insbesondere das Datenmodell, nicht verändern und nicht an Dritte weitergeben, es sei denn der Auftragnehmer stimmt einer solchen Weitergabe ausdrücklich schriftlich zu.

2. Quellcode-Hinterlegung, Quellcode-Herausgabe a) Quellcode-Herausgabe 248

Die Frage der Herausgabe1 des Quellcodes2 beurteilt sich im Rahmen eines Projekts über Anpassung, Einführung und Implementierung einer Standardsoftware anders als in einem Projekt, das eine Individualsoftware zum Gegenstand hat. Bei Entwicklung von Individualsoftware dürfte es wesentlich eher dem Verständnis des Softwareanbieters entsprechen, dass er den Quell1 Burghardt, Softwareerstellung – Anspruch auf Herausgabe des Quellcodes, ITRB 2003, 53; Conrad, Wege zum Quellcode, ITRB 2005, 12; Hoeren, Die Pflicht zur Überlassung des Quellcode, CR 2004, 721; Roth, Wege zum Quellcode II, ITRB 2005, 283; Schneider, Neues zur Vorlage und Herausgabe des Quellcode, CR 2003, 1. 2 Folgende Definition findet sich unter www.wikipedia.org: „Unter dem Quelltext OR oder auch Quellcode (englisch: \“sourcecode\“) oder Programmcode versteht man in der Informatik den für Menschen lesbaren in einer Programmiersprache geschriebenen Text eines Computerpogrammes. Bevor das Programm, das der Programmierer schreibt, von einem Computer ausgeführt werden kann, muss es in Maschinensprache und letztlich in eine Folge von Bits umgesetzt werden. Dies kann entweder durch einen Compiler oder – zur Laufzeit – durch einen Interpreter geschehen.“

708

Witzel

Implementierung von Standardsoftware

Rz. 251 G

code zur Verfügung stellen muss, auch wenn es selbst in diesem Fall einer ausdrücklichen vertraglichen Regelung gegeben sollte, da ohne eine solche ggf. eine Auslegung des Vertrags erfolgen muss. Bei Standardsoftware ist der Quellcode regelmäßig das wesentliche Geschäfts- und Betriebsgeheimnis des Softwareanbieters und damit auch ein wesentlicher Vermögensgegenstand des Unternehmens. Auch bei Fragen des Quellcodes treffen daher widerstreitende Interessen 249 aufeinander: Dem Anwender droht im Fall der Insolvenz des Softwareanbieters der Verlust der Gebrauchstauglichkeit der im Einsatz befindlichen Software, da der insolvente Softwareanbieter seinen Verpflichtungen zur Pflege eventuell nicht mehr nachkommen kann. Der Quellcode und die Einräumung eines entsprechenden Bearbeitungs- und Änderungsrechts wären die Voraussetzung dafür, dass der Anwender die Software weiterhin einsetzen kann. Auf der anderen Seite steht das berechtigte Interesse des Anbieters, seinen Quellcode vor dem Zugriff Dritter zu schützen. Er hat mit hohem Investitionsaufwand seine Software entwickelt und wird versuchen, sein Know-how nach Möglichkeit geheim zu halten. Für den Insolvenzverwalter verliert der Quellcode an Wert, wenn viele oder alle Kunden des Softwareanbieters über den Quellcode ohnehin verfügen. Bei Individualsoftwareerstellung ging der BGH zunächst davon aus, dass die 250 Quellcode-Herausgabe im Zweifel – also ohne besondere Vereinbarung – nicht als Teil der Hauptleistung gemäß § 631 BGB geschuldet ist. Unklar ließ der BGH, ob die Herausgabepflicht aus Werkvertrag auch dann nicht besteht, wenn kein Pflegevertrag abgeschlossen wird1. Von diesem Prinzip ist der BGH abgewichen2. Die Herausgabe des Quellcodes kann nunmehr selbst dann als geschuldet angesehen werden, wenn nichts vereinbart wurde. Der BGH stellt dabei auf folgende – nicht abschließende – Indizien ab: – die Höhe der vereinbarten Vergütung; – eine mögliche geplante Vermarktung (in diesem Fall wird der Quellcode dann für Wartung und Pflege benötigt). Auf den ersten Blick mag die Frage der Quellcode-Herausgabe bei Projekten 251 über Anpassung, Einführung und Implementierung von Standardsoftware keine Rolle spielen: Hier lässt die BGH-Rechtsprechung auch nach wie vor den Rückschluss zu, dass keine Herausgabepflicht besteht3. Das hilft aber nur hinsichtlich des Standards weiter. Die Entscheidung des BGH vom 16.12.2003 kann aber eine Rolle spielen, wenn es um individuelle Anpassungen des Standards geht. Bei individuellen Anpassungen kann es sich auch um selbständige abgrenzbare Module in Ergänzung zum Standard handeln, die durchaus getrennt vermarktet werden können. Aus der Tatsache, dass der BGH offen gelassen hat, ob die oben erwähnten Kriterien kumula1 BGH v. 30.1.1986 – I ZR 242/83, CR 1986, 377. 2 BGH, CR 2004, 7. 3 OLG München v. 16.7.1991 – 25 U 2586/91, CR 1992, 208; OLG Celle, CR 2000, 505.

Witzel

709

G Rz. 252

Sonderregelungen

tiv erfüllt sein müssen, ob die Kriterien „Vermarktung“ und „Wartung“ ein oder zwei Indizien sind und wie sie zu gewichten sind, welche weiteren Kriterien für eine Herausgabe sprechen und ob mit der Entscheidung die frühere Rechtsprechung aufgegeben werden soll, ergibt sich die Notwendigkeit, dass die Quellcodehandhabung ausdrücklich geregelt werden sollte1. Nur damit ist hinreichend Rechtssicherheit für beide Vertragspartner geschaffen. b) Softwarehinterlegung: Escrow 252

Escrow bedeutet soviel wie Treuhand, Hinterlegung. Von Software-Escrow2 spricht man, wenn ein Anbieter von Software den Quellcode nicht an den Anwender herausgeben will, aber bereit ist, im Fall bestimmter Ereignisse (vor allem bei Insolvenz) Einblick zu gewähren. Dieses Ziel soll durch die Hinterlegung der Quelltexte nebst Dokumentation bei einem unabhängigen Unternehmen oder bei einem Notar erreicht werden, der die Unterlagen in den genannten Fällen an den Anwender herausgeben soll.

253

Ob diese Rechtsfigur tatsächlich insolvenzfest ist, ist in der juristischen Literatur umstritten. Das Thema Escrow und die vertragliche Gestaltung wird in Kap. L ausführlich beschrieben, so dass hier auf detailliertere Ausführungen verzichtet wird. Losgelöst von der immer noch höchst umstrittenen Frage der Insolvenzfestigkeit von Escrow-Vereinbarungen erscheint eine dementsprechende Absicherung des Anwenders unumgänglich, jedenfalls dann, wenn das System unternehmenskritisch ist und/oder regelmäßig aktuell gehalten werden muss. 3. Einhaltung von Qualitätsstandards, Maßnahmen zur Qualitätssicherung a) Pflicht des Anbieters zur Qualitätssicherung

254

Eine „ordnungsgemäße“ Qualitätssicherung3 gehört zu den Standardverpflichtungen, die ein Softwareanbieter zu erfüllen hat, verstärkt auch durch die in §§ 433 Abs. 1 Satz und 633 Abs. 1 BGB normierte Verpflichtung, dem Kunden eine mangelfreie Sache zu liefern. Bereits daraus ergibt sich, dass der Softwareanbieter zur vertragsgemäßen Erfüllung seiner vertraglichen Pflichten geeignete Qualitätsmanagementverfahren und -methoden einführen und anwenden muss. Im Rahmen eines Anpassungs-, Einführungsund Implementierungsprojekts muss sich die Qualitätssicherung allerdings nicht nur auf die Software an sich, sondern auf alle Leistungen erstrecken. Fehlende Qualitätssicherung auch nur einer Leistungskomponente kann 1 So auch Conrad, ITRB 2005, 12. 2 Kast/Meyer/Wray, Software Escrow, LG Hamburg v. 6.6.2001 – 406 O 16/01, CR 2002, 374; Kast/Meyer/Wray, Software Escrow: The Saga continues, CR 2004, 147; Siegel, Software Escrow, CR 2003, 941. 3 Nehfort, in: Tiemeyer, IT-Projektmanagement, 2010, S. 447 ff.; Koch, Computervertragsrecht, Rz. 272 ff.; Krcmar, Informationsmanagement, S. 172 ff.

710

Witzel

Implementierung von Standardsoftware

Rz. 256 G

den Erfolg des gesamten Projekts in Frage stellen. Fehlende Qualitätssicherung macht sich bemerkbar, wie eine Studie von Forrester Research aus dem Jahr 2003 zeigt: Etwa 35 % der IT-Budgets oder ca. 15 Mrd. Euro pro Jahr werden für die Beseitigung von Programmfehlern ausgegeben. Die Produktionsverluste durch Computerausfälle aufgrund fehlerhafter Software werden auf ca. 2 % des Umsatzes oder 70 Mrd. Euro p.a. geschätzt. Der Softwareanbieter ist zu einer normgemäßen Qualitätssicherung seiner 255 Leistungen auch dann verpflichtet, wenn der Vertrag mit dem Anwender keine ausdrückliche Regelung zur Qualitätssicherung enthält. Er schuldet Qualitätssicherung als Teil seiner allgemeinen Vertragspflicht zur Einhaltung der Standards von Wissenschaft und Technik und muss dafür rechtzeitig und durchgehend ausreichende Maßnahmen zur Qualitätssicherung der jeweiligen Leistung durchführen und die erforderlichen Vorkehrungen personeller, technischer und organisatorischer Art treffen. Der Softwareanbieter muss also ein Qualitätsmanagementverfahren etablieren, um seine Verpflichtung zur Qualitätssicherung sicherstellen zu können. Die Qualitätssicherung soll das Vertrauen in die Qualität der Arbeitsergebnisse erhöhen. Das Qualitätsmanagement soll für den Erfolg des Projekts als solches sorgen. ISO 9000:2000 definiert das Qualitätsmanagement als „aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität.“ Qualitätssicherung wird dagegen definiert als der Teil des Qualitätsmanagements, der auf das Erzeugen von Vertrauen dahingehend gerichtet ist, dass Qualitätsanforderungen erfüllt werden. Die Qualitätssicherung sorgt nicht dafür, dass die Arbeitsergebnisse besser werden, sondern soll Vertrauen dahingehend schaffen, dass diese gut sind. Mit einer ordnungsgemäßen Qualitätssicherung soll das Risiko reduziert werden, dass die Arbeitsergebnisse den definierten Anforderungen nicht genügen. b) Qualitätssicherung hinsichtlich der Software Die Produktqualität kann einerseits durch die Beurteilung der Qualität des 256 Endprodukts Software und anderseits durch die Sicherung des Prozesses, mit dem die Software entwickelt wird, gewährleistet werden. Beide Wege fordern ein Qualitätsmanagementsystem. Dabei angelegte Qualitätsnormen können ihren Ursprung haben in – aus dem Projektziel abgeleiteten Kriterien; – allgemeinen Entwicklungsrichtlinien einer Organisation; – internationalen Normen, wie z.B. den allgemeinen Qualitätsnormen DIN – ISO 9000–9004. Wird der Softwareentwicklungsprozess unter dem Gesichtspunkt der Qualitätssicherung betrachtet, wird von der Qualität des Herstellungsprozesses auf die Qualität des Software-Produkts geschlossen.

Witzel

711

G Rz. 257

Sonderregelungen

c) Regelungen zur Qualitätssicherung im Vertrag 257

Einer zwingenden vertraglichen Regelung zur Qualitätssicherung bedarf es nicht, um Klarheit über das vom Softwareanbieter durchzuführende Qualitätsmanagement zu haben. Es kann sich eine explizite vertragliche Regelung allerdings empfehlen:

0.1 Der Auftragnehmer hat ein umfassendes Qualitätssicherungssystem zu etablieren, das darauf abzielt, kontinuierliche Qualitätsverbesserungen im Sinne eines Total Quality Management (TQM) zu realisieren. 0.2 Das Qualitätssicherungssystem umfasst Prozesse, Strukturen und Methoden/Verfahren der Qualitätsplanung, der Qualitätslenkung und der Qualitätsprüfung über den gesamten Lebenszyklus eines Produktes (Strategische Positionierung und Design, Fach- und Datenverarbeitungs-Konzeption, Programmierung, Test, Wartung und Weiterentwicklung des Produktes) oder einer sonstigen Leistung, die verbindlich festzulegen sind und kontinuierlich weiterentwickelt werden. 0.3 Der Auftragnehmer ist verpflichtet, die Qualitätssicherungsmaßnahmen fortlaufend im Hinblick auf ihre Wirksamkeit und Aktualität hin zu überprüfen und dies dem Auftraggeber im Rahmen eines Qualitätssicherungsberichtes regelmäßig nachzuweisen. Der Qualitätssicherungsbericht enthält mindestens folgende Informationen: Umfassende Darstellung des Qualitätssicherungs-Konzeptes, Beschreibung der Qualitätssicherungs-Maßnahmen, Bewertung der Wirksamkeit der Qualitätssicherungs-Maßnahmen, Beschreibung der Maßnahmen zur Fortentwicklung der Qualitätssicherung. 0.4 Dem Auftraggeber sind auf Verlangen und in Abstimmung mit dem Auftragnehmer alle Dokumente der Qualitätssicherung zu übergeben. 0.5 Der Auftragnehmer hat den Auftraggeber in die Konzeption und Fortentwicklung der Qualitätssicherungs-Maßnahmen einzubeziehen. Der Auftraggeber kann Vorschläge zur Optimierung/Verbesserung einreichen. Der Auftragnehmer prüft und kommentiert diese Vorschläge. 0.6 Im Rahmen der Konzepterstellung eines Qualitätssicherungs-Systems könnten u.a. folgende Maßnahmen berücksichtigt werden: – Festlegung einer IT-Strategie – Festlegung von Verfahren zur Risikoanalyse – Einführung einer wirksamen Schwachstellenanalyse und eines Fehlermanagements – Integration der Qualitätssicherungs-Maßnahmen in die Aufbauorganisation – Verbindliche Festlegung von Prozessen zur Qualitätssicherung – Konzept zur Einbindung von Mitarbeitern und Anwendern in das Qualitätssicherungssystem – Verbindliche Richtlinien zur Dokumentation

712

Witzel

Rz. 260 G

Implementierung von Standardsoftware

– Verbindliche Einführung eines Vorgehensmodells für die Anwendungsentwicklung – Einsatz moderner Werkzeuge (Case-Tools) im Softwarerealisierungsprozess – Verbindliche Einführung von modernen Testverfahren und Dokumentation in einem Testkonzept – Konzept zur Sicherstellung der Ausbildung und Qualifikation von Mitarbeitern – Verbindliche Einführung von Methoden zur Projektplanung, Zeit- und Kostenschätzung – Einführung von Audits zur kontinuierlichen Überprüfung der Wirksamkeit von Qualitätssicherungs-Maßnahmen. 0.7 Sollten im Rahmen von Abnahmetests Mängel in der Qualitätssicherung auftreten, sind diese unverzüglich zu beseitigen. Treten derartige Mängel wiederholt auf, berechtigt dies den Auftraggeber, seinen Mehraufwand für Abnahmetests dem Auftragnehmer in Rechnung zu stellen.

4. Einzusetzendes Personal, Mitarbeiterqualifikation, Anzahl der Mitarbeiter Typischerweise finden sich in vielen Projektverträgen Regelungen zur Qua- 258 lifikation der vom Softwareanbieter einzusetzenden Mitarbeiter und auch zu deren Anzahl, die in etwa wie folgt aussehen: „Der Auftragnehmer wird für die Leistungserbringung und Durchführung dieses Vertrags technisch und fachlich qualifiziertes Personal einsetzen.“

Ohne eine genaue Spezifikation, welche technischen und fachlichen Qualifi- 259 kationen die eingesetzten Mitarbeiter haben sollen, lässt sich aus einer solchen Formulierung wenig, außer unnötiges Konfliktpotential, ableiten. Den Vertragspartnern ist entweder zu empfehlen, ein genaues Anforderungsprofil für die Mitarbeiter festzulegen oder die Formulierung weg zu lassen. In einem komplexen Projekt über längere Dauer wird man sich im Zweifel verständigen müssen, wenn ein Mitarbeiter nicht zur Zufriedenheit des Anwenders arbeitet, selbst dann, wenn er über festgelegte Anforderungen verfügt.

VII. Änderungen des Leistungsumfangs (Change Request) 1. Typische Änderungssituationen a) „Was lange währt, wird endlich anders“ Kein Projekt verläuft exakt so wie geplant. In nahezu allen IT-Projekten sind Änderungen notwendig1. Dazu eine treffende Bemerkung von Streitz2: 1 S. Kap. D Rz. 156 ff. 2 Streitz, IT-Projekte retten, S. 133.

Witzel

713

260

G Rz. 261

Sonderregelungen

„In nahezu jedem IT-Projekt, das länger als eine Woche dauert, kommt es zu nachträglichen Änderungsanforderungen.“

Die Anforderungen des Auftraggebers ändern sich1: – Es kommen (völlig) neue Anforderungen hinzu; – im Laufe des Anpassungs- und Implementierungsprozesses versteht das Projektteam die Anforderungen besser; – manche Benutzergruppen werden im Laufe des Projekts bezüglich der Prioritäten immer wichtiger; – die technischen Anforderungen ändern sich während der Laufzeit des Projekts. Es hilft nichts, wenn die Vertragspartner im Hinblick auf ein knappes Budget vor dem unvermeidlichen Wandel die Augen verschließen. Vertragliche Regelungen wie „Dem Softwareanbieter ist bekannt, dass für das Projekt nur ein Budget von 1000 Personentagen zur Verfügung steht und es demzufolge keine Change Requests geben darf.“ bringen zwar Wunschdenken zum Ausdruck, verhelfen aber nicht zu einem erfolgreichen Einführungsprojekt. Auch mit dem folgenden Versuch, dem Softwareanbieter den Weg zu einer weiteren Vergütung abzuschneiden, werden Konflikte sicher nicht gelöst: „Die Festpreise decken sämtliche Leistungen über alle Projektphasen einschließlich Programmierung, Parametrierung, Anpassungen, Datenübernahme, Dokumentation, Test, Rollout, Cut-over, Post-Go-Live sowie sämtliche Aufwendungen, die sonst im Rahmen des Projekts notwendig sind, ab. Von den Festpreisen umfasst sind auch die Vorbereitung und die Umsetzung aller Änderungen, die im Rahmen der Konkretisierung oder Ausprägung von Anforderungen erfolgen, sowie alle in der Anlage „Add-ons“ aufgeführten Punkte. Ebenso abgedeckt von den Festpreisen sind die Leistungen, die der Auftragnehmer deswegen zu erbringen hat, weil sich im Laufe des Projekts herausgestellt hat, dass es aus fachlicher Sicht geboten ist, einen anderen als den ursprünglich abgestimmten Weg zur Realisierung der Projektziele zu nutzen. Auch sämtliche Änderungen in Leistungsbeschreibungen und Konzepten sowie deren Umsetzung sind unter den Festpreisen vom Auftragnehmer zu leisten, soweit die Vertragspartner nicht ausdrücklich etwas anderes vereinbaren. Enthalten sind weiterhin Leistungen i.S.d. Ziffer … „Vollständigkeit der Leistungserbringung“, d.h. solche Leistungen, die im Rahmen des Projekts erbracht werden und nach den Kriterien dieser Regelung Leistungsbestandteil sein sollten.“

261

Ein Softwareanbieter, der so geknebelt ist, dass er Geld für das Projekt mitbringen muss, wird ständig nur Wege suchen, eine Anpassung der Vergütung zu rechtfertigen. Es hilft den Vertragspartnern nur, wenn sie sich dem Unvermeidlichen mit einem strukturierten und stringenten Change Management stellen. Änderungswünsche müssen kritisch geprüft und be-

1 Karger, Desorganisierte Leistungsänderungen in IT-Verträgen, ITRB 2009, 18.

714

Witzel

Implementierung von Standardsoftware

Rz. 266 G

wertet werden. Die Aufnahme, Bewertung, Priorisierung, Einplanung und Umsetzung von Change Requests erfordert einen klar definierten Prozess1. Je länger ein Projekt dauert, desto größer ist die Chance, dass Änderungen 262 gegenüber der Leistungsbeschreibung, einschließlich bereits verabschiedeter Feinkonzepte, erforderlich werden. Die Nutzer auf Seiten des Anwenders können bei fortgeschrittener Entwicklungsarbeit erkennen, dass sich technisch viel mehr oder viel komfortablere Funktionen durch die neu einzuführende Software realisieren zu lassen. Darin liegt ein erhebliches Risiko für das Projekt: Je mehr die Nutzer von 263 dem einzuführenden Produkt sehen, desto deutlicher wird ihnen, wie sie es einsetzen können und desto mehr steigen auch ihre Ansprüche und Wünsche an das entstehende Produkt. Gibt es keine vertragliche Regelung, die die Änderungen und Wünsche kanalisiert und/oder keine Projektleitung, die für die Umsetzung der vertraglichen Regelungen sorgt, drohen die Kosten für die Änderungen das Budget zu sprengen. Darüber hinaus wird die Software nie abnahmefähig „vertragsgemäß“ angepasst, da ständig neue Anforderungen hinzukommen. Wichtig ist vor allem, dass Änderungen nicht stillschweigend oder auf Basis mündlicher Vereinbarungen realisiert werden, sondern dass sie einem geregelten Verfahren unterliegen. Änderungen können notwendig werden durch Einflüsse von außen, bei- 264 spielsweise kann sich das politische Umfeld ändern. Die Unternehmensstrategie oder auch die wirtschaftliche Lage des Unternehmens kann anders sein als zu Beginn des Projekts. Eventuell haben sich Gesetze und Vorschriften geändert, die Einfluss auf das Projekt haben, etwa in den Bereichen Steuerrecht, Datenschutz, Sicherheit, Umweltschutz, Gehaltsabrechnungen. b) Kategorisierung von Änderungen Gegenüber sog. unvermeidlichen Änderungen sind die Änderungen abzu- 265 grenzen, die als Änderungsverlangen vom Anwender ganz bewusst nachträglich gestellt werden, weil sie ursprünglich nicht berücksichtigt werden konnten. Von diesen wiederum sind die Änderungen abzuschichten, die erforderlich sind, weil einerseits der Anwender diese Vorgabe nicht rechtzeitig eingebracht hat, andererseits der Auftragnehmer deren Fehlen nicht erkennen konnte. Daraus ergeben sich praktisch drei typische Änderungs-Situationen:

266

– Die unvermeidbaren, angeblich einzuplanenden, immer wieder vorkommenden Änderungen; – die nachträglichen, auf bestimmten Entscheidungen des Anwenders beruhenden Änderungsverlangen; 1 Verspohl, Zehn Probleme – und wie sie zu meistern sind, Computerwoche 38/11.

Witzel

715

G Rz. 267

Sonderregelungen

– die vom Anwender „vergessenen“ und vom Softwareanbieter nicht als solche erkennbaren Nachträge (Korrekturen). c) Rechtsprechung bei fehlendem Änderungsverfahren 267

Ein formelles Änderungsverfahren fehlt häufig. In diesen Fällen wird sich dann der Softwareanbieter nicht oder nur schwer den üblichen Änderungen widersetzen können. Dies ergibt sich aus einer Reihe von Urteilen, die allerdings die Frage aufwerfen, was eigentlich an Änderungsverfahren bzw. Änderungsverlangen noch „normal“ ist: – BGH v. 24.6.19861. – KG v. 1.6.19902: „Mit gewissen Änderungen und Ergänzungen der Programme im Laufe der Programmierarbeiten und dadurch bedingten Verzögerungen hat der Auftragnehmer zu rechnen und sie von vornherein zu berücksichtigen, wenn eine Betriebsanalyse nicht erstellt und ein Pflichtenheft nicht erarbeitet worden war.“ (LS 3) – BGH v. 7.3.19903: Geräteverwaltung – Herausnahme einer Spezialsoftware aus einem Gesamtprojekt – BGH v. 15.4.19904: Holzhandlung (nicht erfüllte Zusatzwünsche, „Selbstverständlichkeiten“ trotz neuer Vertragsgestaltung) – BGH v. 23.6.19925: Wirksame AGB-Klauseln, wonach sich der Auftraggeber bei Änderungs- oder Ergänzungsarbeiten, die auf seinen Wunsch hin an den Programmen vorgenommen werden, nicht mehr auf früher vereinbarte Fertigstellungsfristen berufen kann. – BGH v. 15.4.19996: Hat der Auftragnehmer im Nachtragsangebot für zusätzliche Leistungen selbst bereits Abzüge bei der Vergütung wegen Wegfalls anderer Leistungen gemacht, trägt er die Beweislast für die spätere Behauptung, der Abzug sei unberechtigt. – BGH v. 20.2.20017: Fälligkeit der Dokumentation mit Abschluss der Arbeiten am Programm. d) Auswirkungen von Änderungen auf Termine aa) Berücksichtigung von Änderungen bereits bei der Terminplanung

268

Wenn im Vertrag verbindliche Termine bzw. Fristen vorgesehen sind, lässt sich oft schwer feststellen, was im Fall einer erheblichen Änderung gelten soll: Hätte der Auftragnehmer eine solche Änderung einplanen müssen, 1 2 3 4 5 6 7

BGH v. 24.6.1986 – X ZR 16/85 – S-Projekt I, CR 1986, 799. KG v. 1.6.1990 – 14 U 4238/86, CR 1990, 768. BGH v. 7.3.1990 – VIII ZR 56/89, CR 1990, 707. BGH v. 15.5.1990 – X ZR 128/88, CR 1991, 86. BGH v. 23.6.1992 – X ZR 92/90 – S-Projekt II, CR 1993, 424. BGH v. 15.4.1999 – VII ZR 211/98, ZIP 1999, 1051. BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367 = NJW 2001, 1718.

716

Witzel

Implementierung von Standardsoftware

Rz. 272 G

hätte er sie ebenso auch bei der Terminplanung berücksichtigen müssen. Geht es nur darum, dass immer Änderungen vorkommen, wäre die Folge, dass immer auch Termine geschoben werden müssten. Soweit die Verschiebungen als solche vorher hätten eingeplant werden können, weil sie vorhersehbar oder üblich waren, kommen Nachfristen gegenüber dem Auftragnehmer in Betracht. Soweit sie nicht vorhersehbar waren, entfallen Termine mangels anderweitiger Regelungen1.

269

bb) Anpassung der Terminplanung während des Projekts Wenn solche Verschiebungen auf Grund vereinbarter bzw. vom Auftrag- 270 geber gewünschter Erweiterungen erkennbar werden, ist es eine wichtige Aufgabe der Projektbegleitung (Controlling), den Terminplan/-rahmen angemessen anzupassen. Auch kann es sinnvoll sein, sich sogleich, noch während des Projektlaufs, über die Ursachen und finanziellen Aspekte der Verschiebung (auch im Hinblick auf Pönalen, Prämien, Fälligkeit) zu verständigen, so dass hierüber späterer Streit vermieden werden kann. Bei einem solchen Streit stehen ansonsten evtl. Zahlungsverlangen des Auftragnehmers verbunden mit Leistungsverweigerung den angeblichen Erfüllungsansprüchen des Auftraggebers gegenüber. Diese Blockade wäre zu vermeiden. e) Auswirkungen von Zusatzwünschen und Änderungen auf die Vergütung aa) Konsequenzen des Vertragstyps, Festpreis- und Zeitaufwandsprojekte Eine klare Zuordnung, dass ein Festpreis-Projekt automatisch ein Werkver- 271 trag, ein Zeitaufwands-Projekt automatisch ein Dienstvertrag wäre, lässt sich nicht vornehmen. Man kann allerdings mit gewisser Vorsicht bei einem Zeitaufwandsprojekt als einem von mehreren notwendigen Indizien auf Dienstvertrag schließen. Jedoch ist dieser Schluss nicht zwingend. Vor allem die BGH-Entscheidung vom 25.3.1993 hat dies klar gemacht. Im 272 zugrundeliegenden Fall war in Vorgesprächen ein Kostenaufwand mit Größenordnung angegeben worden (100 000 DM bis 120 000 DM). Es handelte sich aber wohl nicht um einen verbindlichen Kostenvoranschlag. Der BGH hat den Vertrag, obwohl er nach Zeitaufwand ausgeführt wurde, als Werkvertrag qualifiziert. Dabei ist wichtig, dass im konkreten Fall sogar eine Anpassung erfolgen sollte. Es lässt sich auch nicht so differenzieren, dass die Softwareerstellung als solche ein Werkvertrag, die Softwareanpassung ein Dienstvertrag ist. Vielmehr ist entscheidend, ob ein Erfolg erreicht werden soll bzw. das Erfolgsrisiko beim Auftragnehmer liegt. Dabei ist zu beachten, dass auch bei Werkvertrag Dienstleistungen den Gegenstand bilden kön1 Dazu auch BGH v. 24.11.1998 – X ZR 21/96, CI 1999, 48: Vereinbarung von Zusatzleistungen, Erweiterungen, lassen ursprünglich vorgesehenen Termin entfallen.

Witzel

717

G Rz. 273

Sonderregelungen

nen. Es muss jedoch ein Erfolg herbeizuführen sein (§ 631 Abs. 2 BGB). Andererseits kann man einen werkvertraglichen Auftrag mit Vergütung nach Zeitaufwand kombinieren1. 273

Tendenziell würde man die Planungsphase und die Beratung währenddessen als Dienstvertrag einzuordnen haben. Die Erstellung eines Pflichtenhefts wäre hingegen genügend erfolgsorientiert und mithin Werkvertrag. Schwierigkeiten kann die Abgrenzung von vorvertraglicher Angebotserarbeitung bzw. Aufklärung und Beratung bereiten2. bb) Vergütung von Mehraufwand

274

Nicht jede Änderung muss Mehraufwand mit sich bringen. Denkbar wären auch Minderungen des Aufwands. Aber es stellt wohl jede Änderung die Frage nach den Folgen hinsichtlich der Termine und der Synchronisation der verschiedenen Tätigkeiten, also der Projektleitung, aber auch der rechtzeitigen Vertragserfüllung.

275

Grundsätzlich gilt, dass zusätzliche Leistungen auch zusätzliche Vergütung auslösen. Dies wird häufig übersehen, obwohl es jeweils gesondert für Dienst- und Werkvertrag im Gesetz geregelt ist (§ 612 BGB für Dienst-, § 632 BGB für Werkvertrag)3. Eventuell kommt es auch darauf an, ob es sich um eine Zusatzleistung innerhalb des Vertrags oder um einen abgrenzbaren selbständigen Auftrag handelt4.

276

Auch bei Pauschalpreis-Werkverträgen können nicht vorgesehene zusätzliche Werkleistungen ohne Abschluss eines sie betreffenden zusätzlichen Werkvertrags vergütungspflichtig sein. Voraussetzung ist, dass es sich um erhebliche, zunächst nicht vorgesehene Leistungen auf Veranlassung des Bestellers handelt, wobei es nicht darauf ankommt, ob die Parteien über die neue Preisgestaltung eine Einigung erzielt haben5. cc) Nachweis des Mehraufwands

277

Das große Problem bei Festpreisverträgen oder bei Überschreitung vereinbarter Budgets oder Kostenschätzungen ist, ob der Auftragnehmer im Nachhinein nachweisen kann, dass ihm eine verbindliche Änderung oder ein verbindlicher Zusatzauftrag erteilt worden ist und dass dieser Mehraufwand erforderte. Bei notleidenden Projekten ist regelmäßig kaum nachvollziehbar, ob der Auftraggeber die Zusatzleistung tatsächlich beauftragt hat, ob es 1 BGH v. 25.3.1993 – X ZR 17/92– Bauherrenmodell, CR 1993, 759. 2 Im Abgleich mit BGH v. 6.6.1984 – VIII ZR 83/83, CR 1986, 79 (Organisationspapier als vorvertragliche Beratung), Ausnahme: OLG Nürnberg v. 18.2.1993 – 12 U 1663/92, CR 1993, 553 m. Anm. Bartsch, CR 1993, 557. 3 Wichtig für über Angebot hinausgehende Vorarbeiten, s. OLG Nürnberg v. 18.2.1993 – 12 U 1663/92, CR 1993, 553 m. Anm. Bartsch, CR 1993, 557. 4 Zur Abgrenzung BGH v. 13.12.2001 – VII ZR 28/00, MDR 2002, 634 = NJW 2002, 1492. 5 BGH, DB 2002, 1710.

718

Witzel

Implementierung von Standardsoftware

Rz. 280 G

sich tatsächlich um Zusatzaufwand handelt oder nur um eine Konkretisierung des bisherigen Leistungsumfangs1. Auch vergessen viele Auftragnehmer, sofort einen Vorbehalt anzubringen, dass sie den Mehraufwand geltend machen werden. Hinzu kommt, dass, wie bereits erwähnt, Sachverständige der Auffassung 278 sind, der Auftragnehmer hätte das Pflichtenheft zu erstellen. Fehlt ein solches, sind sie der Auffassung, dass alle Veränderungen, die stattfinden, mangels Nachweisbarkeit der Abweichung vom Pflichtenheft sozusagen zu Lasten des Auftragnehmers gehen2. Diese Auffassung ist durch die Entscheidungen des BGH zum Pflichtenheft3 überholt. In der Praxis bedeutet dies, dass der Auftragnehmer darauf achten muss, dass der Auftraggeber keine Änderungen wünscht, die entweder vom Pflichtenheft oder einem gewöhnlichen Ausführungsstandard abweichen. Dieser Fall ist – wie oben ausgeführt – sehr unwahrscheinlich, da es im Grunde kein Projekt ohne Änderungen gibt. Fordert der Auftraggeber also zwangsläufig Änderungen, kann sich der Auftragnehmer mit dem Vorbehalt darauf einlassen, dass er den Mehraufwand später geltend macht. Möglicherweise ist dies einer der großen, wichtigen Ansatzpunkte für eine 279 permanente kaufmännische, letztlich aber auch juristische Projektbegleitung: Wenn sich der Auftraggeber in jedem Fall, also gleich ob Festpreisoder Zeitaufwandsprojekt, zunächst eine Vorkalkulation geben lässt, auf der entweder der Festpreis oder die Aufwandsschätzung beruht, hat er eine Referenz sowohl in fachlicher als auch in preislicher Hinsicht, um Änderungen als Steigerungen oder Minderungen qualifizieren zu können. Ob überhaupt Änderungen durchzuführen sind, ist dann eine Frage, der sogleich nachgegangen werden soll. Jedenfalls lässt sich der Projektverlauf im Hinblick auf solche Veränderungen nur dann beurteilen, wenn eine solche nach Projektschritten und Modulen spezifizierte Vorkalkulation vorliegt. f) Praktische Handhabung von Änderungsverlangen aa) Zumutbarkeit der Durchführung von Änderungen, Erfordernis eines vertraglichen Änderungsverfahrens Grundsätzlich könnte der Auftragnehmer bei Festpreisaufträgen mit gutem 280 Grund die Erbringung von weiteren Leistungen, also Ergänzungen vor Abnahme, ablehnen, vor allem im Hinblick auf Termine, Risiken der Ausführung, Prüfungsaufwand, oder auf einer Änderung des Vertrags bestehen, 1 An dieser Stelle wird erneut deutlich, dass mit schlecht beschriebenen Anforderungen an der falschen Stelle gespart wird. 2 So etwa ganz typisch: OLG München v. 22.11.1988 – 25 U 5810/86, CR 1989, 283. 3 Vor allem BGH v. 24.9.1991 – X ZR 85/90 – Zugangskontrollsystem, CR 1992, 543, weil bei fehlendem Pflichtenheft ein mittlerer Ausführungsstandard geschuldet ist.

Witzel

719

G Rz. 281

Sonderregelungen

nämlich zu Dienstvertrag als „Zurufprojekt“ nach Aufwand. Er könnte gegenüber Änderungen der Leistungen, wie sie im Pflichtenheft festgelegt sind, geltend machen, dass eine etwaige Änderung zumindest nicht vor Abnahme erfolgen soll, um nicht die Abnahmefähigkeit zu gefährden, weil das Pflichtenheft die Referenz hierfür ist. Man wird jedoch zum einen aus dem Charakter des komplexen Langzeitvertrags ebenso wie auch aus der inzwischen mehrfach von den Gerichten festgestellten naturhaften Zwangsläufigkeit der Änderungen im Projektverlauf schließen müssen, dass sich der Auftragnehmer nur bei Unzumutbarkeit gegen Änderungen wehren kann1. Es empfiehlt sich schon deshalb, in den Vertrag ein Änderungsverfahren einzubauen. 281

Soweit der Auftragnehmer noch während des Projektverlaufs zunächst die Vorgabe, also das Pflichtenheft erstellen soll, wird man sinnvollerweise auch hinsichtlich der Erstellung dieses Pflichtenhefts ein solches Änderungsverfahren einbauen. Ansonsten drohen Probleme, wie sie etwa das OLG Köln zu beurteilen hatte. Dort hatte gemäß Vertrag der Auftragnehmer dem Auftraggeber „ein Pflichtenheft mit Realisierungsplan“ zu übergeben. Der Auftragnehmer sah sich hierzu nicht in der Pflicht, nachdem der Auftraggeber in der ersten Programmbesprechung weit über die ursprüngliche Besprechung (die der Auftragnehmer im Pflichtenheft wiedergeben wollte) hinausgehende Anforderungen geäußert hatte. Nach Ansicht des OLG Köln hätte der Auftragnehmer sich darauf einlassen müssen, das Pflichtenheft völlig umzuschreiben (und damit den gesamten Auftrag)2. bb) Mögliche Phasen des Änderungsverlangens

282

In ausgearbeiteten Verträgen wird man für Änderungen „Regiearbeiten“ vereinbaren, wenn ein Festpreis vereinbart ist, und dabei auch gleich die Vergütung (z.B. pro Stunde/pro Qualifikation) festlegen, die dann gelten soll.

283

Streitz3 empfiehlt folgenden Ablauf: – Formulierung der Änderungsanforderung nach einem vorgegebenen Schema (auch auf einem Formular) mit Beschreibung der gewünschten Änderung, Folgen, erforderlichen Maßnahmen, anfordernder Person, Priorität, Datum; ggf. können auch die notwendigen Unterschriftsfelder für die diejenigen Personen vorgesehen werden, die Change Requests beauftragen und entsprechende Vertragsänderungen abschließen können. – Prüfung der Anforderung: Der Auftragnehmer konzipiert eine Realisierungsmöglichkeit und prüft dabei die Auswirkungen auf das Projekt. Dies können Seiteneffekte mit Auswirkungen auf andere funktionale Be1 S. vor allem BGH v. 24.6.1986 – X ZR 16/85, CR 1986, 799 zu Reservekapazitäten im Hardwaremengengerüst wegen der im Projektverlauf immer üblichen Änderungen. 2 OLG Köln, jur-PC 1993, 2412. 3 Streitz, IT-Projekte retten, S. 134.

720

Witzel

Implementierung von Standardsoftware

–

–

–

–

Rz. 284 G

standteile, erhöhte Hardwareanforderungen und Änderungen von Aufwänden (Kosten), Terminen, Abnahmeverfahren und Dokumentationen sein. Weitergehende Untersuchungen: Bei komplexen Änderungswünschen kann es notwendig werden, die Projektarbeit zu unterbrechen und zunächst eine detaillierte Prüfung des Änderungswunschs vorzunehmen. Entscheidung des Auftragnehmers: Auf Basis der ihm zur Verfügung stehenden Ressourcen und der Gesamtsituation im Projekt entscheidet zunächst der Auftragnehmer, ob er den beantragten Change Request umsetzt oder ob er die Realisierung (zunächst) ablehnt und ggf. auf eine spätere Projektphase verschiebt. Entscheidung des Auftraggebers: Der Auftraggeber bestimmt, ob er ein vom Auftragnehmer vorgelegtes Angebot annimmt und die Durchführung des Change Requests beauftragt. Frist: Für eine stringente Projektorganisation empfiehlt es sich, Fristen zur Bearbeitung von Change Requests zu vereinbaren.

Schematisch lassen sich bei den Änderungsverlangen verschiedene Stufen trennen, die in ausgearbeiteten Verträgen auch berücksichtigt werden sollten: – Förmliches Änderungsverlangen des Auftraggebers oder des Auftragnehmers, falls dieser erkennt, dass das Pflichtenheft so nicht ausführbar ist; – Prüfungsverfahren durch den Auftragnehmer, falls das Änderungsverlangen nicht ganz minimal ist mit gleichzeitigem – Vorbehalt, dass auch die – aufwendigere – Prüfung vergütungspflichtig ist; – Mitteilung bzw. Aufforderung an den Auftraggeber, dass die Arbeiten vorläufig einzustellen sind, weil sich aus dem Änderungsverlangen Auswirkungen auf die derzeit in Arbeit befindlichen Leistungen ergeben (um Doppelarbeit zu vermeiden); – Mitteilung des Auftraggebers, ob das Prüfungsverfahren durchgeführt werden soll (entgeltpflichtig), und – Regelung, was für den Fall der Nichtdurchführung geschehen soll (zurück zum bisherigen Pflichtenheft); – Fristen für Reaktionen jeweils seitens des Auftragnehmers hinsichtlich der Mitteilung zur Prüfung und seitens des Auftraggebers zur Beauftragung; – Durchführung der Prüfung mit anschließendem Angebot; – erneute Frist zur Reaktion seitens des Auftraggebers auf das Angebot; – Beauftragung durch den Auftraggeber oder Ablehnung des Angebots; – Durchführung des Auftrags mit Anpassung der Fristen oder – normale weitere Durchführung des Vertrags.

Witzel

721

284

G Rz. 285

Sonderregelungen

285

Ist die Änderung veranlasst durch ursprüngliche Fehler im Pflichtenheft/in der Leistungsbeschreibung, bleibt wohl kein anderer Weg als auch dann, wenn dieses förmliche Verfahren nicht eingehalten wird, eine Anpassung vorzunehmen.

286

Dies gilt insbesondere dann, wenn der Auftragnehmer auf solche Änderungen drängt. Das Hauptproblem in diesem Zusammenhang stellt die Vergütung i.V.m. der Einhaltung der vereinbarten Termine dar. Eventuell sollte diese Alternative gesondert außerhalb dieses formellen Änderungsverfahrens geregelt werden.

287

Dies hängt auch davon ab, ob der Auftragnehmer bereits nach dem Vertrag das Pflichtenheft zu prüfen hat (und insofern das erst spätere Erkennen einen Mangel seiner Leistung darstellen kann) oder ob er nur verpflichtet ist, dann, wenn er die unzureichende Ausführung des Pflichtenhefts erkennt, hierauf aufmerksam zu machen und ein entsprechendes Verfahren einzuleiten. In diesem Falle wäre es so, dass der Anstoß vom Auftragnehmer ausgeht und dieser den Auftraggeber veranlasst, ein förmliches Änderungsverlangen durchzuführen, das in diesem Fall der Auftragnehmer initiiert, zu dem dann der Auftraggeber den zweiten Schritt, nämlich die entsprechende Vorgabe, wie das Pflichtenheft beschaffen sein soll, nachholt. g) Bewertungsgrundlage für Mehraufwände: Aufwandskalkulation

288

Unter dem Aspekt des Änderungsverfahrens (gleich ob förmlich oder mehr informativ) lohnt es, dass Projekte im Vorhinein kalkuliert werden und dass für einzelne Arbeitsschritte bzw. Bereiche (Module) die Arbeiten, die hierzu erbracht werden sollen, festgelegt und auch zeitlich bewertet werden. Diese Kalkulation muss nicht, könnte aber theoretisch Geschäftsgrundlage werden. Bei Abweichungen lässt sich dann ermitteln, welcher Aufwand entfallen ist, welcher hinzugekommen ist und wie sich dieser Aufwand zum Gesamtvertrag verhält. An der Möglichkeit eines solchen Soll-Ist-Vergleichs fehlt es bei vielen Projekten1. h) Ungeeignete Ausführungsart

289

Es kommt häufiger vor, dass die Parteien im Vertrag eine bestimmte Ausführungsart vereinbart haben. Soweit ersichtlich, gibt es für den EDV-Bereich keine unmittelbar einschlägige Entscheidung. Jedoch hat der BGH in anderem Zusammenhang (Sanierungsarbeiten an Decken, Wänden und 1 S.a. Probleme der Rückrechnung auf erforderlichen Aufwand trotz vorliegender Stundenzettel, OLG München v. 22.11.1988 – 25 U 5810/86, CR 1989, 283. Der für die bestimmte Ausführungsart vereinbarte Werklohn umfasst, sofern die Kalkulation des Werklohns nicht allein auf den Vorstellungen des Auftragnehmers beruht, nur diese Ausführungsart, so dass der Auftraggeber Zusatzarbeiten, die für den geschuldeten Erfolg erforderlich sind, gesondert vergüten muss. BGH v. 16.7.1998 – VII ZR 350/96, MDR 1998, 1475 = NJW 1998, 3707.

722

Witzel

Implementierung von Standardsoftware

Rz. 292 G

Fußböden) ausführlich zur Erfolgshaftung des Auftragnehmers beim Werkvertrag mit Vereinbarung einer bestimmten Ausführungsart Stellung genommen. Danach ändert sich grundsätzlich an der Erfolgshaftung des Auftragnehmers im Rahmen eines Werkvertrags nichts, „wenn die Parteien eine bestimmte Ausführungsart vereinbart haben, mit der die geschuldete Funktionstauglichkeit des Werks nicht erreicht werden kann“, und weiter: „Der für die bestimmte Ausführungsart vereinbarte Werklohn umfasst, sofern die Kalkulation des Werklohns nicht allein auf den Vorstellungen des Auftragnehmers beruht, nur diese Ausführungsart, sodass der Auftraggeber Zusatzarbeiten, die für den geschuldeten Erfolg erforderlich sind, gesondert vergüten muss.“ (LS 3)1. Restriktiv für den Auftragnehmer ist dies, als er oft erst im Nachhinein ver- 290 sucht, den Mehraufwand geltend zu machen, so dass es ihm schwer fällt, diesen nachzuweisen. Vor allem gilt dies dann, wenn die Projektkalkulation nicht sauber bestimmten Leistungsbereichen zugeordnete Komponenten enthielt, sondern pauschal erfolgte. Noch wichtiger aber ist, dass das Risiko auch bei Wahl einer ungeeigneten 291 Ausführungsart durch beide Parteien hinsichtlich des geschuldeten Erfolgs beim Auftragnehmer verbleibt. Hat der Auftragnehmer die vereinbarte (untaugliche) Ausführungsart dennoch ausgeführt und ist das Werk deshalb mangelhaft, können die dem Auftragnehmer zustehenden Zusatzvergütungen im Rahmen der Gewährleistung als „Sowieso-Kosten“ berücksichtigt werden. i) Empfehlungen für die Vertragsgestaltung Checkliste: Verfahren bei Änderungswünschen des Auftraggebers

292

Es empfiehlt sich, in den Vertrag eine klare Regelung hinsichtlich des Verfahrens bei möglichen Änderungen/Änderungswünschen des Auftraggebers aufzunehmen. Besonders zu beachtende Punkte sind: – – – – – – –

Differenzierungen bei der Dringlichkeit/Priorisierung der Änderungen; Entsprechende Differenzierung bei der Reaktion des Auftragnehmers; Einstellen der laufenden Arbeiten je nach Art des Änderungsverlangens; Evtl. schon während der Prüfung; Vergütungspflicht für umfangreichere Prüfung; Wegfall/entsprechende Verschiebung von Fristen/Terminen; Klare Regelung, was bei Nicht-Einigung passieren soll (Fortführung, Beendigung); – Vorbereitung für diese Entscheidung: klares Angebot des Auftragnehmers;

1 BGH v. 16.7.1998 – VII ZR 350/96, MDR 1998, 1475 = NJW 1998, 3707.

Witzel

723

G Rz. 293

Sonderregelungen

– Klare Dokumentation der einzelnen Tools und deren Behandlung, – einschließlich Fortschreibung des „Pflichtenhefts“, des Termin- und Aktivitätenplans; – Einbettung in das Eskalationsverfahren.

VIII. Rechtseinräumung, Nutzungs- und Verwertungsrechte 1. Unterscheidung zwischen Standardkomponenten und individuellen Ergänzungen/Erweiterungen a) Differenzierung zwischen den Liefergegenständen, insbesondere „Standard“ und „Anpassungen“ 293

Hinsichtlich der Rechtseinräumung1 bei angepasster Standardsoftware wird zu unterscheiden sein zwischen – den Nutzungsrechten an den vom Softwareanbieter entwickelten und gelieferten Standardkomponenten; – den Nutzungsrechten an vom Softwareanbieter „nur“ gelieferten Standardsoftwarekomponenten, einschließlich etwaiger Open-Source-Softwarekomponenten; – den Nutzungs- sowie etwaigen Verwertungsrechten an den für den Anwender im Rahmen der Einführung und Implementierung entwickelten individuellen Erweiterungen und Ergänzungen und ggf. – den Parametrisierungen sowie an – sonstigen Arbeitsergebnissen, die im Rahmen des Projekts entstehen, insbesondere dem Pflichtenheft2 und anderen Konzepten sowie Dokumentation und Schulungsunterlagen. b) Standardkomponenten

294

An der Standardsoftware wird der Anwender in der Regel einfache (nichtausschließliche) Nutzungsrechte auf Dauer erhalten. Ein ausschließliches Recht scheidet schon vor dem Hintergrund aus, dass der Softwareanbieter Nutzungsrechte auch anderen Kunden einräumen will. Einer der wirtschaftlichen Vorteile beim Einsatz von Standardsoftware ist schließlich auch der weit verbreitete Einsatz. Der Softwareanbieter wird in der Regel die in seinem Unternehmen üblichen „Lizenzierungsmodelle“ anbieten, d.h. „Concurrent“ oder „Named User“-Modelle und – bei großen Anwendern – ggf. eine Konzernlizenz.

1 Zum Urheberrecht s. Karger, Kap. A Rz. 1 ff.; Brandi-Dohrn, Kap. A Rz. 202 ff. 2 Nach Bartsch, Softwarerechte bei Projekt- und Pflegeverträgen, CR 2012, 141, soll das Pflichtenheft selbst nicht urheberrechtlich schutzfähig sein.

724

Witzel

Implementierung von Standardsoftware

Rz. 299 G

Daneben kann es weitere Beschränkungen bei der Nutzung geben, etwa auf 295 die Nutzung auf konkret festgelegter Hardware oder auf die Nutzung an einem bestimmten Standort oder ausschließlich für die internen Geschäftszwecke des Anwenders. Solche Beschränkungen können urheberrechtliche Bindungswirkung entfalten oder nur schuldrechtlich wirken1. Ob der Anwender an den Standardkomponenten auch Bearbeitungsrechte 296 erhält, wird bei den unterschiedlichen Softwareanbietern variieren, überwiegend wird sich die Rechtseinräumung auf die reine Nutzung beschränken. Den Vertragspartnern ist zu empfehlen, dass sie die Einräumung eines Bearbeitungsrechts ausdrücklich regeln und sich zudem auch darüber Gedanken machen sollten, ob zur Ausübung des Bearbeitungsrechts die Herausgabe des Quellcodes erforderlich ist. Umfassen die Standardsoftwarekomponenten auch Open-Source-Software- 297 komponenten2, müssen die für diese Softwarekomponenten geltenden Lizenzbedingungen in die vertraglichen Regelungen meist einbezogen werden, auch wenn die Auswirkungen fraglich sein werden. Auf die in diesen Lizenzbedingungen typischerweise enthaltenen Haftungs- und „Gewährleistungsausschlüsse“ wird sich der Anwender im Verhältnis zum Softwareanbieter kaum einlassen. Das Argument, dass solche Softwarekomponenten ja im Regelfall kostenfrei überlassen werden, überzeugt im Rahmen eines gesamten Projekts zur Anpassung, Einführung und Implementierung selten, da ein etwaiger Kostenvorteil durch den Einsatz von Open-Source-Komponenten kaum transparent werden dürfte. c) Individuelle Erweiterungen/Ergänzungen („Add-ons“) Interessanter ist, welche Rechte dem Anwender an individuellen Erweite- 298 rungen und Ergänzungen der Standardkomponenten eingeräumt werden können. Folgende Varianten sind denkbar: – Die Nutzungsrechte an individuellen Erweiterungen/Ergänzungen entsprechen der Regel zu den Standardkomponenten. Es gibt also eine einheitliche Regelung zur Rechtseinräumung. – Der Anwender erhält an individuellen Erweiterungen/Ergänzungen ausschließliche Nutzungsrechte, ggf. erweitert um Bearbeitungsrechte und evtl. auch um ein Verbreitungs- (Vertriebs-)recht. Eine einheitliche Regelung, mit der nur einfache (nicht-ausschließliche) Rechte eingeräumt werden, ist vor allem dann erforderlich, wenn der Softwareanbieter die individuellen Erweiterungen/Ergänzungen auch für andere

1 Grützmacher, Lizenzgestaltung für neue Nutzungsformen im Lichte von § 69d UrhG, CR 2011, 485; Osterloh, Inhaltliche Beschränkungen des Nutzungsrechts an Software, GRUR 2009, 311. 2 S. dazu Rz. 44 ff.

Witzel

725

299

G Rz. 300

Sonderregelungen

Kunden nutzen will. Es wird insoweit vertreten1, dass sich im Falle einer solchen einheitlichen Regelung die weniger umfassende Rechtseinräumung auch in einem niedrigeren Preis für die Erweiterungen/Ergänzungen niederschlagen muss. Dem ist nicht zwingend zu folgen, denn zumindest ein Teil der Erweiterungen/Ergänzungen wird für den Anwender ohnehin nicht selbständig einsetzbar, sondern nur in Zusammenhang mit den gelieferten Standardkomponenten nutzbar sein. Die ausschließlichen Rechte können also nur eine theoretische Bedeutung haben. Für den Anwender ergeben sich (wirtschaftliche) Vorteile, wenn die von ihm in Auftrag gegebenen Erweiterungen/Ergänzungen in den Standardkatalog des Softwareanbieters mit aufgenommen werden. Dadurch kann sichergestellt werden, dass beim nächsten Releasewechsel der Standardkomponenten die individuell entwickelten Erweiterungen/Ergänzungen – ohne exorbitante Mehrkosten – angepasst werden. d) Parameter und Parametrisierung 300

Die Anpassung von Standardsoftware erfolgt im Idealfall nicht über umfassende Programmierung von Add-ons oder generell Zusatzentwicklung, sondern über die Einstellung der in der Software enthaltenen Parameter. Die Parameter selbst sind Bestandteil des Funktionsumfangs der Standardsoftware und werden damit von der Rechtseinräumung für die Standardsoftware mit umfasst sein. Eine produktiv gesetzte Standardsoftware ist allerdings komplett nach den Anforderungen des Anwenders parametrisiert. Da diese Parametrisierung im Regelfall die individuellen Geschäftsprozesse des Anwenders erfasst, steckt in dieser Arbeitsleistung ggf. sogar eine Bearbeitung der Standardsoftware im urheberrechtlichen Sinne. In jedem Fall fließen in diese Parametrisierung auch die Geschäfts- und Betriebsgeheimnisse des Anwenders ein. Die wenigsten Geschäftsprozesse werden branchenübergreifend so standardisiert sein, dass sie bei allen Unternehmen einer Branche identisch sind. Es kann daher notwendig sein, die konkrete Parametrisierung bei der Rechtseinräumung zu berücksichtigen; eventuell ist eine Vereinbarung notwendig, dass der Softwareanbieter Rechte an der individuellen Parametrisierung insgesamt ausschließlich dem Anwender einräumt. e) Sonstige Arbeitsergebnisse

301

Im Rahmen eines Projekts zur Anpassung, Einführung und Implementierung von Standardsoftware entstehen über die Anpassungen an der Software und deren Parametrisierung hinaus weitere (zumindest theoretisch) schutzfähige Arbeitsergebnisse, vor allem das Pflichtenheft (oder dessen Bestandteile), Schulungs- und Migrationskonzepte, Projektdokumentation (Statusberichte) und Dokumentation. Bei ausreichender Schöpfungshöhe wären solche Dokumente als literarische Werke dem Urheberrechtsschutz zugäng1 S. Redeker, Handbuch der IT-Verträge, Kap. 1.6, Rz. 161.

726

Witzel

Implementierung von Standardsoftware

Rz. 302 G

lich1. Dass in solchen Unterlagen viel Know-how steckt, wenn sie sorgfältig erstellt sind, dürfte außer Frage stehen. In den Ausführungen dieses Kapitels wurde deutlich, dass der Qualität der Anforderungsbeschreibung erhebliche Bedeutung zukommt. Es dürfte nicht auszuschließen sein, dass darin mehr als nicht-schutzfähige Ideen stecken, nämlich auch eine geistige, schöpferische Leistung. Die Vertragspartner sollten daher auch sonstige Arbeitsergebnisse – insbesondere das Pflichtenheft – bei der Vertragsgestaltung, etwa mit folgender Formulierung berücksichtigen:

An sämtlichen Konzepten (insbesondere Pflichtenheft, Workshop-Protokolle, Schulungsunterlagen, Migrationskonzept) räumt der Auftragnehmer dem Auftraggeber im Moment von deren Entstehung die nicht-ausschließlichen zeitlich, inhaltlich und räumlich unbeschränkten Nutzungs- und Verwertungsrechte ein. Diese Rechtseinräumung erstreckt sich auf sämtliche bekannten Nutzungsarten. Der Auftraggeber ist insbesondere berechtigt, Konzepte zu vervielfältigen, zu bearbeiten, weiterzuentwickeln, zu übersetzen und an Dritte weiterzugeben. Der Auftragnehmer ist berechtigt, die Inhalte der für den Auftraggeber erstellten Konzepte als Grundlage für die Erweiterung seiner Standardsoftwareprodukte zu verwenden. Der Auftragnehmer ist nicht berechtigt, die für den Auftraggeber erstellten individuellen Konzepte an Dritte weiterzugeben oder bei Dritten zu verwerten.

f) Spezifizierungslast bei Gestaltung der Rechtseinräumung Generell ist den Vertragspartnern zu empfehlen, die Regelungen zur Rechts- 302 einräumung sorgfältig zu gestalten, denn bei fehlenden oder pauschalen Regelungen ist auf die Zweckübertragungsregel des § 31 Abs. 5 UrhG abzustellen. § 31 Abs. 5 UrhG ist mehr als eine Auslegungsregel. Er bewirkt eine Spezifizierungslast des Erwerbers2. Sorgt er nicht dafür, dass die Nutzungsarten ausdrücklich als solche bezeichnet werden, so wird die Auslegung zwingend auf den Vertragszweck fixiert, was einen Rechtsnachteil für den Anwender bedeuten kann. Dieser Nachteil realisiert sich, wenn der Vertragszweck hinter dem Wortlaut einer Klausel zurückbleibt3. Die Beweislast, dass ein Recht vom Vertragszweck gedeckt wird, trägt, wer sich auf die Einräumung eines Nutzungsrechts beruft4. Er hat bei Fehlen einer einzel1 S. auch Kilian, Entwicklungsgeschichte und Perspektiven des Rechtsschutzes von Computersoftware in Europa, GRURInt 2011, 895. 2 Löwenheim, in: Schricker, 4. Aufl. 2010, § 31 UrhG Rz. 69. 3 Löwenheim, in: Schricker, 4. Aufl. 2010, § 31 UrhG Rz. 69. 4 LG Köln v. 14.7.2010 – 28 O 128/08, ZUM-RD 2010, 698: „Wer behauptet Nutzungsrechte erworben zu haben, muss den Erwerb der Rechte konkret dartun und beweisen.“

Witzel

727

G Rz. 303

Sonderregelungen

nen Bezeichnung zu beweisen, dass der Vertragszweck entsprechend weit reicht. 2. Formulierungsvorschläge 303

Formulierungsvorschlag 1 0.1 Rechtseinräumung an Arbeitsergebnissen im Rahmen der Implementierung Der Auftragnehmer räumt an sämtlichen im Rahmen der Implementierungsleistungen (siehe Ziffer …) entstehenden Arbeitsergebnissen, insbesondere an entstehenden Softwareprogrammen (einschließlich Quellcode), Dokumentationen und Unterlagen dem Auftraggeber die ausschließlichen, räumlich, zeitlich und zahlenmäßig unbeschränkten Nutzungs- und Verwertungsrechte zum beliebigen Einsatz innerhalb des „Auftraggeber-Konzerns“ ein. Die Weitergabe im Sinne von gewerblicher (kommerzieller) Verwertung von Arbeitsergebnissen an Dritte außerhalb des „Auftraggeber-Konzerns“ ohne Zustimmung seitens des Auftragnehmers ist unzulässig. 0.2 Rechtseinräumung an Arbeitsergebnissen im Rahmen der Add-on Entwicklung An Add-ons (s. Ziffer …), einschließlich Quellcode, Dokumentationen und Unterlagen, räumt der Auftragnehmer dem Auftraggeber die ausschließlichen, räumlich, zeitlich und zahlenmäßig unbeschränkten Nutzungs- und Verwertungsrechte zum beliebigen Einsatz innerhalb des „AuftraggeberKonzerns“ ein. Die Weitergabe von Add-ons an Dritte außerhalb des „Auftraggeber-Konzerns“ im Sinne von gewerblicher (kommerzieller) Verwertung ist nur mit Zustimmung seitens des Auftragnehmers zulässig. Sofern ein Add-on in den Produktstandard des Auftragnehmers übernommen werden soll, werden die Vertragspartner entsprechende Absprachen treffen.

304

Formulierungsvorschlag 2 0. Nutzungsrechte 0.1 Planung, Konzepte An den Planungsleistungen und sämtlichen Konzepten (s. Ziffer …) sowie sämtlichen sonstigen Arbeitsergebnissen, die nicht durch die folgenden Ziffern erfasst sind, stehen sämtliche vermögensrechtlichen Befugnisse, insbesondere die Nutzungs- und Verwertungsrechte, ausschließlich dem Auftraggeber zu.

728

Witzel

Implementierung von Standardsoftware

Rz. 305 G

0.2 Standardsoftware An der Standard-Software stehen dem Auftraggeber sowie seinem eventuellen Rechtsnachfolger sowie abgespalteten oder ausgegründeten Betriebsteilen mit rechtlicher Selbständigkeit die einfachen Nutzungs- und Bearbeitungsrechte einschließlich des Rechts zum Outsourcing mit Servicebetrieb durch Dritte („Rückmiete“) zur Nutzung durch den Auftraggeber und durch seinen eventuellen Rechtsnachfolger sowie abgespalteten oder ausgegründeten Betriebsteilen mit rechtlicher Selbständigkeit auf Dauer zu. Dieses Recht gilt für beliebig viele Rechner und Nutzer. 0.3 Anpassungen, Ensemble An den Leistungen des Auftragnehmers hinsichtlich der Einstellung der Parameter, Anpassungen und der Erweiterung der Standardsoftware sowie an eventuellen Zusätzen stehen sämtliche vermögensrechtlichen Befugnisse, insbesondere die Nutzungs- und Verwertungsrechte, ausschließlich dem Auftraggeber und zwar auf Dauer zu. Diese ausschließlichen Rechte stehen dem Auftraggeber auch hinsichtlich des Gesamtergebnisses, dem Ensemble bestehend aus Standardsoftware, Anpassungen, Erweiterungen und Zusätze, zu. Diese Rechte sind nicht insgesamt übertragbar, jedoch durch ein Outsourcing-Unternehmen, das die Software dem Auftraggeber sowie seinem eventuellen Rechtsnachfolger sowie abgespalteten oder ausgegründeten Betriebsteilen mit rechtlicher Selbständigkeit zur Verfügung stellt, ausübbar. 0.4 Abgeltung Vorstehende Rechtseinräumungen einschließlich der Überlassung des Quellcodes und der Dokumentationen sind mit der Vergütung gem. Ziffer … abgegolten.

Formulierungsvorschlag 3

305

0. Der Auftragnehmer räumt an im Rahmen der Anpassung, Einführung und Implementierung entstehenden Arbeitsergebnissen, insbesondere an entstehenden Softwareprogrammen, Dokumentationen und Schulungsunterlagen hiermit dem Auftraggeber die nicht-ausschließlichen, räumlich, zeitlich und zahlenmäßig unbeschränkten Nutzungs- und Verwertungsrechte zum beliebigen Einsatz innerhalb des „Auftraggeber-Konzerns“ ein. Die Weitergabe von Arbeitsergebnissen an Dritte außerhalb des „Auftraggeber-Konzerns“ ohne Zustimmung seitens des Auftragnehmers ist unzulässig.

Witzel

729

G Rz. 306

Sonderregelungen

IX. Vergütungsmodelle 1. Vergütung und Vertragstypen a) Festpreis contra Aufwandsabrechnung 306

Die vor allem bei Softwareanbietern immer noch verbreitete Meinung, nur ein „Festpreis“-Projekt sei dem Werkvertragsrecht zugeordnet, während bei einer vereinbarten Vergütung nach Aufwand1 „automatisch“ Dienstvertragsrecht zur Anwendung kommt, ist nicht haltbar. Dies hat der BGH eindeutig klargestellt: „Das Berufungsgericht sieht in dem zwischen den Parteien geschlossenen Vertrag – trotz der besonderen Form der Abrechnung nach Aufwand – einen Werkvertrag im Sinne von § 631 BGB. Dies entspricht der Rechtsprechung des Senats, nach der die Erstellung von Individualsoftware diesen Vorschriften unterliegt. Die gewählte Form der Abrechnung mag für einen Werkvertrag untypisch sein. Seine Annahme schließt sie nicht aus.“2

307

Allein die Form der Vergütungsabrede lässt also keinen Rückschluss auf den Vertragstyp zu. Die gesetzlichen Regelungen schreiben hinsichtlich der Vergütung bzw. der Form der Vergütung nichts vor. b) „Übliche“ Vergütung bei fehlender Vergütungsabrede

308

Nach § 612 Abs. 1 BGB gilt eine Vergütung als stillschweigend vereinbart, wenn für eine vereinbarte oder eine hingenommene Dienstleistung eine Vergütungsabrede fehlt, die Dienstleistung aber den Umständen nach nur gegen Vergütung zu erwarten ist. Mit der Fiktion wird sichergestellt, dass der Abschluss eines Dienstvertrags nicht am Fehlen einer Vergütungsabrede scheitert, wenn die Dienstleistung nach objektiven Kriterien als entgeltlich anzusehen ist. Nach § 612 Abs. 2 BGB gilt die übliche Vergütung als vereinbart, wenn es an einer Abrede der Vertragspartner zur Höhe der Vergütung fehlt. Üblich ist eine Vergütung, die am gleichen Ort in ähnlichen Gewerben oder Berufen für eine vergleichbare Tätigkeit gezahlt wird3.

309

§ 632 BGB enthält ähnliche Fiktionen für den Werkvertrag: Eine Vergütung gilt als stillschweigend vereinbart, wenn die Herstellung des Werkes nur gegen Vergütung zu erwarten ist (§ 632 Abs. 1 BGB). In Ermangelung einer Vereinbarung über die Höhe der Vergütung ist die übliche Vergütung als vereinbart anzusehen (§ 632 Abs. 2 BGB).

1 Zu Aufwandsschätzungen in IT-Projekten s. Sneed, in: Tiemeyer, Handbuch ITProjektmanagement, 2010, S. 267. 2 BGH v. 25.3.1993 – X ZR 17/92, CR 1993, 759 ff. 3 Erman/Edenfeld, § 612 BGB Rz. 21 m.w.N.

730

Witzel

Implementierung von Standardsoftware

Rz. 311 G

c) Widerstreitende Interessen von Anwender und Softwareanbieter Eines der großen Probleme im Rahmen jedes IT-Projekts, aber im Besonde- 310 ren bei Anpassung, Einführung und Implementierung ist, dass der Leistungsumfang bei Beginn des Projekts nicht exakt feststeht, im Grunde auch nicht feststehen kann. In der Konsequenz kann natürlich auch weder die exakte Vergütung noch eine verlässliche Schätzung feststehen. Je genauer eine Schätzung sein soll, desto genauer muss der Lösungsweg bekannt sein, desto mehr Zeit muss also auf die Aufwandsschätzung selbst verwendet werden, um Anforderungen präzise zu verstehen und sorgfältig zu durchdenken1. Aus Sicht des Softwareanbieters wird demzufolge ein besonderes Interesse daran bestehen, die Vergütung nach oben offen zu lassen und keinesfalls einen Festpreis zu vereinbaren. Der Anwender wird aus Gründen der Planungssicherheit und im Hinblick auf die notwendige Budgetierung auf die Vereinbarung eines Festpreises drängen. Und hierin liegt einer der Kardinalfehler im Projekt: Der Softwareanbieter lässt sich – im Hinblick auf den hart umkämpften Markt – auf den gewünschten Festpreis ein, ohne dass der eigentliche Leistungsumfang auch nur annähernd abgegrenzt wäre. Im Verlauf des Projekts beginnt dann eine lange Leidenszeit für beide Vertragspartner. Mangels tauglicher Anforderungsbeschreibung ist es nur schwer feststellbar, was zum bereits ursprünglich geschuldeten Leistungsumfang gehört und was nicht – was also unter die Kategorie Change Request fällt. Des Weiteren streiten die Vertragspartner darüber, ob es überhaupt vergütungspflichtige Mehraufwände gibt oder nicht. 2. Festpreisabreden Eine Festpreisabrede setzt im Grunde voraus, dass der Leistungsumfang be- 311 reits im Wesentlichen feststeht, was gerade am Anfang eines Projekts eher zweifelhaft sein wird. Entscheiden sich die Vertragspartner für die Vereinbarung eines Festpreises, sollte bei der Vertragsgestaltung umso mehr Augenmerk auf das Änderungsverfahren gelegt werden und auch darauf, wie mit etwaigen Kalkulationsirrtümern umzugehen ist. Nach der Rechtsprechung des BGH sind Kalkulationsirrtümer unbeachtlich und zwar selbst dann, wenn der Erklärungsempfänger den Irrtum des Erklärenden hätte erkennen können oder sogar positiv erkannt hat2. Dies stößt bei Nicht-Juristen häufig auf Unverständnis, vor allem dann, wenn die Vertragspartner die Berechnungsgrundlagen diskutiert und besprochen haben. Nicht jede Information, die ein Vertragspartner in die Vertragsverhandlungen einbringt, ist schon Inhalt seiner Willenserklärung. Lediglich wenn die Berechnungsgrundlagen Gegenstand entscheidender Verhandlungen waren, sollen die Grundsätze über die Störung der Geschäftsgrundlage (§ 313 BGB) anwendbar sein.

1 Geirhos, IT-Projektmanagement, Galileo Computing, 2011, S. 105. 2 Erman/Schwenker, § 632 BGB Rz. 11 m.w.N.

Witzel

731

G Rz. 312 312

Sonderregelungen

Daher empfiehlt es sich zur Sicherheit beider Vertragspartner, Kalkulationen auch ausdrücklich zum Gegenstand des Vertrags zu machen, damit ein etwaiger Irrtum nicht den Ersteller der Kalkulation – meist den Softwareanbieter – zum alleinig Benachteiligten macht.

0.11 Alle nach diesem Vertrag vom Auftragnehmer zu erbringenden Lieferungen und Leistungen für die funktionsgerechte und betriebsbereite Errichtung des Logistik- und Lagerzentrums mit den spezifizierten Einrichtungen einschließlich der Vorbereitungs- und Nebenkosten werden vom Auftragnehmer zum Gesamtfestpreis von … Euro zzgl. Mehrwertsteuer erbracht. Durch diesen Preis werden auch solche Leistungen und Lieferungen abgegolten, die auf Grund eines Versehens nicht aufgeführt wurden, deren Erfordernis sich jedoch bei objektiver wirtschaftlicher Betrachtungsweise des Vertrags, insbesondere der Spezifikationen, als vom Auftragnehmer zu liefern ergeben. 0.2 Der unter 0.1 genannte Gesamtfestpreis berechnet sich im Einzelnen: Wareneingang und Qualitätskontrolle: … Auslagerungsbereich: … Automatisches Behälterlager: … Automatisches Palettenlager: … Materialflusssystem: … Produktionsanbindungen: … Lagerverwaltungssystem: … Informationszentrale: … Zwischenergebnis 1: … GU-Vergütung: … Zwischenergebnis 2: … ./. Nachlass … %: … Netto-Gesamtpreis: …

a) Aufwandsabreden, Vergütungsobergrenzen 313

Einigen sich die Vertragspartner auf eine Vergütung nach Aufwand, sind folgende Festlegungen im Vertrag erforderlich: – Höhe der Tagessätze, innerhalb derer bei vielen Anbietern Variationen nach den Aufgaben der Projektbeteiligten enthalten sind. Die Tagessätze 1 Das Formulierungsbeispiel stammt aus Habel/Rauch, Technologieverträge, S. 86. Die im ersten Absatz enthaltene Regelung, dass „versehentlich“ vergessene Leistungen vom Preis mit umfasst sind, halte ich für nicht empfehlenswert, da sich aus Sicht der Vertragspartner eine objektiv wirtschaftliche Betrachtung kaum finden lässt, die Regelung die Eskalation vorprogrammiert.

732

Witzel

Implementierung von Standardsoftware

Rz. 315 G

differenzieren beispielsweise nach Projektleitung, „sonstigen“ Beratern und Entwicklern. – Preisanpassungen: Vor allem bei langfristigen Projekten wird sich dem Softwareanbieter die Frage stellen, ob die vereinbarten Tagessätze im Verlaufe des Projekts erhöht werden können. – Abrechnungsmodalitäten: Wann wird abgerechnet und auf Basis welcher Leistungsnachweise? Müssen Leistungsnachweise, die Bestandteil der Abrechnungen sind, vom Auftraggeber gegengezeichnet sein (ein in der Praxis wohl hoffnungsloses Unterfangen)? Folgende Formulierung ist denkbar:

314

0.1 Der Auftraggeber vergütet die Leistungen des Auftragnehmers auf Basis folgender Tagessätze: Senior Consultant: … Junior Consultant:

…

Entwickler: … 0.2 Der Auftragnehmer ist berechtigt, die vereinbarten Tagessätze um … % pro Kalenderjahr zu erhöhen, erstmals jedoch zum 31.12. … Die Erhöhung setzt eine Ankündigung von … Monaten zum Ende des Kalenderjahres voraus. 0.3 Reisezeiten sind in den unter Ziff. 0.1 angegebenen Tagessätzen mit einkalkuliert. 0.4 Angefallenen Aufwand stellt der Auftragnehmer auf Basis seiner Leistungsnachweise monatlich in Rechnung.

Um den Anwendern die Budgetierung bei Aufwandsprojekten zu erleichtern, bietet sich die Vereinbarung einer Vergütungsobergrenze mit folgender Formulierung an:

0.1 Eine Vergütung nach Aufwand wird im Einzelvertrag entweder mit oder ohne Obergrenze vereinbart. Gleichzeitig wird im Einzelvertrag vereinbart, ob für Reiseaufwand eine Obergrenze gezogen ist oder nicht. Ist keine ausdrückliche Vereinbarung über Reiseaufwände im Einzelvertrag getroffen, sind diese nicht zusätzlich zu bezahlen. 0.2 Bei einer Vergütung nach Aufwand mit Obergrenze bleibt der Auftragnehmer auch dann zur vollständigen und ordnungsgemäßen Leistungserbringung verpflichtet, wenn die Obergrenze erreicht ist. Für eine Vergütung nach Aufwand gelten ansonsten die Vereinbarungen für eine Vergütung nach Aufwand ohne Obergrenze. 0.3 Eine Vergütung nach Aufwand erfolgt nach abrechenbaren Zeiten der Leistungserbringung. Diese Zeiten werden nur für die Leistungserbringung Witzel

733

315

G Rz. 316

Sonderregelungen

selbst nach voll geleisteten halben Stunden abgerechnet. Die Leistungserbringung durch eine Person in einer Kalenderwoche kann bis maximal 45 Stunden abgerechnet werden, außer es ist ausdrücklich und dokumentiert jeweils zuvor anderes vereinbart.

b) Fälligkeitsregelungen 316

Auch hier zeigt sich wieder individueller Regelungsbedarf. Unterstellt, ein Projekt über Anpassung, Einführung und Implementierung von Standardsoftware ist nach Werkvertragsrecht zu beurteilen, ergibt sich, dass die Vergütung mangels abweichender Regelung erst mit Abnahme fällig ist (§ 641 BGB). Die Vertragspartner müssen entweder einen Zahlungsplan aufstellen oder eine monatliche Abrechnung mit entsprechender Fälligkeit (z.B. „binnen 14 Tagen nach Rechnungsstellung“) vereinbaren. Eventuell kann auch bei der Fälligkeit nach den unterschiedlichen Leistungen differenziert werden: Leistungen mit eher dienstvertraglichem Charakter werden monatlich abgerechnet und sind dann auch monatlich zur Zahlung fällig. Bei den werkvertraglichen Leistungen wird demgegenüber ein Zahlungsplan vereinbart, der sich an den festgelegten Meilensteinen orientiert. Welche Vereinbarung getroffen wird, steht den Vertragspartnern frei. Jede getroffene Regelung sollte klar und deutlich sein.

X. Ablieferung, Abnahme und Tests 317

Jedes Projekt zur Anpassung, Einführung und Implementierung von Standardsoftware muss eindeutig abgeschlossen werden. Dazu wird eine formelle Abnahme/Übergabe1 erforderlich sein, völlig losgelöst von der Frage, ob die Abnahme bei der Anwendbarkeit von § 651 BGB entbehrlich wäre. 1. Gesetzliche Regelungen zur Abnahme und Konsequenzen des § 651 BGB a) Begrifflichkeiten und Terminologie

318

Die Begriffe Abnahme und Funktionsprüfung/-tests, Systemtests, Integrationstests werden häufig in einem Atemzug genannt, sind aber voneinander zu unterscheiden. Eine erfolgreiche Abnahme im Sinne von § 640 Abs. 1

1 Bartsch, Themenfelder einer umfassenden Regelung der Abnahme, CR 2006, 7; Bischof/Witzel, Vereinbarungen zu Test- und Abnahmeverfahren, ITRB 2006, 95; Hörl, Abnahmeregelungen in IT-Verträgen, ITRB 2001, 93; Müller-Hengstenberg/ Wild, Abnahme von Computerprogrammen, CR 1991, 327; s. Kap. D Rz. 194 ff.; Plath, Abnahme bei Individualsoftwareverträgen, ITRB 2002, 98; Wenzel, Kaufrechtliche Probleme in der Unternehmenspraxis und Lösungsvorschläge, DB 2003, 1987; Witzel, Abnahme und Abnahmekriterien im IT-Projektvertrag, ITRB 2008, 160.

734

Witzel

Implementierung von Standardsoftware

Rz. 325 G

Satz 1 BGB setzt sinnvollerweise die erfolgreiche Durchführung von Tests voraus, ist aber in rechtlicher Hinsicht nicht von diesen abhängig. Begrifflich werden im BGB unter „Abnahme“ zwei verschiedene Vorgänge verstanden, nämlich

319

– die Entgegennahme der vom Verkäufer gekauften Sache gemäß § 433 Abs. 2 BGB und – die Billigung eines Werks als im Wesentlichen vertragsgerecht (§ 640 Abs. 1 BGB), verbunden mit der Entgegennahme des Werkes. Die vertragliche Vereinbarung einer Funktionsprüfung bzw. der Durchführung von Funktionstests kann zugleich die Vereinbarung einer Abnahme im Sinne von § 640 Abs. 1 Satz 1 BGB darstellen: Mit erfolgreicher Durchführung der Funktionsprüfung gilt die angepasste und implementierte Software als abgenommen.

320

b) Wirkungen der Abnahme Materiellrechtlich erlischt mit erfolgreicher Abnahme der Erfüllungs- 321 anspruch des Anwenders und es besteht nur noch ein auf das abgenommene Werk bezogener Mängelbeseitigungsanspruch. Im Übrigen muss sich der Anwender bei Abnahme die Kenntnis von Mängeln entgegenhalten lassen (§ 640 Abs. 2 BGB). Weiter beginnt mit der Abnahme der Lauf der Verjährungsfrist für Mängel 322 (§ 634a Abs. 2 BGB) und es geht die Gefahr des zufälligen Untergangs oder der Verschlechterung des Werks auf den Anwender über (§ 644 BGB). Für den Softwareanbieter häufig von besonderer Bedeutung ist Folgendes: 323 Mit der Abnahme wird die Vergütung fällig (§ 641 Abs. 1 BGB). Diese Konsequenz des Werkvertragsrechts ist für die Softwareanbieter besonders schmerzlich: Besteht keine wirksame Vereinbarung zu einer abweichenden Regelung der Fälligkeit oder jedenfalls die vertragliche Verpflichtung des Anwenders zur Zahlung von Abschlagszahlungen, hat er vor der erteilten Abnahme keinen Zahlungsanspruch. Angesichts der durchschnittlichen Projektlaufzeit ist dies eine nicht befriedigende Position. Prozessual tritt eine Beweislastumkehr ein: Vor Abnahme hat der Anbieter 324 die Mangelfreiheit seines Werks zu beweisen, nach Abnahme der auftraggebende Anwender dessen Vorliegen1. Eine formelle Abnahme hat aber auch praktische Auswirkungen: Die Ab- 325 nahme schafft Klarheit. Klarheit über die Qualität der erbrachten Leistungen und die Erfüllung der Erwartungen der Beteiligten. Die Aufnahme der produktiven Nutzung ohne Abnahme führt häufig dazu, dass sich Qualität und Funktionalität der Software im Produktivbetrieb als unzureichend herausstellen. Es folgt eine Leidenszeit, die durch wechselseitigen Schrift1 BGH, BB 1996, 766.

Witzel

735

G Rz. 326

Sonderregelungen

wechsel – unter Einbeziehung von Geschäftsleitung und Anwälten –, leidgeprüfte Anwender, nicht ordentlich ablaufende Geschäftsprozesse und Aufwendungen für externe Berater geprägt ist. Ein Mindestmaß an Raum und Ressourcen für eine fachgerechte Abnahme minimiert dieses Risiko und bietet Sicherheit für beide Vertragspartner. 326

Dass eine formelle Abnahme unverzichtbar ist ergibt sich auch aus dem allgemeinen Risikomanagement oder Compliance-Aspekten für ein Unternehmen, in einigen Branchen ggf. aus aufsichtsrechtlichen Bestimmungen (etwa MARisk). Kommt es in Folge eines Softwaremangels, der bei einer Abnahme entdeckt hätte werden können, zu Produktionsausfällen, Datenverlusten oder anderen Folgeschäden, wird die Geschäftsleitung eines Anwenders in Erklärungsnöte gelangen, wenn für ein produktiv gesetztes, unternehmenskritisches System keine Abnahme vorliegt. c) Auswirkungen des § 651 BGB

327

Kommt § 651 BGB auf die Anpassung, Einführung und Implementierung von Verträgen über Standardsoftware zur Anwendung, würde das Erfordernis der Abnahme streng genommen entfallen: Für einen Vertrag über die Lieferung herzustellender oder zu erzeugender beweglicher Sachen gilt nach § 651 Satz 1 BGB Kaufrecht. Soweit es sich dabei um nicht vertretbare Sachen handelt, sind nach § 651 Satz 3 BGB ergänzend einige werkvertragliche Regelungen (§§ 642, 643, 645, 649, 650 BGB) anzuwenden. Die Anwendung der Regelungen zur Abnahme wird allerdings explizit ausgeschlossen und durch die kaufrechtlichen Regelungen zum Gefahrübergang gemäß §§ 446, 447 BGB ersetzt.

328

Ob nun Kaufrecht auf Verträge über die Anpassung, Einführung und Implementierung von Standardsoftware zur Anwendung kommt1, kann angesichts der praktischen Notwendigkeiten im Rahmen eines komplexen Projekts dahinstehen. Die Vertragspartner werden nicht umhin kommen, vertragliche Vereinbarungen zur Durchführung von Tests und einer finalen Überprüfung des Systems vor Produktivsetzung festzulegen. Das Erfordernis einer „Überprüfung“ der einzelnen Leistungen des Anbieters und der Feststellung, ob die angepasste Standardsoftware in der Systemlandschaft des Anwenders auch tatsächlich läuft, wird schon aus technischen Gegebenheiten unumgänglich sein. Ob eine erfolgreiche Funktionsprüfung dann auch eine Abnahme im rechtlichen Sinne abdeckt, ist bei der vertraglichen Gestaltung von nebensächlicher Bedeutung.

1 S. dazu oben Rz. 71 ff.

736

Witzel

Implementierung von Standardsoftware

Rz. 332 G

2. Testverfahren, Testverpflichtung a) Notwendigkeit vertraglicher Regelungen aa) Erarbeitung von Testprozeduren Im Hinblick auf die bestehenden Unklarheiten zu den Konsequenzen des § 651 BGB auf die vertragstypologische Einordnung empfiehlt es sich für beide Vertragspartner, in ihre vertragliche Vereinbarung eine Regelung zur Durchführung von Tests1 aufzunehmen, die dem Inhalt und der Komplexität eines Einführungsprojekts gerecht wird. Die Vertragspartner sollten sich über folgende Fragen Gedanken machen:

329

– Welche Tests sind von wem und in welchem Umfang und in welchem Stadium des Projekts durchzuführen? – Wie viel Zeit sollen die Tests in Anspruch nehmen? – Von wem ist das Testsystem und wann zu stellen? – Wann müssen Testdaten in welchem Umfang vorliegen? Laut Streitz2 kann bei Projekten ab einer Größenordnung von 50 000 Euro 330 die Abnahme – also die Durchführung von Tests – nicht mehr an einem Tag erfolgen. Die Leistungen sind so komplex und die möglichen Auswirkungen auf den Geschäftsbetrieb derartig vielschichtig, dass ein längerer Zeitraum zur Prüfung des abgelieferten Ergebnisses notwendig ist. Die Tests werden sich im Regelfall über einen Zeitraum von mehreren Wochen erstrecken. Welche Zeiträume genau erforderlich sind, muss der Vertrag definieren. Die vertraglichen Regelungen sollten Vorgaben zur Erarbeitung von Test- 331 prozeduren enthalten. Solche Testprozeduren sollten wiederum auf der Leistungsbeschreibung und den darin beschriebenen Funktionalitäten beruhen. Testprozeduren sollten gemeinsam – aber unter der Federführung des Anwenders – erarbeitet werden: Der Anwender ist am ehesten in der Lage, realistische Testfälle auf Basis der täglichen Arbeit zu entwickeln und will im Übrigen das Erreichen seiner Projektziele sicherstellen3. bb) Weiterer Regelungsbedarf Die vertraglichen Regelungen – ggf. auch die Leistungsbeschreibung – soll- 332 ten alle notwendigen Informationen enthalten, um Tests vorzubereiten, durchzuführen und zu beurteilen: – Bezugnahme/Referenzierung auf die fachlichen Anforderungen des Anwenders;

1 Müller-Hengstenberg/Kirn, Die technologischen und rechtlichen Zusammenhänge der Test- und Abnahmeverfahren in IT-Projekten, CR 2008, 755. 2 Streitz, IT-Projekte retten, S. 137. 3 Die Beibringung von Testfällen und Testdaten sowie die Durchführung von Tests ist auch Teil der Mitwirkung des Anwenders.

Witzel

737

G Rz. 333

Sonderregelungen

– Festlegung der Testart: Korrektheits-, Vollständigkeits-, Robustheits-, Leistungs- oder Dokumentationstests; – erwartete Verarbeitungsfolge; – Klassifikation der Fehler. 333

Die Vertragspartner müssen sich darauf verständigen, welche Tests/Testarbeiten durchgeführt werden sollen. Auch hier finden sich die verschiedensten Begrifflichkeiten, die keineswegs eindeutig zugeordnet sein müssen: Funktionstests, Systemtests, Integrationstests, Unit-Tests, Last-Tests1. Um Auseinandersetzungen zu vermeiden, sollten die Vertragspartner festlegen, was sie unter den einzelnen vorgesehenen Tests verstehen oder welchen Umfang die vereinbarten Tests haben sollen.

334

Begleitend zu den Tests wird ein entsprechender Testdatenbestand benötigt. Die Vertragspartner müssen sich über Art, Umfang und Qualität der Testdaten verständigen. Werden Testdaten durch den Softwareanbieter erstellt, muss der Anwender die Eignung für die Tests prüfen, damit nicht nur wenige – ausgewählte – Konstellationen oder ausgewählte Standardfunktionalitäten getestet werden. Idealerweise werden für die Tests Echtdaten verwendet, die dann vom Anwender beizubringen sind.

335

Bei größeren Projekten sollte ein Testplan erstellt werden, der die benötigten Ressourcen (wie Räume, Server, Arbeitsplätze, Mitarbeiter), die durchzuführenden Tests und die damit betrauten Mitarbeiter einteilt. Die Planung der Tests darf nicht vernachlässigt werden, da die Durchführung von Tests mit zusätzlicher Arbeit verbunden ist, die nicht zum normalen Arbeitsumfang der Fachabteilungen gehört.

336

Anwender aus den Fachabteilungen sind allerdings unbedingt notwendig, da sie die angepasste und eingeführte Standardsoftware nutzen sollen und damit auch akzeptieren müssen. Im Rahmen der Ressourcenplanung muss festgelegt werden, welche Systeme für die Hardware eingesetzt werden, 1 Nach Irlbeck/Langenau/Mayer, Computer-Lexikon, definiert sich ein Systemtest als „Überprüfung eines Programms auf Fehlerfreiheit“. Der Systemtest ist ein aufwendiges Verfahren, das den bei der Programmierung anfallenden Zeitaufwand meist um ein Vielfaches übertrifft. Der Systemtester muss ein Programm wie der spätere Anwender bedienen und die für das Programm typischen Aufgaben durchführen, sich in die Lage von Anwendern versetzen und bewusst Anfängerfehler machen, um die Reaktionen des Programms zu testen, Fehler simulieren und erzeugen und das Verhalten des Programms beobachten, sowie das Programm bis an seine Grenzen testen. Unter www.wikipedia.org wird ein UnitTest als „Teil eines Softwareprozess-Vorgehensmodells“ (z.B. Extreme Programming) beschrieben. Unit-Tests dienen demzufolge zur Validierung der Korrektheit von Modulen einer Software, z.B. von einzelnen Klassen. … Nach jeder Änderung sollte durch Ablauflassen aller Testfälle die Fehlerfreiheit geprüft werden. Ein Integrationstest ist nach www.wikipedia.org eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, verschiedene voneinander unabhängige Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen.

738

Witzel

Implementierung von Standardsoftware

Rz. 337 G

welche Arbeitsplätze zur Verfügung stehen und welche sonstigen Arbeitsmittel benötigt werden. cc) Gestaltungsvorschlag Eine Formulierung zu Tests und Testprozedere könnte wie folgt aussehen: 01.

Abnahme des Pflichtenhefts Die Abnahmeprüfung durch den Auftraggeber erfolgt innerhalb von zehn Arbeitstagen ab Übergabe des Pflichtenhefts an den Auftraggeber. Mit Abnahme des Pflichtenhefts wird dieses wesentlicher Bestandteil dieses Vertrags und entsprechend unterzeichnet. Mit der schriftlichen Abnahme des Pflichtenhefts erklärt der Auftraggeber, dass die Geschäftsprozesse im Pflichtenheft vollständig und inhaltlich richtig abgebildet sind. Die Verantwortung für die technische Machbarkeit und technische Umsetzung übernimmt der Auftragnehmer. Der Auftraggeber wird dem Auftragnehmer etwaige wesentliche Sachmängel des Pflichtenhefts (z.B. Fehlen von in Workshops vereinbarten Festlegungen, sachlich falsche oder widersprüchliche Festlegungen, Inkonsistenzen der Geschäftsprozesse, falsche Darstellung der Geschäftsprozesse) unverzüglich schriftlich mitteilen. Der Auftragnehmer wird solche Sachmängel unverzüglich beheben und dem Auftraggeber eine geänderte Fassung des Pflichtenhefts zur Verfügung stellen. Bis zur Verfügbarkeit der korrigierten Version des Pflichtenhefts wird die Abnahmefrist ausgesetzt. Sonstige unwesentliche Sachmängel des Pflichtenhefts (z.B. unpräzise Formulierungen, grammatikalische Fehler, Rechtschreibfehler) sind vom Auftraggeber ebenfalls schriftlich mitzuteilen und werden vom Auftragnehmer unverzüglich behoben, ohne dass die Abnahmefrist ausgesetzt wird. 02. Teilabnahme Nur sofern Teilabnahmen im Pflichtenheft festgelegt sind, ist der Auftragnehmer berechtigt, Teilabnahmen zu verlangen. Die Leistung zu einem Produktivsetzungstermin kann mit entsprechender Festlegung im Pflichtenheft Gegenstand einer Teilabnahme sein. Teilabnahmen haben keine Auswirkungen auf die Endabnahme, es sei denn, die Vertragspartner treffen im Pflichtenheft ausdrücklich eine andere Regelung. Für Teilabnahmen gilt diese Ziffer … entsprechend. 03. Tests der individuellen Anpassungen 03.1. Testfälle, Testdaten und Testkonzept Individuelle Anpassungen werden zunächst vom Auftragnehmer intern eingehend getestet. Hiernach werden sie von den Vertragspartnern gemeinsam getestet. Für diese Tests wird der Auftragnehmer Testfälle vorschlagen und mit dem Auftraggeber abstimmen, die angeforderten Test-

Witzel

739

337

G Rz. 337

Sonderregelungen

daten einpflegen und ein Testkonzept erarbeiten. Jedes Testkonzept beinhaltet – den zeitlichen Rahmen für die Durchführung der Tests – eine Beschreibung der Zielsetzung der jeweiligen Tests – eine Beschreibung des Testumfangs – die Festlegung der Testumgebung. Testkonzepte sind integraler Bestandteil dieses Vertrages. Nachvollziehbar und schlüssig dargestellter Mehraufwand, insbesondere Personalkosten des Auftraggebers, die durch mangelhaftes Testen seitens des Auftragnehmers entstehen, sind vom Auftragnehmer zu ersetzen, wenn der Auftragnehmer diese Pflichtverletzung zu vertreten hat. Einer Mahnung bedarf es hierzu nicht. Der zu ersetzende Mehraufwand des Auftraggebers wird mit EUR 600,00 netto pro Tag und Person berechnet. 03.2 Teilabnahmen Nur sofern im Pflichtenheft festgelegt, können individuelle Anpassungen Gegenstand von Teilabnahmen sein. Ziffer 04 gilt entsprechend hinsichtlich der Endabnahme. 04. Abnahmeprüfung (Integrationstest) und Abnahme der Vertragssoftware 04.1 Durchführung des Integrationstests Innerhalb von zwei Wochen nach Erhalt einer schriftlichen Erklärung des Auftragnehmers, dass die Vertragssoftware oder die individuelle Anpassung, die Gegenstand einer Teilabnahme ist, zur Abnahme bereitsteht, wird der Endkunde eine Abnahmeprüfung entsprechend der Regelungen in dieser Ziffer 04 beginnen. Die Abnahmeprüfung besteht aus einem Integrationstest, der auf den Testfällen und dem Pflichtenheft beruht. Die Testfälle sollen alle wesentlichen Funktionen der Vertragssoftware abdecken. Dieser Integrationstest wird durch die Key User des Endkunden durchgeführt. Der Auftragnehmer stellt Unterstützung zur Verfügung, sofern dies notwendig ist. Während der Abnahmeprüfung führen die Vertragspartner ein Protokoll, das von beiden Projektleitern unterzeichnet wird. 04.2 Abnahmeerklärung Falls die Abnahmeprüfung erfolgreich ist, wird der Auftraggeber entweder die Teilabnahme oder die Abnahme erklären. Die Vertragssoftware ist abnahmefähig, wenn die Vertragssoftware keine betriebsverhindernden und höchstens drei betriebsbehindernde Mängel aufweist. In diesem Fall ist die Vertragssoftware abzunehmen. Ist die Vertragssoftware nicht abnahmefähig, ist der Auftraggeber zur Verweigerung der Abnahme berechtigt. Jeder Mangel, der während der Abnahmeprüfung auftritt, wird vom Auftraggeber an den Auftragnehmer im Abnahmeprotokoll gemeldet. Diese Meldung enthält die für den Auftraggeber erkennbaren Umstände, um

740

Witzel

Implementierung von Standardsoftware

Rz. 338 G

den Mangel zu identifizieren und zu lokalisieren (z.B. die Umstände, unter denen sich der Mangel zeigte, Fehlermeldungen, Screenshots). Sofern die Abnahmeprüfung nicht entsprechend der vorstehenden Bestimmungen erfolgreich ist, ist der Auftraggeber berechtigt, die Abnahmeerklärung zu verweigern. Er ist weiterhin berechtigt, dem Auftragnehmer eine angemessene Nachfrist von mindestens zehn Arbeitstagen zur Beseitigung bestehender Mängel zu setzen. Nach Ablauf dieser Nachfrist wird die Abnahmeprüfung auf Basis des gleichen Vorgehens wiederholt („erster Wiederholungstest“). Sofern der erste Wiederholungstest erneut Mängel aufweist, die die Abnahme verhindern, wird auf Basis des gleichen Vorgehens mit denselben Fristen ein zweiter Wiederholungstest erfolgen. Sofern auch der zweite Wiederholungstest scheitert ist der der Auftraggeber berechtigt, seine gesetzlichen Rechte auszuüben bzw. Ansprüche geltend zu machen (s. dazu Ziffer … dieses Vertrages). Nachvollziehbar und schlüssig dargestellter Mehraufwand, insbesondere Personalkosten, des Auftraggebers, die durch eine erfolglose Abnahmeprüfung hervorgerufen werden, sind vom Auftragnehmer zu ersetzen, wenn der Auftragnehmer diese Pflichtverletzung zu vertreten hat. Einer Mahnung bedarf es hierzu nicht. Der zu ersetzende Mehraufwand des Auftraggebers wird mit 600 Euro netto pro Tag und Person berechnet. 04.3 Abnahmefiktion bei Produktivnutzung Sofern der Auftraggeber die Vertragssoftware nicht nur vorübergehend (d.h. mehr als vier Wochen) oder zu reinen Testzwecken produktiv nutzt, gilt die Vertragssoftware als abgenommen, wenn der Auftraggeber in einen Zeitraum von vier Wochen keine betriebsverhindernden und nicht mehr als drei betriebsbehindernde Mängel meldet. Kommt es nur zu einer teilweisen Produktivnutzung, so gilt die Fiktion nur für den produktiv genutzten Teil der Vertragssoftware.

3. Stillschweigende Abnahme Die Abnahme muss nicht ausdrücklich erklärt werden. Voraussetzung einer 338 stillschweigenden Abnahme ist grundsätzlich, dass das Werk vollendet, d.h. bei natürlicher Betrachtung als Erfüllung der vertraglich geschuldeten Leistung anzusehen ist. Eine stillschweigende Abnahme kann – unter Berücksichtigung des gesamten erkennbaren Verhaltens des Anwenders – angenommen werden, wenn der Anwender – das jeweilige Programm über einen nicht unerheblichen Zeitraum produktiv nutzt, und zwar auch dann, wenn das Programm noch Mängel aufweist und der Anwender hiervon Kenntnis hat1;

1 OLG München, CR 1991, 19 (21); OLG Köln v. 16.5.1990 – 13 U 108/89, DB 1990, 1865.

Witzel

741

G Rz. 339

Sonderregelungen

– eine Teilwerklohnzahlung leistet und den Anbieter mit Programmänderungen beauftragt1, nicht allerdings, wenn der Anwender zwar zahlt, aber zahlreiche Beanstandungen erhebt; – in einer Übernahmebestätigung die gelieferte Anlage als funktionsfähig und vertragsgemäß bezeichnet2; – die Software nach Kenntniserlangung von den Mängeln weiternutzt3. 339

Der Anwender muss bei oder nach Entgegennahme der Leistung grundsätzlich erkennen lassen, dass er die Leistung als eine im Wesentlichen ordnungsgemäße Erfüllung gegen sich gelten lassen will. 4. Fiktionen

340

Vertraglich vereinbaren lassen sich auch die unterschiedlichsten Abnahmefiktionen – die AGB-rechtlich wohl überwiegend höchst problematisch, mithin unwirksam sind, sich individuell aber vereinbaren lassen. Die könnte wie folgt formuliert werden:

Werden die in Ziffer … festgelegten Tests nicht durchgeführt ohne dass dies der Auftragnehmer zu vertreten hat, gelten die erbrachten Leistungen spätestens vier Wochen nach Bereitstellung zum Test als vertragsgemäß geliefert, d.h. als abgenommen.

Werden Abnahmefiktionen vereinbart, sollte deren Rechtswirkung auch beiden Vertragspartnern bewusst sein. Die Voraussetzungen für die Fiktionen sollten unmissverständlich und klar geregelt sein. 5. Datenschutzrechtliche Aspekte bei Tests und Abnahme 341

Auch bei Projekten zur Anpassung, Einführung und Implementierung von Standardsoftware spielt der Datenschutz eine immer größere Rolle, unter anderem auch bei Tests und Abnahme, wenn mit personenbezogenen Daten (häufig als Echtdaten bezeichnet) des Anwenders getestet werden soll4. Wie jede andere Verarbeitung personenbezogener Daten muss auch die im Rahmen von Tests und Abnahmeprüfungen gesetzlich zulässig sein. Als personenbezogene Daten kommen vor allem die Beschäftigtendaten des Anwenders oder die Daten der Kunden des Anwenders in Betracht. Um nicht dem Anwendungsbereich des BDSG zu unterstehen, müssen die für Tests 1 BGH, NJW 1973, 1792; OLG München v. 24.1.1990 – 27 U 901/88, CR 1991, 19 = DB 1990, 1865. 2 OLG Hamburg v. 9.8.1985 – 11 U 209/84, CR 1986, 83. 3 OLG München v. 24.1.1990 – 27 U 901/88, CR 1991, 19 = DB 1990, 1865. 4 Conrad, in: Auer-Reinsdorff/Conrad, Beck’sches Mandatshandbuch IT-Recht, § 16 Rz. 225.

742

Witzel

Implementierung von Standardsoftware

Rz. 344 G

und Abnahme herangezogenen Daten anonym sein; bei nur pseudonymisierten Daten sind die Vorschriften des BDSG anwendbar. Dies gilt natürlich erst recht, wenn die Daten unverändert bei Tests genutzt werden.

XI. Leistungsstörungen 1. Vorbemerkung Leistungsstörungen1 im Rahmen eines Projekts über Anpassung, Einführung und Implementierung von Standardsoftware können so vielfältig sein wie das Leistungsportfolio in solchen Projekten:

342

– – – –

verzögerte und verspätete Leistung des Softwareanbieters; endgültige Nichtleistung des Softwareanbieters; verzögerte und verspätete Mitwirkung des Anwenders; endgültige Nichterbringung von Mitwirkungsleistungen seitens des Anwenders; – Schlechtleistung seitens des Softwareanbieters, insbesondere mangelhafte Umsetzung der fachlichen Anforderungen des Anwenders bei Anpassung der Standardsoftware, aber auch schlechte Beratungsleistung, mangelndes Projektmanagement etc.; – Schlechtleistung seitens des Anwenders bei Erbringung seiner Mitwirkungsleistungen; – Verletzung von Nebenpflichten, wie Geheimhaltung und Datenschutzregelungen. Die vertraglichen Regelungen zu den Leistungsstörungen sollten berück- 343 sichtigen, dass das unterschiedliche und vielfältige Leistungsspektrum auch eine differenzierte Regelung zu den sich daraus ergebenden Störungen rechtfertigen kann. Allein mit einer Regelung zu Mängeln der Software dürfte es nicht getan sein. Insoweit ist auch Folgendes zu bedenken: Projekte, die scheitern, scheitern mehrheitlich vor der erfolgreichen Abnahme. Ist ein System einmal produktiv – ohne wesentliche Mängel – im Einsatz, wird das Scheitern immer unwahrscheinlicher, die Risiken für einen Anwender bei einer Rückkehr auf sein Altsystem nahezu unübersehbar. Der Vertrag muss Vorsorge dahingehend treffen, dass für den Verzug und die endgültige Nichterfüllung Regelungen getroffen sind. Wie oben2 ausgeführt, lässt sich auf Verträge über Anpassung, Einführung 344 und Implementierung von Standardsoftware die „Lehre vom gemischten Vertrag“ anwenden. In deren Konsequenz ist nunmehr zu prüfen, ob sich die vertraglichen Vereinbarungen zu den Leistungsstörungen an einem bestimmten Vertragstyp orientieren können oder ob dabei zu modifizieren ist. 1 Amann/Brambring/Hertel, Die Schuldrechtsreform in der Vertragspraxis, S. 7 ff.; s. Kap. D Rz. 245 ff. 2 S. Rz. 99 ff.

Witzel

743

G Rz. 345

Sonderregelungen

Zunächst zu den Voraussetzungen und Konsequenzen, die sich aus der Schuldrechtsreform für Leistungsstörungen ergeben. 2. Überblick zu den durch die Schuldrechtsmodernisierung bedingten Änderungen im Leistungsstörungsrecht a) Begriff der Leistungsstörung 345

346

Zentraler Begriff des Leistungsstörungsrechts nach Schuldrechtsreform1 ist die Pflichtverletzung. Nach § 280 Abs. 1 Satz 1 BGB ist der Schuldner, der eine Pflicht aus einem Schuldverhältnis verletzt, verpflichtet, dem Gläubiger den hierdurch entstehenden Schaden zu ersetzen. Pflichtverletzung meint einen objektiven Verstoß gegen eine Pflicht aus einem Schuldverhältnis. Ein Schuldverhältnis entsteht unter den Voraussetzungen des § 311 Abs. 3 BGB. Es kommt nicht ausschließlich darauf an, dass der Schuldner die Pflichtverletzung zu vertreten hat; so setzt der Rücktritt gemäß § 323 BGB eine Pflichtverletzung voraus, der Gläubiger kann aber auch dann vom Vertrag zurücktreten, wenn der Schuldner die Pflichtverletzung nicht zu vertreten hat. Der Begriff der Pflichtverletzung umfasst alle Formen der Leistungsstörung: – Unmöglichkeit und das Unvermögen (mit Sonderregelungen in §§ 275, 283, 311a, 326 BGB); – teilweise Nichtleistung (§ 281 Abs. 1 Satz 2 BGB); – Verzug (§§ 280 Abs. 2 BGB, 286 BGB: Verzögerungsschaden; §§ 280 Abs. 3, 281 Abs. 1 Satz 1 BGB: Schadensersatz statt der Leistung); – Schlechtleistung (§ 281 Abs. 1 Satz 1 BGB: nicht wie geschuldet). Zur Schlechtleistung gehört insbesondere die Verletzung der Pflicht aus § 433 Abs. 1 Satz 2 BGB, nach der der Verkäufer die Pflicht hat, dem Käufer die Sache frei von Sach- und Rechtsmängeln zu verschaffen. Einem Sachmangel steht es nach § 434 Abs. 3 BGB gleich, wenn der Verkäufer eine andere Sache (aliud) oder eine zu geringe Menge liefert; – positive Forderungsverletzung (als Anspruchsgrundlage insbesondere für Mangelfolgeschäden); – Verschulden bei Vertragsschluss (c.i.c.) unter Erstreckung der Haftung auf Dritte (sog. Sachwalterhaftung) nach § 311 Abs. 3 BGB; – Verletzung einer Schutzpflicht.

347

Es kommt im Ergebnis nicht darauf an, welche vertragliche Pflicht der Schuldner verletzt hat, solange feststeht, dass er eine Pflicht verletzt hat. Die Pflichtverletzung ist weiterhin objektiv zu verstehen und setzt kein vorwerfbares Verhalten voraus. Für den Softwareanbieter ergeben sich daraus folgende Schreckensszenarien:

1 Graf von Westphalen/Meier-Göring, Neues Schuldrecht, S. 1 ff.

744

Witzel

Implementierung von Standardsoftware

Rz. 349 G

– Im Worstcase – dem endgültigen Scheitern des Projekts vor Abnahme (erfolgreicher Produktivsetzung) – droht die Rückabwicklung, bei zu vertretenden Pflichtverletzungen zusätzlich der Schadensersatz statt der Leistung. – Jedwede zu vertretende Pflichtverletzung zieht einen Schadensersatzanspruch nach sich, der auch besteht, wenn das Projekt letztlich zum Erfolg führt. – Auch im Fall einer Rückabwicklung nach Abnahme besteht zusätzlich ein Schadensersatzanspruch des Anwenders. – Schadenersatzansprüche ergeben sich aus § 280 BGB auch, wenn dem Softwareanbieter die Nacherfüllung binnen angemessener Frist gelingt. § 280 BGB ermöglicht ihm die Geltendmachung von Betriebsausfallschäden. b) Rechtsfolgen einer Pflichtverletzung aa) Schadensersatz § 280 BGB ist die zentrale Norm für alle Schadensersatzansprüche. Danach 348 führt jede Pflichtverletzung zu einem Schadensersatzanspruch, es sei denn der Schuldner hat die Pflichtverletzung nicht im Sinne der §§ 276 bis 278 BGB zu vertreten. Verschulden liegt vor, wenn dem Schuldner Vorsatz oder Fahrlässigkeit zu Last fällt. Das Verschulden von gesetzlichen Vertretern und Erfüllungsgehilfen ist gleich gestellt. § 280 Abs. 1 Satz 2 BGB enthält eine Verschuldensvermutung. Der Schuldner muss sich also nicht nur von eigenem Verschulden, sondern auch von dem eines gesetzlichen Vertreters oder Erfüllungsgehilfen entlasten1. Aus der Verschuldensvermutung kann sich für die Softwareanbieter eine erhebliche Gefahr ergeben, da der Beweis, eine Pflichtverletzung nicht vertreten zu müssen, kaum gelingen dürfte. Die Grundnorm des § 280 BGB ist für jeden Schadensersatzanspruch aus 349 der Verletzung einer Pflicht aus einem Schuldverhältnis abschließend, soweit es um den Ersatz des Schadens geht, den der Gläubiger unabhängig von der Nicht- und Schlechtleistung verlangt. Für den Schadensersatz im 1 Zum möglichen Entlastungsbeweis heißt es bei Erman/Westermann, § 280 BGB Rz. 31: „An den Entlastungsbeweis dürfen nicht zu hohe Anforderungen gestellt werden …, ein nicht leicht zu handhabendes Kriterium, das den Schuldner nicht von der Obliegenheit befreit, die aus einer Pflichtverletzung und einem daraus hervorgegangenen Schaden folgende Verschuldensvermutung durch Gegenbeweise zu widerlegen … Immerhin hat der Schuldner die Möglichkeit, die – vom Gegner – nicht nachgewiesene, aber denkbare Ursache als unwahrscheinlich zu beweisen oder darzutun, dass er die wahrscheinliche Ursache jedenfalls nicht zu vertreten hat … Bestehen mehrere Möglichkeiten für die Verursachung des Schadens, so betrifft die Notwendigkeit der Entlastung alle Alternativen, was zugleich bedeutet, dass der Entlastungsbeweis misslingt, wenn von mehreren möglichen Ursachen eine, die vom Schuldner zu vertreten wäre, nicht ausgeschlossen werden kann.“

Witzel

745

G Rz. 350

Sonderregelungen

Fall der Unmöglichkeit gilt die Sonderregelung des § 311a BGB. Die Konzeption des Leistungsstörungsrechts zielt nicht darauf ab, welche Pflicht der Schuldner verletzt hat, und bestimmt danach die ersetzbare Schadensposition, sondern geht nur noch danach, ob er überhaupt eine Pflicht verletzt hat und ob dadurch irgendein Schaden entstanden ist. 350

Der einfache Schadensersatzanspruch (§ 280 BGB) tritt anders als der Schadensersatzanspruch statt der Leistung (§ 281 BGB) nicht an die Stelle, sondern neben den Erfüllungsanspruch. Er erstreckt sich auf alle unmittelbaren und mittelbaren Nachteile des schädigenden Verhaltens (der objektiven Pflichtverletzung) und erfasst damit alle neben der Leistungserbringung bereits endgültig eingetretenen Schäden. Der Schadensersatzanspruch des § 280 BGB schwebt über dem Softwareanbieter während der Laufzeit des gesamten Anpassungs-, Einführungs-, und Implementierungsprojekts: Jede Nichteinhaltung vertraglicher Pflichten, die beim Anwender zu einem Schaden führt, kann zu Ersatzansprüchen führen. Hat der Anwender beispielsweise erhöhter Testaufwand, weil die vereinbarten Qualitätssicherungsmaßnahmen bei Erweiterungs- und Zusatzprogrammierungen nicht eingehalten wurden, ist dieser nach § 280 BGB zu ersetzen. Das Gleiche gilt für mangelhafte Beratung seitens des Softwareanbieters, wenn bspw. der Anwender auf seine Empfehlung ein zusätzliches Tool erwirbt, das sich im weiteren Projektverlauf als ungeeignet für seine Zwecke herausstellt. Die praktische Bedeutung dieses Schadensersatzanspruchs und die sich daraus ergebenden Risiken für den Softwareanbieter dürften jedenfalls solange gering sein, wie die Vertragspartner ein Interesse an der erfolgreichen Projektdurchführung haben. Man wird über manche Pflichtverletzung und den daraus resultierenden Aufwand hinwegsehen, um die Atmosphäre im Projekt nicht zu vergiften. Das sollte die bestehenden Risiken nicht verwischen: Gerät das Projekt in die Schieflage, hat der Anwender ein gutes Druckmittel.

351

Schadensersatz statt der Leistung (§§ 281 bis 283 BGB) erfasst solche Schadenspositionen, mit denen der Gläubiger die eigentlich geschuldete Leistung ersetzt verlangen will. Darunter fallen also nur Schäden, die durch Erfüllung des Leistungsanspruchs oder bei Schlechterfüllung durch Nacherfüllung (noch) abgewendet werden können. Schadensersatz statt der Leistung droht dem Softwareanbieter also im Falle des Scheiterns des Projekts. Die Schäden können erheblich sein, bspw. höhere Kosten für ein Ersatzsystem, entgangener Gewinn oder „Lost Profit“.

352

Der Verzögerungsschaden nach § 286 BGB ist der Schaden, der dem Gläubiger durch die Verzögerung der Leistung entsteht: Er tritt neben den Leistungsanspruch. Und er bleibt auch dann bestehen, wenn dem Gläubiger nachträglich ein Schadensersatzanspruch statt der Leistung entsteht.

746

Witzel

Implementierung von Standardsoftware

Rz. 356 G

bb) Rücktritt Die §§ 323 ff. BGB regeln, unter welchen Voraussetzungen bei Leistungsstö- 353 rungen im gegenseitigen Vertrag die Pflicht zur Gegenleistung entfällt, insbesondere unter welchen Voraussetzungen der Gläubiger vom Vertrag zurücktreten kann. Rücktritt wie Schadensersatz gehen von einem einheitlichen Grundtatbestand aus: Der Pflichtverletzung. Der wesentliche Unterschied zwischen Rücktritt und Schadensersatz besteht darin, dass der Rücktritt kein Verschulden voraussetzt. Der Rücktritt führt in seinen Rechtsfolgen nur zur Rückabwicklung des Vertrags, während beim Schadensersatz statt der Leistung dem Gläubiger das Erfüllungsinteresse zu ersetzen ist1. Voraussetzung für einen Rücktritt ist das Vorliegen einer Pflichtverletzung sowie eine erfolglose Nachfristsetzung. Liegt lediglich eine Schlechtleistung vor, so darf die Pflichtverletzung nicht unerheblich sein (§ 323 Abs. 5 Satz 2 BGB). cc) Ersatz vergeblicher Aufwendungen § 284 BGB stellt eine eigene Anspruchsgrundlage dar und ermöglicht dem 354 Gläubiger den Ersatz frustrierter Aufwendungen. Der Ersatz frustrierter Aufwendungen kann nur alternativ zum Schadensersatz geltend gemacht werden und nur bei Vorliegen der Voraussetzungen eines Schadensersatzanspruchs statt der Leistung. Der Gläubiger soll nicht positives und negatives Interesse ersetzt verlangen können. Ersetzt werden nur die Aufwendungen, die der Gläubiger im Vertrauen auf den Erhalt der Leistung gemacht hat und billigerweise machen durfte. Der Ersatz von Aufwendungen ist ausgeschlossen, wenn deren Zweck auch ohne die Pflichtverletzung des Schuldners nicht erreicht worden wäre. 3. Verzug Die Rechtsfolgen des Verzugs sind auch im neuen Schuldrecht gesondert ge- 355 regelt und spielen auch bei Projekten zur Anpassung, Einführung und Implementierung von Standardsoftware eine erhebliche Rolle. Ein komplexes Langzeitprojekt ohne Terminverschiebungen dürfte unwahrscheinlich sein. Wie bereits oben ausgeführt, ist es daher unumgänglich, dass der Vertrag entsprechende Regelungen vorsieht. a) Verbindlichkeit der vereinbarten Termine Der Streit der Vertragspartner im Fall von Verzögerungen beginnt im Regel- 356 fall schon damit, dass keine Einigkeit darüber zu erzielen ist, ob abgestimmte Termine verbindlich sind oder nicht. Während der Anwender auf verbindliche Terminabsprachen vertraut und darauf basierende Entscheidungen trifft und Investitionen tätigt, möchte der Softwareanbieter sich 1 S. Amann, S. 73.

Witzel

747

G Rz. 357

Sonderregelungen

spätestens bei Entreten der Schieflage nicht mehr an den Terminen festhalten lassen, die er erst selbst in den Raum gestellt hat. Im Zweifel wird ein Termin als verbindlich eingestuft werden1, soweit ihn die Vertragspartner nicht einvernehmlich als unverbindlich oder geplant bezeichnen. Leider sind die von den Vertragspartnern dazu gewählten Formulierungen häufig inkonsistent oder widersprüchlich. Während in der Präambel noch von einem Wunschtermin für den Go-Life die Rede ist, findet sich unter der Verzugsregelung eine verbindlich klingende Formulierung. Besonders problematisch wird die Feststellung, ob ein Termin verbindlich ist oder nicht, wenn es kein eigentliches Vertragsdokument gibt, sondern nur die Angebote des Softwareanbieters und dazu eine Flut von E-Mail-Korrespondenz. Um Konflikte über einen etwaigen Verzug und die daraus resultierenden Schäden zu vermeiden, sollten sich die Vertragspartner bereits während der Vertragsverhandlungen Gedanken darüber machen, wie sie mit Terminen umgehen wollen. Es kann interessengerecht sein, bei der Fülle an Terminen, die im Rahmen eines Projekts zur Anpassung, Einführung und Implementierung eine Rolle spielen, zu differenzieren. Nicht alle Termine sind von gleicher Bedeutung und müssen im Fall einer Verzögerung die gleichen Folgen auslösen. Es wird vor allem bei Langzeitprojekten auch immer Termine geben, die zunächst als unverbindlich eingestuft werden müssen, weil die Voraussetzungen für eine verbindliche Festsetzung noch zu klären sind. Beginnt ein Projekt mit einer Konzeptionierungsphase, kann im Vorfeld kein realistischer Termin für den Go-Life festgelegt werden, da die Dauer der Umsetzungsphase davon abhängen wird, welche umzusetzenden Anforderungen in der Konzeptionierungsphase tatsächlich ermittelt werden. Bewährt haben sich Regelungen, die nach Bedeutung und Auswirkung bestimmter Termine sowohl hinsichtlich der Voraussetzungen für den Verzugseintritt als auch hinsichtlich der Verzugsfolgen unterscheiden. 357

Formulierungsvorschlag 1: 01. Termin und Projektplan Die Vertragspartner sind verpflichtet, die im endgültigen Projektplan vereinbarten Termine für Leistung und Mitwirkung einzuhalten. Jede Abweichung soll möglichst frühzeitig erkannt und muss ohne schuldhaftes Zögern schriftlich angezeigt werden. Anpassungen des Projektplans können nur im gegenseitigen Einvernehmen und schriftlich vorgenommen werden. Der Projektplan enthält verbindliche Termine sowie ggf. kritische Termine. Verbindliche Termine sind alle zwischen den Vertragspartnern vereinbarten Liefer- und/oder Übergabetermine, Meilensteine und sonstigen Messpunkte für die Leistungserbringung eines Vertragspartners, die von den Vertragspartnern nicht ausdrücklich als „unverbindlich“, „geplant“, „voraus1 Dies lässt sich auch aus § 286 Abs. 3 Nr. 2 BGB ableiten, nach dem eine Mahnung dann entbehrlich ist, wenn für die Leistung durch vertragliche Vereinbarung eine Zeit nach dem Kalender bestimmt ist.

748

Witzel

Implementierung von Standardsoftware

Rz. 358 G

sichtlich“, „geschätzt“ bezeichnet sind. Kritische Termine sind verbindliche Termine, die im Projektplan von den Vertragspartnern besonders gekennzeichnet sind. 0.2 Verbindlicher Termin Wird ein verbindlicher Termin vom Auftragnehmer aus Gründen, die der Auftragnehmer zu vertreten hat, nicht eingehalten, hat der Auftraggeber der Geschäftsleitung des Auftragnehmers schriftlich eine Frist zu setzen, welche im Verhältnis zur dann noch zu erbringenden Leistung angemessen sein muss. Wird diese Frist nicht eingehalten und hat der Auftragnehmer dies zu vertreten, wird der Auftraggeber eine letzte angemessene Nachfrist, gerichtet an die Geschäftsleitung des Auftragnehmers setzen. Läuft die Nachfrist ergebnislos ab und hat der Auftragnehmer dies ausschließlich zu vertreten, kann der Auftraggeber von diesem Vertrag zurücktreten und den Ersatz eines etwaig entstandenen Schadens im Rahmen der vereinbarten Haftungsbeschränkungen (s. Ziffer …) geltend machen. 0.3 Kritische Termine Wird ein kritischer Termin vom Auftragnehmer aus Gründen, die der Auftragnehmer zu vertreten hat, nicht eingehalten, hat der Auftraggeber der Geschäftsleitung des Auftragnehmers schriftlich eine Frist zu setzen. Diese Verpflichtung zur Nachfristsetzung entfällt allerdings, wenn dem Auftraggeber eine solche Fristsetzung nicht zumutbar ist, z.B. wenn der Auftragnehmer die Erbringung der Leistung ausdrücklich verweigert hat. Eine vom Auftraggeber gesetzte Frist muss im Verhältnis zur dann noch zu erbringenden Leistung angemessen sein. Wird diese Frist nicht eingehalten und hat der Auftragnehmer dies zu vertreten kann der Auftraggeber vom Vertrag zurücktreten und den Ersatz eines etwaig entstandenen Schadens im Rahmen der vereinbarten Haftungsbeschränkungen (s. Ziffer …) geltend machen.

Formulierungsvorschlag 2: 0.1

358

Termine, Meilensteine und Projektplan. Aus der Projektübersicht in Anhang … ergeben sich unverbindliche und vorläufige Termine. Diese Termine werden durch einen abschließenden Projektplan mit verbindlichen Terminen und Meilensteinen abgelöst, der Bestandteil des Pflichtenhefts ist. Verbindliche Termine sind die Termine, die nicht als Meilensteine im Projektplan bezeichnet sind, jedoch von den Vertragspartnern gemeinsam schriftlich festgelegt worden sind und nicht ausdrücklich als unverbindlich gekennzeichnet wurden („unverbindlich“, „geplant“, „voraussichtlich“, „geschätzt“). Meilensteine sind die im Projektplan ausdrücklich als solche bezeichneten Termine für bestimmte Leistungen bzw. Mitwirkungsleistungen.

Witzel

749

G Rz. 359 0.2 0.2.1

0.2.2

0.2.3

0.3

0.4

Sonderregelungen

Anpassung von Terminen und Meilensteinen Höhere Gewalt Keiner der Vertragspartner ist verantwortlich für Verzögerungen, die durch Naturkatastrophen, Feuer, Unfall, Streiks, Krieg, Aufstand, Krawalle und Maßnahmen der Regierung sowie andere außerhalb der Kontrolle der Vertragspartner liegenden Ereignisse verursacht sind, soweit sie die allgemein üblichen Vorkehrungen zur Vermeidung solcher Ereignisse getroffen haben. Beide Vertragspartner werden alle angemessenen Maßnahmen treffen, Verzögerungen infolge solcher Ereignisse so gering wie möglich zu halten. Termine und Meilensteine, Verzögerungen Meilensteine können nur schriftlich im Änderungsverfahren gem. Ziffer … abgeändert werden. Verbindliche Termine können von der Projektleitung einvernehmlich schriftlich geändert werden. Sofern der Auftragnehmer von Umständen Kenntnis erlangt, die zu einer Verzögerung der Leistungserbringung führen könnten, wird der Auftragnehmer den Auftraggeber darüber unverzüglich informieren. Soweit nicht anders in diesem Vertrag vereinbart, werden die Vertragspartner unverzüglich partnerschaftlich darüber verhandeln, wie diese Problematik im Interesse beider Vertragspartner einvernehmlich gelöst werden kann. Der Auftragnehmer wird sich darum bemühen, Verzögerungen vorzubeugen, die Auswirkung etwaiger Verzögerungen zu minimieren und/oder Ereignisse zu vermeiden, die zu Verzögerungen führen können. Verzug Bei im Projektplan enthaltenen Meilensteinen kommt der Auftragnehmer bei unvollständiger Leistungserbringung zum vereinbarten Meilenstein ohne weitere Mahnung in Verzug. Verzug mit verbindlichen Terminen, die keine Meilensteine sind, setzt eine Mahnung des Auftraggebers voraus. Nachfristsetzung Voraussetzung für den Rücktritt des Auftraggebers aufgrund Verzugs des Auftragnehmers ist, dass der Auftraggeber nach Verzugseintritt dem Auftragnehmer eine angemessene schriftliche Nachfrist zur Leistungserbringung setzt.

b) Mahnung 359

Nach der gesetzlichen Regelung tritt Verzug auch ohne Mahnung ein, wenn für die Leistung durch Gesetz, Urteil oder (auch) nachträgliche vertragliche Vereinbarung eine Zeit nach dem Kalender bestimmt ist. Bei den meisten im Rahmen eines Projekts zur Anpassung, Einführung und Implementierung von Standardsoftware vereinbarten Terminen wird eine Mahnung ge-

750

Witzel

Implementierung von Standardsoftware

Rz. 361 G

nerell nicht erforderlich sein, da die Vertragspartner in aller Regel einen bestimmten Kalendertag entweder unmittelbar (1.1., 15.4., 30.6.) oder mittelbar (8. Kalenderwoche, drei Wochen nach Ostern, Mitte des Monats Juli) vereinbart haben dürften. Nicht ausreichend ist es für die Entbehrlichkeit der Mahnung, wenn die Leistungszeit nach dem Kalender nicht bestimmbar, sondern lediglich berechenbar ist, etwa dann, wenn der Projektvertrag von einer Projektlaufzeit von einer bestimmten Anzahl Monaten ausgeht. Gerade dann, wenn zwischen den Vertragspartnern Meinungsverschieden- 360 heiten bestehen, ob ein Termin verbindlich ist oder nicht, wird es sich empfehlen, eine Mahnung auszusprechen, damit sichergestellt ist, dass der Softwareanbieter ordnungsgemäß in Verzug gesetzt wurde. Da auch nicht allen verbindlichen Terminen zwingend die gleiche Bedeutung zukommt, sollten die Vertragspartner hinsichtlich des Erfordernisses einer Mahnung nach der Art der Termine differenzieren1. c) Fristsetzung aa) Verbrauchte Fristsetzungen Projekte, die in Folge von Verzögerungen bei der Leistungserbringung end- 361 gültig scheitern, sind dadurch gekennzeichnet, dass sie über längere Zeiträume notleidend sind. Auch kein noch so ungeduldiger Anwender wirft wohl nach der ersten Überschreitung eines Termins das Handtuch, denn dazu sind die bis dahin getätigten Investitionen zumeist zu groß. Es ist typisch, dass sich Schieflagen über mehrere Monate, wenn nicht Jahre hinziehen, bevor der Anwender sich zu einem Rücktritt und/oder zur Geltendmachung von Schadensersatz statt der Leistung durchringt. Regelmäßig wurden bis zu diesem Zeitpunkt Fristen gesetzt, die vermeintlich oder tatsächlich erfolglos verstreichen. Es finden Gespräche statt, der Lenkungsausschuss tagt und der Softwareanbieter liefert Updates und Korrekturen. Zwischendurch werden in diversen E-Mails Fristen gesetzt. Allerdings fehlt es im unmittelbaren Zusammenhang mit dem Rücktritt an einer Fristsetzung. Im Rahmen einer gerichtlichen Auseinandersetzung dreht sich der Streit dann auch darum, ob wiederholte, in der Vergangenheit liegende Fristsetzungen nicht bereits ausreichen. Nach § 323 Abs. 1 BGB ist Voraussetzung für den Rücktritt, dass eine Frist erfolglos verstreicht. Es ließe sich folglich durchaus argumentieren, dass ein Rücktritt, der in keinem unmittelbaren Zusammenhang mit einer Fristsetzung steht, sich mit diversen fehlgeschlagenen Fristen im Projektverlauf rechtfertigen lassen muss. Allerdings fordert § 323 BGB, dass im Zeitpunkt des Rücktritts zwei Voraussetzungen vorliegen müssen, nämlich der Rücktrittsgrund und die erfolglose Fristsetzung. Geht es bei einem notleidenden Projekt immer wieder zwischen Fristsetzungen und Leistungserbringung hin und her, so lässt sich der Anwender auch immer wieder auf neue Termine und ggf. sogar Änderungen 1 S. vorstehend, Rz. 356 ff.

Witzel

751

G Rz. 362

Sonderregelungen

im Leistungsumfang ein. Einigen sich die Vertragspartner trotz fehlgeschlagener Frist wieder auf neue Termine für die Leistungserbringung, wird der Rücktrittsgrund einvernehmlich „beseitigt“1. Erst das erneute Fehlschlagen führt zu einem neuen Rücktrittsgrund, der allerdings für die Berechtigung zum Rücktritt eine erneute Frist benötigt. Wiederholt sich diese Abfolge mit hinreichendem Abstand, wird der Anwender im Zweifel immer besser beraten sein, vor der Rücktrittserklärung eine Frist zu setzen. Dies gilt, obwohl die Voraussetzungen für die Entbehrlichkeit der Fristsetzung nunmehr in § 323 Abs. 2 BGB geregelt sind. Kann sich der Anwender nicht auf eine eindeutige Erfüllungsverweigerung stützen, die auch durch Vorlage eines entsprechenden Schriftstücks nachweisbar ist, sollte er sich nicht darauf verlassen, dass in seinem konkreten Fall die Fristsetzung verzichtbar ist. Es ist nicht auszuschließen, dass ein Gericht die Voraussetzungen für die Entbehrlichkeit als nicht gegeben ansieht. bb) „Ablehnungsandrohung“ 362

§ 326 a.F. BGB enthielt als Rücktrittsvoraussetzung eine Fristsetzung mit Ablehnungsandrohung. Der Anwender musste mit seiner Fristsetzung auch unmissverständlich erklären, dass er weitere Leistungen nach erfolglosem Fristablauf ablehnt. Für den Softwareanbieter waren damit die Auswirkungen eines Fristablaufs wesentlich klarer. Es musste unmissverständlich zum Ausdruck kommen, dass ihm eine letzte Chance zur Erbringung der vertragsgemäßen Leistung eingeräumt wird. Die Rechtsprechung tendierte dazu, die Voraussetzungen des § 326 a.F. BGB sehr restriktiv anzuwenden; regelmäßig scheiterten Ansprüche auf Schadensersatz wegen Nichterfüllung an der fehlenden Ablehnungsandrohung. Der Gesetzgeber hat sich bei der Neufassung des Leistungsstörungsrechts bewusst dazu entschlossen, diesen Formalismus aufzugeben. Für Softwareanbieter ging dadurch ein Stück Sicherheit verloren. Jede Aufforderung zur Leistungserbringung kann den Anforderungen des § 323 Abs. 1 BGB genügen. Der Anwender muss keine besonderen Erklärungen mehr abgegeben, die auf die Folgen des Fristablaufs konkret hinweisen. Fristen, die einen Rücktritt auslösen, können in einer E-Mail an den Projektleiter stehen, der deren rechtliche Bedeutung möglicherweise nicht richtig einordnen kann. Dass die Wiedereinführung der Ablehnungsandrohung in AGB wegen einer Abweichung vom gesetzlichen Leitbild scheitert, dürfte unstreitig sein. In einer Individualvereinbarung wäre eine solche Regelung durchaus möglich und meist auch verhandelbar. Auch Anwender sehen die Notwendigkeit der Rechtssicherheit einer Erklärung von solcher Tragweite. Ebenfalls denkbar ist zumindest die Maßgabe, dass eine Fristsetzung, die einen Rücktritt auslösen kann und soll, schriftlich an die Geschäftsleitung zu richten ist. Damit ist der Gefahr

1 In diesem Zeitpunkt bereits entstandene Schadensersatzansprüche gemäß sollten hiervon jedenfalls dann unberührt bleiben, wenn sie sich der Anwender ausdrücklich vorbehält.

752

Witzel

Implementierung von Standardsoftware

Rz. 366 G

vorgebeugt, dass sich die den Rücktritt auslösende Kommunikation nur in den E-Mails der Projektleitung wiederfindet. d) Verzugsschäden Selbst wenn es nicht zum endgültigen Scheitern des Projekts kommt, kann ein Verzug für den Softwareanbieter erhebliche finanzielle Folgen auslösen. Die durch den Verzug entstandenen Schäden sind über §§ 280, 286 BGB zu ersetzen. In vielen Projekten, die aus einer Krise doch noch zum Erfolg führen, gehen die reinen Verzögerungsschäden unter, da die Vertragspartner in dem Wissen, dass sie noch mehrere Jahre zusammenarbeiten müssen, dieses Thema nicht weiterverfolgen. Darauf wird sich der Softwareanbieter allerdings nicht verlassen können.

363

4. Mangelhafte Leistungen bei Anpassung, Einführung und Implementierung von Standardsoftware: Sach- und Rechtsmängel und sonstige Schlechtleistung a) Vorbemerkung Wie oben ausgeführt, geht das Leistungsspektrum in Projekten zur Anpas- 364 sung, Einführung und Implementierung über die Lieferung und Leistung zur Anpassung von Standardsoftware hinaus. Geht es um mangelhafte Leistung1, ist folglich nicht allein auf Mängel der Software abzustellen, wobei es sich bei Scheitern eines Projekts im Wesentlichen auf die auftretenden Fehler2 der Software konzentrieren wird. Unterstellt, die angepasste Software ist im Wesentlichen mangelfrei und läuft auch produktiv ohne wesentliche Mängel, dürfte ein Scheitern eines Projekts höchst unwahrscheinlich sein. Nichtsdestoweniger sind Schlechtleistung und Qualitätsmängel nicht al- 365 lein auf die Software und deren Anpassungen beschränkt, auch hinsichtlich der übrigen Leistungen sind „Mängel“ denkbar. Die Vertragsgestaltung sollte dies berücksichtigen. b) Gleichstellung von Sach- und Rechtsmängeln im Kauf- und Werkvertragsrecht Die Schuldrechtsreform hat Sach- und Rechtsmängel bei Kauf- und Werk- 366 vertragsrecht gleichgestellt. Der Verkäufer bzw. der Werkunternehmer ist 1 Koch, Schuldrechtsmodernisierung – Auswirkungen auf das Gewährleistungsrecht bei IT-Verträgen, CR 2001, 569. 2 Mängel im Sinne der Sachmängelhaftung können, müssen aber nicht mit Fehlern im technischen Sinne identisch sein. Technische Eigenschaften sind nämlich nur dann relevant, wenn ein System in Folge der technischen Abweichung nicht mehr (voll) in der vereinbarten Weise genutzt werden kann oder das System teilweise seinen Wert verliert.

Witzel

753

G Rz. 367

Sonderregelungen

verpflichtet, Kaufgegenstand oder Werk frei von Sach- und Rechtsmängeln zu liefern. Mit den Formulierungen in § 435 BGB und § 633 BGB sind Rechtsmängel konsequent der „Gewährleistung“ zugeordnet, die wiederum wie bei Sachmängeln in das allgemeine Leistungsstörungsrecht eingeordnet ist. Diese Gleichstellung hat folgende Konsequenzen, die auch bei der vertraglichen Gestaltung ihre Berücksichtigung finden sollten: – Die Verjährung für Rechtsmängel wurde erheblich verkürzt: Es gilt nicht mehr die 30-jährige Verjährung, sondern eine Verjährung von zwei Jahren, beginnend mit Abnahme oder Ablieferung. Für viele Anwender ergibt sich hier Handlungsbedarf und es wird versucht, die Verjährungsfrist auf mindestens zehn Jahre zu verlängern. – Die Haftung für Rechtsmängel greift nunmehr verschuldensunabhängig, was die typischen Freistellungsvereinbarungen unter Umständen obsolet macht. c) Gesetzlicher Mangelbegriff im Kauf- und Werkvertragsrecht 367

Nicht nur die Gleichstellung von Sach- und Rechtsmängeln gilt im Kaufund Werkvertragsrecht, sondern auch der Mangelbegriff wurde für beide Vertragstypen gleich gestaltet, im Folgenden wird daher auf eine Unterscheidung verzichtet. aa) Vertraglich vereinbarte Beschaffenheit

368

Gemäß § 434 Abs. 1 Satz 1 BGB kommt es für die Sachmangelfreiheit in erster Linie darauf an, ob die verkaufte Sache die vereinbarte Beschaffenheit hat. Die geschuldete Sollbeschaffenheit richtet sich primär nach der Vereinbarung zwischen den Vertragspartnern, also der Leistungsbeschreibung. Das Gesetz stellt hierbei auf einen subjektiven Fehlerbegriff ab, der auf dem Willen der Parteien basiert und nicht nur auf objektive Eigenschaften. Die Beschaffenheit umfasst die körperlichen Merkmale einer Sache sowie die tatsächlichen, wirtschaftlichen, sozialen und rechtlichen Beziehungen der Sache zur Umwelt1. Eine „vereinbarte“ Beschaffenheit setzt zwei übereinstimmende Willenserklärungen voraus. bb) Vertraglich vorausgesetzte Verwendung

369

Nach § 434 Abs. 1 Satz 2 Nr. 1 BGB ist die Sache frei von Sachmängeln, wenn sie sich für die nach dem Vertrag vorausgesetzte Verwendung eignet. § 434 Abs. 2 Satz 1 Nr. 1 BGB soll nach der Gesetzesbegründung diejenigen Fälle umfassen, in denen sich die Vorstellungen der Vertragspartner nicht auf die einzelnen Merkmale der Beschaffenheit richten, sondern darauf, dass sich die Sache für einen bestimmten Verwendungszweck eignet. Der Unterschied zu Abs. 1 Satz 1 liegt darin, dass dort konkrete Beschaffenheits1 Huber/Faust, Schuldrechtsmodernisierung – Einführung in das neue Recht, S. 297, Rz. 26.

754

Witzel

Implementierung von Standardsoftware

Rz. 372 G

merkmale vereinbart werden, während nach Abs. 1 Satz 2 Nr. 1 gewissermaßen das Ergebnis vereinbart wird, nämlich die Zweckeignung. Die vertraglich vorausgesetzte Verwendung muss jeweils nach den Umständen des Einzelfalls festgestellt werden, da durch sie ein bestimmtes Anforderungsniveau festgelegt wird, das als subjektiv festgelegtes nicht notwendig dem jeweils neuesten und höchsten Stand der Technik entsprechen muss. Verschiedene Vertragsparteien können also bezüglich der gleichen Software unterschiedliche Gebrauchsweisen und damit auch unterschiedliche Mängelmaßstäbe vertraglich vereinbaren oder voraussetzen. Die Vertragspartner sollten demzufolge versuchen, sich auf eine gemeinsame Zwecksetzung zu verständigen. Eine Formulierung könnte so ausssehen:

Nach dem gemeinsamen Verständnis von Auftraggeber und Auftragnehmer ist es Ziel des Projekts, im Rahmen des IT-Gesamtbebauungsplans des Auftraggebers, eine (…)-Lösung zur fachlichen Abdeckung des gesamten derzeitigen Geschäfts des Auftraggebers zu realisieren. Gemeinsames Ziel von Auftraggeber und Auftragnehmer ist es weiterhin, die gegenwärtige Anzahl der beim Auftraggeber im Einsatz befindlichen Systeme und den Aufwand für den Betrieb zu verringern.

Als vertraglich vorausgesetzt gelten können nur die Vorstellungen des An- 370 wenders, die dieser gegenüber dem Softwareanbieter deutlich zum Ausdruck bringt1. Hier ist Vorsicht geboten, insbesondere hinsichtlich der Materialien, die Anlage zum Vertrag werden. Vor allem in Präambeln und Vorbemerkungen zum Vertrag sollte nicht pauschal auf Workshops und Gespräche Bezug genommen, sondern nur konkrete Dokumente referenziert werden, die auf mögliche Widersprüche geprüft werden müssen. cc) Gewöhnliche Verwendung § 434 Abs. 1 Satz 2 Nr. 2 BGB bringt hilfsweise objektive Kriterien zur An- 371 wendung: Die Kaufsache ist mangelfrei, wenn sie sich für die gewöhnliche Verwendung eignet und eine Beschaffenheit aufweist, die bei Sachen der gleichen Art üblich ist und die der Käufer nach Art der Sache erwarten kann. Entscheidend ist im Rahmen der gewöhnlichen Verwendungseignung das Bestehen einer Verkehrsauffassung zu dem, was als gewöhnliche (als praxisübliche) Verwendungsform geschuldet ist. Soweit der Anwender Standardsoftware erwirbt, kann er berechtigterweise nur für einen Massenmarkt ausgerichtete, d.h. typisierte Leistungsmerkmale erwarten2. Koch führt dazu aus, „dass ein Programm unabhängig von Vereinbarungen 372 in seinen zentralen Funktionen dem Stand der Technik entsprechen muss“ 1 OLG Köln v. 26.10.1990 – 19 U 28/90, CR 1991, 154 f. 2 Koch, Computervertragsrecht, Rz. 1322.

Witzel

755

G Rz. 373

Sonderregelungen

und nimmt dabei Bezug auf ein Urteil des LG Freiburg1. Technische Standards legen zumindest teilweise Merkmale der gewöhnlichen Verwendungseignung fest. Redeker2 wendet berechtigt ein, dass die Beurteilung nach einer Abweichung vom Stand der Technik immer erst voraussetzt, dass ein Stand der Technik überhaupt feststellbar ist. Dies muss, so Redeker, nicht immer der Fall sein. Schon aus diesen Ausführungen in der Literatur wird deutlich, dass die Beurteilung einer angepassten Software nach gewöhnlicher Verwendung und üblicher Beschaffenheit für die Vertragspartner erhebliche Risiken mit sich bringt. dd) Typische Softwaremängel 373

Die Ausführungen in der Literatur zu Softwaremängeln3 sind vielfältig, nachfolgend nur einige Beispiele: – Ein Finanzbuchhaltungsprogramm ist mangelhaft, wenn es nicht in der Lage ist, einen Scheckbetrag aus mehreren Rechnungen zusammenzusetzen4. – Ein Mangel eines Finanzbuchhaltungsprogramms liegt auch dann vor, wenn der Kontenrahmen nicht den Vorschriften des Bilanzrichtliniengesetzes entspricht5. – Fehlen vereinbarte Bildschirmmasken, liegt ein Mangel vor6. – Zeigt ein Lagerverwaltungssystem bei einer Suche nach Artikeln zwar den geforderten Artikel an, aber nicht die Artikelnummer und weist es auch Textfehler auf, ist dies ein Mangel7. d) Mögliche vertragliche Ausgestaltung des (Sach-)Mangelbegriffs aa) Bedeutung der Leistungsbeschreibung (Pflichtenheft)

374

Viele AGB von Softwareanbietern enthalten Formulierungen wie „Dem Kunden ist bekannt, dass Software nicht fehlerfrei sein kann“8. Unabhängig 1 Koch, Computervertragsrecht, Rz. 1320. 2 Redeker, IT-Recht in der Praxis, Rz. 325. 3 Darstellungen dazu finden sich bei Jäger u.a., Begutachtung und rechtliche Bewertung von EDV-Mängeln, S. 131; Koch, Computervertragsrecht, Teil 7, B. I. Rz. 49 ff.; Marly, Softwareüberlassungsverträge, S. 393 ff. 4 LG Bielefeld, Beilage 5 zu BB 1989, S. 6. 5 OLG-Hamm, NJW-RR 1995, 941. 6 OLG Schleswig v. 6.11.1981 – 11 U 117/80, MDR 1982, 228 = ZIP 1982, 457. 7 OLG Karlsruhe, in: Zahrnt, ECR OLG 78. 8 Die Auswirkungen eines Fehlers können enorm sein, wie eine Auflistung unter www.wikipedia.org zeigt: – 1962 führte ein fehlender Bindestrich in einem Fortran-Programm zum Verlust der Venus-Sonde Mariner 1, welche über 80 Millionen US-Dollar gekostet hatte. – Zwischen 1985 und 1987 gab es mehrere Unfälle mit dem medizinischen Bestrahlungsgerät Therac-25. Infolge einer Überdosis, die durch fehlerhafte Pro-

756

Witzel

Implementierung von Standardsoftware

Rz. 378 G

von der Frage, ob eine derartige Formulierung im Rahmen von AGB oder auch generell die Gewährleistung des Softwareanbieters beschränken kann, entbehren die Aussagen zur grundsätzlichen Fehlerhaftigkeit von Software nicht eines wahren Kerns. Nach Heussen1 wird Software auch dann, wenn Programmierfehler weit- 375 gehend vermieden werden können, sehr häufig einen Rest unvermeidbarer Fehler enthalten, bei denen man es nie ausschließen kann, dass sie unter bestimmten Anwendungsbedingungen virulent werden und Schäden verursachen. Dies gilt auch, wenn die Software vollkommen nach dem Stand der Technik entwickelt worden ist. Tatsache ist, dass bei einer erfolgreichen Zusammenarbeit der Vertragspart- 376 ner wohl in der Tat beide Seiten damit leben müssen, dass sich Fehler nie ganz ausmerzen lassen. Kommt es zu einer streitigen Auseinandersetzung, wird sich vor allem der Anwender darauf berufen, dass er Anspruch auf eine Software frei von Sachmängeln hat. Schwierigkeiten bereiten im Fall einer Schieflage im Projekt die Auffassungen beider Seiten zum „gewöhnlichen Gebrauch“ und zur „üblichen Beschaffenheit“. Um dazu Feststellungen zu treffen, wären objektive Kriterien aus ver- 377 gleichbaren Projekten erforderlich, die allgemein eingehalten werden und den Regeln der Technik entsprechen. Zurückgegriffen werden kann auf Normen und technische Regelwerke, wie DIN (www.din.de), CEN (www.ce norm.be), ISO (www.iso.org), die bei der Bestimmung von gewöhnlicher Beschaffenheit und üblicher Verwendung helfen können. Diese können jedoch nur Anhaltspunkte sein, so dass die Feststellung im konkreten Fall zu erheblichem Aufwand führen wird. Im Interesse beider Vertragspartner sollte es daher liegen, den Mangel- 378 begriff, wie er vom Gesetz vorgeschrieben ist, soweit wie möglich einzuschränken, sodass sich etwaige Mängel nur anhand der vereinbarten Beschaffenheit bestimmen lassen. Wie oben schon ausgeführt, kommt der Leistungsbeschreibung nach der Schuldrechtsreform eine erheblich höhere Bedeutung zu, was durch die Ausgestaltung des neuen Mangelbegriffs noch grammierung und fehlende Sicherungsmaßnahmen verursacht wurde, mussten Organe entfernt werden, ein Patient verstarb drei Wochen nach der Bestrahlung. – 1996 wurde der Prototyp der Ariane 5-Rakete der Europäischen Raumfahrtbehörde eine Minute nach dem Start zerstört, weil der Programmcode, der von der Ariane 4 übernommen wurde und nur für einen (von der Ariane 4 nicht überschreitbaren) Bereich funktionierte, die Steuersysteme zum Erliegen brachte, nachdem ebendieser Bereich von der Ariane 5 überschritten wurde. – 1999 verpasste die NASA-Sonde Climate Orbiter den Landeanflug auf den Mars, weil die Programmierer das falsche Maßsystem verwendeten – Yard statt Meter. Die NASA verlor dadurch die mehrere hundert Millionen Dollar teure Sonde. 1 Heussen, Unvermeidbare Softwarefehler, CR 2004, 1.

Witzel

757

G Rz. 379

Sonderregelungen

einmal verstärkt wird. Nach § 434 Abs. 1 BGB wird zuerst auf die vereinbarte Beschaffenheit abgestellt. Liegt also eine gute Anforderungsbeschreibung vor und werden die fachlichen Anforderungen des Anwenders im Verlauf des Projekts auch entsprechend feinspezifiziert, dürfte für die gewöhnliche Verwendung und übliche Beschaffenheit kaum mehr Raum bleiben. Auch der Vertragszweck, der für die Beurteilung der Mangelhaftigkeit eine Rolle spielen kann, lässt sich im Regelfall beschreiben. 379

Eine solche Formulierung könnte wie folgt aussehen1: Die Aufgaben des Lager- und Materialflusssystems sind – die platzgenaue Bestandsverwaltung im automatischen vier-gassigen Kleinteilelager, im manuellen Palettenhochregallager sowie in den manuellen Lagern Chemielager, Langgutlager, Sperrigteillager und Schnelldrehbereich, – die Steuerung aller Abläufe im Zusammenhang mit der Lagerhaltung und dem Materialfluss, – die Bereitstellung eines Informations- und Steuerungssystems, – die Kommunikation des Lagerverwaltungssystems mit dem Host-System und den Anlagensteuerungen, – die Serienbildung und Versandabwicklung.

380

Daneben kann es sinnvoll sein, den Mangelbegriff im Vertrag selbst zu beschränken, in etwa mit folgender Formulierung:

Ein Sachmangel liegt vor, wenn die Software – unter ordnungsgemäßer Nutzung seitens des Auftraggebers – nicht die vertraglich vereinbarte Beschaffenheit (siehe Leistungsbeschreibung Anhang B) aufweist oder nicht zu der bestimmungsgemäßen Verwendung geeignet ist, die durch die entsprechende Leistungsbeschreibung in Anhang B definiert ist.

bb) Lücken der Leistungsbeschreibung (Pflichtenheft) 381

Die Konsequenzen einer lückenhaften Leistungsbeschreibung sollten klar sein: Ist eine Beschaffenheit nicht vereinbart, greifen die weiteren Stufen des Mangelbegriffs: Auch hier wird auf gewöhnliche Verwendung und übliche Beschaffenheit abzustellen sein; dies dann mit den unter Ziff. 3.1 beschriebenen Risiken für beide Vertragspartner.

1 Das Beispiel und weitere Anregungen für die Beschreibung des Vertragszwecks finden sich in Jungebluth, Das ERP-Pflichtenheft, 4. Aufl. 2008, S. 294.

758

Witzel

Implementierung von Standardsoftware

Rz. 383 G

e) Mängelanzeige des Kunden, Anwendbarkeit von § 381 Abs. 2 HGB aa) Untersuchungs- und Rügepflicht Bei Verträgen über die Anpassung, Einführung und Implementierung von 382 Standardsoftware werden in der Regel auf beiden Seiten Kaufleute stehen, so dass über die Anwendung von § 381 Abs. 2 HGB grundsätzlich zu diskutieren ist. Auch hier ist danach zu unterscheiden, ob man die Anwendung von Werkvertragsrecht bejaht oder der Auffassung zu § 651 BGB folgt. Beim reinen Werkvertragsrecht kommt die Rügeobliegenheit nicht zur Anwendung. Es wird aber die Auffassung vertreten, dass die Interessenlage ähnlich ist, so dass zumindest eine analoge Anwendung der Rügeverpflichtung gerechtfertigt ist. Der Untersuchungs- und Rügepflicht kann insbesondere vor folgendem Hintergrund Bedeutung zukommen: Die lange Projektlaufzeit wird auch dazu führen, dass der Anwender Leistungsergebnisse – beispielsweise Add-ons – erhält, lange bevor die anzupassende und zu implementierende Software in den Produktivbetrieb geht. Dennoch sollte der Anwender prüfen (müssen), ob die gelieferten Leistungsergebnisse im Wesentlichen den Vereinbarungen zwischen den Vertragspartnern entsprechen: Sind beispielsweise die vereinbarten Bildschirmmasken mit allen Eingabefeldern versehen oder ist die vereinbarte Bildqualität von Abbildungen eingehalten? bb) Mängelanzeige Losgelöst von der Untersuchungs- und Rügepflicht ist die Verpflichtung zur 383 Mängelanzeige. Vor Durchführung der Nacherfüllung müssen dem Softwareanbieter die aufgetretenen Mängel erst einmal angezeigt werden. Wie eine Mängelanzeige aussehen muss, ist nicht unstreitig. Es genügt allerdings nicht, wenn der Anwender pauschal das Vorhandensein von Mängeln rügt. Das Erscheinungsbild des Mangels wird darzulegen sein, wobei es wiederum vom Einzelfall abhängt, welche Erscheinungen wie genau dargelegt werden können. Fehlen bestimmte Funktionalitäten, reicht es schlicht aus, deren Fehlen zu rügen. Bei Abstürzen oder Fehlfunktionen sind detailliertere Angaben notwendig, damit geprüft werden kann, was für ein Fehler vorliegt. Es ist allerdings nicht Aufgabe des Anwenders, Ursachenforschung zu betreiben und zu überprüfen, aus welchen Gründen die gelieferte Anlage oder das gelieferte Programm nicht funktionieren1. Bei der Vertragsgestaltung hilft es zum einen, den Anwender zu einer Mängelanzeige zu verpflichten, zum anderen auch, ihm Formulare für die Mängelanzeige vorzugeben, aus denen sich ergibt, welche Angaben der Softwareanbieter konkret benötigt.

1 Redeker, IT-Recht in der Praxis, Rz. 356 m.w.N.

Witzel

759

G Rz. 384 384

Sonderregelungen

Ein Formulierungsvorschlag wäre folgender: Mängel hat der Auftraggeber unverzüglich nach ihrer Entdeckung dem Auftragnehmer schriftlich mitzuteilen. Die Mängelanzeige ist mit einer konkreten schriftlichen Mängelbeschreibung zu verbinden. Der Auftraggeber stellt dem Auftragnehmer außerdem die für die Nacherfüllung erforderlichen Unterlagen zur Einsichtnahme oder auf Anforderung zur Verfügung. Benötigt der Auftragnehmer weitere Unterlagen, hat der Auftraggeber diese Unterlagen auf Anforderung ebenfalls unverzüglich zur Verfügung zu stellen.

f) Verjährung von Mängelansprüchen 385

Aus Sicht des Softwareanbieters ist die Verjährung von Mängelansprüchen vor allem im Hinblick auf die Vergütungspflicht der Pflege von Bedeutung1. Auch insoweit birgt die Schuldrechtsmodernisierung erhebliche Unwägbarkeiten:

386

Mängelansprüche verjähren beim Kauf gemäß § 438 BGB bei dinglichen oder sonstigen im Grundbuch eingetragenen Rechten in 30 Jahren, bei Bauwerken in fünf Jahren und im Übrigen in zwei Jahren. Nach § 438 Abs. 2 BGB beginnt die Verjährung bei Grundstücken mit der Übergabe, sonst mit Ablieferung der Sache.

387

Beim Werkvertrag richtet sich die Verjährung nach § 634a BGB, der wie folgt differenziert: – Bei einem Werk, dessen Erfolg in der Herstellung, Wartung oder Veränderung einer Sache oder in der Erbringung von Planungs- und Überwachungsleistungen besteht, verjähren Mängelansprüche in zwei Jahren. – Bei einem Bauwerk oder einem Werk, dessen Erbringung von Überwachungs- und Planungsleistungen hierfür besteht, verjähren Mängelansprüche in fünf Jahren, – Im Übrigen verjähren Ansprüche in der regelmäßigen Verjährungsfrist, also in drei Jahren.

388

Hier zeigt sich eine der gravierenden Folgen der Entscheidung gegen § 651 BGB und für das Werkvertragsrecht mit der Begründung „Software ist keine Sache“: Es liegt kein Sonderfall vor, sodass die regelmäßige Verjährungsfrist greift. Sie beträgt nach § 195 BGB drei Jahre und beginnt mit dem Ende des Jahres, in dem der Anspruch entstanden ist und der Gläubiger von den den Anspruch begründenden Umständen und der Person des Schuldners Kenntnis erlangt hat oder ohne grobe Fahrlässigkeit Kenntnis erlangen musste, 1 Bartsch, Softwarepflege nach neuem Schuldrecht, NJW 2002, 1526; Runte, Vergütung für Softwarepflege bei laufender Gewährleistung, ITRB 2003, 253; Schneider, Schuldrechtsmodernisierung und Vergütung bei Pflegeverträgen, ITRB 2001, 243; Schneider, Risikobereiche des Pflegevertrags, CR 2004, 241.

760

Witzel

Implementierung von Standardsoftware

Rz. 392 G

längstens zehn Jahre nach ihrer Entstehung. Folgt man der Auffassung, dass über § 651 BGB Kaufrecht zur Anwendung kommt, beträgt die Verjährungsfrist zwei Jahre ab Ablieferung. Mängelansprüche wegen verborgener Mängel verjähren in der Regel drei 389 Jahre ab Ende des Jahres der Aufdeckung des Mangels und wohl spätestens zehn Jahre nach Abnahme – gegenüber der nach altem Schuldrecht geltenden Verjährung eine gravierende Änderung, besonders für den Softwareanbieter im Hinblick auf die Abgrenzung zwischen Pflege und „Gewährleistung“. Einziger Ausweg für die Vertragspartner ist die vertragliche Regelung des Verjährungsbeginns, konkret abgestimmt auf die individuellen Bedürfnisse und Anforderungen des Projekts.

390

g) Rechtsfolgen von Mängeln aa) Überblick Grundnorm für die Rechtsbehelfe des Anwenders1 ist die Vorschrift des § 437 BGB beim Kauf.

391

Der Anwender kann – nach § 439 BGB Nacherfüllung verlangen, – nach den §§ 440, 323 und 326 Abs. 5 BGB vom Vertrag zurücktreten oder nach § 441 BGB den Kaufpreis mindern und – nach den §§ 440, 280, 281, 283 und 311a BGB Schadensersatz oder nach § 284 Ersatz vergeblicher Aufwendungen verlangen. bb) Nacherfüllung Nach den Änderungen der Schuldrechtsreform erhält der Verkäufer also ei- 391a ne zweite Chance, ordentlich zu erfüllen. Erreicht wird dies im Wesentlichen mit dem Instrument der Nachfristsetzung, die allerdings keine Ablehnungsandrohung mehr voraussetzt. Dieses praktische Instrument sollte über eine vertragliche Regelung allerdings wieder zurückkehren: Der Anwender sollte sich genau überlegen, ob eine Frist Sekundäransprüche auslösen soll, für den Softwareanbieter sollte demgegenüber klar sein, dass die gesetzte Frist seine letzte Chance ist. Die Nacherfüllung kann grundsätzlich durch Mängelbeseitigung oder Neu- 392 lieferung erfolgen. Der BGH hat sich in einer Entscheidung vom 2.9.2010 näher mit den Pflichten des Auftragnehmers zur Mängelbeseitigung und -untersuchung auseinandergesetzt. Nach Auffassung des BGH darf das Recht des Auftraggebers, eine Mängelbeseitigung zu verlangen, nicht dadurch eingeschränkt werden, dass die Verantwortlichkeit des Auftragneh1 Lorenz, Rücktritt, Minderung und Schadensersatz wegen Sachmängeln im neuen Kaufrecht: Was hat der Verkäufer zu vertreten?, NJW 2004, 3020.

Witzel

761

G Rz. 393

Sonderregelungen

mers im Zeitpunkt der Inanspruchnahme noch nicht geklärt ist. Der Auftragnehmer dürfe die Mängelbeseitigung nicht davon abhängig machen, dass der Auftraggeber ihm gegenüber eine Erklärung abgebe, wonach der die Kosten der Untersuchung und weiterer Maßnahmen für den Fall übernehme, dass der Auftragnehmer nicht für den Mangel verantwortlich sei1. cc) Rücktritt 393

Der Rücktritt setzt gemäß §§ 437 Nr. 2, 323 BGB grundsätzlich voraus, dass der Käufer dem Verkäufer eine angemessene Frist zur Nacherfüllung gesetzt hat. Erst wenn diese erfolglos abgelaufen ist, kann der Käufer zurücktreten. Entsprechendes gilt für die Minderung und für den Schadensersatz, wenn er an die Stelle der vom Verkäufer geschuldeten Leistung treten soll.

0.1 Bei während der Verjährungsfrist vom Auftraggeber angezeigten Mängeln hat der Auftragnehmer kostenlos nachzuerfüllen. Der Auftragnehmer hat gegebenenfalls auch die Dokumentation zu berichtigen. Stellt sich heraus, dass ein vom Auftraggeber angezeigter Mangel tatsächlich nicht besteht oder weist der Auftragnehmer nach, dass die Mangelursache nicht seiner Leistung anhaftet, kann der Auftragnehmer die Erstattung des Aufwands für die auf Grund der Nacherfüllung erbrachten Leistungen nach den diesem Vertrag zugrundegelegten Vergütungssätzen verlangen, soweit nichts anderes vereinbart wird. 0.2 Soweit dies möglich und im Hinblick auf die Auswirkungen des Mangels angemessen ist, wird der Auftragnehmer bis zur endgültigen Behebung des Mangels eine Zwischenlösung zur Umgehung des Mangels bereitstellen. 0.3 Werden Mängel vom Auftragnehmer nicht binnen für den jeweiligen Mangel angemessener Zeit behoben oder durch eine angemessene Zwischenlösung aufgefangen, kann der Auftraggeber dem Auftragnehmer eine angemessene Nachfrist mit der Erklärung setzen, dass er die Nacherfüllung nach dem Ablauf dieser Frist ablehne. Nach ergebnislosem Fristablauf kann der Auftraggeber nach seiner Wahl – die Mängel auf Kosten des Auftragnehmers selbst beseitigen, wenn nicht der Auftragnehmer die Nacherfüllung zu Recht verweigert, – die Herabsetzung der für die jeweilige Leistung vereinbarten Vergütung verlangen, – bei erheblichen Mängeln hinsichtlich der betroffenen Leistung vom Vertrag zurücktreten, – und bei Verschulden des Auftragnehmers Schadensersatz oder Ersatz seiner vergeblichen Aufwendungen verlangen.

1 BGH v. 2.9.2010 – VII ZR 110/09, CR 2011, 92.

762

Witzel

Implementierung von Standardsoftware

Rz. 398 G

h) Schadensersatz statt der Leistung Im Rahmen des § 281 BGB soll hier der Hinweis auf einen besonderen Scha- 394 denstyp erfolgen, der den Softwareanbietern – bei einer Haftung ohne individuelle Beschränkung – erhebliche finanzielle Einbußen zufügen kann: Zum ersatzfähigen Schaden gehören grundsätzlich auch die Mehrkosten für die Beschaffung eines Ersatzsystems. i) Besonderheiten bei Rechtsmängeln aa) Vorliegen eines Rechtsmangels Der Softwareanbieter ist nach § 633 Abs. 3 BGB verpflichtet, die Software 395 frei von Rechten zu verschaffen, die ein Dritter gegen den Anwender geltend machen könnte. Ein Rechtsmangel1 liegt somit vor, wenn der vertraglich vereinbarte Gebrauch der Software auf Grund eines vorrangigen Rechts eines Dritten nicht in vollem Umfang gewährleistet ist. Der Fall, dass das vertraglich geschuldete Recht insgesamt nicht verschafft werden kann, und damit kein Rechtsmangel, sondern ein Fall der Unmöglichkeit gem. § 311a BGB vorliegt, soll an dieser Stelle nicht behandelt werden. bb) Unterschiedliche Interessenlage im Verhältnis zum Sachmangel Bei Vorliegen eines Sachmangels weicht die Ist-Beschaffenheit der Software in der Weise von der Soll-Beschaffenheit ab, dass die Funktionalität beeinträchtigt ist. Bei einem Rechtsmangel dagegen ist die Funktionstauglichkeit in vollem Umfang gegeben, allein das Recht zur Nutzung ist eingeschränkt. Vor diesem Hintergrund ergeben sich nicht nur unterschiedliche Interessen auf Anbieter- und Anwenderseite, sondern auch Abweichungen im Vergleich zwischen Sachmängel- und Rechtsmängelhaftung.

396

Der Anwender hat im Fall der Geltendmachung einer Schutzrechtsverlet- 397 zung durch einen Dritten das Interesse, das vom Anbieter vertraglich geschuldete Nutzungsrecht in vollem Umfang und schnellstmöglich eingeräumt zu bekommen. Der Softwareanbieter wird ein solches Problem mit möglichst niedrigem Kostenaufwand und bezogen auf seinen gesamten Geschäftsbetrieb, also nicht nur auf einen Anwender, lösen wollen. Die gesetzlichen Regelungen zum Rechtsmangel sind im Kauf- und Werk- 398 vertragsrecht mit Ausnahme von zwei Unterschieden gleich. Das Werkvertragsrecht gewährt dem Anwender unter bestimmten Voraussetzungen ein Recht zur Selbstvornahme nebst Anspruch auf Ersatz der dabei entstandenen notwendigen Aufwendungen. Entgegen dem Kaufrecht steht das Recht

1 Bartsch, Rechtsmängelhaftung bei der Überlassung von Software, CR 2005, 1; Roth, Rechtsmängelhaftung – Vertragsgestaltung nach neuerem Recht, ITRB 2003, 231; Redeker, Rechtsmängel – Voraussetzungen, Garantien und Rechtsfolgen, ITRB 2004, 84.

Witzel

763

G Rz. 399

Sonderregelungen

zur Wahl des Mittels der Nacherfüllung im Werkvertragsrecht dem Anbieter zu. 399

Der Anwender wird aufgrund seiner Sachnähe und der möglichen Auswirkungen eines Rechtsmangels auf seinen gesamten Geschäftsbetrieb ein Interesse am Recht zur Wahl des Mittels zur Nacherfüllung haben. Da ihm dies im Rahmen des Werkvertragsrechts gesetzlich nicht zusteht, kann es angezeigt sein, dies vertraglich zu vereinbaren. Aus demselben Grund wird der Softwareanbieter im Vergleich zum Sachmangel ein noch größeres Interesse an einer unverzüglichen Unterrichtung haben. Weiterhin kann die Möglichkeit zur Mängelbeseitigung durch eine von der geschuldeten Leistung abweichende Leistung im Rahmen eines Rechtsmangels für den Softwareanbieter von noch größerem Interesse sein als bei einem Sachmangel. Die Beseitigung liegt hier nämlich nicht allein in seiner Macht, vielmehr ist er in besonderem Maße von dem Dritten abhängig. Insofern kann es angezeigt sein, dieses Recht vertraglich zu vereinbaren.

400

Für den Fall, dass der Dritte seinen Anspruch gegenüber dem Anwender geltend macht, wird der Anbieter ein Interesse daran haben, die Sache entweder selbst lenken und entscheiden zu können oder zumindest von seiner Zustimmung abhängig zu machen.

401

Da der Anwender eine in vollem Umfang funktionstaugliche Software besitzt, wird sein primäres Interesse in der Regel auf die Einräumung des geschuldeten Rechtes gerichtet sein, Minderung oder Rückabwicklung sind von nachrangigem Interesse. Der Anwender wird also, insbesondere für den Fall, dass der Anbieter dem nicht gerecht wird, die Möglichkeit haben wollen, sich das Recht selbst zu verschaffen, sowie dadurch entstandene Aufwendungen ersetzt verlangen zu können. Da das Recht zur Selbstvornahme im Kaufrecht nicht vorgesehen ist, kann es für den Anwender angezeigt sein, dies vertraglich zu vereinbaren.

402

Darüber hinaus könnte der Anspruch auf Ersatz der notwendigen Aufwendungen zu eng sein bzw. die Beweislast des Anwenders über die Notwendigkeit unangemessen sein, so dass auch diesbezüglich eine vertragliche Regelung angezeigt sein kann. cc) Formulierungsvorschläge

403

Nachfolgend werden einige Formulierungsvorschläge zur vertraglichen Regelung der vorgenannten Interessen dargestellt.

404

Aus Softwareanbietersicht die Einräumung des Rechts zur Wahl hinsichtlich der Nacherfüllungsart:

764

Witzel

Implementierung von Standardsoftware

Rz. 404 G

Der Anbieter ist berechtigt, die Nacherfüllung nach seiner Wahl durch Nachbesserung oder Neulieferung zu erledigen.

Einräumung des Rechts zur Lieferung geänderter Software im Rahmen der Nacherfüllung:

Die Nachbesserung kann der Anbieter nach seiner Wahl wie folgt vornehmen: – Verschaffung und Einräumung des für die vertraglich geschuldete Nutzung notwendigen Rechts oder – die Software so ändern oder ersetzen, dass sie dem vereinbarten Funktions- und Leistungsumfang entspricht, oder zumindest nur unwesentlich und in einer für den Anwender zumutbaren Weise abweicht.

Denkbar ist auch eine Haftungsbegrenzung durch Freistellungspflicht beschränkt auf den Fall, dass der Softwareanbieter den Rechtsmangel zu vertreten hat. Es ist aber fraglich, ob der Anwender das akzeptiert und ob es interessengerecht ist, denn der Anwender hat im Gegensatz zum Anbieter überhaupt keine Möglichkeit der Prüfung oder Einflussnahme; der Softwareanbieter kann dieses Risiko darüber hinaus wirtschaftlich über den Preis kalkulieren. Eine Haftungsbegrenzung durch Festlegung der Pflicht des Anwenders zur umgehenden Meldung geltend gemachter Ansprüche:

Macht ein Dritter die Verletzung von Schutzrechten durch die Verwendung der Software gegenüber dem Anwender geltend, wird der Anwender den Anbieter darüber unverzüglich informieren.

Die Einräumung der Pflicht, den Rechtsstreit in Abstimmung mit dem Anbieter zu führen oder sogar Einräumung der Möglichkeit, ihn gänzlich selbst zu führen:

Der Anwender wird die behauptete Verletzung weder anerkennen noch die Auseinandersetzung über die behauptete Verletzung führen, ohne sich mit dem Anbieter vorher abzustimmen.

oder

Witzel

765

G Rz. 405

Sonderregelungen

Der Anwender wird soweit als möglich dem Anbieter die Verteidigung gegen ihm gegenüber geltend gemachten Ansprüchen überlassen und dem Anbieter jegliche mögliche und zumutbare Unterstützung gewähren. Der Anwender wird insbesondere keinen von einem Dritten ihm gegenüber geltend gemachten Anspruch ohne vorherige schriftliche Zustimmung des Anbieters anerkennen.

405

Aus Anwendersicht ist Folgendes denkbar: Vereinbarung einer erweiterten Haftung durch Freistellung von allen Ansprüchen Dritter (das Risiko der Berechtigung wird dabei auf den Softwareanbieter verschoben):

Der Anbieter gewährleistet, dass die vertraglich vereinbarte Nutzung der überlassenen Software nicht durch Rechte Dritter beschränkt ist und stellt den Anwender von allen Ansprüchen Dritter frei.

Einräumung des Rechtes zur Selbstvornahme: Der Anbieter wird unverzüglich geeignete Schritte zur Abwehr der geltend gemachten Ansprüche ergreifen. Soweit diese für den Anwender nicht ausreichend sind oder nicht schnell genug greifen, ist er berechtigt, seinerseits die nötigen Schritte vorzunehmen.

j) Sonstige Schlechtleistung 406

Auch wenn sich in der Praxis viel auf die Mängel der Software konzentrieren kann, bleibt im Rahmen eines Projekts Raum für „anderweitige Schlechtleistung“ des Softwareanbieters: – Nicht-Einhaltung vereinbarter Qualitätssicherungsmaßnahmen (daraus werden im Regelfall Mängel der Software oder deren Anpassungen resultieren); – Unzureichende oder völlig fehlende Projektdokumentation; – Wiederholter Austausch von Projektleitung und Projektteam; – Bereitstellung von Mitarbeitern ohne ausreichendes Know-how (Berufsanfänger ohne praktische Erfahrung, Mitarbeiter ohne Branchenkenntnisse oder ohne Erfahrungen in vergleichbaren Projekten); – Unzureichende Schulungsunterlagen.

406a Nicht alle der Leistungen, die solch „schlechten Leistungsergebnissen“ zu Grunde liegen, werden unter das Kauf- oder Werkvertragsrecht fallen, sodass die Regelungen zu Sach- und Rechtsmängeln nur begrenzt greifen.

766

Witzel

Implementierung von Standardsoftware

Rz. 409 G

Leistungsstörungen werden also nach § 280 BGB beurteilt. Der Anwender hat bei nachweisbarer Pflichtverletzung und nachweisbar entstandenem Schaden einen Schadensersatzanspruch, wobei das Verschulden zu Lasten des Softwareanbieters vermutet wird. Insoweit stellt sich im Rahmen eines Projekts über Anpassung, Einführung und Implementierung die Frage, ob bei Schlechtleistung tatsächlich nach den unterschiedlichen Leistungen unterschieden werden soll oder ob im Sinne des angestrebten einheitlichen Projekterfolgs auch eine einheitliche Lösung für die mangelhafte Leistung angestrebt werden sollte. Es ist beispielsweise denkbar, dass der Softwareanbieter losgelöst von der vertraglichen Zuordnung der Leistung nacherfüllen muss:

Der Auftragnehmer wird bei sämtlichen unter diesem Vertrag nicht ordnungsgemäß erbrachten Leistungen innerhalb einer angemessenen Frist unentgeltlich nacherfüllen. Der Auftraggeber ist nicht zur Geltendmachung von Schadensersatzansprüchen berechtigt bevor die Frist zur Nacherfüllung ergebnislos verstrichen oder die Nacherfüllung endgültig fehlgeschlagen ist.

5. Sonstige Vertragsgestaltung bei Leistungsstörungen, insbesondere Haftungsbegrenzungen a) Vorbemerkung Die Frage, ob und inwieweit der Softwareanbieter berechtigt ist, seine auf 407 Schadensersatz zielende Haftung wirksam zu beschränken, hat eine erhebliche praktische Bedeutung. Die Risiken, die sich aus einer Pflichtverletzung und den daraus resultierenden Folgen ergeben, dürften für die meisten Softwareanbieter von existenzieller Bedeutung sein. Für viele mittelständische Anbieter dürfte bei Scheitern eines größeren Projekts und sich daraus ergebenden Rückzahlungs- und Schadensersatzverpflichtungen sowie den Kosten für eine gerichtliche Auseinandersetzung die Insolvenz drohen. Bei der Vertragsgestaltung werden sich die Vertragspartner demzufolge über mögliche Haftungsausschlüsse und Haftungsbegrenzungen Gedanken machen1. Ein Haftungsausschluss zeichnet sich dadurch aus, dass er den Anspruchsgrund betrifft und die Entstehung des Anspruchs verhindert, wie beispielsweise die Abbedingung bestimmter Ansprüche oder der Ausschluss der Haftung für bestimmte Pflichten, Schuldarten oder Personen.

408

Die Haftungsbegrenzung lässt dagegen den Anspruch entstehen, beschränkt aber den Umfang der Haftung. Beispiele hierfür sind summenmäßige Haf-

409

1 Auer-Reinsdorff, Haftungsregelungen für Folgeschäden in IT-Projekten, ITRB 2006, 181; Hörl, Haftungsklauseln in IT-Verträgen, ITRB 2005, 217; Hörl, Typische Haftungsklauseln in IT-Verträgen, ITRB 2006, 17; s. auch Graf von Westphalen/Meier-Göring, Neues Schuldrecht, S. 19 ff.

Witzel

767

G Rz. 410

Sonderregelungen

tungsbeschränkungen, Haftungsbegrenzungen auf Personen- oder Sachschäden, Regelungen zur Abbedingung der Haftung für entgangenen Gewinn und Zinsen sowie für nicht vorhersehbare Schäden und Mangelfolgeschäden. 410

Gegenstand von Haftungsausschluss und Haftungsbegrenzungsklauseln können Schadensersatzansprüche jeglicher Art sein. Sie können die Haftung für Personenschäden betreffen, die Haftung für Sachmängel, die Haftung für Schutzrechtsverletzungen und sonstige Rechtsmängel sowie die Haftung für sonstige Schäden (insbesondere reine Vermögensschäden). b) Haftungsbeschränkungen in AGB

411

Es dürfte unstreitig sein, dass Haftungsbeschränkungen in AGB1 bis auf enge Ausnahmen unwirksam sind. Vor allem Softwareanbieter mit anglo-amerikanischem oder angelsächsischem Hintergrund sind die Restriktionen des deutschen AGB-Rechts und die Rechtsprechung des BGH kaum verständlich zu machen2. Das Schema von Intveen3 fasst die begrenzten Möglichkeiten transparent zusammen: Vorsatz/grobe Fahrlässigkeit Grundsätzlich ist eine Haftungsfreizeichnung oder -begrenzung bei Vorsatz und grober Fahrlässigkeit in AGB auch im kaufmännischen/unternehmerischen Verkehr unwirksam. Einfache Fahrlässigkeit Eine Haftungsfreizeichnung bei einfacher/leichter Fahrlässigkeit ist ebenso unzulässig, wenn es um den Haftungsausschluss bei vertragswesentlichen Pflichten (Kardinalpflichten) geht. Kardinalpflichten Bei Verletzung von vertragswesentlichen Pflichten ist eine Haftungsbegrenzung zulässig, wenn hierdurch vertragstypische und vorhersehbare Schäden abgedeckt werden. Eine zutreffende summenmäßige Bezifferung wird dabei wohl selten gelingen. 1 Hörl, Haftungsklauseln in IT-Verträgen, ITRB 2005, 217; Hörl, Typische Haftungsklauseln in IT-Verträgen – Regelungsgegenstände und Hinweise zur Vertragsgestaltung, ITRB 2006, 17; Intveen, Haftungsklauseln in Allgemeinen Geschäftsbedingungen im kaufmännischen/unternehmerischen Verkehr, ITRB 2002, 295; Intveen, Weitere Einzelheiten zu Haftungsklauseln in Allgemeinen Geschäftsbedingungen im kaufmännischen/unternehmerischen Verkehr, ITRB 2003, 13 ff.; Intveen, Die Rechtsprechung des BGB zu Haftungsregelungen in AGB, ITRB 2007, 144; Prätorius, Schadensersatz vertraglich ausgeschlossen und trotzdem in der Haftung? Vorsicht bei der Formulierung von Vertragsklauseln, BC 2012, 127. 2 Kollmann, AGB – Nicht nur theoretische Probleme in der Praxis, NJOZ 2011, 625. 3 Intveen, ITRB 2002, 295 (297).

768

Witzel

Implementierung von Standardsoftware

Rz. 413 G

Konsequenz Eine völlige Haftungsfreizeichnung ist nur in Fällen einfacher/leichter Fahrlässigkeit, und zwar dann in Zusammenhang von nicht-vertragswesentlichen Pflichten, wirksam möglich. Die Möglichkeiten der Haftungsbeschränkung bei Verletzung von sog. Kar- 412 dinalpflichten hat der BGH1 noch einmal erschwert, indem er die Auffassung vertreten hat, dass der Begriff als solcher für den juristischen Laien nicht verständlich und damit nicht transparent ist. Der Verwender der AGB muss nach Auffassung des BGH eine Erläuterung des Begriffs einfügen, um die Klausel wirksam zu gestalten:

Bei der Verletzung solcher Vertragspflichten des Auftragnehmers, deren Erfüllung die ordnungsgemäße Durchführung des Vertrages überhaupt erst ermöglicht, deren Verletzung die Erreichung des Vertrages gefährdet und auf deren Einhaltung der Auftraggeber regelmäßig vertraut, haftet der Auftragnehmer, wenn keiner der in Ziffern 0.1 bis 0.3 genannten Fälle gegeben ist, der Höhe nach begrenzt auf den vertragstypisch vorhersehbaren Schaden.

Es ist zu bezweifeln, dass eine solche Erläuterung, die auf der Entscheidung 413 des BGH beruht, für einen juristischen Laien wesentlich nachvollziehbarer ist, als das Schlagwort der Kardinalpflichten. Der Vertragspartner muss in jedem Fall Vermutungen über die Bedeutung der Formulierungen anstellen. Gleiches gilt für die vertragstypisch vorhersehbaren Schäden. Was darunter fällt und was nicht, bleibt auslegungsbedürftig. Beim PKW-Kauf hat der BGH nahezu alle Schadenspositionen als typisch und vorhersehbar eingestuft2. Bei Projekten zur Anpassung, Einführung und Implementierung von Standardsoftware werden folgende Schäden typischerweise auftreten: – Interner (Mehr-)Aufwand (Personalkosten) beim Anwender durch fehlgeschlagene Tests und Abnahmeprüfungen; – zusätzliche Personalkosten in Folge verzögerter Einführung (bei rechtzeitiger Einführung hätte früher Personal abgebaut werden können); 1 BGH v. 20.7.2005 – VIII ZR 121/04, NJW 2006, 46: „Von einem durchschnittlichen Vertragshändler als juristischem Laien kann nicht erwartet werden, dass er den Inhalt der BGH-Rechtsprechung zu den so genannten „Kardinalpflichten“ kennt. Ihm erschließt sich deshalb ohne nähere Erläuterung auch bei aufmerksamer und sorgfältiger Lektüre des Vertrags nicht, was mit „Kardinalpflichten“ gemeint ist. Möglich, aber auch ausreichend ist eine abstrakte Erläuterung des Begriffs der Kardinalpflicht, wie sie von der Rechtsprechung definiert wird, ohne dass die für den Typus des Vertragshändlervertrags wesentlichen Vertragspflichten, bei deren Verletzung der Vertragszweck gefährdet ist, abschließend aufgezählt werden müssten.“ 2 BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2001, 292: Entgangene Nutzung, entgangener Gewinn, Abschleppkosten, Wertminderung von Inhalt und Ladung.

Witzel

769

G Rz. 414

Sonderregelungen

– weitere Lizenz- und/oder Pflegekosten für Altsysteme, die wegen einer verzögerten Einführung nicht termingerecht abgelöst werden konnten; – Aufwand für die Suche nach Mängelursachen und Unterstützung bei der Mängelbehebung, ggf. auch durch Zuziehung Dritter; – Sachverständigenkosten, etwa zur Erstellung eines Privatgutachtens; – Kosten für die Beweissicherung (etwa ein Parallelbetrieb der IT-Infrastruktur, bis ein gerichtliches Verfahren zum Abschluss gebracht ist); – Mehrkosten für ein Deckungsgeschäft; – Kosten für überflüssig gewordene Drittsoftware oder vergeblich angeschaffte Hardware; – Produktionsausfall bei produktionssteuernden Systemen; – Kosten für externe Berater im Projektmanagement. 414

Der Nachweis wird im Einzelfall schwer zu führen sein. Insbesondere die internen Personalkosten lassen sich häufig nur schätzen, weil die Mitarbeiter die Zeiten nicht oder nur rudimentär erfassen. Dass derartige Schäden typischerweise vorkommen, liegt jedoch auf der Hand. Gerade bei Projekten, die lange notleidend sind, bevor es zum endgültigen Bruch kommt, können sich erhebliche Summen ergeben, die auf den Softwareanbieter neben der Rückzahlung der Vergütung in Folge eines Rücktritts zukommen. c) Haftungsbeschränkungen in individuellen Vereinbarungen

415

Das gesetzliche Haftungsregime kann wesentlich verändert werden, wenn die Haftungsklausel im Einzelnen ausgehandelt wird1. Auch für individuelle Haftungsregelungen ergeben sich Grenzen2, die jedoch wesentlich weiter sind als die in AGB: Grundsätzlich gilt, dass Haftungsausschlüsse und Haftungsbegrenzungen bei Vorsatz gemäß § 276 Abs. 3 BGB unwirksam sind. Das gilt für alle Beschränkungen, so auch für eine Erleichterung der Verjährung3. Ebenfalls kein Unterschied zwischen AGB und Individualabrede ergibt sich aus §§ 444, 639 BGB. Soweit eine Garantie für die Beschaffenheit einer Sache/eines Werks gegeben wird, kann sich der Verkäufer/Unternehmer nicht mit Erfolg auf eine Freizeichnung von der Haftung berufen. In diesen Fällen muss die Schadensersatzhaftung nach §§ 280 ff. BGB uneingeschränkt erhalten bleiben. Auch § 14 ProdHaftG enthält eine zwingende Verbotsnorm. Die Haftung für Personen- und Sachschäden, die auf einen Produktfehler zurückzuführen sind, ist zwingend.

416

Im Übrigen sind die Vertragspartner in ihrer Gestaltung frei, es kommt also auf Verhandlungsgeschick und die Durchsetzbarkeit gegenüber dem Vertragspartner an. Folgende Formulierungen sind denkbar: 1 S. dazu allerdings Rz. 407 ff. 2 Die Beschränkungen, die sich durch die §§ 474 ff. BGB für den Verbrauchsgüterkauf ergeben, bleiben hier außen vor. 3 Erman/Westermann, § 276 BGB Rz. 28.

770

Witzel

Implementierung von Standardsoftware

Rz. 417 G

0.1 Der Auftragnehmer haftet unbegrenzt bei Vorsatz und bei Übernahme einer Garantie. 0.2 Gleich aus welchem Rechtsgrund haftet der Auftragnehmer bei grober Fahrlässigkeit beschränkt auf (…) Euro pro Schadensfall, maximal auf (…) Euro. Bei leichter Fahrlässigkeit ist die Haftung des Auftragnehmers ausgeschlossen. 0.3 Die Haftung für mittelbare Schäden, insbesondere Betriebsausfallschäden, Mehrkosten eines Deckungsgeschäfts und entgangener Gewinn, ist ausgeschlossen. 0.4 Ist ein Schaden sowohl auf Verschulden des Auftragnehmers als auch auf ein Verschulden des Auftraggebers zurückzuführen, muss sich der Auftraggeber sein Mitverschulden anrechnen lassen. Der Auftraggeber ist zur regelmäßigen Sicherung seiner Daten verpflichtet. Bei einem vom Auftraggeber verschuldeten Datenverlust haftet der Auftragnehmer deshalb ausschließlich für die Kosten der Vervielfältigung der Daten von den vom Auftraggeber zu erstellenden Sicherheitskopien und die Rekonstruktion der Daten, die auch bei Erstellung von Sicherheitskopien in angemessenen Abständen verlorengegangen wären. 0.5 Die Haftung nach dem Produkthaftungsgesetz bleibt unberührt. 0.6 Sämtliche Schadensersatzansprüche verjähren zwölf Monate nach Entstehung des Anspruchs. Dies gilt nicht im Falle des Vorsatzes, der Arglist oder einer Garantie.

oder Sofern ein Schaden auf leichte Fahrlässigkeit seitens des Auftragnehmers zurückzuführen ist, gilt Folgendes: – Die Haftung bei leicht fahrlässiger Verletzung einer wesentlichen Vertragspflicht ist begrenzt auf 50 000 Euro pro Schadensfall, es sei denn die leicht fahrlässige Verletzung einer wesentlichen Vertragspflicht führt zum Scheitern des Projekts und der Auftraggeber ist zur Geltendmachung von Schadensersatz statt der Leistung (§ 281 BGB) berechtigt. In einem solchen Fall ist die Haftung des Auftragnehmers begrenzt auf 2 000 000 Euro. – Bei leicht fahrlässiger Verletzung von unwesentlichen Vertragspflichten ist die Haftung des Auftragnehmers ausgeschlossen.

Die Vertragspartner sollten sich jedoch darüber im Klaren sein, dass die Anforderungen der Rechtsprechung an ausgehandelte Klauseln hoch sind. Ausgehandelt sind Klauseln nur dann, wenn der Verwender den Inhalt einer Vertragsbedingung ausdrücklich zur Disposition stellt und der Vertragspartner die Möglichkeit hat, eigene Formulierungs- und Gestaltungsvorschläge

Witzel

771

417

G Rz. 418

Sonderregelungen

einzubringen1. Für ein Aushandeln im Regelfall nicht ausreichend werden Diskussionen und Gespräche über die Vertragsbedingungen sein, vor allem dann, wenn die vom Verwender vorgeschlagenen Bedingungen unverändert bleiben. Es hilft auch nicht, dass der Vertragspartner sich pauschal mit den AGB einverstanden erklärt. Die Abgabe einer solchen Erklärung führt nicht zu ausgehandelten Vertragsbedingungen. Es wird folglich notwendig sein, dass der Vertragspartner, der sich auf einen ausgehandelten Vertrag beruft, die diskutierten Vertragsentwürfe mit nachgewiesenen Änderungen präsentieren muss. Der Dokumentation und Archivierung von Vertragsentwürfen wird daher erhebliche Bedeutung zukommen.

XII. Beendigung des Anpassungs-, Einführungs- und Implementierungsprojekts, insbesondere nach § 649 BGB 1. Beendigungstatbestände 418

Neben dem Rücktritt, den eine Leistungsstörung nach sich zieht, kommen noch andere Beendigungstatbestände in Betracht, nämlich die ordentliche sowie die außerordentliche Kündigung. Kommt man zur Anwendung des Werkvertragsrechts für Verträge zur Anpassung, Einführung und Implementierung von Standardsoftware, gilt zudem § 649 BGB. Die Kündigungsrechte spielen durchaus eine Rolle, da auch andere Überlegungen auf Seiten des Anwenders, ein Projekt zu beenden, ins Spiel kommen können. Durch Änderungen in der Gesellschaftsstruktur eines Anwenders kann es dazu kommen, dass ein Projekt nicht fortgesetzt werden soll. Der neue Mehrheitsgesellschafter hat bspw. bereits ein anderes ERP-System im Einsatz und möchte im Konzern eine einheitliche Softwarelösung. Demzufolge hat er an der Fortsetzung eines Projekts kein Interesse mehr. a) Rücktritt

419

Aus Sicht des Softwareanbieters ist der Rücktritt2 der „worst case“. Auf ihn kommt die Rückzahlung bereits erhaltener Vergütung zu, die bei einem Scheitern im späten Stadium eines Projekts einen erheblichen Betrag ausmachen kann. Tritt ein Auftraggeber zurück, wird er es auch nicht bei der Geltendmachung von Rückzahlungsansprüchen bewenden lassen; es kommen Schadensersatzforderungen aus §§ 281, 280 BGB hinzu. Hat der Anwender das Projekt und den ihm entstandenen Aufwand und die Kosten gut dokumentiert, können schnell sechs- bis siebenstellige Beträge zusammenkommen. Liegen die Rücktrittsvoraussetzungen dem Grunde nach vor, ist die Höhe der Rückforderung in fast allen Fällen unstreitig. Der Nachweis,

1 BGH v. 23.1.2003 – VII ZR 210/01, NJW 2003, 1805. 2 Schuster, Haftung, Aufwendungsersatz und Rückabwicklung bei IT-Verträgen, CR 2011, 215.

772

Witzel

Implementierung von Standardsoftware

Rz. 421 G

in welcher Höhe Vergütung bezahlt wurde, lässt sich anhand der gestellten Rechnungen führen. Interessant wird es allerdings dann, wenn der Anwender Teile der erbrach- 420 ten Leistungen (produktiv) nutzt und sich die aus dieser Nutzung entstandenen wirtschaftlichen Vorteile anrechnen lassen muss. Leistungen aus der Konzeptionierungsphase lassen sich ggf. generell weiter verwenden, dann wenn ein Pflichtenheft nicht spezifisch auf eine bestimmte Standardsoftware zugeschnitten ist, sondern wenn im Vordergrund fachliche Konzepte oder Use Cases stehen, die die Anforderungen des Anwenders losgelöst von der konkreten Software so beschreiben, dass sie auch als Ausgangsbasis für ein anderes Projekt eingesetzt werden können. Von erheblichem Vorteil für einen Softwareanbieter bei einer etwaigen Rückabwicklung sind bereits produktiv genutzte Funktionsbereiche der anzupassenden und einzuführenden Software. Ist beispielsweise Gegenstand eines Projekts die Anpassung, Einführung und Implementierung einer Lösung für das Rechnungswesen und für die Materialwirtschaft und nutzt der Anwender das Rechnungswesen bereits geraume Zeit zur Abwicklung seines operativen Geschäfts zu dem Zeitpunkt, in dem die Einführung der Materialwirtschaft scheitert, muss bei der Berechnung der Rückforderung die produktive Nutzung des Rechnungswesens berücksichtigt werden. Hinzu kommt Folgendes: Ein Rücktritt wird generell immer unwahrscheinlicher, je mehr ein Anwender produktiv nutzt. Die Rückkehr auf das Altsystem ist nur für einen kurzen Zeitraum möglich. Der Anreiz, ein Projekt auch in einer schwierigen Phase doch noch erfolgreich zu Ende zu bringen, ist umso größer, wenn schon ein Teilbereich im Einsatz ist. Softwareanbieter sind also gut beraten, wenn sie eine Einführung und Implementierung in Teilbereiche aufteilen und dafür sorgen, dass einzelne Geschäfts- oder Funktionsbereiche zeitig mit der produktiven Nutzung beginnen. b) Ordentliche Kündigung beim Werkvertrag Das Werkvertragsrecht gesteht dem Softwareanbieter kein Recht zur or- 421 dentlichen Kündigung zu. Im Hinblick auf die Erfolgsorientierung des Vertrags ist dies auch nachvollziehbar; es soll dem Softwareanbieter schließlich nicht ermöglicht werden, sich der Erbringung des geschuldeten Erfolgs dadurch zu entziehen, dass er den Vertrag ordentlich kündigt. Der Anwender hat dagegen nach § 649 BGB ein Kündigungsrecht, ohne dass es eines wichtigen Grundes bedarf. Allerdings behält in diesem Fall der Softwareanbieter seinen Vergütungsanspruch1. Er muss sich aber das anrechnen lassen, was er durch die Aufhebung des Vertrags an Aufwendungen erspart

1 Bartsch, Softwarerechte bei Projekt- und Pflegeverträgen, CR 2012, 141; Intveen, BGH v. 28.7.2011 – VII ZR 45/11, Urt. m. Anm., Vergütungsanspruch nach Kündigung eines Internetsystemvertrags, ITRB 2012, 4; Redeker, Der Entschädigungsanspruch des IT-Unternehmers gemäß § 649 BGB, ITRB 2012, 42.

Witzel

773

G Rz. 422

Sonderregelungen

oder durch anderweitige Verwendung seiner Arbeitskraft erwirbt oder zu erwerben böswillig unterlässt. 422

§ 649 Satz 3 BGB enthält die Vermutung, dass die Restentschädigung 5 % beträgt. Nach dem Gesetzestext ist nicht der Softwareanbieter, sondern der Besteller für die ersparten Aufwendungen beweisbelastet, weil die ersparten Aufwendungen ein Abzugsposten von einem an sich gegebenen Vergütungsanspruch sind. Das Problem des Anwenders wird allerdings darin liegen, dass er zu den ersparten Aufwendungen nichts vortragen kann, da er die Kalkulation des Softwareanbieters nicht kennt. Diese Darlegungslast hat der BGH in einer Reihe von Entscheidungen umgekehrt1. Es liegt am Unternehmer, seine Kalkulation und die Ersparnisse darzulegen. Will er seinen Anspruch aus § 649 Satz 2 BGB geltend machen, muss er in konkreten Projekten detaillierte Daten über die Kosten seiner Mitarbeiter und eventuell (wegen des anderweitigen Einsatzes von Arbeitskraft) sogar die aus anderen Projekten erzielten Erlöse angeben. Dieses Problem versuchte der Gesetzgeber mit der Ergänzung des § 649 BGB zu lösen. Nach § 649 Satz 3 BGB wird in Verträgen, die nach dem 1.1.20092 abgeschlossen worden sind, vermutet, dass dem Unternehmer, wenn er nichts anders darlegt, 5 % der auf den noch nicht erbrachten Teil der Werkleistungen entfallenden vereinbarten Vergütung zustehen. Der ersparte Aufwand wird damit auf 95 % geschätzt. Dem Unternehmer soll mit dieser Vermutung die Darlegungslast für die ersparten Aufwendungen abgenommen werden.

423

Redeker3 kritisiert die neue gesetzliche Regelung in zutreffender Weise. Die Pauschalierung führt nicht zu einer Erleichterung, sondern zu einer Erschwernis. Will ein Softwarehaus mehr als die pauschalierten Aufwendungen verlangen, muss er konkret für das Projekt darlegen, wie hoch die ersparten Aufwendungen und ein eventuell vorhandener anderweitiger Erlös sind. Um dieser Darlegungslast nachzukommen, müsste es zum einen eigene Betriebsgeheimnisse (nämlich seine interne Kostenstruktur) offenlegen, zum anderen ggf. auch geheimhaltungsbedürftige Tatsachen offenbaren, nämlich die mit Projekten anderer Kunden erzielten Erlöse. Beides wird sich ein Auftragnehmer gut überlegen. Um diesem Dilemma zu entgehen, bleibt nur die entsprechende Vertragsgestaltung, die nach dem BGH auch in AGB möglich ist. Eine vertragliche Regelung muss nur den Anforderungen nach §§ 308 Nr. 7a und 309 Nr. 5b BGB gerecht werden, d.h. dem Kunden muss der Nachweis geringerer geschuldeter Vergütung, höherer ersparter Aufwendungen oder anderweitigen Erwerbs offen bleiben4. 1 BGH v. 21.12.1995 – VII ZR 198/94, BGHZ 131, 362; BGH v. 14.1.1999 – VII ZR 277/97, BB 1999, 926. 2 Art. 229 § 19 Abs. 1 EGBGB. 3 Redeker, Der Entschädigungsanspruch des IT-Unternehmers gemäß § 649 BGB, ITRB 2012, 42. 4 § 649 Satz 3 BGB hat keine Leitbildfunktion, weil die Norm nicht den Schaden des Unternehmers abbilden, sondern nur eine Beweiserleichterung bewirken soll, BGH v. 5.5.2011 – VII ZR 161/10, CR 2011, 639.

774

Witzel

Implementierung von Standardsoftware

Rz. 425 G

Ein Formulierungsvorschlag für eine individuelle Vereinbarung lautet wie 424 folgt:

0.1 Ordentliche Kündigung („Ausstiegsklausel“) 0.1.1 Der Auftraggeber hat das Recht und die Möglichkeit ohne Angabe von Gründen aus einzelnen, bereits begonnenen Projektphasen auszusteigen, ohne dass dafür ein Rücktrittsrecht oder ein Recht zur außerordentlichen Kündigung vorliegen muss. 0.1.2 Ein solcher Ausstieg hat die hier beschriebenen Kostenfolgen für den Auftraggeber (Ausstiegspauschale). 0.1.3 Die für die Überlassung der Standardsoftware zu zahlende Vergütung mindert sich wie folgt: Der Auftraggeber muss nur die Vergütung für diejenigen Softwaremodule bezahlen, die in den Projektphasen vor dem Ausstieg bereits produktiv gesetzt wurden und vom Auftraggeber produktiv genutzt werden. Dies gilt bis zum Abschluss der Projektphase 3. Mit Beginn der Projektphase 4 ist bei einem Ausstieg des Auftraggebers die gesamte Vergütung für die Überlassung der Standardsoftware zu bezahlen. 0.1.4 Der Auftraggeber muss ferner sämtliche bis zum Ausstieg erbrachte Projektleistungen nach tatsächlichem Aufwand auf Basis des vereinbarten Tagessatzes bezahlen. 0.1.5 Des Weiteren wird eine Ausstiegspauschale fällig, die sich bei einem Ausstieg vor geplantem Beginn der nächsten Projektphase je nach Ausstiegszeitraum und bereits erfolgten Vorbereitungsarbeiten als Prozentbetrag des geplanten Gesamtaufwands für die nächste Projektphase wie folgt berechnet: – Ausstieg bis zu 4 Wochen vor Beginn der nächsten Projektphase: 10 % – Ausstieg bis zu 2 Wochen vor Beginn der nächsten Projektphase: 15 % – Ausstieg bis zum Beginn der nächsten Projektphase: 20 %

c) Ordentliche Kündigung beim Dienstvertrag Ist ein Projekt zur Anpassung, Einführung und Implementierung als Dienst- 425 vertrag gestaltet, kann auf die Regelungen des §§ 620, 621 BGB zur ordentlichen Kündigung zurückgegriffen werden. Es entspricht dem Wesen des Dienstvertrags, dass er von beiden Vertragspartnern mit an der Vergütung bemessenen Kündigungsfristen ordentlich gekündigt werden kann. Ein solcher Rückgriff wird allerdings eher die Ausnahme sein, da die Vertragspartner typischerweise Regelungen dazu treffen werden.

Witzel

775

G Rz. 426

Sonderregelungen

d) Außerordentliche Kündigung 426

Wenn für die Durchführung eines Werks eine längere Zeit notwendig ist – was beim komplexen Projekt regelmäßig der Fall sein wird –, wird auch ein Kündigungsrecht aus wichtigem Grund gewährt1. § 314 BGB setzt neben einem wichtigem Grund aus voraus, dass die Fortsetzung des Vertragsverhältnisses für die Vertragspartner nicht mehr zumutbar ist. Auf ein Verschulden soll es dabei grundsätzlich nicht ankommen. Auch eigenes Verschulden schließt das Kündigungsrecht nicht aus2.

427

Im Gegensatz zu dem in diesen Fällen meist auch gegebenen Rücktrittsrecht wird der Vertrag durch die außerordentliche Kündigung nur mit Wirkung für die Zukunft beendet. Dies bedeutet, dass die erbrachten Leistungen beim Anwender verbleiben, dieser die erbrachten Leistungen allerdings auch vergüten muss. Eine solche Vergütungspflicht setzt allerdings voraus, dass die erbrachten Leistungen (im Wesentlichen) mangelfrei sind.

428

Gerade bei einer werkvertraglichen Gestaltung eines Projektvertrags, die für den Softwareanbieter keine Ausstiegsmöglichkeiten vorsieht, ist eine Kündigung nach § 314 BGB meist der einzige Ausweg neben einer einvernehmlichen Aufhebung des Vertrags, zu der ein Anwender ohne Kompensation kaum bereit sein wird. Bei einem notleidenden Projekt finden sich sicher viele wichtige Gründe, dieses zu beenden. Allerdings werden diese wichtigen Gründe häufig identisch mit einer schlechten Leistung sein oder mit einer solchen in unmittelbarem Zusammenhang stehen. Wurde die Schlechtleistung vom Softwareanbieter selbst (überwiegend) verursacht, dürfte es schwierig sein, damit einen wichtigen Grund für die außerordentliche Kündigung zu rechtfertigen, obwohl das Verschulden bei § 314 BGB zunächst keine Rolle spielt. Häufig ist in notleidenden Projekten das wechselseitige Vertrauen so belastet, dass eine Fortsetzung der Zusammenarbeit in der Tat unzumutbar erscheint. Bei einem Dauerschuldverhältnis, das eine intensive vertrauensvolle Zusammenarbeit erfordert, kann ein wichtiger Grund zur außerordentlichen Kündigung dann vorliegen, wenn die persönliche Zusammenarbeit schwerwiegend gestört und eine Normalisierung nicht zu erwarten ist. Ist die Vertrauensgrundlage zerstört, kann das Kündigungsrecht auch dem zustehen, der sich selbst vertragswidrig verhalten hat3. Dennoch dürfte es schwierig sein, eine Kündigung mit § 314 BGB zu rechtfertigen, wenn sich keine Kündigungsgründe finden, die in anderen Bereichen liegen als der Verletzung von Leistungspflichten. Muss sich der Softwareanbieter Verzug und/oder Schlechtleistung vorwerfen lassen und ist dadurch das Vertrauen in seine Leistungsfähigkeit erheblich erschüttert

1 Redeker, IT-Recht in der Praxis, Rz. 450 m.w.N. Zur außerordentlichen Kündigung eines Softwarelizenzvertrags bei Vertragsbruch, s. LG Köln v. 14.9.2011 – 28 O 485/05, CR 2012, 77. 2 Beck’scher Online Kommentar, § 314 Rz. 8 m.w.N. 3 Beck’scher Online Kommentar, § 314 Rz. 12 m.w.N.

776

Witzel

Implementierung von Standardsoftware

Rz. 432 G

worden, wird er diesen Sachverhalt nur in Ausnahmefällen zur Begründung einer Kündigung aus wichtigem Grund heranziehen können. Ob eine Kündigung aus wichtigem Grund bei Nichtvorliegen eines wichti- 429 gen Grunds als Kündigung nach § 649 BGB zu behandeln ist, ist streitig. Die Rechtsprechung kommt allerdings meist zu diesem Ergebnis1. Das Werkvertragsrecht sieht keine regelmäßige ordentliche Kündigung zu einem bestimmten Zeitpunkt vor. Ist der Projektvertrag eher dienstvertraglich gestaltet, kommen die §§ 620 ff. BGB zur Anwendung.

430

e) Sonderkündigungsrechte Neben den Regelungen zur ordentlichen und außerordentlichen Kündigung 431 kommt die Vereinbarung von Sonderkündigungsrechten2 bei bestimmten Ereignissen in Betracht, die zwar keinen wichtigen Grund im Sinne von § 314 BGB darstellen, aber bei deren Eintritt die Vertragspartner das Projekt dennoch beenden wollen. Häufig finden sich Sonderkündigungsrechte für den Fall des „Change of Control“. Eine „Change of Control“-Klausel knüpft an die (personelle) Veränderung in der juristischen Person eines Vertragspartners Rechte des anderen Vertragspartners, im Regelfall ein Kündigungsrecht. Veränderungen der Gesellschafterverhältnisse bei einem Vertragspartner können bei Dauerschuldverhältnissen eine große Bedeutung haben. Das Vertrauen in einen Vertragspartner ist häufig auch an eine bestimmte Personenkonstellation im Management geknüpft. Ändern sich die handelnden Personen, kann es im Einzelfall auch notwendig sein, das Projekt zu hinterfragen. Eine vertragliche Regelung mit klarer Zuweisung der Kosten kann und soll eine Projektbeendigung erleichtern. Generell können Sonderkündigungsrechte eine vertragliche Ausgestaltung des § 313 BGB sein. Bestimmte Umstände, denen die Vertragspartner besondere Bedeutung beimessen, etwa die Umsetzung einer Umstrukturierung im Konzern des Anwenders, die den Einsatz einer neuen Software erforderlich macht, oder auch eine erwartete gesetzliche Änderung, für deren Inkrafttreten eine bestimmte Software benötigt wird, können Regelungen notwendig machen, die durch die gesetzlichen Bestimmungen allein nicht abgedeckt sind. Eine Formulierung könnte wie folgt aussehen:

432

Mit dem Erwerb der in Ziffer 1 beschriebenen Software will der Auftraggeber die gesetzlichen Anforderungen erfüllen, die sich aus dem Gesetz/der Richtlinie/dem Abkommen über … ergeben. Im Zeitpunkt der Unterzeichnung dieses Vertrags steht nicht abschließend fest, ob die geplanten gesetzlichen Anforderungen überhaupt umgesetzt werden. Im Falle der Nichtumsetzung des 1 Redeker, IT-Recht in der Praxis, Rz. 452 m.w.N. 2 Söbbing befasst sich mit diesem Thema in MAC-Klauseln in IT-Verträgen, ITRB 2008, 257.

Witzel

777

G Rz. 433

Sonderregelungen

Gesetzes/der Richtlinie/des Abkommens benötigt der Auftraggeber die in Ziffer 1 beschriebene Software nicht. Bis das Gesetz/die Richtlinie/das Abkommen mit einem Inkrafttreten nicht später als … ratifiziert wurde, hat der Auftraggeber das Recht, diesen Vertrag unter Einhaltung einer Kündigungsfrist von 14 Tagen zu kündigen und es besteht keine Verpflichtung zur Zahlung der Vergütung für die Softwareüberlassung gemäß Ziffer 1 bzw. einen Anspruch auf Rückzahlung der bereits geleisteten Vergütung für die gemäß Ziffer 3. Der Auftraggeber vergütet allerdings die bis zum Ablauf der Kündigungsfrist erbrachten Projektleistungen auf Basis der Festlegungen in Ziffer 4.

2. Gestaltungsmöglichkeiten zur Kündigung 433

Es empfiehlt sich, in der Vertragsgestaltung die Kündigungsmöglichkeiten und die Rechtsfolgen der Kündigungen ausführlich zu regeln, eventuell nach Projektfortschritten auch Teilkündigungsrechte vorzusehen. Auf die Anwendung von § 649 BGB kann verzichtet oder die Konsequenzen hinsichtlich der Vergütung modifiziert werden. In AGB wird ein Ausschluss der Rechte des § 649 BGB allerdings nicht gelingen. Der BGH lässt einen solchen Ausschluss nur zu, wenn ein berechtigtes, über die Realisierung des Vergütungsanspruchs hinausgehendes Interesse des Anbieters erkennbar ist, das durch die freie Kündigung des Vertrages in einer Weise beeinträchtigt würde, die dem Anbieter nicht zugemutet werden könne1. Auch in AGB kann die Vermutung des § 649 Satz 3 BGB modifiziert werden.

434

Die individuellen Gestaltungsmöglichkeiten sind vielfältig, folgende Formulierungen sind denkbar:

0.1 Ein Kündigungsrecht des Auftraggebers aus § 649 BGB ist ausgeschlossen. 0.2 Beiden Vertragspartnern bleibt ein Recht zur Kündigung aus wichtigem Grund, § 314 BGB, unbenommen. Die Dauer einer angemessenen Fristsetzung zur Abhilfe hängt von der Art der Pflichtverletzung ab und muss eine konkrete Abhilfe, ggf. unter Hinzuziehung von Dritten, möglich machen. § 323 Abs. 2 BGB findet entsprechende Anwendung.

Eine ausführliche Formulierung zur Kündigung kann wie folgt aussehen:

1 BGH v. 24.3.2011 – VII ZR 133/10, MMR 2011, 311.

778

Witzel

Implementierung von Standardsoftware

Rz. 434 G

0.1 Ordentliche Kündigung Der Auftraggeber ist zur ordentlichen Kündigung des Projektvertrags gemäß § 649 BGB mit einer Frist von zwei Wochen zum Ende des Kalendermonats berechtigt. Im Falle einer solchen Kündigung ist der Auftraggeber verpflichtet, die bis zum Wirksamwerden der Kündigung erbrachten Leistungen zu bezahlen, die vom Auftragnehmer auf Basis des vereinbarten Tagessatzes in Rechnung gestellt werden. § 649 Satz 2 und Satz 3 BGB kommen nicht zur Anwendung. 0.2 Sonderkündigungsrecht Beide Vertragspartner haben zum Ende der Analyse- und Design-Phase ein Sonderkündigungsrecht, das vor Beginn der Implementationsphase ohne Grund mit einer Frist von zwei Wochen ausgeübt werden kann. Übt der Auftraggeber sein Sonderkündigungsrecht aus, ist er verpflichtet, die bis zum Wirksamwerden der Kündigung erbrachten Leistungen zu bezahlen, die auf Basis des vereinbarten Tagessatzes in Rechnung gestellt werden. Übt der Auftragnehmer sein Sonderkündigungsrecht aus, wird die zu zahlende Vergütung um 30 % reduziert. 0.3 Außerordentliche Kündigung aus wichtigem Grund Beide Vertragspartner sind zur außerordentlichen Kündigung aus wichtigem Grund berechtigt. Ein wichtiger Grund liegt insbesondere vor, wenn – einer der Vertragspartner wesentliche Verpflichtungen unter diesem Projektvertrag verletzt und durch diese Vertragsverletzung die Rechte und Pflichten des anderen Vertragspartners wesentlich beeinträchtigt werden; – einer der Vertragspartner mit einer Zahlung über einen Zeitraum von mehr als zwei Monaten in Verzug ist; – ein nicht nur geringfügiger Verstoß gegen Datenschutz- und Vertraulichkeitsbestimmungen vorliegt. Eine außerordentliche Kündigung aus wichtigem Grund darf in der Regel nur erfolgen, wenn dem anderen Vertragspartner vor Ausspruch der Kündigung eine angemessene Frist zur Abhilfe gesetzt wurde und diese Frist erfolglos verstrichen ist. Einer Frist zur Abhilfe bedarf es dann nicht, wenn – der vertragsverletzende Vertragspartner eine vereinbarte Leistung ernsthaft und endgültig verweigert oder – besondere Umstände vorliegen, die unter Abwägung der beiderseitigen Interessen die sofortige, außerordentliche Kündigung rechtfertigen oder – ein Eskalationsverfahren bezüglich einer wesentlichen Meinungsverschiedenheit im Sinne der Ziffern 0.0 erfolglos blieb. Soweit einem Vertragspartner das Recht zur außerordentlichen Kündigung aus wichtigem Grund zusteht, kann dieser Vertragspartner die Kündigung nur binnen einer Frist von vier Wochen, nachdem er Kenntnis von den zur Kündigung berechtigenden Umständen erlangt hat, aussprechen. Berechtigt erst die Gesamtbetrachtung von Ereignissen einen Vertragspartner zur Witzel

779

G Rz. 435

Sonderregelungen

Kündigung aus wichtigem Grund, so ist die vorstehende Frist ab dem letzten dieser Ereignisse zu berechnen. Im Falle einer außerordentlichen Kündigung, die auf einem vom Kunden ausschließlich zu vertretenden wichtigem Grund beruht, hat der Auftragnehmer Anspruch auf Zahlung der bis zum Wirksamwerden der Kündigung erbrachten Leistungen auf Basis des vereinbarten Tagessatzes. 0.4 Schriftformerfordernis Jede Kündigung bedarf der Schriftform.

3. Pflichten nach Vertragsbeendigung a) Unterstützungsleistungen („Termination Assistance“) 435

Das Thema der Beendigungsunterstützung wird seltener in Zusammenhang mit Verträgen über die Anpassung, Einführung und Implementierung von Standardsoftware oder generell Softwareprojekten als im Bereich des Outsourcing diskutiert1. Die Notwendigkeit liegt beim Outsourcing auf der Hand: Wird ein solches Outsourcing-Verhältnis nach mehreren Jahren beendet und soll die Leistungserbringung wieder in die Organisation des Anwenders eingegliedert werden oder soll ein neuer Anbieter die Leistungserbringung übernehmen, ist der Anwender auf die Unterstützung durch den bisherigen Anbieter angewiesen. Viele Outsourcing-Verträge treffen bereits Regelungen für den Fall der Beendigung, so dass die inhaltliche, zeitliche und finanzielle Dimension der Beendigungsunterstützung bereits vor Beginn der Auslagerung transparent ist. Kernbereich einer solchen Regelung zur Beendigungsunterstützung ist die Verpflichtung des Anbieters, alles zu unternehmen, was für einen geordneten Übergang der vertragsgegenständlichen Leistungen auf den Anwender oder auf einen Dritten notwendig ist. Im Einzelfall können solche Leistungen zur Beendigungsunterstützung jedoch auch außerhalb des Outsourcings eine Rolle spielen. Projekte, die die Einführung und Implementierung von Standardsoftware wie SAP, Microsoft, Oracle zum Gegenstand haben, können nicht nur von einem Vertragspartner geführt werden. Generell gilt dies für Standardsoftware, deren Hersteller ein etabliertes System an Implementierungs- und Entwicklungspartnern aufgebaut haben. Wird ein Projekt notleidend, das grundsätzlich auch von einem anderen Anbieter fortgesetzt werden kann, und will der Anwender – trotz eines Projekts in der Schieflage – weiter auf die einmal gewählte Standardsoftware setzen, wird er im Fall einer Beendigung der Vertragsbeziehung mit einem Anbieter ggf. auch dessen Unterstützung benötigen, wenn er das Projekt mit einem neuen Anbieter fortsetzen will. Bei 1 Blöse/Pechardscheck, Die rechtliche Absicherung von IT-Outsourcing-Projekten, CR 2002. 785; Heymann Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 5.4; Hörl, Klauselgestaltung bei IT-Outsourcing-Verträgen nach der InvMARisk, ITRB 2010, 793.

780

Witzel

Implementierung von Standardsoftware

Rz. 436 G

allen Projekten, in denen nicht nur ein Vertragspartner für die Leistungserbringung in Betracht kommt, wird es sich anbieten, das Thema Beendigungsunterstützung im Vertrag zu regeln, wenngleich die Formulierungen nicht so ausführlich sein müssen wie im typischen Outsourcing-Vertrag. b) Datenmigration, Datenherausgabe Ein Sonderthema der Beendigungsunterstützung spielt vor allem bei Projek- 436 ten eine Rolle, in denen sukzessive Teilbereiche der einzuführenden und zu implementierenden Standardsoftware produktiv gesetzt werden und sich die produktive Nutzung dann bereits über längere Zeit erstreckt bevor der Vertrag beendet wird. Durch die produktive Nutzung verändert sich der Datenbestand in den Systemen ständig. Es kommen neue Daten hinzu, alte werden gelöscht oder verändert. Wird kein Parallelbetrieb mit dem alten System durchgeführt, der einen identischen Datenbestand gewährleistet, ist der Anwender darauf angewiesen, dass die Daten im Fall eines Systemwechsels auch wieder migriert werden. Bei dieser Migration wird er auf die Kooperation seines Softwareanbieters angewiesen sein, der wiederum nur widerwillig kooperieren mag, da der Vertrag mit ihm – ggf. wegen nicht in seiner Sphäre liegender Gründe – beendet wurde. Um sich für einen solchen Fall die Kooperationsbereitschaft zu sichern und auch angemessene Konditionen festzulegen, bietet sich die Vereinbarung der Rahmenbedingungen zu Beginn des Projekts an. Festlegen sollten die Vertragspartner nicht nur etwaige Unterstützungsleistungen bei der Migration, sondern auch die Verpflichtung zur Datenherausgabe selbst. Es muss dem Anwender ohne größere technische Schwierigkeiten möglich sein, auf seine Daten zuzugreifen, insbesondere dürfen Datenbanken nicht etwa passwortgeschützt sein.

Witzel

781

H. Projektmanagement Rz. I. Grundbegriffe des Projektmanagements. . . . . . . . . . . . . . . . . . . 1. Bedeutung des Projektmanagements . . . . . . . . . . . . . . . . . . . . . . . a) Projektmanagement als zentraler Erfolgsfaktor . . . . . . b) Spannungsverhältnis Projektmanagement und juristische Projektsteuerung . . . . c) Typische Problemfelder und Konsequenzen für erfolgreiche IT-Projekte . . . . . . . . . . . . 2. Begriffe und Definitionen . . . . . 3. Standards und Normen . . . . . . . a) ProjektmanagementMethoden . . . . . . . . . . . . . . . . . b) Aspekte von PRINCE2 als Beispiel für eine Projektmanagement-Methode . . . . . . . . c) Projektmanagement-Software . . . . . . . . . . . . . . . . . . . . . .

1 1 1

5

7 8 11 11

14 19

II. Rechtliche Grundsätze zur Projektverantwortung . . . . . . . . 25 1. Ansätze in der gesetzlichen Regelung zur Projektverantwortung . . . . . . . . . . . . . . . . . . . . . 25 2. Spannungsverhältnis zwischen juristischer Projektverantwortung und praktischem Projektmanagement. . . . . . . . . . . . . . . . . 30 III. Aufgaben des Projektmanagements . . . . . . . . . . . . . . . . . . . . . . . 1. Überblick über die Aktivitäten des Projektmanagements. . . . . . 2. Bestandteile eines erfolgreichen Projektmanagements . . . . a) Erfüllung der Stakeholdererwartungen. . . . . . . . . . . . . . . b) Planung und Strukturierung c) Informations- und Wissensmanagement . . . . . . . . . . . . . . d) Aufwandsschätzung. . . . . . . .

34 34 39 39 40 41 42

IV. Grundlagen für die erfolgreiche Projektabwicklung . . . . . . . 43 1. Vorgehensmodelle . . . . . . . . . . . . 43

Rz. a) Begriff und Bedeutung für die Vertragsgestaltung . . . . . . b) Einzelne Vorgehensmodelle: Klassisches Phasenmodell, Wasserfall, V-Modell, Agile Programmierung . . . . . . . . . . . aa) Klassisches Phasenmodell . . . . . . . . . . . . . . . . . . . . bb) Wasserfall-Modell. . . . . . . cc) V-Modell . . . . . . . . . . . . . . . dd) Prototypen-Modell . . . . . . ee) Spiralmodell . . . . . . . . . . . ff) Agile Vorgehensmodelle . c) Beispielhafte Projektphasen . aa) Variante 1: Klassisches Phasenmodell . . . . . . . . . . bb) Variante 2: Vier Grobphasen einer SAP R/3Einführung . . . . . . . . . . . . . cc) Variante 3: Phasenmodell für Softwareentwicklung. . . . . . . . . . . . . . . 2. Auswahlkriterien für Vorgehensmodelle . . . . . . . . . . . . . . . . . 3. Projektplanung . . . . . . . . . . . . . . . a) Bestandteile der Projektplanung . . . . . . . . . . . . . . . . . . . b) Ablauf- und Terminplan sowie Aufwandsschätzung . . c) Meilensteine . . . . . . . . . . . . . . d) Puffermanagement . . . . . . . . . 4. Rechtliche Aspekte des Projektmanagements . . . . . . . . . . . . a) Vertragsgestaltung zur Unterstützung des Projektmanagements. . . . . . . . . . . . . . . . . b) Claim Management während des Projekts . . . . . . . . . . . V. Projektorganisation . . . . . . . . . . . 1. Zweck der Projektorganisation: Rollen und Verantwortlichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Denkbare Projektorganisation . 3. Formulierungsvorschlag. . . . . . .

43

48 48 52 53 56 59 61 68 69

70

71 72 74 74 76 78 79 80

80 84 85

85 88 89

VI. Projektkommunikation . . . . . . . 90 1. Risikofaktor Kommunikation . 90

Witzel

783

H Rz. 1

Sonderregelungen Rz.

Rz.

2. Erhöhtes Risiko durch internationale Bezüge . . . . . . . . . . . . . . . 93 3. Schlechte Informationspolitik . 94 4. Vertragliche Festlegungen als Hilfestellung. . . . . . . . . . . . . . . . . 95

a) Risiken und Unsicherheiten . . . . . . . . . . . . . . . . . . . 108 b) Risikomanagement. . . . . . . 112

VII. Projektcontrolling und Risikomanagement. . . . . . . . . . . . . . . . . 101 1. Projektcontrolling . . . . . . . . . . . . 101 2. Risikomanagement . . . . . . . . . . . 108

VIII. Eskalation . . . . . . . . . . . . . . . . . 114 1. Unvermeidbarkeit von Konflikten . . . . . . . . . . . . . . . . . . . . . 114 2. Möglichkeiten zur Konfliktlösung . . . . . . . . . . . . . . . . . . . . . 117

I. Grundbegriffe des Projektmanagements 1. Bedeutung des Projektmanagements a) Projektmanagement als zentraler Erfolgsfaktor 1

IT-Projektverträge dürfen nicht nur Regelungen enthalten, die im Fall des Scheiterns greifen und die Voraussetzungen bzw. Konsequenzen des Scheiterns regeln. Der Hauptfokus sollte auf solchen Regelungen liegen, die im Vorfeld des Scheiterns Abhilfe schaffen (können). Dazu gehört auch das Projektmanagement1. Alle Projekte mit IT-Bezug (nicht nur solche, deren Gegenstand Individualsoftwareentwicklung oder die Anpassung und Implementierung von Standardsoftware ist) haben große Gemeinsamkeiten. Es gibt Anforderungen des Auftraggebers, Abhängigkeiten zwischen den Anforderungen des Auftraggebers und den Leistungen des Anbieters. Wichtige Elemente für den Projekterfolg sind Kommunikation, Entscheidungsfähigkeit und Entscheidungswille. Projekte haben grundsätzlich einen Zeitplan, ein Budget und einen „Auftraggeber“ (dieser kann auch eine interne Abteilung sein). Viele IT-Projekte scheitern nicht an unzureichender Technik, sondern an schlechten und intransparenten Strukturen und unzureichender Organisation sowie Kommunikation.

2

Die Leistungen des Projektmanagements und der Projektsteuerung gehören zu den entscheidenden Erfolgsfaktoren jedes komplexeren IT-Projekts. Projektmanagement bedeutet Organisation des Projektverlaufs. Darunter fällt das Planen, Steuern und Kontrollieren von Projekten2. Ein entscheidendes Element des Projektmanagements liegt in der Projektleitung. Dabei handelt 1 Berkun/Demmig, Die Kunst des IT-Projektmanagements, 2. Aufl. 2010; Geirhos, IT-Projektmanagement, 2011; Schelinski/von dem Bussche, in: Leupold/Glossner, IT-Recht, 2011, Teil 1 Rz. 382 ff.; Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010. 2 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009: „Management umfasst alle Aktivitäten und Aufgaben, um eigene und fremde Aktivitäten unter Mitwirkung von Vorgesetzten, Kollegen, Mitarbeitern und der Außenwelt zu planen und zu kontrollieren, damit ein Ziel oder der Abschluss einer Aktivität erreicht wird.“

784

Witzel

Projektmanagement

Rz. 4

H

es sich im Wesentlichen um Führungsaufgaben, die auch entsprechend qualifiziertes Personal erfordern. Das professionelle Projektmanagement ist als zentrales Erfolgskriterium von Projekten zu sehen. Insbesondere sind – die Projektgrenzen und Projektziele nachvollziehbar zu definieren; – Projektpläne zu entwickeln und einer periodischen Kontrolle zu unterziehen; – Projekte prozessorientiert zu strukturieren; – die Projektorganisation zu gestalten; – eine spezifische Projektkultur zu entwickeln; – die Beziehungen des Projekts zum Projektkontext zu gestalten. Projektmanagement gibt es nicht zum Nulltarif. Wesentlicher Bestandteil 3 des Projektmanagements ist der Planungsprozess, der je nach Umfang und Dauer eines Projekts umfangreiche personelle und finanzielle Ressourcen beider Vertragspartner erfordert. Häufig wollen die Projektbeteiligten an dieser Stelle sparen. Softwareanbieter bemessen in ihren Angeboten die Aufwände für das erforderliche Projektmanagement zu knapp, um günstig anbieten zu können. Auftraggeber meinen, dass in den Planungsprozessen Einsparungspotential besteht, sie hätten schließlich einen „Standard eingekauft“, der nur unwesentlich angepasst werden muss. Beide Vertragspartner übersehen die Vorteile eines konsequenten Projektmanagements, zu dem auch die gründliche Planung gehört: – Projektmanagement kann chaotische und widersprüchliche Einzelschritte, Doppelarbeiten und übereilte Notlösungen verhindern. – Auswahlkriterien und Entscheidungsprozesse sind für alle offen gelegt. – Das Risiko von Fehlentscheidungen wird verringert. – Abweichungen, Störungen und Verzögerungen lassen sich besser und früher erkennen und durch rechtzeitige Maßnahmen abfangen und abmildern. Ähnlich dem Bereich der Anforderungsermittlung (Requirements Engineer- 4 ing) ist das Projektmanagement der falsche Ansatz für Einsparungen. Fehlende Strukturen rächen sich, häufig ist keiner der Vertragspartner mehr in der Lage, den tatsächlichen Status des Projekts zu bestimmen. Wenn sich die Misserfolge beim Testen häufen, wird zu einem späten Zeitpunkt im Projekt deutlich, dass es in der entscheidenden Konzeptionierungsphase an Kommunikation gefehlt hat. Juristische Berater sollten die Kostenschätzungen der Vertragspartner kritisch hinterfragen. Schätzt ein Softwareanbieter bei einem Einführungsprojekt, das sechs bis neun Monate dauern soll, nicht mehr als 20 Personentage für die Aktivitäten des Projektmanagements, liegt schon auf der Hand, dass dies nicht ausreichend ist. Für eine nachvollziehbare Projektdokumentation wird bei einer solchen Schätzung kaum Zeit bleiben.

Witzel

785

H Rz. 5

Sonderregelungen

b) Spannungsverhältnis Projektmanagement und juristische Projektsteuerung 5

Auf den ersten Blick scheinen Vertragsgestaltung und stringentes Projektmanagement eine identische Zielsetzung zu haben, nämlich den erfolgreichen Abschluss eines Projekts. Die Ansätze zur Erreichung dieses Ziels weisen allerdings wesentliche Unterschiede auf, derer sich die Vertragspartner und deren juristische Berater bei der Gestaltung von Verträgen bewusst sein müssen. Während die juristische Projektsteuerung den Ansatz verfolgt, Verantwortlichkeiten klar abzugrenzen, Softwareanbietern und Auftraggebern unterschiedliche Aufgaben zuzuweisen und die Aktivitäten von Projektteams in Leistung einerseits und Mitwirkung anderseits aufzuteilen, richtet das Projektmanagement den Fokus darauf, zu integrieren und die Kooperation und Interaktion der Vertragspartner zu fördern. Dies mag auch daran liegen, dass das Projektmanagement nur bedingt zwischen externen Projekten unter Beteiligung Dritter und unternehmensinternen Projekten unterscheidet, sondern eher generelle Grundsätze aufstellt. Bei unternehmensinternen Projekten hat die Abgrenzung von Verantwortlichkeiten und die Aufgabenzuweisung einen anderen Hintergrund; sie dient nicht als Bewertungskriterium für die Voraussetzung von Leistungsstörungen, sondern hat „nur“ die erfolgreiche Projektbeendigung im Blick.

6

Der Gedanke der Projektmanager auf beiden Seiten ist häufig, dass die Vertragspartner „in einem Boot sitzen“. Juristische Hinweise, die der Abgrenzung der Verantwortung – vor allem im werkvertraglichen Sinne – dienen, sind aus Sicht des Projektmanagements teilweise sogar kontraproduktiv. So mag es beispielsweise in einer kritischen Projektsituation juristisch zwingend sein, den Auftraggeber schriftlich zur Erbringung seiner Mitwirkungsleistungen aufzufordern. Für die Arbeitsebene des Projekts, auf der es häufig auch darum geht, die Anwender des Auftraggebers „abzuholen“, führt eine schriftliche Fristsetzung zu Eskalationen, die ein Projektmanager lieber vermeiden möchte. Die Steuerungsmechanismen des Projektmanagements wie Meilensteine und Projektpläne sollen den Projekterfolg sichern, sind aber keineswegs immer im Einklang mit den juristischen Vorstellungen von Terminen und Verzug. Ein Meilenstein aus Projektsicht bedeutet nicht automatisch nur die Liefer- oder Leistungsverpflichtung eines Vertragspartners, bei dessen Nichteinhaltung einfach die Voraussetzungen des Verzugs vorliegen. Viel häufiger ist ein Meilenstein ein Projektziel, das erreicht ist, wenn beide Vertragspartner – und ggf. auch dritte Projektbeteiligte – voneinander abhängige Leistungen erfüllt haben. Wird der Meilenstein nicht erreicht, ist die Feststellung, wer für die Nichteinhaltung verantwortlich ist, sehr schwierig und auch nicht immer möglich. Ohne ein gutes Projektmanagement wird ein IT-Projekt noch viel weniger Erfolgschancen haben als ohne eine gute vertragliche Grundlage. Für die Vertragsgestaltung ergibt sich damit die Herausforderung, die unterschiedlichen Ansätze in Einklang zu bringen und darauf zu achten, dass ein Vertrag mit Hilfe des Projektma-

786

Witzel

Projektmanagement

H

Rz. 7

nagements gelebt werden kann und nicht den Prinzipien des Projektmanagements völlig widerspricht. c) Typische Problemfelder und Konsequenzen für erfolgreiche IT-Projekte Unzureichendes Projektmanagement ist eine der Ursachen für das häufige 7 Scheitern von IT-Projekten. Die Problembereiche lassen sich wie folgt darstellen1: Problembereiche

Beispiele

Projektdefinition Projektauftrag2

Projektstart ohne vorhergehende Prüfung eines Projektantrags fehlende Projektzielsetzungen unklar formulierte Projektziele (fehlende Messbarkeit) überzogene Zielformulierungen und Erwartungen fehlende oder fehlerhafte Anforderungsspezifikationen

Projektkalkulation

unzureichende Aufwandsschätzung falsche Kostenplanung

Ausgangssituation

unzureichende Kenntnis der Ausgangssituation Projekterschwernis durch Altlasten (fehlende Innovationsbereitschaft beteiligter Teammitglieder, Verharren in überholten Techniken)

Projektabgrenzung

nicht vorgenommene oder ungeklärte Abgrenzung zu anderen Projekten unzureichende Dokumentation der Schnittstellen und Vernetzungen mit anderen Projekten

Methoden und Techniken der Projektarbeit Methodenwahl

falsche Methodenwahl (für Ist-Aufnahme, Ist-Analyse, Soll-Konzeptentwicklung) unzureichende Methodenerkenntnis zur Projektplanung (Zeiten, Ressourcen, Aufwandsschätzung)

1 S. Tiemeyer, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 5. 2 Der Begriff des Projektauftrags ist eine Terminologie aus dem Projektmanagement und bezeichnet ein Dokument des Auftraggebers, das die Existenz des Projekts bestätigt. Es ist kein normierter Begriff, s. www.wikipedia.org.

Witzel

787

H Rz. 7 Problembereiche

Sonderregelungen Beispiele unzureichende Toolunterstützung unzureichende Methodikkenntnisse der Projektkalkulation

Organisation

fehlendes Entscheidungs- und Controllinggremium unzureichende Delegation von Verantwortung durch die Projektleitung

externe Partner (Mitwirkung in Teilprozessen, Beratung)

Probleme bei der Auswahl der Kooperationspartner Unzureichende Qualifikation der externen Unterstützer

Personelle Aspekte der Projektarbeit Projektteam (Verständigung bzw. Kommunikation im Projekt)

inkompetente Teammitglieder bzw. Entscheidungsträger (unzureichende Fachkompetenz) Herkunfts- und Sprachunterschiede der Teammitglieder unterschiedliches Rollenverständnis der am Projekt beteiligten Personen (Spannungen und Konflikte im Team) unklare Aufgabenstellung an die Teammitglieder Doppelbelastung der Teammitglieder

Projektleitung

Kompetenzgerangel mit Führungskräften der Fachabteilung Führungsschwäche der Projektleitung

Fachabteilung

fehlende Benutzerakzeptanz der Projektziele mangelnde Information der Fachabteilung Abteilungsdenken mit „Scheuklappen“ in den Fachbereichen Demotivation des Fachbereichs aufgrund früherer Projektfehlschläge unzureichende Verantwortung und Beteiligung im Projektteam

Unternehmensleitung

mangelnde Unterstützung der Projektarbeit verzögerte Entscheidungen

Projektplanung Anforderungen

fehlende Überprüfung und Einbeziehung von Anforderungen unzureichende Strukturierung von Aufgabenstellung und Dokumenten

788

Witzel

Projektmanagement

H

Rz. 8

Problembereiche

Beispiele

Kosten/Ressourcen

pauschale Planung von Kosten falsch eingeschätzter Ressourcenbedarf

Termine

Terminvorgabe durch Wunschdenken unrealistisch kurze Terminvorgaben zur Fertigstellung

Projektdurchführung und -steuerung Vorgehen

Problemlösung nach Auftreten, zu späte Reaktion unzureichende Regelung von Verantwortlichkeiten, Informations- und Entscheidungswegen Veränderung/Gefährdung der ursprüglichen Projektziele durch neue Anforderungen/neue Forderungen des Auftraggebers fehlendes akzeptiertes Vorgehensmodell fehlende Prioritätenregelung

Projektreviews

zu spätes Erkennen von Zielabweichungen zu lockere Handhabung von Projektreviews fehlende Status- und Terminbesprechungen fehlende gezielte Kostenüberwachung

Berichtswesen

unzureichendes Projektberichtswesen (oberflächlich und mangelhaft) fehlende Dokumentation von Projekt-Fortschritten fehlende Kennzahlen, fehlendes integriertes Frühwarnsystem

2. Begriffe und Definitionen1 Was ist überhaupt ein Projekt? Nach DIN 69901 ist ein Projekt ein Vor- 8 haben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. durch eine Zielvorgabe, zeitliche, finanzielle, personelle oder andere Begrenzungen. Ein Projekt ist abgrenzbar gegenüber anderen Vorhaben und verfügt über eine projektspezifische Organisation. Projekte gibt es nicht nur im Technologieumfeld, sondern in vielen Branchen. Auch die Neuinszenierung einer Oper mit einem festgelegten Premierentermin ist ein Projekt i.S.d. vorstehenden Definition.

1 Geirhos, IT-Projektmanagement, 2011, S. 15: „Ein Projekt ist eine komplexe Aufgabe, die einen Anfang und ein Ende hat, für die eine projektspezifische Organisation eingerichtet wurde und die ein bestimmtes Ziel verfolgt.“

Witzel

789

H Rz. 9 9

Sonderregelungen

Projektmanagement wird je nach Quelle textlich unterschiedlich, inhaltlich aber weitgehend übereinstimmend definiert: – DIN-Norm (DIN 69901 – 5:2009-01): „Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten.“ – Project Management Institute (PMI): „Project Management is the application of knowledge, skills, tools, techniques to project activities to meet project requirements.“ – Gesellschaft für Informatik: „Das Projekt führen, koordinieren, steuern und kontrollieren.“ – ICB (International Competence Baseline): „Führung der Projektbeteiligten zur sicheren Erreichung der Projektziele“

10 Viele Begriffe und Verfahrensweisen im Projektmanagement sind etabliert und standardisiert. In Studiengängen im Bereich des Ingenieurswesens, der Informatik und der Betriebswirtschaft werden Grundkenntnisse des Projektmanagements vermittelt. Es gibt weltweit unterschiedliche Verbände, die sich dem Projektmanagement verschrieben haben: – Project Management Institute (PMI)1 – Office of Government Commerce (OCG) – International Project Management Association (IPMA)2 3. Standards und Normen a) Projektmanagement-Methoden 11 Bei Normen und Standards sind Projektmanagement-Methoden einerseits und Vorgehensmodelle anderseits zu unterscheiden. ProjektmanagementMethoden beziehen sich auf die Instrumente des Projektmanagements, etwa die Anforderungsermittlung (Requirements Engineering), die Projektplanung und das Risikomanagement. Vorgehensmodelle dienen der Festlegung der Abfolge von Tätigkeiten innerhalb eines Projekts. 12 Projektmanagement-Methoden unterstützen bei der strukturierten Planung und Steuerung von Projekten. Eine Projektmanagement-Methode ist eine formalisierte und standardisierte Herangehensweise an Projekte, die insbesondere eine konkrete Ausgestaltung des Projektmanagements vorschreibt. Solche Methoden bieten einen Rahmen, der in der Regel sowohl auf Erfahrungen aus vergangenen Projekten als auch auf theoretischen Überlegungen

1 www.pmi.org: „We serve practitioners and organizations with standards that describe good practices, globally recognized credentials that certify project management expertise, and resources for professional development, networking and community. 2 www.ipma.ch: IPMA is recognized throughout the world as leading authority on competent project and portfolio management (PPPM).

790

Witzel

Projektmanagement

Rz. 14

H

basiert und regelmäßig überprüft sowie bei Bedarf angepasst wird. Projektmanagement-Methoden dienen als Werkzeugkasten für Projektverantwortliche und Projektmanager. Sie sollen dabei unterstützen, Projekte effizient und effektiv zu gestalten. Grundlage für Projektmanagement-Methoden finden sich in – DIN 69900–69905 – ISO 10006 – Project Management Body of Knowledge (PMBOK Guide): PM-Standard des Projektmanagementverbands Project Management Institute – IPMA Competence Baseline ICB: Projektmanagement-Standard des Projektmanagementverbands International Project Management Association/Deutsche Gesellschaft für Projektmanagement (GPM) – PRINCE2: Projektmanagement-Methode, verbreitet vor allem in den Niederlanden und Großbritannien1. – V-Modell – PSI 1: Vorgehensmodell zum kollaborativen Projektmanagement von ProSTEP iViP – Project Management Maturity Model (PMMM) – IEC 62198 Project Risk Management. Die Anwendung einer Projektmanagement-Methode kann einen wesentli- 13 chen Beitrag zum Projekterfolg leisten, allerdings auch nur dann, wenn sie als Werkzeugkasten und nicht zum Selbstzweck eingesetzt wird. Wie alle Methoden, Best Practices, Frameworks und auch Vorgehensmodelle kann eine Projektmanagement-Methode nicht die Festlegung einer klaren und abgrenzbaren Zielsetzung für ein Projekt ersetzen, sie kann nur bei der Umsetzung unterstützen. Die Orientierung an einer ProjektmanagementMethode fördert den Projekterfolg dann, wenn das Werkzeug zur Aufgabe passt. Allein die Auswahl und Anwendung einer etablierten Projektmanagement-Methode hilft für den Projekterfolg nicht; ähnlich wie die Regelungen eines Projektvertrags muss auch die Methodik mit Leben gefüllt werden. b) Aspekte von PRINCE2 als Beispiel für eine ProjektmanagementMethode PRINCE22 wurde 2009 in einer neuen Version veröffentlicht. Die Literatur 14 dazu wurde in zwei Bände, die kostenpflichtig vertrieben werden, aufgeteilt:

1 Zu PRINCE2 u.a. Beims, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 113 ff. 2 Projects in Controlled Environments wurde ursprünglich 1989 von der britischen Central Computer and Telecommunications Agency (CCTA) als Regierungsstandard für Projektmanagement im Bereich der Informationstechnik angewendet.

Witzel

791

H Rz. 15

Sonderregelungen

– Teil 1 ist bezeichnet als „Directing Successful Projects with PRINCE2®“, das sich insbesondere an Projektauftraggeber und Entscheider, also an die Mitglieder eines Lenkungsausschusses richtet. – Teil 2 hat den Titel „Managing Successful Project with PRINCE2®“, da es sich an die gesamte Projektorganisation richtet. 15 PRINCE2 definiert sieben Grundprinzipien des Projektmanagements: – Fortlaufende geschäftliche Rechtfertigung

–

–

– –

–

–

Ein Projekt braucht einen berechtigten Grund für seinen Start und es muss fortwährend gewährleistet sein, dass dieses Projekt einen dokumentierten und genehmigten erwarteten Nutzen hat. Lernen aus Erfahrung Erfahrungen aus anderen Projekten werden gezielt mit aufgenommen und die gesammelten Erfahrungen in laufenden Projekten festgehalten. Definierte Rollen und Verantwortlichkeiten Ein Projekt benötigt definierte Rollen und Verantwortlichkeiten innerhalb einer Organisationsstruktur, in der die Interessen des Auftraggebers, der Anwender und der Lieferanten vertreten sind. Steuerung über Management-Phasen Die Planung, Überwachung und Steuerung ist nach Phasen gegliedert. Steuern nach dem Ausnahmeprinzip Für jedes Projektziel werden bestimmte Toleranzen definiert, die den Handlungsrahmen für delegierte Befugnisse festlegen. Produktorientierung1 PRINCE2 ist auf die Definition und Lieferung von Produkten ausgerichtet, wobei der Schwerpunkt auf deren Qualitätsanforderungen liegt. Anpassung auf die Projektumgebung PRINCE2 wird auf jedes Unternehmen und teilweise sogar jedes Projekt angepasst, um auf die speziellen Anforderungen eines Projekts hinsichtlich seiner Umgebung, des Umfangs, der Komplexität, der Wichtigkeit, der Leistungsfähigkeit und des Risikos eingehen zu können.

16 Neben diesen sieben Grundprinzipien beschreibt PRINCE2 sieben sog. Themen, die während eines Projekts kontinuierlich behandelt werden müssen, damit das Projekt erfolgreich wird: – Business Case (Warum?) Zweck eines Business Cases ist es, die notwendigen Investitionen in das Projekt und die bestehenden Risiken mit dem Projektergebnis und dem daraus resultierenden Nutzen für den Auftraggeber nachvollziehbar zu rechtfertigen.

1 Produktorientierung lässt sich auch als Ergebnisorientierung bezeichnen, s. www.wikipedia.org zu PRINCE2.

792

Witzel

Projektmanagement

Rz. 17

H

– Organisation (Wer?) Das Thema Organisation stellt sicher, dass für jedes Projekt sinnvoll definierte Rollen und Verantwortlichkeiten festgelegt werden, die dabei unterstützen sollen, die vereinbarten Ergebnisse effektiv und effizient zu liefern. – Qualität (Was?) Innerhalb dieses Themas wird beschrieben, welche Mittel und Maßnahmen definiert und implementiert werden müssen, damit das Projekt in der Lage ist, die Produkte entsprechend dem Bedarf des Auftraggebers zu liefern. Qualität ist die Fähigkeit eines Produkts, definierte Anforderungen zu erfüllen. – Pläne (Wie? Wie viel? Wann?) Pläne dienen der Steuerung des Projekts, indem festgelegt wird, (i) was, (ii) wo, (iii) wie, (iv) durch wen, (v) wann und (vi) mit welchen Kosten innerhalb des Projekts geliefert werden soll. Pläne beantworten die Frage, was man für den Projekterfolg benötigt, durch welche Ressourcen es geliefert wird und wann die Lieferung erfolgen wird. – Risiken (Was ist, wenn?) Mit Projekten sind üblicherweise mehr Risiken verbunden als mit normalen betrieblichen Abläufen. Das Thema „Risiken“ beschäftigt sich damit, wie das Projektmanagement mit den Unsicherheiten in den Plänen und der sonstigen Projektumgebung umgeht. Bei der Identifizierung und Beschreibung von Risiken wird in PRINCE2 unterschieden zwischen Risikoursache (Was hat das Risiko herbeigeführt?), Risikoereignis (Worin besteht die Bedrohung oder Chance?) und Risikoauswirkung (Welche Konsequenzen ergeben sich bei Eintritt für das Projekt?) – Änderungen (Was sind die Auswirkungen?) Innerhalb eines Projekts können aus verschiedenen Gründen Änderungen erforderlich werden. – Fortschritt (Wo stehen wir jetzt? Wo gehen wir hin? Sollen wir weitermachen?) Das Thema Fortschritt befasst sich mit dem Vergleich der tatsächlich erzielten Projektergebnisse mit den in der Planung vorgegebenen Zielen. Es handelt sich um einen kontinuierlichen Soll-Ist-Vergleich mit dem Ziel, Abweichungen frühzeitig zu erkennen und entsprechende Maßnahmen einzuleiten. Des Weiteren definiert PRINCE2 sieben Prozesse für die Steuerung von Pro- 17 jekten: – – – – –

Vorbereiten eines Projekts; Lenken eines Projekts; Initiieren eines Projekts; Steuern einer Phase; Managen der Produktlieferung; Witzel

793

H Rz. 18

Sonderregelungen

– Managen des Phasenübergangs; – Abschließen eines Projekts. 18 Unter Prozess versteht PRINCE2 eine Reihe von Aktivitäten, die auf die Erreichung eines bestimmten Ziels gerichtet ist. Ein Prozess ist nicht gleichzusetzen mit einer Phase des Projekts; eine Phase kann aus mehreren Prozessen bestehen. c) Projektmanagement-Software 19 Das Management und die Überwachung eines IT-Projekts sind generell auch ohne den Einsatz spezieller Software möglich. Anwälte, die sich mit IT-Projekten in Schieflage auseinandersetzen müssen, haben häufig große Mühe, den Verlauf des Projekts zu rekonstruieren. Vereinbarte Erweiterungen des Leistungsumfangs können allenfalls durch die Auswertung der ausgetauschten E-Mails1 „ermittelt“ werden, und abgesehen von den auf der Hand liegenden Beweisproblemen ist es nahezu unmöglich, den tatsächlichen Status eines IT-Projekts festzustellen. Eine verlässliche Risikoabschätzung ist mangels belastbarer Dokumente kaum möglich: Sofern es überhaupt Protokolle von Besprechungen gibt, sind diese nicht unterzeichnet, die angeblich letzte Version ist noch im Word-Änderungsmodus. Für die Berater ist nicht feststellbar, worauf sich die Vertragspartner geeinigt haben (könnten). 20 Um das Projektmanagement zu erleichtern, gibt es unterschiedliche Softwareprodukte, die die Organisation und Verwaltung von Ressourcen erleichtern sollen. Unter Projektmanagement-Software versteht man ein Werkzeug, das die unterschiedlichen Dimensionen eines Projekts visualisiert und Warnmechanismen verwendet, um auf Verzögerungen, mangelnde Ressourcen oder Budgetüberschreitungen hinzuweisen. ProjektmanagementSoftware bietet Kommunikationstools, eine zentrale Datenspeicherung für Dokumente (Berichte, Spezifikationen) und ermöglicht ein einheitliches Arbeitsumfeld für alle Beteiligten. Reibungsverluste aufgrund unterschiedlicher Formate und Standards können vermieden werden. 21 Beispiele für Projektmanagement-Software kommerzieller Anbieter sind: – ACOS Plus 1 – Asta Powerproject 1 Zum Thema E-Mail als Kommunikationsmittel, s. Bauer/Hauptmann, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 562: „E-Mail wird heute gern als universelles Medium für den Informationsaustausch genutzt. In einem Beispielprojekt mit einer Laufzeit von 1,5 Jahren und einem Gesamtumfang von 18 Personenjahren erreichen einen von drei Projektmanagern über 3800 E-Mails aus dem Projekt. Das sind fast 14 E-Mails pro Tag. Ein Entwickler eines anderen Projekts hat im Zeitraum von 2 Jahren bei etwa 4000 projektbezogenen E-Mails nur etwa 1/6 davon beantwortet und sich nur etwa 1/6 davon als wichtige Information archiviert.“

794

Witzel

Projektmanagement

– – – – – – – –

Rz. 23

H

PSNext Microsoft Project PLANTA Projektmanagement System FastTrack Schedule Planisware Primavera Rillsoft Project CoP.Track

Auch im Bereich Open Source finden sich vielfältige Werkzeuge zum Pro- 22 jektmanagement: – – – – – – – – – – – –

PHProject Double Choco Latte Dotproject Gnome Planner WebCollab PhCollab ProManager TaskJuggler ProjectPier OpenProj airTODO Open Workbench

Die Anzahl der Produkte im Bereich Projektmanagement-Software ist groß 23 und stetig wachsend. Es gibt Produkte in allen Ausprägungen und für alle Vorgehensmodelle. Es gibt Produkte, die sich eher zur Planung, Steuerung und Überwachung von Einzelprojekten eignen. Daneben gibt es Projektmanagement-Suites, mit denen mehrere parallel laufende Projekte gesteuert werden können. Wichtig erscheint, dass sich die Vertragspartner auf eine zum konkreten Projekt passende Software verständigen und darüber hinaus auch generell festlegen, dass die mit dieser Projektmanagement-Software verwalteten Dokumente und Daten das gemeinsame Projektverständnis abbilden. Sie sollten sich Gedanken darüber machen, ob nur elektronisch ausgetauschte Dokumente dem (ggf. vertraglich geforderten) Schriftformerfordernis gerecht werden sollen und welche Verbindlichkeit den ausgetauschten Daten und Unterlagen zukommen soll. Vor einer abschließenden Entscheidung über den Einsatz einer solchen Software sollten sich die Vertragspartner vergegenwärtigen, wie eine solche Software arbeitet, welchen konkreten Funktionsumfang sie aufweist und in welchem Umfang die Funktionalität genutzt werden soll; des Weiteren, welche Projektmanagement-Prozesse im Detail unterstützt werden sollen.

Witzel

795

H Rz. 24

Sonderregelungen

24 Vertragliche Regelungen dazu bieten sich an:

(1) Projektmanagement-Tool (PMT) des Auftragnehmers (1.1) Zwecksetzung Sämtliche leistungsbezogenen Aktivitäten der Vertragspartner, insbesondere – Anfragen von „change requests“, – Bereitstellung von Angeboten, insbesondere zu angefragten „change requests“, – Beauftragung von Zusätzen zur Software und/oder Dokumenten, – Beauftragung von optionalen Leistungen, – Beauftragung von „change requests“, – Änderungen des Zeitplans, – Änderung von Kommunikationsdaten, – Übergabe und Abnahme von Software und/oder Dokumenten; insbesondere Übergabe- und Abnahmeprotokolle, sowie – die Rüge von Mängeln und Störungsmeldungen. werden im PMT des Auftragnehmers protokolliert/hinterlegt. (1.2) Schriftformerfordernis Die Protokollierung/Hinterlegung im PMT genügt dem in diesem Vertrag vereinbarten Schriftformerfordernis außer für Nachfristsetzungen, Kündigungen oder Änderungen des Vertrages Ziffer 8. Eine Beauftragung, die eine Vergütung beinhaltet oder bei der der Auftraggeber dies im PMT entsprechend vermerkt, ist für den Auftraggeber aber nur dann bindend, wenn sie schriftlich mittels einer gesonderten Bestellungen erfolgt ist. Um dem Schriftlichkeitserfordernis der Abnahmeerklärungen der Anforderungsbeschreibungen gemäß diesem Vertrag zu genügen, muss der Auftragnehmer die vom Auftraggeber im PMT abgenommenen Dokumente unterzeichnen und dem Auftraggeber zusätzlich im Original übermitteln. Eine gescannte Version dieser gegenzeichneten Version wird im PMT entsprechend hinterlegt. (1.3) Zugriff auf das PMT Der Auftragnehmer wird dem Auftraggeber hierzu einen entsprechenden Zugriff auf sein PMTzur Verfügung stellen mittels direkten Zugriffs via Citrix auf das PMT unter Verwendung von RSA Token. Hierzu werden dem Auftraggeber unentgeltlich die zur Autorisierung notwendigen RSA Token zur Verfügung gestellt (bis zum 5 RSA Token pro Projektteam). Der Zugriff des Auftraggebers auf das PMT darf bis zur Beendigung des Projekts sowie eines Jahres darüber hinaus, dem Auftraggeber nicht einseitig vom Auftragnehmer entzogen werden. Im Fall einer Beendigung dieses Vertrages wird der Auftragnehmer dem Auftraggeber angemessene Gelegenheit geben, die im PMT vorhandenen Daten und Unterlagen zu sichern.

796

Witzel

Projektmanagement

Rz. 26

H

II. Rechtliche Grundsätze zur Projektverantwortung 1. Ansätze in der gesetzlichen Regelung zur Projektverantwortung Die Ansätze im BGB zur Steuerung eines (IT-)Projekts sind minimal, das 25 Gesetz verwendet die Begriffe Verantwortung, Projektverantwortung oder Projektleitung nicht1. § 631 Abs. 1 BGB besagt, dass der Unternehmer durch den Werkvertrag zur Erstellung des versprochenen Werks verpflichtet wird. Ein Werkvertrag liegt vor, wenn die Verantwortung für den Erfolg beim beauftragten Unternehmer liegt oder der Einsatz von Personal oder Werkzeugen von seiner Weisung abhängig ist2. § 631 Abs. 2 BGB präzisiert, dass der Gegenstand des Werkvertrags in der Herstellung oder Veränderung einer Sache liegen kann, und zwar „als ein anderer als durch Arbeit oder Dienstleistung herbeizuführender Erfolg“. Aus der Erfolgsorientierung des Werkvertrags und der Aufteilung der Pflichten ergibt sich, dass grundsätzlich bei einer werkvertraglichen Gestaltung der Softwareanbieter im Verhältnis zum Anwender allein die Verantwortung für den Erfolg trägt. Die Risikoverteilung des Werkvertrags geht allein davon aus, dass der Auftragnehmer das Risiko für die Fertigstellung (Herstellungsrisiko) übernimmt, er trägt somit die Projektverantwortung. Um die Projektverantwortung auszuführen, hat er gewissermaßen auch die Pflicht und das Recht zur Projektleitung. Die Verantwortung des Auftragnehmers führt im Ergebnis zu einer weitgehenden Entlastung des Auftraggebers: Der Auftragnehmer ist verpflichtet, die Vorgaben (Anforderungen) des Auftraggebers zu prüfen. Er muss sehen, ob sich das vom Auftraggeber gestellte Material (Beschreibung von Anforderungen und IT-Infrastruktur, Testfälle und Testdaten) für die Erreichung des angestrebten Erfolgs eignet. Ebenfalls trifft den Auftragnehmer eines Werkvertrags die Verpflichtung festzustellen, ob das von ihm zu erstellende Werk zu den vorhandenen Anlagen (Hardware, IT-Infrastruktur und Umsysteme) des Auftraggebers passt oder ob sich aus dem Zusammenwirken des Werks mit anderen vorhandenen Komponenten (Umsystemen) besondere Gefahren für den Auftraggeber ergeben3. Die wesentliche Grundkategorie ist demzufolge die Verteilung von Projekt- 26 verantwortung in Kombination mit Projektleitung auf der einen Seite (charakteristisch beim Softwareanbieter im Fall des Werkvertrags) und die der Mitwirkung auf der anderen Seite (beim Anwender im Werkvertragsrecht). Fachliche Weisungen stehen dem Auftragnehmer auch bei Werkvertrags1 Arbeitskreis „Externe und interne Überwachung der Unternehmung der Schmalenbach-Gesellschaft für Betriebswirtschaft Köln, Projekte, Projektorganisation und Projektüberwachung“, DB 2002, 281. Müller-Hengstenberg, Risikomanagement in DV-Projekten, CR 1999, 198; Müller-Hengstenberg, Risikoverteilung in DV-Projekten, CR 1995, 198; Müller-Hengstenberg, Der Vertrag als Mittel des Risikomanagements, CR 2005, 385; Schneider, Projektsteuerung – Projektrisiken bei Software, LG Duisburg v. 2.12.1999 – 8 O 219/99, CR 2000, 27. 2 Beck’scher Online Kommentar BGB, § 631 Rz. 24. 3 Beck’scher Online Kommentar BGB, § 631 Rz. 4.

Witzel

797

H Rz. 27

Sonderregelungen

recht zu. Das Werkvertragsrecht geht von der klaren Erfolgsverantwortung des Auftragnehmers aus. Wer diese trägt, hat in der Konsequenz die Projektverantwortung und damit die Projektleitung. 27 Unterstellt man also die Anwendung reinen Werkvertragsrechts auf Projekte, die die Entwicklung und/oder Anpassung von Software sowie deren Implementierung zum Gegenstand haben, liegt die alleinige Erfolgsverantwortung beim Softwareanbieter. Dies wird jedoch in der Praxis schon deswegen scheitern, weil eine erfolgreiche Implementierung von Software (gleich ob Standardsoftware oder Individualsoftware) auch die Veränderung von Organisationsprozessen beim Anwender voraussetzt1: Hierfür kann der Softwareanbieter aber keine abschließende Erfolgsverantwortung übernehmen, da die Durchsetzung von Organisations- und Strukturierungsmaßnahmen nur durch den Anwender erfolgen kann. Die vertraglich gestaltete Projektsteuerung muss also bei einer werkvertraglichen Gestaltung eines Projektvertrags einen angemessen Interessenausgleich schaffen. 28 Beim Dienstvertrag2 steht die reine Tätigkeit des Auftragnehmers im Vordergrund. Er zielt nicht auf ein Werk, d.h. auf die Erstellung eines Arbeitsergebnisses oder auf die Erreichung eines bestimmten Arbeitserfolgs ab, sondern auf die Erbringung (unabhängiger) Dienste3. Für die übernommene Leistungspflicht hat der Auftragnehmer allerdings einzustehen. Andernfalls macht er sich – bei Vorliegen von Verschulden – schadensersatzpflichtig (§ 280 BGB). Bei einer rein dienstvertraglichen Gestaltung eines Projektvertrags läge also die Projektverantwortung und in Folge dessen die Projektleitung beim Auftraggeber. Er hat nicht nur ein fachliches, sondern auch ein organisatorisches Weisungsrecht. Nur bei Anwendern in großen Unternehmensstrukturen wird es möglich sein, für ein umfassendes Projekt zur Entwicklung bzw. Anpassung von Software und deren Implementierung die komplette Erfolgsverantwortung allein zu übernehmen. Kleineren und mittleren Unternehmen wird in vielen projektrelevanten Bereichen das Know-how fehlen, aber selbst bei kleineren Unternehmen kann die Verantwortung für die Anforderungsermittlung beim Anwender liegen. 29 Wie in Kap. G4 dargestellt, enthalten IT-Projektverträge überwiegend Elemente unterschiedlicher Vertragstypen, d.h. neben werkvertraglichen und dienstvertraglichen ggf. auch kaufvertragliche oder sogar mietvertragliche.

1 S. Kap. G Rz. 142 ff. 2 Münchener Kommentar zum BGB, 5. Aufl. 2009, § 631 Rz. 15: „Maßgebend für die Beantwortung der Frage, ob die Parteien einen (tätigkeitsbezogenen) Dienstvertrag oder einen (erfolgsbezogenen) Werkvertrag geschlossen haben, ist die vertragliche Bestimmung des Leistungsgegenstands durch die Vertragsschließenden. Die Abgrenzung zwischen Dienst- und Werkvertrag ist damit nicht in erster Linie ein rechtsdogmatisches Problem, sondern eine Frage der Vertragsauslegung.“ 3 Beck’scher Online Kommentar BGB, § 611 Rz. 22 ff. 4 S. dort Rz. 63 ff.

798

Witzel

Projektmanagement

H

Rz. 31

Für die Projektverantwortung kommt es folglich auf die Fallgestaltung im Einzelnen an, ein Rückgriff auf die Anhaltspunkte im Gesetz wird nur bei einigen Aspekten weiterhelfen. Die Vertragspartner werden sich überlegen müssen, für welche Teilbereiche im Projekt bei welchem Vertragspartner die Verantwortung liegen soll. Eine einseitige Verantwortungszuweisung oder Risikoverteilung wird im Zweifel keinem der Vertragspartner gerecht. Anwender sind nicht gut beraten, wenn sie versuchen, über ein werkvertragliches Erfolgsmoment die eigenen Fehler (unmotivierte Nutzer, unzureichende Anforderungsermittlung und mangelnde Ressourcen) und Risiken ihrer Sphäre (IT-Infrastruktur, schlecht dokumentierte Schnittstellen zu Umsystemen und schlechtes Lieferantenmanagement) auf den Auftragnehmer abwälzen zu wollen. Auftragnehmer anderseits brauchen sich über Misserfolge nicht zu wundern, wenn im gesamten Projekt über Change Requests versucht wird, die falschen Kalkulationen zu Beginn eines Projekts zu heilen oder wenn die eigenen Versäumnisse bei der Termintreue im Nachhinein mit angeblich fehlender Mitwirkung gerechtfertigt werden. Projekte, deren Beteiligte im Grabenkampf ersticken, sind selten erfolgreich1. 2. Spannungsverhältnis zwischen juristischer Projektverantwortung und praktischem Projektmanagement Das praktische Projektmanagement hat den Projekterfolg losgelöst von 30 einer Zuweisung der Verantwortung auf den einen oder anderen Vertragspartner im Fokus. Projekte werden immer in Teamarbeit realisiert. Die eigentliche Leistung im Projekt ist typischerweise ein kooperativer Problemlösungsprozess, bei dem alle betroffenen Wissens-, Kompetenz-, und Verantwortungsträger zusammenarbeiten2. Teil des Projektmanagements ist auch die Teambildung, d.h. aus einer Gruppe von Mitarbeitern mit verschiedenen Aufgaben, die zu Beginn eines Projekts zielgerichtet zusammengestellt wurden, soll am Ende eines Projekts ein „echtes Team“ werden. Das kooperative Element des Projektmanagements lässt sich unter anderen 31 auch anhand der Tätigkeitsbereiche3, wie sie vom Project Management Institute beschrieben werden, erkennen: – Integrationsmanagement: Die Integration eines Projekts soll sichergestellt und koordiniert werden. Beteiligte und Betroffene sind einzubeziehen.

1 Interessante Querverbindungen zu Bauprojekten und ggf. Anregungen für die Vertragsgestaltung (Bonus-Malusverträge, Maximumpreisverträge) finden sich bei Eschenbruch, Construction Management – Neue Perspektiven für Auftraggeber und Projektmanager, NZBau 2001, 585 sowie Kapellmann, Ein Construction Management Vertragsmodell – Probleme, Lösungen, NZBau 2001, 592. 2 Tiemeyer, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 608. 3 S. auch www.wikipedia.org.

Witzel

799

H Rz. 32

Sonderregelungen

– Inhalts- und Umfangsmanagement1: Das Management des Projektumfangs sorgt dafür, dass die gesetzten Projektziele erreicht werden. Es ist allerdings nicht nur für die Ergebnisorientierung in Bezug auf die ursprünglichen Ziele ausgerichtet, sondern hat insbesondere zur Aufgabe, notwendige Abweichungen von diesen Zielen, die im Projektverlauf deutlich werden, in das Projekt einzusteuern sowie entsprechende Neuplanungen zu veranlassen. – Terminmanagement: Zielt auf die Einhaltung des Zeitrahmens ab und sollte alle beteiligten Zielgruppen einbinden. Der Projektplan dient dabei als Kommunikationsmedium. – Kostenmanagement: Ist auf Budgeteinhaltung ausgerichtet. Innerhalb dessen ist der Kostenverlauf zu dokumentieren und soweit erforderlich Gegenmaßnahmen einzuleiten. – Qualitätsmanagement: Davon umfasst ist die Standardisierung von Projektprozessen, Dokumentation der Arbeiten und Ergebnisse sowie geeignetes Maßnahmenmanagement. – Personalmanagement: Zielt auf die effiziente Zuordnung der Ressourcen nach Fähigkeit und verfügbaren Kapazitäten zu den Projektaufgaben, aber auch die Teamentwicklung ab. – Kommunikationsmanagement: Schließt alle Betroffenen und Beteiligten ein. – Risikomanagement: Enthält Risikoanalysen, präventive Maßnahmen und Notfallkonzepte. – Beschaffungsmanagement: Dient der Integration und Zusammenarbeit mit Lieferanten. 32 Es wird deutlich, dass im Projektmanagement vor allem kooperative und integrative Elemente betont werden, die den Projekterfolg fördern sollen. Stellt man dem die klassische Aufteilung der juristischen Projektverantwortung gegenüber, wird schnell deutlich, dass es bei der juristischen Risikozuweisung an kooperativen Elementen fehlt. Während aus Sicht des Projektmanagements Projektteams möglichst stark kooperieren und an einem Strang ziehen sollen, versucht die rechtliche Betrachtung möglichst klar abzugrenzen, auch um feststellen zu können, wer etwaige Qualitätsmängel zu verantworten hat. Der Informationsaustausch dient juristisch der Befundund Beweissicherung, aus Projektsicht soll aber vorrangig das Engagement und die Motivation der Beteiligten abgesichert werden. Tiemeyer2 schreibt zutreffend, dass ein Team nur dann eine optimale Leistung erbringt, wenn es eine gemeinsame Richtung einschlägt. Ein wichtiges Element der modernen Teamkultur sei ausreichendes Vertrauen untereinander. Dies leuchtet ein, passt aber nicht zu einer einseitigen rechtlichen Zuweisung der Verantwortlichkeiten. Soll ein Softwareanbieter das alleinige Herstellungsrisiko

1 „Scope Management“, „Anforderungsmanagement“. 2 Tiemeyer, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 619.

800

Witzel

Projektmanagement

Rz. 35

H

tragen, muss er sich anders absichern als bei einer Vereinbarung, nach der auch der Auftraggeber einen angemessen Teil der Verantwortung trägt. Diese für ihn notwendige Absicherung führt nicht zu einer Integration, sondern zu einer Abschottung. Eine rein werkvertragliche Gestaltung eines Projektvertrags scheint gene- 33 rell problematisch, da ein Softwareanbieter für bestimmte Projektbereiche keine Verantwortung übernehmen kann, etwa für die Umsetzung organisatorischer Änderungen, die bei keinem Projekt ausbleiben: Jedes neue System hat zwangsläufig die Änderung oder Neustrukturierung von Geschäftsprozessen zur Folge. Auch vor dem Hintergrund des praktischen Projektmanagements – ohne das kein Projekt erfolgreich sein kann – führt eine eindeutige Risikozuweisung nicht zum Ziel. Ein Vertrag ist ein Element für die erfolgreiche Abwicklung eines Projekts, aber nicht das einzige und wohl auch nicht das entscheidende. Anwender greifen auf die Vorteile des Werkvertrags typischerweise zurück, wenn das Projekt notleidend ist, und berufen sich in Schieflagen darauf, dass sie keine oder kaum Verantwortung haben. Solange das Projekt allerdings in ihrem Sinne läuft, nehmen sie die Steuerung gern in die Hand. Für den Projekterfolg wird es im Regelfall mehr auf das Projektmanagement ankommen als auf den Vertragstyp. Bei der Vertragsgestaltung sollten die Vertragspartner folglich darauf achten, dass sich die vertraglichen Regelungen zur Zuweisung der Verantwortung mit den Ansätzen des praktischen Projektmanagements vereinbaren lassen.

III. Aufgaben des Projektmanagements 1. Überblick über die Aktivitäten des Projektmanagements Zum Projektmanagement1 gehören insbesondere die Planung, Steuerung 34 und Durchführung sowie Überwachung des Projekts, einschließlich der erforderlichen Maßnahmen zur Qualitätssicherung, Projekt- und Ergebnisdokumentation aller Projektschritte. Die Planung legt fest, was zu tun ist und wie lange die Beteiligten dafür voraussichtlich brauchen. Die Steuerung und Durchführung sorgt dafür, dass der festgelegte Plan umgesetzt wird. Die Überwachung umfasst die Prüfung der Durchführung unter Berücksichtigung der Planung und deren Anpassungen, sofern Abweichungen erforderlich sein sollten. Das Projektmanagement hat vor allem folgende Aufgaben abzudecken:

35

– Das Projektmanagement plant, kontrolliert und steuert die projektinternen Tätigkeiten. – Das Projektmanagement bildet die Schnittstelle zu projektexternen Einheiten.

1 Berkun, Die Kunst des IT-Projektmanagements, 2. Aufl. 2009.

Witzel

801

H Rz. 36

Sonderregelungen

– Dem Projektmanagement obliegt die Aufgabe eines Projektrepräsentanten. – Das Projektmanagement bildet das Informationszentrum des Projekts. 36 Die Aufgaben sind darauf ausgerichtet, die von den Vertragspartnern definierten Projektziele zu erreichen. Das bedeutet regelmäßig, dass das Projektmanagement dafür zu sorgen hat, dass eine bestimmte Leistung innerhalb eines festgelegten Terminrahmens sowie innerhalb eines festgelegten maximalen Kostenrahmens erbracht wird. Das magische Dreieck des Projektmanagements bewegt sich folglich zwischen den Parametern Kosten, Termine und Leistung. 37 Projektmanagement begleitet jedes IT-Projekt während der gesamten Laufzeit, wobei zahlreiche strategische und operative Aktivitäten erforderlich sind1 und die konkrete Aufgabenstellung von der Art und Komplexität des Projekts abhängt. Beispielhaft ist folgende Aufgabenklassifizierung: Management-Aufgaben Teil-Aufgaben im IT-Projektmanagement in IT-Projekten Strategische Planung

Generierung und Beurteilung von Projektideen (Erarbeitung von Projektsteckbriefen) Bewertung und Einordnung von Projektvorschlägen Projektdefinition und Projektbeantragung Wirtschaftlichkeitsanalysen zum IT-Projekt (Business Case, ROI) Projektbeauftragung (Erteilung der Projektgenehmigung und vertragliche Vereinbarung) Risikoanalyse und Planung der Maßnahmen Umfeldanalyse und Planung der Umfeldbeziehungen (Stakeholderanalysen) Visionen für die Projektarbeit Erarbeitung eines Vorgehensmodell-Plans

Operative Planung

Ablaufplanung Planung der Arbeitspakete Terminplanung Ressourcenplanung Kostenplanung Finanzplanung Qualitätsplanung

1 S. Tiemeyer, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 7.

802

Witzel

Projektmanagement

H

Rz. 37

Management-Aufgaben Teil-Aufgaben im IT-Projektmanagement in IT-Projekten Systementwicklung/ Implementierung

Anforderungserhebung Systemdesign Entwicklung/Customizing Test und Implementation Einführung

Organisation und Kommunikation

Rollendefinition für die Projektarbeit Verteilung von Aufgaben, Befugnissen und Verantwortung auf ausgewählte Personen Gestaltung des Informationsflusses (Projekt-Informationssystem, Berichtswesen, Sitzungsmanagement, Projektdokumentation) Gestaltung der Kommunikation im Projektteam und im Projektumfeld Informationsgestaltung Projektmarketing Schnittstellenmanagement Vereinbarung von Werten, Normen und Regeln für die Projektarbeit (Projektkultur)

Projekt-Controlling

Integrierte Steuerung von Qualität, Terminen, Ressourcen, Kosten, Finanzmittel Durchführung von Reviews Maßnahmenplanung zur Steuerung Verfolgung der Entwicklung kritischer Erfolgsfaktoren/ Risiken Anordnung korrektiver Maßnahmen Melde- und Berichtswesen

Teamführung

Mitarbeiterauswahl/Teambildung Absicherung von Zielklarheit und Zielakzeptanz Förderung der Personalentwicklung bei den Teammitgliedern Förderung der Zusammenarbeit der Teammitglieder (Motivation, Coaching, Konfliktbehandlung) Initiierung von Veränderungen Schaffung förderlicher Rahmenbedingungen

Witzel

803

H Rz. 38

Sonderregelungen

Management-Aufgaben Teil-Aufgaben im IT-Projektmanagement in IT-Projekten Herbeiführen von Entscheidungen Teamauflösung Aufbau und Pflege von Teamkultur

38 Eine vertragliche Formulierung der Aufgaben der Projektmanager könnte wie folgt lauten:

(1) Das Projektmanagement umfasst folgende Bereiche: – Planung, Steuerung und Kontrolle des Projekts. – Gewährleistung von Projektreporting und Projektkommunikation. – Überwachung des Projektfortschritts und Einleitung eventuell notwendiger Eskalationsmaßnahmen. – Problem- und Konfliktlösung. – Change Management und Vorbereitung von Entscheidungsgrundlagen für den Lenkungsausschuss. (2) Auftragnehmer und Auftraggeber benennen jeweils einen Projektmanager (ggf. den fachlichen und einen technischen auf Seiten des Auftraggebers) sowie deren Stellvertreter. Die Projektmanager der Vertragspartner sind zur Abgabe und Annahme von Erklärungen für den jeweiligen Vertragspartner berechtigt bzw. werden entsprechende Entscheidungen herbeiführen. (3) Der Projektmanager des Auftragnehmers hat folgende Aufgaben: – Management und Kontrolle des Projektumfangs. – Erstellen und Pflege eines Projektcontrollings. – Organisation und Durchführung von wöchentlichen Projektmeetings einschließlich Protokollierung. – Errichtung und Einhaltung des Arbeitsplanmanagements und der Zeiterfassung. – Lösung von Konflikten und Sicherstellung eines adäquaten Konflikt-Management-Prozesses. – Identifikation von Risiken und Durchführung einer angemessenen Strategie zur Risikominimierung. – Analyse von Qualitätsmetriken, Identifizierung und Umsetzung von Verbesserungsinitiativen. – Pflege der Beziehungen mit Sponsoren und wichtigen Mitarbeitergruppen beim Kunden. – Kontrolle der Bedürfnisse von Projektmitarbeitern und Gewährleistung eines angemessenen Demand-Managements.

804

Witzel

Projektmanagement

H

Rz. 39

– Sicherstellung der Kommunikation zum Lenkungsausschuss. – Handhabung von Change Requests, die während des Projekts entstehen. (4) Der Projektmanager des Auftraggebers hat folgende Aufgaben: – Erstellen und Pflege des übergreifenden Gesamtprojektplans. – Erstellen und Pflege eines Kommunikationskonzepts und -plans. – Gewährleistung der Kommunikation mit den Fachabteilungen des Auftraggebers. – Erstellen und Pflege eines auf den Projektplan des Auftragnehmers abgestimmten Ressourcenplans. – Sicherstellung der Einbindung der Mitarbeiter aus allen Fachabteilungen des Auftraggebers. – Organisation und Sicherstellung der Teilnahme der Mitarbeiter des Auftraggebers an den Workshops. – Teilnahme an wöchentlichen Projektmeetings und Unterzeichnung des dazugehörigen Protokolls. – Bereitstellung, Betrieb und Management der technischen Infrastruktur gemäß Ziffer __. – Sicherstellen von Abnahmen bezüglich des Pflichtenhefts. – Erstellen und Bereitstellung der erforderlichen Projektmanagement-Tools für die Erfassung offener Punkte, die Meldung von Fehlern. – Organisation der Schulung aller Projektbeteiligten. – Herbeiführung erforderlicher Entscheidungen des Managements des Kunden. – Management offener Punkte und zu klärender Themen.

2. Bestandteile eines erfolgreichen Projektmanagements a) Erfüllung der Stakeholdererwartungen Als Stakeholder1 bezeichnet man jede Person oder Organisation, deren Inte- 39 ressen durch den Verlauf oder das Ergebnis betroffen sind2. Beispiele für Stakeholder sind die Geschäftsleitung, die Projektteams, von einem Projekt betroffene Organisationseinheiten und Entscheidungsträger. Das Projektmanagement hat die Aufgabe, die Erwartungen der Stakeholder an das Projekt soweit wie möglich zu erfüllen. Um diese Erwartung erfüllen zu können, bedarf es als Teil des Projektmanagements des sog. Stakeholdermanagements, das mit einer Analyse der jeweiligen Interessengruppen be1 Der Begriff „stake“ kann mit Spieleinsatz, Anteil, Anspruch übersetzt werden. „Holder“ wird mit Inhaber, Besitzer übersetzt. Für den Stakeholder steht also sein Einsatz (ggf. sein Anspruch) auf dem Spiel. 2 Melbinger, in: Tiemeyer (Hrsg.) Handbuch IT-Projektmanagement, 2010, S. 589 ff.

Witzel

805

H Rz. 40

Sonderregelungen

ginnt. Bei dieser Analyse sind die Einstellung zum Projekt (positiv, negativ, neutral, ambivalent), Macht und Einfluss des jeweiligen Stakeholders, Konfliktpotential sowie Erwartungen und Befürchtungen (sowohl an das Projektergebnis als auch an den Projektverlauf) zu ermitteln. Auf Basis einer solchen Analyse ist festzustellen, welche Stakeholder ein Projekt unterstützen bzw. opponieren. Für die Ableitung von wirkungsvollen Strategien und Maßnahmen gegen Widerstände der Stakeholder ist sowohl eine vollständige Erfassung der Stakeholder als auch eine umfassende Auseinandersetzung mit deren Interessen und Standpunkten erforderlich. b) Planung und Strukturierung 40 Der Planungsprozess1 dient der Erarbeitung eines Projektfahrplans und soll die Frage beantworten: Wie lange wird es dauern, bis wir über diverse Zwischenstationen das Ziel erreicht haben? Bei der Planung werden künftige Entwicklungen prognostiziert, der Planer setzt Prämissen und macht Annahmen über Abhängigkeiten und Wirkungsgefüge. Die Projektplanung versucht den Projektverlauf theoretisch vorwegzunehmen. Ihre Leistung liegt darin, Komplexität überschaubar und handhabbar zu machen. Planen heißt den Weg zum Projektziel vorzuzeichnen. Darüber hinaus besteht die Aufgabe der Projektplanung darin, die vielfältigen Elemente eines Projekts zu ordnen und festzulegen, – welche Tätigkeiten (Arbeitspakete); – durch wen (verantwortliche Person, Gruppe, Unterauftragnehmer); – wann (Start- und End-Termin mit Abhängigkeiten); – mit welchen (zusätzlichen) Ressourcen (Personal, Sachmittel); – zu welchen Kosten; während der Projektdurchführung abgewickelt werden (Strukturierung)2. Alle geplanten Aktivitäten sollen schrittweise zum Projektziel hinführen. c) Informations- und Wissensmanagement 41 Ein strukturiertes Informationsmanagement3 ist die Basis für eine gute Projektdokumentation und somit für eine ausreichende Wissensbasis. Informationsversorgung hat einen direkten Einfluss auf das Erreichen der Ziele eines Projekts. Ineffiziente Kommunikation verzögert Termine und erhöht Kosten. Missverständnisse zwischen den Projektbeteiligten aufgrund falscher Informationen beeinträchtigen die Qualität der Arbeitsergebnisse.

1 Bertolt Brecht: „Ja, mach nur einen Plan, sei nur ein kluges Licht, und dann mach noch’nen zweiten Plan, geh’n tun sie beide nicht.“ 2 Litke, in: Tiemeyer (Hrsg.) Handbuch IT-Projektmanagement, 2010, S. 175 ff. 3 Bauer/Hauptmann, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 561 ff.

806

Witzel

Projektmanagement

Rz. 44

H

d) Aufwandsschätzung Mit einer der häufigsten Gründe für das Scheitern eines Projekts ist die 42 Überschreitung geplanter Budgets, was in Teilen auch auf unzureichende Aufwandsschätzungen1 zurückzuführen ist.

IV. Grundlagen für die erfolgreiche Projektabwicklung 1. Vorgehensmodelle a) Begriff und Bedeutung für die Vertragsgestaltung Für den Begriff „Vorgehensmodell“2 gibt es keine einheitliche Definition: 43 Es geht im Wesentlichen um die zeitlich logische Folge von Schritten in einem Problemlösungsprozess. Das Vorgehensmodell „sollte den Gesamtablauf von einer ganzheitlichen Zielentwicklung über Vorstudie, Systemauswahl und Festlegung der Projektrahmenbedingungen im engeren Sinn planbar und aushandelbar machen. Ein Vorgehensmodell sollte weiterhin die einzelnen Projektphasen so auslegen, dass einerseits jede Phase ein verwertbares, praktisches Ergebnis produziert, anderseits eine qualitative und quantitative Steuerung des Gesamtprozesses möglich wird.“3 Der Umfang von Vorgehensmodellen kann sehr unterschiedlich sein, von einer halben DIN A4-Seite bis zu mehreren hundert Seiten. Ein Vorgehensmodell – steuert das Denken und die Anwendung von Prinzipien; – bestimmt, welche Methoden und Techniken wann zum Einsatz kommen; – unterteilt das Vorgehen in grundsätzliche, sinnvolle, überschaubare und kontrollierbare Etappen; – legt die sachlogische Reihenfolge und Inhalte dieser Etappen fest. Man kann Vorgehensmodelle in folgende Familien einteilen4:

44

– sequentiell/phasenorientiert (Phasenkonzept/Phasenmodell, Wasserfall, Schleifenmodell); – wiederholend (inkrementell, evolutionär, iterativ [„spiralförmig“], rekursiv); – prototypisch; – wiederverwendungsorientiert; – leichtgewichtig („agil“). 1 Sneed, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 267 ff. 2 Dazu im Detail Bunse/von Knethen, Vorgehensmodelle Kompakt, 2. Aufl. 2008; Brugger, IT-Projekte strukturiert realisieren, S. 139 ff.; Vieweg 2003; Jäger u.a., Begutachtung und rechtliche Bewertung von EDV-Mängeln, S. 18 ff.; Krcmar, Informationsmanagement, S. 185 ff.; Siedersleben, Softwaretechnik. 3 Koch, Computervertragsrecht, Rz. 1086. 4 Bunse/von Knethen, Vorgehensmodelle Kompakt, 2. Aufl. 2008.

Witzel

807

H Rz. 45

Sonderregelungen

45 Das sequentielle Paradigma bezeichnet ein sequentielles Vorgehen mit klar definierten Phasen. Die bekanntesten Vorgehensmodelle, die diesem Paradigma folgen, sind das Wasserfall-Modell und das V-Modell. Das iterative Paradigma heißt, dass ein Entwicklungsprozess mehrfach initiiert wird. Es wird nicht nur ein Wasserfall durchlaufen, sondern es werden kleine Wasserfälle hintereinander gesetzt. Bekannteste Modelle sind das Spiral-Modell und der Rational Unified Process (RUP). Das agile Paradigma ist eine Weiterentwicklung des iterativen Paradigmas, bei der die Planung der Iterationen dynamisch erfolgt. Diesem Paradigma folgen die Vorgehensmodelle Extreme Programming (XP) und SCRUM. 46 Warum ein Vorgehensmodell? Es hat den Vorteil, dass der Ablauf des Projekts für alle Projektbeteiligten dokumentiert und nachvollziehbar ist1. Welche Relevanz hat ein Vorgehensmodell für die vertragliche Gestaltung? Anhand des Vorgehensmodells lassen sich auch die einzelnen Leistungen bestimmen, die von Softwareanbieter und -anwender im Verlauf von Anpassung, Einführung und Implementierung zu erbringen sind. Damit steht das Pflichtenprogramm der Vertragspartner fest, das wiederum Maßstab für die Bewertung der vertragsgemäßen Leistung beider Seiten ist. Des Weiteren liegen in der Projektstruktur die wesentlichen vertraglichen Ansatzpunkte, um ein Projekt steuern und überwachen zu können. In vielen Fällen ist nicht klar, welche Stufen eines Projekts vergütungs-, abnahme-, und/oder übergabepflichtig sind oder wann ein Projekt gescheitert ist: Ohne klare Festlegung von Projektschritten ist nur schwer durchsetzbar, dass bei Vertragsbeendigung die erzielten Stufen/die erreichten Ergebnisse zu übergeben und zu vergüten sind2. 47 Die Frage des Vorgehens innerhalb eines Projekts ist nicht nur ein Thema für das operative Geschäft, sondern auch für die rechtlichen Aspekte. Während Vorgehensmodelle, die dem sequentiellen Paradigma folgen, noch verhältnismäßig einfach mit werkvertraglichen Strukturen in Einklang gebracht werden können, ist dies bei iterativem und agilem Paradigma wesentlich schwieriger. Das Herstellungsrisiko lässt sich bei diesen Prozessen nicht einseitig dem Softwareanbieter zuweisen. Die vertragliche Gestaltung sollte jedoch dem von den Vertragspartnern gewählten Vorgehensmodell Rechnung tragen und nicht durch eine einseitige Gestaltung (egal in welche Richtung) versuchen, vermeintlich rechtliche Sicherheit für die Vertragspartner zu schaffen, wenn auf operativer Ebene nicht die Voraussetzungen geschaffen sind, um diese (angebliche) rechtliche Sicherheit zu leben. 1 Das Vorgehensmodell ist nicht gleichzusetzen mit der Projektplanung: Das Vorgehensmodell ist das Ergebnis einer fundierten methodischen Analyse der Aufgabenstellung, woraus ein sinnvolles Raster für die Bewältigung eines bestimmten Aufgabentyps hervorgeht. Der Projektplan hingegen zeigt die inhaltlichen Aspekte eines konkreten Projekts im zeitlichen Kontext, s. Brugger, IT-Projekte strukturiert realisieren, S. 142 ff. 2 OLG München v. 3.2.1999 – 7 U 1892/98, DB 1999, 1057; BGH v. 7.3.1990 – VIII ZR 56/89, CR 1990, 707.

808

Witzel

Projektmanagement

Rz. 50

H

b) Einzelne Vorgehensmodelle: Klassisches Phasenmodell, Wasserfall, V-Modell, Agile Programmierung aa) Klassisches Phasenmodell Das Phasenmodell1 ist eine Technik, die den gesamten Prozessablauf von 48 der Entwicklung selbst bis zur anschließenden Nutzung des Systems in zeitlich-logische Phasen gliedert: In der Regel wird davon ausgegangen, dass jede Phase abgeschlossen und überprüft sein muss, bevor die Folgende in Angriff genommen wird2. Die Idee des Phasenmodells ist es, dass mit der Ausführung nicht eher begonnen wird, als die Spezifikationen (1) vollständig, (2) widerspruchsfrei und (3) eindeutig vorliegen. Nach jeder Phase steht eine Qualitätssicherung. Erst nach erfolgreichem Abschluss der Qualitätssicherung ist die nächste Phase freigegeben. Allgemein kann festgelegt werden, dass jede Phase aus folgenden Abschnitten besteht: – – – –

Planung; Durchführung; Überprüfung und Qualitätssicherung; Dokumentation des Ergebnisses/Prozesses.

Das Phasenmodell folgt folgenden Grundsätzen:

49

– Projektphasen verlangen ein definiertes Ergebnis am Ende, das geplant, aber vor allem auch kontrolliert werden kann. – Projektphasen sind die oberste Ebene und damit eine wichtige Grundlage für die Vertragsbeziehungen zwischen den Projektbeteiligten. – Die Kommunikation nach außen ist einfacher, wenn die Vertragspartner einen Namen für die aktuelle Projektphase haben. Es ist leichter, Fortschritte nach außen zu kommunizieren. – Projektphasen lassen sich relativ einfach mit Budgets, Terminen und anderen Kerngrößen im Projektmanagement verbinden. – Die gängigen Projektphasen sind gemeinhin bekannt und gebräuchlich und man kann Projekte in Grenzen miteinander vergleichen. Das Phasenmodell hat sich als bewährte Methode etabliert, meist in modifizierten Varianten: Die Vorgehensweisen innerhalb eines Phasenmodells sind je nach Vorlieben, Art und Umfang des Projekts unterschiedlich. Die Art der Phasengliederung ist wesentlich von der Art eines Projekts und dessen Komplexität bestimmt. Es gibt kein allgemeingültiges Phasenmodell. 1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009, S. 518 ff. Zu den verschiedenen Vorgehensmodellen s. Brugger, IT-Projekte strukturiert realisieren, S. 142 ff.; Jäger u.a., Begutachtung und rechtliche Bewertung von EDV-Mängeln, S. 18 ff. 2 Hier liegt aber eine der „Hauptprojektsünden“: Selbst wenn das Projekt in der Theorie strukturiert ist, wird diese Struktur in der Praxis nicht gelebt: beispielsweise wird mit der Realisierung bereits begonnen, obwohl die fachlichen Anforderungen des Anwenders noch nicht abschließend festgelegt sind.

Witzel

809

50

H Rz. 51

Sonderregelungen

51 An Phasenmodellen wird häufig kritisiert, dass es sich um eine Idealisierung der Wirklichkeit handelt, dass es bei der praktischen Durchführung immer wieder Rücksprünge in frühere Phasen gibt und dass die Aktivitäten der einzelnen Phasen am Ende dann doch wieder parallel und nicht sequentiell durchgeführt werden. Generell ist das Phasenmodell nur dann geeignet, wenn der Anwender seine Anforderungen an die zu realisierende Software vollständig und endgültig vorgeben kann. bb) Wasserfall-Modell 52 Auch das Wasserfall-Modell1 ist ein lineares sequentielles Vorgehensmodell, das in Phasen organisiert wird. Dabei gehen die Ergebnisse einer Phase immer als bindende Vorgabe in die nächsttiefere Phase ein. Jede Phase des Wasserfall-Modells hat vordefinierte Start- und Endpunkte mit definierten Ergebnissen. Der Name Wasserfall ergibt sich aus der häufig gewählten graphischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen. Erweiterungen des einfachen Wasserfall-Modells (mit Rücksprung) führen iterative Aspekte ein und erlauben ein schrittweises „Aufwärtslaufen“ der Kaskade, sofern in der aktuellen Phase etwas schief läuft. Charakteristika des Wasserfallmodells sind, dass jede Aktivität in der richtigen Reihenfolge und in der vollen Breite vollständig durchzuführen ist. Der Entwicklungsablauf ist sequentiell, d.h. jede Aktivität muss beendet sein, bevor die nächste anfängt. Am Ende jeder Phase soll ein fertiggestelltes Dokument stehen. Die Beteiligung des Anwenders ist nur in der Definitionsphase vorgesehen, anschließend erfolgen Entwurf und Entwicklung ohne Beteiligung des Anwenders. cc) V-Modell 53 Neuere Modelle für die Projektabwicklung gehen nicht mehr von in sich geschlossenen Phasen aus, sondern von Abläufen, bei denen die klassischen Phasen lediglich in kleineren Teilbereichen vorkommen. Das Vorgehensmodell des öffentlichen Bereichs wird in Literatur und Praxis kurz als V-Modell2 bezeichnet3. 1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009, S. 519 ff. 2 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009, S. 554. 3 Ursprünglich entstand das V-Modell aus den beiden 1986 durch den Bundesminister für Verteidigung in Auftrag gegebenen Projekten „Softwareentwicklungsumgebung für Informationssysteme“ und „Softwareentwicklungsumgebung für Waffen und Waffeneinsatzsysteme“, die mit ihren Ergebnissen die Softwareentwicklung und -pflege in der Bundeswehr standardisieren sollten. 1992 wurde das V-Modell vom Bundesministerium des Inneren für den zivilen Verwaltungsbereich übernommen. Seitdem existiert ein einheitlicher Standard für alle Softwareprojekte des öffentlichen Bereichs. Nunmehr wurde das so genannte V-Modell XT für Softwareprojekte der Bundesbehörden als verbindlich vorgegeben, s. dazu www.kbst.bund.de.

810

Witzel

Projektmanagement

Rz. 57

H

Das V-Modell regelt die Softwarebearbeitung durch die einheitliche und 54 verbindliche Vergabe von Aktivitäten und Produkten (Ergebnissen), die bei der Softwareerstellung und den begleitenden Tätigkeiten für Qualitätssicherung, Konfigurationsmanagement und technisches Projektmanagement anfallen. Das V-Modell gliedert sich in vier Tätigkeitsbereiche, die Submodelle – – – –

PM Projektmanagement; KM Konfigurationsmanagement; QS Qualitätssicherung; SE Systemerstellung.

Verifikation und Validation sind Bestandteile des V-Modells. Unter Verifika- 55 tion versteht man im V-Modell die Überprüfung der Übereinstimmung zwischen einem Softwareprodukt und seiner Spezifikation. Die Validation ist die Eignung des Softwareprodukts für seinen Einsatzzweck. dd) Prototypen-Modell Das Prototypen-Modell1 unterstützt auf systematische Weise die frühzeiti- 56 ge Erstellung ablauffähiger Modelle (Prototypen) des zukünftigen Produkts, um die Umsetzung von Anforderungen und Entwürfen in Software zu demonstrieren und mit ihnen zu experimentieren. Wesen des Prototypen-Modells ist eine Entwicklung, die zu schnellen Ergebnissen führt, damit Änderungswünsche und Probleme in der Entwicklung frühzeitig erkannt werden und mit weniger Aufwand zu beheben sind als nach der kompletten Fertigstellung. Prototypen gibt es in unterschiedlichen Varianten: – Demonstrationsprototyp (dient zur Auftragsakquise); – Prototyp im engeren Sinne (provisorisches, ablauffähiges Softwaresystem); – Labormuster (dient dazu, konstruktionsbezogene Fragen und Alternativen zu beantworten); – Pilotsystem (dient nicht nur zur experimentellen Erprobung, sondern ist der Kern des Produkts); – horizontaler Prototyp (realisiert nur spezifische Ebenen des Systems wie die Benutzeroberfläche oder funktionale Kernebenen); – vertikaler Prototyp (realisiert ausgewählte Teile des Systems durch alle Ebenen). Für den erfolgreichen Einsatz eines Prototypen-Modells sollten folgende Vo- 57 raussetzungen vorliegen2: – Es muss ausreichendes Wissen über das Anwendungsgebiet vorliegen. 1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009, S. 537 ff. 2 Kieback et al, Prototyping in industriellen Softwareprodukten, Informatik-Spektrum (1992) 15. 1992, S. 65.

Witzel

811

H Rz. 58

Sonderregelungen

– Auf Basis schriftlicher Dokumente kann kein Prototyp erstellt werden. Die Entwickler müssen Zugang zu den Nutzern haben. – Die Beteiligung der Nutzer ersetzt nicht die kreativen Ideen und Lösungsvorstellungen der Entwickler. – Alle an der Entwicklung beteiligten Personengruppen müssen in direktem Kontakt stehen. – Prototypen müssen in richtigem Umfang dokumentiert werden. – Die Vorgehensweise hängt von der untersuchten Fragestellung ab. – Geeignete Werkzeuge müssen vorhanden sein. 58 Beim Einsatz eines Prototypen-Modells kann das Entwicklungsrisiko reduziert werden. Die starke Rückkopplung zwischen den Nutzern und den Entwicklern kann Enttäuschungen in einem späten Stadium der Entwicklung verhindern. Eine klare Verantwortungszuweisung an einen der beteiligten Vertragspartner ist beim Prototypen-Modell schwierig. Werkvertragsrecht scheint mit diesem Modell nicht vereinbar zu sein; der Dienstvertrag wäre passender, nimmt aber ggf. den Anwender zu weit in die Pflicht1. ee) Spiralmodell 59 Das Spiralmodell2 ist einerseits ein Prozessmodell, anderseits ein sog. Metamodell, das hilft, für jede Phase einer Entwicklung das geeignete Prozessmodell auszuwählen. Nach dem Spiralmodell werden für jedes Teilprodukt und für jede Verfeinerungsebene vier zyklische Schritte durchlaufen. Das mehrfache Durchlaufen dieser Schritte wird als Spirale dargestellt. – Schritt 1: – Identifikation der Ziele des Teilprodukts, das erstellt werden soll (Leistung, Funktionalität, Anpassbarkeit). – Ermittlung alternativer Methoden, um das Teilprodukt zu realisieren (Entwurf A, Entwurf B, Wiederverwendung). – Festlegung der Randbedingungen, die bei den verschiedenen Alternativen zu beachten sind (Kosten, Zeit, Schnittstellen usw.). – Schritt 2: – Evaluierung der Alternativen unter Berücksichtigung der Ziele und Randbedingungen. – Ergibt sich aus der Evaluierung, dass es Risiken gibt, Entwicklung einer kosteneffektiven Strategie zur Überwindung der Risiken mit Hilfe von Prototypen, Simulationen oder Benutzerbefragungen.

1 So auch Söbbing, Die rechtliche Betrachtung von IT-Projekten, MMR 2010, 222; Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009, S. 542: „Dem stehen folgende Nachteile gegenüber … Verträge für die Softwareerstellung berücksichtigen meist nicht das Prototypen-Modell …“. 2 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2009, S. 556 ff.

812

Witzel

Projektmanagement

Rz. 61

H

– Schritt 3: – In Abhängigkeit von den verbleibenden Risiken Festlegung des Prozessmodells für diesen Schritt, z.B. evolutionäres Modell, inkrementelles Modell oder sequenzielles Modell. – Ggf. Kombination verschiedener Modelle, wenn dadurch das Risiko minimiert wird. – Schritt 4: – Planung des nächsten Zyklus’ einschließlich der benötigten Ressourcen. Dies beinhaltet auch eine mögliche Aufteilung des Produkts in Komponenten, die dann unabhängig weiterentwickelt werden. – Überprüfung der Schritte 1 bis 3 einschließlich der Planung für den nächsten Zyklus durch die betroffenen Personengruppen oder Organisationen. – Herstellung von Einverständnis über den nächsten Zyklus. Das Spiralmodell ist als risikogetriebenes Modell gekennzeichnet, dessen 60 Ziel es ist, Risiken zu minimieren. Vorteil ist, dass Fehler und ungeeignete Alternativen frühzeitig erkannt werden. Die Entwicklung kann umdirigiert werden, wenn die Erkenntnisse innerhalb eines Zyklus’ dies erfordern. Auch beim Spiralmodell kann das ausschließliche Herstellungsrisiko nicht beim Softwareanbieter liegen. Die Verantwortlichkeit kann innerhalb der einzelnen Zyklen wechseln. ff) Agile Vorgehensmodelle Agile Softwareentwicklung1 ist der Oberbegriff für den Einsatz von Agilität 61 in der Softwareentwicklung. Die agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand und wenigen Regeln auszukommen. Im Unterschied zu klassischen Vorgehensmodellen sollen Entwicklungsprozesse schlanker und flexibler werden. Das sog. agile Manifest wurde 2001 von 17 Softwareentwicklern und IT-Projektmanagern verfasst. Der Grundgedanke des agilen Manifests ist, dass die Menschen, die Software entwickeln, im Mittelpunkt stehen und bei ihrer Arbeit den Auftraggeber umfassend einbinden, um schnell und flexibel auf Änderungsanforderungen reagieren zu können. Die vier Grundprinzipien des „Manifesto for Agile Software Development“ sind: – Menschen und Interaktionen bedeuten mehr als Prozesse und Werkzeuge. – Lauffähige Software ist wichtiger als umfangreiche Dokumentation. 1 Auer-Reinsdorff, Feststellung der versprochenen Leistung beim Einsatz agiler Projektmethoden, ITRB 2010, 93; Frank, Bewegliche Vertragsgestaltung für agiles Programmieren, CR 2011, 138; Koch, Agile Softwareentwicklung – Dokumentation, Qualitätssicherung und Kundenmitwirkung, ITRB 2010, 114; Kremer, Gestaltung von Verträgen für die agile Softwareerstellung, ITRB 2010, 283; Schneider, „Neue“ IT-Projektmethoden und „altes“ Vertragsrecht, ITRB 2010, 18.

Witzel

813

H Rz. 62

Sonderregelungen

– Zusammenarbeit mit den Auftraggebern zählt mehr als Vertragsverhandlungen. – Reagieren auf Veränderungen ist wichtiger als das sture Befolgen eines Plans. 62 Agile Modelle lassen sich in etwa wie folgt charakterisieren1: – Sie versuchen, einen Kompromiss für das Dilemma zu finden, entweder keinen strukturierten Prozess oder zu viele Prozesse zu implementieren. – Es werden möglichst wenig Dokumente gefordert; im Extremfall ist der Sourcecode das Dokument. – Es wird iterativ entwickelt: Häufig werden lauffähige Versionen des Zielsystems ausgeliefert, die jeweils eine Teilmenge der ermittelten Anforderungen enthalten. – Stabile Pläne sind Pläne für kurze Zeiträume und werden jeweils für eine Iteration gemacht. 63 Agile Vorgehensmodelle bilden auch einen Gegentrend zu den klassischen, immer komplexer werdenden Vorgehensmodellen. Es ist allerdings bislang nicht klar definiert, wann sich ein Vorgehensmodell agil nennen darf und was genau agile Entwicklung ist. Die bekanntesten Vertreter agiler Projekte sind Extreme Programming, Scrum, Crystal, Dynamic Systems Development Method (DSDM) und Feature Driven Development (FDD). 64 eXtreme Programming (XP)2 ist ein objektorientiertes Vorgehensmodell, dessen Grundprinzip die sog. Leichtgewichtigkeit ist. Dies bedeutet die rasche Entwicklung eines ausführbaren Systems mit einem Minimum an flankierenden Maßnahmen wie z.B. Modellierung sowie die rasche Anpassbarkeit des Vorgehensmodells. Im Vordergrund von XP steht der Teamgedanke, wobei das Modell davon ausgeht, dass alle Personen, die zum Gelingen des Projekts beitragen, an einem Ort bzw. in einem Raum zusammensitzen. Der Auftraggeber wird in das Team integriert und soll mit dem Team vor Ort an der Problemlösung mitwirken. Seine Aufgaben liegen in der Bereitstellung der „User Stories“ (Anforderungen), der Spezifikation der dazu gehörigen Akzeptanztests sowie der Beantwortung auftretender Fragen der Teammitglieder des Softwareanbieters. Die Programmierung erfolgt in Paaren und folgt dem Ansatz des sog. Test Driven Development, was bedeutet, dass vor dem Beginn der eigentlichen Programmierung ein Testfall definiert wird. Der entwickelte Sourcecode muss den Testfall/die Testfälle erfüllen. Das XP-Modell besteht aus zwei Phasen: In der Planungsphase werden die Anforderungen ermittelt und dokumentiert. Dann folgt eine 1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2008, S. 651. 2 Bunse/von Knethen, Vorgehensmodelle Kompakt, 2. Aufl. 2008, S. 115 ff.; Eckkrammer/Gollner, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 92 ff.; Roock/Lippert, eXtreme Programming: eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis, 2. Aufl. 2005.

814

Witzel

Projektmanagement

Rz. 67

H

zweite Phase der iterativen Realisierung, wobei der ausführbare und testbare Sourcecode im Vordergrund steht. XP gilt als geeignetes Vorgehensmodell für Projekte mit sehr kurzer Entwicklungszeit und Umsetzung instabiler Anforderungen (z.B. bei webbasierten Applikationen)1. Die Teamgröße ist auf 10 bis maximal 15 Mitglieder beschränkt. Phasen und Aktivitäten bei XP sehen etwa wie folgt aus:

65

– Planungsphase: Sammlung von User Stories, Erstellung einer prototypischen Architektur, Entwicklung von Testszenarien, Erstellung eines Releaseplans. – Realisierung auf Basis der prototypischen Architektur: Entwicklung von Testfällen für automatisierte Unit Tests sowie Akzeptanztests, Implementierung der User Stories in Programmieraufgaben, Überarbeitung der Architektur, Test der Ergebnisse eines Programmierauftrags, Erfassung von Daten, Durchführung von Akeptanztests. Die Schwierigkeiten, die ein auf XP basierendes Modell bei der Vertrags- 66 gestaltung machen kann, sind schnell erkennbar. Eine werkvertragliche Gestaltung folgt der Idee, dass Leistung des Softwareanbieters klar von der Mitwirkung des Auftraggebers abgegrenzt werden kann. Bei gemischten Teams kann schwer feststellbar sein, wer tatsächlich für welche Aktivität verantwortlich ist. Das rigorose Testen, das bei XP im Vordergrund steht, muss im Verhältnis auf die werkvertraglich vorgesehene Abnahme (richtig) eingeordnet werden. Die erste grundlegende Annahme von SCRUM2 ist die, dass jedes Projekt so 67 komplex ist, dass es sich nicht genau planen lässt, die Projektteams daher nur innerhalb eines groben Rahmens arbeiten können und sich selbst organisieren müssen, um eben diesen groben Rahmen auszufüllen. Wünscht ein Auftraggeber die Durchführung eines Projekts auf Basis von SCRUM und fordert er gleichzeitig feste Termine und Vergütungszusagen, muss er sich fragen lassen, ob eine solche Forderung nicht in einem grundsätzlichen Widerspruch zur ersten grundlegenden Annahme von SCRUM steht. Die zweite Annahme von SCRUM ist die Aufteilung eines Projekts in sog. Sprints. Dabei handelt es sich um Iterationen eines Projekts, die üblicherweise um die 30 Tage dauern und an deren Ende etwas Verwertbares vorliegen muss. Unter dem juristischen Blickwinkel ist die Definition des „Verwertbaren“ schwierig. Die dritte Annahme von SCRUM ist, dass der gesamte Prozess sich im Laufe eines Projekts verbessert. Der Entwicklungszyklus in SCRUM wird durch die Begriffe „Anwenden“ (apply), „Prüfen“ (inspect) und „Anpassen“ (adapt) charakterisiert. Ideen werden iterativ umgesetzt, Ergebnisse kritisch geprüft und Fehler in Produkt und Prozess umgesetzt. Anforderungen werden in einer Liste, dem sog. Product Backlog, gesammelt, beständig gepflegt, aktualisiert, erweitert und priorisiert. Monatlich 1 Bunse/von Knethen, Vorgehensmodelle Kompakt, 2. Aufl. 2008, S. 116. 2 Bunse/von Knethen, Vorgehensmodelle Kompakt, 2. Aufl. 2008, S. 124.

Witzel

815

H Rz. 68

Sonderregelungen

soll ein in Abstimmung der Vertragspartner festgelegtes Arbeitspaket auf Basis der priorisierten Anforderungen umgesetzt (sowie getestet und dokumentiert) werden. c) Beispielhafte Projektphasen 68 Bei Gestaltung und Verhandlung der vertraglichen Grundlagen sollten sich die Verhandlungspartner über das im konkreten Fall gewählte Vorgehensmodell im Klaren sein, um die Leistungen zu definieren, aber auch konkrete Regelungen zu Projektplanung und etwaigen damit verbundenen Sanktionen treffen zu können. Die Vertragspartner sollten sich auch von dem Gedanken verabschieden, dass es ihnen gelingt, eine ausschließliche Verantwortungszuweisung i.S. eines (einzigen) Vertragstyps zu gestalten. Die Darstellung der unterschiedlichen Vorgehensmodelle zeigt deutlich, dass die Verantwortlichkeit in unterschiedlichen Phasen oder Schritten wechseln kann. Beim Prototypen-Modell sowie bei agiler Vorgehensweise ist die klare Abgrenzung nur auf Detailebene möglich. Ein Projektvertrag wird daher am Ende immer Aspekte verschiedener Vertragstypen in sich tragen und je moderner die Vorgehensweise, desto schwerer wird es, den Schwerpunkt im reinen Werkvertrag zu finden1. aa) Variante 1: Klassisches Phasenmodell 69 Projektierung In der Projektierungsphase werden, ausgehend von den Intentionen des Anwenders, die Ziele und Bedingungen des geplanten Vorhabens festgelegt. Aufbauend auf diesen Angaben wird die Planung des Projekts vorgenommen. Fachkonzept Es schließt sich die Fachkonzept-Phase an, in der die in der Projektierung festgelegten Zielsetzungen, Anforderungen und Bedingungen detailliert festgelegt werden. Dabei werden häufig Ergebnisse von durchgeführten IstAufnahmen herangezogen, um eine sinnvolle Ausrichtung des Projekts zu gewährleisten. Als Ergebnis wird ein Lastenheft erarbeitet, das als Basis für die nächsten Phasen dient.

1 Müller-Hengstenberg/Kirn, Die technologischen und rechtlichen Zusammenhänge der Test- und Abnahmeverfahren bei IT-Projekten, CR 2008, 755: „Die vorstehenden Überlegungen zu den softwaretechnischen Spezifika der Softwareentwicklung zeigen sehr deutlich auf, dass es keinen einheitlichen Vertragstyp für alle Leistungen in einem IT Projekt gibt, weil pro Phase die Ergebnisverantwortung im werkvertraglichen Sinn unterschiedlich sein kann. Dies hat zur Folge, dass der Projektvertrag dem Wesen nach ein Kooperationsvertrag zwischen dem Auftraggeber und einem, ggf. auch mehreren Auftragnehmern ist, die alle zusammen für den Erfolg des Projekts und damit für die Erfüllung des Projektvertrags verantwortlich ist.“

816

Witzel

Rz. 70

H

Anhand der fachlichen Vorgaben und des technischen Umfeldes wird Systemkonzept erstellt. Die Aufgaben werden schrittweise genauer schrieben, so dass die fachlichen Anforderungen mit dem zugehörigen sungsweg festgelegt sind. Das hauptsächliche Resultat dieser Phase ist Pflichtenheft.

das beLödas

Projektmanagement

Systemkonzept

Realisierung In dieser Phase wird auf Grundlage des Pflichtenhefts eine Verfeinerung der Verfahrensstruktur vorgenommen. Als wesentliches Ergebnis entsteht das Feinkonzept. Diese Spezifikationen werden entweder im Wege der Parametrisierung oder der ergänzenden Programmierungen umgesetzt. Einführung In der Einführungsphase werden die Voraussetzungen für den einwandfreien und effizienten Ablauf des Produktivbetriebs geschaffen. Wesentlicher Bestandteil dieser Phase ist der Probebetrieb. Am Ende des Probebetriebs sollte eine Abnahme vorgesehen werden. Zu dieser Phase gehören auch Schulungen und ggf. eine Pilotinstallation1. bb) Variante 2: Vier Grobphasen einer SAP R/3-Einführung Projekt Kick-off

70

Der Kick-Off markiert den Start des Einführungsprojekts. Den Mitarbeitern wird der Start des Projekts offiziell verkündet; es wird eine Einteilung in einzelne Teilprojektgruppen vorgenommen. Prozessausgrenzung Die Prozessausgrenzung beschäftigt sich mit der Identifikation der Hauptprozesse. Dazu wird in der Regel in mehreren Gruppensitzungen ein Konsens innerhalb der Projektgruppe hergestellt. Ziel dieser Projektphase ist es, eine scharfe Abgrenzung zwischen den Prozessen zu finden und erste Anhaltspunkte für die notwendige Funktionalität zu sammeln. Prozessmodellierung Die Phase der Prozessgestaltung richtet sich auf die Entwicklung eines detaillierten Soll-Prozessmodells, wobei insbesondere die organisatorische Dimension der Reorganisation von Geschäftsprozessen im Mittelpunkt steht. Software-Einstellung Die Prozessumsetzung in SAP R/3 erfolgt mit Hilfe des SAP R/3-Referenzmodells. Dazu werden zunächst die relevanten Prozesse des Referenzmodells identifiziert, die für die Implementierung der organisatorischen Soll-Prozesse notwendig erscheinen. Anschließend werden die SAP-Refe1 Zu alledem s. Streitz, IT-Projekte retten, S. 23 ff.

Witzel

817

H Rz. 71

Sonderregelungen

renzprozesse um die Varianten bereinigt, die für die Geschäftsprozesse des Unternehmens nicht benötigt werden. Dadurch entsteht ein unternehmensspezifisches Prozessmodell, das bei der organisatorischen Einführung der neuen Geschäftsprozesse zur Dokumentation und Schulung verwendet wird. Gleichzeitig dient dieses Modell als Grundlage für die Einstellungen der SAP ERP-Software1. cc) Variante 3: Phasenmodell für Softwareentwicklung 71 Problemanalyse In dieser Phase sollen Schwachstellen identifiziert und analysiert werden. Ergebnis dieser Phase ist eine Schwachstellenanalyse und ein Projektauftrag. Anforderungsanalyse Die Anforderungen des Auftraggebers werden ermittelt und dokumentiert. Aus den dokumentierten Anforderungen entsteht in Kombination mit der Schwachstellenanalyse das Lastenheft, das von den Fachabteilungen des Auftraggebers „abgenommen“ wird. Spezifikation Auf Basis des Lastenhefts wird ein Lösungsweg zur Umsetzung des Inhalts des Lastenhefts im vom Auftraggeber abzunehmenden Pflichtenheft beschrieben. Prototyp Es erfolgt die Erstellung eines Prototypen. Architektur- und Designentscheidung Die Softwarearchitektur wird ermittelt und dokumentiert. Es werden die notwendigen Entscheidungen für das Design getroffen. Ergebnis ist ein Architekturdiagramm, das ebenfalls abzunehmen ist. Entwicklung Die Software wird entwickelt und vom Softwareanbieter getestet. Test und Abnahme Die Software wird durch den Auftraggeber getestet und abgenommen. Migration Altdaten werden in das neue System übernommen und nach der Übernahme ggf. manuell nachgearbeitet. Die Migration wird vom Auftraggeber abgenommen.

1 Auszüge aus Krcmar, Informationsmanagement, S. 185 ff.

818

Witzel

Projektmanagement

Rz. 72

H

Schulung Anwender und Administratoren des Auftraggebers werden in der Anwendung der neuen Software geschult. Inbetriebnahme Die neue Software wird in der Produktionsumgebung installiert und konfiguriert. Der Auftraggeber gibt zur produktiven Nutzung frei. Begleitende Einführung Die Anwender des Auftraggebers werden betreut, es werden Fehler behoben. 2. Auswahlkriterien für Vorgehensmodelle1 72

Eigenschaften des Projekts Größe des Projekts in Personenmonaten Klein (1 bis 6 Personenmonate)

Mittel (7 bis 12 Personenmonate)

– Prinzipiell ist jedes – Das ausgewählte Vorgehensmodell geVorgehensmodell eignet. muss über Konzepte – Sinnvollerweise werzur Beherrschung den überschaubare von Komplexität und kompakte Moverfügen. delle gewählt. – Wiederholende Vorgehensmodelle empfehlen sich, da die Entwicklung in überschaubaren Zyklen verläuft, die häufige Qualitätsprüfungen ermöglichen.

Groß (ab 13 Personenmonate) Es empfehlen sich rekursive Vorgehensmodelle aus der Familie der wiederholenden Vorgehensmodelle, da sie leicht adaptierbar sind und die Zerlegung des Systems in Inkremente erlauben.

Anzahl der beteiligten Mitarbeiter Klein (1 bis 10 Personen)

Mittel (11 bis 25 Personen)

Groß (26 und mehr Personen)

– Das ausgewählte Vorgehensmodell sollte sich auf Kernaktivitäten konzentrieren. – XP kann eingesetzt werden.

– Empfehlung für ein wiederholendes Vorgehensmodell, das die Verteilung von klar getrennten Aufgaben erlaubt. – Das ausgewählte Vorgehensmodell sollte ausführlich, etwa in Form von Handbüchern, dokumentiert sein.

– Empfehlung für ein wiederholendes Vorgehensmodell, das auch Aktivitäten zur Planung und Kontrolle erlaubt. – Die Verwendung von XP ist nicht zu empfehlen, da geeignete Maßnahmen zur Komplexitätsverwaltung fehlen und das Grundprinzip von XP, das jeder Entwickler auf alle Teile des Systems Zugriff haben soll, sich ggf. nicht realisieren lässt.

1 Nach Geirhos, IT-Projektmanagement, 2011, S. 135.

Witzel

819

H Rz. 72

Sonderregelungen

Arbeiten die Mitarbeiter in verteilten Teams? Ja

Nein

– Empfehlung für ein evolutionäres Modell aus der Familie der wiederholenden Vorgehensmodelle. – Dabei wird ein System in unabhängige Teilsysteme zerlegt, die parallele Entwicklung von Teilsystemen wird unterstützt.

Prinzipiell ist jedes Vorgehensmodell einsetzbar.

Was sind die Prioritäten des Projekts? Auslieferungstag

Funktionalität

Qualität

Gleichwertigkeit von Termin, Funktion und Qualität

– Empfehlung für überschaubare und kompakte Vorgehensmodelle. – Sinnvollerweise ist die gewünschte Funktionalität zu reduzieren. – Wiederholendes Vorgehensmodell.

– Prinzipiell kann jedes Vorgehensmodell gewählt werden. – Das Vorgehensmodell sollte die Ermittlung und Dokumentation von Anforderungen unterstützen. – Es sollte über ausgeprägte Planungsund Steuerungsmechanismen verfügen.

Empfehlung für ein Vorgehensmodell, das Qualitätssicherungsmaßnahmen ausdrücklich vorsieht und diese systematisch definiert.

Evtl. ist ein wiederholendes Vorgehensmodell geeignet, das durch systematisch flankierende Maßnahmen ergänzt wird.

Welcher Art Anwendungsdomäne lässt sich das Projekt zuordnen? Informationssysteme1

Technische Systeme2

– Erfordern Vorge– Das Vorgehenshensmodelle, die die modell sollte expliAbbildung von Gezit und durchgängig schäftsprozessen, die nicht-funktionale Anbindung existieEigenschaften unterrender Drittsysteme stützen. und die Datenmo– Das ausgewählte dellierung unterstütVorgehensmodell zen. sollte Qualittäts– Das Vorgehensmosicherungsmaßnahdell sollte die Ermen unterstützen. mittlung und Doku- – Wiederholende Vormentation von gehensmodelle bieAnforderungen unten sich an. terstützen.

Webbasierte Systeme Agile Vorgehensmodelle bieten sich an.

1 Betriebliches Informationssystem, wie Anwendungen in Bereich Banken, Versicherungen, Öffentliche Verwaltung. 2 Anwendungen im Automobilbereich, der Halbleiterindustrie, dem Anlagenbau und der Robotik.

820

Witzel

Projektmanagement

H

Rz. 72

Eigenschaften des Entwicklungsteams Wie groß ist die Erfahrung des Projektleiters? Gering (Erstes Projekt)

Mittel (einige Projekte) Groß (viele Projekte)

– Ein Vorgehensmodell mit einfacher Abfolge und wohldefinierten Meilensteinen ist geeignet. – Empfehlung für ein sequentielles Vorgehensmodell.

Empfehlung für ein Vorgehensmodell, das umfangreiche Beschreibungsformen und zusätzliche Aktivitäten, etwa zur Qualitätssicherung, vorsieht.

– Erfahrene Projektleiter benötigen keine Unterstützung der ProjektmanagementAktivitäten durch das Vorgehensmodell. – Prinzipiell können alle Vorgehensmodelle zum Einsatz kommen.

Wie hoch ist die Erfahrung der Mitarbeiter bezüglich der Anwendungsdomäne? Gering (noch nie davon gehört)

Mittel (Basiswissen vorhanden)

Groß (täglich angewendet)

– Das Vorgehensmodell sollte auf den Einsatz in der Anwendungsdomäne ausgerichtet sein. – Empfehlung für ein wiederholendes Vorgehensmodell.

– Prinzipiell ist jedes – Empfehlung für ein Vorgehensmodell iteratives Vorgehensmodell. denkbar. – Das Modell sollte – Empfehlung für ein grundsätzliche KonVorgehensmodell zepte für die Anwenauf dem neusten dungsdomäne anbieStand der Technik. ten.

Eigenschaften der Entwicklung Welcher Art ist die Entwicklung? Neuentwicklung (Greenfield Engineering)

Änderung eines existierenden Systems (Re-Engineering)

Prinzipiell ist jedes Vorgehensmodell geeignet.

Empfehlung für ein wiederholendes Vorgehensmodell mit kurzen Zyklen und umfassenden Eingriffsmöglichkeiten.

Welcher Grad an Wiederverwendung wird gewünscht? Keiner

Quellcode

Komponenten

Produktfamilie

Prinzipiell ist jedes Vorgehensmodell geeignet.

Beschränkt sich die Wiederverwendung auf Quellcode, muss ein Vorgehensmodell in der Entwurfs- und Implementierungsphase Wiederverwendung berücksichtigen.

Empfehlung für neuere Vorgehensmodelle, die ein Komponentenparadigma unterstützen.

Empfehlung für ein Vorgehensmodell, das auf Domänenmodellierung sowie die Erfassung, Modellierung und Umsetzung von Variabilitäten eingeht.

Witzel

821

H Rz. 72

Sonderregelungen

Welche Phasen der Entwicklung sollen unterstützt werden? Anforderungsermittlung

OO1Analyse

OOEntwurf

Implementierung

Test

Review/Inspektionen

– Diese Phase wird insbesondere durch User Case-getriebene Vorgehensmodelle unterstützt. – Die Ermittlung nicht-funktionaler Anforderungen wird zur Zeit von keinem Vorgehensmodell unterstützt.

Modellorientierte Vorgehens-Modelle sind geeignet.

Architekturzentrierte Modelle sind geeignet.

Modelle, die sich auf die Implementierung konzentrieren, sind geeignet, z.B. XP oder KobrA.

Empfehlung für Vorgehensmodelle, die früh die Erstellung von Testfällen fordern.

– Reviews und Inspektionen sind manuelle Qualitätsprüfungen und sind nicht auf ausführbaren Quellcode beschränkt. – Nur wenige Vorgehensmodelle, z.B. KobrA, bieten hierfür Unterstützung an.

Eigenschaften der Anforderungen Sind die Anforderungen stabil? Ja

Nein

Jedes Vorgehensmodell – Bei instabilen Anforderungen ist ein proaus der sequentiellen totypisches oder inFamilie ist einsetzbar, 2 krementelles Voretwa OMT . gehensmodell zu empfehlen. – Ein solches Modell erleichtert die Planung und Verwaltung von Änderungen. Werden kundenverständliche Anforderungsdokumente benötigt? Ja

Nein

Vorgehensmodell mit User Case-zentriertem Ansatz sinnvoll.

Jeden beliebige Vorgehensmodell ist denkbar.

Sind demonstrierbare Prototypen notwendig? Ja

Nein

Empfehlung für ein prototypisches Vorgehensmodell.

Jedes beliebige Vorgehensmodell ist anwendbar.

1 OO = objektorientiert. 2 Object Modelling Technique ist eines der am weitesten verbreiteten Vorgehensmodelle im Bereich der objektorientierten Entwicklung, siehe Bunse/von Knethen, Vorgehensmodelle Kompakt, 2. Aufl. 2008, S. 22.

822

Witzel

Projektmanagement

H

Rz. 75

Werden mit dem Anwender Meilensteine vereinbart? Ja

Nein

Empfehlung für ein Jedes beliebige Vorwiederholendes Vorge- gehensmodell ist einhensmodell, das klar setzbar. getrennte Aktivitäten und erste Meilensteine definiert und Aktivitäten zur Planung und zur Kontrolle beinhaltet. Eigenschaften von Änderungen Wie häufig treten Änderungen auf? Selten

Oft

Regelmäßig

Jedes beliebige Vorgehensmodell ist anwendbar.

Sofern die Änderungen in einem Tag umgesetzt werden können, empfiehlt sich ein sequenzielles Vorgehensmodell.

Bei regelmäßigen oder komplexen Änderungen empfehlen sich iterativ-inkrementelle bzw. prototypische Modelle aus der Familie der wiederholenden Vorgehensmodelle, mit kurzen Entwicklungszyklen.

Der Erfolg eines Projekts ist abhängig von einer Vielzahl von Kontextgrö- 73 ßen. Es kommt auf den Erfahrungsgrad der Mitarbeiter, die eingesetzten Werkzeuge und die Organisationsstrukturen der beteiligten Unternehmen an. Nicht jedes Vorgehensmodell kann in jeder Situation eingesetzt werden1. 3. Projektplanung a) Bestandteile der Projektplanung Mit den vorstehend geschilderten Vorgehensmodellen wurden Modelle dar- 74 gestellt, mit denen der ideale Ablauf eines Projekts abgebildet werden kann. Die Projektplanung regelt zum einen die konkrete zeitliche Abfolge eines Projekts und setzt auf dem von den Vertragspartnern ausgewähltem Vorgehensmodell auf. Ein Vorgehensmodell bildet die Rahmenbedingungen für die Projektplanung, die jedoch mehr ist als ein reiner Zeitplan. Projektplanung umfasst die Ablauf- und Terminplanung, aber auch die Aufwandsschätzung und die Finanzplanung, die Ressourcenplanung sowie das Risikomanagement2. Während die Vorgehensmodelle einen allgemeinen Rahmen zur Strukturierung eines Projekts vorgeben, ist Gegenstand einer konkreten Planung zu1 Bunse/von Knethen, Vorgehensmodelle Kompakt, Spektrum, 2. Aufl. 2008, S. 155, 159. 2 Litke, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 175 ff.

Witzel

823

75

H Rz. 76

Sonderregelungen

nächst die Zusammenstellung aller im Verlauf des Projekts zu leistenden Arbeiten, etwa im Rahmen eines Projekt-Struktur-Plans, der eine Übersicht liefert und zentrales Element für die Projektsteuerung sein sollte. Ein Projekt-Struktur-Plan beschreibt, was und nicht wie es zu tun ist. Gegenstand eines Projekt-Struktur-Plans ist es nicht, alle Arbeitspakete in ihrer zeitlichen Reihenfolge darzustellen. Seine Aufgabe ist es vielmehr, alle im Projekt notwendigen Aufgaben zu erfassen und sinnvoll zu strukturieren. Auf Grundlage eines Projekt-Struktur-Plans können dann Ablauf-, Termin-, Ressourcen- und Kostenpläne erstellt werden. b) Ablauf- und Terminplan sowie Aufwandsschätzung 76 Ein Ablaufplan1 ordnet die Liste sämtlicher Arbeiten für die tatsächliche Durchführung. Er soll die logisch und sachlich erforderlichen Abhängigkeiten ermitteln und u.a. folgende Festlegungen treffen: – Welche Arbeitspakete können unabhängig voneinander durchgeführt werden? – Welche Arbeitspakete sind unmittelbare Voraussetzung für ein anderes Arbeitspaket? – Welche Arbeitspakete können unmittelbar auf ein anderes Arbeitspaket folgen? – Welche Aktivitäten lassen sich parallel ausführen? Ein Ablaufplan zeigt die notwendigen Aktivitäten in ihren sachlogischen Abhängigkeiten. 77 Jeder Aktivität des Ablaufplans muss eine geschätzte Zeitdauer zugeordnet werden (Aufwandsschätzung), für die es leider keine exakten Methoden gibt. Gegenstand der Aufwandsschätzung ist die Schätzung, wie viele Personen und wie viel Zeit für ein Arbeitspaket benötigt wird2. Auf Basis eines Ablaufplans und der Aufwandsschätzung kann ein Terminplan erstellt werden. Ein Terminplan ist eine Auflistung aller Aktivitäten mit der geschätzten Dauer sowie den Start- und Endterminen für jede Aktivität. Termine können im Weg einer Vorwärtsrechnung ermittelt werden, d.h. beginnend mit der ersten Aktivität und der geschätzten Dauer für alle Aktivitäten wird 1 Ablauf- und Terminpläne werden regelmäßig graphisch dargestellt, etwa auf Basis von Balkenplantechnik sogenannte GANTT-Diagramme, www.wikipe dia.org. Alternative Darstellung bietet die Netzplantechnik, die ihre Grundlage in der mathematischen Graphentheorie hat. Graphen bestehen aus Knoten und Pfeilen, Netzpläne sind gerichtete Graphen. 2 Die Verbindlichkeit von Schätzungen wird von Vertragspartnern bei der Vertragsgestaltung häufig überschätzt, so Litke, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 195: „Auch bei größter Sorgfalt bleiben die Ergebnisse [einer Aufwandsschätzung] Schätzwerte. Es gibt kein universell einsetzbares und immer korrekte Ergebnisse ablieferndes Schätzverfahren. Dennoch kommen wir in der Tätigkeit der Projektarbeit nicht umhin, den Aufwand zu prognostizieren.“

824

Witzel

Projektmanagement

Rz. 81

H

ein frühestmöglicher Endtermin für das Projekt berechnet. Denkbar ist auch eine Rückwärtsrechnung, die bei der letzten Aktivität beginnt und bis zur ersten Aktivität zurück rechnet. Bei diesen (erneut) theoretischen Berechnungen ist der Kalender (mit Wochenenden, Feiertagen und Ferienzeiten) zu berücksichtigen. Ebenfalls zu berücksichtigen sind Fixpunkte, zu denen bestimmte Aktivitäten abgeschlossen sein müssen. c) Meilensteine Bestandteil eines Terminplans sind Meilensteine. Meilensteine sind vor- 78 definierte Ereignisse, die die Basis für die Kontrolle der zeitlichen Struktur des Projekts und die Effizienz der Mitarbeiter bilden. Meilensteine sollten nur Ereignisse sein, deren Eintreten eindeutig festgestellt werden kann: – Genehmigung/Freigabe/Abnahme für Workshopprotokoll liegt vor; – Pflichtenheft liegt vor; – technisches Umsetzungskonzept liegt vor; – Modul XY wird zur Abnahme bereit gestellt; – Prototyp ist getestet und implementiert. Meilensteine sollten quantitativ und qualitativ kontrollierbar sein. In ihrer Gesamtzahl sollten sie in einem Projekt überschaubar, realistisch formuliert und erreichbar sein. d) Puffermanagement Zur Projektplanung gehört auch das Puffermanagement, das leider häufig zu kurz kommt oder unter den Tisch fällt. Gerade fixe Endtermine sind in der Vertriebsphase beliebtes Druckmittel des Einkaufs oder ein vermeintlich überzeugendes „Verkaufsargument“ für den Vertrieb. Ablauf- und Terminpläne ohne Puffer sind allerdings unrealistisch.

79

4. Rechtliche Aspekte des Projektmanagements a) Vertragsgestaltung zur Unterstützung des Projektmanagements Auch ohne die Diskussion um § 651 BGB und die Sachqualität von Software 80 sind Projekte erheblichen Risiken ausgesetzt. Dies gilt für Projekte, die die Entwicklung einer Individualsoftware zum Gegenstand haben sowie für Projekte, bei denen es um die Anpassung und Implementierung von Standardsoftware geht. Das Gesetz selbst bietet keine ausreichende Fallback-Position mit Steuerungsmechanismen, um diese Spannung zu lösen1. Abhilfe kann nur die vertragliche Gestaltung schaffen, die sich an den Risi- 81 ken im konkreten Einzelfall orientiert und eine ausgewogene Regelung, die

1 S. oben Rz. 25 ff. (Projektverantwortung).

Witzel

825

H Rz. 82

Sonderregelungen

die Interessen beider Vertragspartner berücksichtigt, enthalten sollte1. Um die Risiken in IT-Projekten einigermaßen beherrschbar zu machen, sind auch bei der Vertragsgestaltung Methoden und Vorgehensweisen zu berücksichtigen, die für beide Vertragspartner mehr Sicherheit mit sich bringen. Die Risikoverteilung der gesetzlichen Regelung wird dem nicht gerecht; erforderlich sind: – detaillierte und klare Spezifikationen, sofern dies nach der Eigenart des Projekts möglich ist; – ausführliche Projektplanung; – Risikoanalyse des Projekts (vor dem Projektstart); – begleitendes Qualitätsmanagement; – begleitendes Controlling (laufend); – ausführliche Tests, deren Zeitpunkt sich jeweils am von den Vertragspartnern gewählten Vorgehensmodell orientiert. Wichtig erscheint, dass der Gegenstand des Projekts und das für die Projektdurchführung ausgewählte Vorgehensmodell die Parameter für den Vertrag bestimmen und nicht umgekehrt eine vermeintlich sinnvolle rechtliche Gestaltung dem Vorgehensmodell „übergestülpt“ wird. 82 Zu den vertraglichen Elementen, mit denen ein Projekt gesteuert werden kann, muss Folgendes gehören: – sachliche Bestimmungen über das Leistungsergebnis i.V.m. mit einem Projekt-Struktur-Plan oder Ablaufplan; – Bestimmungen, wie Anforderungen im Einklang mit dem gewählten Vorgehensmodell ermittelt werden; – Regelungen hinsichtlich der Änderungen des Leistungsinhalts i.S.v. Change Management (in Abstufungen nach Notwendigkeiten) mit einem Instrumentarium zu der Frage, was mit vereinbarten Terminen und vereinbarter Vergütung passiert; – Arbeitsteilung und Abgrenzung zwischen den Beteiligten des Softwareanbieters des Anwenders, soweit dies das Vorgehensmodell zulässt; – klare Gliederung des Projekts auch in Verbindung mit der Vergütungsabrede. Zu erreichende Meilensteine sollten klar definiert werden, so dass überprüfbar ist, ob das jeweilige Ziel erreicht ist; – Beschreibung von Test- und Prüfungsszenarien. 83 Die Zusammenarbeit bei Projekten kann koordinativ oder kooperativ angelegt sein, mit allen Abstufungen dazwischen. Die koordinative Form ist gekennzeichnet durch gegeneinander abgegrenzte Parteiinteressen, eine Risikoaufteilung sowie eine beschränkte Informationsweitergabe. Obwohl bekannt ist, dass eine unsachgemäße oder gar unfaire Risikozuweisung die Wahrscheinlichkeit von Projektstörungen signifikant erhöht, ist diese Form

1 Schuhmann, Vom rechtssicheren zum effizienten Projektvertrag, ZfBR 2012, 9.

826

Witzel

Projektmanagement

Rz. 85

H

weit verbreitet. Dasselbe gilt für restriktives Informationsverhalten, das als einer der Hauptgründe für gescheiterte Projekte angesehen wird. Eine kooperative Ausrichtung zeigt sich dagegen in einer ausgewogenen Lastenund Risikoverteilung1. Diese wird im Zweifel auch den neueren Vorgehensmodellen, vor allem Prototypen-Modell sowie agilen Modellen, besser gerecht. b) Claim Management während des Projekts Claim Management2 ist ein Instrument des Projektmanagements. Claim 84 Management umfasst die in einem Unternehmen vorhandenen Einrichtungen, um Risiken, die zu Mehrkosten führen können, zielgerichtet zu handhaben. Wie in Kap. D3 geschildert, ist erhöhter Aufwand im Rahmen eines Projekts fast unvermeidbar; dies gilt umso mehr, wenn die Anforderungen nicht (im Detail) feststehen. Das Claim Management ist ein Instrumentarium, um die beim Vertragsabschluss nicht vorhersehbaren Ereignisse im Verlauf eines Projekts in ihren kommerziellen Folgen zu klären. Bestandteile des Claim Managements sind: – technische Klärung von Änderungen und Erweiterungen; – Durchführung eines vertraglich vereinbarten Change Request/Change Management Prozesses; – Dokumentation der neuen Anforderungen; – Realisierung der neuen Anforderungen.

V. Projektorganisation 1. Zweck der Projektorganisation: Rollen und Verantwortlichkeiten Das Thema Projektorganisation4 stellt sicher, dass für jedes Projekt sinnvoll definierte Rollen und Verantwortlichkeiten festgelegt werden. Projektorganisation sollte so gestaltet werden, dass klare Rollen und Verantwortlich-

1 Schuhmann, Vom rechtssicheren zum effizienten Projektvertrag, ZfBR 2012, 9. 2 Schumann, Anforderungen des Claim Management an die rechtliche Begleitung komplexer Projekte des Anlagenbaus, ZfBR 2002, 739. Gemäß DIN 69905 ist „Nachforderungsmanagement oder Nachtragsmanagement die „Überwachung und Beurteilung von Abweichungen bzw. Änderungen und deren wirtschaftlichen Folgen zwecks Ermittlung und Durchsetzung von Ansprüchen.“ Das Claim Management ist nicht mit dem Change Management gleichzusetzen: Der „Claim“ zielt auf die Anerkennung eines Anspruchs, mit dem Change Management wird eine Vereinbarung abgeändert. 3 S. dort Rz. 156 ff. 4 Gomez u.a., Komplexe IT-Projekte ganzheitlich führen, Ein praxiserprobtes Vorgehen, 2002; Kellner, Die Kunst IT-Projekte zum Erfolg zu führen, Ziele, Strategien und Teamleistungen, 2. Aufl. 2001; Schelle, Projekte zum Erfolg führen, Projektmanagement systematisch und kompakt, 4. Aufl. 2004.

Witzel

827

85

H Rz. 86

Sonderregelungen

keiten für das Lenken (Entscheidungen auf oberster Ebene, Genehmigungsinstanz, Phasenabschlussfreigabe), Managen (Tagesgeschäft im Projekt, Verantwortlichkeit für die Einhaltung von Meilensteinen) und Liefern (Erstellen der Arbeitsergebnisse entsprechend den vereinbarten Anforderungen) auf jeder Ebene festgelegt sind. Wichtige Rollen, die definiert sein sollten, sind: – – – –

Lenkungsausschuss; Projektmanager; Teammanager; Projektunterstützung.

86 Die genaue Projektorganisation ist naturgemäß abhängig von der Projektgröße und dem genauen Projektgegenstand und ggf. auch vom Vorgehensmodell. Bei kleineren Projekten bleiben die Projekteinheiten in den allgemeinen Unternehmensstrukturen verankert und werden von dort aus gesteuert1. Für Großprojekte wird meist ein autonomes Projektmanagement2 installiert, das als eigenständiger, weitgehend unabhängiger Mechanismus funktioniert. Bei mittleren Projekten ist auch eine Kombination möglich: Nur Projektleitung und Projektcontrolling werden institutionalisiert, im Übrigen wird je nach Bedarf auf Mitarbeiter und Ressourcen der bestehenden Unternehmenseinheiten zurückgegriffen. 87 Viele IT-Projekte scheitern wegen mangelnder Organisation und nicht aufgrund mangelnder Fähigkeiten des Softwareanbieters. Die Vertragsgestaltung sollte daher – in der Praxis – auch durchsetzbare und lebbare Regelungen enthalten. Folgende Anforderungen müssen durch die Organisation und die zugewiesenen Rollen eines Projekts erfüllt werden: – Kompetenzen müssen eindeutig geregelt sein: Wer entscheidet was? – Aufgaben und Verantwortungsbereiche sind klar abzugrenzen: Wer macht was? Wer verantwortet welche Ergebnisse? – Entscheidungswege müssen so kurz wie möglich sein. Projekte stehen oft unter Zeitdruck. Bürokratie muss demnach vermieden werden. – Getroffene Entscheidungen müssen nachvollziehbar sein: Wer hat wann was wie und warum entschieden? Welche Informationen und welcher Kenntnisstand lagen zum Zeitpunkt der Entscheidung vor? – Informationen müssen schnell, vollständig und korrekt an die richtigen Zielpersonen weitergegeben werden. – Es muss eine flexible Anpassung an geänderte Anforderungen und Randbedingungen möglich sein.

1 Auch bezeichnet als „Linienprojektorganisation“. 2 Auch bezeichnet als „reine Projektorganisation“, in der die Projektbeteiligten aus den verschiedensten Unternehmensbereichen ausgegliedert und in einem eigenen Projektbereich für die Dauer des Projekts zugeordnet werden.

828

Witzel

Projektmanagement

Rz. 88

H

2. Denkbare Projektorganisation Eine typische Projektorganisation für ein Projekt mittlerer Größe sieht folgende Rollen vor: Anwender/Auftraggeber Entscheidungsbefugte Person. Lenkungsausschuss1 Er stellt die übergeordnete Instanz zur Projektüberwachung und -steuerung dar, trägt in der Regel die Verantwortung für das Erreichen der Ziele und genehmigt Abweichungen und Ergänzungen des Umfangs. Eigenschaften des Lenkungsausschusses sollen Autorität im Unternehmen, Glaubwürdigkeit, Delegationsfähigkeit und ausreichende Verfügbarkeit der Mitglieder sein. Projektmanagement2 Jeder beteiligte Partner benennt einen Verantwortlichen für diese Aufgabe. Die Kompetenzen und die Abgrenzung zum Lenkungsausschuss sollten festgelegt werden. Das Projektmanagement ist für die operative Steuerung aller Projektaktivitäten verantwortlich. Das Projektmanagement ist verantwortlich für alle Prozesse im Projekt mit Ausnahme des Lenkens, das dem Lenkungsausschuss zugewiesen ist. Projektteam(s) Hierzu gehören alle externen und internen Mitarbeiter, die am Projekt mitwirken. Sie sind in der Regel fachlich dem Projektmanager des eigenen Unternehmens unterstellt. Projektteams werden von Teammanagern gesteuert, die dem Projektmanagement berichten. Spezielle Gruppen/Teams Zur Erledigung spezieller Aufgaben (Qualitätssicherung, Tests) wird in der Regel eine vom übrigen Projektgeschehen weitgehend unabhängige Organisation mit gesonderten Mitarbeitern aufgebaut, um die Effizienz der Arbeiten zu verbessern. Projektbüro (Project Office) Die Projektunterstützung übernimmt im Projektbüro administrative Aufgaben und stellt benötigte Werkzeuge zur Verfügung.

1 Auch: Steering Commitee, Projektlenkungsausschuss (PLA), Steuerungsausschuss. 2 Formulierungsvorschlag von Bartsch, in: Beck’sches Formularhandbuch für Bürgerliches, Handels- und Wirtschaftsrecht, III. H. 4; zu den Aufgaben des „SC/ PLA“ s. auch Hoene, Der Projektlenkungsausschuss. Welche Verantwortung braucht der Projektlenkungsausschuss als Steuerungselement bei IT-Projekten?, ITRB 2002, 278.

Witzel

829

88

H Rz. 89

Sonderregelungen

3. Formulierungsvorschlag 89 Eine ausführliche Regelung im Vertrag kann so aussehen:

0. Projektorganisation Der Erfolg des Projektes erfordert ein hohes Maß an Engagement aller am Projekt beteiligten Personen. Neben Engagement und Fachkompetenz kommt einer auf Klarheit, Leistung und Entscheidungsfindung ausgerichteten Projektorganisation besondere Bedeutung zu. Zur Implementierung des … -systems wird die dargestellte Projektorganisation zugrunde gelegt. Im Folgenden wird die grundsätzliche Projektorganisation erläutert. 0.1 Projektgremien Dem Projekt werden zwei Gremien zugeordnet. Sinn der Gremien ist es, die Kommunikation des Projektes auf zwei Ebenen (Geschäftsführungsebene und Projektleitungs- und Koordinationsebene) sicherzustellen. 0.2 Lenkungsausschuss Die Institution „Lenkungsausschuss“ stellt das Eskalations- und Entscheidungsgremium für das Projekt dar. Der Lenkungsausschuss besteht aus Mitgliedern der Geschäftsleitung des Anwenders, eines Vertreters der Gesamtprojektleitung des Softwareanbieters sowie dem Gesamtkoordinator des Anwenders. Die Einrichtung eines gemeinsamen Lenkungsausschusses soll dazu beitragen, dass die internen und externen Entscheidungsträger stets über den gleichen Informationsstand verfügen und dass projektbedeutsame Entscheidungen, welche die vereinbarten Kompetenzen der Gesamtprojektleitung und der Gesamt-Koordination übersteigen, ohne Verzögerung getroffen werden können. Um die Kontinuität der Zusammenarbeit zu sichern, sollten während der Durchführung des Projektes die Mitglieder des Lenkungsausschusses nach Möglichkeit nicht ausgetauscht werden. Die Mitglieder dieses Gremiums werden protokollarisch, monatlich durch die Gesamtprojektleitung über den Stand des Projektes sowie über die Ergebnisse der Review-Boards informiert. Die Funktionen des Lenkungsausschusses sind im Wesentlichen folgende: – Überwachen der Projektergebnisse – Genehmigen der von der Gesamtprojektleitung vorgenommenen Projektplanung. Die Projektplanung (zumindest Projektstrukturplan) erfolgt in Abstimmung mit dem Anwender – Treffen grundlegender strategischer Entscheidungen auf Grundlage der Empfehlungen und Hinweise der Gesamtprojektleitung – Entscheidung über Reduktion und Ausdehnung des Projektumfanges – Entscheidung über die Reihenfolge der Einführungen innerhalb des Unternehmens auf Grundlage der Empfehlungen und Hinweise der Gesamtprojektleitung

830

Witzel

Projektmanagement

Rz. 89

H

– Treffen von Entscheidungen, soweit diese die Kompetenz der Gesamtprojektleitung und der Gesamtkoordination übersteigen – Entscheidung über Programmanpassungen (im Change-Request-Verfahren), soweit durch diese Budgets oder Termine überschritten und vertragliche Vorgaben verändert werden – Unterstützung der Gesamtprojektleitung und der Gesamtkoordination in allen auftretenden Problemen größeren Umfanges – Mitwirkung an der Vermittlung angemessener Erwartungshaltungen der Anwender an die Systeme – Schlichtung von auftretenden Problemen zwischen allen am Projekt beteiligten Stellen – Delegation wichtiger Aufgaben an Mitglieder des Projektteams auf Grundlage der Empfehlungen und Hinweise der Gesamtprojektleitung – Unterstützung und Beratung der Projektleitungen und Koordinatoren Die Ergebnisse des Lenkungsausschusses sind zu protokollieren und spätestens drei Tage nach dem Zusammentreffen dem Verteilerkreis zugänglich zu machen. 0.3 Review-Board Das Review-Board setzt sich aus dem Gesamtprojektleiter und den ProjektKoordinatoren und Beratern des Anwenders sowie den in das Review-Board berufenen Vertretern der einzelnen Fachbereiche des Anwenders zusammen. Die Aufgabe des Review-Boards besteht maßgeblich in der fachlichen Fortschreibung des Projektes, der Kontrolle der erreichten Meilensteine sowie der Definition hieraus resultierender Maßnahmen. Das Review-Board tritt monatlich zusammen, Abweichungen hiervon können einvernehmlich über die Projektleitung abgestimmt werden. Die Agenda wird durch die Gesamtprojektleitung erstellt und spätestens vier Tage vor dem Termin an die Beteiligten verteilt. Das Review Board beschließt über: – – – –

Kategorisierung und Priorisierung von Fehlern der Klasse A Kategorisierung und Priorisierung von Anforderungen der Klasse A Lösung von Konflikten Synchronisierung der Projektaktivitäten auf Grundlage der Empfehlungen und Hinweise der Gesamtprojektleitung – Aktualisierung der Projektplanung auf Grundlage der Empfehlungen und Hinweise der Gesamtprojektleitung – Entscheidung über Programmanpassungen der Klasse B und C, soweit diese innerhalb des Budgets umgesetzt werden können und Termine nicht gefährdet sind. Die Ergebnisse des Review-Boards sind zu protokollieren und spätestens drei Tage nach dem Zusammentreffen dem Verteilerkreis zugänglich zu machen.

Witzel

831

H Rz. 89

Sonderregelungen

0.4 Weitere Projektrollen Die im Folgenden aufgeführten Projektrollen bestehen, im Gegensatz zu den oben aufgeführten Gremien, weitgehend permanent über die gesamte Projektlaufzeit. Einige der Rollenträger sind gleichzeitig Vertreter der Gremien. 0.5 Gesamtprojektleiter Der Gesamtprojektleiter koordiniert alle lieferanteninternen Aktivitäten und ist Hauptansprechpartner für den Anwender. Er ist verantwortlich für Steuerung und Organisation des Projekts und dafür, dass der ausgeschriebene und vereinbarte Vertragsinhalt abnahmefähig und vertragsgemäß installiert und implementiert wird. Dabei ist er verantwortlich für die Vollständigkeit und Richtigkeit der Prozessabbildung gemäß den definierten Sollprozessen und der Systemparametrierung. Er weist auf etwaige Schwierigkeiten bei der Abbildbarkeit von definierten Sollprozessen hin und unterbreitet geeignete Lösungsvorschläge. Er erarbeitet (in einem Workshop mit anschließenden Iterationen) zusammen mit ausgewählten Projektbeteiligten (beratende Funktion) den Projektstruktur- und ablaufplan und erstellt daraus den gesamten Projektplan. Er erstellt des Weiteren den Schulungsplan für die Schulungen der Berater des Anwenders, der Key-User und des Systemmanagements und koordiniert diese Schulungen mit Unterstützung der Koordinatoren des Anwenders. Er ist verantwortlich für die kundenspezifischen Entwicklungsarbeiten und stellt sicher, dass Anpassungen termingerecht bereitgestellt werden und neue Releases in ausreichend getesteter Form installiert werden. Er stellt weiterhin sicher, dass die Integration zwischen den Modulen und den anzubindenden Altsystemen in vereinbarter und sinnvoller Form funktioniert. Er erstellt die Projektberichte (Bestimmungen zu deren Art und Umfang sind gesondert festzuhalten) und berichtet an den Lenkungsausschuss. 0.6 Berater des Softwareanbieters (…) 0.7 Systemmanagement des Softwareanbieters (…) 0.8 Geschäftsführung des Anwenders Die Geschäftsführung des Anwenders ist vor Projektstart aktiver Mitgestalter der Projektinitiierung. Sie wirkt aktiv an der Vertragsgestaltung mit. Es ist von hoher Bedeutung für den Erfolg des Projektes, dass die Geschäftsführung sich aktiv als Sponsor für das Projekt einsetzt und dieses stetig in geeigneter Form verdeutlicht. Nach Projektstart wird die weitere Beteiligung der Geschäftsführung des Anwenders weitgehend auf die Aktivitäten im Rahmen der Teilnahme am Lenkungsausschuss verlagert. Zusätzlich steht sie aber auch zur Unterstützung der Koordinatoren des Anwenders zur Verfügung. 0.9 Koordinatoren des Anwenders Die Koordinatoren haben die Aufgabe, die Durchführung des Projekts zu den definierten Kosten in der definierten Zeit unter Erreichung der gesetzten Ziele 832

Witzel

Projektmanagement

Rz. 90

H

zu überwachen. Um dies ermöglichen zu können, benötigen die Koordinatoren entsprechende Kompetenzen, die ihnen für die Projektlaufzeit eingeräumt werden. Dies sind im Wesentlichen: (…) 0.10 Gesamtkoordination Die wesentlichen Teilprojekte des Projektes sind das Software-Implementierungsprojekt (Definition der Prozesse und Anforderungen und Managen der Umsetzung durch die neue Software) und das technische Projekt (Aufbau eines Rechenzentrums und einer Hardware- und Netzwerkstruktur). Um die beiden parallel laufenden Teilprojekte zu kontrollieren und die Einhaltung der Verpflichtungen durch den Softwareanbieter in notwendiger Weise zu überwachen, wird eine Gesamt-Koordination auf Seiten des Anwenders installiert. Im Falle auftretender persönlicher und fachlicher Probleme zwischen Projektbeteiligten vermittelt die Gesamtkoordination als Mediator. Der Gesamtkoordinator berichtet monatlich an die Geschäftsführung des Anwenders. 0.11 Koordination für die Implementierung Die Aufgabe der Implementierungs-Koordination ist es, die internen Projektabläufe des Anwenders effizient zu organisieren. Die Implementierungs-Koordination überwacht die Bearbeitung der Fehler und Anforderungen durch den Softwareanbieter. Dieser Prozess findet in enger Zusammenarbeit mit der Gesamtprojektleitung und den Beratern des Softwareanbieters statt, die die Erstellung eines abnahmefähigen, vertragsgemäßen Systems sicherstellen. Der Implementierungs-Koordinator sorgt dafür, dass die Beschreibungen der fachlichen Anforderungen klar und eindeutig definiert sind. In der Testphase stellt er sicher, dass alle kritischen Prozesse intensiv getestet werden können. Er organisiert den Ablauf des Integrationstestes und die Durchführung der Abnahmen. (…) 0.12 Technische Koordination (…)

VI. Projektkommunikation 1. Risikofaktor Kommunikation Wie Lapp1 zutreffend ausführt, lassen sich Kommunikation und Vertrauen 90 ebenso wenig wie Spontaneität vertraglich verordnen. Wohlverhaltensregelungen wären zu unbestimmt und damit nicht durchsetzbar. Die Tatsache, dass in diesem Themenbereich vertragliche Regelungen wenig helfen, 1 Lapp, Interaktion und Kooperation bei IT-Projekten, ITRB 2010, 69.

Witzel

833

H Rz. 91

Sonderregelungen

sollte jedoch nicht dazu führen, dass die Kommunikation als Erfolgsfaktor für ein Projekt unterschätzt wird1. Ein erheblicher Risikofaktor für komplexe Projekte ist die mangelnde oder schlechte Kommunikation zwischen den Beteiligten. Werden Projekte notleidend und wird in der Konsequenz die Rechtsabteilung oder die externe anwaltliche Beratung eingeschaltet, wird bei der Risikoabschätzung oder auch der Bewertung der Erfolgsaussichten etwaiger Ansprüche häufig der Faktor Kommunikation unterbewertet. Wird ein vereinbarter Termin nicht eingehalten oder entspricht eine zu entwickelnde oder zu implementierende Software nicht den vereinbarten Anforderungen bzw. erfüllt sie nicht die vereinbarten Qualitätskriterien, beginnt häufig eine mühselige Ursachenforschung und gegenseitige Schuldzuweisung. Dabei wird gerne übersehen, dass Projektziele nicht zwingend nur an harten Kriterien scheitern, sondern dass auch die Kommunikation der Projektbeteiligten untereinander erheblichen Einfluss hat. 91 Folgende Maßnahmen tragen zur Förderung der Kommunikation2 bei: – Ein regelmäßig terminlich festgelegter Informationsaustausch (als Meeting oder Statusbericht) kann Vertrauen schaffen und Halt geben. – Kontinuierliches Lernen der Vertragspartner ist eine zwingende Voraussetzung für den Projekterfolg. Der Softwareanbieter muss die Anforderungen verstehen lernen und der Anwender muss die technischen Möglichkeiten kennenlernen, damit alle ein gemeinsames Verständnis für den Gegenstand des Projekts entwickeln. – Begriffliche Missverständnisse sollten vermieden werden. Sprachverwirrungen (vor allem durch die Verwendung von mehrdeutigen Anglizismen und Abkürzungen) können zu den größten Projektrisiken führen. In der gesamten Projektdokumentation (einschließlich der vertraglichen Regelungen) sollten unbedingt einheitliche Begriffe verwendet werden, was regelmäßig schon deswegen nicht der Fall ist, weil die Unterlagen von unterschiedlichen Bearbeitern erstellt werden. – Prototypen können bei schwierigen Entscheidungen helfen. 92 (Juristische) Berater, die in Krisensituation hinzugezogen werden, tendieren häufig dazu, „Öl ins offene Feuer“ zu gießen und mit entsprechend scharfen Angriffen und Formulierungen das ohnehin schon angeknackste Vertrauen in den Projekterfolg weiter zu untergraben. Die bei notleidenden Projekten gewählten Formulierungen sollten sorgfältig erwogen werden. Es ist genau zu analysieren, welchen Erfolg man mit welcher Maßnahmen erzielen kann und vor allem, ob das Projekt noch gerettet werden kann oder ob es letztlich nur noch um die Form des Abbruchs geht. Eine Fristsetzung, die nicht im

1 Mangold, IT-Projektmanagement kompakt, S. 27 ff.; Streitz, IT-Projekte retten, S. 125. 2 Bauer/Hauptmann, in: Tiemeyer (Hrsg), Handbuch IT-Projektmanagement, 2010, S. 570.

834

Witzel

Projektmanagement

Rz. 94

H

Einklang mit den von den Vertragspartnern vereinbarten Terminen steht, wird im Regelfall zu einer Eskalation in die Rechtsabteilung oder in die Geschäftsleitungsebene führen; damit ist der Projekterfolg manchmal eher gefährdet als gefördert. Ein Indikator für den Projektstatus sind auch Ton und Wortwahl in der zwischen den Vertragspartnern ausgetauschten Korrespondenz. Es kann auch geboten sein, diesen zu deeskalieren und nicht weiter zu verschärfen. 2. Erhöhtes Risiko durch internationale Bezüge Eine weitere Erschwernis ergibt sich immer häufiger durch internationale Be- 93 züge1. Kulturvielfalt kann zu Ideenvielfalt, aber auch zu Missverständnissen und Konflikten führen: Ein deutscher Auftraggeber schließt einen IT-Projektvertrag mit einem US-Softwarehaus, das zwar über deutschsprachige Vertriebsmitarbeiter, nicht aber über deutschsprachige Entwickler und Datenbankdesigner verfügt. Ein Teil der Entwicklungsabteilung ist zudem in Israel angesiedelt. Bereits die Sprachschwierigkeiten erhöhen die Kommunikationsprobleme, was letztlich ein Faktor für das Scheitern eines Projekts sein kann. Sind Vertragspartner aus unterschiedlichen Kulturkreisen involviert, ist dem Rechnung zu tragen. Unser Verständnis ist auch von „christlichen“ und „abendländischen“ Wertvorstellungen geprägt, die etwa in fernöstlichen Ländern nicht geteilt oder nicht verstanden werden. Andere Kulturen bringen eigene Wertesysteme, Traditionen und Gebräuche mit sich, was sich teilweise schon in Begrüßungsritualen widerspiegelt. Diese Wertesysteme können nicht einfach über vertragliche Regelungen ausgehebelt werden, sondern sind vor allem bei der Risikobewertung zu berücksichtigen. Bei multinationalen Projektteams sollte es einfache, aber verbindliche Teamregeln geben, die den unterschiedlichen Arbeitsauffassungen und Konventionen gerecht werden. 3. Schlechte Informationspolitik Projekte kranken regelmäßig an mangelhafter Informationspolitik2. Je tiefer ein Projekt in der Krise steckt, desto schlechter wird der Informationsaustausch regelmäßig. Ob ein Informationsmanagement effizient ist, kann nach folgenden Kriterien bewertet werden: – Flexibilität im Umgang mit Informationsquellen; – Effizienz: Mit wie viel Aufwand ist es für die Beteiligten verbunden, informiert zu bleiben? – Kontinuität: Die aktive und passive Versorgung mit Informationen muss während des Projekts stabil sein. 1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2008, zu Problemen bei der globalen Softwareentwicklung, S. 281 ff. 2 Bauer/Hauptmann, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 561.

Witzel

835

94

H Rz. 95

Sonderregelungen

– Personalisierung: Informationen sollen individuell nutzbar sein. – Akzeptanz: Gutes Informationsmanagement ist daran zu erkennen, dass die Aufbereitung und Weitergabe von allen Projektbeteiligten aktiv, selbstverständlich und freiwillig durchgeführt wird. 4. Vertragliche Festlegungen als Hilfestellung 95 Ein möglichst reibungsloser Informationsaustausch und Maßnahmen zur Förderung einer intensiven und regelmäßigen Kommunikation können zum Erfolg eines Projekts entscheidend beitragen. Festlegungen zur Projektkommunikation einschließlich der Projektsprache sind vor dem Hintergrund eines ordentlichen Projektmanagements, aber auch zur Risikominimierung in rechtlicher Hinsicht erforderlich. Gerade in komplexen Projekten ist eine ordentliche und im Falle der Eskalation auch nachvollziehbare projektbegleitende Dokumentation unumgänglich. 96 Unerlässlich ist eine umfassende projektbegleitende Dokumentation. Zum Start des Projekts ist mehr oder minder genau beschrieben, welche Ziele mit dem Projekt verfolgt werden und welche Ergebnisse erwartet werden. Idealerweise liegen ein ausgewogener Vertrag und eine detaillierte Leistungsbeschreibung vor. Während eines Projekts kommen zum einen geänderte Leistungsinhalte (Change Requests) hinzu, zum anderen sind auch die zwischen den Vertragspartnern unumgänglichen Abstimmungsvorgänge zu dokumentieren. In diesem Zusammenhang spielt erneut das neue Leistungsstörungsrecht eine Rolle: Wie soll es in einem umfassenden Projekt nachvollziehbar sein, ob das vereinbarte Pflichtenprogramm eingehalten wurde, wenn der Ablauf des Projekts nicht schriftlich dokumentiert wurde: „Eine Sitzung, zu der es kein Protokoll gibt, hat nicht stattgefunden“. 97 Die projektbegleitende Dokumentation belegt die Abläufe und die Entwicklung im Projekt und umfasst somit alle Unterlagen, die während der Laufzeit von Anpassung, Einführung und Implementierung angefertigt wurden. Es empfiehlt sich, schon zu Projektstart und in Zusammenhang mit den vertraglichen Vereinbarungen festzulegen, wie die projektbegleitende Dokumentation gestaltet werden soll:

Protokolle werden mit dem Textverarbeitungsprogramm X in der Version Y auf Basis der in Anhang … beigefügten Dokumentenvorlage Z erstellt. Graphiken werden im Format G mit dem Programm H erstellt. Sie werden grundsätzlich als Anhänge von E-Mails versandt.

98 Bei der projektbegleitenden Dokumentation prallen häufig die Einschätzung der Juristen über mögliche Risikominimierung mit der Auffassung der Projektmanager über das „doing“ und das „daily life“ aufeinander. Aus rechtlicher Sicht kann die Projektdokumentation nicht umfassend genug sein, 836

Witzel

Rz. 100 H

Projektmanagement

aus Sicht des Projektmanagements muss noch ausreichend Zeit sein, sich der eigentlichen Projektdurchführung zu widmen: Die Zeit, die für das Verfassen von Protokollen erforderlich ist, muss überschaubar bleiben. Statusberichte sollten trotz dieses Spannungsverhältnisses regelmäßig verfasst werden und folgende Informationen umfassen: – – – – – – –

Management Summary; Aussagen zu Terminlage, Kosten, Qualität und Kapazität; aktuelle Planung; Bericht zu aktuellen Themen; Klärungsbedarf/Handlungsbedarf; aktuelle Projektrisiken; aktueller Stand der Leistungen.

Die Protokollierung dient der Dokumentation mündlicher Besprechungen, 99 vor allem auf Projektleitungsebene und im Entscheidungsgremium, z.B. dem Projektlenkungsausschuss. Zur Sicherheit für beide Vertragspartner sollte insbesondere die Entscheidungsfindung wiedergegeben werden. Protokolle erlangen eine wesentliche Bedeutung, wenn Konflikte im Projekt auftreten: Sie können Leistungsinhalte abgrenzen, die einvernehmliche Verschiebung von Terminen belegen oder bestimmte Qualitätssicherungsmaßnahmen auswählen. Hilfreich kann auch ein Projekthandbuch1 sein, das kein monolithisches 100 Dokument sein muss, sondern auch aus einer Vielzahl von Verknüpfungen (interaktive Links) zu anderen Dokumenten (etwa Konzepten und Spezifikationen) bestehen kann. Eine Kapitelstruktur für ein solches Projekthandbuch kann etwa so aussehen: Kapitel 1 Allgemeines

Zweck des Projekthandbuchs Referenzierte Dokumente

Kapitel 2 Projektbeschreibung

Ausgangslage/Hintergrund Projektziele Rahmenbedingungen/Annahmen Vorgehensmodell Risikomanagement

Kapitel 3 Projektplanung mit Meilensteinen

Projektschritte und Phasen Projekt-Struktur-Plan Ablaufplan und Terminplan Meilensteine mit geplanten Arbeitsergebnissen

1 Ein Projekthandbuch ist nach DIN 69905 die Zusammenstellung von Informationen und Regelungen, die für die Durchführung eines bestimmten Projekts gelten sollen.

Witzel

837

H Rz. 101 Kapitel 4 Projektorganisation

Sonderregelungen Steuerungsausschluss Projektmanagement Projektteam Projektbüro Projektorganigramm Aufgabenverteilung und Rollenbeschreibung Kommunikationsregeln

Kapitel 5 Projektbudget Kapitel 6 Methoden und Werkzeuge

Funktion und Einsatzbereich des Projektmanagement-Tools Berichtswesen

VII. Projektcontrolling und Risikomanagement 1. Projektcontrolling 101

Ein Softwareprojekt befindet sich immer in dem Spannungsfeld zwischen den Parametern Funktionalität, Zeit, Kosten und Qualität. Wenn man diese Parameter nicht permanent kontrolliert und entsprechende Maßnahmen zur Gegensteuerung durchführt, verändern sich diese Parameter fast unvermeidbar und führen spätestens am Projektende oft zu unliebsamen Überraschungen.

102

Projektcontrolling1 bedeutet die Planung und Steuerung der Projektdurchführung zur Sicherung der Erreichung der Projektziele: Das Controlling ist daher mitverantwortlich für den Erfolg des Projekts. Bei der Projektsteuerung zahlt es sich aus, wenn plausible Pläne und gewonnene Soll-Vorgaben (Definition der fachlichen Anforderungen) existieren. Beim Controlling wird festgestellt, ob steuernde Maßnahmen notwendig sind, um das Projekt zum Erfolg zu führen. Projektcontrolling sollte ein permanenter und laufender Vorgang sein. Es geht um folgende Fragen: – – – – –

Ist das Projekt noch auf dem richtigen Weg? Ist das Projekt noch in der geplanten Zeit? Ist das Projekt noch im Budgetrahmen? Sind Funktionalität und Qualität wie vereinbart? Werden Ziele erreicht: In Time? In Budget? In Quality?

1 Zsifkovits, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 307; Kellner, Die Kunst, IT-Projekte zum Erfolg zu führen, S. 171 ff.; Mangold, IT-Projektmanagement kompakt, S. 27 ff.; Streitz, IT-Projekte retten, S. 147 ff.

838

Witzel

Projektmanagement

Rz. 105 H

Projektcontrolling bedeutet die Verbindung zwischen der Projektplanung1 und dem übergeordneten Unternehmenscontrolling. Ziele des Projektcontrollig2 sind folgende:

103

– Abstimmung von Zielvorgaben und Umsetzung mit der Unternehmensstrategie; – Unterstützung des Projektmanagements in der Erreichung der Planungsvorgaben hinsichtlich Qualität, Funktionalität, Kosten und Zeit; – Feststellen von Planabweichungen und deren Ursachen; – Entwicklung von Maßnahmen zur Korrektur und Abweichungen; – Steuerung des Projektumfangs und des Zusammenwirkens von Projekten im Projekt-Portfolio; – Bewerten von Risiken und Einleiten von Maßnahmen zur Risikobeherrschung oder -reduktion. Die Ziele des Projekts stellen die Kriterien dar, an denen das Controlling 104 ausgerichtet ist. Die regelmäßige Überwachung des Projektfortschritts kann frühzeitig anzeigen, ob ein Projekt in eine Schieflage zu geraten droht. Das Controlling muss bei bedeutenden Projekten begleitend tätig sein, um möglichst frühzeitig auf Fehlentwicklungen im Rahmen des Projekts reagieren zu können. Dies bedeutet entweder eine permanente Begleitung der einzelnen Projektphasen oder Überwachungstätigkeiten mit sehr kurzen Zeitabständen vom Projektstart an. Eine vertragliche Regelung dazu könnte in etwa so aussehen:

105

Wesentliche Pflicht des Auftragnehmers ist es, mitverantwortlich aktiv und initiativ die Ziele des Projekts zu verfolgen und zu erreichen. Dazu wird der Auftragnehmer während der Laufzeit des Projekts einen Controller einsetzen, in Abstimmung mit dem Auftraggeber auch mehrere Controller. Der Controller ist ein Mitglied des Projektteams des Auftragnehmers und hat folgende Aufgaben: – Überwachung der Einhaltung der vertraglichen Verpflichtungen beider Vertragspartner sowie der vom Auftragnehmer eingesetzten Subunternehmer; – Dokumentation von streitigen Themen und der diese betreffenden Entscheidungen; – Überwachung von vertraglich festgelegten Lieferungen; – Laufende Überwachung von Zeit- und Terminplänen zur Feststellung von möglichen Inkonsistenzen, Verbesserungen und Risikofaktoren; – Entwicklung und Überwachung einer Kommunikationsstruktur sowie geeigneter Eskalationsmechanismen.

1 S. Rz. 74 ff. 2 Bei großen Projekten wird vielfach ein eigener Projektcontroller eingesetzt, der den Projektmanager bei der Durchführung dieser Aufgabe unterstützt.

Witzel

839

H Rz. 106 106

Sonderregelungen

Hinsichtlich der Controllinganforderungen schafft eine projektbegleitende Dokumentation Transparenz, da sie Kontrollen im Entwicklungsprozess ermöglicht. Es kommen folgende Bereiche in Betracht: – Information des Anwenders über den Projektfortschritt für die eigene Disposition – Information des Anwenders über Risikobereiche und Darstellung von Art und Größe des Risikos – Statusberichte – Zutrittsrechte des Anwenders zu Entwicklungs- und Herstellungseinrichtungen – Vereinbarung von Programm- und Designreviews mit Beteiligung des Anwenders – Unterstützung des Anwenders bei der Durchführung eigener Prüfungen und ihrer Auswertung

107

Das Berichtswesen innerhalb eines Projekts ist zum einen Überwachungsinstrument, zum anderen Überwachungshandlung: Durch die effektive Ausgestaltung des Projektberichtswesens wird sichergestellt, dass Auftraggeber und Auftragnehmer ständig über den Fortgang des Projekts informiert sind. Der Projektcontroller trägt nicht die Verantwortung für das Projekt, sondern die Verantwortung für die „Sicherstellung der Transparenz des Projektgeschehens“. 2. Risikomanagement a) Risiken und Unsicherheiten

108

Was ist ein Risiko? Ein Risiko ist ein gewichtetes Muster möglicher Ereignisse und der damit verbundenen Folgen. Anders gesagt: Ein Risiko ist ein potentielles Problem. Ein Problem ist ein Risiko, das bereits eingetreten ist. Alle Projekte sind mehr oder weniger mit dem Risiko der Terminüberschreitung, der Überschreitung der geplanten Kosten und der Verfehlung der gesetzten Qualitäts- und Funktionsziele behaftet. Risiken wirken sich im Fall des Eintretens üblicherweise schädlich auf das Projekt aus: – Projektrisiken können die Qualität der geschuldeten Leistung beeinträchtigen. – Projektrisiken wirken sich häufig negativ auf das festgelegte Projektbudget aus. – Projektrisiken haben fast immer Terminverzug zur Folge.

109

Je früher die wichtigsten Risikotreiber, also die Faktoren, die den rechtzeitigen Projektabschluss, die Einhaltung des Projektbudgets und die Erreichung

840

Witzel

Projektmanagement

Rz. 111 H

der Leistungsziele, gefährden können, aufgedeckt werden, umso eher kann auch Risikovorsorge getroffen werden. Projektmanagement ist auch Risikomanagement1. Was bedeutet Risikomanagement? Risikomanagement ist eine systematische Vorgehensweise, über Korrekturmaßnahmen nachzudenken, bevor ein Problem auftritt, solange es noch eine abstrakte Vorstellung ist. Das Gegenteil von Risikomanagement ist das Krisenmanagement. Beim Krisenmanagement geht es darum, eine Lösung für das Problem zu finden, nachdem es aufgetreten ist2. Das Risikomanagement umfasst alle organisatorischen Regelungen und Maßnahmen zur Erkennung und zum Umgang mit vorhandenen Risiken. Risikomanagement soll Probleme identifizieren, kontrollieren und steuern. Leider fehlt es in vielen Projekten völlig am Risikomanagement. Software- 110 anbieter vermeiden das Thema in der Vertriebsphase am liebsten völlig, da die Erwähnung etwaiger Risiken für den Vertriebserfolg vermeintlich kontraproduktiv ist. Auftraggeber hoffen, etwaige Risiken schon allein damit zu vermeiden, dass sie sich für ein Standardprodukt entscheiden. Im Hinblick auf die Kosten, die im Fall eines gescheiterten Projekts auf beide Vertragspartner zukommen, erscheinen beide Ansätze kurzsichtig. Ein Softwareanbieter sollte die Hinweise auf bestehende Risiken besser als Beratungsleistung verkaufen, die mittel- und langfristig den Projekterfolg sichert. Auftraggeber sollten sich nicht blind darauf verlassen, dass allein die Entscheidung für ein vermeintlich etabliertes System Risiken erst gar nicht entstehen lässt. Die meisten späteren Probleme sind als Risiken bereits vor dem Projekt- 111 start bekannt. Besteht ein Anwender darauf, dass ein neues System 1:1 die Funktionalität des Altsystems abbildet und lässt er das auch vertraglich „absichern“, steht schon bereits vor der Konzeptionierung fest, dass Probleme auftreten werden. Bei Einführung und Implementierung von Standardsoftware ist die Forderung nach einer 1:1-Ablösung des Altsystems in der Regel unerfüllbar, schon allein deswegen, weil das Altsystem selten im Detail beschrieben ist. Werden – obwohl die Anforderungen allenfalls oberflächlich beschrieben sind – Festpreise vereinbart, ist ein Konflikt nahezu unvermeidbar.

1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2008, S. 359 ff.; Ebert, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 485 ff.; Schelle, Projekte zum Erfolg führen, S. 109 ff.; Ebert, in: Tiemeyer (Hrsg.), Handbuch IT-Projektmanagement, 2010, S. 485 ff. 2 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2008, S. 360; DeMarco/Lister, Bärentango – Mit Risikomanagement Projekte zum Erfolg führen, 2003.

Witzel

841

H Rz. 112

Sonderregelungen

Typische Risikofaktoren

Beispielhafte Maßnahmen zur Risikovorsorge

Personalmangel, Mangel an genügend qualifiziertem Personal

„Einkauf“ von Spezialisten; Maßnahmen der Teambildung; Training; langfristige Einsatzplanung der „Schlüsselkräfte“

Unrealistische Zeitpläne und Budgets

Detaillierte Kosten- und Zeitplanung; Vermeidung von „Luxusfunktionen“; stufenweise Entwicklung in Versionen; Wiederbenutzung vorhandener Komponenten

Entwicklung falscher Softwarefunktionen

Organisationsanalyse; Erstellung eines Prototyps; Einbindung der potentiellen Nutzer; frühzeitige Erstellung von Benutzerhandbüchern

Entwicklung falscher Benutzerschnittstellen

Erstellung eines Prototyps; Einbindung der potentiellen Nutzer; Aufgabenanalysen

Ausstattung des Produkts mit überflüs- Erstellung eines Prototyps; Kosten-Nutsigen Funktionen zen-Analysen Kontinuierliche Änderungen der Anfor- Konsequentes Änderungsmanagement derungen durch den Auftraggeber mit „Einfrieren der Spezifikationen“ Mängel bei den Reaktionszeiten der Systeme

Simulation mit Hilfe eines Prototyps

Zu hohe Erwartungen an die Möglichkeiten der Informatik

Machbarkeitsstudien, Erstellung eines Prototyps

b) Risikomanagement 112

Fehlerhafte Terminpläne, zusätzliche Anforderungen, nicht umsetzbare Spezifikationen, Mitarbeiterkündigungen und geringe Produktivität sind die Kernrisiken. Um Risiken zu managen, ist es notwendig, einen Risikomanagementprozess zu etablieren. Zum aktiven Risikomanagement gehören drei Hauptaktivitäten, die zu einen der Risikobewertung dienen, zum anderen der Risikobeherrschung. Risikobewertung

Risikobeherrschung

Risikoidentifikation

Planung des Risikofalls

Das Ergebnis der Risikoidentifikation ist eine Liste der projektspezifischen Elemente, die den Projekterfolg gefährden.

Für die kritischen Risiken müssen Eventualfallpläne aufgestellt werden, in denen festgelegt wird, was zu tun ist, falls und wenn ein Risiko zum Problem wird.

842

Witzel

Rz. 114 H

Projektmanagement Risikobewertung

Risikobeherrschung

Risikoanalyse

Risikoverminderung

Bei der Risikoanalyse werden die Eintrittswahrscheinlichkeit und die Schadenshöhe für jedes identifizierte Risiko geschätzt.

Es sind die Maßnahmen festzulegen, die vor dem Risiko ergriffen werden müssen, um die geplanten Maßnahmen zur Risikobewältigung im Schadenfall möglich und effektiv zu machen.

Risikoprioritätenbildung

Risikoüberwachung

Risiken müssen nach Priorität geordnet Die Eintrittsindikatoren, die angeben, werden. Bei der Priorisierung kann auf ob ein Risiko eingetreten ist, sind fortlaufend zu überwachen. den Risikofaktor (Risikofaktor = Eintrittswahrscheinlichkeit × Schadenshöhe) abgestellt werden.

Risiken müssen identifiziert, analysiert und priorisiert werden. Auf dieser Basis werden die denkbaren Risikofälle geplant und festgelegt, wie Risiken vermindert und überwacht werden. Mit folgender Checkliste1 lässt sich überprüfen, ob dem Risikomanagement ausreichend Rechnung getragen ist:

113

– Ist eine Risikoliste vorhanden, die alle Kernrisiken enthält und auch alle projektspezifischen Risiken beschreibt? – Ist ein Risikoentdeckungsprozess etabliert, der auch eine offene Diskussion über festgestellte Risiken ermöglicht? – Sind Unsicherheitsdiagramme vorhanden, die genutzt werden? – Ist jedem Risikofaktor ein Eintrittsindikator zugeordnet, der kontinuierlich überwacht wird? – Gibt es für jedes Risiko einen Eventualfallplan und einen Risikoverminderungsplan? – Wird für jedes Risiko die Risikohöhe evaluiert?

VIII. Eskalation 1. Unvermeidbarkeit von Konflikten Konfliktfrei leben und arbeiten zu können, ist ein Mythos2. Wenn – wie in jedem IT-Projekt – verschiedene Personen miteinander an einer Problemlösung arbeiten, kommt es über kurz oder lang unvermeidbar zu Konflikten. Es werden typischerweise Termine nicht eingehalten, Arbeitsergebnisse

1 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2. Aufl. 2008, S. 375. 2 Hans L. Merkle (ehemaliger Vorstandsvorsitzender bei Bosch): „Unsere Aufgabe ist es nicht, den Konflikt als existenziellen Spannungszustand zu negieren, sondern ihn zu erkennen, zu untersuchen und zu bewältigen – und mit ihm zu leben, soweit er nicht zu bewältigen ist.“

Witzel

843

114

H Rz. 115

Sonderregelungen

mit schlechter Qualität ausgeliefert, Informationen entgegen den Absprachen nicht weitergegeben und Rivalitäten im Projektteam ausgetragen. 115

Nach den Schätzungen der Gartner Group geraten 50 % aller Softwareprojekte wenigstens einmal während der Laufzeit in die Schieflage. Aus den regelmäßigen Reports der Standish Group1 über den Erfolg von IT-Projekten ergibt sich beispielsweise für das Jahr 1998, dass 26 % der Softwareprojekte als „succeeded“ einzustufen sind, 28 % als „failed“ und 46 % als „challenged“, d.h. mit Zeit- und Budgetüberschreitung. Im Jahr 2000 galten 28 % der Projekte als „succeeded“, 23 % als „failed“ und 49 % als „challenged“.

116

Im Hinblick auf diese düsteren Szenarien ist es notwendig, sich im Zeitpunkt der Vertragsgestaltung mit möglichen Eskalationsmechanismen auseinander zu setzen und den Vertragspartnern für den „worst case“ ein Reularium vorzugeben, das die Sanierung des Projekts ermöglicht2. Die Eskalation wird dann benötigt, wenn ein Problem im Projekt auf der Arbeitsebene nicht lösbar ist. Die Eskalationssteuerung liegt grundsätzlich in der Verantwortung des Projektmanagements. Die Varianten für Eskalationsverfahren sind vielfältig: Die Vertragspartner können bei Auseinandersetzungen einen Mediator einsetzen, bei Streit über fachliche Fragen einen Gutachter hinzuziehen und im Fall einer tiefgreifenden Auseinandersetzung ein Schlichtungsverfahren durchführen. Allein der Weg zu den ordentlichen Gerichten erscheint zur Problemlösung nicht erstrebenswert. Die außergerichtliche Streitbeilegung3 geht davon aus, dass die Vertragspartner weiter zusammenarbeiten. 2. Möglichkeiten zur Konfliktlösung

117

Die Mediation verfolgt das Prinzip, dass der oder die Mediatoren zwischen den Parteien des Konflikts vermitteln und sich dabei an deren (fachlichen und wirtschaftlichen Interessen) orientieren. Die Mediation strebt eine Konfliktlösung an, die von allen Beteiligten gemeinsam erarbeitet und damit auch mit hoher Wahrscheinlichkeit getragen wird.

118

Ein Schlichtungsverfahren setzt nicht auf eine eigenverantwortliche Konfliktlösung, sondern auf eine Steuerung durch den oder die Schlichter. Eine Schlichtung kommt vor allem dann in Betracht, wenn die Vertragspartner eine außergerichtliche Streitbeilegung, aber auch eine stärkere externe Füh1 Der sog. Chaos Report der Standish Group ordnet IT-Projekte in drei Kategorien ein: (1) Successful: Projekt wurde innerhalb der vorgegebenen Zeit und Budget abgeschlossen. Projektergebnis ist im Einsatz und erfüllt alle Anforderungen. (2) Challenged: Projekt abgeschlossen. Projektergebnis ist im Einsatz. Zeit, Budget oder Leistung sind aber nicht im vorgegebenen Umfang erreicht worden. (3) Failed: Das Projekt wurde vorzeitig abgebrochen oder das Projektergebnis nie eingesetzt. 2 Zahrnt, Probleme bei DV-Projekten und Gegenmaßnahmen, CR 2000, 402. 3 Stubbe, Konfliktmanagement – bedarfsgerechte Streitbeilegungsmechanismen, SchiedsVZ 2009, 321.

844

Witzel

Rz. 120 H

Projektmanagement

rung wünschen und nicht selbst eine Lösung erarbeiten wollen oder können. Es gibt eine Reihe von Schlichtungsstellen; für IT-Projekte kommt vor allem das Schlichtungsverfahren1 der Deutschen Gesellschaft für Recht und Informatik e.V. in Betracht. Der wesentliche Unterschied zwischen Schlichtung und Mediation liegt da- 119 rin, dass bei der Mediation die Vertragspartner weitgehend selbständig einen Lösungsvorschlag erarbeiten, während im Schlichtungsverfahren eine stärkere Führung und Anleitung durch das Schlichtungsteam erfolgt. Beide Verfahren bieten den Vorteil, dass die bestehende Geschäftsbeziehung nicht zwangsläufig zerstört wird, sondern die Vertragspartner Wege und Möglichkeiten erhalten, weiter miteinander zu arbeiten. Die Vertragsgestaltung ist bei der Erstellung eines „Eskalationsgremiums“ gefragt; eine ausführliche Regelung kann wie folgt aussehen:

0. Eskalations- und Konfliktmanagement 0.1 Bildung und Einschaltung eines Eskalationsgremiums 0.1.1 Bildung Eskalationsgremium Die Vertragspartner bilden zur Klärung und Entscheidung von offenen Fragen, die nicht zwischen Projektleiter und Ansprechpartner geklärt werden können, im Rahmen des Projektes ein Eskalationsgremium, bestehend aus 2 Mitgliedern jeder Partei. 0.1.2 Mitglieder des Eskalationsgremiums Die Mitglieder des Eskalationsgremiums sind innerhalb von 10 Kalendertagen nach Unterzeichnung dieses Vertrages schriftlich gegenüber dem jeweils anderen Vertragspartner zu benennen. 0.1.3 Anforderung der Entscheidung durch das Eskalationsgremium Soweit auf der Ebene der Ansprechpartner eine einvernehmliche Entscheidung, Abstimmung, Vereinbarung etc. nicht erreicht werden kann, ist jeder Ansprechpartner berechtigt, die Entscheidung durch das Eskalationsgremium anzufordern. Er hat darüber den jeweils anderen Ansprechpartner zu informieren. 0.1.4 Entscheidung durch das Eskalationsgremium Die Ansprechpartner werden dann jeweils unverzüglich schriftlich den Sachverhalt dem Eskalationsgremium unter Darstellung der Entscheidungsgrundlagen mitteilen. Das Eskalationsgremium wird dann versuchen, innerhalb von zwei Wochen auf Anforderung der Entscheidung durch einen Ansprechpartner eine einvernehmliche Entscheidung zu erzielen, die schriftlich dokumentiert wird. Das Eskalationsgremium kann einvernehmlich die Unterbrechung der

1 www.dgri.de/service/schlichtungsordnung.html.

Witzel

845

120

H Rz. 120

Sonderregelungen

Leistungen festlegen. Hinsichtlich der Vergütung haben die Vertragspartner ebenfalls eine einvernehmliche Lösung zu treffen. 0.2 Einschaltung eines Schiedsgutachters („Sachverständigen“) bei Fragen zur Leistungserbringung 0.2.1 Voraussetzungen der Einschaltung eines Schiedsgutachters („Sachverständigen“) Können sich die Vertragspartner auch unter Einschaltung des Eskalationsgremiums nicht darüber einigen, ob eine vereinbarte Leistung vertragsgemäß erbracht ist, werden diese Streitfragen durch einen Schiedsgutachter („Sachverständigen“) für beide Vertragspartner verbindlich geklärt. 0.2.2 Benennung des Schiedsgutachters („Sachverständigen“) Der Schiedsgutachter wird auf Antrag jeder Partei durch die Deutsche Gesellschaft für Recht und Informatik (DGRI e.V.) benannt. Die Vertragspartner dürfen den Schiedsgutachter erst dann anrufen, wenn im Eskalationsgremium innerhalb einer Frist von 2 Wochen ab Anrufung durch eine der Parteien keine Einigung zu Stande gekommen ist. 0.2.3 Beteiligung der Vertragspartner Beide Vertragspartner sind verpflichtet, – dem Schiedsgutachter alle Informationen zu geben, die er verlangt, sofern diese nicht auf Grund einer Vertraulichkeitsvereinbarung geheim zu halten sind, – Während der üblichen Geschäftszeiten Zutritt zu ihren Räumen zu gewähren, – alle gewünschten Gegenstände zur Besichtigung oder in Kopie zu überlassen, – in technischer Hinsicht alle Vorkehrungen bereitzustellen, um mitzuwirken, damit der Schiedsgutachter die Situation beurteilen kann, – Dritte, die in ihrem Risikobereich tätig sind, anzuweisen, den Schiedsgutachter bei seiner Arbeit zu unterstützen. 0.2.4 Wertung von Informationen Wirkt ein Vertragspartner nicht ausreichend mit, darf der Schiedsgutachter nicht erhaltene Informationen so werten, dass die der anderen Seite günstige Version zugrunde zu legen ist. 0.2.5 Anhörung Hat der Schiedsgutachter seine Untersuchung abgeschlossen, lädt er die Vertragspartner mit einer Einladungsfrist von höchstens einer Woche zur Anhörung. Er trifft seine Entscheidung am Ende der Anhörung mündlich und endgültig. Er hat sie auf Verlangen eines Vertragspartners schriftlich zu begründen, sobald diese ihm hierfür einen Vorschuss leistet. Die Bindung der Entscheidung tritt jedoch schon zum Zeitpunkt der Verkündung ein.

846

Witzel

Projektmanagement

Rz. 120 H

0.2.6 Kosten Der Schiedsgutachter entscheidet auch über die Kosten im Verhältnis des Obsiegens zum Unterliegen. Die Kosten der Rechtsberatung trägt jeder Vertragspartner selbst. 0.2.7 Hemmung der Verjährung Die Verjährung für alle Ansprüche aus dem streitigen Lebenssachverhalt ist ab dem Antrag auf Bennennung eines Schiedsgutachters bis zum Ende des Verfahrens gehemmt, § 203 BGB gilt entsprechend. 0.3 Schlichtung 0.3.1 Voraussetzungen der Schlichtung Bei sonstigen Streitigkeiten (nicht Fragen der Leistungserbringung) zwischen den Vertragspartnern, die nicht durch das Eskalationsgremium (siehe Ziff. 0.1) geklärt werden können oder bei Scheitern einer Einigung nach Ziff. 0.2, soll die Deutsche Gesellschaft für Recht und Informatik (DGRI e.V.) als Schlichter angegangen werden. 0.3.2 DGRI Schlichtungsordnung Dies gilt vor allem im Falle von Streitigkeiten über diesen Vertrag oder über einzelne Bestimmungen dieses Vertrages. Die Schlichtung erfolgt nach der jeweils geltenden Schlichtungsordnung der DGRI. 0.3.3 Hemmung der Verjährung Die Verjährung für alle Ansprüche aus dem streitigen Lebenssachverhalt ist ab dem Schlichtungsantrag bis zum Ende des Schlichtungsverfahrens gehemmt, § 203 BGB gilt entsprechend.

Witzel

847

I. Softwarepflege inklusive Service-Level-Agreement Rz. I. Einführung . . . . . . . . . . . . . . . . . . 1. Gründe für den Abschluss eines Softwarepflegevertrags . . . . a) Anbieterinteresse . . . . . . . . . . aa) Erhöhung des Überlassungsentgeltes für die Software . . . . . . . . . . . . . . . bb) Abschluss eines (zusätzlichen) Softwarepflegevertrags . . . . . . . . . . . . . . . . b) Anwenderinteresse. . . . . . . . . aa) Einsatz und Unterstützung bei der Nutzung der überlassenen Software. . . . . . . . . . . . . . . . . . . bb) Weiterentwicklung . . . . . (1) Technologische Weiterentwicklung . . . . . . (2) Inhaltlich-funktionelle Weiterentwicklung . . . . . . . . . . . . . . . . cc) Fehlerfreies Arbeiten der Software während des Nutzungszeitraums . . . . . 2. Abschluss eines Softwarepflegevertrags aufgrund aktueller Entwicklungen . . . . . . . . . . . . . . a) Corporate Governance . . . . . aa) Sarbanes-Oxley-Act . . . . . bb) Europäische Bestrebungen und Deutscher Corporate-GovernanceKodex . . . . . . . . . . . . . . . . . b) Sicherheit . . . . . . . . . . . . . . . . .

1

22 25

II. Begriffe. . . . . . . . . . . . . . . . . . . . . . 1. Softwarepflege . . . . . . . . . . . . . . . 2. Programmkorrekturen . . . . . . . . a) Umgehung . . . . . . . . . . . . . . . . b) Patch . . . . . . . . . . . . . . . . . . . . . c) Update . . . . . . . . . . . . . . . . . . . . d) Upgrade . . . . . . . . . . . . . . . . . . . e) Release/Version. . . . . . . . . . . .

30 33 38 40 41 42 43 44

1 2

4

7 10

11 12 13

15

17

18 19 20

III. Verpflichtung zum Abschluss eines Softwarepflegevertrags . . 45 1. Praktische Relevanz . . . . . . . . . . 48 2. Anspruchsgrundlagen . . . . . . . . 52

Rz. a) Vertragliche Ansprüche . . . . . aa) Besondere Vertragsbedingungen der öffentlichen Auftraggeber . . . . . . . . . . . bb) Nebenpflicht aus § 242 BGB . . . . . . . . . . . . . . (1) LG Köln: Unwirksamkeit einer ordentlichen Kündigung vor Beendigung des Software-Lebenszyklus’ . . (2) OLG Koblenz: Softwarepflege aufgrund ergänzender Vertragsauslegung . . . . . . . . . . . (3) Keine dauerhafte Pflicht zu Pflegeleistungen . . . . . . . . . . . . . . b) Gesetzliche Ansprüche . . . . . c) Tatsächliche Zwänge zum Abschluss eines Softwarepflegevertrages . . . . . . . . . . . . . aa) Quellcodeherausgabe. . . . bb) Schadensersatz wegen Vertragsverweigerung . . . cc) Schadensersatz wegen Verletzung der Aufklärungspflicht . . . . . . . . . . . .

52

52 53

54

58

60 63

68 69 70

72

IV. Rechtliche Einheit mit dem Softwareüberlassungsvertrag . . 75 1. Einheitliches Rechtsgeschäft . . 76 a) Rechtliche Einheit im ZweiPersonen-Verhältnis . . . . . . . . 77 aa) BGH-Rechtsprechung . . . 81 bb) Übertragung auf Softwareüberlassung und -pflege . . . . . . . . . . . . . . . . . 84 b) Rechtliche Einheit im DreiPersonen-Verhältnis . . . . . . . . 88 c) Rechtsfolgen. . . . . . . . . . . . . . . 97 aa) § 139 BGB . . . . . . . . . . . . . . 100 bb) Rücktritt und Schadensersatz . . . . . . . . . . . . . . . . . . 106 (1) Teilleistung . . . . . . . . . 110 (a) Auswirkungen der Schuldrechtsmodernisierung. . . 111

Peter

849

I

Sonderregelungen Rz.

Rz.

(b) BGH zur Teilbarkeit der Leistung vor der Schuldrechtsmodernisierung . . . . . . . . . . . . . 115 (c) Übertragung der BGH-Rechtsprechung auf das neue Schuldrecht . 118 (2) Interessenfortfall . . . . 119 (3) Abdingbarkeit des § 323 BGB . . . . . . . . . . 123 cc) Kündigung . . . . . . . . . . . . . 124 dd) Einwendungsdurchgriff . . . . . . . . . . . . . . . . . . . 128 2. Kündigung aus wichtigem Grund ohne Vorliegen einer rechtlichen Einheit . . . . . . . . . . . 134 3. Wegfall der Geschäftsgrundlage. . . . . . . . . . . . . . . . . . . . 138

(1) Abwälzung der Mängelbeseitigungspflicht auf den Mieter als verschuldensunabhängige Haftung . . . . . . . . . . . . . . . . . 168 (2) Formularmäßige Begründung einer verschuldensunabhängigen Haftung als grundsätzlich unangemessene Benachteiligung . . . . . 171 (3) Formularmäßige Verpflichtung zur Übernahme der Mängelbeseitigungskosten als verschuldensunabhängige Haftung . . . . . . . . . . . . . . . . . 172 (4) Ausgleich einer unangemessenen Benachteiligung . . . . . . . . . . . . . . . . . . . 173 (5) Berücksichtigung des Mängelbeseitigungsentgeltes in der Kalkulation des Softwareüberlassungsentgeltes . . . . . . . . . . . . . . . . 175 (a) Pauschales Entgelt für die Softwarepflege . . . . . 177 (aa) Haftung für vom Anbieter oder Hersteller schuldhaft herbeigeführte Mängel . . . . . . . . . . . 177 (bb) Ungleichbehandlung und unangemessene Benachteiligung . . . . . . . . . 180 (cc) Unzulässige Abwälzung des Beweislastrisikos auf den Softwareanwender . . . . . . . . . 183 (b) Aufwandsabhängiges Entgelt für die Mängelbeseitigung . . . . . . . . . . . 189 (c) Haftung nach Gefahrbereichen (Sphärenhaftung) . . . . . . . . . . . . . . . . . 190 bb) Keine fehlerfreie Software . . . . 192 cc) Entgeltlichkeit der Mängelbeseitigung als Verstoß gegen § 309 Nr. 2 BGB . . . . . . . . . . . . . 193

V. Kopplung von Softwareüberlassungs- und -pflegevertrag . . . . . . . . . . . . . . . . . . . . . . 139 VI. Sittenwidriger Softwarepflegevertrag . . . . . . . . . . . . . . . . . 145 VII. Vertragsgegenstand und Entgeltproblematiken . . . . . . . . . . . . 148 1. Verhältnis der Entgeltpflicht für Mängelbeseitigung zur Mängelhaftung aus dem Softwareüberlassungsvertrag . . . . . . 150 a) Drei-Personen-Verhältnis . . . 151 b) Individualvereinbarung . . . . . 154 aa) Individualvereinbarung über das Mängelbeseitigungsentgelt im Softwarepflegevertrag . . . . . . . 155 bb) Mängelbeseitigungsentgelt als Schaden? . . . . . . . 160 c) Verstoß gegen § 307 Abs. 2 BGB und das Transparenzgebot . . . . . . . . . . . . . . . . . . . . . 162 d) Zwingend geschuldete Mängelbeseitigung . . . . . . . . . 166 e) Stellungnahme . . . . . . . . . . . . 167 aa) Entgeltlichkeit der Mängelbeseitigung als unangemessene Benachteiligung . . . . . . . . . . . . . . . . . 168

850

Peter

I

Softwarepflege inklusive Service-Level-Agreement Rz.

Rz.

f) Praktische Erwägungen . . . . . 196 aa) Vergütung der Mängelbeseitigung. . . . . . 196 bb) Mängelbeseitigung nach Ablauf der Mängelhaftungsfrist . . . . . . . . . . . . . . 197 cc) Risiko der AGB-rechtlichen Unwirksamkeit bei entgeltlicher Mängelbeseitigung vor Ablauf der Mängelhaftungsfrist . . . . . . . . . . . . . . 198 dd) Risiko der steuerlichen Haftung bei Vereinbarung über die Unentgeltlichkeit der Mängelbeseitigung . . . . . . . . . . . . 199 g) Fazit . . . . . . . . . . . . . . . . . . . . . . 200 2. Preisanpassung . . . . . . . . . . . . . . 203 a) Grundsätzliches . . . . . . . . . . . 207 b) Preisklauselgesetz . . . . . . . . . 212 c) AGB . . . . . . . . . . . . . . . . . . . . . . 224 aa) Kostenelementeklauseln . . . . . . . . . . . . . . . 232 bb) Preisvorbehaltsklauseln . 241 cc) Spannungsklauseln . . . . . 246 dd) Ausgleich einer unangemessenen Benachteiligung . . . . . . . . . . . . . . . 250 (1) Höherrangige Interessen . . . . . . . . . . 252 (2) Gewährung eines rechtlichen Vorteils . . 254 d) Ergänzende Vertragsauslegung . . . . . . . . . . . . . . . . . . . . 265 e) Individualvereinbarung . . . . . 266 3. Gegenstand der Pflege . . . . . . . . 269 a) Maßgebliche Softwareversion. . . . . . . . . . . . . . . . . . . . 269 b) Verweigerung der Übernahme einer Pflegelieferung durch den Softwareanwender. . . . . . . . . . . . . . . . . . . . 272 c) Einstellen der Pflege für einen alten Programmkorrekturstand . . . . . . . . . . . . 281 aa) Programmkorrekturen und deren Auswirkungen . . . . . . . . . . . . . . . . 282 bb) Interessenlage . . . . . . . . . . 284

cc) Ausdrückliche Vereinbarung . . . . . . . . . . . . . . . . . 288 dd) Fehlende Vereinbarung . . 292 VIII. Laufzeit der Pflege und Kündigung . . . . . . . . . . . . . . . . . . . 294 1. Laufzeit der Pflege . . . . . . . . . . . . 294 a) Beginn der Pflege . . . . . . . . . . . 295 aa) Differenzierend nach Pflegeleistungsteil . . . . . . 295 bb) Konflikte mit Leistungen aus dem Softwareüberlassungsvertrag . . . . . 301 b) Laufzeit des Softwarepflegevertrags . . . . . . . . . . . . . . . . . . . 306 aa) Individualvereinbarung . . 306 bb) Öffentliche Ausschreibung . . . . . . . . . . . . . . . . . . . 309 cc) Formularklauseln . . . . . . . 311 (1) Verbraucherverkehr . . 311 (2) Unternehmensverkehr . . . . . . . . . . . . . . . . 314 2. Kündigung . . . . . . . . . . . . . . . . . . . 319 a) Vertraglich vereinbarte Kündigung . . . . . . . . . . . . . . . . 320 b) Kündigungsrecht des Softwareanwenders nach § 649 BGB . . . . . . . . . . . . . . . . . 322 aa) Anwendbarkeit des § 649 BGB auf den Softwarepflegevertrag . . . . . . . 324 bb) Abdingbarkeit des § 649 BGB . . . . . . . . . . . . . . 338 c) Außerordentliche Kündigung . . . . . . . . . . . . . . . . . . . . . . 346 d) End-of-Life-Schreiben und Rechtsmissbrauch. . . . . . . . . . 350 IX. Art und Umfang der Pflegeleistung . . . . . . . . . . . . . . . . . . . . . 358 1. Fernpflege, Erfüllungsort und Datenschutz . . . . . . . . . . . . . . . . . 358 a) Fernpflege/Erfüllungsort . . . . 358 b) Datenschutz . . . . . . . . . . . . . . . 365 2. Einsatz der Software auf vorgegebener Systemumgebung . . . 375 a) Verletzung der Systemumgebung-Einsatzobliegenheit . 380 b) Mängelrüge trotz Verletzung der Systemumgebung-Einsatzobliegenheit . . . . . . . . . . . 382

Peter

851

I Rz. 1

Sonderregelungen Rz.

Rz.

3. Programmkorrekturen, Installationen und Hotline . . . . . . . . . 389 a) Programmkorrekturen. . . . . . 394 aa) Mängelbeseitigung. . . . . . 395 bb) Störungsbeseitigung . . . . 402 cc) Funktionale Verbesserungen, Anpassungen, zusätzliche oder geänderte Funktionen und sonstige Anpassungen/ Korrekturen . . . . . . . . . . . . 411 dd) Nachführen . . . . . . . . . . . . 418 ee) Dokumentation . . . . . . . . 424 b) Installationsleistungen . . . . . 433 c) Hotline . . . . . . . . . . . . . . . . . . . 445

(3) Reaktions- und Wiederherstellungszeiten 489 bb) Reporting . . . . . . . . . . . . . . 491 cc) Verfügbarkeit des Service-Levels . . . . . . . . . . 492 dd) Sanktionen . . . . . . . . . . . . . 493 ee) Vertragstypologische Einordnung, Verhältnis allgemeines Leistungsstörungsrecht zu Mängelhaftung . . . . . . . . . . . . . 497 b) Funktionale Verbesserungen, Anpassungen, zusätzliche oder geänderte Funktionen und sonstige Anpassungen/Korrekturen . . 501 aa) Service-Level und Reporting . . . . . . . . . . . . . . 502 bb) Verfügbarkeit des Service-Levels und Sanktionen . . . . . . . . . . . . . 503 4. Hotline . . . . . . . . . . . . . . . . . . . . . . 504 a) Service-Level und Reporting. 505 b) Verfügbarkeit und Sanktionen . . . . . . . . . . . . . . . . 509 5. Mitwirkungspflichten des Softwareanwenders . . . . . . . . . . . 513 6. Eskalationsprozess . . . . . . . . . . . 515

X. Vertragstypologische Einordnung . . . . . . . . . . . . . . . . . . . . . . . . 458 1. Allgemeines . . . . . . . . . . . . . . . . . 458 2. Typenmischung . . . . . . . . . . . . . . 462 3. Leistungsteile. . . . . . . . . . . . . . . . 465 4. Typisierung eines gemischten Vertrages . . . . . . . . . . . . . . . . . . . . 471 5. Rechtsprechung . . . . . . . . . . . . . . 472 XI. Service-Level-Agreement . . . . . 473 1. Einführung . . . . . . . . . . . . . . . . . . 473 2. Abgrenzung zur Mängelhaftung . . . . . . . . . . . . . . . . . . . . . 481 3. Programmkorrekturen . . . . . . . . 483 a) Mängel- und Störungsbeseitigung . . . . . . . . . . . . . . . . 483 aa) Service-Level . . . . . . . . . . . 484 (1) Mängel- bzw. Störungsklassifikation . . 484 (2) Proaktive/nicht proaktive Mängel- bzw. Störungsbeseitigung . 486

XII. Sonstiges . . . . . . . . . . . . . . . . . . . . 520 1. Nutzungsrechte . . . . . . . . . . . . . . 520 2. Pflichten und Obliegenheiten des Softwareanwenders . . . . . . . 521 3. Mängelhaftung versus Erfüllungsanspruch und Verjährung . 522 4. Vertragsübernahme und Herausgabe/Hinterlegung des Quellcodes. . . . . . . . . . . . . . . . . . . 535

I. Einführung 1. Gründe für den Abschluss eines Softwarepflegevertrags 1

Um die unterschiedlichen Interessenlagen1 der Softwareanbieter2 und -anwender für oder gegen den Abschluss bzw. für oder gegen gewisse Inhalte ei1 Intveen, ITRB 2003, 128; Schneider, Handbuch des EDV-Rechts, K. Rz. 1. 2 Zahrnt, Computervertragsrecht, Kapitel 14 vor 14.1 unterscheidet zusätzlich den Lieferanten vom Anbieter, der unter Umständen zwischen Anbieter und Anwender stehe. Im Folgenden wird der Hersteller der überlassenen Software „Soft-

852

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 5 I

nes Softwarepflegevertrags einzuschätzen bzw. verstehen zu können, werden nachfolgend einige wesentliche – nicht abschließende – Konstellationen und Zielsetzungen dargestellt. a) Anbieterinteresse Das Geschäftsmodell des Softwareanbieters ist u.a. dadurch geprägt, dass 2 Software ab einer gewissen Komplexität nicht fehlerfrei hergestellt werden kann, was im juristischen Schrifttum und in der Rechtsprechung grundsätzlich anerkannt ist1. Dies führt zu der unweigerlichen Folge und Erkenntnis, dass Softwareanbie- 3 ter die Kosten für die Aufwände der zukünftigen Fehlerbeseitigung in ihren Business Cases2 berücksichtigen müssen. Das lässt sich grundsätzlich auf zwei Wegen realisieren. aa) Erhöhung des Überlassungsentgeltes für die Software Zum einen können die Kosten des Softwareanbieters für die zukünftigen 4 Fehlerbeseitigungsaufwände in das Entgelt für die erstmalige Überlassung der Software eingerechnet werden. Diese Vorgehensweise bringt zwangsläufig zumindest zwei Nachteile für 5 die Softwareanbieter mit sich. Auf der einen Seite lässt sich mangels sicherer Annahmen nicht klar bestimmen, wie hoch der zukünftige Anteil des Überlassungsentgelts für die Fehlerbeseitigung sein soll. Darüber hinaus – und das kommt bei Standardsoftware (im Gegensatz zur Erstellung einer Individualsoftware) noch hinzu – besteht die größte Ungewissheit für die Festlegung des Anteils darin, wie der Markt auf die Einführung einer neuen Standardsoftware reagieren wird, denn je größer die Verkaufszahl der Standardsoftware ist, desto kleiner kann der Entgeltanteil berechnet werden, da der Aufwand für die Fehlerbeseitigung im Wesentlichen gleich bleibt. Die Absenkung des Softwareüberlassungsentgelts erhöht regelmäßig die Wettbewerbsfähigkeit im Markt, soweit der Softwareanbieter kein Monopolanbieter ist, der sich ggf. anderweitige Preisstrategien erlauben kann. warehersteller“ genannt; derjenige, der den Pflegevertrag mit dem Softwareanwender abschließt, heißt nachfolgend „Softwareanbieter“. 1 Zahrnt, CR 2004, 408; Schneider, Handbuch des EDV-Rechts, A. Rz. 39 ff.; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge 1.12 Softwarepflege Rz. 37; Marly, Praxishandbuch Softwarerecht, Rz. 1362 m.w.N. Dies wird – so Marly – im Wesentlichen damit begründet, dass die menschliche Auffassungsgabe und Einsicht nicht ausreicht, um komplexe Systeme im notwendigen Ausmaß überschauen zu können. 2 Business Case, http://www.projektmagazin.de/glossar/gl-0402.html: Ein Business Case ist ein Szenario zur betriebswirtschaftlichen Beurteilung einer Investition. Auch ein Projekt stellt aus Sicht des Anbieters eine Investition dar. Der Business Case eines Projekts beschreibt, wie und in welchem Zeitraum seine Ergebnisse dem anbietenden Unternehmen Gewinn bringen.

Peter

853

I Rz. 6 6

Sonderregelungen

Auf der anderen Seite führt die Erhöhung des erstmaligen Überlassungsentgelts für die Software zu einer Erweiterung der vom Softwareanwender zu tätigenden Investition bzw. vergrößert die monatliche Belastung seines Budgets, was sich in seiner Gewinn- und Verlustrechnung negativ niederschlägt. Damit verliert das Softwareprodukt an Nachfrageakzeptanz und die vertrieblichen Produktabsatzchancen sinken. bb) Abschluss eines (zusätzlichen) Softwarepflegevertrags

7

Ein Ausweg aus dem vorbezeichneten Dilemma besteht in der Möglichkeit, die zukünftigen Aufwände für die Beseitigung von Fehlern mit einem gesondert abzuschließenden Softwarepflegevertrag vergütet zu erhalten, in dessen Rahmen üblicherweise zusätzliche Leistungen des Softwareanbieters nachgefragt werden. Damit wird die Nachfrageakzeptanz für die erstmalige Softwareüberlassung erhöht, weil der Softwarepflegevertrag von dem eigentlichen Investment losgelöst wird und vom Softwareanwender – unter Kosten- und Buchführungsgesichtspunkten – gesondert betrachtet werden kann.

8

Diese Vorgehensweise führt sofort zu der – in der juristischen Literatur intensiv umstrittenen – Frage der Zulässigkeit einer Vergütung von Leistungen der Softwarepflege für Maßnahmen der Mängelbeseitigung (Rz. 150 ff.) und der weiteren Frage nach der Zulässigkeit einer Kopplung des Softwareüberlassungsvertrags mit einem Softwarepflegevertrag (Rz. 139 ff.).

9

Unabhängig von der Beantwortung der beiden vorgenannten Fragen soll an dieser Stelle auf das Folgende hingewiesen werden: Die Kosten, die dem Softwareanbieter für Mängelbeseitigung entstehen, muss er sich gezwungenermaßen vergüten lassen bzw. muss die Geschäftsleitung des Softwareanbieters in der Entgeltkalkulation angemessen berücksichtigen. Die Geschäftsleitung leitet das Unternehmen in eigener Verantwortung im Unternehmensinteresse, also unter Berücksichtigung der Belange der Aktionäre, seiner Arbeitnehmer und der sonstigen dem Unternehmen verbundenen Gruppen (Stakeholder) mit dem Ziel nachhaltiger Wertschöpfung1. Ob die Kosten für die Mängelbeseitigung im Zusammenhang mit der Kalkulation für das Entgelt der Softwareüberlassung oder bei der Softwarepflege berücksichtigt werden, ist zunächst eine geschäftspolitisch zu beantwortende Frage des Softwareanbieters bzw. Verhandlungssache mit dem Softwareanwender2.

1 Vgl. Ziff. 4.1.1 der im elektronischen Bundesanzeiger bekannt gemachten Empfehlungen der „Regierungskommission Deutscher Corporate Governance Kodex“ v. 26.5.2010 für börsennotierte Unternehmen in der BRD. Dieser Grundsatz dürfte nicht nur für börsennotierte Unternehmen gelten. 2 Zahrnt, CR 2004, 408.

854

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 13 I

b) Anwenderinteresse Der Anwender hat in erster Linie ein Investitionssicherungs- bzw. -erhal- 10 tungsinteresse. Je nachdem, wie wichtig ihm die Nutzung und der Einsatz der ihm überlassenen Software ist1, desto größer wird sein vorbezeichnetes Interesse ausgeprägt sein. aa) Einsatz und Unterstützung bei der Nutzung der überlassenen Software Dem Softwareanwender ist zunächst daran gelegen, dass die ihm überlasse- 11 ne Software baldmöglichst und fehlerfrei arbeitet. Damit der Softwareanwender den baldigen Einsatz der überlassenen Software sicherstellen kann, benötigt er – abhängig vom Grad der Komplexität der Software – eine Einweisung bzw. Schulung derjenigen Personen, die mit der Software arbeiten sollen, was üblicherweise bereits im Rahmen der Softwareüberlassung vereinbart wird. Darüber hinaus muss der Softwareanwender die Möglichkeit haben, über einen längeren Zeitraum Fragen z.B. zur Funktionsweise der Software an den Softwareanbieter stellen zu können (Hotline), soweit er Probleme, welche sich mit zukünftiger Überlassung von Programmkorrekturen (zum Begriff s. Rz. 38) erweitern oder verändern können, nicht mithilfe der Benutzerdokumentation bzw. des Handbuchs, die bereits zum Umfang der Leistungspflicht des Softwareanbieters bei Softwareüberlassung gehören2, klären kann. Für die Hotlineleistungen benötigt der Softwareanwender daher einen zusätzlichen Vertrag: den Softwarepflegevertrag. bb) Weiterentwicklung Der Aspekt „Weiterentwicklung“ hat im Kern zwei Facetten. Die technolo- 12 gische Weiterentwicklung der Software in Abhängigkeit von der Weiterentwicklung aller Computerbestandteile und die inhaltlich-funktionelle Weiterentwicklung der Software. (1) Technologische Weiterentwicklung Ausgehend von den Prämissen, dass Software allein nicht nutzbar ist, son- 13 dern nur im Zusammenspiel mit weiterer Software (Applikations-, ggf. Middleware- und Betriebssoftware) sowie Hardware arbeitet, und sämtliche Bestandteile dieses technischen Konglomerats zusammen funktionieren müssen und von unterschiedlichen Herstellern technologisch weiterent1 Computerwoche Newsletter v. 26.7.2005: Nils Niehörster, Geschäftsführer des Beratungshauses Raad Consult glaubt, dass SAP ihre Preismodelle zukünftig nicht mehr nach der Zahl der Nutzer, sondern daran ausrichten wird, welchen Wert einzelne softwaregestützte Prozesse für den Kunden haben; s. auch Sonja Lehmann, Preisstrategien in der Softwareindustrie: Gestaltung, Einflussfaktoren und Erfolgsauswirkungen der Bemessungsgrundlage, 2011. 2 BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207; BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367; Seffer/Horter, ITRB 2005, 169; Marly, Praxishandbuch Softwarerecht, Rz. 604.

Peter

855

I Rz. 14

Sonderregelungen

wickelt werden1, wird deutlich, welche Anforderungen an die Entwicklungsabteilungen des Softwareanbieters gestellt werden. 14 Die Interessenlage des Softwareanwenders kann an diesem Punkt unterschiedlich ausgestaltet sein: – Abhängig vom Einsatz bzw. von der Anwendung der Software ist der Softwareanwender an einer Weiterentwicklung gar nicht interessiert2. – Wirkt die ihm überlassene Software hingegen mit anderer – ständig weiterentwickelter – Software zusammen oder möchte er die Errungenschaften neuester technologischer Entwicklungen im Soft- oder Hardwarebereich nutzen, die im Zusammenhang mit der ihm überlassenen Software arbeiten sollen, ist der Softwareanwender auf den Einsatz der aktuellen Computerkomponenten angewiesen, da nur diese in der Regel ordnungsgemäß zusammenarbeiten3. Daher erwartet der Softwareanwender sogar eine entsprechende Weiterentwicklung der Software durch den Softwareanbieter4. (2) Inhaltlich-funktionelle Weiterentwicklung 15 Daneben kann das Interesse des Softwareanwenders darauf gerichtet sein, dass der Softwareanbieter die Software inhaltlich in Bezug auf die Anwenderfunktionalitäten an die allgemeine Fortentwicklung anpasst: Z.B. soll er die Software an geänderte rechtliche Bestimmungen oder sonstige zwingend zu berücksichtigende oder nützliche Veränderungen angleichen5. 16 Beides, die technologische wie auch die inhaltlich-funktionelle Weiterentwicklung, werden von der reinen Softwareüberlassung grundsätzlich nicht

1 Nach dem sog. Murphy-Gesetz können Programme, sobald diese arbeiten, bereits wieder veraltet sein. 2 Will der Softwareanbieter nur einfache Texte schreiben, reicht ihm z.B. MS Word 95 völlig aus. 3 Die Weiterentwicklungen der Computerkomponenten bedingen sich gegenseitig und aus vielfältigsten Gründen: Z.B. führt die Erweiterung von Softwarefunktionalitäten zur Vergrößerung des die Software benötigten Speicherplatzes; je komplexer die vom Programm durchzuführenden Rechenoperationen sind, desto schnellere Prozessoren werden benötigt. Schnellere Prozessoren ermöglichen auf der anderen Seite erst die Programmierung entsprechender Softwarefunktionalitäten. Die Folge hiervon ist die Entwicklung neuer Hard- und Software, die nur zusammen ordnungsgemäß arbeitet. Zu der Frage der gewöhnlich geschuldeten Kompatibilität von Software mit anderen, zusammenwirkenden DV-Produkten bei der Softwareüberlassung, vgl. OLG Stuttgart, in: Zahrnt, Entscheidungen zum Computerrecht-ECR, OLG 290; OLG Köln, in: Zahrnt, Entscheidungen zum Computerrecht-ECR, OLG 232; OLG Köln, in: Zahrnt, Entscheidungen zum Computerrecht-ECR, OLG 197; Marly, Praxishandbuch Softwarerecht, Rz. 1442 ff. mit zahlreichen weiteren Beispielen aus der Rechtsprechung. 4 Zahrnt, CR 2004, 408. 5 Zahrnt, CR 2004, 408.

856

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 19 I

erfasst1 und bedürfen der zusätzlichen Vereinbarung in einem Softwarepflegevertrag. cc) Fehlerfreies Arbeiten der Software während des Nutzungszeitraums Das Interesse des Softwareanwenders, dass die überlassene Software wäh- 17 rend des beabsichtigten Nutzungszeitraumes fehlerfrei arbeitet, liegt auf der Hand. Insbesondere bei größeren Investitionsprojekten ist davon auszugehen, dass der Nutzungszeitraum den Zeitraum überschreitet, innerhalb dessen Fehlerbeseitigung im Weg der Mängelhaftung geltend gemacht werden kann. Außerdem ist denkbar, dass der Softwareanwender zukünftige zusätzliche Funktionalitäten nutzen möchte, deren Überlassung vertraglich nicht vereinbart ist und die der Softwareanbieter/-hersteller erst mit den nächsten Programmkorrekturen (zum Begriff s. Rz. 38) ausliefert. Beide vorbezeichneten Fälle kann der Softwareanwender nur mit dem Abschluss eines zusätzlichen Softwarepflegevertrags absichern. 2. Abschluss eines Softwarepflegevertrags aufgrund aktueller Entwicklungen Auch der immer weiter fortschreitende globale Wettbewerb (nachfolgend 18 unter Rz. 19 ff.) und das sich ständig steigernde Sicherheitsbedürfnis (nachfolgend unter Rz. 25 ff.) stellt immer größere Anforderungen an die Anwenderunternehmen und die Softwareanbieter. Beide Prämissen drängen – je nach Einsatz und Anwendung von Softwarelösungen – Vereinbarungen über Softwarepflege zusätzlich auf, um den gestellten Anforderungen gerecht zu werden. a) Corporate Governance Mehrere US-Bilanzskandale2 haben im Jahr 2001 die internationale Wirt- 19 schaftswelt aufgeschreckt. In diesem Zusammenhang wurde im Juli 2005 der ehemalige CEO des US-Telekommunikationsriesen Worldcom Bernie Ebbers von einem New Yorker Gericht zu 25 Jahren Haftstrafe verurteilt. Ebbers hatte seine 1983 gegründete Telefongesellschaft durch mehr als 60 aggressive Zukäufe zum zweitgrößten US-Telekomkonzern mit einem Umsatz von ungefähr 35 Mrd. US-Dollar in 2001 gemacht. Da die den Analysten in Aussicht gestellten Wachstumsraten nicht einzuhalten waren und um einen Einbruch der Aktienkurse zu verhindern, fälschte Worldcom die Bilanzen mit Fehlbuchungen in Höhe von rund 11 Mrd. US-Dollar, so dass das Unternehmen unter massiven Finanzproblemen zusammenbrach. Daraufhin verloren ca. 20 000 Mitarbeiter ihre Arbeitsplätze und ihre gesam1 In diesem Zusammenhang soll nicht auf die Beantwortung der Frage eingegangen werden, ob im Falle der Überlassung einer Software im Rahmen eines Dauerschuldverhältnisses entsprechende Pflichten zur Weiterentwicklung bestehen bzw. in welchem Umfange diese bestehen können. 2 Z.B. Worldcom und Enron. S.a. http://de.wikipedia.org/wiki/MCI_WorldCom.

Peter

857

I Rz. 20

Sonderregelungen

ten Pensionsrücklagen, soweit diese in Worldcom-Aktien investiert waren. Investoren büßten ca. 180 Mrd. US-Dollar ein. Inzwischen ist das Unternehmen saniert, stark geschrumpft und – von Verizon Communications übernommen – wieder am Markt. aa) Sarbanes-Oxley-Act 20 Als Folge der genannten US-Bilanzskandale wurde auf Initiative der beiden US-Kongressabgeordneten Paul Sarbanes und Michael Oxley durch den USKongress ein Kapitalmarktgesetz zur Verschärfung der Rechnungslegungsvorschriften erlassen, der sog. Sarbanes-Oxley-Act (SOX). Abschnitt 404 des SOX schreibt vor, dass ein effektives internes Kontrollsystem die Zuverlässigkeit der Finanzberichterstattung dokumentieren und nachweisen muss; dies ist von unabhängigen Wirtschaftsprüfern jährlich zu testieren. Von dieser Verpflichtung sind alle an den amerikanischen US-Börsen notierten Unternehmen und ab 2006 alle nicht-amerikanischen Gesellschaften unmittelbar betroffen. Dazu gehören viele deutsche Großunternehmen. Indirekt von SOX betroffen sind deren Tochterunternehmen und Zuliefererfirmen1. Verstößt ein Unternehmen gegen Vorschriften des SOX, können die Verantwortlichen strafrechtlich verfolgt und empfindliche Bußgelder ausgesprochen werden2. Die Zielsetzung von SOX ist klar: Mehr Transparenz in den Unternehmen, striktere Überwachung des Managements, bessere interne Kontrolle, um die desaströsen „plötzlichen“ Niedergänge von Giganten, wie z.B. Worldcom, in Zukunft zu vermeiden. Die Ausgestaltung von SOX obliegt, dies ist eine US-amerikanische Besonderheit, der US Securites and Exchange Commission (SEC)3, so dass die Festlegung von Einzelheiten ständig im Fluss ist4. Die Auswirkungen des SOX auf die Unternehmensüberwachung sind beträchtlich5: Vor allem müssen die unternehmensinternen Abläufe neu gestaltet werden. Jedes betroffene Unternehmen muss seine eigenen SOX-relevanten Prozesse und Kontrollsysteme prüfen und dokumentieren. Die Kontrollsysteme liefern den Unternehmen und den Wirtschaftsprüfern den Nachweis, dass ihre internen Kontrollsysteme wirksam sind und dass die Systeme, aus denen die Zahlen und Informationen generiert werden, zuverlässig arbeiten. Soweit die internen Kontrollsysteme softwarebasiert unterstützt werden, ist selbstverständlich, dass diese und erst recht sämtliche sonstigen finanzrelevanten Softwareapplikationen und ITProzesse den SOX-Anforderungen der betroffenen Kunden genügen müssen. Da sich die wirtschaftlichen und organisatorischen Rahmenbedingungen für und in den Unternehmen ständig ändern, liegt es auf der Hand, dass das 1 Sect. 404 SOX. Nähere Einzelheiten hierzu z.B. unter http://www.kpmg.de/to pics/Sarbanes-Oxley_5405.htm. 2 Sect. 906 SOX. 3 Hütten/Stroman, BB 2003, 2223. 4 http://www.sec.gov. 5 Arbeitskreis „Externe und interne Überwachung der Unternehmung“ der Schmalenbach-Gesellschaft für Betriebswirtschaft e.V., BB 2004, 2399.

858

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 23 I

interne Kontrollsystem und die finanzrelevanten Softwareapplikationen an die Veränderungen der Rahmenbedingungen ständig angepasst werden müssen. Die betreffende Software ist somit laufend anzupassen und weiterzuentwickeln. Wenn und soweit Unternehmen Waren oder Dienstleistungen zuliefern, die 21 bei Kundenunternehmen SOX-relevante Auswirkungen bedingen, sind damit Zuliefererunternehmen von SOX indirekt betroffen. Sie müssen dafür Sorge tragen, dass ihre Waren und Dienstleistungen den SOX-Anforderungen ihrer betroffenen Kunden angepasst werden. bb) Europäische Bestrebungen und Deutscher CorporateGovernance-Kodex Beeinflusst von den amerikanischen Firmenzusammenbrüchen zeichneten 22 sich nachfolgend – den amerikanischen Vorgaben sich annähernde – Legislativinitiativen1 auf europäischer Ebene ab2. In der Bundesrepublik Deutschland wurde insbesondere das Transparenz- und Publizitätsgesetz vom 19.7.20023 erlassen, mit dessen Art. 1 Nr. 16 der § 161 in das Aktiengesetz wieder eingeführt wurde. Danach müssen die Vorstände und Aufsichtsräte der in der BRD börsennotierten Unternehmen jährlich eine Erklärung dazu abgeben, ob und inwieweit dem vom Bundesministerium der Justiz im Bundesanzeiger bekannt gemachten Empfehlungen der „Regierungskommission Deutscher Corporate Governance Kodex“ entsprochen wurde und wird oder inwieweit dies nicht der Fall ist. Dieser Kodex4 enthält weitere dezidierte Vorgaben zu den Aufgaben und Zuständigkeiten des Vorstands und des Aufsichtsrats zur Transparenz sowie zur Rechnungslegung und Abschlussprüfung5. Nach Nr. 4.1.3 und 4.1.4 hat der Vorstand insbesondere die Einhaltung der gesetzlichen Bestimmungen zu gewährleisten und auf deren Beachtung durch die Konzernunternehmen hinzuwirken; außerdem sorgt der Vorstand für ein angemessenes Risikomanagement und Risikocontrolling im Unternehmen. Bereits 1998 trat das Gesetz zur Kontrolle und Transparenz im Unterneh- 23 mensbereich – KonTraG –6 in Kraft, nach dessen Art. 1 Nr. 9 der § 91 AktG einen zweiten Absatz erhielt. Danach hat der Vorstand geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende Entwicklungen früh erkannt 1 Maul/Lanfermann, BB 2004, 1861. 2 KOM (2003) 286: Mitteilung der Kommission an den Rat und das Europäische Parlament: Stärkung der Abschlussprüfung in der EU. 3 BGBl. I 2002, 2681. 4 Wernsmann/Gatzka, NZG 2011, 1001, Der Deutsche Corporate Governance Kodex und die Entsprechenserklärung nach § 161 AktG – Anforderungen des Verfassungsrechts. 5 Veröffentlichung im elektronischen Bundesanzeiger und unter http://www.corpo rate-governance-code.de. 6 BGBl. I 1998, 786.

Peter

859

I Rz. 24

Sonderregelungen

werden. Im Kern ist damit die Einführung eines Risikomanagementsystems gemeint. Diese Verpflichtung gilt für alle deutschen Aktiengesellschaften und soll analog auf andere Unternehmensformen Anwendung finden1. 24 Üblicherweise werden internes Risikomanagement und -controlling softwarebasiert unterstützt; ebenso wie im Fall der Umsetzung der SOX-Anforderungen müssen diese Softwareapplikationen wie auch sämtliche finanzund risikorelevanten Softwareapplikationen an die Veränderungen der Rahmenbedingungen ständig angepasst werden. Die betreffende Software ist somit aus „Corporate Governance-Gründen“ laufend anzupassen und weiterzuentwickeln. b) Sicherheit 25 Die Ausfallsicherheit von IT-Systemen und der Schutz gegen unberechtigte Angriffe auf IT-Systeme sind elementare und fortlaufend steigende Grundbedürfnisse in der Gesellschaft2. Insbesondere vor dem Hintergrund der zweiten vorgenannten Alternative hat der Rat der Europäischen Union unter dem 24.2.2005 einen Rahmenbeschluss über Angriffe auf Informationssysteme3 erlassen4. Dieser stellt darauf ab, dass durch Angleichung der einzelstaatlichen Strafrechtsvorschriften bei Angriffen auf Informationssysteme die Zusammenarbeit zwischen den Justiz- und sonstigen zuständigen Behörden einschließlich der Polizei und anderer spezialisierter Strafverfolgungsbehörden der Mitgliedstaaten verbessert werden soll5. Grund hierfür seien insbesondere potenzielle Gefahren durch Angriffe und Terroranschläge auf Informationssysteme, die Teil der kritischen Infrastruktur der Mitgliedstaaten seien. Das Ziel des Aufbaus einer sichereren Informationsgesellschaft und eines Raums der Freiheit, der Sicherheit und des Rechts werde hierdurch gefährdet; daher bedürfe es Gegenmaßnahmen auf Ebene der Europäischen Union6. 26 Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM)7 stellt in seinem Internetauftritt8 zum Thema Soft1 Hassemer, ITRB 2004, 253, 255 Fn. 18. 2 S. das Vorwort des Präsidenten des Bundesamtes für Sicherheit in der Informationstechnik (BSI), im Leitfaden „Informationssicherheit“ des BSI. 3 Rahmenbeschluss 2005/222/JI des Rates. 4 Im Einzelnen hierzu vgl. Gercke, CR 2005, 468. 5 1. Erwägungsgrund zum Rahmenbeschluss 2005/222/JI des Rates. 6 2. Erwägungsgrund zum Rahmenbeschluss 2005/222/JI des Rates. 7 Die BITKOM ist nach eigenen Angaben: Das Sprachrohr der IT-, Telekommunikations- und Neue-Medien-Branche. BITKOM vertritt mehr als 1350 Unternehmen, davon über 1000 Direktmitglieder. Hierzu gehören fast alle Global Player sowie 700 leistungsstarke Mittelständler. Die BITKOM-Mitglieder erwirtschaften 135 Milliarden Euro Umsatz und exportieren Hightech im Wert von 50 Milliarden Euro. BITKOM repräsentiert damit ca. 90 % des deutschen ITK-Markts. Vgl. www.bitkom.org. 8 www.bitkom.org.

860

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 29 I

ware, IT-Services und Sicherheit u.a. heraus, dass nahezu alle Geschäftsprozesse inzwischen auf digitalisierte Informationen zugreifen und auf eine zuverlässige IT- und Kommunikationsinfrastruktur angewiesen sind. Sicherheitslücken in der Wertschöpfungskette bedrohen den Unternehmenserfolg und können sogar existenzgefährdend sein1. Beispielsweise kann die Geschäftsleitung eines Unternehmens bei Missachtung des erforderlichen Risikomanagements persönlich in Haftung genommen werden2. Der deutsche Bundesinnenminister und der Präsident des Bundesamts für 27 Sicherheit in der Informationstechnik (BSI) haben am 18.8.2005 auf der Bundespressekonferenz den ersten Bericht zur Lage der IT-Sicherheit in Deutschland vorgestellt3, der seitdem durch das BSI jährlich aktualisiert wird. Die Attacken aus dem Internet können große Konzerne, Behörden oder private Internetsurfer – mithin jedermann – treffen. Der BSI-Lagebericht „Die Lage der IT-Sicherheit in Deutschland 2011“ macht deutlich, dass die aktuellen Gefährdungen wie Cyber-Angriffe, Angriffe auf mobile Endgeräte und Attacken, die auch außerhalb der klassischen IT greifen, eine Herausforderung für Politik, Wirtschaft und Gesellschaft bedeuten. Trendthemen wie „Cloud Computing“ und „Smart Meter“ werden Anbieter, Nutzer und auch das BSI im Hinblick auf Risikomanagement und die Gewährleistung von Informationssicherheit künftig stark beschäftigen.“4 Auch große internationale Monopolunternehmen haben zwischenzeitlich ihre Geschäftsstrategie geändert und stellen u.a. Sicherheitsaspekte in den Mittelpunkt ihrer Produktstrategie5.

28

Wegen des sich ständig ändernden IT-Sicherheitsniveaus6 ist Software einer 29 fortwährenden Anpassung und Weiterentwicklung unterworfen, zumal es sich Softwareanbieter aus Wettbewerbsgründen nicht leisten können, die 1 www.bitkom.org. 2 Gemäß § 91 Abs. 2 und § 93 Abs. 2 AktG haftet der Vorstand einer Aktiengesellschaft persönlich, wenn er Entwicklungen, die zukünftig ein Risiko für das Unternehmen darstellen könnten, nicht durch ein Risikomanagement überwacht und durch geeignete Maßnahmen vorbeugt. Geschäftsführern einer GmbH wird nach § 43 Abs. 1 GmbHG die Sorgfalt eines ordentlichen Geschäftsmannes auferlegt. Nach § 317 Abs. 4 HGB haben die Abschlussprüfer die in § 91 Abs. 2 AktG genannten Pflichten eines Vorstands eines börsennotierten Unternehmens zu überprüfen. Weiterhin verpflichtet das Handelsgesetzbuch Abschlussprüfer zu prüfen, ob die Risiken der künftigen Entwicklung zutreffend dargestellt sind (§ 317 Abs. 2 HGB). 3 Pressemeldungen des BSI, downloadbar unter: http://www.bsi.bund.de/Presse. 4 S. auch Lensdorf, CR 2007, 413: IT-Compliance – Maßnahmen zur Reduzierung von Haftungsrisiken von IT-Verantwortlichen. 5 Microsoft stellte auf der Münchener Messe SYSTEMS 2005 v. 24. bis 28.10.2005 das Thema IT-Sicherheit in den Mittelpunkt, in Newsletter Computerwoche v. 29.9.2005 16:48. S.a.: www.microsoft.de/Sicherheit. 6 Peter, CR 2005, 404 (409) und Fn. 59.

Peter

861

I Rz. 30

Sonderregelungen

Geschäftsleitung ihrer Kunden wegen mangelnder Sicherheit ihrer Produkte drakonischen Konsequenzen auszusetzen.

II. Begriffe 30 Im Zusammenhang mit der Softwarepflege benutzen Softwareanbieter und Softwareanwender eine Vielzahl von Begriffen, deren Bedeutungen sich mangels gesetzlicher Definition nur mit nicht unerheblichem Aufwand erschließen lassen; dies gilt sogar für den Begriff der „Softwarepflege“ selbst. 31 Vor diesem Hintergrund ist es angezeigt, die im Softwarepflegevertrag genutzten Begrifflichkeiten zu definieren und in den Vertragstext – wie im anglo-amerikanischen Rechtsraum üblich – ein Kapitel „Definitionen“ aufzunehmen, um größtmögliche Klarheit und Einvernehmen der Vertragsparteien über die Inhalte der im Vertrag enthaltenen Begriffe zu erzielen. Letztlich besteht in der juristischen Literatur eine nahezu nicht mehr überschaubare Vielfalt an Begriffen bzw. Begriffserklärungsversuchen1. 32 Nichtsdestotrotz soll nachfolgend auf einige gebräuchliche Begrifflichkeiten näher eingegangen werden. 1. Softwarepflege 33 Der Begriff „Softwarepflege“ ist gesetzlich nicht definiert. Eine explizite DIN-/VDI- oder VDE-Normung2 hierzu ist nicht vorhanden3. Lediglich § 634a Abs. 1 Nr. 1 BGB enthält die ausdrückliche Nennung des Begriffs „Wartung“. Dann stellt sich die Frage, ob der Gesetzgeber mit Durchführung der Schuldrechtsmodernisierung die Softwarepflege als Wartung i.S.d. § 634a Abs. 1 Nr. 1 BGB verstanden wissen wollte, wonach die in § 634 Nr. 1, 2 und 4 bezeichneten Ansprüche in zwei Jahren verjähren. Andern1 Statt vieler: Zahrnt, Computervertragsrecht, Kap. 14.1, der insbesondere den Begriff „Vollpflege“ geprägt hat (s. hierzu Zahrnt, CR 2004, 408); Redeker, Handbuch der IT-Verträge, 1.12 A. Einleitung; Schneider, Handbuch des EDV-Rechts, K. Rz. 12 ff.; Redeker, IT-Recht, Rz. 635, Bischof/Witzel, ITRB 2003, 31; Müglich, CR 2003, 633. 2 DIN: Deutsches Institut für Normung e.V. VDI: Verein deutscher Ingenieure e.V. VDE: Verband der Elektrotechnik Elektronik Informationstechnik e.V. 3 S. hierzu der kurze Hinweis in Ziff. 4.5 (Änderbarkeit) der DIN 66272, Ausgabe Oktober 1994, identisch mit DIN/ISO 9126: 1991, auf die Bartsch, NJW 2002, 1526, 1527 in Fn. 26 verweist: Danach können Änderungen der Software Korrekturen, Verbesserungen oder Anpassungen der Software an Änderungen der Umgebung, der Anforderungen und der funktionalen Spezifikation einschließen. Für den anglo-amerikanischen Bereich liegen explizite Normierungen vor: IEEE 1219–1998 Standard for Software Maintenance Institute of Electrical and Electronics Engineers 01-May-1998 und BS ISO/IEC 14764:1999 Information technology. Software maintenance British Standard/ISO/IEC 15-Jan-2000. Im Ergebnis ebenso: Schneider, Handbuch des EDV-Rechts, K. Rz. 12a.

862

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 35 I

falls greift die Regelung des § 634a Abs. 1 Nr. 3 BGB, demzufolge die Ansprüche nach Ablauf der regelmäßigen Verjährungsfrist verjähren, also nach drei Jahren (§ 195 BGB). Bei näherer Betrachtung des Gesetzgebungsverfahrens zur Schuldrechts- 34 modernisierung lässt sich feststellen, dass in den Entwurf eines Gesetzes zur Modernisierung des Schuldrechts vom 14.5.20011 in § 634a Abs. 1 Nr. 2 BGB-E2 erst aufgrund der Einlassung des Bundesrats hinter dem Wort „Herstellung“ das Wort „Wartung“ eingefügt wurde3. Begründet wurde die gewünschte Einfügung mit der Gleichschaltung der Verjährungsfristen für die Herstellung einer Sache und dem Hinweis, dass Wartungsarbeiten außerordentlich häufig durchgeführt werden und es daher einer gesetzlichen Regelung bedarf4. Dass der Gesetzgeber hierbei und im folgenden Gesetzgebungsverfahren explizit an Softwarepflege gedacht hat, lässt sich nicht positiv feststellen. Da im August 20015 die Diskussionen zu der Frage, ob Software gewartet oder gepflegt wird6, bekannt waren, darf erwartet werden, dass die Softwarepflege eine explizite und klarstellende Erwähnung in den Erwägungsgründen erfahren hätte, wenn Softwarepflege gemeint gewesen wäre. Softwarepflege ist daher nicht von dem Begriff der Wartung i.S.v. § 634a Abs. 1 Nr. 1 BGB umfasst7. In diesem Zusammenhang ist zusätzlich darauf zu verweisen, dass die DIN 35 31051 (2003-06) mit dem Titel „Grundlagen der Instandhaltung“ den Begriff „Instandhaltung“ in Wartung und andere Grundmaßnahmen (Instandsetzung, Inspektion und Verbesserung) unterteilt. Danach besteht „Wartung“ aus Maßnahmen zur Verzögerung und zur Verhinderung des Abnutzungsvorrats. In dem vorgenannten Sinne nutzt sich Software jedoch nicht ab8. 1 2 3 4 5 6

BT-Drucks. 14/6040. § 634a Abs. 1 Nr. 2 BGB-E ist als Nr. 1 des Abs. 1 verabschiedet worden. BT-Drucks. 14/6857 S. 36 und S. 67. BT-Drucks. 14/6857 S. 36. BT-Drucks. 14/6857 v. 31.8.2001. Schneider, Handbuch des EDV-Rechts, K. Rz. 4 und Fn. 9; Marly, Praxishandbuch Softwarerecht, Rz. 1023; Zahrnt, Computervertragsrecht, Kapitel 14.1 (1). Intveen, ITRB, 2001, 163 der noch im Juli 2001 explizit zwischen Hardware-Wartung (dort unter II.) und Softwarepflege (dort unter IV.) differenziert. Habel, CR 1993, 55; Hentschel, CR 1989, 568. Selbst in der Rechtsprechung wird die Terminologie uneinheitlich verwendet: Vgl. z.B. OLG Köln v. 25.8.2000 – 19 U 80/99 – Softwarepflege, CR 2001, 224; OLG Celle, in: Zahrnt, Entscheidungen zum Computerrecht-ECR OLG 220 – Wartung für Telefonanlage mit Software; OLG Koblenz, MMR 2005, 472 – Wartungsvertrag; OLG Koblenz v. 27.5.1993 – 5 U 1938/92, Pflegevertrag, CR 1993, 626; OLG Köln v. 15.11.2002 – 19 U 115/02, Erfüllungsanspruch aus Softwarepflegevertrag, CR 2003, 329. 7 A.A. Schneider, Handbuch des EDV-Rechts, K. Rz. 12a. 8 Schneider, Handbuch des EDV-Rechts, K. Rz. 12a; Marly, Praxishandbuch Softwarerecht, Rz. 1022; Zahrnt, Computervertragsrecht, Kap. 14.3.1; Intveen, ITRB 2010, 90; Intveen, ITRB 2004, 138; Bartsch, NJW 2002, 1526; Moritz, CR 1999, 541; FG Niedersachsen, v. 16.1.2003 – 10 K 82/99: Keine Afa wegen technischer Abnutzung.

Peter

863

I Rz. 36

Sonderregelungen

36 Bei der Anwendung der Begriffe „Softwarewartung“ oder „Softwarepflege“1 ist im Übrigen zu berücksichtigen, dass sich die öffentlichen Auftraggeber mit Einführung der (älteren) BVB-Pflege (Besondere Vertragsbedingungen für die Pflege von DV-Programmen)2 und der (neuen) EVB-IT Pflege S (Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware)3 für die Terminologie „Softwarepflege“ entschieden haben4. 37 Softwarepflege wird im internationalen Handelsverkehr, insbesondere im anglo-amerikanischen Handelsraum, regelmäßig als „Maintenance“5 bezeichnet, wobei in diesem Zusammenhang für einzelne Unterstützungsleistungen (z.B. Hotline) die Bezeichnung „Support“ verwendet wird6. 2. Programmkorrekturen 38 Die EVB-IT Pflege S, die ausdrücklich nur für die Pflege von Standardsoftware Anwendung findet, verwendet den Begriff „Programmkorrektur“ als Oberbegriff für Umgehung, Patch, Update, Upgrade und Release/Version. Die vorstehenden Begriffe sind nicht gesetzlich definiert. Es ist dabei darauf hinzuweisen, dass Softwareanbieter diese Begriffe auf unterschiedlichste Art und Weise ausfüllen; teilweise verschwimmen die Bedeutungen. 39 Die BVB-Pflege enthält keinen dementsprechenden Definitionskatalog. § 4 BVB-Pflege behandelt lediglich die Begriffe „Mängelbeseitigung“, „Programmänderungen“, „Programmversionen“ und „Programmdokumentationen“, ohne sie näher zu bestimmen; vielmehr wird auf die Leistungsbeschreibung verwiesen, in der die Einzelheiten festzulegen sind. Auf die „Anpassung“ von Programmen geht § 4 BVB-Pflege etwas näher ein. a) Umgehung 40 Als „Umgehung“ bezeichnet die EVB-IT Pflege S die temporäre Überbrückung eines Mangels in der Standardsoftware ohne Eingriff in den Quelloder ausführbaren Code (ersterer auch „Source Code“, letzterer auch „Objekt-Code“ genannt)7. 1 Zur Frage der Falschbezeichnung s. Schneider, CR 2004, 241. 2 Die BVB-Pflege wird regelmäßig für die Pflege von Individualsoftware verwendet. 3 Die EVB-IT Pflege S ist nur für die Pflege von Standardsoftware anzuwenden. 4 Zur EVB-IT Pflege S: Müglich, CR 2003, 633; Intveen, ITRB 2003, 128; Karger, ITRB 2003, 107; Leitzen, ITRB 2003, 78; Feil/Leitzen, CR 2003, 161. 5 BS ISO/IEC 14764:1999 Information technology. Software maintenance British Standard/ISO/IEC 15-Jan-2000 – Ersatz durch ISO/IEC FDIS 14764 (2006) – Software Engineering – Software Life Cycle Processes – Maintenance. 6 v. Baum, CR 2002, 705; Bischof/Witzel, ITRB 2003, 31 (32): Teilweise soll der Begriff „Maintenance“ auch der Hardware-Wartung zugeordnet werden; teilweise würde darunter auch die Gesamtheit aus Wartungs- und Pflegeleistungen definiert; Schneider, Handbuch des EDV-Rechts, K Rz. 12. 7 Zur Abgrenzung Marly, Praxishandbuch Softwarerecht, Rz. 21.

864

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 44 I

b) Patch Ein „Patch“ (engl. Flicken) ist ein Programm, welches ein Bugfix1 zur Feh- 41 lerbehebung einer Software auf dem Rechner installiert2. Mit der EVB-IT Pflege S definiert der öffentliche Auftraggeber den Begriff3 erstmals. Danach ist ein Patch eine temporäre Behebung eines Mangels in der Standardsoftware ohne Eingriff in den Quellcode4. c) Update Die EVB-IT Pflege S definiert das Update als eine Bündelung mehrerer Män- 42 gelbehebungen in der Standardsoftware in einer einzigen Lieferung (z.B. 4.1.3 auf 4.1.4)5. Hierbei sei bemerkt, dass der Begriff Update (engl. aktualisieren, verbessern) selbstverständlich auch im Fall der Pflege von Individualsoftware in Betracht kommt6. d) Upgrade Das „Upgrade“ (engl. Aufrüstung, Steigung, Verbesserung) definiert die 43 EVB-IT Pflege S als die Bündelung mehrerer Mängelbehebungen und geringfügige funktionale Verbesserungen und/oder Anpassungen (z.B. an geänderte Einsatzbedingungen) der Standardsoftware (z.B. 4.1.3 auf 4.2.0)7. e) Release/Version Ein „Release“8 (engl. u.a. Veröffentlichung, Freigabe) umfasst nach EVB-IT Pflege S zusätzliche und/oder geänderte Funktionen und sonstige Anpassungen/Korrekturen (z.B. 4.5.7 auf 5.0.0)9.

1 Mit Bugfix bezeichnet man die erfolgreiche Behebung eines Programmierfehlers. 2 http://www.galileocomputing.de/glossar/gp/anzeige-9540/FirstLetter-P. 3 Dies gilt ebenso für die Begriffe Update, Upgrade und Release. 4 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware EVB-IT Pflege S, Fassung v. 27.3.2003, S. 7 unter Begriffsbestimmungen. 5 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware EVB-IT Pflege S, Fassung v. 27.3.2003, S. 7 unter Begriffsbestimmungen. 6 Entsprechendes gilt für die Begriffe Patch, Upgrade und Release. 7 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware EVB-IT Pflege S, Fassung v. 27.3.2003, S. 7 unter Begriffsbestimmungen. 8 Die EVB-IT Pflege S hält dabei die Begriffe Release/Version gleichbedeutend. 9 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware EVB-IT Pflege S, Fassung v. 27.3.2003, S. 7 unter Begriffsbestimmungen.

Peter

865

44

I Rz. 45

Sonderregelungen

III. Verpflichtung zum Abschluss eines Softwarepflegevertrags 45 Das bürgerliche Recht setzt den Grundsatz der Privatautonomie voraus, welche es dem Einzelnen überlässt, seine Lebensverhältnisse mit dem Mittel des Rechtsgeschäfts zu gestalten, insbesondere zu entscheiden, ob und mit wem bzw. mit welchem Inhalt Verträge geschlossen werden sollen (Vertragsfreiheit)1. 46 In der juristischen Literatur wird diskutiert, ob der Softwareanbieter im Gegensatz zu dem vorstehenden Grundsatz verpflichtet ist, mit dem Softwareanwender einen Softwarepflegevertrag abzuschließen2, damit dieser sein Interesse auf Investitionssicherung und -erhaltung durchsetzen kann. 47 Gerichtliche Entscheidungen explizit zu diesem Aspekt sind nicht vorhanden. Vielmehr wird von der Rechtsprechung die Gefährdung des Investitionsschutzes wegen fehlender Softwarepflegeleistungen im Zusammenhang mit der Kündigung eines Softwarepflegevertrags durch den Softwareanbieter (s. hierzu nachfolgend Rz. 53 ff.) und im Zusammenhang mit der Quellcodeherausgabe (s. hierzu Kap. L Rz. 112 ff.) behandelt. 1. Praktische Relevanz 48 Wenn Softwareanbieter keine Softwarepflegeverträge offerieren, liefern sie in der Regel niedrigpreisige Produkte für Personal Computer (PCs)3. Hier gibt es typischerweise Patches zum Download über das Internet, ohne dass ein gesonderter Pflegevertrag geschlossen wurde, oder – nach einer gewissen Zeit – ein neues Softwareprodukt4. 49 Wenn Softwareanbieter hochpreisige Softwareprodukte (sei es Standardoder Individualsoftware) anbieten, haben sie regelmäßig ein eigenes hohes wirtschaftliches Interesse daran, auf Grund des Abschlusses von Softwarepflegeverträgen zusätzliche Einnahmenquellen zu generieren5. 50 Aus alledem ergibt sich, dass die eingangs gestellte Frage nach der Verpflichtung zum Abschluss eines Softwarepflegevertrags wohl nur in dem Fall zum Tragen kommen wird, dass der Softwareanwender es im Zusammenhang mit der Überlassung einer hochpreisigen Software versäumt hat, die Softwarepflege zu vereinbaren, und der Softwareanbieter versucht, diese Situation für sich auszunutzen und sich weigert, Softwarepflegeleistungen zu einem angemessenen Entgelt zu erbringen. 1 Palandt/Ellenberger, Überbl. vor § 104 Rz. 1, und: Die Privatautonomie ist Teil des allgemeinen Prinzips der Selbstbestimmung des Menschen und wird zumindest in ihrem Kern durch Art. 1 und 2 GG geschützt. 2 Zuletzt hierzu Fritzemeyer/Splittgerber, CR 2007, 209. 3 Zahrnt, CR 2004, 205. 4 Zahrnt, CR 2004, 205. Im Übrigen denke man nur an die Office-Produkte der Firma Microsoft. 5 v. Baum, CR 2002, 705; Jaeger, CR 1999, 209; Hartmann/Thier, CR 1998, 581.

866

Peter

Rz. 53 I

Softwarepflege inklusive Service-Level-Agreement

Nach der überwiegenden Meinung in der Literatur1 lässt sich ein Anspruch 51 auf Abschluss eines Softwarepflegevertrages in der Regel nicht begründen. Die wesentlichen Elemente des Streitstandes werden anhand der nachfolgend aufgeführten Anspruchsgrundlagen dargestellt. 2. Anspruchsgrundlagen a) Vertragliche Ansprüche aa) Besondere Vertragsbedingungen der öffentlichen Auftraggeber Soweit die Besonderen Vertragsbedingungen für die Überlassung von DV- 52 Programmen (BVB-Überlassung) der öffentlichen Auftraggeber Gegenstand eines Vertrags sind, kann sich aus dessen § 21 die Verpflichtung zur Pflege der überlassenen Software ergeben (s. hierzu auch Rz. 59)2. Andernfalls sind konkrete vertragliche Abreden notwendig, die auch in Form einer Option vereinbart werden können. Die neuen Ergänzenden Vertragsbedingungen für die Überlassung von Standardsoftware der öffentlichen Auftraggeber (EVB-IT Überlassung Typ A oder Typ B) enthalten keine Vereinbarungen mehr, die die Verpflichtung zur Pflege der überlassenen Software begründen können3. bb) Nebenpflicht aus § 242 BGB Rechtsprechung, die einen unmittelbaren Abschlusszwang aus § 242 BGB 53 herleitet, besteht nicht4. In der Literatur wird die These aufgestellt, dass derjenige, der ein teures Investitionsgut verkauft, dafür sorgen muss, dass dieses auch genutzt werden kann5. In diesem Zusammenhang werden im Wesentlichen zwei Urteile (LG Köln und OLG Koblenz)6 zur Begründung der Pflegeverpflichtung während des sog. Lebenszyklus’ einer verkauften Software herangezogen, die sich beide mit der Frage der Wirksamkeit einer ordentlichen Kündigung eines Softwarepflegevertrags befassen7, jedoch kön-

1 Bischof/Witzel, ITRB 2003, 31; Welker/Schmidt, CR 2002, 873; v. Baum, CR 2002, 705; Bartsch, NJW 2002, 1526; Moritz, CR 1999, 541; Marly, Praxishandbuch Softwarerecht, Rz. 1031 ff.; Schneider, Handbuch des EDV-Rechts, K Rz. 96 ff. A.A. Zahrnt, CR 2000, 205 ff. und in Computervertragsrecht 14.2 (1) mit Verweis auf 13.2 (1); Jaeger, CR 1999, 209. 2 Im Einzelnen hierzu Marly, Praxishandbuch Softwarerecht, Rz. 1032. 3 Marly, Praxishandbuch Softwarerecht, Rz. 1032. 4 Grapentin/Ströbl, CR 2009, 137. 5 Zahrnt, CR 2000, 205, 206. 6 LG Köln v. 16.10.1997 – 83 O 26/97, CR 1999, 218; OLG Koblenz v. 27.5.1993 – 5 U 1938/92, CR 1993, 626. Zahrnt verweist zwar nur auf das Urteil des LG Köln – dieses wiederum begründet seine Auffassung wiederum teilweise mit Verweis auf das Urteil des OLG Koblenz. 7 Jaeger, CR 1999, 209; Zahrnt, CR 2000, 205, 206 mit Verweis auf das Urteil des AG München, NJW 1970, 1852.

Peter

867

I Rz. 54

Sonderregelungen

nen beide Urteile nicht zur Begründung der vorangestellten These herangezogen werden1. (1) LG Köln: Unwirksamkeit einer ordentlichen Kündigung vor Beendigung des Software-Lebenszyklus’ 54 Das LG Köln2 zieht zur Begründung der Unwirksamkeit einer ordentlichen Kündigung durch den Softwareanbieter die (von Grüneberg vertretene) Ansicht heran, dass der Verkäufer von technischen Industrieprodukten oder Wartungsleistungen verpflichtet sein kann, Ersatzteile für die durchschnittliche Nutzungsdauer des Produkts bereit zu halten3. 55 Dem ist die juristische Literatur bereits mit dem richtigen Argument entgegengetreten, dass eine etwaige Pflicht zur Hardwarewartung nicht auf Softwarepflege übertragen werden kann, da Software – technisch gesehen – nicht verschleißt4. Die Software bzw. deren Funktionalitäten, die fehlerfrei arbeiten, werden auf Grund ordnungsgemäßer Benutzung (mangels Verschleiß) nicht fehlerhaft, so dass keine Rechtfertigung für die Nachlieferung von „Ersatzteilen“ besteht. 56 Soweit ein (nicht verschleißendes) Produkt fehlerhaft ist, ist die Geltendmachung von etwaigen Ansprüchen (allein) hieraus mit Ablauf der Frist zur Verjährung von Ansprüchen wegen Mängeln nicht mehr durchsetzbar, selbst wenn sich ein von Anfang an angelegter Mangel5 erst nach Ablauf der Mängelhaftungsfrist zeigt. Nach Ablauf der Mängelhaftungsfrist muss grundsätzlich kein Vertragspartner mehr dafür Sorge tragen, dass der andere Vertragspartner das ihm überlassene Produkt nutzen kann. 57 Selbst wenn sich die für die Nutzung des Produkts maßgeblichen und außerhalb des Produkts angelegten Rahmenbedingungen ändern, welche der die Software überlassende Vertragspartner nicht beeinflusst oder beeinflussen kann, wie z.B. in den Fällen, bei denen Software inhaltlich-funktionell weiter zu entwickeln ist (s. hierzu Rz. 15 ff.), lässt sich im Zusammenhang mit Softwarepflege nicht rechtfertigen, zu Lasten des Softwareanbieters die Vertragsfreiheit einzuschränken und ihn mithilfe von § 242 BGB zu verpflichten, Softwarepflegeleistungen über den vertraglich vereinbarten Umfang hinaus zu erbringen6.

1 Grapentin/Ströbl, CR 2009, 137; Fritzemeyer/Splittgerber, CR 2007, 209. 2 LG Köln v. 16.10.1997 – 83 O 26/97, CR 1999, 218. 3 Palandt/Heinrichs, § 242 BGB Rz. 29 mit Verweis auf AG München NJW 1970, 1852. 4 Moritz, CR 1999, 541. 5 Im entschiedenen Fall des LG Köln die fehlende Jahr-2000-Fähigkeit, dessen sich der Softwareanbieter durch vorherige Ausübung einer ordentlichen Kündigung des Pflegevertrages entledigen wollte, vgl. Jaeger, CR 1999, 209. 6 Zur mittelbaren Drittwirkung der Grundrechte s. BVerfGE 7, 198, 205.

868

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 60 I

(2) OLG Koblenz: Softwarepflege aufgrund ergänzender Vertragsauslegung Das OLG Koblenz1 hat in einer Entscheidung aus dem Jahr 1993 im Rah- 58 men der Auslegung (§§ 133, 157 BGB) des Softwareüberlassungsvertrags (Suche nach dem hypothetischen Parteiwillen) den Vortrag der Klägerin übernommen, dass bei der Beschaffung von Fremdsoftware die Fähigkeit und Bereitschaft des Softwarehändlers, sein Produkt auch langfristig ordnungsgemäß zu warten und weiterzuentwickeln, ein wichtiges Kriterium bei der Auswahl des Produkts ist2. Hierauf beruft sich wiederum das LG Köln in seiner vorgenannten Entscheidung3. In diesem Zusammenhang untersucht das OLG Koblenz aber nicht die oben 59 aufgeworfene Aussage4 anhand von § 242 BGB. Vielmehr setzte sich das Gericht mit dem Konflikt des § 3 Ziff. 2 BVB-Pflege (Möglichkeit der ordentlichen Kündigung) und § 21 BVB-Überlassung (Recht auf Programmpflege nach Ablauf der Gewährleistungsfrist) auseinander (es wurden BVB-Überlassung und BVB-Pflege vereinbart) und stellt zwischen beiden Vertragsbestimmungen eine Lücke fest, die – auf der Grundlage der vorstehenden Erwägungen der Klägerin – nur sach- und interessengerecht dahin ergänzt werden kann, dass, wenn eine Software gegen Zahlung eines Einmalentgeltes erworben wird, eine ordentliche Kündigung der Pflegevereinbarung durch den Auftragnehmer so lange nicht möglich ist, wie das Programm von diesem allgemein angeboten wird5. In diesem Sinne hätten vernünftige Parteien § 3 BVB-Pflege unter Berücksichtigung der Regelung in § 21 BVBÜberlassung eingeschränkt, wenn sie die vorliegende Fallgestaltung bedacht hätten6. (3) Keine dauerhafte Pflicht zu Pflegeleistungen Weder aus der Begründung des LG Köln noch aus der Begründung des OLG 60 Koblenz für den Sonderfall der BVB der öffentlichen Auftraggeber lässt sich daher ein allgemeiner Grundsatz für ein Verbot der Vertragskündigung bzw. für einen Abschlusszwang – und sei es nur für hochpreisige Softwareprodukte – herleiten7. 1 OLG Koblenz v. 27.5.1993 – 5 U 1938/92, CR 1993, 626. 2 OLG Koblenz v. 27.5.1993 – 5 U 1938/92, CR 1993, 626, 628. Darauf stellt auch Jaeger, CR 1999, 209 ab. 3 LG Köln v. 16.10.1997 – 83 O 26/97, CR 1999, 218. 4 Derjenige, der ein teures Investitionsgut verkauft, müsse dafür sorgen, dass dieses auch genutzt werden kann. 5 Vgl. hierzu den Wortlaut in § 21 BVB-Überlassung letzter Satz: Dies gilt nur für solche Programme, die vom Auftragnehmer allgemein auf dem Markt mit der Verpflichtung zur Mängelbeseitigung angeboten werden. 6 OLG Koblenz v. 27.5.1993 – 5 U 1938/92, CR 1993, 626. 7 Grapentin/Ströbl, CR 2009, 137 bezüglich eines etwaigen Kontrahierungszwanges aus § 242 BGB, wenn der Hersteller seinen Kunden grundsätzlich standardisierte Patches anbietet, deren Lieferung aber nachweisbar stets bzw. überwiegend

Peter

869

I Rz. 61

Sonderregelungen

61 Vor dem Hintergrund des Vorgesagten ist die vom LG Köln1 – wiederum unter Rückgriff auf § 242 BGB – beantwortete, sich anschließende Frage, wie lange die Pflicht zur Pflege der Software andauert (Lebenszyklus), hinfällig. 62 Entsprechend der hier vertretenen Auffassung hat das OLG Koblenz in einer Entscheidung aus dem Jahr 2005 festgestellt: Ohne individuell getroffene vertragliche Absprachen besteht keine generelle Pflicht über Treu und Glauben, Pflegeleistungen für den gesamten Lebenszyklus einer verkauften Software sicherzustellen2. b) Gesetzliche Ansprüche 63 Es wird im Zusammenhang mit den Tatbestandsvoraussetzungen des § 20 Abs. 1 GWB3 die Auffassung vertreten, dass jeder Softwarehersteller ein Monopol am Quellcode hat, solange er ihn nicht ausliefert, woraus sich grundsätzlich ein Abschlusszwang ergibt4. Dieser gelange nur dann nicht zur Entstehung, wenn der Softwareanbieter – seiner Aufklärungspflicht entsprechend – die Fehlerbeseitigung im Überlassungsvertrag ausgeschlossen habe5. 64 Dem ist entgegengesetzt worden, dass die Rechtsprechung bei Anwendung des § 20 Abs. 1 GWB bislang allenfalls zwei Rechtsfolgen angewandt bzw. erwogen hat: Die Lieferung von Ersatzteilen aufgrund eines ganz konkreten Bedarfs oder die Pflicht zur Herausgabe des Quellcodes6, jedoch bisher in keinem Falle die Pflicht zum Abschluss eines Softwarepflegevertrags7. 65 Unabhängig von der Beantwortung der Frage, welche zivilrechtliche Rechtsfolge bzw. welcher zivilrechtliche Anspruch einem Softwareanwender bei einem Verstoß gegen §§ 19, 20 GWB zusteht8, ist eines völlig klar: Allein

1 2

3

4 5 6 7 8

dann verweigert, wenn der Kunde ein drittes Unternehmen für im Zusammenhang mit der Hardwarewartung stehende Leistungen beauftragt hat bzw. beauftragen möchte. LG Köln v. 16.10.1997 – 83 O 26/97, CR 1999, 218; Jaeger, CR 1999, 209. OLG Koblenz v. 12.1.2005 – 1 U 1009/04, CR 2005, 482; Schneider, Handbuch des EDV-Rechts, K. Rz. 98; Marly, Praxishandbuch Softwarerecht, Rz. 1033; Kaufmann, CR 2005, 841. Auf eine Interessenabwägung stellen ab: Grapentin/ Ströbl, CR 2009, 137; Fritzemeyer/Splittgerber, CR 2007, 209. § 20 GWB ist auf Grund des 7. Gesetzes zur Änderung des Gesetzes über Wettbewerbsbeschränkungen v. 7.7.2005 teilweise und redaktionell, jedoch nicht grundlegend geändert worden. Zahrnt, CR 2000, 205; Jaeger, CR 1999, 209. Jaeger, CR 1999, 209 mit Verweis auf Zahrnt. Z.B. Marly, Praxishandbuch Softwarerecht, Rz. 1033 mit Verweis auf Entscheidungen des LG München I (Fn. 930) und OLG Saarbrücken (Fn. 931). Marly, Praxishandbuch Softwarerecht, Rz. 1034; Grapentin/Ströbl, CR 2009, 137; Moritz, CR 1999, 541. Fritzemeyer/Splittgerber, CR 2007, 209 mit Verweis auf BGH v. 19.9.1974 – KZR 14/73, Schreibautomat, GRUR 1975, 326: Ein Anspruch auf Abschluss eines Softwarepflegevertrages ist grundsätzlich möglich. Ulmer, ITRB 2006, 210:

870

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 67 I

die Inhaberschaft am Quellcode führt nicht zur Marktbeherrschung i.S.v. §§ 19, 20 GWB1. Das Tatbestandsmerkmal „marktbeherrschend“ wird nicht auf der Basis eines zumindest urheberrechtlich geschützten Rechts am Quellcode beurteilt, sondern richtet sich allein nach der Größe des konkret zu bemessenden Marktanteils2. Dabei kommt der sog. Marktdefinition (sachlicher und räumlicher Markt) entscheidende Bedeutung zu3. Es ist vorauszuschicken, dass die §§ 19, 20 GWB nur den unternehmeri- 66 schen Verkehr betreffen4, Verbraucher können sich hierauf nicht berufen5. Außerdem muss ein besonderer Interessenkonflikt zwischen den Marktbeteiligten bestehen, wenn ein Softwareanbieter den Abschluss eines Softwarepflegevertrags ablehnt, soll dies zu einem Missbrauch (§ 19 GWB) bzw. zu einer Diskriminierung oder zu einer unbilligen Behinderung (§ 20 GWB) führen. Ein solcher Interessenkonflikt müsste von großer, gesamtwirtschaftlicher Bedeutung sein6, mithin eine Erheblichkeit erreichen, die mit einem Verstoß gegen die guten Sitten i.S.v. § 138 BGB vergleichbar sein dürfte. Denn erst das Erreichen dieser Schwelle lässt es zivilrechtlich zu, das dem Softwareanbieter verfassungsrechtlich zugewiesene Recht auf Privatautonomie zu beschränken7. Selbst wenn im Einzelfall ein Wettbewerbsverstoß darstellbar sein sollte, ist unter Anwendung des Verhältnismäßigkeitsgrundsatzes immer der mildeste Eingriff in das Recht auf Privatautonomie zu wählen8. Vor diesem Hintergrund bedarf es gewichtiger Argumente, um einen Verstoß gegen §§ 19, 20 GWB anzunehmen, selbst wenn keine Ausweichmöglichkeit durch den Erwerb eines Konkurrenzprodukts der zu pflegenden

1

2 3 4 5

6 7 8

Bei einem Kartellrechtsverstoß im Zusammenhang mit 82 EG/§ 19 GWB sind gemäß §§ 33 ff. GWB die Rechtsfolgen: Schadensersatz, Unterlassungsansprüche und Vorteilsabschöpfung. Fritzemeyer/Splittgerber, CR 2007, 209; Schneider, Handbuch des EDV-Rechts, K. Rz. 99; Marly, Praxishandbuch Softwarerecht, Rz. 1034, der – außerhalb des Anwendungsbereiches von § 20 Abs. 1 GWB – den Regelungsbereich des § 826 BGB auf solche Unternehmen erweitern möchte, die lebenswichtige Güter öffentlich anbieten und die einen Vertragsschluss nur aus sachlichen Gründen ablehnen dürfen, sofern der Kunde keine Ausweichmöglichkeiten habe; a.A. wohl Grapentin/Ströbl, CR 2009, 137. Vgl. z.B. § 19 Abs. 3 GWB; Bechtold, GWB Kommentar (4. Aufl.), § 20 Rz. 9 und 10 mit Verweis auf § 19 Abs. 3 GWB; Ulmer, ITRB 2006, 210. Ulmer, ITRB 2006, 210; Ebel, CR 1987, 273; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, 1.12 Rz. 173. Fritzemeyer/Splittgerber, CR 2007, 209. Palandt/Ellenberger, Einf. vor § 145 BGB Rz. 8f und Rz. 10 zur Frage einer Abschlusspflicht bei Rechtsgeschäften mit Verbrauchern im Falle des Bezugs sog. lebenswichtiger Güter. Immenga/Mestmäcker, Wettbewerbsrecht: GWB, Vorwort zur 1. Aufl. Palandt/Ellenberger, § 138 BGB Rz. 1. Palandt/Grüneberg, § 242 BGB Rz. 53 zur Unverhältnismäßigkeit.

Peter

871

67

I Rz. 68

Sonderregelungen

Software besteht1. Ein Verstoß gegen die einschlägigen kartellrechtlichen Vorschriften dürfte noch schwieriger darzustellen sein, sollten entsprechende Ausweichmöglichkeiten für den Softwareanwender bestehen. Im Übrigen darf das Kartellrecht nur bei Vorliegen besonderer Umstände die dem Softwareanbieter zustehenden Rechte des Urheberrechts aushebeln2. Letztlich dürfte es einem Softwareanwender rein tatsächlich kaum möglich sein, einen Kartellrechtsverstoß darzulegen, wenn der Softwareanbieter zu hohe Entgelte für die Softwarepflege verlangt3. c) Tatsächliche Zwänge zum Abschluss eines Softwarepflegevertrages 68 Falls zwischen Softwareanbieter und -anwender noch kein Softwarepflegevertrag zustande gekommen ist, weil der Softwareanbieter den Abschluss verweigert, kommen – soweit kein Anspruch auf Abschluss eines Softwarepflegevertrags auf Grund der §§ 19, 20 GWB besteht – möglicherweise tatsächliche Zwänge in Betracht, die den Softwareanbieter zum Abschluss eines Softwarepflegevertrages bewegen. aa) Quellcodeherausgabe 69 Soweit eine Pflicht zur Quellcodeherausgabe besteht (s. hierzu Kap. L Rz. 112 ff.), ist vom Softwareanbieter zu prüfen, ob es aus Gründen der Kosten-Nutzen-Relation vernünftiger ist, stattdessen einen Softwarepflegevertrag abzuschließen. bb) Schadensersatz wegen Vertragsverweigerung 70 Eine entsprechende Prüfung der Kosten-Nutzen-Relation ist ebenso vorzunehmen, falls dem Softwareanwender ein Anspruch auf Schadensersatz aus §§ 280 Abs. 1, 311 Abs. 2 Nr. 1, 241 Abs. 2 BGB (Verschulden bei Vertragsverhandlungen) zusteht. Ein Schadensersatzanspruch könnte allein schon dadurch gerechtfertigt sein, dass sich der Softwareanbieter ohne triftigen Grund4 weigert, einen Softwarepflegevertrag abzuschließen. 71 Nach § 311 Abs. 2 Nr. 1 BGB entsteht ein Schuldverhältnis mit den (Verhaltens-)Pflichten nach § 241 Abs. 2 BGB schon durch die Aufnahme von Vertragsverhandlungen. Vertragsverhandlungen sind aufgenommen mit dem

1 Grapentin/Ströbl, CR 2009, 137, die einen Abschlusszwang allein mit dem Argument bejahen, dass regelmäßig der Hersteller über die Programmquellen, die Dokumentation und das Fachwissen verfüge. Das Ergebnis offen lassend, jedoch für besondere Einzelfälle eine Abschlusspflicht grundsätzlich bejahend: Fritzemeyer/Splittgerber, CR 2007, 209. 2 Fritzemeyer/Splittgerber, CR 2007, 209 mit Verweis auf BGH v. 13.7.2004 – KZR 40/02, GRUR 2004, 966. 3 Ulmer, ITRB 2006, 210. 4 Palandt/Grüneberg, § 311 BGB Rz. 32 mit Verweis auf mehrere BGH-Entscheidungen zur Ersatzpflicht.

872

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 73 I

Beginn der Verhandlungen1. Hierzu genügen einseitige Maßnahmen eines Vertragsteils, die den anderen zum Vertragsschluss veranlassen sollen2, wie z.B. das Angebot oder die AGB des Softwareanbieters zum Softwareüberlassungsvertrag, falls diese darauf hindeuten, dass der Softwareanbieter auch einen Softwarepflegevertrag andienen möchte3. Ebenfalls kann bereits die sonstige vorvertragliche Korrespondenz ausreichend sein, um ein Schuldverhältnis nach § 241 Abs. 2 BGB entstehen zu lassen4. cc) Schadensersatz wegen Verletzung der Aufklärungspflicht Letztlich kann ein Schadensersatzanspruch des Softwareanwenders gegen 72 den Softwareanbieter nach §§ 280 Abs. 1, 241 Abs. 2 BGB aus dem Softwareüberlassungsvertrag in Betracht kommen, obwohl nicht einmal Vertragsverhandlungen über den Abschluss eines Softwarepflegevertrages aufgenommen wurden5. Nach § 241 Abs. 2 BGB kann das Schuldverhältnis – hier der Softwareüberlassungsvertrag – nach seinem Inhalt jeden Teil zur Rücksicht auf die Rechte, Rechtsgüter und Interessen des anderen Teils verpflichten. Wie unter Rz. 10 ff. im Einzelnen dargestellt, hat der Softwareanwender ein verständliches und nachvollziehbares Investitionserhaltungs- und -sicherungsinteresse, das umso größer ist, je wichtiger dem Softwareanwender das Softwareprodukt ist. Kommen weitere, für den Softwareanbieter erkennbare Umstände hinzu, wie z.B. das Überschreiten einer gewissen Preisschwelle für die Überlassung des Softwareprodukts, der zeit- und kostspielige Aufbau einer Hard- und Betriebssoftwareumgebung durch den Softwareanwender, auf die das überlassene Softwareprodukt installiert werden soll, oder eine aufwändige Einführungsphase über einen längeren Zeitraum, liegt es auf der Hand, dass der Softwareanbieter Rücksicht auf die zuvor genannten Interessen des Softwareanwenders zu nehmen hat, § 241 Abs. 2 BGB. § 241 Abs. 2 BGB proklamiert gewisse Verhaltenspflichten, worunter vor al- 73 lem Aufklärungspflichten fallen6. Soweit die äußeren Umstände zu einer für den Softwareanbieter erkennbaren Evidenz führen, dass der Softwareanwender ohne zusätzliche Pflegeleistungen seinem Investitionserhaltungsund -sicherungsinteresse nicht in einem angemessenen Maße nachkommen kann, muss der Softwareanbieter vor Abschluss des Softwareüberlassungsvertrags den Softwareanwender darauf hinweisen, dass er keinen Softwarepflegevertrag abschließen will.

1 2 3 4

Palandt/Grüneberg, § 311 BGB Rz. 22. Palandt/Grüneberg, § 311 BGB Rz. 22 mit Verweis auf BGH LM § 276 (Fa) Nr. 3. Bischof/Witzel, ITRB 2003, 31. Zum vorvertraglichen Stadium vgl. Schneider, Handbuch des EDV-Rechts, K. Rz. 131 ff. 5 Schneider, Handbuch des EDV-Rechts, K. Rz. 92 Fn. 1. 6 Palandt/Grüneberg, § 241 BGB Rz. 7.

Peter

873

I Rz. 74

Sonderregelungen

74 Das Vorstehende dürfte entsprechend für den Fall gelten, dass der Softwareanbieter dem Softwareanwender zwar einen Softwarepflegevertrag andient, er jedoch ein unangemessen hohes Entgelt für seine Leistungen aus dem Softwarepflegevertrag verlangt. Unter Heranziehung des Rechtsgedankens von § 308 Nr. 7a) BGB muss der Softwareanbieter vor Abschluss des Softwareüberlassungsvertrags den Softwareanwender über seine Entgeltvorstellungen für die Pflegeleistungen aufklären, selbst wenn er damit – sehenden Auges – den Abschluss des Softwareüberlassungsvertrages riskiert.

IV. Rechtliche Einheit mit dem Softwareüberlassungsvertrag 75 Fraglich ist, welche rechtlichen Auswirkungen in Bezug auf den Softwarepflegevertrag bestehen bzw. welche Rechte den Vertragsparteien des Softwarepflegevertrags zustehen, wenn der Softwareüberlassungsvertrag oder der Softwarepflegevertrag nicht zur Entstehung gelangt oder nachträglich fortfällt: Ist ein Teil eines (einheitlichen) Rechtsgeschäfts nichtig, also von Anfang an unwirksam1, ordnet § 139 BGB an, dass das ganze Rechtsgeschäft nichtig ist, wenn nicht anzunehmen ist, dass es auch ohne den nichtigen Teil vorgenommen sein würde. In den Rz. 76 ff. dieses Kapitels wird gezeigt, unter welchen Voraussetzungen es im Verhältnis zwischen einem Softwareüberlassungsvertrag und einem Softwarepflegevertrag zur rechtlichen Einheit kommen kann. Besteht eine rechtliche Einheit, ist jedoch ein Teil eines (einheitlichen) Rechtsgeschäfts nicht nichtig, sondern wird dieser Teil auf Grund eines Rücktritts oder einer Kündigung rückabgewickelt bzw. beendet, fragt sich, welche Konsequenzen dies für den anderen Teil des (einheitlichen) Rechtsgeschäfts mit sich bringt (s. hierzu Rz. 106 ff. und Rz. 124 ff.). Letztlich ist zu klären, welche rechtlichen Möglichkeiten bestehen, wenn ohne Vorliegen einer rechtlichen Einheit entweder der Softwareüberlassungsvertrag oder der Softwarepflegevertrag nicht wirksam wird bzw. wegfällt (hierzu Rz. 134 ff. und Rz. 138). 1. Einheitliches Rechtsgeschäft 76 Soweit der Softwareanwender das Interesse hat, zum Softwareüberlassungsvertrag einen Softwarepflegevertrag abzuschließen, lässt sich dieser Wunsch vertragsrechtlich wie folgt dokumentieren: Entweder werden beide Verträge in einer Urkunde niedergelegt oder die Verträge werden in unterschiedlichen Urkunden vereinbart.

1 Palandt/Ellenberger, Überbl. vor § 104 Rz. 27.

874

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 83 I

a) Rechtliche Einheit im Zwei-Personen-Verhältnis Soweit in den beiden oben genannten Fällen die rechtliche Einheit beider Rechtsgeschäfte nicht explizit festgeschrieben wird, ist der Einheitlichkeitswille im Weg der Auslegung (§§ 133, 157 BGB) festzustellen1.

77

Werden beide Verträge in einer Urkunde niedergelegt, besteht damit bereits eine widerlegliche Vermutung für ein einheitliches Rechtsgeschäft i.S.d. § 139 BGB2.

78

Die getrennte Beurkundung von Softwareüberlassungs- und -pflegevertrag 79 spricht dagegen – ebenfalls widerleglich – für die Selbständigkeit beider Geschäfte3. Unabhängig davon, ob eine Niederlegung der Vereinbarungen in einer oder mehreren Urkunden erfolgt, müssen die nachfolgenden Voraussetzungen bestehen, um von rechtlicher Einheit ausgehen zu können:

80

aa) BGH-Rechtsprechung Zwei an sich selbständige Vereinbarungen stellen dann ein einheitliches Rechtsgeschäft dar, wenn nach den Vorstellungen der Vertragsschließenden die Vereinbarungen nicht für sich alleine gelten, sondern miteinander stehen und fallen sollen4.

81

Es genügt der Einheitlichkeitswille einer Vertragspartei, wenn er für die andere Vertragspartei erkennbar war und von ihr gebilligt oder hingenommen wurde5.

82

Dabei ist der Wille zur rechtlichen Einheit maßgeblich; die Absprachen dür- 83 fen nicht in erster Linie auf wirtschaftlichen Erwägungen, wie der Erwartung eines günstigeren Preises beruhen6. Der Wille zur rechtlichen Einheit kann insbesondere dadurch zum Ausdruck kommen, dass das gesamte Rechtsgeschäft (Softwareüberlassung und -pflege) in eine Hand gelegt werden soll: Das ist insbesondere der Fall, wenn der Wille, alle Leistungen aus

1 Palandt/Ellenberger, § 139 BGB Rz. 5 mit Verweis auf u.a. BGH v. 24.10.2006 – XI ZR 216/05, NJW-RR 2007, 395, Tz. 17; BGH v. 30.4.1976 – V ZR 143/7, NJW 1976, 1931. 2 BGH v. 25.3.1987 – VIII ZR 43/86, CR 1987, 358. 3 Palandt/Ellenberger, § 139 BGB Rz. 5 mit Verweis auf BGH v. 24.10.2006 – XI ZR 216/05, NJW-RR 2007, 395, Tz. 19. 4 BGH v. 24.10.2006 – XI ZR 216/05, NJW-RR 2007, 395, Tz. 17; BGH v. 25.3.1987 – VIII ZR 43/86, CR 1987, 358; grundlegend: BGH v. 30.4.1976 – V ZR 143/7, NJW 1976, 1931; Palandt/Ellenberger, § 139 BGB Rz. 5. 5 Palandt/Ellenberger, § 139 BGB Rz. 5 mit Verweis auf BGH v. 9.7.1992 – IX ZR 209/91, NJW 1992, 3237. 6 BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467; BGH v. 25.3.1987 – VIII ZR 43/86, CR 1987, 358.

Peter

875

I Rz. 84

Sonderregelungen

einer Hand und damit aus einem Guss zu erhalten, der entscheidende Grund für die Zusammenfassung in einem Rechtsgeschäft ist1. bb) Übertragung auf Softwareüberlassung und -pflege 84 Die unter Rz. 10 ff. beschriebene tatsächliche und wirtschaftliche Verknüpfung von Softwareüberlassung und -pflege2 stellen – je nach Ausprägung im Einzelfall – ein starkes Indiz für die Annahme einer rechtlichen Einheit der Vereinbarungen dar. 85 Diese kommt dann klar zum Ausdruck, wenn für den Softwareanbieter erkennbar ist, dass der Softwareanwender sein Investitionssicherungs- und -erhaltungsinteresse mit beiden Vereinbarungen unbedingt verknüpft: Falls der Softwareanwender das Softwareprodukt vor dem Hintergrund des von ihm beabsichtigten Einsatzes nur dann vernünftigerweise nutzen kann und will, wenn er zusätzlich die Pflegeleistungen erhält, ist evident, dass beide Vereinbarungen – Softwareüberlassung und Softwarepflege – miteinander stehen und fallen sollen. 86 Dass ein Softwarepflegevertrag ohne Softwareüberlassung keinen Sinn hat, liegt auf der Hand3: Es liegt kein Softwareprodukt vor, welches der Softwareanwender (erlaubterweise) nutzen kann, und für welches Pflegeleistungen erbracht werden können. Es existiert aus der Sicht des Softwareanwenders keine Software, an der Fehler oder Störungen beseitigt, die angepasst oder weiterentwickelt, Updates oder Upgrades etc. installiert, geschweige denn für die Hotline-Leistungen erbracht werden können. Für das LG Bonn soll der Softwareüberlassungsvertrag vom Bestand des Softwarepflegevertrags schon dann abhängen, wenn beide – formal in zwei Urkunden abgeschlossen – als Gesamtpaket angeboten sind und im Softwareüberlassungsvertrag angekreuzt ist, dass die Softwarepflegevereinbarung abgeschlossen wird bzw. abgeschlossen ist4. 87 Soweit der Anbieter für die Pflegeleistungen in einer Person der Softwareanbieter und gleichzeitig der Hersteller der Software ist, tritt die für den Softwareanbieter erkennbare Erwartung des Softwareanwenders, alle Leistungen, mithin auch die Pflegeleistungen, „aus einem Guss“, aus einer Hand zu erhalten, erst recht in den Vordergrund. Denn der Hersteller besitzt das technische Monopol am Quellcode – nur er kann auch in Zukunft die Nutzbarkeit der Software durch den Softwareanwender durch Fehlerbeseitigung, Anpassung und Weiterentwicklung sicherstellen. 1 BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467. 2 Hierzu auch Schneider, ITRB 2005, 191; Zahrnt, CR 2004, 408. 3 BGH v. 18.10.1989 – VIII ZR 325/88, CR 1990, 24; LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 4 LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414; Schneider, CR 2004, 241: Einheit kann sich auch über eine Option im Überlassungsvertrag, einen Pflegevertrag abzuschließen, ergeben (z.B. BVB-Überlassung); oder wenn im Pflegevertrag auf den Überlassungsvertrag zurückverwiesen wird.

876

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 94 I

b) Rechtliche Einheit im Drei-Personen-Verhältnis Sodann stellt sich die Frage, ob der Softwareanbieter der Annahme einer rechtlichen Einheit allein dadurch begegnen kann, dass er dafür sorgt, dass der Softwarepflegevertrag mit einem Dritten, und sei es ein eigenes Konzernunternehmen, abgeschlossen wird.

88

So wird die Frage einer rechtlichen Einheit von Hard- und Softwarevertrag auch bei Verträgen mit unterschiedlichen Unternehmen geprüft1 und in der Literatur ausnahmsweise dann bejaht, wenn der Softwarehersteller/-anbieter den Hardwarehersteller/-anbieter in Kenntnis des Kundenwunschs nach einer einheitlichen Lösung empfiehlt2.

89

Zunächst dürfte das Folgende offensichtlich sein: Die drei Vertragsparteien können kraft Privatautonomie eine rechtliche Einheit explizit miteinander vereinbaren.

90

Sollte eine solche ausdrückliche Vereinbarung zwischen den drei Vertrags- 91 parteien nicht geschlossen worden sein, ist nach den zuvor (Rz. 77 ff.) dargestellten Voraussetzungen im Weg der Auslegung (§§ 133, 157 BGB) zu prüfen, ob eine rechtliche Einheit von allen Vertragsparteien gewollt ist. Dabei spricht nichts dagegen, die widerleglichen Vermutungen für oder ge- 92 gen eine rechtliche Einheit (Niederlegung der Rechtsgeschäfte in einer Urkunde oder in getrennten Urkunden) im Zwei-Personen-Verhältnis ebenso auf das Drei-Personen-Verhältnis anzuwenden. Im Übrigen kann die – für eine rechtliche Einheit sprechende – Fallgestaltung im Zwei-Personen-Verhältnis, dass die Leistungen alle aus einer Hand und damit aus einem Guss kommen sollen, auch auf das Drei-PersonenVerhältnis übertragen werden. Bindet der Softwarehersteller oder -anbieter den Anbieter des Softwarepflegevertrags in sein Vertriebsnetz ein, erscheint die rein subjektive Aufteilung der Anbieterseite gekünstelt. Dies gilt erst recht, wenn es sich bei dem Dritten um ein Konzernunternehmen des Softwareherstellers/-anbieters handelt.

93

Dem dürfte nicht entgegenstehen, dass einzelne Leistungsanteile der Soft- 94 warepflege, für deren Erbringung die Inhaberschaft des Quellcodes nicht erforderlich ist (z.B. Hotline, Installationsleistungen bei Releasewechsel), vom Anbieter des Softwarepflegevertrags selbst erbracht werden. Diese Pflegeleistungen werden lediglich um die vom Softwarehersteller selbst erbrachten Leistungen (Fehler- und Störungsbeseitigung, Anpassungen und Weiterentwicklungen der überlassenen Software) herum angeboten, die ohne die (das Softwareprodukt selbst betreffenden) Pflegeleistungen im Wesentlichen keinen Sinn ergeben. 1 OLG Frankfurt v. 8.5.1985, in: Zahrnt, DV-Rechtsprechung Bd. 3, OLG 16; LG Köln v. 13.3.1984, in: Zahrnt, DV-Rechtsprechung Bd. 3, LG 94. 2 OLG Köln v. 25.8.2000 – 19 U 80/99, CR 2001, 224 mit Verweis auf Moritz/Tybussek, Computersoftware, 2. Aufl., Rz. 96.

Peter

877

I Rz. 95

Sonderregelungen

95 Soweit der Anbieter der Pflegeleistungen in das Vertriebsnetz des Softwareherstellers/-anbieters eingebunden ist, ist hierfür typisch, dass der Softwarehersteller/-anbieter dem Kunden den in sein Vertriebsnetz eingebundenen Anbieter der Pflegeleistungen empfiehlt. Die Empfehlung allein als Rechtfertigung für eine rechtliche Einheit im Drei-Personen-Verhältnis genügen zu lassen, erscheint nach dem Vorhergesagten eher nicht ausreichend zu sein. 96 Sollte die Fallgestaltung hingegen derart angelegt sein, dass der Softwarehersteller/-anbieter dem Anbieter der Pflegeleistungen den Quellcode übergibt und dass zum Ausdruck kommt, dass der Anbieter der Pflegeleistungen deshalb für die ordnungsgemäße Erbringung seines Leistungsteils alleine und selbständig verantwortlich ist, ist eindeutig, dass die Leistungen nicht aus einer Hand/nicht aus einem Guss sind. Allein eine Empfehlung des Anbieters für die Pflegeleistungen durch den Softwarehersteller kann in dieser Konstellation eine rechtliche Einheit nicht begründen. c) Rechtsfolgen 97 Besteht rechtliche Einheit zwischen dem Softwareüberlassungsvertrag und dem -pflegevertrag, ist es der rechtlichen Einheit immanent, dass beide Vereinbarungen miteinander „stehen und fallen“ sollen (Rz. 81). Wird also der Softwareüberlassungsvertrag beendet mit der Folge, dass der Softwareanwender die überlassene Software nicht mehr weiter nutzen darf (zum Fall der anfänglichen Nichtigkeit s. Rz. 101), kann sich der Softwareanwender auch vom Softwarepflegevertrag lösen und umgekehrt (Rz. 102). Dies gilt ebenso im Fall der rechtlichen Einheit im Drei-Personen-Verhältnis1. 98 Dabei ist anhand der vertraglichen Vereinbarungen bzw. anhand des jeweiligen Vertragstyps zu prüfen, welches Rechtsgeschäft hierfür zur Verfügung steht. 99 Insbesondere ist die Frage zu klären, ob weitere Voraussetzungen erfüllt sein müssen als nur die Feststellung der rechtlichen Einheit i.S.v. § 139 BGB. Entsprechendes gilt im Zusammenhang mit der Geltendmachung von Schadensersatz. aa) § 139 BGB 100

Soweit der Softwareüberlassungsvertrag oder der Softwarepflegevertrag nichtig ist und eine rechtliche Einheit mit der jeweils anderen Vereinbarung feststeht, ordnet § 139 BGB im Grundsatz ebenfalls Nichtigkeit des anderen Teils an, es sei denn, dass dieser ausnahmsweise auch ohne den nichtigen Teil geschlossen und durchgeführt worden wäre.

1 OLG Köln v. 25.8.2000 – 19 U 80/99, CR 2001, 224.

878

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 107 I

Ist der Softwareüberlassungsvertrag nichtig, hat die Aufrechterhaltung des Softwarepflegevertrags keinen Sinn mehr (Rz. 86)1. Dass somit im Rahmen der Wertungen des § 139 BGB der Softwarepflegevertrag aufrecht erhalten bleiben soll, erscheint schlichtweg unwahrscheinlich.

101

Soweit der Softwarepflegevertrag nichtig ist und eine rechtliche Einheit mit dem Softwareüberlassungsvertrag feststeht, dürfte eine Aufrechterhaltung des Softwareüberlassungsvertrags regelmäßig nicht in Betracht kommen. Ist die tatsächliche und wirtschaftliche Verknüpfung beider Vereinbarungen so groß, dass rechtliche Einheit festgestellt wurde, setzt diese Feststellung voraus, dass Softwareüberlassung ohne Softwarepflege nicht gewollt ist.

102

Wenn von den Vertragsparteien sog. salvatorische Klauseln vereinbart wur- 103 den, mithin die Ausnahmerechtsfolgeregelung des § 139 BGB die Regel sein soll, könnte sich dies formell dahingehend auswirken, dass sich der Softwareanwender an einem Teil eines Rechtsgeschäfts (Softwarepflege) festhalten lassen muss, mit dem er – isoliert betrachtet – gar nichts mehr anfangen kann. Sollte die salvatorische Klausel so gefasst sein, dass der Softwarepflegever- 104 trag bestehen bleibt, dürfte der Softwareanwender gegen die Einforderungen von Entgelten aus – soweit überhaupt noch möglich – rechtswirksam angebotenen Pflegeleistungen mit Erfolg die Einrede der unzulässigen Rechtsausübung i.S.v. § 242 BGB erheben dürfen. Zuletzt sei angemerkt, dass diejenige Vertragspartei die Beweislast für die 105 Einheitlichkeit des Geschäfts trägt, die sich auf die Gesamtnichtigkeit beruft2. bb) Rücktritt und Schadensersatz Ist der Softwareanwender berechtigt, von der einen Vereinbarung wegen 106 nicht oder nicht vertragsgemäß erbrachter Leistungen zurückzutreten, fragt sich, ob er mangels einer ausdrücklichen vertraglichen Abrede auch von der anderen Vereinbarung zurücktreten kann, mithin der Rücktritt der einen Vereinbarung die andere Vereinbarung erfasst, obschon der Softwareanbieter oder ein Dritter die Leistungen in Bezug auf die andere Vereinbarung vertragsgemäß erbracht hat. Hat der Softwareanbieter in Bezug auf die Softwareüberlassung oder die 107 Softwarepflege nicht wie geschuldet (z.B. mangelhaft) geleistet, ist fraglich, ob der Softwareanwender im Weg des großen Schadensersatzes vorgehen und daher u.a. die Vergütung für die Vereinbarung zurückverlangen kann, die mangelfrei erbracht wurde. Um dieses Ziel zu erreichen, kann seit der 1 BGH v. 18.10.1989 – VIII ZR 325/88, CR 1990, 24; LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 2 Palandt/Ellenberger, § 139 BGB Rz. 5 mit Verweis auf BGH v. 23.7.1997 – VIII ZR 130/96, NJW 1997, 3304.

Peter

879

I Rz. 108

Sonderregelungen

Schuldrechtsmodernisierung der Softwareanwender auch den Weg über § 284 BGB gehen1, wenn die Voraussetzungen des § 281 BGB vorliegen2. 108

Die zuvor gestellten Fragen können nur dann einer positiven Beantwortung zugeführt werden, wenn der Gläubiger an der vom Schuldner bewirkten Teilleistung kein Interesse mehr hat, § 281 Abs. 1 Satz 2 und § 323 Abs. 5 BGB. Nichts anderes gilt im Fall der Unmöglichkeit der Leistung (§ 275 BGB): Hier findet ebenfalls § 281 Abs. 1 Satz 2 BGB Anwendung, § 283 Satz 2 BGB.

109

Danach sind also zwei Fragen zu beantworten: Ist der Abschluss eines Softwareüberlassungsvertrags und eines Softwarepflegevertrags als eine unteilbare Leistung, jeder Teil also als Teilleistung anzusehen, und unter welchen Voraussetzungen ist Interessenfortfall anzunehmen? (1) Teilleistung

110

Fraglich ist, was unter dem Tatbestandsmerkmal „Teilleistung“ der § 281 Abs. 1 Satz 2 und § 323 Abs. 5 BGB zu verstehen ist. Obergerichtliche Rechtsprechung liegt in Bezug auf das Verhältnis von Softwareüberlassung und Softwarepflege nicht vor. Demnach ist zunächst festzustellen, welche Gesetzesvorschriften im Rahmen der Schuldrechtsreform durch § 281 Abs. 1 Satz 2 und § 323 Abs. 5 BGB abgelöst wurden und wie die Rechtsprechung die entsprechenden Tatbestandsmerkmale der vor der Schuldrechtsmodernisierung wirksamen Vorschriften definiert hatte. (a) Auswirkungen der Schuldrechtsmodernisierung

111

§ 281 und § 323 BGB sind im Weg der Schuldrechtsmodernisierung in das BGB neu eingefügt worden. § 323 BGB ersetzt seitdem das Rücktrittsrecht des gleichzeitig aufgehobenen (alten) § 326 BGB3; Entsprechendes gilt für § 281 BGB (neu) und § 326 BGB (alt) in Bezug auf Schadensersatz4.

112

Ebenso wurde mit der Schuldrechtsmodernisierung der (alte) § 469 BGB aufgehoben und durch § 437 Nr. 2 BGB ersetzt, der auf § 323 BGB verweist5.

113

Gleiches wurde im Rahmen der Schuldrechtsmodernisierung im Werkvertragsrecht umgesetzt. Der (alte) § 634 Abs. 5 BGB mit der Anordnung, § 469 BGB entsprechend anzuwenden, wurde aufgehoben und durch § 634 Nr. 3 BGB ersetzt, der wiederum auf § 323 BGB verweist6.

1 2 3 4 5

Schneider, Handbuch des EDV-Rechts, K. Rz. 276 a.E. Palandt/Grüneberg, § 284 BGB Rz. 4. Palandt/Grüneberg, § 323 BGB Rz. 1. Palandt/Grüneberg, Vorb § 281 BGB Rz. 1. Palandt/Wiedenkaff, Überbl. vor § 433 BGB Rz. 5, 8; BT-Drucks. 14/6040, S. 205 i.V.m. BT-Drucks. 14/6857, S. 29 f. und S. 62. 6 Palandt/Sprau, Vorb. vor § 633 BGB Rz. 1.

880

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 118 I

§ 469 BGB (alt) ordnete für den Fall, dass von mehreren verkauften Sachen 114 nur einzelne mangelhaft sind, das Folgende an: Jeder (Vertrags-)Teil kann verlangen, dass die Wandlung auf alle Sachen erstreckt wird, wenn die Sachen als zusammengehörend verkauft sind und die mangelhaften Sachen nicht ohne Nachteil für ihn von den übrigen getrennt werden können. (b) BGH zur Teilbarkeit der Leistung vor der Schuldrechtsmodernisierung Im Zusammenhang mit der Frage nach der unteilbaren Einheit eines 115 Rechtsverhältnisses (Teilleistung) bzw. der in diesem Sinne verstandenen Zusammengehörigkeit von Sachen hatte der BGH zu § 326 BGB (alt)1 und § 469 BGB (alt)2 zunächst betont, dass sich deren Beantwortung in erster Linie nach der Verkehrsanschauung richtet3. Wichtiges Indiz gegen eine Zusammengehörigkeit ist danach, ob beide Teilleistungen selbständige Vertragsobjekte sind, ob also für sie eigene Märkte bestehen4. Anschließend hat der 8. Zivilsenat des BGH die Rechtsprechung insoweit modifiziert, als dass sich die Zusammengehörigkeit von Sachen i.S.d. § 469 BGB (alt) auch aus der Absicht der Vertragsteile und dem Vertragszweck ergeben kann5. Dieser Rechtsprechung hat sich der 10. Zivilsenat im Zusammenhang mit § 326 BGB (alt) angeschlossen6.

116

Letztlich hat der 8. Zivilsenat des BGH in Bezug auf § 326 BGB (alt) fest- 117 gehalten, dass eine Vereinbarung über die Unteilbarkeit der Leistung im Übrigen auch stillschweigend getroffen werden kann7. Für die Feststellung einer solchen konkludenten Absprache können dieselben Kriterien herangezogen werden, die dafür maßgebend sind, ob mehrere, rechtlich verschieden zu beurteilende Vereinbarungen einen einheitlichen Vertrag i.S.d. § 139 BGB bilden, dessen Leistungen miteinander „stehen oder fallen“ sollen und bei dem von vornherein nur eine vollständige Rückgängigmachung in Betracht kommt, wenn auch nur eine von mehreren Leistungsteilen nicht vertragsgemäß erbracht wird8. (c) Übertragung der BGH-Rechtsprechung auf das neue Schuldrecht Sollte eine Übertragung der Rechtsprechung des BGH zur Unteilbarkeit von 118 Leistungen (§ 326 BGB alt) bzw. zur Zusammengehörigkeit von Sachen (§ 469 BGB alt) auf das Tatbestandsmerkmal „Teilleistung“ des § 281 Abs. 1 1 BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467. 2 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 994. 3 BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467 und BGH v. 4.11.1987 – VIII ZR 314/86, MDR 1988, 223 = CR 1988, 124. 4 BGH v. 4.11.1987 – VIII ZR 314/86, CR 1988, 994 zur Frage, ob Hard- und Software verselbständigten Märkten zuzuordnen sind. 5 BGH v. 25.1.1989 – VIII ZR 49/88, NJW-RR 1989, 559. 6 BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467. 7 BGH v. 7.3.1990 – VIII ZR 56/89, CR 1990, 707. 8 BGH v. 7.3.1990 – VIII ZR 56/89, CR 1990, 707.

Peter

881

I Rz. 119

Sonderregelungen

Satz 2 und des § 323 Abs. 5 BGB erfolgen, ist eines klar: Schon eine stillschweigende Vereinbarung der Vertragsparteien über die Einheitlichkeit von Softwareüberlassung und -pflege i.S.d. § 139 BGB genügt, um Softwareüberlassung oder -pflege als Teilleistung i.S.d. §§ 281 Abs. 1 Satz 2, 323 Abs. 5 BGB zu subsumieren1. (2) Interessenfortfall 119

Ob ein Interessenfortfall für den Gläubiger zum Zeitpunkt der Rücktrittserklärung oder der Geltendmachung des (großen) Schadensersatzes besteht, ist anhand seiner besonderen Verhältnisse, jedoch objektiv zu beurteilen und kommt namentlich in Betracht, wenn die konkreten Zwecke des Gläubigers mit der erbrachten Leistung auch nicht teilweise verwirklicht werden können2.

120

Danach gilt für das Verhältnis von Softwareüberlassung und -pflege: Der Softwarepflegevertrag ist ohne den Softwareüberlassungsvertrag sinnlos3.

121

Hingegen kann der Softwareüberlassungsvertrag ohne die Softwarepflege noch zweckmäßig sein, und zwar dann, wenn die weitere Nutzung der Software ohne Pflege zum Zeitpunkt der Beendigung des Softwarepflegevertrags für den Softwareanwender – unter objektiven Gesichtspunkten – von Interesse bleibt.

122

Allein die Amortisation4 oder die steuerliche Abschreibung dürften für die Feststellung eines Interessenfortfalls daher nicht maßgeblich sein. Entscheidend wird vielmehr das – objektiv festzustellende – Investitionssicherungs- und -erhaltungsinteresse des Softwareanwenders sein und die Beantwortung der Frage, wie wichtig der Einsatz der Software für ihn ist (Rz. 10) und ob er die überlassene Software zu seinen – objektiv festzustellenden – Nutzungszwecken ohne Softwarepflege einsetzen kann5. (3) Abdingbarkeit des § 323 BGB

123

§ 323 BGB ist dispositiv und kann individualvertraglich außerhalb des Verbrauchsgüterkaufs abbedungen werden6. Ob § 323 BGB neben einer vertrag1 S. hierzu Palandt/Grüneberg, § 281 BGB Rz. 36 und Palandt/Grüneberg, § 323 BGB Rz. 23, jeweils mit Verweis auf Heiderhoff/Skamel, JZ 2006, 383. 2 BGH v. 7.3.1990 – VIII ZR 56/89, CR 1990, 707; LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 3 BGH v. 18.10.1989 – VIII ZR 325/88, CR 1990, 24; LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 4 A.A. LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 5 So wird z.B. ERP (Enterprise Ressource Planning) – Software in Großunternehmen, die die zentralen Geschäftsprozesse wie z.B. Buchhaltung im Unternehmen abbildet, nach einer ein- bis zweijährigen Einführungsphase in der Regel über viele weitere Jahre genutzt; der Aufwand eines Wechsels zu einem anderen Anbieter wird wegen der damit verbundenen Aufwände und Risiken gescheut. 6 Palandt/Grüneberg, § 323 Rz. 2.

882

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 127 I

lichen Rücktrittsregelung anwendbar ist, ist Auslegungsfrage1. Das Rücktrittsrecht des Softwareanwenders durch AGB auszuschließen oder einzuschränken ist grundsätzlich nicht zulässig, vgl. § 309 Nr. 8a), Nr. 8b) bb) BGB und § 307 BGB. cc) Kündigung Falls die Vertragsparteien ihre Vereinbarungen mit einem vertraglich ver- 124 einbarten ordentlichen und/oder außerordentlichen Kündigungsrecht versehen haben2, ist im Fall der Kündigungsausübung zu klären, ob beide Verträge eine rechtliche Einheit i.S.d. § 139 BGB bilden (Rz. 75 ff.). Sollte das der Fall sein, ist der rechtlichen Einheit zunächst immanent, dass beide Vereinbarungen miteinander „stehen oder fallen“ sollen, so dass danach eine Kündigung der einen Vereinbarung die andere Vereinbarung miterfasst. Aber wie im Fall des Rücktritts oder des Schadensersatzes ist bei der Kün- 125 digung zusätzlich der Zeitpunkt der Ausübung des Kündigungsrechts beachtlich. Die Frage der rechtlichen Einheit nach Maßgabe des Parteiwillens wird für den Zeitpunkt des Abschlusses der Vereinbarungen beantwortet (Rz. 81). Der Beendigung auch des anderen Vertrags im Fall der Kündigung kann aber § 242 BGB entgegenstehen, denn wenn der Rücktritt die andere Vereinbarung nicht erfasst, weil deren weitere Erfüllung objektiv noch im Interesse des Gläubigers liegt, dürfte es – ebenso wie bei Rücktritt oder Schadensersatz – gegen Treu und Glauben gerichtet sein, wenn bei der Kündigung zum Zeitpunkt ihrer Ausübung die objektive Bewertung der Interessenlage ergibt, dass der Gläubiger noch Interesse an der teilweisen Erfüllung hat. Soweit die Vertragsparteien den Softwarepflegevertrag nicht mit einem 126 vertraglich vereinbarten Kündigungsrecht versehen haben, richtet sich die Frage der Berechtigung zur ordentlichen und/oder außerordentlichen Kündigung nach der vertragstypologischen Einordnung des jeweiligen Vertrags (Softwareüberlassung bzw. -pflege) und den gesetzlichen Vorgaben hierzu. Sollte eine Vertragspartei berechtigt sein, eine der beiden Vereinbarungen zu kündigen, ist § 242 BGB ebenso beachtlich, wie im Fall der vertraglich vereinbarten Kündigung. Wird eine der beiden Vereinbarungen – Softwareüberlassung oder -pflege – 127 verletzt, kann der mittels rechtlicher Einheit verbundene andere Vertrag

1 Palandt/Grüneberg, § 323 Rz. 2 mit Verweis auf OLG Hamm v. 1.12.1986 – 5 U 107/86, BB 1989, 1438. 2 Das gilt in Bezug auf die Softwareüberlassung, soweit diese als Dauerschuldverhältnis (Miete, Leihe) ausgestaltet ist. Die Softwarepflege kann als Dauerschuldverhältnis bezeichnet werden, vgl. Bischof/Witzel, ITRB 2003, 31; Bartsch, NJW 2002, 1526; Marly, Praxishandbuch Softwarerecht, Rz. 1030; Schneider, Handbuch des EDV-Rechts, K. Rz. 50; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 1.12 Rz. 12.

Peter

883

I Rz. 128

Sonderregelungen

nicht unter Aufrechterhaltung des verletzten Vertrages gekündigt werden1. dd) Einwendungsdurchgriff 128

Wenn eine rechtliche Einheit im Drei-Personen-Verhältnis besteht, fragt sich, ob der Softwareanwender Einwendungen aus den Vereinbarungen zur Softwareüberlassung dem Anbieter für die Softwarepflege entgegenhalten kann und umgekehrt. Im Zwei-Personen-Verhältnis sind die Voraussetzungen der §§ 273, 320 BGB zu prüfen.

129

Der Einwendungsdurchgriff im Drei-Personen-Verhältnis setzt voraus, dass ein wirtschaftlich einheitliches, innerlich zusammengehörendes Geschäft in zwei rechtlich selbständige Verträge aufgespalten wird und es Treu und Glauben bei auftretenden Störungen rechtfertigen, die Trennung nicht zu beachten und den Einwendungsdurchgriff zuzulassen2.

130

In Bezug auf das Verhältnis von Softwareüberlassung und -pflege liegt Rechtsprechung des BGH hierzu nicht vor. Das OLG Köln ist in diesem Zusammenhang jedenfalls – ohne nähere Begründung – der Ansicht, dass bei der Frage nach der rechtlichen Einheit im Drei-Personen-Verhältnis beim Hard- und Softwarevertrag die Grundsätze des Einwendungsdurchgriffs herangezogen werden können3.

131

Überträgt man die Grundsätze des BGH zum Einwendungsdurchgriff beim finanzierten Kauf4 auf die hier eingangs gestellte Frage, ist der vorstehenden Ansicht des OLG Köln grundsätzlich zu folgen, denn beim finanzierten Kauf kann der Käufer und Darlehensnehmer nach ständiger Rechtsprechung des BGH dem Darlehensgeber trotz rechtlicher Selbständigkeit des Darlehensvertrags nach Treu und Glauben Einwendungen aus dem Kaufvertrag entgegenhalten, wenn Kauf- und Darlehensvertrag eine wirtschaftliche 1 Palandt/Grüneberg, Überbl. vor § 311 BGB Rz. 17 mit Verweis auf BGH JZ 1972, 493. 2 Palandt/Grüneberg, Überbl. vor § 311 BGB Rz. 18 mit Verweis auf BGH v. 25.3.1982 – III ZR 198/80, BGHZ 83, 301, 303 f. = MDR 1982, 732; BGH v. 5.5.1992 – XI ZR 242/91, MDR 1992, 1144 = NJW 1992, 2562. 3 OLG Köln v. 25.8.2000 – 19 U 80/99, CR 2001, 224: Danach kann von einer rechtlichen Einheit dann ausgegangen werden, wenn der Kunde nicht auf eigene Initiative verschiedene Verträge abschließt, durch Zusammenwirken ein Komplettsystem geliefert wird, die Software nur auf eine bestimmte Hardware eingesetzt werden soll, der Eindruck erweckt wird, als steht dem Kunden nur ein Vertragspartner gegenüber, ein enger zeitlicher und sachlicher Zusammenhang der Lieferungen besteht und der zweite Vertragsschluss vom ersten Lieferanten vermittelt wird. Zur rechtlichen Einheit im Zwei-Personen-Verhältnis bei einem Software- und Hardwaregeschäft: OGH Österreich v. 8.3.2005 – 9 Ob 81/04h, CR 2006, 155; OLG Hamm v. 14.2.2000 – 13 U 196/99, CR 2000, 811. Soll eine Software- und Hardwarelieferung in einer Hand liegen, liegt in der Regel rechtliche Einheit vor: BGH v. 23.1.1996 – X ZR 105/93, CR 1996, 467. 4 Bei Verbrauchern vgl. §§ 358, 359 BGB.

884

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 134 I

Einheit bilden und die Risiken des finanzierten Kaufs sonst nicht angemessen verteilt sind1. Eine solche Einheit bilden Kauf- und Darlehensvertrag, wenn beide Geschäfte über ein Zweck-Mittel-Verhältnis hinaus derart miteinander verbunden sind, dass keines ohne das andere geschlossen worden wäre oder jeder der Verträge seinen Sinn erst durch den anderen erhält2. Diese Feststellung setzt voraus, dass objektiv bestimmte Umstände (Verbindungselemente) vorliegen und dadurch subjektiv beim Darlehensnehmer – für den Darlehensgeber erkennbar – der Eindruck erweckt wird, dass ihm Verkäufer und Darlehensgeber gemeinsam als Vertragspartner gegenüberstehen3. Auf das Verhältnis von Softwareüberlassung und -pflege übertragen bedeutet das: Der Softwarepflegevertrag hat ohne den Softwareüberlassungsvertrag keinen Sinn4. Aus der Sicht des Softwarepflegevertrags gehört dieser mit dem Softwareüberlassungsvertrag untrennbar zusammen.

132

Aus dem Blickwinkel des Softwareüberlassungsvertrags ergibt sich: Wird 133 festgestellt, dass der Softwareanwender sein Investitionssicherungs- und -erhaltungsinteresse mit beiden Vereinbarungen unbedingt verknüpft und der Dritte in das Vertriebsnetz des Softwareanbieters derart eingebunden ist, dass sogar rechtliche Einheit im Drei-Personen-Verhältnis angenommen werden kann (Rz. 93), ist diese Konstellation nicht anders als beim kreditfinanzierten Kauf zu bewerten; bei diesem wird sogar nur wirtschaftliche Einheit vorausgesetzt. 2. Kündigung aus wichtigem Grund ohne Vorliegen einer rechtlichen Einheit Lässt sich rechtliche Einheit zwischen Softwareüberlassung und -Pflege 134 nicht feststellen, kann die Auflösung einer der beiden Vereinbarungen einen wichtigen Grund i.S.d. § 314 BGB für die Kündigung der anderen Vereinbarung darstellen5. Dies geht der Geltendmachung von Ansprüchen nach § 313 BGB (Störung der Geschäftsgrundlage) vor6.

1 BGH v. 5.5.1992 – XI ZR 242/91, MDR 1992, 1144 = NJW 1992, 2560 mit Verweis auf BGH v. 25.3.1982 – III ZR 198/80, BGHZ 83, 301, 303 f. = MDR 1982, 732 m.w.N. 2 BGH v. 5.5.1992 – XI ZR 242/91, MDR 1992, 1144 = NJW 1992, 2560. 3 BGH v. 5.5.1992 – XI ZR 242/91, MDR 1992, 1144 = NJW 1992, 2560 mit Verweis auf weitere BGH-Entscheidungen. 4 BGH v. 18.10.1989 – VIII ZR 325/88, CR 1990, 24; LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 5 Palandt/Grüneberg, Überbl. vor § 311 BGB Rz. 17 mit Verweis auf BGH MDR 1959, 483. 6 Palandt/Grüneberg, § 313 BGB Rz. 14 mit Verweis auf BGH v. 9.10.1996 – VIII ZR 266/95, MDR 1997, 235 = ZIP 1997, 257.

Peter

885

I Rz. 135

Sonderregelungen

135

Eine Kündigung nach § 314 BGB kommt nur dann in Betracht, wenn der zu kündigende Vertrag ein Dauerschuldverhältnis darstellt1, was im Falle der Softwarepflege regelmäßig der Fall ist2.

136

Fällt der Softwareüberlassungsvertrag weg, ist die Aufrechterhaltung der Softwarepflege nicht mehr sinnvoll3. Dieser Umstand dürfte daher grundsätzlich ein wichtiger Grund i.S.d. § 314 Abs. 1 Satz 2 BGB sein. Ausnahmsweise dürfte ein wichtiger Grund dann nicht bestehen, wenn der Softwareanwender den Softwarepflegevertrag sowieso alsbald kündigen kann.

137

Ist der Softwarepflegevertrag nicht existent, ist eine Kündigung des Softwareüberlassungsvertrags aus wichtigem Grund nach § 314 BGB nur dann im Ansatz möglich, wenn dieser als Dauerschuldverhältnis abgeschlossen wurde. Ob und inwieweit ein wichtiger Grund i.S.d. § 314 Abs. 1 Satz 2 BGB vorliegt, bestimmt sich nach der dort normierten Unzumutbarkeitsbewertung. Sollte die weitere Nutzung der Software ohne Pflege zum Zeitpunkt der Beendigung des Softwarepflegevertrags für den Softwareanwender – objektiv betrachtet – von Interesse sein und zweckmäßig bleiben (Rz. 121 f.), spricht ein starkes Indiz gegen einen wichtigen Grund zur Kündigung des Softwareüberlassungsvertrags. 3. Wegfall der Geschäftsgrundlage

138

Wenn der Softwareüberlassungsvertrag mit dem Softwarepflegevertrag keine rechtliche Einheit bildet, kann der Fortfall des Softwarepflegevertrags die Möglichkeit eröffnen, die Rechtsfolgen des § 313 BGB geltend zu machen4. Denn die Wirksamkeit des einen Vertrags kann Geschäftsgrundlage i.S.d. § 313 BGB für den anderen sein5. Danach kann der benachteiligte Teil sogar vom Vertrag zurücktreten oder diesen – bei Dauerschuldverhältnissen – kündigen6, wenn eine Anpassung desselben einem Vertragsteil nicht zugemutet werden kann, § 313 Abs. 3 Satz 1 bzw. Satz 2 BGB7. 1 BGH v. 9.3.2010 – VI ZR 52/09, NJW 2010, 1874. 2 Bischof/Witzel, ITRB 2003, 31; Bartsch, NJW 2002, 1526; Marly, Praxishandbuch Softwarerecht, Rz. 1029; Schneider, Handbuch des EDV-Rechts, K. Rz. 49; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 1.12 Rz. 12. 3 BGH v. 18.10.1989 – VIII ZR 325/88, CR 1990, 24; LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 4 Zu der Frage, ob Softwareüberlassung und -pflege eine gemeinsame Geschäftsgrundlage haben, siehe Schneider, Handbuch des EDV-Rechts, K. Rz. 274. 5 Palandt/Ellenberger, § 139 BGB Rz. 6 a.E.; OLG München v. 22.5.1985 – 7 U 5343/84, CR 1985, 138 im Verhältnis Wartungsvertrag für Hardware und Softwarelieferung. 6 BGH v. 9.3.2010 – VI ZR 52/09, NJW 2010, 1874. 7 Zur Frage des Wegfalls der Geschäftsgrundlage eines Hardwarewartungsvertrages wegen Mangels der Software: OLG München v. 22.5.1985 – 7 U 5343/84, CR 1985, 138 und hierzu Etter, CR 1985, 139. Zur Frage des Wegfalls der Geschäftsgrundlage eines Schulungsvertrages, wenn der Softwarekauf rückabgewickelt wird: OLG Hamm v. 3.2.1997 – 13 U 153/96, CR 1998, 202. S.a. OLG München

886

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 144 I

V. Kopplung von Softwareüberlassungs- und -pflegevertrag Macht der Softwareanbieter den Abschluss eines Softwareüberlassungsver- 139 trags von der Eingehung eines Softwarepflegevertrags abhängig, ist dieses Begehren von den Grundsätzen der Privatautonomie im Ansatz gedeckt (zur Privatautonomie s. Rz. 57). In das Recht des Einzelnen, nach eigenem Ermessen zu entscheiden, ob und 140 mit wem bzw. mit welchem Inhalt Verträge geschlossen werden sollen (Vertragsfreiheit), kann auf Grund eines Gesetztes eingegriffen werden (Art. 2 Abs. 2 Satz 3 GG)1. Nach Maßgabe des § 19 Absätze 1 und 4 GWB setzt die Beantwortung der Frage nach der Unzulässigkeit eines derartigen Kopplungsgeschäfts die Feststellung einer marktbeherrschenden Stellung voraus, welche missbräuchlich ausgenutzt wird. Derartiges wettbewerbswidriges Verhalten ist nach § 19 Abs. 1 GWB verboten.

141

Außerdem setzt sich der missbräuchlich Handelnde der Gefahr der Inanspruchnahme durch Dritte auf Unterlassung, Beseitigung oder Schadensersatz aus, § 33 GWB. Im Übrigen kann die Kartellbehörde den dadurch erlangten wirtschaftlichen Vorteil abschöpfen, § 34 GWB.

142

Unter Einbeziehung des Rechtsgedankens des § 16 Nr. 4 GWB, der mit dem 143 7. Gesetz zur Änderung des Gesetzes gegen Wettbewerbsbeschränkungen vom 7.7.2005 aufgehoben wurde2, sind Kopplungsgeschäfte in Austauschverträgen kartellrechtlich grundsätzlich zulässig3. Nach dem (alten) § 16 GWB unterlagen Vereinbarungen, die einen Beteiligten verpflichten, Waren oder gewerbliche Leistungen abzunehmen, die weder sachlich noch handelsüblich zusammengehören, der Missbrauchsaufsicht des Bundeskartellamtes. Dies wird man jedoch bei einem Softwarepflegevertrag generell nicht annehmen können – im Gegenteil: Regelmäßig ist die Softwarepflege mit der Softwareüberlassung tatsächlich und wirtschaftlich als zusammengehörend verknüpft (Rz. 2 ff., 10 ff.). Um Missbräuchlichkeit i.S.d. § 19 GWB annehmen zu können, müssen da- 144 her andere – wettbewerbsrechtlich bedenkliche – Umstände hinzukommen als allein die Verknüpfung der Softwareüberlassung mit der Softwarepflege4.

1 2 3 4

v. 22.5.1985 – 7 U 5343/84, CR 1985, 138 zur Tragweite der rechtlichen Verknüpfung eines Hardwarewartungs- mit einem Softwarenutzungsvertrag bei Mängeln der Software. EU-Kartellrecht ist hier nicht betrachtet. BGBl. I Nr. 42 S. 1954 ff. BGH v. 9.7.2002 – KZR 30/00, MDR 2003, 167 = NJW 2002, 3779. Vgl. hierzu beispielhaft: BGH v. 30.3.2004 – KZR 1/03, CR 2004, 662 m. Anm. Schütze/Schulze zur Wiesche = NJW 2004, 2375; BGH v. 4.11.2003 – KZR 16/02, CR 2004, 602 = NJW-RR 2004, 1178; BGH v. 9.7.2002 – KZR 30/00, MDR 2003, 167 = NJW 2002, 3779.

Peter

887

I Rz. 145

Sonderregelungen

VI. Sittenwidriger Softwarepflegevertrag 145

Nach § 138 Abs. 1 BGB ist ein Rechtsgeschäft, das gegen die guten Sitten verstößt, nichtig; das gilt insbesondere im Fall des Wuchers (Abs. 2).

146

Das AG Hanau hat im Juni 1998 rechtskräftig entschieden, dass ein Softwarepflegevertrag i.S.v. § 138 BGB sittenwidrig ist, wenn dem Softwareanwender eine regelmäßige Aktualisierungspflicht vertraglich auferlegt wird und diese mittels einer wiederkehrenden Dateisperre abgesichert wird1.

147

Unter mehreren Aspekten, die zu einem branchenfremden und auffallenden Missverhältnis zwischen Leistung und Gegenleistung führten, stellte das Gericht insbesondere folgende Gesichtspunkte heraus: Durch die Sperre des Zugriffs auf Daten des Kunden werde derselbe gezwungen, jedes auch unerwünschte oder sinnlose Update abzunehmen. Der feste Zeitplan für die Updates zeige, dass der Softwareanbieter sogar bereits gelöste Fehler der Programme nicht unverzüglich zu beseitigen beabsichtige, sondern den Softwareanwender bis zum nächsten Termin warten lasse. Dieses Urteil zeigt deutlich, dass die – übertriebene – Absicherung bzw. Durchsetzung von Aktualisierungspflichten mittels softwaretechnisch gestützter Maßnahmen zur Nichtigkeit des gesamten Geschäfts führen kann.

VII. Vertragsgegenstand und Entgeltproblematiken 148

Nicht nur im anglo-amerikanischen Raum ist es üblich und sinnvoll, in einer kurzen Beschreibung den Vertragsgegenstand (Subject Matter of the Agreement) darzulegen und festzuhalten, welches Ziel die Vertragsparteien mit der Vereinbarung verfolgen und was Inhalt der nachfolgenden Regelungen sein soll2.

149

Diese Ausführungen können neben den Beschreibungen in einer Präambel zum Vertrag der Auslegung bei Unklarheiten dienen und führen so – zusätzlich als kurzer Überblick – in die vertraglich zu vereinbarende Materie ein. 1. Verhältnis der Entgeltpflicht für Mängelbeseitigung zur Mängelhaftung aus dem Softwareüberlassungsvertrag

150

In der juristischen Literatur wird ausführlich diskutiert, ob der Softwarepflegeanbieter im Zusammenhang mit AGB ein Entgelt für die Mängelbeseitigung während des Laufs der Mängelhaftungsfrist aus dem Softwareüberlassungsvertrag verlangen darf3; bei einem Softwareüberlassungsvertrag, der als 1 AG Hanau v. 26.6.1998 – 31 C 709/98, NJW-CoR 1998, 434 (Leitsatz). 2 Petri/Göckel, in: Moritz/Dreier, Rechts-Handbuch zum E-Commerce, B. Rz. 113. 3 Schneider, CR 2011, 626 differenzierend dazu, welche Softwarepflegeleistungen der Mängelbeseitigung dienen können.

888

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 155 I

Mietvertrag vereinbart ist, wird diese Frage auf die Laufzeit des Mietvertrags bezogen. Denn während der Mietzeit ist der Vermieter ohnehin zur Aufrechterhaltung der Gebrauchstauglichkeit verpflichtet (§ 535 Abs. 1 Satz 2 BGB)1. a) Drei-Personen-Verhältnis Die AGB-rechtliche Problematik soll nur dann bestehen, wenn der Soft- 151 wareanbieter und der Anbieter der Pflegeleistungen personenidentisch – oder als personenidentisch zu behandeln – sind2. Auf dieser Grundlage würde die genannte AGB-rechtliche Problematik 152 grundsätzlich ausfallen, wenn der Anbieter der Softwareüberlassung und der Anbieter der Softwarepflege unterschiedliche Rechtspersonen sind. Welche Anforderungen erfüllt sein müssen, damit in einem Drei-Personen-Verhältnis beide – der Anbieter der Softwareüberlassung und der Anbieter der Softwarepflege – in Bezug auf die vorgenannte Aussage als personenidentisch zu behandeln sind, ist von der Judikatur bislang nicht diskutiert worden. Diese Frage dürfte sich aber mit den zuvor behandelten Grundsätzen zur 153 rechtlichen Einheit beantworten lassen (Rz. 75 ff.), denn wenn zwischen dem Softwareüberlassungsvertrag und dem -pflegevertrag eine rechtliche Einheit besteht, spricht nichts dagegen, die genannte AGB-rechtliche Problematik auch im Drei-Personen-Verhältnis anzuwenden, falls die nur subjektive Aufteilung der Anbieterseite rein gekünstelt ist (zur rechtlichen Einheit im Drei-Personen-Verhältnis s. Rz. 88 ff.). b) Individualvereinbarung Es ist nicht ausnahmslos unproblematisch, im Rahmen von Individualvereinbarungen beim Softwarepflegevertrag entgeltliche Vereinbarungen über die Mängelbeseitigung festzuschreiben, wenn zugleich aus der Softwareüberlassung Mängelbeseitigung verlangt werden kann3.

154

aa) Individualvereinbarung über das Mängelbeseitigungsentgelt im Softwarepflegevertrag Zu der Feststellung, wann trotz eines von einer Vertragspartei gestellten 155 und i.S.d. § 305 Abs. 1 Satz 1 BGB „vorformulierten“ Vertragstexts nunmehr von einer Individualvereinbarung i.S.d. § 305 Abs. 1 Satz 3 BGB auszugehen ist, mithin diese als „ausgehandelt“ zu behandeln ist, damit keine

1 Runte, CR 2003, 253. 2 Bartsch, NJW 2002, 1526. 3 Schneider, ITRB 2005, 191; Bischof/Witzel, ITRB 2003, 31; v. Baum, CR 2002, 705.

Peter

889

I Rz. 156

Sonderregelungen

AGB (mehr) vorliegt, § 305 Abs. 1 Satz 3 BGB, ist auf die Entscheidungspraxis des BGH hinzuweisen. 156

Der BGH führt hierzu aus: „… Eine solche Individualabrede liegt bei einem von einer Partei gestellten Vertragstext dann vor, wenn der Verwender den in seinen AGB enthaltenen gesetzesfremden Kerngehalt inhaltlich ernsthaft zur Disposition stellt und dem Verhandlungspartner einen Einfluss auf die inhaltliche Ausgestaltung der Vertragsbedingungen tatsächlich einräumt“1. Zu den Voraussetzungen einer Individualvereinbarung in Abgrenzung zu einer AGB s. im Einzelnen Kapitel J. (Individualvereinbarung).

157

Im Zusammenhang mit der Frage, ob eine individuell ausgehandelte Vertragsklausel rechtswirksam ist, nach der die Vermietererhaltungspflicht gemäß § 535 Abs. 1 Satz 2 BGB beim Gewerbemietraum auf den Gewerberaummieter abgewälzt wird, hat der BGH zusammengefasst das Folgende herausgestellt2: In der Regel kann davon ausgegangen werden, dass beide Vertragsparteien bei den Vertragsverhandlungen in der Lage waren, ihre Interessen ausreichend zu wahren. Eine Individualvereinbarung kann insbesondere unter den Voraussetzungen des § 138 BGB3 als unwirksam angesehen werden. Grundsätzlich kann ein Mieter durch Individualvereinbarung weitgehend zu Reparaturen und Instandsetzungsarbeiten verpflichtet werden, auch wenn dies im Ergebnis zu einer verschuldensunabhängigen Haftung führt. Gegen eine solche Abrede bestehen insbesondere dann keine Bedenken, wenn die Übernahme der Erhaltungspflicht in die Mietzinskalkulation eingeht4.

158

Überträgt man diesen Rechtsgedanken auf die hier zu untersuchende Frage, tritt unzweifelhaft keine Kollision mit § 138 BGB auf, wenn das Entgelt für die Mängelbeseitigung zugunsten des Softwareanwenders in die Preiskalkulation der Softwareüberlassung eingeflossen ist. Wenn die Verpflichtung zur Vergütung der Mängelbeseitigung bei der Bemessung des Überlassungsentgelts für die Software berücksichtigt worden ist, stellt sich das Entgelt für die Mängelbeseitigung nach der Pflegevereinbarung auch als ein Teil des Entgelts dar, das als Gegenleistung für die Softwareüberlassung zu entrichten war, so dass Sittenwidrigkeit i.S.d. § 138 BGB in jedem Fall ausgeschlossen werden kann.

1 BGH v. 18.3.2009 – XII ZR 200/06, NJW-RR 2009, 947: Zur Frage einer durch Individualabrede vereinbarten Endrenovierungsklausel in einem Mietvertrag über Gewerberäume. 2 BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383. 3 BGH v. 18.3.2009 – XII ZR 200/06, NJW-RR 2009, 947 zur Individualabrede über eine Endrenovierungsklausel in einem Gewerberaummievertrag: „Ihre Schranken findet die Wirksamkeit einer solchen Vereinbarung vor allem in den Verbotsgesetzen i.S.d. § 134 BGB, im Verbot der Sittenwidrigkeit (§ 138 BGB) und dem Grundsatz von Treu und Glauben (§ 242 BGB)“. Klarer: § 242 BGB kann der Durchsetzung des Anspruchs entgegenstehen. 4 BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383.

890

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 162 I

Ob und inwieweit das Entgelt für die Mängelbeseitigung als Teil der Soft- 159 wareanwenderleistung zuverlässig bei dem Entgelt für die Softwareüberlassung einkalkuliert wurde, ist hierbei nicht maßgebend1. Vielmehr handelt es sich insofern um ein Risiko der die Verpflichtung übernehmenden Partei, die – bei entsprechend höherem Entgelt für die Softwareüberlassung – etwa auch das Risiko zu tragen hätte, dass das vereinbarte Entgelt für die Softwareüberlassung im Laufe der Zeit erheblich von der Entwicklung des marktüblichen Überlassungsentgelts abweicht2. Dieses typische Vertragsrisiko trägt grundsätzlich die jeweils benachteiligte Vertragspartei3. bb) Mängelbeseitigungsentgelt als Schaden? Obwohl dem Softwareanwender das Recht verbleibt, beim Softwarekauf- 160 oder -werkvertrag Nacherfüllung, Schadens- oder Aufwendungsersatz zu verlangen, den Kaufpreis bzw. die Werkvergütung zu mindern oder vom Softwareüberlassungsvertrag zurückzutreten bzw. beim Softwaremietvertrag von seinem Mietminderungsrecht Gebrauch zu machen, Schadensoder Aufwendungsersatz zu verlangen bzw. zu kündigen, ist es ihm verwehrt, dem Softwareanbieter das gezahlte Entgelt für die Mängelbeseitigung als Schadensersatzposition entgegenzuhalten, wenn sich ein Mangel an der überlassenen Software realisiert hat. Hat der Softwareanwender die Verpflichtung zur Übernahme des Entgelts 161 für die Mängelbeseitigung rechtswirksam übernommen, ist ihm kein Schaden entstanden, denn auf der Grundlage der Differenzhypothese ist das Vermögen des Softwareanbieters von Anfang an mit dem Entgelt für die Mängelbeseitigung – sei es ein monatlich pauschales Entgelt oder ein Entgelt nach Aufwand bei Feststellung eines Mangels – belastet. Danach kann keine Differenz zweier Vermögenslagen vor oder nach dem schädigenden Ereignis bestehen. c) Verstoß gegen § 307 Abs. 2 BGB und das Transparenzgebot Werden AGB verwendet, wird überwiegend angenommen, dass die entgeltli- 162 che Vereinbarung über die Mängelbeseitigung aufgrund einer Softwarepflegevereinbarung während der Verjährungsfrist für Mängelansprüche aus der Softwareüberlassung bzw. während der Laufzeit einer mietvertraglichen Softwareüberlassung gegen das Tranzparenzgebot nach § 307 Abs. 1 Satz 2 BGB und außerdem gegen § 307 Abs. 2 BGB verstößt. Ein Verstoß gegen § 307 Abs. 2 BGB besteht, soweit die entgeltliche Vereinbarung über die Mängelbeseitigung mit dem gesetzlichen Leitbild des Softwareüberlas-

1 Zum Gewerberaummietvertrag: BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383. 2 Zum Gewerberaummietvertrag: BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383. 3 BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383.

Peter

891

I Rz. 163

Sonderregelungen

sungsvertrags nicht übereinstimmt, was beim Kauf-, Werk- und Mietvertrag der Fall ist1. 163

Außerdem kann im Abschluss des Softwarepflegevertrags zusätzlich zur Softwareüberlassung ein Anerkenntnis zu sehen sein, weshalb der Softwareanwender keine Mängelhaftungsansprüche aus dem Softwareüberlassungsvertrag geltend machen kann; vielmehr kann er die Fehlerbeseitigung aus dem Pflegevertrag erhalten2. Diese Lösung würde dem Softwareanwender aber dann nicht helfen, wenn der Softwarepflegevertrag tätigkeitsorientiert ausgestaltet ist, mithin im Rahmen der Softwarepflege keine Fehlerbeseitigung geschuldet wird3. Daher ist vorzuziehen, dass im Softwarepflegevertrag eine Fortsetzung der Mängelhaftung zu sehen ist: Entweder läuft die Mängelhaftung noch nicht oder diese wird an den Lauf des Pflegevertrags angehängt, so dass sich die Verjährungsfrist für Mängelansprüche um die Dauer des Pflegevertrags verlängert4.

164

Sodann ist insbesondere für den Anbieter der Softwarepflege zu beachten, dass die Verjährungsfrist aufgrund der Schuldrechtsmodernisierung auf mindestens ein Jahr ausgedehnt wurde (z.B. beim Werkvertrag § 634a i.V.m. § 309 Nr. 8b ff. BGB) und bislang völlig ungeklärt ist, wann die Verjährungsfrist beginnt – je nach Handhabung von § 651 BGB und der Einordnung bei § 634a Abs. 1 Nr. 1 oder Nr. 3 BGB (Rz. 33 ff.)5.

165

Letztlich werden unterschiedlichste Lösungsansätze vorgeschlagen, die eine Übereinstimmung mit den Normierungen des § 307 BGB möglich machen: – keine Pflegevergütung während des Laufs der Mängelhaftungsfrist; – anteilige Vergütung während des Laufs der Mängelhaftungsfrist; – pauschaler Abschlag, wobei wiederum die Höhe des Abschlags bzw. der anteiligen Vergütung heftig diskutiert wird6 und – Ausklammerung der Mängelbeseitigung7. d) Zwingend geschuldete Mängelbeseitigung

166

Eine andere Auffassung in der Literatur führt zur Problemlösung aus, dass der Anbieter für die Softwareüberlassung und -pflege die Mängelbeseitigung 1 Schneider, CR 2011, 626; Schneider, ITRB 2005, 191; Schneider, CR 2004, 241; Schneider, Handbuch des EDV-Rechts, K. Rz. 68 ff.; Intveen, ITRB 2004, 138; Runte, ITRB 2003, 253; Bischof/Witzel, ITRB 2003, 31; v. Baum, CR 2002, 705; Bartsch, NJW 2002, 1526; von Westerholt/Berger, CR 2002, 81. 2 Schneider, Handbuch des EDV-Rechts, K. Rz. 69. 3 Schneider, Handbuch des EDV-Rechts, K. Rz. 70. 4 Schneider, Handbuch des EDV-Rechts, K. Rz. 70 mit Verweis auf AG Mosbach, CR 1989, 1097. Dagegen Zahrnt, CR 2004, 408. 5 Schneider, Handbuch des EDV-Rechts, K. Rz. 261a; Schneider, ITRB 2005, 191. 6 Bartsch, NJW 2002, 1526; Bischof/Witzel, ITRB 2003, 31; Schneider, CR 2004, 241; Zahrnt, CR 2004, 408; Schneider, ITRB 2005, 191. 7 Aufzählung nach Runte, ITRB 2003, 253.

892

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 169 I

auf jeden Fall schuldet: Entweder aufgrund von Mängelhaftungsansprüchen aus dem Softwareüberlassungsvertrag oder aus der Softwarepflegeverpflichtung1. Dabei wird auf eine Entscheidung des OLG Hamm2 und auf eine Entscheidung des LG Stuttgart3 verwiesen, aus denen ein doppelt begründetes Pflegerecht herzuleiten sei, nämlich aus dem Pflegevertrag und aus Mängelhaftungsansprüchen4. Der Softwareanwender könne später das Pflegeentgelt kürzen oder die Zahlung verweigern, soweit solche Pflegearbeiten durchgeführt wurden, die unter die Mängelhaftung fallen5. e) Stellungnahme Wie bereits zuvor ausgeführt (Rz. 150 ff.), besteht die hier behandelte Pro- 167 blematik nicht nur dann, wenn der Softwareanbieter und der Anbieter der Pflegeleistungen personenidentisch sind, sondern ebenfalls im Drei-Personen-Verhältnis, nämlich im Fall der rechtlichen Einheit des Softwareüberlassungs- und des Softwarepflegevertrags (zur rechtlichen Einheit im Drei-Personen-Verhältnis s. Rz. 88 ff.). Besteht rechtliche Einheit im DreiPersonen-Verhältnis, dürften der Anbieter der Softwareüberlassung und der Anbieter der Softwarepflege als personenidentisch behandelt werden, weil die nur subjektive Aufteilung der Anbieterseite rein gekünstelt erscheint. aa) Entgeltlichkeit der Mängelbeseitigung als unangemessene Benachteiligung (1) Abwälzung der Mängelbeseitigungspflicht auf den Mieter als verschuldensunabhängige Haftung Ausgangspunkt der nachfolgenden Überlegungen ist, dass es unter gewissen 168 Umständen ausnahmsweise rechtlich möglich ist, eine auch formularmäßige Vereinbarung über die Abwälzung der Mängelbeseitigungs- bzw. Nacherfüllungspflicht auf den anderen Vertragspartner – sei es im Verbraucheroder im Unternehmensverkehr – wirksam herbeizuführen, obschon eine solche Vereinbarung mit dem gesetzlichen Leitbild des Vertrags nicht übereinstimmt. So dürfen z.B. im Wohnraummietrecht unter bestimmten weiteren Voraussetzungen die Kosten von Bagatellreparaturen auf den Mieter abgewälzt werden6. Im Zusammenhang mit der Abwälzung der Vermieterpflicht zur Erhaltung 169 der Mietsache (§ 535 Abs. 1 Satz 2 BGB) auf den Mieter hat der BGH – wie vorstehend unter Rz. 157 in anderem Zusammenhang ausgeführt – ent-

1 2 3 4 5 6

Marly, Praxishandbuch Softwarerecht, Rz. 1037. OLG Hamm v. 22.5.1986 – 4 U 190/84, CR 1988, 297. LG Stuttgart v. 26.11.1993 – 8 O 568/92, CR 1995, 223. Marly, Praxishandbuch Softwarerecht, Rz. 1036. Marly, Praxishandbuch Softwarerecht, Rz. 1037 f. mit weiteren Einzelheiten. Statt aller: Palandt/Weidenkaff, § 535 BGB Rz. 44.

Peter

893

I Rz. 170

Sonderregelungen

schieden, dass ein Gewerberaummieter durch Individualvereinbarung grundsätzlich weitgehend zu Reparaturen und Instandsetzungsarbeiten verpflichtet werden kann, auch wenn dies im Ergebnis zu einer verschuldensunabhängigen Haftung des Mieters führt1. 170

Insbesondere mit dem letzten Teil der Aussage hat der BGH möglicherweise – mit Blick auf die umstrittene Rechtsprechung der Obergerichte zur Frage der Zulässigkeit einer Abwälzung der Vermieterpflicht zu Reparaturen und Instandsetzungsarbeiten auf den Gewerberaummieter im Fall der Vereinbarung kraft AGB – einen deutlichen Hinweis zur Frage der Zulässigkeit einer derartigen AGB-Klausel geben wollen2. Die formularmäßige Begründung einer verschuldensunabhängigen Haftung zu Lasten des Vertragspartners des Verwenders stellt stets eine unangemessene Benachteiligung i.S.d. § 307 BGB dar. (2) Formularmäßige Begründung einer verschuldensunabhängigen Haftung als grundsätzlich unangemessene Benachteiligung

171

Im Zusammenhang mit der verschuldensunabhängigen Abwälzung des Missbrauchsrisikos auf den Karteninhaber (dort: einer Kundenkreditkare) hatte der BGH bereits eine entsprechende AGB-Klausel wegen Verstoßes gegen § 9 Abs. 2 Nr. 1 AGBG (jetzt § 307 Abs. 2 Nr. 1 BGB) für unwirksam erklärt3. Diese Entscheidung hat das Gericht damit begründet, dass eine Verpflichtung zum Schadensersatz regelmäßig nur bei schuldhaftem Verhalten besteht und dies ein wesentlicher Grundgedanke der gesetzlichen Regelung i.S.v. § 9 Abs. 2 Nr. 1 AGBG (nunmehr § 307 Abs. 2 Nr. 1 BGB) ist. Dieser allgemeine Grundsatz des Haftungsrechts gilt als Ausdruck des Gerechtigkeitsgebots gleichermaßen für vertragliche wie für gesetzliche Ansprüche. Dem steht nicht entgegen, dass der Gesetzgeber für einzelne, näher um1 BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383. 2 BGH v. 6.4.2005 – XII ZR 158/01, NJW 2006, 84 zur Unwirksamkeit einer AGBmäßigen Abwälzung von uferlosen Instandsetzung- und Instandhaltungspflichten auf den Gewerberaummieter: „Die zulässige Abweichung vom gesetzlichen Leitbild findet aber dort ihre Grenze, wo dem Mieter die Erhaltungslast von gemeinsam mit anderen Mietern genutzten Flächen und Anlagen ohne Beschränkung der Höhe nach auferlegt wird. Damit werden dem Mieter auch Kosten übertragen, die nicht durch seinen Mietgebrauch veranlasst sind und die nicht in seinen Risikobereich fallen. Ihm werden dadurch, dass er die gemeinschaftlich genutzten Flächen und Anlagen in dem bei Mietbeginn bestehenden, in der Regel gebrauchten Zustand vorfindet, die Kosten für die Behebung anfänglicher Mängel bzw. bereits vorhandener Abnutzungen durch Reparatur oder Erneuerung überbürdet, deren Höhe für ihn nicht überschaubar ist. Darüber hinaus werden ihm Kosten für Schäden auferlegt, die von Dritten verursacht worden sind, für deren Handeln er keine Verantwortung trägt, so dass auch insoweit ihm nicht zurechenbare und der Höhe nach nicht vorhersehbare Kosten auf ihn übertragen werden. Diese Abweichungen vom gesetzlichen Leitbild des Mietvertrags benachteiligen den Mieter unangemessen.“ 3 BGH v. 23.4.1991 – XI ZR 128/90, MDR 1991, 720 = NJW 1991, 1886.

894

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 173 I

schriebene Ausnahmetatbestände eine Gefährdungshaftung für geboten erachtet hat1. Die beanstandete Klausel weicht von diesem wesentlichen Grundgedanken des Haftungsrechts ab und widerspricht der Haftungsverteilung, wie sie sich ohne die Haftungsregelung aus den maßgebenden gesetzlichen Bestimmungen ergibt2. Die formularmäßige Begründung einer verschuldensunabhängigen Haftung ist grundsätzlich nach § 307 Abs. 2 Nr. 1 BGB unwirksam3. (3) Formularmäßige Verpflichtung zur Übernahme der Mängelbeseitigungskosten als verschuldensunabhängige Haftung Überträgt man die vorstehenden Gedanken des BGH auf die Verpflichtung 172 des Softwareanwenders, mit dem Softwarepflegevertrag die Mängelbeseitigungspflicht des Softwareanbieters aus dem Softwareüberlassungsvertrag zu bezahlen, so kommt dies ebenfalls einer verschuldensunabhängigen Haftung des Softwareanwenders gleich. Der Softwareanwender trägt die – anteiligen oder vollen – Kosten für die Beseitigung von Mängeln, auf deren Eintritt er keinerlei Einfluss hat. Er hat das Kostenrisiko zu tragen, obwohl er nichts gegen den Eintritt eines Mangels unternehmen kann und Mängel nicht verschuldet hat; auf sein Verhalten kommt es überhaupt nicht an. Diese Verpflichtung weicht daher von dem vorgenannten wesentlichen Grundgedanken des Haftungsrechts ab und stellt eine unangemessene Benachteiligung gemäß § 307 Abs. 2 Nr. 1 BGB dar. Denn nach den gesetzlichen Bestimmungen – sei es bzgl. Kauf-, Werk- oder Mietvertrag – haftet der Softwareanbieter für die Kosten der Mängelbeseitigung allein, wenn den Softwareanwender kein Verschulden an dem Eintritt des Mangels trifft; eine verschuldensunabhängige Haftung des Softwareanwenders ist in diesem Zusammenhang gesetzlich nicht vorgesehen4. (4) Ausgleich einer unangemessenen Benachteiligung Nach § 307 Abs. 2 Nr. 1 BGB ist bei Unvereinbarkeit einer AGB-Klausel 173 mit wesentlichen Grundgedanken der durch sie verdrängten gesetzlichen Regelung eine unangemessene Benachteiligung nur „im Zweifel“ anzunehmen5. Auch in den Fällen des § 307 Abs. 2 Nr. 1 BGB bleibt letztlich der Maßstab des § 307 Abs. 1 BGB führend, wonach AGB-Klauseln nur dann unwirksam sind, wenn sie den Vertragspartner des Verwenders „entgegen den Geboten von Treu und Glauben unangemessen benachteiligen“6. 1 BGH v. 23.4.1991 – XI ZR 128/90, MDR 1991, 720 = NJW 1991, 1886; BGH v. 25.6.1991 – XI ZR 257/90, MDR 1991, 859 = NJW 1991, 2414. 2 BGH v. 23.4.1991 – XI ZR 128/90, MDR 1991, 720 = NJW 1991, 1886. 3 BGH v. 25.6.1991 – XI ZR 257/90, MDR 1991, 859 = NJW 1991, 2414; BGH v. 6.10.1982 – VIII ZR 201/81, MDR 1983, 926 = NJW 1983, 159. 4 S. hierzu auch: Schneider, CR 2011, 626; Intveen, ITRB 2010, 90, 92; Intveen, ITRB 2005, 117, 119. 5 BGH v. 25.6.1991 – XI ZR 257/90, MDR 1991, 859 = NJW 1991, 2414. 6 BGH v. 25.6.1991 – XI ZR 257/90, MDR 1991, 859 = NJW 1991, 2414.

Peter

895

I Rz. 174 174

Sonderregelungen

Besondere Umstände können daher dazu führen, dass eine AGB-Klausel, die mit wesentlichen Grundgedanken der gesetzlichen Regelung, von der sie abweicht, nicht zu vereinbaren ist, gleichwohl keine unangemessene Benachteiligung i.S.v. § 307 Abs. 1 BGB enthält und daher wirksam ist. Das kann z.B. dann der Fall sein, wenn die den Vertragspartner benachteiligende Abweichung vom dispositiven Gesetzesrecht durch Gewährung anderer rechtlicher Vorteile ausgeglichen wird1 oder wenn sie durch höherrangige Interessen des AGB-Verwenders gerechtfertigt ist2. (5) Berücksichtigung des Mängelbeseitigungsentgeltes in der Kalkulation des Softwareüberlassungsentgeltes

175

Die Unangemessenheit der Benachteiligung könnte der Softwareanbieter möglicherweise durch Anrechnung des Mängelbeseitigungsentgelts in der Kalkulation für das Softwareüberlassungsentgelt ungeschehen machen. Damit würde dem Softwareanwender zwar kein „echter“ Preisnachlass gewährt, denn mit dem Entgelt für die Mängelbeseitigungskosten addiert verbleibt es beim Ursprungspreis für die Softwareüberlassung. Die kalkulatorische Berücksichtigung kommt jedoch insoweit einem tatsächlichen, wirtschaftlichen Vorteil für den Softwareanwender gleich, als ein Teil des Überlassungsentgelts mit dem Mängelbeseitigungsentgelt quasi ratenweise abbezahlt wird: Der Softwareanwender erhält dadurch praktisch einen Geldzinsvorteil durch Gewährung eines teilweisen Ratenzahlungskredits.

176

Somit lautet die entscheidende Frage in Bezug auf die „unangemessene Benachteiligung“ i.S.d. § 307 Abs. 1 BGB: Stellt dieser Geldzinsvorteil tatsächlich einen rechtlichen Vorteil gegenüber der Verpflichtung des Softwareanwenders dar, pauschales oder aufwandsabhängiges Entgelt für die Mängelbeseitigung kraft Softwarepflegevertrag zahlen zu müssen? (a) Pauschales Entgelt für die Softwarepflege (aa) Haftung für vom Anbieter oder Hersteller schuldhaft herbeigeführte Mängel

177

Das pauschale Entgelt ist der Höhe nach und für die Laufzeit des Softwarepflegevertrags festgeschrieben und lässt sich damit – bezogen auf einen bestimmten Zeitraum – von Anfang an berechnen. Der Anbieter muss den Anteil der Pflegepauschale für die Mängelbeseitigung beim Überlassungsentgelt kalkulatorisch berücksichtigen, um den Grundstein für einen Ausgleich der unangemessenen Benachteiligung zu legen. Der Anbieter ist mithin gezwungen, gegenüber dem Softwareanwender seine Kalkulation für die Pflegepauschale offenzulegen, was er aber in der Regel nicht tun wird3.

1 BGH v. 25.6.1991 – XI ZR 257/90, MDR 1991, 859 = NJW 1991, 2414; BGH v. 1.12.1981 – KZR 37/80, BGHZ 82, 238 = MDR 1982, 295. 2 BGH v. 23.4.1991 – XI ZR 128/90, MDR 1991, 720 = NJW 1991, 1886. 3 Zahrnt, CR 2004, 408.

896

Peter

Rz. 182 I

Softwarepflege inklusive Service-Level-Agreement

Selbst für den außergewöhnlichen Fall, dass der Anbieter seine Kalkulation 178 insoweit offen legt und das monatliche pauschale Entgelt für die Mängelbeseitigung konkret beziffert, müsste der Softwareanwender das pauschale Entgelt für die Mängelbeseitigung – unabhängig von seiner verschuldensunabhängigen Haftung – grundsätzlich auch dann bezahlen, wenn der Mangel vom Anbieter oder dem Softwarehersteller vorsätzlich oder fahrlässig herbeigeführt wird. Eine derartige Haftungsfreizeichnung – ist sie positiv im Formularvertrag formuliert – ist generell unzulässig1. Dies alleine lässt eine unangemessene Benachteiligung möglicherweise 179 noch nicht erkennen, denn der Softwareanwender kann sich in diesem Fall einredeweise gegen die Inanspruchnahme zur Zahlung des Mängelbeseitigungsentgeltes wehren. (bb) Ungleichbehandlung und unangemessene Benachteiligung Der Softwareanwender kann sich zwar gegen die Zahlung des Mängelbesei- 180 tigungsentgelts wehren, ebenso wie es bei einer wirksam ausgehandelten Individualvereinbarung in Betracht kommt. In beiden Fällen – Individualoder Formularvertrag – ist der Softwareanwender aber berechtigt, dem Anbieter die rechtsvernichtende2 Einrede des § 242 BGB (Rechtsmissbrauch) entgegenzusetzen; für diese Einrede trägt er auch die Beweislast3. Diesen Beweis zu führen, wird aber den Softwareanwender – selbst bei Vor- 181 liegen des Quellcodes – vor eine kaum zu überwindende Hürde stellen, weil er die Software weder selbst entwickelt noch hergestellt hat. Im Übrigen hilft ihm nicht die Beweiserleichterung des § 280 Abs. 1 Satz 2 BGB, wonach der Softwareanbieter dartun muss, dass er die Pflichtverletzung nicht zu vertreten hat, da der Softwareanwender sich nicht auf der Anspruchsseite, sondern auf der Einredeseite bewegt. Bei einer Individualvereinbarung kann – und das ist wichtig – im Gegensatz 182 zu einem Formularvertrag in der Regel davon ausgegangen werden, dass beide Vertragsparteien bei den Vertragsverhandlungen in der Lage waren, ihre Interessen ausreichend zu wahren4, mithin das vorstehende Beweislastrisiko angemessen zu berücksichtigen. Das ist bei einem nur formularmäßig abgeschlossenen Vertrag gerade nicht der Fall, so dass dem Risiko der Beweislast mangels individueller Vereinbarung kein anerkennenswerter Vorteil gegenübergestellt werden kann.

1 2 3 4

BGH v. 14.11.2000 – X ZR 211/98, NJW-RR 2001, 342. Palandt/Grüneberg, § 242 BGB Rz. 41. Zöller/Greger, Vor § 284 ZPO Rz. 17a. BGH v. 5.6.2002 – XII ZR 220/99, MDR 2002, 1304 = NJW 2002, 2383.

Peter

897

I Rz. 183

Sonderregelungen

(cc) Unzulässige Abwälzung des Beweislastrisikos auf den Softwareanwender 183

Damit wird eines deutlich: Tatsächlich wird dem Softwareanwender überhaupt kein nennenswerter Vorteil gewährt.

184

Zwar erhält er mit der Vereinbarung über das Mängelbeseitigungsentgelt bei gleichzeitiger Anrechnung dieses Entgelts in die Kalkulation des Überlassungsentgelts einen Geldzinsvorteil durch Gewährung eines teilweisen Ratenzahlungskredits.

185

Aus dem Blickwinkel des Überlassungsvertrags1 verlagert der Softwareanbieter aber aufgrund der Vereinbarung über das Mängelbeseitigungsentgelt in Bezug auf die Geltendmachung von Mängelhaftungsansprüchen – und das ist das Schwerwiegende – das Risiko der Beweislast für den Nachweis eines schuldhaft verursachten Mangels auf den Softwareanwender. Dieser kann sich – wie vorstehend unter Rz. 180 ausgeführt – gegen die Verpflichtung, das Mängelbeseitigungsentgelt für vom Anbieter oder dem Hersteller schuldhaft verursachte Mängel zu zahlen, einredeweise, aber beweisbelastet, mithilfe des § 242 BGB (Rechtsmissbrauch) wehren.

186

Bestünde keine Vereinbarung zum Mängelbeseitigungsentgelt im Softwarepflegevertrag, müsste bei Vorliegen eines Mangels und eines deswegen geltend gemachten Schadensersatzanspruchs der Softwareanbieter allein und im Rahmen der Softwareüberlassung beweisbelastet dartun, dass er den Mangel nicht zu vertreten hat, § 280 Abs. 1 Satz 2 BGB.

187

Eine formularmäßige Abwälzung des Beweislastrisikos auf den Vertragspartner des Verwenders ist jedoch im Verbraucherverkehr nach § 309 Nr. 12a) BGB und selbst im Unternehmensverkehr2 unwirksam.

188

Damit wird deutlich, dass die Verpflichtung des Softwareanwenders im Softwarepflegevertrag, die Mängelbeseitigungskosten während der Mängelhaftungsfrist bzw. währende der Laufzeit der mietweisen Softwareüberlassung zu tragen, ihn gemäß § 307 Abs. 1 Satz 1 BGB entgegen dem Gebot von Treu und Glauben insgesamt unangemessen benachteiligt. (b) Aufwandsabhängiges Entgelt für die Mängelbeseitigung

189

Zu dem vorstehend unter Rz. 183 ff. Dargestellten tritt folgender Umstand hinzu: Es ist für den Softwareanwender zum Zeitpunkt des Abschlusses des Softwareüberlassungsvertrags in keiner Weise absehbar, ob die Höhe des einkalkulierten Nachlasses auf das Überlassungsentgelt den tatsächlich von ihm später aufzubringenden Entgelten für die Mängelbeseitigung ent1 Schneider, CR 2011, 626 zur möglichen Unwirksamkeit insbesondere formularmäßig vereinbarter Entgeltpflichtigkeit von Softwarepflegeleistungen unter Berücksichtigung der Nacherfüllungspflicht aus dem Blickwinkel des Softwareüberlassungsvertrages. 2 Palandt/Grüneberg, § 307 BGB Rz. 40 und § 309 BGB Rz. 107.

898

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 193 I

spricht. Der Softwareanwender kann Glück haben, dass der Softwareanbieter Mängel möglichst schnell beseitigt oder Mängel gar nicht oder nur in geringem Umfang auftreten. Dies hilft aber nicht, die Unangemessenheit der aufwandsabhängigen Kostentragungspflicht des Softwareanwenders für die Mängelbeseitigung auszugleichen. Denn die Höhe des aufwandsabhängigen Entgelts für die Mängelbeseitigung ist bei Abschluss des Formularvertrags über Softwarepflege völlig ungewiss. (c) Haftung nach Gefahrbereichen (Sphärenhaftung) Der Gedanke der Haftung nach Gefahrbereichen beruht auf der Erwägung, 190 dass auf einen Vertragsteil (hier den Softwareanwender) die Risiken abgewälzt werden dürfen, die ihre Ursache ausschließlich in seiner Sphäre haben und vom anderen Vertragsteil (hier dem Softwareanbieter) nicht beherrscht werden können1. Dieser Grundsatz hilft dem Softwareanbieter nicht; vielmehr bestätigt er – im Umkehrschluss – das hier dargelegte Ergebnis: Der Softwareanwender hat die Software weder selbst entwickelt noch hergestellt; allenfalls kann der Softwareanbieter die Gefahr eines drohenden Mangels beherrschen, nicht jedoch der Softwareanwender. Dann darf auf diesen das Kostenrisiko für die Mängelbeseitigung nicht abgewälzt werden. Einzig in dem Fall, in dem der Softwareanbieter dem Softwareanwender 191 auch den Quellcode übergibt und der Softwareanwender selbst in den Quellcode eingreift, um Änderungen oder Ergänzungen der Software vorzunehmen, erscheint es unter dem Gesichtspunkt der Sphärenhaftung gerechtfertigt, dem Softwareanwender ein Mängelbeseitigungsentgelt formularmäßig aufzuerlegen; jedoch nur für diejenigen Mängel, die der Softwareanwender selbst verursacht hat. bb) Keine fehlerfreie Software Vorliegend geht es einzig um die Frage des vom Gesetzgeber verteilten Haftungs- und Beweislastrisikos für die Kosten der Mängelbeseitigung während des Laufs der Mängelhaftungsfrist bzw. während der Wirksamkeit einer mietweisen Softwareüberlassung. Dieses Risiko hat bei Verwendung von AGB der Softwareanbieter allein zu tragen.

192

cc) Entgeltlichkeit der Mängelbeseitigung als Verstoß gegen § 309 Nr. 2 BGB Ist die überlassene Software mangelhaft, kann der Softwareanwender alle 193 Rechte aus und im Zusammenhang mit der Softwareüberlassung geltend machen: Insbesondere kann er grundsätzlich das Überlassungsentgelt zurückbehalten, § 320 BGB. Er bleibt hingegen nach dem Wortlaut des Soft1 BGH v. 25.6.1991 – XI ZR 257/90, MDR 1991, 859 = NJW 1991, 2414; BGH v. 23.4.1991 – XI ZR 128/90, MDR 1991, 720 = NJW 1991, 1886.

Peter

899

I Rz. 194

Sonderregelungen

warepflegevertrags verpflichtet, das Entgelt für die Mängelbeseitigung aus der Pflege zu bezahlen, was für den Softwareanwender auf den ersten Blick insbesondere dann opportun erscheint, wenn die Anbieter der Softwareüberlassung und der Softwarepflege verschiedene Rechtspersonen sind. 194

Liegt jedoch rechtliche Einheit – sogar im Drei-Personen-Verhältnis – vor, dürfte die Einrede des § 320 BGB ebenfalls das Entgelt für die Mängelbeseitigung aus dem Softwarepflegevertrag erfassen (zum Einwendungsdurchgriff s. Rz. 128 ff.). Im Zwei-Personen-Verhältnis führt möglicherweise schon allein der Weg über § 273 BGB zum Ziel, falls hier § 320 BGB dem § 273 BGB nicht generell vorgeht.

195

Sollten die vorgenannten Einreden in Betracht kommen, jedoch wegen des Arguments nicht durchgreifen, weil sich der Softwareanwender im Rahmen der Softwarepflege immerhin freiwillig der Entgeltpflicht für die Mängelbeseitigung unterworfen hat (§ 242 BGB), könnte die formularmäßige Begründung einer Entgeltpflicht für die Mängelbeseitigung einen Verstoß gegen § 309 Nr. 2a) BGB darstellen. Dieser Ansatz kommt aber nur im Verbraucherverkehr zum Tragen, denn formularmäßige Einschränkungen der Leistungsverweigerungsrechte nach § 273 oder § 320 BGB sind im kaufmännischen Verkehr grundsätzlich wirksam1. f) Praktische Erwägungen aa) Vergütung der Mängelbeseitigung

196

Die Tatsache, dass der Softwareanbieter für die Softwarepflege ein Entgelt verlangt, welches er für die Mängelbeseitigung einsetzt, ist an sich nicht verwerflich, sondern vielmehr eine Frage der Kalkulation eines sorgfältigen Kaufmanns (Rz. 9). Die Notwendigkeit der Kalkulation derartiger Kosten erhöht sich, je komplexer die Software ist, wegen ansteigender Fehleranfälligkeit (Rz. 2). Die Anbieterseite ist also wirtschaftlich gezwungen, Entgelte für die Mängelbeseitigung zu kalkulieren2. bb) Mängelbeseitigung nach Ablauf der Mängelhaftungsfrist

197

Da die Anwenderseite von den vorgenannten Umständen der Fehleranfälligkeit weiß, ist die Aufrechterhaltung einer funktionierenden Betriebsorganisation des Softwareanbieters, die die schnellstmögliche Mängelbeseitigung garantiert, für sie wichtig. Daher wünscht die Anwenderseite die Mängelbeseitigung ggf. auch nach Ablauf der Mängelhaftungsfrist aus dem Softwareüberlassungsvertrag. Dazu muss die Softwarepflegevereinbarung eine entsprechende Vereinbarung ausweisen, die rechtswirksam gestaltet werden kann. Wenn und soweit der Softwareanwender während des Laufs der 1 Palandt/Grüneberg, § 309 BGB Rz. 16 mit Verweis auf BGHZ 115, 327. 2 Zur Abgrenzung der vereinbarten Pflegevergütung in Bezug auf die mit dem Softwarepflegevertrag vereinbarten Leistungsteile s. Schneider, CR 2011, 626; Intveen, ITRB 2005, 117.

900

Peter

Rz. 200 I

Softwarepflege inklusive Service-Level-Agreement

Mängelhaftungsfrist Leistungen wünscht, die die Verpflichtungen des Softwareanbieters zum Mängelhaftungsrecht der einzelnen Vertragstypen verschärft, so können diese unzweifelhaft in AGB der Softwareanbieter vereinbart und gesondert vergütet werden. cc) Risiko der AGB-rechtlichen Unwirksamkeit bei entgeltlicher Mängelbeseitigung vor Ablauf der Mängelhaftungsfrist Sollte sich der Softwareanbieter unter dem Dach von AGB die Mängelbeseiti- 198 gung während der Mängelhaftungsfrist aufgrund des Softwarepflegevertrags explizit vergüten lassen wollen, obwohl dies zu einer verschuldensunabhängigen Haftung des Softwareanwenders führt, weicht der Softwareanbieter vom gesetzlichen Leitbild ab, was zur unangemessenen Benachteiligung führt. Seine Pflegevereinbarung ist – was diesen Punkt betrifft – von Anfang an unwirksam, § 307 Abs. 1 Satz 1 BGB (Rz. 167 ff.). dd) Risiko der steuerlichen Haftung bei Vereinbarung über die Unentgeltlichkeit der Mängelbeseitigung Falls der Softwareanbieter die Mängelbeseitigung während der Mängelhaf- 199 tungsfrist oder während der Vertragslaufzeit einer mietvertraglichen Softwareüberlassung im Pflegevertrag als gesonderte Leistung ausdrücklich und unentgeltlich per Individualvereinbarung verspricht, läuft hingegen der Softwareanwender Gefahr, dass das Finanzamt das Versprechen des Softwareanbieters – neben seiner Verpflichtung zur Mängelbeseitigung aus der Softwareüberlassung – als zusätzliches Schenkungsversprechen auffasst und den Wert dieser Leistungen – soweit diese vom Softwareanbieter erbracht wurden (§ 518 Abs. 2 BGB) – als Grundlage für einen Schenkungssteuerbescheid zu Lasten des Softwareanwenders betrachtet. Denn das Finanzamt könnte argumentieren, dass die Mängelbeseitigung bereits mit dem Überlassungsentgelt vergütet ist und der zusätzliche Schuldgrund im Softwarepflegevertrag schenkweise erfolgt. Dem dürfte jedoch mit Erfolg entgegengehalten werden können, dass die – angebliche – schenkweise Einräumung eines zusätzlichen Mängelbeseitigungsanspruchs lediglich rein deklaratorischer Natur ist und inhaltlich keine zusätzliche Vermögensbereicherung auf Seiten des Softwareanwenders erfolgt. Vor Abschluss einer solchen Vereinbarung sollte der Softwareanwender das für ihn zuständige Finanzamt um Stellungnahme bitten. g) Fazit Der Softwareanwender will unentgeltliche Mängelbeseitigung während der 200 Mängelhaftung erreichen. Diese bekommt er aus dem Überlassungsvertrag während des Laufs der Mängelhaftungsfrist oder beim Mietvertrag während der Laufzeit desselben.

Peter

901

I Rz. 201

Sonderregelungen

201

Der Softwareanbieter will während der Mängelhaftungsfrist oder während der Mietzeit im Rahmen der Softwarepflege Mängelbeseitigung anbieten. Dies braucht er nicht, wenn er Mängelbeseitigung schon aus der Softwareüberlassung verschuldet.

202

Die Vergütung für die Mängelbeseitigung muss der Softwareanbieter z.B. über das Überlassungsentgelt kalkulieren oder er muss mit dem Softwareanwender eine rechtswirksame Individualvereinbarung zur Softwarepflege abschließen, will er die Mängelbeseitigung bereits während der Frist der Mängelhaftung explizit vergütet erhalten1. 2. Preisanpassung

203

Bei Softwarepflegeverträgen, die typischerweise als Dauerschuldverhältnisse ausgestaltet sind (vgl. Rz. 461), wollen sich Softwareanbieter im Rahmen der Gestaltung ihrer AGB oftmals ausbedingen, einseitige Preisanpassungen gegenüber ihren Vertragspartnern durchsetzen zu können, ohne ein vertragliches Änderungsverfahren durchführen zu müssen. Zu den Ergebnissen eines vertraglichen Änderungsverfahrens muss der Softwareanwender hingegen seine Zustimmung erteilen.

204

Dementsprechend enthält die BVB-Pflege in § 5 Ziff. 3. und 4. sowie die EVB-IT Pflege S in Ziff. 6.3 einseitige Preisanpassungsregelungen unter den Stichwörtern „Preisvorbehalt“ (BVB-Pflege) bzw. „Vergütungsvorbehalt“ (EVB-IT Pflege S).

205

Die EVB-IT Pflege S sieht als Wirksamkeitsvoraussetzung für eine Preisanpassung u.a. vor, dass der Auftragnehmer (Softwareanbieter) die Vergütung als allgemeinen Listenpreis vorsieht und diese Vergütung ebenso von anderen Auftraggebern (Softwareanwendern) erzielt. Auch die BVB-Pflege verweist in § 5 Ziff. 3. b) auf einen nachgewiesenen Listenpreis. Darüber hinaus sieht die BVB-Pflege Preiserhöhungsmöglichkeiten aufgrund von Tarifänderungen (§ 5 Ziff. 3. a)) und für sonstige Leistungen aufgrund einer Erhöhung der der Vergütung zugrunde liegenden Vergütungssätze vor (§ 5 Ziff. 3. c)) sowie Preisanpassungen im Fall von Änderungen der Umsatzsteuer (§ 5 Ziff. 4.).

206

Es ist fraglich, ob diese Bestimmungen der EVB-IT Pflege S und der BVBPflege, werden sie als AGB vom Softwareanbieter verwendet, nach dem AGB-Recht wirksam sind (s. hierzu nachstehend Rz. 224 ff.). a) Grundsätzliches

207

Eines sei bezüglich einseitiger und nachträglicher Preisanpassungsgesuche einer Vertragspartei klarstellend vorangestellt: Es gilt der Grundsatz der 1 Der Vergütungsanspruch für das Pflegeentgelt verjährt in drei Jahren (§ 195 BGB), LG Konstanz v. 12.5.2010 – 2 O 240/09 B, juris.

902

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 211 I

Vertragstreue „pacta sunt servanda“ – Verträge sind einzuhalten. Die gesetzlich vorgesehene Ausnahme hierzu ist in § 313 BGB als Ausformung des Gedankens von Treu und Glauben (§ 157, § 242 BGB) postuliert1. Bei Wegfall der Geschäftsgrundlage soll eine Vertragspartei unter den dort festgelegten Voraussetzungen berechtigt sein, den geschlossenen Vertrag anpassen zu dürfen; selbst eine Beendigung des Vertrags (Rücktritt bzw. Kündigung) stellt § 313 Abs. 3 BGB als ultima ratio zur Verfügung. Jedoch ist anerkannt, dass bei langfristigen Verträgen eine solche, unabän- 208 derliche Entgeltvereinbarung für die leistungserbringende Vertragspartei nicht interessengerecht sein kann und es der anderen Vertragspartei „ausnahmsweise“ zuzumuten ist, eine angemessene Anpassung des Entgelts hinnehmen zu müssen, um einen Wertausgleich für zwischenzeitlich eingetretene Kostensteigerungen zu erhalten2, ohne den schwierigen und regelmäßig erfolglosen Weg über § 313 BGB gehen zu müssen. Eine Preisanpassung über § 313 BGB zu erreichen, ist nur ganz ausnahmsweise und nur in sehr seltenen Extremfällen möglich3. Zur ergänzenden Vertragsauslegung s. nachfolgend Rz. 265. Bei der rechtlichen Bewertung einer Preisanpassung wird der in den §§ 157, 242 BGB enthaltene und das gesamte Rechtsleben beherrschende Grundsatz, dass jedermann in Ausübung seiner Rechte und Erfüllung seiner Pflichten nach Treu und Glauben zu handeln hat4, nicht aufgegeben. Insbesondere bleibt das in § 241 Abs. 2 BGB festgeschriebene Rücksichtnahmegebot unangetastet, wonach vor allem die Rechte und die sonstigen Rechtsgüter der Gegenpartei zu schützen sind5.

209

Aus alledem wird aber das bestehende Konfliktpotential in Bezug auf län- 210 gerfristige Softwarepflegeverträge deutlich. Der Softwareanwender möchte vor Preisanpassungen geschützt werden, die über die ursprünglich festgelegten gegenseitigen Vereinbarungen hinausgehen. Der Softwareanbieter hat dagegen das ebenfalls anerkennenswerte Interesse, seine Entgelte den aktuellen Kosten- oder Preisentwicklungen anzupassen. Beide Vertragsparteien sind mithin darauf aus, das vereinbarte Äquivalenzverhältnis, also das Gleichgewicht zwischen Leistung und Gegenleistung, zu wahren. Der BGH führt zu den berechtigten Interessen beider Vertragspartner in Be- 211 zug auf Preisanpassungsregelungen aus: „Denn sie (die Preisanpassungsklauseln; Anm. Verf.) dienen dazu, einerseits dem Verwender das Risiko langfristiger Kalkulation abzunehmen und ihm seine Gewinnspanne trotz nachträglicher ihn belastender Kostensteigerungen zu sichern, und anderer1 Palandt/Grüneberg, § 313 BGB Rz. 1. 2 BGH vom 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789. S. z.B. für das Mietrecht §§ 557 ff. BGB. S. auch das Gesetz über das Verbot der Verwendung von Preisklauseln bei der Bestimmung von Geldschulden v. 7.9.2007 (PrKlG). 3 Palandt/Grüneberg, § 313 BGB Rz. 26 ff. mit Beispielen. 4 Palandt/Grüneberg, § 242 BGB Rz. 1. 5 Palandt/Grüneberg, § 241 BGB Rz. 6.

Peter

903

I Rz. 212

Sonderregelungen

seits den Vertragspartner davor zu bewahren, dass der Verwender mögliche künftige Kostenerhöhungen vorsorglich schon bei Vertragsschluss durch Risikozuschläge aufzufangen versucht.“1 b) Preisklauselgesetz 212

Das Preisklauselgesetz vom 7.9.2007 (PrKlG), welches das Preisangaben- und Preisklauselgesetz (inklusive der auf diesem Gesetz erlassenen Preisklauselverordnung) abgelöst hat, verbietet die Verwendung von bestimmten Preisklauseln bei der Bestimmung von Geldschulden, womit die Vertragsfreiheit der Vertragsparteien (Privatautonomie) eingeschränkt ist. Außerdem entfällt der bis dahin geltende bürokratische Aufwand für genehmigungspflichtige Preisklauseln nach dem alten Preisangaben- und Preisklauselgesetz. Mit Inkrafttreten des PrKlG haben die Betroffenen selbst zu prüfen, ob die vereinbarten Preisklauseln, die vom Gesetz erfasst werden, rechtmäßig sind; eine Einzelfallgenehmigung durch das Bundesamt für Wirtschaft ist nicht mehr erforderlich2.

213

In der Begründung des Bundestags zu § 1 PrKlG wird ausgeführt: „Preisklauseln, auch Wertsicherungs- oder Indexklauseln genannt, koppeln die Höhe einer Geldschuld an die Preis- oder Wertentwicklung anderer Güter oder Leistungen (Indexierung). Bei einer unbeschränkten Verwendung können sie inflationäre Tendenzen fördern. Der Gesetzgeber hat daher die Vereinbarung von unmittelbar und selbsttätig, d.h. automatisch wirkenden Preisklauseln unter bestimmten Ausnahmen untersagt und damit die Vertragsfreiheit eingeschränkt. … Aus stabilitäts-, preis- und verbraucherpolitischen Gründen besteht ein Interesse daran, auch künftig auf Grenzen für eine Indexierung nicht zu verzichten. Nach Ansicht der Europäischen Zentralbank (EZB) ist einerseits der Wunsch nach Vertragsfreiheit und Absicherung der Wirtschaftsakteure gegen Inflationsrisiken zu sehen. Andererseits gibt die EZB ‚zu bedenken, dass eine starke Nutzung der Indexklausel sehr kritisch zu sehen wäre, da eine umfassende Lohn- und Preisindexierung übermäßige Rigiditäten im relativen Preissystem hervorrufen und eine Inflationsspirale in Gang setzen könnte‘ (EZB-Jahresbericht 2004, S. 113; CON/2004/20). Das bisher geltende Indexierungsverbot wird daher beibehalten. § 1 Abs. 1 PrKlG entspricht dem bisher in § 2 Abs. 1 Satz 1 des Preisangaben- und Preisklauselgesetzes geregelten Verbot.“3

214

Das in § 1 Abs. 1 PrKlG manifestierte Verbot lautet daher: „Der Betrag von Geldschulden darf nicht unmittelbar und selbsttätig durch den Preis oder Wert von anderen Gütern oder Leistungen bestimmt werden, die mit den vereinbarten Gütern oder Leistungen nicht vergleichbar sind.“ 1 BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789. 2 BT-Drucks. 16/4391 v. 27.2.2007, S. 26 f., S. 20: Im Jahr 2005 waren es 17 000 Einzelfall-Genehmigungsverfahren. 3 BT-Drucks. 16/4391 v. 27.2.2007, S. 27; Hilber, BB 2011, 2691, der keinen Verweis auf die EZB-Bedenken macht.

904

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 221 I

§§ 2 bis 7 PrKlG regeln Ausnahmen zu diesem Verbot. Preisanpassungs- 215 klauseln, die vom Verbot nach den §§ 2 bis 7 des PrKlG ausgenommen sind, müssen aber hinreichend bestimmt sein und dürfen keine unangemessene Benachteiligung enthalten, § 2 PrKlG. § 1 Abs. 2 PrKlG stellt klar, welche Preisklauseln vom Verbot des Abs. 1 nicht erfasst sind; dies sind Preisanpassungsklauseln,

216

1. die hinsichtlich des Ausmaßes der Änderung des geschuldeten Betrags einen Ermessensspielraum lassen, der es ermöglicht, die neue Höhe der Geldschuld nach Billigkeitsgrundsätzen zu bestimmen (Leistungsvorbehaltsklauseln), 2. bei denen die in ein Verhältnis zueinander gesetzten Güter oder Leistungen im Wesentlichen gleichartig oder zumindest vergleichbar sind (Spannungsklauseln), 3. nach denen der geschuldete Betrag insoweit von der Entwicklung der Preise oder Werte für Güter oder Leistungen abhängig gemacht wird, als diese die Selbstkosten des Gläubigers bei der Erbringung der Gegenleistung unmittelbar beeinflussen (Kostenelementeklauseln), 4. die lediglich zu einer Ermäßigung der Geldschuld führen können. Für eine Kommentierung des Preisklauselgesetzes ist hier kein Raum und 217 es ist daher auf die einschlägige Kommentierung zu verweisen. Abschließend ist herauszustellen, dass, selbst wenn eine Preisanpassungsklausel mit dem PrKlG übereinstimmt, dies nicht deren Inhaltskontrolle nach den § 307 BGB oder § 309 Nr. 1 BGB hindert1.

218

Damit ist ebenfalls klar, dass alle Preisanpassungsklauseln, die gemäß § 1 219 Abs. 2 PrKlG vom Verbot des PrKlG nicht erfasst sind, z.B. eine mathematisch ausgebildete Preisanpassungsklausel als Kostenelementeklausel2, selbstverständlich der Inhaltskontrolle nach dem AGB-Recht unterfallen, wenn diese formularmäßig vorgelegt und als AGB verwendet werden (s. hierzu Rz. 224 ff.). Auch für die gemäß dem PrKlG zulässigen Preisanpassungsklauseln bedeu- 220 tet dies: Selbst wenn eine Preisanpassungsklausel nach dem PrKlG wirksam ist, führt dies nicht zu einer automatischen Wirksamkeit nach dem AGBRecht. Wird die Klausel formularmäßig in AGB vom Softwareanbieter verwendet, ist sie immer zusätzlich an den Wirksamkeitskriterien des AGBRechtes zu messen (s. Rz. 224 ff.). Die durchzuführende Inhaltskontrolle nach dem AGB-Recht gilt letztlich ebenso im Fall einer nach dem PrKlG unwirksamen Preisanpassungsklau1 H.M. in Rechtsprechung und Literatur: BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789; statt aller: Palandt/Grüneberg, § 309 BGB Rz. 3. Dies spricht Hilber, BB 2011, 2691 (2693) im Zusammenhang mit seinen Ausführungen zum Verhältnis des PrKlG zum AGB-Recht nicht an. 2 Beispiele bei Hilbert, BB 2011, 2691.

Peter

905

221

I Rz. 222

Sonderregelungen

sel. Denn eine nach dem PrKlG unzulässige Preisanpassungklausel wird erst zum Zeitpunkt des rechtskräftig festgestellten Verstoßes gegen das Gesetz mit Wirkung für die Zukunft unwirksam, soweit die Vertragsparteien nicht einen früheren Zeitpunkt vereinbart haben, § 8 Satz 1 PrKlG1. 222

Jedoch bestimmt § 8 Satz 2 PrKlG, dass Zahlungen, Forderungen oder andere Rechtswirkungen auf der Basis der vereinbarten Preisanpassungsklausel bis zum Zeitpunkt der Unwirksamkeit weiterhin Bestand haben und von der festgestellten Unwirksamkeit unangetastet bleiben2.

223

Daher ist eine formularmäßig verwendete Klausel, die für den Fall der Unwirksamkeit einer Preisanpassungsklausel nach dem PrKlG z.B. bestimmt, dass das erreichte Preisniveau auch nach rechtskräftiger Feststellung der Unwirksamkeit vorübergehend weiter gilt, der Inhaltskontrolle nach dem AGB-Recht unterworfen und nicht automatisch wirksam3. Eine solche Klausel dürfte im Übrigen der Inhaltskontrolle nicht standhalten, da diese nicht auf den vereinbarten Preis referenziert. Vielmehr führt diese Klausel selbst eine Preisanpassung ein, und zwar durch die Bezugnahme auf das zwischenzeitlich „erreichte“ Preisniveau, ohne die von der Rechtsprechung geforderten Angemessenheitskriterien für eine wirksame Preisanpassung – sei es im Verbraucher-, oder sei es im Unternehmensverkehr – zu berücksichtigen (s. Rz. 233 ff.). c) AGB

224

Schwierig ist es, das beschriebene Konfliktpotential (s. Rz. 210) im Rahmen von AGB rechtswirksam abzubilden.

225

Zunächst ist immer zu prüfen, ob eine formularmäßige Preisanpassungsklausel, unabhängig davon, wie diese formuliert ist, unbeachtlich ist, weil die Vertragsparteien ein festes Entgelt für die Laufzeit des Softwarepflegevertrags individuell ausgehandelt hatten (§ 305b BGB)4.

226

Ist die formularmäßige Preisanpassungsklausel hingegen anzuwenden, fragt sich, welcher Prüfungsmaßstab heranzuziehen ist. Da es sich bei dem Softwarepflegevertrag um ein Dauerschuldverhältnis handelt, findet § 309 Nr. 1 BGB keine Anwendung. Prüfungsmaßstab für formularmäßige Preisanpassungsklauseln in Softwarepflegeverträgen ist vielmehr § 307 BGB5.

1 2 3 4

BT-Drucks. 16/4391 v. 27.2.2007, S. 29. BT-Drucks. 16/4391 v. 27.2.2007, S. 29. A.A. wohl Hilber, BB 2011, 2691 (2693). Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 3 ff. 5 Palandt/Grüneberg, § 309 BGB Rz. 8 mit Verweis auf BGH-Rechtsprechung.

906

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 231 I

Formularmäßige Preisbestimmungen, so der BGH, die lediglich die zu erbringende Vergütung bestimmen, sind jedoch von der Inhaltskontrolle ausgenommen, § 307 Abs. 3 BGB1.

227

Der BGH führt hierzu aus, dass die Festlegung der Vergütung grundsätzlich 228 Sache der Vertragsparteien ist. Auch gebe es oftmals keine gesetzliche Bestimmung, die bei Unwirksamkeit der vertraglichen Abrede an deren Stelle treten könnte, um den Preis zu ermitteln. Dies gelte ebenso für Klauseln, die lediglich preisbildende Faktoren und das bei der Entgeltermittlung einzuhaltende Verfahren festlegten2. Solange diese vertraglichen Abreden nur das geschuldete Entgelt festlegen, sind diese Klauseln der Inhaltskontrolle entzogen3. Hiervon sind jedoch nach der Rechtsprechung des BGH zum einen diejeni- 229 gen Klauseln zu unterscheiden, an deren Stelle dispositives Gesetzesrecht zur Festlegung der Vergütung treten kann, wenn eine wirksame vertragliche Regelung zur Festlegung der Vergütung fehlt (s. z.B. § 632 BGB), und zum anderen Klauseln, die die einmal vereinbarte Vergütung – egal auf welche Art und Weise, z.B. mathematisch ausgebildet4 oder durch einseitige Bestimmung des Verwenders formuliert – (nachträglich) modifizieren. Diese unterliegen der vollen Inhaltskontrolle (§§ 307 Abs. 1, 309 Nr. 1 BGB)5. Weil beide Vertragsparteien in Bezug auf etwaige Preisanpassungen berech- 230 tigte Interessen verfolgen (s. Rz. 210), kann die Inhaltskontrolle, so der BGH weiter, nicht ohne Berücksichtigung der Art des konkreten Vertrags, der typischen Interessen der Vertragschließenden und der die jeweilige Klausel begleitenden Regelung getroffen werden6. Dies ist auch auf Softwarepflegeverträge anzuwenden. Bei den Preisanpassungsklauseln dürfte im Wesentlichen zwischen den sog. 231 Kostenelementeklauseln (also Preisanpassungen auf Grund von Kostenerhöhungen) und sog. Preisvorbehaltsklauseln (im PrKlG „Leistungsvorbehaltsklauseln“ genannt) zu unterscheiden sein; bei Letzteren wird dem Softwareanbieter (Auftragnehmer) regelmäßig ein einseitiges Leistungsbestimmungsrecht (§ 315 BGB) eingeräumt7. Daneben finden sich – entsprechend § 1 Abs. 2 Nr. 2 PrKlG – sog. Spannungsklauseln, die unabhängig von 1 2 3 4 5

BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789. BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789. Intveen, ITRB 2005, 117. Beispiele s. bei Hilber, BB 2011, 2691. BGH vom 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789: Denn sie weichen von dem – das dispositive Recht beherrschenden – Grundsatz ab, nach dem die Preisvereinbarung der Parteien bei Vertragsschluss für die gesamte Vertragsdauer bindend ist. 6 BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789. 7 Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 57 ff. Zu Preisindexregelungen beim Softwarepflegevertrag nach dem Preisklauselgesetz s. Intveen, ITRB 2010, 90 (92).

Peter

907

I Rz. 232

Sonderregelungen

der Kostenentwicklung die Erhaltung einer bestimmten Wertrelation zwischen Leistung und Gegenleistung bezwecken1. aa) Kostenelementeklauseln 232

Es dürfte aufgrund neuerer Entscheidungen des BGH2 eine Herausforderung darstellen, im Verbraucher- wie auch im Unternehmensverkehr rechtwirksame Kostenelementeklauseln in Softwarepflegeverträgen formularmäßig zu vereinbaren3.

233

Im Verbraucherverkehr müssen in AGB verwendete Kostenelementeklauseln, nach der Rechtsprechung des BGH i.S.d. § 307 BGB angemessen sein: Das Äquivalenzverhältnis, mithin das gleichwertige Verhältnis zwischen Leistung und Gegenleistung, darf sich nicht einseitig zu Lasten des Vertragspartners (Softwareanwender) ändern und es ist dem Verwender (Softwareanbieter) untersagt, mit der Anwendung der Preisanpassungsregelung nachträglich seinen Gewinn zu steigern4.

234

Die Kostenelementeklausel muss daher eine Begrenzung auf den Umfang der Kostensteigerung beinhalten. Wird eine Kostenposition durch eine Kosteneinsparung ausgeglichen, darf es nicht zu einer Preiserhöhung kommen (Pflicht zur Kostensaldierung), und fallen die Preise, muss der Verwender zur Kostensenkung verpflichtet sein (Pflicht zur Preissenkung)5.

235

Dies macht die Schwierigkeiten in Bezug auf die Umsetzung dieser Anforderungen deutlich. Eine Preisanpassungsklausel muss nicht nur den aufgestellten Kriterien genügen. Im Fall der Geltendmachung einer Preisanpassung muss der Verwender (Softwareanbieter) darlegen und beweisen, dass er die vereinbarten Regelungen eingehalten hat. Zu diesem Zweck muss er im Prozess vor den Gerichten seine Geschäftskalkulation offenlegen, was er jedoch nicht tun wird6.

236

Im unternehmerischen Verkehr ist in Bezug auf die Inhaltskontrolle von Kostenelementeklauseln nach § 307 BGB auf die im Handelsverkehr geltenden Gewohnheiten und Gebräuche angemessen Rücksicht zu nehmen, § 310 Abs. 1 Satz 2 BGB.

1 BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789. 2 Aufgeführt bei Graf von Westphalen, MDR 2008, 424. 3 Graf von Westphalen, MDR 2008, 424, Das faktische Ende von Preisanpassungsklauseln; Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 20 ff. 4 Die Rechtsprechung des BGH hierzu ist detailliert dargestellt in: Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 20 ff. 5 Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 20 ff. 6 Zahrnt, CR 2004, 408.

908

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 241 I

Dass sich im Softwarepflegemarkt Gewohnheiten und Gebräuche durch- 237 gesetzt haben, die dem Softwareanbieter im Rahmen der Anwendung von Kostenelementeklauseln regelmäßig Gewinnsteigerungen garantieren bzw. die Pflicht zur Kostensaldierung/Preissenkung ausschließen, dürfte wohl nicht festzustellen sein. Der Markt im Softwarepflegebereich dürfte eher das Gegenteil zeigen1. Warum sollte im Unternehmensverkehr das Gewinnsteigerungsverbot mit 238 der Pflicht zur Kostensaldierung/Preissenkung anders zu behandeln sein als im Verbraucherverkehr, oder anders gewendet: Ist bezüglich des Gewinnsteigerungsverbots bzw. der Pflicht zur Kostensaldierung/Preissenkung der Verwendungsgegner weniger schutzwürdig, nur weil er ein Unternehmen ist? Auch die Pflicht zur Kostensaldierung und die Pflicht zur Preissenkung bei Kosteneinsparungen dient nichts anderem als der Verhinderung der Gewinnsteigerung, die einseitig den Verwender (Softwareanbieter) begünstigen würde. Ebenso wie das die Pflegeleistungen anbietende Unternehmen ist die Geschäftsführung/der Vorstand des Softwareanwenders auf die Steigerung seines Unternehmenswerts angewiesen (s. hierzu Rz. 9). Daher dürfte es eher ausgeschlossen sein, im Softwarepflegemarkt beim 239 Unternehmensverkehr hinsichtlich der Kostenelementeklauseln grundsätzlich andere Maßstäbe im Bereich der Inhaltskontrolle (§ 307 BGB) anzulegen, als diese nunmehr vom BGH im Verbraucherverkehr vorgezeichnet sind2. Somit dürften auch sog. mathematisch ausgebildete Preisanpassungsklauseln in Softwarepflegeverträgen im Unternehmensverkehr nur wirksam sein, wenn diese die vom BGH im Verbraucherverkehr festgelegten Angemessenheitskriterien (s. Rz. 233 ff.) sicherstellen3. Zum Ausgleich einer – in einem ersten Schritt festgestellten – unangemessenen Benachteiligung des Softwareanwenders s. nachfolgend unter Rz. 250 ff.

240

bb) Preisvorbehaltsklauseln Bei Preisvorbehaltsklauseln ist das Leistungsbestimmungsrecht des Ver- 241 wenders nur dann wirksam, wenn es der Billigkeit entspricht (§ 315 BGB). Bestreitet der Softwareanwender (Auftraggeber), dass der Softwareanbieter (Auftragnehmer) sein Leistungsbestimmungsrecht nicht im Rahmen bil1 Es besteht eher nach wie vor erheblicher Kostendruck in den IT-Abteilungen der Softwareanwender, die bestrebt sind, ihre Kosten – auch im Softwarepflegebereich vielmehr zu senken, als zu erhöhen; s. hierzu: Newsletter Computerwoche, SAP-Wartung – Nicht nur Walldorf kostet v. 18.8.2010, in: http://www.com puterwoche.de/management/it-strategie/2351675/. S. auch „Supportgebühren für SAP-Wartung halbiert“ – Sympatex schließt als einer der ersten Kunden in Deutschland einen Drittwartungsvertrag mit Rimini Street v. 22.11.2011, in: http://www.cio.de/strategien/2295869/. 2 A.A. wohl Hilber, BB 2011, 2691 (2696 f.). 3 A.A. wohl Hilber, BB 2011, 2691 (2697).

Peter

909

I Rz. 242

Sonderregelungen

ligen Ermessens ausgeübt hat, ist der Softwareanbieter (Auftragnehmer) darlegungs- und beweispflichtig und müsste zu diesem Zweck ggf. sogar seine Kalkulation offenlegen, was er jedoch nicht tun wird1. 242

In jedem Fall ist ein sachlich gerechtfertigter Grund auf Seiten des Softwareanbieters (Auftragnehmers) Voraussetzung für die Wirksamkeit der Preisvorbehaltsklausel gemäß § 307 Abs. 1 BGB2, wobei hohe Anforderungen an die formularmäßige, wirksame Ausgestaltung des sachlichen Grundes – im Verbraucher- wie auch im Unternehmensverkehr – bestehen3.

243

Insbesondere wird angenommen, dass Preisvorbehaltsklauseln, in denen vorgesehen ist, dass einschränkungslos die jeweils gültigen Preislisten des Softwarepflegeunternehmens maßgeblich sein sollen, wegen Verstoßes gegen § 307 BGB unwirksam sind4.

244

Es ist mithin eher schwierig, Preis- bzw. Vergütungsvorbehaltsklauseln, so wie in der EVB-IT Pflege S und der BVB Pflege beschrieben, formularmäßig in AGB vom Softwareanbieter wirksam zu vereinbaren.

245

Zum Ausgleich einer – in einem ersten Schritt festgestellten – unangemessenen Benachteiligung des Softwareanwenders s. nachfolgend unter Rz. 250 ff. cc) Spannungsklauseln

246

Bislang gibt es keine Rechtsprechung des BGH dazu, unter welchen Voraussetzungen formularmäßige Spannungsklauseln in langfristigen Vertragsverhältnissen einer Inhaltskontrolle standhalten5.

247

Zum Maßstab für eine angemessene Spannungsklausel, die der Inhaltskontrolle standhalten könnte, hat der BGH ausgeführt: „In einem langfristigen Vertragsverhältnis mag für eine Spannungsklausel dann ein berechtigtes Interesse des Verwenders bestehen, wenn sie bestimmt und geeignet ist zu gewährleisten, dass der geschuldete Preis mit dem jeweiligen Marktpreis für die zu erbringende Leistung übereinstimmt (…). Dies setzt jedoch die Prognose voraus, dass sich der Marktpreis für die geschuldete Leistung typischerweise ähnlich wie der Marktpreis für das Referenzgut entwickelt. In 1 Zahrnt, CR 2004, 408. 2 Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 41 ff. 3 Einzelheiten s. Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 41 ff., 71. 4 Bartl, CR 1985, 13 zu § 9 AGBG; Palandt/Grüneberg, § 309 BGB Rz. 10 in Bezug auf eine Preiserhöhung gemäß Listenpreis beim Bauvertrag mit Verweis auf BGHZ 94, 338; Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 29 mit Verweis auf BGH v. 12.7.1989 – VIII ZR 297/88, NJW 1990, 115. 5 BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789; BGH v. 24.3.2010 – VIII ZR 304/08, NJW 2010, 2793.

910

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 252 I

diesem Fall handelt es sich um eine Bezugsgröße, die den Gegebenheiten des konkreten Geschäfts nahekommt und die deshalb für beide Vertragsparteien akzeptabel sein kann (…). Die Gewährleistung einer gleitenden Preisentwicklung vermeidet dabei auf beiden Seiten die Notwendigkeit, einen langfristigen Vertrag allein deswegen zu kündigen, um im Rahmen eines neu abzuschließenden Folgevertrags einen neuen Preis aushandeln zu können. Die Spannungsklausel sichert so zugleich stabile Vertragsverhältnisse und die im Massengeschäft erforderliche rationelle Abwicklung.“1 Das Zitat zeigt, wie schwierig es sein dürfte, eine diesen Voraussetzungen 248 genügende Vertragsklausel für Softwarepflegeverträge zu entwickeln und – das ist eine weitere Herausforderung – eine richtige, nachweisbare Prognose zu stellen. Zum Ausgleich einer – in einem ersten Schritt festgestellten – unangemessenen Benachteiligung des Softwareanwenders s. nachfolgend unter Rz. 250 ff.

249

dd) Ausgleich einer unangemessenen Benachteiligung Falls jedoch Preisanpassungsklauseln – egal welcher Art – verwendet wer- 250 den, die nach dem Vorhergesagten die erforderlichen Angemessenheitskriterien nicht erfüllen und mithin gemäß § 307 Abs. 1 Satz 1 BGB als eine unangemessene Benachteiligung des Verwendungsgegners (Softwareanwender) gelten würden, fragt sich, ob dies ausgeglichen werden kann mit dem Ergebnis, dass die Preisanpassungsklausel i.S.v. § 307 BGB letztlich doch wirksam ist. Eine unangemessene Benachteiligung i.S.v. § 307 Abs. 1 BGB kann – im Verbraucher- wie auch im Unternehmensverkehr – durch Gewährung anderer rechtlicher Vorteile ausgeglichen werden oder durch höherrangige Interessen des AGB-Verwenders gerechtfertigt sein (s. hierzu vertiefend Rz. 173 f.).

251

(1) Höherrangige Interessen Höherrangige Interessen des Softwareanbieters im Softwarepflegemarkt 252 dürften weder im Verbraucherverkehr noch im Unternehmensverkehr festzustellen sein. Die Geschäftsmodelle im Fall der Pflege von Individualsoftware oder der Pflege von Standardsoftware (zu den Geschäftsmodellen s. Rz. 333 ff., 344) zeigen keine Anhaltspunkte für ein höherrangiges Interesse des Softwareanbieters als vielmehr und lediglich den kalkulatorischen Ausgleich von etwaigen Kostensteigerungen. Bei der Pflege von Individualsoftware kann und muss der Softwareanbieter das Entgelt für seine Leistungen im Voraus für einen festen, überschaubaren Zeitraum kalkulieren; seine dafür etwa erforderlichen Anfangsinvestitionen sind auf ein konkretes Projekt bezogen und damit klar überschaubar zu kalkulieren. Es ist Aufgabe des Softwareanbieters, in das Projekt einzukalkulierende Gemeinkosten so zu 1 BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789; BGH v. 24.3.2010 – VIII ZR 304/08, NJW 2010, 2793.

Peter

911

I Rz. 253

Sonderregelungen

managen, dass etwaige Kostensteigerungen bei den Gemeinkosten möglichst unwesentlich auf den Gewinn durchschlagen. 253

Bei der Pflege von Standardsoftware gilt hinsichtlich der Gemeinkosten grundsätzlich dasselbe, jedoch kommt hinzu, dass das Überschreiten der für die Wirtschaftlichkeit des Vorhabens erforderlichen Menge der Kundenverhältnisse den Gewinn des Softwareanbieters maßgeblich steigern kann, selbst wenn in Bezug auf einzelne Kostenfaktoren Kostensteigerungen zu verzeichnen sind, denn diese werden auf alle Kundenverhältnisse umgelegt und verringern sich somit anteilig, je mehr die Kundenanzahl anwächst. Eine etwaige Fehlkalkulation in einem Pflegeprojekt für Individualsoftware oder das Nichterreichen der erforderlichen Menge von Kundenverhältnissen bei der Pflege von Standardsoftware gehört jedoch zum originären unternehmerischen Risiko des Softwareanbieters und stellt mitnichten ein gegenüber dem Softwareanwender – sei dieser Verbraucher oder Unternehmer – anzuerkennendes höherrangiges Interesse dar. (2) Gewährung eines rechtlichen Vorteils

254

Fraglich ist, ob im Fall einer gewünschten Preisanpassung ein dem Softwareanwender eingeräumtes Kündigungsrecht, dessen Kündigungsfristen regelmäßig zwischen vier bis sechs Wochen liegen1, eine anzuerkennende Gewährung eines rechtlichen Vorteils darstellen kann2, um die in der Preisanpassungsklausel enthaltene und zuvor festgestellte unangemessene Benachteiligung des Verwendungsgegners wieder auszugleichen.

255

Zur Erinnerung: Es geht hier um die Lösung des bestehenden Konflikts von berechtigten Interessen beider Vertragspartner, des Softwareanbieters wie auch des Softwareanwenders, aufgrund einer gewünschten Preisanpassung. Deswegen muss die Inhaltskontrolle – so der BGH – immer die Art des konkreten Vertrags, der typischen Interessen der Vertragschließenden und der die jeweilige Klausel begleitenden Regelung berücksichtigen, s. vorstehend Rz. 230.

256

Daher kann ein durch den Softwareanbieter formularmäßig verwendetes Kündigungsrecht zu Gunsten des Softwareanwenders nur dann zu berücksichtigen sein, wenn es dem Softwareanwender im Fall der vorzeitigen Kündigung überhaupt möglich ist, auf vergleichbare Pflegeleistungen eines Wettbewerbers des Softwareanbieters auszuweichen.

257

Dies setzt im Rahmen einer Einzelfallprüfung die Beantwortung mehrerer Fragen voraus: Zum einen muss für die gepflegte Software überhaupt ein Markt mit vergleichbaren Softwarepflegeleistungen existieren, auf dem echter Preiswettbewerb stattfindet. Andernfalls wäre die dem Softwareanwender ein1 Graf von Westphalen, Vertragsrecht und AGB-Klauselwerke, Preisanpassungsklauseln, Rz. 74. 2 Palandt/Grüneberg, § 309 BGB Rz. 8, 9.

912

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 260 I

geräumte Kündigungsoption mangels echter Ausweichmöglichkeiten ein untaugliches und damit ein im Rahmen der Inhaltskontrolle nicht zu berücksichtigendes Mittel, um das berechtigte Interesse des Softwareanwenders auf Schutz vor Preisanpassungen, die über die ursprünglich festgelegten gegenseitigen Vereinbarungen hinausgehen, zu wahren1. Zum anderen müsste der Softwareanwender rechtlich und tatsächlich über- 258 haupt in der Lage sein, die Softwarepflegeleistungen durch einen Dritten erbringen zu lassen. Hierfür muss dem Softwareanbieter (falls nach den vereinbarten Pflegeleistungen erforderlich, z.B. bei der Pflicht, Fehler in der Software zu beseitigen) der Quellcode der zu pflegenden Software in der aktuellen Version vorliegen, damit dieser dem Wettbewerber, der die Pflegeleistungen fortführen soll, zugänglich gemacht werden kann. Weiterhin muss der Softwareanbieter es dem Softwareanwender in rechtlich ausreichendem Maß gestatten, alle in die aktuelle Softwareversion vom Softwareanbieter eingeflossenen Ergebnisse seiner Pflegeleistungen zum Zweck der Weiterführung der Softwarepflege durch einen Wettbewerber nutzen zu dürfen. Dies wiederum setzt voraus, dass der Softwareanbieter den Softwareanwender mit dem dafür notwendigen Know-how versorgt, insbesondere den aktuellen Stand der gepflegten Software und seiner Pflegeleistungen in einem Betriebshandbuch so beschreibt, dass es einem Wettbewerber ohne Weiteres möglich ist, innerhalb der vom Softwareanbieter gesetzten Kündigungsfrist die Softwarepflegeleistungen vom Softwareanbieter in vergleichbarer Qualität und Güte zu übernehmen. Diese Voraussetzungen dürfen mithin nicht nur rein tatsächlich vorliegen, sondern müssen – was die Übernahme der Softwarepflege durch einen Wettbewerber des Softwareanbieters angeht – spätestens zum Zeitpunkt der Geltendmachung der Preisanpassung rechtlich verbindlich zwischen dem Softwareanbieter und dem Softwareanwender gelten bzw. vereinbart sein, damit sich der Softwareanwender hierauf berufen kann.

259

Schließlich darf ein Wechsel auf einen Wettbewerber des Softwareanbieters, 260 der die Pflegeleistungen fortführt, den Softwareanwender nicht mehr als nur unwesentlich zusätzlich finanziell belasten. Dabei dürften ihm die etwa entstehenden Kosten zum Abschluss der Folge-Pflegevereinbarung generell zuzumuten sein. Sie entstehen in jedem Fall und spätestens dann, wenn der bestehende Softwarepflegevertrag ordentlich beendet wird und ein neuer Softwarepflegevertrag abzuschließen ist. Der dadurch allenfalls entstehende Zinsschaden dürfte vom Softwareanwender wohl hinzunehmen sein, damit eine angemessene Konfliktlösung erzielt werden kann. Damit zeigt sich aber zugleich, dass eine darüber hinausgehende, mehr als nur unwesentliche finanzielle Belastung dem Softwareanwender nicht zuzumuten ist. Er 1 BGH v. 24.3.2010 – VIII ZR 178/08, NJW 2010, 2789 (2792): Zur Unwirksamkeit einer Spannungsklausel bezüglich der Gas-/Ölpreisbindung, weil wegen fehlenden Wettbewerbs auf dem Gasmarkt ein Marktpreis für Gas nicht festgestellt werden kann.

Peter

913

I Rz. 261

Sonderregelungen

hat mit dem vorzeitigen Wechselaufwand seinen Beitrag zur Erzielung eines angemessenen Ausgleichs des bestehenden Interessenkonflikts erbracht. Weitere Zugeständnisse dürften dem Softwareanwender daher nur in ganz besonderen Ausnahmefällen abverlangt werden. 261

Letztlich dürfte es dem Softwareanwender generell nicht zuzumuten sein, sich auf den Erwerb bzw. die Überlassung einer anderen Software verweisen zu lassen, die sodann neu beginnend durch einen Wettbewerber zu pflegen wäre. Der Erwerb bzw. die Überlassung einer neuen Software verursacht beim Softwareanwender eine nicht hinzunehmende neue Investition, die außerhalb der in Frage stehenden Preisanpassung für die Pflege der bereits angeschafften Software steht. Diese Alternative mag allenfalls im Verbraucherverkehr und bei der Pflege einfacher und billiger Standardsoftware denkbar sein, wenn der Wechsel auf eine neue, zu pflegende Standardsoftware den Verbraucher lediglich unwesentlich belastet.

262

Sind also die tatsächlichen, vertragsrechtlichen und kommerziellen Voraussetzungen geschaffen bzw. vorhanden, so dass der Softwareanwender im Fall einer gewünschten Preisanpassung und bei Wahrnehmung der ihm eingeräumten Kündigungsoption innerhalb der vorgesehenen Kündigungsfrist ohne Weiteres und ohne wesentliches Risiko auf die Pflegeleistungen eines Wettbewerbers in einem echten, funktionierenden Markt für die Pflege seiner Software ausweichen kann, dürfte die Einräumung einer entsprechenden Kündigungsoption – sei es im Verbraucherverkehr, sei es im Unternehmensverkehr und unabhängig davon, ob es sich um die Pflege von Standardoder Individualsoftware handelt – eine zum Zwecke der Inhaltskontrolle ausreichende Gewährung eines rechtlichen Vorteils sein. In diesem Fall dürfte daher eine Preisanpassung, selbst wenn diese auf der Grundlage einer nicht angemessenen Preisanpassungsklausel erfolgt, im Ergebnis doch mit § 307 Abs. 1 BGB vereinbar sein.

263

Damit ist jedoch nicht das Tor geöffnet, dass sich der Softwareanbieter mit einem überzogenen Preisanpassungsgesuch jederzeit seiner Verpflichtung, die vereinbarten Softwarepflegeleistungen zu erbringen, entziehen darf. Die Ausübung eines solchen Rechts darf nicht treuwidrig (§ 242 BGB) sein, mithin insbesondere nicht rechtsmissbräuchlich erfolgen.

264

Stellt die Einräumung eines Kündigungsrechts im Fall einer Preisanpassung eine i.S.d. § 307 Abs. 1 BGB anerkennenswerte Gewährung eines rechtlichen Vorteils dar, ist die Höhe der Preisanpassung in das kaufmännische Ermessen des Softwareanbieters gestellt und – vorbehaltlich des Vorhergesagten – gerichtlich nicht überprüfbar. Denn sie ist als Preisbestimmung, die lediglich die zu erbringende neue Vergütung bestimmt, von der Inhaltskontrolle ausgeschlossen, § 307 Abs. 3 BGB (s. hierzu vorstehend Rz. 228). In einem Markt mit funktionierendem Wettbewerb begrenzt vielmehr jener die Anpassung auf neue Preise automatisch auf die im Markt durchsetzbaren Entgelte.

914

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 269 I

d) Ergänzende Vertragsauslegung Es ist noch zu fragen, ob im Fall der Unwirksamkeit einer formularmäßigen 265 Preisanpassungsklausel eine angemessene Preisanpassungsregelung im Wege der ergänzenden Vertragsauslegung in Betracht kommt1. So könnte sich im Einzelfall aus der Natur sehr langfristiger Softwarepflegeverträge ergeben, dass sich die Vertragsparteien bewusst waren und in ihren Willen aufgenommen hatten, dass das zunächst vereinbarte Entgelt nicht während der gesamten Vertragsdauer gelten, sondern sich zum Zweck eines angemessenen Wertausgleiches ändern soll, wenn die Kostenentwicklung es erfordert2. e) Individualvereinbarung Will der Softwareanbieter dem Problemkreis der wirksamen Vereinbarung 266 von Preisanpassungsklauseln in seinen AGB entgehen, muss er entweder eine Preisanpassungsklausel individuell aushandeln oder Softwarepflegeverträge mit unbestimmter oder kurzer Laufzeit vereinbaren, die er im Fall einer beabsichtigten Preisanpassung kündigt bzw. auslaufen lässt, um anschließend ein Angebot auf Neuabschluss mit einem angepassten Preis zu unterbreiten. Die zuvor genannte letztere Vorgehensweise kollidiert jedoch mit dem Interesse des Softwareanbieters, Softwarepflegeverträge für möglichst längerfristige Zeiträume fest abzuschließen (s. hierzu Rz. 322 ff. zur Kündigungsmöglichkeit nach § 649 BGB). Außerdem darf eine solche Kündigung nicht rechtsmissbräuchlich sein, § 242 BGB (s. hierzu Rz. 263), und nicht gegen kartellrechtliche Vorschriften verstoßen (s. hierzu Rz. 63 ff.).

267

Letztlich bleibt dem Softwareanbieter nur der Weg, während der Laufzeit des Softwarepflegevertrags mit seinem Vertragspartner (Softwareanwender) im Rahmen eines vertraglichen Änderungsverfahrens eine Preisanpassung individuell und einvernehmlich zu vereinbaren.

268

3. Gegenstand der Pflege a) Maßgebliche Softwareversion Die Einigung der Vertragsparteien darüber, welche Software ab welchem 269 Versionsstand (z.B. 4.2.6) gepflegt werden soll, ist wesentliches Element des Vertrags. Haben sich die Vertragsparteien über wesentliche Elemente des Vertrags nicht geeinigt, ist der Softwarepflegevertrag nicht zustande gekom-

1 Palandt/Grüneberg, § 306 BGB Rz. 13 mit Verweis auf BGH, WM 2007, 796 Tz. 39: Eine ergänzende Vertragsauslegung findet nur im Individualprozess statt, nicht im Verbandsprozess. 2 BGH v. 12.7.1989 – VIII ZR 297/88, NJW 1990, 115 zu einem Mietvertrag mit einer Mindestlaufzeit von 10 Jahren.

Peter

915

I Rz. 270

Sonderregelungen

men1. Falls die Vertragsparteien ungenaue Bezeichnungen aufnehmen, ist zunächst durch Auslegung (§§ 133, 157 BGB) zu ermitteln, welche konkrete Software gemeint ist2. 270

Soweit Softwareüberlassung und Softwarepflege von einem Softwareanbieter angeboten werden, dürfte der Softwareüberlassungsvertrag die eindeutige Antwort geben: Der Pflegevertrag wird aufgrund der Softwareüberlassung abgeschlossen; die überlassene Software soll gepflegt werden. Soweit anhand des Softwareüberlassungsvertrags die Software im maßgeblichen Versionsstand eindeutig bestimmt werden kann, dürfte eine ungenaue Bezeichnung des Pflegegegenstandes im Pflegevertrag in der Regel unschädlich sein.

271

Falls die Anbieter für die Softwareüberlassung und für die -pflege nicht personenidentisch sind, könnte sich die eindeutige Bestimmung des Pflegegegenstandes als schwieriger herausstellen. b) Verweigerung der Übernahme einer Pflegelieferung durch den Softwareanwender

272

Der Softwareanwender hat daran Interesse, dass die überlassene Software technologisch und inhaltlich-funktionell weiterentwickelt wird und während des Nutzungszeitraums fehlerfrei arbeitet (s. Rz. 11). Um dieses Anwenderinteresse zu erfüllen, ist der Softwarehersteller bestrebt, dass möglichst viele Anwender in seinen Pflegetopf einzahlen, damit er ausreichend Personal in seiner Entwicklungsabteilung vorhalten kann, das die geforderten Erwartungen umsetzt und die Ergebnisse der Anwenderschaft zur Verfügung stellt3.

273

Das Interesse eines Softwareanwenders ist jedoch möglicherweise tangiert, wenn er mit Übernahme einer Programmkorrektur mehr als nur unerhebliche zusätzliche Kosten verzeichnen muss, z.B. durch Investitionen in neue Hardware oder neue Betriebssoftware oder – aufgrund veränderter Schnittstellen – in neue Softwareapplikationen, die mit der überlassenen Software zusammenarbeiten. Ebenso kann sein Investitionssicherungs- oder -erhaltungsinteresse verletzt sein, wenn die Programmkorrektur in funktioneller Hinsicht wesentlich von der überlassenen Software abweicht, so dass er die Software nicht mehr zum beabsichtigten Zweck einsetzen kann.

274

Der Softwarehersteller hat nicht das Interesse, für einen Softwareanwender eine gesonderte kleine Entwicklungsabteilung zu gründen und vorzuhalten, die nunmehr ausschließlich seinen Versionsstand pflegt. Er ist vielmehr da-

1 Palandt/Ellenberger, § 155 BGB Rz. 1. 2 Nach Schreibauer/Taraschka, CR 2003, 557 sollte auf die Dokumentationen der Software Bezug genommen und angegeben werden, wie viele Kopien der Software zu pflegen sind. 3 Zahrnt, CR 2004, 408; Zahrnt, Computervertragsrecht, Kapitel 14.2.1 (3.1).

916

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 281 I

ran interessiert, dass alle Softwareanwender den jeweils aktuellen Stand der Software einsetzen und er keine Vorversionen gesondert pflegen muss. Dann stellt sich die Frage, wie dieser Konflikt zwischen Softwareanwender und Softwarehersteller bzw. -anbieter zu lösen ist.

275

Die EVB-IT Pflege S, die explizit nur auf die Pflege von Standardsoftware 276 Anwendung findet, regelt in Ziff. 8.2 gewisse Tatbestandsvoraussetzungen und Rechtsfolgen für den Fall, dass der Softwareanwender (in den EVB-IT Pflege S als „Auftraggeber“ bezeichnet) eine Programmkorrektur nicht übernehmen möchte: Sollte er berechtigt sein, die Programmkorrektur nicht zu übernehmen, was 277 der Fall ist, falls dem Softwareanwender die Übernahme nicht zuzumuten ist, weil diese wesentlich von der überlassenen Software abweicht, kann er Nacherfüllung in Bezug auf Mängelbeseitigung verlangen. Schlägt diese innerhalb angemessener Frist fehl, kann er Aufwendungsersatz, Herabsetzung der Vergütung oder Rücktritt vom Vertrag hinsichtlich der beauftragten Mängelbeseitigungsleistung und ggf. Schadensersatz geltend machen. Der Schadensersatz ist dabei auf 8 % des Auftragswerts begrenzt. Ist dem Softwareanwender trotz alledem die Fortsetzung des gesamten Pflegevertrages nicht mehr zuzumuten, kann er den Pflegevertrag ganz oder teilweise kündigen. Sollte der Softwareanwender – unabhängig davon, ob es sich um Standard- 278 oder Individualsoftware handelt – keine explizite Regelung zu dem hier behandelten Fragekomplex vereinbart haben, dürfte es maßgeblich darauf ankommen, ob die Überlassung der Programmkorrektur eine Verletzung der vertraglich vereinbarten Pflichten darstellt. Die Beantwortung dieser Frage dürfte im Wesentlichen vom Ergebnis der Befassung mit den §§ 241 Abs. 2, 241a, 242 und 266 BGB abhängig sein. Steht eine Pflichtverletzung fest und kommt der Softwarehersteller bzw. 279 -anbieter dem Erfüllungsverlangen nicht nach, verbleibt dem Softwareanwender nur die Geltendmachung sog. Sekundäransprüche, aufgrund deren der Softwarepflegevertrag auch rückabgewickelt werden kann. Dies hilft dem Softwareanwender letztendlich nicht, will er die Software 280 weiter nutzen. Es kann ihm nur die Herausgabe des Quellcodes helfen, um selbst oder mithilfe eines Dritten die erwarteten Pflegeleistungen sicherzustellen. Zur Herausgabe des Quellcodes s. Kap. L. Rz. 112 ff. c) Einstellen der Pflege für einen alten Programmkorrekturstand Mit Überlassung einer Programmkorrektur an den Softwareanwender stellt 281 sich die Frage, ob der Softwareanbieter verpflichtet ist, weitere Pflegeleistungen für den zuletzt eingesetzten Programmkorrekturstand zu erbringen.

Peter

917

I Rz. 282

Sonderregelungen

aa) Programmkorrekturen und deren Auswirkungen 282

Soweit dem Softwareanwender lediglich Umgehungen, Patches oder Updates überlassen sind (zu den Begriffen s. Rz. 40 ff.), werden mit deren Einspielen ausschließlich Mängelbehebungen durchgeführt. Die vom Softwareanwender genutzte Software bleibt in Bezug auf Art und Umfang der Funktionalitäten oder Einsatzbedingungen unverändert. Weitere Programmkorrekturen setzen daher auf dem bestehenden Programmstand auf, die von ein und derselben Entwicklungsabteilung des Softwareherstellers erarbeitet werden können. In diesen Fällen steht die hier behandelte Problematik nicht in Rede.

283

Sobald jedoch ein Upgrade oder ein Release/eine Version (zu den Begriffen s. Rz. 43, 44) ausgeliefert wird, muss die Entwicklungsabteilung des Softwareherstellers eine Software pflegen, die im Verhältnis zu dem bisherigen Stand der Programmkorrektur über neue oder geänderte Funktionen, Anpassungen (z.B. an geänderte Einsatzbedingungen, z.B. das Zusammenarbeiten mit neuen oder anderen Softwareapplikationen oder neuen Programmkorrekturständen der eingesetzten Betriebssoftware) oder sonstige Korrekturen verfügt, mithin unter Umständen ein in wesentlichen Teilen verändertes Softwareprodukt darstellt. Dabei liegt es auf der Hand, dass die Entwicklungsabteilung des Softwareherstellers bei allen weiteren Programmkorrekturen genau auf diesem neuen Programmkorrekturstand aufsetzen muss, um sicherzustellen, dass die weiteren Programmkorrekturen die Funktionsfähigkeit der Software (inklusive aller neuen Funktionalitäten, Anpassungen oder sonstigen Korrekturen) nicht negativ beeinträchtigen. bb) Interessenlage

284

Für den Softwareanbieter/-hersteller ist daher entscheidend, dass alle Softwareanwender mit einem einheitlichen und aktuellen Programmkorrekturstand arbeiten1. Andernfalls müsste der Softwarehersteller eine zusätzliche Entwicklungsabteilung bereitstellen, die den vorherigen Programmkorrekturstand weiterpflegt, so dass zwei Entwicklungsabteilungen parallel bestehen, die unterschiedliche Programmkorrekturstände von ein und derselben Software bearbeiten.

285

Diese für den Softwarehersteller auf den ersten Blick unbillige Situation kann er entweder dadurch lösen, dass er die bisherige Entwicklungsabteilung aufteilt oder andernfalls zusätzliches Personal bereitstellt. Der erste Fall dürfte negative Auswirkungen auf die Qualität der weiteren Programmkorrekturen haben oder zu zeitlichen Verzögerung hinsichtlich der Fertigstellung und Auslieferung weiterer Programmkorrekturen führen, was für beide Seiten nachteilig sein kann. Im zweiten Fall müsste er Preiserhöhun-

1 Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, 1.12 Rz. 76.

918

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 291 I

gen durchsetzten, damit die – durch zusätzliches Personal gestiegenen – Kosten aufgefangen werden. Führt hingegen die Übernahme eines Upgrades oder eines Releases/einer 286 Version zu einer zusätzlichen Investition des Softwareanwenders, weil er mit Übernahme der Programmkorrektur veranlasst ist, z.B. neue Betriebssoftware oder neue Hardware anzuschaffen oder die Software erneut auf seine besonderen Bedürfnisse entgeltpflichtig anpassen zu lassen, steht die Frage im Raum, ob die mit der Nutzung der neuen Programmkorrektur verbundenen Vorteile die durch sie verursachten Nachteile ausgleichen. Ist das nicht der Fall, liegt die Entscheidung des Softwareanwenders nahe, die Programmkorrektur nicht übernehmen zu wollen.

287

cc) Ausdrückliche Vereinbarung Klarheit zu der eingangs gestellten Frage bringt eine ausgehandelte Individualvereinbarung, die im Einzelfall lediglich an § 138 BGB zu messen ist1.

288

Formularklauseln finden Ihre Grenze zusätzlich in den §§ 307 bis 309 BGB. 289 Eine formularmäßige Vereinbarung über das Einstellen der Pflege für einen alten Programmkorrekturstand unterfällt jedoch nicht der Inhaltskontrolle der §§ 307 ff. BGB, denn Leistungsbeschreibungen, die Art, Güte und Umfang der Hauptleistung unmittelbar festlegen, sind einer Inhaltskontrolle entzogen2. Und die hier ins Auge gefasste Vereinbarung stellt nichts anderes dar als eine Leistungsbeschreibung. Denn die Beschränkung der Pflege auf den aktuellen Programmkorrekturstand legt lediglich den Umfang der vereinbarten Pflegeleistungen fest. Eine derartige formularmäßige Leistungsbeschreibung muss jedoch dem 290 Transparenzgebot genügen, wie § 307 Abs. 3 Satz 2 BGB ausdrücklich klarstellt. Der Softwareanbieter/-hersteller darf die Pflege des vorausgehenden Pro- 291 grammkorrekturstands jedoch nur einstellen, solange und soweit dem Softwareanwender kein Recht zusteht, die Übernahme der neuen Programmkorrektur zu verweigern (s. hierzu Rz. 272 ff.). Stellt die Überlassung der ausgelieferten Programmkorrektur eine Pflichtverletzung dar (s. hierzu Rz. 277 ff.) oder ist dem Softwareanwender die Übernahme der Programmkorrektur aus anderen Gründen nicht zuzumuten, ist es dem Softwareanbieter/-hersteller verwehrt, sich auf seine Vereinbarung zum Einstellen der Pflege für den alten Programmkorrekturstand zu berufen. Die Gründe (z.B. der Softwareanwender müsse erhebliche Vorinvestitionen tätigen, um die Programmkorrektur übernehmen zu können), die dem Softwareanbie1 Klauselbeispiele s. Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, 1.12 § 6 Ziff. 5. Die Durchsetzbarkeit ist an § 242 BGB zu messen. 2 Palandt/Grüneberg, § 307 BGB Rz. 44 mit Verweis auf BGH v. 29.4.2010 – Xa ZR 5/09, NJW 2010, 1958; BGH v. 9.5.2001 – IV ZR 121/00, MDR 2001, 1055 = NJW 2001, 2014.

Peter

919

I Rz. 292

Sonderregelungen

ter/-hersteller das Recht nehmen sollen, sich auf seine vertragliche Bestimmungen berufen zu dürfen, müssen jedoch die Hürde des § 242 BGB nehmen, wobei der Blick auf § 241 Abs. 2 BGB nicht verschlossen werden sollte. dd) Fehlende Vereinbarung 292

Haben die Vertragsparteien es versäumt, eine entsprechende Bestimmung in ihren Vertrag aufzunehmen, nimmt die Beantwortung der Frage, ob der Softwareanbieter/-hersteller die Pflege für den – dem ausgelieferten Upgrade oder Release vorhergehenden – Programmkorrekturstand einstellen kann, zum einen Maß an den §§ 242, 241 Abs. 2 BGB. Zum anderen kann sich der Softwareanbieter/-hersteller auf die Absätze 2 oder 3 des § 275 BGB berufen, falls wiederum ihm hierfür ausreichende Gründe zur Seite stehen.

293

Sollte sich der Softwareanwender mit Erfolg auf die §§ 242, 241 Abs. 2 BGB berufen und eine Pflege des vorherigen Programmkorrekturstands verlangen können, dürfte es widersprüchlich und damit rechtsmissbräuchlich sein (§ 242 BGB), wenn der Softwareanbieter/-hersteller eine Weiterpflege unter Berufung auf eine Bestimmung des Softwarepflegevertrags verweigert, nach der – wie im Fall der Ziff. 8.2 am Ende der EVB-IT Pflege S zementiert – der Softwareanwender bei Überlassung einer Programmkorrektur die jeweils ausgetauschte Fassung zu vernichten oder auf Verlangen an den Auftragnehmer (Softwareanbieter/-hersteller) herauszugeben hat.

VIII. Laufzeit der Pflege und Kündigung 1. Laufzeit der Pflege 294

Von der Prämisse ausgehend, dass es sich bei dem Softwarepflegevertrag regelmäßig um ein Dauerschuldverhältnis handelt1, ist die Frage zu klären, welcher Zeitraum für die Erbringung der Leistungen rechtswirksam vereinbart werden darf. a) Beginn der Pflege aa) Differenzierend nach Pflegeleistungsteil

295

Abhängig von der betroffenen Pflegeleistung (Programmkorrekturen, Installationsleistungen oder Hotline) kann je nach den Bedürfnissen im Einzelfall der Zeitpunkt unterschiedlich ausfallen, wann alle oder einzelne Pflegeleistungen beginnen sollen2. 1 Bischof/Witzel, ITRB 2003, 31; Bartsch, NJW 2002, 1526; Marly, Praxishandbuch Softwarerecht, Rz. 1029; Schneider, Handbuch des EDV-Rechts, K. Rz. 49; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 1.12 Rz. 12. 2 Schneider, ITRB 2005, 191; Zahrnt, CR 2004, 408; Schneider, CR 2004, 241; Intveen, ITRB 2004, 138.

920

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 301 I

Je komplexer die überlassene Software ist, desto früher kann seitens des 296 Softwareanwenders das Bedürfnis nach Hotline-Leistungen bestehen, um sein Interesse zu wahren, dass die überlassene Software baldmöglichst (und fehlerfrei) zum Einsatz kommt. Dem dienen z.B. auch Schulungsleistungen, die regelmäßig bereits mit der Softwareüberlassung vereinbart werden und die es dem Softwareanwender ermöglichen, den Umgang mit den Funktionalitäten der Software zu erlernen; ebenso ist er in der Lage, auftauchende Fragen mittels der Hotline unmittelbar zu klären. Obliegt dem Softwareanbieter/-hersteller aufgrund des Softwareüberlassungsvertrags während der Laufzeit der Verjährung von Mängelansprüchen oder während der Mietzeit (§ 535 Abs. 1 Satz 2 BGB) die Verpflichtung zur Mängelbeseitigung und ist diese nicht wirksam auf den Softwareanwender abgewälzt (s. hierzu Rz. 167 ff.), kommt die kostenpflichtige Überlassung von Programmkorrekturen, die der Mängelbeseitigung dienen, nur nach Ablauf der Verjährungsfrist von Mängelansprüchen in Betracht; während der Mietzeit hingegen überhaupt nicht (s. hierzu Rz. 200 ff.).

297

Zu der Frage, ab wann die Verjährungsfrist zu laufen beginnt bzw. endet, s. Rz. 522 ff. und 533, 5341.

298

Soweit die Programmkorrekturen neben der Mängelbeseitigung weitere 299 Leistungen enthalten, wie dies bei sog. Upgrades oder neuen Releases/Versionen der Fall ist (zu den Begriffen vgl. Rz. 43 f.), sind diese Leistungen des Softwareanbieters/-herstellers grundsätzlich zu vergüten. Da der Softwareanbieter/-hersteller üblicherweise das Interesse hat, dass der Softwareanwender immer die aktuellste Programmkorrektur einsetzt, wird er keinen Softwarepflegevertrag ohne eine entsprechende Vereinbarung abschließen (s. hierzu Rz. 274). Der Softwareanbieter/-hersteller wird demnach darauf achten, dass mit Überlassung der Software deren Pflege beginnt. Zur Höhe eines möglichen Abschlags für Mängelbeseitigungskosten s. Rz. 165.

300

bb) Konflikte mit Leistungen aus dem Softwareüberlassungsvertrag Die Praxis zeigt, dass häufig unmittelbar nach Abschluss teilweise langwie- 301 riger Vertragsverhandlungen über die Überlassung einer Software nebst Pflege der Softwareanbieter/-hersteller ein neues Release/eine neue Version herausbringt. Da der Softwareanbieter/-hersteller die jeweils aktuelle Version pflegen möchte (s. Rz. 274) und der Softwareanwender sie ebenfalls unmittelbar einsetzen will, um an den neuen Funktionalitäten zu partizipieren (s. Rz. 12 ff.), können Konflikte insbesondere dann entstehen, wenn der Softwareanwender bereits nicht unerhebliche Aufwände für die Vorbereitung bzw. für die Durchführung der Installation und Einrichtung/Parametrisierung/Anpassung der erstmalig überlassenen Softwareversion aufgebracht

1 Schneider, ITRB 2005, 191; Schneider, CR 2004, 241.

Peter

921

I Rz. 302

Sonderregelungen

hat und die überlassene Softwareversion quasi nicht oder kaum zum Einsatz kommt. 302

In diesem Zusammenhang wird z.B. vorgeschlagen, dass Programmkorrekturen mit neuen Funktionalitäten/Anpassungen nach erstmaliger Softwareüberlassung für eine Übergangszeit von sechs Monaten nicht eingesetzt werden müssen und erst danach die Pflegeverpflichtung für die Altversion endet1.

303

Unabhängig von den Möglichkeiten der vertraglichen Gestaltung gilt: Hat der Softwareanwender die erstmalige Installation und die Einrichtung/Parametrisierung/Anpassung der Software im Rahmen ihrer Überlassung gezahlt, drängt sich auf, dass er diese – nunmehr unnütz gewordenen – Leistungen mit der Softwarepflege nicht sofort wieder vergüten möchte. Diese (doppelte) Vergütungsproblematik entsteht jedoch in Bezug auf die durch den Softwareanbieter verursachten Kosten nur dann, wenn das angewandte Geschäftsmodell für die Softwarepflege keine Vergütungspauschale vorsieht, sondern die Leistungen für die Installation und Einrichtung/Parametrisierung/Anpassung des neuen Releases nach Aufwand (tätigkeits- oder erfolgsorientiert) gesondert zu vergüten sind.

304

Hierbei sei aber das Folgende klargestellt: Steht fest, dass der Softwareanbieter/-hersteller im Rahmen der Verhandlungen zum Softwareüberlassungsvertrag es pflichtwidrig versäumt hat, den Softwareanwender über die bevorstehende Auslieferung eines neuen Upgrades oder Releases aufzuklären, und ist es deshalb zu einer Installation und Einrichtung/Parametrisierung/ Anpassung der Vorversion gekommen, auf die der Softwareanwender andernfalls verzichtet hätte, entsteht dem Softwareanwender möglicherweise ein nicht unerheblicher Schaden: Der Pflegevertrag hätte nicht früher zu laufen beginnen müssen, sondern hinsichtlich des Beginns der Laufzeit auf die Auslieferung des neuen Upgrades oder Releases abstellen können. Die Kosten, die dem Softwareanwender z.B. dadurch entstehen, dass er bei Dritten Vorleistungen für die Vorversion einkaufen musste (ggf. Anschaffung und Installation einer anderen Systemumgebung für die Vorversion) oder die Vorversion zu installieren hatte und diese einrichten, parametrisieren oder anpassen musste, hätte er sich möglicherweise komplett erspart.

305

Eine Anspruchsgrundlage für die Geltendmachung eines solchen Schadens lässt sich aus den §§ 280 Abs. 1, 311 Abs. 2 Nr. 1, 241 Abs. 2 BGB (Verschulden bei Vertragsverhandlungen) herleiten (s. hierzu auch Rz. 70 f., 72 ff.).

1 Intveen, ITRB 2004, 138.

922

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 309 I

b) Laufzeit des Softwarepflegevertrags aa) Individualvereinbarung Die Laufzeit für eine Pflegevereinbarung kann innerhalb der Grenzen des § 138 BGB frei vereinbart werden1.

306

Eine generelle Pflicht über Treu und Glauben (§ 242 BGB), Pflegeleistungen 307 für den gesamten Lebenszyklus einer verkauften Software sicherzustellen, ist nicht anzuerkennen (s. hierzu Rz. 60 ff.)2. Allenfalls könnte sich aus kartellrechtlichen Erwägungen gemäß § 19 GWB 308 (Missbrauch einer marktbeherrschenden Stellung) oder aus dem Verbot der Diskriminierung nach § 20 Abs. 1 GWB3 nicht nur ein Abschlusszwang ergeben (s. hierzu Rz. 63 ff.), sondern es könnte eine Mindestlaufzeit für die Verpflichtung zur Pflege einer überlassenen Software aus dem Kartellrecht herzuleiten sein, deren Dauer abhängig vom jeweiligen Einzelfall festzustellen ist. bb) Öffentliche Ausschreibung Zu beachten ist schließlich, dass die im Rahmen von öffentlichen Verga- 309 beverfahren vereinbarten vertraglichen Laufzeiten nicht zu Wettbewerbsbeschränkungen führen dürfen (§ 2 Ziff. 1 Abs. (2) VOL/A). Softwarepflegeverträge dürfen daher nur mit angemessenen Laufzeiten vereinbart werden4. Kulartz/Steding verweisen dabei auf eine Entscheidung der 2. Vergabekammer des Bundes beim Bundeskartellamt, wonach eine Option auf Vertragsverlängerung bei einem Dauerschuldverhältnis5, welches bereits mit einer Laufzeit von fünf Jahren vereinbart worden war, geeignet ist, derartige Leistungen der – vom Gesetzgeber geforderten – Kontrolle durch den Wettbewerb mittels neuer Ausschreibung zu entziehen6, denn eine vertragliche Verlängerungsoption könnte eine einmal geschaffene Liefer- und Leistungsbeziehung unter Ausschluss des Wettbewerbs auf Dauer aufrechterhalten7. 1 Die Durchsetzbarkeit ist an § 242 BGB zu messen. 2 Schneider, Handbuch des EDV-Rechts, K. Rz. 184. 3 Bzw. Art. 81, 82 EG-Vertrag, falls der Handel zwischen Mitgliedstaaten betroffen ist. 4 Vgl. hierzu auch Kulartz/Steding, IT-Leistungen, Fehlerfreie Ausschreibungen und rechtssichere Vertragsinhalte, A II 2.3, S. 14 zu der Laufzeit von Dauerschuldverhältnissen. 5 Softwarepflegeverträge sind regelmäßig als Dauerschuldverhältnisse anzusehen, s. hierzu Bischof/Witzel, ITRB 2003, 31; Bartsch, NJW 2002, 1526; Marly, Praxishandbuch Softwarerecht, Rz. 1029; Schneider, Handbuch des EDV-Rechts, K. Rz. 49; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 1.12 Rz. 12. 6 Beschluss der 2. Vergabekammer des Bundeskartellamtes v. 26.5.2001 (VK 2-8/00). 7 Kulartz/Steding, IT-Leistungen, Fehlerfreie Ausschreibungen und und rechtssichere Vertragsinhalte, A II 2.3, S. 14.

Peter

923

I Rz. 310 310

Sonderregelungen

Es ist fraglich, ob bei Softwarepflegeverträgen, die im Weg der öffentlichen Vergabe zustandekommen, eine individuell vereinbarte Laufzeit von fünf Jahren dem vergaberechtlichen Nachprüfungsverfahren (§ 114 Abs. 1, Satz 1 GWB) standhält; siehe Kap. N Rz. 51 (vier Jahre) und § 3 Abs. 4e) EG VOL/A (drei Jahre). cc) Formularklauseln (1) Verbraucherverkehr

311

Fraglich und höchstrichterlich nicht entschieden ist, ob Softwarepflegeverträge mit einem Verbraucher dem Anwendungsbereich des § 309 Nr. 9 BGB unterfallen1. Sollte dies der Fall sein, ist eine den Verbraucher länger als zwei Jahre bindende Laufzeit des Vertrags mit § 309 Nr. 9 BGB nicht zu vereinbaren.

312

Diese zweijährige Laufzeitbegrenzung kann im Verbraucherverkehr nicht dadurch umgegangen werden, dass die AGB des Verwenders den Beginn der Laufzeit nicht an den Zeitpunkt des Vertragsabschlusses, sondern an einen späteren Zeitpunkt, z.B. an den Ablauf der Frist zur Mängelhaftung knüpfen; maßgeblich für die Berechnung der Zweijahresfrist ist allein der Zeitpunkt des Abschlusses des Pflegevertrags2.

313

Sollte sich der Softwareanbieter/-hersteller für eine Vertragsverlängerungsklausel entscheiden, ist § 309 Nr. 9b) BGB zu beachten, falls der Softwarepflegevertrag vom Anwendungsbereich des § 309 BGB erfasst ist. Jedenfalls dürfte im Rahmen von § 309 BGB die Klausel „Der Vertrag verlängert sich stillschweigend jeweils um ein Jahr, wenn er nicht form- und fristgerecht gekündigt wird.“ wirksam sein3. (2) Unternehmensverkehr

314

Bei der Verwendung einer Laufzeitklausel gegenüber einem Unternehmer (§ 14 BGB), gelten die Klauselverbote der §§ 308 und 309 BGB nicht; für die Inhaltskontrolle ist allein § 307 BGB maßgeblich, wobei auf die im Handelsverkehr geltenden Gewohnheiten und Gebräuche angemessen Rücksicht zu nehmen ist (§ 310 Abs. 1 Satz 2, 2. Halbs. BGB)4.

1 Zum Anwendungsbereich des § 309 Nr. 9 s. Palandt/Grüneberg, § 309 BGB Rz. 86. Vgl. OLG Koblenz v. 12.1.2005 – 1 U 1009/04, CR 2005, 84, das von einer grundsätzlichen Anwendbarkeit des § 309 Nr. 9a) BGB auf Softwarepflegeverträge ausgeht. 2 BGH v. 17.3.1993 – VIII ZR 180/92, MDR 1993, 733 = NJW 1993, 1651 zu einem Wartungsvertrag für Videogeräte; ausführlich hierzu Marly, Praxishandbuch Softwarerecht, Rz. 1040 ff. 3 BGH v. 4.12.1996 – XII ZR 193/95, MDR 1997, 225 = NJW 1997, 739 zu einer gleich lautenden Klausel in AGBs eines Fitness-Studios mit sechsmonatiger Vertragsverlängerung; vertiefend Marly, Praxishandbuch Softwarerecht, Rz. 1042. 4 Palandt/Grüneberg, § 310 BGB Rz. 5.

924

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 318 I

Ob eine im kaufmännischen Verkehr verwendete formularmäßige Klausel, 315 die eine zehnjährige oder längere Bindung des Vertragspartners an einen Wartungsvertrag über technische Anlagen beinhaltet, eine unangemessene Benachteiligung darstellt, ist im Schrifttum umstritten1. Im Zusammenhang mit einer gegenüber einem Unternehmer verwendeten formularmäßigen Laufzeitklausel von zehn Jahren über die Wartung einer Fernmeldeanlage hat der BGH unter Bezugnahme auf den vorgenannten Literaturstreit grundsätzlich entschieden, dass die Frage der unangemessenen Benachteiligung einzelfallbezogen zu betrachten ist. So führt der BGH aus2:

316

„Ob eine … Klausel den Vertragspartner des Verwenders … entgegen den Geboten von Treu und Glauben unangemessen benachteiligt, ist mit Hilfe einer umfassenden Abwägung der schützenswerten Interessen beider Parteien … festzustellen. Bei dieser Abwägung sind nicht nur die auf Seiten des Verwenders getätigten Investitionen, sondern der gesamte Vertragsinhalt zu berücksichtigen; notwendig ist eine Gegenüberstellung der insgesamt begründeten gegenseitigen Rechte und Pflichten. Dabei kann von einem Kaufmann bei Abschluss eines Wartungsvertrages über eine technische Anlage erwartet werden, dass er abschätzen kann, ob die Anlage während der gesamten Laufzeit des Vertrages seinen Bedürfnissen genügt. Bei der Vereinbarung von Laufzeiten von zehn Jahren und mehr ist andererseits zu berücksichtigen, dass es auf Seiten des Klauselverwenders in der Regel besonderer Umstände bedarf, die eine Laufzeit von zehn Jahren und mehr rechtfertigen können. Die Unangemessenheit einer derart langfristigen Bindung kann deshalb dann zu bejahen sein, wenn durch sie allein oder ihre Ausgestaltung die persönliche Selbständigkeit und Freiheit sowie ein Mindestmaß an wirtschaftlichem Bewegungsspielraum eines Vertragspartners so beschränkt werden, dass er dem Gegenüber auf Gedeih und Verderb ausgeliefert ist …“3

Darüber hinaus ist – aufgrund der weiteren Hinweise des BGH in der vorste- 317 henden Entscheidung – Folgendes auf die Softwarepflege zu übertragen: Enthält der Softwarepflegevertrag bei einer zehnjährigen Laufzeitbindung eine Preisanpassungsklausel, ohne dem Vertragspartner im Fall von Preiserhöhungen ein Lösungsrecht vom Vertrag einzuräumen, stellt eine Laufzeitbindung von zehn Jahren in jedem Fall eine unangemessene Benachteiligung dar. Die Bindungsfrist von zehn Jahren kann nicht mit der Erwägung gerechtfertigt werden, dass zur Erfüllung des Pflegevertrages Vorhaltekosten für Gerät, sonstiges Material und Personal anfallen4. Ob und inwieweit die vom Verwender eingegangenen Vorhaltekosten eine 318 zeitliche Bindung in diesem Umfang erfordern, wurde vom BGH mangels Vortrags der Parteien in dem entschiedenen Falle nicht überprüft.

1 Vgl. Strauß, NJW 1995, 697; Löwe, NJW 1995, 1726; s. auch Palandt/Grüneberg, § 309 BGB Rz. 96. 2 BGH v. 17.12.2002 – X ZR 220/01, MDR 2003, 617 = NJW 2003, 886. 3 BGH v. 17.12.2002 – X ZR 220/01, MDR 2003, 617 = NJW 2003, 886. 4 BGH v. 17.12.2002 – X ZR 220/01, MDR 2003, 617 = NJW 2003, 886 in Bezug auf den dort behandelten Wartungsvertrag.

Peter

925

I Rz. 319

Sonderregelungen

2. Kündigung 319

Zur Frage der Kündigung bei rechtlicher Einheit von Softwareüberlassung und Softwarepflege s. Rz. 124 ff. Zur Kündigungsmöglichkeit des Softwarepflegevertrages bei Wegfall des Softwareüberlassungsvertrags auf der einen Seite oder der Kündigungsmöglichkeit des Softwarepflegevertrages bei Wegfall des Softwareüberlassungsvertrages auf der anderen Seite, alles bei fehlender rechtlicher Einheit, s. Rz. 134 ff. Ein über Treu und Glauben (§ 242 BGB) herzuleitendes Verbot, den Softwarepflegevertrag vor Ablauf des Lebenszyklus’ der verkauften Software seitens des Softwareanbieters/-herstellers nicht ordentlich kündigen zu dürfen, ist nicht anzuerkennen (s. hierzu Rz. 60 ff.). a) Vertraglich vereinbarte Kündigung

320

Im Rahmen von Individualvereinbarungen setzt § 138 BGB die gestalterischen Grenzen1. Falls Softwarepflegeverträge dem Anwendungsbereich des § 309 Nr. 9 BGB unterfallen, ist in Bezug auf die Länge der verwendeten Kündigungsfrist Maß an § 309 Nr. 9c) BGB zu nehmen (s. hierzu Rz. 311 ff.): Danach ist in AGB eine Klausel unwirksam, die zu Lasten des anderen Vertragsteils eine längere Kündigungsfrist als drei Monate vor Ablauf der zunächst vorgesehenen oder stillschweigend verlängerten Vertragsdauer vorsieht. Strittig ist, ob ein Verstoß gegen § 309 Nr. 9c) BGB auch dann gegeben ist, wenn die Dreimonatsfrist zwar beachtet wurde, die Kündigung jedoch nur für vier oder weniger Termine im Jahr zugelassen wird2.

321

Zum Schluss sei bemerkt, dass Vereinbarungen über feste Laufzeiten dazu führen, dass sich die Vertragsparteien von dem Softwarepflegevertrag nicht ohne wichtigen Grund lösen können3; das Recht zur ordentlichen Kündigung, soweit es denn kraft Gesetzes im Einzelfall bestehen sollte4, ist mit einer entsprechenden Laufzeitvereinbarung abbedungen (zur Laufzeitvereinbarung s. Rz. 306 ff.).

1 Die Durchsetzbarkeit ist an § 242 BGB zu messen. 2 Bejahend Palandt/Grüneberg, § 309 BGB Rz. 93 mit Verweis auf AG Hamburg v. 26.5.1998 – 23a C 116-98, NJW-RR 1998, 1593; zustimmend auch Marly, Praxishandbuch Softwarerecht, Rz. 1045 mit Verweis auf Ulmer/Brander/Hensen, § 309 BGB Nr. 9 Rz. 16; a.A. AG Gütersloh v. 7.4.1983 – 15 C 13/83, MDR 1984, 404. 3 OLG Köln v. 17.7.1998 – 19 U 9/98, CR 1998, 720; Strauß, NJW 1995, 697. 4 Nach Marly, Praxishandbuch Softwarerecht, Rz. 1044 dürfte die Vertragsauslegung regelmäßig zu einer Anwendbarkeit der dienstvertragsrechtlichen Kündigungsvorschriften führen; vgl. hierzu auch Welker/Schmidt, CR 2002, 873.

926

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 326 I

b) Kündigungsrecht des Softwareanwenders nach § 649 BGB Bei Werkverträgen gibt § 649 BGB dem Besteller das Recht, bis zur Voll- 322 endung des Werks den Vertrag zu kündigen. In diesem Fall ist der Unternehmer berechtigt, die vereinbarte Vergütung zu verlangen, wobei er sich insbesondere die durch die Aufhebung des Vertrags ersparten Aufwendungen auf seinen Vergütungsanspruch anrechnen lassen muss (Einzelheiten s. § 649 BGB). § 649 BGB enthält ein sogenanntes „freies“ Kündigungsrecht1, welches der Besteller nach eigenem Ermessen und ohne Angabe von Gründen jederzeit bis zur Vollendung des Werks geltend machen kann.

323

aa) Anwendbarkeit des § 649 BGB auf den Softwarepflegevertrag Es wird in der Literatur überwiegend angenommen, dass § 649 BGB bei 324 Dauerschuldverhältnissen überhaupt nicht – auch nicht analog – anzuwenden ist, weil § 649 BGB für Dauerschuldverhältnisse nicht passt, was auch in der Rechtsprechung der Instanzgerichte Anklang gefunden hat2. Als Konsequenz hierzu wird z.B. ausgeführt, dass § 649 BGB zumindest als stillschweigend abbedungen gelten muss3. Stattdessen soll bei einem Softwarepflegevertrag für beide Vertragsparteien die Möglichkeit einer ordentlichen, an die Einhaltung einer angemessenen Frist gebundenen Kündigung des Vertrags nach Dienstvertragsrecht bestehen4. Hierzu hat der BGH in seiner Entscheidung Internet-System-Vertrag 2 zu- 325 sammengefasst wie folgt Stellung genommen: Haben die Vertragsparteien den Ausschluss des § 649 BGB nicht wirksam vereinbart und kann sich der Kündigungsgegner nicht auf § 242 BGB berufen, kann sich im Weg der ergänzenden Vertragsauslegung allein aus der Besonderheit, dass der Vertrag auf unbestimmte Zeit geschlossen wurde, kein Ausschluss des Kündigungsrechts nach § 649 Satz 1 BGB ergeben5. Jedoch hat der BGH in seiner Entscheidung betont, dass sehr wohl Beson- 326 derheiten vorliegen können, die bei ergänzender Vertragsauslegung zu einem Ausschluss des Kündigungsrechts nach § 649 Satz 1 BGB führen können. Hierzu erklärt der BGH: „… Sie (die Besonderheiten; Anm. Verf.) können mit Rücksicht auf den Regelungsgehalt des § 649 BGB und den 1 MüKo/Busche, § 649 Rz. 1. 2 Redeker, IT-Recht, Rz. 662 f.; Marly, Praxishandbuch Softwarerecht, Rz. 1044; MüKo/Busche, § 649 Rz. 4, 31; OLG Hamburg, MDR 1972, 866 (Gebäudereinigungsvertrag); OLG Düsseldorf v. 15.10.1996 – 23 U 27/96, juris – Sukzessivwerkvertrag über Dekorationsarbeiten; LG Berlin v. 6.6.1984, CR 1986, 772 (Leitsatz – Computerwartung). A.A. Schweyer, Anm. zu Urteil des AG Hamburg v. 4.10.1988 – 35 C 444/88, CR 1989, 1102. 3 Marly, Praxishandbuch Softwarerecht, Rz. 1044. 4 LG Berlin v. 6.6.1984, CR 1986, 772 (Leitsatz – Computerwartung); Marly, Praxishandbuch Softwarerecht, Rz. 1044. 5 BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176.

Peter

927

I Rz. 327

Sonderregelungen

vom Gesetzgeber mit dieser Vorschrift verfolgten Zweck vielmehr nur dann vorliegen, wenn der Unternehmer über die Realisierung seines Vergütungsanspruchs hinaus ein berechtigtes Interesse an der Ausführung der Vertragsleistung hat, welches durch eine jederzeitige freie Kündigung des Vertrages in einer Weise beeinträchtigt werden würde, die hinzunehmen ihm nicht zugemutet werden kann …“1. 327

Wie unter Rz. 462 ff. ausgeführt, handelt es sich bei dem Softwarepflegevertrag grundsätzlich um einen typengemischten Vertrag, dessen Leistungen im Weg eines Dauerschuldverhältnisses erbracht werden. Dabei ist die Feststellung der vertraglichen Typisierung einzelfallabhängig, je nachdem, nach welcher rechtlichen Theorie die Typisierung des Softwarepflegevertrags unter Berücksichtigung der Rechtsprechung des BGH zu erfolgen hat (s. hierzu Rz. 462 ff.), und ob der Softwarepflegevertrag eher „erfolgsorientiert“ oder „tätigkeitsorientiert“ ausgestaltet ist.

328

Ist der Softwarepflegevertrag „tätigkeitsorientiert“ ausgestaltet und findet danach insgesamt Dienstvertragsrecht Anwendung, ist für die hier dargestellte Problematik zum Ausschluss des Kündigungsrechts nach § 649 BGB kein Raum, da Werkvertragsrecht keine Rolle spielt.

329

Ist der Softwarepflegevertrag hingegen „erfolgsorientiert“ ausgestaltet und findet danach insgesamt oder auf seine erfolgsorientierten Vertragsteile das Werkvertragsrecht Anwendung, bleibt die Frage der Anwendbarkeit des § 649 BGB zu klären und muss eine Auseinandersetzung mit den zuvor gezeichneten Vorgaben des BGH erfolgen, falls das Kündigungsrecht des § 649 S. 1 BGB nicht vertraglich wirksam abbedungen wurde (s. hierzu Rz. 338 ff.).

330

Zusammenfassend lässt sich zu den Vorgaben des BGH mithin herausstellen: Solange der in Satz 2 des § 649 BGB verankerte Vergütungsanspruch die Interessen des Softwareanbieters im Einzelfall im ausreichenden Maße abdeckt, gibt es keinen Grund, dem Softwareanbieter das Recht auf Kündigung nach § 649 BGB zu verwehren. Der BGH stellt dabei das wirtschaftlich-kommerzielle Interesse des (Werk-)Unternehmers in den Vordergrund; er führt hierzu aus: „… Diese Vertragsgestaltung ist darauf gerichtet, eine etwa für möglich gehaltene, fristgebundene ordentliche Kündigung zu verhindern, um das Interesse der Klägerin an der Erfüllung des Vertrages zu sichern. Dieses Interesse besteht darin, ihr den Vergütungsanspruch für die gesamte Vertragslaufzeit zu erhalten, damit sich ihre Aufwendungen für die Durchführung des Vertrages amortisieren. Eine freie Kündigung gem. § 649 Satz 1 BGB lässt dieses Interesse unberührt. Dem Unternehmer steht nach § 649 Satz 2 BGB die Vergütung abzgl. der ersparten Aufwendungen und anderweitigen Erwerbs zu. Er wird wirtschaftlich dadurch so gestellt, als wäre der Vertrag erfüllt. Es ist deshalb nach objektivem Verständnis kein Grund 1 BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176 mit Verweis auf BGH v. 21.11.1985 – VII ZR 366/83, BGHZ 96, 275 = MDR 1986, 399 für die Kündigung des die Errichtung des Baus betreffenden Teils eines Bauträgervertrages.

928

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 334 I

erkennbar, warum der Unternehmer mit der von ihm gewählten Vertragsgestaltung das freie Kündigungsrecht des Bestellers nach § 649 Satz 1 BGB hat ausschließen wollen. …“1. Oder anders gewendet: Sollte der Softwareanbieter trotz des in § 649 Satz 2 331 BGB verankerten Vergütungsanspruchs wirtschaftlich nicht so gestellt werden können, als wäre der Vertrag erfüllt, um sein wirtschaftlich-kommerzielles Interesse in dem vom BGH gezeichneten Sinne zu erfüllen, hat er damit das berechtigte Interesse an der Ausführung der Vertragsleistung, so dass dem Softwareanbieter die jederzeitige freie Kündigung des Softwarepflegevertrags durch den Softwareanwender nicht zugemutet werden kann. § 649 BGB findet in einem solchen Falle im Wege der ergänzenden Vertragsauslegung keine Anwendung. Unter diesen Prämissen dürfte die Feststellung solcher zu berücksichtigen- 332 der Besonderheiten maßgeblich davon abhängen, ob es sich bei dem Softwarepflegevertrag um die entgeltliche Softwarepflege einer einzelnen, für einen gesonderten Softwareanwender individuell erstellten Software handelt oder um die entgeltliche Pflege von Standardsoftware, die für eine unbestimmte Vielzahl von Softwareanwendern erfolgt. Im Fall der Pflege einer Individualsoftware für einen einzelnen Software- 333 anbieter dürfte es schwierig sein, zu Gunsten des Softwareanbieters ein berechtigtes Interesse an der Ausführung der Vertragsleistung festzustellen, die die Anwendbarkeit des § 649 BGB ausschließt. Bei der Pflege einer Individualsoftware kann und muss der Softwareanbieter seine allein für dieses Softwarepflegeprojekt anzusetzenden Kosten und die mit diesem Projekt zu erzielenden Erträge betriebswirtschaftlich beurteilen und festlegen. Die in dem Projekt arbeitenden Mitarbeiter oder Subunternehmer des Softwareanbieters werden für den Zeitraum dieses Softwarepflegeprojekts gebunden und können danach ohne Weiteres wieder in einem anderen Softwarepflegeprojekt eingesetzt werden. Auf den sich immer wieder anschließenden Projektwechsel ist dieses Geschäftsmodell sogar angelegt, so dass der Softwareanbieter ständig damit betraut ist, immer wieder neue Individualsoftwareprojekte zu akquirieren. Etwaige für das individuelle Softwarepflegeprojekt getätigte Investitionen, die sich über die Laufzeit des Softwarepflegeprojekts amortisieren sollten, erhält der Softwareanbieter über seinen Vergütungsanspruch nach § 649 Satz 2 BGB ersetzt. Aufgrund der Beendigung des Vertrags nicht getätigte Aufwendungen spart 334 der Softwareanbieter und erhält diese mithin auch nicht über § 649 Satz 2 BGB ersetzt. Anhaltspunkte dafür, dass dem Softwareanbieter über dieses Vergütungsinteresse hinaus daran gelegen sein muss, seine vertraglichen Leistungen bis zum Ende der vereinbarten Vertragslaufzeit erbringen zu dürfen, sind eher nicht ersichtlich.

1 BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176.

Peter

929

I Rz. 335

Sonderregelungen

335

Anders dürfte sich dies im Fall der entgeltlichen Pflege von Standardsoftware für eine unbestimmte Anzahl von Anwendern darstellen. Der Softwareanbieter muss zu diesem Zweck eine eigene Abteilung vorhalten, die ständig damit betraut ist, die Pflegeleistungen für die Anwenderschaft zu erbringen. Dieses Geschäftsmodell beinhaltet die unbedingte Erzielung sog. „Skaleneffekte“ in der Form, dass erst ab einer bestimmten Anzahl von Kunden (vertraglich gebundene Softwareanwender), die im Laufe einer gewissen Zeit nach und nach akquiriert werden und die für die Leistungen über eine feste Laufzeit (Mindestvertragslaufzeit) bezahlen, der Softwareanbieter einen betriebswirtschaftlichen Gewinn erreicht. Die Zeit bis zum Erreichen der „kritischen Masse“ muss der Unternehmer vorfinanzieren und diese Kosten auf alle Kunden umlegen. Die eingesetzten Mitarbeiter oder Subunternehmer des Softwareanbieters müssen sich auf unbestimmte, zumindest über eine längere Zeit mit der Pflege dieser Standardsoftware befassen, um die erforderlichen betriebswirtschaftlichen Gewinne dauerhaft zu erzielen, und können daher nicht ohne Weiteres jederzeit andere Aufgaben übernehmen. Das Geschäftsmodell ist darauf ausgelegt, dauerhaft, zumindest über einen längeren Zeitraum, für eine konkrete Standardsoftware Pflegeleistungen zu erbringen. Der Vergütungsanspruch des § 649 Satz 2 BGB hilft dem Softwareanbieter hier nicht: Wenn alle Softwareanwender den Softwarepflegevertrag nach § 649 Satz 1 BGB jederzeit kündigen dürfen, ist das hier aufgeführte Geschäftsmodell betriebswirtschaftlich nicht erfolgreich durchführbar. Es ist dem Unternehmer nicht zuzumuten, im Kündigungsfall die Kalkulation seines Geschäftsmodells offenzulegen, um dem Kündigenden den auf ihn entfallenden kalkulatorischen Anteil der Gesamtkosten darzulegen1. Außerdem wird mit einer zu großen Wahrscheinlichkeit die „kritische Masse“ der vertraglich zu bindenden Kunden (Softwareanwender) möglicherweise nicht erreicht oder kann über einen vernünftigen Zeitraum hin nicht gehalten werden. Dadurch verfällt dieses Geschäftsmodell quasi auf „Wettniveau“ und darf von einem sorgfältigen Kaufmann weder initiiert noch weiterverfolgt werden, da es ein nicht mehr kalkulierbares Risiko für seinen Unternehmenserfolg darstellt (vgl. hierzu Rz. 26).

336

Hier ist der Softwareanbieter darauf angewiesen, seine vertraglichen Leistungen bis zum Ende der vereinbarten Vertragslaufzeit erbringen zu dürfen, damit er dieses Geschäftsmodell betriebswirtschaftlich erfolgreich umsetzen kann. Damit steht dem Softwareanbieter ein berechtigtes Interesse an der Ausführung der Vertragsleistung zu, die die Anwendbarkeit des § 649 BGB ausschließt.

1 Der Verrat von Geschäftsmodell-Kalkulationen eines Unternehmers (Business Cases) ist über § 17 UWG sogar strafrechtlich geahndet; vgl. hierzu statt aller: Köhler, in: Köhler/Bornkamm, UWG § 17 Rz. 17 – Kalkulationsunterlagen sind Geschäfts- und Betriebsgeheimnisse mit Verweis auf OLG Stuttgart GRUR 1982, 315.

930

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 341 I

Abschließend ist nach alledem festzuhalten: Ist das Kündigungsrecht des Softwareanwenders nach § 649 Satz 1 BGB nicht wirksam abbedungen, ist im Fall der entgeltlichen Pflege von Standardsoftware für eine unbestimmte Anzahl von Softwareanwendern von einem Ausschluss des Kündigungsrechts nach § 649 Satz 1 BGB im Weg der ergänzenden Vertragsauslegung auszugehen.

337

bb) Abdingbarkeit des § 649 BGB Wie der BGH bereits betont hat (s. Rz. 325), kann die Anwendbarkeit des 338 § 649 BGB in den Grenzen des § 138 BGB individualvertraglich wirksam abbedungen werden1. Dies ist bereits aus dem Grund richtig und nachvollziehbar, dass den Vertragsparteien bei Dauerschuldverhältnissen immer das außerordentliche Kündigungsrecht aus wichtigem Grund nach § 314 BGB verbleibt (s. hierzu Rz. 346 ff.). Fraglich ist, ob das Kündigungsrecht des § 649 Satz 1 BGB in AGB wirksam abbedungen werden kann2. Ob ein solcher Ausschluss formularmäßig wirksam vereinbart werden kann, hat der BGH in der Entscheidung InternetSystem-Vertrag 2 nicht beurteilen müssen3.

339

Im Zusammenhang mit einem Bauvertrag über die Errichtung eines Ein- 340 familienhauses hat der BGH entschieden, dass der Ausschluss des in § 649 Satz 1 BGB geregelten freien Kündigungsrechts des Auftraggebers unwirksam ist4. Hierzu hatte der BGH ausgeführt, dass ein solcher Ausschluss den Auftraggeber unangemessen benachteiligt, weil die Klausel mit wesentlichen Grundgedanken der gesetzlichen Regelung des § 649 Satz 1 BGB nicht zu vereinbaren ist5: „… Nach § 649 Satz 1 BGB hat der Auftraggeber jederzeit das Recht, einen Werkvertrag zu kündigen. Dieser hat vorzugsweise Interesse an der Ausführung des Werks und soll deshalb die Möglichkeit einer Lösung vom Vertrag für den Fall erhalten, dass das Interesse wegfällt. Diese grundsätzliche Wertung des Gesetzgebers hat vor allem auch bei langfristig angelegten Werkverträgen, wie bei Bau- oder Architektenverträgen, ihre Berechtigung. Denn es können sich insbesondere bei diesen Vertragstypen nachträglich Umstände ergeben, die die ursprüngliche Entscheidung des Auftraggebers, das Werk in Auftrag zu geben, in Frage stellen. Der Auftragnehmer ist nach der Wertung des Gesetzes durch die Regelung des § 649 Satz 2 BGB ausreichend geschützt. …“6 Bei einer Entscheidung des OLG Oldenburg ging es um die Frage, ob mit ei- 341 ner festen Laufzeitvereinbarung das Kündigungsrecht nach § 649 Satz 1 1 BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176; OLG Oldenburg, v. 5.11.2009 – 14 U 61/09, NJW-RR 2010, 1030. 2 Streitig, s. hierzu Palandt/Sprau, § 649 BGB Rz. 16. 3 BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176. 4 BGH v. 8.7.1999 – VII ZR 237/98, NJW 1990, 3261. 5 BGH v. 8.7.1999 – VII ZR 237/98, NJW 1990, 3261. 6 BGH v. 8.7.1999 – VII ZR 237–98, NJW 1990, 3261.

Peter

931

I Rz. 342

Sonderregelungen

BGB automatisch formularmäßig ausgeschlossen ist1. Diese Frage hat das OLG Oldenburg dahingehend beantwortet, dass allein mit einer festen Laufzeitvereinbarung ein zugleich erklärter Ausschluss des Kündigungsrechts nach § 649 Satz 1 BGB nicht festgestellt werden kann; mithin stellte sich gar nicht mehr die Frage, ob ein Ausschluss dieses Kündigungsrechts formularmäßig wirksam vereinbart werden kann2. 342

Nach alledem spricht zunächst nichts dagegen, die vorgenannten Wertungen des BGH grundsätzlich auf Dauerschuldverhältnisse, mithin auch auf Softwarepflegeverträge zu übertragen, wenn diese erfolgsorientiert ausgestaltet sind.

343

Danach dürfte im Fall der Pflege einer Individualsoftware für einen einzelnen Softwareanwender, der formularmäßige Ausschluss des Kündigungsrechts nach § 649 Satz 1 BGB sowohl im Verbraucher-, als auch im Unternehmensverkehr für unwirksam zu erachten sein, § 307 Abs. 2, Nr. 1 BGB, denn die Interessen des Auftragnehmers sind durch den Vergütungsanspruch nach § 649 Satz 2 BGB ausreichend geschützt (s. Rz. 333 f.).

344

Anders stellt sich dies im Fall der entgeltlichen Pflege von Standardsoftware für eine unbestimmte Anzahl von Softwareanwendern – sei es im Verbraucher- wie auch im Unternehmensverkehr – dar: Wie zuvor ausgeführt (s. Rz. 335 f.), hilft hier dem Auftragnehmer der Vergütungsanspruch nach § 649 Satz 2 BGB nicht. Der Softwareanbieter ist bei diesem Geschäftsmodell durch die Regelung des § 649 Satz 2 BGB gerade nicht ausreichend geschützt. Auch ist es dem Softwareanbieter nicht zuzumuten, mit jedem Softwareanwender einen Individualvertrag auszuhandeln und abzuschließen. Dieses Geschäftsmodell ist bereits im Kern der Sache auf ein sog. Massenmodell ausgerichtet: Der Softwareanbieter ist mithin darauf angewiesen, seine vertraglichen Kundenbeziehungen mit formularmäßig verwendeten Verträgen, d.h. AGB, abzubilden. Die einzige Alternative wäre es, dieses Geschäftsmodell gar nicht umzusetzen und mithin auch keinem Softwareanwender ein Angebot auf Abschluss eines Softwarepflegevertrags zu unterbreiten. Die Folge davon wäre, dass die Anwenderschaft keinerlei Softwarepflege erhielte, obschon sie sich die Standardsoftware angeschafft hat. Dies wäre unzweifelhaft ebenfalls nicht im Interesse der Anwenderschaft.

345

Der formularmäßige Ausschluss des Kündigungsrechts nach § 649 Satz 1 BGB im Fall der entgeltlichen Pflege von Standardsoftware für eine unbestimmte Anzahl von Softwareanwendern stellt daher – weder im Verbraucher-, noch im Unternehmensverkehr – eine unangemessene Benachteiligung des Softwareanwenders dar (§ 307 BGB). Bei diesem Geschäftsmodell kann das Kündigungsrecht des § 649 Satz 1 BGB formularmäßig in AGB wirksam ausgeschlossen werden. 1 OLG Oldenburg, v. 5.11.2009 – 14 U 61/09, NJW-RR 2010, 1030. 2 OLG Oldenburg, v. 5.11.2009 – 14 U 61/09, NJW-RR 2010, 1030.

932

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 349 I

c) Außerordentliche Kündigung Ausgehend von der Annahme, dass es sich beim Softwarepflegevertrag um 346 ein Dauerschuldverhältnis handelt1, ist eine Kündigung aus wichtigem Grund grundsätzlich möglich; die Tatbestandsvoraussetzungen richten sich nach § 314 BGB. Ein Teil der Literatur hält den Softwarepflegevertrag als Dauerschuldver- 347 hältnis mit dem Mietrecht für vergleichbar und diskutiert vor diesem Hintergrund die Anwendung des § 543 Abs. 2 Nr. 3 BGB2. Diese Vorschrift kann jedoch nur dann unmittelbar zur Anwendung gelangen, wenn die Leistungspflichten des in Rede stehenden Softwarepflegevertrags ausschließlich dem Mietrecht zuzuordnen sind. Im Fall einer Typenmischung (s. hierzu Rz. 462 ff.) dürfte nach der in Rechtsprechung und Lehre vorherrschenden Interessentheorie vorzugehen sein (s. hierzu Kap. G Rz. 116 f.)3; über diesen Weg könnte es im Einzelfall zu einer Anwendung der besagten mietrechtlichen Vorschrift kommen. Eine analoge Anwendung des § 543 Abs. 2 Nr. 3 BGB auf Dauerschuldverhältnisse erscheint durch die Einfügung des § 314 BGB im Rahmen der Schuldrechtsmodernisierung schwerlich begründbar, denn § 543 Abs. 2 Nr. 3 BGB behandelt besondere Fälle von vertraglichen Pflichtverletzungen. § 314 BGB enthält hierzu eine Sonderregelung in dessen Abs. 2, so dass eine planwidrige Lücke im Gesetz wohl nicht auszumachen sein dürfte. Das Kündigungsrecht aus wichtigem Grund kann durch AGB nicht ausgeschlossen werden, § 307 Abs. 2 Nr. 1 BGB4.

348

Die wichtigen Gründe können jedoch – in engen Grenzen – formularmäßig 349 definiert werden, solange die Kündigungsmöglichkeiten nach § 314 BGB weder ausgeschlossen noch eingeschränkt werden5. Beschränkungen dieses Kündigungsrechts sind allenfalls mittels Individualvereinbarungen möglich, jedoch nur in engen Grenzen und ohne das Kündigungsrecht nach § 314 BGB völlig auszuschließen6.

1 Bischof/Witzel, ITRB 2003, 31; Bartsch, NJW 2002, 1526; Marly, Praxishandbuch Softwarerecht, Rz. 1029; Schneider, Handbuch des EDV-Rechts, K. Rz. 49; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kapitel 1.12 Rz. 12. 2 Schneider, Handbuch des EDV-Rechts, K. Rz. 270a. 3 MüKo/Emmerich, § 311 BGB BGB Rz. 46, Palandt/Grüneberg, Überbl. vor § 311 BGB Rz. 25. 4 Palandt/Grüneberg, § 309 BGB Rz. 93 und Palandt/Grüneberg, § 314 BGB Rz. 3, jeweils mit Verweis auf BGH v. 26.5.1986 – VIII ZR 218/85, NJW 1986, 3134 = ZIP 1986, 920. 5 Marly, Praxishandbuch Softwarerecht, Rz. 1043 mit Beispielen; wohl auch Schreibauer/Taraschka, CR 2003, 557. 6 Palandt/Grüneberg, § 314 BGB Rz. 3.

Peter

933

I Rz. 350

Sonderregelungen

d) End-of-Life-Schreiben und Rechtsmissbrauch 350

Es ist eine unternehmerische Entscheidung des Softwareherstellers, ein bestimmtes Softwareprodukt auslaufen zu lassen, dessen Pflege alsbald einzustellen und seine Kapazitäten in die Entwicklung und den Vertrieb neuer Produkte zu stecken. Mit den sog. End-of-Life-Schreiben kündigen die Softwareanbieter/-hersteller ihre beabsichtigte Vorgehensweise den Softwareanwendern gegenüber an1.

351

In diesem Zusammenhang gilt: Beinhaltet das End-of-Life-Schreiben die Aussage, ab einem bestimmten Zeitpunkt für ein bestimmtes Softwareprodukt keine Pflegeleistungen mehr erbringen zu wollen, kann dies als Kündigungserklärung ausgelegt werden2.

352

Ist das End-of-Life-Schreiben hingegen so gefasst, dass ein Rechtsbindungswille nicht festgestellt werden kann, z.B. dann, wenn lediglich zum Ausdruck gebracht wird, über eine Pflegeeinstellung noch gesondert zu entscheiden und diese Entscheidung sodann den Softwareanwendern explizit mitteilen zu wollen, dürfte für eine Kündigung im Rechtssinne kein Raum sein3.

353

Die Kündigung soll das Schuldverhältnis für die Zukunft beenden4, was die kündigende Vertragspartei dadurch zum Ausdruck bringt, dass sie mitteilt, ab einem bestimmten Zeitpunkt (das kann auch der Zugang der Kündigungserklärung sein) keine Leistungen aus dem Schuldverhältnis mehr erbringen zu wollen und deshalb – bei gegenseitigen Rechtsgeschäften – keine Gegenleistung mehr erwartet.

354

Geht die Kündigungserklärung dem Erklärungsempfänger zu und sind etwaige vertraglich vereinbarte Formerfordernisse eingehalten, stellt sich nur noch die Frage, ob die Kündigung – nach den vertraglichen oder gesetzlichen Bestimmungen – zulässig sowie einredefrei ist.

355

Ergänzend sei bemerkt: Sind keine vereinbarten Formerfordernisse festzustellen, kann die Veröffentlichung des End-of-Life-Schreibens auf der Website des Softwareanbieters dem Softwareanwender zu dem Zeitpunkt zugehen, wenn er die Website abruft; ebenfalls ist der Zugang per E-Mail rechtlich möglich. Dabei dürfte es nicht darauf ankommen, ob der Softwareanbieter sein End-of-Life-Schreiben an die Allgemeinheit richtet, wenn nur klar herauskommt, dass er sich zumindest auch an alle seine Vertragspartner wendet.

1 Ausführlich hierzu Welker/Schmidt, CR 2002, 873; vgl. auch Schneider, CR 2004, 241. 2 Welker/Schmidt, CR 2002, 873. 3 Welker/Schmidt, CR 2002, 873. 4 Palandt/Grüneberg, Einf. vor § 346 BGB Rz. 12.

934

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 361 I

Das – zunächst rein tatsächliche – Problem besteht für den Softwareanbie- 356 ter vielmehr darin, den Nachweis über den Zugang der Kündigungserklärung führen zu können. Zur Einrede des Rechtsmissbrauchs ist festzustellen: Ein über Treu und 357 Glauben (§ 242 BGB) herzuleitendes Verbot, den Softwarepflegevertrag vor Ablauf des Lebenszyklus’ der verkauften Software seitens des Softwareanbieters/-herstellers ordentlich kündigen zu dürfen, ist nicht anzuerkennen (s. hierzu Rz. 60 ff.). Für die Annahme eines Rechtsmissbrauchs müssen daher andere Umstände vorliegen1.

IX. Art und Umfang der Pflegeleistung 1. Fernpflege, Erfüllungsort und Datenschutz a) Fernpflege/Erfüllungsort Aufgrund des technischen Fortschritts in der Datenkommunikation und 358 bei der Datenübertragung müssen ausgewählte Pflegeleistungen nicht zwingend vor Ort beim Softwareanwender durchgeführt werden2. Das Einspielen von Programmkorrekturen erfolgt oft mittels sog. Fernpflege3. Die BVB-Pflege4 sahen zur Fernpflege noch keine Bestimmungen vor, da an diese Möglichkeit bei der Erarbeitung der BVB-Pflege nicht gedacht wurde5.

359

Dies wurde mit den ergänzenden Vertragsbedingungen für die Pflege von 360 Standardsoftware (EVB-IT Pflege S)6 geändert: Nr. 2.4 EVB-IT Pflege S sieht nunmehr die Vereinbarung sog. Teleserviceleistungen aufgrund einer gesondert abzuschließenden Teleservicevereinbarung ausdrücklich vor. Teleserviceleistungen sind nach den Begriffsbestimmungen der EVB-IT Pfle- 361 ge S Pflegeleistungen, die mittels vereinbarter Kommunikationseinrichtungen und geeigneter Kommunikationsdienste von einem entfernten Ort aus erbracht werden und für die der Auftraggeber die notwendigen Infrastruktureinrichtungen (Leitungen, Modems) vorhält. Gemäß Ziff. 2.4 EVB-IT Pflege S hat der Auftraggeber hierfür nicht nur die notwendigen Einrichtun1 Zur Problematik sog. „taktischer“ Kündigungen des Softwareanbieters im Zusammenhang mit der Jahr-2000-Thematik vgl. Jaeger, CR 1999, 209; OLG Koblenz v. 27.5.1993 – 5 U 1938/92, CR 1993, 626 (Kündigung für Upgrade-Ergänzungsvergütung). 2 Zahrnt, Computervertragsrecht, Kap. 14 14.1 (2.3) Fernpflege; Habel, CR 1993, 55; Hentschel, CR 1989, 568; Apitzsch, CR 1988, 432. 3 S. hierzu auch LG Cottbus v. 28.8.2003 – 4 O 361/02, CR 2004, 260; Schneider, Handbuch des EDV-Rechts, K. Rz. 164. 4 Besondere Vertragsbedingungen für die Pflege von DV-Programmen der öffentlichen Auftraggeber: http://www.cio.bund.de. 5 Hentschel, CR 1989, 568. 6 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware der öffentlichen Auftraggeber.

Peter

935

I Rz. 362

Sonderregelungen

gen bereitzustellen, sondern auch den Zugriff auf das System zu ermöglichen. 362

Die Einzelheiten hierzu enthält die Teleservicevereinbarung: „… beschreibt die technischen und organisatorischen Regelungen für die Durchführung von Pflegearbeiten mittels Telekommunikationsdienste über Netzwerke.“1

363

Außerdem sollte die Teleservicevereinbarung zusätzliche Vereinbarungen über sinnvolle technische Sicherheitsvorkehrungen auf Seiten des Softwareanbieters beinhalten, um dem Sicherheitsbedürfnis des Softwareanwenders nachzukommen2. Z.B. soll damit u.a. das Einspielen von Computerviren unterbunden werden.

364

Letztlich sehen die EVB-IT Pflege S in Ziff. 9 explizit die Möglichkeit vor, gesonderte Vereinbarungen zum Erfüllungsort zu treffen. Demgemäß ist neben der Fernpflege auch ein sog. Vor-Ort-Service/In-House-Service möglich, mithin die unmittelbare Leistungserbringung in den (Geschäfts-)Räumen des Softwareanwenders. b) Datenschutz

365

In beiden Fällen – Fernpflege und Vor-Ort-Service/In-House-Service – ist es generell möglich, dass der Softwareanbieter mit personenbezogenen Daten nach BDSG, Sozialdaten nach SGB oder Daten, die nach dem StGB besonderer Geheimhaltung unterliegen („Privatgeheimnisse“), in Berührung kommen kann (nachfolgend auch „sensible Daten“ genannt). Zwar ist die Softwarepflege nicht auf den Umgang mit sensiblen Daten gerichtet, allerdings ist die Kenntnisnahme nicht immer ausgeschlossen.

366

Mit Ziff. 14.1 und 14.2 EVB-IT Pflege S wird versucht, den Kontakt des Softwareanbieters (Auftragnehmer) zu geschützten Daten des Softwareanwenders (Auftraggeber) zu vermeiden3. Die BVB-Pflege sieht hierzu keine entsprechenden Regelungen vor.

367

§ 11 BVB-Pflege und Ziff. 14.3 EVB-IT Pflege S geben darüber hinaus lediglich vor, dass der Auftragnehmer (Softwareanbieter) dafür sorgen möge, dass alle Personen, die von ihm mit der Bearbeitung oder Erfüllung des Vertrages betraut sind, die gesetzlichen Bestimmungen über den Datenschutz beachten.

1 Begriffsbestimmungen, in „Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware“ – EVB-IT Pflege S. 2 Intveen, ITRB 2001, 163 (164) IV. 4. (Fernwartung). 3 Ziff. 14.1 lautet: „Der Auftraggeber sorgt dafür, dass dem Auftragnehmer alle relevanten, über die gesetzlichen Regelungen hinausgehenden Sachverhalte, deren Kenntnis für ihn aus Gründen des Datenschutzes und der Geheimhaltung erforderlich ist, bekannt gegeben werden.“ Ziff. 14.2 lautet: „Vor Übergabe eines Datenträgers an den Auftragnehmer stellt der Auftraggeber die Löschung schutzwürdiger Inhalte sicher, soweit nichts anderes vereinbart ist.“

936

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 373 I

Die Regelungen in den BVB-Pflege und den EVB-IT Pflege S sind jedoch nicht ausreichend, soweit sensible Daten in Frage stehen.

368

§ 203 StGB schützt das unbefugte Offenbaren von Privatgeheimnissen (ein 369 zum persönlichen Lebensbereich gehörendes Geheimnis oder ein Betriebsoder Geschäftsgeheimnis) durch sog. Berufsgeheimnisträger (z.B. Rechtsanwalt, Arzt, aber z.B. auch Angehörige einer privaten Krankenversicherung) mit der Androhung von Freiheits- oder Geldstrafe. Wenn der Betroffene selbst (z.B. der Mandant, der Patient), also nicht der Berufsgeheimnisträger, in die Offenbarung seines Geheimnisses – inklusive der Offenbarung im Rahmen der Tätigkeiten des Softwareanbieters – einwilligt, dürfte ein Verstoß gegen § 203 StGB zu vermeiden sein. Es ist also immer und unbedingt zu prüfen, ob mit der Erbringung von Softwarepflegeleistungen eine Berührung mit Privatgeheimnissen i.S.d. § 203 StGB verbunden sein kann, was im Zusammenhang mit entsprechenden Leistungen z.B. für Krankenhäuser nicht unwahrscheinlich ist.

370

Es ist vor allem durch den Softwareanwender (Auftraggeber) sicherzustel- 371 len, dass kein Verstoß gegen § 203 StGB möglich ist: Entweder sind vorher die entsprechenden Einwilligungen der Betroffenen einzuholen, was sich jedoch im Einzelfall z.B. aufgrund der Anzahl der Betroffenen als nicht umsetzbar herausstellen kann. Oder es ist zu prüfen, ob etwaige spezialgesetzliche Erlaubnisregelungen1 das Offenbaren ohne vorherige Einwilligung der Betroffenen rechtswirksam zulassen. Soweit spezialgesetzliche Erlaubnisregelungen zusätzliche Anforderungen aufstellen, die vertraglich umgesetzt werden müssen, müssen diese vorab zwischen dem Softwareanwender und dem Softwareanbieter zusätzlich zu den BVB-Pflege bzw. EVB-IT Pflege S vereinbart werden. Falls weder die erforderlichen Einwilligungen der Betroffenen, noch etwaige 372 spezialgesetzliche Erlaubnisregelungen vorliegen, ist das Offenbaren von Privatgeheimnissen an den Softwareanbieter strafrechtlich verboten. Das strafrechtliche Verbot richtet sich nicht nur an den Berufsgeheimnisträger als Auftraggeber (Softwareanwender), sondern kann über die strafrechtlichen Regelungen der Teilnahme (Anstiftung, Beihilfe gem. §§ 26, 27 StGB) auch den Auftragnehmer (Softwareanbieter) mit Freiheits- oder Geldstrafe treffen. Es muss daher mittels technischer, organisatorischer Vorkehrungen ausgeschlossen sein, dass der Auftragnehmer (Softwareanbieter) Zugang zu solchen Privatgeheimnissen erhält. Soweit keine Privatgeheimnisse, sondern personenbezogene Daten oder So- 373 zialdaten betroffen sind, geben § 11 BDSG bzw. § 80 SGB X die Möglichkeit, mittels einer gesondert abzuschließenden Vereinbarung über die Verarbeitung von personenbezogenen Daten bzw. Sozialdaten (Auftragsdatenver-

1 Ob Landesgesetze als Rechtfertigungsgrund rechtlich geeignet sind, ist zu prüfen, vgl. OLG Düsseldorf v. 20.8.1996 – 20 U 139/95, CR 1997, 536.

Peter

937

I Rz. 374

Sonderregelungen

arbeitung), die Rechtsgrundlage für die Erhebung1, Verarbeitung2 oder Nutzung3 solcher Daten durch den Auftragnehmer (Softwareanbieter) zu schaffen, ohne vorher die Einwilligungen der Betroffenen einzuholen4. 374

Bei der Auftragsdatenverarbeitung bleibt der Auftraggeber (Softwareanwender) für die Einhaltung der datenschutzrechtlichen/sozialrechtlichen Vorschriften verantwortlich („Herr der Daten“) und der Auftragnehmer (Softwareanbieter) darf nur im Rahmen der Weisungen des Auftraggebers (Softwareanwenders) die Erhebung, Verarbeitung oder Nutzung solcher Daten vornehmen. Der Auftraggeber (Softwareanwender) schreibt die technischen und organisatorischen Maßnahmen zur Datensicherheit beim Auftragnehmer (Softwareanbieter) vor. § 11 BDSG und § 80 SGB X enthalten darüber hinaus vielfältige Vorgaben, die im Einzelnen in der Vereinbarung über die Auftragsdatenverarbeitung festzulegen sind. Die Regelungen der BVB-Pflege und der EVB-IT Pflege S sind hierfür nicht ausreichend. 2. Einsatz der Software auf vorgegebener Systemumgebung

375

Regelmäßig gibt der Softwareanbieter vor, dass die überlassene Software nur auf einer dafür freigegebenen Systemumgebung genutzt werden soll5. Dies erfolgt nicht nur aus dem Grund, dem Softwareanwender mitzuteilen, innerhalb welcher Systemumgebung die überlassene Software optimal arbeitet, sondern er macht die Vorgabe auch, damit er seine Pflegeleistungen optimal erbringen kann6. Denn es wird dadurch gewährleistet, dass die Software möglichst fehlerfrei arbeitet, weil der Softwareanbieter/-hersteller das Zusammenarbeiten der Software mit der explizit bezeichneten Systemumgebung bei ihrer Entwicklung berücksichtigt hat.

376

Das Ablaufenlassen auf irgendeiner dafür technisch geeigneten Systemumgebung dürfte im Rahmen des bestimmungsgemäßen Gebrauchs der überlassenen Software urheberrechtlich zulässig sein, §§ 69d, 69c UrhG, soweit mit dem Rechtsinhaber keine dies einschränkende Vereinbarung wirksam getroffen wurde. Individualvertraglich können solche Beschränkungen 1 Erheben ist das Beschaffen von Daten über den Betroffenen. 2 Verarbeiten ist das Speichern, Verändern, Übermitteln, Sperren und Löschen von personenbezogenen Daten. 3 Nutzen ist jede Verwendung personenbezogener Daten, soweit es sich nicht um Verarbeitung handelt. 4 OVG Schleswig-Holstein v. 12.1.2011 – 4 MB 56/10, CR 2011, 359: Schutz von Patientendaten durch Auftragsdatenverarbeitung bei hausarztzentrierter Versorgung. Scholz/Lutz, CR 2011, 424: Standardvertragsklauseln für Auftragsverarbeiter und § 11 BDSG; Lensdorf, CR 2010, 735: Auftragsdatenverarbeitung in der EU/EWR und Unterauftragsdatenverarbeitung in Drittländern; Kramer/Herrmann, CR 2003, 938: Zur Reichweite der Privilegierung durch den Tatbestand des § 11 BDSG; Probst, DuD 2003, 508: Der Softwareanwender muss Herr der Systeme bleiben. 5 Zahrnt, Computervertragsrecht, Kapitel 14 14.2 (4). 6 Heymann/Lensdorf, Handbuch der IT-Verträge, 1.12 Rz. 27.

938

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 380 I

im Rahmen der Grenzen der §§ 134, 138 und 242 BGB wirksam vereinbart bzw. durchgesetzt werden. Formularklausel, die den Einsatz der überlassenen Software auf allen anderen (z.B. Ersatz-)Systemumgebungen als den empfohlenen ausdrücklich verbieten, dürften den Softwareanwender i.S.d. § 307 BGB unangemessen benachteiligen und unwirksam sein, es sei denn, eine solche Beschränkung ist in Übereinstimmung mit den §§ 69d, 69c und § 31 UrhG wirksam vereinbart1. Ist eine entsprechende Formularklausel urheberrechtlich gedeckt, dürfte diese Klausel nicht der Inhaltskontrolle unterliegen, soweit diese nicht von den maßgeblichen urheberrechtlichen Vorschriften abweichen oder diese ergänzen, § 307 Abs. 3 BGB2. Die Begriffsbestimmungen der EVB-IT Pflege definieren die Systemumgebung als die „vom Hersteller vorgegebene Hardware und Systemsoftware (einschließlich Kommunikationsdiensten), die zur Ablauffähigkeit der Standardsoftware erforderlich sind.“

377

Setzt der Softwareanwender die überlassene Software nicht auf der vorgege- 378 benen Systemumgebung ein, haben die EVB-IT Pflege hierfür in Ziff. 1.2, Abs. 2 die Antwort: Der Softwareanwender hat grundsätzlich keinen Anspruch auf vereinbarte Pflegeleistungen3. Damit dürfte der Einsatz der überlassenen Software auf einer dafür freige- 379 gebenen Systemumgebung als vertraglich vereinbarte Obliegenheit des Softwareanwenders, mithin als sog. „Systemumgebung-Einsatzobliegenheit“ zu behandeln sein, weil als Rechtsfolge im Fall eines Verstoßes gegen die Systemumgebung-Einsatzobliegenheit kein Schadensersatzanspruch des Softwareanbieters steht, sondern vielmehr der Anspruchsverlust des Softwareanwenders vereinbart ist4. a) Verletzung der Systemumgebung-Einsatzobliegenheit Macht der Softwareanbieter die Verletzung der Systemumgebung-Einsatz- 380 obliegenheit geltend und beruft er sich deswegen auf einen Anspruchsausschluss, ist fraglich, ob dieser formularmäßig in AGB wirksam vereinbart worden sein kann, wenn der Anspruch auf entgeltliche Pflegeleistungen unabhängig davon wegfällt, ob eine Verletzung der Systemumgebung-Einsatzobliegenheit für das nicht optimale Erbringen der Softwarepflegeleistungen ursächlich gewesen ist. Es dürfte eher davon auszugehen sein, dass eine sol-

1 Zur Problematik der rechtlichen Beurteilung sog. OEM-Software (Software, die nur zusammen mit einer bestimmten Hardware eingesetzt und vertrieben werden darf) s. Wandtke/Bullinger/Grützmacher, Urheberrecht, § 69d Rz. 87. 2 Palandt/Grüneberg, § 307 BGB Rz. 50 ff. und Rz. 138 a.E. 3 Zu den Ausnahmen siehe Ziff. 1.2, 2. Abs. EVB-IT Pflege S. 4 Zur Abgrenzung einer vertraglichen Obliegenheit zur vertraglichen (Leistungs-)Pflicht s. BGH v. 17.10.2007 – VIII ZR 251/06, Gebrauchtwagengarantievertrag.

Peter

939

I Rz. 381

Sonderregelungen

che formularmäßige Vereinbarung den Softwareanwender unangemessen benachteiligt, § 307 Abs. 1 Satz 1 BGB1. 381

Die Beweislast für die Kausalität der Verletzung der Systemumgebung-Einsatzobliegenheit zur nicht optimalen Erbringung der Softwarepflegeleistungen trifft den Softwareanbieter, wenn er sich auf einen Anspruchsausschluss berufen will2. Das formularmäßige Abwälzen dieses Beweislastrisikos hilft hier dem Softwareanbieter nicht, denn es ist im Verbraucherverkehr nach § 309 Nr. 12a) BGB und selbst im Unternehmensverkehr (§ 307 BGB) unwirksam (s. hierzu vorstehend unter Rz. 187 f.). b) Mängelrüge trotz Verletzung der Systemumgebung-Einsatzobliegenheit

382

Rügt der Softwareanwender Fehler oder Störungen an der überlassenen Software, obwohl er diese nicht auf der vorgegebenen Systemumgebung einsetzt, kann ihn die Beweislast dafür treffen, dass die von ihm gerügten Fehler auch bei ordnungsgemäßem Gebrauch der Software vorliegen3.

383

Entsprechend hatte das OLG Köln in einem Fall entschieden, in dem der Softwareanwender eine gekoppelte (bundled) Software, entgegen der vertraglichen Abreden, isoliert oder mit anderen Softwarekomponenten (stand alone) benutzt hatte4.

384

Erfolgt die Vorgabe des Softwareanbieters, die Software nur auf einer bestimmten Systemumgebung einzusetzen, per Formularvertrag und wird die Beweislast dafür, dass die vom Softwareanwender gerügten Fehler oder Störungen bei einer festgestellten Verletzung seiner Systemumgebung-Einsatzobliegenheit auch bei ordnungsgemäßem Einsatz der Software auf der vom Softwareanbieter vorgegebenen Systemumgebung vorliegen, dem Softwareanwender übertragen, ist das Folgende zu beachten: Der danach vom Softwareanwender zu führende Beweis ist in jedem Fall als sog. Beweislasterschwerung zu werten, denn der Nachweis des fehlerhaften und nicht störungsfreien Betriebs der überlassenen Software auf einer anderen als der vom Softwareanwender genutzten Systemumgebung, nämlich der vom Softwareanbieter vorgegebenen Systemumgebung, stellt eine für den Softwareanwender – möglicherweise erhebliche – technisch-kommerzielle Hürde dar.

1 BGH v. 6.7.2011 – VIII ZR 293/10, zur Unwirksamkeit einer formularmäßigen Vereinbarung über eine entgeltliche Anschlussgarantie für Material- oder Herstellungsfehler eines Kraftfahrzeugs, wonach Garantieansprüche davon abhängen, dass der Garantienehmer die nach den Herstellerangaben erforderlichen Wartungen in den vorgegebenen Intervallen von einer Vertragswerkstatt des Herstellers durchführen lässt. 2 Zöller/Greger, Vor § 284 ZPO Rz. 17a zur Beweislast für rechtsbegründende Tatsachenmerkmale. 3 OLG Köln, CR 1998, 657. 4 OLG Köln, CR 1998, 657.

940

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 391 I

Es erscheint daher auf den ersten Blick fraglich, ob eine solche formular- 385 mäßige Vereinbarung den Anforderungen des § 309 Nr. 12a BGB standhält, denn selbst Erschwerungen der Beweisführung sind im Verbraucherverkehr nach § 309 Nr. 12a BGB und sogar im Unternehmensverkehr nach § 307 BGB unwirksam1. Jedoch erfasst § 309 Nr. 12a BGB nur diejenigen Bestimmungen, durch die 386 der Verwender die Beweislast zum Nachteil des anderen Vertragspartners ändert, insb. indem er diesem die Beweislast für Umstände auferlegt, die im Verantwortungsbereich des Verwenders liegen. Der Einsatz der Systemumgebung liegt jedoch nicht im Verantwortungs- 387 bereich des Softwareanbieters, sondern im Verantwortungsbereich des Softwareanwenders. Gibt der Softwareanbieter die Systemumgebung vor, liegt es einzig in der Verantwortung des Softwareanwenders, wenn er sich darüber einseitig hinwegsetzt. Formularklauseln, die eine entsprechende Beweislasterschwerung bei Fehler- oder Störungsrügen dem Softwareanwender auferlegen, wenn dieser gegen seine Systemumgebung-Einsatzobliegenheit verstoßen hat, können im Verbraucher- wie auch im Unternehmensverkehr wirksam vereinbart werden.

388

3. Programmkorrekturen, Installationen und Hotline Die genaue Festlegung von Art und Umfang der im Rahmen der Software- 389 pflege zu erbringenden Leistungen und die exakte Definition der verwendeten Begriffe sind von bedeutender Wichtigkeit für die rechtssichere Gestaltung der Verträge (zu dem Begriff „Programmkorrekturen“ s. Rz. 38)2. Im Unternehmensverkehr sollten die Rechtsberater unbedingt die Fachabteilungen hinzuziehen, um mit diesen gemeinsam die Einzelheiten festzulegen.

390

Dabei sollte zwingend zwischen denjenigen Leistungsteilen unterschieden werden, die durch

391

– pauschale Vergütung, – Vergütung nach Aufwand oder – einmalige Vergütung abgegolten werden. Sodann sollte klar niedergelegt werden, welche Leistungsteile ausgeschlossen sind3.

1 Palandt/Grüneberg, § 307 BGB Rz. 40 und § 309 BGB Rz. 107. 2 Marly, Praxishandbuch Softwarerecht, Rz. 1027. 3 Schneider, Handbuch des EDV-Rechts, K. Rz. 165.

Peter

941

I Rz. 392

Sonderregelungen

392

Dementsprechend differenzieren die EVB-IT Pflege S in Ziff. 1 zwischen monatlicher Pauschale, einmaliger Pauschale und Vergütung nach Aufwand.

393

Letztlich muss eine Vereinbarung darüber erfolgen, welche Leistungsteile lediglich tätigkeitsorientiert (Dienstvertrag) erbracht werden sollen und welche Leistungsteile erfolgsorientiert (Werkvertrag) geschuldet werden1. a) Programmkorrekturen

394

Mit den Programmkorrekturen sollen u.a. Umgehungen, Patches, Updates, Upgrades oder Releases/Versionen zu der überlassenen Software geliefert werden (zu den Begriffen s. Rz. 38 ff.). aa) Mängelbeseitigung

395

Soweit mit den Programmkorrekturen Mängel behoben werden sollen, ist darauf zu achten, ob die Pflegevereinbarung diese Verpflichtung tätigkeitsoder erfolgsorientiert definiert; darüber hinaus – und das ist wichtig – ist eindeutig festzuschreiben, ob die vereinbarte Mängelbeseitigung nach Aufwand2 abgerechnet wird oder mit einer (z.B. monatlichen) Pauschalvergütung zu vergüten ist.

396

Sodann stellt sich die entscheidende Frage, was unter einem Mangel zu verstehen ist. Die EVB-IT Pflege S definieren den Mangelbegriff nicht. Die BVB-Pflege3 enthalten in § 4 Ziff. 1, Satz 1, 2. Halbs. nur den Hinweis, dass die Programme bei vertragsgemäßem Einsatz die in der Leistungsbeschreibung festgelegten Leistungen zu erbringen haben. Unabhängig hiervon ist jedoch klar, dass es einen softwarepflegespezifischen Mangelbegriff nicht gibt4.

397

Zur rechtlichen Definition des Mangelbegriffs s. Kap. D Rz. 246 ff. mit Beispielen. Typischerweise entsteht in der Praxis vor allem Streit über die Beantwortung der Frage, was als Soll-Beschaffenheit vereinbart wurde.

398

Für den Fall, dass die Vertragsparteien nicht vereinbart haben, was die Software im Einzelnen zu leisten hat, dürfte die Entscheidungspraxis des BGH im Zusammenhang mit Softwareerstellung Hinweise geben: Danach schuldet der Softwarehersteller eine Software, die dem Stand der Technik im

1 Zu tätigkeitsorientierten AGB s. Schneider, Handbuch des EDV-Rechts, K. Rz. 138 ff.; zur Tätigkeitsorientierung s. auch Hartmann/Thiel, CR 1998, 581; zu erfolgsorientierten AGB s. Schneider, Handbuch des EDV-Rechts, K. Rz. 144 ff.; zur erfolgsorientierter Softwarepflege s. auch Hering, CR 1991, 398. 2 In Ziff. 3.1.2 des EVB-IT Pflegevertrages S als additive Pflegeleistungen bezeichnet, die der Abnahme bedarf – vgl. hierzu statt vieler: Feil/Leitzen, CR 2003, 161. 3 Besondere Vertragsbedingungen für die Pflege von DV-Programmen. 4 Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, 1.12 Rz. 35.

942

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 404 I

mittleren Ausführungsstand entspricht1. Hierbei nehmen die Begriffe „Stand der Technik bei mittlerem Ausführungsstand“ Maß an dem, was der Softwarebesteller nach den getroffenen Vereinbarungen erwarten durfte2. Dies wiederum wird letztlich vom Tatsachenrichter festgestellt. Aufgrund dieser Rechtslage dürfte es ein zwingendes Gebot sein, dass die 399 Vertragsparteien so klar wie möglich vertraglich definieren, was Inhalt und Umfang der vom Softwareanbieter zu erbringenden Pflegeleistungen sein soll. Letztlich dürfte vor dem Hintergrund der vorbezeichneten BGH-Rechtspre- 400 chung der Auffassung nicht gefolgt werden können, dass ein Mangel eine Abweichung von dem ist, was die (Software-)Anwenderschaft erwarten darf3, denn auf die Erwartungshaltung der Anwenderschaft kommt es nicht an; maßgeblicher Ausgangspunkt ist allein die getroffene Vereinbarung. Demnach setzt sich der Softwareanbieter einem möglichen Mangelvorwurf aus, wenn er die ursprüngliche Funktionalität gegenüber der getroffenen Vereinbarung abändert, selbst wenn die Änderung für die überwiegende Mehrzahl der Anwenderschaft akzeptabel ist oder die Änderung dem entspricht, was nach dem Konzept des Softwareanbieters oder nach der Erwartung der Mehrzahl der Anwenderschaft die Software für ihre gewöhnliche Verwendbarkeit dringend können muss4.

401

bb) Störungsbeseitigung Neben der sog. Mängelbeseitigung ist in Softwarepflegeverträgen häufig die 402 Verpflichtung zur sog. Störungsbeseitigung anzutreffen. Im Zusammenhang mit dem zivilrechtlichen Leistungsstörungsrecht ist 403 der Begriff „Störung“ nicht gesetzlich aufgeführt, daher ist das Eine herauszustellen: Der Begriff Störung ist nicht gleichbedeutend mit dem Mangelbegriff5. Den Vertragsparteien ist es jedoch unbenommen, diesen Begriff vertraglich zu definieren. Üblicherweise wird der Begriff der Störung weiter gefasst als der Mangel- 404 begriff. Mithin soll dieser Begriff nicht nur den Mangelbegriff umfassen, sondern auch solche Beeinträchtigungen, die andere Ursachen haben (z.B. Bedienungsfehler, Beeinträchtigungen durch andere, vom Softwareanwender eingesetzte Programme)6.

1 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 = NJW-RR 2004, 782; BGH v. 24.9.1991 – X ZR 85/90, CR 1992, 543; Schneider, ITRB 2010, 241. 2 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 = NJW-RR 2004, 782. 3 Zahrnt, CR 2004, 408. 4 A.A. Zahrnt, CR 2004, 408. 5 OLG München v. 22.11.1988 – 25 U 5810/86, CR 1989, 283: Die Störung selbst ist nicht der Mangel, sondern eine mögliche Folge eines Mangels. 6 Intveen, ITRB 2005, 117.

Peter

943

I Rz. 405

Sonderregelungen

405

Im Zusammenhang mit dem ITIL-Management1 wird unter einer Störung (Incident) ein Ereignis verstanden, das nicht zum standardmäßigen Betrieb eines Services gehört und das tatsächlich oder potentiell eine Unterbrechung oder eine Minderung der Servicequalität verursacht2.

406

Um die Frage nach der Qualität von Software auf den Punkt zu bringen, dürfte die DIN 66272 (Bewertung von Softwareprodukten – Qualitätsmerkmale und Leitfaden zu ihrer Verwendung) Hilfestellung leisten und Orientierung geben, da sie sich gemäß ihrer Ziff. 1 u.a. explizit an diejenigen richtet, die mit der Pflege von Software betraut sind.

407

Ziff. 4 DIN 66272 stellt sechs verschiedene Qualitätsmerkmale für Softwareprodukte auf, deren – vollständiges oder teilweises – Fehlen als eine nicht hinnehmbare Störung im zuvor aufgeführten Sinn vertraglich vereinbart werden kann: – Funktionalität: Eine Menge von Merkmalen, die sich auf das Vorhandensein einer Menge von Funktionen und auf deren festgelegte Merkmale beziehen. – Zuverlässigkeit: Eine Menge von Merkmalen, die sich auf die Fähigkeit der Software beziehen, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. – Benutzbarkeit: Eine Menge von Merkmalen, die sich – auf den Aufwand, der zur Benutzung erforderlich ist und – auf die individuelle Bewertung einer solchen Benutzung durch eine festgelegte oder vorausgesetzte Gruppe von Benutzern beziehen. – Effizienz: Eine Menge von Merkmalen, die sich auf das Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen beziehen. – Änderbarkeit: Eine Menge von Merkmalen, die sich auf den Aufwand beziehen, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen, Verbesserungen oder Anpassungen der Software an Änderungen der Umgebung, der Anforderungen und der funktionalen Spezifikation einschließen3. – Übertragbarkeit: Eine Menge von Merkmalen, die sich auf die Eignung der Software, von einer Umgebung in eine andere übertragen zu werden, beziehen.

408

Vor diesem Hintergrund stellt die DIN 66272 in ihrer Ziff. 5.2.1 u.a. die Sicht des Softwareanwenders heraus, der in erster Linie an der Anwendung der Software, ihrer Leistung und den Auswirkungen ihres Einsatzes interes1 IT Infrastructure Library Management. 2 Söbbing, ITRB 2005, 97. 3 Unter „Anpassung“ wird u.a. oftmals auch die Verpflichtung verstanden, Software an veränderte tatsächliche oder rechtliche Rahmenbedingungen, die sich auf die Leistungsmerkmale der Software auswirken, anzupassen. Vgl. Wohlgemut, MMR 1999, 59; Zahrnt, Computervertragsrecht, Kap. 14.2.1 (3).

944

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 414 I

siert ist, ohne deren interne Aspekte zur Kenntnis zu nehmen oder ohne zu wissen, wie diese entwickelt wurde. Unter Ziff. 5.3 führt die DIN 66272 einen Bewertungsprozess an, der aus 409 drei Phasen besteht: Qualitätsanforderungen festlegen, Bewertung vorbereiten und bewerten. Die letzte Phase ist wiederum in drei Schritte untergliedert: messen, einstufen und beurteilen. Im Rahmen des letzten Schritts wird festgelegt, ob die Software oder die ausgewählte Komponente als annehmbar oder als nicht annehmbar beurteilt werden kann. Weist die Software während der Laufzeit der Pflegevereinbarung vereinbarte Qualitätsmerkmale als nicht mehr annehmbar auf, tritt der Fall der vereinbarten Störung ein, die der Softwareanbieter/-hersteller zu beseitigen hat. Vor allem im Unternehmensverkehr werden die konkreten Beschreibungen 410 für die zu erbringenden Leistungen und die Begriffsdefinitionen in sog. Service-Level-Agreements vereinbart (vgl. Rz. 473 ff.)1. cc) Funktionale Verbesserungen, Anpassungen, zusätzliche oder geänderte Funktionen und sonstige Anpassungen/Korrekturen Diese Pflegeleistungen entsprechen den Definitionen der Begriffe „Upgra- 411 des“ und „Releases/Versionen“ mit Ausnahme der Mängelbehebung (zu den Begriffen s. Rz. 43 f.; zum Begriff der „Anpassung“ s. Rz. 12 ff. und 407 Fn. 3). Auch hier ist wiederum zunächst entscheidend, was die Vertragsparteien unter diesen Pflegeleistungen verstanden haben wollen, so dass entsprechende Definitionen aufgenommen werden sollten. Hierbei ist darauf zu achten, dass eine Anpassung, deren Fehlen eine Störung darstellt, die der Softwareanbieter/-hersteller zu beseitigen hat, bereits als Qualitätsmerkmal definiert sein kann (s. hierzu Rz. 407).

412

Im Zusammenhang mit den in diesem Abschnitt genannten Pflegeleistun- 413 gen, also den funktionalen Verbesserungen, Anpassungen, den zusätzlichen oder geänderten Funktionen und sonstigen Anpassungen/Korrekturen ist die Frage zu stellen, wann und unter welchen Voraussetzungen eine neue Softwareentwicklung, die auf der überlassenen und gepflegten Software aufbaut, als aliud zu verstehen ist. Denn dies hat zur Folge, dass der Softwareanbieter/-hersteller diesen Softwarestand als ein neues Softwareprodukt vermarkten kann, was problematisch ist, wenn dieser Softwarestand genau diejenigen (neuen) Funktionalitäten enthält, auf die der Anwenderbestand bereits gewartet hat und für die er nun mittels kompletter Neulizenzierung nochmals zahlen muss. Vor diesem Hintergrund ist klar, dass der Softwareanwender das Interesse hat, den Umfang der Lieferung von Releases/Versionen mit neuen oder geänderten Funktionalitäten so weit und umfassend wie möglich zu definie-

1 Schuster, CR 2009, 205.

Peter

945

414

I Rz. 415

Sonderregelungen

ren, was mitunter nicht unerhebliche praktische Schwierigkeiten bereiten kann. 415

Bei der Beantwortung der Frage, wann ein aliud vorliegt und wann nicht, bzw. an welchen Maßstäben dies zu messen ist, dürfte auf die Rechtsprechung des BGH zur Falschlieferung bei Gattungsschulden zurückzugreifen sein: Danach ist für die Abgrenzung, ob es sich um eine andere als die geschuldete Ware handelt, in erster Linie auf den ausdrücklich vereinbarten oder dem Verkäufer wenigstens bekannten Vertragszweck und die danach erforderlichen Merkmale der zu liefernden Ware abzustellen1.

416

Die Vertragsparteien haben es weitgehend in der Hand, durch genaue Bestimmung die maßgeblichen Eigenschaften der zu liefernden Programmkorrekturen festzulegen, wobei – das ist deutlich hervorzuheben – ein Restrisiko für den Softwareanwender bleibt. Denn stattet der Softwareanbieter/ -hersteller in freier unternehmerischer Entscheidung sein neues Produkt mit weiteren, außerhalb des Softwarepflegevertrags liegenden neuen Funktionalitäten aus, die auch vom Vertragszweck nicht mehr erfasst sind, hat der Softwareanwender keinen Anspruch auf Überlassung der neuen Software ohne deren Neulizenzierung.

417

Enthält die neue Software jedoch – zumindest auch – hinzugefügte Funktionalitäten, auf deren Lieferung der Softwareanwender Anspruch hat, sind ihm diese im Rahmen der Softwarepflege zu überlassen, wie auch immer dies umzusetzen ist. dd) Nachführen

418

Oftmals wird Standardsoftware durch den Softwareanwender selbst, in vielen Fällen auch durch einen Dritten individuell angepasst, um die überlassene Standardsoftware so im Hinblick auf spezifische Anforderungen des Softwareanwenders zu modifizieren. Dabei ist hier nicht der Fall gemeint, in dem lediglich die in der Standardsoftware bereits enthaltenen Einstellungsparameter bedient werden (die Standardsoftware wird konfiguriert/parametrisiert). Vielmehr soll die individuelle Anpassung der in der Standardsoftware enthaltenen Funktionalitäten und/oder Schnittstellen mittels Änderung und/oder Ergänzung des Quellcodes der Standardsoftware im Mittelpunkt der Betrachtung stehen.

419

Voraussetzung ist, dass dem Softwareanwender der Quellcode der Standardsoftware zur Verfügung gestellt wird, sei es durch den Softwarehersteller selbst oder durch den Softwareanbieter, von dem der Softwareanwender die Standardsoftware erhalten hat. Mit der Überlassung des Quellcodes muss dem Softwareanwender auch das Recht eingeräumt sein, den Quellcode zu dem von ihm beabsichtigten Zweck, selbst oder durch Dritte ändern und/ oder ergänzen zu dürfen, um die Standardsoftware sodann auch in diesem 1 BGH v. 12.3.1997 – VIII ZR 15/96, CR 1997, 462 = NJW 1997, 1914; BGH v. 23.3.1994 – VIII ZR 47/93, MDR 1994, 1100 = WM 1994, 1394.

946

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 423 I

angepassten Zustand nutzen zu dürfen. Zur Anpassung und der damit verbundenen Nutzungsrechtsproblematik s. Kap. G Rz. 293 ff. Sollen nunmehr im Rahmen der Durchführung der vereinbarten Software- 420 pflege Programmkorrekturen in die (angepasste) Standardsoftware eingespielt werden, kann es sein, dass die Programmkorrekturen Einfluss auf die bereits bestehenden Anpassungen der Standardsoftware nehmen. Die angepasste Standardsoftware muss also aufgrund der eingespielten Programmkorrekturen „nachgeführt“, d.h. nochmals individuell angepasst werden. Auch ein anderer Weg ist möglich: Statt die individuell angepasste Standardsoftware nochmals individuell anzupassen, könnte der Softwareanbieter, soweit dieser der Hersteller der Software ist oder zum Zweck der Durchführung der Softwarepflege über den Quellcode verfügt, seine neuen Standardsoftwareversionen (Updates, Upgrades) auf der Basis der individuellen Anpassungen der Standardsoftware selbst „nachführen“, so dass die neuen Programmkorrekturen in die individuell angepasste Standardsoftware eingespielt werden können, ohne dass diese nochmals individuell angepasst werden muss1. Es stellt sich also in Bezug auf beide vorgenannten Konstellationen im Ein- 421 zelfall die Frage, wer für das Nachführen verantwortlich ist und wer die Nachführungsleistungen zu erbringen bzw. zu bezahlen hat; standardmäßig enthalten Softwarepflegeverträge jedenfalls keine Nachführungsleistungen2. Dabei dürfte der Interessenkonflikt zwischen dem Softwareanwender und dem Softwareanbieter größer sein, wenn der Softwareanbieter zugleich der Hersteller der Software ist und die überlassene Standardsoftware für den Softwareanwender selbst individuell angepasst hatte, denn für den Softwareanwender dürfte es schwerlich nachvollziehbar sein, warum er für das Nachführen zusätzlich zahlen soll, wenn andererseits die Möglichkeit besteht, dass der Softwareanbieter die Programmkorrekturen so gestaltet, dass ein Nachführen nicht erforderlich wird3. Ergänzend sei bemerkt, dass die vorstehende Problematik ebenfalls im Zu- 422 sammenhang mit der Softwarepflege einer für den Softwareanwender individuell erstellten Software bestehen kann. Eine abschließende Lösung zu alledem bringt letztlich nur eine klare und erschöpfende vertragliche Regelung im Softwarepflegevertrag, die idealerweise individuell ausgehandelt sein sollte, um die Interessen beider Vertragspartner im Einzelfall angemessen und interessengerecht abzubilden.

1 Schneider, ITRB 2005, 191. 2 Schneider, ITRB 2005, 191. 3 Schneider, ITRB 2005, 191; Schneider, CR 2011, 626 zu Einführungsleistungen und deren Entgeltpflicht.

Peter

947

423

I Rz. 424

Sonderregelungen

ee) Dokumentation 424

Zu Lieferpflicht und -umfang von Softwaredokumentationen im Zusammenhang mit der Softwareüberlassung s. Kap. D Rz. 119 ff. Hier stellt sich die Frage, ob der Softwareanbieter/-hersteller im Rahmen der Auslieferung von Programmkorrekturen ebenfalls zur Überlassung von angepassten Softwaredokumentationen verpflichtet ist.

425

Nach § 4 Ziff. 1, Satz 3 BVB-Pflege kann der Softwareanwender verlangen, dass der Softwareanbieter ihm neue Programmversionen einschließlich Programmdokumentationen zur Verfügung stellt, soweit er darüber verfügungsberechtigt ist.

426

Die EVB-IT Pflege S definieren die Programmkorrektur (zum Begriff s. Rz. 38) „einschließlich zugehöriger Dokumentation“ und führen hierzu in Ziff. 1.6 aus: „Die Dokumentationen der Programmkorrekturen sind in Deutsch und in ausgedruckter oder ausdruckbarer Form zu liefern, soweit nichts anderes vereinbart worden ist.“

427

Ist keine Vereinbarung über die Verpflichtung zur Lieferung einer Softwaredokumentation im Zusammenhang mit der Softwarepflege getroffen worden, ist eine Lieferverpflichtung auf Grundlage der Rechtsprechung des BGH zur Überlassung einer Dokumentation bei der (erstmaligen) Softwareüberlassung anzunehmen. Danach hat der Verkäufer einer Software seine Hauptleistungspflicht solange nicht vollständig erbracht, bis er das Handbuch ausgeliefert hat, weil das Handbuch Teil der verkauften Sachgesamtheit ist1.

428

Hingegen soll nach dem BGH die Online-Hilfefunktion Bestandteil der Software sein, so dass die Verpflichtung, ein Handbuch zu liefern, nicht durch das Zurverfügungstellen einer Online-Hilfefunktion erfüllt werden kann2.

429

Außerdem hat der BGH in Bezug auf die werkvertraglich geschuldete Überlassung einer individuell zu erstellenden Software entschieden, dass der Anspruch des Bestellers auf Lieferung einer zum Betrieb der Software erforderlichen Dokumentation grundsätzlich erst mit dem Abschluss der Arbeiten an dem Programm fällig wird3, mithin auch im Werkvertragsrecht die Verpflichtung zur Lieferung eines Handbuchs justiziabel ist. Diese Rechtsprechung dürfte auch auf andere Vertragstypen übertragbar sein.

430

Vor diesem Hintergrund dürfte eine jüngere Entscheidung des LG Bonn zu sehen sein, der zu entnehmen ist, dass der Pflegegläubiger bei jedem Update der Software einen Anspruch auf eine aktualisierte Softwaredokumentation hat4. 1 BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207; BGH v. 14.7.1993 – VIII ZR 147/92, CR 1993, 681. 2 BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207. 3 BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367. 4 LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 177 (Leitsatz ohne Gründe).

948

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 435 I

Steht die Verpflichtung zur Lieferung einer Dokumentation fest, fragt 431 sich, was Inhalt und Umfang der Dokumentation sein soll (s. hierzu Kap. D Rz. 119 ff.). Grundsätzlich dürfte mit der Rechtsprechung des BGH herausgestellt werden können, dass die Dokumentation es dem Benutzer ermöglichen soll, mit der Software nach dem vereinbarten bzw. – im Fall einer fehlenden Vereinbarung – nach dem anzunehmenden Einsatzzweck zu arbeiten1. Soweit im Weg der (ergänzenden) Vertragsauslegung (§§ 133, 157 BGB) darauf zurückzugreifen ist, muss die Dokumentation nach dem Stand der Technik erstellt sein2. In diesem Zusammenhang ist auf den neuen ISOStandard für Softwaredokumentationen ISO/IEC 26514 aus dem Jahre 2008 hinzuweisen3. Die EVB-IT Pflege S beschreiben jedenfalls nicht, was Inhalt der Software- 432 dokumentation sein soll. Das LG Bonn greift hierzu zwei Kriterien heraus: Zum einen ist die Dokumentation dann mangelhaft, wenn die in ihr enthaltenen Bildschirmdialoge in nennenswertem Umfang nicht (mehr) aktuell sind, nicht mit den im Programm vorhandenen Dialogen übereinstimmen oder gar nicht dokumentiert sind. Zum anderen ist die Dokumentation mangelhaft, wenn ein Inhaltsverzeichnis fehlt, oder sie den Softwareanwender nicht in die Lage versetzt, die Software im Bedarfsfall erneut oder auf einer anderen Anlage zu installieren4. b) Installationsleistungen Als Installation von Software ist der Vorgang zu verstehen, bei dem neue Programme auf einen vorhandenen Computer kopiert und konfiguriert werden; dieser Vorgang wird auch Setup (englisch für Aufbau) genannt5. Der Begriff „Deinstallation“ bezeichnet den umgekehrten Vorgang, also das Entfernen von Software. Die Konfiguration ist eine bestimmte Einstellung von Programmen (oder von Hardwarebestandteilen) eines Computers6.

433

Zur Einführung und Implementierung von Standardsoftware s. Kap. G Rz. 27 ff.

434

Im Softwarepflegeprojekt muss festgelegt werden, ob der Softwareanbieter 435 oder der Softwareanwender für die Installation der Programmkorrekturen verantwortlich ist. Insoweit entscheidet sich z.B., zu welchem Zeitpunkt die Untersuchungspflicht des Softwareanwenders beim Handelskauf nach § 377 HGB beginnt. Ist neben der kaufrechtlichen Überlassung von Soft1 BGH v. 20.2.2001 – X ZR 9/99, CR 2001, 367. Zu verschiedenen Dokumentationsarten s. Stiemerling, ITRB 2011, 286. 2 Palandt/Sprau, § 633 BGB Rz. 6a. 3 ISO/IEC 26514:2008 – Systems and software engineering – Requirements for designers and developers of user documentation. 4 LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 177 (Leitsatz ohne Gründe). 5 Seffer/Horter, ITRB 2005, 169. 6 http://de.wikipedia.org/wiki/Konfiguration_(Computer).

Peter

949

I Rz. 436

Sonderregelungen

ware deren Installation durch den Verkäufer vereinbart, so ist die Ablieferung der Software i.S.d. § 377 HGB (und i.S.d. § 438 Abs. 2 BGB) erst mit Erbringung dieser Zusatzleistung erfolgt1. Entsprechendes gilt für die Abnahme gemäß § 634a Abs. 2 BGB und nach § 640 BGB2. 436

Die BVB-Pflege3 enthalten zu Installationsleistungen keine expliziten Regelungen. Vielmehr kann unter Ziff. 8 des BVB Pflegescheins als zusätzliche Vereinbarung angegeben werden, ob und welche Leistungen durch den Softwareanbieter in Bezug auf die Installation von Programmkorrekturen erbracht werden sollen.

437

Die EVB-IT Pflege S sind insoweit konkreter ausgestaltet: Sie enthalten unter Ziff. 3 (Art und Umfang der Pflegeleistungen), 3.1.1 als zusätzliche Unterstützungsleistung für die Basispflegeleistungen die Möglichkeit, u.a. die Unterstützung des Auftraggebers (Softwareanwenders) bei der Installation von Patches und Updates zu vereinbaren (zu den Begriffen s. Rz. 41 f.). Diese Unterstützung kann sodann alternativ, insbesondere als Teleservice (s. hierzu Rz. 360 ff.) oder als Vor-Ort-Service vereinbart werden. Entsprechende Vereinbarungen ermöglicht Ziff. 3.3 EVB-IT Pflege S für Upgrades und Releases/Versionen (zu den Begriffen s. Rz. 43 f.).

438

Einfachere Programmkorrekturen, wie z.B. Patches oder Updates, werden regelmäßig seitens der Softwarehersteller zum Download über ihre Website angeboten4. Sie enthalten ein sog. Installationspaket, damit die Installation auf dem Computer des Softwareanwenders realisiert werden kann. Moderne Betriebssysteme verfügen über leistungsfähige Standards und Routinen, welche die Installation von Programmen regeln und unterstützen5.

439

Bei komplexeren Programmkorrekturen, wie z.B. Upgrades oder Releases/ Versionen, ist zu entscheiden, wie die Realisierung der Installation zu erfolgen hat6, soweit der Download und die Installation durch den Softwareanwender mittels Ablaufenlassens des mitgelieferten Installationsprogramms nicht angemessen erscheint, denn der Erfolg einer Installation ist eine zwingende Voraussetzung für das Funktionieren komplexer Programme. Schlägt die Installation fehl, kann das Programm nicht verwendet werden. Daher ist die Realisierung der Installation von Programmen oft ebenso komplex und aufwändig wie die Realisierung des eigentlichen Programms7.

440

Es ist daher festzulegen, ob die vom Softwareanbieter/-hersteller zu erbringende Leistung tätigkeits- oder erfolgsorientiert gestaltet sein soll. Dabei 1 2 3 4

BGH v. 22.12.1999 – VIII ZR 299/98, CR 2000, 207. OLG Hamm v. 3.2.1997 – 13 U 153/96, CR 1998, 202. Besondere Vertragsbedingungen für die Pflege von DV-Programmen. Zum Download im Rahmen bestehender Pflegeverträge/Probleme mit ClickWrap-Agreements s. Karger, ITRB 2003, 134. 5 http://de.wikipedia.org/wiki/Installation_(Computer). 6 Z.B. mittels Tele- oder Vor-Ort-Service durch den Softwareanbieter/-hersteller. 7 http://de.wikipedia.org/wiki/Installation_(Computer).

950

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 444 I

hilft dem Softwareanwender eine tätigkeitsorientierte Leistung generell wenig, da er auf den Erfolg, nämlich auf die Realisierung der Installation angewiesen ist. Also ist festzulegen, ob die Vergütung aufwandsabhängig gezahlt wird oder mit dem wiederkehrenden (z.B. monatlichen) Pauschalpreis abgegolten ist. Letztlich sind spätestens im Zusammenhang mit den Installationsleistun- 441 gen die Verantwortlichkeiten für die vorherige Datensicherung1 und für die sog. Altdatenübernahme2 (s. hierzu Kap. G Rz. 144) festzulegen. So besteht nach dem LG Stuttgart für den Softwareanwender bereits eine 442 nach allgemeinen Grundsätzen bestehende Pflicht zur regelmäßigen Datensicherung3. Liegt eine derartige Datensicherungsverantwortung seitens des Softwareanwenders – z.B. zusätzlich durch eine vertragliche Vereinbarung gefestigt – vor und hat er diese nicht durchgeführt, kann der Softwareanbieter/-hersteller bei einem Datenverlust nicht auf Schadensersatz in Anspruch genommen werden, weil den Softwareanwender die alleinige Verantwortlichkeit trifft (§ 254 BGB), selbst wenn der Softwareanbieter/-hersteller den Datenverlust durch die Installation der Programmkorrektur verursacht hat4. In diesem Zusammenhang ist auf eine Entscheidung des BGH zur Beweis- 443 lastumkehr hinzuweisen5: Dort hatte der Softwareanbieter die Verpflichtung, eine Sicherungsroutine für eine regelmäßige Datensicherung auf Magnetbändern zu implementieren. Jedoch funktionierte die Sicherungsroutine nicht, so dass bei einem späteren Festplattencrash die verlorenen Daten nicht über die Sicherungsbänder wieder hergestellt werden konnten. Der Vorwurf des BGH: „Der EDV-Anbieter muss von den technisch möglichen und wirtschaftlich zumutbaren Kontrollen diejenige vornehmen, die ein Fachmann auf dem Gebiet des Implementierens von Programmen auf einer EDV-Anlage angewendet hätte, um auf Grund der Überprüfung annehmen zu können, dass das der Datensicherung dienende Programm übertragen und die Sicherungsroutine auf der EDV-Anlage lauffähig ist. Wird diese Überprüfung unterlassen, kehrt sich im Streitfall, ob ein Datenverlust seine Ursache in fehlerhafter Implementierung der Sicherungsroutine oder einem anderen Ereignis hat, die Beweislast zum Nachteil des EDV-Anbieters um.“6 Entsprechend dürfte eine Beweislastumkehr für den Fall in Frage kommen, 444 dass der Softwareanbieter/-hersteller im Rahmen der Installation der Pro1 Marly, Praxishandbuch Softwarerecht, Rz. 1027. S.a. OLG Koblenz v. 4.8.2010 – 1 U 1492/09, CR 2010, 704 zur Haftungsquote für IT-Unternehmen bei unterlassener Datensicherung vor Festplatten-Neuformatierung. 2 Intveen, ITRB 2001, 131. 3 LG Stuttgart v. 30.1.2002 – 38 O 149/00 KfH, CR 2002, 487. 4 LG Stuttgart v. 30.1.2002 – 38 O 149/00 KfH, CR 2000, 487. 5 BGH v. 2.7.1996 – X ZR 64/94, CR 1996, 663. 6 BGH v. 2.7.1996 – X ZR 64/94, CR 1996, 663 (Ls).

Peter

951

I Rz. 445

Sonderregelungen

grammkorrekturen für die technische Realisierung der Datensicherung und/oder der Altdatenübernahme verantwortlich ist und eine technisch mögliche und wirtschaftlich zumutbare Überprüfung unterlassen hat, nämlich, ob die technischen Vorkehrung entsprechend arbeiten und Daten vollständig und richtig gesichert bzw. übernommen werden. c) Hotline 445

Als „Hotline“ (ursprünglich die englische Bezeichnung für den „heißen Draht“) wird in der englischen und deutschen Umgangssprache ein telefonischer Dienst bezeichnet1.

446

Damit ist der Unterschied zur Fernpflege (s. Rz. 358 ff.) deutlich: Hier geht es um unmittelbare individuelle Kommunikation per Telefon. Sinn der Hotlineleistungen ist es, dem Softwareanwender die Möglichkeit zu geben, Fragen im Zusammenhang mit der Softwarenutzung zu stellen, die sogleich beantwortet werden können, oder Probleme in Bezug auf die Software zu melden, damit etwaige Weiterungen eingeleitet werden können.

447

Bei größeren Softwareprojekten (z.B. ein SAP ERP-Projekt mit 5000 hausinternen Nutzern) ist es üblich, Hotlineleistungen in einen sog. 1st, 2nd oder 3rd Level-Support aufzuteilen2.

448

Dies dient zunächst dazu, die anzurufenden Stellen hierarchisch zu organisieren. Dabei kommt es regelmäßig vor, dass der 1st Level-Support eine beim Softwareanwender eingerichtete Stelle ist, die ausschließlich mit Personen/Mitarbeitern besetzt ist, welche vom Softwareanbieter besonders geschult wurden, um erste Fragen oder Probleme der Nutzer aufzunehmen. Kann der 1st Level-Support die Frage nicht beantworten oder das Problem nicht selbst lösen, wendet er sich an den sog. 2nd Level-Support, der in der Regel vom Softwareanbieter wahrgenommen wird. Der 3rd Level-Support wird sodann vom Softwarehersteller durchgeführt, soweit dieser nicht selbst schon der Softwareanbieter ist.

449

Ist der Softwareanbieter nicht selbst der Softwarehersteller und ist die Einschaltung des 3rd Level-Supports notwendig, ist der Durchgriff des 1st LevelSupports auf den Hersteller, der im Fall des 3rd Level-Supports nicht der Vertragspartner des Softwareanwenders ist, zwischen Softwareanbieter und Softwarehersteller im erforderlichen Umfang zu organisieren. Zwischen diesen beiden muss der Ablaufprozess ebenfalls klar und eindeutig vertraglich definiert sein. Die praktischen Probleme, die sich aus einer mangelnden Absprache ergeben, werden oft unterschätzt. Auch der Softwarehersteller möchte nur von bestimmten qualifizierten Personen angerufen werden, weil er nur so eine gute Leistungsqualität einhalten kann. Nur die beim Softwareanwender ausgewählten Personen (regelmäßig der 1st Level-Sup1 http://de.wikipedia.org/wiki/Hotline. 2 Vgl. hierzu auch Schreibauer/Taraschka, CR 2003, 557.

952

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 454 I

port) dürfen sich z.B. mithilfe einer vom 2nd Level-Support überlassenen Kennung, mit der sie sich beim Softwarehersteller als zum direkten Anruf berechtigte Person identifizieren, unmittelbar an den sog. 3rd Level-Support wenden. Die Einteilung in einen sog. 1st, 2nd oder 3rd Level-Support dient außerdem 450 der Vereinfachung von Ablaufprozessen und verringert vor allem die Kosten für den Softwareanwender, da er das Call-Aufkommen beim Softwareanbieter verringert, denn soweit für Hotlineleistungen keine monatliche Pauschalvergütung vereinbart wird, erfolgt die Berechnung der Inanspruchnahme regelmäßig über sog. Call-Tickets, mithin wird jeder einzelne Anruf berechnet. Letzteres ist üblicherweise dann der Fall, wenn der Hotlineservice über ein Call-Center geführt wird, das vom Softwareanbieter oder -hersteller entweder gesondert eingerichtet wurde oder eingekauft wird. Gegenstand der Hotline Leistungen sind in der Regel Beratungsleistungen i.S.d. § 611 BGB, soweit nicht Fehlermeldungen entgegengenommen werden1. Da die Hotlineleistungen danach nur tätigkeitsbezogen sind, wird deutlich, dass der Softwareanbieter keinen Erfolg, sondern lediglich ein Bemühen schuldet2.

451

Soweit Fehlermeldungen in Frage stehen und die Vergütung über sog. Call- 452 Tickets vereinbart ist, sollte im Rahmen der Vereinbarung sichergestellt werden, dass derartige Anrufe entweder nicht als abzurechnende Call-Tickets erfasst werden oder hierfür eine gesonderte Kommunikationsmöglichkeit geschaffen ist. Denn die Entgegennahme von Fehlermeldungen stellt zunächst nichts anderes dar als einen Realakt im Zusammenhang mit dem Mängelhaftungsrecht, der nach den Vorschriften des BGB nicht gesondert zu vergüten ist. Eine Abwälzung der Vergütung auf den Softwareanwender dürfte nur im Rahmen einer Individualvereinbarung zulässig sein (vgl. zum Verhältnis der Entgeltpflicht für Mängelbeseitigung zur Mängelhaftung aus dem Softwareüberlassungsvertrag Rz. 150 ff.). Bei der Beratungsleistung geht es vor allem um die Klärung von Anwen- 453 dungsfragen im Zusammenhang mit der Nutzung der Software oder um die Beseitigung von durch den Softwareanwender verursachten Fehlfunktionen bzw. um die Lösung sonstiger Probleme bei der Nutzung der Software3. Soweit möglich, sollte definiert sein, welche Themen nicht Gegenstand der Beratungsleistungen in Bezug auf die Software sind. Vor allem bei größeren Softwareprojekten sollte vertraglich klar festgelegt 454 werden, welche Personen aus der Organisation des Softwareanwenders

1 Müglich, CR 2003, 633; Schreibauer/Taraschka, CR 2003, 557; Volle, CR 1996, 139. 2 Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 1.12 Rz. 53. 3 Schneider, Handbuch des EDV-Rechts, K. Rz. 31; Müglich, CR 2003, 633.

Peter

953

I Rz. 455

Sonderregelungen

beim 2nd Level-Support (Softwareanbieter) anrufen dürfen1. Diese Maßnahme dient der Effizienz der Zusammenarbeit: Es soll sichergestellt werden, dass nur diejenigen Personen beim 2nd Level-Support anrufen, die aufgrund vorab durchgeführter Schulungen oder wegen sonstiger Qualifikationen ausreichend befähigt sind, mit der notwendigen Sachkenntnis die erforderlichen Einzelheiten zu klären. Außerdem wird dadurch das Call-Aufkommen kalkulierbar. Für den Softwareanbieter ist wesentlich, dass die Hotline zur Verfügung steht, also nicht besetzt ist oder Rückrufe sofort erfolgen2. 455

Letztlich sollte eindeutig bestimmt sein, zu welchen Zeiten (Wochentage, Uhrzeiten, MEZ3) die Hotline zur Verfügung steht und wann die Leistungen nicht erbracht werden (z.B. länderspezifische oder bundeseinheitliche – gesetzliche bzw. kirchliche – Feiertage)4.

456

Die Leistung „Hotline“ impliziert nicht automatisch das Vorliegen eines Softwarepflegevertrages. Hotlineleistungen werden auch im Zusammenhang mit der Überlassung von Software angeboten, ohne dass ein gesonderter Softwarepflegevertrag abgeschlossen wird5.

457

Die BVB-Pflege6 enthalten zu Hotlineleistungen keine expliziten Regelungen. Vielmehr kann unter Ziff. 8 des BVB Pflegescheins als zusätzliche Vereinbarung angegeben werden, ob und welche Hotlineleistungen durch den Softwareanbieter erbracht werden sollen. Die EVB-IT Pflege S7 enthalten unter Ziff. 3 (Art und Umfang der Pflegeleistungen), 3.4.2 als sog. „Weitere Pflegeleistungen“ die Möglichkeit, Hotlineservice zu vereinbaren, der in einer Anlage gesondert auszugestalten ist.

X. Vertragstypologische Einordnung 1. Allgemeines 458

Obwohl die Frage nach der vertragstypologischen Einordnung wegen der unterschiedlich ausgestalteten Verantwortlichkeiten der Vertragsparteien oder hinsichtlich des Tätigkeits- bzw. Erfolgsbezugs der zu erbringenden Leistungsteile schwierig zu beantworten ist8, ist doch zumindest das Folgende klar: 1 Schneider, Handbuch des EDV-Rechts, K. Rz. 160; Schreibauer/Taraschka, CR 2003, 557. 2 Vgl. hierzu auch Zahrnt, Computervertragsrecht, Kapitel 14.3.2 (4). 3 Mitteleuropäische Zeitzone. 4 Schneider, Handbuch des EDV-Rechts, K. Rz. 160; Schreibauer/Taraschka, CR 2003, 557. 5 Schneider, Handbuch des EDV-Rechts, K. Rz. 31. 6 Besondere Vertragsbedingungen für die Pflege von DV-Programmen. 7 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware der öffentlichen Auftraggeber. 8 Marly, Praxishandbuch Softwarerecht, Rz. 1029.

954

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 463 I

Bei dem Softwarepflegevertrag handelt es sich um einen gegenseitigen Ver- 459 trag i.S.d. §§ 320 ff. BGB, weil sich jede Vertragspartei wegen der Gegenleistung der jeweils anderen Vertragspartei verpflichten will1. Dies hat im Wesentlichen Bedeutung für die Differenzierung der §§ 320 und 273 BGB und die Festlegung des Anwendungsbereiches der §§ 321 und 326 BGB2. Unabhängig von der Vereinbarung eines Gegenseitigkeitsverhältnisses finden bei Pflichtverletzungen die Vorschriften des allgemeinen Schuldrechts (vgl. §§ 280 ff. und 323 ff. BGB) Anwendung, soweit diesen Vorschriften keine Bestimmungen des Besonderen Schuldrechts vorgehen. Es sind jedoch nicht nur Fragen über Pflichtverletzungen maßgeblich, son- 460 dern auch andere Regelungselemente, wie z.B. Voraussetzungen für die Geltendmachung von Ansprüchen wegen Mängeln (z.B. Anzahl der Nachbesserungsversuche) oder der Beginn der Verjährung; diese sind in den Vertragstypen des Besonderen Schuldrechts unterschiedlich ausgestaltet. Wenn sämtliche Pflegeleistungen über eine gewisse Laufzeit wiederkehrend erbracht werden sollen, dürfte ebenso klar sein, dass der Softwarepflegevertrag insgesamt, d.h. bezüglich aller Leistungsanteile, als Dauerschuldverhältnis zu betrachten ist3, was die Anwendbarkeit des § 314 BGB zur Folge hat.

461

2. Typenmischung Selbst wenn das Entgeltmodell des Softwarepflegevertrags für einzelne Leistungsteile (z.B. ticketbezogene Abrechnung bei Hotlineleistungen, s. hierzu Rz. 450, im Übrigen monatliches pauschales Entgelt) unterschiedlich ausgestaltet sein sollte, werden diese Leistungsteile üblicherweise in einer Vertragsurkunde vereinbart, was bereits für ein einheitliches Rechtsgeschäft (vgl. Rz. 78) und zumindest für einen zusammengesetzten Vertrag4 spricht, so dass separate Verträge ausscheiden dürften.

462

Beim typengemischten Vertrag sind die verschiedenen Vertragstypen derart 463 miteinander verbunden, dass sie nur in ihrer Gesamtheit ein sinnvolles Ganzes ergeben; hingegen liegen beim zusammengesetzten Vertrag mehrere, durch den Parteiwillen verbundene, jedoch gedanklich voneinander trennbare Vereinbarungen vor5.

1 Marly, Praxishandbuch Softwarerecht, Rz. 1029 m.w.N. 2 Palandt/Grüneberg, Einf. vor § 320 BGB Rz. 16 der in Bezug auf das Synallagma zusätzlich auf die Unterschiede bei der Schadensermittlung hinweist. 3 Bischof/Witzel, ITRB 2003, 31; Bartsch, NJW 2002, 1526; Marly, Praxishandbuch Softwarerecht, Rz. 1031; Schneider, Handbuch des EDV-Rechts, K. Rz. 49; Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kap. 1.12 Rz. 12. 4 Zum zusammengesetzten Vertrag vgl. Palandt/Grüneberg, Überbl. vor § 311 BGB Rz. 16. 5 Palandt/Grüneberg, Überbl. vor § 311 BGB Rz. 19.

Peter

955

I Rz. 464 464

Sonderregelungen

Letzteres erscheint jedoch schwer vorstellbar: Die Elemente Lieferung von Programmkorrekturen, Anpassung der Dokumentation an die durch die Programmkorrektur erfolgten Änderungen, Installation der Programmkorrektur und Hotlineleistungen, um insbesondere Fragen zur Anwendung der Software klären zu können, die auch durch die Installation der Programmkorrekturen neu entstehen, zeigen, dass eher die innere Verbundenheit aller Leistungsteile als die gedanklich Trennbarkeit derselben im Vordergrund stehen dürfte. Daher erscheint es sachgerechter, von einem typengemischten Vertrag auszugehen, falls die Leistungsteile unterschiedlichen Vertragstypen des BGB zuzuordnen sind1. 3. Leistungsteile

465

In der juristischen Literatur wird die Frage der vertragstypologischen Einordnung in großer Vielzahl und seit langem diskutiert2. So unterschiedlich die einzelnen Stimmen zu den Fragen der korrekten Einordnung teilweise auch sein mögen: Es ist ihnen das Eine im Wesentlichen gemeinsam: Lassen sich mehrere Vertragstypen feststellen, handelt es sich beim SoftwarePflegevertrag regelmäßig um einen typengemischten Vertrag. Soweit lediglich nur ein Vertragstyp festgestellt wird (z.B. Werkvertragsrecht), ist oftmals deutlich, dass nur eine punktuelle Betrachtung der Leistungsteile stattfand3. Daher lässt sich keine allgemeine Aussage dahingehend aufstellen, der Software-Pflegevertrag sei diesem oder jenem Vertragstyp zuzuordnen. Maßgeblich ist und bleibt allein die individuelle Bestimmung von Art und Umfang der einzelnen Leistungsteile des zu prüfenden Pflegevertrages und deren vertragstypologische Einordnungen4.

466

Daher ergibt sich hier für die Programmkorrekturen, Dokumentationen, Installation und Hotline-Leistungen das folgende Bild: – Soweit bei der Mängel- oder Störungsbeseitigung und bei der Lieferung einer angepassten Dokumentation erfolgsbezogene Elemente im Vordergrund stehen dürften (Werkvertrag), sind Hotline-Leistungen regelmäßig tätigkeitsbezogen ausgestaltet (Dienstvertrag; s. hierzu Rz. 451). – Das erfolgsbezogene Element dürfte auch im Falle der Installationsleistungen überwiegen, wenn der Software-Anbieter zugleich der Software-Her1 Intveen, ITRB 2010, 90. 2 Marly, Praxishandbuch Softwarerecht, Rz. 1029 ff.; Schneider, Handbuch des EDV-Rechts, K. Rz. 105 ff.; Zahrnt, Computervertragsrecht, Kapitel 14.1. (3); Heymann/Lensdorf, in: Redeker, Handbuch der IT-Verträge, Kapitel 1.12 Rz. 7 f.; Schneider, CR 2005, 695; Schneider, CR 2004, 241; Runte, ITRB 2003, 253; Bischof/Witzel, ITRB 2003, 31; v. Baum, CR 2002, 705; Bartsch, NJW 2002, 1526; Hartmann/Thier, CR 1998, 581; Volle, CR 1996, 139; Heymann, CR 1991, 525; Hering, CR 1991, 398; Hardt, CR 1991, 200; Löwe, CR 1987, 219; Bartl, CR 1985, 13. Bezogen auf die EVB-IT Pflege S: Müglich, CR 2003, 633 und Feil/Leitzen, CR 2003, 161. 3 So auch Volle, CR 1996, 139 mit Verweis auf LG Köln in Fn. 4. 4 Statt vieler: Volle, CR 1996, 139.

956

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 470 I

steller ist, und der Software-Anwender die Software auf der vom SoftwareAnbieter vorgegebenen Systemumgebung einsetzt (s. hierzu Rz. 375), so dass Werkvertragsrecht Anwendung findet. Liegen diese Voraussetzungen nicht vor, ist mithin der Softwareanbieter 467 nicht zugleich der Softwarehersteller und setzt der Softwareanwender die Software nicht auf der vorgegebenen Systemumgebung ein, dürfte seitens des Softwareanbieters lediglich ein Bemühen geschuldet sein, stehen also tätigkeitsbezogene Elemente und damit Dienstvertragsrecht im Vordergrund. Schwieriger ist die vertragstypologische Einordnung bei Installationsleis- 468 tungen, wenn der Softwareanwender die Software zwar auf der vorgegebenen Systemumgebung einsetzt, der Softwareanbieter jedoch nicht der Hersteller der Software ist. Steht dem Softwareanwender oder dem Softwareanbieter der Quellcode der Software nicht zur Verfügung, ist er – rein tatsächlich – nicht in der Lage, etwaige Anpassungen des Quellcodes vorzunehmen, um einen Installationserfolg zu erzielen. Ob diese Tatsache die Annahme eines erfolgsbezogenen Elementes ausschließt, ist Fallfrage und damit abhängig von Sinn und Zweck des Vertrags und den sonstigen konkreten Umständen. Daher sollte darauf geachtet werden, diesen Punkt ebenfalls klar und deutlich zu definieren und entweder den Erfolg oder die Tätigkeit in den Vordergrund dieses Leistungsanteils zu stellen. Letztlich dürfte sich die Beantwortung dieser Frage in dem Fall erübrigen, 469 dass der Softwareanbieter erfolgsbezogen verpflichtet ist, Mängel oder Störungen zu beseitigen. Will er diese mittels Auslieferung von Programmkorrekturen beseitigen und können diese vom Softwareanwender oder vom Softwareanbieter mangels fehlerfreier Installationsanweisung nicht aufgespielt und umgesetzt werden, ist der Softwareanbieter seiner kaufrechtlichen Lieferpflicht oder seiner werkvertraglichen Pflicht, das Werk zur Abnahme bereitzustellen, nicht nachgekommen und verletzt insoweit seine Leistungspflichten. Soweit es im Zusammenhang mit der Lieferung von funktionalen Verbes- 470 serungen, Anpassungen, zusätzlichen oder geänderten Funktionen und sonstige Anpassungen/Korrekturen der Software mittels Upgrades oder Releases/ Versionen (zu den Begriffen s. Rz. 43 f.) um Softwareüberlassung geht, dürften werkvertragliche/dienstvertragliche oder kaufrechtliche Elemente im Vordergrund stehen. Denn hierbei geht es gerade um die Herstellung oder Erzeugung (und Lieferung) von Programmkorrekturen (als Software) während der Laufzeit des Pflegevertrags. Dieser Fall steht damit im Fokus des (neuen) § 651 BGB, der seit seiner Einführung aufgrund der Schuldrechtsmodernisierung dahingehend heftig umstritten ist, ob er auf Software überhaupt Anwendung finden kann oder nicht (vgl. zu diesem umfangreichen Fragekomplex im Einzelnen Kap. B Rz. 1 ff.).

Peter

957

I Rz. 471

Sonderregelungen

4. Typisierung eines gemischten Vertrages 471

Zu der Frage und dem Streitstand, welche Rechtsnormen welchen Vertragstyps bei Typenmischung anzuwenden sind, s. Kap. G Rz. 116 ff. 5. Rechtsprechung

472

Der BGH hat in seiner Entscheidung Internet-System-Vertrag 1 die Beantwortung der Frage der vertragstypologischen Einordnung von Softwarepflegeverträgen danach ausgerichtet, ob die vereinbarten Leistungen auf einen Tätigkeitserfolg gerichtet sind (dann Werkvertrag) oder, wenn ein solcher Tätigkeitserfolg fehlt, die Einordnung als Dienstvertrag nahe liegt1. Der BGH führt hierzu aus: „… (f) Verträge über die „Wartung“ oder „Pflege“ von Software, EDV-Programmen oder Websites sind als Werkverträge einzuordnen, soweit sie auf die Aufrechterhaltung der Funktionsfähigkeit und die Beseitigung von Störungen (und somit: auf einen Tätigkeitserfolg) gerichtet sind, wohingegen ihre Qualifizierung als Dienstvertrag nahe liegt, wenn es an einer solchen Erfolgsausrichtung fehlt und die laufende Serviceleistung (Tätigkeit) als solche geschuldet ist (…)2.

XI. Service-Level-Agreement 1. Einführung 473

Service-Level-Agreements (SLAs) haben in den letzten Jahren – insbesondere angetrieben durch die wachsende Marktbedeutung des IT-Outsourcings – mehr und mehr an Bedeutung gewonnen3; sie werden regelmäßig per Individualvertrag ausgehandelt4, so dass nachfolgend eine AGB-rechtliche Betrachtung im Wesentlichen nicht stattfindet.

474

SLAs werden jedoch nicht nur im Rahmen sog. Outsourcingprojekte abgeschlossen, sondern z.B. innerhalb einer IT-Organisation zwischen verschiedenen IT-Abteilungen, in der E-Commerce-5 wie auch in der Telekommuni-

1 BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327. 2 BGH v. 4.3.2010 – III ZR 79/09, CR 2010, 327 insbes. mit Verweis auf BGH v. 5.6.1984 – X ZR 75/83, BGHZ 91, 316 (317) = MDR 1984, 840; BGH v. 8.4.1997 – X ZR 62/95, NJW-RR 1997, 942 (943); ferner: OLG München v. 22.11.1988 – 25 U 5810/86, CR 1989, 283 (284); OLG München v. 8.11.1990 – 29 U 3410/90, CR 1992, 401 (402). 3 Schuster, CR 2009, 205; Rath, K&R 2007, 362; Beyer, ITRB 2006, 20; Schumacher, MMR 2006, 12; Peter, CR 2005, 404; Beyer, ITRB 2005, 287; Söbbing, ITRB 2004, 257; Bräutigam, CR 2004, 248; Hörl/Häuser, CR 2003, 713; Hoene, ITRB 2001, 297; Lütcke/Bähr, K&R 2001, 82. 4 Schreibauer/Taraschka, CR 2003, 557. 5 König, in: Bernhard/Lewandowski/Mann, Service-Level-Management in der IT – Wie man erfolgskritische Leistungen definiert und steuert, S. 28 f.

958

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 478 I

kationsbranche1. Auch im Zusammenhang mit Softwarepflegeleistungen sind SLAs anzutreffen2. Eine allgemein gültige oder eine gesetzliche Definition von Service-Level 475 besteht nicht3. Vielmehr zeigt sich eine uneinheitliche Ausgestaltung des Inhalts, der von einem SLA umfasst sein soll, so z.B. teils der komplette Leistungsumfang wie auch die einzuhaltenden Qualitätsstandards4, teils servicebasiert ein SLA für einen Service oder kundenspezifisch ein SLA für alle Services eines Kunden5. So uneinheitlich der Begriff des SLA auch besetzt sein mag, das eine scheint 476 im Grundsatz für alle SLAs zu gelten. Sobald sich eine Leistung auf Auftraggeberseite als unternehmenskritisch herausstellt, entsteht das Bedürfnis des Auftraggebers nach größerer Transparenz des Leistungserbringungsprozesses durch eine exaktere Definition der Leistungsanforderungen (Qualität und Leistungszeit), manchmal auch Erweiterung des Leistungsumfangs (Quantität), deren Kontrolle mittels Reportings, klare Vorgaben für die schnelle und erfolgreiche Beseitigung von Leistungsstörungen sowie Absicherung der Einhaltung der Service-Level durch Eskalationsprozesse und Sanktionsregelungen6. Das SLA soll also als Grundlage dafür dienen, dass ein Mindestmaß an Leis- 477 tungsqualität gesichert wird und Leistungsstörungen möglichst nicht eintreten; sollten sie dennoch eintreten, muss schnellstens der gewünschte Leistungszustand wieder hergestellt werden7. Der rechtliche Hintergrund für ein besonderes Bedürfnis nach näherer Aus- 478 gestaltung von Leistungsqualität, -zeit und ggf. -quantität und deren Aufrechterhaltung bzw. Wiederherstellung mittels eines SLAs liegt darin, dass das deutsche Zivilrecht in Bezug auf Art und Weise (Qualität), Umfang, Zeit und Ort von Leistungen oder bei Leistungsstörungen eine Vielzahl unbestimmter Rechtsbegriffe nutzen muss, die – letztlich durch die Gerichte – auf den Einzelfall angewendet und ausgelegt werden müssen. Dadurch können erhebliche Ungewissheiten und Risiken entstehen. Um dies möglichst zu vermeiden, braucht der Auftraggeber klare und exakte Regelungen, um den Auftragnehmer ohne weiteren Überzeugungsaufwand anzuhalten, die 1 Schuster, Vertragshandbuch Telemedia (3. Teil), D. Rz. 45 ff. 2 Schuster, CR 2009, 205; Schneider, Handbuch des EDV-Rechts, K. Rz. 249b; Marly, Praxishandbuch Softwarerecht, Rz. 1027; Schneider, CR 2005, 695; Intveen, ITRB 2004, 138; Schreibauer/Taraschka, CR 2003, 557; Bischof/Witzel, ITRB 2003, 31. 3 Schreibauer/Taraschka, CR 2003, 557; zur Begriffsentstehung s. Söbbing, ITRB 2004, 257. 4 Schreibauer/Taraschka, CR 2003, 557; Bischof/Witzel, ITRB 2003, 31. 5 http://de.wikipedia.org/wiki/Service_Level_Agreement. 6 Schuster, CR 2009, 205; Schreibauer/Taraschka, CR 2003, 557. 7 S. hierzu König, in: Bernhard/Lewandowski/Mann, Service-Level-Management in der IT – Wie man erfolgskritische Leistungen definiert und steuert, S. 28 f.

Peter

959

I Rz. 479

Sonderregelungen

gewünschten Leistungen zu erbringen, weil er sich die Störung von unternehmenskritischen Abläufen und Prozessen nicht erlauben kann. 479

In Bezug auf die Qualität1 der Leistung lässt sich das Gesagte wie folgt verdeutlichen: Neben den in den §§ 243 Abs. 1 BGB, 360 HGB enthaltenen Bestimmungen zur Lieferung einer Sache von mittlerer Art und Güte bei Gattungsschulden und den in §§ 243 ff. BGB geregelten Sonderbestimmungen enthält nur § 242 BGB eine – dem Wortlaut nach – allgemeine Definition über die Art und Weise, das „Wie“ der Leistung2. Obschon hierzu zunächst im Weg der Auslegung mittels des § 133 BGB und des (fast mit § 242 BGB wortgleichen) § 157 BGB der Parteiwille festzustellen ist, enthält § 242 BGB über seinen Wortlaut hinaus einen objektiven Maßstab, der unabhängig vom Parteiwillen auf Art und Weise, Bestand und Inhalt der Leistungspflichten einwirkt; § 157 BGB betrifft das rechtliche Wollen, § 242 BGB das rechtliche Sollen3. Es ist aber hervorzuheben, dass die Auslegung – einschließlich der ergänzenden Auslegung – Vorrang hat, obwohl § 157 BGB und § 242 BGB ineinander übergreifen; erst wenn der Parteiwille feststeht, ist zu prüfen, wie § 242 BGB auf das Rechtsverhältnis einwirkt4.

480

Wird also bereits der Parteiwille in nicht ausreichendem Maße zum Ausdruck gebracht, erfolgt z.B. die fehlende Festlegung des Inhalts von Leistungspflichten (Art und Umfang) durch den Tatsachenrichter. Wie dieser sodann im Einzelfall die Qualität der Leistungen bestimmt, dürfte schwerlich vorhersehbar sein. 2. Abgrenzung zur Mängelhaftung

481

Soweit Leistungspflichten des Softwarepflegevertrags mit dem SLA näher ausgestaltet werden, besteht keine Abgrenzungsproblematik gegenüber dem Mängelhaftungsrecht.

482

Falls das SLA als AGB verwendet wird und dieses unbestimmte Rechtsbegriffe des Mängelhaftungsrechts näher definiert, dürfte – soweit das Gesetz die nähere Ausgestaltung zulässt und diese zu Lasten des Verwenders erfolgt – kein Wirksamkeitsproblem aufgrund der §§ 307 ff. BGB entstehen.

1 D.h. die Art und Weise, das „Wie“ der Leistung. 2 …, die Leistung so zu bewirken, wie Treu und Glauben mit Rücksicht auf die Verkehrssitte es erfordern. Palandt/Grüneberg, § 242 BGB Rz. 1: Bestand und Inhalt der Leistungspflicht (das „Ob“ und das „Was“) werden vom reinen Wortlaut des § 242 BGB nicht erfasst. 3 Palandt/Grüneberg, § 242 BGB Rz. 19 mit Verweis auf BGHZ 16, 8. 4 Palandt/Grüneberg, § 242 BGB Rz. 19 mit Verweis auf u.a. BGHZ v. 11.10.2005 – XI ZR 395/04, NJW 2006, 54.

960

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 488 I

3. Programmkorrekturen a) Mängel- und Störungsbeseitigung Zu den Begriffen s. Rz. 395 und Rz. 402 ff.

483

aa) Service-Level (1) Mängel- bzw. Störungsklassifikation In Bezug auf eine nähere Ausgestaltung in SLAs werden Mängel oder Stö- 484 rungen regelmäßig einer sog. Mängel- bzw. Störungsklassifikation unterworfen1. Üblicherweise werden dabei sog. Fehlerkategorien (z.B. Fehlerklasse 1: schwere Fehler, Fehlerklasse 2: mittlere Fehler, Fehlerklasse 3: leichte Fehler) definiert, mit denen beschrieben wird, wie sich ein Fehler (= Mangel) konkret auswirkt. Die Beschreibung eines z.B. schweren oder eines mittleren Fehlers sollte individuell und abhängig von der jeweils eingesetzten Software durch die Fachabteilungen erfolgen. Dabei sollte darauf geachtet werden, dass nicht nur der rein technische Hintergrund für die Kategoriesierung maßgeblich ist, sondern – und vor allem – die konkrete Anwendung und die genutzten Funktionalitäten der Software. Je nach Auswirkung des Fehlers erfolgt eine Zuordnung des Mangels oder 485 der Störung zu der jeweiligen Fehlerkategorie entweder (je nach Vereinbarung) durch den Softwareanbieter/-hersteller oder durch den Softwareanwender. (2) Proaktive/nicht proaktive Mängel- bzw. Störungsbeseitigung Üblicherweise wird sodann zunächst festgelegt, ob der Softwareanbieter/- 486 hersteller proaktiv Mängel oder Störungen nachspüren soll oder ob er nur aufgrund einer Mängel- oder Störungsmeldung durch den Softwareanwender aktiv wird. Soll der Softwareanbieter/-hersteller proaktiv Mängel oder Störungen nach- 487 spüren, lässt sich dieser Prozess weiter beschreiben, nämlich dahingehend, was er täglich und in welchem zeitlichen Umfang und mit welchem personellen Aufwand unternehmen soll, wobei das eingesetzte Personal wiederum bestimmte Qualifikationsmerkmale besitzen muss. Dazu kommt, dass der Softwareanbieter/-hersteller z.B. täglich oder wö- 488 chentlich – in festgelegter Form etwa durch Bereithalten zum Abruf auf einem nur für den Softwareanwender zugänglichen Portal – Reports erstellt, die konkret die durchgeführten Maßnahmen beschreiben. Der Softwareanwender erhält damit die Gelegenheit, durch eigene Experten überprüfen zu lassen, ob die durchgeführten Untersuchungen dem Stand der Technik entsprechen und sinnvoll waren. Andernfalls hat er die Möglichkeit, mit-

1 So auch Schreibauer/Taraschka, CR 2003, 557.

Peter

961

I Rz. 489

Sonderregelungen

tels fest vereinbarter Eskalationsprozesse etwaige Veränderungen beim Softwareanbieter/-hersteller zu erzwingen. (3) Reaktions- und Wiederherstellungszeiten 489

Wird der Softwareanbieter/-hersteller proaktiv oder nur aufgrund einer Meldung tätig, werden regelmäßig im Fall der Meldung oder des Feststellens eines Mangels oder einer Störung konkrete Reaktions- und Wiederherstellungszeiten vereinbart, die – je nach Einordnung in die entsprechenden Fehlerkategorien – unterschiedlich ausgestaltet sind. Wiederherstellungszeiten beschreiben das Ende des Zeitraums, innerhalb dessen der Mangel oder die Störung beseitigt sein muss. Wann ein Mangel oder eine Störung als „beseitigt“ anzusehen ist, sollte wiederum klar definiert werden.

490

In diesem Zusammenhang ist insbesondere zu beachten, ob die Reaktionsoder Wiederherstellungszeiten unabhängig von Wochenenden, Feiertagen oder Tageszeiten (MEZ)1 zu bemessen sind. Andernfalls muss eindeutig festgelegt werden, ob z.B. Samstage, Sonntage und z.B. bundeseinheitliche gesetzliche Feiertage und gesetzliche und kirchliche Feiertage z.B. des Landes Nordrhein-Westfalen die Reaktions- oder Wiederherstellungszeiten unterbrechen. Schließlich muss geklärt sein, ob die Fristen nur zu bestimmten Tageszeiten (MEZ), z.B. Montag bis Donnerstag von 7.00 Uhr bis 20.00 Uhr und Freitag von 7.00 Uhr bis 15.00 Uhr laufen, so dass z.B. ein am Freitag um 14.00 Uhr gemeldeter Mangel mit einer Wiederherstellungszeit von 4 Stunden erst am Montag um 10.00 Uhr beseitigt sein muss. Die Notwendigkeit, diese Zeiten so konkret wie möglich zu definieren, wird besonders bei internationalen Projekten deutlich: Wenn z.B. ein Mangel der Kategorie 1 per E-Mail aus den USA mit einer Wiederherstellungszeit von 2 Stunden am Donnerstag um 23.00 Uhr beim Softwareanbieter/-hersteller eingeht (15.00 Uhr Ortszeit USA), muss dieser erst am Freitag um 9.00 Uhr (MEZ) beseitigt sein, und nicht schon um 17.00 Uhr Ortszeit USA (Freitag 1.00 Uhr MEZ). bb) Reporting

491

Sobald eine Mangel- oder Störungsmeldung eingegangen ist, eröffnet der Softwareanbieter/-hersteller üblicherweise ein sog. (internes) Trouble-Ticket, mit dem die Einzelheiten der Meldung und die durchgeführten Maßnahmen (wer, wann, was) dokumentiert werden. Regelmäßig wird dem Softwareanwender die Möglichkeit gegeben (Reporting), online jederzeit den aktuellen Stand der durchgeführten Maßnahmen einzusehen, um seine Experten prüfen zu lassen, ob die bislang durchgeführten Maßnahmen dem Stand der Technik entsprechen und sinnvoll sind. Andernfalls muss ein vereinbartes Eskalationsverfahren dem Softwareanwender die Möglichkeit geben, auf den Mängel- oder Störungsbeseitigungsprozess Einfluss zu nehmen. Zusätzlich können sog. Antwortzeiten (Performance) vereinbart werden, die vor1 Mitteleuropäische Zeitzone.

962

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 495 I

geben, innerhalb welcher Zeitabstände neue Reports zum Abruf bereitzustehen haben. cc) Verfügbarkeit des Service-Levels Letztlich ist es angezeigt, im Rahmen sog. Verfügbarkeiten1 zu vereinbaren, 492 ob der Softwareanbieter/-hersteller den Service-Level „Mängel- oder Störungsbeseitigung“ innerhalb einer gewissen Periode (z.B. wöchentlich oder monatlich) erreicht hat (Messbarkeit). So hätte der Softwareanbieter/-hersteller 100 % Verfügbarkeit erzielt, wenn er innerhalb der maßgeblichen Periode jede Mängel- oder Störungsmeldung innerhalb der vereinbarten Wiederherstellungszeiten beseitigt hat. Sind Wiederherstellungszeiten nicht eingehalten worden, so verringert dies das erzielte prozentuale Ergebnis entsprechend. Dabei können den unterschiedlichen Fehlerkategorien differenzierende Gewichtungen zugewiesen werden, so dass die Verfehlung einer Wiederherstellungszeit bei einem Mangel der Fehlerkategorie 1 wesentlich schwerer wiegt, als bei der Fehlerkategorie 3. Üblicherweise werden Verfügbarkeiten unterhalb der 100-Prozent-Marke vereinbart. Die zu vereinbarende Prozentzahl (z.B. 98,5 %) ist abhängig von deren konkreter Auswirkung, orientiert an den Fragen: Ist es für den Softwareanwender noch akzeptabel, dass bei der vorgeschlagenen Prozentzahl eine bestimmte Größenordnung von Überschreitungen der Wiederherstellungszeiten unsanktioniert bleibt und die Höhe des Entgelts nicht beeinflusst? Ist es für den Softwareanbieter/-hersteller unter diesen Umständen noch wirtschaftlich, die angebotenen Leistungen zu dem vereinbarten Entgelt vergütet zu erhalten? dd) Sanktionen Im Rahmen des Service-Level-Agreements ist es wesentlich, dass im Fall 493 des Nichterreichens der vereinbarten Service-Level – wie immer diese auch im Einzelfall ausgestaltet sind – Sanktionen vereinbart werden. Üblicherweise werden dazu Vertragsstrafenregelungen oder pauschalierter Schadensersatz bzw. pauschale Entgelterstattungen (Malus) vereinbart. Bei der Entscheidung, welche der vorgenannten Sanktionen gewählt bzw. 494 wie die jeweilige Sanktion ausgestaltet wird, sollte bedacht werden, dass die Wahl und die Ausgestaltung Auswirkung auf die Entgeltbemessung des Softwareanbieters/-herstellers hat. Wird z.B. die Vertragsstrafe gewählt und soll diese – entgegen der gesetzlich Vorgabe2 – verschuldensunabhängig verwirkt werden, so hat dies erhebliche Auswirkung auf die Entgeltkalkulation des Softwareanbieters/-herstellers, da dieser das verschuldensunabhängige Haftungsrisiko über ein entsprechend höheres Entgelt absichern muss. Wenn Service-Levels gewählt werden, so sollten die damit vereinbarten 495 Sanktionen – zumindest per Individualvertrag – abschließend vereinbart 1 Peter, CR 2005, 404. 2 Wortlaut § 338 BGB: „…, wenn er in Verzug kommt.“ und § 286 Abs. 4 BGB.

Peter

963

I Rz. 496

Sonderregelungen

werden, wobei die Geltendmachung von Schadensersatzansprüchen unberührt bleiben muss, zumal die Haftung für vorsätzliches eigenes Handeln im Vorhinein nicht rechtswirksam erlassen werden kann (§ 276 Abs. 3 BGB), um für beide Vertragsparteien in Bezug auf Rechtsfolgen eindeutige Klarheit zu erlangen. Andernfalls führt die parallele Anwendung des Mängelhaftungsrechts zu einer zusätzlichen Erhöhung des Entgelts, da der Softwareanbieter/-hersteller auch diesen Umstand in seiner Entgeltkalkulation berücksichtigen muss. 496

Letztlich soll nicht verschwiegen werden, dass bei einem Übertreffen der vereinbarten Verfügbarkeitsquoten ein sog. Bonus vereinbart werden kann. Dieser hat den Zweck, dass eine Mehrleistung der Softwareanbieter/-hersteller belohnt wird, indem das vereinbarte Entgelt für den betroffenen Service-Level angehoben wird. ee) Vertragstypologische Einordnung, Verhältnis allgemeines Leistungsstörungsrecht zu Mängelhaftung

497

Wie bereits unter Rz. 395 ff., 402 ff., 466 dargelegt, überwiegt in Bezug auf die Mängel- und Störungsbeseitigung das erfolgsbezogene Element, so dass auf dieses Leistungsversprechen Werkvertragsrecht Anwendung finden dürfte1.

498

Das Service-Level-Agreement sollte jedoch zusätzlich regeln, was gelten soll, wenn der Softwareanbieter/-hersteller einen Mangel oder eine Störung nicht nur nicht rechtzeitig beseitigen konnte, sondern wenn der Mangel oder die Störung über einen festzulegenden Zeitpunkt hinaus immer noch ganz oder teilweise vorliegt; andernfalls muss auf die Gesetzeslage zurück gegriffen werden.

499

Zunächst dürfte klar sein, dass der Softwareanbieter/-hersteller nach wie vor zur Mängel- bzw. Störungsbeseitigung verpflichtet bleibt und er seine Leistung nicht rechtzeitig erbracht hat. Danach kann der Softwareanwender immer den Weg über § 280 Abs. 2 BGB i.V.m. § 286 BGB gehen, um den Verzögerungsschaden geltend zu machen.

500

Solange und soweit der Softwareanbieter/-hersteller den Mangel bzw. die Störung nicht einmal teilweise beseitigt hat, dürften sich die Rechte des Softwareanwenders nach allgemeinem Leistungsstörungsrecht richten2. Hat der Softwareanbieter/-hersteller den Mangel bzw. die Störung teilweise beseitigt, ist offen und ungeklärt, ob die unmittelbare Anwendung des allgemeinen Leistungsstörungsrechts verlassen werden kann, um über die Abnahme

1 S. auch Schneider, CR 2005, 695 im Zusammenhang mit einem Service-LevelAgreement (SLA). 2 Zum Verhältnis der Mängelrechte zu dem allgemeinen Rechten des Bestellers siehe Palandt/Sprau, Vorb. vor § 633 BGB Rz. 6 f.

964

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 504 I

(§ 640 BGB) das besondere Leistungsstörungsrecht des Werkvertragrechts (Mängelhaftung) in Anspruch zu nehmen (s. hierzu auch Rz. 522 ff.)1. b) Funktionale Verbesserungen, Anpassungen, zusätzliche oder geänderte Funktionen und sonstige Anpassungen/Korrekturen Zu den Begriffen s. Rz. 43 f.

501

aa) Service-Level und Reporting Unabhängig von der Beantwortung der Frage, wie die maßgeblichen Leis- 502 tungen vertragstypologisch einzuordnen sind (s. hierzu Rz. 470) dürfte hier ein Service-Level beschrieben werden können, mit dem festgelegt wird, in welchen Zeitabständen und mit welchem personellen Einsatz sich der Softwareanbieter/-hersteller um die Definition und Umsetzung von Verbesserungen oder Anpassungen der Software etc. zu bemühen hat (Performance). Dabei kann vereinbart werden, dass der Softwareanbieter/-hersteller innerhalb bestimmter zeitlicher Perioden dem Softwareanwender Vorschläge/Ergebnisentwürfe zu unterbreiten hat, die der Softwareanwender sodann durch seine Experten dahingehend überprüfen lassen kann, ob diese dem Stand der Technik entsprechen und sinnvoll sind (Reporting). Andernfalls muss der Softwareanwender mittels eines Eskalationsprozesses die Gelegenheit haben, auf die Entscheidungen des Softwareanbieter/-hersteller Einfluss nehmen zu können. Letztlich ist festzulegen, in welchen Zeitabständen bzw. zu welchen Zeitpunkten der Softwareanbieter/-hersteller die Verbesserungen oder Anpassungen etc. als Update oder Upgrade zu liefern hat. bb) Verfügbarkeit des Service-Levels und Sanktionen Werden alle vereinbarten Lieferungen in dem festgelegten Umfang inner- 503 halb einer vereinbarten Periode (z.B. einem Vertragsjahr) rechtzeitig geliefert, hat der Softwareanbieter/-hersteller die Verfügbarkeit zu 100 % erfüllt. Üblicherweise werden jedoch geringere Verfügbarkeitsquoten vereinbart (z.B. 99 %), so dass erst eine Unterschreitung des abgestimmten Wertes Sanktionen auslösen können2. Zu den Sanktionen s. Rz. 493 ff. 4. Hotline Zum Begriff s. Rz. 445.

504

1 Zur Anwendbarkeit des Nacherfüllungsanspruches, wenn die Verfügbarkeit der Software Gegenstand des SLAs ist s. Schneider, CR 2005, 695. 2 Peter, CR 2005, 404.

Peter

965

I Rz. 505

Sonderregelungen

a) Service-Level und Reporting 505

Maßgeblich für den Softwareanwender ist, dass die zum Anruf berechtigten Personen sofort in unmittelbaren Kontakt mit dem Hotlineberater treten können und nicht in eine Warteschleife laufen bzw. der Hotlineanschluss besetzt ist. Andernfalls wollen sie sofort zurück gerufen werden und innerhalb eines maximal definierten Zeitraums eine qualifizierte Beantwortung ihrer Fragen bzw. die Problemlösung erhalten. Qualitätskriterien sind für den Softwareanwender daher zum einen inhaltliche (Qualität der Beantwortung/Problemlösung) und zum anderen objektive (Anzahl der unmittelbaren Kontaktaufnahme) Umstände.

506

Bei der Festlegung des zu bemessenden Zeitraums für die Beantwortung von Fragen/Problemlösungen besteht wiederum eine Abhängigkeit von der Art und dem Umfang der zu beantwortenden Fragen bzw. Lösung der vorgetragenen Probleme. Diese können unterteilt werden in „schwere“, „mittelschwere“ und „einfache“ Fragen/Probleme, so dass daran unterschiedliche Zeiträume geknüpft werden, die zur Beantwortung bzw. Problemlösung zur Verfügung stehen. Die Einordnung in die entsprechenden Schweregrade muss durch einen der beiden Vertragspartner vorgenommen werden. Dem jeweils anderen muss die Möglichkeit eröffnet sein, im Weg eines Eskalationsverfahrens auf die Entscheidung Einfluss nehmen zu können.

507

Zusätzlich kann als Service-Level vereinbart werden, dass jeder Anruf an die Hotline innerhalb von z.B. 30 Sekunden entgegen genommen werden muss; andernfalls gelten diese Anrufe als verfehlt.

508

Regelmäßig sollte sodann der Softwareanbieter/-hersteller dem Softwareanwender zu festgelegten Perioden (z.B. wöchentlich) eine Übersicht über die Anzahl der Anrufe, ihre Annahmen innerhalb der vereinbarten Zeit und eine Auflistung der Anzahl der gestellten Fragen/Probleme nach Schweregrad und eine Tabelle über die Anzahl ihrer zeitgerechten Erledigung offenlegen (Reporting). b) Verfügbarkeit und Sanktionen

509

Sollten sämtliche Anrufe innerhalb der vorgegeben Zeit entgegen genommen und alle Fragen/Probleme je nach Schweregrad zeitgerecht beantwortet worden sein, hat der Softwareanbieter/-hersteller die Verfügbarkeit zu 100 % erfüllt. Üblicherweise werden jedoch geringere Verfügbarkeitsquoten vereinbart (z.B. 99 %)1, so dass erst eine Unterschreitung des abgestimmten Werts Sanktionen auslösen kann.

510

Da aufgrund des Fernmeldegeheimnisses der Inhalt der Hotline-Anrufe grundsätzlich nicht abgehört werden darf, kann zur Feststellung der Verfügbarkeit des Service-Levels auch eine Anrufer-Zufriedenheitsanalyse durchgeführt werden, die aus datenschutzrechtlichen Gründen anonym zu 1 Peter, CR 2005, 404.

966

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 518 I

erfolgen hat. Die zu beantwortenden Fragen sollten klar, eindeutig und bestenfalls nur mit „Ja“ oder „Nein“ zu beantworten sein. Die Anzahl der gestellten Fragen sollte überschaubar bleiben, damit sich möglichst viele Anrufer an der Zufriedenheitsanalyse beteiligen. In Bezug auf die Auswertung der Fragen sollten diese vorher einvernehmlich gewichtet und mit einem Zielerreichungsgrad in Prozent belegt werden, so dass eine Auswertung durchgeführt werden kann. Das Maß des Erreichens der Verfügbarkeit des Service-Levels richtet sich in diesem Beispiel nach der Zufriedenheit der Hotline-Anrufer.

511

Zu den Sanktionen s. Rz. 493 ff.

512

5. Mitwirkungspflichten des Softwareanwenders Das Scheitern von Projekten beruht in vielen Fällen auf der mangelnden Zusammenarbeit der Vertragsparteien und der Unklarheit, wer für was verantwortlich ist1.

513

Daher ist es entscheidend, dass bei allen Service-Levels die Rollen des Soft- 514 wareanwenders und seine Verantwortlichkeiten definiert werden, womit der Grundstein für den reibungslosen Ablauf der Zusammenarbeit gelegt ist. 6. Eskalationsprozess Der Eskalationsprozess dient dazu, Meinungsverschiedenheiten einer 515 schnellen Klärung zuzuführen. Zu diesem Zweck sollten sog. Eskalationsstufen definiert werden, bei denen auf beiden Seiten der Vertragspartner feste Ansprechpartner bestimmt werden, die innerhalb eines festgelegten Zeitraums zu versuchen haben, eine einvernehmliche Lösung herbeizuführen. Wichtig ist, dass die Fristen (Beginn und Ende), innerhalb derer die Eskalationsstufen zu entscheiden haben, klar und eindeutig definiert sind. Außerdem müssen die Umstände und Fristen bezeichnet sein, unter denen 516 die Meinungsverschiedenheit einer nächsten Eskalationsstufe zugeführt wird, falls die erste Stufe kein Einvernehmen herbeiführen kann. Einigkeit sollte in jedem Fall darüber bestehen, dass entweder die einver- 517 nehmliche Lösung bzw. das Scheitern der Eskalation schriftlich dokumentiert und von beiden Ansprechpartnern der entsprechenden Eskalationsstufe unterzeichnet wird, um spätere Gedächtnisprotokolle und daraus resultierende Uneinigkeiten und Missverständnisse zu vermeiden. Letztlich sollte eine Regelung darüber getroffen werden, ob die Vertrags- 518 parteien während der Durchführung des Eskalationsprozesses den ordentli-

1 Redeker, ITRB 2011, 65; Müglich/Lapp, CR 2004, 801.

Peter

967

I Rz. 519

Sonderregelungen

chen Gerichtsweg oder das Schiedsgerichtsverfahren beschreiten dürfen oder nicht, wobei Maßnahmen des einstweiligen Rechtsschutzes auszunehmen sind; diese müssen immer möglich sein. Dies lässt sich dadurch ergänzen, dass erst nach Ablauf einer gewissen Frist nach Scheitern der Eskalation der Rechtsweg zu den ordentlichen Gerichten eröffnet sein soll, um den Vertragsparteien die Möglichkeit zu geben, ggf. im Nachgang und außerhalb der im Service-Level hinterlegten Prozesse Einvernehmen zu erzielen. Je nachdem sollte dem Gang zu den ordentlichen Gerichten oder den Schiedsgerichten ein sog. Mediationsverfahren vorangestellt werden, um doch noch ein außergerichtliches Einvernehmen herbeiführen zu können. 519

Damit über den Vertragsparteien während der Durchführung des Eskalationsprozesses nicht das Damoklesschwert der Verjährung oder des Ablaufs etwaiger Ausschlussfristen schwebt, sollte eine Vereinbarung aufgenommen werden, wonach das Eskalationsverfahren die Verjährungs- und Ausschlussfristen für alle Ansprüche aus dem streitigen Sachverhalt gemäß bzw. entsprechend § 203 BGB hemmt.

XII. Sonstiges 1. Nutzungsrechte 520

Der Softwareanwender sollte darauf achten, an den gelieferten Programmkorrekturen und Dokumentationen in Art und Umfang dieselben Nutzungsrechte zu erhalten, wie er sie für die überlassene Software und Dokumentation erhalten hatte1. Die EVB-IT Pflege S2 enthält hierzu in Ziff. 3 eine ausdrückliche Regelung entsprechend der vorstehenden Empfehlung. Die BVB-Pflege3 beinhaltet hingegen keine gesonderte Regelung zu den Nutzungsrechten. Es ist möglich, unter Ziff. 11.4 des Pflegescheins zu dem Vertrag über die Pflege von DV-Programmen entsprechende Änderungen und Ergänzungen aufzunehmen. Zur Einräumung von Nutzungsrechten s. im Übrigen Kap. A Rz. 115 ff. und 151 ff. 2. Pflichten und Obliegenheiten des Softwareanwenders

521

Des Weiteren empfiehlt es sich, Pflichten oder Obliegenheiten des Softwareanwenders im Softwarepflegevertrag aufzunehmen, damit die reibungslose Erfüllung der vom Softwareanbieter geschuldeten Leistungen sicher-

1 Zur Thematik, dass die ursprünglich überlassene Software im Rahmen der Durchführung des Softwarepflegevertrages durch Einspielen von Updates, Upgrades quasi zu einer neuen Software inhaltlich abgewandelt wird, siehe Schneider, CR 2011, 626; zu Problemen mit sog. Click-Wrap-Agreements s. Karger, ITRB 2003, 134. 2 Ergänzende Vertragsbedingungen für die Pflege von Standardsoftware. 3 Besondere Vertragsbedingungen für die Pflege von DV-Programmen.

968

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 527 I

gestellt wird (s. hierzu auch Kap. D Rz. 223 ff.)1. Auch hierzu enthält die EVB-IT Pflege S eine ausdrückliche Regelung2, die BVB-Pflege jedoch nicht. 3. Mängelhaftung versus Erfüllungsanspruch und Verjährung Die Mängelhaftung richtet sich – je nach vertragstypologischer Einordnung 522 der gestörten Pflegeleistung (zur vertragstypologischen Einordnung und der Typisierung s. Rz. 458 ff. und 471) – nach besonderem Leistungsstörungsrecht, welches regelmäßig3 auf das allgemeine Leistungsstörungsrecht verweist. Wird eine Leistung aus dem entgeltlichen Softwarepflegevertrag unmöglich 523 (§ 275 BGB), wird eine fällige Leistung nicht oder nicht wie geschuldet erbracht (§ 281 BGB), richten sich die Rechtsfolgen unmittelbar nach den §§ 280 ff., 323 ff. BGB (allgemeines Leistungsstörungsrecht), es sei denn, eine Leistung wurde mangelhaft erbracht, weshalb nur in diesem Fall zunächst der Weg über das besondere Leistungsstörungsrecht zu gehen ist. Soweit für den in Betracht kommenden Vertragstyp besonderes Leistungsstörungsrecht gesetzlich definiert ist, ist im Einzelfall zu prüfen, ob dieses schon oder noch nicht zur Anwendung gelangt; wenn es nicht heranzuziehen ist, verbleibt es bei dem allgemeinen Leistungsstörungsrecht.

524

Die Softwarepflege wirft jedoch wegen ihres Charakters als Dauerschuld- 525 verhältnis die Frage auf, ob während des Laufs des Softwarepflegevertrags überhaupt Mängelhaftungsrecht anzuwenden ist, wenn der Softwareanbieter gleichzeitig die Mängelbeseitigung schuldet4. Zunächst ist hierzu festzuhalten, dass nach der Rechtsprechung des BGH 526 eine dauernde (Werk-)Leistung und eine Vergütung nach Zeitabschnitten die Annahme eines Werkvertrags sowie die Anwendung des werkvertraglichen Mängelhaftungsrechts nicht hindert5. Daher dürfte nichts dagegen sprechen, jedes gesonderte – auch erfolglose – 527 immer wiederkehrende Tätigwerden des Softwareanbieters dahingehend, einzelne identifizierte Mängel zu beseitigen, ebenso als gesonderte werkver1 2 3 4

Redeker, ITRB 2011, 65. Ziff. 2 der EVB-IT Pflege S. S. hingegen z.B. beim Mietvertrag §§ 536 ff. BGB. Bischof/Witzel, ITRB 2003, 31 (mit Verweis auf Goldmann/Redecke, MMR 2002, 6 und Lejeune, K&R 2002, 441) und Bartsch, NJW 2002, 1526, die während des Laufs des Softwarepflegevertrages wegen der Verpflichtung zur Mängelbeseitigung keine Gewährleistungsansprüche für möglich halten und daher das Gewährleistungsrecht erst nach Beendigung des Pflegevertrages in Betracht kommt. Im Übrigen käme während der Laufzeit der Softwarepflege nur Kündigung aus wichtigem Grund in Betracht. Vgl. auch LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 5 BGH NJW 2002, 116 (Ausführung von Buchführungsarbeiten und Entwürfe der Jahresabschlüsse); BGH, BB 1962, 497.

Peter

969

I Rz. 528

Sonderregelungen

tragliche Leistung i.S.d. § 631 Abs. 1 BGB zu qualifizieren und im Fall der Mangelhaftigkeit der erbrachten Leistung, Mängelhaftungsrecht anzuwenden. Denn der vertragliche Erfüllungsanspruch auf Beseitigung von Mängeln an der überlassenen Software konkretisiert sich im Fall ihrer Identifizierung eben auf diese so festgestellten Mängel, deren Beseitigung auch erfolglos, mithin mangelhaft erfolgen kann. 528

Dass der Softwarepflegevertrag insoweit ebenfalls ein Dauerschuldverhältnis darstellt (s. hierzu Rz. 461) führt lediglich dazu, dass § 314 BGB zusätzlich in den Anwendungskreis einzubeziehen ist (zu § 314 BGB s. Rz. 134 ff.). Eine Qualifizierung als Dauerschuldverhältnis schließt die Anwendung des Werkvertragsrechts nicht per se aus1. Das Mängelhaftungsrecht wird hierdurch nicht automatisch ausgeschlossen, was schon alleine § 634a Abs. 1 Nr. 1 BGB in Bezug auf die Verjährungsregelung zu Wartungsleistungen zeigt, welche typischerweise auf Dauer angelegt sind2.

529

Die Anwendung des werkvertraglichen Mängelhaftungsrechts während der Laufzeit des Softwarepflegevertrags stellt sich exemplarisch wie folgt dar: Unabhängig davon, ob ein aktuell aufgekommener Mangel der Software mittels Lieferung einer Programmkorrektur oder trotz Vor-Ort-Services eines Softwaretechnikers beim Softwareanwender fehl schlägt, gilt: Ist diese Leistung mangelhaft, weil der vereinbarte Erfolg (Mängelbeseitigung) nicht eingetreten ist, und hat der Softwareanwender die werkvertragliche Leistung nicht abgenommen, verbleibt es beim Erfüllungsanspruch und das allgemeine Leistungsstörungsrecht findet Anwendung3. Mit Abnahme4 – und deren Erklärung hat allein der Softwareanwender in der Hand5 – beschränkt sich der Erfüllungsanspruch des Softwareanwenders auf das abgenommene Werk, mithin auf die Leistung, mit der der Softwareanwender versucht hatte, identifizierte Mängel der Software zu beseitigen; seine Ansprüche richten sich diesbezüglich ausschließlich nach § 634 BGB6, deren Verjährung nach § 634a BGB nunmehr zu laufen beginnt. Bezüglich anderer oder zu1 BGH v. 4.3.2010 – III ZR 79/09, Internet-System-Vertrag 1, CR 2010, 327. 2 BGH v. 4.3.2010 – III ZR 79/09, Internet-System-Vertrag 1, CR 2010, 327. A.A. LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414 mit dem Argument, dass das Gewährleistungsrecht erst dann einsetzt, wenn den Lieferanten keine „echte“ Erfüllungspflicht mehr trifft, was während der Laufzeit des Softwarepflegevertrages nie der Fall ist, denn: Der Lieferant ist aus dem Softwarepflegevertrag zur Beseitigung auftretender Mängel verpflichtet, so dass während der Laufzeit eines Softwarepflegevertrages kein Bedarf besteht, auf das Gewährleistungsrecht zurückzugreifen. 3 Palandt/Sprau, Vorb. vor § 633 BGB Rz. 7. 4 Müller-Hengstenberg/Kirn, CR 2008, 755: Die technologischen und rechtlichen Zusammenhänge der Test- und Abnahmeverfahren bei IT Projekten; Bartsch, CR 2006, 7: Themenfelder einer umfassenden Regelung der Abnahme. 5 Gleichwohl kann eine Abnahme aufgrund vereinbarter oder gesetzlicher Abnahmefiktionen eintreten, z.B. aufgrund § 640 Abs. 1 Satz 3 BGB. 6 Palandt/Sprau, Vorb. vor § 633 BGB Rz. 8; a.A. LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414 mit Verweis auf Bartsch, NJW 2002, 1526.

970

Peter

Softwarepflege inklusive Service-Level-Agreement

Rz. 533 I

künftig identifizierter Mängel der Software verbleibt es zunächst bei dem vertraglich vereinbarten Erfüllungsanspruch auf deren Beseitigung. Der Softwareanwender ist nicht verpflichtet, Ansprüche aus dem allgemeinen oder besonderen Leistungsstörungsrecht geltend zu machen; es bleibt ihm unbenommen, weiterhin vertragliche Erfüllung, also Beseitigung der identifizierten Mängel zu verlangen.

530

Der zuvor bezeichnete Weg gilt grundsätzlich für jeden identifizierten Man- 531 gel der Software und den erfolglosen Versuch seiner Beseitigung, weil erst der erfolglose Versuch die einzelne mangelhafte werkvertragliche Leistung darstellt, auf die der Softwareanwender seine Ansprüche über § 634 BGB konzentrieren kann. Bleibt der Softwareanwender z.B. bezüglich eines Mangels immer auf der Er- 532 füllungsebene und ist der Softwarepflegevertrag beendet, so dass vertragliche Erfüllung nicht mehr geltend gemacht werden kann, fragt sich, ob der Softwareanwender in dem vorstehenden Beispiel noch nach allgemeinem oder besonderem Leistungsstörungsrecht vorgehen kann, wenn der Softwareanwender während der Laufzeit des Softwarepflegevertrags die Abnahme – ausdrücklich oder stillschweigend – nicht erklärt hatte und keine Abnahmefiktion besteht1. Bei der Beantwortung der vorstehenden Frage ist wie folgt zu differenzieren: Hatte der Softwareanbieter gar nichts zur Beseitigung konkret spezifischer Mängel unternommen, so dürfte das allgemeine Leistungsstörungsrecht Anwendung finden, da der Softwareanbieter nicht einmal im Ansatz etwas geleistet hat, was als werkvertragliche Leistung bezeichnet werden könnte. Der Anspruch auf Erfüllung unterliegt der regelmäßigen Verjährung (§ 195 BGB), die u.a.2 mit dem Schluss des Jahres beginnt, in dem der Anspruch entstanden ist (§ 199 Abs. 1 Nr. 1 BGB), so dass einem Rücktritt die Einrede des § 218 BGB entgegen gesetzt werden kann3, wenn Verjährung des Erfüllungsanspruchs eingetreten ist; Schadensersatzansprüche aus den §§ 280 ff. BGB unterliegen ebenfalls der Regelverjährung nach § 195 BGB4. Bei der Einrede des § 218 BGB ist auf den Zeitpunkt der Beendigung des Softwarepflegevertrags abzustellen und nicht auf den Zeitpunkt, als der Mangel entstanden ist oder erstmals identifiziert wurde. Denn andernfalls würde die Übereinkunft der Vertragsparteien übergangen, dass der Softwareanwender

1 Bischof/Witzel, ITRB 2003, 31 (mit Verweis auf Goldmann/Redecke, MMR 2002, 6 und Lejeune, K&R 2002, 441); Bartsch, NJW 2002, 1526, die während des Laufs des Softwarepflegevertrages wegen der Verpflichtung zur Mängelbeseitigung keine Gewährleistungsansprüche für möglich halten und daher das Gewährleistungsrecht erst nach Beendigung des Pflegevertrages in Betracht kommt. 2 S. § 199 Abs. 1 Nr. 2 BGB. 3 Palandt/Grüneberg, § 323 BGB Rz. 33. 4 Palandt/Ellenberger, § 195 BGB Rz. 4.

Peter

971

533

I Rz. 534

Sonderregelungen

bis zum Schluss, mithin bis zur Beendigung des Softwarepflegevertrags (immer wieder), die Beseitigung der Mängel schuldet (Dauerschuldverhältnis). 534

Hatte der Softwareanbieter erfolglos versucht, die konkret spezifischen Mängel zu beseitigen, ist fraglich, ob der Softwareanwender auch nach Beendigung des Softwarepflegevertrages die Abnahme erklären und den Weg über § 634 BGB gehen kann. Nimmt man an, dass diese Vorgehensweise zulässig ist, so gilt weiter: Die Verjährung richtet sich nach § 634a BGB, wobei der Verjährungsbeginn unterschiedlich ausgestaltet ist, je nachdem, ob § 634a Abs. 1 Nr. 1 oder Nr. 3 BGB Anwendung findet (s. hierzu Rz. 33, 34). In beiden Fällen ist die Abnahme maßgeblicher Auslösungsfaktor. Hier stellt sich jedoch die weitere ungeklärte Frage, ob der Softwareanwender – wenn er z.B. zehn Jahre nach Beendigung des Softwarepflegevertrags die Abnahme erklärt – noch Ansprüche über § 634 BGB geltend machen darf. Die Lösung dürfte wohl über § 242 BGB zu suchen sein und es ist offen, wie die Gerichte im Einzelfall hierzu entscheiden werden1. Zu Leistungsstörungen im Übrigen s. Kap. D Rz. 245 ff. 4. Vertragsübernahme und Herausgabe/Hinterlegung des Quellcodes

535

Die Übernahme von Rechten und Pflichten einer Vertragspartei durch einen Dritten folgt den allgemeinen Regeln2. Soweit die Software inklusive der Programmkorrekturen/Dokumentationen an den Dritten übertragen werden soll, ist darauf zu achten, dass der Übertragende hierfür die urheberrechtlichen Nutzungsrechte innehat (§§ 31 ff. UrhG), soweit dies der urheberrechtliche Erschöpfungsgrundsatz (§ 17 Abs. 2 UrhG)3 nicht entbehrlich macht. Ebenfalls sollte der Übertragende sicherstellen, dass er auch nicht schuldrechtlich an der Weiterübertragung gehindert ist, z.B. auf Grund der Verpflichtung, vor einer Weiterübertragung die Zustimmung des urheberrechtlich Berechtigten einholen zu müssen.

536

Die Verweigerung der Zustimmung zur Vertragsübernahme stellt keinen wichtigen Grund zur Kündigung des Softwarepflegevertrags dar, wenn eine Verpflichtung zur Zustimmung nicht vertraglich vereinbart ist; eine derartige Verpflichtung folgt auch nicht aus § 242 BGB4.

537

Zur Herausgabe des Quellprogramms (auch „Source Code“ genannt) und Hinterlegung des Source Codes s. Kap. L Rz. 112 ff.; 24 ff.

1 S. hierzu LG Bonn v. 19.12.2003 – 10 O 387/01, CR 2004, 414. 2 Allgemein: Palandt/Grüneberg, § 398 BGB Rz. 41 ff. Zur Vertragsübernahme durch Rechtsnachfolge s. BGH v. 20.6.1985 – IX ZR 173/84, MDR 1985, 1021 = NJW 1985, 2528. 3 Schneider, CR 2009, 553 zur rechnerspezifischen Erschöpfung bei Software im Bundle ohne Datenträgerübergabe. 4 Zahrnt, Entscheidungen zum Computerrecht-ECR, OLG 283 (OLG Köln v. 17.7.1998).

972

Peter

4. Kapitel Leistungsstörungen J. Individualvereinbarung Rz. I. Ausgangspunkt: Individualvertrag gemäß § 305 Abs. 1 Satz 3 BGB . . . . . . . . . . . . . . . . . . II. Stellen, Vorformulieren – Vielzahl – AGB-Klausel . . . . . . . 1. Vertragsbedingungen, Vorformulieren . . . . . . . . . . . . . . 2. Vielzahl . . . . . . . . . . . . . . . . . . . . . 3. Stellen . . . . . . . . . . . . . . . . . . . . . . 4. Auftraggeber als AGB-Verwender . . . . . . . . . . . . . . . . . . . . . . 5. Auftragnehmer als AGB-Verwender . . . . . . . . . . . . . . . . . . . . . . a) Umgedrehte Rolle: der Auftragnehmer als Verwender . . b) Stellungnahme . . . . . . . . . . . . 6. Typizität: Anschein einer AGB-Klausel. . . . . . . . . . . . . . . . . a) Grundsätzliche Aussage . . . . b) Stellungnahme . . . . . . . . . . . . 7. Beiderseitiges Einbeziehungsverlangen . . . . . . . . . . . . . . . . . . . . III. Einbeziehung der AGB-Klauseln . . . . . . . . . . . . . . . . . . . . . . . . . 1. Grundsatz . . . . . . . . . . . . . . . . . . . 2. Kaufmännisches Bestätigungsschreiben . . . . . . . . . . . . . . . . . . . . 3. Kollision von Vertragsbedingungen . . . . . . . . . . . . . . . . . . . . . . a) Nachteile für den Auftraggeber . . . . . . . . . . . . . . . . . . . . . b) Nachteile für den Auftragnehmer . . . . . . . . . . . . . . . . . . .

1 5 5 9 15 17 18 19 21 22 22 23 25 26 26 27 29 31 32

IV. Individualvereinbarung – Aushandeln – § 305 Abs. 1 Satz 3 BGB . . . . . . . . . . . . . . . . . . 33

Rz. 1. Regelsatz der BGH-Judikatur . . 2. Unveränderte Übernahme einer Klausel . . . . . . . . . . . . . . . . . a) Ausgangslage der Rechtsprechung . . . . . . . . . . . . . . . . . b) Versuch einer Konkretisierung . . . . . . . . . . . . . . . . . . . . . . c) Eigene Auffassung. . . . . . . . . . aa) Abänderungsbereitschaft bb) Vorliegen „besonderer Umstände“. . . . . . . . . . . . . d) Instanzgerichtliche Rechtsprechung – Literatur . . . . . . . e) Schiedsgerichtliches Urteil. . 3. Besondere Konstellationen . . . . a) Grundansatz: § 311 Abs. 2 BGB . . . . . . . . . . . . . . . . . . . . . . b) Unabdingbare Klausel . . . . . . c) Sachliche Notwendigkeit einer Klausel . . . . . . . . . . . . . . d) Tarifwahl. . . . . . . . . . . . . . . . . . e) Verbot des planmäßigen Abweichens . . . . . . . . . . . . . . . f) Reichweite des Aushandelns . . . . . . . . . . . . . . . . . . . . . . aa) Grundsatz. . . . . . . . . . . . . . bb) Bestimmung der Reichweite . . . . . . . . . . . . . 4. Darlegungs- und Beweislast . . . a) Grundsatz . . . . . . . . . . . . . . . . . b) Beweiserleichterungen. . . . . . c) Nachweis des Individualvertrages . . . . . . . . . . . . . . . . . . d) Nachteile für den Kunden des AGB-Verwenders . . . . . . .

Graf von Westphalen

33 36 36 37 41 41 42 44 49 56 57 60 61 63 65 67 67 70 73 73 76 77 81

973

J Rz. 1

Leistungsstörungen

I. Ausgangspunkt: Individualvertrag gemäß § 305 Abs. 1 Satz 3 BGB 1

Bei einem Software-Erstellungsvertrag kommt es – jedenfalls aus der Sicht des Auftragnehmers beleuchtet – entscheidend darauf an, die Haftungsrisiken, die ja immer das Ergebnis der Verletzung von vertraglichen bzw. gesetzlichen Pflichten sind, angemessen auf Grund einer Individualvereinbarung zu begrenzen. Denn nur unter dieser Voraussetzung besteht für den Auftragnehmer die Möglichkeit, diese Risiken in vertretbaren Grenzen zu halten und diese auch – soweit möglich – kalkulatorisch in Form von hinreichenden Risikozuschlägen zu berücksichtigen. Folglich wird es für den Auftragnehmer von grundlegender Bedeutung sein, im Rahmen der Vertragsverhandlungen sicherzustellen, dass Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln nicht als AGB-Klauseln zu qualifizieren sind, sondern dass sie den Rang einer – ausgehandelten – Individualvereinbarung gemäß § 305 Abs. 1 Satz 3 BGB erreichen. Um dieses Risiko plastisch werden zu lassen, geht es im Kern darum, nachfolgend (K Rz. 1 ff.) die Wirksamkeitsgrenzen von formularmäßigen Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln im unternehmerischen Bereich nach § 307 BGB zu umschreiben.

2

Vorgeschaltet bleibt aber aus der Perspektive des Auftragnehmers die Antwort auf die Frage, unter welchen Voraussetzungen es unter Berücksichtigung der BGH-Judikatur möglich ist, dass eine AGB-Klausel in den Rang eines Individualvertrages gemäß § 305 Abs. 1 Satz 3 BGB gelangt (Rz. 33 ff.). Denn für etwa individualvertraglich fixierte Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln gelten dann nicht die engen Schranken der Wirksamkeit nach § 307 BGB, sondern die weiten Grenzen, die sich – ganz allgemein – aus den Merkmalen der Sittenwidrigkeit nach § 138 BGB oder aus denen der Gesetzeswidrigkeit gemäß § 134 BGB ableiten lassen. Unter diesem Gesichtswinkel sind lediglich die Fälle relevant, in denen entweder eine Beschaffenheitsgarantie nach den §§ 444, 639 BGB vorliegt oder die Haftung für vorsätzliches oder gar arglistiges Verhalten des Auftragnehmers (§§ 276 Abs. 3, 123, 444, 639 BGB) abbedungen worden ist.

3

Die praktische Brisanz dieser auf individualvertragliche Regelungen abzielenden Frage wird für den Auftragnehmer durch eine doppelte Erwägung untermauert: Zum einen steht unter Berücksichtigung der Rechtsprechung fest, dass die Maßstäbe der richterlichen Inhaltskontrolle gemäß § 307 Abs. 2 Nr. 1 BGB so engmaschig gehandhabt werden, dass auf diesem Wege das dispositive Recht praktisch zum zwingenden Recht geworden ist. Mit anderen Worten: Abweichungen vom dispositiven Recht, wie sie insbesondere aufgrund der Risikoverlagerung für Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln prototypisch sind, sind nahezu ausgeschlossen (K Rz. 1 ff.). Doch ist diese vor allem auf die Interpretation von § 307 Abs. 2 Nr. 1 BGB aufbauende Aussage nicht nur auf diese Klauseln beschränkt. Vielmehr handelt es sich hierbei um einen allgemeinen Befund: Gleichgültig wel974

Graf von Westphalen

Rz. 5 J

Individualvereinbarung

che AGB-Klausel im Einzelfall in Rede steht, immer ist es so, dass auch im unternehmerischen Bereich Abweichungen vom dispositiven Recht und damit Risikoverlagerungen zum Nachteil des anderen Vertragsteils nur in sehr engen Grenzen die Chance haben, die Hürden der richterlichen Inhaltskontrolle zu meistern. Ob es sich dabei um Vertragsstrafenklauseln, um Schadenspauschalen, um Preisanpassungen, um Vertragsänderungen oder auch um Beendigungsklauseln handelt, immer ist die Kontrollfrage nach § 307 Abs. 2 Nr. 1 BGB eingefordert: Soweit erhebliche Abweichungen zwischen den Normen des dispositiven Rechts und der betreffenden Klausel vorliegen, spricht vieles dafür, die Unwirksamkeitssanktion eingreifen zu lassen. Doch diese – allgemeinen – Fragen, welche mit der Systematik der richterlichen Inhaltskontrolle nach § 307 BGB zusammenhängen, werden hier nicht im Einzelnen erörtert. Vielmehr beschränken sich die nachfolgenden Ausführungen auf die Darstellung der Wirksamkeitsgrenzen von Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln. Andere Fragen werden daher an geeigneter Stelle jeweils gesondert aufgegriffen und dargestellt. Da die Freiheit einseitiger Vertragsgestaltung – auch im Rahmen von Soft- 4 ware-Erstellungsverträgen gilt diese Gesetzmäßigkeit – durch § 307 BGB weitgehend auf Null reduziert ist, ergeben sich zwei Gesichtspunkte: Zum einen wird unter dieser Perspektive die praktische Notwendigkeit evident, individualvertragliche Vereinbarungen gemäß § 305 Abs. 1 Satz 3 BGB zu begründen, um die nicht unerheblichen Risiken eines Software-Erstellungsvertrages zugunsten des Auftragnehmers einzugrenzen. Zum anderen wird in letzter Zeit die rechtspolitische Diskussion von dem Gedanken beherrscht, für den unternehmerischen Bereich die strikten Voraussetzungen für ein Aushandeln i.S.v. § 305 Abs. 1 Satz 3 BGB abzumindern, was hier jedenfalls nicht unerwähnt bleiben darf (Rz. 33). Denn die bisherige Rechtsprechung des BGH ist nicht gerade von solchen Fallkonstellationen geprägt, bei denen beträchtliche Risiken eines großvolumigen Vertrages standardmäßig nach längeren Verhandlungen zu Buche schlagen und in denen dann formularmäßige Klauseln Opfer der richterlichen Inhaltskontrolle nach § 307 BGB werden. Im Vordergrund der Rechtsprechung stehen vielmehr klassische mittelständische Risiken – ein Faktum, das die rechtspolitische Debatte beflügelt.

II. Stellen, Vorformulieren – Vielzahl – AGB-Klausel 1. Vertragsbedingungen, Vorformulieren § 305 Abs. 1 Satz 1 BGB verlangt, dass es sich um Vertragsbedingungen han- 5 deln muss, damit die Qualifikation als AGB-Klausel in Kraft tritt. Davon ist immer dann zu sprechen, wenn es sich um Regelungen handelt, die geeignet sind, den Inhalt des Vertrages zu gestalten1. Notwendigerweise setzt da1 Palandt/Grüneberg, § 305 BGB Rz. 4.

Graf von Westphalen

975

J Rz. 6

Leistungsstörungen

her das Vorliegen einer Vertragsbedingung voraus, dass die entsprechende Klausel auch Bestandteil eines zwischen dem AGB-Verwender einerseits und dem Auftragnehmer/Kunden andererseits zustande gekommenen Vertrages sein soll1. Es ist also im Rahmen der Qualifikation als AGB-Klausel nicht erforderlich, dass diese auch integraler Bestandteil des Software-Erstellungsvertrages geworden ist. Es reicht aus, wenn die betreffende Klausel im Vorstadium eines Vertrages verwendet wird. Deutlich wird dieser Zusammenhang, wenn man bedenkt, dass die Verwendung von unwirksamen AGB-Klauseln zwangsläufig dazu führt, als Verletzung der vorvertraglichen Verhandlungspflichten i.S.v. § 311 Abs. 2 BGB qualifiziert zu werden, so dass Schadensersatzansprüche gegenüber dem AGB-Verwender auch dann geltend gemacht werden können, wenn die betreffende Klausel keineswegs Bestandteil des Vertrages geworden ist2. Folglich ist der Begriff Vertragsbestimmung unabhängig von einem konkreten Vertragsabschluss sehr weit zu fassen. 6

Von einem „Vorformulieren“ i.S.v. § 305 Abs. 1 Satz 1 BGB ist immer dann zu sprechen, wenn die Vertragsbedingungen – regelmäßig: für eine mehrfache Verwendung – schriftlich aufgezeichnet worden sind3. Mit anderen Worten: Es handelt sich insoweit um ein formales Kriterium, welches die Definition von AGB-Klauseln nach § 305 Abs. 1 Satz 1 BGB entscheidend mitbestimmt4. Gleichgültig ist es hierbei, ob die entsprechende – schriftliche – Aufzeichnung im Hinblick auf das erforderliche „Vorformulieren“ in einer Datenbank oder in einem PC gespeichert wird, oder ob dies handschriftlich oder maschinenschriftlich geschieht5. Anerkannt ist auch in der Judikatur, dass es insoweit selbst ausreicht, wenn der AGB-Verwender die betreffenden Klauseln in seinem Gedächtnis für einen bestimmten Vertragsabschluss oder auch nur für eine bestimmte Klauselfassung gespeichert hat6. Das geht sehr weit, ist aber in der Sache zutreffend. Denn in all diesen Fällen wird eine bereit liegende, weil vorformulierte Vertragsbestimmung im Rahmen einer einseitigen Gestaltungsmacht des Verwenders gegenüber einem Dritten eingesetzt.

7

Dieser Ausgangspunkt zur Qualifizierung des Merkmals des „Vorformulierens“ ist deswegen von Wichtigkeit, weil es sich bei den neuralgischen Klauseln eines Software-Erstellungsvertrages – also: insbesondere bei Haftungsbegrenzungs- und Haftungsfreizeichnungsklauseln – in der Regel zum Nachteil des Auftraggebers um in der Substanz gleichlautende, somit regelmäßig auch vorformulierte Klauseln handeln dürfte. Die Gleichförmigkeit – 1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 9. 2 BGH v. 27.5.2009 – VIII ZR 302/07, NJW 2009, 2590; BGH v. 8.10.1987 – VII ZR 358/86, NJW 1988, 197 (198); Fuchs, in: Ulmer/Brandner/Hensen, vor § 307 BGB Rz. 104. 3 Palandt/Grüneberg, § 305 BGB Rz. 8. 4 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 20. 5 Palandt/Grüneberg, § 305 BGB Rz. 8. 6 BGH v. 4.11.1987 – VIII ZR 314/86, NJW 1988, 410.

976

Graf von Westphalen

Rz. 9 J

Individualvereinbarung

und damit der Schluss darauf, dass sie i.S.v. § 305 Abs. 1 Satz 1 BGB tatsächlich auch vorformuliert worden sind – beruht hier schlicht darauf, dass zum einen diese Klauseln klar, durchschaubar und damit auch transparent i.S.v. § 307 Abs. 1 Satz 2 BGB gestaltet sein müssen und dass zum anderen auch die Fantasie der begabtesten Juristen nicht ausreicht, immer wieder neue Formulierungen zu finden, um Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln in abweichender, aber gleichwohl konziser Weise zu textieren. Die darin liegende Uniformität oder doch zumindest die erkennbare Gleichförmigkeit solcher Klauseln ist daher ein gewisses und durchaus auch gewichtiges Indiz dafür, dass es sich – trotz verschiedener Nuancen im Detail – um vorformulierte Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB handeln kann. Entsprechend dem Grad ihrer Abweichung von den Vorgaben des dispositiven Rechts unterliegen sie dann aber auch grundsätzlich den Geboten der richterlichen Inhaltskontrolle nach § 307 BGB. Des Weiteren ist zu bedenken, dass von einem „Vorformulieren“ i.S.v. § 305 8 Abs. 1 Satz 1 BGB dann nicht die Rede sein kann, wenn die betreffende Klausel ausschließlich für den jeweiligen individuellen Vertrag entworfen worden ist1. Dann fehlt es freilich auch an dem Merkmal der Vielzahl, was dann die Argumentation noch verstärkt, dass es sich um eine nur individualvertraglich zu beurteilende Vertragsbestimmung handelt. Ob und inwieweit man diese Schlussfolgerung auch bei einem Software-Erstellungsvertrag als gegeben bezeichnen kann, ist eine Frage, die nur auf Basis der Umstände des Einzelfalls geklärt werden kann. Das hängt wiederum damit zusammen, dass es im Rahmen von § 305 Abs. 1 Satz 3 BGB auf das weitere Merkmal entscheidend ankommt, dass nämlich ein Aushandeln als konstitutives Element eines Individualvertrages immer nur dann angenommen werden kann, als sich das Aushandeln in der Tat auf die betreffende Bestimmung bezogen hat. Dies wird durch die Verwendung des Wortes „soweit“ in dieser Norm signalisiert (Rz. 67 f.). Zu der damit zusammenhängenden Frage der Darlegungs- und Beweislast vgl. Rz. 73 ff. 2. Vielzahl Ein weiteres Qualifikationsmerkmal einer AGB-Klausel i.S.v. § 305 Abs. 1 9 Satz 1 BGB ist, dass sie für eine „Vielzahl“ von Verträgen aufgestellt, mithin: vorformuliert worden ist. Da also, wie bereits zuvor kurz betont, der für einen individuellen Vertrag ausgearbeitete Vertragstext – für sich allein genommen – dieses definitorische Merkmal nicht erfüllt2, kommt es darauf an, wie die Grenze der nach § 305 Abs. 1 Satz 1 BGB erforderlichen „Vielzahl“ konkret zu bestimmen ist. Die Rechtsprechung des BGH, der hier zu folgen ist, vollzieht die Antwort in zwei Richtungen: Objektiv bewertet reicht es aus, dass die betreffende AGB-Klausel – keinesfalls also der gesam-

1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 21. 2 BGH v. 13.9.2001 – VII ZR 487/99, NJW-RR 2002, 13.

Graf von Westphalen

977

J Rz. 10

Leistungsstörungen

te Vertrag – drei Mal tatsächlich verwendet wurde1. Ein solcher Nachweis ist indessen in der Regel nicht einfach zu führen, weil es dem anderen Vertragsteil kaum gelingen könnte, den Nachweis zu erbringen, dass der AGBVerwender seinerseits die betreffende Klausel in drei gleichen Verträgen tatsächlich bereits verwendet hat. Zur Konsequenz hat diese Schwierigkeit, dass die Rechtsprechung des BGH – jedenfalls: die des VII. Senats – dazu übergegangen ist, typisierende Annahmen vorzusehen, bei deren Vorliegen eine AGB-Klausel – vorbehaltlich des Gegenteilsbeweises durch den AGBVerwender – in Betracht kommt (Rz. 22 ff.). 10 Zu beachten ist allerdings zunächst, dass das Merkmal der „Vielzahl“ für die AGB-typische Situation vorgesehen war, das Phänomen von Massenverträgen zu erfassen2. Doch ist gleichzeitig zu betonen, dass die Rechtsprechung in Bezug auf die Annahme einer „Vielzahl“ i.S.v. § 305 Abs. 1 Satz 1 BGB ausgesprochen restriktiv verfährt, was jedoch in der in der Literatur als richtig angesehen wird3. Daher ist im Ergebnis zu unterstreichen, dass auch dann das Merkmal der „Vielzahl“ erfüllt ist, wenn der AGB-Verwender schon bei der erstmaligen Verwendung der betreffenden Klausel die Absicht verfolgt, diese oder eine inhaltsgleiche Klausel auch in künftigen Fällen zu benutzen4. 11 Das ist freilich in der Praxis nur sehr schwer nachzuweisen. Denn die jeweilige Absicht bzw. das entsprechende Motiv des Verwenders sind klassische „innere“ Tatsachen, die des Beweises durch einen Dritten in aller Regel nur sehr schwer zugänglich sind. Daher bleibt es wohl grundsätzlich bei dem Befund: Entweder gelingt dem anderen Vertragsteil der Nachweis einer dreimaligen Verwendung, um auf diese Weise das Merkmal der „Vielzahl“ in § 305 Abs. 1 Satz 1 BGB auszufüllen, oder er ist wegen der Typizität des Vertragsaufbaus und der Typizität der entsprechenden Klausel darauf angewiesen, auf die Beweiserleichterungen zurückzugreifen, welche die Rechtsprechung bereit hält (Rz. 22). 12 Doch bevor auf diese Frage eine Antwort erteilt wird, ist weiterhin zu bedenken, dass es keineswegs erforderlich ist, dass der AGB-Verwender selbst die betreffende Klausel für eine „Vielzahl“ vorformuliert hat. Greift nämlich der AGB-Verwender im Rahmen eines Software-Erstellungsvertrages auf ein bestimmtes (mehr oder weniger gängiges und erprobtes) Vertragsmuster zurück, dann sind damit i.S.v. § 305 Abs. 1 Satz 1 BGB die Würfel

1 BGH v. 27.9.2001 – VII ZR 388/00, NJW 2002, 138; BGH v. 15.4.1998 – VIII ZR 377/96, NJW 1998, 2286. 2 BGH v. 8.11.1974 – V ZR 36/73, NJW 1975, 165 (166). 3 AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 5; Ulmer/ Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 23; Palandt/Grüneberg, § 305 BGB Rz. 9; Erman/Roloff, § 305 BGB Rz. 11. 4 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 24; Palandt/Grüneberg, § 305 BGB Rz. 9; AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 5.

978

Graf von Westphalen

Individualvereinbarung

Rz. 14 J

gefallen. Denn dann ist eindeutig das Merkmal der „Vielzahl“ als erfüllt anzusehen1. Des Weiteren ist es nach der BGH-Judikatur nicht erforderlich, dass die betreffende Klausel in mindestens drei Fällen gegenüber jeweils anderen Vertragspartnern verwendet wird; es reicht vielmehr aus, dass es sich um den gleichen Vertragspartner handelt2. Ein letzter Punkt, der praktisch in Bezug auf das Merkmal der „Vielzahl“ 13 bedeutsam sein kann: Werden nämlich zwischen den gleichen Vertragsparteien im Laufe der Jahre mehrere, in der Sache aber praktisch gleich lautende Software-Erstellungsverträge (ausgenommen Preis und Leistungsinhalt) kontrahiert, dann ist nach der BGH-Judikatur das Risiko erheblich, dass es sich jedenfalls bei den unverändert übernommenen Klauseln um AGB-Klauseln handeln kann, welche der richterlichen Inhaltskontrolle nach § 307 BGB unterworfen werden können. Selbst wenn es sich im ersten Fall um einen klassischen Individualvertrag handelt, kann es durchaus sein, dass als Folge der erneuten, wiederholenden und daher „vielfachen“ Verwendung der betreffenden Vertragsbedingungen daraus eine AGB-Klausel i.S.v. § 305 Abs. 1 Satz 1 BGB entsteht3. Diesem von der Rechtsprechung des BGH entwickelten Ansatz ist jeden- 14 falls im unternehmerischen Bereich nicht zu folgen. Denn wenn im ersten Fall die Voraussetzungen eines Individualvertrages tatsächlich vorliegen, dann ist insoweit ein beiderseitiger, gleichrangiger Akt der autonomen Selbstbestimmung im Rahmen der Vertragsgestaltungsfreiheit anzuerkennen (Rz. 33 ff.). Die erneute, d.h. wiederholende Festlegung der gleichen Vertragsbedingungen ändert daran nichts, weil der in einem solchen Verfahren liegende Rationalisierungseffekt von beiden Parteien gleichförmig als Ausweis der Tatsache anerkannt wird, dass beide Parteien – nach wie vor – auf den Inhalt der Vertragsbedingungen Einfluss genommen haben. Die Klauseln entsprechen dann dem beiderseitigen wohl verstandenen Interesse; sie sind dann in allen Fällen Ausdruck und auch Ausprägung der beiderseitigen – autonom ausgeübten – Vertragsgestaltungsfreiheit. Zwar ist diese Feststellung letztlich von den Umständen des Einzelfalls abhängig. Doch bestehen keine Bedenken, sie als Regelfall anzuerkennen. Denn die wiederholende Ausfertigung der gleichen, zunächst individuell ausgehandelten Vertragsbedingungen führt nicht dazu, dass der eine Teil dann plötzlich seine einseitige Vertragsgestaltungsmacht als AGB-Verwender einsetzt und den anderen Vertragsteil mit den zuvor individuell ausgehandelten Bedingungen konfrontiert4. Er tut dies vielmehr regelmäßig in der festen Überzeugung, dass die einmal individuell ausgehandelten Bedingungen auch weiterhin dem freien, autonomen Willen des anderen Vertragsteils entsprechen. 1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 24. 2 BGH v. 25.11.2003 – VI ZR 8/03, NJW 2004, 1454; Erman/Roloff, § 305 BGB Rz. 11. 3 BGH v. 15.12.1976 – IV ZR 197/75, NJW 1977, 624. 4 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 (1133).

Graf von Westphalen

979

J Rz. 15

Leistungsstörungen

3. Stellen 15 Aus der grundliegenden Entscheidung des BGH vom 17.2.20101 folgt, dass das wesentliche, charakteristische Merkmal einer AGB-Klausel – bezogen auf das Merkmal des „Stellens“ nach § 305 Abs. 1 Satz 1 BGB – darin zu sehen ist, dass AGB-Klauseln definitionsgemäß auf der einseitigen Gestaltungsmacht des Verwenders beruhen und insoweit als „gestellt“ anzusehen sind2. Mit anderen Worten: Der Verwender übernimmt es, den Kunden mit einer von ihm vorgeschlagenen Regelung zu „konfrontieren“, auf deren „Ausgestaltung“ er dann als unmittelbare Folge „gewöhnlich keinen Einfluss nehmen kann“3. Anders ausgedrückt ist das Merkmal des „Stellens“ rein formal dahin zu verstehen, dass damit die Rolle des AGB-Verwenders umschrieben wird, weil und soweit er die Einbeziehung der betreffenden AGB-Klauseln in den konkreten Vertrag auf diesem Wege veranlasst hat4. Nicht erforderlich ist es insoweit, dass der AGB-Verwender eine wirtschaftliche oder auch intellektuelle Überlegenheit über den anderen Vertragsteil aufweist, so dass insoweit ein „Ungleichgewicht zwischen den Vertragsbeteiligten“ besteht5. Denn es geht im Rahmen von § 305 Abs. 1 Satz 1 BGB ausschließlich darum, die in dem Merkmal des „Stellens“ zum Ausdruck gelangende „einseitige Gestaltungsmacht“ des AGB-Verwenders zu bezeichnen6. Dieses – formale – Merkmal des § 305 Abs. 1 Satz 1 BGB wird dadurch ergänzt, dass – gegenläufig formuliert – der Kunde im Hinblick auf die ihm unterbreiteten Vertragsbedingungen so gestellt ist, dass er „auf ihre Ausgestaltung gewöhnlich keinen Einfluss nehmen kann“7. Mit der Bejahung oder Verneinung wirtschaftlicher oder auch intellektueller Überlegenheit des Verwenders über seinen Vertragspartner hat die Norm des § 305 Abs. 1 Satz 1 BGB also nichts zu tun. 16 Dass die BGH-Entscheidung vom 17.2.20108 nicht zum unternehmerischen Verkehr ergangen ist, sondern einen Sonderfall betraf, der den Kauf eines Gebrauchtwagens im c2c-Verkehr zum Gegenstand hatte, ist im Rahmen dieser Analyse irrelevant. Denn die Interpretation des Merkmals des „Stellens“ in § 305 Abs. 1 Satz 1 BGB ist unabhängig davon, ob der AGB-Verwender Unternehmer oder Verbraucher ist. Aus diesem Grund wird auch die vorerwähnte BGH-Entscheidung in allen maßgeblichen – neuen – Kommen1 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 = ZIP 2010, 628 mit Anm. Kaufhold; hierzu auch Graf von Westphalen, ZIP 2010, 1110 ff. 2 Hierzu auch Kaufhold, ZIP 2010, 631 (632 f.). 3 So BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 = ZIP 2010, 628, 630; vgl. auch insoweit BT-Drucks. 7/3919, S. 15. 4 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 27; Erman/Roloff, § 305 BGB Rz. 12; Palandt/Grüneberg, § 305 BGB Rz. 10. 5 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 = ZIP 2010, 628 (629). 6 Graf von Westphalen ZIP 2010, 1110 (1111); Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 27. 7 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 = ZIP 2010, 628 (630). 8 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 = ZIP 2010, 628.

980

Graf von Westphalen

Individualvereinbarung

Rz. 17 J

tierungen in der Weise verstanden, dass damit eine umfassende, grundlegende Aussage getroffen worden ist, wie denn das Merkmal des „Stellens“ in § 305 Abs. 1 Satz 1 BGB zu verstehen ist1. So gesehen ist es aber auch gleichgültig, von welcher Seite der betreffende AGB-Text entworfen worden ist, weil das Merkmal des „Stellens“ eben lediglich die Partei bezeichnet, auf deren Veranlassung die betreffenden Klauseln in den Vertrag einbezogen werden – mit der Konsequenz, dass sie ihr dann auch als Verwendung von AGB-Klauseln zugerechnet werden2. Daraus sind verschiedene weitere Konstellationen abzuleiten. 4. Auftraggeber als AGB-Verwender Werden vorformulierte AGB-Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB bei ei- 17 nem Software-Erstellungsvertrag vom Auftraggeber vorformuliert, dann ist seine Interessenlage regelmäßig dadurch charakterisiert: Er verhält sich genauso wie jedes andere Unternehmen, welches in der Funktion eines Einkäufers tätig wird: Es besteht für ihn keinerlei Anlass, über Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln oder auch sonstige Risikobegrenzungen nachzudenken, weil ihn die gesetzliche Risikoverteilung hinreichend schützt. Sie ist durchaus käuferfreundlich, und zwar unabhängig davon, ob ein Software-Erstellungsvertrag im dogmatischen Ergebnis als Kauf- oder als Werkvertrag eingeordnet werden muss. Dass Software-Erstellungsverträge gleichwohl – auch in diesen Fällen – der richterlichen Inhaltskontrolle im Rahmen von § 307 Abs. 2 Nr. 1 BGB unterworfen sind, kann nicht in Zweifel gezogen werden3. Auch wenn es nur wenige Entscheidungen gibt, wie denn die richterliche Inhaltskontrolle nach § 307 Abs. 2 Nr. 1 BGB gegenüber Einkaufs-AGB im Detail aussieht4, so ist doch in der Sache entscheidend: Die gesetzlichen Haftungsrisiken des Auftragnehmers dürfen nicht zu seinem Nachteil – entgegen den Gerechtigkeitsforderungen des dispositiven Rechts – ausgedehnt und damit zum Vorteil des Auftraggebers gestaltet werden. In Betracht kommen insoweit in erster Linie Klauseln, welche Haftungssanktionen ohne Rücksicht auf ein Verschulden i.S.v. § 280 Abs. 1 Satz 2 BGB einfordern oder die gesetzlichen Verjährungsfristen der §§ 438, 634a BGB extensiv zum Nachteil des Auftragnehmers verändern. Zu denken ist aber auch daran, dass einfache Beschaffenheitsvereinbarungen nach den §§ 434, 633 BGB in den Rang einer Garantie gehoben werden5. Doch werden die hieraus sich ergebenden Einzelheiten an anderer Stelle dargestellt (K Rz. 1 ff.). 1 Palandt/Grüneberg, § 305 BGB Rz. 10; Erman/Roloff, § 305 BGB Rz. 12; zweifelnd Schauer, AnwBl. 2012, 690 (695). 2 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 27. 3 BGH v. 5.10.2005 – VIII ZR 16/05, NJW 2006, 47. 4 Im Einzelnen AGB-Klauselwerke/Graf von Westphalen, Einkaufsbedingungen, Rz. 1 ff. 5 BGH v. 5.10.2005 – VIII ZR 16/05, NJW 2006, 47; kritisch Palger/Schröder, AnwBl. 2012, 683 (688).

Graf von Westphalen

981

J Rz. 18

Leistungsstörungen

5. Auftragnehmer als AGB-Verwender 18 Unter dieser Perspektive hat der Auftragnehmer gerade im Blick auf das von ihm regelmäßig als untragbar angesehene gesetzliche Haftungsrisiko ein vitales Interesse daran, möglichst umfassende und weit reichende Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln ins Spiel zu bringen. Denn nur so können die oft als extrem zu bezeichnenden Risiken von Software-Erstellungsverträgen hinreichend sicher eingeschränkt werden. Nur so kann der Auftragnehmer mit einiger Verlässlichkeit das ihn treffende Schadensersatzrisiko im Fall einer Pflichtverletzung hinreichend sicher beherrschen. Allerdings ergeben sich hierbei zwei Rechtsfragen: a) Umgedrehte Rolle: der Auftragnehmer als Verwender 19 Soweit nämlich der Auftraggeber in seinen Bestellbedingungen – sozusagen im „vorauseilenden Gehorsam“ – formularmäßig Haftungsfreizeichnungsoder Haftungsbegrenzungsklauseln zugunsten seines Vertragspartners, des Auftragnehmers, einbaut, weil diese – etwa im Hinblick auf den Ausschluss von entgangenem Gewinn, mittelbaren Schäden oder Folgeschäden – angeblich „branchenüblich“ sind und ohnehin nur in dieser oder ähnlicher Weise vom Auftragnehmer akzeptiert werden, stellt sich die heikle Frage, wer denn unter diesen Voraussetzungen als AGB-Verwender anzusehen ist. Die Rechtsprechung des BGH ist in diesem Punkt eindeutig und ziemlich rigide: Es ist dann nämlich nicht der Auftraggeber, der die Rolle des AGB-Verwenders i.S.v. § 305 Abs. 1 Satz 1 BGB übernimmt und eine entsprechende Klausel „stellt“, sondern die Rolle dreht sich um: Es ist dann der Auftragnehmer als AGB-Verwender anzusehen1. Die nicht ganz leicht nachzuvollziehende Argumentation ist folgende: Der Auftraggeber geht in diesen Fällen davon aus, dass ein Vertrag nur zu bestimmten Bedingungen zustande kommt, weil – das gilt vor allem für Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln – der Auftragnehmer sonst es ablehnen würde, einen Vertrag überhaupt abzuschließen. Trifft dies in tatsächlicher Hinsicht zu, dann handelt der Auftraggeber nicht aus eigenem Interesse, sondern er nimmt praktisch für den Auftragnehmer die Rolle des Verwenders in die Hand, weil er seine Interessen schützen will und insoweit einseitige Gestaltungsmacht ausübt. 20 Ist dies der Fall, dann ist plötzlich der Auftragnehmer Verwender der betreffenden, in seinem Interesse gestalteten AGB. Zur Konsequenz hat dies dann, dass er selbst darauf achten muss, ob die zu seinen Gunsten vorformulierten Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln in der Tat den Anforderungen der richterlichen Inhaltskontrolle gemäß § 307 Abs. 2 Nr. 1 BGB ausreichen (Kap. K Rz. 1 ff.). Trifft dies nicht zu – und dies dürfte wohl die Regel sein –, dann ist der Auftragnehmer – im eigenen Interesse – verpflichtet, für eine Abänderung dieser Klauseln Sorge zu tragen, 1 Grundlegend BGH v. 4.3.1997 – X ZR 141/95, NJW 1997, 2043 (2044).

982

Graf von Westphalen

Individualvereinbarung

Rz. 21 J

um auf diese Weise zu gewährleisten, dass die Voraussetzungen des Aushandelns i.S.v. § 305 Abs. 1 Satz 3 BGB tatsächlich erfüllt werden. Geschieht dies nicht, verbleibt es vielmehr bei den vorformulierten, aber unwirksamen Klauseln, dann ist der Auftraggeber berechtigt, ihre Unwirksamkeit nach § 307 BGB geltend zu machen. Zu seinen Gunsten tritt dann die allgemeine Sanktion des § 306 Abs. 2 BGB ein, so dass dann die gesetzlichen Normen uneingeschränkt gelten. Dieses Resultat erscheint auf den ersten Blick ein wenig weltfremd und keineswegs sachgerecht. Doch es entspricht der Judikatur und ist daher für die Praxis bis auf weiteres hinzunehmen. b) Stellungnahme Indessen sind Bedenken und Zweifel anzumelden. Gerade wenn in einem 21 Software-Erstellungsvertrag – entsprechend der üblichen Vertragspraxis – Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln verwendet werden, etwa der Ausschluss des Anspruchs auf entgangenen Gewinn, mittelbarer Schäden oder Folgeschäden, dann sprechen die besseren Argumente für einen von der BGH-Judikatur abweichenden Ansatz. Da nämlich der Auftraggeber diese Klauseln als Teil der von ihm gestellten Vertragsbedingungen verwendet, ist er auch insoweit – rein formal betrachtet – als AGBVerwender i.S.v. § 305 Abs. 1 Satz 1 BGB zu qualifizieren. Dass er dabei Rücksicht auf die Usancen der Branche genommen hat und praktisch im „vorauseilenden Gehorsam“ Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln vorsieht, ändert an diesem Befund nichts. Diese Schlussfolgerung führt aber dann zwangsläufig dazu, dass der AGB-Verwender nicht befugt ist, sich auf die Unwirksamkeit dieser Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel i.S.v. § 307 Abs. 2 Nr. 1 BGB mit Erfolg zu berufen. Vielmehr gilt dann der allgemeine Grundsatz1, der auch von der Judikatur bestätigt wird2: Die Normen des AGB-Rechts i.S.d. §§ 307 ff. BGB schützen ausschließlich die Partei, welche mit den AGB-Klauseln „konfrontiert“ worden ist3, versagen aber dem AGB-Verwender die Befugnis, sich seinerseits auf die angebliche Unwirksamkeit der von ihm gestellten Vertragsbedingungen zu berufen4. Wenn denn die betreffende Klausel nicht auf ausdrückliche Veranlassung des Auftragnehmers in den Vertrag aufgenommen worden ist5, dann besteht auch kein Grund, ihn als Verwender anzusehen. Daher hat der Auftragnehmer auch keinen Anlass, eine ihm günstige Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel zur Disposition zu stellen, um i.S.v. § 305 Abs. 1 Satz 3 BGB dann im Rahmen eines Aus-

1 Fuchs, in: Ulmer/Brandner/Hensen, vor § 307 BGB Rz. 53; Erman/Roloff, vor § 307 BGB Rz. 15; Palandt/Grüneberg, § 307 BGB Rz. 7. 2 BGH v. 2.4.1998 – IX ZR 79/97, NJW 1998, 2280 (2281). 3 So BGH v. 17.2.2010 – VIII ZR 67/09, ZIP 2010, 628 (630). 4 BGH v. 2.4.1998 – IX ZR 79/97, NJW 1998, 2280 (2281); Erman/Roloff, vor § 307 BGB Rz. 15; Fuchs, in: Ulmer/Brandner/Hensen, vor § 307 BGB Rz. 53. 5 Vgl. BGH v. 2.4.1998 – IX ZR 79/97, NJW 1998, 2280 (2281).

Graf von Westphalen

983

J Rz. 22

Leistungsstörungen

handelns einen Individualvertrag zu erreichen (Rz. 33 ff.). Vielmehr kann er die für ihn günstigen Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln als wirksame Vereinbarung hinnehmen. 6. Typizität: Anschein einer AGB-Klausel a) Grundsätzliche Aussage 22 Die Rechtsprechung trägt inzwischen den dogmatischen Ansatz, dass es sich auch dann um AGB-Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB handelt, wenn der betreffende Vertrag so „typisch“ aufgebaut ist und daher auch typische Klauseln enthält, wie etwa bei einem Bauvertrag1 oder einem Bauträgervertrag2 AGB-Klauseln vorliegen. Die Typizität der Vertragsgestaltung trägt also den widerlegbaren Schluss, dass es sich bei diesem Vertragswerk auch bei der ersten Verwendung gegenüber dem betreffenden Vertragspartner um AGB-Klauseln handelt3. Auch die Literatur teilt diesen Ansatz4. Im Ergebnis bedeutet dies, dass der Nachweis der Vielzahl in § 305 Abs. 1 Satz 1 BGB als Wesensmerkmal einer AGB-Qualifikation erheblich zugunsten des Vertragspartners erleichtert wird. Denn der Nachweis der jeweiligen Typizität der betreffenden Klausel bringt ihn in die Vorhand, weil es dann Sache des Verwenders ist, entweder nachzuweisen, dass die jeweilige AGBKlausel nur für den Einzelfall geschaffen worden ist oder dass es sich um eine ausgehandelte Individualabrede nach § 305 Abs. 1 Satz 3 BGB handelt (Rz. 33 ff.). b) Stellungnahme 23 Auch Software-Erstellungsverträge sind durch eine – technisch und praktisch vorgegebene – Typizität charakterisiert. Es besteht keine Veranlassung, die kurz dargestellten Grundaussagen der Judikatur auf die Fälle von Bauverträgen zu begrenzen. Denn die Typizität der Verwendung von AGB ist allgemeiner Natur. Abgesehen davon sind Software-Erstellungsverträge jedenfalls dann einem Bauvertrag typologisch direkt vergleichbar, wenn man diesen Typus dem Bereich des Werkvertragsrechts zuordnet. Aber auch dann, wenn man zu einer kaufvertraglichen Qualifikation über § 651 BGB neigt, liegen die werkvertraglichen Elemente eines Software-Erstellungsvertrages in hinreichender Dichte vor, so dass man die Ergebnisse der Judikatur als anwendbar bezeichnen muss5. Es besteht also auch bei Software-Erstellungsverträgen die Vermutung, dass es sich bei dem jeweiligen Vertrags1 BGH v. 14.5.1992 – VII ZR 204/90, BGHZ 118, 229. 2 BGH v. 27.11.2003 – VII ZR 53/03, WM 2004, 290. 3 Hierzu auch BGH v. 23.6.2005 – VII ZR 277/04, ZIP 2005, 1604 – „ständige Rechtsprechung“; Fischer, FS für Kreft, 2004, S. 33, 49 ff. 4 AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 6; Fischer, FS für Kreft, 2004, S. 33, 49 ff.; Palandt/Grüneberg, § 305 BGB Rz. 23. 5 BGH v. 23.6.2005 – VII ZR 277/04, ZIP 2005, 1604.

984

Graf von Westphalen

Individualvereinbarung

Rz. 25 J

werk um AGB-Klauseln handelt. Dabei macht es keinen Unterschied, ob diese aus Datenbanken stammen1 oder von einem Rechtsanwalt für den AGB-Verwender – außerhalb des Einzelfalls – entworfen sind. Teilt man diesen Ansatzpunkt, dann dürfte es Sache des AGB-Verwenders – 24 hier: des Auftraggebers – sein, die gegen ihn streitende Vermutung, dass es sich um AGB-Klauseln nach § 305 Abs. 1 Satz 1 BGB handelt, zu widerlegen. Praktisch kann dies lediglich in der Weise geschehen, dass der AGBVerwender dann den Nachweis führt, die betreffende Klausel ausschließlich für den Einzelfall entworfen zu haben. Das wird jedenfalls dann keinen Erfolg haben, wenn es sich in der Tat um eine als typisch anzusehende Vertragsbestimmung handelt. Doch reicht es für den vom Auftraggeber zu führenden Gegenteilsbeweis aus, wenn er den Nachweis erbringt, dass die betreffende Klausel lediglich Gegenstand einer Ausschreibung war, weil dann nach der BGH-Judikatur das Merkmal der „Vielzahl“ i.S.v. § 305 Abs. 1 Satz 1 BGB fehlt2. Dass er aber auch berechtigt ist, den Nachweis einer ausgehandelten Individualabrede nach § 305 Abs. 1 Satz 3 BGB zu führen, liegt auf der Hand, begegnet aber in der Sache den allgemeinen Schwierigkeiten, weil die Hürden für den Nachweis einer solchen Abrede sehr hoch sind (Rz. 33 ff.). Gelingt indessen dem Auftraggeber nicht, die wegen der Typizität der betreffenden Klausel eingreifende Vermutung, es handle sich um eine AGB-Klausel, zu widerlegen, dann ist er beweisfällig geblieben. 7. Beiderseitiges Einbeziehungsverlangen Es mag auch – sicherlich sehr selten – bei Software-Erstellungsverträgen 25 vorkommen, dass sich beide Parteien auf ein bestimmtes Muster für ihren Vertrag einigen3. Geschieht dies, dann sind die Normen der §§ 305 ff. BGB nicht anwendbar4. Denn unter dieser Voraussetzung – und dieser Ansatz ist entscheidend – nimmt keine der beiden Vertragsparteien einseitig für sich die rechtsgeschäftliche Gestaltungsmacht in Anspruch und konfrontiert die andere Seite mit den betreffenden Vertragsbedingungen, indem sie ihr gleichzeitig die Möglichkeit praktisch abschneidet, auf deren Gestaltung tatsächlich Einfluss zu nehmen. Daraus folgt aber, dass nur unter diesen – engen – Voraussetzungen keinem der beiden Vertragsparteien die Rolle des AGB-Verwenders zuzuweisen ist – mit der Konsequenz, dass dann auch nicht die andere Partei in den Genuss des Schutzes der §§ 307 ff. BGB gelangt. Doch wird man in diesen Fällen immer verlangen müssen, dass beide Parteien die Einbeziehung des betreffenden Vertragsmusters in ihren rechts1 BGH v. 7.6.2005 – VI ZR 192/04, NJW 2005, 2543 (2544). 2 BGH v. 15.10.1996 – VI ZR 327/95, NJW 1997, 135; Palandt/Grüneberg, § 305 BGB Rz. 9. 3 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 29; Erman/Roloff, § 305 BGB Rz. 12. 4 BGH v. 17.2.2010 – VIII ZR 67/09, ZIP 2010, 628.

Graf von Westphalen

985

J Rz. 26

Leistungsstörungen

geschäftlichen, privatautonomen Gestaltungswillen aufgenommen haben1. Es müssen also immer belastbare Elemente einer Individualabrede i.S.v. § 305 Abs. 1 Satz 3 BGB vorliegen, um den Tatbestand anzunehmen, dass beide Parteien sich auf ein bestimmtes Vertragsmuster geeinigt haben. Nur dann scheiden die Grundsätze der §§ 305 ff. BGB aus.

III. Einbeziehung der AGB-Klauseln 1. Grundsatz 26 Bei Software-Erstellungsverträgen bereitet es in der Regel praktisch keine Schwierigkeiten, die Einbeziehung der AGB – sei es der AGB des Auftraggebers oder der des Auftragnehmers – sicherzustellen. Denn es handelt sich hierbei in der Regel um schriftlich abgeschlossene Verträge, in denen dann – ergänzend – auf die Geltung der AGB verwiesen wird. Berücksichtigt man, dass diese Verträge ohnehin nur im unternehmerischen Verkehr abgeschlossen werden, dann sind unter dieser Voraussetzung keine Bedenken angezeigt: Die Einbeziehungsvoraussetzungen gemäß §§ 145 ff. BGB sind dann erfüllt. Dazu ist es auch nicht erforderlich, dass die betreffenden AGB in dem Vertrag mit abgedruckt oder beigefügt werden, weil im unternehmerischen Verkehr es ausreicht, wenn auf die einzubeziehenden AGB verweisen wird2. Dies sieht auch die Rechtsprechung so3. Verweist also der Verwender auf die Geltung seiner AGB, dann ist es Sache des anderen Vertragsteils, sich nach ihrem Inhalt zu erkundigen4. Dieser ist dann aber auch verpflichtet, diesem Begehren zu entsprechen und die betreffenden AGB dem anderen Teil zur Kenntnis zu bringen5. Geschieht dies nicht, sprechen berechtigte Argumente dafür, dass dann der Grundsatz des § 242 BGB eingreift und der Verwender nicht berechtigt ist, sich auf die rechtsgeschäftliche Geltung der AGB mit Erfolg zu berufen6. 2. Kaufmännisches Bestätigungsschreiben 27 Liegen die Voraussetzungen eines kaufmännischen Bestätigungsschreibens tatsächlich vor und nimmt der AGB-Verwender im Rahmen eines solchen Schreibens auf seine AGB Bezug, dann liegt darin eine wirksame Einbeziehung7. Es entspricht einer vielfach geübten kaufmännischen Praxis, gewohnheitsrechtlich (vgl. § 346 HGB) auf das Instrument des kaufmän1 Palandt/Grüneberg, § 305 BGB Rz. 13. 2 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 170; Palandt/ Grüneberg, § 305 BGB Rz. 54. 3 BGH v. 16.3.1982 – VI ZR 275/80, NJW 1982, 1749 (1750). 4 Palandt/Grüneberg, § 305 BGB Rz. 54; Erman/Roloff, § 305 BGB Rz. 47. 5 Vgl. auch MünchKomm/Basedow, § 305 BGB Rz. 91; Palandt/Grüneberg, § 305 BGB Rz. 54. 6 Palandt/Grüneberg, § 305 BGB Rz. 54. 7 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 177 ff.

986

Graf von Westphalen

Individualvereinbarung

Rz. 29 J

nischen Bestätigungsschreibens zurückzugreifen, weil seine wesentliche Funktion darin besteht, einen mündlich geschlossenen Vertrag gegenüber dem anderen Vertragsteil – zum Zweck der Beweissicherung – schriftlich zu bestätigen. Wirksamkeitsvoraussetzung ist hierbei, dass die Parteien einen schriftlichen Vertragsabschluss vereinbart haben1. Ferner muss sich das Bestätigungsschreiben auf die zuvor getroffene mündliche, fernmündliche oder telegrafisch getroffene Vereinbarung beziehen, so dass der Empfänger die Einzelheiten der vorangegangenen Vertragsverhandlungen nachvollziehen kann2. Regelmäßig ist dann die so vereinbarte und im kaufmännischen Bestätigungsschreiben enthaltene Schriftform nicht als vertragskonstitutiv, sondern als deklaratorisch gewollt3. Soweit dann ein solches Bestätigungsschreiben Abweichungen von dem mündlich Vereinbarten – insbesondere wegen der einbezogenen AGB-Klauseln – enthält, ist der Empfänger verpflichtet, unverzüglich (zwei bis drei Tage) zu widersprechen4. Erfüllt er diese Obliegenheit nicht, so gilt sein Schweigen als Zustimmung5. Dies gilt freilich dann nicht, wenn der Bestätigende das mündlich Vereinbarte bewusst falsch bestätigt hat, weil er dann schlechterdings mit einer Zustimmung nicht rechnen konnte und auch nicht rechnen durfte6. Auch wenn in diesem Bestätigungsschreiben die AGB des Verwenders erst- 28 mals in Bezug genommen werden, ist grundsätzlich davon auszugehen, dass sie wirksam Vertragsbestandteil geworden sind, sofern der Empfänger nicht unverzüglich widersprochen hat. Doch kann es hier sehr auf die Einzelheiten ankommen, weil das mündlich Vereinbarte Vorrang i.S.v. § 305b BGB genießt. Grundsätzlich ist allerdings davon auszugehen, dass die AGB-Klauseln den mündlich vereinbarten Vertragsinhalt lediglich ergänzen, so dass der Empfänger – auch im Fall seines ausbleibenden Widerspruchs – hierdurch nicht unangemessen belastet wird. Hinzu tritt auch die Erwägung, dass die richterliche Inhaltskontrolle gemäß § 307 BGB in jedem Fall vorbehalten bleibt. 3. Kollision von Vertragsbedingungen Auch wenn es im Rahmen eines Software-Erstellungsvertrages sehr selten 29 ist, dass beide Parteien AGB-Klauseln verwenden, so sei doch auf Folgendes hingewiesen: Nach der Rechtsprechung des BGH7 setzt sich der Auftraggeber mit seinen Vertragsbedingungen (Einkaufs-AGB) jedenfalls dann gegenüber entgegenstehenden Verkaufs-AGB des Auftragnehmers durch, soweit der Auftraggeber in seinen AGB eine Ausschließlichkeits- und Abwehrklau1 2 3 4 5 6 7

BGH v. 18.3.1964 – VIII ZR 281/62, NJW 1964, 1270. BGH v. 20.3.1974 – VIII ZR 234/72, NJW 1974, 992. Palandt/Ellenberger, § 147 BGB Rz. 11; Erman/Armbrüster, § 147 BGB Rz. 8 ff. Erman/Armbrüster, § 147 BGB Rz. 11. BGH v. 10.1.2007 – VIII ZR 380/04, NJW 2007, 987 (988). BGH v. 3.7.1967 – VIII ZR82/65, WM 1967, 958 (960). BGH v. 24.10.2000 – X ZR 42/99, NJW-RR 2001, 484.

Graf von Westphalen

987

J Rz. 30

Leistungsstörungen

sel enthält. Nach Auffassung des BGH kann in diesen Fällen der Auftragnehmer nicht berechtigterweise erwarten, dass er sich mit seinen gegenläufigen Verkaufs-AGB durchsetzt. 30 Ob dieser Rechtsprechung zu folgen ist, bleibt zweifelhaft1. Zutreffend erscheint es im Fall der Kollision von AGB-Klauseln bei Vertragsabschluss auf das Kongruenz-Prinzip des § 154 Abs. 1 BGB zurückzugreifen: Soweit die Parteien aufgrund der individuellen Erklärungen den Vertragsabschluss tatsächlich gewollt haben, wird dieser nicht durch den Dissens in den AGB gehindert, und zwar unabhängig davon, welche Partei Ausschließlichkeitsoder Abwehrklauseln vorhält. Entscheidend ist allein, dass der entsprechende Einbeziehungswille des Verwenders vorlag2. Dies entspricht auch dem Trend in der instanzgerichtlichen Judikatur3 und wird auch von der Literatur so gesehen4. a) Nachteile für den Auftraggeber 31 Folgt man dieser Auffassung, dann ergeben sich im Zweifel folgende Fragestellungen: Sofern der Auftraggeber in seinen AGB (Einkaufs-AGB) keinerlei Regelungen im Hinblick auf Haftungsfreizeichnungs- oder Haftungsbegrenzungen enthält, während der Auftragnehmer auf diese Klausel gesteigerten Wert legt, wird man gleichwohl zu dem Ergebnis gelangen müssen, dass nach § 154 Abs. 1 BGB Dissens besteht. Denn der Auftraggeber hat in seinen AGB die gesetzliche Risikoverteilung zum Gegenstand seines Vertragsangebots gemacht, während die Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln gegenläufig, d.h. in Abweichung vom dispositiven Recht formuliert sind5. Sofern allerdings auf den Software-Erstellungsvertrag Kaufrecht gemäß § 651 BGB zur Anwendung berufen ist, führt diese Konstellation regelmäßig auch dann zur Anwendung von § 377 HGB, wenn der Auftragnehmer in seinen Verkaufs-AGB keine entsprechende vertragliche Regelung vorsieht, während der Auftraggeber die strikte Obliegenheit zur Wareneingangskontrolle nach § 377 HGB in seinen AGB abmildert. Denn auch hier liegt nach § 154 Abs. 1 BGB ein hinreichender Dissens vor. Gleiches dürfte aber auch dann gelten, wenn der Auftraggeber in seinen AGB eine umfassende Abnahmeprozedur vorsieht, während die AGB des 1 Vgl. auch Palandt/Grüneberg, § 305 BGB Rz. 54; AGB-Klauselwerke/Graf von Westphalen, Vertragsabschlussklauseln Rz. 39 ff. 2 Im Einzelnen AGB-Klauselwerke/Graf von Westphalen, Vertragsabschlussklauseln, Rz. 39 ff. 3 OLG Dresden v. 13.2.1998 – 8 U 2863/97, NJW-RR 1999, 846 (847); OLG Düsseldorf v. 24.4.1996 – 11 U 54/95, NJW-RR 1997, 946; OLG Hamm v. 11.7.1983 – 2 U 86/83, BB 1983, 1814; OLG Stuttgart v. 16.10.1980 – U 130/80, ZIP 1981, 176. 4 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 188 ff.; Palandt/ Grüneberg, § 305 BGB Rz. 54; Erman/Roloff, § 305 BGB Rz. 54 f.; MünchKomm/ Basedow, § 305 BGB Rz. 100; im Einzelnen auch Graf von Westphalen, FS für Horn, 2006, S. 159, 160 f. 5 AGB-Klauselwerke/Graf von Westphalen, Vertragsabschlussklauseln, Rz. 47 f.

988

Graf von Westphalen

Individualvereinbarung

Rz. 33 J

Auftragnehmers hierzu schweigen. Denn die Anwendung von § 651 BGB bedingt gerade nicht die Anwendbarkeit von § 640 BGB – mit der Konsequenz, dass auch insoweit die Voraussetzungen eines Dissenses i.S.v. § 154 Abs. 1 BGB gegeben sind. b) Nachteile für den Auftragnehmer Es liegt auf der Hand, dass im Fall der Kollision von Vertragsbedingungen 32 etwa vorhandene Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln als nicht wirksam vereinbart anzusehen sind. Der Dissens nach § 154 Abs. 1 BGB wirkt sich hier voll aus; es gelten dann die gesetzlichen Haftungsregeln1. Dies gilt im Zweifel unabhängig davon, welcher Tatbestand einer Pflichtverletzung vorliegt, weil der Dissens gegenüber den AGB des Auftraggebers regelmäßig als umfassend zu verstehen ist. Soweit der Auftragnehmer einen einfachen Eigentumsvorbehalt nach § 449 BGB vereinbart, ist davon auszugehen, dass sich dieser im Zweifel durchsetzt, wenn und soweit die AGB des Auftragnehmers einer Person zugehen, welche zur Abänderung eines Vertrages befugt ist2. Soweit allerdings ein verlängerter oder auch erweiterter Eigentumsvorbehalt in den AGB des Auftragnehmers enthalten sein sollte, führt die Kollision mit entgegenstehenden AGB des Auftraggebers dazu, dass dann keine wirksame Vereinbarung vorliegt3. Darin liegt allerdings bei Software-Erstellungsverträgen nur selten ein wirklich praktisch bedeutsames Problem, weil die Absicherung etwaiger Risiken kaum durch Vorbehaltsvereinbarungen vorgenommen wird. Wie bei allen Großverträgen stehen Bürgschaften und auch Bankgarantien im Vordergrund des Sicherungsinteresses.

IV. Individualvereinbarung – Aushandeln – § 305 Abs. 1 Satz 3 BGB 1. Regelsatz der BGH-Judikatur Liegen die Voraussetzungen einer AGB-Klausel nach § 305 Abs. 1 Satz 1 33 BGB vor, dann ist der AGB-Verwender nach ständiger Rechtsprechung des BGH verpflichtet, den „gesetzesfremden Kerngehalt“ der betreffenden Klausel gegenüber seinem Vertragspartner ernsthaft zur Disposition zu stellen4. Mehr noch: Er muss dem anderen Vertragsteil die „reale Möglichkeit“ einräumen, eine Abänderung der vorformulierten Klausel – entsprechend sei-

1 2 3 4

Im Einzelnen auch Graf von Westphalen, FS für Trinkner, 1996, S. 441 ff. BGH v. 16.3.1982 – VI ZR 275/80 NJW 1982, 1749, 1750. BGH v. 20.3.1985 – VIII ZR 342/83, NJW 1985, 1838, 1840. BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110, 1111.

Graf von Westphalen

989

J Rz. 34

Leistungsstörungen

nem jeweiligen eigenen Interesse – durchzusetzen1. Daraus hat der BGH einen Regelsatz entwickelt2: Danach ist nur eine aufgrund der Einflussnahme des Kunden tatsächlich abgeänderte Vertragsbestimmung keine AGB, sondern eine ausgehandelte Individualvereinbarung3. Hintergrund für diesen Regelsatz ist die bereits apostrophierte Erkenntnis, dass nämlich der AGBVerwender einseitig für sich die Vertragsgestaltungsfreiheit in Anspruch nimmt, sofern er AGB-Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB verwendet. Reduziert er also auf diese Weise – nämlich: durch das einseitige „Stellen“ von Vertragsbedingungen4 – die dem anderen Vertragsteil zustehende Vertragsgestaltungsfreiheit auf eine reine Vertragsabschlussfreiheit, dann verbleibt es stets bei der Qualifizierung der Vertragsbestimmung als AGB-Klausel. Denn nur die materielle Änderung eines vorformulierten Vertragstextes ist Ausweis der tatsächlichen – privatautonom verstandenen – Einflussnahme des anderen Vertragspartners5. 34 Daher steht auch die Rechtsprechung auf dem Standpunkt, dass der in § 305 Abs. 1 Satz 3 BGB verwendete Begriff des „Aushandelns“ nicht gleichbedeutend ist mit dem des Verhandelns, so dass ein Durchsprechen, Erörtern oder sogar auch ein Vorlesen des Vertragstextes nicht ausreicht6. Vielmehr kommt es – und so ist der Begriff des „Aushandelns“ auch zu verstehen – darauf an, dass eine gleichberechtigte Vertragsgestaltungsfreiheit im Hinblick auf die betreffende Klausel tatsächlich eingreift7. Anders gewendet: Der AGB-Verwender muss seinem Vertragspartner die „reale Möglichkeit“8 von sich aus einräumen, damit dieser in der Lage ist, eigene Textvorschläge zur Neugestaltung der Vertragsbedingungen in die Verhandlung einzuführen9. Mit anderen Worten: Der Vertragspartner muss also die „effektive Möglichkeit“ erhalten, die „inhaltliche Ausgestaltung der Vertragsbedingungen zu beeinflussen“10. 35 Liegen diese Voraussetzungen vor, besteht kein Zweifel, dass dann eine entsprechende individualvertragliche Regelung i.S.v. § 305 Abs. 1 Satz 3 BGB vereinbart ist. Folglich scheidet eine richterliche Inhaltskontrolle nach § 307 BGB aus. Was das für die neuralgischen Klauseln einer Haftungsfreizeichnung oder einer umfassenden Haftungsbegrenzung („cap“) bedeutet, wird weiter unten noch im Einzelnen dargestellt werden (Kap. K Rz. 60); 1 Hierzu auch AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 9 ff. 2 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110, 1111. 3 Hierzu auch Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 47 ff. 4 BGH v. 17.2.2010 – VIIIZR 67/09, NJW 2010, 1131. 5 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110. 6 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 48 f. 7 BGH v. 16.7.1998 – VII ZR 9/97, NJW 1998, 3488 (3489). 8 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). 9 BGH v. 17.2.2010 – VIII 67/09, NJW 2010, 1131, 1133; vgl. auch Kaufhold, ZIP 2010, 631, 634; Graf von Westphalen, ZIP 2010, 1110 ff. 10 BGH v. 17.2.2010 – VIII 67/09, NJW 2010, 1131 (1133).

990

Graf von Westphalen

Individualvereinbarung

Rz. 36 J

hier muss es ausreichen, den von der Rechtsprechung entwickelten Regelsatz als in sich stimmig zu bezeichnen. Denn auch die später noch nachzuzeichnende rechtspolitische Debatte (Rz. 44 ff.) um die Grenzziehung bei einem Individualvertrag i.S.d. § 305 Abs. 1 Satz 3 BGB greift in der Sache nicht durch: Soweit nämlich in der Tat eine vom Verwender vorgelegte Klausel tatsächlich entsprechend den Interessen des anderen Vertragsteils abgeändert worden ist, wird man grundsätzlich zu dem Resultat gelangen müssen, dass dies eine ausgehandelte Vereinbarung darstellt. Doch dass auch hier wiederum Grenzüberschreitungen vorliegen können, soll nicht verschwiegen werden, wird aber erst weiter unten näher beleuchtet werden (Rz. 56 ff.). 2. Unveränderte Übernahme einer Klausel a) Ausgangslage der Rechtsprechung Hat der AGB-Verwender den „gesetzesfremden Kerngehalt“ der betreffen- 36 den Klausel1 ernsthaft zugunsten seines Vertragspartners zur Disposition gestellt, ist aber gleichwohl eine Abänderung des vorformulierten Textes tatsächlich nicht erfolgt, dann stellt sich die schwierige Frage, unter welchen Voraussetzungen dennoch eine ausgehandelte Individualabrede gemäß § 305 Abs. 1 Satz 3 BGB bejaht werden kann. Die Ausgangsentscheidung des BGH vom 3.11.19992 meint, dass allenfalls unter „besonderen Umständen“ ein „Aushandeln“ auch dann angenommen werden kann, wenn der einseitig „gestellte Entwurf“ – freilich, wie hinzuzusetzen ist: „nach gründlicher Erörterung“ – unverändert verbleibt3. Insofern reicht es nach Ansicht des BGH nicht aus, wenn der AGB-Verwender einem Vertragspartner lediglich „freistellt“, den ihm vorgelegten Vertrag auch zu unterzeichnen oder dies sein zu lassen4. Noch restriktiver scheint die Rechtsprechung des VII. Senats des BGH5. Denn danach reicht auch die allgemein geäußerte Bereitschaft, Vertragsklauseln auch auf Bitten/Verlangen seines Vertragspartners zu ändern, nicht aus, um als „Aushandeln“ nach § 305 Abs. 1 Satz 3 BGB qualifiziert zu werden. Im konkreten Fall ging es darum, dass der AGB-Verwender eine – unwirksame – Bürgschaft auf erstes Anfordern vorsah, welche der Kunde allerdings bereitwillig akzeptieren wollte, weil diese – bis zum Erlass einer gegenteiligen Rechtsprechung des BGH6 – als durchaus übliches Sicherungsinstrument in der Baubranche angesehen wurde7. Doch nach Auffassung des BGH rechtfertigt ein solches Verhalten nicht die Annahme, dass der AGB-Verwender die betreffende Klausel auch ernsthaft zur

1 2 3 4

BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). BGH v. 19.5.2005 – III ZR 437/04, NJW 2005, 2543 – Partnerschaftsvermittlungsvertrag. 5 BGH v. 14.4.2005 – VII ZR 56/04, NJW-RR 2005, 1040 (1041). 6 BGH v. 10.4.2003 – VII ZR 314/01, NJW 2003, 2605 (2607) m.w.N. 7 BGH v. 23.1.2003 – VII ZR 210/01, NJW 2003, 1805.

Graf von Westphalen

991

J Rz. 37

Leistungsstörungen

Disposition seines Kunden gestellt hätte1. Die Folge ist, dass hier dann keine ausgehandelte Individualabrede vorliegt. b) Versuch einer Konkretisierung 37 Sofern eine Klausel in einem Software-Erstellungsvertrag als AGB-Klausel nach § 305 Abs. 1 Satz 1 BGB zu qualifizieren ist, aber im endgültigen Vertragstext unverändert – etwa: auch bei einer Freizeichnungs- oder Haftungsbegrenzungsklausel – übernommen wurde, dann stellt sich zunächst die Frage, in welchem Maß der AGB-Verwender verpflichtet war, einem Vertragspartner die „reale Möglichkeit“2 einzuräumen, tatsächlich auf den Inhalt der Vertragsklausel Einfluss zu nehmen3. Nimmt man die Rechtsprechung des VII. Zivilsenats des BGH zum Maßstab4, dann ist der AGB-Verwender verpflichtet, den „gesetzesfremden Kerngehalt“ der betreffenden Klausel ernsthaft zur Disposition zu stellen, so dass erst dann dem Vertragspartner die Möglichkeit offen steht, seine eigenen Abänderungswünsche auch tatsächlich einzubringen und auf die Vertragsgestaltung Einfluss zu nehmen5. 38 Bezogen auf die in einem Software-Erstellungsvertrag zentrale Haftungsbegrenzungsklausel bedeutet dies: Es reicht danach wohl nicht aus, wenn der AGB-Verwender lediglich die Höhe der Gesamthaftung – gleichgültig, ob diese in einem Prozentsatz des Kaufpreises oder nominal in einem Euro-Betrag ausgedrückt ist – zur Disposition seines Vertragspartners stellt. Denn diese Vorgehensweise bezieht sich nicht unmittelbar auf den „gesetzesfremden Kerngehalt“ der Haftungsbegrenzungsklausel6. Dieser ist vielmehr erst dann bei einer solchen Klausel erreicht, wenn der gesamte Klauselinhalt ernsthaft zur Disposition gestellt wird. Denn eine jede Haftungsbegrenzung weicht vom dispositiven Recht ab, enthält also allemal noch einen „gesetzesfremden Kerngehalt“7. Das besagt, dass der AGB-Verwender danach auch gehalten wäre, eine Haftung nach gesetzlichen Bestimmungen als mögliche Alternative seinem Vertragspartner anzubieten. 39 Das geht freilich sehr weit und ist deswegen nicht überzeugend, weil es im Rahmen eines Aushandelns nach § 305 Abs. 1 Satz 3 BGB entsprechend der hier vertretenen Auffassung entscheidend darauf ankommt, ob der Vertragspartner des AGB-Verwenders tatsächlich in der Lage war, auf die Vertragsgestaltung Einfluss zu nehmen. Dies ist das alles entscheidende

1 2 3 4 5

BGH v. 14.4.2005 – VII ZR 56/04, NJW-RR 2005, 1040 (1041). BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). BGH v. 17.2.2010 – VIII 67/09, NJW 2010, 1131 (1133). BGH v. 14.4.2005 – VII ZR 56/04, NJW-RR 2005, 1040 (1041). Grundlegend BGH v. 7.3.2013 – VII ZR 162/12, NJW 2013, 1431 – der gesamte „gesetzesfremde Kerngehalt“ muss zur Disposition gestellt werden; enger Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 51. 6 BGH v. 14.4.2005 – VII ZR 56/04, NJW-RR 2005, 1040 (1041). 7 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111).

992

Graf von Westphalen

Individualvereinbarung

Rz. 41 J

Merkmal1. Tut er dies, dann macht er in jedem Fall im Rahmen seiner Einflussnahme von seiner privatautonomen Gestaltungsfreiheit Gebrauch, so dass dann die Voraussetzungen einer Individualabrede vorliegen. Bezogen auf eine Haftungsbegrenzungsklausel besagt dies, dass es ausreicht, wenn der Verwender die Höhe der Haftung ernsthaft zur Disposition stellt, so dass sich dann die Parteien auf einen Wert verständigen, der den beiderseitigen berechtigten Interessen entspricht. Bezogen auf eine Haftungsfreizeichnung liegen die Dinge anders. Denn diese weicht fundamental vom dispositiven Recht ab. Daher ist hier der Verwender allemal verpflichtet, dem anderen Vertragsteil anzubieten, dass eine Haftungsbegrenzungsklausel als beiderseits interessengerechte Lösung dies Interessenkonflikts in Betracht zu ziehen ist. Dabei macht es keinen entscheidenden Unterschied, welche Schadensersatzhaftung bei einer bestimmten Pflichtverletzung des Auftragnehmers in Rede steht, ob es sich um Fälle des Verzugs, der Schlechterfüllung oder der Mängelhaftung handelt. Dass auch in diesen Fällen eine Ausstrahlungswirkung der jeweils geänderten AGB auf solche Klauseln zu prüfen ist, welche nicht geändert worden sind, sei nicht verschwiegen, wird aber an anderer Stelle noch behandelt, so dass darauf zu verweisen ist (Rz. 67 f.). Gestützt werden diese Erwägungen dadurch, dass in dem BGH-Urteil vom 40 3.11.19992 lediglich davon die Rede ist, dass eine – unverändert übernommene, aber ausgehandelte Klausel – voraussetzt, dass sie eine „gründliche Erörterung“3 erfahren hat. Diese aber reicht unter Beachtung einer neueren Entscheidung des BGH aus4, um zu gewährleisten, dass der Vertragspartner des AGB-Verwenders tatsächlich in der Lage war, entsprechend seinen eigenen Vorstellungen und Interessen auf die Vertragsgestaltung Einfluss zu nehmen. Wird also eine solche – privatautonome – Einflussnahme auf den Inhalt der betreffenden Klausel auf Grund des Gangs der Vertragsverhandlungen erkennbar, dann reicht dieser Umstand grundsätzlich aus (Rz. 41 ff.), um eine Individualabrede nach § 305 Abs. 1 Satz 3 BGB zu bejahen. c) Eigene Auffassung aa) Abänderungsbereitschaft Doch wird man eine „gründliche Erörterung“5 im Zweifel nur dann als 41 hinreichende Basis für das Vorliegen eines ausgehandelten Individualvertrages nach § 305 Abs. 1 Satz 3 BGB annehmen dürfen, wenn ausreichende Indizien dafür vorliegen, dass der Kunde tatsächlich in der Lage war, die Vertragsgestaltung entsprechend seinen eigenen Interessen auch zu beeinflussen. Dies setzt jedoch voraus, dass der AGB-Verwender tatsächlich ab1 A.M. wohl BGH v. 7.3.2013 – VII ZR 162/12, NJW 2013, 1431; vgl. auch Graf von Westphalen, BB 2013, 909. 2 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110. 3 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1112). 4 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131. 5 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1112).

Graf von Westphalen

993

J Rz. 42

Leistungsstörungen

änderungsbereit war, ohne so weit gehen zu müssen, dass er auch den „gesetzesfremden Kerngehalt“ der jeweiligen Klausel ernsthaft zur Disposition gestellt hätte1. Doch ohne den Nachweis einer hinreichenden Bereitschaft, den vorformulierten Text auch tatsächlich abzuändern, wird man kaum davon ausgehen können, dass der AGB-Verwender dem anderen Vertragsteil auch eine ausreichende Einflussnahme auf den Inhalt der betreffenden Klausel gestattet hat. bb) Vorliegen „besonderer Umstände“2 42 Offen ist damit aber noch die weitere Frage, was denn der BGH in seinem maßgebenden Urteil vom 3.11.19993 unter den „besonderen Umständen“ versteht, die nach „gründlicher Erörterung“ ausreichend sein sollen, um eine unverändert übernommene AGB-Klausel rechtlich in den Rang einer Individualabrede zu heben. Um dieses begriffliche Merkmal auszufüllen, erscheint es zweckmäßig und erforderlich, auf alle relevanten Umstände abzustellen, die den Vertragsabschluss begleiten4. Sind also beide Vertragspartner geschäftlich hinreichend erfahren, bedienen sie sich sogar anwaltlicher Hilfe bei den Vertragsverhandlungen und ist das Volumen des Software-Erstellungsvertrages durchaus erheblich – etwa oberhalb der Grenze von 500 000 oder gar von 1 Mio. Euro –, dann sind alle diese Gesichtspunkte in die Waagschale zu werfen5. Zu berücksichtigen ist darüber hinaus auch, welche Dauer die Vertragsverhandlungen in Anspruch genommen haben, weil in der Regel dieses Moment in einem unmittelbaren Verhältnis zum Gegenstand des Vertrages, zum Preis- sowie zur Wettbewerbssituation, in der sich die Parteien befinden, steht6. In der Regel indiziert nämlich die Dauer der Verhandlungen, dass die Parteien um die jeweils interessen- und sachgerechte Lösung eines Konflikts – vor allem bei einem größeren Projekt – nachhaltig gerungen haben, um dann letztlich mit der gefundenen Lösung auch einverstanden zu sein. Denn das Konfrontieren der einen Partei mit den AGB des Verwenders erfordert für gewöhnlich nur, dass der Akt des „Stellens“ i.S.d. § 305 Abs. 1 Satz 1 BGB sich vollzieht7. Daher wird man auch fragen müssen, ob und in welchem Umfang Preiszugeständnisse gemacht worden sind, die – möglicherweise – in einem unmittelbaren Verhältnis zu der betreffenden Klausel stehen. Doch löst diese Frage ein Sonderproblem aus, was erst weiter unten behandelt wird; es geht nämlich um die Bewältigung von Konstellationen, die mit dem Stichwort der sog. „Tarifwahl“ zusammen hängen (Rz. 63). 1 Hierzu auch Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 51; einschränkend und im Ergebnis großzügiger Staudinger/Schlosser, § 305 BGB Rz. 36a; vgl. auch OLG Köln v. 23.6.1995 – 19 U 274/94, WM 1995, 1593. 2 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2010, 1110 (1112). 3 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1112). 4 AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 17 ff. 5 Hierzu auch – freilich de lege ferenda – Müller/Griebler/Pfeil, BB 2009, 2258 ff. 6 AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 17. 7 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131.

994

Graf von Westphalen

Individualvereinbarung

Rz. 44 J

Eine hinreichende Rechtssicherheit wird man gleichwohl bei dieser Frage, 43 was denn unter den „besonderen Umständen“1 zu verstehen ist, bei denen die unveränderte Übernahme einer vorformulierten Klausel gleichwohl als Individualvertrag einzuordnen ist, unter Berücksichtigung der bislang ergangenen BGH-Judikatur nicht ohne weiteres finden können. Das wird auch deutlich, wenn man sich an die Ergebnisse wendet, welche in der instanzgerichtlichen Rechtsprechung in diesem Punkt zu Tage gefördert worden sind und die dann – so oder anders – auch in der Literatur ihren Niederschlag gefunden haben. Davon soll jetzt die Rede sein. d) Instanzgerichtliche Rechtsprechung – Literatur Die instanzgerichtliche Judikatur bestätigt, dass umfangreiche und langwie- 44 rige Vertragsverhandlungen in der Regel ausreichen, um eine Individualvereinbarung gemäß § 305 Abs. 1 Satz 3 BGB zu konstituieren2. Auch kann ein Aushandeln dann vorliegen, wenn verschiedene vorformulierte Vertragsbestimmungen ernsthaft zur Disposition gestellt worden sind, obwohl dann die entscheidende Klausel – hier: eine Bürgschaft auf erstes Anfordern – nicht abgeändert wurde3. Ins Gewicht fällt auch, ob der Vertragspartner des AGB-Verwenders über hinreichende fachlich-sachliche Erfahrung, insbesondere aber auch über einschlägige juristische Kenntnisse verfügt, um die Bedeutung einer – unverändert gebliebenen – Klausel zu ermessen, was dann für die Annahme einer Individualvereinbarung ausreicht4. Im Übrigen gibt es aber eine Fülle von instanzgerichtlichen Entscheidungen, die – vor allem auch bei größeren Projekten – belegen, dass die Hürde des § 305 Abs. 1 Satz 3 BGB sehr hoch liegt, wenn eine Abänderung der einseitig vorformulierten Klausel tatsächlich weder ernsthaft vorgeschlagen noch wirklich nachhaltig intendiert war und daher auch nicht stattgefunden hat5. Im Ergebnis wird man allerdings festhalten müssen, dass die instanzgerichtliche 1 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1112). 2 OLG Nürnberg v. 10.11.2010 – 12 U 565/10, MDR 2011, 345 – Preisanpassungsklausel. 3 OLG Düsseldorf v. 2.7.2004 – 23 U 172/03, OLGR Düsseldorf 2005, 31. 4 OLG Köln v. 19.5.1995 – 20 U 199/94, OLGR Köln 1996, 13. 5 OLG Hamburg OLG 2011, 2663 (2669) – Bürgschaft auf erstes Anfordern; OLG Köln v. 17.8.2010 – 3 U 69/09, BeckRS 2011, 23934 – Vertragsstrafenklausel in einem Bauvertrag, OLG Köln v. 30.10.2009 – 19 U 46/09, BeckRS 2010, 14701 – Kooperationsvertrag: Nicht erreichende definierte Mindest-Umsatzerwartung – Ausgleichszahlung – lediglich ein Erläutern der Klausel; OLG Celle v. 29.7.2009 – 14 U 67/09, NJW-RR 2009, 1529 – Koppelung der auszuzahlenden Vergütung in einen Generalplanervertrag zum Nachteil des nachgeschalteten Architekten und Ingenieurs: Der AGB-Verwender hat hier vorgetragen, er hätte den Vertrag mit einem anderen Subunternehmer abgeschlossen, wenn der Vertragspartner sich geweigert hätte, diese Klausel zu akzeptieren; OLG Celle v. 11.10.2007 – 6 U 40/07, OLGR Celle 2009, 91 – Vertragsstrafeklausel: Bauvertrag; OLG Hamm v. 2.2.2007 – 26 U 91/06, juris = BeckRS 2008, 08876 – selbstschuldnerische Bürgschaft: Bauvertrag.

Graf von Westphalen

995

J Rz. 45

Leistungsstörungen

Judikatur sich bislang nahtlos an die Voraussetzungen hält, welche in der BGH-Judikatur entwickelt worden sind, um ein wirksames Aushandeln i.S.v. § 305 Abs. 1 Satz 3 BGB zu bejahen. Ein Löcken gegen den Stachel der Rechtsprechung des BGH ist bislang jedenfalls nicht festzustellen. 45 In der Kommentarliteratur überwiegen demzufolge auch noch die Stimmen, welche der BGH-Judikatur – auch im unternehmerischen Bereich – Folge leisten und die strengen Voraussetzungen eines Aushandelns i.S.v. § 305 Abs. 1 Satz 3 BGB als zutreffende Interpretation der gesetzlichen Norm, des „Aushandelns“ betrachten1. Doch es finden sich auch Gegenstimmen. So vertritt etwa Schlosser2 die Auffassung, im unternehmerischen Verkehr müsse ein großzügigeres Raster gelten, um ein Aushandeln nach § 305 Abs. 1 Satz 3 BGB zu bejahen3. Grüneberg steht auf dem Standpunkt, der AGB-Verwender müsse dem anderen Vertragsteil eine angemessene Verhandlungsmöglichkeit einräumen, so dass dieser in der Lage sei, mit zumutbarem Aufwand seine eigenen Interessen wahrnehmen zu können. Zurückhaltend gegenüber der Rechtsprechung des BGH äußert sich auch Pfeiffer4. 46 Auffallend ist allerdings, dass diese Kritik sich nicht unmittelbar gegen bestimmte, als eindeutig fehlerhaft zu beurteilende BGH-Entscheidung richtet, sondern die als zu rigide empfundene Interpretation des Begriffs „Aushandeln“ in § 305 Abs. 1 Satz 3 BGB als solche – und damit tendenziell auch den Gesetzgeber – angreift. Geltend gemacht wird vor allem, dass die unternehmerische Freiheit des Verwenders zu sehr eingeschränkt werde, wenn – sozusagen als Regelfall – eine Abänderung des vorformulierten Textes einer AGB-Klausel als Bedingung für eine Individualabrede verlangt wird. In der Aufsatz-Literatur wird daher gerade in letzter Zeit zudem – oberhalb der Bandbreite einer wissenschaftlichen Kritik – vermehrt geltend gemacht, eine gesetzliche Reform von § 305 Abs. 1 Satz 3 BGB sei im unternehmerischen Verkehr rechtspolitisch dringend geboten. Dabei werden auch einzelne Gesetzgebungsvorschläge unterbreitet5. Teilweise wird aber auch der Versuch unternommen, unter Hinweis auf die besonderen Gegebenheiten des unternehmerischen Verkehrs die von der Rechtsprechung erzielten Ergebnisse zu § 305 Abs. 1 Satz 3 BGB durch eine wohl nicht zulässige Uminterpretation des Begriffs „aushandeln“ zu einem einfachen „verhandeln“ abzumildern6. Denn letzteres bezeichnet lediglich eine Tätig1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 47 ff.; AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 9 ff.; Erman/Roloff, § 305 BGB Rz. 18 ff.; MünchKomm/Basedow, § 305 BGB Rz. 37. 2 Staudinger/Schlosser, § 305 BGB Rz. 36a, Rz. 44. 3 Palandt/Grüneberg, § 305 BGB Rz. 24. 4 Pfeiffer, in: Wolf/Lindacher/Pfeiffer, § 305 BGB Rz. 38 f. 5 Berger, NJW 2010, 465 ff.; Müller/Griebler/Pfeil, BB 2009, 2658 (2660). 6 Palandt/Grüneberg, § 305 BGB Rz. 24; Dauner-Lieb/Axer, ZIP 2010, 309 ff.; Leuschner, JZ 2010, 875 ff.; Lenkaitis/Löwisch, ZIP 2009, 441 ff.; Kessel/Jüttner, BB 2008, 1350 (1352); Lischek/Mahnken, ZIP 2007, 158 ff.; Berger, ZIP 2006, 2149 ff.

996

Graf von Westphalen

Individualvereinbarung

Rz. 49 J

keit, während ein „aushandeln“ begrifflich immer einschließt, dass auch ein abweichendes Ergebnis erzielt wurde, was darauf hindeutet, dass dann auch den Interessen des anderen Vertragsteils hinreichend Rechnung getragen wurde. Ohne insoweit auf weitere Einzelheiten in der jeweiligen, vor allem auch 47 rechtspolitisch geprägten Argumentation einzugehen1, lässt sich zusammenfassen sagen: Diese Autoren bestreiten im Wesentlichen den von der BGH-Judikatur2 aufgestellten Grundsatz, dass auch im unternehmerischen Bereich nur eine abgeänderte Klausel im Regelfall die Voraussetzungen eines Aushandelns nach § 305 Abs. 1 Satz 3 BGB erfüllt, so dass auch – großzügiger als bislang von der BGH-Judikatur bejaht – die Möglichkeit eröffnet werden solle, dass eine unverändert übernommene Klausel als Individualabrede akzeptiert werden könne. Denn der Unternehmer, so lässt sich die Argumentation auf den Punkt bringen, weiß in aller Regel, was er tut; er handelt grundsätzlich selbstverantwortlich und muss daher auch an diesem Ergebnis gemessen werden, wenn er eine unveränderte Klausel akzeptiert hat, und zwar auch dann, wenn sie der richterlichen Inhaltskontrolle nach § 307 BGB als AGB-Klausel nicht standhalten würde. Auf die dogmatische Berechtigung dieser Kritik näher einzugehen, ist hier 48 aus praktischen Gründen nicht angezeigt3. Denn die von den Kritikern vertretene Ansicht ist, weil und soweit sie von der Auffassung des BGH abweicht4, keine unbedingt verlässliche Hilfe im Rahmen einer streitigen Auseinandersetzung5. Es muss daher ausreichen, vor allem auch auf die Stimmen zu verweisen, welche nach wie vor die Rechtsprechung des BGH auch für den unternehmerischen Bereich als zutreffend und sachgerecht einschätzen6. Für den weiteren Gang der hier anzustellenden Erwägungen ist also im Grundsatz der BGH-Judikatur zu folgen. e) Schiedsgerichtliches Urteil Da bei Software-Erstellungsverträgen häufig Schiedsgerichtsklauseln vereinbart werden, ist es notwendig, auch auf die Entscheidung des ICC-Zwischenschiedsspruchs Nr. 10279 vom 29.1.2001 hinzuweisen7. Dieser Schieds1 Hierzu auch Berger, FS für Graf von Westphalen, 2010, S. 13, 17 ff., der ein Urteil eines ICC-Schiedsgerichts zum Tatbestand des Aushandelns – SchiedsVZ 2005, 108 – im Einzelnen darstellt s. Rz. 49 ff. 2 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111 f.). 3 Graf von Westphalen, BB 2010, 195 ff.; Graf von Westphalen, NJW 2009, 2977. 4 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110. 5 Vgl. aber für das Aushandeln von Großprojekten instruktiv Kessel/Stomps, BB 2009, 2666 ff. 6 Insbesondere Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 47 ff.; Erman/Roloff, § 305 BGB Rz. 20; MünchKomm/Basedow, § 305 BGB Rz. 37; im Einzelnen auch Graf von Westphalen, ZIP 2010, 1110 ff.; Graf von Westphalen, ZIP 2007, 149 ff. 7 SchiedsVZ 2005, 108 ff. m. Anm. Hobeck, S. 112.

Graf von Westphalen

997

49

J Rz. 50

Leistungsstörungen

spruch trifft bei einem internationalen Anlagen-Liefervertrag folgende Feststellungen: 50 „Zwischen Unternehmern, die sich nicht in einem wirtschaftlichen Ungleichgewicht gegenüber stehen, kann eine Haftungsbegrenzungsklausel („cap clause“) auch dann als ausgehandelt gelten, wenn sie während der Vertragsverhandlungen nicht geändert und von einer Vertragspartei als nicht verhandelbar hingestellt wurde, solange sie nur Gegenstand der Verhandlungen zwischen den Parteien war. Die Annahme, eine derartige Klausel sei unter diesen Voraussetzungen nicht ausgehandelt, ist mit der kaufmännischen Rechtswirklichkeit nicht zu vereinbaren“1.

51 Ob dieser Tendenz auch in einem – nationalen – Software-Erstellungsvertrag bei Vereinbarung einer Schiedsgerichtsklausel zu folgen ist, um eine unverändert gebliebene, aber verhandelte Haftungsbegrenzungsklausel als individualvertragliche Vereinbarung zu qualifizieren, kann offen bleiben. Denn solche Entscheidungen eines Schiedsgerichts hängen in hohem Maß von der Bereitschaft der einzelnen Schiedsrichter ab, sich an eine fest gefügte Ansicht in der Judikatur auch dann anzulehnen, wenn sie den tradierten Resultaten einer abweichenden internationalen oder auch nationalen Praxis nicht entspricht. Das ist erfahrungsgemäß wohl selten. 52 Dabei ist gleichzeitig und ganz grundsätzlich anzumerken, dass die Bereitschaft eines AGB-Verwenders, sich an die etablierten Ergebnisse der Judikatur bei der eigenen Klauselgestaltung anzulehnen, jedenfalls dann – auf Grund langjähriger Erfahrung ist dies zu bestätigen – mitunter sehr begrenzt ist, wenn es sich um die Umsetzung der grundlegenden Erkenntnis handelt, dass formularmäßige Freizeichnungs- und Haftungsbegrenzungsklauseln im Kontext von § 307 Abs. 2 Nr. 1 BGB streng genommen nicht mehr als wirksame Vereinbarungen zu haben sind2. Doch ist der Vollständigkeit halber zu erwähnen, dass dieses Schieds-Urteil teilweise als „Markenzeichen“ angesehen wird, um den angeblichen Irrweg der BGH-Judikatur – vor allem im internationalen Bereich – näher zu markieren3. 53 Teilweise wird freilich auch die Meinung vertreten, dass bei der Beurteilung einer vorformulierten Klausel als Ausgang der Individualvereinbarung i.S.v. § 305 Abs. 1 Satz 3 BGB vor allem auch die wirtschaftlichen Kräfte- und Gleichgewichtsverhältnisse zu berücksichtigen sind4. Doch ist im gleichen Atemzug dem entgegenzusetzen, dass der BGH es abgelehnt hat, die wirtschaftlichen Macht- und Marktverhältnisse überhaupt zu berücksichtigen, soweit die Definition des „Stellens“ von vorformulierten AGB-Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB in Rede stehen. Denn nach seiner Auffassung 1 Hierzu im Einzelnen auch Berger, FS für Graf von Westphalen, 2010, 13, 17 ff. 2 Hierzu bereits Graf von Westphalen, FS für Trinkner, 1996, S. 441 ff.; Übersicht über die Entwicklung der Judikatur in den letzten 50 Jahren vgl. Graf von Westphalen, BB 2011, 195 ff. 3 Vgl. auch Berger, NJW 2001, 2152 (2154); Berger/Kleine, BB 2007, 2137 (2138 f.); Langner, WM 2006, 1233, 1237; vgl. auch Rabe, NJW 1987, 1978 (1980). 4 Hierzu auch Berger, in: Prütting/Wegen/Weinreich, § 307 BGB Rz. 36; Staudinger/Schlosser, § 310 BGB Rz. 12 a.E.

998

Graf von Westphalen

Individualvereinbarung

Rz. 56 J

kommt es ausschließlich darauf an, welche der beiden Parteien einseitig die Vertragsgestaltungsfreiheit für sich reklamiert hat, um als AGB-Verwender den anderen Vertragsteil mit dem Klauselwerk zu konfrontieren1. Es fügt sich in dieses Bild, dass laut BGH damit auch allen Erwägungen eine Absage zu erteilen ist, die darauf aufbauen, dass sowohl im Rahmen von § 305 Abs. 1 Satz 3 BGB als auch – insbesondere – im Kontext der richterlichen Inhaltskontrolle nach § 307 BGB eine branchen- und gruppenspezifische Differenzierung vorzunehmen sein sollte2. Entscheidend ist nämlich hier der auf der Hand liegende Gegeneinwand: Es 54 fehlen auf Sicht verlässliche, gerichtlich überprüfbare Kriterien, um – gemessen an den Erfordernissen der Rechtssicherheit – Maßstäbe zu entwickeln, die hier weiterhelfen könnten. Vielmehr wäre zu besorgen, dass für eine höhere Flexibilisierung eine im Ergebnis nicht mehr zu bewältigende Flut an Präjudizien – entsprechend den unterschiedlichsten Marktund Branchegegebenheiten – entstehen würde3. Denn was soll vorgetragen werden: Umsatzzahlen, Marktanteile, technisches Know-how, juristisches Knowhow des Unternehmens, der Beteiligten? Was wiegt im Einzelfall schwerer? Hinzu tritt auch der berechtigte Einwand, dass eine konturenscharfe Trennlinie zwischen den einzelnen – wie auch immer gearteten – Gruppen/Branchen nicht verlässlich gezogen werden kann. Im Ergebnis wird man also den vorerwähnten Schiedsspruch4 schlicht nur 55 zur Kenntnis nehmen müssen. Denn soweit ersichtlich, hat er bislang jedenfalls in keiner Weise auf die instanzgerichtliche Judikatur, und schon gar nicht auf die des BGH, irgendeinen Einfluss entwickelt. Vereinzelt gebliebene Urteile eines Schiedsgerichts sind daher keine hinreichende Basis, eine von der Praxis als fest gefügt angesehene Linie der Judikatur des BGH hinter sich zu lassen5. 3. Besondere Konstellationen Gerade im Zusammenhang mit der Verhandlung von Software-Erstellungs- 56 verträgen, aber auch bei allen sonstigen Großprojekten ergeben sich indessen immer wieder bestimmte mehr oder weniger als typisch einzuordnende Konstellationen, deren rechtliche Bewertung entscheidend dafür ist, ob in der Tat ein Aushandeln i.S.v. § 305 Abs. 1 Satz 3 BGB gerade dann zu bejahen ist, wenn die betreffende vorformulierte Klausel – vor allem auch im 1 BGH v. 17.2.2010 – VIII 67/09, NJW 2010, 1131 (1133). 2 Hierzu Lenkaitis/Löwisch, ZIP 2009, 441 (445 ff.); Kessel/Stomps, BB 2009, 2666 (2668 ff.); Berger/Kleine, BB 2007, 2137 (2138 f.); vgl. auch Fuchs, in: Ulmer/ Brandner/Hensen, § 307 BGB Rz. 373 ff. 3 Graf von Westphalen, NJW 2008, 2977 (2980); vgl. auch Kessel/Stomps, BB 2009, 2666 (2675). 4 ICC-Schiedsspruch v. 29.1.2001 – Schiedsverfahren Nr. 10279, SchiedVZ 2005, 108 ff. 5 A.M. Berger, FS für Graf von Westphalen, 2010, S. 13, 17 ff.

Graf von Westphalen

999

J Rz. 57

Leistungsstörungen

Bereich der Risiko- und Haftungsbegrenzung – unverändert übernommen wurde. a) Grundansatz: § 311 Abs. 2 BGB 57 Bittet der AGB-Verwender/Auftraggeber um Zustimmung zu einer von ihm vorgeschlagenen Klausel und bietet er gleichzeitig dem Auftragnehmer an, etwaige Änderungsvorschläge prüfen zu wollen, so stellt sich die Frage, ob eine solche Verhandlungssituation im Kontext von § 311 Abs. 2 BGB ausreicht, um eine Obliegenheit des Auftragnehmers zu begründen, seinerseits Gegenvorschläge zu unterbreiten1. Ob diese Situation vorliegt, kann freilich nur unter Beachtung der Umstände des Einzelfalls beantwortet werden. Beweisbelastet ist hier in der Regel der AGB-Verwender, weil es ja um den Nachweis einer Individualabrede geht2. Verweigert sich aber der Auftragnehmer in diesen Fällen, Gegenvorstellungen überhaupt zu formulieren, etwa auch deswegen, weil er erkennt, dass die vorgeschlagene Klausel ohnehin AGB-widrig ist, dann stellt sich zunächst die Frage, ob der dogmatische Ansatz zutreffend ist, aufgrund der laufenden Vertragsverhandlungen sei eine Obliegenheit des Auftragnehmers i.S.v. § 311 Abs. 2 BGB abzuleiten, sich auf die so angebotenen Verhandlungen auch nachhaltig und selbstverantwortlich einzulassen. Dieser Ansatz wird teilweise in der Literatur abgelehnt3. Doch ist dem zu widersprechen. Denn anerkanntermaßen löst das Bestehen von Vertragsverhandlungen gegenseitige Rücksichtspflichten aus, so dass der Auftragnehmer nicht berechtigt ist, ein solches – ernsthaftes – Verhandlungsangebot des AGB-Verwenders einfach zu ignorieren. Tut er das nämlich, dann entsteht – rein tatsächlich betrachtet – die vielbeschworene „AGB-Falle“4. Denn die unwirksamen AGB bleiben dann erhalten – zum Vorteil des anderen Vertragsteils. Der Verwender ist dann der Blamierte. 58 Doch sind solche Befürchtungen nicht begründet. Der Schlüssel liegt nämlich in § 311 Abs. 2 BGB: Gerade weil das Stellen einer AGB-widrigen Klausel eine Pflichtverletzung des AGB-Verwenders im Kontext von § 311 Abs. 2 BGB darstellt, löst dies auch einen Schadensersatzanspruch gegenüber dem AGB-Verwender aus5. Wenn aber der AGB-Verwender – und dies ist der entscheidende Punkt – dann seinerseits ernsthafte Verhandlungen und damit implizit eine Abänderung der betreffenden, unwirksamen Klausel anbietet, dann muss sich der Auftragnehmer auf entsprechende Verhandlungen auch nach Treu und Glauben einlassen. Jedenfalls muss er in eine selbstverant1 Hierzu Ulmer/Habersack, in Ulmer/Brandner/Hensen, § 305 BGB Rz. 51; Kessel/ Jüttner, BB 2008, 1350 (1353). 2 Palandt/Grüneberg, § 305 BGB Rz. 24. 3 Erman/Roloff, § 305 BGB Rz. 19. 4 Vgl. Kessel/Jüttner, BB 2008, 1350 (1353). 5 BGH v. 27.5.2009 – VIII ZR 302/07, NJW 2009, 2590; BGH v. 14.6.1994 – XI ZR 210/93, NJW 1994, 2754; Fuchs, in: Ulmer/Brandner/Hensen, vor § 307 BGB Rz. 104.

1000

Graf von Westphalen

Individualvereinbarung

Rz. 60 J

wortliche Prüfung eintreten und darf den AGB-Verwender nicht in der Schadensersatzhaftung „hängen“ lassen. Tut er dies trotzdem, dann spricht jedenfalls sehr viel dafür, dass es sich um ein widersprüchliches Verhalten des anderen Teils i.S.d. § 242 BGB handelt. Das schließt dann die Berufung auf die Unwirksamkeit der betreffenden 59 Klausel aus. Zur Folge hat dies, dass es sich daher um eine Individualvereinbarung nach § 305 Abs. 1 Satz 3 BGB handelt. Denn dann hatte ja der Auftragnehmer die realistische Möglichkeit, auf die Gestaltung der Klausel tatsächlich auch Einfluss zu nehmen1. Freilich ist sogleich – das Bild abrundend – hinzuzusetzen, dass die Annahme einer Individualvereinbarung nach § 305 Abs. 1 Satz 3 BGB hier davon abhängt, dass der Auftragnehmer tatsächlich Einfluss auf die Gestaltung der Klausel hätte nehmen können. Eine gewisse Differenzierung zur BGH-Judikatur2 liegt freilich darin, dass in dieser Sicht darauf verzichtet wird, vom AGB-Verwender zu fordern, dass dieser uneingeschränkt den gesamten „gesetzesfremden Kerngehalt“ der betreffenden AGB-Klausel ernsthaft zur Disposition zu stellen, bevor eine Individualabrede angenommen werden kann3. Es reicht vielmehr die Einflussnahme auf die Gestaltung der Klausel als reale Möglichkeit aus. Diese auch wahrzunehmen, kann immer von einem Vertragspartner erwartet werden. b) Unabdingbare Klausel Vor allem im Zusammenhang mit Haftungsfreizeichnungs- und Haftungs- 60 begrenzungsklauseln4 kommt es immer wieder vor, dass der AGB-Verwender eine solche Klausel als unabdingbar bezeichnet, weil er gleichzeitig vorgibt, den offerierten Preis auf Basis einer solchen Risikobegrenzungsklausel kalkuliert zu haben. Im Rahmen der hier anzusprechenden Lösung dieses Problems ist zu erwähnen, dass der BGH5 in einem Mietvertrag – obiter – festgestellt hat, dass auch eine nicht abgeänderte Klausel, welche der AGBVerwender als unabdingbar hinstellt, in Wirklichkeit eine ausgehandelte Individualvereinbarung nach § 305 Abs. 1 Satz 3 BGB darstellen kann. Doch ist mit Recht gegen diese Entscheidung geltend gemacht worden6, dass sich der XII. Senat in diesem Urteil vom 26.2.19927 mit keinem Wort mit der gegenteiligen BGH-Judikatur auseinandergesetzt hat. Mehr noch: Es ist zu unterstreichen, dass dieses Urteil in den nachfolgenden BGH-Entscheidungen 1 BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131; Graf von Westphalen, ZIP 2010, 1110 ff. 2 BGH v. 14.4.2005 – VII ZR 56/04, NJW-RR 2005, 1040 (1041). 3 So allerdings auch BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111 f.). 4 ICC-Schiedsspruch v. 29.1.2001 – Schiedsverfahren Nr. 10279, SchiedsVZ 2005, 108. 5 BGH v. 26.2.1992 – XII ZR 129/90, NJW 1992, 2283 (2285). 6 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 51 bei Fn. 191. 7 BGH v. 26.2.1992 – XII ZR 129/90 NJW 1992 (2283); vgl. aber BGH v. 21.12.2012 – VII ZR 222/12, NJW 2013, 856.

Graf von Westphalen

1001

J Rz. 61

Leistungsstörungen

(auch und vor allem anderer Senate) keinen Widerklang gefunden hat1. Auch in der nachfolgenden Entscheidungen des VII. Senats vom 14.4.20052 findet dieses Urteil keine Resonanz. Daher wird man gut daran tun, auch im unternehmerischen Verkehr festzuhalten, dass es nicht ausreicht, die Voraussetzungen einer Individualabrede gemäß § 305 Abs. 1 Satz 3 BGB zu bejahen, wenn der AGB-Verwender in der Verhandlung schlicht kategorisch erklärt, eine bestimmte Klausel sei für ihn unabdingbar3. Denn dann verweigert er dem anderen Teil die reale Möglichkeit, auf die Gestaltung des Vertrags auch Einfluss zu nehmen, so dass es bei der Grundaussage bleibt: Hier wird dann nur einseitige Gestaltungsmacht des Verwenders ausgeübt, er konfrontiert den anderen Teil mit seinem Bedingungswerk und nimmt allein für sich die Vertragsgestaltungsfreiheit in Anspruch4. c) Sachliche Notwendigkeit einer Klausel 61 Etwas anderes kann dann i.S.v. § 305 Abs. 1 Satz 3 BGB gelten, wenn der AGB-Verwender im Einzelnen darlegt, dass eine bestimmte Klausel für ihn sachlich notwendig ist5. Gerade bei Haftungsbegrenzungsklauseln in Software-Erstellungsverträgen wird man geneigt sein können, insoweit ein durchaus berechtigtes Interesse des AGB-Verwenders/Auftragnehmers an einer solchen Klauselgestaltung im Grundsatz anzuerkennen6. Ob allerdings die simple Erklärung des AGB-Verwenders, er habe ein berechtigtes Interesse an der betreffenden Klausel, ausreicht, die Voraussetzungen des Aushandelns i.S.v. § 305 Abs. 1 Satz 3 BGB zu bejahen, erscheint zweifelhaft. Vorzuziehen ist allemal die Erwägung, die bei der Beurteilung einer Haftungsbegrenzungsklausel relevant werden kann7: Diese ist ja immer dann als unangemessen anzusehen, wenn sie die Haftung des AGB-Verwenders unterhalb der Schwelle des vorhersehbaren, typischerweise eintretenden Schadens begrenzt. Daher wird man wohl vom AGB-Verwender fordern müssen, dass er bereit ist, die Klausel nicht nur als „unabdingbar“ oder als „gesetzlich notwendig“ zu bezeichnen, sondern auch die Bereitschaft signalisiert, alternative Vorschläge des Auftragnehmers nachhaltig in Erwä1 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1112). 2 BGH v. 14.4.2005 – VII ZR 56/04, NJW-RR 2005, 1040 (1041). 3 Hierzu BGH v. 21.12.2012 – VII ZR 222/12, NJW 2013, 856 (858); auch Ulmer/ Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 51; AGB-Klauselwerke/ Graf von Westphalen, Individualvereinbarung, Rz. 23; in der Sache wohl auch: Erman/Roloff, § 305 BGB Rz. 20. 4 BGH v. 7.3.2013 – VII ZR 162/12, NJW 2013, 1431; BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 (1133). 5 AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 22. Doch ist dies auf Grund der jüngsten BGH-Judikation durchaus sehr zweifelhaft – BGH v. 21.12.2012 – VII ZR 222/12, NJW 2013, 856 (858); BGH v. 7.3.2013 – VII ZR 162/12, NJW 2013, 1431. 6 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 51; vgl. auch Erman/Roloff, § 305 BGB Rz. 20. 7 BGH v. 11.11.1992 – VIII ZR 238/91, NJW 1993, 335.

1002

Graf von Westphalen

Individualvereinbarung

Rz. 64 J

gung zu ziehen. Dadurch verschafft er nämlich dem anderen Teil eine reale Möglichkeit, auf die Vertragsgestaltung auch Einfluss zu nehmen. Im Ergebnis ist also die Bejahung einer Individualabrede gemäß § 305 Abs. 1 62 Satz 3 BGB entscheidend davon abhängig, dass der Auftragnehmer die betreffende, als sachlich notwendig angesehene Klausel – nach Ablehnung der Gegenvorschläge durch den Verwender – im Rahmen seiner autonomen Selbstbestimmung freiwillig akzeptiert. Ohne eine ausführliche Erörterung des Für und Wider der unterbreiteten Änderungsvorschläge wird man aber dieses Ergebnis schwerlich bejahen dürfen. d) Tarifwahl Hinter dem Wort von der „Tarifwahl“ versteckt sich die Rechtsfigur, dass 63 der AGB-Verwender seinem Vertragspartner von sich aus alternative Angebote unterbreitet, die zum einen unterschiedliche Vertragsbedingungen, zum anderen einen unterschiedlichen Preis aufweisen. Nach der Rechtsprechung des BGH1 ist es erforderlich, dass der AGB-Verwender – im Rahmen der zu wählenden Alternativen – seinem Vertragspartner die Möglichkeit eröffnet, die Gestaltung des Vertrages (also: der Bedingungen und/oder des Preises) unmittelbar zu beeinflussen2. Es muss sich also darum handeln, dass der Vertragspartner des Verwenders berechtigt ist, selbst den wesentlichen Inhalt der Klausel/des Vertrages auf Grund der unterbreiteten Alternativen autonom zu bestimmen3. Bei einem Software-Erstellungsvertrag kann diese Frage jedenfalls dann 64 praktisch werden, wenn der Auftraggeber dem Auftragnehmer die „Tarifwahl“ in der Weise eröffnet, dass er dem Auftragnehmer die Wahlfreiheit lässt, welche von zwei Alternativen er tatsächlich will: etwa eine Höchsthaftung in Höhe von 20 % des Vertragspreises oder eine solche von 50 % bei unterschiedlicher Preisgestaltung. Dabei ist jedoch darauf zu achten, dass die Wahlfreiheit des Auftragnehmers in vollem Umfang gewahrt bleibt4. Die hinter dieser Rechtsfigur von der „Tarifwahl“ aufscheinende Rechtsfrage lässt sich am besten dadurch in der Praxis beantworten, dass man eine Parallele zu den Voraussetzungen eines Aushandelns i.S.v. § 305 Abs. 1 Satz 3 BGB zieht (Rz. 33 ff.).

1 BGH v. 6.12.2002 – V ZR 220/02, NJW 2003, 1313. 2 Hierzu auch AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 29; Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 56a. 3 BGH v. 13.11.1997 – X ZR 135/95, NJW 1998, 1066 (1067). 4 BGH v. 13.11.1997 – X ZR 135/95, NJW 1998, 1066.

Graf von Westphalen

1003

J Rz. 65

Leistungsstörungen

e) Verbot des planmäßigen Abweichens 65 In der Literatur ist anerkannt1, dass es für die Annahme einer Individualvereinbarung gemäß § 305 Abs. 1 Satz 3 BGB nicht ausreicht, wenn der AGBVerwender planmäßig vorgeht, indem er zum Beispiel eine inakzeptable, offensichtlich unwirksame AGB-Klausel „bereitwillig“ streichen lässt, um so dann eine andere, ebenfalls unwirksame AGB-Klausel in Form einer vorgeblichen „Tarifwahl“ einzusetzen. Denn unter dieser Voraussetzung gestattet der AGB-Verwender seinem Kunden nicht, auf die Gestaltung der AGB tatsächlich Einfluss zu nehmen, weil er ja auch nicht den „gesetzesfremden Kerngehalt“ der AGB-Klausel2 ernsthaft zur Disposition stellt. Demzufolge ist auch daran zu erinnern, dass der BGH in seinem Urteil vom 9.4.19873 entschieden hat: Wenn der AGB-Verwender bei einem Bankvollmachtsformular dem Kunden gestattet, bestimmte Streichungen vorzunehmen, dann reicht dies für die Annahme eines ausgehandelten Individualvertrages nach § 305 Abs. 1 Satz 3 BGB gerade nicht aus. In diesem Fall hat der BGH sogar erklärt, dass die „formularmäßige Aufforderung an den Unterzeichner, den Inhalt einer Formularerklärung durch Streichung einzelner Teile zu verändern“, für sich gar nicht ausreicht, als Aushandeln nach § 305 Abs. 1 Satz 3 BGB qualifiziert zu werden4. 66 Unter dieser Voraussetzung ist daher davor zu warnen, dass der Auftraggeber/AGB-Verwender im Rahmen eines Software-Erstellungsvertrages das Instrument der „Tarifwahl“ (Rz. 63) planmäßig verwendet. Freilich kommt hier alles entscheidend darauf an, dass im Einzelnen die tatbestandlichen Voraussetzungen der Darlegungs- und Beweislast erfüllt werden (Rz. 73 ff.). Das ist nicht sehr leicht. Aber man wird auch hier auf die bereits behandelte Vermutungsregel zurückgreifen können: Sind nämlich die Vertragsbedingungen systematisch und inhaltlich typisch gestaltet (Rz. 22), dann spricht der Beweis des ersten Anscheins bzw. überwiegende Indizien dafür, dass es sich um einen im Voraus vorformulierten Vertrag handelt, so dass § 305 Abs. 1 Satz 1 BGB zum Zuge gelangt. Es ist dann Sache des AGB-Verwenders den Nachweis zu führen, dass gleichwohl die Voraussetzungen eines Individualvertrages i.S.v. § 305 Abs. 1 Satz 3 BGB vorliegen (Rz. 33). f) Reichweite des Aushandelns aa) Grundsatz 67 Liegen die Voraussetzungen einer vorformulierten AGB-Klausel gemäß § 305 Abs. 1 Satz 1 BGB vor, dann ist zu beachten, dass § 305 Abs. 1 Satz 3 BGB das Wort „soweit“ im Zusammenhang mit einem Aushandeln, also 1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 57; Becker, in: Bamberger/Roth, § 305 BGB Rz. 35. 2 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111 f.). 3 BGH v. 9.4.1987 – III ZR 84/86, NJW 1987, 2011. 4 BGH v. 9.4.1987 – III ZR 84/86, NJW 1987, 2011.

1004

Graf von Westphalen

Individualvereinbarung

Rz. 70 J

dem konstitutiven Element eines Individualvertrages verwendet. Dies bedeutet: Soweit dem Kunden tatsächlich die Möglichkeit eröffnet worden ist, Einfluss auf die Gestaltung der Vertragsbedingungen zu entfalten, liegt ein Aushandeln nur für die jeweils einzelne, vom Aushandeln betroffene Klausel vor1. Damit steht vom Grundsatz fest, dass die typische Fallkonstellation bei der Wirksamkeitskontrolle von Vertragsbestimmungen in einem Software-Erstellungsvertrag oft eine Mischform darstellen: Zum einen liegen unveränderte AGB-Klauseln vor, die dann auch der richterlichen Inhaltskontrolle gemäß §§ 307 ff. BGB unterworfen werden; zum anderen handelt es sich aber um ausgehandelte Individualvereinbarungen, deren Grenzen dann lediglich an den §§ 138, 134, 242 BGB zu messen sind. Dabei ist nachhaltig zu betonen, dass ein Aushandeln von Hauptleistung 68 und Preis AGB-rechtlich irrelevant ist. Dies ergibt sich aus § 307 Abs. 3 Satz 1 BGB. Denn alle AGB-Klauseln, die das Hauptleistungsversprechen einer der beiden Vertragsparteien zum Gegenstand haben, unterliegen nicht der richterlichen Inhaltskontrolle. Aus praktischer Sicht wird man auch sagen dürfen, dass die Frage, ob ein Aushandeln einer einzelnen Vertragsbestimmung i.S.v. § 305 Abs. 1 Satz 3 BGB zu bejahen ist, nur für die Vertragsbestimmungen relevant ist, welche ihrerseits – gemessen an den Kriterien von § 307 Abs. 2 Nr. 1 BGB – vom dispositiven Recht abweichen. Denn nur hier stellt sich die Frage, ob eine an sich unwirksame AGB-Klausel letzten Endes den Mechanismen der richterlichen Inhaltskontrolle gemäß §§ 307 ff. BGB entzogen ist, weil es sich um eine ausgehandelte Individualvereinbarung nach § 305 Abs. 1 Satz 3 BGB handelt. Dass diese Aussage freilich nur eine äußerst grobe Regel zum Gegenstand 69 hat, kann durch den Hinweis auf mehrere andere Bestimmungen im Rahmen der §§ 305 ff. BGB verdeutlich werden: Das in § 307 Abs. 1 Satz 2 BGB enthaltene Transparenzgebot gilt ausweislich der Norm von § 307 Abs. 3 Satz 2 BGB auch für die Beurteilung des jeweiligen Hauptleistungsversprechens, sei es der Preis, sei es die vom Auftragnehmer zu erbringende Sachleistung. Auch der Grundsatz vom Vorrang der Individualabrede gemäß § 305b BGB bleibt zu beachten. Schließlich ist auch auf das Verbot der überraschenden Klausel gemäß § 305c Abs. 1 BGB zu verweisen. Denn alle diese Bestimmungen ergänzen in der einen oder anderen Weise die Möglichkeiten der richterlichen Überprüfung von AGB-Klauseln, welche das Hauptleistungsversprechen der beiden Vertragsparteien zum Gegenstand haben. bb) Bestimmung der Reichweite Soweit eine Vertragsbestimmung i.S.v. § 305 Abs. 1 Satz 1 BGB tatsächlich 70 nach § 305 Abs. 1 Satz 3 BGB ausgehandelt worden ist, stellt sich sogleich immer die Frage, ob nicht möglicherweise diese Individualvereinbarung 1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 55; AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 23; Erman/Roloff, § 305 Rz. 22.

Graf von Westphalen

1005

J Rz. 71

Leistungsstörungen

Auswirkungen auf andere Vertragsbestimmungen entfaltet, die ihrerseits als AGB-Klauseln einzuordnen sind1. Diese Prüfung ist immer eine Frage des Einzelfalls2. Soweit die Individualvereinbarung tatsächlich reicht und auch andere, nicht ausgehandelte Vertragsbestimmungen tatsächlich gegenständlich erfasst, ist jeweils durch Auslegung nach den §§ 133, 157 BGB zu ermitteln. Abzustellen ist hier auf den jeweiligen Sachzusammenhang. Man wird nämlich kaum sagen dürfen, dass die individualvertragliche Fixierung einer Haftungshöchstgrenze Auswirkungen hat auf eine – unwirksame – Verjährungsklausel. 71 Soweit also ein Software-Erstellungsvertrag werkvertraglich einzuordnen ist, stellt sich bei der individualvertraglichen Vereinbarung von Zahlungsbedingungen selbstverständlich auch die Frage, ob damit nicht die Vorleistungspflicht des AGB-Verwenders abgeändert wurde; möglicherweise stellt sich auch die weitere Frage, ob auf diese Weise nicht die Einrede des nicht erfüllten Vertrages gemäß § 320 BGB eingeschränkt ist. 72 Sind indessen zahlreiche AGB-Klauseln im Einzelnen ausgehandelt, spricht – per Saldo – vieles dafür, dass es sich dann insgesamt um einen Individualvertrag handelt3. Soweit nämlich der Vertragstext an mehreren Stellen – aufgrund der Einflussnahme des Auftragnehmers – tatsächlich abgeändert worden ist, deuten diese Indizien sehr stark in die Richtung, dass der Auftraggeber/AGB-Verwender seinem Vertragspartner auch im Übrigen die „reale“ Möglichkeit“4 eingeräumt hat, auf die Gestaltung des gesamten Vertrages tatsächlich Einfluss zu nehmen, um seine eigenen Interessen auch durchzusetzen. Hat er diese Möglichkeit dann in Bezug auf einzelne Klauseln nicht genutzt, obliegt ihm die Beweislast, dass es sich um eine AGB handelt. 4. Darlegungs- und Beweislast a) Grundsatz 73 Macht eine Partei geltend, es handele sich um eine AGB-Klausel i.S.v. § 305 Abs. 1 Satz 1 BGB, dann ist sie auch verpflichtet, den entsprechenden Nachweis zu führen5. Dabei streitet der Umstand hier zugunsten der beweisbelasteten Partei, wenn die jeweiligen Vertragsbestimmungen in gedruckter oder in sonstiger vielfältiger Form vorliegen6. Denn dies deutet dann darauf hin, dass das Merkmal der „Vielzahl“ in § 305 Abs. 1 Satz 1 BGB als nachgewiesen angesehen werden kann (Rz. 9). 1 Im Einzelnen: AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 24 f. 2 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 55. 3 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 55. 4 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). 5 BGH v. 25.6.2002 – XI ZR 239/01, NJW-RR 2002, 1344. 6 BGH v. 13.9.2001 – VII ZR 487/99, NJW-RR 2002, 13.

1006

Graf von Westphalen

Individualvereinbarung

Rz. 77 J

Dieser Ansatz versagt allerdings dann, wenn die Vertragsbestimmungen – 74 und dies ist inzwischen üblich – von einem PC ausgedruckt werden. Sie liegen dann in maschinenschriftlicher Form vor und gestatten nicht ohne weiteres den Nachweis, dass es sich um AGB-Klauseln gemäß § 305 Abs. 1 Satz 1 BGB handelt1. Denn man sieht ihnen ja nicht an, dass sie vorformuliert worden sind; sie erwecken vielmehr den Anschein, als seien sie nur für den einzelnen Vertrag entworfen, was den AGB-Charakter beseitigt2. Die Darlegungs- und Beweislast dafür, dass die jeweiligen Vertragsbestim- 75 mungen auch tatsächlich in den Individualvertrag gemäß §§ 145 ff. BGB wirksam einbezogen sind, obliegt dem AGB-Verwender3. Denn er ist es ja, der aus den wirksam einbezogenen AGB-Klauseln auch Rechte/Vorteile für sich ableitet4. Die AGB müssen eben Vertragsbestandteil werden; die Sondernorm des § 305 Abs. 2 BGB gilt im unternehmerischen Verkehr nach § 310 Abs. 1 BGB nicht. b) Beweiserleichterungen Hat indessen der AGB-Verwender für den bestimmten Vertragstyp eines 76 Software-Erstellungsvertrages typische Klauseln verwendet5, welche auf eine klassische Konfliktsituation eben dieses Vertragstyps zugeschnitten sind, dann spricht eine Vermutung dafür (Rz. 22 ff.), dass es sich um AGBKlauseln handelt, die nicht nur für den einzelnen Vertrag, sondern für eine Mehrfachverwendung vorgesehen sind6. Dieser Gedanke ist für jeden Vertragstyp fruchtbar zu machen. Auch Software-Erstellungsverträge bedingen von ihrer Typizität her einen systematisch ähnlichen, weithin gleichförmigen Aufbau in den Vertragsbestimmungen. Daher ist – indiziell – davon auszugehen, es handelt sich grundsätzlich im Rahmen einer gegebenen Typizität um AGB-Klauseln nach § 305 Abs. 1 Satz 1 BGB. Es ist dann Sache des AGB-Verwenders, den Nachweis zu führen, dass diese Vermutung nicht zutrifft, dass insbesondere die jeweilige streitbefangene Vertragsbestimmung – trotz ihrer Typizität – nur für den Einzelfall formuliert wurde. c) Nachweis des Individualvertrages Hat der Auftragnehmer oder auch der Auftraggeber den Nachweis geführt, 77 dass es sich um AGB-Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB handelt, dann zielt dieser Nachweis darauf ab, in verschiedener Weise die Wirksamkeit 1 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 61; Erman/Roloff, § 305 BGB Rz. 58. 2 BGH v. 13.9.2001 – VII ZR 487/99, NJW-RR 2002, 13. 3 BGH v. 19.5.1994 – VII ZR 26/93, NJW 1994, 2547. 4 Erman/Roloff, § 350 BGB Rz. 59. 5 Hierzu Fischer, FS für Kreft, 2004, S. 33, 49 ff. 6 BGH v. 27.11.2003 – VII ZR 53/03, NJW 2004, 502; BGH v. 14.5.1992 – VII ZR 204/90, NJW 1992, 2160; Palandt/Grüneberg, § 305 BGB Rz. 24.

Graf von Westphalen

1007

J Rz. 78

Leistungsstörungen

der einzelnen Klauseln nach den §§ 305 ff. BGB anzugreifen. Dem kann sich der AGB-Verwender nur durch den Nachweis entziehen, dass die Voraussetzungen des Aushandelns nach § 305 Abs. 1 Satz 3 BGB tatsächlich vorliegen1. Auch insoweit kommt wieder eine Erleichterung der Darlegungs- und Beweislast dem AGB-Verwender zugute: Sind nämlich nachträglich in den vorformulierten Vertragstext maschinen- oder handschriftliche Ergänzungen eingefügt worden, dann sprechen gewichtige Indizien dafür, dass es sich insoweit um eine Individualvereinbarung nach § 305 Abs. 1 Satz 3 BGB handelt2. Damit ist freilich der AGB-Verwender noch nicht am Ziel. Vielmehr bleibt es dem Kunden freigestellt, den Gang des Verhandlungsprozesses im Einzelnen darzulegen, um daraus den Schluss zu ziehen, dass ein Aushandeln tatsächlich nicht vorlag (Rz. 33 ff.). 78 Da in der Praxis der Nachweis einer ausgehandelten Individualvereinbarung i.S.v. § 305 Abs. 1 Satz 3 BGB oft scheitert, wird man beiden Parteien den Rat erteilen müssen, jedenfalls bei größeren Projekten im Rahmen eines Software-Erstellungsvertrages den Gang der einzelnen Vertragsverhandlungen, beginnend mit der Angebotsphase protokollarisch exakt festzuhalten. Das ist zwar mit Zeit und Aufwand verbunden. Aber eine andere Chance, die Voraussetzungen des Individualvertrages nach § 305 Abs. 1 Satz 3 BGB nachzuweisen oder zu widerlegen, besteht nicht. 79 Dies hängt auch damit zusammen, dass die Rechtsprechung des BGH den Satz trägt, dass vorformulierte Bestätigungsklauseln, wonach der Vertrag im Einzelnen ausgehandelt worden sein soll, ihrerseits an § 309 Nr. 12 Buchst. a BGB scheitern3. Denn diese Klauseln verschieben zum Nachteil des Kunden die Beweisführungslast, was auch im unternehmerischen Verkehr gemäß § 307 Abs. 2 Nr. 1 BGB entsprechend zu berücksichtigen ist4. 80 Die dem AGB-Verwender obliegende Darlegungs- und Beweislast ist insbesondere dann erheblich, wenn das gesamte Vertragswerk oder auch (insbesondere) die neuralgischen Klauseln, die sich auf Sanktionen im Rahmen von Pflichtverletzungen beziehen, unverändert übernommen (Rz. 60 ff.) worden sind5. Denn gerade unter dieser Voraussetzung obliegt dem AGBVerwender der volle Beweis dafür, dass tatsächlich ein Aushandeln i.S.v. § 305 Abs. 1 Satz 3 BGB stattgefunden hat (Rz. 33 ff.). Er muss also dann 1 BGH v. 6.12.2002 – V ZR 220/02, NJW 2003, 1313, 1314; BGH v. 3.4.1998 – V ZR 6/97, NJW 1998, 2600, 2601; Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 62; AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung Rz. 32. 2 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 63; Palandt/Grüneberg, § 305 BGB Rz. 24; Erman/Roloff, § 305 BGB Rz. 20; MünchKomm/Basedow, § 305 BGB Rz. 45. 3 Erman/Roloff, § 305 BGB Rz. 58; AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 34; Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 65. 4 AGB-Klauselwerke/Graf von Westphalen, Individualvereinbarung, Rz. 34. 5 Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 64.

1008

Graf von Westphalen

Rz. 82 J

Individualvereinbarung

den Nachweis führen, dass er dem Auftragnehmer die „reale Möglichkeit“1 eingeräumt hat, durch eine Änderung der Vertragsbedingungen seine eigenen Interessen tatsächlich geltend zu machen2. d) Nachteile für den Kunden des AGB-Verwenders Mit Recht ist darauf aufmerksam gemacht worden3, dass das Grundproblem 81 des Aushandelns nach § 305 Abs. 1 Satz 3 BGB dadurch umschrieben ist: Der Vertragspartner des AGB-Verwenders, der sich auf ein Aushandeln einlässt, verliert dadurch automatisch den Schutz des AGB-Rechts. Geht man davon aus, dass – für gewöhnlich – in einem jeden Vertragsformular unwirksame AGB-Klauseln verwendet werden – dies ist insbesondere bei Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln zu besichtigen –, dann ist für den aushandlungswilligen Vertragspartner damit ein eklatanter wirtschaftlicher und kommerzieller Nachteil verbunden. Dies hat zu der Frage geführt, ob in diesen Fällen nicht der Kunde sich auch darüber im Klaren sein müsste, dass er durch die Annahme des Verhandlungsangebots seinen Schutzstandard erheblich verringert, was ein entsprechendes Belehren voraussetze4. Selbst wenn man diese beim Aushandeln regelmäßig vorhandenen Nachteile für den Kunden zum Nennwert nimmt, wird man – jedenfalls im unternehmerischen Bereich – weder eine entsprechende Belehrung des AGB-Verwenders fordern müssen, noch wird man darauf abheben dürfen, ob denn in der Tat ein entsprechendes Rechtsbewusstsein beim Kunden vorlag, seine Rechtsposition aufgrund des Aushandelns zu verschlechtern. Vielmehr reicht es aus, wenn der AGB-Verwender die hier im Einzelnen dargelegten Voraussetzungen für ein Aushandeln nach § 305 Abs. 1 Satz 3 BGB beachtet (Rz. 33). Tut er dies, dann liegt es in der autonomen Entscheidung des Kunden, ob er 82 bereit ist, seine eigenen wirtschaftlichen Interessen zu verfolgen, indem er auf die einzelne Vertragsbestimmung tatsächlich Einfluss nimmt. Verweigert sich der Kunde einem entsprechenden Angebot des AGB-Verwenders, dann greift hier – wie im Einzelnen zuvor dargelegt (Rz. 57) – der Grundsatz von § 311 Abs. 2 BGB ein: Der AGB-Verwender hat nämlich ein legitimes Interesse daran, der Schadensersatzsanktion nach § 311 Abs. 2 BGB wegen der Verwendung unwirksamer Klauseln zu entfliehen5, indem er den „gesetzesfremden Kerngehalt“ der betreffenden AGB-Klausel ernsthaft zur Disposition des Kunden stellt6 oder doch dem anderen Teil die Möglichkeit eröffnet, auf die Vertragsgestaltung Einfluss zu nehmen. 1 2 3 4

BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). I.E. Graf von Westphalen, ZIP 2010, 1110 ff. Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 58. BGH v. 19.5.2005 – III ZR 437/04, NJW 2005, 2543 – Partnerschaftsvermittlungsvertrag. 5 Hierzu i.E. auch Fuchs, in: Ulmer/Brandner/Hensen, vor § 307 BGB Rz. 104 m.w.N. 6 BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111).

Graf von Westphalen

1009

K. Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln Rz. I. Beschaffenheitsgarantien gemäß §§ 444, 639 BGB – Individualvertragliche Schranken . . . 1. Vorliegen einer Beschaffenheitsgarantie . . . . . . . . . . . . . . . . . 2. Abgrenzung gegenüber einer Beschaffenheitsvereinbarung . . 3. Auslegung – Indizien . . . . . . . . . 4. Reichweite der Garantieübernahme . . . . . . . . . . . . . . . . . . . . . . 5. Ausdrückliche – stillschweigende Garantieübernahme . . . . 6. Haftungsfreizeichnung – Haftungsbegrenzung . . . . . . . . . . . . . a) Individualvertragliche Vereinbarung . . . . . . . . . . . . . . . . . b) Praktische Schlussfolgerung c) AGB-Klauseln . . . . . . . . . . . . . II. Auftraggeber als AGB-Verwender . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Höherqualifizierung einer Beschaffenheitsvereinbarung . . . . a) Verschuldensunabhängige Haftung . . . . . . . . . . . . . . . . . . . b) Verfügbarkeitsgarantien . . . . 2. Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln . III. Auftragnehmer als AGB-Verwender . . . . . . . . . . . . . . . . . . . . . . 1. Verletzung von Leben, Körper oder Gesundheit . . . . . . . . . . . . . a) Ausgangspunkt . . . . . . . . . . . . b) Vertrag mit Schutzwirkung zugunsten Dritter . . . . . . . . . . c) Haftpflichtversicherungsschutz . . . . . . . . . . . . . . . . . . . . 2. Vorsatz und grobe Fahrlässigkeit – § 309 Nr. 7b BGB . . . . . . . a) Tatbestand des groben Verschuldens . . . . . . . . . . . . . . . . .

Rz.

2 2 3. 4 8 10 12 13 13 15 16 18 19 19 23

4. 5.

25 27 28 28 29 33 34

6. 7.

b) Subunternehmer: Erfüllungsgehilfe – Kauf- oder Werkvertrag . . . . . . . . . . . . . . . c) Begrenzung: Vorhersehbarer Schaden . . . . . . . . . . . . . . . . . . . Haftungsfreizeichnung – Fahrlässige Pflichtverletzung . . . . . . a) Schuldhafte Verletzung einer wesentlichen Vertragspflicht . . . . . . . . . . . . . . . . . . . . aa) Voraussetzungen von § 307 Abs. 2 Nr. 2 BGB . . bb) Notwendigkeit einer transparenten Vertragsgestaltung? . . . . . . . . . . . . . cc) Versuch einer Konkretisierung . . . . . . . . . . . . . . . . (1) Hauptpflichten . . . . . . (2) Nebenpflichten . . . . . . dd) Verschulden bei Vertragsabschluss . . . . . . . . . . Rechtsfolgen: Schadensersatz – § 280 BGB . . . . . . . . . . . . . . . . . . . Rechtsfolge: Schadensersatz statt der Leistung – Rücktritt . . a) Ausgangspunkt . . . . . . . . . . . . b) Eigene Auffassung. . . . . . . . . . c) Berücksichtigung der Interessen bei einem Softwareerstellungsvertrag . . . . . . . . . . Haftungsbegrenzungsklauseln . Zentrale Frage: Umfassende Haftungsbegrenzung („Cap“) . . a) Anspruchsspezifische Enumeration der Haftungsbegrenzung . . . . . . . . . . . . . . . . b) Umfassende Klausel . . . . . . . .

36 38 39

39 41

44 45 45 48 49 50 53 53 55

57 59 60

61 62

IV. Sanktionen für unwirksame Klauseln . . . . . . . . . . . . . . . . . . . . . 66

35

Wegen der besonderen Risikoträchtigkeit von Softwareerstellungsverträgen ist die Frage von entscheidender Bedeutung, ob und unter welchen Voraussetzungen es dem Auftragnehmer möglich ist, die Schadensersatzhaftung Graf von Westphalen

1011

1

K Rz. 2

Leistungsstörungen

für etwaige Pflichtverletzungen auszuschließen oder zu begrenzen. Gegenläufig ist naturgemäß das Interesse des Auftraggebers, im Fall von Pflichtverletzungen des Auftragnehmers möglichst weitreichende Haftungen vertraglich sich auszubedingen. Diese unterschiedliche Interessenlage gebietet es, folgende Differenzierungen anzubringen: Zunächst sind die Fragen zu erörtern, die mit der Vereinbarung von Beschaffenheitsgarantien i.S.d. §§ 444, 639 BGB zusammenhängen (sub. I, Rz. 2 ff.), weil insoweit auch individualvertragliche Schranken zu beachten sind. Sodann ist danach zu differenzieren, ob es sich um Vertragsbedingungen handelt, die der Auftraggeber – sozusagen als Einkaufs-AGB – vorformuliert und damit i.S.v. § 305 Abs. 1 Satz 1 BGB gestellt hat (sub. II, Rz. 18 ff.). Schließlich ist der Frage Raum zu geben, welche inhaltlichen Wirksamkeitsgrenzen dann zu beachten sind, wenn der Auftraggeber in der Lage war, seine eigenen Vertragsbedingungen gegenüber dem Auftraggeber durchzusetzen (sub III, Rz. 27 ff.).

I. Beschaffenheitsgarantien gemäß §§ 444, 639 BGB – Individualvertragliche Schranken 1. Vorliegen einer Beschaffenheitsgarantie 2

Neben dem Fall der hier nicht im Einzelnen erörterten Arglisthaftung enthalten die §§ 444, 639 BGB praktisch identische Textfassungen. Denn in beiden Normen geht es darum, ob der Auftragnehmer die Garantie für die Beschaffenheit der Sache bzw. des Werks übernommen hat. Ob dies zutrifft, ist unabhängig davon, ob der zugrunde liegende Softwareerstellungsvertrag als Kaufvertrag i.S.v. § 651 BGB oder als Werkvertrag nach §§ 631 ff. BGB einzuordnen ist. Ausgangspunkt für die nachstehend anzustellenden Erwägungen ist in beiden Fällen das BGH-Urteil vom 29.11.20061. Es befasst sich mit der Frage, unter welchen Voraussetzungen eine Beschaffenheitsgarantie i.S.v. § 444 BGB bejaht werden kann, wenn es – wie in dem entschiedenen Fall – darum ging, dass der Verkäufer eine bestimmte Laufleistung eines Motorrads beim Kauf im Internet angegeben hatte. Der BGH geht davon aus, dass immer dann von einer Beschaffenheitsgarantie zu reden ist, wenn die Voraussetzungen einer Zusicherungshaftung nach § 459 Abs. 2 BGB a.F. bejaht werden können2. Danach ist es erforderlich, dass der Verkäufer in vertragsgemäß bindender Weise die Gewähr für das Vorhandensein der vereinbarten Beschaffenheit der Kaufsache übernimmt und gleichzeitig seine Bereitschaft damit zu erkennen gibt, für alle Folgen des Fehlens dieser Beschaffenheit – ohne Rücksicht auf ein Verschulden – einstehen zu wollen3. In der Sache knüpft damit der BGH an seine Ausgangs-

1 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 – Motorrad. 2 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad. 3 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad.

1012

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 4

K

entscheidung zu § 463 Satz 1 BGB a.F. an1. Dies entspricht im Übrigen auch dem Willen des Gesetzgebers2. Da der BGH in der Vergangenheit immer wieder die Angabe über die „Laufleistung“ eines Gebrauchtwagens/Motorrads als Eigenschaftszusicherung nach § 463 Satz 1 BGB a.F. behandelt hatte3, ist es nur folgerichtig, wenn der BGH – auch im Kontext von § 444 BGB (und damit auch nach § 639 BGB) – in der Angabe des Gebrauchtwagenhändlers über die Laufleistungen des Fahrzeugs/Motorrads den haftungsbegründenden Tatbestand sieht, dem der Käufer besonderes Vertrauen entgegen bringt, so dass im Ergebnis die Annahme einer Beschaffenheitsgarantie begründet ist. Dabei entspricht es einer alt hergebrachten Judikatur, dass die Frage, ob in der Tat eine – verschuldensunabhängige – Beschaffenheitsgarantie gewollt ist, immer aus der Perspektive des redlichen Erklärungsempfängers nach den §§ 133, 157 BGB zu beantworten ist4. Die Literatur folgt dieser Einschätzung5. Gleichwohl sind verschiedene Differenzierungen erforderlich, um die Frage 3 abschließend zu beantworten, unter welchen Voraussetzungen bei Vorliegen einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB auch eine individualvertragliche Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel scheitert. 2. Abgrenzung gegenüber einer Beschaffenheitsvereinbarung Gerade wenn man berücksichtigt, dass eine Garantie in der Regel Teil eine 4 vertragliche Vereinbarung zwischen Auftraggeber und Auftragnehmer ist und dazu führt, auf Grund einer Zusicherung die Rechte des Käufers/Bestellers zu verstärken6, ist es erforderlich, eine markante Grenzziehung gegenüber einer Beschaffenheitsvereinbarung i.S.v. § 434 Abs. 1 Satz 1 BGB bzw. von § 633 Abs. 2 BGB vorzunehmen. Ohne in Details gehen zu wollen7, wird man hier jedenfalls folgende Gesichtspunkte festhalten müssen, die geeignet sind, als Beschaffenheit einer Sache/eines Werks qualifiziert zu

1 BGH v. 29.5.1968 – VIII ZR 77/66, BGHZ 50, 200 (204) – Kleber. 2 BT-Drucks 14/6040, S. 132; vgl. auch Dauner-Lieb/Thiessen, ZIP 2002, 108 (112 ff.); Triebel/Hölzle, BB 2002, 521 (530 f.); Schmidt-Räntsch, AnwBl. 2003, 529 (535). 3 BGH v. 13.5.1998 – VIII ZR 292/97, NJW 1998, 2207; BGH v. 15.2.1984 – VIII ZR 327/82, NJW 1984, 1454; BGH v. 18.2.1981 – VIII ZR 72/80, NJW 1981, 1268. 4 BGH v. 29.5.1968 – VIII ZR 77/66, BGHZ 50, 200 (204) – Kleber. 5 Palandt/Weidenkaff, § 444 BGB Rz. 12; Erman/Grunewald, § 444 BGB Rz. 12; MünchKomm/Westermann, § 444 BGB Rz. 15; Faust, in: Bamberger/Roth, § 443 BGB Rz. 6 ff. 6 BGH v. 17.3.2010 – VIII ZR 253/08, NJW-RR 2010, 1329 (1330) – Kunststoffkorken; Faust, in: Bamberger/Roth, § 443 BGB Rz. 6. 7 Vgl. Erman/Grunewald, § 434 BGB Rz. 3 ff.; Palandt/Weidenkaff, § 434 BGB Rz. 9 ff.

Graf von Westphalen

1013

K Rz. 5

Leistungsstörungen

werden. Erfasst werden davon zunächst alle der Sache anhaftenden Eigenschaften1. Damit wird z.B. auch die Frage beantwortet, ob eine Sache neu oder alt ist, welche Materialien verwendet werden, welche Haltbarkeit vorliegt oder inwieweit Verschleiß als haftungsbegründender Umstand gegeben ist2. 5

Soweit bei einem Softwareerstellungsvertrag bestimmte Funktions- und Leistungsparameter vom Auftragnehmer zu erfüllen sind, stellt sich immer eine oft nicht leicht zu bewältigende Auslegungsfrage. Festzuhalten ist jedoch allemal, dass es sich hierbei grundsätzlich um die Vereinbarung einer Beschaffenheit handelt, weil auf diese Weise der mit dem (Werk-)Vertrag verfolgte Zweck näher umschrieben wird, einschließlich etwa vereinbarter Funktionen3. Es gilt nämlich nach der Rechtsprechung des BGH – jedenfalls für den Bereich des Werkvertragsrechts – ein sog. funktionaler Mängelbegriff4. Das bedeutet: Das Vorliegen eines Mangels entscheidet sich nicht allein nach der Parteivereinbarung, sondern auch danach, welche Funktionen das Werk nach dem Willen der Parteien haben sollte5. Notwendig ist dabei stets, dass die betreffende Beschaffenheit der Sache/des Werks als Bestandteil des Vertrages vereinbart wird. Denn der Leistungsmangel muss zwangsläufig dazu führen, dass der angestrebte Erfolg beeinträchtigt wird6. Eine solche Abrede kann sowohl ausdrücklich7 als auch konkludent geschlossen werden8. Soweit eine ausdrückliche Vereinbarung – bezogen auf eine bestimmte Beschaffenheit der Sache/des Werks – vorliegt, wird sie regelmäßig schriftlich fixiert werden9; doch notwendig ist dies nicht10. Ob hingegen eine stillschweigende Beschaffenheitsvereinbarung vorliegt, kann nur unter Berücksichtigung der allgemeinen Auslegungsgrundsätze nach den §§ 133, 157 BGB entschieden werden, was regelmäßig voraussetzt, dass konkrete Anhaltspunkte vorliegen11. Das Vorliegen einer solchen Abrede

1 2 3 4 5 6 7 8

9 10 11

Erman/Grunewald, § 434 BGB Rz. 2. Palandt/Weidenkaff, § 434 BGB Rz. 10. Erman/Schwenker, § 633 BGB Rz. 10. BGH v. 29.9.2011 – VII ZR 87/11, ZfBR 2012, 30 (31); BGH v. 8.11.2007 – VII ZR 183/05, NJW 2008, 511. BGH v. 8.11.2007 – VII ZR 183/05, NJW 2008, 511 (512); BGH v. 15.10.2002 – X ZR 69/01, NJW 2003, 200 (201). BGH v. 19.1.1995 – VII ZR 131/93, NJW-RR 1995, 472. Erman/Grunewald, § 434 BGB Rz. 13. BGH v. 16.7.2003 – VIII ZR 243/02, NJW 2003, 2824 – Auto „fabrikneu“; BGH v. 18.6.1980 – VIII ZR 185/79, NJW 1980, 2127 – Auto „fabrikneu“; MünchKomm/Westermann, § 434 BGB Rz. 12. Maßgeblichkeit des Prospekts für die von einem Bauträger übernommenen Leistungen: BGH v. 25.10.2007 – VII ZR 205/06, NJW-RR 2008, 258. Zum allgemeinen Problem von Schriftformklauseln vgl. AGB-Klauselwerke/ Graf von Westphalen, Schriftformklausel, Rz. 1 ff. Faust, in: Bamberger/Roth, § 434 BGB Rz. 40.

1014

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 7

K

wird man im Übrigen nur mit großer Zurückhaltung bejahen dürfen, weil die Haftungssanktion nach den §§ 444, 639 BGB sehr erheblich ist1. Es ist das Wesensmerkmal einer Beschaffenheitsgarantie, dass sie sich 6 immer auf eine bestimmt Beschaffenheit/Eigenschaft der Sache/des Werks bezieht. Demzufolge liegt das immer durch Auslegung zu ermittelnde maßgebende Differenzierungsmerkmal gegenüber einer Beschaffenheitsvereinbarung darin, dass i.S.v. § 276 Abs. 1 Satz 1 BGB eine – haftungsbegründende – Garantie übernommen wird, weil sich in der Garantieerklärung eine bestimmte Risikoübernahme verbirgt2. Dabei liegt – haftungserweiternd i.S.v. § 276 Abs. 1 Satz 1 BGB – nur dann eine solche Garantieübernahme tatsächlich vor, wenn die Erklärung derart ist, dass der Auftraggeber redlicherweise aus dieser Erklärung ableiten kann, dass der Auftragnehmer bereit ist, für das Fehlen der betreffenden Beschaffenheit – ohne Rücksicht auf ein Verschulden – haftungsmäßig einzustehen3. Nach der Standardformel der BGH-Judikatur setzt also die Übernahme einer Garantie – oberhalb der Vereinbarung einer Beschaffenheit – voraus, dass der Verkäufer/Werkunternehmer in vertragsgemäß bindender Weise auch die Gewähr für das Vorhandensein der vereinbarten Beschaffenheit übernimmt und gleichzeitig seine Bereitschaft erkennbar wird, für alle nachteiligen Folgen einzustehen, wenn und soweit die Beschaffenheit nicht vorhanden ist4. Immer erstreckt sich daher diese Einstandspflicht – dies ist nämlich garantietypisch – auf die vom Verschulden losgelöste Verpflichtung zum Schadensersatz5. Der entscheidende Befund besteht also bei der Abgrenzung zwischen Ga- 7 rantie und Beschaffenheitsvereinbarung in einer doppelten Feststellung: Zum einen verlangt eine Beschaffenheitsgarantie i.S.d. §§ 444, 639 BGB, dass der Auftragnehmer gegenüber dem Auftraggeber zu erkennen gibt, dass er eine Schadensersatzhaftung für den Fall übernimmt, dass die vereinbarte (Soll-)Beschaffenheit nicht mit der tatsächlichen (Ist)-Beschaffenheit übereinstimmt. Das ist der eine Gesichtspunkt; der andere: Diese Schadensersatzhaftung muss auch noch – anders als in § 437 Nr. 3 BGB oder in § 634 Nr. 4 BGB verankert – vom Verschulden, d.h. vom Vorwurf der Fahrlässigkeit losgelöst sein. Es muss sich – mit anderen Worten formuliert – um eine unbedingte Schadensersatzhaftung handeln, welche der Auftragnehmer aus der Sicht des Auftraggebers begründen will und auch begründet6. Dabei ist nach den §§ 133, 157 BGB immer eine solche Auslegung der Garantieerklä1 BGH v. 17.3.2010 – VIII ZR 253/08, NJW-RR 2010, 1329 (1330) – Kunststoffkorken; BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 – Laufleistung eines Motorrads; BGH v. 13.12.1995 – VIII ZR 328/94, NJW 1996, 836 – Fertigbeton. 2 Palandt/Grüneberg, § 276 BGB Rz. 32. 3 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad; das gilt auch für den gleichen Begriff in § 477 BGB – BGH v. 14.4.2011 – I ZR 133/09, NJW 2011, 2653. 4 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 – Motorrad. 5 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad. 6 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad.

Graf von Westphalen

1015

K Rz. 8

Leistungsstörungen

rung des Auftraggebers erforderlich, welche zu einem Ergebnis führt, das die Interessen beider Parteien gleichgewichtig berücksichtigt1. Deshalb ist stets mit hoher Gründlichkeit und Sorgfalt zu prüfen, ob in der Tat der Auftragnehmer oberhalb einer Beschaffenheitsvereinbarung eine Beschaffenheitsgarantie nach den §§ 444, 639 BGB begründen wollte und auch zum Schutz der Interessen des Auftraggebers begründet hat. 3. Auslegung – Indizien 8

Geht man also davon aus, dass die vertragsgemäß bindende Einstandspflicht des Auftragnehmers für das Vorliegen einer Beschaffenheitsgarantie i.S.d. §§ 444, 639 BGB konstitutiv ist, nämlich für das Vorhandensein der vereinbarten Beschaffenheit schadensersatzrechtlich, ohne Rücksicht auf ein Verschulden einstehen zu wollen2, dann stellt sich im Rahmen der durchzuführenden Auslegung nach den §§ 133, 157 BGB stets die Frage, welche Indizien insoweit maßgebend sein könnten. Festzuhalten ist in einem ersten Schritt, dass die Begründung einer Beschaffenheitsgarantie – wie stets3 – nicht entscheidend davon abhängig ist, welche Verben der Auftragnehmer oder einer seiner Vertreter tatsächlich verwendet, ob er von „zusichern“ oder gar von „garantieren“ spricht4. Indessen sind diese Verben – wie stets bei einer zunächst vom Wortlaut ausgehenden Interpretation5 – allemal ein gewisses Indiz dafür, die Frage näher zu untersuchen, ob nicht in der Tat eine Schadensersatzhaftung oberhalb einer Beschaffenheitsvereinbarung tatsächlich gewollt ist. Andererseits ist aber auch im Auge zu behalten, dass die Verwendung des Verbs „garantieren“ in vielen Fällen gleichbedeutend ist mit dem umgangssprachlich nicht sonderlich beliebten Wort des „gewährleisten“. Sieht man die Dinge in diesem Zusammenhang, so deutet zunächst diese Feststellung darauf hin, dass die vom Auftragnehmer begründete schadensersatzrechtliche Einstandspflicht in diesen Fällen lediglich den gesetzlichen Rahmen der §§ 437 Nr. 3 BGB bzw. § 634 Nr. 4 BGB entspricht, also eine verschuldensabhängige Haftung verkörpert.

9

Mithin muss das Ergebnis der Auslegung nach den §§ 133, 157 BGB, sofern in der Tat das Vorliegen einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB bejaht werden soll darauf abzielen, ob der Auftragnehmer eine Erklärung – bezogen auf eine Beschaffenheit der Sache/des Werks – abgegeben hat, welche gleichzeitig die Übernahme eines bestimmten Schadensersatzrisikos zum Gegenstand hat6. Wägt man also die für die Auslegung jeweils 1 BGH v. 31.10.1995 – XI ZR 6/95, NJW 1996, 248; Palandt/Ellenberger, § 133 BGB Rz. 18. 2 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346, 1348 – Motorrad. 3 Palandt/Ellenberger, § 133 BGB Rz. 14 m.w.N. 4 Palandt/Weidenkaff, § 443 BGB Rz. 11. 5 BAG v. 15.9.2009 – 9 AZR 757/08, NJW 2010, 394 (396); BGH v. 1.3.2011 – II ZR 16/10, NJW 2011, 1666 (1667). 6 BGH v. 17.3.2010 – VIII ZR 253/08, NJW-RR 2010, 1329 (1330) – Kunststoffkorken; BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad.

1016

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 10 K

heranzuziehenden Indizien, dann liegt sicherlich das Schwergewicht darin, dass eine Beschaffenheitsgarantie gemäß §§ 444, 639 BGB nach dem Zweck des Vertrages1 und unter Beachtung der beiderseitigen Interessen2 stets voraussetzt, dass der Auftragnehmer eine vom Verschulden losgelöste Risikoübernahme begründen wollte, falls die vereinbarte Beschaffenheit der Sache/des Werks nicht vorhanden sein sollte. Mit anderen Worten: Es muss sich – aus der Perspektive des Auftraggebers her beleuchtet – um einen als konstitutiv anzusehenden Vertrauenstatbestand handeln, den der Auftragnehmer gesetzt hat3. 4. Reichweite der Garantieübernahme Gerade wenn man im Kontext der §§ 444, 639 BGB berücksichtigt, dass die 10 Übernahme einer vom Verschulden losgelösten Garantie in § 276 Abs. 1 Satz 1 BGB ihren Sitz hat, dann ergibt sich zwingend eine weitere Differenzierung: Im Hinblick auf die in der jeweiligen Risikoübernahme liegende – verschuldensunabhängige – Schadensersatzhaftung ist nämlich danach zu unterscheiden, welchen Inhalt und Umfang das jeweils übernommene Schadensersatzrisiko des Auftragnehmers zum Gegenstand hatte4. Nach der zu § 463 Satz 1 BGB a.F. entwickelten These stellt sich also die Frage, ob die jeweilige Zusicherungserklärung schadensersatzrechtlich und verschuldensunabhängig das Risiko des Mangelschadens oder auch das des Mangelfolgeschadens zum Gegenstand hat5. Ob an dieser Distinktion weiter festzuhalten ist, könnte deswegen zweifelhaft erscheinen, weil die Differenzierung zwischen einem Mangelschaden und einem Mangelfolgeschaden im Kontext der §§ 437 Nr. 3 BGB bzw. § 634 Nr. 4 BGB obsolet geworden ist; denn die schadensersatzrechtliche Grundnorm des § 280 Abs. 1 Satz 1 BGB dominiert. Die dem Fehlen der (garantierten) Beschaffenheit zugrunde liegende Pflichtverletzung schließt i.S.v. § 280 Abs. 1 Satz 1 BGB notwendigerweise ein, dass alle unmittelbaren oder mittelbaren Nachteile des schädigenden Verhaltens von der Einstandspflicht des Schuldners erfasst werden6. Zur Konsequenz hat dies, dass nur solche Folgeschäden aus dem Anwendungsbereich von § 280 Abs. 1 Satz 1 BGB ausscheiden, welche entweder außerhalb der adäquaten Kausalität oder außerhalb des Schutzzwecks der jeweils verletzten Norm liegen7. Aber gerade auch dann, wenn man die Unterscheidung zwischen Mangelschaden und Mangelfolgeschaden als nicht mehr tragfähig anerkennt, wird man gleichwohl immer im Kontext der Risikoübernahme 1 BGH v. 13.6.2007 – IV ZR 330/05, NJW 2007, 2320 (2322); Palandt/Ellenberger, § 133 BGB Rz. 18. 2 BGH v. 3.4.2000 – II ZR 194/98, NJW 2000, 2099; BGH v. 26.1.1998 – II ZR 243/96, NJW 1998, 1481. 3 BGH v. 29.5.1968 – VIII ZR 77/66, BGHZ 50, 200 (204) – Kleber. 4 Palandt/Grüneberg, § 276 BGB Rz. 32. 5 BGH v. 29.5.1968 – VIII ZR 77/66, BGHZ 50, 200 – Kleber. 6 Palandt/Grüneberg, § 280 BGB Rz. 32. 7 Hierzu Palandt/Grüneberg, vor § 249 BGB Rz. 29 ff.

Graf von Westphalen

1017

K Rz. 11

Leistungsstörungen

nach § 276 Abs. 1 Satz 1 BGB auf das Sorgfältigste prüfen müssen, in welchem Umfang der Auftragnehmer bei Begründung einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB seine Bereitschaft hat erkennen lassen, verschuldensunabhängig für bestimmte Schadensersatzfolgen einzustehen. 11 Dass diese Schadensfolgen bei Fehlen einer Beschaffenheitsgarantie i.S.d. §§ 444, 639 BGB immer auch das Risiko von Produktionsausfall oder entgangenem Gewinn einschließt, bedarf keiner weiteren Begründung. Denn wenn dieses Schadensersatzrisiko bereits Gegenstand der Schadensersatzhaftung des Verkäufers/Werkunternehmers nach den § 437 Nr. 3 BGB bzw. § 634 Nr. 4 BGB ist1, dann leuchtet es unmittelbar ein, dass auch die – verschuldensunabhängige – Haftung für eine Beschaffenheitsgarantie jedenfalls immer in die gleiche Richtung zielt. Der Unterschied ist dann lediglich der: Im Rahmen der kauf- bzw. werkvertraglichen Mängelhaftung besteht eine verschuldensabhängige Schadensersatzhaftung, wie sich aus § 280 Abs. 1 Satz 2 BGB ablesen lässt, während die Schadensersatzhaftung im Rahmen der §§ 444, 639 BGB vom Verschulden losgelöst ist. In praktischer Hinsicht äußert sich diese Unterscheidung vor allem darin, dass die Beschaffenheitsgarantie nach den §§ 444, 639 BGB auch die Haftung für Entwicklungsrisiken einschließt2. Will man hier eine Regel aufstellen, welchen Umfang die verschuldensunabhängige Schadensersatzhaftung nach den §§ 444, 630 BGB für gewöhnlich auslöst, erscheint es – mangels gegenteiliger Anhaltspunkte – naheliegend, insoweit auf das Merkmal der Vorhersehbarkeit abzustellen. Danach fallen alle die schadensersatzrechtlichen Folgen in den Haftungsrahmen der §§ 444, 639 BGB, welche aus der Sicht beider Vertragsparteien üblicherweise dann eintreten und dann vorhersehbar sind, falls die bestimmte, garantierte Beschaffenheit der Sache/des Werkes fehlt. Geht man – wie hier geschehen – davon aus, dass regelmäßig die Schadensposition Produktionsausfall bzw. entgangener Gewinn3 in den Risikobereich einer Beschaffenheitsgarantie fällt, dann kann das Merkmal der Vorhersehbarkeit sich lediglich auf solche Schäden beziehen, die an anderen Rechtsgütern des Auftraggebers aufgrund des Fehlens der Beschaffenheitsgarantie entstehen. 5. Ausdrückliche – stillschweigende Garantieübernahme 12 Nach der Rechtsprechung des BGH4 ist zu bedenken, dass die Annahme einer ausdrücklichen Beschaffenheitsgarantie nach den §§ 444, 639 BGB die Regel darstellt, weil der BGH die Auffassung vertritt, bei der Bejahung einer nur stillschweigend erklärten Beschaffenheitsgarantie sei Zurückhaltung erforderlich. Dem wird man durchaus zustimmen dürfen, weil ja – wie dar1 BGH v. 19.6.2009 – V ZR 93/08, NJW 2009, 2674 – Hauskauf; Palandt/Weidenkaff, § 437 BGB Rz. 35. 2 BGH v. 5.7.1972 – VIII ZR 74/71, BB 1972, 1069 – Fensterlack. 3 BGH v. 19.6.2009 – V ZR 93/08, NJW 2009, 2674 – Hauskauf. 4 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346, 1348 – Motorrad.

1018

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 14 K

gestellt – die schadensersatzrechtlichen Haftungsfolgen sehr erheblich sind, zumal sie losgelöst von einem Verschulden des Auftragnehmers eintreten. Gleichwohl ist zu berücksichtigen, dass die frühere Judikatur des BGH teilweise eine sehr weitreichende Garantiehaftung aufgrund einer stillschweigenden Erklärung angenommen hat1 und auch werbemäßige Erklärungen ausreichend sein ließ, um eine Zusicherungshaftung zu bejahen2. 6. Haftungsfreizeichnung – Haftungsbegrenzung a) Individualvertragliche Vereinbarung Gelangt man unter Berücksichtigung der §§ 133, 157 BGB zu dem Resultat, 13 dass in der Tat eine Beschaffenheitsgarantie nach den §§ 444, 639 BGB vorliegt, dann ist die Sanktion – gerichtet auf Ersatz des entstandenen Schadens – vorgezeichnet: Soweit die jeweils durch Auslegung zu ermittelnde Risikoübernahme im Rahmen der Beschaffenheitsgarantie nach den §§ 444, 639 BGB festgestellt werden kann, scheitert eine Haftungsfreizeichnung. Der Gesetzgeber stellt dies dadurch klar, dass er in beiden Normen das Wort „soweit“ vorsieht. Wenn also eine unbedingte Einstandspflicht im Rahmen einer Beschaffenheitsgarantie begründet worden ist, dann hängt das Scheitern der Haftungsfreizeichnung auf das Engste mit dem Verbot des widersprüchlichen Verhaltens i.S.v. § 242 BGB zusammen3. Soweit also der Auftragnehmer regelmäßig auf individualvertraglicher Ebene eine Beschaffenheitsgarantie nach den §§ 444, 639 BGB begründet hat, darf die darin liegende Risikoübernahme nicht durch eine gegenläufige Haftungsfreizeichnung ihres Wesensgehalts beraubt werden4. Denn zugrunde liegt ja das schutzwürdige Vertrauen des Auftraggebers5. Daraus folgt, dass eine Haftungsfreizeichnung gegenüber den Haftungsrisiken, die sich bei Vereinbarung einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB ergeben, in wirksamer Weise auch auf der Ebene eines Individualvertrages nicht vereinbart werden kann. Denn dann wäre die Garantie ohne Inhalt; das Vertrauen des Auftraggebers hängt in der Luft. Mithin bleibt lediglich die praktische Möglichkeit, bei Vorliegen einer Be- 14 schaffenheitsgarantie nach den §§ 444, 639 BGB eine Haftungsbegrenzungsklausel zu vereinbaren. Diese ist jedoch nur dann i.S.d. §§ 444, 639 BGB wirksam, wenn sie sich in transparenter Weise auf die konkrete Risikoübernahme bezieht, welche Gegenstand der Beschaffenheitsgarantie des Auftragnehmers war6. Mit anderen Worten: Soweit der Auftraggeber der 1 BGH v. 5.7.1972 – VIII ZR 74/71, BB 1972, 1069 – Fensterlack. 2 BGH v. 21.6.1967 – VIII ZR 26/65, BGHZ 48, 118 – TREVIRA. 3 Erman/Grunewald, § 444 BGB Rz. 12; MünchKomm/Westermann, § 444 BGB Rz. 15. 4 Palandt/Weidenkaff, § 444 BGB Rz. 14. 5 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad. 6 Im Einzelnen Graf von Westphalen, KSzW 2010, 164 (165); Graf von Westphalen, Festschrift Röhricht, Köln 2005, S. 675 (682 ff.).

Graf von Westphalen

1019

K Rz. 15

Leistungsstörungen

verschuldensunabhängigen Risikoübernahme des Auftragnehmers Vertrauen entgegenbringt, dass die Beschaffenheitsgarantie tatsächlich eingehalten wird und kein oder nur ein begrenztes Risiko verbleibt, ist die Haftungsbegrenzung nur dann wirksam, wenn sie punktgenau das betreffende, konkrete Schadensersatzrisiko eingrenzt. Daher ist eine klare, transparente und eindeutige Verbindung zwischen der Garantieübernahme einerseits und der Haftungsbegrenzung andererseits vorzusehen. Denn nur so wird das der Garantie entgegengebrachte Vertrauen des Auftraggebers in redlicher Weise begrenzt. Anders gewendet und schärfer formuliert: Der geschädigte Auftraggeber muss exakt wissen, dass er bei Verletzung der betreffenden Beschaffenheitsgarantie i.S.d. §§ 444, 639 BGB nur summenmäßig begrenzt haftet. Alle Auslegungszweifel gehen hier zu Lasten des Auftragnehmers, der es ja in der Hand hat, den Risikogehalt seiner Beschaffenheitsgarantie im Einzelnen zu fixieren. b) Praktische Schlussfolgerung 15 Soweit also bei einem Softwareerstellungsvertrag Beschaffenheitsgarantien i.S.d. §§ 444, 639 BGB gegeben werden, kann eine – individualvertragliche – Haftungsbegrenzung auf zweierlei Weise – rein technisch gesehen – wirksam vereinbart werden: Vorzuziehen ist die Vertragsgestaltung, dass die Haftungsbegrenzung in unmittelbarer räumlicher Nähe zu der jeweiligen Beschaffenheitsgarantie i.S.d. §§ 444, 639 BGB verankert wird. Dann weiß der Auftraggeber, dass die aus der Beschaffenheitsgarantie resultierende Schadensersatzhaftung von vorneherein summenmäßig begrenzt ist. Die Kombination von Garantie und Begrenzung der Schadensersatzhaftung springt förmlich ins Auge. Alternativ kann man daran denken, die sich aus der Verletzung einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB ergebende Schadensersatzhaftung in einem „cap“ – bezogen auf alle Haftungstatbestände – zu erfassen (Rz. 62 ff.). Das muss dann allerdings durch einen klaren Verweis auf die betreffende vertragliche Regelung sichergestellt werden. Wenn nämlich in einem solchen „cap“ alle vertraglichen und gesetzlichen Haftungen des Auftragnehmers gegenüber dem Auftraggeber erfasst werden, die das Ergebnis der dem Auftragnehmer zuzurechnenden Pflichtverletzungen sind, dann kann dort auch eine wirksame Haftungsbegrenzungsklausel im Kontext der §§ 444, 639 BGB in wirksamer Weise verankert werden. Denn auch in diesem Fall weiß der Auftraggeber exakt, in welchem Maß sein Vertrauen in den Bestand der Beschaffenheitsgarantie geschützt ist. c) AGB-Klauseln 16 Es bedarf kaum einer weiteren Begründung, dass exakt die gleichen Wirksamkeitsgrenzen dann eingreifen, wenn die aus der Verletzung von Beschaffenheitsgarantien gemäß §§ 444, 639 BGB resultierenden Schadensersatzansprüche durch Formularklauseln ausgeschlossen oder begrenzt werden sollen. Dies ergibt sich aufgrund von zwei aufeinanderfolgenden Erwägun1020

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 18 K

gen: Zum einen ist darauf aufmerksam zu machen, dass jedwede Beschaffenheitsgarantie individualvertraglichen Charakter besitzt. Sie ist ja immer Gegenstand der zugrunde liegenden Vertragsbeziehung, welche notwendigerweise den Charakter eines Individualvertrages insoweit hat, als ja die Gewährung einer Beschaffenheitsgarantie immer Gegenstand des Leistungsversprechens des Auftragnehmers ist. Zur Konsequenz hat dies, dass sie gemäß § 305b BGB Vorrang gegenüber einer etwaigen, entgegenstehenden Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel besitzt. Soweit also die individualvertraglich begründete Risiko- und Haftungsübernahme nach den §§ 444, 639 BGB reicht (Rz. 10), ist die entgegenstehende Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel wegen des Vorrangprinzips der Individualabrede nach § 305b BGB zu verwerfen. Zum anderen ist zu unterstreichen, dass der in den §§ 444, 639 BGB enthaltene Verbotstatbestand zwangsläufig im Rahmen von § 307 Abs. 2 Nr. 1 BGB seine Resonanz findet. Dieser Ansatz ist mit einem einfachen Erst-Recht-Argument zu verfestigen: Wenn schon im Rahmen einer individualvertraglichen Abrede die aus der Verletzung einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB resultierende Schadensersatzhaftung nicht wirksam abbedungen oder begrenzt werden kann, dann gilt dies erst recht dann, wenn AGB-Klauseln i.S.v. § 305 Abs. 1 Satz 1 BGB einseitig gestellt, d.h. verwendet werden. Es ist nämlich ausgeschlossen, dass die insoweit nach § 307 Abs. 2 Nr. 1 BGB zu beachtenden Wirksamkeitsgrenzen anders verlaufen können als diejenigen, die sich unmittelbar aus der Anwendung der für eine Beschaffenheitsgarantie geschaffenen Normen der §§ 444, 639 BGB reichen. Des Weiteren besteht kein Zweifel daran, dass die richterliche Inhaltskon- 17 trolle nach § 307 Abs. 2 Nr. 1 BGB zum Zuge gelangt, sofern der Auftragnehmer/AGB-Verwender den Versuch unternehmen sollte, trotz Vorliegens einer Beschaffenheitsgarantie nach den §§ 444, 639 BGB die im Verletzungsfall eingreifende Schadensersatzsanktion vom Vorliegen eines Verschuldens abhängig zu machen. Denn es gehört zum konstitutiven Wesenselement einer Beschaffenheitsgarantie, dass sie – wie dargelegt (Rz. 5 f.) – vom Verschulden losgelöst ist1.

II. Auftraggeber als AGB-Verwender Immer dann, wenn der Auftraggeber bei Durchführung eines Softwareer- 18 stellungsvertrags die marktstarke Partei ist, liegt es nahe, dass in einem solchen Fall – wie allgemein bei Einkaufs-AGB – keine Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln verwendet werden. Denn der Auftraggeber hat in diesen Fällen immer ein vitales Interesse daran, dass – mindestens – die gesetzlichen Haftungssanktionen, einschließlich der nur nach den gesetzlichen Bestimmungen limitierten Schadensersatzhaftung des Auftragnehmers eingreifen. Dort finden sich gleichwohl verschiedene 1 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348) – Motorrad.

Graf von Westphalen

1021

K Rz. 19

Leistungsstörungen

Klauselvarianten, die unter der Perspektive von § 307 Abs. 2 Nr. 1 BGB zu prüfen sind. 1. Höherqualifizierung einer Beschaffenheitsvereinbarung a) Verschuldensunabhängige Haftung 19 In der Praxis kommt es immer wieder vor, dass die Einkaufs-AGB des Auftraggebers dadurch charakterisiert sind, dass sie die Haftungsvoraussetzungen – entgegen der gesetzlichen Wertung – zum Nachteil des Auftragnehmers verschärfen. Das geschieht vor allem in der Weise, dass bei Vorliegen einer Beschaffenheitsvereinbarung gemäß §§ 434 Abs. 1, 633 Abs. 2 BGB eine vom Verschulden losgelöste Garantiehaftung des Auftragnehmers begründet wird. So werden bestimmte technische Spezifikationen, Leistungsarten etc. nicht nur „vereinbart“, sondern unbedingt „garantiert“. Damit strebt der Auftragnehmer an, eine zum Nachteil des Auftragnehmers ausschlagende Verschärfung der Schadensersatzhaftung nach den §§ 437 Nr. 3, 634 Nr. 4 BGB zu erreichen. Denn bei Verletzung einer Beschaffenheitsvereinbarung haftet der Auftragnehmer auf Schadensersatz, insbesondere auch für entgangenen Gewinn1, nur im Fall des Verschuldens, wie sich aus der Verweisung auf die generelle Schadensersatznorm des § 280 Abs. 1 Satz 2 BGB unmittelbar ergibt. 20 Wenn aber nunmehr formularmäßig eine verschuldensunabhängige Garantie bei der Verletzung von technischen Spezifikationen, Leistungsdaten etc. der zu erstellenden Software vom Auftragnehmer eingefordert wird, dann ergeben sich daraus zwei zu bewältigende Fragenkreise: An erster Stelle ist die Frage zu beantworten, ob die formularmäßig verlangte, verschuldensunabhängige „Garantie“ weiterhin eine Beschaffenheitsvereinbarung i.S.d. §§ 434 Abs. 1, 633 Abs. 2 BGB ist oder ob in ihr eine weitergehende, über das Gesetz hinausreichende Haftungssanktion vorliegt. Unter Berücksichtigung der jeweiligen individualvertraglichen Erklärungen ist dies durch Anwendung der allgemeinen Auslegungskriterien der §§ 133, 157 BGB zu lösen (Rz. 8 ff.). Gelangt man auf dieser Ebene zu dem Resultat, dass es sich in Wirklichkeit „nur“ um eine Beschaffenheitsvereinbarung handelt, dann ist bereits die verschuldensunabhängige Haftung des Auftragnehmers mit dem Vorrangprinzip des Individualvertrages nach § 305b BGB nicht vereinbar. Sie widerstreitet aber auch dem allgemeinen Haftungsprinzip, wonach der Auftragnehmer – gleichgültig, ob er die Funktion des Verkäufers oder die des Werkunternehmers einnimmt – für Pflichtverletzungen nur verschuldensabhängig auf Schadensersatz haftet2. Darin liegt nach Auffassung des BGH ein wesentliches Grundprinzip des deutsch-rechtlichen Schadensersatzrechts3.

1 BGH v. 19.6.2009 – V ZR 93/08, NJW 2009, 2674 – Hauskauf. 2 BGH v. 5.10.2005 – VIII ZR 16/05, NJW 2006, 47. 3 BGH v. 5.10.2005 – VIII ZR 16/05, NJW 2006, 47.

1022

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 23 K

Wenn nunmehr der Auftraggeber/AGB-Verwender eine vom Verschulden 21 losgelöste Haftung – entgegen dem individualvertraglich erzielten Auslegungsergebnis – formularmäßig einfordert, dann verstößt dies aber auch in eklatanter Weise gegen § 307 Abs. 2 Nr. 1 BGB. Denn damit weicht der Auftraggeber zum Nachteil des Auftragnehmers von den Grundwertungen des dispositiven Rechts ab: Die Klausel ist dann unwirksam. Unter Berücksichtigung der Sanktionsfolge des § 306 Abs. 2 BGB verbleibt es daher bei dem gesetzlichem Haftungsregime. Im Ergebnis besagt also das AGB-rechtliche Verbot der Höherqualifizierung, dass es mit § 307 Abs. 2 Nr. 1 BGB unvereinbar ist, wenn der Auftraggeber/AGB-Verwender schärfere, dem Auftragnehmer nachteilige Haftungsvoraussetzungen in seinen Klauseln vorsieht, als dies dem gesetzlichen Typenbild entspricht1. Nichts anderes i.S.v. § 307 Abs. 2 Nr. 1 BGB gilt jedoch dann, wenn der Auf- 22 traggeber/AGB-Verwender die aus der Verletzung einer Beschaffenheitsvereinbarung gemäß §§ 437 Nr. 3, 634 Nr. 4 BGB resultierende Schadensersatzhaftung des Auftragnehmers vom Nachweis des fehlenden Verschuldens i.S.v. § 280 Abs. 1 Satz 2 BGB entkoppelt. Denn es benachteiligt naturgemäß die Interessen des Auftragnehmers, wenn er nicht berechtigt ist, trotz Vorliegens seiner – objektiv einzuordnenden – Pflichtverletzungen den Nachweis fehlenden Verschuldens i.S.v. § 280 Abs. 1 Satz 2 BGB zu führen, um auf diese Weise die Schadensersatzsanktion zugunsten des Auftraggebers zu vermeiden. Rein praktisch unterscheidet sich diese Konstellation in nichts von derjenigen, dass bei Vorliegen einer Beschaffenheitsvereinbarung formularmäßig eine Garantie/Zusicherung einer bestimmten Beschaffenheit/Eigenschaft eingefordert wird. Denn in beiden Fällen sind damit die Haftungsvoraussetzungen gegenüber der gesetzlichen Normallage verschärft, so dass zugunsten des Auftragnehmers § 307 Abs. 2 Nr. 1 BGB eingreift. b) Verfügbarkeitsgarantien Nichts anderes gilt dann, wenn und soweit – wie bei Softwareerstellungs- 23 verträgen durchaus häufig – Verfügbarkeitsgarantien vom Auftragnehmer verlangt werden. Danach soll der Auftragnehmer gewährleisten, dass die Software während eines bestimmten Zeitraums immer – bis auf festgelegte Grenzen – für den Auftraggeber voll im Einsatz ist, was auch bei Wartungsverträgen entsprechend vereinbart wird2. Soweit diese innerhalb vertraglich spezifizierter Parameter vereinbart werden, gilt zunächst der allgemeine Grundsatz, dass das Hauptleistungsversprechen nicht Gegenstand der richterlichen Inhaltskontrolle ist, wie sich aus § 307 Abs. 3 Satz 1 BGB ablesen lässt. Da solche Verfügbarkeitsgarantien in der Sache aber regelmäßig darauf hinauslaufen, eine bestimmte – garantierte – Nutzungsdauer der Ma1 Christensen, in: Ulmer/Brandner/Hensen, Bes. Vertragstypen, Teil 2 (E) Rz. 5; AGB-Klauselwerke/Graf von Westphalen, Einkaufsbedingungen, Rz. 42. 2 Vgl. OLG Köln v. 31.1.2003 – 19 U 151/02, K&R 2003, 573.

Graf von Westphalen

1023

K Rz. 24

Leistungsstörungen

schine/Anlage etc. zugunsten des Auftraggebers sicherzustellen, bergen sie ein erhebliches Haftungsrisiko1. Gewöhnlich werden sie daher auch individualvertraglich vereinbart. Handelt es sich hierbei um eine Beschaffenheitsgarantie i.S.d. §§ 444, 639 BGB, dann gelten zugunsten des Auftraggebers die gesetzlichen Sanktionen in Form von Schadensersatzansprüchen, um den entstandenen Ausfall der Software zu kompensieren. Sind derartige Verfügbarkeitsgarantien individualvertraglich begründet und damit auch im Einzelnen zwischen den Parteien verhandelt/ausgehandelt2, dann wird man in aller Regel keine rechtlichen Bedenken gegen die Wirksamkeit solcher Abreden herleiten können. 24 Etwas anderes i.S.v. § 307 Abs. 2 Nr. 1 BGB gilt jedoch dann, wenn es sich bei einer solchen Garantiezusage in Wirklichkeit nur um eine Beschaffenheitsvereinbarung i.S.d. §§ 434 Abs. 1, 633 Abs. 2 BGB handelt. Denn dann kommt erneut die Frage auf, ob die dadurch formularmäßig begründete verschuldensunabhängige Schadensersatzhaftung nicht mit § 307 Abs. 2 Nr. 1 BGB in Widerstreit steht, was nach Auffassung des BGH zutrifft3. Ist indessen die Verfügbarkeitsgarantie als Beschaffenheitsgarantie gemäß §§ 444, 639 BGB zu qualifizieren, dann ist sie verschuldensunabhängig4, so dass dann Bedenken i.S.v. § 307 Abs. 2 Nr. 1 BGB nicht angezeigt sind. 2. Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln 25 Enthalten vom Auftraggeber herrührende AGB im Rahmen eines Softwareerstellungsvertrages Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln, wie sie ansonsten „eher“ in den AGB des Auftragnehmers enthalten sind, dann stellt sich unter Berücksichtigung der hier aufgezeigten Judikatur (Kap. J Rz. 18 f.) die Frage, ob insoweit möglicherweise nicht der Auftraggeber, sondern der Auftragnehmer als AGB-Verwender i.S.v. § 305 Abs. 1 Satz 1 BGB anzusehen ist. Dies ist nach der Rechtsprechung des BGH immer dann zu bejahen, wenn und soweit der Auftraggeber im Hinblick auf angebliche branchenmäßige Usancen zugunsten des Auftragnehmers Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln vorgesehen hat5. 26 Trifft dies zu, dann gelten die weiter unten aufgeführten Anmerkungen (Rz. 27 ff.). Voraussetzung für die Anwendung dieser Figur des „Vorauseilenden Gehorsams“ ist es, dass die AGB-Klauseln deswegen verwendet werden, weil widrigenfalls der Vertragspartner nicht bereit sein dürfte, den Ver1 AGB-Klauselwerke/Graf von Westphalen, Einkaufsbedingungen, Rz. 44; Kühnel, BB 1992, 934 ff. 2 Vgl. Palandt/Grüneberg, § 305 BGB Rz. 22; Kap. J Rz. 33 ff. 3 BGH v. 5.10.2005 – VIII ZR 16/05, NJW 2006, 47. 4 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348). 5 BGH v. 9.3.2006 – VII ZR 268/04, NJW-RR 2006, 740 (741); BGH v. 4.3.1997 – X ZR 141/95, NJW 1997, 2043; Ulmer/Habersack, in: Ulmer/Brandner/Hensen, § 305 BGB Rz. 27.

1024

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 29 K

trag abzuschließen, weil er diesen nur unter Berücksichtigung der „üblicherweise“1 verwendeten AGB tut.

III. Auftragnehmer als AGB-Verwender Soweit der Auftragnehmer gegenüber dem Auftraggeber Haftungsbegren- 27 zungs- oder Haftungsfreizeichnungsklauseln verwendet, sind im unternehmerischen Verkehr folgende Wirksamkeitsgrenzen gemäß § 307 BGB zu beachten: 1. Verletzung von Leben, Körper oder Gesundheit a) Ausgangspunkt Der Verbotstatbestand von § 309 Nr. 7a BGB ist von seinem Wortlaut her 28 nur im Verbraucherverkehr anwendbar. Doch immer dann, wenn – im unternehmerischen Verkehr – der Auftragnehmer oder einer seiner Erfüllungsgehilfen (Mitarbeiter/Arbeitnehmer oder Angestellten) den Tod eines Dritten verursacht oder ihm einen Körper- oder Gesundheitsschaden zugefügt hat, stellt sich die Frage, ob dieser Verbotstatbestand nicht doch in Geltung zu setzen ist2. Entscheidend für seine Anwendung ist in diesen Fällen folgende Erwägung: Es stellt sich immer die Frage, ob der Auftraggeber als Geschädigter Unternehmer i.S.v. § 14 BGB oder Verbraucher nach § 13 BGB ist. Ist – selten genug – der geschädigte Auftragnehmer Kaufmann gemäß § 1 HGB, dann stellt sich i.S.v. § 14 BGB die Frage, ob der erlittene Schaden in der Tat bei Abschluss eines Rechtsgeschäfts in Ausübung seiner gewerblichen oder selbständigen beruflichen Tätigkeit sich ereignet hat3. Das ist abhängig von den Umständen des jeweiligen Falles so oder anders zu beantworten. Ist aber der Auftraggeber eine juristische Person, dann steht jedenfalls nach der Rechtsprechung des BGH fest, dass der Geschäftsführer – trotz seiner Stellung als Organ – als Verbraucher nach § 13 BGB einzustufen ist4. In gleicher Weise ist zu entscheiden, wenn der Geschädigte ein beim Auftraggeber beschäftigter Angestellter oder Arbeitnehmer ist. In dieser Perspektive ist der so Geschädigte – im Verhältnis der Vertragsparteien – nämlich lediglich ein Dritter. b) Vertrag mit Schutzwirkung zugunsten Dritter Zur Konsequenz hat diese Einordnung, dass sich die Frage stellt, ob der 29 Geschädigte dann als Verbraucher berechtigt ist, vom Auftragnehmer die 1 2 3 4

BGH v. 4.3.1996 – X ZR 141/95 NJW 1997, 2043. Hierzu AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklauseln, Rz. 30. Hierzu Palandt/Ellenberger, § 14 BGB Rz. 2. BGH v. 8.11.2005 – XI ZR 34/05, NJW 2006, 431; BGH v. 28.6.2000 – VIII ZR 240/99, NJW 2000, 3133.

Graf von Westphalen

1025

K Rz. 30

Leistungsstörungen

Beachtung des Verbotstatbestandes von § 309 Nr. 7a BGB einzufordern. Das wirft die weitere Frage auf, ob denn nicht die zwischen Auftraggeber und Auftragnehmer vereinbarte Haftungsfreizeichnungsklausel – gleiches gilt im Übrigen auch für eine Haftungsbegrenzungsklausel – auch Schutzwirkungen zugunsten der jeweils geschädigten Angestellten/Arbeitnehmern oder sonstigen Mitarbeitern des Auftraggebers entfaltet1. Dabei ist zunächst einzuräumen, dass diese Rechtsfigur regelmäßig den „umgedrehten“ Fall erfasst. Denn der schädigende Dritte beruft sich dann auch auf die von seinem Arbeitgeber gegenüber dem jeweiligen Vertragspartner vereinbarte Freizeichnung, welche dann sich auch auf den Schädiger selbst erstreckt. 30 Hier aber geht es um die Beantwortung der Frage, ob und unter welchen Voraussetzungen der vom Vertragspartner zu beachtende Verbotstatbestand des § 309 Nr. 7a BGB auch dann zugunsten des Geschädigten eingreift, wenn der Schädiger selbst nicht Vertragspartner, sondern ein Dritter ist. Prüft man gleichwohl, ob die Rechtsfigur des Vertrages mit Schutzwirkung zugunsten eines Dritten auch diese Fälle erfassen kann, dann ist zunächst der Ausgangspunkt dieser Konstruktion zu bedenken: Ob ein Vertrag auch Schutzwirkungen zugunsten eines Dritten tatsächlich vorliegt, entscheidet sich immer aufgrund einer nach den §§ 133, 157 BGB vorzunehmenden Vertragsauslegung2. Das wird man in der Regel wohl bejahen dürfen, weil ja feststeht, dass nicht der AGB-Verwender in der Regel selbst etwaige Schädigungen Dritter im Sinn des Verbots von § 309 Nr. 7a BGB verwirklicht. Und man wird auch in gleicher Weise argumentieren dürfen, dass der AGB-Verwender in der Regel nicht seinem Vertragspartner, sondern in erster Linie dessen Angestellten/Arbeitnehmern derartige Schäden zufügt. Es liegt also im Rahmen üblicher Erwartungen, dass Dritte einen Körper- oder Gesundheitsschaden als Folge einer dem AGB-Verwender zuzurechnenden Pflichtverletzung erleiden. 31 Bejaht man also, dass die hier nicht weiter im Einzelnen darzulegenden und zu vertiefenden Voraussetzungen eines Vertrages mit Schutzwirkung zugunsten Dritter vorliegen3, dann erst stellt sich die Frage, ob eine zwischen Auftraggeber und Auftragnehmer vereinbarte – wirksame – Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel auch zu Lasten der geschädigten Dritten (Arbeitnehmer, Angestellte, Mitarbeiter) des Auftraggebers wirkt4. Dogmatisch ist der entscheidende Gesichtspunkt zur Beantwortung dieser Frage in § 334 BGB zu sehen. Danach ist der Schuldner nämlich berechtigt, Einwendungen aus dem Hauptvertrag grundsätzlich auch gegenüber dem Dritten geltend zu machen5. Mehr noch: Soweit im Verhältnis 1 Hierzu Palandt/Grüneberg, § 328 BGB Rz. 15. 2 BGH v. 2.4.1998 – III ZR 245/96, NJW 1998, 1948 (1949). 3 Hierzu im Einzelnen MünchKomm/Gottwald, § 328 BGB Rz. 106 ff.; Erman/ Westermann, vor § 328 BGB Rz. 9 f.; Palandt/Grüneberg, § 328 BGB Rz. 13 ff. 4 Hierzu MünchKomm/Gottwald, § 328 BGB Rz. 132 ff.; Palandt/Grüneberg, § 328 BGB Rz. 20. 5 BGH v. 10.11.1994 – III ZR 50/94, NJW 1995, 392 (393).

1026

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 33 K

der Vertragsparteien eine Haftungsfreizeichnung oder Haftungsbegrenzung wirksam vereinbart ist, kann auch der geschädigte Dritte keine weitergehenden Rechte aus eben diesem Vertrag im Rahmen der zu seinen Gunsten eingreifenden Schutzwirkung ableiten1. Dieses Resultat würde aber auch unter Berücksichtigung des Rechtsgedan- 32 kens von § 334 BGB dem geschädigten Dritten in gleicher Weise zufallen. Denn es treten ihm gegenüber die gleichen Rechtsfolgen ein: Ist die Haftungsfreizeichnung wirksam, verbleibt es auch im Verhältnis zu dem jeweiligen Dritten – sei er Schädiger oder geschädigter Dritter – bei der Feststellung, dass die aus dem Hauptvertrag resultierenden Einwendungen auch für den Dritten eingreifen. Doch kommt bei der Verwendung einer gegen § 309 Nr. 7a BGB gerichteten Klausel der bereits kurz angesprochene Tatbestand hinzu: Wenn nämlich der Auftraggeber eine juristische Person gemäß § 14 BGB ist, dann ist der Verbotstatbestand von § 309 Nr. 7a BGB ihm gegenüber praktisch leerlaufend. Denn die juristische Person handelt durch ihre Organe; diese aber sind – wie dargelegt (Rz. 28) – grundsätzlich als Verbraucher nach § 13 BGB zu qualifizieren. Daher sind auch im unternehmerischen Verkehr etwaige Haftungsfreizeichnungs- oder Haftungsbegrenzungsklauseln, welche gegen den Verbotstatbestand von § 309 Nr. 7a BGB gerichtet sind, zum Schutz der Rechtsgüter Dritter als unwirksam zu qualifizieren. Denn der Geschädigte ist grundsätzlich in diesen Fällen ein Verbraucher. c) Haftpflichtversicherungsschutz Für die Unwirksamkeit einer Haftungsfreizeichnung spricht aber auch un- 33 ter Berücksichtigung von § 307 Abs. 1 Satz 1 BGB ein weiterer Gedanke, der noch später im Einzelnen auseinanderzufalten sein wird: Da der Auftragnehmer als AGB-Verwender ohne weiteres in der Lage ist, sich gegen die Risiken von Personenschäden durch Abschluss einer Haftpflichtversicherung abzusichern, ist es i.S.v. § 307 Abs. 1 Satz 1 BGB unwirksam, wenn eine Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel dem geschädigten Dritten etwaige Ersatzansprüche gegenüber dem Auftragnehmer abschneidet, obwohl insoweit Deckungsschutz im Rahmen der §§ 100 ff. VVG besteht2. Daraus folgt also, dass auch beim Softwareerstellungsvertrag im Verhältnis zwischen Auftragnehmer und Auftraggeber der Verbotstatbestand von § 309 Nr. 7a BGB zu beachten ist. Hilfsweise ist auf den allgemeinen Verbotstatbestand des § 307 Abs. 1 Satz 1 BGB zurückzugreifen.

1 MünchKomm/Gottwald, § 328 BGB Rz. 132. 2 Vgl. auch BGH v. 24.10.2001 – VIII ARZ 1/01, NJW 2002, 673, 675; im Einzelnen auch AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 101 ff.

Graf von Westphalen

1027

K Rz. 34

Leistungsstörungen

2. Vorsatz und grobe Fahrlässigkeit – § 309 Nr. 7b BGB 34 Sofern eine Pflichtverletzung – gleich, welcher Art – auf Vorsatz oder grober Fahrlässigkeit beruht, besteht nach der Rechtsprechung des BGH kein Zweifel daran, dass eine gegen § 309 Nr. 7b BGB verstoßende Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel im unternehmerischen Verkehr an § 307 Abs. 1 Satz 1 BGB scheitert1. Daraus folgt: Der Verbotstatbestand von § 309 Nr. 7b BGB muss bei allen Pflichtverletzungen beachtet werden, die potenziell in einem Softwareerstellungsvertrag sich ereignen können und auf einer vorsätzlichen oder grob fahrlässigen Schädigung beruhen. Da diese einzelnen Tatbestände einer dem Auftragnehmer als AGB-Verwender zuzurechnende Pflichtverletzung weiter unten bei der Erörterung der Wirksamkeitsgrenzen einer Freizeichnungs- oder Haftungsbegrenzungsklausel bei Vorliegen einfacher Fahrlässigkeit näher erläutert werden, sei darauf verwiesen (Rz. 33 ff.). a) Tatbestand des groben Verschuldens 35 Da beim Softwareerstellungsvertrag der Vorwurf einer vorsätzlichen oder arglistigen Schädigung selten sein dürfte2, kommt es aus praktischen Erwägungen heraus entscheidend darauf an, ob im Einzelfall die Tatbestandsvoraussetzungen grober Fahrlässigkeit vorliegen. Nach der gängigen Formel der Judikatur trifft dies dann zu, wenn der Schuldner schon einfachste, ganz naheliegende Überlegungen nicht angestellt hat und nicht das beachtet, was im gegebenen Fall jedem einleuchten musste3. Mit anderen Worten: Bei einem grob fahrlässigen Verhalten muss auch ein subjektiv unentschuldbares Fehlverhalten vorliegen, welches – so der BGH – das gewöhnliche Maß an Fahrlässigkeit ganz erheblich übersteigt4. Ob diese Voraussetzungen im Einzelfall tatsächlich vorliegen, ist immer Gegenstand tatrichterlicher Würdigung; feste Regeln sind nicht anzuerkennen5. b) Subunternehmer: Erfüllungsgehilfe – Kauf- oder Werkvertrag 36 Innerhalb des Verbotstatbestandes von § 309 Nr. 7b BGB ist auch immer ein vorsätzliches bzw. grob fahrlässiges Verhalten des Erfüllungsgehilfen zu bedenken. Dabei gilt i.S.v. § 278 BGB folgende Differenzierung: Ist der zugrunde liegende Softwareerstellungsvertrag ein Werkvertrag gemäß §§ 631 ff. BGB, dann ist auch der Subunternehmer des jeweiligen Auftragnehmers dessen Erfüllungsgehilfe, so dass insoweit eine strikte Haftung nach § 278 1 BGH v. 19.9.2007 – VIII ZR 141/06, NJW 2007, 3774 – „Gleichschritt“. 2 Zu den Elementen des Vorsatzes Palandt/Grüneberg, § 276 Rz. 10f; zur sog. Vorsatztheorie BGH v. 16.7.2002 – X ZR 250/00, NJW 2002, 3255 (3256). 3 BGH v. 13.12.2004 – II ZR 17/03, NJW 2005, 981 (982); BGH v. 5.12.1983 – II ZR 252/82, NJW 1984, 789 (790). 4 BGH v. 11.7.2007 – XII ZR 197/05, NJW 2007, 2988 (2989). 5 BGH v. 11.7.2007 – XII ZR 197/05, NJW 2007, 2988 (2989).

1028

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 38 K

BGB eingreift1. Entscheidend ist insoweit, dass der Subunternehmer im Rahmen der dem Auftragnehmer obliegenden – werkvertraglichen – Verbindlichkeit tätig wird, indem er bei der Erstellung des Werks mitwirkt und so den geschuldeten Erfolg herbeiführen hilft2. Ist hingegen der Softwareerstellungsvertrag i.S.v. § 651 BGB als Kaufvertrag zu qualifizieren, dann spricht vieles dafür, dass der Vorlieferant des Auftragnehmers nicht als Erfüllungsgehilfe nach § 278 BGB einzuordnen ist3. Entscheidend für diese unterschiedliche Einordnung ist zunächst der Be- 37 fund, dass der Verkäufer nach § 433 Abs. 1 Satz 2 BGB lediglich verpflichtet ist, eine mangelfreie Sache zu liefern und dem Käufer Eigentum an ihr zu verschaffen. Im Rahmen dieser kaufvertraglichen Verbindlichkeiten des Verkäufers als Schuldner i.S.v. § 278 BGB wird aber der Vorlieferant nicht tätig4. Dabei geht diese Ansicht davon aus, dass der Vorlieferant selbst nicht bei der Herstellung der Software tätig wird. Dies aber ist unter Berücksichtigung des Wortlauts von § 651 BGB durchaus zweifelhaft5. Denn die Lieferung und eben auch die Herstellung einer vertragsgemäßen Software ist primäre Verpflichtung des Auftragnehmers/Verkäufers. Doch diese Sicht findet auch ihre Gegenstimmen, welche an der kaufvertraglichen Qualifikation im Rahmen des § 651 BGB ebenso festhalten wie daran, dass hier der Subunternehmer eben nicht Erfüllungshilfe des Auftragnehmers ist6. Eine Entscheidung des BGH steht insoweit noch aus. Bis zu ihrem Erlass wird man daher – aus praktischen Gründen – der zuletzt vertretenen Meinung folgen, auch wenn die dogmatisch überzeugenderen Argumente für die erste Auffassung streiten. c) Begrenzung: Vorhersehbarer Schaden Die Beachtung des Verbotstatbestandes gemäß § 309 Nr. 7b BGB gebietet es 38 auch, dass im unternehmerischen Verkehr nicht nur Haftungsfreizeichnungs-, sondern auch alle Haftungsbegrenzungsklauseln nach § 307 Abs. 1 Satz 1 BGB als unwirksam einzuordnen sind. Denn der vom BGH angesprochene „Gleichschritt“ zwischen dem Verbotskatalog von § 309 BGB einerseits und der grundsätzlichen Geltung von § 307 BGB im unternehmerischen Verkehr andererseits gebietet es, dass auch summenmäßige Haftungsbegrenzungen bei Vorliegen eines groben Verschuldens zu beanstan1 BGH v. 15.1.1976 – VII ZR 96/74, NJW 1976, 516; Palandt/Grüneberg, § 278 BGB Rz. 14; MünchKomm/Grundmann, § 278 BGB Rz. 34. 2 Erman/Westermann, § 278 BGB Rz. 31. 3 BGH v. 19.6.2009 – V ZR 93/08, NJW 2009, 2674 (2676) – Hauskauf; BGH v. 15.7.2008 – VIII ZR 211/07, NJW 2008, 2837, 2840 – Parkettstäbe; BGH v. 21.6.1967 – VIII ZR 26/65, NJW 1967, 1903 – TREVIRA. 4 MünchKomm/Grundmann, § 278 BGB Rz. 31; Palandt/Grüneberg, § 278 BGB Rz. 13. 5 Hierzu MünchKomm/Grundmann, § 278 BGB Rz. 31. 6 Palandt/Grüneberg, § 278 BGB Rz. 13; Unberath, in: Bamberger/Roth, § 278 BGB Rz. 28.

Graf von Westphalen

1029

K Rz. 39

Leistungsstörungen

den sind1. Dass allerdings, wie noch zu erwähnen sein wird (Rz. 59), der Auftragnehmer als AGB-Verwender berechtigt ist, auch im Anwendungsbereich von § 309 Nr. 7b BGB die Schadensersatzhaftung auf den vorhersehbaren, typischerweise eintretenden Schaden zu begrenzen, soll in diesem Kontext nicht verschwiegen werden2. Doch ist im gleichen Atemzug hinzuzusetzen, dass der Unterschied des danach zu bestimmenden Umfangs eines Schadensersatzanspruches sich nicht wesentlich von demjenigen unterscheidet, den § 249 BGB vorsieht3. Denn die Grenze der Vorhersehbarkeit ergibt sich regelmäßig dadurch, dass auf den jeweiligen Schutzzweck der verletzten Norm zurückgegriffen wird4. Hierauf stellt im Übrigen auch – bezogen auf alle Schadensersatzansprüche – die Rechtsprechung des BGH ab5, womit eine Begrenzung der adäquaten Kausalität im Hinblick auf die zu ersetzenden Schadensfolgen erreicht wird6. Nicht zu ersetzen sind danach nicht vorhersehbare Exzess-Schäden (Rz. 59). 3. Haftungsfreizeichnung – Fahrlässige Pflichtverletzung a) Schuldhafte Verletzung einer wesentlichen Vertragspflicht 39 Seit Jahrzehnten ist die Rechtsfigur etabliert, dass der AGB-Verwender/Auftragnehmer nicht berechtigt ist, seine Haftung freizuzeichnen, sofern die zugrunde liegende Pflichtverletzung als wesentlich eingeordnet wird7. Inzwischen gibt es praktisch keinen Vertragstyp mehr, bei dem nicht die Rechtsprechung festgestellt hätte, dass bei Verletzung einer wesentlichen Vertragspflicht die Haftungsfreizeichnungsklausel des AGB-Verwenders/ Schuldners nach § 307 Abs. 2 Nr. 2 BGB versagt8. Zwangsläufig bringt diese Einordnung es mit sich, dass weder der Werk- noch der Kaufvertrag – und um diese Vertragstypen geht es bei einem Softwareerstellungsvertrag – insoweit eine Ausnahme bilden9. Deshalb ist es nur folgerichtig10, dass es auch 1 Erman/Roloff, § 309 BGB Rz. 76; Palandt/Grüneberg, § 309 BGB Rz. 45 ff. 2 BGH v. 11.11.1992 – VIII ZR 238/91, NJW 1993, 335, st. Rspr. 3 AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 115 ff. (118). 4 Hierzu Palandt/Grüneberg, vor § 249 BGB Rz. 29 ff. 5 BGH v. 11.1.2005 – X ZR 163/02, NJW 2005, 1420 (1421). 6 BGH v. 20.10.1994 – IX ZR 116/93, NJW 1995, 449 (451). 7 BGH v. 29.1.1968 – II ZR 18/65, BGHZ 49, 356 (363) – Wasserundichte Ladungsluke, durchrostete Schotten; BGH v. 28.6.1971 – II ZR 66/69, VersR 1971, 833; BGH v. 11.3.1974 – II ZR 45/73, VersR 1974, 771 (772 f.) – jeweils falsche Beladung; BGH v. 21.4.1975 – II ZR 164/73, VersR 1975, 1117 (1118); BGH v. 20.3.1978 – II ZR 19/76, VersR 1978, 557; BGH v. 28.2.1983 – II ZR 31/82, VersR 1983, 549 – anfängliche Fahr- und Ladungsuntüchtigkeit des Schiffes. 8 Nachweise in AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 37 f. 9 BGH v. 19.2.1998 – I ZR 233/95, NJW-RR 1998, 1426 (1427) – Bremer Lagerhaus; BGH v. 26.6.1991 – VIII ZR 231/90, ZIP 1991, 1362 (1365) – VDMA-Bedingungen; BGH v. 5.12.1995 – X ZR 14/93, NJW-RR 1996, 783 (788). 10 Neustens BGH v. 18.7.2012 – VIII ZR 337/11, NJW 2013, 291 – Stromlieferung.

1030

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 41 K

bei einem Hard- und Softwarevertrag unwirksam ist, entgegen den Geboten von § 307 Abs. 2 Nr. 2 BGB die Schadensersatzhaftung für die Schlechterfüllung vertraglicher Hauptpflichten auszuschließen1. Daraus folgt zwingend, dass der Auftragnehmer als AGB-Verwender ver- 40 pflichtet ist, gegenüber dem Auftraggeber sicherzustellen, dass in den AGB eine etwa vereinbarte Haftungsfreizeichnungsklausel sich nicht auf die Fälle erstreckt, in denen er schuldhaft eine wesentliche Vertragspflicht verletzt. Das bedeutet konkret: Freizeichnungsklauseln sind in einem Softwareerstellungsvertrag nicht geeignet, die Schadensersatzhaftung des Auftragnehmers wirksam zu verneinen. Folglich eignen sich genau aus diesem Grund AGB-Klauseln nicht als Instrument der Risikobegrenzung2. Es ist daher unbedingt notwendig, die Interessen des Auftragnehmers durch Vereinbarung einer individuell ausgehandelten Haftungsbegrenzungsklausel zu schützen (Kap. J Rz. 33 ff.). aa) Voraussetzungen von § 307 Abs. 2 Nr. 2 BGB Abgesehen von diesen praktischen Erwägungen liegen die besonderen dog- 41 matischen Schwierigkeiten darin, im Einzelnen festzustellen, unter welchen Tatbestandsvoraussetzungen denn nach der Rechtsprechung in der Tat eine wesentliche Vertragspflicht i.S.v. § 307 Abs. 2 Nr. 2 BGB vorliegt, so dass die Haftungsfreizeichnungsklausel im Fall einer schuldhaften Pflichtverletzung unwirksam ist. Die Judikatur des BGH prägt seit langem den Satz, dass jeweils im Einzelfall zu prüfen ist, ob eine Haftungsfreizeichnungsklausel tatsächlich an § 307 Abs. 2 Nr. 2 BGB scheitert, weil sie im Ergebnis die sich aus dem Vertrag ergebenden Rechte und Pflichten des Verwenders so einschränkt, dass die Erreichung des Vertragszwecks gefährdet ist3. Wäre nämlich die Haftungsfreizeichnungsklausel wirksam, dann wäre dies gleichbedeutend mit der Aushöhlung von vertragswesentlichen Rechtspositionen. Denn sie nehmen dem Auftraggeber gerade diejenigen Rechte/ Ansprüche oder schränken sie ein, welche der Vertrag nach seinem Inhalt und Zweck gerade dem Auftraggeber gewähren soll4. Anders gewendet: Es geht um die Befreiung von der Erfüllung solcher Pflichten, welche erst die ordnungsgemäße Erfüllung des Vertrages ermöglichen und auf deren Einhaltung der Vertragspartner – hier: der Auftraggeber – regelmäßig vertraute und auch vertrauen darf. Eine solche Freizeichnung ist mit den Grundwertungen von § 307 Abs. 2 Nr. 2 BGB unvereinbar5.

1 OLG Köln v. 18.8.1997 – 19 U 43/97, NJW-RR 1998, 1274. 2 Im Einzelnen schon Graf von Westphalen, FS für Trinkner, 1996, S. 441 ff. 3 BGH v. 9.11.1989 – IX ZR 269/87, NJW 1990, 761, 764 – Krankenhausvertrag; BGH v. 29.11.1988 – X ZR 112/87, NJW-RR 1989, 953, 955 – Werftarbeiten II; BGH v. 3.3.1988 – X ZR 54/86, ZIP 1988, 515, 518 – Werftarbeiten I. 4 BGH v. 19.2.1998 – I ZR 233/95, NJW-RR 1998, 1426, 1427 – Bremer Lagerhaus; BGH v. 5.12.1995 – X ZR 14/93, NJW-RR 1996, 783 (788) – VDMA. 5 BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2001, 292 (302) – Kfz-Kauf.

Graf von Westphalen

1031

K Rz. 42

Leistungsstörungen

42 Diese dogmatischen Zusammenhänge hat der BGH im Übrigen noch vor einiger Zeit in einer aufsehenerregenden Entscheidung bestätigt1. Doch hat der BGH in diesem Urteil zusätzlich konstatiert, dass die Rechtsfigur der wesentlichen Vertragspflicht nicht als „Kardinalpflicht“ bezeichnet werden darf, weil diese Terminologie – auch im unternehmerischen Verkehr – als intransparent gemäß § 307 Abs. 1 Satz 2 BGB eingestuft werden muss2. Das geht sicherlich sehr weit, ist aber nachfolgend noch gesondert anzusprechen, weil sich ja eine gleich gerichtete Fragestellung auch dann ergibt, wenn der Auftragnehmer als AGB-Verwender anstelle des Begriffs „Kardinalpflicht“ von einer „wesentlichen“ oder einer „vertragswesentlichen Pflicht“ im Kontext einer Freizeichnungsklausel spricht (Rz. 44). 43 In der Literatur wird die Grundaussage des BGH zur Unwirksamkeit von Freizeichnungsklauseln bei schuldhafter Verletzung einer wesentlichen Vertragspflicht unter Auswertung der Tatbestandsmerkmale von § 307 Abs. 2 Nr. 2 BGB als grundsätzlich zutreffend angesehen3. Begreift man indessen den Verbotstatbestand von § 307 Abs. 2 Nr. 2 BGB als notwendige Konkretisierung des allgemeinen Verbotstatbestandes von § 307 Abs. 2 Nr. 1 BGB4, dann wird deutlich, dass das Abstellen auf die „Natur des Vertrages“ sowie auf die damit korrespondierenden „wesentlichen Rechte und Pflichten“, die durch eine Klausel nicht eingeschränkt oder gar aushöhlt werden dürfen, damit der Vertragszweck nicht gefährdet wird, auch unmittelbar an die Normen des dispositiven Rechts anknüpft5. Geschützt werden also die durch den jeweiligen Vertrag geschaffenen zentralen Leistungserwartungen des Kunden/Auftraggebers6. Dies hat die Meinung beflügelt, dass – gerade unter Geltung der Ergebnisse der Schuldrechtsmodernisierung – § 307 Abs. 2 Nr. 2 BGB in Wirklichkeit keine andere Aussage trifft als die, dass die wesentlichen Rechte und Pflichten des AGB-Verwenders im Fall ihrer Pflichtverletzung freizeichnungsfest sind7. Der Vertragszweck ist also auf Erfüllung gerichtet; das ist das prägende Synallagma und gleichzeitig auch Ausweis des Äquivalenzverhältnisses von Leistung und Gegenleistung. Darauf vertraut der jeweilige Vertragspartner des Verwenders; und er wird in diesem Vertrauen auch geschützt. Wird es enttäuscht, dann ist die Kompensation dieses Defizits in Form von Schadensersatz geschuldet (Rz. 50). Eine gegenläufige Haftungsfreizeichnungsklausel ist daher nach § 307 Abs. 2 Nr. 1 BGB unwirksam. 1 BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1505) – Honda. 2 Kritisch mit Recht Kappus, NJW 2006, 15; aber nunmehr BGH v. 18.7.2012 – VIII ZR 337/11, NJW 2013, 291 – Verbrauchergeschäft – Stromlieferung. 3 Erman/Roloff, § 307 BGB Rz. 33; Palandt/Grüneberg, § 307 BGB Rz. 30 ff.; MünchKomm/Wurmnest, § 307 BGB Rz. 72 f. 4 Palandt/Grüneberg, § 307 BGB Rz. 34. 5 Wolf, in: Wolf/Lindacher/Pfeiffer, § 307 BGB Rz. 132 f. 6 Vgl. auch BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2000, 292 (302) – Kaufvertrag. So Erman/Roloff, § 307 BGB Rz. 33. 7 Im Einzelnen: AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 43 ff.; Christensen, in: Ulmer/Brandner/Hensen, § 309 Nr. 7 BGB Rz. 32 ff.

1032

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 45 K

bb) Notwendigkeit einer transparenten Vertragsgestaltung? Im Ergebnis hat der BGH die Frage unbeantwortet gelassen, ob der AGB- 44 Verwender verpflichtet ist, die Vermeidung einer Intransparenz i.S.v. § 307 Abs. 1 Satz 2 BGB bei Freizeichnungsklauseln sicherzustellen, dass die wesentlichen Vertragspflichten im Einzelnen konkretisiert werden1. Dabei geht es in der Sache darum, ob es ausreicht, wenn der Verwender nur von einer „wesentlichen Vertragspflicht“ in seinen AGB spricht, ohne im Einzelnen näher zu beschreiben, was denn darunter zu verstehen ist. Der BGH selbst spricht in seiner Honda-Entscheidung2 davon, dass die Freizeichnungsklausel dem Auftraggeber nicht das nehmen darf, was der Vertrag ihm nach seinem Sinn und Zweck gerade zu gewähren hat. Des Weiteren darf eine Freizeichnungsklausel, wäre sie denn wirksam, nicht dazu führen, dass der Verwender von der Erfüllung solcher Pflichten befreit wird, auf deren Erfüllung der andere Vertragsteil vertraut hat und auch vertrauen durfte3. Würde man in einem Vertrag diese Formel wiederholen, wäre für eine anzustrebende Transparenz der Vertragsgestaltung i.S.v. § 307 Abs. 1 Satz 2 BGB nicht sonderlich viel gewonnen. Doch erscheint es ein wenig gekünstelt, dass der BGH in diesem Zusammenhang die Verwendung des Begriffs „Kardinalpflicht“ als intransparent erklärt4, es aber offenbar als ausreichend ansieht, wenn man stattdessen von der schuldhaften Verletzung einer „wesentlichen Vertragspflicht“ spricht. Denn auch unter diesem Terminus kann sich kaum ein Nichtjurist etwas Konkretes vorstellen. Daher dürfte es sachgerecht sein, die Konkretisierung dieses Begriffs mit den gleichen Worten zu umschreiben, die zuvor aus der Honda-Entscheidung des BGH5 nahezu wortgleich übernommen worden sind6. Das dürfte dann den Anforderungen an eine hinreichende Transparenz genügen. Allerdings ist hierdurch für das weitere Verständnis, was sich denn hinter diesen Formeln im Detail verbirgt, nicht viel für die praktische Anwendung gewonnen. Damit ist der Versuch einer tatbestandlichen Konkretisierung angesagt. cc) Versuch einer Konkretisierung (1) Hauptpflichten Vieles spricht dafür, dass alle diejenigen Pflichten als wesentlich i.S.v. § 307 45 Abs. 2 Nr. 2 BGB von der Rechtsprechung bezeichnet werden, welche im Gegenseitigkeitsverhältnis nach § 320 BGB stehen. Erfasst werden also allemal die vom Auftragnehmer zu erfüllenden Hauptpflichten7. Denn wenn 1 2 3 4 5 6

BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda. BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda. BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda. BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda. BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda. BGH v. 18.7.2012 – VIII ZR 337/11, NJW 2013, 291 – Stromlieferung: Verbraucher; hierzu auch Graf von Westphalen, NJW 2013, 2239 (2242 f.). 7 BGH v. 23.2.1984 – VII ZR 274/82, NJW 1985, 3016 – Veredelung von Textilien; BGH v. 1.2.2005 – X ZR 10/04, NJW 2005, 1774 – Beförderungspflicht eines Bus-

Graf von Westphalen

1033

K Rz. 46

Leistungsstörungen

diese Pflichten schuldhaft nicht erfüllt werden, aber die Wirksamkeit einer Haftungsfreizeichnungsklausel der dann eingreifenden Sanktionsfolge entgegengehalten wird, dann wird regelmäßig i.S.v. § 307 Abs. 2 Nr. 2 BGB auch die Erreichung des Vertragszwecks gefährdet1. Dabei ist es nach dem Wortlaut von § 307 Abs. 2 Nr. 2 BGB nicht erforderlich, dass die zentralen Leistungserwartungen des Kunden/Auftragnehmers2 vereitelt oder überhaupt nicht erreicht werden, weil eine Gefährdung ausreicht. Die Schwelle ist also nicht sehr hoch, wird aber bei der Prüfung einer Haftungsfreizeichnungsklausel in diesen Fällen immer überschritten. Denn denkt man diese Klausel als wirksam, dann ist der Kunde/Auftraggeber praktisch rechtslos gestellt, was auch zu der Auffassung beigetragen hat, dass die zentrale Norm zur Feststellung, ob eine Haftungsfreizeichnungsklausel bei einer schuldhaften Verletzung wesentlicher Vertragspflichten scheitert, nicht in § 307 Abs. 2 Nr. 2 BGB, sondern unmittelbar in der zentraleren Norm von § 307 Abs. 2 Nr. 1 BGB zu sehen ist3. 46 Die zentrale Leistungserwartung des Auftragnehmers ist im Rahmen eines Softwareerstellungsvertrages allemal, dass im Ergebnis die entwickelte und veräußerte Software mangelfrei ist – gleichgültig, ob es sich um einen Kaufvertrag i.S.v. § 433 Abs. 1 Satz 2 BGB oder um einen Werkvertrag nach § 633 Abs. 1 BGB handelt. Immer ist die Freiheit von Sach- und Rechtsmängeln die Rechtsposition, deren Erfüllung als Hauptleistung nicht nur im Gegenseitigkeitsverhältnis steht, sondern auch das Äquivalenzverhältnis von Leistung und Gegenleistung bestimmt. Eingebunden in dieses Pflichtenkonzept ist natürlich auch die Pflicht zur rechtzeitigen Leistungserbringungserbringung, so dass alle Verzugsfolgen – insbesondere auch die Schadensersatzsanktion nach § 280 Abs. 2 BGB – vom Freizeichnungsverbot erfasst werden4. Tritt der Tatbestand der Unmöglichkeit ein, dann gilt nichts anderes5. 47 Dies führt unmittelbar zu der weiteren Feststellung, dass auch das „Fehlschlagen der Nacherfüllung“ in diese Kategorie zu rechnen ist6. Die Norm des § 440 BGB weist dies ebenso aus wie die des § 636 BGB, weil unter der Voraussetzung des „Fehlschlagens der Nacherfüllung“7 das Scheitern der Erfüllung feststeht, zumal ja dann die Rechtsfolge dem Auftraggeber sowohl

1 2 3 4 5 6 7

reiseunternehmers; BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda: Vertragshändler. Palandt/Grüneberg, § 307 BGB Rz. 34 ff. So Erman/Roloff, § 307 BGB Rz. 33. Im Einzelnen: AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 43 ff. BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2001, 292 (302) – Kfz-Kaufvertrag. OLG Köln v. 21.3.1997 – 19 U 215/96, NJW-RR 1998, 1274 – Hardware/Software. Hierzu AGB-Klauselwerke/Graf von Westphalen – Freizeichnungsklausel, Rz. 86 f. BGH v. 2.2.1994 – VIII ZR 262/92, NJW 1994, 1004 (1005).

1034

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 48 K

das Recht auf Rücktritt als auch den Anspruch auf Schadensersatz statt der Leistung verspricht. Damit steht fest, dass der Auftragnehmer/AGB-Verwender nicht berechtigt ist, sich in wirksamer Weise von der schuldhaften Nichterfüllung bzw. Schlechterfüllung all der Pflichten wirksam i.S.v. § 307 Abs. 2 Nr. 2 BGB freizuzeichnen, die im Gegenseitigkeitsverhältnis stehen. (2) Nebenpflichten Die Rechtsprechung des BGH hat allerdings auch entschieden, dass das Ver- 48 bot der Freizeichnungsklausel i.S.v. § 307 Abs. 2 Nr. 2 BGB auch dann eingreift, wenn der AGB-Verwender/Auftragnehmer schuldhaft eine Nebenpflicht i.S.v. § 241 Abs. 2 BGB verletzt hat – vorausgesetzt, ihre sanktionslose Nichterreichung führt dazu, dass die Erreichung des Vertragszwecks gefährdet wird1. So hat z.B. der BGH eine Haftungsfreizeichnung bei Missbrauch im Rahmen eines sog. „Tankschecksystems“ als unwirksam nach § 307 Abs. 2 Nr. 2 BGB verworfen, obwohl es sich „nur“ um eine Nebenpflicht gehandelt hat2. Denn die periodische Rechnungslegung mit Verbrauchsnachweisen – sie war der wesentliche Kern des „Tankschecksystems“ – sollte dem Kunden die Last abnehmen, jede Fahrt anhand eines jeden Rechnungsbelegs einzeln abrechnen zu müssen, so dass dann eine den Missbrauch ausschließende Freizeichnungsklausel diesen wirtschaftlichen Gesamtzweck wieder in Frage stellte. Berücksichtigt man allerdings im Kontext von § 241 Abs. 2 BGB, dass der Schutzzweck der dort normierten Nebenpflichten darauf abzielt, die Rechte, Rechtsgüter und Interessen des Auftraggebers zu schützen, dann wird man – ungeachtet der gebotenen generell-abstrakten Bewertung einer solchen Freizeichnungsklausel – nicht daran vorbeisehen dürfen, in welcher Weise die Freizeichnungsklausel mit der Pflicht des Auftraggebers oder des Auftragnehmers korreliert, durch Einkaufen von Versicherungsschutz adäquat eine eigenständige Risikovorsorge zu treffen3. Angesprochen wird dabei in erster Linie die Möglichkeit des AGB-Verwender/Auftragnehmers einen adäquaten Haftpflichtversicherungsschutz zum Schutz der Rechtsgüter des Auftraggebers zu kontrahieren4. Ist nämlich dem AGB-Verwender der Abschluss einer adäquaten Haftpflichtversicherungsdeckung zumutbar, weil vertretbare, nicht aber exzessive Prämien verlangt werden, dann greift der Gedanke ein: Die Kollektivierung eines Individualrisikos ist allemal die gerechtere Konfliktlösung als eine Freizeichnungsklausel eingreifen zu lassen, weil diese dazu führt, dass der Geschädigte mit seinem Schaden allein gelassen wird. Dem gegenüber führt der auch nach § 307 Abs. 1 Satz 1 BGB zu beachtende Verweis auf die 1 Erman/Roloff, § 307 BGB Rz. 33; Palandt/Grüneberg, § 307 BGB Rz. 33 ff.; MünchKomm/Wurmnest, § 307 BGB Rz. 74 ff. 2 BGH v. 20.6.1984 – VIII ZR 137/83, NJW 1985, 914 (915) – Tankschecksystem. 3 Hierzu im Einzelnen: AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 95 ff. 4 BGH v. 24.10.2001 – VIII ARZ 1/01, NJW 2002, 673 (675); BGH v. 12.5.1980 – VII ZR 166/79, NJW 1980, 1953 – Chemisch-Reinigung.

Graf von Westphalen

1035

K Rz. 49

Leistungsstörungen

mögliche Haftpflichtversicherungsdeckung – und die entsprechende Ersatzleistung der Versicherung – dazu, dass alle potenziellen Versicherungsnehmer über die Prämie das kollektivierte Risiko unter sich aufteilen. Zwangsläufig bedingt dies, wenngleich dies im Einzelfall schwer nachzuweisen ist, dass die Prämienlast über die Kosten des Produkts dann auf die Allgemeinheit verteilt wird, so dass jeder einzelne Vertragspartner des AGB-Verwenders dann durch einen (tendenziell) erhöhten Preis sicherstellt, dass das Prämienaufkommen zugunsten der Versicherungsnehmer gewährleistet ist. Konkret bedeutet dies, dass eine Haftungsfreizeichnungsklausel tendenziell an § 307 Abs. 2 Nr. 1 BGB oder auch an § 307 Abs. 1 Satz 1 BGB scheitert, wenn sie sich auf das Risiko von Personen- oder Sachfolgeschäden bezieht. Dieses Risiko ist – abhängig von den Umständen des Einzelfalls – generell im Rahmen von Ziff. 1 AHB (2008) gedeckt. dd) Verschulden bei Vertragsabschluss 49 Bedenkt man, dass die Rechtsfigur des Verschuldens bei Abschluss eines Vertrages i.S.v. § 311 Abs. 2 BGB im Kern auf dem Gedanken des Vertrauensschutzes beruht1, dann ist bei einer Verletzung dieser Pflicht die Nähe zum Verbotstatbestand von § 307 Abs. 2 Nr. 2 BGB sehr nahe. Denn die dort angesprochenen Pflichten betreffen ja auch das Grundvertrauen des anderen Vertragsteils, dass die vom Schuldner übernommen Pflichten, auf deren ordnungsgemäße Erfüllung der Gläubiger vertrauen durfte und auch vertraut hat, gegenüber einer Freizeichnungsklausel geschützt ist2. Hinzu kommt die Nähe dieser Rechtsfigur zu den Fällen der Garantiehaftung nach den §§ 444, 639 BGB (Rz. 2 ff.). Nichts anderes gilt insoweit, als bei Vorliegen einer Pflichtverletzung i.S.d. § 311 Abs. 2 BGB immer wieder die Frage zu beantworten ist, ob denn der Auftragnehmer hier nicht eine besondere Aufklärung und Beratung gegenüber seinem Vertragspartner schuldet, so dass auch entsprechende vertragliche Pflichten auf Grund eines dann oft stillschweigend zustande gekommenen Beratungsvertrages geschuldet werden3. Nimmt man dies alles näher unter die Lupe, dann spricht vieles dafür, dass der Auftragnehmer auch nicht berechtigt ist, sich von dem Vorwurf einer schuldhaften Pflichtverletzung i.S.d. § 311 Abs. 2 BGB wirksam freizuzeichnen4. 4. Rechtsfolgen: Schadensersatz – § 280 BGB 50 Liegt unter Berücksichtigung des zuvor Gesagten eine schuldhafte Verletzung einer wesentlichen Vertragspflicht des Auftragnehmers vor, dann spricht nach der Rechtsprechung des BGH alles dafür, dass eine gegen den 1 Vgl. im Einzelnen auch Palandt/Grüneberg, § 311 BGB Rz. 22 ff. 2 BGH v. 20.7.2005 – VIII ZR 121/04, NJW-RR 2005, 1496 (1503) – Honda. 3 BGH v. 23.7.1997 – VIII ZR 238/96, NJW 1997, 3227 (3228); Palandt/Grüneberg, § 311 BGB Rz. 16. 4 AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 88 f.

1036

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 52 K

Schadensersatzanspruch nach § 280 BGB gerichtete Haftungsfreizeichnungsklausel an § 307 Abs. 2 Nr. 2 BGB scheitert1. Dies hat der BGH mit Zustimmung der Literatur2 für den Fall des Lieferverzuges festgestellt. Dass sich dieses Urteil auf einen Kfz-Kauf eines Verbrauchers bezieht, ist irrelevant. Denn die Norm des § 307 Abs. 2 Nr. 2 BGB gilt nach der Rechtsprechung des BGH in gleicher Weise auch für den unternehmerischen Bereich3. Genauso wird man auch entscheiden müssen, wenn es zu Schadensersatzansprüchen des Käufers wegen eines Sach- oder Rechtsmangels im Rahmen von § 437 Nr. 3 BGB geht. Dann stehen vor allem Schäden wegen Nutzungsausfall und entgangener Gewinn auf dem Programm4. Denn sowohl bei der Mängelhaftung (§ 433 Abs. 1 Satz 2 BGB oder § 633 Abs. 2 BGB) als auch im Fall des Verzugs handelt es sich um die Verletzungen der Hauptpflicht, welche dann Schadensersatzansprüche nach § 280 Abs. 1 BGB oder – im Fall des Verzuges – nach § 280 Abs. 2 BGB auslösen. Dies bedeutet, um die häufigsten praktischen Fälle aufzuführen, dass der 51 Auftragnehmer nicht berechtigt ist, den bei der Erstellung eines Softwareprojekts immer wieder möglichen Verzögerungsschaden wirksam auszuschließen. Er ist aber auch nicht berechtigt, den auf Nutzungsausfall und entgangenen Gewinn gerichteten Schadensersatzanspruch nach § 437 Nr. 3 BGB wirksam freizuzeichnen5. Die damit aufgezeigten Risiken bei der Abwicklung eines Softwareerstellungsvertrages liegen damit auf der Hand; sie sind – dies ist der allgemeine Befund und die Konsequenz dieser Auffassung – nur auf einer individualvertraglichen Vereinbarung wirksam abzubedingen. Es soll allerdings nicht verschwiegen werden, dass in der Literatur gegen 52 diese Auffassung nachvollziehbare Bedenken geäußert werden. Sie richten sich in erster Linie gegen die Anwendbarkeit von § 307 Abs. 2 Nr. 2 BGB für den Fall, dass der Auftragnehmer eine mangelhafte Sache/mangelhaftes Werk erstellt und auf diese Weise dem Auftraggeber einen Vermögensschaden (Nutzungsausfall, entgangener Gewinn) zufügt. Geltend gemacht wird insbesondere, dass hier der Nacherfüllungsanspruch dazu führt, dass der Auftraggeber im Ergebnis eine mangelfreie Sache/Werk erhält, so dass von einer Gefährdung des Vertragszwecks i.S.v. § 307 Abs. 2 Nr. 2 BGB nicht die Rede sein könne, soweit eine Haftungsfreizeichnungsklausel die 1 BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2001, 292 (295). 2 Christensen, in: Ulmer/Brandner/Hensen, Bes. Vertragstypen, Teil 17 Rz. 18; AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 76 f. 3 Hierzu auch Palandt/Grüneberg, § 309 BGB Rz. 48 ff.; Christensen, in: Ulmer/ Brandner/Hensen, § 309 BGB Nr. 7 Rz. 38. 4 BGH v. 19.6.2009 – V ZR 93/08, NJW 2009, 2674 – Hauskauf. 5 Zum Anspruch auf Ersatz des Schadens: BGH v. 19.6.2009 – V ZR 93/08, NJW 2009, 2674; im Einzelnen AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 59 ff.; Graf von Westphalen, BB 2002, 209 (212 f.); Christensen, in: Ulmer/Brandner/Hensen, § 309 BGB Nr. 7 Rz. 38; MünchKomm/Wurmnest, § 307 Rz. 72; a.A. Dauner-Lieb/Kahn, FS für Graf von Westphalen 2010, S. 55, 56 ff. halten die Möglichkeit für gegeben, den Anspruch auf Nutzungsausfall abzubedingen.

Graf von Westphalen

1037

K Rz. 53

Leistungsstörungen

aus der Mangelhaftigkeit resultierenden Schadensersatzrisiken oder die auf Grund eines Verzugs ausschließt1. Doch ist dieser Ansatz deswegen nicht überzeugend, weil zwei Gegenargumente in Stellung zu bringen sind: Zunächst ist darauf aufmerksam zu machen, dass sowohl der eingetretene Verspätungsschaden als auch ein etwaiger mangelbedingter Nutzungsausfall oder entgangener Gewinn endgültige Vermögenseinbußen des Auftraggebers darstellen. Es handelt sich in der herkömmlichen Terminologie nämlich – jedenfalls im Rahmen der Mängelhaftung – um einen klassischen Mangelschaden, der als Folge des Mangels allemal im Vermögen des Auftraggebers verbleibt, zumal der Differenzthese von § 249 BGB Tribut geschuldet wird. Hinzu tritt die weitere Erwägung, dass nämlich der dogmatische Ansatz, im Fall der schuldhaften Verletzung einer wesentlichen Vertragspflicht stets auf § 307 Abs. 2 Nr. 2 BGB – und damit auf den Tatbestand der Gefährdung des Vertragszwecks – zurückzugreifen, nicht unbedingt überzeugend ist2. Berücksichtigt man nämlich, dass die Trennlinie zwischen § 307 Abs. 2 Nr. 1 BGB und § 307 Abs. 2 Nr. 2 BGB bestenfalls mikroskopisch wahrzunehmen ist, weil es bei der schuldhaften Verletzung einer wesentlichen Vertragspflicht immer darum geht, dass Normen des dispositiven Rechts aus Gründen verletzt werden, die der Auftragnehmer/ AGB-Verwender zu vertreten hat, dann bedarf die Frage einer Antwort: Wird der Auftraggeber nicht unangemessen i.S.v. § 242 BGB (§ 307 BGB) benachteiligt, wenn ihm als Folge einer verspäteten oder mangelhaften Lieferung/ Werkerstellung ein endgültiger Vermögensnachteil verbleibt? Entspricht dies dem Äquivalenzverhältnis von Leistung und Gegenleistung? Dass diese Frage unter Geltung des Gebots der richterlichen Inhaltskontrolle nach § 307 BGB kaum abschließend mit „ja“ zu beantworten ist, folgt letztlich auch aus dem BGH-Urteil vom 12.1.19943. Denn in diesem Urteil wird – bezogen auf den Tatbestand des Verzugs – klargestellt, dass im unternehmerischen Verkehr die Haftung für die Erfüllung einer fristgerechten Lieferverpflichtung „Hauptleistungspflicht“ ist und damit nicht wirksam nach § 307 Abs. 2 Nr. 2 BGB abbedungen werden darf. Dass dann für die Mängelhaftung kein anderer Maßstab gelten kann, liegt auf der Hand. 5. Rechtsfolge: Schadensersatz statt der Leistung – Rücktritt a) Ausgangspunkt 53 In all den Fällen, in denen der Auftraggeber als Folge einer dem Auftragnehmer zuzurechnenden Pflichtverletzung berechtigt ist, nach Fristsetzung Schadensersatz statt der Leistung zu verlangen oder vom Vertrag zurückzutreten, stellt sich unter der Perspektive von § 307 Abs. 2 Nr. 1 BGB die weitere Frage, ob der Auftragnehmer/AGB-Verwender berechtigt ist, die 1 Tettinger, AcP 205 (2005), S. 1 (13 ff.); vgl. auch Fuchs, in: Ulmer/Brandner/Hensen, § 307 BGB Rz. 292 ff.; Tiedtke/Burgmann, NJW 2005, 1153 (1155). 2 AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 55 ff. 3 BGH v. 12.1.1994 – VIII ZR 165/92, NJW 1994, 1060 (1063) – Daihatsu.

1038

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 55 K

Haftung auf Schadensersatz statt der Leistung (§ 281 BGB) wirksam abzubedingen, weil er gleichzeitig dem Auftraggeber ein Rücktrittsrecht einräumt. Die damit aufgeworfene Frage zentriert darin, ob es dem AGB-Verwender in die Hand gegeben ist, bei schuldhafter Verletzung eine wesentliche Vertragspflicht den Anspruch des Auftraggebers auf Schadensersatz statt der Leistung durch Einräumung eines Vertragslösungsrechts wirksam abzubedingen. Hierüber gibt es bislang – soweit ersichtlich – keine belastbare Entscheidung, weder des BGH noch eines Obergerichts. Deshalb ist nach der Auffassung der Literatur zu fragen, die nach wie vor ein umstrittenes Meinungsbild repräsentiert. Soweit die Wirksamkeit einer den Schadensersatzanspruch statt der Leistung umfassenden Freizeichnungsklausel bejaht wird, geschieht dies vor allem unter Hinweis des § 309 Nr. 8b bb BGB. Denn im Fall des „Fehlschlagens“ der Nacherfüllung ist ein solches Vertragslösungsrecht als unbedingt notwendige Kompensation des durch die Nichterfüllung entstandenen Nachteils angesehen wird1. Doch finden sich auch Gegenstimmen2. Geht man, wie hier geschehen, davon aus, dass nach Auffassung des BGH3 54 der Ausschluss der Schadensersatzhaftung nach § 280 Abs. 2 BGB im Fall einer fahrlässig begründeten Verzugshaftung an § 307 Abs. 2 Nr. 2 BGB scheitert, dann wird man hier ein klassisches Erst-Recht-Argument bemühen müssen, um das gleiche Ergebnis für den Anspruch auf Schadensersatz statt der Leistung zu begründen. Denn der Verzugsschaden nach § 280 Abs. 2 BGB steht neben dem weiterhin dem Auftraggeber zustehenden Erfüllungsanspruch. Demgegenüber führt der Schadensersatzanspruch statt der Leistung, wie aus § 281 Abs. 4 BGB abzulesen, dazu, dass der Anspruch auf Erfüllung untergeht. Damit aber würde eine Haftungsfreizeichnungsklausel unmittelbar dazu führen, dass das Äquivalenzverhältnis von Leistung und Gegenleistung – und damit: die Erreichung des Vertragszwecks – auf das Empfindlichste i.S.v. § 307 Abs. 2 Nr. 2 BGB gestört wäre. Das ist auf dieser Ebene nicht hinzunehmen4. b) Eigene Auffassung Gleichwohl stellt sich – vor allem unter Berücksichtigung der Norm von § 309 Nr. 8b bb BGB – die weitere Frage, ob die Rechte des Auftraggebers in diesen Fällen nicht doch hinreichend gewahrt werden, wenn ihm der 1 Erman/Roloff, § 309 BGB Rz. 74; so wohl auch Palandt/Grüneberg, § 309 BGB Rz. 48; Litzenburger, NJW 2002, 1244 (1245); Dauner-Lieb/Kahn, FS für Graf von Westphalen 2010, S. 55, 64 ff.; Tettinger, AcP 205 (2005) S. 1 (13 ff.); Fuchs, in: Ulmer/Brandner/Hensen, § 307 BGB Rz. 293 f. 2 Christensen, in: Ulmer/Brandner/Hensen, § 309 Nr. 7 BGB Rz. 38; AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 59 ff.; offen lassend MünchKomm/Wurmnest § 309 BGB Nr. 7 Rz. 29; Koch, WM 2002, 2173 (2179). 3 BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2001, 292 (293); BGH v. 12.1.1994 – VIII ZR 165/92, NJW 1994, 1060 (1063) – Daihatsu. 4 AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 60 f.

Graf von Westphalen

1039

55

K Rz. 56

Leistungsstörungen

Auftragnehmer den Anspruch auf Schadensersatz statt der Leistung zwar abschneidet, ihm aber ein Rücktrittsrecht einräumt1. Dabei ist ungefragt einzuräumen, dass die Norm von § 309 Nr. 8b bb BGB den Schluss nahelegt, dass im Fall des „Fehlschlagens“ der Nacherfüllung ein Minderungs- oder Rücktrittsrecht i.S.v. § 437 Nr. 2 ausreicht, um die Rechte des Auftraggebers – gleichgültig ob er die Position eines Käufers oder die eines Werkbestellers inne hat – auszugleichen. Doch ist im gleichen Atemzug hinzuzusetzen, dass § 440 BGB – gleiches gilt für § 636 BGB – im Fall des „Fehlschlagens“ der Nacherfüllung den Auftraggeber davon dispensieren, dem Auftragnehmer eine Frist zu setzen, bevor dieser berechtigt ist, beide Ansprüche/Rechte einzufordern, nämlich: Schadensersatz statt der Leistung nach § 281 BGB oder ein Rücktrittsrecht nach § 323 BGB (§ 437 Nr. 3 BGB; § 634 Nr. 4 BGB). 56 Dass aber die §§ 440, 636 BGB für diese Fälle die Grundnorm i.S.v. § 307 Abs. 2 Nr. 1 BGB darstellen und § 309 Nr. 8b bb BGB lediglich die AGBrechtliche Klauselgestaltung anspricht, ist schon vom Wortlaut der Normen her evident. Dies aber führt bei Anwendung von § 307 Abs. 2 Nr. 1 BGB unmittelbar zu der Erkenntnis, dass in den Fällen des „Fehlschlagens“ der Nacherfüllung der Auftraggeber – sei es als Käufer, sei es als Werkbesteller – ungekürzt sowohl den Anspruch auf Schadensersatz statt der Leistung als auch das Recht auf Rücktritt erhalten muss. Unterstrichen wird diese Lösung durch den Hinweis auf § 325 BGB: Wenn nämlich der Gesetzgeber in dieser Norm dem Gläubiger das Recht einräumt, nach seiner Wahl Schadensersatz statt der Leistung und (kumulativ) ein Recht auf Rücktritt geltend zu machen, dann muss diese den Auftraggeber als Gläubiger begünstigende Rechtsfolge auch unmittelbare Auswirkungen auf die Rechte haben, die ihm im Fall des „Fehlschlagens“ der Nacherfüllung verbleiben müssen. Da nämlich § 325 BGB seinerseits einen hohen Gerechtigkeitsgehalt aufweist, der i.S.v. § 307 Abs. 2 Nr. 1 BGB zu berücksichtigen ist, wird man also zu dem Ergebnis gelangen müssen: Im Fall des „Fehlschlagens“ der Nacherfüllung stehen dem Auftraggeber sowohl das Recht auf Schadensersatz statt der Leistung als auch das des Rücktritts zur Seite. Entgegenstehende AGB-Klauseln verstoßen gegen § 307 Abs. 2 Nr. 2 BGB und sind daher unwirksam2. c) Berücksichtigung der Interessen bei einem Softwareerstellungsvertrag 57 Dabei gilt ein weiterer Gesichtspunkt, der insbesondere bei einem Softwareerstellungsvertrag bedeutsam ist: Würde man hier anders entscheiden und deshalb abweichend i.S.v. § 307 Abs. 2 Nr. 1 BGB argumentieren, dass dem Auftraggeber lediglich im Fall des „Fehlschlagens“ einer Nacherfüllung das Recht auf „Rücktritt“ verbleibt, dann werden auf diese Weise die 1 Erman/Roloff, § 309 BGB Rz. 74; Fuchs in: Ulmer/Brandner/Hensen, § 307 BGB Rz. 294 f. 2 Offen lassend MünchKomm/Wurmnest, § 309 Nr. 7 Rz. 29 m.w.N.

1040

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 59 K

Rechte des Auftraggebers kaum hinreichend gewahrt. Denn der Rücktritt von einem Projektvertrag liegt regelmäßig nicht im Interesse des Auftraggebers: Scheitert nämlich ein solches Projekt, dann steht der Anspruch auf Schadensersatz statt der Leistung – gemessen an den schutzwürdigen Interessen des Auftraggebers – eindeutig im Vordergrund, weil regelmäßig dann auch nicht unerhebliche Investitionskosten vorprogrammiert sind. Mit der Rückabwicklung i.S.d. §§ 346 ff. BGB ist dem Auftraggeber kaum gedient; allein die Pflicht, etwaige Anzahlungen zurückzahlen zu müssen, ist keine hinreichend angemessene Antwort auf das Scheitern eines Projekts. Daher spricht gerade bei einem Softwareerstellungsvertrag die Interessenlage der Parteien im Rahmen von § 307 Abs. 2 Nr. 1 BGB für die hier vertretene Lösung: Dem Auftraggeber ist ungekürzt der Anspruch auf Schadensersatz statt der Leistung einzuräumen; kumulativ hierzu ist ihm auch das Rücktrittsrecht zu gewähren. Diese Erwägungen, die prototypisch für den Fall des „Fehlschlagens“ der 58 Nacherfüllung dargestellt worden sind, gelten naturgemäß auch in all den anderen Fällen, in denen eine schuldhafte Pflichtverletzung vorliegt, die sich auf eine wesentliche Vertragspflicht bezieht. Denn immer dann, wenn als Folge einer solchen Pflichtverletzung dem Auftraggeber das Recht zusteht, Schadensersatz statt der Leistung gemäß § 281 BGB einzufordern, wird man unter Berücksichtigung der Wertungskriterien von § 307 Abs. 2 Nr. 2 BGB zu dem Resultat gelangen müssen: Eine entgegenstehende Haftungsfreizeichnungsklausel ist unwirksam. Dabei macht es keinen entscheidenden Unterschied, ob insoweit Pflichtverletzungen im Fall eines Lieferverzuges, einer Mängelhaftung, der Unmöglichkeit oder der schuldhaften Verletzung einer (wesentlichen) Nebenpflicht i.S.v. § 241 Abs. 2 BGB in Rede stehen. Immer kommt alles entscheidend darauf an, ob nach der zugrundeliegenden gesetzlichen Wertung dem Auftraggeber ein Anspruch auf Schadensersatz statt der Leistung nach §§ 281 ff. BGB zur Seite steht. 6. Haftungsbegrenzungsklauseln Wie bereits zuvor angedeutet, ist die Rechtsprechung des BGH bereits seit 59 Jahrzehnten stabil: Wenn und soweit der Auftragnehmer eine wesentliche Vertragspflicht i.S.v. § 307 Abs. 2 Nr. 2 BGB schuldhaft verletzt hat, ist eine Haftungsbegrenzungsklausel nur dann mit § 307 Abs. 2 Nr. 1 BGB vereinbar, wenn sich der Schadensersatz des Auftraggebers auf den typischerweise eintretenden, vorhersehbaren Schaden bezieht1. Auch die Literatur teilt diese Auffassung2. Daraus folgt zwingend: Eine wie auch immer geartete Haf1 BGH v. 27.9.2000 – VIII ZR 155/99, NJW 2001, 292 (295); BGH v. 25.2.1998 – VIII ZR 276/96, NJW 1998, 1640 (1644); BGH v. 12.1.1994 – VIII ZR 165/92, NJW 1994, 1060 (1063 ff.); BGH v. 11.11.1992 – VIII ZR 238/91, NJW 1993, 335. 2 Christensen, in: Ulmer/Brandner/Hensen, § 309 Nr. 7 BGB Rz. 39; AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklauseln, Rz. 118 f.; Erman/Roloff, § 309 BGB Rz. 78; Palandt/Grüneberg, § 309 BGB Rz. 51 f.

Graf von Westphalen

1041

K Rz. 60

Leistungsstörungen

tungsbegrenzungsklausel, welche nicht diesen Höchstbetrag ausdrücklich anspricht und auch summenmäßig erreicht, ist nach § 307 Abs. 2 Nr. 1 BGB unwirksam1. In der Sache unterscheidet sich diese Haftungsgrenze nicht in nennenswerter Weise von derjenigen, die § 249 BGB mit der Verpflichtung zur Naturalrestitution festlegt. Denn die Vorhersehbarkeit eines Schadens ist in ähnlicher Weise ein Instrument, die Schadensersatzhaftung – außerhalb der naturwissenschaftlichen Kausalität – normativ zu begrenzen wie der von der Rechtsprechung bemühte Satz von der adäquaten Kausalität2 oder den Hinweis auf den Schutzzweck der Norm3. Damit steht fest, dass dem Auftragnehmer als AGB-Verwender nicht in die Hand gegeben ist, in wirksamer und belastbarer Weise seine Haftungsrisiken bei einem Softwareerstellungsvertrag zu begrenzen. Denn es besteht Einvernehmen darüber, dass eine wirksame Haftungsbegrenzungsklausel lediglich dazu führt, dass nicht vorhersehbare Exzess-Risiken abbedungen werden dürfen4. 7. Zentrale Frage: Umfassende Haftungsbegrenzung („Cap“) 60 Berücksichtigt man das zuvor Gesagte und nimmt hinzu, dass auch die in den §§ 444, 639 BGB verankerten Garantiezusagen keine Haftungsbegrenzungen zulassen (Rz. 2 ff.), welche dem Zweck der Beschaffenheitsgarantie oder auch einer Zusicherungserklärung5 zuwider läuft6, dann stellt sich die entscheidende Frage: In welcher Weise ist der Auftragnehmer in der Lage, die aus einen Softwareerstellungsvertrag resultierenden Haftungsrisiken insgesamt wirksam einzugrenzen. Denn wenn er – nach der hier vertretenen Meinung – im Fall einer schuldhaften Verletzung einer wesentlichen Vertragspflicht i.S.v. § 307 Abs. 2 Nr. 2 BGB nach den gesetzlichen Normen – also: praktisch unbegrenzt – haftet, dann sind zwei Handlungsgebote angezeigt. a) Anspruchsspezifische Enumeration der Haftungsbegrenzung 61 Zunächst gebieten bereits formelle Gründe, die allerdings im Wesentlichen dem Transparenzgebot des § 307 Abs. 1 Satz 2 BGB geschuldet sind, etwaige Haftungsbegrenzungsklauseln immer anspruchsspezifisch zu regeln. Dahinter verbirgt sich der allgemeine Grundsatz, dass der Auftraggeber im Falle einer schuldhaften Pflichtverletzung des Auftragnehmers in der Lage sein muss, von sich aus die ihm zustehenden Schadensersatzansprüche geltend 1 Erman/Roloff, § 309 BGB Rz. 78. 2 Palandt/Grüneberg, vor § 249 BGB Rz. 26 ff. 3 BGH v. 26.6.1997 – IX ZR 233/96, NJW 1997, 2946 (2947); BGH v. 10.10.1996 – IX ZR 294/95, NJW 1997, 250 (253); BGH v. 21.9.1995 – IX ZR 228/94, NJW 1996, 48 (51). 4 Fuchs, in: Ulmer/Brandner/Hensen, § 309 Nr. 7 BGB Rz. 39; Palandt/Grüneberg, § 307 BGB Rz. 51; AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklausel, Rz. 118 ff.; Erman/Roloff, § 309 BGB Rz. 78. 5 BGH v. 29.11.2006 – VIII ZR 92/06, NJW 2007, 1346 (1348). 6 Hierzu im Einzelnen: Graf von Westphalen, KSzW 2010, 164 ff.

1042

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 63 K

zu machen, soweit diese nicht in wirksamer Weise begrenzt sind. Dies schließt ein, dass die jeweilige Haftungsbegrenzungsklausel an der systematisch zutreffenden Stelle erwähnt wird, also: beim Verzug, bei der Mängelhaftung oder – durch entsprechende Verweise auch im Rahmen einer Gesamthaftung („Cap“)1. Dieser Ansatz hat vor allem auch seine weitreichende praktische Bedeutung, wenn es sich darum handelt, dass die mit den Mängelansprüchen konkurrierenden deliktischen Ansprüche – Stichwort: „weiterfressender Schaden“ – erfasst werden müssen2. b) Umfassende Klausel In einem zweiten Schritt sollte dann der Auftragnehmer gesteigerten Wert 62 darauf legen, dass alle vertraglichen und gesetzlichen Ansprüche, welche im Rahmen des Vertragsverhältnisses dem Auftraggeber zustehen könnten, von einer Gesamthaftungsklausel („Cap“) erfasst werden. Will man nämlich hier nicht die Schadensersatzhaftung auf den typischerweise eintretenden, vorhersehbaren Schaden begrenzen3, sondern diesen Höchstbetrag aus zwingenden, kommerziellen und betriebswirtschaftlichen Gründen unterhalb dieser Schwelle ansiedeln, dann ist diese Möglichkeit dem Auftragnehmer als AGB-Verwender nur dann eröffnet, wenn er bereit ist, die entsprechende Gesamthaftungsklausel mit dem Auftraggeber im Einzelnen nach § 305 Abs. 1 Satz 3 BGB auszuhandeln (Kap. J Rz. 33). Dabei stellt sich gerade hier die ganz entscheidende Frage: Ist es erfor- 63 derlich, dass der Auftragnehmer als AGB-Verwender in diesen Fällen den „gesetzesfremden Kerngehalt“4 ernsthaft gegenüber dem Auftraggeber zur Disposition stellt, um ihm die „reale Möglichkeit“5 einzuräumen, seine wirtschaftlichen Interessen durch eine Neuformulierung der Haftungsbegrenzungsklausel durchzusetzen? Oder ist ein Weniger ausreichend, aber auch erforderlich?6 Behält man die erste Alternative als Ansatzpunkt im Auge, dann wird der Auftragnehmer als AGB-Verwender gehalten sein, alternativ zu einer Haftungsbegrenzung dem Auftraggeber die Möglichkeit zu eröffnen, eine allein an den gesetzlichen Bestimmungen ausgerichtete Haftung anzubieten. Denn nur unter diesen Voraussetzungen hat der Auftragnehmer als AGB-Verwender den „gesetzesfremden Kerngehalt“7 der vor-

1 2 3 4

BGH v. 24.11.1976 – VIII ZR 137/75, BB 1977, 162 – Schwimmschalter. Hierzu im Einzelnen Produkthaftungshandbuch/Foerste, 3. Aufl., § 21 Rz. 28 ff. BGH v. 11.11.1992 – VIII ZR 238/91, NJW 1993, 335. BGH v. 22.11.2012 – VII ZR 222/12, NJW 2013, 856 (858); BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). 5 BGH v. 22.11.2012 – VII ZR 222/12, NJW 2013, 856 (858); BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). 6 Hierzu vor allem BGH v. 7.3.2013 – VII ZR 162/12, NJW 2013, 1431 (1432). 7 BGH v. 23.1.2003 – VII ZR 210/01, NJW 2003, 1805 (1807); BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111).

Graf von Westphalen

1043

K Rz. 64

Leistungsstörungen

gesehenen, vorformulierten Haftungsbegrenzungsklausel zur Disposition gestellt. 64 Dieser dogmatische Ansatz geht sehr weit und ist – jedenfalls nach der hier vertretenen Auffassung (Kap. J Rz. 41 ff.) – im unternehmerischen Verkehr nicht zwingend zu beachten1. Denn hier reicht es aus, dass der Auftragnehmer als AGB-Verwender dem Auftraggeber die „reale Möglichkeit“2 eingeräumt hat, auf die Gestaltung der Haftungsbegrenzungsklausel tatsächlich Einfluss zu nehmen3. Sieht man bereits in einer solchen Einflussnahme den Tatbestand einer privatautonomen Vertragsgestaltungsfreiheit i.S.d. § 305 Abs. 1 Satz 3 BGB als realisiert an, dann reicht es aus, wenn Auftragnehmer und Auftraggeber ernsthaft und nachhaltig über die als vertretbar und realistisch eingeschätzte Haftungshöchstgrenze verhandeln und zu einem gemeinsamen – interessengerechten – Ergebnis gelangen. 65 Zweckmäßigerweise kann das in der Weise geschehen, dass der vom Auftragnehmer herrührende Vertragsentwurf im Hinblick auf eine umfassende Haftungsbegrenzungsklausel („Cap“) überhaupt keine Angaben enthält, sondern einen Leerraum. Dieser kann dann, muss aber auch im privatautonomen Konsens der Parteien gefüllt werden, gleichgültig, welcher Prozentsatz des Kaufpreises oder welcher Nominalbetrag als Haftungsobergrenze dann eingesetzt wird, um das Gesamtrisiko des Auftragnehmers transparent zu begrenzen. Wenn sich dann eine solche Vertragsbestimmung auf alle gesetzlichen und/oder vertraglichen Ansprüche bezieht, die im Vertragsverhältnis zwischen Auftraggeber und Auftragnehmer auf Grund einer Pflichtverletzung des Auftragnehmers zur Entstehung gelangen können, dann ist eine solche Vertragsgestaltung als Individualvertrag zu werten und nur in den engen Grenzen der §§ 138, 242 BGB angreifbar. Freilich hilft dies nicht im Rahmen des § 276 Abs. 3 BGB und auch der Tatbestand der Arglisthaftung und der der Garantiehaftung nach den §§ 444, 639 BGB (Rz. 2 ff.) sind vorzubehalten, um vermeidbare Probleme nach § 139 BGB im Blick auf die Rest-Wirksamkeit der Haftungsbegrenzungsklausel zu vermeiden.

IV. Sanktionen für unwirksame Klauseln 66 Ist eine Haftungsfreizeichnungs- oder Haftungsbegrenzungsklausel – gleichgültig, aufgrund welcher Rechtsnorm – unwirksam, dann ergibt sich die Rechtsfolge aus § 306 Abs. 2 BGB. Es gilt dann dispositives Recht4. Eine ergänzende Vertragsauslegung i.S.d. §§ 133, 157 BGB findet in diesen Fällen

1 2 3 4

Vgl. aber BGH v. 7.3.2013 – VII ZR 162/12, NJW 2013, 1431 (1432). BGH v. 3.11.1999 – VIII ZR 269/98, NJW 2000, 1110 (1111). BGH v. 17.2.2010 – VIII ZR 67/09, NJW 2010, 1131 (1133). BGH v. 14.12.1995 – III ZR 34/95, NJW 1996, 654, 656; BGH v. 20.1.1983 – VII ZR 105/81, NJW 1983, 1322, 1327; Christensen in: Ulmer/Brandner/Hensen, § 309 BGB Nr. 7 Rz. 40; Palandt/Grüneberg, § 307 BGB Rz. 53.

1044

Graf von Westphalen

Haftungsfreizeichnungs- und Haftungsbegrenzungsklauseln

Rz. 67 K

nicht statt1. Denn dies würde dazu führen, dass im Ergebnis eine geltungserhaltende Reduktion der betreffenden Klausel stattfinden würde, die aber nach ständiger Rechtsprechung des BGH unzulässig ist2. Auch verstößt es gegen § 306 Abs. 2 BGB, wenn Haftungsfreizeichnungs- 67 oder Haftungsbegrenzungsklauseln mit salvatorischen Zusätzen versehen werden, und zwar „soweit gesetzlich zulässig“3. Denn abgesehen davon, dass solche Klauseln schon bei der Einbeziehung gemäß §§ 145 ff. BGB Probleme aufwerfen, weil ihnen die erforderliche Transparenz fehlt4, sind solche Klauseln geeignet, die von § 306 Abs. 2 BGB zwingend gebotene Geltung des dispositiven Rechts als Ersatzrecht zu verdrängen5.

1 Palandt/Grüneberg, § 309 BGB Rz. 51 ff. 2 BGH v. 21.1.1999 – III ZR 289/97, NJW 1999, 1031, 1032; BGH v. 19.2.1998 – I ZR 233/95, NJW-RR 1998, 1426, 1429. 3 Hierzu BGH v. 5.3.2013 – VIII ZR 137/12, NJW 2013, 1668. 4 Vgl. AGB-Klauselwerke/Graf von Westphalen, Freizeichnungsklauseln Rz. 8 f. 5 Schmidt in: Ulmer/Brandner/Hensen, § 306 Rz. 39 ff.; AGB-Klauselwerke/Graf von Westphalen/Thüsing, Rechtsfolgen Rz. 39 ff.

Graf von Westphalen

1045

5. Kapitel Einzelprobleme L. Hinterlegung von Software, Escrow

I. 1. 2. 3. 4.

Quellcode . . . . . . . . . . . . . . . . . . . Interessenlage. . . . . . . . . . . . . . . . Rechtsprechungsentwicklung . „Hinterlegung“, Begriff . . . . . . . Grundschema der Vertragsbeziehungen . . . . . . . . . . . . . . . . . 5. Variante: Hinterlegung für eine Vielzahl noch unbekannter Kunden . . . . . . . . . . . . . . . . . . . . . 6. Variante: Hinterlegung durch den Kunden. . . . . . . . . . . . . . . . . . II. Insolvenzfestigkeit und Kündbarkeit des Beschaffungsvertrags . . . . . . . . . . . . . . . . . . . . . . . . 1. Einführung . . . . . . . . . . . . . . . . . . 2. Wesentliche Voraussetzungen . 3. Gefährdung der dauerhaften Überlassung und Rechtseinräumung . . . . . . . . . . . . . . . . . . . . 4. Abstraktionsprinzip . . . . . . . . . . 5. Kriterien für Insolvenzfestigkeit mit Einbeziehung des Escrow-Agenten. . . . . . . . . . . . . . III. Analyse der Konstruktion . . . . . 1. Maximen/Fragestellungen zum Rahmen . . . . . . . . . . . . . . . . a) Umfang . . . . . . . . . . . . . . . . . . . b) Inhaberschaft . . . . . . . . . . . . . . c) Vergütung . . . . . . . . . . . . . . . . . d) Eigentum . . . . . . . . . . . . . . . . . e) Bedingungsfeindlichkeit . . . . 2. Treuhand, Verhältnis zur Insolvenz des Treugebers. . . . . . . . IV. Vertragsgestaltung und -struktur . . . . . . . . . . . . . . . . . . . . 1. Phasen . . . . . . . . . . . . . . . . . . . . . . 2. Leistungsbereiche . . . . . . . . . . . . 3. Konstruktionen/Konstellationen . . . . . . . . . . . . . . . . . . . . .

Rz.

Rz.

1 1 16 24

V. Herausgabe . . . . . . . . . . . . . . . . . . 112 1. Allgemeines . . . . . . . . . . . . . . . . . 112 2. Zur „insolvenzfesten“ Konstruktion . . . . . . . . . . . . . . . . 114 3. Beispiele zu Hinterlegungsfällen . . . . . . . . . . . . . . . . . . . . . . . . 122 a) „Harte“ Fälle . . . . . . . . . . . . . . 122 b) „Weiche“ Fälle. . . . . . . . . . . . . 123 4. Spezielle Fälle . . . . . . . . . . . . . . . . 125 a) Jahr 2000-Fehler. . . . . . . . . . . . 126 b) „Unkündbarkeit“ . . . . . . . . . . 127 c) Eurofähigkeit . . . . . . . . . . . . . . 128 5. Besondere Regelungen zur Herausgabe . . . . . . . . . . . . . . . . . . 129

29

35 37

39 39 41

43 46

56 58 59 59 63 65 69 73 74 79 80 92 99

VI. Risiken des Escrow-Vertrags, besondere Problemlagen. . . . . . . 131 1. Pflege . . . . . . . . . . . . . . . . . . . . . . . 131 2. Weiterreichende Pflichten, Dauerschuldverhältnis . . . . . . . . 133 3. Empfehlungen . . . . . . . . . . . . . . . 136 4. LG Mannheim, Konsequenzen . 138 a) Einstweiliges Verfügungsverfahren . . . . . . . . . . . . . . . . . . 139 b) Ausschließlichkeit einer Field of use-Regelung . . . . . . . 140 c) Erfüllung von Nebenpflichten . . . . . . . . . . . . . . . . . . 141 d) Absicherung der Urheberrechte bei Software-Überlassung . . . . . . . . . . . . . . . . . . . . 143 5. Gegenmodell LG Frankfurt, Software als Sache . . . . . . . . . . . . 146 6. Insolvenz-unabhängige aufschiebend bedingte Verfügung: BGH vom 17.11.2005 . . . . . . . . . 149 VII. Prozessuale Verwertung, Vorlage, Beweis- und Befundsicherung . . . . . . . . . . . . . . . . . . . . 158 VIII. Leistungsstörungen, Mitwirkung . . . . . . . . . . . . . . . . . . 162

Schneider

1047

L Rz. 1

Einzelprobleme Rz.

Rz.

IX. Vorschläge für die Vertragsgestaltung . . . . . . . . . . . . . . . . . . . 168 1. Verhältnis zum Beschaffungsvertrag . . . . . . . . . . . . . . . . . . . . . . 168 2. Die Lösung des Insolvenzproblems über Nießbrauch beim Beschaffungsvertrag . . . . . . . . . . 170

3. Speziell Escrow während der Erstellung der Software . . . . . . . 174 X. De lege ferenda . . . . . . . . . . . . . . . 178

I. Quellcode 1. Interessenlage 1

Der Anwender als Endanwender, der zugleich selbst Anbieter bzw. Vertreiber sein kann, Händler und Integrationshäuser benötigen für die Bearbeitung der Software, etwa um sie zu aktualisieren, faktisch den Quellcode. Rechtlich erfordert dies, dass ihnen ein entsprechendes Bearbeitungsrecht zusteht. Ohne explizite Regelung hat der Anwender ein solches nur im Rahmen der Fehlerbeseitigung, § 69d Abs. 1 UrhG1, und der Herstellung der Interoperabilität (§ 69e UrhG). Des Weiteren braucht er die physische Ausgabe des Quellcodes2. Rechtseinräumung und Übergabe des geeigneten Materials zusammen ergeben erst die Möglichkeit für den Anwender, selbst am Quellcode zu arbeiten.

2

Über längere Zeit war in Deutschland nicht klar und ist es wohl auch bislang noch nicht vollständig, ob bei Abwesenheit spezieller Vereinbarungen der Auftragnehmer von anzupassender bzw. zu erstellender Software verpflichtet ist, den Quellcode mitzuliefern. Seit einer Entscheidung aus dem Jahr 1986 gab es eine beachtliche Reihe von OLG- und LG-Entscheidungen hierzu, die tendenziell – in Abhängigkeit vom Vertragswerk – kundenfreundlicher ausfielen3.

3

Die Zurückhaltung der Gerichte, vor allem des BGH, spiegelt das Interesse des Anbieters, den Quellcode nicht aus der Hand zu geben, und zwar trotz dessen Absicherung durch den urheberrechtlichen Schutz4. Übersehen wird häufig, dass der Kunde ohne Verfügbarkeit des Quellcodes seiner Investition in die Software nicht sicher sein kann. Insoweit gehört die Vorsorge hinsichtlich des Quellcodes zur „IT-Sicherheit“5.

1 BGH v. 24.2.2000 – I ZR 141/97, CR 2000, 656. 2 Zusätzlich evtl. die Entwicklungsumgebung, Tools für die Standardsoftware, Schlüssel und Dokumentationen, s.a. Auer-Reinsdorff/Kast, Software-Escrow, in: Auer-Reinsdorff/Conrad (Hrsg.), Beck’sches Mandatshandbuch IT-Recht, 2011, § 10 Rz. 68 zu den zu hinterlegenden Gegenständen und Informationen. 3 S. sogleich zu den Urteilen unten Rz. 16 ff. 4 S. dazu sogleich unten Rz. 16 ff. 5 S. Schultze-Melling, CR 2005, 73 (76).

1048

Schneider

Hinterlegung von Software, Escrow

Rz. 7

L

Die Softwarehäuser sehen den Quellcode als ihr „Herzstück“. Dementspre- 4 chend gehen auch die Insolvenzverwalter davon aus, dass „der“ Quellcode selbstverständlich zur Masse gehört. Daran ändert sich nach der Meinung vieler Insolvenzverwalter auch nichts, wenn Kopien hiervon hergestellt und den Kunden überlassen wurden1. Erschöpfung auf Grund dauerhafter Überlassung spielt offensichtlich hinsichtlich des Quellcodes keine Rolle2. Das Interesse des Kunden ist, sich in gewissem Sinne unabhängiger zu ma- 5 chen und, zumindest im Notfall, über den Quellcode zu verfügen3. In Großbritannien, USA ist es weitgehend üblich, Escrow bei Standard-Softwarelizenzen für geschäftswichtige Software zu vereinbaren. In Frankreich ist die Hinterlegung bei Individualsoftware (nicht dagegen bei Standardsoftware) gebräuchlich4. Dort besteht keine Klarheit darüber, „ob der Unternehmer dem Auftraggeber bei der Erstellung von Individualsoftware den Source Code herausgeben muss, sofern der Vertrag keine Regelung enthält“5. Kurz zur Erläuterung: Der Quellcode ist diejenige Ausführung des Pro- 6 gramms, die zwar nicht ablauffähig, aber änderbar ist, während der Objektcode die Ausführung ist, die aus dem Quellcode entsteht, ausführbar ist, aber kaum änderbar. Will man also die Software weiterentwickeln, ändern und irgendwie speziell für sich gestalten, braucht man den „Quellcode“6. Neben dem Notfall der Insolvenz des Softwarehauses gibt es noch eine Rei- 7 he weiterer Fälle, in denen ein Interesse, evtl. sogar beider Parteien, am Quellcode und dessen „Befundsicherung“ besteht. So kann etwa Streit darüber entstehen, wann die Software sich in welchem Zustand mit welchen Eigenschaften befunden hat, etwa dann, wenn die mangelbehaftete Version beim Kunden angeblich durch dessen Änderungen entstanden ist.

1 Zum Überblick unter KO s. Gesper, CR 1989, 8; zu Lizenzen unter InsO s. Cepl, NZI 2000, 357; Wallner, NZI 2002, 70; Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software, Wien 2002; zur Software in der Insolvenz s. Paulus, CR 2003, 237, und Graef, ZUM 2006, 104; zu BGH v. 26.3.2009 – I ZR 153/06, GRUR 2009, 946 – Reifen Progressiv – s. Dieselhorst, CR 2010, 90, und zur Fortführung durch BGH v. 19.7.2012 – I ZR 70/10, CR 2013, 572 – M2Trade – und v. 19.7.2012 – I ZR 24/11, CR 2012, 575 – Take Five – s. Berger, ZInsO 2013, 569; Seegel, CR 2013, 205; zur Reform s. Wimmer, ZIP 2012, 545; DGRI, CR 2012, 216, und unten Rz. 178. S.a. unten Rz. 53 ff, 56 ff. 2 LG Mannheim CR 2003, 811 und dazu unten Rz. 115 ff. 3 Zur evtl. Folge der Verpflichtungen zur Notfallplanung, Escrow zu vereinbaren, s. Steger, CR 2007, 137, sowie BSI M 6.137 Treuhänderische Hinterlegung (Escrow), bsi.bund.de. 4 S. Dujardin/Lejeune, ITRB 2011, 136 (139). 5 S. Dujardin/Lejeune, ITRB 2011, 136 (139). 6 S.a. Deville, NJW-CoR 1997, 108; zur Unbrauchbarkeit von Software ohne Quellcode s. z.B. OLG Frankfurt ECR OLG 195 (i.V.m. § 396 BGB a.F.), zum Bedarf am Quellcode s. BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 und dazu auch sogleich unten unten Rz. 16 ff.

Schneider

1049

L Rz. 8

Einzelprobleme

8

Viele Anbieter sehen in ihren AGB vor, dass die „Gewährleistung“ entfällt, wenn der Kunde Änderungen an der Software vornimmt. Diese Klausel ist höchst problematisch, weil sie ein Änderungsrecht zugunsten des Kunden im Rahmen AGB-rechtlicher objektiver Auslegung ergibt bzw. impliziert1. Sie wird andererseits hinsichtlich des Mängelhaftungsausschlusses nicht wirksam sein, weil dem Anwender der Entlastungsbeweis verweigert wird. Immerhin zeigt sich hier aber die Problematik.

9

In einem ähnlichen Sinne, nämlich für Beweisfragen, könnte eine Rolle spielen, in welchem Zustand wer wann die Software bereits angefertigt hatte, wenn es darum geht, wer Urheber und Miturheber ist bzw. welche Weiterentwicklungen stattgefunden haben. Durch eine Art Genealogie der Softwarestände kann dies unter Zuhilfenahme weiterer Informationen evtl. geklärt werden.

10 Ähnliche Überlegungen können bei einem Projekt eine Rolle spielen, bei dem der Auftraggeber mit Arbeiten an der Software unmittelbar mitwirkt. Um die Y-förmige Vergabelung (Forking) und somit Entstehung neuer Versions-Entwicklungsrichtungen durch Entwicklung divergierender Versionen möglichst zu vermeiden bzw. deren Probleme zu kompensieren, kann es sich empfehlen, dass stets sowohl der „Originalquellcode“, wie ihn der Hersteller laufend ergänzt, festgehalten wird, als auch die Anpassungen, die im Team vorgenommen werden. Dies gilt insbesondere dann, wenn die eigentliche Entwicklungsabteilung nicht vor Ort tätig ist, sondern evtl. sogar im Ausland (Offshore). Jedenfalls wird der Auftraggeber darauf zu achten haben, dass er den Quellcode der gesamten Software aktuell inkl. aller Änderungen und Updates erhält (s.a. Rz. 43 ff.). 11 Auch beim Zurücksetzen auf alte Versionen, etwa weil die neue zu mangelbehaftet ist, können Arbeiten erforderlich werden, die eine vorherige Befundsicherung ebenso sinnvoll machen wie bei Übergabe zur Abnahme bzw. Inbetriebnahme – etwa nach Änderungen oder Ergänzungen, Portierungen u.Ä.2. 12 Das typische Interesse des Kunden dürfte aber die Absicherung dafür sein, eine Investition in die Software getätigt zu haben, die nicht nur aus der Beschaffung der Software selbst, sondern auch deren Anpassung, dem Umstellungsaufwand, der Schulung der Mitarbeiter, den Reisekosten u.Ä. besteht, was u.U. ein Vielfaches der Softwarebeschaffung selbst ausmachen kann. Diese Investition will der Kunde schützen. Er will die Software auch dann noch gebrauchstauglich erhalten können, wenn der Auftragnehmer diese Aufgabe nicht (mehr) wahrnimmt. Typische Fälle in diesem Zusammen-

1 S.a. OLG München v. 27.10.1987 – 13 U 2458/86, CR 1988, 378. 2 S. zu Folgen mangelnder Befundsicherung im non liquet Fall: BGH v. 2.7.1996 – X ZR 64/94, MDR 1997, 26 = CR 1996, 663.

1050

Schneider

Hinterlegung von Software, Escrow

Rz. 17

L

hang waren das Jahr-2000-Problem sowie die Euro- und Postleitzahlenumstellung1. In manchen Teilen der IT-Branche ist es üblich, dass der Kunde den Quell- 13 code zumindest zu erheblichen Teilen mitgeliefert bekommt. Der Rest, ein kleiner „Kern“, wird dann z.B. hinterlegt. In manchen Bereichen ist es üblich, den gesamten Quellcode nicht herauszugeben, aber zu hinterlegen. Ebenso gibt es aber auch Bereiche, in denen die Auftragnehmer sich scheuen, überhaupt etwas vom Quellcode herzugeben. Insofern kann wohl von einer Branchenübung kaum die Rede sein2. Als Mittelweg hat sich im Laufe der Zeit, vor allem aus UK und USA3 kom- 14 mend, die sog. Hinterlegung des Quellcodes als Geschäftsmodell entwickelt und zwar insbesondere dann, wenn die einfache Konstruktion, den Quellcode dem Kunden zu übergeben, der ihn seinerseits aber bei sich verschließt und nur im Notfall herausholt, nicht akzeptiert wird. Die Einschaltung eines Dritten kann auch insofern zusätzliche Vorteile bie- 15 ten, als selbst bei direkter Übergabe des Quellcodes an den Kunden nicht sichergestellt ist, dass dieser Quellcode die Leistungen erbringt, die sich der Kunde erhofft. Insofern treffen die Hinterlegungsfirmen auch Vorkehrungen dafür, die Identität des Quellcodes und ggf. auch dessen Qualität, also vor allem die Kompilierbarkeit, festzustellen (sog. Verifikation). 2. Rechtsprechungsentwicklung Aufgrund einer BGH-Entscheidung vom 30.1.1986 ging die Rechtsprechung 16 davon aus (einzige Ausnahme war für längere Zeit LG München I), dass eine Mitlieferung des Quellcodes auch bei voller Bezahlung und auch dann, wenn der Auftraggeber eigentlich Anspruch auf die Unterlagen hat, nicht geschuldet ist, wenn die Herausgabe an den Auftraggeber nicht ausdrücklich geregelt ist4. Diese Meinung ist evtl. im Wandel begriffen, wie die folgenden Beispiele zeigen. Um den Umfang auch der Quellcodeleistung zu erfassen, sollte man den 17 Gebrauch, den man davon machen will, beschreiben. Dies hat eine Doppel1 Zu Jahr 2000 OLG Nürnberg v. 5.12.2003 – 5 U 2546/02, CR 2005, 260; LG Köln v. 16.10.1997 – 83 O 26/97, CR 1999, 218; zu Eurofähigkeit OLG Köln v. 21.3.2003 – 19 U 112/01, K&R 2003, 613. 2 A.M. LG Aschaffenburg v. 16.12.1997 – 1 O 354/93, CR 1998, 203, und wieder wesentlich restriktiver: BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490, und dazu Hoeren, CR 2004, 721. 3 Zu Escrow unter US-Recht s. Kochinke/Fraune, CR 1992, 7; zur Entwicklung in Deutschland s. Lensdorf, CR 2000, 80; Kast/Meyer/Wray, CR 2002, 379; Siegel, CR 2003, 941; Kast/Meyer/Peters, CR 2004, 147. 4 BGH v. 30.1.1986 – I ZR 242/83, MDR 1986, 910 = CR 1986, 377; a.M. LG München I v. 18.11.1988 – 21 O 11130/88, CR 1989, 990 m. Anm. Malzer = DB 1989, 973.

Schneider

1051

L Rz. 18

Einzelprobleme

funktion. Zum einen erstrecken sich dann bestimmte Nutzungsrechte auch auf den Quellcode, zum anderen wird auch der Umfang dessen, was herauszugeben ist, klar. 18 Man kann also zusätzlich zur Beschreibung der Unterlagen mit aufnehmen, dass der Quellcode mit Beschreibung in einer Art herauszugeben ist, die den Auftraggeber in die Lage versetzt, selbst die Software zu pflegen, weiter zu entwickeln, zu verbessern und mit anderer Software zu verbinden sowie solche Leistungen gegenüber dem Auftraggeber zu erbringen. 19 Damit ist noch nicht genau geregelt, was wann herauszugeben ist. Es wäre jedoch innerhalb eines relativ breiten Spektrums Fachleuten klar, was erforderlich ist. Notfalls ist dies mit einem Sachverständigengutachten festzustellen. 20 Besser wäre es, den Quellcode hinsichtlich Umfang und Version(en), seine Ausgestaltung (Muster) und den Grad an Kommentierung sowie die gegenständlichen Repräsentationen (Datenträger, Listen) zwecks Bestimmtheit auch für evtl. Titel genau zu beschreiben. Dies geschieht aber häufig nicht oder nur unzureichend. 21 In der Folge ist streitig, ob die Herausgabe des Quellcodes vom Anwender verlangt werden kann: – Dass bei Standardanwendungssoftware grundsätzlich kein Anspruch auf Herausgabe des Quellcodes besteht, dürfte wohl weitgehend herrschende Meinung sein. Andererseits kommt eine solche Herausgabe in Betracht, wenn spezielle Vereinbarungen zwischen den Parteien getroffen sind, die über die Überlassung hinausgehen, so insbesondere eine Art unentgeltlicher Pflege im Rahmen einer Pilotanwendung. Nach Meinung des OLG München kann der Kunde weder als vertragliche Leistung noch als Schadensersatz die Herausgabe des Quellenprogramms bzw. entsprechende Informationen verlangen1. – Ausdrücklich setzt sich die Entscheidung von der des LG München I, die allerdings nicht die vorausgehende Instanz war, ab. Das LG München I hatte entschieden, dass der Vertrag über die Erstellung von Individualsoftware auch die Pflicht des Erstellers zur Herausgabe des Quellcodes nebst Herstellerdokumentation enthält und zwar „wenn Anwender und Ersteller keinen langfristigen Wartungsvertrag geschlossen haben, die Gewährleistungsfrist abgelaufen ist und eine Fehlerbeseitigung durch Dritte erforderlich wird“2.

Das LG München hat sich also sehr detailliert mit der BGH-Entscheidung vom 30.1.19863 auseinandergesetzt und gerade die Andersartigkeit des konkreten Falls gegenüber dem dort entschiedenen herausgearbeitet. Die drei Kriterien (kein Wartungsvertrag, Gewährleistungsfrist abgelau1 OLG München v. 16.7.1991 – 25 U 2586/91, CR 1992, 208. 2 LG München I v. 18.11.1988 – 21 O 11130/88, CR 1989, 990 (LS). 3 BGH v. 30.1.1986 – I ZR 242/83, MDR 1986, 910 = CR 1986, 377.

1052

Schneider

Hinterlegung von Software, Escrow

–

–

–

–

–

–

Rz. 21

L

fen und Fehlerbeseitigung durch Dritte) erscheinen auch als wesentliche Merkmale für Regelungen bei der Herausgabe des Quellcodes im Rahmen von Escrow-Verträgen1. Der Gedanke dahinter ist, dass sich der Kunde auf andere Weise nicht helfen kann. Mehr als Randüberlegung hatte das LG Saarbrücken die Frage gestellt, ob bei voller Vergütung und Nicht-Übernahme einer Pflegeverpflichtung eine Herausgabepflicht für den Quellcode besteht, über die aber im konkreten Fall nicht entschieden wurde2. Nach altem Recht kam vor allem i.V.m. § 326 BGB a.F. ein Schadensersatzanspruch bei abgebrochenem Projekt in Betracht, wenn weder die geeignete Dokumentation noch der Quellcode in einer Weise übergeben wurden, dass der Kunde damit etwas anfangen konnte. Es bestand also keine Vergütungspflicht, wenn der Kunde mit dem, was er erhalten hatte, mangels Quellcode und/oder Dokumentation nichts anfangen konnte3. Eine der ersten Entscheidungen, die sich ähnlich wie das LG München positiv zur Herausgabe äußerten, stammt vom LG Aschaffenburg. Danach soll die Herausgabe des Quellcodes bei Software-Erstellung bzw. individuell für den Auftraggeber erstellter Software zwecks weiteren Absatzes „der Regelfall“ sein. Dieses Interesse „zwecks weiteren Absatzes“ wird in der BGH-Entscheidung vom 16.12.2003 akzeptiert und aufgewertet4, reicht aber allein nicht. Aus den Umständen des Vertrags kann sich im Übrigen auch schon ergeben, dass die Bearbeitungsmöglichkeit nicht nur rechtlich, sondern auch technisch/physisch Vertragsbestandteil bzw. Vertragsgrundlage ist. Insofern hat das OLG Karlsruhe entschieden, dass der Quellcode Teil der vereinbarten Wartungsdokumentation ist5. Auch ohne besondere Vereinbarung ist bei einem Vertrag zur Einstellung von Fremdsoftware eines Drittherstellers der Quellcode vom Auftragnehmer mitzuliefern6. Der Ausschluss einer Herausgabepflicht hinsichtlich des Quellcodes in AGB ist wirksam7.

1 S. auch unten Rz. 79 ff. 2 OLG Saarbrücken ECR OLG 173. 3 OLG Frankfurt ECR OLG 195 mit falscher Anmerkung/Überschrift (es ging um Schadensersatzansprüche bei abgebrochenem Projekt). 4 LG Aschaffenburg v. 16.12.1997 – 1 O 354/93, CR 1998, 203 = CI 1998, 49: Die Herausgabe des Quellcodes ist bei Software-Erstellung bzw. individuell für den Auftraggeber erstellter Software zwecks weiteren Absatzes „der Regelfall“ (sehr problematisch, restriktiver: BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490); s. auch Rz. 23. 5 OLG Karlsruhe CR 1999, 11: Quellcode ist als Teil der vereinbarten WartungsDokumentation mitgeschuldet (problematisch). 6 OLG Karlsruhe v. 16.8.2002 – 1 U 250/01, CR 2003, 95: s. kritisch J. Schneider, CR 2003, 317. 7 LG Köln v. 15.4.2003 – 85 O 15/03, CR 2003, 484.

Schneider

1053

L Rz. 22

Einzelprobleme

– In der Entscheidung vom 16.12.2003 hat sich der BGH etwas stärker als nur zur Abhängigkeit von den Umständen des Einzelfalles geäußert, indem er zwei Kriterien herausgearbeitet hat, die wahrscheinlich kumulativ vorliegend zur Herausgabepflicht für den Quellcodes führen, auch wenn sonst nichts Besonderes vereinbart ist: – für Vermarktung durch Besteller zu erstellende Software, der für Entwicklung und Wartung den Quellcode braucht; – Höhe des Werklohns1. 22 Mit der Herausgabepflicht iS eines vertraglichen Anspruchs nicht zu verwechseln ist ein Besichtigungsanspruch des Verletzten im Rahmen von Verfahren, bei denen sich der Verletzte nicht anders helfen kann, als die Vorlage des Quellcodes zu verlangen. In diesem Zusammenhang hat der BGH klargestellt, dass die strengen Anforderungen an die Wahrscheinlichkeit der Verletzung, wie sie im Patentverfahren galten bzw. gelten, für den Urheberrechtsprozess nicht einschlägig sind2. 23 Die BGH-Entscheidung vom 16.12.2003 brachte insofern einen Fortschritt, als besondere Voraussetzungen – kumulativ – auch nach Meinung des BGH dazu führten, dass der Quellcode herauszugeben ist3. 3. „Hinterlegung“, Begriff 24 Seit längerer Zeit wird in USA und England, wahrscheinlich auch in anderen Ländern dieses Rechtskreises, der Begriff Escrow für die Hinterlegung des Quellcodes bei einem Dritten verwendet4. In Frankreich sind (inzwischen) „Hinterlegungsvereinbarungen bei Verträgen über Individualsoftware (anders bei Standardsoftware) absolut üblich, zumal (dort) keine Klarheit darüber besteht, ob der Unternehmer dem Auftraggeber bei der Erstellung von Individualsoftware den Source Code herausgeben muss, sofern der Vertrag keine Regelung enthält“5. 25 In Deutschland ist der Begriff der Hinterlegung einerseits recht plastisch dafür verwendet worden, führt aber andererseits in die falsche Richtung, weil damit im Rahmen der §§ 372 ff. BGB und der Hinterlegungsordnung (HintO) eine bestimmte Vorgehensweise verbunden ist6.

1 BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490. 2 BGH v. 2.5.2002 – I ZR 45/01, MDR 2003, 167 = CR 2002, 791 und dazu J. Schneider, CR 2003, 1. S.a. BGH v. 20.9.2012 – I ZR 90/09, CR 2013, 284 – UniBasic – IDOS zur Herausgabe bei nur teilweiser Übernahme. 3 Vor allem die Weiterbearbeitung bzw. -pflege durch den Kunden und die Höhe der Vergütung, BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490 und dazu Hoeren, CR 2004, 721. 4 S. z.B. Kast/Meyer/Wray, CR 2002, 272, und Kast/Meyer/Peters, CR 2004, 147. 5 Dujardin/Lejeune, ITRB 2010, 136 (139). 6 S. auch Roth zur andersartigen Bedeutung, ITRB 2005, 283.

1054

Schneider

Hinterlegung von Software, Escrow

Rz. 31

L

Um dieses förmliche Verfahren handelt es sich gerade nicht. Es geht auch 26 nicht um die Hinterlegung zu Sicherungszwecken. Am nächsten kommt wohl die Hinterlegung beim Notar. Aber auch diese ist keine Hinterlegung im Sinne der §§ 372 ff. BGB. Grundsätzlich wird der Notar seinerseits nur auf durch Urkunden zu belegende Herausgabefälle reagieren (können). Das bedeutet, dass andere Fälle als Insolvenz oder Löschung aus dem Handelsregister schwerlich bei einer Notarhinterlegung berücksichtigt werden könnten, so etwa End-of-Life der Software, Kündigung der Pflege, Einstellen des Geschäftszweigs beim Softwarehaus oder Verweigerung einer für den Kunden betriebsnotwendigen Ergänzung/Änderung auch gegen angemessene Vergütung. Der Nutzen für den Anbieter besteht darin, dass er sicher sein kann, dass 27 der Kunde den Quellcode körperlich noch nicht in Händen hält, solange nicht einer der genau zu bestimmenden Herausgabefälle eintritt. Der Nutzen für den Kunden besteht darin, dass er seine Investition nicht 28 nur im Hinblick auf Insolvenz des Anbieters bzw. Herstellers sichert, sondern auch für andere Fälle vorbauen kann (geeignete Regelungen vorausgesetzt), wie z.B. Outsourcing an einen Dritten1, eigene Pflegeverpflichtungen gegenüber dem Kunden als Händler2. 4. Grundschema der Vertragsbeziehungen Das Grundschema der Vertragsbeziehungen lässt sich wie folgt skizzieren: Es gibt einen Anbieter/Lieferanten/Unternehmer, der Software an den Kunden (als Besteller/Auftraggeber/Käufer) zu liefern oder schon übergeben hat. Dieser wird unter Escrow-Aspekten meistens als Lizenzgeber bezeichnet.

29

Der Empfänger dieser Leistungen, also der Kunde, hat mit diesem Lizenzgeber einen Vertrag, der unter Aspekten des Escrow als „Lizenzvertrag“ gesehen wird und der den Kunden als Lizenznehmer sieht bzw. bezeichnet. Damit ist noch nicht gesagt, ob insoweit Kauf oder Miete (oder sogar Werkvertrag) vorliegt. Dieser meist vorgängige Beschaffungsvertrag wird auch „Überlassungsvertrag“ genannt3.

30

Auch diese Bezeichnung besagt aber noch nichts über den Vertragstyp, vor 31 allem nicht, ob Kauf oder Miete vorliegt. Der Vorzug der „Überlassung“ ist jedoch, dass sie weiter zu sein scheint als „Lizenz“ und vor allem auch die Varianten der Anpassung bzw. der angepassten Software und auch der Erstellung der Software umfassen kann. Auch signalisiert die Bezeichnung schon, dass dem Kunden etwas übergeben wird, wie auch immer dies genau bezeichnet wird, und nicht nur „Rechte“ eingeräumt werden. 1 S. z.B. Fritzemeyer/Schoch, CR 2003, 793. 2 Was auch eine Dachorganisation oder ein Dienstleister sein kann, der seine Filialen, Handelsvertreter, Zulieferer usw. versorgt. 3 S. etwa Oberscheidt, Die Insolvenzfestigkeit der Softwarehinterlegung, Münster 2002, S. 11 unter Hinweis auf Marly, Softwareüberlassungsverträge.

Schneider

1055

L Rz. 32

Einzelprobleme

32 Der Escrow-Agent kommt als Dritter bei der Escrow-Vereinbarung ins Spiel1. D.h., dass die beiden Vertragspartner, Lizenznehmer und Lizenzgeber, einen bilateralen Vertrag geschlossen haben, was den Beschaffungsvertrag betrifft, und nun ein neuer, weiterer Vertragspartner hinzutritt. In der Grundkonstruktion hat der Escrow-Agent jeweils einen vollständigen, gleichlautenden Vertrag mit jedem der beiden Partner, Lizenzgeber und Lizenznehmer. Der Vertrag enthält sowohl seine Rechte und Pflichten gegenüber dem Lizenzgeber als auch gegenüber dem Lizenznehmer. Diese doppelte Vertragsbeziehung wird häufig als „Doppeltreuhand“ gesehen, wobei die Voraussetzung natürlich wäre, dass überhaupt eine Treuhand vorliegt2 33 Dieses Grundschema wird nun gelegentlich variiert. Diese Variationen spielen grundsätzlich keine allzu große Rolle; die Ausnahme bildet der zentrale Punkt der Insolvenz eines der beiden Vertragspartner, wobei die Insolvenz des „Lizenzgebers“ besonders gefährlich ist. 34 Vorweg sei noch bemerkt, dass diese Grundkonstruktion und die Einzelheiten des Escrow-Vertrags nicht zu einer zusätzlichen Rechtsposition des Lizenznehmers führen müssen bzw. führen sollen. Das bedeutet, dass grundsätzlich die Befugnisse des Lizenznehmers für den Fall etwa, dass er den Quellcode heraus erhält, bereits im Beschaffungsvertrag (auch beim „System-Vertrag“ mit Anpassung des Standards; s.a. Rz. 10) niedergelegt sein sollten. Dem entspricht es natürlich nicht, wenn im Beschaffungsvertrag lediglich steht, dass die Vertragspartner noch zusätzlich einen Escrow-Vertrag schließen werden. 5. Variante: Hinterlegung für eine Vielzahl noch unbekannter Kunden 35 Die Variante in die eine Richtung ist, dass der Lizenzgeber zunächst seinen Escrow-Vertrag mit dem Escrow-Agenten schließt, ohne überhaupt einen entsprechenden Beschaffungsvertrag, auf den dies projiziert wäre, mit einem Lizenznehmer abgeschlossen zu haben. Diese Hinterlegung erfolgt also sozusagen vorsorglich. Die Idee ist, dass beliebig hinzutretende Lizenznehmer, die in Zukunft Lizenzverträge mit dem Lieferanten/Hinterleger schließen, an dieser Hinterlegungsvereinbarung partizipieren. Diese Variante hat mehrere Besonderheiten. Zum einen dürfte in der Regel der Quellcode nur einmal für die jeweilige Ausprägung/Version beim Escrow-Agenten hinterlegt sein. Das bedeutet, dass der Escrow-Agent ein Vervielfältigungsrecht benötigt, um ggf. einzelne Kunden/Lizenznehmer bedienen zu können. Des Weiteren bedeutet dies, dass die Kopie des Quellcodes, die für einen einzelnen Kunden bestimmt wäre, noch nicht aus- bzw. abgesondert wäre. Man

1 Zu den Konstellationen s.a. Auer-Reinsdorff/Kast, Software-Escrow, in: AuerReinsdorff/Conrad (Hrsg.), IT-Recht, 2011, § 10 Rz. 35 ff. 2 Zur Treuhand bzw. zur Doppeltreuhand beim Quellcode s. Hoeren, CR 2004, 721 (i.V.m. BGH v. 16.12.2003 – X ZR 129/01, CR 2004, 490) und unten Rz. 74 ff.

1056

Schneider

Hinterlegung von Software, Escrow

Rz. 38

L

kann allerdings vorsehen, dass diese Absonderung bereits in dem Moment hergestellt wird, in dem sich ein Kunde dem Abkommen anschließt. Typisch ist diese Variante für den Fall eines Vertriebs von Standardsoftware 36 mit einer Vielzahl von noch unbekannten Kunden, denen als Vorteil der Escrow-Vertrag mit angeboten wird. Zu den Kunden können auch Vertragshändler gehören, die sich der Forderung der Herausgabe des Quellcodes seitens ihrer Kunden ausgesetzt sehen. Dafür bietet es sich an, den Endkunden die Möglichkeit zu geben, ggf. den Escrow-Vertrag direkt mit dem Hersteller/Lizenzgeber zu schließen1 bzw. ihnen die Berechtigung zu geben, dem vom Lizenzgeber angebotenen Abkommen beizutreten. 6. Variante: Hinterlegung durch den Kunden Die andere Variante ist, dass der Kunde die Software vom Lieferanten auch 37 im Quellcode erhält, d.h. insbesondere bei Individualanpassung und -erstellung von Software, aber auch bei Standardsoftware eine Kopie des Quellcodes und diese ihm, dem Kunden, zu Eigentum übergeben wird. Er hat daran auch bestimmte, im Beschaffungsvertrag näher geregelte Rechte. Eine solche Gestaltung wünscht der Auftraggeber naturgemäß in solchen Fällen (etwa auch für die Zwecke weiterer Pflege auch gegenüber Dritten), wenn er die Software seinerseits weiter vertreiben will. Das Besondere ist, dass sich in diesem Fall der Kunde im Beschaffungsvertrag gegenüber dieser sehr umfassenden dinglichen Position schuldrechtlich beschränkt und im Grunde genommen eine Situation herstellt, die der Einlagerung des Quellcodes im Tresor entspricht, nur mit dem Unterschied, dass ein Dritter die Verwahrung und Herausgabe übernimmt, was wiederum die Überwachung für den Lizenzgeber erleichtert. Interessant an dieser Konstruktion ist, dass zumindest hinsichtlich des je- 38 weils bestimmten Softwarestands sämtliche erforderlichen Leistungen bereits erfüllt sind und, wenn die Vertragskonstruktion dies hergibt, auch durch die entsprechenden Zahlungen abgedeckt sind. Es ist auf den ersten Blick völlig klar, dass die erste Variation insolvenzrechtlich eher problematisch, die letzte insolvenzrechtlich eher unproblematisch erscheint. Damit ist schon das Hauptthema des Escrow-Vertrags angesprochen, nämlich das Problem der Insolvenz.

1 S.a. zu einem anderen Vorschlag für Vertragshändler Bischof/Witzel in: Redeker (Hrsg.), Handbuch der IT-Verträge, 2.3 Vertragshändlervertrag Software, Rz. 175: Der Vertrag wird mit dem Händler abgeschlossen, wenn dies bei Forderungen der Endkunden notwendig wird.

Schneider

1057

L Rz. 39

Einzelprobleme

II. Insolvenzfestigkeit und Kündbarkeit des Beschaffungsvertrags 1. Einführung 39 Typischerweise wird mit Escrow/Hinterlegung als wesentliche Gefahr, der zu begegnen ist, Insolvenz in Verbindung gebracht. Der Test, ob sich Escrow lohnt, scheint die Insolvenzfestigkeit zu sein. Dies verkennt, dass es eine Vielzahl von Gründen gibt, die ebenfalls eine Hinterlegung ratsam erscheinen lassen, etwa projektbegleitend zur Absicherung vielleicht sogar beider Vertragspartner, bei Kooperationen, für Beweisfragen u.Ä. Dennoch ist unbestreitbar, dass der typische Fall, bei dem die Softwarehinterlegung in der Praxis als hilfreich erachtet wird, die Insolvenz vornehmlich des Lizenzgebers/Auftragnehmers ist. Gleichzeitig ist dies der Punkt, der bei einer Hinterlegungsvereinbarung die meisten Schwierigkeiten bereitet. 40 Hintergrund ist, verkürzt gesagt, dass es sich bei der Hinterlegungsvereinbarung nicht etwa um eine Vorausverfügung oder „Lösungsklausel“ (nur) für den Insolvenzfall handeln darf. Tatsächlich aber achten viele Vertragspartner nicht oder erst zu spät darauf, dass genau die Art, wie sie die Hinterlegung vereinbart und gehandhabt haben, diesen Eindruck der Vorausverfügung oder der Lösungsklausel erweckt. Dies hängt damit zusammen, dass zunächst einmal ein Vertrag praktisch ohne Quellcodevereinbarung geschlossen wird und man erst später daran denkt, eine gesonderte Vereinbarung hierzu zu schließen. Dann passen die beiden Vereinbarungen häufig insbesondere hinsichtlich der Rechtseinräumung (Bearbeitungsrecht erst in der Escrow-Vereinbarung), Vergütung (nicht auf den Quellcode erstreckt) und vor allem Kündbarkeit nicht zusammen. 2. Wesentliche Voraussetzungen 41 Eine der wesentlichen Voraussetzungen, dass Escrow im Hinblick auf eine Insolvenz des Softwarehauses wirksam ist, ist die Deckungsgleichheit des Vertragstyps mit der Voraussetzung, dass die Rechtseinräumung unbedingt zu erfolgen hat und nicht Unentgeltlichkeit vorliegt, was die Rechte an dem Quellcode betrifft. 42 Die Unbedingtheit der Rechtseinräumung entspricht der bei den meisten Softwareüberlassungsverträgen vorliegenden vertragstypologischen Einordnung in das Kaufrecht. Die dauerhafte Nutzungsrechtseinräumung steht dabei meist gar nicht so sehr im Vordergrund wie die Charakteristik als „Erwerb“, allerdings nur der Kopie der Software. Es kann sich aber, und dies ist im Hinblick auch auf die Teilbarkeit des Quellcodes wichtig, insoweit auch um eine Kopie des Quellcodes, also jeweils um dessen Vervielfältigungsstücke handeln, ohne dass dadurch in irgendeiner Weise die Substanz beim rechtseinräumenden Unternehmen geschmälert wäre. Allerdings ist richtig, dass diejenigen Kunden, die über den Quellcode verfügen, theoretisch in die Lage versetzt werden, selbst Änderungen daran vorzunehmen. Hierzu sind sie allerdings auch ohne explizite Einräumung, was viele Insolvenzverwal1058

Schneider

Hinterlegung von Software, Escrow

Rz. 45

L

ter übersehen, allein schon auf Grund des Fehlerberichtigungsrechts1 und des Rechts zur Herstellung der Interoperabilität2 berechtigt, wenn nicht sogar – schlechte – AGB ihnen versehentlich noch weitere Nutzungsrechte gewähren (etwa über die Formulierung, dass bei Änderungen an der Software die Gewährleistung entfällt oÄ). 3. Gefährdung der dauerhaften Überlassung und Rechtseinräumung Die Endgültigkeit der Rechtseinräumung und damit der Erschöpfung wird al- 43 lerdings konterkariert durch die in vielen AGB festzustellende Unart, dem Lizenzgeber Kündigungsrechte für den Fall angeblicher Vertragsverletzung durch den Lizenznehmer zu gewähren. Die Verträge (auch Überlassung/Herstellung/Anpassung und Escrow) müssen also daraufhin untersucht werden, ob sie jeweils genügend klar die Unbedingtheit der Rechtseinräumung verbunden mit der Überlassung der jeweiligen Vervielfältigungsstücke ergeben, ohne dass überhängende bzw. „offene“ weitere Pflichten bestehen, die eher zu einer Einordnung als Dauerschuldverhältnis führen würden. Auch ohne vertragliche Regelung einer Kündigungsmöglichkeit (die bei 44 Kauf AGB-rechtlich höchst problematisch bzw. unwirksam ist) ist zu bedenken, dass auch bei „klassischen“ Software-Erstellungsverträgen, die als Werkvertrag qualifiziert werden (und nicht über § 651 BGB kaufrechtlich beurteilt werden)3, eine Kündigungsmöglichkeit bereits vom Gesetz her unmittelbar vorgesehen ist, und zwar für den Besteller gemäß § 649 Abs. 1 BGB – jederzeit möglich4 – und für den Auftragnehmer unter den Voraussetzungen der §§ 642, 643 BGB. Daneben besteht auch das Kündigungsrecht aus wichtigem Grund nach § 314 BGB. Bei Dienstverträgen hätte § 626 BGB wohl Vorrang gegenüber § 314 BGB und besteht eine Möglichkeit ordentlicher Kündigung auch ohne explizite Regelung, § 620 BGB. Die Kündigungsmöglichkeiten aus dem Werkvertrag und auch aus § 314 45 BGB beziehen sich vor allem auf die Fälle bzw. die Konstruktionen, bei denen unmittelbar Werkvertragsrecht Anwendung findet. Typischerweise handelt es sich hierbei um einen Vertrag, dessen Schwerpunkt die immaterielle Leistung bildet. Dies ist wiederum typisch für die Anpassungsprojekte. Infolgedessen stellt sich dort vor allem auch die Frage, wie dauerhaft die Überlassung der zugrundeliegenden (Standard-)Software erfolgt. Insoweit besteht das Kündigungsproblem in zweifacher Hinsicht: – für den Anpassungsvertrag als Werkvertrag und – für den Überlassungsvertrag, der möglicherweise als Kaufvertrag ausgeprägt ist. 1 Gemäß § 69d Abs. 1 UrhG; Fehlerbeseitigung gehört zum bedingungsfesten Kern: BGH v. 24.2.2000 – I ZR 141/97, CR 2000, 656. 2 Gemäß § 69e UrhG. 3 S. oben Kap. B Rz. 1 ff. 4 S.a. BGH v. 27.1.2011 – VII ZR 133/10, CR 2011, 176; BGH v. 5.5.2011 – VII ZR 161/10, CR 2011, 639 und BGH v. 28.7.2011 – VII ZR 45/11.

Schneider

1059

L Rz. 46

Einzelprobleme

4. Abstraktionsprinzip 46 Für beide Verträge kommt aber noch eine Variante hinzu, die sich speziell an den Rechtseinräumungen (und eigentlich nicht an den zugrundeliegenden Hauptverträgen) orientiert. Die Frage ist, was im Fall einer Kündigung nach den vorstehend aufgezeigten Möglichkeiten mit den Rechten, die dem Kunden/Besteller zustehen, passiert. Die Gefahr, insbesondere im Hinblick auf Escrow, ist, etwa bei projektbegleitender Hinterlegung der verschiedenen Versionsstände, dass eine Art automatischer Rückfall nach § 9 Abs. 1 VerlG greift (analog)1. 47 Mit guten Argumenten hat Hoeren hierzu Bedenken angemeldet und begründet. Auch er stellt darauf ab, dass eine dauerhafte Überlassung an den Kunden/Besteller gewollt ist, wofür auch die Pauschalvergütung ein Indiz ist (im Gegensatz etwa zu einer laufenden Lizenzgebühr). Dies ist wichtig, weil insoweit dann § 41 UrhG, Rückruf, für den IT-Projektvertrag nicht in Betracht kommt2. 48 Hoeren weist sodann nach, dass aufgrund des Abstraktionsprinzips eine Kündigung des Software-Erstellungsvertrags keine Auswirkungen auf die bereits übertragenen Nutzungsrechte hat3. 49 Diese Endgültigkeit der Überlassung wird von den Insolvenzverwaltern häufig übersehen. Bei nicht datenträger-basierter Überlassung dürfte die Kategorisierung als „Lizenz“, also die Reduzierung des Vertragsinhalts auf die Nutzungsrechtseinräumung, weiterhin vorherrschend sein. Die Einschätzung deren Charakters als „dinglich“ ist str., s.a. Kap. A Rz. 151. 50 Zudem ließe sich einwenden, dass solche Verträge, deren AGB selbst bereits ein Kündigungsrecht (zugunsten des Auftragnehmers) zumindest im Hinblick auf die zugrundeliegende Standardsoftware enthalten, keine endgültige Überlassung darstellen. 51 Soweit ersichtlich, wird hierbei der Vertragscharakteristik, wie sie sich nach einer AGB-rechtlichen Überprüfung zugunsten des Kunden ergibt, wenig Beachtung geschenkt. D.h., dass die Insolvenzverwalter eher die AGB auch hinsichtlich solcher Klauseln wörtlich nehmen, die unwirksam sind. Dabei ist zu beachten, dass bei der vertragstypologischen Einordnung zur Gewinnung der Referenz für die AGB-rechtliche Prüfung die Klauseln nicht

1 S. dazu insbesondere LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811 m. Anm. Grützmacher, S. 814 und dazu unten Rz. 138 ff. S. aber BGH v. 26.3.2009 – I ZR 153/06 – Reifen Progressiv, CR 2009, 767 und dazu Dieselhorst, CR 2010, 69, und v.a. Stöckel/Brandi-Dohrn, CR 2011, 553 zum dinglichen Charakter von Lizenzen; s.v.a. bezüglich Unterlizenzen nun BGH v. 19.7.2012 – I ZR 70/10, CR 2012, 572 und dazu Seegel, CR 2013, 205. 2 S. Hoeren, CR 2005, 773; s.a. Kap. A Rz. 78 ff. 3 Hoeren, CR 2005, 773, insbesondere in der Zusammenfassung, S. 777.

1060

Schneider

Hinterlegung von Software, Escrow

Rz. 53

L

mit berücksichtigt werden dürfen, die später der ABG-rechtlichen Überprüfung unterliegen1. Nicht zuletzt aufgrund der Diskussion im Anschluss an die BGH-Entschei- 52 dung v. 17.11.20052 mit unmittelbarer Relevanz für die insolvenzrechtliche Beurteilung von Lizenzverträgen, aber auch an die Entscheidung des BGH v. 15.11.20063, die damit nicht leicht in Einklang zu bringen ist, gab es eine Initiative des Bundesjustizministeriums mit dem Entwurf einer Neuregelung des § 108a InsO-E mit einer Kabinettsvorlage v. 22.8.2007. Der neue § 108a InsO-E sollte in etwa § 108 InsO nachgebildet werden und hätte praktisch die Insolvenzfestigkeit von Lizenzverträgen festgeschrieben. Diese war schon davor im Streit und ist es auch danach in erheblichem Maß geblieben. Der Entwurf wurde aber schließlich nicht weiterverfolgt. Im Rahmen eines Referentenentwurfs eines „Gesetzes zur Verkürzung des Restschuld-Befreiungsverfahrens, zur Stärkung der Gläubigerrechte und zur Insolvenzfestigkeit von Lizenzen“ wurde unter dem 18.1.2012 ein neuer Vorschlag vorgelegt. Danach wäre § 108a InsO nunmehr wesentlich näher an § 103 InsO orientiert. Dem Lizenznehmer stünde danach in kurzer Frist von einem Monat, nachdem ihm die Ablehnung der Erfüllung des Lizenzvertrags durch den Insolvenzverwalter zugegangen ist, das Recht zu, den Abschluss eines neuen Lizenzvertrags zu angemessenen Bedingungen für die weitere Nutzung des geschützten Rechts zu verlangen. Derzeit ist noch unklar, ob dieser neuerliche Vorschlag Gestalt annehmen wird. Interessant daran ist jedenfalls, dass nicht nur eine angemessene Vergütung (nach-)zu verhandeln wäre, sondern „angemessene Bedingungen“. Ob das Verfahren sehr praktikabel ist, kann bezweifelt werden – s.a. die Stellungnahme der DGRI4. Wesentlich praktischer erscheint, den Bestand der eingeräumten Rechte zu erhalten und ggf. nur Vergütung durch den Insolvenzverwalter nachfordern bzw. nachverhandeln zu lassen5. Es bleibt unklar, warum der Lizenznehmer anders bzw. schlechter gestellt 53 werden soll als der Mieter eines Objekts, obwohl dem Lizenznehmer quasidingliche Rechte bzw. sog. dingliche Rechte zustehen6. Ebenfalls unklar erscheint für die Konzeption des Entwurfs zu § 108a (2012), wie Kunden bei ASP bzw. SaaS uä. Providingverträgen gestellt bzw. geschützt werden können. Weiter ist nicht ganz klar, inwieweit der Gesetzgeber tatsächlich eine Parallele zu § 365(n) Bankruptcy Code (US BC) des amerikanischen Rechts schaf-

1 2 3 4 5 6

S. vor allem BGH v. 4.3.1997 – X ZR 141/95, MDR 1997, 913 = CR 1997, 470. BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151, s. dazu Rz. 114, 149 ff. BGH v. 15.11.2006 – XII ZR 120/04 – ASP –, CR 2007, 75; s. dazu Rz. 16, 82. CR 2012, 216. S. Stellungnahme der DGRI Brandi-Dohrn u.a., CR 2012, 216. S. Brandi-Dohrn, CR 2011, 553; Grützmacher, CR 2011, 485; s.a. Kap. A; BGH v. 19.7.2012 – I ZR 70/10, CR 2012, 572.

Schneider

1061

L Rz. 54

Einzelprobleme

fen kann bzw. wollte, nachdem nämlich dort gerade der Lizenznehmer ein entsprechendes Wahlrecht hat1. 54 Die Beurteilung dieses Vorschlages führt deshalb einerseits zu der ganz grundsätzlichen Frage nach dem Charakter solcher Lizenzen, die nicht als „Kauf“ zu qualifizieren sind oder sogar dann, wenn sie als Kauf gelten. In der Entscheidung Reifen Progressiv hatte der BGH entschieden, dass ein einfaches Nutzungsrecht, das sich von einem ausschließlichen Nutzungsrecht ableitet, nicht erlischt, wenn das ausschließliche Nutzungsrecht aufgrund eines wirksamen Rückrufs wegen Nichtausübung (§ 41 UrhG) erlischt2. Die Entscheidung Reifen Progressiv wird auch auf die Situation der Insolvenz des Lizenzgebers projiziert3, allerdings wohl eher im Sinne einer Ausnahme. Diese Entscheidung wäre dann auch für Vertriebssysteme und für die hier zu behandelnde Frage bei Escrow von entscheidender Bedeutung. Die Verfügung hinsichtlich Escrows bliebe von dem späteren Wegfall der Berechtigung des Verfügenden unberührt. 55 Eine Entscheidung des LG München I sah einfache Patentlizenzen bereits als insolvenzfest an, wenn die Rechtseinräumung auf Dauer und gegen Einmalentgelt erfolgte4. Damit wäre, angewandt auf Software, die typisch kaufrechtlich orientierte Konstruktion abgedeckt, was dafür spricht, auch die werkvertragliche Überlassung, Erfüllung vorausgesetzt, als insolvenzfest anzunehmen. Jedenfalls wäre bei Anpassungsprojekten die Standardsoftware-Lizenz insolvenzfest gestaltbar – auch ohne InsO-Änderung.

1 S.a. Lejeune zu In re Quimonda, Bankruptcy Court for the Eastern District of Virginia v. 28.10.2011 – Case No. 09-14766-SSM, CRI 2012, 26. 2 BGH v. 26.3.2009 – I ZR 153/06– Reifen Progressiv, GRUR 2009, 946; zu den Konsequenzen der Entscheidung s. Dieselhorst, CR 2010, 90; Scholz, GRUR 2009, 1107 (zum Wegfall der Hauptlizenz, dem BGH zustimmend). Zur Rezeption des BGH-Urteils s.a. OLG München v. 20.1.2011 – 29 U 4446/10, K&R 2011, 601, wo im Anschluss an die BGH-Entscheidung Reifen Progressiv festgestellt wurde, dass abgeleitete, und zwar einfache wie auch ausschließliche Nutzungsrechte die vorzeitige Beendigung des vorgelagerten Nutzungsrechts überdauern können. Inzwischen noch bestätigt und verstärkt („Fortführung“) durch BGH v. 19.7.2012 – I ZR 70/10, CR 2013, 572 – M2Trade – und v. 19.7.2012 – I ZR 24/11, CR 2012, 575 – Take Five, dazu PM des BGH: Der BGH „hat nunmehr entschieden, dass das Erlöschen der Hauptlizenz auch in den Fällen nicht zum Erlöschen der Unterlizenz führt, in denen der Hauptlizenznehmer dem Unterlizenznehmer ein einfaches Nutzungsrecht gegen fortlaufende Zahlung von Lizenzgebühren („M2Trade“) oder ein ausschließliches Nutzungsrecht gegen Beteiligung an den Lizenzerlösen („Take Five“) eingeräumt hat und die Hauptlizenz nicht aufgrund eines Rückrufs wegen Nichtausübung, sondern aus anderen Gründen erlischt – wie hier aufgrund einer wirksamen Kündigung des Hauptlizenzvertrages wegen Zahlungsverzugs („M2Trade“) oder aufgrund einer Vereinbarung über die Aufhebung des Hauptlizenzvertrages („Take Five“).“ 3 Weber/Hötzel, NZI 2011, 432. 4 LG München I v. 9.2.2012 – 7 O 1906/11, GRUR 2012, 377 (LS).

1062

Schneider

Hinterlegung von Software, Escrow

Rz. 56

L

5. Kriterien für Insolvenzfestigkeit mit Einbeziehung des Escrow-Agenten Bei den typischen Escrow-Verträgen ist auch der Escrow-Agent unmittelbar 56 in den insoweit dreiseitigen Vertrag, also gegenüber Lizenzgeber und -nehmer, eingebunden. Sicherer erscheint aber die Konstruktion, dass der Lizenzgeber nur dem Lizenznehmer endgültige Rechte einräumt und die Materialien zu Eigentum übergibt, der sie dann in Selbstrestriktion für sich hinterlegt1. Dies soll aber nicht notwendig sein, folgt man Wallner2. Dieser fasst seine Ausführungen zur Insolvenz des Urhebers im Hinblick auf den Zugriff des Nutzers auf den Quellcode wie folgt zusammen: – In der Hinterlegungsvereinbarung hat der Software-Ersteller der Hinterlegungsstelle ein gegenständliches einfaches Nutzungsrecht am Quellcode einzuräumen (unter Verweis auf Pagenberg/Geissler)3. – Diese Nutzungsrechtseinräumung soll dabei „unbedingt“ erfolgen, „um eine Insolvenzanfechtung auszuschließen“. – Eine „Trennungsklausel“ sollte in den Vertrag mit aufgenommen werden, damit weitere Pflichten des Softwareherstellers, z.B. die Einräumung von einfachen gegenständlichen Nutzungsrechten am Quellcode weiterentwickelter Versionen der überlassenen Software (einschließlich Pflegemaßnahmen), Berücksichtigung finden. Diese Trennungsklausel „sollte zum Inhalt haben, dass die Verpflichtungen zur Einräumung des einfachen gegenständlichen Nutzungsrechts am Ausgangsquellcode einschließlich der Übergabe des Quellcodes auf einem Datenträger ein rechtlich eigenständiges Schicksal im Verhältnis zu weiteren vertraglichen Pflichten haben“4. – Es ist für genügende Teilbarkeit des Gegenstands zu sorgen. Dies soll dem Fall vorbeugen, dass das Vertragsverhältnis zwischen Hinterlegungsstelle und Software-Hersteller „im Zeitpunkt der Eröffnung des Insolvenzverfahrens von beiden Teilen noch nicht vollständig erfüllt wurde“. Dann muss die Hinterlegungsstelle den Quellcode „nicht an den Verwalter herausgeben, wenn der Vertragsteil der Nutzungsrechtsüberlassung in Ansehung des Gesamtvertrags teilbar ist“5. Nach der Rechtsprechung des BGH6 werden die bereits erfüllten Vertragsteile bei teilbaren Verträgen nicht von der Insolvenzeröffnung berührt7.

1 Dazu näher unten Rz. 37 und v.a. Rz. 99. 2 Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software, S. 208 f. 3 Pagenberg/Geissler, Lizenzverträge, 1997, S. 622 mit § 8 des Vertragsmusters. 4 Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software, S. 208 m.w.N. 5 Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software, S. 208. 6 BGH v. 4.5.1995 – IX ZR 256/93, BGHZ 129, 336 ff. = MDR 1996, 161. 7 Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software, S. 208.

Schneider

1063

L Rz. 57

Einzelprobleme

– Der auf die Einräumung der Rechte am Quellcode entfallende Anteil am Gesamtentgelt sollte deshalb auch klar ausgewiesen werden und zuzuordnen sein. Somit wäre der Wert des Nutzungsrechts am Quellcode ausdrücklich zu beziffern. – Weiter ist wichtig, dass die Gestaltung und Einräumung des Nutzungsrechts für den Endkunden bereits mit Einräumung der entsprechenden Rechte an die Hinterlegungsstelle aus dem Vermögen des Schuldners ausscheidet1. 57 Diese Auffassungen Wallners waren durch die Entscheidung des LG Mannheim, die sich auf seine Darstellung in einem Aufsatz bezieht und unten näher behandelt wird, eher gefährdet. Obwohl die Rspr. sich wesentlich anders entwickelt hat, ist zu empfehlen, dass der Anwender unmittelbar vom Hersteller die entsprechenden Nutzungsrechte eingeräumt bekommt und nicht der Umweg über den Escrow-Agenten gegangen wird. Dieser ist gleichwohl einzuschalten, allerdings im Hauptpunkt durch den Anwender und nicht durch den „Lizenzgeber“2. Andererseits steht nun die Insolvenzfestigkeit von Tochterrechten auch für den Fall fest, dass die Hauptlizenz wegen Kündigung, insbes. bei ausstehender Vergütung, erlischt3.

III. Analyse der Konstruktion 58 Im Folgenden soll versucht werden, die Hinterlegung hinsichtlich möglicher vertraglicher Konstruktionen so darzustellen, dass sie auch den insolvenzrechtlichen Anforderungen genügt, also auch und gerade in diesem Kardinalfall wirksam helfen kann. 1. Maximen/Fragestellungen zum Rahmen a) Umfang 59 Der Praxistest, aber auch der Haltbarkeitstest für Escrow wird in der Praxis sein, dass stets klar ist, wo sich mit welchen Rechten das gesamte Material befindet. Ausdrücklich ist hier von „gesamtem Material“ die Rede und nicht nur einfach vom Quellcode. Mit dem Quellcode kann der Kunde – in der Regel ein Laie – kaum etwas anfangen. Er benötigt dazu zusätzliche An-

1 Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software, S. 209. 2 Im Hinblick auf LG Mannheim besonders wichtig, dazu unten Rz. 138 ff. (LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811). S. auch zu aufschiebender Bedingung Rz. 114, 149 ff. 3 S. im Anschluss an und in Fortführung von BGH v. 26.3.2009 – I ZR 153/06, GRUR 2009, 1107 – Reifen Progressiv, BGH v. 19.7.2012 – I ZR 70/10, CR 2013, 572 – M2Trade – und v. 19.7.2012 – I ZR 24/11, CR 2012 575 – Take Five; Berger, ZInsO 2013, 569; Seegel, CR 2013, 205.

1064

Schneider

Hinterlegung von Software, Escrow

Rz. 61

L

gaben, etwa die Quellcodekommentierung1, vielleicht sogar die Entwicklungsumgebung bzw. eine ganz spezielle Umgebung technischer Art. Wichtig ist im Hinblick auf evtl. Insolvenz, dass für einzelne Kunden nicht etwa der Quellcode, sondern eine Kopie, ggf. je Kunde eine einzelne, hinterlegt wird. Für den Insolvenzverwalter wiederum ist es im Hinblick auf die Verwertung wichtig, wenn der Quellcode als identifizierbares Gut behandelt werden kann, nicht etwa als Software wie sie auf „den … Rechnern steht und liegt“ (so das „Muster“, das ein Insolvenzverwalter verwendet). Es kann durchaus sein, dass der Quellcode zum einen nicht auf den Rechnern der Insolvenzschuldnerin „liegt“, v.a. nicht in der aktuellen Version der Entwicklung, und zum anderen, dass von „Software“ insofern der Quellcode nicht umfasst ist. Dieser befindet sich häufig nicht nur auf einem bestimmten Server, sondern auch auf Laptops der Entwickler, bei Auftragnehmern und Subunternehmern. Es kann sich vor allem unter eigentumsrechtlichen Aspekten anbieten, den 60 Komplex der Unterlagen einschließlich des Datenträgers und vor allem der darauf repräsentierten Quellcodes und der Kommentierungen sowie Dokumentationen hierzu als „Material“ zu bezeichnen. Andererseits ist klar, dass der Kunde an den auf dem Datenträger repräsentierten und in den Unterlagen erläuterten Programmen letztlich nicht das „Eigentum“ erhält, sondern Nutzungsrechte. Dass diese über § 453 BGB kaufrechtlich dem Sachgegenstand gleichgestellt werden, ändern nichts an der Problematik, dass auf der einen Seite von Gegenständen die Rede ist, die als Sache dem Eigentum zugänglich sind, andererseits aber auch immaterielle Gegenstände vorliegen, die als „sonstige Gegenstände“ i.S.v. § 453 BGB zu sehen sind2. Auch „einfache“ Lizenzen, also Nutzungsrechtseinräumungen, haben ande- 61 rerseits „dinglichen“ Charakter, was im Hinblick auf Insolvenz und deren Wirkungen bislang wenig beachtet wurde3. Bei Miete ergibt sich ein gewisser Schutz aus der Sukzessionsregel § 566 BGB, die allerdings insolvenzrechtlich keinen Schutz gegenüber dem Wahlrecht des Insolvenzverwalters gewährt. Häufig wird ohnehin aufgrund nutzungsintensitätsabhängiger Ver-

1 In Abhängigkeit von eingesetzter Sprache, Beachtung der style guides (z.B. bei MS Dynamics) u.Ä.; s.a. Stiemerling, ITRB 2013, 87. 2 Zu den diversen Arten der Dokumentation s. Hoppen, Kap. Q Rz. 100 ff.; s.a. Hoppen/Hoppen, CR 2009, 761; Stiemerling, ITRB 2011, 286. Zur Diskussion der Sachqualität von Software s. Kap. B, neuerdings v.a. OLG Hamm v. 28.11.2012 – 12 U 115/12 i.V.m. EuGH v. 3.7.2012 – C 128/11; dazu s. sogleich Rz. 62. 3 S. aber Dieselhorst, CR 2010, 69 zu BGH v. 26.3.2009 – I ZR 153/06 – Reifen Progressiv; s. v.a. Stöckel/Brandi-Dohrn, CR 2011, 553; offen gelassen bei BGH v. 30.6.2011 – III ZB 59/10 – Cross Patent License Agreement und dazu Heim, GRUR 2012, 97 und dazu – gegen Dinglichkeit der Lizenz – Heim, GRUR 2012, 97. S.a. ohne diese Begrifflichkeit LG München I v. 9.2.2012 – 7 O 1906/11, GRUR 2012, 377 (LS).

Schneider

1065

L Rz. 62

Einzelprobleme

gütung1 bei der Lizenz Miete vorliegen. Für die auf ein solches Vertragsverhältnis aufbauende Anpassung wird eher Überlassung der Software und der Rechte auf Dauer vorliegen (Werkvertrag). Diese disparaten Rechtsverhältnisse dürften beim Escrow-Vertrag kaum abbildbar sein. 62 Bei Online eingespielter bzw. bezogener Software trat nach früher h.M. auch bei käuflichem Erwerb und Nutzungsrechtseinräumung auf Dauer keine Erschöpfung ein. Eine Weitergabe der Software wäre danach nicht erlaubt bzw. die entsprechenden Weitergabe- und Abtretungsverbote in den typischen AGB wirksam2. Diese Ansicht ist nicht mehr haltbar3. Entscheidend ist die Überlassung auf Dauer4. Diese führt auch „Online“ zu Erschöpfung, so dass Weitergabeverbote unwirksam sind. Ungelöst ist aber die weitere Voraussetzung berechtigter Weitergabe: die vorherige Löschung/Unbrauchbarmachung. Evtl. könnte dabei Escrow helfen: die eigene Version wird sofort gelöscht, die Version des Agenten weitergegeben. Dies dürfte aber voraussetzen, dass der Kunde hinterlegt hat (nicht der Lieferant). b) Inhaberschaft 63 Die zweite Frage in diesem Zusammenhang ist, wer, wenn Eigentum an diesen Materialien eingeräumt bzw. übertragen werden kann, dieses Eigentum jeweils innehat. Dies insbesondere im Hinblick auf die Insolvenzfestigkeit des Treuhandmodells, wenn denn eine Treuhand unterstellt wird. Diese Fragen werden weiter unten im Zusammenhang auch mit der Treuhänderschaft kurz behandelt. 64 Hier geht es zunächst einmal darum, dass eine Synchronisation in den Verträgen und in den Vertragskonstellationen herbeizuführen ist, die eine Art Rechtskonformität mit Gleichlauf der verschiedenen Transaktionen erreichen muss, nämlich – Zahlungen – Rechtseinräumung – Eigentum an den Materialien. Dies gilt unbedingt auch für Anpassungsprojekte, also Änderungen am Code, Erweiterungen und zusätzliche Programme.

1 Zu neuen Nutzungsformen und insoweit auch neuen Lizenzmodellen s. Grützmacher, CR 2011, 697; „Abschied“ von der Lizenz: Koch, ITRB 2011, 42. 2 S. Tendenz noch bei BGH v. 3.2.2011 – I ZR 12/08 – Oracle ./. UsedSoft, CR 2011, 223, dazu Leistner, CR 2011, 209. 3 S. zu EuGH v. 3.7.2012 – C-128/11, CR 2012, 498 Schneider/Spindler, CR 2012, 489. 4 Ungenau: „unbefristet“ oder „ohne zeitliche Begrenzung“, so aber BGH v. 17.7.2013 – I ZR 129/08 – UsedSoft II.

1066

Schneider

Hinterlegung von Software, Escrow

Rz. 69

L

c) Vergütung Im Idealfall aus Sicht des Escrow (nicht unter Aspekten der fortschrittsabhängigen Zahlung) hat der Kunde die Überlassung der Materialien (auch wenn er sich eines Escrow-Unternehmens bedient) sowohl hinsichtlich des Quellcodes als auch hinsichtlich des Objektcodes und der sonstigen Dokumentationen und Leistungen bereits voll vergütet. Es soll also erreicht werden, dass insoweit der Vertrag seitens des Kunden voll erfüllt ist.

65

Bei der Rechtseinräumung sollte klargestellt sein, dass sich die Rechte gera- 66 de im Beschaffungsvertrag seitens des Kunden bereits ohne den Herausgabefall auch auf den Quellcode und dessen Bearbeitung, vielleicht sogar auf die Weiterverbreitung der Bearbeitung (wenn der Kunde seinerseits die Software weiter vertreibt) beziehen. Ganz kontraindiziert wäre es also, wenn im Überlassungsvertrag geregelt wäre, dass genau für den Fall der Insolvenz etwa der Kunde bestimmte zusätzliche Rechte erhalten soll. Dies wäre der typische Fall der Vorausverfügung1. Schließlich spielt natürlich eine erhebliche Rolle, wo mit welchen Rechten das Material liegt. Hier soll es nach Oberscheidt etwa genügen, dass das Material bzw. das Eigentum hieran nicht mehr beim Hersteller/beim Softwarehaus liegt, sondern bei der Hinterlegungsstelle. Oberscheidt geht also von einer Übereignung auf die Hinterlegungsstelle aus2.

67

Möglicherweise ist aber auch dies nicht weit genug gedacht: Auch hier liegt 68 bei genauerer Betrachtung wieder die Gefahr einer Vorausverfügung in dem Sinne vor, dass sich zwar der Lizenzgeber/das Softwarehaus scheinbar der Eigentumsrechte an den Materialien begeben hat, aber die eigentliche Eigentumsverfügung an den Kunden erst erfolgt, wenn eben der Herausgabefall, hier immer kritisch der Insolvenzfall, eintritt. Dies bedeutet, dass man die schuldrechtliche ebenso wie die dingliche Seite des Escrow-Vertrags im Verhältnis zu den beiden Vertragspartnern näher beleuchten muss, da es sich insoweit auch um ein Dauerschuldverhältnis handelt, das noch nicht erfüllt ist. Insofern unterliegt auch ggf. der Escrow-Vertrag den Rechten des Insolvenzverwalters hinsichtlich noch nicht vollständig erfüllter Verträge. Vor diesem Hintergrund ist natürlich die Frage der Treuhandkonstruktion von besonderer Bedeutung (dazu unter Rz. 74 ff.). d) Eigentum Sobald von „Eigentum“ die Rede ist, stellt sich die Frage, ob und inwieweit 69 überhaupt an Software eigentumsähnliche Rechte entstehen bzw. übertragen werden können. Im Zusammenhang mit einer Sicherungsübereignung 1 S.a. BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151, ebenso dort zur davon zu unterscheidenden aufschiebenden Bedingung für Rechte, die für zukünftig entstehende Versionen eingeräumt worden waren. 2 Oberscheidt, Die Insolvenzfestigkeit der Softwarehinterlegung, Münster 2002, S. 28 f.

Schneider

1067

L Rz. 70

Einzelprobleme

hatte der BGH schon früh klargestellt, dass dies unter den Gesichtspunkten der Behandlung der Rechte an der Software eine verfehlte Rechtskonstruktion ist. Er hat in der fraglichen Entscheidung Holzhandelsprogramm1 aufgrund des zeitlich weit zurückliegenden Vertrags hingenommen, dass dort diese Formulierung gewählt wurde, und sie anders interpretiert, aber angedeutet, dass für zukünftige Verträge diese Wortwahl eher schädlich wäre. 70 Die fragliche Problematik ergibt sich genauso, wenn es darum geht, wann genau und in welchem Umfang der Rechtsübergang etwa auf den Kunden erfolgt, z.B. noch vor Bezahlung2. 71 In diesem Zusammenhang ist die neuerdings wieder entflammte Diskussion um die sog. Sachqualität von Software von Bedeutung. Es erscheint absehbar, dass gerade im Hinblick auf die Umgehung des § 651 BGB ein Wandel in der Auffassung besteht, dass Software keine Sache ist und sein kann3, der sich evtl. durchsetzt. 72 Wird die Sachqualität rundheraus so abgelehnt und handelt es sich nicht um rein kaufrechtlich erworbene Software, wofür die Gleichstellung im Rahmen von § 453 BGB einschlägig ist, ist eine „Eigentums“-ähnliche Position für den Kunden kaum vorstellbar. Diese Auffassung dürfte aber nun zur Mindermeinung werden, wenn die Konsequenzen aus der EuGH-Gebraucht-Software E. richtig umgesetzt werden4. e) Bedingungsfeindlichkeit 73 Es kann davon ausgegangen werden, dass sämtliche Regelungen, die erst dann aufleben sollen bzw. die erst dann überhaupt erst entstehen, wenn der Insolvenzfall eintritt, als Vorausverfügungen schädlich sind, also nicht zur Insolvenzfestigkeit führen können5. Dagegen soll eine aufschiebend bedingte Verfügung über den Quellcode auch zukünftiger Versionen wirksam sein, wenn der entsprechende Gegenstand bis zur Insolvenz entstanden ist und die Bedingung danach eintritt6. 2. Treuhand, Verhältnis zur Insolvenz des Treugebers 74 Vertragstyplogisch wird man grundsätzlich den Escrow-Vertrag im Verhältnis zwischen beiden Parteien als Geschäftsbesorgungsvertrag verstehen 1 BGH v. 20.1.1994 – I ZR 267/91, MDR 1994, 462 = CR 1994, 275. 2 S. dazu vor allem Karger, CR 2001, 357, Ziff. V. 3 S. ausführlich oben Kap. B Rz. 1 ff. und z.B. Bartsch, CR 2010, 553; Heydn, CR 2010, 765; Redeker, CR 2011, 634. 4 S. m.w.N. Kap. B Rz. 2 und 34. S. zur Formulierung Rz. 114. 5 S. im Einzelnen: Paulus, CR 1994, 83; Paulus, CR 2003, 237; Siegel, CR 2003, 941 (944); s. auch zur Vorausverfügung (nicht im insolvenzrechtl. Sinn!) bei Rechtseinräumung Karger, CR 2001, 357. 6 BGH v. 17.11.2005 – IX ZR 162/04, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg und dazu unten Rz. 149 ff.

1068

Schneider

Hinterlegung von Software, Escrow

Rz. 78

L

können; eine Treuhand muss nicht notwendigerweise vorliegen. Auch den sog. Geschäftsbesorgungs- und Auftragsverträgen wohnen Treuepflichten des Beauftragten inne. Es ist aber nicht Voraussetzung, dass es sich um eine treuhänderische Stellung handelt1. Hinsichtlich der Treuhand und deren Ausgestaltung gibt es einige wichtige Sonderkonstellationen im Zusammenhang mit der Insolvenz, die es angeraten erscheinen lassen, der Frage nachzugehen, ob bzw. ggf. welche Treuhand vorliegt.

75

Aufgrund der Unterschiede der Ausgestaltungen hat etwa bei einer sog. 76 fremdnützigen Treuhand im Fall der Insolvenz des Treugebers der Treuhänder kein Aus-/Absonderungsrecht und kann der Insolvenzverwalter die Herausgabe verlangen2. Bei der eigennützigen Treuhand ist es dagegen so, dass der Sicherungsnehmer ein Absonderungsrecht hätte3. Bei der sog. doppelseitigen Treuhand, die für Escrow gelegentlich angenom- 77 men wird, gehen diese Kategorien nun durcheinander bzw. passen nicht so recht zusammen. Eigennützige (Sicherungs)-Treuhand soll vorliegen, wenn das Treuhandverhältnis im Interesse des Treunehmers, in der Regel, um ihn dinglich zu sichern, begründet wird, wobei typisch Sicherungsabtretung oder Sicherungsübereignung wären4. Bei der fremdnützigen (Verwaltungs)Treuhand wird das Treuhandverhältnis „im Interesse des Treugebers“ (weil er sein Recht nicht ausüben will oder kann) begründet5. Als Beispiele werden genannt die Inkassoabtretung und das Rechtsanwalts- bzw. Notaranderkonto. Bei der doppelseitigen Treuhand ist nun beides möglich: Der Treuhänder verwaltet das Treugut aufgrund des Vertrags mit dem Treugeber im Rahmen einer Verwaltungstreuhand und verwendet es aufgrund des Vertrags mit oder zugunsten des Gläubigers des Treugebers für diesen (als Sicherungstreuhand)6. Das Merkmal einer unechten Treuhand dürfte bei vielen Escrow-Verträgen 78 vorliegen, indem diese das Prinzip enthalten, dass die Rechte, evtl. als „Intellectual Property Rights“ oder „Confidential Property“ (passend zum Begriff „Material“ für Software, Informationen und Dokumentationen) beim Hersteller („Owner“ der Software) verbleiben7. Bleibt der Treugeber Eigen1 BGH v. 10.12.2002 – X ZR 193/99, MDR 2003, 559; Hoeren, CR 2004, 721 (723). 2 S. Palandt/Bassenge, § 903 BGB Rz. 43 unter Hinweis auf BGH NJW 1962, 1200. 3 S.a. Palandt/Bassenge, § 930 BGB Rz. 37 unter Hinweis auf BGH NJW 2008, 3142. 4 S. Palandt/Bassenge, § 903 BGB Rz. 35. 5 Palandt/Bassenge, § 903 BGB Rz. 35 unter Hinweis auf BGH v. 9.7.1992 – XII ZR 156/90, FamRZ 1992, 1401 = NJW-RR 1993, 367. 6 Palandt/Bassenge, § 903 BGB Rz. 35 unter Hinweis auf BGH v. 12.10.1989 – IX ZR 184/88, MDR 1990, 238 = WM 1989, 1779; zum Problem s.a. Roth, ITRB, 2005, 283. 7 S. Hoeren, CR 2004, 721 (723); Hoeren, CR 2005, 773 ff.

Schneider

1069

L Rz. 79

Einzelprobleme

tümer des Materials, gehört auch die Kopie des Quellcodes zur Insolvenzmasse und nicht dem Treunehmer1.

IV. Vertragsgestaltung und -struktur 79 Bei der vertraglichen Ausgestaltung sind im Prinzip Phasen und dabei Aktivitätsfelder bzw. Leistungsbereiche sowie die Struktur und die Konstruktionen zum Verhältnis der Beteiligten zueinander zu unterscheiden. 1. Phasen 80 Nach dem Abschluss der Vereinbarung wird zunächst in einer ersten Phase der Quellcode – wobei noch genauer zu regeln ist, von wem – an die Hinterlegungsstelle gegeben. Hier geht es um die Übergabe, vor allem den physikalischen Transfer. Diese Phase erscheint relativ trivial, weil häufig nicht gesehen wird, dass zu ihr auch die Verifikation gehört. Ein Escrow-Unternehmen wird also – vertraglich genauer geregelt – den Eingang des Quellcodes verzeichnen und dann eine Überprüfung vornehmen, ohne besondere Vereinbarungen nach Standardkriterien. Dies umfasst z.B. die Prüfung, ob tatsächlich der Quellcode auf dem Datenträger gespeichert ist, der vertraglich vereinbart ist, bis hin zu der Frage, ob er verwertbar, also kompilierbar ist. Die Beanstandungsquote soll relativ bzw. unerwartet hoch sein. 81 Die zweite Phase ist die Lagerung beim Escrow-Unternehmen, das häufig auch als Escrow-Agent bezeichnet wird. Diese Phase scheint eine Art Ruhephase zu sein, was aber trügt. Tatsächlich wird der Quellcode nämlich während dieser Vertragsphase im Rahmen von Pflegeverträgen oder sonstigen Änderungen bewirkenden Maßnahmen immer wieder neu an die Hinterlegungsstelle zu geben sein. Diese wird dann auch regelmäßig die Verifikation vorzunehmen haben. 82 Die wohl problematischste, dritte Phase ist die der Herausgabe, sei dies aufgrund eines Herausgabeverlangens des Anwenders oder aufgrund der Beendigung des Vertrags, nach anglo-amerikanischen Vorstellungen dann mit Rückgabe an den Auftragnehmer/Lizenzgeber. 83 Ergänzt werden kann vor allem die erste Phase mit Wirkung auch für die zweite durch spezielle Verifikationsmaßnahmen bis hin zu dem Verfahren, dass beide Vertragspartner gemeinsam, unterstützt durch Sachverständige, feststellen, ob der zu übergebende Quellcode tatsächlich in der Lage ist, kompiliert zu werden und ob die kompilierte Software tatsächlich im Wesentlichen mangelfrei ausführbar und mit der beim Kunden im Einsatz befindlichen identisch ist.

1 Hoeren, CR 2004, 721 (723); Hoeren, CR 2005, 773 ff.

1070

Schneider

Hinterlegung von Software, Escrow

Rz. 87

L

Die verschiedenen Leistungen des Escrow-Agenten könnten also wie folgt gegliedert werden:

84

– Entgegennahme des Quellcodes, – Verifikation, – Lagerung mit Aktualisierung und Folgen der Verifikation und Lagerung bzw. Rückgabe von früheren Generationen des Quellcodes, – Herausgabe. Um diese verschiedenen Phasen überhaupt realisieren zu können, ist der 85 Escrow-Agent darauf angewiesen, dass die beiden Parteien – hier vor allem der Lizenzgeber – den in der Hinterlegungsvereinbarung geregelten Pflichten nachkommen. Typisch wäre also, zur Realisierung der Lieferung des Quellcodes und den Möglichkeiten der Verifikation sinngemäß Folgendes zu vereinbaren:

– Der Lizenzgeber wird verpflichtet, eine Ausgabe/ein Exemplar des gesamten – noch näher zu beschreibenden – Materials innerhalb einer bestimmten Frist, gerechnet ab Datum der Vereinbarung, dem Escrow-Agenten körperlich zu übergeben (wobei sinnvollerweise die genauen Modalitäten der Übersendung zu regeln wären). – Der Lizenzgeber wird verpflichtet, dafür zu sorgen, dass stets die jeweils aktuelle Version/die letzte Version, die der Lizenzgeber als Objektcode an den Lizenznehmer geliefert hat bzw. die dort aktuell im Einsatz ist, durch das beim Escrow-Agenten befindliche Material generiert werden kann. (In diesem Zusammenhang könnte klargestellt werden, inwieweit älteres Material bzw. frühere Versionen durch neue ersetzt werden bzw. wie lange die Versionen aufzubewahren sind.)

Das Problem in diesem Zusammenhang ist, dass hier der Charakter als 86 Dauerschuldverhältnis bzw. noch nicht voll ausgeführter Vertrag auch hinsichtlich des Escrow-Vertrags deutlich wird. Sicherer wäre es insofern, nur zu vereinbaren, dass eine bestimmte, konkrete Version des Quellcodes, die beim Escrow-Agenten hinterlegt wird, in der Lage ist, einen bestimmten, beim Kunden im Einsatz befindlichen Objektcodes wieder zu erzeugen. Ein ähnliches Problem ist mit der nächsten Verpflichtung verbunden, wonach ggf. der Lizenzgeber sogar eine Ersatzkopie des Materials zu übergeben hat. Im Hinblick auf eine mögliche Alterung des Materials kann es sinnvoll sein, auch ohne, dass ein Update stattgefunden hätte, eine Nachlieferung derselben Version vorzunehmen. Auch hierin liegt aber eine schuldrechtliche Verpflichtung im Rahmen eines Dauerschuldverhältnisses, die insolvenzrechtlich problematisch ist.

Schneider

1071

87

L Rz. 88

Einzelprobleme

88 Im Rahmen der erwähnten Verifikation kann es sich ergeben, dass dem Escrow-Agenten doch nicht die richtige Version überlassen wurde bzw. dieser nicht in der Lage ist, aus dem gelieferten Material den richtigen Objektcode zu erzeugen. Dafür können zahlreiche Gründe vorliegen; häufig wird einfach eine veraltete Version geschickt, manchmal stimmen Bezeichnungen nicht usw. Insoweit wäre dann der Vertrag nicht erfüllt. 89 Bei der Lieferung des Materials wird der Escrow-Agent u.U. auf zusätzlichen Informationen bestehen müssen, um die Verifikation vorzunehmen. Auch dies wäre eine Verpflichtung des Lizenzgebers. 90 In den Fällen, in denen der Quellcode für eine Vielzahl von Kunden/Anwendern hinterlegt werden soll, wird sich der Escrow-Agent das Recht ausbedingen müssen, Vervielfältigung vorzunehmen. Dabei kann der Zeitpunkt entscheidend sein. Wenn dies erst geschieht, wenn das Herausgabeverlangen gestellt wird, kann dem eine Maßnahme des Insolvenzverwalters, insbesondere nach § 103 InsO, entgegenstehen. Wird die Kopie bereits im Rahmen der Aussonderung/Absonderung für den jeweiligen Kunden bei dessen Vertragsschluss mit dem Escrow-Agenten/Lizenzgeber hergestellt, könnte dagegen, wenn man damit den Vertrag als erfüllt ansieht (was nicht unproblematisch ist), die Hinterlegung „insolvenzfest“ sein. 91 Ergänzt werden die vorstehenden Pflichten noch durch eine Regel, wonach immer dann, wenn ein Update beim Kunden eingespielt wird, der EscrowAgent den dazugehörigen Quellcodestand erhält. Auch dies wiederum ist eine Verpflichtung im Rahmen des Dauerschuldverhältnisses, auf die Zukunft gerichtet und kaum „insolvenzfest“, bevor nicht die entsprechende Version beim Escrow-Agenten für den Kunden deponiert ist. 2. Leistungsbereiche 92 Aus dem vorherigen ergibt sich schon, dass sich ganz grob die Leistungsbereiche des Escrow-Agenten in verschiedene Felder einteilen lassen, die sich indirekt schon aus den Phasen ergeben. Im Hinblick auf die Synchronisierung des Beschaffungs- mit dem Escrow-Vertrag werden sich folgende Felder und Regelungsbereiche empfehlen: – Vertragsgestaltung und -abschluss mit Anlagen, nicht zuletzt zwecks Identifikation des genauen Programms und des genauen Programmstandes (Leistungsgegenstand), Beschreibung des „Materials“, z.B.: – Datenträger mit genauer Bezeichnung, Version, Inhaltsangabe, – Directories für alle Datenträger im Ausdruck, – Entwicklungswerkzeuge, Tools, – Dokumentationen und Kommentierung, – Namen, Daten der Entwickler, Bearbeiter (sehr kritisch)1.

1 S.a. Siegel, CR 2003, 941 (945).

1072

Schneider

Hinterlegung von Software, Escrow

Rz. 94

L

– Entgegennahme, – Verifikation i.S.v. Standardverifikation und, bei besonderer Vereinbarung, spezielle Verifikationsverfahren, auch zwecks Feststellung der – Vollständigkeit und der – Compilierbarkeit mit richtigen Ergebnissen1, – Lagerung des Materials, – Erneuerung des Materials, – Herausgabe oder Rückgabe. Die Verifikation ist ein wichtiger Schritt, vor der Einlagerung festzustellen, 93 ob die Software als Quellcode überhaupt den Vereinbarungen und somit dem Object-Code entspricht. Das Minimum ist die Standardverifikation. Sie umfasst vor allem die Identifizierung des Materials mit Vergleich zum Leistungsgegenstand und die Kompilationsfähigkeit. Weiter soll geprüft werden: – – – – – –

Virenfreiheit, Lesbarkeit, Freiheit von Sperren, Schlüssel-Erfordernissen, evtl. auch Verfallsdaten, Vollständigkeit verglichen mit dem Inhaltsverzeichnis, Entkomprimierbarkeit komprimierter Dateien2, Stichproben zur Dokumentation3 und deren Eignung.

Bei Voll-Verifikation wird auch geprüft, ob sich der identische Objectcode generieren (kompilieren) lässt. Folgende Schritte gehören zur Vollverifikation4: – Identifizierung des Materials, – Prüfung der formalen Übereinstimmung mit dem Leistungsgegenstand, bezogen auf Software und Dokumentation einschließlich der für die Kompilierung und deren Tests erforderlichen Erläuterungen, – Kompilierung, evtl. mit Beteiligung der beiden Vertragspartner, Dokumentation der Ergebnisse und deren Prüfung, Mitteilung an die Vertragspartner und bei Erfolg, – Verifizierung der Software und deren Ablauffähigkeit und – Funktionsfähigkeit mit Berichten hierzu5.

1 Stiemerling, ITRB 2013, 87. 2 Gemäß CEN/ISSS (CWA) 13620; s.a. Siegel, Informatik Spektrum 2005, S. 407; s.a. Karger, in: Kilian/Heussen (Hrsg.), Computerrechtshandbuch, Kap. 21 Rz. 36. 3 Siegel, CR 2003, 941 (945 f.). 4 Karger, in: Kilian/Heussen (Hrsg.) Computerrechtshandbuch, Kap. 21 Rz. 37. 5 Karger, in: Kilian/Heussen (Hrsg.) Computerrechtshandbuch, Kap. 21 Rz. 37.

Schneider

1073

94

L Rz. 95

Einzelprobleme

95 Als Variante zu erwähnen ist noch die Vertrags- bzw. Firmenspezifische Verifikation, ggf. mit Testkriterien, gemeinsamer Compilation, Übergabe der Materialien an alle Beteiligten, also ganz individueller Ausgestaltung1. 96 Das Thema Rückgabe ist mit größter Sorgfalt zu behandeln: wenn die Übergabe an den Escrow-Agenten zugunsten des Kunden nicht endgültig ist2, stellt sich ein ähnliches Problem ein wie bei der Kündbarkeit von Softwareüberlassungsverträgen3. 97 Den Feldern von Betätigungen entsprechend sind die Pflichten des EscrowAgenten auszuprägen bzw. geregelt. Dabei ist zu beachten, dass die Entgegennahme des Quellcodes und dessen Verifikation stets neu vorzunehmen ist bzw. vorgenommen wird, wenn eine neue Version vom Lizenzgeber übermittelt wird, gleich, ob es sich um eine echte neue Version oder nur eine neue Ausgabe des schon bisher bekannten bzw. vorhandenen Standes handelt. Damit verändert sich körperlich aber in jedem Falle das „Material“, wie es beim Escrow-Agenten vorhanden ist. 98 Die Pflichten des Escrow-Agenten sind also spiegelbildlich zu diesen entsprechenden Feldern ausgeprägt, wobei noch die Verpflichtungen, ggf. zu informieren, evtl. auch beide Vertragspartner, hinzukommen. Dies gilt z.B., wenn die Verifikation nicht erfolgreich ist, aber auch, wenn vereinbart wird, dass die Ergebnisse der Verifikation beiden Parteien mitgeteilt werden. Dies gilt insbesondere bei Spezialvereinbarungen zur Verifikation. 3. Konstruktionen/Konstellationen 99 Zumeist ist der Escrow-Vertrag ein separat abgeschlossener Vertrag, der allerdings auch schon eine Anlage zum Beschaffungsvertrag sein kann. Evtl. berechtigt der Lizenzvertrag, der zwischen dem regionalen (Vertrags-)Händler und dem Endkunden abgeschlossen wird, zum Beitritt zu einem bereits bestehenden Escrow-Agreement des Herstellers mit einem Escrow-Agenten. Es entsteht eine Kette Lizenzgeber – Agent – Lizenznehmer. Üblich ist auch das Dreieck als fast klassische Vertragssituation für Escrow, bei der der Escrow-Agent mit Lizenzgeber und Lizenznehmer zusätzlich einen Vertrag zum eigentlichen Beschaffungsvertrag zwischen Lizenzgeber und Lizenznehmer schließt (s. etwa EVB-IT System). Seltener dürfte sein, dass der Hinterlegungsvertrag nur zwischen Lizenzgeber und Escrow-Agent besteht und der Agent ermächtigt wird, den Quellcode in bestimmten Fällen herauszugeben. Vor allem bei großem Absicherungsbedürfnis des Anwenders und Skepsis gegenüber der Insolvenzfestigkeit der anderen Konstruktionen empfiehlt es 1 S.a. Stiemerling, ITRB 2013, 87; Siegel, CR 2003, 941 (946). 2 Zur unechten Treuhand wegen Verbleibs des Eigentums beim Treugeber s. oben Rz. 78. 3 S. dazu Fischl, ITRB 2004, 286.

1074

Schneider

Hinterlegung von Software, Escrow

Rz. 104

L

sich, den Hinterlegungsvertrag zwischen Lizenznehmer und Escrow-Agent (evtl. mit Selbstrestriktion des Anwenders) zu schließen. Der Anwender soll dazu den unmittelbaren Anspruch auf Herausgabe vom Lizenzgeber erhalten, diesen aber grundsätzlich in der Form ausführen, dass der EscrowAgent körperlich den Quellcode für den Anwender entgegennimmt. Es entsteht die Kette Lizenzgeber – Lizenznehmer – Escrow-Agent. Schließlich ist noch die Variante zu erwähnen, dass die Parteien vereinbaren, noch eine Hinterlegungsvereinbarung zu schließen. Diese Konstruktion hilft im Bedarfsfall, etwa nach Kündigung oder gar bei Insolvenz, praktisch nichts mehr. Die Struktur und die Konstellationen der vertraglichen Gestaltung sind bei 100 Escrow einerseits in einer sehr typischen Weise in der Praxis anzutreffen, die ziemlich sicher Probleme im Hinblick auf die insolvenzrechtliche Absicherung bereitet. Auf der anderen Seite gibt es durchaus Konstellationen und Strukturen, die im Hinblick auf die Insolvenz, insbesondere die des Lizenzgebers, unproblematisch erscheinen. Daneben ist noch zu beachten, dass je nach Vertrags-Konstellation auch er- 101 hebliche urheberrechtliche Probleme auftreten können. Dies beginnt damit, dass nach dem Escrow-Vertrag der Agent die Software etwa im Rahmen der Verifikation – siehe Rz. 80, 83 – ablaufen lässt und hierfür ein Nutzungsrecht benötigen würde. Wenn man diese Arbeiten als Outsourcing betrachten würde, wäre die Frage, ob insoweit eine gesonderte Lizenz erforderlich ist. Viele Software-Anbieter sehen schon bei einer Backup-Lösung eine solche Lizenz als erforderlich an1. Des Weiteren wird zu prüfen sein, ob und inwieweit der Hauptvertrag, bei 102 dem etwa die Nutzungsrechtseinräumung näher geregelt ist, und der Escrow-Vertrag harmonieren. Z.B. kommt es des Öfteren vor, dass im Hauptvertrag Vertraulichkeitsregelungen in Kombination auch mit der Rechtseinräumung und auch separat vorgesehen sind, die nicht so ohne Weiteres eine Übergabe der Software an Dritte erlauben. Zwecks Beurteilung dieser Kongruenzen bzw. evtl. Divergenzen wird es 103 sich empfehlen, jeweils den Konstellationen des Hauptvertrags und die der Escrow-Vereinbarung genauer zu untersuchen. Hinsichtlich der Escrow-Vereinbarung gibt es folgende drei typische Struktur-Modelle (a–c) und eine ebenfalls typische Vertragskonstellation (d), die erst noch auszufüllen wäre: a) Der Lizenzgeber hat mit einem Escrow-Agenten eine zweiseitige Gene- 104 ral-Abmachung, wonach der Lizenzgeber dem Escrow-Agenten den Quellcode in der aktuellen Version übergibt, damit dieser den Quellcode bei sich verwahrt. Erwerber der Software bzw. Kunden eines evtl. internationalen Vertriebssystems, die den rechtmäßigen Bezug der Software nachweisen, können diesem Escrow-Agreement durch einseitige Erklä1 S.a. Söbbing, ITRB 2007, 50; Grützmacher, CR 2011, 697.

Schneider

1075

L Rz. 105

Einzelprobleme

rung beitreten bzw. sich gegenüber dem Escrow-Agenten erklären und den Nachweis erbringen, dass sie die Software rechtmäßig im Objektcode bezogen haben. Unter bestimmten Voraussetzungen, die insofern dann in dieser Escrow-Erklärung näher angegeben sind, kann der Kunde den Quellcode herausverlangen. U.U. muss dazu der Escrow-Agent erst eine Kopie des Quellcodes individuell für den einzelnen Kunden erstellen. 105

Die Vertragskette würde dann so aussehen, dass jeder der beiden Vertragspartner separat einen Vertrag hinsichtlich des Quellcodes mit dem Escrow-Agenten schließt, während Hersteller/Lizenzgeber und Kunde evtl. miteinander keinen direkten Vertrag haben, weder zu Escrow, noch zur Lizenz. Dies gilt insbesondere, wenn etwa der Kunde seinen Vertrag mit einem deutschen Vertragspartner schließt, während der Lizenzgeber in den USA oder im sonstigen Ausland sitzt1. Insofern wäre es u.U. sehr wichtig, ob der Escrow-Agent dann seinerseits einen Sitz in Deutschland hat und nach welchem Recht sich dieser Vertrag beurteilt. Die insolvenzrechtlichen Konsequenzen sind in den USA und Deutschland sehr verschieden2.

106

b) Relativ lange war es wohl typisch, dass beide Vertragspartner nicht nur miteinander einen Vertrag schließen, sondern auch einen weiteren Vertrag gemeinsam im Dreiecksverhältnis mit dem Escrow-Agenten. Insofern gab es also einen bilateralen Vertrag und einen trilateralen. Insofern war die Synchronisation wohl am leichtesten möglich. In solchen Fällen ist auch die Einbindung des Pflegevertrages und der sich daraus ergebenden Entwicklungen am leichtesten.

107

c) Insbesondere bei angepasster Software und erst recht bei Softwareerstellung, aber auch bei großen Standard-Software-Paketen hat sich individuell eine andere Struktur herausgestellt, die nicht zuletzt besonders auf die Insolvenzfestigkeit abzielt, v.a. was die Insolvenz des Lizenzgebers betrifft: Der Lizenzgeber schließt eine Vereinbarung, möglicherweise als integraler Bestandteil des Hauptvertrags, mit dem Lizenznehmer als Auftraggeber, in der die Überlassung des Quellcodes in allen Stadien und in allen Ausdrucksformen vereinbart wird. Die Herausgabe wird möglicherweise auch kombiniert mit der ausdrücklichen Regelung, dass diese stets parallel auf einem Datenträger zu erfolgen hat, wenn eine Online-Überspielung (was auch hinsichtlich des Quellcodes denkbar ist) erfolgen würde. Dem Auftraggeber stehen die Rechte evtl. relativ oder sogar insgesamt umfassend zu. Er verpflichtet sich jedoch, und zwar insoweit nur schuldrechtlich, den so erhaltenen Quellcode bei sich zu behalten (z.B. im 1 Zur internationalen Zuständigkeit s. BGH v. 1.12.2011 – IX ZB 232/10, DB 2012, 223. 2 S. neuerdings etwa Bankruptcy Court for the Eastern District of Virginia, 28.10.2011 i.S. Quimonda, case No. 09 – 14766 – SSM, CRI 2012, 26, Summary & Comment Lejeune, CRI 2012, 26.

1076

Schneider

Hinterlegung von Software, Escrow

Rz. 109

L

Tresor, vielleicht mit bestimmten Vorschriften hinsichtlich der Versiegelung), kombiniert mit einem Besichtigungsanspruch des Auftragnehmers/Lizenzgebers1. Der Auftraggeber ist berechtigt (und evtl. auch verpflichtet) über den Quellcode eine entsprechende Vereinbarung mit dem Dritten, dem Escrow-Agenten zu schließen und die Software bei diesem zu hinterlegen. Er ist aber jederzeit berechtigt, den Quellcode herauszuholen (wie aus seinem eigenen Safe) und einzusetzen, also zu bearbeiten, zu compilieren und im Rahmen der Rechtseinräumung des Hauptvertrags zu nutzen. Allerdings muss er dem Auftragnehmer ggf. das Vorliegen eines der Herausgabe-Ereignisse nachweisen2. Kann er dies nicht, wird ein bestimmter zusätzlicher Betrag fällig, der bereits vereinbart ist. Möglicherweise wird dem Lizenzgeber nachgelassen, einen größeren Schaden nachzuweisen. Der Vorteil dieser letzten Lösung dürfte darin liegen, dass der jeweilige 108 Real-Akt der Übergabe und die Ausprägung der Rechte an dem Quellcode bereits völlig abgeschlossen ist, die entsprechenden Unterlagen in der Sphäre des Kunden sind und die Verantwortung, ob er zu Recht den Quellcode herausrückt, allein bei diesem liegen. Vorsorglich wäre zu klären, dass – selbstverständlich insoweit auch nicht zuletzt zwecks Verifikation, vielleicht sogar im Rahmen von Backup seitens des Escrow-Agenten und sonstiger Dritter eine Nutzung, schließlich sogar eine evtl. Bearbeitung erlaubt ist, soweit sich dies nicht bereits aus dem Hauptvertrag ergibt. Hinsichtlich der ersten Lösung stellt sich die Frage, ob die Ermächtigung des Escrow-Agenten, in bestimmten Fällen den Quellcode herauszugeben, dann nicht das Hauptproblem wird, wenn der Insolvenzfall des Lizenzgebers vorliegt. Insoweit wurde der Vergleich mit den Ziehungsrechten im Rahmen von Filmrechten gezogen3. d) Wohl sehr problematisch, wenn auch häufig praktiziert, ist der Fall, dass 109 sich die Vertragsparteien auch im Hauptvertrag verpflichten, eine Escrow-Vereinbarung zu treffen. Es handelt sich um eine rein schuldrechtliche Vereinbarung, die höchstens noch als Indikator dafür benutzt werden kann, dass dann, wenn diese Escrow-Vereinbarung getroffen wird, insoweit auch der Quellcode vom Lizenzgeber (an den Escrow-Agenten) herauszugeben ist. Wenn diese Escrow-Vereinbarung nicht in angemessener Frist getroffen wird, stellt sich allerdings die Frage, ob insoweit nicht an so etwas wie „Verzicht“ zu denken ist bzw. ob immer ein Anspruch 1 Ähnlich einem Auditing, also mit Betretungsrecht, Vorlage durch den Lizenznehmer oder den von diesem beauftragten Agenten. 2 Typisch wäre etwa, dass der Auftragnehmer seinen Verpflichtungen nicht nachgekommen ist, wobei ein Verfahren entsprechend § 314 BGB vereinbart sein kann, also etwa Fristsetzung/Abmahnung erforderlich ist, wenn nicht schon Leistungsverweigerung vorliegt und dokumentiert ist. Die Voraussetzungen könnten ganz ähnlich auch denen der Selbstvornahme entsprechen. 3 S. schon von Frentz, OSE-Symposium v. 26.1.2007. www.ose-international.org/ 47.0.html.

Schneider

1077

L Rz. 110

Einzelprobleme

auf Abschluss dieser entsprechenden Vereinbarung noch besteht, insbesondere wenn das Vertragsverhältnis (etwa über die Pflege) länger dauert. Ein solches Verlangen, den Abschluss des Escrow-Vertrags nun vorzunehmen, dürfte dann spätestens im Insolvenzfalle des Lizenzgebers, aber auch des Lizenznehmers, scheitern. 110

Eine besondere Aufgabe für die Vertragsgestaltung ist, Parallelität und Kongruenz der Rechtseinräumungen, Vergütungsregeln und Beendigungs- als auch Herausgabe-Szenarien zu erreichen und Disparitäten zu vermeiden. Typisch wäre etwa, dass der Beschaffungsvertrag ein Bearbeitungsverbot enthält.

111

Bei der Konstruktion, dass der Lizenznehmer den Quellcode für sich hinterlegt, diesen aber nur in bestimmten Fällen herausverlangt, hat zwar der Lizenzgeber keinen Vertrag mit dem Escrow-Agenten, es werden aber zu seinen Gunsten Informationspflichten in den Vertrag des Lizenznehmers mit dem Escrow-Agenten aufgenommen und evtl. ein Pendant zum Besichtigungsanspruch, den sich der Lizenzgeber im Beschaffungsvertrag ausbedingen würde. Danach wäre der Escrow-Agent verpflichtet, sich einem Audit zu unterziehen, das eigentlich den Anwender kontrolliert.

V. Herausgabe 1. Allgemeines 112

Naturgemäß spielen bei den vertraglichen Regelungen die Herausgabefälle eine erhebliche Rolle. Was dabei gelegentlich übersehen wird, ist, dass die Herausgabe einen Sinn haben muss und dieser Sinn nur gegeben ist, wenn der Kunde/Anwender mit dem herausgegebenen Quellcode auch etwas anfangen darf (und nicht nur kann). Das bedeutet, dass im Vertragswerk an geeigneter Stelle, dazu sogleich, die Rechte des Kunden am Quellcode deutlich geregelt werden müssen. Es wird sich empfehlen, diese Rechtseinräumung nicht so zu splitten, dass etwa im Lizenzvertrag nur einfache Nutzungsrechte am Objektcode eingeräumt und in der Hinterlegungsvereinbarung zusätzlich Rechte am Quellcode eingeräumt werden.

113

Vielmehr empfiehlt sich, dass mit „dinglicher Wirkung“, vor allem im Hinblick auf die Insolvenz, endgültig auch und erst recht am Quellcode im Rahmen des Hauptvertrags die Rechte dem Kunden eingeräumt werden. Dieser kann sich allerdings schuldrechtlich verpflichten, von seinen Rechten, insbesondere auf Herausgabe und anschließender Nutzung, auch Bearbeitung, nur unter bestimmten Voraussetzungen Gebrauch zu machen. Eine solche Regelung wäre dann auch dahingehend klarzustellen, dass sie von der Vergütung umfasst ist, dass also die Vergütung auch eine Abgeltung für diese Rechtseinräumung darstellt. Infolgedessen würde es sich hier nicht um eine Art Geschenk oder eine ähnliche Verfügung handeln, die also ggf. auch tatsächlich die Gläubiger benachteiligen würde, wenn es zur Insolvenz kommt. 1078

Schneider

Hinterlegung von Software, Escrow

Rz. 118

L

2. Zur „insolvenzfesten“ Konstruktion Bis zur Entscheidung des BGH vom 17.11.20051 galt: Wahrscheinlich war nur insolvenzfest:

114

Der Kunde erhält die Materialien, Quellcode und Dokumentation hierzu, direkt zu „Eigentum“2. Nun kann als entscheidend gelten, dass die Herausgabefälle nicht an den Insolvenzfall anknüpfen3, sondern an das Vorliegen eines wichtigen Grundes, und Vergütung vorsehen.

Natürlich spielt insofern die Diskussion darüber eine Rolle, ob Software eine Sache ist. Allein das „Eigentum an Materialien“ ist schon problematisch, wenn man der Software die Sacheigenschaft abspricht. Dann bleibt nur das Eigentum am Datenträger. Allerdings gibt es auch das Eigentum an der Dokumentation4.

115

Die Formulierung hinsichtlich der Rechte müsste sich an der Entscheidung 116 des BGH, die noch eine „Sicherungsübereignung“ aus dem Jahre 1976 zum Gegenstand hatte, orientieren5. Danach wäre inzwischen im Vertrag klarzustellen, dass – ggf. neben den 117 dinglichen Verfügungen – Nutzungsrechte am Objekt- und Quellcode eingeräumt werden (wobei genau geregelt werden sollte, welche, insbesondere also das Bearbeitungsrecht und dann die Rechte an den so entstehenden neuen Versionen). Die Rechtseinräumung an den Kunden erfolgt in dem gewünschten Um- 118 fang, also wahrscheinlich nicht ausschließlich, aber mit der genauen Beschreibung, wozu er die Software auch als Objektcode bei sich nutzen darf und dann darüber hinaus das Recht auf Bearbeitung und Nutzung der so entstehenden neuen Version. 1 BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151 m. Anm. Plath/Scherenberg; s.a. Rz. 149. 2 S.a. Roth, ITRB 2005, 283. Vorbild hierzu könnte vor allem LG Frankfurt sein, LG Frankfurt v. 10.11.2004 – 2-06 O 0142/04; dazu ausführlich unten Rz. 146 ff.; s. aber LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811, Rz. 138; s.a. Kap. B Rz. 3. 3 BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151, LS 2. Wenn insolvenzfest vereinbart wird, die Ausübung eines Kündigungsrechts sei die aufschiebende Bedingung für einen Rechtsübergang, scheitert dieser nicht daran, dass er vom Willen des Berechtigten abhängt. 4 Zur Sachqualitäts-Diskussion im Zusammenhang mit § 651 BGB s. Kap. B Rz. 1 ff. 5 S. BGH v. 20.1.1994 – I ZR 267/91 – Holzhandelsprogramm, MDR 1994, 462 = CR 1994, 275.

Schneider

1079

L Rz. 119

Einzelprobleme

119

Falls die Hinterlegung zugunsten eines Vertriebshauses bzw. eines Hauses entstehen soll, das selbst vertreibt und pflegt, ist eine entsprechende Erweiterung der Rechtseinräumung erforderlich, also vor allem die Vervielfältigung und Verwertung der durch die Bearbeitung entstehenden Versionen.

120

Schuldrechtlich würde sich der Kunde aber verpflichten, von diesen Rechten nur Gebrauch zu machen, wenn bestimmte Fälle eintreten, wozu insbesondere auch gehört, dass der Auftragnehmer bestimmten Verpflichtungen nicht oder nicht mehr richtig nachkommt.

121

Die Herausgabefälle könnten dann noch genauer aufgelistet und so eingeteilt werden, dass klar ist, dass einige relativ leicht ermittelbar sind, im Sinne eines Ja/Nein-Schemas, andere „weich“ und evtl. schwerer zu kontrollieren sind. Bei diesen besteht dann auch eher die Gefahr des Missbrauchs. Damit aber der Kunde schnell von dem Quellcode Gebrauch machen kann, könnte man eine Sicherheitsregelung einbauen. Der Kunde würde also in diesen Fällen erst zum Quellcode schreiten dürfen, nachdem er zuvor entsprechende Sicherheit gestellt hat. 3. Beispiele zu Hinterlegungsfällen a) „Harte“ Fälle

122

Häufig1 genannte Vorschläge sind als „hart“ anzusehen, da es im Wesentlichen um gerichtliche Titel geht, die insofern auch höhere Chancen auf Durchsetzung haben: – Eröffnung Insolvenzverfahren (§§ 102 ff. InsO), wäre zu vermeiden bzw. ist unwirksam, da praktisch eine „Vorausverfügung“ (im insolvenzrechtlichen Sinne) vorliegt bzw. vorausgesetzt wird2; – Eröffnung Vergleichsverfahren (§ 11 VerglO); – Löschung der Firma; – Eintragung des Liquidationsbeschlusses; – Ablehnung der Eröffnung eines Insolvenzverfahrens mangels Masse; – Vorlage eines rechtskräftigen Urteils mit Wirkung gegenüber dem Anbieter auf Herausgabe; – Vorlage einer einstweiligen Verfügung gem. § 935 ZPO auf Herausgabe des Quellcodes (etwa im Rahmen eines urheberrechtlichen Verfahrens)3 mit Nachweis der Zustellung;

1 Koch, Computer-Vertragsrecht, 6. Aufl., S. 1151, 1152 f.; s. aber anders Koch, Computer-Vertragsrecht, 7. Aufl., dort ohne Aufzählung, Kap. 5 Rz. 230, 231. 2 S. BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151 m. Anm. Plath/Scherenberg. 3 Zur evtl. Einschaltung eines zur Verschwiegenheit verpflichteten Dritten s. etwa BGH v. 2.5.2002 – I ZR 45/01 – Faxkarte, CR 2002, 791; zum Anspruch s.a. BGH v. 20.9.2012 – I ZR 90/09, CR 2013, 284 – UniBasic – IDOS.

1080

Schneider

Hinterlegung von Software, Escrow

Rz. 124

L

– Vorlage eines Beweissicherungsbeschlusses; – schriftliche Zustimmung des Anbieters1. b) „Weiche“ Fälle In der Vertragspraxis wäre es hilfreich, wenn auch folgende Herausgabefälle 123 berücksichtigt würden, wobei gegenüber deren Durchsetzung eher Skepsis angebracht ist, insbesondere, was die Insolvenzfestigkeit betrifft. Jedoch kann davon ausgegangen werden, dass die folgenden Fälle in der Praxis durchaus häufig so oder ähnlich geregelt werden: – Der Lizenzgeber/Auftragnehmer ist nicht bereit oder nicht in der Lage – ggf. durch ein Mahnschreiben und die Darlegung nachzuweisen, dass hierauf keine geeignete Antwort erfolgte – für den Auftraggeber/Lizenznehmer eine wesentliche Funktion der Software herzustellen oder zu ändern, obwohl der Auftraggeber nachweislich hierfür eine angemessene bzw. marktübliche Vergütung geboten hat oder der Auftragnehmer nicht in der Lage ist, dies innerhalb angemessener Frist zu bewerkstelligen. – Der Auftragnehmer verletzt eine wesentliche Pflicht aus dem Pflegevertrag, insbesondere hinsichtlich der Aktualisierung oder der Mängelbeseitigung. – Scheitern des Projekts zu Erstellung oder Anpassung der Software, evtl. differenziert nach Gründen (z.B. nur solche, die in der Sphäre des Unternehmers liegen und von diesem zu vertreten sind) zwecks Sanierung durch den Besteller. – „End-of-Life“ beim Unternehmer2. Die Notwendigkeit solcher „weichen“ Regelungen wird oft nicht so deut- 124 lich, weil die Fälle, um die es dabei geht, scheinbar durch Pflegeverträge oder Ähnliches abgedeckt sind. An Beispielen aus der Vergangenheit gibt es aber doch einige, die vielleicht zeigen, dass die Vertragspartner an manche Besonderheiten oder Entwicklungen bei einem langfristigen Vertrag nicht gedacht hatten. Allerdings zeigt dies auch wieder den Dauerschuldcharakter der Lizenzbeziehungen mit dem für das Insolvenzrecht gefährlichen Moment, dass dann der Lizenzverwalter kündigen kann. Die Wirkungen auf die bereits ausgelieferten Quellcodestände wäre gesondert zu prüfen (s. Rz. 91, 92, 97).

1 Koch, Computer-Vertragsrecht, S. 1151, 1152 f.; s. auch Schneider, Handbuch des EDV-Rechts, M. Rz. 121 mit den zitierten Fällen; Siegel, CR 2003, 941 (944). 2 Zur Kündigung wegen End-of-Life durch Unternehmer s. Welker/Schmidt, CR 2002, 873.

Schneider

1081

L Rz. 125

Einzelprobleme

4. Spezielle Fälle 125

Kurz zu einigen speziellen Fällen: a) Jahr 2000-Fehler

126

Zwar ist die Jahr 2000-Wende vorbei und das Problem eigentlich gelöst bzw. umgangen. Einige wenige Urteile haben sich damit noch befasst. Interessant ist jetzt, wenn man die Jahr 2000-Problematik verallgemeinert, etwa über den Euro hin zu anderen größeren Umstellungen im Zusammenhang mit gesetzgeberischen Maßnahmen oder auch technischen Entwicklungen, dass manche Gerichte trotz Pflegeverpflichtung nicht die Pflicht zur Herstellung der Jahr 2000-Fähigkeit gesehen haben. Typisch dürfte z.B. sein, dass manche Hersteller „End-of-Life“ verfügen, während der Kauf- und Pflegevertrag mit dem Händler geschlossen wurde, so dass der Händler gar nicht in der Lage ist, noch weitere Leistungen zu erbringen. Ein solcher Fall ließe sich als Herausgabefall sehr gut denken. Das End-of-Life kann für die Erhaltung der Gebrauchstauglichkeit beim Kunden katastrophale Folgen haben1. b) „Unkündbarkeit“

127

Dem steht zwar die Auffassung des LG Köln gegenüber, dass auch fünf Jahre nach End-of-Life noch die Pflege zu leisten sei2. Jedoch ist diese Meinung relativ isoliert geblieben. Das OLG Koblenz hat seine Auffassung, die in eine ähnliche Richtung von der Unkündbarkeit ging (gestützt auf BVB-Überlassung („§ 21“) i.V.m. BVB-Pflege („§ 3“)), revidiert3. c) Eurofähigkeit

128

Im Falle des OLG Nürnberg hatte der Kunde es als Pflichtverletzung des Pflegeunternehmens angesehen, dass dieses nicht die Jahr 2000-Fähigkeit herstellen wollte, auch nicht die Euro-Fähigkeit und schließlich auch nicht eine Kostentabelle4. Das Gericht hat dies „unter Berücksichtigung der Ausführungen des Sachverständigen“ verneint. Danach durfte der Auftraggeber nicht davon ausgehen, dass die entsprechenden Arbeiten im Rahmen des Wartungsvertrages

1 Zu sog. End-of-Life-Schreiben s. Welker/Schmidt, CR 2002, 873. 2 S. LG Köln v. 16.10.1997 – 83 O 26/97, CR 1999, 218 und hierzu Zahrnt, CR 2000, 205; Jäger, CR 1999, 209 und Moritz, CR 1999, 541. 3 S. OLG Koblenz v. 12.1.2005 – 1 U 1009/04, CR 2005, 482 in Abgrenzung zu OLG Koblenz v. 27.5.1993 – 5 U 1938/92, CR 1993, 626 m. krit. Anm. MüllerHengstenberg, CR 1994, 95. 4 S. OLG Nürnberg v. 5.12.2003 – 5 U 2546/02, ITRB 2004, 77 = CR 2005, 260.

1082

Schneider

Hinterlegung von Software, Escrow

Rz. 130

L

geschuldet seien. Ein Ausschluss dieser Leistung war allerdings auch nicht geregelt1. Bei einer Branchensoftware speziell für den Finanzdienstleistungsbereich ist das Fehlen der Eurofähigkeit (hier Umwandeln der DM-Beträge) ein gravierender Mangel2. 5. Besondere Regelungen zur Herausgabe Man wird bei den Herausgabefällen auch Standardfälle und besondere Fälle 129 mit unter Umständen auch besonderen Sicherungen unterscheiden können. Die Standardfälle dürften diejenigen sein, die unter Rz. 122 aufgelistet sind. Die speziell zu vereinbarenden Punkte sind solche, die eher unter Rz. 123 f. fallen, also „weich“ sind. Nun wird der Lizenzgeber – berechtigterweise – bei einem solchen Verlangen zur Vertragsgestaltung des Escrow-Vertrages einwenden, dass solche Regelungen eher schlecht oder schwer zu beurteilen sind, weil manche der Begriffe „Gummi“ sind. Dies gilt etwa, wenn es darum geht, ob der Lizenzgeber als Auftragnehmer oder eine von ihm bestimmte Firma (wichtig im Insolvenzverfahren) bereit und in der Lage ist, die gewünschte und betriebsnotwendige Änderung für den Kunden „innerhalb angemessener Frist“ und zu „angemessenen Bedingungen“ auszuführen. In solchen Fällen kann es sich empfehlen, zur Vermeidung von gegenseitigen 130 Blockaden, ggf. sogar im Rahmen von einstweiligen Verfügungen, das Verfahren genauer zu beschreiben, wann sich der Kunde/Anwender des Quellcodes bedienen darf und, wie er evtl. bei Widerspruch des Lizenzgebers diesen absichern kann und dann trotzdem den Quellcode vom Escrow-Agenten erfolgreich herausverlangen darf: – Der Lizenznehmer legt mit dem Herausgabeverlangen gegenüber dem Escrow-Agenten – mit Kopie an den Lizenzgeber – dar, – dass er ein Verlangen entsprechend dem Fall betriebsnotwendiger Änderungen gegen ein Angebot angemessener Vergütung gestellt hat; – der Lizenznehmer weist nach, dass der Auftragnehmer/Lizenzgeber nicht innerhalb der im Vertrag festgelegten Frist geantwortet oder innerhalb der Frist negativ geantwortet hat und – dass er die im Vertrag festgelegte Sicherheit gestellt hat (z.B. eine genauer zu beschreibende Bankbürgschaft in der vereinbarten Höhe). – Die Betriebsnotwendigkeit wurde dabei schon beim ersten Verlangen unterstützt bzw. begründet mit einer zugleich abgegebenen eidesstattlichen Versicherung eines zuständigen Mitarbeiters, dass das Herausgabeereig-

1 OLG Nürnberg v. 5.12.2003 – 5 U 2546/02, ITRB 2004, 77 = CR 2005, 260; ebenso ablehnend AG Düren v. 14.4.2004 – 45 C 332/00, CR 2004, 734; a.M. zu Eurofähigkeit LG Stuttgart v. 26.2.2001 – 14 O 232/00, CR 2002, 255. 2 OLG Köln v. 21.3.2003 – 19 U 112/01, K&R 2003, 613.

Schneider

1083

L Rz. 131

Einzelprobleme

nis tatsächlich gegeben ist, insbesondere die Betriebsnotwendigkeit der Änderung/Ergänzung. Eine weitere Absicherung könnte auch sein, dass klargestellt wird, dass insoweit eine Geheimhaltungsverpflichtung seitens des Kunden besteht, wenn diese nicht schon von Anfang an Bestandteil des Escrow-Vertrags war. Schließlich lässt sich regeln, dass der Auftrag, wenn der Kunde nicht selbst die Änderungen vornimmt, nicht an bestimmte Auftragnehmer geht, die als die besonderen Konkurrenten des Auftragnehmers gelten. Hier bestehen allerdings möglicherweise kartellrechtliche Bedenken.

VI. Risiken des Escrow-Vertrags, besondere Problemlagen 1. Pflege 131

Schon aus den Überlegungen zur dinglichen Regelung mit „Materialien“ und „Eigentum“1 heraus hat sich ergeben, dass es Schwierigkeiten bereitet und nahezu unmöglich erscheint, entsprechende Rechte an zukünftigen Versionen wirksam zu vereinbaren mit der Folge, dass Pflegeverträge in der Kombination mit Escrow (allenfalls) hinsichtlich solcher Versionen insolvenzfest sind, die bereits hinterlegt sind, nicht hinsichtlich zukünftiger Versionen.

132

Dies hängt damit zusammen, dass der Pflegevertrag der typische Fall ist, wo zwar zunächst einmal werkvertragliche Regelungen hinsichtlich des Leistungsbildes bestimmend sein können (etwa im Hinblick auf die Mängelbeseitigung), wo aber zumindest auch ein starkes Moment des Dauerschuldverhältnisses besteht. Dies bedeutet, dass der Insolvenzverwalter prüfen bzw. entscheiden kann, ob er diesen Vertrag bedienen will. Auch wird er prüfen, ob er die entsprechende Regelung anfechten kann. Gerade beim Pflegevertrag handelt es sich um einen Vertrag, der in dem Stadium, in dem Insolvenz eintritt, beidseitig wahrscheinlich noch nicht, zumindest einseitig nicht, erfüllt ist. 2. Weiterreichende Pflichten, Dauerschuldverhältnis

133

Ein Urteil vor allem des LG Mannheim2 sorgte für erhebliche Probleme im Zusammenhang nicht nur mit Dauerschuldverhältnissen, sondern allen Verträgen, bei denen zwar der Hauptvertragsgegenstand erfüllt ist und zwar auch vollständig im Sinne eigentlich der Insolvenzordnung (vor allem § 103 InsO), wo jedoch noch daneben Leistungspflichten bestehen bzw. fortbestehen, zu

1 S. oben Kap. B Rz. 1 ff. 2 LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811 m. Anm. Grützmacher; s. dazu im Vergleich mit und als Kontrast zu BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151; Grützmacher, CR 2006, 289.

1084

Schneider

Hinterlegung von Software, Escrow

Rz. 137

L

denen typischerweise die Pflege gehören könnte, zu denen sogar die Hinterlegungsvereinbarung selbst gehören könnte. Aber auch unabhängig von diesen zusätzlichen Regelungen enthalten sehr viele Lizenzverträge, auch wenn sie auf dauerhafte Überlassung gerichtet sind, Regelungen, die über die Erfüllung des Hauptvertragsgegenstandes hinausgehen, insbesondere Treuepflichten, Geheimhaltungspflichten, Abwerbeverbote, sogar ein Kündigungsrecht des Lizenzgebers im Falle schwerer urheberrechtlicher Verstöße. Als besonders üblich dürfen Vertraulichkeits- bzw. Geheimhaltungsvereinbarungen angesehen werden1. Redeker empfiehlt, die Lizenzvereinbarung möglichst „schlank“ zu gestal- 134 ten, um genau diesen Effekt fortdauernder Leistungspflichten evtl. auch in Form von Nebenpflichten, zu vermeiden. Er rät sogar im Hinblick auf die – allerdings problematische – Entscheidung des LG Mannheim2 davon ab, Escrow-Vereinbarungen zusätzlich zu schließen. Die Alternative, die er vorzieht, ist direkte Übergabe des Quellcodes3. Diese Lösung erscheint ziemlich radikal und im Vergleich mit folgendem Modell auch wohl als zu radikal.

135

3. Empfehlungen Wie angedeutet wird es sich ohnehin empfehlen, dass der eigentliche Hin- 136 terleger nicht der Lizenzgeber, auch nicht beide zusammen, Lizenzgeber und Lizenznehmer, ist bzw. sind, sondern der Auftraggeber/Lizenznehmer. Insofern ist Redeker auch zuzustimmen. Der Auftraggeber soll den Quellcode – unter Gesichtspunkten sowohl des Urheberrechts als auch der Insolvenzordnung – bedingungsfrei erhalten. Praktisch erhält er ihn im Rahmen des Hauptvertrags in einem solchen Fall zu „Eigentum“. Urheberrechtlich wird dies ergänzt durch eine Berechtigung – wenn auch nicht ausschließliche – zur dauerhaften Nutzung, Bearbeitung und Übersetzung der bearbeiteten Ergebnisse sowie deren Nutzung, zumindest im eigenen Hause des Auftraggebers, im Falle einer Vertriebsfirma ggf. auch dann des Vertriebs der entsprechend entstehenden neuen Versionen zusammen mit dem Vervielfältigungsrecht und dem Recht der Bearbeitung dieser so entstehenden Version, etwa im Rahmen der Pflege. Bei einer solchen endgültigen Übertragung, die durch eine entsprechende 137 Vergütung auch abgegolten ist, würde keine Hauptpflicht mehr fortbestehen, wenn dieser Übergabefall rechtzeitig vor den für die Insolvenz relevanten Daten/Fristen erfolgt ist. Der Auftraggeber wiederum verpflichtet sich dann allerdings, seinerseits von diesem Recht keinen Gebrauch zu machen

1 S. vor allem Fischl, ITRB 2005, 265. 2 LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811; zu BGH v. 17.11.2005 – IX ZR 162/04, CR 2006, 151; s. Grützmacher, CR 2006, 289 und unten Rz. 149. 3 Redeker, ITRB 2005, 263.

Schneider

1085

L Rz. 138

Einzelprobleme

und wählt dazu einen Partner, bei dem er die Software hinterlegt. Statt der Übergabe an den Auftraggeber direkt kann auch die Übergabe an diesen Escrow-Agenten erfolgen1. 4. LG Mannheim, Konsequenzen 138

Diese Empfehlungen stehen in einem gewissen Gegensatz zu den Schlussfolgerungen, die vor allem Redeker aus dem Urteil des LG Mannheim gezogen hat2. Die weitere Entwicklung lässt zwar diese Entscheidung als veraltet erscheinen. Jedoch lassen sich aus diesem Urteil einige Besonderheiten entnehmen, die im Ergebnis dazu führen, dass dann, wenn diese Besonderheiten nicht vorliegen, auch dessen Grundsätze nicht gelten können. Im Folgenden handelt es sich also um eine Art Argumentekatalog, wenn es darum geht, entgegen der Ansicht von Redeker bzw. trotz des Urteils des LG Mannheim die Insolvenzfestigkeit von Escrow zumindest als möglich anzusehen, wenn nur die Maßgaben, die sich aus dem Urteil ergeben, beachtet werden. Diese Themen spielen auch bei der Diskussion um einen § 108a InsO-E eine Rolle (s.a. Rz. 178 ff.). a) Einstweiliges Verfügungsverfahren

139

Es handelte sich um ein Verfahren zur einstweiligen Verfügung. Das bedeutete ohnehin ein kursorisches Verfahren. Nach Ansicht des Gerichts konnte die Verfügungsklägerin ihre Verfügungsansprüche nicht glaubhaft machen. Dies betraf einen Unterlassungsanspruch im Hinblick auf Herstellung und Vertrieb einer bestimmten Software. b) Ausschließlichkeit einer Field of use-Regelung

140

Bei dieser Software handelte es sich um eine solche, hinsichtlich derer die beiden Vertragspartner im ursprünglichen Vertrag eine Aufgaben- und Vertriebsabgrenzung vorgenommen hatten, so dass nicht primär ein ausschließliches Nutzungsrecht vorlag, sondern eine zeitlich unbegrenzte und nicht ausschließliche Lizenz für den Eigenbedarf, jedoch eine spezielle ausschließliche und übertragbare Nutzungsrechtseinräumung hinsichtlich einer bestimmten Verwendung, wobei es dann wieder an anderer Stelle im Vertrag hieß, dass es sich um eine zeitlich unbegrenzte und nicht ausschließliche, (allerdings) „für die Weiterentwicklung und Nutzung im Segment Möbelindustrie ausschließliche Lizenz für den Eigenbedarf, für den Weitervertrieb im Segment Möbel- und Industrie, bezogen auf das Produkt …“ handelt. Praktisch bedeutet dies, dass sich die Ausschließlichkeit auf eine sog. Field

1 S. auch oben Rz. 99. 2 Redeker, ITRB 2005, 263; LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811.

1086

Schneider

Hinterlegung von Software, Escrow

Rz. 142

L

of Use-Regelung bezog, deren Wirkung äußerst zweifelhaft erscheint, vom Gericht aber insoweit nicht geprüft wurde1. c) Erfüllung von Nebenpflichten Das Gericht befand, dass bestimmte Pflichten und hier Nebenpflichten aus 141 dem Vertrag noch nicht erfüllt waren. Solche Nebenleistungen hat das Gericht im Hinblick auf § 17 KO (also die Vorgängerregelung zur InsO) mit der Nichterfüllung einer Restleistung verglichen. Bei den Nebenpflichten ging es darum, die im Lizenzmaterial enthaltenen Schutzvermerke beizubehalten sowie alle von ihr hergestellten vollständigen oder teilweisen Kopien von maschinenlesbarem Lizenzmaterial in unveränderter Form zu übernehmen. Es erscheint nicht haltbar, mit Pflichten, die letztlich nichts anderes sind, als ein bestehendes Urheberrecht an der Software selbst zu beachten, soweit nicht einem selbst die Rechte eingeräumt sind, die Anwendung von § 103 InsO zu rechtfertigen. Für den Fall der tatsächlichen Beendigung aufgrund der Erfüllungsablehnung des Insolvenzverwalters soll nach Ansicht des Gerichts gemäß § 103 Abs. 2 InsO das Erlöschen der Lizenz eintreten und dies soll folgen aus der „analogen Anwendung des § 9 VerlG, aufgrund derer das Abstraktionsprinzip im Urhebervertragsrecht nicht gilt“2. Diese Analogie zum Verlagsgesetz ist nicht vertretbar. Insolvenzrechtlich hält diese Auffassung ohnehin nicht, da der BGH schon zuvor der sog. Erlöschenstheorie eine Absage erteilt hatte3. U.a. spricht gegen die analoge Anwendung des § 9 VerlG, dass nach der No- 142 vellierung des Urhebervertragsrechts nicht mehr davon ausgegangen werden kann, dass eine planwidrige Lücke, die Voraussetzung für diese Analogie ist, vorliegt4. Des Weiteren hat der BGH einfachen Lizenzen „dinglichen“ Charakter zugesprochen, so dass diese auch nach erfolgreichem Rückruf des ausschließlichen Nutzungsrechts, woraus sich die einfachen Lizenzen ableiten, nicht erlöschen5.

1 LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811 f. und dazu auch vor allem die Anmerkung von Grützmacher, S. 814. 2 LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811 f., LS 2 S. 2 m. krit Anm. Grützmacher, CR 2004, 814 und ausführlicher Grützmacher, CR 2006, 289. 3 BGH v. 25.4.2002 – IX ZR 313/99, NJW 2002, 2783, und dazu Grützmacher, Hinterlegungsvereinbarung, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Kap. 1.7 Rz. 33 ff. 4 S. Grützmacher, CR 2004, 815 in seiner Anmerkung zu dem Urteil des LG Mannheim. 5 BGH v. 26.3.2009 – I ZR 153/06 – Reifen Progressiv, CR 2009, 767; s dazu Dieselhorst, CR 2010, 69; s.a. für Kündigung zum Bestand der Tochterrechte BGH v. 19.7.2012 – I ZR 70/12, CR 2012, 572 – M2 Trade.

Schneider

1087

L Rz. 143

Einzelprobleme

d) Absicherung der Urheberrechte bei Software-Überlassung 143

Zur Plausibilität trägt die Überlegung bei, dass letztlich mit der Argumentation des LG Mannheim generell keinerlei Softwareüberlassungsvertrag mehr denkbar wäre, bei dem mehr als das Stück Software „gekauft“ wird, weil überall eine Absicherung der Urheberrechte, soweit sie beim Lizenzgeber verbleiben, Gegenstand des Vertrags ist. Der einfachste Fall ist wohl der, dass beim Ziehen der Sicherungskopie – was generell erlaubt ist – der entsprechende Vermerk verbleiben soll.

144

Von der Plausibilität her wäre es im Übrigen so, dass die „Lizenz“ unter insolvenzrechtlichen Gesichtspunkten noch strikter als bisher in die „typische“ Lizenz, die eher mietrechtlich einzuordnen ist und in die nur so bezeichnete, allgemeine Lizenz eingeteilt wird, die sehr wohl kaufrechtlich orientiert sein kann. Das Insolvenzproblem eines nicht erfüllten Vertrages würde sich zentral für den mietrechtlich ausgerichteten Vertrag stellen1.

145

Insolvenzsicher wäre nach Rössel nur der käufliche Erwerb von Software, der zur insolvenzrechtlich ungestörten Nutzung befähigt, und dies nur, sofern der Kaufpreis bezahlt ist2. Dies deckt sich mit der Einschätzung der Wirkung der BGH-Entscheidung zum dinglichen Charakter der einfachen Lizenz3. Zentral wäre in jedem Fall, dass eine geeignete Rechtseinräumung sowohl im Überlassungsvertrag für die Software selbst/im Beschaffungsvertrag enthalten ist, als auch deren Entsprechung im Quellcode- bzw. EscrowVertrag. 5. Gegenmodell LG Frankfurt, Software als Sache

146

Dass dabei der Quellcode ein eigenes Schicksal haben kann, das abgeschlossen behandelt werden kann, zeigt die Entscheidung des LG Frankfurt a.M. vom 10.11.20044. Diese Entscheidung ist nicht unmittelbar mit der Entscheidung des LG Mannheim gleichzusetzen. Sie betrifft jedoch zentral die Frage, um welche Art von Beschaffenheit es sich bei Software handelt und wie die „Eigentumslage“ hieran beurteilt werden kann. Das LG Frankfurt hat u.a. festgestellt, dass die dortige Klägerin „Eigentümerin der im Klageantrag zu 1) näher bezeichneten Softwaremodule“ ist und hat dann des Weiteren ausgeführt, dass zwar Eigentum nur an Sachen, mithin körper-

1 S.a. Rössel, ITRB 2003, 205. 2 Rössel, ITRB 2003, 206. 3 BGH v. 26.3.2009 – I ZR 153/06 – Reifen Progressiv, CR 2009, 767; BGH v. 19.7.2012 – I ZR 70/12, CR 2012, 572 und dazu Seegel, CR 2013, 205; s. aber Dieselhorst, CR 2010, 69, IV.3.b im Hinblick auf § 103 InsO und die Fälle, in denen etwa verbliebene Nebenpflichten noch erhebliches Gewicht hätten. Hier würde dann bei Wahl der Erfüllungsverweigerung BGH v. 25.4.2002 – IX ZR 313/99, NJW 2002, 2783, greifen, s.unten Rz. 155. 4 LG Frankfurt a.M. v. 10.11.2004 – 2-06 O 142/04.

1088

Schneider

Hinterlegung von Software, Escrow

Rz. 148

L

lichen Gegenständen besteht und Computerprogramme für sich genommen keine solchen körperlichen Gegenstände sind1. „Nach der Rechtsprechung ist nur die Verkörperung der Programme auf einem Datenträger als Sache anzusehen (vgl. BGH NJW 1993, 2436, 2438). Vorliegend ist die Sache im Rechenzentrum der … aufgespielt. Vermutlich ist sie Bestandteil des Speichermediums eines Servers. Unerheblich ist, dass auf dem Speichermedium natürlich auch andere Softwareprogramme aufgespielt sind und auch andere Software Bestandteile des Systems enthalten sind, an denen die Klägerin kein Eigentum beansprucht. Voraussetzung für die Sachqualität ist nur, dass die Softwaremodule auf irgendeinem Speichermedium aufgespielt sind und damit ‚verkörpert‘ im Sinne des § 90 BGB sind (vgl. BGH NJW 1992, 2436, 2438). Der sachenrechtliche Spezialitätsgrundsatz ist durch die Bezeichnung der einzelnen Module gewahrt. Die mit … bzw. … u.Ä. bezeichneten Programmteile sind klar individualisierbare Datenmengen des Gesamtprogramms. Der Programmcode des Moduls … ist z.B. aus dem Gutachten der Klägerin … ersichtlich. Die Module sind folglich eigentumsfähige Sachen.“2

Das Gericht behandelt dann weiter den Verbleib des Eigentums und stellt dazu fest, dass die Übereignung durch „Abtretung des Herausgabeanspruchs“ erfolgte3. Hinsichtlich des Rechts an diesem Programm führt dann das Gericht zu 147 dem Klageantrag 2), der als ebenfalls begründet angesehen wurde, weiter aus. Der Klageantrag 2) hatte zum Gegenstand, dass festgestellt wird, dass die Klägerin Inhaberin der zeitlich unbeschränkten und im Sinne des § 31 Abs. 3 UrhG ausschließlichen und urheberrechtlichen Nutzungsrechts zur Weiterentwicklung und unbeschränkten Verwertung aller Softwaremodule sowohl im Objektcode als auch im Quellcode ist. Hierzu führt also das Gericht weiter aus4: „Gemäß § 4 Nr. 2 des Einbringungsvertrages hat die Beklagte das ausschließliche Nutzungsrecht entsprechend § 34 UrhG an die Klägerin übertragen. Die Parteien gehen übereinstimmend davon aus, dass die Zustimmung der Urheber nach § 34 Abs. 1 UrhG für die Übertragung der Rechte, die Gegenstand des Einbringungsvertrages sind, vorlag. § 4 Nr. 2 des Vertrages sieht vor, dass die Beklagte „alle ihr zustehenden Nutzungs-, Weiterentwicklungs- und Verwertungsrechte der Einbringenden an … auf die Klägerin überträgt. Die Beklagte hat mit Schriftsatz … unstreitig gestellt, dass es sich bei … um das später unbenannte System handelt. Hierzu gehören auch die im Antrag bezeichneten Module. Die Formulierung ‚alle … Nutzungsrechte‘ spricht dafür, dass ein ausschließliches Nutzungsrecht eingeräumt wurde. Dies ergibt sich im Übrigen auch aus der Systematik des Vertrages. … Eine Vertragsauslegung nach der ‚Zweckübertragungstheorie‘ im Sinne des § 31 Abs. 5 UrhG führt zu keinem anderen Ergebnis.“

Die Entscheidung des LG Frankfurt hat insofern an Bedeutung bzw. Wirkung verloren, als inzwischen das Ergebnis durch höhere Gerichte ausführ1 LG Frankfurt a.M. v. 10.11.2004 – 2-06 O 142/04 unter Hinweis hier auf Palandt/ Heinrichs, 63. Aufl., § 90 BGB Rz. 2. 2 LG Frankfurt a.M. v. 10.11.2004 – 2-06 O 142/04. 3 LG Frankfurt a.M. v. 10.11.2004 – 2-06 O 142/04. 4 LG Frankfurt a.M. v. 10.11.2004 – 2-06 O 142/04.

Schneider

1089

148

L Rz. 149

Einzelprobleme

licher erarbeitet wurde. Zudem wird trotz der oben zitierten Entscheidungen (Kap. B Rz. 14, 34) immer noch Software der Sachcharakter abgesprochen1 (und wenn es nur geschieht, um bei Erstellung und Anpassung die Wirkung des § 651 BGB zu vermeiden)2. Zum anderen erscheint die fragliche Nutzungsrechtseinräumung wenig gelungen, da zu allgemein3. 6. Insolvenz-unabhängige, aufschiebend bedingte Verfügung: BGH vom 17.11.2005 149

In einer Entscheidung vom 17.11.20054 hat der BGH eine Klausel als insolvenzfest angesehen, die wie folgt lautete: „Dieser Vertrag kann von jedem Vertragspartner nur bei Vorliegen eines wichtigen Grundes – ohne Einhaltung einer Kündigungsfrist – gekündigt werden. Ein wichtiger Grund liegt vor, wenn Tatsachen gegeben sind, aufgrund derer den Kündigenden unter Berücksichtigung aller Umstände des Einzelfalles und unter Abwägung der Interessen der Vertragsteile die Fortsetzung des Vertrages nicht mehr zugemutet werden kann. Bei Kündigung dieses Vertrages durch die Firma m. oder die Firma p. gehen die Source-Codes von A. in der zum Zeitpunkt der Kündigung aktuellen Version inkl. der Nutzungs- und Vertriebsrechte dieser Version auf die Firma p. über. Für den Übergang des Source-Codes sowie der Nutzungs- und Vertriebsrechte zahlt die Firma p. eine einmalige Vergütung in Höhe des Umsatzes der letzten sechs Monate vor Ausspruch der Kündigung.“

150

Dazu hat der BGH in der erwähnten Entscheidung festgestellt: „a) Eine aufschiebend bedingte Verfügung über ein künftige Sache oder ein künftiges Recht ist insolvenzfest, wenn der fragliche Gegenstand bis zur Insolvenzeröffnung entstanden ist und danach die Bedingung eintritt. b) Wenn insolvenzfest vereinbart wird, die Ausübung eines Kündigungsrechts sei die aufhebende Bedingung für einen Rechtsübergang, scheitert dieser nicht daran, dass er vom Willen des Berechtigten abhängt. c) Hat vor Insolvenzeröffnung – wenngleich aufschiebend bedingt – ein dinglicher Rechtsübergang stattgefunden, kann der Insolvenzverwalter diesen nicht mehr dadurch verhindern, dass er die Nichterfüllung des zugrundeliegenden Vertrages wählt.“5

151

Die oben zitierte Klausel stand in einem Vertrag aus dem Jahr 1998 über Nutzung, Weiterentwicklung und Vertrieb der „A.-Produkte und aller daraus resultierenden Zusatzmodule“. Am 1.10.2001 wurde das Insolvenzver1 Auch wenn dieser etwa vom BGH – mit ganz ähnlicher Begründung, Software bedarf immer der Repräsentation auf einem Datenträger wie Stick, Server … – bejaht wurde (BGH v. 15.11.2006 – XII ZR 120/04, CR 2007, 75, dazu Kap. B Rz. 52). 2 S. Kap. B Rz. 91 ff. 3 S. etwa BGH zu Übersetzerverträgen (BGH v. 7.10.2009 – I ZR 38/07 – Talking to Addison, NJW 2010, 771). 4 BGH v. 17.11.2005 – IX ZR 162/04, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg. S.a. Berger, CR 2006, 505. 5 BGH v. 17.11.2005 – IX ZR 162/04, LSe, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg.

1090

Schneider

Hinterlegung von Software, Escrow

Rz. 155

L

fahren eröffnet. Der Insolvenzverwalter erklärte gegenüber der dortigen Beklagten den Nichteintritt in den Nutzungsvertrag gemäß § 103 InsO, woraufhin die Beklagte den Vertrag kündigte und die Übergabe der SourceCodes zu der nunmehr aktuellen Version +6 forderte, während der Vertrag ursprünglich zum Stand der Version +3.1 geschlossen worden war. Dass im Ergebnis die dann folgende Kündigung als Reaktion auf die Ableh- 152 nung des Eintritts gemäß dem Vertrag genau die gleiche Wirkung hat wie eine Auflösungsklausel, hat der BGH nicht übersehen1. Gleichwohl hat er die fragliche Klausel für wirksam erachtet. Demnach ist es möglich, was dann erst recht für Escrow-Vereinbarungen gelten muss, eine nicht konkret auf den Insolvenzfall, sondern auf die Unzumutbarkeit der Fortsetzung des Vertrages gerichtete Klausel zu schaffen, die zur Herausgabe des Quellcodes seitens des Escrow-Agenten führt. Dieser direkte Weg kann insolvenzfest gestaltet werden, da das so geschaffene „Zugangsrecht“ die erforderliche „Aussonderungskraft“ hat2. Erst recht wird es dann wirksam möglich sein, den Weg über den Escrow-Vertrag zu gehen. Besonders zu erwähnen ist allerdings in diesem Zusammenhang, dass im 153 fraglichen Fall des BGH für die Herausgabe des Quellcodes eine gesonderte Vergütung ausgeworfen war. Normalerweise hätte man dies evtl. als eher schädlich angesehen, weil insoweit noch eine Vergütung zu zahlen und somit der Vertrag noch nicht erfüllt wäre. Konkret hat der BGH dies aber gerade nicht als schädlich angesehen, sondern als einen Aspekt herangezogen, warum insoweit keine Benachteiligung vorliegt. Weiter war für den BGH von besonderer Bedeutung, dass durch die fragliche Regelung nicht einfach eine Automatik besteht, die zur Auflösung bzw. zur Herausgabeverpflichtung führt3.

154

Es sind Fragezeichen gegenüber der Entscheidung des BGH angebracht, ins- 155 besondere, ob der Entscheidungsstrang so weitergeführt werden wird, wie er sich auch aufgrund der Zitate in der BGH-Entscheidung aus früheren Entscheidungen heraus andeutet4. Auch stellt sich urheberrechtlich die Frage, inwieweit ein dinglicher Rechtsübergang aufschiebend bedingt an noch nicht bestehender Software möglich ist5.

1 BGH v. 17.11.2005 – IX ZR 162/04, Rz. 24, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg. 2 Berger, CR 2006, 505 (510). 3 BGH v. 17.11.2005 – IX ZR 162/04, Rz. 18, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg. 4 Die Entwicklung führt von BGH v. 27.5.2003 – IX ZR 51/02, BGHZ 155, 87 = MDR 2003, 1136 über BGH v. 29.6.2004, NZI 2004, 583 zu dieser Entscheidung vom 17.11.2005 i.V. auch mit der Aufgabe der „Erlöschenstheorie“, die hiermit nochmals bestätigt wurde (s. dazu BGH v. 25.4.2002 – IX ZR 313/99, MDR 2002, 1270 = ZIP 2002, 1093). 5 Bejahend schon Karger, CR 2001, 357.

Schneider

1091

L Rz. 156

Einzelprobleme

156

Weiter wird zu prüfen bzw. zu verfolgen sein, ob die urheber- und vertragsrechtliche Qualifikation des BGH1 – Lizenzvertrag als Dauernutzungsvertrag und somit Rechtspacht mit der Folge der Einordnung bei §§ 108, 112 InsO – Bestand hat und vor allem haben soll. Die Anwendung von Kaufrecht bei dauerhafter Überlassung von Software, zumindest über § 453 BGB, sollte alternativ gesehen werden bzw. möglich bleiben.

157

Vertragsrechtlich wird den Parteien im Hinblick auch auf den Escrow-Vertrag zu empfehlen sein, neben den sonstigen Herausgabefällen und den Berechtigungen des Kunden wie Änderung, vor allem Bearbeitung und Übersetzung, sowie ggf. Vervielfältigung der Bearbeitungen, einen Herausgabefall zu schaffen, der nicht auf Insolvenz abstellt: a) Es besteht ein Dauerschuld(-ähnliches) Rechtsverhältnis wie Pflege-, Vertriebs- oder ähnlichen Vertrag: Die Herausgabe des Quellcodes – ggf. einer Kopie, wenn der Kunde nicht ausschließlich berechtigt sein soll – hängt vom Eintritt der aufschiebenden Bedingung ab, dass ein wichtiger Grund vorliegt, der den Kunden zur Kündigung des Vertragsverhältnisses berechtigt. Die Vergütungsfrage sollte klar geregelt sein, evtl. als bereits erledigt ausgewiesen werden. b) Der Beschaffungsvertrag ist erfüllt, lediglich der Quellcode ist noch nicht an den Kunden übergeben: Die Herausgabe des Quellcodes – ggf. einer Kopie, wenn der Kunde nicht ausschließlich berechtigt sein soll – hängt vom Eintritt der aufschiebenden Bedingung ab, dass der Kunde sich in einer wesentlichen Frage der Nutzbarkeit der Software ohne den Quellcode nicht helfen kann und der Lieferant keine Abhilfe innerhalb angemessener Frist, auch nicht gegen angemessene Vergütung, schafft. Die Vergütungsfrage sollte auch für diesen Fall klar geregelt sein, evtl. als bereits erledigt ausgewiesen werden.

VII. Prozessuale Verwertung, Vorlage, Beweis- und Befundsicherung 158

Soweit ersichtlich, hat in der Praxis die Vorlage an ein Gericht bei dem Escrow-Vertragsverhältnis insoweit keine Rolle gespielt, als keine Entscheidung hierzu bekannt ist. Ganz pragmatisch erscheint dieser Weg vor allem als Streitvermeidungs-Maßnahme. Unklar erscheint aber, ob diese Maßnahme auch tatsächlich im Streitfalle funktionieren würde. Die Frage, die dahinter steckt, ist, welche Rolle genau der Escrow-Agent spielt. Wenn es so wäre, dass der dort lagernde Quellcode eigentlich dem Auftraggeber „gehört“, so wäre er nicht anders zu behandeln als etwa ein Lagerunternehmen, das vorübergehend die Unterlagen oder sonstige Gegenstände des Auftraggebers bei sich verwahrt. Er wäre reiner Erfüllungsgehilfe, für den allerdings der Auf1 BGH v. 17.11.2005 – IX ZR 162/04, Rz. 21, MDR 2006, 711 = CR 2006, 151 m. Anm. Plath/Scherenberg.

1092

Schneider

Hinterlegung von Software, Escrow

Rz. 162

L

traggeber haften würde. Würde der Auftraggeber verurteilt, den Quellcode vorzulegen, so müsste er seinen Auftragnehmer entsprechend anweisen. Adressat des entsprechenden Vorlageantrags etwa seitens des Lizenzgebers oder des Insolvenzverwalters wäre nicht das Escrow-Unternehmen1. Bei all den Konstruktionen allerdings, bei denen der Escrow-Agent zumindest 159 auch für den Lizenzgeber „verwahrt“, wäre die Situation der Doppel-Treuhand zu berücksichtigen. Jedenfalls könnte dann der Lizenzgeber selbst, ggf. unmittelbar auch aus vertraglicher Position heraus, gegen den Escrow-Agenten vorgehen, insbesondere, wenn sich dessen Leistung als Verletzung des Vertrages mit ihm, dem Lizenzgeber, erweisen würde. Im Ergebnis könnte dies bedeuten, dass eine Vorlage gegenüber dem Gericht 160 zu Beweiszwecken von jedem der beiden Vertragspartner verlangt und von jedem der beiden Vertragspartner des jeweils anderen Vertragspartners verhindert werden könnte. Im Hinblick auf Mangel- bzw. Haftungsansprüche könnte es noch beson- 161 ders interessant sein, den Zustand der Software zu einem ganz bestimmten Zeitpunkt zu beweisen. Ein genereller „Gewährleistungsausschluss“, wenn der Kunde Änderungen an der Software vorgenommen hat, wäre wohl zumindest in AGB unwirksam. Dem Kunden müsste der Entlastungsbeweis eröffnet werden, dass die Änderungen nicht den streitigen Mangel herbeigeführt haben, evtl. auch, dass die Änderungen nicht die Analyse- und Bearbeitungsarbeiten wesentlich erschwert haben (im Hinblick auf Mehraufwand). In diesem Falle dürften die Rechte an dem Quellcode weniger eine Rolle spielen als schlicht die „Befundsicherung“. Im Rahmen einer solchen Situation wäre es wohl treuwidrig, wenn einer der beiden Vertragspartner versuchen würde, die Vorlage an das Gericht zu vereiteln. Immerhin käme aber auch in Betracht, wenn dem nicht Treuepflichten entgegenstehen, dass der Escrow-Agent bzw. dessen Mitarbeiter als sachverständige Zeugen einvernommen werden.

VIII. Leistungsstörungen, Mitwirkung Das Leistungsstörungsrecht der Escrow-Vertragspartner gegenüber dem Es- 162 crow-Agenten wird sich nach dem Leitbild des Geschäftsbesorgungsvertrags orientieren, so dass die §§ 280 ff. BGB unmittelbar zur Anwendung kommen würden (mangels eigener gesetzlicher Regelungen). In vielen Fällen werden aber Schlecht- und Nichtleistungen des Escrow-Agenten darauf be1 Zur Vorlageverpflichtung im Rahmen des Besichtigungsanspruchs aufgrund geringerer Voraussetzungen als bei Patentverletzung s. vor allem BGH v. 2.5.2002 – I ZR 45/01, MDR 2003, 167 = CR 2002, 791 im Vergleich zu BGH v. 8.1.1985 – X ZR 18/84, MDR 1985, 579 = CR 1985, 77; s.a. BGH v. 20.9.2012 – I ZR 90/09, CR 2013, 284 – UniBasic – IDOS und dazu Tennefeld, C., CR 2013, 417 zum Besichtigungsanspruch, auch wenn es nur um teilweise Übernahme geht.

Schneider

1093

L Rz. 163

Einzelprobleme

ruhen, dass ihm von Seiten einer der beiden Vertragspartner nicht die entsprechende Leistungsmöglichkeit gegeben wurde. Der simpelste Fall ist, dass der Quellcode noch nicht vom Lizenzgeber beim Escrow-Agenten eingetroffen ist oder dort bereits mangelhaft angekommen ist, so dass er z.B. nicht ausführbar und die Folge ist, dass entweder der Kunde gar nichts erhält, wenn er die Herausgabe (auch berechtigt) verlangen würde bzw. mit dem nichts anfangen kann, was er erhält. Zu den wesentlichen Pflichten und damit auch zu den Leistungsstörungsmöglichkeiten seitens des Escrow-Agenten würde gehören, dass er dafür sorgt, dass die beiden Vertragspartner wiederum ihre Pflichten ordnungsgemäß erfüllen, die im Vertrag sorgfältig ausgearbeitet sein sollten. 163

Diese Vertragskonstruktion müsste es dem Escrow-Agenten erlauben, die Defizite, die der jeweils eine Vertragspartner in das Vertragsverhältnis eingebracht hat, dem jeweils anderen entgegenhalten zu können. Dies wird nur dann nicht gelten bzw. wirksam sein, wenn der Escrow-Agent seinerseits nicht die ihm obliegenden Pflichten zur Beitreibung etwa des Quellcodes, zu dessen Verifizierung u.Ä., auch zur Beanstandung, erfüllt hat.

164

Bei der oben angedeuteten Konstruktion, die die möglicherweise einzig insolvenzfeste ist, dass nämlich dem Auftraggeber die gesamten Materialien zum „Eigentum“ übertragen werden1 und er dann sich selbst beschränkend diese Materialien beim Escrow-Agenten hinterlegt, wobei die Ablieferung an den Escrow-Agenten evtl. direkt von Seiten des Lizenzgebers erfolgt, sind primär die Pflichten seitens des Escrow-Agenten gegenüber dem Auftraggeber ausgeprägt. Hinsichtlich des Auftragnehmers würde es sich im Wesentlichen um Rechte handeln, wonach sich nämlich der Lizenzgeber verpflichtet hat, entsprechende Leistungen, die den Escrow-Agenten in die Lage versetzen, seine Funktion auszuüben, zu erfüllen.

165

Grundsätzlich kommt auch immer in Betracht, dass der jeweils andere Vertragspartner an den Leistungen des Escrow-Agenten mitzuwirken hat. Trifft etwa der Escrow-Agent eine Beanstandung im Rahmen der Verifikation, kann es sein, dass nicht nur der Lizenzgeber, sondern auch der Lizenznehmer/Auftraggeber in der Lage und vielleicht nur er in der Lage ist, die Beanstandung aufzuklären. Dies betrifft Lesbarkeiten des Materials, Ausführung von Makros u.Ä. Grundsätzlich wird es im Escrow-Vertrag bei solchen Mitwirkungsleistungen der Vertragspartner um Nebenpflichten nach altem Recht gehen. Es kann sich deshalb empfehlen, die Mitwirkung besonders auszugestalten und so zu stärken, dass daraus Hauptpflichten werden. Da die beiden Vertragspartner des Escrow-Agenten über den Beschaffungsvertrag verbunden und in diesem die Grundregeln auch für das Escrow niedergelegt sind, kann es sich empfehlen, diese Mitwirkungsleistungen bereits

1 Argumentativ gut begründbar bzw. zu unterstützen mit OLG Hamm v. 28.11.2012 – 12 U 115/12, CR 2013, 214 i.V.m. EuGH v. 3.7.2012 – C-128/11, CR 2012, 498.

1094

Schneider

Hinterlegung von Software, Escrow

Rz. 168

L

dort festzuhalten und zwar in dem Sinne, dass es sich zugleich auch um Pflichten gegenüber dem jeweils anderen Vertragspartner handelt. Bei Beendigung der Escrow-Vereinbarung hätte im Rahmen der Geschäfts- 166 besorgung der Escrow-Agent das von ihm Erlangte zurückzugeben. Es war schon deutlich geworden, dass eine entsprechende Rückgabepflicht an den Lizenzgeber im Hinblick auf das Dauerschuldverhältnis Escrow im Verhältnis zum Lizenzgeber eher problematisch ist (weil vom Insolvenzverwalter angreifbar bzw. anfechtbar und vor allem im Hinblick auf die Erfüllung verweigerbar). Es kann sich deshalb empfehlen, statt der „Rückgabe“ entweder die „Auskehr“ an den Kunden zum endgültigen Verbleib zu vereinbaren. Dies würde auch gut zum Ende der Selbstrestriktion seitens des Kunden passen, wenn dieser hinterlegt hat. Alternativ istes denkbar, dass der Escrow-Agent nach angemessener Frist das Material löscht. Hier können Beweisprobleme evtl. noch nach Beendigung des Escrow-Vertrages auftreten und dann wieder das oben angedeutete Problem mit sich bringen, inwieweit dann der Escrow-Agent noch passiv-legitimiert wäre, etwa im Hinblick auf Vorlage oÄ. Infolge dessen wäre eigentlich die Übergabe an einen der beiden Vertragspartner besser, damit der Escrow-Agent sich entlasten kann und die Vertragsverhältnisse klargestellt sind. Im Falle der Treuhand-Konstruktion wird es gar nicht anders gehen, als eine 167 klare Vereinbarung dahingehend zu treffen, welcher der beiden „Treugeber“ bei Beendigung des Escrow-Verhältnisses die Materialien erhalten soll.

IX. Vorschläge für die Vertragsgestaltung 1. Verhältnis zum Beschaffungsvertrag Einerseits ist eine Synchronisierung des Escrow- mit dem Beschaffungsver- 168 trag zu empfehlen. Dazu gehört einmal, dass die Beschaffung die Rechtseinräumung so gestaltet, dass auch der Fall der Bearbeitung des Quellcodes umfasst und zugleich klargestellt ist, dass die Quellcode-Überlassung – via Escrow – bereits durch die Vergütung gemäß Beschaffungsvertrag abgegolten ist1. Die insoweit empfohlenen Eckpunkte im Überlassungsvertrag sind: – Vertragliche Verpflichtung des Anbieters zur Hinterlegung, – Bezeichnung der vorgesehenen Hinterlegungsstelle (Escrow-Agent), – Vertragliche Verpflichtung der Parteien zum Abschluss des Escrow-Vertrags, 1 Der Escrow-Vertrag soll „sozusagen Teil“ des zugrundeliegenden Erwerbsvertrages sein, jedenfalls in Grundzügen: Redeker, IT-Recht in der Praxis, Rz. 595 unter Hinweis auf Karger, in: Kilian/Heussen (Hrsg.) Computerrechtshandbuch, Abschn. 36, nun Kap. 21 Rz. 72; zu Stichworten/Themen s.a. Rath, CR 2013, 78.

Schneider

1095

L Rz. 169

Einzelprobleme

– Möglichst genaue Bezeichnung des zu hinterlegenden Materials (Software, Modulliste, Version(en), Dokumentation, Tools usw., – Bestimmung des Übergabezeitpunkts, – vorgesehene Dauer der Hinterlegung, – genaue Beschreibung der Herausgabefälle und – genaue Beschreibung des Herausgabeverfahrens, – Rechte des Anwenders beim Umgang mit dem Quellcode, auch Pflichten, – Kostenregelung1. 169

Andererseits sind die meisten der vorstehenden Punkte auch wichtige Bestandteile des Escrow-Vertrags. Eine sehr enge Verknüpfung fördert die Gefahr, dass bei fehlender Insolvenzfestigkeit des Escrow-Vertrags dies auch auf den Beschaffungsvertrag durchschlägt, der dadurch vom Dauerschuldmoment des Escrow-Vertrags „infiziert“ wird2. 2. Die Lösung des Insolvenzproblems über Nießbrauch beim Beschaffungsvertrag

170

Die Lösung des Insolvenz-Problems gegenüber der Beschaffung kann im Konzept des Nießbrauchs als Lösung des Insolvenzproblems gesehen werden3.

171

Plath legt zum einen dar, dass es durchaus möglich ist, Nießbrauchsrechte an Software wirksam zu gewähren, zum anderen, dass eine Verknüpfung des Nießbrauchs mit dem Lizenzvertrag zwar möglich, es aber unsicher ist, inwieweit „der Ausschluss einzelner Nutzungen mit dinglicher Wirkung im Rahmen des § 1030 Abs. 2 BGB möglich ist“4.

172

Das Besondere im Hinblick auf die Entscheidung des LG Mannheim ist, dass ein Anspruch des Nießbrauchers auf weitere Leistungen nicht besteht. Der Inhaber des belasteten Rechts wird lediglich dazu verpflichtet, die Nutzung durch den Nießbraucher zu dulden. Weitere Leistungen muss er nicht erbringen. Allerdings stellt sich auch hier das Problem, dass der Auftraggeber/Kunde evtl. nicht den Quellcode direkt erhält, sondern nur über eine Hinterlegungsvereinbarung. Mit der Nießbrauchs-Konzeption dürfte sich die oben angedeutete Eigentumsangenäherte Position nicht vertragen, so dass das Problem der Nebenleistungen in Form der Hinterlegungsvereinbarung wohl bestehen bleibt.

1 Karger, in: Kilian/Heussen (Hrsg.) Computerrechtshandbuch, Kap. 21 Rz. 72. 2 Bei Escrow als Nebenpflicht i.S.d. LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811 f. und dazu auch vor allem die Anmerkung von Grützmacher, S. 814. 3 S. vor allem Plath, CR 2005, 613; s.a. Berger, GRUR 2004, 20; Kast/Schneider/ Siegel, K&R 2006, 446. 4 Plath, CR 2005, 613 (617).

1096

Schneider

Hinterlegung von Software, Escrow

Rz. 177

L

Wie erwähnt – siehe Rz. 138, 141 – hatte das LG Mannheim nicht berücksichtigt, dass (auch) die Erfüllungsablehnung (§ 103 InsO) den Vertrag bestehen lässt1.

173

3. Speziell Escrow während der Erstellung der Software Im Kontext des Buches geht es um Softwareerstellung. Es fällt dabei dem 174 Auftraggeber nicht so schwer, eine Klausel durchzusetzen, wonach ihm die Software auch im Quellcode zusteht, er hierauf einen Herausgabeanspruch hat und ihm das Recht der Bearbeitung zusteht. Entsprechendes gilt für Anpassungsverträge, wobei sich Escrow bereits für den Quellcode der Standardsoftware empfiehlt. Bei Scheitern des Projekts wäre der Auftraggeber – eine geeignete Verein- 175 barung vorausgesetzt – nicht nur berechtigt, sondern auch über die Quellcode-Herausgabe in der Lage, die Software selbst oder durch Dritte fertig stellen zu lassen. Im Falle der Insolvenz des Auftragnehmers stellen sich jedoch die Probleme der Vorausverfügung bzw. des noch nicht erfüllten Vertrags mit der Folge, dass der Insolvenzverwalter Erfüllung verweigern kann und die Rechtseinräumung („Lizenz“) nach § 103 InsO erlischt2. Eine Zerlegung des Vertrages nach Projektschritten liegt als Schutz nahe: 176 Der Auftraggeber erhält projektfortschrittsabhängig den jeweiligen Stand des Quellcodes und zahlt einen entsprechenden Teil der Vergütung. Dies würde vor allem passen, wenn insoweit ohnehin Teilabnahmen vorgesehen sind. Allerdings würde es nicht passen, wenn es sich bei den Zahlungen nur um Abschlagszahlungen handeln würde. Erfolg könnte dieses Modell insoweit haben, als der jeweilige Quellcode- 177 Stand übergeben und (zugunsten des Kunden) hinterlegt ist. Für zukünftige Quellcode-Stände würde die Herausgabe bei Erfüllungsverweigerung des Insolvenzverwalters scheitern3. Das Erlöschen der Rechte des Kunden könnte allerdings auch den Umfang bis zur bisherigen Fertigstellung umfassen. Dem ließe sich wohl nur begegnen, wenn man an der Software das Eigentum (zusammen mit dem gesamten „Material“) übertragen kann4. Dies wird bekanntlich bezweifelt5 Jedoch erscheint die Konstruktion der endgültigen Überlassung der Materialien als Vervielfältigungsexemplare – wenn der Auftragnehmer nicht die ausschließlichen Rechte erwirbt – an den Auftraggeber, der für sich selbst hinterlegt, im Einklang mit Autoren, die sogar 1 Grützmacher, in: Redeker (Hrsg.), Handbuch der IT-Verträge, Kap. 1.7 Rz. 33 unter Verweis auf BGH v. 25.4.2002 – IX ZR 313/99, NJW 2002, 2783. 2 Entsprechend LG Mannheim v. 27.6.2003 – 7 O 127/03, CR 2004, 811, s. oben Rz. 138 ff. 3 Wenn nicht aufschiebend bedingte Verfügung gem. BGH v. 17.11.2005 greift, s. Rz. 149 ff. 4 S. Karger, CR 2001, 357, auch zur Synchronisierung der Vergütung. 5 S.a. Rz. 56 ff. und 149 ff.

Schneider

1097

L Rz. 178

Einzelprobleme

geringere Anforderungen stellen (Oberscheidt1, Wallner2 und Hoeren3), auch im Hinblick auf das LG Mannheim4 insolvenzfest. Mit der Entscheidung des BGH vom 17.11.2005 wird als insolvenzfest gelten, dass eine aufschiebend bedingte Verfügung greift, auch wenn sie durch die Kündigung des Lizenznehmers ausgelöst wird. Der Grund darf jedoch nicht in der Insolvenz unmittelbar liegen5.

X. De lege ferenda 178

In den letzten Jahren wurde durch die Rechtsentwicklung der Charakter der Softwareüberlassung als „Lizenz“ immer stärker herausgestellt6. Ein Impuls dazu ist auch der „Online“-Vertrieb mit dem Problem der Erschöpfung und damit evtl. Wirksamkeit der Weitergabe- bzw. Abtretungsverbote7. Nach EuGH stellt sich das Erschöpfungsproblem bei Online-Bezug nicht mehr8.

179

Ein Referentenentwurf v. 11/20119 sieht – anders noch als der Entwurf BTDrucks 16/741610 – den Fall vor, dass der Insolvenzverwalter nach § 103 InsO-E die Erfüllung eines Lizenzvertrags ablehnt. Dann „kann der Lizenznehmer binnen eines Monats, nachdem die Ablehnung zugegangen ist, vom Verwalter oder einem Rechtsnachfolger den Abschluss eines neuen Lizenzvertrages verlangen, der dem Lizenznehmer zu angemessenen Bedingungen die weitere Nutzung des geschützten Rechts ermöglicht. Bei der Festlegung der Vergütung ist auch eine angemessene Beteiligung der Insolvenzmasse an den Vorteilen und Erträgen des Lizenznehmers aus der Nutzung des geschützten Rechts sicherzustellen; die Aufwendungen des Lizenznehmers zur Vorbereitung der Nutzung sind zu berücksichtigen, soweit sie sich werterhöhend auf die Lizenz auswirken.“11

1 Oberscheidt, Die Insolvenzfestigkeit der Softwarehinterlegung, S. 28 f. 2 Wallner, Die Insolvenz des Urhebers. Unter besonderer Berücksichtigung der Verträge zur Überlassung von Software. 3 Hoeren, CR 2005, 773. 4 Oberscheidt, Die Insolvenzfestigkeit der Softwarehinterlegung, S. 28 f. 5 S. oben Rz. 139 ff. 6 S. etwa Hilty, MMR 2003, 3; schon Moritz, CR 1993, 257 (341, 414); Moritz, CR 1994, 257; Moritz; MMR 2001, 94. 7 Zu der Diskussion zu „Gebrauchtsoftware“ nach BGH v. 3.2.2011 – I ZR 129/08, CR 2011, 223 Oracle v. UsedSoft, Leistner, CR 2011, 209; Moritz, K&R 2011, 240; Bräutigam, CRi 2012, 1; Marly/Nestler, LMK 2011, 31676; zu OLG Karlsruhe v. 27.7.2011 – 6 U 18/10; Wenn, jurisPR-ITR 19/2011 Anm. 3. 8 EuGH v. 3.7.2012 – C 128/11; s.a. Nachweise in Kap. B Rz. 3, 4, 34. 9 V. 7.12.2011; genannt § 108a – E 2012, s. PM des BMJ v. 23.1.2012. 10 § 108a InsO-E 2007 v. 22.8.2007, 1. Lesung 14.2.2008; Stellungnahme BITKOM v. 22.1.2008; DGRI v. 10.9.2007; s.a. Daneshzadeh Tabrizi, Lizenzen in der Insolvenz 2011. 11 S.a. Stellungnahme der DGRI CR 2012, 216.

1098

Schneider

Hinterlegung von Software, Escrow

Rz. 179

L

Auch der E. 2012 hat keine Chancen auf Realisierung. In späteren Entwurfsfassungen entfiel der Vorschlag zu § 108a-E „spurlos“1. Andererseits hält der Ruf nach dem Gesetzgeber auch nach den Meilenstein-Entscheidungen des BGH an2. Für Escrow ist aber schon jetzt davon auszugehen, dass die Vertragsverhältnisse für Tochterrechte insolvenzfest gestaltet werden können3.

1 RegE v. 12.7.2012 für ein Gesetz zur Verkürzung des Restschuldbeherrschungsverfahrens. So noch zum Entwurfsstand 7.12.2011 sehr kritisch Verweyen, K&R 2012, 563. 2 S. nur Seegel, CR 2013, 205 zu BGH v. 26.3.2009 – I ZR 153/06 – Reifen Progressiv – und BGH v. 19.7.2012 – I ZR 70/10 – M2 Trade. 3 Zu Hinweisen s. Rath, CR 2013, 78.

Schneider

1099

M. Öffentliche Förderung von Forschung und Entwicklung

I. Überblick . . . . . . . . . . . . . . . . . . . 1. Förderung von Forschung und Entwicklung . . . . . . . . . . . . . . . . . 2. Die Grenzen der Forschungsförderung nach dem Gemeinschaftsrahmen . . . . . . . . . . . . . . . 3. Quellen der Förderung . . . . . . . . a) Forschungsförderung in Deutschland. . . . . . . . . . . . . . . aa) Institutionelle Förderung. . . . . . . . . . . . . . . . . bb) Projektförderung . . . . . . . b) Forschungsförderung in Europa . . . . . . . . . . . . . . . . . . . . II. Zentrale Fragen des deutschen Zuwendungsrechts . . . . . . . . . . . 1. Arten und Formen der Zuwendungen in Deutschland . . . . . . . a) Zuordnung der Förderprogramme . . . . . . . . . . . . . . . . . . . b) Zuwendungen und Verträge . 2. Zuwendungsbestimmungen des BMBF. . . . . . . . . . . . . . . . . . . . a) Antragsverfahren bei der Projektförderung nach den NKBF . . . . . . . . . . . . . . . . . . . . . b) Nebenbestimmungen der Zuwendungsbescheide . . . . . c) Die wesentlichen Vorschriften der NKBF 98 . . . . . . . . . . . 3. Vertragsmuster für (Unter-)Verträge mit dem BMBF . . . 4. Weitere Zuwendungsbestimmungen . . . . . . . . . . . . . . . . . . . . . a) Bundesministerium für Verteidigung (BMVg) und Bundesamt für Wehrtechnik und Beschaffung (BWB) . . . . . b) Bundesministerium für Wirtschaft und Technologie (AiF-Förderung) . . . . . . . . . . . . c) Länderministerien und Zuwendungsbestimmungen anderer Einrichtungen . . . . . .

Rz.

Rz.

1

III. Zentrale Fragen des europäischen Zuwendungsrechts . 70 34 1. Die Forschungsrahmenprogramme (FRP) . . . . . . . . . . . . . . . . 71 a) Das 7. Forschungsrahmenprogramm (2007–2013) b) Horizon 2020 – Das Forschungsrahmenprogramm für Forschung und Innovation (2014–2020) 2. Die wichtigsten Zuwendungsbestimmungen im Überblick . . 82 a) EU-Projekte . . . . . . . . . . . . . . . 82 aa) Das Grant-Agreement zum 7. Forschungsrahmenprogramm. . . . . . . . . . 83 bb) Förderquoten und Kostenarten . . . . . . . . . . . . . . . 88 cc) Beteiligte an EU-Projekten . . . . . . . . . . . . . . . . . . . . 90 dd) Beteiligungsregeln und Antragsverfahren . . . . . . . 91 ee) Annex II (General Conditions) . . . . . . . . . . . . . . . . . . 96 (1) Kalkulation und Kosten . . . . . . . . . . . . . . . . . 97 (2) Gestiges Eigentum . . . 98 (3) Berichte. . . . . . . . . . . . . 104 (4) Haftung . . . . . . . . . . . . . 105 (5) Anwendbares Recht . . 107 (6) Der Muster-Konsortialvertrag DESCA. . . . . 108 b) Andere europäische Förderstellen . . . . . . . . . . . . . . . . . . . . 124

1

7 12 14 15 19 27 39 39 39 44 46

49 50 52 62 66

66

68

68

IV. Sonderfall Softwareerstellung . . 125 1. Die NKBF des BMBF . . . . . . . . . . 126 2. Vertragsbedingungen des Bundes für die Beschaffung von ITDienstleistungen (EVB-IT) und von DV-Anlagen und Geräten . . 128 3. Annex II (General Conditions) der EU . . . . . . . . . . . . . . . . . . . . . . . 131 V. Zusammenfassung . . . . . . . . . . . 132

Kaiser

1101

M Rz. 1

Einzelprobleme

I. Überblick 1. Förderung von Forschung und Entwicklung 1

Der hohe Stellenwert naturwissenschaftlicher Forschung und Entwicklung (FuE) für Staat und Wirtschaft wird zu Recht immer wieder betont. Am Beispiel des Speicherformats mp3 lässt sich eindrucksvoll belegen, wie eine einzige innovative Entwicklung den gesamten Wirtschaftszweig der Audio- und Videomärkte signifikant verändern kann. Entwicklungen mit ähnlicher Tragweite zeichnen sich auch in anderen Bereichen ab. Die Investitionen, um solche Entwicklungen zu ermöglichen, sind allerdings enorm und wären in vielen Bereichen ohne staatliche Unterstützung nicht möglich. FuE werden deshalb in Deutschland und Europa über staatliche Forschungsförderung nachhaltig unterstützt1. In Deutschland gibt es einen breiten Konsens in Parlament, Regierung und Justiz, dass dem Staat eine besondere Verantwortung für die Gewährleistung geeigneter Rahmenbedingungen für FuE zukommt2.

2

Die Ziele der EU-Mitgliedstaaten waren gemäß der Lissabon-Strategie (2000–2010) auf eine durchschnittliche Investitionsquote in FuE von 3 % des Bruttoinlandsprodukts (BIP) gerichtet3. Diese Größenordnung wurde in Deutschland bisher nicht erreicht. Die Gegenüberstellung der Zahlen ausgewählter Jahre im Zeitraum von 1981 bis 2011 ergibt die folgende Entwicklung der FuE-Investitionsquote in Deutschland4: 1981

1991

1995

2000

2002

2003

2004

2006

2008

2009

2010

2011

2,43 %

2,47 %

2,19 %

2,45 %

2,49 %

2,52 %

2,49 %

2,53 %

2,69 %

2,81 %

2,80 %

2,88 %

Die durchschnittliche FuE-Investitionsquote der EU-Mitgliedstaaten liegt bei 1,74 % (2008). Die OECD-Mitgliedstaaten weisen die durchschnittliche FuE-Investitionsquote von 2,5 % (2003) auf5. 1 Grundsätzlich zur Planung von Förderprogrammen und Zuwendungen Krämer/ Schmidt, Zuwendungsrecht – Zuwendungspraxis, Textsammlung, Stand September 2011, Abschnitt C. 2 Rosenberger, Wirtschaft und Verwaltung 3/2009, 133 ff. (zur Diskussion im Bundestag S. 133 f.); Überblick in Meusel, Außeruniversitäre Forschung im Wissenschaftsrecht, § 22 Rz. 336, S. 301 ff. m.w.N., auch: Flämig/Kimminich et al., Handbuch des Wissenschaftsrechts, Bd. 2, XII, S. 1379 ff. 3 KOM (2011) 808 endg. v. 30.11.2011, KOM (2010) 2020 endg. v. 3.3.2010, S. 5; KOM (2010) 546 endg. v. 6.10.2010, S. 4, S. 7. 4 Die Zahlen für die Jahre 1981 bis 2008 entstammen der Broschüre „Bildung und Forschung in Zahlen 2011“ des Bundesministeriums für Bildung und Forschung. S. http://www.datenportal.bmbf.de/portal/index.html (wie alle in diesem Abschnitt zitierten Internetseiten zuletzt konsultiert am 20.1.2013). Die Zahlen aus den Jahren 2009, 2010 und 2011 sind dem Bericht „Research, Innovation and Technological Performance. Report 2011“ der Expertenkommission Forschung und Innovation (EFI), Berlin 2011, entnommen. Die Zahlen für das Jahr 2012 lagen bei Verlagsschluss noch nicht vollständig vor. 5 Die Zahlen sind dem Bericht „Research, Innovation and Technological Performance. Report 2011“ der EFI, Berlin 2011, entnommen.

1102

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 5 M

Die FuE-Investitionen in Deutschland haben an Dynamik gewonnen. Im 3 Zeitraum zwischen 2005 und 2008 stiegen die Bundesausgaben um 1,9 Mrd. Euro (Anstieg um etwa 21 %), die Aufwendungen der Wirtschaft stiegen im selben Zeitraum um etwa 7,4 Mrd. Euro (Anstieg um etwa 19 %)1. Im Jahr 2009, inmitten der länderübergreifend ausgebrochenen Wirtschafts- und Finanzkrise, konnte der deutsche Staat die gesunkenen FuE-Investitionen der Wirtschaft ausgleichen: der Zuwachs staatlicher Ausgaben für FuE belief sich 2009 auf 5,9 % und betrug damit 32,3 % der gesamten deutschen FuEAufwendungen (30,7 % im Vorjahr 2008). Diese stiegen auf 66,7 Mrd. Euro2. Im Jahr 2010 stiegen die gesamten Ausgaben für FuE in Deutschland auf etwa 70 Mrd. Euro3. Die Wirtschaft investierte davon etwa 46,9 Mrd. Euro4. Die Europäische Union unterstützte mit dem 7. Forschungsrahmenpro- 4 gramm (2007–2013) u.a. die Bildung europäischer wissenschaftlicher Exzellenzzentren und die Ausprägung der Wissensgesellschaft im Europäischen Forschungsraum (ERA). Dies entsprach dem Ziel der Lissabon-Strategie (2000–2010), Europa als wettbewerbsstärkste wissensbasierte Wirtschaftsregion der Welt zu etablieren. Instrumente waren z.B. das sog. Wissensdreieck mit den Eckpunkten Forschung, Bildung und Innovation. Das Budget des Rahmenprogramms betrug ca. 54 Mrd. Euro (inkl. Euratom). Das folgende Forschungsrahmenprogramm, Horizon 2020 (2014–2020), zeichnet sich durch sein erhöhtes Budget aus, dessen Umfang zurzeit im Detail verhandelt wird. Der Vorschlag der Europäischen Kommission beläuft sich auf ca. 87 Mrd. Euro5. Zu den Leitideen der die Lissabon-Strategie ablösenden Strategie „Europa 2020“ (2010–2020) gehört die Realisierung der sog. Innovationsunion6 der Mitgliedstaaten. Die Bedeutung des Europäischen Forschungsraums, dessen Neugestaltung seit dem 6. Forschungsrahmenprogramm (2002–2006) vorangetrieben wird, ist seit der Vertragsrevision von Lissabon im Jahr 2009 nun auch im Vertrag über die Arbeitsweise der Europäischen Union (AEUV) verankert: Art. 179 Abs. 1 AEUV befürwortet die Schaffung eines „europäischen Raums der Forschung“ als Mittel zur Stärkung der wissenschaftlichen und technologischen Grundlagen der Union. In wettbewerbsrechtlicher Hinsicht ist die EU bestrebt, die Forschungsförderung in Europa in einem Gleichgewicht zu halten, um die Funktions-

1 S. „Bundesbericht Forschung und Innovation 2010“ des Bundesministeriums für Bildung und Forschung, S. 19, http://www.bmbf.de/de/12210.php. 2 S. die Mitteilung des Bundesministeriums für Bildung und Forschung unter http://www.bmbf.de/de/12210.php. 3 Pressemitteilung des Bundesministeriums für Bildung und Forschung 158/2011 v. 5.12.2011. 4 Pressemitteilung des Bundesministeriums für Bildung und Forschung 158/2011 v. 5.12.2011. 5 Pressemitteilung der Europäischen Kommission IP/11/1475 v. 30.11.2011. 6 KOM (2010) 546 endg. v. 6.10.2010.

Kaiser

1103

5

M Rz. 6

Einzelprobleme

fähigkeit des Marktes durch die sektoral oft hohe Forschungsförderung nicht zu gefährden1. Hierzu existiert als Ausprägung des Art. 107 AEUV der sog. Gemeinschaftsrahmen. Dieser legt als verbindliche Richtlinie der europäischen Wirtschaftsminister die zulässigen Förderquoten für FuE für verschiedene Arten der Forschung fest2. Auch im Wettbewerbs- und Kartellrecht hat die EU die Kooperationen für FuE im Auge. In Ergänzung zu Art. 101 AEUV bestehen die Gruppenfreistellungsverordnungen für „Forschung und Entwicklung“ aus dem Jahr 2001 sowie für „Technologietransfer“ aus dem Jahr 2004. Diese Vorschriften sollen kartellrechtswidrige Abreden in Kooperations- und Lizenzverträgen vermeiden3. Seit dem 1.7.2005 wurde das europäische Wettbewerbs- und Kartellrecht zum primären Prüfungsmaßstab der europäischen Nationalstaaten, weshalb in Deutschland das Gesetz gegen Wettbewerbsbeschränkungen mit der 7. Gesetzesnovelle4 geändert wurde. Die Auswirkungen dieser Reform werden diskutiert und können für die öffentliche Förderung von Bedeutung sein5. 6

Die Staaten der EU haben jedenfalls sowohl einzelstaatlich als auch in der Gemeinschaft stets unterstrichen, dass Forschungsförderung und Forschungskooperationen im europäischen Wirtschaftsraum große Aufmerksamkeit verdienen und dabei die Funktionsfähigkeit der Märkte gewährleistet bleiben muss6. 2. Die Grenzen der Forschungsförderung nach dem Gemeinschaftsrahmen

7

Das sog. Beihilferecht der EU richtet sich mit Rahmenbedingungen für alle Subventions- und Förderbereiche an die europäischen Mitgliedstaaten. Es gilt im Verhältnis der EU zu den Regierungen der Mitgliedstaaten7. Die Forschungsförderung kann den Regelfällen von Art. 107 AEUV nicht klar zugeordnet werden, ist aber jedenfalls nicht ausdrücklich als zulässige

1 Heidenhain, Handbuch des Europäischen Beihilfenrechts, § 17 Rz. 121 ff., 136. 2 Grabitz/Hilf, Das Recht der Europäischen Union, Textsammlung, Art. 81, Rz. 259 ff.; Grabitz/Hilf, Das Recht der Europäischen Union, Textsammlung, Art. 81, Rz. 521 ff. 3 Zur Auswirkung einzelner Vorschriften des EU-Kartellrechts auf Kooperationsverträge in FuE vgl. Wurzer/Kaiser, Handbuch Internationaler Know-howSchutz, S. 295 ff. 4 Gesetz gegen Wettbewerbsbeschränkungen (GWB), BGBl. I 2005, S. 2114. 5 S. u.a. das Gutachten der Monopolkommission unter http://www.monopolkom mission.de/sg_41/text_s41.pdf. 6 Rosenberger, Wirtschaft und Verwaltung 3/2009, 133 ff. (133); s. auch Heinrich, Die rechtliche Systematik der Forschungsförderung in Deutschland und den Europäischen Gemeinschaften unter Beachtung von Wissenschaftsfreiheit und Wettbewerbsrecht, Kölner Schriften zum Internationalen und Europäischen Recht, Bd. 6, 2003. 7 Geiger/Khan/Kotzur, EUV/AEUV. Vertrag über die Europäische Union und Vertrag über die Arbeitsweise der Europäischen Union, Kommentar, Art. 107 AEUV, S. 466 f., Rz. 1–5.

1104

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 10 M

Beihilfemaßnahme in Art. 107 Abs. 2 AEUV definiert. Sie unterfällt den „Kann“-Vorschriften zur „Förderung wichtiger Vorhaben von gemeinsamem europäischen Interesse“ (Art. 107 Abs. 3 lit. b AEUV) oder der „Entwicklung gewisser Wirtschaftszweige oder Wirtschaftsgebiete“ (Art. 107 Abs. 3 lit. c AEUV). Die letztgenannte Vorschrift wird am häufigsten für FuE-Beihilfen zitiert1. Prüfungsmaßstab für alle nationalen Fördermaßnahmen in FuE ist der sog. 8 Gemeinschaftsrahmen. Damit werden den europäischen Mitgliedstaaten Grenzen für die Forschungsförderung vorgegeben, zu deren Einhaltung sich die Wirtschaftsminister der EU verpflichtet haben2. Der Gemeinschaftsrahmen hat damit zwar nicht den Rang einer formalen Rechtsvorschrift, ist aber in den Mitgliedstaaten verbindlich und unterliegt der rechtlichen Kontrolle durch die Behörden der EU3. Die Kontrolle der Förderung wird gem. Art. 108 AEUV durch die Verpflich- 9 tung der Staaten zur sog. „Notifizierung“, also einer Genehmigung ihrer Förderprogramme, sichergestellt4. Wird die Notifizierung unterlassen ohne dass ein Ausnahmefall vorlag oder wurde die zulässige Förderquote überschritten, kann ein Prüfungsverfahren über die erfolgte Fördermaßnahme in Gang gesetzt werden, an dessen Ende im schlimmsten Fall sogar die jeweiligen Zuwendungsbescheide zu widerrufen wären. Entscheidungen der Kommission über die Unvereinbarkeit einer Fördermaßnahme (Beihilfe) können beim Europäischen Gerichtshof angefochten werden. Beachtet ein Mitgliedstaat die Entscheidung der Kommission über die Unvereinbarkeit nicht, können sowohl die Kommission selbst, als auch ein beeinträchtigter Mitgliedstaat den Europäischen Gerichtshof unmittelbar anrufen, Art. 108 Abs. 2 AEUV. Durch die Vertragsrevision von Lissabon wurde Art. 108 AEUV um einen vierten Absatz zur Freistellungsermächtigung der Kommission erweitert. Dieser gestattet es der Kommission, Freistellungsverordnungen des Rates gemäß Art. 109 AEUV durch Verordnungen zu konkretisieren5. Der Gemeinschaftsrahmen unterscheidet nach geltendem Recht zwischen 10 Grundlagenforschung (Förderquote bis 100 %), industrieller Forschung (Förderquote bis 50 %) und experimenteller Entwicklung (Förderquote bis

1 Geiger/Khan/Kotzur, EUV/AEUV, Kommentar, Art. 107 AEUV, S. 472, Rz. 27. 2 ABl. der EU Nr. C 45/5 v. 17.2.1996 – 96 C 45/06. 3 Heidenhain, Handbuch des Europäischen Beihilfenrechts, § 14 Ziff. 4, Rz. 23; auch der Begriff der „Beihilfe“ ist teilweise unklar, aber nach überwiegender Meinung „weit zu fassen“; Geiger/Khan/Kotzur, EUV/AEUV Kommentar, Art. 107 AEUV, S. 468, Rz. 7. So wird z.B. auch die Nichtdurchsetzung von Forderungen der öffentlichen Hand als staatliche Beihilfe definiert, vgl. Soltész/Makowski, EuZW 2003, S. 73 ff. 4 Geiger/Khan/Kotzur, EUV/AEUV, Kommentar, Art. 108, S. 475 f. 5 Geiger/Khan/Kotzur, EUV/AEUV, Kommentar, Art. 108, S. 475 f.

Kaiser

1105

M Rz. 11

Einzelprobleme

25 %). Diese Forschungsarten sind ausführlich definiert. Bei Vorliegen bestimmter Voraussetzungen können die Sätze nach einer Art Bonussystem erhöht werden (z.B. für den Mittelstand oder bestimmte strukturschwache Regionen). Für die Zusammenarbeit zwischen Wissenschaft und Wirtschaft gelten unter gewissen Voraussetzungen Ausnahmen von der Pflicht zur Notifizierung1. Der aktuelle Gemeinschaftsrahmen ist seit 1.1.2007 in Kraft und hat analog zum 7. Forschungsrahmenprogramm Gültigkeit bis 20132. Zugleich mit dem ab 1.1.2014 geltenden Forschungsrahmenprogramm Horizon 2020 wird ein neuer Gemeinschaftsrahmen in Kraft gesetzt. 11 Im Hinblick auf Zuwendungen wird seit langem diskutiert, ob die beihilferechtliche Privilegierung öffentlicher Forschungseinrichtungen und Hochschulen im bisherigen Sinne beibehalten werden kann. Die deutsche Bundesregierung setzt sich hierfür ausdrücklich ein3. Die ordnungspolitisch aus Sicht der Kommission gewünschte Alternative ist, die Forschungsaktivitäten ganz generell in gewerbliche und nicht gewerbliche Tätigkeiten aufzuteilen. Für Forschungseinrichtungen und Unternehmen, die beides betreiben, ist zwischen rein wissenschaftlicher, privilegierter Forschung und Aufgaben des Technologietransfers als gewerblicher Aufgabe zu trennen. Für diese verschiedenen Aufgaben seien prinzipiell unterschiedliche Förderquoten anwendbar. Das bedeutet, dass in ein und derselben Einrichtung oder in einem einzigen Unternehmen zwischen verschiedenen Arten von Forschung auch im Hinblick auf die Haushaltsführung unterschieden werden muss. Im Ergebnis wären danach in der Forschung streng getrennte Unternehmensbereiche, u.a. mit getrennter Buchführung, zu führen. Dies ist für die Privilegierung der Forschung eine unnötige Bürokratisierung und im Ergebnis ein Hemmnis. Die Feststellung zulässiger Förderquoten war auch bisher über den Gemeinschaftsrahmen und die Notifizierungspflicht nachweisbar gesichert und entspricht etwa den Vorschriften, wie sie für öffentliche Unternehmen nach der sog. Transparenzrichtlinie der EU gelten4.

1 Heidenhain, Handbuch des Europäischen Beihilferechts, § 17, Rz. 137, 140. 2 ABl. der EU v. 30.12.2006 – C 323/1. 3 Die Bundesregierung hat bereits 2005 über das Bundesministerium für Finanzen eine Mitteilung an die Generaldirektion Wettbewerb gerichtet und ausdrücklich für die Aufrechterhaltung der Privilegierung von öffentlichen Hochschul- und Forschungseinrichtungen und Beibehaltung des Modells linearer Förderkategorien und der Förderintensitäten plädiert. Weiter wurde die Erweiterung der Möglichkeiten zur Vergabe öffentlicher Forschungsaufträge an Unternehmen vorgeschlagen und empfohlen, einen Zuschlag für Existenzgründer und Kleinstunternehmen einzuführen. 4 Richtlinie 80/723/EWG über die Transparenz der finanziellen Beziehungen zwischen den Mitgliedstaaten und den öffentlichen Unternehmen, ABl. Nr. L 195 v. 29.7.1980, S. 35–37, zuletzt geändert durch die am 27.7.2000 verabschiedete Richtlinie 2000/52/EG der Kommission.

1106

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 14 M

3. Quellen der Förderung Die Forschungsförderung stammt in Deutschland überwiegend aus den 12 Haushalten des Bundes und der Länder und in geringem Umfang von anderen öffentlichen Rechtsträgern, z.B. Körperschaften oder Stiftungen1. Die Größenordnung des Ansatzes in den öffentlichen Haushalten war lange Zeit relativ konstant, Bund und Länder hielten sich bei der Finanzierung in etwa die Waage. Die Ausgaben des Bundes sind allerdings in den letzten Jahren stärker gestiegen als die der Länder2. Auch privatwirtschaftlich organisierte Organisationen wie z.B. die Deutsche Forschungsgemeinschaft oder die Alexander von Humboldt-Stiftung fördern FuE über Zuwendungen und Stipendien. Diese Einrichtungen sind vollständig öffentlich finanziert3. Zuwendungsempfänger sind vor allem Hochschulen und außeruniversitäre Forschungseinrichtungen. Privatrechtliche Stiftungen, wie z.B. die Volkswagen-Stiftung4 unterstützen spezielle Bereiche, die in ihrem Satzungszweck liegen. Die europäische Förderung für FuE stammt vor allem von der Kommission 13 der EU, speziell der Generaldirektion Forschung und der Generaldirektion Unternehmen und Industrie, oder anderen Generaldirektionen, z.B. der Generaldirektion für Gesundheit und Verbraucherschutz. Weitere europaweit agierende Organisationen wie die European Space Agency oder international ausgerichtete Stiftungen finanzieren und fördern FuE zusätzlich. a) Forschungsförderung in Deutschland Die Förderung unterscheidet prinzipiell nach institutioneller Förderung und 14 Projektförderung. Unter institutioneller Förderung ist die Finanzierung von Einrichtung, Ausstattung, Infrastruktur und Personal einer Institution zu verstehen. Die Projektförderung zielt auf die finanzielle Unterstützung von definierten Einzelvorhaben bei einem oder mehreren Partnern ab. Soweit die Förderung aus öffentlichen Mitteln bestritten wird, liegt das öffentliche Haushaltsrecht in jedem Fall zugrunde. Die Förderung wird über Zuwendungsbescheide als begünstigende Verwaltungsakte sichergestellt, die im Rahmen der Verpflichtungsermächtigungen der Ministerien oder anderer Behörden für diese Maßnahmen erlassen werden. Die Höchstgrenzen des Gemeinschaftsrahmens sind einzuhalten.

1 Informationen über aktuelle Fördermaßnahmen u.a. unter http://www.foerderin fo.bund.de/. 2 Vgl. „Föderalismus und Forschungs- und Innovationspolitik“, Studien zum deutschen Innovationssystem, Nr. 11, 02/2011, S. 13. 3 Details dazu bieten die Internetseiten http://www.dfg.de und http://www.avh. de. 4 S. http://www.volkswagenstiftung.de.

Kaiser

1107

M Rz. 15

Einzelprobleme

aa) Institutionelle Förderung 15 Der Bund fördert insgesamt 305 Einrichtungen institutionell. Die MaxPlanck-Gesellschaft (MPG), die Deutsche Forschungsgemeinschaft (DFG), zusätzlich die DFG-Sonderforschungsbereiche, die Fraunhofer-Gesellschaft (FhG), die Einrichtungen der Helmholtz-Gemeinschaft und die Leibniz-Gemeinschaft sind die größten Zuwendungsempfänger1. 16 Die außeruniversitären Forschungseinrichtungen sind bis auf die FraunhoferGesellschaft vollständig öffentlich finanziert. Soweit es sich um öffentlich organisierte Einrichtungen handelt, wird das öffentliche Haushaltsrecht unmittelbar angewendet. Der Betrieb privatwirtschaftlich organisierter Einrichtungen wird in entsprechender Anwendung der öffentlichen Regeln über Zuwendungen finanziert. Es gilt das Besserstellungsverbot gegenüber vergleichbaren staatlichen Einrichtungen, so dass öffentlich-rechtliche Finanz- und Organisationsstrukturen in allen außeruniversitären Einrichtungen bestehen. 17 Die sog. institutionelle Förderung von Einrichtungen wird nach unterschiedlicher Aufteilung von Bund und Ländern getragen, auch die Höhe der öffentlichen Zuwendungen ist unterschiedlich2. Die Max-Planck-Gesellschaft z.B. erhält 84 % ihrer Förderung von Bund und Ländern. Den Rest finanziert sie aus Mitgliedsbeiträgen und Spenden. Die Einrichtungen der Helmholtz-Gemeinschaft erhalten 90 % ihrer Förderung vom Bund und 10 % von den Sitzländern. Die Einrichtungen der Leibniz-Gemeinschaft werden je zur Hälfte von Bund und Ländern finanziert. Die Fraunhofer-Gesellschaft erhält etwa 40 % ihres Aufwands als Grundfinanzierung und erwirtschaftet den Rest aus Mitteln der Wirtschaft und der Projektförderung. 18 Die Anträge auf Zuwendung zur institutionellen Förderung werden auf der Basis von Wirtschaftsplänen über jährlich erlassene Zuwendungsbescheide gestellt. Die Grundlage für die Zuwendungsbescheide stellen die sog. „Allgemeinen Nebenbestimmungen für Zuwendungen zur institutionellen Förderung“ (ANBest-I) dar, die Regelungen über die Zweckbestimmung der Zuwendung und die Vorschriften für die Mittelverwendung enthalten. Aufgrund des jährlich erstellten sog. Gesamtverwendungsnachweises von öffentlich geförderten Einrichtungen wird die Ordnungsmäßigkeit des Jahresabschlusses durch einen Wirtschaftsprüfer gesondert festgestellt.

1 Krämer/Schmidt, Zuwendungsrecht, Ordner 3 B 1, S. 54. 2 Krämer/Schmidt, Zuwendungsrecht, Ordner 3 C II 2, S. 2; Grundsätze zur verfassungsmäßigen Betrachtung der Finanzgewährleistung, Finanzierungsart und Finanzierungsautonomie von Forschungseinrichtungen bei Trute, Die Forschung zwischen grundrechtlicher Freiheit und staatlicher Institutionalisierung, § 12 S. 427, 429, 440.

1108

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 21 M

bb) Projektförderung Die Förderung von Einzelvorhaben findet beim Zuwendungsempfänger 19 statt, der das Projekt allein oder mit anderen Partnern durchführt. Die zuständigen Bundes-/Landesministerien bewilligen die Projekte in ihren Fachabteilungen. Die Verwendung der Fördermittel wird in gesonderten Organisationen, den sog. Projektträgern überwacht. Diese agieren als beliehene Unternehmer oder im Auftrag der Ministerien, sorgen für den Erlass der Bescheide und die ordnungsgemäße Durchführung der Projekte. Sie prüfen die Mittelverwendung, die Einhaltung der Verwertungspläne und sind Ansprechpartner für die im Verlauf der Projekte auftauchenden Fragen. Die Funktionen der Projektträger werden von außeruniversitären Forschungseinrichtungen in Ergänzung ihrer eigenen Forschungstätigkeit oder von eigens dazu errichteten Organisationen sichergestellt. Bedeutende Projektträger sind z.B. das Deutsche Zentrum für Luft- und Raumfahrt (DLR), das Forschungszentrum Jülich (FZJ), der Verein Deutscher Ingenieure (VDI) und die Arbeitsgemeinschaft industrieller Forschungsvereinigungen „Otto von Guericke“ e.V. (AiF). Die jeweiligen Internetseiten der Projektträger geben ausführlich Auskunft über Förderprogramme, sowie Antrags- und Genehmigungsverfahren1. Die wichtigsten Zuwendungsgeber in Deutschland für FuE sind: Bundesministerium für Bildung und Forschung (BMBF): Von den gesamten 20 öffentlichen Ausgaben für FuE entfallen auf den Haushalt des BMBF 11,6 Mrd. Euro im Jahr 2010. Damit geht vom BMBF auch der größte Anteil der Projektförderung in Deutschland aus. Der Fördersatz beträgt gegenüber Unternehmen der Wirtschaft bis zu 50 %, für Forschungseinrichtungen und Hochschulen bis zu 100 %. Informationen zur Forschungsstruktur in Deutschland, zu Förderprogrammen und -initiativen sind erhältlich über die Förderberatung „Forschung und Innovation“ des Bundes, Projektträger Jülich (PtJ), Forschungszentrum Jülich GmbH in Berlin2. Bundesministerium für Wirtschaft und Technologie (BMWi): Dieses Minis- 21 terium wickelt einen Teil seiner Förderung je nach Programm entweder direkt aus seiner Behörde oder über die Arbeitsgemeinschaft industrieller Forschungsvereinigungen „Otto von Guericke“ e.V. (AiF) als Projektträger ab. Der Fördersatz liegt in der Regel bei 50 % oder niedriger. Die BMWi-Förderung wird teilweise auf Basis der Bestimmungen des BMBF zur Projektförderung bei der gewerblichen Wirtschaft (NKBF3), in einzelnen Programmen, aber auch nach eigenen Zuwendungsbestimmungen des Ministeriums ge1 S. etwa die Internetseite des Projektträgers Jülich, http://www.ptj.de. 2 S. http://www.foerderinfo.bund.de/. 3 „Nebenbestimmungen für Zuwendungen auf Kostenbasis des Bundesministeriums für Bildung und Forschung an Unternehmen der gewerblichen Wirtschaft für Forschungs- und Entwicklungsvorhaben“ (Stand: April 2006), erhältlich als BMBF-Vordruck 0348a im Formularschrank unter http://foerderportal.bund.de/ea sy/easy_index.php?auswahl=easy_formulare&formularschrank=bmbf.

Kaiser

1109

M Rz. 22

Einzelprobleme

währt. Die Förderung zielt vor allem auf die anwendungsorientierte wissenschaftlich-technische Grundlagenforschung und die Förderung von Existenzgründungen ab. 22 Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit (BMU): Das Ministerium unterhält das Bundesumweltamt in Berlin als wichtigste nachgeordnete Behörde. Die Projektförderung wird zum Teil über das Ministerium selbst, aber auch über das Umweltbundesamt oder andere Einrichtungen seines Ressorts abgewickelt. Die Projektförderung des Umweltbundesamts erfolgt im Rahmen von Verträgen unter Zugrundelegung bestimmter Zuwendungsbestimmungen, die denen des BMBF ähnlich sind. 23 Bundesministerium für Ernährung, Landwirtschaft und Verbraucherschutz (BMELV): Das Ministerium unterhält mit institutioneller Förderung spezielle Einrichtungen, die sich mit Verbraucherschutz und Landwirtschaft beschäftigen, wie z.B. die Bundesforschungsanstalt für Forst- und Holzwirtschaft oder die Bundesforschungsanstalt für Ernährung und Lebensmittel. Für Projektförderung stehen Mittel nur in beschränktem Maße (ca. 20 Mio. Euro/Jahr) zur Verfügung. Die Fachagentur nachwachsender Rohstoffe e.V. ist einer der wichtigsten Projektträger des BMELV. Die Förderung erfolgt in entsprechender Anwendung der Förderbestimmungen des BMBF. 24 Bundesministerium der Verteidigung (BMVg): Die Förderung wird über Verträge mit dem Bundesamt für Wehrtechnik und Beschaffung (BWB) in Koblenz abgewickelt. Das BMVg erlässt kaum noch eigene Zuwendungsbescheide. Einige wenige rein verteidigungsbezogene Institute werden noch vollständig vom BMVg institutionell gefördert und sind teilweise bei den Einrichtungen der Helmholtz-Gemeinschaft oder der Fraunhofer-Gesellschaft integriert. Die verteidigungsbezogene Projektförderung unterliegt meist strenger Geheimhaltung und sehr speziellen Bestimmungen, die zumindest bezüglich der Verwertung der Ergebnisse durch die Zuwendungsempfänger restriktiv sind. 25 Länderministerien: Die Förderung findet in den Ressortministerien statt, die je nach Bundesland unterschiedlich bei den Ministerien für Bildung und/oder Wissenschaft angesiedelt sind. In einigen Bundesländern werden diese Aufgaben auch von den Wirtschaftsministerien wahrgenommen. Die Aufwendungen sind in den Bundesländern unterschiedlich hoch. Die Programme sind auf die besonderen regionalen Gegebenheiten zugeschnitten. Die Bedingungen zur Förderung sind meist relativ flexibel und unterliegen unterschiedlichen Voraussetzungen. Häufig werden die Zuwendungsbestimmungen des BMBF entsprechend angewendet. 26 Deutsche Forschungsgemeinschaft (DFG): Sie fördert Forschungsvorhaben in allen Wissenschaftsgebieten im Wege der Projektförderung und der Unterstützung von Kooperationsvorhaben. Sie unterhält daneben Sonderforschungsbereiche an den Universitäten, die mit erheblichen Fördermitteln

1110

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 30 M

ausgestattet sind. Die DFG vergibt etliche Forschungspreise, z.B. den hoch dotierten Gottfried Wilhelm Leibniz-Preis. Die Förderbedingungen sind je nach Art der Zuwendung unterschiedlich. b) Forschungsförderung in Europa Die Europäische Union hat sich in Art. 179 AEUV ausdrücklich die För- 27 derung von Forschung und Entwicklung zum Ziel gesetzt. Im Haushalt der EU werden erhebliche Mittel dafür zurückgestellt. Dabei gilt prinzipiell das Subsidiaritätsprinzip, d.h. bevor die Kommission fördert, sollen private Ressourcen oder nationalstaatliche Fördermittel ausgeschöpft werden bzw. dürfen nicht verfügbar sein. Die Europäische Union und die Europäische Atomgemeinschaft (Euratom) 28 fördern beide FuE. Die Verwaltung der Fördermittel findet allerdings komplett über den Haushalt der Kommission der EU statt1. Im europäischen Umfeld wird ebenfalls zwischen institutioneller Förderung und Projektförderung unterschieden. Die Projektförderung steht dabei aber klar im Vordergrund. Gemeinsame, von verschiedenen Mitgliedstaaten oder ihren Einrichtungen betriebene und gemeinsam finanzierte Forschungseinrichtungen stellen nach wie vor die Ausnahme dar. Folgende Stellen haben für die Förderung besondere Bedeutung: Kommission der EU: Die EU unterhält zurzeit sieben eigene Forschungs- 29 institute, die sie institutionell voll finanziert (sog. Gemeinsame Forschungsstelle oder Joint Research Centre – JRC). Es gibt auch eine Reihe von Stiftungen, die aus Mitteln der EU betrieben werden, z.B. das Institut zur Verbesserung von Lebens- und Arbeitsbedingungen in Dublin oder die Europäische Rechtsakademie in Trier. Zu erwähnen ist auch der European Investment Fund in Luxemburg, der erhebliche Mittel der EU als Risikokapital (Venture-Capital) für Förderung von Firmengründungen bereithält. Der größte Anteil der Projektförderung wird in den Forschungsrahmenpro- 30 grammen der Generaldirektion Forschung gewährt. Das 7. Forschungsrahmenprogramm mit ca. 54 Mrd. Euro Förderung (inkl. Euratom) war von 2007 bis 2013 in Kraft. Der folgenden Förderperiode mit der Laufzeit von 2014 bis 2020 wurde der Name „Horizon 2020“ verliehen. Das Budget beträgt nach Vorschlag der Kommission ca. 87 Mrd. Euro und wird derzeit im Detail verhandelt2. Die Kommission unterscheidet zwischen Aktivitäten und Programmen, die als Förderarten im Wesentlichen die Projektför1 Information über die Forschungsförderung der EU, Programme und Verfahren in der ausführlichen homepage http://cordis.europa.eu/. 2 S. MEMO/11/848 der Europäischen Kommission v. 30.11.2011. Bei Drucklegung befinden sich Budget und Beteiligungsregeln von Horizon 2020 in Verhandlung. Diese werden im Jahr 2013 im ordentlichen Gesetzgebungsverfahren gem. Art. 294 AEUV vom Europäischen Parlament und dem Rat der Europäischen Union beraten und verabschiedet.

Kaiser

1111

M Rz. 31

Einzelprobleme

derung, Stipendien und Förderung von sog. Begleitmaßnahmen unterscheiden. 31 Europäische Atomgemeinschaft (Euratom): Die Euratom hat die Aufgabe, zur „Hebung der Lebenshaltung in den Mitgliedstaaten“1 durch die Entwicklung der Kernenergie beizutragen. Um dieser Aufgabe gerecht zu werden, hat die Euratom die Forschung in diesem Bereich zu fördern. Euratom koordiniert die Forschung der Mitgliedstaaten, gewährt finanzielle Hilfe zu Forschungsprogrammen und führt ergänzend eigene Forschungs- und Ausbildungsprogramme durch. Die Forschungsförderung der Euratom erfolgt über die Generaldirektion Forschung der EU in einem gesonderten Programm. Die Beteiligungsregeln für EU-Projekte der Generaldirektion Forschung gelten entsprechend. Seit dem 4. Forschungsrahmenprogramm werden die Rahmenprogramme der Euratom separat geregelt. Zum Erhalt der Kohärenz wurden jedoch noch das 4. und 5. Forschungsrahmenprogramm der EG und der Euratom am gleichen Tag mit gleicher Laufzeit beschlossen. Seit dem 6. Rahmenprogramm wird hiervon jedoch abgesehen. Das 7. Rahmenprogramm der Euratom für Forschungsmaßnahmen im Nuklearbereich ist für den Zeitraum von 2007 bis 2011 vorgesehen und damit um zwei Jahre kürzer als das 7. Forschungsrahmenprogramm der EU für die allgemeine Forschung. Die Förderung betraf ursprünglich die Kernforschung, die Förderziele haben sich im Lauf der Zeit deutlich geändert. Das Fördervolumen der Aktivitäten der Euratom belief sich im Zeitraum von 2007 bis 2011 auf 2,751 Mrd. Euro2. 32 Europäische Gemeinschaft für Kohle und Stahl (EGKS): Nach Ablauf des EGKS-Vertrags am 23.7.2002 liefen auch die entsprechenden Programme zur Forschungsförderung aus3. Die bestehenden finanziellen Reserven werden im Rahmen eines Forschungsfonds für Kohle und Stahl über die EUKommission weiterhin zur Forschungsförderung eingesetzt. 33 EUREKA: Es handelt sich um ein europäisches Forum für grenzüberschreitende Kooperation im Bereich angewandter Forschung und Technologie im High-Tech Bereich. Die Förderung ist bei den nationalen Behörden der Mitgliedstaaten zu beantragen. EUREKA unterhält ein eigenes Sekretariat in Brüssel und nationale Projektkoordinatoren, die den Projektpartnern aber viel Autonomie lassen4. 34 European Space Agency (ESA): Diese Einrichtung ist eine auf Grund gesonderten Staatsvertrags gegründete Organisation für die europäische Raumfahrt. Ihr gehören 16 Mitgliedstaaten der EU an, die sie auch finanzieren. 1 Art. 1 EAGV (Vertrag zur Gründung der Europäischen Atomgemeinschaft). 2 ABl. der EU L 54/21 v. 22.2.2007. 3 Geiger, EUV/EGV, Art. 305 EGV, Rz. 2. Aufgrund des Ablaufs des EGKS-Vertrags findet Art. 305 Abs. 1 EGV im AEUV keine Entsprechung. 4 Weiteres unter http://www.eureka.dlr.de/.

1112

Kaiser

Rz. 42 M

Öffentliche Förderung von Forschung und Entwicklung

Die Mitgliedstaaten der ESA sind mit denen der EU nicht identisch. Im sog. Wissenschaftsprogramm werden die Fördermittel eingestellt. Hieraus fördert die ESA im Eigeninteresse und für Zwecke der Raumfahrt Einzelprojekte in ihren Mitgliedstaaten. Die Fördermittel für das Jahr 2010 betrugen ca. 3,744 Mrd. Euro. Weitere europäische Förderstellen, die die Förderung von FuE nur mittelbar 35 unterstützen, sind u.a. die Entwicklungsbank des Europarates, die Europäische Investitionsbank und die Europäische Bank für Wiederaufbau und Entwicklung. Einstweilen frei.

36–38

II. Zentrale Fragen des deutschen Zuwendungsrechts 1. Arten und Formen der Zuwendungen in Deutschland a) Zuordnung der Förderprogramme Die bestehenden Förderprogramme sind sehr vielseitig und schwer über- 39 schaubar. Sie sind zum einen von den Interessen der Gebietshoheit und von Zuständigkeiten, z.B. von Bund und Ländern, und von der Ausrichtung nach Ressorts, z.B. Verteidigung oder Raumfahrt, zum anderen auch rein fachlich nach Disziplinen, z.B. Energie, Mikroelektronik, Lebenswissenschaften, geordnet. Die Volumina der Programme sind außerordentlich unterschiedlich, ebenso wie die Anforderungen an einen erfolgreichen Antrag. Die Strukturierung in einem Gesamtüberblick wäre dafür sehr umfangreich und würde nur bedingt weiterhelfen. In der Praxis orientieren sich die Antragsteller nach der fachlichen Zuord- 40 nung der Förderprogramme, die für sie in Frage kommen, gleich aus welcher Quelle sie stammen. Hier wird besonders auf die Übersicht des BMBF verwiesen1. Eine Segmentierung der Förderprogramme kann auch nach allgemeinen Zielsetzungen wie folgt erreicht werden2: – – – –

41

Förderung von Forschung und Entwicklung Strukturförderung (z.B. der regionalen Wirtschaftsstruktur) Allgemeine Investitionsförderung für kleine und mittlere Unternehmen Existenzgründungsförderung

Die Einzelmaßnahmen hierfür sind in Programmen der einzelnen Zuwen- 42 dungsgeber niedergelegt. In aller Regel handelt es sich um sog. „verlorene Zuschüsse“. Ganz allgemein kommen aber auch weitere Förderwege in Frage: 1 Einzelheiten siehe unter http://www.foerderinfo.bund.de/. 2 Weitnauer, Handbuch Venture Capital, Abschnitt D, S. 193, Rz. 237.

Kaiser

1113

M Rz. 43

Einzelprobleme

– Zuwendungen in Form von nicht rückzahlbaren Zuschüssen – Darlehen zu meist günstigen Verzinsungen – Stille oder offene Beteiligungen im Bereich der Gründungsförderung 43 Zuwendungsempfänger sind meist Unternehmen oder Einrichtungen, also juristische Personen. Nur in seltenen Ausnahmefällen erhalten auch natürliche Personen Zuwendungen, dann meist in Form von Stipendien. b) Zuwendungen und Verträge 44 Im Bereich der Forschungsförderung wird unter Zuwendung in der Regel ein Zuschuss ohne Rückzahlungspflicht verstanden. Natürlich gibt es auch andere Förderarten wie Darlehen oder Stipendien. Hier soll der Hauptfall von Zuwendungen im Sinne „verlorener Zuschüsse“ behandelt werden. Der Zuwendungsbescheid als begünstigender Verwaltungsakt ergeht unter bestimmten allgemeinen Zuwendungsbestimmungen und kann spezielle Auflagen (besondere Nebenbestimmungen) enthalten, z.B. die Einhaltung bestimmter Veröffentlichungs- und Verwertungspflichten1. Das Öffentliche Recht findet Anwendung mit der Folge, dass im Falle der Anfechtung eines Zuwendungsbescheides die Verwaltungsgerichtsbarkeit zuständig wäre. 45 Die Gewährung der Fördermittel erfolgt neben den Zuwendungen auch im Rahmen von Verträgen. Dabei handelt es sich in der Regel nicht um fiskalische Beschaffungen, sondern nur um eine alternative Form der Gewährung von Mitteln für die Durchführung von Projekten. Die Vertragsbedingungen gehen zwar grundsätzlich von einem Austauschverhältnis aus (Forschungsauftrag), sind aber den Zuwendungsbescheiden nachgebildet, so dass der Unterschied nur in der rechtlichen Qualität „Zuwendung oder Vertrag“ liegt. Ob solche Verträge der Zivilgerichtsbarkeit oder auch der Verwaltungsgerichtsbarkeit unterliegen, ist im Einzelfall zu beurteilen. Soweit es sich um sog. „öffentliche Verträge“ handelt oder der Vertrag nur zum Vollzug der Zuwendung dient, werden sie der Verwaltungsgerichtsbarkeit zuzuordnen sein. Ansonsten wären sie prinzipiell als Verträge im Sinne eines Leistungsaustausches zivilrechtlich zu bewerten. Dies betrifft dann eher Fälle, bei denen Bund, Länder oder besonders das Bundesamt für Wehrtechnik und Beschaffung (BWB) Aufträge zur Deckung des eigenen Bedarfs tätigen. Hier steht weniger der Zuwendungsgedanke als das fiskalische Handeln im Vordergrund.

1 Zusammenfassung der Instrumente der Forschungsförderung auch in Heinrich, Die rechtliche Systematik der Forschungsförderung in Deutschland und den Europäischen Gemeinschaften unter Beachtung von Wissenschaftsfreiheit und Wettbewerbsrecht, Kölner Schriften zum Internationalen und Europäischen Recht, Kapitel 3, S. 76 ff.; Überblick über Förderarten und Vergabepraxis in: Krämer/Schmidt, Zuwendungsrecht, Ordner 3, Abschnitt C.

1114

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 48 M

2. Zuwendungsbestimmungen des BMBF Die Zuwendungsverfahren der einzelnen Förderstellen sind stark diversifi- 46 ziert und oft sehr spezifisch gestaltet. Die allgemeinen Problemstellungen bei Zuwendungen entsprechen sich allerdings in den meisten Fällen. Dabei geht es u.a. um Regeln der Mittelverwendung, der Rechte an den Ergebnissen und an den Erlösen sowie der Veröffentlichungspflichten. Es empfiehlt sich, diese wesentlichen Fragen anhand typischer Zuwendungsbestimmungen zu behandeln, die am häufigsten eingesetzt werden. Dazu bieten sich die Bestimmungen des BMBF zur Projektförderung bei der gewerblichen Wirtschaft (sog. NKBF1) an. Die Zuwendungsbestimmungen des BMBF werden in längeren Zeit- 47 abschnitten geprüft und geändert. Die von 1988 bis 1998 geltenden NKFT 88 wurden im Jahr 1998 durch die NKBF ersetzt. Im Jahr 2008 blieb die turnusmäßig alle zehn Jahre erwartete Reform aus. Zum jetzigen Zeitpunkt im Januar 2013 ist über eine Reform nichts bekannt. Die NKBF waren zunächst nur für die Förderung von Unternehmen der gewerblichen Wirtschaft vorgesehen. Diesen Bestimmungen gingen die Empfehlungen eines im Jahr 1996 vom damaligen Ministerium für Forschung und Technologie berufenen Sachverständigenkreises voraus, dem verschiedene Zielsetzungen gegeben wurden. Im Vordergrund stand, innovationsstärkende Regelungen für die Ergebnisverwertung in geförderten Vorhaben zu finden. Daneben sollten die neu geschaffenen Bedingungen Modellcharakter für die vielen vereinzelten Zuwendungsbestimmungen in Bund und Ländern haben. Einzelheiten sind im Abschlussbericht des vorgenannten Sachverständigenkreises zum Thema „Innovationsstärkende Regelungen der Ergebnisverwertung öffentlich geförderter Forschung und Entwicklung“ festgehalten2. Durch die NKBF 98 wurden die Zuwendungsbestimmungen in wesentli- 48 chen Teilen reformiert. Dies wird vor allem bei den Regelungen für die Behandlung der Ergebnisse deutlich. Hier besteht eine unbeschränkte exklusive Nutzungsbefugnis der Zuwendungsempfänger. Gleichzeitig wurde das Verfassen und Fortschreiben eines Verwertungsplans für die Projektförderung verlangt. Zusätzlich ist vorgesehen, dass die Einnahmen aus der Verwertung von Forschungsergebnissen beim Zuwendungsempfänger verbleiben, soweit sie für innovative Zwecke verwendet werden. Alle übrigen Regelwerke des BMBF wurden nach und nach wörtlich gleichlautend umge-

1 „Nebenbestimmungen für Zuwendungen auf Kostenbasis des Bundesministeriums für Bildung und Forschung an Unternehmen der gewerblichen Wirtschaft für Forschungs- und Entwicklungsvorhaben“ (Stand: April 2006), BMBF-Vordruck 0348a im Formularschrank unter http://foerderportal.bund.de/easy/easy_ index.php?auswahl=easy_formulare&formularschrank=bmbf. 2 Eine Zusammenfassung der Empfehlungen hat der Vorsitzende Hanns Ullrich in Wissensmanagement, Heft September/Oktober 1997, S. 259 ff., veröffentlicht – „Mehr Initiative, mehr Innovation. Innovationsstärkende Regelung der Ergebnisverwertung öffentlich geförderter Forschung und Entwicklung“.

Kaiser

1115

M Rz. 49

Einzelprobleme

staltet. Dies gilt damit für Unternehmen, Hochschulen und alle außeruniversitären Forschungseinrichtungen gleichermaßen. Auch die Verträge zur Forschungsförderung (sog. BEBF ZE 981) enthalten denselben Wortlaut wie die NKBF. Einige Länderministerien haben die NKBF zum Vorbild genommen und fördern auf der gleichen Grundlage. Dabei bleibt aber festzuhalten, dass einige wenige Ressorts des Bundes die NKBF nicht übernommen haben. Zum Beispiel unterhält das Wirtschaftsministerium eigene Bedingungen für die Förderung auch im Bereich der Forschung. Das Haushaltsgrundsätzegesetz (HGrG) und die Haushaltsordnungen streben ganz generell einheitliche Zuwendungsbestimmungen in Bund und Ländern und eine entsprechende Anpassung der Verwaltungsvorschriften an. Bei den Zuwendungsbestimmungen für FuE hat die zitierte Reform der NKBF eine Verbesserung der Situation, aber noch keine abschließend einheitliche Handhabung erzeugt2. Wegen dieser positiven Vereinheitlichungstendenz, die sich als sehr hilfreich erwiesen hat, werden die NKBF in diesem Beitrag beispielhaft für die Konditionen der Projektförderung besprochen. a) Antragsverfahren bei der Projektförderung nach den NKBF 49 Das Bundesministerium für Bildung und Forschung bestreitet den überwiegenden Teil der Forschungsförderung in Deutschland. Das Antrags- und Genehmigungsverfahren ist weitgehend systematisiert. Die Anträge erfolgen auf bestimmten Formularen z.B. „Antrag für eine Zuwendung auf Kostenbasis (AZK)“ oder „Angebot für einen Auftrag auf Kostenbasis (AAK)“. Die Kosten hierfür müssen nach dem öffentlichen Preisrecht und dort nach der sog. Verordnung PR Nr. 30/53 über die Preise bei öffentlichen Aufträgen (VO-PR 30/53) und den Leitsätzen für Preisermittlung (LSP) kalkuliert sein. Der Bund stellt einen umfangreichen Formularschrank zur Verfügung. Dort sind die Formulare der Ministerien BMBF, BMWi, BMELV, BMU u.a. zu finden3. Weitere Hinweise zu den einzelnen Programmen und den Antragsvoraussetzungen geben die Projektträger4. b) Nebenbestimmungen der Zuwendungsbescheide 50 Die Zuwendungsbescheide ergehen individuell und enthalten die technische Beschreibung und Kalkulation der Projekte. Die Bescheide sind im Übrigen aber standardisiert und verweisen auf Zuwendungsbestimmungen. Die Bestimmungen orientieren sich im Wesentlichen an den sog. Neben1 „Allgemeine Bestimmungen für Forschungs- und Entwicklungsverträge der Zuwendungsempfänger des Bundesministeriums für Bildung und Forschung“ (Stand: März 2000), BMBF-Vordruck 0370b im Formularschrank unter http://foerderportal. bund.de/easy/easy_index.php?auswahl=easy_formulare&formularschrank=bmbf. 2 Zur Rechtseinheit in Bund und Ländern siehe Krämer/Schmidt, Zuwendungsrecht, Ordner 4 D I 2.2., S. 22. 3 S. https://foerderportal.bund.de/easy/. 4 S. etwa die weiterführenden Internetseiten, z.B. des Projektträgers Jülich: http://www.ptj.de/.

1116

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 54 M

bestimmungen für Zuwendungen zur Projektförderung (ANBest-P). Diese Regelungen stammen aus dem Bundesministerium für Finanzen und geben den allgemeinen Rahmen für die Mittelverwendung bei Förderung vor. Sie haben ihre Wurzeln unmittelbar im öffentlichen Haushaltsrecht1. Die ANBest-P wurden durch den Bund im Jahr 1982 durch sog. Besondere Nebenbestimmungen für die Projektförderung in Forschung und Entwicklung (BNBestP-FuE) ergänzt, da man die Notwendigkeit von Sonderregelungen für den Forschungsbereich sah. Ausgehend hiervon haben einige Zuwendungsgeber ihre Zuwendungsbestimmungen mehr oder weniger unmittelbar daran orientiert2. Im einzelnen Zuwendungsbescheid bestehen die Nebenbestimmungen aus 51 allgemeinen und besonderen Nebenbestimmungen. Die allgemeinen Nebenbestimmungen geben den gesamten rechtlichen Rahmen für Finanzierung, Rechtsposition des Zuwendungsempfängers und Behandlung der Zuwendung sowie eventuelle Konsequenzen bei Verstoß gegen die Zuwendungsvorschriften wieder. Dies wird beim BMBF durch die NKBF unter Verweis auf die ANBest-P und das öffentliche Haushaltsrecht sichergestellt. Besondere Nebenbestimmungen werden individuell für jedes Projekt formuliert, falls solche vorgesehen sind. In Zuwendungsbescheiden für Kooperationsprojekte wird zusätzlich ein Merkblatt über die Gestaltung von Kooperationsverträgen beigefügt. c) Die wesentlichen Vorschriften der NKBF 98 Die Einhaltung des Zuwendungszwecks3 ist entsprechend den haushalts- 52 rechtlichen Vorschriften gemäß § 44 BHO (zweckentsprechende Mittelverwendung) Voraussetzung. Der Zuwendungszweck ist im Bescheid definiert und nimmt in der Regel Bezug auf die Projektbeschreibung. Die Mittel dürfen nur dafür verwendet werden. Die Verwendung muss in finanzieller und tatsächlicher Hinsicht nachgewiesen werden. Der Zuwendungsempfänger hat eine Mitteilungspflicht, wenn er bei einer 53 anderen Stelle eine Zuwendung zum gleichen Thema beantragt hat oder sich damit eine Änderung der Finanzierung um mehr als 10 % oder mehr als 50 000 Euro ergibt. Prinzipiell gelten das Subsidiaritätsprinzip und das Verbot der Doppelförderung bei fast allen Zuwendungsgebern. Die NKBF 98 schreiben für die Zuwendungsbestimmungen des BMBF einen 54 sog. Verwertungsplan, Ziff. 6 NKBF, vor. Der Zuwendungsempfänger soll bei der Erstellung des Verwertungsplans Informationsrecherchen durchführen und vom neuesten Stand der Wissenschaft und Technik ausgehen. Hierbei sollen möglichst elektronische Quellen (Datenbanken, Informationen 1 Krämer/Schmidt, Zuwendungsrecht, Ordner 4 D I 3, S. 23 ff. 2 Detaillierte Aufstellung in Krämer/Schmidt, Zuwendungsrecht, Ordner 4 D XII. 3 Krämer/Schmidt, Zuwendungsrecht, Ordner 4 D X 3, S. 2.

Kaiser

1117

M Rz. 55

Einzelprobleme

aus Netzwerken u.a.) benutzt werden. Der Zuwendungsempfänger ist verpflichtet, den Verwertungsplan nicht nur zu erstellen, sondern auch mit Berichten fortzuschreiben. Damit soll erreicht werden, dass die Zweckbestimmung der Zuwendung erfüllt wird und der Empfänger sich von vorneherein im Klaren ist, zu welchen Zwecken die Ergebnisse verwendet werden sollen. Der Zuwendungsgeber soll sich ein Bild verschaffen können, ob die ursprüngliche Absicht auch verfolgt wurde und eine zweckentsprechende Verwendung des Ergebnisses verfolgt wird. Die Konsequenzen bei Abweichungen vom Verwertungsplan sind im Wesentlichen, dass der Zuwendungsempfänger das ihm nach den neuen Bestimmungen eingeräumte Exklusivrecht nach Ablauf von zwei Jahren wieder verliert und ein Dritter auf Antrag ein Nutzungsrecht beim BMBF erhalten kann, Ziff. 18.1 NKBF. 55 Im Rahmen der zuwendungsfähigen Einzelkosten können kleine und mittlere Unternehmen die Kosten für Schutzrechtsanmeldungen (Patentanwalt, Patentamt) gefördert erhalten. Es empfiehlt sich aber, den Umfang solcher Kosten mit dem Zuwendungsgeber abzustimmen, da eventuelle Unklarheiten über die Art der Anmeldungen u.a. bestehen können. Bei den Personalkosten gibt es bestimmte Einschränkungen für die Verrechnung. 56 Der Schlussbericht ist gem. Ziff. 8.2 NKBF nach einem bestimmten Muster vorzulegen. Die Berichtspflicht besteht seit Einführung des Verwertungsplans im Wesentlichen aus seiner Fortschreibung. Dort ist aufzunehmen, wie die in Anspruch genommenen Erfindungen verwertet werden und wie die wirtschaftlichen Erfolgsaussichten genutzt werden sollen. Schließlich ist eine Aussage über die wissenschaftliche und wirtschaftliche Anschlussfähigkeit für eine nächste Phase zu treffen. Wie bisher ist die Einhaltung der Finanz- und Zeitpläne sicherzustellen. 57 Der erste Grundsatz für die Rechte am Ergebnis1 ist, dass die Sicherung der gewerblichen Schutzrechte Vorrang vor der Veröffentlichung hat, Ziff. 10.1 NKBF. Dadurch soll sichergestellt werden, dass dem Zuwendungsempfänger nicht die Möglichkeit des Schutzes seiner Ergebnisse aus dem Vorhaben durch Veröffentlichungspflichten genommen wird. Der Zuwendungsempfänger ist aber dennoch (unter Beachtung dieses Grundsatzes) verpflichtet, innerhalb von neun Monaten nach Abschluss des Vorhabens auf geeignete Weise den fachlich interessierten Stellen in Deutschland die Ergebnisse des 1 Zu den Regelungen für die Rechte am Ergebnis in Kooperationsverträgen bei Forschung und Entwicklung, wie sie typischerweise der Förderung mehrerer Zuwendungsempfänger zugrunde liegen, vgl. Kaiser, Berliner Vertrags Office (CDRom), Freiburg, Stand 2008, Vertragsmuster Kooperationsverträge, Erläuterungen Ziff. 28–40, 48, sowie im gleichen Vertragsmuster unter Textbausteine: Nr. 9 für Fälle der Mitfinanzierung von Industrieunternehmen; siehe auch Wurzer/ Kaiser, Handbuch Internationaler Know-how-Schutz, S. 295 ff.; siehe hierzu auch Körner, Nutzung staatlich geförderter technischer Entwicklungen – insbesondere von Universitäten – durch privatwirtschaftliche Unternehmen, in: Anderbrügge/Epping/Löwer (Hrsg.), Dienst an der Hochschule, Festschrift für Dieter Leuze zum 70. Geburtstag, Berlin 2003, S. 321 ff.

1118

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 62 M

Vorhabens zugänglich zu machen oder in angemessener Weise zu veröffentlichen, Ziff. 11.4 NKBF. Falls bei der Anmeldung von Schutzrechten eine Verlängerung der Fristen erfolgen sollte, wird die Veröffentlichung hinausgeschoben. Zusätzlich hat der Zuwendungsempfänger dem BMBF die Veröffentlichung einschließlich einer Kurzfassung zuzuleiten. Der zweite wichtige Punkt ist, dass die FuE-Ergebnisse dem Zuwendungs- 58 empfänger grundsätzlich ausschließlich zur Nutzung zur Verfügung stehen, Ziff. 12.1 NKBF. Er kann sie exklusiv unter Wahrung seines Wettbewerbsvorsprungs verwerten. Das ausschließliche Nutzungsrecht kann zeitlich oder sachlich beschränkt sein, Ziff. 12.3 NKBF, und darf nur Bestand haben, wenn es nicht zu einer wettbewerbswidrigen Stellung führt, Ziff. 12.2 NKBF. Führt die Zuwendung trotzdem zu einem Verstoß gegen das Wettbewerbsrecht, muss der Zuwendungsempfänger die Zuwendung zurückzahlen und erkauft sich damit quasi das Exklusivrecht. Die Folgen der Nichtbeachtung der Verwertungspflichten sind, dass der Zuwendungsempfänger in der Regel nach zwei Jahren das Recht auf ausschließliche Nutzung verliert. In einem solchen Fall kommt es zu der Regelung, die früheren Verfahrensweisen entspricht, nämlich dass der Zuwendungsgeber Dritten die Möglichkeit zur Nutzung des geförderten Ergebnisses einräumen muss, Ziff. 18.2 NKBF.

59

Die Einnahmen aus der Verwertung der Ergebnisse, z.B. Lizenzen, verblei- 60 ben beim Zuwendungsempfänger, Ziff. 15 NKBF. Sie sind für innovative Zwecke zu verwenden. Die Schutzrechte dürfen aber nur veräußert werden, wenn der Erwerber die hierauf bezogenen Verpflichtungen, vor allem aus dem Verwertungsplan, erfüllt. Die Verwertung der Ergebnisse im Ausland außerhalb der EU bedarf der 61 vorherigen schriftlichen Zustimmung des Zuwendungsgebers. Mit dieser Regelung soll der unkontrollierte Abfluss von in Europa geförderten Forschungsergebnissen ins außereuropäische Ausland vermieden werden. Die Regelung ist im Hinblick auf die Nachprüfbarkeit, z.B. bei Unterlizenzen an Tochtergesellschaften, problematisch. Man kann allerdings die Verwertungsabsicht im außereuropäischen Ausland bereits im Verwertungsplan angeben. In diesem Fall gilt sie als genehmigt. Andernfalls kann auch nachträglich noch die Genehmigung für eine solche Verwertung erteilt werden. 3. Vertragsmuster für (Unter-)Verträge mit dem BMBF Für den Fall der Vergabe von Unteraufträgen des Zuwendungsempfängers 62 geben die NKBF einen Mustervertrag (BEBF 98) mit feststehenden Vertragsbedingungen vor1. 1 U.a. ist der Vertragstext der BEBF 98 (Stand: September 2005) im Formularschrank des BMBF zu finden, BMBF-Vordruck 0361b unter http://foerderportal. bund.de/easy/easy_index.php?auswahl=easy_formulare&formularschrank=bmbf.

Kaiser

1119

M Rz. 63

Einzelprobleme

63 Die Vergabe von Aufträgen an Dritte darf nur an fachkundige Unternehmen oder Personen gegeben werden, Ziff. 3.1 NKBF. Über einen Betrag von 100 000 Euro hinaus sind die Aufträge zustimmungspflichtig, Ziff. 3.2 NKBF. Bei den üblichen Zuwendungen bis 50 % sind die BEBF 98 nur bei einem Auftragswert von über 1 Mio. Euro zu vereinbaren, Ziff. 3.3 NKBF. Ferner ist ein Prüfungsrecht zugunsten des Zuwendungsgebers vorzusehen. Beschaffungsaufträge mit einem Entwicklungsanteil von mindestens 25 % der Vergütung sind wie FuE-Verträge zu behandeln. 64 In den BEBF 98 ist besonders die Regelung für die Behandlung von Schutzrechten des Auftragnehmers bemerkenswert. In diesen Fällen darf der Auftragnehmer des Zuwendungsempfängers die Schutzrechte nicht behalten, sondern er muss sie an den Auftraggeber (Zuwendungsempfänger) übertragen. Der Grund hierfür ist, dass man die Verwertungsrechte und -pflichten beim Zuwendungsempfänger konzentrieren will. Dieser Grundsatz ist richtig. Die Übertragungspflicht ist aber hierfür keineswegs notwendig und führt teilweise sogar zu unerwünschten Effekten. 65 Diese Regelung kann für den Auftragnehmer, besonders Forschungseinrichtungen, manche Hochschulinstitute, aber auch für mittelständische Unternehmen von Nachteil sein, denn sie verlieren ihre Schutzrechte automatisch. Aber auch umgekehrt kann es sein, dass ein Zuwendungsempfänger und Auftraggeber, z.B. ein Hochschulinstitut oder ein Mittelständler, gar kein Interesse am Eigentum an den Schutzrechten hat. Nicht jedes Institut oder jedes Unternehmen möchte sich die Kosten einer Schutzrechtsanmeldung oder Aufrechterhaltung aufladen. Die Regelung ist auch deshalb bedenklich, weil der Erfinder des Unterauftragnehmers im Widerspruch zum Arbeitnehmererfindergesetz eine Rechtsposition zum Erwerb der Erfindung verliert, wenn der daran berechtigte Auftraggeber, also sein Arbeitgeber, sie aufgeben muss. Die Verpflichtung zur Übertragung ist daher möglicherweise wegen Verstoßes gegen das Arbeitnehmererfindergesetz unzulässig, solange ein Vorbehalt zugunsten des Arbeitnehmererfinders fehlt. 4. Weitere Zuwendungsbestimmungen a) Bundesministerium für Verteidigung (BMVg) und Bundesamt für Wehrtechnik und Beschaffung (BWB) 66 Das BMVg gibt Zuwendungen nur streng zweckgebunden für Verteidigungszwecke und mit einzelnen restriktiven Konditionen. Die Geheimhaltung spielt naturgemäß eine wichtige Rolle. Fördermittel des BMVg gehen in erster Linie an verteidigungsbezogene Forschungsinstitute oder bestimmte Rüstungsunternehmen (z.B. Diehl, Rheinmetall). 67 Die Zuständigkeiten zwischen dem BMVg und dem BWB sind so aufgeteilt, dass nahezu alle Aufträge und Fördermaßnahmen für FuE über das BWB abgewickelt werden. Das BWB verwendet für die Förderung spezielle Vertrags-

1120

Kaiser

Rz. 71 M

Öffentliche Förderung von Forschung und Entwicklung

muster. Dort werden keine Zuwendungsbescheide erlassen, sondern es wird ein Mustervertrag angewandt. Dieser hat sehr spezielle Regelungen im Unterschied zu den Förderbestimmungen oder Vertragsbedingungen des BMBF. b) Bundesministerium für Wirtschaft und Technologie (AiF-Förderung) Das Wirtschaftsministerium vergibt seine Förderung überwiegend über die 68 Arbeitsgemeinschaft industrieller Forschungsvereinigungen „Otto von Guericke“ e.V. (AiF). Die AiF ist eine Dachorganisation, die fachbezogene Forschungsinstitutionen unterhält. Die sog. AiF-Stellen1 erhalten Zuwendungsmittel vom Wirtschaftsministerium und geben sie entsprechend an Firmen weiter. c) Länderministerien und Zuwendungsbestimmungen anderer Einrichtungen Des Umfangs wegen kann auf nämliche an dieser Stelle nicht eingegangen 69 werden. Die Förderung der Länder hat meist sehr spezifische, auf regionale Eigeninteressen zugeschnittene Forschungsprogramme zum Gegenstand. Jedes Förderprogramm verfügt über eigene Musterverträge, die (quantitativ und qualitativ) unterschiedlich gestaltet sind. Viele Bundesländer wenden inzwischen die NKBF des Bundes entsprechend an oder übernehmen sie wörtlich in ihre Regelwerke. Andere Einrichtungen, insbesondere Stiftungen, fördern anhand ihrer institutionellen Bestimmung oder ihrer Widmung. Die Zuwendungsbestimmungen sind in gewissem Maße ähnlich.

III. Zentrale Fragen des europäischen Zuwendungsrechts Die forschungspolitische Kompetenz der EU ist im Titel XIX, Art. 179–190 70 AEUV begründet. Ziele der gemeinsamen Forschungspolitik sind zum einen nach innen gerichtet die Stärkung der wissenschaftlichen und technologischen Grundlagen der Industrie sowie nach außen gerichtet die Entwicklung ihrer internationalen Wettbewerbsfähigkeit und zum dritten schließlich die Unterstützung anderer EU-Strategien mit Forschungsbezug. 1. Die Forschungsrahmenprogramme (FRP) Die Förderung erfolgt in mehrjährigen sog. Forschungsrahmenprogram- 71 men2, die ein Instrument zur mittelfristigen Planung der gemeinschaftlichen Maßnahmen in diesem Bereich darstellen. Da der ursprüngliche EWGVertrag (durch die Beschlüsse des europäischen Gipfels von Maastricht 1992 namentlich zum Vertrag zur Gründung der Europäischen Gemeinschaft, 1 Ausführliche Informationen unter http://www.aif.de/. 2 Ausführliche Informationen unter http://cordis.europa.eu/eu-funding-guide/ home_de.html.

Kaiser

1121

M Rz. 72

Einzelprobleme

dem EGV, weiterentwickelt und mit dem Inkrafttreten des Vertrags von Lissabon 2009 in den Vertrag über die Arbeitsweise der EU, den AEUV, überführt) noch keine umfassende forschungspolitische Zuständigkeit enthielt, wurde das 1. Forschungsrahmenprogramm (1984–1987), dotiert mit 3,75 Mrd. Euro, durch einen Rückgriff auf die Generalklausel des Art. 308 EWGVertrag ins Leben gerufen. Erst durch die Ergänzungen der Einheitlichen Europäischen Akte im EWG-Vertrag wurde die forschungspolitische Lücke 1986 geschlossen. Seit dem 2. Forschungsrahmenprogramm (1987–1989) wurden Prioritäten zur Förderung festgelegt. Die Investitionen betrugen 5,4 Mrd. ECU. Das 3. Forschungsrahmenprogramm (1990–1994) umfasste 5,7 Mrd. ECU und hatte bereits eine Konzentration von Forschungsthemen zum Gegenstand. Im 4. Forschungsrahmenprogramm (1994–1998) wurden insgesamt 12,4 Mrd. ECU ausgezahlt und neue Prioritäten in der Forschung gesetzt. Seit 1998 war das 5. Forschungsrahmenprogramm in Kraft (1998–2002). Die Investitionen lagen bei 14,96 Mrd. Euro. Das 6. Forschungsrahmenprogramm (2002–2006) definierte klare Ziele für die Forschungsförderung, führte neue Förderinstrumente, Networks of Excellence (NoE) und Integrated Projects (IPs), ein und visierte bereits die Neuorganisation des Europäischen Forschungsraums (ERA) an. Das Budget belief sich auf 17,5 Mrd. Euro. Das 7. Forschungsrahmenprogramm (2007–2013) mit einem Budget von ca. 54 Mrd. Euro (inkl. Euratom) führte die Neustrukturierung vorhandener Instrumente aus und etablierte mit den „Gemeinsamen Technologieinitiativen“ (JTIs) neue Instrumente zur Durchführung der geförderten Projekte. Das Forschungsrahmenprogramm Horizon 2020 (2014–2020) treibt die Gestaltung des Europäischen Forschungsraums weiter voran und fördert besonders innovative Aktivitäten in der angewandten Forschung. Das Budget liegt gemäß Vorschlag der Kommission bei ca. 87 Mrd. Euro und wird zurzeit im Detail verhandelt1. 72 Die FRP werden in Abstimmung mit den einzelnen Mitgliedstaaten formuliert. Sie werden vom Rat auf Vorschlag der Kommission im Europäischen Parlament und nach Anhörung des Wirtschafts- und des Sozialausschusses nach dem Mitentscheidungsverfahren gemäß Art. 294 AEUV verabschiedet. Bei der Erstellung der FRP wird die Kommission von Ausschüssen beraten. Als institutioneller Kern der Beratung bei der Programmerstellung auf EUEbene werden der Ausschuss für europäische Entwicklung von Wissenschaft und Technologie (CODEST) und der Beratende Ausschuss für Industrielle Forschung und Entwicklung (IRDAC) genannt, die gemäß der Kommissionsentscheidung vom 23.10.1998 in das „European Research Forum“ (ERF) zusammengeführt wurden, das 2001 in das „European Research Advisory Board“ (EURAB) aufgegangen ist. Dieses wiederum wurde 2008 abgelöst vom sog. European Research Area Board (ERAB).

1 S. MEMO/11/848 der Europäischen Kommission v. 30.11.2011.

1122

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 76 M

a) Das 7. Forschungsrahmenprogramm (2007–2013) Im 7. Forschungsrahmenprogramm (2007–2013) standen insgesamt 50,521 73 Mrd. Euro Fördermittel (ohne Euratom) zur Verfügung. Das Budget war 68 % höher als im vorangehenden 6. Forschungsrahmenprogramm (2002–2006) und barg zusätzliche Ressourcen für die europäische Forschung. Die Laufzeit des 7. FRP war im Vergleich zu den vorangehenden Forschungsrahmenprogrammen aber nahezu verdoppelt, so dass die verfügbaren Jahresbeträge zwar höher waren, jedoch nicht so signifikant, wie es zunächst erscheint. Mit der Verpflichtung der Mitgliedstaaten im Jahr 2010 zur Erhöhung des bei den Mitgliedstaaten im Durchschnitt bei ca. 2 % des BIP liegenden Forschungsbudgets auf 3 % des BIP sendete das 7. FRP zudem eine starke politische Botschaft an die Mitgliedstaaten. Die Stärkung des Europäischen Forschungsraums (ERA) durch effizientere Bündelung europäischer Forschungsanstrengungen und -kapazitäten stand im Mittelpunkt des 7. FRP. Wichtige Elemente früherer Forschungsrahmenprogramme blieben erhalten: Europäische Partnerschaften in Form von Konsortien, grenzübergreifende Zusammenarbeit, offene Koordination, Flexibilität und Forschungsexzellenz. Auf der Basis unterschiedlicher Programme, den sog. Spezifischen Program- 74 men, setzte sich das 7. FRP zusammen. Das umfangsstarke Programm „Zusammenarbeit“ fokussierte dabei auf bedeutende Forschungsthemen wie Gesundheit, Informations- und Kommunikationstechnologien (IKT) und Weltraum. Die angestrebte Flexibilität dieses Programms sollte nach Ansicht der Kommission das Eingehen auf Bedürfnisse der Industrie gewährleisten und forcieren. Die folgende Auflistung der 7 Spezifischen Programme enthält mit den ersten 5 Programmen das 7. FRP der EU und mit den beiden letzten Programmen das Rahmenprogramm von Euratom: Zusammenarbeit (32,413 Mrd. Euro Fördervolumen)

75

Ideen (7,510 Mrd. Euro) Menschen (4,750 Mrd. Euro) Kapazitäten (4,097 Mrd. Euro) Gemeinsame Forschungsstelle (nicht nukleare Aktivitäten; 1,751 Mrd. Euro) Euratom (2,234 Mrd. Euro) Gemeinsame Forschungsstelle (nukleare Aktivitäten; 517 Mrd. Euro) Der neu gegründete Europäische Forschungsrat (ERC) zielte als erste euro- 76 paweite Agentur für Forschungsförderung auf die Finanzierung risikoreicher, aber potentiell höchst lohnender europäischer Pionierforschung. Als benutzergesteuerte Nachfolger der Europäischen Technologieplattformen (ETPs) wurden Gemeinsame Technologieinitiativen (JTIs) eingeführt, die verschiedene Partner zusammenführen sollten, um Ziele zu erreichen, die über eine bloße Aufforderung zur Antragseinreichung als nicht realisierbar galten. Die JTIs richteten sich an jene Forschungsbereiche, in denen vermehrte Zusammenarbeit und erhebliche Investitionen für einen langfris-

Kaiser

1123

M Rz. 77

Einzelprobleme

tigen Erfolg erforderlich sind. Im 7. FRP wurde zudem ein sog. Research Enquiries Service eingerichtet, der als Kontaktstelle für potentielle Teilnehmer und als Hilfestellung für Teilnehmer in EU-finanzierter FuE agierte. Aufgrund der Osterweiterung der EU und der Umstrukturierungen in der Kommission ist die Zuständigkeit für Forschung seit dem 7. FRP zwei Generaldirektionen (GDs) zugeordnet. Dies sind wie bisher die GD Forschung und nun auch die GD Unternehmen und Industrie. Einige Zuständigkeiten der GD Forschung, insbesondere solche der angewandten Forschung, unterliegen nun der GD Unternehmen und Industrie. b) Horizon 2020 – Das Forschungsrahmenprogramm für Forschung und Innovation (2014–2020) 77 Zur Strategie „Europa 2020“ (2010–2020) gehört als Leitinitiative die Vorstellung der Europäischen Union als einer Innovationsunion1. Das Forschungsrahmenprogramm Horizon 2020 (2014–2020) unterstützt die Leitinitiative der Strategie „Europa 2020“ und treibt diese systematisch voran. Maßnahmen sind eine weitere, gezielte Ausgestaltung des Europäischen Forschungsraums (ERA) nach Maßgaben gemeinsamer wissenschaftlicher Potentiale und wirtschaftlicher Möglichkeiten und die Rekrutierung neuer, gemeinsamer wissenschaftlicher und unternehmerischer Potentiale und Leistungsquellen in Europa. Drei Schwerpunkte des Forschungsrahmenprogramms Horizon 2020 sind: die Exzellenz europäischer Forschung und Wissenschaft, die Wettbewerbsfähigkeit europäischer Industrie und die Bewältigung aktueller Themen der Lebensbedingungen der Europäer. Hierzu gehören Themen wie der Klimawandel, die Energieversorgung und gesellschaftliche Herausforderungen wie der demografische Wandel2. 78 Das Forschungsrahmenprogramm Horizon 2020 bündelt verschiedene Forschungs- und Innovationsmaßnahmen der EU, z.B. Fördermaßnahmen des Europäischen Instituts für Innovation und Technologie (EIT3) und des Rahmenprogramms für Wettbewerbsfähigkeit und Innovation (CIP4) in einem Programm. Das Programm zeichnet sich aus durch eine Vereinfachung im Aufbau und eine Verschlankung seines administrativen Apparates mit ge1 S. KOM (2010) 546 endg. v. 6.10.2010, „Leitinitiative der Strategie Europa 2020. Innovationsunion“, S. 15; KOM (2010) 2020 endg. v. 3.3.2010, S. 6; KOM (2011) 808 endg. v. 30.11.2011, S. 2, S. 10–12. 2 S. KOM (2011) 808 endg. v. 30.11.2011, Mitteilung der Kommission an das Europäische Parlament, den Rat, sowie den europäischen Wirtschafts- und Sozialausschuss und den Ausschuss der Regionen. S. auch http://ec.europa.eu/research/ho rizon2020/index_en.cfm?pg=h2020#. 3 S. die Internetpräsenz des European Institute of Innovation and Technology unter http://eit.europa.eu/. 4 S. die Darstellung zum Competitiveness and Innovation Framework Programme unter http://ec.europa.eu/cip/index_de.htm, sowie, insbes. für kleine und mittlere Unternehmen, den Ausblick für den Zeitraum 2014 bis 2020 unter http:// ec.europa.eu/cip/cosme/index_en.htm.

1124

Kaiser

Rz. 83 M

Öffentliche Förderung von Forschung und Entwicklung

mindertem bürokratischem Aufwand für potentielle Teilnehmer, gewährt durch ein geändertes Kostenerstattungsmodell. Zudem gibt es weniger Formalitäten bei der Ausarbeitung von Vorschlägen und eine Reduktion von Kontrollen und Rechnungsprüfungen1. Das Budget von Horizon 2020, dessen Höhe zurzeit im Detail verhandelt 79 wird, übersteigt gemäß der von der Kommission am 30.11.2011 vorgelegten Summe von ca. 87 Mrd. Euro die Budgets bisheriger Forschungsrahmenprogramme deutlich2. Dem erfolgreichen Europäischen Forschungsrat kommt eine Steigerung seines bisherigen Fördervolumens um 77 % zu Gute3. Dies unterstreicht die im zweiten Schwerpunkt von Horizon 2020 angestrebte Stärkung der Wettbewerbsfähigkeit der europäischen Industrie und betont die besondere Förderung innovativer Aktivitäten in der angewandten Forschung. Einstweilen frei.

80–81

2. Die wichtigsten Zuwendungsbestimmungen im Überblick a) EU-Projekte Die Förderung wird im europäischen Sektor nicht mit Zuwendungsbeschei- 82 den, sondern mit Verträgen abgewickelt. Der Erlass von Zuwendungsbescheiden würde Hoheitsgewalt für die zuwendenden Einrichtungen voraussetzen, die im Unterschied zu der nationalen Souveränität der einzelnen Staaten nicht besteht. Der Vorrang von EU-Recht reicht hierzu nicht aus. Den Verträgen wird jeweils die Rechtsgeltung eines Mitgliedstaates zugrunde gelegt. Die Verträge mit der EU unterliegen z.B. seit dem 5. Forschungsrahmenprogramm ausschließlich belgischem oder luxemburgischem Recht. aa) Das Grant Agreement zum 7. Forschungsrahmenprogramm4 Das Grant Agreement enthält die Zuwendungsbedingungen für das geför- 83 derte Forschungsprojekt und regelt somit die Rechte und Pflichten der Teilnehmer gegenüber der Kommission. Wie bereits im 6. Forschungsrahmenprogramm existierte für das 7. Forschungsrahmenprogramm lediglich ein einziger Formularvertrag für das Grant Agreement mit einer Version der Ge1 S. KOM (2011) 808 endg. v. 30.11.2011, S. 4. 2 S. MEMO/11/848 der Europäischen Kommission v. 30.11.2011. Im ordentlichen Gesetzgebungsverfahren gem. Art. 294 AEUV wird das Budget vom Europäischen Parlament und vom Rat der Europäischen Union im Jahr 2013 verabschiedet. 3 S. die Darstellungen unter http://ec.europa.eu/research/horizon2020/index_en. cfm?pg=h2020 und unter http://erc.europa.eu/sites/default/files/document/file/ erc_highlight_ec_proposal_Horizon2020_0.pdf. 4 Bei Drucklegung befinden sich die Beteiligungsregeln für das Forschungsrahmenprogramm Horizon 2020 (2014–2020) in Verhandlung. Diese werden im Jahr 2013 vom Rat und vom Parlament der EU im Rahmen eines ordentlichen Gesetzgebungsverfahrens gem. Art. 294 AEUV verabschiedet.

Kaiser

1125

M Rz. 84

Einzelprobleme

neral Conditions (Annex II). Die Sondervorschriften für die unterschiedlichen Instrumente wurden in einem separaten Anhang (Annex III) behandelt. 84 Das Grant Agreement galt bei der Förderung durch die Kommission für alle Instrumente der indirekten Förderung („indirect actions“), womit Projektförderung im Unterschied zur institutionellen Förderung der eigenen Einrichtungen der EU gemeint war. Der Inhalt des Grant Agreements war grundsätzlich nicht verhandelbar, jedoch enthielt der Kernvertrag („Core Contract“) Optionen für unterschiedliche Fallgestaltungen. 85 Der Fördervertrag mit der EU auf Basis des Grant Agreements war grundsätzlich von allen Projektpartnern bilateral mit der Kommission abzuschließen. Allerdings wurde das Grant Agreement selbst lediglich durch die Kommission und den Koordinator (Art. 1 Nr. 1–4 des Kernvertrags) unterzeichnet. Der Vertrag trat damit in Kraft (Art. 11 des Kernvertrags). Die anderen Teilnehmer (sog. Contractors) traten dem Grant Agreement durch eine separate Beitrittserklärung bei, die als Annex IV dem Kernvertrag beigefügt war. 86 Unteraufträge mussten im Annex I aufgeführt sein, soweit es sich nicht um kleinere Dienstleistungen handelte, die zudem nicht wesentliche Aufgaben der Projektarbeiten darstellten, Annex II A 3 II 7 Nr. 2. Damit waren Unteraufträge mit nur geringem Forschungsanteil nur noch in Ausnahmefällen mit vorheriger Genehmigung der Kommission möglich. Der Auftraggeber musste ebenfalls gemäß Annex II A 3 II 7 Nr. 2 sicherstellen, dass bestimmte Regelungen des Annex II auch für den Unterauftragnehmer gelten. 87 Das Grant Agreement bestand grundsätzlich aus mindestens vier Teilen oder maximal acht Teilen (Kernvertrag und 3 bis 7 Anlagen): – Der eigentliche Text des Grant Agreements, der Kernvertrag („Core Contract“), ist relativ kurz und enthält nur den Gegenstand, die Kosten und andere formelle Vertragselemente. – Annex I enthält die technische Projektbeschreibung, die von den Teilnehmern abzuarbeiten ist. – Annex II enthält den rechtlichen Inhalt des Vertrags und alle allgemeinen Rahmenbedingungen und Grundsätze für die Durchführung des Projekts, wie z.B. die Finanzierung, Rechte am Ergebnis oder Haftung. Der Annex II ist nicht verhandelbar. – Annex III enthält die besonderen Bestimmungen für die einzelnen anzuwendenden Instrumente. Die jeweils zutreffende Version des Annex III mit den Vorschriften für das anzuwendende Instrument wird damit zum Vertragsbestandteil. – Annex IV und Annex V enthalten die Erklärung zum Beitritt der Teilnehmer (Contractors) am Projekt und die Beitrittserklärung später zum Konsortium hinzukommender Teilnehmer. – Annex VI und Annex VII enthalten die Kostenkalkulation des Projekts und die Einzelheiten für die Kostennachweise. 1126

Kaiser

Rz. 90 M

Öffentliche Förderung von Forschung und Entwicklung

Die Regelungen des Kernvertrags gehen den Regelungen in den Anhängen vor, der Annex III geht dem Annex II vor und diese beiden gehen wiederum dem Annex I vor. bb) Förderquoten und Kostenarten Die Förderquoten gem. Annex II B 1 II 16 des Grant Agreements betrugen im Einklang mit dem Gemeinschaftsrahmen für Forschung, Entwicklung und Innovation, der die gleiche Laufzeit wie das 7. Forschungsrahmenprogramm hatte:

88

Forschung und Entwicklung: 75 %

für öffentliche Stellen ohne Erwerbszweck, mittlere und höhere Bildungseinrichtungen und Forschungsorganisationen

75 %

für kleinere und mittlere Unternehmen

50 %

für alle übrigen Einrichtungen

Demonstrationsvorhaben: 50 %

für alle Rechtspersonen

Management, Audits, Training und sonstige Fördermaßnahmen: 100 %

für alle Rechtspersonen

Support Actions, Coordination Actions: 100 %

für alle Rechtspersonen1

Seit dem 7. Forschungsrahmenprogramm wurde ein Kostenerstattungssys- 89 tem (Art. 32 der Beteiligungsregeln2) eingeführt, das die früheren Kostenmodelle ersetzt. cc) Beteiligte an EU-Projekten An EU-Projekten sind verschiedene Parteien beteiligt. Man unterscheidet unter anderem: – Contractor: Er ist der Unterzeichner der bilateralen Vereinbarung mit der Kommission. – Coordinator: Er wird von den Projektteilnehmern gewählt und muss von der Kommission anerkannt werden. Der Coordinator handelt im Auftrag des Konsortiums (Art. 8 Kernvertrag). Er hat sicherzustellen, dass die übrigen Vertragspartner dem Fördervertrag rechtzeitig beitreten (Annex II A 1 General Principles Art. II Abs. 3) und trägt auch sonst die Verantwor1 Als Gemeinkostenpauschale werden nur 7 % der direkten Kosten erstattet. 2 Verordnung (EG) Nr. 1906/2006 des Europäischen Parlaments und des Rates v. 18.12.2006 zur Festlegung der Regeln für die Beteiligung von Unternehmen, Forschungszentren und Hochschulen an Maßnahmen des Siebten Rahmenprogramms sowie für die Verbreitung der Forschungsergebnisse (2007–2013) – ABl. L 391/1 v. 30.12.2006.

Kaiser

1127

90

M Rz. 91

Einzelprobleme

tung für die Durchführung des Projekts (Annex II A 1 General Principles Art. II Abs. 3a–c). Der Coordinator ist insbesondere für die Entgegennahme und entsprechende Verteilung der von der Kommission ausgezahlten Fördermittel verantwortlich. Ihm erwächst hierdurch jedoch keinerlei Entscheidungsbefugnis, er ist vielmehr „Zahlstelle“. Darüber hinaus ist der Coordinator Ansprechpartner für Mitteilungen der Vertragspartner und der Kommission (Annex II A 1 General Principles Art. II Abs. 3a–e). Die Kosten für die Koordination waren im 7. FRP ohne prozentuale Begrenzung förderfähig. – Subcontractor: Dieser Vertragspartner schließt, wie sonst auch bei Unterverträgen üblich, den Vertrag mit einem der Vertragspartner der EU (Contractor). Auch im 7. FRP waren Unterverträge mit Forschungsanteilen generell nur noch mit besonderer Begründung und vorheriger Genehmigung durch die Kommission erlaubt. Der Contractor musste sicherstellen, dass bestimmte Regelungen des Annex II auch für den Subcontractor gelten (Annex II A 3 II 7 Nr. 2, letzter Absatz). dd) Beteiligungsregeln und Antragsverfahren 91 Die Fördervoraussetzungen für das 7. FRP galten für alle Mitgliedstaaten sowie für die assoziierten Staaten mit Zugangsrechten zu den Programmen, z.B. der Schweiz, und waren in einer Verordnung der Kommission niedergelegt1. 92 Für das 7. FRP waren die Regelungen des Beihilferechts und des für die Forschung geltenden Gemeinschaftsrahmens zu beachten, den die Kommission mit Gültigkeit für den gleichen Zeitraum wie das 7. FRP erlassen hatte. Die Kommission betonte die Kontinuität zum 6. FRP und richtete die Beteiligungsregeln danach aus. 93 Zentrale Punkte der Beteiligungsregeln sind: – eine neue Definition der Forschungsorganisationen (Art. 2 Nr. 7 der Beteiligungsregeln) – ein zweiphasiges Verfahren für die Anträge zur Förderung (Art. 16 der Beteiligungsregeln) – ein Kostenerstattungssystem anstelle von Kostenmodellen (Art. 32 der Beteiligungsregeln) – Höchstgrenzen für die Förderung: neu ist die Anhebung der möglichen Quoten auf bis zu 75 % für öffentliche Einrichtungen, Hochschulen, Forschungsorganisationen, Sekundarschulen und kleine und mittlere Unternehmen (Art. 33 der Beteiligungsregeln) – die Einführung eines Risikofonds zur Abmilderung von Haftungsrisiken (Art. 38 der Beteiligungsregeln) – keine Begrenzung der Förderfähigkeit von Managementkosten auf 7 % 1 Verordnung (EG) Nr. 1906/2006 des Europäischen Parlaments und des Rates v. 18.12.2006 – ABl. L 391/1 v. 30.12.2006.

1128

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 98 M

– Regelungen für IP in Fortsetzung des 6. FRP (Art. 39 ff. der Beteiligungsregeln), kein Zustimmungserfordernis der Kommission für individuelle IP-Regelungen Förderanträge („Proposals for indirect actions“) konnten erst gestellt wer- 94 den, wenn die Kommission zur Abgabe im Rahmen einer Ausschreibung aufgefordert hat (Art. 16 Abs. 2 der Beteiligungsregeln). Dann wurde zunächst ein Kurzvorschlag von der Kommission erbeten und erst nach positiver Evaluation dieses Kurzvorschlags zur Abgabe des kompletten Förderantrages aufgefordert. Alle Aufrufe der Kommission werden im Amtsblatt der EU veröffentlicht und sind auch über die Cordis-Website abrufbar1. Die Kommission wählt den Begünstigten aufgrund der Qualität seines Antrages, also in einer Art Wettbewerbsverfahren, aus.

95

ee) Annex II (General Conditions) Annex II regelte die rechtlich essentiellen Teile des Vertrages mit der EU 96 und gab Definitionen vor2. Er war ebenso wie der Vertragstext selbst nicht verhandelbar und stellte das eigentliche juristische Regelwerk für die EUVertragspartner dar. Nach einem vorangestellten Definitionsteil folgten im Teil A die Regelungen u.a. über die Durchführung des Projekts, Unteraufträge und Kündigung, im Teil B die Finanzbestimmungen und im Teil C die Bestimmungen über die Rechte an den Projektergebnissen (Annex II C II 26–42: IP-Rechte, Transfer, Zugangsrechte für Foreground und Background u.a.). Wesentliche Punkte des Annex II waren: (1) Kalkulation und Kosten Sog. Cost-Statements waren als Grundlage für die Kalkulation des geförderten Projekts zusammen mit den Programm-Berichten im Rahmen des Reporting und der Kostenabrechnung vorzulegen. Die jeweiligen Förderquoten sind in Annex II B 1 II 16 niedergelegt. Es erfolgt eine Kostenerstattung (Annex II B 1 II 18). Das Vollkostenmodell kam auch im 7. FRP primär zur Anwendung.

97

(2) Geistiges Eigentum Die allgemein eingeführten Begriffe „Foreground“ und „Background“ wer- 98 den seit dem 7. FRP auch in der EU-Förderung verwendet. Der „Sideground“ wurde endgültig ausgeschlossen und wird nicht mehr als Teil des Backgrounds aufgefasst. Insofern ist die unglückliche Definition des 6. FRP revidiert. Allerdings nehmen die IP-Regeln einiger JTIs (Joint Technology Initiatives) diese Rechtsfigur wieder auf. 1 S. http://cordis.europa.eu. 2 Der Annex II ist abrufbar unter http://cordis.europa.eu/fp7/calls-grant-agreement _en.html.

Kaiser

1129

M Rz. 99

Einzelprobleme

Die Rechte am Ergebnis waren an den Regeln des 6. FRP orientiert, steigerten das Verwertungspotential aus EU-Projekten durch weitere Vereinfachung und Liberalisierung der Verwertungsrechte aber nochmals. Zunächst stand das Eigentum an den im Projekt entstehenden Kenntnissen – Foreground, d.h. im Projekt erarbeitetes IP – dem Teilnehmer zu, von dem die Kenntnisse stammen (Annex II C 1 II 26 Nr. 1). Soweit es sich um Projektergebnisse mehrerer Teilnehmer handelt, standen diese den jeweiligen Projektpartnern gemeinschaftlich zu (Annex II C 1 II 26 Nr. 2). 99 Für die Vertragspartner bestand die Pflicht, die Ergebnisse in angemessenem Rahmen schützen zu lassen (Annex II C 1 II 28). Geschah das nicht, stand der EU ein subsidiäres Anmelderecht zu (Annex II C 1 II 28 Nr. 3). Sollten die Kosten für den Schutz zu hoch sein, so gab es die Möglichkeit zur Förderung der Schutzrechtskosten. Damit die Verpflichtung zur Anmeldung nicht durch neuheitsschädliche Vorveröffentlichungen ins Leere lief, hatten die Vertragspartner die Kommission und die anderen Vertragspartner 30 Tage vor Veröffentlichung zu informieren. 100

Weiter unterlagen die Teilnehmer einer Verwertungspflicht, wobei die wirtschaftlichen Interessen der anderen Vertragspartner zu berücksichtigen waren (Annex II C 1 II 29).

101

Jeder der Projektpartner hatte den anderen Vertragspartnern an seinem Foreground für die Dauer und Durchführung des Vorhabens und, soweit dies für die eigenen Arbeiten notwendig war („Need to know-Prinzip“), unentgeltliche Zugangsrechte („access rights“) einzuräumen (Annex II C 1 II 33). Dies galt sowohl für den Foreground (Annex II C 1 II 33 Nr. 1) als auch für den Background (Annex II C 1 II 33 Nr. 2). Etwas anderes galt nur, falls der betreffende Vertragspartner im Falle des Background hierzu nicht berechtigt war oder dies vor dem Abschluss des Fördervertrags anders vereinbart wurde (Annex II C 1 II 33 Nr. 2). Soweit zur Verwertung der eigenen Ergebnisse die Nutzung von Kenntnissen anderer Projektpartner notwendig war, mussten diese am jeweiligen Foreground zu angemessenen Bedingungen („fair and reasonable conditions“) oder unentgeltlich gewährt werden (Annex II C 1 II 34 Nr. 1). Ein Zugangsrecht bestand auch für den Background, wenn es für die Verwertung notwendig war, und zwar ebenfalls zu angemessenen Bedingungen oder unentgeltlich.

102

Die Partner konnten – wie im 6. FRP – Background vertraglich aus dem Projekt ausschließen, wenn dies vor Projektbeginn vereinbart worden war. Das auszunehmende Wissen musste aber vor Unterzeichnung des Grant Agreements der EU bekannt sein. Nachträglich war eine Einschränkung des Zugangsrechts zum Background nicht mehr möglich, so dass ein entsprechender Einigungsdruck im Vorfeld bestand. Hier war aber zu beachten, dass die anderen Vertragspartner dem Ausschluss des Backgrounds nur widersprechen konnten, soweit durch den Ausschluss die Durchführung des Projektes oder die berechtigten Interessen der anderen Teilnehmer erheblich beeinträchtigt wurden. In diesem Zusammenhang war zu berücksichtigen, 1130

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 105 M

dass die vorgenannten Zugangsrechte prinzipiell keine Rechte zur Unterlizenzierung enthielten. Daher war es sinnvoll, im Rahmen des Konsortialvertrages bei Bedarf eine entsprechende Regelung vorzusehen. Es war jedoch die Einschränkung für die Vergabe von Zugangsrechten an Tochtergesellschaften außerhalb der EU und den assoziierten Staaten zu beachten (Annex II C 1 II 34 Nr. 3). Die Regelungen gaben den Partnern in EU-Projekten viel Dispositionsfrei- 103 heit, die im Rahmen des Konsortialvertrages ausgefüllt werden konnte. Lizenzrechte über die Zugangsrechte des Annex II hinaus konnten innerhalb des Konsortiums völlig frei vereinbart werden. (3) Berichte Die Zuwendungsempfänger hatten laufende Berichtspflichten (Annex II A 2 104 II 4). Die Berichte mussten den vorgesehenen Vertragsabschnitten entsprechend vorgelegt werden und Angaben über den Fortschritt der Arbeiten, die beabsichtigte Nutzung der Ergebnisse sowie einen Finanzbericht enthalten (Annex II A 2 II 4 Nr. 1a–c). Schließlich war ein Schlussbericht zu erstellen, dessen Inhalte vorgeschrieben waren (Annex II A 2 II 4 Nr. 2a–b). An die Finanzberichte und Abrechnungen wurden bestimmte Anforderungen gestellt (Annex II A 2 II 4 Nr. 4–8). Die Berichte entsprachen im 7. FRP zusammengefasst dem sog. „Technological Implementation Plan“ (TIP) des 6. FRP, dessen Funktionen zur Überwachung und Steuerung des Projekts in den Berichtspflichten mehr oder weniger enthalten waren. (4) Haftung Die Kommission schloss jede Haftung gegenüber den Empfängern der För- 105 derung aus (Annex II C 2 Final Provisions Nr. II 42 Nr. 1). Die Vertragspartner stellten darüber hinaus die Kommission auch von der Haftung gegenüber Dritten frei, die durch die Verwertung der Projektergebnisse eintreten konnte (Annex II C 2 Final Provisions Nr. II 42 Nr. 2). Die Vertragspartner stellten die Kommission auch für den Fall der Verletzung von Rechten Dritter frei (Annex II C 2 Final Provisions Nr. II 42 Nr. 3). Die Haftung war allerdings auf den entsprechenden Anteil des einzelnen Partners, den dieser am Gesamtprojekt hatte, beschränkt (Annex II B 2 II 20). Es wurde projektweise ein Fonds eingeführt, aus dem finanzielle Verpflichtungen bei Haftungsproblemen gedeckt werden sollten (Annex II B 2 II 21 Nr. 1–3). Ein Teil der Fördersumme wurde von jedem Partner für den Fonds einbehalten. Es konnte in bestimmten Fällen auch nachgefördert werden. Wenn es zu einem finanziellen Schaden gekommen war, wurde dieser zunächst aus dem Fonds gedeckt. Wurde ein verantwortlicher Partner ermittelt, konnte er von der Kommission zu einer zusätzlichen Zahlung an den Fonds verpflichtet werden (Annex II B 2 II 21 Nr. 4). Dieser Betrag wurde einfach von der Förderung abgezogen. Zum Ende des Projekts wurden ggf. Restbeträge aus dem Fonds wieder an die Teilnehmer ausgezahlt. Nach einem bestimmten

Kaiser

1131

M Rz. 106

Einzelprobleme

„Fund Index“ wurden die Beträge an die Mitglieder des Konsortiums verteilt. Dieser Betrag durfte ebenfalls nie den Anteil des jeweiligen Partners am Projekt übersteigen (Annex II B 2 II 21 Nr. 6). 106

In der Haftungsklausel des Grant Agreements war weder eine gesamtschuldnerische Haftung der Vertragspartner gegenüber der EU statuiert noch eine teilschuldnerische Haftung, wie sie im 6. FRP vorgesehen war. Die im Annex II vorgesehene Limitierung auf den Projektbetrag (Annex II C 2 II 20 1) zum Grant Agreement sprach deutlich für eine teilschuldnerische Haftung. Juristisch war dies aber nicht klargestellt, so dass mangels einer anderen klaren Regelung schlimmstenfalls eine Gesamtschuld anzunehmen war, die aber auf die Summe aller Beträge begrenzt war. Die gemeinsame Durchführung eines EU-Projekts ist ohne Zweifel eine (Innen-)Gesellschaft im Sinne unserer BGB-Gesellschaft. Man kann nicht annehmen, dass belgisches oder luxemburgisches Recht bei einer solchen Situation zu einer Teilschuld kommen würde. Deshalb wird man wohl bei der „joint and several liability“, also der Gesamtschuld, ankommen, wobei die Haftungshöhe aber jedenfalls gegenüber der Kommission auf eine teilschuldnerische Haftung in Höhe des eigenen Betrags limitiert ist. Dies kam im Grant Agreement zum Ausdruck. Für die Ausgleichsansprüche untereinander gilt der jeweils vereinbarte Konsortialvertrag mit den internen Verpflichtungen oder Limitierungen. (5) Anwendbares Recht

107

Als anwendbares Recht gilt das Recht des Sitzes der bewilligenden Stelle in der Kommission. Damit kommt für Verträge mit der Kommission nur noch belgisches Recht (für Generaldirektionen in Brüssel) und luxemburgisches Recht (für Generaldirektionen in Luxemburg) in Frage. Die Rechtsgeltung wird formularmäßig vereinbart. (6) Der Muster-Konsortialvertrag DESCA

108

Die Vertragspartner eines EU-Projekts müssen in einem Konsortialvertrag festlegen, wie sie die Durchführung untereinander gestalten und welche Rechtsbeziehungen sie – über die Verpflichtungen aus dem Grant Agreement hinaus – untereinander eingehen möchten. In den Rahmenprogrammen gab es Muster für Konsortialverträge, die von Interessenvertretern aus Wissenschaft und Wirtschaft ausgehandelt wurden. Für das 7. FRP hatte sich eine Europäische Initiative gebildet, die ein solches Muster entwickelt hatte. Dieses wurde DESCA (Development of a Simplified Consortium Agreement for FP7) genannt1. Beteiligt waren bei der Verhandlung des Vertragsmusters unter anderen die europäischen Interessengemeinschaften CAT, EARTO, UNITE, EUROCHAMBRES, ANRT, EICTA und EUCAR. Für das Forschungsrahmenprogramm Horizon 2020 wird ein entsprechender Vertrag ausgehandelt werden.

1 S. http://www.desca-fp7.eu/.

1132

Kaiser

Rz. 113 M

Öffentliche Förderung von Forschung und Entwicklung

Der Vertrag war modular aufgebaut und bot unterschiedliche Optionen. Es 109 gab ein Grundmuster, von dem ausgehend folgende weitere Varianten entwickelt wurden: – – – –

kleine Projekte zwischen Universitäten und Forschungseinrichtungen kleine Projekte in Zusammenarbeit mit Unternehmen große Projekte zwischen Universitäten und Forschungseinrichtungen große Projekte in Zusammenarbeit mit Unternehmen

Alle Muster gingen von der gleichen Grundstruktur aus. Je nach Art und 110 Größe des Projekts wurden verschiedene Gremien vorgesehen, die unterschiedlich zusammengesetzt waren (siehe „Remarks“ im DESCA-Grundmuster). DESCA sah einen gegenseitigen Haftungsausschluss für ausgetauschte In- 111 formationen sowie Rechtsmängel vor. Ebenso bestand keine gegenseitige Haftung für indirekte Schäden, Folgeschäden oder entgangenen Gewinn. Die Haftungssumme blieb damit für gegenseitige Ansprüche auf die einfache oder zweifache Projektsumme der jeweiligen Partner beschränkt. Vorsatz und grobe Fahrlässigkeit wurden nicht ausgeschlossen (Sektionen 4 und 5). Im Verhältnis zur Kommission haftete jeder Projektteilnehmer nur in Höhe seines jeweiligen Projektanteils (Grant Agreement, Annex II C 2 Garantiefonds und Einziehungen 20, 1), womit eine gesamtschuldnerische Haftung gegenüber der Kommission entfallen dürfte. Die allgemeinen Regelungen wie Geheimhaltung (Sektion 10), anwendbares Recht (Sektion 11.7) oder Streitschlichtung (Sektion 11.8) entsprachen den allgemeinen Gepflogenheiten für Konsortialverträge. Das Agreement mit der Kommission geht dem Konsortialvertrag stets vor (Sektion 11.1). Der wichtigste Bereich des DESCA ist die Zuordnung des jeweils einzeln 112 oder gemeinsam erarbeiteten geistigen Eigentums. Zunächst ist für den Background der einzelnen Teilnehmer die Möglichkeit gegeben, dieses von der Durchführung/Verwertung des Projekts auszunehmen. Dies kann nötig sein, wenn ein Projektpartner bereits an einen Dritten vertraglich gebunden ist oder wenn er nicht möchte, dass bestimmter Background eingebracht wird. In einem solchen Fall können solche Background-Rechte in einer Vereinbarung vor Abschluss des Vertrages ausgeschlossen werden (Ziffer 9 DESCA mit 3 verschiedenen Optionen). Das entspricht im Übrigen den Rahmenbedingungen des ANNEX II zum Grant Agreement (Grant Agreement, Annex II C 2 Zugangsrechte 32, 3). Diese auszuschließenden Rechte sind dem Konsortium mitzuteilen. Die General Assembly entscheidet dann über die Bedeutung und Behandlung dieser Rechte. Die Struktur des DESCA für IP-Regeln war wie folgt aufgebaut: Sektion 8.

Foreground, Ownership, Transfer, Publication

Sektion 9.2

General Principles

Sektion 9.3

Access Rights for Implementation

Kaiser

113

1133

M Rz. 114

Einzelprobleme

Sektion 9.4

Access Rights for Use

Sektion 9.5

Access Rights for Affiliated Entities

Sektion 9.6

Additional Access Rights

Sektion 9.7

Access Rights for Parties entering or leaving the Consortium

Sektion 9.8

Specific Provisions for Access Rights to Software

114

Das Grant Agreement verlangte den Abschluss einer Vereinbarung über gemeinsames Eigentum. Solange eine solche Vereinbarung fehlte, räumten sich die Vertragspartner Lizenzen an ihrem geistigen Eigentum ein – allerdings ohne das Recht, Unterlizenzen zu erteilen. Nach den DESCA-Optionen konnten das einmal die Rechte des Grant Agreements oder Rechte mit Unterlizenzmöglichkeiten sein.

115

Das Muster folgte wie bisher dem Prinzip, dass sich die Vertragspartner an ihren Rechten gegenseitig Zugangsrechte („access rights“) gewähren. Die Rechte mussten dabei insoweit eingeräumt werden, wie sie tatsächlich von den Partnern für die Verwertung ihrer eigenen Ergebnisse gebraucht wurden („Need-Prinzip“). Dabei wird zwischen den Rechten zur Durchführung des Projekts und den Rechten für Verwertungszwecke unterschieden. Es ist jeweils definiert, was „Need“ bedeutet (siehe Sektion 1 DESCA, Definitionen). Im Wesentlichen wird darauf abgestellt, dass das Projekt ohne die eingeräumten Rechte nicht oder nur mit erheblichen Problemen durchgeführt werden kann. In diesem Fall muss die Lizenz zur Durchführung gewährt werden. In der Verwertungsphase muss das IP so wichtig sein, dass sonst die Ergebnisverwertung technisch oder rechtlich unmöglich wird.

116

Das DESCA differenzierte zwischen Foreground und Background. Dem Foreground war in Sektion 8 zusätzlich zu den Zugangsrechten ein eigenes Kapitel gewidmet. Hier ging es um Ergänzungen zum Begriff des Foreground im Sinne des Grant Agreements (Annex II C II 26). Hier wurden Klarstellungen zum gemeinsamen Eigentum (zwei Optionen), den Rechten der Vertragspartner zum Technologietransfer und zu Veröffentlichungen vorgenommen. In Sektion 9 waren die Zugangsrechte für Foreground und Background geregelt.

117

Für die Projektdurchführung sind Zugangsrechte einzuräumen. Auch hier gilt das „Need-Prinzip“. Für die Durchführung des Projekts („Implementation“) gibt es zusätzlich zu den Rechten der anderen Partner jeweils Zugangsrechte, am Background ein nicht ausschließliches und unentgeltliches Nutzungsrecht, soweit der Background nicht ausgeschlossen wurde, und am Foreground ein nicht ausschließliches und unentgeltliches Nutzungsrecht.

118

Das DESCA kannte zwei Optionen für die Behandlung des Backgrounds. In der ersten Option wird der Background aufgelistet, der in das Projekt aufgenommen wird. Alles andere soll ausgeschlossen sein. Genau andersherum sieht eine zweite Option vor, dass man den ausgeschlossenen Background auflistet und alles andere einzubringen ist (Sektion 9.1, Option 2).

1134

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 122 M

Änderungen nach Abschluss des Vertrags sind dann nur noch mit Zustimmung der General Assembly möglich. Der sog. Sideground – IP, das zeitlich nicht vor der Projektlaufzeit, sondern parallel dazu entsteht – ist nicht mehr Bestandteil des Backgrounds, wie es das 6. FRP noch vorsah. Die Zugangsrechte zu IP aus Parallelprojekten der Vertragspartner waren immer schon problematisch und sind im Prinzip nicht gerechtfertigt, da dort häufig andere rechtliche Verpflichtungen bestehen, mit denen man in Konflikt geraten kann. Der gegenseitige Zugang der Vertragspartner zum Background des anderen ist unentgeltlich (Sektion 9.3), wenn er für die Durchführung des Projekts benötigt wird („Need-Prinzip“) und nicht über eine Background Liste ausgeschlossen wurde. Die Nutzung des Backgrounds von anderen Partnern zu Verwertungszwecken des eigenen IP ist stets nicht ausschließlich und immer entgeltlich (Sektion 9.4). Auch bei der Behandlung des Foregrounds waren zwei Optionen vorgese- 119 hen. Eine davon sah angemessene Bedingungen („fair and reasonable conditions“) für den Fall vor, dass der eingeräumte Foreground für die Verwertung des eigenen IP benötigt wurde („Need-Prinzip“) und IP-Rechte Dritter enthalten waren. Über die Einräumung von IP eines Vertragspartners darf nie ein Zugang zu Rechten Dritter hergestellt werden, ohne dass dieser Dritte zustimmt. Dieser Fall, dass weiteres IP von Partnern außerhalb in das Projekt eingebracht werden kann, soll nicht ausgeschlossen sein. Dieses Vorgehen kann unter Umständen sinnvoll sein. In einem solchen Fall würde aber bei Nutzung ohne Zustimmung des Dritten ein unzulässiger Vertrag zu Lasten Dritter entstehen. Eine andere Option sah vor, dass der Zugang zu den Rechten der anderen Vertragspartner unentgeltlich ist, soweit das IP für die Verwertung der eigenen Ergebnisse gebraucht wird („Need-Prinzip“). Hier ist der Regelfall gemeint, dass lediglich das IP der anderen Vertragspartei benötigt wird, nicht aber evtl. Rechte Dritter. In diesen Fällen ist die Einräumung der Rechte unentgeltlich (Sektion 9.4). Die Verwendung für weitere, eigene Forschungstätigkeit ist ohnehin stets unentgeltlich (9.4.1, Option 1, Satz 2). Für einen neu beitretenden Vertragspartner wurde der bisher erarbeitete 120 Foreground als Background behandelt. Ausscheidende Partner mussten die Zugangsrechte des Vertrags weiter gegen sich gelten lassen. Wenn ein Vertragspartner freiwillig ausschied, konnte er weiter seine bis zum Ausscheiden geltenden Zugangsrechte beanspruchen. Schied er aufgrund Verschuldens aus, verlor er seine Zugangsrechte. Es gab weitere Sonderregelungen für verbundene Gesellschaften (Sektion 9.5). Diese konnten entweder die gleichen Rechte haben wie die Zuwendungsempfänger aus dem Grant Agreement (9.5, Option 1) oder mit zusätzlichen Bedingungen versehen werden (9.5, Option 2).

121

Für Software galten ergänzende Sonderregeln an verschiedenen Stellen des DESCA (z.B. Sektion 9.8 hinsichtlich der Access Rights).

122

Kaiser

1135

M Rz. 123 123

Einzelprobleme

Zwei weitere Muster mit Vorteilen für die Industrieseite stammten von EUCAR (Automotive Industrie) und EICTA (IT-Technologie)1. b) Andere europäische Förderstellen

124

Andere europäische Förderstellen, wie zum Beispiel die European Space Agency (ESA) haben grundsätzlich eigene Regelungen2, die oft wesentlich voneinander abweichen. Selbst innerhalb der Kommission wird die Förderung etwa der Euratom nach gesonderten Regelungen gewährt. Die Kostenerstattung bei ESA-Projekten beträgt meist 100 %. Das Problem besteht im harten Wettbewerb um die Aufträge. Die Angebote an die ESA müssen nach bestimmten, sehr detaillierten Regularien ausgeführt sein. Dann findet ein Wettbewerb statt, bei dem das beste Angebot ausgewählt wird. Der Aufwand für ein aussichtsreiches Angebot ist erheblich und schreckt viele Anbieter ab. Die ESA als besonderes Gebilde mit eigenem Staatsvertrag hat auch hinsichtlich ihrer Vertragsbedingungen für die Forschungsförderung Besonderheiten3.

IV. Sonderfall Softwareerstellung 125

In der öffentlichen Förderung gibt es natürlich auch Projekte, die die Erstellung von Software-Programmen oder Forschung (z.B. Softwaresicherheit) zum Gegenstand haben oder zumindest mit umfassen. Hierzu gibt es keine Sonderregelungen im Zuwendungsrecht. Software-Projekte sind wie folgt von den allgemeinen Regeln erfasst. 1. Die NKBF des BMBF

126

Die NKBF sowie andere Regelwerke definieren den Begriff „Ergebnisse“. Dort ist Software ganz grundsätzlich mit enthalten. Die NKBF sprechen von „… allen Erkenntnissen, Erfindungen, entwickelten Gegenständen, Verfahren und Rechenprogrammen, die bei der Durchführung des Vorhabens entstehen …“. Die Software ist damit durch den Begriff „Rechenprogramme“ erfasst, Ziff. 9.1 NKBF. In der Folgevorschrift weist Ziff. 10.5 für „in sonstiger Weise (insbesondere urheberrechtlich) geschützter Teile des Ergebnisses …“ darauf 1 Weiterführende Informationen sind im Abschnitt „Musterverträge“ unter http://www.forschungsrahmenprogramm.de/konsortialabkommen.htm erhältlich. 2 Informationen unter http://www.esa.int vor allem unter dem Suchbegriff „esa and the eu“. 3 Einzelheiten zur Politik der ESA und zu Rahmenbedingungen einer Förderung der Raumfahrt vgl. Grünbuch – Europäische Raumfahrtpolitik, KOM (2003) 17 endg. v. 21.1.2003; Weißbuch, KOM (2003) 673 endg. v. 11.11.2003; sowie zum Abschluss eines Rahmenabkommens zwischen der ESA und der EG 2004/578/EG – ABl. L 261 v. 6.8.2004.

1136

Kaiser

Öffentliche Förderung von Forschung und Entwicklung

Rz. 130 M

hin, dass der Zuwendungsempfänger sicherzustellen hat, dass er seinen Verpflichtungen nach Ziff. 13.1 aus dem Zuwendungsbescheid nachkommen kann. Ziff. 13.1 regelt lediglich die Pflicht des Zuwendungsempfängers, die Ergebnisse für Forschung und Lehre und bei besonderem öffentlichem Interesse zur Verfügung zu stellen. Damit wird die Sorge für die gegebenenfalls notwendige rechtliche Sicherung auf den Zuwendungsempfänger übertragen. Sollte bei einem Ergebnis, das Software enthält, ein besonderer Schutz notwendig sein, obliegt diese Sicherstellung dem Zuwendungsempfänger. Da Software kraft Gesetzes geschützt ist, werden zunächst keine zusätzli- 127 chen Maßnahmen erwartet. Allenfalls in den Fällen, in denen eine patentrechtliche Sicherung der Software möglich ist oder ein Name oder eine Marke zu schützen ist, würde den Zuwendungsempfänger eine solche Pflicht treffen. Bei kleinen und mittleren Unternehmen werden sog. „notwendige Kosten“ hierzu als zuwendungsfähig anerkannt. In einem Verweis auf Ziff. 5.6.1 NKBF, in der die zuwendungsfähigen Kosten definiert sind, findet sich aber nur die Ersatzfähigkeit von Kosten für Schutzrechtsanmeldungen. Es ist zwar nicht sicher, ob hier an die patentfähigen Softwareprogramme gedacht war, da die Anmeldepraxis beim Erlass der NKBF 98 zu der heutigen unterschiedlich war, diese Fälle würden aber darunterfallen. 2. Vertragsbedingungen des Bundes für die Beschaffung von IT-Dienstleistungen (EVB-IT) und von DV-Anlagen und Geräten Bund, Länder und Kommunen haben sich seit 2002 zur Einführung einer 128 Neufassung der gemeinsamen Vertragsbedingungen für die Beschaffung informationstechnischer Leistungen und entsprechender Geräte verständigt. Die EVB-IT werden laufend aktualisiert, letzte Mustertexte stammen vom November 2012. Durch die EVB-IT werden die BVB in vielen Bereichen abgelöst. Die verschiedenen Vertragsmuster sind auf einer Internetseite des Bundes zu finden1. Die Vertragsmuster decken das gesamte Beschaffungsspektrum ab. Die 129 EVB-IT sind anwendbar für Systemlieferung, System, Kauf, Dienstleistung, Überlassung Typ A und Typ B, Instandhaltung und Pflege S. Die BVB gelten noch für Verträge zur Pflege, Miete und Planung. Bei diesen Vertragsmustern handelt es sich um Sonderregelungen des öffentlichen Vergaberechts. Die Übergänge der Vertragstypen sind bei Neuentwicklungen oder FuELeistungen durchaus fließend und überlappen sich mit dem allgemeinen Zuwendungsrecht. So kann beispielsweise die Entwicklung einer völlig neuen Software FuE-Charakter haben und aus diesem Grund nicht der Beschaffung, sondern den Regelungen der Forschungsförderung unterfallen. Dann finden die Regelungen der EVB-IT keine Anwendung. Die Einzelregelungen der Verträge nach EVB-IT unterliegen dem Kaufrecht, dem Werkvertragsrecht oder dem Dienstvertragsrecht, je nachdem, welches 1 http://www.cio.bund.de/DE/IT-Beschaffung/it_beschaffung_node.html.

Kaiser

1137

130

M Rz. 131

Einzelprobleme

Moment im einzelnen Vertragstyp überwiegt. Soweit geistiges Eigentum entsteht, regelt für jeden Vertragstyp eine sog. Nutzungsrechtsmatrix den Umfang der Nutzungsrechte für den Auftraggeber im Einzelnen. 3. Annex II (General Conditions) der EU 131

Auch im ANNEX II des Grant Agreements des 7. FRP der EU existierten keine Sonderregelungen für die Förderung von Softwareprojekten. Insoweit finden die üblichen Regelungen Anwendung. In den Begriffsbestimmungen des Annex II sind unter Ziff. 7 „copyrights“ und „similar forms of protection“ genannt, worunter die Behandlung der Softwarerechte zu subsumieren ist.

V. Zusammenfassung 132

Die öffentliche Forschungsförderung und damit auch das Zuwendungsrecht und seine Praxis sind sehr vielgestaltig. Bestimmte zentrale Vorgehensweisen und Vorschriften finden sich in allen Förderprogrammen wieder und werden je nach dem notwendigen Sachbezug und den Besonderheiten der fördernden Stellen angepasst. Das BMBF als wichtigste Fördereinrichtung in Deutschland und die Generaldirektionen Forschung sowie Unternehmen und Industrie als die bedeutendsten der Europäischen Union verfügen über die größten Fördervolumina. Dementsprechend findet man dort auch die größte Erfahrung mit Förderprojekten und die vergleichsweise routiniertesten Vorgehensweisen. Dennoch tauchen auch dort immer wieder Fragen und Konstellationen auf, die mit den Standards der Förderbestimmungen oder Verträge nicht ohne weiteres bewältigt werden können. Insoweit ist ein hohes Maß an Flexibilität bei Zuwendungsgeber und -empfänger gefragt.

1138

Kaiser

N. Öffentliche Vergabe von IT-Leistungen Rz. I. Überblick über die rechtlichen Grundlagen des Vergaberechts . 1. Einschlägige Vorschriften . . . . . a) Einführung . . . . . . . . . . . . . . . . b) EU-Richtlinien und deren Umsetzung. . . . . . . . . . . . . . . . aa) EU-Richtlinien . . . . . . . . . bb) Umsetzung der EURichtlinien . . . . . . . . . . . . cc) Ausblick. . . . . . . . . . . . . . c) Vorschriften des 4. Teils des GWB . . . . . . . . . . . . . . . . . . . . . d) Vergabeverordnung und Sektorenverordnung. . . . . . . . e) Die einzelnen Vergabe- und Vertragsordnungen . . . . . . . . . 2. Grundprinzipien des Vergaberechts . . . . . . . . . . . . . . . . a) Wettbewerbsgrundsatz . . . . . b) Gleichbehandlungsgrundsatz . . . . . . . . . . . . . . . . . . . . . . . c) Transparenzgrundsatz . . . . . . d) Berücksichtigung mittelständischer Interessen . . . . . . e) Prinzip der Wirtschaftlichkeit, Vergabe an geeignete Unternehmen . . . . . . . . . . . . . II. Ausschreibungspflicht . . . . . . . . 1. Einleitung . . . . . . . . . . . . . . . . . . . 2. Öffentlicher Auftraggeber, § 98 GWB . . . . . . . . . . . . . . . . . . . 3. Öffentlicher Auftrag, § 99 GWB . . . . . . . . . . . . . . . . . . . a) Grundsätze. . . . . . . . . . . . . . . . b) Ausnahmetatbestand „Inhouse-Geschäft“ . . . . . . . . c) Vertragsänderungen, -verlängerungen . . . . . . . . . . . aa) Vertragsverlängerungen . bb) Inhaltliche Vertragsänderungen . . . . . . . . . . . . d) Rahmenvereinbarungen . . . . aa) Vergaberechtliche Ausgangslage . . . . . . . . . . bb) Definition . . . . . . . . . . . . . cc) Bindungsgrad. . . . . . . . . . . dd) Wesentlicher Inhalt . . . . .

1 1 1 5 5 8 11a 12 13 16 17 19 20 22 24

28 29 29 31 34 34 36 40 41 42 45 45 47 48 49

Rz. ee) Rahmenvereinbarung mit einem oder mehreren Unternehmen . . . . . . . ff) Zweistufiger Beschaffungsvorgang . . . . . . . . . . . gg) „Sperrwirkung“ . . . . . . . . 4. Nationales oder EU-Vergaberecht . . . . . . . . . . . . . . . . . . . . . . . . a) Schwellenwert . . . . . . . . . . . . . b) Schätzung des Auftragswerts . . . . . . . . . . . . . . . . . . . . . 5. Ausnahmen vom Anwendungsbereich des Vergaberechts . . . . . . . . . . . . . . . . . . . 6. Anzuwendende Vergabe- und Vertragsordnungen . . . . . . . . . . . a) Abgrenzung von VOB, VOL und VOF . . . . . . . . . . . . . . . . . . b) Lieferleistungen. . . . . . . . . . . . c) Sonstige Leistungen/Dienstleistungen . . . . . . . . . . . . . . . . . d) Gemischte Verträge . . . . . . . .

52 53 55 56 56 59

67 68 68 69 70 73

III. Verfahrensarten nach VOL/A . . 76 1. Einleitung . . . . . . . . . . . . . . . . . . . 76 a) EU-Ebene . . . . . . . . . . . . . . . . . 76 b) Nationale Ebene . . . . . . . . . . . 79 c) Wahl des „richtigen Verfahrens“ . . . . . . . . . . . . . . . . . . . 80 2. De-Facto-Vergaben . . . . . . . . . . . 82 a) Begriff. . . . . . . . . . . . . . . . . . . . . 82 b) Folgen . . . . . . . . . . . . . . . . . . . . 84 3. Das offene Verfahren/die öffentliche Ausschreibung . . . . . . 85 4. Das nichtoffene Verfahren (national: die beschränkte Ausschreibung). . . . . . . . . . . . . . . 89 5. Das Verhandlungsverfahren/ die freihändige Vergabe. . . . . . . . 93 a) Bedeutung und Merkmale . . . 93 b) Voraussetzungen . . . . . . . . . . . 97 c) Ablauf des Verhandlungsverfahrens/der freihändigen Vergabe . . . . . . . . . . . . . . . . . . . 102 6. Wettbewerblicher Dialog . . . . . . 105 a) Einleitung . . . . . . . . . . . . . . . . . 105 b) Anwendungsbereich . . . . . . . . 106

Bischof

1139

N

Einzelprobleme Rz.

Rz.

c) Ablauf des Wettbewerblichen Dialogs . . . . . . . . . . . . . 109 aa) Auswahlphase . . . . . . . . . 109 bb) Dialogphase . . . . . . . . . . . . 111 cc) Angebotsphase . . . . . . . . . 114

ee) EVB-IT Instandhaltung . . 184 ff) EVB-IT Pflege S . . . . . . . . . 185 gg) EVB-IT System . . . . . . . . . 189 hh) EVB-IT Systemlieferung . 194 ii) EVB-IT Erstellung. . . . . . 198a jj) Ausblick . . . . . . . . . . . . . . . 199

IV. Vorbereitung von Vergabeverfahren . . . . . . . . . . . . . . . . . . . . 116 1. Anlegung einer Vergabeakte, Vergabevermerk. . . . . . . . . . . . . . 116 2. Feststellung des Beschaffungsbedarfs . . . . . . . . . . . . . . . . . . . . . . 120 3. Sicherstellung der Finanzierung und ggf. Genehmigung . . . 123 4. Aufstellung der internen Organisation des Auftraggebers . . . . 125 5. Externe Unterstützung des Auftraggebers/Projektantenproblematik . . . . . . . . . . . . . . . . . 128 6. Marktanalyse . . . . . . . . . . . . . . . . 131 7. Erstellung der Vergabeunterlagen . . . . . . . . . . . . . . . . . . . 134 8. Leistungsbeschreibung . . . . . . . 139 a) Bedeutung . . . . . . . . . . . . . . . . 139 b) Anforderungen an die Leistungsbeschreibung . . . . . . . . . 140 c) Arten von Leistungsbeschreibungen . . . . . . . . . . . . 145 d) Erstellung der Leistungsbeschreibung . . . . . . . . . . . . . . 150 e) Überprüfung der Erfüllung der Anforderungen in der Leistungsbeschreibung im Vergabeverfahren . . . . . . . . . . 152 f) Fehlerhafte Leistungsbeschreibungen . . . . . . . . . . . . 153 9. Zuschlagskriterien . . . . . . . . . . . 155 10. Vertragliche Gestaltung . . . . . . . 168 a) Einleitung. . . . . . . . . . . . . . . . . 169 b) Zur Verfügung stehende Vertragsbedingungen . . . . . . . 170 c) EVB-IT als AGB . . . . . . . . . . . . 172 d) Anwendbarkeit und Lösungsansätze . . . . . . . . . . . . 174 e) Formaler Aufbau der EVB-IT 177 f) Die einzelnen Vertragstypen 180 aa) EVB-IT Kauf . . . . . . . . . . . 180 bb) EVB-IT Überlassung Typ A . . . . . . . . . . . . . . . . . 181 cc) EVB-IT Überlassung Typ B . . . . . . . . . . . . . . . . . . 182 dd) EVB-IT Dienstleistung . . 183

1140

Bischof

V. Durchführung von Vergabeverfahren . . . . . . . . . . . . . . . . . . . . 200 1. Vergabebekanntmachung. . . . . . 200 a) EU-Vergaben. . . . . . . . . . . . . . . 200 b) Nationale Vergaben . . . . . . . . 204 2. Teilnahmeantrag: Anforderungen und Frist . . . . . . . . . . . . . . 206 3. Eignung: Fachkunde, Leistungsfähigkeit, Gesetzestreue und Zuverlässigkeit. . . . . . . . . . . 210 a) Grundsätze . . . . . . . . . . . . . . . . 210 b) Übersicht zu den Eignungskriterien . . . . . . . . . . . . . . . . . . 212 c) Nachweis der Eignung . . . . . . 216 aa) Finanzielle und wirtschaftliche Leistungsfähigkeit . . . . . . . . . . . . . . . 218 bb) Fachliche und technische Leistungsfähigkeit. . . . . . . . . . . . . . . . . . . . 220 cc) Nachweis des Nichtvorliegens von Ausschlussgründen . . . . . . . . . . . . . . . . 222 dd) Nachweis der Eintragung im Berufs- oder Handelsregister . . . . . . . . . 226 ee) Präqualifizierungsverfahren . . . . . . . . . . . . . . 227 4. Teilnahmewettbewerb . . . . . . . . 230 aa) Auswahl der Bieter . . . . . . 230 bb) Fehlen von Unterlagen . . 233 cc) Information der ausscheidenden Bewerber . . . 234 5. Aufforderung zur Angebotsabgabe . . . . . . . . . . . . . . . . . . . . . . . 237 6. Angebote . . . . . . . . . . . . . . . . . . . . 242 a) Vorgaben für die Bieter . . . . . . 242 b) Öffnung durch die Vergabestelle . . . . . . . . . . . . . . 243 7. Verhandlungen mit den Bietern . . . . . . . . . . . . . . . . . . . . . . 244 8. Bewertung der Angebote . . . . . . 248 a) Einleitung . . . . . . . . . . . . . . . . . 248 b) Zwingende Ausschlussgründe . . . . . . . . . . . . . . . . . . . . 249

N

Öffentliche Vergabe von IT-Leistungen Rz.

Rz.

aa) Fakultative Ausschlussgründe . . . . . . . . . . . . . . . . . 251 bb) Eignungsprüfung . . . . . . . 252 cc) Angemessenheit des Preises . . . . . . . . . . . . . . . . 253 dd) Wirtschaftlichstes Angebot . . . . . . . . . . . . . . . 254 9. Zuschlagserteilung, Informations- und Wartepflicht gem. § 101a GWB . . . . . . . . . . . . . . . . . 255 10. Vergabevermerk, Veröffentlichung des Ergebnisses des Vergabeverfahrens . . . . . . . . . . . . 257 a) Vergabevermerk . . . . . . . . . . . 257 b) Veröffentlichung des Verfahrensergebnisses . . . . . . . . . 263

a) Primärrechtsschutz: Das Nachprüfungsverfahren . . . . . 287 aa) Allgemeines . . . . . . . . . . . . 287 bb) Zuständigkeit . . . . . . . . . . 288 cc) Zulässigkeit des Nachprüfungsantrags . . . . . . . . 292 dd) Nachprüfungsantrag, § 107 Abs. 1 GWB . . . . . . . 293 ee) Antragsbefugnis, § 107 Abs. 2 GWB . . . . . . . . . . . . 298 ff) Rechtzeitige Rüge, § 107 Abs. 3 GWB . . . . . . . 308 gg) Unverzügliche Begründung des Nachprüfungsantrags (§ 108 Abs. 1 GWB) . . . . . . . . . . . . . . . . . . 321 hh) Zustellung des Nachprüfungsantrags und Wirkung (§ 115 GWB). . . . . . . 322 ii) Verfahrensbeteiligte sowie deren Rechte und Pflichten . . . . . . . . . . . . . . . 324 jj) Untersuchungsgrundsatz, § 110 GWB . . . . . . . . 330 kk) Akteneinsicht, § 111 GWB . . . . . . . . . . . . . . . . . . 332 ll) Begründetheit des Nachprüfungsantrags . . . . . . . . 335 mm) Entscheidung, §§ 113, 114 GWB und dessen Bindungswirkung gem. § 124 GWB . . . . . . . . . . . . . 336 b) Primärrechtsschutz vor dem OLG: Sofortige Beschwerde gemäß § 116 GWB . . . . . . . . . . 344 aa) Zulässigkeit, Zuständigkeit . . . . . . . . . . . . . . . . . 344 bb) Frist, Form . . . . . . . . . . . . . 345 cc) Wirkung der sofortigen Beschwerde . . . . . . . . . . . . 347 dd) Beschwerdeentscheidung . . . . . . . . . . . . . . . . . . . 348 c) Sekundärrechtsschutz: Schadensersatz gem. § 126 GWB . . . . . . . . . . . . . . . . 349 3. Rechtsschutz der Bieter unterhalb der Schwellenwerte . . . . . . 353 a) Ausgangslage . . . . . . . . . . . . . . 353 b) Einstweiliger Rechtsschutz vor den Zivilgerichten . . . . . . 354 c) Ausblick . . . . . . . . . . . . . . . . . . 355

VI. Beendigung eines Vergabeverfahrens durch Aufhebung . . . . . 264 1. Einleitung . . . . . . . . . . . . . . . . . . . 264 2. Voraussetzungen der Aufhebung eines Vergabeverfahrens . . . . . . . . . . . . . . . . . . . 265 a) Einleitung. . . . . . . . . . . . . . . . . 265 b) Voraussetzungen einer Vollaufhebung . . . . . . . . . . . . . 267 aa) Kein ordnungsgemäßes Angebot . . . . . . . . . . . . . . . 270 bb) Wesentliche Änderung der Ausschreibungsgrundlagen . . . . . . . . . . . . . 271 cc) Kein wirtschaftliches Ergebnis der Ausschreibung . . . . . . . . . . . . . . . . . . 274 dd) Bestehen anderer schwerwiegender Gründe . . . . . . . . . . . . . . . . 275 c) Folgen einer Aufhebung . . . . 276 d) Schadensersatzansprüche . . . 278 aa) Berechtigte Aufhebung . . 278 bb) Unberechtigte Aufhebung . . . . . . . . . . . . . . . . 279 VII. Rechte der Bieter im Vergabeverfahren . . . . . . . . . . . . 282 1. Überblick . . . . . . . . . . . . . . . . . . . 282 a) Historische Entwicklung . . . 282 b) Bestehende Möglichkeiten zur Geltendmachung von Bieterrechten . . . . . . . . . . . . . . 285 2. Rechtsschutz der Bieter oberhalb der Schwellenwerte . . . . . . 287

Bischof

1141

N Rz. 1

Einzelprobleme

I. Überblick über die rechtlichen Grundlagen des Vergaberechts 1. Einschlägige Vorschriften a) Einführung 1

2

Das Vergaberecht1, das sowohl das Vergabeverfahren als auch die dazugehörigen Vertragsbedingungen umfasst, ist nicht einheitlich in einem Gesetz, sondern in einer Vielzahl unterschiedlicher Normen auf unterschiedlichen Ebenen geregelt. Zur Feststellung der einschlägigen Normen muss zwischen den Ober- und Unterschwellenvergaben unterschieden werden, was sich nach dem so genannten Schwellenwert richtet (s. hierzu nachfolgend unter Rz. 56). Die zu beachtenden Rechtsgrundlagen für Oberschwellenvergaben sind: – Europäisches Primärrecht, v.a. – Vorschriften über die Marktfreiheiten, Art. 28, 43, 49 EGV – Diskriminierungsverbot, Art. 12 EGV – Freier Warenverkehr, Art. 28 EGV – Freier Dienstleistungsverkehr, Art. 43, 49 EGV – Arbeitnehmerfreizügigkeit, Art. 39 EGV – Kapitalverkehrsfreiheit, Art. 56 EGV – EU-Richtlinien im Europäischen Gemeinschaftsrecht als Europäisches Sekundärrecht – die Regelungen der §§ 97 ff. GWB (4. Teil des GWB)2 – die Vergabeverordnung (VgV3), die Vergabeverordnung Verteidigung und Sicherheit (VSVgV)4 sowie die Sektorenverordnung (SektVO5) in der jeweils gültigen Fassung,

1 Vergaberecht wird vom BVerfG wie folgt definiert: „Gesamtheit der Normen, die ein Träger öffentlicher Verwaltung bei der Beschaffung von sachlichen Mitteln und Leistungen, die er zur Erfüllung von Verwaltungsaufgaben benötigt, zu beachten hat.“ (BVerfG v. 13.6.2006 – 1 BvR 1160/03 – NJW 2006, 3701). 2 Gesetz gegen Wettbewerbsbeschränkungen (GWB) in der Fassung der Bekanntmachung vom 15.7.2005 (BGBl. I S. 2114), zuletzt geändert durch Artikel 1 des Gesetzes v. 20.4.2009 (BGBl. I S. 790) samt Berichtigung v. 9.7.2009, BGBl. I S. 1795 (v. 15.7.2009). 3 Verordnung über die Vergabe öffentlicher Aufträge v. 11.2.2003, BGBl. I S. 168; geändert durch Artikel 2 des Gesetzes v. 20.4.2009 (BGBl. I S. 790); geändert durch Artikel 1 der Verordnung zur Anpassung der Verordnung über die Vergabe öffentlicher Aufträge (Vergabeverordnung – VgV). 4 Vergabeverordnung Verteidigung und Sicherheit vom 12. Juli 2012 (BGBl. I S 1509). 5 Verordnung über die Vergabe von Aufträgen im Bereich des Verkehrs, der Trinkwasserversorgung und der Energieversorgung (Sektorenverordnung – SektVO) v. 7.6.2010 (BGBl. I S. 724); zuletzt geändert durch Artikel 1 der Verordnung v. 9.5.2011, BGBl. I S. 800.

1142

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 6

N

– die Vergabe- und Vertragsordnung für Bauleistungen (VOB/A), für freiberufliche Leistungen (VOF) und für sonstige Leistungen (VOL/A)1 Die Vorschriften sind in der dargestellten Reihenfolge zu beachten (Kaskadenprinzip). Die zu beachtenden Rechtsgrundlagen unterhalb der Schwellenwerte sind:

3

– Haushaltsrecht, §§ 7 HGrG, 7 BHO, 55 LHO, 29 ff. GemHVO – VOB/A, Abschnitt 1 – VOL/A, Abschnitt 1 Die Regelungen der §§ 97 ff. GWB und der VgV, VSVgV sowie SektVO sind auf nationaler Ebene nicht anwendbar. Zu beachten sind die teils vorhandenen Landesvergabegesetze2 sowie – soweit vorhanden – Erlasse und Verordnungen innerhalb der einzelnen Länder. Maßgeblich für die vertragliche Gestaltung sind VOL/B sowie die EVB-IT bzw. deren Vorläufer, die BVB.

4

b) EU-Richtlinien und deren Umsetzung aa) EU-Richtlinien Beginnend im Jahr 1971 erfassen die materiellen Vergaberichtlinien der EU 5 sämtliche Bau-, Liefer- und Dienstleistungen oberhalb bestimmter Schwellenwerte3, die von der öffentlichen Hand in Auftrag gegeben werden. Diese wurden sodann ergänzt durch Rechtsmittelrichtlinien, die die prozessualen Mindestanforderungen für Nachprüfungsverfahren bei Beschwerden von Bietern regeln und somit die in den materiellen Vergaberichtlinien festgelegten Rechtspositionen der Bieter und damit Verpflichtungen der öffentlichen Hand stärken. Es lagen folgende EU-Richtlinien vor, die in der Bundesrepublik Deutschland in nationales Recht umgesetzt wurden: – – – –

Liefer-Koordinierungs-Richtlinie (RL 93/36/EWG – LKR) Bau-Koordinierungs-Richtlinie (RL 93/37/EWG – BKR) Dienstleistungs-Richtlinie (RL 92/50/EWG – LKR) dazugehörig die Rechtsmittel-Richtlinie (RL 89/665/EWG)

1 S. zur Einführung in die Vergabe von IT-Leistungen Grützmacher, ITRB 2002, 236 ff.; Kulartz/Steding, IT-Leistungen, Fehlerfreie Ausschreibungen und rechtssichere Vertragsinhalte, 2002. 2 S. Überblick bei Wieddekind, in: Willenbruch/Wieddekind, Kompaktkommentar Vergaberecht. 3 S. hierzu Rz. 56 ff.

Bischof

1143

6

N Rz. 7

Einzelprobleme

– Sektoren-Richtlinie zu Liefer-, Bau- und Dienstleistungen im Bereich der Wasser-, Energie-, Verkehrsversorgung (RL 93/38/EWG) – dazugehörig die Rechtsmittel-Richtlinie Sektoren (RL 92/13/EWG) 7

Im Rahmen des sog. Legislativpakets der Europäischen Kommission zur Vereinfachung, Modernisierung und Flexibilisierung der vier materiellen EU-Vergaberichtlinien verabschiedeten das Europäische Parlament und der Rat am 31.3.2004 die Richtlinien 2004/17/EG (VKR, „klassische Richtlinie“, betrifft die klassischen öffentlichen Auftraggeber) und 2004/18/EG (SKR; betrifft die Auftraggeber im Bereich Wasser-, Energie- und Verkehrsversorgung sowie der Postdienste)1, die das europäische Vergaberecht vereinheitlichen und modernisieren sollten2. bb) Umsetzung der EU-Richtlinien

8

Die EU-Richtlinien 2004 waren bis zum 31.1.2006 in nationales Recht umzusetzen, was jedoch größtenteils nicht fristgerecht gelang. Zwischenzeitlich erfolgte die Umsetzung in deutsches Recht weitgehend (zuletzt mit der Reform 2009), wenn auch nicht fristgerecht3.

9

Eine kurzfristige Änderung ergab sich aufgrund einer Gesetzesinitiative der Regierungsfraktionen bereits Mitte 2005. Mit dem am 7.9.2005 veröffentlichten „Gesetz zur Beschleunigung der Umsetzung von Öffentlichen Privaten Partnerschaften und zur Verbesserung der Rahmenbedingungen für Öffentlich Private Partnerschaften“ (ÖPP-Beschleunigungsgesetz)4 traten bereits folgende wesentliche Änderungen in Kraft: – Zulassung eines „wettbewerblichen Dialogs“ als neues Verfahren bei besonders komplexen Aufträgen in § 101 Abs. 1 und 5 GWB sowie § 6a VgV5 – Beibehaltung des Vorrangs des offenen Verfahrens für „klassische“ Auftraggeber; freie Wahl für Sektorenauftraggeber in § 101 Abs. 6 GWB – Klarstellung bei „gemischten Aufträgen“ hinsichtlich der anzuwendenden Vorschriften: § 99 Abs. 6 GWB bestätigt die bisher bereits angewandte Schwerpunkttheorie6. 1 ABl. EU Nr. L 134 S. 1 f., S. 114 ff. 2 S. zur geplanten Reform auch der Rechtsmittelrichtlinien: Prieß/Gabriel, VergabeR 2005, 707 ff. Für die Änderung der Rechtsmittel-Richtlinien liegt bereits ein Entwurf vor. (Vorschlag für eine Richtlinie des Europäischen Parlaments und des Rates zur Änderung der Richtlinien 89/665/EWG und 92/13/EWG des Rates zwecks Verbesserung der Wirksamkeit der Nachprüfungsverfahren im Bereich des öffentlichen Auftragswesens [SEC0[06]557]). 3 S. zur unmittelbaren Anwendbarkeit v. allem Bischof/Stoye, MMR 2006, 138; Müller-Wrede, VergabeR 2005, 693, 695 ff.; Rundschreiben des BMWI v. 26.1.2006, abrufbar unter www.bmwi.de unter Wirtschaft – Wirtschaftspolitik – öffentliche Aufträge; s.a. Bischof, in: Auer-Reinsdorff/Conrad, Beck’sches Mandatshandbuch IT-Recht, § 30 Rz. 25 ff. m.w.N. 4 BGBl. I 2005, S. 2676 ff. v. 7.9.2005. 5 S. zum wettbewerblichen Dialog Rz. 105 ff. 6 S. zur „Schwerpunkttheorie“ Rz. 74 f.

1144

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 11b

N

– Zulassung des Generalübernehmers in §§ 4, 6 VgV. Es besteht keine Forderung nach einem Mindestmaß an Eigenleistung, so dass der Bieter bei der Erfüllung der Leistungen sich der Fähigkeiten anderer Unternehmer bedienen kann. – Ausschluss von „Projektanten“ in §§ 4, 6 VgV nur bei Wettbewerbsverfälschung durch Informationsvorsprung (Einzelfallprüfung)1. Zielsetzung des Gesetzes war es, der öffentlichen Hand die Gründung und 10 die Tätigkeit von Öffentlich Privaten Partnerschaften (ÖPP) zu erleichtern, und es veränderte zu diesem Zweck den rechtlichen Rahmen für Private Public Partnerships (PPP’s) in wesentlichen Bereichen2. Die Einführung des wettbewerblichen Dialogs als neue Verfahrensart neben offenem, nichtoffenen und Verhandlungsverfahren nahm insoweit auch bereits Vorgaben der EU-Richtlinie vorweg3. Im Folgenden wurden zur Umsetzung der EU-Richtlinien in mehreren Re- 11 formschritten seit 2006 die Vergabe- und Vertragsordnungen neu gefasst, jeweils auch die Vergabeverordnung sowie am 20.4.2009 das Gesetz zur Modernisierung des Vergaberechts4 veröffentlicht mit der Zielsetzung der Vereinfachung und Vereinheitlichung des Vergaberechts. Für Sektorenauftraggeber trat zudem neu am 29.9.2009 die Sektorenverordnung in Kraft, die abschließend die Vergabe der sog. Sektorenauftraggeber (im Bereich Verkehr, Trinkwasser und Energieversorgung) regelt. Zum 12.7.2012 trat zudem die Vergabeverordnung Verteidigung und Sicherheit für diesen Bereich in Kraft. cc) Ausblick Auf EU-Ebene bleibt das Vergaberecht im Hinblick auf Modernisierungsüberlegungen weiterhin in Bewegung. Die EU-Kommission hatte ein Grünbuch5 über die Modernisierung der europäischen Politik im Bereich des öffentlichen Auftragswesens – Wege zu einem effizienten europäischen Markt für öffentliche Aufträge veröffentlicht und hierzu umfangreiche Konsultationen durchgeführt.

11a

Am 20. Dezember 2011 hat die Kommission ihre Vorschläge für zwei neue Richtlinien veröffentlicht:

11b

– Richtlinie für Vergaben klassischer öffentlicher Auftraggeber (ersetzt die geltende Richtlinie 2004/18/EG) sowie – Richtlinie für Vergaben von Sektorenauftraggebern in den Bereichen Energie, Wasser und Verkehr (ersetzt die geltende Richtlinie 2004/17/EG)

1 S. hierzu Bischof/Stoye, MMR 2006, 138. 2 S. zur Auslagerung von IT-Leistungen auf Publik Private Partnerships: Lensdorf/ Steger, CR 2005, 161 ff. 3 S. zum Ablauf Rz. 105 ff. 4 BGBl. I 2009, 790 ff. 5 Grünbuch der EU-Kommission KOM(2011) 15 vom 27.1.2011.

Bischof

1145

N Rz. 11c 11c

Einzelprobleme

Zu beiden Richtlinien sind Kompromisstexte entstanden (Stand 30.11.2012 [16725/1/12] zur klassischen Richtlinie sowie Stand 20.12.2012 [18011/12] zur Sektorenrichtlinie). Neu ist zudem ein Vorschlag für eine neue Richtlinie über die Konzessionsvergabe entstanden (Stand 20.12.2012, 18007/12). Die Kompromisstexte stellen in Form von Arbeitspapieren den vorläufigen Stand der Verhandlungen im Rat der Europäischen Union dar. Sie sind rechtlich unverbindlich und werden als Grundlage für die informellen Verhandlungen mit den andern EU-Institutionen verwendet. Hierzu liegen bereits diverse Stellungnahmen, so u.a. vom Deutschen Anwaltverein sowie der Bundesvereinigung der kommunalen Spitzenverbände vor1.

11d Am 25.6.2013 haben sich der Rat der Europäischen Union und das Europäische Parlament unter Begleitung der Europäischen Kommission im sog. Trialog-Verfahren auf eine Endfassung der Richtlinienvorschläge für die Vergabe von öffentlichen Aufträgen durch klassische öffentliche Auftraggeber und durch Sektorenauftraggeber sowie für die Vergabe von Konzessionsverträgen geeinigt. Zur endgültigen Verabschiedung der Richtlinien sind nun noch die formale Zustimmung des Rates der EU, die wohl zügig erfolgen soll, und eine entsprechende Plenarabstimmung im Europäischen Parlament erforderlich, die voraussichtlich im Oktober 2013 stattfinden wird. Mit ihrem Inkrafttreten werden die beiden neu gefassten Vergaberichtlinien an die Stelle der bisherigen Richtlinien aus dem Jahre 2004 (RL 2004/18/EG und 2004/17/EG) treten. Die Konzessionsrichtlinie wird dann erstmals auf EU-Ebene gesetzlich die Vergabe von Dienstleistungskonzessionen regeln. Sie gilt auch für Konzessionen im Bereich der Bau- und Lieferleistungen. c) Vorschriften des 4. Teils des GWB 12 Der 4. Teil des GWB, eingeführt durch das zum 1.1.1999 in Kraft getretene Vergaberechtsänderungsgesetz2, regelt in drei Abschnitten folgendes: – Grundsätze des Vergabeverfahrens in §§ 97–101 GWB (1. Abschnitt)3 – Vorschriften zum Nachprüfungsverfahren in §§ 102–124 GWB (2. Abschnitt)4 – Regelungen über Rechtsmissbrauch, Schadensersatz, Ermächtigungsgrundlagen und Kosten in §§ 125–129 GWB (3. Abschnitt)5

1 Die Entwicklung gilt es zu beobachten; ein aktueller Überblick findet sich unter http://www.forum-vergabe.de/vergaberechtliche-informationen/modernisierungdes-vergaberechts/. 2 Gesetz v. 28.8.1998, BGBl. I S. 2512. 3 Vgl. hierzu nachfolgende Ausführungen zu den Grundprinzipien des Vergaberechts in Rz. 17 ff. 4 S. hierzu Ausführungen in Rz. 287 ff. 5 S. hierzu Ausführungen in Rz. 349 ff.

1146

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 14

N

Nachdem §§ 97–101 GWB nur die Grundzüge des Vergabeverfahrens, nicht aber dessen Einzelheiten regeln, mussten diese kraft der in § 97 Abs. 6 GWB erteilten Ermächtigung im Verordnungswege geregelt werden. d) Vergabeverordnung und Sektorenverordnung Auf Basis der Ermächtigung in § 97 Abs. 6 GWB wurde die Vergabeverord- 13 nung (VgV) erlassen, die regelmäßigen Änderungen unterworfen ist1. Im Jahre 2010 wurde die VgV weiter entschlackt (nur noch 10 Paragraphen) und insbesondere die neue Sektorenverordnung erlassen2. Zum 12.5.2011 wurde die VgV3 in neuer Fassung bekannt gemacht, vorrangig v.a. um die Richtlinie 2009/33/EG des Europäischen Parlaments und des Rates vom 23.4.2009 über die Förderung sauberer und energieeffizienter Straßenfahrzeuge umzusetzen. Mit Neufassung in 2011 sind zudem drei Anlagen hinzugekommen. Anlage 1 und 2 wurden aus VOL/A und VOF entnommen. Anlage 3 ist neu und bezieht sich auf Straßenverkehrsfahrzeuge. Für Sektorenauftraggeber trat zum 23.92009 die SektVO in Kraft. Die VgV war damit jedoch nicht zur Ruhe gekommen: Der Bundesrat hat 14 am 6.7.2012 der 6. Verordnung zur Änderung der Vergabeverordnung (VgV) sowie dem Verordnungsentwurf der neuen VSVgV (Vergabeverordnung für die Bereich Verteidigung und Sicherheit) ohne Änderungen zugestimmt. Ebenso hat der Bundesrat auch dem Entwurf der neuen Vergabeverordnung für die Bereiche Verteidigung und Sicherheit, VSVgV (BR-Drucks. 321/12), ohne Änderungen zugestimmt. Die neue VSVgV ist Teil der Umsetzung der EU-Richtlinie zu Vergaben in den Bereichen Sicherheit und Verteidigung (2009/81/EG). Während durch Änderungen im GWB der Anwendungsbereich des neuen Sicherheitsvergaberechts festgelegt wird, enthält die VSVgV die entsprechenden Verfahrensregeln. Die neue Vergabeverordnung für die Bereiche Verteidigung und Sicherheit (VS-VgV) und die geänderte VgV wur-

1 VgV 2006 in der Fassung der Bekanntmachung v. 11.2.2003, BGBl. I. S. 169; zuletzt geändert durch die 3. Verordnung zur Änderung der Vergabeverordnung v. 23.10.2006, BGBl. I v. 26.10.2006, S. 2334, in Kraft getreten zum 1.11.2006. Dann VgV 2009 in der Fassung v. 11.2.2003, BGBl. I. S. 169; geändert durch Artikel 2 des Gesetzes v. 20.4.2009 (BGBl. I S. 790), veröffentlicht am 23.4.2009. 2 In der VgV 2010 wurde diese noch weiter entschlackt und beinhaltet seitdem nur noch 10 Paragraphen, da zahlreiche Vorschriften der VgV 2009 aufzuheben waren: Verordnung zur Anpassung der Verordnung über die Vergabe öffentlicher Aufträge (Vergabeverordnung – VgV) sowie der Verordnung über die Vergabe von Aufträgen im Bereich des Verkehrs, der Trinkwasserversorgung und Energieversorgung (SektVO) v. 23.9.2009 (BGBl. I 2009 S. 3110); zuletzt geändert durch Artikel 1 der Verordnung über die Vergabe von Aufträgen im Bereich des Verkehrs, der Trinkwasserversorgung und der Energieversorgung (Sektorenverordnung – SektVO) v. 7.6.2010, BGBl. v. 10.6.2010, S. 724. 3 VgV in der Fassung der Bekanntmachung v. 11.2.2003 (BGBl. I, S. 169), zuletzt geändert durch Artikel 1 der Verordnung v. 9.5.2011, BGBl. I 2011, S. 800.

Bischof

1147

N Rz. 15

Einzelprobleme

den am 18.7.2012 im BGBl. veröffentlicht, so dass die neuen Regelungen seit 19.7.2012 in Kraft sind1. 15 Die VgV dient als eine Art Schnittstelle zwischen dem Gesetz (GWB) und den einzelnen Vergabe- und Vertragsordnungen (vormals Verdingungsordnungen), da auch sie keine Regelungen über die Einzelheiten des Vergabeverfahrens enthält. §§ 4, 5, 6 VgV bestimmen den Anwendungsbereich von VOL/A, VOF und VOB/A. e) Die einzelnen Vergabe- und Vertragsordnungen 16 Die „unterste Stufe“ der Vergabevorschriften stellen die einzelnen Vergabeund Vertragsbedingungen VOB/A, VOL/A und VOF dar. Diese enthalten die eigentlichen Regelungen über das bei der Vergabe von Aufträgen einzuhaltende Verfahren und bilden somit den Kern des materiellen Vergaberechts. Oberhalb der EU-Schwellenwerte2 haben die Bestimmungen der Vergabeund Vertragsbedingungen Rechtsnormqualität.

EU-Vergabe Aurag über Schwellenwert

Naonale Vergabe Aurag unter Schwellenwert

EU-Richtlinien Haushaltsrecht (§ 55 BHO/LHO mit Ziff. 2.1.7 VV

VS VgV

§§ 97 ff. GWB Vergabeverordnung (VgV)

VOB Schwellenwert bei IT-Leistungen (geschätzter Auragswert) 200°000 Euro (ohne USt)

(nur Abschni 1)

VOF

SektVO

VOL VOL/A

VOL/B

EVB-IT

2. Grundprinzipien des Vergaberechts 17 Die wesentlichen im Vergaberecht – unabhängig vom anwendbaren Vergabeverfahren – zu berücksichtigenden Säulen und damit die Grundprinzipien des Vergaberechts bestimmt § 97 Abs. 1 bis 4, 5 GWB wie folgt, wobei die erstgenannten drei Prinzipien im Europarecht verankert sind: – Wettbewerbsgrundsatz: Vergabe im fairen Wettbewerb – Transparenzgebot – Nichtdiskriminierungs-/Gleichbehandlungsgrundsatz 1 BGBl. I Nr. 33 S. 1508. 2 S. hierzu Rz. 56 ff.

1148

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 19

N

– Prinzip der Wirtschaftlichkeit – Vergabe an geeignete Unternehmen1. Diese Grundsätze sind in allen Verfahrensarten und in allen Verfahrensstadien zu beachten. Bei Unterschwellenvergaben sind diese Grundsätze ebenfalls zu beachten. Sie werden aus Verfassungsrecht und aus europäischem Primärrecht (vgl. die Grundfreiheiten des EG-Vertrags) hergeleitet. Die Verletzung dieser Prinzipien durch einen öffentlichen Auftraggeber 18 kann – bei Oberschwellenvergaben – von den Bietern gerügt und zum Gegenstand eines Nachprüfungsverfahrens2 gemacht werden, da die Bieter gem. § 97 Abs. 7 GWB einen Anspruch auf Einhaltung der Bestimmungen über das Vergabeverfahren durch den öffentlichen Auftraggeber haben. Die öffentliche Hand ist daher gehalten, im gesamten Vergabeverfahren auf die Einhaltung dieser Prinzipien ihr besonderes Augenmerk zu richten. a) Wettbewerbsgrundsatz Der Wettbewerbsgrundsatz3 soll der Durchsetzung der europäischen Grund- 19 freiheiten, wie Waren-, Dienstleistungs- und Niederlassungsfreiheit, dienen. Er verlangt, in einem möglichst formalisierten Verfahren möglichst vielen Bietern die Gelegenheit zu geben, ihre Leistung anzubieten. Der öffentliche Auftraggeber ist gehalten, Leistungen grundsätzlich im Wettbewerb zu vergeben. Er ist verpflichtet, wettbewerbsbeschränkende und unlautere Verhaltensweisen zu bekämpfen. Dies resultiert im Wesentlichen aus dem EU-Gemeinschaftsrecht, das einen funktionierenden EG-Binnenmarkt fordert. Daher müssen Interessenten aus allen Mitgliedsstaaten der EU gleichberechtigten Zugang zu öffentlichen Aufträgen in allen Mitgliedsstaaten erhalten. Als wesentliche Ausprägungen des Wettbewerbsgrundsatzes lassen sich z.B. auch das Festhalten am Vorrang des offenen Verfahrens vor anderen Verfahrensarten, das Verbot der parallelen Beteiligung zweier Unternehmen mit identischer Geschäftsführung oder die parallele Beteiligung als Einzelbewerber und Mitglied einer Bietergemeinschaft in einem Vergabeverfahren feststellen. Auch die Einhaltung von Geheimhaltungsvorschriften stellt eine Voraussetzung für die Wahrung des Wettbewerbsgrundsatzes dar. Wettbewerbsbeschränkende Absprachen und wettbewerbswidrige Verhaltensweisen (vgl. insbesondere § 1 GWB, §§ 3, 8 UWG) werden mit dem Aus-

1 Vgl. hierzu Müller-Wrede, VOL/A Kommentar 2001, Einleitung Rz. 10 ff.; Eberstein, in: Daub/Eberstein, VOL/A Kommentar, Einführung, Rz. 64; UfAB V Version 2.0; s. auch Noch, Vergaberecht kompakt, Verfahrensablauf und Entscheidungspraxis, S. 13 ff. 2 S. hierzu Rz. 287 ff. 3 S. Dreher, in: Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 17 ff.

Bischof

1149

N Rz. 20

Einzelprobleme

schluss aus dem Vergabeverfahren sanktioniert (s. u.a. § 19 EG Abs. 3f VOL/A)1. b) Gleichbehandlungsgrundsatz 20 Der Gleichbehandlungsgrundsatz2 verbietet die Diskriminierung von Unternehmen bei der Auftragsvergabe. Alle Bieter sind gleich zu behandeln bzw. nicht ohne sachlichen Grund unterschiedlich zu behandeln. Gem. § 97 Abs. 2 Hs. 2 GWB ist eine Ungleichbehandlung nur zulässig, wenn dies aufgrund des GWB geboten oder gestattet ist. Dieser Grundsatz prägt das Vergabeverfahren in vielerlei Hinsicht, so z.B. dass inländische Bieter keinen Wissensvorsprung vor ausländischen Bietern erhalten dürfen (z.B. durch frühere Veröffentlichungen), ortsansässige Bieter gegenüber nicht ortsansässigen Bietern nicht bevorzugt werden dürfen oder alle Bieter im laufenden Vergabeverfahren stets die gleichen Informationen erhalten müssen3. Alle Bieter müssen die gleichen Chancen auf den Zuschlag haben, daher müssen für alle beteiligten Unternehmen auch die gleichen Voraussetzungen gelten. So muss z.B. der Auftraggeber aufgestellte Fristen zugunsten und zu Lasten aller Bieter einhalten, kein Bieter darf einseitig bevorzugt werden. Der Gleichbehandlungsgrundsatz erfasst sowohl sämtliche Handlungen des Auftraggebers im laufenden Vergabeverfahren als auch zeitlich vorgelagerte Entscheidungen, die Auswirkungen auf das Vergabeverfahren haben. So sind insbesondere die Bekanntmachung, die Leistungsbeschreibung, die Auswahl von Unternehmen für die Angebotsabgabe beim nichtoffenen Verfahren und Verhandlungsverfahren sowie auch eine Aufhebungsentscheidung am Gleichbehandlungsgrundsatz zu messen. 21 Ob ein Verstoß gegen den Gleichbehandlungsgrundsatz vorliegt, muss in jedem Einzelfall festgestellt werden. Die Darlegungs- und Beweislast trägt derjenige, der sich auf das Gleichbehandlungsgebot beruft, in aller Regel also das Unternehmen, das eine Diskriminierung behauptet4. c) Transparenzgrundsatz 22 Der Transparenzgrundsatz wird europarechtlich aus den Grundfreiheiten und verfassungsrechtlich als „Vorhersehbarkeit, Messbarkeit und Transparenz staatlichen Handelns“ aus dem Rechtsstaatsprinzip (Art. 20 Abs. 3

1 S. u.a. Diehl, in: Müller-Wrede, GWB-Vergaberecht, Kommentar, § 97 Rz. 4 ff. 2 S. Dreher, in: Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 44 ff. S.a. zur Rechtsprechung Weyand, Vergaberecht, 4. Aufl., § 97 Rz. 383 ff. 3 S. zu gleichbehandlungswidrigen Vergabepraktiken Dreher, in: Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 49–71. 4 S. Müller-Wrede, GWB-Vergaberecht, Kommentar, § 97 Rz. 4 ff.

1150

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 25

N

GG) hergeleitet1 und gilt bei sämtlichen Verfahrensarten, insbesondere dem Verhandlungsverfahren. Das Transparenzgebot2 fordert eine transparente Verfahrensweise, um die 23 Einhaltung von Wettbewerbs- und Gleichbehandlungsgrundsatz zu sichern. Die öffentliche Hand muss daher z.B. nachvollziehbar die einzelnen Verfahrensschritte, insbesondere getroffene Entscheidungen, dokumentieren3. Bieter sollen damit in die Lage versetzt werden, sämtliche Verfahrensstadien nachprüfen zu können (Ex post-Betrachtung). Die Transparenz bezieht sich aber auch auf eine Ex ante-Betrachtung, wonach Bieter schon von Anfang an in die Lage versetzt werden sollen, ihre Chancen bei einer Verfahrensteilnahme zu beurteilen. Dies spiegelt sich z.B. in der vorherigen Bekanntgabe von Zuschlagskriterien (s. § 8 Abs. 1b, § 12 Abs. 2n VOL/A bzw. § 10 EG Abs. 2c VOL/A). Vergabeunterlagen müssen transparent gestaltet sein, die Vergabeentscheidung transparent erfolgen. Von wesentlicher Bedeutung ist auch, dass das gesamte Vergabeverfahren nachvollziehbar in seinen einzelnen Verfahrensschritten zeitnah fortlaufend dokumentiert werden muss (vgl. § 20 bzw. § 24 EG VOL/A)4. d) Berücksichtigung mittelständischer Interessen Weiter bestimmt § 97 Abs. 3 GWB die Berücksichtigung mittelständischer 24 Interessen, im Wesentlichen durch Teilung der Aufträge in Fach- und Teillose5. Fachlose liegen vor, wenn die Gesamtleistung in einzelne Fachgebiete aufgeteilt wird, die sich nach gewerberechtlichen Vorschriften oder sonstigen allgemein üblichen Abgrenzungen ergeben. Bei der Vergabe von ITLeistungen lässt sich oftmals in der Praxis folgende Aufteilung nach Losen finden: ein Los zur Lieferung von Hardware, ggf. noch feiner aufgeteilt in ein Los zur Lieferung der Hardware und ein weiteres Los zur Lieferung von PCs, und ein anderes Los zur Lieferung von Software, meist verbunden mit weiteren Leistungen wie Parametrierung, Anpassung, Schulung, ggf. auch Pflege. Die Bestimmung des § 97 Abs. 3 GWB ist im Rahmen der GWB-Reform stark verändert worden und soll Ausdruck eines besonders mittelstandsfreundlichen Verständnisses sein: Es soll eine Losvergabe stattfinden. Daher kann nur ausnahmsweise von einer Losaufteilung abgesehen werden, wenn nach einer Interessenabwägung, innerhalb derer dem Auftraggeber ein Beurteilungsspielraum zusteht, überwiegende Gründe für eine einheitliche 1 S. BGH, Urt. v. 17.2.1999 – X RZ 101/97, NJW 2000, 137 (139). 2 S. Dreher, in: Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 30 ff. 3 Dies hat z.B. seinen Niederschlag in den Vorschriften des § 30 VOL/A zum Vergabevermerk gefunden. S.a. Weyand, Vergaberecht, 4. Aufl., § 97 GWB, Rz. 226 ff. m.w.N. 4 S. u.a OLG München, Beschl. v. 17.1.2008, Verg 15/07. 5 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, 2003, § 97 GWB Rz. 13; s. auch Dreher, in: Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 73 ff.

Bischof

1151

25

N Rz. 26

Einzelprobleme

Auftragsvergabe sprechen. Was solche überwiegenden Gründe, auch i.S.v. vertretbaren Gründen, sind, ist stets anhand der konkreten Umstände des einzelnen Projekts zu bestimmen. Es sollte sich um qualitative und wirtschaftliche Kriterien handeln. 26 Die Erwägungen zur Losaufteilung bzw. zum Verzicht auf eine solche Losaufteilung unterliegen wiederum der Dokumentationspflicht (als Ausfluss des Transparenzgebots). Der öffentliche Auftraggeber muss also im Rahmen der Vorbereitung seines Vergabeverfahrens ein Absehen von der Losvergabe nachvollziehbar begründen. Pauschale Behauptungen und reine Erfahrungssätze reichen hierzu nicht aus. In aller Regel wird sogar verlangt, dass die Kosten der unterschiedlichen Vorgehensweisen vom öffentlichen Auftraggeber durchgerechnet werden, um so den Verzicht auf Losvergabe aus wirtschaftlichen Gründen/Kostengründen transparent darlegen und nachweisen zu können. Die Rechtsprechung1 stellt hier durchaus hohe Anforderungen an die Qualität einer solchen Begründung. Allein die Behauptung, man benötige „Leistungen aus einer Hand“ reicht hierfür nicht aus, vielmehr bedarf es einer detaillierten und fundierten Betrachtungsweise. 27 Auch ist aus langjähriger Praxis klar, dass die Losaufteilung nicht die einzige Art und Weise der Mittelstandsförderung ist. Es kommen aber auch andere Maßnahmen in Betracht, wie z.B. – Zulassung von Bietergemeinschaften2, – Loslimitierung, d.h. die Festlegung einer Höchstgrenze für die an einen einzelnen Bieter zu vergebenden Lose3, – Vorgaben im Hinblick auf die Erteilung von Unteraufträgen e) Prinzip der Wirtschaftlichkeit, Vergabe an geeignete Unternehmen 28 Zu den wesentlichen Grundsätzen der Vergabe gehört auch, dass die Aufträge unter Berücksichtigung der wirtschaftlichen Leistungsfähigkeit und der fachlichen Eignung (§ 97 Abs. 4 GWB) auf das wirtschaftlichste Angebot (§ 97 Nr. 5 GWB) erteilt werden4. Der öffentliche Auftraggeber muss somit Fachkunde, Leistungsfähigkeit, Gesetzestreue und Zuverlässigkeit der Unternehmen prüfen. Letztlich sind dies unbestimmte Rechtsbegriffe, bei deren Auslegung dem öffentlichen Auftraggeber ein Beurteilungsspielraum zusteht5. 1 S. u.a. OLG Düsseldorf Beschl. v. 8.9.2004 – VII Verg 38/04 – VergabeR 2005, 109; OLG Düsseldorf, Beschl. v. 14.4.2005 – VII Verg 93/04 – VergabeR 2005, 513; VK Rheinland-Pfalz Beschl. v. 30.9.2005 – VK 35/05. 2 S. vertiefend zum Thema Bietergemeinschaften: Ohrtmann, VergabeR 2008, 426. 3 S. zu den Grenzen der Loslimitierung Otting/Tresselt, VergabeR 2009, 585. 4 S. Dreher, in: Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 95 ff., 143 ff. 5 Vgl. Müller-Wrede, GWB-Vergaberecht, Kommentar, § 97 Rz. 34 m.w.N. S. zur Eignungsprüfung im Detail nachfolgend Rz. 210.

1152

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 32

N

II. Ausschreibungspflicht 1. Einleitung Eine Ausschreibungspflicht besteht auf jeden Fall nur, wenn ein öffent- 29 licher Auftraggeber einen öffentlichen Auftrag vergibt. Ob rein nationale oder auf EU-Recht basierende Normen des Vergaberechts anzuwenden sind, wird von den in § 98 GWB und § 2 VgV genannten persönlichen und sachlichen Anwendungskriterien bestimmt. Hieraus ergibt sich eine Zweiteilung des Vergaberechts1:

30

– Kommt rein nationales Vergaberecht zur Anwendung, da die Schwellenwerte unterschritten werden, besteht die gleiche Rechtslage wie vor dem Vergaberechtsänderungsgesetz, d.h. die sog. haushaltsrechtliche Lösung: Das Vergaberecht ist Teil des Haushaltsrechts (§§ 55 BHO, LHO) und schreibt den für den Einkauf zuständigen Stellen ein bestimmtes Verhalten, eine bestimmte Vorgehensweise beim Einkauf zum Schutz der Finanzen vor. Die Vergaberegeln waren somit lediglich objektive Ordnungsregeln, deren rechtlicher Gehalt allenfalls eine Reflexwirkung auf potentielle Vertragspartner haben konnte. Die Vergabe- und Vertragsordnungen sind weder Gesetz noch Rechtsverordnung, sondern nur eine interne Verhaltensregel, die in erster Linie eine gleichmäßige Behandlung der Beschaffungsvorgänge, die Wahrung des freien Wettbewerbs sowie eine Auswahl des wirtschaftlichsten Angebots sicherstellen soll. Ein Nachprüfungsverfahren nach §§ 102 ff. GWB ist nicht möglich. – Kommt EU-Vergaberecht zur Anwendung, sind die Vergabe- und Vertragsordnungen durch die Verweisungen in der VgV nicht mehr Verwaltungsvorschriften, sondern haben Rechtsverordnungscharakter. Verstöße gegen vergaberechtliche Bestimmungen (§ 97 Abs. 7 GWB) können gerügt werden und Gegenstand von Nachprüfungsverfahren gem. §§ 102 ff. GWB sein. 2. Öffentlicher Auftraggeber, § 98 GWB Die persönlichen Voraussetzungen ergeben sich aus § 98 GWB. Nur öffent- 31 liche Auftraggeber i.S.v. § 98 GWB haben die Vorschriften des Vergaberechts zu beachten. Hierbei ist zu beachten, dass § 98 GWB den Begriff des öffentlichen Auftrag- 32 gebers funktional und nicht wie im klassischen Sinne institutionell bestimmt. Entscheidend ist demnach allein, ob die auf dem Markt auftretende Einheit staatliche Funktionen wahrnimmt oder nicht. § 98 GWB ersetzt § 57a Abs. 1 HGrG, wobei es keine inhaltlichen Unterschiede gibt, und

1 Vgl. Müller-Wrede, VOL/A Kommentar 2001, Einleitung Rz. 22, 41–43.

Bischof

1153

N Rz. 33

Einzelprobleme

sieht in seinen Nr. 1 bis 6 einen Katalog von öffentlichen Auftraggebern vor. Diese sind demnach1: a) Gebietskörperschaften und deren Sondervermögen (§ 98 Nr. 1 GWB): Bund, Länder und Kommunen b) Andere juristische Personen des öffentlichen und des privaten Rechts, die zu dem besonderen Zweck gegründet wurden, im Allgemeininteresse liegende Aufgaben nichtgewerblicher Art zu erfüllen, wenn Gebietskörperschaften sie überwiegend finanzieren oder über ihre Leitung die Aufsicht ausüben, sowie die Verbände dieser juristischen Personen (§ 98 Nr. 2 und Nr. 3 GWB). Diese Abgrenzung ist nicht immer einfach, vor allem, da immer mehr öffentliche Aufgaben in der Form des Privatrechts ausgeführt werden und die öffentliche Hand zunehmend über Tochtergesellschaften selbst am Wettbewerb teilnimmt. Bei eindeutiger Gewinnerzielungsabsicht würde man zwar regelmäßig die Tätigkeit im Allgemeininteresse ablehnen. Nach der Rechtsprechung des EuGH2 kommt es jedoch primär auf den Gründungszweck an, selbst wenn dann tatsächlich gewerbliche Zwecke verfolgt werden, so dass das Vergaberecht umfassend anzuwenden ist. Häufig wird in der Praxis übersehen, dass öffentliche Auftraggeber auch staatlich beherrschte, öffentliche Aufgaben erfüllende Einrichtungen in der Form des Privatrechts sind. Eine Beherrschung ist immer dann anzunehmen, wenn eine überwiegende Finanzierung durch eine oder mehrere Gebietskörperschaften vorliegt (Vermutung bei einer Kapitalbeteiligung von mehr als 50 %). Die überwiegende Zahl der Verbände liegt im Kommunalbereich, so etwa Wasserversorgungs-, Abwasser-, Müllbeseitigungs- oder Planungsverbände. c) So genannte Sektoren-Auftraggeber, d.h. natürliche oder juristische Personen des Privatrechts (§ 98 Nr. 4 GWB – Sektorenbereich3), die im Bereich Trinkwasser- und Energieversorgung, Personenverkehr und Fernmeldeverkehr tätigt sind. Allerdings wird das Fernmeldewesen aus dem Vergaberecht über § 8 VgV wieder entlassen, da dieses dort nicht mehr aufgeführt wird. d) Subventionierte natürliche oder juristische Personen des Privatrechts (§ 98 Nr. 5 GWB) und sog. Fälle der Baukonzession (§ 98 Nr. 6 GWB). 33 Bei klassischen öffentlichen Auftraggebern, wie z.B. Gebietskörperschaften, ist diese Einordnung unproblematisch. Problematisch wird die Abgrenzung 1 S. Müller-Wrede, VOL/A Kommentar 2001, Einleitung, Rz. 44 ff.; Müller, in: Daub/Eberstein, VOL/A Kommentar 2000, § 1a Rz. 8 ff., Reidt/Stickler/Glahs, Vergaberecht Kommentar 2003, § 98 GWB, s. auch Noch, Vergaberecht kompakt, S. 41 ff. 2 Zum Urteil des EuGH zur „Österreichischen Staatsdruckerei“ s. Riedl, in: Heiermann/Riedl/Rusam, VOB/A, Einl. Rz. 2; Ingenstau/Korbion, VOB/A, Einl. Rz. 18; Boesen, Vergaberecht, Einl. Rz. 141; a.A. Bechtold, Vor § 97 Rz. 18. 3 Die Vergabe von Sektoren-Auftraggebern wird nicht näher betrachtet; es bestehen Sonderregelungen (b-Paragraphen der VOL/A); im Wesentlichen gelten obige Ausführungen entsprechend.

1154

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 35

N

dann, wenn Einrichtungen des privaten Rechts handeln, die in irgendeiner Art und Weise mit dem Staat verbunden sind. Als Hilfestellung zur Bestimmung der Eigenschaft als öffentlicher Auftraggeber kann oftmals die Überlegung dienen, ob eine besondere Staatsnähe gegeben ist, also der Staat irgendwie mit einem besonderen Einfluss, sei es finanzieller oder aufsichtsrechtlicher Art, in Erscheinung trifft. In solchen Fällen ist die Einordnung als öffentlicher Auftraggeber wahrscheinlich1. 3. Öffentlicher Auftrag, § 99 GWB a) Grundsätze Öffentliche Aufträge sind entgeltliche Verträge zwischen öffentlichen Auf- 34 traggebern i.S.d. § 98 GWB und Unternehmen, die Liefer-, Dienst- oder Bauleistungen zum Inhalt haben. Nur wenn der öffentliche Auftraggeber als „Nachfrager“ auftritt, liegt ein solcher öffentlicher Auftrag vor. Weiter ist erforderlich, dass ein „entgeltlicher Vertrag“ geschlossen wird, der öffentliche Auftraggeber also eine Gegenleistung erbringen muss2. Nach wohl überwiegender Rechtsprechung ist der Begriff der Entgeltlichkeit weit auszulegen. Es ist jeder geldwerte Vorteil erfasst, auch wenn nicht Geldmittel zur Verfügung gestellt werden3. Bei der Beschaffung von Open Source Software (OSS) ist die Entgeltlichkeit 35 allerdings fraglich. Überwiegend darf für die OSS-Software selbst kein Entgelt verlangt werden. Allerdings ist mit der Nutzung von OSS-Produkten in aller Regel mehr verbunden, so z.T. Anpassungsleistungen, Pflege, Support. Diese Folgekosten müssen somit berücksichtigt werden. Je nach OSS-Produkt kann die Entgeltlichkeit bereits mit der Beschaffung der OSS-Komponente verbunden sein, wenn z.B. auch sogleich Pflege und Support nachgefragt werden, wofür die meisten OSS-Lizenzmodelle auch Vergütungsmöglichkeiten vorsehen. Selbst wenn der tatsächliche Erwerb von OSS unentgeltlich sein sollte (und damit vergaberechtsfrei), fallen die damit verbundenen Tätigkeiten wiederum unter den Betriff des entgeltlichen Vertrags4.

1 S. u.a. Willenbruch/Wieddekind, in; Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 26; Müller-Wrede, GWB-Vergaberecht, Kommentar, § 98 GWB. 2 S. EuGH „Stadt 5.land“, VergabeR 2001, 380 = NZBau 2001, 512. 3 S. OLG Naumburg NZBau 2006, 58; BayObLG, VergabeR 2003, 329; OLG Düsseldorf v. 22.9.2004 – VII Verg 44/04, NZBau 2005, 652; OLG Düsseldorf v. 8.9.2004 – VII Verg 35/04 und OLGR 2004, 301; EuGH „Stadt Mailand“, VergabeR 2001, 380; EuGH „Heizkraftwerk München“, VergabeR 2005, 57. 4 Vgl. S. Heckmann, CR 2004, 401; Müller/Gerlach, CR 2005, 87, 88; Willenburch/ Wieddekind, in: Leupold/Glossner, Münchener Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 156 f.

Bischof

1155

N Rz. 36

Einzelprobleme

b) Ausnahmetatbestand „Inhouse-Geschäft“ 36 § 99 Abs. 1 GWB erfordert einen Vertrag zwischen öffentlichen Auftraggebern und Unternehmen. Der Begriff des Unternehmens bezeichnet einen Rechtsträger, gleich welcher Rechtsform, der sich wirtschaftlich betätigt. Der Unternehmensbegriff ist weit auszulegen. Es kann sich um natürliche oder juristische Personen handeln, die selbst Arbeiten ausführen, aber auch um ein solches Unternehmen, das auf fremde Fachkräfte oder fachliche Einrichtungen zurückgreift oder auch einer Gruppe von Unternehmen, gleicher Rechtsform. 37 Bei rechtlicher Verschiedenheit von Auftraggeber und Auftragnehmer ist dies unproblematisch. Vergaberechtlich sind jedoch solche Leistungen nicht erfasst, die von der öffentlichen Hand unmittelbar im Regie- oder Eigenbetrieb1 erbracht werden („echte“ Inhouse-Geschäfte)2. Hierbei handelt es sich regelmäßig um unselbständige Verwaltungseinheiten ohne eigene Rechtspersönlichkeit; sie sind daher mit dem öffentlichen Auftraggeber rechtlich identisch; die Aufgabenübertragung verlässt nicht den Bereich des öffentlichen Sektors. Die Gründung solcher Regie- und Eigenbetriebe, z.B. zum Betrieb eines Rechenzentrums für eine größere Behörde, ist vergaberechtlich unbeachtlich. 38 Problematischer ist die Situation aber, wenn der Auftrag an eine eigenständige juristische Person vergeben wird, die vom öffentlichen Auftraggeber nicht vollständig „beherrscht“ wird („unechte Inhouse-Geschäfte“). Der EuGH3 hat die vergaberechtliche Unbeachtlichkeit anerkannt, wenn trotz unterschiedlicher juristischer Rechtspersönlichkeiten folgende Kriterien kumulativ erfüllt werden: – Wirtschaftliche Identität zwischen Auftraggeber und Auftragnehmer – Gebietskörperschaft übt über diese juristische Person eine Kontrolle aus wie über ihre eigenen Dienststellen – Juristische Person verrichtet ihre Tätigkeit im Wesentlichen für die Gebietskörperschaft oder diejenige, die ihre Anteile innehat. 39 Diese sog. „Teckal-Kriterien“ hat der EuGH mit folgenden Entscheidungen konkretisiert: – „Stadt Halle“4: „Eine Kontrolle wie über eine eigene Dienststelle ist nur dann gegeben, wenn der Auftragnehmer vollständig von der öffentlichen Hand gehalten wird. Schon eine minimale private Beteiligung schließt es aus, dass eine Kontrolle wie über eine eigene Dienststelle angenommen wird.“ 1 Regie- und Eigenbetriebe sind unselbständige Verwaltungseinheiten ohne eigene Rechtspersönlichkeit. 2 S. zu Möglichkeiten und Grenzen Dammert, BauRB 2005, 151. 3 EuGH v. 18.11.1999 (Teckal), Rs. C-107/98, NZBau 2000, 90. 4 EuGH v. 11.1.2005 (Stadt Halle) Rs. C-26/03, VergabeR 2005, 43 ff.; s.a. BauRB 2005, 110 ff. s. auch Lotze, VergabeR 2005, 278.

1156

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 40

N

– „Parking Brixen“1: Nach dieser Entscheidung hält der EuGH eine InHouse-Vergabe auch an ein 100 % öffentliches Unternehmen für nicht möglich, wenn das Unternehmen eine „Marktausrichtung“ erreicht hat, die eine Kontrolle wie über eine eigene Dienststelle nicht erlaubt. Die auftraggebende Stelle muss auf die Entscheidungen des Auftragnehmers einwirken und dabei sowohl die strategischen wie auch die wichtigen operativen Entscheidungen beeinflussen können; nur dann kann von einer Kontrolle des öffentlichen Auftraggebers gesprochen werden, die ein In-House-Geschäft zulässt. – „Carbotermo“2: Der EuGH berücksichtigt bei der Beurteilung der Frage, ob ein Unternehmen seine Tätigkeit im Wesentlichen für die Körperschaft verrichtet, die seine Anteile innehat, alle Tätigkeiten, die dieses Unternehmen auf grund einer Vergabe durch den öffentlichen Auftraggeber verrichtet, unabhängig davon, wer diese Tätigkeit vergütet, sei es der öffentliche Auftraggeber selbst oder der Nutzer der erbrachten Dienstleistungen. Es kommt dabei nicht darauf an, in welchem Gebiet diese Tätigkeit ausgeübt wird. Das kontrollierte Unternehmen muss hauptsächlich für den Auftraggeber tätig sein: jede andere Tätigkeit darf nur rein nebensächlich sein. c) Vertragsänderungen, -verlängerungen Nach Vertragsschluss kann es zu Änderungen/Anpassungen oder Verlänge- 40 rungen3 des Vertrags kommen. Wenn sich der Auftraggeber im Vergabeverfahren Optionsrechte ausbedungen hat, kann bzw. wird er von diesen auch Gebrauch machen. Hierbei ist stets zu prüfen, ob derartige Vorgänge einen öffentlichen Auftrag i.S.d. § 99 Abs. 1 GWB darstellen und somit das Vergaberecht zur Anwendung gebracht werden muss. Nicht jede Vertragsänderung, die in einem bestimmten Umfang nachträglich auch verlangt werden kann (vgl. § 2 VOL/B), und jede Vertragsverlängerung vermag jedoch einen neuen Vergabevorgang zu begründen. Es ist stets eine Einzelfallprüfung mit wertender Betrachtung vorzunehmen, ob die Änderung hinsichtlich ihres Umfangs und ihrer Wirkungen dem Abschluss eines neuen Vertrages gleichsteht. Eine gewisse Erheblichkeit der Änderung muss vorliegen, so die bisherige Spruchpraxis und Literatur4. Diese Abgrenzung ist oftmals in der Praxis schwierig vorzunehmen. 1 2 3 4

EuGH v. 13.10.2005 (C-458/03). EuGH v. 11.5.2006 (C-340/04). S. Kulartz/Duikers, VergabeR 2008, 728. OLG Düsseldorf, Beschl. v. 8.5.2002 – Verg 8–15/01, s. oeffentliche-auftraege.de; OLG Düsseldorf, Beschl. v. 20.6.2001 – Verg 3/01, VergabeR 2001, 329; OLG Düsseldorf, Beschl. v. 14.2.2001 – Verg 13/01, VergabeR 2001, 210: „… Bei so genannten Anpassungen oder Änderungen schon bestehender Vertragsbeziehungen ist daher zu beurteilen, ob die die Anpassung oder Abänderung ausmachenden vertraglichen Regelungen in ihren wirtschaftlichen Auswirkungen bei wertender Gesamtbetrachtung einer neuen Vergabe gleichkommen Dies ist anzunehmen, wenn

Bischof

1157

N Rz. 41

Einzelprobleme

aa) Vertragsverlängerungen 41 In aller Regel ist die Verlängerung eines bestehenden, ggf. befristeten Vertrags1 einem Neuabschluss gleichzusetzen. Nach allgemeiner Auffassung liegt daher ein öffentlicher Auftrag vor, der somit als neuer Beschaffungsvorgang dem Vergaberecht unterliegt. Aber dennoch gibt es Ausnahmen, da nicht jede Vertragsverlängerung dem Neuabschluss gleich steht: – Keine Neuausschreibungspflicht besteht, wenn die Verlängerung in dem zu verlängernden Vertrag bereits vorgesehen und als Vertragsklausel im Rahmen der diesem Vertrag zu Grunde liegenden Ausschreibung bekannt gemacht worden war2. – Entsprechendes gilt auch für Verlängerungsoptionen: Soweit diese vorgesehen waren, stellt ihre Ausübung keinen vergaberechtlich relevanten Vorgang dar. – Sieht ein befristeter Vertrag vor, dass er sich automatisch um einen bestimmten Zeitraum verlängert, wenn er nicht durch einen der Vertragspartner gekündigt wird, handelt es sich bei der Nichtausübung des Kündigungsrechts ebenfalls nicht um einen dem Vergaberecht unterliegenden Vorgang, da die Verlängerung der Laufzeit bei „Nicht-Kündigung“ im bereits ausgeschriebenen Vertrag bereits vorgesehen war. – Allerdings gibt es hiervon wiederum eine Rückausnahme: Ein neuer Vergabevorgang liegt vor, wenn vorgesehen ist, dass dann an Stelle des nicht gekündigten Vertrags ein neuer Vertrag tritt, der noch zu vereinbaren ist. Darin liegt ein neuer vergaberechtlich relevanter Beschaffungsvorgang3. bb) Inhaltliche Vertragsänderungen 42 Inhaltliche Vertragsänderungen können sich auf den Leistungsumfang, die Vergütung oder auch rein rechtliche Bestimmungen beziehen. Auch hier ist als Maßstab wiederum eine wertende Betrachtung vorzunehmen, um festzustellen, ob eine gewisse Erheblichkeit besteht. 43 Ein Änderungsvertrag, wonach ein Auftrag um weitere fünf Jahre verlängert wird und der gleichzeitig den Auftragsgegenstand in erheblicher Weise, z.B. durch die getroffene Vereinbarung der bisherige Vertragsinhalt nicht unerheblich abgeändert wird.“ Hingegen LG Frankfurt/M., Beschl. v. 28.1.2008 – 2-40 201/06, VergabeR 2008, 513, das diese Argumentation für wenig hilfreich hält und auf Wettbewerbsrelevanz abstellt: „Nach Ansicht des Gerichts darf für Vertragsänderungen, deren Gegenstand für den Bieterwettbewerb keine spürbare Bedeutung gehabt haben, da diese Punkte im Wettbewerb keine werbende Bedeutung hatten und für die Kalkulation des Angebotes unerheblich waren, kein neuer Wettbewerb gefordert werden.“ S.a. Wagner/Jürschik, VergabeR 2012, 401. 1 S. u.a. Gruneberg, VergabeR 2005, 171; Braun, VergabeR 2005, 586. 2 Vgl. OLG Celle Beschl. v. 4.5.2001 – 13 Verg 5/00 – VergabeR 2001, 325; VK Hamburg (FB) Beschl. v. 27.4.2006 – VgK FB 2/06, s. ibr-online. 3 Vgl. hierzu Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 99 GWB Ziff. 4b m.w.N.; Müller-Wrede/Müller, VOL/A, § 1a Rz. 71 ff.

1158

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 45

N

hinsichtlich des Umfangs der übertragenen Dienstleistungen sowie der Höhe der hierfür zu zahlenden Entgelte verändert, unterfällt dem Vergaberecht1. Hierbei ist dann zu prüfen, ob die einschlägige Vergabe- und Vertragsordnung für diese weitere, zusätzliche Beauftragung ggf. Ausnahmeregelungen hinsichtlich der Verfahrensart enthält, so dass dem bisherigen Auftragnehmer der Auftrag erteilt werden kann2. Zur Abgrenzungsfrage zwischen vergaberechtlich irrelevanten Anpassungen 44 eines Vertrags von ausschreibungspflichtigen Vertragsänderungen im Einzelnen hat der EuGH erstmals mit Urteil vom 19.6.20083 Stellung genommen, wobei in der Situation des vom EuGH zu beurteilenden Ausgangsverfahrens gerade keine Vergabe vorlag. Demnach sind folgende Konstellationen in der vorliegenden Entscheidung als vergaberechtlich nicht relevant angesehen worden. – Ein Dienstleistungserbringer überträgt Dienstleistungen, die an den öffentlichen Auftraggeber erbracht werden, an eine Kapitalgesellschaft, deren Alleingesellschafter er selbst ist und die er kontrollieren und anweisen kann, unter Beibehaltung der Haftung für die Einhaltung der vertraglichen Verpflichtungen. – Ein ursprünglicher Vertrag wird dadurch an veränderte äußere Umstände angepasst, dass die ursprünglich in nationaler Währung ausgedrückten Preise in Euro umgerechnet und dabei geringfügig abgerundet werden; es wird auf einen neuen Preisindex Bezug genommen, der gemäß den Bestimmungen des ursprünglichen Vertrages den zuvor festgelegten Preisindex ersetzt. – Während der Laufzeit eines auf unbestimmte Zeit geschlossenen Dienstleistungsauftrags wird in einem Nachtrag eine Kündigungsverzichtsklausel für drei Jahre verlängert, welche zum Zeitpunkt der Vereinbarung der neuen Klausel unwirksam geworden wäre. Für bestimmte Staffelpreise in einem besonderen Bereich werden größere Rabatte, als die ursprünglich vorgesehenen festgelegt. d) Rahmenvereinbarungen aa) Vergaberechtliche Ausgangslage Auch Rahmenvereinbarungen4 stellen öffentliche Aufträge dar, die grds. 45 ausgeschrieben werden müssen. Solche Vereinbarungen empfehlen sich v.a. bei wiederkehrenden Beschaffungen, insbesondere bei der Beschaffung von Hardware sowie Standardsoftware. Der sukzessive Beschaffungsbedarf wird dabei in einer einzigen Ausschreibung, nämlich der Ausschreibung der Rahmenvereinbarung, zusammengefasst. 1 2 3 4

Vgl. OLG Düsseldorf v. 14.2.2001 – Verg 13/00, LSK 2001, 420266. S. hierzu unter Rz. 76 ff. S. EuGH v. 19.6.2008 – Rs. C-454/06, VergabeR 2008, 758 m. Anm. Hermann. S. Rosenkötter, VergabeR 2010, 368.

Bischof

1159

N Rz. 46

Einzelprobleme

46 Die VOL/A enthält eindeutige Regelungen sowohl für nationale Vergabe (§ 4 VOL/A) als auch für die EU-Vergabe (§ 4 EG VOL/A), wobei die EU-Regelung wesentlich detaillierter das Vorgehen bei der Vergabe von Rahmenvereinbarungen vorschreibt, als die nationale Regelung dies vorsieht. bb) Definition 47 Rahmenvereinbarungen sind Aufträge, die ein oder mehrere Auftraggeber an ein oder mehrere Unternehmen vergeben können, um die Bedingungen für Einzelaufträge, die während eines bestimmten Zeitraums vergeben werden sollen, festzulegen, insbesondere über den in Aussicht genommen Preis. Das in Aussicht genommene Auftragsvolumen ist so genau wie möglich zu ermitteln und bekannt zu geben, braucht aber nicht abschließend festgelegt zu werden, § 4 bzw. § 4 EG VOL/A. Die Rahmenvereinbarungen legen somit nur Bedingungen für noch abzuschließende Einzelverträge fest. cc) Bindungsgrad 48 Vorschriften zur rechtlichen Ausgestaltung der Rahmenvereinbarungen finden sich nicht. Diese wird insbesondere durch den Bindungsgrad der Vertragspartner vorgegeben. Im Wesentlichen lassen sich drei rechtliche Gestaltungsmöglichkeiten unterscheiden: – Einseitig verbindliche Rahmenvereinbarung: Diese Ausgestaltung stellt in der Praxis den Regelfall dar. Es besteht keinerlei Verpflichtung des Auftraggebers zur Inanspruchnahme der vorgehaltenen Leistungen. Nur das Unternehmen ist – ohne korrespondierenden Anspruch auf Beauftragung – zur Erbringung der Leistungen auf Abruf verpflichtet1. – Beidseitig verbindliche Rahmenvereinbarung: In dieser Konstellation sind beide Vertragspartner rechtlich gebunden. Der Auftraggeber ist verpflichtet, die Einzelaufträge aus der Rahmenvereinbarung zu erteilen. Das Unternehmen schuldet die Leistungserbringung auf Abruf. Diese Gestaltung stellt in der Praxis eher die Ausnahme dar. Als Variante tritt die Vereinbarung einer Mindestabnahmepflicht des Auftraggebers auf, was ggf. sogar nach § 8 Nr. 1 Abs. 3 VOL/A 2006 geboten war, um ungewöhnliche Wagnisse des Bieters zu kompensieren. Die neue VOL/A enthält zwar keine ausdrückliche Regelungen mehr zum Verbot, dem Bieter ungewöhnliche Wagnisse aufzubürden. Eine Verpflichtung, dem Bieter keine von ihm nicht beeinflussbaren und hinsichtlich Preis und Fristen schätzbaren Leistungspflichten abzuverlangen, dürfte sich jedoch bereits aus allgemeinen Grundsätzen ergeben, zumal bei solchen Verfahren, in denen mit dem Bieter nicht verhandelt werden darf2. 1 Der Auftraggeber bleibt jedoch zur sorgfältigen Ermittlung und Angabe seines Bedarfs verpflichtet. Ein Nichtabruf von Einzelleistungen kann u.U. zu Schadenersatzansprüchen führen: Graef, NZBau 2005, 561. 2 S. zur Behandlung ungewöhnlicher Wagnisse nach der Neufassung der VOL/A Brauer, VergabeR 2012, 343.

1160

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 51

N

– Beidseitig unverbindliche Rahmenvereinbarung: Hier ist weder der Auftraggeber zum Abruf verpflichtet noch der Auftragnehmer zur Leistungserbringung bei Abruf. Der praktische Nutzen solcher Gestaltungen ist nur gering, da beiderseits keine verlässlichen Bindungen vorliegen. Allenfalls ist diese Ausgestaltung bei Abschluss einer Rahmenvereinbarung mit mehreren Unternehmen ratsam, um bei Verweigerung der Leistung durch ein Unternehmen weitere Alternativen zu haben. dd) Wesentlicher Inhalt Im Hinblick auf das Erfordernis einer eindeutigen und erschöpfenden Leis- 49 tungsbeschreibung (§ 7 Abs. 1 bzw. § 8 Abs. 1 EG VOL/A) muss der wesentliche Inhalt der abzuschließenden Rahmenvereinbarung ersichtlich sein; nur dann kann ein Unternehmen eine vernünftige Kalkulation durchführen und ein Angebot abgeben. Das bedeutet, dass schon in den Vergabeunterlagen (§ 8 bzw. § 9 EG VOL/A) der zu erwartende Bedarf des öffentlichen Auftraggebers so konkret wie möglich anzugeben ist. Dies bezieht sich vor allem auf den in Aussicht genommenen Preis, den Leistungszeitraum sowie das in Aussicht genommene Auftragsvolumen. Schließlich ist die Rahmenvereinbarung keine unbestimmte Abmachung, 50 sondern vielmehr die verbindliche Grundlage eines späteren Abrufs mittels Vergabe von Einzelaufträgen. Sämtliche Details der Einzelaufträge müssen jedoch nicht bereits in der Rahmenvereinbarung enthalten sein. Dies ergibt sich im Umkehrschluss aus § 4 Abs. 5b EG VOL/A), wonach Angebote vor Beauftragung der Einzelleistungen vervollständigt werden müssen, soweit nicht sämtliche Bedingungen in der Rahmenvereinbarung geregelt sind. Es muss jedoch bei Gestaltung der Rahmenvereinbarung überlegt und hinterfragt werden, welche Bedingungen tatsächlich offen gelassen werden können. Gerade die preisliche Gestaltung sollte zumindest im Hinblick auf die wesentlichen Eckpunkte fest vereinbart werden, also z.B. v.a. hinsichtlich der Höhe von Stunden-/Tagessätzen. Empfehlenswert erscheint zumindest eine verbindliche Mindestabnahmemenge. Die maximale Laufzeit einer Rahmenvereinbarung beträgt vier Jahre, es sei 51 denn, eine Ausnahme ist durch den Auftragsgegenstand oder besondere Umstände gerechtfertigt, § 4 Abs. 1 S. 4 VOL/A bzw. § 4 Abs. 7 EG VOL/A). Im Bereich der Informationstechnologie wird es einer besonderen Abwägung im jeweiligen Einzelfall bedürfen, ob der gesamte Zeitrahmen überhaupt ausgeschöpft oder gar überschritten werden soll. Gerade die hohe Innovationsgeschwindigkeit und das damit verbundene Bedürfnis, nicht stets hinter dem aktuellen Stand der Technik zurückzubleiben, werden eher dazu führen, den Höchstrahmen zu unterschreiten. Soll der Zeitrahmen ausgeschöpft werden, sollte – soweit möglich – über die vertragliche Gestaltung eine Anpassung an den aktuellen Stand der Technik erreicht werden.

Bischof

1161

N Rz. 52

Einzelprobleme

ee) Rahmenvereinbarung mit einem oder mehreren Unternehmen 52 Aus der Rahmenvereinbarung muss sich auch ergeben, ob diese letztlich mit einem oder mehreren Unternehmen abgeschlossen werden soll, da dies auch die Vergabe der Einzelaufträge maßgeblich beeinflusst: Die Vergabe der einzelnen Aufträge erfolgt nach unterschiedlichen Verfahrensweisen, abhängig davon, ob die Rahmenvereinbarung mit einem oder mehreren Unternehmen geschlossen werden soll (vgl. auf EU-Ebene: § 4 Abs. 3 bis 6 EG VOL/A; auf nationaler Ebene lässt § 4 VOL/A den Ablauf weitgehend offen)1. Hierbei ist zu beachten, dass bei einer Rahmenvereinbarung mit mehreren Unternehmen grds. die Beteiligung mindestens dreier Auftragnehmer gefordert wird, sofern eine ausreichende Anzahl geeigneter Unternehmen und zulässiger Angebote vorliegt, § 4 Abs. 4 EG VOL/A2. ff) Zweistufiger Beschaffungsvorgang 53 Vergaberechtlich ist zwischen dem Verfahren, das zum Abschluss der Rahmenvereinbarung führt, und der Vergabe der auf der Rahmenvereinbarung basierenden Einzelaufträge zu unterscheiden („zwei Vergabestufen“)3. Der Abschluss der Rahmenvereinbarung dient auf der ersten Stufe dazu, die Bedingungen für Aufträge festzulegen (insbesondere Preis und Umfang), die von einem oder mehreren Auftraggebern im Lauf eines bestimmten Zeitraums vergeben werden sollen. Weitere Details und Einzelheiten werden bei Vergabe der Einzelaufträge als zweiter Stufe festgelegt, wobei in der Praxis häufig auch erst dort Preis und Umfang abschließend vereinbart werden. 54 Bei Vergabe der Einzelaufträge ist weiter danach zu differenzieren, ob die Rahmenvereinbarung mit einem oder mehreren Unternehmen abgeschlossen wurde; hierbei ist auch die Detailgenauigkeit der Rahmenvereinbarung von erheblicher Bedeutung4. Zur Bestimmung der zutreffenden Verfahrensart für die Vergabe von Rahmenvereinbarungen gelten die allgemeinen Regelungen5, d.h. die Vergabe einer Rahmenvereinbarung stellt keine eigenständige Vergabeart dar. Die Vergabe auf EU-Ebene erfolgt somit im offenen oder nichtoffenen Verfahren oder im Verhandlungsverfahren oder per wettbewerblichem Dialog. gg) „Sperrwirkung“ 55 § 4 Abs. 1 S. 3 bzw. § 4 Abs. 1 S. 3 EG VOL/A untersagt es, mehrere Rahmenvereinbarungen für dieselbe Leistung abzuschließen. Das Verbot bezieht sich auf inhaltlich unterschiedlich ausgestaltete Rahmenvereinbarungen bezüg1 So auch Knauff, VergabeR 2006, 24, 30. 2 S. zur nur schwer überzeugenden Forderung nach „mindestens drei Unternehmen“ Grönig, VergabeR 2005, 156, 160. 3 S. u.a. Müller-Wrede/Poschmann VOL/A Kommentar 2. Aufl. 2007, § 3a Nr. 4 Rz. 41. 4 S.a. Gröning VergabeR 2005, 156; Knauff VergabeR 2006, 24. 5 S. hierzu Rz. 76 ff.

1162

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 58

N

lich derselben Leistung. Daraus darf jedoch keine generelle Sperrwirkung für eine gleichgerichtete nachfolgende Vergabe abgeleitet werden – zumindest dann nicht, wenn keine Abnahmeverpflichtung des Auftraggebers existiert. Aus rein vergaberechtlicher Sicht erscheint eine neue Vergabe als zulässig. Ob allerdings der Auftraggeber damit vertragliche Pflichten aus der Rahmenvereinbarung verletzt, ist nach zivilrechtlichen Maßstäben zu beurteilen1. 4. Nationales oder EU-Vergaberecht a) Schwellenwert Eine EU-weite Ausschreibung muss nur erfolgen, wenn der Auftragswert, die 56 Schwellenwerte übersteigt (sachliche Voraussetzungen, § 100 GWB i.V.m. §§ 2, 1 VgV)2. Maßgeblich für die Vergabe von IT-Leistungen ist, abgesehen von den Sondervorschriften für den Sektorenbereich, oberste und obere Bundesbehörden und bei der Vergabe von Losen, ein Mindestauftragswert in Höhe von derzeit 200 000 Euro ohne Umsatzsteuer (§ 2 Nr. 3 VgV). Die schlichte Behauptung, dass die Vergabe voraussichtlich über diesem Schwellenwert liegt, genügt den Anforderungen des Vergaberechts nicht. Der öffentliche Auftraggeber ist vielmehr gehalten, diesen Auftragswert gem. § 3 VgV realistisch zu schätzen („seriöse Prognose“). Er muss möglichst genau kalkulieren und dabei Vergleichswerte berücksichtigen3. Maßgebend ist der Verkehrs- oder Marktwert, zu dem die ausgeschriebene Leistung zum maßgeblichen Zeitpunkt am Markt zu erhalten ist4. Als zulässig wird bei pflichtgemäßer Schätzung des Basiswerts ein Schätzungsspielraum von plus/minus 10 % erachtet. Diese Informationen erhält der öffentliche Auftraggeber am besten im Rahmen einer von ihm durchgeführten Marktanalyse.

57

Hält sich der Auftraggeber an den vorgegebenen Rahmen (s. hierzu sogleich 58 unter Rz. 59 ff. zu den maßgeblichen Vorgaben der Auftragswertsschätzung), steht ihm ein Beurteilungsspielraum zu, der von den Nachprüfungsstellen nicht hinterfragt werden kann, sondern hingenommen werden muss5.

1 S. hierzu Müller-Wrede/Poschmann, VOL/A, Kommentar, 2. Aufl. 2007, § 3a Nr. 4 Rz. 30 ff.; s.a. Knauff, VergabeR 2006, 24; a.A. Jakoby, VergabeR 2004, 768; Graef, NZBau 2005, 561. 2 S. ausführlich hierzu Grützmacher, ITRB 2002, 236, 238; Ohle/Sebastiani, CR 2003, 510 ff.; Schimanek, K&R 2004, 269 ff. 3 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, 2003, § 3 Rz. 1. 4 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, 2003, § 3 Rz. 4 ff. 5 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, 2003, § 3 Rz. 5.

Bischof

1163

N Rz. 59

Einzelprobleme

b) Schätzung des Auftragswerts 59 Maßgeblicher Zeitpunkt für die Schätzung des Auftragswerts ist gem. § 3 Abs. 9 VgV der Tag der Absendung der Bekanntmachung der beabsichtigten Auftragsvergabe oder die sonstige Einleitung des Vergabeverfahrens1. 60 Bei der Schätzung des Auftragswertes ist von der geschätzten Gesamtvergütung (ohne Umsatzsteuer) für die vorgesehene Leistung auszugehen, § 3 Abs. 1, § 1 Abs. 1 VgV. Dem Auftraggeber ist es insbesondere nicht erlaubt, den Wert eines Auftrags so zu schätzen oder so aufzuteilen, dass er ihn bewusst der Anwendung der Vergaberechtsbestimmungen entziehen kann (Verbot der Umgehung des Vergaberechts, § 3 Abs. 2 VgV). 61 Bei zeitlich begrenzten Lieferaufträgen von einer Laufzeit bis zu 12 Monaten sowie bei Dienstleistungsaufträgen bis zu 48 Monaten Laufzeit, für die kein Gesamtpreis angegeben wird, ist bei der Schätzung des Auftragswerts der Gesamtwert für die Laufzeit des Vertrags zugrunde zu legen. Bei Lieferaufträgen mit einer Laufzeit von mehr als 12 Monaten ist der Gesamtwert einschließlich des geschätzten Restwerts zugrunde zu legen. Bei unbefristeten Verträgen oder bei nicht absehbarer Vertragsdauer folgt der Vertragswert aus der monatlichen Zahlung multipliziert mit 48 (§ 3 Abs. 4 VgV)2. 62 Wenn die Vergabe nach Losen3 erfolgen soll, so sind gem. § 3 Abs. 7 VgV bei der Schätzung des Auftragswert alle Lose zu berücksichtigen und somit die Werte der einzelnen Lose zusammenzurechnen, auch wenn der zu vergebende Auftrag aus mehreren Losen besteht, für die jeweils ein gesonderter Auftrag vergeben wird. Bei reinen Lieferaufträgen gilt dies jedoch nur für Lose bzgl. gleichartiger Lieferungen. 63 Werden Optionsrechte vorgesehen, insbesondere das Recht des Auftraggebers, von einem Unternehmer eine Leistung zu schon in der Vergabe festliegenden Konditionen zu verlangen, ist der Auftragswert unter Einbeziehung des Werts des Optionsrechts zu berechnen, § 3 Abs. 1 Satz 2 VgV. 64 Wird ein Rahmenvertrag ausgeschrieben, so ist auf den geschätzten Höchstwert aller für diesen Zeitraum geplanten Aufträge abzustellen, § 3 Abs. 6 VgV. 65 Projiziert auf die Vergabe von IT-Leistungen bedeutet dies, dass bei Vergabe komplexer IT-Leistungen, d.h. aus verschiedenen einzelnen Leistungen bestehenden Projekten, für die Kostenschätzung der Marktpreis der Lieferung von Hard- und/oder Software und sonstigen zu erbringenden Leistungen (Parametrisierung/Anpassung, Ergänzung/Änderung, Schulung, Wartung/Pflege) maßgeblich ist.

1 S. zur Vergabebekanntmachung nachfolgend Rz. 200 ff. 2 S. hierzu auch Art. 9 RL 2004/18/EG. 3 Lose entstehen durch die Teilung der Aufträge in Fach- und Teillose; s. hierzu bereits oben Rz. 24 ff.

1164

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 68

N

Soweit die zu erbringenden Leistungen Dauerschuldverhältnisse darstellen (z.B. Pflege von Software, Wartung von Hardware, langfristige Projekt-/Systemverträge) gilt zudem als Grundlage der Schätzung bei

66

– eindeutig befristeten Verträgen: Gesamtauftragswert, – unbefristeten Verträgen: monatliche Zahlung multipliziert mit 48. Dies gilt auch, wenn der Vertrag eine Verlängerungsklausel sowie eine Kündigungsmöglichkeit enthält. 5. Ausnahmen vom Anwendungsbereich des Vergaberechts § 100 GWB zählt Ausnahmetatbestände für Vertragsbeziehungen auf, für 67 die das Vergaberecht nicht gilt. Wie bei allen Ausnahmetatbeständen gilt, dass diese abschließend und eng auszulegen sind1. Im IT-Bereich kann durchaus der sicherheitsrelevante Bereich im Sinne der Regelung in § 100 Abs. 8 GWB eine Rolle spielen, was jeweils einer Einzelfallprüfung bedarf2. Gemäß § 100 Abs. 8 GWB eine Rolle spielen ist das Vergaberecht dann nicht anwendbar, wenn – ein Auftrag in Übereinstimmung mit den Bestimmungen der Bundesrepublik Deutschland für geheim erklärt wird; – die Ausführung eines Auftrags besondere Sicherheitsmaßnahmen entsprechend vorstehender Bestimmungen erfordert; – besonders hohe Sicherheitsrelevanz besteht, nämlich bei Beschaffungen im Zusammenhang mit dem Einsatz der Streitkräfte bzw. mit der Umsetzung von Maßnahmen zur Terrorismusbekämpfung sowie bei der Beschaffung von sensibler Informationstechnik oder Telekommunikationsanlagen; – internationale Abkommen oder besondere Verfahren einer internationalen Organisation bestehen. 6. Anzuwendende Vergabe- und Vertragsordnungen a) Abgrenzung von VOB, VOL und VOF Die zu vergebenden IT-Leistungen sind unter die Begriffe der Bau-, Liefer- 68 und Dienstleistungen einzuordnen, da hierdurch bestimmt wird, welche Vergabe- und Vertragsordnung maßgeblich ist (§ 1 VOL/A)3. Bei Verträgen, die verschiedene dieser Leistungstypen beinhalten, ist § 99 Abs. 13 GWB zu

1 Vgl. Dreher, in: Immenga/Mestmäcker, § 100 Rz. 12. 2 Vgl. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 55; Gass/Ohle, ZfBR 2006, 655. Für verteidigungs- und sicherheitsrelevante Aufträge i.S.d. § 99 Abs. 7 GWB gilt die VSVgV, es sei denn § 100 Abs. 3 bis 6 oder 100c GWB wären einschlägig. 3 S. zur Problematik der Abgrenzung (baurechtsbezogen) Noch, BauRB 2005, 147.

Bischof

1165

N Rz. 69

Einzelprobleme

beachten (wertmäßig überwiegender Leistungsanteil entscheidet, ob Lieferoder Dienstleistung vorliegt). Bei einem Auftrag zur Durchführung mehrerer Tätigkeiten gelten die Bestimmungen für die Tätigkeit, die den Hauptgegenstand darstellt, § 99 Abs. 8 GWB. Rahmenvereinbarungen sowie Vertragsänderungen/-verlängerungen bedürfen einer gesonderten Betrachtung. b) Lieferleistungen 69 Lieferleistungen unterfallen stets der VOL/A. Gem. § 99 Abs. 2 GWB sind Lieferaufträge Verträge zur Beschaffung von Waren, die vor allem Kauf, Ratenkauf, Leasing, Miete oder Pacht mit oder ohne Kaufoption betreffen. Unter Waren sind alle beweglichen, körperlichen Sachen des Handelsverkehrs zu verstehen, sowie elektrischer Strom, Gas, Wasser, Fernwärme und Software1. Die Lieferung von Standardsoftware ist damit eindeutig eine Lieferung i.S.v. § 4 VgV sowie § 1 VOL/A. Auch die notwendige Parametrisierungsleistung sowie die Einweisung in die Software dürften als zur Lieferleistung gehörig anzusehen sein. c) Sonstige Leistungen/Dienstleistungen 70 Sonstige Leistungen/Dienstleistungen unterfallen der VOF, wenn diese im Rahmen einer freiberuflichen Tätigkeit oder im Wettbewerb mit freiberuflich Tätigen angeboten werden und ihr Gegenstand eine Aufgabe ist, deren Lösung nicht vorab eindeutig und erschöpfend beschrieben werden kann (vgl. § 1 VOL/A, § 1 VOF). 71 Die Definition einer freiberuflichen Tätigkeit richtet sich grundsätzlich nach § 18 Abs. 1 Nr. 1 EStG, ist aber nicht abschließend2. So dürfte nach jetziger Rechtsprechung des BFH wohl auch die Tätigkeit des Informatikers hierunter fallen. Es genügt, dass die Tätigkeit im Wettbewerb zu Freiberuflern erbracht wird, womit insbesondere Gesellschaften, die von Freiberuflern gebildet (wie z.B. BGB-Gesellschaft, GmbH, AG) und die handels- und steuerrechtlich als Kaufleute bzw. Gewerbetreibende behandelt werden, erfasst werden. Vergaberechtlich kann es aber keinen Unterschied machen, in welcher Rechtsform ein Bieter eine Tätigkeit durchzuführen beabsichtigt. Maßgeblich ist allerdings, ob die auszuschreibende Dienstleistung in der Vergangenheit von Gewerbetreibenden oder von Freiberuflern erbracht wurde. Dies kann der öffentliche Auftraggeber nur anhand einer Marktanalyse

1 Vgl. Kulartz/Steding, IT-Leistungen, 2002, S. 10; s. auch BGH v. 4.11.1987 – VIII ZR 314/86, MDR 1988, 223 = CR 1988, 124; BGH v. 22.12.1999 – VIII ZR 299/98, MDR 2000, 442 = CR 2000, 207 ff. 2 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 5 VgV Rz. 2; Müller, in: Daub/Eberstein, Kommentar zur VOL/A, § 1 Rz. 16; s. auch Grützmacher, ITRB 2002, 236 (239), der zwischen Konzeptionierung und maßgeschneiderter Beratung gegenüber der reinen Umsetzung, Schulung und Wartung unterscheidet.

1166

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 75

N

feststellen1. Ergibt die Marktanalyse, dass die Leistungen von Gewerbetreibenden erbracht wurden, findet die VOL/A Anwendung. Dies gilt selbst dann, wenn sich auf die Vergabe hin Freiberufler bewerben würden2. Sind hingegen freiberufliche Leistungen betroffen, ist weiter zur prüfen, ob 72 die Leistung nicht eindeutig und erschöpfend im Voraus beschreibbar ist. Erschöpfend beschreibbar ist eine Leistung, wenn Angebote abgegeben werden können, die von einem Auftraggeber objektiv ohne weitere Rückfragen und Verhandlungen bewertet werden können3. Sind diese Voraussetzungen erfüllt, gelangt die VOL/A zur Anwendung, ansonsten die VOF. d) Gemischte Verträge Die reine Lieferung mit kleineren Zusatzleistungen wird aber gerade kom- 73 plexen IT-Projekten nicht gerecht, wenn über die Lieferung vorhandener Standardsoftware hinaus eine Vielzahl weiterer Leistungen zu erbringen ist (wie u.a. Änderung, Ergänzung, Anpassung der Software, Pflege, Schulung etc.). Diese dürften vergaberechtlich als sonstige Leistungen bzw. Dienstleistungen anzusehen sein. Insoweit müsste dann eine Abgrenzung zwischen VOL/A und VOF stattfinden. Bei solchen gemischten Verträgen, deren Leistungsinhalt sowohl aus Liefe- 74 rungen als auch aus Dienstleistungen besteht, entscheidet der Schwerpunkt der Leistung, welche Vergabe- und Vertragsordnung anzuwenden ist: Übersteigt der Wert der Dienstleistungen den Wert des Lieferanteils, so ist der gesamte Auftrag als Dienstleistung zu qualifizieren. Ist dagegen der Wert des Lieferanteils höher, so ist der gesamte Auftrag als Lieferleistung zu behandeln. Die Schwerpunkttheorie war bislang nicht in VgV oder GWB gesetzlich 75 anerkannt. Mit dem ÖPP-Beschleunigungsgesetz wurde die Theorie gesetzlich anerkannt und in § 99 Abs. 6 GWB verankert, nunmehr § 99 Abs. 13 GWB4. Nachfolgend wird – entsprechend der wohl überwiegenden Praxis – von der Anwendung der VOL/A ausgegangen.

1 S. nachfolgend Rz. 131 ff. Zu einer solchen war der Auftraggeber nach § 4 Nr. 1 VOL/A a.F. verpflichtet. Die Neuregelungen enthalten diese Verpflichtung nicht mehr, was aber nicht deren Wegfall gleichkommt. 2 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 5 VgV Rz. 2; Müller, in: Daub/Eberstein, Kommentar zur VOL/A, § 1 Rz. 16, jeweils m.w.N. 3 S. Kulartz/Steding, Fehlerfreie Ausschreibungen und rechtssichere Vertragsinhalte, S. 11. 4 S. hierzu bereits Rz. 68.

Bischof

1167

N Rz. 76

Einzelprobleme

III. Verfahrensarten nach VOL/A 1. Einleitung a) EU-Ebene 76 Die VOL/A gibt auf EU-Ebene zunächst drei Grundtypen vergaberechtlicher Verfahrensarten vor, die grundsätzlich in einer Hierarchie zueinander stehen, § 101 Abs. 1 GWB, § 3 Abs. 1 EG VOL/A1: – Offenes Verfahren: Der Regelfall nach dem Willen des Gesetzgebers. Es ist gekennzeichnet durch strikte Form- und Fristvorgaben, stark formalisiert und erlaubt keine Verhandlungen mit den Bietern. Der Bewerberkreis ist unbeschränkt. – Nichtoffenes Verfahren: Dieses darf nur dann angewandt werden, wenn die in § 3 EG Abs. 2 VOL/A genannten Voraussetzungen erfüllt sind, so z.B. wenn die Leistung nur von einem beschränkten Bewerberkreis in geeigneter Weise (besonders auf Grund außergewöhnlicher Fachkunde, Leistungsfähigkeit oder Zuverlässigkeit) erbracht werden kann. Das Verfahren bietet gegenüber dem offenen Verfahren Form- und Fristerleichterungen. – Verhandlungsverfahren: Es darf nur unter engen Voraussetzungen angewandt werden und soll nach dem Willen des Gesetzgebers die absolute Ausnahme darstellen (§ 3 Abs. 3 und 4, 24 EG VOL/A). Zudem wird unterschieden, ob eine Vergabebekanntmachung veröffentlicht wird (§ 3 EG Abs. 3 VOL/A) oder nicht (§ 3 EG Abs. 4 VOL/A). – Wettbewerblicher Dialog (s. Rz. 77) 77 Mit dem ÖPP-Beschleunigungsgesetz vom 8.9.2005 wurde der wettbewerbliche Dialog eingeführt. Er darf nur unter der Voraussetzung des § 101 Abs. 4 GWB, § 3 EG Abs. 7 Satz 1 VOL/A bei besonders komplexen Aufträgen angewandt werden. Hierbei handelt es sich um ein Vergabeverfahren mit vorgeschaltetem Teilnahmewettbewerb, das die Vergabe in drei Phasen vorsieht und in dem über alle Einzelheiten des Auftrags verhandelt werden darf: – Phase 1: Teilnahmewettbewerb, in dem die konkreten Teilnehmer am Vergabeverfahren aus dem Kreis der Bewerber ausgewählt werden. – Phase 2: Dialogphase, in der mit den Teilnehmern die Optimierung der angebotenen Lösungen erarbeitet wird. – Phase 3: Bietphase, in der die optimierte Lösung ausgeschrieben und der Zuschlag unter den Teilnehmern erteilt wird.

1 Die VOF sieht dagegen nur das Verhandlungsverfahren (mit oder ohne vorheriger Vergabebekanntmachung) vor (§ 5 VOF). S. zu den einzelnen Verfahrensarten und Voraussetzungen auch Noch, Vergaberecht kompakt, 3. Aufl., S. 229 bis 249 mit zahlreichen Rechtsprechungsnachweisen.

1168

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 80

N

In welchem Verhältnis die bisherigen drei Verfahrensarten zu dieser neuen 78 Verfahrensart und v.a. das Verhandlungsverfahren zum Wettbewerblichen Dialog steht, dürfte wohl wie folgt zu beantworten sein: Weder aus VKR noch aus dem Wortlaut des § 101 GWB kann ein Hinweis entnommen werden, dass Verhandlungsverfahren und Wettbewerblicher Dialog in einem Vorrang-/Nachrangverhältnis zueinander stehen. Weder ist das Verhandlungsverfahren zum wettbewerblichen Dialog vorrangig noch umgekehrt. Vielmehr sind beide Verfahren je nach ihren normierten Voraussetzungen – und damit aber nachrangig gegenüber Offenem und Nichtoffenem Verfahren – unabhängig voneinander zulässig. Dies kann im Einzelfall auch zu Überschneidungen, also zur doppelten Zulässigkeit führen. Dem öffentlichen Auftraggeber steht dann ein Wahlrecht zwischen den beiden zulässigen Verfahrensarten zu1. b) Nationale Ebene Auf nationaler Ebene (also bei Unterschreitung der Schwellenwerte) stehen dem öffentlichen Auftraggeber folgende Verfahrensarten zur Verfügung:

79

– öffentliche Ausschreibung, § 3 Abs. 1 S. 1, Abs. 2 VOL/A – beschränkte Ausschreibung, § 3 Abs. 1 S. 2, Abs. 3 VOL/A mit Teilnahmewettbewerb bzw. ohne Teilnahmewettbewerb, § 3 Abs. 4 VOL/A – freihändige Vergabe, § 3 Abs. 5 VOL/A Auch auf nationaler Ebene gilt der Vorrang der öffentlichen Ausschreibung, § 3 VOL/A; nur wenn die Ausnahmetatbestände einer anderen Verfahrensart erfüllt sind, kann diese angewandt werden. c) Wahl des „richtigen Verfahrens“ Die Wahl der Vergabeart ist eine der schwierigsten Entscheidungen bei Ver- 80 gabe von IT-Leistungen, insbesondere da die Begründung der Abweichung vom offenen bzw. nichtoffenen Verfahren (bzw. national von der öffentlichen bzw. beschränkten Ausschreibung) aktenkundig gemacht werden muss (§§ 3 EG, 24 EG VOL/A bzw. §§ 3, 20 VOL/A) und die Bieter – bei EU-weiten Vergaben – die Wahl einer falschen Verfahrensart vor der Vergabekammer nachprüfen lassen können muss. Dies kann ggf. sogar bis zur Aufhebung der Ausschreibung führen2. Nur in wenigen Fällen wurden von nationalen Gerichten oder vom EuGH die von den öffentlichen Auftraggebern vorgebrachten Begründungen bislang anerkannt. Insbesondere sog. „De-facto-Vergaben“, bei 1 Dies wird auch durch die Gesetzesbegründung zu § 101 GWB wie folgt unterstrichen: „Mit der Änderung der Reihenfolge der Absätze 4 und 5 [in § 101 GWB] soll klar gemacht werden, dass zwischen dem wettbewerblichen Dialog und dem Verhandlungsverfahren keine Hierarchie besteht. Der wettbewerbliche Dialog ist ebenso wie das Verhandlungsverfahren an das Vorliegen bestimmter Voraussetzungen geknüpft.“ 2 S. vor allem Noch, Vergaberecht kompakt, S. 249 f.

Bischof

1169

N Rz. 81

Einzelprobleme

denen unter Missachtung/Nichtbeachtung der Vergabevorschriften „freihändig“ vergeben wird, also die Voraussetzungen hierfür nicht vorlagen, unterliegen der Nachprüfung vor der Vergabekammer1. 81 Gerade für Verhandlungsverfahren ohne Teilnahmewettbewerb/freihändige Vergabe, also eine Vergabe ohne Wettbewerbsbeteiligung und ohne entsprechende Veröffentlichungen vor Auftragserteilung, mussten und müssen zwingende Gründe gegeben sein, für deren Vorliegen im Zweifel der öffentliche Auftraggeber die Beweislast trägt2. Dabei ist v.a. Folgendes zu beachten: – Die Vorschriften, die die Fälle regeln, in denen die Durchführung einer freihändigen Vergabe/eines Verhandlungsverfahrens zulässig ist, stellen Ausnahmen dar und sind daher eng auszulegen3. – Der öffentliche Auftraggeber muss die Entscheidung für freihändige Vergabe/Verhandlungsverfahren begründen und er trägt die Beweislast für das Vorliegen der Voraussetzungen. Es werden strenge Maßstäbe an die Begründungsqualität angelegt4. 2. De-Facto-Vergaben a) Begriff 82 Der Begriff der De-facto-Vergaben hat sich in den vergangenen Jahren als Bezeichnung einer Vorgehensweise der Vergabestellen (meist im Zusammenhang mit EU-weiten Vergaben) eingebürgert, bei der diese entweder aus Unkenntnis bzw. einer rechtlichen Fehleinschätzung heraus oder in voller Kenntnis der rechtlichen Gegebenheiten auf die Durchführung eines eigentlich erforderlichen Vergabeverfahrens verzichten. 83 Das absichtliche Unterlassen jeder formalen Ausschreibung ist dem vergaberechtlichen Umgehungsverbot (§ 3 Abs. 2 VgV) zuzuordnen und kann im Wege der Nachprüfung von „übergangenen Bietern“ verfolgt werden. Dahinter können sich z.B. folgende Konstellationen verbergen: – Die Vergabestelle wendet sich direkt an ein oder mehrere Unternehme, lässt sich Preise benennen bzw. Angebote erstellen und erteilt dann auf dieser Basis einen Auftrag. – Befristete Altverträge werden schlicht verlängert oder in wesentlichen Teilen (in Bezug auf Leistungsumfang, Vergütung o.Ä.) verändert. – Es werden Anschlussaufträge erteilt, ohne dass die diesbezüglichen Voraussetzungen gem. § 3 bzw. § 3 EG VOL/A vorgelegen hätten. 1 S. Rz. 300, 82 ff.; Noch, Vergaberecht kompakt, S. 81 ff. 2 S. u.a. Kaelble, in: Müller-Wrede, VOL/A Kommentar, 2. Aufl. 2007, § 3a Rz. 149 m.w.N. 3 U.a. EuGH v. 18.11.2004 – Rs C 126/03, EU Kommission ./. Bundesrepublik Deutschland. 4 U.a. EuGH v. 18.11.2004 – Rs C 126/03, EU Kommission ./. Bundesrepublik Deutschland.

1170

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 89

N

b) Folgen § 101b GWB bestimmt im Falle der de-facto-Vergabe (d.h. der Auftragsertei- 84 lung direkt an ein Unternehmen unter Verletzung der Vergaberegeln) die schwebende Unwirksamkeit des Vertrags. Der Vertrag ist jedoch dann von Anfang an wirksam, wenn die in § 101b Abs. 2 GWB vorgesehenen Fristen abgelaufen und die Unwirksamkeit nicht in einem Nachprüfungsverfahren geltend gemacht wurde1. 3. Das offene Verfahren/die öffentliche Ausschreibung § 3 EG Abs. 1 VOL/A bestimmt, dass eine Ausnahme vom Vorrang des offe- 85 nen Verfahrens nur in begründeten Ausnahmefällen zulässig ist. Diese Ausnahmen wiederum ergeben sich aus den Zulässigkeitstatbeständen von nichtoffenem Verfahren, Verhandlungsverfahren oder wettbewerblichem Dialog. Beim offenen Verfahren2 werden die Leistungen im formal fest vorgeschriebe- 86 nen Rahmen nach einer öffentlichen Aufforderung einer unbeschränkten Zahl von Unternehmen zur Einreichung von Angeboten vergeben (§ 3 Abs. 1 S. 1 bzw. § 3 EG Abs. 1 S. 1 VOL/A). Ein Teilnahmewettbewerb findet nicht statt, so dass die Eignung der Bieter (Fachkunde, Leistungsfähigkeit, Zuverlässigkeit) nicht in einer „Vorstufe“, sondern im Rahmen der Angebotsbewertung gem. § 19 EG VOL/A geprüft und bewertet wird. Beim offenen Verfahren beträgt die Angebotsfrist mindestens 52 Tage vom Tage der Absendung der Bekanntmachung gerechnet (§ 12 EG Abs. 2 VOL/A). Liegen die Voraussetzungen des § 12 EG Abs. 3 VOL/A vor, kann diese Frist im Regelfall auf 36 Tage, im Minimum auf 22 Tage verkürzt werden3.

87

Verhandlungen mit den Bietern sind gem. § 18 EG VOL/A grundsätzlich verboten. Es sind nur noch Aufklärungen, aber keinerlei Arten von Verhandlung zulässig.

88

4. Das nichtoffene Verfahren (national: die beschränkte Ausschreibung) Eine beschränkte Ausschreibung/ein nichtoffenes Verfahren soll nur stattfinden, wenn – die Leistung nach ihrer Eigenart nur von einem beschränkten Kreis von Unternehmen in geeigneter Weise ausgeführt werden kann, besonders wenn dafür außergewöhnliche Fachkunde oder Leistungsfähigkeit oder

1 S. hierzu auch nachfolgend zu § 101a GWB unter Rz. 255 ff. 2 Unter Beachtung der genannten Besonderheiten können die Ausführungen zum Verhandlungsverfahren entsprechend herangezogen werden. 3 S. zur Verkürzungsmöglichkeit dieser Fristen bei elektronischer Vergabe § 12 EG Abs. 6 VOL/A.

Bischof

1171

89

N Rz. 90

Einzelprobleme

Zuverlässigkeit (nun nur noch zusammenfassend als „Eignung“ bezeichnet) erforderlich ist1, – die öffentliche Ausschreibung/das offene Verfahren für den Auftraggeber oder die Bewerber einen Aufwand verursachen würde, der zu dem erreichbaren Vorteil oder dem Wert der Leistung im Missverhältnis stehen würde, – eine vorangegangene öffentliche Ausschreibung/ein offenes Verfahren kein wirtschaftliches Ergebnis gehabt hat oder – eine öffentliche Ausschreibung/ein offenes Verfahren aus anderen Gründen (z.B. Dringlichkeit, Geheimhaltung) unzweckmäßig ist (bei § 3 EG Abs. 2 VOL/A sind die genannten Beispiele nicht mehr erwähnt). 90 Der beschränkten/nichtoffenen Ausschreibung2 sollte, soweit zweckmäßig, eine öffentliche Aufforderung vorangehen, sich um Teilnahme zu bewerben (beschränkte Ausschreibung mit vorgeschaltetem öffentlichen Teilnahmewettbewerb, vgl. § 3 Nr. 1, Abs. 4 VOL/A a.F.). Eine entsprechende Regelung findet sich in der jetzigen VOL/A nicht mehr. Üblicherweise werden nichtoffene Verfahren ohnehin mit Teilnahmewettbewerb durchgeführt. Dabei kann eine Höchstzahl von Unternehmen (nicht unter fünf) bestimmt werden, die dann zur Abgabe eines Angebots aufgefordert werden (§ 3 EG Abs. 5 VOL/A). 91 Beim nichtoffenen Verfahren beträgt die Teilnahmefrist grds. mindestens 37 Tage (§ 12 EG Abs. 4 VOL/A), die Angebotsfrist mindestens 40 Tage (§ 12 EG Abs. 5 VOL/A), jeweils vom Tag der Absendung der Bekanntmachung an gerechnet. In Fällen besonderer Dringlichkeit beträgt die Teilnahmefrist mindesten 15 Tage (§ 12 EG Abs. 4 Satz 2 VOL/A, wobei bei elektronischer Übermittlung auf 10 Tage verkürzt werden kann). Liegen die Voraussetzungen des § 12 EG Abs. 5 S. 2, 3 VOL/A) vor, kann die Angebotsfrist im Regelfall auf 36 Tage, im Minimum auf 22 Tage, in Fällen der besonderen Dringlichkeit auf 10 Tage verkürzt werden3. 92 Wie beim offenen Verfahren sind mit den dort genannten Ausnahmen auch hier Verhandlungen mit den Bietern gem. § 18 EG VOL/A grundsätzlich verboten. Eine Ausnahme besteht auch hier für Aufklärung. 5. Das Verhandlungsverfahren/die freihändige Vergabe a) Bedeutung und Merkmale 93 Die Verfahrensarten offenes und nichtoffenes Verfahren werden zumeist dem Bedürfnis des öffentlichen Auftraggebers nicht gerecht, insbesondere 1 Vgl. zu diesen Kriterien nachfolgend unter Rz. 210 ff. 2 Unter Beachtung der genannten Besonderheiten können die Ausführungen zum Verhandlungsverfahren entsprechend herangezogen werden. 3 S. zur weiteren Fristverkürzung bei elektronischer Vergabe § 12 EG Abs. 6 VOL/A. S. zur Beschaffung kompletter IT-Systeme auch Losch, VergabeR 2012, 352.

1172

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 99

N

die Leistungsbeschreibung mit dem potentiellen Bieter im Einzelnen zu verhandeln. Dem steht das in § 15 bzw. § 18 EG VOL/A postulierte Verhandlungsverbot entgegen. Nach der Rechtslage bis zum 7.9.2005 konnte meist nur das Verhandlungs- 94 verfahren den Bedürfnissen beider Seiten gerecht werden, in dem über Preis und Leistung sowie über die vertraglichen Bedingungen verhandelt werden konnte. Seit dem 8.9.2005 besteht zudem bei der Vergabe von besonders komplexen Leistungen das neue Vergabeverfahren „wettbewerblicher Dialog“, in dem über alle Einzelheiten des Auftrags verhandelt werden kann (zum wettbewerblichen Dialog s. Rz. 105 ff.)1. Verhandlungsverfahren und wettbewerblicher Dialog stellen flexible Ver- 95 fahren dar, da es gerade zulässig ist, nach Angebotsabgabe mit den Bietern über die Angebote zu verhandeln. Bei den Verhandlungen ist allerdings darauf zu achten, dass diese Verhandlungen nicht so weit gehen dürfen, dass sich durch die verhandelten Änderungen der ursprünglich ausgeschriebene Beschaffungsgegenstand ändert2. Das Verhandlungsverfahren gliedert sich grds. in einen Teilnahmewettbe- 96 werb und das eigentliche Verhandlungsverfahren. Nur in engen Ausnahmefällen kann auf den Teilnahmewettbewerb verzichtet werden, § 3 EG Abs. 4 VOL/A (s. Rz. 100 ff.) b) Voraussetzungen § 3 EG Abs. 3 und 4 VOL/A sehen auf EU-Ebene zwei Varianten vor:

97

– Verhandlungsverfahren mit vorheriger Vergabebekanntmachung, – Verhandlungsverfahren ohne vorherige Vergabebekanntmachung. Auf nationaler Ebene sieht § 3 Abs. 5 VOL/A die freihändige Vergabe vor. Diese Vergabearten stellen – nach dem Willen des EU- und des deutschen 98 Gesetzgebers – die absolute Ausnahme dar. Die genau umschriebenen und abschließenden Ausnahmetatbestände werden, insbesondere durch den EuGH, entsprechend eng und restriktiv ausgelegt3. Das Verhandlungsverfahren mit vorheriger Vergabebekanntmachung ist 99 nur bei Vorliegen einer der drei folgenden Fallkonstellationen zulässig: 1 S. auch Rz. 9, 77 f.; Bischof, ITRB 2005, 181; Knauff, VergabeR 2004, 287; Ollmann, VergabeR 2005, 685; Lensdorf, CR 2006, 138; Bischof/Stoye, MMR 2006, 138. S. zur Bestandsaufnahme Dobmann, VergabeR 2013, 166. S. zur Beschaffung komplexer IT-Systeme auch Losch, VergabeR 2012, 352. 2 S. hierzu OLG Dresden, VergabeR 2005, 646, 650 f.; OLG Naumburg, Beschl. v. 1.9.2004 – 1 Verg 11/04; OLG Dresden, NZBau 2003, 118, 119. 3 S. Fett, in: Müller-Wrede, VOL/A Kommentar, § 3a Rz. 67 mit Verweis auf Erwägungsgrund Nr. 12 der Lieferkoordinierungsrichtlinie der EU sowie Rz. 68. S.a. Kaelble, in: Müller-Wrede, VOL/A Kommentar, 3. Aufl., § 3 EG Rz. 49 ff. m.w.N.; Weyand, Vergaberecht, Praxiskommentar, 3. Aufl., § 3 EG VOL/A Rz. 11456 ff.

Bischof

1173

N Rz. 100

Einzelprobleme

– In einem zuvor durchgeführten offenen oder nichtoffenen Verfahren kam es aus rein formalen Gründen nicht zur abschließenden Wertung samt Zuschlag; die Vergabebedingungen werden nicht grundlegend geändert (§ 3 EG Abs. 3a VOL/A). Bei Einbeziehung aller Unternehmer, die die Eignungskriterien erfüllt und form-/fristgerechte Angebote eingereicht hatten, darf ausnahmsweise auf einen Teilnahmewettbewerb verzichtet werden. – Die vorherige Festlegung eines Gesamtpreises ist bei einem Dienstleistungsauftrag nicht möglich (§ 3 EG Abs. 3b VOL/A). Dies dürfte wohl bei komplexen und neuartigen, erstmalig zu beschaffenden Leistungen der Fall sein (z.B. Planungsleistungen, neuartige Technologien)1. – Die hinreichend genaue Festlegung der vertraglichen Spezifikationen ist bei Dienstleistungsaufträgen, insbesondere geistig-schöpferischen, nicht möglich (§ 3 EG Abs. 3c VOL/A). Zu denken ist insbesondere an Vergaben, die auf einer funktionalen Leistungsbeschreibung § 8 EG Abs. 2 Nr. 2 VOL/A) basieren. Dies dürfte die für komplexe IT-Projekte2 am ehesten begründbare Ausnahmevorschrift sein, wobei auf eine klare Abgrenzung gegenüber dem Anwendungsbereich der VOF zu achten ist. 100

Das Verhandlungsverfahren ohne vorherige Vergabebekanntmachung ist nur unter den abschließenden, eng auszulegenden und meist schwer begründbaren Voraussetzungen des § 3 EG Abs. 4a bis j VOL/A zulässig, so z.B. falls – es sich um Forschungs- und Entwicklungsaufträge handelt (§ 3 EG Abs. 4b VOL/A), wobei kein weiterer kommerzieller Nebenzweck verfolgt werden darf. – bei einem Unternehmen ein Alleinstellungsmerkmal besteht (§ 3 EG Abs. 4c VOL/A) und somit andere Unternehmen nicht in Betracht kommen können. Diese Regelung ist bei der Vergabe von IT-Leistungen von wesentlicher Bedeutung, denn in dieser Vorschrift wird gerade auf Ausschließlichkeitsrechte abgestellt, wie sie das Urheberrecht dem Hersteller von Software gewährt: Nach § 3 EG Abs. 4c VOL/A kann der Auftraggeber im „stillen Verhandlungsverfahren“ vergeben, wenn der Auftrag wegen seiner technischen oder künstlerischen Besonderheiten oder auf Grund des Schutzes eines Ausschließlichkeitsrechts (z.B. Patent-, Urheberrecht) nur von einem bestimmten Unternehmen durchgeführt werden kann. Korrespondierend dazu kann eine freihändige Vergabe dann stattfinden, wenn für die Leistungen gewerbliche Schutzrechte zugunsten eines bestimmten Unternehmens bestehen und der Auftraggeber oder andere Unternehmen nicht zur Nutzung dieser Rechte befugt sind. Dies bedarf der ausführlichen Begründung unter konkreter Darstellung des vorliegenden fachlichen und technischen Sachverhalts, da der öffentliche 1 Sehr restriktive Handhabung dieser Regelung, daher praktisch wenig relevant (s. Fett, in: Müller/Wrede, VOL/A Kommentar, § 3a Rz. 90 ff.). 2 S. auch OLG Düsseldorf, Beschl. v. 13.11.2000 – Verg. 18/00, VergabE C-10-18/00v.

1174

Bischof

Rz. 102 N

Öffentliche Vergabe von IT-Leistungen

–

–

–

–

Auftraggeber die Beweislast für das Vorliegen dieses Ausnahmetatbestands trägt. dies unbedingt erforderlich ist, wenn aus zwingenden Gründen, die der Auftraggeber nicht voraussehen konnte, die vorgeschriebenen Fristen nicht eingehalten werden können, wobei die Umstände, die die zwingende Dringlichkeit begründen, auf keinen Fall dem Verantwortungsbereich des Auftraggebers entsprechen dürfen (§ 3 EG Abs. 4d VOL/A). es um die Vergabe von neuen Dienstleistungen geht, die in der Wiederholung gleichartiger Leistungen bestehen, die durch den gleichen Auftraggeber an das Unternehmen vergeben werden, das den ersten Auftrag erhalten hat, sofern sie einem Grundentwurf entsprechen, der bereits Gegenstand einer ersten Ausschreibung war (vgl. § 3 EG Abs. 4g VOL/A). bei zusätzliche Lieferungen zur teilweisen Erneuerung oder Erweiterung erfolgen sollen, sofern ein Unternehmenswechsel zu unterschiedlichen technischen Merkmalen und dies zur technischen Unvereinbarkeit oder unverhältnismäßigen technischen Schwierigkeiten führen würde (zudem ist der Auftrag zeitlich auf drei Jahre begrenzt) (gemäß § 3 EG Abs. 4e VOL/A). zusätzliche Dienstleistungen erforderlich sind, die zunächst nicht vorgesehen waren und nun unvorhersehbar erforderlich werden (maximaler Auftragswert: 50 % des Wert des Hauptauftrags) (§ 3 EG Abs. 4f VOL/A). Gerade bei der Softwareerstellung ermöglicht diese Vorschrift eine flexible Anpassung des ursprünglichen Auftrags ohne neues Vergabeverfahren an die während der Softwareerstellungsphase nahezu unvermeidliche Anpassung bzw. Erweiterung des ursprünglichen Auftrags.

Auf nationaler Ebene ergibt sich die Zulässigkeit der freihändigen Vergabe aus § 3 Abs. 5 lit. a–l VOL/A; diese Regelungen ähneln den Bestimmungen zur Zulässigkeit des Verhandlungsverfahrens ohne Teilnahmewettbewerb.

101

c) Ablauf des Verhandlungsverfahrens/der freihändigen Vergabe Das Verhandlungsverfahren mit Vergabebekanntmachung sieht die Durch- 102 führung eines Teilnahmewettbewerbs vor, in dem aus der sich meldenden Anzahl an Bewerbern anhand der veröffentlichten Eignungskriterien ausgewählt wird, wer zur Angebotsabgabe aufgefordert wird. Es müssen – geeignete Bewerber vorausgesetzt – mindestens drei Unternehmen zur Angebotsabgabe aufgefordert werden (vgl. 3 EG Abs. 5 VOL/A). Der Auftraggeber kann das Verhandlungsverfahren selbst in unterschiedlichen Phasen abwickeln, so dass die Zahl der Angebote/Bieter, über das/mit denen verhandelt wird, im Laufe des Verfahrens anhand der veröffentlichten Zuschlagskriterien verringert werden kann (vgl. § 3 Abs. 6 VOL/A). Beabsichtigt der Auftraggeber ein solches Vorgehen, so muss er dies entweder in der Bekanntmachung oder in den Vergabeunterlagen mitteilen. In einer Schlussphase muss aber noch echter Wettbewerb gewährleistet sein, falls

Bischof

1175

N Rz. 103

Einzelprobleme

eine ausreichende Anzahl geeigneter Unternehmen vorhanden ist, § 3 EG Abs. 6 Satz 2 VOL/A. 103

Das Verhandlungsverfahren ohne Vergabebekanntmachung eröffnet – wie der Name bereits impliziert – in aller Regel keinen Wettbewerb, da vielfach nur mit einem einzigen Bieter verhandelt wird, der für die Leistungserbringung in Frage kommt. Hierauf zielen auch die Zulässigkeitsvoraussetzungen ab. Regelungen zum formalen Ablauf dieses Verfahrens finden sich letztlich nicht, so dass der öffentliche Auftraggeber relativ frei in der Gestaltung ist, soweit er die vergaberechtlichen Grundsätze beachtet. Für die freihändige Vergabe auf nationaler Ebene gilt dies entsprechend

104

Das Verhandlungsverfahren/die freihändige Vergabe sind flexible Verfahren, da die VOL/A den Ablauf nicht im Detail regelt und reglementiert. Dies begründet natürlich keinen „rechtsfreien Raum“. Vielmehr muss auch das Verhandlungsverfahren unter Beachtung der vergaberechtlichen Grundsätze (vgl. Rz. 17 ff.) abgewickelt werden. Dies bedeutet vor allem, dass die Bieter stets über den gleichen Informationsstand verfügen müssen, für alle Bieter gleiche Fristen gelten, nicht zugunsten eines Bieters von den Bedingungen abgewichen werden kann u.ä. 6. Wettbewerblicher Dialog a) Einleitung

105

§ 101 Abs. 1 GWB benennt den wettbewerblichen Dialog als Verfahrensart für die Vergabe von öffentlichen Liefer-, Bau- und Dienstleistungsaufträgen, wobei § 101 Abs. 4 GWB ausdrücklich die Vorgabe der EU-Richtlinie, dass es sich um eine spezielle Verfahrensart für besonders komplexe Aufträge handelt, festschreibt. Weiter wird vorgeschrieben, dass eine Aufforderung zur Teilnahme zu erfolgen hat, der sich Verhandlungen mit ausgewählten Unternehmen über alle Einzelheiten des Auftrags anschließen1. Auch die Erörterung aller Aspekte des Auftrags mit jedem Bewerber ist in der EURichtlinie vorgesehen2. Die verfahrensrechtlichen Regelungen finden sich in § 3 EG Abs. 7 VOL/A, allerdings nicht umfassend. Diese Lücke wird durch die unmittelbare Anwendung der EU-Richtlinien geschlossen. Der Verhandlungsspielraum ist zwar größer als beim offenen oder nichtoffenen Verfahren, jedoch im Verhältnis zum Verhandlungsverfahren geringer. b) Anwendungsbereich

106

Der wettbewerbliche Dialog kann von der öffentlichen Hand nur unter den in § 3 EG Abs. 7 VOL/A genannten Voraussetzungen angewandt werden. Der Vorrang des offenen Verfahrens wurde durch das ÖPPG nicht verändert

1 Dieses Erfordernis ergibt sich aus Art. 29 Abs. 2 VKR. 2 Vgl. Beweggrund Nr. 31 sowie Art. 29 Abs. 3 S. 2 VKR.

1176

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 108 N

(vgl. § 101 Abs. 7 GWB)1. Auch gegenüber dem nichtoffenen Verfahren dürfte der wettbewerbliche Dialog subsidiär sein, was sich zumindest aus den Vorgaben der VKR ergibt. Nach der Gesetzesbegründung sind als komplexe Aufträge v.a. solche mit 107 komplexer Finanzierung zu verstehen, deren rechtliche und finanzielle Konstruktionen im Voraus nicht beschrieben werden können. Das Verfahren dürfte aber auch auf den IT-Bereich künftig Anwendung finden, v.a. wenn es nicht nur um die „bloße“ Beschaffung von Standardsoftware ohne weitere Leistungen der Bieter geht (z.B. x Lizenzen des Microsoft Office Pakets), sondern ein Projekt durchzuführen ist, in dem ggf. auf Basis von Standardsoftware weitere Leistungen wie Parametrisierung, Anpassung, Implementierung, Schulung sowie meist auch Pflegeleistungen zu erbringen sind. Diese Komplexität legt die Anwendung dieser Verfahrensart nahe. Typische Beispiele für den wettbewerblichen Dialog dürften künftig zusammenfassend etwa sein: – – – – –

Mautsysteme, große Bauprojekte, individuelle Softwarekonzepte, komplexe Softwareprojekte, Werbe- und Marketingkonzepte2.

Eine weite Auslegung der oben genannten Merkmale des „komplexen Vor- 108 habens“ wird sich aber dennoch verbieten, da der wettbewerbliche Dialog ebenso wie das Verhandlungsverfahren Ausnahmecharakter hat. Somit sind auch an die technische, rechtliche oder finanzielle Unklarheit hohe Anforderungen zu stellen3. Andererseits stellt die Gesetzesbegründung des ÖPPG nur geringe Anforderungen an die objektive Unmöglichkeit, da bereits unverhältnismäßig hoher Kosten- und/oder Zeitaufwand hierfür ausreichen sollen4. Dies dürfte dem Wortlaut der Richtlinie nicht entsprechen5.

1 „Subsidiäres Ausnahmeverfahren“: s. Prieß, Handbuch des europäischen Vergaberechts, 3. Aufl., S. 201; s.a. Knauff, VergabeR 2004, 289: Dieser leitet sogar noch die Subsidiarität des Verhandlungsverfahrens gegenüber dem wettbewerblichen Dialog aus Art. 30 Abs. 1 lit. a) VKR ab. Dies dürfte jedoch zu weitgehend sein; vielmehr dürften Verhandlungsverfahren und wettbewerblicher Dialog gleichwertig nebeneinander stehen. S. bereits einführend bei Rz. 78. 2 S. Erwägungsgrund (31) VKR. 3 Prieß, Handbuch des europäischen Vergaberechts, 3. Auflage, S. 202. 4 BT-Drucks. 15/5668, S. 13. 5 Zur Problematik Ollmann, VergabeR 2005, 685, 688; s. insbesondere zur Komplexität Lensdorf, CR 2006, 138; s.a. Heckmann, CR 2005, 711 zur Verrechtlichung des IT-Beschaffungswesens.

Bischof

1177

N Rz. 109

Einzelprobleme

c) Ablauf des Wettbewerblichen Dialogs aa) Auswahlphase 109

Das Verfahren beginnt mit einer europaweiten Bekanntmachung1, die einer (vereinfachten) funktionalen Ausschreibung ähnelt. Die Vergabestelle hat hierdurch ihre Bedürfnisse und Anforderungen bekannt zu machen; die Erläuterung dieser Anforderungen kann in der Bekanntmachung selbst oder in einer Beschreibung erfolgen, § 3 EG Abs. 7 Satz 2a VOL/A. Diese Beschreibung wird nur an diejenigen Unternehmen übermittelt werden, welche die in der Bekanntmachung angegebenen Eignungskriterien erfüllen und einen frist- und ordnungsgemäßen Teilnahmeantrag gestellt haben2.

110

Wie bei jedem Teilnahmewettbewerb sind die Bieter anhand der in der Bekanntmachung veröffentlichten Teilnahmebedingungen („wirtschaftliche, finanzielle und technische Leistungsfähigkeit“ i.S.v. Leistungsfähigkeit, Fachkunde und Zuverlässigkeit) auszuwählen3. Die ausgewählten Bieter (mindestens 3)4 werden dann zur Teilnahme am Dialog aufgefordert. Der Mindestinhalt dieser Aufforderung zur Teilnahme ergibt sich aus Art. 40 VKR. bb) Dialogphase

111

Im Anschluss an die im Teilnahmewettbewerb erfolgende Auswahl der in Frage kommenden Unternehmen und die Aufforderung zur Teilnahme wird der eigentliche Dialog mit diesen ausgewählten Bietern eröffnet. Ziel ist es, dass die öffentliche Hand ermittelt und festlegt, wie ihre Bedürfnisse am besten erfüllt werden können5. Daher kann mit einer Vielzahl von Unternehmen in mehreren Phasen über alle Einzelheiten des Auftrags verhandelt werden. Diese Möglichkeit umfassender Verhandlungen stellt die herausragende Neuerung im Rahmen der Reform des europäischen Vergaberechts dar6.

112

Über die Phasen kann die Bieterzahl verringert werden, wenn die Kriterien für eine solche Verringerung in der Vergabebekanntmachung oder in einer

1 Zu verwenden ist das Standardformular, vgl. http://simap.europa.eu. 2 Prieß, Handbuch des europäischen Vergaberechts, 3. Aufl., S. 203 zu Art. 29 Abs. 2 RL 2004/18/EU. Die Fristen ergeben sich aus direkter Anwendung des Art. 38 VKR, da weder in GWB, VgV noch VOL/A geregelt. S. zur Bewerbungsfrist auch Müller-Wrede/Kaelble, VOL/A, Kommentar, 2010, § 3 EG Rz. 251. 3 S. bislang §§ 7, 7a VOL/A; Art. 44 bis 52 VKR. Zum bestehenden Ermessen s. u.a. Müller-Wrede/Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 50 ff. 4 Art. 44 Abs. 3 VKR bzw. nun ausdrücklich in § 3 EG Abs. 7 S. 2a VOL/A genannt. 5 § 3 EG Abs. 7 S. 2b VOL/A. 6 S.a. Knauff, VergabeR 2004, 287, 291.

1178

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 114 N

Leistungsbeschreibung zuvor den Bietern bekannt gegeben wurden1. Die Möglichkeit dieser Unterteilung dient v.a. der Verfahrensökonomie. Dem schützenswerten Interesse der Bieter, dass ihre Geschäftsgeheimnisse 113 und das Firmen-Know-how nicht der Konkurrenz zufließen, soll dadurch Rechnung getragen werden, dass keine bestimmte Unternehmen begünstigende Informationen an die anderen Bieter und vertrauliche Informationen nur mit Zustimmung des jeweiligen Unternehmens weitergegeben werden dürfen (§ 3 EG Abs. 7 Satz 2b am Ende VOL/A)2. Das Vertrauen der Bieter in diese Vorgaben ist jedoch noch immer gering. Unternehmen bezweifeln einen ausreichend Schutz ihrer Konzepte, in die eben gerade das vorhandene Know-how, Visionen u.ä. einfließen3. Ebenso bestehen erhebliche Zweifel an der praktischen Durchsetzbarkeit des genannten Gebots. Zur Verhinderung einer missbräuchlichen Weiterverwendung der Lösungsvorschläge durch die Vergabestelle, z.B. bei Eigenoptimierung der Leistungsbeschreibung, könnte der Vorschlag, eine Vertraulichkeitserklärung von der öffentlichen Hand zu fordern4, hilfreich sein. Dies wird von der Praxis durchaus praktiziert: Sowohl der öffentliche Auftraggeber als auch die Bieter unterzeichnen Vertraulichkeitserklärungen oder der öffentliche Auftraggeber verpflichtet sich in seinen Ausschreibungsbedingungen zur Vertraulichkeit und fordert seinerseits von den Bietern mit Abgabe eines ersten Angebots die Übermittlung einer zu unterzeichnenden Vertraulichkeitserklärung. Dieses Vorgehen scheint sich zu bewähren. cc) Angebotsphase Gemäß § 3 EG Abs. 7 Satz 2d VOL/A haben die Auftraggeber die Dialogpha- 114 se zu beenden, wenn eine oder mehrere Lösung(en) gefunden ist/sind, die ihre Bedürfnisse erfüllt/erfüllen. Erst jetzt steht die detaillierte Leistungsbeschreibung für den zu vergebenden Auftrag fest. Mit Schließen des Dialogs werden die Bieter zur verbindlichen, endgültigen Angebotsabgabe (Best and Final Offer/Final Tender) auf Basis/Grundlage der eingereichten und in der Dialogphase näher ausgeführten Lösungen aufgefordert5. Was damit als Basis/Grundlage im Einzelnen genau gemeint ist, geht aus dieser Formulierung in § 3 EG Abs. 7 Satz 2d VOL/A jedoch nicht hervor6. An diesen Angeboten dürfen dann nur noch Klarstellungen, Präzisierungen und Fein1 Art 29 Abs. 4 VKR. Nun in § 3 EG Abs. 7 S. 2c VOL/A geregelt. Zur Frage des Ausscheidens eines Teilnehmers mit seiner Lösung s. Ollmann, VergabeR 2005, 686, 689. 2 Diese Regelung entspricht auch der Zielsetzung der VKR (Art. 2 sowie Art. 29 Abs. 3 Unterabs. 2). S. Prieß, Handbuch des europäischen Vergaberechts, 3. Aufl., S. 203; s.a. Werner/Freitag, NZBau 2000, 551, 552. 3 S. u.a. Opitz, NZBau 2003, 183, 191; Knauff, VergabeR 2004, 287, 293; Rechten, NZBau 2004, 366 (368); Schütte, 2004, 237; Möller, BauRB 2005, 376. 4 S. u.a. Ax/Schneider/Bischoff, Vergaberecht, 2006, § 11 Rz. 13 (S. 584). 5 § 6a Abs. 5 VgV n.F.; Art 29 Abs. 6 VKR. 6 S. hierzu die Kritik von Noch, BauRB 2005, 385, 390.

Bischof

1179

N Rz. 115

Einzelprobleme

abstimmungen erfolgen, aber keine grundlegenden Änderungen, vgl. § 3 EG Abs. 7 Satz 2d am Ende VOL/A. 115

Der Auftrag ist wiederum an dasjenige Unternehmen zu vergeben, das das wirtschaftlichste Angebot auf Basis der bekanntgegebenen Zuschlagskriterien abgegeben hat, § 3 EG Abs. 7 S. 2e) VOL/A1. Dieses Unternehmen wiederum kann dazu aufgefordert werden, einzelne Aspekte des Angebots zu erläutern oder im Angebot enthaltene Zusagen zu bestätigen. Dies darf jedoch weder zur Änderung wesentlicher Aspekte des Angebots oder gar der gesamten Ausschreibung führen, noch zu Wettbewerbsverzerrungen oder Diskriminierung anderer Unternehmen2. Auch hier gilt die Informationsund Wartepflicht des § 101a GWB.

IV. Vorbereitung von Vergabeverfahren3 1. Anlegung einer Vergabeakte, Vergabevermerk 116

Der öffentliche Auftraggeber sollte stets mit einer Nachprüfung des Vergabeverfahrens rechnen. Die vielfältigen „Tücken des Vergaberechts“ scheinen es oft unmöglich zu machen, in keine der typischen „Vergabefallen“ zu treten und sich somit angreifbar für Bieter zu machen. Aus diesem Grund sowie zur Einhaltung des vergaberechtlichen Transparenzgrundsatzes ist es erforderlich, von Anfang an alle möglichen, notwendigen, sinnvollen und zulässigen Vorbereitungen, nicht zuletzt zur Dokumentation des Verfahrens zu treffen. Hierzu gehört, von Anfang an eine geeignete und vor allem vollständige Dokumentation des gesamten Vergabeverfahrens in einer Vergabeakte zu führen.

117

Für das Vergabeverfahren hat der öffentliche Auftraggeber eine eigene Akte mit eigenem Aktenzeichen anzulegen und in dieser – wie vom Vergaberecht gefordert – das Verfahren, die einzelnen Verfahrensschritte, insbesondere die getroffenen Entscheidungen dokumentieren. So sollten gem. § 20 bzw. § 24 EG VOL/A insbesondere folgende Punkte in der Vergabeakte dokumentiert sein: – Festlegung der Wahl der Vergabeart sowie Begründung bei Abweichung vom offenen Verfahren; – Vergabeunterlagen inkl. Vertragsentwurf und Bewertungsmatrix für die Leistung und ggf. Eignung vor Veröffentlichung der Bekanntmachung; – Bekanntmachungen;

1 Vgl. Art. 29 Abs. 7 i.V.m. Art. 53 VKR. Vgl. zur Angebotswertung § 25 VOL/A; s. zu typischen Wertungsfehlern des Auftraggebers Ohle/Sebastiani, CR 2003, 510, 514 ff.; s.a. zur Wertung im Verhandlungsverfahren OLG Bremen, Beschl. v. 29.1.2004, BauRB 2004, 174. 2 § 3 EG Abs. 7 S. 2e) VOL/A; Art. 29 Abs. 7 S. 2 RL 2004/18/EG. 3 S.a. Bischof, ITRB 2012, 140.

1180

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 119 N

– Gründe, aufgrund derer von einer Losvergabe (ganz oder teilweise) abgesehen wurde und der Auftrag vielmehr insgesamt vergeben wurde; – Gründe, warum die Vorlage von Eignungsnachweisen erforderlich ist und warum ggf. über Eigenerklärungen hinausgehende Nachweise verlangt werden; – Namen und Anschriften der Interessenten bzw. Bieter; – jeglicher Kontakt zu den Bewerbern bzw. Bietern während des gesamten Vergabeverfahrens (z.B. Beantwortung von Fragen, Klarstellungen zu Angeboten etc.); – Begründung von Auswahl bzw. Ablehnung von Bewerbern/Bietern; – Niederschrift zur Angebotsöffnung; – Ergebnis der Angebotsprüfung; – Dokumentation der Prüfung und Wertung der Angebote; – Begründung der Zuschlagserteilung. Diese Punkte sind bereits ausschreibungsbegleitend1 zum jeweiligen Zeitpunkt zu dokumentieren. Sie fließen in den abschließenden Vergabevermerk ein (§ 20 bzw. § 24 EG VOL/A) bzw. bilden diesen letztlich. Die in § 24 EG Abs. 2 lit. a–j VOL/A aufgezählten Inhalte müssen mindestens im Vergabevermerk enthalten sein. Darüber hinaus ist jede maßgebliche Entscheidung und jeder Verfahrensschritt festzuhalten. Sinn und Zweck der Vergabeakte ist es, darin all diejenigen Dokumente be- 118 reit zu halten, die zwingend in einem Vergabeverfahren notwendig sind und die im Fall eines Nachprüfungsverfahrens (bei den Vergabekammern, den Gerichten oder dem Europäischen Gerichtshof) vorgelegt und geprüft werden müssten. Die Vergabeakte dient der Dokumentation des gesamten Vergabeverfahrens, d.h. jeder einzelnen Stufen eines Verfahrens, der getroffenen Maßnahmen sowie der Feststellungen und Begründungen der einzelnen getroffenen Entscheidungen. Gerade die Entscheidungen des öffentlichen Auftraggebers sollen transparent, nachvollziehbar und überprüfbar sein, um einen willkürfreien Wettbewerb zu garantieren. Die Vergabeakte sollte aber freigehalten werden von allen sonstigen schriftlichen Unterlagen, die zwar für die rein interne Projektarbeit der Vergabestelle unabdingbar, nicht aber im Vergabeverfahren erforderlich sind. Eine mangelhafte bzw. fehlende Dokumentation führt zwar nicht direkt zu 119 Ansprüchen des Bieters. Allerdings können im Fall einer Nachprüfung Dokumentationsmängel dazu führen, dass gegen erhobene Rügen aus dem Vergabevermerk heraus ggf. nicht nachvollziehbar argumentiert werden kann und so z.B. die Vergabekammer Verfahrensschritte nicht ordnungsgemäß nachvollziehen kann. In solchen Fällen mag zwar ggf. der mit Rüge geltend gemachte Vergabeverstoß selbst nicht vorgelegen haben, ist dies jedoch nicht überprüfbar, wird in aller Regel von der Vergabekammer das Verfahren in das Stadium vor dem Zeitpunkt des Dokumentationsmangels zurückver1 S. auch BayObLG v. 20.8.2001 – Verg 9/01, VergabeR 2001, 438.

Bischof

1181

N Rz. 120

Einzelprobleme

setzt. Dies kann u.U. zur Wiederholung der Wertung samt umfassender Dokumentation führen. Teils wurde bei erheblichen Dokumentationsdefiziten auch schon die Aufhebung des gesamten Verfahrens angeordnet1. Dem öffentlichen Auftraggeber ist daher zu raten, auf die Dokumentation des Verfahrens im Vergabevermerk ausreichendes Augenmerk zu legen und v.a. Beurteilungs- und Ermessensentscheidungen nachvollziehbar zu begründen. 2. Feststellung des Beschaffungsbedarfs 120

Üblicherweise geht es darum, mittels eines Schriftstücks zunächst die sog. „Verfahrens- und Beschaffungsidee“ darzulegen. Dies entspricht der „Erstellung einer Problembeschreibung“, die vor allem auf folgende Aspekte eingehen sollte: – auslösende Momente für das Vorhaben – bereits erkannte Schwachstellen – Randbedingungen – finanziell – gesetzlich – personell.

121

Grds. ist der öffentliche Auftraggeber frei, seinen Beschaffungsbedarf zu definieren und zu bemessen, wobei er die Grundsätze der Nichtdiskriminierung und des Wettbewerbs zu beachten hat. Er kann somit qualitativ und quantitativ eigenverantwortlich darüber entscheiden, welche Leistung er beschafft. Das Vergaberecht bestimmt somit nicht, was beschafft wird, sondern vielmehr, auf welche Art und Weise diese Beschaffung zu erfolgen hat2.

122

Initiiert ein öffentlicher Auftraggeber eine Ausschreibung, so muss er diese auch ernsthaft verfolgen, da er schließlich am Markt ein entsprechendes Vertrauen geweckt hat. Insbesondere sind Ausschreibungen für vergabefremde Zwecke (z.B. Markterkundung) nicht zulässig, § 2 EG Abs. 3 VOL/A. 3. Sicherstellung der Finanzierung und ggf. Genehmigung

123

Ein Vergabeverfahren darf nicht eingeleitet werden, wenn die Finanzfrage ungeklärt ist und damit die Frage des Zuschlags davon abhängig wäre, ob der Auftraggeber sich die Vergabe „leisten“ kann. Das Vorhandensein ausreichender Finanzmittel sollte sorgfältig dokumentiert werden. Sind ausreichende Finanzmittel nicht vorhanden, sondern von einer Drittfinanzierung (z.B. Fördermittel, Zuschüsse etc.) abhängig, sollte der öffentliche Auftrag1 S. Wiillenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, Teil. 9 Rz. 267 m.w.N. 2 S. Wiillenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, Teil. 9 Rz. 148 m.w.N.

1182

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 128 N

geber als Vergabestelle sich um feste Finanzierungszusagen bemühen und diese sorgfältig aufbewahren. Nur so könnte die Vergabestelle z.B. bei ausbleibender Finanzierung trotz Zusage beweisen, dass dies einen Grund für eine Aufhebung des Vergabeverfahrens darstellt, da die Ursache nicht bei der Vergabestelle zu suchen ist (vgl. § 17 bzw. § 20 EG VOL/A)1. Nicht erforderlich ist aber, dass bereits zum Zeitpunkt der Vergabebekannt- 124 machung die Haushaltsmittel bereitgestellt sind2. 4. Aufstellung der internen Organisation des Auftraggebers Der öffentliche Auftraggeber sollte für ein Vergabeverfahren ein geeignetes Team zusammenstellen, das – – – –

125

die Vergabeunterlagen erstellt, das Vergabeverfahren organisiert und koordiniert, die Bewertung und Auswahl der Bieter durchführt sowie an den Verhandlungen mit den Bietern über Preis, Leistung, vertragliche Gestaltung teilnimmt.

Dieses Team sollte über das erforderliche Know-how hinsichtlich der zu 126 vergebenden IT-Leistungen, der Geschäftsabläufe des Auftraggebers sowie zum Vergaberecht inkl. Verfahrensablauf verfügen. Oftmals wird dieses Wissen nicht vollumfänglich beim Auftraggeber vorhanden sein. In der Praxis lassen sich die Vergabestellen daher immer öfter durch externe Berater (z.B. IT-Consultants, IT-Sachverständige, z.T. Rechtsanwälte mit Schwerpunkt im IT- und Vergabebereich) unterstützen (s. sogleich Rz. 128 ff.). Sinnvollerweise begleitet dieses Team bzw. zumindest die maßgeblichen 127 Wissensträger aus diesem Team später auch die Durchführung des IT-Projekts durch den Auftragnehmer, dem der Zuschlag erteilt wurde. Auf diese Weise kann der öffentliche Auftraggeber auch sicherstellen, dass seinen Mitarbeitern die vom Auftragnehmer zu erbringenden Leistungen (Umfang der Leistungsbeschreibung), die hierzu bereits geführten Diskussionen im Verhandlungsverfahren sowie die vertragliche Grundlage, auf der die Ausführung basiert, bekannt sind und somit die Projektarbeit effizienter unterstützt, begleitet und ggf. auch kontrolliert werden kann3. 5. Externe Unterstützung des Auftraggebers/Projektantenproblematik Der öffentliche Auftraggeber hat oftmals nicht das erforderliche hausinter- 128 ne Know-how in Bezug auf die konkrete Beschreibung der zu vergebenden Leistungen, auf das Vergaberecht und die vertragliche Gestaltung. Die Notwendigkeit der Beiziehung externen Sachverstands mit entsprechenden Un1 S. Noch, in: Müller-Wrede, VOL/A Kommentar 2001, § 16 Rz. 11 ff. m.w.N. 2 S. Eberstein, in: Daub/Eberstein, VOL/A Kommentar, 2000, § 16 Rz. 6. 3 S.a. Bischof, Vorbereitung einer Ausschreibung, ITRB 2012, 140.

Bischof

1183

N Rz. 129

Einzelprobleme

terstützungsleistungen kann zu unterschiedlichen Zeitpunkten, nämlich bei der Vorbereitung und bei der Durchführung der Vergabe, auftreten. Der Auftraggeber muss beim Einsatz Externer darauf achten, dass er die Entscheidungen im Vergabeverfahren selbst zu treffen hat. Er darf sich nur zur Vorbereitung dieser Entscheidungen oder auch zur Erstellung der Leistungsbeschreibung externer Berater bedienen. Die letztliche Entscheidungsgewalt und Ausübung muss aber beim Auftraggeber liegen1. 129

Wenn sich ein solcher externer Berater später an dem Vergabeverfahren beteiligt, an dessen Vorbereitung er selbst mitgewirkt hat, könnten sich Wettbewerbsvorsprünge einstellen, da der Berater wohl unzweifelhaft einen deutlichen Informationssprung besitzt (ob er diesen auch tatsächlich nutzt oder nutzen kann, ist hierbei zunächst unbeachtlich). Dennoch hat die Rechtsprechung (v.a. der EuGH2) anerkannt, dass es unzulässig ist, grundsätzlich ein Beteiligungsverbot sog. Projektanten auszusprechen. Vielmehr muss eine Einzelfallentscheidung erfolgen3. Der Auftraggeber ist gem. § 6 Abs. 6 bzw. § 6 EG Abs. 7 VOL/A verpflichtet, sicherzustellen, dass der Wettbewerb durch den Einsatz von Projektanten nicht verfälscht wird.

130

Wie ein Ausgleich etwaiger Wissensvorsprünge zu erfolgen hat bzw. wie der öffentliche Auftraggeber die Wettbewerbsverfälschung zu verhindern hat, ergibt sich aus den Bestimmungen von GWB und VOL/A hingegen nicht. In der Praxis hat sich bewährt, durch Workshops und/oder die Einrichtung von Datenräumen etwaige Wissensvorsprünge auszugleichen, damit alle Bieter wirklich über den gleichen Informationsstand verfügen. Um die (Vor-)Arbeit des Projektanten entsprechend aufbereiten zu können, ist eine detaillierte Dokumentation der Tätigkeiten des Projektanten daher unabweisbar4. 6. Marktanalyse

131

Ein öffentlicher Auftraggeber war gem. § 4 Nr. 1 VOL/A a.F. verpflichtet, bei Abweichung vom offenen Verfahren vor Beginn des Vergabeverfahrens eine Markterkundung durchzuführen bzw. eine Marktübersicht zu erstellen. Zwar ist die Regelung des § 4 Nr. 1 VOL/A in der Neufassung entfallen. Eine Marktanalyse/Marktübersicht wird sich der öffentliche Auftraggeber aber dennoch dann verschaffen müssen, wenn er prüft, welches Vergabeverfahren er beschreiten möchte bzw. wenn er beabsichtigt, vom offenen Verfahren abzuweichen. Gerade die Ausnahmebestimmungen erfordern meist eine Marktkenntnis des öffentlichen Auftraggebers, die dieser sich eigen1 S. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 268 ff. m.w.N. 2 EuGH, Urt. v. 3.3.2005, C-21/03 und C-347/03. 3 S. Ohle/von dem Bussche, CR 2004, 791 ff. zum Risiko des Ausschlusses und zu geeigneten Gegenmaßnahmen für Auftraggeber und Auftragnehmer. S.a. Bischof/Stoye, MMR 2006, 137 ff. 4 S.a. Goodarzi, in: Lehmann/Meents, Handbuch des Fachanwalts Informationstechnologierecht, 2. Aufl., Kapitel 24 Rz. 55 ff.

1184

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 134 N

ständig verschaffen muss, um die Ausnahmevorschriften auch begründen zu können1. Um die Marktanalyse durchzuführen, können z.B. als Informationsquellen 132 genutzt werden: – – – – – – –

Fachzeitschriften, Informationen aus dem Internet, Veröffentlichungen, Messen, Ausstellungen, Anbieterinformationen/-präsentationen, Anfragen bei anderen öffentlichen Auftraggebern, Anfragen bei Fachleuten, Voranfragen bei Firmen etc.

Die Ergebnisse sind schriftlich darzustellen, wobei die auf dem Markt befindlichen Anbieter samt Kurzdarstellung des jeweiligen Produktes unter Angabe der Quellen, aus denen diese Informationen gewonnen wurden, deutlich werden sollen. Ein „Ranking“ darf sich aus einer solchen Übersicht jedoch keinesfalls erge- 133 ben, da dies weit über die Zielsetzung der Markterkundung hinausgeht und bereits eine Bewertung vorwegnimmt, die dem eigentlichen „öffentlichen Teil“ des Vergabeverfahrens vorbehalten ist. Unzulässig ist ebenfalls, dass der Auftraggeber sich lediglich eine Marktübersicht verschafft, ohne ernsthaft an eine Vergabe zu denken; es gilt § 16 VOL/A2. 7. Erstellung der Vergabeunterlagen Unter Vergabeunterlagen ist die Gesamtheit aller Aufzeichnungen zu ver- 134 stehen, die eine Vergabestelle für eine anstehende Auftragsvergabe anfertigt und Bewerbern zuleitet3. Die Regelungen in § 8 Abs. 1 bzw. § 9 EG Abs. 1 VOL/A definieren Vergabeunterlagen als alle Angaben, die erforderlich sind, um eine Entscheidung zur Teilnahme am Vergabeverfahren oder zur Angebotsabgabe zu ermöglichen. Diese Unterlagen bestehen in der Regel aus – Anschreiben (Aufforderung zur Angebotsabgabe) (§ 8 Abs. 1a VOL/A, § 9 EG Abs. 1a VOL/A); – Bewerbungsbedingungen als Beschreibung der Einzelheiten der Durchführung des Verfahrens (§ 8 Abs. 1b bzw. § 9 EG Abs. 1b VOL/A), wobei die Angabe der Zuschlagskriterien als Bestandteil der Bewerbungsbedingungen gefordert wird, falls die Vergabebekanntmachung diese nicht enthält;

1 S. hierzu unter Rz. 89 ff. und 97 ff. 2 S. von Baum, in: Müller-Wrede, VOL/A, Kommentar, § 4 Rz. 6; Müller, in: Daub/ Eberstein, VOL/A, § 16 Rz. 14; Ingenstau/Korbion, VOB/A, § 16 Rz. 9. 3 S. zu einer denkbaren Gliederung der Vergabeunterlagen: UfAB V, Version 2.0, Kapitel 4.16.2 sowie 4.16.3 und 4.16.4 (zum Aufbau).

Bischof

1185

N Rz. 135

Einzelprobleme

– Vertragsunterlagen bestehend aus Leistungsbeschreibung (§ 7 bzw. § 8 EG VOL/A) sowie den Vertragsbedingungen (§ 9 bzw. § 11 EG VOL/A). – Die Ausarbeitung hat unter Beachtung der Vorschriften der §§ 6–9 bzw. §§ 6–11 EG VOL/A zu erfolgen, hierher gehören daher insbesondere – Eignungskriterien zur Prüfung von Fachkunde, Leistungsfähigkeit und Zuverlässigkeit (§ 6 bzw. §§ 6, 7 EG VOL/A)1; – die Zuschlags-/Bewertungskriterien nach § 8 Abs. 1b bzw. § 9 EG Abs. 1b VOL/A2. – § 8 Abs. 1b VOL/A bestimmt „einschließlich der Angabe der Zuschlagskriterien, sofern nicht in der Bekanntmachung bereits genannt“. – § 9 EG Abs. 1b VOL/A bestimmt „einschließlich der Angabe der Zuschlagskriterien und deren Gewichtung, sofern nicht in der Bekanntmachung bereits genannt“. 135

Bei EU-weiten Vergaben hat das Anschreiben gem. § 10 EG Abs. 2 VOL/A zudem noch folgende Angaben zu enthalten: – beim nichtoffenen Verfahren und Verhandlungsverfahren mit Teilnahmewettbewerb: Hinweis auf die veröffentlichte Vergabebekanntmachung; – beim wettbewerblichen Dialog: Termin und Ort des Beginns der Dialogphase; – die zuständige Vergabekammer; – soweit nicht bereits in der Vergabebekanntmachung genannt: – alle vorgesehenen Zuschlagskriterien, einschließlich deren Gewichtung oder, sofern diese aus nachvollziehbaren Gründen nicht angegeben werden können (was wiederum zu dokumentieren ist), die absteigende Reihenfolge der ihnen zuerkannten Bedeutung; – die Absicht, ein Verhandlungsverfahren oder ein wettbewerblicher Dialog in verschiedenen Phasen abzuwickeln, um die Zahl der Angebote zu verringern.

136

Die Bewerbungsbedingungen legen die verfahrensbezogenen Anforderungen an das Vergabeverfahren fest und sollten von allen Bietern sorgfältig gelesen werden, denn dieses Dokument enthält in aller Regel insbesondere die Fristen für die Einreichung von Angeboten sowie die Abgabe von Nachweisen, ebenso auch die Eignungs- und Zuschlagskriterien (ggf. mit Verweisen auf Anlagen). Meist enthält dieses Dokument auch Hinweise zur Anzahl der Verhandlungsrunden bei einem Verhandlungsverfahren und zum grundsätzlichen Vorgehen, das der Auftraggeber beabsichtigt (z.B. Beschränkungen der Teilnehmeranzahl für die Verhandlungen aus Platzgründen u.ä).

137

Wann der maßgebliche Zeitpunkt der Fertigstellung aller Vergabeunterlagen ist, wird in der einschlägigen Literatur nicht absolut eindeutig beantwortet. 1 S. hierzu im Detail nachfolgend unter Rz. 210 ff. 2 S. auch unter Rz. 155 ff., 254.

1186

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 141 N

Letztlich wird man aber der Darstellung, dass bestimmte Vergabeunterlagen erforderlich sind, die die Entscheidung zur Verfahrensteilnahme bzw. Angebotsabgabe ermöglichen sollen, schließen können, dass der Zeitpunkt für die Erstellung bestimmter erforderlicher Dokumente jeweils von der betroffenen „Verfahrensphase“ abhängt. So ist zu differenzieren, wann welche Unterlagen vorliegen müssen. Die Fertigstellung aller Unterlagen noch vor Veröffentlichung der Vergabebekanntmachung wird daher wohl nicht mehr gefordert werden können, wie dies zur Vorgängervorschrift des § 16 Nr. 1 VOL/A noch diskutiert worden war. Spätere Änderungen der Vergabeunterlagen durch den Auftraggeber im Ver- 138 gabeverfahren sind aufgrund der Selbstbindung des Auftraggebers nicht ohne Weiteres zulässig. Dies kann jedoch dann zulässig sein, wenn und soweit alle Interessenten die gleichen Chancen haben, auf die veränderte Situation zu reagieren. Dem Auftraggeber ist zu empfehlen, bei solchen aus seiner Sicht notwendigen Änderungen alle Bieter zu informieren und deren Zustimmung zu den Änderungen einzuholen. Dies schafft für die Vergabestelle die notwendige Rechtssicherheit für das weitere Verfahren. 8. Leistungsbeschreibung a) Bedeutung Die Leistungsbeschreibung ist ein wesentlicher Kern der Vergabeunterla- 139 gen, da sie zum einen die spätere Vergleichbarkeit der Angebote gewährleisten soll und zum anderen die vom Bieter zu realisierenden Leistungsinhalte darstellt und damit Maßstab für die Beurteilung der Vertragserfüllung sowie etwaiger Ansprüche wegen Sach- und Rechtsmängeln ist1. b) Anforderungen an die Leistungsbeschreibung § 7 bzw. § 8 EG VOL/A regeln die Anforderungen an die Leistungsbeschreibung: Die zu erbringenden IT-Leistungen müssen u.a. eindeutig und so erschöpfend beschrieben sein, dass alle Bieter die Beschreibung im gleichen Sinne verstehen und die Angebote selbst vergleichbar sind.

140

Dies macht nicht bereits die Aufnahme von Optionen, d.h. von Wahl- 141 oder Alternativpositionen und Bedarfs- oder Eventualpositionen neben den Grundpositionen, von vornherein unzulässig. Allerdings dürfen die Optionen gegenüber den Grundpositionen kein solches Gewicht in der Wertung erhalten, dass sie deren Bedeutung gleich kommen oder diese gar verdrängen. Ist dies der Fall, ist eine Option unzulässig, da keine eindeutige und erschöpfende Leistungsbeschreibung mehr vorliegt2. Welchen maximalen 1 S.a. Bischof, ITRB 2010, 192. 2 S. Kulartz/Steding, IT-Leistungen, Fehlerfreie Ausschreibungen und rechtssicher Vertragsinhalte, Ziff. 7.1 (S. 38); Noch, Vergaberecht kompakt, S. 269 ff.; Kulartz, in: Daub/Eberstein, VOL/A, § 25 Rz. 47; OLG Saarbrücken, NZBau 2000, 158 ff.

Bischof

1187

N Rz. 142

Einzelprobleme

Umfang Bedarfspositionen haben dürfen, ist nicht abschließend geklärt, wobei überwiegend von einer 10 %-Grenze in Bezug auf den geschätzten Auftragswert ausgegangen wird1. 142

Hervorzuheben ist insbesondere, dass die Leistungsbeschreibungen produkt- und lösungsneutral zu gestalten sind2. IT-bezogen heißt dies, dass in der Leistungsbeschreibung möglichst sämtliche Anforderungen an die zu vergebende Lösung dargestellt sein müssen. Da die letztlich zum Einsatz kommende Lösung noch unbekannt und damit unklar ist, mit welchem Abdeckungsgrad von Standardsoftware, Parametrisierung, Anpassungen, Erweiterungen die geforderte Lösung realisiert wird, empfiehlt sich dringend, eine fachliche Feinspezifikation vorzunehmen, in der Funktionalität, Geschäftsprozesse, Anforderungen an Schnittstellen und Migration von Altdaten umfassend dargestellt werden.

143

Grds. ist die Nennung von Marken-/Produktnamen nicht gestattet. Dies ist lediglich ausnahmsweise erlaubt, wenn die Beschreibung durch hinreichend genaue, allgemein verständliche Bezeichnungen nicht möglich ist, selbst dann aber nur mit dem Zusatz „oder gleichwertig“ (vgl. § 7 Abs. 4 bzw. § 8 EG Abs. 2 Nr. 1e und Abs. 7 VOL/A).

144

Die Vergaberechtsreform lässt durch die Neufassung des § 97 Abs. 4 GWB auch zu, dass für die Auftragsausführung zusätzliche Anforderungen an die Unternehmen gestellt werden können. Diese stellen – nach dem Wortlaut der Gesetzesbegründung – „konkrete Verhaltensanweisungen an das ausführende Unternehmen für die Ausführung des Auftrags dar“3. Sie dienen zudem der Umsetzung der Bestimmungen der Art. 26 VKR und Art. 38 SKR. Solche zusätzlichen Anforderungen an Auftragnehmer für die Ausführung des Auftrags stellen – entgegen der Stellung im Gesetz gerade keine Eignungskriterien dar. Vielmehr sieht der deutsche Gesetzgeber in ihnen Leistungsanforderungen, die daher Gegenstand der Leistungsbeschreibung sind und somit allen Bietern zu Beginn des Vergabeverfahrens bekannt gegeben werden müssen4. Als solche zusätzlichen Anforderungen werden in § 97 Abs. 4 Satz 2 GWB genannt:

1 Vgl. Noch, Vergaberecht kompakt, S. 271 f. m.w.N. 2 H.M. im Vergaberecht. S. auch BayObLG v. 15.9.2004 – Verg 026/03, BauRB 2005, 19 (baurechtlich). S. zur Problematik der Vergabe von Open Source-Software Heckmann, CR 2004, 401 ff.; Müller/Gerlach, CR 2005, 87 ff. 3 Die Nichteinhaltung z.B. durch Nichtabgabe geforderter Erklärungen bzw. durch gegenteilige Aussagen im Angebot vermag den Ausschluss des Angebots zu begründen. Stellt sich die Nichteinhaltung erst bei Ausführung heraus, hat dies v.a. vertragsrechtliche Konsequenzen (hier ist an Rücktritts-/Kündigungsrechte bzw. Vertragsstrafenregelungen im jeweiligen Vertrag zu denken). 4 Die deutsche Umsetzung wird kritisiert, da weder die EU-Richtlinien noch EuGH von Leistungsanforderungen ausgehen, sondern lediglich Auftragsausführungsbestimmungen darin sehen (so Varga, VergabeR 2009, 535, 542).

1188

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 148 N

– soziale Aspekte1, – umweltbezogene Aspekte2, – innovative Aspekte. c) Arten von Leistungsbeschreibungen Es gibt folgende Arten von Leistungsbeschreibungen3: – – – –

145

konventionell, konstruktiv, funktional, Mischformen.

Die konventionelle Leistungsbeschreibung oder auch Leistungsbeschrei- 146 bung mittels verkehrsüblicher Bezeichnungen (§ 8 Nr. 2 Abs. 1 VOL/A) kommt vor allem bei standardisierten, handelsüblichen Leistungsgegenständen in Betracht. Diese Art trifft in der Regel zu auf die Lieferung von Computerbildschirmen, Tastaturen, Mäusen oder auch „Standard-PC’s“ (d.h. inklusive des üblichen Zubehörs), sonstige Hardware oder auch Standardsoftware. Unter der konstruktiven Leistungsbeschreibung (§ 8 Nr. 2 Abs. 1b VOL/A) 147 ist die Beschreibung der Leistung nach ihren wesentlichen Merkmalen und konstruktiven Einzelheiten zu verstehen. Sie kommt in der Regel nur in Betracht, wenn die Bedarfsvorstellungen des öffentlichen Auftraggebers bis in die Einzelheiten festliegen. Dies dürfte jedoch in der Regel bei Beschaffung von IT-Leistungen nur selten der Fall sein. Gerade bei umfangreichen, komplexen IT-Projekten wird daher meist auf 148 die funktionale Leistungsbeschreibung (§ 8 Nr. 2 Abs. 1a VOL/A) zurückgegriffen. Hierunter ist die Bezeichnung der Leistung durch eine Darstellung ihres Zwecks, ihrer Funktion sowie der an sie gestellten sonstigen Anforderungen zu verstehen. Die konstruktive Lösung wird dabei weitgehend den Bietern aufgrund deren Know-hows überlassen. Auch die funktionale Leistungsbeschreibung unterliegt einem gewissen Bestimmtheitserfordernis: Die Kriterien für die Angebotswertung, das Leistungsziel, die Rahmenbedingungen sowie die wesentlichen Einzelheiten der Leistung müssen auch bei der nur ausnahmsweise zulässigen funktionalen Leistungsbeschreibung bekannt sein4. 1 S.a. zu sozialen Aspekten Varga, VergabeR 2009, 535; Mohr, VergabeR 2009, 543. 2 S. zur Energieeffizienz Bischof, ITRB 2011, 140. 3 S. u.a. Ohle/Sebastiani, CR 2003, 511, 513 ff.; Noch, in: Müller-Wrede, VOL/A, Kommentar, § 8 Rz. 13 ff. und 46 ff.; Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 8 Rz. 43 ff. 4 OLG Düsseldorf, Beschl. v. 14.2.2001 – Verg 14/00 – Vergaberechts-Report 3/2001, S. 3.

Bischof

1189

N Rz. 149 149

Einzelprobleme

Auch Kombinationen der verschiedenen Arten von Leistungsbeschreibung sind möglich (§ 7 Abs. 2 Satz 2c bzw. § 8 EG Abs. 2 Nr. 3 VOL/A). d) Erstellung der Leistungsbeschreibung

150

Gerade die Erstellung der Leistungsbeschreibung erfordert die Beteiligung aller Organisationsbereiche und der jeweiligen Berufsgruppen des Auftraggebers – nicht nur, um alle relevanten Anforderungen zu erfassen, sondern auch, um die spätere Akzeptanz bei Einführung der neuen Lösung zu steigern. Sinnvoll ist gerade hier die Unterstützung durch externe Berater1.

151

Technisch empfiehlt sich zur Erstellung der Leistungsbeschreibung der Einsatz eines Tabellenkalkulationsprogramms, da sich hierdurch Bereiche vor nicht gewollten Änderungen schützen lassen und später die Auswertung von beantworteten Anforderungen, insbesondere bei (teilweiser) Verknüpfung mit den Zuschlagskriterien, erheblich einfacher ist. Lassen sich nicht alle Anforderungen in Tabellenform auflisten, so sollten diese in einem weiteren Dokument, z.B. als anwendungsbezogenes Konzept, beschrieben werden. e) Überprüfung der Erfüllung der Anforderungen in der Leistungsbeschreibung im Vergabeverfahren

152

Zur Überprüfung der Angaben der Bieter zur Leistungsbeschreibung sollte ein Verfahren vorgesehen werden, in dem der Bieter praktisch zeigen muss, dass die von ihm angebotene Softwarelösung die Anforderungen erfüllen kann (z.B. Vorführung an einem mit ausreichenden Daten versehenen Echtsystem auf Basis von „Echtfällen“ sowie Überlassung dieses Systems zu Testzwecken an den Auftraggeber). Dieses Verfahren („Proof of Solution“), das in die Bewertung/Zuschlagskriterien mit einfließen sollte, ist zur Transparenz des Verfahrens sowie zur Gleichbehandlung aller Bieter bereits in den Vergabeunterlagen zu beschreiben. Gibt der öffentliche Auftraggeber eine solche Vorgehensweise an, ist er gegenüber den Bietern hieran auch gebunden und kann somit nicht mehr davon abweichen, es sei denn, alle beteiligten Bietern stimmen dem zu2. f) Fehlerhafte Leistungsbeschreibungen

153

Ein Verstoß gegen die Anforderungen aus § 7 bzw. § 8 EG VOL/A stellt eine rügefähige Verletzung vergaberechtlicher Bestimmungen dar, die ein Bieter auch im Weg des Nachprüfungsverfahrens verfolgen kann. Ziel dabei ist die vergaberechtskonforme Umgestaltung der Leistungsbeschreibung.

154

Macht der Auftraggeber eine erkennbar fehlerhafte Leistungsbeschreibung zum Gegenstand seiner Ausschreibung, so löst dies für sich gesehen keine 1 S. bereits Rz. 128 ff. 2 S. OLG Düsseldorf v. 9.4.2003 – Verg 43/02, BauRB 2004, 50.

1190

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 158 N

Kompensations- oder Schadensersatzansprüche der Bieter aus, es sei denn, ein anspruchstellender Bieter durfte auf die Einhaltung der Vergabebestimmungen vertrauen und hat den Verstoß gegen die Ausschreibungspflichten nicht erkannt. Mit anderen Worten: In der Regel scheiden monetäre Ansprüche bei einem Verstoß aus. Die Bieter haben lediglich einen Anspruch darauf, dass der Auftraggeber die Leistungsbeschreibung „nachbessert“1. 9. Zuschlagskriterien Zuschlagskriterien sind die entscheidenden Wertungsmerkmale für die Ermittlung des wirtschaftlichsten Angebots und demnach für die Erteilung des Zuschlags.

155

§ 9 EG Abs. 1b VOL/A verpflichtet dazu, dass die Zuschlagskriterien und deren Gewichtung entweder in den Bewerbungs-/Ausschreibungsbedingungen oder in der Vergabebekanntmachung zu nennen sind. Gleiches gilt für den nationalen Bereich gemäß § 8 Abs. 1b VOL/A, jedoch ohne ausdrückliche Erwähnung der Gewichtung. Der Auftraggeber muss dabei einerseits die Wertungskriterien möglichst genau festlegen, um die Chancengleichheit zu gewährleisten, andererseits möchte er aber einen größtmöglichen Wertungsspielraum bewahren. Der Auftraggeber ist bei Festlegung der Zuschlagskriterien nicht völlig frei, sondern hat bestimmte Grenzen des Vergaberechts zu beachten.

156

Letztlich können lediglich zwei Maßstäbe für die Vergabeentscheidung rele- 157 vant sein: der niedrigste Preis oder das wirtschaftlich günstigste Angebot2. Bestimmt ein Auftraggeber keine Kriterien, so gilt allein der Preis. Bei manchen Vergaben wird dies sicherlich auch die beste Variante sein, v.a. wenn es keinerlei Unterschiede in der Leistung selbst geben kann und somit letztlich auch keine anderen Kriterien berücksichtigt werden können. Zu beachten ist auch, dass die Rechtsprechung davon ausgeht, dass – bei Festlegung von weiteren Kriterien – auf den Preis als Kriterium nicht verzichtet werden kann und zudem der Preis auch in der Bedeutung nicht zu niedrig angesetzt werden darf (z.B. innerhalb einer Bewertungsmatrix mit mindestens 30 % im Verhältnis zu weiteren Kriterien)3. Für die Festlegung der Kriterien sind die Umstände des jeweiligen Vergabe- 158 falles maßgeblich, aus denen sich ergibt, welche Anforderungen an die Lieferung oder Leistungen gestellt werden4, was letztlich eine fachliche Beurteilung darstellt.

1 S. BGH v. 1.8.2006 – X ZR 146/03, VergabeR 2007, 194. 2 Vgl. von Baum, in: Müller-Wrede, VOL/A Kommentar, § 9a Rz. 8. 3 S.u.a. VK Lüneburg v. 8.5.2006 – VgK.07/2005; VK Brandenburg v. 14.6.2007 – 1 VK 17/07. S.a. OLG Dresden, VergabeR 2001, 41 ff. 4 S. Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 9a Rz. 7.

Bischof

1191

N Rz. 159 159

Einzelprobleme

Unter Berücksichtigung der europäischen Vorgaben darf es sich nur um ausschließlich auftragsbezogene Kriterien handeln. Beispielhaft werden in den dem Vergaberecht zugrunde liegenden EU-Richtlinien (Dienstleistungs- sowie Sektorenrichtlinie) folgende maßgeblichen Wertungskriterien (umgesetzt in § 16 Abs. 8 bzw. § 19 EG Abs. 9 VOL/A) aufgestellt: – – – – – – – – – – – – –

Lieferzeit Ausführungsdauer Betriebskosten Rentabilität Qualität Ästhetik Zweckmäßigkeit technischer Wert Kundendienst technische Hilfe Verpflichtung hinsichtlich Ersatzteilen Versorgungssicherheit Preis.

160

Die Reihenfolge der Kriterien gibt Auskunft über ihre Gewichtung, d.h. welche Wertungsmerkmale vorrangig vor anderen zu beachten sind und bei der Ermittlung des wirtschaftlichsten Angebots den Ausschlag geben. Die Gewichtung ist auftragsbezogen zu ermitteln und festzulegen. Die Reihenfolge der den Kriterien zuerkannten Bedeutung ist ausdrücklich als solche zu bezeichnen, um sie vom Fall einer bloßen Aufzählung abzugrenzen1. Die Gewichtung ist ausreichend. Nicht gefordert ist eine Festlegung der Bedeutung im Verhältnis zu anderen Kriterien, beispielsweise durch prozentuale Angabe oder durch Veröffentlichung eines Punktesystems hinsichtlich der einzelnen Kriterien2.

161

Bewährt hat sich die Erstellung einer Bewertungsmatrix3, in der die Unterkriterien entsprechend einer vorher festgelegten Gewichtung aufgeführt werden. Diese orientiert sich an den benannten Kriterien, ihrer Gewichtung und dem Zielerfüllungsgrad (gegebenenfalls in Form einer Benotung nach Schulsystem oder mittels Punktesystemen). Diese Gewichtung muss nach herrschender Auffassung, die sich dabei auf die Formulierung in Art. 26 LKR beruft, nicht in der Bekanntmachung oder den Vergabeunterlagen vorab bekannt gegeben werden.

162

Gegenteiliger Auffassung ist allerdings die Vergabekammer des Bundes (Beschluss v. 9.5.2000 – VK A-24/99). Auch der EuGH hat in einem Urteil – al1 S. Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 9a Rz. 8. 2 S. von Baum, in: Müller-Wrede, VOL/A, Kommentar, § 9a Rz. 16. 3 Der Bewertungsmatrix dürfen nur eindeutige Begriffe zu Grunde liegen: OLG Bremen, BauRB 2004, 173.

1192

Bischof

Rz. 164 N

Öffentliche Vergabe von IT-Leistungen

lerdings in Bausachen – die Veröffentlichung der Bewertungsmatrix gefordert (EuGH v. 12.12.2002 – Rs. C-470/99). Die Rechtsprechung geht davon aus, dass die Veröffentlichung zumindest erfolgen muss, wenn die Bewertungsmatrix vor Versand der Vergabeunterlagen bereits erstellt war1. Durch die Regelung in § 9 EG Abs. 1b VOL/A steht die Verpflichtung, die Gewichtung der Zuschlagskriterien anzugeben, fest. Somit wird die Bewertungsmatrix immer dann zu erstellen und anzugeben sein, wenn sie zum Verständnis der Gewichtung erforderlich ist. Dann kann auch die Angabe einer Formel notwendig werden2. Goodarzi3 stellt eine einfache Bewertungsmatrix wie folgt dar: Zuschlagskriterien

Gewichtung (%)

Preis

40 %

Ausbaufähigkeit des Systems

30 %

Anwenderfreundlichkeit

25 %

Lieferfrist Summe:

Punktewertung: 1 = sehr gut 2 = gut 3 = befriedigend 4 = ausreichend 5 = mangelhaft

163

Bewertungsergebnis: Gewichtung × Punktewertung

5% 100 %

Weitere Bewertungsmethoden (einfache und erweiterte Richtwertmethode) 164 mit entsprechenden Mustern sind in der „Unterlage für Ausschreibung und Bewertung von IT-Leistungen“ (UfAB V, Version 2.0) zu finden. Die Verwendung dieser Bewertungsmatrizen ist für solche Stellen verbindlich, für die (z.B. durch Verwaltungsanweisung) auch die Anwendung der UfAB verbindlich vorgeschrieben wurde. Beide Methoden sehen die Festlegung von Kriterien in Haupt- und Untergruppen vor. Weiter werden sog. A-Kriterien bestimmt, die zwingend erfüllt werden müssen und bei Nichterfüllung zum Ausschluss führen würden. Daneben sind B-Kriterien vorgesehen, die bewertet werden. Insofern können auch sog. Mindestpunktzahlen vorgegeben werden. Bei beiden Methoden wird ein Preis-/Leistungsverhältnis gebildet, welches für die Bestimmung des wirtschaftlichsten Angebots maßgeblich ist. Die erweiterte Richtwertmethode sieht zudem noch vor, dass – zur weiteren Differenzierung – innerhalb einer bestimmten, zuvor definierten und den Bietern bekannt gegebenen Schwankungsbreite des Preis-/Leistungsver1 Vgl. EuGH v. 12.12.2002 – Rs. C-470/99 (Universale-Bau), Slg. 2002, I – 11617; OLG Düsseldorf v. 16.2.2005 – VII Verg 74/04, VergabeR 2005, 364. 2 S. Müller-Wrede/Gnittke/Hattig, VOL/A-Kommentar, 2. Aufl. 2007, § 9a Rz. 20 ff., 26 f. 3 Lehmann/Meents/Goodarzi, Handbuch des Fachanwalts Informationstechnologierecht, 2. Aufl., Kapitel 24, Rz. 74.

Bischof

1193

N Rz. 165

Einzelprobleme

hältnisses (z.B. 5 % Abweichung) ein bestimmtes Kriterium über den Zuschlag entscheidet1. 165

Für die Praxis bleibt daher zusammenfassen festzuhalten: Es kann und sollte auf ein Punktesystem, Gewichtungen, Ermittlung von Abdeckungsgraden o.ä. zurückgegriffen werden, wobei der Preis weiterhin als bedeutendes Wertungskriterium anzuwenden ist (diesen völlig zu vernachlässigen, erscheint nicht vertretbar)2. Die Erstellung einer Bewertungmatrix hat sich bewährt, in der die Unterkriterien entsprechend einer vorher festgelegten Gewichtung aufgeführt werden. Ob diese Bewertungsmatrix den Bietern vollumfänglich bekannt zu geben ist, ist umstritten, im Hinblick auf die zitierte EuGH-Entscheidung wohl aber ratsam3. Sehr hilfreich bei Erstellung der Zuschlagskriterien sind die UfAB V, Version 2.0, die sich ausführlich mit Kriterienkatalog, Bewertungsmatrix und Bewertungsmethode auseinander setzen4. Diese eignen sich, um aus Bietersicht ggf. dem Auftraggeber eine intransparente, nicht nachvollziehbare Bewertung vorzuwerfen, vor allem, wenn sich aus den Vergabeakten die Bewertung nicht erschließt.

166

Für die spätere Wertung dürfen nur solche Kriterien herangezogen werden, die zuvor in der dargestellten Weise angegeben wurden. Nach der Bekanntgabe dürfen weder die Kriterien selbst noch ihre Gewichtung aufgehoben, geändert oder ergänzt werden. Auch bei Wertung der Angebote darf von ihnen nicht mehr abgewichen werden5. Weiter ist bei Festlegung der Kriterien zu beachten, dass diese – transparent sein müssen und – ausländische Anbieter nicht diskriminieren dürfen.

167

Die Vorschriften zu den Zuschlagskriterien haben bieterschützenden Charakter und sollen die Transparenz des Vergabeverfahrens und die Nachprüfbarkeit der Vergabeentscheidung gewährleisten und zur Objektivierung der Vergabeentscheidung beitragen. Dem Bieter soll zudem die Angebotserstellung und die Gewichtung einzelner Angebotsteile erleichtert werden. 10. Vertragliche Gestaltung

168

Einstweilen frei. 1 S. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchener Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 193 f.; UfAB V unter www.cio.bund.de. 2 S. Ohle/Sebastiani, CR 2003, 510 (513 ff.) m.w.N.; OLG Dresden, VergabeR 2001, 41, 44: Preis ist in der Regel mit 30 % zu berücksichtigen. 3 S. zur Nicht-Veröffentlichung der Gewichtung: Noch, in: Müller-Wrede, VOL/A, Kommentar, § 25 Rz. 90; Kulartz, in: Daub/Eberstein, VOL/A, Kommentar, § 25 Rz. 44; s. zur gegenteiligen Auffassung: Vergabekammer des Bundes v. 9.5.2000, VK A-24/99 sowie Urt. des EuGH v. 12.12.2002 – Rs. C-470/99. 4 S. UfAB V Version 2.0, Ziff. 4.17, 4.18, 4.20 bis 4.22 (s. unter www.cio.bund.de). 5 S. Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 9a Rz. 10.

1194

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 170 N

a) Einleitung Zu den Vertragsunterlagen als Bestandteil der Vergabeunterlagen gehören 169 neben der Leistungsbeschreibung (dazu vorstehend Rz. 139 ff.) die Vertragsbedingungen. Aus § 11 EG VOL/A und § 9 VOL/A ergibt sich, welche einzelnen Vertragsbedingungen einer Vergabe zugrunde zu legen sind: – VOL/B (Teil B der Vergabe- und Vertragsordnung für Leistungen – Allgemeine Vertragsbedingungen für die Ausführung von Leistungen); diese sind grundsätzlich zum Vertragsgegenstand zu machen; auch die VV zu § 55 BHO verpflichtet den Auftraggeber, die VOL/B zum Vertragsbestandteil zu machen. – Zusätzliche Allgemeine Vertragsbedingungen, die allerdings der VOL/B nicht widersprechen dürfen. – Ergänzende Vertragsbedingungen (für die Erfordernisse einer Gruppe gleichgelagerter Einzelfälle). Bei IT-Vergaben ist selbstverständlich an die Einbeziehung der EVB-IT zu denken, jeweils abgestimmt auf den zu beschaffenden Leistungsgegenstand. b) Zur Verfügung stehende Vertragsbedingungen Für die Vergabe von IT-Leistungen stehen als ergänzende Vertragsbedingun- 170 gen i.S.d. VOL/A zur Verfügung: – Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen (EVB-IT) – Soweit noch nicht durch EVB-IT abgelöst: Besondere Vertragsbedingungen für die Beschaffung von DV-Leistungen (BVB)1. Noch geltende BVB sind hierbei die – BVB-Pflege – BVB-Miete und – BVB-Planung. Als EVB-IT stehen derzeit folgende zur Verfügung: – Basis-EVB-IT: – EVB-IT Kauf – EVB-IT Überlassung Typ A – EVB-IT Überlassung Typ B – EVB-IT Dienstleistung – EVB-IT Instandhaltung – EVB-IT Pflege S – System-EVB-IT: – EVB-IT System

1 S. Leitzen/Intveen, CR 2001, 493.

Bischof

1195

N Rz. 171

Einzelprobleme

– EVB-IT Erstellung – EVB-IT Systemlieferung. 171

Es werden für die einzelnen zu vergebenden Leistungen folgende Vertragstypen und deren Zuordnung zu den EVB-IT/BVB empfohlen1: Vertragsgegenstand

Empfohlener Vertragstyp

Basis-EVB-IT Kauf von Hardware (ggf. inklusive Aufstellung, jedoch ohne sonstige Leistungsanteile)

EVB-IT Kauf

Kauf von Standardsoftware (ggf. inklusive Vorinstal- EVB-IT Überlassung Typ A lation, jedoch ohne sonstige Leistungsanteile Miete von Standardsoftware (ohne sonstige Leistungsanteile)

EVB-IT Überlassung Typ B

Dienstvertrag

EVB-IT Dienstleistung

Instandhaltung (früher: Wartung) von Hardware

EVB-IT Instandhaltung

System-EVB-IT Erstellung von IT-Systemen aus einer oder mehreren EVB-IT System Systemkomponenten (Standardsoftware und/oder Hardware, ggf. Individualsoftware) einschließlich weiterer Leistungen zur Herbeiführung der Betriebsbereitschaft, wobei letztere und/oder die Erstellung der Individualsoftware den Schwerpunkt der Leistung darstellen (z.B. weil sie mehr als 16 % des Auftragswerts ausmachen). Der Vertrag ist insgesamt ein Werkvertrag. Auf Softwareleistungen reduzierter, gekürzter EVB- EVB-IT Erstellung (ersetIT Systemvertrag (1) zur Erstellung von Individualzen BVB-Erstellung) software, (2) zur Anpassung von Software auf Quellcodeebene bzw. (3) zu umfangreichem, den Vertrag werkvertraglich prägenden Customizing von Standardsoftware, wobei die Standardsoftware zu diesem Zweck beigestellt oder vom Auftragnehmer auf der Grundlage dieses Vertrages überlassen werden kann. Der Vertrag ist insgesamt ein Werkvertrag. Kauf von IT-Systemen aus einer oder mehreren Sys- EVB-IT Systemlieferung temkomponenten (Standardsoftware und/oder Hard- (ersetzen BVB-Kauf, BVB Überlassung Typ II) ware) einschließlich weiterer Leistungen zur Herbeiführung der Betriebsbereitschaft ohne dass diese Leistungen den Schwerpunkt bilden. Der Vertrag ist insgesamt ein Kaufvertrag.

1 Zu finden unter www.cio.bund.de über den Suchbegriff „EVB-IT Entscheidungshilfe“. S.a. UfAB V Version 2.0, Kapitel 1.2.3, 1.2.4. und 4.2.

1196

Bischof

Rz. 173 N

Öffentliche Vergabe von IT-Leistungen Vertragsgegenstand

Empfohlener Vertragstyp

Erstellung von Individualsoftware

EVB-IT System (ersetzen BVB-Erstellung)

BVB Miete von Hardware

BVB-Miete

Pflege von Individualsoftware

BVB-Pflege (zukünftig: EVB-IT Systemservice)

Planung von DV-gestützten Verfahren, insbesondere BVB-Planung (zukünftig: Planung von Individualsoftware (Planungsphase, EVB-IT Planung) Fachliches Feinkonzept)

c) EVB-IT als AGB Unstreitig handelt es sich bei den BVB/EVB-IT um AGB der öffentlichen 172 Hand. Selbst wenn Anbieter im „vorauseilenden Gehorsam“ die EVB-IT heranziehen bzw. in ihr Angebot mit einbeziehen, ändert dies an der Tatsache, dass es sich insoweit weiterhin um AGB des Auftraggebers handelt, nichts. BVB/EVB-IT werden als AGB erst durch ausdrückliche Vereinbarung/Einbeziehung zwischen den Vertragspartnern wirksam (§ 305 Abs. 2 BGB). Folglich sehen sämtliche Vertragsdeckblätter der BVB sowie die Vertragsmuster der EVB-IT (meist unter Nummer 2)1 vor, welche Regelungen in welcher Reihenfolge Vertragsbestandteil werden und wo die BVB/EVB-IT zur Einsichtnahme bereitgestellt werden. Als AGB unterliegen die EVB-IT der Inhaltskontrolle der §§ 305 ff. BGB. In- 173 sofern ist zu berücksichtigen, dass BVB und EVB-IT einen Kompromiss als Ergebnis der Verhandlung zwischen der öffentlichen Verwaltung und der Privatwirtschaft/Industrie darstellen. Einzig die EVB-IT System wurden zunächst nicht endgültig mit der Industrie abgestimmt. Dieser Vertrag ist zu Gunsten der öffentlichen Verwaltung gestaltet und begegnete deshalb beim Erscheinen nicht unerheblicher Kritik, die inzwischen aber eher abgeklungen ist. Inzwischen sind auch die Verhandlungen zur Aktualisierung der EVB-IT System zwischen öffentlicher Hand und Industrie abgeschlossen. Der IT-Planungsrat hat am 21.6.2012 der modifizierten Fassung der EVB-IT System zugestimmt. Die Veröffentlichung der neuen EVB-IT System mit Zustimmung des BITKOM erfolgte in Version 2.0 am 19.9.2012. Der EVB-IT Systemvertrag liegt nur in Version 2.01 vom 9.1.2013 vor2. Die EVB-IT Systemlieferung waren von Anfang an mit der Industrie abgestimmt, auch ent-

1 Der EVB-IT Systemvertrag enthält diese Regelung unter Nummer 1.2, der EVBIT Systemlieferungsvertrag unter Nummer 1.3. 2 S. Müller/Fischer, EVB-IT System 2.0 Die wichtigsten Änderungen im Überblick, CR 2012, 422. S.a. die Ankündigung samt Anm. von Keller-Stoltenhoff auf www.it-recht-kanzlei.de.

Bischof

1197

N Rz. 174

Einzelprobleme

sprechend industriefreundlich und trafen daher auch auf keinen erheblichen Widerstand in der Industrie1. Kompromisse führen zum Teil zu die öffentliche Hand benachteiligenden Regelungen. Solche Benachteiligungen sind jedoch wirksam, da es dem Verwender von AGB sehr wohl gestattet ist, sich selbst zu benachteiligen. d) Anwendbarkeit und Lösungsansätze 174

Inwieweit die Auftraggeber – trotz der Pflicht zu deren Anwendung nach Haushaltsrecht2 – die Vergabe wirksam auf diese Vertragsbedingungen stützen können, insbesondere wegen der Weitergeltung der alten BVB, darin bestehender Lücken sowie deren noch unvollständiger Nachfolger, der EVBIT, ist insbesondere bei komplexen IT-Projekten durchaus umstritten3. Nur selten werden sich die zu vergebenen IT-Leistungen eindeutig in das „Korsett“ nur eines einzigen Vertragstyps der EVB-IT/BVB einordnen lassen. In den meisten Fällen, zumindest in denen, die über die Beschaffung von Hardware und Standardsoftware hinausgehen, wird ein „Bündel“ von Leistungen vom Bieter zu erbringen sein, die jede für sich vertragstypologisch unterschiedlich einzuordnen sind4. Dies hat zur Folge, dass für eine Vielzahl von Leistungen unterschiedliche Vertragsbedingungen zur Anwendung gelangen, von denen Teile schuldrechtsmodernisiert sind, andere dagegen nicht. Zudem ist nicht immer klar, welche Vertragsbedingungen auf welche Leistungen im Detail anzuwenden sind. Die Transparenz darf daher zu Recht bezweifelt werden5.

175

Die UfAB V, Version 2.0 (Kapitel 4.3 am Ende), sprechen folgende Empfehlung aus: „Fällt die zu beschaffende Leistung nicht in den Anwendungsbereich eines EVB-IT- oder BVB-Vertragstypen, sind von der ausschreibenden Stelle ggf. eigene Formulierungen zu entwickeln. Bei komplexen Vertragsregelwerken empfiehlt sich die Einschaltung des hausinternen Rechtsreferats bzw. der Rechtsabteilung oder auch die Hinzuziehung eines externen Sachverständigen.“

176

Dies könnte der Ausweg sein, um den konkreten Erfordernissen des Einzelfalls gerecht zu werden. Die Verträge werden dann im Verhandlungsverfah1 Zum Verfahren s.a. Keller-Stoltenhoff/Müller/Spitzer, CR 2010, 147. 2 Die Verwaltungsvorschriften zur Bundeshaushaltsordnung bzw. zu den Landeshaushaltsordnungen schreiben die Anwendung den Dienststellen von Bund und Ländern vor. Ob diese Verpflichtung auf Gemeindeebene ebenfalls besteht, ergibt sich aus den jeweiligen landesrechtlichen Vorschriften. 3 S. zum Streitstand: Koch, ITRB 2003, 136; Feil, ITRB 2003, 259 f.; Müglich, CR 2004, 166. 4 S. zur Vertragstypologie die weiteren Kapitels dieses Buches, insbesondere zu § 651 BGB sowie zur Anpassung, Einführung und Implementierung von Standardsoftware. 5 S. Koch, ITRB 2003, 136; a.A. Feil, ITRB 2003, 259 f.; Müglich, CR 2004, 166. S. zur Modifizierung der EVB-IT durch die öffentliche Hand Küppers, ITRB 2010, 142.

1198

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 178 N

ren mit den einzelnen Bietern verhandelt (soweit diese Vergabeart zulässigerweise gewählt werden konnte). Dies dürfte auch keine Benachteiligung der Bieter durch die öffentliche Hand darstellen, da im Rahmen von Neben-/ Änderungangeboten der Bieter nicht daran gehindert ist, die aus seiner Sicht notwendigen Änderungen am Vorschlag der öffentlichen Hand vorzubringen und hierbei auch bei der Preisgestaltung das Risiko der vertraglichen Gestaltung (insbesondere wegen der Haftung für Sach- und Rechtsmängel sowie Schadensersatz oder auch das projektmäßige Vorgehen) entsprechend zu berücksichtigen. e) Formaler Aufbau der EVB-IT Sowohl der formale Aufbau der EVB-IT1 ist weitgehend einheitlich, als auch 177 zu erheblichen Teilen die inhaltliche Ausgestaltung. Der formale Aufbau ist dadurch gekennzeichnet, dass ein bestimmter Satz von Dokumenten je EVB-IT den jeweiligen Vertragstyp insgesamt bildet: – Vertragsformular: Im jeweiligen Vertragsformular werden die Rechte und Pflichten beider Vertragspartner geregelt. Insbesondere wird der Leistungs-/Vertragsgegenstand definiert. Die erste Seite dient dabei als „Management Summary“, die weiteren Nummern des Vertrags enthalten die notwendigen Detaillierungen. Teils sind „feste Texte“ ohne weitere Wahlmöglichkeit vorgesehen, teils verschiedene Ankreuzvarianten oder das Ausfüllen freier Textfelder bzw. das Verwenden gesonderter Anlagen, die dann Bestandteil des Vertrags werden. Zudem schaffen bei sämtlichen EVB-IT Regelungen „am Ende des Musterformulars“ eine darüber hinausgehende Flexibilität, da diese ausdrücklich „Sonstige Vereinbarungen“ zulassen (so z.B. die Nummer 15 der EVB-IT Kauf). Zu beachten ist grundsätzlich, dass solche Vereinbarungen nur dann getroffen werden sollten, wenn hierfür ein Bedürfnis beim jeweiligen Auftraggeber besteht2, das dieser – auch aus vergaberechtlicher Perspektive – in seiner Vergabeakte dokumentieren sollte. Besteht ein solches nachvollziehbares, nicht diskriminierendes Bedürfnis, so sind abweichende Regelungen auch zulässig, selbst wenn sie erheblich von den „ausgehandelten Mustern“ abweichen sollten. – AGB: Für sämtliche unter Rz. 170 f. dargestellten Vertragstypen liegen entsprechende spezifische ergänzende Vertragsbedingungen vor, die über Nummer 2.1 (bzw. 1.2 oder 1.3) der EVB-IT in den Vertrag einbezogen werden Ergänzt werden die EVB-IT zum Teil durch Nutzungshinweise/Nutzerhin- 178 weise, die jedoch nicht Vertragsbestandteil werden. Sie dienen vor allem dazu, dem AGB-Verwender Hinweise zum Verständnis sowie zum Ausfüllen der Vertragsformulare zu geben. Zugleich dienen sie auch dazu, dem poten1 Zum formalen Aufbau der BVB s. Bischof, in: Auer-Reinsdorff, Beck’sches Mandatshandbuch IT-Recht, § 30 Rz. 31. 2 S. Feil/Leitzen, EVB-IT Kap. 2 Rz. 130.

Bischof

1199

N Rz. 179

Einzelprobleme

tiellen Vertragspartner grundlegende Informationen zu geben. Derzeit sind drei Nutzerhinweise veröffentlicht, zum einen für die EVB-IT System und zum anderen für die bis zur Einführung der EVB-IT System vorhandenen Vertragstypen (Kauf, Instandhaltung, Überlassung Typ A und B, Pflege S, Dienstleistung) sowie seit Mai 2011 für EVB-IT Systemlieferung. Die Nutzerhinweise für die EVB-IT System weisen beispielsweise einen Umfang von 62 Seiten auf und erläutern die einzelnen Ziffern der AGB und Nummern des Systemvertrags. Noch ausführlicher sind die Nutzerhinweise für die EVB-IT Systemlieferung mit 95 Seiten an notwendigen Erläuterungen. 179

Hinsichtlich der Nummerierung hat sich folgende sinnvolle Praxis eingebürgert, die zu beachten und zu befolgen ist: Die einzelnen Klauseln im Vertrag werden mit Nummern, die einzelnen Klauseln in den AGB mit Ziffern bezeichnet. Dies erleichtert die jeweilige Referenzierung innerhalb des Vertrages wie auch der gesamten Vergabeunterlagen. f) Die einzelnen Vertragstypen aa) EVB-IT Kauf

180

Die EVB-IT Kauf1 sind nicht auf den Erwerb von Hardware allein beschränkt. Zwar ist in Ziffer 1 der AGB von Produkten und Hardware die Rede. Aus Nummer 1.1 des EVB-IT Kaufvertrags ergibt sich jedoch, dass zugleich neben dem Kauf (und der Lieferung) der Hardware auch folgende weiteren Leistungsgegenstände möglich sind (wobei die Auswahl durch „Ankreuzen im Vertragsformular“ erfolgt): – die unbefristete Überlassung von Standard-Software gegen Einmalvergütung, – die Aufstellung von Hardware, – die Vorinstallation der Standard-Software durch den Auftragnehmer. Aus den Nutzerhinweisen (Ziffer 2.2.1) ergibt sich, dass die EVB-IT Kauf keine werkvertraglichen Vereinbarungen enthalten. Dies ist jedoch ausweislich der Langfassung des Kaufvertrags nicht zutreffend, weil neben der Leistung „Aufstellung von Hardware“ auch die „Vorinstallation“ zusätzlich als Vertragsgegenstand ausgewählt werden können. Der Kauf von Hardware mit „geringfügigen werkvertraglichen Leistungsanteilen“ soll dennoch nach dem Willen der Verwender dieser AGB zur Anwendung des EVB-IT Systemlieferungsvertrages führen (Nutzerhinweise Ziffer 2.2.1).

1 S. ausführlich zu den einzelnen Vertragstypen: Bischof/Schneider, in: AuerReinsdorff, Beck’sches Mandatshandbuch IT-Recht, § 31; Feil/Leitzen, EVB-IT Kommentar, 2003; Müller-Hengstenberg, Vertragsbedingungen für Softwäreverträge der öffentlichen Hand, 7. Aufl.

1200

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 183 N

bb) EVB-IT Überlassung Typ A Dieser Vertragstyp findet Anwendung bei Überlassung von Standardsoftwa- 181 re gegen Einmalvergütung zur unbefristeten Nutzung. Die Formulierung „zeitlich unbefristete Überlassung“ ist nicht typisch für Kauf. Richtig müsste sie lauten „auf Dauer“. Grundsätzlich ist eine geltungserhaltende Reduktion bzw. eine verwenderfreundliche Interpretation nicht zulässig. Diese Ungenauigkeit ist aber bisher noch nicht beanstandet bzw. Gegenstand gerichtlicher Entscheidungen geworden. Für sämtliche zusätzliche Leistungen (wie etwa Installation, Integration, Parametrisierung und Anpassung) müssen andere EVB-IT-Texte gefunden werden, also insbesondere die EVB-IT Dienstleistung; ggf. passen insoweit jedoch auch die Texte der EVB-IT System, wenn der werkvertragliche Charakter – im Gegensatz zu den EVB-IT Dienstleistung – im Vordergrund steht und den Schwerpunkt der Leistung ausmacht. Ggf. ist es in einem solchen Fall dann ohnehin erforderlich, ausschließlich die EVB-IT System oder die EVB-IT Erstellung zur Anwendung zu bringen. cc) EVB-IT Überlassung Typ B Dieser Vertragstyp findet Anwendung bei Überlassung von Standardsoft- 182 ware gegen Einmalvergütung für die zeitlich begrenzte Nutzung, somit für die Miete von Standardsoftware1. Die Abbildung neuer Softwareüberlassungsmodelle wie SaaS, Cloud-Computing, die als Miete eingeordnet werden, kann ggf. mit diesem Vertragstyp erfolgen, allerdings mit umfassenden Ergänzungen, um diesen Überlassungsmodellen gerecht zu werden. dd) EVB-IT Dienstleistung Dieser Vertragstyp soll alle Leistungen, die im weitesten Sinne mit IT zusam- 183 menhängen, erfassen, die als Beratung und Unterstützung gem. §§ 611 ff. BGB erbracht werden. Die EVB-IT AGB-Texte stellen insofern klar, dass kein Werkvertrag gewollt ist. Typischer Anwendungsbereich sind Schulungen, Beratungs- und sonstige Unterstützungsleistungen. Folgende (typischen) IT-Leistungen stellen die Praxis bei der Anwendung der EVB-IT vor Herausforderungen: – Die Erstellung eines „Pflichtenhefts“ oder sonstiger Konzepte kann mit den EVB-IT Dienstleistung wegen des erfolgsorientierten Charakters nicht abgedeckt werden; dies wäre wohl über BVB-Planung zu erreichen, eine Mischung aus Werk- und Dienstvertrag. – Ein Rollout (z.B. Umstellung der Arbeitsplätze-Clients auf neue Software) wäre nur als Dienstvertrag, also ohne Herbeiführung der Funktionsfähigkeit/Betriebsbereitschaft, mit den EVB-IT Dienstleistung machbar.

1 S. Feil/Leitzen, CR 2002, 480.

Bischof

1201

N Rz. 184

Einzelprobleme

Will der Auftraggeber ausschließliche Rechte oder über die in Ziffer 4 der EVB-IT Dienstleistung hinausgehende Rechte eingeräumt erhalten, so muss er dies explizit anderweitig im Vertragsformular regeln (vgl. Nummer 6 des Vertragsformulars). ee) EVB-IT Instandhaltung 184

Gegenstand des Vertrags ist das, was häufig als Wartung von Hardware bezeichnet wird. Instandhaltung ist der Oberbegriff und umfasst auch die Instandsetzung. Ohne dies vertragstypologisch deutlich zu machen, decken die EVB-IT Instandhaltung zwei verschiedene Ausprägungen ab: – den erfolgsorientierten, werkvertraglich zu qualifizierenden Typ, bei dem die Aufrechterhaltung und Wiederherstellung der Betriebsbereitschaft geschuldet ist (Ziffer 1.1), und – den stark tätigkeitsorientierten, teils dienstvertraglich, im Ergebnis und v.a. bei der Leistungsstörung werkvertraglich zu qualifizierenden Typ, bei dem bestimmte Tätigkeiten geschuldet sind (Ziffer 1.2), um die Betriebsbereitschaft wieder herzustellen. ff) EVB-IT Pflege S

185

Die EVB-IT Pflege S1 sind ausschließlich für die Pflege von Standardsoftware anzuwenden. Standardsoftware wird auch hier definiert als Programme, Module, Tools u.ä., die für die Bedürfnisse einer Mehrzahl von Kunden am Markt und nicht speziell vom Auftragnehmer für den Auftraggeber entwickelt wurden (einschließlich der dazugehörigen Dokumentation). Für die Pflege von Individualsoftware sind noch immer die BVB-Pflege anzuwenden.

186

Zwar geht die Tendenz der Rechtsprechung bei Pflegeverträgen dahin, diese insgesamt als Werkvertrag anzusehen. Letztlich handelt es sich jedoch aufgrund des typischerweise sehr unterschiedlichen Regelungsinhalts um einen typengemischten Vertrag. Die typischen Leistungen nach EVB-IT Pflege S weisen teils Erfolgscharakter auf, insbesondere wenn es um die Mängelbeseitigung geht, teils reinen Unterstützungscharakter (z.B. Telefonsupport) oder tragen hinsichtlich des Erwerbs von Updates, Upgrades auch kaufrechtliche Züge. Die EVB-IT Pflege S versuchen die jeweiligen Pflegeleistungen dem jeweils passenden BGB-Vertragstyp zuzuordnen und hierfür dann die einschlägigen Rechtsregelungen zu verfassen.

187

Für besondere Anforderungen an die zu erbringenden Pflegeleistungen sind die „Besonderen Vereinbarungen“ zu nutzen bzw. entsprechende Anlagen zum Pflegevertrag zu erstellen. Typisches Beispiel hierfür kann die Vereinbarung von Service Levels sein, die neben der reinen Reaktions- auch 1 S. Karger, ITRB 2003, 107; Müglich, CR 2003, 633; Feil/Leitzen, CR 2003, 161; Intveen, ITRB 2003, 128.

1202

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 190 N

Wiederherstellungszeiten, Strafbewehrungen bei Zeitüberschreitungen (z.B. Vertragsstrafe, pauschalierter Schadensersatz) oder auch Bonus-/Malus-Regelungen vorsehen. Auch die Anforderungen der neuen Softwareüberlassungsmodelle in der Cloud, SaaS u.ä. lassen sich nur mit Ergänzungen des Vertragsformulars sinnvoll für beide Vertragspartner abbilden. Vielfach passen die EVB-IT Pflege S auch nur nach umfassenden Ergän- 188 zungen zu den am Markt vorzufindenden Pflegemodellen, die z.B. auch End-of-Life-Themen mit besonderen Pflegeperioden samt Sonderkonditionen hierzu vorsehen oder bestimmte „Pflegelevel“ (Silver/Gold/Platinum oder Standard/Business o.Ä.) mit unterschiedlichem Leistungsinhalt anbieten, zwischen denen ggf. gewechselt werden kann. gg) EVB-IT System Die EVB-IT System1 wurden konzipiert für die Beschaffung (komplexer) IT- 189 Systeme. Die Abbildung dieser Beschaffungen hatte die Praxis zuvor aufgrund der bislang vorhandenen EVB-IT (und BVB) und deren Mit-/und Nebeneinander vor erhebliche Schwierigkeiten gestellt. Die Beschaffung auf Basis verschiedenster Verträge durchführen zu müssen, entsprach meist auch nicht den Interessen der öffentlichen Hand, Leistungen aus einer Hand zu transparenten und einheitlich geltenden Vertragsbedingungen zu beschaffen. Die EVB-IT System kommen daher bei Vorliegen folgender Voraussetzungen zur Anwendung: – Der Schwerpunkt der vertraglichen Leistungen liegt in der Erstellung eines IT-Systems – ggf. einschließlich der Erstellung von Individualsoftware –, der Integration und Zusammenfügung von Einzelleistungen, der Einbindung in die Systemumgebung des Auftraggebers sowie in der Herbeiführung der Funktionsfähigkeit des Gesamtsystems und – der Wert der Anpassungsleistungen (worunter Erstellung der Individualsoftware, Migration von Altdaten sowie Herbeiführung der Betriebsbereitschaft des Gesamtsystems zu verstehen ist) überschreitet einen Wert von 16 % des Erstellungspreises oder – der Wert der Anpassungsleistungen überschreitet zwar den Wert von 16 % des Erstellungspreises nicht, aber – die Anpassungsleistungen sind so entscheidend, dass das IT-System ohne sie durch den Auftraggeber nicht oder nicht sinnvoll nutzbar ist oder – es handelt sich bei den Anpassungen um die Erstellung zahlreicher Individualprogrammierungen oder – es wird lediglich die Erstellung von Individualsoftware in Auftrag gegeben2. 1 S. Intveen, ITRB 2012, 282; Lensdorf, CR 2008, 1. 2 Die EVB-IT System ersetzen somit den BVB-Erstellungsvertrag, zumindest solange es keinen speziellen „EVB-IT Werkvertrag“ gibt. Ist diese Fallkonstellation relevant, ist die Vergabestelle gehalten, im Vertrag ausdrücklich klarzustellen, dass dann mit „Gesamtsystem“ schlicht die Erstellung der Individualsoftware gemeint ist, damit die Regelungen der EVB-IT System nicht ins Leere laufen.

Bischof

1203

190

N Rz. 191

Einzelprobleme

Sollte eine dieser Voraussetzungen nicht erfüllt werden, sollen aber mehrere Leistungen inklusive geringfügiger Anpassungsleistungen aus einer Hand beschafft werden, so ist der EVB-IT Systemlieferungsvertrag1 anzuwenden. 191

Die EVB-IT System sind für komplexe IT-Systeme bestimmt und stellen die Vertragsgrundlage für die Beschaffung verschiedenster Leistungen als einheitliches IT-System dar. Diese Leistungen können insbesondere umfassen: a) Leistungen bis zur Abnahme – Kauf von Hardware, – Miete von Hardware, – Überlassung von Standardsoftware auf Dauer gegen Einmalvergütung, – Überlassung von Standardsoftware auf Zeit, – Erstellung und Überlassung von Individualsoftware auf Dauer, – Übernahme von Altdaten und andere Migrationsleistungen, – Erstellung des Gesamtsystems und Herbeiführung von dessen Betriebsbereitschaft, – Schulung, – Erstellung von Dokumentation, – Projektmanagement Standardmäßig im Vertragsformular bereits angekreuzt sind aufgrund der Zielsetzung, ein funktionsfähiges Gesamtsystem zu erhalten, die Leistungen zur Herbeiführung der Betriebsbereitschaft des Gesamtsystems und zum Projektmanagement. Diese sind unabweisbar für den Projekterfolg. Sonstige Leistungen können zusätzlich als Vertragsinhalt vereinbart werden b) Leistungen nach der Abnahme – Systemservice nach Abnahme (was mit Aufrechterhaltung und/oder Wiederherstellung der Betriebsbereitschaft verbunden wird) – Weiterentwicklung und Anpassung des Gesamtsystems Sonstige Leistungen können zusätzlich als Vertragsinhalt vereinbart werden.

192

Von wesentlicher Bedeutung ist, dass die Leistungen zur Herbeiführung der Betriebsbereitschaft des Gesamtsystems den Schwerpunkt der Leistungen bilden, so dass der Vertrag – nach dem Willen der Verwender – einheitlich dem Werkvertragsrecht unterfällt.

193

Daran hat sich auch im Rahmen der Verhandlungen zum EVB-IT Systemvertrag V2.0 nichts geändert. Am 21.6.2012 hat der IT-Planungsrat der modifizierten Fassung zugestimmt; die BITKOM hatte ihre Zustimmung bereits am 29.3.2012 erteilt. Mit der Veröffentlichung ist nunmehr zeitnah zu rechnen2.

1 S. hierzu Rz. 194 ff. 2 S. unter www.cio.bund.de.

1204

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 193 N

Als wesentliche Änderungen sind folgende, besonders bedeutsame Punkte zu erwähnen: – Das Vertragsformular der EVB-IT System wurde an das Vertragsformular der EVB-IT Systemlieferung angeglichen. Dies zeigt sich besonders deutlich darin, dass nun auch beim EVB-IT Systemvertrag Nutzungsrechtsmatrizen einbeziehen lassen, um Art und Umfang der Nutzungsrechte an der Standardsoftware des Gesamtsystems zu regeln. Auch in Bezug auf die Individualsoftware werden abweichende und ergänzende Regelungen gegenüber den AGB erlaubt. – Die Regelungen zur Rechtseinräumung wurden v.a. in Bezug auf Anpassungsleistungen an der Standardsoftware1 den Bedürfnissen der IT-Branche entsprechend angepasst: – An Anpassungen der Standardsoftware auf Quellcodeebene, die der Auftragnehmer in den Standard übernimmt (und dies bei Angebotsabgabe bereits ankündigt), erhält der Auftraggeber nur die Rechte, die er auch an der Standardsoftware erhält. – An Anpassungen der Standardsoftware auf Quellcodeebene, die nicht in den Standard übernommen werden, erhält der Auftraggeber die Rechte, die er auch an der Individualsoftware erhält. Allerdings muss der Auftragnehmer die Anpassungen lediglich im Objektcode übergeben, wobei er allerdings dafür zu sorgen hat, dass der Auftraggeber eine funktionierende Softwareversion erzeugen kann. – Für vorbestehende Softwareteile (d.h. Bibliotheken oder Programmfragmente bzw. Module, die der Auftragnehmer in Individualsoftware einbaut) gelten zwar grundsätzlich dieselben Rechteregelungen wie für Individualsoftware, jedoch mit der Ausnahme, dass keinesfalls ausschließlich Nutzungsrechte eingeräumt werden. Der Auftragnehmer kann – unter bestimmten Voraussetzungen – die Rechte hinsichtlich Bearbeitung, Verbreitung und Unterlizenzierung weiter einschränken. – An vorbestehenden Materialien des Auftragnehmers, die dieser bei der Herbeiführung der Betriebsbereitschaft nutzt (wie z.B. Vorlagen, Konzepte, Dokumentation) erhält der Auftraggeber kein Recht zur Bearbeitung und Unterlizenzierung. – Im Rahmen des Systemservice werden nun standardmäßig Servicezeiten (Montag bis Freitag, 8–17 Uhr, mit Ausnahme gesetzlicher Feiertage am Erfüllungsort) vorgesehen, wenn keine anderen Servicezeiten im Vertragsformular genannt sind. Bei Störungen in der Standardsoftware werden nun differenzierte Regelungen vorgesehen, die den Fall lösen sollen, wenn der Auftragnehmer nicht selbst Hersteller der Software ist. Zunächst ist ein verfügbarer, die Störung beseitigender Programmstand zur 1 Solche Anpassungen der Standardsoftware auf Quellcodeebene führen nach der derzeit noch veröffentlichten Fassung der EVB-IT System dazu, dass die Standardsoftware dadurch insgesamt zur Individualsoftware. S.a. zu lizenzrechtlichen Aspekten Bischof, ITRB 2009, 64.

Bischof

1205

N Rz. 194

– –

–

–

Einzelprobleme

Verfügung zu stellen. Ist ein solcher nicht vorhanden, ist eine Umgehungslösung zur Verfügung zu stellen. Ist dies unzumutbar, muss sich der Auftragnehmer beim Hersteller für die baldmögliche Überlassung eines die Störung beseitigenden Programmstands einsetzen, worüber eine Auskunftspflicht des Auftragnehmers besteht. Es wurden zusätzliche Mitwirkungsleistungen des Auftraggebers vereinbart (siehe Ziffer 11 der EVB-IT System AGB). Bei der Abnahme wurde insbesondere die Frist für Funktionsprüfung verkürzt. Wenn es Teilabnahmen gibt, bleibt es dabei, dass eine Gesamtabnahme zu erfolgen hat, deren Gegenstand nach wie vor v.a. die Prüfung der systemübergreifenden Funktionalitäten sowie der Interoperabilität aller Teile des Gesamtsystem ist. Die Regelungen zur Mängelhaftung wurden überarbeitet. Hervorzuheben ist die Verkürzung der Verjährungsfrist für Rechtsmängel von 60 auf 36 Monate sowie die Aufnahme einer Sonderregelung entsprechend der EVB-IT Systemlieferung für Schutzrechtsverletzungen; eine solche Regelung fehlte bislang vollständig. Zugunsten der IT-Branche wurde eine Einschränkung des Rücktrittsrechts bei Mängelansprüchen aufgenommen: Das Rücktrittsrecht endet in Bezug auf die Standardsoftware bereits nach 12 und nicht erst nach 24 Monaten. Die Haftungsbegrenzung gilt nun für alle gesetzlichen und vertraglichen Schadensersatzansprüche bei leichter Fahrlässigkeit des Auftragnehmers, somit auch für Freistellungs- und Aufwendungsersatzansprüche. Im Rahmen des Systemservices richtet sich die Haftungsbegrenzung für leicht fahrlässige Pflichtverletzungen nun auf die Summe, die während der Vertragslaufzeit für den Systemservice zu zahlen ist, insgesamt minimal das Doppelte und maximal da Vierfache der Vergütung, die für das erste Vertragsjahr des Systemservices zu zahlen ist.

hh) EVB-IT Systemlieferung 194

Der EVB-IT Systemlieferung1 sollen unter folgenden Voraussetzungen zur Anwendung gelangen: – Folgende Leistungen dürfen nicht bzw. nicht ausschließlich Vertragsgegenstand sein: – Erstellung von Individualsoftware, – Überlassung von Standardsoftware, – Lieferung von Hardware. – Der Schwerpunkt der vertraglichen Leistungen liegt in der Lieferung eines IT-Systems, nicht in der Herbeiführung der Betriebsbereitschaft des Systems.

1 S. Intveen, ITRB 2011, 216; Keller-Stoltenhoff/Müller/Spitzer, CR 2010, 147; Redeker, ITRB 2010, 255.

1206

Bischof

Rz. 198 N

Öffentliche Vergabe von IT-Leistungen

– Der Wert der Anpassungs- bzw. Integrationsleistungen ist im Verhältnis zum Wert der das IT-System bildenden Systemkomponenten deutlich geringer. Die Rechtsprechung1 hat eine Erheblichkeitsschwelle bei 16 % des Auftragswerts angesetzt, wobei dies allerdings nur einen Anhaltspunkt, nicht jedoch eine „generelle Richtschnur“ darstellt. – Der Auftraggeber benötigt in erster Linie die vertragsgegenständlichen Systemkomponenten. Vertragsgegenstand ist die Lieferung eines Systems, welches i.d.R. aus 195 Hard- und Software einschließlich der Herbeiführung der Betriebsbereitschaft auf der Grundlage eines Kaufvertrages und dem hieran anschließenden Systemservice besteht. Als typischer Leistungsinhalt ist daher vorgesehen: – – – – –

Erwerb von Hardware und Standardsoftware, Leistungen zur Herbeiführung der Betriebsbereitschaft, Übernahme von Altdaten und anderer Migrationsleistungen, und Schulungen sowie sonstige Leistungen zur Systemlieferung.

Allgemein wird der EVB-IT Systemlieferung daher als Kaufvertrag mit Mon- 196 tageverpflichtung des Auftragnehmers i.S.v. § 434 Abs. 2 BGB eingeordnet. Der Auftragnehmer schuldet insbesondere die Demonstration der Betriebsbereitschaft des Systems (sozusagen als Ersatz für die nicht vorgesehene werkvertragliche Abnahme der Montage). Bei dieser soll die Ablauffähigkeit des Systems sowie vertraglich vereinbarten Funktionalitäten vorgeführt werden. Ist im Vertrag nicht vereinbart, dass bestimmte Funktionalitäten vorzuführen sind, so bezieht sich die Demonstration der Betriebsbereitschaft ausschließlich auf die Ablauffähigkeit des Systems. Die Demonstration ist die einzige Möglichkeit, vor Systemlieferung festzustellen, ob das System im Wesentlichen funktioniert. Wenn betriebsverhindernde oder betriebsbehindernde Mängel i.S.d. Ziffer 3.1.1 bzw. 3.1.2 AGB vorliegen, kann der Auftraggeber die Lieferung zurückweisen. Der EVB-IT Systemlieferung sieht ebenfalls eine Gesamtverantwortlich- 197 keit des Auftragnehmers vor, was v.a. in den Informationspflichten des Auftragnehmers (s. Ziffer 6 der AGB) zum Ausdruck kommt, wonach der Auftraggeber möglichst umfassend über Risiken und Probleme bei der Vertragserfüllung wie auch über die auf ihn zukommenden Aufgaben, Beistellungsleistungen u.ä. rechtzeitig informiert werden soll. Mit den EVB-IT Systemlieferung wurde erstmals die Verwendung sog. Nut- 198 zungsrechtsmatrizen eingeführt. Diese sollen dafür sorgen, dass nur die Regelungen zu Nutzungsrechten aus den Lizenzbedingungen der Hersteller in den Vertrag einbezogen werden, nicht aber diese Lizenzbedingungen als Ganzes. In der Nutzungsrechtsmatrix können nun die Beschränkungen ge1 S. OLG Köln Urt. v. 10.3.2006 – 19 U 160/05 – BeckRS 2006, 09810.

Bischof

1207

N Rz. 198a

Einzelprobleme

genüber dem Standard der Rechtseinräumung der EVB-IT Systemlieferung eingetragen werden, was den unterschiedlichen Lizenzierungsmodellen der Softwareindustrie entgegenkommt1. ii) EVB-IT Erstellung 198a Die EVB-IT Erstellung wurden am 9.7.2013 – nach kurzer Verhandlung zwischen öffentlicher Hand und Wirtschaft – veröffentlicht. Es handelt sich hierbei um einen „allein für werkvertragliche Leistungen rund um Software gekürzten EVB-IT Systemvertrag“2. Vertragsgegenstand der EVB-IT Erstellung sind Leistungen zur Erstellung von Individualsoftware, zur Anpassung von Software auf Quellcodeebene und zu umfangreichem, den Vertrag werkvertraglich prägenden Customizing von Standardsoftware, wobei die Standardsoftware zu diesem Zweck beigestellt oder vom Auftragnehmer auf der Grundlage dieses Vertrages überlassen werden kann. Der Vertrag ist insgesamt ein Werkvertrag. Zur Frage, wann Anpassungsleistungen als wesentlich im vorgenannten Sinne anzusehen sind, wird wohl auf die für den EVB-IT Systemvertrag maßgeblichen Kriterien abgestellt werden können. Er regelt auch den Kauf der Standardsoftware vom Auftragnehmer, die angepasst werden soll. Eine Miete der Standardsoftware, wie bei den EVB-IT System, ist nicht möglich. Der Vertrag entstand wohl weitgehend durch Streichen von Passagen der EVB-IT System, die sich auf Hardware- und Mietleistungen bezogen. Allerdings wurden auch weitere Streichungen vorgenommen, die für IT-Projekte wohl in aller Regel von wesentlicher Bedeutung sind. Auffällig ist gerade, dass sämtliche Regelungen gestrichen wurden, die sich mit Projektmanagement und Vorgehensmodell befassen. Diese gerade für IT-Projekte wohl unerlässlichen Regelungen müssen nunmehr im Vertragsmuster über die „Sonstigen Vereinbarungen“ vom Anwender eingebracht werden. Die AGB der EVB-IT Erstellung unterscheiden sich von den EVB-IT System AGB letztlich durch die vorgenommenen Streichungen der Regelungen zur Miete von Hard- und Standardsoftware, zum Personal, zum Projektmanagement und zu möglichen Sicherheiten sowie sprachlichen Anpassungen. Die Nutzungsrechtsregelungen für die Standardsoftware, Individualsoftware, Standardsoftware, die auf Quellcodeebene angepasst wird, und für vorbestehende Teile, die bei der Erstellung von Individualsoftware genutzt werden, sind dieselben wie bei den EVB-IT System. Wie bereits bei den EVB-IT Systemlieferung und den EVB-IT System, besteht auch bei den EVB-IT Erstellung die Möglichkeit, über das Muster „Nutzungsrechtsmatrix“ von den 1 S. Bischof/Schneider, in: Auer-Reinsdorff, Beck’sches Mandatshandbuch ITRecht, § 31 Rz. 272 ff.; Intveen, ITRB 2011, 216; Redeker, ITRB 2010, 255; KellerStoltenhoff/Müller/Spitzer, CR 2010, 147. 2 Vgl. Keller-Stoltenhoff unter http://www.vergabeblog.de/2013-08-11/der-evb-iterstellungsvertrag-ein-neues-kind-der-evb-it-familie/.

1208

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 201 N

AGB abweichende Nutzungsrechte zu vereinbaren. Statt von Serviceleistungen nach Abnahme wird nun von Pflegeleistungen gesprochen, deren Umfang den Regelungen zu den anderen EVB-IT Systemverträgen entspricht. Weitere Änderungen sind letztlich sprachlicher Natur. Das Vertragsmuster ist – im Vergleich zum Systemvertrag – stark gestrafft (21 Seiten statt 38 Seiten), wobei die wesentlichen Regelungsmöglichkeiten weiter vorhanden sind. Hervorgehoben ist die maßgebliche Hauptleistung, nämlich das Customizing, das nun in der eigenständigen Nummer 4.3 des Vertrages geregelt ist. Den öffentlichen Auftraggebern, die Projekte ohne Hardware beauftragen möchten, wird der EVB-IT Erstellung im Hinblick auf die erfolgten Kürzungen und Straffungen entgegenkommen. jj) Ausblick Als weitere EVB-IT Vertragstypen sind geplant EVB-IT Planung sowie EVBIT Systemservice (Wartung und Pflege von IT-Systemen)

199

V. Durchführung von Vergabeverfahren 1. Vergabebekanntmachung a) EU-Vergaben Bei EU-weiten Vergabeverfahren (bis auf das „stille Verhandlungsverfah- 200 ren“) ist eine Vergabebekanntmachung entsprechend den Mustern der EU zu veröffentlichen1. Mit dieser wird Vergabeabsicht kundgetan und bei nichtoffenem Verfahren und Verhandlungsverfahren zur Stellung von Teilnahmeanträgen aufgefordert. Beim offenen Verfahren stellt die Vergabebekanntmachung bereits die Aufforderung zur Angebotsabgabe dar. Der Tag der Absendung der Bekanntmachung muss vom öffentlichen Auftraggeber nachgewiesen werden können, § 15 EG Abs. 2 Satz 4 VOL/A. Spätestens 12 Tage nach Absendung findet die Veröffentlichung im Supple- 201 ment zum Amtsblatt in deutscher Sprache, die auch verbindlich ist (sowie eine Zusammenfassung der wichtigsten Bestandteile in den anderen Amtssprachen der Gemeinschaft), statt. Bei elektronisch erstellten und übersandten Bekanntmachung erfolgt die Veröffentlichung spätestens 5 Tage nach ihrer Absendung (§ 12 EG Abs. 3 VOL/A). Die Formulare sowie weitere Hilfestellungen sind unter http://simap.europa.eu zu finden. Sämtliche Ver-

1 Diese Bekanntmachung ist zu richten an das Amt für amtliche Veröffentlichungen der Europäischen Gemeinschaften (2, rue Mercier, L-2985 Luxemburg). Zu verwenden sind nun die auf Grund der EU-RL 2004/17/EG und 2004/18/EG entwickelten neuen Standardformulare, zu finden unter http://simap.eu.int (in pdf sowie als Online-Formular); s. hierzu Lindenthal, VergabeR 2006, 1 ff.

Bischof

1209

N Rz. 202

Einzelprobleme

gabebekanntmachungen auf EU-Ebene sowie weitere Veröffentlichungen sind unter http://ted.europa.eu im Internet abrufbar. 202

Daneben ist eine nationale Veröffentlichung möglich, nicht jedoch vor dem Absendungstag und nicht mit anderem Wortlaut als die EU-Veröffentlichung (§ 15 EG Abs. 4 VOL/A)1; auch muss auf das Absendungsdatum der Veröffentlichung an die EU hingewiesen werden. Eine Verpflichtung zur zusätzlichen nationalen Veröffentlichung besteht nicht2.

203

Zum Inhalt der Vergabebekanntmachung gehört u.a. die Anforderung von Nachweisen (§ 6 bzw. § 7 EG VOL/A), aufgrund derer die Bewerber ausgewählt werden, die den Anforderungen an Leistungsfähigkeit, Zuverlässigkeit und Fachkunde entsprechen (§ 7 EG Abs. 1, 2, 3 und 6 VOL/A in Verbindung mit § 6 EG Abs. 3 bis 6 VOL/VOL/A)3. b) Nationale Vergaben

204

Bei nationalen Vergaben4 ist § 12 VOL/A zu beachten, wonach die Veröffentlichungen in Tageszeitungen, amtlichen Veröffentlichungsblättern, Fachzeitschriften oder Internetportalen erfolgen (§ 12 Abs. 1 Satz 1 VOL/A). Es obliegt dem öffentlichen Auftraggeber, das aus seiner Sicht geeignete Veröffentlichungsmedium5 auszuwählen. Ggf. ist auch eine Veröffentlichung in mehreren Medien erforderlich. Bei dieser Entscheidung hat er zu berücksichtigen, dass – das Medium einem unbeschränkten Kreis von Bewerbern ohne Schwierigkeiten zugänglich ist, – ein ausreichend großer Bewerberkreis angesprochen wird, – das Medium keine zu geringe Auflagenzahl hat und sich nicht nur auf einen kleinen Einzugsbereich bezieht, – das Medium fachlich nicht zu sehr spezialisiert ist, es sei denn, es wird ein Spezialauftrag vergeben, der nur über spezielle Medien überhaupt den richtigen Adressatenkreis trifft6.

1 S. Reichling, in: Müller-Wrede, VOL/A-Kommentar, 3. Aufl., § 15 EG Rz. 81 ff. So auch bereits zum alten Recht Fett, in: Müller-Wrede, VOL/A, § 17a Rz. 69 ff. 2 S. Reichling, in: Müller-Wrede, VOL/A-Kommentar, 3. Aufl., § 15 EG Rz. 81. So auch bereits zum alten Recht Fett, in: Müller-Wrede, VOL/A, § 17a Rz. 69 ff. 3 S. die Hinweise von Reichling, in: Müller-Wrede, VOL/A-Kommentar, 3. Aufl., § 15 EG Rz. 21 ff. zum Bekanntmachungsmuster und den notwendigen Mindestangaben. 4 S. zu Unterschwellenvergaben Bischof, ITRB 2012, 292. 5 S. die Übersicht bei Reichling, in: Müller-Wrede, VOL/A-Kommentar, 3. Aufl., § 12 Rz. 26 zu den wichtigsten Ausschreibungsblättern und Internetportalen (mit Kontaktdaten). 6 S. Reichling, in: Müller-Wrede, VOL/A-Kommentar, 3. Aufl., § 12 Rz. 18 ff.

1210

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 209 N

Zudem müssen alle Bekanntmachungen in Internetportalen zentral über die Suchfunktion des Internetportals www.bund.de ermittelt werden können (§ 12 Abs. 1 Satz 2 VOL/A). Die Mindestangaben einer Bekanntmachung ergeben sich aus § 12 Abs. 2 Satz 2 VOL/A1.

205

2. Teilnahmeantrag: Anforderungen und Frist Ein Teilnahmeantrag ist in den Vergabeverfahren erforderlich, bei denen ein 206 Teilnahmewettbewerb durchgeführt wird, bevor zur Angebotsabgabe aufgefordert wird, demnach bei: – – – –

beschränkter Ausschreibung (§ 3 Abs. 1 Satz 2 VOL/A) freihändigen Vergaben mit Teilnahmewettbewerb (§ 3 Abs. 1 Satz 3 VOL/A) nichtoffenen Verfahren (§ 101 Abs. 3 GWB) Verhandlungsverfahren mit vorheriger öffentlicher Aufforderung zur Teilnahme (§ 101 Abs. 5 GWB) – Wettbewerblicher Dialog (§ 101 Abs. 4 Satz 2 GWB). Bei den nationalen Vergaben finden sich keine detaillierten Anforderungen 207 an den Teilnahmeantrag. Für die Bearbeitung und Abgabe der Teilnahmeanträge ist eine ausreichende Frist vorzusehen (vgl. § 10 Abs. 1 VOL/A). Eine feste Frist – wie bei EU-weiten Vergaben – ist gerade nicht vorgesehen, so dass die Angemessenheit der Frist vom öffentlichen Auftraggeber zu ermitteln ist, Insoweit bietet es sich an (wie bei der alten Regelung des § 18 Nr. 1 Abs. 1 Satz 2 VOL/A 2006), z.B. darauf abzustellen, wie viel zusätzliche Aufwand ggf. noch erforderlich ist, um z.B. ergänzende Unterlagen anzufordern. Bei EU-weiten Vergaben ist für die Stellung von Teilnahmeanträgen eine 208 Mindestfrist von 37 Tagen, gerechnet vom Tag der Absendung der Bekanntmachung an, vorzusehen (§ 12 EG Abs. 4 VOL/A). In Fällen besonderer Dringlichkeit ist eine Verkürzung auf mindestens 15 Tage bzw. bei elektronischer Übermittlung auf mindestens 10 Tage vorgesehen, gerechnet vom Tag der Absendung der Bekanntmachung an. Bei elektronisch erstellten und übermittelten Bekanntmachungen (was heute wohl die Regel sein dürfte), kann die Mindestfrist für Teilnahmeanträge um 7 Tage verkürzt werden, beträgt demnach also nur noch 30 Tage. Die Anforderungen an die Teilnahmeanträge werden sodann in § 14 EG 209 VOL/A geregelt. Die Teilnahmeanträge können auf dem Postweg, per Telekopie oder elektronisch übermittelt werden. Telefonisch angekündigte Anträge sind vor dem Ablauf der Teilnahmefrist zu bestätigen. Die Grundsätze der Informationsübermittlung, insbesondere in Bezug auf elektronische Kommunikation, ergeben sich aus § 13 EG VOL/A. Der öffentliche Auftrag1 S. Reichling, in: Müller-Wrede, VOL/A-Kommentar, 3. Aufl., § 12 Rz. 31 ff.

Bischof

1211

N Rz. 210

Einzelprobleme

geber hat für die Unversehrtheit und Vertraulichkeit der übermittelten Teilnahmeanträge zu sorgen. Der Bewerber muss daher den Teilnahmeantrag in einem verschlossenen Umschlag einreichen und diesen als Teilnahmeantrag kennzeichnen (§ 14 EG Abs. 2 Satz 1 VOL/A). Die Teilnahmeanträge werden bis zum Ende der Teilnahmeantragsfrist unter Verschluss gehalten (§ 14 EG Abs. 2 Satz 2 VOL/A). Bei elektronischer Übermittlung ist eine Verschlüsselung erforderlich (§ 14 EG Abs. 3 VOL/A). 3. Eignung: Fachkunde, Leistungsfähigkeit, Gesetzestreue und Zuverlässigkeit a) Grundsätze 210

Für europaweite Vergaben bestimmt § 97 Abs. 4 Satz 1 GWB, dass Aufträge an fachkundige leistungsfähige, gesetzestreue und zuverlässige Unternehmen vergeben werden. Entsprechende Regelungen finden sich sodann in § 2 EG Abs. 1 VOL/A sowie § 19 EG Abs. 5 VOL/A. Gleichlautende Regelungen finden sich für nationale Vergaben in § 2 Abs. 1 Satz 1 VOL/A.

211

Wann die Eignung geprüft wird, hängt vom gewählten Vergabeverfahren ab. In allen Verfahren mit Teilnahmewettbewerb wird die Eignung der Unternehmen bereits im Teilnahmewettbewerb geprüft, da unter den sich bewerbenden Unternehmen eine Auswahl derjenigen stattzufinden hat, die zur Angebotsabgabe aufgefordert werden (s. zum Teilnahmewettbewerb, Rz. 230 ff.). Insofern findet durchaus eine Bewertung statt, welches Unternehmen als geeigneter angesehen wird. Bei allen anderen Verfahrensarten wird die Eignung der Unternehmen im Rahmen der Angebotsbewertung gemäß § 19 EG VOL/A bzw. § 16 VOL/A auf der zweiten Wertungsstufe geprüft. Nur wer als geeignet bewertet wurde, kommt dabei in die nächste Wertungsstufe. Eine vergleichende Eignungsprüfung findet hierbei gerade nicht statt1. b) Übersicht zu den Eignungskriterien

212

Ein Bewerber/Bieter hat die notwendige Fachkunde2, wenn er Kenntnisse, Erfahrungen und Fertigkeiten besitzt, die für die fachgerechte Ausführung der zu vergebenen Leistung erforderlich sind. Gerade die Fachkunde kann mit Referenzen nachgewiesen werden.

213

Ein Bewerber/Bieter verfügt über die erforderliche Leistungsfähigkeit, wenn er über die personellen, kaufmännischen, technischen und finanziellen Mittel verfügt, die für die fach- und fristgerechte Ausführung notwendig sind.

214

Die Zuverlässigkeit eines Bewerbers/Bieters ist gegeben, wenn er seinen gesetzlichen Verpflichtungen nachgekommen ist und auf Grund der Erfüllung 1 S. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9 Rz. 195 m.w.N. 2 S. Eignungskriterien im Überblick UfAB V Version 2.0, Ziff. 4.15.3.

1212

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 218 N

früherer Verträge eine einwandfreie Ausführung einschließlich Gewährleistung erwarten lässt. Das Merkmal der Gesetzestreue ist im Rahmen der Vergaberechtsreform 2009 eingefügt worden, was sich zunächst so liest, als wäre die Gesetzestreue ein neues viertes Eignungsmerkmal. Überwiegend wird wohl davon ausgegangen, dass die Gesetzestreue nur ein Unterbegriff bzw. Bestandteil der Zuverlässigkeit ist1. Für diese Eignungsprüfung sollte – ebenso wie für die Leistungsbewertung – 215 die Erstellung einer jeweils eigenen Bewertungsmatrix erfolgen. Zu beachten ist allerdings, dass das Ergebnis lediglich „geeignet“ oder „nicht geeignet“ lauten kann, so dass Bewertungspunkte nur eine Entscheidungshilfe darstellen und nicht zu einer Rangfolge führen dürfen (s. UfAB V Version 2.0, Kapitel 4.15.4). c) Nachweis der Eignung Der Auftraggeber ist nicht verpflichtet, alle Nachweise zu verlangen, viel- 216 mehr soll er nur die verlangen, die er zur Beurteilung der Eignung tatsächlich benötigt. Welche Eignungsnachweise denkbar sind, ergibt sich auf EUEbene aus §§ 6, 7 EG VOL/A, auf nationaler Ebene aus § 6 VOL/A. Es kann grds. auf EU-Ebene unterschieden werden zwischen Nachweisen 217 zu: – finanzieller und wirtschaftlicher Leistungsfähigkeit (§ 7 EG Abs. 2 VOL/A) – fachlicher und technischer Leistungsfähigkeit (§ 7 EG Abs. 3 VOL/A, beinhaltet teils auch den Nachweis zur Fachkunde) – Nichtvorliegen von Ausschlussgründen, damit zur Zuverlässigkeit und Gesetzestreue (§ 6 EG Abs. 4–6 sowie § 7 EG Abs. 6 und 7 VOL/A). aa) Finanzielle und wirtschaftliche Leistungsfähigkeit Hierfür sieht § 7 EG Abs. 2 lit. a–d VOL/A folgenden Katalog vor, der in der Regel verlangt werden kann2: „2. (1) In finanzieller und wirtschaftlicher Hinsicht kann von dem Unternehmen zum Nachweis seiner Leistungsfähigkeit in der Regel folgendes verlangt werden: a) Vorlage entsprechender Bankauskünfte, b) bei Dienstleistungsaufträgen entweder entsprechende Bankerklärungen oder der Nachweis entsprechender Berufshaftpflichtversicherungsdeckung, c) Vorlage von Bilanzen oder Bilanzauszügen des Unternehmens, falls deren Veröffentlichung nach dem Gesellschaftsrecht des Staates, in dem das Unternehmen ansässig ist, vorgeschrieben ist,

1 S. u.a. Weyand, IBR-Online, Kommentar, Vergaberecht 2009, § 97 Rz. 564; Gabriel, NJW 2009, 2011, 2012; Roth, VergabeR 2009, 404. 2 S. Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 7a Rz. 21 ff.; Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 7 EG Rz. 24 ff.

Bischof

1213

218

N Rz. 219

Einzelprobleme

d) Erklärung über den Gesamtumsatz des Unternehmens sowie den Umsatz bezüglich der besonderen Leistungsart, die Gegenstand der Vergabe ist, jeweils bezogen auf die letzten drei Geschäftsjahre.“

219

Folgende zusätzliche Nachweise sind (z.T. auch vom Europäischen Gerichtshof [EuGH]) als zulässig angesehen worden: – Angabe des Gesamtwerts der einem Unternehmen zu einem bestimmten Zeitpunkt erteilten Aufträge, die gleichzeitig ausgeführt werden dürfen; – Nachweis, dass ein Unternehmen über das Minimum an Eigenmitteln und die Anzahl an Arbeitern und Führungskräften verfügt, die die innerstaatlichen Rechtsvorschriften für die Unternehmensklasse fordern, die nach diesen Vorschriften auf Grund des Umfangs der zu vergebenden Arbeiten erforderlich ist; – Nachweis über die Anzahl der durchschnittlich beschäftigten Arbeitskräfte; – Auskünfte über das für die Leitung und Ausführung vorgesehene technische Personal. bb) Fachliche und technische Leistungsfähigkeit

220

Hierfür sieht § 7 EG Abs. 3 lit. a–g VOL/A folgenden Katalog vor1: „(2) In fachlicher und technischer Hinsicht kann das Unternehmen je nach Art, Menge und Verwendungszweck der zu erbringenden Leistung seine Leistungsfähigkeit folgendermaßen nachweisen: a) durch eine Liste der wesentlichen in den letzten drei Jahren erbrachten Leistungen mit Angabe des Rechnungswertes, der Leistungszeit sowie der öffentlichen oder privaten Auftraggeber: – bei Leistungen an öffentliche Auftraggeber durch eine von der zuständigen Behörde ausgestellte oder beglaubigte Bescheinigung, – bei Leistungen an private Auftraggeber durch eine von diesen ausgestellte Bescheinigung; ist eine derartige Bescheinigung nicht erhältlich, so ist eine einfache Erklärung des Unternehmens zulässig, b) durch die Beschreibung der technischen Ausrüstung, der Maßnahmen des Unternehmens zur Gewährleistung der Qualität sowie der Untersuchungs- und Forschungsmöglichkeiten des Unternehmens, c) durch Angaben über die technische Leitung oder die technischen Stellen, unabhängig davon, ob sie dem Unternehmen angeschlossen sind oder nicht, und zwar insbesondere über diejenigen, die mit der Qualitätskontrolle beauftragt sind, d) bei Lieferaufträgen durch Muster, Beschreibungen und/oder Fotografien der zu erbringenden Leistung, deren Echtheit auf Verlangen des Auftraggebers nachgewiesen werden muss, e) bei Lieferaufträgen durch Bescheinigungen der zuständigen amtlichen Qualitätskontrollinstitute oder -dienststellen, mit denen bestätigt wird, dass die durch entsprechende Bezugnahmen genau gekennzeichneten Leistungen bestimmten Spezifikationen oder Normen entsprechen, 1 S. Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 7a Rz. 26; Müller-Wrede, VOL/A, Kommentar 3. Aufl., § 7 EG Rz. 34 ff.

1214

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 222 N

f) sind die zu erbringenden Leistungen komplexer Art oder sollen sie ausnahmsweise einem besonderen Zweck dienen, durch eine Kontrolle, die von den Behörden des Auftraggebers oder in deren Namen von einer anderen damit einverstandenenzuständigen amtlichen Stelle aus dem Land durchgeführt wird, in dem das Unternehmen ansässig ist; diese Kontrolle betrifft die Produktionskapazitäten und erforderlichenfalls die Untersuchungs- und Forschungsmöglichkeiten des Unternehmens sowie die von diesem zur Gewährleistung der Qualität getroffenen Vorkehrungen, g) durch Studiennachweise und Bescheinigungen über die berufliche Befähigung, insbesondere der für die Leistungen verantwortlichen Personen.“

Es gibt keine anderen Vorschriften in der VOL/A als §§ 6, 7 EG VOL/A bzw. 221 § 6 VOL/A, in denen aufgelistet wäre, durch welche Unterlagen die Fachkunde und Zuverlässigkeit nachgewiesen werden. Zdzieblo erwähnte hierzu noch zur „alten VOL/A“, dass die EG Richtlinien von der Eignung der Anbieter als Oberbegriff für die drei Kriterien (Leistungsfähigkeit, Zuverlässigkeit und Fachkunde) sprechen und dass die VOL/A gerade diesen „Eignungsbegriff“ nicht verwendet. Auch die SKR-Regelungen (SKR = Sektorenrichtlinie) benutzen diese Bezeichnung nicht, sondern sprechen von Qualifikation. Daher wird davon auszugehen sein, dass mit den aufgelisteten Nachweisen auch Fachkunde und Zuverlässigkeit belegt werden können. Gerade die Regelungen zum Nachweis des Nichtvorliegens von Ausschlussgründen sind wohl eindeutig der Zuverlässigkeit zuzordnen. cc) Nachweis des Nichtvorliegens von Ausschlussgründen Auf EU-Ebene sind zwei Konstellationen zu unterscheiden. § 6 EG Abs. 6 VOL/A enthält folgende Ausschlussgründe: „Von der Teilnahme am Wettbewerb können Bewerber ausgeschlossen werden, a) über deren Vermögen das Insolvenzverfahren oder ein vergleichbares gesetzliches Verfahren eröffnet oder die Eröffnung beantragt oder dieser Antrag mangels Masse abgelehnt worden ist. b) die sich in Liquidation befinden, c) die nachweislich eine schwere Verfehlung begangen haben, die ihre Zuverlässigkeit als Bewerber in Frage stellt, d) die ihre Verpflichtung zur Zahlung von Steuern und Abgaben sowie der Beiträge zur gesetzlichen Sozialversicherung nicht ordnungsgemäß erfüllt haben, e) die im Vergabeverfahren vorsätzlich unzutreffende Erklärungen in Bezug auf ihre Fachkunde, Leistungsfähigkeit und Zuverlässigkeit abgegeben haben.“

Als Nachweis zu deren Nichtvorliegen können entsprechende Bescheinigungen der zuständigen Stelle oder Erklärungen verlangt werden, § 7 EG Abs. 7 VOL/A. Hinsichtlich eines Ausschlusses steht dem Auftraggeber nach dem Wortlaut „können ausgeschlossen werden“ ein Ermessensspielraum zu. Hingegen ist ein Ausschluss wegen Unzuverlässigkeit grds. zwingend, wenn der Auftraggeber Kenntnis von einem der Ausschlussgründe des § 6

Bischof

1215

222

N Rz. 223

Einzelprobleme

EG Abs. 4 VOL/A hat. Hierbei geht es um rechtskräftige Verurteilungen von dem Unternehmen zuzurechnender Personen wegen bestimmter, im Detail aufgelisteter Straftatbestände. Hiervon kann nur abgesehen werden, wenn gem. § 6 EG Abs. 5 VOL/A entweder zwingende Gründe des Allgemeininteresses vorliegen und andere Unternehmen die Leistung nicht angemessen erbringen können oder wenn aufgrund besonderer Umstände des Einzelfalls der Verstoß die Zuverlässigkeit des Unternehmens nicht in Frage stellt. 223

Als Nachweis für das Nichtvorliegen der genannten Fälle bzw. die Unrichtigkeit einer Kenntnis des Auftraggebers ist grds. ein Bundeszentralregisterauszug bzw. gleichwertige Urkunden der zuständigen Gerichts- oder Verwaltungsbehörde des Herkunftslandes anzusehen (vgl. § 7 EG Abs. 6 VOL/A).

224

Die bisherige Praxis verlangt meist für beide vorgenannten „Ausschlussfälle“ nur entsprechende Eigenerklärungen der Bieter (unter Vorgabe von auszufüllenden „Musterformularen“, deren Verwendung zwingend vorgeschrieben wird). Dies wird nun von § 7 EG Abs. 1 Satz 2, 3 VOL/A gefordert, da vorrangig Eigenerklärungen zu fordern sind und das Verlangen nach anderen Nachweise zu begründen ist.

225

Auf nationaler Ebene enthält § 6 Abs. 5 VOL/A folgende Ausschlussgründe: „5. Von der Teilnahme am Wettbewerb können Bewerber ausgeschlossen werden, a) über deren Vermögen das Insolvenzverfahren oder ein vergleichbares gesetzliches Verfahren eröffnet oder die Eröffnung beantragt oder dieser Antrag mangels Masse abgelehnt worden ist. b) die sich in Liquidation befinden, c) die nachweislich eine schwere Verfehlung begangen haben, die ihre Zuverlässigkeit als Bewerber in Frage stellt, d) die ihre Verpflichtung zur Zahlung von Steuern und Abgaben sowie der Beiträge zur gesetzlichen Sozialversicherung nicht ordnungsgemäß erfüllt haben, e) die im Vergabeverfahren vorsätzlich unzutreffende Erklärungen in Bezug auf ihre Fachkunde, Leistungsfähigkeit und Zuverlässigkeit abgegeben haben.“

Deren Nichtvorliegen ist grundsätzlich durch die Vorlage von Eigenerklärungen nachzuweisen, § 6 Abs. 3 S. 2 VOL/A. Werden andere Nachweise als Eigenerklärungen verlangt, so muss der Auftraggeber dies in der Vergabedokumentation ausdrücklich begründen, § 6 Abs. 3 S. 3 VOL/A. dd) Nachweis der Eintragung im Berufs- oder Handelsregister 226

Dieser Nachweis kann gem. § 7 EG Abs. 8 VOL/A verlangt werden. Ob ein solcher Nachweis verlangt wird oder nicht, liegt im Ermessen der Vergabestelle; diese ist nicht gezwungen, sich solche Nachweise vorlegen zu lassen, zumal diese nichts über Fachkunde und Leistungsfähigkeit eines Unternehmens aussagen. Sinn und Zweck der Forderung dieses Nachweises ist es einerseits, die mit der Beauftragung eines Unternehmens ohne berufsrechtliche Zulassung verbundenen Risiken zu vermeiden. Andererseits kann sich 1216

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 229 N

die Vergabestelle über die Auszüge wesentliche Informationen z.B. zu Existenz, Rechtsform, Vertretungsbefugnissen und -verhältnissen beschaffen1. ee) Präqualifizierungsverfahren Unter Präqualifikation2 ist eine der eigentlichen Auftragsvergabe vorgela- 227 gerte auftragsunabhängige Prüfung der Eignungsnachweise zu verstehen. Ist diese Eignungsprüfung vom Unternehmen ohne Beanstandungen bei den hierfür vorgesehenen Prüfunternehmen durchlaufen, wird das Unternehmen auf Zeit in eine allgemein zugängliche Liste präqualifizierter Unternehmen aufgenommen und braucht nicht bei jedem Vergabeverfahren – als Beitrag zu einer Entbürokratisierung – alle Einzelnachweise dem Auftraggeber vorzulegen. Ein solches Präqualifizierungsverfahren ist im Baurecht (vgl. § 8 VOB/A) 228 vorgesehen. Bereits am 27.4.2006 wurde auf dem Deutschen Industrie- und Handelskammertag in Berlin vorgestellt, dass auch für den VOL-Bereich ein solches bundesweites Präqualifizierungssystem geschaffen werden soll, wobei die Grundüberlegungen zu Präqualifizierungsnachweisen und Qualitätsstandards weitgehend deckungsgleich mit dem im Baubereich bekannten Verfahren sind. Ziel war es, dass ein solches System für den VOL/Bereich bis zum 1.1.2008 vorbereitet wird. Eine entsprechende Ergänzung der VOL/A war zunächst nicht erfolgt. § 97 Abs. 4a GWB sieht seit Neufassung des GWB 2009 auch eine entsprechende Regelung vor. Dies wurde sodann auch in der VOL/A umgesetzt: Für EU-Vergaben sieht § 7 EG Abs. 4 VOL/A vor, dass auch Eignungsnachweise, die durch Präqualifizierungsverfahren erworben wurden, zugelassen werden können. Gleiches sieht § 6 Abs. 4 VOL/A für die nationale/Unterschwellenvergabe vor. Zwischenzeitlich wurde eine bundesweite Präqualifizierungsdatenbank unter www.pq-vol.de eingerichtet. Damit soll sowohl bei Bietern als auch der öffentlichen Hand der Aufwand zur Erstellung bzw. Prüfung der Eignungsnachweise reduziert werden, indem das Präqualifizierungsverfahren einmal durchlaufen wird und der entsprechende Nachweis bei den öffentlichen Auftraggebern (anstelle von Einzeldokumenten) zur Eignungsprüfung vorgelegt wird. Unternehmen sind nicht verpflichtet, ein solches Verfahren zu durchlaufen und können und dürfen daher ihre Eignung auch weiterhin durch die in den Verdingungsunterlagen geforderten Nachweise darlegen. Das Präqualifikationsverfahren ist dezentral nach Bundesländern organi- 229 siert. Die Präqualifizierung nehmen Industrie- und Handelskammern oder die von ihnen getragenen Auftragsberatungsstellen3 vor (PQ-Stelle). Dort werden die gebietszugehörigen Unternehmen geprüft, und die dezentralen Daten tagesaktuell an die bundesweite PQ-Datenbank übermittelt. Neben 1 S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl. 2010, Rz. 68 ff. m.w.N. 2 S.a. Braun/Petersen, VergabeR 2010, 433. 3 S. für Bayern: Auftragsberatungszentrum e.V. unter www.abz-bayern.de (auch zum Verfahren, Geltungsdauer des Zertifikats und Kosten).

Bischof

1217

N Rz. 230

Einzelprobleme

den Pflichtnachweisen erheben einige PQ-Stellen entsprechend den Vorgaben aus ihrem jeweiligen Bundesland zusätzliche landesspezifische Angaben und Nachweise. 4. Teilnahmewettbewerb aa) Auswahl der Bieter 230

Nach Ablauf der Teilnahmeantragsfrist wählt der Auftraggeber anhand der mit dem Teilnahmeantrag vorgelegten Unterlagen (entsprechend den geforderten Nachweisen) diejenigen Bewerber aus, die den Anforderungen an Fachkunde, Leistungsfähigkeit und Zuverlässigkeit entsprechen (§ 10 EG Abs. 1 VOL/A). Damit soll erreicht werden, dass nur solche Bewerber ausgewählt werden, die tatsächlich in der Lage sind, den zu vergebenden Auftrag auszuführen und dass die Zahl der Bewerber auf eine überschaubare Anzahl reduziert wird1.

231

Die Bewerber haben keinen Anspruch, zur Angebotsabgabe aufgefordert zu werden, wenn sie sich mit einem Teilnahmeantrag am Vergabeverfahren beteiligt haben2. Dies ergibt sich auch deutlich aus dem Wortlaut des § 10 EG Abs. 1 VOL/A, da der Auftraggeber aus dem Kreis der Bewerber auswählt.

232

Bei der Auswahl der zur Angebotsabgabe aufzufordernden Bieter besitzt der Auftraggeber einen eigenen Ermessens- und Beurteilungsspielraum unter Beachtung der Grundsätze der Verhältnismäßigkeit und Gleichbehandlung, insbesondere des Willkürverbots3. Die Beurteilung der Eignung rein anhand schematischer, nicht einzelfallbezogener Checklisten ist ungeeignet, da weder eignungs- noch leistungsbezogen4. Von wesentlicher Bedeutung ist daher eine nachvollziehbare Begründung für einen Ausschluss vom weiteren Verfahren. Es dürfen keine 1 S. Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 50 ff.; s.a. Gnittke/Hattig, in: Müller-Wrede, VOL/A Kommentar, 3. Aufl, § 10 EG Rz. 5 f. m.w.N. 2 S. Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 53 unter Hinweis auf den Beschluss des Vergabeüberwachungsausschuss Nordrhein-Westfalen v. 10.11.1998, 424-84.45-12/98; Zdzieblo, in: Daub/Eberstein, VOL/A, Kommentar, § 7a Rz. 49 f. erläutert noch deutlicher, dass der Auftraggeber nicht verpflichtet ist, alle Bewerber, die die geforderten Unterlagen beigebracht haben und die die genannten Eignungsmerkmale aufweisen, eine Angebotsaufforderung zukommen zu lassen, dies ergebe sich schon aus dem Wortlaut der Vorschrift des § 7a Nr. 3 VOL/A, nämlich: „… 3. Ist ein Teilnahmewettbewerb durchgeführt worden, so wählt der Auftraggeber anhand der … geforderten … Unterlagen unter den Bewerbern, die den Anforderungen an Fachkunde, Leistungsfähigkeit und Zuverlässigkeit entsprechen, diejenigen aus, …“. S.a. Gnittke/Hattig, in: MüllerWrede, VOL/A, Kommentar, 3. Aufl, § 10 EG Rz. 12. 3 S. Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 54; Zdzieblo, in: Daub/ Eberstein, VOL/A, Kommentar, § 7a Rz. 49 f.; s.a. Gnittke/Hattig, in: MüllerWrede, VOL/A, Kommentar, 3. Aufl., § 10 EG Rz. 7 ff. m.w.N. 4 S. Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 54 f.

1218

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 234 N

Kriterien herangezogen werden, die sich – z.B. nach der Vergabebekanntmachung – eindeutig ausschließlich auf die Zuschlagsentscheidung beziehen1. bb) Fehlen von Unterlagen Fehlen in einem Teilnahmeantrag wichtige Angaben oder Nachweise zu den Mindestanforderungen, so ist ein Ausschluss dieses Bewerbers (= Absehen von einer weiteren Beteiligung) nicht ermessensfehlerhaft2.

233

§ 7 EG Abs. 13 VOL/A wiederum ermöglicht dem Auftraggeber aber, einzelne Unternehmen aufzufordern, die von ihnen vorgelegten Bescheinigungen zu vervollständigen oder zu erläutern. Ob der Auftraggeber dies tut, steht jedoch in seinem Ermessen, eine Verpflichtung besteht nicht. Der Auftraggeber kann aber keine über die ursprünglichen hinausgehenden Nachweise verlangen3. Ebenso wenig darf der Auftraggeber unvollständige Nachweise – etwa im Rahmen eines Aufklärungsgesprächs – ergänzen lassen. Es stellt sich allerdings die Frage, ob die Regelung des § 19 EG Abs. 2 VOL/A, nach der Erklärungen und Nachweise nachgefordert werden dürfen, wenn sie nicht mit dem Angebot vorgelegt werden, entsprechend auf das Fehlen von Eignungsnachweisen im Teilnahmewettbewerb angewandt werden kann. Dies wird kontrovers diskutiert: Es lässt sich durchaus eine vergleichbare Situation erkennen, wenn man darauf abstellt, dass § 19 EG Abs. 2 auch den Zweck verfolgt, übertriebenen Formalismus zu vermeiden4. Nach anderer Ansicht ist eine dezidierte Betrachtung erforderlich, denn § 19 EG VOL/A betrifft eine andere Phase des Vergabeverfahrens, nämlich die Angebotswertung, so dass eine Nachforderung im Teilnahmewettbewerb gerade nicht intendiert war5. cc) Information der ausscheidenden Bewerber § 101a GWB bringt klar zum Ausdruck, dass „abgelehnte Bewerber“ über 234 ihr Ausscheiden informiert werden sollen, denn wird ein Bewerber nicht über die Ablehnung seines Teilnahmeantrags (d.h. seiner Bewerbung) informiert, so muss ein solcher – eigentlich längst ausgeschiedener – Bewerber ebenfalls gemäß § 101a Abs. 1 Satz 2 i.V.m. Satz 1 GWB eine Information vor Zuschlagserteilung erhalten (und wird damit wie ein „Bieter“ behandelt). § 22 EG Abs. 1 VOL/A sieht zudem auch vor, dass der Auftraggeber den nicht berücksichtigten Bewerbern die Gründe für die Nichtberücksichti1 2 3 4

S. OLG Bremen, BauRB 2004, 173. S. Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 55. Müller-Wrede, VOL/A, Kommentar, 2001, § 7a Rz. 61 ff. So Gnittke/Hattig, in: Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 10 EG Rz. 7 ff. m.w.N. 5 Vgl. Lirsch, CR 2011, 691. S. zur Europarechtskonformität der Nachforderungsregelungen Mantler, VergabeR 2013, 175.

Bischof

1219

N Rz. 235

Einzelprobleme

gung unverzüglich, spätestens innerhalb von 15 Tagen nach Eingang eines entsprechenden Antrags, mitzuteilen hat1. 235

Die Bewerber haben keinen Anspruch darauf, über die Merkmale und Vorteile der erfolgreichen Bewerber und über den Namen der erfolgreichen Bewerber informiert zu werden. Somit darf in der Begründung folgendes nicht angegeben werden: – Name der Bewerber, die zur Angebotsabgabe aufgefordert wurden; – konkrete Merkmale und Vorteile der Bewerber, die zur Angebotsabgabe aufgefordert wurden; in abstrakter Weise wird dies jedoch für zulässig erachtet. Auch dürfen keine Informationen enthalten sein, die gem. § 12 Abs. 4 VOL/A bzw. § 15 EG Abs. 12 VOL/A vertraulich zu behandeln oder geheim zu halten sind. Bei einer ausreichenden Anzahl von insgesamt geeigneten Bewerbern genügt es für die bestehende Informationspflicht in mehr allgemeiner Form die Gründe zu nennen und dabei auch die Freiheit zu nutzen, welche Ablehnungsgründe im Einzelnen angegeben werden. Es müssen nicht sämtliche Ablehnungsgründe genannt werden. Der Auftraggeber ist zumindest im Rahmen des § 22 EG Abs. VOL/A (noch) frei, welche Ablehnungsgründe im Einzelnen angegeben werden. In Frage kommt die gesamte Bandbreite von Gründen, die zur Nichtberücksichtigung führen können2. Es sollte dem antragstellenden Bewerber aber aufgezeigt werden, warum er nicht zum Kreis der zur Angebotsabgabe Aufgeforderten gehört. Hierbei darf sich der Auftraggeber auf die Gesichtspunkte beschränken, die eine mangelnde Fachkunde, Leistungsfähigkeit sowie Zuverlässigkeit (Eignung) des Bewerbers begründen.

236

Das Absageschreiben könnte beispielsweise wie folgt aufgebaut sein: Sehr geehrte Damen und Herren, leider müssen wir Ihnen (ggf. auf Ihre Anfrage vom …) mitteilen, dass Ihre Bewerbung nicht zum Zuge gekommen ist und Ihr Unternehmen nicht zur Angebotsabgabe aufgefordert wird. Die maßgeblichen Gründe sind die folgenden: Es hat sich eine ausreichende Anzahl von geeigneten Bewerbern beworben, unter denen anhand der Kriterien „Fachkunde, Leistungsfähigkeit und Zuverlässigkeit“ die Auswahl stattfand. Von besonderer Bedeutung war hierbei … (z.B. möglichst zahlreiche Installationen mit weitestgehend ähnlichem Leistungs-

1 Mit diesen Neuregelungen ist der länger schwelende Streit darüber, ob abgelehnte Bewerber zu informieren sind oder nicht (vgl. die alten Regelungen des § 13 VgV und § 27a VOL/A) beigelegt. 2 S. Roth, in: Müller-Wrede, VOL/A Kommentar, § 27a Rz. 8.

1220

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 239 N

umfang in anderen Unternehmen in vergleichbarer Größe). Im Vergleich mit den anderen Bewerbern konnte Ihr Unternehmen daher nicht berücksichtigt werden. Zur Ablehnung Ihrer Bewerbung führte vor allem … (Einzelfallbegründung). Wir danken nochmals für Ihr Interesse an unserem Vergabeverfahren. Mit freundlichen Grüßen

5. Aufforderung zur Angebotsabgabe Bei einem ausreichenden Kreis geeigneter Bewerber darf beim Verhandlungsverfahren gem. § 3 EG Abs. 5 Satz 3 VOL/A die Anzahl der zur Verhandlung zugelassenen Unternehmen nicht unter drei, beim nichtoffenen Verfahren nicht unter fünf liegen. Diese Unternehmen sind unter Übersendung der Vergabeunterlagen gem. § 10 EG Abs. 1 VOL/A (s. hierzu Rz. 134 ff.) zur Angebotsabgabe aufzufordern.

237

Die Vergabeunterlagen bestehen dabei gem. § 9 EG Abs. 1 VOL/A aus

238

– dem Anschreiben (Aufforderung zur Angebotsabgabe), – der Beschreibung der Einzelheiten der Durchführung des Verfahrens, einschließlich der Angabe der Zuschlagskriterien und deren Gewichtung (sofern nicht bereits in der Vergabebekanntmachung genannt, – den Vertragsunterlagen (Leistungsbeschreibung und Vertragsbedingungen). Der Inhalt dieses Anschreibens orientiert sich an § 10 EG Abs. 2 VOL/A, so- 239 weit dies zweckmäßig ist und könnte z.B. wie folgt lauten:

1 Grundsätzliche Bestimmungen Die Vergabeunterlagen dürfen nur zur Erstellung eines Angebots verwendet werden. Jede Veröffentlichung und Weitergabe an Dritte (auch auszugsweise) ist ohne die ausdrückliche Genehmigung der vergebenden Stelle nicht statthaft. Ergänzende oder berichtigende Angaben zur Auftragsvergabe werden allen Bietern schriftlich mitgeteilt. 2 Aufschrift und Form der Angebote Das Angebot sowie alle Anlagen hierzu (= sämtliche Angebotsunterlagen) sind in schriftlicher Form mit Datum versehen und unterschrieben in … Ausfertigung und einmal in elektronischer Form auf einer CD-Rom im Format von … in einen fensterlosen Briefumschlag oder vergleichbaren Versandbehälter zu stecken und zu verschließen. Der Briefumschlag ist mit der Firmenanschrift und mit der Aufschrift Nicht öffnen! Bischof

1221

N Rz. 239

Einzelprobleme

Angebot zum Vergabeverfahren „…“ zu versehen. Der so gekennzeichnete Umschlag ist in einem weiteren (äußeren) Briefumschlag oder vergleichbaren Versandbehälter unterzubringen. Das Angebot muss vor Ablauf der Angebotsfrist beim … eingegangen sein. Später eingehende Angebote werden nicht berücksichtigt. Die Angebote können per Post, Paketdienst, aber auch unmittelbar durch Abgabe beim Auftraggeber, zu Händen von Herrn … zugestellt werden. Andere Zustellungsformen (z.B. elektronische Post, Telefax etc.) sind nur ergänzend möglich und ersetzen die oben genannte Form nicht. Bei Abweichung der elektronischen Fassung von der schriftlichen Fassung des Angebots samt aller Anlagen (Angebotsunterlagen) gilt die schriftliche Fassung als verbindlich. Die Identität der schriftlichen und elektronischen Form ist ausdrücklich zu bestätigen. 3 Fristen Die Angebotsfrist endet mit Ablauf des … Der Bieter kann sein Angebot nur bis zum Ablauf der Angebotsfrist schriftlich berichtigen oder zurückziehen. Die Zuschlagsfrist beginnt mit dem Ablauf der Angebotsfrist. Der Auftraggeber wird den Zuschlag möglichst bis …, spätestens aber am … erteilen. Der Bieter ist bis zum Ablauf der Zuschlagsfrist an sein Angebot gebunden. 4 Fragen zur Auftragsvergabe Fragen zur Auftragsvergabe können schriftlich bis einschließlich … unter dem Stichwort „…“ an … gerichtet werden. Die Beantwortung wird schriftlich erfolgen. 5 Inhalt des Angebots Das Angebot muss die Preise und alle sonstigen geforderten Angaben und Erklärungen enthalten. Alle Preise sind in Euro mit gesondert ausgewiesener Umsatzsteuer anzugeben. Sofern die Vergabegegenstände nicht vom Hersteller der Software selbst, sondern von einem Dritten angeboten werden, hat der Bieter sicherzustellen und nachzuweisen, dass der Softwarehersteller mit dem Angebot durch einen Dritten einverstanden ist und dieser bei Bedarf notwendige Anpassungen seiner Software gemäß der Vereinbarung zwischen Auftraggeber und Bieter vornimmt bzw. durch den Bieter vornehmen lässt. Soweit weitergehende Erläuterungen zur Beurteilung des Angebots erforderlich erscheinen, kann der Bieter sie auf besonderer Anlage dem Angebot beifügen. Sie dürfen jedoch nur kommentierenden, nicht aber fordernden Charakter haben. Das Angebot muss in deutscher Sprache verfasst und unterschrieben sein. Bei Generalunternehmerschaft muss das Angebot vom Generalunternehmer unterschrieben sein. Es ist eine Anlage beizufügen, in dem die vom Gene-

1222

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 239 N

ralunternehmer beizuziehenden Unternehmen genannt werden und die beizuziehenden Unternehmen ihre Bereitschaft zur Beiziehung erklären. Soweit die vom Bieter vorgenommenen, eigenen Eintragungen durch den Bieter wieder geändert wurden, muss dies zweifelsfrei erkennbar sein. Änderungen und Ergänzungen an den Vergabeunterlagen sind unzulässig und führen zum Ausschluss. Fabrikations-, Betriebs- oder Geschäftsgeheimnisse sind in den Angebotsunterlagen entsprechend kenntlich zu machen. Im Rahmen der Verhandlungen ist vorgesehen, dass … 6 Wettbewerbsbeschränkende Verhaltensweisen Wettbewerbsbeschränkende Absprachen gem. § 1 des Gesetzes gegen Wettbewerbsbeschränkungen (GWB vom 26.8.1998 – BGBl. I, S. 2546) sind nicht zulässig, insbesondere Verabredungen oder Empfehlungen über – – – – –

Gewinnaufschläge Gewinnbeteiligung die zu fordernden Preise Entrichtung von Ausfallentschädigungen oder Abstandszahlungen u.Ä. Zahlungs-, Lieferungs- oder andere Vertragsbedingungen, soweit sie unmittelbar oder mittelbar den Preis beeinflussen, es sei denn, dass sie im Einzelfall nach Maßgabe des GWB ausnahmsweise zulässig sind – Abgabe oder Nichtabgabe von Angeboten. 7 Generalunternehmerschaft Beabsichtigt der Bieter als Generalunternehmer aufzutreten, so hat er anzugeben, welche weiteren Unternehmen von ihm einbezogen werden sollen. Der Generalunternehmer hat sich zu bemühen, Unteraufträge an kleine und mittlere Unternehmen in dem Umfang zu erteilen, wie er es mit der vertragsgemäßen Ausführung der Leistung vereinbaren kann. 8 Schutzrechte Im Angebot ist anzugeben, ob für den Gegenstand des Angebots gewerbliche Schutzrechte bestehen oder vom Bieter oder anderen beantragt sind oder werden. 9 Änderung, Berichtigung und Rücknahme von Angeboten Nachträgliche Änderungen oder Berichtigungen der Angebote sind als solche zu kennzeichnen und müssen in einem verschlossenen Umschlag (wie das Angebot selbst) zugestellt werden. Änderungen oder Berichtigungen sind nur bis zum Ablauf der Angebotsfrist zulässig. Bis zum Ablauf der Angebotsfrist können solche Änderungen oder Berichtigungen schriftlich ebenso wie das Angebot selbst unter Berücksichtigung der Formanforderungen nach Ziff. 2 zurückgezogen werden.

Bischof

1223

N Rz. 239

Einzelprobleme

10 Vergütung/Kostenerstattung für die Bearbeitung des Angebots Für die Erstellung des Angebots wird keine Vergütung gewährt. Dem Angebot beigefügte Unterlagen, Muster usw. gehen, sofern nichts anderes vereinbart, ohne Anspruch auf Vergütung in das Eigentum des Auftraggebers über. 11 Nebenangebote und Änderungsvorschläge Nebenangebote und Änderungsvorschläge sind nur in Verbindung mit einem Hauptangebot zugelassen. 12 Zuschlagserteilung Die Entscheidung über den Zuschlag (Zuschlagserteilung) wird innerhalb der Zuschlagsfrist schriftlich mitgeteilt. Der Zuschlag wird auf das wirtschaftlichste Angebot erteilt. Die Zuschlagskriterien sind in … näher bezeichnet und erläutert. Wird der Zuschlag auf das Angebot rechtzeitig und ohne Änderung erteilt, ist der Vertrag zu den Vorgaben dieser Auftragsvergabe auf der Grundlage des Angebots rechtsverbindlich zustande gekommen; dies gilt unbeschadet einer evtl. späteren urkundlichen Festlegung. Das Angebot ist nicht berücksichtigt worden, wenn bis zum Ablauf der Zuschlagsfrist kein Auftrag erteilt wurde. 13 Mitteilung über nicht berücksichtigte Angebote Alle Bieter, deren Angebote nicht berücksichtigt werden sollen, werden gemäß § 13 der Vergabeverordnung spätestens 14 Kalendertage vor der Zuschlagserteilung schriftlich über den Namen des Bieters, dessen Angebot angenommen werden soll, und über den Grund der vorgesehenen Nichtberücksichtigung ihres Angebots informiert. 14 Hinweise für die Erstellung eines Angebots Das Angebot ist aus den in der Leistungsbeschreibung formulierten Fragen und Forderungen unter Beachtung der in der Leistungsbeschreibung dargestellten Hinweise zu erstellen. Das Angebot muss auf der Leistungsbeschreibung basieren. Das Angebot ist nach folgender Gliederung zusammen zu stellen. Die einzelnen Gliederungspunkte sind durch ein Register zu trennen: a) Formloses Anschreiben mit Datum und Unterschrift b) Formular für die Angebotsabgabe (inklusive Preisblatt) Anlage … c) Eigenerklärungen zu Fachkunde, Leistungsfähigkeit und Zuverlässigkeit, Anlage … d) Ggf. Kenntlichmachung der Fabrikations-, Betriebs-, Geschäftsgeheimnisse in den Angebotsunterlagen Anlage … e) Detaillierte Angebotsdarlegung gemäß Leistungsbeschreibung f) Ggf. sonstige Anlagen Erläuterung zu den einzelnen Teilen des Angebots: … Ergänzend wird auf § 19 EG VOL/A verwiesen. 1224

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 242 N

15 Nachprüfungsverfahren Unbeschadet der Prüfungsmöglichkeiten von Aufsichtsbehörden unterliegt die Vergabe öffentlicher Aufträge der Nachprüfung durch die Vergabekammern. Ein Antrag auf ein Nachprüfungsverfahren nach §§ 102 ff. GWB v. 26.8.1998. BGBl. I., S. 2547 (GWB) ist schriftlich zu stellen und an die … Vergabekammer) … zu richten. Für Amtshandlungen der Vergabekammern werden Kosten (Gebühren und Auslagen) zur Deckung des Verwaltungsaufwandes erhoben (§ 128 GWB). 16 Anlagen …

Eine Angebotsfrist für ein Verhandlungsverfahren ist in § 12 EG VOL/A 240 nicht ausdrücklich vorgesehen1. Eine solche Frist ist allerdings erforderlich und notwendig, da der Auftraggeber nur dann sicher sein kann, dass alle Angebote zu einem bestimmten Zeitpunkt vorliegen, um diese gemeinsam prüfen, bewerten und gegebenenfalls darüber verhandeln zu können. Die Angebotsfrist sollte sich an der Komplexität der zu beschaffenden IT-Leistungen orientieren; sinnvollerweise wird die Mindestangebotsfrist des nichtoffenen Verfahrens (40 Tage ab dem Tag der Aufforderung zur Angebotsabgabe, § 12 EG Abs. 5 VOL/A) angesetzt2. Zu Recht weisen die UfAB V darauf hin, dass ausreichende Fristen vorzusehen sind und dass bei Fristsetzungen der Gleichbehandlungsgrundsatz zu beachten ist, d.h. allen Bietern sind die gleichen Fristen zu setzen3. Die Bieter sind berechtigt, zusätzliche Auskünfte zu den erhaltenen Verdin- 241 gungsunterlagen zu verlangen. Der Auftraggeber muss solch rechtzeitig angeforderte zusätzliche Auskünfte über die Verdingungsunterlagen und das Anschreiben spätestens sechs Tage vor Ablauf der Angebotsfrist erteilen, § 12 EG Abs. 8 VOL/A. Hierbei hat der Auftraggeber auch darauf zu achten, dass solche Auskünfte allen Bietern zu erteilen sind, um „Wissensvorsprünge“ Einzelner zu verhindern und um sich nicht dem Vorwurf der „Ungleichbehandlung“ auszusetzen. Dem Auftraggeber ist zu raten, eine Frist zur Fragestellung zu setzen, auch damit für die Beantwortung von Fragen ausreichend Zeit bleibt. 6. Angebote a) Vorgaben für die Bieter Jeder Bieter kann nur davor gewarnt werden, in seinem Angebot Änderun- 242 gen gegenüber den vom Auftraggeber übermittelte Vergabeunterlagen vor1 S. von Baum, in: Müller-Wrede, VOL/A, Kommentar, § 18a Rz. 26. 2 S. Eberstein, in: Daub/Eberstein, VOL/A, Kommentar, § 18 Rz. 3 a.E., 13 ff. 3 Vgl. UfAB V, Version 2.0, Ziff. 4.11.

Bischof

1225

N Rz. 243

Einzelprobleme

zunehmen (vgl. § 19 EG VOL/A). Gemeint ist damit jegliche Abweichung von den Vergabeunterlagen, also in Bezug auf Leistungsbeschreibung, vertragliche Gestaltung, Rahmenbedingungen u.ä. Unzulässig sind daher insbesondere: – Aufnahme von Zusätzen, – Entfernung von Bestandteilen der Vergabeunterlagen, – Abweichung von den in den Vergabeunterlagen vorgegebenen Vertragsbedingungen: – Insbesondere die Beifügung von AGB der Bieter stellt eine solche unzulässige Abweichung von den Vergabeunterlagen dar, die zwingend zum Ausschluss führt. b) Öffnung durch die Vergabestelle 243

Für die eingehenden Angebote und deren Öffnung sieht § 17 EG VOL/A ein streng formalisiertes Verfahren vor. Daraus folgt, dass die Angebote bis zum Ablauf der Angebotsfrist unter Verschluss und geheim zu halten sind. Die Öffnung muss von mindestens zwei Vertretern des Auftraggebers gemeinsam durchgeführt und dokumentiert werden. Bieter sind nicht zugelassen. Der Mindestinhalt der geforderten Dokumentation ergibt sich aus § 17 EG Abs. 2 Satz 3 VOL/A (Name und Anschrift der Bieter, Preisangaben, Nebenangebote)1. 7. Verhandlungen mit den Bietern

244

Bei den meisten Vergabearten gilt das Verhandlungsverbot des § 18 EG VOL/A (bzw. § 15 Satz 2 VOL/A). Diese ist jedoch beim Verhandlungsverfahren (bzw. der freihändigen Vergabe) gerade nicht anwendbar. Gleiches gilt auch in der Dialogphase des wettbewerblichen Dialogs.

245

Daher kann der öffentliche Auftraggeber mit den Bietern nach Prüfung der Angebote in die Verhandlung insbesondere hinsichtlich der angebotenen Leistung, des angebotenen Preises, gegebenenfalls auch der Vertragsbedingungen eintreten. Falls ein Nachweis der Leistungen von den Bietern verlangt wird („Proof of Solution“) ist es sinnvoll, zunächst hiermit zu beginnen und erst im Anschluss weiter über Leistungen, Preis und Vertragsgestaltung zu verhandeln. Ggf. kann es aber auch sinnvoll sein, solche Test1 Die Neuregelung des § 17 EG VOL/A beseitigt eine nach altem Recht bestehende Unsicherheit: § 22 VOL/A („alt“) sprach in der Überschrift nur von „Ausschreibungen“, so dass hieraus in Verbindung mit der Regelung des § 22 Nr. 6 Abs. 4 VOL/A („alt“) gefolgert wurde, dass die Vorschrift für das Verhandlungsverfahren keine Anwendung findet (s.a. Daub/Eberstein/Eberstein, VOL/A, Kommentar, 2001, § 22 Rz. 49). Dennoch erschien die entsprechende Anwendung der Regelungen im Hinblick auf die notwendige Vertraulichkeit als angebracht. Der Wortlaut des § 17 EG VOL/A hingegen ist klar: Die Regelung gilt für alle Verfahrensarten.

1226

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 248 N

stellungen u.ä. nur vom „Bestbieter“ zu verlangen, da diese meist auch mit erheblichem Aufwand für die Bieter verbunden sind. Für Verhandlungen muss der Auftraggeber im Hinblick auf eine bestehende Zuschlagsfrist bereits bei Planung des Verhandlungsverfahrens entsprechende Zeit einkalkulieren, insbesondere wenn mehrere Bieter für die Verhandlungen in Betracht kommen. In der Regel bedarf es mehrerer Verhandlungsrunden, die stets unter Beachtung der Vergabegrundsätze durchzuführen sind und entsprechend protokolliert/dokumentiert werden müssen. Es kann sich anbieten, mit allen Bietern zu verhandeln und abschließend 246 deren letzte – vergleichbare – Angebote zur endgültigen Wertung anzufordern („Last Call-Verfahren“). Denkbar ist es auch, nur mit dem bevorzugten Bieter („bester Bieter“ bei Anwendung der Zuschlagskriterien) zu verhandeln („Preferred Bidder-Verfahren“), und nur bei Scheitern der Verhandlungen mit dem nächstplazierten Bieter Verhandlungen aufzunehmen. Fraglich ist jedoch, ob solche „Preferred Bidder-Verfahren“ noch zulässig sind, da Art. 44 Abs. 4 VKR klar vorschreibt, dass in einer Schlussphase noch so viele Angebote vorliegen müssen, dass ein echter Wettbewerb gewährleistet ist (sofern eine ausreichende Anzahl geeigneter Bieter überhaupt vorliegt). Gleiches findet sich auch in § 3 EG Abs. 6 VOL/A. Der Auftraggeber muss – unabhängig vom angewandten Weg – bei seinen Ver- 247 handlungen die Vergabegrundsätze, insbesondere Transparenz und Gleichbehandlung, wahren1; ein wechselseitiges Ausspielen der Bieter durch Preisverhandlungen, um den Preis so weit wie möglich nach unten zu drücken, darf jedoch nicht stattfinden2; die jeweiligen Verhandlungsergebnisse sind nachvollziehbar zu dokumentieren. 8. Bewertung der Angebote a) Einleitung § 19 EG VOL/A fasst die Prüfung und Wertung der Angebote in einer Vor- 248 schrift zusammen. Aus den ergänzenden Erläuterungen zu § 16 VOL/A (nationale Ebene) ist zu entnehmen, dass aus der Anordnung der Absätze keine verbindliche Prüfungs- und Wertungsreihenfolge abzuleiten ist. Dies schien die Aufgabe der etablierten „Wertungspyramide“ zu sein. Die Literatur3 geht jedoch einhellig davon aus, dass – auch wenn die Regelung des § 19 EG VOL/A die Wertungspyramide nur rudimentär durchscheinen lässt – die Angebotswertung in vier voneinander zu unterscheidenden Phasen abläuft, was der bisherigen Wertungspyramide letztlich entspricht:

1 S. hierzu Müller-Wrede, VOL/A, Kommentar, § 24 Rz. 30 ff. 2 S. Müller-Wrede, VOL/A, Kommentar, § 24 Rz. 32. 3 Müller-Wrede/Horn/Roth, in: Müller-Wrede, VOL/A, Kommentar, 3. Aufl. 2010, § 19 EG Rz. 4.

Bischof

1227

N Rz. 249

Einzelprobleme

– Auf der ersten Stufe werden diejenigen Angebote ausgeschieden, die unter formalen oder inhaltlichen Mängeln leiden (§ 19 EG Abs. 1 bis 4 VOL/A). – Auf der zweiten Stufe werden die Bieter im Hinblick ihre Eignung überprüft (§ 19 EG Abs. 5 VOL/A). – In der dritten Stufe werden Angebote ausgesondert, bei denen der Preis in offenbarem Missverhältnis zur Leistung steht (§ 19 EG Abs. 6 VOL/A). – Auf der vierten Stufe wird das wirtschaftlichste Angebot entsprechend den bekannt gegebenen Zuschlagskriterien ermittelt (§ 19 EG Abs. 8, 9 VOL/A i.V.m. § 21 EG Abs. 1 VOL/A). b) Zwingende Ausschlussgründe 249

§ 19 EG Abs. 3 VOL/A sieht zwingende Ausschlussgründe vor. Dies heißt, dass der Auftraggeber bei Vorliegen eines der genannten Gründe keinen Entscheidungsspielraum hat. Ein solches Angebot ist zwingend auszuschließen1. Ggf. für einen Bieter eine harte, aber gesetzlich gewollte Sanktion stellen folgende Gründe dar: – – – –

250

Fehlen von geforderten Erklärungen und Nachweisen2 Fehlen einer Unterschrift3 Zweifelhafte Änderungen des Bieters an seinen eigenen Eintragungen4 Änderungen oder Ergänzungen an den Verdingungsunterlagen im Angebot des Bieters5

Zu beachten ist bei bis zum Ablauf der Angebotsfrist fehlender Erklärungen und Nachweisen, dass diese gem. § 19 EG Abs. 2 VOL/A vom Auftraggeber unter einer zu bestimmenden Nachfrist nachgefordert werden können6. Ungeklärt ist, ob die Regelung auch auf die bis zum Ablauf der Bewerbungsfrist nicht vorliegenden Erklärungen und Nachweise nachgefordert werden können7. Der Auftraggeber hat grundsätzlich sowohl ein Entscheidungsermessen („Ob“ der Nachforderung) als auch ein Auswahlermessen („Wie“ der Nachforderung). Dieses Ermessen ist durch die Nachprüfungsorgane nur im Hinblick auf Ermessensfehler überprüfbar. Allerdings kann auch hier in 1 S. Müller-Wrede/Horn in Müller-Wrede, VOL/A Kommentar 3. Auflage 2010, § 19 EG Rz. 79 ff. 2 S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 84 ff. 3 S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 109 ff. 4 S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 118 ff. 5 So z.B. auch durch Beifügung von AGB; s. im Detail auch Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 128 ff. (131). 6 S. Mantler, VergabeR 2013, 175 zur Europarechtskonformität der Nachforderungsregelung. 7 S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 29 ff. (53). S.a. Lirsch, CR 2011, 691.

1228

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 254 N

Einzelfällen eine Ermessensreduktion auf Null bestehen: So wird bei Fehlen der gleichen Nachweise bei zwei Bietern der Auftraggeber entweder beide Nachweise oder keinen nachfordern, nicht aber nur einen Bieter zur Nachreichung auffordern können1. Allerdings gilt die Möglichkeit zur Nachforderung nicht für Preisangaben, es sei denn, es handelt sich nur um „unwesentliche Einzelpositionen, deren Einzelpreise den Gesamtpreis nicht verändern oder die Wertungsreihenfolge und den Wettbewerb nicht beeinträchtigen.“2 aa) Fakultative Ausschlussgründe Bei den Gründen des § 19 EG Abs. 4 VOL/A i.V.m. § 6 EG Abs. 6 VOL/A hat der Auftraggeber dagegen einen Ermessensspielraum: Er kann ausschließen oder werten. Allerdings kann, falls mehrere der in § 6 EG Abs. 6 VOL/A genannten Gründe vorliegen, aus Gründen der Gleichbehandlung auch hier das Ermessen im Einzelfall auf Null reduziert sein, so dass ein Ausschluss des Bieters zu erfolgen hat3.

251

bb) Eignungsprüfung Gemäß § 19 EG Abs. 5 VOL/A soll der Auftraggeber die Bieter aussortieren können, von deren persönlicher und fachlicher Eignung4 er nicht überzeugt ist. Siehe zur Eignungsprüfung bereits oben unter Rz. 210 ff.

252

cc) Angemessenheit des Preises Bevor der Auftraggeber zur abschließenden Wertung in § 19 EG Abs. 8 253 VOL/A übergeht (Wirtschaftlichkeitsprüfung), muss eine Vorprüfung erfolgen, in deren Rahmen die Angemessenheit der Preise sowie das Preis-Leistungs-Verhältnis insgesamt im Mittelpunkt stehen. Hierbei geht es um besondere Auffälligkeiten bei den Preisen, um letztlich in der letzten Wertungsstufe nur noch mit wirklich seriös kalkulierten Angeboten konfrontiert zu sein. Die Vergabestelle hat hier eine allgemeine Aufklärungspflicht5. dd) Wirtschaftlichstes Angebot § 19 EG Abs. 8, 9 VOL/A bildet die vierte und letzte Wertungsstufe und 254 damit die endgültige Auswahl und „Bezuschlagung“ des wirtschaftlichsten 1 2 3 4

S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 55 ff. (61–63). S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 67 ff. m.w.N. S. Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 162 ff. In Verfahren mit Teilnahmewettbewerb ist die Eignungsprüfung bereits im Rahmen des Teilnahmewettbewerbs abgeschlossen: Nur geeignete Bewerber werden überhaupt zur Angebotsabgabe aufgefordert. Eine Eignungsprüfung im Rahmen der Wertung gem. § 19 EG VOL/A findet dann nicht mehr statt. 5 S. Müller-Wrede/Horn, in: Müller-Wrede, VOL/A, Kommentar, 3. Aufl., § 19 EG Rz. 171 ff.

Bischof

1229

N Rz. 255

Einzelprobleme

Angebots. Wie bereits oben dargestellt, kann die Auftragsvergabe nach dem Kriterium der Wirtschaftlichkeit erfolgen, bei dem zum Preis weitere Unterkriterien hinzukommen (siehe zu den Zuschlagskriterien unter Rz. 155 ff.). 9. Zuschlagserteilung, Informations- und Wartepflicht gem. § 101a GWB 255

Dem entsprechend Rz. 248 ff. ermittelten „besten Bieter“ ist der Zuschlag zu erteilen (§ 18 bzw. § 21 EG VOL/A).

256

Auf EU-Ebene ist zudem die Informations- und Wartepflicht des § 101a GWB zu erfüllen. Es gelten hierbei folgende Anforderungen: Neben dem Namen des Bieters, der den Zuschlag erhalten soll, sind nun zudem anzugeben: – Die Gründe der Nichtberücksichtigung der unterlegenen Bieter: Der bisherige Wortlaut des § 13 VgV sprach nur vom „Grund der Nichtberücksichtigung“, so dass nicht sämtliche Gründe zu nennen waren, sondern letztlich der bzw. die ausschlaggebenden/wichtigsten Gründe. Dies stellt eine Anspannung der Pflichten der Vergabestelle dar und ermöglicht dem Bieter auf der anderen Seite eine umfassendere Information hinsichtlich des Misserfolgs seines Angebots, was mehr Transparenz schafft und zudem auch leichter die Prüfung ermöglicht, ob die Entscheidung vom unterlegenen Bieter akzeptiert wird. – Den frühestmöglichen Zeitpunkt des Vertragsschlusses: Dieses genaue Datum musste sich der Bieter bisher selbst ermitteln; nun ist der Auftraggeber in der Pflicht, den Zeitpunkt im Informationsschreiben selbst anzugeben. Der Kreis der zu Informierenden ist eindeutig klargestellt: – Bieter1 sind zu informieren; diese gelten als betroffen, wenn sie noch nicht endgültig ausgeschlossen wurden. Der endgültige Ausschluss hat dann stattgefunden, wenn dies dem betroffenen Bieter mitgeteilt und entweder vor der Vergabekammer als rechtmäßig anerkannt wurde oder keinem Nachprüfungsverfahren mehr unterzogen werden kann. Lässt sich dies nicht mit Sicherheit feststellen, wird es sich empfehlen, schlicht alle am Verfahren beteiligten Bieter gemäß § 101a GWB zu informieren. – Bewerber2 sind dann zu informieren, wenn ihnen noch keine Information über die Ablehnung ihrer Bewerbung zur Verfügung gestellt wurde, bevor die Mitteilung der Zuschlagsentscheidung an die betroffenen Bieter

1 Nochmals klarstellend: Die Auftragnehmer werden Bieter genannt, wenn sie zur Angebotsabgabe aufgefordert wurden und ein Angebot abgegeben haben. 2 Nochmals klarstellend: Bewerber sind Unternehmen, die noch kein Angebot abgegeben haben, aber einen Antrag im Teilnahmewettbewerb gestellt haben (z.B. in der dem Verhandlungsverfahren mit Vergabebekanntmachung der Angebotsphase vorgeschalteten „Bewerbungsphase“ = Teilnahmewettbewerb).

1230

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 257 N

ergangen ist. Wer also imTeilnahmewettbewerb kein „Absageschreiben“ erhalten hat, muss gemäß § 101a GWB vor Zuschlagserteilung informiert werden. Die Frist wird an die Vorgaben der Rechtsmittelrichtlinie 2007/66/EG angepasst und beträgt nun grundsätzlich 15 Kalendertage. Die Frist verkürzt sich jedoch auf 10 Kalendertage, wenn die Information per Fax oder auf elektronischem Weg versandt werden. Es wird klargestellt, dass die Frist mit dem Tag nach der Absendung der Information zu laufen beginnt und es auf den Zugang nicht ankommt. Damit dürfte dieses bei § 13 VgV durchaus noch unterschiedlich gehandhabte Thema geklärt sein. Der öffentliche Auftraggeber muss unverzüglich in Textform über die getroffene Entscheidung zu informieren. Wird die Vorgabe des § 101a GWB nicht erfüllt, regelt § 101b GWB, dass der geschlossene Vertrag schwebend unwirksam ist und dies auch bleibt, wenn dieser Verstoß gegen § 101a GWB in einem Nachprüfungsverfahren festgestellt wurde. Für ein solches Nachprüfungsverfahren führt § 101b Abs. 2 GWB Fristen ein: – Der Verstoß gegen § 101a GWB muss innerhalb von 30 Kalendertagen ab Kenntnis, spätestens jedoch sechs Monate nach Vertragsschluss in einem Nachprüfungsverfahren geltend gemacht werden. – Wird die Auftragsvergabe im EU-Amtsblatt öffentlich bekannt gemacht, dann endet die Frist 30 Kalendertage nach dieser Veröffentlichung der Auftragsvergabe. Mit anderen Worten: Sind die genannten Fristen abgelaufen, ohne dass ein Nachprüfungsverfahren eingeleitet wurde, besteht Rechtssicherheit: Der Vertrag ist von Anfang an wirksam! Diese Rechtsfolgen des § 101b GWB gelten zudem nicht nur beim Verstoß gegen § 101a GWB, sondern auch bei den so genannten De-facto-Vergaben (s. hierzu bereits unter Rz. 82). 10. Vergabevermerk, Veröffentlichung des Ergebnisses des Vergabeverfahrens a) Vergabevermerk Die Notwendigkeit eines Vergabevermerks ergibt sich aus § 20 VOL/A, § 24 257 EG VOL/A. Gesprochen wird nunmehr von „Dokumentation“. Gem. §§ 20, 24 EG VOL/A ist der Auftraggeber stets (also unabhängig davon, ob das Verfahren Lieferung oder Dienstleistung zum Gegenstand hat sowie bei allen Verfahrensarten) verpflichtet, die Vergabe so zu dokumentieren, dass die einzelnen Stufen des Verfahrens, die Maßnahmen, die Feststellung sowie die Begründung der einzelnen Entscheidungen festgehalten wird.

Bischof

1231

N Rz. 258

Einzelprobleme

258

Letztlich soll mit dieser Dokumentation das gesamte Verfahren transparent und nachvollziehbar dargestellt werden. Zum einen sollte der Auftraggeber, um sich die Erstellung dieses Vermerks zu erleichtern, bereits im Lauf des Verfahrens die notwendigen Schritte zum jeweiligen Zeitpunkt dokumentieren. Zum anderen ist es zur Gewährleistung eines effektiven Rechtsschutzes der Anbieter zwingend erforderlich, alle wesentlichen Zwischenentscheidungen auch bereits vor der Zuschlagserteilung und dem Vertragsschluss nachvollziehbar und zeitnah zu dokumentieren1. Auf diese Weise kann für diesen Vermerk bereits auf die erstellten Dokumente unter Darstellung der jeweiligen Verfahrensabschnitte zur Vereinfachung, Beschleunigung und Übersichtlichkeit Bezug genommen werden. Der Vergabevermerk bildet somit den Abschluss der Vergabeakte.

259

Die entscheidende Bedeutung des Vergabevermerks, der Dokumentation liegt darin, die Überprüfbarkeit der im Rahmen des Vergabeverfahrens getroffenen Maßnahmen, Feststellungen und Entscheidungen zu gewährleisten, vor allem dann, wenn ein Bieter oder Bewerber ein Nachprüfungsverfahren einleiten sollte. Der Anbieter hat ein subjektives Recht auf ausreichende Dokumentation des Vergabeverfahrens und insbesondere der wesentlichen Entscheidungen im Vergabeverfahren.

260

§ 24 EG VOL/A2 bestimmt folgende Mindestangaben einer Dokumentation: „a) Namen und Anschrift des öffentlichen Auftraggebers, Gegenstand und Wert des Auftrags, der Rahmenvereinbarung oder des dynamischen Beschaffungssystems, b) Namen der berücksichtigen Bewerber oder Bieter und die Gründe für ihre Auswahl, c) Namen der nicht berücksichtigten Bewerber oder Bieter und die Gründe für ihre Ablehnung, d) Gründe für die Ablehnung von ungewöhnlich niedrigen Angeboten, e) Namen des erfolgreichen Bieters und die Gründe für die Auswahl seines Angebots sowie – falls bekannt – der Anteil am Auftrag oder an der Rahmenvereinbarung, den der Zuschlagsempfänger an Dritte weiterzugeben beabsichtigt, f) bei nicht offenen Verfahren, Verhandlungsverfahren und wettbewerblichen Dialogen die Gründe, die die Anwendung dieser Verfahren rechtfertigen, g) ggf. die Gründe, aus denen die Auftraggeber auf die Vergabe eines Auftrags, den Abschluss einer Rahmenvereinbarung oder die Einrichtung eines dynamischen Beschaffungssystems verzichtet haben, h) Gründe, aufgrund derer mehrere Teil- oder Fachlose zusammen vergeben werden sollen,

1 S. auch Portz, in: Daub/Eberstein, VOL/A, Kommentar, § 30 Rz. 6 ff.; Noch, Vergaberecht kompakt, S. 365 f. m.w.N. 2 § 20 VOL/A bestimmt für den nationalen Bereich zwar lediglich, dass das Vergabeverfahren von Anfang an fortlaufend zu dokumentieren ist, so dass die einzelnen Stufen des Verfahrens, die einzelnen Maßnahmen sowie die Begründung der einzelnen Entscheidungen festgehalten werden. Inhaltlich besteht letztlich zu den ausführlicheren Bestimmungen auf EU-Ebene kaum ein Unterschied.

1232

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 262 N

i) Gründe, warum der Gegenstand des Auftrags die Vorlage von Eignungsnachweisen erfordert und ggf. warum in diesen Fällen Nachweise verlangt werden müssen, die über Eigenerklärungen hinausgehen, j) Gründe der Nichtangabe der Gewichtung der Zuschlagskriterien.“

Folgende Angaben sind über diese Mindestangaben hinaus regelmäßig Inhalt des Vergabevermerks: – – – – – – – – – – – – – – – – – – – –

261

Name und Anschrift des Auftraggebers gewähltes Verfahren mit Begründung Art und Umfang der vom Vertrag erfassten Leistung Art und Umfang der einzelnen Lose, ggf. mit Begründung Wert des Auftrags (bzw. der einzelnen Lose) Auskunft über die Erkundung des Bewerberkreises einzelne Stufen des Vergabeverfahrens mit genauer Datumsangabe Namen der in die Vergabe einbezogenen Bewerber oder Bieter mit Begründung Namen der ausgeschlossenen Bewerber von der Teilnahme am Wettbewerb und die Gründe für ihren Ausschluss Angaben zu den Gründen bzw. zur Höhe vereinbarter Vertragsstrafen und Sicherheitsleistungen Angaben zu den Gründen für die Abweichung bei der Verjährung von Gewährleistungsansprüchen Zahl der Änderungsvorschläge und Nebenangebote Angaben der Gründe für ein Abweichen von einer angemessenen Angebots- bzw. Zuschlags- und Bindefrist Namen der berücksichtigten Bieter und die Gründe für ihre Auswahl Ergebnis der Prüfung der Angebote Angaben über Verhandlungen mit Bietern und deren Ergebnis Ergebnis der Wertung der Angebote Name des Auftragnehmers und Gründe für die Erteilung des Zuschlags auf sein Angebot ggf. Angaben über die Ausfertigung einer Vertragsurkunde ggf. Angaben und Begründung für eine Aufhebung der Ausschreibung.

Zur Erzielung der dem Vergabevermerk zukommenden Beweiskraft1 muss 262 der Vermerk den Ersteller erkennen lassen und daher auch mit (jeweiliger) Datumsangabe unterzeichnet werden.

1 S. Portz, in: Daub/Eberstein, VOL/A, Kommenatr, § 30 Rz. 5; Weyand, Vergaberecht, § 97 GWB Rz. 137 m.w.N.

Bischof

1233

N Rz. 263

Einzelprobleme

b) Veröffentlichung des Verfahrensergebnisses 263

Zu beachten ist zudem die Bekanntmachung über die Auftragserteilung innerhalb von 48 Tagen nach Vergabe gem. § 23 EG VOL/A entsprechend den bekannten Standardformularen.

VI. Beendigung eines Vergabeverfahrens durch Aufhebung 1. Einleitung 264

Jedes Vergabeverfahren endet entweder mit: – Zuschlagserteilung (§ 18 VOL/A bzw. § 21 EG VOL/A) oder mit – Aufhebung (§ 17 VOL/A bzw. § 20 EG VOL/A). Andere Beendigungsgründe kennt das Vergaberecht nicht. Einzig denkbare Fallkonstellation hierzu ist, dass überhaupt keine Angebote eingegangen sind, da es dann auch keinen unterrichtungspflichtigen Bieter gibt1. Die bloße „Nichtzuschlagserteilung“ hingegen führt nicht zur Beendigung des Vergabeverfahrens. 2. Voraussetzungen der Aufhebung eines Vergabeverfahrens a) Einleitung

265

Die Voraussetzungen einer Aufhebung sind abschließend in § 17 bzw. § 20 EG VOL/A dargestellt, wonach die Aufhebung möglich ist, wenn: – kein Angebot eingegangen ist, das den Bewerbungsbedingungen entspricht, – die Grundlagen der Vergabeverfahren sich wesentlich geändert haben, – das Vergabeverfahren kein wirtschaftliches Ergebnis gehabt hat, – andere schwerwiegende Gründe bestehen2. Es kann sowohl eine Voll- wie auch eine Teilaufhebung erfolgen (§ 17 Abs. 1, § 20 EG Abs. 1 VOL/A). Da die Aufhebung aber den Ausnahmefall darstellen soll, sind die vorgenannten Aufhebungstatbestände eng auszulegen.

266

Die Bewerber/Bieter sind von der Aufhebung unter Bekanntgabe der Gründe unverzüglich zu benachrichtigen. Eines Antrags des Bewerbers/Bieters bedarf es hierfür nicht. Zu beachten ist bei Verwendung solcher Muster jedoch, dass rein formularhafte Begründungen – falls es zu einem Nachprüfungsverfahren kommen sollte – in der Regel nicht ausreichen. Die Begründung muss vielmehr auf den Einzelfall bezogen sein.

1 S. hierzu Portz, in: Daub/Eberstein, VOL/A, Kommentar, 5. Aufl., § 26 Rz. 16. 2 S. Lischka, in: Müller-Wrede, VOL/A, Kommentar, 3. Aufl. 2010, § 20 EG Rz. 24 m.w.N.

1234

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 272 N

b) Voraussetzungen einer Vollaufhebung Die in § 17 bzw. § 20 EG VOL/A genannten vier Aufhebungsgründe sind ab- 267 schließend und eng auszulegen, da es sich um Ausnahmeregelungen handelt1. Es handelt sich um eine Kann-Vorschrift. Der Auftraggeber ist daher nicht 268 grundsätzlich zur Aufhebung verpflichtet, sondern vielmehr hierzu berechtigt. Ob der Auftraggeber von diesem Recht Gebrauch macht, liegt in seinem Ermessen, es muss also eine Ermessensentscheidung getroffen werden. Bei der Ausübung des Ermessens darf der Auftraggeber nicht allein auf seine Interessen abstellen, sondern muss auch die Interessen der Bewerber und Bieter berücksichtigen. Denn diese dürfen davon ausgehen, dass ein Zuschlag erteilt wird und sich somit für den „Gewinner“ der Aufwand für die Erstellung des Angebots amortisiert. Diese Ermessensentscheidung obliegt der Nachprüfung durch die Verga- 269 bestellen. Der Nachprüfung entzogene Beurteilungsspielräume oder ein nur begrenzt überprüfbares Ermessen der Vergabestelle besteht nicht. Die Rechtskontrolle, ob die Zuschlagskriterien sich auf die Wirtschaftlichkeit des ausgeschriebenen Auftrags beziehen und auch sonst mit dem Vergaberecht in Einklang stehen sowie, ob sie im Rahmen der Angebotswertung zutreffend angewendet werden, erfolgt gem. §§ 107 ff. GWB in vollem Umfang2. aa) Kein ordnungsgemäßes Angebot Es darf kein einziges Angebot eingegangen sein, das den Ausschreibungsbedingungen entspricht.

270

Dies ist dann der Fall, wenn Angebote ausgeschlossen werden müssen oder wenn ein Zuschlag aufgrund der fehlenden Eignung des Bieters nicht möglich ist. Auch Angebote, auf die wegen eines unangemessenen Preis-/Leistungsverhältnisses kein Zuschlag erteilt werden darf, fallen unter diese Regelung. bb) Wesentliche Änderung der Ausschreibungsgrundlagen Eine solche Änderung darf erst nach Einleitung der Ausschreibung eingetreten oder bekannt geworden sein. Es muss sich somit um nicht vorhersehbare Gründe handeln.

271

Zudem muss es sich um eine Änderung der Grundlagen handeln, die we- 272 sentlich, d.h. nicht unbedeutend sowie einschneidend und nachhaltig, ist. Erst wenn es für den Auftraggeber unzumutbar erscheint, trotz wesentlicher Änderungen der Ausschreibungsgrundlagen den Zuschlag auf eins der Angebote zu erteilen, ist diese Schwelle überschritten. 1 S. Fett, in: Müller-Wrede, § 26 Rz. 1 ff.; s. Portz, in: Daub/Eberstein, VOL/A, Kommentar, 5. Aufl., § 26 Rz. 1 ff. 2 S. Immenga/Mestmäcker, GWB-Kommentar, § 97 Rz. 150 ff., s. nachfolgend Rz. 238 ff.

Bischof

1235

N Rz. 273 273

Einzelprobleme

Relevante Gründe für eine Änderung der Grundlagen der Ausschreibung können sowohl die Bedarfssituation des Auftraggebers als auch dessen Finanzierungshintergrund sein1. Bedeutsam können hier die Kürzung oder Verzögerung der bereitgestellten Haushalts- oder Fördermittel sein. Grundsätzlich ist der Auftraggeber in solchen Fällen an das Haushaltsrecht gebunden. Allerdings darf bei fehlenden finanziellen Mitteln dann nicht aufgehoben werden, wenn der nunmehrige Finanzierungsfehlbetrag auf einer vom Auftraggeber fehlerhaft ermittelten Mittelkalkulation im Vorfeld der Ausschreibung beruht. Denn die Bieter dürfen grds. darauf vertrauen, dass ein Auftraggeber nur dann ein Vergabeverfahren einleitet, wenn er die Kosten auch tragen kann2. cc) Kein wirtschaftliches Ergebnis der Ausschreibung

274

Der Zuschlag muss auf das wirtschaftlichste Angebot erteilt werden. Dies ist dasjenige, bei dem das günstigste Verhältnis zwischen der gewünschten Leistung und dem angebotenen Preis erzielt wird. Wird erkennbar, dass keins der Angebote diese Voraussetzungen erfüllt und eine nach Haushaltsrecht erfolgende wirtschaftliche und sparsame Verwendung der Haushaltsmittel nicht möglich ist, muss der Auftraggeber die Ausschreibung aufheben. Allerdings muss eine nicht nur unerhebliche Unwirtschaftlichkeit gegeben sein3. dd) Bestehen anderer schwerwiegender Gründe

275

Es muss sich um einen den anderen drei Gründen gleichkommenden, ebenso schwer wiegenden Grund zur Aufhebung handeln. Dies kann nur eine Einzelfallentscheidung anhand des konkreten Vergabeverfahrens und der konkret eingetretenen Situation sein. Auch hier müssen die beiderseitigen Interessen berücksichtigt werden. Die anderen schweren Gründe müssen in ihren Voraussetzungen und in ihrem Gewicht den anderen Aufhebungsgründen gleichkommen. c) Folgen einer Aufhebung

276

Mit der Aufhebung wird das Vergabeverfahren zum Abschluss gebracht, unabhängig davon, ob die Aufhebung selbst rechtmäßig oder rechtswidrig war.

277

Allerdings kann die Aufhebung selbst wiederum Gegenstand einer Nachprüfung sein. Die Vergabekammern können die Rechtmäßigkeit der Aufhebung prüfen und im Fall der Unrechtmäßigkeit und fortbestehenden Ver-

1 S. Fett, in: Müller-Wrede, § 26 Rz. 32 ff. und 40 ff. 2 BGH zur VOB/A, VergabeR 2003, 163, 164. 3 S. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 238 m.w.N.

1236

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 281 N

gabeabsicht des Auftraggebers auch die Wiederaufnahme und Fortführung des Verfahrens anordnen1. Um eine Nachprüfung zu vermeiden, gehen zahlreiche Auftraggeber in der Praxis dazu über, bei fortbestehender Vergabeabsicht und Übergang in ein anderes/neues Vergabeverfahren (meist Verhandlungsverfahren) mit den vorhandenen Bietern eine Zustimmung der Bieter zur Aufhebung sowie zum weiteren Vorgehen einzuholen. Die Bieter sind in aller Regel nicht abgeneigt und stimmen zu, um weiter am Verfahren beteiligt zu sein. d) Schadensersatzansprüche aa) Berechtigte Aufhebung Ist die Aufhebung von einem Aufhebungsgrund in § 17 bzw. § 20 EG VOL/A 278 gedeckt, besteht grundsätzlich kein Schadensersatzanspruch der Bieter, weder auf das negative Interesse (vergeblich aufgewandte Kosten für die Erstellung des Angebots und Teilnahme am weiteren Auswahlverfahren) noch auf entgangenen Gewinn. bb) Unberechtigte Aufhebung Erfolgt die Aufhebung der Ausschreibung zu Unrecht, ist also nicht von 279 § 17 bzw. § 20 EG VOL/A gedeckt, kann der Bieter folgende Ansprüche auf Schadensersatz nach BGH geltend machen, wobei dies in der Literatur nicht unumstritten ist2: – Dem Bieter, der bei Fortsetzung des Verfahrens und der Vergabe des Auftrags den Zuschlag erhalten hätte, steht ein Anspruch auf Ersatz der mit der Teilnahme am Verfahren verbundenen Aufwendungen zu (vergeblich gemachte Aufwendungen). – Ein weitergehender Anspruch auf den entgangenen Gewinn besteht grundsätzlich nur dann, wenn der ausgeschriebene Auftrag im Nachgang der aufgehobenen Ausschreibung anderweitig tatsächlich erteilt wird. Schadensersatzberechtigt ist nur das Unternehmen, das im aufgehobenen Vergabeverfahren den Zuschlag erhalten hätte, was dieses notfalls zu beweisen hat. Die Schadensersatzklage muss vor den ordentlichen Gerichten geltend ge- 280 macht werden; diese sind an etwaige Entscheidungen der Vergabekammer oder des zweitinstanzlichen Oberlandesgerichts im Nachprüfungsverfahren gem. § 124 GWB gebunden. Sehr umstritten in der Literatur, aber Spruchpraxis ist, dass ein Nachprü- 281 fungsantrag bei der Vergabekammer auf Rückgängigmachung (Aufhebung) der Aufhebung unzulässig ist, wenn zu diesem Zeitpunkt die Aufhebung der Ausschreibung durch den Auftraggeber erfolgt war. Denn zu diesem 1 Vgl. BGH, VergabeR 2003, 313, 314. 2 S. Fett, in: Müller-Wrede, § 26 Rz. 50, 51, 98 ff.

Bischof

1237

N Rz. 282

Einzelprobleme

Zeitpunkt bestehe kein aktuelles Interesse des Unternehmens am Auftrag mehr und ein noch gar nicht anhängiges Nachprüfungsverfahren könne sich nicht mehr durch die bereits erfolgte Aufhebung der Ausschreibung nachträglich erledigen (= Wegfall des Fortsetzungsfeststellungsinteresses gem. § 114 Abs. 2 Satz 2 GWB)1.

VII. Rechte der Bieter im Vergabeverfahren 1. Überblick a) Historische Entwicklung 282

Den Bietern standen nicht seit jeher Rechte gegenüber den öffentlichen Auftraggebern zur Einhaltung der vergaberechtlichen Bestimmungen zu2. Nach der Rechtslage vor 1993 war das Vergaberecht in Deutschland dem öffentlichen Haushaltsrecht zugeordnet; anwendbare Normen waren zunächst Verwaltungsvorschriften, deren Aufgabe darin bestand, die korrekte und wirtschaftliche Verwendung öffentlicher Gelder zu sichern. Die Bieter sollten – außerhalb des allgemeinen Kartellrechts – keine Rechte haben, insbesondere sollte es keinen gerichtlichen Rechtsschutz geben.

283

Der europäische Gesetzgeber befasste sich jedoch zunehmend mit dem Vergaberecht und erließ marktöffnende Richtlinien, die ab Erreichen gewisser Schwellenwerte das Vergabeverfahren regeln sollten. Diese wurden durch die Rechtsmittelrichtlinien begleitet3. Die Umsetzung dieser Richtlinien erfolgte durch das 2. Gesetz zur Änderung des Haushaltsgrundsätzegesetzes (HGrG)4, zwei nachrangige Rechtsverordnungen, der Vergabeverordnung und der Nachprüfungsverordnung, wobei die Verordnungen auf die VOL/A, VOB/A und die VOF verwiesen. Diese sog. haushaltsrechtliche Lösung von 1993 führte zwar zur Änderung des Nachprüfungsverfahrens, aber nicht in ausreichender Form. So wurden zwar Vergabeprüfstellen und Vergabeüberwachungsausschüsse als Nachprüfungsinstanzen geschaffen, die ab Erreichen des EG-relevanten Auftragsvolumens eine formalisierte Überprüfung der Verfahren ermöglichten. Es wurde jedoch ausdrücklich festgelegt, dass dem Bieter keine individuell einklagbaren Rechtsansprüche zustehen oder subjektive Rechte des Bieters entstehen sollten.

284

Dies erwies sich nicht als europarechtskonform, so dass auf Grund des wachsenden Drucks schließlich das Vergaberechtsänderungsgesetz 1998 am 1.1.1999 in Kraft trat, mit dem die Vorschriften der §§ 97 ff. GWB entstan1 S. Fett, in: Müller-Wrede, § 26 Rz. 124 ff., 129; s. auch Portz, in: Daub/Eberstein, § 26 Rz. 52 ff. 2 S. zur Entwicklung u.a. Bechtold, GWB-Kommentar, 3. Aufl., Vor § 97 Rz. 1 ff., Immenga/Mestmäcker, GWB-Kommentar, 3. Aufl., Vor §§ 97 ff. Rz. 33 ff. 3 S. hierzu bereits Rz. 5 ff. 4 Gesetz v. 26.11.1993, BGBl. I, S. 1928 zum Haushaltsgrundsätzegesetz v. 19.8.1969.

1238

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 286 N

den1. Seitdem stehen den Bietern erstmals subjektive Rechte auf die Einhaltung der vergaberechtlichen Vorschriften durch den öffentlichen Auftraggeber sowie gerichtlicher Rechtsschutz zu. b) Bestehende Möglichkeiten zur Geltendmachung von Bieterrechten Dem Bieter stehen (oberhalb der Schwellenwerte)2 zur Geltendmachung 285 von Rechten im Vergabeverfahren nach geltendem Recht folgende Möglichkeiten zur Verfügung: – – – –

Anrufung der Rechts-, Fach- oder Dienstaufsicht Anrufung einer Vergabeprüfstelle Einleitung eines Nachprüfungsverfahrens vor den Vergabekammern Geltendmachung von Schadensersatzansprüchen vor den ordentlichen Gerichten.

§ 102 GWB sieht ausdrücklich vor, dass die Prüfung durch Aufsichtsbehörden sowie daneben die Nachprüfung vor den Vergabekammern möglich ist. Es besteht hierbei keinerlei Rangfolge: Vergabekammern werden unabhängig davon tätig, ob vorher, zeitgleich oder danach auch Aufsichtsbehörden eingeschaltet werden3. Die Vergabeprüfstellen wurden durch mehrere Änderungen der vergabe- 286 rechtlichen Bestimmungen sukzessive degradiert: Vor dem Inkrafttreten des VgRÄG waren sie obligatorische Eingangsinstanz vor den Vergabeüberwachungsausschüssen. Mit der Neukonstruktion des Primärrechtsschutzes verloren sie diesen Status. Nach der Modernisierung des 4. Teils des GWB sind sie nun gänzlich aus dem GWB verschwunden. Aus der Gesetzesbegründung ist ersichtlich, dass dennoch die grundsätzliche Prüfungsmöglichkeit durch Vergabeprüfstellen bestehen bleiben soll4. Zum einen sollen sie einem Bieter, der sich gegen eine vermeintliche Rechtsverletzung durch die Vergabestelle wehren will, aber (noch) nicht ein kostenpflichtiges Nachprüfungsverfahren einleiten möchte, eine „formlose und in der Regel kostenlose“ Überprüfung und Beratung durch eine der Vergabestelle vorgesetzte Stelle ermöglichen5. Zum anderen verspricht sich der Gesetzgeber eine Entlastung der Vergabekammern und mittelbar auch der Vergabesenate. An obiger Auffassung hat die Bundesregierung nach Kritik des Bundesrats nur 1 S. BGBl. 1998, S. 2546. 2 S. bei Vergabe unterhalb der Schwellenwerte zur Eröffnung des Verwaltungsrechtswegs: VG Neustadt/Weinstr. v. 19.10.2005, VergabeR 2006, 78; VG Potsdam v. 20.9.2005, VergabeR 2006, 83; OVG Berlin-Brandenburg v. 21.9.2004, VergabeR 2006, 85. 3 S.a. Müller-Wrede, GWB-Vergaberecht, Kommentar, § 102 Rz. 14 zu „Kein dreistufiges Nachprüfungsverfahren“. Vgl. Bechtold, GWB-Kommentar, § 102 Rz. 1, 2. 4 Vgl. Müller-Wrede, GWB-Vergaberecht, Kommentar, § 102 Rz. 13 m.w.N. 5 Auch die öffentlichen Auftraggeber wenden sich bisweilen informativ an die Vergabeprüfstelle, um deren Ansicht zu bestimmten Themen bzw. zu einem geplanten Vorgehen bereits im Vorfeld „abzufragen“.

Bischof

1239

N Rz. 287

Einzelprobleme

noch in Bezug auf die Vergabeprüfstellen auf Bundeseben festgehalten. Soweit die Länder an diesen ebenfalls festhalten wollen, müssen sie entsprechende Regeln für die Einrichtung und das Verfahren von Vergabeprüfstellen erst schaffen1. Die Aufsichtsbehörden2 erfüllen die gleiche Funktion unter Beibehaltung sämtlicher ihnen zur Verfügung stehender Eingriffsmöglichkeiten3. Die Vergabekammern sind für den Primärrechtsschutz zuständig, die ordentlichen Gerichte für den Sekundärrechtsschutz4. 2. Rechtsschutz der Bieter oberhalb der Schwellenwerte a) Primärrechtsschutz: Das Nachprüfungsverfahren aa) Allgemeines 287

Das Nachprüfungsverfahren ist ein eigenständiges Rechtsschutzverfahren in zwei Instanzen, den Vergabekammern in 1. Instanz und den Vergabesenaten der Oberlandesgerichte in 2. Instanz. Ein Rechtsmittel gegen die Entscheidung der Oberlandesgerichte ist nicht vorgesehen. Der BGH wird in Rahmen von Divergenzvorlagen unterschiedlicher Vergabesenate gemäß § 124 GWB mit vergaberechtlichen Fragestellungen befasst. Ausnahmsweise kann es auch zu Verfassungsbeschwerden und damit zur Entscheidung des Bundesverfassungsgerichts kommen. bb) Zuständigkeit

288

§ 104 Abs. 2 Satz 1 GBW bestimmt, dass die Bieter ihr Recht auf Einhaltung der Vergabevorschriften nur im Verfahren vor der Vergabekammer geltend machen können, wobei die Regelung in § 102 GWB5 unberührt bleibt. Dies begründet eine ausschließliche Zuständigkeit der Vergabekammer. Vergabekammern sind Behörden, die mit gerichtsähnlichen Kompetenzen ausgestattet sind6.

289

§ 104 Abs. 1 GWB unterschiedet hinsichtlich der örtlichen Zuständigkeit danach, ob der öffentliche Auftrag dem Bund oder den Ländern zuzuordnen ist. Hieraus können erhebliche Abgrenzungsschwierigkeiten entstehen. § 106a GWB regelt die Abgrenzung, ob die Vergabekammer des Bundes oder

1 Vgl. Müller-Wrede, GWB-Vergaberecht, Kommentar, § 102 Rz. 13 m.w.N. 2 Dies sind diejenigen Stellen der Verwaltung, die gegenüber dem öffentlichen Auftraggeber die Fach-, Rechts- und Dienstaufsicht ausüben. 3 S. Immenga/Mestmäcker, GWB-Kommentar, § 102 Rz. 3, 4, 5 ff. 4 Für die Praxis sind Primär- und Sekundärrechtsschutz von wesentlicher Bedeutung, so dass nachfolgend ausschließlich hierauf abgestellt wird. Hinsichtlich der Aufsichtsbehörden sowie der Vergabeprüfstellen wird auf die einschlägige Literatur verwiesen. 5 S. hierzu Rz. 285. 6 Vgl. OLG Düsseldorf, VergabeR 2001, 154.

1240

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 292 N

die Vergabekammern der einzelnen Länder zuständig sind. Die Bundesländer wiederum haben jeweils Ausführungsbestimmungen hierzu erlassen1. Die Suche nach der „richtigen Vergabekammer“ ist für die Bieter nicht ein- 290 fach. Ein bei einer unzuständigen Kammer eingereichter Nachprüfungsantrag ist unzulässig, so dass der Antrag dem öffentlichen Auftraggeber auch nicht zugestellt wird und somit die gewünschte Wirkung („Zuschlagssperre“) nicht eintritt. Die unzuständige Vergabekammer hat zwar aufgrund der bestehenden Beratungs- und Auskunftspflicht nach § 25 VwVfg die Pflicht, dem Bieter die zuständige Vergabekammer mitzuteilen, sofern bekannt oder einfach erkennbar. Eine Pflicht zur Weiterleitung des Antrags besteht jedoch nicht. Dies kann für den Bieter – wie bereits angesprochen – sehr nachteilige Folgen haben. Daher sieht § 15 EG Abs. 10 VOL/A auch vor, dass der öffentliche Auftrag- 291 geber bereits in der Vergabebekanntmachung2 sowie in den Vergabeunterlagen3 die Vergabekammer samt Anschrift4 anzugeben hat, die für ein Nachprüfungsverfahren zuständig ist. Erforderlich ist die Angabe des Behördennamens, des Orts, der Straße und der Telefonnummer. Empfehlenswert ist auch die Angabe der Faxnummer im Hinblick auf die kurzen Fristen im Vergaberecht. Die Angabe einer falschen Vergabekammer stellt an sich bereits eine rügefähige Rechtsverletzung dar. Dies entbindet den Bieter jedoch nicht davon, die zuständige Vergabekammer dann selbst zu ermitteln. Denn die Angabe einer falschen Vergabekammer vermag nicht deren Zuständigkeit zu begründen. Insoweit gelten die obigen Ausführungen entsprechend. cc) Zulässigkeit des Nachprüfungsantrags Die Zulässigkeitsvoraussetzungen eines Nachprüfungsantrags ergeben sich aus§§ 107, 108 GWB: – Nachprüfungsntrag, § 107 Abs. 1 GWB i.V.m. § 108 GWB – Antragsbefugnis, § 107 Abs. 2 GWB – rechtzeitige, nicht verfristete Rüge, § 107 Abs. 3 GWB Eine Antragsfrist ist nicht vorgesehen5. Wesentlich ist auch, dass ein Nachprüfungsantrag nur bis zur Zuschlagserteilung zulässig ist. Wurde der Zuschlag erteilt, ist aber stets zu prüfen, ob dies wirksam geschehen ist. Zweifel an der Wirksamkeit eines Zuschlags können sich z.B. ergeben wegen der fehlenden Vorabinformation nach

1 S. hierzu Aufzählung in Reidt/Stickler/Glahs, Vergaberecht, Kommentar, 2. Aufl., Anhang IV Ziffer 1. 2 S. Rz. 200 ff. 3 S. Rz. 134 ff. 4 S. zur Übersicht der Vergabekammern samt Anschriften: Reidt/Stickler/Glahs, Vergaberecht Kommentar, Anhang IV Ziff. 2. 5 S. Immenga/Mestmäcker, GWB-Kommentar, § 107 Rz. 5.

Bischof

1241

292

N Rz. 293

Einzelprobleme

§ 101a GWB, wegen Vorliegens einer De-facto-Vergabe oder aus den Nichtigkeitsgründen der §§ 134, 138 BGB1. dd) Nachprüfungsantrag, § 107 Abs. 1 GWB 293

Die Vergabekammer wird stets nur aufgrund eines wirksamen Antrags tätig. Die Einleitung eines Nachprüfungsverfahrens ohne einen solchen Antrag ist unzulässig. Innerhalb des Verfahrens gilt dann allerdings § 114 Abs. 1 Satz 2 GWB, wonach die Vergabekammer nicht an gestellte Anträge gebunden ist.

294

Die formellen Mindestanforderungen bestimmt § 108 Abs. 1 GWB, wonach der Antrag schriftlich einzureichen und unverzüglich zu begründen ist (s. zur Begründung unter Rz. 321). Eine mündliche Antragstellung ist somit – abweichend von § 22 VwVfG – nicht möglich. Zudem ist der Antrag grundsätzlich in deutscher Sprache einzureichen. Eine andere Sprache führt jedoch nicht zur Unzulässigkeit, da die Vergabekammer eine Übersetzung fordern oder selbst, ggf. auf Kosten des Antragstellers, in Auftrag geben kann.

295

Dennoch ist es für das antragstellende IT-Unternehmen zwingend erforderlich, den Antrag in deutscher Sprache einzureichen, denn eine solche Übersetzung verzögert das Verfahren und verhindert die Zustellung des Antrags an die Vergabestelle und damit den Eintritt des Zuschlagsverbots gem. § 115 Abs. 1 GWB2.

296

Zu beachten ist, dass der Antrag gem. § 108 Abs. 1 Satz 2 GWB ein bestimmtes Begehren (= Sachantrag) enthalten soll. Nachdem es sich um eine Soll-Vorschrift handelt, führt das Fehlen eines solchen Antrags jedoch nicht zur Unzulässigkeit. Insbesondere müssen keine tenorierungsfähigen Anträge gestellt werden3. Allerdings muss aus dem Antrag erkennbar sein, welche Rechtsverletzung gerügt wird. Ein Sachantrag könnte beispielsweise wie folgt lauten:

Im Namen und im Auftrag der Antragstellerin erheben wir Nachprüfungsantrag betreffend das Vergabeverfahren „…“ und beantragen: 1. die Antragsgegnerin zu verpflichten, die Ausschreibung aufzuheben und das Projekt … neu auszuschreiben; 2. der Antragstellerin Einsicht in die Vergabeakten zu gewähren; 3. die Hinzuziehung des Verfahrensbevollmächtigten der Antragstellerin gem. § 128 Abs. 4 GWB für notwendig zu erklären;

1 S. BGH, NZBau 2001, 151, 152; OLG Düsseldorf v. 24.9.2002 – Verg 48/02. 2 S. zum Zuschlagsverbot nachfolgend unter Rz. 322 f. 3 So u.a. VK Bremen v. 1.3.2007 – VK 01/07; VK Bund v. 23.12.2005 – VK 1-155/05.

1242

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 300 N

4. der Antragsgegnerin die Kosten des Verfahrens einschließlich der Kosten der zweckentsprechenden Rechtsverfolgung der Antragstellerin aufzuerlegen.

Für ausländische IT-Unternehmen ist zudem § 108 Abs. 1 Satz 3 GWB zu beachten, wonach ein inländischer Empfangsbevollmächtigter zu benennen ist. Fehlt diese Angabe, so ist der Nachprüfungsantrag unzulässig.

297

ee) Antragsbefugnis, § 107 Abs. 2 GWB Die Antragsbefugnis besteht dann, wenn das antragstellende IT-Unterneh- 298 men1 – ein Interesse am Auftrag hat, – eine Verletzung seiner Rechte gem. § 97 Abs. 7 GWB sowie – einen drohenden Schaden geltend macht. Überhöhte Anforderungen dürfen unter dem Gesichtspunkt der Rechtsschutzgarantie nicht gestellt werden2. Somit kann weder der öffentliche Auftraggeber noch ein sonstiger Dritter, 299 der ein (ideelles) Interesse an einem ordnungsgemäßen Vergabeverfahren hat (z.B. Unternehmensverbände u.Ä.) einen Antrag auf Nachprüfung stellen. Ebenso wenig haben Aufsichtsbehörden oder die Vergabeprüfstelle ein Antragsrecht. Dieses Recht steht somit ausschließlich am Auftrag interessierten Unternehmen zu. Ungeschriebene Voraussetzung ist, dass es tatsächlich einen konkreten Ver- 300 gabevorgang gibt. Dies heißt jedoch nicht, dass es sich zwingend um ein förmliches Vergabeverfahren i.S.v. § 101 GWB3 handeln muss. Auch bei denjenigen Auftragsvergaben, in denen der Auftraggeber kein förmliches Vergabeverfahren eingeleitet hat, aber dennoch einen Auftrag vergeben will (De facto-Vergabe), ist ein Nachprüfungsverfahren zulässig und insbesondere die Antragsbefugnis eines Unternehmens gegeben, das sich hiergegen wehren will. Ob ein Vergabevorgang vorliegt, richtet sich somit nach materiellen Kriterien4. Allerdings dient dieses Nachprüfungsrecht nicht dem

1 S. zu Bietergemeinschaften und Antragsbefugnis: OLG Düsseldorf v. 3.1.2005 – VII-Verg 82/04, BauRB 2005, 137. 2 S. BVerfG v. 29.7.2004 – 2 BvR 2248/03, BauRB 2004, 368. S. zum Anspruch ausgeschlossener Bieter auf Aufhebung der Ausschreibung: Müller-Wrede/Schade, VergabeR 2005, 460; OLG Düsseldorf v. 27.4.2005, VergabeR 2005, 483; OLG Frankfurt v. 21.4.2005, VergabeR 2005, 487; a.A. jedoch Thüringer OLG v. 20.6.2005, VergabeR 2005, 492 (zu einer Entscheidung des BGH über eine Divergenzvorlage kam es wegen Antragsrücknahme – leider – nicht mehr). 3 S. zu den Verfahrensarten auf EU-Ebene Rz. 85 ff. 4 S. hierzu im Detail Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 107 Rz. 13a m.w.N.

Bischof

1243

N Rz. 301

Einzelprobleme

Selbstzweck: Der Antragsteller muss sich selbst rechtstreu verhalten und damit schutzwürdig sein1. 301

Vorbeugender Rechtsschutz wird nicht gewährt. Es genügt also nicht die Behauptung, dass eine Auftragsvergabe drohen könnte, ohne dass Anhaltspunkte für eine konkrete Beschaffungsinitiative vorgetragen werden können. Mit anderen Worten: Nicht jeder Kontakt zu Unternehmen oder sonstige Aktivitäten der öffentlichen Hand z.B. zur Markterkundung stellen bereits den Beginn eines konkreten Vergabeverfahrens dar.

302

Interesse am Auftrag bedeutet ein tatsächliches, unmittelbar eigenes, wirtschaftliches Interesse. In der Regel werden hier keine allzu hohen Anforderungen gestellt und wird das Interesse dadurch dokumentiert, dass der Antragsteller ein Angebot abgegeben hat. Ausnahmsweise kann auch ohne Angebot ein Interesse gegeben sein, nämlich dann, wenn der Antragsteller geltend machen kann, dass er durch einen Vergaberechtsverstoß des öffentlichen Auftraggebers an der Abgabe eines Angebots gehindert war2. Die Vergabekammern erwarten auch dann umfassende Nachweise, wenn sich das Interesse am Auftrag nicht ohne Weiteres erkennen lässt, so z.B. wenn das Unternehmen noch nie im betreffenden Bereich tätig war (im IT-Bereich kann dies z.B. gelten, wenn ein Unternehmen bislang nur im Software-Bereich tätig war, nun aber auch Hardware anbietet).

303

Vorlieferanten oder Subunternehmer können kein Interesse am Auftrag geltend machen, da es ihnen am unmittelbaren eigenen Interesse mangelt. Ihr Interesse bezieht sich auf einen Auftrag durch den Bieter, nicht aber an einer direkten Beauftragung durch die Vergabestelle. Ihnen stehen daher auch keine eigenen subjektiven Rechte i.S.v. § 97 Abs. 7 GWB zu.

304

Ein Interesse fehlt, wenn der Antragsteller weder ein Angebot abgegeben hat, noch einen Verfahrensverstoß gerügt hat3. Ein Interesse fehlt auch dann, wenn dieses erst nach einem Vergabefehler der Vergabestelle entstanden ist. Ein typisches Beispiel hierfür wäre, dass ein IT-Unternehmen im Rahmen des durchgeführten Teilnahmewettbewerbs keinen Teilnahmeantrag gestellt hat oder z.B. aufgrund fehlender Nachweise aus dem Teilnahmewettbewerb ausgeschieden ist und die Vergabestelle erst im weiteren Verfahren einen Vergabefehler begangen hat. Hieraus darf jedoch nicht rückgeschlossen werden, dass immer die Abgabe eines Angebots zwingend erforderlich ist, um das Interesse zu bejahen. Es gibt auch Konstellationen, in denen es auf ein Angebot gar nicht ankommt, so z.B. wenn gar kein Vergabeverfahren durchgeführt wird, obwohl dies erforderlich wäre (De factoVergabe).

1 S. OLG Brandenburg v. 10.2.2004 – Verg W 8/03, BauRB 2004, 306. 2 S. BayObLG, VergabeR 2003, 345; OLG Düsseldorf, VergabeR 2005, 343. 3 Vgl. EuGH v. 12.2.2004 – Rs. C-230/02, BauRB 2004, 137.

1244

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 308 N

Im Rahmen der Antragstellung muss auch die Möglichkeit einer Rechtsver- 305 letzung substantiiert vorgetragen werden. Ob diese tatsächlich vorliegt, wird erst bei der Begründung geprüft. § 97 Abs. 7 GWB beschränkt die subjektiven Rechte der Bieter auf die Einhaltung der Bestimmungen über das Vergabeverfahren, was weit auszulegen ist. Ob eine Rechtsverletzung durch Nichtbeachtung vergaberechtlicher Bestimmungen vorliegt, ist anhand aller Regelungen zu prüfen, die mit dem formellen und materiellen Vergaberecht in Zusammenhang stehen, also nach GWB, Vergabeverordnung sowie den Vergabe- und Vertragsordnungen1. Es muss ich jedoch bei den Bestimmungen über das Vergabeverfahren stets um bieterschützende Vorschriften handeln. Da kein Bieter einen allgemeinen Anspruch auf Einhaltung aller Vorschriften des Vergaberechts hat, bedarf es einer subjektiven Betroffenheit. Ebenso muss ein zumindest drohender Schaden dargelegt werden, § 107 305a Abs. 2 Satz 2 GWB. Zielsetzung dieser Regelung ist die Vermeidung unnötiger Nachprüfungsverfahren. Zwar werden hier keine hohen Anforderungen gestellt, es gilt aber Folgendes zu beachten: Wer evident keine Aussicht auf Erteilung des Zuschlags hat, selbst wenn 306 der geltend gemachte Vergabeverstoß ausgeräumt würde, dem kann auch kein Schaden drohen. Dies ist vor allem in folgenden Konstellationen denkbar: Der Antragsteller müsste (z.B. wegen fehlender Eignungsnachweise) ohnehin vom Verfahren ausgeschlossen werden oder er liegt in der Wertungsreihenfolge (z.B. wegen des höchsten Angebotspreises) so weit hinten, dass ein Zuschlag auf das Angebot des Antragstellers eindeutig nicht in Betracht kommt. Dies wird jedoch dann großzügiger gehandhabt, wenn es überhaupt kein förmliches Vergabeverfahren gegeben hat. Maßgeblich ist hierbei auch, ob der Schaden durch die Beseitigung des Ver- 307 gabeverstoßes ebenfalls wieder beseitigt werden kann. Ist dies nicht der Fall (z.B. wenn der Zuschlag bereits erteilt und damit der Vertrag zustande gekommen ist), so verbleibt es nur bei der Geltendmachung eines etwaigen Schadensersatzanspruchs (vgl. § 126 GWB); ein Nachprüfungsverfahren ist nicht mehr möglich2. ff) Rechtzeitige Rüge, § 107 Abs. 3 GWB Diese Vorschrift ist für jeden Bieter von erheblicher rechtlicher Bedeutung: Nach § 107 Abs. 3 Satz 1 GWB ist der Nachprüfungsantrag unzulässig, wenn der Antragsteller den gerügten Verstoß im Vergabeverfahren erkannt

1 Ein praktischer Hinweis: Sehr hilfreich ist hierbei der VOL/A Kommentar von Müller-Wrede, da dort bei allen Vorschriften in der Kommentierung ein eigener Unterpunkt zum bieterschützenden Charakter der Vorschrift aufgenommen wurde. Somit ist auf „einen Blick“ erkennbar, ob subjektive Rechte bestehen oder nicht und wenn ja, in welchem Umfang. 2 S. hierzu Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 107 Rz. 24 ff.

Bischof

1245

308

N Rz. 309

Einzelprobleme

und nicht gegenüber dem Auftraggeber unverzüglich gerügt hat. Eine Rüge gegenüber einem Dritten, z.B. der Aufsichtsbehörde, genügt nicht. Erfolgt die unverzügliche Rüge nicht nach positiver Kenntnis des Vergabeverstoßes, ist ein Nachprüfungsantrag unzulässig (Präklusionswirkung). Die Vergaberechtsreform 2009 hat § 107 Abs. 3 GWB neu gefasst und damit eindeutigere Regelungen aufgestellt, teils auch in Umsetzung der umfangreichen Rechtsprechung zur Rügepflicht. Für die Bieter bedeutet die Neuregelung eine Verschärfung ihrer Verpflichtungen zum schnellen Handeln; für die Auftraggeber schaffen die Regelungen schneller Klarheit und Rechtssicherheit darüber, ob sie noch mit einer Rüge und einem Nachprüfungsverfahren rechnen müssen. 309

Der Bieter muss positive Kenntnis vom Vergaberechtsverstoß haben. Die positive Kenntnis muss sich sowohl auf den tatsächlichen Sachverhalt als auch auf dessen rechtliche Bedeutung beziehen. Allein die Kenntnis des Sachverhalts reicht noch nicht aus, weil damit nicht zwingend auch die Kenntnis eines (Rechts-)Verstoßes verbunden ist. Es ist erforderlich, dass nach den subjektiven Einschätzungen des Bieters ein Verstoß vorliegt1. Ein Kennenmüssen wird nicht als ausreichend erachtet2. Diese positive Kenntnis muss bei den Personen im Unternehmen des Bieters vorliegen, die auch berechtigt sind, darüber zu entscheiden, ob eine Rüge erhoben werden soll oder nicht. Dementsprechend muss es sich um die Personen handeln, die für das Unternehmen verbindliche Erklärungen abgegeben können. In der Regel sind dies die Mitglieder der Geschäftsführung. Nicht ausreichend ist somit die Kenntnis von anderen Mitarbeitern, wie z.B. Mitgliedern der Projektgruppe, die das Vergabeverfahren auf operativer Ebene betreut oder z.B. der Rechtsabteilung.

310

Letztlich sind die Anforderungen an eine Rüge nicht hoch: Die Rüge muss nicht schriftlich erhoben werden, was zu Beweiszwecken aber dringend zu empfehlen ist. Auch die Verwendung des Worts „Rüge“ ist nicht erforderlich; es genügt, wenn der Bieter den Sachverhalt und den angeblichen Verstoß bezeichnet und dass er vom Auftraggeber erwartet, dass dieser den Verstoß auch abstellt. Zu beachten ist allerdings, dass sich die Anforderungen an eine Rüge mit der Erfahrung von Unternehmen in Bezug auf Vergabeverfahren erhöhen kann. Gleiches gilt auch, wenn sich der Bieter von einem Anwalt vertreten lässt3.

311

Die Rüge muss unverzüglich gegenüber dem Auftraggeber ausgesprochen werden. Unverzüglich wird auch hier i.S.v. § 121 BGB verstanden, so dass die Rüge ohne schuldhaftes Zögern erfolgen muss. Folglich bleibt nur sehr kurze Zeit, um eine Rüge auszusprechen, wobei es dem Unverzüglich-

1 Vgl. OLG Düsseldorf, NZBau 2000, 440. 2 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 107 Rz. 33. 3 Vgl. Byok, in: Byok/Jäger, Vergaberechtskommentar, 2. Aufl., § 107 GWB Rz. 986.

1246

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 312 N

keitsgebot nicht widerspricht, wenn das Unternehmen fachlichen Rat bei externen Beratern, z.B. einer Rechtsanwaltskanzlei mit Spezialwissen im Bereich des Vergaberechts, einholt und/oder sich die Geschäftsführung mit der hausinternen Rechtsabteilung abstimmt. Von der Rechtsprechung ist zwischenzeitlich eine Rügefrist von 1–3 Tagen ab Erkennen des Verstoßes entwickelt worden, bei schwierigen Sachverhalten ggf. auch etwas länger. Veraltet dürfte die Rechtsprechung sein, wonach eine maximale Frist von ca. zwei Wochen ab positiver Kenntnis zu beachten war. Die genaue Fristlänge kann zwar stets nur nach der Lage des Einzelfalls beurteilt werden, aber zu viel Zeit sollte sich ein Bieter im Hinblick auf die stringente Rechtsprechung sicherlich nicht lassen. Dieses Gebot der Unverzüglichkeit gilt auch für die in § 107 Abs. 3 Nr. 2 und 3 GWB genannten Verstöße, die aus Bekanntmachung oder Vergabeunterlagen erkennbar sind. Die Besonderheit insofern ist, dass die Bestimmungen der § 107 Abs. 2 Nr. 2 und 3 GWB eine Ausschlussfrist aussprechen: Wenn nicht spätestens bis zur Angebotsabgabe oder Bewerbung die Rüge ausgesprochen wird, dann ist der Bieter auf jeden Fall präkludiert. Vom Erfordernis der Unverzüglichkeit ab positiver Kenntnis wird dadurch jedoch keine Ausnahme gemacht. Allerdings hat diese „deutsche Lösung der unverzüglichen Rügeerhebung“ 312 Gegenwind vom EuGH erhalten (EuGH v. 28.1.2010 – C-406/08, C-456/08, zu englischen und irischen Regelungen hinsichtlich von Fristen zur Einleitung einer Vergabenachprüfung): „Eine Ausschlussfrist, deren Dauer in das freie Ermessen des zuständigen Richters gestellt ist, ist für die Bieter in ihrer Dauer nicht vorhersehbar und stellt nicht die wirksame Umsetzung der Rechtsmittelrichtlinie sicher.“ Die Entscheidung wirft somit die Frage auf, ob deutsches Recht auf eine „unverzügliche Rüge“ abstellen kann bzw. ob § 107 Abs. 3 Nr. 1 GWB europarechtskonform ist. Die Rechtsprechung hatte zunächst uneinheitlich auf die vorgenannte Entscheidung des EuGH reagiert: – § 107 Abs. 3 Nr. 1 GWB darf nicht mehr angewandt werden, und dies wird weitgehend damit begründet, dass – die Zulässigkeit der Nachprüfung von der Rechtzeitigkeit (= Unverzüglichkeit) der Rüge abhängt; – Unsicherheit besteht, was damit für ein Zeitraum gemeint ist; – die Legaldefinition in § 121 Abs. 1 BGB an diesem Ergebnis nichts ändert1.

1 So VK Arnsberg v. 25.8.2010 – VK 15/10; OLG Celle v. 26.4.2010 und v. 4.3.2010; VK Hamburg v. 7.4.2010 – VK BSU 2/10 und 3/10; VK Rheinland-Pfalz v. 20.4.2010 – VK 2-07/10 und 2-09/10; VK Saarland v. 8.3.2010; VK Nordbayern v. 10.2.2010 – 21-VK-3194-01/10.

Bischof

1247

N Rz. 313

Einzelprobleme

– § 107 Abs. 3 Nr. 1 GWB ist nicht betroffen, denn – § 107 Abs. 3 enthält materiell-rechtliche Präklusionsregel, keine „Klagefrist“; – kein Ermessen; „unverzüglich“ ist legaldefiniert; keine Ungewissheit der Bieter1. 313

Für die Vergaberechtspraxis ergibt sich daher derzeit eine erhebliche Rechtsunsicherheit, da die Rechtsprechung und auch die Literatur2 nicht einheitlich sind. Aus Sicht der öffentlichen Auftraggeber wird – folgt man der EuGH-Rechtsprechung – es den Bietern wieder ermöglicht, „Rügen zu sammeln“ und daher ggf. ein Verfahren erheblich zu verschleppen, wenn „geballt“ erst dann gerügt wird, wenn der Bieter entgegen seiner Erwartung den Zuschlag nicht erhält. Bis zur endgültigen Klärung sollten Bieter im eigenen Interesse aber wohl auch weiterhin unverzüglich rügen, um sich nicht doch einer Präklusionsgefahr auszusetzen.

314

Ob Beweismittel für den Verstoß bereits beschafft sind, ist nicht ausschlaggebend3. Die Rüge muss vom Bieter selbst gegenüber dem Auftraggeber unter Darstellung des Sachverhalts, der für vergabewidrig gehalten wird, erhoben werden. Es bestehen keine besonderen formellen Anforderungen, so dass auch eine mündliche oder telefonische Rüge möglich ist. Aus Beweisgründen ist es jedoch empfehlenswert, die Rüge in Schriftform einzureichen (z.B. vorab per E-Mail und Telefax, per Post bzw. eingeschriebenem Brief). Eine detaillierte rechtliche Begründung ist nicht erforderlich.

315

Allerdings gibt es auch einige – wenige – Fallkonstellationen, in denen eine solche Rüge gegenüber dem Auftraggeber entbehrlich ist: – Es ist bereits ein Nachprüfungsverfahren anhängig und der Bieter/Antragsteller erhält Kenntnis von weiteren Verstößen. In diesem Fall genügt es, wenn die weiteren Verstöße direkt gegenüber der Vergabekammer gerügt werden. – Die bereits gerügten Verstöße werden wiederholt oder setzen sich fort (z.B. unzulässige Verhandlungen mit einem Bieter im offenen oder nichtoffenen Verfahren, § 101 Abs. 2 und 3 GWB).

1 So OLG Dresden v. 7.5.2010 – WVerg 6/10; 1. VK Bund v. 5.3.2010 – VI 1-16/10; VK Hessen v. 23.8.2010. 2 Vgl. Schwintowski, Bieterbegriff – Suspensiveffekt und konkrete Stillhaltefrist im deutschen und europäischen Vergaberecht, VergabeR 2010, 877 ff. (bejaht Verstoß gegen europäisches Primär- und Sekundärrecht); Pooth, „Muss man noch unverzüglich rügen“, VergabeR 2011, 358 (verneint Verstoß gegen die Rechtsmittelrichtlinie). 3 S. OLG Naumburg, BauRB 2994, 141.

1248

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 320 N

– Der Auftraggeber hat bereits eindeutig und unmissverständlich erklärt, dass er einen bekannten Vergabeverstoße nicht abstellen wird, also sein Verhalten nicht ändern wird. – Eine vorherige Rüge könnte zu einer Rechtsverkürzung zum Nachteil des Bieters führen, z.B. wenn sich das Verfahren in einem so fortgeschrittenen Stadium befindet, dass der Auftraggeber unmittelbar nach Eingang der Rüge den Zuschlag erteilen und damit ein Nachprüfungsverfahren vereiteln könnte (s. § 114 Abs. 2 Satz 1 GWB). Diese Konstellation war jedoch von jeher umstritten und ist auf Grund der in § 101a GWB enthaltenen Informationspflicht ohnehin weitgehend gebannt. Nicht geregelt ist, ob bzw. wie viel Zeit der Bieter zwischen Rüge und Einreichung des Nachprüfungsantrags abzuwarten hat. Sinn und Zweck der Rügepflicht ist es, dem Auftraggeber die Möglichkeit zu geben, seinen Vergabeverstoß abzustellen, was eine hinreichende Frist voraussetzt.

316

Ein Nachprüfungsantrag unmittelbar nach der Rüge würde dem widerspre- 317 chen. Allerdings ist auch zu berücksichtigen, dass die Rüge noch nicht zum Zuschlagsverbot des § 115 Abs. 1 GWB führt. Dem Sicherungsbedürfnis der Bieter trägt in allen förmlichen Vergabeverfahren § 101a GWB mit seiner Informationspflicht von 15 Kalendertagen bzw. 10 Kalendertagen bei Information per Fax oder auf elektronischem Weg vor Zuschlagserteilung Rechnung. Dies gilt jedoch – naturgemäß – nicht für die faktischen Vergaben. Hier kann es daher angezeigt sein, der Rüge möglichst kurzfristig den Nachprüfungsantrag nachfolgen zu lassen, um einen Zuschlag zu verhindern. Die Angemessenheit der Frist zwischen Rüge und Nachprüfungsantrag bleibt daher der Prüfung im konkreten Einzelfall vorbehalten. Für jeden Bieter hat die Vorschrift des § 107 Abs. 3 GWB somit praktisch 318 zur Folge, dass das Vergabeverfahren genau beobachtet werden muss und sowohl die Vergabeunterlagen als auch jedes weitere Schriftstück, das vom Auftraggeber versandt wird, sowie die persönlichen Gespräche und Verhandlungsrunden stets mit einem kritischen Auge bezüglich etwaiger Vergaberechtsverstöße betrachtet werden müssen. So sollten die Vergabeunterlagen daraufhin überprüft werden, ob z.B. unzuläs- 319 sige Nachweise verlangt werden, diskriminierende, wettbewerbsverzerrende, einseitig andere Bieter bevorteilende Leistungsanforderungen gestellt werden, ob an der Erstellung der Verdingungsunterlagen Dritte beteiligt waren, die nun ggf. ebenfalls im Vergabeverfahren als Konkurrenten teilnehmen. Zu berücksichtigen ist in diesem Zusammenhang besonders die mit Ver- 320 gaberechtsreform 2009 neu eingeführte Regelung des § 107 Abs. 3 Nr. 4 GWB: Ein Nachprüfungsantrag ist dann unzulässig, wenn dieser erst mehr als 15 Kalendertage nach Eingang der Mitteilung des Auftraggebers, einer Rüge nicht abhelfen zu wollen, bei der Vergabekammer eingeht. Während eines laufenden Vergabeverfahrens kann diese Bestimmung zur Folge haben, dass ein Bieter bereits ein Nachprüfungsverfahren einleiten muss, bevor er

Bischof

1249

N Rz. 321

Einzelprobleme

den Ausgang des Verfahrens überhaupt kennt. Tut er dies nicht, kann er sich auf diese Rüge, der nicht abgeholfen wurde, nicht mehr berufen. Für alle Beteiligten ist daher von besonderer Bedeutung, dass auf diese Rechtsmittelfrist zwingend bereits in der Vergabebekanntmachung hinzuweisen ist. Fehlt es an einem solchen Hinweis, ist die Frist des § 107 Abs. 3 Nr. 4 GWB nicht beachtlich1. gg) Unverzügliche Begründung des Nachprüfungsantrags (§ 108 Abs. 1 GWB) 321

§ 108 Abs. 1 GWB bestimmt, dass der Nachprüfungsantrag unverzüglich zu begründen ist. Daher würde es zunächst genügen, zu sämtlichen Zulässigkeitsvoraussetzungen vorzutragen und die Begründung innerhalb kurzer Zeit nachzureichen. Nachdem das Nachprüfungsverfahren vom Beschleunigungsgrundsatz geprägt ist und die Vergabekammer bereits binnen fünf Wochen das Verfahren abschließen soll, also eine Entscheidung zu treffen hat, erfolgen in der Praxis Antragstellung und Begründung in aller Regel gemeinsam. Dies liegt v.a. daran, dass eine Vergabekammer den Nachprüfungsantrag nur dann zustellt, sofern dieser nicht offensichtlich unzulässig oder unbegründet ist. Daher muss sich die Vergabekammer einen groben Überblick zu den erhobenen Vorwürfen verschaffen, was letztlich nur bei Vorliegen einer Begründung gelingt. Die Begründung muss gem. § 108 Abs. 2 Satz 1 GWB umfassen: – Bezeichnung des Antragsgegners – Beschreibung der behaupteten Rechtsverletzung mit Sachverhaltsdarstellung – Bezeichnung der verfügbaren Beweismittel – Darlegung der Rügeobliegenheit gem. § 107 Abs. 3 GWB (s. dazu bereits oben Rz. 308 ff.)2. hh) Zustellung des Nachprüfungsantrags und Wirkung (§ 115 GWB)

322

Nach Eingang des Nachprüfungsantrags prüft die Vergabekammer im Weg einer Vorprüfung, ob der Antrag nicht offensichtlich unzulässig oder unbegründet ist3. Gibt es hierfür keine Anhaltspunkte, so ist der Nachprüfungsantrag zuzustellen, zumindest gem. dem Wortlaut von § 110 GWB, der keine weiteren Voraussetzungen kennt. Üblicherweise sehen jedoch die Geschäftsordnungen der Vergabekammer vor, dass ein Kostenvorschuss zu bezahlen ist4. 1 So zumindest das OLG Celle v. 12.5.2010 – 12 Verg 3/10. S.a. Dirksen, VergabeR 2013, 410. 2 S.a. Ruhland, in: Müller-Wrede, GWB-Vergaberecht, Kommentar, § 108 Rz. 3 ff. m.w.N. 3 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 110 Rz. 21 ff. 4 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 110 Rz. 27.

1250

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 329 N

Mit der Zustellung des Nachprüfungsantrags an den Auftraggeber darf die- 323 ser gem. § 115 Abs. 1 GWB vor einer Entscheidung der Vergabekammer und dem Ablauf der Beschwerdefrist nach § 127 Abs. 1 den Zuschlag nicht erteilen1. Wird dennoch ein Zuschlag erteilt, so ist dieser gem. § 134 BGB nichtig. ii) Verfahrensbeteiligte sowie deren Rechte und Pflichten Verfahrensbeteiligte nach § 109 GWB sind:

324

– Antragsteller – Auftraggeber – Unternehmen, deren Interessen durch die Entscheidung schwerwiegend berührt werden und die beigeladen worden sind. Auch im Verfahren vor der Vergabekammer ist die notwendige Beiladung2 325 vorgesehen. Notwendig ist die Beiladung dann, wenn der Ausgang des Nachprüfungsverfahrens rechtsgestaltende Wirkung für ein drittes Unternehmen hat. Dies ist beispielsweise der Fall, wenn die Aufhebung des Vergabeverfahrens gefordert wird und damit der bestplatzierte Bieter den Zuschlag nicht erhalten würde. Im Übrigen steht die Beiladung im Ermessen der Vergabekammer: alle aus 326 Sicht der Vergabekammer relevanten Aspekte können berücksichtigt werden. Die Vergabekammern laden beispielsweise diejenigen Bieter bei, bei denen nach Sachlage mit einem weiteren Nachprüfungsantrag gerechnet werden kann. Wichtig aus Unternehmenssicht ist auch, dass auf die Beiladung nicht verzichtet werden kann. Erfolgt eine Beiladung, kann sich das Unternehmen dem nicht einseitig entziehen.

327

Der Beigeladene hat – auf Grund der damit einhergehenden Bindungswirkung – auch folgende umfassenden Rechte:

328

– Recht zu tatsächlichen und rechtlichen Ausführungen – Recht zur Akteneinsicht – Recht zur Geltendmachung aller sonstigen Angriffs- und Verteidigungsmittel – Recht zur Antragstellung, um die eigenen Interessen wahrzunehmen3. § 113 Abs. 2 Satz 1 GWB verpflichtet alle Beteiligten, an der Aufklärung des 329 Sachverhalts mitzuwirken (Pflicht zur Förderung des Verfahrens). Die Vorschrift wird an verschiedenen Stellen des GWB konkretisiert, so insbesondere in §§ 107 Abs. 3, 110 Abs. 2 Satz 3, § 111 Abs. 1, § 112 Abs. 1 GWB. 1 S. zur Ausnahme gem. § 115 Abs. 2 GWB auf Antrag des Auftraggebers: Reidt/ Stickler/Glahs, Vergaberecht, Kommentar, § 115 Rz. 26 ff. 2 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 109 Rz. 22 ff. 3 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 109 Rz. 29 ff.

Bischof

1251

N Rz. 330

Einzelprobleme

jj) Untersuchungsgrundsatz, § 110 GWB 330

Wesentliches Verfahrensmerkmal ist, dass die Vergabekammer den Sachverhalt von Amts wegen erforscht, § 110 Abs. 1 Satz 1 GWB. Die Vergabekammer soll dabei aber darauf achten, dass der Ablauf des Vergabeverfahrens nicht unangemessen beeinträchtigt wird, § 110 Abs. 1 Satz 2 GWB. Der Antragsteller erhält bereits eine bestimmte „Sicherheit“, wenn die Vergabekammer den Nachprüfungsantrag der Vergabestelle zustellt, da dies nur erfolgt, sofern der Antrag weder offensichtlich unzulässig noch unbegründet ist, § 110 Abs. 2 Satz 1 GWB.

331

Die Vergabekammer fordert dabei zudem die Vergabeakten1, also die Akten, die das Vergabeverfahren dokumentieren, an. Der Auftraggeber ist dabei verpflichtet, der Vergabekammer die Vergabeakten sofort zur Verfügung zu stellen. Sofort bedeutet hier, dass umgehend nach Eingang der Aufforderung die Unterlagen zusammengestellt und auf dem schnellstmöglichen Weg an die Vergabekammer überbracht werde müssen2. Dies verdeutlicht zum einen die Wichtigkeit der Vergabeakten an sich sowie zum anderen die Notwendigkeit deren Führung und Dokumentationspflichten im Lauf des Verfahrens. Mit anderen Worten: Der öffentliche Auftraggeber sollte seine Vergabeakten stets auf dem Laufenden halten und alle Verfahrensschritte/-entscheidungen sofort dokumentieren sowie die Vergabeakten von „vergabefremden“ Unterlagen freihalten. kk) Akteneinsicht, § 111 GWB

332

Die Verfahrensbeteiligten haben Einsichtsrecht in die Akten bei der Vergabekammer. Vom Einsichtsrecht sind diejenigen Unterlagen ausgeschlossen, die Fabrikations-/Betriebs-/Geschäftsgeheimnisse enthalten. Im Übrigen besteht das Einsichtsrecht hinsichtlich sämtlicher der Vergabekammer zur Entscheidung vorliegenden Unterlagen, also sowohl der Akten der Vergabekammer als auch der beigezogenen Vergabeakten, eingereichter Schriftsätze usw. Die Einsicht kann nur bei der Vergabekammer erfolgen; dies gilt auch für nicht ortsansässige Verfahrensbeteiligte.

333

Die Verfahrensbeteiligten haben einen Anspruch auf die – allerdings kostenpflichtige – Erstellung von Ausfertigungen, Auszügen oder Abschriften aus den Akten.

334

Ob die Akteneinsicht neue Erkenntnisse erbringt, hängt wohl wesentlich davon ab, was vom öffentlichen Auftraggeber an Unterlagen in die Vergabeakten aufgenommen wurde. Oftmals liegen den Verfahrensbeteiligten bis auf vom öffentlichen Auftraggeber verwendete Formulare (z.B. zum Vergabevermerk gem. § 30 VOL/A, der sich am Verfahrensablauf orientiert) alle weiteren Schriftstücke ohnehin schon vor. Zudem kann die Vergabekammer gem. § 111 Abs. 2 GWB die Einsicht in Teile der Vergabeakte versagen, 1 S. hierzu Rz. 116 ff. 2 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 110 Rz. 36 m.w.N.

1252

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 335 N

z.B. wenn sehr sensible Bereiche angesprochen sind. Im Regelfall wird es aber notwendig sein, den Verfahrensbeteiligten die wertungsrelevanten Unterlagen zugänglich zu machen, da diese in den meisten Fällen die Entscheidung der Vergabekammer letztlich tragen1. Auch wenn unklar ist, ob neue Erkenntnisse gewonnen werden können, und auch wenn (zurecht) in Teile das Einsichtsrecht von der Vergabekammer nach § 111 Abs. 2 GWB versagt wird, sollte auf dieses Recht keinesfalls verzichtet werden, da es die einzige Möglichkeit darstellt, die vom Auftraggeber geführten Unterlagen „zu Gesicht zu bekommen“. ll) Begründetheit des Nachprüfungsantrags Der Nachprüfungsantrag ist dann begründet, wenn tatsächlich ein Ver- 335 gaberechtsverstoß vorliegt, der den Antragsteller in seinen Rechten verletzt. Typische Beispiele hierfür sind: – Scientology-Erklärung: Die Forderung nach einer solchen Erklärung hält einer Überprüfung aus europarechtlicher Sicht nicht stand. – Fehlende Produktneutraliät (§ 8 EG Abs. 7 VOL/A): Es werden bestimmte technische Merkmale unter konkreter Bezugnahme auf Herstellernamen gefordert. Um eine solche Anforderung „vergabefest“ aufstellen zu können, müsste die Notwendigkeit der Nennung bestimmter Produkte (z.B. Markennamen, Typenbezeichnungen etc.) substantiiert dargelegt werden können. Allerdings wurde die Produktneutralität sehr restriktiv von den Nachprüfungsorganen ausgelegt. So ist insbesondere der Zusatz „oder gleichwertiger Art“, der bei Forderung eines bestimmten Produkts stets hinzuzufügen ist, dann dennoch nicht ausreichend, wenn die Spezifikation des benannten Herstellers bis ins letzte Detail übernommen wurde. Dieses Verhalten wird als wettbewerbsfeindlich gewertet. Die Entscheidungen der Nachprüfungsorgane verdeutlichen, dass es nicht gelingen kann, durch die rein formale Verwendung des Zusatzes „oder gleichwertiger Art“ wieder einen vergaberechtskonformen Zustand herzustellen. Ein konkretes Beispiel hierzu: Von Seiten der EU-Kommission wird – wie dies auch von AMD getan wird – beanstandet, dass in Ausschreibungen Intel-Mikroprozessoren oder Intel gleichwertige Produkte verlangt bzw. zu spezifische Produktvorgaben (z.B. Vorgabe von Mikroprozessoren mit einer bestimmten Taktfrequenz) gemacht werden, was zu einer Benachteiligung von Konkurrenten (wie z.B. der Firma AMD) führt. Die Kommission sieht darin einen Verstoß gegen die EU-Richtlinie 93/36/EWG und auch gegen Art. 28 EGV (Einfuhrbeschränkung). Mikroprozessoren und die von ihnen erwartete Leistung könnten z.B. durch unterschiedliche „Benchmarks“ beschrieben werden, die Taktfrequenz könne die Leistung eines Rechners nicht wiedergeben. 1 S. zum Einsichtsrecht: Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 110 Rz. 7 ff., 12 ff.; insbesondere OLG Jena, NZBau 2000, 354.

Bischof

1253

N Rz. 336

Einzelprobleme

mm) Entscheidung, §§ 113, 114 GWB und dessen Bindungswirkung gem. § 124 GWB 336

Es gilt der in § 113 GWB postulierte Beschleunigungsgrundsatz. Die Vergabekammer hat binnen fünf Wochen ab Eingang des Nachprüfungsantrags eine Entscheidung zu treffen und diese zu begründen, § 113 Abs. 1 Satz 1 GWB. In Ausnahmefällen kann der Vorsitzende diese Frist um den erforderlichen Zeitraum unter Mitteilung der entsprechenden Begründung verlängern. Hierfür ist erforderlich, dass tatsächliche oder rechtliche Schwierigkeiten bestehen. Beispiele hierfür sind: – Überlastung der Vergabekammer (wovon auch des Öfteren Gebrauch gemacht wird)1, – hohe Anzahl an Beteiligten, denen rechtliches Gehör zu gewähren ist, – Erforderlichkeit der Einschaltung eines Sachverständigen, – sehr komplexe oder sehr seltene Vergabevorgänge.

337

Der Vergabekammer ist es gestattet, gem. § 113 Abs. 2 Satz 2 GWB den Verfahrensbeteiligten Fristen für deren Sach- und Rechtsvortrag zu setzen. Werden diese Fristen von den Betroffenen nicht eingehalten, so kann danach erfolgender Vortrag von der Vergabekammer unbeachtet bleiben. Diese Regelung erscheint auch interessengerecht im Hinblick auf den Beschleunigungsgrundsatz des Vergabeverfahrens sowie im Vergleich zu anderen Verfahrensordnungen (z.B. ZPO).

338

An gestellte Anträge ist die Vergabekammer nicht gebunden, unterliegt aber dem Verhältnismäßigkeitsgrundsatz. Sie kann daher nach eigenem Ermessen auf die Rechtmäßigkeit des Vergabeverfahrens einwirken, § 114 Abs. 1 Satz 2 GWB2. Die Vergabekammer ist allerdings keine allgemeine Rechtmäßigkeitskontrollinstanz: In aller Regel orientiert sich die Vergabekammer an den gestellten Anträgen und geht nur in Ausnahmefällen darüber hinaus. Gerade wenn dem Auftraggeber Beurteilungs- und Ermessensspielräume zustehen, darf die Vergabekammer diese Entscheidungen nur auf Beurteilungs- und Ermessensfehler hin überprüfen. Ein eigene Entscheidung darf die Vergabekammer nur bei einer Ermessensreduzierung auf 0 treffen3.

339

Die Vergabekammer entscheidet anhand der erfolgten Untersuchungen und Feststellungen, ob der Antragsteller tatsächlich in seinen Rechten aus § 97 Abs. 7 GWB verletzt ist. Der hierfür maßgebliche Zeitpunkt ist der Zeitpunkt der Entscheidung der Vergabekammer. Logische Konsequenz hieraus

1 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 113 Rz. 8 ff.; Bechtold, GWB, § 113 Rz. 2; a.A. Boesen, Vergaberecht, § 113 Rz. 20. 2 S. zur Entscheidungskompetenz der Vergabekammer: OLG Düsseldorf v. 15.6.2005, VergabeR 2005, 670. 3 Vgl. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 289 m.w.N.

1254

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 343 N

ist, dass der Auftraggeber bis zu diesem Zeitpunkt einen bei Verfahrenseinleitung bestehenden Vergabeverstoß heilen kann. Ist Gegenstand des Verfahrens beispielsweise, dass unzulässigerweise die 340 Leistungsbeschreibung für das zu vergebende Softwareprojekt von einem externen Berater erstellt wurde, der enge Geschäftskontakte zu einem konkurrierenden Bieter hat, dessen Leistungsfähigkeit bei der Leistungsbeschreibung berücksichtigt wurde, so kann dieser Verstoß im laufenden Vergabeverfahren dadurch geheilt werden, dass dieser Bieter ausgeschlossen wird. Dies muss die Vergabekammer berücksichtigten. In der Regel kommt – wenn keine weiteren Verstöße vorliegen – nur die Rücknahme des Nachprüfungsantrags oder die Umstellung auf einen Fortsetzungsfeststellungsantrag gem. § 114 Abs. 2 Satz 2 GWB in Betracht1. Stellt die Vergabekammer eine Rechtsverletzung fest, trifft sie die nach An- 341 sicht der Vergabekammer geeignete Maßnahmen, um diese zu beseitigen und eine Schädigung der betroffenen Interessen zu verhindern. Mit anderen Worten: Auch wenn der Antragsteller auf Grund der aus seiner Sicht vorliegenden Schwere der Rechtsverletzungen des Auftraggebers die Aufhebung des Verfahrens beantragt, bedeutet dies nicht, dass es letztlich zu einer Aufhebung kommt. So kann es vorkommen, dass die Vergabekammer z.B. lediglich einen Bieter ausschließt oder anordnet, die Wertung neu durchzuführen oder einen anderen Verfahrensschritt – unter Beachtung der Vorgaben der Vergabekammer entsprechend den Anforderungen des Vergaberechts – zu wiederholen2. Aber auch das Ermessen der Vergabekammer kennt eine Grenze: § 114 Abs. 2 342 Satz 1 GWB. Die Vergabekammer kann einen erteilten Zuschlag nicht mehr aufheben, und zwar unabhängig davon, ob das durchgeführte Vergabeverfahren rechtmäßig oder rechtswidrig war. Der Zuschlag beendet das Vergabeverfahren, ohne dass die Vergabekammer rückwirkende Einflussmöglichkeiten hat3. Wenn das Vergabeverfahren rechtswidrig war, kann dies jedoch gem. § 114 Abs. 2 Satz 2 GWB festgestellt werden4. Jede Entscheidung des Vergabegerichts entfaltet Bindungswirkung gem. 343 § 124 GWB für ein gerichtliches Verfahren vor den ordentlichen Gerichten zur Geltendmachung von Schadensersatz im Hinblick auf – Tenor, – Tatsachenfeststellungen, 1 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 114 Rz. 7a, 47 ff. 2 S. ausführlich zu Entscheidungsmöglichkeiten und Entscheidungsinhalten Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 114 Rz. 10 ff. 3 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 114 Rz. 20 ff. 4 S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 114 Rz. 47 ff.

Bischof

1255

N Rz. 344

Einzelprobleme

– Tragende rechtliche Erwägungen und Wertungen, – Feststellungen zur Verletzung von subjektiven Bieterrechten1. b) Primärrechtsschutz vor dem OLG: Sofortige Beschwerde gemäß § 116 GWB aa) Zulässigkeit, Zuständigkeit 344

Die Entscheidungen der Vergabekammern können im Weg der sofortigen Beschwerde zu den jeweiligen Oberlandesgerichten (deren örtliche Zuständigkeit über den Sitz der Vergabekammer ermittelt wird, § 116 Abs. 3 GWB) angefochten werden, wobei alle Verfahrensbeteiligten berechtigt sind, diese einzulegen. bb) Frist, Form

345

Die sofortige Beschwerde ist gemäß § 117 GWB binnen einer Frist von zwei Wochen einzureichen, wobei diese in der Regel2 erst mit förmlicher Zustellung der Entscheidung der Vergabekammer zu laufen beginnt und nicht bereits mit der Vorab-Übersendung per Fax an alle Beteiligten.

346

Die sofortige Beschwerde muss bei Einlegung schriftlich begründet werden, wobei anzugeben ist, – inwieweit die Entscheidung der Vergabekammer angefochten und welche abweichende Entscheidung beantragt wird sowie – auf welche Tatsachen und Beweismittel die sofortige Beschwerde gestützt wird. Vor den Vergabesenaten der Oberlandesgerichte herrscht gem. § 117 Abs. 3 S. 1 GWB Anwaltszwang. Der Beschwerdeführer muss beachten, dass gem. § 117 Abs. 4 GWB alle Verfahrensbeteiligten des Nachprüfungsverfahrens vor der Vergabekammer vorab über die Einlegung der Beschwerde zu unterrichten sind.

1 Zu Rücknahme eines Nachprüfungsantrags s. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 293 m.w.N. Zu den Kosten eines Nachprüfungsverfahrens sowie der sofortigen Beschwerde s. Bischof, in: Teubel/Scheungrab, Münchner Anwaltshandbuch Vergütungsrecht, § 28 sowie Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 294 f. m.w.N. Zu den Eilverfahren im Vergaberecht s. Willenbruch/Wieddekind, in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 301 ff. m.w.N. 2 Dies gilt jedoch dann nicht, wenn dem Fax ein Empfangsbekenntnis beigefügt ist, das unterzeichnet zurückzufaxen ist: OLG Stuttgart v. 11.7.2000 – 2 Verg 5/00, NZBau 2001, 462.

1256

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 349 N

cc) Wirkung der sofortigen Beschwerde Die Einlegung der sofortigen Beschwerde hat aufschiebende Wirkung (Suspensiveffekt), d.h. die Entscheidung der Vergabekammer kann nicht umgesetzt werden. Zu beachten ist aber, dass diese Wirkung zwei Wochen nach Ablauf der Beschwerdefrist wieder entfällt (§ 118 Abs. 1 Satz 2 GWB).

347

Für den vor der Vergabekammer unterlegenen Bieter hat dies zur Folge, dass er – um eine Zuschlagserteilung wirklich bis zur Entscheidung über die sofortige Beschwerde zu verhindern – einen Antrag auf Verlängerung der aufschiebenden Wirkung (und damit des Zuschlagsverbots) gleichzeitig mit Einlegung der sofortigen Beschwerde stellen muss (§ 118 Abs. 1 Satz 3 GWB). Meist ordnet der Vergabesenat die einstweilige Verlängerung der aufschiebenden Wirkung bis zur Entscheidung über die Verlängerung der aufschiebenden Wirkung an, da der Antrag sorgfältig summarisch geprüft werden muss, v.a., da bei Ablehnung des Antrags der Auftraggeber in der Regel zeitnah den Zuschlag erteilen wird und somit „vollendete Tatsachen“ schafft1. dd) Beschwerdeentscheidung Hält der Vergabesenat die Beschwerde für begründet, so hebt er die Ent- 348 scheidung der Vergabekammer auf (§ 123 Satz 1 GWB), wobei er selbst entscheiden oder die Vergabekammer verpflichten kann, in der Sache neu zu entscheiden. Auch der Vergabesenat ist nicht befugt, einen erteilten Zuschlag aufzuheben (§§ 123 Satz 4, 114 Abs. 2 GWB)2. Nach derzeit allgemeiner Auffassung3 ist gegen die Entscheidung des OLG die in §§ 74 ff. GWB vorgesehene Rechtsbeschwerde nicht zulässig, was u.a. damit begründet wird, dass in § 120 Abs. 2 GWB ein Verweis auf die entsprechenden Zulässigkeitsvoraussetzungen fehlt. In der Praxis werden die Verfassungsbeschwerde und die Rüge nach § 321a ZPO als Rechtsbehelfsmöglichkeiten außerhalb des GWB diskutiert, mit denen ggf. die Entscheidung des OLG erfolgreich angegriffen werden kann. Es erscheint daher in der Beratungspraxis sinnvoll, sich über diese Rechtsschutzmöglichkeiten Gedanken und im Zweifel von beiden Gebrauch zu machen. c) Sekundärrechtsschutz: Schadensersatz gem. § 126 GWB Sekundärrechtsschutz besteht vor den ordentlichen Gerichten. Diese sind 349 gem. § 124 GWB an die Entscheidung der Vergabekammer gebunden, nicht je1 Unterliegt dagegen der Auftraggeber vor der Vergabekammer und legt hiergegen sofortige Beschwerde ein, kann dieser gem. § 121 GWB einen Antrag auf Vorabentscheidung über den Zuschlag stellen (s. hierzu Noch, Vergaberecht kompakt, S. 125 ff.). 2 S. zu Divergenzvorlagen an den BGH: Noch, Vergaberecht kompakt, S. 127 f. m.w.N. 3 BGH, VergabeR 2004, 62; Immenga/Mestmäcker/Stockmann, Fn. 2 zu § 123 Rz. 2 sowie Fn. 2 zu § 124 Rz. 2. S.a. Giedinghaben/Schopp, VergabeR 2007, 33.

Bischof

1257

N Rz. 350

Einzelprobleme

doch an Entscheidungen der Vergabeprüfstellen oder Vergabeüberwachungsausschüsse1. 350

Der Bieter, der ohne Verstoß gegen Vergabevorschriften eine echte Chance auf Erteilung des Zuschlags gehabt hätte, hat gem. § 126 Satz 1 GWB einen Schadensersatzanspruch gegen den Auftraggeber2. Er ist auf den Vertrauensschaden oder das sog. negative Interesse und somit auf die Kosten der Vorbereitung des Angebots oder der Teilnahme am Vergabeverfahren gerichtet3.

351

Trotz dieser Beschränkung kann sich der öffentliche Auftraggeber Schadensersatzansprüchen von erheblicher Höhe ausgesetzt sehen, denn die Teilnahme an einem Vergabeverfahren verursacht bei den IT-Unternehmen erhebliche Kosten, insbesondere wenn der Auftraggeber bei einem Verhandlungsverfahren umfangreiche Prüfungen der Angebote und der Leistungsfähigkeit vorgesehen hat (s. oben „Proof of Solution“). Solche Verfahren binden personelle und technische Ressourcen oft über einen längeren Zeitraum.

352

Darüber hinaus können die Unternehmen zudem weitergehende Ansprüche, also z.B. auf entgangenen Gewinn, nach den allgemeinen Vorschriften geltend machen4; das Vergaberecht steht dem nicht entgegen, was § 126 Satz 2 GWB ausdrücklich festhält. Als Anspruchsgrundlagen kommen in Betracht § 311 Abs. 2 BGB („cic“)5, § 823 Abs. 2 BGB i.V.m. Vergaberecht, § 823 Abs. 1 GBG (Eingriff in den eingerichteten und ausgeübten Gewerbebetrieb), § 826 BGB, §§ 20, 33 GWB i.V.m. UWG6. 3. Rechtsschutz der Bieter unterhalb der Schwellenwerte a) Ausgangslage

353

Die Vorschriften zum Nachprüfungsverfahren gem. §§ 107 ff. GWB gelten nicht für Vergaben unterhalb der Schwellenwerte, also Vergaben im Bereich der Liefer- und Dienstleistungen, bei denen der Auftragswert unter (derzeit) 200 000 Euro (ohne USt.) liegt. Somit haben die Bieter keine Möglichkeit, subjektive Rechte vor der Vergabekammer oder den Oberlandesgerichten7 geltend zu machen. Es fehlte somit lange Zeit an einer gerichtlichen Nach-

1 2 3 4

S. zu Letzterem OLG Naumburg, BauRB 2005, 141. S. zur Haftung des Auftraggebers bei Vergabefehlern: Ohler, BauRB 2005, 153. S. Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 126 Rz. 2, 26 f. S. zur Geltendmachung von entgangenem Gewinn OLG Naumburg, BauRB 2005, 141. 5 S. zum vorvertraglichen Schuldverhältnis aus § 311 Abs. 2 BGB und zur Vertrauenshaftung OLG Dresden v. 10.2.2004 – 20 U 1697/03, BauRB 2004, 205; s. auch LG Leipzig, VergabeR 2006, 288. 6 S. zum Umfang ausführlich Reidt/Stickler/Glahs, Vergaberecht, Kommentar, § 126 Rz. 2, 28 ff. 7 S. hierzu vorstehend, Rz. 287 ff.

1258

Bischof

Öffentliche Vergabe von IT-Leistungen

Rz. 355 N

prüfungsmöglichkeit und damit ein wirklich effektiver Vergaberechtsschutz. In Betracht kamen lediglich: – Beschwerde bei der Rechts- oder Fachaufsichtsbehörde der Vergabestelle – aber kein Anspruch auf Tätigwerden – kartellrechtliche Verstöße gegen das Diskriminierungsverbot § 20 Abs. 1 oder 2 GWB (Zivilrechtsweg) – nur bei marktbeherrschender oder marktstarker Stellung der Vergabestelle – Verwaltungsrechtsweg bei Eingriffen öffentlich-rechtlicher Natur – z.B. Ausschluss des Bieters in Form von Vergabesperren. Gerade ein Handeln öffentlich-rechtlicher Natur wurde jedoch bislang von der herrschenden Meinung in der Regel abgelehnt. b) Einstweiliger Rechtsschutz vor den Zivilgerichten Die Entscheidung des Bundesverwaltungsgerichts1 hat – nach langjährigen 354 Diskussionen zum Rechtsweg – Klarheit geschaffen: Bei den Unterschwellenvergaben ist der Rechtsweg zu den Zivilgerichten eröffnet. Die viel diskutierte Zwei-Stufen-Theorie2 findet auf den Abschluss von Verträgen auf vergaberechtlichem Wege keine Anwendung. Um einen – ggf. kurzfristig anstehenden – Zuschlag zu verhindern, muss ein Bieter vorläufigen Rechtsschutz nach §§ 916 ff. ZPO in Anspruch nehmen, was nach Zuschlagserteilung nicht mehr möglich ist3. Dieser Weg wird in der Praxis auch durchaus beschritten4. c) Ausblick Wie sich der Unterschwellenrechtsschutz in den nächsten Jahren entwickelt, darf mit Spannung erwartet werden. Denn bereits der Koalitions1 BVerwG v. 2.5.2007 – 6 B 10.07, NJW 2007, 2275, VergabeR 2007, 337. 2 S. u.a. OVG Koblenz, v. 25.5.2005, NZBau 2005, 411 f.; s.a. VergabeR 2006, 462 ff.; VG Neustadt a.d. Weinstr., VergabeR 2006, 78 und 351; Sächs. OVG v. 13.4.2006, NZBau 2006, 393; OVG Nordrhein-Westfalen v. 11.8.2006 – 15 E 880/06, VergabeR 2006, 771. 3 S.a. Willenbruch/Wieddekind in: Leupold/Glossner, Münchner Anwaltshandbuch IT-Recht, 2. Aufl., Teil 9, Rz. 306. 4 S. (beispielhaft) Entscheidungen der Zivilgerichte im einstweiligen Rechtsschutz (meist gestützt auf „Verstoß gegen Willkürverbot, Art. 3 Abs. 1 GG), die jedoch überwiegend dem Bieter nicht zum gewünschten Erfolg verholfen haben: LG Cottbus v. 10.9.2007 – 5 O 99/07, VergabeR 2008, 123; LG Frankfurt/O. v. 14.11.2007 – 10 O 360/07, VergabeR 2008, 132; OLG Brandenburg v. 17.12.2007, 13 W 79/07 – VergabeR 2008, 294; LG Landshut v. 11.12.2007 – 73 O 2576/07, VergabeR 2008, 298; OLG Brandenburg v. 29.5.2008 – 12 U 235/07, VergabeR 2008, 992; OLG Oldenburg v. 2.9.2008 – 8 W 117/08, VergabeR 2008, 995. S.a. jüngst zur Stärkung des Rechtsschutzes: OLG Düsseldorf v. 13.1.2010 – 27 U 1/09, VergabeR 2010, 531. S.a. Dicks, forum vergabe 2012, Jahrbuch, S. 121 ff.

Bischof

1259

355

N Rz. 355

Einzelprobleme

vertrag von CDU, CSU und FDP vom 6.10.2009 sieht weitere Reformschritte vor. Die Diskussion zu möglichen Lösungen in der Literatur hat bereits begonnen1. Der Ausschuss Vergaberecht des Deutschen Anwaltvereins (DAV) hat ebenfalls Stellung zum Primärrechtsschutz im Unterschwellenbereich genommen, dessen Erfordernis bejaht und konkrete Vorschläge zur Ausgestaltung unterbreitet2. Entsprechende Evaluierungen sowohl zur Erhebung der notwendigen Daten im Unterschwellenbereich als auch zum einschlägigen rechtlichen Rahmen laufen. Es werden unterschiedliche Modelle diskutiert, denen wohl allen gemeinsam ist, dass eine ordnungsgemäße Vorabinformation der unterlegenen Bieter und eine angemessene Wartefrist bis zur Zuschlagserteilung eingeführt werden soll. Ob und wann mit entsprechenden Neuerungen zu rechnen ist, ist noch nicht absehbar3.

1 S. Burgi VergabeR 2010, 402. 2 Stellungnahme abrufbar unter http://anwaltverein.de/downloads/stellungnahmen/ SN-10/SN48.pdf?PHPSESSID=620rieg5d6iff3arivkjecatu3. 3 S. Krist VergabeR 2011, 163.

1260

Bischof

O. Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software Rz. I. Vorbemerkung . . . . . . . . . . . . . . . II. Versicherungsschutz nach Maßgabe der Betriebshaftpflichtversicherung. . . . . . . . . . . 1. Rechtsgrundlagen . . . . . . . . . . . . 2. Versichertes Risiko . . . . . . . . . . . a) Betriebsbeschreibung . . . . . . . b) Vorsorgeversicherung . . . . . . 3. (Mit-)Versicherte Personen . . . . 4. Versicherte Schadenarten . . . . . a) Personenschäden . . . . . . . . . . b) Sachschäden. . . . . . . . . . . . . . . aa) Beschädigung oder Vernichtung von Sachen. . . . bb) Datenschäden . . . . . . . . . . cc) Beispiele für Sachschäden i.S.v. Ziff. 1.1 AHB . . (1) Lieferung oder Herstellung von vornherein fehlerhafter Software . . . . . . . . . . . . (2) „Weiterfresserschäden“ . . . . . . . . . . . (3) Produktionsschäden . (4) Schäden durch unwirksame Produkte . . 5. Versicherte Ansprüche . . . . . . . . a) Inanspruchnahme auf Schadenersatz . . . . . . . . . . . . . b) Begriff der gesetzlichen Haftpflichtbestimmung . . . . c) Privatrechtliche Natur des Schadenersatzanspruchs . . . . 6. Umfang des Versicherungsschutzes. . . . . . . . . . . . . . . . . . . . . 7. Versicherungssumme . . . . . . . . . a) Wahl der „richtigen“ Versicherungssumme . . . . . . . . . b) Begrenzung der Leistung . . . . aa) Jahreshöchstleistung . . . . bb) Selbstbehalte . . . . . . . . . . . cc) Serienschadenklausel . . . (1) Ursachenklausel . . . . (2) Warenklausel . . . . . . . 8. IT-relevante Ausschlüsse vom Versicherungsschutz . . . . . . . . .

1

4 4 6 6 8 10 11 13 15 15 17 20

20 21 23 25 26 26 31 32 33 36 36 38 38 39 40 41 43

Rz. a) Schäden durch vorsätzliche Handlungen (Ziff. 7.1 AHB) . b) Kenntnisklausel (Ziff. 7.2 AHB). . . . . . . . . . . . . . . . . . . . . . c) Haftungserweiterungen (Ziff. 7.3 AHB) . . . . . . . . . . . . . d) Tätigkeitsschäden (Ziff. 7.7 AHB). . . . . . . . . . . . . . . . . . . . . . aa) Tätigkeitsschäden an bearbeiteten Sachen (Ziff. 7.7 [1] AHB) . . . . . . . bb) Schäden an Hilfsmitteln (Ziff. 7.7 [2] AHB) . . . . . . . cc) Wirkbereichsschäden (Ziff. 7.7 [3] AHB) . . . . . . . dd) Spätschäden . . . . . . . . . . . . ee) Sachfolgeschäden . . . . . . . ff) Deckungserweiterung . . . e) Herstellung und Lieferung (Ziff. 7.8 AHB) . . . . . . . . . . . . . f) Auslandsschäden. . . . . . . . . . . aa) Ziff. 7.9 AHB . . . . . . . . . . . bb) Wiedereinschluss von Auslandsschäden . . . . . . . (1) Versicherte Risiken . . (2) USA/Kanada-Risiken. (3) Zusammenfassung Auslandsdeckung . . . . g) Schäden durch Umwelteinwirkung (Ziff. 7.10 lit. b) AHB). . . . . . . . . . . . . . . . . . . . . . aa) Nullstellung der Betriebshaftpflichtversicherung für Umweltrisiken . . . . . . . . . . . . . . . . . bb) Anwendungsbereich . . . . (1) Allgemeines Umwelt-Betriebsrisiko . . . (2) Umwelt-Produktrisiko . . . . . . . . . . . . . . . h) Strahlenklausel (Ziff. 7.12 AHB). . . . . . . . . . . . . . . . . . . . . . i) Nullstellung von IT-Risiken (Ziff. 7.15 AHB) . . . . . . . . . . . .

45 48 52 53

55 57 58 59 60 61 62 64 64 65 65 70 71

72

72 74 75 76 79 80

44

Koch

1261

O

Einzelprobleme Rz. aa) Löschung, Unterdrückung, Unbrauchbarmachung oder Veränderung von Daten . . . . . . . . . . . . . bb) Nichterfassen oder fehlerhaftes Speichern von Daten . . . . . . . . . . . . . . . . . cc) Störung des Zugangs zum elektronischen Datenaustausch . . . . . . . . dd) Übermittlung vertraulicher Daten oder Informationen . . . . . . . . . . . . . . ee) BHV-IT/Privathaftpflichtversicherung . . . . . 9. Bewertung des Versicherungsschutzes für Softwarehäuser . . .

81

83

84

85 86 87

III. Versicherungsschutz nach Maßgabe der Produkthaftpflichtversicherung. . . . . . . . . . . 88 1. Rechtsgrundlagen . . . . . . . . . . . . 88 2. Adressatenkreis des ProdHM . . 89 3. Versichertes Risiko . . . . . . . . . . . 90 a) Betriebsbeschreibung und Vorsorgeversicherung . . . . . . 90 b) Abgrenzung zur Versicherung des Betriebs(stätten)risikos (Ziff. 1.1). . . . . . . . . . . . . 91 aa) Inverkehrbringen des Erzeugnisses . . . . . . . . . . . 95 bb) Abschluss der Arbeiten oder sonstiger Leistungen . . . . . . . . . . . . . . . . . . . . 97 c) Mitversicherung von Tätigkeitsspätschäden (Ziff. 1.2) . . 100 aa) Einschluss von Tätigkeitsspätschäden . . . . . . . 101 bb) Deckungsumfang . . . . . . . 102 4. Mitversicherte Personen (Ziff. 2) . . . . . . . . . . . . . . . . . . . . . . 103 5. Abgrenzungen und Erweiterungen des Versicherungsschutzes (Ziff. 4 ProdHM) . . . . . 104 a) Ansprüche wegen Schäden infolge Fehlens vereinbarter Eigenschaften . . . . . . . . . . . . . 105 aa) Personen- und Sachschäden sowie Folgeschäden (Ziff. 4.1 ProdHM) . . . . . . 105

1262

Koch

Rz. bb) Vermögensschäden (Ziff. 4.2–4.5 ProdHM) . . . . . . . 106 b) Verbindungs-, Vermischungs-, Verarbeitungsschäden (Ziff. 4.2 ProdHM) . . . . . . . . . . . . . . . . . . . . . . 107 aa) Voraussetzungen des Bausteins gemäß Ziff. 4.2.1 ProdHM . . . . . . . . . . . . . . . . . . . 107 (1) Verbindung, Vermischung oder Verarbeitung mangelhafter Erzeugnisse . . . . . 108 (2) Anwendbarkeit von Ziff. 4.2.1 ProdHM auf Software (Daten und Programme) . . . . . . . . . . . . . 110 bb) Versicherte Kosten (Ziff. 4.2.2 ProdHM) . . . . . . . . . 112 (1) Beschädigung oder Vernichtung anderer Produkte . . . . . . . . . . . . . . . . . . . 113 (2) Herstellungskosten (Ziff. 4.2.2.2 ProdHM) . . . . 114 (3) Nachbesserungskosten (Ziff. 4.2.2.3 ProdHM) . . . . 115 (a) Rechtlich gebotene und wirtschaftlich zumutbare Nachbearbeitung . . . . . . . . . . . . 115 (b) Begriff der anderen Schadenbeseitigung . . . 117 (c) Ausschluss für Rückrufkosten . . . . . . . . . . . . 118 (4) Weitere Vermögensnachteile (Ziff. 4.2.2.4 ProdHM) . . . . . . . . . . . . . . . . 119 (a) Begriff des weiteren Vermögensnachteils. . . 120 (b) Veräußerung des Gesamtprodukts nicht oder nur mit Preisnachlass . . . . . . . . . . . . . 122 (c) Einschränkung der Eintrittspflicht des Versicherers . . . . . . . . . . 123 (5) Produktionsausfall (Ziff. 4.2.2.5 ProdHM) . . . . 124 (a) Begriff des Produktionsausfalls . . . . . . . . . . . 125

O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software Rz.

Rz.

(b) Infolge der Mangelhaftigkeit der Gesamtprodukte . . . . . . . . 126 c) Weiterverarbeitung und -bearbeitung (Ziff. 4.3 ProdHM) . . . . . . 128 aa) Voraussetzungen des Bausteins gemäß Ziff. 4.3.1 ProdHM . . . . . . . . . . . . . . . . . . . 129 (1) Weiterverarbeitung oder -bearbeitung mangelhafter Erzeugnisse . . . . . . . . . . 129 (2) Anwendbarkeit von Ziff. 4.3.1 ProdHM auf Software (Daten und Programme) . . . . . . . . . . . . . 130 bb) Versicherte Kosten (Ziff. 4.3.2 ProdHM). . . . . . . . . 131 (1) Nutzlose Weiterverarbeitungs- oder -bearbeitungskosten (Ziff. 4.3.2.1 ProdHM). . . . . . . . . . . . . . . . 132 (2) Nachbesserungskosten bei Weiterverarbeitungsoder -bearbeitungsschäden und weitere Vermögensnachteile (Ziff. 4.3.2.2 und Ziff. 4.3.2.3 ProdHM) . . . . 133 d) Aus- und Einbaukosten (Ziff. 4.4 ProdHM). . . . . . . . . . . . . . 134 aa) Voraussetzungen des Bausteins gemäß Ziff. 4.4.1 ProdHM . . . . . . . . . . . . . . . . . . . 135 (1) Einbau, Anbringen, Verlegen oder Auftragen mangelhafter Erzeugnisse 135 (2) Anwendbarkeit von Ziff. 4.4.1 ProdHM auf Software (Daten und Programme) . . . . . . . . . . . . . 136 bb) Versicherte Kosten (Ziff. 4.4.2 ProdHM). . . . . . . . . 138 (1) Austauschkosten (Ziff. 4.4.2.1 ProdHM) . . . . 139 (a) Erzeugnis . . . . . . . . . . . . 139 (b) Einzelteile von Erzeugnissen . . . . . . . . . 141

(2) Transportkosten (Ziff. 4.4.2.2 ProdHM) . . . . 142 (3) Nachbesserungsbedingter Austausch (Ziff. 4.4.3 ProdHM) . . . . . . . . . . . . . . . . 143 (4) Ausschlüsse (Ziff. 4.4.4 ProdHM) . . . . . . . . . . . . . . . . 144 (a) Eigenmontage-Ausschluss (Ziff. 4.4.4.1 ProdHM) . . . . . . . . . . . . . 145 (b) Kfz-, Schienen- und WasserfahrzeugteileAusschluss (Ziff. 4.4.4.2 ProdHM) . 147 (c) Ausgrenzung des Austauschrisikos zum Rückrufrisiko (Ziff. 4.4.4.3 ProdHM) . 149 e) Maschinenklausel/Steuerungselementeklausel (Ziff. 4.5 ProdHM) . . . . . . . . . . . . . . . . . . . . . . 150 aa) Maschinenklausel . . . . . . . . . . 150 bb) Deckungserweiterung . . . . . . . 151 (1) Steuerungselementeklausel. . . . . . . . . . . . . . . . . . 151 (2) Anwendbarkeit auf die Produktion, Be- oder Verarbeitung von Daten . . . . . 152 cc) Versicherte Schäden und Kosten (Ziff. 4.5.2 ProdHM) . . 153 (1) Beschädigung oder Vernichtung anderer Produkte (Ziff. 4.5.2.1 ProdHM) . . 153 (2) Nutzlose Herstellungskosten (Ziff. 4.5.2.2 ProdHM) . . . . . . . . . . . . . . . . 154 (3) Nachbesserungskosten (Ziff. 4.5.2.3 ProdHM) . . . . 155 (4) Weitere Vermögensnachteile (Ziff. 4.5.2.4 ProdHM) . . . . . . . . . . . . . . . . 157 (5) Produktionsausfall (Ziff. 4.5.2.5 ProdHM) . . . . 158 (6) Mittelbare Schäden (Ziff. 4.5.2.6 ProdHM) . . . . 160 f) Prüf- und Sortierkosten (Ziff. 4.6 ProdHM) . . . . . . . . . . . . . . . . . . . . . . 162

Koch

1263

O

Einzelprobleme Rz.

Rz.

6. Auslandsdeckung (Ziff. 5 ProdHM) . . . . . . . . . . . . . . . . . . . . 164 7. Risikoabgrenzungen (Ziff. 6 ProdHM) . . . . . . . . . . . . . . . . . . . . 165 a) Nicht versicherte Tatbestände (Ziff. 6.1 ProdHM) . 166 b) Ausschlusstatbestände (Ziff. 6.2 ProdHM). . . . . . . . . . 167 aa) Ansprüche aus Garantien oder Haftungserweiterungen (Ziff. 6.2.1 ProdHM). . . . . . . . . . . . . . . 167 bb) Gewährleistung wegen Rechtsmängeln (Ziff. 6.2.2 ProdHM). . . . . 168 cc) Ansprüche wegen Schäden gemäß Ziff. 7.8 AHB (Ziff. 6.2.3 ProdHM). . . . . 169 dd) Pflichtwidrigkeitsklausel (Ziff. 6.2.4 ProdHM) . 170 ee) Erprobungsklausel (Ziff. 6.2.5 ProdHM). . . . . 171 ff) Luftprodukthaftpflicht (Ziff 6.2.6 ProdHM) . . . . . 174 gg) Konzernklausel (Ziff. 6.2.7 ProdHM). . . . . 176 8. Versicherungsfall und Serienschaden (Ziff. 8 ProdHM). . . . . . 177 a) Versicherungsfall (Ziff. 8.2 ProdHM) . . . . . . . . . . . . . . . . . . 177 b) Serienschaden (Ziff. 8.3 ProdHM) . . . . . . . . . . . . . . . . . . 178 aa) Standardklausel . . . . . . . . 178 (1) Ursachenklausel . . . . 179 (2) Warenklausel . . . . . . . 180 (3) Kontraktionswirkung . . . . . . . . . . . . . . . 181 bb) Alternativklausel . . . . . . . 182 9. Versicherungssumme, Maximierung und Selbstbehalt (Ziff. 9 ProdHM). . . . . . . . . . . . . . 184 a) Versicherungssumme (Ziff. 9.1 ProdHM). . . . . . . . . . 184 b) Maximierung (Ziff. 9.2 ProdHM) . . . . . . . . . . . . . . . . . . 185 c) Selbstbehalt (Ziff. 9.3 ProdHM) . . . . . . . . . . . . . . . . . . 186 10. Bewertung des Versicherungsschutzes für Softwarehäuser . . . 187

IV. Versicherungsschutz nach Maßgabe der BBR IT-Dienstleister . . . . . . . . . . . . . . . . . . . . . . . 188 1. Adressatenkreis der BBR ITDienstleister . . . . . . . . . . . . . . . . . 188 2. Allgemeine Vereinbarungen (Ziff. 1) . . . . . . . . . . . . . . . . . . . . . . 189 a) Versichertes Risiko (Ziff. 1.1.1–1.1.3) . . . . . . . . . . . 189 aa) Softwarebezogene Dienstleistungen . . . . . . . 190 bb) Providertätigkeiten . . . . . 191 cc) Hardwarebezogene Dienstleistungen . . . . . . . 192 b) Versicherte Schadenarten (Ziff. 1.1 Abs. 1–4) . . . . . . . . . . 193 aa) Personen- und Sachschäden . . . . . . . . . . . . . . . . . . . . 193 bb) Vermögensschäden. . . . . . 194 c) Mitversicherte Personen (Ziff. 1.2) . . . . . . . . . . . . . . . . . . 195 d) Versicherungssummen/Maximierung (Ziff. 1.4) . . . . . . . . 196 e) Erweiterungen des Versicherungsschutzes (Ziff. 1.5). . . . . 197 aa) Auslandsschäden (Ziff. 1.5.1) . . . . . . . . . . . . . 198 (1) Zurverfügungstellung von Daten zum Herunterladen . . . . . . . . . 199 (2) Reparatur-, Wartungs- und Pflegearbeiten . . . . . . . . . . . . . . 201 (3) Auslandsdeckungsspezifische Ausschlüsse . . . . . . . . . . . . 202 (4) Anrechnung von Kosten auf die Versicherungssumme . . . . . . . . 203 bb) Daten- und Tätigkeitsschäden (Ziff. 1.5.3) . . . . . 204 (1) Datenschäden . . . . . . . 205 (2) Tätigkeitsschäden . . . 207 (3) Daten- und tätigkeitsschädenspezifische Ausschlüsse . . . . 209 (4) Sublimit und Selbstbeteiligung . . . . . . . . . . 210

1264

Koch

O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software Rz.

Rz.

cc) Vermögensschäden aus der Verletzung von Datenschutzgesetzen und Persönlichkeitsrechten (Ziff. 1.5.5) . . . . . . . . . . . . . 211 (1) Umfang des Versicherungsschutzes . . 211 (2) Persönlichkeitsrechtsspezifische Ausschlüsse . . . . . . . . 213 f) Ausschlüsse (Ziff. 1.7) . . . . . . 214 aa) Unzureichende Datensicherung . . . . . . . . . . . . . . 215 bb) Computerviren und Eingriffe im Datenverarbeitungssystem/Datennetze . . . . . . . . . . . . . . . . . . 220 cc) Luftfahrtprodukte . . . . . . 222 3. Betriebs(stätten)risiko (Ziff. 2) . 224 4. Produkt-/Leistungsrisiko (Ziff. 3) . . . . . . . . . . . . . . . . . . . . . . 225 a) Gegenstand der Versicherung (Ziff. 3.1) . . . . . . . . . . . . . 225 b) Erweiterung des Versicherungsschutzes für Personen-, Sachschäden und Folgeschäden (Ziff. 3.3.1) . . . . . . . . . . . . . . . . 226 c) Erweiterung des Versicherungsschutzes für Vermögensschäden (Ziff. 3.3.3–3.3.5) . . . . . . . . . . . 227 aa) Vermögensschäden im Zusammenhang mit dem Betrieb eines Softwarehauses . . . . . . . . . . . . 228 (1) Software-Erstellung, -Handel, -Implementierung, -Pflege . . . . . . 228 (2) IT-Analyse, -Organisation, -Einweisung, -Schulung. . . . . . . . . . . 229 (3) Netzwerkplanung, -installation, -integration, -pflege . . . . . . 230 bb) Vermögensschäden im Zusammenhang mit Herstellung von und Handel mit Hardware und hardwarebezogenen Tätigkeiten . . . . . . . . . . . . 231

cc) Zeitliche Begrenzung des Versicherungsschutzes . . 232 d) Risikoabgrenzungen und Ausschlüsse (Ziff. 3.4) . . . . . . 233 aa) Erfüllungsansprüche und -surrogate (Ziff. 3.4.1) . . . 234 bb) Ansprüche aus Garantien. . . . . . . . . . . . . . . . . . . . 235 cc) Gewährleistung wegen Rechtsmängeln . . . . . . . . . 236 dd) Ansprüche wegen Schäden gemäß Ziff. 7.8 AHB. 237 ee) Pflichtwidrigkeitsklausel. . . . . . . . . . . . . . . . . 238 ff) Erprobungsklausel . . . . . . 239 gg) Konzernklausel . . . . . . . . . 240 hh) Vollständiges Unterlassen von Wartung und/ oder Pflege . . . . . . . . . . . . . 241 ii) Vertragsverletzungen . . . . 242 jj) Lizenzvergabe . . . . . . . . . . 243 kk) Rückrufkosten . . . . . . . . . 244 e) Versicherungsfall/Serienschaden/Selbstbehalt (Ziff. 3.5) . . . . . . . . . . . . . . . . . . 245 aa) Versicherungsfall . . . . . . . 245 bb) Serienschaden . . . . . . . . . . 246 cc) Selbstbehalt . . . . . . . . . . . . 247 5. Umweltrisiko (Ziff. 4) . . . . . . . . . 248 6. Bewertung . . . . . . . . . . . . . . . . . . . 249 V. 1. 2. 3. 4.

Alternativkonzepte . . . . . . . . . . . 250 Versichertes Risiko . . . . . . . . . . . 251 Versicherte Schadenarten . . . . . 252 Mitversicherte Unternehmen . . 253 Erweiterungen des Versicherungsschutzes . . . . . . . . . . . . . . . . 254 a) Auslandsschäden. . . . . . . . . . . 254 b) Datenschäden . . . . . . . . . . . . . 255 c) Tätigkeitsschäden . . . . . . . . . . 257 d) Verletzung von gewerblichen Schutzrechten, Urheberrechten sowie des Wettbewerbsrechts . . . . . 258 e) Sonstige Erweiterungen . . . . . 262 aa) Verzug . . . . . . . . . . . . . . . . . 262 bb) Umwelteinwirkungen/ Allmählichkeitsschäden . . . . . . . . . . . . . . . . 264 cc) Softwareviren . . . . . . . . . . 265

Koch

1265

O Rz. 1

Einzelprobleme Rz.

Rz.

dd) Mehrkosten nach fehlgeschlagener Installation. . . . . . . . . . . . . . . . . . 266 ee) Verjährungsverlängerung . . . . . . . . . . . . . . . . . . . 267 ff) Strafrechtsschutz . . . . . . . 268 gg) Pflichtwidrigkeitsklausel . . . . . . . . . . . . . . . . 269

f) Nachhaftungsversicherung . . 270 g) Rückwärtsversicherung . . . . . 273 5. Produkt-/Leistungsrisiko . . . . . . 274 a) Lagerhaltungsschäden . . . . . . 275 b) Bauwerksschäden . . . . . . . . . . 276 6. Abschließende Bemerkungen . . 277

I. Vorbemerkung 1

Schäden infolge fehlerhafter Software oder im Zusammenhang mit der Implementierung von Software können Ausmaße annehmen, die die bislang in der nicht virtuellen Welt üblichen Dimensionen bei Weitem übersteigen. Hierzu trägt zum einen die elektronische Vernetzung bei, die zur Folge hat, dass Dritte geschädigt werden, mit denen keine Beziehung besteht und deren Schädigung daher auch nicht in Betracht gezogen werden konnte. Es kommt hinzu, dass IT-Anwendungen oftmals die Arbeitsergebnisse anderer IT-Anwendungen als Eingabe verwenden. Diese Abhängigkeit kann dazu führen, dass ein insgesamt höherer Gesamtschaden beim Erwerber eintritt (Kumulationseffekt). Die Erfahrung lehrt zudem, dass sich Fehler auf Grund der menschlichen Unzulänglichkeit nicht nur innerhalb eines Entwicklungs-, Herstellungs- oder Implementierungsprozesses, sondern ganz generell nicht allein durch präventive Maßnahmen zur Qualitätssicherung vermeiden lassen. Insbesondere die Unternehmensleitung von Softwarehäusern ist deshalb im Rahmen des Risikomanagements (Ebene der Risikosteuerung) gehalten, die finanziellen Folgen eines einmal eingetretenen Schadens durch Sicherstellung risikoadäquaten Versicherungsschutzes soweit wie möglich abzumildern.

2

Im Klartext bedeutet dies nichts anderes, als dass die Unternehmensleitung zu prüfen hat, ob und inwieweit Versicherungsschutz für diese Risiken erhältlich ist, bestehende Verträge der Anpassung bedürfen und erforderlichenfalls neue Versicherungsverträge abgeschlossen werden müssen1. Verletzen die Mitglieder des Vorstands einer AG oder GmbH-Geschäftsführung diese Pflicht, droht ihnen gegenüber der Gesellschaft für den daraus entstandenen Schaden die Haftung in ihrer Eigenschaft als Organ (§§ 93 Abs. 2 AktG, 43 Abs. 2 GmbHG) und nach § 280 Abs. 1 BGB wegen Verletzung der Pflichten aus dem Anstellungsvertrag2. Der Anstellungsvertrag ist auch An-

1 Umfassend R. Koch, Versicherbarkeit von IT-Risiken, Rz. 86 ff.; vgl. auch BGH v. 26.11.1985 – VI ZR 9/85, MDR 1986, 395 = NJW-RR 1986, 572 (574). 2 Nach BGH v. 9.12.1996 – II ZR 240/95, GmbHR 1997, 163 = NJW 1997, 741 (742) nimmt § 43 GmbHG die vertragliche Anspruchsgrundlage vollständig in sich auf, es besteht insoweit keine Anspruchskonkurrenz mehr. Kritisch Scholz/

1266

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 4

O

knüpfungspunkt für die Haftung der Geschäftsführer von BGB- und Personenhandelsgesellschaften nach § 280 Abs. 1 BGB, wobei der beschränkte Sorgfaltsmaßstab der §§ 708, 277 BGB (keine Haftung für leichte Fahrlässigkeit) Anwendung findet, soweit er nicht im Gesellschaftsvertrag abbedungen worden ist1. Die Risikosituation von Softwarehäusern ist u.a. dadurch gekennzeichnet, 3 dass regelmäßig während der Entwicklung und Teilimplementation der Software ein Zugriff auf die IT-Infrastruktur, IT-Anwendungen und Daten des Kunden erfolgt. Vor dem Hintergrund der bislang höchstrichterlich nicht eindeutig geklärten Sachqualität von Daten erweist sich die nur eingeschränkte Deckung von Vermögensschäden sowie der Tätigkeitsschadenausschluss in der herkömmlichen Betriebshaftpflichtversicherung (Muster-Bedingungsstruktur AT) als sehr problematisch. Bei Bestehen einer Produkthaftpflichtversicherung (ProdHM) kommt als praktisches Problem die Abgrenzung zwischen dem Betriebsstätten- und dem Produktrisiko hinzu, die nicht nur bedeutsam für die Deckung von Vermögensschäden, sondern auch für den Ausschluss von Schäden infolge nicht ausreichend erprobter Produkte ist. Die Versicherungswirtschaft hat mittlerweile Konzepte entwickelt, die dieser besonderen Risikosituation von Softwarehäusern besser Rechnung tragen und speziell Deckung für Haftpflichtrisiken aus der Erstellung und dem Vertrieb von Individualsoftware sowie den damit einhergehenden typischen Annextätigkeiten versprechen. Die Konzepte beruhen vielfach auf den Musterbedingungen des Gesamtverbands der Deutschen Versicherungswirtschaft (GDV) (BBR IT-Dienstleister). Bevor auf die Musterbedingungen und alternative Ansätze näher eingegangen wird, soll zunächst der Umfang des Versicherungsschutzes für Softwarehäuser in der herkömmlichen Betriebs- und Produkthaftpflichtversicherung betrachtet und Deckungsdefizite herausgearbeitet werden. Die Darstellung orientiert sich am Aufbau der aktuellen Musterbedingungen des GDV, um dem Leser eine schnelle Zuordnung zu ermöglichen.

II. Versicherungsschutz nach Maßgabe der Betriebshaftpflichtversicherung 1. Rechtsgrundlagen Die herkömmliche Betriebshaftpflichtversicherung baut auf den Allgemei- 4 nen Versicherungsbedingungen für die Haftpflichtversicherung (AHB) und den Besonderen Bedingungen für die Betriebshaftpflichtversicherung auf. Den Vorschriften des VVG kommt daneben nur noch Lückenfüllungs- und – im Rahmen der Inhaltskontrolle nach §§ 307–309 BGB – Kontrollfunktion Schneider, § 43 GmbHG Rz. 13; zum AktG s. Hüffer, § 93 AktG Rz. 11; zur Genossenschaft s. Beuthien, § 34 GenG Rz. 2. 1 Vgl. Palandt/Sprau, § 713 BGB Rz. 11.

Koch

1267

O Rz. 5

Einzelprobleme

zu1. Die Besonderen Bedingungen und Risikobeschreibungen können sich von Versicherer zu Versicherer und von Fassung zu Fassung unterscheiden. Nachstehend wird deshalb auf die vom GDV veröffentlichen Musterbedingungen (Muster-Bedingungsstruktur AT 2011) zurückgegriffen. Welche Besonderen Bedingungen im Einzelfall gelten, muss jeweils anhand der Vertragsunterlagen geprüft werden. Soweit nachstehend auf die AHB Bezug genommen wird, ist die vom GDV veröffentlichte Fassung aus dem April 2012 gemeint, die die zum 1.1.2008 in Kraft getretene Reform des VVG vollständig berücksichtigt. 5

Auf ältere Fassungen der AHB wird nur soweit eingegangen, als sie im Vergleich zu den aktuellen AHB Erweiterungen oder Beschränkungen der Deckung enthalten, die für Softwarehäuser von Bedeutung sind. Ergänzend sei an dieser Stelle darauf hingewiesen, dass bei Altverträgen das VVG a.F. anzuwenden ist, wenn der Versicherungsfall bis zum 31.12.2008 eingetreten ist. Haben die Versicherer von der Möglichkeit der Vertragsanpassung gemäß Art. 1 Abs. 3 EGVVG keinen Gebrauch gemacht, ist die Sanktionsregelung bei Verletzung vertraglich vereinbarter Obliegenheiten unwirksam. Der Versicherer kann deshalb bei grob fahrlässiger Verletzung vertraglicher Obliegenheiten kein Leistungskürzungsrecht gemäß § 28 Abs. 2 Satz 2 VVG geltend machen2. 2. Versichertes Risiko a) Betriebsbeschreibung

6

Der Gegenstand des versicherten Risikos in der herkömmlichen Betriebshaftpflichtversicherung ist nicht (irgend-)eine, sondern die im Versicherungsvertrag und seinen Nachträgen beschriebene betriebliche Tätigkeit des Unternehmens (Grundsatz der Spezialität des versicherten Risikos)3. Für gewöhnlich gibt die Beschreibung des zu versichernden Unternehmens nicht den kompletten Tätigkeits- und/oder Produktionsbereich wieder. In diesem Fall ist im Wege der Auslegung zu ermitteln, welche Tätigkeiten im Einzelnen versichert sind. Dabei kommt dem Merkmal der Branchenüblichkeit entscheidende Bedeutung zu. Hilfstätigkeiten sind (ggf. als Risikoerhöhung, vgl. Ziff. 3.1 (2) AHB) versichert, soweit sie dazu bestimmt sind, dem versicherten (Haupt-/Neben-)Risiko zu dienen4. Solche Tätigkeiten können auch von anderen Betrieben oder Berufen ausgeübt werden. Deshalb kommt es auf die Branchenüblichkeit nicht an5. 1 Palandt/Grüneberg, § 307 BGB Rz. 156; vgl. auch Prölss/Martin/Prölss, Vorbem. I Rz. 13 ff.; Littbarski, AHB, Vorbem. Rz. 15 ff. 2 BGH v. 12.10.2011 – IV ZR 199/10, RuS 2012, 8 ff. 3 Vgl. Ziff. 7.1.1 Mustertarif. 4 Beckmann/Matusche-Beckmann/v. Rintelen, § 26 Rz. 9; Prölss/Martin/Lücke, BHV Nr. 7.1.1 Rz. 6; Späte, BetrH Rz. 7. 5 Vgl. öOGH v. 24.10.1974, VersR 1975, 1140; Beckmann/Matusche-Beckmann/v. Rintelen, § 26 Rz. 9; anders noch R. Koch, VersR 2006, 1433 (1435).

1268

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 10 O

Ist die Erstellung von Individualsoftware oder der Betrieb eines Software- 7 hauses Gegenstand des versicherten Risikos, so ist nicht nur die Erstellung von und der Handel mit Software versichert, sondern auch die Anpassung (z.B. in Form der Parametrisierung) und die Implementierung und Pflege von Software. Als branchenübliche Haupt- oder Hilfstätigkeit dürften darüber hinaus IT-Analyse, -Organisation, -Einweisung, -Schulung sowie alle damit verbundenen Beratungsleistungen zu qualifizieren sein. Ob daneben auch Hardware-Handel, -Modifizierung (Nachrüstung), -Installation, -Wartung und damit verbundene Beratungsleistungen zumindest als Hilfstätigkeit mitversichert sind, ist fraglich. Dafür ließe sich anführen, dass die Erstellung von Software zuweilen eine Vergrößerung der Festplatte oder des Arbeitsspeichers erforderlich macht. b) Vorsorgeversicherung Verneint man die Branchenüblichkeit der Risiken aus hardwarebezogenen 8 Dienstleistungen, kommt eine Mitversicherung nach Maßgabe der Vorsorgeversicherung i.S.v. Ziff. 4 AHB in Betracht. Voraussetzung für das Eingreifen der Vorsorgeversicherung ist jedoch, dass diese Risiken nach Abschluss des Versicherungsvertrags neu entstehen. Gemäß Ziff. 4.1 AHB beginnt der Versicherungsschutz in solchen Fällen sofort mit dem Eintritt des neuen Risikos, ohne dass es einer besonderen Anzeige bedarf. Der Versicherungsnehmer ist aber verpflichtet, auf Aufforderung des Versicherers, die in der Regel durch einen auf der Beitragsrechnung aufgedruckten Hinweis erfolgt, binnen eines Monats nach Empfang dieser Aufforderung jedes neu eingetretene Risiko anzuzeigen. Unterlässt der Versicherungsnehmer die rechtzeitige Anzeige oder kommt 9 innerhalb einer Monatsfrist nach Eingang der Anzeige bei dem Versicherer eine Vereinbarung über den Beitrag für das neue Risiko nicht zustande, so bestimmt Ziff. 4.1 (1) AHB, dass der Versicherungsschutz für dasselbe rückwirkend vom Gefahreneintritt ab fortfällt. Tritt der Versicherungsfall ein, bevor die Anzeige des neuen Risikos erstattet ist, so hat der Versicherungsnehmer zu beweisen, dass das neue Risiko erst nach Abschluss der Versicherung und in einem Zeitpunkt eingetreten ist, in dem die Anzeigefrist nicht verstrichen war. Für gewöhnlich besteht Versicherungsschutz für neue Risiken in der Betriebshaftpflichtversicherung nur zu einem Sublimit (z.B. 1 Mio. Euro für Personen- und 500 000 Euro für Sachschäden). 3. (Mit-)Versicherte Personen Mitversichert in der Betriebshaftpflichtversicherung ist die persönliche gesetzliche Haftpflicht – der gesetzlichen Vertreter des Versicherungsnehmers und solcher Personen, die er zur Leitung oder Beaufsichtigung des versicherten Betriebs

Koch

1269

10

O Rz. 11

Einzelprobleme

oder eines Teils desselben angestellt hat, in dieser Eigenschaft (vgl. Ziff. 7.1.2.3 Muster-Bedingungsstruktur AT); – sämtlicher übrigen Betriebsangehörigen für Schäden, die sie in Ausübung ihrer dienstlichen Verrichtung für den Versicherungsnehmer verursachen (vgl. Ziff. 7.1.2.4 Muster-Bedingungsstruktur AT). Die Betriebshaftpflichtversicherung bietet somit sämtlichen gegenwärtigen und ehemaligen Betriebsangehörigen Schutz gegen die persönliche Inanspruchnahme für Schäden, die auf betrieblich veranlasstem Handeln oder Unterlassen beruhen. Die Betriebsangehörigkeit wird regelmäßig durch Arbeits- oder Dienstvertrag begründet. Betriebsfremde Arbeitnehmer (z.B. Leiharbeiter) werden als Betriebsangehörige angesehen, wenn sie in den Betrieb eingegliedert sind, d.h. mit Wissen und Willen des Betriebsinhabers tätig werden und dessen Weisungen unterstehen1. Die gesetzliche Haftpflicht des Versicherungsnehmers für Schäden, die betriebsfremde Dritte als seine Erfüllungsgehilfen (z.B. Softwareentwicklung durch Subunternehmer) verursachen, wird in der Betriebshaftpflichtversicherung regelmäßig nur im Rahmen des versicherten Risikos des Versicherungsnehmers und gegen eine Zuschlagsprämie mitversichert. 4. Versicherte Schadenarten 11 Gemäß Ziff. 1.1 Satz 1 AHB gewährt der Versicherer für den Fall Versicherungsschutz, dass der Versicherungsnehmer „wegen eines während der Wirksamkeit der Versicherung eingetretenen Schadenereignisses (Versicherungsfall), das einen Personen-, Sach- oder sich daraus ergebenden Vermögsschaden zur Folge hatte, aufgrund gesetzlicher Haftpflichtbestimmungen privatrechtlichen Inhalts von einem Dritten auf Schadenersatz in Anspruch genommen wird.“

Nach der Konzeption der AHB besteht somit standardmäßig nur Deckung für Personen- und Sachschäden. Für sog. echte Vermögensschäden, d.h. Schäden, die weder aus Personen- noch aus Sachschäden resultieren, besteht gemäß Ziff. 2.1 AHB Versicherungsschutz nur bei besonderer Vereinbarung. Eine solche Vereinbarung wird in der Betriebshaftpflichtversicherung zwar standardmäßig getroffen2. Jedoch werden echte Vermögensschäden nur zu einem Sublimit mitversichert. Im Übrigen ist die Deckungserweiterung in erster Linie von Bedeutung für Haftpflichtansprüche aus der Verletzung von Datenschutzgesetzen durch Missbrauch personenbezogener Daten3.

1 Vgl. Prölss/Martin/Lücke, Betriebhaftpfl. Ziff. 7.1.2 Rz. 9; Beckmann/MatuscheBeckmann/v. Rintelen, § 26 Rz. 26. 2 Vgl. Ziff. 7.6.5 Mustertarif. 3 Vgl. Ziff. 7.6.5.1 Mustertarif.

1270

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 14 O

Kein Versicherungsschutz besteht für sonstige Vermögensschäden, die u.a. resultieren

12

– durch vom Versicherungsnehmer (oder in seinem Auftrag oder für seine Rechnung von Dritten) hergestellte oder gelieferte Sachen oder geleistete Arbeiten (Produkt-/Leistungsrisiko) (vgl. Ziff. 7.6.5.2 lit. a) Muster-Bedingungsstruktur AT), – aus planender oder beratender Tätigkeit (vgl. Ziff. 7.6.5.2 lit. b) MusterBedingungsstruktur AT), – aus Tätigkeiten im Zusammenhang mit der Datenverarbeitung (vgl. Ziff. 7.6.5.2 lit. g) Muster-Bedingungsstruktur AT), – aus der Verletzung von gewerblichen Schutzrechten und Urheberrechten sowie des Kartell- und Wettbewerbsrechts (vgl. Ziff. 7.6.5.2 lit. h) MusterBedingungsstruktur AT) sowie – aus der Nichteinhaltung von Fristen und Terminen (vgl. Ziff. 7.6.5.2 lit. i) Muster-Bedingungsstruktur AT). Angesichts dieses umfassenden Ausschlusskatalogs kommt der Abgrenzung zwischen Personen- und Sachschäden einerseits und Vermögensschäden andererseits erhebliche Bedeutung für den Versicherungsschutz zu. a) Personenschäden § 1 Ziff. 1 AHB a.F. definiert den Personenschaden als Schadenereignis, das den Tod, die Verletzung oder Gesundheitsbeschädigung von Menschen zur Folge hat.

13

Beispiel: Durch einen Softwarefehler kommt es zu einer Fehlmedikation bei einem Krankenhauspatienten. Dadurch erleidet dieser eine Lungenembolie. Im Falle einer Haftung des Softwareerstellers besteht für die aus diesem Schadenereignis folgenden Ansprüche aus § 823 Abs. 1 BGB und § 1 Abs. 1 ProdHaftG Deckung. Der Versicherungsschutz erstreckt sich dabei nicht nur auf die erlittenen Körperund Gesundheitsschäden, sondern auch auf alle daraus resultierenden Personenfolgeschäden, auch „unechte“ Vermögensschäden oder Vermögensfolgeschäden genannt, die aus den finanziellen Nachteilen für den Erwerb oder das Fortkommen des Verletzten resultieren (vgl. § 842 BGB)1. Nicht unter den Begriff des Personenschadens i.S.v. § 1 Ziff. 1 AHB a.F. fällt die Verletzung des allgemeinen Persönlichkeitsrechts, soweit nicht zugleich auch eine Verletzung des Körpers oder eine Gesundheitsbeschädigung vorliegt2.

Ziff. 1.1 AHB verzichtet auf die Definition des Personenschadens. Dennoch 14 erscheint es fraglich, ob sich die Verletzung des allgemeinen Persönlichkeitsrechts unter den Begriff des Personenschadens subsumieren lässt, da 1 Vgl. Kilian/Heussen/Reinhardt, Teil 121 Rz. 26. 2 Zum Streit über die Einbeziehung solcher Ansprüche s. Prölss/Martin/Lücke, Nr. 1 AHB Rz. 31 f.; Langheid/Wandt/Büsken, AllgHaftpflV Rz. 24; Späte, § 1 Rz. 49; Littbarski, § 1 Rz. 18; Wussow, § 1 Rz. 80; Bruck/Möller/R. Johannsen8, Bd. IV Anm. G 71.

Koch

1271

O Rz. 15

Einzelprobleme

die Definition des Personenschadens in § 1 Ziff. 1 AHB a.F. dem für die Auslegung von Versicherungsbedingungen maßgeblichen Verständnis des durchschnittlichen Versicherungsnehmers entsprechen dürfte1. Dieser verbindet mit einem Personenschaden die Verletzung des Lebens, des Körpers oder der Gesundheit, nicht aber Rechtsgutsverletzungen, die dem Bereich des allgemeinen Persönlichkeitsrechts zuzurechnen sind (z.B. Ehre)2. Der Verzicht auf eine Definition gibt jedoch Spielraum für eine weitergehende Auslegung. Allerdings sieht Nr. 7.16 AHB ausdrücklich einen Ausschluss für Persönlichkeitsschäden vor. b) Sachschäden aa) Beschädigung oder Vernichtung von Sachen 15 Der Begriff des Sachschadens ist in § 1 Ziff. 1 AHB a.F. als Beschädigung oder Vernichtung von Sachen definiert. Nach der Rechtsprechung liegt ein Sachschaden immer dann vor, wenn auf die Substanz einer bereits bestehenden Sache körperlich so eingewirkt wird, dass deren zunächst vorhandener Zustand beeinträchtigt und dadurch die Brauchbarkeit zur Erfüllung des ihr eigentümlichen Zwecks wirtschaftlich beeinträchtigt wird3. Eine Verletzung der Sachsubstanz selbst ist jedoch nicht erforderlich. Vielmehr reicht eine Einwirkung ohne eine solche aus4. Abweichend von dem für das Haftungsrecht maßgebenden Begriff der Eigentumsverletzung i.S.d. § 823 Abs. 1 BGB lassen sich unter dem Begriff des Sachschadens somit weder das Abhandenkommen noch die bloße Beeinträchtigung des Rechts an einer Sache subsumieren. Auch die bloße Beeinträchtigung der Nutzungsmöglichkeit stellt – soweit nicht eine Einwirkung auf die Sachsubstanz stattgefunden hat – keinen Sachschaden dar5. Dieser Inkongruenz von Haftung und Deckung kommt bei Störungen des Zugangs zum elektronischen Datenaustausch (z.B. DoS-Attacken) Bedeutung zu. Beispiel6: Ein Internet-Kaufhaus beauftragt ein Softwarehaus mit der Erstellung einer speziellen Software, die DoS-Angriffe erkennt und Gegenmaßnahmen ergreift. Trotzdem wird das Kaufhaus Opfer einer solchen Attacke, da die Software den vereinbarten Zweck nicht erfüllt. Die Beeinträchtigung der Nutzbarkeit des Netzwerkrechners 1 St. Rspr., vgl. nur BGH v. 9.6.2004 – IV ZR 228/03, MDR 2004, 1296 = NJW-RR 2004, 1394 (1395). 2 R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1476. 3 Vgl. BGH NJW 1961, 269; BGH VersR 1961, 265 (266); BGH VersR 1969, 723 (726); BGH VersR 1976, 629 (631); BGH VersR 1979, 853 (854); BGH v. 21.9.1983 – IVa ZR 154/81, MDR 1984, 209 = VersR 1983, 1169; OLG Hamm VersR 1978, 28 (29); OLG Hamm v. 11.11.1992 – 20 U 133/92, VersR 1993, 823; OLG Saarbrücken v. 29.11.1995 – 5 U 300/95-20, VersR 1996, 1356 (1357). 4 BGH VersR 1979, 853 (854 f.); OLG Hamm v. 11.11.1992 – 20 U 133/92, VersR 1993, 823; Prölss/Martin/Lücke, Nr. 1 AHB Rz. 22; Littbarski, AHB, § 1 Rz. 18. 5 Vgl. Thürmann/Kettler, S. 52. 6 R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1483.

1272

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 18 O

stellt sich als Eigentumsverletzung dar. Für diese haftet das Softwarehaus unter dem Gesichtspunkt des Inverkehrbringens untauglicher Produkte (Verletzung einer vertraglichen Schutz-/deliktischen Verkehrspflicht). Für die daraus resultierenden Schadenersatzansprüche des Internet-Kaufhauses gegen das Softwarehaus besteht in der herkömmlichen Betriebshaftpflichtversicherung kein Versicherungsschutz, weil es an einem Sachschaden i.S.v. § 1 Ziff. 1 AHB a.F. fehlt. Das Bombardieren eines Netzwerkrechners mit Anfragen (Datenpaketen) stellt keine Einwirkung auf die Sachsubstanz des Netzwerkrechners dar. Versicherungsschutz besteht auch nicht nach den Bestimmungen für die Mitversicherung von Vermögensschäden in der Betriebshaftpflichtversicherung, da diese Produktrisiken ausschließen (Rz. 12).

In Ziff. 1.1 AHB wird auf die Definition des Begriffs des Sachschadens ver- 16 zichtet. Damit ist der Weg frei, diesen – abgesehen von dem Fall des Abhandenkommens – einer Eigentumsverletzung i.S.v. § 823 Abs. 1 BGB gleichzusetzen und somit auch Gebrauchsbeeinträchtigungen darunter zu subsumieren. Dass diese Gleichsetzung durch den Wegfall der Definition beabsichtigt ist, ergibt sich aus den Erläuterungen des GDV. Dieser hat zur Begründung die „eher fließende Rechtsprechung in diesem Bereich“ angeführt. Deshalb sei „eine offene Formulierung als geeigneter anzusehen, umfassend zu greifen“1. bb) Datenschäden Betreffen Schäden infolge fehlerhafter Software nicht Daten und Program- 17 me, sondern z.B. gegenständliche Betriebseinrichtung (IT-Risiken i.w.S.), stellt sich die Frage nach der Sachqualität und damit einhergehend nach dem Vorliegen eines Sachschadens nicht. Beispiel: Der Versicherungsnehmer entwickelt eine Steuerungssoftware für eine Hochregalanlage. Infolge eines Programmfehlers kommt es zu Schäden an dem automatischen Palettenumsetzer.

Fraglich ist jedoch, ob Schäden an Daten und Programmen (IT-Risiken 18 i.e.S.) als Sachschäden zu qualifizieren sind. Insoweit stellt sich auf der Ebene der Deckung – ebenso wie auf der Haftungsebene im Rahmen der Prüfung, ob eine Eigentumsverletzung vorliegt – die Frage nach der Sachqualität von Daten und Programmen2. Entsprechend dem im Rahmen der Auslegung von Versicherungsbedingungen geltenden allgemeinen Grundsatz, dass Worte, mit denen die Rechtssprache feststehende Begriffe verbindet, in diesem Sinne zu verstehen sind3, ist der maßgebliche Sachbegriff 1 Vgl. BGH v. 9.12.2008 – VI ZR 173/07, NJW 2009, 1066; BGH v. 15.11.2006 – XII ZR 120/04, NJW 2007, 2394 (zur vertragstypologischen Einordnung); BFH v. 28.10.2008 – IX R 23/08, BFH/NV 2009, 562 (zur Verlustberücksichtigung nach dem EStG). 2 Vgl. Palandt/Grüneberg, § 90 BGB Rz. 2. 3 Vgl. dazu BGH v. 11.12.2002 – IV ZR 226/01, MDR 2003, 389 = NJW 2003, 826 (828); BGH v. 8.12.1999 – IV ZR 40/99, MDR 2000, 393 = NJW 2000, 1194 (1196).

Koch

1273

O Rz. 19

Einzelprobleme

§ 90 BGB zu entnehmen1. Danach sind Sachen „nur körperliche Gegenstände“. Ob das für die Sacheigenschaft konstituierende Merkmal der Körperlichkeit vorliegt, beurteilt sich in erster Linie nach der Verkehrsanschauung2. 19 Die Maßgeblichkeit der Verkehrsanschauung lässt es geboten erscheinen, die Sachqualität von Daten danach zu beurteilen, ob sie im Falle der Unterbrechung der Energiezufuhr (z.B. Stromausfall) verloren gingen oder erhalten blieben, und nur im ersteren Falle die Sachqualität zu verneinen3. Verletzt der Versicherungsnehmer die Integrität von Daten, die auf dem Computer seines Kunden gespeichert sind, lässt sich ein Sachschaden somit zwanglos bejahen. Es ist nicht erforderlich, dass die Veränderung auf einer Beschädigung oder Zerstörung des Datenträgers beruht oder gleichzeitig damit einhergeht. Damit ist lediglich Daten, die sich im Arbeitsspeicher befinden, Sachqualität abzusprechen. Auf Grund der Maßgeblichkeit der Verkehrsanschauung kann es im Übrigen für Sachqualität nicht darauf ankommen, dass einmal gespeicherte Daten vorübergehend – nämlich im Rahmen der für ihre Bearbeitung oder ihren Aufruf erforderlichen Übertragungs- oder Speichervorgängen außerhalb (Datenfernübertragung) oder innerhalb (Datenbus4) eines Computers – ihre Körperlichkeit verlieren5. Entscheidend ist der „Aggregatzustand“ im Zeitpunkt der Datenveränderung. cc) Beispiele für Sachschäden i.S.v. Ziff. 1.1 AHB (1) Lieferung oder Herstellung von vornherein fehlerhafter Software 20 Die Herstellung oder Lieferung von vornherein fehlerhafter Software stellt keinen Sachschaden i.S.d. Ziff. 1.1 Satz 1 AHB dar. Beispiel: Der Versicherungsnehmer erstellt Software, die mit einem Virus infiziert ist und deshalb nicht einsetzbar ist. Für die Annahme eines Sachschadens fehlt es an der dafür erforderlichen Einwirkung auf die Software. Die geminderte Tauglichkeit der mangelhaften Software ist nämlich nicht Folge der Einwirkung auf diese, sondern das Ergebnis fehlerhafter Herstellung6. Entfaltet das Virus seine schadenstiftende Funktion und löscht oder 1 2 3 4

Vgl. Prölss/Martin/Lücke, Nr. 7 AHB Rz. 38; Littbarski, AHB, § 4 Rz. 197. Vgl. Palandt/Grüneberg, § 90 BGB Rz. 2. Vgl. nur R. Koch, Versicherbarkeit von IT-Risiken, Rz. 357 m.w.N. Beim sog. Datenbus handelt es sich um einen Teil des internen Bussystems eines Computers (Bus). Er übernimmt – im Zusammenwirken mit dem Adressbus und dem Steuerbus – den Transport von Daten. Vgl. Brockhaus, Stichwort „Datenbus“. 5 R. Koch, Versicherbarkeit von IT-Risiken, Rz. 358; R. Koch, Versicherung im ITBereich, in: Karlsruher Forum 2010, S. 121 f.; MünchKomm/Wagner, § 2 ProdHaftG Rz. 16; a.A. Redeker, oben Kap. D Rz. 71 ff. 6 St. Rspr., vgl. BGH VersR 1976, 629 (631); BGH VersR 1979, 853 (854); OLG München v. 27.11.1979 – 5 U 2653/79, MDR 1980, 850 = VersR 1980, 1138 (1139); OLG Hamm v. 21.4.1989 – 20 U 279/88, VersR 1990, 376 (377).

1274

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 22 O

verändert z.B. auf der Festplatte abgespeicherte Dateien, liegt ein sog. Mangelfolgeschaden vor. Die daraus resultierenden Schadenersatzansprüche sowohl aus Vertrag (§§ 634 Nr. 4, 280 Abs. 1 BGB) als auch aus Delikt (§§ 823 Abs. 1 BGB, 1 Abs. 1 ProdHaftG) sind gedeckt, da es sich um einen Sachschaden i.S.v. Ziff. 1.1 AHB handelt1. Führt fehlerhafte Software dazu, dass z.B. Preise falsch ausgewiesen, eingegebene Daten nicht oder nicht korrekt abgespeichert werden, liegt zwar auch ein Mangelfolgeschaden vor, für den der Hersteller haftet, jedoch nicht in Form eines Sach-, sondern eines Vermögensschadens2.

(2) „Weiterfresserschäden“ Von der Fallgruppe der Lieferung oder Herstellung einer mangelhaften Sache 21 abzugrenzen sind die sog. Weiterfresserschäden. Es handelt sich hierbei um die Fälle, in denen ein aus mehreren Einzelteilen bestehendes Erzeugnis – eine zusammengesetzte Sache –, bei dem lediglich ein funktionell abgrenzbares Einzelteil mit einem Mangel behaftet ist, das nach einer gewissen Zeit zur Beschädigung oder Zerstörung der zusammengesetzten Sache oder von Teilen dieser Gesamtsache führt. Die Rechtsprechung bejaht in solchen Konstellationen eine Eigentumsverletzung an der Restsache (= Gesamtprodukt ./. fehlerhaftes Teil), sofern nicht der Mangelunwert der Sache bei Eigentumsübergang und der später eingetretene Schaden stoffgleich sind3. Die Beeinträchtigung der Restsache durch weiterfressende Mängel stellt sich grundsätzlich auch als Sachschaden i.S.v. Ziff. 1.1 Satz 1 AHB dar4. Stoffgleichheit ist zu bejahen, wenn die Sache als Ganzes wegen des Man- 22 gels von vornherein nicht oder nur in sehr eingeschränktem Maße zum vorgesehenen Zweck verwendbar war5. Hierher gehören auch die Fälle, bei denen eine Beseitigung des (wenn auch nur einem Teil der Sache anhaftenden) Fehlers technisch nicht möglich ist; eine gleiche Beurteilung greift Platz, wenn ein Mangel nicht in wirtschaftlich vertretbarer Weise (unter Einbeziehung der Aufwendungen für die Fehlersuche) behoben werden kann6. Ist hingegen der Mangel zunächst nur auf einen Teil des Produkts beschränkt, in wirtschaftlich vertretbarer Weise behebbar und führt er erst später zu einer Zerstörung des Produkts oder zur Beschädigung anderer Teile desselben, dann hat der von dem Fehler zunächst nicht erfasste Teil der Sache einen ei1 Vgl. Kilian/Heussen/Schmidt-Salzer/Otto, Teil 112 Rz. 23. 2 Vgl. BGH v. 26.1.2005 – VIII ZR 79/04 – fehlerhafte Preisauszeichnung durch Datentransferfehler, CR 2005, 355 f. 3 St. Rspr., zuletzt BGH VersR 2005, 554 (556) m.w.N. 4 Vgl. Langheid/Wandt/Büsken, AllgHaftpflV Rz. 32; Rüffer/Halbach/Schimikowski/Schimikowski, Nr. 1 AHB Rz. 27; Produkthaftungshdb./Graf von Westphalen, § 50 Rz. 50; Stempfle, in: MAH VersicherungsR, § 15 Rz. 56 (bezogen auf Ziff. 1.1 ProdHM). 5 Vgl. z.B. BGH v. 18.1.1983 – VI ZR 270/80 – Kfz-Hebebühne, MDR 1983, 390 = NJW 1983, 812; OLG Oldenburg v. 18.4.1985 – mit Nichtannahmebeschluss des BGH v. 20.5.1986 – VI ZR 127/85, VersR 1986, 1003; R. Koch, AcP 203 (2003), 603 (610 f.). 6 Vgl. BGH v. 18.1.1983 – VI ZR 310/79 – Gaszug, BGHZ 86, 256 (262) = MDR 1983, 389.

Koch

1275

O Rz. 23

Einzelprobleme

genen Wert; der Mangelunwert deckt sich dann nicht mit dem Schaden1. Bei Softwarefehlern dürfte die Verwendbarkeit der Software in aller Regel von vornherein beeinträchtigt sein, so dass Stoffgleichheit zu bejahen und deshalb sowohl eine Eigentumsverletzung i.S.v. § 823 Abs. 1 BGB als auch ein Sachschaden i.S.v. Ziff. 1.1 Satz 1 AHB zu verneinen sind2. (3) Produktionsschäden 23 Von der Fallgruppe der Weiterfresserschäden sind wiederum die Fälle abzugrenzen, in denen im Rahmen des Herstellungsprozesses einwandfreie Sachen mit fehlerhaften Sachen verbunden, vermischt oder verarbeitet werden (Produktionsschäden). In solchen Fällen liegt haftungsrechtlich eine Eigentumsverletzung i.S.v. § 823 Abs. 1 BGB3 und deckungsrechtlich ein Sachschaden i.S.v. Ziff. 1.1 Satz 1 AHB4 an den Einzelteilen vor, die zuvor unversehrt im Eigentum des Herstellers der Gesamtsache gestanden haben, soweit diese durch ihr unauflösliches Zusammenfügen mit fehlerhaften Teilen des Zulieferers nicht nur in ihrer Verwendbarkeit, sondern erheblich in ihrem Wert beeinträchtigt oder gar wertlos geworden sind5. Diese Produktionsschäden resultieren vornehmlich aus der industriellen Fertigung von Massenprodukten. 24 Ob diese Grundsätze auf die Erstellung von Individualsoftware übertragbar sind, ist fraglich. Zweifel sind vor allem deshalb angebracht, weil den fehlerhaften Daten und Programmen im Zeitpunkt der Verbindung, Vermischung oder Verarbeitung keine Sachqualität zukommt und es insofern am Vorhandensein zweier Sachen fehlt6. Beispiel: Der Versicherungsnehmer beliefert A mit Software, die dieser in ein Softwarepaket integriert. Ist nun die Software des Versicherungsnehmers mit einem Mangel behaftet, der dazu führt, dass das gesamte Softwarepaket nicht mehr eingesetzt werden kann, stellt sich die Frage, ob für die Schadenersatzansprüche des A wegen Unbrauchbarkeit der von ihm beigesteuerten fehlerfreien Software Deckung besteht. Werden die Daten oder Programme über eine Kabelverbindung oder ein Funknetz direkt von einer Festplatte auf die andere Festplatte übertragen7 oder von Diskette, CD-ROM oder online über das Internet zunächst in den Arbeitsspeicher geladen, 1 Vgl. BGH NJW 1985, 2420 – Kompressor. 2 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 633 ff. 3 Nach h.M. sind Weiterfresserschäden nicht nach dem ProdHaftG ersatzfähig; vgl. nur Darstellung des Streitstands bei R. Koch, Versicherbarkeit von IT-Risiken, Rz. 610. 4 Vgl. Späte, § 1 Rz. 70; Wussow, § 1 Anm. 45; Krause, NVersZ 2001, 103 (107); Thürmann, PHI 2000, 163 (169); differenzierend Schmidt-Salzer/Hinsch, Rz. 7.550. 5 Vgl. BGH NJW 1998, 1942 (1943) – Transistor. 6 R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1727. 7 Diese Übertragungsmöglichkeit lag der Entscheidung BGH v. 18.10.1989 – VIII ZR 325/88, CR 1990, 24 = CR 1990, 112 m. Anm. Heymann = NJW 1990, 320 ff. zugrunde.

1276

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 26 O

verlieren sie ihre Körperlichkeit und damit ihre Sachqualität in dem Moment, in dem der Datentransfer – innerhalb des Computers erfolgt er im Rahmen des Bussystems zumeist über elektrische Leitungen1 – beginnt. Erst mit dem Abspeichern der aufgespielten Daten und Programme auf einem Datenträger erlangen sie wieder die Eigenschaft als Sache.

(4) Schäden durch unwirksame Produkte Wirkt ein fehlerhaftes Produkt auf (andere) Sachen des Erwerbers schädi- 25 gend ein, liegt haftungsrechtlich eine Eigentumsverletzung und deckungsrechtlich ein Sachschaden vor. Dies gilt in gleicher Weise, soweit die Fehlerhaftigkeit darin begründet ist, dass sich eine Gefahr verwirklicht hat, die von dem Produkt abgewehrt werden sollte, aber tatsächlich nicht abgewehrt wurde2. Beispiel: Eine falsch programmierte Sprinkleranlage schaltet sich bei einem Brand nicht ein. Die Schadenersatzansprüche des Auftraggebers aus Vertrag (§§ 634 Nr. 4, 280 Abs. 1 BGB) und Delikt (§ 823 Abs. 1 BGB) gegen den für die fehlerhafte Programmierung Verantwortlichen wegen etwaiger Personen- und Sachschäden sind vom Versicherungsschutz umfasst.

5. Versicherte Ansprüche a) Inanspruchnahme auf Schadenersatz Nach dem Wortlaut von Ziff. 1.1 AHB sind grundsätzlich nur Schaden- 26 ersatzansprüche Dritter gegen den Versicherungsnehmer gedeckt. Für Ansprüche, die nicht auf diese Rechtsfolge gerichtet sind, z.B. auf Übergabe und Übereignung der Kaufsache (§ 433 Abs. 1 Satz 1 BGB), auf Nacherfüllung (§§ 439, 635 BGB) oder Minderung (§§ 441, 638 BGB), besteht grundsätzlich kein Versicherungsschutz. Sie sind Ausdruck des kaufmännischen Risikos, das beim Unternehmer verbleiben soll. Ergänzend bestimmt Ziff. 1.2 AHB, dass kein Versicherungsschutz für Ansprüche, auch wenn es sich um gesetzliche Ansprüche handelt, besteht „– auf Erfüllung von Verträgen, Nacherfüllung, aus Selbstvornahme, Rücktritt, Minderung, auf Schadenersatz statt der Leistung; – wegen Schäden, die verursacht werden, um die Nacherfüllung durchführen zu können; – wegen des Ausfalls der Nutzung des Vertragsgegenstandes oder wegen des Ausbleibens des mit der Vertragsleistung geschuldeten Erfolges; – auf Ersatz vergeblicher Aufwendungen im Vertrauen auf ordnungsgemäße Vertragserfüllung; – auf Ersatz von Vermögensschäden wegen Verzögerung der Leistung; – wegen anderer an die Stelle der Erfüllung tretender Ersatzleistungen.“ 1 Vgl. Brockhaus, Stichwort „Bus“. 2 Vgl. Produkthaftungshdb./Graf von Westphalen, § 50 Rz. 51 zu Ziff. 1.2 ProdHM (1987).

Koch

1277

O Rz. 27

Einzelprobleme

27 Die Regelungen des 1. und 6. Spiegelstrichs erfassen die Erfüllung von Verträgen als solche sowie die an die Stelle der Erfüllung tretenden Ersatzleistungen. Bei diesen Formulierungen handelt es sich nach Ansicht der Rechtsprechung um eigenständige versicherungsrechtliche Begriffe, die losgelöst davon seien, wie die vom Geschädigten erhobenen Ansprüche vertraglich einzuordnen sind1. Was unter diesen Begriffen zu verstehen sei, müsse anhand des Interesses am unmittelbaren Leistungsgegenstand bestimmt werden, wie es in den den Versicherungsnehmer bindenden Verträgen seinen Niederschlag gefunden habe2. Beim Kaufvertrag schuldet der Verkäufer die Lieferung einer mangelfreien Sache. Beim Werkvertrag schuldet der Auftragnehmer im Rahmen der getroffenen Vereinbarung ein funktionstaugliches und zweckentsprechendes Werk. Ist die Sache oder das Werk mit einem Mangel behaftet, sind die Gewährleistungsansprüche deshalb dem nicht versicherten vertraglichen Erfüllungsbereich zuzuordnen. Dementsprechend bestimmt Ziff. 1.2 (1) AHB, dass kein Versicherungsschutz besteht für Ansprüche auf Nacherfüllung, aus Selbstvornahme, Rücktritt, Minderung, auf Schadensersatz statt der Leistung. Die Klauseln des 2.–5. Spiegelstriches betreffen ebenfalls Schadenersatzansprüche, die auf Ersatz des Erfüllungsinteresses gerichtet sind, nämlich sog. Nacherfüllungsbegleitschäden, Nutzungsausfallschäden, frustrierte Aufwendungen sowie Verzugsschäden. Soweit die Ansprüche wegen der vorgenannten Schäden/Aufwendungen nicht auf Schadensersatz und/oder nicht auf den Ersatz von Vermögensschäden gerichtet sind, kommt ihnen nur deklaratorische Funktion zu3. Unberührt von Ziff. 1.2 AHB bleiben vertragliche und deliktische Schadenersatzansprüche, die über das unmittelbare Erfüllungsinteresse hinausgehende Schäden zum Gegenstand haben, z.B. weil sie wegen mangelhafter Leistung an anderen Rechtsgütern des Versicherungsnehmers entstanden sind (sog. Mangelfolgeschäden)4. 28 Versicherungsschutz besteht für Ausgleichsansprüche nach § 426 Abs. 1 und 2 BGB5. Beispiel: Der Versicherungsnehmer stellt Steuerungssoftware für Elektromotoren her, die in Dunstabzugsabhauben für Hotelbetriebe eingebaut werden. Auf Grund eines Softwarefehlers kommt es zu einem Brand, der zu erheblichen Sachschäden bei den Betrieben führt. Verschulden aller Beteiligten unterstellt, haften sowohl der Hersteller der Software als auch die Hersteller der Elektromotoren und der Abzugshauben 1 Vgl. BGH v. 28.9.2011 – IV ZR 170/10, NJW-RR 2012, 103 (104); BGH 19.11.2008 – IV ZR 277/05, NJW-RR 2009, 381 (382). 2 Vgl. BGH v. 28.9.2011 – IV ZR 170/10, NJW-RR 2012, 103 (104). 3 Vgl. Schmidt-Salzer/Thürmann, Rz. 8.106 f. 4 Vgl. BGHZ 43, 88 (90); BGH NJW 1975, 1278 (1279); OLG Hamm v. 29.9.1993 – 20 U 96/93, CR 1994, 679 = NJW-RR 1994, 420 (421); OLG Frankfurt/M. VersR 1982, 790; OLG Köln v. 23.6.1983 – 5 U 224/82, VersR 1985, 933; OLG Koblenz v. 29.10.1999 – 10 U 1052/98, VersR 2000, 755 (756). 5 BGH v. 21.5.2003 – IV ZR 209/02, VersR 2003, 901; BGH v. 17.5.1956 – II ZR 96/55, VersR 1956, 364; Prölss/Martin/Lücke, Nr. 1 AHB Rz. 12.

1278

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 31 O

den geschädigten Hotelbetrieben gegenüber als Gesamtschuldner nach §§ 823 Abs. 1, 840 BGB. Entschädigt der Hersteller der Elektromotoren die Betriebe und verlangt vom Versicherungsnehmer Ersatz nach § 426 Abs. 1 Satz 1 BGB und §§ 426 Abs. 2, 823 Abs. 1 BGB, besteht für diese Ansprüche Versicherungsschutz (soweit keine Ausschlüsse eingreifen).

Ansprüche des Beauftragten nach § 670 BGB oder des Geschäftsführers ohne 29 Auftrag gemäß §§ 670, 677, 683 BGB auf Aufwendungsersatz sind dann versichert, wenn die Geschäftsführung darin besteht, die Schadenersatzverpflichtung des Versicherungsnehmers zu erfüllen. Dann tritt der Anspruch des Beauftragten/Geschäftsführers ohne Auftrag an die Stelle des Anspruchs des Geschädigten gegen den Versicherungsnehmer1. Beispiel: Wie zuvor, jedoch bestehen keine Ansprüche der Geschädigten gegen den Hersteller der Elektromotoren, weil dieser – anders als der Softwarehersteller – nicht schuldhaft gehandelt hat. Ausgleichsansprüche nach § 426 BGB kommen hier nicht in Betracht, da keine Gesamtschuld besteht. Entschädigt der Elektromotorenhersteller die Hotelbetriebe, besteht für die Ansprüche gegen den Softwarehersteller nach § 670 BGB oder §§ 670, 677, 683 BGB Versicherungsschutz.

Widerspricht der Softwarehersteller der Geschäftsführung des Elektromoto- 30 renherstellers, wird man in der Konsequenz auch dessen Bereicherungsanspruch gemäß §§ 684, 812 Abs. 1 Satz 1 BGB (Befreiung von einer Verbindlichkeit) als unberechtigter Geschäftsführer vom Anwendungsbereich des § 1 Ziff. 1 AHB umfasst ansehen können. Nach der Rechtsprechung des BGH ist auch der Beseitigungsanspruch nach § 1004 Abs. 1 Satz 1 BGB versichert, soweit er dieselbe wiederherstellende Wirkung hat wie ein auf Naturalrestitution gerichteter Schadenersatzanspruch (vgl. § 249 Abs. 1 BGB)2. Demgegenüber sind Unterlassungsansprüche vom Versicherungsschutz grundsätzlich ausgeschlossen3. b) Begriff der gesetzlichen Haftpflichtbestimmung Versicherungsschutz besteht nur für Schadenersatzansprüche auf Grund ge- 31 setzlicher Haftpflichtbestimmungen. Darunter fallen solche Normen, die unabhängig vom Willen der Beteiligten an die Verwirklichung eines unter Ziff. 1.1 AHB fallenden Ereignisses Rechtsfolgen knüpfen (z.B. § 1 Abs. 1 ProdHaftG, § 823 Abs. 1 BGB, § 280 BGB)4. Dabei macht es keinen Unterschied, ob sie auf Gesetz, Verordnung oder Richterrecht beruhen5. Nicht 1 Vgl. Prölss/Martin/Lücke, Nr. 1 AHB Rz. 13; Langheid/Wandt/Büsken, AllgHaftpflV Rz. 54. 2 Vgl. BGH v. 8.12.1999 – IV ZR 40/99, MDR 2000, 393 = NJW 2000, 1194 ff. 3 Vgl. Prölss/Martin/Voit/Knappmann27, § 1 AHB Rz. 7 (zu §§ 862, 1004 BGB). 4 St. Rspr., vgl. nur BGH v. 11.12.2002 – IV ZR 226/01, RuS 2003, 149 = VersR 2003, 236; BGH v. 8.12.1999 – IV ZR 40/99, RuS 2000, 100 = VersR 2000, 311; BGH v. 20.11.1970 – IV ZR 1188/68, VersR 1971, 144 = NJW 1971, 429. 5 Prölss/Martin/Lücke, Nr. 1 AHB Rz. 6; Späte, § 1 Rz. 126; Schmidt-Salzer, Produkthaftung IV/1 Rz. 7.216.

Koch

1279

O Rz. 32

Einzelprobleme

vom Versicherungsschutz umfasst sind demgegenüber Haftpflichtansprüche, die nur auf Grund einer die gesetzliche Haftpflicht erweiternden vertraglichen Vereinbarung durchgesetzt werden können (Rz. 52). c) Privatrechtliche Natur des Schadenersatzanspruchs 32 Die von Dritten gegenüber dem Versicherungsnehmer geltend gemachten Schadenersatzansprüche müssen auf Grundlage gesetzlicher Haftpflichtbestimmungen privatrechtlichen Inhalts geltend gemacht werden. Ausgenommen vom Versicherungsschutz sind somit Schadenersatzansprüche aus öffentlich-rechtlichen Vorschriften (z.B. Ersatz der Kosten einer behördlich angeordneten Ersatzvornahme nach Maßgabe des allgemeinen Polizei- und Ordnungsrechts)1. 6. Umfang des Versicherungsschutzes 33 Der Umfang des Versicherungsschutzes ist Gegenstand von Ziff. 5.1 AHB. Danach umfasst die Leistungspflicht des Versicherers „die Prüfung der Haftpflichtfrage, die Abwehr unberechtigter Schadensersatzansprüche und die Freistellung des Versicherungsnehmers von berechtigten Schadensersatzverpflichtungen.“

Neben der Eintrittspflicht für die finanziellen Folgen besteht somit eine wesentliche Funktion der Haftpflichtversicherung in der Rechtsverteidigung, d.h. der Prüfung, ob die geltend gemachten Schadenersatzansprüche dem Grunde und der Höhe nach berechtigt sind sowie die Übernahme der für die Rechtsverteidigung erforderlichen Kosten. 34 Aus der Rechtsschutzfunktion folgt, dass der Deckungsanspruch des Versicherungsnehmers bereits dann entsteht, wenn der tatsächlich oder vermeintlich geschädigte Dritte ernsthaft einen Haftpflichtanspruch geltend macht, der in den Schutzbereich des Versicherungsvertrags fällt2. Ist dies nicht der Fall, z.B. weil der Dritte Vorsatz des Versicherungsnehmers behauptet (§ 103 VVG), ist der Vortrag des Versicherungsnehmers maßgeblich, soweit letzterer den Vorsatz bestreitet3. 35 Diese Auslegung ist zum einen deshalb geboten, weil der Versicherungsnehmer gemäß Ziff. 25.2 AHB verpflichtet ist, wahrheitsgemäße Angaben zu machen4 und somit die Vermutung der Redlichkeit für ihn streitet5. Zum anderen stünde es im Widerspruch zum Sinn und Zweck des Rechtsschutz1 Vgl. Oldenburg NVersZ 2000, 536 = VersR 2001, 229; OLG Nürnberg NVersZ 2000, 537; OLG Düsseldorf NJW 1966, 738. 2 Vgl. BGH VersR 1979, 1117; OLG Düsseldorf v. 28.10.1980 – 4 U 41/80, VersR 1981, 1072; OLG Hamm VersR 1978, 809; OLG Köln RuS 1996, 432. 3 Vgl. OLG Celle VersR 1978, 25; Prölss/Martin/Lücke, § 100 Rz. 17. 4 Vgl. OLG Köln v. 9.3.1999 – 9 U 82/98, VersR 2000, 352 (354); Prölss/Martin/Lücke, Nr. 25 AHB Rz. 14. 5 Vgl. Prölss/Martin/Lücke, § 100 Rz. 17.

1280

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 38 O

anspruchs, bei widersprüchlichem Vortrag auf die Behauptungen des Dritten abzustellen, weil es damit in dessen Hand läge, dem Versicherungsnehmer seinen Rechtsschutzanspruch zu entziehen. Soweit es keine konkreten Anhaltspunkte dafür gibt, dass der Versicherungsnehmer die Unwahrheit sagt, ist der Versicherer in einer solchen Konstellation grundsätzlich verpflichtet, Deckungsschutz zu erteilen. Er kann die Deckungszusage jedoch unter dem Vorbehalt abgeben, dass der Versicherungsnehmer in dem Haftpflichtprozess nicht wegen Vorsatzes zum Schadenersatz verurteilt wird1. 7. Versicherungssumme a) Wahl der „richtigen“ Versicherungssumme Die Frage nach der richtigen Höhe der Versicherungssumme lässt sich nicht 36 allgemein beantworten. Während in der Sachversicherung ein fester Risikorahmen durch den Wert der versicherten Sache besteht, lässt sich ein möglicher Höchstschaden in der Haftpflichtversicherung nicht bestimmen2. Dies gilt insbesondere hinsichtlich des Produkthaftpflichtrisikos. Mit Ausnahme der Haftung für Personenschäden nach § 1 ProdHaftG (begrenzt nach § 10 auf 85 Mio. Euro) enthalten die in Frage kommenden Haftungsnormen keine Grenzen, an denen sich der Versicherungsnehmer orientieren könnte. Es fehlt somit eine objektive Bezugsgröße für die Ermittlung der „erforderlichen“ Deckungssumme. Die Entscheidung über die Höhe der Deckungssumme kann deshalb nur auf Grund einer sorgfältigen Analyse der vorhandenen Risiken und des Umfangs der finanziellen Mittel erfolgen, die der Versicherungsnehmer zur Deckung dieser Risiken bereitstellen kann und will3. Da Softwarehäuser Produkthaftungsrisiken ausgesetzt sind, sollte die De- 37 ckungssumme – nicht zuletzt auch mit Blick auf die Serienschadenklausel nach Ziff. 6.3 AHB (Rz. 40 ff.) – pauschal für Personen- und Sachschäden keinesfalls unter 5 Mio. Euro, bei direkten oder indirekten Exporten in die USA sollte die Deckungssumme nicht unter 10 Mio. Euro liegen, da Aufwendungen des Versicherers für Anwalts-, Sachverständigen- und Zeugenkosten – abweichend von Ziff. 6.5 AHB – auf die Deckungssumme angerechnet werden (Rz. 70). b) Begrenzung der Leistung aa) Jahreshöchstleistung Die vereinbarten Versicherungssummen bilden gemäß Ziff. 6.1 AHB die 38 Höchstgrenze bei jedem Schadenereignis. Regelmäßig wird eine Jahreshöchstleistung (Maximierung) gemäß Ziff. 6.2 AHB genannt. Üblich ist eine 1 S. hierzu Prölss/Martin/Lücke, § 100 Rz. 16. 2 Vgl. hierzu Kilian/Heussen/Schmidt-Salzer/Otto, Teil 112 Rz. 24. 3 Vgl. Kilian/Heussen/Schmidt-Salzer/Otto, Teil 112 Rz. 25.

Koch

1281

O Rz. 39

Einzelprobleme

Maximierung, die sich auf das Doppelte der Versicherungssumme je Versicherungsjahr beläuft. Jedoch sind nach entsprechender Vereinbarung mit dem Versicherer auch höhere Maximierungen möglich. bb) Selbstbehalte 39 Regelmäßig wird eine Selbstbeteiligung des Versicherungsnehmers vereinbart. Dabei handelt es sich zumeist um eine Kombination zwischen einer sog. Quotenfranchise (z.B. 10 %) und einer Abzugsfranchise (z.B. mind. 500 Euro) mit/ohne Höchstbetrag. Alternativ hierzu kommt die Vereinbarung einer sog. Integralfranchise in Betracht, bei der ein unter dem Selbstbehalt liegender Anspruch überhaupt nicht, eine darüber hinausgehende Ersatzforderung dagegen in voller Höhe übernommen wird. cc) Serienschadenklausel 40 In der Praxis wird der Serienschadenklausel nach Ziff. 6.3 AHB bei der Bemessung der Versicherungssumme oftmals zu wenig Beachtung geschenkt. Nach dieser Klausel gelten „[m]ehrere während der Wirksamkeit der Versicherung eintretende Versicherungsfälle […] als ein Versicherungsfall, der im Zeitpunkt des ersten dieser Versicherungsfälle eingetreten ist, wenn diese – auf derselben Ursache, – auf gleichen Ursachen mit innerem, insbesondere sachlichem und zeitlichem, Zusammenhang oder – auf der Lieferung von Waren mit gleichen Mängeln beruhen.“ (Hervorhebung durch den Verfasser)

Die Serienschadenklausel verklammert mehrere zeitlich zusammenhängende Schäden aus derselben Ursache oder mehrere Schäden aus Lieferungen der gleichen mangelhaften Waren fiktiv zu einem einheitlichen Schadenereignis. Dies hat zur Folge, dass die Deckungssumme (in Höhe der Maximierung) ungeachtet der Zahl der tatsächlich eingetretenen Schäden nur einmal zur Verfügung steht1. Anknüpfend an den Wortlaut der Klausel unterscheidet man zwischen Ursachenklausel und Warenklausel (auch Lieferklausel genannt). (1) Ursachenklausel 41 Die Ursachenklausel stellt auf das Kausalereignis oder den Verstoß ab. Schäden aus derselben Ursache liegen nicht schon dann vor, wenn sie auf einer „gleichen“ oder „gleichartigen“ Ursache beruhen2.

1 Vgl. Büsken, NJW 2003, 1715; Späte, § 3 Rz. 52. 2 Vgl. BGH v. 27.11.2002 – IV ZR 159/01, MDR 2003, 330 = VersR 2003, 187 (188); BGH v. 28.11.1990 – IV ZR 184/89, MDR 1991, 605 = NJW-RR 1991, 412.

1282

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 43 O

Beispiel: Infolge einer fehlerhaften Programmierung der Software für eine Sprinkleranlage (= Kausalereignis) kommt es zu unkontrollierten Wasseraustritten (= Folgeereignisse). Soweit die Wasseraustritte zeitlich zusammenhängen, liegt ein Serienschaden vor mit der Folge, dass der Versicherer für sämtliche aus der fehlerhaften Programmierung resultierenden Schäden und daraus resultierender Folgeschäden maximal einmal die Deckungssumme zu leisten hat.

Ein Serienschaden liegt daneben vor (erweiterte Ursachenklausel), wenn die 42 Versicherungsfälle auf gleichen Ursachen mit innerem, insbesondere sachlichem und zeitlichem, Zusammenhang beruhen. Die Bestimmung des zeitlichen Zusammenhangs führt in der Praxis zu Schwierigkeiten, was insbesondere bei Änderungen des Versicherungsvertrags (z.B. Deckungssumme, Selbstbehalt) Probleme aufwirft1. Der BGH hat einen zeitlichen Zusammenhang angenommen, nachdem es innerhalb von viereinhalb Monaten zu verschiedenen Deckenabstürzen gekommen war2. In der Literatur ist der erforderliche zeitliche Zusammenhang bejaht worden, wenn die Schäden sich an einem sich senkenden Haus und am Nachbarhaus im Abstand von Tagen oder Wochen zeigen3. Hingegen soll es am zeitlichen Zusammenhang bereits fehlen, wenn eine schlecht unterhaltene Mauer zum Teil einstürzt und der Rest erst einige Wochen später zusammenfällt4. Als zeitliche Höchstgrenze für den ersten und den zweiten Schadeneintritt werden sechs Monate genannt. Überwiegend werden jedoch pauschale zeitliche Vorgaben abgelehnt und die besonderen Umstände des Einzelfalls als maßgeblich angesehen5. (2) Warenklausel Die Warenklausel knüpft an das Inverkehrbringen gleicher Waren an. Im 43 Gegensatz zur Ursachenklausel kommt es bei der Warenklausel weder auf die Ursache noch auf den zeitlichen Zusammenhang an6. Gleiche mangelhafte Waren sind nur solche Waren, die „in ihrer Herkunft, ihrer Zusammensetzung, in allen ihren Eigenschaften, in ihrem vorgesehenen Verwendungszweck und in denjenigen Mängeln, die adäquat-ursächlich für die mehreren Schäden sind, völlig oder zumindest nahezu völlig übereinstimmen“7. Folge hiervon ist, dass eine Gleichheit von Waren in der Regel dann gegeben sein wird, wenn sie aus derselben Serie stammen8. Sind hingegen in der Serienfertigung von Serie zu Serie Umrüstungen erfolgt, soll dies zu einem Wegfall der Gleichheit der Waren einer Serie zu denjenigen der vor1 2 3 4 5

Vgl. Büsken, NJW 2003, 1715 (1716). Vgl. BGHZ 43, 88 (94). Vgl. Wussow, § 3 Anm. 15. Vgl. Wussow, § 3 Anm. 15. Vgl. Büsken, NJW 2003, 1715 (1716); Littbarski, AHB, § 3 Rz. 171, jeweils m.w.N. 6 Vgl. Littbarski, AHB, § 3 Rz. 173. 7 Vgl. Büsken, NJW 2003, 1715 (1716); Späte, § 3 Rz. 57. 8 Meyer-Kahlen, VersR 1976, 8 (12); Späte, § 3 Rz. 57.

Koch

1283

O Rz. 44

Einzelprobleme

herigen Serie führen1. Im Übrigen sind letztlich auch hier die Umstände des Einzelfalls maßgeblich. 8. IT-relevante Ausschlüsse vom Versicherungsschutz 44 Nachstehend werden die für den Betrieb eines Softwarehauses relevanten Ausschlüsse näher betrachtet. a) Schäden durch vorsätzliche Handlungen (Ziff. 7.1 AHB) 45 Nach Ziff. 7.1 AHB sind ausgeschlossen vom Versicherungsschutz „Versicherungsansprüche aller Personen, die den Schaden vorsätzlich herbeigeführt haben.“

Mit der Formulierung „aller Personen“ sind nicht nur der Versicherungsnehmer selbst, sondern alle mitversicherten Personen gemeint. Letzteres ergibt sich aus Ziff. 27.1 AHB, wonach alle in dem Versicherungsvertrag bezüglich des Versicherungsnehmers getroffenen Vereinbarungen auch auf mitversicherte Personen Anwendung finden2. Vom Ausschluss betroffen sind jedoch jeweils nur die Versicherungsansprüche derjenigen Personen, die selbst vorsätzlich gehandelt haben3. 46 Während sich der Versicherungsnehmer sein eigenes vorsätzliches Verhalten sowie das seiner gesetzlichen Vertreter (z.B. Geschäftsführer) stets zurechnen lassen muss, haftet er für vorsätzlich herbeigeführte Schäden von Mitarbeitern unterhalb der Geschäftsleitungsebene grundsätzlich nur dann, wenn sie Repräsentanten sind. Als Repräsentant ist anzusehen, wer in dem Geschäftsbereich, zu dem das versicherte Risiko gehört, auf Grund eines Vertretungs- oder ähnlichen Verhältnisses an die Stelle des Versicherungsnehmers getreten und befugt ist, selbständig in einem gewissen, nicht ganz unbedeutenden Umfang für den Versicherungsnehmer zu handeln (Risikoverwaltung)4. Von entscheidender Bedeutung ist dabei, ob der Versicherungsnehmer sich der Verfügungsbefugnis und der Verantwortlichkeit vollständig begeben hat5. Ob dies der Fall ist, beurteilt sich nach den Umständen des Einzelfalls. Bei einfachen Angestellten ist eine Repräsentantenstellung i.d.R. nicht gegeben. 47 Der Vorsatz muss sich nicht nur auf das Schadenereignis an sich beziehen, sondern auch sämtliche Schadenfolgen umfassen6. Dabei reicht bedingter Vorsatz aus. Der Handelnde muss also den als möglich vorgestellten Erfolg 1 2 3 4

Vgl. Späte, § 3 Rz. 57. Vgl. auch Littbarski, AHB, § 4 Rz. 382. Vgl. BGH NJW 1971, 459 f.; Späte, § 4 Rz. 207; Littbarski, AHB, § 4 Rz. 382. Vgl. BGH VersR 2005, 218; BGH v. 21.4.1993 – IV ZR 34/92, BGHZ 122, 250 (252 f.) = MDR 1993, 957. 5 Vgl. BGH v. 26.4.1989 – IVa ZR 242/87, MDR 1989, 801 = NJW 1989, 1861 (1862). 6 Vgl. nur Nachweise bei Prölss/Martin/Lücke, Nr. 7 Rz. 5.

1284

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 51 O

in seinen Willen aufgenommen und für den Fall seines Eintritts gebilligt haben1. b) Kenntnisklausel (Ziff. 7.2 AHB) Ziff. 7.2 AHB erweitert den Vorsatzausschluss auf Versicherungsansprüche 48 aller Personen, „die den Schaden dadurch verursacht haben, dass sie in Kenntnis von deren Mangelhaftigkeit oder Schädlichkeit – Ereignisse in den Verkehr gebracht oder – Arbeiten oder sonstige Leistungen erbracht haben.“ Der Vorsatz muss sich also nicht auf die Schadenzufügung als solche erstrecken2. Insoweit kommt hier eine weitergehende Zurechnung der Kenntnis von Mitarbeitern auch nach den Grundsätzen der Wissensvertretung in Betracht3.

49

Wissensvertreter ist, wer in nicht ganz untergeordneter Stellung vom Ver- 50 sicherungsnehmer zumindest in einem Teilbereich damit betraut ist, an dessen Stelle – oder an Stelle des dazu berufenen Organs – für das Versicherungsverhältnis rechtserhebliche Tatsachen zur Kenntnis zu nehmen4. Im Unterschied zum Repräsentanten kann dem Wissensvertreter durchaus nur ein begrenzter Aufgabenbereich zugeordnet sein. Es bedarf also keiner umfassenden Übertragung der Risikoverwaltung. Andererseits muss der Wissensvertreter schon eine gewisse herausgehobene Stellung haben. Untergeordnete Hilfspersonen zählen nicht dazu, auch wenn sie aus rein tatsächlichen Gründen eher informiert sein mögen. Er bedarf keiner Bevollmächtigung. Die Zurechnung erfolgt vielmehr unabhängig vom Willen des Versicherungsnehmers wegen der betriebsinternen Organisation5. Bezogen auf Softwarehäuser dürften zumindest die Mitarbeiter, die verantwortlich für den Change-Management-Prozess oder die Abnahme sind, zum Kreis der Wissensvertreter zählen. Grundsätzlich muss der Versicherungsnehmer (oder sein Repräsentant/Wissensvertreter) positive Kenntnis von der Mangelhaftigkeit oder Schädlichkeit der Ware, des Erzeugnisses oder der Arbeit haben. Grob fahrlässige Unkenntnis genügt nicht6. Erbrachte Arbeiten i.S.v. Ziff. 7.2 AHB sollen insbesondere solche sein, die zur Mangelhaftigkeit oder Schädlichkeit einer vom Versicherungsnehmer nicht hergestellten oder gelieferten Sache, aber 1 Vgl. BGH v. 17.6.1998 – IV ZR 163/97, VersR 1998, 1011. 2 Späte, § 1 Rz. 213. 3 Nicht gesehen von OLG Karlsruhe v. 20.3.2003 – 12 U 214/02, VersR 2003, 987 f. 4 Vgl. zuletzt BGH VersR 2005, 218; BGH v. 21.6.2000 – IV ZR 157/99, MDR 2000, 1247 = VersR 2000, 1133. 5 Vgl. Prölss/Martin/Prölss, § 28 Rz. 86 ff.; Bruck/Möller/Heiss, § 28 Rz. 113 ff. 6 Vgl. BGH, VersR 1961, 265 (266); BGH, VersR 1953, 316 (317); OLG Karlsruhe, RuS 2003, 282 (283); OLG Stuttgart, RuS 1994, 451 (452) = VersR 1995, 1229.

Koch

1285

51

O Rz. 52

Einzelprobleme

bearbeiteten Sache führen. Unter diesen Ausschluss fallen auch geistige Arbeiten1. c) Haftungserweiterungen (Ziff. 7.3 AHB) 52 Ziff. 7.3 AHB schließt Haftpflichtansprüche vom Versicherungsschutz aus, „soweit sie auf Grund Vertrags oder Zusagen über den Umfang der gesetzlichen Haftpflicht des Versicherungsnehmers hinausgehen.“

Da Haftpflichtansprüche, die nur auf Grund einer die gesetzliche Haftpflicht erweiternden vertraglichen Vereinbarung durchgesetzt werden können, schon nach Ziff. 1.1 AHB nicht vom Versicherungsschutz umfasst sind, kommt Ziff. 7.3 AHB lediglich Klarstellungsfunktion zu. Der Ausschluss betrifft Verschärfungen des gesetzlichen Haftungsmaßstabs, nicht hingegen die Erweiterung oder Ergänzung der im Gesetz für die einzelnen Vertragstypen vorgesehenen Vertragspflichten2. Betroffen sind vor allem Abreden, die eine verschuldensunabhängige Haftung des Versicherungsnehmers begründen (z.B. Garantien, Eigenschaftszusicherungen), die Verlängerung von Verjährungsfristen oder die Abbedingung der kaufmännischen Untersuchungs- und Rügepflichten (§ 377 HGB) zum Gegenstand haben3. d) Tätigkeitsschäden (Ziff. 7.7 AHB) 53 Die Risikosituation von Softwarehäusern ist vor allem dadurch gekennzeichnet, dass regelmäßig während der Entwicklung und Teilimplementation der Software ein Zugriff auf IT-Infrastruktur, IT-Anwendungen und Daten des Kunden erfolgt. Vor diesem Hintergrund kommt dem Tätigkeitsschadenausschluss sehr große Bedeutung zu. Gemäß Ziff. 7.7 AHB besteht kein Versicherungsschutz für „(1) die Schäden durch eine gewerbliche oder berufliche Tätigkeit des Versicherungsnehmers an diesen Sachen (Bearbeitung, Reparatur, Beförderung, Prüfung und dgl.) entstanden sind; bei unbeweglichen Sachen gilt dieser Ausschluss nur insoweit, als diese Sachen oder Teile von ihnen unmittelbar von der Tätigkeit betroffen waren; (2) die Schäden dadurch entstanden sind, dass der Versicherungsnehmer diese Sachen zur Durchführung seiner gewerblichen oder beruflichen Tätigkeiten (als Werkzeug, Hilfsmittel, Materialablagefläche und dgl.) benutzt hat; bei unbeweglichen Sachen gilt dieser Ausschluss nur insoweit, als diese Sachen oder Teile von ihnen unmittelbar von der Benutzung betroffen waren; 1 Vgl. Prölss/Martin/Lücke, Nr. 7 Rz. 17; Späte, § 1 Rz. 213; vgl. ferner OLG Koblenz v. 25.6.1993 – 10 U 1274/92, VersR 1994, 715 (716), das den Begriff „Arbeiten“ für sprachlich zweideutig und deshalb als unklar i.S.d. § 5 AGBG a.F. (= § 305c Abs. 2 BGB) ansieht. 2 Vgl. Prölss/Martin/Voit/Lücke, Nr. 7 Rz. 18; Bruck/Möller/R. Johannsen8, Bd. IV, Anm. G 161. 3 Produkthaftungshdb./Graf von Westphalen, § 50 Rz. 44; Kilian/Heussen/ Schmidt-Salzer/Otto, Teil 112 Rz. 43; LG Kaiserslautern v. 31.1.2005 – 3 O 354/04, NJW-RR 2005, 1114.

1286

Koch

Rz. 56 O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

(3) die Schäden durch eine gewerbliche oder berufliche Tätigkeit des Versicherungsnehmers entstanden sind und sich diese Sachen oder – sofern es sich um unbewegliche Sachen handelt – deren Teile im unmittelbaren Einwirkungsbereich der Tätigkeit befunden haben; dieser Ausschluss gilt nicht, wenn der Versicherungsnehmer beweist, dass er zum Zeitpunkt der Tätigkeit offensichtlich notwendige Schutzvorkehrungen zur Vermeidung von Schäden getroffen hatte.“

Der Zweck des Tätigkeitsschadenausschlusses liegt darin, den Versicherer 54 in einem gewissen Umfang von dem erhöhten Risiko zu befreien, das sich aus der gewerblichen oder beruflichen Tätigkeit des Versicherungsnehmers ergibt und damit gleichzeitig zu verhindern, dass der Versicherungsnehmer bei dieser Tätigkeit im Vertrauen auf den bestehenden Versicherungsschutz geringere Sorgfalt walten lässt1. Nach dem Zusatz zu Ziff. 7.7 AHB entfällt der Versicherungsschutz sowohl für den Versicherungsnehmer als auch für die durch den Versicherungsvertrag etwa mitversicherten Personen, wenn die Voraussetzungen von Ziff. 7.7 AHB in der Person von Angestellten, Arbeitern, Bediensteten, Bevollmächtigten oder Beauftragten des Versicherungsnehmers gegeben sind. aa) Tätigkeitsschäden an bearbeiteten Sachen (Ziff. 7.7 [1] AHB) Hinsichtlich dieser Klausel ist zu unterscheiden zwischen Tätigkeiten an beweglichen Sachen sowie an unbeweglichen Sachen. Wird die Tätigkeit an einer beweglichen Sache ausgeübt, ist der Ausschluss nach ganz h.M. nicht auf Schäden an den unmittelbar bearbeiteten Teilen der Sache beschränkt, sondern macht die Gesamtsache zum Ausschlussobjekt2.

55

Beispiel: Per Datenfernübertragung versucht der Versicherungsnehmer (Softwarehaus) bei einem Kunden Viren zu beseitigen, die sich in bestimmten Dateien auf der Festplatte „eingenistet“ haben. Der Versuch misslingt. Anstelle die Viren zu beseitigen, aktiviert der Versicherungsnehmer sie. Sämtliche Daten auf der Festplatte werden zerstört. Ausschlussobjekt sind zumindest sämtliche, auf der Festplatte gespeicherten Daten, denen nach hier vertretener Ansicht Sachqualität zukommt. Die Schadenersatzansprüche des Auftraggebers aus §§ 280 Abs. 1, 241 Abs. 2 BGB und aus § 823 Abs. 1 BGB fallen somit unter die Tätigkeitsklausel. Sie sind nicht gedeckt.

Demgegenüber greift der Risikoausschlusses bei Schäden an unbeweglichen 56 Sachen nur unter der Voraussetzung ein, dass die unbeweglichen Sachen oder Teile von ihnen unmittelbar Auftragsgegenstand gewesen sind3. Diese Variante des Ausschlusses dürfte für die typischen Tätigkeiten von Softwarehäusern ohne Bedeutung sein. 1 OLG Köln v. 10.6.2008 – 9 U 144/07, VersR 2009, 391; vgl. auch Späte, § 4 Rz. 128; Bruck/Möller/R. Johannsen8, Bd. IV, Anm. G 202. 2 Vgl. OLG Köln v. 28.10.1982 – 5 U 10/82, VersR 1984, 26; öOGH VersR 1991, 1043. 3 Vgl. BGH v. 3.5.2000 – IV ZR 172/99, MDR 2000, 1131 = NJW-RR 2000, 1189 f.; OLG Karlsruhe v. 7.10.2004 – 12 U 145/04, VersR 2005, 213.

Koch

1287

O Rz. 57

Einzelprobleme

bb) Schäden an Hilfsmitteln (Ziff. 7.7 [2] AHB) 57 Die in Ziff. 7.7 (2) AHB umschriebenen Sachverhalte betreffen nicht solche Sachen, die Gegenstand der beruflichen Tätigkeit des Versicherungsnehmers waren, sondern andere – bewegliche oder unbewegliche – Sachen, deren er sich im Rahmen der Durchführung von Auftragsarbeiten als Hilfsmittel – z.B. als Speichermedium – bedient hat1. Beispiel: Der Versicherungsnehmer implementiert neue Software. Er speichert den Inhalt der Festplatte auf einer CDR seines Auftraggebers ab. Beim Ablegen der CDR gleitet sie ihm aus den Händen und wird durch den Aufprall so stark beschädigt, dass sie nicht mehr in CDR-Laufwerken lesbar ist. Für die Ansprüche des Auftraggebers aus §§ 280 Abs. 1, 241 Abs. 2 BGB und aus § 823 Abs. 1 BGB besteht kein Versicherungsschutz.

cc) Wirkbereichsschäden (Ziff. 7.7 [3] AHB) 58 Ebenfalls vom Versicherungsschutz ausgeschlossen sind Schäden an fremden Sachen, die sich im zwangsläufigen Einwirkungs- oder Gefahrenbereich der Arbeiten befunden haben. Dem Versicherungsnehmer wird allerdings die Möglichkeit eingeräumt, nachzuweisen, dass ihm der Schaden nicht vorwerfbar ist. Dies ist dann der Fall, wenn er die offensichtlich notwendigen Schutzvorkehrungen ergriffen hat, d.h. diejenigen, die jedermann einleuchten mussten (objektiver Maßstab). Dieser Fallgruppe kommt vor allem bei Tätigkeiten Bedeutung zu, bei denen der zu bearbeitende Teil aus einer zusammengesetzten Sache herausgelöst und getrennt davon bearbeitet wird oder die zusammengesetzte Sache so große Ausmaße hat, dass nach der Verkehrsauffassung die Arbeit an einem Teil davon vernünftigerweise nicht mehr als Tätigkeit an der Sache im Ganzen betrachtet werden kann2. In diesen Fällen haben sich die Teile der Sache, die nicht Gegenstand der Bearbeitung waren, in aller Regel im zwangsläufigen Einwirkungs- oder Gefahrenbereich der Arbeiten befunden. dd) Spätschäden 59 Der Tätigkeitsschadenausschluss erfasst auch Spätschäden. Darunter sind solche Schäden am Ausschlussobjekt zu verstehen, deren Ursache während der Tätigkeit an oder mit der Sache gesetzt worden ist, die aber erst nach Abschluss der Tätigkeit eingetreten sind3. ee) Sachfolgeschäden 60 Gemäß Ziff. 7.7 AHB ergreift der Ausschluss nicht nur Schäden an Sachen, die Gegenstand der Tätigkeit des Versicherungsnehmers waren, deren er sich als Hilfsmittel bedient hat oder die sich im unmittelbaren Einwir1 Vgl. BGH v. 3.5.2000 – IV ZR 172/99, MDR 2000, 1131 = NJW-RR 2000, 1189 f. 2 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1593 f. 3 S. Späte, § 4 Rz. 159; Nickel, VersR 1987, 965 (968).

1288

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 63 O

kungsbereich der Tätigkeit befunden haben, sondern auch „alle sich daraus ergebenden Vermögensschäden“. Mit dem Begriff des Vermögensschadens ist nicht der Vermögensschaden i.S.v. Ziff. 2.1 AHB gemeint, sondern Sachfolgeschaden. ff) Deckungserweiterung In der Regel sind die Versicherer gegen Mehrprämie dazu bereit, Tätigkeits- 61 schäden in der Betriebshaftpflichtversicherung zu einem Sublimit mitzuversichern1. e) Herstellung und Lieferung (Ziff. 7.8 AHB) Gemäß Ziff. 7.8 AHB sind vom Versicherungsschutz ausgeschlossen,

62

„Haftpflichtansprüche wegen Schäden an vom Versicherungsnehmer hergestellten oder gelieferten Sachen, Arbeiten oder sonstigen Leistungen infolge einer in der Herstellung, Lieferung oder Leistung liegenden Ursache und alle sich daraus ergebenden Vermögensschäden. Dies gilt auch dann, wenn die Schadenursache in einem mangelhaften Einzelteil der Sache oder in einer mangelhaften Teilleistung liegt und zur Beschädigung oder Vernichtung der Sache oder Leistung führt. Dieser Ausschluss findet auch dann Anwendung, wenn Dritte im Auftrag oder für Rechnung des Versicherungsnehmers die Herstellung oder Lieferung der Sachen oder die Arbeiten oder sonstigen Leistungen übernommen haben.“

Die sog. Herstellungs- und Lieferungsklausel ergänzt Ziff. 1.2 AHB. Während der Anwendungsbereich der Erfüllungsausschlussklausel auf Schadenersatzansprüche von Vertragspartnern des Versicherungsnehmers beschränkt ist, ergreift Ziff. 7.8 AHB auch Schadenersatzansprüche, die aus der Schlechterfüllung vor allem von Kauf- und Werkverträgen resultieren und von den Abnehmern der Sachen oder Arbeiten in der Lieferkette (z.B. Endverbraucher) geltend gemacht werden2. Zu den von diesem Ausschluss betroffenen Schäden gehört der Wertverlust 63 der hergestellten oder gelieferten Sache sowie der Nutzungsausfall3. Letzterer umfasst nach der Rechtsprechung nicht nur den Gebrauchs- oder Gewinnausfall wegen mangelnder Ersatzfähigkeit, sondern auch die Kosten für andersartige Ersatzmaßnahmen wie etwa in Gestalt eines erhöhten Personal- und Sachaufwands, betrieblicher Neu- und Umdispositionen oder der Anmietung von Ersatzgeräten4. Von Schäden an den vom Versicherungsnehmer hergestellten oder gelieferten Arbeiten oder Sachen zu unterscheiden sind Schäden durch eine solche Sache oder mittelbar aus einer mangel1 Vgl. Späte, § 4 Rz. 159; Nickel, VersR 1987, 965 (968). 2 Zum Verhältnis zwischen § 4 I Ziff. 6 Abs. 3 und § 4 II Ziff. 5 AHB a.F. s. Einzelheiten bei Littbarski, AHB, § 4 Rz. 478 ff. 3 BGHZ 23, 349, 353 f. – Halleneinsturz; OLG Köln v. 10.6.2008 – 9 U 144/07, VersR 2009, 391. 4 Vgl. BGH v. 25.9.1985 – IVa ZR 183/83 – Bohrinselkran, BGHZ 96, 29, 32 f. = MDR 1986, 212; BGHZ 23, 349, 353 f. – Halleneinsturz.

Koch

1289

O Rz. 64

Einzelprobleme

haften Leistung entstandene Schäden an anderen Sachen oder gar Personenschäden. Diese Schäden werden von Ziff. 7.8 AHB nicht erfasst1. f) Auslandsschäden aa) Ziff. 7.9 AHB 64 Gemäß Ziff. 7.9 AHB bezieht sich der Versicherungsschutz nicht auf „Haftpflichtansprüche aus im Ausland vorkommenden Schadenereignissen“. Ziff. 1.1 Abs. 2 AHB definiert den Begriff des Schadenereignisses als „das Ereignis, als dessen Folge die Schädigung des Dritten unmittelbar entstanden ist. Auf den Zeitpunkt der Schadenverursachung, die zum Schadenereignis geführt hat, kommt es nicht an.“ Ein Auslandsschaden liegt somit begrifflich immer dann vor, wenn der schädigende Erfolg im Ausland (z.B. Einsatzort der fehlerhaften Software) eingetreten ist, mag auch die Ursache im Inland (z.B. Ort der Herstellung der fehlerhaften Software) gesetzt worden sein2. Der Begriff „Ausland“ ist staatsrechtlich zu verstehen3. Der Ausschluss von Auslandsschäden wird in der herkömmlichen Betriebshaftpflichtversicherung regelmäßig abbedungen und durch eine differenzierte Regelung ersetzt. bb) Wiedereinschluss von Auslandsschäden (1) Versicherte Risiken 65 Ziff 7.7.1 Muster-Bedingungsstruktur AT schließt die gesetzliche Haftpflicht des Versicherungsnehmers wegen Versicherungsfällen im Ausland ein „a) aus Anlass von Geschäftsreisen oder aus der Teilnahme an Ausstellungen, Kongressen, Messen und Märkten; b) durch Erzeugnisse, die ins Ausland gelangt sind, ohne dass der VN dorthin geliefert hat oder hat liefern lassen; c) durch Erzeugnisse, die der VN ins europäische Ausland geliefert hat, hat liefern lassen oder die dorthin gelangt sind; d) aus Bau-, Montage-, Reparatur- und Wartungsarbeiten (auch Inspektion und Kundendienst) oder sonstigen Leistungen im Inland oder europäischen Ausland.“

66 Lit. b) betrifft u.a. die sog. indirekten Exporte. Für sie besteht weltweit Versicherungsschutz. Lit. c) erfasst die sog. direkten Exporte. Versichert sind nicht nur Schäden innerhalb Europas, sondern auch außerhalb (= weltweit), wenn dem direkten Export ins europäische Ausland ein indirekter (Weiter-)Export ins außereuropäische Ausland oder dem direkten Export ins nichteuropäische Ausland ein indirekter (Weiter-)Export ins europäische Ausland nachfolgt. Lit. d) betrifft die Erbringung von Dienstleistungen. 1 OLG Köln v. 10.6.2008 – 9 U 144/07, VersR 2009, 391. 2 Vgl. Prölss/Martin/Lücke, Nr. 7.9 Rz. 96, m.w.N. 3 Vgl. Prölss/Martin/Lücke, Nr. 7.9 Rz. 96.

1290

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 69 O

Hierzu zählen bezogen auf die typischen Tätigkeiten eines Softwarehauses u.a. Implementierung, Anpassung und Pflege von Software. Unklar ist die Einordnung der Fernübertragung von Software auf Grund ent- 67 sprechender Angebote im Internet zum Herunterladen. Misst man Software mit der hier vertretenen Ansicht Sachqualität zu und sieht sie deshalb als Erzeugnis i.S.v. Ziff. 7.7.1 Muster-Bedingungsstruktur AT an, stellt sich die Frage, ob es sich hierbei um eine Form des direkten oder indirekten Exports handelt, sofern im Ausland befindliche Kunden die Software herunterladen1. Diese Frage ist in erster Linie bei Massen- und somit Standardsoftware von Bedeutung, bei der der Anbieter Adresse und Standort des Kunden nicht kennt. Bei Individualsoftware dürfte sie sich nicht stellen, weil sie nicht im Internet zum Herunterladen angeboten wird. Abweichend von Ziff. 1.1 AHB ist der Versicherungsschutz nicht auf privat- 68 rechtliche Haftpflichtansprüche beschränkt, sondern umfasst auch Ansprüche aus öffentlichem Recht. Versichert sind zudem auch Ansprüche aus nicht kodifiziertem Recht (z.B. common law), selbst wenn derartige Regelungen dem deutschen Recht widersprechen2. An dem Erfordernis der gesetzlichen Haftpflicht i.S.v. Ziff. 7.7.1 Muster-Bedingungsstruktur AT fehlt es erst dann, wenn nach rechtsstaatlichen Gepflogenheiten keine Haftung mehr angenommen werden kann, z.B. weil die Zubilligung eines Schadenersatzanspruchs nach allgemeiner Rechtsanschauung als reiner Willkürakt anzusehen wäre3. Fraglich ist, welches Recht bei Auslandssachverhalten für die Qualifikation 69 eines Geschehens als Personen- oder Sachschaden maßgeblich ist. Wie zuvor festgestellt, müssen diese Begriffe in der Haftpflichtversicherung im Hinblick auf die angestrebte Kongruenz zwischen Haftung und Deckung ausgelegt werden. Bedeutet dies nun, dass er bei der Mitversicherung von Auslandsschäden im Lichte des Erfolgsorthaftungsrechts zu verstehen ist? Dagegen ließe sich im Hinblick auf den Auslandsschadenausschluss anführen, dass der Begriff des Personen-/Sachschadens in Ziff. 1.1 Satz 1 AHB an die Haftung nach deutschem Deliktsrecht anknüpft. Der Wiedereinschluss von Versicherungsfällen im Ausland in der Privat- und Betriebshaftpflichtversicherung geht den AHB jedoch als Spezialregelung vor und ist deshalb grundsätzlich auch primärer Anknüpfungspunkt für die Auslegung. Legt man mit der Rechtsprechung die Verständnismöglichkeiten eines Versicherungsnehmers ohne versicherungsrechtliche Spezialkenntnisse und damit – auch – seine Interessen zugrunde4, erscheint es deshalb nicht fernliegend den versicherungsvertraglichen Begriff des Personen-/Sachschadens bei Ver-

1 2 3 4

S. hierzu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1550 ff. Vgl. Späte, § 4 Rz. 26; Prölss/Martin/Lücke, Betriebshaftpfl. Ziff. 7.7 Rz. 1. Vgl. Späte, § 4 Rz. 27. Vgl. BGH v. 23.6.1993 – IV ZR 135/92, BGHZ 123, 83 (85) = RuS 1993, 351 und ständig, vgl. BGH v. 25.5.2011 – IV ZR 17/10, VersR 2011, 1179.

Koch

1291

O Rz. 70

Einzelprobleme

sicherungsfällen im Ausland im Lichte des dort geltenden Haftungsrechts auszulegen1. (2) USA/Kanada-Risiken 70 Auf Grund der Besonderheiten des Rechtssystems in den USA und Kanada werden gemäß Ziff. 7.7.3 Muster-Bedingungsstruktur AT bei Versicherungsfällen in den USA und Kanada die Aufwendungen des Versicherers für Kosten – abweichend von Ziff. 6.5 AHB – als Leistungen auf die Deckungssumme angerechnet. Zu den Kosten zählen u.a. Anwalts-, Sachverständigen-, Zeugen- und Gerichtskosten. Nach Ansicht des OLG Frankfurt/M. ist diese Klausel nach § 307 Abs. 2 Nr. 1 BGB unwirksam2. Vom Versicherungsschutz ausgeschlossen bleiben Ansprüche auf Entschädigung mit Strafcharakter (z.B. „punitive damages“). Solche Ansprüche setzen regelmäßig ein absichtliches, bösartiges oder zumindest rücksichtloses Verhalten voraus3. Ihre Deckung würde daher ohnehin am Vorsatzausschluss gemäß Ziff. 7.1 AHB scheitern (Rz. 45 ff.). (3) Zusammenfassung Auslandsdeckung 71 Die Auslandsdeckung für Softwarehäuser in der herkömmlichen Betriebshaftpflichtversicherung sei anhand nachstehender Fallkonstellationen verdeutlicht: – Software wird in Deutschland in den Verkehr gebracht/softwarebezogene Tätigkeit in Deutschland, Schadenfall in Deutschland oder Europa: fi Versicherungsschutz besteht; – Software wird in Deutschland in den Verkehr gebracht und vom Erwerber ins nichteuropäische Ausland verbracht/weitergeleitet, Schadenfall außerhalb Europas: fi Versicherungsschutz besteht; – Direkter Export der Software ins europäische Ausland/softwarebezogene Tätigkeit im europäischen Ausland, Schadenfall in Europa: fi Versicherungsschutz besteht; – Direkter Export der Software nach Europa und durch Erwerber ins nichteuropäische Ausland (d.h. indirekter Export ins nichteuropäische Ausland) weitergeleitet/verbracht; Schadenfälle weltweit: fi Versicherungsschutz besteht; – Direkter Export ins nichteuropäische Ausland/softwarebezogene Tätigkeit im nichteuropäischen Ausland, Schadenfall außerhalb Europas: fi Versicherungsschutz besteht nicht; – Direkter Export ins nichteuropäische Ausland und Verbringung/Weiterleitung durch Erwerber ins europäische Ausland, Schadenfall in Europa: fi Versicherungsschutz besteht. 1 R. Koch, Versicherung im IT-Bereich, in: Karlsruher Forum 2010, S. 128 f. 2 OLG Frankfurt/M. v. 9.6.2011 – 7 U 127/09, RuS 2011, 509 (510). 3 Späte, § 4 Rz. 34.

1292

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 75 O

g) Schäden durch Umwelteinwirkung (Ziff. 7.10 lit. b) AHB) aa) Nullstellung der Betriebshaftpflichtversicherung für Umweltrisiken Gemäß Ziff. 7.10 lit. b) AHB sind in der Betriebshaftpflichtversicherung vom Versicherungsschutz ausgeschlossen

72

„Haftpflichtansprüche wegen Schäden durch Umwelteinwirkung [sog. „Nullstellung“ der Betriebshaftpflichtversicherung für Umweltrisiken].“

Dies gilt nicht [=Wiedereinschluss] „(1) im Rahmen der Versicherung privater Haftpflichtrisiken oder (2) für Schäden, die durch vom Versicherungsnehmer hergestellte oder gelieferte Erzeugnisse (auch Abfälle), durch Arbeiten oder sonstige Leistungen nach Ausführung der Leistung oder nach Abschluss der Arbeiten entstehen (Produkthaftpflicht). Kein Versicherungsschutz [=Ausschluss vom Wiedereinschluss] besteht jedoch für Schäden durch Umwelteinwirkung, die aus der Planung, Herstellung, Lieferung, Montage, Demontage, Instandhaltung oder Wartung von – Anlagen, die bestimmt sind, gewässerschädliche Stoffe herzustellen, zu verarbeiten, zu lagern, abzulagern, zu befördern oder wegzuleiten (WHG-Anlagen); – Anlagen gem. Anhang 1 oder 2 zum Umwelthaftungsgesetz (UmweltHG-Anlagen); – Anlagen, die nach dem Umweltschutz dienenden Bestimmungen einer Genehmigungs- oder Anzeigepflicht unterliegen; – Abwasseranlagen oder Teilen resultieren, die ersichtlich für solche [= umweltgefährdenden] Anlagen bestimmt sind.“ (Hervorhebung und Zusätze in eckigen Klammern durch den Verfasser)

Die Nullstellung der Umweltrisiken ist insbesondere von Bedeutung für Softwarehäuser, die Software für umweltgefährdende Anlagen herstellen, implementieren und/oder pflegen. Softwarepflege und -implementierung dürften sich auch bei der nach § 305c Abs. 2 BGB gebotenen engen Auslegung von Ausschlüssen nämlich noch unter den Begrifflichkeiten Instandhaltung/Montage/Demontage subsumieren lassen.

73

bb) Anwendungsbereich Hinsichtlich des Anwendungsbereichs von Ziff. 7.10 lit. b) AHB gilt es zu differenzieren, zwischen Umwelteinwirkungen, die aus dem allgemeinen, nichtproduktbezogenen Umwelt-Betriebsrisiko resultieren und produktbezogenen Umweltrisiken.

74

(1) Allgemeines Umwelt-Betriebsrisiko Der Ausschluss nach Ziff. 7.10 lit. b) (1) AHB erstreckt sich nicht nur auf die 75 Haftung nach § 1 UmweltHG für Schäden, die von umweltgefährdenden Anlagen und damit zusammenhängenden Risiken ausgehen. Der Ausschluss umfasst auch die Haftung von Unternehmen, die keine solche Anlagen betreiben und von Dritten wegen Sachschäden, die aus Umwelteinwirkungen Koch

1293

O Rz. 76

Einzelprobleme

im Rahmen des allgemeinen Betriebs resultieren, nach § 823 Abs. 1 BGB in Anspruch genommen werden (auch Nicht-Anlagen-Risiko genannt)1. Mit dem Begriff der Umwelteinwirkung wird spiegelbildlich an § 3 Abs. 1 UmweltHG angeknüpft. § 3 Abs. 1 UmweltHG definiert Schäden durch Umwelteinwirkung als Schaden, der „durch Stoffe, Erschütterungen, Geräusche, Druck, Strahlen, Dämpfe, Wärme oder sonstige Erscheinungen verursacht wird, die sich in Boden, Luft oder Wasser ausgebreitet haben“2. Grundsätzlich ist somit jedes Unternehmen unabhängig von dem Unternehmensgegenstand von dem Ausschluss betroffen. (2) Umwelt-Produktrisiko 76 Während für Schäden durch Umwelteinwirkungen im Rahmen des allgemeinen Betriebs somit keine Deckung besteht, erfahren Produkthaftpflichtrisiken eine Sonderregelung. Soweit der Versicherungsnehmer umweltgefährdende Anlagen oder Teile plant, herstellt, liefert, (de-)montiert, instand hält oder wartet, die ersichtlich für solche Anlagen bestimmt sind, greift der Ausschluss gemäß Ziff. 7.10 lit. b) (2) AHB ein (sog. Anlagen-Regressrisiko oder qualifiziertes Produkthaftpflichtrisiko). In allen anderen Fällen kommt er nicht zum Tragen (sog. einfaches Produkthaftpflichtrisiko)3. Beispiel: Auf Grund fehlerhafter Programmierung eines Thermostats durch den Versicherungsnehmer kommt es beim Betrieb des Ofens einer Bäckerei (= umweltgefährdende Anlage) zu einem hitzebedingten Überdruck, der zu einer Explosion des Ofens führt. Durch die Druckwelle (= Umwelteinwirkung) wird die Betriebseinrichtung beschädigt. Es besteht Versicherungsschutz für die Schadenersatzansprüche des Inhabers der Bäckerei.

77 Bezogen auf den Ausschluss von Teilen für umweltgefährdende Anlagen gilt es das einschränkende Merkmal der Ersichtlichkeit zu beachten. Dieses Merkmal dient der Abgrenzung zum nicht-anlagespezifischen Umwelt-Produktrisiko. Es ist nicht klar, ob es rein objektiv zu verstehen ist oder (auch) auf die Vorstellungen des Versicherungsnehmers ankommt. Geht es um die Erstellung von Software speziell für bereits vorhandene umweltgefährdende Anlagen und/oder um die Implementierung oder Pflege von Software in solchen Anlagen, ist Ersichtlichkeit stets zu bejahen. In allen anderen Fällen kommt es darauf an, ob der Versicherungsnehmer positive Kenntnis über den Verwendungszweck hat oder auf Grund konkreter Anhaltspunkte da1 Vgl. Schimikowski, Rz. 340; Hoeren/Schulze-Schwienhorst, in: Graf von Westphalen (Hrsg.), Haftpflichtversicherungsbedingungen, Rz. 73. 2 Unter „Stoffe“ sind körperliche Gegenstände (z.B. Staub) zu verstehen; „sonstigen Erscheinungen“ fehlt die Körperlichkeit, sie müssen mit den Merkmalen Druck, Gase, Geräusche, Dämpfe, Wärme, Strahlen vergleichbar sein (z.B. Magnetismus); vgl. Deutsch, JZ 1991, 1097 (1100). 3 Hoeren/Schulze-Schwienhorst, in: Graf von Westphalen (Hrsg.), Haftpflichtversicherungsbedingungen, Rz. 75.

1294

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 81 O

mit rechnen musste, dass die von ihm hergestellten Teile in einer umweltgefährdenden Anlage Verwendung finden. Bei nur abstrakter Möglichkeit einer solchen Verwendung besteht Versicherungsschutz über die Betriebshaftpflichtversicherung1. Softwarehäuser, die Software speziell für umweltgefährdende Anlagen er- 78 stellen, implementieren und/oder pflegen, können ihr Produkthaftpflichtrisiko durch Vereinbarung der Umwelthaftpflicht-Basisversicherung, die als Annex-Deckung zur Betriebshaftpflichtversicherung vorgesehen ist, oder durch Abschluss einer Umwelthaftpflichtversicherung nach Maßgabe des Umwelthaftpflicht-Modells versichern2. h) Strahlenklausel (Ziff. 7.12 AHB) Vom Versicherungsschutz ausgeschlossen sind gemäß Ziff. 7.12 AHB Haft- 79 pflichtansprüche wegen Schäden, „die in unmittelbarem oder mittelbarem Zusammenhang stehen mit energiereichen ionisierenden Strahlen (z.B. Strahlen von radioaktiven Stoffen oder Röntgenstrahlen).“ Beispiel: Infolge eines Softwarefehlers wird der zu behandelnde Patient durch ein medizinisches Gerät verstrahlt. Für die Schadenersatzansprüche des Patienten gegen den Hersteller der Software nach § 823 Abs. 1 BGB besteht kein Versicherungsschutz.

i) Nullstellung von IT-Risiken (Ziff. 7.15 AHB) Ziff. 7.15 AHB schließt Haftpflichtansprüche aus

80

„wegen Schäden aus dem Austausch, der Übermittlung und der Bereitstellung elektronischer Daten, soweit es sich handelt um Schäden aus (1) Löschung, Unterdrückung, Unbrauchbarmachung oder Veränderung von Daten, (2) Nichterfassen oder fehlerhaftem Speichern von Daten, (3) Störung des Zugangs zum elektronischen Datenaustausch, (4) Übermittlung vertraulicher Daten oder Informationen.“

aa) Löschung, Unterdrückung, Unbrauchbarmachung oder Veränderung von Daten Die in Ziff. 7.15 (1) AHB verwendeten Begrifflichkeiten beschreiben prak- 81 tisch jede erdenkbare Beeinträchtigung der Integrität und Verfügbarkeit von Daten und Programmen. Damit sind umfassend sämtliche Datenschäden ausgeschlossen, ohne dass es auf die rechtliche Qualifikation derselben als Sach- oder Vermögensschaden ankommt3. Darüber hinaus besteht kein Ver1 Vgl. Dengler, HaftpflichtV, S. 259. 2 S. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1622, 1983 ff. 3 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1645 ff.; R. Koch, RuS 2005, 181 (182); Stockmeier, S. 23.

Koch

1295

O Rz. 82

Einzelprobleme

sicherungsschutz für alle sich daraus ergebenden Folgeschäden an sonstigen Sachen sowie an Personen. Zu beachten ist, dass Ziff. 7.15 (1) AHB von seinem Wortlaut her weder auf Schäden infolge der Nutzung des Internets noch auf Schäden durch Computerviren oder sonstige Schadprogramme beschränkt ist. Von dem Ausschluss betroffen ist somit auch die Beeinträchtigung der Integrität von Daten beim Empfänger infolge fehlerhafter Software, die online per E-Mail oder mittels eines Datenträgers angeboten oder übertragen wird1. Beispiel: Die von einem Softwarehaus adaptierte Software ermöglicht Kunden den Internetzugang. Sie nimmt Veränderungen von Betriebssystemdaten, insbesondere der Netzwerk- und DFÜ-Verbindungseinstellungen auf den Kundenrechnern vor. Unabhängig davon, ob die Software online per Datenfernübertragung oder per Datenträger aufgespielt wird, besteht kein Versicherungsschutz, wenn gespeicherte Daten des Kunden durch die Software in ihrer Integrität nachteilig beeinträchtigt werden.

82 Im Ergebnis bewirkt der Ausschluss gemäß Ziff. 7.15 (1) AHB somit nicht nur eine Nullstellung des Versicherungsschutzes für Fremdschadenrisiken, die aus der Nutzung des Internets oder E-Mail-Dienstes resultieren, sondern stellt IT-Risiken insgesamt praktisch auf Null2. Er führt somit zu einer nicht unerheblichen Einschränkung des Versicherungsschutzes in der Betriebshaftpflichtversicherung für die Anbieter von Software oder softwarebezogenen Leistungen. bb) Nichterfassen oder fehlerhaftes Speichern von Daten 83 Die Nichterfassung von Daten oder das fehlerhafte Speichern von Daten vermag im Zusammenhang mit dem Austausch, der Übermittlung und der Bereitstellung elektronischer Daten unmittelbar weder einen Sachschaden noch einen Personenschaden zu begründen. Denkbar sind jedoch mittelbare Sachschäden oder Personenschäden, so z.B. wenn per E-Mail erfolgte Anweisungen zur Bedienung von Maschinen oder zur Einnahme von Medikamenten fehlerhaft gespeichert werden. In dieser Alternative kommt dem Ausschluss gemäß Ziff. 7.15 (2) AHB konstitutive Wirkung zu3. cc) Störung des Zugangs zum elektronischen Datenaustausch 84 Die Störung des Zugangs zum elektronischen Datenaustausch stellt keinen Sachschaden i.S.v. § 1 Ziff. 1 AHB bei einem Dritten dar, da dieser eine Ein-

1 Vgl. Anlage 2 zum GDV-Rundschreiben H 26/04 M v. 17.6.2004, S. 2. 2 S. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1652; R. Koch, RuS 2005, 181 (182 f.). 3 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1655; R. Koch, RuS 2005, 181 (183); Stockmeier, S. 27.

1296

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 86 O

wirkung auf eine Sache zur Voraussetzung hat1. Die Bedeutung dieses Ausschlusses ergibt sich bei Lichte betrachtet erst aus der durch Ziff. 1.1 AHB geschaffenen Kongruenz zwischen dem deckungsrechtlichen Begriff des Sachschadens und der haftungsrechtlich relevanten Eigentumsverletzung (Rz. 16). Da somit für die Annahme eines Sachschadens die Beeinträchtigung in dem bestimmungsgemäßen Gebrauch der Sache ausreicht, bestünde ohne den Ausschluss nach Ziff. 7.15 (3) AHB Deckung für Schadenersatzansprüche wegen Störung des Zugangs zum elektronischen Datenaustausch2. Nach den Erläuterungen des GDV zu Ziff. 7.15 (3) AHB sollen durch diesen Ausschluss nur Internet-typische Schäden ausgeklammert werden, nicht hingegen Schäden durch Fehlfunktionen oder Ausfälle der vom Versicherungsnehmer gelieferten Hardware mit der Folge eines gestörten Internetzugangs3. dd) Übermittlung vertraulicher Daten oder Informationen Fremdschäden, die aus dem Verlust der Vertraulichkeit von Daten und Informationen resultieren, können Anlass zu Ansprüchen wegen Verletzung des allgemeinen Persönlichkeitsrechts und des Eingriffs in den Gewerbebetrieb geben. Für diese Ansprüche besteht keine Deckung in der Betriebshaftpflichtversicherung, auch nicht im Rahmen der standardmäßigen Mitversicherung von Vermögensschäden. Deshalb kommt dem Ausschluss nach Ziff. 7.15 (4) AHB im Wesentlichen deklaratorische Bedeutung zu4.

85

ee) BHV-IT/Privathaftpflichtversicherung Als Ausgleich zur Nullstellung gemäß Ziff. 7.15 AHB hat der GDV als sepa- 86 rates Deckungskonzept die Zusatzbedingungen zur Betriebshaftpflichtversicherung für die Nutzer von Internet-Technologie (BHV-IT) entwickelt. Deckungsschutz nach Maßgabe der BHV-IT ist jedoch für Softwarehäuser nicht erhältlich, da gemäß Ziff. 6 BHV-IT u.a. kein Versicherungsschutz für Risiken besteht aus Software-Erstellung, -Handel, -Implementierung, -Pflege5. In der Privathaftpflichtversicherung (vgl. Muster-Bedingungsstruktur IX Ziff. 4.1) werden Schäden aus dem Austausch, der Übermittlung und der Bereitstellung elektronischer Daten, z.B. im Internet, per E-Mail oder mittels Datenträger dagegen standardmäßig wieder eingeschlossen, „soweit es sich handelt um

1 Vgl. BGH VersR 1979, 853 (854 f.); OLG Hamm VersR 1978, 28; OLG Hamm v. 11.11.1992 – 20 U 133/92, VersR 1993, 823; Späte, § 1 Rz. 55 ff.; Prölss/Martin/ Voit/Knappmann, § 1 AHB Rz. 12; Littbarski, AHB, 2001, § 1 Rz. 18. 2 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1657. 3 Vgl. Anlage 2 zum GDV-Rundschreiben H 26/04 M v. 17.6.2004, S. 2. 4 R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1659. 5 R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2431 f.; R. Koch, RuS 2005, 181 (184).

Koch

1297

O Rz. 87

Einzelprobleme

(1) Löschung, Unterdrückung, Unbrauchbarmachung oder Veränderung von Daten (Datenveränderung) bei Dritten durch Computer-Viren und/oder andere Schadprogramme; (2) Datenveränderung aus sonstigen Gründen sowie der Nichterfassung und fehlerhaften Speicherung von Daten bei Dritten und zwar wegen – sich daraus ergebender Personen- und Sachschäden, nicht jedoch weiterer Datenveränderungen sowie – der Kosten zur Wiederherstellung der veränderten Daten bzw. Erfassung/korrekter Speicherung nicht oder fehlerhaft erfasster Daten; (3) Störung des Zugangs Dritter zum elektronischen Datenaustausch“.

9. Bewertung des Versicherungsschutzes für Softwarehäuser 87 Die herkömmliche Betriebshaftpflichtversicherung bietet Softwarehäusern nur bei Personen- und Sachschäden durch fehlerhafte Daten und Programme (IT-Risiken i.w.S.) ausreichenden Schutz. Bei Sachschäden ist freilich die Einschränkung geboten, dass bei Schäden an Daten und Programmen (IT-Risiken i.e.S.) Deckungsstreitigkeiten vorprogrammiert sind. Diese resultieren daraus, dass die höchstrichterliche Rechtsprechung die Sachqualität von Daten noch nicht eindeutig festgestellt hat. Diese Unsicherheit betrifft vor allem den hier interessierenden Bereich der IT-Dienstleistungen. Im Rahmen der Anpassung und Pflege von Software, Implementierung von Programmroutinen oder Wartung von Hardware drohen nämlich vornehmlich Schäden an Daten und Programmen. Selbst wenn man mit der hier vertretenen Ansicht deren Sachqualität bei Verkörperung auf einem Datenträger bejaht, wird die Deckung oftmals am Tätigkeitsschadenausschluss gemäß Ziff. 7.7 AHB scheitern (Rz. 53 ff.). Deckungseinschränkungen ergeben sich zudem aus der Erweiterung des Anwendungsbereichs von Ziff. 7.8 (Rz. 62 ff.). Fremdschadenrisiken, die dem Bereich des Vermögensschadens zuzuordnen sind, bleiben auf Grund der Ausschlüsse selbst bei Mitversicherung von Vermögensschäden (Rz. 11 f.) weitestgehend unversichert (z.B. fehlerhafte Rechnungserstellung auf Grund eines Fehlers der Abrechnungssoftware).

III. Versicherungsschutz nach Maßgabe der Produkthaftpflichtversicherung 1. Rechtsgrundlagen 88 Die Produkthaftpflichtversicherung baut auf den AHB und den Besonderen Bedingungen und Risikobeschreibungen für die Produkthaftpflichtversicherung von Industrie- und Handelsbetrieben (ProdHM) auf. Das ProdHM ist dabei nicht als selbständiger Vertrag, sondern als Teil der Betriebshaftpflichtversicherung konzipiert. Die in der Praxis für Industrie, Handel und Gewerbe angebotenen Policen weisen bei Abschluss der Produkthaftpflicht-

1298

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 90 O

versicherung mindestens eine Drei-, bei Indeckungnahme des Rückrufkosten- und Umwelthaftpflichtrisikos eine Vier- oder Fünfteilung auf: – Der Allgemeine Teil (I) enthält alle Vertragsbestimmungen, die auch für die folgenden Vertragsteile gelten, wie z.B. Betriebsbeschreibung, mitversicherte Personen und nicht versicherte Risiken. – Teil II regelt das allgemeine Betriebsrisiko (auch Betriebsstättenrisiko genannt), die Risiken aus Haus- und Grundbesitz, Arbeitsunfällen, Verkehrs(sicherungs)pflichten. – Teil III erfasst das Produkthaftpflichtrisiko, und zwar nach Maßgabe des ProdHM. – Die Teile IV und V regeln die Risiken aus dem Rückruf von Produkten und aus Schäden infolge von Umwelteinwirkungen. Der nachstehenden Betrachtung liegt die vom GDV veröffentliche Fassung des ProdHM aus dem August 2008 zugrunde. 2. Adressatenkreis des ProdHM Das ProdHM ist in erster Linie auf die Bedürfnisse von Herstellern und 89 Händlern ausgerichtet, deren Erzeugnisse nicht Endprodukte sind, sondern einer weiteren gewerblichen/industriellen Tätigkeit unterliegen1. Versicherungsschutz besteht für die sog. Kostenschäden, die dem Abnehmer des fehlerhaften Produkts (= Gesamtprodukthersteller) dadurch entstehen, dass er im Rahmen des Fertigungsprozesses Aufwendungen tätigt, die infolge der Fehlerhaftigkeit fehlschlagen. Als Adressaten kommen somit vornehmlich Hersteller von Zwischenprodukten in Betracht. 3. Versichertes Risiko a) Betriebsbeschreibung und Vorsorgeversicherung Ebenso wie in der Betriebshaftpflichtversicherung besteht Deckung bei Ver- 90 sicherung der erweiterten Produktrisiken nur für die im Versicherungsvertrag und seinen Nachträgen beschriebene betriebliche Tätigkeit des Unternehmens. Abweichend von Ziff. 4.1 (1) AHB ist in Ziff. 10.1 ProdHM bestimmt, dass der Versicherungsnehmer neue Risiken unverzüglich anzuzeigen hat. Kommt der Versicherungsnehmer dieser Anzeigepflicht nicht nach, sieht Ziff. 10.2 ProdHM als Sanktion indessen nicht Leistungsfreiheit, sondern nur eine Erhöhung der vereinbarten Selbstbehalte in Schadenfällen vor, die mit solchen Erhöhungen oder Erweiterungen oder mit neu entstandenen Risiken in Zusammenhang stehen.

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 1.

Koch

1299

O Rz. 91

Einzelprobleme

b) Abgrenzung zur Versicherung des Betriebs(stätten)risikos (Ziff. 1.1) 91 Gemäß Ziff. 1.1 ProdHM erstreckt sich der Versicherungsschutz auf „die gesetzliche Haftpflicht des Versicherungsnehmers für Personen-, Sach- und daraus entstandene weitere Schäden, soweit diese durch vom Versicherungsnehmer – hergestellte oder gelieferte Erzeugnisse, – erbrachte Arbeiten oder sonstige Leistungen verursacht wurden. Dieser Versicherungsschutz beginnt mit dem Zeitpunkt, in dem der Versicherungsnehmer die Erzeugnisse in den Verkehr gebracht, die Arbeiten abgeschlossen oder die Leistungen ausgeführt hat.“ Beispiel1: Von einem Softwarehaus adaptierte Software nimmt Veränderungen der Systemdateien vor. Dies hat die Instabilität des Rechnerbetriebs zur Folge. Eine vollständige Entfernung der Software ist nicht möglich. Es ist deshalb eine Neuinstallation des Betriebssystems erforderlich.

92 Die Beeinträchtigung der Funktionsfähigkeit des Betriebssystems stellt haftungsrechtlich eine Eigentumsverletzung dar, die den Kunden aus Vertrag (§§ 634 Nr. 4, 280 Abs. 1 BGB) und Delikt (§ 823 Abs. 1 BGB) zum Schadenersatz (Ersatz der Aufwendungen für die Neuinstallation) berechtigt. Deckungsrechtlich handelt es sich um einen Sachschaden i.S.v. Ziff. 1.1 AHB, weshalb Versicherungsschutz gemäß Ziff. 1.1 ProdHM besteht. Das Beispiel macht deutlich, dass der Ausgangspunkt des Konzepts der Produkthaftpflichtversicherung deckungsgleich mit dem der allgemeinen Betriebshaftpflichtversicherung ist. Nur die gesetzliche Haftpflicht des Versicherungsnehmers für Personen- und Sachschäden sowie für Vermögensschädigung, die durch Personenschaden oder Sachschaden entstanden ist (= unechte Vermögensschäden), ist umfassend – i.S.e. Allgefahrenversicherung – gedeckt2. Versicherungsschutz für echte Vermögensschäden besteht demgegenüber nur im Rahmen der Deckungserweiterungen gemäß Ziff. 4.2–4.6 ProdHM. 93 Mit der Beschränkung des Versicherungsschutzes auf Schäden, die durch vom Versicherungsnehmer hergestellte oder gelieferte Erzeugnisse, erbrachte Arbeiten oder sonstige Leistungen verursacht wurden, ist nicht nur eine zeitliche, sondern auch sachliche Zäsur gesetzt, welche die Deckung von Schäden nach Maßgabe der konventionellen Betriebshaftpflichtversicherung gegenüber dem ProdHM abgrenzt3. Für Schäden, die durch vom Versicherungsnehmer hergestellte oder gelieferte Erzeugnisse vor dem Inverkehrbringen des Erzeugnisses oder vor Abschluss der Arbeiten oder Ausführung der Leistung entstanden sind, richtet sich die Deckung nach Maßgabe der Versicherung des Betriebs(stätten)risikos. 1 Vgl. Kochinke/Nebel, VersRAI 2004, 8, 9 zu America Online Inc. v. St. Paul Mercury Insurance Co., 4th Cir 02-2018, abrufbar unter http://laws.lp.findlaw. com/4th/022018p.html. 2 Vgl. Thürmann/Kettler, S. 41. 3 Vgl. Produkthaftungshdb./Graf von Westphalen, § 50 Rz. 2.

1300

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 95 O

Für Schäden, die nach dem Inverkehrbringen des Erzeugnisses oder nach 94 Abschluss der Arbeiten oder Ausführung der Leistung entstanden sind, besteht demgegenüber Versicherungsschutz nur nach Maßgabe des ProdHM. Lediglich die Einschränkungen des Versicherungsschutzes durch die AHBAusschlüsse sind weiterhin anwendbar, soweit sie nicht ausdrücklich abbedungen sind oder im Widerspruch zum ProdHM (§ 305c Abs. 2 BGB) stehen. Umgekehrt gelten Deckungserweiterungen im Rahmen der Versicherung des Betriebs(stätten)risikos (z.B. Abbedingung von Ausschlüssen) nicht für das Produkt-/Leistungsrisiko. Hierzu bedarf es einer besonderen Vereinbarung. Dies führt im Ergebnis zu einer Nullstellung des Produkt-/Leistungsrisikos im Vergleich zur herkömmlichen Betriebshaftpflichtversicherung1. aa) Inverkehrbringen des Erzeugnisses Weder der Begriff des Erzeugnisses noch der des Inverkehrbringens werden 95 im ProdHM näher erläutert2. Mit Blick auf die Deckungserweiterungen gemäß Ziff. 4 ProdHM ist der Begriff des Erzeugnisses gleichbedeutend mit dem der beweglichen Sache i.S.v. § 90 BGB3. Somit fallen nach hier vertretener Auffassung auch Daten und Programme, soweit sie auf einem Datenträger gespeichert sind, unter den Begriff des Erzeugnisses4. Unter dem Begriff des Inverkehrbringens wird man in Anlehnung an § 1 Abs. 2 Nr. 1 ProdHaftG das willentliche Begeben der tatsächlichen Herrschaftsgewalt über das Produkt zu verstehen haben. Dies geschieht dadurch, dass der Hersteller das (End- oder Teil-)Produkt ausliefert, in den Vertrieb, in die Verteilerkette oder in den Wirtschaftskreislauf gibt. Nicht in den Verkehr gebracht hat der Hersteller ein Produkt, das ohne seinen Willen seiner Verfügungsmacht entzogen wurde5. Beispiel6: Der Versicherungsnehmer übernimmt für seinen Auftraggeber die Erstellung einer Individualsoftware, mittels derer ein Hochregallager gesteuert werden soll. Die Testphase ist bereits abgeschlossen. Trotzdem kommt es im laufenden Betrieb zu einer Software-bedingten Fehlsteuerung, infolge derer das Hebewerkzeug den Inhalt eines Regallagerplatzes zu Boden fallen lässt. Hier ist ein Erzeugnis – die Individualsoftware – erstellt und in Verkehr gebracht worden. Der durch die Fehlsteue-

1 Zum Verhältnis ProdHM/BetriebshaftpflichtV s. Nickel, in: Kullmann/Pfister, Kza 6854, S. 3; Produkthaftungshdb./Graf von Westphalen, § 59 Rz. 2. 2 In den GDV-Erl. zu Ziff. 1.1 ProdHM 1987 werden unter dem Begriff des Erzeugnisses „Waren i.w.S.“ verstanden; abgedruckt bei Prölss/Martin/Voit/Knappmann27, ProdHaftPfl Ziff. 1 Rz. 18. 3 Zum Begriff des Erzeugnisses vgl. Thürmann/Kettler, S. 97 ff. 4 Im Ergebnis auch Bartsch, S. 226. 5 Vgl. Palandt/Sprau, § 1 ProdHaftG Rz. 14; MünchKomm/Wagner, § 1 ProdHaftG Rz. 26 ff.; Thürmann/Kettler, S. 66 ff.; Stempfle, in: MAH VersicherungsR, § 15 Rz. 20 ff. 6 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 12.

Koch

1301

O Rz. 96

Einzelprobleme

rung verursachte Sachschaden wird im Rahmen des Produkt- und Leistungsrisikos ersetzt.

96 Vor Abschluss der Testphase, insbesondere bei der Erstellung von Individualsoftware nach Kundenwünschen sind jedoch verschiedene Problemstellungen denkbar. Die Bewertung hinsichtlich des Einsatzpunkts des Produkt- und Leistungsrisikos ist hier nur einzelfallspezifisch möglich. Dabei müssen im Schadenfall die vertragliche Gestaltung des Werk- oder Dienstleistungsvertrags und/oder das Pflichtenheft herangezogen werden1. bb) Abschluss der Arbeiten oder sonstiger Leistungen 97 Im Hinblick auf die klassischen Tätigkeiten eines Softwarehauses dürfte diesem Abgrenzungskriterium in der Praxis vielfach noch größere Bedeutung zukommen als dem Merkmal des Inverkehrbringens. Nach h.M. greift der Versicherungsschutz nach Maßgabe des ProdHM in den Fällen, in denen der Versicherungsnehmer das Erzeugnis nicht nur liefert, sondern auch einbaut oder sonstige Leistungen (z.B. Beratung oder Einweisung) erbringt, erst mit dem Abschluss dieser Tätigkeiten ein. Dieser soll spätestens dann vorliegen, wenn die „Sachherrschaft“ über die durchzuführenden Arbeiten und Leistungen nicht mehr beim Versicherungsnehmer liegt2. 98 Umfassende Softwareerstellungsprojekte unterteilen sich für gewöhnlich in mehrere hierarchisch aufeinander aufbauende Projektschritte, die sukzessive abgearbeitet werden. Hinzu kann noch die Problematik treten, dass einzelne Projektschritte von unterschiedlichen Dienstleistern übernommen werden. Kommt es im Rahmen dieser Schritte zu einem Schaden, stellt sich die Frage, ab welchem Zeitpunkt die Leistung (möglicherweise als Teilleistung) als erbracht anzusehen ist. In den Erläuterungen des GDV zu den BBR IT-Dienstleister findet sich hierzu als Antwort, man könne in der Fertigstellung jeder einzelnen Teillösung davon ausgehen, dass das Produkt- und Leistungsrisiko angesprochen sei3. 99 Vereinbaren wirtschaftlich starke Auftraggeber als Zeitpunkt für die Abnahme der Leistung einen bestimmten Zeitraum nach der Nutzbarkeit (und tatsächlichen Nutzung/Inbetriebnahme), um mögliche Mängel, die durch Tests nicht festgestellt worden sind, noch im Erfüllungszeitraum reklamieren zu können, stellt sich bei Folgeschäden aus fehlerhaften Leistungen die Frage, ob für den Einsatzzeitpunkt der Produkthaftpflichtdeckung der Zeitpunkt der tatsächlichen Nutzung durch den Auftraggeber oder aber die – spätere – förmliche Abnahme entscheidend ist. Entscheidet man sich für

1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 12. 2 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 18; Stempfle, in: MAH VersicherungsR, § 15 Rz. 72; Thürmann/Kettler, S. 67; Produkthaftungshdb./Graf von Westphalen, § 50 Rz. 19. 3 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 12; vgl. Thürmann/Kettler, S. 66 ff.

1302

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 102 O

den Zeitpunkt der förmlichen Abnahme, hätte dies vielfach zur Konsequenz, dass für in der Zwischenzeit eingetretene Produkthaftpflichtfälle keine Deckung bestünde, da diese noch vom nicht versicherten Erfüllungsbereich (Ziff. 1.2 AHB) umfasst wären. In diesem Zusammenhang ist allerdings zu beachten, dass das ProdHM die Abnahme gemäß § 640 BGB nicht als Einsatzzeitpunkt voraussetzt. In der Literatur wird deshalb für die Einstandspflicht des Produkthaftpflichtversicherers auch beim Werkvertrag zu Recht nicht auf die förmliche Abnahme, sondern auf den Verlust der Sachherrschaft durch den Versicherungsnehmer abgestellt1. c) Mitversicherung von Tätigkeitsspätschäden (Ziff. 1.2) Gemäß Ziff. 1.2 ProdHM sind mitversichert

100

„gesetzliche Haftpflichtansprüche wegen Schäden, die an fremden Sachen durch eine gewerbliche oder berufliche Tätigkeit des Versicherungsnehmers an oder mit diesen Sachen entstanden sind und alle sich daraus ergebenden Vermögensschäden. Dieser Versicherungsschutz besteht nur, sofern die Schäden nach Abschluss der Arbeiten oder Ausführung der sonstigen Leistungen eingetreten sind.“

aa) Einschluss von Tätigkeitsspätschäden Diese Regelung bezieht sich auf Tätigkeitsspätschäden, für die in der Be- 101 triebshaftpflichtversicherung gemäß Ziff. 7.6 AHB Deckung nur durch einen entsprechenden Einschluss und i.d.R. sublimitiert Versicherungsschutz erlangt werden kann (Rz. 61)2. Der Einschluss ist für Hersteller und Lieferanten von Software durchaus von Bedeutung, soweit sie die Software selbst installieren oder an die Hardware-/Software-Umgebung beim Besteller anpassen. Erfasst werden auch Schäden, die an fremden Sachen entstanden sind, die der Versicherungsnehmer zur Ausübung seiner Tätigkeit einsetzte („mit diesen Sachen“). Beispiel: Der Versicherungsnehmer installiert Software zur Erweiterung einer bereits vorhandenen Maschinenstraße im Auftraggeberwerk. Infolge eines Fehlers bei der Installation kommt es später zu Sachschäden an der Anlage. Deckung bezüglich der sachbeschädigten Anlage (ohne die Software des Versicherungsnehmers) besteht über Ziff. 1.2 ProdHM.

bb) Deckungsumfang Ausgenommen von dem Einschluss von Tätigkeitsspätschäden bleiben An- 102 sprüche wegen der Beschädigung von Kraft-, Schienen- und Wasserfahrzeugen sowie Containern und deren Ladung. Dies wird in den Erläuterungen des GDV mit dem erheblichen Risikopotenzial z.B. aus der Zulieferung und

1 Vgl. Prölss/Martin/Voit, ProdHaftPfl Ziff. 1 Rz. 18; Schimikowski, RuS 2002, 45 ff.; Thürmann/Kettler, S. 67 f. 2 Vgl. Thürmann, PHI 2000, 163 (166).

Koch

1303

O Rz. 103

Einzelprobleme

dem gleichzeitigen Assembling durch den Versicherungsnehmer bei einem Kfz-Hersteller begründet1. Das Risiko der Beschädigung von Sachen, „die sich beim Versicherungsnehmer zur Lohnbe- oder -verarbeitung, Reparatur oder sonstigen Zwecken befinden oder befunden haben“,

bleibt wegen der besonderen Risikosituation, insbesondere der Abgrenzung zum nicht gedeckten Erfüllungsbereich, ebenfalls vom Versicherungsschutz ausgeschlossen2. Beispiel: Der Versicherungsnehmer installiert im Lohnauftrag die ihm zugelieferte Software. Auf Grund eines Fehlers bei der Installation sind bestimmte Funktionalitäten der Software nicht mehr abrufbar. Es besteht kein Versicherungsschutz für die Schadenersatzansprüche des Auftraggebers.

4. Mitversicherte Personen (Ziff. 2) 103

Weitergehend als der Muster-Bedingungsstruktur AT (Rz. 10) sieht das ProdHM die Mitversicherung des Subunternehmerrisikos in Ziff. 2 ProdHM standardmäßig vor. Nicht versichert bleibt die Haftpflicht der Subunternehmer selbst und deren Betriebsangehörigen. 5. Abgrenzungen und Erweiterungen des Versicherungsschutzes (Ziff. 4 ProdHM)

104

Neben dem in Ziff. 1.1 ProdHM geregelten konventionellen Produkthaftpflichtrisiko erweitert Ziff. 4 den Versicherungsschutz auf bestimmte, abschließend benannte vertragliche Haftungstatbestände und Vermögensschäden. Ziff. 4 ProdHM weist folgende Struktur auf: Ziff. 4.1 Personen- oder Sachschäden aufgrund von Sachmängeln infolge Fehlens von vereinbarten Eigenschaften Ziff. 4.2 Verbindungs-, Vermischungs-, Verarbeitungsschäden Ziff. 4.3 Weiterver- oder -bearbeitungsschäden Ziff. 4.4 Aus- und Einbaukosten Ziff. 4.5 Schäden durch mangelhafte Maschinen (fakultativ) Ziff. 4.6 Prüf- und Sortierkosten (fakultativ).

In der Praxis werden die Bausteine gemäß Ziff. 4.1.–4.4 ProdHM en bloc mitversichert und bei Bedarf durch die Bausteine gemäß Ziff. 4.5 und 4.6 ProdHM ergänzt3.

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 3. 2 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 3. 3 Vgl. Krause, NVersZ 2001, 103, 104; Klinkhammer, VP 2000, 143 (150).

1304

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 106 O

a) Ansprüche wegen Schäden infolge Fehlens vereinbarter Eigenschaften aa) Personen- und Sachschäden sowie Folgeschäden (Ziff. 4.1 ProdHM) In Erweiterung der Deckung in der herkömmlichen Betriebshaftpflichtversicherung sind gemäß Ziff. 4.1 ProdHM versichert

105

„auf Sachmängeln beruhende Schadenersatzansprüche Dritter im gesetzlichen Umfang wegen Personen-, Sach- und daraus entstandener weiterer Schäden, wenn der Versicherungsnehmer aufgrund einer Vereinbarung mit seinem Abnehmer über bestimmte Eigenschaften seiner Erzeugnisse, Arbeiten und Leistungen dafür verschuldensunabhängig einzustehen hat, dass diese bei Gefahrübergang vorhanden sind“. (Hervorhebung durch den Verfasser)

Zu beachten ist, dass nur Schadenersatzansprüche Dritter „im gesetzlichem Umfang“ abgedeckt werden. Frei vereinbarte Rechtsfolgen, wie z.B. pauschalierter Schadenersatz bei einer bestimmten Anzahl fehlerhafter Erzeugnisse, sind ebenso wenig versichert wie Schadenersatzansprüche wegen Verletzung einer Beschaffenheits- und Haltbarkeitsgarantie i.S.v. § 443 BGB. Haltbarkeitsgarantien scheiden auch deshalb aus, weil sich diese Klausel nur auf Vereinbarungen erstreckt, die sich auf das Vorhandensein von Eigenschaften bei Gefahrübergang beziehen1. Beispiel2: Der Versicherungsnehmer sichert seinem Auftraggeber, einer Druckerei, für die er eine individuell angepasste Grafik-Software erstellt, die Kompatibilität zur bereits vorhandenen Software der Druckmaschinen zu. Der Versicherungsnehmer erhält den Auftrag nur, weil er bereit ist, diese Zusicherung mit der Maßgabe abzugeben, dafür verschuldensunabhängig einzustehen, dass bei der Druckerei keine Folgeschäden entstehen. Ein Druckauftrag über vielfarbige Prospekte wird gestartet. Die Software steuert jedoch eine zu große Farbmenge in die Düsen der Druckmaschine, die dadurch verkleben und unbrauchbar werden. Der Schadenersatzanspruch des Kunden gegen den Versicherungsnehmer aus Vertrag (§§ 634 Nr. 4, 280 Abs. 1 BGB) und Delikt (§ 823 Abs. 1 BGB) wegen der Eigentumsverletzung ist hinsichtlich der Kosten für den Austausch der Düsen und die Stillstandzeiten der Druckmaschine während des Austausches auch bei Nichtverschulden gedeckt.

bb) Vermögensschäden (Ziff. 4.2–4.5 ProdHM) Ansprüche wegen Vermögensschäden i.S.d. Ziff. 4.2.1, 4.3.1, 4.4.1, 4.5.1 ProdHM infolge Fehlens vereinbarter Eigenschaften sind im Umfang der Ziff. 4.2.2, 4.3.2, 4.4.2 und 4.5.2 ProdHM ebenfalls gedeckt. Gemeinsames Merkmal dieser Bausteine ist zudem, dass „Mängel bei der Beratung über die An- oder Verwendung der vom Versicherungsnehmer hergestellten oder gelieferten Erzeugnisse sowie Falschlieferungen […] Mängeln in der Herstellung oder Lieferung gleich[stehen]“. (Hervorhebung durch den Verfasser) 1 Vgl. Stempfle, in: MAH VersicherungsR, § 15 Rz. 112; Thürmann, PHI Jubiläumsausgabe 2002, S. 24, 28 ff.; zur Auslegung des Begriffs der Eigenschaft vgl. Graf von Westphalen, PHi 2004, 172 (173 ff.); Zölch, PHi 2005, 15 (20 ff.). 2 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 12.

Koch

1305

106

O Rz. 107

Einzelprobleme

b) Verbindungs-, Vermischungs-, Verarbeitungsschäden (Ziff. 4.2 ProdHM) aa) Voraussetzungen des Bausteins gemäß Ziff. 4.2.1 ProdHM 107

Ziff. 4.2.1 ProdHM verspricht Versicherungsschutz für „gesetzliche Schadenersatzansprüche Dritter wegen der in Ziff. 4.2.2 genannten Vermögensschäden i.S.v. Ziff. 2.1 AHB infolge Mangelhaftigkeit von Gesamtprodukten Dritter, die durch eine aus tatsächlichen oder wirtschaftlichen Gründen nicht trennbare Verbindung, Vermischung oder Verarbeitung von mangelhaft hergestellten oder gelieferten Erzeugnissen mit anderen Produkten entstanden sind. Erzeugnisse im Sinne dieser Regelung können sowohl solche des Versicherungsnehmers als auch Produkte Dritter sein, die Erzeugnisse des Versicherungsnehmers enthalten.“

Dieser Deckungsbaustein regelt den Tatbestand der Herstellung einer neuen mangelhaften Sache, dem Gesamtprodukt, das durch Verbindung, Vermischung oder Verarbeitung der vom Versicherungsnehmer mangelhaft hergestellten oder gelieferten Erzeugnisse mit anderen Produkten entstanden ist. Dies gilt nur bei tatsächlicher Mangelhaftigkeit und nicht bei bloßem Mangelverdacht. Deckungsauslösendes Schadenereignis für Verbindungs-, Vermischungs-, Verarbeitungsschäden ist gemäß Ziff. 8.2.1 ProdHM der Zeitpunkt der Verbindung, Vermischung oder Verarbeitung der Erzeugnisse. (1) Verbindung, Vermischung oder Verarbeitung mangelhafter Erzeugnisse 108

Die Begriffe „Verbindung“, „Vermischung“ und „Verarbeitung“ in Ziff. 4.2.1 ProdHM werden in Ziff. 4.2.2 ProdHM nicht näher erläutert. Nähere Klarheit über die Auslegung bringen auch nicht die anderen Deckungsbausteine. Entsprechend dem allgemeinen Grundsatz, wonach bei der Auslegung von Versicherungsbedingungen Worte, mit denen die Rechtsprache feststehende Begriffe verbindet, idS zu verstehen sind1, sind für die Beurteilung, ob eine Verbindung, Vermischung oder Verarbeitung vorliegt, somit die §§ 946 ff. BGB maßgeblich2.

109

Eine Verbindung liegt danach immer dann vor, wenn die Erzeugnisse des Versicherungsnehmers wesentlicher Bestandteil eines Grundstücks oder Bauwerks (§ 946 BGB) oder neuen einheitlichen beweglichen Sache (§ 947 BGB) werden. Dies beurteilt sich nach §§ 93, 94 BGB. Gemäß § 93 BGB sind Bestandteile einer beweglichen Sache wesentlich, die von einander nicht getrennt werden können, ohne dass der eine oder der andere zerstört oder in seinem Wesen verändert wird. Zu den wesentlichen Bestandteilen eines Grundstücks gehören nach § 94 Abs. 1 BGB die mit Grund und Boden fest 1 Vgl. BGH v. 3.5.2000 – IV ZR 172/99, MDR 2000, 1131 = VersR 2000, 963 (964); BGH v. 17.5.2000 – IV ZR 113/99, MDR 2000, 1248 = VersR 2000, 1090 (1091 f.); BGH v. 8.12.1999 – IV ZR 40/99, MDR 2000, 393 = NJW 2000, 1194 ff.; BGH v. 5.7.1995 – IV ZR 133/94, NJW-RR 1995, 1303 (1304). 2 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 39; Produkthaftungshdb./Graf von Westphalen, § 52 Rz. 12; a.A. Schmidt-Salzer/Hinsch, Rz. 7.591.

1306

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 111 O

verbundenen Sachen, insbesondere Gebäude. Zu den wesentlichen Bestandteilen eines Gebäudes gehören gemäß § 94 Abs. 2 BGB die zur Herstellung eingefügten Sachen. Vermischung i.S.v. § 948 BGB setzt voraus, dass bewegliche Sachen miteinander untrennbar verbunden sind. Der Untrennbarkeit steht es dabei gleich, wenn die Trennung der vermischten Sachen mit unverhältnismäßigen Kosten verbunden sein würde. Verarbeitung i.S.v. § 950 BGB liegt schließlich vor, wenn durch eine bewusste menschliche oder menschlich gesteuerte Arbeitsleistung ein oder mehrere Stoffe verarbeitet oder umgebildet werden und dadurch eine neue bewegliche Sache hergestellt wird1. (2) Anwendbarkeit von Ziff. 4.2.1 ProdHM auf Software (Daten und Programme) Fraglich ist, ob der Deckungsbaustein auf die Verbindung, Vermischung 110 oder Verarbeitung von fehlerhaften mit fehlerfreien Daten und Programmen z.B. im Rahmen einer Programmanpassung anwendbar ist. Wie bereits im Rahmen der Einordnung von Produktionsschäden unter dem Begriff des Sachschadens erörtert, sind Zweifel vor allem deshalb angebracht, weil den fehlerhaften Daten und Programmen im Zeitpunkt der Verbindung, Vermischung oder Verarbeitung keine Sachqualität zukommt und es insofern an dem Vorhandensein zweier Sachen fehlt (Rz. 24). Lässt man diese Problematik außer Betracht, stellt sich weiterhin die Frage, welche der Alternativen – Verbindung, Vermischung oder Verarbeitung – Anwendung findet. Beispiel: Der Versicherungsnehmer liefert auf einer CDR fehlerhafte Enterprise Resource Planning (ERP)-Software, die von einem Softwarehaus auf die spezifischen Bedürfnisse seiner Kunden irreversibel angepasst (z.B. parametrisiert) wird2. Nach drei Monaten Entwicklungsarbeit wird festgestellt, dass die Software auf Grund des Fehlers in der Praxis nicht einsetzbar ist.

Für die Annahme einer Verbindung i.S.v. Ziff. 4.2 ProdHM ist zunächst Vo- 111 raussetzung, dass die fehlerhaften Daten zusammen mit den fehlerfreien Daten eine neue Sacheinheit bilden, fehlerhafte ebenso wie fehlerfreie Daten durch die Verbindung ihre Selbständigkeit verloren haben und nicht mehr voneinander getrennt werden können, ohne dass die einen oder anderen zerstört oder in ihrem Wesen verändert werden. Ob dies im vorstehenden Beispiel der Fall ist, lässt sich nur anhand der technischen Umstände des Einzelfalls beurteilen. Ebenfalls einer generellen Beurteilung entzogen ist die Frage, wann Daten untrennbar „vermischt“ sind oder die Trennung 1 Vgl. Palandt/Bassenge, § 950 BGB Rz. 4 f. 2 Beim Enterprise Resource Planning handelt es sich um ein Verfahren zur bedarfsgerechten Bereitstellung von Daten, welches einem Unternehmen erlaubt, die gesamte Geschäftstätigkeit zu überwachen und zu steuern. Es beruht auf integrierter Anwendungs-Software, die alle Unternehmensaspekte einbezieht, z.B. Herstellung, Buchhaltung, Lagerverwaltung, Personal und Vertrieb. Vgl. Brockhaus, Stichwort „Enterprise Resource Planing“.

Koch

1307

O Rz. 112

Einzelprobleme

mit unverhältnismäßigen Kosten verbunden ist, so dass von einer Vermischung i.S.v. Ziff. 4.2 ProdHM gesprochen werden kann1. Am ehesten dürfte der Vorgang der Anpassung als Verarbeitung i.S.v. Ziff. 4.2 ProdHM zu qualifizieren sein, da die bearbeitete Software gegenüber der Ursprungsversion stets weitergehende Funktionen erfüllt und somit als neue Sache angesehen werden kann2. bb) Versicherte Kosten (Ziff. 4.2.2 ProdHM) 112

Sieht man den Tatbestand von Ziff. 4.2.1 ProdHM als erfüllt an, regelt sich der Umfang der Deckung nach Ziff. 4.2.2 ProdHM. (1) Beschädigung oder Vernichtung anderer Produkte

113

Zunächst sind gemäß Ziff. 4.2.2.1 ProdHM Schadenersatzansprüche gedeckt wegen „der Beschädigung oder Vernichtung der anderen Produkte, soweit hierfür nicht bereits Versicherungsschutz nach Ziff. 1 oder 4.1 besteht“.

Die Beschädigung oder Vernichtung anderer Produkte infolge einer aus tatsächlichen oder wirtschaftlichen Gründen untrennbaren Verbindung, Vermischung oder Verarbeitung mit fehlerhaften Zutaten stellt haftungsrechtlich eine Eigentumsverletzung i.S.v. § 823 Abs. 1 BGB dar und kommt deckungsrechtlich einem Sachschaden i.S.v. Ziff. 1.1 AHB gleich (Rz. 15). Insoweit besteht für die Haftpflichtansprüche des Eigentümers auf Ersatz der Kosten für die fehlerfreien Produkte stets bereits Versicherungsschutz nach Ziff. 1 ProdHM3. Bezogen auf obiges Beispiel ließe sich somit die Deckung für den Sachschaden an der fehlerfreien Software durchaus bejahen, wenn diese im Rahmen der Anpassung (= Verarbeitung) der fehlerhaften ERP-Basissoftware nachteilig verändert worden ist. (2) Herstellungskosten (Ziff. 4.2.2.2 ProdHM) 114

Gemäß §§ 437 Nr. 3, 280 Abs. 1 BGB kann der Hersteller des Gesamtprodukts vom Versicherungsnehmer Ersatz der Herstellungskosten verlangen. Deckungsrechtlich handelt es sich bei diesen Schadenpositionen um echte Vermögensschäden, weshalb für den auf den Ersatz dieser Kosten gerichteten Schadenersatzanspruch kein Versicherungsschutz in der herkömmlichen Betriebshaftpflichtversicherung besteht. Hier hilft der Baustein gemäß Ziff. 4.2.2.2 ProdHM weiter, der Versicherungsschutz auch für Schadenersatzansprüche verspricht wegen „für die Herstellung der Gesamtprodukte aufgewendeter Kosten mit Ausnahme des Entgeltes für die mangelhaften Erzeugnisse des Versicherungsnehmers“. 1 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1727 f. 2 Vgl. BGH NJW 1995, 2633. 3 Vgl. Produkthaftungshdb./Graf von Westphalen, § 52 Rz. 17 ff. (zur Parallelvorschrift der Ziff. 4.2.1 ProdHM 1987); Stempfle, in: MAH VersicherungsR, § 15 Rz. 130; a.A. Klinghammer, VP 2000, 143 (150).

1308

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 116 O

Bezogen auf obiges Beispiel muss der Versicherungsnehmer somit lediglich das von dem Softwarehaus (= Hersteller des Gesamtprodukts) für die fehlerhafte ERP-Basissoftware gezahlte Entgelt als Schadenposition selbst tragen1. (3) Nachbesserungskosten (Ziff. 4.2.2.3 ProdHM) (a) Rechtlich gebotene und wirtschaftlich zumutbare Nachbearbeitung Der Hersteller des Gesamtprodukts kann vom Versicherungsnehmer den 115 Ersatz der Herstellungskosten nicht „um jeden Preis“ verlangen. Gemäß § 254 Abs. 2 Satz 1 BGB ist der Hersteller haftungsrechtlich nämlich zur Schadenminderung verpflichtet. Er darf das entstandene mangelhafte Gesamtprodukt nicht komplett verwerfen, sondern muss sich ggf. auf die technisch mögliche und ihm wirtschaftlich zumutbare billigere Nachbesserung oder Schadenbeseitigung verweisen lassen2. In diesem Fall ist sein Anspruch auf Schadenersatz auf den Ersatz der Nachbesserungs- oder sonstigen Schadenbeseitigungskosten anstelle der ursprünglichen Herstellungskosten für die Gesamtsache beschränkt. Auch bei dieser Schadenposition handelt es sich um einen echten Vermögensschaden, weil die Nachbesserungskosten nicht die Folge des Sachschadens am mangelfreien Ausgangsmaterial sind, sondern der von Anfang an bestehenden Mangelhaftigkeit des Endprodukts3. Spiegelbildlich zu der vorstehend aufgezeigten haftungsrechtlichen Lage be- 116 steht gemäß Ziff. 4.2.2.3 ProdHM Versicherungsschutz nur für Schadenersatzansprüche gegen den Versicherungsnehmer wegen der „Kosten für eine rechtlich gebotene und wirtschaftlich zumutbare Nachbearbeitung der Gesamtprodukte oder für eine andere Schadenbeseitigung (siehe aber Ziff. 6.2.8). Der Versicherer ersetzt diese Kosten in dem Verhältnis nicht, in dem das Entgelt für die Erzeugnisse des Versicherungsnehmers zum Verkaufspreis der Gesamtprodukte (nach Nachbearbeitung oder anderer Schadenbeseitigung) steht.“

Da Ziff. 4.2.2.3 ProdHM an die haftungsrechtliche Situation, insbesondere auch die Schadenminderungspflicht des Geschädigten anknüpft, ist die Versicherungsleistung für Nachbearbeitung oder Schadenbeseitigung begrenzt auf die Kosten der nutzlosen Herstellung, die wirtschaftlich der kompletten Verwerfung der neu hergestellten Sache – hier also die angepasste ERP-Basissoftware – gleichkommt4. Zu beachten ist, dass die Kosten der Nachbesserung oder sonstigen Schadenbeseitigung in dem Verhältnis nicht ersetzt werden, in dem das Entgelt für das gelieferte Erzeugnis zum erwarteten Ver-

1 Vgl. Stempfle, in: MAH VersicherungsR, § 15 Rz. 134. 2 Zur Schadenminderungspflicht vgl. MünchKomm/Oetker, § 254 BGB Rz. 90 f.; Palandt/Grüneberg, § 254 BGB Rz. 32 f.; Erman/Kuckuck, § 254 BGB Rz. 67 f., jeweils m.w.N. 3 Stempfle, in: MAH VersicherungsR, § 15 Rz. 137 ff. 4 Vgl. GDV-Rundschreiben GDV H 35/2002 M v. 30.7.2002, S. 6.

Koch

1309

O Rz. 117

Einzelprobleme

kaufserlös des Gesamtprodukts steht. Damit wird das nicht versicherte Erfüllungsinteresse in Abzug gebracht, denn in der Nachbesserung des Gesamtprodukts liegt auch eine wegen Ziff. 1.2 AHB nicht gedeckte Nachbesserung des Erzeugnisses des Versicherungsnehmers. Der Wertanteil für das zugelieferte mangelhafte Produkt und der Vertragserfüllungsaufwand sind somit aus dem vom Versicherer zu leistenden Entschädigungsbetrag herauszurechnen1. (b) Begriff der anderen Schadenbeseitigung 117

Was unter dem Begriff „andere Schadenbeseitigung“ zu verstehen ist, ist unklar. Nach den Erläuterungen des GDV sollen darunter – in Abgrenzung zur Nachbearbeitung, die auf die Mängelbeseitigung am Gesamtprodukt abzielt – solche Maßnahmen fallen, die zwar nicht die Mängel als solche beheben, aber deren negative Auswirkungen reduzieren oder aufheben2. (c) Ausschluss für Rückrufkosten

118

Der Hinweis auf Ziff. 6.2.8 ProdHM ist vor dem Hintergrund des Sonderdeckungskonzepts der Rückrufkostenversicherung zu sehen. Soweit die Kosten der Nachbearbeitung des Gesamtprodukts oder einer anderen Schadenbeseitigung im Zusammenhang mit einem Rückruf von Erzeugnissen geltend gemacht werden, werden sie nicht ersetzt. Rückruf ist in Ziff. 6.2.8 Satz 3 ProdHM definiert als „die auf gesetzlicher Verpflichtung beruhende Aufforderung des Versicherungsnehmers, zuständiger Behörden oder sonstiger Dritter an Endverbraucher, Endverbraucher beliefernde Händler, Vertrags- oder sonstige Werkstätten, die Erzeugnisse von autorisierter Stelle auf die angegebenen Mängel prüfen, die ggf. festgestellten Mängel beheben oder andere namentlich benannten Maßnahmen durchführen zu lassen“.

Die gesetzliche Verpflichtung zum Rückruf kann zum einen auf der Verkehrspflicht des Versicherungsnehmers oder eines im Rahmen der Warenherstellung beteiligten Dritten3 beruhen, zum anderen auf einer behördlichen Anordnung des Rückrufs nach den Vorgaben des Produktsicherheitsgesetzes (§ 26 Abs. 4 ProdSG). Versicherungsschutz ist in einem solchen Fall nur über eine gesondert zu vereinbarende Rückrufkostenversicherung erhältlich4.

1 Zur Berechnung s. Nickel, in: Kullmann/Pfister, Kza 6860, S. 25. 2 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 6; Stempfle, in: MAH VersicherungsR, § 15 Rz. 140. 3 S. hierzu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 640 ff. 4 S. hierzu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1879 ff.

1310

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 122 O

(4) Weitere Vermögensnachteile (Ziff. 4.2.2.4 ProdHM) Gemäß Ziff. 4.2.2.4 ProdHM sind ferner versichert Schadenersatzansprüche wegen

119

„weiterer Vermögensnachteile (z.B. entgangenen Gewinnes), weil die Gesamtprodukte nicht oder nur mit einem Preisnachlass veräußert werden können (siehe aber Ziff. 6.2.8). Der Versicherer ersetzt diese Vermögensnachteile in dem Verhältnis nicht, in dem das Entgelt für die Erzeugnisse des Versicherungsnehmers zu dem Verkaufspreis steht, der bei mangelfreier Herstellung oder Lieferung der Erzeugnisse des Versicherungsnehmers für die Gesamtprodukte zu erzielen gewesen wäre“.

(a) Begriff des weiteren Vermögensnachteils Der Begriff des weiteren Vermögensnachteils ist im ProdHM nicht erläu- 120 tert. Es findet sich lediglich in dem Klammerzusatz der beispielhafte Hinweis auf den entgangenen Gewinn. In der einschlägigen Literatur werden als weitere Vermögensnachteile i.S.v. Ziff. 4.2.2.4 ProdHM Vernichtungskosten hinsichtlich des fehlerhaften Gesamtprodukts einschließlich der Transportkosten zum Vernichtungsort sowie Zoll-, Lager-, Sortier- und Überprüfungskosten gezählt, soweit sie die Folge der Unveräußerlichkeit des mangelhaften Gesamtprodukts sind1. Umstritten ist, ob zu den weiteren Vermögensnachteilen auch etwaige Ver- 121 tragsstrafen gerechnet werden können, die der Hersteller des Gesamtprodukts an seinen Vertragspartner zahlen muss, weil er das Gesamtprodukt infolge seiner Mangelhaftigkeit nicht veräußern kann. Zum Teil wird dies mit der Begründung verneint, ersetzt würden nur solche Vermögensnachteile, die eine direkte Folge der Unveräußerlichkeit des Gesamtprodukts seien, es sich bei der Vertragsstrafe aber lediglich um eine mittelbare Folge der Unveräußerlichkeit handele2. Dem wird entgegengehalten, dass dem Wortlaut von Ziff. 4.2.2.4 ProdHM ein Unmittelbarkeitskriterium nicht entnommen werden könne. Für die letztgenannte Ansicht spricht, dass das Erfordernis der Unmittelbarkeit zum Zwecke der Begrenzung des Versicherungsschutzes für Produktionsausfallkosten in Ziff. 4.2.2.5 ProdHM ausdrücklich enthalten ist3. (b) Veräußerung des Gesamtprodukts nicht oder nur mit Preisnachlass Gemäß Ziff. 4.2.2.4 ProdHM muss der Vermögensnachteil darauf beruhen, 122 dass das Gesamtprodukt unveräußerlich ist oder nur mit Preisnachlass veräußert werden kann. Die Unveräußerlichkeit kann sich sowohl aus tatsäch-

1 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 86; Stempfle, in: MAH VersicherungsR, § 15 Rz. 147, jeweils m.w.N. 2 Vgl. Thürmann/Kettler, S. 129; Schmidt-Salzer/Hinsch, Rz. 7.670. 3 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 88 f.; Stempfle, in: MAH VersicherungsR, § 15 Rz. 148.

Koch

1311

O Rz. 123

Einzelprobleme

lichen als auch aus rechtlichen Gründen ergeben1. Bei fehlerhafter Software dürfte stets tatsächliche Unveräußerlichkeit vorliegen. Sie ist anzunehmen, wenn das Gesamtprodukt vernichtet werden muss oder derart mit Mängeln behaftet ist, dass es von vornherein niemand kaufen oder nicht zu einem geringeren Preis behalten will, wenn also mit einem Rücktritt nach Übergabe innerhalb der Gewährleistungsfrist zu rechnen ist2. Rechtliche Unveräußerlichkeit ist gegeben, wenn ein mangelhaftes Gesamtprodukt auf Grund eines Verstoßes gegen gesetzliche Bestimmungen nicht absetzbar ist oder mit einem behördlichen Verkaufsverbot belegt wurde3. Ziff. 4.2.2.4 ProdHM ist ferner anwendbar, wenn das – mangelhafte – Gesamtprodukt nur mit einem Preisnachlass veräußert werden kann. Dabei kommt es nicht darauf an, ob der Hersteller des Gesamtprodukts den Preisnachlass auf Verlangen seiner Kunden – vor oder nach der Übereignung – einräumen muss, auf Grund seines mangelhaften Zustands sogleich mit einem Preisnachlass verkauft oder trotz Nachbearbeitung nicht den zu erwartenden Preis erzielen kann4. (c) Einschränkung der Eintrittspflicht des Versicherers 123

Wie bei Ziff. 4.2.2.3 ProdHM wird in Bezug auf die gedeckten Schadenpositionen das nicht versicherte Erfüllungsinteresse des Versicherungsnehmers mittels Quotenklausel in Abzug gebracht. (5) Produktionsausfall (Ziff. 4.2.2.5 ProdHM)

124

Schließlich besteht gemäß Ziff. 4.2.2.5 ProdHM Versicherungsschutz auch für Schadenersatzansprüche wegen „der dem Abnehmer des Versicherungsnehmers unmittelbar entstandenen Kosten durch den Produktionsausfall, der aus der Mangelhaftigkeit der Gesamtprodukte herrührt. Ansprüche wegen eines darüber hinausgehenden Schadens durch den Produktionsausfall sind nicht versichert.“

(a) Begriff des Produktionsausfalls 125

Voraussetzung für die Anwendbarkeit von Ziff. 4.2.2.5 ProdHM ist ein Produktionsausfall. Ein solcher liegt vor, wenn ungewollt der Fertigungsprozess unterbrochen wird5.

1 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 91; Schmidt-Salzer/Hinsch, Rz. 7.666. 2 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 91; Schmidt-Salzer/Hinsch, Rz. 7.666. 3 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 91; Stempfle, in: MAH VersicherungsR, § 15 Rz. 150. 4 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 92; Stempfle, in: MAH VersicherungsR, § 15 Rz. 152; Thürmann/Kettler, S. 130. 5 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 100; Schmidt-Salzer/Hinsch, Rz. 7.684.

1312

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 127 O

(b) Infolge der Mangelhaftigkeit der Gesamtprodukte Der Produktionsausfall muss auf der Mangelhaftigkeit der Gesamtprodukte 126 beruhen, die wiederum aus der Verbindung, Vermischung oder Verarbeitung mangelhafter Erzeugnisse mit anderen Produkten zu einer neuen Sache entstanden sein muss. An dieser Doppelkausalität fehlt es, wenn der Mangel des Erzeugnisses – im obigen Beispiel die ERP-Basissoftware – vor Beginn der Verbindung, Vermischung oder Verarbeitung z.B. bei der Eingangskontrolle festgestellt und deshalb die Produktion gestoppt wird. Für die Schadenersatzansprüche des Abnehmers wegen daraus erwachsener Kosten besteht kein Versicherungsschutz1. Weiterhin ist zu berücksichtigen, dass der Produktionsausfall selbst nicht gedeckt ist („durch den Produktionsausfall“), sondern nur die dem ersten Abnehmer (Hersteller des Gesamtprodukts) infolge des Ausfalls unmittelbar entstehenden Kosten, die daraus resultieren, dass das Gesamtprodukt mehrere Verarbeitungs- und Bearbeitungsstufen durchlaufen sollte, auf den weiteren Stufen aber infolge des Produktionsausfalls nicht weiter be- oder verarbeitet werden kann2. Unmittelbar soll in diesem Zusammenhang bedeuten, dass nur die Kosten 127 ersetzt werden, die für die unmittelbar nachgeschalteten Arbeiten beim Gesamtprodukthersteller als laufende Kosten entstehen (z.B. Löhne der Etikettier- und Verpackungsabteilung). Insoweit ist die mehrstufige Verarbeitung nicht in die Deckung einbezogen3. Im Übrigen sind Kosten nicht gleichzusetzen mit Einnahmeausfall und umfassen deshalb auch nicht den entgangenen Gewinn4. Kommt es in dem obigen Beispiel infolge des Fehlers der ERP-Basissoftware innerhalb des Betriebs des Softwarehauses zu einem Stillstand der für die Anpassung zuständigen Abteilung, werden somit nur die Kosten für die in dieser Abteilung beschäftigten Arbeitnehmer und eingesetzten Maschinen ersetzt, nicht hingegen der durch den Produktionsausfall entgangene Gewinn. Sofern es bei Abnehmern des Softwarehauses infolge des Produktionsausfalls ebenfalls zu einem Ausfall kommt und diese das Softwarehaus deswegen auf Schadenersatz in Anspruch nehmen, besteht für etwaige um diese Position erhöhte Schadenersatzansprüche des Softwarehauses gegen den Versicherungsnehmer aus §§ 280 Abs. 1, 2, 286 BGB oder §§ 281, 280 Abs. 1 BGB kein Versicherungsschutz.

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 7; Stempfle, in: MAH VersicherungsR, § 15 Rz. 156, 159. 2 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 106; Schmidt-Salzer/Hinsch, Rz. 7.690. 3 Vgl. Thürmann, PHi 2000, 163, 170; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 106; Schmidt-Salzer/Hinsch, Rz. 7.690. 4 Vgl. Nickel, in: Kullmann/Pfister, Kza 6860, S. 30, 37; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 39; Produkthaftungshdb./Graf von Westphalen, § 52 Rz. 12; Schmidt-Salzer/Hinsch, Rz. 7.692.

Koch

1313

O Rz. 128

Einzelprobleme

c) Weiterverarbeitung und -bearbeitung (Ziff. 4.3 ProdHM) 128

Lehnt man die Qualifikation des Vorgangs der Anpassung von Basissoftware als Verarbeitung i.S.v. Ziff. 4.2 ProdHM ab, stellt sich die Frage, ob nicht der Baustein gemäß Ziff. 4.3.1 ProdHM eingreift. Dieser verspricht Versicherungsschutz für „gesetzliche Schadenersatzansprüche Dritter wegen der in Ziff. 4.3.2 genannten Vermögensschäden i.S.v. Ziff. 2.1 AHB infolge Weiterverarbeitung oder -bearbeitung mangelhaft hergestellter oder gelieferter Erzeugnisse, ohne dass eine Verbindung, Vermischung oder Verarbeitung mit anderen Produkten stattfindet. Erzeugnisse im Sinne dieser Regelung können sowohl solche des Versicherungsnehmers als auch Produkte Dritter sein, die Erzeugnisse des Versicherungsnehmers enthalten.“

Deckungsauslösendes Schadenereignis für Weiterverarbeitungs- und -bearbeitungsschäden ist gemäß Ziff. 8.2.2 ProdHM der Zeitpunkt der Weiterverarbeitung und -bearbeitung der Erzeugnisse. aa) Voraussetzungen des Bausteins gemäß Ziff. 4.3.1 ProdHM (1) Weiterverarbeitung oder -bearbeitung mangelhafter Erzeugnisse 129

Unter Weiterverarbeitung werden allgemein solche Vorgänge erfasst, bei denen der Dritte das gelieferte Erzeugnis zu einem anderen Produkt umwandelt („sachauflösende Wertschöpfung“). Bei Weiterbearbeitung bleibt das gelieferte Erzeugnis in der Regel erhalten, wird aber einer Veredelung, Oberflächenbehandlung oder Ähnlichem unterzogen („sachbewahrende Wertschöpfung“)1. (2) Anwendbarkeit von Ziff. 4.3.1 ProdHM auf Software (Daten und Programme)

130

Die unmittelbare Weiterverarbeitung oder -bearbeitung der Daten findet im Arbeitsspeicher des jeweiligen Computers statt. Da die Daten mit dem Laden in den Arbeitsspeicher ihre Sachqualität verlieren und erst wieder mit ihrer Abspeicherung auf dem Datenträger in dann weiterver- oder -bearbeiteter Form erlangen, stellt sich auch hier die Frage nach der Anwendbarkeit von Ziff. 4.3.1 ProdHM. Bejaht man sie, dürfte der Vorgang der Anpassung von Basissoftware nicht lediglich als Weiterbe-, sondern als Weiterverarbeitung zu qualifizieren sein. bb) Versicherte Kosten (Ziff. 4.3.2 ProdHM)

131

Die Deckung regelt sich nach Ziff. 4.3.2 ProdHM, die in ihrer Struktur Ziff. 4.2.2 ProdHM gleicht. Es fehlen lediglich die Gegenstücke zu Ziff. 4.2.2.1 ProdHM (Beschädigung der anderen Produkte) und zu Ziff. 4.2.2.5 (Kosten durch Produktionsausfall).

1 Vgl. Späte, ProdHM, Rz. 36; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 114.

1314

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 135 O

(1) Nutzlose Weiterverarbeitungs- oder -bearbeitungskosten (Ziff. 4.3.2.1 ProdHM) Zunächst besteht gemäß Ziff. 4.3.2.1 ProdHM Versicherungsschutz für Schadenersatzansprüche wegen der

132

„Kosten für die Weiterverarbeitung oder -bearbeitung der mangelhaften Erzeugnisse mit Ausnahme des Entgeltes für die mangelhaften Erzeugnisse des Versicherungsnehmers, sofern die verarbeiteten oder bearbeiteten Erzeugnisse unveräußerlich sind“.

Ersetzt werden z.B. die umsonst aufgewandten Lohnkosten, Energiekosten, Kosten für Betriebs- und Verbrauchsstoffe und Abschreibungen für die eingesetzten Maschinen. Nicht gedeckt sind die Materialkosten für das zugelieferte fehlerhafte Produkt1. (2) Nachbesserungskosten bei Weiterverarbeitungs- oder -bearbeitungsschäden und weitere Vermögensnachteile (Ziff. 4.3.2.2 und Ziff. 4.3.2.3 ProdHM) Die Regelungen zum Ersatz der Nachbesserungskosten bei Weiterverarbei- 133 tungs- oder -bearbeitungskosten gemäß Ziff. 4.3.2.2 ProdHM sowie zum Ersatz weiterer Vermögensnachteile gemäß Ziff. 4.3.2.3 ProdHM sind inhaltsgleich mit Ziff. 4.2.2.2 und Ziff. 4.2.2.3 ProdHM. Insoweit kann auf die dortigen Anmerkungen verwiesen werden (Rz. 112 ff.). d) Aus- und Einbaukosten (Ziff. 4.4 ProdHM) Der Baustein gemäß Ziff. 4.4.1 ProdHM verspricht Versicherungsschutz für

134

„gesetzliche Schadenersatzansprüche Dritter wegen der in Ziff. 4.4.2 und 4.4.3 genannten Vermögensschäden i.S.v. Ziff. 2.1 AHB infolge Mangelhaftigkeit von Gesamtprodukten Dritter, die durch den Einbau, das Anbringen, Verlegen oder Auftragen von mangelhaft hergestellten oder gelieferten Erzeugnissen entstanden sind. Erzeugnisse im Sinne dieser Regelung können sowohl solche des Versicherungsnehmers als auch Produkte Dritter sein, die Erzeugnisse des Versicherungsnehmers enthalten.“

Deckungsauslösendes Schadenereignis ist gemäß Ziff. 8.2.3 ProdHM der Zeitpunkt des Einbaus, Anbringens, Verlegens oder Auftragens der Erzeugnisse. aa) Voraussetzungen des Bausteins gemäß Ziff. 4.4.1 ProdHM (1) Einbau, Anbringen, Verlegen oder Auftragen mangelhafter Erzeugnisse Die Begriffe Einbau, Anbringen, Verlegen oder Auftragen haben keinen Ein- 135 gang in die Rechtssprache gefunden. Nach allgemeiner Auffassung beschreiben sie lediglich tatsächliche Vorgänge und sind exemplarischen Charakters. Wie die Begriffspartner auf der Seite der Wiederherstellung in 1 Vgl. hierzu Späte, ProdHM, Rz. 37; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 121; Schmidt-Salzer/Hinsch, Rz. 7.733 ff.

Koch

1315

O Rz. 136

Einzelprobleme

Ziff. 4.4.2.1 ProdHM zeigen (Ausbauen, Abnehmen, Freilegen oder Entfernen) soll dadurch konzeptionell jeder nennenswerte Aufwand zum Austausch eines gelieferten Erzeugnisses erfasst werden, ohne dass es darauf ankommt, wie dieser Austauschvorgang benannt wird1. Selbst der Austausch von künstlichen Körperteilen, Implantaten, Herzschrittmachern soll darunter fallen2. (2) Anwendbarkeit von Ziff. 4.4.1 ProdHM auf Software (Daten und Programme) 136

Fraglich ist die Anwendbarkeit dieses Bausteins auf fehlerhafte Software. Daten und Programme werden weder in eine Sache eingebaut noch an einer Sache angebracht, auf ihr verlegt oder aufgetragen, sondern mit anderen Daten und Programmen entweder im Arbeitsspeicher verknüpft oder direkt auf der Festplatte abgespeichert. Beispiel: Der Versicherungsnehmer erstellt Programmbausteine, die von seinen Abnehmern in Softwarepakete integriert und in PCs installiert werden. Auf Grund eines Fehlers in den Programmbausteinen des Versicherungsnehmers kommt es zu einem ständigen „Aufhängen“ der PCs. Die Programmbausteine lassen sich unproblematisch aus dem Softwarepaket wieder entfernen.

Von einem Einbau kann hier allenfalls im übertragenen Sinne gesprochen werden, was allerdings wegen der Beispielhaftigkeit der in Ziff. 4.4.1 ProdHM aufgeführten Austauschvorgänge ausreicht3. Zweifel an der Anwendbarkeit sind jedoch wiederum unter dem Gesichtspunkt angebracht, dass den Daten im Zeitpunkt des so verstandenen Einbaus, d.h. während der Integration der fehlerhaften Bausteine in das Softwarepaket keine Sacheigenschaft zukommt. Erst mit dem Abspeichern der aufgespielten Daten und Programme durch den Erwerber erlangen sie wieder Sachqualität. 137

Soweit Vertreter der Versicherungswirtschaft sich mit dieser Problematik auseinandergesetzt haben, verneinen sie die Anwendbarkeit von Ziff. 4.4.1 ProdHM auf „mangelhafte Computerdaten oder Software“4. Zur Begründung führen sie an, es handele sich um gespeicherte Befehle, die einen entsprechenden Datenträger elektronisch so konfigurierten, dass bestimmte Funktionen des Geräts ermöglicht würden. Er würde also kein gegenständliches Erzeugnis eingebaut, angebracht oder verlegt, sondern eine elektronische Einstellung eines vorhandenen Datenträgers vorgenommen, die mit der Magnetisierung einer metallischen Oberfläche verglichen werden könn-

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 9; s.a. Thürmann/Kettler, S. 149 f.; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 162 ff., zu Ziff. 4.4 lit. a) ProdHM 1987. 2 Schmidt-Salzer/Hinsch, Rz. 7.776. 3 Nickel, in: Kullmann/Pfister, Kza 6926, S. 13. 4 Vgl. Thürmann/Kettler, S. 148.

1316

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 140 O

te1. Dieser Argumentation liegt der Gedanke zu Grunde, dass Daten, selbst wenn sie auf einem Datenträger verkörpert sind, keine Sachqualität zukommt. Sie lässt zugleich erahnen, welchen Standpunkt ein Versicherer (im Deckungsstreit) einnehmen würde. bb) Versicherte Kosten (Ziff. 4.4.2 ProdHM) Sieht man in dem vorherigen Beispiel den Tatbestand der Ziff. 4.4.1 ProdHM als erfüllt an, regelt sich der Umfang der Deckung nach Ziff. 4.4.2 ProdHM.

138

(1) Austauschkosten (Ziff. 4.4.2.1 ProdHM) (a) Erzeugnis Versicherungsschutz besteht gemäß Ziff. 4.4.2.1 ProdHM für Schadenersatzansprüche des Gesamtprodukteherstellers gegen den Versicherungsnehmer wegen der

139

„Kosten für den Austausch mangelhafter Erzeugnisse (nicht jedoch von deren Einzelteilen), d.h. Kosten für das Ausbauen, Abnehmen, Freilegen oder Entfernen mangelhafter Erzeugnisse und das Einbauen, Anbringen, Verlegen oder Auftragen mangelfreier Erzeugnisse oder mangelfreier Produkte Dritter. Vom Versicherungsschutz ausgenommen bleiben die Kosten für die Nach- und Neulieferung mangelfreier Erzeugnisse oder mangelfreier Produkte Dritter.“

Versicherungsschutz nach diesem Baustein besteht somit nur für die Schadenersatzansprüche des geschädigten Dritten gegen den Versicherungsnehmer, die auf den Ersatz der im Zusammenhang mit dem Austausch stehenden Kosten gerichtet sind. Hierzu zählen neben den in Ziff. 4.4.2.1 Satz 1 genannten Kosten z.B. Reisekosten, Überstundenzuschläge, Spesen und Übernachtungskosten für das Montagepersonal, Gemeinkosten, Prüfkosten sowie Kosten für Arbeitsmittel und -geräte, Kleinteile. Nicht gedeckt werden nach Ziff. 4.4.2.1 Satz 2 ProdHM die Kosten für die Nach- und Neulieferung mangelfreier Erzeugnisse2. Die Kosten der Überprüfung, ob das eingebaute Produkt mangelhaft ist, zäh- 140 len nicht zu den gemäß Ziff. 4.4.2.1 ProdHM gedeckten Schadenersatzpositionen, da sie dem eigentlichen Ausbau vorgeschaltet sind. Nur der nach Abschluss der Überprüfung vorgenommene Ausbau der als mangelhaft erkannten Erzeugnisse ist gedeckt3. Ob daneben ein Anspruch auf Deckung der Überprüfungskosten nach §§ 62, 63 VVG als Rettungskosten besteht, ist streitig4. 1 Vgl. Thürmann/Kettler, S. 148. 2 Vgl. Nickel, in: Kullmann/Pfister, Kza 6926, S. 12 f. 3 Einzelheiten hierzu bei Schmidt-Salzer/Hinsch, Rz. 7.846 ff.; vgl. ferner Grote, VersR 1995, 508 (510); Thürmann/Kettler, S. 155 f.; Späte, ProdHM, Rz. 43. 4 Ablehnend: Stempfle, in: MAH VersicherungsR, § 15 Rz. 194; Schmidt-Salzer/ Hinsch, Rz. 7.855 ff.; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 148; bejahend: Produkthaftungshdb./Graf von Westphalen, § 52 Rz. 54 ff.

Koch

1317

O Rz. 141

Einzelprobleme

(b) Einzelteile von Erzeugnissen 141

Für die Praxis von besonderer Bedeutung ist der im Klammerzusatz ausdrücklich statuierte Ausschluss der Deckung von Schadenersatzansprüchen, die auf den Ersatz der Kosten für den Austausch von Einzelteilen von (Gesamt-)Erzeugnissen des Versicherungsnehmers gerichtet sind1. Bei der Herstellung von Software dürfte ein Austausch einzelner Daten freilich kaum in Betracht kommen, vielmehr wird eine mangelfreie Version aufgespielt. Im Übrigen besteht die Möglichkeit, Schadenersatzansprüche, die auf den Ersatz der Kosten aus Einzelteileaustauschmaßnahmen sowie für Reparaturen im eingebauten Zustand gerichtet sind, durch Vereinbarung der Deckungserweiterung gemäß Ziff. 4.4.5 ProdHM zu beseitigen. (2) Transportkosten (Ziff. 4.4.2.2 ProdHM)

142

Ziff. 4.4.2.2 ProdHM trifft eine Regelung bezüglich der Deckung von Transportkosten, die im Zusammenhang mit der Anlieferung eines mangelfreien Erzeugnisses im Rahmen einer Aus- und Einbaumaßnahme entstehen. Danach sind ausschließlich Schadenersatzansprüche gedeckt wegen der „Kosten für den Transport mangelfreier Erzeugnisse oder mangelfreier Produkte Dritter mit Ausnahme solcher an den Erfüllungsort der ursprünglichen Lieferung des Versicherungsnehmers. Sind die Kosten für den direkten Transport vom Versicherungsnehmer bzw. vom Dritten zum Ort des Austausches geringer als die Kosten des Transportes vom Erfüllungsort der ursprünglichen Lieferung des Versicherungsnehmers zum Ort des Austausches, sind nur die Kosten des Direkttransportes versichert.“

Nennenswerte Transportkosten dürften beim Austausch fehlerhafter Software kaum entstehen, soweit dieser online erfolgt. (3) Nachbesserungsbedingter Austausch (Ziff. 4.4.3 ProdHM) 143

Die Regelung gemäß Ziff. 4.4.3 ProdHM ist haftpflichtuntypisch, weil sie die Deckung für die in Ziff. 4.4.2 ProdHM zuvor behandelten Kosten auf solche Fälle erweitert, in denen die Kosten des Austausches mangelhafter durch mangelfreie Produkte „zur Erfüllung einer gesetzlichen Pflicht zur Neulieferung oder zur Beseitigung eines Mangels des Erzeugnisses des Versicherungsnehmers von diesem oder seinem Abnehmer aufgewendet werden.“ (Hervorhebung durch den Verfasser)

Damit sind die Aus- und Einbaukosten nicht nur im Rahmen eines Schadenersatzanspruchs des Abnehmers gemäß §§ 437 Nr. 3, 440, 281, 280/§§ 634 Nr. 4, 636, 281, 280 BGB versichert, sondern auch im Rahmen der Nacherfüllung im Wege der Mangelbeseitigung oder Ersatzlieferung (§ 439 Abs. 2/§ 635 Abs. 2 BGB).

1 Vgl. LG Hannover v. 27.12.2002 – 6 O 144/02, VersR 2003, 1247 f. – zur Reichweite der Ausbau- und Einbaukostenklausel nach dem ProdHM 1987.

1318

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 148 O

(4) Ausschlüsse (Ziff. 4.4.4 ProdHM) In Ziff. 4.4.4 ProdHM sind speziell für die Austauschkostendeckung gelten- 144 de Ausschlüsse formuliert. (a) Eigenmontage-Ausschluss (Ziff. 4.4.4.1 ProdHM) Keine Deckung besteht für auf den Ersatz von Austauschkosten gerichtete Schadenersatz- oder Nachbesserungsansprüche gegen den Versicherungsnehmer, soweit er

145

„die mangelhaften Erzeugnisse selbst eingebaut oder montiert hat oder in seinem Auftrag, für seine Rechnung oder unter seiner Leitung hat einbauen oder montieren lassen …“ (Hervorhebung durch den Verfasser)

Dies gilt nicht, „… wenn der Versicherungsnehmer beweist, dass die Mangelhaftigkeit nicht aus dem Einbau, der Montage oder Montageleitung, sondern ausschließlich aus der Herstellung oder Lieferung resultiert“.

Mit der Beschränkung des Eigenmontage-Ausschlusses wird vor allem si- 146 chergestellt, dass der neben der Lieferung auch noch zum Einbau verpflichtete Versicherungsnehmer gegenüber dem nur zur Lieferung verpflichteten Versicherungsnehmer nicht schlechter gestellt wird1. Auf Grund dieser Beschränkung kommt er bei Softwarefehlern nur zur Anwendung, wenn die Fehlerhaftigkeit auf der Installation beruht. (b) Kfz-, Schienen- und Wasserfahrzeugteile-Ausschluss (Ziff. 4.4.4.2 ProdHM) Kein Versicherungsschutz besteht, wenn

147

„sich die Mangelbeseitigungsmaßnahmen gemäß Ziff. 4.4.1 bis 4.4.3 auf Teile, Zubehör oder Einrichtungen von Kraft-, Schienen- oder Wasserfahrzeugen beziehen“.

Betroffen von diesem Ausschluss sind u.a. Hersteller von Software in der Steuerungselektronik für Kraftfahrzeuge. Die Anwendung des Ausschlusses wird jedoch beschränkt auf die Fälle, in denen „… diese Erzeugnisse im Zeitpunkt der Auslieferung durch den Versicherungsnehmer oder von ihm beauftragte Dritte ersichtlich für den Bau von oder den Einbau in Kraft-, Schienen- oder Wasserfahrzeugen bestimmt waren“. (Hervorhebung durch den Verfasser)

Die Zweckbestimmung der Erzeugnisse für die angesprochenen Risikobereiche muss dem Versicherungsnehmer somit bereits bei Auslieferung zumindest erkennbar gewesen sein2. Fahrlässige Unkenntnis steht insoweit

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 10; s.a. Thürmann, PHi 2000, 163 (171). 2 Vgl. Thürmann/Kettler, S. 178.

Koch

1319

148

O Rz. 149

Einzelprobleme

positiver Kenntnis gleich1. Fahrlässigkeit ist zu bejahen, wenn der Versicherungsnehmer oder der von ihm eingeschaltete Dritte anhand der ihm zur Verfügung gestandenen Informationen und Unterlagen erkennen konnte, für welchen Zweck die von ihm hergestellten oder gelieferten Erzeugnisse bestimmt waren. Allein die Tatsache, dass ein bestimmtes Produkt in unterschiedlicher Art eingesetzt werden kann, maW die abstrakte Möglichkeit genügt hierfür nicht2. (c) Ausgrenzung des Austauschrisikos zum Rückrufrisiko (Ziff. 4.4.4.3 ProdHM) 149

Kein Versicherungsschutz im Rahmen des Deckungsbausteins gemäß Ziff. 4.4 ProdHM besteht nach Ziff. 4.4.4.3 ProdHM für Ansprüche wegen der Kosten im Zusammenhang mit einem Rückruf von Erzeugnissen des Versicherungsnehmers oder Produkten Dritter, die Erzeugnisse des Versicherungsnehmers enthalten (Ziff. 6.2.8 ProdHM). e) Maschinenklausel/Steuerungselementeklausel (Ziff. 4.5 ProdHM) aa) Maschinenklausel

150

Der Baustein gemäß Ziff. 4.5.1 ProdHM verspricht Versicherungsschutz für „gesetzliche Schadenersatzansprüche Dritter wegen der in Ziff. 4.5.2 genannten Vermögensschäden i.S.v. Ziff. 2.1 AHB infolge Mangelhaftigkeit von Produkten, die durch vom Versicherungsnehmer mangelhaft hergestellte, gelieferte, montierte oder gewartete Maschinen produziert, be- oder verarbeitet wurden.“

Ziff. 4.5 ProdHM regelt den Sachverhalt, dass mit einer vom Versicherungsnehmer hergestellten Maschine mangelhafte Produkte hergestellt werden. Unter dem Begriff der Maschine sind Vorrichtungen zur fortlaufenden Produktion, Be- oder Verarbeitung von Sachen, also Hardware zu verstehen3. Die Vereinbarung dieser Klausel macht deshalb für ein reines Softwarehaus keinen Sinn. bb) Deckungserweiterung (1) Steuerungselementeklausel 151

Liefert das Softwarehaus neben der Software ergänzend auch einzelne Hardware-Elemente, die in Maschinen eingebaut werden und dazu dienen, den maschinellen Herstellungsprozess unmittelbar oder mittelbar zu steuern, zu kontrollieren oder auf andere Weise zu beeinflussen, besteht für die daraus resultierenden Risiken ebenfalls kein Versicherungsschutz. Maschi-

1 Vgl. Thürmann/Kettler, S. 178; a.A. Produkthaftungshdb./Graf von Westphalen, § 50 Rz. 50. 2 Vgl. Stempfle, in: MAH VersicherungsR, § 15 Rz. 206. 3 Vgl. Schmidt-Salzer/Hinsch, Rz. 7.904; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 236.

1320

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 152 O

nenteile, die nicht ihrerseits Maschinen sind, fallen nämlich ebenfalls nicht unter diesen Deckungsbaustein1. Es besteht jedoch die Möglichkeit, diese Risiken durch Vereinbarung der sog. Steuerungselementeklausel mitzuversichern2. Diese Klausel wird i.d.R. zu Ziff. 4.5.1 ProdHM als dritter Absatz eingefügt und hat folgenden Wortlaut3: „Als Maschinen gelten auch Werkzeuge an Maschinen und Erzeugnisse der Steuer-, Mess- und Regeltechnik sowie Formen.“ Beispiel4: Der Versicherungsnehmer liefert neben der Steuerungs-Software für eine Produktionsstraße ergänzend auch einzelne Hardware-Elemente. Durch einen Fehler dieser Elemente wird Ausschuss produziert.

Zu beachten ist, dass der Umfang des Versicherungsschutzes nach Maßgabe der Steuerungselementeklausel akzessorisch an das Bestehen und den Umfang der Deckung des Herstellers der Maschine anknüpft, in die die Steuerungselemente eingebaut worden sind. (2) Anwendbarkeit auf die Produktion, Be- oder Verarbeitung von Daten Fraglich ist, ob die Steuerungselementeklausel auch dann eingreift, wenn 152 eine Maschine infolge eines Mangels der in den Maschinen integrierten Hardware-Elemente fehlerhafte Daten erstellt. Beispiel: Der Versicherungsnehmer liefert für eine Supermarktkette Software für BarcodeLesegeräte sowie Hardware-Elemente, die in die Lesegeräte integriert werden. Auf Grund eines Mangels der Hardware werden die Barcodes für die jeweiligen Waren fehlerhaft erfasst mit der Folge, dass den Kunden an der Kasse zum Teil zu niedrige Preise für Waren berechnet werden. Bei den mittels des Lesegeräts erfassten und abgespeicherten Daten handelt es sich um Sachen i.S.v. § 90 BGB. Die ermittelten Daten sind zwar nicht das Ergebnis einer Be- oder Verarbeitung5. Sie lassen sich jedoch als neue Produkte i.S.v. Ziff. 4.5.1 ProdHM begreifen. Der hiergegen vom Schrifttum vorgebrachte Einwand, eine mangelhafte Datenermittlung führe nicht zu Mängeln der gemessenen oder geprüften Sache, sondern allenfalls zu Folgeschäden wegen falscher Ergebnisse6, vermag angesichts der nach § 305c Abs. 2 BGB gebotenen Auslegung zugunsten des Versicherungsnehmers ebenso wenig zu überzeugen wie der Hinweis darauf, dass der Rechtsfolgenkatalog dieses Deckungsbausteins nicht auf derartige 1 Vgl. Prölss/Martin/Voit/Knappmann, ProdHaftPfl Nr. 4 Rz. 62; Schmidt-Salzer/ Hinsch, Rz. 7.910. 2 Vgl. Nickel, in: Kullmann/Pfister, Kza 6926, S. 21; Schmidt-Salzer/Hinsch, Rz. 7.910. 3 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 13. 4 Vgl. GDV-Rundschreiben H 37/2002 M v. 1.7.2002, S. 15. 5 Vgl. auch Schmidt-Salzer/Hinsch, Rz. 7.908: „Bei datenermittelnden Geräten (Messen, Wiegen, Testen, Prüfen) lässt sich zwar durchaus von einer Bearbeitung oder Verarbeitung von Sachen sprechen …“. 6 Vgl. Schmidt-Salzer/Hinsch, Rz. 7.908; ihm folgend Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 236; Stempfle, in: MAH VersicherungsR, § 15 Rz. 238.

Koch

1321

O Rz. 153

Einzelprobleme

Vermögensschäden ausgerichtet sei1. Für die Schadenersatzansprüche der Lesegerät-Hersteller gemäß §§ 437 Nr. 3/634 Nr. 4, 280 Abs. 1 BGB besteht mithin grundsätzlich Versicherungsschutz nach Maßgabe von Ziff. 4.5.2 ProdHM.

cc) Versicherte Schäden und Kosten (Ziff. 4.5.2 ProdHM) (1) Beschädigung oder Vernichtung anderer Produkte (Ziff. 4.5.2.1 ProdHM) 153

Gemäß Ziff. 4.5.2.1 ProdHM sind zunächst gedeckt Schadenersatzansprüche wegen „der Beschädigung oder Vernichtung der mittels der Maschine [Steuer-, Mess- und Regeltechnik] hergestellten, be- oder verarbeiteten Produkte, soweit hierfür nicht bereits Versicherungsschutz nach Ziff. 1 oder 4.1 besteht“. [Zusatz in eckigen Klammern durch Verfasser]

Diese Klausel ist Ziff. 4.2.2.1 ProdHM nachgebildet (Rz. 113). Bezogen auf das hier in Rede stehende Beispiel kommt ihr keine Bedeutung zu, da durch das fehlerhafte Erfassen von Barcodes nichts beschädigt oder vernichtet wird. (2) Nutzlose Herstellungskosten (Ziff. 4.5.2.2 ProdHM) 154

Nach Ziff. 4.5.2.2 ProdHM besteht Versicherungsschutz für Schadenersatzansprüche wegen „anderer für die Herstellung, Be- oder Verarbeitung der Produkte nutzlos aufgewendeter Kosten“.

Diese Deckungsklausel unterscheidet sich von Ziff. 4.2.2.2 ProdHM nur durch den Zusatz „nutzlos“. Ergänzend sei deshalb auf die dortigen Ausführungen verwiesen (Rz. 114). Durch den Zusatz wird klargestellt, dass Versicherungsschutz nur für die Kosten der ursprünglich mangelhaften Produktion, Be- oder Verarbeitung besteht, nicht aber für die Kosten einer Ersatz-Herstellung2. Zu den versicherten Kosten der Produktion zählen z.B. Lohnkosten, Energiekosten, Abschreibungen, Verpackung, Kosten für den Transport des Rohmaterials zum Maschinenhersteller3. Im obigen Beispiel zählen zu den versicherten Kosten nur die Lohn- und Energiekosten für das fehlerhafte Erfassen. (3) Nachbesserungskosten (Ziff. 4.5.2.3 ProdHM) 155

Soweit der geschädigte Abnehmer der Maschine haftungsrechtlich auf Grund seiner Schadenminderungspflicht gemäß § 254 Abs. 2 Satz 1 BGB verpflichtet ist, die fehlerhaft hergestellte, be- oder verarbeiteten Produkte nachzubessern (und nicht komplett zu verwerfen), besteht nach Ziff. 4.5.2.3 ProdHM Versicherungsschutz hinsichtlich der

1 Vgl. Schmidt-Salzer/Hinsch, Rz. 7.908. 2 Produkthaftungshdb./Graf von Westphalen, § 55 Rz. 34; Schmidt-Salzer/Hinsch, Rz. 7.967. 3 Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 259; Späte, ProdHM, Rz. 51.

1322

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 157 O

„Kosten für eine rechtlich gebotene und wirtschaftlich zumutbare Nachbearbeitung der mittels der Maschinen [Steuer-, Mess- und Regeltechnik] des Versicherungsnehmers hergestellten, be- oder verarbeiteten Produkte oder für eine andere Schadenbeseitigung“. [Zusatz in eckigen Klammern durch Verfasser]

Die Regelung ist weitgehend Ziff. 4.2.2.3 ProdHM nachgebildet, weshalb ergänzend auf die dortigen Ausführungen verwiesen wird (Rz. 115 ff.). Das Wort „Gesamtprodukte“ wurde ersetzt durch die Formulierung „mittels der Maschinen [Steuer-, Mess- und Regeltechnik] des Versicherungsnehmers hergestellten, be- oder verarbeiteten Produkte“. Anders als nach Ziff. 4.2.2.3 ProdHM enthält die Maschinenklausel keine Quotenklausel, mittels derer das nicht versicherte Erfüllungsinteresse in Abzug gebracht wird. Dies liegt daran, dass die Produkte keine Erzeugnisse des Versicherungsnehmers sind und auch keine Produkte Dritter darstellen, die Erzeugnisse des Versicherungsnehmers enthalten1. Zu den versicherten Nachbearbeitungskosten zählen im obigen Beispiel die Kosten für die Neuerfassung der Barcodes. Im Unterschied zu Ziff. 4.2.2.3 und Ziff. 4.3.2.2 ProdHM sind die Kosten für 156 eine notwendige Nachbearbeitung der mittels der Steuer-, Mess- und Regeltechnik des Versicherungsnehmers hergestellten, be- oder verarbeiteten Produkte oder die Kosten für eine andere Schadenbeseitigung selbst dann gedeckt, wenn diese Maßnahmen im Rahmen einer Rückrufaktion erfolgen. Diese Abweichung ist darin begründet, dass der Versicherungsnehmer anders als bei den Bausteinen der Ziff. 4.2 und 4.3 ProdHM keine Möglichkeit hat, seine gesetzlichen Haftpflichtrisiken hinsichtlich der mittels einer von ihm hergestellten Steuer-, Mess- und Regeltechnik hergestellten, be- oder verarbeiteten Produkte über eine Rückrufkostenversicherung zu decken2. Es fehlt daher in Ziff. 4.5.2.3 ProdHM an dem Hinweis auf den Rückrufkostenausschluss der Ziff. 6.2.8 ProdHM. (4) Weitere Vermögensnachteile (Ziff. 4.5.2.4 ProdHM) Nach Ziff. 4.5.2.4 ProdHM besteht Versicherungsschutz für Schadenersatzansprüche wegen „weiterer Vermögensnachteile (z.B. entgangenen Gewinnes), weil die mittels der Maschinen [Steuer-, Mess- und Regeltechnik] des Versicherungsnehmers hergestellten, be- oder verarbeiteten Produkte nicht oder nur mit einem Preisnachlass veräußert werden konnten“. [Zusatz in eckigen Klammern durch Verfasser]

Mit Ausnahme der Quotenklausel, die aus den zuvor bei Ziff. 4.5.2.3 ProdHM genannten sachlichen Gründen nicht mit in den Text der Maschinenklausel aufgenommen worden ist, ist Ziff. 4.5.2.4 ProdHM nahezu wortgleich mit Ziff. 4.2.2.4 ProdHM, weshalb auf die dortigen Ausführungen verwiesen werden kann (Rz. 119 ff.). Diese Klausel ist auf das fehlerhafte Erfassen von Daten nicht anwendbar.

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 13. 2 Stempfle, in: MAH VersicherungsR, § 15 Rz. 212.

Koch

1323

157

O Rz. 158

Einzelprobleme

(5) Produktionsausfall (Ziff. 4.5.2.5 ProdHM) 158

Nach Ziff. 4.5.2.5 ProdHM besteht Versicherungsschutz für Schadenersatzansprüche wegen „der dem Abnehmer des Versicherungsnehmers unmittelbar entstandenen Kosten infolge eines sich aus Mängeln der hergestellten, be- oder verarbeitenden Produkte ergebenden Produktionsausfalles. Ansprüche wegen eines darüber hinausgehenden Schadens durch den Produktionsausfall sind nicht versichert“.

Diese Regelung ist Ziff. 4.2.2.5 ProdHM nachgebildet. Insoweit kann auf die dortigen Ausführungen verwiesen werden (Rz. 124 ff.). Hervorgehoben werden sollen nur noch die spezifischen, auf Ziff. 4.5.2.5 ProdHM bezogenen Fragen. 159

Grundgedanke dieser Regelung ist es, dem Maschinenhersteller/Hersteller von Steuer-, Mess- und Regeltechnik Versicherungsschutz dafür zu gewähren, dass sein Abnehmer mit der Maschine mangelhafte Zwischenprodukte herstellt, die er anschließend nicht mehr weiterverarbeiten kann, und sich hieraus Stillstandskosten ergeben1. Ersetzt werden nur die durch diesen Stillstand unmittelbar verursachten Kosten. Zu diesen Kosten zählen vor allem Lohnkosten und eventuelle Abschreibungen auf die dortigen Maschinen2. Entgangene Gewinne durch Verlust von Marktanteilen oder von Kundenbindungen sind dagegen keine unmittelbare Folge des Produktionsausfalls. Für Schadenersatzansprüche, die auf den Ersatz dieser Schadenpositionen gerichtet sind, besteht kein Versicherungsschutz3. Diese Klausel ist auf das fehlerhafte Erfassen von Daten nicht anwendbar. (6) Mittelbare Schäden (Ziff. 4.5.2.6 ProdHM)

160

Ziff. 4.5.2.6 ProdHM erweitert den Versicherungsschutz für Schadenersatzansprüche wegen „weiterer Vermögensnachteile, weil die mittels der Maschinen [Steuer-, Mess- und Regeltechnik] des Versicherungsnehmers mangelhaft hergestellten, be- oder verarbeiteten Produkte mit anderen Produkten verbunden, vermischt, verarbeitet (Ziff. 4.2) oder weiterverarbeitet oder -bearbeitet (Ziff. 4.3) eingebaut, angebracht, verlegt oder aufgetragen (Ziff. 4.4) werden. Dieser Versicherungsschutz wird im Umfang der vorgenannten Ziff. 4.2 ff. gewährt“. [Zusatz in eckigen Klammern durch Verfasser]

Damit besteht die Möglichkeit für den Versicherungsnehmer, Schäden aus einer weiteren Verarbeitung der maschinell produzierten Erzeugnisse – grundsätzlich somit auch fehlerhaft erfasste Daten – im Umfang der Ziff. 4.2 ff. ProdHM zu versichern4.

1 Vgl. Späte, ProdHM, Rz. 55; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 282. 2 Schmidt-Salzer/Hinsch, Rz. 7.995 f.; Späte, ProdHM Rz. 56; Littbarski, ProdukthaftpflichtV, Ziff. 4 Rz. 284 ff. 3 Schmidt-Salzer/Hinsch, Rz. 7.993; Späte, ProdHM Rz. 56. 4 Vgl. Nickel, in: Kullmann/Pfister, Kza 6926, S. 22; Krause, NVersZ 2001, 103 (106); Thürmann, PHi 2000, 163 (173).

1324

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 165 O

Die Austauschkosten werden über Ziff. 4.5.2.6 ProdHM i.V.m. Ziff. 4.4 161 ProdHM ersetzt. Eine direkte Anwendung der Ziff. 4.2 ff. ProdHM scheitert daran, dass die mittels der mangelhaften Maschine/Steuer-, Mess- und Regeltechnik des Versicherungsnehmers hergestellten Produkte keine Erzeugnisse i.S.d. Ziff. 4.2 ff. ProdHM sind. f) Prüf- und Sortierkosten (Ziff. 4.6 ProdHM) Unter der Voraussetzung, dass

162

„Versicherungsschutz nach den vorangegangen Ziff. 4.2 ff. [besteht]“

verspricht Ziff. 4.6.1 ProdHM Deckung für „gesetzliche Schadenersatzansprüche Dritter wegen der in Ziff. 4.6.2 und 4.6.3 genannten Vermögensschäden infolge der Überprüfung von Produkten auf Mängel, wenn die Mangelhaftigkeit einzelner Produkte bereits festgestellt wurde und auf Grund ausreichenden Stichprobenbefundes oder sonstiger nachweisbarer Tatsachen gleiche Mängel an gleichartigen Produkten zu befürchten sind. Die Überprüfung muss der Feststellung dienen, welche der Produkte mit Mangelverdacht tatsächlich mangelhaft sind und welche der nach den Ziff. 4.2 ff. versicherten Maßnahmen zur Mangelbeseitigung erforderlich sind. Produkte im Sinne dieser Regelung sind solche, die aus oder mit Erzeugnissen des Versicherungsnehmers hergestellt, be- oder verarbeitet wurden.“ (Hervorhebung durch den Verfasser)

Das deckungsauslösende Schadenereignis beurteilt sich gemäß Ziff. 8.2.4 ProdHM nach den für Ziff. 4.2 bis 4.5 ProdHM vorgesehenen Zeitpunkten, je nachdem, mit welcher dieser Deckungsbausteine die in Ziff. 4.6 ProdHM geregelte Überprüfung in Zusammenhang steht. Die Vereinbarung dieses Deckungsbausteins dürfte im Zusammenhang mit 163 der Herstellung von Software nicht weiter interessant sein, da Softwarefehler i.d.R. der ganzen „Serie“ anhaften, so dass eine Einzelüberprüfung nicht erforderlich ist. Auf die Darstellung von Ziff. 4.6 ProdHM wird deshalb verzichtet. 6. Auslandsdeckung (Ziff. 5 ProdHM) Der Versicherungsschutz für Schäden im Ausland ist im ProdHM aus- 164 drücklich offengelassen worden. Zu beachten ist, dass eine für das Betriebs(stätten)risiko vereinbarte Deckung nicht per se für Ansprüche wegen Produkthaftpflichtschäden gilt (Rz. 91 ff.). Insoweit bedarf es einer besonderen Vereinbarung. In der Praxis wird regelmäßig Deckung nach Maßgabe des Mustertarifs zu Grunde gelegt. Auf die dortigen Ausführungen kann deshalb verwiesen werden (Rz. 64 ff.). 7. Risikoabgrenzungen (Ziff. 6 ProdHM) Ziff. 6 ProdHM behandelt unter der Überschrift „Risikoabgrenzungen“ als Oberbegriff sowohl nicht versicherte Tatbestände (Ziff. 6.1 ProdHM) als auch Ausschlusstatbestände (Ziff. 6.2 ProdHM). Ihnen kommt – von weniKoch

1325

165

O Rz. 166

Einzelprobleme

gen Ausnahmen abgesehen – auf Grund der Systematik der Produkthaftpflichtversicherung, die vergleichbar ist mit der im Sachversicherungsrecht bekannten Versicherung gegen benannte Gefahren, vielfach nur deklaratorische Bedeutung zu. Nur soweit nach dem ProdHM grundsätzlich versicherte Vermögensschäden vom Versicherungsschutz ausgenommen werden, liegt ein echter Ausschluss vor. a) Nicht versicherte Tatbestände (Ziff. 6.1 ProdHM) 166

Ziff. 6.1.1 ProdHM ist identisch mit der Erfüllungsausschlussklausel gemäß Nr. 1.2 AHB. Ziff. 6.1.2 ProdHM schließt ferner aus „im Rahmen der Versicherung gemäß Ziff. 4.2 ff. Ansprüche wegen Folgeschäden (z.B. Betriebsunterbrechung oder Produktionsausfall), soweit diese nicht in den Ziff. 4.2 ff. ausdrücklich mitversichert sind“. (Hervorhebung durch den Verfasser)

Hierbei handelt es sich ebenfalls nur um eine klarstellende Regelung, da die versicherten Kosten in den jeweiligen Deckungsbausteinen abschließend benannt sind. Zu beachten ist, dass der Ausschluss auf Schäden infolge von Betriebsunterbrechungen oder Produktionsausfall, die aus einem nach Ziff. 1.1, 4.1 ProdHM gedeckten Sachschaden resultieren, keine Anwendung findet1. b) Ausschlusstatbestände (Ziff. 6.2 ProdHM) aa) Ansprüche aus Garantien oder Haftungserweiterungen (Ziff. 6.2.1 ProdHM) 167

Ausgeschlossen vom Versicherungsschutz sind gemäß Ziff. 6.2.1 ProdHM „Ansprüche aus Garantien oder auf Grund sonstiger vertraglicher Haftungserweiterungen, soweit es sich nicht um im Rahmen der Ziff. 4 versicherte Vereinbarungen bestimmter Eigenschaften von Erzeugnissen, Arbeiten und Leistungen bei Gefahrübergang handelt, für die der Versicherungsnehmer verschuldensunabhängig im gesetzlichen Umfang einzustehen hat“. (Hervorhebung durch den Verfasser)

Will der Versicherungsnehmer Erklärungen zu den Einsatzmöglichkeiten seiner Zulieferprodukte (z.B. zur Kompatibilität der Software) abgeben, sollte er vorher mit dem Versicherer die Abgrenzung zwischen Eigenschaftszusicherung und Garantiezusage abklären. Im Zweifel ist die Einholung einer ausdrücklichen Bestätigung des Versicherers geboten, dass er sich insoweit nicht auf den Ausschluss für selbständige Garantiezusagen berufen wird. bb) Gewährleistung wegen Rechtsmängeln (Ziff. 6.2.2 ProdHM) 168

Kein Versicherungsschutz besteht darüber hinaus für „Ansprüche, die daraus hergeleitet werden, dass gelieferte Sachen oder Arbeiten mit einem Rechtsmangel behaftet sind (z.B. Schäden aus der Verletzung von Paten1 Vgl. Thürmann/Kettler, S. 233.

1326

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 170 O

ten, gewerblichen Schutzrechten, Urheberrechten, Persönlichkeitsrechten, Verstößen in Wettbewerb und Werbung)“. (Hervorhebung durch den Verfasser)

Auch dieser Ausschlussklausel kommt nur klarstellende Funktion zu, weil für die als echte Vermögensschäden zu qualifizierenden Ansprüche wegen eines Rechtsmangels schon nach Maßgabe der Ziff. 4.1 ff. ProdHM kein Versicherungsschutz besteht1. cc) Ansprüche wegen Schäden gemäß Ziff. 7.8 AHB (Ziff. 6.2.3 ProdHM) Gemäß Ziff. 6.2.3 ProdHM sind nicht gedeckt

169

„Ansprüche wegen Schäden gemäß Ziff. 7.8 AHB“. (Hervorhebung durch den Verfasser)

Dieser Ausschluss dient ebenfalls nur der Klarstellung. Insoweit kann auf die Ausführungen zu Ziff. 7.8 AHB verwiesen werden (Rz. 62 f.). Soweit Vermögensschäden nach Maßgabe des ProdHM mitversichert sind, kommt der Ausschluss nicht zum Tragen. dd) Pflichtwidrigkeitsklausel (Ziff. 6.2.4 ProdHM) Der Ausschluss gemäß Ziff. 6.2.4 ProdHM ist demgegenüber konstitutiver Natur. Kein Versicherungsschutz besteht für „Ansprüche gegen den Versicherungsnehmer oder jeden Mitversicherten, soweit diese den Schaden durch bewusstes Abweichen von gesetzlichen oder behördlichen Vorschriften sowie von schriftlichen Anweisungen oder Bedingungen des Auftraggebers herbeigeführt haben“. (Hervorhebung durch den Verfasser)

Die Pflichtwidrigkeitsklausel ist zum Teil weiter als diejenige des Ziff. 7.2 AHB gefasst. Dort ist zur Versagung des Versicherungsschutzes notwendig, dass der Schaden bewusst und gewollt herbeigeführt wird oder bei Lieferung oder Herstellung Kenntnis von der Mangelhaftigkeit oder Schädlichkeit der Waren, Erzeugnissen oder Arbeiten besteht (Rz. 48 ff.). Nach Ziff. 6.2.4 ProdHM reicht hingegen das bewusste Abweichen von Vorschriften, Anweisungen oder Bedingungen aus. Erforderlich ist, dass zwischen Abweichung und Schaden ein Ursachenzusammenhang besteht2. Wie bei Ziff. 7.2 AHB verliert nur derjenige seinen Versicherungsschutz, der bewusst gegen die entsprechenden Bestimmungen verstößt, wobei Verstöße von Repräsentanten und Wissensvertretern dem Versicherungsnehmer zugerechnet werden (Rz. 46, 50 f.)3.

1 Vgl. Stempfle, MAH VersicherungsR, § 15 Rz. 264. 2 Vgl. Produkthaftungshdb./Graf von Westphalen, § 58 Rz. 47; Stempfle, in: MAH VersicherungsR, § 15 Rz. 274; Penner, VersR 2005, 1359 ff. 3 Vgl. Thürmann/Kettler, S. 246; Stempfle, in: MAH VersicherungsR, § 15 Rz. 274; Looschelders, VersR 1999, 666 ff. m.w.N.

Koch

1327

170

O Rz. 171

Einzelprobleme

ee) Erprobungsklausel (Ziff. 6.2.5 ProdHM) 171

Auch bei der Erprobungsklausel (z.T. auch Experimentierklausel genannt) handelt es sich um einen „echten“ Ausschluss. Nach Ziff. 6.2.5 Satz 1 ProdHM sind ausgeschlossen „Ansprüche aus Sach- und Vermögensschäden durch Erzeugnisse, deren Verwendung oder Wirkung im Hinblick auf den konkreten Verwendungszweck nicht nach dem Stand der Technik oder in sonstiger Weise ausreichend erprobt waren“. (Hervorhebung durch den Verfasser)

Die Erprobungsklausel gilt nicht nur für gänzliche Neuentwicklungen, sondern auch für die Weiterentwicklung von Produkten. Ihr Zweck besteht darin, zu verhindern, dass Unternehmen aus Kosten- oder Wettbewerbsgründen Erzeugnisse auf den Markt bringen, ohne sie vorher ausreichend erprobt zu haben1. Die Erprobungsklausel hat in der Vergangenheit mehrfach Änderungen erfahren2. 172

Eine Legaldefinition für den Sicherheitsstandard „Stand der Technik“ findet sich in § 3 Abs. 6 BImSchG: „Stand der Technik im Sinne dieses Gesetzes ist der Entwicklungsstand fortschrittlicher Verfahren, Einrichtungen oder Betriebsweisen, der die praktische Eignung einer Maßnahme zur Begrenzung von Emissionen in Luft, Wasser und Boden, zur Gewährleistung der Anlagensicherheit, zur Gewährleistung einer umweltverträglichen Abfallentsorgung oder sonst zur Vermeidung oder Verminderung von Auswirkungen auf die Urnwelt zur Erreichung eines allgemein hohen Schutzniveaus für die Umwelt insgesamt gesichert erscheinen lässt. Bei der Bestimmung des Standes der Technik sind insbesondere die in der Anlage aufgeführten Kriterien zu berücksichtigen.“

Ob diese seit 2002 geltende Definition, die sich u.a auch in § 3 Ziff. 11 WHG wiederfindet, dem Verständnis des durchschnittlichen Produkthaftpflicht-Versicherungsnehmers entspricht, dürfte zu bezweifeln sein, da sie dem Wortlaut nach auf die Vorsorge gegen schädliche Umwelteinwirkungen gerichtet und kaum einer Verallgemeinerung zugänglich ist. 173

Demgegenüber dürfte die Definition in der bis 2002 geltenden Fassung von § 3 Abs. 6 BImSchG, die allgemeiner gehalten ist und die der Musterbedingungsgeber aufgreifen wollte3, diesem Verständnis entsprechen. Danach ist „Stand der Technik im Sinne dieses Gesetzes [.] der Entwicklungsstand fortschrittlicher Verfahren, Einrichtungen oder Betriebsweisen, der die praktische Eignung einer Maßnahme zur Begrenzung von Emissionen gesichert erscheinen lässt. Bei der Bestimmung des Standes der Technik sind insbesondere vergleichbare Verfahren, Einrichtungen oder Betriebsweisen heranzuziehen, die mit Erfolg im Betrieb erprobt worden sind.“

Um dem Standard Stand der Technik Rechnung zu tragen, muss der Hersteller von Software Programmtests durchführen4. 1 2 3 4

Vgl. Fausten, VersR 1996, 411. Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1851 ff. Vgl. GDV-Rundschreiben H 35/2002 v. 30.7.2002, S. 16. Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1856.

1328

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 176 O

ff) Luftprodukthaftpflicht (Ziff 6.2.6 ProdHM) Keine Deckung besteht gemäß Ziff. 6.2.6 für Ansprüche aus

174

„– Planung oder Konstruktion, Herstellung oder Lieferung von Luft- oder Raumfahrzeugen sowie von Teilen von Luft- oder Raumfahrzeugen, soweit diese Teile im Zeitpunkt der Auslieferung durch den Versicherungsnehmer oder von ihm beauftragte Dritte ersichtlich für den Bau von Luft- oder Raumfahrzeugen sowie den Einbau in Luft- oder Raumfahrzeuge bestimmt waren, – Tätigkeiten (z.B. Montage, Wartung, Inspektion, Überholung, Reparatur, Beförderung) an Luft- oder Raumfahrzeugen sowie Luft- oder Raumfahrzeugteilen“.

Diese Klausel schließt das gesamte Luftprodukthaftpflichtrisiko aus. Soweit der Versicherungsnehmer Software für oder Dienstleistungen an Luft- oder Raumfahrzeugen sowie Teilen davon herstellt oder erbringt, besteht kein Versicherungsschutz für daraus erwachsene Schadenersatzansprüche des Auftraggebers oder eines Dritten. Beispiel1: Der Versicherungsnehmer erhält von einem Flugzeughersteller den Auftrag zur Herstellung von Software für Höhenmessgeräte. Ist diese fehlerhaft, besteht weder für die Ansprüche des Flugzeugherstellers auf Ersatz der Austauschkosten noch für die Ansprüche von Passagieren wegen Personen- und Sachschäden Deckung.

Versicherungsschutz ist jedoch dann gegeben, wenn die Zweckbestimmung 175 aus den gesamten Umständen nicht ersichtlich war. Insoweit kann auf die obigen Ausführungen zum Merkmal der „Ersichtlichkeit“ im Rahmen des Kfz-, Schienen- und Wasserfahrzeugteile-Ausschlusses gemäß Ziff. 4.4.4.2 ProdHM verwiesen werden (Rz. 147 f.). gg) Konzernklausel (Ziff. 6.2.7 ProdHM) Nach Ziff. 6.2.7 ProdHM sind vom Versicherungsschutz ausgeschlossen „Ansprüche wegen Vermögensschäden i.S.v. Ziff. 2.1 AHB, die von Unternehmen, die mit dem Versicherungsnehmer oder seinen Gesellschaften durch Kapital mehrheitlich verbunden sind oder unter einer einheitlichen unternehmerischen Leitung stehen, geltend gemacht werden“.

Diese Klausel soll verhindern, dass der Versicherungsnehmer Produktionszweige oder Abteilungen rechtlich verselbständigt, um auf diese Weise für Schäden Deckungsschutz zu erhalten, die bei einheitlicher Betrachtung des Herstellungsablaufs (oder innerhalb eines Unternehmens ohne diese Strukturen) an sich dem Bereich der internen Wertschöpfung und insoweit als Eigenschäden zu qualifizieren wären2.

1 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 17. 2 Vgl. Stempfle, in: MAH VersicherungsR, § 15 Rz. 292 ff.; Thürmann/Kettler, S. 256 f.

Koch

1329

176

O Rz. 177

Einzelprobleme

8. Versicherungsfall und Serienschaden (Ziff. 8 ProdHM) a) Versicherungsfall (Ziff. 8.2 ProdHM) 177

Ziff. 8.2 ProdHM definiert den Zeitpunkt des Versicherungsfalls gesondert für die einzelnen Deckungsbausteine der Ziff. 4.2 ff. ProdHM. Grundsätzlich tritt gemäß Ziff. 8.2.1–8.2.6 ProdHM der Versicherungsfall jeweils in dem Zeitpunkt ein, in dem das mangelhafte Erzeugnis des Versicherungsnehmers Eingang in den gewerblichen Verwertungsprozess findet und damit die Notwendigkeit entsteht, Maßnahmen zu ergreifen, die von den Ziff. 4.2 ff. ProdHM erfasst werden1. b) Serienschaden (Ziff. 8.3 ProdHM) aa) Standardklausel

178

Das ProdHM enthält standardmäßig eine von Ziff. 6.3 AHB abweichende Serienschadenklausel. Gemäß Ziff. 8.3 ProdHM gelten „[m]ehrere während der Wirksamkeit des Vertrages eintretende Versicherungsfälle – aus der gleichen Ursache, z.B. aus dem gleichen Konstruktions-, Produktionsoder Instruktionsfehler, es sei denn, es besteht zwischen den mehreren gleichen Ursachen kein innerer Zusammenhang, oder – aus Lieferungen solcher Erzeugnisse, die mit den gleichen Mängeln behaftet sind, […] unabhängig von ihrem tatsächlichen Eintritt als in dem Zeitpunkt eingetreten, in dem der erste dieser Versicherungsfälle eingetreten ist“.

(1) Ursachenklausel 179

Abweichend von der AHB-Ursachenklausel (Rz. 41 f.) stellt die ProdHM-Ursachenklausel (1. Spiegelstrich) nicht auf dieselbe, sondern allein auf die gleiche Ursache ab und nimmt zudem durch die exemplarische Nennung von gleichen Konstruktions-, Produktions- oder Instruktionsfehlern eine zusätzliche Konkretisierung möglicher Fehlerarten vor. Zwischen mehreren gleichen Ursachen muss zudem ein innerer Zusammenhang bestehen. Ein solcher ist nur dann zu bejahen, wenn eine Ursache nicht ohne die andere denkbar ist oder alle Ursachen nicht ohne eine gemeinsame dritte Ursache möglich sind2. Als Beispiele hierfür lassen sich Planungsfehler in einem Betriebsteil anführen, die sich dann später bei verschiedenen Produktionsvorgängen in den einzelnen Betriebsstätten auswirken3. An einem inneren Zusammenhang soll es demgegenüber fehlen, soweit die gleiche Schadenursache nur rein zufällig gesetzt wird, etwa wenn ein Mitarbeiter des Versicherungsnehmers bei der Kontrolle eines Erzeugnisses dessen Mängel übersieht und ein anderer Mitarbeiter durch Zufall den gleichen Fehler begeht4. 1 2 3 4

Stempfle, in: MAH VersicherungsR, § 15 Rz. 313. Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 13; Thürmann/Kettler, S. 272 f. Vgl. Späte, ProdHM, Rz. 81; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 14. Vgl. Späte, ProdHM, Rz. 81; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 14.

1330

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 182 O

(2) Warenklausel Abweichend von der AHB-Warenklausel (Rz. 43) stellt die ProdHM-Waren- 180 klausel nicht auf Lieferungen der gleichen mangelhaften Waren ab, sondern auf Lieferungen solcher Erzeugnisse, die mit den gleichen Mängeln behaftet sind. Entscheidend ist somit die Gleichheit des Mangels der gelieferten Erzeugnisse, während die Erzeugnisse selbst durchaus verschiedenartig sein können. Auch müssen die durch die Mängel eingetretenen Schäden nicht gleichartig sein und können daher auch bei verschiedenen Personen oder Sachen entstehen1. Auf einen irgendwie gearteten Zusammenhang zwischen den Mängeln kommt es nicht an2. (3) Kontraktionswirkung Ziff. 8.3 ProdHM fingiert, dass mehrere Schadenereignisse aus bestimmten 181 Ursachen in dem Zeitpunkt eingetreten sind, in dem das erste dieser Ereignisse eingetreten ist, ohne dass sie zu einem Ereignis verklammert werden. Die ProdHM-Serienschadenklausel enthält also nur eine zeitliche Fiktion und keine Kontraktion auf ein Schadenereignis3. Dies hat für den Versicherungsnehmer den Vorteil, dass sich der Umfang des Versicherungsschutzes nicht an der für ein einzelnes Schadenereignis zur Verfügung stehenden Deckungssumme nach Ziff. 9.1 ProdHM orientiert (Rz. 184), sondern an der nach Ziff. 9.2 ProdHM festgelegten Jahreshöchstleistung (Maximierung) (Rz. 184), die sich auf ein Mehrfaches der für ein einzelnes Schadenereignis zur Verfügung stehenden Deckungssumme beläuft (zumeist doppelte Maximierung), und zwar desjenigen Jahres, in dem das erste dieser Ereignisse eingetreten ist4. Für Serienschäden, die während der Wirksamkeit des Vertrags eintreten, besteht nach h.M. Versicherungsschutz auch dann, soweit sie erstmalig vor Beginn des Versicherungsvertrags aufgetreten sind5. Hat der Versicherungsnehmer Kenntnis von den vor Abschluss des Vertrages eingetretenen Schäden, kann der Versicherer ggf. vom Vertrag zurücktreten und Leistungsfreiheit geltend machen (§§ 19, 21 VVG). bb) Alternativklausel Da Ziff. 8.3 ProdHM nur eine zeitliche Fiktion und keine Kontraktion auf 182 ein Schadenereignis enthält, bleiben die Serienteilschäden einzelne Schadenereignisse. Das bedeutet aber, dass eine außerordentliche Kündigung des Versicherungsvertrags gemäß Ziff. 19 AHB sowohl für den Versicherer als auch für den Versicherungsnehmer nach einer Entschädigungsleistung mög1 2 3 4 5

Vgl. Späte, ProdHM, Rz. 82; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 16. Vgl. Späte, ProdHM, Rz. 82; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 15. Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 17; Thürmann/Kettler, S. 275. Vgl. Späte, ProdHM, Rz. 83; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 17. Vgl. Meyer-Kahlen, VersR 1976, 8 (10); Späte, ProdHM, Rz. 85; Thürmann/Kettler, S. 275; a.A. Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 19; Stempfle, in: MAH VersicherungsR, § 15 Rz. 292 ff.

Koch

1331

O Rz. 183

Einzelprobleme

lich ist1. Vor allem um diese Gefahr zu vermeiden, wurde folgende Alternativklausel geschaffen, die gegenüber den bisherigen Serienschadenklauseln eine zeitliche Verklammerung der Serienteilschäden vorsieht2: „Mehrere Versicherungsfälle – aus der gleichen Ursache, z.B. aus dem gleichen Konstruktions-, Produktionsoder Instruktionsfehler, es sei denn, es besteht zwischen den mehreren gleichen Ursachen kein innerer Zusammenhang, oder – aus Lieferungen solcher Erzeugnisse, die mit den gleichen Mängeln behaftet sind (Serie), gelten unabhängig von ihrem tatsächlichen Eintritt als ein Versicherungsfall und in dem Zeitpunkt eingetreten, in dem der erste dieser Versicherungsfälle eingetreten ist. Teilweise abweichend von § 1 Ziff. 1 AHB bezieht sich die zeitliche Geltung des Versicherungsschutzes ausschließlich auf Versicherungsfälle solcher Serien, deren erster Versicherungsfall während der Wirksamkeit der Versicherung eingetreten ist, aber auch auf alle Versicherungsfälle dieser Serie.“

183

Die Erweiterung des Versicherungsschutzes gegenüber der Standardklausel besteht darin, dass eine einmal gedeckte Serie versichert bleibt, auch wenn der Versicherungsvertrag beendet wird3. Unerheblich ist die Art der Beendigung des Vertrags. Die Kontraktion zu einem Schadenereignis hat jedoch zur Folge, dass keine Eintrittspflicht des Versicherers besteht, wenn das erste Schadenereignis vor dem Versicherungszeitraum liegt. Ferner ist die Eintrittspflicht begrenzt durch die Deckungssumme je Versicherungsfall (und nicht – wie bei der Serienschadenklausel nach Ziff. 8.1 ProdHM – durch die Jahreshöchstersatzleistung)4. Der Deckungsumfang bestimmt sich nach dem Zeitpunkt des Eintritts des ersten Versicherungsfalls5. 9. Versicherungssumme, Maximierung und Selbstbehalt (Ziff. 9 ProdHM) a) Versicherungssumme (Ziff. 9.1 ProdHM)

184

Entsprechend der Regelung gemäß Ziff. 9.1 ProdHM werden in der Praxis unterschiedliche Versicherungssummen für Personenschäden einerseits und – kombiniert – Sach- und Vermögensschäden andererseits bestimmt. b) Maximierung (Ziff. 9.2 ProdHM)

185

Die gemäß Ziff. 9.2 ProdHM vorgesehene Begrenzung der Höchstersatzleistung für alle Versicherungsfälle eines Versicherungsjahres (Maximierung) dient der Risikobeschränkung und -kalkulierung für den Versicherer. In der Praxis erlangt sie vor allem Bedeutung bei Serienschäden. 1 Vgl. Prölss/Martin/Voit, ProdHaftPfl Ziff. 8 Rz. 5; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 19. 2 Vgl. GDV-Rundschreiben H 35/2002 M v. 30.7.2002, S. 19 f. 3 Vgl. Späte, ProdHM, Rz. 87; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 22. 4 Vgl. Späte, ProdHM, Rz. 87; Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 22. 5 Vgl. Stempfle, in: MAH VersicherungsR, § 15 Rz. 317.

1332

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 188 O

c) Selbstbehalt (Ziff. 9.3 ProdHM) Ziff. 9.3 Satz 1 ProdHM bestimmt, dass sich der Versicherungsnehmer bei 186 jedem Versicherungsfall an den versicherten Schäden in einer bestimmten Höhe selbst zu beteiligen hat. Davon ausgenommen sind Serienschäden i.S.v. Ziff. 8.3 ProdHM. Vor dem Hintergrund, dass Serienteilschäden als einzelne Schadenereignisse behandelt werden und der Versicherungsnehmer im Falle einer Serie den Selbstbehalt somit so oft zu tragen hätte, wie einzelne Versicherungsfälle eingetreten wären, sieht Ziff. 9.3 ProdHM vor, den Selbstbehalt auf einen bestimmten Betrag zu begrenzen. Zur Höhe des vereinbarten Selbstbehalts lassen sich allgemeine Aussagen nur schwer treffen. Wie bei der Festlegung der Deckungssumme steht die Bemessung des Selbstbehalts in unmittelbarem Zusammenhang mit der individuellen Risikoanalyse und der betriebswirtschaftlichen Frage nach der Höhe tragbarer Versicherungskosten1. 10. Bewertung des Versicherungsschutzes für Softwarehäuser Im Vergleich zum Mustertarif bringt das ProdHM insoweit eine deutliche 187 Verbesserung des Versicherungsschutzes mit sich, als Schadenersatzansprüche infolge des Fehlens vereinbarter Eigenschaften mitversichert sind. Die Unsicherheiten, die sich aus dem Fehlen gesetzlicher Vorgaben und eindeutiger höchstrichterlicher Entscheidungen zur Sachqualität von Daten ergeben, werden jedoch nicht beseitigt. Soweit Deckung für Vermögensschäden versprochen wird, birgt die Subsumtion softwarebezogener Schadensachverhalte unter die einzelnen Bausteine gemäß Ziff. 4.2–4.5 ProdHM Schwierigkeiten in sich. Entsprechend der Zielsetzung des ProdHM werden schließlich in erster Linie fehlgeschlagene Aufwendungen und der entgangene Gewinn nachfolgender Produzenten ersetzt. Bei fehlerhafter Software drohen aber weit darüber hinausgehende Folgeschäden, da die durch den Einsatz der Software generierten Daten die Grundlage für andere IT-Anwendungen und Entscheidungsprozesse bilden.

IV. Versicherungsschutz nach Maßgabe der BBR IT-Dienstleister 1. Adressatenkreis der BBR IT-Dienstleister Bereits im Jahre 2001 hatte der GDV die Besonderen Bedingungen und 188 Risikobeschreibungen für die Haftpflichtversicherung von Softwarehäusern (BBR Software) unverbindlich zur Anwendung empfohlen, die erstmals auf AHB-Basis eine „offene“ Vermögensschadendeckung vorsahen2. Die BBR Software waren allerdings ausschließlich auf das reine Softwarehaus mit seinen typischen Annextätigkeiten zugeschnitten. Der Bereich des Internet1 Vgl. Littbarski, ProdukthaftpflichtV, Ziff. 8 Rz. 33 ff. 2 Vgl. GDV-Rundschreiben H 14/01 M v. 15.3.2001.

Koch

1333

O Rz. 189

Einzelprobleme

Providings blieb ausgeklammert. In einem zweiten Schritt hat der GDV die BBR Software zu einem umfassenden IT-Versicherungsmodell erweitert, das die Bezeichnung Besondere Bedingungen und Risikobeschreibungen für die Haftpflichtversicherung von IT-Dienstleistern (BBR IT-Dienstleister) trägt. Diese umfassen auch die Risiken aus Herstellung und Handel von Hardware neben den hier nicht näher interessierenden Risiken aus dem InternetProviding. Der GDV hebt in seinen Erläuterungen zu den BBR IT-Dienstleister jedoch immer wieder hervor, dass diese Bedingungen nicht für den „reinen“ Hersteller oder Händler konzipiert seien1. Der Handelsbereich sei letztlich nur aufgenommen worden, um den Tätigkeitsbereich eines Softwarehauses ganzheitlich zu erfassen, z.B. wenn die Lieferung und der Einbau einer größeren Festplatte oder eines leistungsfähigeren Arbeitsspeichers beim Kunden erfolgt. Die BBR IT-Dienstleister folgen in ihrer Struktur den üblichen Betriebshaftpflichtversicherungspolicen, indem sie zwischen dem Betriebs(stätten)-, Produkt-/Leistungs- und Umweltrisiko trennen und diesen Bereichen einen allgemeinen Teil voranstellen. 2. Allgemeine Vereinbarungen (Ziff. 1) a) Versichertes Risiko (Ziff. 1.1.1–1.1.3) 189

Für gewöhnlich gibt die für das versicherte Risiko maßgebliche Beschreibung des zu versichernden Unternehmens nicht den kompletten Tätigkeits-/Produktionsbereich wieder. Die BBR IT-Dienstleister weichen von dieser Praxis insoweit ab, als sie die versicherten Tätigkeiten im Einzelnen abschließend umschreiben und katalogisieren2. aa) Softwarebezogene Dienstleistungen

190

Gemäß Ziff. 1.1.1 besteht Versicherungsschutz für die typischen Softwarehaustätigkeiten, nämlich „– Software-Erstellung, -Handel, -Implementierung, -Pflege; – IT -Analyse, -Organisation, -Einweisung, -Schulung; – Netzwerkplanung, -installation, -integration, -pflege; und alle damit verbundenen Beratungsleistungen.“

bb) Providertätigkeiten 191

Daneben besteht Versicherungsschutz gemäß Ziff. 1.1.2 auch für die Tätigkeit als Provider für „– die Zugangsvermittlung ins Internet (z.B. Access Providing); – das Bereithalten fremder Inhalte (z.B. Host Providing);

1 Vgl. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 5. 2 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2438 ff.; Versicherungsrechtshdb./Spindler, § 40 Rz. 64 ff.

1334

Koch

Rz. 194 O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

– das Bereithalten eigener Inhalte (z.B. Content Providing), jedoch nur für Personen- und Sachschäden“.

Nur bei gesonderter Vereinbarung besteht Versicherungsschutz für das ZurVerfügung-Stellen von Anwendungsprogrammen, auf die über das Internet zugegriffen werden kann (Application Service Providing) sowie den Betrieb von Rechenzentren und Datenbanken. cc) Hardwarebezogene Dienstleistungen Gemäß Ziff. 1.1.3 besteht ferner Versicherungsschutz für

192

„Hardware-Handel, -Modifizierung (Nachrüstung), -Installation, -Wartung und alle damit verbundenen Beratungsleistungen

sowie – falls besonders vereinbart – für – –

Hardware-Herstellung; Herstellung und Handel von/mit Mess-, Steuer- und Regeltechnik.“

Nachstehend wird nur die Deckung, die für die Tätigkeiten von Softwarehäusern relevant ist, d.h. für die software- und mitversicherten hardwarebezogenen Risiken untersucht. Der Versicherungsschutz für Risiken aus Provider-Tätigkeiten (Ziff. 3.2, 3.4.2.1) bleibt ausgeklammert. b) Versicherte Schadenarten (Ziff. 1.1 Abs. 1–4) aa) Personen- und Sachschäden Versichert ist die gesetzliche Haftpflicht für Personen- und Sachschäden 193 und daraus entstandene weitere Schäden. Schäden Dritter durch Löschung, Beschädigung oder Beeinträchtigung der Ordnung von Daten Dritter und alle sich daraus ergebenden Vermögensschäden (Datenschäden), werden wie Sachschäden behandelt (vgl. Ziff. 1.5.2.1, 1.5.2.2, 3.3.2). bb) Vermögensschäden Hinsichtlich der Deckung für (echte) Vermögensschäden treffen die BBR IT- 194 Dienstleister in Ziff. 1.1 Abs. 2 und 3 eine differenzierte Regelung, die an die in den Ziff. 1.1.1 und 1.1.3 katalogisierten Tätigkeiten anknüpft. Für Vermögensschäden infolge fehlerhafter Erbringung der in Ziff. 1.1.1 genannten softwarebezogenen Dienstleistungen besteht gemäß Ziff. 3.3 eine umfassende Deckung. Diese erstreckt sich auch auf die Verletzung von Datenschutzgesetzen und Persönlichkeitsrechten. Für hardwarebezogene Tätigkeiten i.S.v. Ziff. 1.1.3 besteht in Anlehnung an das ProdHM nur ausschnittsweise Deckung für Vermögensschäden, und zwar für Aus- und Einbaukosten (Ziff. 3.3.4) und Schäden durch Steuerungselemente (Ziff. 3.3.5) sowie ebenfalls aus der Verletzung von Datenschutzgesetzen und Persönlichkeitsrechten.

Koch

1335

O Rz. 195

Einzelprobleme

c) Mitversicherte Personen (Ziff. 1.2) 195

Der Kreis der mitversicherten Personen entspricht dem gemäß Ziff. 7.1.2.3, 7.1.2.4 Muster-Bedingungsstruktur AT (Rz. 10), Ziff. 2 ProdHM (Rz. 103). d) Versicherungssummen/Maximierung (Ziff. 1.4)

196

Die BBR IT-Dienstleister sehen – wie das ProdHM – eine Kombination von Versicherungssummen für Personen- und sonstige Schäden (Sach- und Vermögensschäden) vor. Für Daten- und Tätigkeitsschäden i.S.v. Ziff. 1.5.2 bestimmt Ziff. 1.4 Abs. 3, dass die hierfür gesondert vereinbarten Versicherungssummen nicht separat, sondern innerhalb der Versicherungssumme für Sach- und Vermögensschäden zur Verfügung stehen. Daher ist für solche Schäden ein Sublimit vorgesehen. e) Erweiterungen des Versicherungsschutzes (Ziff. 1.5)

197

Ziff. 1.5 enthält Erweiterungen des Versicherungsschutzes für IT-Dienstleister, die nicht nur für das Betriebs(stätten)risiko, sondern auch für das Produkt-/Leistungsrisiko bedeutsam sind. aa) Auslandsschäden (Ziff. 1.5.1)

198

Der Auslandsschädenausschluss wird in der herkömmlichen Betriebshaftpflichtversicherung regelmäßig abbedungen und durch Ziff. 7.7 Muster-Bedingungsstruktur AT ersetzt, die zwischen direkten und indirekten Exporten unterscheidet (Rz. 66). Die Regelungen zur Deckung von Auslandsschäden in den BBR IT-Dienstleister knüpfen ebenfalls an diese Differenzierung an und treffen zudem eine Sonderregelung für Schadenfälle aus abgerufener oder zum Download angebotener fehlerhafter Software sowie Reparatur-, Wartungs- und Pflegearbeiten. Diese Sonderregelung soll hier näherer Betrachtung unterzogen werden. (1) Zurverfügungstellung von Daten zum Herunterladen

199

Ziff. 1.5.1.1 lit. d) erfasst die Fälle, in denen der Versicherungsnehmer den Abruf von Daten (z.B. Downloading über das Internet) ermöglicht. Der Versicherungsschutz hängt – abweichend von Ziff. 7.7 Muster-Bedingungsstruktur AT – allein davon ab, dass der Versicherungsfall, also das Schadenereignis, im europäischen Ausland eingetreten ist. Daraus ergeben sich die folgenden Fallkonstellationen1: – Datenabruf in Deutschland und Weiterleitung durch Erwerber/Nutzer ins europäische Ausland, Schadenfall in Europa: fi Versicherungsschutz besteht;

1 S. Rundschreiben des GDV H 37/02 M v. 1.8.2002, S. 8.

1336

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 202 O

– Datenabruf in Deutschland und Weiterleitung durch Erwerber/Nutzer ins nichteuropäische Ausland, Schadenfall außerhalb Europas: fi Versicherungsschutz besteht nicht; – Datenabruf im europäischen Ausland, Schadenfall in Europa: fi Versicherungsschutz besteht; – Datenabruf im europäischen Ausland und Weiterleitung durch Erwerber/ Nutzer ins nichteuropäische Ausland, Schadenfall außerhalb Europas: fi Versicherungsschutz besteht nicht; – Datenabruf im nichteuropäischen Ausland, Schadenfall außerhalb Europas: fi Versicherungsschutz besteht nicht; – Datenabruf im nichteuropäischen Ausland und Weiterleitung durch Erwerber/Nutzer ins europäische Ausland, Schadenfall in Europa: fi Versicherungsschutz besteht. Will der Versicherungsnehmer seine Haftpflicht für Versicherungsfälle im 200 außereuropäischen Ausland durch zur Verfügung gestellte Daten versichern, bedarf es einer besonderen Vereinbarung. Dies gilt in gleicher Weise für im Ausland gelegene Betriebsstätten, z.B. Produktions- oder Vertriebsniederlassungen sowie für eine Erweiterung des nichtdatenabrufspezifischen Export-, Arbeits- oder Leistungsrisikos auf Länder außerhalb Europas. (2) Reparatur-, Wartungs- und Pflegearbeiten Nach Ziff. 1.5.1.1 lit. e) ist eingeschlossen die gesetzliche Haftpflicht des Versicherungsnehmers wegen Versicherungsfällen

201

„im Ausland aus in Europa durchgeführten Reparatur-, Wartungs- und Pflegearbeiten (auch Inspektion, Kundendienst und Fernwartung/-pflege, Letzteres auch abweichend von lit. d).“

Anders als in Ziff. 1.5.1.1 lit. d) ist hier nicht erforderlich, dass der Versicherungsfall im europäischen Ausland eingetreten ist. Dies gilt ausweislich des Klammerzusatzes ausdrücklich auch für die Fernwartung oder -pflege. Spielt der Versicherungsnehmer eine Software-Aktualisierung innerhalb Europas auf, sind somit auch die dadurch außerhalb Europas eintretenden Schäden gedeckt. (3) Auslandsdeckungsspezifische Ausschlüsse Ziff. 1.5.1.2 enthält die bereits aus der Muster-Bedingungsstruktur AT und 202 dem ProdHM bei Mitversicherung der Auslandsschäden bekannten Ausschlüsse von Ansprüchen nach den Art. 1792 ff. und 2270 des französischen Code Civil oder gleichartiger Bestimmungen anderer Länder (lit. c) sowie auf Entschädigung mit Strafcharakter, insbesondere „punitive damages“ (lit. b) (Rz. 70).

Koch

1337

O Rz. 203

Einzelprobleme

(4) Anrechnung von Kosten auf die Versicherungssumme 203

Entsprechend den Regelungen der Muster-Bedingungsstruktur ATs und des ProdHM werden nach Ziff. 1.5.1.4 bei Versicherungsfällen in den USA/USTerritorien und Kanada Aufwendungen des Versicherers für Kosten als Leistungen auf die Versicherungssumme angerechnet. Ziff. 1.5.1.4 sieht folgende Selbstbeteiligungsregelung vor: „Selbstbeteiligung des VN an jedem Schaden: … %, mindestens … Euro, höchstens … Euro Kosten gelten als Schadenersatzleistungen.“

Die Formulierung „Kosten gelten als Schadenersatzleistung“ hat zur Folge, dass der Selbstbehalt vom Versicherungsnehmer auch bei erfolgreicher Anspruchsabwehr zu tragen ist1. bb) Daten- und Tätigkeitsschäden (Ziff. 1.5.3) 204

Gegenstand von Ziff. 1.5.3 sind Datenschäden und Tätigkeitsschäden. Obgleich auf Grund möglicher Schadenbilder eine enge Verknüpfung zwischen ihnen besteht, behandeln die BBR IT-Dienstleister sie getrennt. (1) Datenschäden

205

Gemäß Ziff. 1.5.3.1 ist eingeschlossen die gesetzliche Haftpflicht des Versicherungsnehmers „aus Schäden Dritter durch Löschung, Beschädigung oder Beeinträchtigung der Ordnung von Daten Dritter und alle sich daraus ergebenden Vermögensschäden, die vor Abschluss der Arbeiten und der Ausführung der sonstigen IT-Leistungen eintreten. Derartige Schäden werden wie Sachschäden behandelt.“ (Hervorhebung durch den Verfasser)

Ziff. 1.5.3.1 betrifft nur die Versicherung von Datenschäden vor Abschluss der Arbeiten und/oder Ausführung sonstiger IT-Leistungen. Beispiel: Der Versicherungsnehmer installiert bei einem Architekten eine Baudatenbank. Als er feststellt, dass der vorhandene Speicher nicht ausreichen wird, spricht er mit Mitarbeitern des Architekten die Löschung von Daten auf der Festplatte ab. Anstelle der Daten auf der Festplatte löscht er aber versehentlich Daten auf einem externen Datenspeicher, auf dem der gesamte Schriftverkehr und alle Ausschreibungen des Architektenbüros gespeichert waren. Für die daraus resultierenden Schäden besteht Deckung im Umfang von Ziff. 1.5.3.5.

206

Für Datenschäden nach Abschluss der Arbeiten oder Ausführung sonstiger IT-Leistungen besteht Versicherungsschutz nach Maßgabe der Versicherung des Produkt-/Leistungsrisikos gemäß Ziff. 3.3.1, 3.3.3, 3.3.4 und 3.3.5 (Rz. 228 ff.). Diese Differenzierung ist insoweit von Bedeutung, als für Datenschäden vor Abschluss der Arbeiten, also im Rahmen des Betriebs(stätten)risikos gemäß Ziff. 1.5.3.5 ein Sublimit sowie ein Selbstbehalt vorgesehen ist, während für Schäden im Bereich des Produkt-/Leistungsrisikos nur 1 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2471.

1338

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 207 O

ein Selbstbehalt und kein Sublimit besteht. Eine Abgrenzung zwischen Schäden vor und nach Abschluss der Arbeiten und Ausführung der Leistungen kann somit auch bei den BBR IT-Dienstleistern erforderlich werden. (2) Tätigkeitsschäden Ziff. 1.5.3.2 betrifft Tätigkeitsschäden und trägt der besonderen Risikositua- 207 tion eines Softwarehauses Rechnung. Abweichend von Ziff. 7.7 AHB besteht Versicherungsschutz für die gesetzliche Haftpflicht aus Schäden an fremden Sachen (auch Daten) und allen sich daraus ergebenden Vermögensschäden, wenn „– die Schäden durch Installations- und Implementierungsarbeiten oder eine sonstige gewerbliche oder berufliche Tätigkeit des Versicherungsnehmers an diesen Sachen (auch Daten) entstanden sind; bei unbeweglichen Sachen gilt diese Regelung nur insoweit, als diese Sachen oder Teile von ihnen unmittelbar von der Tätigkeit betroffen waren; – die Schäden dadurch entstanden sind, dass der Versicherungsnehmer diese Sachen (auch Daten) zur Durchführung von Installations- und Implementierungsarbeiten oder einer sonstigen gewerblichen oder beruflichen Tätigkeit benutzt hat; bei unbeweglichen Sachen gilt diese Regelung nur insoweit, als diese Sachen oder Teile von ihnen unmittelbar von der Benutzung betroffen waren; – die Schäden durch Installations- oder Implementierungsarbeiten oder durch eine gewerbliche oder berufliche Tätigkeit des Versicherungsnehmers entstanden sind und sich diese Sachen (auch Daten) oder – sofern es sich um unbewegliche Sachen handelt – deren Teile im unmittelbaren Einwirkungsbereich der Tätigkeit befunden haben.“ Beispiele1: 1) Der Versicherungsnehmer hat den Auftrag, bei einem Steuerberater eine neue Software zu installieren. Beim Umsetzen eines Bildschirms kommt es zu Beschädigungen an der Hardware (Bildschirm, PC, Tastatur o.Ä.) des Steuerberaters. Daten werden dabei nicht beschädigt. Da es sich hierbei um Schäden an fremden Sachen handelt, sind derartige Schäden im Umfang von Ziff. 1.5.3.5 versichert. 2) Während einer Software-Implementierung wird versehentlich vom Versicherungsnehmer ein Datenträger seines Auftraggebers beschädigt. Gleichzeitig werden die Daten auf dem Datenträger zerstört. Auch dieser Schaden am Datenträger inklusive der Schäden an den Daten bzw. die Wiederherstellung dieser Daten sind im Umfang von Ziff. 1.5.3.5 gedeckt. 3) Der Versicherungsnehmer hat die Aufgabe, ausschließlich die Postleitzahlen-Dateien eines Inkassobüros zu bearbeiten. Durch ein Missverständnis bearbeitet er auch die Dateien, in denen die Kontoverbindungen der Auftraggeber des Inkassobüros gespeichert sind und verändert diese versehentlich. Als am Monatsende das Inkasso durchgeführt werden soll, wird die Datenveränderung festgestellt. Die Kosten zur Wiederherstellung der Daten werden im Umfang von Ziff. 1.5.3.5 reguliert. Ein etwaiger Betriebsunterbrechungsschaden wäre ebenfalls im Rahmen der Ziff. 1.5.3.2 versichert.

1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 8.

Koch

1339

O Rz. 208 208

Einzelprobleme

Abweichend vom Versicherungsschutz für Datenschäden i.S.v. Ziff. 1.5.3.1 bestimmt sich der Umfang der Deckung für Tätigkeitsschäden unabhängig davon, ob sie vor Abschluss der Arbeiten oder der Ausführung sonstiger ITLeistungen eingetreten sind, nach Ziff. 1.5.3.5. Insoweit weichen die BBR IT-Dienstleister von der Produkthaftpflichtversicherung ab, die Tätigkeitsspätschäden (vgl. Ziff. 1.2 ProdHM) dem Produkt-/Leistungsrisiko zuweist. Die damit verbundene Schlechterstellung im Vergleich zur Produkthaftpflichtversicherung (Sublimit und Selbstbeteiligung) sieht der GDV durch das Schadenpotenzial als gerechtfertigt an, das beim Tätigwerden im Betrieb des Auftraggebers durch leichte Fehlbedienungen oder Unachtsamkeiten entstehen kann1. (3) Daten- und tätigkeitsschädenspezifische Ausschlüsse

209

Die Regelungen in Ziff. 1.5.3.3 und 1.5.3.4 enthalten Ausschlüsse vom Versicherungsschutz für Daten- und Tätigkeitsschäden. Ziff. 1.5.3.2 bestimmt, dass die Ausschlussbestimmungen gemäß Nr. 1.2 AHB (Erfüllungsansprüche und -surrogate) (Rz. 26 f.) und Nr. 7.8 (Schäden an hergestellten oder gelieferten Arbeiten oder Sachen) (Rz. 62 f.) bestehen bleiben. Hierbei handelt es sich nur um eine Klarstellung, da die AHB grundsätzlich neben den BBR ITDienstleister gelten und die in den AHB vorgesehenen Leistungsausschlüsse – soweit sie nicht abbedungen sind – ohnehin eingreifen. Freilich ist die Relevanz dieser Ausschlüsse für die nach Ziff. 1.5.3.1 und 1.5.2.2 versicherten Schäden nicht erkennbar. Ziff. 1.5.3.4 schließt Ansprüche aus wegen „– der Beschädigung von Sachen (auch Daten) gemäß Ziff. 1.5.2.22, die sich beim Versicherungsnehmer zur Reparatur oder zu sonstigen Zwecken befinden oder von ihm übernommen wurden; – der Beschädigung der Ladung von Fahrzeugen und Containern durch/oder beim Be- und Entladen; – Be- und Entladeschäden i.S. von Ziff. 1.5.33.“

Der Ausschluss des 1. Spiegelstrichs ist eine Erweiterung der Besitzklausel i.S.v. Ziff. 7.6 AHB. (4) Sublimit und Selbstbeteiligung 210

Wie zuvor angesprochen, begrenzt Ziff. 1.5.3.5 die Höchstersatzleistung für Daten- und Tätigkeitsschäden. Die Versicherungssumme für Sach- und Vermögensschäden beträgt „je Versicherungsfall … Euro. Die Gesamtleistung für alle Versicherungsfälle eines Versicherungsjahres beträgt das Doppelte dieser Versicherungssumme. Selbstbeteiligung des Versicherungsnehmers an jedem Schaden: … %, mindestens … Euro, höchstens … Euro.“

Zumindest für Schadenfälle vor Abschluss der Arbeiten oder Ausführung der Leistungen bedarf es keiner Abgrenzung zwischen Ziff. 1.5.3.1 oder 1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 8. 2 Anm. des Verfassers: gemeint ist wohl 1.5.3.2. 3 Anm. des Verfassers: gemeint ist wohl 1.5.4.

1340

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 213 O

1.5.3.2, da hinsichtlich der Ersatzleistung und des Selbstbehalts einheitliche Regelungen gelten1. Unbeantwortet bleibt die Frage nach dem Verhältnis zwischen den Regelungen gemäß Ziff. 1.5.3.5 und Ziff. 1.5.1.4, soweit ein nach Ziff. 1.5.1 gedeckter Auslandsschaden in den USA oder Kanada eintritt. Diese Frage ist insbesondere dann von Bedeutung, wenn unterschiedlich hohe Sublimits und/oder Selbstbehalte vereinbart werden. cc) Vermögensschäden aus der Verletzung von Datenschutzgesetzen und Persönlichkeitsrechten (Ziff. 1.5.5) (1) Umfang des Versicherungsschutzes Gemäß Ziff. 1.5.5 besteht Versicherungsschutz wegen Vermögensschäden

211

„– aus der Verletzung von Datenschutzgesetzen durch Missbrauch personenbezogener Daten und – der Verletzung von Persönlichkeitsrechten und Namensrechten“.

Das gilt auch für derartige Schäden aus dem Bereithalten eigener Inhalte (z.B. Content Providing). Die Regelung des 1. Spiegelstrichs knüpft an die Haftung für die Verletzung von Datenschutzgesetzen durch den Missbrauch personenbezogener Daten an und entspricht der Mitversicherung von Vermögensschäden in der herkömmlichen Betriebshaftpflichtversicherung (Rz. 11). Die Regelung des 2. Spiegelstrichs geht darüber hinaus, da sie allgemein De- 212 ckung für Ansprüche wegen Verletzung von Persönlichkeitsrechten verspricht. Hierzu zählen nicht nur das nach § 823 Abs. 1 BGB als sonstiges Recht geschützte allgemeine Persönlichkeitsrecht, das auch das Recht auf informationelle Selbstbestimmung umfasst, sondern auch die besonderen Persönlichkeitsrechte wie z.B. – das Namensrecht gemäß § 12 BGB für den privaten Bereich, §§ 14, 15 MarkenG für den gewerblichen Bereich, – das Recht am eigenen Bild (§ 22 KUG), – die Ehre, der Ruf des von der Äußerung Betroffenen durch Beleidigung, üble Nachrede oder Verleumdung (§ 823 Abs. 2 BGB i.V.m. §§ 185 ff. StGB), – der Angriff auf die Kreditwürdigkeit (§ 824 BGB), – das vertraulich gesprochene Wort (§ 201 StGB), – Privat- und Geschäftsgeheimnisse (§ 203 StGB, § 17 UWG). (2) Persönlichkeitsrechtsspezifische Ausschlüsse Ausgeschlossen bleiben bei Persönlichkeitsrechtsverletzungen

213

„– Ansprüche hinsichtlich Auskunft, Berichtigung, Sperrung und Löschung von Daten sowie der hiermit zusammenhängenden Verfahrenskosten; 1 In der Praxis beläuft sich die Selbstbeteiligung zumeist auf 10 %, höchstens 5 000 Euro.

Koch

1341

O Rz. 214

Einzelprobleme

– Bußgelder, Strafen und Kosten derartiger Verfahren sowie Strafvollstreckungskosten; – Ansprüche wegen Schäden aus der Diskriminierung oder Belästigung durch den Versicherungsnehmer, einen Mitversicherten oder eine von ihnen bestellte oder beauftragte Person während der Aufnahme, dem Bestehen oder der Beendigung von Arbeitsverhältnissen.“ (Fettdruck durch den Verfasser)

Die Regelungen des 1. und 2. Spiegelstrichs beziehen sich vornehmlich auf Ansprüche wegen Verletzung von Datenschutzgesetzen (§§ 33–35, 43, 44 BDSG). Ihnen kommt lediglich klarstellende Funktion zu, da die BBR ITDienstleister nur Deckung für Schadenersatzansprüche versprechen. Der Ausschluss des 3. Spiegelstrichs erfasst die sog. EPL (= Employer’s Practices Liability)-Ansprüche. f) Ausschlüsse (Ziff. 1.7) 214

Ziff. 1.7 enthält nicht schadenspezifische, sondern allgemeine Ausschlüsse, die sowohl für das Betriebs(stätten)- als auch das Produkt-/Leistungsrisiko von Bedeutung sind und zur Vermeidung von Wiederholungen in den Teil Allgemeine Vereinbarungen platziert wurden1. Nachstehend werden nur die IT-spezifischen Ausschlüsse einer näheren Betrachtung unterzogen. aa) Unzureichende Datensicherung

215

Ausgeschlossen sind nach Ziff. 1.7.1.1, 1. Spiegelstrich Ansprüche Dritter wegen Sach- und Vermögensschäden, „aus dem bewusst pflichtwidrigen Unterlassen der Sicherung von Daten des Auftraggebers“.

216

Fraglich ist zunächst, ob es sich bei dieser Klausel überhaupt um einen Ausschluss handelt oder nicht vielmehr um eine sog. verhüllte Obliegenheit, die der Gefahrverhütung dient. Im letztgenannten Fall ist der Versicherer gemäß Ziff. 26.2 AHB leistungsfrei, wenn der Versicherungsnehmer die Obliegenheit vorsätzlich verletzt. Bei grob fahrlässiger Verletzung ist der Versicherer berechtigt, seine Leistung in einem der Schwere des Verschuldens des Versicherungsnehmers entsprechenden Verhältnis zu kürzen. Der Versicherungsschutz bleibt jedoch bestehen, wenn der Versicherungsnehmer nachweist, dass die Verletzung der Obliegenheit weder für den Eintritt oder die Feststellung des Versicherungsfalls noch für die Feststellung oder den Umfang der dem Versicherer obliegenden Leistung ursächlich war. Das gilt nicht, wenn der Versicherungsnehmer die Obliegenheit arglistig verletzt hat.

217

Nach der Rechtsprechung des BGH kommt es für die Abgrenzung zwischen einem (echten) Ausschluss und einer verhüllten Obliegenheit nicht auf Wortlaut oder Stellung einer Klausel an, sondern auf deren materiellen Inhalt. Eine verhüllte Obliegenheit soll immer dann vorliegen, wenn eine 1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 10.

1342

Koch

Rz. 220 O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Klausel in erster Linie vom Versicherungsnehmer ein sorgfältiges Verhalten fordert. Hier liegt es in der Hand des Versicherungsnehmers, sich den Versicherungsschutz zu erhalten. Dagegen soll eine objektive Risikobegrenzung vorliegen, wenn die betreffende Klausel eine individualisierende Beschreibung des Wagnisses enthält, für das Versicherungsschutz gewährt oder ausgeschlossen sein soll1. Gemessen an diesen Abgrenzungskriterien spricht der Wortlaut der Klausel 218 für eine verhüllte Obliegenheit. Denn die Klausel knüpft an ein positives Tun des Versicherungsnehmers an. Bestätigt wird diese Bewertung durch vergleichbare Klauseln in der Sachversicherung (z.B. Klausel TK 1911 Ziff. 7 zu den ABE, Klausel TK 2911 Ziff. 7 zu den AMB), die als Obliegenheit ausgestaltet sind. Im Übrigen gehen Unklarheiten bei der Auslegung nach § 305c Abs. 2 BGB zu Lasten des Versicherers, was im Zweifel zur Annahme eine Obliegenheit führt2. Unabhängig von der Qualifikation als echter Ausschluss oder verhüllte Ob- 219 liegenheit stellt sich ferner die Frage, ob diese Klausel einer Inhaltskontrolle standhält. Bedenken bestehen insoweit, als hinsichtlich des Umfangs der Datensicherung keine Konkretisierung erfolgt3. Die Datensicherungsklausel dürfte von daher mit dem Transparenzgebot des § 307 Abs. 1 Satz 2 BGB kaum zu vereinbaren und folglich unwirksam nach § 307 Abs. 1 Satz 1 BGB sein. Eine Lückenfüllung im Wege der ergänzenden Vertragsauslegung nach §§ 133, 157 BGB scheitert daran, dass eine Vielzahl von Möglichkeiten zur Lückenfüllung zu Gebote steht (stündlich/täglich/wöchentlich etc.). Nur eine zeitliche Festlegung wie z.B. in Klausel TK 1928 Ziff. 6 lit. a) zu den ABE könnte die Intransparenz beseitigen4. bb) Computerviren und Eingriffe im Datenverarbeitungssystem/ Datennetze Ausgeschlossen sind nach Ziff. 1.7.1.1, 2. Spiegelstrich Ansprüche wegen Sach- und Vermögensschäden, „aus dem bewusst pflichtwidrigen Unterlassen von dem Stand der Technik entsprechenden Sicherheits- und Schutzvorkehrungen gegen Software, die geeignet ist, die Datenordnung zu zerstören oder zu verändern, z.B. Software-Viren, Trojanische Pferde und dgl., sowie gegen unbefugte Eingriffe in Datenverarbeitungssysteme/Datennetze (z.B. Hacker-Attacken, Denial of Service Attacks)“. (Hervorhebung durch den Verfasser)

1 BGH v. 2.12.1992 – IV ZR 135/91, MDR 1993, 845 = VersR 1993, 223; BGH v. 9.12.1987 – IVa ZR 155/86, CR 1988, 559 = VersR 1988, 267 (269); krit. Römer/ Langheid, § 6 Rz. 7; BK/Schwintowski, § 6 Rz. 23 ff.; Prölss/Martin/Prölss, § 6 Rz. 7 ff. 2 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2491. 3 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 10. 4 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2492.

Koch

1343

220

O Rz. 221

Einzelprobleme

Auch bei dieser Klausel handelt es sich nicht um einen Ausschluss, sondern um eine verhüllte Obliegenheit zum Zwecke der Gefahrverhütung1. Es kommt also nicht darauf an, ob der Versicherungsnehmer sein System und weitergegebene Produkte/Leistungen mit dem Stand der Technik entsprechenden Sicherheits- und Schutzvorkehrungen überprüft hat, sondern ob er diese Schadprogramme bei Einsatz solcher Vorkehrungen hätte entdecken können. Anders als bei Ziff. 1.7.1.1, 1. Spiegelstrich bestehen gegen die Wirksamkeit der Klausel unter dem Gesichtspunkt fehlender Transparenz keine Bedenken. Die Bezugnahme auf den Stand der Technik bestimmt das Pflichtenprogramm hinreichend genau, da dieser Standard durch die Rechtsprechung konkretisiert worden ist2. 221

Im Übrigen sei darauf hingewiesen, dass bei Einhaltung der nach Ziff. 1.7.1.1, 1.–2. Spiegelstrich geforderten Standards mangels Verschuldens schon keine Haftung des Versicherungsnehmers gegenüber Dritten bestünde, so dass die Leistung des Versicherers bei Datenschäden nach der Konzeption der BBR IT-Dienstleister praktisch auf die Anspruchsabwehr beschränkt ist. cc) Luftfahrtprodukte

222

Gemäß Ziff. 1.7.4.3 ist nicht versichert die Haftpflicht aus „– der Planung oder Konstruktion, Herstellung oder Lieferung von Luft- oder Raumfahrzeugen oder Teilen (auch Software) von Luft- oder Raumfahrzeugen, soweit die Teile ersichtlich für den Bau von Luft- oder Raumfahrzeugen oder den Einbau in Luft- oder Raumfahrzeugen bestimmt waren, sowie Anlagen zur Steuerung und Überwachung des Luftverkehrs (z.B. Grounding); – Tätigkeiten (z.B. Montage, Wartung, Inspektion, Überholung, Reparatur, Beförderung) an Luft- oder Raumfahrzeugen oder deren Teilen (auch Software), sowie an Anlagen zur Steuerung und Überwachung des Luftverkehrs (z.B. Grounding)“.

223

Der aus der herkömmlichen Betriebs- und Produkthaftpflichtversicherung bekannte allgemeine Luftfahrtprodukte-Ausschluss wird in den BBR ITDienstleister dahingehend ergänzt, dass Software explizit als denkbares Teil eines Luft- oder Raumfahrzeugs genannt wird (z.B. Software in der Steuerungselektronik moderner Luftfahrzeuge). Zudem wird die Klausel um den Ausschluss von Ansprüchen im Zusammenhang mit Anlagen zur Steue1 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2493. S. auch Ziff. 2 BetriebshaftpflichtV für die Nutzer von Internet-Technologien, die eine vergleichbare Klausel enthält, die als Obliegenheit ausgestaltet ist und folgenden Wortlaut hat: „Dem Versicherungsnehmer obliegt es, dass seine auszutauschenden, zu übermittelnden, bereitgestellten Daten durch Sicherheitsmaßnahmen und/oder -techniken (z.B. Virenscanner, Firewall) gesichert oder geprüft werden bzw. worden sind, die dem Stand der Technik entsprechen. Diese Maßnahmen können auch durch Dritte erfolgen. Verletzt der Versicherungsnehmer diese Obliegenheit, gilt Ziff. 26 AHB (Rechtsfolgen bei Verletzung von Obliegenheiten).“ 2 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2493.

1344

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 225 O

rung oder Überwachung des Luftverkehrs erweitert (Grounding). Betroffen ist z.B. Software, die Radar- oder Funkleitsysteme unterstützt oder die Landebahnbefeuerung überwacht1. Es sind somit sowohl unmittelbare Schäden durch Luft- und Raumfahrzeuge sowie deren Teile – soweit ersichtlich für die Luft- und Raumfahrt bestimmt – als auch Schäden durch Fehler in Luftüberwachungs- und -steuerungssystemen ausgeschlossen, die z.B. einen sonstigen Vermögensschaden zur Folge haben2. Beispiel: Wegen des Ausfalls des Luftüberwachungssystems muss der Flugverkehr eingeschränkt werden. Die betroffenen Fluggesellschaften machen daraufhin den Betreiber des Flughafens wegen der Flugstornierungen und Umbuchungen auf andere Flughäfen haftpflichtig. Für die (Regress-)Ansprüche des Betreibers gegen den Systemlieferanten (Versicherungsnehmer) besteht keine Deckung.

3. Betriebs(stätten)risiko (Ziff. 2) Ziff. 2 enthält einen Katalog mitversicherter Wagnisse, die weder an die 224 Haupt- noch an die Hilfstätigkeiten eines Softwarehauses anknüpfen und deshalb keiner weiteren Betrachtung unterzogen werden. Betroffen ist u.a. die gesetzliche Haftpflicht des Versicherungsnehmers als Eigentümer, Mieter, Pächter, Leasingnehmer und Nutznießer von Grundstücken, Gebäuden oder Räumlichkeiten, die ausschließlich für den versicherten Betrieb oder für Wohnzwecke des Versicherungsnehmers und seiner Betriebsangehörigen benutzt werden sowie aus seinen Sozialeinrichtungen für Betriebsangehörige. 4. Produkt-/Leistungsrisiko (Ziff. 3) a) Gegenstand der Versicherung (Ziff. 3.1) Gemäß Ziff. 3.1 ist versichert

225

„die gesetzliche Haftpflicht des Versicherungsnehmers für Personen- und Sachschäden (auch an Daten) sowie daraus entstandene weitere Schäden, soweit diese durch vom Versicherungsnehmer – erstellte oder gelieferte Erzeugnisse, – erbrachte Arbeiten oder sonstige IT-Leistungen verursacht wurden“.

Zudem erfolgt in Anlehnung an die Regelungstechnik des ProdHM über Ziff. 3.1 grundsätzlich eine Zuweisung des Produkt- und Leistungsrisikos zur Produkthaftpflichtdeckung „für die unter Ziff. 1.1.1 und – soweit vereinbart – Ziff. 1.1.3 versicherten Risiken mit dem Zeitpunkt, in dem der Versicherungsnehmer die Erzeugnisse in den Verkehr gebracht, die Arbeiten abgeschlossen oder die IT-Leistungen ausgeführt hat“.

1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 11. 2 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 11.

Koch

1345

O Rz. 226

Einzelprobleme

Hinsichtlich der Begriffe des Inverkehrbringens von Erzeugnissen und des Abschlusses von Arbeiten oder IT-Leistungen gelten die obigen Ausführungen zur Parallelregelung in Ziff. 1.1 ProdHM entsprechend (Rz. 95 ff.). b) Erweiterung des Versicherungsschutzes für Personen-, Sachschäden und Folgeschäden (Ziff. 3.3.1) 226

Entsprechend der Regelung nach Ziff. 4.1 ProdHM (Rz. 105) sind Ansprüche wegen Personen- und Sachschäden und daraus entstandener weiterer Schäden infolge Fehlens vereinbarter Eigenschaften gemäß Ziff. 3.3.1 mitversichert. c) Erweiterung des Versicherungsschutzes für Vermögensschäden (Ziff. 3.3.3–3.3.5)

227

In Ziff. 3.3.3 wird, wie bereits erwähnt, eine sog. „offene“ Vermögensschadendeckung inklusive Betriebsunterbrechung und Produktionsausfall geboten, soweit es um die Risiken geht, die mit dem Betrieb eines Softwarehauses im Zusammenhang stehen. Hinsichtlich der Herstellung von und des Handels mit Hardware greifen die BBR IT-Dienstleister in Ziff. 3.3.4 und 3.3.5 auf das Enumerativprinzip und die Deckungsinhalte des ProdHM zurück. Gemeinsames Merkmal der Bausteine gemäß Ziff. 3.3.3–3.3.5 ist, dass Ansprüche wegen Vermögensschäden infolge Fehlens vereinbarter Eigenschaften mitversichert sind. Mängel bei der Beratung über die An- oder Verwendung der vom Versicherungsnehmer hergestellten oder gelieferten Erzeugnisse sowie Falschlieferungen stehen Mängeln in der Herstellung oder Lieferung gleich. Im Einzelnen stellt sich die Deckung für Vermögensschäden wie folgt dar. aa) Vermögensschäden im Zusammenhang mit dem Betrieb eines Softwarehauses (1) Software-Erstellung, -Handel, -Implementierung, -Pflege

228

Gemäß Ziff. 3.3.3.1 besteht Versicherungsschutz für gesetzliche Schadenersatzansprüche Dritter wegen Vermögensschäden, soweit es sich handelt um Schäden „aus für Dritte erstellter fehlerhafter Software. Hierzu zählen auch Schäden im Zusammenhang mit Software-Handel sowie -Implementierung und -Pflege für Dritte.“ Beispiel1: Der Versicherungsnehmer hat den Auftrag, für einen Handelsbetrieb eine Software zur Preisumgestaltung in Euro zu erstellen. Fälschlicherweise halbiert die Software auch die gesetzliche Mehrwertsteuer. Die Preise für den Endverbraucher werden dadurch zu niedrig ausgewiesen. Der Auftraggeber muss aber die gesetzlich vor1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 14.

1346

Koch

Rz. 231 O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

geschriebene Mehrwertsteuer abführen. Für diesen reinen Vermögensschaden besteht Versicherungsschutz gemäß Ziff. 3.3.3.1.

(2) IT-Analyse, -Organisation, -Einweisung, -Schulung Versichert sind nach Ziff. 3.3.3.2 ferner Schadenersatzansprüche

229

„aus für Dritte vorgenommener fehlerhafter IT-Analyse, -Organisation, -Einweisung und -Schulung sowie aus damit verbundenen Beratungsleistungen“. Beispiel1: Der Versicherungsnehmer entwickelt ein Buchhaltungsprogramm und vergisst bei der Schulung im Betrieb des Auftraggebers, darauf hinzuweisen, dass das Programm keine automatische Datensicherungsfunktion enthält, sondern die Datensicherung stets manuell erfolgen muss. Nach der Implementierung erfasst die Buchhaltung wie bisher üblich die Einnahme- und Ausgabedaten eines Tages, sichert diese wegen des unterlassenen Hinweises durch den Versicherungsnehmer jedoch nicht. Die nicht gespeicherten Daten müssen daraufhin nochmals eingegeben werden. Der durch die erforderlichen Überstunden entstehende reine Vermögensschaden ist versichert.

(3) Netzwerkplanung, -installation, -integration, -pflege Schließlich bestimmt Ziff. 3.3.3.3, dass Schadenersatzansprüche mitversichert sind

230

„aus für Dritte vorgenommener fehlerhafter Netzwerkplanung, -installation, -integration und -pflege sowie aus damit verbundenen Beratungsleistungen“. Beispiel2: Der Versicherungsnehmer erstellt eine Netzwerk-Software für eine Hotelkette, welche die Buchungen der einzelnen Hotels zusammenführen soll. Nach erfolgreicher Testphase funktioniert das Programm zunächst fehlerfrei. Als am Monatsende die einzelnen Hotels ihre Daten zu übermitteln versuchen, stellt sich heraus, dass die Software derart große Datenmengen nicht korrekt verarbeiten kann. Dadurch entstehen Reiseunternehmen, die in Vertragsverhältnissen zu der Hotelkette stehen, Umbuchungskosten. Für diese reinen Vermögensschäden besteht Versicherungsschutz.

bb) Vermögensschäden im Zusammenhang mit Herstellung von und Handel mit Hardware und hardwarebezogenen Tätigkeiten Abweichend vom ProdHM werden für Vermögensschäden im Zusammen- 231 hang mit Hardware-Handel, -Beratung, einschließlich -Modifizierung (Nachrüstung), -Installation, -Wartung sowie – falls vereinbart – für Hardware-Herstellung und die Herstellung von Steuer-, Mess- und Regeltechnik (Ziff. 1.1.3) nur zwei Deckungsbausteine angeboten, und zwar die Aus- und Einbaukostenklausel sowie die Steuerungselementeklausel. Da beide Klauseln hinsichtlich der Voraussetzungen und des Umfangs des Versicherungsschutzes identisch sind mit Ziff. 4.4. ProdHM (Rz. 134 ff.) und der Deckungserweite1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 14. 2 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 14.

Koch

1347

O Rz. 232

Einzelprobleme

rung zu Ziff. 4.5 (Rz. 150 ff.) kann auf die dortigen Anmerkungen verwiesen werden. cc) Zeitliche Begrenzung des Versicherungsschutzes 232

Gemäß Ziff. 3.2 Abs. 1 besteht für Ansprüche nach Ziff. 3.3.3 und – soweit vereinbart – Ziff. 3.3.4 wegen Schäden durch Erzeugnisse, Arbeiten und sonstige IT-Leistungen des Versicherungsnehmers, die vor Inkrafttreten dieses Versicherungsvertrags ausgeliefert oder erbracht wurden, Versicherungsschutz nur bei besonderer Vereinbarung. Die Nachhaftungsdeckung gemäß Ziff. 3.2 Abs. 2 sieht vor, dass der Versicherungsschutz zudem die Folgen aller Versicherungsfälle umfasst, die dem Versicherer nicht später als drei Jahre nach Beendigung des Versicherungsvertrags gemeldet werden. d) Risikoabgrenzungen und Ausschlüsse (Ziff. 3.4)

233

Die in Ziff. 3.4 enthaltenen Risikoabgrenzungen und Ausschlüsse ergänzen Ziff. 1.7 (Rz. 213 ff.). Sie sind weitgehend identisch mit Ziff. 6 ProdHM. Besonderheiten weist der Ausschluss gemäß Ziff. 3.4.2.1 auf (z.B. zeitlicher Selbstbehalt bei Betriebsunterbrechung). Da er nur die Risiken aus der Tätigkeit als Provider betrifft, wird er nicht behandelt. aa) Erfüllungsansprüche und -surrogate (Ziff. 3.4.1)

234

Der Ausschluss von Erfüllungsansprüchen und Ziff. 3.4.1 entspricht Ziff. 6.1.1 ProdHM (Rz. 166).

-surrogaten

gemäß

bb) Ansprüche aus Garantien 235

Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.2 Ansprüche wegen Sach- und Vermögensschäden „aus Garantien oder aufgrund sonstiger vertraglicher Haftungserweiterungen, soweit es sich nicht um im Rahmen der Ziff. 3 versicherte Vereinbarungen bestimmter Eigenschaften von Erzeugnissen, Arbeiten und IT-Leistungen bei Gefahrübergang handelt, für die der Versicherungsnehmer verschuldensunabhängig im gesetzlichen Umfang einzustehen hat“. (Hervorhebung durch den Verfasser)

Dieser Ausschluss entspricht Ziff. 6.2.1 ProdHM (Rz. 167). Dem Begriff der Leistungen wird lediglich das Kürzel „IT“ vorangestellt. cc) Gewährleistung wegen Rechtsmängeln 236

Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.3 Ansprüche, „die daraus hergeleitet werden, dass gelieferte Sachen oder Arbeiten mit einem Rechtsmangel behaftet sind (z.B. Schäden aus der Verletzung von Patenten, gewerblichen Schutzrechten, Urheberrechten, Verstöße gegen Wettbewerb und Werbung; siehe aber Ziff. 1.5.4)“.

1348

Koch

Rz. 240 O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Wie aus dem Hinweis auf Ziff. 1.5.4 deutlich wird, greift dieser Ausschluss nicht ein, soweit der Rechtsmangel in der Verletzung von Persönlichkeitsrechten (Rz. 210 f.) begründet liegt. dd) Ansprüche wegen Schäden gemäß Ziff. 7.8 AHB Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.4 Ansprüche wegen Schäden gemäß Ziff. 7.8 AHB (Rz. 62 f.).

237

ee) Pflichtwidrigkeitsklausel Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.5 Ansprüche 238 gegen den Versicherungsnehmer oder jeden Mitversicherten, soweit diese den Schaden durch bewusstes Abweichen von Vorschriften, Anweisungen oder Bedingungen des Auftraggebers sowie durch eine sonstige bewusste Pflichtverletzung herbeigeführt haben. Dieser Ausschluss ist wortgleich mit Ziff. 6.2.4 ProdHM (Rz. 170). ff) Erprobungsklausel Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.6 Satz 1

239

„Ansprüche wegen Sach- und Vermögensschäden durch Erzeugnisse (Produkte, ITLeistungen), deren Verwendung oder Wirkung im Hinblick auf den konkreten Verwendungszweck nicht nach dem Stand der Technik – bei Software z.B. ohne übliche und angemessene Programmtests – oder in sonstiger Weise ausreichend erprobt waren.“ (Hervorhebung durch den Verfasser)

Der Erprobungsklausel kommt insbesondere bei der Erstellung von Individualsoftware besondere Bedeutung zu, da hier maßgeschneiderte Lösungen gefertigt werden. Sie stimmt inhaltlich mit Ziff. 6.2.5 ProdHM überein (Rz. 171 f.), enthält in Bezug auf die Erprobung von Software jedoch eine Konkretisierung des Standards „Stand der Technik“ durch den Zusatz „bei Software z.B. ohne übliche und angemessene Programmtests“. Auf eine weitere Spezifizierung hat der GDV verzichtet, da sich bislang keine einheitlichen Standards durchgesetzt haben. Eine Konkretisierung der Angemessenheit kann somit nur im Einzelfall unter Berücksichtigung der angewandten Programmtests erfolgen1. gg) Konzernklausel Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.7

240

„Ansprüche wegen Vermögensschäden i.S.v. Ziff. 2.1 AHB sowie Schäden durch Datenlöschung, -beschädigung oder Beeinträchtigung der Datenordnung, die von Unternehmen, die mit dem Versicherungsnehmer oder seinen Gesellschaften durch Kapital mehrheitlich verbunden sind oder unter einer einheitlichen unternehmerischen Leitung stehen, geltend gemacht werden“.

1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 17.

Koch

1349

O Rz. 241

Einzelprobleme

Die Konzernklausel ist aus dem ProdHM (Ziff. 6.2.7) bekannt. Insoweit kann auf die dortigen Anmerkungen verwiesen werden (Rz. 175). hh) Vollständiges Unterlassen von Wartung und/oder Pflege 241

Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.8 „Ansprüche wegen Schäden, die daraus resultieren, dass der Versicherungsnehmer oder ein von ihm beauftragter Dritter die geschuldete Hardware-Wartung und/oder Software-Pflege vollständig unterlässt“. (Hervorhebung durch den Verfasser)

Der GDV hebt in seinen Erläuterungen hervor, dass der Ausschluss nur bei einem vollständigen Unterlassen eingreift. Der Versicherungsschutz bleibt somit bestehen, wenn der Schaden nur darauf beruht, dass ein oder mehrere Arbeitsschritte im Rahmen der Wartung/Pflege versehentlich nicht durchgeführt werden1. ii) Vertragsverletzungen 242

Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.9 „Ansprüche wegen Nichteinhaltung von Fristen, Terminen, Vor- und Kostenanschlägen“.

Dieser Klausel kommt keine eigenständige Bedeutung zu, da diese Ansprüche bereits von dem Ausschluss für Erfüllungsansprüche und -surrogate nach Ziff. 3.4.1 erfasst werden. jj) Lizenzvergabe 243

Ausgeschlossen vom Versicherungsschutz sind nach Ziff. 3.4.2.10 „Ansprüche aus der Vergabe von Lizenzen, die den Abnehmer zur Weiterveräußerung berechtigen“.

Diesen Ausschluss begründet der GDV mit den Besonderheiten der SoftwareBranche. Dort würden Lizenzen vergeben, um dem direkten Abnehmer des Versicherungsnehmers ein Nutzungsrecht einzuräumen. Allein durch diese Vertragsgestaltung ändere sich aber noch nicht die Umsatz-Risiko-Relation. Daher müsse in diesem Fall der Versicherungsschutz bestehen bleiben. Erst wenn der Lizenznehmer gleichzeitig zur Weiterveräußerung oder zur Nutzung der Software als Plattform für seine Eigenentwicklungen legitimiert werde, solle die damit verbundene Risikoerhöhung in der umsatzgestützten Beitragsberechnung des Versicherungsnehmers ihren Niederschlag finden. Deshalb sei der Ausschluss aufgenommen worden, um im Einzelfall einen risikogerechten Beitrag ermitteln zu können2. kk) Rückrufkosten 244

Ausgeschlossen vom Versicherungsschutz sind gemäß Ziff. 3.4.2.11 Ansprüche wegen Kosten gemäß Ziff. 3.3.3.1 und 3.3.4, die im Zusammenhang 1 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 17. 2 S. GDV-Rundschreiben H 37/02 M v. 1.8.2002, S. 17.

1350

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 249 O

mit einem Rückruf von Erzeugnissen geltend gemacht werden. Die Definition des Rückrufs entspricht der nach Ziff. 6.2.8 ProdHM (Rz. 118). In der Praxis dürfte ein „Software-Rückruf“ kaum vorkommen. Bei Software wird im Regelfall eine Aktualisierung aufgespielt. e) Versicherungsfall/Serienschaden/Selbstbehalt (Ziff. 3.5) aa) Versicherungsfall Versicherungsfall ist gemäß Ziff. 3.5.1 das während der Wirksamkeit des 245 Vertrags eingetretene Schadenereignis. Bei dem Deckungsbaustein Ausund Einbaukosten (Ziff. 3.3.4) tritt der Versicherungsfall im Zeitpunkt des Einbaus, Anbringens oder Verlegen der Erzeugnisse, bei der Steuerungselementeklausel (Ziff. 3.3.5) im Zeitpunkt der Produktion, Be- oder Verarbeitung ein. bb) Serienschaden Die Definition des Serienschadens gemäß Ziff. 3.5.2 ist identisch mit 246 Ziff. 8.3 ProdHM, weshalb auf die dortigen Ausführungen verwiesen werden kann (Rz. 177 ff.). cc) Selbstbehalt Gemäß Ziff. 3.5.3 hat sich der Versicherungsnehmer – soweit nicht 247 Ziff. 3.4.2.1, 3. Spiegelstrich gilt (zeitlicher Selbstbehalt) – bei jedem Versicherungsfall an den versicherten Schäden selbst zu beteiligen. Im Falle eines Serienschadens i.S.v. Ziff. 3.5.2 wird für alle Versicherungsfälle dieser Serie ein gesonderter Selbstbehalt vereinbart. 5. Umweltrisiko (Ziff. 4) Das Umweltrisiko ist in Ziff. 4 in einer eigenständigen Klausel geregelt. Je 248 nach der Art der zu Grunde liegenden IT-Risiken können das Umwelt-Betriebsrisiko (Rz. 75) und/oder das Umwelt-Regressrisiko (Rz. 76 ff.) im Rahmen der Umwelthaftpflicht-Basisversicherung mitversichert werden. 6. Bewertung Trotz des Ausschlusskatalogs bieten die BBR IT-Dienstleister für Schäden 249 im Zusammenhang mit den typischen Tätigkeiten eines Softwarehauses umfangreichen Schutz für Sach-, Personen- und vor allem Vermögensschäden. Ergänzungsbedarf besteht hinsichtlich der Auslandsdeckung für Inhalte, die zum Herunterladen aus dem Internet angeboten werden. Die Abgrenzung zwischen Daten- und Tätigkeitsschäden wird nicht immer leicht zu führen sein. Gleiches gilt für die Abgrenzung zwischen dem Betriebs(stätten)- und dem Produkt-/Leistungsrisiko. Da Daten- und Tätigkeitsschäden hinsichtlich des Deckungsumfangs nur dann gleich behandelt werden, Koch

1351

O Rz. 250

Einzelprobleme

wenn der Schaden vor Abschluss der Arbeiten oder der sonstigen IT-Leistungen eingetreten ist, sind deshalb Streitigkeiten nicht nur über die Qualifikation von Schäden, sondern auch deren Zuordnung zum Betriebs(stätten)- oder Produkt-/Leistungsrisiko vorprogrammiert. Unter dem letztgenannten Gesichtspunkt drohen Deckungsstreitigkeiten im Übrigen auch bei Schäden, die weder Daten- noch Tätigkeitsschäden sind, z.B. wenn Daten fehlerhaft eingegeben werden, die zu fehlerhaften Berechnungen führen. Da es sich hierbei um (echte) Vermögensschäden handelt, besteht Deckung nur dann, wenn sie nach Abschluss der Arbeiten eingetreten sind. Nicht nur unter allgemein zivilrechtlichen1, sondern auch unter versicherungsrechtlichen Gesichtspunkten hat der Versicherungsnehmer deshalb durch eine entsprechende vertragliche Gestaltung des Werk- oder Dienstleistungsvertrags und/oder des Pflichtenhefts dafür Sorge zu tragen, dass – gerichtsfest – Feststellungen zum Abschluss der (Teil-)Arbeiten oder (Teil-)Leistungen getroffen werden können.

V. Alternativkonzepte 250

Die auf dem Markt angebotenen Deckungskonzepte weichen zum Teil stark von den BBR IT-Dienstleister ab. Die für den Versicherungsnehmer bedeutsamsten Abweichungen werden nachstehend aufgezeigt. Von einer Bezugnahme auf bestimmte Versicherer und Policen ist abgesehen worden, da die Darstellung nicht den Anspruch erheben kann und will, den gesamten Markt abzubilden. 1. Versichertes Risiko

251

Einige Versicherer dehnen den Katalog der standardmäßig in den BBR ITDienstleister versicherten Risiken über den Kreis der für Softwarehäuser typischen Tätigkeiten hinaus aus z.B. auf die Abwicklung von E-Commerce, den Betrieb von Rechenzentren und Datenbanken für Dritte und das Application Service Providing2. 2. Versicherte Schadenarten

252

Alle auf dem Markt angebotenen AHB-basierten Deckungskonzepte für Softwarehäuser erweitern in Übereinstimmung mit den BBR IT-Dienstleister den Versicherungsschutz auf Vermögensschäden. Zum Teil werden Policen angeboten, die eine vollkommen offene Vermögensschadendeckung enthalten, die nur durch Ausschlüsse begrenzt wird. Eine Differenzierung zwischen dem Betriebs(stätten)- und dem Produkte-/Leistungsrisiko findet nicht statt3. 1 Vgl. Müller-Hengstenberg, CR 2005, 385 ff. 2 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2565, 2644 f. 3 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2562 ff.

1352

Koch

Rz. 256 O

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

3. Mitversicherte Unternehmen Weitergehend als die BBR IT-Dienstleister werden teilweise unselbständige 253 Niederlassungen im In- und Ausland (ausgenommen USA/Kanada) sowie selbständige Tochterunternehmen des Versicherungsnehmers innerhalb der EU standardmäßig mitversichert. Dieser Versicherungsschutz wird vielfach jedoch nur subsidiär zu einer ggf. für diese Niederlassungen/Unternehmen bestehenden (lokalen) Haftpflichtversicherung geboten1. 4. Erweiterungen des Versicherungsschutzes a) Auslandsschäden Vielfach wird weltweite Vermögensschadendeckung ohne Differenzierung zwischen direktem oder indirektem Export angeboten mit den bekannten Beschränkungen für USA/Kanada-Risiken (Anrechnung von Kosten des Rechtsschutzes als Leistungen auf die Versicherungssumme)2.

254

b) Datenschäden Bei AHB-basierten Deckungskonzepten werden Datenschäden vereinzelt 255 abweichend von den BBR IT-Dienstleister als Vermögensschäden deklariert, zum Teil wird keine Zuordnung vorgenommen. Bei nicht AHB-basierten Deckungskonzepten werden Datenschäden in der Regel ausdrücklich wie Vermögensschäden behandelt3. Diese Vermögensschadenkonzepte werden zumeist nicht isoliert, sondern als Ergänzung zur AHB-basierten Betriebsund Produkthaftpflichtversicherung angeboten, die wiederum – vergleichbar mit Ziff. 7.15 AHB (Rz. 80 ff.) – eine Nullstellung der IT-Risiken vorsieht4. Klauselbeispiel (aus einer Betriebs-/Produkthaftpflichtversicherungspolice)5: Kein Versicherungsschutz besteht für Vermögensschäden und daraus resultierende Folgeschäden, für die gemäß separater Vermögensschaden-Haftpflichtversicherung (IT-Police) Versicherungsschutz geboten wird. Dieses gilt auch für solche Sachschäden, die in der (IT-Police) als Vermögensschaden definiert sind.

Die aus Ziff. 2.1 AHB bekannte (Negativ-)Abgrenzung des Begriffs des Ver- 256 mögensschadens, die auch diesen Vermögensschadendeckungen zugrunde liegt, kann sich als sehr problematisch erweisen. Wenn Datenschäden einerseits wie Vermögensschäden behandelt werden, Vermögensschäden andererseits definitionsgemäß nicht aus Sachschäden herleitbar sein dürfen, hat dies zur Konsequenz, dass für Datenverluste, die aus der Beschädigung des Datenträgers (= Sachschaden) herrühren, kein Versicherungsschutz be1 2 3 4 5

S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2569 f., 2613 f. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2563, 2619. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2577. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2603 ff. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2604.

Koch

1353

O Rz. 257

Einzelprobleme

steht1. Folgt man der hier vertretenen Ansicht zur Sachqualität von gespeicherten Daten, gilt es zudem zu berücksichtigen, dass haftungsrechtlich bei Verletzung der Datenintegrität ein Sachschaden vorliegt. Soweit in der ITPolice der Begriff des Sachschadens – anders als der Begriff des Vermögensschadens – keine eigenständige Definition gefunden hat, ist der Begriff des Sachschadens aus der Sicht des durchschnittlichen Versicherungsnehmers zu bestimmen. Dieser wird den Begriff des Sachschadens insbesondere auch deshalb mit dem korrespondierenden Begriff in Ziff. 1.1 AHB gleichsetzen, weil die IT-Police die Betriebs- und Produkthaftpflichtversicherung, die auf den AHB basiert, ergänzt. Ausgehend von diesem Verständnis stellt die Verletzung der Datenintegrität deckungsrechtlich einen Sachschaden dar. Es besteht somit bei Geltung der obigen Klausel – vorbehaltlich einer ausdrücklichen Einbeziehung der Verletzung der Datenintegrität in den Versicherungsschutz der IT-Police – auch keine Deckung für Schäden an Software oder durch Datenverlust, soweit diese aus einer Verletzung der Integrität (irgendwelcher) Daten resultieren2. c) Tätigkeitsschäden 257

Der Einschluss von Tätigkeitsschäden erfolgt bei AHB-basierten Deckungskonzepten entsprechend der Regelung in den BBR IT-Dienstleistern standardmäßig und in der Regel zu einem Sublimit (z.B. 30 000 Euro, zweifach maximiert) und einem Selbstbehalt (z.B. 10 %, mind. 100 Euro, max. 1000 Euro). d) Verletzung von gewerblichen Schutzrechten, Urheberrechten sowie des Wettbewerbsrechts

258

Über den Deckungsumfang der BBR IT-Dienstleister hinausgehend wird vielfach nicht nur Versicherungsschutz für die Verletzung von Persönlichkeitsrechten versprochen, sondern ganz allgemein für Verletzungen des Urheberrechts, gewerblicher Schutzrechte und bei Verstößen gegen das Wettbewerbsrecht3. Einige Versicherer schließen jedoch Ansprüche aus, die vor Gerichten in Common-Law-Ländern (z.B. Großbritannien, Irland, Malta, USA, Kanada, Jamaika, Australien, Neuseeland, Hongkong, Singapur, Malaysia) oder auf der Basis des dort geltenden Rechts erhoben werden. Auf Grund des im Immaterialgüterrecht maßgeblichen Territorialitätsprinzips, demzufolge das Recht desjenigen Staates anzuwenden ist, für dessen Gebiet der Immaterialgüterschutz in Anspruch genommen wird4, besteht somit de facto kein Versicherungsschutz für Rechtsverletzungen in diesen Ländern.

1 2 3 4

S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2607. Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2608. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2578. Zuletzt zum Markenrecht BGH v. 13.10.2004 – I ZR 163/02, CR 2005, 359, 360 f.

1354

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 263 O

Zudem wird die Deckung unter den Vorbehalt gestellt, dass der Versiche- 259 rungsnehmer nachweist, vor Inverkehrbringen der Produkte eine entsprechende Recherche durch geeignete Fachkräfte durchgeführt zu haben. Gegen die Wirksamkeit dieser Einschränkung bestehen die gleichen Bedenken, wie sie in Bezug auf Ziff. 1.7.1.1 BBR IT-Dienstleister geäußert worden sind (Rz. 214 ff.). Es handelt sich bei dieser Einschränkung ebenfalls um eine gefahrverhütende Obliegenheit i.S.v. § 28 Abs. 1 VVG, deren Nichtbeachtung zum Verlust des Versicherungsschutzes führt. Neben dem Verschulden ist Kausalität zwischen der Obliegenheitsverletzung und dem Schaden erforderlich. Beide Voraussetzungen werden bei einer unterlassenen Recherche regelmäßig zu bejahen sein1. Ausdrücklich und in Abweichung von der gesetzlichen Beweisregel wird 260 dem Versicherungsnehmer die Beweislast dafür aufgebürdet, dass er seine Obliegenheit zur Nachforschung nicht verletzt hat. Diese Abweichung führt zur Unwirksamkeit der Einschränkung gemäß § 309 Nr. 12 Buchst. a) BGB i.V.m. §§ 310 Abs. 1, 307 Abs. 2 Nr. 1 BGB. Teilweise wird erweiterter passiver Rechtsschutz gewährt, d.h. die Ge- 261 richts- und Anwaltskosten eines Verfahrens, mit dem der Erlass einer einstweiligen Verfügung begehrt wird, auch wenn es sich um Ansprüche auf Unterlassung oder Widerruf handelt, sowie einer Unterlassungs- oder Widerrufsklage gegen den Versicherungsnehmer werden ersetzt. e) Sonstige Erweiterungen aa) Verzug Weitergehend als die BBR IT-Dienstleister gewähren einige Versicherer De- 262 ckung für gesetzliche Haftpflichtansprüche aus Verzug. Teilweise wird der Versicherungsschutz beschränkt auf solche Fälle, in denen der Verzug unmittelbar auf der Nichtverfügbarkeit von Daten auf Grund von Schäden an elektronischen Geräten des Versicherungsnehmers beruht „– durch Brand, Explosion, Leitungswasser oder Abwasser; – auf Grund eines Abhandenkommens durch Einbruchdiebstahl, Raub und Plünderung; – auf Grund von Über- oder Unterspannung, elektrostatischer Aufladung, elektromagnetischer Störung sowie höherer Gewalt einschließlich Blitzeinwirkung“2.

Die Deckung wird zudem davon abhängig gemacht, dass die Geräte über ei- 263 ne Elektronik-Versicherung sachversichert sind. Beruht der Verzug auf einer der vorgenannten Ursachen, wird freilich vielfach ein Verschulden des Versicherungsnehmers zu verneinen sein, so dass die Versicherung auf Abwehrschutz beschränkt bleibt3. 1 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2579. 2 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2580, 2628. 3 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2580.

Koch

1355

O Rz. 264

Einzelprobleme

bb) Umwelteinwirkungen/Allmählichkeitsschäden 264

Weitergehend als die BBR IT-Dienstleister wird vielfach standardmäßig Versicherungsschutz gewährt für gesetzliche Haftpflichtansprüche privatrechtlichen Inhalts wegen Schäden durch Umwelteinwirkungen, die dem nichtanlagenspezifischen Umwelt-Betriebsrisiko zuzuordnen sind (Rz. 75)1. cc) Softwareviren

265

Der Versicherungsschutz für Vermögensschäden Dritter infolge schadstiftender Software entspricht zumeist dem Standard gemäß Ziff. 1.7.1.1, 2. Spiegelstrich BBR IT-Dienstleister, so dass auf die dortigen Anmerkungen verwiesen werden kann (Rz. 219 ff.). dd) Mehrkosten nach fehlgeschlagener Installation

266

Die Deckungskonzepte, die eine vollkommen offene Vermögensschadendeckung aufweisen, enthalten zumeist Klauseln, wonach Ansprüche auf Grund einer endgültig fehlgeschlagenen Installation der vom Versicherungsnehmer hergestellten und gelieferten Software in eine bei dem Besteller bereits bestehende Hardware mitversichert sind, soweit es sich um folgende Kosten handelt2: „– Kosten für die Mehrarbeit des eigenen Personals des Bestellers zur Beseitigung der Software; – Mehrkosten aus der Beauftragung eines Dritten zur Beseitigung der bereits installierten Software“.

Dieser Deckungstatbestand weist Parallelen zu den Deckungsbausteinen gemäß Ziff. 4.2 ProdHM (Verbindungs-, Vermischungs- und Verarbeitungsschäden) (Rz. 107 ff.) und Ziff. 4.4 ProdHM (Ausbau- und Einbaukosten) (Rz. 134 ff.) auf. Die ausdrückliche Mitversicherung ist erforderlich, da anderenfalls diese Kosten unter den Ausschluss gemäß Ziff. 1.2 AHB fielen. Der Begriff der Mehrkosten (2. Spiegelstrich) darf dabei nicht verwechselt werden mit dem korrespondierenden Begriff in der Sachversicherung. Mehrkostendeckungen auf der Basis der Elektronik-, Feuer- oder Maschinenversicherung versichern Kosten für Überbrückungsmaßnahmen, die entstehen, weil der frühere betriebsfertige Zustand dieser Sache wiederhergestellt oder diese Sache wiederbeschafft werden muss (z.B. Kosten für die Benutzung anderer Anlagen, Umprogrammierung), nicht hingegen Kosten der Wiederherstellung von Daten3.

1 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2581. 2 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2587. 3 Vgl. R. Koch, Versicherbarkeit von IT-Risiken, Rz. 1169 ff.

1356

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 272 O

ee) Verjährungsverlängerung Zuweilen wird standardmäßig ein Verzicht auf den Einwand der Ausschlussbestimmung des Ziff. 7.3 AHB vereinbart für den Fall, dass der Versicherungsnehmer die gesetzliche Verjährungsfrist verlängert1.

267

ff) Strafrechtsschutz Einige Versicherer übernehmen abweichend von Ziff. 5.3 AHB die Gerichts- 268 kosten sowie die gebührenmäßigen – ggf. auch die mit ihm besonders vereinbarten höheren – Kosten der Verteidigung in einem Strafverfahren wegen eines Ereignisses, das einen unter den Versicherungsschutz fallenden Haftpflichtanspruch zur Folge haben könnte2. gg) Pflichtwidrigkeitsklausel Die Pflichtwidrigkeitsklausel wird zuweilen abgemildert, indem bei Schä- 269 den infolge Abweichung von schriftlichen Anweisungen oder Bedingungen des Auftraggebers, der Ausschluss nur dann eingreift, wenn der Versicherungsnehmer nicht nachweist, den Auftraggeber unverzüglich über die Abweichung unterrichtet zu haben3. f) Nachhaftungsversicherung Die AHB-basierten Konzepte, die der Schadenereignistheorie folgen, sehen 270 standardmäßig eine bis zu fünfjährige Meldefrist für vor dem Vertragsende eingetretene Versicherungsfälle vor4. Einschränkend machen einige Versicherer die Deckung davon abhängig, dass die Ursache für das Schadenereignis in der Vertragslaufzeit liegt. Die Vermögensschadenkonzepte folgen zum Teil dem Verstoßprinzip in Verbindung mit dem Claims Made-Prinzip. Versicherungsfall ist demnach die

271

„erstmalige Geltendmachung eines Haftpflichtanspruches gegenüber dem Versicherungsnehmer oder einer mitversicherten Tochter- oder Beteiligungsgesellschaft, der während der Laufzeit dieses Vertrags erhoben wird und auf einer vom Versicherungsnehmer während der Vertragslaufzeit gesetzten Ursache beruht und innerhalb der Meldefrist dem Versicherer angezeigt wird. Im Sinne dieses Vertrags ist ein Haftpflichtanspruch geltend gemacht, wenn gegen den Versicherungsnehmer oder eine mitversicherte Tochter- oder Beteiligungsgesellschaft ein Anspruch schriftlich erhoben wird“5.

Auf Grund dieser Versicherungsfalldefinition bedarf es auch hier einer Nachhaftungsdeckung, um zu verhindern, dass der Versicherungsschutz mit dem 1 2 3 4 5

S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2588. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2590. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2600. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2591. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2615.

Koch

1357

272

O Rz. 273

Einzelprobleme

Ende des Versicherungsvertrags ausläuft. Vielfach wird standardmäßig eine Nachmeldefrist von drei Jahren vorgesehen, verbunden mit der Einschränkung, dass mit dem Versicherungsbeginn einer anderen Vermögensschadenhaftpflichtversicherung innerhalb dieses Zeitraums die Nachmeldefrist endet. Innerhalb der Nachmeldefrist gemeldete Versicherungsfälle sind nur dann versichert, wenn die Ursache des Versicherungsfalls vor dem Ablauf dieser Versicherung gesetzt wurde1. g) Rückwärtsversicherung 273

Die Vermögensschadenkonzepte enthalten zumeist eine Rückwärtsdeckung für Versicherungsfälle wegen Ursachen, welche bis maximal zwei Jahre vor Beginn dieses Versicherungsvertrags gesetzt wurden und weder dem Versicherungsnehmer noch eine der mitversicherten Tochter- oder Beteiligungsgesellschaften bei Abschluss dieses Versicherungsvertrags bekannt waren oder für sie erkennbar gewesen wären. Als bekannte Ursache gilt ein Vorkommnis, wenn es von dem Versicherungsnehmer oder einer Tochter- oder Beteiligungsgesellschaft als – wenn auch nur möglicherweise – objektiv fehlsam erkannt oder ihnen gegenüber, wenn auch nur bedingt, als fehlsam bezeichnet worden ist, auch wenn Schadenersatzansprüche weder erhoben noch angedroht noch befürchtet worden sind2. 5. Produkt-/Leistungsrisiko

274

In einigen Deckungskonzepten beschränkt sich die Deckung für hardwarebezogene Risiken abweichend von den BBR IT-Dienstleister nicht auf die Gewährung von Versicherungsschutz nach Maßgabe der Deckungsbausteine für Aus- und Einbaukosten und der Steuerungselementeklausel als Ergänzung zur Maschinenklausel, sondern bietet alle Deckungsbausteine des ProdHM an mit Ausnahme des Bausteins Prüf- und Sortierkosten (Ziff. 4.6 ProdHM). a) Lagerhaltungsschäden

275

Ergänzend wird Versicherungsschutz geboten für Vermögensschäden infolge Beeinträchtigung der Lagerordnung, wenn die für die Lagerordnung erforderlichen Daten mit vom Versicherungsnehmer hergestellter, gelieferter, montierter, installierter, integrierter oder gewarteter Hardware oder Hardwarekomponenten verarbeitet werden. Ersetzt werden die Kosten für die „– Wiederherstellung der Lagerordnung (z.B. Ausräumen, Sortieren, Wiedereinräumen der gelagerten Güter); – vorübergehende Anmietung zusätzlicher Lagerkapazität (z.B. bei unnötiger Nachbestellung von Waren);

1 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2617. 2 S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2618.

1358

Koch

Versicherung von IT-Risiken aus Erstellung und Vertrieb von Software

Rz. 277 O

– Wiederherstellung/Berichtigung von beeinträchtigten Lagerdaten auf Datenträgern; – erneute maschinelle Aufbereitung von Lagerdaten (z.B. Sortieren oder Verdichten von Eingabedaten)“1.

b) Bauwerksschäden Eingeschlossen sind zudem Schadenersatzansprüche Dritter wegen Ver- 276 mögensschäden infolge Mangelhaftigkeit von Bauwerken, Gebäuden oder deren Teile, die unter Verwendung der vom Versicherungsnehmer hergestellten, gelieferten, montierten, installierten, integrierten oder gewarteten Hardware oder Hardwarekomponenten geplant oder konstruiert wurden2. 6. Abschließende Bemerkungen Bei den Konzepten, die eine vollständig offene Vermögensschadendeckung 277 anbieten, den Versicherungsschutz somit ausschließlich auf der Sekundärebene, d.h. über die Ausschlüsse bestimmen, ist zu beachten, dass der Umfang der Deckung im Vergleich zu den Modellen, die den Versicherungsschutz auf der Primärebene festlegen, zurückfallen kann. So bringt z.B. die uneingeschränkte Geltung von Ziff. 1.2 AHB eine im Vergleich zum ProdHM und den BBR IT-Dienstleister erhebliche Einschränkung des Versicherungsschutzes für Vermögensschäden mit sich. Denn es gilt zu berücksichtigen, dass die Deckungsbausteine des ProdHM und der BBR IT-Dienstleister auf der Primärebene zum Teil Vermögensschäden abdecken, die dem Bereich der Erfüllung zuzuordnen sind. Betroffen sind die Schadenpositionen Ausund Einbaukosten3, entgangener Gewinn4 sowie Produktionsausfall5 sowie die Aus- und Einbaukosten im Rahmen des Nacherfüllungsanspruchs gemäß § 439 Abs. 2 BGB oder § 635 Abs. 2 BGB6. Um diese Positionen mitzuversichern, bedarf es der partiellen Abbedingung von Ziff. 1.2 AHB. Bei reinen Vermögensschadenkonzepten ist es erforderlich, die Negativabgrenzung des Begriffs des Vermögensschadens zu modifizieren.

1 2 3 4 5 6

S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2678 ff. S. dazu R. Koch, Versicherbarkeit von IT-Risiken, Rz. 2681 f. Vgl. Ziff. 4.4.2, 4.4.5, 4.4.6 ProdHM und Ziff. 3.3.4.1 BBR IT-Dienstleister. Vgl. Ziff. 4.2.2.4, 4.3.2.3, 4.5.2.4 ProdHM und Ziff. 3.3.5.2 BBR IT-Dienstleister. Vgl. Ziff. 4.4.3 ProdHM und Ziff. 3.3.5.2 BBR IT-Dienstleister. Vgl. Ziff. 4.4.2, 4.4.5, 4.4.6 ProdHM und Ziff. 3.3.4.1 und 3.3.4.2 BBR IT-Dienstleister.

Koch

1359

P. Handels- und steuerrechtliche Aspekte von Software

I. Einordnung in das Gesamtwerk und Einleitung . . . . . . . . . .

Rz.

Rz.

1

2. Bestimmung des wirtschaftlichen Eigentums . . . . . . . . . . . . . 13

II. Grundlegende Definitionen und Abgrenzungen . . . . . . . . . . . 4 1. Qualifikation der Software als immaterielles Wirtschaftsgut. . 4 a) Beurteilung nach deutschem Handels- und Steuerrecht . . . . . . . . . . . . . . . . 4 b) Beurteilung nach internationalen Rechnungslegungsvorschriften . . . . . . . . . . . . . . . 8 c) Abgrenzungskriterien für das Vorliegen immaterieller Vermögensgegenstände aus Rechtsprechung und Verwaltungsauffassung . . . . . . . . 10 d) Ausgewählte Beispiele zur steuerlichen Beurteilung und Bilanzierung von Software . . . . . . . . . . . . . . . . . . 12

III. Steuerliche Aspekte bei Inlandssachverhalten . . . . . . . . . 1. Steuerliche Behandlung beim Entwickler der Software . . . . . . . 2. Steuerliche Behandlung beim Lizenznehmer der Software . . . . 3. Umsatzsteuerliche Aspekte . . . 4. Gewerbesteuer . . . . . . . . . . . . . . .

21 22 26 30 32

IV. Internationale Bezüge. . . . . . . . . 33 1. Lizenzvergabe an inländische Lizenznehmer durch ausländische Unternehmer . . . . . . . . . . 36 2. Abkommensübersicht und Besonderheiten in einzelnen deutschen Abkommen . . . . . . . . 40 V. Ausgewählte Gestaltungsund Problemfälle . . . . . . . . . . . . . 41 VI. Fazit . . . . . . . . . . . . . . . . . . . . . . . . 43

Literaturübersicht: Baetge/Thiele/Kirsch, Kommentar zum Bilanzrecht, Anmerkungen zu §§ 246 und 248, LBW; Beck’scher Bilanzkommentar, hrsg. von Ellrott, Förschle, Grottel u.a., 8. Aufl. 2012; Debatin/Wassermeyer (Hrsg.), Doppelbesteuerung: DBA, Loseblatt-Kommentar zu allen deutschen Doppelbesteuerungsabkommen, 119. Aufl. 2012, Eibelshäuser, Wirtschaftliche Betrachtungsweise im Steuerrecht – Herkunft und Bedeutung, DStR 2005, 1331, Engel, Die Leasingerlasse als Grundlage der Leasingvertragsgestaltung, DStR 2000, 1478, Groß, Der Lizenzvertrag, 3. Aufl., Wiesbaden 2011, Groß/Georgues/Matheis, Aktuelles zur bilanziellen Behandlung von ERP Systemen – die Gretchenfrage nach Anschaffung oder Herstellung, DStR 2006, 339, Groß/Rohrer, Lizenzgebühren, München 2003, Heno, Jahresabschluss nach Handelsrecht, Steuerrecht und internationalen Standards (IAS, IFRS), 4. Auflage, Heidelberg 2004, Henschel, Umsatzsteuerliche Behandlung des sog. E-Commerce, Köln 2004, Hoeren/Neubauer (Hrsg.), Entwicklung des Internet- und Multimediarechts im Jahr 2011, MMR Beilage 2012, 1, International Accounting Standards Board (Hrsg.), International Financial Reporting Standards, Stuttgart, 2011, Käbisch, Internet und Umsatzsteuer, Düsseldorf 2002; Köhler/Benzel/Trautmann, Die Bilanzierung von ERP Software im Internetzeitalter, DStR 2002, 926, Küffner, Umsatzsteuer bei Softwareüberlassung, DStR 1999, 1139, Petersen/Bansbach/Dornbach (Hrsg.), IFRS Praxishandbuch, München, 2010; Rouenhoff, Erste Analyse des OECD-Diskussionspapiers zur Berücksichtigung von Intangibles bei der Festlegung von Verrechnungspreisen, iStR 2012, 654; Scharfenberg/Marquardt, Die Bilanzierung des Customizing von ERP-Software, DStR 2004, 195, Tappe, Steuerliche Betriebsstätten in der „Cloud“ – Neuere technische Ent-

Strunk

1361

P Rz. 1

Einzelprobleme

wicklungen im Bereich des E-Commerce als Herausforderung für den ertragsteuerrechtlichen Betriebsstättenbegriff, iStR 2011, 870, Winnefeld, Bilanz-Handbuch, 4. Auflage, München 2006.

I. Einordnung in das Gesamtwerk und Einleitung 1

Immaterielle Wirtschaftsgüter, sei es allein oder im Zusammenhang mit anderen materiellen Vermögensgegenständen, anderen immateriellen Vermögensgegenständen oder im Zusammenhang mit sonstigen Dienstleistungen, haben in den letzten Jahrzehnten dramatisch an Bedeutung zugenommen. Insbesondere die besondere „Flüchtigkeit“ und fehlende physische Zuordnung zu einem bestimmten Ort auf der Welt, aber auch die hohe Schwankungsbreite der Werte immaterieller Vermögensgegenstände, wie z.B. Software, führt dazu, dass diesem Bereich zu Recht ein stetig steigendes Gewicht beigemessen wird. Aber auch die Diskussion über unfairen Steuerwettbewerb wäre durch das Vorliegen immaterieller Wirtschaftsgüter und die Ortsungebundenheit aufgrund der Digitalisierung und Vernetzung nicht möglich gewesen. Unternehmen, wie Google, Apple, Starbucks und andere weisen ihre Gewinne Gesellschaften in Niedrigsteuerländern durch die Nutzung von immateriellen Wirtschaftsgütern durch Konzerngesellschaften in Hochsteuerländern zu und können hierdurch offensichtlich ohne betriebswirtschaftliche, kaufmännische Nachteile zu erleiden die Steuerbelastung minimieren. Die Finanzverwaltungen der betroffenen Staaten reagieren überrascht und verärgert und kündigen massive Verschärfungen der Gesetze zur Verhinderung solcher Gewinnverlagerungen und der Nutzung immaterieller Wirtschaftsgüter in der Zukunft an.

2

Durch das Internet und die sich abzeichnende Zunahme von Wirtschaftsaktivitäten mit immateriellen Wirtschaftsgütern, wie bspw. der Überlassung von Software wurde eine Grundfrage des Internationalen Steuerrechts, die in der Vor-Internetzeit hinreichend gelöst war, neu gestellt. Die Frage danach, wann ein Staat, der nicht der Ansässigkeitsstaat ist, das Recht hat, das Einkommenssubstrat aus einer Unternehmenstätigkeit zu besteuern. Solange man für die Vornahme einer Aktivität im anderen Staat eine feste Einrichtung, ein Ladenlokal, eine Werkstatt, ein Lager oder einen Vertreter vor Ort benötigte, war die physische Präsenz im Quellenstaat Anknüpfungspunkt für die sich ergebende Besteuerung der insoweit erwirtschafteten Gewinne im Quellenstaat. Die Besteuerung folgte dem international anerkannten Prinzip, dass das Unternehmen, das von dem Quellenstaat „profitiert“, sich auch an den Kosten des Landes über Steuerzahlungen beteiligen sollte. Jetzt wird deutlich, Unternehmen können Volkswirtschaften nutzen, ohne gleichzeitig einen steuerlichen Anknüpfungspunkt in dem jeweiligen Land zu begründen. Aufgrund der technischen Besonderheiten können Unternehmen Standorte auch nach dem jeweiligen Steuerumfeld auswählen, da weltweite Aktivitäten von nahezu jedem Platz der Erde möglich sind. Dies führt zur derzeit zu beobachtenden Erosion des Steuerauf1362

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 4

P

kommens der Quellenstaaten. Die Reaktion der Gesetzgeber in allen Ländern ist die Änderung der Besteuerungsgrundlagen für grenzüberschreitende Lizenzverträge, dem Verbot der uneingeschränkten Abzugsfähigkeit von Lizenzzahlungen sowie der Annahme fiktiver Betriebsstätten zur Begründung von Steuerpflichten in Quellenstaaten. All dies muss m.E. an den Anfang eines solchen Beitrages für die steuerrechtlichen Aspekte von Softwareverträgen gestellt werden. Neben den bekannten und zu Recht sehr wichtigen und im Rahmen dieses 3 Werkes ausführlich diskutierten Rechtsfragen im Zusammenhang mit Software, im Hinblick auf die Erstellung als auch auf die Nutzung bzw. den Verkauf sind die bilanzielle Behandlung von Entwicklungsaufwand, von Herstellungsaufwand sowie die Bestimmung des Realisationszeitpunkts und weiterer im Nachfolgenden noch zu diskutierenden Fragen von besonderer Bedeutung.

II. Grundlegende Definitionen und Abgrenzungen 1. Qualifikation der Software als immaterielles Wirtschaftsgut a) Beurteilung nach deutschem Handels- und Steuerrecht Software gehört unstreitig zu den immateriellen Wirtschaftsgütern im deut- 4 schen wie internationalen Bilanzrecht1. Zunächst ist festzustellen, dass alle Voraussetzungen eines Wirtschaftsgutes bei Software erfüllt sind. Es handelt sich um einen wirtschaftlichen Wert, der abgrenzbar und selbständig bewertbar ist. Im Gegensatz z.B. zum Geschäfts- oder Firmenwert ist Software selbständig bewertbar und verkehrsfähig und erfüllt damit die Voraussetzungen für ein Wirtschaftsgut nach deutschem Handelsrecht und über die Maßgeblichkeit der Handelsbilanz für die Steuerbilanz auch für steuerliche Zwecke. Mit einiger Überraschung nimmt man zunächst zur Kenntnis, dass die Definition des immateriellen Vermögensgegenstandes weder dem Vertragsrecht, noch dem Bilanzrecht, noch dem nationalen deutschen Steuerrecht oder gar dem internationalen Steuerrecht zu entnehmen ist2. Gemeinsam ist allen genannten Rechtsgebieten, dass zu den immateriellen Vermögensgegenständen des Anlagevermögens alle unkörperlichen Werte gehören, die nicht zu den Sachanlagen3 oder Finanzanlagen zählen oder Vermögensgegenstände des Umlaufvermögens sind. Eine darüber hinausgehen-

1 EDV-Software gehört seit dem Grundsatzurteil des BFH v. 3.7.1987 (BStBl. II 728) zu den immateriellen Vermögensgegenständen. S. hierzu auch Hoyos/Huber, in Beck’scher Bilanzkommentar, § 247 HGB Rz. 377 ff. 2 S. hierzu auch OECD: Discussion Draft – Revision of the Special Considerations for Intangibles in Chapter VI of the OECD-Transfer Pricing Guidelines and Related Provisions, 6.6.2012–14.9.2012, (www.oecd.org/dataoecd/39/61/50526258. pdf) sowie Rouenhoff, iStR 2012, 654 ff. 3 In diesem Sinne bereits HFA des IDW S 5 HFA 11, WPg 2003, 876.

Strunk

1363

P Rz. 5

Einzelprobleme

de Definition ist nicht ersichtlich, vielmehr beschränkt sich die Literatur1 auf eine beispielhafte Aufzählung, die nun vom Gesetzgeber in seiner Bilanzgliederungsvorschrift des § 266 Abs. 2 A. I HGB i.d.F. des BilMoG wie folgt übernommen wurde: – Selbst geschaffene gewerbliche Schutzrechte und ähnliche Rechte und Werte, – Entgeltlich erworbene Konzessionen, gewerbliche Schutzrechte und ähnliche Rechte und Werte sowie Lizenzen an solchen Rechten und Werten – Geschäfts- oder Firmenwert – Geleistete Anzahlungen 5

Sofern die den Lizenzeinnahmen zugrundeliegenden Vermögensgegenstände als immaterielle Vermögensgegenstände gem. § 248 Abs. 2 HGB auch dann aktiviert werden dürfen, wenn sie nicht entgeltlich erworben wurden, sondern selbst erstellt wurden, bleibt es im Steuerrecht beim Verbot der Aktivierung gem. § 5 Abs. 2 EStG. Insoweit kommt es zum Auseinanderfallen von handelsrechtlichem und steuerrechtlichem Ergebnis. Hierfür ist auch die Bildung latenter Steuern in der Handelsbilanz nicht erforderlich, da es sich nicht nur um temporäre, sondern endgültige Abweichungen handelt. Für den Lizenzgeber hat diese Bilanzierungspraxis den Vorteil, dass die Aufwendungen für die Herstellung des Vermögenswertes im Jahr der Verausgabung für steuerliche Zwecke gewinnmindernd berücksichtigt werden, nicht jedoch für handelsrechtliche Zwecke. Demgegenüber stehen Lizenzeinnahmen steuerlich aber auch keine laufenden Aufwendungen gegenüber, so dass jede Einnahme sofort zu steuerpflichtigem Gewinn führt.

6

Da es jedoch hierfür auch einer Definition des Begriffs des „Immateriellen Wirtschaftsgutes“ bedarf, hat die Finanzverwaltung die folgende Aufzählung für immaterielle Wirtschaftsgüter vorgenommen: – Rechte sind z.B. gewerbliche Schutzrechte und ähnliche Rechte, z.B. Patente, Markenrechte, Warenzeichenrechte, Gebrauchsmuster, Lizenzen, Urheber- und Verlagsrechte, Leistungsschutzrechte, Film- und Fernsehrechte gem. § 94 UrhG. – Rechtspositionen sind z.B. Konzessionen, Nutzungsberechtigungen dinglicher oder schuldrechtlicher Art, Wettbewerbsrechte, Belieferungsrechte, Vertriebsrechte, Optionsrechte und Vorkaufsrechte. – Sonstige wirtschaftliche Werte und Vorteile sind z.B. Fabrikationsverfahren, Rezepte, Know-how, ungeschützte Erfindungen, Geheimverfahren, Kundenstamm bei getrennter Veräußerung.

7

Die Bilanzierungsfähigkeit von Software hängt jedoch nicht nur von der Qualifikation als Wirtschaftsgut ab, sondern auch davon, ob besondere Verbote der Bilanzierung entgegenstehen. Sowohl handelsrechtlich wie steuer1 Beispielhaft Rz. 372 ff.

1364

Strunk

Hoyos/Huber,

in

Beck’scher

Bilanzkommentar,

§ 247

HGB

Handels- und steuerrechtliche Aspekte von Software

Rz. 9

P

rechtlich ist die Bilanzierung selbst erstellter immaterieller Wirtschaftsgüter des Umlaufvermögens zulässig und geboten. Selbst erstellte immaterielle Wirtschaftsgüter des Anlagevermögens sind nach § 5 Abs. 2 EStG nicht zu aktivieren, sondern sind steuerlich sofort abzugsfähige Betriebsausgaben1. Handelsrechtlich besteht demgegenüber ein Wahlrecht gem. § 248 Abs. 2 Satz 1 HGB für selbst erstellte immaterielle Wirtschaftsgüter, sofern es sich nicht um Marken, Drucktitel, Verlagsrechte, Kundenlisten oder vergleichbare immaterielle Wirtschaftsgüter handelt. Im Ergebnis ist somit die Aktivierung selbst erstellter Software des Anlagevermögens zulässig. Aus Gründen des Gläubigerschutzes ist für Kapitalgesellschaften aber die Bildung einer Ausschüttungssperre obligatorisch gem. § 268 Abs. 8 HGB. Sofern jedoch eine Aktivierung vorgenommen wird, sind Pflichtangaben im Anhang der Bilanz gem. § 285 Nr. 22 HGB erforderlich. Das Unternehmen hat in diesem Fall alle Forschungs- und Entwicklungskosten des Geschäftsjahres auszuweisen sowie darzulegen, wie hoch der Teil auf die selbst geschaffenen immateriellen Wirtschaftsgüter des Anlagevermögens ist. Software kann auch planmäßig oder außerplanmäßig abgeschrieben werden, wobei die Bestimmung nach den steuerlichen AfA-Tabellen regelmäßig bei Software von einer Nutzungsdauer von drei bis fünf Jahren ausgeht und hierbei insbesondere der technologischen Entwertung der Software entsprechendes Gewicht beimisst2. b) Beurteilung nach internationalen Rechnungslegungsvorschriften Die einzige Definition findet man im IRS 38 section 133 indem es dort 8 heißt, ein immaterieller Vermögenswert zeichnet sich durch die folgenden Kriterien aus: – – – –

Identifizierbarkeit; nicht monetarisierbar bzw. nicht monetär; substanzlos; kontrollierbar, i.d.R. bedeutet dies rechtlich durchsetzbar, siehe auch IRSB 38 section 15; – wahrscheinlich kann hierdurch ein wirtschaftlicher Vorteil in der Zukunft erwirtschaftet bzw. erzielt werden; – zuverlässig bewertbar ist. Alle anderen Rechtskreise bedienen sich einer beispielhaften Aufzählung für immaterielle Wirtschaftsgüter und einer entsprechenden Beschreibung dieser Wirtschaftsgüter als nicht körperliche Wirtschaftsgüter, wie dies z.B. 1 BFH v. 8.9.2011 – IV R 5/09, BStBl. II 2012, 122. 2 Zu weiteren Besonderheiten, z.B. bei der Bilanzierung des Customizing von ERPSoftware s. beispielhaft mit weiteren Nachweisen Scharfenberg/Marquardt, DStR 2004, 195. 3 Zu weiteren Einzelheiten s. Petersen/Bansbach/Dornbach (Hrsg.), IFRS Praxishandbuch, S. 111 ff.

Strunk

1365

9

P Rz. 10

Einzelprobleme

bei Verfahren, Formeln und Herstellungsmethoden, aber auch bei Rechten wie z.B. Urheberrechten im Rahmen von Softwareerstellung der Fall sein kann. c) Abgrenzungskriterien für das Vorliegen immaterieller Vermögensgegenstände aus Rechtsprechung und Verwaltungsauffassung 10 Eine Hilfestellung könnte möglicherweise die vorzunehmende Abgrenzung zwischen immateriellen und materiellen Wirtschaftsgütern bringen. Aber auch diese Frage ist regelmäßig Gegenstand von kontrovers geführten Diskussionen, wobei anhand der folgenden Kriterien eine Abgrenzung vorgenommen bzw. versucht wird, eine solche vorzunehmen. Entscheidend ist für die Beurteilung, welche Rechtsnatur der Vertrag tatsächlich aufweist. Sind bspw. eindeutige Regelungen eines Kaufvertrages anzutreffen, so kommt es zumeist zur Annahme eines solchen mit der Maßgabe, dass eine Übergabe des wirtschaftlichen Eigentums stattfindet. Hieraus kann jedoch noch nicht geschlossen werden, dass es sich um ein materielles oder immaterielles Wirtschaftsgut handelt, wenngleich ein Verkauf regelmäßig für ein materielles Wirtschaftsgut spricht, doch ist dies gerade bei der Überlassung von Daten weiterhin fraglich. So ist z.B. nach Auffassung der deutschen Finanzverwaltung die Gewährung des Zugriffs auf Datenbanken, die permanent aktualisiert werden, gerade nicht als Nutzung eines immateriellen Wirtschaftsgutes, sondern vielmehr als Veräußerung des jeweils aktuellsten Datenbestandes als materielles Wirtschaftsgut anzusehen1. Dies ist jedoch nach der Rechtsprechung des BFH der einzige Fall, in dem im Zusammenhang und in sachlicher Nähe zur Software von einem materiellen Wirtschaftsgut ausgegangen wird. Der BFH hat sonst in ständiger Rechtsprechung, zuletzt am 18.5.20112, festgestellt, dass Computerprogramme jedweder Art grundsätzlich unkörperlicher Natur und daher immaterielle Wirtschaftsgüter sind, auch dann, wenn sie auf einem Datenträger gespeichert und demnach aus materiellen und immateriellen Elementen zusammengesetzt sind. Der erkennende Senat führt weiter aus, dass kein Anlass bestehe, mit Rücksicht auf die Entwicklung der Informationstechnologie oder die zunehmende Bedeutung und Verfügbarkeit von Software immaterielle Wirtschaftsgüter insgesamt als bewegliche Wirtschaftsgüter zu behandeln.

1 Keine immateriellen Wirtschaftsgüter, sondern materielle und zugleich abnutzbare bewegliche Wirtschaftsgüter sind, wenn sie nicht unter anderen rechtlichen Gesichtspunkten, z.B. als Kundenkartei oder Verlagsarchiv, als immaterielle Wirtschaftsgüter anzusehen sind, Computer-Programme, die keine Befehlsstruktur enthalten, sondern nur Bestände von Daten, die allgemein bekannt und jedermann zugänglich sind, z.B. mit Zahlen und Buchstaben (BFH v. 5.2.1988 III R 49/83, BStBl. II, S. 737). 2 BFH v. 18.5.2011 – X R 26/09, BStBl. II 2011, 865 unter Hinweis auf bisherige Rechtsprechung in Tz. 18 der Urteile (BStBl. II 1979, 634, BStBl. II 1987, 728, BStBl. II 1989, 1016, BStBl. II 1994, 873 und BStBl. II 1988, 737.

1366

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 12

P

Wie die Entscheidung des BFH zeigt, muss daher davon ausgegangen wer- 11 den, dass nicht die Art und Weise der Übermittlung bzw. das Vorliegen einer Verkörperung entscheidend für die Qualifikation als immaterielles Wirtschaftsgut ist, sondern das wirtschaftlich Gewollte. So kann es bspw. hinsichtlich der Qualifikation als immaterielles Wirtschaftsgut grundsätzlich keinen Unterschied machen, ob ein Wirtschaftsgut erworben wird bzw. ein Urheberrecht zur Nutzung erworben wird, oder ob im Wege einer vertraglichen Vereinbarung einem Kunden im Wege des sog. „Software on Demand“ die Nutzung der Software gegen Zahlung in Abhängigkeit der Inanspruchnahme angeboten wird. An der Beurteilung als immaterielles Wirtschaftsgut hält der BFH1 auch fest in Kenntnis der Entscheidung des BGH vom 18.10.19892, in der dieser von einer entsprechenden Anwendung der für bewegliche Sachen einschlägigen Rechtsvorschriften auf Software ausgegangen ist. Auch sieht der BFH in seiner Entscheidung vom 18.5.20113 keinen Widerspruch zu anderen Urteilen des BFH aus der Vergangenheit. Insbesondere führt er aus, dass die umsatzsteuerliche Behandlung keine Rückschlüsse auf die bilanzielle und ertragsteuerliche Behandlung von Software hat. Die Veräußerung von Standardsoftware durch einen Händler stellt hiernach4 keine Einräumung, Übertragung oder Wahrnehmung von Rechten dar, die sich aus dem Urheberrechtsgesetz ergäben, so dass die entsprechende Steuerermäßigung nach dem UStG nicht zu gewähren sei. Diese Differenzierung zwischen Urheberrechten auf der einen Seite und Produkten, die mittels eines Urheberrechtes eine bestimmte Eigenschaft erlangen, wird auch von der OECD getragen. In dem OECD-Musterabkommenskommentar zu Artikel 12 OECD-Musterabkommen (Musterabkommen zur Vermeidung der Doppelbesteuerung auf dem Gebiet der Steuern vom Einkommen und vom Vermögen, OECD-MA in der Fassung 2010) in Textziffer 12 ff. wird zwischen Copyrights, deren Überlassung zu Lizenzeinkünften führt, und copyrighted articles, die zu gewerblichen, unternehmerischen Einkünften führen5, unterschieden. d) Ausgewählte Beispiele zur steuerlichen Beurteilung und Bilanzierung von Software Ausgewählte Beispiele zur steuerlichen Beurteilung und Bilanzierung von Software: – Systemsoftware (Betriebssystem), die der Steuerung des Computers dient und sonst keine weitere praktische Anwendung hat, wird als selbständiges immaterielles Wirtschaftsgut behandelt. 1 2 3 4 5

BFH v. 18.5.2011 – X R 26/09, BStBl. II 2011, 865. BGH v. 18.10.1989 – VIII ZR 325/88, NJW 1990, 320. BFH v. 18.5.2011 – X R 26/09, BStBl. II 2011, 865. BFH v. 13.3.1997 – V R 13/96, BStBl. II 1997, 372. Diese Frage ist aus der Sicht des Internationalen Steuerrechts und der Aufteilung der Besteuerungsrechte bei der Bestimmung eines Quellensteuerrechts auch ohne Begründung einer Betriebsstätte von entscheidender Bedeutung.

Strunk

1367

12

P Rz. 13

Einzelprobleme

– Anwendersoftware hat ebenfalls keine feste Verbindung zur Hardware und wird daher ebenfalls als selbständiges immaterielles Wirtschaftsgut behandelt1. – Firmware, also Steuerungsprogramme in technischen Geräten sind demgegenüber unselbständiger Teil des technischen Geräts und daher vom materiellen Wirtschaftsgut nicht abzugrenzen und geben diesem auch nicht das Gepräge, so dass es zu einer Umqualifizierung kommen würde (z.B. Software in Kraftfahrzeugen). – Sofern Systemsoftware zusammen mit der Hardware verkauft wird und für die Software kein zusätzliches Entgelt vereinbart ist, handelt es sich um einen unselbständigen Bestandteil der Hardware. Wird demgegenüber eine gesonderte Berechnung vorgenommen, kommt es zum Vorliegen eines immateriellen Wirtschaftsgutes. – Trivialprogramme (alle Computerprogramme, deren Anschaffungskosten nicht mehr als 450 Euro betragen, gelten per se als Trivialprogramme, sonst hat eine gesonderte Prüfung stattzufinden) gehören nach Auffassung der Finanzverwaltung zu den abnutzbaren, beweglichen und selbständig nutzbaren Wirtschaftsgütern. – Datenträger, die nur Datenbestände beinhalten, gelten als materielle Wirtschaftsgüter. – Internetpräsenz gehört in Analogie zu Marken und ähnlichen Rechten sowie in Analogie zur Software zu den immateriellen Wirtschaftsgütern. – Domain-Name gehört nach Auffassung des BFH2 zu den immateriellen Wirtschaftsgütern, wobei immer dann, wenn der Domain kein markenähnlicher Wert zuzurechnen ist, eine Abschreibung nicht vorzunehmen ist. – Open Source Software ist ein immaterielles Wirtschaftsgut. Hierbei besteht jedoch die technisch und praktisch schwierige Aufgabe zu bestimmen, ob es sich nur um ein Wirtschaftsgut handelt oder um mehrere und wem diese Wirtschaftsgüter gehören3. – Software in der so genannten Cloud bereitet zahlreiche steuertechnische Probleme hinsichtlich der Umsatz- und Ertragsteuern, stellt jedoch die grundsätzliche Eigenschaft als Wirtschaftsgut nicht in Frage. 2. Bestimmung des wirtschaftlichen Eigentums 13 Von ebenfalls besonderer Bedeutung ist die Frage des Übergangs des wirtschaftlichen Eigentums an der Software. Grundsätzlich liegt dem Übergang des wirtschaftlichen Eigentums und damit eine für handelsrechtliche wie 1 BFH v. 28.7.1994 – III R 47/92, BStBl. II 1994, 873: „Software ist ein immaterielles Wirtschaftsgut, da das Produkt „geistig-schöpferischer Leistung“ gegenüber dem Materialwert des Datenträgers im Vordergrund steht.“ 2 BFH v. 19.10.2006 – III R 6/05, BStBl. II 2007, 301. 3 Zum Problem des wirtschaftlichen Eigentums s. Punkt 2.

1368

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 15

P

steuerrechtliche Zwecke erfolgte Realisation immer dann vor, wenn tatsächlich nicht nur die zivilrechtliche, sondern auch die wirtschaftliche Verfügungsmacht von einer Person auf eine andere Person übergeht. Das Steuerrecht unterscheidet sich hinsichtlich des Begriffsumfangs der Veräußerung erheblich von dem des Zivilrechtes. Der zivilrechtliche Begriff der Veräußerung umfasst hierbei jede Übertragung des rechtlichen Eigentums, wobei sowohl die entgeltliche als auch die unentgeltliche Rechtsübertragung erfasst werden. Demgegenüber sieht das nationale deutsche Steuerrecht eine Veräußerung nur dann als gegeben an, wenn es sich um die entgeltliche Übertragung des rechtlichen oder zumindest des wirtschaftlichen Eigentums von einer Person auf eine andere Person handelt. Ausgangspunkt der Überlegungen hinsichtlich der Bedeutung des wirt- 14 schaftlichen Eigentums im Handels- und Steuerrecht ist zunächst die Feststellung, dass der Kaufmann gem. § 246 HGB sein Vermögen, d.h. dem Vollständigkeitsverbot folgend alle Vermögensgegenstände, zu bilanzieren hat. Im Grundsatz wird das Handelsgesetzbuch vom Eigentumsbegriff des Bürgerlichen Gesetzbuches geprägt. Danach ist Eigentum im Sinne des § 39 AO das in § 903 BGB i.V.m. § 90 BGB behandelte umfassende Herrschaftsrecht an einer Sache. Gegenstand des Eigentums können also nur Sachen, d.h. körperliche, bewegliche oder unbewegliche Gegenstände sein. Im Gegensatz dazu ist der Begriff des wirtschaftlichen Eigentums, wie er dem § 39 Abs. 2 Nr. 1 AO zugrunde liegt, wesentlich weiter. Dieser umfasst neben Sachen auch Forderungen, Rechte sowie sonstige wirtschaftliche Vorteile, die durch eindeutige und klar abgrenzbare Aufwendung erlangt worden sind, dem Betrieb ein über das Ende der Wirtschaftsperiode hinausgehenden Nutzen zu bringen versprechen und nach der Verkehrsauffassung selbständig bewertungsfähig sind, also die Wirtschaftsguteigenschaft erfüllen. Das Handelsrecht verlangt in § 246 HGB, dass der Kaufmann sein gesamtes 15 Vermögen zu bilanzieren hat. Was jedoch unter seinem Vermögen zu verstehen ist, ob es sich nur um das rechtliche oder auch um das so genannte wirtschaftliche Eigentum handelt, war im Handelsrecht lange Zeit nicht näher definiert. Erst seit der Änderung des HGB durch das BilMoG1 ist der Grundsatz der Bilanzierung nach dem wirtschaftlichen Eigentum in § 246 Abs. 2 HGB aufgenommen worden. Hierbei hat der Handelsgesetzgeber auf eine eigenständige Definition verzichtet und verweist hinsichtlich des Begriffsinhaltes auf die Vorschrift in der AO. In § 39 Abs. 2 Nr. 1 AO heißt es: „Übt ein anderer als der Eigentümer [gemeint ist der zivilrechtliche Eigentümer] die tatsächliche Herrschaft über ein Wirtschaftsgut in der Weise aus, dass er den Eigentümer [zivilrechtlichen Eigentümer] im Regelfall für die gewöhnliche Nutzungsdauer von der Einwirkung auf das Wirtschaftsgut wirtschaftlich ausschließen kann, so ist ihm das Wirtschaftsgut zuzurechnen.“ Diese Regelung besagt nicht mehr und nicht weniger, als dass abweichend vom zivilrechtlichen Eigentum für handelsrechtliche Zwecke wie für 1 Bilanzrechtsmodernisierungsgesetz vom 25.5.2009, BGBl. I S. 1102.

Strunk

1369

P Rz. 16

Einzelprobleme

steuerliche Zwecke dem so genannten wirtschaftlichen Eigentümer, also dem Vertragspartner, das Eigentum so zuzurechnen ist, dass er die wirtschaftliche Substanz innehat und über diese wirtschaftliche Substanz mit allen Chancen und Risiken für die gesamte oder nahezu gesamte Nutzungsdauer des Wirtschaftsgutes verfügen kann. Die wichtige Frage hierbei ist regelmäßig, wann eine Übertragung des Eigentums vom zivilrechtlichen Eigentümer auf einen Dritten stattgefunden hat. Der Fall ist weitgehend eindeutig, wenn der zivilrechtliche Eigentümer und der wirtschaftliche Eigentümer nicht auseinander fallen, doch sind zahlreiche Fälle denkbar, bei denen genau letztgenanntes passiert. Insbesondere bei Leasing- und Mietsowie Mietkaufregelungen, aber auch bei Lizenzverträgen ist sehr genau zu prüfen, ob das wirtschaftliche Eigentum übergeht. Für die hierzu zu untersuchende Frage, ob § 39 Abs. 2 Nr. 1 AO tatsächlich eine hinreichend gute Anwendungsmöglichkeit auch für immaterielle Wirtschaftsgüter bietet, fehlt es an einer einheitlichen Meinung in Kommentierung, Rechtsprechung und Finanzverwaltung. Es ist wohl davon auszugehen, dass die so genannten Leasingerlasse der Finanzverwaltung, die für die Bilanzierungspraxis eine wichtige Stütze hinsichtlich der Frage des Übergangs des wirtschaftlichen Eigentums bzw. der Zuordnung des wirtschaftlichen Eigentums sind, auch auf immaterielle Vermögensgegenstände Anwendung findet, doch sind eine Vielzahl von Fragen bisher ungeklärt. 16 So ist bspw. im Gegensatz zu einem materiellen Wirtschaftsgut die Sachherrschaft bei immateriellen Vermögensgegenständen und Wirtschaftsgütern nicht gegeben, so dass eine Mehrfachnutzung, möglicherweise ein und desselben Wirtschaftsgutes oder auch nur einer Kopie eines Wirtschaftsgutes jederzeit denkbar. Laut ständiger Rechtsprechung erfolgt die Bilanzierung nach wirtschaftlichen Kriterien, wenn der Bilanzierende gegenüber dem zivilrechtlichen Eigentümer eine abgesicherte Rechtsposition hat, die es ihm ermöglicht, den zivilrechtlichen Eigentümer für die gewöhnliche Nutzungsdauer von der Einwirkung auf das Wirtschaftsgut wirtschaftlich auszuschließen. Weil das konstitutive Merkmal der Sachherrschaft auf immaterielle Wirtschaftsgüter nicht anwendbar ist, erscheint eine Übertragung der Grundsätze des § 39 Abs. 2 Nr. 1 AO auch auf immaterielle Vermögensgegenstände keineswegs gesichert. Da der zivilrechtliche Eigentümer nie vollständig von dem Einwirken auf das Recht oder die Software ausgeschlossen werden kann, ist unter Anwendung der wirtschaftlichen Betrachtungsweise auf die Erwartungen des Bilanzierenden, den Gegenstand bzw. das Nutzungsrecht produktiv, d.h. mit den verbundenen Chancen und Risiken, einsetzen zu können, abzustellen. Liegt ein uneingeschränktes Nutzungsrecht für den Bilanzierenden vor, so dass die Ertragserwartungen nicht mehr durch Rechte Dritter entzogen werden können, dann sind die Grundsätze des § 39 Abs. 2 Nr. 1 AO auch auf immaterielle Wirtschaftsgüter anzuwenden. 17 Ungeachtet des Umstandes, wie man die Frage der Zuordnung des wirtschaftlichen Eigentums bei immateriellen Wirtschaftsgütern beantwortet, 1370

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 19

P

bleibt festzustellen, dass es keine einheitlichen Regelungen hierzu gibt und dass es weitgehend in das Ermessen des Bilanzierenden bzw. des von ihm geprüften Wirtschaftsprüfers abhängt, ob wirtschaftliches Eigentum und damit eine Umsatz- und Gewinnrealisierung entstanden ist oder nicht. Gerade im internationalen Steuerrecht ist die Frage der Zuordnung von Wirtschaftsgütern zu einer Person besonders wichtig, denn wenn eine Übertragung des wirtschaftlichen Eigentums stattgefunden hat, kann typischerweise nicht eine Qualifizierung als Lizenzeinkünfte mit laufenden Quellensteuerzahlungen zum Tragen kommen. Rechtsprechung zur handelsrechtlichen oder steuerrechtlichen Übertragung 18 des wirtschaftlichen Eigentums bei Software in Deutschland liegt derzeit nicht vor, so dass auf die Rechtsprechung zum Übergang des wirtschaftlichen Eigentums bei anderen immateriellen Vermögensgegenständen, insbesondere von Wertpapieren und Rechten, zurückgegriffen werden muss. Hinsichtlich der Veräußerung von Gesellschaftsrechten haben die Finanzverwaltung1 und die Rechtsprechung2 festgestellt, dass eine Veräußerung nur dann vorliegt, wenn das wirtschaftliche Eigentum auf den Erwerber übergeht. Eine Veräußerung ist immer dann gegeben, wenn dem Erwerber alle wesentlichen Rechte übertragen wurden. Für den Bereich der Software stellt sich hierbei insbesondere die Frage, ob die Zurückbehaltung bestimmter Rechte, wie z.B. Vertriebsrechte für bestimmte Regionen oder das Recht zur fortgesetzten Nutzung des Rechts für die eigene Herstellung, die Übertragung des wirtschaftlichen Eigentums verhindern. Die Frage kann derzeit nicht abschließend beantwortet werden, ist jedoch aufgrund der Rechtsprechung zum wirtschaftlichen Übergang bei Wertpapieren als äußerst wahrscheinlich anzusehen. Das folgende Beispiel soll die steuerliche Brisanz der Frage der Zurechnung 19 von Wirtschaftsgütern anhand der Bestimmungen des wirtschaftlichen Eigentums verdeutlichen. Beispiel: Ein deutsches Unternehmen erwirbt zum Preis von 1 Mio. Euro das Urheberrecht an einer Software von einem fremden Dritten. Das Unternehmen erwartet erhebliche Wertsteigerungen aufgrund weiterer technischer Entwicklungen. Daher erfolgt zeitnah im Anschluss an den Erwerb eine Veräußerung des Rechtes an eine Konzerngesellschaft auf den British Virgin Islands zu einem Preis von 1,2 Mio. Euro. Die Gesellschaft auf den British Virgin Islands, die sonst keinerlei Aktivitäten unterhält, überlässt gegen laufende monatliche Zahlung die Lizenz- und Verwertungsrechte einem anderen US-Konzernunternehmen. Die US-Gesellschaft ihrerseits wiederum überlässt die übertragenden Rechte nach erfolgter Wertsteigerung aufgrund technischer Entwicklungen bei Hardware zum Preis von 10 Mio. Euro an einen fremden Dritten. Die Fragen, die sich hierbei regelmäßig stellen, sind: 1 Veräußerung i.S.d. § 17 Abs. 1 EStG ist die entgeltliche Übertragung des rechtlichen oder zumindest des wirtschaftlichen Eigentums an einer Beteiligung auf einen anderen Rechtsträger, H 17 EStRl. 2 BFH v. 17.2.2004 – VIII R 28/02, BStBl. II, 651 sowie DStRE 2004, 886.

Strunk

1371

P Rz. 20

Einzelprobleme

– Wer ist wirtschaftlicher Eigentümer? – Wo sind die realisierten Veräußerungsgewinne zu versteuern?

20 Im vorliegenden Beispiel ist u.a. darüber nachzudenken, ob eine zivilrechtlich anzuerkennende Veräußerung des Rechts von der deutschen Gesellschaft auf die Konzerngesellschaft auf den British Virgin Islands überhaupt eine Übertragung des wirtschaftlichen Eigentums darstellen kann. Wird die Gesellschaft auf den British Virgin Islands als eigenständiges Rechtsobjekt anerkannt, so müsste man von einer Übertragung des wirtschaftlichen Eigentums ausgehen. Handelt es sich demgegenüber um eine Gesellschaft, deren steuerliche Anerkennung versagt wird, hat ungeachtet der zivilrechtlichen Würdigung keine Übertragung im steuerrechtlichen Sinne stattgefunden mit der Konsequenz, dass alle Wertsteigerungen und alle zukünftigen Erträge tatsächlich der deutschen Besteuerung unterliegen. Eine weitere Frage, die an dieser Stelle zu klären ist, ist die Frage, ob die vertraglichen Vereinbarungen zwischen der deutschen Gesellschaft und der Konzerngesellschaft auf den British Virgin Islands und der US-Konzerngesellschaft tatsächlich zur Übertragung des wirtschaftlichen Eigentums geführt haben. In Abhängigkeit von der Beantwortung dieser einzelnen Fragen kommt es entweder zur Besteuerung des Veräußerungsgewinns in Höhe von ca. 9 Mio. Euro auf den Britisch Virgin Islands oder in den USA oder möglicherweise in mehreren dieser Rechtsordnungen. Dies alles steht in Abhängigkeit von der Frage, wer zu welchem Zeitpunkt wirtschaftlicher Eigentümer des Rechts ist.

III. Steuerliche Aspekte bei Inlandssachverhalten 21 Bei der steuerlichen Beurteilung von Software sind sowohl ertragsteuerliche als auch umsatzsteuerliche Aspekte zu beachten. Die ertragsteuerlichen Aspekte sind danach zu differenzieren, ob ein Unternehmen oder eine natürliche Person die Software selbst entwickelt oder erworben hat und die Software zur Erzielung eigener Einkünfte einsetzt oder ob es sich um ein nutzendes Unternehmen im Sinne eines Lizenznehmers handelt. Die entsprechende Unterscheidung ist auch für die umsatzsteuerliche Beurteilung vorzunehmen, wobei jedoch einige weitere Aspekte des Umsatzsteuerrechts kurz angesprochen werden sollen. Abschließend sollen grenzüberschreitende Lizenzverträge über die Softwareüberlassungen aus steuerlicher Sicht näher untersucht werden. 1. Steuerliche Behandlung beim Entwickler der Software 22 Sofern eine natürliche Person regelmäßig am so genannten allgemeinen wirtschaftlichen Verkehr teilnimmt, selbständig, nachhaltig und mit Gewinnerzielungsabsicht Software entwickelt und diese Software im Wege des Verkaufs oder der Lizenzierung, also Einräumung von Nutzungsrechten an der Software, wirtschaftlich verwertet, erzielt sie Einkünfte aus selbständiger Arbeit im Sinne des § 18 EStG. Der Steuerpflichtige darf in diesen Fäl1372

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 25

P

len seinen Gewinn nicht nach dem Betriebsvermögensvergleich (Bilanzierung), sondern nach einer vereinfachten Methode auf Ebene der Einnahmen und Ausgaben, wobei der Gewinn der Überschuss der Einnahmen über die Ausgaben ist, ermitteln. Nach § 4 Abs. 3 EStG können diejenigen Steuerpflichtigen ihren Gewinn ermitteln, die nicht durch Gesetz (§§ 140 ff. AO oder §§ 238 ff. HGB) zur Buchführung verpflichtet sind. Hierbei handelt es sich neben der Gruppe der Freiberufler weiter um sog. Kleingewerbetreibende. Ausgaben und Einnahmen wirken sich bei der Gewinnermittlung nach § 4 Abs. 3 EStG grundsätzlich in dem Jahr ihres Zu- bzw. Abflusses aus (§ 11 EStG). Erwirbt der Steuerpflichtige die Software jedoch selbst, erzielt er Einkünfte aus Gewerbebetrieb und ist aufgrund dessen sowohl nach Handelswie auch nach Steuerrecht buchführungs- und bilanzierungspflichtig und hat einen Jahresabschluss aufzustellen, in dem die oben genannten bilanziellen Vorgaben zu beachten sind. Für Kapitalgesellschaften gilt demgegenüber, dass diese ungeachtet ihrer 23 originären Tätigkeit nur gewerbliche Einkünfte erzielen können und insbesondere die Einkünfte aus selbständiger wie nichtselbständiger Art einer Kapitalgesellschaft wesensfremd sind und deshalb auch bei ausländischen Kapitalgesellschaften, die in Deutschland unternehmerisch tätig sind, nicht anzunehmen sind. Die Kapitalgesellschaft hat steuerlich das Aktivierungsverbot des § 5 Abs. 2 EStG zu beachten und alle Aufwendungen für die Erstellung der Software im Jahr des liquiditätsmäßigen Abflusses als Betriebsausgaben gewinnmindernd anzusetzen. Sofern die Gesellschaft aufgrund anderer geschäftlicher Aktivitäten Gewinne erwirtschaftet, können diese mit dem Aufwand verrechnet und zunächst eine Besteuerung vermieden werden. Bei erworbener Software kann eine planmäßige Abschreibung, wie oben bereits erläutert, vorgenommen werden. Nach § 5 Abs. 3 Satz 1 Nr. 1 EStG kann wegen einer Verletzung fremder Pa- 24 tent-, Urheber- oder ähnlicher Schutzrechte unter bestimmten Voraussetzungen eine Rückstellung gebildet werden. Die Bildung der Rückstellung ist zulässig, wenn der Rechtsinhaber Ansprüche wegen der Rechtsverletzung geltend gemacht hat oder mit einer Inanspruchnahme wegen der Rechtsverletzung ernsthaft zu rechnen ist. Die Höhe der Rückstellung richtet sich primär nach dem befürchteten Schaden. Bleibt die Inanspruchnahme wegen der Rechtsverletzung aus, muss eine ggf. gebildete Rückstellung spätestens in der Bilanz des dritten, auf die Bildung der Rückstellung folgenden Wirtschaftsjahres gewinnerhöhend aufgelöst werden. Die Lizenzerträge unterliegen der regulären Gewerbesteuer, so dass die Ka- 25 pitalgesellschaft mit ihren Einkünften einer Besteuerung von zumeist 30 % unterliegt, wobei 15 % Körperschaftssteuersatz und in Abhängigkeit von den gemeindlichen Hebesätzen für die Gewerbesteuer durchschnittlich noch einmal 15 % Gewerbesteuer zu zahlen ist.

Strunk

1373

P Rz. 26

Einzelprobleme

2. Steuerliche Behandlung beim Lizenznehmer der Software 26 Lizenzrechte an Software unterscheiden sich steuerlich nicht von Lizenzrechten an anderen immateriellen nutzbaren Wirtschaftsgütern. Lizenzrechte werden nach der Rechtsprechung des BFH unabhängig von deren Ausgestaltung als immaterielle Wirtschaftsgüter betrachtet1. Von entscheidender Bedeutung für die bilanzielle Behandlung von Lizenzrechten ist die konkrete Ausgestaltung der Überlassung des Lizenzrechts. Lizenzüberlassung gegen laufende Gegenleistung: 27 Üblicherweise werden Lizenzgebühren vom Lizenznehmer nicht in einem Betrag bei Anschaffung oder Begründung des Lizenzrechtes, sondern in laufenden Beträgen, z.B. monatlich oder abhängig von der Anzahl der Nutzer, gezahlt. Insoweit stellen Lizenzverträge Dauerschuldverhältnisse, wie z.B. Miete und Pacht, dar. Außerdem liegen insoweit schwebende Geschäfte vor. Unter schwebenden Geschäften werden gegenseitige Verträge verstanden, die noch von keiner Seite erfüllt sind. Die laufenden Lizenzzahlungen für die Software stellen keine Anschaffungskosten für das Recht als solches dar, sondern sind vielmehr eine Gegenleistung für die fortwährende Nutzung der Lizenz. Die laufenden Lizenzgebühren sind demnach in dem Wirtschaftsjahr, dem sie zeitlich zuzuordnen sind, als Betriebsausgaben zu berücksichtigen. Geleistete Anzahlungen für die Lizenzüberlassung sind zu aktivieren, da aufgrund der Zahlung ein Anspruch und somit ein eigenständiges Wirtschaftsgut entsteht2. Anschaffungsnebenkosten auf schwebende Geschäfte sind jedoch ausgeschlossen3. Lizenzüberlassung gegen Einmalzahlung: 28 Nach den oben skizzierten Grundsätzen ist von Anschaffungskosten auszugehen, wenn die Lizenzrechte für einen bestimmten Zeitraum gegen ein einmaliges Entgelt erworben werden. Dies hat der BFH in seiner viel beachteten Entscheidung zum Alleinvertriebsrecht entschieden4. Die Anschaffungskosten der erworbenen Rechte sind linear über die Nutzungsdauer abzuschreiben. Gem. § 7 Abs. 2 EStG sind für Lizenzrechte als immaterielle Wirtschaftsgüter degressive Abschreibungen untersagt. Außerplanmäßige Abschreibungen sind jedoch bei entsprechendem Nachweis zulässig5. 29 Hinsichtlich der Frage, wann bei Lizenzverträgen das wirtschaftliche Eigentum vom Lizenzgeber auf den Lizenznehmer übergeht, kann nach den oben dargelegten Argumenten nur im Einzelfall eine Beantwortung vorgenommen werden. 1 BFH v. 19.6.1997 – IV R 16/95, BStBl. II 1997, 808. 2 BFH v. 25.9.2009 – I R 86/07, BStBl. II 2010, 120 mit weiteren Hinweisen auf die Rechtsprechung zur Bilanzierungsfähigkeit von Transferzahlungen bei Fußballspielern. 3 BFH v. 19.6.1997 – IV R 16/95, BStBl. II 1997, 808. 4 BFH v. 27.7.1988 III R 49/83, BStBl. II 1989, 101. 5 S. hierzu beispielhaft FG Nds. v. 18.11.2009 – 2 K 100/07, EFG 2010, 699.

1374

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 32

P

3. Umsatzsteuerliche Aspekte Die Lizenzgewährung stellt umsatzsteuerlich grundsätzlich eine sonstige 30 Leistung gem. §§ 3, 3a UStG dar, die, wenn sowohl Lizenznehmer als auch Lizenzgeber im Inland ansässig sind, steuerbar und in der Regel mangels Steuerbefreiung auch steuerpflichtig ist. Ausnahmen hiervon bestehen u.U. jedoch bei der Überlassung von Computerprogrammen. Nach Auffassung der Finanzverwaltung ist der Verkauf von Standardsoftware auf Datenträgern, wie z.B. einer DVD, als Lieferung zu beurteilen (R 25 Abs. 2 Nr. 7 UStR 2009). Der Ort der Lieferung bestimmt sich dann nach § 3 Abs. 7 UStG. Für die Höhe der Umsatzsteuer ist insbesondere § 12 Abs. 2 Nr. 7 lit. c UStG zu beachten. Für die Einräumung, Übertragung und Wahrnehmung von Rechten, die sich aus dem Urheberrechtsgesetz ergeben, ermäßigt sich der Steuersatz nach dieser Vorschrift auf 7 %. Diese Befreiung gilt jedoch nur für sonstige Leistungen, nicht jedoch für die oben beschriebenen Lieferungen. Im Ergebnis ist daher festzustellen, dass in Abhängigkeit von der vertraglichen Ausgestaltung, aber auch in Abhängigkeit von der tatsächlichen Umsetzung der Rechteüberlassung zum Teil massiv andere Steuerbelastungen zu beachten sind, die bewusst von den Handelnden herbeigeführt werden können. Bei grenzüberschreitenden Vorgängen ist stets darauf zu achten, ob an einen Unternehmer im EU-Ausland oder in einem Drittstaat geleistet wird oder an einen Nichtunternehmer. Die umsatzsteuerlichen Konsequenzen liegen bei Unternehmern als Leistungsempfängern regelmäßig darin, dass der Ort der Leistung nicht mehr der Ort des leistenden Unternehmers ist, sondern der Ort des empfangenden Unternehmers. Entsprechende steuerliche Vorschriften für den leistenden Unternehmer, wie z.B. nach § 13b UStG das so genannte Reverse-Charge-Verfahren, sind zu berücksichtigen. Beispiel: Ein deutsches Unternehmen lizenziert Software an eine im Ausland ansässige Person. Diese Person behauptet, sie sei Unternehmer im Sinne des UStG. Das deutsche Unternehmen weist in seiner deutschen Rechnung keine deutsche Umsatzsteuer aus, da gem. § 3a Abs. 4 i.V.m. § 3a Abs. 3 UStG der Ort der Leistung nicht in Deutschland liegt.

In der Praxis häufig ein Streitpunkt, wer die Nachweispflicht für die Unter- 31 nehmereigenschaft des Kunden zu erbringen hat, wobei die Finanzverwaltung diese Pflicht meines Erachtens zu Unrecht beim steuerpflichtigen Unternehmer sieht. 4. Gewerbesteuer Gem. § 8 Nr. 1 lit. f GewStG sind dem Gewerbeertrag Lizenzzahlungen, die 32 an einen Dritten gezahlt wurden, hinzuzurechnen. Ein Viertel der Aufwendungen für die zeitlich befristete Überlassung von Rechten (insbesondere Konzessionen und Lizenzen, mit Ausnahmen von Lizenzen, die ausschließlich dazu berechtigen, daraus abgeleitete Rechte Dritten zu überlassen) werden bei Überschreiten eines Freibetrages von 100 000 Euro hinzugerechnet. Strunk

1375

P Rz. 33

Einzelprobleme

Eine Hinzurechnung nach § 8 Satz 1 Nr. 1 lit. f GewStG ist nicht vorzunehmen auf Aufwendungen, die nach § 25 KSVG Bemessungsgrundlage für die Künstlersozialabgabe sind. Die zuerst genannte Ausnahmevorschrift führt bei so genannten Verkehrslizenzen zu einer Nichthinzurechnung der Aufwendungen zum Gewerbeertrag.

IV. Internationale Bezüge 33 Der inländische Unternehmer unterliegt mit seinen weltweiten Einkünften der unbeschränkten Steuerpflicht in Deutschland. Dies schließt jedoch generell nicht aus, dass der ausländische Staat, aus dem die Einnahmen stammen, ebenfalls einen Besteuerungstatbestand annimmt und eine Besteuerung vornimmt. Sofern zwischen den beiden Staaten ein Abkommen zur Vermeidung der Doppelbesteuerung besteht, welches die Zuweisung der Besteuerungsrechte zwischen den Vertragsstaaten regelt, ist zu prüfen, um welche Einkunftsart im Sinne des Abkommens es sich handelt. Grundsätzlich folgen die deutschen Doppelbesteuerungsabkommen (DBA) dabei den Vorgaben des OECD-MA. In Art. 12 OECD-MA ist grundsätzlich geregelt, dass Lizenzeinnahmen ausschließlich im Staat des Vergütungsgläubigers zu besteuern sind und der Quellenstaat kein Besteuerungsrecht hat. Die wirtschaftliche Überlegung hinter dieser steuerlichen Behandlung ist, dass bei einer Quellensteuer auf Basis der Einnahmen und nicht der Einkünfte (also als Differenz zwischen Einnahmen und Betriebsausgaben) die Gefahr der Überbesteuerung recht hoch ist. Insbesondere in den Fällen, in denen der Lizenzgeber das Recht selber einlizenziert und eine vergleichsweise niedrige Umsatzrendite hat, besteht die Gefahr, dass selbst bei einem niedrigen Quellensteuersatz auf die Einnahmen der gesamte Ertrag besteuert wird. 34 In diesen Fällen würde das Besteuerungsrecht des Ansässigkeitsstaates des Vergütungsschuldners ins Leere laufen. Lizenzgebühren nach dem Recht der DBA sind Vergütungen jeder Art, die als Gegenleistung für die Benutzung oder das Recht auf Benutzung bestimmter (Lizenz-)Gegenstände gezahlt werden. Hinsichtlich der Umsetzung in die deutsche DBA-Praxis siehe nachfolgende Übersicht. Deutschland hat in einer Vielzahl von Fällen eine Quellensteuer für den Ansässigkeitsstaat dennoch vereinbart. In diesen Fällen sowie in Fällen, in denen kein DBA besteht, aber gleichwohl im Ausland auf die Einkünfte Steuern gezahlt wurden, stellt sich die Frage der Vermeidung oder Milderung der eingetretenen Doppelbesteuerung. Die ebenfalls nach den Regelungen der DBA mögliche Freistellung der ausländischen Einkünfte kommt im vorliegenden Fall der Lizenzeinkünfte nicht zum Tragen. Vielmehr wird die Doppelbesteuerung durch Anrechnung der im Ausland gezahlten Steuern vermieden.

1376

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 37

P

§ 34c EStG beinhaltet die unilateralen Maßnahmen zur Vermeidung der 35 Doppelbesteuerung. Gem. § 34c Abs. 1 EStG kann eine ausländische Steuer im Inland angerechnet werden, sofern die Steuer bestimmten Anforderungen genügt. § 34c Abs. 2 EStG gibt dem Steuerpflichtigen die Möglichkeit, an Stelle der Anrechnung den Abzug der im Ausland gezahlten Steuer von der inländischen Bemessungsgrundlage zu beantragen, sofern dies für ihn günstiger ist. § 34c Abs. 3 EStG trifft Vorgaben für den Fall, dass eine Anrechnung nach § 34c Abs. 1 EStG wegen der fehlenden Steueridentität oder der nicht gegebenen Übereinstimmung des Besteuerungszeitraums nicht erfolgen kann. Nun gelangt im Inland die Abzugsmethode zur Anwendung. 1. Lizenzvergabe an inländische Lizenznehmer durch ausländische Unternehmer Das im Ausland ansässige Unternehmen ist grundsätzlich nicht unbe- 36 schränkt steuerpflichtig in Deutschland. Vielmehr ist das Unternehmen beschränkt steuerpflichtig, wenn inländische Einkünfte vorliegen. Liegen solche Einkünfte vor, ist in einem weiteren Schritt zu prüfen, ob ein DBA vorliegt und ob nach den Regelungen des DBA Deutschland das Besteuerungsrecht für die Einkünfte behält. Als steuerbare und steuerpflichtige Einkünfte i.S.d. § 49 Abs. 1 EStG kommen solche i.S.d. § 49 Abs. 1 Nr. 2 EStG in Frage. Zu den Sondertatbeständen des § 49 Abs. 1 Nr. 2 EStG gehören seit dem Veranlagungszeitraum 2008 auch Einkünfte aus der Veräußerung von inländischem unbeweglichem Vermögen, von Sachinbegriffen oder Rechten, die im Inland belegen oder in ein inländisches öffentliches Buch oder Register eingetragen sind. Durch den Verzicht auf den Verweis von Rechten iS.d § 49 Abs. 1 Nr. 6 EStG erfolgt eine inhaltliche Ausweitung auf sämtliche Rechte, die den geforderten Inlandsbezug aufweisen. Liegt eine vollständige Aufgabe des Rechts vor, wie dies üblicherweise bei der Gewährung einer Alleinnutzungsmöglichkeit für eine Software der Fall ist, muss von einer Veräußerung und nicht von einer Überlassung ausgegangen werden. Die sich daraus ergebenden Einkünfte führen zur beschränkten Steuerpflicht, wenn die Voraussetzungen des § 49 Abs. 1 Nr. 2 lit. f EStG erfüllt sind. Wird nicht die Vermögenssubstanz übertragen, sondern nur eine Nutzung gewährt, liegen Einkünfte i.S.d. § 49 Abs. 1 Nr. 6 EStG vor. Diese können u.a. gegeben sein, wenn die überlassene Software in einer inländischen Betriebsstätte oder in einer anderen Einrichtung verwertet wird. Hierfür sind die folgenden Tatbestandsvoraussetzungen entscheidend: – Es muss sich um eine Vermietungs- oder Verpachtungstätigkeit handeln, – die unbewegliches Vermögen, Sachinbegriffe oder Rechte zum Gegenstand hat, – welche entweder im Inland belegen oder in ein inländisches Register eingetragen sind oder die im Inland in einer Betriebsstätte oder ähnlichen Einrichtung verwertet werden.

Strunk

1377

37

P Rz. 38

Einzelprobleme

38 Zu den Rechten i.S.d. § 49 Abs. 1 Nr. 6 EStG gehören insbesondere schriftstellerische, künstlerische und gewerbliche Urheberrechte, also Rechte, die nach dem UrhG gesetzlich geschützt sind. Ferner fallen unter Rechte auch Gefälligkeiten, Gefälle und Rechte zur Verwertung gewerblicher Erfahrungen. Vor allem bei den urheberrechtlich geschützten Rechten ist auf die Abgrenzung zu den Einkünften gem. § 49 Abs. 1 Nr. 1–3 EStG zu achten. Weiteres Erfordernis für die Annahme von Einkünften i.S.d. § 49 Abs. 1 Nr. 6 EStG ist die zeitlich begrenzte Überlassung des Rechts. Diese liegt auch dann vor, wenn bei Abschluss des Vertrages ungewiss ist, ob und wann die Überlassung zur Nutzung endet. Folglich ist eine zeitlich begrenzte Überlassung von Rechten anzunehmen, wenn bei Abschluss des Vertrages ungewiss ist, ob und wann die Überlassung zur Nutzung endet. Der Lizenzgeber darf sich nicht endgültig seiner Rechtsstellung begeben, weder unbegrenzt noch auf einige wenige Länder bezogen. Auf die rechtliche Qualifikation des Nutzungsverhältnisses kommt es hierbei nicht an; sowohl schuldrechtliche als auch ausschließlich dingliche Nutzungsverhältnisse begründen die nach § 49 Abs. 1 Nr. 6 EStG geforderte Überlassung1. 39 Die in § 49 Abs. 1 Nr. 6 EStG genannten Einkünfte lassen sich in den Doppelbesteuerungsabkommen nicht generell nur unter einer Einkunftsart subsumieren, sondern müssen unterschiedlichen Einkunftsarten zugewiesen werden, was zu sehr verschiedenen Rechtsfolgen führt. Die Unterscheidung zwischen Copyrights und copyrighted Articles führt zur Zuordnung der erstgenannten Art zu Einkünften aus Lizenzen gem. Art. 12 OECD-MA und bei den copyrighted Articles zu den Einkünften gem. Art. 7 OECD-MA, den Unternehmensgewinnen. Die Zurechnung zu den Unternehmensgewinnen führt dazu, dass für die abkommensrechtliche Zuweisung eines – nach nationalen Regelungen gegebenen – Besteuerungsrechts das Vorliegen einer Betriebsstätte oder eines ständigen Vertreters im Inland erforderlich ist2. In diesen Fällen wäre anders als bei Anwendung des Art. 12 OECD-MA eine Besteuerung im Quellenstaat möglich. Der Hauptanwendungsfall für Einkünfte aus Vermietung und Verpachtung (VuV) bzw. aus Lizenzgebühren ist die zeitlich befristete Überlassung von Rechten, die unter Art. 12 Abs. 2 OECD-MA explizit genannt sind. Eine weitergehende Übereinstimmung besteht zwischen dem Begriff der „Nutzungsüberlassung“ des nationalen Steuerrechts und dem Abkommensrecht, so dass Einkünfte gem. § 49 Abs. 1 Nr. 6 EStG aus der Überlassung von Rechten auch unter Art. 12 Abs. 1 OECD-MA zu subsumieren sind und insoweit ausschließlich im Ansässigkeitsstaat besteuert werden. Eine Besteuerung im Quellenstaat erfolgt nur dann, wenn eine Anwendung des Art. 12 OECD-MA zu Gunsten einer anderen Ein-

1 BFH v. 7.12.1977 – I R 54/75, BStBl. II 1978, 355; BFH v. 23.5.1979 – I R 163/77, BStBl. II 1979, 757; BFH v. 27.2.1996 – III R 64/74, BStBl. II 1976, 529. 2 Zur Abgrenzung von Arbeitseinkünften i.S.d. Art. 14 OECD-MA und Lizenzeinkünften i.S.d. Art. 12 OECD-MA s. BFH v. 13.10.1976 – I R 261/70, BStBl. II 1977, 76 sowie v. 29.4.1970 – I R 113/67, BStBl. II 1970, 762.

1378

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 40

P

kunftsart ausscheidet oder abkommensrechtlich auch dem Quellenstaat ein in der Höhe beschränktes Besteuerungsrecht zusteht1. Sowohl einige deutsche DBA als auch das Musterabkommen der UNO sehen ein in der Höhe beschränktes Quellensteuerrecht des Quellenstaates vor. Hierdurch sollen vor allem Entwicklungsländer geschützt werden, die durch eine solche Regelung Zugriff auf das Steuersubstrat nehmen können. Die OECD-Staaten untereinander lehnen eine solche Gewährung des Besteuerungsrechts jedoch ab, da mit einer Quellensteuer von 5 bis 10 % in vielen Fällen bereits das gesamte Steuergut abschließend besteuert wird und dem Ansässigkeitsstaat kein wirtschaftlich nennenswertes, eigenständiges Besteuerungsrecht verbleibt2. Eine Besteuerung im Quellenstaat ist neben einer originär anderen Einkunftsqualifizierung bei der Überlassung von Sachinbegriffen oder Rechten auch dann gegeben, wenn die Lizenzeinkünfte dem Subsidiaritätsgedanken folgend derivativ den Unternehmensgewinnen oder den Einkünften aus selbständiger Arbeit zuzurechnen sind. Ist das den Lizenzgebühren zugrunde liegende Vermögen wirtschaftlich einer Betriebsstätte oder einer festen Einrichtung zuzuordnen3, so kommt es abkommensrechtlich gem. Art. 12 Abs. 3 OECD-MA zu einer Zuweisung des Besteuerungsrechts zum Quellenstaat. Diese Zuweisung erfolgt unabhängig davon, welche Einkunftsqualifzierung der Quellenstaat nach nationalem Steuerrecht vornimmt. 2. Abkommensübersicht und Besonderheiten in einzelnen deutschen Abkommen DBA

Quellensteuersatz

Ägypten 1987

15 (25)

Argentinien 1978/1996

Unbeschränkt (15)

Algerien 2007

10

Albanien 2010

5

Aserbaidschan

5 (10)

Australien 1972

10

Bangladesch 1990

10

40

1 In der deutschen Abkommenspraxis gilt dies bspw. für die DBA mit Australien (BStBl. I 1974, 424), mit Japan (BStBl. I 1967, 59 in der Fassung des 3. Änderungsprotokolls v. 17.2.1983, BGBl. II 1984, 194), mit Finnland (BStBl. I 1981, 201) und zahlreichen Entwicklungsländern. 2 Die Bundesrepublik Deutschland hat abweichend von dieser Praxis z.B. mit den „Entwicklungsländern“ Finnland, Art. 12 Abs. 1 Satz 2 DBA-Finnland (BStBl. I 1981, 201), und Japan, Art. 12 Abs. 1 Satz 2 DBA-Japan (BStBl. I 1967, 59) Regelungen getroffen, die ein Quellensteuerrecht von 5 % bzw. 10 % festschreiben. 3 Vgl. Wassermeyer in Debatin/Wassermeyer, Art. 12 OECD-MA Rz. 102 (Oktober 2001).

Strunk

1379

P Rz. 40

Einzelprobleme

DBA

Quellensteuersatz

Belgien 1967/2002

0

Bolivien 1992

15

Bulgarien 2010

5

China 1985118

10 (7)

Dänemark 1995

0

Ecuador 1982

15

Elfenbeinküste 1979

10

Estland 1996

10 (5)

Finnland 1979

0

Frankreich 1959/1969/1989/2002, Art. 15

0

Georgien 2006

0

Ghana 2004

8

Griechenland 1966, Art. VIII

0

Indien 1995

10

Indonesien 1990

15 (10; 7,5)

Iran, Islamische Republik 1968

10

Irland 2011

0

Island 1971

0

Israel 1962/1977, Art. 14

0 (5)

Italien 1989

5 (0)

Jamaika 1974

10

Japan 1966/1979/1983

10

Jugoslawien (SFR) 1987, Art. 13119

0

Kanada 2001

0 (10)

Kasachstan 1997

10

Kenia 1977

15

Kirgistan 2005

10

Korea, Republik 2000

10 (2)

Kroatien 2006

0

Kuwait 1987/1999

10

1380

Strunk

Handels- und steuerrechtliche Aspekte von Software DBA

Quellensteuersatz

Lettland 1997

10 (5)

Liberia 1970

10 (20)

Liechtenstein 2011

0

Litauen 1997

10 (5)

Luxemburg 2013

5

Malaysia 2010

7

Malta 2001

0

Marokko 1972

10

Mauritius 1978

15

Mexiko 1993

10

Mongolei 1994

10

Namibia 1993

10

Neuseeland 1978

10

Niederlande 1059/1986/1991

0

Norwegen 1991

0

Österreich 2002

0

Pakistan 1994

10

Philippinen 1983

15 (10)

Polen 2004

5

Portugal 1980

10

Rumänien 2001, Art. 11

3

Russische Föderation 1996

0

Sambia 1973

10

Schweden 1992

0

Schweiz 2000

0

Simbabwe 1988

7,5

Singapur 2004

(8)

Slowenien 2006

5

Spanien 2011

0

Sri Lanka 1979

10

Rz. 40

Strunk

P

1381

P Rz. 41

Einzelprobleme

DBA

Quellensteuersatz

Südafrika 1973, Art. 9

0

Syrien 2010

12

Tadschikistan 2003

5

Thailand 1967

15 (5)

Trinidad/Tobago 1973

10 (0)

Tschechoslowakei 1980

0 (5)

Türkei 2010

10

Tunesien 1975

15 (10)

UdSSR 1981

0

Ukraine 1995

5 (0)

Ungarn 2011

0

Uruguay 2010

10

Usbekistan 1999

5 (3)

Venezuela 1995

5

Vereinigte Arabische Emirate 2010

10

Vereinigtes Königreich 2010

0

Vereinigte Staaten 1989/2006

0

Vietnam 1995

10 (7,5)

Weißrussland 2006

3 (5)

Zypern 2011

0

V. Ausgewählte Gestaltungs- und Problemfälle 41 Nachfolgend sollen einige beispielhafte Gestaltungs- und Problemfälle kurz dargestellt werden.

1382

Strunk

Handels- und steuerrechtliche Aspekte von Software

Rz. 42

P

Beispiel 1: Lizengeber Hauptlizenz 90 Inc. EAV

Ausland I Deutschland Kunde

Unterlizenz

1.

Kein DBA-Fall: Quellensteuer nach nationalem deutschem Steuerrecht 15%

2.

Quellensteuer wird auf Einnahmen erhoben; Betriebsausgaben bleiben ohne Berücksichtigung in Deutschland

3.

Gefahr der Überbesteuerung in Deutschland

4.

Regelmäßig keine Erstattung zu viel gezahlter Quellensteuern im Ausland.

5.

Kunde behält 15% der Zahlungsverpflichtung ein und überweist 85 an die ausländische Inc., die ihrerseits an den Lizenzgeber 90,– cash zahlen muss.

6.

Steuerbelastung ist 150% und bei jeder Transaktion entsteht ein weiterer cash-Abfluss

7.

Steuerpflicht in Deutschland nur dann, wenn Recht oder Muster oder Verfahren in einer inländischen Betriebsstätte genutzt wird; vertragliche Vereinbarung notwendig.

100 Deutschland

BS Endnutzer

Ein deutsches Unternehmen erwirbt eine Lizenz von einem anderen deutschen Unternehmen zum Preis von 90,– Euro und überlässt diese Lizenz im Rahmen einer zulässigen Unterlizenz an einen Kunden im Ausland zum Preis von 100,– Euro. Der ausländische Staat verpflichtet den Kunden zur Einbehaltung einer Quellensteuer von 10 % auf den Bruttobetrag in Höhe von 100,– Euro. Das deutsche Unternehmen hat dem Welteinkommensprinzip folgend auch die Einkünfte aus dem Ausland in Deutschland zu besteuern und nimmt 100,– Euro Betriebseinnahmen sowie 90,– Euro Betriebsausgaben an. Auf den Gewinn von 10 Euro müssen in Deutschland 30 % Steuern gezahlt werden, die jedoch wegen der Anrechnung der ausländischen Steuern nicht zu zahlen sind. Da aber der ausländische Staat die einbehaltene Quellensteuer dem deutschen Unternehmen nicht erstattet, kommt es zu einer Steuerquote von 100 %, die man regelmäßig nur durch geeignete Gestaltungen und Maßnahmen verhindern kann. Beispiel 2: Ein deutsches Unternehmen verpflichtet sich als Lizenznehmer einer Individualsoftware einem ausländischen Unternehmen je Monat eine Zahlung von 10 000,– Euro zu leisten. Vertragsbestandteil ist eine so genannte Grossing up-Klausel, die den Lizenznehmer verpflichtet, ungeachtet einer Verpflichtung zum Einbehalt von Quellensteuern für den Lizenzgeber dem Lizenzgeber den ungemilderten Bruttobetrag zu überweisen.

Eine solche Vereinbarung führt dazu, dass der Lizenznehmer eine bis zu 42 20 % höhere Lizenzzahlung erbringen muss und darüber hinaus dem Lizenzgeber auch noch ein weiterer Vorteil in Höhe der Anrechnung der für ihn im Ausland einbehaltenen Steuern aus seiner inländischen Steuerschuld ermöglicht wird. Die Verträge sollten daher sorgfältig auf Steuerfolgen geprüft werden und ggf. sollten Anpassungen vorgenommen werden. Ist man selbst der Lizenznehmer, können sich entsprechende Vorteile ergeben.

Strunk

1383

P Rz. 43

Einzelprobleme

Beispiel 3: Inc.

1.

Inc. möchte eigentlich direkt an Kunden leisten, aber kein DBA zwischen Ausland I und Ausland II, so dass nationale Quellensteuer im Ausland II von 25% endgültig wird.

2.

Annahme: Zwischen Ausland I und Deutschland DBA mit Quellensteuer 0% und zwischen Deutschland und Ausland II Quellensteuer auch von 0%.

3.

Treaty Shopping der Inc. durch Zwischenschaltung einer deutschen Tochtergesellschaft = Reduzierung der Quellensteuer im konkreten Fall von 25% auf 0%.

4.

Wenn Deutschland in der Funktion des Auslandes II wäre, dann Treaty Override.

5.

Ergebnis wäre: Deutschland gewährt Quellensteuerbefreiung nur, wenn Empfänger der Lizenzeinnahmen im Ausland wirtschaftlich qualifiziert ist.

Ausland I Deutschland GmbH

Deutschland Ausland II Kunde 25% Quellensteuer

VI. Fazit 43 Im Ergebnis ist festzuhalten, dass die handels- und steuerrechtlichen Aspekte, insbesondere im Bereich der Bewertung und Bilanzierung von Software für die Unternehmen von großer Bedeutung sind, aber gleichwohl für diesen Bereich noch keine gefestigte Literaturmeinung, Finanzverwaltungsauffassung oder gar Rechtsprechung besteht. Diese Unsicherheit bedeutet erhöhte Risiken, aber auch Gestaltungsmöglichkeiten der Unternehmen. Insbesondere bei grenzüberschreitenden Softwareüberlassungen ist neben dem jeweiligen nationalen Steuerrecht auch das Recht der Doppelbesteuerungsabkommen zu beachten. Durch die bewusste Gestaltung von Geschäftsprozessen können steuerliche Nachteile vermieden werden. Aber nicht nur der Lizenzgeber hat steuerliche Aspekte zu beachten, sondern auch der Lizenznehmer, da er regelmäßig für abzuführende Quellensteuern die Haftung zu übernehmen hat.

1384

Strunk

Q. Bewertung von Software, Due Diligence, Compliance Rz. I. Bewertungssituationen, Bewertungsanlässe und Bewertungsziele . . . . . . . . . . . . . . . . . . . 1. Software als Teil des Unternehmenswerts, Due Diligence . . . . . . . . . . . . . . . . . . . . . . . 2. Übertragung von Rechten . . . . . 3. Make or Buy-Entscheidungen . 4. Steuerliche Beurteilung von Softwareentwicklungen . . . . . . . 5. Projekte in der Krise . . . . . . . . . .

Rz.

1

2 3 4 5 6

6. 7.

II. Der Wertbegriff als solcher . . . . 7 1. Herstellungskosten, Wiederbeschaffungswert . . . . . . . . . . . . 8 2. Ertragswert . . . . . . . . . . . . . . . . . . 10 3. Gemeiner Wert, Marktwert, Verkehrswert . . . . . . . . . . . . . . . . 12 4. Liquidationswert . . . . . . . . . . . . . 18 III. Wertbestimmende technische Faktoren einer Software Due Diligence . . . . . . . . . . . . . . . 1. Erfüllung der fachlich funktionalen Anforderungen . . . . . . . . . 2. Erfüllung allgemeiner gesetzlicher und regulatorischer Anforderungen. . . . . . . . . . . . . . . . . . a) Grundsätze ordnungsmäßiger Buchführung (GoBS) . . . . b) Erfüllung von Vorschriften zum internen Kontrollsystem IKS . . . . . . . . . . . . . . . . . . . c) Bundesdatenschutzgesetz (BDSG) . . . . . . . . . . . . . . . . . . . 3. Offenheit, Schnittstellen . . . . . . 4. IT-Sicherheitsaspekte . . . . . . . . . a) Allgemeine gesetzliche und regulatorische Vorschriften . . . . . . . . . . . . . . . . . . b) Grundschutz-Kataloge des BSI . . . . . . . . . . . . . . . . . . . . . . . c) Standardisierte Sicherheitskonzepte . . . . . . . . . . . . . . . . . . d) Kriterienkataloge . . . . . . . . . . e) ISO/IEC 27001. . . . . . . . . . . . . 5. Software-Qualität . . . . . . . . . . . . a) Fehlerfreiheit . . . . . . . . . . . . . .

20

8. 9.

22

23 26

29 10. 31 32 36

42 43 44 47 48 49 51

b) Laufzeitverhalten, Performanz und Stabilität . . . . . . . . 52 c) Ergonomie, Usability . . . . . . . 56 d) Mehrsprachigkeit . . . . . . . . . . 64 e) Wartbarkeit (Pflegbarkeit, Änderbarkeit), Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . 65 Technologische Basis, Software-Architektur . . . . . . . . . . . . . 68 Quellcode . . . . . . . . . . . . . . . . . . . 74 a) Zum Einfluss des Programmierstils, ProgrammierRichtlinien . . . . . . . . . . . . . . . . 76 b) Codierungsstandards . . . . . . . 78 c) Inline-Dokumentation. . . . . . 79 d) Modellierungstechniken, Design Patterns . . . . . . . . . . . . 82 e) Libraries und Open-SourceKomponenten . . . . . . . . . . . . . 83 f) Versions-Management, fehlender Quellcode . . . . . . . . . . . 89 Datenmodell . . . . . . . . . . . . . . . . . 92 Dokumentation . . . . . . . . . . . . . . 100 a) Anwenderdokumentation . . . 105 b) Systemdokumentation, Betriebshandbuch . . . . . . . . . . 107 c) Verfahrensdokumentation . . 109 d) Inline-Dokumentation. . . . . . 112 e) Softwarearchitektur, übergreifende Darstellungen. . . . . 114 f) SoftwareentwicklungsDokumentation . . . . . . . . . . . . 115 Softwareentwicklungsprozess . 119 a) Wasserfall-Modell . . . . . . . . . . 124 b) V-Modell und V-Modell XT . . 125 c) Rational Unified Process (RUP) . . . . . . . . . . . . . . . . . . . . . 129 d) Extreme Programming, Agile Programmierung, Scrum. . . . . . . . . . . . . . . . . . . . . 131 e) CMMI . . . . . . . . . . . . . . . . . . . . 135 f) SPICE/ISO 15504. . . . . . . . . . . 138 g) PMBOK . . . . . . . . . . . . . . . . . . . 140 h) ITIL. . . . . . . . . . . . . . . . . . . . . . . 141 i) ISO/IEC 20000 . . . . . . . . . . . . . 144 j) DIN EN ISO 9000-2005/9001 . . . . . . . . . . . . 147

Hoppen

1385

Q

Einzelprobleme Rz.

Rz.

11. Qualitätssicherungs-Maßnahmen im Projekt . . . . . . . . . . . . . . 148 a) QS-Prinzipien . . . . . . . . . . . . . 150 b) Vorgehen bei Tests . . . . . . . . . 151 c) Fehlerdokumentation und Fehlermanagement . . . . . . . . 156

4. Beurteilung des Softwareentwicklungsprozesses . . . . . . . . . . . 214 5. Abschätzung der Herstellkosten . . . . . . . . . . . . . . . . . . . . . . . 216 a) Ermittlung des Quellcodeumfangs . . . . . . . . . . . . . . 216 b) Bestimmung des Entwicklungsaufwandes . . . . . . . . . . . . 219 c) Berücksichtigung des Erfüllungsgrades bei der Bewertung unfertiger oder defizitärer Projekte . . . . . . . . . . . . . . 222 d) Einbezug von Personalkosten-Ansätzen . . . . . . . . . . . 228 e) Plausibilisierung anhand tatsächlicher Aufwandswerte . . . . . . . . . . . . . . . . . . . . . 231 6. Beurteilung kaufmännischer Aspekte (Nutzbarkeit, Vermarktbarkeit) . . . . . . . . . . . . . . . . 232 a) Absatz- und Umsatzgrößen . 233 b) Konkurrenzsituation, Alleinstellungsmerkmale . . . 235 c) Prüfung der Besitz- und Eigentumsverhältnisse . . . . . 238 aa) Identifizierung inkludierter Lizenzen und sonstiger Rechte Dritter, Open-Source-Komponenten . . . . . . . . . . . . . . . . . 239 bb) Eigene Softwarekomponenten mit Rechteeinschränkungen . . . . . . . 242 cc) Patente . . . . . . . . . . . . . . . . 245 dd) Software-Escrowing . . . . . 246 d) Berücksichtigung geplanter und erforderlicher Maßnahmen . . . . . . . . . . . . . . . . . . . . . . 247 7. Ertragswertorientierte Ermittlung des Verkehrswerts . . . . . . . 248 a) Annahme einer begrenzten Lebensdauer . . . . . . . . . . . . . . . 253 b) Zu betrachtende Erlös- und Kostenarten . . . . . . . . . . . . . . . 258 c) Betrachtung verschiedener Szenarien. . . . . . . . . . . . . . . . . . 268 d) Wahl des Kapitalisierungszinssatzes . . . . . . . . . . . . . . . . . 271 aa) Basiszinssatz . . . . . . . . . . . 273 bb) Wachstumsabschlag . . . . 275 cc) Risikozuschlag . . . . . . . . . 276

IV. Bewertungsmethoden . . . . . . . . 159 1. Ansätze der Informatik . . . . . . . 159 a) Function Point Analysis . . . . 161 b) COCOMO II . . . . . . . . . . . . . . 166 aa) Entwicklungsbedingungen . . . . . . . . . . . . . . . . . . . . 180 bb) Kostentreiberfaktoren . . . 187 c) COSMIC Full FunctionPoint (FFP) . . . . . . . . . . . . . . . . 192 d) Produktorientierte Schätzung . . . . . . . . . . . . . . . . . . . . . . 194 2. Betriebswirtschaftliche Ansätze . . . . . . . . . . . . . . . . . . . . . 195 a) Kapitalisierung, Barwert . . . . 196 b) IDW Standards S1 und S5 . . . 199 aa) Maßgebliche Vorgaben des IDW Standards S1 – Grundsätze zur Durchführung von Unternehmensbewertungen . . . . . . 201 bb) Maßgebliche Vorgaben des IDW Standards S5 – Grundsätze zur Bewertung immaterieller Vermögenswerte. . . . . . . . . . . 202 c) IDW PS 850, 880 . . . . . . . . . . . 203 aa) Maßgebliche Vorgaben des IDW Prüfungsstandards PS850 – Projektbegleitende Prüfung bei Einsatz von Informationstechnologie . . . . . . . . . 205 bb) Maßgebliche Vorgaben des IDW Prüfungsstandards PS880 – Die Prüfung von Softwareprodukten . . . . . . . . . . . . . . . . 206 V. Vorgehen bei der Bewertung . . . 207 1. Vergleichende Betrachtung unterschiedlicher Wertansätze . . . . . . . . . . . . . . . . . . . . . . 208 2. Beurteilung der Produkteigenschaften . . . . . . . . . . . . . . . . . . . . . 210 3. Beurteilung des Quellcodes . . . 212

1386

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 4

Q

Rz.

Rz.

e) Sonstige wertbeeinflussende Faktoren . . . . . . . . . . . . . . . . . . 279 f) Restwert am Ende der Lebensdauer der Software . . . . . 280

g) Darstellung von Ausmaß der Unsicherheit und Ergebnisbandbreite der Bewertung . . . . . . . . . . . . . . . . . 283

I. Bewertungssituationen, Bewertungsanlässe und Bewertungsziele Die Erstellung von Software ist in der Regel mit erheblichen wirtschaftli- 1 chen Aufwendungen verbunden. Deswegen ist es geradezu zwangsläufig, dass sich in verschiedenen unternehmerischen Situationen die Frage nach dem Wert einer Software stellt. In der Regel ist dann der merkantile Wert gefragt, je nach Situation können die zu betrachtenden wertbestimmenden Aspekte allerdings unterschiedlich sein, ebenso wie die Bewertungsziele. Eine Software-Bewertung umfasst aber immer auch qualitative Aspekte, z.B. hinsichtlich der Weiterentwickelbarkeit oder der Erfüllung regulatorischer Anforderungen (Compliance). 1. Software als Teil des Unternehmenswerts, Due Diligence Bei der Akquisition ganzer Unternehmen oder einzelner Unternehmenstei- 2 le, aber auch in Finanzierungs- und Überschuldungssituationen kann die im Unternehmen geschaffene bzw. betriebene selbsterstellte Software einen erheblichen Wertposten darstellen. Dies gilt sowohl bei Software, die für den Eigenbedarf erstellt wurde als auch bei Software, die als Standardsoftware am Markt angeboten wird. Bewertungsziel ist hier die Ermittlung des Zustands einer vorhandenen Software und des Wertes der wirtschaftlich verwertbaren Substanz dieser Software (Due Diligence). 2. Übertragung von Rechten Auch bei einer Übertragung von Rechten, die über das reine Nutzungsrecht 3 hinausgeht, also etwa bei Einbringung einer Software als Sacheinlage, bei dem Erwerb der vollumfänglichen Rechte an einer Software oder der Übernahme ganzer Geschäftsbereiche geht es darum, einen angemessenen Wert der Software zu bestimmen. Neben der Bestimmung dieses Wertes wird es hier regelmäßig Bewertungsziel sein, auch qualitative Aussagen zur bestimmungsgemäßen Nutzbarkeit der übertragenen Software und zu zukünftigen Wartungs- und Betriebskosten zu erhalten. 3. Make or Buy-Entscheidungen Bewertungsfragen können sich auch bereits dann stellen, wenn die zu be- 4 trachtende Software noch gar nicht vorhanden ist. Hier stellt sich nämlich Hoppen

1387

Q Rz. 5

Einzelprobleme

manchmal die Frage, ob die Software besser selber entwickelt oder am Markt beschafft wird. Bewertungsziel ist dann die Gegenüberstellung des Ertragswertes bzw. Kaufpreises einer zu erwerbenden Software und der Wiederbeschaffungs- bzw. Herstellungskosten einer neu zu entwickelnden Software unter Berücksichtigung der Entwicklungszeit. 4. Steuerliche Beurteilung von Softwareentwicklungen 5

Durch die Neuregelungen des Bilanzrechtsmodernisierungsgesetzes (BilMoG) bieten sich dem Unternehmen neue Gestaltungsmöglichkeiten hinsichtlich der Aktivierung selbst erstellter immaterieller Vermögensgegenstände. Im Rahmen der bilanzpolitischen Gestaltung können sich daher Bewertungsfragen mit teilweise erheblichen wirtschaftlichen Auswirkungen stellen1. Bewertungsziel ist hier die Ermittlung oder Absicherung von Wertansätzen bei der Aktivierung von Software. 5. Projekte in der Krise

6

Schließlich ist auch in einer Projektkrise eine Wertbestimmung vorzunehmen, um Entscheidungsalternativen qualifiziert gegeneinander abwägen zu können. Hier geht es häufig darum, erreichte Leistungs- und Projektstände zu bewerten. Das Bewertungsziel kann darin liegen, (Rest-)Entwicklungskosten abzuschätzen oder eine angemessene Vergütung für den erreichten Projektstand zu bestimmen.

II. Der Wertbegriff als solcher 7

Alleine anhand der vorstehenden Aufzählung unterschiedlicher Bewertungssituationen zeigt sich, dass man nicht von dem „Wert“ einer Software sprechen kann. Vielmehr können in unterschiedlichen Situationen unterschiedliche Begriffe gemeint sein. 1. Herstellungskosten, Wiederbeschaffungswert

8

Der Begriff der Herstellungskosten beschreibt den Aufwand, der bei einer unabhängigen (Neu-)Entwicklung einer Software anzusetzen ist. Ein so ermittelter Wert stellt den Substanzwert als Rekonstruktions- oder Wiederbeschaffungswert der Software dar. Diesem Substanzwert, verstanden als Netto-Teilrekonstruktionszeitwert, fehlt zwar grundsätzlich der direkte Bezug zu künftigen finanziellen Überschüssen und er kann insofern nicht den wirtschaftlichen Wert der Software darstellen. Er ist aber Ausdruck der bei 1 Hoppen/Hoppen, Bewertung und Bilanzierung selbst erstellter Software, CR 2009, 761. Das Aktivierungswahlrecht nach BilMoG ist ein handelsrechtliches und kein steuerrechtliches. Steuerlich sind weiterhin selbst geschaffene immaterielle Vermögensgegenstände nicht bilanzierbar.

1388

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 13 Q

der Softwareentwicklung vorgeleisteten Aufwendungen, die einem Erwerber der Software durch den Verzicht auf die Entwicklung einer identischen Software erspart bleiben1. Anhand von Herstellkosten können Make or Buy-Entscheidungen getroffen 9 werden und die Werthaltigkeit aktivierbarer Eigenentwicklungen nachgewiesen werden. 2. Ertragswert Wird eine selbstentwickelte Software nicht ausschließlich im eigenen Un- 10 ternehmen eingesetzt, sondern auch oder nur Dritten in Lizenz angeboten, so bestimmt sich der Wert der Software nicht mehr aus den Herstellungskosten, sondern wird vornehmlich „durch ihre Eigenschaft bestimmt, Einnahmeüberschüsse zu erwirtschaften“ bzw. deren Erwirtschaftung in einem Unternehmen zu ermöglichen. „Der Barwert der zukünftigen Überschüsse der Einnahmen über die Ausgaben bildet den theoretisch richtigen Wert eines Unternehmens“ bzw. der Software2. Der Ertragswert ergibt sich üblicherweise als Barwert der finanziellen Über- 11 schüsse, die bei Fortführung der Nutzung der Software erwirtschaftet werden. Er bestimmt sich allein aus der Ertragskraft, d.h. der Eigenschaft, finanzielle Überschüsse für den Inhaber der Software zu generieren3. 3. Gemeiner Wert, Marktwert, Verkehrswert Als Gemeiner Wert oder Verkehrswert wird üblicherweise der objektivierte 12 Wert der der Software innewohnenden und übertragbaren Ertragskraft angesehen4. Der gemeine Wert bestimmt sich nach § 9 des Bewertungsgesetzes (BewG) wie folgt: „Bei Bewertungen ist, soweit nichts anderes vorgeschrieben ist, der gemeine Wert zugrunde zu legen. Der gemeine Wert wird durch den Preis bestimmt, der im gewöhnlichen Geschäftsverkehr nach der Beschaffenheit des Wirtschaftsgutes bei einer Veräußerung zu erzielen wäre. Dabei sind alle Umstände, die den Preis beeinflussen, zu berücksichtigen. Ungewöhnliche oder persönliche Verhältnisse sind nicht zu berücksichtigen.“ Der Verkehrswert einer Standardsoftware wird sich in der Regel am Ertrags- 13 wert orientieren, wohingegen der Verkehrswert einer Individualsoftware, 1 Vgl. hierzu IDW Prüfungsstandard S1 i.d.F. 2008, Rz. 170 und 171. 2 Standard des Fachausschusses für Unternehmensbewertung und Betriebswirtschaft (FAUB) des Instituts der Wirtschaftsprüfer IDW S 1 „Grundsätze zur Durchführung von Unternehmensbewertungen“ sowie IDW S 5 „Grundsätze zur Bewertung immaterieller Vermögensgegenstände“. 3 Diese Definition erfolgt in enger Anlehnung an die Definition des Unternehmenswerts in dem IDW Prüfungsstandard S1 i.d.F. v. 2.4.2008, s. dort Rz. 4. 4 Vgl. hierzu IDW Prüfungsstandard S1 i.d.F. 2008, Rz. 38.

Hoppen

1389

Q Rz. 14

Einzelprobleme

die das Unternehmen zur eigenen Nutzung entwickeln lässt, mangels Fungibilität (keine übertragbare Ertragskraft) gegen Null tendieren wird oder aus den Ertragskomponenten herzuleiten ist, die sich alleine aus der Wartung oder der Verwendung von Komponenten des Quellcodes in anderem Kontext realisieren lassen. 14 Der tatsächlich erzielbare Preis für eine Softwareentwicklung bildet sich auf freien Kapitalmärkten aus Angebot und Nachfrage. Er wird dabei wesentlich von der Nutzenschätzung (Grenznutzen) des jeweiligen Käufers und Verkäufers bestimmt. Ein potentieller Erwerber der Software wird den Preis, den er bereit ist, zu zahlen, danach bestimmen, – welchen Ertrag er bei einer Verwertung der erworbenen Software erzielen kann und – welche Kosten er alternativ bei einer Neuentwicklung zu tragen hätte. 15 Aus der subjektiven Sicht eines starken potentiellen Erwerbers mag sich der tatsächliche Marktwert der Software unter Berücksichtigung des Gesamtmarktes, der eigenen Vermarktungsstrategie und Annahme eines (ggf. steigenden) Marktanteils darstellen. Der tatsächliche Wert für den potentiellen Erwerber kann dann als Ertragswert seiner eigenen Einschätzungen ermittelt werden. Dabei spielen subjektive Einflussgrößen (geänderte Preisstrukturen, Vertriebskonzepte etc.) eine Rolle. Auf diese kommt es aber bei der Ermittlung des Verkehrswertes nicht an. Der Erwerber wird nämlich in der Regel nicht bereit sein, einen so ermittelten Wert als Preis für die Software zu zahlen, da er den Mehrwert aus einer verbesserten Vermarktung selber abschöpfen möchte. Er wird eher bereit sein, den Wert zu erstatten, den die Software für den Veräußerer in dessen objektiver Position realistisch darstellen kann. 16 Der so zu verstehende übertragbare Ertragswert der Software im Sinne einer verselbständigten Erfolgsgröße ist daher als der Wert der Software zu bestimmen, der unter der Annahme der Fortführung des bisherigen Verwertungskonzeptes losgelöst von eigentümerbezogenen Erfolgsfaktoren und individuellen Wertvorstellungen einzelner Parteien zu realisieren ist (objektivierter Wert). Üblicherweise wird dabei von der Fortführung der Verwertung der Software in der bisherigen Form ausgegangen. 17 Bei der Bestimmung des Verkehrswertes sind die Herstellungskosten (Wiederbeschaffungswert) insofern von Interesse, als sie – zuzüglich der Opportunitätskosten für die sofortige und urheberrechtlich abgesicherte Verfügbarkeit der Software (time to market) – eine Wertobergrenze darstellen dürften. Ein potentieller Erwerber wird auch bei extremer Ertragskraft nicht aus dem Auge verlieren, zu welchen Kosten er eine Software selber neu entwickeln könnte. Einen höheren Preis wird er allenfalls dann zahlen wollen, wenn er damit einen Konkurrenten vom Markt nehmen kann. Dann unterliegt seine Bewertung ganz anderen Kriterien.

1390

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 22 Q

4. Liquidationswert Alternativ ist in manchen Situationen der Liquidationswert der Software zu 18 betrachten. Der Liquidationswert ist auch dann maßgeblich, wenn die Verwertung der Software eingestellt werden soll oder nicht mehr möglich ist. Der Liquidationswert einer Software ist der Wert, der sich bei einem Abbruch der Verwertungskonzeption noch erzielen lässt. Er besteht im Wesentlichen aus Wartungsgebühren, die sich auch nach Abbruch aller Entwicklungsaktivitäten noch über einen gewissen Zeitraum erzielen lassen sowie einem evtl. durch die Veräußerung bzw. anderweitige Verwertung der Quellprogramme (in Teilen oder im Ganzen, z.B. der Frameworks) erzielbaren Erlöses. In besonderen Konstellationen kann der Liquidationswert den Ertragswert 19 überschreiten. Er stellt dann bei der Bestimmung des Verkehrswerts eine Wertuntergrenze dar. Das kann z.B. der Fall sein, wenn ein angemessener Unternehmerlohn in die Ermittlung des Ertragswerts aufgenommen werden soll.

III. Wertbestimmende technische Faktoren einer Software Due Diligence Zunächst werden Faktoren aus technischer Sicht thematisiert, die den Wert 20 einer Software bestimmen. Diese Faktoren sind bei einer Due Diligence zu untersuchen, sowohl für qualitative Betrachtungen der Nutz- und Wartbarkeit als auch für die quantitative Bestimmung von Parametern zur Bestimmung eines merkantilen Wertes im Sinne der vorgenannten Wertbegriffe. In einer sinnvollen Software Due Diligence wird nicht flächendeckend und 21 rein technisch getrieben untersucht. Vielmehr wird der Umfang der Untersuchung zu Beginn abgestimmt, entsprechend der Zielsetzung des Auftraggebers, der benötigten Entscheidungsparameter, der als relevant erachteten Risiken, der überhaupt zugänglichen Informationen und der als bekannt vorauszusetzenden Fakten. Im Sinne einer effizienten Vorgehensweise empfiehlt es sich, den Untersuchungsumfang zunächst mit Augenmaß zu wählen und ggf. je nach Erkenntnislage punktuell schrittweise zu verfeinern. Nicht untersuchte, hypothetisch vorausgesetzte Aspekte sind dabei kenntlich zu machen. 1. Erfüllung der fachlich funktionalen Anforderungen Die Software muss die fachlichen Anforderungen, die sich aus ihrem Ein- 22 satzzweck ergeben, erfüllen, d.h. funktional abdecken. Einschränkungen sind wertmindernd, und zwar in Höhe der Herstellkosten zur Beseitigung der Funktionsdefizite. Maßstab sind hier in erster Linie die expliziten Festlegungen in Form der Leistungsspezifikationen und der daraus abgeleiteten technischen Konzepte sowie, falls solche nicht vorliegen, die vorausgesetzte Hoppen

1391

Q Rz. 23

Einzelprobleme

bzw. für die gewöhnliche Verwendung erforderliche Beschaffenheit – in der Regel, aber nicht zwangsläufig in mittlerem Ausführungsstandard. Vielfach, insbesondere wenn die Software bereits seit längerem produktiv im Einsatz ist, wird ohne weitere Prüfung davon ausgegangen, dass die fachlich funktionalen Anforderungen erfüllt werden. 2. Erfüllung allgemeiner gesetzlicher und regulatorischer Anforderungen 23 Zudem muss die Software die zum Bewertungsstichtag geltenden und das Einsatzgebiet betreffenden gesetzlichen und regulatorischen Anforderungen (Gesetze, Verordnungen, Normen, Richtlinien) berücksichtigen und umsetzen. Die Übereinstimmung mit solchen Anforderungen wird vielfach als Functionality Compliance oder IT-Compliance bezeichnet1. Einschränkungen gefährden die Verwertbarkeit der Verarbeitungsergebnisse der Software und sind als funktionales Defizit wertmindernd anzusetzen. 24 Zunehmend ist eine systematische Adressierung des Themas in Form strukturierter IT-Compliance-Prozesse in den Unternehmen zu beobachten, die letztlich auf kontinuierliche Beobachtung der Entwicklungen und dadurch initiierte Anpassung der Software bzw. argumentative Positionierung hinauslaufen. Wenngleich viele der Anforderungen die organisatorische Einordnung einer Software auf Anwenderseite betreffen, ergeben sich vielfach auch funktionale Anforderungen an die Software. Die proaktive Wirkung solcher IT-Compliance-Prozesse in der Softwareentwicklung sichert daher den Wert einer Software ab. 25 Es würde an dieser Stelle zu weit führen, auch nur eine Auflistung der potentiell relevanten Vorschriften zu versuchen. In fast allen Branchen gibt es spezifische Branchen- und Industriestandards mit IT-Bezug. Im Finanzwesen ergeben sich z.B. Anforderungen zum Risikomanagement, die ganz maßgeblich die Strukturen einer Software bestimmen können, aus dem KWG. Das gleiche gilt für das Gesundheitswesen mit Regelungen des SGB zur Dokumentationspflicht. Von erheblicher Praxisrelevanz, und deswegen nachfolgend kurz angesprochen, sind GoBS, IKS und BDSG. Daneben können sich – ohne Anspruch auf Vollständigkeit – IT-Compliance-Anforderungen aus folgenden Regelwerken ergeben: GDPdU, MaRisk, KonTraG, Basel II, Sarbanes-Oxley Act (SOX), Euro-SOX, IDW PS 330 und RS FAIT 1, Deutscher Corporate Government Kodex (DCGK), ITIL, ISO 20000 oder ISO 270012.

1 Conrad, in: Beck’sches Mandats-Handbuch IT-Recht, § 2 Rz. 9. 2 Strasse/Wittek, IT-Compliance, Informatik Spektrum, Band 35, Heft 1, Februar 2012.

1392

Hoppen

Rz. 30 Q

Bewertung von Software, Due Diligence, Compliance

a) Grundsätze ordnungsmäßiger Buchführung (GoBS) Von weitreichender und grundsätzlicher Bedeutung sind die Ordnungs- 26 mäßigkeits-Anforderungen, denen nach HGB, AO und anderen Vorschriften alle Buchführungssysteme und deren Vorsysteme unterliegen und die allgemein als Grundsätze ordnungsmäßiger Buchführung (GOB) bezeichnet werden1. Die sich daraus ergebenden Anforderungen bei der Ausgestaltung von IT-Systemen wurden 1995 durch das BMF in Form der der Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS) konkretisiert2. Aus den GoBS lassen sich umfangreiche allgemeine Anforderungen an ein Softwaresystem ableiten3. Wesentlich sind insbesondere die Beleg-, und Journalfunktion. Demnach 27 müssen Geschäftsvorfälle retrograd und progressiv prüfbar sein (Nachvollziehbarkeit). Die Erfüllung der Belegfunktion setzt die Dokumentation von Vorgängen durch sog. Belege voraus. Durch die Journalfunktion wird die Reihenfolge der Buchungen dokumentiert (Protokoll). Alle Informationen, die in den Verarbeitungsprozess eingeführt werden, müssen erfasst werden und dürfen nicht mehr unterdrückt werden können. Die ordnungsgemäße Anwendung des Verfahrens ist zu belegen (durch Programmprotokolle und eine Verfahrensdokumentation). Buchungen sind dann ordnungsgemäß, wenn sie geordnet, vollständig, formal richtig, zeitgerecht und verarbeitungsfähig gespeichert werden. Änderungen dürfen nur durch Stornierungen oder Neubuchungen erfolgen. Zur Erreichung einer Datensicherheit fordern die GoBS ein Datensicherungskonzept, in dem geregelt wird was, wogegen, wie lange, und wie gesichert werden muss. Zu sichern sind Programme und Datenbestände, aber auch Änderungen an Tabellen und Stammdaten.

28

b) Erfüllung von Vorschriften zum internen Kontrollsystem IKS Die GoBS fordern die Existenz eines internen Kontrollsystems (IKS). Hie- 29 runter versteht man die „Gesamtheit aller aufeinander abgestimmten und miteinander verbundenen Kontrollen, Maßnahmen und Regelungen zum Schutz von Vermögen und Informationen vor Verlusten, zur Bereitstellung vollständiger, genauer, aussagefähiger, zeitnaher Aufzeichnungen, zur Auswertung und Kontrolle der Aufzeichnungen sowie zur Befolgung der Geschäftspolitik“. Relevanz entfalten diese Regelungen in allen Systemen, die der Dokumentation und Archivierung von Geschäftsvorgängen dienen. Zur Sicherstellung der Dokumentation und Prüfbarkeit fordern die GoBS die Existenz einer Verfahrensdokumentation (Inhalt, Aufbau, Ablauf). Diese 1 Vgl. insb. §§ 238, 239 und 257 HGB sowie Erläuterungen des Instituts der Wirtschaftsprüfer in Form der IDW RS FAIT1. 2 Schreiben des BMF an die obersten Finanzbehörden der Länder v. 7.11.1995 – IV A 8 – S 0316 – 52/95, BStBl. 1995 I S. 738. 3 Vgl. Streitz, Ordnungsmäßigkeit, NJW-CoR1996, 221 ff.

Hoppen

1393

30

Q Rz. 31

Einzelprobleme

umfasst eine Beschreibung der sachlogischen Lösung, Beschreibung der programmtechnischen Lösung und auch eine Beschreibung, wie die Programmund Datenintegrität gewahrt bleibt (Freigabeverfahren, Testläufe, Zugriffsberechtigungen). c) Bundesdatenschutzgesetz (BDSG) 31 Grundsätzliche Anforderungen an die Funktionalität einer Software können sich auch aus dem BDSG ergeben, insbesondere wenn es um die Speicherung personenbezogener Daten geht. Um personenbezogene Daten handelt es sich, wenn Einblicke in persönliche oder sachliche Verhältnisse einer bestimmbaren Person möglich sind. Die Speicherung solcher Daten ist nur zulässig, wenn sie per Gesetz/Vorschrift erforderlich ist, ein berechtigtes Interesse oder eine Einwilligung der Person vorliegt. § 9 BDSG regelt die technischen und organisatorischen Maßnahmen, die bei der Softwareerstellung ggf. bereits in den internen Strukturen der Software zu beachten sind. Besondere Anforderungen können sich insbesondere aus den Grundsätzen der Speicherkontrolle, Benutzerkontrolle, Zugriffskontrolle, Übermittlungskontrolle, Eingabekontrolle und Transportkontrolle ergeben1. 3. Offenheit, Schnittstellen 32 Software wird heute zunehmend nicht mehr in geschlossenen, gut kontrollierbaren Umgebungen eingesetzt, sondern in offenen Umgebungen mit verschiedensten Zugangskanälen. Die Funktionalität der Software wird in vielen Fällen sowohl über eine Bedienoberfläche zur manuellen Bedienung durch den Menschen als auch über Programmaufruf-Schnittstellen, sog. Application Programming Interface (API) zur Konnektivität mit über-, nebenund untergeordneten Software-Systemen bereitgestellt. Darüber können die Programmfunktionen direkt programmatisch angesprochen werden. Dies kann sowohl von dem gleichen Rechner bzw. Server aus erfolgen, als auch von anderen Rechnern über Mechanismen zur Interprozesskommunikation wie etwa Remote Procedure Call (RPC). 33 In fast jeder Branche gibt es fachspezifische standardisierte Datenformate, die über standardisierte Import- oder Export-Schnittstellen unterstützt werden müssen. Weitverbreitet sind z.B. die Formate DTAUS oder MT940 zum Datenaustausch mit Banken, EDIFACT als branchenübergreifender und internationaler Standard zum Austausch elektronischer Daten im Geschäftsverkehr, die GAEB-Datenformate im Bauwesen (Ausschreibungen, Leistungsverzeichnisse, Angebote) und das DATANORM-Format zur Bereitstellung von Artikelstammdaten durch Hersteller.

1 BDSG § 9, vgl. auch den Maßnahmenkatalog im Anhang des BDSG mit den sog. „10 Geboten“.

1394

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 37 Q

Auch auf Systemebene werden Softwareprogramme häufig über Schnittstel- 34 len eingebunden, etwa bei der Koppelung der Benutzerverwaltung der Anwendung an externe Benutzerverzeichnisse und Verzeichnisdienste (LDAP, Active Directory) mit dem Ziel eines Single-Sign-On (SSO). Weitere Anforderungen an die Offenheit einer Anwendung können sich aus 35 den Grundsätzen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU) ergeben, nach denen IT-Systeme, deren Verarbeitungsergebnisse der Prüfung durch die Finanzbehörden unterliegen, drei Arten des Datenzugriffs für die Prüfer bereitstellen müssen (unmittelbarer Lesezugriff, mittelbarer Zugriff über Auswertungen und Datenträgerüberlassung). In jüngster Zeit wurden die Vorschriften zur Überlassung von Datenbeständen durch das Steuerbürokratieabbaugesetz (SteuBAG) umfassend ausgedehnt. Danach müssen Jahresabschlüsse als sog. E-Bilanz elektronisch an die Finanzverwaltung übermittelt werden. Das hierbei einzuhaltende Gliederungsschema kann umfassende Anforderungen an die Software stellen. 4. IT-Sicherheitsaspekte Die Anforderungen an die Offenheit und Integrierbarkeit von Software haben zur Folge, dass Sicherheitsaspekte heute eine viel stärkere Rolle spielen als noch vor wenigen Jahren. Schutzziele einer IT-Sicherheit sind1

36

– Authentizität: Echtheit und Glaubwürdigkeit von Informations-Objekten, – Datenintegrität bzw. Unversehrtheit: In sich konsistente und nicht manipulierbare Zusammenstellung von Informations-Objekten, Schutz vor ungewollten Veränderungen, – Verfügbarkeit: Schutz der Informations-Objekte vor Verlust, Entzug, Blockade oder Zerstörung, – Verbindlichkeit: Nachweisbarkeit von Aktionen auf Informations-Objekten und – Vertraulichkeit: Schutz vor unkontrollierter Einsichtnahme von Informations-Objekten. Insbesondere wenn Zugangskanäle über das Internet bestehen, ist die Software potentiell verschiedensten Bedrohungen ausgesetzt. Diese können nicht alle durch Infrastrukturkomponenten des Netzwerks (z.B. Firewalls) unterdrückt werden, sondern erfordern ein sorgfältiges und dem Stand der Technik entsprechendes Software-Design. Z.B. ist immer wieder von Schäden zu hören, die durch Hacker-Techniken wie Buffer Overflow oder SQL-

1 Eckert, IT-Sicherheit, 2009, S. 6 ff. Das BSI nennt in seinen als Grundwerte und Schutzziele lediglich Vertraulichkeit, Integrität und Verfügbarkeit, vgl. ITGrundschutz 4.2.3, Schutzbedarf und Schutzziele (https://www.bsi.bund.de/ DE/Themen/weitereThemen/WebkursITGrundschutz/Schutzbedarfsfeststellung/ Schutzbedarfskategorien/Schutzziele/schutzziele_node.html).

Hoppen

1395

37

Q Rz. 38

Einzelprobleme

Injection verursacht werden1. Das Open Web Application Security Project, eine Non-Profit-Initiative führender IT-Unternehmen und IT-Anwender veröffentlicht regelmäßig jährlich die Top 10 Sicherheitsrisiken von webbasierten Anwendungen. Im Jahr 2010 waren dies SQL-Injection, Cross-Site Scripting (XSS), Broken Authentification and Session Management, Insecure Direct Object References, Cross-Site Request Forgery (CSRF), Security Misconfiguration, Insecure Cryptographic Storage, Failure to Restrict URL Access, Insufficient Transport Layer Protection und Invalidated Redirects and Forwards2. Fehler können analytisch z.B. durch Penetrationstests aufgedeckt werden3. 38 Aber auch unbeabsichtigte Zugriffe von innerhalb der Organisation sind abzusichern. Die Mehrzahl der Angriffspunkte muss bereits in den Kernkomponenten der Software konzeptionell berücksichtigt werden; ansonsten ist eine nachträgliche Absicherung in der Regel nur äußerst schwierig, aufwändig und fehlerträchtig möglich. Solche Aspekte sind wertbestimmend, da sie nicht nur die Sicherheit des jeweils erreichten Softwarestandes bestimmen, sondern auch ganz maßgeblichen Einfluss auf die zukünftige Wartbarkeit und Weiterentwickelbarkeit der Software haben. 39 Auch auf der Anwendungsebene können sich Sicherheitsrisiken ergeben, beispielsweise wenn das Berechtigungskonzept unzulänglich oder unflexibel, d.h. nur auf bestimmte Organisationsstrukturen zugeschnitten, ist. Moderne Anwendungen bieten die Möglichkeit, sowohl systemweit je Benutzer oder Benutzergruppe Funktionsberechtigungen vergeben zu können (menu level, Möglichkeit des Aufrufs von Funktionen) als auch Aktionsberechtigungen detailliert definieren zu können (screen level, object level, Möglichkeit der Ausführung von Aktionen wie Einsehen, Ändern, Löschen etc.) und Datensichten in Abhängigkeit der Zugriffsrechte des Benutzers filtern zu können. 40 Der Aufwand für Sicherheitsprüfungen ist in der Regel, wenn sie unabhängig von der Softwareentwicklung vorgenommen werden, ganz erheblich und kann in den meisten Fällen im Rahmen der eigentlichen Softwarebewertung nicht geleistet werden. Umso wichtiger ist es dann aber, bei der Bewertung zumindest kursorisch zu prüfen, inwieweit die Sicherheitseigenschaften der Software systematisch in diese „hineinkonstruiert“ wurden (Stichwort Security Engineering bzw. konstruktive Qualitätssicherung), also bereits im Entwicklungsprozess berücksichtigt wurden. Es gibt BestPractice-Empfehlungen und grundsätzliche Konstruktionsprinzipien zur Entwicklung abgesicherter Software4. Bereits bei der fachlichen Konzeption sollte eine Schutzbedarfs- bzw. Bedrohungsanalyse und daraus abgeleitet ei1 Vgl. hinsichtlich dieser und anderer Bedrohungen Eckert, IT-Sicherheit, 2009, S. 45 bzw. 156. 2 http://www.owasp.org/index.php/OWASP_Top_Ten_Project. 3 Eckert, IT-Sicherheit, 2009, S. 194 ff. 4 Eckert, IT-Sicherheit, 2009, S. 168 ff.

1396

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 43 Q

ne Risikoanalyse vorgenommen worden sein. Nur so können bei der DVSpezifikation grundlegende Sicherheitsfunktionen systematisch identifiziert und vorgesehen werden. Dazu gehören die Ausgestaltung der Rechteverwaltung, die Mechanismen zur Identifikation und Authentifikation, ggf. sehr in die technische Detailebene hineingehende Verfahren, freiwerdende Speicherobjekte wieder zu zerstören, aber auch Grundprinzipien der Ereignisprotokollierung. IT-Sicherheit kann auch relativ einfach durch Verwendung geeigneter und in sich schon sicher konstruierter Frameworks (z.B. zum Zugriff auf Datenbanken) erreicht werden. In der Regel kann anhand der Softwareentwicklungsdokumentation oder der Systemdokumentation auch mit begrenztem Aufwand erkannt werden, ob eine systematische Befassung mit IT-Sicherheitsaspekten bei der Entwicklung der Software stattgefunden hat oder nicht. Beurteilungsmaßstäbe können aus folgenden Unterlagen gewonnen werden:

41

a) Allgemeine gesetzliche und regulatorische Vorschriften Aus den vorstehend bereits genannten allgemeinen gesetzlichen und regu- 42 latorischen Vorschriften können sich Anforderungen zur Protokollierung von Benutzeraktivitäten ergeben (sog. Auditing). Aus Sicht der GoBS betrifft dies z.B. Konfigurationsänderungen, Datenänderungen an Stammdaten, aber je nach Anwendung auch den Aufruf einzelner Programmfunktionen und die Erstellung von Druckausgaben (Reports). Die Einhaltung der Rechtspflichten wie der getroffenen Sicherheitsmaßnahmen muss dokumentiert werden1. Solche Dokumentationen sind zwar immer bezogen auf den konkreten Anwendungsfall in der Organisation des Anwenders zu erstellen, je nach Anwendungsgebiet kann dies aber nur möglich sein oder deutlich erleichtert werden, wenn begleitend zu der Entwicklung der Software bereits entsprechende Grundlagen-Dokumente erarbeitet und Testate zum Verhalten der Software erstellt wurden. Die Existenz solcher Dokumente ist bei der Bewertung einer Software zu berücksichtigen. b) Grundschutz-Kataloge des BSI Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat in 43 Deutschland seit 1995 als sog. Grundschutz-Handbuch eine stetig wachsende Sammlung von Maßnahmen zur Erlangung eines IT-Grundschutzes herausgegeben. Gruppiert in verschiedenen Bausteinen wurden sehr praxisorientiert über 700 Maßnahmen in verschiedensten Handlungsfeldern gesammelt. Mit Erscheinen der Norm 27001 hat das BSI das GrundschutzHandbuch neu strukturiert2 in einen grundsätzlichen Anforderungsteil – die sog. BSI-Standards 100-1 bis 100-4 – und in die sog. IT Grundschutz-Kataloge, die als „Loseblatt-Sammlung“ den fortentwickelten praxisorientier1 Koch, IT-Projektrecht, 2007, S. 146. 2 http://ww.bsi.de/gshb/deutsch/index.htm.

Hoppen

1397

Q Rz. 44

Einzelprobleme

ten Maßnahmenkatalog des Grundschutz-Handbuches enthalten. Die BSIStandards bilden die Norm DIN ISO/IEC 27001 vollständig und darüber hinaus weitere Aspekte anderer Normen der ISO 2700x-Reihe ab1. Während der BSI-Standard 100-1 (Managementsysteme für Informationssicherheit) sich mit der Verantwortung des Managements für sichere IT-Prozesse und einem kontinuierlichen Verbesserungsprozess befasst, beschreibt der BSI Standard 100-2 (IT-Grundschutz-Vorgehensweise) eine Methodik, wie der Sicherheitsbeauftragte die Anforderungen aus 100-1 umsetzen kann. Wesentliches Element ist eine Risikoanalyse. Der BSI-Standard 100-3 (Risikoanalyse auf der Basis von IT-Grundschutz) beschreibt ein Verfahren, wie unter Rückgriff auf die Bausteine des Grundschutz-Kataloges Gefährdungslagen systematisch erhoben, bewertet und behandelt werden können. Die jüngste Publikation BSI Standard 100-4 aus 2008 beschreibt schließlich eine Methodik zur Etablierung eines Notfallmanagements, das auf das im BSI-Standard 100-2 beschriebene Vorgehen zur Umsetzung eines Managementsystems für Informationssicherheit aufsetzt. c) Standardisierte Sicherheitskonzepte 44 Neben den IT-Grundschutzkatalogen hat das BSI einen Prozess zur Erstellung eines Sicherheitskonzeptes nach dem PDCO-Modell2 vorgeschlagen, der auf eine kontinuierliche Verbesserung der Sicherheit auch in bestehenden Anwendungen abzielt. Solche Sicherheitskonzepte werden zunehmend auch bei externen Software-Zertifizierungen, z.B. solchen der TÜV-Institute, verlangt. 45 Die Firma Microsoft entwickelt ihre Anwendungen z.B. nach dem Security Development Lifecycle (SDL3) und implementiert dabei drei Paradigmen, um die Sicherheit ihrer Software zu erhöhen: Security by Design (möglichst fehler- und angriffstolerantes Systemkonzept), Security by Default (möglichst sichere Grundeinstellungen, Aufweichung der Sicherheit nur durch bewusste Handlungen) und Security by Deployment (Bereitstellung zusätzlicher, die Sicherheit erhöhender Hilfsmittel und Informationen)4. 46 Die Existenz entsprechender Mechanismen in der Organisation des Softwareentwicklers kann bei der Bewertung abgefragt und berücksichtigt werden. 1 https://www.bsi.bund.de/cln_183/DE/Themen/ITGrundschutz/itgrundschutz_ node.htm, Stand 26.4.2010. 2 Plan, Do, Check, Act-Modell nach Deming, auch Bestandteil von ISO 27001. 3 S. http://www.microsoft.com/security/sdl. 4 Windows Vista war das erste nach SDL entwickelte Betriebssystem. Gegenüber dem Vorgänger, Windows XP, wurden im ersten Jahr nach Freigabe 45 Prozent weniger Schwachstellen entdeckt, vgl. http://www.microsoft.com/security/ sdl/learn/measurable.aspx und Microsoft SDL Statusbericht, http://www.micro soft.com/germany/msdn/aktuell/news/show.mspx?id=msdn_de_43662, Stand 8.1.2012.

1398

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 49 Q

d) Kriterienkataloge Die Sicherheit informationstechnischer Systeme und damit auch die Si- 47 cherheit einer Software kann nach standardisierten Kriterienkatalogen bewertet werden. Im europäischen Bereich gibt es die ITSEC-Kriterien (Information Technology Security Evaluation Criteria), im internationalen Bereich wird nach Common Criteria (CC, auch ISO 15408) bewertet1. Die Evaluierung nach diesen Kriterien erfolgt durch entsprechend lizenzierte Prüfstellen. Die Lizenzierung wird in Deutschland durch das BSI wahrgenommen. Eine solche Zertifizierung ist werterhöhend, aber auch in einzelnen Aspekten kann man sich bei der Bewertung von Software an den Kriterienkatalogen orientieren. e) ISO/IEC 27001 Die internationale Norm ISO/IEC 27001 wurde 2005 entwickelt, um ein Mo- 48 dell für die Einrichtung, Umsetzung, Durchführung, Überwachung, Überprüfung, Instandhaltung und Verbesserung eines Informationssicherheits-Managementsystems (ISMS) bereitzustellen. Sie ist mit der allgemeinen Norm zur Qualitätssicherung, ISO 9001:2000, abgestimmt und wurde 2008 in deutscher Sprachfassung unverändert in das deutsche Normenwerk übernommen2. Das Dokument ist sehr generisch gehalten, um auf alle Organisationen unabhängig von Typ, Größe und Geschäftsfeld anwendbar zu sein. 5. Software-Qualität Qualität bedeutet relative Beschaffenheit3 und wird in DIN 55350 wie folgt 49 definiert: „Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht.“4. Die Qualität einer Software bestimmt sich in mehreren Dimensionen. Bereits in den 80er-Jahren wurde begonnen, verschiedenste Aspekte, hinsichtlich derer eine Software Stärken oder Defizite haben kann, zu ordnen und zu strukturieren5. Dabei bildeten sich im Wesentlichen sechs Hauptmerkmale heraus, zunächst in den Normen DIN 66272 und ISO/IEC 9126, die in der Norm ISO/IEC 25000 aufgegangen sind6. 1 Ein komprimierter Überblick findet sich in Claudia Eckert, IT-Sicherheit, 2009, Kapitel 5, Bewertungskriterien. 2 DIN ISO/IEC 27001:2008-09 Informationssicherheits-Managementsysteme – Anforderungen (ISO/IEC 27001:2005), Beuth Verlag, 2008. 3 Abgeleitet aus dem lateinischen Wort qualitas. 4 DIN 55350-11:1995. 5 Vgl. z.B. Sneed, Software-Management, 1986, S. 89 ff. und Trauboth, Handbuch der Informatik – Software-Qualitätssicherung, 1993, S. 25 ff. 6 Eine knappe, aber über das hier skizzierte hinausgehende Zusammenfassung findet sich in http://de.wikipedia.org/wiki/ISO/IEC_9126, vgl. vertiefend Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 463 ff.

Hoppen

1399

Q Rz. 50

Einzelprobleme

– Funktionalität: Die Software muss angemessen sein, d.h. sich für den vorgesehenen fachlichen Einsatzzweck eignen, sie muss richtig, und fehlerfrei arbeiten, interoperabel, ordnungsmäßig (functionality compliance) und sicher sein. Diese Faktoren wurden im Einzelnen in den vorangehenden Kapiteln thematisiert (vgl. Rz. 22, 23 ff., 32, 36 ff.). – Zuverlässigkeit: Darüber hinaus muss sie in der Lage sein, ihr Leistungsniveau über einen bestimmten Zeitraum zu bewahren. Das ist dann der Fall, wenn sie eine geringe Fehlerrate hat, konform zu Standards und Vorschriften hinsichtlich der Zuverlässigkeit arbeitet und ansonsten möglichst fehlertolerant und im Notfall mit ihren Datenbeständen wiederherstellbar ist. – Benutzbarkeit: Die Software muss in der Anwendung verständlich und leicht erlernbar sein. Sie sollte mit geringem Aufwand bedienbar sein, womöglich mit einer gewissen Attraktivität, indem Sie in der Lage ist, den Benutzer situationsgerecht über Hilfestellungen zur effizienten Nutzung der Anwendung zu befähigen. – Effizienz: Das Zeitverhalten der Anwendung muss angemessen sein, sowohl im Dialog mit dem Anwender als auch im Durchsatz bei Massenverarbeitungen. Dabei sollten nur angemessene Ressourcen der Ausführungsumgebung verbraucht werden (Verbrauchsverhalten). – Wartbarkeit: Ursachen von Mängeln müssen im Quellcode und den begleitenden Unterlagen der Software diagnostiziert und änderungsbedürftige Teile identifiziert werden können (Analysierbarkeit). Die Softwarearchitektur muss mit vertretbarem Aufwand und überschaubaren Nebenwirkungen modifizierbar sein. – Portabilität/Übertragbarkeit: Die Software muss von einer in eine andere Umgebung übertragen werden können. Dazu muss sie anpassbar und variabel installierbar sein und mit anderen Softwareprodukten koexistieren können. 50 Bei der Bewertung von Software kann in der Regel aus Zeit- und Aufwandsgründen keine umfassende Analyse der Qualität der Software erarbeitet werden1. Dennoch bieten sich auch hier kursorische Prüfungen zu qualitätsbestimmenden Einzelaspekten an. a) Fehlerfreiheit 51 Das Ablaufverhalten kann in der Regel anhand von Fehlerstatistiken beurteilt werden, die bei dem Softwareentwickler geführt werden (vgl. 1 „Der Entwicklungsfortschritt ist objektiv nicht zu ermitteln. … Um festzustellen, ob dieses Dokument oder Quellprogramm überhaupt verwendbar ist, ist eine genaue Untersuchung durch einen Experten erforderlich. Um die Qualität zu überprüfen, muss man fast denselben Aufwand betreiben wie bei der Entwicklung.“, Helmut Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 151.

1400

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 56 Q

Rz. 156 ff.). In der Bewertungspraxis bieten ersatzweise auch Aufzeichnungen der Hotline bzw. des Second Level Supports Anhaltspunkte hinsichtlich der Fehlerfreiheit der Software. Eine Betrachtung der Werte – – – –

Anzahl neuer Fehlermeldungen Rückstand offene Meldungen maximale Bearbeitungsdauer durchschnittliche Bearbeitungsdauer

über mehrere Perioden liefert in der Regel ein gutes Bild über absolute Größenordnungen und Tendenzen. b) Laufzeitverhalten, Performanz und Stabilität Das Antwortzeitverhalten muss bei allen Bedienvorgängen so gestaltet sein, dass die Arbeit der Benutzer wirkungsvoll unterstützt wird und bei normaler Last keine den Arbeitsfluss behindernden Wartezeiten auftreten. Anwenderfehler müssen weitgehend abgefangen werden.

52

Hintergrund-Prozesse müssen so ablaufen, dass die Software das gesamte 53 Arbeitsvolumen auch bei Lastspitzen mit ausreichenden Zeitpuffern insgesamt bewältigen kann und dabei noch ausreichende Wartungsfenster freigehalten werden können. Die Software muss eine ausreichende Verfügbarkeit bieten, möglichst kon- 54 zeptionell bereits im Design abgesichert und sich auch in Ausfallsituationen so verhalten, dass der ordnungsgemäße Betrieb mit festgelegten Prozeduren wieder aufgenommen werden kann. Zu Beurteilung heranzuziehen sind die vorgegebenen Anforderungen und 55 Mengengerüste, die aus der Software-Architektur ableitbaren qualitativen Eigenschaften der Software, Systemprotokolle aus produktiven Umgebungen sowie ggf. Informationen aus Anwenderbefragungen. c) Ergonomie, Usability Während in den Anfangszeiten der Programmierung zunächst die reine Funk- 56 tionalität im Vordergrund stand1, kommt es seit Entwicklung der heute üblichen grafischen Bedienoberflächen (graphical user interface, GUI) entscheidend darauf an, wie der Benutzer seine Aufgaben mit der Software erledigen kann, auch unter Berücksichtigung rechtlicher Vorgaben, etwa in Deutschland der Bildschirmarbeitsverordnung (BildscharbV) oder der EG-Richtlinie 90/270/EWG2. Dies betrifft im Grundsatz sowohl installierte Anwendun1 Von mittlerweile nur noch historischen Interesse aber aus heutiger Sicht durchaus interessant sind z.B. die Ausführungen zum User Interface aus der Frühzeit grafischer Benutzeroberflächen in Ian Sommerville, Software Engineering, Menlo Park 1982, 1985, S. 228 ff. 2 Vgl. Streitz, Software-Ergonomie, NJW-CoR1996, 23 ff.

Hoppen

1401

Q Rz. 57

Einzelprobleme

gen (sog. Fat Clients) als auch Anwendungen, die über eine webbasierte Oberfläche zugänglich sind. 57 Die Normenreihe DIN EN ISO 9241 definiert Richtlinien der Interaktion zwischen Computer und Mensch, darunter in mehreren Teilen auch Richtlinien, die die Entwicklung von Software betreffen1. In Teil 110 dieser Norm werden Qualitätskriterien als Grundsätze der Dialoggestaltung definiert: Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität, Fehlertoleranz, Individualisierbarkeit und Lernförderlichkeit2. Die Norm ISO/IEC 9126 definiert in Teil 4 Maße für die Usability, also die Benutzbarkeit einer Software in den Kategorien Effektivität, Produktivität, Sicherheit und Zufriedenheit3. 58 Im Rahmen einer Software-Bewertung können auch bei einer kursorischen Prüfung Indizien zur Ergonomie der Software gewonnen werden. Softwareanwendungen arbeiten heute üblicherweise mit Bedienobjekten wie TabControls, Drop-Down-Listen etc. Informationen sollten übersichtlich in den einzelnen Bildschirmbereichen angeordnet werden. Dabei sollte deutlich zwischen unterschiedlichen Bereichen (Sichten, Selektionen, Eingabefeldern, Anzeigefeldern) unterschieden werden. Bildschirmgestaltung und Aufteilung sollten einheitlichen Grundsätzen folgen. Die Farbgestaltung sollte modifiziert werden können, um so auf Sehschwächen einzelner Benutzer eingehen zu können. Die angezeigten Informationen müssen umfassend zur Bearbeitung des jeweiligen Geschäftsvorfalls sein. 59 Die Bedienung sollte über die ganze Anwendung hinweg einheitlich sein. Eingaben sollten validiert und Fehleingaben frühestmöglich abgewiesen werden. Kopierfunktionen mit den gängigen Windows-Bedienfunktionen können heute in allen Bereichen erwartet werden, in denen sie sinnvoll zur Verbesserung der Arbeitsabläufe eingesetzt werden können. Tabellarische Darstellungen sollten vom Benutzer modifiziert werden können hinsichtlich Spaltenfolge, Spaltenbreite und Sortierung. Die Menüs sind individuell anpassbar. Ausdruck-Vorschaufunktionen sind heute als Standard anzusehen. 60 Die Navigation und Eingaben sollten anstelle einer Bedienung über die Maus auch durchgängig über die Tastatur möglich sein. Grundfunktionen der Bedienung zum Einfügen, Ändern, Selektieren und Löschen von Daten 1 EN ISO 9241 Teile 11–17, 110 und 151. 2 Teil 10 der Norm wurde in 2006 durch den inhaltlich aktualisierten Teil 110 ersetzt, s. weiterführend Balzert, Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2, 2005, S. 220 f. oder Balzert, Lehrbuch der Softwaretechnik – Softwareentwicklung, 2001, S. 677 f. Eine knappe, aber über das hier skizzierte hinausgehende Zusammenfassung findet sich auch unter http://de.wi kipedia.org/wiki/Software-Ergonomie. 3 ISO/IEC TR 9126-4 Software engineering – Product quality – Part 4: Quality in use metrics, s. im Überblick auch Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 466.

1402

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 65 Q

sind über die ganze Oberfläche der Software hinweg einheitlich auszugestalten. Bei Fehleingaben muss eine frühestmögliche Fehlermeldung erfolgen. Zum Stand der Technik gehört auch, dass das System Statusmeldungen und Fortschrittsanzeigen ausgibt, sobald die Reaktion auf Eingaben nicht unmittelbar erfolgt. In Bildschirmanzeigen können flexible Filterfunktionen zur Selektion der ausgegebenen Daten erwartet werden. Viele Anwendungen bieten Möglichkeiten, in einem Expertenmodus auch individuelle Abfragen über Abfragegeneratoren zu gestalten und stellen flexible Möglichkeiten zum Datenexport in den verschiedensten Formaten, fast immer auch in Microsoft Excel, zur Verfügung. Unter Ergonomieaspekten sind auch die Anpassungsmöglichkeiten an orga- 61 nisatorische Anforderungen zu beurteilen. Hierzu zählen Möglichkeiten im Bereich der Gestaltung von Bildschirm- und Druckausgaben, der Anordnung der Bildschirmbereiche, der Menügestaltung und der Vergabe von Zugriffsberechtigungen. Förderlich für die Software-Ergonomie ist eine gute Abstimmung von Me- 62 nübreite und Menütiefe. Die Anzeige der Funktionshierarchie und ggf. der Anmelddaten sollten jederzeit die Orientierung geben, in welchem Datenbestand gerade gearbeitet wird. Der Softwareentwicklung sollte ein Gestaltungsregelwerk (style guide) zugrunde liegen, in dem grundsätzlich festgelegt wird, wie die Bedienoberfläche einheitlich zu gestalten ist. Hier finden sich dann Vorgaben zur Ausprägung der vorgenannten Einzelaspekte.

63

d) Mehrsprachigkeit Voraussetzung für die Vermarktbarkeit einer Software in mehreren Ländern 64 ist die Mehrsprachigkeit. Immer ist darunter zu verstehen, dass in der Benutzeroberfläche zwischen mehreren Sprachen umgeschaltet werden kann. Aber auch Anwendungsdaten, z.B. Artikeltexte, müssen in mehreren Sprachen erfasst werden können. Auch bei einem rein unternehmensinternen Einsatz ist Mehrsprachigkeit heute häufig erforderlich, wenn das Unternehmen über Standorte und Mitarbeiter in mehreren Ländern verfügt. Aus technischer Sicht ist es deshalb vorteilhaft, wenn die Software den UnicodeZeichensatz unterstützt (in jedem Fall erforderlich für die Darstellung chinesischer und anderer asiatischer Sprachzeichen) und alle sprachabhängigen Texte separiert vom Quellcode in einem sog. Repository gehalten werden. e) Wartbarkeit (Pflegbarkeit, Änderbarkeit), Skalierbarkeit Von ganz entscheidender Bedeutung bei der Wertbestimmung einer Software ist deren Zukunftsfähigkeit. Der Großteil der Kosten im Lebenszyklus einer Software, je nach Erhebung unterschiedlich, aber vielfach mit etwa

Hoppen

1403

65

Q Rz. 66

Einzelprobleme

70 % beziffert1, entfällt auf die Betriebs- und Wartungsphase. Im Gegensatz zu anderen industriell gefertigten Gütern bedeutet Wartung bei Software nämlich nicht nur das Erhalten des ursprünglichen Zustands bzw. Korrigieren von Fehlern, sondern im Gegenteil fast immer die Fortentwicklung und Anpassung der Software an geänderte Bedingungen, also das Erreichen neuer Zustände. Unter Wartung können alle Arbeiten an der Software verstanden werden, die bei der Entwicklung noch nicht geplant waren. Sie lassen sich klassifizieren in korrektive, adaptive, perfektive und präventive Maßnahmen2. 66 Die durch die Wartung entstehenden Kosten, sei es im Eigenbetrieb oder bei der vertriebsmäßigen Verwertung, bestimmen sich zu einem hohen Maße danach, wie einfach es ist, den Status Quo der Software zu analysieren, um Fehler im Quellcode oder änderungsbedürftige Teile identifizieren zu können (Pflegbarkeit). Software ist zudem nichts Statisches, sondern unterliegt immer Änderungen, aus internen wie externen Gründen. Deswegen muss eine Software mit vertretbarem Aufwand modifiziert und erweitert werden können (Änderbarkeit). Dazu gehört auch die Erhöhung von Durchsatzraten bei wachsenden Nutzer- oder Zugriffszahlen oder funktionalen Erweiterungen (Skalierbarkeit). Dies macht deutlich, dass sich bereits während der Entwicklung entscheidet, wie einfach oder schwierig die Wartung sein wird. Wartung beginnt nicht erst nach Abschluss der Entwicklung. 67 Die Bewertung einer Software hinsichtlich der Wartbarkeit erfordert in der Praxis fast zwingend eine Befassung mit folgenden technischen Aspekten, auf die in den nächsten Kapiteln eingegangen wird: – Technologische Basis und Software-Architektur: Diese Merkmale sind entscheidend für die zu erwartenden Aufwendungen bei der Wartung einer Software. Von außen, also anhand der Funktionalität, der Benutzeroberfläche und der Anwenderdokumentation sind sie in der Regel nicht beurteilbar. Ungünstige Kopplung und Abhängigkeiten von Systemkomponenten können die Wartbarkeit erschweren (s. Rz. 68 ff.). – Qualität des Quellcodes: Der Quellcode kann für Dritte aber nach einiger Zeit auch für den Entwickler selber gut verständlich oder unverständlich sein (vgl. Kap. C Rz. 283 ff.). Gerade in komplexen objektorientierten Software-Architekturen kann es entscheidend sein, nicht allen „Versuchungen“ zu erliegen, die eine Programmiersprache bietet, sondern sich an bewährte Entwurfsmuster, sog. Patterns zu halten (s. Rz. 74 ff.). – Qualität des Datenmodells: Daten können günstig oder ungünstig abgespeichert werden. Das wird zwar bei einer Software-Bewertung kaum 1 Balzert verteilt 1/3 zu 2/3, s. Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, Heidelberg 2008, S. 195, Sneed nennt 25 % zu 75 %, s. Sneed, Software-Projektkalkulation, 2005, S. 117. 2 So schon Swanson, The Dimensions of Maintenance, 2nd Intern. Conf. on Software Engineering, IEEE, 1976 und später im Standard Glossary of Software Engineering Technology, IEEE Std., 1990, 610.12.

1404

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 68 Q

hinsichtlich aller denkbaren Aspekte beurteilt werden können, dennoch kennt die Informatik auch hier Grundprinzipien, die im Sinne der Pflegund Änderbarkeit einer Software eingehalten werden sollten (s. Rz. 92 ff.). – Dokumentation der Software und der Softwareentwicklung: Der effiziente Zugang zu einer Software ist nur bei kleinen Programmen alleine aus dem Quellcode heraus möglich. In der Regel ist es erforderlich, den Zugang prinzipiell auch (bisher) unbeteiligten Dritten offen zu halten (z.B. neuen Programmierern oder bei Fortsetzung der Entwicklung in einer anderen Organisation). Dies erfordert eine ordentliche und aktuelle Softwareentwicklungs-Dokumentation und Kommentierung des Quellcodes (vgl. Rz. 100 ff.). – Entwicklungsprozesse: Die Wartbarkeit eines Software-Produktes wird maßgeblich durch die Prozesse bestimmt, in denen die Entwicklung vollzogen wurde. Eine methodische, systematische und geplante Vorgehensweise hilft, Arbeiten an der Software verlässlich planen und effizient durchführen zu können. Gute Entwicklungsprozesse umfassen die effiziente Nutzung von Werkzeugen in einer Entwicklungsumgebung und ermöglichen auch umfangreichere Umgestaltungen bzw. Restrukturierungen (sog. Refactoring1) bei größeren Änderungen oder Erweiterungen (s. Rz. 119 ff.). – Qualitäts-Sicherungsmaßnahmen: Die Qualität einer Software und damit auch die Wartbarkeit kann durch konstruktive und analytische QS-Maßnahmen deutlich verbessert und abgesichert werden (s. Rz. 148 ff.). QS-Maßnahmen sind in die Softwareentwicklungsprozesse eingebettet. Bspw. findet in bestimmten Prozessmodellen eine Verzahnung von Spezifikation und Test statt, indem Testfälle bereits parallel zu der Anforderungsspezifikation definiert werden (z.B. V-Modell) oder der erforderliche Programmcode für automatisierte Tests auf Komponentenebene bereits parallel mit der Codierung der einzelnen Komponenten entsteht (test driven development, s. Rz. 125 ff.). 6. Technologische Basis, Software-Architektur Die technologische Basis einer Software bestimmt sich aus der intendierten 68 Ausführungsumgebung (Betriebssysteme, Datenbanken, KommunikationsInfrastruktur), der Entwicklungsumgebung, den verwendeten Programmiersprachen sowie den fertigen Komponenten (Frameworks, Libraries), auf die bei der Entwicklung zurückgegriffen wird. Eine ungünstige oder aus historischen Gründen mittlerweile überalterte technologische Basis kann erheblich aufwandserhöhend sein. Vorteilhaft im Sinne der Wartbarkeit ist, wenn gut dokumentierte und marktgängige Softwareentwicklungs-Umgebungen (IDE, integrated development environment) oder Programm-Generatoren 1 Vgl. Fowler, Refactoring – oder: Wie Sie das Design vorhandener Software verbessern, 2000.

Hoppen

1405

Q Rz. 69

Einzelprobleme

eingesetzt werden. Die klassischen Entwicklungswerkzeuge Editor, Compiler bzw. Interpreter und Linker1 reichen heute praktisch nicht mehr aus, um Softwareentwicklung effizient zu betreiben. Integrierte Programmentwicklungs-Umgebungen koordinieren und automatisieren heute Aktivitäten, die über die reine Programmierung hinausgehen, vor allem Spezifikation, Entwurf und Test der Software und helfen dem Programmierer, den Quellcode der Software im Laufe seines Lebens zu analysieren und systematisch, effizient und in sich konsistent zu restrukturieren, zu transformieren, neu zu kombinieren, zu vermessen (sog. Profiling) und zu dokumentieren. Sie unterstützen ferner die Kollaboration und Kommunikation in Entwicklungsteams und bieten Schnittstellen zum übergeordneten Projektmanagement2. Besonders die Entwicklung und Nutzung von Open-Source-Komponenten ist ohne zeitgemäße Entwicklungsumgebungen nicht mehr vorstellbar. Weitverbreitete Entwicklungsumgebungen werden selber als Open-Source-Projekte entwickelt, sind unabhängig von einzelnen Programmiersprachen und bieten offene Plattformen zur Integration vielfältiger Zusatzkomponenten3. 69 Die Software-Architektur bestimmt, wie die Software vom Grunde her aufgebaut ist, in welche (horizontalen) Basiskomponenten und (vertikalen) Funktionskomponenten sie untergliedert ist und wie diese Komponenten zusammenspielen. Die Software-Architektur bestimmt die Eigenschaften der Software hinsichtlich Sicherheit, Stabilität, Performanz, Wartbarkeit, Skalierbarkeit und Integrierbarkeit. Grundlegende Architekturentscheidungen sind die Wahl von Betriebssystem und Datenbank, der Programmiersprache und die Festlegung auf einzusetzende Frameworks, z.B. für die Datenhaltung und die Bedienoberfläche (GUI). 70 Vorteilhaft – und in der Praxis seit vielen Jahren etabliert – ist eine aus mehreren Schichten bestehende Architektur der Software. Dabei sind fast immer vorzufinden (sog. three-tier architecture): – Datenhaltungs-Schicht: Durch diese Schicht wird das Datenmodell der Software unabhängig und ausführbar auf unterschiedlichen Datenbanken. Dies kann erreicht werden durch entsprechende Abstraktionslayer im Quellcode der Software (häufig werden hierzu auch Open SourceKomponenten eingesetzt). – Anwendungs-Schicht: In dieser Schicht wird die eigentliche fachliche Funktionalität implementiert, möglichst unabhängig von Eigenschaften konkreter Ein-, Ausgabeeinheiten. Die Ausführung des so implementierten Codes erfolgt häufig auf sog. Applikationsservern, kann aber auch in der Implementierung mit der Benutzeroberfläche kombiniert sein. Bei

1 S. Schmidt, in: Beck’sches Mandats-Handbuch IT-Recht, § 1 Rz. 33, 83. 2 S. weitergehend Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 2009, S. 60 ff. 3 Ein führendes Beispiel hierfür ist die Entwicklungsplattform Eclipse, s. www. eclipse.org.

1406

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 73 Q

sog. Client-Server-Architekturen fehlt diese Schicht beispielsweise, sie ist dann mit der Präsentations-Schicht verwoben. Dies ist nicht notwendigerweise ein wertmindernder Faktor. In der Organisation des Quellcodes kann die fachliche Funktionalität durchaus sauber isoliert implementiert und dennoch im Objekt-Code in die Präsentations-Schicht (Client-Software) integriert sein. Bei komplexen Systemen kann die Anwendungs-Funktionalität ihrerseits wieder mehrschichtig untergliedert sein oder eigene Zwischenschichten an der Schnittstelle zu Datenhaltungs- und Präsentationsschicht haben (z.B. um eine Unabhängigkeit von der verwendeten Datenbank zu erhalten). – Präsentations-Schicht: In dieser Schicht wird in erster Linie der Zugriff auf die Software implementiert, sei es als grafische Benutzeroberfläche, webbasierte Oberfläche, Verlagerung einzelner Funktionen in sog. Apps für mobile Endgeräte oder auch Ausgabefunktionalitäten für Reporting, Business Intelligence und Schnittstellen zur technischen Integration mit benachbarten Systemen in übergeordneten Anwendungsszenarien. Generell lässt sich sagen, dass eine hohe und saubere Modularisierung einzelner Funktionskomponenten, heutzutage technisch unterstützt durch objektorientierte Programmiersprachen, aufwandsminimierend wirkt.

71

Bei Änderungen an einer Software bestehen immer Risiken unerwünschter Nebenwirkungen. Bei ungünstiger Software-Architektur können diese so groß werden, dass eine Software praktisch nicht mehr modifizierbar bzw. erweiterbar ist. Insbesondere bei langjährigen inkrementellen Entwicklungen mit Ad-Hoc-Änderungen und ohne zwischenzeitliches Reengineering steigt ein solches Risiko erheblich an.

72

Bei einer Sonderform der Softwareentwicklung, der sog. modellgetriebenen 73 Entwicklung (engl. Model Driven Architecture MDA oder Model Driven Software Development MDSD) wird angestrebt, die gesamte Anwendungslogik in einem formalen Modell zu beschreiben, aus dem heraus automatisiert Quellcode generiert werden kann. Diese Ideen sind nicht neu1, fallen aber vor dem Hintergrund stetig steigender Rechenleistungen und immer komplexerer Entwicklungsumgebungen besonders in den letzten Jahren auf fruchtbaren Boden. Man entwickelt quasi eine anwendungsspezifische bzw. domänenspezifische Programmiersprache. Die Wartbarkeit einer Software wird durch eine solche Software-Architektur grundsätzlich erheblich gesteigert2. Da der Quellcode generiert wird, sind kaum Fehler zu erwarten oder nur übergreifend und können durch Korrekturen im Quellcode-Generator an zentraler Stelle beseitigt werden. Auch anwendungsweite Änderungen und Ergänzungen können durch zentrale Änderungen im Programm-Gene1 S. z.B. schon in Sneed, Software-Entwicklungsmethodik, 1986, Funktionen eines Programm-Generators, S. 208 ff. 2 S. weitergehend Balzert, Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering, 2009, S. 79 ff.

Hoppen

1407

Q Rz. 74

Einzelprobleme

rator einfach realisiert werden. Erkauft wird dieser Vorteil durch eine erhöhte und im konkreten Anwendungsfall möglicherweise an einzelnen Stellen hinderliche Standardisierung, Verlagerung der Komplexität auf die Modellebene und durch Kompromisse in der Effizienz des Codes. Die Weiterentwickelbarkeit einer solchen Software steht in enger Abhängigkeit zur Weiterentwickelbarkeit der domänenspezifischen Programmiersprache und eingesetzten Programm-Generatoren. Insofern sind diese bei der Bewertung ebenfalls zu betrachten und dabei zu berücksichtigen, dass für mittel- bis langfristige Betrachtungen das Problem der Pflegbarkeit und Änderbarkeit lediglich auf die abstraktere Ebene der modellbetriebenen Architektur verlagert wird. Bei umfangreichen Anwendungen mit einer regulären Lösungsstruktur, z.B. betrieblichen Informationssystemen, kann dies dennoch sehr vorteilhaft sein. 7. Quellcode 74 Software ohne Quellcode ist nicht weiterentwickelbar und nicht wartbar und damit in der Regel praktisch wertlos. Sie kann dann allenfalls einer Restverwertung zugeführt werden oder als Prototyp und Spezifikation für eine neue Softwareentwicklung dienen. Die hier dargestellten Überlegungen gehen immer davon aus, dass der Quellcode der zu beurteilenden Software zumindest in der letztgültigen aktuellen Fassung vorliegt. 75 Auch bei einer sehr detaillierten Spezifikation hat der Programmierer in der Regel große Spielräume in der konkreten Ausgestaltung des Quellcodes. Guter Quellcode ist aus sich selbst heraus verständlich. Hierzu tragen wesentlich bei gut gewählte und konsequent eingehaltene ProgrammierRichtlinien und Codierungsstandards sowie eine aussagekräftige ergänzende Kommentierung (Inline-Dokumentation). a) Zum Einfluss des Programmierstils, Programmier-Richtlinien 76 Ein guter Programmierstil kann die Wartbarkeit und die Möglichkeiten, Fehler in der Software schnell zu finden, erheblich verbessern, und zwar bezogen auf den Quellcode jedes einzelnen Entwicklers, aber auch übergreifend in der Gesamtsicht auf den Quellcode des gesamten Entwicklungsteams. Bekannt ist dies bereits seit langer Zeit1, wird aber dennoch in der Praxis häufig vernachlässigt, besonders in kleineren Programmierteams und in Projekten, die zunächst für eine rein interne Nutzung gedacht waren, aber auch häufig dann, wenn unter Zeitdruck entwickelt wurde. 77 Guter Quellcode ist einfach und klar verständlich, verwendet selbsterklärende und nach einem durchgängigen Konzept vergebene Bezeichner (für Variablen, Funktionen, Prozeduren, Objekte, Eigenschaften, Methoden etc.), unterliegt einheitlichen Konventionen bei der Typisierung von Objekten, 1 Kernighan/Plauger, The Elements of Programming Style, 1978.

1408

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 79 Q

enthält beschreibende Kommentarköpfe zu jedem Programm-Modul in einem einheitlichen Format, ansonsten eine nach einheitlichen Regeln gebildete aussagekräftige Kommentierung (s.u.), die zum Verständnis von Algorithmen beiträgt und verwendet einfache Anweisungen und ein einfaches und übersichtliches textuelles Code-Layout. Fehlerhafte oder unsinnige Eingabedaten sollten im Quellcode erkannt und abgewiesen werden, dazu sollte ein einheitliches Error-Handling implementiert sein, der Code sollte die Ressourcen der Ausführungsumgebung effizient nutzen, aber – von Ausnahmefällen mit kritischer Performanz abgesehen – nicht auf Kosten der Lesbarkeit und Einfachheit1. Ein gut strukturierter und modularisierter Quellcode zeichnet sich insbesondere durch möglichst kurze und überschaubare, in sich abgeschlossene Programmabschnitte (Unterprogramme, Module, Klassen) und einen klar erkennbaren Programmfluss aus. Wiederkehrende Verarbeitungsfolgen werden abstrahiert und in Unterprograme (Funktionen, Prozeduren, Module, Methoden) ausgegliedert. Datenstrukturen werden so gewählt, dass sie die Verständlichkeit fördern. Undurchschaubare Programmlogiken werden vermieden. Solche Grundsätze sind auch – und gerade – in komplexen Algorithmen und Programmsystemen umsetzbar2. b) Codierungsstandards Üblicherweise können in Entwicklungsteams, die auf den Programmierstil 78 achten, Dokumente vorgelegt werden, die Codierungsstandards beschreiben3. Solche internen Richtlinien sind häufig auch Bestandteil proaktiver Qualitätssicherung. Die Kontrolle und der Nachweis der Einhaltung der Codierungsstandards erfordern regelmäßige Quellcode-Inspektionen. Die Dokumentation solcher Inspektionen ist als weiterer wertbestimmender Faktor anzusehen. c) Inline-Dokumentation Quellcode enthält in der Regel Kommentare, in denen der Entwickler wich- 79 tige Gedankengänge und Nutzungshinweise festhält, die bei der späteren Nutzung und Wartung des Quellcodes ansonsten nur durch zeitaufwändige Analysen wiederzugewinnen wären. Zu einer Inline-Dokumentation gehört in jedem Fall die systematische und einheitliche Beschreibung von Programm-Funktionen im Kopf einzelner Programm-Objekte (Funktionen, Prozeduren, Module, Methoden, Klassen) und auf der gröberen Ebene einzelner Programm-Dateien. Standard in dieser Hinsicht bei der Entwicklung von 1 Pressmann, Software Engineering – Grundkurs für Praktiker, 1989, S. 177 ff. 2 S. weiterführend Martin, Clean Code – A Handbook of Agile Software Craftsmanship, Englewood Cliffs, NJ, 2008. 3 Zeitgemäße Beispiele für Richtlinien und Konventionen zur Benennung von Objekten und Checklisten zur Beurteilung von Quellcodes finden sich z.B. in Balzert, Lehrbuch Grundlagen der Informatik, 2005, Abb. A-1 bis A-7 in Anhang A.

Hoppen

1409

Q Rz. 80

Einzelprobleme

Software in Java ist die Dokumentation der Programmtexte in JavaDoc1. Hierbei handelt es sich um ein Konzept, in dem anhand speziell markierter Kommentare innerhalb des Programmquelltextes eine gesonderte Dokumentation der Software erstellt werden kann. Diese Dokumentation ist insbesondere im Rahmen der Softwarepflege und Änderung eine notwendige Voraussetzung. In anderen Programmiersprachen gibt es vergleichbare Konzepte. 80 Viele Entwicklungsumgebungen2 sind in der Lage, bei der Codierung kontextabhängig Hilfetexte als Auszüge aus der Inline-Kommentierung anzuzeigen, wenn bei der Formatierung der Kommentierung bestimmte Standards eingehalten wurden (sog. Content-Assist, Auto-Completion, TypeAhead o.Ä.). 81 Die Qualität einer Inline-Dokumentation kann in der Regel erst bei der konkreten praktischen Arbeit mit dem Quellcode erkannt werden. Anhaltspunkte für eine Softwarebewertung können aber auch anhand quantitativer Indikatoren gewonnen werden. Eine einfache Kenngröße ist der Anteil von Kommentarzeilen (comment ratio CR) am gesamten Quellcode-Volumen. Als Daumenregel können Anteile an qualifizierter Kommentierung am Quellcode von unter 5 % als ungenügend, Anteile von 15 % bis 30 % als gut und Anteile von über 30 % als außergewöhnlich angesehen werden, wobei dies immer im Zusammenhang mit der Anwendungsdomäne, der Komplexität3 und der sonstigen Strukturierung des Codes beurteilt werden muss4. Der Umfang alleine ist aber nicht alles. Gute Kommentare begründen die gewählte Codierung und beschreiben Zusammenhänge und Schnittstellen, sie wiederholen nicht die ohnehin codierte Logik und sie überdecken nicht wichtige Hinweise mit trivialen Ausführungen. d) Modellierungstechniken, Design Patterns 82 Im Rahmen der Softwarebewertung kann der Code mit vertretbarem Aufwand auch danach untersucht werden, inwieweit die Softwareobjekte und ihr Zusammenspiel nach einheitlichen Entwurfsmustern codiert wurden. In der objektorientierten Softwareentwicklung haben sich bereits seit Längerem verschiedene standardisierte Entwurfsmuster, sog. design patterns 1 Balzert, Lehrbuch Grundlagen der Informatik, 2005, Abb. A-14 in Anhang A. 2 Z.B. die verbreitet genutzte Open-Source-Entwicklungsumgebung Eclipse oder Microsoft Visual Studio. 3 Die auch messbar ist, z.B. als Anzahl der möglichen Ausführungspfade durch einen Quelltext (Cyclomatic Complexity CC). 4 Vgl. hierzu z.B. die Codierungsstandards des Infospheres Team am California Institute of Technology Caltech aus 1999: „Horribly commented code averages 0–5 % comment ratio, poorly commented code has a 5–10 % comment ratio, average code has a 10–15 % comment ratio, good code has a 15–25 % comment ratio, excellent code has a L 25 % comment ratio.“, http://www.sourceformat. com/coding-standard-java-caltech.htm.

1410

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 84 Q

durchgesetzt1. Es handelt sich um bewährte generische Codestrukturen für immer wiederkehrende Kategorien von Entwurfsaufgaben. Typische Begriffe sind factory pattern, singleton pattern, composite pattern, proxy pattern, facade pattern, observer pattern. Die Codierung nach solchen Standards hält eine Softwarearchitektur deutlich verständlicher, einfacher und kompakter und macht sie wiederverwendbar. Ansonsten können gerade in der objektorientierten Programmierung nicht mehr durchschaubare Abhängigkeiten zwischen verschiedenen Objektklassen entstehen, die die Wartbarkeit eines Quellcodes deutlich behindern können. e) Libraries und Open-Source-Komponenten In Softwareentwicklungen fließen heute fast immer Softwarekomponenten 83 ein, die auch an anderer Stelle Verwendung finden und in der Regel ihren eigenen Lizenzbedingungen unterliegen. Bei solchen Softwarekomponenten kann es sich handeln um – kommerzielle Softwarekomponenten von Drittanbietern (Libraries, Bibliotheken), – Open-Source-Softwarekomponenten, häufig auch ganzen Frameworks, die grundlegende Aspekte der entwickelten Software betreffen, – ad-hoc im Internet recherchierte Code-Fragmente aber auch – Softwarekomponenten des Softwareentwicklers, die er auch in anderen Entwicklungsprojekten verwendet oder zukünftig verwenden möchte (Frameworks, Libraries). Der Softwareentwickler arbeitet nicht mehr nur mit den Sprachkons- 84 trukten der Programmiersprache, sondern bindet solche Bibliotheken mit fertigem Quellcode in sein Projekt ein. Bei Bedarf kann er sich in den Quellcode einarbeiten und diesen modifizieren. Dabei kann es sich um Elementarfunktionalitäten handeln (etwa die Verarbeitung intern benötigter Speicherobjekte (Arrays, Strings), Abstrahierungsschichten zur dauerhaften Abspeicherung von Datenbeständen in Datenbanken (sog. Persistenzlayer), fertige Komponenten der an der Benutzeroberfläche der Software sichtbaren Bedienelemente (Menüleisten, Eingabefelder, Suchfelder, Kalender-Elemente, Anzeige von Kartendarstellungen, Explorer-artige Auswahllisten und Auswahlbäume etc.), Datumsfunktionen, Formelsammlungen, Datenkonvertierungen, Verschlüsselungs- oder andere Sicherheitsroutinen, Programme zur Aufbereitung von Druckreports u.v.m.2. 1 Das Standardwerk hierzu ist Gamma/Helm/Johnson/Vlissides, Design Patterns – Elements of Reusable Object-Oriented Software, 1995, einen guten Überblick gibt auch Balzert, Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2, 2005, S. 356 ff. 2 S. weitergehend Hoppen/Thalhofer, Der Einbezug von Open Source-Komponenten bei der Erstellung kommerzieller Software, CR 2010, 275 ff.

Hoppen

1411

Q Rz. 85

Einzelprobleme

85 Frameworks implementieren einen wiederverwendbaren Entwurf für eine bestimmte Aufgabenstellung. Sie definieren die Architektur einer Softwareanwendung hinsichtlich dieser Aufgabenstellung und ermöglichen es dem Programmierer, sich auf abstraktere Fragestellungen zu konzentrieren. Frameworks beschleunigen die Anwendungsentwicklung und vereinheitlichen die internen Strukturen der Software, was zu verringerten Wartungskosten führt1. 86 Das Interesse des Auftraggebers einer Softwareentwicklung geht meistens dahin, die vollen Rechte an der in seinem Auftrag erstellten Software zu erhalten, also einschließlich der Rechte an allen inkludierten Bibliotheken, Frameworks etc., um sich alle Möglichkeiten der Weiterentwicklung der Software zu sichern. 87 Bei der Softwarebewertung ist zu ermitteln, in welchem Umfang Libraries, Frameworks oder andere Softwarekomponenten mit eingeschränkten Nutzungsrechten, sei es als FOSS (free and open source software) oder kommerzielle Komponenten, in den Quellcode eingeflossen sind (vgl. Rz. 238 ff.). 88 Verletzungen von Rechten Dritter können den Wert einer Software erheblich beeinträchtigen, im Extremfall sogar ganz zunichte machen. Große Softwarehäuser betreiben mittlerweile erhebliche Anstrengungen auf strategischer und operativer Ebene, um solche Entwicklungen zu vermeiden. Spezialisierte Firmen bieten entsprechende Dienstleistungen zur Überwachung von Quellcodes und zum Abgleich mit bekannten Codes aus freier Software und Open-Source-Software an. Die Problematik wird dadurch verschärft, dass im Internet in allen gängigen Programmiersprachen Code-Fragmente zu praktisch allen kleineren Problemstellungen einfach zu finden sind. In der Praxis erliegen Programmierer erwiesenermaßen vielfach der Versuchung, solche Fragmente leicht modifiziert in den eigenen Code zu übernehmen2. Solche Verletzungen sind praktisch bei einer Softwarebewertung nicht aufdeckbar. Deswegen ist es positiv zu werten, wenn der Softwareentwickler über strategische Prinzipien und Prozessrichtlinien (FOSS policies) sowie fest definierte Kontrollprozesse verfügt und das Thema proaktiv besetzt und intern kommuniziert. Eine wirksame FOSS-Strategie – wird von der Unternehmensleitung initiiert und gesteuert, – definiert die Richtlinien, unter denen FOSS-Komponenten getestet, zur Nutzung freigegeben, in die Software eingebaut und weiterverteilt wird,

1 S. Balzert, Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2, 2005, S. 358 f. 2 „Firms must recognize and acknowledge the existence of Internet code in their own code bases. Given our findings, they should further consider that some of the Internet code reused in their software might also violate license obligations“ in: Sojer/Henkel, License Risks from Ad Hoc Reuse of Code from the Internet, Communications of the ACM Dec. 2011, Vol. 54 No. 12, S. 74 ff.

1412

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 92 Q

– sensibilisiert die Entwickler hinsichtlich der rechtlichen Lizenzierungsfragen und der damit verbundenen Risiken und gibt ihnen klare Leitlinien, – findet ihren Niederschlag in den konkreten Arbeitsprozessen bei Codierung (Codier-Richtlinien), Updateverfahren, Test- und Freigabeprüfungen und – definiert die eigene Beteiligung in Open-Source-Projekten oder allgemein in der FOSS-Community. f) Versions-Management, fehlender Quellcode Quellcode wird heute üblicherweise in allen im Laufe der Entwicklung ent- 89 standenen Zwischenständen in einem Versionsmanagement-System gespeichert1. Mit jedem Release der Software wird ein neuer Zweig (sog. Branch) eröffnet. Fehler können in dem jeweiligen Branch des alten Releases gefixt werden. Alte Versionsstände lassen sich rekonstruieren und es ist möglich, an alten Versions- bzw. Releaseständen unabhängig vom Stand der neuesten Version Wartungsarbeiten vorzunehmen. Die Verfügbarkeit historischer Quellcodes ist insofern wertbestimmend. Fehlen historische Quellcodes, ist zu prüfen, inwieweit davon die Wartbar- 90 keit bestehender Installationen betroffen ist. Ggf. ist dies in Form höherer Betriebskosten – und damit wertmindernd – zu berücksichtigen. Ähnliches gilt, wenn zwar historische Quellcodes vorliegen, aber – aus wel- 91 chen Gründen auch immer – der aktuell passende Quellcode fehlt. In diesem Fall sind die Aufwendungen abzuschätzen, die erforderlich sind, um aus dem aktuellsten Quellcodes-Stand den Quellcode der aktuellen Software-Fassung erneut herzuleiten, im Ergebnis ebenfalls mit wertmindernder Auswirkung. 8. Datenmodell Üblicherweise speichern Softwareanwendungen ihre Datenbestände heute 92 in Datenbanken. In Datenbanken werden Daten nach einheitlichen Prinzipien und unter der Steuerung eines Datenbank-Management-Systems (DBMS) gespeichert. Dies ermöglicht die Zusammenführung, Konsolidierung und zentral gesicherte Verwaltung von Unternehmensdatenbeständen, auch wenn sie von unterschiedlichen Anwendungen verwaltet werden. Die Struktur der von einem DBMS verwalteten Datenbanken wird in dem sog. Data Dictionary verwaltet (DD). Der mit Abstand am weitest verbreitete Datenbank-Typ sind relationale Datenbanken (RDBMS). Historisch gab es

1 Weitverbreitet sind z.B. als Open-Source-Lösung Subversion (SVN) und im kommerziellen Umfeld Microsoft Visual SourceSafe (VSS). Neue verteilte Versionsverwaltungssysteme sind Git oder Mercurial.

Hoppen

1413

Q Rz. 93

Einzelprobleme

hierarchische Datenbanken und Netzwerk-Datenbanken, die wegen ihrer Performanz in großen Anwendungssystemen von Versicherungen und Banken teilweise heute noch im Einsatz sind, aber ansonsten seit den 1990er Jahren von RDBMS abgelöst wurden. In den letzten Jahren etablieren sich neue Konzepte, insbesondere objektorientierte Datenbanken1. 93 Die Art und Weise, wie Daten in einer Datenbank gespeichert und verarbeitet werden, wird in einem sog. Datenmodell beschrieben. Das Datenmodell beschreibt primär – Datentabellen zur Speicherung der eigentlichen Daten (sog. Entitäten), – Index-Definitionen zur Beschleunigung des Zugriffs auf die Daten, – relationale Beziehungen zwischen einzelnen Tabellen über sog. Fremdschlüssel (foreign keys) und – spezialisierte und gefiltert Sichten auf Daten mit eigenen Zugriffsrechten (sog. Views). 94 Es kann darüber hinaus aktive Code-Objekte umfassen (Funktionen, StoredProcedures, Trigger) die auf der Datenbank ausgeführt werden können, um gezielt Verarbeitungen auf den Datenbeständen vorzunehmen. Bestimmte Programmcodes können auch an Ereignisse (Einfügen, Ändern oder Löschen von Datensätzen) gekoppelt sein, man spricht dann von sog. Triggern. 95 Vielfach wird das Datenmodell jedoch bewusst einfach gehalten und lediglich die Möglichkeit der Datenbanken genutzt, Daten in Tabellen zu speichern. Man erreicht dadurch die Unabhängigkeit von spezifischen Funktionsmerkmalen einzelner Datenbankprodukte. Es werden dann weder Views noch Functions, Stored Procedures oder Trigger genutzt, die entsprechende Funktionalität wird in der Anwendungs-Schicht und der Datenhaltungs-Schicht der Software implementiert. In der objektorientierten Programmierung können durch eine saubere Kapselung des Datenzugriffs in Objektklassen (Datenbank-Abstraktionslayer, object relational mapping) gleiche Ergebnisse erzielt werden. In diesen Fällen wird auch die referentielle Integrität (konsistente Verknüpfung der Datenelemente) häufig nicht auf Datenbankebene mittels foreign keys erzwungen, sondern im Objektmodell verankert. 96 Unter Bewertungsgesichtspunkten sind die verschiedenen Vorgehensweisen prinzipiell gleichwertig. Wesentlich ist eine saubere und durchgängige Konzeption und Umsetzung, verbunden mit einer in sich konsistenten Dokumentation des Datenmodells, auch toolbasiert als grafische Darstellung der einzelnen Tabellen und ihrer Beziehungen untereinander. Tabellen- und Feldbezeichnungen der Datenstrukturen sollten sprechend sein und die Bedeutung der Tabellen und ihrer Datenfelder schon anhand der Bezeichnung erahnen lassen. Zudem sollte die Dokumentation des Datenmodells eine

1 Vgl. Schmidt, in: Beck’sches Mandats-Handbuch IT-Recht, § 1 Rz. 87 ff.

1414

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 100 Q

Kommentierung der Bedeutung der einzelnen Tabellen und Datenfelder beinhalten. Ebenso sollten die zugrundeliegenden Modellierungsregeln dokumentiert und erläutert sein. Grundgedanke einer relationalen Datenmodellierung ist, dass fachlich in- 97 haltlich identische Informationen nur einmal gespeichert werden, auch wenn sie Bestandteil mehrerer Datensätze sind. Bei der Datenmodellierung findet zu diesen Zwecken zur Beseitigung von Redundanzen eine sog. Normalisierung nach einer eigenen wissenschaftlichen Theorie mit mehreren Normalformen statt1. In der Praxis ist hier ein ausgewogenes Maß zu finden, das sowohl die geforderte Fachlichkeit als auch die erforderliche Performanz der Anwendung berücksichtigt2. Dabei können durchaus Fehler gemacht werden, die wertbeeinflussend sind 98 weil sie zu einer nachhaltig ungünstigen Datenspeicherung führen. Das kann sowohl zu fachlichen Unzulänglichkeiten der Anwendung als auch zu Performanz-Problemen führen. Z.B. kann bei falscher Modellierung die Änderung einer Kundenadresse auch rückwirkend auf alte Belege „durchschlagen“. Die Wahl eines falschen objektorientierten Frameworks kann dazu führen, dass die Anwendung den geforderten Durchsatz nicht erreicht. Häufig werden Datenmodelle in abstrakten Modellen entwickelt und doku- 99 mentiert, was bei der Bewertung positiv zu beurteilen ist. Aus solchen Repräsentationen können dann automatisch sowohl Objektklassen des Quellcodes zum Speichern der Daten in der Datenbank (sog. Persistenz-Schicht) als auch Skripte zur Erstellung von Datenbankschemata für die unterschiedlichen unterstützten Datenbanksysteme (sog. DDL-Skripte) generiert werden. Das Datenmodell wird dadurch datenbankunabhängig. 9. Dokumentation Zu einer Softwareentwicklung gehört eine Dokumentation der bei der 100 Entwicklung entstandenen Arbeitsergebnisse (vgl. Kap. A Rz. 7). Arbeitsergebnisse entstehen nicht nur bei der Codierung, sondern auch in den vorgeschalteten Anforderungs- und Entwurfsphasen und in den nachgeschalteten Test- und Einführungsphasen. Das bei der Softwareentwicklung zusammen mit der Codierung aufgebaute Know-how „ist immateriell. Man sieht es nicht. Man kann es nicht berühren. Der Manager ist abhängig von der Dokumentation, um den Entwicklungsfortschritt zu überprüfen.“3.

1 Einen guten Überblick gibt Wikipedia in http://de.wikipedia.org/wiki/Normal isierung_(Datenbank). 2 Vgl. Balzert, Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2, 2005, S. 382. 3 Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 151.

Hoppen

1415

Q Rz. 101 101

Einzelprobleme

Die Dokumentation einer Software ist mindestens in folgenden Bereichen erforderlich, insbesondere für einen fremden Erwerber, der das nötige interne Know-how zu der Software erst noch aufbauen muss1: – Dokumentation zum Betrieb der Software, bestehend aus – Anwenderdokumentation und – Systemdokumentation (auch Betriebshandbuch), – Schnittstellendokumentation, – Verfahrensdokumentation und fachliche Hintergrundinformationen zur Vermarktung und organisatorischen Einführung der Software, – Dokumentationen zur Wartung und Weiterentwicklung der Software, bestehend aus – Dokumentation des Quellcodes (Inline-Dokumentation) und der – Software-Architektur, – Dokumentation des Softwareentwicklungs-Projekts (Softwareentwicklungs-Dokumentation einschließlich Anforderungs-Dokumentation und Entwurfskonzepten), – angefallene Dokumente aus Konzeption, Entwurf und Tests.

102

Eine Softwareentwicklung ohne solche Dokumentation ist in ihrer Verwendbarkeit stark eingeschränkt. Die Perpetuierungsfunktion, die der BGH einer Anwendungsdokumentation im Zusammenhang mit der Lieferung einer Anwendungs-Software zugerechnet hat, ist aus technischer Sicht bei einer Softwareentwicklung der Softwareentwicklungs-Dokumentation insgesamt zuzuschreiben2. Defizite in der Dokumentation sind wertmindernd. Bei der Software-Bewertung kann dies quantifiziert werden, indem der Aufwand für eine Nachdokumentation abgeschätzt wird.

1 Zu Arten der Dokumentation vgl. auch Sarre, in: Beck’sches Mandats-Handbuch IT-Recht, § 1, Rz. 120–124; Conrad, in: Beck’sches Mandats-Handbuch IT-Recht, § 16 Rz. 258 ff.; Stiemerling, Dokumentation von Software – typische Vertragsleistungen und zugehörige Dokumentationspflichten, ITRB 2011, 286–290; hinsichtlich Software-Entwicklungs-Dokumentation Hoppen/Hoppen, Bewertung und Bilanzierung selbst erstellter Software, CR 2009, 766. 2 „Handbücher, auch als Bedienungsanleitungen oder Dokumentationen bezeichnet, enthalten – in Wort oder graphischer Darstellung – eine Beschreibung des technischen Aufbaus der Anlage, ihrer Funktionen, gegebenenfalls der Möglichkeiten der Kombination mit anderen Geräten sowie ihre Veränderung oder Ergänzung. Sie vermitteln die Summe aller Kenntnisse, die erforderlich sind, um die Anlage bedienungsfehlerfrei und zur Verwirklichung des mit ihrer Anschaffung vertraglich vorgesehenen Zwecks nutzen zu können. Sie ergänzen und konservieren schon vorhandenes Wissen des Benutzers über den Gebrauch der Anlage und verleihen der dem Lieferer obliegenden Einweisung in die Gerätehandhabung Dauer. Das verkörperte „Nutzungswissen“ löst sich damit von der subjektiven Beziehung zum Lieferanten und wird gleichsam zum Teil der Anlage.“, BGH v. 5.7.1989 – VIII ZR 334/88, CR 1989, 189 (192).

1416

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 107 Q

Anhaltspunkte zum Inhalt von Softwaredokumenten ergeben sich aus DIN 103 662701. Danach müssen solche Dokumente – inhaltlich vollständig, angemessen, fehlerfrei und konsistent sein und – in der Qualität der Darstellung verständlich sowie übersichtlich sein. Nachfolgend werden Einzelaspekte der o.g. Dokumentationsformen be- 104 trachtet. a) Anwenderdokumentation Die Anwenderdokumentation besteht in der Regel aus einem Benutzerhandbuch. Wesentlich für die Bewertung der Software sind nicht das Layout, sondern das verfügbare Text-, Grafik- und Bildmaterial sowie ggf. vorhandene Meta-Informationen zur Verknüpfung von Programmfunktionen mit Dokumentations-Teilen. Insofern tritt die Frage, ob eine gedruckte Dokumentation oder eine Online-Dokumentation vorliegt, hier aus technischer Sicht in den Hintergrund.

105

Eine Anwenderdokumentation muss übersichtlich, verständlich, vollständig 106 und richtig sein2. Sie muss aktuell sein und die beschriebenen Programmfunktionen und Abläufe müssen den tatsächlichen Programmgegebenheiten der zu beurteilenden Software-Version entsprechen. Ein Arbeitskreis des EDV-Gerichtstags hat 1998 die rechtlichen und technischen Anforderungen, die für Anwenderhandbücher gelten, als Empfehlung in einer Prüfliste für die Gestaltung von Anwenderdokumentationen zusammengestellt3. b) Systemdokumentation, Betriebshandbuch Themen, die nicht die Benutzung der Software im Tagesbetrieb betreffen, 107 gehören nur dann in die Anwenderdokumentation, wenn die Software in der Regel vom Anwender selber administriert wird. Ansonsten sind sie in eine gesonderte technische Dokumentation auszugliedern (Systemdokumentation, früher auch DV-Handbuch genannt). Die Systemdokumentation richtet sich an die mit den technischen Hintergründen vertraute Fachperson. Sie enthält Informationen, die über die reine Benutzung hinausgehen, insbesondere die System- und Umgebungsanforderungen, die Installation, ein Dateiverzeichnis, das Zusammenwirken mit anderen Hard- und Softwarekomponenten, Systemerweiterungen, die Rechte- und Benutzerverwaltung, Angaben zum Vorgehen bei der Datensicherung, Test-Routinen

1 DIN 66270:1998-01, Informationstechnik – Bewerten von Softwaredokumenten – Qualitätsmerkmale, Berlin, 1998. 2 S. im Detail Brandt, Bewertungskriterien für Anwenderhandbücher, CR 1989, 571 ff. und Streitz, Anwenderdokumentation, NJW-CoR 1/97, 31 ff. 3 EDV-Gerichtstag 1998, Anwenderhandbücher auf dem Prüfstand, NJW-CoR 1999, 76 ff.

Hoppen

1417

Q Rz. 108

Einzelprobleme

(Smoke Tests), Schnittstellen- und Datenbank-Beschreibungen, Update-Verfahren und Betriebs-Probleme1. 108

Bei größeren Softwaresystemen werden zusätzlich auch die technischen Betriebsabläufe in der konkreten Installation in Form eines Betriebshandbuches beschrieben. c) Verfahrensdokumentation

109

In einer Verfahrensdokumentation werden die einzelnen Geschäftsprozesse und die hinter der Software stehenden Konzepte fachlich funktional beschrieben. Solche Angaben sind für die mittel- und langfristige Wartbarkeit einer Software erforderlich. Entsprechende Darstellungen können auch Bestandteil der Benutzerdokumentation sein und dort die Verwendung der einzelnen Bedienfunktionen im Anwendungskontext beschreiben.

110

Solche Informationen sind auch als Hintergrundinformation für die Vermarktung und Einführung der Software zu sehen und können durch Arbeitsunterlagen wie vorbereitete Checklisten und Best-Practice-Implementationsvorgaben ergänzt werden.

111

Verfahrensdokumentationen werden unter Ordnungsmäßigkeits-Aspekten auch von den GoBS gefordert. d) Inline-Dokumentation

112

Die Kommentierung in Quellprogrammen (Inline-Dokumentation) dient der Zuordnung des Programmtextes zu fachlichen Funktionen, dem Verständnis des Programmtextes, der Nutzung von Programmbausteinen sowie der Orientierung innerhalb von und zwischen einzelnen Quellcodepassagen. Ist ein Quellcode geschuldet, gehört auch eine entsprechende Beschreibung bzw. Kommentierung dazu2. In der Rechtsprechung ist das allgemein anerkannt, wird aber dennoch von Softwareentwicklern vielfach ignoriert bzw. auf nicht mehr eintretende spätere Überarbeitungsphasen verschoben.

113

Zu den einzelnen Inhalten einer Inline-Dokumentation vgl. Rz. 79. e) Softwarearchitektur, übergreifende Darstellungen

114

Bei mittleren und größeren Softwareprogrammen ist zusätzlich zur Dokumentation des Quellcodes eine übergeordnete Dokumentation erforderlich, die die Beziehungen der einzelnen Programmteile untereinander aufzeigt. Bei objektorientierten Entwicklungen erfolgt dies fast immer basierend auf einer grafischen Darstellung, Stichwort ist hier die Unified Modeling

1 Vgl. Streitz, Systemdokumentation, NJW-CoR 1997, 95 ff. 2 Conrad, in: Beck’sches Mandats-Handbuch IT-Recht, § 16 Rz. 271.

1418

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 116 Q

Language (UML) in ihren verschiedenen Ausprägungen1. Eine gute verbale Beschreibung der Architektur des Quellcodes ist jedoch in jedem Fall hilfreich und insofern auch wertbestimmend. f) Softwareentwicklungs-Dokumentation Ziel einer Softwareentwicklungs-Dokumentation ist es, die bei der Soft- 115 wareentwicklung – insbesondere der Programmierung und ihrer vorhergehenden Konzeption – anfallenden Informationen zum besseren Verständnis des Quellcodes der Anwendung einer weiteren, späteren Verwendung, die durchaus zeitlich, örtlich und personell in anderem Kontext erfolgen kann, nutzbar zu machen. Eine gute Programmentwicklungsdokumentation soll „bei der Zusammenarbeit verschiedener Aufgabenträger an einer Programmentwicklung die sachlichen Voraussetzungen festlegen, die Weiter- und Neuentwicklung eines Programms ermöglichen und erleichtern und die Programmentwicklung einer Überprüfung zugänglich machen“2. Dokumente mit ergänzenden Informationen aus dem Softwareentwick- 116 lungs-Prozess, die solche Zwecke verfolgen sind z.B. – Anforderungsdokumente zur Beschreibung der Fachaufgaben (Lastenheft, Anforderungsdokumentation), – fachliche Konzepte (Fachkonzept), – DV-technische Feinkonzepte als Beschreibung der implementierten fachlichen Grundkonzepte (Pflichtenheft, Systemkonzept, DV-Feinkonzept, DV-Feinspezifikation), – abstrakte und erläuternde Darstellungen der Software-Objekte, z.B. Klassendiagramme, Aktivitätsdiagramme, Sequenzdiagramme (UML), zum besseren Verständnis der internen Abläufe und Abhängigkeiten im Quellcode (Programmorganisation), – Kommunikationsdiagramme, – Schnittstellenbeschreibungen, – Datenbankmodelle oder anders geartete übersichtliche Darstellungen der zugrundeliegenden und entwickelten Datenstrukturen (Datenorganisation), – eine Dokumentation der Entwicklungsumgebung, – eine Darstellung des Vorgehensmodells bei der Entwicklung, – Style Guides/Codierungs-Richtlinien oder sonstige Richtlinien zur Programmentwicklung sowie – eine Beschreibung des Prüfverfahrens,

1 S. weiterführend Balzert, Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2, 2005. 2 Vgl. hierzu DIN 66231, die zwar in den Details überaltert ist und mittlerweile zurückgerufen wurde, in diesem Grundansatz aber unverändert gültig ist.

Hoppen

1419

Q Rz. 117 – – – –

Einzelprobleme

die konkreten Testpläne mit den einzelnen Testfällen und die Dokumentation der Programmtests mit den Feststellungen, Abnahmeprotokolle sowie Aufstellungen der beteiligten Mitarbeiter mit Aufgaben und angefallenem Entwicklungsaufwand.

117

Defizite in der Softwareentwicklungsdokumentation führen bei Wartung und Weiterentwicklung zu erhöhten Aufwänden und sind häufig in Umgebungen mit kleinen Teams vorzufinden. Dort findet Softwareentwicklung auch heute vielfach stark auf Zuruf und wenig formalisiert statt, mit hohem Individualitätsgrad bei den Entwicklern. Man verlässt sich dabei auf das im Laufe der Jahre gebildete Know-how und die in solchen Fällen fast immer als hoch eingeschätzte Qualifikation der Entwickler. Solche Defizite bedeuten für einen Erwerber deutlich erhöhte Aufwände in der Wartung und Weiterentwicklung der Software und erhöhen das Risiko bei der Vermarktung der Software. Bei einer Übernahme der Software und ihrer Quellcodes durch einen fremden Dritten wird dieser zunächst ein tieferes Verständnis entwickeln müssen, um das Know-how, das in den Köpfen der Entwickler steckt, wieder aufzubauen. Bei der Weiterentwicklung und Wartung sind zunächst entsprechende Informationen zu gewinnen und aufzubereiten. Für konzeptionelle Planungen fehlt zunächst die Basis. Hier bestehen für einen potentiellen Erwerber, aber auch für den Auftraggeber selbst, mittelfristige Risiken bei der Vermarktung. Ein Fehlen der o.g. Dokumente wird sich dabei als hinderlich bzw. aufwandserhöhend herausstellen.

118

Gängige Verfahren zur Aufwandsschätzung von Softwareentwicklungsprojekten beziehen die Softwareentwicklungs-Dokumentation in den ermittelten Aufwand ein. Defizite in der Softwareentwicklungs-Dokumentation müssen insofern bei einer Wertermittlung berücksichtigt werden. Das kann objektiviert werden, indem die Arbeitsergebnisse, die bei einer Veräußerung von der Auftraggeberin übertragen werden können, analysiert werden und die erforderlichen Nacharbeiten zur Erstellung einer ordnungsgemäßen Dokumentation aufwandsmäßig ermittelt werden. Aus subjektiver Erwerbersicht können je nach Szenario auch andere Abschläge – höher oder niedriger – angemessen sein. 10. Softwareentwicklungsprozess

119

Die Qualität eines Software-Produktes ist entscheidend von der Qualität des Prozesses der Softwareentwicklung (Software-Management) abhängig. Hier maßgeblich sind die allgemeinen Aktivitäten des Projektmanagements (vgl. Kap. H), aber vor allem auch eine methodische, systematische und geplante Vorgehensweise unter Berücksichtigung der folgenden Aspekte1:

1 Vgl. Schomisch, Die Sicherung der Softwarequalität, NJW-CoR 1997, 154 ff.

1420

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 120 Q

– Grundlage der Entwicklung ist eine mit allen beteiligten Stake Holdern abgestimmte Anforderungsanalyse und Anforderungsdokumentation, die auch konstruktive Maßnahmen zur Erreichung von Qualitätsforderungen definiert. – Konsequenter Einsatz einer zeitgemäßen Softwareentwicklungsumgebung und deren Methoden und Werkzeuge – Gliederung des Entwicklungsprozesses in überschaubare und hinsichtlich ihres Erfolges bewertbare Einheiten (Phasen) – Einbeziehung des Auftraggebers bei der Beurteilung der Zwischenergebnisse – Formales Änderungs-Management, Dokumentation von Änderungsanforderungen (Change Requests, CR) und Aufnahme in die laufende Entwicklung nur nach abgestimmter Modifikation der Projektplanung – Iterativer Entwurfsprozess mit schrittweiser Verfeinerung vom Was zum Wie – Codierung auf möglichst abstraktem Niveau (Einsatz höherer Programmiersprachen, Objektmodelle, Frameworks, Nutzung und Schaffung wiederverwendbaren Codes) – Reviews am Ende einzelner Entwicklungsabschnitte – Systematische Testaktivitäten mit Testplanung, Testfällen, Modul- und Integrationstests, möglichst unter Verwendung automatisierter Testverfahren, Regressionstests bei neuen Versionen – Dokumentation von Fehlern, Nachvollziehbarkeit der Beseitigung bis in den Quellcode – Systematisches Release-Management mit Dokumentation der Änderungen und Erweiterungen im Produktlebenszyklus – In den Softwareentwicklungsprozess integrierte und kontinuierlich aktualisierte Dokumentation – Konfigurationsmanagement zur eindeutigen Identifikation aller entwickelten Software-Objekte und deren Änderungen in den einzelnen Entwicklungsstufen, Sicherung der Integrität und Identifikation konkreter zu bestimmten Zeitpunkten des Softwareentwicklungsprozesses gesicherter und freigegebener Softwarekonfigurationen (Baselines). – Ableitung von Kenngrößen aus den laufenden Prozessen zur Beurteilung dieser Prozesse Auch die Wartbarkeit der entwickelten Software (vgl. Rz. 65 ff.) wird durch 120 die vorgenannten Merkmale eines methodischen Vorgehens maßgeblich bestimmt. Generell kann davon ausgegangen werden, dass rund 30 % der Gesamtkosten im Lebenszyklus einer Software auf die Entwicklung und 70 % auf die Programmpflege und Weiterentwicklung entfallen1. Bei der Wert1 Balzert verteilt 1/3 zu 2/3, s. Helmut Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 195, Sneed nennt 25 % zu 75 %, s. Harry M. Sneed, Software-Projektkalkulation, 2005, S. 117.

Hoppen

1421

Q Rz. 121

Einzelprobleme

bestimmung der Software muss deswegen geprüft werden, ob aufgrund des Vorgehens im Softwareentwicklungsprozess Abstriche bei der Wartbarkeit oder der Weiterentwickelbarkeit vorgenommen werden müssen. 121

Wie bei der Softwareentwicklung vorgegangen wurde, lässt sich bei der Bewertung am besten anhand der Softwareentwicklungs-Dokumentation (vgl. Rz. 115 f.) und der Unterlagen aus dem Projektmanagement (vgl. Kap. H) analysieren.

122

Das Unternehmen kann dabei sein eigenes Prozessmodell aufgebaut haben oder sich an etablierten Standards orientieren. Das Modell kann dabei eine strikt sequentielle Anordnung der einzelnen Projektphasen vorsehen – sog. Wasserfall-Modell oder die einzelnen Phasen zeitlich überlappend vorsehen. Die Software kann monolithisch oder inkrementell in einzelnen Ausbaustufen oder Komponenten entwickelt werden. Es kann auch evolutionär, agil oder anhand von Prototypen vorgegangen werden, um endgültige Festlegungen in der Spezifikation möglichst lange hinauszögern zu können. Alle Modelle haben spezifische Vor- und Nachteile1. Wichtig aus Bewertungssicht ist vor allem, dass ein Prozessmodell existiert und praktiziert wird, in dem – – – –

die Entwicklungsphasen mit ihren jeweiligen Aktivitäten, die dabei zu erstellenden Teilprodukte mit ihren Fertigstellungskriterien, die Verantwortlichkeiten, Kompetenzen und Qualifikationen und anzuwendende Standards, Richtlinien, Methoden und Werkzeuge

definiert werden. 123

Nachfolgend werden einige Standard-Prozessmodelle kurz skizziert. a) Wasserfall-Modell

124

Hier werden die Phasen Anforderungsdefinition, Analyse, Entwurf, Codierung, Test und Inbetriebnahme nacheinander durchlaufen. b) V-Modell und V-Modell XT

125

Das sog. V-Modell sieht vor, dass mit jeder Verfeinerung der Arbeitsergebnisse frühestmöglich Testkriterien für den späteren Abschluss des Projekts festgelegt werden, und zwar auf der jeweiligen Abstraktionsebene des einzelnen Arbeitsergebnisses. Bei der Anforderungsdefinition wird festgelegt, wie am Ende des Projekts die Abnahmetests auszusehen haben. Im Grobentwurf wird festgelegt, wie der Systemtest ablaufen soll. In der Feinspezifikation werden bereits Testfälle für die Integrationstests definiert. In der Codierung einzelner Module werden Modultests vorgenommen. Diese Vorgehensweise zwingt zu frühzeitiger Befassung mit Details, reduziert In1 Eine umfassende Diskussion findet sich in Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 515 ff.

1422

Hoppen

Rz. 130 Q

Bewertung von Software, Due Diligence, Compliance

terpretationsspielräume und fördert dadurch die Qualität von Entwurfsdokumenten und die Aufmerksamkeit des Auftraggebers in frühen Projektphasen. Der konzeptionelle Ansatz einer Verzahnung von Entwurf und Test-Spezifi- 126 kation wird im Rahmen des eXtreme Programming (XP, s. Rz. 131 ff.) mit dem sog. Test Driven Development (testgetriebenes Programmieren) auf die Spitze getrieben. Hier wird in der Codierung zunächst der Code für den automatisierten Test einzelner Programmeinheiten geschrieben, bevor die Programmeinheit selber programmiert wird1. Unter Bewertungsaspekten sind jegliche Bemühungen, in denen Testverfah- 127 ren als Qualitätssicherungsmaßnahmen frühzeitig im Softwareentwicklungsprozess definiert werden, qualitätssteigernd und damit positiv zu sehen. In Deutschland wurde basierend auf dem V-Modell ein umfassendes Vor- 128 gehensmodell für Softwareentwicklungen der Bundeswehr und der Bundesbehörden entwickelt, zunächst 1997 als V-Modell 97 und ab 2005 ab V-Modell XT. Es handelt sich um ein umfassendes und komplexes Konzept zur Abwicklung großer Softwareentwicklungsprojekte. Es sind Software-Werkzeuge verfügbar (Projektassistent), mittels derer das Modell projektspezifisch angepasst werden kann und komplette Projektunterlagen generiert werden können2. c) Rational Unified Process (RUP) Der Rational Unified Process wurde von der Firma Rational (heute IBM) 129 entwickelt und basiert eng auf den Unified Modeling Language (UML) zur Entwicklung objektorientierter Softwareanwendungen. Das RUP-Prozessmodell wird durch Software-Werkzeuge unterstützt, die in allen Projektphasen integriert eingesetzt werden können. Bereits in früheren Planungsstadien können Prototypen realisiert werden, die in Iterationsschritten funktional ausgebaut werden. Die einzelnen in den Iterationen durchlaufenen Projektphasen heißen Konzeption (inception), Ausarbeitung (elaboration), Konstruktion (construction) und Übergabe (transition). Die entstehenden Arbeitsergebnisse – Anwendungsfälle (Use-case-Modelle) 130 und Objektmodelle in UML-Notation – können unmittelbar zur Definition der Software-Architektur und Codierung verwendet werden. Dadurch wird die Effizienz erhöht. Auch hier werden Interpretationsspielräume und damit Projektrisiken minimiert.

1 Vgl. Balzert, Lehrbuch Grundlagen der Informatik, 2005, S. 533 ff. 2 S. http://www.v-modell-xt.de.

Hoppen

1423

Q Rz. 131

Einzelprobleme

d) Extreme Programming, Agile Programmierung, Scrum 131

Heute werden verstärkt Methoden des Extreme Programming (XP) oder der agilen Programmierung genutzt1. Es handelt sich um eine Gegenbewegung zu den komplexen Modellen mit hohem Dokumentationsumfang. Zielsetzung ist die Beschleunigung und Vereinfachung der Softwareentwicklung durch Reduktion von frühzeitigen Festlegungen und Dokumenten auf ein Minimum2.

132

Die Kernideen eines agilen Entwicklungsprozesses wurden 2001 als sog. agiles Manifest3 formuliert und basieren auf im Jahr 2000 veröffentlichten Thesen zur Reduktion des Aufwands bei der Softwareentwicklung4: – Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen – Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation – Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen – Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung

133

Seitdem werden Dokumentationsdefizite gerne unter Bezugnahme auf diese Ideen verharmlost. Hierauf ist in der Bewertungspraxis zu achten. Es ist richtig – und wurde in der Softwaretechnik bereits seit jeher als partizipative Softwareentwicklung propagiert –, dass eine gute Zusammenarbeit zwischen Auftraggeber und Auftragnehmer im Erfolgsfall mit großer Wahrscheinlichkeit zu besseren Ergebnissen führt. Aus diesem Grunde werden agile Methoden in der Industrie positiv gesehen und praktisch angewandt5. Auch ein agiles Vorgehen bedingt jedoch ein systematisches Arbeiten mit beurteilbaren Arbeitsergebnissen.

134

Ein solches iteratives inkrementelles Prozessmodell ist beispielsweise die Scrum-Methode6. Dabei erfolgt die Feinkonzeption in einzelnen Schüben (sog. sprints) unmittelbar durch die Programmierer. Charakteristisch für ein solches Vorgehen ist das Fehlen einer systematischen und übergreifenden Dokumentation. Typisches Entwicklungsdokument beim Arbeiten nach der Scrum-Methode – und damit im Verfahren einer Software-Bewertung be-

1 Vgl. Schneider, „Neue“ IT-Projektmethoden und „altes“ Vertragsrecht, ITRB 2010, 18–23; Koch, Agile Softwareentwicklung – Dokumentation, Qualitätssicherung und Kundenmitwirkung, ITRB 2010, 114–119; Frank, Bewegliche Vertragsgestaltung für agiles Programmieren, CR 2011, 138. 2 http://www.agilealliance.org. 3 http://agilemanifesto.org. 4 Beck, eXtreme Programming Explained, Reading, 2000. 5 Vgl. Jähnichen, Formen agilen Programmierens, DGRI Jahrbuch 2011, 2012. 6 http://www.scrumalliance.org, http://www.scrum.org, vgl. auch Conrad/Schneider, in: Beck’sches Mandats-Handbuch IT-Recht, § 8 Rz. 135 ff.

1424

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 138 Q

urteilbar – ist das Product Backlog, das sowohl aus der laufenden Entwicklung als auch in historischen Fassungen vorliegen sollte1. e) CMMI CMMI ist ein Rahmenmodell für die Softwareentwicklung und wurde im 135 Software Engineering Institute (SEI) der Carnegie Mellon University (CMU) entwickelt2. Die Entwicklung geht auf eine Initiative des US-Verteidigungsministeriums aus dem Jahre 1986 zurück. Das Modell gibt nicht primär konkrete Prozess-Schritte vor, sondern Ziele 136 für die Prozessdurchführung und Beurteilungskriterien für die Kategorisierung von IT-Organisationen. CMMI steht dabei für Capability Maturity Model Integration. Eine Organisation kann nach dem Modell einem von fünf Reifegraden zugeordnet werden, die aufeinander aufbauen und grob wie folgt skizziert werden können3: – CMMI 1, Reifegrad „initial“: keine Prozessorganisation, „Ad hoc“-Vorgehensweisen – CMMI 2, Reifegrad „managed“: Anforderungen werden dokumentiert und nachverfolgt, es existieren Projektplanung und Projektcontrolling, Qualitätssicherungs-Prozesse und ein Konfigurationsmanagement – CMMI 3, Reifegrad „defined“: Organisationsweite Standardisierung und Durchsetzung der Prozess-Schritte aus CMMI 2, Werkzeugunterstützung, systematisierte Entscheidungsfindung, Risikomanagement – CMMI 4, Reifegrad „quantitatively managed“: Quantitative Erhebung von Leistungsindikatoren und Kennziffern, Messung der Performanz, quantitatives Projektmanagement – CMMI 5, Reifegrad „optimizing“: Kontinuierlicher Verbesserungsprozess Unter Bewertungsaspekten ist wesentlich, dass die Softwareentwicklung 137 unter einem CMMI Reifegrad von 2 erfolgte. Höhere Reifegrade betreffen primär die Softwareentwicklungs-Organisation, nicht aber das bei der Bewertung (isoliert) zu betrachtende Softwareprodukt als solches und sind daher für die Software-Bewertung von nachrangiger Bedeutung. f) SPICE/ISO 15504 SPICE (Software Process Improvement and Capability Determination) ist 138 ebenso wie CMMI ein Rahmenmodell und kann zur Bewertung einer Softwareentwicklung herangezogen werden. Es wurde seit 2004 in der Norm 1 Vgl. weiterführend Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 651 ff. und hinsichtlich Scrum S. 670 ff. 2 S. http://www.sei.cmu.edu/cmmi/solutions/translations/german.cfm. 3 Alternativ ist auch eine Klassifizierung bezogen auf einzelne Prozessschritte möglich, vgl. weiterführend Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 571 ff.

Hoppen

1425

Q Rz. 139

Einzelprobleme

ISO/IEC 15504 standardisiert1 und in mehreren Teilen sukzessive ausgebaut, z.B. in 2008 (Part 7) zur Bewertung der Prozessreife einer Organisation und zuletzt in Jahr 2011 (Part 10) um Kriterien bei besonderen Sicherheitsanforderungen (safety extension). Die einzelnen Prozesse einer Softwareentwicklungs-Organisation können sog. Assessments unterzogen werden, zu denen in der Norm Mindeststandards vorgegeben werden. Teil 5 des Standards bezieht sich auf das Prozess-Referenzmodell der Norm ISO 12207 Life Cycle Management – Software Life Cycle Processes. Dort sind in der Gruppe ENG (Engineering) die typischen, bei einem Softwareentwicklungsprozess zu durchlaufenden Prozesse (von Anforderungsanalyse bis zu Tests, Installation und Wartung) enthalten. Aus den Ergebnissen der Assessments werden Maßnahmen zur Prozessverbesserung und die Bestimmung eines Reifegrades bezüglich des jeweiligen Prozesses abgeleitet. Dabei können sechs Reifegrade (process attribute, PA) erreicht werden: – PA 0, Reifegrad „incomplete“: Der Prozess ist nicht vollständig definiert. – PA 1, Reifegrad „performed“: Der Prozess ist definiert und eingeführt und erfüllt seinen Zweck. – PA 2, Reifegrad „managed“: Der Prozess wird geplant und gesteuert. Arbeitsergebnisse sind definiert und können objektiv beurteilt werden. – PA 3, Reifegrad „established“: Der Prozess basiert auf einem StandardProzess. – PA 4, Reifegrad „predictable“: Der Prozess wird hinsichtlich seiner Performanz mittels Kenngrößen überwacht und operiert in einer vorgegebenen Bandbreite. – PA 5, Reifegrad „optimizing“: Der Prozess wird hinsichtlich übergeordneter Ziele kontinuierlich verbessert. 139

Auch hier erscheint für die Bewertung wesentlich, dass die Softwareentwicklungsprozesse einen Reifegrad von 2 haben. Höhere Bewertungen betreffen Vorteile für die Organisation, weniger das einzelne Software-Produkt, und sind daher für die Software-Bewertung von nachrangiger Bedeutung. g) PMBOK

140

PMBOK (Project Management Body of Knowledge) ist ein weitverbreitetes und in SAP-Projekten genutztes Rahmenwerk für ein ganzheitliches Projektmanagement unter Einhaltung von Best-Practice-Standards2. Es wurde seit 1987 von dem US-amerikanischen Projektmanagement-Verband Project Management Institute (PMI) entwickelt und liegt seit 2008 in der vierten

1 ISO/IEC 15504, Information technology – Process Assessment. 2 S. http://www.pmi.org/PMBOK-Guide-and-Standards.aspx.

1426

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 141 Q

Auflage vor1. Adressiert werden breit gefächert verschiedene ManagementGebiete: – – – – – – – – –

Integrations-Management Inhalts- und Umfangs-Management (Scope) Termin-Management Kosten-Management (z.B. Earned Value Method) Qualitäts-Management Personal-Management Kommunikations-Management Risiko-Management Beschaffungs-Management

h) ITIL ITIL ist kein konkretes Prozessmodell und auch kein Rahmenmodell, son- 141 dern eine umfassende Best-Practice-Sammlung für alle IT-Prozesse, darunter auch Teilprozesse der Softwareentwicklung. Die IT Infrastructure Library (ITIL) wurde bereits Ende der 80er-Jahre von der britischen Regierung (OGC, Office of Government Commerce) in Auftrag gegeben, um ein strukturiertes Prozessrahmenwerk für IT-Organisationen und deren Kunden zu schaffen. ITIL befasst sich mit dem Management von IT-Services primär aus der Sicht des IT-Dienstleisters. Im Vordergrund stand die Frage: Welche Prozesse sollte eine IT-Organisation klar regeln, damit sie erfolgreich arbeitet? Dabei wurde das Rad nicht neu erfunden, sondern auf in der Praxis bereits bewährte Organisationsstrukturen zurückgegriffen. ITIL ist keine Projektmethodik. ITIL versteht sich vielmehr als sog. Best-Practice-Ansatz und dokumentiert Prozesse und Terminologien für das Management und den Betrieb von IT-Dienstleistungen, die sich in der Praxis bewährt haben2. In 2005 griffen 50 % aller Unternehmen in Deutschland und Österreich Ansätze aus ITIL auf, für 2007 wurde dieser Anteil auf 76 % geschätzt3. Andere Referenzmodelle zu IT-Service-Management-Prozessen, z.B. das IT Process Model (ITPM) und der IBM Tivoli Unified Process (ITUP) der Firma IBM oder das IT Service Management Reference Model der Firma HP (ITSM) richten sich an ITIL aus.

1 Seit 2010 auch in einer deutschen Ausgabe: PMI (Hrsg.), A Guide to the Project Management Body of Knowledge, 4. Ausgabe – Official German Translation (Taschenbuch) PMI, 2009. 2 Vgl. auch Hoppen/Victor, ITIL – Die IT Infrastructure Library, Möglichkeiten, Nutzen und Anwendungsfälle in IT-Verträgen, CR 2008, 199 ff. 3 Gemäß einer Studie von Dr. Materna, Juli 2007.

Hoppen

1427

Q Rz. 142

Einzelprobleme

142

Im Mai 2007 erfolgte die Publikation einer umfassend überarbeiteten Version 3 von ITIL1. ITIL V3 orientiert sich am sog. Lebenszyklus von Services und beschreibt in 5 Büchern, welche Prozesse zu welchem Zeitpunkt – von der Entwicklung eines neuen Services bis hin zur Stilllegung eines Services – für eine effiziente IT-Organisation notwendig sind. Diese fünf Kernpublikationen (sog. ITIL Core) sind: Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement. Mittlerweile steht nicht mehr nur die Beschreibung von Best-Practice-Ansätzen einzelner Prozesse im Vordergrund, sondern zusätzlich die Implementierung einer übergeordneten Service-Strategie auf der Basis eines Service Lifecycle. Diese soll einen kontinuierlichen Verbesserungsprozess und eine möglichst optimale Ausrichtung der IT-Organisation an den Unternehmensanforderungen des Kunden sicherstellen, wie es auch in der Norm ISO/IEC 20000 gefordert wird.

143

Das ITIL-Framework ist generisch, d.h. es legt fest, was für eine effiziente IT-Organisation benötigt wird – die konkrete Ausgestaltung obliegt aber dem jeweiligen Unternehmen. Für die Entwicklung von Software sind vor allem die Bereiche Service Design und Continual Service Improvement relevant. i) ISO/IEC 20000

144

ISO/IEC 20000 ist eine internationale Norm für IT-Service-Management. Sie geht zurück auf den British Standard BS 15000, der im Jahre 2000 unter maßgeblicher Mitwirkung der Autoren von ITIL veröffentlicht wurde und wurde im Dezember 2005 gültig2.

145

Mit der Norm soll die Zertifizierbarkeit einer IT-Organisation anhand konkreter Kriterien ermöglicht werden. Sie geht über die eher unverbindlichen Empfehlungen und Vorschlägen von ITIL hinaus und definiert Mindestanforderungen für die Implementierung standardisierter Prozesse der Service-Managements in IT-Organisationen. Dabei werden im Wesentlichen die generischen Prozessbeschreibungen des ITIL Prozessmodells aufgegriffen, aber etwas anders zusammengefasst3. Teil 1 der Norm (Specification) definiert sehr abstrakt standardisierte Definitionen und Mindestanforderungen an die Prozesse. Teil 2 (Code of practice) liefert Umsetzungsempfehlungen.

1 The Official Introduction to Service Lifecycle, Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement, OGC, The Stationery Office Books, 2007. 2 ISO/IEC 20000-1:2005-12 Information technology – Service management Part 1: Specification und Part 2: Code of practice, 2005. 3 Vgl. http://20000.fwtk.org/20000-itil.htm.

1428

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 149 Q

Viele Beschaffungsvorhaben der öffentlichen Hand und des privaten Sektors 146 in entwickelten Volkswirtschaften verlangen eine ISO 20000-Zertifizierung.“1 j) DIN EN ISO 9000-2005/9001 Ein Softwareentwicklungsprozess kann sich auch an der Norm DIN EN ISO 9000 orientieren. Die Norm enthielt in Ihrer bis 2000 gültigen Fassung als Teil 32 einen an einem typischen Softwareentwicklungsmodell orientierten Leitfaden auf der Basis der in der DIN EN ISO 9001 beschriebenen allgemeinen Anforderungen an ein prozessorientiertes Qualitäts-Managementsystem. Mit solchen Maßnahmen kann ein Softwareentwickler seine Qualitätsfähigkeit dokumentieren, indem er aufzeigt, dass er Qualitätsanforderungen festgelegt hat und diese erfüllt3.

147

11. Qualitätssicherungs-Maßnahmen im Projekt Wertbestimmend ist schließlich, welche Maßnahmen im Entwicklungsprojekt systematisch vorgesehen sind, um das Erreichen vorgegebener Qualitätsziele sicherzustellen (Qualitäts-Management). Eine Qualitätssicherung gehört zu den Standardverpflichtungen, die ein Softwareanbieter zu erfüllen hat (vgl. hierzu Teil F Rz. 246 und Rz. 248). Es kann sich dabei um

148

– konstruktive Maßnahmen handeln, die technisch über Methoden und Werkzeuge oder organisatorisch über Richtlinien, Standards und Checklisten dafür sorgen, dass die Software bestimmte Qualitätseigenschaften erfüllt, oder um – analytische Maßnahmen, mit denen die Arbeitsergebnisse auf die Einhaltung von Vorgaben hin überprüft werden, i.W. durch die Ausführung von Tests, Code-Inspektionen, Walkthroughs, Reviews, Audits o.A. Solche Maßnahmen müssen geplant, durchgeführt, gesteuert und über- 149 wacht werden4. Die gewonnenen Erkenntnisse müssen in die Steuerung des Entwicklungsprozesses einfließen.

1 Vgl. Gartner Research, ISO/IEC 20000 Has an Important Role in Sourcing Management (ID G00136652), 2006. 2 DIN EN ISO 9000:2005.12 Qualitätsmanagementsysteme – Grundlagen und Begriffe (ISO 9000:2005). 3 DIN ISO 9001 Qualitätsmanagementsysteme – Modell zur Qualitätssicherung/ QM-Darlegung in Design, Entwicklung, Produktion, Montage und Wartung. 4 Umfassende Darstellung hierzu s. Schmidt, in: Beck’sches Mandats-Handbuch IT-Recht, § 1 Rz. 153–442.

Hoppen

1429

Q Rz. 150

Einzelprobleme

a) QS-Prinzipien 150

Prinzipien einer Software-Qualitätssicherung und damit Beurteilungsaspekte bei einer Software-Bewertung sind1: – Produkt- oder prozessbezogene Festlegung der Qualitätsziele: Qualitätsziele ergeben sich daraus, dass Fehler, also Abweichungen der Ist-Beschaffenheit von einer in Form konkreter Ausprägungen der generellen Qualitätsmerkmale Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit und Portabilität (s. Rz. 49 ff.) beschriebenen Soll-Beschaffenheit, zu vermeiden sind. Es gibt Qualitätsmodelle, in denen Softwarequalität durch konkrete, hierarchisch strukturierte Qualitätsmerkmale definiert wird, z.B. Teil 1 der Norm ISO/IEC 91262. – Solche Qualitätsmerkmale können im spezifischen Softwareentwicklungsprojekt anhand einer Risikoanalyse priorisiert werden, um QS-Maßnahmen wirtschaftlich zu steuern. Hier werden Maßnahmen vor ihrer Umsetzung hinsichtlich ihres Risikos für das Business beurteilt, möglichst getrennt nach möglichem Schaden (Impact) und der erwarteten Risiko-Wahrscheinlichkeit. Aus Management-Sicht kann ein solcher Risikoabwägungsprozess sichergestellt werden, indem die vorgenommene Einstufung dokumentiert und den relevanten Beteiligten kenntlich gemacht wird. – Definition von quantitativen Qualitäts-Indikatoren (Metriken) und zu erreichenden Qualitäts-Stufen: Qualität kann nur anhand definierter Maße gemessen werden. Teil 2 und Teil 3 der Norm ISO/IEC 9126 geben z.B. externe Maße (z.B. Performanz-Größen, Fehlerraten, Fehlerbeseitigungsquoten, Testabdeckung) und interne Maße (z.B. Kommentierungsgrade, Ergebnisse aus Code-Analysen, Speicherbedarf, Interoperabilität, Konformitätsgrade) vor. Eine sehr umfangreiche Darstellung möglicher Metriken zur Quantifizierung der Qualitätseigenschaften von Software wurde bereits 1988 mit dem IEEE Standard 982.13 und dem Benutzerleitfaden IEEE 982.24 vorgelegt. Im zu bewertenden Softwareentwicklungsprojekt können solche Maße erhoben und gegen Zielwertebereiche abgeprüft werden. – Vorrang von konstruktiven QS-Maßnahmen vor analytischen QS-Maßnahmen, nach dem Motto „Vorbeugen ist besser als heilen“. Teilweise sind konstruktive Maßnahmen erforderlich um quantitative Indikatoren analytischer Maßnahmen zu gewinnen.

1 S. Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 481. 2 ISO/IEC 9126-1, Software Engineering – Product Quality, Part 1: Quality Model. 3 IEEE Standard 982.1 Dictionary of Measure to Produce Software, 1988. 4 IEEE Standard 982.2 Guide for the Use of IEEE Standard Dictionary of Measure to Produce Software, 1988.

1430

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 152 Q

– Möglichst frühzeitige Fehlerentdeckung und -Behebung: Obwohl die meisten Fehler in Entwurf, Feinkonzeption und Codierung verursacht werden, werden die meisten Fehler erst bei Modul-, Integrations- oder (noch schlimmer) Systemtests entdeckt. In diesen Stadien ist der Beeinflussungsgrad erheblich eingeschränkt, die Kosten für die Fehlerbehebung sind 10- bis 50-fach höher als in den Entwurfsstadien. Z.B. können erhebliche unnötige Aufwendungen durch nachträglich erforderliche Änderungen am Datenmodell entstehen. Es gilt, den Aufmerksamkeitspegel aller Beteiligten (Stakeholder) in den frühen Projektphasen durch eine entwicklungsbegleitende, integrierte Qualitätssicherung hoch zu halten. Häufig ist jedoch genau das Gegenteil der Fall: Nach der Teilnahme an Machbarkeitsstudien und Erhebungen zum Anforderungsumfang wird die Fachabteilung erst nach Monaten oder gar Jahren mit dem fertigen Produkt konfrontiert, nur um dann festzustellen, dass am tatsächlichen Bedarf vorbeientwickelt wurde. Entgegengewirkt werden kann diesem Problem durch QS-Prüfungen an allen Arbeitsergebnissen und Rückkopplung mit dem Auftraggeber oder auch durch die frühzeitige entwicklungsbegleitende Definition von Testfällen in möglichst vielen Stufen des Entwurfsprozesses (s. V-Modell in Rz. 125 ff.). – Unabhängige analytische Qualitätssicherung: Analytische Maßnahmen können nicht von den Personen durchgeführt werden, die an der Entwicklung des jeweiligen Arbeitsergebnisses beteiligt waren. Die Rollen sind strikt zu trennen. Idealerweise ist der Auftraggeber operativ oder zumindest informativ zu beteiligen. Ein Entwickler kann nicht seine eigenen Feinkonzepte oder Programme testen. Eine Person, die an der Anforderungsanalyse oder Fachkonzeption gearbeitet hat, kann diese nicht prüfen. Sie kann aber sehr wohl effizient die in den nachgeordneten Entwicklungsprozessen entstandenen Arbeitsergebnisse (Feinkonzepte, Programme) gegen die von ihr erstellten Arbeitsergebnisse testen. b) Vorgehen bei Tests Es gibt keinen verbindlich-verpflichtend gültigen Standard, der festlegt, wie 151 eine Software-Qualitätssicherung auszusehen hat oder wie konkret bei Tests und der Abnahme vorzugehen ist. Es gibt aber vielfältige technische Regelwerke, Best-Practice-Sammlungen und anerkannte Regeln der Technik (ISO/IEC 20000, DIN ISO/IEC 27001, Grundschutz-Katalog des BSI, ITIL) mit in großem Umfang deckungsgleichen Empfehlungen. Man unterscheidet zwischen

152

– Modultests zum Überprüfen einzelner Programmeinheiten, – Integrationstests zum Test des Zusammenspiels mehrerer oder aller Programmeinheiten, – Funktionstests zur Prüfung der Funktionalität der kompletten Anwendung, – Schnittstellentests, Hoppen

1431

Q Rz. 153 – – – –

Einzelprobleme

Installationstests, Massen- und Lasttests bzw. Stresstests, Leistungs- bzw. Performance-Tests und Regressionstests zur Validierung der Funktion nach der Vornahme von Änderungen etc.1.

153

Aus der Sicht des Programmierers gibt es unterschiedliche Ansätze: Strukturtestverfahren (white box), funktionale Tests (black box), Grenzwertanalysen als manuelle, halb- oder vollautomatisierte Tests bis hin zum testgetriebenen Programmieren2.

154

Eine nach branchenüblichen Kriterien aufgebaute Qualitätssicherung wird jedenfalls folgende Aspekte berücksichtigen: – Wesentliche Änderungen an IT-Systemen sind vor ihrer Durchführung ausreichend und angemessen zu testen. – Die Planung der Tests erfolgt in Form sog. Testfälle, in denen das erwartete Systemverhalten festgelegt wird, damit es mit dem tatsächlichen Systemverhalten verglichen werden kann. Die Testfälle sind eingebettet in einen Testplan und werden ggf. um vorgegebene Test-Skripte ergänzt3. – Bei der Gestaltung der Testfälle und des Testplans ist auf ausreichende Abdeckung der Funktionalitäten des zu testenden Systems zu achten. – Bei den Tests ist eine eigene Testumgebung zu verwenden, um Nebenwirkungen mit dem Produktionssystem auszuschließen. Die Testumgebung sollte so weit wie möglich der Produktions-Umgebung entsprechen. Sind Abweichungen – auch aus Kosten-/Nutzen-Aspekten – unumgänglich, sind die Auswirkungen dieser Unterschiede auf die Risiko-Situation bewusst zu machen. – Die Planung, die Ausführung und die abschließende Beurteilung von Tests sind zu dokumentieren. Sinn der Dokumentation ist die Nachvollziehbarkeit geordneter Testverfahren und damit die Durchsetzung der Einhaltung durch das Management. – Konfigurationen sind in geeigneter Weise systematisch in Form eines Konfigurations-Managements zu dokumentieren. – Planung und Ausführung der Tests sind von einer von dem Test-Team unabhängigen Instanz zu überwachen. Dies ist nur möglich bei einer systematischen Testdokumentation. – Die Freigabe eines Changes setzt den erfolgreichen Abschluss aller Tests voraus.

1 Conrad/Schneider/Witzel, in: Beck’sches Mandats-Handbuch IT-Recht, § 16 Rz. 204. 2 Zum Testen von Programmen im Detail s. Balzert, Lehrbuch Grundlagen der Informatik, 2005, S. 504 ff. 3 Conrad/Schneider/Witzel, in: Beck’sches Mandats-Handbuch IT-Recht, § 16 Rz. 216 ff.

1432

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 158 Q

– Es ist sicherzustellen, dass die spätere Umsetzung in der getesteten Weise erfolgt. Was das konkrete Vorgehen bzw. die konkrete Form durchzuführender Test- 155 und Abnahmeverfahren betrifft, sind die einschlägigen Standards sehr generisch. Die konkrete Ausgestaltung ist unternehmens- bzw. projektspezifisch auf die Gegebenheiten des Einzelfalls abzustellen. c) Fehlerdokumentation und Fehlermanagement Heute gehört es zum Standard, dass Fehlermeldungen an einer Software sys- 156 tematisch aufgezeichnet und mit Änderungen am Quelltext verknüpft werden (Bug-Tracking). Aus den Aufzeichnungen sollte hervorgehen, – wann und – zu welcher Programmeinheit eine Fehlermeldung erfolgte, – wie der Fehler klassifiziert wurde1, z.B. in den Dimensionen – Relevanz für den Einsatz der Software (prüfungsverhindernd, nutzungsverhindernd, nutzungsbehindernd mit Umgehungsmöglichkeit, kleinere Fehler ohne wesentliche Behinderung, Änderungs- oder Erweiterungswünsche für zukünftige Releases, Schönheitsfehler)2, – Kritikalität (critical, major, minor), – Schadenrisiko (hoch, mittel, niedrig), oder – Ursache (fehlende Anforderung, fehlerhafte Implementierung)3, und – in welchem Status sich die Meldung befindet, insbesondere ob und wann der Fehler behoben wurde. Das Fehlermanagement muss in den Softwareentwicklungsprozess als Informationsquelle für das Qualitäts-Management integriert sein.

157

So können bei der Softwarebewertung der Reifegrad der Software, Tenden- 158 zen in der Fehlerentwicklung, die Verteilung der Fehler auf Releases oder Programm-Module und Kenngrößen zur Fehlerbehebung (Response- und Bearbeitungszeiten, Rückstände) über die Zeitachse analysiert und beurteilt werden.

1 S. „Fehlerklassifikation für Software“ – Leitfaden des BITKOM Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V., 2007. 2 Vgl. auch Conrad/Schneider/Witzel, in: Beck’sches Mandats-Handbuch ITRecht, § 16 Rz. 222. 3 Hilfreiche Ansätze für eine systematische Klassifikation und Beurteilung von Fehlern liefert auch immer noch die Norm DIN 66271 „Software-Fehler und ihre Beurteilung durch Lieferanten und Kunden“ aus dem Jahre 2005.

Hoppen

1433

Q Rz. 159

Einzelprobleme

IV. Bewertungsmethoden 1. Ansätze der Informatik 159

Bewertungsmethoden der Informatik dienen in erster Linie der Ermittlung des Entwicklungsaufwandes und damit der Herstellkosten einer Software. Ausgehend von Kenngrößen des Entwicklungsprojekts, z.B. des Umfangs des Quellcodes, kann der Aufwand, der bei einer unabhängigen Neuentwicklung der Software anzusetzen ist, abgeschätzt werden1. In der Praxis wurden seit Ende der 70er-Jahren des letzten Jahrhunderts2 eine Vielzahl von Verfahren entwickelt, die von unterschiedlichen Basisgrößen ausgehen (function points, data points, object points, use cases, Anzahl aufrufbare Codeelemente, Testfälle, lines of code, statement count etc.)3. Nachfolgend werden einige Verfahren beschrieben, die regelmäßig angewendet werden, umfassend publiziert und im Laufe der Jahre mit wissenschaftlichen und empirischen Studien unterlegt wurden4.

160

Allen Verfahren gemeinsam ist, dass ihre Genauigkeit von Produktivitätsgrößen abhängt, die bei einer externen Schätzung – auch z.B. bei der Bewertung einer Software – nur grob angenommen werden können, in der Praxis branchen- oder firmenspezifisch erheblich schwanken können und im Prinzip auf die konkrete Softwareentwicklungs-Organisation hin kalibriert werden müssen. Da dies kaum immer möglich sein wird, bietet jede Schätzmethode Einflussfaktoren an, über deren Abschätzung die in die Berechnung einfließende Produktivität an die Umgebungsbedingungen eines konkreten Entwicklungsprojekts angepasst werden kann. Letztlich handelt es sich um grobe Näherungen und um Faktoren, die der Entwickler des jeweiligen Schätzmodells aus seiner subjektiven Sicht für relevant hält5. Teilweise wird die Ansicht vertreten, die Qualität einer Schätzung durch parallele Schätzungen mit unterschiedlichen Schätzverfahren abzusichern6. In der hier in Rede stehenden Bewertung von Software-Projekten ist die Situation etwas anders, sie erfolgt retrograd und nicht progressiv; die Software wurde bereits entwickelt, Kenngrößen können sehr präzise bestimmt werden. Insofern erscheint es hier – auch unter Zeit- und Aufwandsaspekten – angemessen, Aufwandsschätzungen anhand eines Schätzverfahrens vorzunehmen. 1 S. im Überblick Jantzen, Verfahren der Aufwandsschätzung für komplexe Softwareprojekte von heute, Informatik-Spektrum, 2008 und Sneed, Software-Projektkalkulation, 2005, S. 41 ff. 2 Ausgangspunkt waren Vorgaben der US-Regierung gegenüber IBM, Softwareund Hardware-Dienstleistungen zu unbundlen, woraufhin sich im Markt die Nachfrage nach Softwareprojekten zum Festpreis entwickelte. 3 S. Sneed, Software-Projektkalkulation, 2005. 4 Umfangreiche Ausführungen hierzu finden sich in Capers Jones, Applied Software Measurement – Global Analysis of Productivity and Quality, 2008. 5 S. Jones, Variations in Software Development Practices, IEEE Software, 2003, S. 22. 6 S. Sneed, Software-Projektkalkulation, 2005, S. 69.

1434

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 165 Q

a) Function Point Analysis Das älteste und heute noch gebräuchliche Verfahren zur Aufwandsbestim- 161 mung ist die Function Point Analysis (FPA)1. Das Verfahren geht zurück auf erste Ansätze von Albrecht bei IBM in 1979, wurde aber im Laufe der Jahre in seiner Definition verfeinert und dem Stand der Technik angepasst2. Ein Großteil der Veröffentlichungen bezieht sich auf Function Points. Die International Function Point User Group (IFPUG) hat weltweit einheitliche Bewertungsrichtlinien veröffentlicht3. Das Verfahren bestimmt den fachlichen Leistungsumfang und geht aus von 162 den Funktionalitäten, die die Softwareentwicklung aus der Sicht des Endanwenders zu erfüllen hat. Diese werden in die kleinsten sinnvollen und mit dem System durchführbaren abgeschlossenen Aktivitäten, sog. Elementarprozesse, zerlegt. Die Elementarprozesse werden dabei nach einem relativ traditionellen Verständnis von Datenverarbeitung in fünf Kategorien eingeteilt und in ihrer Komplexität jeweils nach festgelegten Kriterien als Low, Average oder High bestimmt4. Die fünf Kategorien sind:

163

– External Input – Übernahme von Daten aus anderen Systemen, – External Output – Übergabe von Daten an andere Systeme, – External Inquiry – Annahme, Verarbeitung und Beantwortung von Anfragen aus anderen Systemen, – Internal Logical Files – Aus Anwendersicht identifizierbare Datengruppe, die von der Anwendung verwaltet wird sowie – External Interface Files – Aus Anwendersicht identifizierbare Datengruppe, die von der Anwendung nicht verwaltet wird, aber für die Verarbeitung relevant ist. Abhängig von der Komplexität werden für jeden Elementarprozess nach ei- 164 nem definierten Verfahren sog. function points ermittelt. In der Summe bestimmt sich so der gesamte Function-Point-Wert der Softwareentwicklung. Der Function-Point-Wert ist ein Maß für den Aufwand zur Programmierung der Software, er berücksichtigt aber nicht die weiteren Projektaufwendungen, die neben der reinen Programmierung anfallen. Ursprünglich wurde dieser Wert in dem FPA-Verfahren anhand von 14 Sys- 165 tem-Charakteristiken (Data Communication, Distributed Data Processing,

1 Garmus/Herron, Function Point Analysis – Measurement Practices for Successful Software Projects, 2000. 2 Dennoch enthält es auch heute noch Einflussfaktoren (System-Charakteristiken), die mittlerweile als vollkommen überholt gelten müssen, z.B. der Grad der Online-Datenbankänderung (online update). 3 http://www.ifpug.org. 4 Umfassende Darlegungen zum Einsatz der Methode finden sich in Bundschuh/ Fabry, Aufwandsschätzung von IT-Projekten, 2004.

Hoppen

1435

Q Rz. 166

Einzelprobleme

Performance, Heavily Used Configuration, Transaction Rate, Online Data Entry, End User Efficiency, Online Update, Complex Processing, Reusability, Installation Ease, Operational Ease, Multiple Sites, Facilitate Change) korrigiert, man spricht dann von adjusted function points. Diese SystemCharakteristiken sind auf heutige Systeme nur noch bedingt anwendbar, teilweise gehen sie noch von der Vorstellung einer Batch-Verarbeitung aus1. Bedeutung hat FPA aber immer noch in der Analyse von Softwareanwendungen und der systematischen Ermittlung von unadjusted function points, die dann als Ausgangspunkt für weitere Berechnungen z.B. der Bestimmung des Quellcode-Umfangs in dem COCOMO-Verfahren (s. Rz. 166 ff.), dienen. Damit kann z.B. der tatsächliche Quellcode-Umfang der zu bewertenden Softwareentwicklung gegen die implementierte Funktionalität abgeglichen und auf Plausibilität hin bewertet werden. b) COCOMO II 166

Bereits Anfang der 80er Jahre wurde von Boehm an der University of Southern California (USC) das Schätzverfahren COCOMO entwickelt (Constructive Cost Model)2. Dieses Verfahren kann angewandt werden, um den Entwicklungsaufwand einer Software zu bestimmen und beruht auf tatsächlichen Projektaufwendungen in großen Softwareprojekten. Das Verfahren wurde im Jahr 1995 als COCOMO 2.03 an die sich verändernden Entwicklungsumgebungen und neue Programmiersprachen angepasst. Es steht seit 2000 als COCOMO II-Modell zur Verfügung4. Die USC aktualisiert von Zeit zu Zeit die in das Modell einfließenden Parameter, die durch die Beobachtung und Auswertung von Softwareentwicklungsprojekten verfeinert werden und entwickelt Submodelle (COCOMO Suite)5.

167

In dem Verfahren wird der Entwicklungsaufwand einer Software in Personenmonaten PM ermittelt. Dieser umfasst in dem Modell nicht nur die

1 Gute Schätzergebnisse wurden auch in letzter Zeit noch bei konsistenter Nutzung innerhalb einer deutschen Versicherungs-Organisation gemacht, in der alle Faktoren konstant bleiben, s. Bundschuh/Fabry, Aufwandsschätzung von IT-Projekten, 2004. 2 Boehm, Software Engineering Economics, 1981. 3 Boehm/Clark/Horowitz/Westland, The COCOMO 2.0 Software Cost Estimation Model, USC, 1995, s. http://sunset.usc.edu/research/COCOMOII/Docs/ispa95. pdf. 4 Boehm/Abts/Brown/Chulami/Clark/Horrowitz/Madachy/Reifer/Steece, Software Cost Estimation with Cocomo II, Englewood Cliffs, NJ, 1999, zentrale Informationsquelle im Internet ist http://sunset.usc.edu/csse/research/COCO MOII/cocomo_main.html. 5 Barry Boehm/Ricardo Valerdi/Jo Ann Lane/A. Winsor Brown, COCOMO™ Suite Methodology and Evolution, CrossTalk – The Journal of Defense Software Engineering, 2005, S. 20 ff., s. http://sunset.usc.edu/csse/TECHRPTS/2005/usccse 2005-509/usccse2005-509.pdf.

1436

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 173 Q

reinen Programmierarbeiten, sondern den gesamten Projektaufwand. Er bestimmt sich in Abhängigkeit der Programmgröße Size durch die Gleichung PMnominal ¼ A  ðSizeÞB Der Multiplikator A sowie der Exponent B passen das Modell den spezifischen Projektgegebenheiten an. A ist eine Konstante. Die Bildung von B reflektiert die allgemeinen Entwicklungsbedingungen des Projekts, in dem die Software entsteht. Durch den Exponenten wird der Tatsache Rechnung getragen, dass die Produktivität bei steigender Projektgröße sinkt.

168

Der Quellcodeumfang Size ist im Normalfall in KDSLOC (tausend DSLOC) 169 anzugeben. DSLOC (delivered source lines of code) gibt die Anzahl effektiv wirksamer Programmbefehle am Ende der Entwicklung an. Es wird zwar von lines of code gesprochen, dies ist aber traditionell bedingt1. Gemeint ist die Anzahl der Anweisungen als kleinste syntaktische Einheit der verwendeten Programmiersprache. Dabei sind Kommentarzeilen und Codebestandteile, die nicht zur effektiven Programmfunktionalität beitragen (z.B. Textcode-Fragmente oder im Lauf der Entwicklung wieder verworfener Code) nicht zu berücksichtigen. Alternativ kann die Schätzung auch auf der Basis von Function Points oder 170 anderen Ausgangsgrößen vorgenommen werden, zu denen ProduktivitätsKennziffern vorliegen. Der so ermittelte nominelle Entwicklungsaufwand PMnominal ist mittels ei- 171 ner Reihe von Kostentreiberfaktoren (effort multipliers, EM) zu korrigieren, um Charakteristika der Softwareentwicklung zu berücksichtigen, die den Aufwand beeinflussen. COCOMO-II bietet drei Schätzmodelle mit unterschiedlichem Genauig- 172 keitsgrad an2: – Application Composition-Modell für sehr grobe Schätzungen im frühen Projektstadium – Early Design-Modell für grobe Schätzungen anhand von sieben Kostentreiberfaktoren – Post Architecture-Modell mit dem höchsten Detaillierungsgrad anhand von siebzehn Kostentreiberfaktoren. Besonders gut kann das Verfahren angewandt werden, wenn der Quellcode 173 bereits erstellt wurde und damit der Quellcodeumfang bereits bekannt ist, also in der Bewertungssituation. Hier kann das Post Architecture-Modell genutzt werden, da alle Kostentreiberfaktoren beurteilt werden können. Das Modell kann dann sehr gut dazu genutzt werden, die tatsächlich ange1 Als noch eine Lochkarte nur einen Programmbefehl enthalten konnte. Heute kann eine Zeile Code mehrere Anweisungen umfassen, umgekehrt kann sich eine Anweisung auf mehrere Zeilen erstrecken. 2 Vgl. auch Balzert, Lehrbuch der Softwaretechnik – Softwaremanagement, 2008, S. 210 ff.

Hoppen

1437

Q Rz. 174

Einzelprobleme

fallenen Entwicklungsaufwendungen des Unternehmens zu plausibilisieren bzw. abzustützen. 174

Im Post Architecture-Modell werden 17 Kostentreiberfaktoren (EM1-17) und ggf. ein Qualitätsfaktor (QM)1 multiplikativ angewandt und führen zu einer Korrektur des Entwicklungsaufwands, wenn die Gegebenheiten von „normalen“, typischen Projektgegebenheiten abweichen. # " 17 Y PMadjusted ¼ PMnominal  EM1  QM t¼1

175

Bei der Ermittlung des Entwicklungsaufwandes werden somit folgende Schritte durchgeführt: 1. Bestimmung des Quellcodeumfangs 2. Bestimmung und Berücksichtigung der Entwicklungsbedingungen 3. Bestimmung und Berücksichtigung der Kostentreiberfaktoren

176

Das Verfahren liefert im Ergebnis eine Abschätzung der Entwicklungsaufwendungen in den Phasen bzw. Tätigkeiten für Systemanalyse, Systementwurf, Feinkonzeption, Codierung, Modultest, Systemtest/Integration und Dokumentation. Der Aufwand für Anforderungsanalyse und Projektierung wird von dem Verfahren nicht geliefert und ist noch hinzuzurechnen. Das liegt daran, dass das Verfahren davon ausgeht, dass der Quellcodeumfang abgeschätzt werden kann – z.B. auch anhand der Function-Point-Methode. Deswegen ist es erst anwendbar, nachdem Anforderungsanalyse und Projektierung abgeschlossen wurden.

177

Das Verfahren liefert neben dem Entwicklungsaufwand in Personenmonaten auch Angaben über die erforderliche Anzahl an Personen und dann zu erwartende Entwicklungsdauer in Monaten.

178

Soll eine nicht vollständig abgeschlossene Softwareentwicklung bewertet werden, ist ergänzend zu berücksichtigen, in welchem Umfang die einzelnen bei einer Softwareentwicklung zu durchlaufenden Projektphasen fertiggestellt sind. Hierzu sind die jeweiligen Erfüllungsgrade der einzelnen Phasen zu bestimmen. I.W. sind hier zu sehen Anforderungsanalyse und Projektierung, Produktdesign (Grobkonzept, Fachkonzept, Lastenheft), Fein- und Systemkonzeption (Pflichtenheft), (DV-technisches Konzept), Programmierung, Modul- und Integrationstests, Einführungs- und Stabilisierungsphase.

179

Die Genauigkeit des COCOMO-II-Schätzverfahrens kann mit +/– 25 % angesetzt werden, insbesondere, wenn das Projekt abgeschlossen ist und der

1 Qualitätsfaktoren im Submodell COQUALMO unter Berücksichtigung von automatisierter Analyse, Review-Aktivitäten und Testaktivitäten, vgl. Sneed, Software-Projektkalkulation, 2005, S. 62.

1438

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 184 Q

Quellcode-Umfang aus dem Projekt heraus bekannt ist1. Wenn in der Bewertungspraxis bei der Anwendung des Verfahrens einzelne Informationen über die Projektentwicklung nicht zur Verfügung stehen, empfiehlt es sich, jeweils konservativ von Werten am unteren Ende der möglichen Bandbreite auszugehen. Die Bandbreite bei Variation von Entwicklungsbedingungen und Kostentreiberfaktoren kann durch alternative Schätzungen optimistischer, neutraler und pessimistischer Szenarien aufgezeigt werden. aa) Entwicklungsbedingungen Das Softwareentwicklungsprojekt wird in dem COCOMO-Verfahren nach 180 Komplexität und Schwierigkeit kategorisiert. Dabei sind die Merkmale Neuartigkeit, Entwicklungsflexibilität, Risikovorsorge, Teamzusammenarbeit und Prozessreife zu berücksichtigen. Zu jedem Merkmal sind mehrere Faktoren Wi vorhanden, deren Ausprägung nach folgender Skala unterschieden wird: sehr niedrig, niedrig, normal, hoch, sehr hoch und extra hoch. Nicht alle Merkmale sind in allen Stufen vorgesehen; teilweise liegen keine Faktoren für die Stufen sehr niedrig, niedrig, sehr hoch und extra hoch vor. Die Neuartigkeit (Precedentedness, W1) ist zu bewerten an der Erfahrung 181 aus vergleichbaren Softwaresystemen, der Wiederverwendbarkeit bereits vorhandener Lösungsansätze, dem Grad der Identifikation der Organisation mit den Produktzielen, der parallelen Entwicklung neuer Hardware oder neuer Ablauforganisationen sowie der Erfordernis neuer Algorithmen oder Datenverarbeitungsarchitekturen. Die Entwicklungsflexibilität (Development Flexibility, W2) ist zu bewerten an der Abhängigkeit der zu entwickelnden Software von vorher definierten Einsatzumgebungen, der Abhängigkeit von extern vorgegebenen Schnittstellenspezifikationen und dem Zeitdruck.

182

Die Risikovorsorge (Architecture/Risk Resolution, W3) bestimmt den Grad 183 der Abstimmung der Projektarchitektur auf die Projektrisiken. Sie ist zu bewerten nach der Existenz und Vollständigkeit eines Risk-ManagementPlans, der Abstimmung des Projektplans darauf, dem Anteil der konzeptionellen Projektaktivitäten, dem Grad der Erfordernis hochqualifizierter Mitarbeiter, dem Einsatz von Werkzeugen zur Durchsetzung der Projektziele, dem Grad der konzeptionellen Unbestimmtheit in zentralen Bestandteilen der Softwarearchitektur und der Anzahl erkannter kritischer Risikostellen. Die Teamzusammenarbeit (Team Cohesion, W4) ist zu beurteilen anhand der Übereinstimmung der persönlichen Ziele und Kulturen aller Beteilig1 In dem ursprünglichen COCOMO-Verfahrens lagen zunächst 81 % aller Schätzungen innerhalb +/– 20 % der tatsächlichen Kosten. Das traf allerdings Ende der 90er-Jahre nicht mehr zu, was zu der Entwicklung des COCOMO-II-Verfahrens führte. In dieser neuen Methode lag die Genauigkeit wieder bei +/– 20 % in 75 % aller Fälle, s. Sneed, Software-Projektkalkulation, 2005, S. 62.

Hoppen

1439

184

Q Rz. 185

Einzelprobleme

ten, der Fähigkeit und Bereitschaft einzelner Beteiligter, die Ziele anderer zu verfolgen, der Erfahrung in der Zusammenarbeit sowie der Fähigkeit, eine gemeinsame Vision und Commitments zu entwickeln. 185

Die Prozessreife (Process Maturity, W5) ist anhand eines Untermodells (Capability Maturity Model des Software Engineering Institutes der USC) zu ermitteln (vgl. Darstellungen zu CMMI in Rz. 135 ff.).

186

Die Einstufung des Projektes innerhalb der vorgenannten Merkmale bestimmt den Exponenten B aus der Gleichung (1) zu: X B ¼ 0:91 þ 0:01  w1 bb) Kostentreiberfaktoren

187

In das COCOMO-Schätzverfahren fließen Kostentreiberfaktoren (EM1-17) ein, die Produkt-, Plattform-, Personal-, und Projekt-Merkmale darstellen. In jeder Gruppe sind mehrere Faktoren vorhanden, deren Ausprägung unterschieden wird nach sehr niedrig, niedrig, normal, hoch, sehr hoch und extra hoch. Nicht alle Merkmale sind in allen Stufen vorgesehen, teilweise liegen keine Faktoren für die Stufen sehr niedrig, niedrig, sehr hoch und extra hoch vor. Eine Einstufung als „normal“ hat immer den Wert 1, führt also zu keiner Korrektur des Entwicklungsaufwands.

188

Folgende Produkt-Merkmale werden unterschieden1: – – – – –

189

Geforderte Zuverlässigkeit der Software (Required Reliability) Größe der Datenbasis (Database Size) Komplexität des Produkts (Product Complexity) Geforderte Wiederverwendbarkeit (Required Reuse) Anforderungsniveau an die Software-Dokumentation (Documentation)

Im Bereich der Plattform-Merkmale gibt es folgende Kriterien: – Beschränkungen/Kritikalität der Ausführungszeit (Execution Time Constraint) – Beschränkungen/Kritikalität der Speicheranforderungen (Main Storage Constraint) – Änderungshäufigkeit in der Systemumgebung (Platform Volatility)

190

Die Personal-Merkmale berücksichtigen die Qualifikation der im Projekt eingesetzten Mitarbeiter: – Analyse-Fähigkeiten (Analyst Capability) – Programmier-Fähigkeiten als Team (Programmer Capability) – Erfahrung der Programmierer im Anwendungsgebiet (Applications Experience)

1 Vgl. http://sunset.usc.edu/research/COCOMOII/expert_cocomo/expert_cocomo 2000.html.

1440

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 193 Q

– Erfahrung der Programmierer in der Entwicklungsplattform (Platform Experience) – Erfahrung der Programmierer in der Programmiersprache und den eingesetzten Software-Werkzeugen (Language and Toolset Experience) – Personalfluktuation (Personnel Continuity) Zudem existieren die folgenden Projekt-Merkmale:

191

– Einsatz moderner Softwarewerkzeuge (Use of Software Tools) – Kommunikationsintensität (Multisite Development) – Geforderte Entwicklungszeit (Required Development Schedule) c) COSMIC Full Function-Point (FFP) Im Jahre 1999 entstand auf der Basis von FPA (vgl. Rz. 161 ff.) unter Führung 192 des Common Software Measurement International Consortium das Verfahren COSMIC-FFP, in dem die speziellen Gegebenheiten objektorientierter Software berücksichtigt werden1. Beispielsweise ist es mit dieser Metrik möglich, den Umfang eines Software-Systems, das in der Definitionssprache UML (Unified Modeling Language) definiert wurde, abzuschätzen, d.h. bereits auf der Ebene eines Pflichtenhefts. Das Verfahren wurde 2003 als internationaler Standard definiert2, der in 2008 als ISO/IEC 19761:2008 an die Version 3 von COSMIC angepasst wurde. Die Elementarprozesse werden in dem Modell functional process type ge- 193 nannt und umfassen nicht nur die aus Anwendersicht geforderten Funktionalitäten, sondern auch die aus Entwicklersicht zusätzlich notwendigen systeminternen Prozesse. Dadurch können systeminterne Gegebenheiten und Technologieaspekte besser berücksichtigt werden. Jeder Elementarprozess wird danach untersucht, in welchem Umfang er bestimmte Datenbewegungen – nämlich Read bzw. Write als Lesen oder Schreiben von im System verwalteten Datenbeständen und Entry bzw. Exit als Annahme bzw. Abgabe von Daten an externe Systeme oder Anwender – vornimmt. Die Anzahl der Datenbewegungen bestimmt dann die Vergabe von sog. CFSUs, COSMIC functional size units. Die Summe aller CFSUs ist in dem Modell, ähnlich wie bei der Function-Point-Methode, das Maß für den Programmieraufwand der Software und dient dazu, den Quellcode-Umfang abzuschätzen. Die übrigen Charakteristika eines Softwareentwicklungsprojektes (vgl. Kostentreiberfaktoren in COCOMO zur Berücksichtigung von Qualitätsund nicht-funktionalen Anforderungen) werden auch hier, wie bei der Function-Point-Methode, nicht betrachtet.

1 http://www.cosmicon.com. 2 ISO/IEC 19761:2003: Software Engineering – COSMIC-FFP, A functional size measurement method.

Hoppen

1441

Q Rz. 194

Einzelprobleme

d) Produktorientierte Schätzung 194

Eine weitere Möglichkeit der Aufwandsschätzung besteht darin, das Softwaresystem in die zu realisierenden System-Objekte zu zerlegen und dadurch ein Mengengerüst typisierter Tätigkeiten in den einzelnen Entwicklungsphasen zu bestimmen. Die zu bewertende Software kann z.B. dahingehend analysiert werden, wie viele Datenbank-Tabellen, Datenbank-Felder, Eingabemasken, Druckausgaben, Batch-Prozesse, Schnittstellen, Workflows, interne Programmfunktionen, Klassen, Module, Prozeduren etc. sie enthält und welche Tätigkeiten in welchem Umfang bei Entwurf, Spezifikation, Codierung und Tests anfallen werden. Voraussetzung ist, dass verlässliche Produktivitätswerte für diese Tätigkeiten vorliegen oder aus anderen Projekten bzw. Erfahrungswerten abgeleitet werden können. 2. Betriebswirtschaftliche Ansätze

195

Bei der Bestimmung des Wertes der Software anhand betriebswirtschaftlicher Ansätze wird nicht auf die Ermittlung der Herstellungskosten (Entwicklungsaufwand der Software, Ergebnis der Bewertungsansätze der Informatik) abgezielt, sondern es stehen in der Regel die mit dem Eigentum an der Software erzielbaren Nettozuflüsse (Zahlungsströme) im Fokus. Vor dem Hintergrund eines geänderten Verwertungskonzepts können ggf. auch Substanz- und Liquidationswert von Interesse sein. a) Kapitalisierung, Barwert

196

In der Praxis werden zur Bestimmung eines konkreten Wertes die aus der Verwertung der Software erzielbaren künftigen Erträge auf den Bewertungsstichtag abgezinst (diskontiert) und aufsummiert. Dieser Vorgang wird als Kapitalisierung, der dabei ermittelte Wert wird als Barwert bezeichnet.

197

Der Barwert B errechnet sich zu T X B¼ ðEt  At Þ  ð1 þ zÞt t¼1

wobei T den Betrachtungshorizont (Lebensdauer der Software) in Jahren und Et bzw. At die mit der Verwertung der Software verbundenen Einnahmen und Ausgaben im jeweiligen Jahr t darstellen. z ist der Kapitalisierungszinssatz, dessen Höhe das Ergebnis maßgeblich beeinflusst. 198

In die Ermittlung des Barwerts fließt maßgeblich der Kapitalisierungszinssatz z ein, der in der Höhe so zu bemessen ist, dass er die Rendite einer Alternativanlage mit vergleichbaren Chancen und Risiken abbildet (vgl. Rz. 271 ff.) Wahl des Kapitalisierungszinssatzes), fristenkongruent auf die Laufzeit der Nutzungsmöglichkeit der Software ausgerichtet.

1442

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 201 Q

b) IDW Standards S1 und S5 Richtlinien zur Bestimmung eines Verkehrswerts liefern die von Wirt- 199 schaftsprüfern bei der Durchführung von Unternehmensbewertungen angewandten allgemeinen Grundsätze und Methoden, die in den Veröffentlichungen Standard S1 „Grundsätze zur Durchführung von Unternehmensbewertungen“1 und Standard S5 „Grundsätze zur Bewertung immaterieller Vermögenswerte“2 des Instituts der Wirtschaftsprüfer (IDW) dokumentiert wurden. Aus diesen Standards sind – aus der technischen Sicht des Informatikers – 200 folgende Grundsätze auch für die Bewertung von Software maßgeblich: aa) Maßgebliche Vorgaben des IDW Standards S1 – Grundsätze zur Durchführung von Unternehmensbewertungen – Rz. 4: Der Wert „bestimmt sich durch den Barwert der mit dem Eigen- 201 tum … verbundenen Nettozuflüsse“, also allein aus der Ertragskraft der Software. – Rz. 5: Anzunehmen ist im Normalfall die Fortführung der bisherigen Verwertung. – Rz. 6: „Dem Substanzwert kommt keine eigenständige Bedeutung zu“. – Rz. 12: Der Sachverständige als neutraler Gutachter hat „mit nachvollziehbarer Methodik einen von den individuellen Wertvorstellungen betroffener Parteien unabhängigen Wert“ als objektivierten Wert zu ermitteln. – Rz. 13: Der Preis „bildet sich auf freien Kapitalmärkten aus Angebot und Nachfrage. Er wird wesentlich von der Nutzenschätzung (Grenznutzen) der jeweiligen Käufer und Verkäufer bestimmt“. – Rz. 22: Werte sind „zeitpunktbezogen auf den Bewertungsstichtag zu ermitteln“ (Stichtagsprinzip). – Rz. 38: Bei der Ermittlung des objektivierten Wertes der Software ist die der Software „innewohnende und übertragbare Ertragskraft zu bewerten.“ – Rz. 71: Bei der Informationsbeschaffung sind als „unternehmensbezogene Informationen … vor allem interne Planungsdaten sowie daraus entwickelte Plan-Bilanzen, Plan-Gewinn- und Verlustrechnungen sowie Plan-Kapitalflussrechnungen heranzuziehen. Als marktbezogene Daten können insbesondere Informationen über branchenspezifische Märkte und volkswirtschaftliche Zusammenhänge verwendet werden“. 1 Institut der Wirtschaftsprüfer, IDW Standard S 1 – Grundsätze zur Durchführung von Unternehmensbewertungen (IDW S 1), Düsseldorf, derzeit aktueller Stand v. 2.4.2008. 2 Institut der Wirtschaftsprüfer, IDW Standard S 5 – Grundsätze zur Bewertung immaterieller Vermögenswerte (IDW S 5), Düsseldorf, derzeit aktueller Stand v. 25.5.2010.

Hoppen

1443

Q Rz. 202

Einzelprobleme

– Rz. 76–78: „In der Praxis hat es sich daher als hilfreich erwiesen, die finanziellen Überschüsse in unterschiedlichen Zukunftsphasen zu planen und zu prognostizieren“. In den meisten Fällen wird die Planung in zwei Phasen vorgenommen, einer Detailplanungsphase von drei bis fünf Jahren, zu der „zumeist hinreichend detaillierte Planungsrechnungen zur Verfügung“ stehen. „Die Planungsjahre der ferneren zweiten Phase basieren i.d.R. – ausgehend von der Detailplanung der ersten Phase – auf langfristigen Fortschreibungen von Trendentwicklungen“. – Rz. 80: „Aufgrund der Fülle von Einflussfaktoren kann es sich empfehlen, mehrwertige Planungen, Szenarien oder Ergebnisbandbreiten zu erstellen, um das Ausmaß der Unsicherheit der künftigen finanziellen Überschüsse zu verdeutlichen und erste Anhaltspunkte für die Berücksichtigung der Unsicherheit … zu gewinnen“. – Rz. 81: „Die Prognose der künftigen finanziellen Überschüsse ist auf ihre Plausibilität hin zu beurteilen“. – Rz. 82: Die „Verlässlichkeit und Vollständigkeit der Bewertungsgrundlagen“ ist zu beurteilen. – Rz. 83: Von dem Unternehmen ist eine Vollständigkeitserklärung einzuholen. Trotzdem hat der Sachverständige sich „selbst ein Urteil über die Plausibilität der Planungen und Prognosen zu bilden“. – Rz. 85: „In bestimmten Fällen kann es … sachgerecht sein, eine begrenzte Lebensdauer … anzunehmen“. Hiervon ist bei Software auszugehen. – Rz. 89: Das kann durch „Abschlag vom Erwartungswert der finanziellen Überschüsse (Sicherheitsäquivalenzmethode, Ergebnisabschlagsmethode) oder als Zuschlag zum Kapitalisierungszinssatz (Zinszuschlagsmethode, Risikozuschlagsmethode)“ erfolgen. – Rz. 90: National und international ist die Zinszuschlagsmethode üblich. bb) Maßgebliche Vorgaben des IDW Standards S5 – Grundsätze zur Bewertung immaterieller Vermögenswerte 202

– Rz. 4: Bei der Bewertung ist „zwischen der Bewertung des Vermögenswerts für Transaktionszwecke im Rahmen eines ordentlichen Geschäftsgangs (going concern) und der Bewertung unter der Annahme der Zerschlagung des Unternehmens (Liquidation) zu unterscheiden“. – Rz. 8: Der Wirtschaftsprüfer als Sachverständiger bewertet „aus der Perspektive eines fremden Dritten mit nachvollziehbarer Methodik einen typisierten Wert für den betreffenden immateriellen Vermögenswert. Hierbei hat er alle für die Bewertung relevanten Tatsachen und Umstände zu berücksichtigen und kritisch zu würdigen“. – Rz. 18: „Für die Bewertung immaterieller Vermögenswerte kommen grundsätzlich drei Bewertungsverfahren infrage. Dies sind das marktpreisorientierte Verfahren (market approach), das kapitalwertorientierte Verfahren (income approach) und das kostenorientierte Verfahren (cost approach)“. 1444

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 202 Q

– Rz. 19: Ein marktpreisorientiertes Verfahren setzt „hinreichend vergleichbare Vermögenswerte“ und einen „aktiven Markt“ voraus und scheidet für die Bewertung von Software wegen Inhomogenität, geringer Fungibilität und nicht öffentlich bekannter Preise i.d.R. aus. – Rz. 22: „Dem kapitalwertorientierten Verfahren liegt die Annahme zugrunde, dass sich der Wert eines immateriellen Vermögenswerts aus dessen Eigenschaft ergibt, künftige Erfolgsbeiträge in Form von Cashflows zu erwirtschaften“. – Rz. 23: „Der Wert eines Vermögenswerts ergibt sich aus der Summe der Barwerte der künftig erzielbaren Cashflows zum Bewertungsstichtag (Discounted Cash Flow), die aus der Nutzung des immateriellen Vermögenswerts während der erwarteten wirtschaftlichen Nutzungsdauer und ggf. aus dem Abgang generiert werden“. – Rz. 25: „Beim zugrunde zu legenden Planungszeitraum der Cashflows ist auf die wirtschaftliche Nutzungsdauer bzw. die verbleibende Restnutzungsdauer des immateriellen Vermögenswerts abzustellen. Regelmäßig ist die Nutzungsdauer immaterieller Vermögenswerte, wie auch die materieller Vermögenswerte, zeitlich begrenzt, sodass die Berücksichtigung einer ewigen Rente im Bewertungskalkül nicht in Betracht kommt“. – Rz. 41: „Der Wert des immateriellen Vermögenswerts wird durch Diskontierung der ihm zugerechneten künftigen finanziellen Überschüsse auf den Bewertungsstichtag ermittelt. Bei der regelmäßig angewendeten Risikozuschlagsmethode müssen die Erwartungswerte der Cashflows mit einem risikoangepassten Kapitalisierungszinssatz diskontiert werden“. – Rz. 48: Das kostenorientierte Verfahren „umfasst die Reproduktionskostenmethode und die Wiederbeschaffungskostenmethode. Es hat allerdings eine wesentliche konzeptionelle Schwäche, da der zukünftige Nutzen aus dem immateriellen Vermögenswert allenfalls mittelbar im Bewertungskalkül berücksichtigt wird. Kostenorientierte Methoden werden daher i.d.R. nur für Plausibilitätsüberlegungen (z.B. anhand von Anschaffungskosten für immaterielle Werte) eingesetzt oder wenn andere Verfahren nicht oder nicht hinreichend sicher anwendbar sind“. – Rz. 51: „Die Entscheidung, welches Wertkonzept und welches Bewertungsverfahren für die Bewertung eines immateriellen Vermögenswerts heranzuziehen ist, richtet sich nach dem Bewertungsanlass“. – Rz. 110: „Die Arbeitspapiere müssen einem sachkundigen Dritten ermöglichen, das Bewertungsergebnis nachzuvollziehen und die Auswirkungen der getroffenen Annahmen auf den ermittelten Wert abzuschätzen (intersubjektive Nachprüfbarkeit)“. – Rz. 112: Der Sachverständige hat „die wesentlichen Annahmen und die Vorgehensweise bei der Wertableitung zu dokumentieren und darzulegen, warum er diese im jeweiligen Wertkonzept für geeignet hält“.

Hoppen

1445

Q Rz. 203

Einzelprobleme

c) IDW PS 850, 880 203

Das IDW hat in den Prüfungsstandards PS 850 bzw. PS 880 die Berufsauffassung dargelegt, nach der Wirtschaftsprüfer unbeschadet ihrer Eigenverantwortlichkeit bei der projektbegleitenden Prüfung der Entwicklung und des Einsatzes von IT-gestützten Rechnungslegungssystemen bzw. bei der Prüfung von Softwareprodukten und der Erteilung von Bescheinigungen zu Softwareprodukten vorgehen.

204

Hier werden vielfältige Aspekte angesprochen, die grundsätzlich auch bei der Bewertung von Software zu berücksichtigen sind, jeweils angepasst an den konkreten Projektumfang: aa) Maßgebliche Vorgaben des IDW Prüfungsstandards PS850 – Projektbegleitende Prüfung bei Einsatz von Informationstechnologie

205

– Rz. 17: Typischerweise entstehen in Softwareentwicklungsprojekten in den einzelnen Projektphasen definierte Arbeitsergebnisse: Eine „Aufgabenbeschreibung“ als Ergebnis der Planungsphase, „fachliche Pflichtenhefte“ als Ergebnis der Definitionsphase, „technische Entwurfsspezifikationen“ als Ergebnis der Entwurfsphase, das Programm selber als Ergebnis der Realisierungsphase, „Modul-, Integrations- und Lasttests“ als Ergebnis der Testphase. – Rz. 23: Projektrisiken bei der Entwicklung von Individualsoftware ergeben sich im Wesentlichen aus – „dem Funktionsumfang der Software und deren Ausgestaltung“, aus – „einer unzureichenden Entwicklungsumgebung“ und – einer nicht „adäquaten Umsetzung der Grundsätze ordnungsmäßiger Buchführung“, insbesondere der Beleg-, Journal- und Kontenfunktion, – unzureichender Dokumentation und einer – nicht „angemessenen Ausgestaltung der anwendungsbezogenen ITKontrollen (Eingabe-, Verarbeitungs- und Ausgabekontrollen)“. – Rz. 28: Bei der Prüfung ist „festzustellen, ob die sich aus den anzuwendenden gesetzlichen Vorschriften sowie aus den Grundsätzen ordnungsmäßiger Buchführung ergebenden Ordnungsmäßigkeits-, Sicherheitsund Kontrollanforderungen bei der Umsetzung des IT-Projekts beachtet wurden“. – Rz. 57: Prüfungsrelevante Arbeitsergebnisse der Entwurfsphase sind fachliche Spezifikationen, technische Spezifikationen einschließlich der Schnittstellen zu anderen IT-Anwendungen, Kapazitäts- und Leistungsanforderungen und ggf. spezifische Sicherheitskonzepte. Diese Ergebnisse müssen nachvollziehbar dokumentiert sein. – Rz. 61: Bezogen auf die Realisierungsphase sind die „Einhaltung der Richtlinien für die Programmierung und die Wirksamkeit der projektinternen Qualitätssicherungsmaßnahmen“ zu prüfen, insbesondere auch

1446

Hoppen

Rz. 206 Q

Bewertung von Software, Due Diligence, Compliance

– – –

– –

–

„ob mittels Entwicklertests bereits in dieser Phase die sachgerechte Umsetzung der funktionalen Anforderungen beurteilt wird“. Rz. 74: Zu prüfen ist, ob in der Testphase „Tests gemäß den Projektvorgaben geplant, vorbereitet und durchgeführt werden“. Rz. 76: Dabei ist auf „Funktionstrennung zwischen Entwicklung, Testdurchführung und Projektabnahme“ zu achten. Rz. 77: Es kann erwartet werden, dass in der Testphase „der Testplan insgesamt eine hinreichende Abdeckung aller Programmfunktionen gewährleistet“, „die Testfälle gemäß Testplan durchgeführt“ werden und „die Testergebnisse nachvollziehbar dokumentiert“ werden. Rz. 90: Ergebnisse der „internen Revision bzw. der Organisationseinheiten“ können bei der Prüfung berücksichtigt werden. Rz. 91: Jedoch: „Die unbesehene Übernahme fremder Ergebnisse ist nicht zulässig. Der projektbegleitende Prüfer hat die Untersuchungen und Feststellungen Dritter zumindest kritisch zu würdigen“. Rz. 92: Die Prüfungshandlungen und die gewonnenen Erkenntnisse sind „angemessen in den Arbeitspapieren zu dokumentieren und die wesentlichen Ergebnisse im Prüfungsbericht … zusammenzufassen“.

bb) Maßgebliche Vorgaben des IDW Prüfungsstandards PS880 – Die Prüfung von Softwareprodukten – Rz. 11: Bestandteil einer Softwareprüfung ist die Beurteilung des Soft- 206 wareentwicklungsverfahrens, insb. auch das bei der Softwareentwicklung angewandte Dokumentations- und Testverfahren. – Rz. 13: Die Prüfung der Angemessenheit von Programmfunktionen setzt eine aussagefähige Verfahrensdokumentation voraus. – Rz. 14: Die programmtechnische Umsetzung von Programmfunktionen setzt Tests des Softwareherstellers voraus, die systematisch auf der Grundlage von Testfällen vorgenommen wurden. – Rz. 18: Gesetzliche und regulatorische Anforderungen bei Softwareprodukten mit Bezug zur Rechnungslegung oder internen Kontroll- bzw. Risikomanagementsystemen ergeben sich insbesondere aus den Grundsätzen ordnungsmäßiger Buchführung (Ordnungsmäßigkeit, Sicherheit rechnungslegungsbezogener Programmfunktionen) und regulatorischen Vorschriften zur Rechnungslegung, z.B. § 25a KWG. Ansonsten sind aufgabenspezifische Normen und Standards oder spezifische Branchen- und Industriestandards mit IT-Bezug zugrunde zu legen. – Rz. 20: Vom Softwarehersteller selbst entwickelte Kriterien müssen relevant, vollständig und verständlich sein und eine konsistente, objektive und nachvollziehbare Beurteilung des Softwareprodukts ermöglichen. – Rz. 21: Solche Kriterien können z.B. Projekt- und Programmierrichtlinien oder Vorgaben zur Oberflächengestaltung sein.

Hoppen

1447

Q Rz. 206

Einzelprobleme

– Rz. 25: Die Anforderungen der Grundsätze ordnungsmäßiger Buchführung (s. Kap. Q Rz. 26) erfordern zwingend die Einhaltung der Grundsätze gemäß §§ 238 und 239 HGB, die Umsetzung von Beleg-, Journal-, Kontenfunktion sowie die Berücksichtigung von Anforderungen zur Dokumentation und Archivierung1. – Rz. 28: Der Grundsatz der Nachvollziehbarkeit in Systemen, die den GOB unterliegen, verlangt neben spezifischen Nachweisfunktionen der Software, anhand derer Buchungen nachvollzogen werden können auch „vollständige, aussagefähige Verfahrensdokumentation zur Erläuterung des Softwareprodukts bzw. des Buchführungsverfahrens“. – Rz. 29: Der Grundsatz der Unveränderlichkeit in solchen Systemen verlangt, dass „der ursprüngliche Zustand von geänderten rechnungslegungsrelevanten Stamm- und Bewegungsdaten erkennbar bleibt“ und „die Tatsache der Veränderung nachweisbar ist“. – Rz. 30: „Ferner müssen in der Anwendung im Rahmen des programminternen Kontrollsystems hinreichende Eingabe-, Verarbeitungs- und Ausgabekontrollen vorgesehen sein, um insb. die Richtigkeit und Vollständigkeit der Eingabe und Verarbeitung von Geschäftsvorfällen sicherzustellen“. – Rz. 33: „Softwareprodukte können durch entsprechend gestaltete Verarbeitungsfunktionen einen Beitrag zur Sicherheit von IT-Systemen leisten. Beispiele hierfür sind in Softwareprodukte integrierte Verschlüsselungstechniken oder die Gestaltung eines Berechtigungsverfahrens mit detaillierten Rollenkonzepten, Feldberechtigungen und Freigabeverfahren“. – Rz. 38: „Typische Beispiele für spezifische Branchen- und Industriestandards mit IT-Bezug sind ISO- und DIN-Normen, aber auch COBIT als Standards für die Gestaltung von IT-Prozessen“. – Rz. 48: Voraussetzung für Prüfungshandlungen „ist das Vorliegen geeigneter und vollständiger Dokumentationsunterlagen, die in einer Weise bereitgestellt werden müssen, dass die Softwareentwicklungsumgebung und die zu prüfenden Programmfunktionen für den Wirtschaftsprüfer in angemessener Zeit nachvollzogen werden können“. Zu diesen Unterlagen zählen insbesondere eine Anwenderdokumentation, eine technische Dokumentation und eine Betriebsdokumentation. „Diese Anforderungen an die Verfahrensdokumentation gelten stets und unabhängig von dem jeweiligen Aufgabengebiet des Softwareprodukts“. – Rz. 53: „Unzureichende Softwareentwicklungsverfahren und der Umgang mit veralteten oder nicht ausgereiften Technologien“ bergen fehlererhöhende Risiken. Gefordert werden „standardisierte und normierte 1 Vgl. hinsichtlich der Archivierung im Allgemeinen auch Hoppen, Datenarchivierung – DV-technische Aspekte bei der Erfüllung rechtlicher Aufbewahrungspflichten, CR 2008, 674 ff. und hinsichtlich der E-Mail-Archivierung Lensdorf, E-Mail Archivierung: zwingend oder nur „nice to have“?, CR 2008, 354 ff.

1448

Hoppen

Bewertung von Software, Due Diligence, Compliance

–

–

–

–

– –

–

–

–

Rz. 206 Q

Entwicklungsprozesse, die Toolunterstützung von Routineaufgaben in der Entwicklung und vollständige und aktuelle Verfahrens- und Testdokumentation“. Konkrete Risiken in den einzelnen Phasen des Softwareentwicklungsprozesses ergeben sich insbesondere durch unzureichende Dokumentation in allen Phasen. Rz. 57: „Standards und Normen für die Softwareentwicklung sind Voraussetzung für eine prozessintegrierte Qualitätssicherung und sollen die Nachvollziehbarkeit der Softwareentwicklung erleichtern. Typische Beispiele sind: Namenskonventionen für Felder, Objekte und Module, standardisierte Vorgaben für die Erstellung von Quellcodes oder von technischen Dokumentationen und Tools zur (Teil-)Automatisierung von Entwicklungsaufgaben und zur maschinellen Kontrolle der Einhaltung von Programmiervorgaben“. Rz. 58: „In der Softwareentwicklungsumgebung bzw. für die Programmbibliotheken sind die Versionen nachzuweisen und deren Änderungen eindeutig voneinander abgegrenzt zu dokumentieren“. Rz. 59: „Das Test- und Abnahmekonzept muss gewährleisten, dass alle in dem Softwareprodukt abgebildeten Funktionen und Geschäftsprozesse in ausreichendem Maße getestet werden. Die Testfälle, der Testumfang, der Testabdeckungsgrad sowie die Testdurchführung und deren Ergebnisse müssen in einer für Dritte nachvollziehbaren Weise dokumentiert werden“. Rz. 60: „Besondere Bedeutung hat der Wirtschaftsprüfer der Entwicklung und Pflege von System- und Testdokumentationen beizumessen“. Das gilt auch für deren Aktualisierung nach Programmänderungen. Rz. 67: „Die Beurteilung der Funktionsfähigkeit erfolgt anhand von Testfällen bzw. Testergebnissen des Softwareherstellers“. Rz. 68: „Das Test- und Abnahmekonzept des Softwareherstellers muss sicherstellen und nachweisen, dass alle Programmfunktionen durch Testfälle abgedeckt werden, nicht nur der erwartete Programmablauf berücksichtigt wird, sondern auch Testfälle zur Erzeugung von Fehlermeldungen konzipiert wurden (sog. Test gegen das System), bei parametergesteuerten Programmfunktionen auch die variablen Steuerungsdaten getestet werden und in die Tests auch Eingangs- und Ausgangsschnittstellen einbezogen werden“. Rz. 69: „Die Durchführung der Tests und den Vergleich zwischen erwartetem und erzieltem Testergebnis“ müssen anhand der Testdokumentation beurteilt werden können. Rz. 74: Bereits vorhandene Beurteilungen können einbezogen werden. „Die Ergebnisse solcher Beurteilungen unterliegen … stets zumindest der kritischen Würdigung durch den Wirtschaftsprüfer“. Rz. 75: Die Durchführung der Bewertung ist als solche nachvollziehbar zu dokumentieren: „Die gewonnenen Kenntnisse über das zu prüfende Softwareprodukt und das Softwareentwicklungsverfahren sowie die dazu

Hoppen

1449

Q Rz. 207

Einzelprobleme

im Rahmen von Aufbau- und Funktionsprüfungen vorgenommenen Prüfungshandlungen sind im berufsüblichen Umfang in den Arbeitspapieren zu dokumentieren“.

V. Vorgehen bei der Bewertung 207

Nachfolgend wird – praktisch ausgerichtet – beschrieben, wie bei der Durchführung einer Software Due Diligence unter Beachtung der vorstehend dargestellten Grundlagen vorgegangen werden kann. 1. Vergleichende Betrachtung unterschiedlicher Wertansätze

208

Bei der Softwarebewertung kann – und sollte – der Wert der Software unter verschiedenen Aspekten betrachtet werden: 1. in Form der tatsächlich angefallenen Entwicklungsaufwände (Anschaffungs- bzw. Herstellungskosten), 2. als Wiederbeschaffungswert auf der Basis von Bewertungsansätzen der Informatik, d.h. Ableitung der Entwicklungsaufwände anhand der Größe des Quellcode, z.B. unter Verwendung des COCOMO-Verfahrens (Wiederbeschaffungskosten), 3. als Verkehrswert auf der Basis betriebswirtschaftlicher Bewertungsansätze, d.h. unter Berücksichtigung von möglichen Einnahmen aus Lizenzen, Support, Updates (Kapitalwert) 4. ggf. als Ableitung aus vergleichbaren Transaktionen (Marktwert) und schließlich 5. in Form der noch verwertbaren Substanz bei Beendigung der Verwertung (Liquidationswert).

209

Die unterschiedlichen Wertangaben können gegeneinander aufgewogen bzw. zur Plausibilisierung herangezogen werden, z.B. hinsichtlich maximaler oder minimaler Ansätze. In der Summe ergibt eine vergleichende Betrachtung erfahrungsgemäß eine verlässliche, nachvollziehbare und in sich konsistente Wertbestimmung (objektivierter Wert). 2. Beurteilung der Produkteigenschaften

210

Im Vordergrund jeder Bewertung steht zunächst das zu bewertende Software-Produkt selbst. Es ist unter verschiedenen Aspekten zu analysieren und zu beschreiben. Dabei können sich vielfältige qualitative Fragen stellen. Im Einzelnen sind die oben beschriebenen wertbestimmenden Faktoren maßgeblich (vgl. Rz. 20 ff.).

211

Die nachfolgenden Fragen können als Checkliste dienen: a) Allgemeine Feststellungen zum Produkt, Zielgruppe – Welche Version der Software wird bewertet? 1450

Hoppen

Rz. 211 Q

Bewertung von Software, Due Diligence, Compliance

– – – – –

Was ist der Einsatzzweck der Software? In welchen Branchen kann sie eingesetzt werden? Welche Kunden setzen die Software ein? Wie hat sich die Software historisch entwickelt? Gab es dabei wesentliche Umbruchsituationen?

b) Betrachtung der Funktionalität und Ordnungsmäßigkeit, IT-Compliance – Wie ist der Funktionsumfang der Software? – Was sind typische Datenmengen? – In welchem Umfang werden die fachlich funktionalen Anforderungen erfüllt? – Wo sind besondere Vor- und Nachteile? – Gibt es funktionale Alleinstellungsmerkmale? – Erfüllt die Software die gesetzlichen und regulatorischen Anforderungen des Umfelds, in dem sie zum Einsatz kommen soll? – Erfüllt die Software die Sicherheitsanforderungen? – Wie ist die Berechtigungsverwaltung der Software aufgebaut? Können Benutzeraktivitäten zum Zwecke eines Auditings aufgezeichnet werden? – Werden Konfigurationsänderungen und Änderungen an Stammdaten protokolliert und interne Kontrollsysteme wirksam abgebildet? – Wie sehen die Schnittstellen der Software aus? Welche Möglichkeiten gibt es, die Software in einen größeren Anwendungs-Kontext zu integrieren? – Wie sind die Laufzeiten und das Antwortzeitverhalten der Software in realistischen Produktionsumgebungen? – An welchen Stellen und in welchem Umfang kann die Software über die Möglichkeiten des Standards hinaus an individuelle Gegebenheiten angepasst werden? c) Beurteilung des Datenmodells – Angaben zum Umfang des Datenmodells – Ist das Datenmodell normalisiert? d) Betrachtung der Produktqualität – Wie ist das Ablaufverhalten der Software? – Wie ist die Ergonomie zu beurteilen? – Entspricht die Bedienoberfläche dem Stand der Technik? – Arbeitet die Software erwartungskonform? – Ist die Software (weitgehend) fehlerfrei? – Anhand welcher Unterlagen kann das beurteilt werden? e) Beurteilung der Dokumentation – Woraus besteht die Anwenderdokumentation? Hoppen

1451

Q Rz. 212

Einzelprobleme

– Welchen Umfang hat sie? – Wird die Software in der Breite abgedeckt und in der Tiefe ausreichend beschrieben? – Entsprechen die Darstellungen den tatsächlichen Programmabläufen? – Wie sieht das Online-Hilfesystem aus? – Ist es gut in die Anwendung integriert? – Liefert es sinnvolle kontextbezogene Angaben? – Gibt es eine Verfahrensdokumentation? – Liefert diese Dokumentation ausreichende Hintergrundinformationen für die Einführung der Software in neuen Umgebungen? – Gibt es eine Softwareentwicklungs-Dokumentation? – Woraus besteht diese? – Ist sie systematisch aufgebaut? – Welche Phasen des Softwareerstellungsprozesses sind dokumentiert? – Gibt es ein einheitliches übergreifendes Rahmenwerk für die Dokumentation? f) Beurteilung der Wartbarkeit/Weiterentwickelbarkeit – Wie ist die technologische Basis? – Aus welchen Komponenten besteht die Software? – Wie ist die Systemarchitektur der Software? – In welcher/welchen Programmiersprachen wurde die Software entwickelt? – Wie erfolgt die Datenhaltung? – Wie sieht das Datenmodell aus? – Unter welchen Betriebssystem-, Datenbank- bzw. Applikations-Server-Plattformen sind die Komponenten der Software einsetzbar? – Welche sonstigen Systemvoraussetzungen müssen beim Betrieb erfüllt sein? – Welcher Einarbeitungsaufwand ist abzusehen? 3. Beurteilung des Quellcodes 212

Die Wartbarkeit der Software hängt entscheidend von der Qualität des Quellcodes ab. Insofern ist dieser bei der Bewertung von Software dezidiert zu betrachten, und zwar sowohl hinsichtlich seines (übergeordneten) grundsätzlichen Aufbaus (Systemarchitektur, vgl. Rz. 68 ff.) als auch hinsichtlich der konkreten Ausführung des Quellcodes (vgl. Rz. 74 ff.).

213

Als Checkliste können folgende typische zu klärende Aspekte genannt werden: – Bestehen Codierungsrichtlinien und wurden diese eingehalten? – Ist der Quellcode klar und einheitlich strukturiert? 1452

Hoppen

Rz. 215 Q

Bewertung von Software, Due Diligence, Compliance

– – – –

– – –

–

– Sind funktional abgeschlossene Programmabschnitte kurz und überschaubar gehalten? Wurden einheitliche Modellierungstechniken (Design Patterns) angewandt? Wie ist der Kommentierungsgrad? In welchen Sprachen wurden die einzelnen Komponenten entwickelt? Können die Entwickler einen guten Überblick über den Quellcode vermitteln? – Können die fachlichen Funktionsbereiche einfach identifiziert werden? – Gibt es eine saubere Trennung von Datenhaltung, Datenverarbeitung und Datenpräsentation? Wo ist fremder Quellcode, der Rechten Dritter unterliegt, eingeflossen? Enthält der Code Relikte, die nicht mehr von Relevanz sind (toter Code)? Wie ist der Quellcode historisch entstanden? – Liegt der Quellcode in historischen Versionen vor? – Gibt es alte Komponenten, die nicht in die aktuelle Entwicklungsumgebung portiert wurden? Sind wesentliche Änderungen am Quellcode vorgesehen bzw. in ihrer Notwendigkeit absehbar?

4. Beurteilung des Softwareentwicklungsprozesses Die Qualität eines Software-Produktes ist entscheidend von der Qualität des Prozesses der Softwareentwicklung (Software-Management) abhängig (vgl. Rz. 119 ff.).

214

Typische zu klärende Aspekte im Sinne einer Checkliste sind:

215

– Nach welchem Modell wurde im Projekt vorgegangen? – Wie viele und welche Entwickler waren und sind mit der Software betreut? – Welches Know-how ist in jüngster Zeit abgeflossen? – Welche besonderen Qualifikationen sind erforderlich? – Welche Entwicklungsstandards gibt es? – Wie sehen diese aus? – Wie erfolgt das Bug-Tracking? – Welche Angaben stehen zur Verfügung? – Können daraus Aussagen zum Reifegrad oder zu Tendenzen in der Fehlerentwicklung abgeleitet werden? – Gibt es eine QS-Zertifizierung, z.B. nach DIN/ISO 9001? – Finden Qualitätsaudits statt? – Gibt es einen Testplan mit Testfällen? – Wer definiert die Testfälle? In welcher Projektphase erfolgt das? Hoppen

1453

Q Rz. 216

Einzelprobleme

– Welche Bereiche der Software decken die Testfälle ab? – Gibt es Konzepte zu automatisierten Tests, Unit-Tests? – Wie werden die Quellcodes verwaltet? – Wie ist die Release-Planung? – Gibt es unterschiedliche Fassungen der Software in unterschiedlichen Installationen? 5. Abschätzung der Herstellkosten a) Ermittlung des Quellcodeumfangs 216

Bei einer retrospektiven Betrachtung einer selbst erstellten Software liegt der Quellcode in der Regel vor. Zunächst ist dann zu bestimmen, welche Programme zum Gesamtsystem gehören. Dabei sind nur die Module und Befehle zu berücksichtigen, die tatsächliche logisch wirksame Programmanweisungen darstellen. Kommentierungen bzw. nicht verwendete Programmteile sind nicht heranzuziehen, ebenso wie bestimmte Sprachkonstrukte, die keine eigenständigen Logik-Anweisungen darstellen, sondern der Gliederung des Programmcodes oder der Steuerung des Compiliervorgangs dienen. Grundsätzlich wird dabei von einer strukturierten Programmierung ausgegangen, die in der Regel einen Befehl pro Programmzeile enthält. Zur Ermittlung des Codeumfangs kann der IT-Sachverständige auf Tools zurückgreifen, die eine korrekte Ermittlung der logisch wirksamen Programmbefehle (sog. logical source lines of code SLOC1) vornehmen. Beispielsweise analysiert das an der University of Southern California (USC) entwickelte und frei im Internet verfügbare Werkzeugs UCC (unified code count2) in gängigen Programmiersprachen (darunter auch C++, Java und Python) die Programmzeilen und ermittelt die Anzahl logisch wirksamer Programmbefehle.

217

In manchen Fällen müssen andere Betrachtungen angestellt werden. Beispielsweise generieren manche Entwicklungsumgebungen Quellcode-Dateien, die lediglich automatisch generierte Zeilen mit Layout-Informationen von Oberflächenelementen enthalten. Der Aufwand für die Gestaltung von Oberflächenelementen ist in einem Schätzverfahren wie COCOMO bereits berücksichtigt, deswegen wird solcher Code bei der Ermittlung des Aufwandes in der Regel nicht mitgezählt. 1 Man unterscheidet zwischen physical lines of code, und logical lines of code. In einer physical line of code können prinzipiell mehrere Programmbefehle in einer Zeile stehen, umgekehrt kann sich ein Programmbefehl auch über mehrere Zeilen des Quellprogramms erstrecken. Insofern kann logisch identischer Programmtext bei unterschiedlichem Zeilenumbruch auf unterschiedliche physical lines of code erstrecken. Das muss bei der Bewertung ausgeklammert werden, für die Bewertung relevant ist daher die tatsächliche Anzahl der Programmbefehle oder logical lines of code. 2 S. http://sunset.usc.edu/research/CODECOUNT.

1454

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 222 Q

Ist die Anzahl der Programmbefehle (noch) nicht bekannt, so muss sie in 218 einer Hilfsrechnung näherungsweise anhand der Anzahl zu entwickelnder Programmfunktionen oder Prozeduren, sog. Function Points, ermittelt werden, worunter im Wesentlichen die Anzahl zu entwickelnder Programmfunktionen oder Prozeduren zu verstehen ist. Aus der Anzahl der Function Points kann dann – abhängig von der verwendeten Programmiersprache – der zu erwartende Quellcode-Umfang berechnet werden (vgl. Rz. 161 ff.). Eine solche Betrachtung kann auch dazu herangezogen werden, die Angemessenheit des Umfangs des Quellcodes zu plausibilisieren. b) Bestimmung des Entwicklungsaufwandes Bei der Abschätzung der Herstellkosten sind die Entwicklungsbedingungen 219 zu berücksichtigen, z.B. in Form der in dem COCOMO-Verfahren gewählten Projektmerkmale Neuartigkeit, Entwicklungsflexibilität, Risikovorsorge, Teamzusammenarbeit und Prozessreife. Es lässt sich dann ein Grundaufwand (nominal effort) ermitteln. Zu diesem Grundaufwand sind der Einfluss weiterer konkreter Anforderungen an die Softwarelösung, die Einsatzumgebung und die Fähigkeiten und Vorgehensweisen des Entwicklungsteams hinzuzurechnen. In dem COCOMO-Verfahren erfolgt dies in Form der Kostentreiberfaktoren (vgl. Rz. 166 ff.). Es ergibt sich dann der tatsächlich zu erwartende Entwicklungsaufwand (estimated effort). Die hier skizzierten Schätzverfahren der Informatik benötigen als Ein- 220 gabeparameter Grundangaben, die zunächst in initialen Projektphasen ermittelt werden müssen. Deswegen wird der zur Ermittlung dieser Angaben erforderliche Grundaufwand von den Modellen nicht bestimmt. In dem von dem COCOMO-Verfahren gelieferten Entwicklungsaufwand sind die Entwicklungsphasen Produktdesign (Grob- und Systemkonzept), Feinkonzept, Programmierung, Modul- und Integrationstests sowie die Einführungs- und Stabilisierungsphase enthalten, nicht jedoch die Anforderungsanalyse und Projektierung. Nach üblichen Erfahrungswerten ist hier ein Aufwand von 5 %–20 % des Gesamtprojektumfangs anzusetzen und hinzuzurechnen. Zur Berücksichtigung der immer mit einer Schätzung verbundenen Unge- 221 nauigkeiten empfiehlt es sich, auch Werte für ungünstige und günstige Szenarien und damit eine Bandbreite wahrscheinlicher Entwicklungsaufwände zu ermitteln. c) Berücksichtigung des Erfüllungsgrades bei der Bewertung unfertiger oder defizitärer Projekte In bestimmten Bewertungssituationen kann es Aufgabe sein, einen objektiven Ansatz für die Herstellkosten im aktuellen Zustand einer noch nicht abgeschlossenen Softwareentwicklung zu bestimmen. Ebenso kann es erforderlich erscheinen, bei der Analyse festgestellte Defizite in den Arbeitsergebnissen einzelner Projektphasen – z.B. unvollständige Dokumentationen – durch Abschläge in der Bewertung zu berücksichtigen. Hoppen

1455

222

Q Rz. 223 223

Einzelprobleme

Hier kann genauso vorgegangen werden, wie dies bisher dargestellt wurde, allerdings ist zusätzlich zu berücksichtigen, in welchem Umfang die einzelnen üblicherweise zu durchlaufenden Projektphasen bereits fertiggestellt sind bzw. welche Abzüge für die Berücksichtigung von Defiziten in den Arbeitsergebnissen einzelner Projektphasen anzusetzen sind. Als Daumengröße kann von folgenden Ansätzen in der Verteilung des Gesamtaufwandes ausgegangen werden1: Projektphasen

Prozentanteil

Analyse (Anforderungsanalyse und Projektierung) Spezifikation (Produktdesign, Grob- und Systemkonzept)

5–20 % 10–15 %

Entwurf (Feinkonzept)

10–20 %

Codierung (Programmierung)

20–25 %

Modul- und Integrationstests

25–40 %

sowie ggf. auch Einführungs- und Stabilisierungsphase Summe

100 %

224

Die Verteilung kann im Einzelfall variieren je nach Größe des Projekts und Art der Zusammenarbeit im Projektteam. In größeren Projekten wächst der Aufwand für Integrations- und Testaktivitäten. Das COCOMO-Modell unterscheidet hier zwischen Projekten im organic, semi-detached oder embedded Mode und den Projektgrößen small, intermediate, medium und large und liefert jeweils unterschiedliche Aufwandsverteilungen für diese Szenarien2.

225

Zur Ermittlung des Entwicklungsaufwandes ist zunächst der Fertigstellungsgrad in den einzelnen Bereichen zu ermitteln. Dazu ist zu prüfen, inwieweit die Arbeiten in den einzelnen Phasen ordnungsgemäß erbracht wurden. Hier ist jeweils ein Erfüllungsgrad zu bestimmen.

226

Der unter Anwendung eines Schätzverfahrens ermittelte Entwicklungsaufwand für die vollständige Erfüllung kann dann auf die einzelnen Projektphasen aufgeteilt und um den jeweiligen Erfüllungsgrad korrigiert werden.

227

Im Ergebnis liegt ein objektivierter Wert vor für den Entwicklungsaufwand, der betrieben werden müsste, um die unfertigen Arbeitsergebnisse – die z.B. bei einer Veräußerung übertragen werden könnten – wiederherzustellen. d) Einbezug von Personalkosten-Ansätzen

228

Die Bewertungsmodelle der Informatik liefern im Ergebnis Entwicklungsaufwendungen in Personentagen oder Personenmonaten. Um einen mer1 Vgl. z.B.Sneed, Software-Projektkalkulation, 2005, S. 27. 2 Boehm/Abts/Brown/Chulami/Clark/Horrowitz/Madachy/Reifer/Steece, ware Cost Estimation with Cocomo II, 1999.

1456

Hoppen

Soft-

Bewertung von Software, Due Diligence, Compliance

Rz. 233 Q

kantilen Wertansatz bzw. bilanzierungsfähigen Betrag zu erhalten, sind die ermittelten Entwicklungsaufwendungen, die ja Zeitaufwände darstellen, mit den Personalkosten zu bewerten. In den einzelnen Projektphasen werden in der Regel Personen unterschiedli- 229 cher Qualifikation eingesetzt. Hier ist im Einzelfall eine sinnvolle und dem Projekt gerecht werdende Zuordnung verfügbarer Personalkostenansätze zu den einzelnen Projektphasen vorzunehmen. Dabei sind Kostensätze anzusetzen – differenziert nach den einzelnen Projektphasen und unterschiedlichen Qualifikationen der beteiligten Mitarbeiter –, die in der Regel einem IT-Sachverständigen zugänglich sind, teilweise aber auch im Internet recherchiert werden können. In gängigen Veröffentlichungen von Personalkosten wird beispielsweise differenziert zwischen – – – –

IT-Leitung, IT-Systemhaus IT-Berater, Berufserfahrung 6–8 Jahre Softwareentwicklung, Berufserfahrung 6–8 Jahre Softwareentwicklung, Berufserfahrung 3–5 Jahre

Im Ergebnis sind damit die Herstellkosten der Softwareentwicklung abge- 230 schätzt. Auch hier bietet es sich an, in der Untersuchung verschiedene Szenarien und damit die Bandbreite möglicher Schätzergebnisse aufzuzeigen. e) Plausibilisierung anhand tatsächlicher Aufwandswerte Wenn das zu bewertende Softwareentwicklungsprojekt bereits umgesetzt 231 wurde, können die tatsächlich im Projekt angefallenen Personalkosten den abgeschätzten Herstellkosten gegenübergestellt werden. Dadurch lassen sich die Ergebnisse der Aufwandsschätzung plausibilisieren und in der Regel bestätigen. 6. Beurteilung kaufmännischer Aspekte (Nutzbarkeit, Vermarktbarkeit) Die Bestimmung des Verkehrswerts einer Software, die auch Dritten in Lizenz angeboten wird, erfordert die Berücksichtigung folgender kaufmännischer Aspekte.

232

a) Absatz- und Umsatzgrößen Der Ertragswert ergibt sich üblicherweise als Barwert der finanziellen Über- 233 schüsse, die bei Fortführung der Nutzung der Software erwirtschaftet werden. Er bestimmt sich allein aus der Ertragskraft, d.h. der Eigenschaft, finanzielle Überschüsse für den Inhaber der Software zu generieren1.

1 Diese Definition erfolgt in enger Anlehnung an die Definition des Unternehmenswerts in dem IDW Standard S1 i.d.F. 2008, s. dort Rz. 4.

Hoppen

1457

Q Rz. 234 234

Einzelprobleme

Insofern sind bei der Untersuchung folgende Größen zu ermitteln: – Installationsbasis und deren Entwicklung – Anzahl der vergebenen/installierten Lizenzen – aktuell – historisch (mindestens letzte 3 Jahre) – Unterschiedliche Ausprägungen der Lizenzen (Lizenzierungsmodell) – Einzelmodule – Regionale Preisdifferenzierungen – etc. – Umsatzentwicklung (mindestens letzte 3 Jahre) – differenziert entsprechend dem Lizenzierungsmodell/Preisliste – Absatz- und Umsatzprognose – Prognose der vergebenen Lizenzen – Prognose zur Preisentwicklung b) Konkurrenzsituation, Alleinstellungsmerkmale

235

Die Beurteilung historischer Umsatz- und Absatzzahlen und die Herleitung von Zukunftsprognosen daraus kann fundiert nur vor dem Hintergrund einer Markt- und Wettbewerbsanalyse vorgenommen werden. Es sind Informationen über die Marktpositionierung und die Vermarktbarkeit der Software einzuholen. Dies gilt insbesondere bei hohen Marktanteilen. Auch bei Änderungen in der Produktausrichtung oder einer aggressiveren Vermarktungskonzeption sind die Markt- und Wettbewerbssituation zu untersuchen. Dabei ist der Markt für die Software zu identifizieren und das Wettbewerbsumfeld mit den wichtigsten Akteuren zu analysieren. Dazu zählen Angaben zum Gesamtmarkt, Vertriebswegen, Referenzen und Angaben zu den wesentlichen Wettbewerbern. Es sind Leistungsvergleiche mit den Konkurrenzprodukten anzustellen und – sofern vorhanden – Alleinstellungsmerkmale zu identifizieren, die eine Marktposition absichern können. Zur Informationsgewinnung können auch Marketingunterlagen herangezogen werden.

236

Wenn im Einzelfall solche Untersuchungen nicht vorgenommen werden können oder auftragsgemäß nicht vorgenommen werden sollen, müssen Annahmen getroffen und bei der Beurteilung deutlich als solche herausgestellt werden. In der Regel wird man dann vom Status Quo und einer Fortschreibung der bisherigen Vermarktungserfolge ausgehen.

237

Unnötig anzumerken ist, dass der Funktionsumfang einer Software nicht das alleinige Entscheidungskriterium für den Markterfolg eines Softwareproduktes ist. Das gesamte Umfeld des Anbieters kann wirtschaftlich eine Rolle spielen. Einem kleinen Anbieter können Vermarktungshindernisse erwachsen, die allein in seiner Unternehmensgröße begründet sind. Insofern können sich Zukunftsprognosen und daraus abgeleitete Ertragswerte schon allein durch Übertragung auf größere, besser positionierte Anbieter, aber 1458

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 240 Q

auch durch entsprechende strategische Kooperation mit solchen Anbietern, verändern. c) Prüfung der Besitz- und Eigentumsverhältnisse Es ist zu prüfen, ob über die voll umfassenden, zeitlich und inhaltlich unbeschränkten Verwertungsrechte an der Software in allen ihren Bestandteilen verfügt werden kann (vgl. Kap. A Rz. 72 ff.). Eine Belastung der Software mit Rechten Dritter kann die weitere Verwertung erheblich einschränken oder gar verhindern und somit stark wertmindernd wirken.

238

aa) Identifizierung inkludierter Lizenzen und sonstiger Rechte Dritter, Open-Source-Komponenten Heute ist bei Software fast immer davon auszugehen, dass Softwarekom- 239 ponenten Dritter eingebunden sind, seien es kommerzielle Komponenten, freie Software oder Open-Source-Komponenten (OSS). Dies können sowohl Quellcodes (Libraries, Frameworks) als auch eigenständig funktionsfähige und ausführbare Programme sein, die als Objektcode eingebunden sind oder als externe Programme aufgerufen werden. Schon durch die Nutzung von Softwareentwicklungsumgebungen und Plug-Ins für diese Umgebungen können lizenzierungspflichtige und somit potentiell wertmindernde Komponenten mit Rechten Dritter in den Quell- oder Objektcode einfließen. Solche Softwarekomponenten sind vollständig zu bestimmen und aufzulis- 240 ten (vgl. Rz. 83 f.). Die jeweils geltenden Lizenzbedingungen sind anzugeben und daraufhin zu prüfen, ob die Einräumung oder Übertragung von Rechten an der Software hierdurch behindert wird1. Bei der Nutzung von kommerziellen Lizenzen oder Open-Source-Lizenzen mit Copyleft-Klausel (typische Vertreter sind GPL und LGPL), wird ein unbeschränkter proprietärer Vertrieb praktisch erheblich behindert oder gar verhindert. Unter der Copyleft-Klausel besteht das Risiko, dass die Integration von Open-Source-Komponenten die eigene Softwareentwicklung „infiziert“ und diese unter dieselben Lizenzbedingungen wie die Open-Source-Software zu stellen ist. Permissive Lizenzformen2 enthalten keine Copyleft-Klausel oder ähnliche Beschränkungen. Es kommt somit auf die jeweilige Lizenzform, aber auch auf die Art der Einbindung der Drittsoftware an. Z.B. kann die Integration von Open-SourceKomponenten auch bei Copyleft-Klauseln noch unkritisch sein, wenn sie als eigenständiges Subsystem integriert wird (sog. aggregate, Werkverbindung), aber kritisch werden, wenn sie enger in die eigene Softwareentwicklung eingebaut oder gar partiell modifiziert werden (sog. modification, 1 Zu den verschiedenen Open Source-Lizenzmodellen und ihren Auswirkungen auf die wirtschaftliche Verwendbarkeit vgl. Thalhofer, Commercial Usability of Open Source Software Licenses – To what extent can software governed by GNU or alternative licenses be commercially exploited?, Computer Law Review International (CRi), 2008, 129 ff. 2 Vor allem BSD- und MIT-Lizenzen sowie daraus abgeleitete Lizenzen.

Hoppen

1459

Q Rz. 241

Einzelprobleme

Werkbearbeitung). Werden fremde Objektcodes so eingebunden, dass sie erst dann zur Laufzeit in den Hauptspeicher geladen werden, wenn die Funktionalität benötigt wird – man spricht dann von dynamischer Verlinkung – kann dies u.U. unkritisch sei (z.B. unter der LGPL als combined work). Bei der Einbindung fremden Quellcodes – statische Verlinkung – kommt es darauf an, ob dieser unverändert übernommen wurde (unter der LGPL dürften sich dann bei Einhaltung einzelner konkreter Ziffern der LGPL noch keine einschränkenden Wirkungen ergeben). In allen Fällen der teilweisen oder modifizierten Verwendung fremden Quellcodes treten die Wirkungen der Copyleft-Klausel ein. Hier kann allenfalls durch geschickte Modularisierung eine Lokalisierung auf einzelne Module erreicht und ein Übergreifen auf den gesamten Quelltext verhindert werden (Stichwort: Minimalquelltext)1. 241

Bei der Bewertung sind hier mindestens entsprechende Erklärungen des Inhabers der Software einzuholen, in Zweifelsfällen ist der Sachverhalt kritisch zu prüfen. Es ist sicherzustellen, dass diese Softwarekomponenten aufgrund der jeweils zugrundeliegenden Open-Source-Lizenzen bzw. aufgrund von mit den jeweiligen Rechteinhabern abgeschlossenen Lizenzverträgen ohne Beschränkung für die Weiterentwicklung und den Vertrieb der Software genutzt werden können. Ansonsten sind Einschränkungen darzulegen und wertmindernd zu berücksichtigen. bb) Eigene Softwarekomponenten mit Rechteeinschränkungen

242

Wenn die Software Komponenten enthält, die der Entwickler auch in anderen Entwicklungsprojekten – vielleicht bei anderen Kunden – genutzt oder vermarktet hat oder in Zukunft zu nutzen beabsichtigt, ergeben sich hieraus auch Aspekte, die eine freie Verwertung der Software verhindern oder am Markt störende Effekte bewirken können.

243

Das gleiche gilt, wenn zur Pflege und Fortentwicklung der Software proprietäre Softwarekomponenten erforderlich sind, die der Erwerber bei einem Besitzübergang nicht oder nur mit eingeschränkten Nutzungsrechten erhält und die er sich nicht frei am Markt beschaffen kann. Eine solche Situation kann vorliegen, wenn die Komponenten proprietär sind und von dem Softwareentwickler geschaffen wurden.

244

Diese Aspekte sind durch entsprechende Erklärungen des Inhabers der Software abzusichern und ggf. wertmindernd zu berücksichtigen. cc) Patente

245

Liegt für Funktionsprinzipien der Software, die über den konkreten Programmcode hinausgehen oder für technische Verfahren, auf denen die Software beruht, ein patentrechtlicher Schutz vor, sichert dies Alleinstellungs1 S. weiterführend Hoppen/Thalhofer, Der Einbezug von Open Source-Komponenten bei der Erstellung kommerzieller Software, CR 2010, 275 ff.

1460

Hoppen

Rz. 248 Q

Bewertung von Software, Due Diligence, Compliance

merkmale der Software ab. Dieser Aspekt kann in die Beurteilung von Absatz- und Umsatzprognosen einfließen und damit indirekt werterhöhend wirken. dd) Software-Escrowing In manchen Fällen ist die entwickelte Software nebst ihrer Entwicklungsdokumentation bei einer unabhängigen Stelle hinterlegt (Software-Escrowing). Für die Bewertung kann dies unter folgenden Aspekten relevant sein:

246

– Die Hinterlegungsstelle kann mit der Annahme qualitätssichernde Maßnahmen, insbesondere Konsistenz- und Identitätsprüfungen, vorgenommen haben, die bei der Bewertung aufgegriffen werden können. – Die Bedingungen, unter denen die Hinterlegungsstelle die Software an Dritte herausgeben wird, sind zu klären und hinsichtlich wertmindernder Risiken zu prüfen. d) Berücksichtigung geplanter und erforderlicher Maßnahmen Schließlich sind in die Bewertung wesentliche Maßnahmen oder zu erwartende Änderungen an der Software einzubeziehen, die den Wert der Software negativ beeinflussen könnten. Hierzu ist zu prüfen,

247

– inwieweit Module oder Funktionsbereiche der Anwendung fachlich irrelevant sind und aus dem Produkt entfernt werden sollten, – funktionale Defizite bestehen oder kurz- bis mittelfristig absehbar sind – z.B. aufgrund gesetzlicher Änderungen – die einer Vermarktung entgegenstehen und unbedingt die Entwicklung neuer Module oder Funktionsbereiche erforderlich machen, – sonstige Mängel bekannt sind – z.B. Fehler – die kurzfristig beseitig werden müssen oder – etwa Rückstellungen für Gewährleistungsansprüche gebildet wurden. 7. Ertragswertorientierte Ermittlung des Verkehrswerts Der Wert einer Software in Analogie zu dem Wert eines Unternehmens 248 wird durch deren Eigenschaft bestimmt, finanzielle Überschüsse zu erzielen bzw. deren Erwirtschaftung in einem Unternehmen zu ermöglichen; „Der Wert eines Unternehmens …“ bzw. der Software „… bestimmt sich unter der Voraussetzung ausschließlich finanzieller Ziele durch den Barwert der mit dem Eigentum an dem Unternehmen verbundenen Nettozuflüsse an die Unternehmenseigner (Nettoeinnahmen als Saldo von Ausschüttungen bzw. Entnahmen, Kapitalrückzahlungen und Einlagen“1. Dieser Wert ergibt sich dabei „grundsätzlich aus den finanziellen Überschüssen, die bei Fort-

1 Institut der Wirtschaftsprüfer, IDW Standard S 1, Rz. 4.

Hoppen

1461

Q Rz. 249

Einzelprobleme

führung des Unternehmens und Veräußerung etwaigen nicht betriebsnotwendigen Vermögens erwirtschaftet werden (Zukunftserfolgswert)“1. 249

Eine Wertuntergrenze für die Software stellt der Liquidationswert dar, der bei einem Abbruch der unternehmerischen Tätigkeit und Abwicklung der vorhandenen Verträge zu erzielen wäre, ggf. nach Abzug entsprechender, mit der Liquidation verbundener Kosten.

250

Der Liquidationswert einer Software bei einem unmittelbaren Abbruch der Verwertungskonzeption besteht im Wesentlichen aus Wartungsgebühren, die sich auch nach Abbruch aller Entwicklungsaktivitäten noch über einen gewissen Zeitraum erzielen lassen und die auch einem Erwerber der Software zufließen würden. Den Wartungsgebühren sind Personalkosten entgegenzustellen, um die Wartungsverpflichtungen vertragsgemäß erfüllen zu können. Ebenfalls zu berücksichtigen ist ein evtl. durch die Veräußerung bzw. anderweitige Verwertung der Quellprogramme (in Teilen oder im Ganzen, z.B. der Frameworks) erzielbarer Erlös. Ein Erwerber der Software könnte auch an der Übernahme des Kundenstammes interessiert sein, um diesen mit seinen eigenen Produkten und in seinem Dienstleistungsgeschäft betreuen zu können. Zur wertmäßigen Berücksichtigung dieses Aspekts kann ein bestimmter Anteil des Deckungsbeitrages aus dem Dienstleistungsumsatz des letzten Jahres angesetzt werden.

251

Eine Wertobergrenze für die Software stellen die Kosten einer vollständigen Neuentwicklung – zuzüglich der Opportunitätskosten für die sofortige Verfügbarkeit der Software – dar. Als Alternative zu dem Erwerb der Software wird ein potentieller Erwerber nämlich die Kosten einer Neuentwicklung in Betracht ziehen (Make or Buy-Entscheidung). Bei einer Neuentwicklung wird er zusätzlich die Kosten der Markteinführung sowie die Kosten eines späteren Markteintritts zu berücksichtigen haben.

252

In diesem Sinne sind bei der Bestimmung des Wertes einer Software sowohl die Herstellungskosten (Entwicklungsaufwand der Software) als auch die mit dem Eigentum an der Software erzielbaren Nettozuflüsse (Zahlungsströme) zu betrachten. Ein Ertragswert kann als Barwert (vgl. Rz. 196 ff.) der aus der Verwertung der Software bei fortgeführtem Unternehmenskonzept wahrscheinlich zu erzielenden finanziellen Überschüsse bestimmt werden und liefert einen möglichen Kaufpreis für die Buy-Variante, der den Herstellungskosten im Make-Szenario gegenüberzustellen ist. Die Überschüsse werden dabei als die Differenz zwischen Erlösen und Kosten ermittelt. Die so ermittelten Überschüsse werden auf den Bewertungsstichtag diskontiert. a) Annahme einer begrenzten Lebensdauer

253

Bei dem zu bewertenden Wirtschaftsgut Software ist naturgemäß von einer begrenzten Lebensdauer auszugehen. Der anzusetzende Wert für die Le1 Institut der Wirtschaftsprüfer, IDW Standard S 1, Rz. 5.

1462

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 258 Q

bensdauer ist immer im Einzelfall zu bestimmen. Aufgrund der hohen Marktdynamik in der Informationstechnologie wird es nur in Ausnahmefällen angemessen sein, einen Betrachtungszeitraum von 10 oder mehr Jahren anzusetzen. Auch bei einer kontinuierlichen Fortentwicklung der Software erscheint es 254 nur bei besonders fundierter Begründung angemessen, einen längeren Betrachtungszeitraum zu wählen. Erfahrungsgemäß wird die Software im Laufe der Zeit immer schwieriger wartbar, hinzu kommen exogene technologische Entwicklungen, die eine Software auch bei kontinuierlicher Wartung „altern“ lassen. Aus praktischen Erwägungen heraus ist es häufig sinnvoll, den Betrachtungszeitraum in zwei Phasen aufzuteilen, die unterschiedlich geplant werden. Für die näherliegenden Jahre (i.d.R etwa 3 bis max. 5 Jahre, je nach Planungshorizont des Unternehmens) werden Einzelplanansätze gebildet, deren Entwicklung im Einzelnen erläutert und begründet werden kann. Für die darauffolgenden Jahre des Betrachtungszeitraums wird eine Fortführung des Geschäfts auf dem Niveau des zuletzt im Detail geplanten Jahres angenommen.

255

Nimmt man – entgegen den obigen Ausführungen – eine ewige Rente an, 256 sind Aufwendungen zum Erhalt der Softwaresubstanz in einer Höhe anzusetzen, die Reengineering und Überführungen in neue technologische Umgebungen umfasst, was in der Praxis früher oder später mit einer Neuentwicklung der Software verbunden ist. Angesichts der kaum langfristig prognostizierbaren technischen Entwicklung dürften solche Schätzungen mit erheblichen Unsicherheiten behaftet sein. Der Wert der Software bestimmt sich als Summe aus

257

– dem Barwert der zu erwartenden finanziellen Überschüsse in der Restnutzungszeit (Betrachtungszeitraum) und – dem Barwert der danach bei Aufgabe der Softwareweiterentwicklung noch zu erzielenden Überschüsse (Rest- oder Liquidationswert)1. b) Zu betrachtende Erlös- und Kostenarten Die bei der Bewertung zu berücksichtigenden Erlöse umfassen in der Regel – Lizenzumsätze (Neulizenzen sowie Erweiterungs- oder Zusatzlizenzen bei vorhandenen Kunden), 1 Institut der Wirtschaftsprüfer, IDW Standard S1 i.d.F. 2008, Rz. 87: „Bei begrenzter Lebensdauer des zu bewertenden Unternehmens ist der Unternehmenswert zu berechnen als Summe aus dem Barwert der künftigen finanziellen Überschüsse aus dem betriebsnotwendigen Vermögen (bis zur Aufgabe des Unternehmens), dem Barwert der künftigen finanziellen Überschüsse aus dem nicht betriebsnotwendigen Vermögen (bis zur Aufgabe des Unternehmens) und dem Barwert der künftigen finanziellen Überschüsse, die aus der Aufgabe (z.B. der Liquidation) des Unternehmens resultieren.“

Hoppen

1463

258

Q Rz. 259

Einzelprobleme

– Dienstleistungsumsätze im Zusammenhang mit der Lizenzvergabe (Planung, Installation, Anpassung, Einführung, Inbetriebnahme, Schulung), – Wartungsumsätze und – sonstige erzielbare Erlöse (zunehmend häufiger und vor allem zukünftig wird eine Software günstig bzw. kostenlos zur Verfügung gestellt und der Nutzen ergibt sich aus kostenpflichtigem Content). 259

Die geplanten Erlöse lassen sich nur erzielen, wenn dementsprechend Aufwendungen von – – – –

Vertrieb, Produktmarketing, allgemeine Verwaltung, Hotline, Wartung, Erbringung der fakturierten Dienstleistungen und Weiterentwicklungen am Standard

betrieben werden. Diese sind bei der Wertermittlung zu berücksichtigen. 260

In der Praxis hat sich bewährt, zur Verprobung und Plausibilisierung die Absätze und Umsätze der Vergangenheit zu analysieren und daran angelehnt ein Kosten- und Erlös-Modell für die Fortschreibung der Zahlen in den Betrachtungszeitraum hinein zu entwickeln.

261

Dieser Ansatz ist allerdings ungeeignet bei relativ neu am Markt eingeführter Software. Hier kann die Planung nur zukunftsgerichtet erfolgen. Dabei sind Blasen („Wolkenkuckuksheim“ bei Start-Up-Planungen) zu vermeiden bzw. einer besonderen Validierung und Begründung zuzuführen. Zu beachten sind ggf. erkennbare Marktsättigungsgrade, es ist zu erläutern, wo positive Ertragsentwicklungen herkommen können (z.B. neue Märkte, Umsatzanteile von Wettbewerbern aufgrund besseren Produkts, neue Softwareanwendung).

262

Der Lizenzbestand erhöht sich jährlich um die neu vergebenen Lizenzen und verringert sich – jedenfalls im Wartungsgeschäft – um die aufgekündigten Lizenzen. Insofern sind die Bestandszahlen und die jährlichen Zu- und Abgänge zu ermitteln, entsprechend der Produkt- und Preis-Struktur des Lizenzgebers. Je nach Art der Software kann es erforderlich sein, Übertragungen von Gebrauchtlizenzen bei der Bestimmung der Entwicklung des Lizenzbestands zu berücksichtigen. Sofern eine Lizenzierung als Software as a Service (SaaS) erfolgt, vergleichbar mit einem Mietmodell, ergeben sich aus dem Bestand jährliche Lizenzumsätze. Auf der Kostenseite können sich komplementäre Kosten ergeben, wenn die Lizenzierung über Reseller o.Ä. erfolgt.

263

Dienstleistungsumsätze stehen in der Regel in einem direkten Zusammenhang mit dem Bestand der vergebenen Lizenzen bzw. – soweit sie aus Implementierung und Roll-Out herrühren und insoweit nicht ständig wiederkehrend sind – mit dem Bestandszuwachs der vergebenen Lizenzen.

1464

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 267 Q

Die Beziehungen können aus historischen Daten abgeleitet und für die Zu- 264 kunft fortgeschrieben werden. Dabei ist zu differenzieren zwischen Dienstleistungen mit Neukunden und Dienstleistungen für Bestandskunden. Beispielsweise kann zu jedem Umsatz in der Neulizenzierung mit einem entsprechenden Dienstleistungsumsatz für Implementierungsleistungen gerechnet werden. Dienstleistungsumsätze im Bestandskundengeschäft lassen sich meistens gut anhand historischer Zahlenreihen prognostizieren. Wartungsgebühren werden üblicherweise aus Verträgen generiert, die mit 265 den Kunden abgeschlossen werden, um Fehler in der Software zu beseitigen und die Software funktional fortzuentwickeln. Der Bestand an Wartungsgebühren erhöht sich insofern jährlich um einen prozentualen Anteil am Neulizenz-Umsatz und verringert sich um wegfallende Kunden. Übertragungen von Gebrauchtlizenzen sind bestandsneutral. Realistische, marktübliche und nachhaltig realisierbare Wartungsgebührensätze liegen bei 12–18 % der Lizenzkosten p.a.1. Aus diesem Budget wird in der Regel die Weiterentwicklung von internen Basiskomponenten der Software (Frameworks etc.) und die Vornahme zwingend gesetzlich vorgeschriebener fachlicher Änderungen finanziert. Auch hier lassen sich konkrete Vergangenheitswerte von Kosten und Erlösen ermitteln und in dem Modell für die Zukunft fortschreiben. Weitergehende fachliche Weiterentwicklungen werden häufig durch Kundenprojekte finanziert und führen zu Dienstleistungsumsätzen. Auf der Kostenseite sind Ansätze für den Vertrieb der Software, das Pro- 266 duktmarketing sowie allgemeine Verwaltungsarbeiten zu ermitteln, die den sich aus der Verwertung der Software ergebenden Erlösen oder Zahlungsströmen zwingend zuzurechnen sind. Diese können in einem bestimmten Verhältnis zu den Lizenzumsätzen stehen und entsprechend in dem Kostenund Erlös-Modell geplant werden. Zudem sind Kosten für den Betrieb einer Hotline und die Erfüllung der Verpflichtungen aus dem Wartungsvertragsgeschäft anzusetzen. Den Erlösen aus dem Dienstleistungsgeschäft sind die Kosten aus dem damit verbundenen Personaleinsatz entgegenzurechnen. Hier können in der Regel anhand des Verhältnisses der internen Kosten zu extern fakturierten Kostensätzen genaue Abschätzungen vorgenommen werden. Das jährliche Ergebnis und der daraus ableitbare Zahlungsstrom ergeben 267 sich aus der Differenz zwischen Erlösen und Kosten. Bei der Bestimmung des Barwerts wird davon ausgegangen, dass dieser jährlich am Periodenende zur Verfügung steht.

1 Bei update-intensiver Software werden auch deutlich höhere Sätze verlangt, z.B. bei Lohnabrechnungsprogrammen.

Hoppen

1465

Q Rz. 268

Einzelprobleme

c) Betrachtung verschiedener Szenarien 268

Alle zukunftsbezogenen Bewertungen basieren naturgemäß auf unsicheren Erwartungen. Angesichts der Vielzahl zu betrachtender Faktoren und der dynamischen technologischen Entwicklungen bestehen Risiken sowohl in der Unsicherheit der Prognose zukünftiger Erfolge als auch bei der richtigen Wahl der Kapitalisierungsparameter. Es bietet sich daher an, mehrwertige Planungen zu unterschiedlichen Szenarien vorzunehmen, um die Ergebnisbandbreite bei Variation einzelner Einflussfaktoren und damit das Ausmaß der Unsicherheit der künftigen finanziellen Überschüsse zu verdeutlichen.

269

Beispielsweise können für Annahmen hinsichtlich – – – – –

einer Steigerung der Lizenzumsätze im Neugeschäft, eines Anteils der Dienstleistungsumsätze am Neugeschäft, Zugängen und Abgängen im Wartungsgeschäft, Kosten für Vertrieb, Produktmarketing und allgemeine Verwaltung sowie Personalkostenansätzen

jeweils ein neutrales, optimistisches und pessimistisches Szenario betrachtet und die sich bei Variation der zugrundeliegenden Parameter ergebenden Schwankungsbreiten angegeben werden (Sensitivitätsanalyse). 270

Bei der Gesamtbetrachtung ist damit zu rechnen, dass zwischen den Unsicherheiten der einzelnen Annahmen kompensatorische Einflüsse wirksam werden, da erfahrungsgemäß manche unvorhergesehenen negativen Einflüsse durch ebenfalls unvorhergesehene positive Einflüsse kompensiert werden. d) Wahl des Kapitalisierungszinssatzes

271

In die Ermittlung des Barwerts fließt maßgeblich ein Kapitalisierungszinssatz ein, der in der Höhe so zu bemessen ist, dass er die Rendite einer fristenkongruenten Alternativanlage mit vergleichbaren Chancen und Risiken abbildet. Die nach den vorstehenden Ausführungen ermittelten Ergebnisse sind mit dem Kapitalisierungszinssatz auf den Bewertungsstichtag abzuzinsen. Durch die Abzinsung der erwarteten Überschüsse sollen die Erfolge der Software mit den Überschüssen einer entsprechenden alternativen Investition verglichen werden können. Die gegenüber einer Anlage am Kapitalmarkt vergleichsweise höheren generellen Unternehmerwagnisse werden durch Modifizierung des Kapitalmarktzinssatzes berücksichtigt (Zinszuschlagsmethode1).

272

Bei der Festlegung des Kapitalisierungszinssatzes sind drei Komponenten zu berücksichtigen: Basiszinssatz, Wachstumsabschlag und Risikozuschlag. 1 Vgl. Institut der Wirtschaftsprüfer, IDW Standard S1 i.d.F. 2008, Rz. 88 ff. (6.2). Alternativ wird das Risiko in der Bemessungsgrundlage abgebildet; dann kein Risikozuschlag mehr.

1466

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 277 Q

aa) Basiszinssatz Ausgangspunkt für die Ermittlung des anzuwendenden Kapitalisierungs- 273 zinssatzes ist der sog. Basiszinssatz als der landesübliche Zinssatz für eine (quasi-)risikofreie Kapitalmarktanlage. Er kann aus der Durchschnittsrendite marktgängiger und fristadäquater inländischer öffentlicher Anleihen abgeleitet werden, z.B. entnehmbar der Zinsstrukturkurve für Bundesanleihen. Von der aktuellen Zinssituation kann nicht zwangsläufig auf die zukünftig zu erwartende Verzinsung geschlossen werden. Erwartete Entwicklungen können dargelegt und in die Berechnungen einbezogen werden.

274

bb) Wachstumsabschlag Grundsätzlich ist der Kapitalisierungszinssatz um inflationsbedingte Preis- 275 steigerungen zu bereinigen, wenn die Schätzung der künftigen Erträge in realen Größen und auf Grundlage des Geldwertes zum Bewertungsstichtag vorgenommen wird. Die tatsächliche Berücksichtigung ist im Einzelfall zu prüfen; der gewählte Basiszinssatz kann auch bereits eine Geldentwertungsprämie enthalten1. Außerdem kann in den meisten Fällen nicht gesichert davon ausgegangen werden, dass die erzielbaren Überschüsse aus der Softwareverwertung mit der jährlichen Geldentwertung wachsen können. Schon deswegen erscheint es bei der Bewertung von Software angebracht, auf eine weitergehende Berücksichtigung des Inflationssatzes durch einen Abschlag vom Kapitalisierungszinssatz zu verzichten. cc) Risikozuschlag Ein wesentlicher Aspekt bei der Bestimmung eines Kapitalisierungszinssat- 276 zes für die Bewertung von Software ist, dass die künftigen finanziellen Überschüsse aufgrund der Ungewissheit der Zukunft insbesondere in der dynamischen IT-Branche kaum mit Sicherheit prognostiziert werden können. Softwareentwicklung und die Verwertung von Software stellen unternehmerische Engagements dar, die mit besonderen Risiken und Chancen verbunden sind. Deswegen müssen die Anlagealternativen auch hinsichtlich ihrer Risiken äquivalent sein, abgestimmt nicht auf die subjektive Risikoneigung eines bestimmten Investors, sondern auf das allgemeine Verhalten des Marktes. Investitionen in informationstechnische Systeme allgemein und in komplexe Einheiten wie Software im Speziellen sind als besonderes Risiko zu sehen. Zur Herstellung der Vergleichbarkeit der Anlagealternativen ist ein deutlicher Zuschlag zum Kapitalmarktzins notwendig.

1 Dies ist beispielsweise bei festverzinslichen Anleihen der Fall, weil diese als Nominalwerte in vollem Umfang der Geldentwertung unterliegen.

Hoppen

1467

277

Q Rz. 278 278

Einzelprobleme

Eine zusätzliche Risikoprämie kann erforderlich werden, wenn dem Umstand Rechnung getragen werden soll, dass es sich um ein kleines bzw. mittleres Unternehmen handelt, bei dem der Fortbestand bei größeren Schwankungen der konjunkturellen Lage einem höheren Risiko unterliegt (starke personenbezogene Bindung hinsichtlich eines Know-how-Trägers). e) Sonstige wertbeeinflussende Faktoren

279

Wenn in der technischen Bewertung besondere wertbeeinflussende Sachverhalte als Aufwendungen erkannt wurden, die entweder bei dem Inhaber oder bei dem Erwerber noch zur Sicherstellung der Übertragbarkeit der Ertragskraft1 zu erbringen sind – z.B. aufgrund einer erschwerten Wartbarkeit der Software (vgl. Rz. 222 ff.) –, sind diese in der Wertermittlung als gesonderter Abschlag zu berücksichtigen. f) Restwert am Ende der Lebensdauer der Software

280

Am Ende der Lebensdauer der Software verbleibt ein Restwert in Form der Wartungsgebühren aus noch laufenden Wartungsverträgen, die sich auch nach Abbruch aller Entwicklungsaktivitäten noch über einen gewissen Zeitraum erzielen lassen, nämlich solange, wie eine Betreuung verbliebener Kunden, die trotz Abkündigung noch nicht auf eine andere Lösung umgestellt haben, noch wirtschaftlich durchführbar ist. Es ist natürlich mit Abkündigung der Software davon auszugehen, dass die Mehrzahl der Kunden rechtzeitig eine neue Lösung etablieren wird.

281

Zur Berücksichtigung des Restwertes können die Wartungsgebühren über einen begrenzten Zeitraum bei einem Teil des Kundenstamms angesetzt werden (Berücksichtigung der Abschmelzverluste). In entsprechendem Umfang sind diesen Wartungsgebühren die Personalkosten entgegenzustellen, um die, wenn auch geringer werdenden, Wartungsverpflichtungen vertragsgemäß erfüllen zu können.

282

Bei größeren Installationsbasen können sich in diesem Posten nicht zu vernachlässigende Werte ergeben. g) Darstellung von Ausmaß der Unsicherheit und Ergebnisbandbreite der Bewertung

283

Es empfiehlt sich grundsätzlich, die Ergebnisbandbreiten bei Variation einzelner Bewertungsparameter in verschiedenen Szenarien aufzuzeigen2. Anhand solcher Angaben kann das Ausmaß der Unsicherheit der künftigen finanziellen Überschüsse veranschaulicht werden und es können Anhalts1 IDW Standard S1 i.d.F. 2008, Rz. 38: „Bei der Ermittlung des objektivierten Unternehmenswerts ist die dem Unternehmen innewohnende und übertragbare Ertragskraft zu bewerten.“ 2 Institut der Wirtschaftsprüfer, IDW Standard S1, Rz. 80.

1468

Hoppen

Bewertung von Software, Due Diligence, Compliance

Rz. 284 Q

punkte für die Berücksichtigung der Unsicherheit im Rahmen des Bewertungskalküls gegeben werden. Die sich bei Variation einzelner Bewertungsparameter ergebenden Ertragswerte können beispielsweise tabellarisch aufgezeigt werden. Bei gleichzeitigem Eintreten aller pessimistischen Annahmen wird der Er- 284 tragswert natürlich ganz erheblich sinken, bei Eintreten aller optimistischen Annahmen entsprechend massiv steigen. Solche Extremszenarien sind allerdings unwahrscheinlich. Vielmehr kann davon ausgegangen werden, dass unvorhergesehene negative Einflüsse durch ebenfalls unvorhergesehene positive Einflüsse kompensiert werden, auch wenn sich grundsätzlich in der Sachverständigentätigkeit die Aufrechnung von Ungenauigkeiten im Ausgangssachverhalt verbietet.

Hoppen

1469

R. Leasing bei Softwareerstellungsprojekten (IT-Projektleasing) Rz. I. 1. 2. 3.

Einleitung . . . . . . . . . . . . . . . . . . . Leasingvertrag . . . . . . . . . . . . . . . Begriff des IT-Projektleasings . . Grundlegende Besonderheiten des IT-Projektleasingvertrags . .

II. Rechtliche Einordnung von IT-Projektleasingverträgen . . . . 1. Rechtsnatur des Finanzierungsleasings im Allgemeinen . 2. Rechtsnatur des IT-Projektleasings (Regelfall). . . . . . . . . . . . 3. Fallgestaltungen, in denen der Leasingnehmer als Eigentümer des Leasingobjekts gelten kann . . . . . . . . . . . . . . . . . . . . . . . . a) Steuerliche Vorgaben zur Eigentümerstellung . . . . . . . . b) Eigentümerstellung nach steuerlichen Vorgaben im Fall des Spezialleasings . . . . . III. Besonderheiten bei IT-Projektfinanzierungsleasing. . . . . . . . . . 1. Hauptleistungspflichten . . . . . . a) Hauptleistungspflichten des Leasinggebers. . . . . . . . . . . . . . aa) Überlassung des Leasingobjekts zur Nutzung

1 1 2 5 12 12 15

19 22

28 31 31 31 31

Rz. bb) Beschaffungspflicht und deren Grenzen . . . . . . . . . . cc) Belassen des Leasinggutes beim Leasingnehmer/Keine Verantwortlichkeit für Störungen durch den Lieferanten . . . dd) Entrichtung der vereinbarten Vergütung/Abnahme aus dem IT-Projektvertrag . . . . . . . . . . . . . b) Hauptleistungspflichten des Leasingnehmers. . . . . . . . . . . . aa) Abnahme als Erfüllungsgehilfe des Leasinggebers bb) Abgabe einer Übernahmebestätigung . . . . . . . . . . cc) Zahlung der Leasingraten . . . . . . . . . . . . . . . . . . 2. Regelungen zur Risikoverteilung in AGB . . . . . . . . . . . . . . . . . a) Übernahmeerklärung . . . . . . . b) Sach- und Preisgefahr . . . . . . . c) Mangelhaftungsrechte . . . . . . d) Instandhaltungspflicht. . . . . . e) Gekoppelte Übernahmeund Wiedereintrittsklauseln. 3. Rechtseinräumung . . . . . . . . . . .

32

37

39 41 41 44 49 54 54 55 56 58 59 68

I. Einleitung 1. Leasingvertrag Unter einem Leasingvertrag1 wird i.d.R. die dem Leasingnehmer gewährte 1 Gebrauchsüberlassung eines Gegenstandes durch den Leasinggeber gegen (ratenweise) Zahlung einer Gebühr vereinbart. Unterschieden wird zwischen Finanzierungs-, Hersteller- und Operating-Leasing: – Finanzierungsleasing: Das Finanzierungsleasing ist durch ein Dreiecksverhältnis gekennzeichnet2. Der Finanzierungsleasingvertrag ist ein lang1 Grundlegende Literatur über Leasing vgl. Graf von Westphalen et al. (Hrsg.), Der Leasingvertrag. 2 BGH v. 19.2.1986 – VIII ZR 91/85, CR 1986, 458 = NJW 1986, 1744; Wolf, JuS 2002, 335.

Gennen

1471

R Rz. 2

Einzelprobleme

fristiger Vertrag, bei dem die Finanzierungsfunktion im Vordergrund steht. Der Leasinggeber beschafft das Leasingobjekt von einem Dritten und überlässt dem Leasingnehmer den Gebrauch hieran. Das Eigentum verbleibt beim Leasinggeber1. Es wird i.d.R. eine feste Grundmietzeit vereinbart, während der der Leasingnehmer die Deckung der vom Leasinggeber zu tragenden Kosten (Anschaffungs-, Herstellungs-, Finanzierungs- und Nebenkosten) nebst Verzinsung des eingesetzten Kapitals und Gewinnzuschlag herbeiführt2, sog. Vollamortisation. Beim Teilamortisationsvertrag werden die Kosten des Leasinggebers durch die Raten des Leasingnehmers nur zum Teil gedeckt. – Herstellerleasing: Beim Herstellerleasing fehlt das Dreiecksverhältnis. Das Leasingobjekt wird unmittelbar vom Hersteller oder Händler dem Leasingnehmer bereit gestellt3. – Operating-Leasing: Beim Operating-Leasing steht die Nutzungsüberlassung im Vordergrund, nicht die Finanzierung4. Das Objekt wird meist mehrfach nacheinander verleast bzw. im Rechtssinne vermietet. Der Leasingvertrag kann sehr kurzfristig ausgestaltet sein, der Leasingnehmer ist meist berechtigt, den Leasingvertrag jederzeit bzw. sehr kurzfristig zu kündigen5. 2. Begriff des IT-Projektleasings 2

Eine Möglichkeit der Fremdfinanzierung eines (Individual-)Softwareerstellungsprojektes ist die Finanzierung über Leasing. Leasingobjekt ist dabei eher selten lediglich die in einem Projekt zu erstellende (Individual-)Software (Computerprogramm einschließlich Dokumentation); zumeist werden etwa auch zum Projekt gehörende Standardsoftware und Hardware geleast; ferner werden sonstige Personalleistungen, sofern sie keinen zu großen Umfang einnehmen, ebenfalls vom Leasing erfasst. Deswegen wird vielfach von „IT-Projektleasing“ gesprochen. Dieser Begriff wird auch nachstehend durchgängig verwendet. Verstanden wird unter IT-Projektleasing daher eine Fallgestaltung, in der ein Anwender, der spätere Leasingnehmer, die Erstellung/Beschaffung einer Individualsoftware bzw. einer IT-Lösung bei einem oder mehreren Lieferanten beauftragt und ein Dritter, der spätere Leasinggeber, nach Zustandekommen des Erstellungs-/Beschaffungsvertrages auf Auftraggeberseite an die Stelle des Anwenders tritt und damit selbst Vertragspartner des/der Lieferanten im Erstellungs-/Beschaffungsvertrag wird. Zwischen dem Anwender/Leasingnehmer und dem Dritten/Leasinggeber wird ferner (gleichzeitig) der Leasingvertrag abgeschlossen und mithin ver1 Vgl. zur steuererlasskonformen mietrechtlichen Einordnung des Vertrages Rz. 13 ff.; Vollamortisationserlass BStBl. 1971 I S. 264, II 1. a)/b). 2 FG Hamburg DStRE 2010, 687. 3 AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 28. 4 AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 11. 5 BGH v. 11.3.1998 – VIII ZR 205/97, MDR 1998, 648 m. Anm. Friedrich = NJW 1998, 1637.

1472

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 6

R

einbart, dass der Dritte dem Anwender die zu erstellende IT-Lösung nach ihrer Fertigstellung im Rahmen eines Dauerschuldverhältnisses auf Zeit zur Nutzung überlässt. Denkbar ist auch eine Konstellation, in der der Leasinggeber nicht erst später in den Erstellungs-/Beschaffungsvertrag eintritt, sondern unmittelbar Vertragspartner des Herstellers wird. Ebenso ist Herstellerleasing denkbar. Im Gegensatz zu Leasingverträgen über fertige Produkte ist jedoch beim IT- 3 Projektleasing (mindestens teilweise) kein bereits fertiges Produkt Leasingobjekt, sondern (mindestens teilweise) eine noch herzustellende oder anzupassende Softwarelösung. IT-Projektverträge bzw. Softwareerstellungsverträge sind, schon wegen der 4 vorzunehmenden Anpassungs- und Programmierarbeiten und der sich an die Übergabe in den Betrieb anschließenden (jahre-)langen Nutzung, auf Dauer angelegt. Sofern leasingfinanziert, werden sie, in aller Regel (zumindest) als Dreiecksverhältnis ausgestaltet. Demnach ist der Leasingvertrag, dem ein IT-Projektvertrag zugrunde liegt, regelmäßig als Finanzierungsleasingvertrag einzuordnen, wovon auch der BGH ausgeht1. Die Ausführungen dieses Kapitels beziehen sich damit allein auf IT-Projektfinanzierungsleasingverträge2. 3. Grundlegende Besonderheiten des IT-Projektleasingvertrags Auf den Vertrag über IT-Projektleasing sind die rechtlichen Grundsätze des Leasingrechts anzuwenden, jedoch ist auf die besondere Fallgestaltung, wonach das Leasingobjekt teilweise noch entsteht, Rücksicht zu nehmen3.

5

Der IT-Projektleasingvertrag wird zwischen dem Anwender/Leasingnehmer 6 (Unternehmer4) geschlossen, der die zu finanzierende IT-Lösung nutzen will, und dem Dritten/Leasinggeber. Dazu steigt der Dritte/Leasinggeber regelmäßig bereits in einer der eigentlichen Erstellung vorgeschalteten5 Planungsphase in die Vorfinanzierung des Projektes ein, indem er nach Abschluss des Softwareentwicklungs- bzw. IT-Projektvertrages zwischen Anwender/Leasingnehmer und Lieferanten für den Anwender/Leasingnehmer in den Vertrag eintritt („Eintrittsmodell“). Er trägt mithin komplett die Last der (Vor-)Finanzierung des Erstellungsprojektes. Gleichzeitig schließt er mit

1 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575. 2 Zur Einordnung des IT-Projektleasingvertrages als Finanzierungsleasing vgl. Rz. 13 ff. 3 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575. 4 Grundsätzlich kann natürlich auch ein Verbraucher Vertragspartner eines IT-Projektleasingvertrags sein, da diese Situation aber eher selten ist, wird diese im Folgenden vernachlässigt. 5 Jedenfalls bei eher traditionellen Projektmethoden, zu modernen Projektmethoden (agiles Programmieren), bei denen eine deutliche Phasentrennung nicht mehr auszumachen ist, vgl. oben Kap. H.

Gennen

1473

R Rz. 7

Einzelprobleme

dem Anwender/Leasingnehmer den Leasingvertrag1. Refinanzieren kann der Leasinggeber seine Investition i.d.R. nur durch die Zahlung monatlicher Leasingraten; diese Refinanzierung beginnt i.d.R. jedoch erst, wenn das Gesamtleasingobjekt bzw. die Softwarelösung abgenommen und in Betrieb ist, s. nachfolgendes Schaubild. IT-Projekt Leasing – Einführung/Ablauf

Abnahme/Ablieferung/Fertigstellung des Arbeitsergebnisses

Phasen des IT-Projekts (grob) Planung

Erstellung

Individuelles Arbeitsergebnis

Phasen des IT-Projekt-Leasings Vorfinanzierungsphase

Leasingphase

Beginn der Zahlung der Leasingraten

7

Die Besonderheit von IT-Projektleasing resultiert demnach im Wesentlichen daraus, dass das zu überlassende Objekt zunächst vom Lieferanten individuell für den Anwender/Leasingnehmer erstellt oder angepasst wird und ihm erst dann vom Leasinggeber „überlassen“ wird. Bei Produkten, die im Zeitpunkt des Abschlusses des Leasingvertrages noch nicht hergestellt oder gar mangels abgeschlossener Planung noch nicht konkret definiert bzw. definierbar sind, schaltet sich der Leasingphase also eine Planungsund Herstellungsphase vor. Das Leasingobjekt wird, sofern und soweit es in einer Individualsoftware oder einer durchgreifend überarbeiteten Standardsoftware besteht, nicht „lediglich“ durch den Kauf durch den Leasinggeber vorfinanziert. Das Leasingobjekt ist vielmehr ein nach den individuellen Bedürfnissen zu erstellendes komplexes Arbeitsergebnis.

8

Aus der Tatsache, dass der Leasinggeber dem Leasingnehmer eine nach den Vorstellungen des Leasingnehmers konzipierte und auf seine individuellen Bedürfnisse zugeschnittene IT-Lösung schuldet, ergeben sich regelmäßig zumindest folgende Besonderheiten hinsichtlich der vertraglichen Beziehung zwischen Leasinggeber und Leasingnehmer: 1 Vgl. die Sachverhalte in BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79, und OLG Brandenburg, CR 2009, 763; Habersack, WM 2008, 809.

1474

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 10 R

– Der Leasingnehmer muss, um das gewünschte Leasingobjekt zu erhalten, an der beauftragten Erstellung mitwirken, dies schließt meist Konzeption, Umsetzung und Erstellung ein. Er muss Entscheidungen im laufenden Entwicklungsprozess treffen, den Lieferanten mit allen notwendigen Informationen versorgen und diesem die Installation der Lösung in seinen Räumen bzw. am Betriebsort gestatten1. – Im Verhältnis der Parteien des Leasingvertrages zueinander kennt nur der Leasingnehmer die genauen Anforderungen, die an das Leistungsergebnis zu stellen sind. Meist kann nur der Leasingnehmer entscheiden, ob es den Anforderungen entspricht. Ob demnach eine Lieferung stattgefunden hat oder die Abnahme geschuldet wird und ob die Lösung mangelbehaftet ist, kann im Verhältnis der Parteien zueinander regelmäßig nur der Leasingnehmer entscheiden. – Die Entscheidung, mit dem beauftragten Lieferanten zusammen zu arbeiten/die Auswahl des Lieferanten hat in der Regel der Leasingnehmer getroffen, auch die Vorverhandlungen hat beim Eintrittsmodell meist der Leasingnehmer geführt. Dies ist zwar auch im Übrigen beim Finanzierungsleasingvertrag der Fall, allerdings verlangt der Erwerbs-/Kaufvertrag, dem ein typischer Finanzierungsleasingvertrag zugrunde liegt, keine enge, oft auf Jahre angelegte Zusammenarbeit, so dass der Auswahl hier ein wesentlich höheres Gewicht zukommt. – Der Lieferant ist hinsichtlich der Überlassungsverpflichtung (Übergabe) Erfüllungsgehilfe des Leasinggebers, wenn er direkt an den Leasingnehmer, nicht an den Leasinggeber liefern soll. Der Leasingnehmer ist hinsichtlich der Abnahmeverpflichtung des Leasingebers gegenüber dem Lieferanten Erfüllungsgehilfe des Leasinggebers. Der Leasingnehmer ist damit maßgeblich am Erfolg des IT-Projektvertrags 9 beteiligt, ohne dessen Vertragspartner zu sein. Durch die Notwendigkeit der Erstellung des Leasinggegenstandes unter Mitwirkung des Leasingnehmers erhöht sich die Komplexität des Leasingvertrages im Verhältnis zu einem üblichen Finanzierungsleasing. Folglich ist auch die Wahrscheinlichkeit des Eintritts von Leistungsstörungen erhöht. In Konstellationen, bei denen der Leasinggeber zunächst lediglich ein fertiges Leasingobjekt käuflich erwirbt, ist das finanzielle und damit auch das Insolvenzrisiko, welches der Leasinggeber trägt, nicht im gleichen Maße gegeben, weil der Leasinggeber meist erst dann eine Zahlung an den Lieferanten leistet, wenn er bzw. der Leasingnehmer das Leasingobjekt auch tatsächlich erhalten hat. Der Leasinggeber hat dann bereits Eigentum am Leasingobjekt als Gegenwert bekommen. Außerdem geht die Gefahr des zufälligen Untergangs beim typischen Leasing mit der Übergabe an den Leasingnehmer bzw. eine Transportperson unmittelbar über. Die Störungsanfälligkeit wird zudem dann potenziert, wenn mehrere Auf- 10 tragnehmer/Lieferanten an dem Projektvertrag mitwirken um eine System1 Habersack, WM 2008, 809.

Gennen

1475

R Rz. 11

Einzelprobleme

lösung zu konzipieren. Kompliziert wird die Fallgestaltung dementsprechend, wenn der zugrunde liegende IT-Projektvertrag, wie nicht selten, ein Generalunternehmervertrag ist. Bisweilen verlangt der Leasinggeber die Auftrennung der Teilleistung in verschiedene Vereinbarungen und mithin die Auflösung der Generalunternehmerkonstellation, während der Anwender diese eher beizubehalten wünscht. Sieht man die geschilderte Projektsituation aus Anwenderperspektive, besteht bei IT-Projekten naturgemäß ein Interesse des Anwenders/Leasingnehmers daran, eine integrierte Gesamtlösung aus verschiedenen Komponenten zu erhalten, einschließlich z.B. einer etwaigen Migration vorhandener Daten aus einem Altsystem, und erst dann zur Zahlung verpflichtet zu sein, wenn alles vertragsgemäß abgewickelt ist. Aus der Perspektive des Leasinggebers, der selbst nicht Lieferant ist, stellt sich in einer solchen Situation insbesondere das Problem, dass unklar ist, wann das Erstellungsprojekt abgeschlossen ist, welches finanzielle Volumen – angesichts z.B. vieler Change Requests – es haben wird (welches Finanzierungsvolumen demnach ansteht), wann und inwiefern ein qualitativ genügender Leasinggegenstand entsteht und wer diese Qualität beurteilt. Sofern es sich um ein komplexes Projekt mit einem Leistungsbündel handelt, wird der Leasinggeber daher versuchen, die einzelnen Teile der Gesamtheit der Leasingobjekte nach Risikoklassen zu trennen. Bisweilen versuchen Leasinggeber daher, die verschiedenen Leasingobjekte in rechtlich als getrennt gewünschte Verträge aufzunehmen, z.B. eine vergleichsweise einfach zu behandelnde Standardsoftware und Hardware in einen oder in zwei Leasingverträge, während die ebenfalls zum Projekt gehörende, noch zu erstellende Individualsoftwarelösung, der i.d.R. problematischste Projektteil, in einem gesonderten Vertrag ausgegliedert wird. Solche Verträge werden voneinander getrennt mit Regelungen wie:

Dieser Leasingvertrag ist unter allen Umständen sachlich und inhaltlich von etwaigen anderen mit dem Leasingnehmer geschlossenen Verträgen über Hardware-Leasing [und/oder Standardsoftware-Leasing] hinsichtlich sämtlicher Ansprüche des Leasingnehmers gegen den Leasinggeber oder den Lieferanten zu trennen. Der Vertrag über die Hardware [und/oder die Standardsoftware] einerseits und der Vertrag über die im Projekt zu erstellende Software andererseits stellen keine rechtliche Einheit i.S.d. § 139 BGB dar. Ein Rücktritt aufgrund eines Mangels der Software lässt diese Verträge unberührt und umgekehrt. Dies gilt auch, wenn ein Gesamtpreis hinsichtlich der Hardware [, der Standardsoftware] und der Individualsoftware vereinbart worden ist.

11 Mit der Zahlung der Leasingraten beginnt der Leasingnehmer meist erst nach Beginn der Gebrauchsüberlassung oder Inbetriebnahme der IT-Lösung, und damit erst nach Beendigung des Entwicklungsprojektes1. Damit ist die 1 Mit Verweis auf steuerliche Gründe: Habersack, WM 2008, 809.

1476

Gennen

Rz. 13 R

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Durchführung des Leasingvertrages abhängig vom Erfolg des Softwareerstellungs- bzw. IT-Projektvertrages.

II. Rechtliche Einordnung von IT-Projektleasingverträgen 1. Rechtsnatur des Finanzierungsleasings im Allgemeinen Die rechtliche Einordnung des Finanzierungsleasingvertrags ist umstritten. 12 Der BGH, was für die Praxis maßgeblich sein dürfte, und erhebliche Teile der Literatur1 ordnen den Finanzierungsleasingvertrag in erster Linie als Mietvertrag2 ein. Ausdrücklich wendet der BGH das Mietvertragsrecht unter der Prämisse an, dass „bei einer Inhaltskontrolle jeweils das Eigengepräge des Leasingvertrags unter sachgerechter Bewertung der von den Parteien typischerweise verfolgten Interessen berücksichtigt“ werden muss3. Die Rechtsprechung erlaubt deshalb die Abwälzung der Sach- und Preisgefahr4 und den Ausschluss von Gewährleistungsansprüchen bei Abtretung der Ansprüche gegen den Lieferanten5. Der Finanzierungsleasingvertrag weiche vom Mietvertrag aufgrund seiner Finanzierungs- und Amortisationsfunktion ab. Weil mit dem Vertrag die besonderen Investitionsbedürfnisse des Leasingnehmers abgedeckt würden, habe er auch für die Amortisierung einzustehen, so dass es zudem gerechtfertigt sei, beispielsweise dem Leasingnehmer das Fehlinvestitionsrisiko aufzuerlegen6. Die mietrechtliche Einordnung wird jedenfalls für solche Fälle vertreten, in 13 denen der Leasinggeber die Sache eigens zur Vertragserfüllung anschafft und an dieser Eigentum erhält, sein Gesamtaufwand gedeckt7 wird und er sich von der Sachmängelhaftung durch Abtretung der kaufrechtlichen Gewährleistungsansprüche frei zeichnet8. Während einer Grundlaufzeit ist der Vertrag zudem als ordentlich nicht kündbar ausgestaltet und der Leasingnehmer ist zumindest zur Bewirkung der Vollamortisation verpflichtet (bzw. Teilamortisation bei Teilamortisationsvertrag)9. Die Zuordnung zum Mietrecht wird wiederum mit der vergleichbaren Interessenlage begründet. 1 AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 25; Emmerich, JuS 1990, 2 (4). 2 BGH NJW 1977, 195 (196); BGH NJW 1977, 848. 3 BGH v. 4.7.1990 – VIII ZR 288/89, CR 1991, 407 = NJW 1990, 3016 (3017). 4 BGH v. 30.9.1987 – VIII ZR 226/86, CR 1987, 846 = NJW 1988, 198 (199); BGH NJW 1977, 195 (196); BGH v. 12.2.1985 – X ZR 31/84, NJW 1985, 1537. 5 BGH NJW 1977, 848; BGH v. 16.9.1981 – VIII ZR 265/80, MDR 1982, 223 = NJW 1982, 105; BGH v. 13.3.1991 – VIII ZR 34/90, MDR 1991, 718 = NJW 1991, 1746; BGH v. 9.7.2002 – X ZR 70/00, MDR 2003, 145 = NJW-RR 2003, 51 (52). 6 BGH v. 4.7.1990 – VIII ZR 288/89, CR 1991, 407 = NJW 1990, 3016 (3018). 7 Vgl. AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 18 zur Vollamortisationspflicht nach Vollamortisationserlass. 8 BGH NJW, 1986, 179; BGH NJW 1977, 848; BGH v. 16.9.1981 – VIII ZR 265/80, MDR 1982, 223 = NJW 1982, 105. 9 BGH v. 10.7.1996 – VIII ZR 282/95, MDR 1996, 1119 = NJW 1996, 2860 (2861).

Gennen

1477

R Rz. 14

Einzelprobleme

Der Vertragszweck sei darauf gerichtet, dass der Leasinggeber die Sache beschafft und Eigentum an dieser erhält und in einem mangelfreien Zustand auf Zeit zum Gebrauch überlässt. Es sei demnach eine entgeltliche Gebrauchsüberlassung angestrebt, ohne dass das Eigentum auf den Leasingnehmer übergehen soll1. Dem Finanzierungsleasing sei, als Besonderheit gegenüber anderen Arten der Finanzierung immanent, dass das Leasinggut dem Leasinggeber jedenfalls als „wirtschaftliches Eigentum“ im Sinne von § 39 Abs. 2 AO zugerechnet werde. Meist sei dies Motivation des Leasinggebers. Der Vermieter überlasse damit Eigentum einem Dritten auf Zeit. Wer nicht Eigentümer sei, sei lediglich Finanzier2, so dass der Leasinggeber auch als bürgerlich-rechtlicher Eigentümer anzusehen sei3. Die Eigentümerstellung wird demnach aus der steuerlichen Behandlung des Mietobjekts hergeleitet. 14 In der Literatur werden unterschiedliche Auffassungen vertreten4. Insbesondere wird vertreten, dass ein Vertrag „eigener Art“ vorliegt oder ein typengemischter Vertrag5. Der Vertrag beinhalte eine fremdnützige Beschaffung und entspreche deshalb überwiegend dem Geschäftsbesorgungs- und Kreditverhältnis6. Hinsichtlich der Beschaffung des Gegenstandes sei der Leasinggeber als mittelbarer Stellvertreter des Leasingnehmers anzusehen; sein Aufwendungsersatzanspruch werde dem Leasingnehmer durch die Ratenzahlung kreditiert. Der Finanzierungsleasingvertrag lasse sich seinem Kerngehalt nach keinem bestimmten Vertragstypus zuordnen7. Diese Meinung geht davon aus, dass hinsichtlich des anwendbaren Rechts eine „punktuell problembezogene Ähnlichkeitsfeststellung“ vorzunehmen ist, schließt sich dadurch der Behandlung des Finanzierungsleasingvertrages des BGH als „atypischen Mietvertrag“ aber im Ergebnis an. 2. Rechtsnatur des IT-Projektleasings (Regelfall) 15 Der Meinungsstreit, ob Mietrecht beim Finanzierungsleasingvertrag anwendbar ist, setzt sich im Rahmen der Beurteilung von Finanzierungsleasingverträgen, die zur Finanzierung einer IT-Projektlösung abgeschlossen wurden, wenn auch in anderer Ausgestaltung, fort.

1 2 3 4

AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 25. BGH v. 19.2.1986 – VIII ZR 91/85, CR 1986, 458 = NJW 1986, 1744. Graf von Westphalen, NJW 2008, 2234 (2240 f.). Vertreten werden unterschiedliche Lösungsansätze, so soll Kaufrecht anwendbar sein, ein Vertrag „eigener Art“ oder ein Geschäftsbesorgungsverhältnis vorliegen. Vgl. zum Streitstand: MünchKomm/Koch, BGB, Band 3, Finanzierungsleasing, Rz. 26–28; Wolf, JuS 2002, 335. 5 Lieb, DB 1988, 951; MünchKomm/Koch, BGB, Band 3, Finanzierungsleasing, Rz. 32. 6 Canaris, NJW 1982, 305 (306). 7 Lieb, DB 1988, 951.

1478

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 18 R

Während Teile der Literatur1 davon ausgehen, dass die Besonderheiten des 16 IT-Projektleasings eine abweichende Einordnung des Vertrages, etwa als Darlehens- oder Geschäftsbesorgungsvertrag rechtfertigen, geht der BGH in gefestigter Rechtsprechung von der Anwendbarkeit des Mietrechts aus2. Daher wies der BGH dem Leasinggeber in einem IT-Projektleasingvertrag (Bundle-Lease-Vertrag über eine Systemsoftwarelösung) nicht lediglich die Stellung eines Finanziers, sondern eines Vermieters zu. Dass der Leasinggeber rechtlicher und wirtschaftlicher Eigentümer der IT-Lösung werden wollte, entnahm der BGH dabei der Gesamteinheit der vertraglichen Regelungen, die typische finanzierungsleasingvertragliche Regelungen umfassten. Demnach geht der BGH davon aus, dass die mietrechtliche Einordnung im Grundsatz auch bei IT-Projektfinanzierungsleasingverträgen vorzunehmen ist3. Ein Teil der Literatur hält dem entgegen, dass das Scheitern des Projekts bei 17 IT-Projektverträgen dem leasingtypischen Beschaffungsvorgang zuzuordnen sei. Dieses Risiko sei vom Leasinggeber nicht zu verantworten, sondern aufgrund der besonderen Fallgestaltung dem Leasingnehmer zuzuordnen4, denn der Leasingnehmer wähle den Lieferanten aus. Würde der Leasinggeber das mietrechtliche Beschaffungsrisiko tragen und er damit auch für die Erstellung durch den Lieferanten als sein Erfüllungsgehilfe einstehen, müsste im Einzelfall ermittelt werden, wer genau die Verzögerung zu vertreten habe, der Lieferant oder der Leasingnehmer. Dies sei bei komplexen Erstellungsprozessen, bei denen nicht nur der Ersteller, sondern auch der spätere Nutzer der Lösung wesentlich mitzuwirken habe, oft schwierig. Außerdem habe sich der Leasingnehmer zur Zusammenarbeit mit dem Lieferanten durch dessen Auswahl verpflichtet5. Mit dieser Auffassung wäre der IT-Projektvertrag eher als Darlehens- oder Geschäftsbesorgungsvertrag einzuordnen6. Dem hat der BGH eine Absage erteilt, denn der Leasinggeber habe aufgrund seiner Stellung als Eigentümer eine Gebrauchsüberlassungspflicht; der Leasingnehmer könne nicht besser beurteilen, ob der Lieferant liefern könne und wolle, als der Leasinggeber7. Zudem wird vertreten, dass in der besonderen Fallkonstellation des IT-Pro- 18 jektleasings eine andere als eine mietrechtliche Einordnung denkbar sei, weil das Vorliegen einer speziell für den Leasingnehmer erstellten „System1 Graf von Westphalen, NJW 2008, 2234 (2240 f.); Habersack, WM 2008, 809. 2 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 mit Verweis auf allgemeinen Finanzierungsleasingvertrag BGH v. 9.10.1985 – VIII ZR 217/84, BGHZ 96, 103 (106) = MDR 1986, 228; BGH NJW 1977, 1058; BGH NJW 1986, 179; BGH v. 8.11.1989 – VIII ZR 1/89, CR 1990, 333 = NJW-RR 1990, 182; BGH NJW 1987, 1383 (1384). 3 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575. 4 Habersack, WM 2008, 809 (812). 5 Habersack, WM 2008, 809 (812). 6 Graf von Westphalen, NJW 2008, 2234 (2240 f.). 7 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577).

Gennen

1479

R Rz. 19

Einzelprobleme

lösung“ den Herausgabeanspruch des Leasinggebers (§ 985 BGB) wertlos mache1. Gemeint ist damit, in Anlehnung an die steuerlich begründete Einordnung des Finanzierungsleasings zum Mietrecht, dass der Leasinggeber beim IT-Projektleasing nicht als Eigentümer der Sache anzusehen sei, weil eine Herausgabe der Sache an den Leasinggeber entweder nicht möglich sei oder die Herausgabe für diesen keinen Wert habe. Dann handle es sich um ein „Spezialleasing“ (s. nachfolgend Rz. 28 ff.). Auch nach dieser Ansicht wären IT-Projektfinanzierungsleasingverträge grundsätzlich jedenfalls nicht mietrechtlich, sondern eher darlehens- oder geschäftsbesorgungsrechtlich einzuordnen. Einer solchen grundlegenden Einordnung stimmt der BGH in der Entscheidung vom 29.10.20082 nicht zu, räumt aber ein, dass je nach Fallgestaltung auch Spezialleasing vorliegen kann. Folglich bleibt im Einzelfall zu prüfen, ob ein solches vorliegt. Hierzu ist eine besondere Fallgestaltung erforderlich; die Tatsache allein, dass ein individualisiertes komplexes IT-Projekt vorliegt, genügt jedoch offenbar nicht. 3. Fallgestaltungen, in denen der Leasingnehmer als Eigentümer des Leasingobjekts gelten kann 19 Ein Sonderfall in dem vorgenannten Sinne liegt vor, wenn dem Leasingnehmer das (wirtschaftliche) Eigentum an dem Leasingobjekt zuzurechnen ist. Es ist zwar regelmäßig davon auszugehen, dass nach den Vereinbarungen der Leasinggeber Eigentümer des Leasinggegenstandes wird3. Ist der Einzelfall aber so gestaltet, dass der Leasingnehmer als (wirtschaftlicher) Eigentümer des Leasinggegenstandes anzusehen ist, ist auch die Anwendung von Darlehens- oder Geschäftsbesorgungsvertragsrecht auf den IT-Finanzierungsleasingvertrag vertretbar4. 20 Die vertragliche Zuordnung des Finanzierungsleasingvertrages zum Mietrecht erfolgt nach der Rechtsprechung auch bzw. gerade aufgrund der vertraglich vorgegebenen Eigentumsverhältnisse. Zur Beurteilung der Eigentumsverhältnisse werden wiederum die steuerlichen Grundsätze und Besonderheiten herangezogen. Die steuerliche Einordnung gibt die bürgerlich-rechtliche und damit mietvertragliche Einordnung sogar vor5. Zwar ist grundsätzlich davon auszugehen, dass nicht die steuerlichen Vorgaben Einfluss nehmen auf die Beurteilung der bürgerlich-rechtlichen Eigentumsverhältnisse, im Gegenteil6. Allerdings ist Motivation für einen Finanzierungsleasingvertrag regelmäßig der für die Vertragsparteien entstehende 1 2 3 4

Graf von Westphalen, NJW 2008, 2240 (2241). BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575. BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577). Im Ergebnis: BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577); Graf von Westphalen, NJW 2008, 2234 (2240); ggf. auch die Anwendung von Kaufrecht. 5 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577). 6 MünchKomm/Koch, BGB, Band 3, Finanzierungsleasing, Rz. 17.

1480

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 24 R

steuerliche Vorteil. Legt man den Vertrag nach allgemeinen (bürgerlichrechtlichen) Auslegungsgrundsätzen aus, will der Leasinggeber meist zumindest „wirtschaftlicher“ Eigentümer des Leasingobjektes i.S.v. § 39 Abs. 2 Satz 1 AO sein. Folglich ist die bürgerlich-rechtliche Zuordnung des Eigentums zumindest mittelbar beeinflusst von der steuerlich-rechtlichen. Eine Abweichung von der mietrechtlichen Einordnung des Leasingvertrages erscheint damit dann gerechtfertigt, wenn kein steuererlasskonformes Finanzierungsleasing vorliegt, bzw. dem Leasingnehmer das (zunächst wirtschaftliche) Eigentum am Leasingobjekt zuzurechnen ist.

21

a) Steuerliche Vorgaben zur Eigentümerstellung Wann aus steuerlicher Sicht das wirtschaftliche Eigentum dem Leasingneh- 22 mer zugeordnet wird, richtet sich nach § 39 AO. Übt ein anderer als der bürgerlich-rechtliche Eigentümer die tatsächliche Sachherrschaft über die Sache aus und kann er den anderen von der wirtschaftlichen Einwirkung auf die Sache nach dem typischen Verlauf für die gewöhnliche Nutzungsdauer ausschließen, wird ihm das wirtschaftliche Eigentum zugerechnet (§ 39 Abs. 2 Nr. 1 Satz 1 AO). Wann das wirtschaftliche Eigentum dem Leasingnehmer i.S.v. § 39 AO zu- 23 zuordnen ist, ist dem Vollamortisierungserlass von 19711 zu entnehmen. Zur wirtschaftlichen Einordnung der Eigentumsverhältnisse wird vor allem die „betriebsgewöhnliche Nutzungsdauer“ herangezogen, die nach AfA-Tabellen zu bestimmten ist. So wird das wirtschaftliche Eigentum dem Leasinggeber im Vollamortisierungsvertrag z.B. dann zugerechnet, wenn die Grundlaufzeit mindestens 40 %, aber höchstens 90 % der betriebsgewöhnlichen Nutzungsdauer beträgt. Für die steuerliche Zuordnung eines Wirtschaftsgutes zum Leasingnehmer 24 kommt es im Einzelfall auf das Gesamtbild der tatsächlichen, nicht allein der formal vereinbarten Verhältnisse an2. Eine Eigentumsverfügung im Sinne von § 929 BGB ist nicht erforderlich. Als ausreichend wird vor den Finanzgerichten anerkannt, dass sich die Grundmietzeit zumindest annähernd mit der betriebsgewöhnlichen Nutzungsdauer deckt. Auch wenn die Laufzeit zwar erheblich geringer ist, dem Leasinggeber aber ein Recht auf Vertragsverlängerung oder Kauf zusteht und bei Optionsausübung nur noch ein sehr geringer Mietzins zu entrichten ist oder ein Kaufpreis zu zahlen ist, der einer Anerkennungsgebühr gleichkommt3, ist von einer Verschiebung der Stellung des wirtschaftlichen Eigentümers zum Leasingnehmer aus1 BStBl. 1971 I S. 264. Es handelt sich bei den Steuererlassen aber lediglich um Verwaltungsvorschriften die lediglich Normen interpretieren, die Gerichte mangels Rechtsnormqualität aber nicht binden, lediglich eine Richtigkeitsvermutung erzeugen; BFH v. 9.12.1999 – III R 74/97, BStBl. II 2001, 311 = FR 2000, 470. 2 BFH DStRE 2001, 971 (974). 3 BFH DStRE 2001, 971 (974); FG Hamburg DStRE 2010, 687 (689).

Gennen

1481

R Rz. 25

Einzelprobleme

zugehen. Damit ein Vertrag als Mietvertrag angesehen werden kann, müssen sich Mietzins, Mietdauer und Mietbedingungen ausschließlich nach der bezweckten Gebrauchsüberlassung richten, auch bei wirtschaftlicher Betrachtungsweise. Dies ist eben dann nicht der Fall, wenn die Mietzeit derart bemessen sei, dass nach ihrem Ablauf ein wirtschaftlicher oder technischer Verbrauch der Mietsache eingetreten und zudem während der Vertragslaufzeit eine Rückgabe der Sache ausgeschlossen ist. In diesen Fällen kann der Leasingnehmer den Leasinggeber bis zur Beendigung der Nutzungsdauer des Leasingobjekts von jeglicher Einwirkung ausschließen, was letztlich einem von Anfang auf die Veräußerung gerichtetem Geschäft gleichkommt1. Der Leasingnehmer ist dann als wirtschaftlicher Eigentümer anzusehen. Unerheblich ist in diesem Zusammenhang, ob das Vertragsverhältnis bei Insolvenz oder Aufgabe des Gewerbebetriebs aus Sicherungszwecken vorzeitig beendet werden kann2. 25 Die Zivilgerichte stellen hinsichtlich der mietrechtlichen Einordnung nicht allein auf die Steuerklasse ab. Der BGH hat in einem Fall, in dem sich der Leasinggeber ausdrücklich vorbehalten hatte, dass die Sache nach der Mietzeit an ihn zurück zu geben war und er sie weiterverwerten konnte und ferner die Vertragsdauer gleich der betriebsgewöhnlichen Nutzungsdauer war, Mietrecht angewendet, obwohl das wirtschaftliche Eigentum nach dem Vollamortisationserlass aufgrund der vereinbarten mehr als 90 % der betriebsgewöhnlichen Nutzungsdauer dem Leasingnehmer zuzurechnen war, weil nicht erkennbar war, dass die Sache nach der Rückgabe für den Leasinggeber keinen Wert mehr hatte3. In jedem Fall sind die Steuerklasse aber bei der Beurteilung des Einzelfalls auch im Zivilprozess heranzuziehen. Hauptsächlich kommt es für die Zuordnung des wirtschaftlichen Eigentums darauf an, ob der Nutzungsberechtigte den Eigentümer dauerhaft von der Nutzung ausschließen kann. Es ist jedenfalls dann davon auszugehen, dass der bürgerlich-rechtliche Eigentümer von der wirtschaftlichen Einwirkung im Sinne von § 39 Abs. 2 Satz 1 AO ausgeschlossen ist, wenn seinem Herausgabeanspruch keine wirtschaftliche Bedeutung mehr zukommt4. 26 Für die Einordnung des wirtschaftlichen/bürgerlich-rechtlichen Eigentums gilt damit, dass jedenfalls dann, wenn dem Herausgabeanspruch keine wirtschaftliche Bedeutung mehr zukommt, der Leasingnehmer als Eigentümer des Leasinggegenstands anzusehen ist. Dann ist nicht von einer Anwendbarkeit des Mietrechts auszugehen. Ob und wann ein solcher Fall vorliegt, richtet sich nach dem Einzelfall und ist daher jedenfalls auch bei IT-Projektleasingverträgen möglich. Vorstellbar ist dies insbesondere bei besonders

1 2 3 4

BFH BStBl. II 1978, 507 (508). BFH BStBl. II 1978, 507 (508). BGH NJW 1977, 848 (849). BFH v. 12.9.1991 – III R 233/90, BStBl. II 1992, 182 = FR 1992, 132; BFH DStRE 2001, 971 (974) mit Verweis auf BFH BStBl. II 1970, 264; Graf von Westphalen, NJW 2008, 2234 (2241).

1482

Gennen

Rz. 29 R

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

komplexen Anpassungsarbeiten und bei sehr umfangreicher und anderweitig nicht verwendbarer Individualsoftware. Unerheblich ist in diesem Zusammenhang jedenfalls, ob dem Leasinggeber 27 beispielsweise vertraglich das Recht eingeräumt wurde, jederzeit Zutritt zur Sache zu haben, oder er diese warten oder reparieren muss, denn diese Rechte ändern nichts an der Einordnung des Wertes des Herausgabeanspruchs. Dieser bleibt wertlos, wenn der Leasingnehmer die Sache bis zu ihrer vollständigen wirtschaftlichen Abnutzung nicht herauszugeben braucht1. Wurde also zusammen mit dem Leasingvertrag vereinbart, dass der Leasinggeber die ITLösung zu warten hat o.ä., so dass diesem bzw. seinem Vertragspartner aus dem IT-Projektvertrag ein Einwirken auf das Leasingobjekt ermöglicht wird, bedeutet dies nicht automatisch, dass das Eigentum dem Leasinggeber zuzuordnen ist. b) Eigentümerstellung nach steuerlichen Vorgaben im Fall des Spezialleasings Auf das Verhältnis von Nutzungs- und Überlassungsdauer kommt es für die 28 Zuordnung des wirtschaftlichen Eigentums an den Leasingnehmer nach dem Vollamortisierungserlass nicht an, wenn der Leasinggegenstand derart auf die Bedürfnisse des Leasingnehmers angepasst wurde, dass eine wirtschaftlich sinnvolle anderweitige Nutzung oder Verwertung nicht möglich ist (sog. Spezialleasing)2. Auch in diesem Fall ist der Herausgabeanspruch wertlos. Beim Spezialleasing wird jedenfalls das wirtschaftliche Eigentum daher dem Leasingnehmer zugeordnet3. Bisher hat die Rechtsprechung nur in sehr wenigen Fällen das Vorliegen ei- 29 nes Spezialleasings angenommen. In Erwägung gezogen wurde es z.B. bei der Installation einer auf die Anforderungen des Leasingnehmers angepassten Telefonanlage4. Der BFH entschied im Fall einer Ladenlokaleinrichtung, dass ein Spezialleasing sogar dann vorliegen kann, wenn Teile der Gesamtlieferung auch noch anderweitig verwendet werden können, das Gesamtpaket aber nur für den einen Leasingnehmer verwendbar ist5. Eine entsprechende Fallkonstellation würde zwar im Fall des IT-Projektleasings selbst bei einer nur leichten Anpassung einer Standardsoftware vorliegen können, zumal das Gesamtpaket in der ganz konkreten Ausgestaltung meist nur von dem Leasingnehmer nutzbar ist. Wäre das zutreffend, würde schon bei leichten Anpassungs- und Implementierungsarbeiten immer ein Spezialleasing vorliegen. Allerdings war im genannten Fall der Ladeneinrichtung der weit überwiegende Teil nicht mehr anderweitig verwendbar. Demnach ist nicht 1 BFH BStBl. II 1978, 507; BFH DStRE 2001, 971 (978). 2 BFH DStRE 2001, 971 (975); FG Hamburg DStRE 2010, 687; vgl. Vollamortisationserlass BStBl. 1971 I S. 264, II 2. D) III. 4. 3 Vollamortisationserlass BStBl. 1971 I S. 264, II 2. D) III. 4. 4 BFH DStRE 2001, 971. 5 BFH BStBl. II 1970, 264, Rz. 78; BFH DStRE 2001, 971 (975).

Gennen

1483

R Rz. 30

Einzelprobleme

ausgeschlossen, dass trotz Individualisierungsanpassungen kein Spezialleasing vorliegt, wenn der überwiegende Teil weiterverwendet werden kann. 30 Auch im Rahmen von IT-Projektverträgen ist mithin eine Beurteilung des Leasingvertrages als Spezialleasing nicht ausgeschlossen1. Zwar hat der BGH in der Entscheidung vom 29.10.20082 ein solches nicht angenommen, jedoch waren hierzu auch keine Feststellungen durch die Tatsacheninstanzen getroffen worden. Bei IT-Projektfinanzierungsleasingverträgen, bei denen eine IT-Lösung derart auf die Bedürfnisse des Leasingnehmers angepasst bzw. zugeschnitten wird, dass der Leasinggegenstand nach der Vertragslaufzeit nur noch vom Leasingnehmer wirtschaftlich sinnvoll genutzt werden kann, wird von einem Spezialleasing ausgegangen werden müssen. Dann bleibt damit die Anwendung von Geschäftsbesorgungs- oder Darlehensvertragsrecht oder die Einordnung als Vertrag sui generis3 möglich.

III. Besonderheiten bei IT-Projektfinanzierungsleasing 1. Hauptleistungspflichten a) Hauptleistungspflichten des Leasinggebers aa) Überlassung des Leasingobjekts zur Nutzung 31 Hauptleistungspflicht des Leasinggebers ist, dem Leasingnehmer die näher bezeichnete funktionstüchtige Sache bzw. Sachgesamtheit, die IT-Lösung, zum Gebrauch zu überlassen4. Das Leasingobjekt muss dabei regelmäßig dem nach den vereinbarten Vorgaben erstellten Projektergebnis entsprechen. Beim Eintrittsmodell hat der Leasinggeber demnach eine Lösung zu überlassen so wie der Leasingnehmer dies mit dem Lieferanten im IT-Projektvertrag vereinbart hat. Die Übergabe des Leasinggegenstandes erfolgt in den meisten Fällen durch den Lieferanten. Insoweit ist der Lieferant als Erfüllungsgehilfe des Leasinggebers anzusehen5. bb) Beschaffungspflicht und deren Grenzen 32 Grundsätzlich geht die Rechtsprechung davon aus, dass der Leasinggeber im typischen Finanzierungsleasingvertrag auch das Beschaffungsrisiko trägt. Im Unterschied zum reinen Finanzier hat der Finanzierungsleasinggeber als Eigentümer eine Gebrauchsüberlassungspflicht. Aus der Eigentümerstellung und der Gebrauchsüberlassungspflicht leitet sich eine Verantwortlichkeit für die Sache ab. Diese rechtfertigt jedenfalls keine umfassende Abwälzung 1 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577); Habersack, WM 2008, 809; Graf von Westphalen, NJW 2008, 2234 (2241). 2 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575. 3 Zur entsprechenden allgemeinen Einordnung des Finanzierungsleasingvertrags: Lieb, DB 1988, 946 (951). 4 BGH v. 9.10.1985 – VIII ZR 217/84, MDR 1986, 228 = NJW 1986, 179. 5 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577).

1484

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 35 R

des Beschaffungsrisikos auf den Leasingnehmer1. Fraglich ist damit, ob und inwieweit der Leasinggeber auch zur Herstellung (bzw. zum Herstellenlassen) des Leasingobjektes verpflichtet ist, bzw. ob oder wann ihm eine etwaige nicht rechtzeitige oder nicht vertragsgemäße Erstellung der im Projekt zu erstellenden Lösung durch den Lieferanten über § 278 BGB zuzurechnen ist. Dies ist eine sehr häufig vorkommende Fallgestaltung; es ist bekannt, dass die Mehrzahl der Softwareerstellungsprojekte Probleme im Hinblick auf Termineinhaltung, Qualität und/oder Budget haben. Insoweit erkennt der BGH ein schutzwürdiges Interesse des Leasinggebers an2: „Der Leasinggeber hat ein schutzwürdiges Interesse daran, zu einem bestimmten Zeitpunkt eine endgültige Klärung herbeizuführen, wie lange sich die Erstellungsphase noch hinziehen wird, da er die Erstellung über einen längeren Zeitraum vorfinanziert, seine Gegenleistung in Form der Leasingraten aber erst ab Abnahme des Werkes/Beginn des Leasingvertrags erhält.“

Damit kann man sich einen sachlichen Grund für einen Rücktritt von dem 33 noch nicht durch Zahlung von Leasingraten zur Durchführung gelangten Leasingvertrag vorstellen, misst man dies an § 308 Nr. 3 BGB (ggf. über § 307 BGB). Vertreten wird hierzu in der Literatur, dass den Besonderheiten des IT-Pro- 34 jektleasings dadurch Rechnung zu tragen sei, dass der Leasingnehmer das Beschaffungsrisiko trage. Die Pflicht des Leasinggebers beziehe sich daher allein auf die Überlassung des fertigen Projektergebnisses, nur insoweit könne auch der Lieferant Erfüllungsgehilfe (§ 278 BGB) des Leasinggebers sein3. Die Herstellung des Leasinggegenstandes trage lediglich zur Schaffung der Leistungsvoraussetzungen bei. Bei Entwicklungsprozessen sei meist nicht leicht zu ermitteln, wer eine Pflichtverletzung vorgenommen habe, der Lieferant oder der Anwender/Leasingnehmer. Außerdem sei es der Leasingnehmer, der den Lieferanten auswähle. Eine Schadensersatzpflicht des Leasinggebers ergebe sich demnach nur bei der Übernahme einer Beschaffungsgarantie, wovon nur bei Gattungsschulden ausgegangen werden könne, demnach regelmäßig nicht bei IT-Projektleasingverträgen mit Individualsoftwareanteil. Der Leasinggeber hafte also nicht uneingeschränkt für jedes Beschaffungshindernis. Aufgrund der Besonderheiten des IT-Projektfinanzierungsleasingvertrages sei eine Einschränkung der Haftung des Leasinggebers auf die „Beschaffung des Lieferanten“ beschränkbar. Der BGH hat in der Entscheidung vom 29.10.20084 über den genauen Um- 35 fang der Erfüllungsgehilfeneigenschaft des Lieferanten und damit auch den Umfang des Pflichtenkreises des Leasinggebers nicht entschieden. Er stellt in der o.a. Entscheidung aber jedenfalls fest, dass es unwirksam sei, von einer vertraglichen Klausel, die den Leasinggeber zum Rücktritt vom Leasing1 2 3 4

BGH v. 19.2.1986 – VIII ZR 91/85, CR 1986, 458 = NJW 1986, 1744 (1745). BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577). Habersack, WM 2008, 809 (811). BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575.

Gennen

1485

R Rz. 36

Einzelprobleme

vertrag bei Verzögerungen berechtigt, auch solche Fälle erfassen zu lassen, in denen „der im Rahmen der Erfüllung der ihm obliegenden Gebrauchsüberlassungspflicht als sein [des Leasinggebers] Erfüllungsgehilfe (§ 278 Satz 1 BGB) tätige Lieferant (…) die verzögerte Erstellung oder Abnahme der Sache zu vertreten“ habe1.

Insbesondere könne so das Insolvenzrisiko des Lieferanten nicht auf den Leasingnehmer abgewälzt werden. Der Leasinggeber habe aufgrund seiner „hervorgehobenen Stellung (…) als Eigentümer und Vermögensinhaber des Leasinggegenstandes mit seiner sich daraus herleitenden Gebrauchsüberlassungspflicht“ das Insolvenzrisiko des Lieferanten zu tragen2. Aus der besonderen Konstellation des IT-Projektleasings, bei der der Leasinggegenstand erst noch hergestellt werden müsse und von Mitwirkungshandlungen des Leasingnehmers abhänge, lasse sich nicht zwangsläufig eine andere Beurteilung herleiten. Die Leistungsfähigkeit und -willigkeit des Lieferanten könne vom Leasingnehmer nicht besser beurteilt werden als vom Leasinggeber. Folglich rechnet der BGH dem Leasinggeber im Ergebnis das Beschaffungs-/ Herstellungsrisiko zu. 36 Damit bleibt aber unklar, ob überhaupt und ggf. in welchem Umfang sich der Leasinggeber vom Beschaffungsrisiko freizeichnen kann. Das Verhalten des Lieferanten wird ihm zugerechnet, da dieser als sein Erfüllungsgehilfe betrachtet wird. Das gesamte Projekthandeln erfolgt durch den Erfüllungsgehilfen, so dass eine Freizeichnung in AGB voraussichtlich nur für solche Fälle erfolgen kann, in denen auch der Erfüllungsgehilfe eine Verzögerung nicht zu vertreten hat und auch sonst keine Umstände ersichtlich sind, die es dem Leasinggeber ermöglichen würden, das Beschaffungs-/Herstellungsrisiko auf den Leasingnehmer abzuwälzen. Anders ausgedrückt: Fälle, in denen der Leasingnehmer die Verzögerung zu vertreten hat, werden zum Rücktritt berechtigen. Da die Situation beim IT-Projektvertrag allerdings stark von der eines typischen Finanzierungsleasingvertrages abweicht, die Durchführung des IT-Projekts Jahre dauern kann und sein Erfolg von sehr vielen unterschiedlichen Faktoren abhängen kann, ist über eine Risikoumverteilung aus Sicht des Leasinggebers in jedem einzelnen Fall nachzudenken. Dies gilt jedenfalls im Softwareentwicklungsbereich, bei dem die Mitwirkung des Leasingnehmers unerlässlich ist und gleichzeitig eine Beurteilung, auf wessen Verschulden eine Verzögerung oder Unmöglichkeit der Fertigstellung beruht, sehr schwierig ist. Bei den meisten gescheiterten oder mit Problemen behafteten IT-Projekten stellt sich retrospektiv heraus, dass sowohl der Lieferant wie der Anwender in erheblichem Umfang ihre vertraglichen Pflichten nicht erfüllt haben. Nicht ausgeschlossen ist damit, dass eine Risikoabwälzung in Teilen auf den Leasingnehmer möglich sein könnte. Bis zur weiteren gerichtlichen Klärung dieser Frage bleibt dem Leasinggeber im Grundsatz nur die Möglichkeit individualvertragliche Regelungen zur Verteilung dieses Risikos zu treffen. 1 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577). 2 BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577).

1486

Gennen

Rz. 40 R

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

cc) Belassen des Leasinggutes beim Leasingnehmer/Keine Verantwortlichkeit für Störungen durch den Lieferanten Die Gebrauchsüberlassungspflicht ist in einem mietrechtlichen Dauer- 37 schuldverhältnis nicht allein mit der Überlassung des Mietobjekts erfüllt. Für die Dauer des Mietverhältnisses besteht die Pflicht zur Ermöglichung der Nutzung, insbesondere darf der Mieter nicht an der vertraglichen Nutzung ohne gerechtfertigten Grund gehindert werden1. Hindert der Lieferant den Leasingnehmer an der Nutzung des Gegenstan- 38 des, beispielsweise durch ferngesteuertes Abschalten o.ä., dann ist dieses Verhalten nicht ohne weiteres dem Leasinggeber im Sinne von §§ 278, 831 BGB zuzurechnen. Wurde der Lieferant nicht vom Leasinggeber beauftragt oder zur Verrichtung herangezogen, handelt dieser insoweit nicht (mehr) als Erfüllungs- oder Verrichtungsgehilfe des Leasinggebers. Der Leasinggeber ist, nachdem er das Projekt zum Gebrauch überlassen hat nur zur Nichtstörung dieses Gebrauchs verpflichtet, so dass die Störung gerade nicht zur Erfüllung der Vertragspflichten des Leasinggebers gehört und diesem deshalb auch nicht zugerechnet werden kann2. dd) Entrichtung der vereinbarten Vergütung/Abnahme aus dem IT-Projektvertrag Im Übrigen ist der Leasinggeber (aus dem IT-Projektvertrag) gegenüber dem 39 Lieferanten zur Zahlung der vereinbarten Vergütung verpflichtet. Der Leasinggeber kann dem Lieferanten allerdings die Mangelhaftigkeit der Leasingsache einredeweise i.S.v. § 320 BGB entgegen halten, auch dann, wenn er, wie i.d.R., alle Mangelhaftungsansprüche an den Leasingnehmer abgetreten hat3. Andernfalls hätte der Lieferant trotz bestehender Mängel einen Anspruch auf Vergütung. Zudem ist der Leasinggeber dem Lieferanten zur Zahlung der geltend ge- 40 machten Vergütung erst nach der Abnahme verpflichtet (§ 641 BGB). Hat der Leasinggeber die Rechte aus dem Werkvertrag an den Leasingnehmer abgetreten und nimmt der Leasinggeber dennoch das Werk ab, obwohl dieses noch offensichtliche/bekannte Mängel enthält, macht der Leasinggeber sich gegenüber dem Leasingnehmer nach allgemeinen Grundsätzen schadensersatzpflichtig, wenn und soweit diesem die Geltendmachung des Mangels nach § 634 Nr. 1–3 BGB wegen § 640 Abs. 2 BGB verwehrt ist.

1 OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (766). 2 OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (766). 3 BGH NJW 1971, 838; BGH v. 10.10.1994 – VIII ZR 295/93, NJW 1995, 187 (188).

Gennen

1487

R Rz. 41

Einzelprobleme

b) Hauptleistungspflichten des Leasingnehmers aa) Abnahme als Erfüllungsgehilfe des Leasinggebers 41 Zwar hat der Leasingnehmer gegenüber dem Leasinggeber als Vertragspartner eines Mietvertrages keine Abnahme zu erklären. Jedoch bedarf es im Verhältnis zwischen Leasingeber und Lieferant im IT-Projektvertrag bzw. Softwareerstellungsvertrag der Abnahme. Die hierzu notwendigen Prüfungen werden i.d.R. nicht vom Leasinggeber vorgenommen, sondern vom Leasingnehmer. Insoweit handelt dieser als Erfüllungsgehilfe des Leasinggebers1, der so seiner vertraglichen Abnahmeverpflichtung aus dem IT-Projektvertrag bzw. Softwareerstellungsvertrag nachkommt. Für etwaiges Verschulden des Leasingnehmers hat der Leasinggeber daher dem Lieferanten nach § 278 BGB einzustehen2. 42 Fraglich ist, ob der Leasingnehmer gegenüber dem Leasinggeber zur Abnahme als dessen Erfüllungsgehilfe verpflichtet ist, wenn nichts vereinbart ist. Diese Pflicht könnte sich zumindest konkludent aus der Dreiecksgestaltung ergeben, wenn der Lieferant, wie in IT-Projektverträgen regelmäßig, unmittelbar an den Leasingnehmer liefert. Allerdings ist der Leasingnehmer gerade nicht Vertragspartner des Lieferanten. Der Lieferant ist aber beim Werkvertrag regelmäßig auf eine Abnahme angewiesen, um die Zahlungsverpflichtung des Leasinggebers gegenüber dem Lieferanten auszulösen (§ 641 BGB). Es ist deshalb davon auszugehen, dass der Leasingnehmer jedenfalls gegenüber dem Lieferanten dazu beitragen muss, dass das Vertragsverhältnis (IT-Projektvertrag) „bis zur Abnahmebestätigung gedeiht“3. 43 Eine andere Frage ist, welches Verhalten des Leasingnehmers der Lieferant als Abnahme des Leasinggebers werten darf. In diesem Zusammenhang sind die allgemeinen rechtlichen Grundsätze zur Abnahme heranzuziehen. Der Lieferant, der unmittelbar an den Leasingnehmer liefert, weiß, dass der Leasinggeber die Sache nicht untersuchen konnte, sondern eine solche Untersuchung erst beim Leasingnehmer erfolgen wird. Da zudem auch der Lieferant von dem Dreiecksverhältnis profitiert, da er einen meist solventen Vertragspartner erhält und zudem ohne diesen das Geschäft oft nicht zustande gekommen wäre, kann nicht schon alleine die Übergabe an den Leasingnehmer als Abnahme gewertet werden. Obwohl also das Leasingobjekt seinem Vertragszweck (Überlassung an den Leasingnehmer) bereits zugeführt wird, ist alleine in der Übergabe keine Abnahme durch den Leasinggeber zu sehen. 1 BGH v. 14.3.1984 – VIII ZR 284/82, MDR 1984, 838 = NJW 1984, 2034; BGH v. 20.10.2004 – VIII ZR 36/03, MDR 2005, 201 = NJW 2005, 365 (366). 2 BGH v. 14.3.1984 – VIII ZR 284/82, MDR 1984, 838 = NJW 1984, 2034 (2036). 3 BGH v. 14.3.1984 – VIII ZR 284/82, MDR 1984, 838 = NJW 1984, 2034 (2036) – für den Fall, dass dem Leasingvertrag ein Kaufvertrag vorgeschaltet war, bei dem vereinbart wurde, dass der Käufer/Leasinggeber erst nach einer Untersuchung des Gegenstandes (vergleichbar mit der Abnahme) den Kaufpreis zu zahlen hat.

1488

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 47 R

bb) Abgabe einer Übernahmebestätigung I.d.R. legt der Leasinggeber dem Leasingnehmer – durch den Lieferanten – 44 eine sog. Übernahmebestätigung zur Unterzeichnung vor. Hierunter ist grundsätzlich die bloße Bestätigung des Empfangs von Ware zu verstehen; auf die Abgabe einer Übernahmebestätigung hat der Leasinggeber einen Anspruch nach § 368 Satz 1 BGB1. Insofern unterscheidet sich diese deutlich von einer Bestätigung oder Erklärung der Abnahme, welcher der darüber hinausgehende Erklärungsinhalt zukommt, dass die empfangene Leistung als vertragsgemäß anerkannt wird. Der Übernahmebestätigung werden häufig dennoch gleich zwei weitere 45 Funktionen in den Einkaufs-/Leasingbedingungen zugeordnet. Der Leasinggeber hält sich gegenüber dem Lieferanten des Leasingobjekts so lange hinsichtlich der Zahlung der Vergütung frei, bis der Leasingnehmer die Übernahme (bzw. Abnahme) bestätigt hat. Außerdem markiert die Übernahmebestätigung regelmäßig den Beginn der Zahlungspflicht der Leasingraten an den Leasinggeber. Die Übernahmebestätigung ist ihrer Rechtsnatur nach lediglich eine Quit- 46 tung i.S.d. § 368 BGB, kein Schuldanerkenntnis i.S.d. § 781 BGB2. Mit der Unterzeichnung durch den Leasingnehmer tritt eine Beweislastumkehr ein mit der Folge, dass der Leasingnehmer ab diesem Zeitpunkt die Unrichtigkeit der Erklärung gem. §§ 368, 363 BGB beweisen muss3. Dem Leasingnehmer wird aber durch die Abgabe der Erklärung nicht die Möglichkeit genommen, Primär- und Sekundäransprüche geltend zu machen. Die Bestätigung ist nicht als Anerkenntnis oder Verzicht auf Einwendungen anzusehen. Eine abweichende Vereinbarung, nach der die Übernahmebestätigung als Verzicht auf die Geltendmachung von Einwendungen (mangelhafte oder unvollständige Lieferung) zu sehen sein soll, ist nach § 307 Abs. 2 Nr. 1 BGB unwirksam4. Der Leasinggeber würde sonst zu einer Erklärung veranlasst, deren Voraussetzungen er zum Zeitpunkt der Abgabe der Erklärung noch gar nicht beurteilen könnte5. Bringt der Leasingnehmer bei einem durch den Lieferanten zu erstellenden Werk durch sein Verhalten (Unterschreiben der Übernahmebestätigung) zum Ausdruck, dass er dieses als vertragsgerecht akzeptiert, ist davon auszugehen, dass der Leasinggeber seine primäre Pflicht zur Überlassung des Leasinggegenstandes erfüllt hat, selbst wenn dieser Mängel aufweisen soll-

1 BGH v. 24.5.1993 – II ZR 36/92, MDR 1993, 854 = NJW-RR 1993, 1381 (1383). 2 BGH v. 5.7.1989 – VIII ZR 334/88, CR 1990, 189 m. Anm. Bokelmann = NJW 1989, 3222. 3 Marly, Praxishandbuch Softwarerecht, S. 298; Palandt/Weidenkaff, 67. Aufl., Einf. vor § 535 BGB Rz. 49. 4 BGH v. 1.7.1987 – VIII ZR 117/86, CR 1987, 591 = CR 1988, 111 m. Anm. Bokelmann = NJW 1988, 204 (206). 5 BGH v. 27.6.1990 – VIII ZR 72/89, CR 1990, 718 = NJW-RR 1990, 1462 (1465).

Gennen

1489

47

R Rz. 48

Einzelprobleme

te1. Vor diesem Hintergrund ist dem Leasingnehmer stets anzuraten, nicht ohne weiteres die regelmäßig von dem Leasinggeber vorformulierte Übernahmebestätigung unbesehen zu unterzeichnen. Vielmehr sollte er sich vorbehalten, nur für den nach seiner Einschätzung eindeutig vertragsgerecht erfüllten Teil der Lieferungen/Leistungen die Übernahme zu bestätigten oder aber die Übernahmebestätigung sonst in ihrer Reichweite zu beschränken. Der Anspruch nach § 368 Satz 1 BGB beinhaltet nur die Abgabe eines schriftlichen oder in elektronischer Form erteilten Empfangsbekenntnisses. Eine besondere Form kann nur bei vorliegendem berechtigtem Interesse nach § 368 Satz 2 BGB verlangt werden. Der Leasinggeber muss sich deshalb auch mit einer anderen als der vorformulierten Erklärungsform zufrieden geben, was auch dann gelten kann, wenn die vom Leasinggeber vorgegebene Formulierung vertraglich festgelegt ist. Die Berufung auf die vertraglich vereinbarte Form kann rechtmissbräuchlich sein2. Eine zu weit gehende Erklärung muss der Leasingnehmer jedenfalls nicht unterzeichnen3. Insbesondere ist er nicht zur „Abnahme“ verpflichtet, bis er Gelegenheit hatte die Sache ausreichend zu untersuchen. Ist also eine „Abnahme“ an die Übernahmeerklärung gekoppelt, dann kann der Leasingnehmer die Abgabe der Erklärung verweigern, bis er genügend Zeit zur Prüfung hatte4. 48 Die voreilige Unterzeichnung einer nicht richtigen oder ihrem Inhalt zu weit gefassten Übernahmeerklärung ist auch deshalb zu vermeiden, weil zu berücksichtigen ist, dass der Leasingnehmer sich gegenüber dem Leasinggeber durch Abgabe einer falschen Übernahmebestätigung u.U. schadensersatzpflichtig machen kann. Die Abgabe einer unrichtigen Übernahmebestätigung stellt eine (vor-)vertragliche Nebenpflichtverletzung dar, wenn der Leasinggeber aufgrund dieser die vereinbarte Vergütung aus dem IT-Projektvertrag an den Lieferanten zahlt5, ein etwaiger Rückerstattungsanspruch des Leasinggebers gegen den Lieferanten aufgrund dessen Insolvenz aber nicht durchgesetzt werden kann6. cc) Zahlung der Leasingraten 49 Der Leasingnehmer ist vertraglich zur Zahlung von (meist monatlichen) Leasingraten verpflichtet. I.d.R. wird die Zahlungspflicht erst mit vollständiger Erstellung des Werkes bzw. mit Gebrauchsüberlassung beginnen7. Ist nichts vereinbart, richtet sich der Beginn der Zahlungspflicht nach den §§ 535 ff. BGB. Dabei ist die Vollamortisation zugunsten des Leasinggebers

1 2 3 4 5 6

OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (765). BGH v. 17.2.1993 – VIII ZR 37/92, CR 1993, 491 = NJW 1993, 1381 (1383). OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (765). Schneider, Handbuch des EDV-Rechts, F Rz. 363. BGH v. 20.10.2004 – VIII ZR 36/03, MDR 2005, 201 = NJW 2005, 365 (366). BGH v. 1.7.1987 – VIII ZR 117/86, CR 1987, 591 = CR 1988, 111 m. Anm. Bokelmann = NJW 1988, 204. 7 Habersack, WM 2008, 809.

1490

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 52 R

zu bewirken1. Nicht Voraussetzung des Beginns der Zahlungspflicht ist jedoch eine Abnahme des Werkes durch den Leasingnehmer. Der Lieferant liefert zwar regelmäßig unmittelbar an den Leasingnehmer, nicht an den Leasingeber. Nichtsdestotrotz besteht zwischen Leasingnehmer und Leasinggeber kein Werk- sondern ein Mietvertrag. Nicht zwingende Voraussetzung für den Beginn der Zahlungspflicht ist, 50 dass der Leasinggeber das Werk gegenüber dem Lieferanten abgenommen hat; dies kann abweichend vereinbart werden. Der Leasingnehmer kann dann die Zahlung der Leasingraten auch nicht mit der Begründung verweigern die Lösung sei noch nicht gegenüber dem Lieferanten abgenommen. Selbst wenn vertraglich vereinbart sein sollte, dass der Leasingnehmer die Sache für den Leasinggeber untersuchen soll und ggf. für diesen, als dessen Erfüllungsgehilfe, die Abnahme gegenüber dem Lieferanten erklären soll, so hängt die Ratenzahlungspflicht doch nicht von der werkvertraglichen Abnahme ab. Die Zahlungsverpflichtung des Leasingnehmers beginnt trotz Lieferung nur 51 dann nicht, wenn die gelieferte IT-Lösung nicht der vertragsgemäß vereinbarten entspricht. Dann kann der Leasingnehmer dem Leasinggeber die Einrede des nichterfüllten Vertrages (§ 320 BGB) entgegen halten. In diesem Zusammenhang ist aber der Gedanke des § 640 BGB heranzuziehen, nämlich dann, wenn der Leasingnehmer durch sein Verhalten ausdrückt, dass er den Gegenstand als vertragsgemäß akzeptiert (z.B. Unterzeichnung einer Übernahmebestätigung, die die Aussage enthält, dass das Gelieferte dem Vereinbarten entspricht). Dies gilt auch dann, wenn die Lieferung/Leistung noch Mängel aufweist2. Solche Mängel sind, wenn die Gewährleistungsrechte vertraglich entsprechend abgetreten wurden, gegenüber dem Lieferanten geltend zu machen. Die Einrede des nichterfüllten Vertrages gegenüber dem Leasinggeber ist dann aber ausgeschlossen. Der Leasingnehmer kann nach Überlassung der IT-Lösung Mangelhaftungs- 52 rechte nur gegenüber dem/den Lieferanten geltend machen, wenn der Leasinggeber, wie regelmäßig, die eigene Haftung durch Abtretung der Gewährleistungspansprüche gegen den Lieferanten ausgeschossen hat. Daraus folgt auch, dass eine Einstellung der Zahlung der Leasingraten an den Leasinggeber nur dann erfolgen darf, wenn der Leasingnehmer den Mangel gegenüber dem Lieferanten geltend gemacht hat und zurückgetreten ist. Bestreitet der Lieferant das Bestehen des Rücktrittsrechts, muss der Leasingnehmer zunächst klageweise aus dem erklärten Rücktritt gegen den Lieferanten vorgehen und darf erst mit Rechtskraft die Zahlung der Leasingraten

1 BGH v. 14.3.2007 – VIII ZR 68/06, MDR 2007, 824 = NJW-RR 2007, 1066; FG Hamburg DStRE 2010, 687; Vollamortisation als „Garantieversprechen“: AGBKlauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 18. 2 OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (765).

Gennen

1491

R Rz. 53

Einzelprobleme

verweigern, vorläufig bereits mit Rechtshängigkeit1. Erst dann wird auch dem Leasingvertrag die Grundlage entzogen2. Vertreten wird zwar, dass mit der Schuldrechtsmodernisierung der Rücktritt als Mittel im Gegensatz zur früheren Wandlung genüge, eine Klageerhebung deshalb nicht erforderlich sei3. Weil der tatsächliche Wegfall der Geschäftsgrundlage aber erst mit Obsiegen des Leasingnehmers im Gewährleistungsstreit feststehe, bzw. mit Rechtskraft des Urteils, sei nach dem BGH auch nach der Schuldrechtsmodernisierung eine Verweigerung der Zahlung von Leasingraten vor Rechtshängigkeit mit Blick auf die Interessenlage des Leasinggebers nicht gerechtfertigt4. Eine andere Sichtweise hätte auch zur Folge, dass der Leasinggeber die Sache, die sich regelmäßig beim Leasingnehmer befindet, untersuchen müsste, um festzustellen, ob dem Leasingnehmer ein Rücktrittsrecht und damit auch ein Ratenzahlungsverweigerungsrecht zusteht5, so dass dem BGH zuzustimmen ist. 53 Im Übrigen sei darauf hingewiesen, dass bei einem Geschäftsbesorgungsoder Darlehensvertrag der Amortisationsanspruch des Leasinggebers auch bei Nicht- oder Schlechterfüllung des Lieferanten entsteht6. 2. Regelungen zur Risikoverteilung in AGB a) Übernahmeerklärung 54 Wie bereits erwähnt ist die Vereinbarung in AGB, nach der der Übernahmebestätigung eine über § 368 BGB hinausgehende Bedeutung zugedacht werden soll, nach § 307 Abs. 2 Nr. 1 BGB unwirksam. Insbesondere gilt die Abnahme- bzw. Übernahmebestätigung nicht als Verzicht auf die Geltendmachung von Einwendungen (mangelhafte oder unvollständige Lieferung)7. Vereinbarungen nach denen die Ratenzahlungspflicht des Leasingnehmers „unbedingt und uneingeschränkt“ einsetzt, nachdem der Leasingnehmer die Übernahmeerklärung abgegeben hat, sind unwirksam, weil dadurch eine vollständige Risikozuweisung zulasten des Leasingnehmers erfolgt8. Dies ist jedenfalls dann anzunehmen, wenn hierbei nicht der Fall ausgeschlossen ist, dass die Sache (trotz unterzeichneter Übernahmebestätigung) nicht an den Leasingnehmer übergeben worden ist oder nicht mehr 1 BGH v. 16.6.2010 – VIII ZR 317/09, MDR 2010, 912 = NJW 2010, 2798 (2800); OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (765). 2 BGH v. 19.2.1986 – VIII ZR 91/85, CR 1986, 458 = NJW 1986, 1744 (1745). 3 Vgl. BGH mit Verweis auf Literaturmeinungen BGH v. 16.6.2010 – VIII ZR 317/09, MDR 2010, 912 = NJW 2010, 2798 (2800). 4 BGH v. 16.6.2010 – VIII ZR 317/09, MDR 2010, 912 = NJW 2010, 2798 (2800). 5 MünchKomm/Koch, BGB, Band 3; Finanzierungsleasing, Rz. 114. 6 MünchKomm/Koch, BGB, Band 3; Finanzierungsleasing, Rz. 27. 7 BGH v. 1.7.1987 – VIII ZR 117/86, CR 1987, 591 = CR 1988, 111 m. Anm. Bokelmann = NJW 1988, 204 (206). 8 BGH v. 1.7.1987 – VIII ZR 117/86, CR 1987, 591 = CR 1988, 111 m. Anm. Bokelmann = NJW 1988, 204 (206); Schneider, Handbuch des EDV-Rechts, F Rz. 358.

1492

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 56 R

übergeben werden kann, der Leasinggeber also nicht erfüllt hat oder erfüllen kann. Auch der Schadensersatzanspruch, der aufgrund der unrichtigen Abgabe der Übernahmebestätigung entsteht, rechtfertigt keine vollständige Erfüllungsleistung des Leasingnehmers1. Eine einseitige Risikozuweisung ist schon deshalb nicht gerechtfertigt, weil regelmäßig der Lieferant bei der Lieferung von der Mangelhaftigkeit oder Unvollständigkeit der Sache weiß. Für dieses Mitverschulden hat der Leasinggeber nach § 278 BGB einzustehen2. b) Sach- und Preisgefahr Die Besonderheiten des Finanzierungsleasings rechtfertigen es, von miet- 55 rechtlichen Vorschriften in gewissem Umfang abzuweichen. Dies betrifft die Abwälzung der Sach- und Preisgefahr auf den Leasingnehmer. Dieser hat das Hauptinteresse an der Benutzung des Leasinggutes und kann sich zudem gegen die Sach- und Preisgefahr versichern. Eine Behandlung des Leasingnehmers wie einen Käufer ist daher gerechtfertigt3. Die Abwälzung hat die Folge, dass der Leasinggeber nicht für Ersatz zu sorgen hat, wenn die Sache nach Beginn der Gebrauchsüberlassung untergeht, der Leasingnehmer aber gleichzeitig zur Entrichtung der vereinbarten Leasinggebühren verpflichtet bleibt. Der Leasinggeber finanziert lediglich die Investitionsentscheidung des Leasingnehmers, weshalb der Leasinggeber nur für die Beschaffung nicht aber für die ununterbrochene Gebrauchsgewährung verpflichtet ist4. Hat sich der Leasingnehmer gegen den Untergang versichert, stehen die Zahlungen dem Leasinggeber zu. Etwaige (Vollamortisierungs-) Überschüsse müssen nicht an den Leasingnehmer ausgezahlt werden, sondern verbleiben beim Leasinggeber5. Die besondere Interessenlage beim ITProjektleasing rechtfertigt keine andere Beurteilung. c) Mangelhaftungsrechte Der Leasinggeber kann sich in AGB von der Sachmängelhaftung des Leasingnehmers hinsichtlich der Mängel an der Leasingsache durch Abtretung der eigenen Mangelhaftungsansprüche gegen den Lieferanten aus dem Be-

1 BGH v. 1.7.1987 – VIII ZR 117/86, CR 1987, 591 = CR 1988, 111 m. Anm. Bokelmann = NJW 1988, 204 (206); AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 66. 2 BGH v. 1.7.1987 – VIII ZR 117/86, CR 1987, 591 = CR 1988, 111 m. Anm. Bokelmann = NJW 1988, 204 (206, 207); AGB-Klauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 66. 3 BGH v. 30.9.1987 – VIII ZR 226/86, CR 1987, 846 = NJW 1988, 198 (200); AGBKlauselwerke/Graf von Westphalen, Klauselwerke/Leasing, Rz. 16. 4 BGH v. 30.9.1987 – VIII ZR 226/86, CR 1987, 846 = NJW 1988, 198 (200); MünchKomm/Koch, BGB, Band 3; Finanzierungsleasing, Rz. 88. 5 BGH NJW 2008, 990.

Gennen

1493

56

R Rz. 57

Einzelprobleme

schaffungsvertrag freistellen1. Voraussetzung ist aber, dass diese unbedingt und vorbehaltlos übertragen werden2 bzw. die Interessen des Leasingnehmers angemessen gewahrt werden3. Dies gilt nicht nur, wenn der Beschaffungsvertrag einen Kaufvertrag darstellt, sondern auch für einen Werkvertrag4. 57 Die besondere Situation des Leasingvertrages rechtfertigt eine solche Freizeichnung von den Mangelhaftungsrechten, weil der Leasinggeber die Bedürfnisse des Leasingnehmers hinsichtlich der Auswahl des Leasinggutes nicht beurteilen kann, genauso wenig wie die Vertragsgemäßheit bzw. Mangelfreiheit der Leistung5. Dies gilt erst Recht beim IT-Projektleasingvertrag, dem eine komplexe Softwareerstellung nach den individuellen Bedürfnissen des Leasingnehmers vorausgeht. d) Instandhaltungspflicht 58 Bleibt der Leasinggeber Eigentümer des Leasinggegenstandes, hat er ein Werterhaltungsinteresse, welches eine AGB-rechtliche Verpflichtung des Leasingnehmers zur Wartung und Instandhaltung rechtfertigt. Dies gilt insbesondere bei wartungsintensiven Leasinggegenständen wie Computeranlagen. Auch die Verpflichtung des Abschlusses eines Wartungsvertrages darf im Rahmen des Kopplungsverbotes vereinbart werden6. e) Gekoppelte Übernahme- und Wiedereintrittsklauseln 59 Oftmals wird zusammen mit dem Rücktrittsrecht des Leasinggebers vereinbart, dass der Leasingnehmer nach dem Rücktritt des Leasinggebers in den Vertrag mit dem Lieferanten (wieder) einzutreten und alle bis dahin erstellten Bestandteile (zum Selbstkostenpreis) zu übernehmen hat. Im Mietrecht werden bei einem Rücktritt vom Vertrag vor Übergabe der Mietsache grundsätzlich beide Parteien von ihren Leistungspflichten frei. Damit stellt eine Wiedereintritts- und Übernahmeklausel eine erhebliche Abweichung vom gesetzlichen Leitbild des Mietrechts dar. Dies gilt jedenfalls dann, wenn der Rücktritt bzw. der Wiedereintritt nicht auf einer Verzögerung beruht, die der Leasinggeber zu vertreten hat. Der BGH hat in der Entscheidung vom 29.10.2008 ausdrücklich offen gelassen, ob eine Unwirksamkeit einer solchen Wiedereintritts- und Übernahmeklausel auch dann vorliegen würde, 1 BGH NJW1986, 1744; OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (764); das gilt auch gegenüber Verbrauchern BGH v. 20.6.1984 – VIII ZR 131/83, MDR 1985, 315 = NJW 1985, 129 (130). 2 OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (764). 3 BGH v. 19.2.1986 – VIII ZR 91/85, MDR 1986, 668 = CR 1986, 458 = NJW 1986, 1744. 4 OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (765). 5 BGH v. 20.6.1984 – VIII ZR 131/83, MDR 1985, 315 = NJW 1985, 129 (130); OLG Brandenburg v. 4.6.2008 – 4 U 167/07, CR 2008, 763 (764). 6 MünchKomm/Koch, BGB, Band 3, Finanzierungsleasing, Rz. 95.

1494

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 63 R

wenn das auslösende Rücktrittsrecht auch in anderen Fällen als bei Verschulden des Leasinggebers eingeräumt worden wäre. Welche Rücktrittsfolgen insoweit wirksam vereinbart werden können, bleibt weiter unklar1. Unwirksam ist mithin folgende Klausel:

Die Leasinggesellschaft ist berechtigt, im Falle des Rücktritts (…) alle (…) erbrachten Lieferungen und Leistungen (…) zum Selbstkostenpreis (…) anzudienen. Zu diesem Zweck bietet der Kunde schon heute verbindlich an, (…) zu diesem Zeitpunkt gelieferte Hard- und Software (…) abzukaufen. (…). Leasinggesellschaft und Kunde sind sich darüber einig, dass der Kunde infolge des Rücktritts der Leasinggesellschaft vom Vertrag wieder in die Beschaffungsverträge mit den Lieferanten anstelle der Leasinggesellschaft einritt.

Mit Blick auf die Rechtsprechung zu Leasingverträgen außerhalb des IT-Be- 60 reichs hält der BGH in der Entscheidung vom 29.10.2008 auch für Leasingverträge bei IT-Projekten an seiner Auffassung fest, dass eine Drittverweisung hinsichtlich des Lieferanteninsolvenzrisikos unzulässig ist. Der Leasinggeber als Eigentümer der Leasingsache hat diese dem Leasingnehmer zum Gebrauch zu überlassen. Der Gebrauchsüberlassungspflicht kann sich der Leasinggeber „insbesondere im Hinblick auf das Insolvenzrisiko des Lieferanten nicht entziehen“2. Das Risiko, dass der Rückzahlungsanspruch bei Rücktritt aufgrund der In- 61 solvenz des Lieferanten nicht erfüllt werden kann, kann auch im unternehmerischen Verkehr in AGB nicht auf den Leasingnehmer abgewälzt werden3. Dies gilt erst Recht, wenn der Leasingnehmer die Sache wegen der Verzögerung der Erstellung (welche ggf. das Rücktrittsrecht ausgelöst hat), nicht überlassen bekommen hat. Auch die beim Projektfinanzierungsleasingvertrag vorliegenden Besonder- 62 heiten, insbesondere die Erforderlichkeit der Mitwirkung des Leasingnehmers, rechtfertigen keine andere Beurteilung der Nichtabwälzbarkeit des Insolvenzrisikos. Obwohl der Leasingnehmer maßgeblich bei der Erstellung des Leasinggegenstandes beteiligt ist, stellt die rechtzeitige Erstellung der beauftragten Software oder IT-Lösung keinen „leasingtypischen Beschaffungsvorgang“ dar, dessen Risiko den Leasingnehmer trifft4. Der Leasingnehmer kann in der Regel die Leistungsfähigkeit- und -willigkeit des Lieferanten nicht besser beurteilen als der Leasinggeber. Ein Son1 2 3 4

Koch, Anm. zum Urteil des BGH CR 2009, 575, LMK 2009, 273510. BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577). BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577). Vgl. zur Gegenansicht: Habersack, WM 2008, 809 (812) der das Scheitern des Projekts zum „leasingtypischen Beschaffungsvorgang“ zählt, dessen Risiko dem Leasingnehmer zuzurechnen sei.

Gennen

1495

63

R Rz. 64

Einzelprobleme

derfall, bei dem es gerechtfertigt ist, dem Leasingnehmer das Beschaffungsrisiko zuzuteilen, liegt jedenfalls dann nicht vor, wenn der Leasinggeber maßgeblichen Einfluss auf die Auswahl und Beauftragung der Lieferanten hat. Dies gilt auch dann, wenn der Leasinggeber erst nach Beschaffungsvertragsschluss zwischen Leasingnehmer und Lieferant in den Beschaffungsvertrag für den Leasingnehmer eintritt, der Leasinggeber sich aber für weitere Lieferanten die „im Rahmen der Projektarbeit (…) die Hardware und Software bereitstellen oder die bei der Realisierung der Systemlösung beratende oder unterstützende Aufgaben übernehmen sollen“ erheblichen Einfluss auf die Auswahl einräumten lässt1. 64 Habersack2 vertritt die Auffassung, dass es verfehlt wäre, die Kauf-, Erstattungs- und Wiedereintrittsklausel an den für die Mangelhaftigkeit des Leasinggutes entwickelten Vorgaben zu messen. Es bliebe dann unberücksichtigt, dass die durch die Mangelhaftigkeit des Leasinggutes bestehende Pflichtverletzung des Lieferanten zugleich eine Pflichtverletzung des Leasinggebers gegenüber dem Leasingnehmer begründe. Schließlich habe der Leasingnehmer den Lieferanten ausgewählt. Letztlich würde der Leasingnehmer wieder nur so gestellt, als wenn der Leasinggeber nie in das Geschäft zwischen Lieferant und Leasingnehmer eingetreten wäre. Das Scheitern des Projekts sei ein Risiko, welches vom Leasinggeber nicht zu verantworten und klar dem leasingtypischen Beschaffungsvorgang zuzuordnen und damit dem Leasingnehmer zuzuschreiben sei3. Der BGH hat diese Auffassung aber aus den oben genannten Gründen ausdrücklich abgelehnt. 65 Auch andere Stimmen in der Literatur gehen davon aus, dass es regelmäßig der Leasingnehmer sei, der den Lieferanten aussuche. „Hafte (zukünftig) der Leasinggeber für das Insolvenzrisiko des Lieferanten, würde sich der Leasingnehmer den preisgünstigeren und bonitätsschwächeren Lieferanten aussuchen, da dieser Aspekt für ihn keine Relevanz habe4.“ 66 Zwar spricht das Eintrittsmodell in der Tat eher dafür, dass der Leasingnehmer den Lieferanten ausgesucht hat. Da es ihm aber darum geht eine IT-Lösung zu erhalten und dies meist zeitnah, wird ihm auch daran gelegen sein, einen solventen Softwarehersteller zu beauftragen. Der BGH hat zudem recht damit, dass der Leasinggeber genauso gut beurteilen kann wie der Leasingnehmer, ob der Lieferant zu leisten in der Lage ist oder ob hinsichtlich des Lieferanten ein Insolvenzrisiko besteht. Zudem ist der Leasinggeber nicht selten noch weniger auf das Geschäft insgesamt angewiesen als der Leasingnehmer, der die IT-Lösung benötigt, so dass er auch nicht unter einem höheren Abschlussdruck steht. Nicht selten ist es auch so, dass der Lieferant einen Leasinggeber vorschlägt, Lieferant und Leasinggeber dem-

1 2 3 4

BGH v. 29.10.2008 – VIII ZR 258/07, CR 2009, 79 = NJW 2009, 575 (577 f.). Habersack, WM 2008, 809 (812). Habersack, WM 2008, 809 (812). Weber, NJW 2009, 2927 (2931).

1496

Gennen

Leasing bei Softwareerstellungsprojekten (IT-Projektleasing)

Rz. 71 R

nach bereits einen Rahmenvertrag o.ä. abgeschlossen haben. In diesem Fall ist dem Auswahlargument jedenfalls die Grundlage entzogen. Im Übrigen entspricht der Wiedereintritt des Leasingnehmers in den Be- 67 schaffungsvertrag jedenfalls dann nicht seinem „typischen Interesse“, wenn der Erwerb der bereits erbrachten (Teil-)Leistungen für ihn zum Zeitpunkt des Widereintritts nutzlos ist. Diese Möglichkeit wäre in AGB durch die Aufnahme einer Ausnahme von der Widereintrittsverpflichtung abzubilden. 3. Rechtseinräumung Der Leasinggeber muss sicherstellen, dass er gemäß dem Beschaffungsvertrag/IT-Projektvertrag auch dazu berechtigt ist die IT-Lösung, soweit Rechte des geistigen Eigentums, insbesondere Urheberrechte bzw. urheberrechtliche Nutzungs- und Verwertungsrechte, betroffen sind, dem Leasingnehmer zum Gebrauch zu überlassen.

68

Der Leasinggegenstand wird dem Leasingnehmer beim Finanzierungslea- 69 sing typischer Weise auf Zeit überlassen, so dass der Leasinggeber berechtigt sein muss, die IT-Lösung dem Leasingnehmer zu vermieten. Zwar ist beim Finanzierungsleasing hinsichtlich des Computerprogramms grundsätzlich davon auszugehen, dass Erschöpfung eintritt, da das Leasinggut endgültig aus der Hand gegeben wird1. Das Vermietrecht ist aber nach § 69c Nr. 3 Satz 2 UrhG von der Erschöpfung ausgenommen, so dass dem Leasinggeber auch hinsichtlich des Computerprogramms ein Vermietrecht als ein dinglich eigenständiges Nutzungsrecht eingeräumt sein muss. Außerdem müssen die Nutzungsrechte unter Beachtung der §§ 31 ff. UrhG 70 und §§ 69a ff. UrhG so ausgestaltet sein, dass der Leasingnehmer die IT-Lösung auch so wie beabsichtigt nutzen kann (z.B. Vervielfältigungsrechte/ Mehrplatzlizenz etc.), bzw. muss der Leasinggeber diese dem Leasingnehmer einräumen oder auf diesen übertragen dürfen. Während beim Eintrittsmodel davon auszugehen ist, dass der Leasingneh- 71 mer sich die Nutzungsrechte bei Vertragsschluss mit dem Lieferanten – so wie er sie benötigt – hat einräumen lassen, ist anderseits hier besonders darauf zu achten, dass der Leasinggeber (also der Vertragspartner des Lieferanten) die Nutzungsrechte übertragen bzw. einräumen und die IT-Lösung vermieten darf. Ist dies vertraglich nicht geregelt, ist dies jedenfalls dann mit dem Lieferanten explizit zu vereinbaren, wenn der Lieferant sich nicht ausdrücklich mit dem Eintritt des Leasinggebers in den Vertrag einverstanden erklärt hat. Diese Fallkonstellation ist etwa denkbar, wenn Lieferant und Leasingnehmer bei Vertragsschluss des Beschaffungsvertrags noch keine Fremdfinanzierung geplant hatten, der Leasingnehmer sich das Recht zur

1 Wandtke/Bullinger/Grützmacher, Urheberrecht, § 69c Rz. 30.

Gennen

1497

R Rz. 72

Einzelprobleme

Vertragsübertragung aber (bei AGB im Rahmen der Wertung des § 309 Nr. 10 BGB) hat einräumen lassen. 72 Hat der Leasinggeber sich ausdrücklich mit der Übernahme des Vertrages durch den Leasinggeber/Fremdfinanzierung einverstanden erklärt, ist allerdings davon auszugehen, dass das Recht zur Vermietung an den Leasingnehmer damit konkludent eingeräumt wurde. Dies gilt erst recht, wenn der Beschaffungsvertrag von Anfang an zwischen dem Lieferanten und dem Leasinggeber geschlossen wurde und/oder der Lieferant von Anfang an wusste, dass die IT-Lösung zu Zwecken des Leasings überlassen wird1. 73 Wird allerdings der Vertrag von Anfang an zwischen Leasinggeber und Lieferant geschlossen, ist hier wiederum besonderes Augenmerk auf die Rechteeinräumung im Sinne der Nutzungsabsicht des Leasingnehmers zu legen.

1 Wandtke/Bullinger/Grützmacher, Urheberrecht, § 69c Rz. 43.

1498

Gennen

Stichwortverzeichnis Die fettgedruckten Buchstaben verweisen auf die Kapitel, die Zahlen auf die Randziffern innerhalb der Kapitel. Abänderungsbereitschaft – AGB-Klausel/Individualvereinbarung J 41 ff. Abbruch – Rechtsfolgen G 26 – Vertragsverhandlungen G 22 Abfindung – Aufhebungsvertrag E 198 Abgeltungstheorie – Erfindervergütung E 115 f. Ablehnungsandrohung G 203, 362, 393 – Nacherfüllungsanspruch D 292 Ablieferung – Standardsoftware G 317 ff. Abmahnung – Kündigung E 191 Abnahme B 75 ff., 123 f. – agile Softwareentwicklung D 114 – Anbieterinteresse C 361 ff. – Änderungsverlangen G 280 – Anforderungs-/Leistungsbeschreibung G 158 – Anwenderinteresse C 359 f. – Auswirkungen des § 651 BGB G 327 – Bedeutung D 277 ff. – Begriff G 318 ff. – Beweislastumkehr G 324 – Datenschutz G 341 – Erfüllungsanspruch D 278 – Erfüllungsgehilfe des Leasinggebers R 41 ff. – EVB-IT System N 193 – Fehlen des Pflichtenheftes D 152 – fehlende D 431 – Festlegung der Kriterien D 204 – Fiktion D 215 ff.; G 337, 340 – Finanzierungsleasing R 40 – Fristen D 279 – Fristsetzung D 180 – Funktionsprüfung D 198, 222 – Gefahrübergang G 327 – gemeinsames Protokoll D 199 – Implementierung von Standardsoftware G 79 – Kaufrecht D 194 – Mangelbegrenzung C 335 – Minderung D 281 – Mitwirkungsleistungen G 219 – Muster, Vertragsklausel D 494 ff. – Musterformulierung zur Abnahmeerklärung G 337 – Musterformulierung zur Teilabnahme G 337 – Pflichtenheft C 21

– Planungsphase C 182, 332 f. – Planungsprozess C 203 ff. – Probebetrieb und Produktivbetrieb D 200 ff. – Standardsoftware G 317 ff. – stillschweigende Abnahme D 207 ff.; G 338 f. – Übernahmebestätigung R 44 ff. – Umkehr der Beweislast C 333 – Verfahren D 194 ff. – Vergütung G 323 – Verhalten R 43 – Verjährung D 343 – Verjährungsbeginn B 58 f. – Verjährungsfristen C 374 ff. – vertragliche Pflichten D 194 ff. – vertragliche Regelung D 196 – Vertragsklauseln D 205 f. – Wirkungen G 321 ff. – Zahlungsmodalitäten R 50 – Zeitpunkt D 195 Abnahme, Planungsprozess – Risiken C 204 – Untersuchungs- und Rügepflichten C 204 – Verjährungsfrist für Mängel C 204 Abnahmeklauseln – Anordnung einer Abnahme D 218 – Fälligkeit D 219 – Fiktion einer Abnahme D 216 – Funktionsprüfung D 222 – Teilzahlung D 219 – Verjährung D 219 ff. – Wirksamkeit D 217 ff. Abnahmekonzept – Prüfungsstandards 880 Q 206 Abnahmeprotokoll D 199 Abnahmeverpflichtung – Werkunternehmer, freier Mitarbeiter E 289 Abnehmerverwarnung A 400 ff. Abnutzung – Software I 35 Abrechnungsmodalitäten – Arbeitnehmerüberlassung E 240 Abrechnungssoftware – Beratungspflichten D 19 Absageschreiben – Teilnahmewettbewerb N 236 Abschlagszahlung – Implementierung von Standardsoftware G 79 – nach Projektfortschritt C 370 – Werkvertrag D 68

1499

Stichwortverzeichnis Abschluss der Arbeiten – Versicherungsschutz O 97 ff. Abschlusszwang – Softwarepflegevertrag I 53 Abschreibung – Software P 7 Absichtserklärung – aufzunehmende Punkte G 25 – Anspruch auf Vertragsschluss D 41 – Auslegung D 35 – Exklusivität D 38 – Geheimhaltungspflichten G 23 ff. – Geheimhaltungsvereinbarung D 39 – gescheiterte Vertragsverhandlungen D 22 – Inhalt D 456 – Regelung zum Aufwendungsersatz D 37 – Überschriften D 40 – unmotivierter Verhandlungsabbruch D 35 – Verhandlungsstadium G 23 ff. – vorvertragliche Beziehungen D 34 ff. – Zusammenfassung der Rechtspflichten D 34 – Zweck D 36 Absorptionstheorie – gemischter Vertrag G 116 Abwasseranlage – Versicherungsschutz O 72 Abwicklung – Rücktritt D 301 ff. Abzugsfranchise O 39 Access-Provider-Vertrag B 100 Access-rights siehe Zugangsrechte Add-ons – Implementierung von Standardsoftware G 35 – Nutzungsrechte G 298 ff. AfA-Tabelle – Software P 7 Allgemeine Geschäftsbedingungen – Ablehnungsandrohung G 362 – Abnahmeklauseln D 205 f.; siehe auch dort – Abwälzung des Beweislastrisikos, Mängelbeseitigungskosten I 187 – Änderung der Software L 8 – Anwendung E 10 – Arbeitsvertrag E 3 – Ausschluss der Quellcode-Herausgabe L 21 – Ausschluss des UN-Kaufrechts F 38 – Beschränkung der Gewährleistung G 374 – Datenschutz F 70 ff. – Dokumentation D 132 – England/Frankreich/Schweiz F 31 – entgangener Gewinn B 67 – EU-Standardvertragsklausel, Auftragsdatenverarbeitung C 439

1500

– formularmäßige Verpflichtung zur Mängelbeseitigung I 172 – Garantie G 169 – Geltendmachung von Rechten durch Dritte D 488 ff. – Grenzen F 29 ff. – Haftungsausschluss/-beschränkung G 411 ff. – Haftungsfreizeichnung K 25; siehe auch Freizeichnungs-/Begrenzungsklauseln – Implementierung von Standardsoftware G 35 – individuelle Abrede im Softwarepflegevertrag, Mängelhaftungsentgelt I 155 ff. – Insolvenzfestigkeit L 50 f., 149 – Kardinalpflichten, Haftungsbeschränkung G 412 – Klausel zur Nacherfüllungspflicht D 509 f. – Klauselwirksamkeit bei Gewährung anderer rechtlicher Vorteile I 174 – Kündigungsklauseln D 451 ff. – Mängelbeseitigung nach Fristablauf I 198 – Mitwirkungshandlungen des Kunden D 231 – Mitwirkungspflichten statt Obliegenheiten D 241 ff. – Nacherfüllungsanspruch D 366 – Onlinevertrag C 99 – Open Source-Software A 368 ff. – Organisationsstruktur D 467 ff. – Pauschalvergütung B 67 ff. – Pflegelaufzeit I 311 ff. – Preisanpassung I 206 ff., 224 ff. – Projekt-Verträge C 1 – Rechtsfolgen bei Mängeln B 62 – Rücksichtnahme, Preisanpassung I 209 – Rücktrittsrecht des Anwenders I 123 – Schriftformklauseln D 477 ff. – Systemumgebung I 375 ff. – Transparenz bei Copyleft-Lizenz A 359 – unangemessene Benachteiligung, Softwarepflege-, Softwareüberlassungsvertrag I 173 – UN-Kaufrecht F 33 ff. – USA F 30 – Vergütung bei Kündigung D 442 – Vergütungsregelungen D 189 ff. – Verhandlungsstadium G 14 – Verjährung B 57 ff.; D 337 ff. – verschuldensunabhängige Haftung I 171 – Vertragsstrafen D 409 ff. AGB-Klausel – Anschein J 22 ff. – Auftraggeber als Verwender J 17 – Aushandeln J 39 ff. – beiderseitiges Einbeziehungsverlangen J 25 – Dissens J 31 f.

Stichwortverzeichnis – – – –

Einbeziehungsgrundsatz J 26 Freizeichnung in AGB R 36 gesetzesfremder Kerninhalt J 59 gesetzesfremder Kerninhalt ausgehandelt J 33 – Gleichförmigkeit J 7 – Individualvereinbarung J 1 ff. – juristische Kenntnisse J 44 – kaufmännisches Bestätigungsschreiben J 27 – Kollision von Vertragsbedingungen J 29 – Kongruenz-Prinzip J 30 – nachteilig für Auftraggeber J 31 – nachteilig für Auftragnehmer J 32 – Obliegenheitsprüfung J 57 ff. – planmäßige Verwendung J 66 – Preiszugeständnisse J 42 – Rationalisierungseffekt J 14 – sachliche Notwendigkeit J 61 f. – Schadensersatzanspruch J 58 – Stellen bei Vertragsschluss J 15 ff. – unabdingbare Klausel J 60 – unveränderte Übernahme einer Klausel J 36 ff. – Vertragsbedingung J 5 ff. – Vielzahl von Verträgen J 9 ff. – Vorformulieren J 6 ff. AGB-Kontrolle – nach Preisklauselgesetz I 218 ff. Agile Methodik B 108; F 19 Agile Verfahren – Abnahme D 114 – Änderungswünsche C 155 – Anwendungsvoraussetzungen C 117 ff. – Aufklärung C 148 – Contra-Indikatoren C 118 – Dokumentation D 111 f. – Erarbeitung des Leistungskatalogs C 115 – Ergänzung des Ausführungsstandards C 151 ff. – extreme Programming C 128 ff. – Funktionsmangel C 148 – Grundlagen C 126 – kurze Planungs- und Entwicklungsphasen C 126 – Liste der Voraussetzungen C 118 – Manifest C 124 – mittlerer Ausführungsstandard C 142 ff. – Mitwirkung des Anwenders G 225 – Mitwirkung des Kunden D 116 – moderne Vorgehensmodelle C 113 ff. – personenbezogene Daten C 434 – Pflichtenheft C 114, 142 ff. – Pflichtenverteilung C 74 ff. – Prinzipien C 125 – Prioritäten C 125 – Projektmethoden C 117 – Prototyping C 120 ff. – rechtliche Einordnung D 108 ff. – Scrum C 131 ff.

– Software-Bewertung Q 131 ff. – Umkehrung der Phasenabfolge C 181 – Vertragszweck C 150 – Wasserfallmodell C 115, 119 – Zielrichtung D 108 – Zwischenziele D 108 AiF-Förderung – Zuwendungsbestimmungen M 68 Akteneinsicht – Nachprüfungsverfahren N 332 ff. Aktienoptionen – Vergütungsbestandteil E 17 Aktivitäten- und Fristenplan – Mitwirkung des Kunden C 329 – Projekt-Verträge C 328 ff. – Verfeinerungen C 330 Algorithmen – ergänzender Leistungsschutz A 272 – Urheberrechtsschutz A 33 ff. Aliud – Abgrenzung zu neuer Software, BGH I 415 – Lieferung D 275 Allgemeines Persönlichkeitsrecht O 14 Altdatenübernahme – Entwicklung eines Übernahmeprogramms D 101 – Implementierung von Standardsoftware G 144 f. – Mitwirkungsleistungen G 219 – Musterformulierung G 144 – Notwendigkeit G 145 – rechtliche Einordnung D 101 ff. – Standardprogramm D 106 – vertragliche Pflichten D 52 – Vertragsgegenstand D 102 – zusätzlicher Leistungsaspekt D 107 Alternativangebote – Tarifwahl J 63 f. Alternativkonzepte – abschließende Bemerkungen O 277 – Auslandsschäden O 254 – Datenschäden O 255 f. – Erweiterung des Versicherungsschutzes O 254 ff. – fehlgeschlagene Installation O 266 – mitversicherte Unternehmen O 253 – Nachhaftungsversicherung O 270 ff. – Pflichtwidrigkeitsklausel O 269 – Produkt-Leistungsrisiko O 274 ff. – Rückwärtsversicherung O 273 – Schutzrechtsverletzung O 258 ff. – Softwareviren O 265 – Strafrechtsschutz O 268 – Tätigkeitsschäden O 257 – Umwelteinwirkung O 264 – Urheberrechtsverletzungen O 258 ff. – Verjährungsverlängerung O 267 – versicherte Schadenarten O 252 – versichertes Risiko O 251 – Verzug O 262 f.

1501

Stichwortverzeichnis – Wettbewerbsverletzung O 258 ff. Altersversorgung, betriebliche – Aufhebungsvertrag E 198 American Arbitration Association, AAA F 52 Amortisation – Vereitelung, Unlauterkeit A 285 f. Anbieten – ergänzender Leistungsschutz A 266 – Verwertungsrechte A 87 Anbieter – Interessen bei Abnahme/Freigabe C 361 ff. – Leistungen bei Implementierung G 129 ff.; siehe auch Anbieterleistungen – Softwarepflegevertrag I 2 ff. – Vertragsgestaltung G 63 ff. Anbieterleistungen – Altdatenübernahme G 144 f. – Analyse/Konzeption G 138 – Customizing der Standardsoftware G 139 ff. – Dokumentation G 231 ff. – Einweisung G 148 ff. – einzusetzendes Personal G 258 f. – Erstellung eines Pflichtenhefts G 135 ff. – Feinspezifikation G 135 ff. – Form der Software G 133 ff. – Go-Life Support G 151 – Installation G 146 f. – Lieferung der Standardsoftware G 133 ff. – Migration G 144 f. – Mitarbeiterqualifikation G 258 f. – Projektumsetzung G 128a – Schulung G 148 ff. – Verschuldensbeschränkung G 227 Anbieterwechsel – Softwarepflege I 258 ff. Änderbarkeit – Software-Bewertung Q 65 ff. – Softwarepflege I 407 – Vergabeunterlagen N 138 Änderungen – Ablehnung D 175 – Änderungsverbot A 77 – Anscheins- oder Duldungsvollmacht D 165 – Dokumentation C 285 ff.; D 158 – Fehlerrisiko D 159 – Festpreis D 169 – Geschäftsgrundlage D 174 – Grenze D 169 – Grundproblem D 156 ff. – Kalkulation D 168 – konkludente Vereinbarung D 165 – Kündigung D 175 f. – Muster, Vertragsklausel D 474 ff. – Präzisierung D 156 – Rechtsanspruch D 158 – Software-Bewertung Q 247 – stillschweigende Änderungen D 167 ff.

1502

– – – – – – – –

Systemumgebung D 156 Umfang D 159 vereinbartes Verfahren D 162 ff. Vergütung D 160 Verzug D 397 f. Zusatzaufwendungen D 159 Zusatzvergütung D 170 ff. Zustimmungspflicht des Softwareerstellers D 174 ff. Änderungskündigung – Kündigungsschutzgesetz E 195 Änderungsmanagement – Planungsphase C 255 – Prüfungspflichten des Pflichtenhefts C 253 ff. Änderungsverfahren – Rechtsprechung G 267 Änderungsverlangen – Checkliste G 292 – Fehler im Pflichtenheft G 285 – Formulierung G 283 – mögliche Phasen G 282 – praktische Handhabung G 280 ff. – verschiedene Stufen G 284 Anerkenntnis – Softwarepflege-, Softwareüberlassungsvertrag I 163 Anerkennung – ausländischer Urteile F 42 ff. – Urheberschaft/Rechtsinhaberschaft A 74 Anforderungsbeschreibung – Bedeutung für die Vertragsgestaltung G 155 ff. – Begriff G 130 – Checkliste zur Erstellung G 164 – funktional/nicht-funktional G 153 f., 180 ff. – Inhalt G 132 – Kostenaspekte G 162 – vereinbarte Beschaffenheit G 157 Anforderungsermittlung – Requirements Engineering G 163 Anforderungskatalog C 173 Angebote, Vergabe – Angemessenheit des Preises N 253 – Ausschlussgründe siehe dort – Eignungsprüfung N 252 – Öffnung durch die Vergabestelle N 243 – Vergleichbarkeit N 242 – Vorgaben für die Bieter N 242 – wirtschaftlichstes Angebot N 254 Angebotsbewertung – im offenen Verfahren, Vergaberecht N 86 Angebotsfrist – im offenen Verfahren, Vergaberecht N 87 Angebotsphase – Rechte und Pflichten G 1 ff. – wettbewerblicher Dialog N 114 f.

Stichwortverzeichnis Angemessenheit – Vergütung A 180 ff. Anhörung – Beweissicherung, Softwareschutz A 386 Anlagen – Wertigkeit der Anlagen zum Vertag C 350 Anlagen-Liefervertrag – Schiedsgerichtsbarkeit J 50 Anlagen-Regressrisiko O 76 Anmelderecht, subsidiäres – Zuwendungsrecht, EU M 99 Anmeldung – Offenlegung im Patentrecht A 208 – Zeitrahmen im Patentrecht A 204 Annahmeverzug D 300 Anonymisierung – Auftragsdatenverarbeitung C 404 – Datenschutz bei personenbezogenen Daten C 389 Anpassung – als Störung I 412 – Preis, Softwarepflegevertrag I 203 ff. – Service-Level-Agreements I 501 ff. Anpassung der Standardsoftware siehe auch Standardsoftware, Implementierung – Anpassungsbedarf G 47 f. – BGH-Rechtsprechung G 99 ff. – Erstellung eines Reports G 141 – Feststellung des Bedarfs G 49 – Gegenstand der Anpassung G 46 – gemischter Vertrag G 112 ff.; siehe auch dort – Konsequenzen der rechtlichen Vertragseinordnung G 106 ff. – Programmänderungen G 139 – Setzen von Parametern G 139 – technische Möglichkeiten G 41 ff. Anpassungsplanung – anhand ausgewählter Software C 183 ff. – Disposition bei Geschäftsleitung und Mitarbeitern C 229 – Dokumentation C 273 – Organisation des Kunden C 223 ff. – Schulungsplan C 221 – Umfang des Aufwands C 226 – Werkvertrag C 227 ff. Anscheins- oder Duldungsvollmacht – Änderungswünsche D 165 Anteilsverzicht – Miturheber A 65 f. Anton Piller Order A 381 Antrag, Nachprüfungsverfahren – Befugnis N 298 ff. – Begründetheit N 335 – Beschleunigungsgrundsatz N 336 – Bindungswirkung N 336 ff. – De facto-Vergabe N 300, 304 – drohender Schaden N 305a

– Entscheidung N 336 ff. – inländischer Empfangsbevollmächtigter N 297 – Interesse am Auftrag N 302 – keine Erfolgsaussichten bei Schadensersatz N 306 – konkreter Vorgang N 300 – mögliche Rechtsverletzung N 305 – Muster N 296 – Präklusion N 308 – Sachantrag N 296 – vorbeugender Rechtsschutz N 301 – Zulässigkeit des Antrags N 292 Antragsverfahren – Aufklärung Scheinselbständigkeit E 246 – Projektförderung M 49 Antwortzeiten – Mangel D 255 f., 262 – nicht-funktionale Anforderungen G 189 Anvertrauen – Geheimnisverrat A 314 Anwaltsgeheimnis – Auftragsdatenverarbeitung C 399 Anwender – Bearbeitungsrecht L 1 – Beibringung der Anforderungen G 170 ff. – Interessen bei Abnahme/Freigabe C 359 f. – Mitwirkung G 215 ff.; siehe auch Mitwirkung des Auftraggebers – Regelung der Mitwirkung G 221 – Vertragsgestaltung G 63 ff. Anwenderdokumentation Q 105 f. Anwenderhandbuch – Vertragseinordnung B 49 Anwenderinteresse – Softwarepflegevertrag I 10 ff. Anwenderpflichten – Softwarepflegevertrag I 521 Anwendung von Kaufrecht siehe auch Kaufrecht – Minderung D 369 – Muster, Vertragsklauseln D 503 ff. – Nacherfüllungsanspruch D 362 ff. – Rechtsmängel D 377 ff. – Rücktritt D 369 – Rügeobliegenheiten D 373 ff. – Schadensersatz D 370 – Verjährung D 371 Anwendungsprogramm – wettbewerbliche Eigenart A 275 Anwendungs-Schicht Q 70 Application-Service-Vertrag B 100 Apps – Standardsoftware B 49 Arbeitnehmerüberlassung, illegale E 223 ff. Arbeit auf Abruf – Arbeitsvertrag E 9

1503

Stichwortverzeichnis Arbeitgeber – Arbeitnehmerüberlassung, illegale E 223 ff. – Änderungskündigung E 195 – Annahmeverzug E 170 – Arbeitnehmerüberlassung, gewerbliche, Rechteübertragung E 228 ff. – Entgeltzahlungsverzug E 166 ff. – Fürsorgepflicht E 1 – Hauptleistungspflicht E 16 ff. – Leistungsklage auf Arbeit E 161 – Leistungsstörungen E 166 ff. – Lohnfortzahlungspflicht E 162 – Lohnzahlungsverpflichtung E 170 – Nachentrichtung von Sozialversicherungsbeiträgen E 246 – Nebenpflicht E 19 – Scheinselbständige E 245 ff. – Schutzrechtsübertragung E 211 ff. – Unterlizensierung E 264 – unternehmerische Entscheidung, dringendes betriebliches Erfordernis E 185 ff. – Urheber-Nutzungsrecht E 55 f. – Urheber-Nutzungsrechtsübertragung E 75 – Weiterübertragung E 264 Arbeitgeberdarlehen – Aufhebungsvertrag E 198 Arbeitgeberhaftung – gesamtschuldnerisch mit Arbeitnehmer E 165 Arbeitnehmer – Abmahnung E 191 – Änderungskündigung E 195 – Anrechnung von Ersatzeinkünften E 170 – Arbeitnehmerüberlassung, illegale E 223 ff. – Begriff E 25 – erfolgsunabhängige Leistung E 163 ff. – freier Mitarbeiter E 241 f. – Kündigung E 180 ff. – Leistungspflichten E 11 ff. – Nichtleistung E 159 – personenbedingte Kündigung E 192 – Scheinselbständige E 245 ff. – Schlechtleistung , Kündigung E 192 – Softwareentwickler E 1 – Tätigkeitsort E 29 – Treuepflicht E 1 – Unmöglichkeit der Leistung E 160 f. – Urheberpersönlichkeitsrecht E 20 – verhaltensbedingte Kündigung E 191 – Verlust des Lohnanspruchs E 161 – vertragswidriges Verhalten E 191 – Wahrnehmung seiner Aufgaben E 30 ff. – Zurückbehaltungsrecht an Arbeitsleistung E 168 Arbeitnehmerähnliche Person – freier Mitarbeiter E 243

1504

Arbeitnehmererfindergesetz – analog für Geschäftsführererfindungen E 103 ff. – Schiedsstelle E 81 Arbeitnehmererfindervergütung E 79 ff.; siehe auch Erfindervergütung Arbeitnehmererfindung – Auskunftsanspruch E 87 – Beendigung des Arbeitsverhältnisses E 210 – Deutschland E 79 – Erfindungswert E 85 – Geheimhaltung siehe Geheimhaltungsverpflichtung – Konkurrenzfragen E 83 – Verbesserungsvorschlag E 82 ff. – Vergütung E 83 – vertikaler Entwicklungsvertrag E 90 ff. Arbeitnehmererfindungsgesetz – Überblick E 80 ff. – Zuwendungsempfänger, Weitergabe an Dritte M 65 Arbeitnehmerhaftung – Beweiserleichterung E 165 – gesamtschuldnerisch mit Arbeitgeber E 165 – Unmöglichkeit der Arbeitsleistung E 161 – Vorgehen des Arbeitgebers E 165 – wegen Schlechtleistung E 164 Arbeitnehmerpflichten – Leistungsstörungen E 158 ff. Arbeitnehmerrechte – Pflichten E 1 ff. Arbeitnehmerschutzregelungen – Vertragsfreiheit E 3 Arbeitnehmerüberlassung – Abgrenzung Dienst- und Werkvertrag E 218 ff. – Abrechnungsmodalitäten E 240 – Arbeitnehmeraustausch E 236 – Arbeitskampf E 233 – Arbeitszeit E 219 – Auswahlfehler E 235 – Begriff E 214 ff. – echte/unechte E 215 f. – Entwicklung übertragenes Unternehmen E 26 – Erfindervergütung E 95 ff. – Erfolg, Vergütung E 220 – Fachqualifikation E 227 – gewerbliche E 216 – illegale Überlassung E 223 ff. – Klausel über Stundennachweis E 239 – Kleinbetriebe E 217 – Leiharbeitsverhältnis E 215 – Leistungspflichten E 226 f. – Leistungsstörungen E 231 ff. – Meldepflicht beim Arbeitnehmer E 232 – Nutzungs- und Verwertungsrechte E 229

Stichwortverzeichnis – Personalauswahl und -überlassung E 234 – Rechteübertragung E 228 ff. – rechtliche Einordnung E 216 – Regelung über Rechtseinräumung E 229 – technischer Verbesserungsvorschlag E 230 – Vergütungshöhe für Arbeitnehmererfindung E 97 ff. – Vergütungspflicht E 238 ff. – Vergütungspflicht für Arbeitnehmererfindung E 96 – verspätete Vergütung E 237 – vorrübergehende Entsendung E 218 Arbeitnehmerüberlassung, gewerbliche – AÜG E 221 ff. – Gewinnerzielungsabsicht E 221 – illegale Überlassung E 223 ff. – Schadensersatz E 223 – Vertrag E 222 Arbeitnehmerurheber – angemessene Vergütung E 118 – Rechtseinräumung E 52 ff. – Schöpferprinzip E 55 Arbeitsaufgabe – Definition E 12 Arbeitsentgelt – Arbeitsvertrag E 4 – Hauptleistungspflicht E 16 ff. Arbeitsergebnisse – Arbeitsvertrag A 122 – Auflistung A 7 – Auslegung von Eigentumsvorbehaltsklauseln A 145 f. – Datenbankwerk A 46 – Dienstvertrag A 121 – Eigentumsvorbehalt A 143 – Entbehrlichkeit einer rechtsgeschäftlichen Verfügung A 131 ff. – Entstehung der Software A 139 – Funktionsprüfung A 141 – Geschäfts-/Betriebsgeheimnis A 309 – Gesellschaftsvertrag A 123 – Nutzungs-/Verwertungsrechte E 14 – öffentlich-rechtliches Dienstverhältnis A 122 – Prüfungsstandards 850 Q 205 – Rechtseinräumung A 115 ff.; G 301; siehe auch Rechtseinräumung, Arbeitsergebnisse – Rechtseinräumung bei Abnahme A 141 – Rechtsverschaffungspflicht A 124 f. – Rechtsvorbehalt A 143 f. – Testnutzung A 141 – Übergabe/Ablieferung der Software A 140 – Übersicht zur Schutzfähigkeit A 51 – Urheberrecht E 20 ff. – Urheberrechtsschutz A 6, 42 – Verfügungsgeschäft A 126 ff. – Vergütung, Rechtseinräumung A 143 f.

– Vertragsabschluss A 137 f. – Vertragsgestaltung G 303 ff. – Werkvertrag, Werklieferungsvertrag A 118 ff. – Wettbewerbsschutz A 261 – Zeitpunkt der Rechtseinräumung A 115, 134 ff. Arbeitskampf – Arbeitnehmerüberlassung E 233 Arbeitskraft – Verwendung, Kündigung D 434 ff. Arbeitsleistung – Art und Umfang E 31 – nachträgliche Vertragsänderung E 31 – Ort und Zeit E 36 Arbeitsplatzwechsel – Recht am Arbeitsergebnis E 39 ff. Arbeitsspeicher – Vervielfältigung A 81 Arbeitsteilung – Miturheberschaft A 55 ff.; siehe auch dort Arbeitsunfähigkeitsbescheinigung – Mangel G 159 Arbeitsverhältnis – Änderungsverbot A 77 – Beendigung E 173 ff. – Fehlen eines Rechtsübertragungszeitpunkts A 149 – Fiktion, Arbeitnehmerüberlassung E 224 – Geheimhaltungsverpflichtung E 15 – gesetzliche Lizenz A 132 – Rückrufrecht A 78 – Urheberpersönlichkeitsrecht A 72 – Verwertungsrechte A 53 – Zugangsrecht A 79 Arbeitsvermittlung – Arbeitnehmerüberlassung, illegale E 225 Arbeitsvertrag – Abweichung von Urheberrechten E 51 – Arbeitnehmerüberlassung, gewerbliche E 226 – Arbeitsaufgabe E 12 – Arbeitsleistung E 1, 31 ff. – Ausspähen von Betriebs- und Geschäftsgeheimnissen E 121 ff. – Befristung siehe dort – Betriebszweck E 64 – Dauer E 7 – Dokumentation zum Computerprogramm E 5 – dynamische Verweisungen E 10 – Einwilligung zur Konkurrenztätigkeit E 144 – freier Mitarbeiter E 2 – Inlandsbeschäftigung E 4 – Konkurrenzverbot E 136 ff. – Leistungspflichten E 11 ff. – Leistungsstörungen E 158 ff.

1505

Stichwortverzeichnis – Mindestangaben E 4 – Probezeit E 8 – Recht am Arbeitsergebnis E 5 – Schriftform E 4 – Teilzeit E 9 – Tipps zum Inhalt E 63 – Vertragsfreiheit E 3 – Werkunternehmer E 2 – Wettbewerbsklausel E 150 – Wettbewerbsverbot E 137 ff. Arbeitszeit – freier Mitarbeiter E 242 Arbitration rules – ICC F 52 Architektur, Software – Dokumentation Q 101, 114 – Due Diligence Q 69 – modellgetriebene Entwicklung Q 73 – Schichten Q 70 – three-tier architecture Q 70 Archivierung – Auftragsdatenverarbeitung C 396 – Due Diligence Q 29 f. ARGE-Softwareprojektvertrag – Haftung E 369 Artefakte – Scrum C 133, 137 ff. – Sprint Backlog C 137 Arztabrechnungssoftware D 19, 252, 267 Arztgeheimnis – Auftragsdatenverarbeitung C 399 ASP-Vertrag – BGH B 112 f. Aufforderung – im offenen Verfahren, Vergaberecht N 86 Aufgabenbereiche – Musterformulierung für Zuweisung G 136 Aufhebungsfolgen – Vergabeverfahren N 278 ff. Aufhebungsvertrag – Anfechtung E 200 – Anspruch auf Arbeitslosengeld E 201 – Beendigung des Arbeitsverhältnisses E 197 ff. – einvernehmlich E 198 – Mindestinhalt E 198 – Rücktritt, Widerruf E 200 – steuerliche Folgen E 201 – Verlust einer Versorgungsanwartschaft E 201 Aufklärungs- und Beratungspflichten – Anpassung vorhandener Software D 15 – Beratung zur Systemumgebung D 16 f. – Ermittlungspflichten des Kunden D 10 – Fachkunde des Kunden D 6 – fehlende Unterlagen D 7 f., 11 – fehlerhafte Auskünfte D 14 – Hinweis auf Leistungsbeschreibung D 4 ff.

1506

– Inhalt der Pflichten D 7 – Nebenpflicht D 139 ff. – Pflichtenheft D 8 – rechtliche Vorgaben D 19 – Tauglichkeit der Standardsoftware D 18 – Umfang D 5 f. – Untersuchungen D 7 f. – vorvertragliche Beziehungen D 4 ff. – weitere Beratungspflichten D 18 Aufklärungspflichten – agile Methodik C 148 – Auftragnehmer C 77 – Geheimhaltung im Verhandlungsstadium G 12 – Planungsphase C 72 – Schadensersatz bei Verletzung G 4 – Verhandlungsstadium G 4 ff. Aufklärungspflichtverletzung – Schadensersatzanspruch I 72 f. Auflösung – Beendigung des Konsortiums E 370 ff. Auflösungsklausel L 151 f. Aufsichtsbehörde – Betretungsrechte C 427 – Rechtsschutz, Vergabeverfahren N 286 Auftrag – Verarbeitung personenbezogener Daten C 384 f. Auftraggeber – Ermittlungspflichten D 10 – grenzüberschreitende Verträge F 1 ff. – Insolvenz F 59 ff. – internen Projektmanager C 192 – Mitwirkung G 204 ff.; siehe auch Mitwirkung des Auftraggebers – Mitwirkungspflichten C 49, 192 – Prüfungspflichten C 232 ff. – Querschnittsaufgabe C 192 Auftraggeberzusicherung – internationaler Bezug F 8 Auftragnehmer – Erkundigungspflicht C 51; D 9 – grenzüberschreitende Verträge F 1 ff. – Organisationsvorschlag D 9 – personenbezogene Daten des Auftraggebers C 382 f. – Prüfungspflichten C 240 ff. – Sachkunde und Hinweispflichten D 4 ff. – V-Modell C 318 – vorvertragliche Pflichten D 4 ff. – vorvertragliche Übergabe des Pflichtenhefts C 241 – Zustimmungspflicht bei Änderungen D 174 ff. Auftragsabwicklung – Implementierung von Standardsoftware G 35 Auftragsdatenverarbeitung – Anforderungen C 405 ff. – Anlage zu § 9 BDSG C 417 ff.

Stichwortverzeichnis – Auftragnehmer im Nicht-EU-/-EWRAusland C 439 ff. – Beteiligungsrechte des Betriebsrates C 409 – Checkliste C 409 – Datenschutz F 73 – Echtdatentest C 425 f. – Eckpunkte des Vertrags C 409 – Einwilligung des Betroffenen C 437 f. – Einzelfragen zum Vertrag C 427 ff. – EU-Standardvertragsklausel C 439 – Funktionsübertragung C 402 f. – Geheimhaltungsvereinbarung C 443 – gesetzliche Erlaubnis C 380 – Projekt-Vertrag C 378 ff. – Prüfungsaufgaben C 406 ff. – Prüfungspflichten C 413 ff. – Safe Harbor-Konzept C 439 ff. – typische Situationen C 396 – Verschlüsselung/Anonymisierung C 404 – Vertrag C 405 – Zutritts-/Zugangskontrolle C 418 ff. Auftragswert – Schätzung, Vergabeverfahren N 59 ff. Aufwandsschätzung – Projektmanagement H 43 ff. Aufwandsvereinbarungen Formulierungsbeispiele – Muster, Vertragsklausel D 459 ff. – Zug um Zug Leistung D 461 Aufwandsvergütung – Dienst-/Werkvertragsrecht G 306 – Festlegungen im Vertrag G 313 ff. – Musterformulierung im Vertrag G 314 – Werk- oder Dienstvertrag D 57 Aufwendungen – Ersatz G 398, 402 – Ersatz bei Pflichtverletzung G 354 – Musterformulierung im Vertrag G 393 – ordentliche Kündigung G 422 ff. – Pauschalierung G 422 ff. Aufwendungsersatz – Absichtserklärung D 37 – Erforderlichkeit der Aufwendungen D 31 f. – gescheiterte Vertragsverhandlungen D 21 ff. – Nichterfüllung D 385 – unhaltbare Zusagen G 8 – Versicherungsschutz O 29 Ausbaukosten – Anwendbarkeit auf Software O 136 – Schadenereignis O 134 – Versicherungsschutz, ProdHM O 134 ff. – Voraussetzungen O 135 Ausdruck – Betriebsspionage A 320 – fehlerhaft D 267 Ausdrucksform – Urheberrechtsschutz A 32

Ausdruckzeiten D 262 Auseinandersetzung – Beendigung des Konsortiums E 370 ff. Ausfallsicherheit – IT-Systemen I 25 ff. Ausführungsart G 289 Ausführungsstandard G 175 ff. – fehlendes Pflichtenheft C 261 ff. – mittlerer C 71 – mittlerer, agile Methodik C 142 ff. – mittlerer, Projekt-Vertrag C 42 Ausführungsumgebung Q 68 Ausfuhrliste – Außenwirtschaftsverordnung F 81 Ausgleichsanspruch – Versicherungsschutz O 28 Ausgleichslizenz – Vergütungsbasis für Arbeitnehmererfindung E 98 Aushandeln – berechtigtes Interesse J 61 f. – Einflussnahme auf Vertragsgestaltung/ Haftungsbegrenzung J 39 ff. – enge gesetzliche Vorgaben J 46 ff. – Individualvereinbarung G 417 – Nachteile J 81 f. – reale Möglichkeit J 80 – Reichweite J 67 ff. – Tarifwahl J 63 f. Auslagen – Durchsetzung des Softwareschutzes A 388 Auslandsschäden – abweichende Deckungskonzepte O 254 – Ansprüche aus öffentlichem Recht O 68 – Begriff O 64 – indirekte/direkte Exporte O 66 – USA/Kanada-Risiken O 70 – versichertes Risiko O 65 ff. – Versicherungsschutz, ProdHM O 164 – Wiedereinschluss O 65 ff. – Zusammenfassung O 71 Auslandsschäden, BBR IT-Dienstleister – Ergänzungsbedarf O 249 – Versicherungsausschluss O 198 – zur Verfügung Stellung von Daten zum Herunterladen O 199 Auslegung – Absichtserklärung D 35 – Pflegegegenstand, Versionsstand I 269 ff. – Vertragseinheit bei Softwarepflege-, Softwareüberlassungsvertrag I 77 ff. Ausschließlichkeitsrecht – Patentrecht A 208, 210 Ausschluss vom Versicherungsschutz – Auslandsschäden O 64 ff. – BHV-IT O 86 – Datenschäden O 81 ff. – Haftungserweiterung O 52 – Herstellung von Sachen, Ziff. 7.8 AHB O 62 f.

1507

Stichwortverzeichnis – Kenntnisklausel O 48 ff. – Lieferung von Sachen, Ziff. 7.8 AHB O 62 f. – Nichterfassen von Daten O 83 – Nullstellung von IT-Risiken O 80 ff. – Nutzungsausfall O 63 – Privathaftpflichtversicherung O 86 – Schäden durch Umwelteinwirkung O 72 ff. – Störung des Zugangs zum Datenaustausch O 84 – Strahlenklausel O 79 – Tätigkeitsschäden O 53 ff. – Übermittlung vertraulicher Daten O 85 – vorsätzliche Handlungen O 45 ff. – Wertverlust O 63 Ausschluss vom Versicherungsschutz, BBR IT-Dienstleister – Ansprüche wegen Schäden, Ziff. 7.8 AHB O 237 – Auslandsschäden O 202 – Computerviren O 220 – Erfüllungsanspruch, -surrogat O 234 – Erprobungsklausel O 239 – Garantien O 235 – Gewährleistung wegen Rechtsmängel O 236 – Konzernklausel O 240 – Lizenzvergabe O 243 – Luftfahrtprodukte O 222 f. – Persönlichkeitsrechtsverletzung O 213 – Pflichtwidrigkeitsklausel O 238 – Rückrufkosten O 244 – Sublimit und Selbstbeteiligung O 210 – Unterlassen von Wartung/Pflege O 241 – unzureichende Datensicherung O 215 ff. – Vertragsverletzungen O 242 Ausschluss vom Versicherungsschutz, ProdHM – Ansprüche aus Garantien O 167 – Ansprüche aus Haftungserweiterungen O 167 – Ansprüche wegen Schäden, Ziff. 7.8 AHB O 169 – Erprobungsklausel O 171 ff. – Gewährleistung wegen Rechtsmängel O 168 – Konzernklausel O 176 – Luftprodukthaftpflicht O 174 f. – Pflichtwidrigkeitsklausel O 170 Ausschlussfristen – Eskalationsprozess I 519 Ausschlussgründe – Eignung, Vergabe N 222 ff. – Eignung, Vergabe, nationale Ebene N 225 – Ermessen N 251 – fakultative N 251 – zwingende N 249 f.

1508

Ausschreibung – V-Modell C 316 – beschränkte ~ N 89 ff. Ausschreibungspflicht – öffentliche Auftraggeber N 31 ff. Außenwirtschaftsgesetz – und -verordnung F 75 Außenwirtschaftsverordnung – Ausfuhrliste F 81 Außerordentliche Kündigung – Standardsoftware G 426 ff. – Verhältnis zu § 649 BGB G 429 – Verschulden G 426 – wichtiger Grund G 428 Ausstiegsklausel G 424 Austauschkosten – aufgrund von Nachbesserung O 143 – Ausgrenzung zum Rückruf O 149 – Deckungsausschluss O 144 ff. – Einzelteile von Erzeugnissen O 141 – Maschinenklausel O 160 f. – Weiterverarbeitung und -bearbeitung, ProdHM O 139 f. Auswahlberatung – Pflichtverletzung C 175 Auswahlfehler – Arbeitnehmerüberlassung E 235 Auswahlphase – wettbewerblicher Dialog N 109 f. Automatisierte Dateien – Datenschutz bei Projekt-Vertrag C 379 Background M 98, 118 Backup-System – Auftragsdatenverarbeitung C 396 BAG – Geheimhaltungsverpflichtung, nachvertragliche E 127 – Haftungserleichterung zugunsten Arbeitnehmer E 165 Banken – Prüfungspflichten C 237 Barwert – Software-Bewertung Q 10 f., 196 ff. Basisversicherung – Umwelthaftpflicht O 78 Basiszinssatz – Software-Bewertung Q 273 f. Bauprojekte – wettbewerblicher Dialog N 107 Bauwerkschäden O 276 Beamter – freier Mitarbeiter E 263 Bearbeitung, freie A 85 Bearbeitungsrechte A 83; G 296; L 1 Bedarfsoptionen – Eventualoptionen, Vergabeverfahren N 141 Bedienbarkeit – nicht-funktionale Anforderungen G 189

Stichwortverzeichnis Bedienungsanleitung – Anwenderdokumentation G 231 ff. – Einzelheiten aus der Rechtsprechung G 233 – Fälligkeit G 238 f. – Gewährleistung C 96 – Mangelhaftigkeit G 240 – Online-Hilfen G 233 – Übersicht zur Schutzfähigkeit A 51 – Urheberrechtsschutz A 43 Bedienungscomfort D 266 Bedrohungsanalyse – IT-Sicherheit Q 40 Beeinträchtigung – Nachahmung A 263 – Urheberpersönlichkeitsrecht A 76 ff. Beendigung siehe auch Aufhebungsvertrag – Hinterlegung L 166 f. – Nutzungs- und Verwertungsrechte, Nebenrechte E 207 ff. – Arbeitsverhältnis siehe Befristung; Kündigung Beendigungskündigung – ultima ratio E 187 Befristung – Arbeitsverhältnis E 174 ff. – Arbeitsvertrag E 4 – sachlicher Grund E 176 – Softwareentwicklungsprojekte E 177 – unwirksam E 177 – zweckbefristeter Arbeitsvertrag E 174 ff. Begleitmaterial – Urheberrechtsschutz A 27 Behinderung – Unlauterkeit A 284 Behinderungswettbewerb A 269 Beibringungspflicht – Erkundigungspflicht C 54 Beihilferecht, EU siehe auch Zuwendungsrecht, EU – Anwendungsbereich M 7 – EuGH M 9 – Forschungsbereiche M 10 – Kontrolle M 9 – Privilegierungen M 11 – Prüfungsmaßstab M 8 Beitragsansatz – Patentschutz für Software A 229 Bekanntmachung – eu-weit, wettbewerblicher Dialog N 109 Belgien – Durchsetzung des Softwareschutzes A 379 Benutzbarkeit – Softwarepflege I 407 Benutzerdokumentation D 111 Benutzerhandbuch G 243; siehe auch Handbuch Benutzerinteraktionen – Musterformulierung G 185

Benutzung, freie A 85 Beobachtung A 102 ff. Berater, externer – Leistungsbeschreibung, Vergabeverfahren N 151 – Projektantenproblematik N 128 ff. Beratung – Auswahl der Standardsoftware C 172 ff. – Nebenpflicht C 158 ff. – Vergütungspflicht C 163 ff. – zusätzliche Beauftragung C 163 ff. – explizite Vereinbarung C 165 Beratungsleistungen – Softwarepflegevertrag I 451 Beratungspflichten – Fehler im Pflichtenheft D 142 – Mängel, Versicherungsschutz O 106 – Nebenpflicht D 139 ff. – Pflicht des Softwareerstellers D 414 – Rückgängigmachung des Vertrages D 417 – Softwareanbieter zu Mitwirkungspflichten G 218 – Umfang D 414 Beratungsvertrag – Abgrenzung zur Realisierung C 158 – Anpassungsplanung C 183 ff. – Ausgestaltung C 166 ff. – Auswahl geeigneter Hardware C 190 – BVB-Planung C 158 ff. – falsche Auswahlempfehlung C 175 – Implementierungsplanung C 183 ff. – Ist-/Bedarfsanalyse C 188 – Kollision diverser Methoden C 180 – Kompatibilität C 191 – Rechtsprechung für Zusatzaufträge C 258 – Unterstützungsvertrag C 177 ff. – Voraussetzungen C 257 – Zusatzbeauftragung C 259 Berechtigungsanfrage A 404 Berechtigungskonzept – IT-Sicherheit Q 39 Bereicherung – Versicherungsschutz O 30 Bereicherungsanspruch – Wettbewerbsverstoß A 295 Berichtswesen – Projektcontrolling H 107 Berliner Verträge – Konsortium E 364 Berner Übereinkunft B 118 Beschaffenheit – keine Vereinbarung G 381 – Pflichtenheft G 157 – Sollbeschaffenheit D 247 ff. – vertragliche Vereinbarung G 368 – Vertragsbestandteil B 127 Beschaffenheitsgarantie – Arglist K 2

1509

Stichwortverzeichnis – ausdrückliche/stillschweigende Garantieübernahme K 12 – Auslegungshilfe K 8 f. – Beschaffenheitsvereinbarung K 4 ff. – Haftungsfreizeichnung K 13 ff. – individualvertragliche Schranken K 2 ff. – Reichweite der Garantieübernahme K 10 f. – Umfang G 165 – Vorliegen K 2 f. Beschaffenheitsvereinbarung – Höherqualifizierung K 19 ff. – Verfügbarkeitsgarantie K 24 Beschaffungsbedarf – Feststellung N 120 ff. Beschaffungsmanagement H 31 Beschaffungsvertrag – Hinterlegung L 99 – Lieferant/Leasinggeber R 72 f. – Nießbrauch L 170 ff. – wichtige Bestandteile L 168 Beschleunigungsgrundsatz – Gesetz gegen Wettbewerbsbeschränkungen N 336 Beschluss – Muster zur Durchsetzung des Softwareschutzes A 388 Beschränkte Ausschreibung – Teilnahmefrist N 91 – Teilnahmewettbewerb N 90 – Verbot der Verhandlung mit den Bietern N 92 – Verlängerungsmöglichkeit N 91 – Voraussetzungen N 89 ff. Beschwerde – Patentversagung A 207 Beschwerdeentscheidung – Rechtmittel N 348 – Vergabesenat N 348 – Wirkung N 347 Beseitigungsanspruch – Verstoß gegen Geheimnisschutz A 329 – Wettbewerbsverstoß A 292 ff. Besichtigungsanspruch – Abgrenzung Herausgabepflicht L 22 – Durchsetzung des Softwareschutzes A 382 f. Besitzstand – Software A 249 Besitzverhältnis – Software-Bewertung Q 238 ff. Bestätigungsklauseln – Individualvereinbarung J 79 Besteuerung – Softwareüberlassung P 1 ff. Beteiligte – Projektorganisation H 88 Beteiligungsanspruch – Urheber E 112 ff.

1510

Betriebsgeheimnisse siehe auch Geschäftsgeheimnis – Allklausel E 123 – Arbeitsergebnisse A 309 – Arbeitsvertrag E 121 – ausspionieren E 121 – Begriff A 300 ff. – Quellcode-Herausgabe G 248 – Rückabwicklung bei Rücktritt D 307 – Verhandlungsstadium G 10 ff. – Verletzung D 447 Betriebsangehörige – ehemalige, Versicherungsschutz O 10 – Versicherungsschutz O 10 Betriebsausgaben – selbst erstellte immaterielle Wirtschaftsgüter P 7 Betriebsbeschreibung – versichertes Risiko O 90 Betriebsdokumentation G 245 Betriebshaftpflichtversicherung für Nutzer von Internet-Technologie (BHV-IT) O 86 Betriebshandbuch – Due Diligence Q 107 ff. Betriebsrat – Auftragsdatenverarbeitung C 409 Betriebsrisiko – Umwelt, Versicherungsschutz O 75 – Versicherungsschutz O 91, 226 Betriebsspionage A 296, 317 ff. Betriebsstättenrisiko – Versicherungsschutz O 91, 226 Betriebssystem – Beeinträchtigung O 91 Betriebsübergang – Verarbeitung personenbezogener Daten C 386 Betriebsunterbrechung siehe Produktionsausfall Betriebsvereinbarung – Grenzen der Vertragsfreiheit E 3 Betriebszweck – Arbeitsvertrag E 64 – Ermittlung im Einzelfall E 69 ff. – nachträgliche Änderung E 71 Beweiserleichterung – typische Klauseln J 76 Beweiskraft – Vergabevermerk N 262 Beweislast siehe auch Darlegungs-/Beweislast – Abnahme G 324 – Abnehmerverwarnung A 401 – Gleichbehandlung im Vergabeverfahren N 21 – Installationsleistungen I 443 – Rechtseinräumung G 302 – Umkehr bei Abnahme C 333

Stichwortverzeichnis – Vergabeverfahren ohne Teilnahmewettbewerb N 81 – Mängelbeseitigungsentgelt I 180 ff. – Nichtigkeit/Softwarepflege-, Softwareüberlassungsvertrag I 105 – Verletzung der Systemumgebung-Einsatzobliegenheit I 380 f. – Vertragsgemäßheit B 77 – Werkunternehmer E 280 Beweislastumkehr – Übernahmebestätigung R 46 – Verletzung der Systemumgebung-Einsatzobliegenheit I 382 ff. Beweissicherung – Anhörung A 386 – Antrag A 392 – deutsches Recht ab 2002 A 384 ff. – deutsches Recht bis 2002 A 382 f. – Düsseldorfer Praxis A 388 f. – Durchsetzungsrichtlinie A 386 f. – England A 380 – Frankreich A 379 – Herausgabe bei Hinterlegung L 122 – Hinterlegung L 158 ff. – Kaution A 386 – Kosten A 395 – USA A 378 – Verletzungswahrscheinlichkeit A 390 – Verschwiegenheitspflicht A 393 – Vorlegungspflicht, § 142 ZPO A 384 – Zurücksetzen auf alte Version L 11 Bewertung – Software Q 1 ff.; siehe auch SoftwareBewertung – Software, steuerrechtlich P 4 Bewertungsdurchführung – Absatz-/Umsatzgröße Q 233 ff. – Abschätzung der Herstellkosten Q 216 ff. – Ausmaß der Unsicherheiten Q 283 f. – Basiszinssatz Q 273 f. – Besitz-/Eigentumsverhältnisse Q 238 ff. – Betrachtung verschiedener Szenarien Q 268 ff. – Beurteilung der Produkteigenschaften Q 210 ff. – Dokumentation Q 211 – eigene Softwarekomponenten Q 242 ff. – Entwicklungsaufwand Q 219 ff. – Ergebnisbandbreite Q 283 f. – Erlöse Q 258 ff. – Ermittlung des Quellcodeumfangs Q 216 ff. – ertragswertorientierte Verkehrswertermittlung Q 248 ff. – Escrowing Q 246 – geplante/erforderliche Maßnahmen Q 247 – Kapitalisierungszinssatz Q 271 ff. – kaufmännische Aspekte Q 232 ff. – Konkurrenzsituation Q 235 ff.

– – – – –

Kostenarten Q 258 ff. Lebensdauer der Software Q 253 ff. Patente Q 245 Personalkosten Q 228 ff. Plausibilisierung anhand tatsächlicher Aufwandswerte Q 231 – Quellcodes Q 212 f. – Restwert Q 280 ff. – Risikozuschlag Q 276 ff. – Softwareentwicklungsprozess Q 214 ff. – unfertige/defizitäre Projekte Q 222 ff. – vergleichende Betrachtung unterschiedlicher Wertansätze Q 208 ff. – Vermarktbarkeit Q 232 ff. – Wachstumsabschlag Q 275 – Wartbarkeit Q 211 – Wartungsgebühren Q 265 ff. – Zielgruppe Q 211 Bewertungsmatrix – Beispiel N 163 – Eignung, Vergabe N 215 – Unterkriterien N 165 f. – Wertungskriterien, Vergaberecht N 161 Bewertungsmethoden – Ansätze in der Informatik Q 159 ff. – Barwert Q 196 ff. – betriebswirtschaftliche Ansätze Q 195 ff. – Bewertung immaterieller Vermögenswerte Q 202 – COCOMO II Q 166 ff. – COSMIC Full Function-Point (FFP) Q 192 f. – Durchführung von Unternehmensbewertungen Q 201 – Elementarprozesse Q 162 – Entwicklungsaufwand Q 159 – Function Point Analysis Q 161 ff. – Herstellkosten Q 159 – IDW PS 850, 880 Q 203 ff. – IDW Standards, S 1und S 5 Q 199 ff. – Kapitalisierung Q 196 ff. – Produktivitätsgrößen Q 160 – produktorientierte Schätzung Q 194 – Richtlinien Q 161 – Schätzmodelle Q 172 f. – UfAB N 164 – Vorgehen des Wirtschaftsprüfers Q 203 ff. Bewertungsziele – Software Q 2 ff. BFH – Informatiker als Freiberufler N 71 – Spezialleasing R 29 – Vermögensgegenstände, immaterielle P 10 f. BGB-Gesellschaft – FuE-Verträge E 372 – Konsortium, Auflösung E 370 ff. BGH – abgestuftes Getriebe E 362

1511

Stichwortverzeichnis – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

ASP-Vertrag B 112 f. Auftragnehmer als Verwender J 19 Aushandeln J 33 ff. Aushandeln von Individualvereinbarungen G 417 Auskunftsanspruch, Arbeitnehmererfindung E 87 Beschaffenheitsgarantie K 12 Bestellerparagraph E 117 Buchhaltungsprogramm E 348 c2c-Verkehr J 16 chronologisch zur Sachqualität B 55 Computerprogramm B 42 Druckbalkenentscheidung A 383 Einheit von Rechtsverhältnissen Übertragung auf neues Schuldrecht I 118 f. Einheit von Rechtsverhältnissen vor Schuldrechtsmodernisierung I 115 ff. Erörterung einer Klausel J 40 Faxkarte A 385 Finanzierungsleasing R 4, 12 funktionaler Mängelbegriff K 5 geltungserhaltende Reduktion K 66 Haftungsbeschränkung, Kardinalpflichten G 412 Handbuch, Sachgesamtheit I 427 ff. Honda-Entscheidung K 44 Individualvereinbarung, Mängelhaftungsentgelt I 156 Inhaltskontrolle, Preisanpassungsinteressen I 255 Inkassoprogramm A 6 Insolvenzfestigkeit L 149 ff. Internetprovidervertrag B 100 Internet-System-Vertrag B 100 Internet-System-Vertrag 1 I 472 Internet-System-Vertrag 2 I 325 ff. Klausel oder Individualabrede J 2 ff., 12 ff. Kollision von Vertragsbedingungen J 29 f. Laufzeitbegrenzung für Pflegeleistungen I 311 ff. Leasing R 25 Lieferverzug K 50 Lizenzvertrag B 40 Lücken für § 651 BGB B 106 ff. Mangel I 400 Oracle B 3 Patentschutz für Software A 225, 232 ff., 244 ff. Portierung B 44 Preisanpassung I 211 Preisanpassung, Inhaltskontrolle I 229 f. Programmierleistungen B 46 Quellcodeherausgabe E 303 Rechtsfolgen bei Mängeln B 65 ff. Sachqualität von Software B 43 Schadensersatz, Aufhebung von Vergabeverfahren N 279 Schiedsgerichtsbarkeit J 55

1512

– Software als Sache G 82 – Softwareerstellung/-anpassung B 104, 63 ff., 92 ff. – Softwarepflege, Dokumentation I 427 ff. – Softwarepflege-, Softwareüberlassungsvertrag I 81 ff. – Standardsoftware B 45 f. – Standardsoftware, Kaufrecht G 87 ff. – Transparenzgebot K 42 – Unternehmensverkehr, Laufzeitbegrenzung für Pflegeleistungen I 316 ff. – Usedsoft B 3 – Vergütung ist Sache der Vertragsparteien I 228 – verschuldensunabhängige Haftung I 169 f. – Verweigerung von Leasingraten R 52 – Wahlrecht des Insolvenzverwalters F 61 – Webdesignvertrag B 101 – Werkvertragsrecht B 109 Bibliothekenprogramm – Rechte Dritter D 483 – Rechteübertragung D 44 – Softwareerstellung D 43 ff., 73 – Umfang D 45 Bieter – Leistungsbeschreibung im Vergabeverfahren N 140 ff. – zusätzliche Auskünfte zu Verdingungsunterlagen N 241 Bieterausschluss – Beispiel N 340 Bieterbetrachtung – Vergabeverfahren N 23 Bieterrechte – Aufsichtsbehörde N 286 – Entwicklung N 282 ff. – Geltendmachung N 285 ff. – Nachprüfungsantrag N 293 ff. – Nachprüfungsverfahren siehe auch dort – Primärrechtsschutz N 287 ff. – Rechtsschutz oberhalb der Schwellenwerte N 287 ff. – Rechtsschutz unterhalb der Schwellenwerte N 353 ff. – rechtzeitige Rüge N 308 ff. – Sekundärrechtsschutz N 349 ff. – Vergabekammern N 286 – Vergabeprüfstelle N 286 – Zuschlagssperre N 290 Bilanzierung – Software P 4, 7 – Software in Clouds P 12 – Verbot, immaterielles Wirtschaftsgut P7 Bilanzskandale I 19 ff. Bilaterale Abkommen – Vollstreckung/Anerkennung ausländischer Urteile F 45 Bildschirmmaske – Mangel G 373

Stichwortverzeichnis – Urheberechtsschutz A 12 Bindungswirkung – Entscheidung im Nachprüfungsverfahren N 336 ff. BITKOM – Sicherheit I 26 Black Swan – Scheiterungsgründe von Projekt-Verträgen C 8 ff. BMBF – Zuwendungsbestimmungen M 46 ff. BMVg – Zuwendungsbestimmungen M 66 f. Bonus – Service-Level-Agreements I 496 BoyD – personenbezogene Daten C 435 Branchensoftware G 39 Branchenüblichkeit – versichertes Risiko O 6 BSD-artige Lizenzbedingungen A 355 Buchführungssystem – IDW Prüfungsstandards 850 Q 206 – Software-Bewertung Q 26 ff. Buchhaltungssoftware – Werkvertrag D 57 – Beratungspflichten D 19 Buchvergleich – Vertragseinordnung B 114 Budget – Projektplanung G 199 Bürokommunikation – Auftragsdatenverarbeitung C 396 Bug-Tracking Q 156 Bundesagentur für Arbeit – Scheitern von IT-Projekten G 124 Bundesamt für Sicherheit in der Informationstechnik – Grundschutz-Handbuch Q 43 Bundesdatenschutzgesetz – Due Diligence Q 31 – Geheimhaltungspflicht E 135 – personenbezogene Daten bei Projekt-Verträgen C 378 ff. Bundesministerien – Projektförderung M 20 ff. Bundeszentralregister – Ausschlussgründe, Vergabe N 223 Bundle-Lease-Vertrag R 16 Business Bluesprint – Anforderungen G 153 Business Case – Zweck H 16 Buy-Out-Vertrag – umfassende Rechtseinräumung A 156 – Vergütung A 184 BVB/EVB-IT – AGB N 172 ff. – AGB der öffentlichen Hand N 172 BVB-Erstellung – Änderung der Leistung D 163

– Beginn der Realisierungsphase C 182 – Fehlermitteilung C 243 – Prüfungspflichten des Auftragnehmers C 213 – Urheberrechtsschutz A 6 BVB-Pflege – ergänzende Vertragsauslegung, Softwarepflege I 59 – Individualsoftware N 186 – öffentliche Auftraggeber I 60 – Preisanpassung I 204 – Programmkorrekturen I 39 – Programmkorrekturen, einschließlich Dokumentation I 425 – Softwarepflege I 36 BVB-Planung – Beratungsvertrag C 158 ff. – Gewährleistung C 27 – Grob-/Feinkonzept C 86 f. – Nutzungsrechte C 347 – Planungsleistungen und Dokumentation C 278 ff. – Teilabnahme C 205 – Urheberrechtsschutz A 6 – Verfahrensidee C 298 BWB – Zuwendungsbestimmungen M 66 f. CAD/CAP-Systeme – Standardsoftware G 39 Cap clause – Haftungsbegrenzung K 60 ff. – Haftungsbegrenzungsklauseln J 50 – Schadensersatzanspruch K 15 Capability Maturity Model Q 185 Carbotermo – Inhouse-Geschäft N 39 Catch-all-Klausel – Dual-use-Güter F 80 CEN – Mangelbegriff G 377 Change Managements C 207 Change of Control – Sonderkündigungsrecht G 431 f. Change Request – Änderungssituationen G 260 – Anpassung der Terminplanung G 270 – Auswirkungen auf Zusatzwünsche G 271 ff. – Bewertungsgrundlage G 288 – Checkliste G 292 – erhebliche Änderungen G 268 – fehlendes Pflichtenheft G 278 – Festpreise G 260 – Formulierung der Änderungsanforderung G 283 – Fristen G 283 – Kategorisierung G 265 – Muster, Vertragsklausel D 474 ff. – Nachweis des Mehraufwands G 277 ff.

1513

Stichwortverzeichnis – praktische Handhabung G 280 ff. – Prüfungspflichten des Pflichtenhefts C 253 ff. – Rechtsprechung bei fehlendem Änderungsverfahren G 267 – Terminplanung G 268 ff. – ungeeignete Ausführungsart G 289 ff. – Vergütung G 274 ff. – Vertragsgestaltung G 292 – Zumutbarkeit G 280 Checkliste – Änderungswünsche des Auftraggebers G 292 – Auftragsdatenverarbeitung C 409 – Bewertung des Quellcodes Q 213 – Bewertung von Produkteigenschaften Q 211 – Erstellung des Pflichtenheftes G 164 Claim Management – Projektmanagement H 84 Clean-Room-Verfahren A 105 Cloud – Softwarebilanzierung P 12 Cloud Computing – BSI-Lagebericht I 27 Cloud-Computing – Auslandsbezug bei Auftragsdatenverarbeitung C 441 – Verarbeitung personenbezogener Daten C 385, 394 CMMI – Reifegrade Q 135 ff. COCOMO-Verfahren – Entwicklungsaufwand Q 167 – Entwicklungsbedingungen Q 180 ff. – Entwicklungsdauer Q 177 – Entwicklungsflexibilität Q 182 – Genauigkeit Q 179 – Kostentreiberfaktoren Q 171, 187 ff. – Neuartigkeit Q 181 – Post Architecture-Modell Q 173 ff. – Projektphasen Q 224 – Prozessreife Q 185 – Quellcode Q 217 – Quellcode-Umfang Q 169 – Risikovorsorge Q 183 – Schätzmodelle Q 171 f. – Software-Bewertung Q 166 ff. – Teamzusammenarbeit Q 184 Codierungsstandards Q 78 Computerprogramm – Arbeitsplatzwechsel E 39 ff. – Bearbeitungsrecht E 45 – Beendigung des Arbeitsverhältnisses E 207 ff. – Begriff A 9 – Betriebsgeheimnis A 303 – Customizing A 22 – Datenbank, Daten A 20 – geistige Schöpfung A 36 – immaterielles Gut B 36

1514

– Individualität A 39 – Maschinen-, Objekt- und Quellcode A 10 – Multimediawerk A 19 – objektorientierte A 21 – Patentfähigkeit A 225 ff. – Recht am Arbeitsergebnis E 23 ff. – Rechtsübergang E 42 ff. – Schaffung durch Arbeitnehmer E 25 ff. – Schaffung nach Anweisungen des Arbeitgebers E 37 f. – Schnittstelle A 13 – unbeschränktes Nutzungsrecht seitens des Arbeitgebers E 46 – urheberrechtlich geschützte Arbeitsergebnisse E 211 – Websites A 17 – Zeitpunkt des Rechtsübergangs E 50 Computerrechtsrichtlinie F 2 Computerviren – abweichende Deckungskonzepte O 265 – Befall D 264 – Gefahrverhütung, Obliegenheit O 220 – Sachschaden O 20 – Stand der Technik O 220 – Versicherungsschutz O 81, 220 Contractor – Zuwendungsrecht, EU M 90 Contra-Indikatoren, agile Methodik C 118 Controlling siehe auch Projektcontrolling – IT-Projekt H 37 – Projektmanagement H 38 – weitere Services C 194 Coordinator – Zuwendungsrecht, EU M 90 Copyleft Effekt F 6 – exportrechtlicher Genehmigungsvorbehalt F 90 f. Copyleft-Klausel – Software-Bewertung Q 240 Copyleft-Lizenz – Anpassung von Standardsoftware G 44 – Firmware A 358 ff. – LG Berlin A 358 ff. – mit Copyleft-Effekt A 356 ff. – ohne Copyleft-Effekt A 354 ff. – Open-Source Software A 350 ff. – Transparenz A 359 – Verlinkung A 367 – viraler Effekt A 356 ff. Copyright – Miturheberschaft A 59 Cordis Website – Forschungsförderung M 94 Corporate Governance – Controlling I 24 – deutscher Kodex I 22 ff. – Risikomanagement und -controlling I 24 – US-Bilanzskandal I 19 ff. COSMIC Full Function-Point Q 192 f.

Stichwortverzeichnis Customizing – Anpassung von Standardsoftware D 49 – Standardsoftware G 139 ff. – Urheberrechtsschutz A 22 Cyber-Angriffe – BSI-Lagebericht I 27 Darlegungs- und Beweislast siehe auch Beweislast – AGB-Klausel J 11 – AGB-Klausel/Individualvereinbarung J 73 ff. – Kündigung D 435 ff. – Pflichtenheft C 47 – Pflichtverletzung D 312 – Tarifwahl J 66 – Unkenntnis bei Nichterfüllung D 384 – Urheberrechtsschutz A 41 Dateien – Überlaufen D 261 Dateiformat – Urheberrechtsschutz A 11 Daten – Beibringung von Testdaten C 220 – Bereitstellung C 219 – Nichterfassen, Versicherungsschutz O 83 – Urheberrechtsschutz A 20 Datenabruf – Versicherungsschutz O 199 Datenaustausch – Störung des Zugangs, Versicherungsschutz O 84 Datenbank – Abstraktionslayer Q 95 – Begriff A 49 – Beseitigung von Schutzmechanismen A 288 – Due Diligence Q 84 – Leistungsschutzrecht A 46 ff. – Präqualifikation N 228 – Schutzfähigkeit A 259 – Speicherungsmodelle Q 92 – Übersicht zur Schutzfähigkeit A 51 – unerlaubte Verwertung A 201 – Urheber-/Wettbewerbsschutz A 259 f. – Urheberrechtsschutz A 20, 46 ff. – Urheberschaft/Rechtsinhaberschaft A 67 – versichertes Risiko O 251 – Vertragsbeendigung G 436 – wesentliche Investition A 50 Datenbankwerk – Begriff A 47 – Übersicht zur Schutzfähigkeit A 51 – Urheberrechtsschutz A 46 ff. – Urheberschaft/Rechtsinhaberschaft A 67 Datenhaltungs-Schicht Q 70

Datenherausgabe – Vertragsbeendigung G 436 Dateninkonsistenzen D 261 Datenlöschung siehe Löschung von Daten Datenmigration – Vertragsbeendigung G 436 Datenmodell – Bewertungsdurchführung Q 211 – Due Diligence Q 92 ff. – Lieferung, Nebenpflicht D 136 ff. – Normalisierung Q 97 – Software-Bewertung Q 67 – Speicherung von Daten Q 93 f. Datennetze – unbefugte Eingriffe, Versicherungsschutz O 220 Datensammlung A 48 Datenschaden – abweichende Deckungskonzepte O 255 f. – Bewertung des Versicherungsschutzes O 249 – Sachschaden O 17 ff. – Selbstbehalt O 206 – Versicherungsschutz O 81 ff. – Versicherungsschutz, BBR IT-Dienstleister O 204 f. Datenschutz – Abnahme G 341 – Auftragsdatenverarbeitung F 73 – Cloud-Computing C 394 – Fernpflege I 365 ff. – Funktionsübertragung bei personenbezogenen Daten C 402 f. – Geheimhaltung personenbezogener Daten C 398 ff. – internationaler Bezug F 70 ff. – Outsourcing C 393 – personenbezogene Daten, Softwarepflege I 373 f. – Privatgeheimnis I 369 – Projekt-Vertrag C 378 ff. – Softwarepflegevertrag I 365 ff. – Testverfahren G 341 – Vermögensschaden bei Verletzung O 211 ff. – Verschlüsselung personenbezogener Daten C 404 Datensicherung – Gefahrverhütung, Obliegenheit O 215 f. – Installationsleistungen I 441 ff. – Mitverschulden D 323 – Muster, Vertragsklausel D 516, 518 – Software-Bewertung Q 28 – unzureichend, Versicherungsschutz O 215 ff. – Versicherungsklausel O 217 ff. Datenspeicherung – Software-Bewertung Q 67 Datenträger – Betriebsspionage A 320

1515

Stichwortverzeichnis – Vertragseinordnung B 32 ff. – Vorlegungspflicht, § 142 ZPO A 384 Datenübermittlung – Verlust der Vertraulichkeit, Versicherungsschutz O 85 Datenverarbeitung – unbefugte Eingriffe, Versicherungsschutz O 220 Datenverarbeitungsanlagen – Projekt-Vertrag C 379 Dauerschuldverhältnis – Auftragswert, Vergabeverfahren N 65 f. – Entgeltproblematik I 208 – Hinterlegung L 133 f. – Lizenzvertrag L 156 – Softwarepflegevertrag I 327, 528 Deckungsanspruch – Auslandsschäden O 71 – Rechtsschutzfunktion O 34 – Umfang O 33 ff. Deckungserweiterung O 11, 61, 92, 95, 196 ff., 264 ff. Deckungsgleichheit – Insolvenzfestigkeit L 41 f. Deckungssumme siehe Versicherungssumme Deckungsumfang siehe auch versicherte Kosten – Herstellungskosten O 114 – Tätigkeitsspätschäden O 102 – Verbindungs-, Vermischungs-, Verarbeitungsschäden O 112 ff. De-facto-Vergaben – Begriff N 82 – Folgen N 84 – Nachprüfungsverfahren N 80, 300 – vergaberechtliches Umgehungsverbot N 83 Defizite – Bewertungsdurchführung Q 222 ff. Deinstallation – Begriff I 433 Dekompilierung – Begriff A 108 – Berechtigter A 109 – beschränkter Zweck A 110 ff. – Betriebsspionage A 319 – Unerlässlichkeit A 113 – Verwendungsbeschränkung A 114 – zustimmungsfreie Maßnahmen A 106 ff. Demoversion – Shareware A 348 Denial Persons List – Belieferung mit Auslandsbezug F 86 DESCA – Background M 118 – Definitionskapitel M 115 – Foreground M 119 – Haftungsausschluss M 111 – IP-Regeln M 113

1516

– Zuordnung des erarbeiteten Eigentums M 112 – Zuwendungsrecht, EU M 108 ff. Design Pattern Q 82 Deutsche Forschungsgemeinschaft M 26 Deutsche Rentenversicherung Bund – Antragsverfahren zur Aufklärung über Scheinselbständigkeit E 246 Deutsches Patent- und Markenamt – Schiedsstelle für Arbeitnehmerstreitigkeiten E 81 Deutschland – Forschungsförderung M 14 ff. – Investitionsquote M 2 ff. – Softwareerstellungsverträge F 14 DGRI – Schiedsgutachter H 120 Dialogphase – wettbewerblicher Dialog N 111 ff. Diensterfindung – Geheimhaltungsverpflichtung E 134 Dienstleistung – ergänzender Leistungsschutz A 271 – hardwarebezogen O 192 – softwarebezogen O 190 – Umsätze, Software-Bewertung Q 263 Dienstleistungsrichtlinie – Wertungskriterien, Vergaberecht N 159 Dienstleistungstyp – EVB-IT N 183 Dienstverhältnisse – Urheberrecht E 28 Dienstvertrag – Abgrenzung zum Werkvertrag siehe auch Werk- oder Dienstvertrag – Arbeitnehmerüberlassung E 219 – Erfolgsverantwortung, Projektverantwortung H 28 f. – Fehlen eines Rechtsübertragungszeitpunkts A 148 – Implementierung von Standardsoftware G 94, 71 ff. – Leistungsstörungen C 340 ff. – Mitwirkungspflichten des Auftraggebers G 213 – Nacherfüllung C 176, 342 – ordentliche Kündigung G 425 – Planungsphase C 26, 70 – Projektmanagement C 193 – Projekt-Verträge C 54 ff. – Softwarepflegevertrag I 466 – Unterstützung des Auftraggebers C 177 ff. – Unterstützungsleistung C 170 – Vergütung der Softwareerstellung A 173 ff. – Verweisung ins allgemeine Leistungsstörungsrecht C 341 – Werkvertrag E 251 ff.; siehe auch Werkoder Dienstvertrag – Zeitaufwandsprojekt G 271 f.

Stichwortverzeichnis Dienstwagen – Aufhebungsvertrag E 198 Differenzhypothese – Schadensersatzanspruch I 161 DIN – Begriff des Pflichtenhefts C 81 – Mangelbegriff G 377 DIN EN ISO 9000-2005/9001 – Software-Bewertung Q 147 Diskriminierung – Vergabeverfahren N 20 Disparität – Vertragsparteien E 3 dispute resolution clauses F 40 ff. Dissens – AGB-Klausel J 31 f. Dokumentation – agile Softwareentwicklung D 111 f. – allgemeine Geschäftsbedingungen D 132 – Änderungswünsche D 158 – Anforderungen C 280 – Anpassungsprojekt C 273 – Anwenderdokumentation G 243; Q 105 f. – Arbeitnehmer auferlegt E 14 – Arten G 233 – Benutzerhandbuch D 119 ff. – Betriebsdokumentation G 245 – Bewertungsdurchführung Q 211 – BVB-Planung C 278 ff. – Defizite Q 133 – Due Diligence Q 29 f., 100 ff. – Echtdatentest C 426 – Empfehlung bei Individualvereinbarung J 78 – Eskalationsstufen I 517 – Fehlen G 232 – Fehler bei Qualitätssicherung Q 156 ff. – fehlerhaft D 135 – Form und Art G 231 ff. – Freigabe C 271 – häufige Änderungswünsche C 285 ff. – Hauptleistungspflicht, Werkunternehmer, freier Mitarbeiter E 288 – Hinterlegung Q 246 – Inhalt und Umfang I 431 f. – Inhalt, DIN 66270 Q 103 – Inline, Due Diligence Q 79 – Inline-Dokumentation Q 112 f. – Installation G 246 – komplexere Projekte C 285 – Leistungen des Anbieters G 231 ff. – Lieferungsumfang, Vereinbarungen D 131 – Losaufteilung, Vergabeverfahren N 26 – Miturheberschaft A 59 – Musterformulierung G 247 – Nebenpflicht D 119 ff., 126 ff. – notwendige Bereiche Q 101

– ordnungsgemäße Leistungserbringung B 77 – Perpetuierungsfunktion Q 102 – Pflichtenheft C 269; G 172 – Programmbeschreibung C 276 – Programmkorrekturen I 424 ff. – Projektmanagement H 96 ff. – Projekt-Verträge C 269 ff. – Prüfungshandlungen, IDW PS 850 Q 205 – Quellcode C 283; Q 101 – Recht am Arbeitsergebnis E 5 – Rechtsfolgen bei Nichtlieferung D 134 f. – Schlechtleistung G 406 – Software-Architektur Q 114 – Software-Bewertung Q 67 – Softwareentwicklung Q 115 ff., 121 – Softwareprüfung, IDW PS 880 Q 206 – Sprache G 237 – Systemdokumentation G 244; Q 107 ff. – typische Mängel G 240 – übergreifende Darstellungen Q 114 – Übertragung auf Dritte I 535 ff. – update I 430 – Verfahrensdokumentation Q 101, 109 ff. – Vergabeakte N 119 – Vergabeverfahren N 116 – Verlauf des Projekts C 270 – Vertragsbestandteil R 2 – Vertragseinordnung B 49 – Vertragsgegenstand B 78 f. – Wartung/Pflege G 234 Dokumente – Vorlegungspflicht, § 142 ZPO A 384 Doppelbesteuerungsabkommen – Software P 33 – Übersicht P 39 Download – Erschöpfungsgrundsatz A 88 – Patches, Updates I 438 Drittbezug – Mängelhaftung , Entgelt I 151 ff. – Pflegegegenstand, Versionsstand I 271 – Softwarepflegevertrag I 88 ff. Dritter/Dritte – Betriebsspionage A 317 – Escrow-Agent L 32 – Geltendmachung von Rechten D 481 ff. – Haftung im Verhandlungsstadium G 15 ff. – Hinterlegungsunternehmen L 15 – Vergütung von Nutzungsrechten A 193 f. – Verletzung von Schutzrechten G 400, 404 – Versicherungsschutz O 10 – Vorlagenfreibeuterei A 324 – Vorlegungspflicht, Softwareschutz A 384 Druckbalkenentscheidung A 383

1517

Stichwortverzeichnis Dual-use-Güter – Definition F 77 ff. – pauschaler Genehmigungsvorbehalt F 79 – Software F 82 ff. – verwendungsbezogene Genehmigungspflicht F 80 – Verwendungsprognose F 78 Dual-use-Verordnung F 75 Due Diligence – agile Programmierung Q 131 ff. – Anwenderdokumentation Q 105 f. – Bedrohungsanalyse Q 40 – Betriebshandbuch Q 107 ff. – Bundesdatenschutzgesetz Q 31 – CMMI Q 135 ff. – Codierungsstandards Q 78 – Datenmodell Q 92 ff. – Design Pattern Q 82 – Dokumentation Q 100 ff. – Dokumentation der Software Q 67 – Einfluss des Programmierstils Q 76 f. – eingeschränkte Nutzungsrechte Q 87 f. – Entwicklungsprozesse Q 67 – Ergonomie Q 56 ff. – Extreme Programming Q 131 ff. – fachlich funktionale Anforderungen Q 22 – Fehlerfreiheit der Software Q 51 – Frameworks Q 40, 68, 83 ff. – gesetzliche Anforderungen Q 23 ff. – Grundsätze ordnungsgemäßer Buchführung Q 26 ff. – Inline-Dokumentation Q 79, 112 f. – IT-Sicherheit Q 36 ff. – Laufzeitverhalten Q 52 ff. – Libraries Q 83 ff. – Mehrsprachigkeit Q 64 – Modellierungstechniken Q 82 – Offenheit Q 32 ff. – Open Source-Komponenten Q 83 ff. – Performanz Q 52 ff. – Programmier-Richtlinien Q 76 f. – Programmiersprache Q 68, 88 – Qualität des Datenmodells Q 67 – Qualität des Quellcodes Q 67 – Qualitätssicherung Q 67, 148 ff. – Quellcode Q 74 ff. – Quellcode, fehlerhaft Q 89 ff. – Rational Unified Process (RUP) Q 129 f. – regulatorische Anforderungen Q 23 ff. – Schnittstellen Q 32 ff. – Scrum Q 131 ff. – Skalierbarkeit Q 65 ff. – Software-Architektur Q 67 ff., 114 – Softwareentwicklungs-Dokumentation Q 115 ff., 121 – Softwareentwicklungsprozess Q 119 ff.; siehe auch dort – Software-Qualität Q 49 ff. – Stabilität Q 52 ff.

1518

– – – – –

Systemdokumentation Q 107 ff. technologische Basis Q 68 ff. Umfang bei Software Q 2 Usability Q 56 ff. Verarbeitung personenbezogener Daten C 386 – Verfahrensdokumentation Q 109 ff. – Versions-Management Q 89 ff. – V-Modell/V-Modell XT Q 125 ff. – Vorschriften zum internen Kontrollsystem Q 29 f. – Wartbarkeit Q 65 ff. – Wasserfall-Modell Q 124 – wertbestimmende technische Faktoren Q 20 ff. Düsseldorfer Praxis – Durchsetzung des Softwareschutzes A 388 f. Durchsetzung des Softwareschutzes – ausländisches Recht A 378 ff. – Belgien A 379 – Besichtigungsanspruch A 382 f. – Deutsches Recht bis 2002 A 382 f. – Düsseldorfer Praxis A 388 f. – Durchsetzung am Markt A 398 ff. – England A 380 – EU-Richtlinie A 386 f. – Frankreich A 379 – Italien A 379 – Klageantrag A 377 – Musterbeschluss A 388 – Patentschutz A 376 ff. – Problemstellung A 376 – TRIPS-Abkommen A 384 – Umsetzung der Durchsetzungsrichtlinie A 387 – Urheberschutz A 376 ff. – USA, Durchsetzung A 378 – Vorlegungsvorschrift A 384 – vorprozessuale Ermittlungsmöglichkeit A 384 Dynamik – V-Modell C 319 f. Echtdatentest – Dokumentation C 426 – personenbezogene Daten C 425 f. – Zugriffsrechte C 426 E-Commerce – Service-Level-Agreements I 474 Effizienz – Softwarepflege I 407 Eigenart, wettbewerbliche A 273 ff. Eigenentwicklung – Open Source-Software A 366 ff. Eigenmontage-Ausschluss O 145 f. Eigenschaften – Schäden infolge Fehlens O 105 Eigentum – gesetzliche Verankerung P 13 ff.

Stichwortverzeichnis – Hinterlegung L 63, 69 ff. Eigentum, geistiges – EU-Projektförderung M 98 ff. – Forschungsförderung Deutschland M 57 ff. – Muster-Konsortialvertrag DESCA M 112 Eigentum, wirtschaftliches – Leasing R 22 ff. Eigentumsverhältnis – Hinterlegung L 146 – Software-Bewertung Q 238 ff. Eigentumsvorbehalt – Arbeitsergebnisse A 143 – Klausel bei Arbeitsergebnissen A 145 f. Eignung, Vergabe – Angebotseignung N 252 – Ausschlussgründe N 222 ff. – Bewertungsmatrix N 215 – Bundeszentralregister N 223 – Eigenerklärung N 224 – Eintragung im Berufs-/Handelsregister N 226 – Fachkunde N 212 – fachliche und technische Leistungsfähigkeit N 220 f. – Grundsätze N 210 f. – Leistungsfähigkeit N 213 – Nachweis N 216 f. – Nachweise für Leistungsfähigkeit, EuGH N 219 – Präqualifikation N 227 – Übersicht über die Kriterien N 212 ff. – wirtschaftliche Leistungsfähigkeit N 218 f. – Zuverlässigkeit N 214 Einbaukosten – Anwendbarkeit auf Software O 136 – Schadenereignis O 134 – Versicherungsschutz, ProdHM O 134 ff. – Voraussetzungen O 135 Einführung der Standardsoftware siehe auch Standardsoftware, Implementierung – Aufgaben G 50 ff. – BGH-Rechtsprechung G 99 ff. – gemischter Vertrag G 112 ff.; siehe auch dort – Probleme G 122 ff. – wirtschaftliche Auswirkungen G 56 ff. – Vertragseinordnung siehe Rechtliche Einordnung Einführungsunterstützung G 151 Einfuhr – Software F 86 ff. Einkäufer – Softwareerstellungsverträge J 17 Einkünfte, steuerliche – bei Lizenzen P 36 ff. Einmalzahlung A 184

Einspruch – europäisches Patentrecht A 218 – Patentrecht A 209 Einstweilige Verfügung – Beweissicherung, Softwareschutz A 387 f. – Glaubhaftmachung L 139 – Herausgabe bei Hinterlegung L 122 – Kosten A 388 – Verfügungsgrund A 390 Einstweiliger Rechtsschutz – Softwareschutz A 384 – Unterschwellenvergaben N 354 Eintrittsmodell R 60 ff., 71 Einweisung/Schulung – Abnahme B 77 – fehlerhaft, Versicherungsschutz O 229 – Nebenleistung D 100 – Softwarepflegevertrag I 11 – Standardsoftware G 148 ff. Einwendungsdurchgriff – Softwarepflege-, Softwareüberlassungsvertrag I 128 ff. Einwilligung – Auftragsdatenverarbeitung C 437 f. Elementarprozesse Q 162 ff. Empfangsvollmacht – Antrag, Vergabeverfahren N 297 End-of-life – Herausgabe bei Hinterlegung L 123, 126 ff. End-of-life-Schreiben – Kündigungserklärung I 351 – Nachweis über Zugang I 356 – Rechtsbindungswille I 352 – Rechtsmissbrauch I 357 – Zugang I 353 ff. England siehe Großbritannien Enterprise Ressource Planning G 34 Entgangener Gewinn – AGB B 67 – Haftungsbeschränkung G 409 – Maschinenklausel O 159 – Verzugsschaden D 402 Entgelt – Software, Fehleranteil I 4 ff. Entgelterstattung – Service-Level-Agreements I 493 ff. Entgeltlichkeit – OSS N 35 – Vergaberecht N 34 f. Entgeltproblematik – Vertragsgegenstand I 148 ff. Entgeltzahlung – verzögert E 166 Entscheidung – Nachprüfungsverfahren N 341 Entwicklerrechte E 265 ff. Entwicklung – Forschungsförderung M 19 ff.

1519

Stichwortverzeichnis Entwicklungsauftrag – Verhandlungsverfahren ohne Vergabebekanntmachung N 100 Entwicklungsaufwand – Ansätze in der Informatik Q 159 – Bewertungsdurchführung Q 208, 219 ff. – Korrektur Q 187 – Kostentreiberfaktoren Q 171 – Personalkosten Q 228 ff. – Personenmonate Q 167 – Vereitelung der Amortisation A 285 f. – bilanzielle Behandlung P 3 Entwicklungsbedingungen – COCOMO-Verfahren Q 180 ff. Entwicklungsflexibilität Q 182 Entwicklungsphase – kurz, agile Methodik C 126 Entwicklungsteam – Miturheber A 56 Entwicklungsunterauftrag – Arbeitnehmerüberlassung E 218 Entwicklungsvertrag – freier Mitarbeiter E 244 Entwurfsmaterial – gesetzliche Lizenz A 132 – konzeptionelle Vorgaben A 26 – Schutzfähigkeit A 3 f. – Übersicht zur Schutzfähigkeit A 51 – Urheberrechtsschutz A 23 Entwurfsmuster Q 82 Erfinder – Konsortium E 353 Erfindervergütung – Abgeltungstheorie E 115 f. – Abkaufregelung E 88 – Arbeitnehmerüberlassung E 95 ff. – Arbeits-/Zivilrecht E 109 – Auskunftsanspruch E 87 – Entwicklung im Konzern E 93 f. – Erfindung der Organe oder Geschäftsführer E 102 ff. – Fördermittel E 92 – Hochschulentwicklung E 105 ff. – jährliche E 86 – Konsortial-Projektvertrag E 101 – Serienproduktentwicklung E 91 – Softwareerstellung im Kooperationsverhältnis E 95 ff. – Sondervergütung E 103 – Urheberrechtsgesetz E 110 ff. – Wertungen des ArbEG E 104 Erfindung siehe technische Erfindung Erfindungshöhe – Patentschutz für Software A 231, 237 Erfindungswert – Ermittlung im Einzelfall E 85 – vertikaler Entwicklungsvertrag E 90 Erfolg – Projektmanagement H 73 Erfolgsverpflichtung – Scrum/agiles Programmieren F 19

1520

– Zuordnung F 20 Erfüllungsgehilfe – Schadensersatz G 348 Ergänzende Vertragsauslegung – Ausschluss des Kündigungsrechts bei Softwarepflege I 326 – entgeltliche Standardpflege I 337 Ergänzender Leistungsschutz siehe Leistungsschutz Ergebnisüberprüfung – Dokumentation B 88 – Einordnung B 80 ff. – Fristenplan B 84 – Installation B 85 – Überwachung B 87 – Vertragsgegenstand B 80 ff. Ergebnisveröffentlichung – Vergabeverfahren N 263 Ergonomie – Software-Bewertung Q 56 ff. Erkundigungspflicht – Auftragnehmer C 51 – Beibringungspflicht C 54 – fachliche Anforderungen C 76 – Überprüfung der Angaben C 59 Erlös – Software-Bewertung Q 258 ff. Ermessen – Eignung, Vergabe N 222 – Vergabevermerk N 119 Ermittlung, vorprozessual A 384 Erprobungsklausel – Anwendungsbereich O 171 – Ausschluss vom Versicherungsschutz O 171 ff., 239 – Individualsoftware O 239 – Stand der Technik O 172 f. Ersatzleistungen – versicherte Ansprüche O 27 Ersatzvornahme – Implementierung von Standardsoftware G 79 Erschöpfungsgrundsatz – Gebrauchtsoftware G 134 – Insolvenzfestigkeit L 43 – Pflegeleistung durch Dritte I 535 – Software-Leasing A 90 – Verbreitungsrechte A 88 ff. – Vermietung A 89 Ersichtlichkeit – Luftprodukthaftpflicht O 175 – Schäden durch Umwelteinwirkung O 77 Ersparter Aufwand – ordentliche Kündigung G 422 ff. Ertrag – Miturheberschaft A 64 Ertragskraft – Unternehmensbewertung Q 201 Ertragswert – Software-Bewertung Q 10 f., 19

Stichwortverzeichnis Erzeugnis – Austauschkosten, Weiterverarbeitung O 139 – Inverkehrbringen O 225 – Inverkehrbringen, ProdHM O 95 – Lieferung, Warenklausel O 179 – Verbindungs-, Vermischungs-, Verarbeitungsschäden O 108 ff. – Weiterverarbeitung und -bearbeitung, ProdHM O 129 f. Escrow siehe Hinterlegung Escrow Agent F 67 ff. – Beendigung der Vereinbarung L 166 f. – Dritter L 32 – Insolvenzfestigkeit L 56 f. – Leistungsbereiche L 92 – Leistungsstörungen L 162 ff. – Mitwirkungspflichten L 162 ff. – rechtliche Einordnung L 158 – Rückgabe L 96 – Update L 91 – Verifikation L 93 ff. – Vertragskonstruktionen L 99 ff. – Vervielfältigungsrecht L 35, 90 Escrow-Unternehmen siehe Hinterlegungsunternehmen Eskalation – Projektmanagement H 114 ff. – vertragliche Lösung H 120 Eskalationsprozess – Gerichtsweg I 518 – Service-Level-Agreements I 515 ff. – Verjährung I 519 Eskalationsstufen – Dokumentation I 517 – Fristen I 516 – Individualvereinbarung I 515 ff. EU-FuE-Förderung E 366 EuGH – grafische Benutzeroberfläche A 12 – Oracle B 3 – rechtzeitige Rüge im Nachprüfungsverfahren, Vergaberecht N 312 – Teckal-Kriterien N 38 f. – Überprüfung der Förderung M 9 – Vertragsveränderung, Vergabeverfahren N 44 EuGVVO – Vollstreckung/Anerkennung ausländischer Urteile F 44 EU-Recht – grenzüberschreitende Verträge F 2 EU-Richtlinie – Durchsetzung des Softwareschutzes A 386 f. – Patentfähigkeit A 226 – Verkaufsgüterkaufrichtlinie C 66 Eurofähigkeit – Herausgabe bei Hinterlegung L 128

Europa – Forschungsförderung E 366; M 27 ff.; siehe auch dort – Forschungsinstitute M 29 – Investitionsquote M 2 ff. – Sicherheit, Rahmenbeschluss I 25 Europäische Atomgemeinschaft – Forschungsförderung M 28 ff. Europäische Förderstellen M 124 ff. Europäische Grundfreiheiten – Wettbewerbsgrundsatz N 19 Europäischer Forschungsraum – Entwicklung M 4 ff. Europäisches Patentamt – Abgrenzung zur BGH-Rechtsprechung A 244 ff. – Beitragsansatz A 229 – Erfindungshöhe A 237 – Patentfähigkeit A 226 ff. – Unterschiede zur BGH-Rechtsprechung A 233 – weiterer technischer Effekt A 230 Europäisches Patentübereinkommen, EPÜ A 213 Europäisches Zuwendungsrecht siehe Zuwendungsrecht, EU European Space Agency – europäische Förderung M 14 – weitere europäische Förderstellen M 124 EU-Schwellenwert – Vergabeverfahren N 16 EU-Standardvertragsklausel – Auftragsdatenverarbeitung C 439 EU-Vergaberichtlinien – Aufzählung N 6 – Reformschritte in Deutschland N 11 – Sicherheit N 14 – Umsetzung N 8 ff. EVB-IT – Beschaffung von IT-Dienstleistungen M 128 ff. – Dienstleistung N 183 – formaler Aufbau N 177 ff. – geplante Vertragstypen N 199 – Inhaltskontrolle, Vergabeverfahren N 173 – Instandhaltung N 184 – Kauf N 180 – Nutzungshinweise N 178 – öffentliche Auftraggeber I 52 – sonstige Vereinbarungen N 177 – Überlassung Typ A N 181 – Überlassung Typ B N 182 – Vertragsformular N 177 EVB-IT-Pflege S – Anpassung an Pflegemodelle N 188 – auch funktionale Verbesserung I 43 – Auftragsdatenverarbeitung I 374

1521

Stichwortverzeichnis – besondere Vereinbarungen N 187 – Bündelung mehrerer Mängelbehebungen bei Standardsoftware I 42 – Datenschutz I 366 ff. – Fernpflege I 360 ff. – Hotline I 457 – Inhalt und Umfang der Softwaredokumentation I 432 – Installationsleistungen I 437 – Mangel I 396 – Nutzungsrechte I 520 – Pflegeverweigerung I 276 – Preisanpassung I 204 – Programmkorrekturen I 38 – Programmkorrekturen, einschließlich Dokumentation I 426 – release I 44 – Softwarepflege I 36 – Standardsoftware N 185 ff. – Systemumgebung I 377 f. – Vergütung I 392 – weitere Pflegeleistungen I 457 EVB-IT System – Abnahme N 193 – Begriffsabgleich mit Pflichtenheft C 80 ff. – Beschaffung komplexer IT-Systeme N 189 ff. – Haftungsbegrenzung N 193 – Leistungen bis zur Abnahme N 191 – Leistungen nach der Abnahme N 192f – Lieferung N 194 ff. – Mängelhaftung N 193 – Nutzungsrechtsmatrizen N 193 – Regelungen zur Rechtseinräumung N 193 – Service N 193 – Systemlieferung, Vertragsgegenstand N 194 ff. – Trennung von Planung und Realisierung C3 – V-Modell C 199 – Voraussetzungen N 190 ff. – Vorgehensmodell C 3 Existenzgründung – Forschungsförderung M 21 Experte – Sachverständigenhaftung G 20 Exporte – Versicherungsschutz O 66 Exportkontrolle F 74 ff. – Copyleft Effekt F 90 f. – Strafbarkeit F 87 ff. Extreme Programming – Abgrenzung zu Scrum C 130 – agile Methodik C 128 ff. – explizite Planung C 130 – Grundlagen C 129 – Modelle im Projektmanagement H 64 – Software-Bewertung Q 131 ff.

1522

– Test Driven Development Q 126 Exzellenzzentren – Europa M 4 EZB – Preisklauseln I 213 Fachlose – Aufteilung im Vergaberecht N 24 Fachzeitschrift – Vergabeveröffentlichung N 204 Fahrlässigkeit – Freizeichnungs-/Begrenzungsklauseln K 39 ff. Fälligkeit – Abnahmeklauseln D 219 – Vergütung D 179 ff. – Vergütungsregelungen G 316 Falschberatung C 176, 352 ff. Faxkarte – BGH-Rechtsprechung A 385 Fehlbedienungen – Mangel D 261 Fehlen vereinbarter Eigenschaften – Folgeschäden O 105 – Personenschäden O 105 – Sachschäden O 105 – Vermögensschäden O 106 Fehler – Grad der Erkennbarkeit C 243 Fehlerberichtigung A 100 Fehlerbeseitigungskosten – Softwarepflegevertrag I 3 – zusätzlicher Pflegevertrag I 7 ff. Fehlerdokumentation – Qualitätssicherung Q 156 ff. Fehlerentdeckung – Qualitätssicherung Q 150 Fehlerfreiheit – Software-Bewertung Q 51 Fehlerkategorien – Service-Level-Agreements I 484 f. Fehlerklassen – SLA B 76 Fehlermanagement – Qualitätssicherung Q 156 ff. Fehlermeldungen – Dokumentation D 284 ff. – falsche Beschreibung D 285 f. – Mangel D 265 – Softwarepflegevertrag I 452 Fehlschlagen – Nacherfüllung D 293 Feinkonzept – BVB-Planung/-Erstellung C 86 f. – Projektmanagement H 69 – Schwierigkeiten bei der Erstellung C 309 – Übersicht zur Schutzfähigkeit A 51 – Urheberrechtsschutz A 23

Stichwortverzeichnis Feinspezifikation siehe auch Leistungsbeschreibung – Anbieterleistung G 135 ff. – Anforderungen G 152 f. Fernpflege – Datenschutz I 365 ff. – Hotline I 446 – Softwarepflegevertrag I 358 ff. Fernübertragung von Software O 67 Fernwartung – Geheimhaltungspflicht E 135 Fernzugriff – personenbezogene Daten C 427 Festpreis – Abrede G 311 f. – Änderung des Leistungsumfangs G 260 – Änderungswünsche D 169 – Change Request G 271 ff. – Dienst-/Werkvertragsrecht G 306 – Kalkulationsirrtum G 311 f. – Musterformulierung im Vertrag G 312 – Nachweis des Mehraufwands G 277 ff. – Planungssicherheit für Auftraggeber C 200 – Risiko für Auftragnehmer C 200 Field of use-Regelung – Hinterlegung L 140 Fiktion – Abnahme D 215 ff.; G 337, 340 Finanzbuchhaltung – Buchungskapazität D 268 – Mitwirkung des Anwenders G 218 – typische Softwaremängel G 373 Finanzdienstleistungen – Vergütungsbestandteil E 17 Finanzierung – Forschungsförderung M 12 ff. Finanzierungsleasing R 1 – Beschaffungspflicht/Grenzen R 32 ff. – Beschaffungsrisiko R 32 – Gebrauchsüberlassung R 69 ff. – Hauptpflichten des Leasinggebers R 31 ff. – Hauptpflichten des Leasingnehmers R 41 ff. – Nutzungsüberlassung R 37 – Rechtsnatur R 12 – Überlassung des Objekts R 31 – Vergütung R 39 f. – Zahlung nach Abnahme R 40 Finanzverwaltung – immaterielles Wirtschaftsgut P 6 Firmenwagen – Vergütungsbestandteil E 17 Firmware – Sammelwerk, Copyleft-Effekt A 358 ff. First to file-Prinzip A 206 Folge-Pflegevereinbarung – Kosten I 260 Folgeschäden – Projekt-Verträge C 352 f.

Förderprogramme – Segmentierung M 41 Fördervolumina – BMBF M 132 Foreground M 98, 119 Formularvertrag – Beweislastumkehr, Verletzung der Systemumgebung-Einsatzobliegenheit I 384 Formulierungsbeispiel siehe Gestaltungsvorschläge Forschung – öffentliche Förderung siehe Forschungsförderung Forschungsauftrag – Verhandlungsverfahren ohne Vergabebekanntmachung N 100 Forschungsförderung siehe auch Zuwendungsrecht, EU – Antrags- und Genehmigungsverfahren M 49 – Arbeitnehmererfindungsgesetz M 65 – Beiträge, Spenden M 17 – deutsche Programme M 39 ff. – europäische Förderung M 13 – EU siehe Europa – Euratom M 31 – EUREKA M 33 – Europäische Gemeinschaft für Kohle und Stahl (EGKS) M 32 – European Space Agency (ESA) M 34 – Förderarten M 30 – Förderungsquellen M 12 f. – Formulare M 49 – Grenzen M 7 ff. – in Deutschland M 14 ff. – in Europa M 27 ff. – institutionelle Förderung M 15 ff. – Kosten für Schutzrechtsanmeldungen M 55 – Nebenbestimmungen M 46 ff. – Notifizierung M 9 – öffentliches Haushaltsrecht M 16 – ohne Rückzahlungsverpflichtung M 44 – privatwirtschaftlich organisierte Institutionen M 12 – Projektförderung M 19 ff. – Projektförderung/institutionelle Förderung M 14 ff. – Quellen der Förderung M 12 f. – Recht am Ergebnis M 57 ff. – Schlussbericht M 56 – Verbot der Doppelförderung M 53 – Vertrag, Zuwendung M 44 – Vertragsmuster M 62 ff. – weitere europäische Förderstellen M 35 Forschungsrahmenprogramm – europäisches Zuwendungsrecht M 71 ff. Forschungsrahmenprogramm (7.) – Beteiligungsregelungen M 93 – Fördermittel M 73 ff.

1523

Stichwortverzeichnis – Fördervoraussetzungen M 91 ff. Foss – Due Diligence Q 88 Framework – Due Diligence Q 40, 68, 83 ff. – Software-Bewertung Q 239 Frankreich – Durchsetzung des Softwareschutzes A 379 – Haftungsregelungen F 22 – Insolvenz des Auftraggebers F 63 – Patentfähigkeit A 240 – Softwareerstellungsverträge F 15 Freeware – Open Source-Software A 346 Freier Mitarbeiter – arbeitnehmerähnliche Person E 243 – Arbeitszeit E 242 – Beendigung des Arbeitsverhältnisses E 290 ff. – Begriff E 241 f. – Entwicklungsvertrag E 244 – Geheimhaltung E 273 – Geheimnisverrat A 308 – Informatiker N 71 – Konkurrenzverbot E 274 – Leistungsstörungen E 275 ff. – Leistungsstörungen im Dienstvertrag E 276 ff. – Leistungsstörungen im Werkvertrag E 279 ff. – Miturheber A 54 – nachvertragliches Wettbewerbsverbot E 148 – Nutzungs-/Verwertungsrechte E 293 ff. – Rechtsübertragung E 264 – Scheinselbständige E 245 ff. – technische Erfindungen E 263 – Verjährung der Gewährleistungsansprüche E 286 ff. – Zeitpunkt der Rechtsübertragung A 150 – Zweckerreichung, Werkvertrag E 292 Freies Werk – Anbietungspflicht E 78 – Begriff E 77 f. – Urheber-Nutzungsrecht E 56 Freigabe – als Abnahme B 124 – Anbieterinteresse C 361 ff. – Anwenderinteressen C 359 f. – Auswirkungen C 208 – Beispiel C 368 – Change Managements C 207 – Dokumentation C 271 – Iterationsschritte C 206 – Leistungsstörungen C 367 ff. – Planungsphase C 182 – Rechtsfolgen C 334 f. – statt Abnahme C 334 Freihändige Vergabe – Bedeutung N 93 ff.

1524

– Nachprüfungsverfahren N 80 f. – Verhandlungsverfahren siehe dort – VOL/A N 97 Freistellung – Aufhebungsvertrag E 198 Freizeichnung – Haftung J 1 ff. Freizeichnungs-/Begrenzungsklauseln – AGB K 16 – Auftraggeber als Verwender K 18 ff. – Auftragnehmer als Verwender K 27 ff. – fahrlässige Pflichtverletzung K 39 ff. – Individualvereinbarung K 13 f., 40 – praktische Schlussfolgerung K 15 – Sanktionen für unwirksame ~ K 66 f. – Schadensersatzanspruch K 50 ff. – Verletzung von Leben, Körper oder Gesundheit K 28 ff. – verschuldensunabhängige Haftung K 19 ff. Fremdfinanzierung – Finanzierungsleasing R 72 Fristen – Change Request G 283 – Formulierung bei Anwendermitwirkung G 230 – Nacherfüllungsanspruch D 291 – Rücktritt oder Schadensersatz K 53 ff. – Rügeobliegenheiten, § 651 BGB D 374 ff. – verspätete Herstellung D 405 – vor/nach Abnahme D 279 Fristen- und Aktivitätenplan – Formulierungsbeispiel G 203 – Projektplanung G 197 ff. Fristsetzung – Implementierung von Standardsoftware G 35 – Nichteinhaltung von Terminen G 202 f. – Planungsprozess C 55 – Verzug G 361 f. FuE siehe Forschungsförderung FuE-GVO – schwarze Klauseln E 346 – weiße Klauseln E 345 Fürsorgepflicht – Arbeitgebers E 1 Function Point Analysis – Elementarprozesse Q 162 ff. – IFPUG Q 161 Functionality Compliance Q 23 ff. Funktionale Anforderungen – Benutzerinteraktionen G 185 – Formulierungsbeispiele G 185 – Kriterien G 195 f. – Pflichtenheft G 180 ff. – Verkaufssystem G 184 Funktionalität – Bewertungsdurchführung Q 211 – Implementierung von Standardsoftware G 35

Stichwortverzeichnis – Mangel D 255 f. – Softwarepflege I 407 – Urheberechtsschutz A 11 Funktionsmangel – Pflichtenheft C 71, 148 – Vertragsbestandteil B 127 Funktionsprüfung – Abnahme D 198, 222 – Muster, Vertragsklausel D 495 – Rechtseinräumung an den Arbeitsergebnissen A 141 Garantie – Abgrenzung zur Leistungsbeschreibung G 165 ff. – allgemeine Geschäftsbedingungen G 169 – Ausschluss vom Versicherungsschutz O 167, 235 – Beschaffenheitsgarantie K 10 f. – entgangener Gewinn K 11 – Formulierung G 166 – Haftung ohne Verschulden D 347 – Haftungsausschluss D 349 – Implementierung von Standardsoftware G 79 – Musterformulierung im Vertrag G 416 – Rechtsfolgen von Mängeln D 346 ff. Gebrauchsbeeinträchtigung – Sachschaden O 16 Gebrauchsmuster siehe auch Patentrecht – technische Erfindung A 202 – Vorprüfung A 207 Gebrauchsüberlassung – Risikoverteilung in AGB R 68 ff. – Zahlung der Leasingraten R 49 ff. Gebrauchtsoftware B 3 – Erschöpfungsgrundsatz G 134 Gefahrübergang – Abnahme G 327 – Implementierung von Standardsoftware G 79 Gegenvorschlag – bei Klauselverwendung J 57 ff. Geheimhaltung – Auftragsdatenverarbeitung C 398 ff. – freier Mitarbeiter E 273 – Regelung in der Absichtserklärung D 39 – Softwareentwickler E 273 – Vereinbarung bei personenbezogenen Daten C 405, 443 Geheimhaltungsverpflichtung – Abbruch von Vertragsverhandlungen G 22 – arbeitsrechtlicher Geheimnisschutz E 120 – Bundesdatenschutzgesetz E 135 – Datenverarbeitung E 135 – des Lieferanten D 418 ff. – Diensterfindung E 134

– Fernwartung E 135 – Herausgabeverpflichtung anvertrauter Dokumente E 122 – Interessenlage E 119 – Karenzentschädigung E 128 – Kündigung D 447 – Kündigung bei Verletzung D 424 – Letter of Intent G 23 ff. – Muster, Vertragsklausel D 458 – nachvertraglich E 126 ff., 147 ff. – nachvertragliche, Folgen eines Verstoßes E 129 – Rücktritt D 423 – Schadensersatz D 421 f. – spezialgesetzliche E 130 ff. – Treuepflicht E 15 – Umfang E 119 – Verletzung im Verhandlungsstadium G 10 ff. – Verstoß E 124 – Vertragsstrafen D 422 – während des Arbeitsverhältnisses E 120 ff. – wirtschaftliches Interesse E 121 Geheimnisschutz – Betriebsspionage A 317 ff. – Dekompilierung A 319 – Escrow-Unternehmen A 311 – Geheimhaltungsinteresse/-wille A 304 ff. – Geheimnisverrat A 299 ff., 312 ff. – Geheimnisverwertung A 322 ff. – Geschäfts-/Betriebsgeheimnis A 300 ff. – Herstellung einer verkörperten Wiedergabe A 320 – Individualsoftware A 310 – keine Offenkundigkeit A 307 ff. – Personenkreis A 308 – Rechtsfolgen eines Verstoßes A 325 ff. – Standardsoftware A 311 – Unternehmensbezug A 304 ff. – Verwertung A 296 – Vorlagenfreibeuterei A 324 – Wegnahme einer Sache A 321 – Wettbewerbsrecht A 296 ff. – Wirtschaftsstrafrecht A 297 Geheimnisverrat – anvertraut A 314 – Tatgegenstand A 314 – unbefugt A 316 – Unternehmensbeschäftigte A 313 – Verletzungshandlung A 315 – Zugänglichmachung A 314 Geheimnisverwertung A 322 ff. Gehilfe – Miturheber A 57 Geistige Schöpfung – Computerprogramme A 36, 42 Gemeiner Wert – Software Q 12 ff.

1525

Stichwortverzeichnis Gemeinschaftliche Forschungsinstitute – Joint Research Centres M 29 Gemeinschaftspatentübereinkommen, GPÜ A 210 Gemeinschaftsunternehmen – Konsortium E 320 Gemischter Vertrag siehe auch Rechtliche Einordnung – Absorptionstheorie G 116 – Beurteilung des Schwerpunkts G 117 – Gesamtrichtung des Vertrages G 115 – individuelle Gestaltung G 120 – Kombinationstheorie G 116 – Leistungsstörungen G 344 – notwendige Elemente G 121 – rechtliche Typisierung G 116 – Unterschied zusammengesetzter Vertrag G 113 General Public License (GPL) A 351 ff., 358 ff. Generalunternehmer – Begriff E 295b – Grundlage für Subunternehmervertrag E 302 – Haftung bei Nicht- oder Schlechtleistung des Subunternehmers E 297 – Interessenlage bei Vergütung E 310 – Mängel E 298 – Rechteübertragung E 308 – Risiken aus Subunternehmervertrag E 296 – Zuschlag auf Leistung des Subunternehmers E 311 Generalunternehmervertrag – IT-Projektleasing R 10 Gerichtskosten – abweichende Deckungskonzepte O 268 Gerichtsstandsvereinbarung F 49 Gerichtszweig – Forschungsförderung M 45 Gesamthaftung – cap clause K 62 ff. Gesamthandsgemeinschaft – Miturheberschaft A 60 f. Gesamtlösung – Anwendersoftware C 178 ff. Gesamtprodukt – Preisnachlass O 122 – Produktionsausfall infolge Mangelhaftigkeit O 126 f. – Unveräußerlichkeit O 122 – Vernichtungskosten O 120 Gesamtschuldnerhaftung – Arbeitgeber und Arbeitnehmer E 165 Gesamtsozialversicherungsbeiträge – Nachzahlungspflicht E 246 Geschäftemachen – Begriff E 138 Geschäftsbesorgung – Hinterlegung L 74

1526

– Leistungsstörungen bei Hinterlegung L 162 ff. Geschäftsführererfindung – Sondervergütung E 103 Geschäftsgeheimnis siehe auch Betriebsgeheimnis – Akteneinsicht, Nachprüfungsverfahren N 332 – Arbeitsergebnisse A 309 – Begriff A 300 ff. – Betriebsspionage A 317 ff. Geschäftsgrundlage – Änderungswünsche D 174 Geschäftsreisen – Versicherungsschutz O 65 Gesellschaftsvertrag – Rechtseinräumung an den Arbeitsergebnissen A 123 – Konsortium E 319 Gesetz gegen Wettbewerbsbeschränkungen – Absage, Vergabe N 234 ff. – Ausnahmen vom Anwendungsbereich des Vergaberechts N 67 – Beschleunigungsgrundsatz N 336 – Interessenberücksichtigung des Mittelstandes N 25 – kein Wissensvorsprung für inländische Bewerber N 20 – Nachprüfungsverfahren N 256, 287 ff. – Schadensersatz, Vergabefehler N 349 ff. – Sicherheitsvergaberecht N 14 – Ungleichbehandlung N 20 f. – Unternehmensbegriff N 36 – Vergabeverordnung, Sektorenverordnung N 13 – Vorschriften des 4. Teils N 12 ff. – wettbewerblicher Dialog N 105 Gesetzeskonformität – IDW Prüfungsstandards 850 Q 206 – Software-Bewertung Q 23 ff. Gesetzestreue – Eignung, Vergabe N 214 Gestaltungshöhe – Urheberrechtsschutz A 44 f. Gestaltungsrecht – Minderung D 308 f. – Rücktritt D 309 Gestaltungsvorschläge siehe auch Musterformulierung – Abnahmeklauseln D 494 ff. – Änderungsverfahren D 474 ff. – Anwendung von Kaufrecht, § 651 BGB D 503 ff. – Aufwandsvereinbarungen D 459 ff. – Change-Request-Verfahren D 474 ff. – Geheimhaltungsvereinbarung D 457 – Geltendmachung von Rechten durch Dritte D 481 ff. – Hinterlegungsvereinbarung L 85 – Mängelrechte, Musterklauseln D 505 ff.

Stichwortverzeichnis – – – – – – – –

Nacherfüllung, Musterklausel D 507 ff. Organisationsregeln D 466 ff. Projektleiter D 467 Projekt-Verträge D 455 ff. Schadensersatz D 513 ff. Schriftformklauseln D 476 ff. Stellvertretung D 467 vereinfachte Organisationsstruktur D 473 – Vergütungsregelung nach Kündigung D 519 – Verjährungsklauseln D 499 ff. – Vertragsstrafen D 457 – vorvertragliche Regelungen D 455 ff. Gesundheitsschäden D 322, 516 Gewährleistung – Bedienungsanleitung C 96 – Beschränkung G 374 – BVB-Planung C 27 – Open Source-Software A 368 ff. – Rechtsmangel G 366 Gewährleistungsausschluss – Weitergabe bei Open Source-Software A 354 Gewerbesteuer – Softwareüberlassung P 32 Gewerblicher Rechtsschutz – Kumulationsprinzip A 257 Gewinn – Miturheberschaft A 64 Gewinn, entgangener – Garantieübernahme K 11 – Wettbewerbsverstoß A 295 Gewinnverlagerung – immaterielles Wirtschaftsgut P 1 Gleichbehandlungsgrundsatz – Teilnahmewettbewerb N 232 – Transparenzgebot N 23 – Vergaberecht N 20 Globaler Wettbewerb – Softwarepflegevertrag I 18 Go-Life – Support G 151 – Verzug G 356 Grafische Benutzeroberfläche – Software-Bewertung Q 56 ff. – Übersicht zur Schutzfähigkeit A 51 – Urheberrechtsschutz A 12, 43 Grant Agreement – 7. Rahmenprogramm M 83 ff. – geistiges Eigentum M 112 ff. – Haftungsklausel M 106 – Zugangsrechte M 102 Grenznutzen – Software-Bewertung Q 14 – Unternehmensbewertung Q 201 Grenzregelungen – des Arbeitsvertrages E 3 Grobkonzept – Anforderungsprofil C 310 – Bewertung des Ist-Zustandes C 305

– BVB-Planung/-Erstellung C 86 f. – Erfolgsvereinbarung C 311 – frühzeitige Vornahme C 307 – Strukturierung C 313 – Übersicht zur Schutzfähigkeit A 51 – Urheberechtsschutz A 23 – Werkvertrag C 310 ff. Großbritannien – Begriff Escrow L 24 – Durchsetzung des Softwareschutzes A 380 – Escrow L 5 – Haftungsregelungen F 23 – Patentfähigkeit A 239, 243 – Softwareerstellungsverträge F 17 Großprojekte – Ursachen für das Scheitern G 128 Grünbuch – Vergaberecht N 11a Grundlagen – Vergaberecht N 1 ff. Gruppenfreistellungsverordnung – Forschung und Entwicklung M 5 – Konsortium E 331 – Vertikal-GVO E 335 ff. Gutachten siehe Sachverständigengutachten Gute Sitten – Interessenkonflikt zwischen Marktbeteiligten I 66 Haftpflichtbestimmung – Begriff O 31 Haftpflichtversicherungsschutz – Haftungsfreizeichnung K 33 – Risikovorsorge K 48 Haftung – Arbeitnehmer siehe Arbeitnehmerhaftung – ARGE-Softwareprojektvertrag E 369 – DESCA M 111 – Funktionsmangel C 152 – Kommission gegenüber Förderungsempfängern M 105 f. – Konsortium E 368 f. – Open Source-Software A 368 ff. – Unternehmensleitung, Versicherungsschutz O 2 – Mängelbeseitigung, AGB I 171 – Mängelbeseitigung, BGH I 169 f. – Quellensteuern P 40 – verschuldensunabhängige, Softwarepflege-, Softwareüberlassungsvertrag I 157 Haftung des Herstellers – Beratung D 12 – fehlerhafte Auskünfte D 14 Haftungsausschluss – allgemeine Geschäftsbedingungen G 411 ff. – Garantie D 349; G 166

1527

Stichwortverzeichnis – – – – –

Kardinalpflichten G 411 Leistungsstörungen G 408 Mängel L 8 Vorsatz G 416 Weitergabe bei Open Source-Software A 354 Haftungsbegrenzung – allgemeine Geschäftsbedingungen G 411 ff. – entgangener Gewinn G 409 – Enumeration K 61 – EVB-IT System N 193 – Individualvereinbarung G 415 ff. – Kardinalpflichten G 411 – Lizenzen G 413 – Muster, Vertragsklausel D 516 – Personalkosten G 413 – Personen-/Sachschäden G 409 – Produkthaftungsgesetz G 415 – Produktionsausfall G 413 – Sachverständigenkosten G 413 – salvatorische Zusätze K 67 – summenmäßig G 409 – umfassende K 60 ff. – Verschulden G 411 – Vertragsgestaltung G 407 ff. – vorhersehbarer Schaden K 36 f. Haftungsbegrenzungsklauseln – cap K 60 ff. – cap clause J 50 – Individualvereinbarung J 1 ff. – salvatorische Zusätze K 67 – Softwareerstellungsverträge J 38; K 59 ff. Haftungserleichterung – zugunsten Arbeitnehmer E 165 Haftungserweiterung – Ausschluss vom Versicherungsschutz O 52, 167 Haftungsfreistellungsklausel F 8 – Individualvereinbarung J 1 ff. Haftungsfreizeichnung siehe auch Freizeichnungs-/Begrenzungsklauseln – fahrlässige Pflichtverletzung K 39 ff. – Haftpflichtversicherungsschutz K 33 – Sachfolgeschäden K 48 – Vertrag mit Schutzwirkung zugunsten Dritter K 29 ff. Haftungsfrist – Mängelbeseitigung nach Fristablauf I 197 Haftungsregelungen – Arbeitnehmer siehe Arbeitnehmerhaftung – Abdingbarkeit F 21 – England F 23 – Frankreich F 22 – pauschales Abbedingen F 28 – Schweiz F 22 Haltbarkeitsgarantie G 165 Hamburger Vertrag – Konsortium E 365

1528

Handbuch – Anforderungen D 120 ff. – Begriff G 231 – Grundschutz-Handbuch des BSI Q 43 – Nebenpflicht D 119 – Sachgesamtheit, Lieferumfang I 427 ff. – Schulung D 121 – Sprache D 122 – Übersicht zur Schutzfähigkeit A 51 – Urheberrechtsschutz A 27, 43 Handelsbilanz – Lizenzen P 5 – Software P 4 Hardware – Beratungsvertrag bei Auswahl C 190 – Vermögensschäden, Versicherungsschutz O 231 – Wartung, EVB-IT Instandhaltung N 184 Hauptleistungspflicht – Inhaltskontrolle AGB J 68 – Transparenzgebot J 69 Haushaltsmittel – Vergaberecht N 124 Haushaltsrecht – Forschungsförderung M 16 – Unterlage für Ausschreibung und Bewertung von IT-Leistungen N 175 – Vergaberecht N 282 – Vertragsbedingungen, Vergaberecht N 174 ff. Hemmungswirkung – im Eskalationsprozess I 519 Herausgabe bei Hinterlegung L 82 – Allgemeines L 112 f. – Beispiele L 122 ff. – besondere Regelungen L 129 f. – End-of-life beim Unternehmer L 123 – Eurofähigkeit L 128 – Jahr 2000-Fehler L 126 – Rechte am Quellcode L 112 f. – Sicherheitsregelung L 121 – Software als Sache L 115 – Unkündbarkeit L 127 – Vertriebshaus L 119 Herausgabe des Quellcodes siehe Quellcodeherausgabe Herausgabeanspruch – Spezialleasing R 28 Herkunftstäuschung – nachschaffende Übernahme A 281 – Unlauterkeit A 284, 289 Herstellen – ergänzender Leistungsschutz A 267 Hersteller – Monopol am Quellcode I 87 – Vertragsgestaltung bei Standardsoftware G 66 ff. Herstellerleasing R 1 Herstellungs- und Lieferungsklausel O 62 Herstellungsanspruch D 277

Stichwortverzeichnis Herstellungskosten – Bewertungsdurchführung Q 216 ff. – Ermittlung des Quellcodeumfangs Q 216 ff. – Ersatz, Deckungsumfang O 114 – nutzlose, Maschinenklausel O 154 – Software-Bewertung Q 8, 159 Herstellungsrisiko – Projektverantwortung H 25 Hilfefunktion – online, Softwarebestandteil I 428 Hilfsmittel – Schäden O 57 Hilfstätigkeit – versichertes Risiko O 6 f. Hinterlegung – Ausschließlichkeit einer Field of use-Regelung L 140 – Bedingungsfeindlichkeit L 73 – Beendigung der Vereinbarung L 166 f. – Begriff L 24 ff. – Beschaffungsvertag L 99 – Beweissicherung L 158 ff. – Bewertungsdurchführung Q 246 – Dauerschuldverhältnis L 133 f. – de lege ferenda L 178 f. – durch den Kunden L 37 f. – Eigentum L 69 ff. – einstweilige Verfügung L 139 – Empfehlungen L 136 f. – Entwicklungsumgebung L 59 – Ersatzkopie L 87 – für unbekannten Kundenkreis L 35 f. – Geschäftsmodell L 14 – Großbritannien L 5 – Herausgabe L 82, 112 ff.; siehe auch Herausgabe bei Hinterlegung – Inhaberschaft L 63 f. – Insolvenz G 252 f. – Insolvenzfestigkeit B 90; L 39 ff., 58 ff. – Leistungsstörungen L 162 ff. – LG Frankfurt L 146 – LG-Mannheim L 134 f., 138 – Lizenzgeber L 29 – Lizenzvertrag L 30 – Mitwirkungspflichten L 162 ff. – Mustervereinbarung L 85 – Nebenpflichten L 141 – Nutzungsrechte L 60 – Pflege L 131 f. – Phasen L 80 ff. – prozessuale Verwertung L 158 ff. – Quellcode C 292; G 252 f. – Quellcodekommentierung L 59 – Regelungspunkte L 168 f. – Rückgabe L 96 – Software-Bewertung Q 246 – Softwareerstellung-/anpassung L 174 ff. – Treuhand L 74 ff. – Umfang L 13 – Update L 91

– Urheberrechte bei Software-Überlassung L 143 ff. – USA L 5 – Vergütung L 65 ff. – Verhältnis zum Beschaffungsvertrag L 168 ff. – Vertragsbeziehungen L 29 ff. – Vertragsgestaltung L 79 ff., 99 ff. – Vertragsgestaltung L 168 ff.; siehe auch dort – vertragsrechtliche Empfehlungen L 157 – Vertragsrisiken L 131 ff. – Vorlage an Gericht L 158 ff. – weiterreichende Pflichten L 133 f. Hinterlegungsstelle – Source Code F 67 ff. Hinterlegungsunternehmen – Geheimnisverrat A 311 – Herausgabe L 82 – Lagerung L 81 – Verifikation L 15 Hinterlegungsvereinbarung B 90 f. – Insolvenzfestigkeit F 68 f. Hinweis- und Beratungspflichten – Schadensersatz D 415 Höhenmessgerät O 174 Home forum rule F 48 Home-Office – Arbeitsleistung E 36 Honda-Entscheidung – BGH K 44 Horizont 2020 – Budgetverhandlungen M 79 – Rahmenprogramm Forschung und Entwicklung M 4, 10 Hotline – Begriff I 445 – Beratungsleistungen I 451 – Pflegelaufzeit I 296 – Sanktionen I 512 – Service-Level und Reporting I 505 ff. – Softwarepflegevertrag I 11, 456 – Support I 447 ff. – Verfügbarkeit des Service-Levels I 509 ff. – Zeiten I 456 ICC – Schiedsgerichtsbarkeit J 49 ff. Ideen – Schutzfähigkeit A 272 – Urheberrechtsschutz A 28 ff. IDW PS 850 – definierte Arbeitsergebnisse Q 205 – Dokumentation Q 205 – projektbegleitende Prüfung Q 205 – Risiken Q 205 – Software-Bewertung Q 203 ff. IDW PS 880 – Prüfung von Softwareprodukten Q 206

1529

Stichwortverzeichnis IDW Standards – Bewertung immaterieller Vermögenswerte Q 202 – Durchführung von Unternehmensbewertungen Q 201 – Software-Bewertung Q 199 ff. Immaterielle Schäden – Urheberrechtsverletzung A 196 Immaterielle Vermögenswerte – Software-Bewertung Q 202 Implementierung – Erweiterung des Versicherungsschutzes O 228 – fehlerhaft, Sicherung I 443 – Software I 434 – Standardsoftware G 27 ff. Implementierungsplanung – anhand ausgewählter Software C 183 ff. Indexklauseln siehe Preisklauseln Individualabrede – Verjährung B 59 ff. – Vorrang der ~ J 69 Individualität – Computerprogramme A 39 – Urheberrechtsschutz A 44 Individualsoftware – BVB-Pflege N 186 – Erstellung B 5 – Geheimnisverrat A 310 – Kündigung des Pflegevertrages, wirtschaftlich-kommerzielles Interesse I 333 – Kündigungsausschluss I 343 – Marktanteil G 40 – Nachführen I 422 – Nachteile der Standardsoftware G 59 – Quellcode-Herausgabe G 250 – Subunternehmer E 302 ff. – Vorteile der Standardsoftware G 56 – Werkvertragsrecht B 106 Individualvereinbarung – Ablehnungsandrohung G 362 – Anschein einer AGB-Klausel J 22 ff. – Ausgangspunkt J 1 ff. – Aushandeln G 417; J 33 ff. – Bestätigungsklauseln J 79 – Dokumentationsempfehlung J 78 – Einbeziehung einer AGB-Klausel J 26 ff. – Einzelfallprüfung J 70 – Haftungsbegrenzung J 1 ff. – Haftungsbeschränkung G 415 ff. – handschriftliche Ergänzungen J 77 – langwierige Vertragsverhandlungen J 44 ff. – Mängelbeseitigungsentgelt I 157 f. – Möglichkeit des Aushandelns J 80 – Nachweis J 77 – Pflegelaufzeit I 306 ff. – Reichweite der Aushandlungsvermutung J 72 – Risikoverlagerung J 3

1530

– sachliche Notwendigkeit einer Klausel J 62 – Sachzusammenhang J 70 – Service-Level-Agreements I 473 ff. – unveränderte Übernahme einer Klausel J 36 ff. – Verbot planmäßigen Abweichens J 65 f. – Verhandlungsprotokoll J 78 – Vertragsgestaltungsfreiheit J 14 Individuelle Erweiterungen – Standardsoftware G 298 ff. Informatiker – Freiberufler N 71 Informationsaustausch – Projektkommunikation H 90 ff. Informationspflichten D 224 f. Inhaberschaft – Hinterlegung L 63 f. Inhaltskontrolle – Allgemeine Geschäftsbedingungen E 10 – Auftragnehmer als Verwender J 19 ff. – Kostenelementeklauseln I 233 – Laufzeitklausel für Pflegeleistungen I 311 ff. – Obliegenheit , Systemumgebung I 386 – Preisanpassungsklauseln I 229 ff. – Preisklauselgesetz I 218 ff. – Preisvorbehaltsklauseln I 242 – Softwareerstellungsverträge J 33 ff. – Spannungsklauseln I 246 ff. – Verfügbarkeitsgarantie K 23 f. Inhaltsmanagement H 31 Inhouse-Geschäft – Carbotermo N 39 – echtes ~ N 37 – Parking Brixen N 39 – Stadt Halle N 39 – unechtes~ N 38 – Vergaberecht N 36 ff. Inlandsbeschäftigung – Nachweisgesetzanforderungen E 4 Inline-Dokumentation Q 79, 112 f. Innovationsunion – Europa 2020 M 4 – Horizont 2020 M 77 ff. Insolvenz – deutsches internationales ~recht F 59 ff. – Escrow Agent F 67 ff. – Hinterlegung L 39 ff. – Nutzungsrechte C 349 – Quellcode-Herausgabe G 249 – Source Code F 64 ff. – Treugeber L 74 ff. – Lizenzgeber L 33 Insolvenzfestigkeit B 90 – Absicherung des Urheberrechts L 145 – Abstraktionsprinzip L 46 ff. – allgemeine Geschäftsbedingungen L 50 f. – Bedingungseintritt L 150 – BGH-Rechtsprechung L 52 f., 149 ff.

Stichwortverzeichnis – Deckungsgleichheit des Vertragstyps L 41 f. – Einbeziehung des Escrow-Agenten L 56 f. – Endgültigkeit der Überlassung L 49 – Kündigung L 44 f., 150 – Lizenzvertrag L 52 f. – Nießbrauch beim Beschaffungsvertrag L 170 ff. – Patentlizenz L 55 – Rechtseinräumung L 42 ff. – Software-Escrow G 253 – Treuhandmodell L 63 – Vergütung L 47 – vertragliche Konstruktionen L 58 ff. – Vertragsklausel L 149 Insolvenzrisiko – Abwälzung auf Leasingnehmer R 35 – IT-Projektleasing R 9 Insolvenzverfahren – Herausgabe bei Hinterlegung L 114 ff. Insolvenzverwalter – Quellcode L 4 – Wahlrecht F 61 Installation – Beschreibung G 234 – Dokumentation G 246 – Nebenpflicht D 99 – Standardsoftware G 146 f. Installationsleistungen – Altdatenübernahme I 441 ff. – Begriff I 433 – Datensicherung I 441 ff. – Datensicherung, Beweislastumkehr I 443 – EVB-IT Pflege S I 437 – tätigkeitsorientiert oder erfolgsorientiert I 440 – vertragstypologische Einordnung I 468 Installationspaket – zum Download I 438 Instandhaltung – EVB-IT N 184 – Software I 35 Institutionelle Förderung – Bundesförderung M 15 – Landesförderung M 17 Integralfranchise O 39 Integrationsmanagement H 31 Integrationstest – Musterformulierung G 337 Interessenkonflikt – Marktbeteiligte I 66 International Function Point User Group Q 161 Internetauftritt – Mangel D 249 Internetportal – Vergabeveröffentlichung N 204 Internetprovidervertrag – BGH B 100

Internet-System-Vertrag – BGH B 100; G 99 ff. – Werkvertrag G 95 Interoperabilität A 111 f. Inverkehrbringen – ProdHM O 95 – Versicherungsschutz, BBR IT-Dienstleister O 225 – Verwertungsrechte A 87 Investitionen – staatliche Unterstützung siehe Forschungsförderung Investitionsquote – Deutschland M 2 ff. – Europa M 2 ff. – Forschungsförderung M 1 ff. ISO – Mangelbegriff G 377 ISO/IEC 15504 – Software-Bewertung Q 138 ISO/IEC 20000 – Software-Bewertung Q 144 ff. – Tests bei Qualitätssicherung Q 152 ISO9000:2000 – Qualitätssicherung G 255 ISO9100 – V-Modell C 322 Ist-Analyse C 297 ff. Italien – Durchsetzung des Softwareschutzes A 379 IT-Analyse – fehlerhaft, Versicherungsschutz O 229 IT-Compliance – Abnahme G 326 – Anforderungen an Software Q 23 ff. – Beurteilung der Produkteigenschaften Q 211 IT-Dienstleistungen – Beschaffung, Vertragsbedingungen des Bundes M 128 ff. Iterationsschritte C 206 ITIL – Software-Bewertung Q 141 ff. – Störungsbegriff I 405 – Tests bei Qualitätssicherung Q 152 IT-Leistungen – Abgrenzung VOL/A und VOF N 73 ff. – Auftragswert, Vergabeverfahren N 65 f. – Vergabeverfahren, Organisation des öffentlichen Auftraggebers N 125 ff. – Wahl der Vergabeart N 80 f. IT-Projekt – Erfolg H 1 ff. – Problemfelder H 7 – Projektmanagement H 1 ff. – strategisch/operative Planung H 37 – Systementwicklung H 37 IT-Projektleasing – Begriff R 2 ff. – Dritter R 5 ff.

1531

Stichwortverzeichnis – – – – – – – – – – – – – –

Einführung/Ablauf R 6 Eintrittsmodell R 6 Freizeichnung in AGB R 36 Gebrauchsüberlassungspflicht R 37 f. Generalunternehmervertrag R 10 Leistungsstörungen R 9 Mitwirkungspflichten R 8 Planungs-/Herstellungsphase R 7 rechtliche Einordnung R 12 ff. Regelfall R 15 ff. Risikoklassen R 10 Risikoverteilung in AGB R 54 ff. Rücktritt R 33 ff. steuerrechtliche Vorgaben zur Eigentümerstellung R 22 ff. – Vergütung R 39 f. – Vertrag R 1 – vertragliche Besonderheiten R 5 ff. – Zahlungsmodalitäten R 11; siehe auch Finanzierungsleasing IT-Service-Management – ISO/IEC 20000 Q 144 IT-Sicherheit – Berechtigungskonzept Q 39 – BSI-Lagebericht I 27 – gesetzliche Vorschriften Q 42 – Grundschutz-Katalog des BSI Q 43 – ISO/IEC 27001 Q 48 – Kriterienkatalog Q 47 – Qualitätssicherung Q 40 – regulatorische Vorschriften Q 42 – Schutzziele Q 36 – Software-Bewertung Q 36 ff. – standardisierte Sicherungskonzepte Q 44 ff. – Übergabe des Quellcodes L 3 Jahreshöchstleistung O 38 Jahrtausendwende – Herausgabe bei Hinterlegung L 126 Kalkulation – Irrtum bei Festpreisabrede G 311 f. – Kündigung D 436 – Preisanpassungsinteressen I 211 – Softwareerstellung B 69 Kanada – Auslandsschäden O 70 Kapitalisierung – Software-Bewertung Q 196 ff. – Zinssatz, Software-Bewertung Q 271 ff. Kardinalpflichten – Haftungsbegrenzung G 411 Karenzentschädigung – Auskunftsverpflichtung für künftige Bezüge E 152 – Geheimhaltungsverpflichtung E 128 – Wettbewerbsverbot E 151

1532

– Zahlungsklage E 155 Kartellrecht – Forschung und Entwicklung M 5 – Herausgabe des Quellcodes A 172 – Konsortium E 324 ff. – Softwarepflege-, Softwareüberlassungsvertrag I 143 – Softwarepflegevertrag I 67 Kaufrecht – Abnahme D 194 – BGH-Entscheidung vom 23.7.2009 G 87 ff. – Fälligkeitsregelungen D 182 – Implementierung von Standardsoftware G 71 ff. – Leistungsbeschreibung D 248 ff. – Lieferung und Anpassung von Standardsoftware D 81 ff. – Lieferung und Parametrisierung von Standardsoftware D 90 ff. – Mitwirkungspflichten des Auftraggebers G 213 – Montageverpflichtung B 125 – Rechtsfolgen von Mängeln G 391 ff. – reine Anpassungsleistungen G 109 – Software B 1 – Verjährung von Mängelansprüchen G 386 – Verjährung von Rechtsmängeln D 359 – Verweisungsnorm, § 651 BGB G 98 Kaufrechts-Richtlinie – Anwendung von § 651 BGB B 6 ff. – EU-rechtliche Auslegung B 24 ff. – Umsetzung B 14 ff. – UN-Kaufrecht B 27 f. – Verbrauchsgut B 25 ff. Kaution – Beweissicherung, Softwareschutz A 386 Kenntnis – Unlauterkeit A 281, 284, 290 Kenntnisklausel – Erweiterung zum Vorsatz O 48 – Wissensvertreter O 49 f. Kerntheorie – Patentschutz für Software A 225, 230 Kfz-, Schienen- und WasserfahrzeugteileAusschluss O 147 f. Kick-off – Projektmanagement H 70 Klageantrag A 377 ff. Kleinbetriebe – Arbeitnehmerüberlassung E 217 Kleine Münze – Urheberrechtsschutz A 38 Know-how – zustimmungsfreie Maßnahmen A 104 Kodierungsrichtlinien – Bewertungsdurchführung Q 213 Kombinationstheorie – gemischter Vertrag G 116

Stichwortverzeichnis Kombinationsvertrag – Anpassung, Einführung und Implementierung von Standardsoftware G 112 ff. Kommissionshaushalt – Forschungsförderung in Europa M 28 Kommunikation siehe auch Projektkommunikation – IT-Projekt H 37 – Management H 31 – Projektmanagement H 41 Kommunikationsprobleme – Mehreckskonstellationen E 295e Kommunikationssteuerung D 6 Kompatibilität – Eignung der Hardware C 191 Kompetenzgefälle C 72 f. Konfliktlösung – im Projekt H 117 ff. – Projekthandbuch H 99 – Projektmanagement H 117 ff. Kongruenz-Prinzip – AGB-Klausel J 30 Konkludente Abnahme D 207 ff. Konkludente Vereinbarung – Änderungswünsche D 165 Konkretisierungsversuch – Softwareerstellungsverträge J 37 ff. Konkurrenz – Software-Bewertung Q 235 ff. Konkurrenzverbot – Abgrenzung zu Vorbereitungshandlung E 145 – Arbeitsvertrag E 136 ff. – freier Mitarbeiter E 274 – Konsortium E 322 – Softwareentwickler E 274 – Teilzeit E 143 ff. Konsortial-Projektvertrag siehe auch Konsortium – Softwareerfindung E 101 Konsortialvertrag – DESCA M 108 ff. Konsortium – Abgrenzung zum Austauschvertrag E 312 – Anteilsübertragung E 372 – Ausprägung E 314 – Begriff E 312 – Bemessungsgrundlage, BGH E 362 – Berechnungsmodell für Vergütung E 361 – Bruchteilsgemeinschaft E 316 – Erfindervergütung E 357 – Ergebnisse E 347 ff. – EU-Forschungsförderung E 313 – FuE-Verträge E 323 ff. – gemeinsame Verwertung E 338 – Gemeinschaftsunternehmen E 320, 351 – Gesamthandsvermögen E 317 – Größenkriterien E 340 – Gruppenfreistellungsverordnung E 323 ff.

– – – – – – – –

Haftung E 368 f. Hamburger Vertrag E 365 kostenlose Lizenzen, Konsorten E 367 Legalausnahme E 332 ff. Marktanteil E 339 marktstarke FuE-Partner E 434 f. Musterverträge (Berliner Verträge) E 364 Musterverträge (Hamburger Vertrag) E 365 – neue Kartellverordnung E 333 – Nichtwettbewerber E 341 – Nutzungsrechte E 318 – Produkt zur Eigenverwertung E 360 – projektbezogen, endet E 370 ff. – übliche Sondervereinbarungen E 363 ff. – Verbot konkurrierender Entwicklung E 321 – verbundenes Werk E 350 – Vereinbarungen, nützliche E 330 – Vereinbarungen, wettbewerbsbeschränkende E 328 – Vergütungspflicht E 358 – vertikales Auftragsverhältnis E 315 – Vertragsverhältnis E 319 ff. – Verwertung E 349 – Verwertungsumsatz E 359 – Wettbewerber und Auftraggeber E 412 – Zweckerreichung E 312 – Zweckübertragungsgrundsatz E 356 KonTraG – deutsche Bestrebungen nach Überwachung I 23 Kontraktionswirkung O 181 Konzept siehe Grobkonzept; Feinkonzept Konzeptionelle Vorgaben A 26 Konzern – Softwareentwickler E 93 f. Konzernklausel – Ausschluss vom Versicherungsschutz O 176, 240 Konzernprivileg C 381, 401 Körperschäden D 322, 516 Kosten – Anforderungs-/Leistungsbeschreibung G 162 – Beweissicherung, Softwareschutz A 395 – einstweilige Verfügung A 388 – Open Source-Software A 331 – Pflichtenheft G 172 – Projektmanagement H 3 Kosten des Projekts siehe Projektkosten Kosten, versicherte siehe Versicherte Kosten Kostenbeteiligung – Nacherfüllungsanspruch D 288 Kosteneinsparung – Anpassung von Standardsoftware G 44 Kostenelementeklauseln I 216 – Beweislast I 235 – BGH I 232 f. – Preisanpassungsklauseln I 231

1533

Stichwortverzeichnis – Umfangsbegrenzung I 234 – unternehmerischer Verkehr I 236 f. – Verbraucherverkehr I 238 f. Kostenerstattung – bei ESA-Projekten M 124 Kostenmanagement H 31 Kostenschäden – Versicherungsschutz, ProdHM O 89 Kostentreiberfaktoren – COCOMO-Schätzverfahren Q 187 ff. – COCOMO-Verfahren Q 219 – Korrektur des Entwicklungsaufwands Q 171 ff. – Kürzung des Entwicklungsaufwands Q 171 – Personal-Merkmale Q 190 – Plattform-Merkmale Q 189 – Produkt-Merkmale Q 188 Kraftfahrzeuge – fehlerhafte Steuerungselektronik O 147 Krankenhaus – Softwarepflegevertrag, sensible Daten I 370 f. Krankheit – Kündigung E 192 Krankheitsdaten – Auftragsdatenverarbeitung C 409 Kriegswaffenkontrollgesetz F 75 Krisenmanagement – Projektmanagement H 94 Kündigung – ABG B 67 – Abdingbarkeit von § 649 BGB I 338 ff. – Abmahnung E 191 – Änderungskündigung E 195 – Änderungswünsche D 175 f. – Anwendbarkeit des § 649 BGB I 324 ff. – Anwendbarkeit des § 649 BGB, Skaleneffekte I 335 – Anwendbarkeit des Kündigungsschutzgesetzes E 182 – Arbeitsverhältnis E 178 ff. – Auflösungsklausel L 151 – Ausbleiben von Mitwirkungshandlungen D 234 – Ausschluss G 434 – Ausschluss durch AGB I 348 – außerordentlich E 195; G 426 ff. – bei Preisklausel als rechtlicher Vorteil I 254 ff. – betriebsbedingt E 185 ff. – Beweislast bei Zugang E 178 – Darlegungs- und Beweislast D 435 ff. – Definition E 178 – Dienstvertrag, Standardsoftware G 425 – durch Besteller D 434 – durch Drittauftraggeber bei Konsortium E 370 ff. – durch Unternehmer D 433 – End-of-life-Schreiben I 350 ff.; siehe auch dort

1534

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Entgeltzahlungsverzug E 169 erbrachte Teilleistungen D 444 ergänzende Vertragsauslegung I 337 Erklärung, Gründe E 184 feste Vertragslaufzeit I 341 freier Mitarbeiter E 291 Fristen E 179 Grenzen E 180 ff. Implementierung von Standardsoftware G 79 Insolvenzfestigkeit L 44 f., 150 Interessenabwägung E 191 Internetpräsenzvertrag/Einordnung B 65 ff. Klagefrist E 193 Krankheit E 192 Musterformulierung im Vertrag G 433 ff. Personal, Verzug D 394 f. personenbedingt E 192 Programmsperre D 445 f. Recht auf außerordentliche I 346 ff. Recht des Anwenders bei Pflegevertrag I 322 ff. Restentschädigung G 422 Rücknahme E 178 Schlechtleistung E 165 Schriftform G 434 Softwareanbieter G 421 Softwarepflege-, Softwareüberlassungsvertrag I 124 ff. Softwarepflege-, Softwareüberlassungsvertrag, wichtiger Grund I 134 ff. Softwarepflegevertrag I 53 ff. Sonderkündigungsrechte G 431 f. soziale Rechtfertigung E 181 soziale Rechtfertigung, betriebsbedingte ~ E 188 unangemessene Vergütung A 186 Unkündbarkeit, Hinterlegung L 127 Unterschiede E 179 unzumutbare Fortsetzung E 194 Vergütungsklausel, Muster D 519 verhaltensbedingt E 191 verhaltensbedingt bei Wettbewerbsverstoß E 142 Verhältnismäßigkeitsgrundsatz E 183 Verletzung der Geheimhaltungspflicht D 424 Verletzung von Betriebsgeheimnissen D 447 vertraglich vereinbart über Softwarepflege I 320 ff. Vertragsgestaltung D 449 ff. Vertragsklauseln D 451 ff. Vertragsklauseln zur Vergütung D 442 Verwendung der Arbeitskraft D 434 ff. Wegfall der Gründe E 184 Werkvertrag, Standardsoftware G 421 ff. wichtiger Grund I 349; E 196 Zugang E 184

Stichwortverzeichnis Kündigungsausschluss – formularmäßig formuliert I 339 ff. – Individualsoftware I 343 – Standardsoftware I 344 f. Kündigungsfrist – freier Mitarbeiter E 291 Kündigungsschutzgesetz E 180 ff. Kündigungsschutzklage – außerordentliche Kündigung E 196 Kündigungsverzichtsklausel – Vergabeverfahren, EuGH N 44 Kündigungszeitpunkt – Softwarepflege-, Softwareüberlassungsvertrag I 125 Kumulationsprinzip – gewerblicher Rechtsschutz A 257 Kundendaten – Geheimhaltung im Verhandlungsstadium G 10 ff. Kundenschäden – Gesamtschuldnerhaftung E 165 Kundenschutzabreden – Wettbewerbsverbot E 157a Lagerhaltungsschäden O 275 Lagerung – Hinterlegung L 81 Lagerverwaltung D 269 Lagerverwaltungssystem – Mangel G 373 – Musterformulierung zum Verwendungszweck G 379 Länderembargos F 85 Last Call-Verfahren – Angebote zur endgültigen Wertung N 246 Lastenheft siehe auch Pflichtenheft – Anforderungen G 153 – Definition in VDI 2519 C 83 – Projektmanagement H 69 Laufzeit – Vergaberecht, Rahmenvereinbarung N 51 Laufzeitklausel siehe Pflegelaufzeit Laufzeitverhalten – Software-Bewertung Q 52 ff. Leasing – Erschöpfungsgrundsatz A 90 – wirtschaftliches Eigentum aus steuerrechtlicher Sicht R 22 ff. Leasinggeber – Beschaffungsrisiko R 32, 2 Leasinggut – beim Leasingnehmer R 37 – Störung durch Lieferanten R 38 Leasingnehmer – als Eigentümer R 19 ff. – Anwender R 2 Leasingobjekt R 5 – Nutzungsüberlassung R 31

Leasingraten R 11 – Zahlung R 49 ff. Leasingvertrag – IT-Projektleasing R 1 ff. – Rücktritt R 33 Lebensdauer – Software-Bewertung Q 253 ff. – Wartbarkeit Q 254 Legislativpaket – EU-Vergaberichtlinien N 7 Leiharbeitnehmer – Schadensersatz E 223 Leistung, mangelhaft D 245 ff. Leistungen – Implementierung von Standardsoftware G 130 ff. – zusätzliche G 275 Leistungen des Softwareanbieters siehe Anbieterleistungen Leistungsbeschreibung – Abgrenzung zur Garantie G 165 ff. – Analyse/Konzeption G 138 – Anforderungen G 152 f.; N 144 – Anlage Nachrang zum Vertrag C 350 – Arten von ~en N 145 ff. – Ausgestaltung eines Mangels G 374 ff. – Bedeutung für die Vertragsgestaltung G 155 ff. – Begriff G 130 – Erstellung N 150 f. – externe Berater N 151 – fehlendes/unzureichendes Pflichtenheft G 175 ff. – fehlerhafte ~ N 153 f. – funktionale N 148 – grafische Modelle G 196 – Hinweispflicht D 4 ff., 11 – konstruktive N 147 – konventionelle N 146 – Kriterien für die Beschreibung G 195 f. – lösungsneutral G 195 – Lücken G 381 – Merkmale G 189 ff. – Musterformulierung G 131 – Nachbesserungsrecht N 154 – produkt- und lösungsneutral N 142 – Proof of Solution N 152 – Standardsoftware C 97 f. – Tabellenkalkulationsprogramm N 151 – testbar G 195 – Testinformationen G 332 – Transparenzgebot C 94 ff. – Verantwortlichkeit des Anwenders G 170 ff. – Vergaberecht, Rahmenvereinbarung N 49 – Vergabeunterlagen N 139 ff. – Verhaltensanweisungen, Vergabeverfahren N 144 – vollständig G 195 – Werk- oder Dienstvertrag D 57

1535

Stichwortverzeichnis – Ziele G 172 Leistungserbringung – ordnungsgemäße B 76 – Softwarepflegevertrag I 389 ff. Leistungskatalog – Implementierung von Standardsoftware G 110 Leistungspflichten – Arbeitnehmer E 11 ff. – Subunternehmer E 295g Leistungsportfolio – Implementierung von Standardsoftware G 32 Leistungsqualität – Service-Level-Agreements I 477 ff. Leistungsrisiko – Versicherungsschutz, BBR IT-Dienstleister O 225 ff. Leistungsschutz – Anbieten A 266 – Datenbank A 46 ff. – Dienstleistung A 271 – gesetzliche Regelungen A 250 ff. – Herstellen A 267 – konkrete Gestaltung A 272 – Leistungsergebnis A 271 – Leistungsübernahme A 248 – Mitbewerberbezug A 265, 270 – Nachahmung A 276 ff. – nachschaffende Übernahme A 248 – Praxisrelevanz A 259 – Schutzdauer A 258, 291 – technische Schutzmechanismen A 269 – unlautere Nachahmung A 248 ff. – Unlauterkeit begründende Umstände A 283 ff. – Verhältnis zu anderen Fallgruppen A 254 – Verhältnis zum Sonderrechtsschutz A 255 f. – Voraussetzungen A 263 ff. – Ware A 271 – Wechselwirkung A 264 – wettbewerbliche Eigenart A 273 – Wettbewerbsrecht A 247 ff. Leistungsschwerpunkt – Vertragsgegenstand B 11 Leistungsstörungen siehe auch Pflichtverletzung – Begriff G 345 ff. – dienstvertragliche Einordnung C 340 ff. – fehlende Abnahme D 431 – Freigabe C 367 ff. – Garantie G 168 – Geheimhaltungspflichten D 418 ff. – gemischter Vertrag G 344 – Generalunternehmer E 308 – Haftungsbeschränkung G 407 ff. – Hinterlegung L 162 ff. – Konsortium E 368 f.

1536

– Kündigung D 433 ff. – mangelhafte Leistung D 245 ff. – nachträglicher Einbau der Programmsperre D 426 f. – Nebenpflichtverletzung D 414 – Nichterfüllung D 380 ff. – Obliegenheiten des Bestellers D 428 ff. – Pflichtverletzungen des Lieferanten D 414 ff. – Planungsphase C 332 ff. – Rücktritt D 432 – Schadensersatz G 348 ff. – Schuldrechtsmodernisierung G 345 ff. – sonstige Leistungsstörungen D 380 ff. – Standardsoftware G 342 ff. – Subunternehmer E 295g – Unmöglichkeit D 380 ff. – verspätete Herstellung D 405 – vertragliche Regelungen G 343 – Verschulden G 347 – Vertragsstrafen D 409 ff. – Verzug D 388 ff.; G 355 ff. – werkvertragliche Einordnung C 337 ff. Leistungsübernahme – fast identische A 279 – nachschaffende A 280 – Unlauterkeit begründende Umstände A 283 ff. – unmittelbare A 277 f. Leistungsumfang – Änderung G 260 ff.; siehe auch Change Request Leistungsverweigerung – Nacherfüllungsanspruch D 289, 367 f. – Unmöglichkeit D 387 Leistungsvorbehaltsklauseln I 216 Leitungsbeschreibung – Beschreibung der Dokumentation G 241 ff. Letter of Intent siehe Absichtserklärung Libraries – Due Diligence Q 83 ff. Lieferant – Erkundigungspflicht D 9 – Vertragsgestaltung bei Standardsoftware G 66 ff. Lieferanteninsolvenzrisiko – Risikoverteilung in AGB R 60 Lieferkette – Versicherungsausschluss O 62 Lieferumfang – Online-Hilfefunktion I 428 Lieferverzug – Schadensersatzanspruch K 50 Link-Bibliothek D 138 Linux-Klausel A 187 Liquidationsverfahren – Herausgabe bei Hinterlegung L 122 Liquidationswert – Bewertungsdurchführung Q 208

Stichwortverzeichnis – Software-Bewertung Q 18 f. – Wartung Q 250 – Wertuntergrenze Q 249 Lissabon-Strategie M 4 Lizenz – Bewertungsdurchführung Q 208 – Dauernutzungsvertrag L 156 – Doppelbesteuerungsabkommen P 33 – Erlöschen L 141 – gesetzliche A 132 – Gestaltungsfälle, Steuerrecht P 40 ff. – Gewerbesteuerrecht P 32 – Haftungsbegrenzung G 413 – kostenlose Lizenzen, Konsorten E 367 – Nießbrauch L 170 ff. – Open Source-Komponenten G 44 – Software-Bewertung Q 239 ff. – Umsätze, Software-Bewertung Q 258 ff. – Umsatzsteuerrecht P 30 f. – Vermögensgegenstände, immaterielle P5 – Weitergabe bei Open Source-Software A 342 Lizenzbedingungen – ohne Copyleft-Effekt A 354 ff. Lizenzgeber – Begriff, Hinterlegung L 29 Lizenzierungsmodell – internationaler Bezug F 6 Lizenzkosten – Open Source-Software A 333 Lizenznehmer – steuerliche Behandlung P 26 – Vergütung des Urhebers A 188 ff. – zustimmungsfreie Maßnahmen A 97 ff. Lizenzvergabe – Versicherungsausschluss O 243 Lizenzvertrag – BGH B 40 – Herausgabe bei Hinterlegung L 112 f. – Insolvenzfestigkeit L 52 f. Lizenzvertrag, grenzüberschreitender – Änderung der Besteuerungsgrundlagen P2 Lohnbuchhaltung – Mangel G 159 Lohnzahlungspflicht – Arbeitgeber E 16 Losaufteilung – Auftragswert, Vergabeverfahren N 62 – Vergabeverfahren N 24 ff. Löschung von Daten – Auftragsdatenverarbeitung C 427 – Versicherungsschutz O 81 ff. Luftfahrtprodukte – Versicherungsausschluss O 222 f. Luftprodukthaftpflicht O 174 Luftüberwachungssystem – Versicherungsausschluss O 223

Machbarkeitsstudien – Angebotsphase G 1 – Konzeptvorbereitung C 302 ff. – Systemumstellungen C 303 – Zeitpläne C 303 Mahnung D 388, 400 f.; G 359 f. Maintenance – Softwarepflegevertrag I 37 Management siehe Projektmanagement Mangel siehe auch Sachmangel; Rechtsmangel – Abgrenzung Unmöglichkeit/Sachmängelrecht D 386 – agile Methodik C 152 ff. – Aliudlieferung D 275 – Antwortzeiten D 255 f., 262 – Arbeitsunfähigkeitsbescheinigung G 159 – Ausdruck bei Rechnungsprogramm D 267 – Ausdruckzeiten für Listen D 262 – Ausfälle D 263 – Bedienungscomfort D 266 – Begriff G 367 – Begriffsbeschränkung G 380 – Beispiele D 260 ff. – Beseitigung/Neulieferung G 392 – Besonderheiten bei Rechtsmangel G 395 ff. – Dateninkonsistenzen D 261 – Definition D 246 – DIN/CEN/ISO G 377 – Dokumentation G 240 – Einsortierung von Umlauten D 274 – Einteilung nach Auswirkung D 260 ff. – Ermittlung/Beurteilung nach Pflichtenheft C 19 – Fehlbedienungen D 261 – Fehlermeldungen D 265 – Finanzbuchhaltungsprogramm D 268 – funktionaler K 5 – Funktionalität D 255 f. – Funktionsmangel C 71 – Gefahr der Disfunktionalität D 270 – gesetzliche Vorgaben D 252 – gewöhnliche Verwendung G 371 – gleichgestellte Probleme D 275 f. – Grad der Erkennbarkeit C 243 – Internetauftritt D 249 – Kaufrecht D 248 – Leistungsbeschreibung D 248 ff. – Lohnbuchhaltung G 159 – Muster, Verjährungsklausel D 500 f. – Musterformulierung zum Verwendungszweck G 379 – Nacherfüllung G 391a f. – Nutzungsbeschränkung D 271 – Pflichtenheft C 62 – Quellcode D 265

1537

Stichwortverzeichnis – rechtlicher/technischer Mangelbegriff D 257 ff. – Rechtsfolgen G 391 ff.; siehe auch Rechtsfolgen von Mängeln – Rechtsmängel D 276 – Risiken bei fehlendem Pflichtenheft C 265 ff. – Rücktritt G 393 – Schadensersatz statt der Leistung G 394 – Selbstvornahme G 398 – Sicherungsläufe D 262 – Softwareentwickler E 279 f. – Sollbeschaffenheit D 247, 250 – sonstige Schlechtleistung G 406 f. – Speicherplatzmangel D 265 – Störungsbeseitigung I 404 – Subunternehmer E 295g – Textverarbeitung D 265 – typische Softwaremängel G 373 – Überlaufen von Dateien D 261 – Überweisungsformulare G 159 – unterschiedliche Hersteller D 287 – verborgener Mangel G 389 – vereinbarte Anforderungen D 255 – Verjährung G 385 ff. – Verjährungsfrist G 322 – vertraglich vereinbarte Beschaffenheit G 368 – vertragliche Ausgestaltung G 374 ff. – Vertragsklauseln D 505 ff. – Verweisung aufs Kaufrecht, § 651 BGB siehe Anwendung von Kaufrecht – Verwendungszweck G 369 – Virenbefall D 264 – Wartbarkeit D 255 – Zeiterfassung D 269 – zeitliche Definition I 397 – zukünftige Nutzungsprobleme D 272 – Zuweniglieferung D 275 Mängelansprüche – Implementierung von Standardsoftware G 79 – Verjährung G 79 Mangelanzeige – Inhalt D 283 f.; G 383 – Musterformulierung im Vertrag G 384 – Untersuchungs- und Rügepflicht G 382 Mängelbeseitigung I 41 – Abnahme G 321 – Anbieterinteressen I 201 f. – Anwenderinteressen I 200 ff. – Drittbezug I 167 – formularmäßige Verpflichtung I 172 – Kosten I 9 – mehrere I 43 – nach Ablauf der Haftungsfrist I 197 – Programmkorrekturen I 395 ff. – Softwarepflegevertrag I 8 – unangemessene Benachteiligung I 168 ff. – unentgeltlich, steuerliche Haftung I 199

1538

– Vergütung I 196 – vertragstypologische Einordnung I 469 – zwingend geschuldet I 166 Mängelbeseitigungsentgelt – als Schaden I 160 f. – aufwandsabhängig I 189 – Beweislast I 180 ff. – Pflegepauschale I 177 ff. – unangemessene Benachteiligung I 180 ff. – Ungleichbehandlung I 180 ff. – Verstoß gegen § 309 Nr. 2 BGB I 193 ff. Mangelfolgeschaden C 352 Mangelhafte Leistung – Schlechtleistung G 406 f. – Standardsoftware G 364 ff. Mängelhaftung – Abwälzung des Beweislastrisikos auf Softwareanwender I 183 ff. – AGB I 155 ff. – Drittbezug I 151 ff. – Entgeltproblematik I 150 ff. – EVB-IT System N 193 – Frist I 56 – individuelle Abrede im Softwarepflegevertrag I 154 ff. – Kalkulation in Softwareüberlassungsentgelt I 175 ff. – Programmkorrekturen I 277 – Sphärenhaftung I 190 f. – Verjährungsfrist I 163 ff. – Vertragsbestandteil B 127 – Werkvertrag, beispielhaft I 529 ff. Mängelrechte – Vertragseinordnung B 72 ff. Mangelüberbrückung – Umgehung I 40 Manifest – agile Methodik C 124 Markenzeichen – Schieds-Urteil J 52 Marktanalyse – Vergabeverfahren, öffentlicher Auftraggeber N 131 ff. Marktbeherrschung – Marktdefinition I 65 – missbräuchliches Ausnutzen I 141 ff. – Quellcode I 65 Marktdefinition I 65 Marktstudien – Konzeptvorbereitung C 302 ff. Marktwert – Bewertungsdurchführung Q 208 – Software-Bewertung Q 12 ff. Maschinencode – Urheberechtsschutz A 10 Maschinenklausel – Anwendbarkeit auf Software O 152 – Beschädigung anderer Produkte O 153 – mittelbare Schäden O 160 f. – Nachbesserungskosten O 155

Stichwortverzeichnis – nutzlose Herstellungskosten O 154 – Produktionsausfall O 158 f. – versicherte Schäden und Kosten O 153 – Versicherungsschutz O 150 – weitere Vermögensnachteile O 157 Mautsysteme – wettbewerblicher Dialog N 107 Mc Kinsey – Black Swan C 8 ff. Mediation – Projektmanagement H 117 – Schiedsgerichtsbarkeit F 56 ff. Mehraufwand – Bewertungsgrundlage G 288 – Kalkulation G 288 – Nachweis G 277 ff. – ungeeignete Ausführungsart G 290 – Vergütung G 274 ff. Mehreckskonstellationen E 295e Mehrsprachigkeit – Software-Bewertung Q 64 Meilenstein – Fristen- und Aktivitätenplan G 199 – Projektmanagement H 78 – Projektplanung H 100 – unzureichende Mitwirkung G 230 – vereinbarte Termine G 201 ff. – Verzug G 357 f. Metriken – Qualitätssicherung Q 150 Microsoft – Sicherungskonzept Q 44 ff. Mietrecht – Software B 1 – Finanzierungsleasing R 13 – Vertrag zur Implementierung von Standardsoftware G 72 Migration – Implementierung von Standardsoftware G 144 f. – Musterformulierung G 144 – rechtliche Einordnung D 101 f. – Projektmanagement H 71 Minderung – Abnahme D 281 – Gestaltungsrecht D 308 f. – Reparaturkosten D 308 – Vergütung D 308 – Verjährung D 341, 369 – Werkvertrag D 296, 308 ff. Mindestabnahmepflicht – Vergaberecht, Rahmenvereinbarung N 48 Mindestangaben – Arbeitsvertrag E 4 Mindestauftragswert – nationales oder EU-Vergaberecht N 56 Mindestbefugnisse, § 69d UrhG A 97 Minimum-Contracts-Lehre F 47

Missbräuchlichkeit – Softwarepflege-, Softwareüberlassungsvertrag I 144 Mitarbeiter siehe Personal Mitarbeiterbeteiligungen – Vergütungsbestandteil E 17 Mitarbeiterdaten – Auftragsdatenverarbeitung C 409 Mitbewerber – Behinderung A 253 f. – Wettbewerbshandlung A 265 ff. Miterfinder – Konsortium E 353 ff. Mittelstandsförderung – andere Maßnahmen N 27 – Losaufteilung, Vergabeverfahren N 25 Miturheberschaft – Anteilsverzicht A 65 f. – BGH E 348 – einheitliches Werk A 58 – Einwilligungserfordernis A 62 ff. – Entwicklungsteams A 56 – Ertragsverteilung A 64 – Gehilfen A 57 – Gesamthandsgemeinschaft A 60 f. – Identifizierung der Beiträge A 59 – Projektteams A 54 – Verwertungsrechte A 80 – Voraussetzungen A 55 ff. – Weiterentwicklung A 55 Mitverschulden – Datensicherung D 323 – Musterformulierung im Vertrag G 416 – Open Source-Software A 371 Mitwirkung des Anwenders – Musterformulierung G 230 – Vertrag