Als je klant je broncode wist, dan hou je een leeg auteursrecht over, succes verder

| AE 13908 | Intellectuele rechten, Security | 2 reacties

“Eiser heeft al vrijwilliger software ontwikkeld voor gedaagde.” Een zin in een arrest waar menig ict-jurist rillingen van krijgt: weinig dingen gaan zo vervelend verkeerd als afspraken tussen vrijwilligers. Ook in deze zaak: de software was heel handig, maar op zeker moment is de samenwerking beëindigd, en oh ja oeps, toen “heeft gedaagde de computer waarop haar server draaide laten formatteren en vervolgens verkocht.” Waarna de eiser nu zijn auteursrecht inzet om de broncode terug te zetten. (Dank, tipgever)

Het gerechtshof (ja, dit ging in hoger beroep) legt de feiten kort en zakelijk uit:

[appellant] heeft als vrijwilliger software voor [de stichting] ontwikkeld. Aan die samenwerking is een einde gekomen. Op enig moment heeft [de stichting] de computer waarop de server van [de stichting] draaide laten formatteren en vervolgens verkocht. [De stichting] beschikt nog over een gedeeltelijke back-up. [appellant] wil dat [de stichting] hem de broncode van de door hem voor [de stichting] ontwikkelde software afgeeft en, wanneer dat niet (meer) mogelijk is, dat [de stichting] hem schade vergoedt die hij daardoor lijdt.
De software had als doel het incasseren van donaties, ter vervanging van een commercieel pakket van een derde. Ik zie wel hoe dat enige waarde heeft, ook als de samenwerking ten einde is gekomen – genoeg andere stichtingen die wellicht óók die software willen gebruiken. Daarnaast vermoed ik dat de procedure ook iets te maken had met dat er op zeker moment onenigheid is ontstaan tussen het bestuur en een ander lid dat kennelijk enige band had met de vrijwilliger in kwestie.

Uiteindelijk zette de vrijwilliger zijn auteursrecht in om de broncode terug te krijgen. Er was weinig twijfel dát hij het auteursrecht had, ook al was er een vrijwilligersovereenkomst getekend met daarin een bepaling dat “De werkzaamheden zullen bestaan uit: Bouwen van de IKN Database“. Had daar nou “Alle auteursrechten die ontstaan uit de werkzaamheden komen toe aan de Stichting” bij gestaan, dan hadden we een mooie discussie kunnen voeren.

De stichting had natuurlijk wel een licentie (gebruiksrecht) op die software gekregen, wat uiteindelijk eindigde toen men afscheid van elkaar nam. Dat was ook niet het probleem; de stichting had een andere oplossing gevonden zo meldde men. Maar de broncode bewaren en teruggeven, dat hoort er niet bij.

Of nou ja, niet? Want in de afspraken was ergens wel terug te vinden dat de broncode “in eerste instantie enkel en alleen opgeslagen [wordt] op de daartoe aangeschafte server” die de stichting in huis had. Je zou dat kunnen lezen als een soort van beveiligingseis, het moet bij ons in-house staan zodat anderen er niet bij kunnen. Of misschien was het wel gemakzucht, dan hoeft de vrijwilliger het niet op zijn eigen laptop te beheren. Of controledrift, dan kan het bestuur een ander erbij laten (alleen hadden ze dan het auteursrecht moeten regelen). Of noem nog maar een paar motivaties.

[appellant] heeft op de zitting bij het hof duidelijk gemaakt dat er valide redenen waren om de broncode op de server van [de stichting] te schrijven, maar ook dat betekent niet dat voor [de stichting] duidelijk was of moest zijn dat zij ervoor verantwoordelijk was dat de auteursrechtelijk beschermde creatie van [appellant] op een drager behouden bleef. Op grond van de bewoordingen van de afspraken zoals [appellant] stelt dat die zijn gemaakt, hoefde voor [de stichting] niet duidelijk te zijn dat zij dat risico droeg.
Ik hoor wel eens vaker dat mensen op grond van hun auteursrecht claims leggen op kopieën. Dat is dus een probleem, zoals het Hof het hier formuleert: het auteursrecht legt aan een bewaarder niet de verplichting op om de broncode voor de rechthebbende veilig te stellen. Het auteursrecht is een verbodsrecht, een recht van uitsluiting. Je kunt wel mensen dwingen de broncode te wissen als ze die hebben in strijd met je recht, maar niet om ze je een kopie te laten geven.

Arnoud

Wanneer ben je nou gebonden aan rare bedingen in een disclosurebeleid?

| AE 13894 | Security | 7 reacties

Via Twitter:

Stel: @DIVDnlvind een lek bij veel organisaties en gebruikt security.txt om contactgegevens te vinden en in bulk organisaties te informeren. Wat als één van die organisaties een disclosure beleid hanteert met een eenzijdig geformuleerde geheimhoudingsclausule?
DIVD is het Dutch Institute for Vulnerability Disclosure dat opereert als een tussenpersoon: zij worden geïnformeerd over security issues en berichten dat aan organisaties die daarmee aan de slag moeten. Denk aan leveranciers in wiens software een gat wordt ontdekt, of bedrijven wiens gegevens zijn gelekt. Security.txt is een standaardmiddel voor het informeren van organisaties: je zet dit op je website en plaatst er contactgegevens in van de security-persoon die over incidenten of kwetsbaarheden moet worden geïnformeerd. Dit bestand is machine-leesbaar, zodat je automatisch zaken als het e-mailadres eruit kunt vissen om er vanuit je eigen applicatie een notificatie heen te sturen.

Een van de informatievelden die in een security.txt-bestand staat, is het policybeleid waaronder je meldingen aanneemt. Dit is dus de vulnerability disclosure policy of responsible disclosure policy, waarin een bedrijf uitlegt hoe je tips doorgeeft, hoe ze daarmee omgaan en wat ze van jou verwachten. En dat is dus waar de Twittervraag over gaat: als men daarin zet “gij zult voor eeuwig zwijgen over het gemelde op straffe van eene boete van vijftienhonderd florijnen”, hoe bindend is dat dan en op wie?

Het haakt in op de recente discussie over ethische hackers in België, waar ook verwezen werd naar strenge geheimhouding als je binnen een wettelijk beschermingsregime wilde opereren. Maar een kernverschil is wel dat het daar gaat over een wettelijk regime, waar je het mee te doen hebt. Hier gaat het over privaatrechtelijke regels, juridisch gezien algemene voorwaarden die deel uit kunnen maken van een overeenkomst. Als je een overeenkomst sluit met een strenge geheimhouding, dan zit je daaraan vast. Als professioneel opererende partij is daar weinig discussie over.

Het lastige is natuurlijk, waardoor zit je aan die voorwaarden vast. Een handtekening zet je niet, en je communiceert ook geen akkoord op andere wijze. Je handelt conform het gepubliceerde beleid, maar dat is zeker niet genoeg. Juristen noemen dat “browse-wrap” overeenkomsten, naar analogie met de click-wrap overeenkomst waarbij je door klikken op “I agree” ergens mee akkoord gaat, en met de oudere shrink-wrap overeenkomst waarbij je akkoord gaat (althans, beweerdelijk) door het krimpfolie te verbreken. (Alles hierover in mijn nieuwe boek.)

Hoofdregel uit de wet is dat browse-wrap overeenkomsten niet legaal zijn. Dit haal ik uit een arrest van het Hof Den Haag uit 2018, dat het sluitstuk is van acht jaar procederen inclusief de hulplijn van het Hof van Justitie. Na een zéér diepgravende analyse van internationaal privaatrecht, Iers versus Engels versus Nederlands recht en of een rechtskeuze uit algemene voorwaarden meeweegt bij de vraag of die voorwaarden bindend zijn, komt men met een zeer recht-voor-z’n-raap conclusie over browse-wrap:

Waar deze juridisch onbeschermbare [prijs]gegevens [van Ryanair-vluchten] voor een ieder gratis en vrij toegankelijk zijn openbaar gemaakt op een openbare website [van Ryanair zelf], zal een redelijk persoon niet denken dat PR Aviation, louter door de website te bezoeken en/of deze gegevens te verzamelen, zich wilde binden aan de gebruiksvoorwaarden die haar verbieden om die gegevens te verzamelen en te gebruiken, noch aan de daarin opgenomen rechtskeuze. Ter vergelijking: wie op straat aan een muur, of in een étalage zichtbaar vanaf de openbare weg, een aanplakbiljet heeft opgehangen met een tekst waarvan de eerste regel luidt: “Wie verder leest, moet € 5,- betalen”, mag er niet zo maar op vertrouwen dat een voorbijganger die de tekst verder leest, zich heeft willen binden aan deze voorwaarde.
Zou je ergens in moeten loggen of een aanvraag doen, dan kan men wel voorwaarden stellen. Het ging hier dus goed (voor PR Aviation) omdat de gegevens openbaar én onbeschermd waren. Dat analoog toepassen zou dan zijn: “als iemand gewoon een tip over een kwetsbaarheid wil doorgeven, dan mag je er niet op vertrouwen dat die zich wilde binden aan jouw voorwaarden”.

