Moet je als programmeur verstand van rechten hebben? #legaltechtuesday

Vorige week blogde ik Moet je als jurist leren programmeren? en dat gaf vele leuke reacties, waaronder via Linkedin de vraag:

Vice versa, zou je ook kunnen stellen dat software ontwikkelaars enige basiskennis van de juridische praktijk moeten hebben ?
Grappig genoeg hoor je die een stuk minder vaak. Maar de observatie is een hele scherpe, ik denk zeker wel en zelfs méér kennis dan omgekeerd juristen van het programmeerveld.

Dit omdat software steeds vaker gewoon juridische dingen oplost, denk aan het bestellen van producten, het maken van afspraken, het vastleggen van contracten etc. Vaak zie je dat het daar juridisch nét rammelt, of naar Amerikaans voorbeeld gebouwd wordt. En dat is niet alleen irritant voor juristen die het toevallig zien (ik heb tegenwoordig speciale sloffen waar mijn tenen in kunnen krommen) maar ook gewoon kostbaar voor je klant.

Simpel voorbeeld: vrijwel iedere websitebouwer die een bestelformulier of aankoopscherm bouwt, zet daar een vinkje bij waarmee de algemene voorwaarden kunnen worden aanvaardt. Doet iedereen, zal wel moeten en de documentatie legt het ook niet uit. Maar het is fout: zo’n vinkje is helemaal niet nodig om mensen aan je voorwaarden te binden.

Over de AVG en hoe dat uitpakt, daar kan ik een boek over schrijven, zo veel fouten worden daarin gemaakt. Toestemming vragen waar dat niet hoeft, privacyverklaringen laten accorderen, plugins van derden neerzetten en denken dat dat zomaar mag, zo kan ik nog wel even doorgaan. Handig om te weten.

Maar het kan ook subtieler. Denk aan een site waar mensen dingen mogen posten. Natuurlijk kun je dan claims krijgen wegens bijvoorbeeld auteursrechtinbreuk, en daar moet je dan wat mee. (Ook trouwens met privacyclaims en andere dingen.) Maar dat betekent niet dat je zomaar alles weghaalt. Je houdt rekening met de rechten van je gebruikers, zoals wanneer ze een parodie posten of een citaat gebruiken en meer niet. Weten dat dit kan, lijkt me wel het minste dat je van een developer kunt vragen.

Natuurlijk hoef je als ontwikkelaar zeker niet een mr-titel te hebben. Ik denk dat het niet goed mogelijk is om én het IT-veld én het juridische veld allebei goed bij te houden, op het niveau dat beiden eisen als je het echt goed wil doen. Maar de basiskennis, ja die moet er zijn. Programmeren doe je niet in een vacuüm waar anderen juridische lucht in pompen.

Arnoud

Wat mag een werkgever met Sinterklaascadeaus in coronatijd?

Een lezer vroeg me:

Als FG bij ons bedrijf vroeg ik me af hoe we moeten omgaan met Sinterklaas in deze coronatijd. Traditioneel koopt iedereen cadeautjes voor elkaar (lootjes trekken), en koopt de werkgever ook nog iets van een chocoladeletter. Dat mensen elkaars postadres krijgen lijkt me niet de bedoeling, maar mag de werkgever het allemaal opsturen namens de collega’s? Of denk jij dat er toestemming nodig is?
Het is inderdaad zeer niet de bedoeling dat collega’s elkaars postadres (huisadres) krijgen zodat ze Sinterklaascadeaus kunnen opsturen.

Een werkgever mag zijn personeel natuurlijk cadeautjes geven, zeker rond de feestdagen. De AVG vindt het prima als je die dan opstuurt in een tijd van pandemie en/of thuiswerken. Dat valt gewoon onder goed werkgeverschap, oftewel uitvoering van de arbeidsovereenkomst. En als je een wat preciezere FG bent, dan gooi je dit op eigen gerechtvaardigd belang. Dat betekent praktisch gezien alleen dat werknemers bezwaar kunnen maken.

