Choose DCO or CLA

[bnb]

As an OpenJS Foundation project, we need to adopt either the DCO or a CLA (ref: IP_POLICY_GUIDANCE.md).

DCO is annoying and hard. CLA is easier but potentially more of a barrier for some folks.

There's some existing tooling for each:

• https://github.com/probot/dco
• https://easycla.lfx.linuxfoundation.org/#/
  • the preferred CLA tool for the OpenJS Foundation, which they will directly support. If we want to use another tool, we can but they won't be able to help support it. I assume we don't care about that if we choose a different tool.

[groundwater]

Asking around a while back, it seemed nobody cared much about one or the other. Which is the easiest? It seems like the CLA requires a company's legal department, whereas a DCO doesn't. Is that the case?

[kpfleming]

Speaking as the person who has to handle these things for outbound contributions from our company, CLAs are infinitely more difficult than the DCO. DCO does not require legal review at all, but every CLA does. CLAs also require that we explicitly communicate the list of authorized contributors to the target project, and no matter how easy the CLA management system is, 'some work' is always worse than 'no work' :-)

DCOs also leave evidence of the contributor's assertions in the source code repository; CLAs do not, the evidence is locked up in whatever CLA management system was in use at the time the contribution was made (and is never visible to the other contributors or the project's downstream users).

Given my experience handling contributions to dozens and dozens of projects, I'm curious what experiences led to the statement 'DCO is annoying and hard.'

[bnb]

I'm curious what experiences led to the statement 'DCO is annoying and hard.'

In practice in the Node.js project, the exact reasoning you point out is the challenge.

DCO puts the burden on the individual developer rather than the organization. This adds overhead to contributions, and at the scale of something like Electron - specifically, across dozens of repositories managed by distinct working groups - is hard to consistently enforce.

Some tooling exists to help, but it is not really as comprehensive. This results in a higher burden for maintainers both in their own work and in shepherding in the work of non-maintainers.

[kpfleming]

In my experience, most projects which use CLAs require both the individual and their employer (or other org) to sign a CLA, because they cannot be certain at the time the contribution is made which party (if not both) holds copyright interests in the contributions. When that is the situation, the DCO is much simpler, since the contributor only has to add the Signed-off-by line in their commits, instead of navigating the CLA-signing system.

Following the link above, I see this text as it relates to LF projects:

The Board has pre-approved an individual CLA and a corporate CLA. Projects can choose to adopt either the individual CLA by itself or both the individual CLA and the corporate CLA without any further review.

Given that, every contributor will required to participate in at least one CLA if the project chooses the CLA option. For contributors who hold their own copyrights (and thus there isn't any organization or CCLA involved), they will have to sign the ICLA.

[bnb]

I generally agree with you!

since the contributor only has to add the Signed-off-by line in their commits

This specifically is the challenge. The word "only" is doing a lot of work here, since it both requires that experienced individuals who are already contributing change their workflows and that maintainers have to consistently educate people on how and why they need to do this (or build automation to do so adding further maintenance burden).

In concept DCO does sound much easier. In practice it is a burden that is applied to every commit. That burden can be managed, but it's not trivial. I say this as someone who's contributed to a large-scale DCO-based project for over half a decade.

Either way is a trade off with some burden being assigned somewhere, and as a project under the OpenJS Foundation we just need to choose which burden to take on.

[groundwater]

[DCO] is hard to consistently enforce

@bnb can you expand on this? I would be against a solution that's not 100% automated.

In practice it is a burden that is applied to every commit

Is that codified in a requirement? I don't think I understand why it would be different, legally, between a CLA and DCO. As in, a CLA is generally signed once and it covers all contributions from that user. Why would a DCO need to be different?

[bnb]

@bnb can you expand on this? I would be against a solution that's not 100% automated.

Is that codified in a requirement?

Yes, this is what the DCO is. Per the LF's definition (DCO is from Linux, so this is an authoritative source):

The DCO is a per-commit sign-off made by a contributor stating that they agree to the terms published at https://developercertificate.org/ for that particular contribution.

You have to sign off on every single commit. If you're squashing, you just need to do this once, but if you're not it needs to be in every commit and you'll have to re-push changes with it if you don't include it. There are editor settings/git configuration you can do, but this is additional upfront work that not everyone (read: external contributors) will always get right. The aforementioned empty commit is a useful hack around this if you're squashing, as it'll appropriately sign off without you having to do anything but that either requires a custom bot or for that PR to land + that bot to be added to every repo in the org.

If you want to automate it, you effectively need a bot on every repo that will screech at you if maintainers have not done a DCO sign-off or that'll add an empty commit with a DCO sign-off automatically.

The latter approach is valid but has been historically annoying and not fundamentally different than just signing off in your commits. It is now a feature that the Linux Foundation has PR'ed to the Probot DCO repo that seems to now finally be getting traction with two LF maintainers being added to support it.

[dsanders11]

Gonna chime in with my perspective here as an individual contributor to a handful of Electron repositories.

CLA does have the advantage of being less annoying for contributors since it's usually something that a bot will ask you to sign and that's that, no need to change your commits. It also usually applies across all repositories for a project, so it's a once and done thing.

DCO does have the disadvantage of being a larger burden on contributors, and one that will probably get tripped on a fairly regular basis as a result, and can not be resolved easily with a quick web form. I'm big on lowering barriers to entry for contributions, and DCO seems to add a bit more of a barrier than CLA does. For individual contributors signing a CLA can be done in 30 seconds on whatever device they see it on, like their phone. Modifying the commits to adhere to the DCO is more effort, and could lead to more one-off PRs from individual contributors never being merged since they won't take the time to understand the DCO process and update their commits.

All of that said, DCO has a somewhat large advantage over CLAs, from my perspective. Which is there's less ambiguity and potential issues when employment status for a contributor changes over time. I've signed dozens of CLAs as an individual contributor with this account across many projects. Now if I use this GitHub account to make a contribution for my job, I'll be green lit as having signed the CLA, even though in that case, that contribution should actually be under a CCLA, not ICLA. Even if I'm aware and try to do it correctly, the CLA management systems are going to be hit or miss on whether I can resign it as a CCLA after it's already been signed with that account as an ICLA. That could lead to a quagmire of separate accounts per employer, if you want to ensure you conform to CLA requirements. With DCO, it's clear with every contribution that I'm signing off at the time of the contribution, instead of falling back on a CLA I may have signed as an individual years ago and not even remember I signed.

So from my perspective, DCO offers a strong advantage in that it automatically adapts as the copyright situation for a contributor changes over time.

[kpfleming]

Absolutely valid, since a number of CLA checkers do it based on the GitHub user identity of the PR submitter, and not the email addresses of the authors/committers of the commits in the PR branch.

[tchetwin]

Is there any update on the process to decide between and implement either CLA/DCO?

The link in the first Issue note can now be found here: IP_POLICY_GUIDANCE.md