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 ik dan de boete betalen als mijn klant daarop aangesproken wordt?

Heel formeel sprekend heeft een softwareontwikkelbedrijf géén plicht om te zorgen dat hun software aan de AVG voldoet. De AVG stelt regels voor de verwerking van persoonsgegevens, en dat gaat pas spelen bij het in productie nemen van die software. Er is dus niets mis met software waarbij persoonsgegevens niet kunnen worden geëxporteerd, het enige is dat een afnemer die niet in kan zetten in situaties waarin de AVG op hem van toepassing is.

Praktisch gezien ontkom je er niet aan om rekening te houden met de AVG, precies om die reden. Een softwarebedrijf met Nederlandse klanten kan het niet maken om zo’n exportfunctie weg te laten, want zijn klanten voldoen dan gewoon niet aan de wet en hebben dus een groot probleem als ze deze software in gebruik zouden nemen.

De discussie zal dus meer gevoerd worden op hoe ver je moet gaan als developer, en ook waar de kosten komen te liggen. Want dat er een exportfunctie moet zijn is één ding, welke gegevens er wel en niet onder vallen is een heel ander. Daar zijn ook de juristen het nog niet helemaal over eens, bijvoorbeeld. En er zijn nog veel meer dingen: hoe vraag je precies toestemming en hoe makkelijk moet deze in te trekken zijn?

Ik denk dat je er op dit moment dan ook niet aan ontkomt om hier in detail over te spreken met je klant. Dit kan mijn software, dit wil jij erbij, ik weet van de AVG en wat zie jij? (/juf Ank). En dat dan vastleggen in functionele specificaties of test cases, en in het contract opnemen dat jouw verantwoordelijkheid is dat het zal werken zoals vastgelegd.

In de toekomst zie ik meer mogelijkheden. De AVG kent de optie om technologieën voor gegevensbescherming of -verwerking te certificeren. Je zou dan als developer zo’n certificaat kunnen halen, en daarmee je klanten gerust stellen dat ze jou prima kunnen kopen. Eventuele aansprakelijkheid zou dan zeer mee moeten vallen (je bent immers gecertificeerd) en zou wellicht ook nog te verhalen zijn op de certificaatverstrekker. Maar dit zal nog wel een jaar of vijf duren, minstens.

Arnoud

Licentiecodes meenemen van je werk is geen diefstal

Een licentiecode meenemen van je werk als je ontslag neemt, is geen diefstal of heling. Dat vonniste de rechtbank Den Haag onlangs. De verdachte in deze strafzaak had ontslag genomen en wilde kennelijk met die licentiecode goede sier maken bij de nieuwe werkgever, iets dat de oude werkgever zó ernstig vond dat men aangifte deed, en bij het OM vonden ze het ook ernstig genoeg om te vervolgen. Maar de rechtbank ziet hier geen diefstal in, omdat een licentiecode immers geen ‘goed’ is dat je kunt stelen.

De precieze reden voor het meenemen kan ik niet uit het vonnis halen, maar ik lees dat diverse werknemers tegelijk ontslag namen en bij de concurrent gingen werken. Deze werknemer had in dat verband die licentiecode voor een Amerikaans softwarepakket naar zichzelf gemaild vanaf het werk. De werkgever kwam hierachter en deed aangifte.

De verdachte werd formeel vervolgd voor het misdrijf bekendmaken van vertrouwelijke informatie (schending van bedrijfsgeheimen). Het is namelijk strafbaar om door misdrijf vertrouwelijke bedrijfsgegevens te achterhalen en bekend te maken (artikel 273 Strafrecht). Dat kan ook gaan om digitale informatie, en bij licentiecodes zie ik wel waarom je die als vertrouwelijk zou aanmerken.

Voor de rechtbank was er echter een principieel bezwaar: welk misdrijf dan? Want de verdachte was op zich gerechtigd in de computer van de werkgever die licentiecode op te vragen, dus er was geen sprake van computervredebreuk.