Vaak zie je dat zulke cadeau’s ingekocht worden bij een organisatie die ze ook verstuurt. Dan krijg je altijd de discussie of die organisatie verwerker of verantwoordelijke is. Ik zou daar niet te veel tijd aan besteden maar vooral afspreken dat deze organisatie geen eigen reclame gaat sturen naar het personeel, iets waar zulke clubs nog wel eens een handje van hebben.

Als de werknemers surprises voor elkaar maken, dan ontkom je er niet aan dat dit centraal verstuurd wordt vanuit de werkgever. Het lijkt me te ingewikkeld dat iedereen elkaars adres krijgt, behalve als er bezwaar is en dat getoetst wordt in alle vrijheid en weet ik veel. Doe jezelf en iedereen (behalve de office manager) een pleziertje en laat de office manager dat centraal doen.

Tentamenvraag: is Sinterklaas (een zzp’ende acteur die je daartoe inhuurt) een verwerker of een verwerkingsverantwoordelijke voor wat betreft de Grote Boek-informatie die de werkgever over de collega’s verschaft?

Arnoud

 

Wat kan ik als mijn werkgever mijn bsn en medisch dossier lekt?

Een lezer vroeg me:

De laptop van mijn leidinggevende is recent gestolen. Helaas was het systeem niet versleuteld, waardoor gevoelige persoonsgegevens (zoals mijn naam, geboortedatum, BSN, handtekening en medische gegevens) door de dief te lezen zouden kunnen zijn. Ik ben netjes geïnformeerd en het lek wordt gemeld, maar ik vind dit niet genoeg. Wat kan ik juridisch doen tegen mijn werkgever?
Allereerst: erg jammer en vervelend dat er anno 2020 nog steeds werkgevers zijn die dus dit soort gevoelige gegevens rondsjouwen zonder zelfs maar full-disk encryptie. Het is erg pijnlijk om daar via een datalekmelding achter te moeten komen.

De procedure is zo te lezen netjes gevolgd: de werknemer moet worden geïnformeerd en de AP ook, want de gegevens zijn zeer gevoelig en misbruik daarvan kan zeker tot schade bij de werknemer(s) leiden. Ook als het maar een handjevol mensen was – BSN en medische gegevens tellen als zeer gevoelig ook bij kleine hoeveelheden.

Dat wil niet zeggen dat de kous daarmee af is. De werknemer kan desondanks immers schade lijden door het lek, en volgens de AVG is de werkgever daar gewoon voor aansprakelijk stellen.

Het lastige hierbij is natuurlijk aan te tonen wat je schade is, zeker als er nog geen kwaadwillend gebruik van je gegevens is gemaakt. En bij diefstal van een laptop is de kans reëel dat dat ook niet gaat gebeuren; waarschijnlijk herinstalleert de dief Windows en verkoopt hij het ding tweedehands. Je kunt dan natuurlijk gaan monitoren op misbruik maar je zult waarschijnlijk niets tegenkomen.

Het gaat me wat ver om te zeggen dat een werkgever maar gewoon een bedrag moet geven bij wijze van forfaitaire schadevergoeding. Maar zonder concreet aangetoonde schade kan de werknemer verder niet zo veel. Bij financiële gegevens zou je nog kunnen eisen dat de werkgever een monitoringdienst betaalt om op het ahem “dark web” te kijken of je creditcard daar opduikt, maar voor bsn’s of medische dossiers is er niet echt zo’n markt.

Arnoud

Juinen heeft jou nodig om de nummer één AI wereldstad te worden!

