Mag Spotify mijn SSD-schijven tot prut reduceren?

| AE 9077 | Internetrecht | 15 reacties

ssd-schijf-opslagOeps. 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 overijverig downloadende gebruikers: dit was een oeps foutje bedankt van Spotify. De nieuwste versie lost het op, maar de schade is niet ongedaan te maken. Kan dat zomaar?

We hebben natuurlijk de productaansprakelijkheid in de wet, en die opent met een veelbelovend artikel:

De producent is aansprakelijk voor de schade veroorzaakt door een gebrek in zijn produkt, tenzij: (…)

Alleen gaat dat ‘gebrek’ vervolgens alleen over fysieke veiligheid, zeg maar ontploffingen en dergelijke. Overmatige slijtage is moeilijk te zien als een veiligheidskwestie, behalve misschien bij autogordels. Bovendien is een app zoals Spotify geen ‘product’ (al dan niet met een k), want dat moet een roerende zaak zijn. Dus daarmee komen we er niet.

Wanprestatie dan. De app doet niet wat je ervan mag verwachten, dus geen conformiteit dus herstel & vergoeding van schade. En ja, dit geldt ook voor software – het Beeldbrigade-arrest van de Hoge Raad bepaalde in 2014 expliciet dat standaardsoftware onder de kooptitel valt en daarmee aan de conformiteitseis moet voldoen. Alleen hm: is er wel sprake van een koop? Je koopt immers niet de app, die krijg je gratis. Je betaalt voor de dienst van Spotify, en dat zie ik als wezenlijk wat anders.

Onrechtmatige daad? Strijd met een wettelijke plicht of inbreuk op een recht, die zie ik niet. Dus dan houd ik over de maatschappelijke zorgvuldigheid, zeg maar dit dóe je gewoon niet. Dit is niet netjes, ook al staat het niet als verbod in de wet. Dat kan altijd, maar sterk vind ik ‘m niet.

Oké, er is een oplossing maar helemaal lekker zit het me niet. Ik vermoed dat dit zo’n ding is waar niemand ooit over nagedacht heeft. Sinds wanneer kan software immers hardware pijn doen (HCF daargelaten)

(Ongetwijfeld staat er in de Spotify EULA iets over geen aansprakelijkheid voor welke schade dan ook, maar ongezien mijn juridische hoela voor zo’n voorwaarde.)

Arnoud

