add DCO 1.1; remove reference to CLA

[boneskull]

We're able to ditch the CLA (yay!) for a DCO, which (IMO) is a lot less painful for developers to deal with.

I've already configured probot/dco to handle the checks; once this is ready, it will be a requirement to merge any PR across the org.

The most straightforward way I've found to signoff automatically is just to create an alias, e.g., git config alias.ci 'commit -s', then use git ci to commit.

Often you can configure GUIs such as SourceTree to do this automatically, as well.

[boneskull]

cc @mochajs/core since this is kind of Important

[boneskull]

This should affect new PRs going forward. If the CLA is already signed, I don't want to require the DCO as well. Contributors of existing PRs are welcome to sign off on their commits, of course, but we should not require this.

[coveralls]

Coverage remained the same at 90.589% when pulling aef4ce2 on dco into a63ab5f on master.

[craigtaub]

Mind if i ask why you think its less painful?
From trust perspective it seems the better choice, but from ease-of-use isn't it more work that first time with a DCO?
Just trying to understand the reasoning/benefits to this.

[boneskull]

I've found people are usually much more squeamish about CLAs--I'm one of those people, in fact.

Here are some reasons:

• Signing a CLA means you enter into legal terms & conditions.
• It behooves new contributors to you know, actually read & know what they are signing
• I wager most people signing CLAs don't know if they are actually allowed to do so
• CLAs may be illegal to sign in some jurisdictions.
• CLAs can be problematic for some employers.

My feeling is that CLAs are loved more by legal counsel for companies that tend to get sued over IP. Google is very pro-CLA, for example.

The JSF's CLA is rather light as these things go--it's little more than the DCO + some stuff about how you abide by each project's license.

That being said, if others aren't sold on the idea, and feel signing off on commits is worse, we can just keep the CLA.

If undecided, I encourage you to use your favorite search engine to read about CLAs vs DCOs.

I'll disable the DCO bot for now, probably shouldn't have left it on!

[outsideris]

CLA is not painful for me, but I sometimes saw a case of that developers use multiple emails for a PR and they had a trouble to fix them for CLA.
I'm already using DCO for a while.

[outsideris]

Should we remove CLA check when we merge this PR?

[boneskull]

@outsideris that's the idea, yeah.

still would appreciate more input esp. from @plroebuck and @Munter.

[plroebuck]

So if someone commits something that would have been illegal, under CLA they'd have been responsible. Under DCO, who is? Can both of them be used without conflict?

I prefer CLA scheme we already have myself, but don't care excessively either way.
Also seems easier to press a website button once than have to sign every git commit.

[boneskull]

So if someone commits something that would have been illegal, under CLA they'd have been responsible. Under DCO, who is? Can both of them be used without conflict?

Who is ultimately responsible is an open question, as there's no legal precedent yet (to my knowledge).

I prefer CLA scheme we already have myself, but don't care excessively either way.
Also seems easier to press a website button once than have to sign every git commit.

Let's keep in mind that the people who would find CLAs to be an impediment to contributing are likely not seeing this PR.

I do see the benefits of a CLA if you've already signed it.

That said, I don't want to flip-flop back and forth. Maybe it'd be workable to allow for both? I'll follow up on that with JSF legal.

[JoshuaKGoldberg]

Closing to keep our review queue small. The current CLA system works and nobody from OpenJS has yelled at us to change it. 🙂