On Tue, Apr 17, 2018 at 11:38:26PM +0200, Ævar Arnfjörð Bjarmason wrote: > I've been loosely following a similar discussion around blockchains and > my understanding of the situation is that for a project such as say > Linux the GDPR gives you this potential out for that[1]: > > "the personal data are no longer necessary in relation to the > purposes for which they were collected or otherwise processed" > > I.e. you understand that when you submit a patch to linux.git how it's > going to get used, and that it's in a storage system that isn't going to > be pruned just because you ask for it. > [...] > You can make a compelling case that for say submitting your data to the > Bitcoin blockhcain the above quote from article 17 overrides it Well, you're quoting from lit. a but there's also lit. b to f! It says "one of the following grounds applies", not "all of ...". > This is very different from you say joining a company, committing to its > internal git repo, and your name being there in perpetuity, or choosing > to submit a patch to linux.git or git.git. > > I'd think that would be handled the same way as a structural engineering > firm being able to record in perpetuity who it was that drew up the > design for some bridge. Internal repo is entirely unproblematic, since you don't need consent for doing that. It is covered by Art. 6 (1) lit. f. The problem is public repos. Publishing employee information is generally considered not to be covered by Art. 6 (1) lit. f. After all, you can easily publish the software but not the repo. > I don't think it's plausible that the GDPR, > which is probably mainly going to be about consumer protection, is going > to concern itself with that in practice. Oh, no, GDPR is about privacy in general. It's not only about consumer protection. It applies in the same way to employees in relation to their employer and to citizens in relation to the authorities, and to open source contributors in relation to the projects, or to any other data processing outside family and friends (Art. 2 (2) lit. c). I am inclined to assume that Art. 6 (1) lit. b might be the solution, since the licenses typically demand a history of changes to be distributed with the program (for example, GPLv3 section 5 a). After all, the author generally wants to be given credit for his changes and it can be assumed that this one of the conditions for licensing the work in the first place. On the other hand, of course, the author could waive the condition at any time, which means Art. 6 (1) lit. b wouldn't apply anymore and you'd have the same issue as with consent-based processing of the information (lit. a). Best wishes Peter -- Peter Backes, rtc@xxxxxxxxxxxxxxxxxxx
