Of course since Phorge itself is a public project with, potentially, UK/EU contributors the signup/login page should really display such a warning.

Checking the Wikipedia entry for GDPR at https://en.wikipedia.org/wiki/General_Data_Protection_Regulation it mentions that this regulation or other similar ones have been enacted in:

The regulation became a model for many national laws outside the EU, including Chile, Japan, Brazil, South Korea, Argentina and Kenya. The California Consumer Privacy Act (CCPA), adopted on 28 June 2018, has many similarities with the GDPR.

Note that there needs to be a specific warning that changes to the code, commits, will be available for the life of the project.

I'd definitely recommend this change. Although I am not the best with legal mumbo jumbo, this would definitely be a must-have.

Definitely a good idea for anyone who wants to run Phorge in EU/UK or work with EU/UK contributors. Though it really is only necessary for the signup page - individual repositories really only have to worry about CLAs (if relevant).

I also think that it should be optional (easily disabled), as, for example, affected companies using Phorge only internally are likely to have employees sign a GDPR notice as part of their employment contract, and an additional GDPR notice in Phorge itself would be redundant.

The EU & UK GDPR provisions are very specific that each data gathering application must inform the user:

• What data is being gathered
• Why it is being gathered
• What it will be used for
• How long it will be retained

It also includes rules against blanket declarations such as some companies have been known to make.

Since the data being gathered is not the same as many companies general data gathering, e.g. HR Records and the period that it is to be retained for is likely different (the life of the software rather than the period of employment plus X years) each instance should probably have such information on the signup page, (and preferably in the wiki so that it can be reviewed &/or referenced later). In my opinion it does no harm to remind users outside of the UK/EU/etc. that their contributions will be retained and traceable to them for the entire life of the project(s) - personally I feel a warm glow thinking that my contributions will be identifiable as my contributions. It also means that if someone is intending to abuse the tool by making nefarious contributions &/or doing things like being abusive to other users then they cannot say that they didn't realise that it could be traced back to them which may help to reduce such instances.

So I would suggest that being able to easily disable such a notification is not a priority.

Yes, the GDPR notice must inform about each and every purpose specifically. But it must do so only once - that can be at sign up.

You do not need separate notices for each individual purpose and storage period. Again, employers generally tend to have their employees sign a GDPR notice that includes all the relevant purposes, and they have actual legal teams that write these GDPR notices.

My reasoning being that these employers, that actually do have in-house legal teams, will generally be able to craft a better GDPR notice for their purposes than we ever could here, and they should have the ability to not use Phorge's GDPR notice, without having to resort to modifying Phorge.

Considering that at least historically, Phabricator has prioritized professional teams backed by corporations, I would say that it is in fact a priority to have the ability to easily disable such notifications.

What about the public versions? It still should have a GDPR notification.

Yes, that's why I'm saying "yeah, great idea, let's do this, but let's also create a config toggle so that it can be disabled for people and orgs who don't need it".

@Labricator Definitely - as potentially contributors can be from anywhere in the world, including places with GDPR or equivalent legislation. (Note that I am In Wales, UK so would be covered). I am reasonably sure, not a lawyer remember, the legislation is written in such a way that you can't get away with things like "the data is stored somewhere without DGPR so it doesn't apply", etc.

Would it worth considering having multiple versions available with which is displayed determined by locale & language selection, (I18n & I10n). Then places with specific legislation could display the boilerplate or customised version and places without could, potentially, mention it with a link rather than having a specific sign-off and also linguistic problems could be addressed by the instance maintainer(s).

I18n is also fairly important from the point of view that citizens in certain jurisdictions are basically legally immune against documents written in a language different from the official language of their jurisdiction, so, +1 on that.

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

In T15033#1516, @gadgetsteve wrote:

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

What are the implications for Phroge? Anything?

@dcog Just:

1. You/We should probably already have a GDPR notification of some sort for this site
2. You cannot count on even large employers/organisations already having one.

An example can be found at https://docs.github.com/en/github/site-policy/github-privacy-statement and specifically for GDPR at https://docs.github.com/en/github/site-policy/github-privacy-statement#our-legal-bases-for-processing-information

We should either provide a mechanism for masking who contributed what to the information stored in an instance of Phorge, I don't think that this is totally practical for source code in git, hg, etc., or include notification of what information will be retained and make it clear that it will be retained indefinitely or for a specified period.

In T15033#1516, @gadgetsteve wrote:

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

I mean if we're doing examples, my current employer is the largest internet service company in the country (not ISP, think regional competitor to Google), and they had me sign a GDPR notice along with opt-in permission for purposes where this was feasible (for example, the ability to not appear on company photos, etc.). We're much smaller than in your example, in the hundreds of employees, rather than thousands.

Either way, I am not for dropping this feature, quite to the contrary. That's why I gave this the Heart award. I think it really is necessary to have this nowadays. What I am advocating for is a "Do not display GDPR notice" toggle somewhere in the configuration, so that organizations who already have that covered don't have to deal with patching the notice out from Phorge.

In T15033#1512, @golyalpha wrote:

Yes, that's why I'm saying "yeah, great idea, let's do this, but let's also create a config toggle so that it can be disabled for people and orgs who don't need it".

Ah, alright. I got a bit confused about what you were saying.