git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: GDPR compliance best practices?

From
PBPeter Backes <rtc@helen.plasma.xg8.de>
Date
Jun 3, 2018, 23:01 UTC
Message-ID
<20180603230138.GA14956@helen.PLASMA.Xg8.DE>
In-Reply-To
<5F80881E35F941E88D9C84565C437607@PhilipOakley>
On Sun, Jun 03, 2018 at 11:28:43PM +0100, Philip Oakley wrote:
> It is here that Article 6 kicks in as to whether the 'organisation' can
> retain the data and continue to use it.

Article 6 is not about continuing to use data. Article 6 is about having and even obtaining it in the first place.

Article 17 and article 21 are about continuing to use data.
> For an open source project with an open source licence then an implict DCO
> applies for the meta data. It is the legal  basis for the the release.

Neither article 6 nor 17 or 21 have anything remotely like an "implicit DCO" as a legitimization for publishing employee data.

The GDPR is very explicit about implicit stuff never being a basis for consent, if you want to imply that is your basis. And consent can be withdrawn at any time anyway.

An open source license has nothing whatsoever to do with the question of version control metadata. A public version control system is not necessary to publish open source software.

Show 5 quoted lines
> > - copyright is about distributing the program, not about distributing
> > version control metadata.
> It is specificaly about giving that right to copy by Jane Doe (but git gives
> no other information other than that supposedly globally unique 'author
> email'.

I don't get what you are saying. As I said, a public version control system is not necessary to publish open source software. The two things may be intimately related in practice, but not in theory.

Show 6 quoted lines
> > - Being named is a right, not an obligation of the author. Hence, if
> > the author doesn't want his name published, the company doesn't have
> > legitimate grounds based in copyright for doing it anyway, against his
> > or her will.
> Git for Open Source is about open licencing by name. I'd agree that a closed
> corporate licence stays closed, but not forgotten.

Again I don't get what you are saying. The author has a right to be named as the author, not an obligation. This has nothing whatsoever to do with the question of Open Source vs. closed corporate licenses.

Show 5 quoted lines
> > Let's be honest: We do not know what legitimization exactly in each
> > specific case the git metadata is being distributed under.
> 
> We should know, already. A specific licence [or limit] should be in place.
> We don't really want to have to let a court decide ;-)

It is insufficient to have a license for distributing the program. The license is not a GDPR legitimization for git metadata. Distributing the program can be done without distributing the author's identity as part of the metadata of his commits.

> The law is never decided by technical means, unfortunately.

It is. The GDPR refers to the state of the art of technology without defining it. Thus, technical means are very important in the GDPR. This may be something new for lawyers. If technology changes tomorrow, even without anything else changing, you may be breaking the GDPR by this simple fact tomorrow, while not breaking it today.

Again: Technology is very important in the GDPR.
> Regular git users should have no issues - they just need to point 
> their finger at the responsible authority.

If git users are putting commits online for global download, they are the responsible authority.

> The DCO/GPL2 are the legitimate data record that recipients should have for
> their copy. There is no right to be forgotten at that point.

What do you mean by "should have for their copy"? Why shouldn't there be a right to be forgotten? Open Source Software has been distributed a lot without detailed version control history information. Having this information as a record is certainly in the interest of the recipient, but it is very very questionable that it is an overriding legitimate grounds as per Art. 17 for keeping that data.

> I see the solution to be elsewhere, and that it is in some ways a strawman
> discussion: "if someone has the right to be forgotten, how do we delete the
> meta data", when that right (to delete the meta data in a properly licence
> repo) does not exist.

See, this kind of shady legal argument is what lawyers are selling you. Why not put the energy into designing a technical solution.

They tell you: "Ignore the GDPR. I will give you backup by giving you lots of disclaimers and excuses for doing so. Just give me a lot of money."

Having the ability to validate yet erase data form repositorys is desirable from a technical point of view. It has a lot of uses, not necessarily only legal ones. The objection of efficiency raised by Ted is a valid one. The strawman argument is not.

Best wishes Peter

-- 
Peter Backes, rtc@helen.PLASMA.Xg8.DE
Previous: Philip OakleyNext: Philip Oakley
Message 21 of 53 in “GDPR compliance best practices?”
  1. Peter BackesApr 17, 2018
  2. Ævar Arnfjörð BjarmasonApr 17, 2018
  3. Peter BackesApr 17, 2018
  4. Peter BackesJun 3, 2018
  5. Ævar Arnfjörð BjarmasonJun 3, 2018
  6. Peter BackesJun 3, 2018
  7. Ævar Arnfjörð BjarmasonJun 3, 2018
  8. Peter BackesJun 3, 2018
  9. Philip OakleyJun 3, 2018
  10. Peter BackesJun 3, 2018
  11. Theodore Y. Ts'oJun 3, 2018
  12. Peter BackesJun 3, 2018
  13. Peter BackesJun 3, 2018
  14. Theodore Y. Ts'oJun 3, 2018
  15. Peter BackesJun 3, 2018
  16. Theodore Y. Ts'oJun 3, 2018
  17. Peter BackesJun 3, 2018
  18. Theodore Y. Ts'oJun 4, 2018
  19. Peter BackesJun 4, 2018
  20. Philip OakleyJun 3, 2018
  21. Peter BackesJun 3, 2018
  22. Philip OakleyJun 4, 2018
  23. David LangJun 7, 2018
  24. Peter BackesJun 7, 2018
  25. Philip OakleyJun 7, 2018
  26. Peter BackesJun 7, 2018
  27. David LangJun 7, 2018
  28. Peter BackesJun 7, 2018
  29. David LangJun 7, 2018
  30. Peter BackesJun 8, 2018
  31. David LangJun 8, 2018
  32. Peter BackesJun 8, 2018
  33. David LangJun 8, 2018
  34. David LangJun 12, 2018
  35. Peter BackesJun 12, 2018
  36. Martin FickJun 12, 2018
  37. Theodore Y. Ts'oJun 13, 2018
  38. Peter BackesJun 13, 2018
  39. Theodore Y. Ts'oJun 8, 2018
  40. Peter BackesJun 8, 2018
  41. Ævar Arnfjörð BjarmasonJun 8, 2018
  42. Peter BackesJun 8, 2018
  43. Ævar Arnfjörð BjarmasonJun 8, 2018
  44. Theodore Y. Ts'oJun 8, 2018
  45. Peter BackesJun 8, 2018
  46. Johannes SixtJun 8, 2018
  47. Philip OakleyJun 9, 2018
  48. Theodore Y. Ts'oJun 10, 2018
  49. Philip OakleyJun 3, 2018
  50. Ævar Arnfjörð BjarmasonJun 3, 2018
  51. Peter BackesJun 3, 2018
  52. Jonathan NiederJun 8, 2018
  53. Ævar Arnfjörð BjarmasonJun 8, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.