Alles is in Juinen, is al veertig jaar het motto van dit trotse dorp. En nadat in 2019 dit land besloot miljarden te investeren in kunstmatige intelligentie (ook wel AI), dacht men: waarom is niet ook AI in Juinen? Precies op tijd voor de World City AI Ranking, waar tot ieders verbazing dit vaak klein ingeschatte plaatsje genomineerd was tussen technologiereuzen als Singapore, New York en Nairobi. Gaat het ze lukken om vanaf 1 februari genoeg AI-initiatieven te ontplooien die ook nog eens aan wet- en regelgeving voldoen? Ik heb jou, praktijkmens met affiniteit voor AI, regulering en compliance, daarbij hard nodig.

Jaja, dit gaat natuurlijk over mijn nieuwe cursus “AI in de praktijk: compliance en governance” die als elearning van start gaat per 1 februari. In tien hoofdstukken neem ik je via e-learning op unieke wijze mee in de materie, toets je interactief je niveau en werk je met échte casussen (en dus ook échte AI) om je begrip en beoordelingsvermogen te vergroten.

Compliance en AI, geloof me het is inhoudelijk leuk. Kijken hoe je transparante besluitvorming met een algoritme (sorry programmeurs) realiseert, hoe je datasets op bias naloopt en hoe je omgaat met de milieu-impact van AI. Maar ik snap best dat het saai is om alleen abstracte cases te oefenen.

Daarom deze game-opzet met Juinen: jij gaat als AI Compliance Officer van de gemeente aan de slag, en je krijgt cases van burgers en bedrijfsleven. Of van de gemeente zelf, in bijvoorbeeld deze interactieve video-oefening waarbij je de burgemeester en wethouder moet overtuigen van het belang van het juridisch borgen van AI.

Doe je mee? We beginnen 1 februari, eigen tijd maar elke week moet je wel je casus af hebben anders komt Juinen niet op nummer 1.

Arnoud

Is het ethisch hacken om het Twitterwachtwoord van Trump te raden?

De Nederlandse ethische hacker Victor Gevers heeft vorige week naar eigen zeggen het Twitter-account van Donald Trump gehackt. Dat meldde Tweakers vorige week. Het wachtwoord (maga2020!) was eenvoudig te raden, zegt Gevers tegen Vrij Nederland. VN zegt ook dat er sterke aanwijzingen zijn dat Gevers achter een beruchte tweet van de president zat. Het gaf de nodige discussie over ethisch hacken, dingen mogen veranderen en hoe publiek je mag gaan met zo’n ontdekking.

Victor Gevers was ook een van de hackers die in 2016 in wisten te breken op het account van Trump. Daarom kreeg deze inlog zo veel aandacht, hoewel er ook twijfel is over de echtheid. Twitter zelf zegt geen rare inlog te hebben gezien, en bij een screenshot van Gevers dat het interne profiel van Trump toont, ontbreekt het Amerikaanse vlaggetje in de biografie-regel. (Mogelijk kwam dat door de gebruikte browser/OS combinatie.)

Maar dat even terzijde. Stel inderdaad, je weet het wachtwoord van zo’n prominent account te raden en je ziet dat ook alle beweerdelijke extra maatregelen (zoals 2FA) er niet zijn. Wat mag je dan doen? Nou ja, het slachtoffer en/of de dienstverlener informeren natuurlijk, dat past volledig binnen de heersende spelregels voor ethische hackers.

Ermee naar buiten treden is een ander verhaal. Natuurlijk, bij responsible disclosure hoort ook een melding op zeker moment zodat het publiek ook weet wat er mis is. Maar dat is omdat het publiek getroffen kan zijn door het lek dat jij als ethisch hacker had ontdekt. Of omdat ze moeten weten dat die dienstverlener zat te prutsen. Bij een probleem als dit zie ik geen reden om met (responsible) disclosure te dreigen.

Wel is het natuurlijk zo dat het zeer groot nieuws is dat dit oppermachtige Twitteraccount zó slecht beveiligd is. Dan kun je prima naar de pers stappen en melden dat je dit nieuws ontdekt hebt. Ook als je het zelf hebt gemaakt, dat nieuws. Een journalistieke hack is niet hetzelfde als een ethische hack.

Arnoud

Moet je als jurist leren programmeren? #legaltechtuesday

Code as law. Met dat mantra is de toon gezet: steeds vaker speelt software en online dienstverlening een steeds belangrijker rol in de juridische praktijk. Software maakt beslissingen, software selecteert of wijst af. Of functioneert anderszins op onnavolgbare wijze. Ga er maar aan staan met een juridische analyse of claim: de mindset die hoort bij software en ICT ontwerpen, is een hele andere dan die hoort bij een aansprakelijkheidsstelling formuleren of een dagvaarding opstellen. Vandaar dat je steeds vaker leest dat advocaten en juristen moeten leren programmeren. Maar is dat wel echt zo nuttig?

Vooropgesteld: programmeren is gewoon leuk. Het is puzzelen, in logische volgorde instructies uitwerken en rekening houden met randgevallen waar niemand aan gedacht heeft. Wie wel eens een Lego Mindstorms robot heeft ingesteld, begrijpt meteen wat ik bedoel. (Zoekt u nog een Sint- of Kerstcadeau voor uw kind of neefje/nichtje?)

En het mooie is, programmeren lijkt ergens wel op contracteren of juridisch puzzelen. Want ook daar moeten logische stappen genomen worden, hindernissen geëlimineerd, randzaken ingeperkt en risico’s afgedekt. Dat het bij programmeren gaat om het risico dat een temperatuursensor 4000 graden aangeeft en bij contracteren dat een opdrachtnemer ziek wordt, dat is een inhoudelijk detail.

Toch zijn er ook wel verschillen. Juristen leren denken binnen het redelijke en billijke (art. 6:2 en 6:248 BW, bijvoorbeeld). Als een uitkomst al te bizar is, dan weet iedere jurist dat deze kan worden bijgesteld. Een boeteclausule die op zes ton uitkomt voor een overtreding van een half uur, dat wordt gegarandeerd gematigd. Bij de menselijke rechter inderdaad, want het contract komt op zes ton. En als je dit in software doet, dan komt daar ook gewoon spijkerhard zes ton uit. Computers zijn niet redelijk, zij rekenen alleen maar.

Deze verschillen maken dat het best interessant kan lijken om als jurist een cursus programmeren te doen. Als jurist en programmeur kan ik u vertellen: dat is ook zeker de moeite waard, alleen moet u wel vooraf bedenken wat u zou willen kunnen. Je hebt namelijk programmeren en programmeren: gaat het om het begrijpen van de basics, wilt u doorgronden hoe algoritmes (stappenplannen) opgebouwd worden en welke valkuilen daarbij komen kijken, wilt u een juridische dienst of app opzetten of iets anders? Dit zijn namelijk zeer verschillende cursussen.

Voor mij staat voorop dat de skill van het programmeren zelf niet zo heel belangrijk is. Programmeren is namelijk geen handeling op zich, zoals bijvoorbeeld schilderen of fotograferen. Het is een activiteit binnen een groter kader, namelijk applicatie- of dienstontwikkeling. Onderhoud en meegaan met nieuwe ontwikkelingen zijn essentieel. Tenzij je het dus houdt bij Mindstorms robots. Maar programmeren is niet iets dat je leert en daarna altijd onder je riem hebt; je moet het altijd bijhouden en opnieuw toepassen.

Wat je wél kunt leren van een korte cursus, zijn algemene skills en vaardigheden uit dit digitale domein. Een specifieke skill is bijvoorbeeld hoe je een groot algemeen probleem opdeelt in kleine blokjes, en daarna ieder deelprobleem oplost op een manier dat het aansluit bij het vorige en het volgende deelprobleem. Ook helpt programmeren u data beter te begrijpen – een waardevolle skill als u met zogenaamde artificial intelligence aan de slag gaat. Want u kunt wel om een verkeerde komma heen lezen in een dossier, uw robot paralegal slaat onverbiddelijk op hol van zo’n onnozele fout. Ook leert u door programmeren meer projectmatig denken, want software ontwerpen is te groot om even snel op een middag te doen.

