De softwarebijsluiter

04 December 2015
Categorie:
669

In deze blog poneer ik een idee om het geprogrammeerde gedrag van fysieke producten, door middel van software, meer transparant te maken en daarnaast stel ik een mechanisme voor om leveranciers te stimuleren hun afspraken en beloftes na te komen.

 

Bij gesloten source software weet je niet helemaal zeker of het beloofde gedrag van de software overeenkomt met het werkelijke gedrag van de software. Het schrijven van goede en toekomstvaste software zie ik nog steeds als kunst, met als basis een gedegen en ethisch verantwoord vakmanschap. We spreken in dit verband ook wel van ’Security, Privacy and Continuity (SPC) by Design’. Want naast het beloofde gedrag van de software wil je ook graag dat de software betrouwbaar functioneert. Zelfs zonder dat je hier expliciet om hoeft te vragen.

 

Tegenwoordig bevatten fysieke producten ook steeds meer ingebouwde software. Denk hierbij aan mobiele telefoons, auto’s, medische apparatuur, horloges, energiemeters, huishoudelijke apparatuur, kleding, enz. Deze software staat in toenemende mate via internet in verbinding met de “schepper” van deze software. Zeker nu deze fysieke producten steeds meer sensoren bevatten die bijna alles kunnen meten en deze informatie opslaan in Big data-oplossingen, lijken wij niet meer te ontkomen aan “Big Brother is watching you”. Er zijn voorbeelden genoeg van software die niet is ontworpen volgens de principes van SPC by Design:

Behoefte aan SPC by Design

Behoefte aan Security: Een programmeur die bij een financieel pakket de bedragen net iets afwijkend afrondt, het voordeel optelt en op regelmatige basis geautomatiseerd naar zijn eigen rekening overboekt. Of het neerstorten van een Europese raket omdat de verschillende versies van de softwaremodules in deze raket niet goed bleken samen te werken met een vernieuwde versie van deze raket.

Behoefte aan Privacy: Appjes op mobiele apparaten die privacy gevoelige informatie doorspelen naar commerciële partijen. Of een online apotheek die, zonder dat klanten dit weten, hun medische gegevens doorspeelt aan andere commerciële partijen.

Behoefte aan Continuity: Een autofabrikant die zogenaamde sjoemelsoftware inbouwt om auto’s onterecht te laten voldoen aan strengere milieueisen. Gegeven de imagoschade en vertrouwensbreuk bij overheden en consumenten een rechtstreekse aanslag op de continuïteit van de levering van dergelijke auto’s.

 

De bovenstaande problematiek wordt steeds nijpender omdat leveranciers steeds meer op een mondiaal niveau opereren en hun hoofdkantoor vestigen in het land waar de beste deals zijn te sluiten. Terwijl de wetgever meestal op landelijk niveau werkt en niet over de kennis en de middelen beschikt om het fysieke product, inclusief de ingebouwde software, op zijn merites te beoordelen.

 

Het ongeldig verklaren van de Safe Harbour Act helpt hier niet bij. Met de Safe Harbour Act was er overeenstemming tussen Europa en de Verenigde Staten over de bescherming van de privacy van Europese burgers. Door het ongeldig verklaren ontbreekt nu een wettelijke bescherming voor de uitwisseling van persoonsgegevens.

 

Leveranciers van fysieke producten met ingebouwde software hebben daarom een ander soort incentive nodig om dan toch te leveren wat zij beloven, zonder ongewenste bijwerkingen. En hiermee hebben we een mooie brug geslagen naar de medicijnindustrie waarbij ieder medicijn een zogenaamde bijsluiter kent en een overzicht wordt gegeven van ongewenste bijwerkingen die zich mogelijk voor kunnen doen.

De introductie van de softwarebijsluiter

Wat te denken van een softwarebijsluiter voor fysieke producten, een document waarin de leveranciers de (alle) mogelijke bijwerkingen van de ingebouwde software moet benoemen. Vertoont de software ander gedrag dan in de bijsluiter als mogelijke bijwerking is benoemd? Dan kan de leverancier hierop worden aangesproken en aangeklaagd. Een dergelijke softwarebijsluiter schept uiteraard verplichtingen in het leven, maar heeft ook voor alle partijen voordelen:

 

  • De consument is de grootste winnaar, want die kan een betere aankoopbeslissing nemen op basis van een begrijpelijke en korte bijsluiter. Daarnaast is er een grotere kans dat het product betrouwbaar functioneert zonder ongekende neveneffecten. De consument heeft hierbij wel de plicht om te softwarebijsluiter te lezen en te begrijpen;
  • De overheid heeft als voordeel dat het verrassingseffect van ongewenst en onverwacht gedrag kleiner is, want incomplete bijsluiters leiden onherroepelijk te vervolging en schadeloosstellingen. De overheid heeft hierbij wel de verantwoordelijkheid om de softwarebijsluiter bijvoorbeeld voor heel Europa verplicht te stellen;
  • De leverancier heeft als voordeel dat er helderheid wordt geschapen in de verwachtingen met zowel klanten en overheden, maar heeft daarbij de plicht het spel netjes te spelen.

Verder onderzoek

Kan de softwarebijsluiter alle probleemgevallen hierboven genoemd bij “Behoefte aan SPC by Design” oplossen? Ik heb het idee van niet. Vandaar dat het principe van “SPC by Design” mijn inziens het uitgangspunt moet zijn voor alle belangrijkste veranderingen. Vandaar dat ik aanvullend op deze blog over de softwarebijsluiter nog een blog ga wijden aan “SPC by Design”.

De softwarebijsluiter heeft nog een aantal uitzoekpunten waar volgens mij een hele mooie afstudeeropdracht of promotieonderzoek aan kan worden gewijd op het snijvlak van Europese wetgeving en ICT.

Vragen die hierbij onder andere aan de orde zijn:

 

  1. Moet de softwarebijsluiter alleen aanwezig zijn voor fysieke producten of ook voor software producten?
  2. Hoe kan een softwarebijsluiter helpen om kwade opzet te voorkomen dan wel te ontmoedigen?
  3. Kan de softwarebijsluiter vrijwillig worden geïntroduceerd, net als een webwinkel keurmerk, of juridisch afgedwongen via bijvoorbeeld Europese wetgeving?
  4. Hoe voorkom je dat machtige leveranciers een grote lobby gaan starten om harde garanties, van de softwarebijsluiter, voor de consument teniet te doen?

 

Met veel liefde en aandacht wil ik de afstudeerder of promovendus begeleiden die bereid is zijn of haar tanden te zetten in dit vraagstuk.

 

Met dank aan Ewald Jansen, Irene de Leeuwerk, Klaas Zondervan, Michail Theuns en Sanne Kuijpers voor hun constructieve inbreng bij het schrijven van deze blog.

Auteur

Ben Elsinga