Kun je Microsoft aansprakelijk stellen voor schade uit een ransomware-aanval?

| AE 9521 | Aansprakelijkheid, Software | 25 reacties

De computersystemen zijn nog steeds niet bruikbaar, zo liggen beide containerterminals van APM in de Rotterdamse Haven nog steeds stil. Dat las ik bij Bright. De ransomware Petya wist vele computers te gijzelen in de IT-omgeving van de Haven, en dat is niet eenvoudig op te lossen. De reden blijkt een bug in Windows, die al tijden bij de NSA bekend zou zijn maar nooit gemeld is. Is er nu enige mogelijkheid Microsoft aansprakelijk te stellen voor de schade van zulke downtime?

Het makkelijke antwoord is natuurlijk nee, want in de voorwaarden van Microsoft staat gewoon dat ze niet aansprakelijk zijn voor de gevolgen van fouten in hun software. En ja, dat is rechtsgeldig bij grote partijen zoals de Rotterdamse Haven. Bij consumenten in principe niet, tenzij er heel bijzondere omstandigheden zijn (zoals, blijf ik volhouden, wanneer de software gratis beschikbaar werd gesteld).

Maar goed, wat in het hypothetische geval dat er geen rechtsgeldige beperking van aansprakelijkheid was. Dan zou het kunnen. Wel moet er dan aan een aantal eisen zijn voldaan. Kort gezegd is de belangrijkste vraag of Microsoft deze fout had moeten voorkomen, vanuit hun zorgplicht als dienstverlener. Of iets anders geformuleerd, of je het Microsoft kunt aanrekenen dat die fout erin zat (toerekenbare tekortkoming).

Ik denk dat je daar in het algemeen niet meteen van kunt spreken, tenzij men de fout kende en deze dan onnodig lang liet liggen. Alle software heeft fouten, zeker zulke grote en complexe software als Windows. Het is onvermijdelijk dat er dan van tijd tot tijd een exploit opduikt die mensen schade berokkent.

Verder, zelfs als je uitkomt bij een toerekenbare tekortkoming of verzaken van de zorgplicht, dan nog heb je altijd het verweer “waarom had je geen backup” of andere maatregelen ter beperking van de schade. Want anno 2017 behoort iedereen te weten dat je je systeem goed moet afschermen voor onheil van buitenaf, en dat je je data moet backuppen om terug te kunnen na een geslaagde aanval. Het voelt weinig redelijk om je bedrijfsdata kwijt te spelen door een aanval en dan Microsoft de rekening te geven.

Bij consumenten blijf je zitten met het probleem dat zij juridisch gezien meestal geen schade hebben. Zet maar eens een geldbedrag op het gegijzeld hebben van je vakantiefoto’s of persoonlijke administratie. En zonder schade geen claim.

Arnoud

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

Moeten we echt elk jaar de copyrightvermelding in onze broncode updaten?

| AE 9248 | Software | 23 reacties

Een lezer vroeg me:

Alle broncodes binnen ons bedrijf hebben een copyrightvermelding, als volgt:
Copyright © 2016 $NAAM
THIS SOURCE CODE IS THE UNPUBLISHED AND CONFIDENTIAL PROPERTY OF $NAAM<
AND MAY NOT BE COPIED, MODIFIED OR DISTRIBUTED WITHOUT PRIOR WRITTEN AUTHORIZATION.
(Iets ingekort in verband met leesbaarheid.) Nu moet ik al die notices aanpassen want het is 2017. Kan dat echt niet anders?

Vrijwel alle broncode heeft een copyright notice, maar juridisch is dat eigenlijk nergens voor nodig. Heel formeel bestaat een copyrightvermelding uit drie elementen, in deze volgorde:

  • Het woord "copyright", de afkorting "copr." of het C-in-een-cirkel symbool ©. Allebei is dus eigenlijk dubbelop, en wie "(C)" doet is eigenlijk fout bezig.
  • Het jaar van eerste publicatie van het werk. Als het gaat om een aangepaste versie, dan moeten de jaren van elke wijziging ook worden vermeld. Zo geeft "1985, 1987-1989" bijvoorbeeld aan dat het werk gemaakt is in 1985 met wijzigingen in 1987, 1988 en 1989. Onze vraagsteller hoeft dus niet álle bestanden aan te passen, maar alleen bij de eerste wijziging in 2017 dat jaar toe te voegen.
  • De naam van de auteur. Dit mag een afkorting of pseudoniem zijn, zolang de auteur maar te identificeren is. In dit geval mag de statutaire naam worden gevoerd, of een andere handelsnaam die het bedrijf gebruikt.

