Tag: Software

About Software

Subscribe Feeds

Geen nieuwe Linux-versies meer van aangiften LH en Vpb, mag dat?

Geplaatst op in Informatiemaatschappij, 20 reacties

Gebruikt u voor het doen van de aangifte loonheffingen of vennootschapsbelasting de Linux-versie? Met ingang van volgend jaar kan dat niet meer. Dat las ik bij de Belastingdienst. “We hebben besloten geen Linux-versies meer te maken, omdat deze bijna niet gebruikt worden.” zo gaat het verder. Linuxgebruikende ondernemers zullen dus een Windows- of Mac-emulator moeten installeren of blijven hobbelen met de huidige versie, tenzij ze een accountant hebben die wel met Windows of Mac kan werken. Hoewel het dus kennelijk maar een kleine groep is, lijkt het me wel behoorlijk vervelend. En ik dacht dat de overheid het gebruik van open source wilde stimuleren?

Sinds 2012 is het voor ondernemers verplicht om digitaal belastingaangifte te doen. Het gaat daarbij onder meer om de aangifte omzetbelasting, de loonheffingen, de inkomstenbelasting en de vennootschapsbelasting. Ontheffing is daarbij niet mogelijk, ongeacht reden (dus ook niet als je internet een poel des verderfs vindt).

Helaas maakt de wet niet duidelijk op welke manier dat ‘langs elektronische weg’ precies wordt ingevuld. Dit wordt dan ook aan de Belastingdienst overgelaten. Die doet haar best om de bekendste platforms te ondersteunen, en daar rekende zij lange tijd Linux ook onder. Maar al in 2007 was het probleem dat daar nauwelijks gebruik van gemaakt werd. Toen ging het om 6.589 van 5.7 miljoen particulieren, helaas kan ik nu geen cijfers vinden over dat gebruik.

Omdat er dus geen harde eis is over welke platforms te ondersteunen, is het in principe een vrije keuze van de Belastingdienst om te bepalen voor welke platforms zij haar software wil aanbieden. En het lijkt me redelijk dat je zegt, een platform dat vrijwel niet wordt gebruikt (aantoonbaar met je historische aangiftestatistieken) dat ondersteunen we niet meer, dat kost meer dan het oplevert. Dat strookt niet met het streven om open source te populariseren, maar als je het jaren probeert en niemand gaat met je mee, dan moet je er misschien mee stoppen?

Arnoud

Wanneer is het hebben van een Remote Acces Tool en een Keylogger strafbaar?

Geplaatst op in Regulering, Security, 22 reacties

In december werd een man veroordeeld voor het voorhanden hebben en verspreiden van Blackshades software. De rechtbank merkte dit aan als medeplichtigheid tot computervredebreuk, omdat deze software gebruikt kan worden om een inbraak in andermans computer te vergemakkelijken. Wat diverse lezers ertoe bracht om me te vragen, hoezo is het strafbaar om die software te hebben? Er zijn zo veel tools voor remote access, hoe moet je nu weten wanneer dat wel of niet strafbaar is?

Het enkele feit dat software geschikt is voor remote access maakt deze natuurlijk niet meteen een hulpmiddel voor computervredebreuk. De wet spreekt van “ontworpen of geschikt gemaakt” voor het misdrijf (art. 139d lid 2 Strafrecht), en niet alle binnengaan of binnendringen in andermans computer is een misdrijf. Een ICT-bedrijf kan immers prima legaal bij de klant zijn computer binnengaan om onderhoud te plegen onder een contract, of op verzoek inloggen om een probleem te herstellen.

Dergelijke software kan ook door criminelen worden gebruikt om stiekem bij mensen binnen te dringen, en dan bijvoorbeeld data te gijzelen of te verkrijgen, of om de computer als springplank voor een aanval elders te gebruiken. Dat zijn misdrijven.

Hoe zie je dan het verschil? Zoals ik wel vaker zeg, dat zie je aan de intentie van hoe de software wordt vermarket en hoe deze in de markt bekend staat. De software Blackshades staat bekend als hackingtool:

Blackshades is the name of a malicious trojan horse used by hackers to control infected computers remotely. The malware targets the computers using Microsoft Windows -based operating systems. According to US officials, over 500,000 computer systems have been infected worldwide with the software. … Blackshades infects computer systems by downloading onto a victim’s computer when the victim accesses a malicious webpage (sometimes downloading onto the victim’s computer without the victim’s knowledge, known as a drive-by download) or through external storage devices, such as USB flash drives.

De rechtbank is dan ook van oordeel dat de Blackshades software hoofdzakelijk is ontworpen om het plegen van computervredebreuk mogelijk te maken. Daarmee is bezit van deze software dus strafbaar. Dat de software ook gebruikt kan worden voor legale activiteiten is dan niet relevant; het gaat erom of hij hoofdzakelijk bedoeld is voor illegale zaken. En gezien hoe deze software algemeen bekend staat, en het soort features dat aan boord is, is dat hier dus het geval.

De verdachte wilde zich aansluiten bij de reeds bestaande Blackshades organisatie, en kreeg dat op zeker moment ook voor elkaar. Bovendien had hij wetenschap van alle functionaliteiten en illegale mogelijkheden van deze software. Dat maakt hem ook strafbaar voor het voorhanden hebben van die software, én voor medeplichtigheid aan misdrijven zoals binnendringen en denial of service aanvallen.

Arnoud

Van wie is samen geschreven software eigenlijk?

Geplaatst op in Intellectuele rechten, 19 reacties

Een lezer vroeg me:

Samen met een kennis werk ik al geruime tijd aan een stuk software, dat we gebruiken voor een betaalde webdienst. Nu overweeg ik ermee te stoppen, want ik heb privé andere prioriteiten. Ik heb de bulk van het werk gedaan, maar mijn partner ook best aardig wat. Hoe moeten wij dit regelen, aan wie komen deze rechten toe?

Hoofdregel van de Auteurswet is dat de rechten liggen bij de partij die het creatieve werk heeft gedaan. Als twee mensen werk doen, dan ontstaan er dus twee auteursrechten naast elkaar. Ieder van de ontwikkelaars mag dan beslissen wat hij of zij daarmee doet.

Althans in principe, want je moet in alle redelijkheid wel rekening houden met de belangen van de ander. Dit is altijd een heel gedoe om achteraf recht te trekken, zeker als mensen met ruzie uit elkaar gaan. Het is dus veel beter dit vooraf te regelen, of zoals deze vraagsteller het netjes op het moment zelf te willen uitzoeken.

Iets ingewikkelder wordt het als het werk van de twee niet goed los te weven is. Er is dan namelijk sprake van een gemeenschappelijk auteursrecht, één recht dat aan beide ontwikkelaars toekomt. Dat kun je niet zomaar verdelen, je bent er samen eigenaar van. Hier moet dus worden afgesproken wie van de twee het recht meeneemt – en natuurlijk wat de ander er dan nog mee mag doen.

Als een van de twee ermee stopt, dan is het makkelijk. Je spreekt dan af (schriftelijk en met handtekening) dat alle rechten naar de voortzettende partner gaan, en waarschijnlijk zal de stoppende partner dan een afkoopsom ontvangen of een laatste winstuitkering. Je hoeft je dan denk ik geen zorgen te maken over licenties aan de stoppende partner, hij ging immers stoppen.

Willen beiden uit elkaar en apart hetzelfde gaan doen, dan wordt het ingewikkelder. Degene met de rechten staat net wat sterker dan degene die alleen een licentie krijgt om onder die rechten óók te opereren. Je kunt natuurlijk keiharde afspraken maken, maar wat doe je dan als er toch ruzie komt of de partij met rechten verkoopt die aan een derde? Om die reden kan het interessant zijn om in dat geval alle rechten gemeenschappelijk te verklaren, zodat je beiden van elkaar afhankelijk blijft.

Arnoud

Mag je onder de cookiewet bloatware vooraf installeren?

