Produkthaftung für Software – ewige Schwachstelle oder ungenutzte Chance?

Immer wieder stieß ich in meiner langen Berufskarriere auf ein Thema, dem man am liebsten aus dem Wege ging. Es war die Frage der Produkthaftung von Software. Bei dieser Frage kommt ein fundamentaler Unterschied zwischen Software und allen andern Wirtschaftsgütern zum Ausdruck. An diese Problematik erinnert wurde ich kürzlich durch einen Beitrag von Poul-Henning Kamp, der im September in der ACM-Zeitschrift Queue erschien. Genau derselbe Beitrag kommt auch im November-Heft der Communications der ACM. Kamp vertritt darin die Meinung, dass es höchste Zeit ist, eine gesetzliche Regelung anzustreben. Dass dies die Industrie zwinge umzu­denken, ja von vorne anzufangen, sei kein Schaden sondern ein Nutzen. Die Industrie IST das Problem, meint Kamp – man beachte die Großschreibung (engl.: The Software Industry IS the Problem).

Auch GI-Präsident Stefan Jähnichen hat sich in einer Online-Kolumne mit dem Thema der Haftung auseinandergesetzt. Dabei fallen mir zwei Dinge besonders auf:

Selbst der GI-Präsident sieht inzwischen im Chaos Computer Club (CCC) eine kompetente Instanz für alle Fragen im Spannungsfeld von Informatik und Gesellschaft. Sein moralisches Prestige ist dabei um Klassen höher als etwa das der Deutschen Bank. 
Als loyaler Vertreter der Informatik-Branche vermeidet Jähnichen das Wort ‚Produkthaftung‘ wie der Teufel das Weihwasser. Stattdessen spricht er von ‚Software Liability‘, da man ja bei englischen Vokabeln den Vorteil hat, dass einem deutschen Leser die damit einhergehenden Konnotationen nicht gleich einfallen. Das klingt sogar so ähnlich wie das seit Jahren abgedroschene Wort ‚Reliability‘ (auf Deutsch ‚Zuverlässigkeit‘), ist aber etwas ganz anderes.

Der CCC ‚fordert vermehrte Anstrengungen‘, von wem, das lässt er offen. Jähnichen reagiert darauf mit den üblichen recht harmlosen Appellen ans fachliche Gewissen und der Forderung nach besserer Schulung. Außerdem verlangt er, dass 

bei der Entwicklung neuer Software von Anfang an Zuverlässigkeit und Sicherheit höchste Priorität haben. 

So wie viele akademische Vorschläge greifen auch Jähnichens Ideen etwas zu kurz. Aus der zeitlichen Distanz von Jahrzehnten und frei von jeder geschäftlichen Verant­wortung will ich versuchen das Problem der Haftung so darzustellen, wie ich es sehe, und zwar aus einer etwas breiteren Perspektive. Da ich kein Lehrbuch schreiben will, muss ich mich auf einige wesentliche Aspekte beschränken.

Technische Seite des Problems

Die Entwicklungsphase ist zwar wichtig, ist aber nicht allein entscheidend. Natürlich muss man Software so konstruieren, dass die Anzahl und der Schwierigkeitsgrad von Fehlern möglichst reduziert werden. Formale Beweistechniken und eigenes Testen können dann helfen, wenn eine richtig definierte Aufgabe falsch gelöst wurde. Das betrifft vielleicht weniger als die Hälfte aller Fehler. Es deckt nicht die Fälle ab, dass die Aufgabe ineffizient gelöst wurde. Vor allem aber bleiben diese Methoden völlig außen vor, wenn die zu lösende Aufgabe falsch oder nicht haargenau definiert wurde. Typisch ist, dass von 20 möglichen oder nötigen Fallunterscheidungen zwei vergessen wurden. Nicht immer ist alles in der Natur eindeutig als Schwarz oder Weiß einzustufen. Es können Tausende von Grautönen und Millionen Farben dazwischen liegen, die separat behandelt werden müssen. Menschen sind zwar männlich oder weiblich. Den Familienstand festzulegen wird bereits erheblich schwieriger: Ledig, verheiratet, geschieden, verwitwet, in einer eingetragenen Partnerschaft lebend, usw. Alle neueren und pragmatischen Ansätze im Repertoire des Software Engineerings nehmen auch diesen Teil der Realität zur Kenntnis. Inspektionen und unabhängiges Testen sind entscheidend.