Daar staat natuurlijk tegenover dat het onderzoeken en uitpluizen van vulnerabilities al snel in de sfeer van computervredebreuk terecht komt, omdat je op plekken komt waarvan je moet weten dat je er niet hoort te zijn. Daardoor heerst het beeld dat je maar beter de policy-regels kunt accepteren, want dan zal men geen aangifte doen of je civielrechtelijk aanspreken op de schade. Dus je gaat dan semi-vrijwillig akkoord omdat het alternatief “nee ik was wel binnen maar ik verwerp jullie regels” neerkomt op een bekentenis van een misdrijf.

Maar is het wel een misdrijf, zo’n ethische hack? Het Openbaar Ministerie denkt daar volgens mij anders over, die focussen op het maatschappelijk belang en je proportionaliteit/subsidiariteit maar niet op de vraag of je keurig de regels van het bedrijf gevolgd hebt. Gezien die regels lijkt het mij zeer onwaarschijnlijk dat je vervolgd wordt als je volgens de algemeen aanvaarde ethische regels werkt maar er gezien de situatie wel voor kiest om na een redelijke periode te publiceren over de vulnerability.

Een civielrechtelijke zaak dan, men dagvaardt je wegens onrechtmatige daad en claimt tonnen aan schade plus een verbod met dwangsom om ooit nog in de buurt van hun IP-range te komen? Dat kan natuurlijk altijd, alleen bij ethisch hacken is er haast per definitie geen schade, dus wat wou je dan claimen? Los daarvan lijkt het me moeilijk te spreken van onrechtmatig handelen als het geen computervredebreuk is omdat je het ethisch verantwoord deed.

Dan blijft contractbreuk over: los van de rechtmatigheid, wij hadden áfgesproken dat jij je mond zou houden toen jij de melding deed, en die afspraak schend je nu. Maar eenzijdig iets afspreken kan dus niet, en dan komen we terug bij die Ryanair-zaak over de vraag of je akkoord was gegaan met die voorwaarden omdat ze ergens te lezen waren. Ik zie ondertussen nog steeds geen reden waarom dat zo zou zijn, als een CVD-melding een gewone, legale actie is dan zie ik dat als analoog aan die tekst op de muur. De enige uitzondering die ik kan bedenken is als je iets extra’s zou willen, zoals een beloning. Dan doe je meer dan alleen een melding en kan er ook meer van je verwacht worden.

Arnoud

 

 

[insert code as law joke here] of hoe de EU Cyber Resiliency Act softwareontwikkeling gaat veranderen

| AE 13891 | Innovatie, Ondernemingsvrijheid, Regulering, Security | 9 reacties

“The EU’s new Cyber Resilience Act is about to tell us how to code”, las ik op de blog van Bert Hubert (aanrader). De CRA is een concept-Verordening over cyberbeveiligingseisen voor producten met digitale elementen, zeg maar alles dat we IoT (internet of [st]hi[nt]g?s?) noemen, maar dan breder want netwerkverbinding is niet perse een eis. Dergelijke apparaten moeten eindelijk, eindelijk een goede cyberbeveiliging hebben, maar dat zal nogal wat voeten in de aarde krijgen, zo laat Hubert overtuigend zien. Hoe gaat de toekomst van cybersecurityrecht eruit zien?

De CRA (originele concepttekst) maakt deelt uit van de Europese Digitale Decade, het grote strategieplan van Europa om de wereld te transformeren. Veiligheid van digitale apparaten hoort daar natuurlijk bij, ik zou het zelfs een van de speerpunten van iedere serieuze ict-strategie durven te noemen. En met boetes tot 15 miljoen (of 2% wereldwijde omzet indien hoger) maakt deze Verordening het echt wel een belangrijk onderwerp. Toch is het ook een hele spannende, want afbakenen wat er nu écht allemaal gebeurt is nog razend ingewikkeld.

Neem bijvoorbeeld de uitzondering voor open source, wat een terecht aandachtspunt is omdat je vrijwilligers niet hetzelfde wilt behandelen als commerciële bedrijven. Alleen, hoe baken je dat op een beetje rechtlijnige manier af? Want als ik als bedrijf apparaten gratis weggeef (met alle broncode open source) en geld vraag voor een gekoppelde, verplichte SaaS-dienst dan wil je wel dat die apparaten aan de CRA voldoen. En dan heb je ook nog bedrijven die werknemers opdragen aan open source projecten te werken, omdat ze daar indirect voordeel uit halen bij het implementeren van ict-oplossingen bij klanten. De CRA zegt nu (overweging 10):

In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.
Vervolgens val je onder de CRA als je een product (dus hardware met “digitale elementen” erin) op de markt brengt vanuit een “commercial activity”. Je zou zeggen dat die vrijwilliger die alleen een stuk software op internet zet, hier buiten valt alleen al omdat hij geen producten op de markt brengt. Maar let op: de definitie van een product is “software or hardware product”, dus ook enkel software online zetten kan er al onder vallen, als je daarmee een commerciële activiteit ontplooit. Dat dat bij Microsoft geldt wanneer die gratis software online zetten is dan één ding, een vrijwilliger met een “doneer nu”-knop voelt toch heel anders. Gezien de aard van de verplichtingen is dit wel een zwaar ding, dat echt nog fors op de schop moet. Gelukkig hebben een hoop partijen zich al hierover uitgelaten, dus ik ben benieuwd wat de volgende versie van de tekst gaat zeggen.

Waarom is het dan zo zwaar? De kern is dat ieder “product met digitale elementen” voldoet aan een serie basiseisen, en als je product op een aparte lijst staat dan ben je “critical” en krijg je nog een extra set eisen op je ontwerp-bord. (Stop je er AI in dan krijg je nóg meer eisen, waarover een andere keer.) Het is jouw taak als fabrikant aan te tonen dat je voldoet aan die eisen, en om dat vooraf schriftelijk uitgewerkt te hebben (een cybersecurity risk assessment). Maar alleen een papieren gaapdocument is niet genoeg: je moet gedurende 5 jaar (of levensduur indien korter) een proces hebben om kwetsbaarheden op te lossen (art. 10 lid 6).

Maar er is meer, in die lijst met basiseisen staan namelijk deze twee heel belangrijke componenten:

  1. Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks;
  2. Products with digital elements shall be delivered without any known exploitable vulnerabilities;
Die tweede klinkt meteen héél erg sterk: een product mag niet worden verkocht als er bekende kwetsbaarheden in zitten. Hoe ga je dat doen met een productielijn waarbij het zeg drie maanden duurt van fabriek tot schap in de winkel? Dat kun je zien als een bug, maar ik zie het als een feature: ontdekt men een fout dan moet je dus meteen een update realiseren die direct bij verkoop beschikbaar komt. Of inderdaad je distributeurs instrueren dat apparaat niet te verkopen tot het is opgelost, zeg maar een recall net zoals bij glasscherven in de pindakaas. Ik zou dat wel een goeie vinden, dat we cybersecurity net zo ernstig vinden als glasscherven.

Om dit alles vorm te geven, wordt het aloude CE-keurmerk opgepoetst. Wie dit keurmerk voert, geeft aan dat zijn producten voldoen aan de CRA. Dat maakt aansprakelijkheid een heel stuk makkelijker, zeker in combinatie met de recent besproken AI Liability Directive die gewoon de bewijslast omkeert: wie het CE keurmerk voert en een onveilig product blijkt te hebben verkocht, moet bewijzen dat er niets aan de hand was anders moet hij alle schade vergoeden.

De grote uitdaging, zoals Hubert ook opmerkt, is wie dit alles gaat overzien. Zonder standaarden gaat het niet, maar wie zal de standaard maken over cybersecurity? Hubert:

I have personally been part of a few standardisation processes, and it is extremely worrying how these are dominated by just a few parties, most of them non-European and with strong commercial goals to get a standard passed that works for them.
Dit beeld zal herkenbaar zijn voor iedereen (ikzelf ook) die ooit met standaardisatie heeft meegekeken. Dit zou wel eens het grootste struikelblok kunnen gaan worden. Tegelijkertijd: alleen met een open norm eisen dat een product veilig genoeg is, gaat hem ook niet worden. Dan verzint iedereen eigen criteria en krijgen we jarenlange discussie over waar welke lat zou moeten liggen. Een standaard set eisen is de enige optie. Dus dit gaat nog erg pijnlijk worden, en ik ben bezorgd dat het hierdoor veel langer gaat duren dan nodig is.

