A very common question I get from corporate clients is whether they should use Developer’s Certificates of Origin (DCOs) or contributor agreements for their open source projects. I’ll refer to both contributor licensing agreements (like Apache’s) and contributor copyright assignment agreements (like MongoDB’s) as “CLAs” here.
In short, the answer is that DCOs work well for entities that are ideologically committed to open source. DCOs are a particularly good fit for license stewards like the Free Software Foundation, who are very invested in their licenses of choice. DCOs work less well for for-profit entities that are concerned with retaining licensing flexibility and being able to exercise their intellectual property rights, both offensively and defensively. While DCOs are definitely becoming more popular and failure to use them may mean fewer contributors, it’s important to remember that they were introduced and propagated specifically to rein in corporate behavior with respect to open source projects.
Companies can successfully go the CLA or the DCO route, but that success will be highly dependent on the company’s priorities, competitive environment, licensing models, and need for licensing flexibility. Here are the main divides between DCOs and CLAs:
1. CLAs allow for easy relicensing whereas DCOs discourage it. Contributor licensing agreements typically require that the contributor grant a very broad license to the contribution to the project’s owner. In the case of contributor assignment agreements, the contributor transfers copyright ownership of the contribution to the project’s owner. Either one allows a company to easily change a project’s (or a contribution’s) license to a different open source license or to license the project (or a contribution) under a commercial license.
DCOs function under the “inbound=outbound” model, i.e. contributors grant the project contributions under the same license as the project itself. That means that if a project wanted to change its license, the project would need to actively reach out to all of its contributors and ask for a broader license that would allow for the contributions to be relicensed.* (That would also be the case if the project had no DCOs or CLAs at all.) If a company wanted to move a feature out of an open source version of its product and into an enterprise version of its product, it would likewise need to separately get a license from contributors to that feature to license that contribution out commercially and not under the original project license.**
It took Mozilla 5 years to move Firefox from MPL 1.1 to MPL 2.0 because they did not have contributor agreements in place at the time. It took OpenSSL about 2 years to move from the OpenSSL/SSLeay license to Apache 2.0. In both cases, the projects were not owned by commercial entities, the licensing move was not motivated by profit, and the license change was not drastic. Corporate projects should probably expect this process to take longer and to receive more pushback from contributors, especially if the licensing change results in the project moving from a permissive to a copyleft license or vice versa or if the project is going to become commercially licensed.
As you can see, DCOs offer less flexibility for a commercial enterprise that is driven by the needs of its customers and the shifting market. A need to relicense for a commercial enterprise may arise because of changing developer preferences, a court decision that redefines the open source license in an unfavorable way or invalidates it entirely (this happened with the Artistic License 1.0), a desire to pick a license more compatible with another key technology, or the need to rethink which features should be under an open source license and which should get moved into an enterprise version of the product. That desire for flexibility runs into direct conflict with DCOs precisely because DCOs were designed to prevent projects from changing licenses over time (“inbound=outbound is the way a FLOSS community implements their morality”).
Think about it this way: the projects where DCOs originated are ones where the participants have as much if not more allegiance to the license itself than they do to the project. These entities are likely to defend their chosen license in litigation (including via amicus briefs and the like), and to manage litigation in a way that will preserve the intended meaning of the license, even at the expense of a specific project or copyright holder. For most corporate entities, however, their primary commitments are to their customers, shareholders and employees; they should switch licenses if they need to and retaining the ability to do that in the worst-case scenario can be the difference between staying in business or not.
2. CLAs have explicit patent grants that can protect a company from patent lawsuits, whereas DCOs don’t. Individual contributors are very unlikely to instigate patent litigation with respect to an open source contribution they made, but a corporate contributor might. While it may seem silly that a company would sue another company for contributions it willingly made, keep in mind that a company will not consider a contribution “willingly made” if its legal department wasn’t aware of it and didn’t sign off on it.
A patent grant is standard and straightforward in a CLA, clearly signed by the corporate contributor. DCOs, on the other hand, are problematic for three reasons:
1) DCOs don’t look and feel like a legal contract, making it less likely an employee will run it by their legal department and get proper sign-off;
2) No court has ruled that tags in DVCS commit logs can substitute for signing a contract (click-throughs, however, do constitute a legal signature), and
3) It’s unknown if the tag is being put in place by someone in their individual capacity or in their corporate capacity – there’s no way to tell who is actually “signing” up to the DCO since there is no point when a contributor is prompted to disclose this information.
Even Bradley Kuhn, who is one of the biggest proponent of DCOs will admit this shortcoming of DCOs.
3. CLAs make the contributor responsible for any intellectual property infringement due to their contribution, whereas DCOs mostly don’t. This is not particularly relevant or useful for individual contributors because no one would want the public relations fallout from suing an individual contributor no matter the circumstances, and individual contributors are unlikely to be able to pay out any significant damages.
However, this is useful for corporate contributors, especially those whose contributions are not new features but instead just integrations to their own products or services. Even if they were unaware of their code violating someone else’s patent, it may be equitable to hold them liable if they are receiving as much or more benefit from the integration as the project. Note that the DCO’s language with respect to this issue is fairly weak and it is unclear just how far it goes, whereas CLAs are clear that the contributor is responsible for all intellectual property infringement in their contribution.
The best way to square the difference with respect to individual and corporate liability for intellectual property infringement is to offer separate CLAs for individual and corporate contributors.
4. Copyright assignment agreements can ensure a company’s ability to sue or countersue a competitor for intellectual property infringement. In order to have standing in court to sue or counter-sue in relation to a contribution, a company must have copyright ownership over the contribution and the copyright must be registered. Only a contributor copyright assignment agreement can effect that.
Under a DCO, a contributor grants a company a non-exclusive license to the code they are contributing, but not ownership, meaning that it would not aid in securing a company’s standing before a court. Practically speaking, a company may have to find the contributor or their heirs and ask them to participate in the litigation in order to enforce an intellectual property claim related to a contribution given under a DCO.
Many CLAs also do not take copyright ownership over a contribution, but merely a broad license. With regard to this issue, they are on equal footing with DCOs. Whether to ask for copyright assignment rather than a broad license is a question that’s answered differently by different tech companies and even different open source foundations. Google does not take ownership for example, but the FSF does. Whether or not this aspect of a CLA is important to a company hinges on whether it is in a competitive space that is likely to yield lawsuits from competitors, whether the company itself is likely to bring lawsuits against competitors, whether and what portion of the contributions the company receives are substantial/key to its products, and how well a company tracks who is contributing what to its products.
5. CLAs can help minimize administrative overhead. With a CLA, any code contributed to a company can be used in whatever way the company desires and it is not necessary to track the contribution or its provenance. The CLA itself can be a simple click-through whose results are automatically stored.
However, if a company does not use CLAs, but it remains concerned about its ability to relicense or its ability to bring or counter a lawsuit, then it will still want to keep track of who contributed what (and whether in their personal or professional capacity), including contact information. This may be difficult at first because not all contributors mark their contributions with their names and contact information, and it will become harder over time if code is merged or refactored since notices can easily be lost during that process and over time there will be downright philosophical questions about who really wrote the resulting code.
Note that this is truly more difficult than it may seem given the German court’s ruling for VMware against a Linux contributor. The court there said that the contributor’s reference to his GIT commits was insufficient basis for determining what was his copyrighted work. This ruling potentially goes both ways: if GIT commits aren’t sufficient for a contributor to lay claim to his contributions, then they may also not be sufficient for a project owner to lay claim to its own work, either.
In the end, the system a company creates to track this information is likely to be even more complicated than just a simple click-through CLA.
______________________________________________________________________________
* It might be possible for a project to change licenses but keep the contributions under the original project license if the original and the new license were compatible. However, in many cases the entire reason for a license change is to become compatible with some other license, so this may not be possible. Also, keeping contributions under one license while moving the project as a whole onto another is practically very difficult because over time as code is modified and refactored, it becomes difficult to draw the line between that original contribution and the evolving project. So, keeping a few contributions under the original license might be possible if they’re distinguished and sequestered, but this is like not a viable plan for all of a project’s contributions.
** Depending on the original project license, the company could include the feature in a commercially project licensed without getting contributor sign-off, so long as that particular feature remained under the original project license. Of course, if the license is copyleft, the company would still have to provide source code for that particular feature.
One thought on “Should I Use a Developer’s Certificate of Origin or a Contributor Agreement?”