Introducing Developer Certificate of Origin

Hello Chefs!  Currently, Chef asks each contributor to a Chef-managed open source project to sign a contributor license agreement (“CLA”) or to be part of a corporate contributor license agreement (“CCLA”) signed by their employer.

We’ve justified this in the past because (i) it ensures that we will always be able to release our projects, free from any individual contributor revoking our rights to distribute their contribution; (ii) if you fork a Chef project, or utilize it in a commercial product, you know that you are clear of patent and copyright issues; and (iii) it makes clear what is required of our contributors.  We also said that the most important thing about the CLA is that it doesn’t give Chef any special rights – it just makes things more explicit.

We still believe all of that. HOWEVER, we also believe there are other, easier ways to achieve the same thing.

Effective October 3, 2016, Chef will no longer require CLAs or CCLAs for contributions to its open source projects.  Rather, Chef is adopting the developer certificate of origin (“DCO”) used by several other projects and overall smart people.

The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find below or at

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the 
    best of my knowledge, is covered under an appropriate open 
    source license and I have the right under that license to   
    submit that work with modifications, whether created in whole
    or in part by me, under the same open source license (unless
    I am permitted to submit under a different license), as 
    Indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including 
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the open source license(s)

Subsequent developers who co-author or otherwise help shepherd the contribution in some way also add their own attestation so it’s not unusual to end up with a contribution which looks like:

 Author: Nathen Harvey <[email protected]>

 Committer: Adam Jacob <[email protected]>

   Sprinkle extra delight on our DSL

   Due to an oversight, we were only 96% delightful. Ensure the 
   delight now goes to 11.

   Signed-off-by: Nathen Harvey <[email protected]>
   Signed-off-by: Julia Cook <[email protected]>
   Signed-off-by: Adam Jacob <[email protected]>

We’ve considered this change in the past and have hesitated because the CLAs have more words and therefore must be clearer, right?  Maybe not…  We agree that the DCO accomplishes the same purpose as the CLAs by indicating that developers are responsible for the code that they contribute and that they understand that the contribution is under the terms of the Apache License. This simple process is familiar to developers and more and more legal departments are willing to consider this approach as well.

That’s it.  It’s that simple.  We have more information in the FAQ’s if you want to know more, but if you just want to know how to contribute, you’re done and happy contributing!


The DCO started with the Linux project.  Does that mean you’re moving to GPL or another license?

No Way!  Chef will continue to use the Apache License Version 2 because it provides the same level of freedom for our users that we desire for ourselves. The DCO is increasingly seeing adoption outside the Linux kernel – for example Docker, Samba, Git, Open vSwitch, OpenDaylight, Ceph and qemu all now use it.  Red Hat initiates more open source projects than any other company, and the vast majority of these have never used any sort of CLA or copyright assignment.

Does this Change the Obvious Fix Rule?

No Way!  The theme here is “everything is the same, just easier and more delightful.”

No CLA means the patent language goes away, right?

WRONG.  This move is a confirmation that the Apache License 2.0 speaks for itself.  The CLA was just a process wrapped around the rights.  Your rights and our rights don’t change. To argue otherwise would imply that the Apache License 2.0 contains fundamental legal flaws and would call into question open source licenses as whole.

The Apache License 2.0 actually contains an explicit license condition that says, in effect, that patches submitted to the upstream project are by default to be licensed under the same terms that the contributor received the project code under — namely the Apache License 2.0. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. […]

What if I’ve already signed a CLA?

None of your rights are changing, and you don’t need to do anything with your previous contributions (see above for more information). In the future, just add the DCO statement to your commits as usual.

What about Contributors from Europe?  Are their contributions valid without a CLA?

Yes.  The DCO is an express statement from a contributor that they have the right to make their contributions and that they are intentionally making their contribution under terms enabling distribution under the project’s license – in this case the Apache License 2.0.  There are two basic conceptual elements of a CLA that are beneficial – that contributors explicitly state they have the right to make their contributions and that they are intentionally making their contribution under terms enabling distribution under the project’s license. Apache-style CLAs are not the sole means of achieving these objectives.  Just like a CLA, the DCO is an attestation attached to every contribution made by every developer.

So are the rights granted and given under the Chef CLA different from the Apache License?

It is important to note that the DCO is not a license. The license of the project – in our case the Apache License – is the license under which the contribution is made. However, the DCO in conjunction with the Apache License may be considered an alternate CLA.

The existence of section 5 of the Apache License is proof that the Apache License is intended to be usable without CLAs. Users need for the code to be open source, with all the legal rights that implies, but it is the open source license that provides this.  The Apache License provides very generous copyright permissions from contributors, and contributors explicitly grant patent licenses as well. These rights are granted to everyone. A number of Apache License 2.0 projects use CLAs as well, but invariably these CLAs are, from the contributor’s perspective, more restrictive legal obligations that run to the benefit of one organization rather than to the community. And unlike the Apache License, which is, like all open source licenses, operational without requiring additional legal formalities or paperwork, CLAs are typically structured like conventional contracts, entailing some system of formal assent and bureaucratic procedure.

If I’m contributing while an employee, do I still need my employer to sign something?

No!  Isn’t that great!?  The DCO confirms that you are entitled to submit the code, which assumes that you are authorized to do so.  It treats you like an adult and relies on your accurate statement about your rights to submit a contribution.  

What took you so long?  Why are you doing this now?

With the updates to Supermarket, we thought we had a nifty, streamlined process.  However, the advantages of a DCO are compelling so we consider this the next step in our continuing path to greater awesomeness.

  • The simple DCO document and workflow lower the barrier to contribution for first time contributors.
  • Contributors reaffirm their rights to contribute with each and every contribution made.  This is more clear than asking each contributor to sign a CLA when first contributing and then expecting the contributor to remember the terms of that CLA with each commit.
  • Commits with multiple authors may easily be affirmed by each author.
  • A DCO statement can be included in contributions made via email or a bug tracking system, since it is merely some textual metadata attached to the description of the contribution.
  • The DCO statement makes it clear that all of the contributions are made under the same terms:  the project’s license.

This all sounds great – how is it going to work?

Each commit must include a DCO which looks like this

Signed-off-by: Joe Smith <[email protected]>

The project requires that the name used is your real name. Neither anonymous contributors nor those utilizing pseudonyms will be accepted.

You may type this line on your own when writing your commit messages.  However, Git makes it easy to add this line to your commit messages. Make sure the and are set in your git configs. Use -s or – – signoff to add the Signed-off-by line to the end of the commit message.

What if I forget to add the attestation to my commit message?

Every commit, that does not meet the criteria for an obvious fix, must have a Signed-off-by line.  If you have already submitted a PR you must amend your commits to include the Signed-off-by line.  In the case where your PR is a single commit, amending your message can be as simple as running git commit – – amend -s.  When there are multiple commits in your PR this will require a little more work to rewrite the commit message for each commit.

Rewrite my commit history?!  I am not a git guru, can you just accept my pull request?

Every commit, that does not meet the criteria for an obvious fix, must have a Signed-off-by line.  Chef maintainers, listed in the project’s file, may ask you to attest to the DCO by way of a comment on your PR.  After you have done so, a maintainer will rebase your branch adding an appropriate attestation to each commit.  The resulting commit message would include something along the lines of:

Signed-off-by: Jane Doe <[email protected]> on behalf of Joe Smith <[email protected]>

Was the community involved in this decision?

Absolutely!  This change was proposed as a pull request to the Chef RFC repository there was a lengthy and healthy discussion on the matter before it was adopted by the community as RFC-80 – Developer Certificate of Origin (DCO) for Contributions.

Thank you for your contributions!  You are awesome.

Nathen Harvey

As the VP of Community Development at Chef, Nathen helps the community whip up an awesome ecosystem built around the Chef framework. Nathen also spends much of his time helping people learn about the practices, processes, and technologies that support DevOps, Continuous Delivery, and Web-scale IT. Prior to joining Chef, Nathen spent a number of years managing operations and infrastructure for a number of web applications. Nathen is a co-host of the Food Fight Show, a podcast about Chef and DevOps.