Als de software het niet meer doet

Producenten zijn niet de enigen die software (apps) als een product behandelen; ook in bredere maatschappelijke, juridische of sociale discussies wordt software zo afgeschilderd. Ook in het dagelijks leven kijken we er niet van op als een collega zegt een tekstverwerker te gebruiken. Integendeel: zo zouden we reageren als die collega had beweerd documenten met een typemachine te schrijven! Ook het Europees Parlement beschouwt software inmiddels als product in haar recentste richtlijnen. Maar wat is een softwareproduct nu eigenlijk? Wat is die tekstverwerker waarmee we die “gepolijste documenten” kunnen maken?

Voordat we die vraag kunnen beantwoorden, moeten we eerst bepalen waarom we die vraag überhaupt willen beantwoorden. Discussies over software gaan steeds vaker over de impact die software heeft op onze omgeving. Neem als voorbeeld de treinstoring in Rotterdam van juli 2022, waarover ProRail schrijft dat de oorzaak “een probleem in de software [bleek] te zijn”. De software deed niet wat het had moeten doen. Een situatie die ons allemaal bekend zal voorkomen: een tekstverwerker die weigert een figuur in te voegen of steeds laat verspringen. Van een fysiek voorwerp zouden we zeggen dat het een defect vertoont of dat het zijn functie niet vervult. De preciezere vraag die ik wil beantwoorden, luidt dan ook: wat is het equivalent van deze functiedrager wanneer we over software spreken? Aan welk voorwerp schrijft een softwareproducent een schrijffunctie toe? Welk voorwerp gebruiken we om te schrijven en mogen we op onze beurt beoordelen in termen van die functie?

Mijn antwoord op deze vraag is onlangs gepubliceerd in het tijdschrift Synthese. In het artikel beargumenteer ik eerst wat het antwoord niet kan zijn. Vertrekkend van die negatieve resultaten kom ik vervolgens tot een zinnig antwoord op de vraag wat we dan wél als functiedrager moeten aanwijzen.

Stel dat het verkooppraatje van de softwareproducent mij zou overtuigen. Ik open de applicatiewinkel op mijn laptop, zoek naar de tekstverwerker, klik op “koop” en voer mijn wachtwoord in. Een ogenblik later downloadt mijn laptop de software van een server op mijn laptop. Als gevolg krijgt een reeks geheugencellen op de solid state drive (de opvolger van de harde schijf) van mijn laptop een andere lading (of spanning). Deze ladingen stellen code (gegevens, informatie) voor. Ze zijn als inkt op een bedrukte pagina, met het grote verschil dat mensen de informatie op een solid state drive niet direct kunnen aflezen. In tegenstelling tot een typemachine kan ik code niet gebruiken om teksten mee te schrijven. Code heeft noch een invoermechanisme (zoals de toetsen van een typemachine), noch een uitvoermechanisme (hamertjes). Het is dan ook onzinnig om een schrijffunctie aan de code van de softwareproducent toe te schrijven.

Hoewel de code van de tekstverwerker dus niet de functiedrager kan zijn, speelt deze wel degelijk een belangrijke rol bij de totstandkoming van die functiedrager. Softwareproducenten bieden hun code met een reden aan. Net als producenten van fysieke objecten willen ze bijdragen aan een doel, of claimen ze dat althans. Beide producenten verschillen in hoe ze bijdragen aan dat doel. Typemachines en tekstverwerkers helpen ons bij het schrijven van documenten. Maar in tegenstelling tot een typemachine is de code niet als zodanig bruikbaar. De code van een softwareproducent is bedoeld om op een apparaat geïnstalleerd te worden. Of, zoals ik in iets algemenere woorden stel in het artikel: iemand moet eerst een apparaat configureren met de code van de softwareproducent. Pas na die configuratie kunnen we het apparaat voor het beoogde doel gebruiken. De code en de bijbehorende configuratiehandeling zijn alleen nodig wanneer het ongeconfigureerde apparaat zelf niet tot dat doel kan bijdragen. Met andere woorden: het ongeconfigureerde apparaat kan niet de functiedrager zijn. Bij software is de functiedrager dus niet de code, niet het apparaat, maar het apparaat geconfigureerd met de code.

Deze analyse heeft gevolgen voor hoe we dienen om te gaan met ogenschijnlijke softwaredefecten. Als we stellen dat een tekstverwerker niet werkt, doen we in feite een uitspraak over een apparaat dat geconfigureerd is met een bepaalde tekstverwerkercode. Verder onderzoek is nodig om een uitspraak te kunnen doen over de code of het apparaat zelf. Een simpel voorbeeld: stel, de wekker op onze telefoon gaat niet af. Mogen we daaruit concluderen dat de code van de wekkerapp fouten bevat? Het antwoord daarop luidt “nee”. Dit (uitblijven van) gedrag van onze telefoon kan namelijk ook verklaard worden door een defecte luidspreker.

Zo legt de analyse de complexiteit van aansprakelijkheidskwesties bij softwaregebruik bloot. Bij wie leggen we de schuld wanneer het geluid van de wekker (bij correct gebruik) zo luid is dat de gebruiker gehoorbeschadiging oploopt? Bij de softwareproducent, de smartphonefabrikant of iemand anders? Er is immers geen sprake van één fabrikant van één bepaald product, maar van een samenspel van verschillende, vaak onafhankelijk van elkaar ontwikkelde componenten. Naast de code van de softwareproducent is er een apparaat betrokken. Bovendien kan laatstgenoemde zelf ook het resultaat zijn van een configuratiehandeling. Het apparaat waarop we een tekstverwerker installeren, is vaak meer dan een verzameling fysieke componenten: de code van tekstverwerkers is ontwikkeld voor apparaten die reeds geconfigureerd zijn met een bepaald besturingssysteem.

De analyse roept dus ook vragen op. Hoe nauw moeten softwareproducenten de apparaten omlijnen waarop hun code geïnstalleerd mag worden? In hoeverre moeten zij anticiperen op toekomstige apparaten? Welke vrijheden hebben de partijen die de installatie (configuratie) uitvoeren? Wat is de rol van de producenten die betrokken zijn bij de totstandkoming van het apparaat? In welke mate dienen zij bij de introductie van nieuwe apparaten rekening te houden met code die reeds op de markt is gebracht? Daarover later meer.