Die Auswirkungen der neuen Produkthaftungsrichtlinie für Software: Teil III

Im III Teil dieser Blog-Reihe werden weitere materielle und verfahrensrechtlinie Änderungen durch die Produkthaftungsrichtlinie dargestellt. Der Fokus liegt dabei auf die Auswirkungen für Software:

‍

2.3.    Erleichterungder Beweisführung

Im Rahmen einer, dem Vorschlag zur PHRL vorgelagerten, öffentlichen Konsultation waren 77 % der Befragten der Ansicht, dass technisch komplexe Produkte zu Schwierigkeiten im Zusammenhang mit der Beweislast der geschädigten Person führten.[1] 53% aller Ansprüche wegen Produkthaftung scheiterten aufgrund von Beweisschwierigkeiten.[2] Daraus leitet sich eines der Hauptziele der PHRL ab: Die Beweislast soll in komplexen Fällen gemindert werden und die Einschränkungen bei der Geltendmachung von Ansprüchen verringert werden.[3] Andieser Stelle soll darauf hingewiesen, dass das Produkthaftungsgesetz regelmäßig außervertragliche Haftungsfälle betrifft, bei welchen die Beweislastumkehr nach § 1298 ABGB nicht zur Anwendung gelangt.

Der konkrete Vorschlag, wie dieses Vorhaben umgesetzt werden soll ist nicht weniger alsrevolutionär – und mit dem österreichischen Zivilverfahrensrecht sowie demnemo-tenetur-Prinzip (das Verbot eines Zwangs zur Selbstbelastung), immerhin einem Grundprinzip der österreichischen Verfassung[4], nur schwer in Einklang zu bringen.

Art 9 Z 2 lita) PHRL sieht sinngemäß vor, dass von einer Fehlerhaftigkeit des Produktes – unter anderem – dann auszugehen ist, wenn der Beklagte ihm entlastende Beweismittel nicht offenlegt. Dadurch soll eine Informationsasymmetrie behoben werden, denn geschädigte Personen haben häufig einen erheblichen Nachteil gegenüber den Herstellern in Bezug auf den Zugang zu Informationen darüber, wieein Produkt hergestellt wurde und wie es funktioniert.[5] Da die Hersteller über Fachwissen verfügen und besser informiert sind als die geschädigte Person, sollte es ihnen obliegen, die Vermutung einer Fehlerhaftigkeit des Produktes zu widerlegen.

‍

Prozessführung bei Lizenzstreitigkeiten vor Gericht

Neben denbereits erwähnten zivilverfahrens-, und auch verfassungsrechtlichen Kritikpunkten birgt dieser Ansatz folgende Gefahr: Ein Mitbewerber könnte unter dem Deckmantel der Fehlerhaftigkeit eines Produktes versuchen an Geschäfts- undBetriebsgeheimnisse des Herstellers zu gelangen. Dies erkennt der Gesetzgeber auch, weshalb sicherzustellen ist, dass der Zugang zu Beweismitteln auf das notwendige und verhältnismäßige Maß beschränkt ist und dass vertrauliche Informationen und Geschäftsgeheimnisse geschützt werden.[7]Bei der Entscheidung über solche Maßnahmen sollten die nationalen Gerichte Folgendes berücksichtigen: i) die Notwendigkeit, das Recht auf einen wirksamen Rechtsbehelf und ein faires Verfahren zu gewährleisten, ii) dieberechtigten Interessen der Parteien und gegebenenfalls Dritter und iii) denmöglichen Schaden, der einer der Parteien und gegebenenfalls Dritten durch die Gewährung oder Ablehnung dieser Maßnahmen entstehen kann.[8]

Schließlich regelt Art 9 Z 4 PHRL einen speziellen Fall der Beweisführungserleichterung inbesonders technisch oder wissenschaftlich komplexen Fällen. Demnach wird die Fehlerhaftigkeit eines Produktes vermutet, wenn es übermäßig schwierig ist den ursächlichen Zusammenhang zwischen dessen Fehlerhaftigkeit und dem Schaden nachzuweisen. In diesen Fällen muss der Kläger bloß nachweisen, dass das Produkt zum Schaden beigetragen hat und dass das Produkt wahrscheinlich fehlerhaft war und/oder seine Fehlerhaftigkeit den Schaden wahrscheinlich verursacht hat.

