It is not unusual for a commercial software package to consist of millions of lines of code, with customized software combined with preexisting software, such as libraries, interfaces, or services, developed by third parties. Open source projects can provide software developers with a valuable resource for such third-party software. By incorporating these projects into their own code, software developers can reduce inefficiencies that result from writing software libraries that already exist and solving problems that have already been overcome.
An open source project comprises a community of software developers that agree to develop a common software-code base and make it freely available but subject to certain license requirements. The resulting software is typically vetted by multiple contributors to the open source project and may be further updated and improved based on their contributions. Open source software is prevalent in many popular software products, including Mozilla Firefox, Wordpress, GNU/Linux, Android mobile devices, Open Java Development Kit (OpenJDK), and even commercial products like Apple's OS X.
There are different views about how an open source project should manage the ownership and licensing of copyrights for individual software contributions to the project. One option is for an author (copyright holder) of such software to retain ownership of the software's copyright but contribute it under an open source license defined by the project. If the open source project is managed by a single entity (“maintainer”), the author instead may license the software copyright to the project's maintainer, which in turn releases the software under the project's open source license. In another option, the author of the software contribution may assign ownership of the software copyright to the maintainer, which releases the software under the project's open source license. Of course, another option is not to define any specific policy for licensing or ownership of software contributions to the project.
One way of managing the rights associated with contributions is through a Contributor License Agreement (CLA), sometimes referred to as a “contribution agreement.” There is some disagreement, however, in the open source community about whether a CLA should be required of individual contributors. A CLA may be used to define the legal terms, such as rights and obligations of the contributor, that apply to contributions (usually software) to the open source project. The CLA, for example, may require the contributor to grant a copyright license in the contribution to the open source project, its maintainer, and/or downstream recipients. Because CLAs are not standardized, contributions to different open source projects may be subject to different CLAs or none at all. While smaller, informal open source projects may not require CLAs, such as for hobbyist groups coordinating through a GitHub repository, larger projects, often backed by one or more corporations, may require formal CLA agreements from its contributors. Several well-known open source projects, such as The Apache Software Foundation, Django Software Foundation, Eclipse Foundation, just to name a few, require CLAs.
As discussed further below, open source projects have to weigh the pros and cons of requiring its individual contributors to sign a CLA. Here, we summarize some of the factors to consider when deciding whether a CLA would be appropriate for an open source project.
Contributor License Agreements
There are several choices of how to implement a CLA. Some projects may opt for a short and simple CLA agreement, while others may choose a more detailed legal instrument. Further, some projects may require separate CLAs for individual and corporate contributors. While CLAs can take many different forms, here are some provisions that are often included.
In general, a CLA is used to grant sufficient rights to the open source project to allow it to release a software contribution under the project's open source license(s). In a simple case, the CLA may require each contributor to assign ownership of the copyright in the contribution to the open source project. The assignment may be coupled with a nonexclusive license granted back to the contributor, a “grant-back license,” which gives the original author permission to copy, modify, or distribute the contribution and its derivative works under the grant-back license. The Free Software Foundation, for example, uses this approach for some of its GNU projects, allowing a single maintainer to own and enforce the copyrights for the project's software.
More common, however, a CLA includes a copyright license that enables the author of the contribution to retain ownership of the copyright, which may be more desirable from the contributor's perspective. The copyright license in the CLA cannot be more restrictive than the open source license used to distribute the project's code. For example, if the open source project distributes its code under a “permissive” copyright license, such as the MIT or BSD license, then its CLA cannot require software contributions under a more restrictive license, such as a “copyleft” GPL license. Doing so would impose additional restrictions that would preclude distribution under the project's permissive license and undermine the original intent of the permissive license.
In addition, a CLA typically requires the contributor to make certain representations and warranties, which may include one or more of:
- the contributor is the author of the contribution;
- the contributor has the legal right to grant the copyright license;
- the contributor does not have an employer that can claim rights in the copyright;
- the contribution is an original work;
- the contribution is not subject to third-party licenses, claims, suits, or actions.
The CLA also may include certain disclaimers by the contributor. For example, the CLA may state that the contributor provides the contribution on an “As Is” basis, without any express or implied warranties as to title, non-infringement, merchantability, and/or fitness for a particular purpose. The CLA may disclaim any express or implied warranties that would require the contributor to provide ongoing technical support for the contribution.
Some CLAs further require the contributor to grant a patent license that prevents the author of a contribution to the open source project from later alleging patent infringement based on the contribution. The Google Individual CLA is an example of a contribution agreement including such a patent license.
As seen above, a CLA is essentially a legal contract that can be customized for a particular open source project. While the CLA can set forth certain rights and obligations for a contributor based on their contribution to an open source project, it can also include restrictions on how the project itself may license and distribute the contribution.
Benefits of Using a CLA
A CLA can provide several advantages for an open source project having multiple contributors. By expressly describing rights and obligations of contributors, the open source project, and/or maintainer, the CLA can protect each of the project's participants from disputes regarding licensing or ownership of software contributions. For projects where the contributors include employees of collaborating corporations, the CLA can also provide peace of mind to the corporate employers that certain legal protections are in place to reduce the possibility of intellectual-property disputes based on their employees' contributions to the project.
The CLA also provides legal assurances for the open source project and its maintainer. The open source project, for example, can rely on representations and warranties in the CLA that a contributor has the right to make the contribution, has the right to grant a copyright license to the contribution, and is not precluded from making the contribution based on any intellectual-property rights of an employer. CLAs that include a patent license can protect the open source project, its maintainer, and downstream recipients of an open source contribution from the contributor later alleging patent infringement based on making, using, selling, offering for sale, or importing the contribution.
The CLA can also include other provisions that may be beneficial for the open source project over the long term, such as to address who will be responsible for enforcing the open source license in the event of copyright infringement and any preferred alternative dispute resolution or governing law that should apply. The CLA could also clarify if it applies to contributions to only certain software in an open source project, the entire open source code base, or across multiple projects maintained by the same entity. Further, the CLA may include provisions that would permit the open source project to change open source licenses over time without having to seek authorization from each of its contributors before making the change. The CLA also could authorize the open source project to distribute the contribution simultaneously under separate licenses, such as an open source and proprietary licenses, depending on whether the code will be used commercially. Oracle's MySQL is an example of an open source project with such a dual-license approach.
Another advantage of using a CLA is that it provides a formal mechanism for the open source project to keep track of its contributors and contributions. Each contributor may provide identifying information in the CLA that can allow the project maintainer to keep track of who are the primary contributors to the project, where they are employed, and other statistical information regarding the project's contributions.
To assist maintainers, there are several publicly-available examples of CLAs and related management tools that can be used to implement a CLA based on the particular needs of an open source project.
Even without a CLA, open source projects can leverage the policies of popular online code repositories like GitHub. GitHub projects can benefit from the default “inbound=outbound” contribution policy in GitHub's Terms of Service. According to this policy, whenever a contributor makes a contribution to any GitHub repository containing notice of a license, the contributor agrees to license the contribution under the same terms. If, however, the GitHub repository for the open source project provides a separate contribution agreement, that CLA will supersede GitHub's default “inbound=outbound” policy. Thus, even absent a CLA, the open source project can rely on this GitHub contribution policy to ensure that any contributions to the project can be released under the project's open source license.
Disadvantages of Using a CLA
There may be compelling reasons why an open source project may not want to use a CLA. A common criticism of CLAs is their potential to discourage contributions to the open source project. A legal contract defining rights and obligations, and potential liabilities, associated with a contribution can be intimidating to software developers who simply want to contribute minor bug fixes or other refinements to existing open source code. Creating additional barriers prior to allowing contribution can disincentivize those who would otherwise contribute.
Additionally, individual contributors may be deterred from agreeing to the terms of a CLA if they do not understand the legalities or consequences of signing the agreement (online or offline) or otherwise agreeing to its terms. Without legal representation, individual contributors may perceive the CLA terms as coercive or unfair. Corporate contributors also may be hesitant to agree to a CLA or allowing their employees to agree to a CLA before seeking authorization from their legal counsel. Yet other contributors may prefer to remain anonymous, which may not be possible when a project requires a CLA. As a result, potential contributors may choose not to make helpful software contributions to the open source project because of fear, misunderstanding, or inconvenience associated with signing the CLA.
Another possible disadvantage is the administrative overhead required to catalog and maintain a database of CLAs received for each contribution in an open source project. For projects having a large number of contributions and/or contributors, this can be a non-trivial task. Further still, it can be difficult to police when contributions have been received without a corresponding CLA and how to handle such submissions.
Other arguments against CLAs suggest an “inbound=outbound” contribution policy should be implied when a contribution is made to an open source project, thus mooting the need for a CLA. While the GitHub Terms of Service expressly defines such a contribution policy as its default, the “inbound=outbound” policy may not be a safe assumption for open source projects hosted on other platforms. Further, although a licensor delivering an original work requested by a licensee for distribution may imply a nonexclusive copyright license, it is unclear whether a court would find that a voluntary contribution to an open source project creates an implied copyright license or an implied “inbound=outbound” policy.
A CLA also may not be necessary if the open source project instead chooses to use a Developer Certificate of Origin (DCO). The DCO was created by the Linux Foundation as a concise statement for a contributor to certify that they either created their contribution or are otherwise authorized to submit it to open source project and agree that their contribution may be distributed under the project's open source license(s). In a sense, the DCO is like a lightweight CLA that may be more appealing to contributors who would otherwise refuse to sign a CLA with more comprehensive terms.
Conclusion
A CLA can provide a useful tool for providing clarity and defining certain rights and obligations that apply to contributions in an open source project. They can help maintain the integrity of the project and protect the project from potential legal exposure, particularly when multiple corporate entities are involved. CLAs, however, may not be ideal for every project. They can include legal terms that require review and sign-off by lawyers and also may require substantial administrative overhead for the maintainer of the project. CLAs may find particular usefulness in larger projects, having many contributions and contributors, that will persist for a long time. But CLAs may have less utility for relatively smaller or less formal open source communities where the code base is created by only a few contributors. Ultimately, the needs of a particular open source project will dictate whether or not a CLA will be beneficial and the specific CLA provisions that should be included.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
