Tag: Saas

About Saas

Subscribe Feeds

Adobe zet je ontwerp op zwart (letterlijk) als je niet bijbetaalt voor kleurinformatie, wacht wat?

Geplaatst op in Ondernemingsvrijheid, 27 reacties
stux / Pixabay

Adobe-programma’s als Photoshop, Illustrator en InDesign hebben geen standaard toegang meer tot de meeste kleuren van Pantone, tenzij gebruikers daarvoor een abonnement afnemen. Dat meldde Tweakers onlangs. Wie dat abonnement niet neemt, krijgt zwarte vlakken waar eerst nog kleuren in de Pantone-kleurcoderingen stonden. Het verraste veel mensen, want hoezo kan Pantone auteursrecht claimen op een kleur? Dat kunnen ze ook niet, maar dankzij de wonderen van de cloud kan Pantone dit toch afdwingen.

Het bedrijf Pantone is marktleider in het vaststellen van kleurcoderingen, waarmee ontwerpers op eenduidige manier kunnen aangeven welke kleur bedoeld is. Dat lost bijvoorbeeld het probleem op dat een beeldscherm iets anders toont dan een printer produceert; als het bestand “PMS 012” vermeldt dan zal iedere drukker daar hetzelfde van maken. Een nuttige functie, waar wereldwijd op ingesprongen is en waardoor Pantone nu de dominante partij is in kleurcoderingen.

Het gaat natuurlijk om technische informatie: er zitten 2161 kleuren in het systeem, en van elke kleur is de hoeveelheid cyaan, magenta, geel en zwart vastgelegd. Ook krijgt elke kleur een naam, de Kleur van het Jaar 2022 is nummer 17-3938 en heet Very Peri (“Very Peri displays a spritely, joyous attitude and dynamic presence that encourages courageous creativity and imaginative expression”, aldus de jury).

Goed, leuk, maar is dat genoeg voor een auteursrecht? Ik betwijfel het zeer. Maar als je de hele lijst van 2161 kleuren mét code en naam neemt, dan denk ik dat daar wel een auteursrecht op rust. Wil je dus die hele lijst in je printer (of ontwerpprogramma) dan zul je een licentie moeten nemen. Fair enough, maar dat zou een eenmalig bedrag moeten zijn want het is absurd dat je jaarlijks betaalt voor zo’n lijst terwijl jouw klant het apparaat koopt of de software installeert op zijn desktop en daarvoor ook eenmalig betaalt.

Maar goed, toen kwam de cloud en werd alles anders (geen MLP referentie). Beter gezegd: Toen bedacht Adobe dat het veel leuker is dat je per maand betaalt voor haar tools, in plaats van eenmalig een enórme smak geld. En een paar jaar later dacht Pantone, dat kunnen wij ook. Vandaar dus die eis om maandelijks te betalen voor dat bestandje (en de merknaam), want als iemand zelf al aangeeft dat je per maand kunt betalen dan is als leverancier maandelijks afrekenen natuurlijk net zo logisch.

Heel erg juridisch is dit dus niet, dit is vooral een voorbeeld van hoe de cloud ingezet kan worden om nieuwe bedrijfsmodellen af te dwingen. En om diezelfde reden is er dus niets aan te doen, als je cloudtools gebruikt en de prijs gaat omhoog, dan kun je of betalen of wegwezen.

Arnoud

 

Hoe krijg ik security op de kaart bij mijn kinderopvang?

Geplaatst op in Informatiemaatschappij, Privacy, 5 reacties
congerdesign / Pixabay

Een lezer vroeg me:

Onze kinderen gaan naar de kinderopvang. Het bureau gebruikt hiervoor een SaaS-platform van een derde, met daarin dus alle persoonsgegevens (inclusief bsn en benodigde gezondheidsinformatie). Maar meer dan een wachtwoord wordt er niet gebruikt, en je mag zo te zien onbeperkt wachtwoorden proberen. Ik maak me daar grote zorgen over, ik zie dit zo gehackt worden. Wat kan ik doen, zijn er juridische middelen?
Er zijn vele, vele pakketten en diensten als deze. Nu we als maatschappij graag onze zaakjes zo veel mogelijk online willen regelen, is het logisch dat er allerhande portalen, apps en diensten komen waarmee dat kan. En die slaan dan dus al die gegevens op, die vaak wettelijk nodig zijn (zoals bsn bij kinderopvang) of waarzonder men niet kan werken (zoals allergie-gegevens).