Een alternatief dat steeds meer aan populariteit wint, is het zogeheten no-code programmeren. Hierbij hoeft de programmeur geen details van programmeertalen te kennen, maar heeft zhij een visuele interface waarmee dingen aan elkaar te knopen zijn. De computer heeft de benodigde programmeercode op de achtergrond paraat, maar valt u daar niet mee lastig.

Een heel simpel voorbeeld? Probeert u dan IFTTT (if this then dat) eens, een dienst waarmee u van alles aan elkaar kunt knopen. Van agenda’s tot e-mail tot Onenote of zelfs uw wasmachine, als die dat ondersteunt. Dat vereist enig logisch nadenken over wat u precies wilt, en vooral: omzetten naar specifieke, concrete instructies. Zo zou ik op warme dagen graag willen dat mijn zonwering op tijd dicht gaat. Vertalen naar instructies: Als de temperatuur om 13uur boven de 26 graden is, doe dan de zonwering omlaag. Tenzij in mijn agenda “afwezig” staat. Tenzij het regent. Tenzij … kijk, daar voelt u al een programmeur in uzelf omhoog komen.

Overweegt u programmeerervaring op te doen? Vraag u dan eerst af wat u eigenlijk zou willen bereiken. Koop een Mindstorms robot, puzzel met een no-code dienst zoals IFTTT en ga eens puzzelen wat uw eigen robot paralegal zou moeten doen. En beslis daarna.

Arnoud

Mag je contactgegevens via WhatsApp doorgeven of is dat ook al een AVG probleem?

Een lezer vroeg me:

Er zijn beperkingen bij het doorgeven van het e-mailadres aan derden. Maar contactgegevens doorgeven via WhatsApp is een standaard feature. Het zijn weliswaar geen e-mailadressen, maar kan dat volgens de wet zo maar?
Voor het doorgeven van e-mailadressen, 06-nummers en alle andere contactgegevens van personen (ook indien voor zakelijk contact) gelden gewoon dezelfde regels. Dat zijn immers allemaal persoonsgegevens onder de AVG.

Het maakt niet uit of je handmatig een 06-nummer in een e-mail plakt en deze zo doorgeeft, of dat je in de WhatsApp applicatie voor de optie “Contactpersoon toevoegen” kiest, een gegevenssetje kiest uit de lijst van je Android/Apple adresboek en deze in mooie layout laat verschijnen bij de ontvanger. In beide gevallen gebeurt hetzelfde: de contactgegevens komen bij de ontvanger.

Of dat mag, hangt allereerst af van of het delen onder de AVG valt. Die kent immers een uitzondering voor huishoudelijk of zuiver persoonlijk gebruik (artikel 2 lid 2c AVG). In principe geldt die alleen als je de gegevens voor jezelf houdt, maar in zeer beperkte kring delen kan vaak nog net. Als de buurvrouw mijn nummer aan de overbuurman geeft omdat die een afspraak wil om een pakketje bij me te halen, dan zie ik dat als buiten de AVG.

Als het onder de AVG valt heb je een grondslag nodig. Dat zal vaak toestemming zijn (“geef mijn nummer maar aan Jaap, hij mag me altijd appen voor een offerte”), maar dat is niet de enige. Uitvoering van een overeenkomst kan ook (“Jaap is mijn accountant, app hem maar over de jaarcijfers zodat we het contract kunnen finaliseren”). En wellicht kom je er ook met een eigen gerechtvaardigd belang (“Jaap vindt het vast fijn als Pieter hem appt hierover”).

Ik lees vaak dat men zegt, als je WhatsApp (of vergelijkbare applicatie) gebruikt dan ben je akkoord met de voorwaarden en dan mag iedereen je dus appen. Dat argument volg ik niet. Ten eerste staat dat niet in de voorwaarden van WhatsApp, en ten tweede kunnen die voorwaarden geen toestemming afdwingen voor levenslang gecontacteerd te worden door eender wie.