Nochmals mit andern Worten: Es reicht nicht aus, sicherzustellen, dass Software (nur) das tut, was man als Entwickler erwartet. Sie muss meistens erheblich mehr können. Viele Programme, die zuerst für einen bekannten Kreis von Kollegen geschrieben wurden, werden heute von Millionen Menschen auf der ganzen Welt täglich genutzt. Klassisches Beispiel ist das Internet.

Sehr wesentlich für die Lösung jeder Haftungsfrage ist die Zwischenphase zwischen Entwicklung und Nutzung. Jeder Programmierer, der Zugriff zu Code hat, also ihn unter die Tastatur bekommt, kann ihn modifizieren. Er kann z.B. bei jedem Aufruf des Betriebssystems eine Falltüre einbauen, die es ihm erlaubt, die Funktion des Programms zu verändern. Die penibelste und sachgerechteste Entwicklung nützt nichts, wenn das Programm anschließend auf dunklen Kanälen zum Nutzer gelangt. Besonders gefährlich ist es, wenn es zwischendurch dem Spieltrieb junger, unter­beschäftigter Genies ausgesetzt wird. 

Da die meisten Betriebssysteme allgemeine Vorkehrungen treffen, um diese Eingriffe zu verhindern, geht der übliche Weg heute über die nicht ordentlich behandelten Fehlersituationen, z.B. Pufferüberläufe. Bekanntlich stellt die Fehlerbehandlung gängiger Programme etwa 80% seines Codes dar und ist sehr oft unsauber strukturiert. Schließlich kann jemand die dem Nutzer zur Verfügung stehende Maschine verändern, sei es per Mikrocode oder per Hardware, mit dem Ziel, bestimmte Programme zu analysieren und zu modifizieren. Besonders leicht ist es, Programme zu verändern, wenn der Quellcode verfügbar ist. Dass dies auch möglich ist, wenn man vom Objektcode ausgehen muss, hat vor einigen Wochen der Chaos Computer Club am Beispiel des Staatstrojaners nachgewiesen. 

Geschäftliche Seite des Problems

Wie der von Kamp zitierte Ken Thompson demonstrierte, stoßen die technischen Möglichkeiten, vertrauenswürdige Programme zu erzeugen, generell an Grenzen. Selbst wenn man Software eher wie Hardware behandeln würde, also nur als Mikrocode oder ROM-Speicher verteilen würde, wäre das Problem nicht 100% gelöst. Es würde allerdings in sehr vielen Fällen ausreichen.

Deshalb scheint mir ein umfassender Ansatz zur Lösung primär im geschäftlichen Bereich zu liegen. Es geht darum, Vertrauensketten zwischen Lieferanten und Nutzern, also zwischen Menschen und Organisationen zu schaffen. Um diese aufzubauen, ist es wichtig, dass der Lieferant als Erstes offenlegt, welche Risiken er eingegangen ist. Er muss sagen, mit wem er zusammengearbeitet hat, und welchen Weg das Produkt genau genommen hat. Auch muss er angeben, wie er den Lieferweg laufend sichert, und zwar vor, während und nach der Entwicklung. Dass dies die Tendenz zu geschlossenen Systemen, also Systemen aus einer Hand, verstärkt, ist offensichtlich. Auch in diesem Punkte ging die Firma Apple beim iPhone und iPad bereits einen Schritt in die richtige Richtung. Sie überprüft selbst alle Anwendungen, die auf den Systemen installiert werden. Ihr Erfolg könnte die ganze Industrie bewegen, ebenfalls diesen Lösungsansatz ernst zu nehmen. Vielleicht erklärt dies auch etwas die Wut, die Steve Jobs empfand, wenn er auf den Android-Ansatz der Firma Google zu sprechen kam.

Rechtliche Seite des Problems

In Deutschland ist die Produkthaftung durch das Produkthaftungsgesetz (ProdHaftG) eindeutig geregelt. Es betont klar die Verantwortung des Herstellers.

Wird durch den Fehler eines Produkts jemand getötet, sein Körper oder seine Gesundheit verletzt oder eine Sache beschädigt, so ist der Hersteller des Produkts verpflichtet, dem Geschädigten den daraus entstehenden Schaden zu ersetzen (§1, Absatz 1).

Ein Produkt hat einen Fehler, wenn es nicht die Sicherheit bietet, die unter Berücksichtigung aller Umstände, insbesondere (a) seiner Darbietung, (b) des Gebrauchs, mit dem billigerweise gerechnet werden kann, (c) des Zeitpunkts, in dem es in den Verkehr gebracht wurde, berechtigterweise erwartet werden kann (§3, Absatz1).

