Ministers stelt ontwikkelaars aansprakelijk voor softwarefouten

| AE 9502 | Aansprakelijkheid, Software | 23 reacties

Demissionair staatssecretaris Klaas Dijkhoff heeft in een Kamerbrief gezegd zegt dat softwareontwikkelaars op verschillende manieren aansprakelijk zijn voor schade die als gevolg van hun product ontstaat. Dat las ik bij Tweakers. Juridisch gezien zegt hij weinig nieuws; de regels over conformiteit bij producten bevatten immers geen uitzondering voor de software-delen van producten. Nieuw is wel de expliciete opmerking dat er ook aansprakelijkheid bestaat “als de software niet voldoet aan de veiligheid die is overeengekomen of die de afnemer redelijkerwijs mocht verwachten.” Hoi hoi, ontwikkelaars aansprakelijk voor security bugs?

In de brief presenteert de staatssecretaris het Cybersecuritybeeld Nederland 2017. De omgang met security bugs en security updates is daarbij een belangrijk aandachtspunt.

De Kamer wilde specifiek weten hoe het zat met aansprakelijkheid voor ontwikkelaars of verkopers van onveilige producten. Ik roep al jaren dat het tijd wordt om productsecurity in de wet te zetten, maar uit deze brief blijkt dat ik achterloop: dat staat al jaren gewoon in de wet. Producten mogen immers geen gebrekkige veiligheid hebben, anders is de leverancier of producent daarvoor aansprakelijk (art. 6:185 BW).

Laat ik nu altijd gedacht hebben dat dat gaat over fysieke veiligheid, ontploffingen en vergiftigingen en zo. Maar dat ziet de staatssecretaris dus anders:

De producent is kort gezegd aansprakelijk voor een productie-, informatie- of ontwerpgebrek, waardoor de software niet de veiligheid biedt die ervan mag worden verwacht. Hij kan zich wel verweren tegen aansprakelijkheid, bijvoorbeeld door te stellen dat het op grond van de stand van de technische kennis op het tijdstip waarop hij de software leverde, onmogelijk was het bestaan van het veiligheidsgebrek te kennen.

In de comments bij Tweakers kwam nog de issue langs dat je hiermee ook aansprakelijk bent voor eventuele bugs in open source in je product. Dat klopt, maar is een feature en geen bug. Het doet er immers niet toe van wie jij je onderdelen betrekt. Als jij een product op de consumentenmarkt brengt, dan moet het veilig zijn, punt. Je regelt het maar met je leveranciers.

En ja ik weet dat open source licenties allemaal zeggen “wij zijn niet aansprakelijk” en dat is legaal in leverancier-afnemer relaties (dus met de producent van zo’n apparaat). Maar dat betekent alleen dat die producent een risico neemt door met open source te werken.

Dus goed nieuws wat mij betreft; nu wel doorpakken en daadwerkelijk de ACM laten optreden tegen brakke Internet Der Dingen-apparaatjes.

Arnoud

