There are a number of issues that have been raised, either directly or tangentially, including:
Q1: Can we have an effective CLA based on a GH username rather than an email or a signature?
A1: Yes, we can. The applicable law (for the US, which is the relevant jurisdiction here) is that electronic signatures can be used for these purposes. An electronic signature is very broadly defined to include any “symbols or other data in digital form attached to an electronically transmitted document as verification of the sender’s intent to sign the document.” So a GH username can be used to authenticate a document if it is the intent of the person for their username to do so. However, we should update our CLA text to make the intent explicit.
Q2: Do we have to have the person’s legal name and address?
A2: No, the law does not require the person’s legal name and address. However, it would make it easier to track someone down in case we had an issue. Ultimately this is a risk management question, not a legal question. We may want to have a heightened verification process for anyone who is on the core team.
Now, the really tricky one (as noted by @kpfleming, among others):
Q3: Does using the GH username change the risk profile for Python?
A3: Yes, it does. It makes it more likely that an individual CLA (ICLA) will be used when what we really want is a corporate CLA (CCLA).
Q4: Why does this matter?
A4: This really gets to the core of why we have a CLA - it is mostly (but not entirely) there to protect Python against a situation where someone contributes something to Python that they did not own due to their employment status. Random developers - even high level ones - do not have the authority to out-license the organization’s IP. It must come from someone with authority. In practice that means someone from legal, someone VP or higher, or someone with an express delegation of authority from someone who has authority. The problem is that lawyers and VPs are usually not on GH and do not usually have GH usernames. Thus it makes it significantly more likely that someone who does this via GH is going to not be the right person.
Q5: What can we do?
A5: There is no really good solution, because lawyers. A couple possibilities come to mind, however, that we could probably enact:
- We could only accept ICLAs via GH usernames, everything else requires an eSigned PDF.
- We can talk to major Python backers - and periodically poll core devs relative to their employment status- and reach out to get broad CLAs from that targeted set of companies. That would solve the problem for many devs.
- Google’s solution is that there is an email list that is controlled by someone with authority; anyone signed up to that email list is approved. We might be able to script something similar with email->repo integration.
- We can disallow email blinding and scan for non-free email addresses. (This seems fraught and likely to cause trouble.)