Source: http://docplayer.org/2763789-Softwarefehler-wer-haftet-fuer-was.html
Timestamp: 2017-09-24 12:23:24
Document Index: 89676110

Matched Legal Cases: ['Art. 191', 'Art. 258', 'Art. 368', 'Art. 4', 'Art. 4', 'Art. 3', 'Art. 3', 'BGE', 'Art. 3', 'Art. 4', 'Art. 1', 'Art. 2', 'Art. 1', 'Art. 1', 'Art. 6', 'Art. 42', 'Art. 5', 'Art. 2', 'Art. 8', 'Art. 41', 'Art. 55', 'Art. 41', 'BGE', 'BGE', 'Art. 55']

Softwarefehler Wer haftet für was? - PDF
Softwarefehler Wer haftet für was?
Download "Softwarefehler Wer haftet für was?"
1 Softwarefehler Wer haftet für was? R OGER S TAUB * Inhaltsverzeichnis Softwarefehler Wer haftet für was? Ausgangslage / Problemstellung Softwarefehler und rechtlich relevanter Mangel Vorbemerkung Beispiele für Softwarefehler Fehlerkategorien Beispiele aus der Praxis Rechtlich relevante Mängel Der Mangelbegriff im Vertragsrecht Der Mangelbegriff im Produktehaftpflichtrecht Kein Mangelbegriff im Deliktsrecht Haftung aus Produktehaftpflicht Haftungsvoraussetzungen: Überblick Wann ist Software ein fehlerhaftes Produkt? Wer haftet? Wofür wird gehaftet? Ausnahmen von der Haftung Fazit Haftung aus Delikt Allgemeine Haftungsvoraussetzungen Zur Widerrechtlichkeit Zum Verschulden Wer haftet? Wofür wird gehaftet? Fazit Haftung aus Vertrag Allgemeine Voraussetzungen eines vertraglichen Ersatzanspruches Rechtsnatur des Softwarevertrages Bedeutung der Rechtsnatur Unterscheidung unmittelbarer Schaden /mittelbarer Schaden Spezialfragen zum Verschulden Ausnahmen von der Ersatzpflicht Vertragliche Haftungsbeschränkung * Der Autor dankt RA MARCEL BIRCHER für wertvolle Hinweise und für die Zusammenstellung von Literatur und Materialien sowie Dr.DIRK SPACEK für die kritische Durchsicht des Manuskripts. 321
2 R OGER S TAUB 5.8 Vertragliche Haftung für Handlungen / Unterlassungen Dritter Fazit Weitere Haftungsgrundlagen Grundlagen für einen Rückgriff Haftung von Gesellschaftsorganen Schlussbetrachtung Literaturverzeichnis Ausgangslage / Problemstellung Bauprojekte und IT-Projekte haben eines gemeinsam: sie sind nie fehlerfrei. Aus den Fehlern können Schäden entstehen, und es stellt sich dann die Frage, wer den Schaden letztlich zu tragen hat. Ist Software fehlerhaft, so besteht eine erhebliche Bandbreite von potentiell Geschädigten wie auch von potentiell Haftenden. Zwischen diesen Personen können mannigfaltige rechtliche Beziehungen be- oder entstehen, die als Grundlage für eine Überwälzung der Haftung dienen können und im Einzelfall zu prüfen sind. Vereinfacht lässt sich diese Situation grafisch wie folgt darstellen: 322
3 Softwarefehler Wer haftet für was? 323
4 R OGER S TAUB Am einen Ende dieses Spektrums steht der Entwickler der Software. Das ist eigentlich immer eine natürliche Person, die entweder was die Ausnahme sein dürfte das Produkt direkt an den Endkunden verkauft oder aber die Software als Arbeitnehmer oder Freelancer im Dienste einer Softwarefirma entwickelt hat. Diese Softwarefirma wiederum wird von ihren Organen geleitet. Am anderen Ende des Spektrums steht der oder die direkt Geschädigte. Das kann sowohl eine natürliche wie auch eine juristische Person sein, und sie kann die Software oder das die Software enthaltende Produkt entweder privat oder zu geschäftlichen Zwecken nutzen. Der entstandene Schaden kann entweder in einem Körperschaden, einem Sachschaden oder einem Vermögensschaden bestehen. Zwischen diesen beiden Endpunkten der Haftungskette sind oft verschiedene weitere Personen zwischengeschaltet. Die bereits erwähnte Softwarefirma kann ihr Softwareprodukt z.b. über einen Zwischenhändler an Lizenznehmer vertreiben, oder es kann z.b. sein, dass jemand die Software in ein Produkt (z.b. in Hardware oder sonst in einen automatisch gesteuerten Gegenstand) einbaut. Es kann aber auch sein, dass jemand verschiedene Softwareprodukte von (in der Regel verschiedenen) Dritten zu einem IT-System zusammenbaut (Assembler). Diese zwischengeschalteten Personen veräussern sodann die Software oder die Produkte mit der inkorporierten Software weiter an Erwerber oder Lizenznehmer, welche unter Umständen ihrerseits wiederum Kunden haben, die letztlich dann den direkten Schaden erleiden. Die zwischengeschalteten Unternehmen sind in der Regel nicht direkt geschädigt. Sie können finanzielle Einbussen jedoch dadurch erleiden, dass ihnen wegen der Fehlerhaftigkeit von Software oder von Produkten mit integrierter Software Einnahmen entgehen oder weil direkt Geschädigte direkt oder indirekt auf sie Rückgriff nehmen. Diese Konstellation führt zu einer grossen Vielzahl von unmittelbaren und mittelbaren Haftungskonstellationen auf unterschiedlichen rechtlichen Grundlagen. Aufgrund der grossen Anzahl potentiell Betroffener stellt sich die Frage, wie das Risiko letztlich aufzuteilen ist. In rechtlicher Hinsicht ist dabei daran zu erinnern, dass das schweizerische Haftpflichtrecht nach wie vor auf dem alten Grundsatz " casum sentit dominus" beruht 1. Das bedeutet konkret, dass der direkt Geschädigte den Schaden grundsätzlich selbst zu tragen hat, es sei denn, er kann ihn unter einem besonderen Titel auf einen Dritten abwälzen. Die Möglichkeit der Abwälzung kann sich 1 R EY, Rz. 18 ff.; H ONSELL, 9 ff. 324
5 Softwarefehler Wer haftet für was? primär aus den Bestimmungen über die Produktehaftpflicht, das Deliktsrecht oder das Vertragsrecht ergeben. Ein undifferenziertes Abstellen auf den Grundsatz " casum sentit dominus" würde allerdings in unbilliger Weise den Umstand vernachlässigen, dass der tatsächlich Geschädigte in aller Regel eher zufällig zum Schaden kommt. Unter ökonomischen Gesichtspunkten ist zudem zu berücksichtigen, dass für die Kosten grundsätzlich derjenige aufkommen sollte, der sie tatsächlich auch minimieren kann bzw. der tatsächlich in der Lage ist, Massnahmen zur Verhinderung eines Schadens zu treffen. Dies wird in der Regel die Softwarefirma sein 2. Vor diesem Hintergrund wird nachfolgend geprüft, zu welchen Lösungen das geltende Recht kommt. In einem ersten Schritt wird dabei einleitend der Begriff des Softwarefehlers (d.h. des den Schaden auslösenden Ereignisses) dem rechtlichen Mangelbegriff gegenübergestellt (nachfolgend Ziff. 2). Daran anschliessend wird für die einzelnen Haftungsgrundlagen Produktehaftpflicht (Ziff. 3), Deliktsrecht (Ziff. 4), Vertragsrecht (Ziff. 5) und weitere Grundlagen (Ziff. 6) geprüft, wer gegenüber wem welche Ansprüche unter welchen Voraussetzungen direkt oder indirekt geltend machen kann. In einer Schlussbetrachtung (Ziff. 7) wird sodann das Fazit gezogen, ob die oben beschriebene ökonomisch anzustrebende Risikoaufteilung vom Recht tatsächlich verwirklicht wird. 2. Softwarefehler und rechtlich relevanter Mangel 2.1 Vorbemerkung Die Erkenntnis, dass nicht jeder Softwarefehler im technischen Sinne gleichzeitig auch ein rechtlich relevanter Mangel sein muss, ist nahezu ebenso alt wie die juristische Auseinandersetzung mit Problemen des Softwarerechts. Der Softwaretechniker versteht unter einem Softwarefehler jede Abweichung der Software von den technischen Zielvorgaben 3. Da ab einer gewissen Komplexität jegliche Software solche Abweichungen 2 Zum Ganzen vgl. K ILIAN, 192; M ORSCHER, 66; W IDMER, Bzw. detaillierter (auf BONS zurückgehend, zitiert bei MARLY, Rz. 837): "jegliche Abweichung in Inhalt, Aufbau und Verhalten eines Objekts zwischen ermittelten, beobachteten oder gemessenen Daten einerseits und den entsprechenden, in den Zielvorgaben spezifizierten oder theoretisch gültigen Daten andererseits"; vgl. auch REDEKER, 702; für das schweizerische Recht: F RÖHLICH-BLEULER, Rz
6 R OGER S TAUB aufweist ("Software ist nie fehlerfrei"), ist klar, dass nicht jeder Fehler ein rechtlich relevanter Mangel sein kann. Rechtsdogmatisch hat es hierfür verschiedene Begründungsversuche gegeben. So wird z.b. die Ansicht vertreten, dass der römisch-rechtliche Grundsatz " minima non curat praetor " eine entsprechende Abgrenzung ermögliche 4. Nach der hier vertretenen Ansicht ist dieser Ansatz nicht zielführend, da er auf die Höhe des eingeklagten (bzw. eingetretenen) Schadens abstellt. Diese Höhe hängt aber nur bedingt von der Fehlerqualität, sondern vielmehr auch von diversen anderen Faktoren ab. Ein kleiner Fehler in der Software kann zu immensen Schäden führen, während umgekehrt ein schwerer Fehler im Einzelfall folgenlos bleiben kann. Die richtige Antwort dürfte daher vielmehr in den Anspruchsvoraussetzungen des jeweiligen Rechtsinstituts liegen Beispiele für Softwarefehler Fehlerkategorien Software kann in verschiedenster Hinsicht fehlerhaft sein. In der Literatur werden Kategorien typischer Fehler gebildet, die allerdings für die vorliegend interessierenden Rechtsfragen kaum von Bedeutung sind. Folgende Untergruppen können hier genannt werden 6 : (a)funktionsmängel / Funktionsdefizite: Bei dieser Art von Fehler besteht eine Diskrepanz zwischen dem erwarteten und dem tatsächlichen Ergebnis einer Programmabarbeitung. Ist die Funktion zwar vorhanden, wird sie aber fehlerhaft ausgeführt, liegt ein Funktionsmangel vor. Beispiel wäre etwa eine falsche Berechnung wegen der fehlerhaften programmtechnischen Aufbereitung einer Formel. Bei Funktionsdefiziten ist die vereinbarte oder notwendige Funktion gar nicht vorhanden. Ein 4 Für das schweizerische Recht z.b. M ORSCHER, Vgl. im Einzelnen dazu sogleich unten Ziff. 2.3; die praktische Bedeutung dieser Frage darf ohnehin nicht überschätzt werden: für das deutsche Recht vgl. z.b. R EDEKER, Die hier vorgenommene Unterteilung folgt derjenigen von MARLY, Rz Andere Kategorien sind freilich genauso sinnvoll; vgl. z.b. FRÖHLICH-BLEULER, Rz ; WIDMER, 107 f.; HEUSSEN, 7 f.; HOEREN, 202 ff.; eine äusserst hilfreiche Zusammenstellung der Kasuistik (alphabetisch geordnet nach Schlagworten) findet sich bei S CHNEIDER, Rz
7 Softwarefehler Wer haftet für was? Bespiel hierfür wäre die fehlende Möglichkeit, einmal eingegebene Daten zu ändern 7. (b)inkompatibilität: Hier geht es um die Frage, ob eine Software mit ihren Vorversionen oder mit anderen Softwareprodukten kompatibel ist. Kompatibilität bedeutet dabei die Eigenschaft, ohne Anpassungs- oder Änderungsarbeiten kombinierbar zu sein. So darf z.b. je nach Einsatzbereich heute wohl davon ausgegangen werden, dass eine Software, die nicht mit Microsoft-Produkten kompatibel ist, fehlerhaft ist. Auch wenn eine Software Daten ihrer Vorversion nicht bearbeiten kann, ist sie fehlerhaft. In der Regel bedarf es aber einer vertraglichen Abmachung, dass Produkte kompatibel sind 8. (c)kapazitätsmängel / geringe Rechengeschwindigkeit: Beide Fehlerarten verlieren tendenziell an Bedeutung. Ein Kapazitätsmangel kann sowohl dann gegeben sein, wenn der benötigte Speicher im Vergleich zum vorgesehenen zu gross ist, als auch, wenn der neben der Software verbleibende Restspeicher für eine sinnvolle Nutzung zu klein ist. Eine (zu) geringe Rechengeschwindigkeit kann zu einer zu langsamen Arbeitsweise des Gesamtsystems führen. Aus der deutschen Gerichtspraxis kann hier z.b. auf Fälle verwiesen werden, in denen eine Antwortzeit von 31 Sekunden oder eine Reaktionszeit von mehr als zwei Sekunden bis zur Bildschirmanzeige einer Dateneingabe als (rechtlich) mangelhaft gewertet wurden 9. (d)viren: Computerprogramme, welche die Fähigkeit der Reproduktion und der Infektion haben und zudem eine vordefinierte Funktion ausführen, werden als Viren bezeichnet 10. (e)massnahmen zur Verhinderung unberechtigter Programmnutzung: Programmsperren zum Schutz des Computerprogramms sind grundsätzlich zulässig, können aber dann einen Mangel darstellen, wenn die Gebrauchstauglichkeit des Programms gemindert wird 11. (f) Fehlende Bedienerfreundlichkeit: Zu dieser Fallgruppe gehören z.b. das Fehlen der Hilfefunktion oder das Hängenbleiben des Programms 7 M ARLY, Rz ; vgl. auch F RÖHLICH-BLEULER, Rz M ARLY, Rz ; F RÖHLICH-BLEULER, Rz. 377; H EUSLER/MATHYS, LG Essen, CR 1987, 428; LG Karlsruhe, CR 1991, 673, beide zitiert bei WENTE, 85; vgl. auch M ARLY, Rz ; F RÖHLICH-BLEULER, Rz. 382; H EUSLER/MATHYS, Siehe dazu im Detail den Beitrag von K LEINER in diesem Band; M ARLY, Rz FRÖHLICH-BLEULER, Rz. 374; die Gebrauchstauglichkeit kann z.b. dann eingeschränkt sein, wenn Computerprogramme wegen mehrerer Dongles verschiedener Hersteller nicht mehr ordnungsmässig funktionieren, was zu Systemabstürzen führen kann: M ARLY, Rz
8 R OGER S TAUB bei Fehlbedienungen ohne Ausgabe selbsterklärender Fehlertexte und ohne ausreichende Hinweise zur Fehlerbeseitigung in der Dokumentation. Im Einzelfall wird die fehlende Bedienerfreundlichkeit aber häufig nicht als rechtlich relevanter Mangel zu qualifizieren sein 12. (g)unzureichende Dokumentation: Das Vorliegen einer gut verständlichen Dokumentation ist für den Nutzer der Software von grosser Bedeutung. Ist eine Dokumentation nicht vorhanden oder ungenau, ist sie unübersichtlich oder nur schwer verständlich, stellt dies einen Fehler der Software und unter Umständen auch einen rechtlich relevanten Mangel dar 13. Die Dokumentation kann auch nicht ohne weiteres durch Anweisungen auf dem Bildschirm, eine Benutzerschulung oder eine Hotline ersetzt werden 14. (h)fehlende Robustheit bei Bedienungsfehlern: Robustheit bedeutet, dass die Software bei Bedienungsfehlern, mit denen gerechnet werden muss, nicht ohne weiteres Abstürze zulässt. Tut sie dies, ist die Software fehlerhaft 15. (i) Weitere Fehlerkategorien: Die obige Darstellung ist keineswegs abschliessend. Weitere Fehlerkategorien umfassen z.b. die fehlende Pflege- und Migrationsfreundlichkeit einer Software oder Entwurfsfehler Beispiele aus der Praxis Die Zuordnung von Softwarefehlern zu den oben in Ziff dargestellten Kriterien ist nicht immer einfach und letztlich auch nicht aussagekräftig (insbesondere in Bezug auf das Schädigungspotential). Das Schädigungspotential von Softwarefehlern lässt sich z.b. anhand der folgenden Beispiele aus der Praxis aufzeigen: (a)therac-25 ( ): Therac-25 war eine Maschine für Strahlentherapien. Zwischen 1985 und 1987 wurden mindestens sechs Unfälle bekannt, bei welchen Patienten massive Überdosen verabreicht wurden, was zu mindestens fünf Todesfällen führte. Bei zu schneller Eingabe der Bestrahlungsdaten startete das Gerät den Elektronenbeschuss, obwohl das Ziel noch nicht in Position war. Im Rahmen der Ursachenfor- 12 Vgl. M ARLY, Rz ; F RÖHLICH-BLEULER, Rz. 379 f. 13 M ARLY, Rz ; F RÖHLICH-BLEULER, Rz. 379; H EUSLER/MATHYS, Vgl. OLG Stuttgart, CR 1999, 74; LG Mannheim, BB 1985, 144; MARLY, Rz. 963; R EDEKER, 703; W ENTE, 93 f. 15 M ARLY, Rz Im Einzelnen: M ARLY, Rz
9 Softwarefehler Wer haftet für was? schung wurden sowohl institutionelle Fehler (z.b. das Fehlen einer adäquaten Erklärung von Error Codes in der Dokumentation) wie auch Engineering-Fehler entdeckt. So verwendete der Ingenieur beispielsweise Software von älteren Modellen, was dazu führte, dass die Existenz von fehlerhaften Softwarebefehlen nicht indiziert wurde 17. (b)mars Polar Lander (1999): Beim Anflug auf den Mars schoss die Software die Motoren hundert Fuss über der Marsoberfläche ab, was dazu führte, dass das 165 Millionen US-Dollar teure Gerät zerstört wurde 18. (c)bankautomaten Berlin (2001): Ein kompletter Systemausfall bei der Datenverarbeitungsgesellschaft, die für das System der Berliner Sparkasse und der Berliner Bank zuständig war, führte unter anderem dazu, dass Dritte ohne Hacker-Know-how Einsicht in fremde Konten nehmen und Hypotheken, Schulden und Überweisungsaufträge der Kontoinhaber durchsehen konnten 19. (d)us-stromausfall (2003): Im August 2003 blieben acht Bundesstaaten im Nordosten der USA und Teile Kanadas während fünf Tagen ohne Strom. Schuld war ein Softwarefehler des Managementsystems zur Überwachung und Steuerung von Stromnetzen beim Erzeuger. Das System stellte seinen Dienst nach einem durch eine besondere Kombination von Ereignissen und Alarmen ausgelösten Fehler ein. Der Backup-Server versagte, weil ihn die Anzahl der nicht verarbeiteten Meldungen überforderte. In der Folge nahm das System auflaufende Alarme nicht mehr entgegen, was dazu führte, dass die Operatoren nicht reagierten und die in solchen Fällen vorgesehene Abkoppelung des Netzes von anderen Stromnetzen unterblieb 20. (e)börse Tokio (2005): Ein Mitarbeiter eines Finanzunternehmens verwechselte zwei Eingabefelder der Software der Börse von Tokio. Statt einer Aktie für 610'000 Yen bot er 610'000 Aktien für jeweils einen Yen an. Die Software akzeptierte diese völlig unlogische Eingabe und verunmöglichte sogar zehn Minuten lang die Korrektur. Dies führte zu Hunderttausenden von Kauforders und zu einem Kurssturz der Aktie CBS News vom 29. April 2003: "Software Bugs Can be Lethal", abrufbar unter 19 "Software-Fehler legt Geldautomaten lahm (Update)", abrufbar unter heise.de/newsticker/meldung/ "Software-Fehler verursachte US-Stromausfall 2003", abrufbar unter heise.de/newsticker/meldung/
10 R OGER S TAUB Das Finanzunternehmen erlitt (inklusive Rückvergütungen) einen Schaden von 280 Millionen Euro Rechtlich relevante Mängel Wie oben bereits ausgeführt wurde, ist nicht jeder Softwarefehler ein rechtlich relevanter Mangel. Erforderlich ist vielmehr, dass er diejenigen Merkmale erfüllt, welche die jeweils zur Diskussion stehenden Anspruchsgrundlagen voraussetzen. Dabei gibt es keinen, das gesamte vertragliche und ausservertragliche Haftpflichtrecht umspannenden Mangelbegriff. Zu unterscheiden ist vielmehr nach der Anspruchsgrundlage Der Mangelbegriff im Vertragsrecht Als Mangel gilt im Vertragsrecht jegliches Abweichen vom vertraglich Geschuldeten 22. Bei Softwaremängelprozessen stellt sich dabei allerdings oft das praktische Problem, dass es schwierig feststellbar ist, was überhaupt geschuldet ist. Umgekehrt ist es manchmal auch nur begrenzt feststellbar, was die Software leistet 23. In diesem Sinne ist der Mangelbegriff ein einheitlicher, unabhängig davon, wie das zugrundeliegende Rechtsverhältnis zu qualifizieren ist. Die Rechtsfolgen der Sachgewährleistung setzen jedoch teilweise eine unterschiedliche Schwere des Mangels voraus, je nachdem welcher Vertragstypus zur Anwendung kommt 24. Ein Mangel liegt zunächst immer dann vor, wenn eine zugesicherte Eigenschaft fehlt. Es wird also nicht vorausgesetzt, dass die Gebrauchstauglichkeit der Software herabgesetzt oder gar erheblich herabgesetzt wird. Die Zusicherung kann sogar stillschweigend erfolgen 25. Wesentlich schwieriger ist bei Softwareverträgen die Feststellung vorausgesetzter Eigenschaften. Deren Fehlen stellt ebenfalls einen Mangel dar. Abzustellen ist auf die Gebrauchstauglichkeit, die der Anwender in guten Treuen erwarten darf. Kriterien sind dabei insbesondere die Abmachungen im Ver- 21 "Software-Fehler gehen ins Geld", abrufbar unter php. 22 W IDMER, 114 m.w.h. 23 R EDEKER, Vgl. z.b. Art. 191 Abs. 1 OR, Art. 258 Abs. 3 lit. a OR und Art. 368 Abs. 2 OR; H EUS- LER/MATHYS, 183 ff. 25 W IDMER,
11 Softwarefehler Wer haftet für was? trag, die Branchenüblichkeit und die Verwendung von Gütesiegeln oder Gütezeichen. Letztere stellen einen technischen Standard dar, woraus sich der vorausgesetzte Gebrauch ebenfalls ableiten lässt Der Mangelbegriff im Produktehaftpflichtrecht Der haftungsauslösende Produktfehler wird in Art. 4 PrHG 27 definiert. Ein Produkt ist demnach dann fehlerhaft, wenn es nicht diejenige Sicherheit bietet, die man unter Berücksichtigung aller Umstände zu erwarten berechtigt ist. Haftungsauslösendes Moment ist somit die Enttäuschung berechtigter Sicherheitserwartungen. Der Massstab ist dabei ein objektiver 28. In diesem Sinne berechtigte Sicherheitserwartungen werden insbesondere durch die Produktpräsentation erweckt. Dazu gehören Anleitungen, Gütesiegel oder Aussagen in der Werbung 29. Ein weiterer Anhaltspunkt für die berechtigten Sicherheitserwartungen ist der vernünftigerweise zu erwartende Gebrauch. Es ist in diesem Zusammenhang zu überlegen, in welchem Gebiet das Produkt eingesetzt wird, wer in den potentiellen Anwenderkreis fällt (und welche IT-Kenntnisse diese Personen haben). Daraus wiederum lassen sich Rückschlüsse auf vorhersehbare Fehlmanipulationen schliessen. Generell lässt sich sagen, dass der Kunde davon ausgehen darf, bei richtiger Anwendung eines Produktes entstünden keine Schäden 30. Das Nichteinhalten von Sicherheitsnormen bildet hier ebenfalls einen Anhaltspunkt; es wird in der Regel als Fehler zu qualifizieren sein 31. In zeitlicher Hinsicht ist bei all diesen Fragen der Zeitpunkt des Inverkehrbringens des Produktes relevant. Spätere Verbesserungen des Produktes wirken in Bezug auf die Frage, was die berechtigten Sicherheitserwartungen waren, nicht zurück. Umgekehrt ist davon auszugehen, dass die Binsenwahrheit, Software sei nie mangelhaft, dem Softwareproduzenten 26 Vgl. F RÖHLICH-BLEULER, Rz. 363 ff.; W IDMER, Bundesgesetz vom 18. Juni 1993 über die Produktehaftpflicht, SR H EUSLER/MATHYS, S TRAUB, Produktehaftung, Rz. 56; W EBER, E-Commerce, STRAUB, Produktehaftung, Rz. 34 und 39; erhöhte Anforderungen wird man an die Sicherheit eines Softwareproduktes dann stellen dürfen, wenn voraussehbar ist, dass ein Fehler zu Körperverletzungen führen kann (so z.b. bei Software, die in medizinaltechnischen Produkten verwendet wird): M ORSCHER, S TRAUB, Produktehaftung, Rz. 37 mit Hinweis auf abweichende Lehrmeinungen. 331
12 R OGER S TAUB nicht weiterhelfen wird. Nach zutreffender Ansicht sind Softwaremängel nicht als produktimmanent hinzunehmen 32. Software ist oft Teil eines anderen Produktes. Im produktehaftpflichtrechtlichen Sinne spricht man dabei von Teilprodukten. Die Fehlerhaftigkeit im Sinne von Art. 4 PrHG und damit die zu erwartende Bandbreite sicheren Gebrauchs ist für jedes Teilprodukt separat zu bestimmen Kein Mangelbegriff im Deliktsrecht Das Deliktsrecht knüpft die Haftpflicht nicht an den Mangelbegriff an, sondern an das widerrechtliche Verursachen einer Schädigung. Ausführungen zum Mangelbegriff erübrigen sich daher Haftung aus Produktehaftpflicht 3.1 Haftungsvoraussetzungen: Überblick Als erste mögliche Haftungsgrundlage für durch Softwarefehler verursachte Schäden kommt die Produktehaftpflicht gemäss PrHG 35 in Frage. Die Haftungsvoraussetzungen nach PrHG sind die Folgenden: (a)der Schaden wird durch ein Produkt verursacht, das fehlerhaft ist (dazu oben Ziff sowie unten Ziff. 3.2). (b)durch das fehlerhafte Produkt wird eine bestimmte Art von Schaden verursacht (dazu unten Ziff. 3.4). (c)zwischen Fehler und Schaden besteht ein adäquater Kausalzusammenhang. Es kommt die allgemeine Definition gemäss Rechtsprechung zur Anwendung. Danach ist der Schaden dann adäquat verursacht, wenn die betreffende Ursache nach dem gewöhnlichen Lauf der Dinge und der allgemeinen Lebenserfahrung an sich geeignet war, den eingetretenen Erfolg zu bewirken, so dass der Eintritt des Erfolges als durch 32 STRAUB, Produktehaftung, Rz. 47; vgl. auch die Hinweise auf abweichende deutsche Lehrmeinungen bei M ORSCHER, S TRAUB, Produktehaftung, Rz Zu den Haftungsvoraussetzungen nach Deliktsrecht vgl. unten Ziff Für das europäische Recht siehe Richtlinie 85/374/EWG des Rates vom 25. Juli 1985 zur Angleichung der Rechts- und Verwaltungsvorschriften der Mitgliedstaaten über die Haftung für fehlerhafte Produkte (PrHRL); zur Bedeutung der PrHRL für das schweizerische Recht vgl. S TRAUB, Produktehaftung, Rz. 10 ff. 332
13 Softwarefehler Wer haftet für was? die fragliche Tatsache allgemein begünstigt erscheint 36. Probleme in beweistechnischer Hinsicht können sich vor allem bei nicht reproduzierbaren Fehlern eines IT-Systems ergeben. Die Kausalität ist dann nur schwer feststellbar Wann ist Software ein fehlerhaftes Produkt? Das PrHG will nicht auf jegliche Art von Fehlern angewandt sein, sondern nur auf solche, die an einer beweglichen Sache bestehen. Zusätzlich gilt es auch für Fehler an Elektrizität (Art. 3 Abs. 1 PrHG). Nach zutreffender Ansicht meint Art. 3 Abs. 1 PrHG jedoch nicht eine bewegliche Sache im sachenrechtlichen Sinne. Der Begriff ist vielmehr nach produktehaftpflichtrechtlichen Kriterien auszulegen 38. Umgekehrt ist aber im Hinblick auf die Frage der Produktqualität von Software auch zu berücksichtigen, dass das PrHG auf Dienstleistungen nicht angewandt sein will. Ohne weiteres wird man die Produkteigenschaft desjenigen Gegenstandes bejahen können, in den die Software eingebaut ist. In diesem Falle haftet der Softwarehersteller als Teilproduzent 39. Ähnlich liegen die Dinge, wenn die Programmkopie auf einem Datenträger gespeichert ist 40. Die Produktqualität der Software selbst also losgelöst von einem körperlichen Produkt, in das sie integriert oder kopiert ist wird von der herrschenden Lehre in der Schweiz bejaht 41. Diese Ansicht ist zumindest in Bezug auf Standardsoftware sicherlich zutreffend. Angesichts der Tatsache, dass das Computerprogramm sowohl bei der körperlichen wie auch bei der unkörperlichen Übertragung unverändert übertragen wird, kann die Art der Materialisierung bzw. Übertragung unter produktehaftpflichtrechtlichen Gesichtspunkten keine Rolle spielen. Weniger eindeutig ist dagegen die Situation in Bezug auf Individualsoftware. Diese ist das Ergebnis eines konkreten Auftrages bzw. eines konkreten, kundenspezifischen Werkvertrages und daher sehr nahe an einer Dienstleistung. Sie ist 36 Statt Vieler: BGE 123 III 110 E. 3a. 37 Vgl. S TRAUB, Produktehaftung, Rz. 126 f. 38 BasK-FELLMANN, N 2 zu Art. 3 PrHG; FELLMANN/VON BÜREN-VON MOOS, Rz. 141; S TRAUB, Produktehaftung, Rz. 15, m.w.h. 39 S TRAUB, Produktehaftung, Rz. 16; W EBER, E-Commerce, 502; vgl. auch H ESS, Vgl. S TRAUB, Produkt, Abs. III und IV. 41 STRAUB, Produktehaftung, Rz. 17 und 21; HEUSLER/MATHYS, 203; WEBER, E-Commerce, 502; WEBER, Haftungsgrundlagen, 131; ROBERTO, Produktehaftpflicht, 57 f.; a.m. R EY, Rz. 1186c. 333
14 R OGER S TAUB in aller Regel auch nicht dafür bestimmt, als handelbare Ware auf dem Markt eingesetzt zu werden, sondern soll vielmehr die individuellen Bedürfnisse des Kunden befriedigen. Zumindest soweit Letzteres im Vordergrund steht, ist daher die Qualifizierung von Individualsoftware als Produkt im Sinne des PrHG abzulehnen 42. Die Dokumentation ist nach der hier vertretenen Auffassung Teil der Software. Enthält sie einen Mangel, liegt daher ein Produktfehler im Sinne von Art. 4 PrHG vor. In Bezug auf den produkthaftpflichtrechtlichen Fehlerbegriff kann auf die Ausführungen oben in Ziff verwiesen werden. 3.3 Wer haftet? Als Grundsatz gilt: Für ein fehlerhaftes Produkt haftet unter dem PrHG die Herstellerin (Art. 1 PrHG). Das führt uns zur Frage, wer als Herstellerin des fehlerhaften Produktes gilt. Der Begriff ist ein weiter (Art. 2 PrHG): Es gilt zunächst, dass sowohl die Herstellerin des Endproduktes wie auch die Herstellerin der Teilprodukte haften. Das bedeutet, dass nicht nur die Herstellerin des Gegenstandes, in das die Software integriert wird, haftet, sondern auch die Herstellerin der zu integrierenden Software. Die Herstellerin der Software haftet dabei sowohl für die Leistungen ihrer Arbeitnehmer wie auch für diejenigen ihrer Freelancer; bezüglich Letzterer allerdings nur, soweit sie die Organisationsgewalt über deren Leistungen innehat 43.Weiter haftet auch der sog. Assembler, d.h. diejenige Person, welche aus Einzelteilen ein neues Produkt herstellt 44. Als Herstellerin gilt aber auch die sog. "Quasiherstellerin", d.h. diejenige Person, welche sich durch das Anbringen z.b. ihres Namens oder ihrer Marke auf dem Produkt als Herstellerin ausgibt. Auch der Importeur gilt als Hersteller 45. All diese verschiedenen Hersteller und Herstellerinnen haften nach allgemeinen haftpflichtrechtlichen Grundsätzen solidarisch. Subsidiär, d.h. wenn keiner dieser Hersteller ermittelt werden kann, haftet auch der Lie- 42 Zu absolut daher STRAUB, Produktehaftung, Rz. 23, für den funktionsfähige Individualsoftware unabhängig von ihrer individuellen Herstellung immer ein Produkt ist; ablehnend auch R EY, Rz. 1186c. 43 S TRAUB, Produktehaftung, Rz H ESS, 155 f.; S TRAUB, Produktehaftung, Rz Zu Einzelfragen wie dem Import von Gratissoftware oder zur Online-Übertragung als Import vgl. S TRAUB, Produktehaftung, Rz. 92 ff. 334
15 Softwarefehler Wer haftet für was? ferant der Software 46. Die Haftung des Lizenzgebers an Software ist hingegen umstritten. Denkbar ist eine Haftung als Quasihersteller 47. Oft ist Software ein blosses Teilprodukt des Endproduktes, sei es, dass sie in eine bewegliche Sache integriert ist, oder sei es, dass sie selbst Komponente eines grösseren IT-Systems ist. Auch dies führt grundsätzlich zu einer Haftung des Softwareherstellers für Schädigungen, die durch das Endprodukt verursacht werden. Vorausgesetzt wird jedoch einerseits, dass die Software als Teilprodukt eine eigene produkttypische Schädigungsgefahr aufweist 48. Andererseits haftet der Softwarehersteller nur für seine Vorhersteller (z.b. einen Freelancer), nicht jedoch für die Nachhersteller Wofür wird gehaftet? Die Produktehaftpflicht nach PrHG gilt nicht unbeschränkt, sondern nur für ganz bestimmte Arten von Schäden: Eine Haftung besteht zunächst nur für Personen- oder Sachschäden. Andere Schäden wie insbesondere Vermögensschäden sind nicht zu ersetzen. Ein Ersatz für den Schaden, der durch Datenverlust entsteht, wäre daher z.b. nicht möglich 50. In Bezug auf Sachschäden wird darüber hinaus vorausgesetzt, dass die beschädigte Sache hauptsächlich zum privaten Gebrauch oder Verbrauch bestimmt war und vom Geschädigten hauptsächlich privat verwendet worden ist (Art. 1 Abs. 1 PrHG). Bereits dies bedeutet eine erhebliche Einschränkung der Bedeutung des Produkthaftpflichtrechts für Softwarefehler. Hinzu kommt, dass eine Haftung für Schäden am fehlerhaften Produkt selbst nicht besteht (Art. 1 Abs. 2 PrHG) 51. Letzteres führt in Bezug auf integrierte Software zur heiklen Frage, ob der Softwarehersteller (als Hersteller eines Teilproduktes) für Schäden am Gesamtprodukt haftet, in das die Software integriert ist. Wie praktisch relevant diese Frage sein kann, zeigt sich am Beispiel des durch einen Soft- 46 Zur Haftung des OEM-Anbieters vgl. S TRAUB, Produktehaftung, Rz H ESS, 164; zum Ganzen: S TOESSEL, passim. 48 S TRAUB, Produktehaftung, Rz S TRAUB, Produktehaftung, Rz W EBER, E-Commerce, 504; vgl. auch R EY, Rz. 308a; die Haftung für Datenverlust würde darüber hinaus meist auch daran scheitern, dass wertvolle Daten in aller Regel zu geschäftlichen (und nicht zu privaten) Zwecken genutzt werden. 51 Produktehaftung ist Haftung für Mangelfolgeschäden: R EY, Rz
16 R OGER S TAUB warefehler verursachten Absturzes eines Privatflugzeugs. Die Frage ist umstritten 52. Meines Erachtens dürfte die Haftung für das Gesamtprodukt zu verneinen sein. Aus Sicht des Abnehmers und Geschädigten ist das Produkt (z.b. das Flugzeug), das ein fehlerhaftes Teilprodukt (z.b. die Steuerungssoftware) enthält, in der Regel als solches fehlerhaft. Eine Aufspaltung in den nicht zu ersetzenden fehlerhaften Teil und den zu ersetzenden fehlerhaften Rest (der oft ohne den fehlerhaften Teil auch nicht funktionieren würde) wirkt gekünstelt. Bei Sachschäden besteht ein Selbstbehalt von CHF 900 (Art. 6 Abs. 1 PrHG). Im Übrigen richten sich die Berechnung und die Aufteilung des Schadenersatzes nach Art. 42 ff. OR. 3.5 Ausnahmen von der Haftung Das PrHG sieht insbesondere in Art. 5 verschiedene Ausnahmen von der Haftung des Herstellers vor. Auf einige davon wurde bereits eingegangen. So besteht z.b. keine Haftung, wenn der Fehler im Zeitpunkt des Inverkehrbringens noch nicht bestanden hat, oder es haftet der Teilprodukthersteller nicht für Fehler, die von seinen Nachherstellern gemacht wurden. Weiter besteht keine Haftung, wenn die Herstellung des Produkts ohne wirtschaftlichen Zweck oder ausserhalb beruflicher Tätigkeit erfolgte. Eine Haftung nach PrHG setzt sodann voraus, dass das fehlerhafte Produkt überhaupt in Verkehr gebracht wurde. Das Inverkehrbringen kann auch durch den Lizenznehmer geschehen 53. Der Begriff des Inverkehrbringens umfasst nach zutreffender Ansicht auch das unveränderte Kopieren der bereits in Verkehr gebrachten Programmkopie durch einen Dritten. Dies muss auch gelten, wenn die Programmkopie unerlaubt hergestellt wurde, was freilich umstritten ist. Das eigentliche Inverkehrbringen nimmt nämlich der Hersteller auch hier mit der Abgabe der ersten Programmkopie vor. So gesehen besteht kein Unterschied zum berechtigten Kopieren. Der Hersteller muss meines Erachtens aber damit rechnen, dass Kopien unzulässigerweise hergestellt werden, da dies wenn auch unzulässig so doch notorisch ist. Es darf auch davon ausgegangen werden, dass entsprechende unzulässige Handlungen in der Kalkulation der 52 Vgl. STRAUB, Produktehaftung, 108, m.w.h.; ablehnend wie hier: BasK-FELLMANN, N 11 f. zu Art. 2 PrHG. 53 S TRAUB, Produktehaftung, Rz
17 Softwarefehler Wer haftet für was? Lizenzgebühren mitberücksichtigt sind, so dass auch ökonomische Gesichtspunkte der hier vertretenen Ansicht nicht entgegenstehen 54. Als weiterer Entlastungsgrund gilt sodann das Vorliegen sog. Entwicklungsrisiken. Nach zutreffender Ansicht sind solche freilich nur mit Zurückhaltung anzunehmen, nämlich dann, wenn sie absolut unvorhersehbar sind 55. Die Herstellung nach verbindlichen hoheitlichen Normen gilt ebenfalls als Entlastungsgrund 56. Schliesslich ist noch festzuhalten, dass die Haftung nach PrHG absolut zwingend ist. Eine Freizeichnung oder Haftungsbeschränkung ist daher nicht möglich (Art. 8 PrHG). 3.6 Fazit Zusammenfassend kann festgestellt werden, dass das PrHG dem direkt Geschädigten zwar grundsätzlich verschuldensunabhängige Ansprüche gegenüber diversen Beteiligten gibt (Herstellern der Software und des Gegenstandes, in welchen Software integriert ist, Importeuren, Personen, die ihre Kennzeichen auf dem Produkt mit der Software anbringen, und allenfalls auch Lieferanten). Die praktische Bedeutung des PrHG für die Haftung aus Softwarefehlern ist dennoch begrenzt. Dies ist insbesondere darauf zurückzuführen, dass ein Grossteil der aufgrund von Softwarefehlern entstehenden Schäden (Vermögensschäden und Schäden an gewerblich verwendeten Produkten sowie am fehlerhaften Produkt selbst) von der Haftung ausgenommen sind. Nimmt man z.b. die oben in Ziff dargestellten Fälle, so käme wohl nur in Bezug auf den Fall Therac-25 eine Haftung nach PrHG in Frage. Hinzu kommt, dass in Bezug auf Individualsoftware erhebliche Vorbehalte bestehen, ob das Produktehaftpflichtrecht überhaupt zur Anwendung kommt. Alles in allem wird der Geschädigte daher in aller Regel auf andere Haftungsgrundlagen (aus Delikt und Vertrag) ausweichen müssen. 54 A.M. S TRAUB, Produktehaftung, Rz. 134 ff. 55 S TRAUB, Produktehaftung, Rz Die Einhaltung privater Normen wie DIN oder ISO entlastet dagegen nicht: H ESS, 272; S TRAUB, Produktehaftung, Rz
18 R OGER S TAUB 4. Haftung aus Delikt 4.1 Allgemeine Haftungsvoraussetzungen Steht der Geschädigte in keiner vertraglichen Beziehung zum Schädiger, und fällt auch eine Haftung nach PrHG ausser Betracht, ist eine Haftung nach Deliktsrecht zu prüfen. Ganz allgemein setzt die Haftung nach Art. 41 ff. OR eine widerrechtliche Handlung oder Unterlassung voraus, die einen unmittelbaren oder mittelbaren Schaden adäquat kausal verursacht 57. Grundsätzlich wird nur für Verschulden gehaftet. Eine für die Haftung für Softwarefehler bedeutende Ausnahme besteht neben der oben bereits behandelten Produktehaftpflicht bei der Geschäftsherrenhaftung gemäss Art. 55 OR. Von besonderem Interesse sind im Zusammenhang mit der Haftung für Softwarefehler die Fragen der Widerrechtlichkeit und des Verschuldens. Darauf wird nachfolgend detaillierter eingegangen, ebenso wie auf die Frage, wer (und vor allem) wofür haftet. 4.2 Zur Widerrechtlichkeit Damit eine schädigende Handlung als widerrechtlich qualifiziert werden kann, muss sie entweder ein absolut geschütztes Rechtsgut oder eine Schutznorm verletzen 58. Soweit durch fehlerhafte Software Sachen oder Personen zu Schaden kommen, stellen sich diesbezüglich weniger Probleme. Es liegt dann eine Verletzung eines absolut geschützten Rechtsgutes vor. Problematisch sind in diesem Zusammenhang dagegen Datenverluste. Sie wird man wohl nur dann als Sachschaden qualifizieren können, wenn der verlorene Datenbestand im beschädigten Datenträger enthalten ist 59. Selbst wenn man die Zerstörung des Datenträgers als Verletzung eines absolut geschützten Rechtsgutes auch in Bezug auf die Daten gelten lässt, wird das Problem jedoch nur teilweise, nämlich nur bezüglich der Daten des Eigentümers des Datenträgers gelöst. Befinden sich auf dem Datenträger auch Daten Dritter, so liegt aus Sicht des geschädigten Eigentümers nur ein Drittschaden vor, der vom Eigentümer des Datenträgers grundsätz- 57 Zum Begriff des adäquaten Kausalzusammenhanges siehe oben Ziff. 3.1 Bst. c. 58 Statt vieler: R EY, Rz. 682 ff. und 698 ff. 59 Zum Ganzen vgl. R EY, Rz. 308a. 338
19 Softwarefehler Wer haftet für was? lich nicht geltend gemacht werden kann. Der an den Daten Berechtigte hat zwar einen Schaden, doch ist er eben nicht in einem absolut geschützten Rechtsgut verletzt, so dass es aus seiner Sicht an der Widerrechtlichkeit fehlt. Denkbar und wohl auch sinnvoll wäre es, diese Fälle über die sog. Drittschadensliquidation zu lösen 60. Darüber hinaus dürfte es dagegen schwierig sein, Datenverluste als Sachschäden zu qualifizieren. Gleiches gilt, wenn durch Datenverluste weitere Schäden entstehen wie Arbeitsausfälle oder ein Mehraufwand (z.b. für die Wiederherstellung der Daten). Es stellt sich mithin die Frage, ob die Widerrechtlichkeit dann anders begründet werden kann. Zu denken ist zunächst an die Verletzung einer Schutznorm. Dabei handelt es sich um eine besondere Norm, die gerade den Schutz vor Schäden von der Art des eingetretenen Schadens zum Zwecke hat 61. Gerade im Softwarebereich sind solche Schutznormen jedoch selten. Insbesondere stellen technische Normen (wie z.b. ISO/BS) keine Vermögensschutznormen dar 62. Weiter liesse sich überlegen, ob sich durch Anwendung des Gefahrensatzes die Widerrechtlichkeit entsprechender Schädigungen im Einzelfall begründen liesse. Gemäss dem Gefahrensatz ist derjenige, der einen Zustand schafft oder aufrechterhält, der einen Anderen schädigen könnte, verpflichtet, die zur Vermeidung eines Schadens erforderlichen Vorsichtsmassnahmen zu treffen 63. Gestützt darauf könnte man z.b. argumentieren, dass bei Software mit entsprechendem Schädigungspotential Vorsichtsmassnahmen in die Software und/oder in die Dokumentation zu integrieren sind. Allerdings ist gemäss Ansicht des Bundesgerichts der Gefahrensatz nicht dazu da, die Widerrechtlichkeit zu begründen, sondern er soll primär beim Verschulden von Bedeutung sein 64.Der Gefahrensatz hilft somit ebenfalls nicht weiter. 4.3 Zum Verschulden Grundsätzlich setzt eine Haftung aus Art. 41 ff. OR Verschulden voraus, das vom Geschädigten zu beweisen ist. Verschulden kann bekanntlich ent- 60 Zur Drittschadensliquidation vgl. GAUCH /SCHLUEP/SCHMID/REY, Rz ff.; REY, Rz. 363 ff.; H ONSELL, R EY, Rz. 698 m.w.h. 62 S TRAUB, Ausservertragliche Haftung, Vgl. R EY, Rz. 753 m.w.h. 64 BGE 124 III 300; 123 III 312; 119 II 129; vgl. allerdings auch BGE 116 Ia
20 R OGER S TAUB weder in einem Vorsatz oder in Fahrlässigkeit liegen. Vorsatz dürfte bei Softwarefehlern in aller Regel nicht gegeben sein. Heikle Fragen stellen sich dagegen in Bezug auf die Fahrlässigkeit. Auszugehen ist von einem objektivierten Fahrlässigkeitsbegriff. Das bedeutet, dass ein Mangel an der unter den gegebenen Umständen erforderlichen Sorgfalt Fahrlässigkeit begründet. Subjektive Umstände wie beispielsweise die Erfahrung des Schädigers sind allerdings ebenfalls zu berücksichtigen, wie auch der eben erwähnte Gefahrensatz 65. Generell wird man bei Software zu prüfen haben, ob sich der Verursacher so verhalten hat, wie man es von einem Informatiker erwarten darf, der einen entsprechenden Ausbildungsstand hat 66. Wenn der Informatiker nicht über den der Aufgabenstellung angemessenen Ausbildungsstand verfügt, entlastet ihn das indessen nicht. Er muss sich dann ein Übernahmeverschulden vorwerfen lassen. Von Bedeutung sind sodann in der Branche gängige Sicherheitsstandards. Wenn der Hersteller der Software von diesen abweicht, kann dies ein Indiz für fahrlässiges Verhalten sein. 4.4 Wer haftet? Grundsätzlich haftet zunächst diejenige natürliche Person, welche die fehlerhafte Software entwickelt hat, die zu einem Schaden führt. Gerade bei grösseren Schäden dürfte allerdings die Haftung des Softwareentwicklers aufgrund seiner regelmässig geringen wirtschaftlichen Leistungsfähigkeit nur beschränkt interessant sein. Das Softwareunternehmen, für welches der fehlerhafte Softwareentwickler tätig ist, haftet unter den Voraussetzungen von Art. 55 OR (Geschäftsherrenhaftung). Diese Haftung setzt voraus, dass der Entwickler in einem Subordinationsverhältnis zum Softwareunternehmen steht. In Bezug auf Arbeitnehmer des Softwareunternehmens ist dies unproblematisch. Bei Freelancern dagegen kann diese Frage heikel werden. Die rechtliche Natur der Beziehung zwischen Geschäftsherrn und Hilfsperson ist allerdings nicht entscheidend. Es kommt vielmehr darauf an, ob ein tatsächliches Unterordnungsverhältnis, eine ökonomisch-organisatorische Subordination, besteht 67. Dies kann durchaus auch in Bezug auf den Freelancer gegeben sein. 65 Vgl. R EY, Rz. 843, 847 und S TRAUB, Ausservertragliche Haftung, R EY, Rz