From: Peter Backes <rtc@helen.PLASMA.Xg8.DE>
To: Philip Oakley <philipoakley@iee.org>
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 01:01:38 +0200 [thread overview]
Message-ID: <20180603230138.GA14956@helen.PLASMA.Xg8.DE> (raw)
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.
> > - 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.
> > - 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.
> > 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
next prev parent reply other threads:[~2018-06-03 23:01 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 [this message]
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
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=20180603230138.GA14956@helen.PLASMA.Xg8.DE \
--to=rtc@helen.plasma.xg8.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
/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).