All About DCOs and CLAs

Originally posted on Consortiuminfo.org, July 6, 2020

Of the fundamental structural questions that drive discussions within the open source community, two that continually spur fervent debate are (a) whether software code should be contributed under a Contributor License Agreement (“CLA”) or a Developer Certificate of Origin (“DCO”), and (b) whether code developed by an employee or independent contractor should be contributed under a CLA signed by the developer as an individual or by her employer under a corporate CLA.

Are there any clear answers to these questions? As so often is the case, the answer to that question is, “it depends.”

CLAs and DCOs serve the same basic function – to help ensure that when code is contributed to a project, company or open source foundation (“Project”) for use as part of an open source work (“Work”), the Project and its users (“Users”) have the rights needed to use and redistribute the contributed code as intended without fear of being sued.

In part, the decision between using a CLA or DCO depends on a host of legal considerations, such as: the nature and use of the Work; whether the Project is a legal entity; whether the code is contributed by an individual, or by an employee or contractor on a company’s behalf; whether the Project needs the ability to change downstream licensing terms; User needs; developer concerns and preferences; logistical challenges of administering CLAs and DCOs; whether use of the code may infringe contributor or third party patent rights; and other factors.

But the fervor, and the decision whether to use a CLA, DCO, or perhaps nothing, is not only about legal factors. The debate stems from fundamental differences among the stakeholders in ideology, and in their views and opinions regarding risk tolerance and their respective roles, interests, rights, responsibilities, administrative burdens, and other considerations.

Background

When sufficiently original software is created, whether an entirely new program or a modification to existing code, the new work is automatically protected by copyright law. This means that others can use, copy, modify, and redistribute the software only if permitted (licensed) to do so by the author or other copyright owner. Additionally, in certain situations, a software user might need licenses under applicable patent rights held by the software owner or a third party. Is one better than another? Well, as so often is the case, that depends.In the case of “open source” software that is collaboratively developed as part of a community project, there can be dozens, hundreds, or even thousands of contributors – and thus many copyright holders – who have contributed to the Work.

With so many copyright holders, there are typically two documents that Users and Projects rely upon
to ensure that they have an appropriate open source license from all contributors to the resulting Work – the Project’s open source license, and either a CLA or DCO. Far less often, a Project may require contributors to assign ownership of the copyright in their contributions to the Project. The principal benefit of this approach is that the Project can bring an action for infringement against users that violate the terms of the Project’s open source license. But there are drawbacks as well, as discussed below.

Project Licenses

Most open source projects have an open source license that applies to the overall project (the “Project License”). The Project License is the license under which the overall Work is licensed to Users, and the default license for individual files within the Work. By “default license,” we mean that the Project License applies to the overall Work and to each individual file within the Work, unless notices in the Work indicate that certain individual files are subject to different open source licensing terms.

Open source licenses generally fall into two categories, “permissive” licenses (e.g. Apache License v.2.0, the MIT License, and the BSD License), or “copyleft” licenses (e.g. the GNU General Public License v3 (GPL-3), the Mozilla Public License 2.0 (MPL-2.0), and the Eclipse Public License 1.0 (EPL-1.0)). For additional information about this distinction, see “What Every User of Open Source Software Needs to Know About License Types” by my Partner, Joanna Lee.

At a minimum, an open source license grants Users a copyright license to copy, modify and use the code. Open source licenses also generally include specific disclaimers, acknowledgements of authorship, and sometimes a patent license and other terms.

CLAs and DCOs

When a Project accepts a contribution, the Project needs to ensure that the Project and Users can use the contribution under the applicable Project License, and that the contributor agrees that the contribution will be licensed to Users and the Project under the Project License (or, if permitted by the Project, another open source license that is compatible with the Project License). The Project accomplishes this by requiring contributors to agree to a CLA or a DCO.

As described in more detail below, a CLA is effectively a license agreement that reiterates or incorporates the essential provisions of the Project License, and may grant the Project additional rights as well. A DCO is essentially a certification that the contributor has the rights necessary to license their contribution under the applicable open source license.

CLAs

CLAs have been in use for many years, and often vary by Project. Some of the better known CLAs are the Apache CLAs (Corporate and Individual), the Google CLAs (Corporate and Individual) (mild adaptations of the Apache CLA), and the Microsoft CLA (which covers both individual and corporate contributors).