Er zijn tegelijk maar weinig wettelijke kaders. De AVG is natuurlijk de bekendste. Deze bepaalt dat zulke gegevens goed beschermd moeten zijn, maar schrijft geen specifieke security-eisen voor. Je moet zelf, op basis van de situatie, de kosten en de te verwachten bedreigingen, een afweging maken om het zo goed mogelijk op orde te maken.

Er is ook geen toezichthouder die preventief je platform komt screenen of een audit komt uitvoeren. Of zelfs maar komt eisen dat jij een audit laat uitvoeren of wat dan ook. Wie het heel treurig wil formuleren, komt dus tot de conclusie dat alles AVG proof is totdat blijkt dat dat niet zo is. Door een hack of datalek dus. Ik word daar inderdaad niet vrolijk van.

En natuurlijk, dan mag de kinderopvang de rommel opruimen en de schade vergoeden. Want ook als ze dit zonder enige kennis van digitale zaken inkopen, zij blijven onder de AVG de verwerkingsverantwoordelijke en zij zijn aansprakelijk voor alles dat er mis gaat. (Op papier kunnen ze dat verhalen op de leverancier, of ze dit in de onderhandelingen van het servicelevelcontract afdwingen blijft natuurlijk giswerk.)

Als je als ouder een vermoedelijk datalek of ander probleem zit, kun je dat natuurlijk aankaarten. Alleen lastig: het bureau kan er niets mee, want die heeft de kennis niet. En de leverancier van het platform is vaak lastig bereikbaar voor de eindklanten, of heeft er weinig belang bij theoretische risico’s snel op te pakken.

Dus veel praktische oplossingen zijn er niet. Specifiek bij kinderopvang is er wellicht nog de route van de oudercommissie, die bij het bureau kan aankaarten dat er zorgen leven en of er wat anders bedacht kan worden. Mijn gevoel is dat bij veel van dergelijke commissies de zorg om digitale veiligheid niet heel hoog is, maar het is het proberen waard.

Arnoud

Welke responstijd heeft een SaaS-dienst zonder SLA?

Geplaatst op in Ondernemingsvrijheid, 6 reacties

Een lezer vroeg me:

Ik ben een kleine ondernemer en net gestart met een software-as-a-service dienst. Het voelt nog wat vroeg om harde SLA’s aan klanten aan te bieden, maar waar sta ik als dat niet doe? Aan welke getallen zit ik dat vast, hoe bereken je dat?
Een service level agreement of SLA is bedoeld om concrete afspraken te maken tussen een leverancier en afnemer, bijvoorbeeld over beschikbaarheid van een SaaS-dienst of de reactiesnelheid bij problemen of storingen. Dat concrete is handig, omdat je dan geen discussie krijgt over “te laat” of “te langzaam” iets oppakken. Daar staat natuurlijk tegenover dat je dan wel concreet dat getal moet leveren, ook als dat eigenlijk niet past bij je bedrijf. Dus ik snap dat kleine bedrijven dit liever niet doen.

Als je geen expliciete afspraken maakt, dan kom je als hoofdregel uit bij wat de wet de redelijkheid en billijkheid noemt. Je ziet dat ook wel in de algemene voorwaarden van SaaS-diensten: Leverancier zal zich inspannen een redelijk niveau van beschikbaarheid te leveren. Dat is genoeg, het enige is natuurlijk dat je dan bij een klagende klant héle lange discussies kunt krijgen over wat een redelijk niveau is en waarom jouw downtime op dinsdagmiddag 14:30 daar wel of niet onder valt.

Aanvullend geldt daarbij de gewoonte (art. 6:248 lid 1 BW), wat je kunt zien als wat gebruikelijk is in de branche waarin je opereert. Als daar een bepaald percentage gebruikelijk is, dan moet jij dat ook leveren. Ik ken alleen niet echt dergelijke gebruiken in welk deel van de software-as-a-service markt, ik zou juist willen zeggen dat de gewoonte is om zonder SLA alleen zo’n “redelijk inspannen” toezegging te doen.

Het is overigens prima om een getalsmatige toezegging te doen zonder een ding van twintig kantjes dat “Service Level Agreement” heet erbij te leveren. Leverancier zal zich inspannen de beschikbaarheid per maand op 98% of meer te houden. En vaak zie je dat het de klanten niet eens gaat om die beschikbaarheid, maar om andere dingen:

  • Leverancier zal onderhoud beperken tot de nachtelijke uren en/of het weekend.
  • Leverancier zal onderhoud met downtime vooraf aankondigen.
  • Leverancier zal Klant continu op de hoogte houden van de voortgang van het wegnemen van het probleem.
Ik zou als kleine ondernemer dan ook eerder daarvoor kiezen. Je klanten worden een stuk tevredener als ze weten dat jij ze persoonlijk begeleidt en informeert, en echt zelf ook wil dat ‘ie het nu weer doet.

Arnoud

Ben ik verwerker bij de accounts van mijn klanten?

Geplaatst op in Privacy, 7 reacties

Een lezer vroeg me:

Zoals heel veel SaaS-diensten bied ik accounts aan voor bedrijfsmatig gebruik: één account per gebruiker, maar gekoppeld via een bedrijfsabonnement. Ben ik nu verwerker voor de gegevens in die accounts?
Het valt me inderdaad op dat vele SaaS-dienstverleners denken dat ze verwerker zijn omdat ze persoonsgebonden accounts hebben. Dat is alleen te kort door de bocht. Mogelijk komt dit door een spraakverwarring: je verwerkt dan wel persoonsgegevens, maar je bent pas verwerker als je dat doet in opdracht van een ander (de verwerkingsverantwoordelijke).

Wanneer ik een dienst afneem, en daarbij zijn mijn persoonsgegevens nodig (bijvoorbeeld voor een account + facturatie, of voor het tonen van mij als gebruiker aan andere gebruikers) dan is de dienstverlener gewoon de verwerkingsverantwoordelijke. Hij bepaalt immers wat er gebeurt met die gegevens van mij: waar worden ze getoond, wie heeft er toegang toe en waar mogen ze worden ingezet.

Ik zou die dienst namens mijn bedrijf kunnen afnemen. Dan kunnen ook collega’s een account krijgen binnen het bedrijfsaccount, en normaliter betaal ik dan maar één keer. Dit verandert alleen nog niets aan de situatie voor verwerkerschap: de dienstverlener bepaalt nog steeds wat er gebeurt met al die persoonsgegevens, van zowel mij als van mijn collega’s. Hij blijft dan dus verwerkingsverantwoordelijke.

Een dienstverlener wordt verwerker wanneer het verwerken van de persoonsgegevens onderdeel is van de dienst, want het juridisch criterium is dat ik als klant doel en middelen vaststel. Het triviale voorbeeld is een personeelsadministratie: ik upload dan een set personeelsgegevens met bijvoorbeeld loongegevens, en de SaaS-dienst genereert loonstroken. Voor die set is men dan verwerker, want ik bepaal wat ik upload (welke personeelsleden, welke gegevens) en waarom (ik wil loonstroken).

De accounts om toegang te krijgen tot de dienst zijn volgens mij geen onderdeel van de dienst, zodat daarvoor geen verwerkersovereenkomst met de klanten nodig is. Zolang de leverancier/dienstverlener zelf bepaalt wat hij doet met die accounts, is hij daar zelf verwerkingsverantwoordelijke voor.

Arnoud

Waarom willen klanten van SaaS-maatwerk toch altijd het IE hebben?

Geplaatst op in Intellectuele rechten, 19 reacties

Een lezer vroeg me:

Ik ontwikkel SaaS-oplossingen op maat, op basis van mijn eigen basisapplicatie. Elke keer weer krijg ik discussie met de klant (meestal zijn advocaat, trouwens) dat ze het IE van het maatwerk willen hebben. Als ik dan zeg dat ze daar niets aan hebben, omdat ik de basisapplicatie in beheer heb, dan krijg ik vaak een glazige blik en “we willen het toch want we betalen er voor”. Waarom is dat toch steeds het standpunt van juristen? Dit is toch volstrekt niet logisch?

Deze discussie komt mij zeer bekend voor, en inderdaad kun je je afvragen of het wel het standaard uitgangspunt moet zijn dat je als klant eigenaar moet worden (pardon, houder van de auteursrechten) van iets dat je op maat laat maken dat bovenop een bestaande SaaS-oplossing komt staan. Ik kan er eigenlijk geen directe reden voor bedenken en je maakt het jezelf als opdrachtgever nodeloos moeilijk.

De traditionele reden om eigenaar te willen worden van maatwerk is zodat je er zelf mee verder kunt. Dit komt uit de tijd dat applicaties 99% maatwerk waren, en dan is het natuurlijk logisch om dat te eisen. Maar hoe meer standaardwerk er in de software zit, hoe lastiger dat standpunt is vol te houden. Ja, je kunt dan escrow van de standaardsoftware hanteren omdat je dan “verder kunt” met het geheel. Maar bij SaaS is broncode-escrow vrij zinloos, omdat je zó veel meer hebt dan alleen de software.

Meer algemeen is altijd de vraag, is het echt goedkoper om deze kant op te gaan? Waar haal jij tegen die tijd de developers vandaan die zich snel in kunnen werken in die applicatie om jou continuïteit te garanderen? Ik geef het je te doen met de complexiteit van applicaties vandaag de dag.

Een andere reden is dat men denkt het maatwerk te zijner tijd bovenop een ander stuk standaardwerk te kunnen monteren. Daar kan ik alleen maar “moehaha” op zeggen.

Van een geheel andere orde is de motivatie dat men niet wil dat de ontwikkelaar diezelfde functionaliteit verkoopt aan de concurrent. Immers als ik 100 uur werk betaal en de opdrachtnemer geeft dat werk vervolgens gratis aan de concurrent omdat hij daar een toffe indruk wil wekken, dan word ik wel een beetje boos ja. Ook al heb ik gekregen waar ik voor heb betaald, namelijk 100 uur werk en een keurig werkend stukje maatwerk.

Als dat het bezwaar is, dan is er echter nog een andere oplossing en dat is gewoon exclusiviteit afspreken. Dan zeg je, ditzelfde werk mag je de komende drie/zes/twaalf maanden niet doen voor de concurrent. Dan heb je meteen ook het geval gevangen dat de dienstverlener gewoon opnieuw de maatwerksoftware schrijft – iets dat mag van het auteursrecht, zolang hij maar geen copypaste doet. Natuurlijk zal de ontwikkelaar wel geld eisen voor deze verplichte omzetderving, maar dan heb je volgens mij de eerlijke discussie over wat je wilt en wat dat mag kosten.

Een variant op dit bezwaar is dat het maatwerk gebaseerd is op vertrouwelijke informatie (zoals een bedrijfsproces of koppeling met iets geheims). Dan zou hergebruik van het maatwerk de geheimhouding schenden. Maar dan is het antwoord simpel: nou ja, dat mag niet want we hebben vertrouwelijkheid afgesproken. En er zit genoeg in het maatwerk dat niét onder de vertrouwelijkheid valt, over het algemeen.

Helaas is een té vaak voorkomende reden dat men het wil omdat het in de inkoopvoorwaarden staat. En ja, die zijn door een duur kantoor opgesteld of daar moet op heel hoog niveau toestemming voor afwijken worden gehaald dus dat kan dan niet anders. Dit zijn de lastigste discussies in de praktijk.