Im Interesse einer gerechten Risikoverteilung sollten potentiellen Haftungsadressaten von der Haftung jedoch befreit werden, wenn sie nachweisen können, dass besondere entlastende Umstände vorliegen. Sie sollten nicht haftbar sein, wenn sie nachweisen können, dass eine andere Person das Produkt gegen ihren Willen ausdem Herstellungsprozess entnommen hat oder dass der eigentliche Grund für dieFehlerhaftigkeit des Produkts die Einhaltung verbindlicher Vorschriften war.[9]

2.4.    Produktbeobachtungsowie Update- und Upgrade-Pflichten: Auswirkungen für Software und Recht

Bei Beurteilung der Frage, ob eine Software fehlerhaft nach der PHRL ist, sollen nachstehenden Aspekte berücksichtigt werden. Dabei ist einerseits der Zeitpunkt des Inverkehrbringens oder der Inbetriebnahme maßgeblich, aber andererseits auch – und dies ist in dieser Klarheit neu – der Zeitpunkt danach, wenn Mängel auftreten, die ihre Ursache in Upgrades und Updates haben.

Die Möglichkeitder Wirtschaftsakteure sich einer Haftung zu entziehen soll eingeschränkt sein,wenn Software-Updates oder Software-Upgrades nicht angeboten wurden, die Schwachstellen im Bereich der Cybersicherheit und der Sicherheit des Produktes beheben sollen. Demnach sollen die Hersteller auch für Schäden haften, die durch die Nichtbereitstellung von Updates oder Upgrades für dieSoftwaresicherheit, die erforderlich sind, um die Schwachstellen des Produkts als Reaktion auf sich wandelnde Cybersicherheitsrisiken zu beheben, verursacht werden. [10] In diesem Zusammenhang ist erwähnenswert, dass die Aktualisierungspflicht offenbar ausschließlich den Aspekt „Softwaresicherheit“ bzw „Cybersicherheitsrisiken“ betrifft, obgleich diese Einschränkung in Artikel 10Abs 2 lit b PHRL nicht dezidiert zum Ausdruck kommt. Hinzuweisen ist jedochgenerell darauf, dass ein Produkt als fehlerhaft gilt, wenn es nicht die Sicherheit bietet, die die breite Öffentlichkeit unter Berücksichtigung aller Umstände erwarten darf.

‍

Auswirkungen auf das Softwarerecht

Da die Begriffe der Softwaresicherheit und Cybersicherheitsrisiken einerseits unbestimmt sind und andererseits eine Software auch unter anderen Gesichtspunkten fehlerhaft sein kann, drohen Abgrenzungsschwierigkeiten. Die Zielsetzung des Produkthaftungsgesetzes vor Augen, nämlich die Haftung für Schäden, die natürlichen Personen durch fehlerhafte Produkte entstehen, ist es jedoch zutreffend, die Aktualisierungspflicht nicht auf Fälle beispielsweise bloßer Funktionsdefizite, fehlender Interoperabilität, geringererArbeitsgeschwindigkeit, fehlerhafter Benutzerfreundlichkeit, Rechtsmängel oder unzureichender Dokumentation der Software auszudehnen.[12]Derartige Leistungsstörungen werden durch das vertragliche Gewährleistungsrecht kompensiert, wobei in diesem Zusammenhang auf die Aktualisierungspflicht und die objektiv erforderlichen Eigenschaften einer Software nach § 6 und § 7 Verbrauchergewährleistungsgesetz hinzuweisen ist.[13]Sehr wohl könnte jedoch angedacht werden, den Aspekt der „Datensicherheit“ in die Aktualisierungspflicht (auch) nach dem Produkthaftungsgesetz aufzunehmen, sofern er nicht bereits ohnehin vom Begriff der „Sicherheit“ umfasst ist. Wendehorst/Duller[14] unterscheiden in diesem Zusammenhang zwischen „Sicherheitsrisiken“ und „Funktionalitätrisiken“ wobei die Sicherheitsrisiken wiederum unterteilt werden in „physische Risiken“ wie Tod, Körper- und Sachschäden, „rein wirtschaftliche Schäden“ und „soziale Risiken“ wie beispielsweise Diskriminierung oder Bloßstellungen. ErwGr 16 nennt auch den Verlust oder die Verfälschung von Daten, wie z.B. auseiner Festplatte gelöschte Inhalte, einschließlich der Kosten für die Rettung oder Wiederherstellung der Daten als potentielle Schäden. Ob damit auch psychische Schäden unter die Produkthaftung fallen, bleibt nachwie vor unklar.[16]

