Contributor Licence Agreements

by Ross Gardler and Rowan Wilson on 4 January 2008 , last updated

Introduction

A Contributor Licence Agreement (CLA) is strongly recommended when accepting third party contributions to an open development project, such as an open source software project. In order to redistribute contributions, it is necessary to ensure that the project has the necessary rights to do so. A Contributor Licence Agreement is a lightweight agreement, signed by the copyright holder, that grants the necessary rights for the contribution to be redistributed as part of the project.

Contributor Licence Agreements also simplify the process of collaborating with partners on projects as they can form part of a broader collaboration agreement. Such agreements define ownership of copyright in works produced in collaboration and, furthermore, they describe any licensing of specific copyright in materials generated by the project. However, a collaboration agreement may also detail financial and structural arrangements in the partnership, while a CLA limits itself to addressing intellectual property rights (IPR) and is therefore more widely applicable.

Why is a CLA necessary?

The purpose of a CLA is to ensure that the guardian of a project’s outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence. In some cases this will mean that the contributor will assign the copyright in all contributions to the project owner; in other cases, they will grant an irrevocable licence to allow the project maintainer to use the contribution. CLAs also have roles in raising awareness of IPR issues within a project.

A CLA clearly defines what licence is granted or what rights are transferred when an individual or organisation contributes IPR to a project. Failure to either concentrate copyright in a single organisation or to grant a licence across partners often results in considerable complications for the future management of project outputs. For example, if it becomes necessary to change the licence on outputs, the full consent of all copyright holders is required. Such consent may be withheld or it may be impossible to contact a party thus making it impossible (or at least expensive) to proceed. Where copyright has been assigned to a single entity, or where the right to relicence the materials has been granted, there is no need to contact individual contributors.

It is important to realise that even contracted staff do not automatically assign copyright unless it is explicitly stated in their contract. It is therefore important that project managers ensure all contract staff sign a CLA for their contributions, or alternatively have suitable conditions written into their contract.

What needs to be in a CLA?

The CLA (or inbound licence) needs to grant rights to a project’s owner (or owning body) 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. This can have a number of benefits for the project, including allowing copyright infringements to be taken up by a single entity. Naturally, though, some contributors will not want to simply give away their IPR, and it is in these cases that a licence agreement is needed. The project will be granted certain rights over the contributor’s IPR, and in addition be granted the right to pass on (or sub-license) these grants to third parties.

Thus the contributor needs to - at minimum - grant the rights that will be granted to the end user in the distribution licence (the outbound licence) in addition to the right to sub-license. 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 authorisation to take a desired action with their contribution, such as releasing under a different licence.

A CLA should also contain personal information about the person that signs it, such as a complete name and mailing address. Beware of the potential implications that storing this information could have in terms of the data protection law in your country.

Recording CLAs

It is very important to record the assignment of copyright or grant of rights for each contribution. This means a project must track and record CLAs submitted by contributors. There are two approaches a project can take when recording CLAs. The first is to insist that every contribution from a third party is accompanied by a CLA. The second is to have a CLA signed and submitted to project administrators for permanent record. Regardless of the type of CLA in use, a project must ensure that they are recorded permanently. Which process is the best for a project depends on how the project accepts third party contributions.

Generally, contributions to open source projects go through one of two processes. These are commonly known as review-then-commit and commit-then-review. The name refers to the order of processing of contributions.

Review-then-commit

In a review-then-commit process, the contribution is submitted to the project in the form of a software patch, usually via an issue tracker or a mailing list. The patch is then peer-reviewed and commented on as appropriate. A subsequent patch may be submitted in response to the feedback, which in turn will be peer reviewed. Once the patch has been approved, it will be committed to the project; that is, the patch will be applied to the revision control system and thus will appear in future releases of the software.

