Niet noemen open source licentie is auteursrechtinbreuk

| AE 12278 | Intellectuele rechten | 6 reacties

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

 

Compliance en risicomanagement bij Artificiële Intelligentie leren? #legaltechtuesday

| AE 12263 | Iusmentis | 3 reacties

Steeds meer organisaties zetten Artificial Intelligence (AI) in. Dit versnelt beslissingsprocessen en schept nieuwe inzichten omtrent risico’s, klanteigenschappen en commerciële kansen. Deze techniek is zeer nieuw en haar inzet roept dan ook vele vragen op over de juridische en ethische randvoorwaarden. Mag dat wel, een computer laten beslissen? Welke kaders hanteer je om een verantwoorde inzet van AI te realiseren? Wordt het tijd voor een AI Compliance Officer?

De inzet van AI biedt nieuwe mogelijkheden. Bestaande processen kunnen fors worden versneld door menselijke tussenkomst te vervangen door een AI. Zo zou een AI-bewaker bagage van bezoekers kunnen screenen op ongewenste voorwerpen, en deze doet dat dan veel sneller dan een mens (en is bovendien om vijf uur niet moe en afgeleid). Een verzekeraar zou een AI in kunnen zetten om claims te kunnen analyseren.

Dergelijke analyses hebben echter ook diverse risico’s. Zo staan AI’s er om bekend dat zij bestaande vooringenomenheid (bias) uit de onderliggende data sterk uitvergroten, wat kan leiden tot ongewenst gedrag zoals discriminatie. Ook is het vaak lastig duidelijke uitleg te krijgen over hoe een AI tot zijn conclusie komt: dergelijke data-analyse is volkomen onvergelijkbaar met een menselijk gedachteproces.

Deze risico’s maken organisaties nog steeds huiverig over de inzet van AI. Ook de wetgever heeft niet stilgezeten: in de Europese privacywet GDPR is een expliciet verbod opgenomen om mensen aan besluiten te onderwerpen die door een AI zijn genomen. Hoe dan ook grip te krijgen op AI, en te zorgen voor een nette, ethisch verantwoorde inzet, is een lastige vraag voor veel organisaties.

In 2019 publiceerde de Europese Commissie de Ethics Guidelines for trustworthy AI. Onder “ethisch” verstaat men niet alleen het voldoen aan wettelijke regels, maar ook aan meer algemene ethische principes. Ethische AI bestaat uit drie componenten, waaraan gedurende de volledige levenscyclus van het systeem moet worden voldaan: de AI moet

  1. wettig zijn, door te voldoen aan alle toepasselijke wet- en regelgeving,
  2. ethisch zijn, door naleving van ethische beginselen en waarden te waarborgen, en
  3. robuust zijn uit zowel technisch als sociaal oogpunt, aangezien KI-systemen ongewild schade kunnen aanrichten, zelfs al zijn de bedoelingen goed.
Uitgaande van deze drie componenten komen de richtsnoeren tot zeven vereisten voor AI-systemen:
  1. Menselijke controle en toezicht
  2. Diversiteit, non-discriminatie en rechtvaardigheid
  3. Technische robuustheid en veiligheid
  4. Transparantie en verklaarbaarheid
  5. Privacy en datagovernance
  6. Maatschappelijk en milieuwelzijn
  7. Verantwoording en controleerbaarheid
Het toetsen aan deze vereisten komt in de praktijk neer op het welbekende proces van compliance: formuleer criteria waarmee naleving kan worden gemeten, zorg dat mensen doordrongen zijn van het belang van naleving en toets op de criteria. Dat dan ook nog eens op een positieve manier; nee zeggen is altijd makkelijk, maar technologie op een compliant en werkbare manier de markt op krijgen is een stuk lastiger.

Omdat het hier ook nog eens gaat om geavanceerde technologie en vaak vele partijen betrokken zijn, is AI compliance een uitdagende kwestie. Een AI compliance officer moet dan ook behoorlijk thuis zijn in wetgeving, techniek en de toepassingspraktijk.

Ik vond dit zo’n leuke dat ik de afgelopen weken eigenlijk alleen heb gewerkt aan mijn nieuwe leergang AI in de praktijk: compliance & governance. Deze online leergang is speciaal ontwikkeld voor informatieprofessionals, juristen en compliance officers die aan de slag moeten of willen met AI en de toetsing daarvan. Geen blokkades opwerpen, maar zorgen dat bedrijven en instanties aan de slag kunnen. Weten wat er wel kan en hoe dat wordt bereikt.