Festzuhalten ist, dass nunmehr dezidiert angedachte Form der Produktbeobachtungs- bzw Wartungspflicht die bereits geltende Rechtslage widerspiegelt. So bejahte der OGH die Produktbeobachtungspflicht für den österreichischen Rechtsbereich im Rahmen des allgemeinen Schadenersatzrechts und führt das Bestehen der Produktbeobachtungspflicht im Rahmen des allgemeinen Schadenersatzrechtsdogmatisch auf die Lehre von den Verkehrssicherungspflichten zurück, die nicht im Zeitpunkt des Inverkehr nicht bestanden. Bei Sicherheitslücken ist demnach eine Verpflichtung, Softwareupdates einzuspielen bereits jetzt regelmäßig zu bejahen.[18]

Eine Legaldefinition der Begriffe „Update“ bzw „Upgrade“[19] ist dabei nicht ersichtlich, sodass sich Abgrenzungsfragen, etwa zu einembloßen „Bug-Fixing“ ergeben können. In Ermangelung dieser Definition ist wohldem gebräuchlichen Verständnis zu folgen, wonach Upgrades einen Wechsel zu einer höheren Version (also zum Beispiel von 1.5. auf 2.0.) meint und dabei die Funktionsfähigkeit der bisherigen Software erhöht.[20]Ein Update[21]hingegen dient der Aufrechterhaltung der bisherigen Leistungsfähigkeit innerhalb einer Version (also zum Beispiel von 1.5. auf 1.6.) und geht einher mit der Behebung von Fehlern („Bugs“).[22] Nachdem die Wartungspflicht dazu dienen soll Sicherheitslücken zu schließen, wird bloß eine korrektive Wartung und keine verbessernde Wartung[23]geboten sein. Davon zu unterscheiden sind Releases[24]und Patches[25]. Die Updates und Upgrades werden in der Regel over-the-air (OTA) eingespielt.[26]

Dabei ist zu beachten, dass eine Wartungspflicht nicht zeitlich unlimitiert bestehen kann. Nachdem eine Software auf den Markt gebracht wird, wird die Wartung für eine ältere Version nur für eine bestimmte Zeit bereitgestellt, bevor die Wartung für diese Version vollständig eingestellt wird („end of life“).

In ErwGr 43 heißt es, dass die Haftung für einen angemessenen Zeitraum gelten sollte, das heißt zehn Jahre nach dem Inverkehrbringen. Die Verjährungsfrist soll jedoch erneut beginnen, nachdem ein Produkt wesentlich verändert wurde, z. B. infolge einer Wiederaufarbeitung, die ein Produkt so verändert, dass seine Konformität mit den geltenden Sicherheitsanforderungen beeinträchtigt sind.[27]

Weiters stellen sich die Fragen, wann konkret ein Sicherheitsupdate eingespielt werden muss, wie konkret zu reagieren ist und ob der Anwender auch ein Zwangsupdate dulden muss. Hier gilt, dass je größer das Schädigungspotential ist, umso größeres Gewicht kommt der Produktbeobachtung zu.[28]Sofern sich aus der Produktbeobachtung ergibt, dass von dem im Verkehrgebrachten Produkt potentiell Gefahren ausgehen, kann der Hersteller zur Reaktion verpflichtet sein. Dabei reicht das Spektrum von Warn- bis hin zuRückrufpflichten.[29] Ist das Gefährdungspotential sehr hoch und hält sich der Nutzer nicht an Warnungen bzw führt dieser keine Updates durch, können im Einzelfall Zwangsupdatesgerechtfertigt sei.[30] Dazu ist ebenfalls zu konstatieren, dass der Nutzer, mangels anderer Vereinbarung, entsprechend § 1419 ABGB nicht zur Annahme vonLeistungen verpflichtet ist. Umgelegt auf Updates bedeutet dies, dass der Nutzer ihm bereitgestelltes Updates grundsätzlich nicht installieren muss.[31]

2.4.1.  Aktualisierungspflicht– Kritische Würdigung: Auswirkungen auf das Softwarerecht