Arnoud

 

Twitter laat gebruikers betalen voor tweefactorauthenticatie via sms, mag dat van de AVG?

| AE 13861 | Security | 11 reacties

Bestaande Twitter-gebruikers die van tweefactorauthenticatie (2FA) via sms gebruikmaken zullen hier vanaf 20 maart voor moeten betalen. Dat meldde Security.nl onlangs. Het platform heeft de beveiligingsmaatregel namelijk onderdeel gemaakt van het betaalde Twitter Blue-abonnement. Voor velen reden om me te vragen, “mag dat wel” met name omdat de AVG adequate beveiliging eist en dit toch… Lees verder

DeGiro moet schade door gekaapt beleggingsaccount deels vergoeden

| AE 13853 | Security | 1 reactie

DeGiro moet de schade die een klant door een gekaapt beleggingsaccount leed deels vergoeden, meldde Security.nl onlangs. De klant probeerde te herstellen van een gekaapt account, maar kreeg te weinig medewerking van de aandelenbroker. Klachteninstituut Kifid vindt de schade beide partijen gelijk te verwijten. De klant ontdekte vorig jaar maart dat er aankoopopdrachten via zijn… Lees verder

Ethische hackers mogen dankzij nieuwe wet Belgische bedrijven hacken zonder toestemming

| AE 13855 | Security | 14 reacties

Hoogdag voor de ethische hackers, want vanaf vandaag gaat een wet in die hen een pak meer vrijheid geeft. Dat meldde de VRT onlangs. Maar met ook een pak restricties: melden bij de verantwoordelijke binnen 72 uur, geen geld of ander gewin, en iets waar den Floor ambetant van wordt: een geheimhoudingsplicht voor de ethisch… Lees verder

ABN Amro mag onbewerkte kopie van identiteitsdocument toch opslaan

| AE 13851 | Ondernemingsvrijheid, Security | 29 reacties

ABN Amro mag een foto of scan van een onbewerkt identiteitsdocument toch opslaan, aangezien dit niet in strijd met de AVG is, las ik bij Security.nl. De beroepscommissie van het financiële klachteninstituut Kifid oordeelde anders dan de klachtenuitspraak van vorig jaar, waarin het vastleggen en bewaren van een kopie van dit ID-bewijs juist sterk aan banden… Lees verder

Mag je gelekte software doorspitten om te zien of deze tegen jou gebruikt is?

| AE 13803 | Security, Uitingsvrijheid | 2 reacties

Activistische hackers hebben 1,8 terabyte aan software en broncode online gezet van het Israëlische spionagebedrijf Cellebrite. Dat meldde Tweakers vorige week. Onder meer ons NFI gebruikt deze software om mobiele telefoons te kraken, bijvoorbeeld in een strafrechtelijk onderzoek. De discussie in de comments focuste op een interessante vraag: mag je in deze publicatie snuffelen als… Lees verder

Verdachte krijgt lagere straf voor phishing wegens politie-onderzoek naar iPhone

| AE 13796 | Regulering, Security | 3 reacties

Een man die via sms en WhatsApp phishingaanvallen uitvoerde heeft een lagere straf gekregen omdat de politie zijn iPhone zonder toestemming van de rechter-commissaris onderzocht, las ik bij Security.nl. De rechtbank Midden-Nederland oordeelde dat De strafzaak was het gevolg van een smishing-zaak (sms-phishing, sorry) waarbij verzekeraar Achmea als gezicht was gebruikt. Dat lijkt competent genoeg… Lees verder

Wordt de directie persoonlijk aansprakelijk voor IT-fouten onder de NIS2-richtlijn?

| AE 13781 | Ondernemingsvrijheid, Security | 6 reacties

De NIS2-richtlijn lijkt nog ver weg, maar omdat de gevolgen groot kunnen zijn, moeten bedrijven niet te lang wachten met actie. Dat las ik bij Dutch IT Channel.  “Heel belangrijk detail is dat de directie van bedrijven persoonlijk aansprakelijk wordt voor het conformeren aan deze wetgeving”, zo werd uitgelegd tijdens een bijeenkomst van de Dutch Cybersecurity… Lees verder