Je zou dan eerder van diefstal of verduistering moeten spreken, net zoals je het diefstal noemt als een werknemer legaal de kantine in gaat en een zak met koffiebonen meeneemt. Maar voor diefstal (of verduistering) is vereist dat er een ‘goed’ wordt weggenomen. En volgens de jurisprudentie kan dat alleen als het slachtoffer de feitelijke macht over die informatie verliest zodra de dader zich deze toe-eigent.

Bij objecten in virtuele werelden is voorstelbaar dat je spreekt van “feitelijke macht verliezen”. Als speler B dat zwaard te pakken krijgt van A, dan heeft A het automatisch niet meer. Idem voor zeg een bitcoin of een belminuut. Maar bij een licentiecode is daarvan geen sprake. De code is dan op twee plaatsen aanwezig, en twee partijen hebben er dan macht over. Daarom geen diefstal en dus geen strafbaar onthullen van bedrijfsgeheimen.

Op zich een logische uitkomst, zeker als je bedenkt dat de volgende Wet Computercriminaliteit dit expliciet wél strafbaar gaat stellen. A contrario redenerend doe je dat alleen als het nu niet strafbaar is, dus is het nu niet strafbaar.

Arnoud

Kun je Microsoft aansprakelijk stellen voor schade uit een ransomware-aanval?

| AE 9521 | Intellectuele rechten, Ondernemingsvrijheid | 25 reacties

De computersystemen zijn nog steeds niet bruikbaar, zo liggen beide containerterminals van APM in de Rotterdamse Haven nog steeds stil. Dat las ik bij Bright. De ransomware Petya wist vele computers te gijzelen in de IT-omgeving van de Haven, en dat is niet eenvoudig op te lossen. De reden blijkt een bug in Windows, die al tijden bij de NSA bekend zou zijn maar nooit gemeld is. Is er nu enige mogelijkheid Microsoft aansprakelijk te stellen voor de schade van zulke downtime?

Het makkelijke antwoord is natuurlijk nee, want in de voorwaarden van Microsoft staat gewoon dat ze niet aansprakelijk zijn voor de gevolgen van fouten in hun software. En ja, dat is rechtsgeldig bij grote partijen zoals de Rotterdamse Haven. Bij consumenten in principe niet, tenzij er heel bijzondere omstandigheden zijn (zoals, blijf ik volhouden, wanneer de software gratis beschikbaar werd gesteld).

Maar goed, wat in het hypothetische geval dat er geen rechtsgeldige beperking van aansprakelijkheid was. Dan zou het kunnen. Wel moet er dan aan een aantal eisen zijn voldaan. Kort gezegd is de belangrijkste vraag of Microsoft deze fout had moeten voorkomen, vanuit hun zorgplicht als dienstverlener. Of iets anders geformuleerd, of je het Microsoft kunt aanrekenen dat die fout erin zat (toerekenbare tekortkoming).

Ik denk dat je daar in het algemeen niet meteen van kunt spreken, tenzij men de fout kende en deze dan onnodig lang liet liggen. Alle software heeft fouten, zeker zulke grote en complexe software als Windows. Het is onvermijdelijk dat er dan van tijd tot tijd een exploit opduikt die mensen schade berokkent.

Verder, zelfs als je uitkomt bij een toerekenbare tekortkoming of verzaken van de zorgplicht, dan nog heb je altijd het verweer “waarom had je geen backup” of andere maatregelen ter beperking van de schade. Want anno 2017 behoort iedereen te weten dat je je systeem goed moet afschermen voor onheil van buitenaf, en dat je je data moet backuppen om terug te kunnen na een geslaagde aanval. Het voelt weinig redelijk om je bedrijfsdata kwijt te spelen door een aanval en dan Microsoft de rekening te geven.

