From Tony Guntharp’s blog post on CLAs and CLAHub:
First of all, what exactly is a Contributor License Agreement (hereafter referred to as CLA)?
Most of us that have been employed as Software Engineers by corporations are already intimately familiar with CLAs although in the corporate world they are generally called a “Intellectual Property Assignment Agreement”. In many ways a CLA is nothing more than that but specifically geared towards Open Source projects.
A CLA is a legal document in which you state you are entitled to contribute the code/documentation/translation to the project you’re contributing to and are willing to have it used in distributions and derivative works. This means that should there be any kind of legal issue in the future as to the origins and ownership of any particular piece of code, then that project has the necessary forms on file from the contributor(s) saying they were permitted to make this contribution.
The CLA also ensures that once you have provided a contribution, you cannot try to withdraw permission for its use at a later date. People and companies can therefore use that software, confident that they will not be asked to stop using pieces of the code at a later date.
The CLA needs to grant rights to a project’s owner (or owning body/organization) that enable the release of the software in question. In the simplest scenario, a CLA is not, in fact, used at all; the contributor simply assigns the copyright to the project owner. When done properly, the contributor will need to sign a statement to that effect.
Thus the contributor needs to - at minimum - grant the rights that will be granted to the project’s owner in the distribution licence. When granting rights it is common to grant a very broad range of rights. This is in order to avoid the need to return to the contributor for authorization to take a desired action with their contribution, such as releasing under a different licence.
It is very, very important to record the assignment of copyright or grant of rights for each contribution or from each contributor. This means an Open Source project must track and record CLAs submitted by contributors. It is generally best to have a CLA signed and submitted to project administrators for permanent record prior to the contributor submitting his/her contributions.
Maintaining CLAs can be challenging but overall it is not a difficult task. It does increase the effort required to make and accept third-party contributions. Most contributors will start small; i.e., they will provide a simple bug-fix, or a spelling correction. The temptation is there to bypass the requirement of a CLA for small contributions.
This begs the the question, “Must a CLA be in place for every contribution?”
For small contributions, the risk of loss from legal action can be small. For larger chunks of code/documentation, incorporating major functionality, the risks would be much, much higher.
At the end of the day, it’s really up to the project owners and stakeholders on which contributions they chose to accept with and without a CLA.
So what notable Open Source projects are using a CLA? Here are just a few.
If you’re a developer with an Open Source project hosted on GitHub or an organization that’s doing the same then you should really take the time to evaluate CLAHub as it just integrates nicely with the existing tools and methods that you are more than likely already using.