Trotzdem es sich kaum vermeiden lässt, dass Bugs und Fehler in einer komplexen Software erst nach Inverkehrbringung eintreten, und damit eine Aktualisierungspflicht opportun erscheint, soll diese auch einer kritischen Würdigung unterzogen werden.

Die primäre Kritik liegt darin, dass auch KMUs und Start-Ups bereits zum Lancierung ihrer Softwareprodukte deren Wartungüber den Software Lifecycle[32]sicherstellen müssen. Die damit einhergehende Wartungspflicht begründet eine erhebliche finanzielle Herausforderung. Die Evaluierung von Fehler in Millionen von Code-Zeilen stellt viele Unternehmen an sich vor Schwierigkeiten. Darüber hinaus sind viele KMUs zurückhaltend mit ihrer Bereitschaft, hohe zeitliche undpersonelle Kapazitäten in die Wartung von Software zu investieren. Dies deshalb nicht, da KMUs regelmäßig in neue Software investieren müssen, da regelmäßig nur diese einen Umsatz (return on investment) erwirtschaften. [33]Generell ist zu befürchten, dass die Wartungspflichten zu einer Erhöhung der Preise für Software führt, da die Unternehmen die gestiegenen Kosten (für dieWartung) an die Kunden übertragen werden.

Diesen Aspekt vor Augen, sowie des wohl treibenden (zumindest unterschwelligen) Faktors für etliche Initiativen im Bereich der europäischen Gesetzgebung, nämlich die Dominanz der, natürlich nicht in der EU-ansässigen, „magnificant seven“: Microsoft, Apple, Google (Alphabet),Facebook (Meta), Nvidia und Tesla einzuschränken, ist zu konstatieren: Die Wartungspflicht konterkariert dieses Ziel. Schließlich sind es gerade diese genannten Akteure, die es sich buchstäblich leisten können, den „Luxus“ einer Wartung ihrer Produkte sicherzustellen. Der Burggraben um diese Unternehmen wird damit nur noch größer.

In diesem Zusammenhang muss auch betont werden, dass insbesondere US-Unternehmen einanderen Zugang zum Thema „Risiko“ haben, als dies bei europäischen Unternehmender Fall ist. US-Unternehmen folgen hier regelmäßig einem rein wirtschaftlichen Ansatz, wonach Sicherheitsmaßnahmen nur umgesetzt werden, wenn die Gesamtkosten dieser Maßnahmen niedriger sind als die als „Kosten“ einer möglichen Schädigung. Europa wählt hier einen anderen Ansatz, da sich insbesondere der Tod oder Personenschäden nicht mit monetären Faktoren abwiegen lassen.[34] Damit soll zum Ausdruck gebracht werden, dass US-Unternehmen liberaler, negativ ausgedrückt rücksichtsloser, vorgehen, was sich jedenfalls letztlich einer unterschiedlichen Innovationsbereitschaft manifestiert.

‍

3. Zusammenfassung - Auswirkungen für Softwareunternehmen

‍

Die Novelle der Produkthaftungsrichtlinie wird eine hohe praktische Relevanz für Anbieter von Software und den E-Commerce-Handel haben. Software wird nun unmissverständlich jedenfalls vom Anwendungsbereich des Produkthaftungsrechtes erfasst sein. Software ist in diesem Sinne weit zu verstehen und umfasst auch KI-Anwendungen. Für Verbraucher wird die Novelle zwei wesentliche Konsequenzen haben: (i) Es wird sich leichter ein Haftungsadressat bestimmen lassen und (ii) der bestehenden Informationsasymmetrie wird mit Beweiserleichterungsregeln begegnet. Anbieter von Software werden zu berücksichtigen haben, dass sie potentiell für Third-Party-Komponenten haftbar gemacht werden können. Weiters werden sie ihr Unternehmen derart aufstellen müssen, dass eine Wartung der Software über den gesamten Software-Lifecycle sichergestellt ist. Die Situation wird für Verbraucher verbessert; KMUs werden über die gestiegene Haftungsgefahr stöhnen. Langfristig werden, paradoxerweise, wohl die großen, mächtigen, EU-auswärtigen Technologie-Unternehmen profitieren. Einige Aspekte sind noch unklar und diskussionswürdig. Besonders ins Auge stechen dabei der weite Anwendungsbereich der „Home-Office-Regelung“; der Ausschluss von freier und quelloffener Software vom Anwendungsbereich; zivilverfahrens- und verfassungsrechtliche Fragen in Bezug auf die Beweislastregelung sowie die Dauer der Produktbeobachtungsfrist. Obgleich durchaus noch mit punktuellen Änderungen zu rechnen ist, tun Softwareunternehmen, IT-Händler und E-Commerce-Plattformen gut daran, sich bereits heute mit den anbahnenden Gesetzesänderungen auseinanderzusetzen.

‍

Literatur-Tipp: Handbuch Softwarerecht

[1]Vgl S 10 PHRL.

[2] EY, Technopolis and VVA “Evaluationof Council Directive 85/374/EEC on the approximation of laws, Final Report,Commission 2018, 23.

[3] Vgl S 2 PHRL.

[4] Art 6 MRK.

[5]Vgl ErwGr 30 zur PHRL.

[6]Vgl ErwGr 34 zur PHRL.

[7]Vgl ErwGr 31 zur PHRL.

[8]Vgl ErwGr 32 zur PHRL.

[9]Vgl 36 zur PHRL.

[10]Vgl 38 zur PHRL.

[11]Vgl Art 8 PHRL.

[12] Tretzmüller,Handbuch Softwarerecht, S 200.

[13] Schmitt, jusIT 6/2021, 221.

[14] Wendehorst/Duller, Safety and Liability-Related Aspects of Software, S 216 ff.

[15]Demnach sind Überschneidungen mit Schadenersatzansprüchen gemäßArt 82 DSGVO nicht auszuschließen.

[16] Wendehorst/Duller, Safety and Liability-Related Aspects of Software, S 277.

[17] Vgl RIS-Justiz RS0128169; OGH13.9.2012, 6 Ob 215/11b; vgl Fida, Update, Patches & Co (2022), 156.

[18] Schultz/Sarre,Nutzung von Cloud Service im Unternehmen, CR 5/2022, 290.

[19]Siehe lediglich „Softwareänderung“ in ErwGr 29 zur PHRL.

[20]In den deutschen EVB-IT Pflege vom 16.7.2015 wird ein Upgrade definiert als„Bündelung mehrerer Mängelbehebungen und/oder Störungsbeseitigungen und mehrals geringfügige funktionale Verbesserungen und/oder Anpassungen derStandardsoftware in einer einzigen Lieferung“.

[21]In den deutsche EVB-IT Pflege vom 16.7.2015 wird ein Update definiert als die„Bündelung mehrerer Mängelbehebungen und/oder Störungsbeseitigungen sowiegeringfügige funktionale Verbesserungen und/oder Anpassungen derStandardsoftware in einer einzigen Lieferung“.

[22] Tretzmüller,Handbuch Softwarerecht, S 139.

[23]Zu den Begriffen der “correction maintenance“ und „enhancement maintenance“siehe Wendehorst/Duller, Safety and Liability-Related Aspects ofSoftware, S 209.

[24] Nachden EVB-IT ist ein Release: „Eine neue Entwicklungsstufe einerStandardsoftware, die sich gegenüber dem vorherigen Release bzw der Version imFunkjtions- und/oder Datenspektrum erheblich unterschiedet (zB Änderungen derVersionnummer von Version 4.5.7 zu 5.0.0)“.

[25] Nachden EVB-IT ist ein Patch: „Eine temporäre Behebung eines Mangels und/oder eineStörung in der Standardsoftware ohne Eingriffe in den Quellcode“.

[26] Wendehorst/Duller, Safety and Liability-Related Aspects of Software, S211.

[27] Vgl ErwGr 44 zur PHRL.

[28] OGH 11.1.2001, 2 Ob 309/99a.

[29] Fida,Update, Patches & Co (2022), 161; Fitz/Grau in Fritz/Grau/Reindl,PHG, 2. Auflage, § 5 Rz 155.

[30] Fida,Update, Patches & Co (2022), 168; Tretzmüller, HandbuchSoftwarerecht, S 206.

[31] Fida,Update, Patches & Co (2022), 183; Schmitt, Gewährleistung beiVerträgen über digitale Inhalte, 224.

[32] Zum Begriff des SoftwareDevelopment siehe Everett/McLeod, Software Testing: Testing acrosthe Entire Software Development Life Cycle, 30.

[33] Wendehorst/Duller, Safety and Liability-Related Aspects of Software, S209.

[34] Wendehorst/Duller, Safety and Liability-Related Aspects of Software, S 227.

‍