Does Gitlab's TOS updates affect Python-related GDPR Compliance?

Late 2019-10-24 Edit:
It appears, due to massive amounts of feedback, Gitlab has reverted the telemetry TOS updates until an unspecified future date. Discussion is ongoing in multiple-connected Gitlab issue threads.

Hello Everyone,

I have been a non-posting lurker for some time, so please forgive the brevity of my profile’s activity history.
I have also tried my best to search both this forum and the more general community forums for related discussion ahead of this post. I have also searched through relevant PEP discussion (507 comes to mind) for additional insight. If there is a more suitable (or existing) location for this discussion, I will happily transfer elsewhere.

As many already know, Gitlab has updated its Terms of Service announcing that they intend to implement mandatory telemetry. At this time, and based on the sparsely available communications from Gitlab, it appears that this TOS update forces users to opt-in to the telemetry (implementation appears to be a staggered rollout based on user subscription level.) Furthermore, if a user declines to opt-in, Gitlab says this will effectively break Gitlab web and API access for those users until they opt-in.

I am hoping someone within the core team, or the PSF, or the steering council would kindly inform those of us in the non-core community about how this situation might affect the Python language and its ongoing development work. Specifically, I am wondering how this TOS update might affect (or break) any Python development’s GDPR compliance. For example, would interacting with Python through Gitlab cause an unknowing user to submit to this new telemetry?

I am aware that most (almost all) Python development is source controlled through Github, which appears to be compliant based on available information. I personally have a number of products that require this compliance for legal marketability, and so this issue is understandably relevant and important.

I realize this post is somewhat out-of-the-norm for the majority of content here, so I thank you all in advance for offering insight in to the matter. It is my hope to avoid opinion-based judgements about Gitlab and their decisions, as already seen elsewhere.

Reference links:


Good question, and thanks for raising this issue.
I think this is outside of core team’s realm though…
Perhaps The PSF or PSF legal would be in better position to help?

1 Like

Thank you for a quick response. I have updated my original post to note that Gitlab has rolled backed the TOS telemetry updates apparently due to overwhelming feedback. They plan to re-implement at an unspecified future date.

Might be worth revisiting the issue at some point before that re-implementation, however.

Could you explain what you mean by this? If you’re voluntarily participating in CPython development then the onus is on you to accept and review the policies of the service being used, whether they be Github,, Travis CI etc.

If you’re just working offline then I don’t think any part of CPython development is tied to the hosting service (e.g you won’t accidentally interact with the Github API if you just build Python).

End users, e.g people running and developing Python code will never interact with CPython’s development workflow.

Happy to offer clarification for the sake of ongoing discussion.

  1. It appears that, while the TOS opt-in agreement notification went live yesterday, the actual code implementing the telemetry was merged into Gitlab’s origin/master several days prior. This could mean that potential GDPR compliance-breaking changes have already occurred without Gitlab endusers being aware.
  2. I understand and agree with your point about the onus being on devs to know what tools they use, but in real world practicality “the general majority” doesn’t read the TOS. Gitlab said they would “honor a browser’s [Do No Track setting]” without explaining the technical implementation. They also did not say if the unspecified third-parties which have access to the telemetry data will match Gitlab’s DNT honoring policy.
  3. In addition to #2, there doesn’t appear to be a completely fool-proof way to ensure all Python-related developers would follow all of the necessary steps to enable DNT, assuming we can take Gitlab at their word.
  4. As far as the forced opt-in policies a.k.a. “opt in by default,” there are a number of responses in the Gitlab issue threads which explain in much deeper and eloquent detail than I could hope to write here.

I’m neither a legal expert nor a core Python dev. I’m out of the loop when it comes to the finer details of things like the various Python libraries and their CICD, internal discussions related to GDPR compliance, etc. Which is why I was originally asking for clarification.

There is also another worthwhile discussion to be had about if Gitlab’s TOS changes, either now or in the future, warrant the removal of Python dev source control from the vendor altogether. Again, I’m merely a vested stakeholder without decision-making permissions. Thanks for your response, I hope this helps clarify in some way.

There’s no official Python development on GitLab. @barry has some projects over there which end up being pushed into the stdlib, but they are not officially part of Python’s direct development and so shouldn’t affect anyone (e.g. you would still file bugs at


I’m sorry, reading this thread I cannot help but think it is completely
irrelevant to the PSF and the core devs since we don’t use GitLab.

In a later post, you say:

"there doesn’t appear to be a completely fool-proof way to ensure 
all Python-related developers would follow all of the necessary 
steps to enable DNT"

When did it become the PSF’s mission to ensure that “all Python-related
developers” opt-out of GitLab’s telemetry?

We also manage the official ci-images over on GL, but again, that’s not part of CPython development.

I’m not a core dev or a lawyer, as far as I know, whatever is in the GitLab terms of service, it does not affect Python development.

This answers my original question. Thank you for the clarification.

1 Like