Het punt is alleen dat geen enkele wet een copyrightvermelding eist als voorwaarde om auteursrecht te hebben op die software. Auteursrecht ontstaat namelijk enkel door het werk te maken, ongeacht wat er bij staat aan naams- of copyrightvermeldingen.

In de VS was het tot 1978 wél verplicht om zo'n vermelding te doen, anders was je werk niet beschermd. Maar juristen zijn een conservatief stel mensen, en bovendien het stáát heel juridisch dus laten we het maar doen. Cargo culting dus. Hetzelfde geldt voor all rights reserved.

Een naamsvermelding van de rechthebbende is natuurlijk wel zo handig, en een waarschuwing dat zonder licentie deze broncode niet mag worden verspreid kan ook geen kwaad. (Alleen graag zonder hoofdletters, dat leest beter.) Het is dus prima om vanaf nu "Copyright $NAAM" zonder jaartal te doen, dan hoef je er nooit meer aan te komen (tenzij je de auteursrechten verkoopt uiteraard.)

Arnoud

Mag Spotify mijn SSD-schijven tot prut reduceren?

| AE 9077 | Internetrecht | 15 reacties

Oeps. De afgelopen vijf maanden (zo niet langer) heeft de Spotify app zo hard staan schrijven naar de ssd-schijven in telefoons dat deze járen aan levensduur zijn kwijtgeraakt. Dat las ik bij Ars Technica. Frequent schrijven naar ssd schijven is serieus Niet Handig aangezien dat voor grote slijtage zorgt. En nee, het ging niet om… Lees verder

Ben ik nog aansprakelijk als ik het IE op mijn software overdraag?

| AE 9038 | Aansprakelijkheid, Software | 8 reacties

Een lezer vroeg me: Voor een klant heb ik maatwerksoftware ontwikkeld. Zij willen nu het intellectueel eigendom daarop verkrijgen. Op zich prima, alleen wil ik dan geen aansprakelijkheid meer voor fouten. Ik heb er dan immers geen controle meer over. Daar reageerden ze heel verbaasd op. Maar dit is toch geen gekke vraag? Nee, een… Lees verder

Je bent als bedrijf aansprakelijk voor stiekem geïnstalleerde software door je werknemer

| AE 8865 | Arbeidsrecht, Software | 28 reacties

Een werkgever is aansprakelijk voor illegale software geïnstalleerd door een werknemer, en daarbij maakt het niet uit of dat expliciet verboden was door de werkgever. Dat maak ik op uit een recent vonnis (via) van de rechtbank Rotterdam. Er is sprake van zogeheten risico-aansprakelijkheid: ongeacht wat je doet, je draait op voor eventuele inbreuken op… Lees verder

Mag een browserextensie je waarschuwen voor oplichters?

| AE 8707 | Meningsuiting, Software | 20 reacties

Afgelopen maand heb ik in de avonduren een chrome extensie ontwikkeld die op elke webpagina zoekt naar IBAN, telefoonnummer, e-mailadressen, las ik (dank, tipgever) bij Gathering of Tweakers. De poster was slachtoffer van oplichting geworden en ontdekte dat hij dit had kunnen voorkomen door even dergelijke gegevens door Google te halen. Vandaar de extensie: de… Lees verder

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Contracten, Open source, Software | 11 reacties

Een lezer vroeg me: Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen? De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT… Lees verder

Mag je systemen testen met productiedata met persoonsgegevens?

| AE 8523 | Privacy, Software | 8 reacties

Een lezer vroeg me: Bij mijn laatste klant kreeg ik te horen dat ik bij de update van hun software wel mag testen, maar alleen met nepgegevens. Het argument was dat hun klanten geen toestemming hadden gegeven voor gebruik van hun data voor testdoeleinden. Deed ik dat toch, dan zouden ze de boetes wegens datalekken… Lees verder

Hoe een merkenclaim tijdelijk het internet stukmaakte

| AE 8525 | Auteursrecht, Merken, Open source, Software | 23 reacties

Whoa. Elf regels code weghalen leidde tot een stukgegaan internet, las ik bij BusinessInsider. Dit was het onverwachte gevolg van een merkenclaim van sociaal netwerk Kik tegen softwaremodule Kik. Op basis van die claim werd de module weggehaald, waar de developer zo boos over werd dat hij al zijn code weghaalde. Waaronder dus die ene… Lees verder