Developer Certificate of Origin (DCO)

[nathenharvey]

Chef's open source projects will no longer require a contributor license agreement (CLA) or corporate contributor license agreement (CCLA). A developer certificate of origin (DCO) will be required for each contribution to the projects.

Signed-off-by: Nathen Harvey nharvey@chef.io

[coderanger]

As a way to make life simpler for and keep commits a little less cluttered, can we write this in such a way that all commits from maintainers count as good?

[coderanger]

(maybe write something into the maintainers policy that becoming a maintainer you are agreeing to that blurb indefinitely)

[lamont-granquist]

👍

[robbkidd]

I agree that once DCO is accepted as policy, Currybot will no longer be necessary because it is an implementation of checking commits against CLA signatures tracked within Supermarket. But won't we still want some sort of automation around checking that commits have sign-offs? And I think that automation would be simplest if everyone must include the sign-off, otherwise the automation needs to check inclusion in a maintainers list which was a source of maintenance trouble with Currybot.

[thommay]

Yes, we'll have a bot checking DCO sign-offs, and it will be considerably more straight forward to just do that for everyone - it also makes life simpler if we need to audit commits for any reason.

[robbkidd]

👍

Turning off Currybot: +:100:

[stevendanna]

👍

[coderanger]

Okay, copying comments over from Slack but to lead off I'm still 👎 on this as written:

Right now the CLA process is effectively a one-time deal for each user. Contribute once or a million times and it's still the same amount of effort. This, instead, requires work that is linear with the number of commits. There is no way in git to configure this at a per-repo level, of even globally. You have to remember to do A Different Thing from a normal git workflow on every single commit. I'm aware a few other major repos use this same workflow, but they are a vanishing minority compared to what people expect from git. Add to this that some git UIs (notably GitHub's fork-and-edit UI, which is a really easy way for people to submit minor fixes) don't even have a button for Sign Off. It's a relatively unused feature of git, few people will come in understanding what this is or means. This means we're going to have to guide a lot of people through rewriting history and force pushing, which is going to break a lot of other stuff (PR comments, Travis, etc).

All in all I find this a total non-starter. We're trying to optimize a workflow to make it easy for automated verification, not for the humans that have to execute it. As a counter proposal, how about we require one "sign off" commit from a given user anywhere in the commit history of a project. That requires no history changes (if you forget on your first PR just add a new no-op commit with a Sign Off), is easier to walk people through, and can be statically verified. Even that would still make life hard for GitHub-fork-and-edit editors but we can have the PR bot give them the text to put in a commit message at least.

tl;dr 👎 Design a workflow that is good for humans not bots.

[lamont-granquist]

Can we get some words in here that existing currybot-approved PRs will be acceptable to merge?

Because for many outstanding PRs we will simply never get the people who submitted them to resubmit with all the PRs signed off, and while its simple to rebase and recommit as myself, that's typically rude and a bit questionable unless the rebase is problematic.

[lamont-granquist]

And one idea that I like is that currybot now should start retroactively DCO signing people's commits where currybot has already recognized those commits as being covered by a CLA. Then when I rebase those commits and add some fixes that the resultant PR is fully DCO signed off on -- which keeps the DCO signing side of the equation trivial since it doesn't need to know about grandfathered-in CLA commits it just needs to ensure all commits have a DCO signature (and once all the old commits have been DCO amended then the grandfather hack goes away).

[coderanger]

I should add @robbkidd mentioned on Slack that a possible improvement would be to get a patch in to git to allow configuring Sign Off on a per-repo basis. This makes it maybe 5% more acceptable but still has the same issues of new users having to rewrite history and Chef has a looooot of repos under it's banner so even per-repo work is still worse than we have today where it's all per-user work.

[thommay]

@coderanger I think your premise is incorrect. We're designing a workflow to maximise the number of humans that can contribute. Bots are completely irrelevant. Yes, once the CLA is signed it's a one time deal, but getting it signed is a huge barrier to entry - there's a vast number of patches where simply asking for a CLA is too much effort. And beyond that, we hear time and again from corporations that simply won't sign a CCLA, even if they have a policy of contributing to open source. And I'm willing to bet that for every corporation or individual contributor that we do hear from that are many that we don't.
In terms of experience, we're doing the same thing as habitat, and as docker, and git itself. OpenStack are considering moving to it ( https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Other_Projects_Using_the_DCO ). So I'm reasonably confident that contributors will be familiar with the process, and other tools will catch up with this.

[coderanger]

Habitat is (not as a critique just reality here) not a project that has enough contributors that the overlap is helpful. Ditto linux kernel, which I should add is a project legendary for being hard to contribute to so maybe using them as an example is ... not so good. Docker, at least probably non-zero overlap but still I'm not seeing that as enough to consider people informed. Other than "other people do it" what's the defense for requiring a specific, non-standard action to be taken on every commit? And why is this better than something similar to the DCO legal policy but executed once per use or once per repo (i.e. why can't we apply the same legal text but to every commit by a given user once accepted)?

[thommay]

@lamont-granquist yeah, if a PR is already signed off there's no reason that we wouldn't take it. But if/when we switch, any new PRs will need a Signed-Off line.
@coderanger honestly I am just adding a signed-off line to all my commits now by default. It's a one time effort entirely. I'm not really sure I believe that there are situations where projects would reject my commits because I have an extra line in the message.

[coderanger]

@thommay Is there an option for that in git or do you mean you use a shell alias or similar?

[coderanger]

(my commit UI definitely has no "Sign Off on all commits" option, and at least some UIs don't even have the option at all)

[stevendanna]

And why is this better than something similar to the DCO legal policy but executed once per use or once per repo (i.e. why can't we apply the same legal text but to every commit by a given user once accepted)?

Personally, I like the fact that it is on a per-commit basis. It is an especially nice reminder for those people who work on the build-related portions of our software to double check you have correctly attributed the decades-old patch you found on the internet for libwayold.

[coderanger]

@stevendanna I agree entirely that this makes life easier for the RelEng folks, but they are not the ones I'm concerned with. We can augment their experience with scripts and training in a way we can't for contributors.

If we take this proposal back to brass tacks it seems like there are three goals. First, we want to drastically reduce and simplify the legal text that contributors have to agree to. No argument from me on this one, less is more. Second, we want to have an in-band way to agree to the legal text that is less "go to this other site and do a thing" than the current CLA process. Third, and mostly relevant to Chef's RelEng team, we want better ways to ensure legal compliance from all contributors. Does that sound accurate overall? I am happy to propose alternatives but I want to make sure we're all on the same page as far as goals.

[thommay]

We also want to be consistent with the route that other large projects are going, so we don't dive off in a different direction, because user education is something that we care about.
DCO is becoming an accepted standard, so anything that is different to that becomes much harder to justify.

[coderanger]

I really think that's overstating the value of DCO, it's the kernel, Docker, maybe Samba, and then a lot of smaller projects. I also don't think we should accept it as "standard" when it clearly has so many major problems. I can understand why the kernel team likes it, given that they make heavy use of a lot of under-used features in git and the contributions are generally from people very familiar with both git and the command line, but we aren't that and I want us to have a better contributor UX than DCO allows for.

[lamont-granquist]

Mailing list threads on proposed patches to git for adding config.signoff option:

http://git.661346.n2.nabble.com/PATCH-Add-a-commit-signoff-configuration-variable-to-always-use-signoff-td1886619.html
http://git.661346.n2.nabble.com/PATCH-commit-add-commit-signoff-config-option-td7634305.html#a7634307
http://git.661346.n2.nabble.com/PATCH-v2-commit-add-commit-signoff-config-option-td7634348.html#a7634356

(adding this here since I did the google research to find them)

[coderanger]

Those patches definitely help for the long-time contributor and maintainer personas, though it doesn't help with drive-by contributions (especially from the GitHub web UI). Also the last messages in those threads are over a year ago so probably safe to assume that any changes in git will not be Soon™.

[scotthain]

Pretty sure this is already in git?
https://git-scm.com/docs/git-config

format.signOff
A boolean value which lets you enable the -s/--signoff option of format-patch by default. Note: Adding the Signed-off-by: line to a patch should be a conscious act and means that you certify you have the rights to submit this work under the same open source license. Please see the SubmittingPatches document for further discussion.

[lamont-granquist]

FWIW I think every alternative that addresses licensing issues like this has differently flawed UX right now. What I see as a benefit here is getting off of the special snowflake chef CLA process that nobody else in the world uses. I'd like to see us on a homu bot that enforced DCO since that get us on the same page as docker, git, linux kernel. I actually do find it vastly preferable to be jumping off of the same cliff as all the other lemmings. Some users that refuse to sign any CLA will now be able to contribute, some users will refuse to take the time to rewrite their commits after they fire them off and their PRs go red. I doubt any of the latter will be high quality PRs. To that extent I don't think this RFC is about making it "easier" to contribute in any sense (and it might be perfectly acceptable to make it slightly more difficult). We already have enough open PRs and PRs that are incomplete and we have marked "finish for merge" that we haven't had enough time to get to, so we don't have a problem of having too few PRs. I do think we need to get out of the business of developing our own special snowflake workflow and legal process and should get on board with what other open source projects are doing to solve the same problems.

[stevendanna]

@coderanger Would you say that an accurate summary of your objection is that:

The sign-off is an extra piece of work people will need to do on a per-commit basis that they don't need to do for other projects. In some cases, this will require users to rewrite their git histories, a process some developers might not be skilled at. Both of these will make it harder for new and existing contributors.

If so, I agree that this process is a bit more work on an on-going basis than the CLA system, but my experience as a new contributor to habitat was that it doesn't end up being too bad.

In terms of the chilling effect it could have on new contributors, I'm not convinced that having to do -s when you git-commit is going to deter someone who has already gotten their dev setup sorted, made their change, and gotten the tests to run and pass.

While I certainly don't want to add another hurdle, I've personally found the DCO Sign-off has some positive effects -- it encourages me to take a second look at my commit message and ensure it provide the context needed to review the change.

In habitat-sh/core-plans there are a couple of small hurdles like this for patches (lint checks that you need to fix even though you didn't cause the problem, DCO, etc) and while I agree it is a new, smaller project, my experience there has been that new contributors have been working together to help each other with their first contributions and the process has been pretty pleasant.

[stevendanna]

@scotthain That only affects the format-patch command I think.

[scotthain]

@stevendanna ah I believe you are correct, I rescind my statement.

[coderanger]

@stevendanna I, and a lot of other people, don't use the git command line for commits. I think you are assuming people contributing to Chef are all CLI-centric and comfortable with git. I can assure neither of those are universally true. As for that being my objection, that's the heart of it, yes. It doesn't fully illuminate the cascading secondary effects as I've laid out about. I also disagree with the statement that it's "a bit more work", it's a lot more. Every time you say "please rewrite every commit in your pull request or we can't accept it" you're going to lose contributors, and I would say that's going to be the majority of pull requests for a long time. Again, I don't accept we should do this just because everyone else is, it is bad, that doesn't change just because others are doing it until such time as we could reasonably expect a large majority of contributors have already learned the DCO process (in the way that we tend to assume they have already figured out how PRs work). The current state of DCO is nowhere near that, so use of existing projects feels like a very empty reason.

[coderanger]

@stevendanna It would depend on the interpretation of "certified" and I think Legal's comment before was that they would prefer we use the same certification rules as other major DCO users. Personally I would love to see "certification" by way of a comment in a PR but I fully understand that that exposes us to more risk and that's grounds to say no.

[stevendanna]

@coderanger Yes, I agree. This is why I've mostly kept my copious opinions on the legal side to myself since I feel like the ultimate role for me as a maintainer is to help decide on whether this process as a whole is better than the CLA process sans modification. I am heavily in favor of choosing a process that is identical or nearly identical to what other projects use for the reasons Adam has laid out in a few places.

[adamhjk]

I'll ask. I suspect that:

1. If @ssd accepted a PR because the person on the other side said "I would do the DCO, but I don't know how"
2. That would be grounds for @ssd to add the DCO to the resulting commit with a comment.

If that was acceptable, would that drop the burden low enough? Ie: A maintainer would do it on their behalf, given they state "I want you to do this, and I attest to the DCO" or whatever.

[coderanger]

@adamhjk I would buy that 100%. Still more work, but as a maintainer I'm happy to eat that occasionally if it means a healthier community.

[spuder]

As a user who has signed the CLA, I'm 👎 in the change.

Reasons

• The CLA is a one time inconvience
• I don't use git from the command line

If developers use GUI apps like github, source tree, tower, setting up signing keys is a much bigger deal.

Also, sometimes people make quick pull request from github (like documentation fixes).

If you are already familiar with git from the command line and have git commit signing already setup, this isn't a big change, for everyone else this will be a large barrier to entry.

[adamhjk]

Just to be clear, this isn't signing keys. This is a single line
attestation ("Signed-off-by") that you can get with git -s. Still feel the
same?
On Sat, Aug 27, 2016 at 7:05 PM Spencer Owen notifications@github.com
wrote:

As a user who has signed the CLA, I'm 👎 in the change.

Reasons

• The CLA is a one time inconvience
• I don't use git from the command line

If developers use GUI apps like github, source tree, tower, setting up
signing keys is a much bigger deal.

Also, sometimes people make quick pull request from github (like
documentation fixes).

If you are already familiar with git from the command line and have git
commit signing already setup, this isn't a big change, for everyone else
this will be a large barrier to entry.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#213 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAQ0G98p8dvkXigo4tyl2jDUUsWuFxlks5qkOzRgaJpZM4Jd0W3
.

[spuder]

Derp, I confused -S (--gpg-sign[=<keyid>]) with -s (--signoff).

This is actually a bigger hurdle than initially thought since sourcetree & github desktop don't have documented support for --signoff

This change would mandate that users have to use git from the command line, omitting any other git tools.

I work at a company where git is a second class citizen and currently only used with cookbooks. Getting developers to understand git from the command line has been difficult, git gui tools have overcome this resistance.

[coderanger]

@spuder Would it be enough if they could confirm acceptance of the DCO agreement as a comment in the PR and then one of the maintainers would add the -s log messages before merging?

[spuder]

@coderanger I suppose that would work as log as it is sufficiently transparent to the end user.

Also it appears atlassian's source tree does support --signoff

[agh]

I've worked at a number of large companies and it's been much easier to get one-off signoff (attested via DCO) for a particular contribution, or even an internal agreement that 'Person X' or 'Department Y' can contribute to Chef Software on behalf of Mega Corporation, Inc.

Please note I am not a lawyer and can only paraphase what I've been told by corporate counsel, however the Corporate Contributor License Agreement (CCLA) is often perceived as a blanket engagement between MegaCorp and Chef Software (any contribution, and any employee). Unfortunately that may be "strategic contract review", vs. "tactical contract approval" (DCO).

In at least one company which I've worked, any VP Engineering can sign off contributions via DCO, i.e. authority was delegated, whereas Legal had to be fully engaged to review and sign any new Corporate Contributor License Agreement.

Not altering the process and terms used is of critical importance, thus all commits being signed. There's an eminently reasonable view taken by Legal that since a Pull Request may contain several commits, which can be unbundled, each must be considered a "contribution" (and thus signed). Becoming a snowflake by altering the process or terms puts you back into onerous legal review.

For anyone who hasn't worked at a Fortune 100, any Legal engagement can easily run into 3+ months of back-and-forward between LOB (line of business) and corporate functions, and there'll inevitably be a "Why is this in the corporations interest?" discussion. You need a business case. Navigating this process can be a pain in the butt, which I imagine dampens the appetite of an engineer to contribute their patches upstream.

Whilst I'm sure its not malicious, most of the people voting 👎 here do have some implicit bias. You've already navigated the ICLA or CCLA, you are contributors, and there is an entirely understandable "This changes my workflow, for what benefit?" reaction, but IMO this is a big deal. In my humble opinion the DCO has always been superior, and the widespread adoption of Contributor License Agreements in the industry was a mistake. One we are now rectifying.

@adamhjk Please consider this a strong 👍 from me, and in contemplating your decision, please give some consideration to the cogs in the machine who want to participate in your community but also have complex legal processes to navigate. It's my belief DCO could make this easier.

[sigmavirus24]

Whilst I'm sure its not malicious, most of the people voting 👎 here do have some implicit bias. You've already navigated the ICLA or CCLA, you are contributors, and there is an entirely understandable "This changes my workflow, for what benefit?" reaction

Actually, hate to be that person, but you're wrong. I, for one, have never once contributed to Chef. I happened across this discussion elsewhere in a discussion of barriers to entry for OSS and how projects never actually remove them, they just change them. I was waiting for someone to look at some contribution stats and say "Hey wait, that person never contributed before!" but they didn't.

Yes I have dealt with (I|C)CLAs before. No I don't think they're pleasant. All the tooling used to enforce them is terrible. I don't think DCO is any better though.

[adamhjk]

@sigmavirus24 well, welcome to the Chef community! :) I suspect nobody called you out on it because, in fact, nobody cared - you're as welcome here as you can be, and your opinion counts for something, even if you're not a contributor yet.

[agh]

Indeed, welcome, and I largely agree with your remarks on tooling.

Unfortunately society is pretty litigious and its important for Chef Software to protect itself. Therefore we have a choice: two options both with different workflow challenges, but one, Developer Certificate of Origin, which is legally simpler (my term, explained below) -

• Attestation is on the developer. It's up to you to ask "Can I contribute?" (if necessary) and covered under "and I have the right to submit it", do you have the authority to contribute?
• The agreement is very short, and therefore easy for attorneys to read and consider.
• It's extremely granular - operating at a commit level ("a contribution", in the legal sense). Organisations can view it as a 'per contribution' (which is likely a bundle of commits) approval. They could opt to do blanket "You may contribute!" per person or department. It's up to them.
• It's not particularly onerous, in my opinion, requiring only git commit -s.

Given there are a goodly number of projects moving towards DCO any limitations to the editing interface on github.com might be fixed in the mid-term through a UI enhancement exposing -s functionality, has anyone asked GitHub Support to consider this?

Arguments above around "drawing someone into contractual violation" by suggesting contributors alias git commit to git commit -s are interesting, I don't think this should be suggested practice, however I would note that even with a Corporate Contributor License Agreement you may still be required to obtain approval before raising a Pull Request.

I've actually seen problems where even though MegaCorp has signed the CCLA, that does not constitute blanket approval internally to give whatever patches you want to the external company, for inclusion in their project; i.e. the signing of the CCLA does not alter your employment agreement, and thus, a CCLA should usually not be viewed as implicit approval to contribute. Thusly I would posit it is possible to "violate" in either CCLA or DCO processes.

[Tensibai]

@agh

Whilst I'm sure its not malicious, most of the people voting 👎 here do have some implicit bias. You've already navigated the ICLA or CCLA, you are contributors, and there is an entirely understandable "This changes my workflow, for what benefit?" reaction

I can't say I've a workflow, I did 2 PR in a period of 3 years (roughly).
I'm against it because it sounds not fail proof for me and likely to drive others in a bad path. (see below)

Thusly I would posit it is possible to "violate" in either CCLA or DCO processes.

Yes, it's possible in both. What is clear is lowering the barrier (simple message/option in a git commit toward a signature process) is likely to put a lot of people in fault because they won't think twice if they're really allowed to.

I've the feeling it's a logical move to ease the CLA (git based instead of web based) but this has a high potential of risk for contributors. The CLA web process is good in this sense it makes people think twice. The drawback is never ending PR (maybe because it's too hard, maybe because they read it and suddenly realize they can't), but I personally prefer this than driving people in breaking their corporate engagement.

[robbkidd]

As a maintainer, I'm 👍 to maintainer sign-off after having confirmed contributor agreement. Maintainer sign-off can help in the case of the obvious fix rule which this RFC explicitly leaves in place. And from my experience so far, changes contributed via the GitHub editor tend to fall under "obvious fix."

I've been a fan of the sign-off addenda that the kernel maintainers add as a patch moves through their workflow. For example, git/git@da0005b or even git/git@1d1876e (where format.signoff was added to the config file to ease their own workflow).

Some other options for getting Signed-off-by: You <you@yourplace.org> into commit messages.

Globably sign-off all commits

Some folks are understandably wary of this one.

# ~/.gitconfig
[alias]
  commit = commit -s

Have a special alias to DCO commits

Global, but you have to remember to use it.

# ~/.gitconfig
[alias]
  dco = commit -s

Use a commit message template

This option lets you include the DCO text in your commit message on a per-repo basis and is supported by several of the GUI clients.

# ~/.gitmessage-dco

Signed-off-by: You <you@yourplace.org>

Then, within repos for projects that require a DCO sign-off:

chef/chef > git config commit.template ~/.gitmessage-dco

Note that the config command was not given --global, so the config option is only set for the current repo.

[nathenharvey]

@nathenharvey - obvious fix still applies, yes?

Yes! The obvious fix rule still applies, regardless of CLA or DCO.

can we confirm a DCO via the PR itself, and then include the signed off by as evidence

I'm working with Legal on this specific request: Can a contributor's change be signed-off-by a maintainer?

[jasmeralia]

As someone who has done the CLA before I'm personally fine with DCO if that's the way we move. I do agree with a lot of @coderanger's concerns, though. If legal allows the maintainer to sign off, I think that changes the face of the discussion quite a bit and significantly lowers the bar to entry compared to the CLA.

[nathenharvey]

I have confirmed with our legal team that a project maintainer, listed in MAINTAINERS.md, may complete the sign-off on behalf of another individual given:

1. The original contributor agrees to the Developer Certificate of Origin (DCO) in some public forum, such as a comment in the Pull Request (PR).
2. The project maintainer must not alter any part of the submission other than the commit messages, pursuant to part c of the DCO.
3. The project maintainer's sign-off will note that the sign-off is being given on behalf of the original contributor (eg, Signed-off-by: Jane Doe <jane@example.com> on behalf of Joe Smith <joe.smith@email.com>)
4. The PR that is merged must include a link to the original contributor's public attestation to the DCO.

Maintainers will have to do additional work when contributors are unable to or refuse to update their commit messages. As such, contributors should be encouraged to update their commit messages on their own as part of the process of reviewing PRs.

I believe this addresses the largest concerns that remain towards adopting the DCO.

[adamhjk]

Chef will switch to the DCO

If you're only here to know the final decision, that's it. Keep reading to understand my thinking on the topic. :)

DCO and CLA

The purpose of the CLA and the DCO are identical. In both cases, it asks a contributor to attest that they have the right to contribute the code - that it is free of an encumbrances that would make it illegal to contribute. The Apache CLA we use goes much further than the DCO does - it includes statements about copyright and patents, amongst other things. The DCO instead is much simpler verbiage - it relies on the license of the project itself to set the terms of contribution. This was also true of the CLA - in the end, the License is what carries most of the weight post contribution.

In both cases, the DCO and the CLA exist to protect contributors, users, and companies. For contributors, it makes clear that the intent is that your contributions be merged to Chef. Combined with the Apache License, it makes clear that you retain your copyright - which is the ultimate source of our community's equal footing for contributors, regardless of their employment. Once you commit to Chef, you own a piece of it, and that ownership can't be taken from you. For users and companies, it provides a clean audit trail of the software - each commit can be tracked back to the attestation from the contributor that they have the right to contribute that code. That's what makes the ecosystem possible - for all the folks who integrate Chef, ship Chef, or build on Chef.

Advantages to the CLA

There are two primary advantages to the CLA. The first is that it's a document you sign one time, rather than on every commit. Once you've signed it, all your contributions are covered. The second is that, once you go through the trouble of signing it, there are no limits placed on your workflow, other than what the project itself requires (in terms of commit hygiene, format, etc).

An ancillary advantage to the CLA, in our case, is that the CLA already exists. Every contributor to Chef has signed the CLA - some of us even faxed it in. Since that moment, we've been free from thinking about it. Continuing with the CLA means that status quo is maintained, which means our existing contributor base doesn't have to do anything different tomorrow than they did today.

Downsides to the CLA

First, the CLA requires you to use an external system to sign the CLA. Originally, we did this by fax. We then moved to Docusign, and finally to our own system on Supermarket. As a new contributor, your first task is to leave Github, create an account on Supermarket, and sign the CLA. Often, this process also involves review by a legal team, in particular if you are contributing from a corporation.

Second, there is a general misunderstanding of the CLA attestation. We often get the feedback that we are, for example, taking copyright assignment from our contributors. This happened in this thread from one of our longest standing contributors. In general, the length and complexity of the CLA cause most people to misunderstand its meaning.

Third, we have had hundreds, maybe more, of closed or abandoned PRs over the years due to a lack of willingness to sign the CLA.

Fourth, the CLA is broadly administered centrally by Chef Software. One thing we see as that administrator is the desire for organizations to customize the CLA - to either add or subtract language, or tweak certain terms. These conversations take time, and rarely (if ever) result in any substantive changes to the agreement. Instead, they simply take both time and money - both for the organizations doing the negotiating, and for Chef.

Finally, and this is admittedly subjective, we wind up in a random internet discussion defending our position with some regularity, and have from the beginning of the project. While I'm proud of my defense of, and advocating for the importance of, CLAs, I don't think it's particularly valuable to the project that we continue to be a leading light in the CLA collecting community. :)

Advantages to the DCO

The DCO is significantly shorter, and much easier to understand. Its four clauses, all of which are written in as close to plain english as possible. It doesn't use words like Copyright, Patent, etc. As a side effect, most people can read and understand the DCO with a minimum of effort.

The DCO can be handled entirely within the development workflow. You "sign" it by adding a single line to your commit message, which can be added automatically in several ways, or manually. As most of our contributions are technical in nature, this can be a significantly lower barrier - in particular combined with the ease of understanding in the previous paragraph.

Clause "C" of the DCO allows maintainers of the project to sign off on work that was performed by others. Unlike the CLA process (as understood and administered by the project today), if a new contributor is unwilling or unable to sign their commits due to unfamiliarity with tools, or lack of time, the maintainers can carry those commits forward by asking the contributor to agree to the DCO via commenting on the Github pull request. This would allow us to take contributions that are valuable to the project, and keeps the interaction where it belongs - on the pull request itself.

Disadvantages to the DCO

The biggest is the fact that we ask you to add the "Signed-off-by" line on every commit. For existing developers, this change means having to alter your existing workflow for contributing to Chef. For new developers, this may mean having to use commands like git commit -s --amend, or git rebase -i. While many developers are familiar with this process, many are not.

If it wasn't for our reading of clause C, this argument would have been enough to convince me to keep the CLA.

Response to various arguments

People won't read the agreement/They won't talk to their corporate counsel

This is a risk of both the CLA and the DCO. Many, many people simply sign whatever is put in front of them - it's a hurdle, and they leap over it. In both cases, it doesn't change the fact that you agreed to the terms - your decision to be ignorant of the agreement changes nothing about your responsibilities, or other people's liability.

The use of clause C doesn't change the bad UX

This may be true, but we haven't reached the last responsible moment to decide to engage in this work. As a developer myself, I don't find the idea of checking out someone's branch and doing an interactive rebase to append a line as particularly onerous. I would happily do it before I write a script that can reliably do it automatically, which then needs to be maintained and debugged - and if it has issues, might leave an un-suspecting contributor in a worse state than they were before, repository wise.

If this burden proves too high, we should invest in automating it. Lets see the burden first, and lets make sure that the ability for a contributor to ask maintainers to carry the patch via Clause C is an option given by the bot.

Lawyers gonna Lawyer

This argument basically boils down to "lawyers are going to be involved either way". While the that may be true, in many cases it needn't be - the question for a corporate counsel isn't "are you willing to sign the CCLA and then let me contribute to this project under the apache license" - it is instead "is it okay for me to contribute this to Chef under the Apache License?". Our experience is that the second question is significantly easier to answer than the first, as the first requires a careful review of a pretty long legal document, while the second does not.

I understand that this will vary based on the lawyer, as such things do, and ultimately this comes down to my experience with our legal counsel negotiating CLAs through hundreds of large enterprises. I could be wrong 🤷.

Lawyers gonna re-litigate

If you already signed the CCLA, you'll have to now agree to the DCO. That's true - but given that the DCO says less than the CCLA did, and in both cases you are agreeing to the Apache License, it's equivalent. Most lawyers will see that immediately and move on, if they even need to be involved at all.

I won't contribute anymore if you switch

I'm sorry we won't receive any of your contributions. My job as the Project Lead is to balance the needs of all of our community, and in my estimation, the DCO provides more benefit than downsides. If that means we loose your future contributions, I respect your choice, and I thank you for everything you've contributed so far.

In closing

I want to thank the community for raising their voices in this RFC, and for comporting themselves with honesty and integrity in disagreement. As I said above, if it wasn't for our teams reading of Clause C enabling maintainers to carry patches for those unwilling or unable to utilize git to add the signed off by, your argument would have swayed me to remain with the existing CLA process. It's a testament to all of you that we can have this discussion, and that we can resolve the issue and move forward together.

Best,
Adam

[adamhjk]

As the decider, this RFC is approved. Go for it, @chef/rfc-editors.

[adamleff]

RFC 080 assigned!

[hrj]

It was fascinating reading this thread.

I hope you guys realize that comments on Pull Requests and Issues on Github can be edited by the maintainer of a project. So, if a comment accepts a DCO, it is no guarantee that the words are from the contributor.

Signed with a GPG key is probably the only way to be sure of anything in a decentralized repo hosted on a third-party service.

[sigmavirus24]

I hope you guys realize that comments on Pull Requests and Issues on Github can be edited by the maintainer of a project.

@hrj, there's no need to be condescending. When comments are edited on GitHub, the comment display is updated to reflect that to tell you who did it and when.

Signed with a GPG key is probably the only way to be sure of anything in a decentralized repo hosted on a third-party service.

So instead of lowering the barrier to entry, you want to make it orders of magnitude more difficult?

[hrj]

So instead of lowering the barrier to entry, you want to make it orders of magnitude more difficult?

I don't want anything. I was just briefly passing through this corner of the galaxy. Peace!