Bij consumenten blijf je zitten met het probleem dat zij juridisch gezien meestal geen schade hebben. Zet maar eens een geldbedrag op het gegijzeld hebben van je vakantiefoto’s of persoonlijke administratie. En zonder schade geen claim.

Arnoud

Ministers stelt ontwikkelaars aansprakelijk voor softwarefouten

| AE 9502 | Intellectuele rechten, Ondernemingsvrijheid | 23 reacties

Demissionair staatssecretaris Klaas Dijkhoff heeft in een Kamerbrief gezegd zegt dat softwareontwikkelaars op verschillende manieren aansprakelijk zijn voor schade die als gevolg van hun product ontstaat. Dat las ik bij Tweakers. Juridisch gezien zegt hij weinig nieuws; de regels over conformiteit bij producten bevatten immers geen uitzondering voor de software-delen van producten. Nieuw is wel… Lees verder

Moeten we echt elk jaar de copyrightvermelding in onze broncode updaten?

| AE 9248 | Intellectuele rechten | 23 reacties

Een lezer vroeg me: Alle broncodes binnen ons bedrijf hebben een copyrightvermelding, als volgt: Copyright © 2016 $NAAM THIS SOURCE CODE IS THE UNPUBLISHED AND CONFIDENTIAL PROPERTY OF $NAAM< AND MAY NOT BE COPIED, MODIFIED OR DISTRIBUTED WITHOUT PRIOR WRITTEN AUTHORIZATION. (Iets ingekort in verband met leesbaarheid.) Nu moet ik al die notices aanpassen want... Lees verder

Mag Spotify mijn SSD-schijven tot prut reduceren?

| AE 9077 | Informatiemaatschappij | 15 reacties

Oeps. De afgelopen vijf maanden (zo niet langer) heeft de Spotify app zo hard staan schrijven naar de ssd-schijven in telefoons dat deze járen aan levensduur zijn kwijtgeraakt. Dat las ik bij Ars Technica. Frequent schrijven naar ssd schijven is serieus Niet Handig aangezien dat voor grote slijtage zorgt. En nee, het ging niet om… Lees verder

Ben ik nog aansprakelijk als ik het IE op mijn software overdraag?

| AE 9038 | Intellectuele rechten, Ondernemingsvrijheid | 8 reacties

Een lezer vroeg me: Voor een klant heb ik maatwerksoftware ontwikkeld. Zij willen nu het intellectueel eigendom daarop verkrijgen. Op zich prima, alleen wil ik dan geen aansprakelijkheid meer voor fouten. Ik heb er dan immers geen controle meer over. Daar reageerden ze heel verbaasd op. Maar dit is toch geen gekke vraag? Nee, een… Lees verder

Je bent als bedrijf aansprakelijk voor stiekem geïnstalleerde software door je werknemer

| AE 8865 | Intellectuele rechten, Ondernemingsvrijheid | 28 reacties

Een werkgever is aansprakelijk voor illegale software geïnstalleerd door een werknemer, en daarbij maakt het niet uit of dat expliciet verboden was door de werkgever. Dat maak ik op uit een recent vonnis (via) van de rechtbank Rotterdam. Er is sprake van zogeheten risico-aansprakelijkheid: ongeacht wat je doet, je draait op voor eventuele inbreuken op… Lees verder

Mag een browserextensie je waarschuwen voor oplichters?

| AE 8707 | Intellectuele rechten, Uitingsvrijheid | 20 reacties

Afgelopen maand heb ik in de avonduren een chrome extensie ontwikkeld die op elke webpagina zoekt naar IBAN, telefoonnummer, e-mailadressen, las ik (dank, tipgever) bij Gathering of Tweakers. De poster was slachtoffer van oplichting geworden en ontdekte dat hij dit had kunnen voorkomen door even dergelijke gegevens door Google te halen. Vandaar de extensie: de… Lees verder

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Intellectuele rechten | 11 reacties

Een lezer vroeg me: Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen? De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT… Lees verder