Today we are announcing the open source beta-release of EasyCLA, one of several services that are part of LFX.
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.
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.
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:
EasyCLA removes many of these manual processes by doing the following:
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:
Any project hosted by the Linux Foundation and using either GitHub or Gerrit can use EasyCLA.
Contributors, Project Maintainers, and Companies can all benefit:
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.
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.
For Company
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.
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!
—