De stof wordt volledig online aangeboden. Met geavanceerde vormen van elearning kan de cursist eenvoudig werken en effectief de stof tot zich nemen. De docent is online beschikbaar voor 1-op-1 overleg, en via een discussieforum kunnen cursisten met elkaar overleggen en brainstormen.

Met dat forum is trouwens iets bijzonders: het wordt aangeboden door een fictief Nederlands dorp. De leergang kent namelijk een serious game element, waarbij deelnemers optreden voor bedrijfsleven en overheid in dat dorp om te zorgen dat AI-initiatieven volledig compliant én bruikbaar worden. Hoe beter men het spel speelt, hoe hoger het dorp scoort in de wereldwijde competitie van de Most AI-focused city in the world, bijgehouden door het fictieve United Nations Office for Global AI (UNOGAI). Bij pittige onderwerpen als deze is serious gaming een bewezen techniek om leren effectiever te maken.

Durf jij de uitdaging aan? Op 1 februari gaat de eerste ronde van start. Meer informatie en de inschrijfmogelijkheid vindt u bij ICTRecht.

Arnoud

 

 

 

Hoe erg is het dat onze loginbanner “Welkom” zegt tegen mensen?

| AE 11713 | Security | 6 reacties

Een lezer vroeg me:

Op onze interne servers krijgt personeel een loginscherm met daarop een tekst à la “Welkom bij Initech, gelieve in te loggen – uitsluitend voor werkdoeleinden gebruiken”. Nu zegt onze ISO auditor dat deze tekst problematisch is, omdat met name dat ‘welkom’ zou maken dat inbrekers kunnen claimen er niet wederrechtelijk te zijn. Dus het moet worden “Verboden toegang – uitsluitend geautoriseerd personeel – misbruik wordt vervolgd als misdrijf”. Dat vind ik niet echt vriendelijk naar mijn personeel, is er een tussenweg? Is dit echt zo krom, juridisch?

Dit is een broodje aap-verhaal dat geen enkele juridische basis kent. Het recht werkt niet zo en de inhoud van zo’n loginscherm gaat echt het verschil niet maken wanneer iemand vervolgd wordt voor computervredebreuk.

Natuurlijk komt dit verhaal uit Amerika, maar ook daar lijkt het nergens op een werkelijke zaak te herleiden (deze en deze bijvoorbeeld zijn vrij oude bronnen al). Ik kan in Nederland geen enkele rechtszaak rond computervredebreuk vinden waarbij het zelfs maar een discussie was wat de loginbanner of MOTD vermeldde.

Het recht kijkt nooit naar één specifiek aspect van de zaak, zoals zo’n logintekst. Bij rechtszaken wordt altijd gekeken naar de volledige omstandigheden van het geval. Het criterium is immers of de inbreker had moeten weten dat hij op verboden terrein was toen hij de handeling verrichte die hem ten laste werd gelegd. Dat zal nooit afhangen enkel van een zo’n tekstje. Je moet bijvoorbeeld nog steeds inloggen op het systeem van de vraagsteller, en als je een wachtwoord raadt dan moet je weten dat dat niet mag. Dus ga je alsnog nat.

Ik kan werkelijk geen situatie bedenken waarin die tekst relevant is. Heel misschien als er een gast/gast account is op zo’n systeem én je dingen kunt doen die niet gewenst zijn vanaf zo’n gastenaccount. Dan mocht je naar binnen (“welkom”) en mocht je inloggen zonder bekend te zijn (gast/gast) en was je in staat iets te doen dat niet de bedoeling was, hoe kon je dan weten dat dat laatste het geval was. Maar dat voelt weinig realistisch.

Arnoud

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

| AE 10656 | 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… Lees verder

Je hebt nog 32 dagen om de AVG te implementeren #32totavg

| AE 10478 | Privacy | 30 reacties

Vandaag zijn er nog precies 32 dagen te gaan tot 25 mei 2018, de datum waarop de Algemene Verordening Gegevensbescherming (AVG, ook wel General Data Protection Regulation oftewel GDPR) van kracht wordt. Er is nog steeds veel onzekerheid over de AVG, die van alles zou verbieden of onwerkbaar maken. De AVG noem ik altijd vooral… Lees verder

GPL compliance engineering guide uitgebracht

| AE 1289 | Intellectuele rechten | 4 reacties

Vorige week verscheen versie 1 van de GPL Compliance Engineering Guide, geschreven door Armijn Hemel die u waarschijnlijk wel kent van het GPL-Violations project. Dit is een handleiding over hoe GPL-schendingen op te sporen. Een mooie aanvulling dus op de gids van SFLC waarin algemene stappen staan over hoe je je als bedrijf aan de GPL… Lees verder