Since this process requires a patch submission step, it is possible to require each submission to be accompanied by a signed CLA. Some projects allow this assignment to be a simple check box in the issue tracker submission form. Whether recording acceptance in this way is suitable for your project will be something you will need to discuss internally, and possibly with legal support, and relates directly to the project’s tolerance for risk. This approach is found in some significant open development communities, such as the Apache Software Foundation. An alternative approach can be found in the Linux kernel project. Here, patches are submitted to a special mailing list. Each patch must have the CLA text appended to the end of the submission email.

Allowing CLAs to be submitted for each contribution, at the time of contribution, is efficient in that there is no need to wait for the CLA to be acknowledged by the project before the contribution can be made. This streamlining of the submission process is critical if a project is to welcome new contributors wishing to make even the smallest contribution, as it ensures that the process of signing a CLA is less cumbersome than submitting the patch. If it is not, then many potential contributors simply will not bother to contribute.

Commit-then-review

In a commit-then-review process, the contributor is able to commit the changes directly to the revision control system. This will trigger a notification to the community that a change has been made and they will then peer-review the committed code. In some cases, comments will be forthcoming and changes may be made; in other cases, the commit will pass review without modification. Clearly, commit-then-review is only appropriate for contributors who have shown they have a clear understanding of the project and are able to make sensible judgement calls about what should/should not be committed. Most projects that operate a commit-then-review policy only do so for core members of the development team; other members operate under a review-then-commit process.

Since this process allows contributors to add content directly to the project without going through a separate contribution process, it is not possible to enforce the signing of the CLA for each contribution. Therefore it is necessary to have a CLA signed and on file for such contributors. The increased overhead this creates for both the project and the contributor is worth the short-term pain, since any contributor the project trusts to have direct access to the revision control system is likely to be a significant contributor in the future.

Associating commits to CLAs

Regardless of how a project chooses to record CLAs, it is important that a record of the CLA for each contribution is kept on file. This is to ensure that any dispute with respect to ownership of the project outputs can be resolved quickly and easily. That is, the project must be able to identify who made the contributions in question and prove that the necessary copyrights or licence to the IPR contained within it were granted to the project.

In order to maintain this audit trail, it is necessary to ensure that when a patch is applied, it is linked to the appropriate CLA. Again the process for this depends on the commit policy of the project.

For review-then-commit it is usual for the commit log message created by the person reviewing and applying the patch to contain a reference to the submission record containing the CLA. In the case of submission from an issue tracker, this will usually be the issue number; in the case of a mailing list submission, this will be a link to the mailing list archives.

For a commit-then-review process, it is necessary to ensure that the revision control username is associated with a CLA kept on file.

Risk-assessment

Maintaining CLAs is not a difficult task; however it does increase the effort required to make and accept third-party contributions. Most contributors will start small; that is, they will provide a simple bug-fix, or a spelling correction. The temptation is therefore to waive the requirement of CLAs for small contributions. This gives rise to the question, ‘Must a CLA be in place for every contribution, no matter how small?’

Some contributions - very minor bug-fixes or corrections to documentation (sometimes called ‘driveby contributions’) - are too insubstantial to be protected by copyright. In the case of contributions that are substantial, a brief risk-assessment must be made, weighing the risk of loss from legal action against the cost to the project of acquiring a CLA. For small contributions, the risk of loss from legal action would be vanishingly small. For larger chunks of code, incorporating major functionality, the risks would be much higher.

Along with a realistic assessment of risk, a well-planned take-down and excision policy is vital. If some code in your project becomes the subject of controversy over ownership, a willingness to cease distribution temporarily while removing or replacing the code will go a long way towards mitigating any potential legal losses, and also dissatisfaction among users.

Corporate Contributor Licence Agreements

Since most employment contracts state that copyright material generated in the course of an individual’s employment belongs to their employer, it is likely that a person who works on an open development project as part of their job will need a CLA signed by their employer. These are often called ‘Corporate Contibutor Licence Agreements’ or CCLAs.

Contributor Licence Agreements are just one component of a project’s governance model.

Further reading

Links:

Related information from OSS Watch: