Moodle Privacy (11): Ketenaansprakelijkheid en open source

Ketenaansprakelijkheid en open source, wat hebben die met elkaar te maken? Laat ik het duidelijk maken met een praktijkvoorbeeld.

Stel, u bent directeur van een opleidingsinstituut en uw organisatie gebruikt Moodle volop in de opleidingen. U heeft de hosting uitbesteed aan een Moodle dienstverlener die op haar beurt weer het beheer van de webservers heeft ondergebracht bij een hostingpartij met eigen servers in een datacenter.

U bent als opleidingsinstituut de opdrachtgever en dus gegevensverantwoordelijke. U bepaalt het doel van de verwerkingen, de soorten gegevens en wie de betrokkenen zijn (want dat heeft een checklist zo goed aangegeven…). Maar als gegevensverantwoordelijke bent u ook verantwoordelijk van de juiste verwerking door de Moodle dienstverlener (verwerker) en de hostingpartij (subverwerker). U kunt door de toezichthouder aansprakelijk worden gesteld bij een datalek, maar ook als deze plaatsvindt bij de verwerker of subverwerker. We hebben het hier over ketenaansprakelijkheid.

In een mailwisseling werd ik betrokken hoever deze ketenaansprakelijkheid gaat. Want kan een ontwikkelaar van een Moodle plugin aansprakelijk worden gesteld bij een datalek? Moodle is open source, maar ook de Moodle plugins worden uitgebracht onder de GPLv3 licentie. In deze licentie zijn in de artikelen 15 en 16 disclaimers van garantie en verantwoordelijkheid opgenomen. Maar artikel 17 uit de GPVv3 behandelt het feit dat lokale wetgeving dit anders mag regelen.

Nu ben ik geen jurist, maar mijn eerste reactie was: die ontwikkelaar verwerkt geen persoonsgegevens en zit dus niet in de keten. Daarnaast is het de verantwoordelijkheid van de opdrachtgever om te bepalen of een Moodle plugin ‘AVG-proof’ is. De enige vraag die ik heb is hoe het zit met een belangrijk principe van de AVG, namelijk ‘privacy by design’. Maar ik vermoed dat ook hier geldt dat de opdrachtgever verantwoording draagt.

Het is goed dat in de Moodle plugin database zichtbaar wordt welke plugins wel en niet de privacy API van Moodle hebben geïmplementeerd. Dan kan je als sitebeheerder betere keuzes maken welke plugins je gebruikt (of niet meer).