Guidance to affiliated projects for achieving or maintaining GDPR compliance

This is primarily, I think, a question for the SPI Board, though if anyone else has thoughts on the subject, please do share.

On behalf of the OBF I am wondering whether SPI offers guidance, or counsel, to help its affiliated projects achieve (or maintain) compliance with GDPR requirements.

The relevant area that this issue probably applies most commonly for SPI member projects is user and developer mailing lists. Most of the OBF’s projects have one or both of these, and we (OBF) run those on server infrastructure of ours (more precisely, server infrastructure we rent from AWS) as a benefit to OBF member projects. We also subscribe OBF members to a private mailing list and email them occasional notifications from the OBF Board (such as upcoming public Board meetings).

The GDPR makes an emphasis on requiring people to be allowed to expressly opt-in rather than ability to opt-out. There are opinions out there that interpreted correctly this should mean to ask every pre-GDPR subscriber to expressly opt-in again, and not doing so might be non-compliant. (It’s frankly not my reading of it, but I’m not a lawyer nor legal counsel.)

Another thing we have been wondering is liability in the case of non-compliance of an SPI affiliated project and resulting fines, which can be quite expensive. Presumably these would come to SPI for payout? Would SPI charge fines it has to pay out against a project’s earmark balance? (Presumably yes.) And what if the fines exceed the earmarked balance?

Perhaps I’ve missed it, but overall I don’t think I’ve seen any substantive discussion here on this issue, despite the fact that at least in theory there could be substantial payout liabilities for SPI?

-hilmar
--
Hilmar Lapp -:- lappland.io