Op dinsdag 22 mei 2018 16:35:24 CEST schreef John Ralls: > > On May 22, 2018, at 6:02 AM, Geert Janssens <geert.gnuc...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