Ik zie voor de ontwikkelaar twee oplossingen:

  1. Auteursrecht op het maatwerk behouden met het argument dat het toch onbruikbaar is buiten de basisapplicatie. Wel krijgt de klant exclusiviteit op het maatwerk gedurende bv. 12 maanden, zodat er geen zorg is dat de concurrent het meteen ook krijgt. Kostprijs kan omlaag als de periode korter wordt.
  2. Auteursrecht overdragen en bepalen dat de onderliggende ideeën en principes vrij blijven voor de ontwikkelaar. Dat mag van de auteurswet toch al (45k Aw) mits je dus geen broncode hergebruikt.

Wie optie 1 scherp wil insteken, neemt twee prijzen op in de offerte waarvan de laagste is gemarkeerd met “zonder exclusiviteit” en de tweede “met 12 maanden exclusiviteit”. Dit is mijn standaard contractentruc maar het werkt nog steeds als een tierelier, zelfs wanneer de dure advocaat van de wederpartij de truc kent.

Arnoud

Mijn werkgever blokkeert mijn thuisverbinding omdat ik een TOR relay heb

Geplaatst op in Ondernemingsvrijheid, 21 reacties

Een lezer vroeg me:

De dienstverlener van een SaaS administratie-pakket voor de zakelijke markt blokkeert/blacklist de thuisverbinding van een werknemer omdat deze een TOR node draait. De helpdesk weigert dit IP-adres te whitelisten en stelt dat de werknemer zichzelf van de blacklist zal moeten laten verwijderen, wat zou betekenen dat de node offline moet. Mag dit?

Deze manier van werken is me opgevallen bij een aantal SaaS-pakketten. Ik vermoed dat er iemand op security-cursus is geweest en daar leerde dat er met TOR nare dingen gebeuren, zodat het beter is om verkeer vanaf TOR te weren. Dus IP-adressen die óók een TOR node zijn, mogen dan niet inloggen.

Inderdaad gebeuren er rare en strafbare zaken via TOR, maar dat is onvermijdelijk met een netwerk dat opgezet is voor volledig anonieme communicatie. Maar wat je daar verder ook van vindt, ik zie niet hoe het relevant is bij het kunnen inloggen op een SaaS-tool. Ik snap dat je aanvallers wil weren, maar uiteindelijk doe je dat door een adequate authenticatieprocedure.

En oké, als je verkeer vanúit TOR wilt weren dan snap ik dat ergens – dat kan een wachtwoorddief zijn die zijn sporen wil wissen, en welk bedrijf zou standaard willen dat zijn werknemers inloggen via TOR? Maar hier gaat het over IP-adressen die óók een TOR node zijn, maar waarvan de login los staat van TOR.

Tegelijkertijd, wat doe je er aan als klant? Want dit soort dingen zijn -zeker in de zakelijke contractensfeer- prima zo af te spreken dat de dienstverlener het mag. Als die ervoor kiest om alleen als Nederlands bekend staande IP-adressen toe te laten bij de inlog, dan zit je als zakelijke klant op vakantie in Thailand inderdaad met een blokkade. En dan staat men in haar recht. Dit nog los van het punt dat je niet gaat procederen over een dergelijke bagatel, want de kosten zijn hoger dan de baten.

Arbeidsrechtelijk nog wel een interessante: kan ik als werkgever van een werknemer in deze situatie eisen dat zhij stopt met die TOR node? Kennelijk moet zhij thuis kunnen werken (anders is het probleem niet relevant voor het werk) en kennelijk is het contractueel redelijk dat de leverancier hem weert gezien die node. Het hindert het werk, wat die werknemer doet. Daar staat tegenover dat ik als werkgever vrij weinig te maken heb met zo’n privéhobby.

Wat zouden jullie de werkgever adviseren?

Arnoud

Moet je echt bij elke internetdienst een bewerkersovereenkomst sluiten?

Geplaatst op in Privacy, 12 reacties

Een lezer vroeg me:

