I just got one of those GDPR mails from gitlab.com, which pointed me to a Web page where I had to accept some terms and conditions. The same as everywhere, except this passage:

(For GitLab Contributors Only) As part of my voluntary contribution to any GitLab project, I acknowledge and agree that my name and email address will become embedded and part of the code, which may be publicly available. I understand the removal of this information would be impermissibly destructive to the project and the interests of all those who contribute, utilize, and benefit from it. Therefore, in consideration of my participation in any project, I hereby waive any right to request any erasure, removal, or rectification of this information under any applicable privacy or other law and acknowledge and understand that providing this information is a requirement under the agreement to contribute to the GitLab project.

As far as I understood GDPR, this passage is just plain bullocks and they're trying to get away with arguably the most difficult bit of GDPR, especially if you consider their argument. I can feel their pain, but it also just doesn't feel like this is made possible by GDPR and if GitLab would deny or not completely fulfil such a deletion request, it would be liable to litigation. Am I correct in this?

Note: I'm not trying to put GitLab in a bad spot here, they're just the first (only?) ones that included this kind of passage in their agreement.

  • 9
    GitLab is probably referring to how git includes your name and email in every commit you make. To remove them would mean modifying the history of every change that was made to all projects since your first commit in each. That's indeed very destructive. This would mean that the next time someone syncs their copy of the project with GitLab, it would potentially show all the history of the project since your first commit as diverging and one would be left to figure out what part of their local history to move GitLab's new history, and how. I expect GitHub and others to have the same problem. – JoL May 25 at 21:40
  • See also: GDPR + git history – unor May 28 at 5:08
up vote 63 down vote accepted

Yes, their waiver has no legal basis and is invalid under the GDPR. They should have hired a better lawyer.

GDPR rights cannot be waived (mrllp.com).

The last bit should have been:

Therefore, in consideration of my participation in any project, I understand that retaining my name and email address, as described above, does not require my consent and that the right of erasure, as spelled out in the GDRP Article 17 (1) b does not apply. The legal basis for our lawful processing of this personal data is Article 6 (1) f ("processing is necessary for the purposes of the legitimate interests pursued by the controller").

I.e. there is nothing in the GDPR that compels GitLab to erase this information, but their waiver is bogus.

Keeping track of individual contributions in a software projects is necessary for a number of reasons, including security (if somebody contributes code that jeopardizes security, you want to audit everything that person has contributed).

  • 5
    OK, so it is made possible by GDPR to keep these people's names in history. I wondered what kind of impact this would have had to open source software, but now it seems limited. Thanks for this bit of information! – rubenvb May 25 at 6:14
  • 16
    People saw the "consent" basis and went bananas, ignoring all the other legitimate bases for data processing. – pjc50 May 25 at 10:20
  • 3
    I was about to go off on a rant about how this is an example of why the whole "right to deletion" thing is fundamentally unethical and this being a perfect example of why, but apparently the law stopped short of breaking all legitimate reasons for indefinite historical record keeping, sooo... I still stand by my thesis but the rant is postponed. +1 for citing example legalese and bringing attention to this reasonable provision for exceptions in the law. – mtraceur May 25 at 21:06
  • 4
    @chrylis: That would be really fun with Mercurial's append-only history modification (TL;DR: Instead of throwing away rewritten commits after the GC period expires, Mercurial marks them obsolete, hides them from view, and persists them forever in clones that knew they existed. This is useful for a number of reasons but also means full obliteration has to be done locally in each clone -- there's no git push --force equivalent. So you can't automate it without local shell access everywhere.) – Kevin May 26 at 3:43
  • 13
    Fast work. For the curious, GitLab has already integrated this change (not worded precisely as in this answer but close). – Wildcard May 26 at 4:33

(Please note that I an a random guy on the internet, not a lawyer)

Although the GDPR seems rather ill-conceived, they managed to cover this part OK:

(3) Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:

...

e) legal claims.

It's already established that contributions to software are an act of writing, making you the author, with author rights and copyrights that have been established in law over the course of the past 500 years. The copyright can be granted or sold (automatically if someone is paying you for it), but the author rights cannot be waived. (The idea being someone cannot sue an author and legally take their authorship away, even if the author owes them money).

Thus the record of who-wrote-what is a legal claim and cannot be removed.

I can feel their pain, but it also just doesn't feel like this is made possible by GDPR and if GitLab would deny or not completely fulfil such a deletion request, it would be liable to litigation. Am I correct in this?

GitLab does not have the right to edit a contributor list to a codebase they do not own. It would be illegal for them to fulfill a deletion request. GDPR does not apply to the contributor list.

  • 6
    +1. One nuance to note is that "copyright being granted/sold" is an American-esque construct, and many countries consider copyright inalienable, and in those countries, a similar effect is achieved with authorship-for-hire by unlimited and perpetual licensing. Also I don't know if there really is a legal conflict between authorship claims being special in the case of the author themselves wanting such claims deleted, but if there is then a version control system's commit history is also effectively a list of authorship claims, to my non-lawyer intuition. – mtraceur May 25 at 21:10
  • 10
    "Although the GDPR seems rather ill-conceived" Maybe stick to the facts, a lot of people - including me - wholeheartedly disagree on this. – Polygnome May 25 at 22:02
  • 3
    "GitLab does not have the right to edit a contributor list to a codebase they do not own" -- although a note to anyone who is hoping to evade GDPR by simply writing everyone's personal data into a document and selling the copyright in that document to a third party so that "we don't own this data and therefore cannot remove your personal data from it": that won't work, you'll still get fined. If the court thought that's what was going on then, as a last resort, GitLab could be directed to delete the whole document, at which point they may or may not discover that they can edit it after all ;-) – Steve Jessop May 26 at 13:16
  • 5
    @mtraceur "many countries consider copyright inalienable": you're thinking of moral rights; that does not apply to other aspects of copyright protection, which can be granted or sold anywhere. Furthermore, moral rights include a right not to be publicly identified as the author of a work, so the idea that moral rights forbid a data processor from removing identifying information from a work of authorship is ill founded. See en.wikipedia.org/wiki/Moral_rights. The "record of who wrote what" must be removed if the author requests it, for copyright purposes and for GDPR. – phoog May 26 at 13:22
  • 2
    @Steve Jessop - The personal data wouldn't be part of a legal claim in that case. So the first request for removal should to the owner of the codebase, second request to GitLabs, similar to how it would work today if someone decided to upload a Harry Potter book onto GitHub. They can lock/delete the whole repo, but they can't just start editing the code inside files. – IKM May 27 at 12:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.