From: Peter Backes <rtc@helen.PLASMA.Xg8.DE>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: "David Lang" <david@lang.hm>,
"Philip Oakley" <philipoakley@iee.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: GDPR compliance best practices?
Date: Wed, 13 Jun 2018 16:48:18 +0200 [thread overview]
Message-ID: <20180613144818.GA28829@helen.PLASMA.Xg8.DE> (raw)
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
next prev parent reply other threads:[~2018-06-13 14:48 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 19:15 GDPR compliance best practices? Peter Backes
2018-04-17 21:38 ` Ævar Arnfjörð Bjarmason
2018-04-17 23:25 ` Peter Backes
2018-06-03 9:27 ` Peter Backes
2018-06-03 10:45 ` Ævar Arnfjörð Bjarmason
2018-06-03 11:25 ` Peter Backes
2018-06-03 12:59 ` Ævar Arnfjörð Bjarmason
2018-06-03 14:18 ` Peter Backes
2018-06-03 15:28 ` Philip Oakley
2018-06-03 17:46 ` Peter Backes
2018-06-03 18:18 ` Theodore Y. Ts'o
2018-06-03 19:11 ` Peter Backes
2018-06-03 19:24 ` Peter Backes
2018-06-03 20:07 ` Theodore Y. Ts'o
2018-06-03 20:52 ` Peter Backes
2018-06-03 21:03 ` Theodore Y. Ts'o
2018-06-03 22:16 ` Peter Backes
2018-06-04 13:47 ` Theodore Y. Ts'o
2018-06-04 18:22 ` Peter Backes
2018-06-03 22:28 ` Philip Oakley
2018-06-03 23:01 ` Peter Backes
2018-06-04 12:24 ` Philip Oakley
2018-06-07 1:38 ` David Lang
2018-06-07 6:32 ` Peter Backes
2018-06-07 21:28 ` Philip Oakley
2018-06-07 22:34 ` Peter Backes
2018-06-07 22:38 ` David Lang
2018-06-07 23:21 ` Peter Backes
2018-06-07 23:53 ` David Lang
2018-06-08 6:16 ` Peter Backes
2018-06-08 7:42 ` David Lang
2018-06-08 11:58 ` Peter Backes
2018-06-08 18:51 ` David Lang
2018-06-12 18:56 ` David Lang
2018-06-12 19:12 ` Peter Backes
2018-06-12 19:16 ` Martin Fick
2018-06-13 14:12 ` Theodore Y. Ts'o
2018-06-13 14:48 ` Peter Backes [this message]
2018-06-08 2:53 ` Theodore Y. Ts'o
2018-06-08 6:26 ` Peter Backes
2018-06-08 8:13 ` Ævar Arnfjörð Bjarmason
2018-06-08 12:03 ` Peter Backes
2018-06-08 22:53 ` Ævar Arnfjörð Bjarmason
2018-06-08 14:45 ` Theodore Y. Ts'o
2018-06-08 16:02 ` Peter Backes
2018-06-08 22:09 ` Johannes Sixt
2018-06-09 22:50 ` Philip Oakley
2018-06-10 1:41 ` Theodore Y. Ts'o
2018-06-03 17:54 ` Philip Oakley
2018-06-03 19:48 ` Ævar Arnfjörð Bjarmason
2018-06-03 20:24 ` Peter Backes
2018-06-08 22:42 ` Jonathan Nieder
2018-06-08 23:00 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180613144818.GA28829@helen.PLASMA.Xg8.DE \
--to=rtc@helen.plasma.xg8.de \
--cc=avarab@gmail.com \
--cc=david@lang.hm \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).