Wij maken zakelijk gebruik van applicaties en software in de cloud. Mijn vraag is nu echter of je echt met iedere cloud leverancier een bewerkersovereenkomst moet afsluiten? Iedere applicatie verwerkt namelijk op de een of andere manier wel persoonsgegevens, de ene meer dan de ander. In sommige gevallen gaat het enkel om het e-mail adres en inlog gegevens. En soms wéét je het niet, zoals bij chatdiensten (Yammer of Slack). Daar kunnen mensen best persoonsgegevens intypen. Wat zegt de wet?

Dit is inderdaad een lastige kwestie. Heel formeel moet dit inderdaad altijd, bij iedere derde die in jouw opdracht persoonsgegevens opslaat van jouw personeel of klanten. De wet eist namelijk dat je bij elke bewerker een bewerkersovereenkomst sluit waarin je apart regelt welke eisen omtrent persoonsgegevens hij moet nakomen (en hoe jij dat gaat borgen en auditten).

Een bewerker is iedereen die in jouw opdracht persoonsgegevens verwerkt en niet zelfstandig bepaalt voor welke doelen (of met welke middelen). De meeste clouddiensten laten aan de klant over wat er gebeurt met klantdata en kiezen dus niet zelf de doelen. Over de middelen-keuze kun je twisten, maar uiteindelijk is dat denk ik ook een klantkeuze: die klikt op knop A of activeert feature B, de dienstverlener is daar passief.

Het is een discussie of dat ook geldt als de derde niet wéét dat je persoonsgegevens gaat aanleveren. Extreem voorbeeld is Pastebin: daar kun je teksten plakken die dan gepubliceerd worden. Ik kan daar persoonsgegevens plakken, maakt dat Pastebin een bewerker?

Als er echter gestructureerde velden zijn voor persoonsgegevens (al is het maar jouw gebruikersnaam etc) dan voldoet deze partij aan de definitie van bewerker en moet er dus een bewerkrsovereenkomst komen. Doe je dat niet, dan ben jij in overtreding van de Wbp – zij het dat daar géén boete op staat. Het voornaamste risico is dat jij de claims krijgt als de bewerker data lekt of iets anders verkeerd doet, en dat je dan geen verhaalsmogelijkheid hebt.

Veel van dit soort partijen zijn Amerikaans en kennen het concept bewerkersovereenkomst (“Personal data processing agreement”) eigenlijk niet. Sommigen willen graag Europese business en tekenen met liefde, anderen vinden het maar onzin en reageren niet eens op de vraag. Het is dan dus een risico-afweging voor jou.

Onder de aankomende Privacyverordening (ADV: koop dat boek) zal dit mogelijk veranderen. De Verordening zegt namelijk dat ook de bewerker aansprakelijk is voor boetes en schade als er geen bewerkersovereenkomst – pardon, verwerkersovereenkomst – is tussen hem en de verantwoordelijke. In hoeverre dat afdwingbaar is tegen Amerikaanse partijen is natuurlijk een heel andere vraag.

Arnoud

En nu eisen sitevoorwaarden ook al je eerstgeboren kind op

Geplaatst op in Informatiemaatschappij, 7 reacties

ie-aagree-ezelGaan we weer: hee kijk, niemand leest websitevoorwaarden, zelfs als je erin zet dat je je eerstgeboren kind moet afstaan, gaat iedereen blindelings akkoord. Dat las ik bij Ars Technica. Leuk nieuwtje weer, maar wat mij betreft nieuwswaarde nul.

Al sinds het begin van internet staat iedere site bol van de gebruiksvoorwaarden. Ergens wel logisch, want er was bar weinig geregeld. Bovendien kwamen de eerste commerciële sites uit Amerika, en daar staat sowieso alles dichtgetimmerd met voorwaarden. Dus dat schept een precedent, zeker bij sitebouwers die denken “het zal wel moeten” en de tekst van de vorige site copypasten. Sorry, ja, ik ben wat cynisch.