Geplaatst op in Privacy, 2 reacties

Een lezer vroeg me:

De cookiewet bepaalt dat cookies niet mogen worden geplaatst zonder expliciete toestemming van de gebruiker. Het juridische begrip cookies is veel ruimer dan het technische begrip cookies, ook scripts en programma’s vallen eronder. Wat betekent dit voor bloatware? Dat is ongewenste software die al op de computer staat bij aankoop. Waarom is dat geen ‘plaatsen van software’?

De cookiewet (artikel 11.7 Telecommunicatiewet) is inderdaad veel breder dan alleen cookies. Deze wet bepaalt dat er geen informatie mag worden gelezen of geplaatst op iemands randapparatuur (computer, telefoon, tablet) via een telecommunicatienetwerk zonder toestemming. Ongeacht of het met privacy te maken heeft. Dus ook een stiekeme update aan je software is niet toegestaan.

Dit wetsartikel kent ook het geval waarin “op een andere wijze dan door middel van een elektronisch communicatienetwerk” informatie wordt gelezen of geschreven. Ook dat is niet toegestaan. De memorie van toelichting noemt als voorbeelden usb-sticks, cd-roms of externe harde schijven. Maar wat ik mis, is de situatie “het stond al op het randapparaat toen dat op de markt kwam”. Ik denk dat er gewoon niet nagedacht is over deze situatie.

Afhankelijk van wat die bloatware/software precies doet op je computer, zou je misschien kunnen spreken van verboden uitlezen of versturen van informatie vanaf de randapparatuur. Denk aan software die rapporteert dat ie is geactiveerd, of zelfs gegevens van de computer uitleest en doorstuurt. Maar als die software bij het eerste gebruik een en ander meldt en toestemming vraagt, dan is er verder weinig aan te doen vanuit dit perspectief.

Misschien dat je kunt zeggen, de aanwezigheid van zulke software moet worden gemeld omdat het essentiële informatie is over het product. Wordt het niet gemeld, dan is het product nonconform en kun je je geld terugkrijgen bij de winkel. Dat is misschien nog een effectievere oplossing ook.

Arnoud

Mijn klanten eisen dat mijn ontwikkeltraject AVG proof software geeft, kan dat wel?

Geplaatst op in Ondernemingsvrijheid, Privacy, 17 reacties

Een lezer vroeg me:

Als softwareontwikkelaar krijg ik steeds vaker vragen of mijn software wel AVG proof is. Ik begrijp die vraag en wil mensen ook best tegemoet komen, maar het voelt wel als een hellend vlak omdat ik dan ineens aansprakelijkheden op me neem. Stel ik bouw een exportfunctie van persoonsgegevens niet in, moet ik dan de boete betalen als mijn klant daarop aangesproken wordt?

Heel formeel sprekend heeft een softwareontwikkelbedrijf géén plicht om te zorgen dat hun software aan de AVG voldoet. De AVG stelt regels voor de verwerking van persoonsgegevens, en dat gaat pas spelen bij het in productie nemen van die software. Er is dus niets mis met software waarbij persoonsgegevens niet kunnen worden geëxporteerd, het enige is dat een afnemer die niet in kan zetten in situaties waarin de AVG op hem van toepassing is.

Praktisch gezien ontkom je er niet aan om rekening te houden met de AVG, precies om die reden. Een softwarebedrijf met Nederlandse klanten kan het niet maken om zo’n exportfunctie weg te laten, want zijn klanten voldoen dan gewoon niet aan de wet en hebben dus een groot probleem als ze deze software in gebruik zouden nemen.

De discussie zal dus meer gevoerd worden op hoe ver je moet gaan als developer, en ook waar de kosten komen te liggen. Want dat er een exportfunctie moet zijn is één ding, welke gegevens er wel en niet onder vallen is een heel ander. Daar zijn ook de juristen het nog niet helemaal over eens, bijvoorbeeld. En er zijn nog veel meer dingen: hoe vraag je precies toestemming en hoe makkelijk moet deze in te trekken zijn?

Ik denk dat je er op dit moment dan ook niet aan ontkomt om hier in detail over te spreken met je klant. Dit kan mijn software, dit wil jij erbij, ik weet van de AVG en wat zie jij? (/juf Ank). En dat dan vastleggen in functionele specificaties of test cases, en in het contract opnemen dat jouw verantwoordelijkheid is dat het zal werken zoals vastgelegd.

In de toekomst zie ik meer mogelijkheden. De AVG kent de optie om technologieën voor gegevensbescherming of -verwerking te certificeren. Je zou dan als developer zo’n certificaat kunnen halen, en daarmee je klanten gerust stellen dat ze jou prima kunnen kopen. Eventuele aansprakelijkheid zou dan zeer mee moeten vallen (je bent immers gecertificeerd) en zou wellicht ook nog te verhalen zijn op de certificaatverstrekker. Maar dit zal nog wel een jaar of vijf duren, minstens.

Arnoud

Licentiecodes meenemen van je werk is geen diefstal

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, Regulering, 18 reacties

Een licentiecode meenemen van je werk als je ontslag neemt, is geen diefstal of heling. Dat vonniste de rechtbank Den Haag onlangs. De verdachte in deze strafzaak had ontslag genomen en wilde kennelijk met die licentiecode goede sier maken bij de nieuwe werkgever, iets dat de oude werkgever zó ernstig vond dat men aangifte deed, en bij het OM vonden ze het ook ernstig genoeg om te vervolgen. Maar de rechtbank ziet hier geen diefstal in, omdat een licentiecode immers geen ‘goed’ is dat je kunt stelen.

De precieze reden voor het meenemen kan ik niet uit het vonnis halen, maar ik lees dat diverse werknemers tegelijk ontslag namen en bij de concurrent gingen werken. Deze werknemer had in dat verband die licentiecode voor een Amerikaans softwarepakket naar zichzelf gemaild vanaf het werk. De werkgever kwam hierachter en deed aangifte.

De verdachte werd formeel vervolgd voor het misdrijf bekendmaken van vertrouwelijke informatie (schending van bedrijfsgeheimen). Het is namelijk strafbaar om door misdrijf vertrouwelijke bedrijfsgegevens te achterhalen en bekend te maken (artikel 273 Strafrecht). Dat kan ook gaan om digitale informatie, en bij licentiecodes zie ik wel waarom je die als vertrouwelijk zou aanmerken.

Voor de rechtbank was er echter een principieel bezwaar: welk misdrijf dan? Want de verdachte was op zich gerechtigd in de computer van de werkgever die licentiecode op te vragen, dus er was geen sprake van computervredebreuk.

Je zou dan eerder van diefstal of verduistering moeten spreken, net zoals je het diefstal noemt als een werknemer legaal de kantine in gaat en een zak met koffiebonen meeneemt. Maar voor diefstal (of verduistering) is vereist dat er een ‘goed’ wordt weggenomen. En volgens de jurisprudentie kan dat alleen als het slachtoffer de feitelijke macht over die informatie verliest zodra de dader zich deze toe-eigent.

Bij objecten in virtuele werelden is voorstelbaar dat je spreekt van “feitelijke macht verliezen”. Als speler B dat zwaard te pakken krijgt van A, dan heeft A het automatisch niet meer. Idem voor zeg een bitcoin of een belminuut. Maar bij een licentiecode is daarvan geen sprake. De code is dan op twee plaatsen aanwezig, en twee partijen hebben er dan macht over. Daarom geen diefstal en dus geen strafbaar onthullen van bedrijfsgeheimen.

Op zich een logische uitkomst, zeker als je bedenkt dat de volgende Wet Computercriminaliteit dit expliciet wél strafbaar gaat stellen. A contrario redenerend doe je dat alleen als het nu niet strafbaar is, dus is het nu niet strafbaar.

Arnoud

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

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 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

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 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?

Geplaatst op in Intellectuele rechten, 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?

Geplaatst op in Informatiemaatschappij, 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