Hi Peter, David,
I thought that the legal notice (aka 'disclaimer') was pretty reaonable.
Some of Peter's fine distinctions may be technically valid, but that does
not stop there being legal grounds. The proof of copyright is a legal
grounds.
Unfortunately once one gets into legal nitpicking the wording becomes
tortuous and helps no-one.
If one starts from an absolute "right to be forgotten" perspective one can
demand all evidence of wrong doing , or authority to do something, be
forgotten. The GDPR has the right to retain such evidence.
I'll try and comment where I see the distinctions to be.
From: "Peter Backes" <rtc@xxxxxxxxxxxxxxxxxxx>
Hi David,
thanks for your input on the issue.
LEGAL GDPR NOTICE:
According to the European data protection laws (GDPR), we would like to
make you
aware that contributing to rsyslog via git will permanently store the
name and email address you provide as well as the actual commit and the
time and date you made it inside git's version history.
This is simply an information statement
This is inevitable,
because it is a main feature git.
The "inevitable" word creates a point of argument within the GDPR. Removing
the word (and 'because/main') brings the sentance back to be an informative
statement without a GDPR claim.
As we can, see, rsyslog tries to solve the issue by the already
discussed legal "technology" of disclaimers (which is certainly not
accepted as state of the art technology by the GDPR). In essence, they
are giving excuses for why they are not honoring the right to be
forgotten.
Disclaimers do not work. They have no legal effect, they are placebos.
The GDPR does not accept such excuses. If it would, companies could
arbitrarily design their data storage such as to make it "the main
feature" to not honor the right to be forgotten and/or other GDPR
rights. It is obvious that this cannot work, as it would completely
undermine those rights.
The GDPR honors technology as a means to protect the individual's
rights, not as a means to subvert them.
If you are concerned about your
privacy, we strongly recommend to use
--author "anonymous <gdpr@xxxxxxxxxxx>"
together with your commit.
The [key] missing information here is whether rsyslog has a DCO (Developer
Certificate of Origin) and what that contains.
The git.git DCO is here
https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L304-L349
This will also help discriminate between the "name" part and the <unique>
identifier, as both could be separately anonymised (given the right DCO).
Thus it may be that the name is recored as "anonymous", but with a
<uid@known.place> that bridges the legal evidence/right to be forgotten
bridge.
This can only be a solution if the project rejects any commits which
are not anonymous.
However, we have valid reasons why we cannot remove that information
later on. The reasons are:
* this would break git history and make future merges unworkable
This is not a valid excuse (see above).
Within the GDPR, that is correct. It (breaking history validation), of
itself, should not be the reason.
The technology has to be
designed or applied in such a way that the individuals rights are
honored, not the other way around.
In absence of other means, the project has to rewrite history if it
gets a valid request by someone exercising his right to be forgotten,
even if that causes a lot of hazzle for everyone.
* the rsyslog projects has legitimate interest to keep a permanent record
of the
contributor identity, once given, for
- copyright verification
- being able to provide proof should a malicious commit be made
True, but that doesn't justify publishing that information and keeping
it published even when someone exercises his right to be forgotten.
Publishing (the meta data) is *distinct* from having it.
However publishing the content and it's legal copyright is also associated
with identifying the copyright holder (who has released it). This can be the
uid if they hide behind a legal entity. This creates the catch 22 scenario.
You either start off public and stay public, or you start off private and
stay there.
Whether the rsyslog folk want to accept copyrighted work without appropriate
legal release (who guards the guards, what's their badge number?) is part of
the same information requirement.
Malicious intent makes the submission (commit) part of a legal evidence one
needs to retain, so is supported by GDPR.
In that case, "legitimate interest" is not enough. There need to be
"overriding legitimate grounds". I don't see them here.
Please also note that your commit is public and as such will potentially
be
processed by many third-parties. Git's distributed nature makes it
impossible
to track where exactly your commit, and thus your personal data, will be
stored
and be processed. If you would not like to accept this risk, please do
either
commit anonymously or refrain from contributing to the rsyslog project.
The onward publishing and release should be by refernce to the DCO, and not
that it's the Git way. As Peter notes, the 'Git way' (solely by itself) is
no defence.
This is one of those statements that ultimately say "we do not honor
the GDPR; either accept that or don't submit". That's the old, arguably
ignorant mentality, and won't stand.
The project has to have a legal basis for publishing the personal
metadata contained in the repository. In doubt, it needs to be consent
based, as that is practically the only basis that allows putting the
data on the internet for everyone to download. And consent can be
withdrawn at any time.
The GDPR's transitional period started over two years ago. There was
enough time to get everything GDPR compliant.
It might be possible to implement my solution without changing git,
btw. Simply use the anonymous hash as author name, and store the random
number and the author as a git-notes. git-notes can be rewritten or
deleted at any time without changing the commit ID. I am currently
looking into this solution. One just needs to add something that can
verify and resolve those anonymous hashes.
To me, the key legal document is the DCO (and the law on which it stands).
It is that which either conveys the rights, or does not. If the DCO is too
loose then folk will be able to walk away from their malign code, and demand
that someone else take responsibility for protecting them from it.
Philip