Hoe dan ook, iedere site heeft dus voorwaarden. Ze komen allemaal op ongeveer hetzelfde neer: doe normaal en zeur niet. Ah sorry, ga ik weer. Ze komen allemaal op hetzelfde neer: je mag de dienst gebruiken, hij kan wijzigen of uit de lucht zijn, wij zij niet aansprakelijk en als je je wangedraagt dan gooien we je er van af. Precies – zeur niet en doe normaal.

Omdat ze allemaal hetzelfde zijn, en vooral omdat je in de praktijk toch weinig verhaal hebt, leest geen hond die voorwaarden. Je kent de site van reputatie, je weet dus ongeveer wat moderatoren of auteurs gaan doen en je merkt het wel als je foto wordt geblokkeerd of je bijdrage wordt aangepast wegens schending voorwaarden. Daar heb je die voorwaarden niet voor nodig. Ook niet omdat uiteindelijk er altijd staat “naar ons inzicht”, dus hoe dan ook hebben ze gelijk. Zeur niet.

Dit experiment bewijst dus niets nieuws, wat mij betreft. Het is een feit van algemene bekendheid dat voorwaarden niet worden gelezen. Desondanks: je zit er in principe wél juridisch aan vast. Het zijn algemene voorwaarden zoals de wet dat noemt, en die zijn ook bindend als ze niet worden gelezen. Zolang je ze maar had kúnnen lezen. Dat je dan twee jaar van je leven kwijt bent met al die voorwaarden is juridisch niet relevant.

Omdat het dan wel érg hard door kan schieten – ze zouden eens je eerstgeboren kind kunnen opeisen – kent de wet daar een paar correctiemechanismes voor. Algemene voorwaarden mogen niet onredelijk bezwarend zijn. Zo mag een dienst niet zomaar zijn aansprakelijkheid op nul zetten, dat is onredelijk bezwarend zonder héle goeie reden. De voorwaarden ineens 100% omgooien is ook onredelijk. En voor zaken als kinderen opeisen is er een nóg hardere juridische stok om mee te slaan: overeenkomsten in strijd met de openbare orde of goede zeden zijn nietig. Bestaan niet. Je kúnt niet contracteren dat je kind wordt afgestaan.

Vervelend blijft uiteindelijk wel dat je daarvoor naar de rechter moet. En als je dat niet weet of niet ziet zitten, dan kun je een probleem hebben als de site toch die voorwaarden gaat handhaven. Denk aan het opeisen van maandbedragen of het eisen van een schadevergoeding voor het een of ander. Dat is natuurlijk niet specifiek voor sitevoorwaarden, maar het is wel een probleem.

Wat mij betreft schaffen we het hele zootje dan ook zo snel mogelijk af, in ieder geval voor consumenten. Dat hebben we in feite al gedaan bij de ecommerce: het is wettelijk vrijwel 100% geregeld wat je mag als webwinkel. Je kunt alleen nog in het voordeel van de consument dingen anders doen, zoals een dertigdagenretourtermijn in plaats van de wettelijke veertien. Waarom doen we dat nog steeds niet voor online diensten?

Arnoud

Is de Amazon cloud nu wel veilig voor Europese persoonsgegevens?

Geplaatst op in Informatiemaatschappij, 13 reacties

simpsons-cloud-diefstal-data-fotoDe Europese privacytoezichthouders hebben Amazon’s clouddienst privacytechnisch goedgekeurd, las ik op diverse media. Daarmee zou Amazon Web Services ineens da juridische bomb (oké, The Register) zijn.

Het ligt iets subtieler: de contracten waaronder Amazon werkt, zijn voorzien van juridische clausules over export en gebruik van persoonsgegevens door Amazon. En die clausules zijn goedgekeurd, zodat Amazon voldoet aan de Europese regels op dat punt.

Wie persoonsgegevens wil laten verwerken door een ander, moet een bewerkersovereenkomst sluiten met die ander. Daarin wordt vastgelegd wat de bewerker (de opdrachtnemer, Amazon dus) mag doen met persoonsgegevens, wat hem verboden is en op welke manier hij de persoonsgegevens moet beveiligen.