Deel dit artikel

  1. Dat de staatssecretaris dat vindt is mooi, maar dat wil niet zeggen dat de rechterlijke macht dat ook vindt. Ik mag hopen dat die zich niets aantrekt van wat de staatssecretaris vindt.

    Dus eigenlijk is dit een mening van iemand die er niets over te zeggen heeft. Waarde…?

    Bovendien is dit verbintenissenrecht, dus tussen twee partijen. Er moet wel eerst schade zijn bij de tegenpartij. 6:185 BW is geen basis om op te treden tegen maatschappelijke schade, en al veel minder tegen de mogelijkheid daarvan.

    • Ik mag hopen dat die zich niets aantrekt van wat de staatssecretaris vindt.
      De staatssecretaris kan bij een wet toch een inlegvelletje stoppen met hoe e.e.a. geinterpreteerd moet worden door rechters? En als ze daar niet in mee gaan, kan hij altijd nog de wet aanpassen en het hier expliciter in zetten. Ik denk dat de mening van de staatsectretatis behoorlijk relevant is.

      • No way kan hij een inlegvelletje toevoegen. We hebben scheiding der machten, weet je nog.

        De wetgevende macht moet maar zorgen dat de wetten goed zijn, niet de rechtsprekende macht vertellen hoe ze de wet moeten interpreteren.

        Hij kan inderdaad de wet aanpassen als het parlement akkoord gaat. Dan moet hij dat maar doen, ipv met inlegvelletjes te werken.

  2. nieuw is wel de expliciete opmerking dat er ook aansprakelijkheid bestaat “als de software niet voldoet aan de veiligheid die is overeengekomen of die de afnemer redelijkerwijs mocht verwachten

    Het lijkt mij bijvoorbeeld wel logisch om minimaal 2 jaar security updates te verwachten op mobiele producten. Inclusief alle goedkope telefoons en goedkope tablets.

  3. Vragen van een leek….

    Hoe interpreteer je “op grond van de stand van de technische kennis op het tijdstip waarop hij de software leverde”? Een website die SQL-injectie toelaat is per definitie fout, want dat is toch echt ‘common knowledge’. Maar een klein gaatje in Windows waardoor bijvoorbeeld ransomware via een email programma toegang tot alle bestanden krijgt? Kan MS zich dan verdedigen door te zeggen “Dit is zo klein lekje, dit hadden we nooit verwacht op grond van de technische kennis tijdens levering, en redelijkerwijs nooit zelf kunnen ontdekken.” of mag je zeggen “Als hackers het lek konden vinden, dan had MS het zelf ook moeten vinden, dus dokken maar.”? En dan? Wat is de schade van al je fotobestanden en hobbyprojecten kwijt (data=niets?)? Of kan MS zich dan makkelijk verdedigen door aan te geven dat je maar een backup had kunnen maken, want dat is tegenwoordig ook ‘common knowledge’, want je HD had ook gewoon kunnen crashen.

    Ziet iemand hier op termijn veroordelingen/schadevergoedingen op dit vlak uit rollen?

    Blijft inderdaad over de brakke beveiliging van koelkasten en koffiezetapparaten die een DDOS aanval doen en een bedrijf platleggen.

  4. De stand van de techniek bepaal je door de vakliteratuur en congresverslagen door te nemen… Voor softwarebugs zijn er organisaties (zoals CERT) die openbare lijsten met beveiligingsgaten bijhouden.

    En ja, het is “algemene kennis” dat het verstandig is om regelmatig een backup van jouw gegevens te maken. Als je daarin nalatig bent, heeft dat gevolgen voor de hoogte van de schadevergoeding, niet voor de aansprakelijkheid voor de fout.

    Microsoft heeft zijn zaken redelijk op orde met zijn automatische updates, de veiligheidsproblemen zitten tegenwoordig vooral in “embedded systemen” die door de fabrikant niet bijgewerkt worden.

    • Het hangt er denk ik ook vanaf over wat voor fout je het hebt. Een fout in het ontwerp, waarvan op datum van uitbrengen algemeen gedacht werd dat het een veilig ontwerp was. Of een buffer overflow foutje dat na 10 jaar ontdekt wordt. Dat eerste lijkt mij niet de aansprakelijkheid van de leverancier, dat laatste wel. ook al staat het foutje niet in de CERT lijst.

  5. Dus goed nieuws wat mij betreft; nu wel doorpakken en daadwerkelijk de ACM laten optreden tegen brakke Internet Der Dingen-apparaatjes.

    Ik betwijfel het. Veel IoT projecten ontstaan uit hobbyende elektronica-amateurs die wat in elkaar knutselen en denken dat anderen er ook interesse voor hebben. Een KickStarter project is dan best snel gestart maar op Instructables vind je genoeg andere projecten die je zelf kunt bouwen en die volledig ontworpen zijn door hobbyisten waarvan velen geen kaas hebben gegeten van beveiliging. En ik denk ook niet dat velen weten waar ze wettelijk voor verantwoordelijk gehouden kunnen worden.

    Probleem is gewoon dat hobby-electronica gewoon veel te goedkoop is en er dus heel veel mensen mee kunnen gaan experimenteren en dan van alles maken wat hen handig lijkt. Een WiFi-bestuurde lamp die aangaat als deze beweging detecteert terwijl de zon onder is en meteen ook foto’s maakt van de omgeving om te uploaden naar een web server? Da’s niet nieuw meer. Alleen, die WiFi module is een van de grotere lekken in het systeem en zal dat ook altijd blijven, ook al maken de producenten van die modules deze zo veilig mogelijk.

    Maar goed, hetzelfde probleem zie je ook bij websites. Er zijn teveel amateurs bezig in dit vak die niet begrijpen hoe belangrijk beveiliging is en het vaak gewoon achterwege laten omdat het anders teveel tijd kost om te ontwikkelen. Dus gebruikersnamen en wachtwoorden komen in plaintext in de database en de communicatie gaat over HTTP omdat werken met SSL te moeilijk is. IoT is niet veel anders dan die vele wrakke websites.

    De vraag is dan ook wat de ACM eigenlijk kan doen tegen al dat amateurisme…

  6. En ja ik weet dat open source licenties allemaal zeggen “wij zijn niet aansprakelijk” en dat is legaal in leverancier-afnemer relaties (dus met de producent van zo’n apparaat). Maar dat betekent alleen dat die producent een risico neemt door met open source te werken.

    Dat is wel leuk als er een apparaat-maker als middle-man optreedt, maar hoe zit het tegenover “consumenten” die jouw software direct van jouw site downloaden?

    Niemand kan voldoende financiële middelen of verzekeringen hebben om zich te beschermen tegen de aansprakelijkheid van fouten in open source software: het aantal keren dat de software wordt gekopieerd en gebruikt kent geen grenzen, en de mogelijke schade kent dus ook geen grenzen. Niemand(!) is bereid daarvoor aansprakelijk te zijn. De andere kant van de medaille is natuurlijk dat het nut van open source software ook onbegrenst groot is, door al dat vrije gekopieer. En dat allemaal zonder de maker een vergoeding te geven die zou kunnen dienen als dekking voor aansprakelijkheid.

    Werkelijk het enige dat open source ontwikkelaars kunnen doen is hun best doen om de software zo veel mogelijk foutvrij te maken. Ze kunnen (door de beperkte stand van de techniek) niet garanderen dat de software foutvrij is; ze kunnen niet eens beloven security-fixes te leveren, tenzij ze op de een of andere manier zo’n belofte kunnen financieren. Daar staat tegenover dat de broncode beschikbaar is, dus dat eventuele fouten altijd door anderen kunnen worden opgelost. Er is geen “uiterste houdbaarheidsdatum” waarna support stopt, en er is geen afhankelijkheids-relatie.

    Een consument die open source software gebruikt, of een fabrikant die open source software als component in een product opneemt, zou moeten weten dat ‘ie zelf risico draagt bij eventuele schade door fouten. Voor mensen die dat niet willen zou het mooi zijn als er een soort verzekerings-model zou bestaan voor open source software: elke verzekerde betaalt maandelijks een kleine premie, en krijgt uitbetaald in geval van schade door fouten in de software. De verzekering doet er ook goed aan om het oplossen van fouten te financieren; dit wordt voordeliger naarmate er meer gebruikers van de zelfde software bij de zelfde verzekeraar zitten.

    • Ik wel eens een discussie gehad over fouten in browsers. Hij verdedigde Microsoft en ik hamerde steeds op alle fouten die daar in zaten. Microsoft is zo traag met het oplossen dat hier grapjes over worden gemaakt. Afijn, op een gegeven moment dacht hier iets gevonden te hebben: toen Firefox (ik denk v3) net uitgebracht was zaten er meer bugs in dan bij IE. Ik wees er daarop fijntjes op dat al die bugs twee weken wel (bijna) allemaal waren opgelost, terwijl het aantal bugs bij IE twee jaar later niet was verminderd. Open Source beschouw ik over het algemeen juist als veilige software.

      • Ik ben het helemaal met je eens, maar ik wilde wel even duidelijk hebben dat van aansprakelijkheid van de maker geen sprake kan zijn. Ik heb geloof ik wel duidelijk gemaakt dat er andere mechanismen zijn die de gebruiker van open source software beschermen; concrete afwezigheid van bugs is uiteindelijk toch prettiger dan aansprakelijkheid in geval van aanwezigheid van bugs.

        Je moet mijn post absoluut niet lezen als een waarschuwing tegen gebruik van open source.

    • Als een consument gratis software van internet trekt, dan denk ik dat het wél mogelijk is de aansprakelijkheid van de leverancier op nul te zeggen (art. 6:237 sub f BW, het mag niet zonder goede reden). Productaansprakelijkheid bestaat dan niet want software op internet is geen ‘product’ in de zin van art. 6:185 BW. Dus ik denk dat opensourceontwikkelaars weinig te vrezen hebben van consumentenclaims.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS