Open source community calls in the wake of GDPR
I am a supporter of the intentions and sentiment behind the General Data Protection Regulation (GDPR) that came into force last month. However, it comes with some side effects.
Take community calls for the open source community, for example. Here’s how they often work:
- Agenda — someone with a level of responsibility within the project creates an agenda using a service you don’t have to login to access and to which everyone can contribute (e.g. Etherpad)
- Synchronous call — at the appointed time, those wishing to participate connect to some kind of audio and/or video conferencing services (e.g. Zoom)
- Recordings — those who are interested in the project but couldn’t participate at the time catch up via the agenda and recording.
I’ve been running community calls using this kind of approach for the last five years or so. It’s an effective method and a process I do so automatically, I didn’t even think about the GDPR implications.
Yesterday, however, I was informed (very nicely!) by Carlo Polizzi, Moodle’s DPO and Legal Counsel, that I needed to delete the data I’d collected in this way and find a new way to do this.
GDPR requires that (unless community members contribute anonymously) we must, at the very least:
- Gain consent from each individual that we can store their personal data and that they agree to our privacy policy.
- Inform individuals what that data will be used for and how long we will be storing it.
- Give them the option of withdrawing that consent at any time and having their data deleted.
This means, of course, that community members are going to have to register and then log in to a system that tracks them over time. I’ve written before about creating an architecture of participation for episodic volunteering. This certainly prevents more of a challenge for the ‘easy onboarding’ part of that.
So, not sure what to do, put up the Bat-Signal and asked my network. Out of that came suggestions to use:
- An encrypted etherpad solution that auto-deletes after a specified amount of time (e.g. CryptPad)
- Forum software that feels quite ‘realtime’ (e.g. Discourse)
- A Moodle course with guest access open (e.g. MoodleCloud)
On a more meta level, I also had some feedback that synchronous communication discriminates users for whom English isn’t their first language and/or who are disabled.
For now, given the above feedback, we’re going to end community calls in their current guise. I’ve met with Mary Cooch, Moodle’s community educator to discuss a few options for how we could do things differently, and we’re going to explore using the existing MoodleNet discussion forum at moodle.org along with BigBlueButton.
If you’ve got any questions, comments, or suggestions, I’d love to hear them, as this is something that many other open source projects are going to have to grapple with, as well!
Image CC BY-SA opensource.com
Are people sharing personal data in these community calls? Couldn’t you just anonymise the records?
It’s a good thought, but as a community call we want people to identify themselves to others. It builds trust.
As for anonymising afterwards, that’s possible with regular documents but not ones (like wikis, Google Docs, and Etherpads) that have revision histories…
It’s interesting to read this, it’s true that it’s a pain to change the format but I have to say that I agree with GDPR, specially because there is also video in community calls and some kind of consent should be necessary.
Having said that, wouldn’t it be possible to allow only logged in participants, and include in the registration form terms & conditions reggarding all of this? Login could even be enabled with Socials (Twitter, Google, etc) to make it easier.
I’m sure you’ve already thought of that because it’s the obvious solution. I guess the problem is with the necessity to delete data if requested? It isn’t nice, but I guess one “easy way” is to delete the entire recording if requested even by one participant…
Maybe another way of preserving video would be to upload it to ipfs so that it cannot be deleted (like d.tube). If everybody gives consent, would it be possible? In a sense “you” wouldn’t be storing it, because you don’t have ownership of the ipfs network.
It’s interesting, isn’t it? At first, it doesn’t seem reasonable to delete an entire recording because one person changes their mind about consent around data processing. On the other hand, I can empathise with someone who doesn’t want to be associated with a project any more.
In terms software IPFS, it’s a great idea, but as Carlo (Moodle’s DPO) told me, GDPR doesn’t care about the constraints of your technology. That’s why blockchain solutions are going to have a hard time with immutability and data subject requests for deletion…
I think that the first thing you need is a second opinion. The lawyer seems very over-cautious. It strikes me that what the lawyer is requiring go well beyond the provisions of GDPR.
p.s. I want to call my bank and have them delete any records they have related to me. Especially the ones that say I owe them money.
we wish we could all do that however right to erasure is not always applicable and depends on the lawful basis of processing https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/ (more detail https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/)
p.p.s. What I have learned over the years is to *never* ask a layer what course of action to take. The lawyer will always recommend the path of zero risk.
Instead, ask the lawyer what the risks are. Not “should I delete all my records” but “what are the risks if I delete all my records, and what are the risks if I do not.” Then *you* (not the lawyer) decide what path to take.
Lawyers aren’t managers and they should not be treated like managers. Lawyers provide advice and counsel, but managing should be left to actual managers and management processes.