Re: GDPR compliance best practices?

From: Peter Backes <rtc@helen.plasma.xg8.de>
Date: Jun 3, 2018, 17:46 UTC
Message-ID: <20180603174617.GA10900@helen.PLASMA.Xg8.DE>
In-Reply-To: <6BE308009FFA4CCDB5B3B47C2AC53E20@PhilipOakley>

On Sun, Jun 03, 2018 at 04:28:31PM +0100, Philip Oakley wrote:

Show 5 quoted lines

> In most Git cases that legal/legitimate purpose is the copyright licence,
> and/or corporate employment. That is, Jane wrote it, hence X has a legal
> rights of use, and we need to have a record of that (Jane wrote it) as
> evidence of that (I'm X, I can use it) right. That would mean that Jane
> cannot just ask to have that record removed and expect it to be removed.

Re corporate employment:

For sure nobody would dare to quesion that a company has a right to keep an internal record that Jane wrote it.

The issue is publishing that information. This is an entirely different story.

I already stressed that from the very beginning.

Re copyright license:

No, a copyright license does not provide a legitimization.

- copyright is about distributing the program, not about distributing 
version control metadata.

- 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.

> From a personal view, many folk want it to be that corporates (and open
> source organisations) should hold no personal information with having
> explicit permission that can then be withdrawn, with deletion to follow.
> However that 'legal' clause does [generally] win.

Let's be honest: We do not know what legitimization exactly in each specific case the git metadata is being distributed under.

It may be copyright, it may be employment, but it may also be revocable consent. This is, we cannot safely assume that no git user will ever have to deal with a legitimate request based on the right to be forgotten.

> In the git.git case (and linux.git) there is the DCO (to back up the GLP2)
> as an explicit requirement/certification that puts the information into the
> legal evidence category. IIUC almost all copyright ends up with a similar
> evidentail trail for the meta data.

This makes things more complicated, not less. You have yet more meta data to cope with, yet more opportunities to be bitten by the right to be forgotten. Since I proposed a list of metadata where each entry can be anonymized independently of each other, it would be able to deal with this perfectly.

> The more likely problem is if the content of the repo, rather than the meta
> data, is subject to GDPR, and that could easily ruin any storage method.
> Being able to mark an object as <Lost/Deleted> would help here(*).

My proposal supports any part of the commit, including the contents of individual files, as eraseable, yet verifiable data.

Show 6 quoted lines

> Also remember that most EU legislation is 'intent' based, rather than
> 'letter of', for the style of legal arguments (which is where some of the UK
> Brexit misunderstandings come from), so it is more than possible to get into
> the situation where an action is both mandated and illegal at the same time,
> so plent of snake oil salesman continue to sell magic fixes according to the
> customers local biases.

This may be true. I am not trying to sell snake oil, however. To have erasure and verifiability at the same time is a highly generic feature that may be desirable to have for a multitude of reasons, including but not limited to legal ones like GDPR and copyright violations.

> I do not believe Git has anything to worry about that wasn't already an
> issue.

Yes, but it definitely had and still does have something to worry about.

git should provide technical means to deal with this. I provided a proposal based on anonymization that does not in any way have any drawback compared to the status quo, except a slight increase in metadata size and various degrees of backwards incompatibility, depending on how it is implemented.

What do you think about my proposal as a solution for the problem?

You provide a lot of arguments about why it is not a necessity to have this, but let's assume it is; is there any actual problem you see with the proposal, except that someone would have to implement it?

Best wishes Peter

-- 
Peter Backes, rtc@helen.PLASMA.Xg8.DE