Wiki

Edit this Page View Revision History

Contributor Agreements

How to Accept Code and Documentation Contributions Legally

After you have chosen a license and released your open source software, what do you do when someone posts a code or documentation contribution?

(For purposes of discussion, we’ll assume it’s a code contribution, also known as a “patch”. But everything below applies to documentation and other copyrightable contributions too.)

In other words, how does the project get the legal right to redistribute some contributor’s code changes? How does the project know the contributor won’t sue later for copyright infringement?

The answer is that the contributor gives the project that right formally, by signing an agreement saying that the project can redistribute the contributed code. Note the contributor only has to do this once per project. The agreement covers not only the current contribution but all subsquent ones, so the form is only requested with someone’s first contribution.

There are two general approaches:

  • Contributor License Agreement (CLA)

    With a CLA, the contributor retains formal copyright ownership of the contribution, but gives the project a (deep breath) non-exclusive, perpetual, world-wide, irrevocable, no-charge, royalty-free copyright license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute (etc, etc) the contribution. In other words, the contributor retains copyright, but promises not to exercise most of the powers that copyright ownership would ordinarily imply, thus enabling the project to feel safe in accepting the contribution.

    • CLAs can generally be submitted electronically, at least in the U.S. (apparently because they do not transfer ownership of any copyrights). Many open source projects accept CLAs by email or web form.

  • Copyright Assignment Agreement (CAA)

    With a CAA, the contributor assigns copyright ownership of the contribution to the project.

    • A CAA is more burdensome to execute; it usually involves faxing or mailing.
    • Can help with dual licensing.
    • Some contributing developers do not like them; see above about dual-licensing.

Which one should you use?

The short answer is: CLA.

For government projects, we recommend CLA rather than CAA, because a CLA is physically easier for contributors (it can be submitted by email or web form) and because some contributors may sign more readily when no actual transfer of ownership is involved.

CAAs, on the other hand, are mainly requested by private-sector corporations who seek to consolidate copyright ownership. There are various reasons why a corporation might want that. The most common are that it can simplify assertion of copyright internationally, and it can enable “dual-licensing” models where the corporation makes the software available under proprietary terms, for a fee, to customers who need exclusivity for one reason or another (such as marketing a proprietary product derived from the code base). But the transfer of ownership involved in a CAA, along with the possibility of dual-licensing, makes it harder to persuade some contributors to sign, even when the CAA contains a “license-back” provision ensuring that the contributor retains all meaningful rights with respect to their own changes, or even when it contains a promise to only distribute the assigned works under open source terms.

In the case of government code, and for that matter most private-sector code, there is no need to take on the complications involved in a CAA. As long as the contributor is willing to make their changes available via a CLA, that provides all the rights a government agency needs.

CLA examples:

CAA examples:

References:

There is an effort to standardize contributor agreements – see Project Harmony, “…a community-centered group focused on contributor agreements for free and open source software (FOSS).”

For a more detailed discussion of contributor agreements in general, see producingoss.com/en/contributor-agreements.html.

Open_Source