Het maakt dus niet uit hoe je iemands contactgegevens deelt. De kern is dat je het alleen moet doen als het netjes is om te doen.

Arnoud

Met één klik je privacyvoorkeuren juridisch bindend doorgeven, gaat dat ooit lukken?

Met de Global Privacy Control in je browser kun je straks met één muisklik instellen of je gevolgd en geprofileerd wil worden, las ik bij Ars Technica. Deze nieuwe optie, die echt niet hetzelfde is als de keihard gefaalde Do Not Track instelling in je browser (waarmee je met één muisklik kon instellen of je gevolgd en geprofileerd wilde worden), zou wel eens een heel groot dingetje kunnen gaan worden omdat zowel de GDPR als de Californische Consumer Privacy Act (CCPA) dergelijke instellingen juridisch bindend zouden verklaren. Vooralsnog zit de optie alleen in Brave en DuckDuckGo, Mozilla (van Firefox) houdt het bij een braaftaalpersverklaring en van Chrome is nog niets vernomen. Maar laten we optimistisch blijven en eens kijken hoe bindend dit is.

Beetje flauw natuurlijk om zo negatief over DNT te doen, want dat was een goed idee. Sowieso is het natuurlijk heel raar dat mensen gevraagd moeten worden of ze gevolgd en geprofileerd willen worden, want dat is geen beslissing waar je gewone mensen mee lastig moet willen vallen. Dat is gedrag dat we ofwel maatschappelijk aanvaardbaar vinden of niet, en dan verbied je het dus – of niet. En nee, het is geen kwestie van uitleggen of verwachten dat mensen de tijd nemen dit te begrijpen.

Maar goed, als het dan kennelijk gevraagd moet worden dan lijkt me een instelling in de browser heel wat beter dan iedere website zijn eigen supertrage popup met misleidende “eigen instellingen”-knop. Dat was ook waar DNT voor bedoeld was, en wat GPC ook moet gaan doen. DNT werd echter rijkelijk vroeg (2009) voorgesteld, en sneuvelde een stille dood omdat bedrijven geen zin hadden het te ondersteunen.

GPC zou een succes moeten worden omdat het wordt gepresenteerd als de implementatie van de GDPR en de Californische tegenhanger CCPA. Beiden kennen immers een juridisch kader voor toestemming geven (en intrekken) en wat daarbij komt kijken, dus als je GPC nu zo bouwt dat het een GDPR-compliant toestemming of intrekking geeft, dan moet je als bedrijf daar wat mee. Zou je zeggen, want de belangen zijn zo groot dat ik 100% verwacht dat advertentiebedrijven smoesjes zullen blijven verzinnen waarom je de AVG toch echt anders moet lezen.

In Californië pakken ze het harder aan. In een uitvoeringsregeling gekoppeld aan de CCPA staat expliciet dat bedrijven moeten luisteren naar browsergeconfigureerde toestemming:

The CCPA includes a mechanism for solving the one-by-one problem. The regulations interpreting the law specify that businesses must respect a “global privacy control” sent by a browser or device. The idea is that instead of having to change privacy settings every time you visit a new site or use a new app, you could set your preference once, on your phone or in a browser extension, and be done with it.
De AVG kent zo’n uitvoeringsregeling niet, en het is ook niet echt de Europese stijl van wetgeving dat we keihard opschrijven dat een bepaalde instelling of knop de wettelijke manier is om iets voor elkaar te krijgen. Wel zou de EDPB (de samenwerkende toezichthouders) een richtsnoer kunnen publiceren (artikel 70 AVG) waarin zonder veel mitsen en maren staat dat GPC rechtsgeldige toestemming (of weigering daarvan) oplevert en dat een bedrijf niet mag eisen dat je de eigen interface gebruikt. Een richtsnoer is geen wet maar je moet van goede huize komen wil je er zomaar van af kunnen wijken.

Uiteindelijk staat of valt dit natuurlijk met de handhaving. Zolang er geen concrete en directe prikkel is om je site aan te passen, zal GPC net zo hard sneuvelen als DNT. Maar ik begrijp niet waarom dit allemaal zo lang moet duren; we weten wat de eisen voor toestemming zijn en hoe dit kan worden gehandhaafd.

Arnoud

Niet noemen open source licentie is auteursrechtinbreuk

Apollo Fintech maakte inbreuk op het auteursrecht van Jelurida door een cryptomunt aan te bieden die is gebaseerd op de ‘Nxt software’, zonder daarbij de licentie van Jelurida (de Jelurida Public License of ‘JPL’) te verstrekken, zo meldde Rechtspraak.nl onlangs (via). Leuk dat dan ‘JPL’ tussen aanhalingstekens moet als kennelijk gekke term, terwijl cryptomunt gewoon ingeburgerd is. Maar dat terzijde: vrij uniek dat er rechtszaken komen over de naleving van open source licenties. Het is hier natuurlijk weer een speciaal geval, een ruzie tussen twee groepen die werken aan dezelfde software.

De Nxt software implementeert blockchains, en de organisatie Jelurida is ooit begonnen met de Nxt software te ontwikkelen. Zij gebruikt daarbij de Jelurida Public License, een zo te lezen van de GPL afgeleide eigen licentie met een paar opmerkelijke bepalingen. Of je de JPL écht open source kan noemen is  daarom de vraag: de licentie eist een betaling in jouw eigen cryptomunt als je met die software een alternatieve blockchain maakt die niet compatibel is met de originele. Dat is niet helemaal hoe we open source normaal bedoelen, namelijk dat alles mag en je nooit hoeft te betalen. Maar dat terzijde.

Een paar jaar later kwam er de club Apollo, die haar eigen cryptomunt aanbiedt. Daarbij dreef zij op de Jelurida software, iets dat in eerste instantie ook erkend werd in de Github, maar ergens in 2019 verdween de licentievermelding en de tekst van de JPL. Onduidelijk is waarom, en in augustus 2020 kwam die vermelding ook weer terug, maar (mogelijk vanwege een breder gevoel van onvrede) toch stapte Jelurida naar de Nederlandse rechter (vanwege de forumkeuze uit de JPL).

De uitspraak heeft toch de nodige pareltjes. Zo was er meteen ruzie over of de ontwikkelaars van de Nxt software hun rechten wel aan Jelurida hadden afgestaan. Die hadden dat wel toegezegd, maar in digitaal getekende tokens en niet in officiële aktes. Dat is wel héél hypermodern (ik weet dat digitale aktes ook kunnen, maar is een token op de blockchain een akte):

Of overdracht onder een pseudoniem, in een Nxt Token, voorzien van een GPG public key en een Nxt account nummer, voldoet aan het dan geldende aktevereiste zal in dat geval ook moeten worden beoordeeld naar buitenlands recht.
Gelukkig voor Jelurida bleken er ook ouderwetse ontwikkelaars te zijn, die keurig een overdrachtscontract getekend hadden. Daarmee had men de ruimte om de claim te doen.

De volgende stap was discussie of Jelurida de licentie wel van de GPL (geldend op versie 0) mocht omzetten naar hun eigen JPL, omdat niet alle developers daarmee ingestemd zouden hebben. De kortgedingrechter veegt dat snel van tafel: te weinig bewijs dat daar rechthebbenden op tegen waren.

En dan de hamvraag: was het auteursrecht geschonden. Apollo had de software grondig herzien:

Niet in geschil is dat Apollo de Nxt Software heeft bewerkt en coderegels heeft toegevoegd bij het ontwikkelen van de Apollo Software. Jelurida heeft een rapport van 19 augustus 2020 van dr. A.K. Seewald overgelegd, waarin de code base van de Nxt public blockchain platform en de Apollo Foundation codebase met elkaar worden vergeleken. Seewald concludeert dat de Apollo Software een significant deel van de Nxt Software code bevat op bestand-, functie- en coderegelniveau. Tussen de 60% en 73% van de functies van de Nxt Software komen voor ten minste 50% overeen met functies van de Apollo Software. Driekwart van die overeenkomende functies is identiek. Van die overeenkomende functies kan 93% van de coderegels worden teruggevoerd op de core developers van de Nxt Software. Apollo stelt echter 400.000 regels aan eigen code te hebben toegevoegd en de code te hebben ge-refactored, met als resultaat dat de Apollo Software een wezenlijk ander product is dat voldoende van de Nxt Software verwijderd is om als zelfstandig werk te kunnen worden aangemerkt.
Dat laatste is geen argument: refactoring is juridisch gezien een vertaling of verfilming. Het betekent dat je het oude werk opnieuw weergeeft in een andere vorm, maar niet dat je alle brokjes creativiteit uit het origineel kwijt bent geraakt. En dat laatste is het enige argument dat je op tafel moet leggen. Iets is pas nieuw als al het oude (oké, al het creatieve oude) eruit verdwenen is.

Inbreuk dus. En in dit geval is dat een hele simpele: alleen al dat je de credit notice naar de originele licentie hebt verwijdert, maakt dat je deze schendt. En daarmee is de licentie automatisch vervallen, zij het dat het probleem natuurlijk wel in 2020 weer hersteld was. De rechtbank bepaalt dan ook (met dwangsom) dat Apollo zich netjes aan de licentie moet blijven houden, en al haar zakelijke klanten moet benaderen om ze de inbreukmakende versie te laten vernietigen. Schadevergoeding is niet aan de orde (het is een kort geding) maar wel moeten ze een kleine 40.000 euro proceskosten betalen.

Arnoud

 

Banken en verzekeraars mogen niet zomaar meewerken aan ransomware-betalingen

De VS waarschuwen banken en verzekeraars dat ze mogelijk de wet overtreden wanneer ze ransomware-losgeld betalen aan criminelen, las ik bij Trouw onlangs. Allereerst omdat je dan met verdachte transacties te maken hebt (je gaat ineens in bitcoin betalen) en ten tweede omdat je nog wel eens aan partijen in sanctielanden (zoals Noord-Korea, Wannacry) blijkt te betalen, en dat is keihard verboden. Ook in Nederland moeten financiële instellingen betalingen melden die met ransomware te maken hebben. Dat kan nog wel eens knap ingewikkeld worden.

Een tijd geleden schreef ik over wat een instantie moet doen die zijn data of systemen gegijzeld ziet. Als betalen werkelijk de beste optie is (er is geen goede backup, er is urgentie, etc) dan zullen mensen daar toch snel toe geneigd zijn. En ik moet zeggen, ik begrijp dat wel als je slachtoffer bent. Ook al is het zakelijk, het doet echt pijn zo’n datagijzeling.

Daar staat natuurlijk tegenover dat je een crimineel businessmodel in stand houdt, wat maatschappelijk niet wenselijk is. Maar er is geen algemene regel dat je geen losgeld mag betalen, of niet het verdienmodel van criminelen in stand mag houden. Ik zie het echt als een stukje nood, als je dat zelf doet. Doe je het als professioneel ingeschakelde hulppersoon, zoals een cybersecuritybedrijf of verzekeraar, dan wordt dat anders. Dan is het echt een zakelijke keuze dat je criminelen wilt belonen in plaats van strafbare feiten op wilt (laten) sporen, en dan wordt het een heel ander verhaal voor mij.

In Trouw lees ik dat verzekeraars niet direct aan gijzelnemers betalen. Hooguit wordt soms een slachtoffer schadeloos gesteld dat zelf koos voor betaling. Ik denk dat dat nog net door de beugel kan, aangenomen dat er natuurlijk niet aangespoord is om “gewoon te betalen en dan krijg je het van ons vergoed”.

Arnoud