Export van persoonsgegevens naar buiten de EU is daarbij een speciaal geval. Dit mag eigenlijk niet, tenzij het ontvangende land een net zo strenge wet heeft over persoonsgegevens als de EU. En geen enkel land buiten de EU heeft dat. Gelukkig zijn daar wat uitzonderingen op. Eén uitzondering ontstaat als je met je bewerker afspraken maakt conform de modelcontracten die de EU ooit heeft opgesteld. En de toezichthouders hebben nu dus bepaald dat Amazon’s contracten conform die modellen zijn.

Het wil echter niet zeggen dat het gebruik van de Amazon cloud zonder meer goed voor de privacy is. Er blijft nog altijd die ene angel bestaan waar Microsoft zich aan gestoken heeft: de Amerikaanse rechter vindt dat zij de macht heeft het Amerikaanse Microsoft te bevelen data af te geven die bij haar Europese dochters opgeslagen staat. Microsoft vecht dit aan, maar er zijn goede redenen waarom die rechter gelijk kan hebben.

Arnoud

Ik wil een kopie van mijn clouddata van de curator!

Geplaatst op in Informatiemaatschappij, 42 reacties

disc-data-weg-bewaren-kruis.jpgEen lezer vroeg me:

Wij nemen een clouddienst af waar onze klantdata (contactgegevens en dergelijke) mee beheerd wordt. Maar nu is de clouddienstverlener failliet en de dienst dus uit de lucht. De hostingpartij heeft nog wel een kopie van de data, maar hij wil deze niet afstaan tenzij we fors gaan betalen. De curator wil ook geen data afgeven. Wat kan ik doen? Die data is toch ons eigendom?

Nee, die data is niet je eigendom. Die data is juridisch helemaal niets en daarom valt er dus niets te eisen omtrent die data.

Het hosten van data is voor de wet een vorm van dienstverlening. Dat daarbij bits worden gemanipuleerd, is leuk maar juridisch niet relevant. Afgezien van specifiek virtuele objecten in digitale werelden is data niet iets dat voor eigendom in aanmerking komt, omdat het daar niet tastbaar genoeg voor is.

Afspraken maken dus. De dienstverlener moet “de zorg van een goed opdrachtnemer in acht nemen”, staat in de wet. Vandaag de dag mag je daar wel uit concluderen dat hij moet zorgen voor toegang tot data, bij voorkeur in een algemeen leesbaar formaat. Zo kun je backups maken van je data voor een eventuele migratie of calamiteit zoals faillissement. (Hoewel dit nog nooit bij de rechter bevestigd is en menig clouddienstverlener data opsluit in een eigen formaat waarna je er alleen via hun tools bij kunt.)

Alleen: bij faillissement houdt alles op wat je contractueel hebt afgesproken. De curator heeft maar één taak en dat is de schuldeisers tevreden stellen. Als hij daarbij wanprestatie moet plegen, dan is dat toegestaan. Een contractuele afspraak dat je bij faillissement gauw een kopie mag downloaden, is dus het papier niet waard waar deze op afgesproken is.

Met de hoster valt wellicht wat af te spreken. Die is niet failliet dus die zou een kopie van de data kunnen geven. Maar omdat je daar niet al een contract mee had, is hij daartoe niet verplicht en zou hij zijn kans schoon kunnen zien even wat verlies goed te maken. Beter is dus dit vooraf af te spreken, bijvoorbeeld via de stichting Continuïteit (waar ik bestuurslid van ben).

Wellicht heb je auteursrecht op de data. Ook dat gaat niet helpen: het is geen inbreuk op auteursrecht of databankrecht om te weigeren toegang tot een kopie van het werk te verschaffen. Dat weten we uit een rechtszaak in mei waarbij de toegang tot een databank werd geblokkeerd door de dienstverlener. “Geen toegang tot de gegevens” hebben is niet het soort schade waar deze intellectuele-eigendomswetten voor gemaakt zijn.

Een goede backupstrategie en/of afspraken met hoster en dienstverlener zijn dus de enige middelen om dit probleem op te lossen. En als je dat pas achteraf wilt regelen, dan gaat het een hele dure grap worden.

Arnoud