In a nutshell, CLAs are streamlined contracts that directly address the core legal rights and issues typically covered in software licenses, such as the following:

1. Copyright License. All CLAs include a royalty-free copyright license, permitting Users, among other things, to reproduce, prepare derivative works based upon, sublicense, and distribute the software. Sometimes the Project will explicitly receive the same license rights as other Users. In other cases, the Project will receive a broader set of rights that provides flexibility to change the terms of the applicable Project License, or potentially to license a contribution or Work on completely different terms, without the need to obtain new licenses or consents from contributors. This flexibility can be important for a Project if the original Project License becomes outdated, is defective, or does not address a particular use, such as commercial use.
2. Patent License. Like some open source licenses, some CLAs also include a royalty-free patent license. If the Project License includes a patent license, the CLA likely will as well. Patent licenses grant Users the right to implement patent claims that are owned or licensable by the contributor and would be necessarily infringed by (among other things) making, using, or selling the contribution or the Work. Some CLAs with patent licenses (e.g. the Apache CLA) also include provisions permitting the contributor to terminate the patent license granted to any licensee that sues on the basis that the contribution or its use constitutes infringement of patents the licensee owns or controls.
3. Representations and Warranties. Typically, CLAs (and to an extent DCOs) require the contributor to represent and warrant that they (individually, or on behalf of their employer) have sufficient rights (as owner or licensee) to make the contribution and grant the licenses specified in the CLA, or to disclose if that is not the case. Requiring these representations can help reduce the possibility that contributors will contribute code without the necessary rights, and can help protect Projects and Users if the representations are false, especially in the case of corporate CLAs.
4. Disclaimers. Except for whatever warranties are specified in the CLA, CLAs typically specify that the contribution is provided “As-Is” and disclaim all other express or implied warranties, including warranties of title, non-infringement, merchantability, and fitness for a particular purpose. Such warranties are intended to help protect contributors from User claims regarding contributions and failure to include them can raise significant contributor concerns.
5. Assignment of Contributions. Occasionally, a CLA will require the contributor to assign its ownership of the copyright in the contribution to the Project, rather than simply grant a copyright license. Although assignment has some potential benefits from a Project’s perspective, it has drawbacks as well. On the one hand, only the copyright owner typically has the right to enforce a copyright. Therefore, assignment can provide a Project with standing to sue and enforce the copyright in a contribution against infringers. On the other hand, ownership of the copyright in each contribution is not necessary to support the Project License or the Project’s ability to enforce the copyright in the larger Project Work. Requiring copyright assignment can discourage contribution and make collaboration with other open source software Projects more challenging; if a contributor has to assign their copyright to a Project, they might then be unable to contribute some of the same code to another Project. Similarly, since a contributor must own the copyright in their code in order to assign it, requiring assignment would make it impossible to submit contributions that include open source code obtained from other Projects. As a result, instances of an outright assignment requirement in a CLA are rare.

Given the flexibility of CLAs, and the comfort they generally provide for corporate Projects and Users, CLAs have traditionally been considered well suited for open source Projects that are expected to be long in duration or broad in scope, or to have large institutional supporters who place a premium on lack of ambiguity, risk avoidance and legal clarity. At the same time, proponents of DCOs would note that these CLA benefits come at a price, including logistical challenges and administrative burdens, as discussed further below. And CLAs may be unpopular with the community of developers a Project wishes to attract.

Individual vs. Corporate CLAs

A related issue is whether to use an “individual” CLA or a “corporate” CLA. As the names suggest, individual CLAs are intended for use when a contribution is being made by an individual person, on his or her own behalf. Corporate CLAs are intended for use when a contribution is being made by and on behalf of a company. Some CLAs cover both scenarios. As noted earlier, it is the owner of the copyright in a contribution that has the right under copyright law to prevent unauthorized use. Generally, as a matter of copyright law, the copyright in code produced by an employee acting in that capacity is considered a “work-made-for-hire” and therefore owned by the employer. The company would also generally be the owner if the code was developed in the course of the contracted-for services by an independent contractor with an enforceable assignment of inventions clause in their contract.

As a result, an individual developer who creates code in a professional capacity (as employee or contractor) very well may not be the code’s owner, and therefore may not have the right to make the contribution, unless they are doing so on behalf of the company and have authority to do so. Additionally, if a contribution is being made by an employee or contractor of a company, to the extent that company owns patents that might be infringed by the use of the code, obtaining a corresponding patent license from the company may be important, and it may be unclear (at best) whether the individual developer has the right or authority to grant such a license. In these situations, a corporate CLA executed by an individual with authority to enter into an agreement on behalf of the company, rather than by the individual developer, may help to reduce uncertainty and ensure that Users have the rights they need.

DCOs

A DCO is essentially a developer’s certification (a) that they have the right to submit specified code to the Project under either the open source license agreement indicated in the contributed files, or the applicable Project License (each a “Contribution License”), or that they received the code from someone else who has stated the same, and (b) that they acknowledge the Project may make that code and the resulting Work available under the applicable Project License.

DCO Process

The DCO was first introduced in 2004 by The Linux Foundation (then known as OSDL – the Open Source Development Labs), in connection with its Linux kernel project. The current Linux Foundation DCO (https://developercertificate.org/) has been adopted verbatim by most Projects that use DCOs, and reads (in its entirety) as follows:

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 it.

(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) involved.

In order to submit code under the DCO where the Project has adopted that approach, the developer must simply add a “Signed-off-by: ” statement in the commit message (where the name is the name of the developer).

DCO Drivers

Unlike CLAs, DCOs do not include express copyright or patent license grants, extensive representations or warranties, disclaimers, assignment of contributions, or other terms found in CLAs. Instead, they are intended to reduce barriers to contribution by simplifying the contribution process, referencing the Contribution License (rather than stating specific terms), addressing developer concerns regarding CLAs, and supporting the “Inbound=Outbound” ideology of many DCO proponents. Some of the primary complaints regarding CLAs that drive the adoption of DCOs are:

1. Inbound=Outbound. As a matter of fairness, equality, and to add certainty regarding the specific open source license that will be used to distribute contributions, DCO proponents generally assert that the terms under which contributors make contributions should be the same as the terms of the applicable outgoing Contribution License granted to Users. That is, “inbound=outbound.” Accordingly, such proponents assert that Projects should not have the right to change downstream license terms after contributions have been made, as is generally possible under CLAs. This model is implemented in DCOs by requiring contributors to certify that they have the right to submit their code “under the open source license indicated in the file,” and to acknowledge that the project and contribution “may be redistributed consistent with the project or the open source license(s) involved.”
2. Administrative Burdens and Bureaucracy. Proponents of DCOs suggest that administrative burdens and bureaucracy associated with CLAs slow contribution and the open source development process. For example:

• CLAs may be non-standardized and complex, requiring significant legal review (especially for corporate contributors)
• Corporate contributors may have difficulty obtaining CLA signatures
• Projects may need to establish and follow policies for monitoring and tracking CLAs, deciding whether employees should sign individual CLAs even if the employer has a corporate CLA on file, or deciding how to verify whether a company’s employee is contributing individually or on behalf of its employer

DCOs are specifically designed to reduce such administrative burdens by placing a high priority on brevity, standardization, simple review and implementation. On the other hand, there can also be logistical and administrative hurdles associated with using DCOs, and a developer may unknowingly (or knowingly) provide a DCO when in fact she does not have all the rights asserted in that document. Where a corporate CLA is on file, that risk is greatly reduced.

3. Assignment of Contributor Rights. Most CLAs do not include required assignment provisions, and developers will often object to CLAs that do. As DCOs do not assign contain copyright assignments, many developers believe they are preferable to CLAs in that regard.

Comparison to CLAs

Generally, DCO proponents agree that, either indirectly, by implication, or otherwise, DCOs give Users and Projects the assurances necessary to use and distribute contributed code as needed and in accordance with the applicable Contribution License. As noted below, this conclusion depends in part on the actual DCO terms, and in part on a balancing of (a) the practical value of the traditional contract terms typical of CLAs, and (b) the benefits of potentially increasing contributions by dispensing with those traditional terms.

1. License Grants. Perhaps most importantly, DCOs do not contain express license grants. For CLA proponents, this can be a significant concern, as most CLA proponents (corporate contributors or users) are accustomed to contract review, have resources to invest in related processes, and value the clarity, detail and express provisions contained in CLAs. On the other hand, DCOs contain the contributor’s affirmations that they have (or believe they have) the right to submit their contributions under the applicable Contribution Licenses. This, combined with the express reference to a specific Contribution License in the DCO and the actual terms of the Contribution License, is generally accepted to mean that the contributor is granting a license on the terms specified in the Contribution License (including the other terms of the Contribution License, such as warranty limitations, patent license grants, etc.).

Whether this conclusion is accurate as a legal matter is an open question, but arguably, it would be challenging (although not impossible) for a contributor (individual or corporate) to submit code under a DCO and then successfully sue Users for infringement or argue in court that they did not intend to license their contribution under the applicable open source license. Additionally, DCO proponents note that: (a) most individual contributors likely do not have the resources or inclination to engage in infringement litigation, and (b) even if they do, it would likely be seen as “taboo” by the open source community for a contributor (individual or corporate) to voluntarily submit code under a DCO, then reverse position by asserting infringement. Contributors taking such a position could potentially face exclusion from participation in other Projects, and would likely find it near impossible to build participation in their own. For more regarding this taboo, see “Microsoft and OIN: Legal Commitments vs. the Power of the Taboo,” by my Partner, Andy Updegrove. A more concerning possibility is that a third party may be the author of the contributed code, or that the contributor made a mistake in relation to the license under which the third party code was available (e.g., a restrictive (“copyleft”) license, where the Project the code was contributed to utilized a permissive license).

2. Representations and Warranties. Although DCOs contain developer affirmations that they have the right to submit the code, these are not presented or worded as traditional representations and warranties, and are not as comprehensive as the representations and warranties contained in CLAs or Contribution Licenses. And even assuming that by referencing the Contribution License a DCO thereby incorporates the broader representations, warranties and other terms of the Contribution License, it is an open question whether a “Signed-off-by: ” statement in a contribution file is legally enforceable by a Project or User. On the other hand, as a practical matter, the value of enforceable representations and warranties (at least in part) is that if they prove to be false, the aggrieved party may be entitled to sue the representing party for damages. But for Projects that use DCOs, and in particular where contributors are likely to be individuals without the kind of deep pockets that make litigation attractive, the benefits of using DCOs and thereby increasing contribution may well outweigh the benefits of requiring traditional, enforceable representations and warranties.
3. Disclaimers. As noted earlier, CLAs typically include “As-Is” language and express disclaimers of warranties (other than those expressly set forth in the CLA), all of which serve to benefit contributors and shield them from potential liability, in particular where the code is defective or its use may have unintended consequences. DCOs contain no such express disclaimers, and therefore arguably may be more risky for contributors in that regard. That said, DCOs reference the relevant Contribution License, and virtually all Contribution Licenses contain such disclaimers. As a result, proponents of DCOs would suggest that contributors benefit from those disclaimers because they are in the referenced Contribution License.
4. Relicensing. As noted above, the broad license grants typical of CLAs support changes to downstream license terms should the need arise. Assuming a DCO equates to a license grant on the terms of the applicable Contribution License, it is arguable that because a DCO specifically references the “the open source license indicated in the file,” the license(s) provided for under the DCO model are limited to the specific grants in the Contribution License in effect at the time of the contribution. If correct, the license granted in a DCO would not provide flexibility to change downstream license terms after the time of contribution (e.g., if an updated version of the Project License was created). As a practical matter, however, it is extremely rare for a Project to want to change its Project License terms midway through its life cycle. Additionally, as long as the Contribution License is permissive, it is likely compatible with other permissive open source licenses. As a result, although flexibility to change licensing terms may be preferable in some situations, the inability to do so may not be a significant concern as a practical matter.

Conclusion

Ultimately, CLAs and DCOs serve the same function – to help assure Projects and their Users that they have sufficient rights to use contributed open source code as intended. CLAs get there the more traditional way – they spell out the contributor’s rights, obligations and warranties in legal terms, and are therefore attractive to those who find such terms familiar and comforting. On the other hand, CLAs are typically somewhat complex, often require legal review, and may present logistical and administrative hurdles that cause some contributors to simply walk away. DCOs instead rely on a linkage to the language of the Contribution Agreement, and therefore dispense with virtually all of the formality and legalese of CLAs. As a result, they are short and easy to implement, require virtually no review, and are unlikely to drive away contributions. Choosing between CLAs and DCOs ultimately depends on factors such as the size, longevity and corporate support of the Project, the ideologies and views of those involved, and potentially competing goals of increasing (or removing barriers to) contribution and minimizing potential uncertainty and risk. But it’s no surprise that DCOs have become increasingly popular as the comfort factor in these light-weight legal tools has spread and grown.