[ethics] Realname policy excludes marginalized individuals. #3549

New Issue

GiteaMirror · 2025-11-02T05:16:47-06:00

GiteaMirror commented

2025-11-02 05:16:47 -06:00

Originally created by @jakimfett on GitHub (Jul 8, 2019).

Under the sign-off section in the contributing guidelines, this line caught my eye:

Please use your real name...

There's a lot of ignorance, reinforcement of marginalization, and failure to understand identity that are baked into the next few sentences:

...we really dislike pseudonyms or anonymous contributions. We are in the open-source world without secrets.

Requiring someone to reveal their "real" name to add anything to your source code brings up several questions:

Who defines 'real'?
How is 'real' determined?
What authority or registry are the names verified against?
Who has access to the metadata created by the signed, realname commits?
Why is 'real name' more important than identity consistency?
How do you process requests to remove a 'deadname' from the source?
At what point in the legal name change process is an individual 'allowed' to use their chosen name, vs their name assigned at birth?
What determines the difference between a pseudonym and a real name for people who have gone by the pseudonym for most of their life?
Does this mean that there is a list of real names for all current and past contributors, and if so, who curates that list?
Who is responsible for enforcing this portion of the policy?

I'd like to propose that these lines be excised, along with the realname policy, from the contributing guidelines document.

Originally created by @jakimfett on GitHub (Jul 8, 2019). Under [the sign-off section in the contributing guidelines](https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#sign-off-your-work), this line caught my eye: > Please use your real name... There's a lot of ignorance, reinforcement of marginalization, and failure to understand identity that are baked into the next few sentences: > ...we really dislike pseudonyms or anonymous contributions. We are in the open-source world without secrets. Requiring someone to reveal their "real" name to add anything to your source code brings up several questions: * Who defines 'real'? * How is 'real' determined? * What authority or registry are the names verified against? * Who has access to the metadata created by the signed, realname commits? * Why is 'real name' more important than identity consistency? * How do you process requests to remove a 'deadname' from the source? * At what point in the legal name change process is an individual 'allowed' to use their chosen name, vs their name assigned at birth? * What determines the difference between a pseudonym and a real name for people who have gone by the pseudonym for most of their life? * Does this mean that there is a list of real names for all current and past contributors, and if so, who curates that list? * Who is responsible for enforcing this portion of the policy? I'd like to propose that these lines be excised, along with the realname policy, from the contributing guidelines document.

GiteaMirror added the type/question label 2025-11-02 05:16:47 -06:00

GiteaMirror closed this issue

2025-11-02 05:16:47 -06:00

GiteaMirror commented

2025-11-02 05:16:48 -06:00

@techknowlogick commented on GitHub (Jul 9, 2019):

Thank you for asking these questions. The approach we are using with the DCO is what is used to protect everyone involved in the project (this includes users of Gitea, and also contributors/maintainers) from legal issues with regards to licensing of the intellectual property provided to the project.

The project does not have the legal resources to determine how best to accept this information, and so we must rely on larger projects (such as The Linux foundation who created the DCO) who have already engaged with lawyers. It does have issues, some of those issues you have mentioned above. Personally I have to rely on assuming good-faith from users who open PRs that what they are putting into commits is what is legally binding. Like the Linux Kernel, Git itself, and many other projects this information is stored directly, and as a matter of policy it is immutable, in git history. I would I recommend asking The Linux Foundation the the questions you have asked as they would be able to provide a better response than I could.

My personal goal is that the project moves to a way of providing a similar guarantee of assigning IP rights to the project under the terms of the license without special commit information, one such way that other projects use is a CLA. Switching to a CLA would involve legal advice, so I can't offer any timelines, nor can I guarantee that it will happen, but I can't say it won't happen either.

I want to thank you again for raising these concerns. As the majority of this ticket is questions I will now close it as we request that questions are directed to Discord (https://discord.gg/gitea) or the forum (https://discourse.gitea.io), but I will open a PR for documentation.

@techknowlogick commented on GitHub (Jul 9, 2019): Thank you for asking these questions. The approach we are using with the [DCO](https://developercertificate.org/) is what is used to protect everyone involved in the project (this includes users of Gitea, and also contributors/maintainers) from legal issues with regards to licensing of the intellectual property provided to the project. The project does not have the legal resources to determine how best to accept this information, and so we must rely on larger projects (such as The Linux foundation who created the DCO) who have already engaged with lawyers. It does have issues, some of those issues you have mentioned above. Personally I have to rely on assuming good-faith from users who open PRs that what they are putting into commits is what is legally binding. Like the Linux Kernel, Git itself, and many other projects this information is stored directly, and as a matter of policy it is immutable, in git history. I would I recommend asking The Linux Foundation the the questions you have asked as they would be able to provide a better response than I could. My personal goal is that the project moves to a way of providing a similar guarantee of assigning IP rights to the project under the terms of the license without special commit information, one such way that other projects use is a [CLA](https://en.wikipedia.org/wiki/Contributor_License_Agreement). Switching to a CLA would involve legal advice, so I can't offer any timelines, nor can I guarantee that it will happen, but I can't say it won't happen either. I want to thank you again for raising these concerns. As the majority of this ticket is questions I will now close it as we request that questions are directed to Discord (https://discord.gg/gitea) or the forum (https://discourse.gitea.io), but I will open a PR for documentation.

GiteaMirror commented

2025-11-02 05:16:48 -06:00

@jakimfett commented on GitHub (Jul 15, 2019):

Thank you, I appreciate the thorough reply.

@jakimfett commented on GitHub (Jul 15, 2019): Thank you, I appreciate the thorough reply.

GiteaMirror referenced this issue

2025-11-02 05:28:20 -06:00

AppWorkDir is really AppWorkPath #3851

Sign in to join this conversation.