[GNC-dev] GDPR and gnucash as a project

[Geert Janssens]

Op dinsdag 22 mei 2018 16:35:24 CEST schreef John Ralls:
> > On May 22, 2018, at 6:02 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:
> > 
> > Yesterday John raised some concerns about GDPR compliance of the gnucash
> > project itself.
> > 
> > This is a different question from the one Mike Evans asked in April this
> > year about GDPR compliance by people *using* gnucash.
> > 
> > This requires some thought as the GDPR has many aspects.
> > 
> > The essence of the GDPR (global data protection regulation) is to regulate
> > the processing of EU citizen's personal data.
> > 
> > The first question this raises is which personal data does the gnucash
> > project process ? So far I have come up with:
> > - e-mail addresses on the gnucash mailing lists
> > - user accounts in bugzilla
> > - user accounts in our wiki
> > - user accounts on Uservoice
> > The above are pretty clear. There are others that are less clear to me
> > whether they constitute personal data or not:
> > - the actual messages people send to mailing lists and which are stored in
> > a public archive
> > - the actual comments on bugs
> > - the actual page edits in wiki
> > And also what about things like our irc channel ? Does that fall under
> > processing personal data ? We don't really run the irc channel, we only
> > use
> > it. But on the other hand we do publish irc logs. Does GDPR apply to those
> > ? I can't tell really.
> > And the same question could be asked about our code itself in a way. Does
> > a
> > code contribution represent personal data ? Each commit logs an e-mail
> > address of a committer which can't easily be removed.
> > 
> > Once we have established what constitutes personal data we need to
> > formulate a "privacy policy" in which we explain how we process this data
> > and whether third parties are involved (think github, uservoice,
> > travis-ci, our social media presence,...).
> > 
> > An open source project is a bit in an odd situation because we do almost
> > everything in public so there's very little being kept private. We publish
> > archives of our mailing list conversations, irc logs, commits and so on.
> > We
> > have to inform our users of this in a clear manner. The good thing is we
> > only do keep the absolute minimum amount of information to function: a
> > username (which can be an e-mail address) and a password is usually
> > sufficient. Unless the message content also falls under personal data.
> > 
> > We also require explicit consent to use the personal data. We're
> > reasonably
> > good in this respect as for all services we offer we require the user to
> > opt- in. We will never use for example mail addresses gathered from
> > bugzilla user accounts to automatically enroll the same people in a
> > mailing list. We probably should more clearly indicate what people
> > subscribe to in each case while they are registering. So when registering
> > for a mailing list, it should be pretty clear that anything the person
> > contributes will end up on a public web page. The same goes for all other
> > services we offer and make use of.
> > 
> > Next a person should be allowed to make corrections to the personal data
> > we
> > were provided with and "the right to be forgotten". For user accounts in
> > the various services we offer this is not really a problem. Most of these
> > do allow the user to change passwords, user names or e-mail addresses.
> > However if the message content is also part of private data it becomes
> > much harder. In that case the question becomes whether a user can request
> > a mail message to be removed from our mailing list archive. I have no
> > answer to this.
> > 
> > Next there is the requirement to protect children. I don't know for sure
> > if
> > this applies to us. If it does our registration processes should ask a
> > minimum age and require consent of a parent or equivalent in order to
> > continue with the registration. This is mostly mentioned in the context
> > of social networks. But as we publish all communication in public it may
> > apply to us as well.
> > 
> > And finally in case of data breaches we should inform the affected people
> > of this. Again one I don't know exactly how to deal with.
> > 
> > This mail is meant as a kick-off to start thinking about this. Any
> > feedback is very welcome.
> 
> Some more considerations:
> 
> Uservoice data lives on Uservoice’s servers, not ours, and so GDPR
> compliance there is their problem.

Probably correct. As we don't use the personal data we collect from say 
bugzilla accounts to populate uservoice accounts, we are not passing 
information to a third party here. We do use the service but not likely to be 
responsible for the personal data they collect.
> 
> We have copied from Gnome’s BZ a bunch of names and email addresses for
> reporters, commenters, and developers on GnuCash bugs without those
> people’s permission. The GDPR permits collecting information without
> permission for “business necessity” so I think it’s legal;

I think so too. If we don't we won't be able to continue to manage our bugs 
after gnome shuts down their bugzilla. That sounds like a strong "business 
necessity". Moreover we continue to use the data for the same purpose: 
tracking bugs related to the gnucash product. We're not suddenly using the 
bugzilla email addresses to send newsletters or things like that. So I tend to 
think we are just migrating to a different platform not changing the user 
facing service it offers.

> it’s easy for a
> user to change their name and email in BZ, or for us to do so for them,
> meeting the “right to be forgotten” requirement.
> 
True.

> IRC includes IP addresses, which the GDPR explicitly mentions as personal
> information, in “joined” messages, and those get logged. ISTM those
> messages aren’t important as they’re not part of the conversation and we
> could easily stop logging them delete them from the existing logs.
> 
Yes, I think we should do that.

> We collect user names and emails for authenticating new users and
> transmitting their initial credentials. AFAIK we’re done with them after
> that; I don’t even know if the wiki retains them.
> 
> The “right to be forgotten” is pretty incompatible with Git: It includes the
> contributor’s name and email address in the commit and it becomes part of
> the blockchain. Removing it requires rewriting the blockchain which
> invalidates every other clone of the repository. Anonymizing contributions
> also makes it impossible to trace copyrights since we don’t require
> transfer of copyright and anyway have no entity to accept the transfer.
> 
Agreed. See also David T's reply and my reply to David. I don't think the GDPR 
and by extension "the right to be forgotten" apply here. The legal framework 
of copyright prevents these rights.

Geert