Deel dit artikel

  1. Kleine correctie, het ging om Spotify voor Windows, Mac en Linux en niet om de mobiele apps voor Android of iOS (zie artikel van Ars Technica). De eerste zin klopt dus niet helemaal.

    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.

  2. Ik zie software meestal als “as is” (staat meestal ook zo in de licentie): het is wat het is, en verder heb ik er geen verwachtingen van. Ik probeer altijd zelf uit te zoeken wat voor vlees ik in de kuip heb. Broncode analyseren is natuurlijk veel te veel werk (behalve bij triviale scripts), dus meestal behelp ik me daarbij met handleidingen, en met wat anderen schrijven over de software. Geen wonder dat ik redelijk paranoïde ben: er is vaak een heleboel dat je niet betrouwbaar kunt bepalen aan software, met name bij proprietary software.

    Als je als gebruiker een bepaald belang hebt (bijv. levensduur van je SSD-schijf), dan kan het handig zijn om dat belang af te dwingen. Voor schrijf-volume weet ik het niet, maar voor veel zaken kan het besturingssysteem software in een sandbox draaien die jouw belangen afdwingt. Het zou mooi zijn als dat voor schrijfvolume ook zou kunnen, al zou dat wel betekenen dat Spotify plotseling niet meer werkt. Misschien is een zachte grens een compromis: zodra je de grens bereikt beperk je de schrijf-snelheid. Spotify werkt dan nog wel, maar erg traag. Idealiter zou je dan als gebruiker wat instellingen in Spotify kunnen aanpassen om het wat minder schrijverig te maken. Als alternatief zou je het schrijf-volume van Spotify kunnen verhogen (in de instellingen van het besturingssysteem), maar dat is dan een bewuste keuze waar je als gebruiker zelf maar de gevolgen van moet dragen.

    Weet iemand trouwens hoe ik de levensduur van SD-kaartjes in mijn Raspberry Pi 2 vergroot? Ik heb nu /tmp en /run gemount als tmpfs, /var en /home als partities op een externe harde schijf (geen SSD), en de root partitie (incl. /usr) is met relatime gemount. Toch gaan SD-kaartjes bij mij meestal na een paar maanden up-time al weer kapot. En nee, ik heb geen Spotify op dit apparaat.

      • relatime zou vergelijkbaar moeten zijn met noatime, maar met betere compatibiliteit met bepaalde toepassingen. Het idee is, dat bij een file access de access time alleen wordt aangepast als de oude access time ouder is dan de modify time. Het effect is dan dat je na elke bestandswijziging (sowieso een schrijf-actie) nog hooguit 1 extra schrijf-actie op de access time krijgt. Dus van relatime -> noatime verwacht ik hooguit een factor 2 verbetering.

        Dat zou wel een aardige verbetering zijn, maar eigenlijk word ik pas echt geïnteresseerd als ik minimaal een factor 10 verbetering kan krijgen.

  3. Alleen hm: is er wel sprake van een koop? Je koopt immers niet de app, die krijg je gratis. Je betaalt voor de dienst van Spotify, en dat zie ik als wezenlijk wat anders.

    Ik zou het ermee eens zijn als je Spotify ook zo met andere software kon gebruiken, maar je moet toch de software van Spotify gebruiken om de dienst te kunnen gebruiken? Kun je dan echt spreken van “wezenlijk wat anders”?

  4. “Sinds wanneer kan software immers hardware pijn doen”

    In de jaren ’80 had een vriend van mij een MSX-computer (ik was zelf van de Commodore-64), in die MSX zat kennelijk een relais die schakelde als je van tape ging lezen. Ik bedacht toen dat een klein programmaatje dat steeds een bestand laat openen en weer sluiten na verloop van tijd dat relais kapot kon krijgen. We hebben het voor een paar seconden geprobeerd, het relais ratelde als een machinegeweer. Dat relais zou vast zijn gesneuveld na een wat langere tijd.

  5. Je zegt:

    Onrechtmatige daad? Strijd met een wettelijke plicht of inbreuk op een recht, die zie ik niet.
    Wellicht kan ik ECLI:NL:HR:1996:ZC2221 in herinnering brengen. Een rozenkweker kocht een (naar later bleek vervuild) bestrijdingsmiddel. Aanvankelijk gingen alle parasieten dood, later ook de rozenstruiken. De Hoge Raad oordeelde:
    het in het verkeer brengen van een produkt dat bij normaal gebruik voor het doel waarvoor het — naar in deze zaak niet is bestreden — bestemd was, schade veroorzaakt als hier aan de orde is, [is] onrechtmatig
    Daar komt bij dat bug in juni is gemeld op het officiële supportforum, maar pas in november gerepareerd. Zulke laksheid helpt zowel bij de onrechtmatigheid als bij de toebedeling van de schade. Ik zie zo’n zaak daarom wel kansrijk, maar de schade is alleen niet zo groot. Hooguit 10 euro per persoon. Daar kun je in Nederland niks mee.

  6. Ik betoog dat hier wel sprake is van een wanprestatie. Er is sprake van een wanprestatie wanneer een partij tekortschiet in de verplichting die hij is aangegaan. Hiervoor hoeft geen sprake te zijn van wederkerigheid. Een verbintenis kan ten slotte prima aangegaan worden om niet. Het uitsluiten van aansprakelijkheid zal niet kunnen omdat dit stuit op de zwarte en/of grijze lijst.

  7. “Sinds wanneer kan software immers hardware pijn doen” In de tijd van de Amiga gingen er al verhalen over het oververhitten van chips of kapot maken van floppydisks of -drives. Door software. Het Stuxnet virus was speciaal ontworpen om Iraanse centrifuges te beschadigen. Er waren virussen rond die bios- of andere firmware kunnen overschrijven. Er wordt zelfs gespeculeerd over de de sluizen van stuwdammen waarvan de regelsystemen ook een aansluiting hebben op het internet.

    Geldt daarvoor dan ook: Software is een dienst en geen fysiek product, dus dan gelden voor de aangerichte schade héél andere regels?

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