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 13, 2018, 14:48 UTC
Message-ID
<20180613144818.GA28829@helen.PLASMA.Xg8.DE>
In-Reply-To
<20180613141218.GA28384@thunk.org>
On Wed, Jun 13, 2018 at 10:12:18AM -0400, Theodore Y. Ts'o wrote:
> Sure, but given that you are the one trying to claim that people need
> to do all sorts of extra development work (I don't see any patches

No. I am not. I said it is desirable to have a convenient solution for the problem. I did not demand development work or patches from anyone, just kindly asked for a comment on a possible solution.

> from you) and suffer performance degredation, the burden of proof is
> on _you_ to show that this is a problem that github, et. al., are
> likely run into.
*You* claimed there was performance degradation, not me.

That github et. al. will sooner or later receive such erasure requests is a practical certainty. Google receives them every day in large quantities. Just think about someone who committed smelly code on github and now wants to get a new job and wants to get rid of all associations with those smells.

> In particular, keep in mind that distribution of open source code can
> only be done under the terms of an open source license --- and a
> license is a contract.

Not that it would be relevant here, but, depending on jurisdication, it is highly controversial whether open source licenses really constitute contracts (or, for example, promissory estoppel).

For the right to erasure, it does not matter whether a contract exists or not.

The GDPR explicitly prohibits any use of contracts in a way that undermines the GDPR. Making it an irrevocable contractual obligation to publish the data is not going to be an excuse thus. And Free Software licenses have nothing whatsoever to do with repository metadata. Such software has existed long before version control became so popular.

> So in particular, your claim that the data is
> no longer necessary (point a) is at the very least going to be subject

No, it is github's claim that it must no longer be necessary for being erased, not mine!

I clearly stated that if ANY point (not: ALL points) is given, the data must be deleted.

Thus, point b, c, d or any other are just as good as point a.
> to dispute and is a legal question.  I can think of any number of ways
> that this could considered necessary in order to assure open source
> license compliance, the public interest in terms of allowing forking,
> etc.

To claim that the data is necessary (which is, as I said, irrelevant) and then say it's not because you can as well use a dummy user string, is self-contradicting.

> The bottom line is I'm sure the lawyers at github and Microsoft have
> very carefully done their due diligence, and if they are concerned,
> I'm sure we'll see patches from them, since after all, they would not

Why should they be concerned? They can rewrite history if necessary. They have a solution, though an inconvenient one. As far as the lawyers are concerned, that solution is pefectly fine.

Best wishes Peter

-- 
Peter Backes, rtc@helen.PLASMA.Xg8.DE
Previous: Theodore Y. Ts'oNext: Theodore Y. Ts'o
Message 38 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.