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

Hi Hilmar,

On Wed, Aug 22, 2018 at 01:04:36PM -0400, Hilmar Lapp wrote:
> This is primarily, I think, a question for the SPI Board, though if
> anyone else has thoughts on the subject, please do share.

I'll give a summary of the situation right now from my perspective as
SPI president, but indeed other people with useful thoughts to share are
encouraged to do so, whether board members or other members of the SPI
community.

> 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.

We currently have no guidance to share on this, although we are aware of
the issue and have it on our list of tasks to investigate. As a US
entity, our usual pro bono legal counsel is licensed to advise on US
(and by coincidence Indian) law, not EU/EEA law. Therefore they do not
have a standard answer ready for us and their other free software
community clients.

That said, we realize that the scope of GDPR is big enough to affect
some of our associated projects and quite possibly SPI's own activities.
Debian has made some partial efforts for their own compliance, such as a
contact address for data protection related inquiries. That's a good
idea that any project can do.

If anyone is interested in volunteering to help investigate this further
and developing guidance, do let the board know. But of course we will be
investigating with what resources we do have in the absence of new
volunteers.

One slightly reassuring thought: I don't think the various regulators
are interested in coming down quickly and harshly on any data controller
or data processor that's legitimately trying to do the right thing, and
doubly so for a community group like us or an associated project. So, we
should definitely do our best to comply, but equally we shouldn't panic.

> 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).

That's a good list of places where you might process personal data.

> 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.)

I'm not a lawyer or legal counsel either. My layman reading, not
speaking on behalf of SPI, is that fresh consent would be needed if the
old consent does not meet GDPR's requirements for valid consent, and if
you don't have another basis for processing their data. Otherwise old
consent or the alternative basis would still be fine.

> 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?

Unlike some other nonprofit hosts like the Software Freedom Conservancy,
associated projects do not become "part" of SPI. They retain their
independent existence, usually as unincorporated associations of
individuals, but SPI does hold legal ownership of certain project
assets in trust for the projects. The projects are the beneficial
owners.

Most likely, if a project violates the GDPR and is assessed fines, that
project's assets at SPI would be a valid place for those fines to be
collected. If required to pay fines for a project, we would certainly
take those fines preferentially out of that project's earmark balance
with us.

If the fines exceed that balance, we would see if there's a way for the
regulator to assess the excess fines against that project's non-SPI
assets, or to reduce the penalty to the amount of the project's assets
so as not to hurt our other projects. I can't predict right now whether
they'd be amenable to that.

But if we're required to pay a sum larger than the earmark for any type
of legal violation by a project, other projects might be impacted until
those funds are replenished. That's an inherent risk of a multiproject
fiscal sponsorship model like SPI's. For this type of reason, we are
wary about accepting projects with an especially elevated risk of legal
trouble. GDPR, of course, is generally applicable and not unique to any
project.

> 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?

The board has discussed it some, but in general, topics that related to
legal risks are rarely discussed on a publicly accessible and publicly
archived forum like spi-general. I think some meeting minutes or logs
have touched on it briefly.

- Jimmy Kaplowitz
jimmy(at)spi-inc(dot)org

Note that there's a mailing list about GDPR and FOSS. It's not been
active lately but the mailing list archives contain some interesting
conversations:

https://www.earth.li/mailman/listinfo/gdpr-discuss

--
Martin Michlmayr
https://www.cyrius.com/