Clarify "real name" when contributing via DCO #383
Comments
|
I don't know what it should look like and I am not an expert in this area, but I do know our community is expected to be one of the most inclusive and implementing processes or policies that remove the choice of participation regardless that is the intent or 'just' an effect - it is debilitating to our growth, diversity, innovation. The security community has long used pseudonyms and it still thrives. There should be no reason to continue a practice bc others have done it or bc we've always done it. I expect us to break new ground, be different, that's what makes cloud native. |
|
I at least need clarification on whether the reason behind "real name" is to link individual liability or not. |
|
This has per-country legal complications too - some countries don't strictly have a "legal name" (e.g the UK) |
|
Hi @dims, @caniszczyk pointed me to this issue and asked me to clarify what I had provided last Friday. it wasn’t clear to me in #379 that this is what you were asking about and my response was without awareness of your interest in the broader question raised in this issue. The DCO is a representation by someone stating they have the right to contribute the code they have proposed for acceptance into a project. That representation is important for legal purposes and was the community-developed outcome after a $1 billion lawsuit by SCO against IBM. The representation is designed to prevent issues but also keep the burden on contributors low. It has proven very adaptable to other projects, is built into git itself (and now also GitHub), and is in use by thousands of projects to avoid more burdensome requirements to contribute (such as a CLA). The real name should be a real one that can be used to identify the person making the representation. It's not required to be a legal name, your name on a passport, a birth name, or anything official, but a real name such that someone in the community would be able to find the person if an issue with the code they contributed were ever to arise. There is also an email address, but emails don't always work forever, especially as people change jobs. The point is to be able to identify the real person, regardless of their birth name, legal name, etc. Anyone can use the real name people in the community know them as. The point is to avoid anonymous ids, fake names, or throwaway pseudonyms such as ABC123 at anonymous123@mail.ru from contributing intellectual property with no path for the community to identify who that contributor was - if and when an issue were to arise. If a patent dispute broke out over ABC123's contribution - how would we ever identify them? If CNCF wants to go beyond the kernel documentation to explain this, that would be fine to do. It could be a statement along the lines of the following (just a quick draft, could probably use improvements):
|
|
Thank you to everyone who has voiced their opinions on this thread! This topic is very close to my heart and I couldn't agree more with the comment by @TheFoxAtWork that ran along the lines of "let's not keep doing something just because we've always done it this way". @mkdolan is exactly right about why code attribution is necessary. There is no doubt that tracking each and every contribution back to the contributor is needed, however there are a number of ways in which this may be achieved without necessarily publishing real names. @dims in the original post listed a few alternatives for keeping track of a contributor, without expecting them to disclose their real name in a public repo. I am a big advocate for some of these alternatives to be considered! I can give an example of the use case that I am working with. A number of people in my product group are very keen to contribute to open source projects - and in fact PARSEC is one that we want to engage with in the near future - but will not do so if it means publishing their real names, and the current CNCF contribution policy does not allow pseudonyms or anonymous contributions. As a product group - and as an employer - we can keep an internal record of each contributor's name, and allow that person to use a pseudonym in public. As long as the employer is trusted to keep that persistent record and to release the real names if required - e.g. in case some piece of code is contested - then a solution of this sort would satisfy the requirements. Perhaps another way to look at it is to state the overarching rule that requires code attribution and be open to look at ways of fulfilling it on a case-by-case basis? |
#383 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
|
Thank you everyone for the valuable feedback, we have clarified this in an official doc https://github.com/cncf/foundation/blob/main/dco-guidelines.md |
@justincormack Does it also apply to Linux Foundation projects not under the CNCF? If so, that's great news, and the kernel docs should be updated. |
cncf/foundation#383 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Context:
We had a issue opened a week ago - #379
Which resulted in an update from CNCF staff as to what the current policy was:
cncf/toc@4b5d504
However, talking to community folks who currently are already contributing, there are a bunch of questions/concerns:
Looks like other LF projects have tried a failed before [1]. However could we do better than those projects that were simply not as diverse to avoid harm[2] and be more welcoming than those projects?
As one person eloquently put:
for the people who raised this concern about anonymity, the choice is not between contributing with their real name or a pseudonym, the choice is between contributing or not contributing at all. For a person who cannot have their name in public, requiring them to go public in order to be part of an OSS project, in effect excludes them from that project.For reducing the scope of this discussion, let us limit this set of questions to DCO for now. As a community, we petition the GB and Legal Committee to take a look at this more carefully and deliberately.
(Please don't close this as WONT-FIX / WORKING-AS-INTENDED unless we get an official word from GB + Legal Committee)
Also see traffic on CNCF-TOC mailing list as well - https://lists.cncf.io/g/cncf-toc/topic/92137934
[1] https://wiki.hyperledger.org/display/TSC/DCO+and+Pseudonyms
[2] https://en.wikipedia.org/wiki/Deadnaming
cc @parispittman @RichiH (as Developer Reps in GB)
The text was updated successfully, but these errors were encountered: