EasyCLA helps maintainers of open source projects to streamline their workflows and reduce the hassles of managing Contributor License Agreements (CLAs) and authorizing contributors.
By automating many of the manual processes, this software-as-a-service hosted by the Linux Foundation reduces delays for developers to get authorized under a CLA.
Companies involved in open source projects benefit from having direct control over and visibility into which of their developers can contribute under their signed Corporate CLA.
The Linux Foundation already manages over 10,000 signed CLAs. This experience has enabled us to build EasyCLA so it can scale with the largest open source projects, freeing up thousands of hours of time for developers, maintainers, and companies contributing to open source.
What is a CLA?
CLA stands for Contributor License Agreement, essentially a contract between the open source project entity and either an individual developer or the company contributing code.
CLAs are often categorized as either Individual CLAs and Corporate CLAs.
By signing an Individual CLA, an individual developer agrees that they have the right to contribute code and are doing so in accordance to the terms in the CLA. When an individual signs their Individual CLA, they bind their contributions to the project under the terms of the CLA.
The complexity multiplies, however, when the project requires a Corporate CLA.
Corporate CLAs are often desired to provide direct corporate authority for employees of a company to make contributions with explicit authority for the grants (e.g. a patent grant) in an open source license.
There are other potential uses of Corporate CLAs, but it’s a project’s decision whether to use a CLA or not. In some projects, a CLA may address concerns amongst the contributor and user communities that makes it easier for them to participate in the community. Other projects may not have the same level of concern and the CLA may, in fact, become a barrier to participation and “drive by” contributions
If the project decides to use a CLA and a contributing developer works for a company, a Corporate CLA needs to be signed by an authorized signatory of the company who employs them. By signing the Corporate CLA and then indicating which developers are authorized to contribute code under that CLA, the company removes ambiguity about who the company has authorized to contribute under the terms of the CLA and license for the project.
The Linux Foundation often recommends a “license-in” == “license-out” model where contributions are made under a project license with a Developer Certificate of Origin DCO “Signed-off-by” statement on each commit. This means that the developer self-certifies their right to contribute to a project. Projects can easily enforce the DCO “Signed-off-by” requirement in code review tools such as Gerrit, GitHub1 and GitLab for example.
Some projects have considerations that lead to requiring a CLA in addition to using the DCO.
The agreement could include, for example, a statement of the license terms for the contribution to that project; a confirmation that the developer’s employer has authorized the contribution under those terms; or statements confirming that the contributor actually wrote the contribution. Some project communities believe these explicit statements provide greater certainty about rights contributors grant to the project.
In this case, the project maintainers carry the burden of managing the CLAs and the lists of authorized contributors. The burden increases as the number of contributors grows.
Automating the CLA process with EasyCLA alleviates this administrative load on the maintainers.
What Challenges does EasyCLA solve?
For projects that use CLA, one of the biggest problems is that the whole process adds friction to the project maintainer.
The common CLA processes of filing paperwork, following up with an internal signatory, and ensuring commits are made by authorized developers is a huge administrative headache.
Some of those specific pains include:
- Tracking CLA paperwork, which is often spread across multiple emails or spreadsheets, is time-consuming and brittle
- Ensuring that the list of company developers authorized to contribute to open source projects is up-to-date requires manual, fragile, time-consuming effort.
- Collecting developers’ signatures and then waiting for maintainers to manually process CLAs can delay contributions
- Projects and their maintainers want to ensure that every contribution was made under a CLA
What does EasyCLA do?
EasyCLA removes many of these manual processes by doing the following:
- Automates the CLA signature and authorization workflows
- Notifies contributors if they need to sign the CLA, or get authorized under their employer’s CLA from within GitHub or Gerrit
- Blocks unauthorized contributors until they are authorized under a signed CLA
- Supports reusing CLAs across projects
- Enables each company signing a CLA to manage their own list of authorized contributors under their CLA
- Includes modified template CLAs based on the Apache Software Foundation’s CLAs, as an option for the project’s CLAs
How EasyCLA Works
EasyCLA begins with the Project Manager, who is the project maintainer responsible for selecting the appropriate Individual and Corporate CLA.
Traditionally, the Project Manager has had to enforce whether a contributor was authorized to commit code to their project. This would become especially cumbersome when getting signatures for Corporate CLAs from companies and updating each company’s whitelist of authorized developers.
With EasyCLA, the Project Manager can apply their CLA to their project and EasyCLA automates and streamlines the rest of the authorization process.
For an Individual developer, the process is straightforward: if they haven’t signed the project’s CLA, their commit will be blocked and they will be given a link that takes them to the CLA. After providing their e-signature agreeing to the CLA, all their future commits to that project will be allowed.
For a Corporate developer, the process is more complicated. We’ve defined three primary roles for this automated CLA workflow:
- Contributor: any developer wanting to contribute code to the project
- CLA Manager: person authorized to manage who can contribute under the company’s Corporate CLA
- CLA Signatory: the authorized signatory of the project’s CLA for the company
Who can use EasyCLA?
Any project hosted by the Linux Foundation and using either GitHub or Gerrit can use EasyCLA.
Contributors, Project Maintainers, and Companies can all benefit:
- Contributors submit code with minimal hassle from CLA paperwork.
- Project Maintainers stop worrying whether accepted pull requests fall under signed CLAs and managing the signed paperwork.
- Companies get greater comfort from a workflow that enables proper signing authority for Corporate CLAs.
If your project is not a Linux Foundation project, you can sign up here to indicate interest in using EasyCLA for your project. We are exploring support for non-LF projects on a case-by-case basis.
How to Get Started
For Project Maintainers
If you’re a maintainer of a project already using EasyCLA, you can login with your LF ID here to manage your CLAs.
If you are the CLA Manager for a company with developers contributing to Linux Foundation projects that are using EasyCLA, sign in with or create your LF ID here.
From there, you can send the agreement to the appropriate signatory. After the CLA has been signed, you can then can begin whitelisting developers.
Contribute Code to EasyCLA
The code running EasyCLA is open sourced.
While the code is open, there are still several dependencies in the code that would make it difficult right now to run the code on your own infrastructure.
However, if you feel there are features you want to add that will make EasyCLA work better for your, your project, or your company, then please go ahead and create an issue or submit a pull request!
- The Linux Foundation Brings Together IT and Finance Teams to Advance Cloud Financial Management and Education - June 29, 2020
- SODA Foundation Gains New Investments, Expands Charter to Address Increasing Need for Data Autonomy - June 29, 2020
- SPDX Specification Becomes the Second ISO/IEC JTC 1 Submission From JDF - June 29, 2020