For a project to use EasyCLA, it must meet the following requirements:
EasyCLA only supports for the projects that are hosted in the Linux Foundation.
It does not support the projects or repositories that are hosted outside the Linux Foundation.
The project repositories are in GitHub or Gerrit or GitLab
If the project uses Gerrit source control, the Gerrit instance should be hosted on The Linux Foundation platform.
The repository administrator should enable Branch Restrictions and Branch Protection for the repository in GitHub or GitLab. The restrictions and protection should be set to enable required status checks on a branch regardless of the role for the organization.
For a CLA Manager to access EasyCLA, they must register an LF Single Sign-On (SSO) account. If you do not have an LF SSO account, you can read how to create an account here.
For a company to sign a project's CCLA, they must identify the appropriate company employees who will be the CLA Manager and CLA Signatory for that CCLA.
How you interact with EasyCLA depends on your role. EasyCLA supports the following roles in its workflow:
When a CCLA is first being signed, the Contributor, CLA Manager, and CLA Signatory all might be the same person--or they might be different people. Each contributing company will determine for themselves which employees have these roles. Read below to understand these roles so that you can discuss with your company's management and legal counsel about who should be designated for each.
A Project Manager is someone (typically project administrator or maintainer of the project) who is responsible for setting up the project's CLA templates and configuring the corresponding repositories in the EasyCLA Project Console (also called Project Control Center). For more details, see Project Managers.
A Contributor is someone (typically a developer) who contributes code to a GitHub or Gerrit project that is set up on EasyCLA.
The specific workflow that a contributor follows will depend on:
whether the project is hosted on GitHub or Gerrit; and
whether they are contributing on behalf of themselves or a company (typically their employer).
After submitting a contribution on GitHub or Gerrit, if a Contributor has not yet been authorized under a signed CLA, then their contribution will be initially blocked. They will use the EasyCLA Contributor Console to either:
sign an ICLA (if contributing on their own behalf); or
identify the company on whose behalf they are contributing, so that they can either be authorized under a signed CCLA or else start the CCLA signing process.
A CLA Manager is someone who is authorized by a company to manage the list of authorized Contributors, and other CLA Managers, under that company’s CCLA for a project.
A CLA Manager uses the EasyCLA Corporate Console to:
When a CCLA is first being set up for signature, it will specify an "Initial CLA Manager". This person uses the EasyCLA Corporate Console to coordinate the signing of the CLA (see CLA Signatory below).
After the CCLA is fully signed, then the specified Initial CLA Manager will be able to use the EasyCLA Corporate Console to manage the list of authorized Contributors. They can also designate additional CLA Managers.
By default, a CLA Manager is not automatically an authorized Contributor themselves, unless they add themselves to the authorized Contributor list.
A CLA Signatory is someone who has been authorized by their company to sign a CCLA on its behalf.
If a company's CLA Signatory is the same as their Initial CLA Manager, then they will be redirected to sign the CCLA via the EasyCLA Corporate Console. If the CLA Signatory is a different person from the Initial CLA Manager, then the CLA Signatory will receive an email to review and sign the CCLA.
If you are authorized and receive an email request to sign contracts, then review and sign the project’s CLA on behalf of the company.
Who do I contact to enable my Linux Foundation-hosted project to use EasyCLA?
Open https://jira.linuxfoundation.org/plugins/servlet/theme/portal/4/create/143, submit the form describing your requirements, and import your existing CLAs.
Why does The Linux Foundation ask contributors of some projects to sign CLAs?
Some project communities have elected to use CLAs as a required step for code contributions. The Linux Foundation wants to ensure that contributions comply with the IP (Intellectual Property) policies of that project.
What is the difference between a Corporate CLA (CCLA) and an Individual CLA (ICLA)?
A Corporate CLA needs to be in place if you are contributing code on behalf of your employer. A Corporate CLA should be signed by an individual who is authorized to enter into legal agreement on behalf of the company. After the Corporate CLA is signed, your email address needs to be included in an approved list for the project. A CCLA manager for your company is responsible for managing the approved list.
An Individual CLA is signed by an individual for contributions that they contribute on their own behalf, as opposed to contributions on behalf of their employer or another entity.
How can I contribute to GitHub/Gerrit/GitLab repositories?
If you are an individual contributor, see Individual Contributor. If you are a corporate contributor, see Corporate Contributor for details.
Open your email, which you provided while signing the ICLA, to check the signed ICLA that was sent from The Linux Foundation. If you have not received the email, you can open a support ticket to have it resent.
Using the Domain Approval Criteria requires less overhead because CCLA signatories and CCLA managers do not need to add and manage numerous employee email addresses.
I contribute to an open source project on behalf of my employer. Do I need to sign anything?
Probably not. If your company's CCLA signatory has signed a Corporate CLA, and if you are included in the approved list under that company's CLA, then you simply confirm your association with the company during your code submission process.
However, if you are the first one from your company to contribute to a project, then your company's CCLA signatory will need to sign a Corporate CLA as part of the EasyCLA setup process. Depending on the company, you might be an authorized CCLA signatory (please check with the legal counsel of your company to be sure).
Otherwise, if your company has already signed a Corporate CLA but you are not yet on your company's approved list, you must be included on the approved list by your company's CCLA manager as part of the EasyCLA process.
When I am trying to contribute code under a CCLA, what should I do if my company is not listed?
You must add your company as described here before you can contribute code under corporate CLA (CCLA).
If my project community has elected to use CLAs as a required step for contributions to their code, do I need to be authorized under a CLA for each project to which I contribute?
Yes, provided that the project has a CLA.
If you are contributing as an individual—you must sign an Individual CLA for each project to which you contribute.
If you are contributing as an employee of a company, your company's CCLA signatory must sign a Corporate CLA.
Do I have to sign a CLA every time I contribute code to a project?
If you have already signed CLA for a project, then you don't need to sign every time to contribute to the project. Signing a CLA for a project covers all code contributions to that project. You may, however, need to sign additional CLAs if you choose to contribute to other projects that require CLAs.
Your ICLA will be emailed to the email address you provided when signing it, as soon as you sign it. If you did not receive the email, you can open a support ticket to have it resent.
(Individual Contributors) Wait for the few seconds or refresh the page to get your EasyCLA status updated.
(Corporate Contributors) After you complete the process, you must acknowledge acknowledging company contribution. If you have already acknowledged company contributions, wait for few seconds or refresh the page to get your EasyCLA status updated.
Why does EasyCLA redirect and update a previously opened PR instead of the one I performed the signature on?
When there are two or more opened PRs in the same repository, during the signature process, EasyCLA will always redirect and update the earliest opened PR. Once the signature has been completed, you can add a "/easycla"
comment on the other PRs to trigger the EasyCLA bot and update your authorization status for each open PR.
The cla/linuxfoundation check on my PR for a Kubernetes repo is not marked as passed after signing the CNCF CLA through EasyCLA?
Kubernetes repositories are in the process of migrating from CLA v1 (cla/linuxfoundation check) to EasyCLA (EasyCLA check). During this migration, the cla/linuxfoundation check is not being updated even when the users have properly signed the CLA. If the PR has the label "cncf-cla: yes," it means the authorization for the user has been granted. Note that the cla/linuxfoundation check is neither a requirement nor a blocker for merging the PR once all the required labels have been included.
Once the migration has been completed cla/linuxfoundation check will be removed.
What is the acceptable email format?
A valid email address with an email prefix and an email domain, for example abc@mail.com
The allowed characters for the email prefix are letters (a-z), numbers, underscores, periods, and dashes, and an underscore, period, or dash must be followed by one or more letters or numbers, for example: abc-d@mail.com/abc.def@mail.com/abc@mail.com/abc_def@mail.com
The allowed characters for an email domain are letters, numbers, and dashes, and the last portion of the domain must be at least two characters, for example:.com,.org,.cc.
If you are having issues with EasyCLA, go to The Linux Foundation Support Center, and file a ticket.
Following sections help you troubleshoot common problems that you might encounter when using EasyCLA tool.
I have an agreement on file, but EasyCLA does not authorize me and displays "Missing ID on Commit".
If your commits are linked to your GitHub account, and yet the GitHub pull request is not passing the EasyCLA check, then open the pull request, type/easycla
in the comment box, click Comment as shown below. This runs the EasyCLA bot again, and the GitHub pull request is passed.
Contributor's commits are linked to GitHub account, however, they are still having trouble contributing to EasyCLA-enforced repositories.
If your CLA Manager has approved your company email address or email domain, ensure that your company email is verified in your GitHub account settings and make sure your GitHub email address is public.
Or
If your CLA Manager has approved your GitHub Organization, ensure that you have made that membership public.
Contributor's commits are linked to Gerrit account, however, they are still having trouble contributing to EasyCLA-enforced repositories.
Ensure that your Gerrit email address is added to the approved list, and you must log in to Gerrit instance of your project using the same email address that is added to the approved list.
After a Contributor has signed an ICLA, EasyCLA status is not updated on contributor console.
It may take a few moments for the status of the EasyCLA checks to update. Please wait a few moments and then refresh the page. **** If the EasyCLA status is still not updated, open the pull request, and comment /easycla
in the comment section as shown below. This comment runs the bot again. If the status still does not change, open a support ticket.
After a Contributor has signed an ICLA, EasyCLA status on Git command line still displays "No contributor agreement" when the contributor pushes the code change.
For a CCLA, after a Contributor has been added to the approved list for the first time, the CLA status still displays Not Covered.
After being added to the approved list under their company's signed CCLA, the Contributor must acknowledge their association with the company. This is a one-time action and, after completion, it will not be required for future contributions to that project.
Although it is uncommon, some projects may require a Contributor under a CCLA to additionally sign an ICLA. If this is required, then after completing the company acknowledgement, the Contributor will be guided to sign the project's ICLA.
For a CCLA, after a contributor has been added to the approved list for the first time, the CLA status on Git command line still displays No contributor agreement when you push the code change.
Navigate to the Gerrit window, sign out, sign in again, and then push the code.
In the “Checks” section of the pull request, EasyCLA status is showing as “Expected”.
Open the pull request, and comment /easycla
in the comment section as shown in the image below. This comment runs the bot again. If the status still does not change, open a support ticket.
After signing an ICLA or verifying under a CCLA, the status does not change to “Authorized” for multiple open pull requests.
Open one pull request, and comment /easycla
in the comment section as shown in the image below. This comment runs the bot again. If the status still does not change, open a support ticket.
After hosting my project on The Linux Foundation, I can not use EasyCLA for my project.
Open https://jira.linuxfoundation.org/plugins/servlet/theme/portal/4/create/143, submit the form describing your requirements, and import your existing CLAs.
When I am trying to contribute code under a CCLA, my company is not displayed in the list.
You must create a record for your company as described here.
I have signed an ICLA, however I cannot view the signed ICLA.
Open your email, that you have provided while signing the ICLA, to check the signed ICLA that is sent from The Linux Foundation. If you have not received the email, you can open a support ticket to have it resent.
\
Ensure that your commits are linked to your GitHub account. If your commits are not linked to any GitHub user, GitHub will display the grey Octocat logo beside the commits.
Navigate to the Gerrit window, sign out, sign in again, and then push the code.
EasyCLA was previously enabled for a GitHub repository, but someone other than the project manager has subsequently disabled it.
You can also add the branch protection rule manually, as described below:
1. As the GitHub organization owner or administrator, go to the GitHub repository that you want EasyCLA to monitor.
2. Click Settings from the top menu.
3. Settings appear with Options in the left pane.
4. Click Branches under Options.
5. Select master for the Default branch. Click Edit or Add rule for Branch protection rules of your organization.
6. Select the following check boxes under Rule settings, and click Create:
Require status checks to pass before merging
Require branches to be up to date before merging
Include administrators
GitHub is set up to permit administrators and organization owners to have maximum flexibility, which includes disabling installed applications, such as EasyCLA. To avoid this, you must enable branch protection by after the GitHub organization is added to a project.
Following are the third-party services, backend components and frontend consoles used in the development of the EasyCLA tool.
Besides integration with the LFX platform and its underlying services, EasyCLA uses the following third party services:
Docusign for the CLA agreement e-sign flow
Docraptor for converting CLA templates from HTML to PDF
GitHub for GitHub PR CLA authorization checking/gating
Gerrit for CLA authorization review checking/gating
Auth0 For Single Sign On
Salesforce through the LFX Platform APIs
GitLab supports two ways of registering your EasyCLA bot with GitLab :
Integrations: Navigate to Integrations tab of Project Settings. To have your EasyCLA bot listed under Add an integration section, you must create a MR (Merge Request) to GitLab's codebase, and get that accepted. The code must be written in Ruby.
Webhook : The other way of integrating your bot with GitLab is to add a webhook which will be called on certain events that happen in GitLab Project, such as opening MR (Merge Request). The webhook must respond in certain time frame. GitLab has a Webhook API where you can interact with programmatically and add/edit/delete your webhook which can make the integration smoother from user point of view.
The EasyCLA tool has two backend components.
Python - some older APIs are implemented in python and can be found in the cla-backend directory.
GoLang - Most of the backend development is implemented in Golang, and can be found in the cla-backend-go directory. In particular, this backend contains APIs powering most of the v2 APIs which integrate with the LFX Platform (including Salesforce data), and the LFX platform permissions model.
The EasyCLA frontend consists of three independent Single Page Applications (SPAs) built with the Ionic framework:
EasyCLA Project Console for a project's director or manager (typically an LF staff member) to oversee the project's CLA setup. It is sometimes referred as the LFX Project Control Center in this documentation.
EasyCLA Contributor Console for a contributor to a project to sign an Individual CLA (ICLA), or to kick off the corporate CLA (CCLA) signature process.
EasyCLA Corporate Console for a company's CLA Manager to coordinate the corporate CLA signature process, and then to manage their company's authorized contributors.
This project’s source code is licensed under the MIT License. A copy of the license is available in LICENSE.The project includes source code from keycloak
, which is licensed under the Apache License, version 2.0 (Apache-2.0), a copy of which is available in LICENSE-keycloak.This project’s documentation is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0). A copy of the license is available in LICENSE-docs.
The following diagram illustrates EasyCLA architecture:
The following diagram illustrates the EasyCLA release process: