git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Peter Backes" <rtc@helen.PLASMA.Xg8.DE>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: GDPR compliance best practices?
Date: Mon, 4 Jun 2018 13:24:04 +0100	[thread overview]
Message-ID: <31E7614B606B48909B9E850E62926979@PhilipOakley> (raw)
In-Reply-To: 20180603230138.GA14956@helen.PLASMA.Xg8.DE

Hi Peter,
(lost the cc's)

From: "Peter Backes" <rtc@helen.PLASMA.Xg8.DE>
> 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.

Correct, and that is the part I was refering to. Recipients of the
particular meta data require it for the licencing purpose. Thus they can
continue to have (and 'need') that data. It is that 'other side of the 
fence'
view I mentioned.

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

I was refering to 'implict' in a reverse direction, that is, the DCO
supports the legal basis to have and hold the data. The express licence
terms in the various open source licences give the permission, and becomes
one of these legally conflicting aspects

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

Such is the law. It's the practice that is legal/illegal, decided in court
(if it gets there)

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

The question is which clause is being used to justify an action. Those
corporate organisations want a legal basis for holding data, not a voluntary
permisson (because folk may try and rescind that permission... ). Those in
open source want to ensure that their licence is a legal basis for other
folk to have copies, and that folk can show they have that permission.

Those with a personal data view, will focus on the hope that they can remove
permission, especially for companies that are doing things they find
unacceptable, and maybe 'illegal' or unethical. The GDPR attempts to balance
the different set of expectaions, and the overlaps will need to be
negotiated. Different nations (and individuals) have different perceptions
as to what is normal and reasonable thus focus on different aspects, not
appreciating the Competeing Values that are present in the different
Frameworks of their weltanshauung.

If a closed source corporate does publish their closed data, they have real
internal problems anyway regarding that contradiction!

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

They will still argue about what is the state of the art, and that if the
art is hidden in some lab, then it's not available to meet the criteia.

> Again: Technology is very important in the GDPR.

We know quantum computing can crack the codes, but.... when does it become
the state of the art. SHA1 has been 'cracked' once in one special case, but
that doesn't make it state of the art for cracking a Git repo. It is a
problem about fooling some of the people some of the time which needs to
become [not fooling] most of the [appropriate] people most of the time. That
is what the owners should have known.

Some of this is, unfortunately, also about legal systems as to their
approaches to law and evidence, so UK maybe responding differently to
Germany, or USA, as to what even the words mean.

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

It isn't an absolute GDPR right

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

So your agument is that you/someone can make someone else guilty of an
offence by demanding they destroy evidence that proves their innocence.
>
>> 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."

It's: make sure you understand all sides of the GDPR. There is a lot of FUD
from all sides.

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

Efficiency would not be a valid argument. A major annoyance, yes. Something
that likely would stop open source contributers working on it, yes. But just
as ALARP is used in safety to say spend what it takes, if slowing down the
processing is what it takes to meet the GDPR then do it, so companies (and 
those
that do the processing) would have to fund that.

Thanks

Philip


  reply	other threads:[~2018-06-04 12:24 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 [this message]
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
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=31E7614B606B48909B9E850E62926979@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=rtc@helen.PLASMA.Xg8.DE \
    /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).