CLAs best practices

[anajsana]

Discussion coming from TODO Slack thread:

@nuritzi "Do you know if TODO Group has resources on how companies can start to monitor CLAs for their team (both individual and corporate)? We’re in the midst of defining a policy around this at GitLab, and I'd appreciate learning more about best practices. Does anyone have pointers?"

"I mean, managing CLAs that GitLab employees need to sign with other projects."

[anajsana]

Alan Tse (Western Digital) "Right now, we're a manual process where approved contributions go through a CLA review as part of our contribution review process, but it's all emails with CLAs thrown into our CLM when signed. I'm also including our FSF managed assignments but that also required a bit more legal review. I'm hoping there's some decent practices/tooling we can also adopt."

[anajsana]

Justin Rackliffe (Fidelity Investments) "Most orgs have some sort of ticketing system for tracking the execution, but an active control for external CLAs I have not seen. If you have a single pipeline for outbound contributions than possibly a control could be created that allowed for ongoing."

[anajsana]

@kpfleming "Our workflow is based on our ticketing system and manual tracking of the results. I can't see how anything else would be practical. But... if you are allowing employees to sign CLAs for work they are contributing on behalf of the company, you've got an entirely different problem to solve"

[anajsana]

@gyehuda "At my last company I created a Jira queue for this. Employees who wished to contribute to a project that required them to sign a CLA would open a Jira. The process would enable an open exchange to ensure that others who might need to know were able to be looped in (e.g. you wish to contribute to foo, you should meet X who is also contributing to foo… please coordinate). Then when they signed the CLA, I’d track the signed document in the Jira ticket.

I ran another process for managing the CCLA updates. E.g. every quarter I’d review who we have contributing to OpenStack, Google projects, etc. where we had a CCLA and an appendix listing authorized contributors. I’d reach out to get updates, and then send an updated appendix (to OpenStack, etc.) or update the email group (in Google’s case where they managed it that way).

There were rare cases where we’d decline to sign a CLA that we deemed to be worded in unacceptable ways. So the Jira tracked that too. Rare, but it happened a few times in the past.

Due to an M&A activity, I became responsible for an existing open source project managed by the other company that caused me some concern. A contributor on the project indicated to me directly that he did not want his company listed as a contributor since he never asked if he could contribute to the project in the first place. Whereas I was not a fan of CLAs at the time, I realized that the OSPO now had a project in our portfolio that was accepting contributions but had indications that the participating companies would potentially contest their contributions. This seemed like a risk to the project’s longer term success and the OSPO’s reputation. So I requested a drafting of a custom CLA/DCO-like document and sent it to the existing contributors of this project (there were only about 10 or 11, if I recall), indicating that we wanted them to confirm the legitimacy of their contribution under the terms of the project license (or that we’d have to remove their code from the repo). All did, but the one who first was reluctant to speak with their legal department. Eventually, we convened the meeting and got the signed confirmation (although I learned why he wanted to avoid his legal department, total jerks). I stored all those in a Jira ticket associated with the OSPO too."

[anajsana]

Eugen Cusmaunsa "As an open source project maintainer myself, I have a question: Is it indeed much easier for the orgs to contribute code if the project just requires DCO instead of CLA? https://opensource.com/article/18/3/cla-vs-dco-whats-difference
Or perhaps DCO needs a similar level of approvals in reality?"

[anajsana]

@vmbrasseur "In reality, a contributor should be receiving permission from the copyright holder—often their employer—before making any sort of FOSS contribution. Which means, yes, the DCO still imposes a burden on employers as far as implementing policy and maintaining records."

[anajsana]

@kpfleming "Indeed. The DCO is just an assertion that you have permission to contribute the code in question, so you still need to obtain that permission from the copyright holders involved. If the code was made available to you under an open source license of some type then you have the permission already, but if it was not (for example, you wrote it during your working hours and your employer owns the copyrights), then you will need to obtain the permission."

[hyandell]

We (AWS) have:

1. A list of CLAs employees can sign individually. [simplified summary, ones in which the employee is verifying they received permission from their employer];
2. A list of Corporate CLAs we have signed and can add an employee to;
3. Ticket process for CLA not on the list.

[kpfleming]

We have #2 and #3, but not #1, as I've never seen a CLA which would qualify under those conditions.

[hyandell]

It's basically the Apache ICLA and clones of the Apache ICLA. It's between individual and Apache, not corporation and Apache. When I say 'employees can sign individually', I mean they sign as themselves, not a CLA they can sign on behalf of the company.