Die Ersatzpflicht des Herstellers ist ausgeschlossen, wenn …der Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, in dem der Hersteller das Produkt in den Verkehr brachte, nicht erkannt werden konnte (§1, Absatz 2, Nr.5).

Die Produkthaftung gilt unabhängig vom Verschulden. Bekanntlich vermeidet die Software-Industrie daher, ihre Produkte als Produkte zu vermarkten. Sie werden vielmehr als Teil eines Dienstleistungsvertrags nur zur Nutzung überlassen. Alle Lizenzverträge, Eulas genannt, basieren rein auf der vertraglichen Haftung. In Deutschland kommt § 823 BGB zur Anwendung. Da haftet nur, 

wer vorsätzlich oder fahrlässig das Leben, den Körper, die Gesundheit, die Freiheit, das Eigentum oder ein sonstiges Recht eines anderen widerrechtlich verletzt …

Das Risiko für den Lieferanten ist in diesem Falle um Größenordnungen geringer. Das beginnt damit, dass der Nutzer dem Lieferanten zuerst einmal schuldhaftes Verhalten nachweisen muss. Seit Anbeginn hat die Industrie ihre Haltung damit begründet, dass Software grundsätzlich nicht fehlerfrei entwickelt werden kann. Dies überfordere (immer noch) den Stand von Wissenschaft und Technik.

Wie kommen wir weiter?

Viele Kollegen werden sagen, warum soll man etwas ändern, wo doch der Markt täglich bestätigt, dass die augenblickliche Lösung befriedigend ist. Außerdem kann es sein, dass das Problem von alleine weggeht, d.h. dass es sich auswächst – wie man dies bei Kinderkrankheiten erleben kann. Gemeint ist, dass eingebettete Software bald zum bestimmenden Standard wird. Es gibt nämlich kaum noch ein technisches Produkt, das nicht unter der Haube von Software gesteuert ist. Das ist bei Haushaltsgeräten ebenso der Fall wie bei Gartengeräten und Spielzeugen, von Fahrzeugen und medizinischen Geräten ganz zu schweigen. Kein Lieferant denkt daran, hier getrennte Lizenzen (also Eulas) für den Software-Anteil des Gerätes zu drucken und dem Produkt beizulegen.

Für die heute mit Lizenzen überlassenen eigenständigen Software-Produkte sehe ich drei Wege, um Fortschritte zu erzielen. Das sind dieselben Wege, die bei andern heiklen Fragen immer wieder gegangen werden.

Weg 1: Jemand, der den Mut dazu hat, prescht vor. Er bietet Software als Produkt an. Dann müsste sich herausstellen, ob der Markt dies honoriert.
Weg 2: Die Branche als Ganzes geht eine Selbstverpflichtung ein. Dann übernehmen alle gleichzeitig dasselbe Risiko. Eine Übereinkunft zu treffen, ist allerdings zeitraubend.
Weg 3. Man wartet auf den Gesetzgeber. Das ist zwar die brutalste, und meist auch die teuerste Lösung. Ob und wann diese Möglichkeit überhaupt besteht, will ich nicht weiter diskutieren.

Unsere Branche sollte sich entscheiden, ob sie weiterhin einen großen Bogen um das Thema Produkthaftung machen will, oder ob man darin vielmehr eine Chance sieht, die man ergreifen möchte. Der Frage stellen müssen sich die wirtschaftlichen Akteure selbst. Das ist zweifellos besser, als wenn ihnen eine Antwort von außen aufgedrängt wird. Wegen der globalen Ausrichtung der Branche kann diese Frage nicht nur in Deutschland allein angegangen werden, sondern muss den Weltmarkt berücksichtigen. Analogien oder Situationen, wo ähnliche Alternativen bestanden, gab es Zuhauf. Erinnern möchte ich an Sicherheitsfragen im Automobilbau, an die Reduzierung von Umweltbelastungen, die Kontrolle von Lebensmitteln, und ganz zuletzt an die Frage, wie man erreichen kann, dass der Anteil von Frauen in der Unternehmensführung gesteigert werden kann. Die zusätzlichen Fragen, die sich die Software-Industrie stellen sollte, lauten: Zu welcher andern Situation bestehen Ähnlichkeiten und was lässt sich aus diesen andern Erfahrungen lernen?