In
september heeft de Europese Commissie haar voorstel gepubliceerd om
productaansprakelijkheidsregels in te voeren voor beveiligingsfouten in
software, de zogenaamde Cyber Resilience Act (CRA). Hoewel dit niets te
vroeg komt en de Commissie duidelijk veel aandacht heeft besteed aan de
vrije en open source ecosystemen die ten grondslag liggen aan de meeste
van onze huidige informatiesystemen, heeft het eindresultaat
fundamentele gebreken die in het wetgevingsproces hersteld zullen moeten
worden.
Update: nu ook met antwoord op laatste consultatie van de Europese Commissie over dit voorstel.
Doel en karakter van de voorgestelde verordening
Zoals gezegd had de invoering van aansprakelijkheidsregels voor beveiligingslekken in software al veel eerder moeten plaatsvinden. Dit is het belangrijkste doel van het voorstel: ervoor zorgen dat degenen die "digitale producten" maken, waaronder software, aansprakelijk worden gesteld als zij onzorgvuldig handelen als het gaat om beveiligingslekken. Een onderwerp wat dringend en goed geregeld moet worden, in die zin is het heel goed dat dit eindelijk op de wetgevingsagenda staat. Qua karakter is dit voorstel gemodelleerd naar bestaande Europese modellen voor productconformiteit, waarvan de CE-markeringen op veel producten in de praktijk het meest zichtbaar zijn. Dit is meteen een zorgpunt, aangezien software niet noodzakelijkerwijs in dezelfde competitie zit als USB-laders. Daarom enkele concrete suggesties om dit voorstel te verbeteren.
Software als (artistieke) uitingsvorm
Allereerst zou het voorstel expliciet moeten erkennen dat software, vooral software waarvan de licenties expliciet het recht op inzage en verbetering van de broncode erkennen, een uiting is die onder de uitingsvrijheid valt. Dit betekent dat wanneer de Europese wetgever software reguleert, zij een beter evenwicht moet vinden tussen de verschillende grondrechten die in het geding zijn dan het geval is bij louter conformiteitsregelgeving voor producten. Het is geen goede wetgevingstechniek om dit in de overwegingen te doen en het niet uit te breiden in de inhoud. Het is altijd een kernbeginsel van de Europese mensenrechten geweest dat inmenging in grondrechten zoals de vrijheid van meningsuiting duidelijk wettelijk moet worden afgebakend. Eenvoudig gezegd: beperkingen van de vrijheid van meningsuiting moeten voor de burgers kenbaar en voorspelbaar zijn. Overwegingen in wetteksten zijn daarvoor niet goed genoeg, evenmin als het overdragen van de bevoegdheid tot het maken van gedelegeerde handelingen aan de Commissie om verder in te grijpen in deze specifieke vrijheid zonder een expliciet evenwicht te vinden tussen dit grondrecht en de urgentie van het maatschappelijke doel om informatiebeveiliging te verbeteren.
Onduidelijke definities in de CRA
Ten tweede definieert het voorstel het begrip "commerciële activiteit" dat activiteiten met behulp van open source software die typisch als niet-commercieel worden opgevat maar onder deze definitie van commerciële activiteit zouden vallen. Als bijvoorbeeld een kleine maatschappelijke organisatie open source gebruikt om mensen in staat te stellen een RSVP in te dienen voor een van hun evenementen (een SaaS-oplossing, volgens het voorstel), zou dit onder de definitie van commerciële activiteit van de CRA vallen. Het ligt voor de hand dat die organisatie de persoonsgegevens van de deelnemers aan het evenement conform de AVG moet beschermen. Volgens de voorgestelde tekst van de CRA zou de NGO daarbij verplicht zijn een CE-markering (verplichte conformiteitsmarkering voor de regulering van de binnen de Europese Economische Ruimte verkochte goederen) te verkrijgen voor de gebruikte software, wat het gebruik van dergelijke software in de praktijk vrijwel onmogelijk zou maken.
Nog afgezien van het feit dat de slecht geplaatste definitie van commerciële activiteit in de overwegingen cirkelredeneringen bevat van het type dat, als het bij software zou voorkomen, als een verborgen gebrek zou worden beschouwd. In de regel zijn CE-markeringen geen geschikt instrument in de context van stand-alone software. En zelfs in de context van embedded software zijn er problemen die zich doorgaans niet voordoen bij andere aspecten van fysieke producten. Vooral omdat goed onderhouden software updates en patches omvat die geen equivalent hebben in de fysieke wereld en voor een veel dynamischer situatie zorgen dan de certificatieprocessen voor CE-markering toelaten.
Hoeveel verordeningen over productaansprakelijkheid voor software hebben we nodig?
Ten slotte voegt de CRA een nieuwe set regels toe aan een reeks Europese verordeningen en richtlijnen die het concept van productaansprakelijkheid voor software in het algemeen bestrijken. Hoewel het begrijpelijk is dat software in motorvoertuigen en in medische apparatuur onder verschillende regelgevingen vallen (beide zijn specifiek vrijgesteld van de voorgestelde CRA), kunnen diezelfde stukken code ook in diverse andere sectoren worden gebruikt op manieren die de maker niet kon voorzien.
Er zijn tal van instrumenten, bibliotheken en stukken software die onder open source-licenties beschikbaar worden gesteld, vaak door kleine bedrijven of kleine groepen ontwikkelaars, die in de praktijk onder de CRA zullen vallen en/of onder diverse sectorale regelingen, de komende algemene productaansprakelijkheidsverordening en mogelijk ook de EU AI-act en de EU AI Liability Act.
Dit creëert rechtsonzekerheid voor ontwikkelaars en zal zeker een remmend effect hebben op juist die ecosystemen die vaak over het algemeen verantwoordelijker hebben gehandeld bij het aanpakken van beveiligingslekken in hun software dan bij klassiek gelicenseerde software het geval pleegt te zijn.
