Known Issues

The following issues are known to be present in the v2.0.0 release of EasyCLA:

• Auto-Branch Protection

• Organization Association

Auto-Branch Protection

Auto-Branch Protection only protects a repo's default git branch. Non-default branches are not currently auto-configured for EasyCLA protection. Currently, GitHub/GitLab organization owners must manually set up branch protection rules for non-default branches.

Organization Association

Currently, user roles in EasyCLA can only be associated with a single company or organization at a time.

Releases

Release notes for the EasyCLA backend and APIs can be found at https://github.com/communitybridge/easycla/releases.

Release notes for the EasyCLA Contributor Console can be found at https://github.com/communitybridge/easycla-contributor-console/releases

EasyCLA V2.0 supports projects with a parent-child model of any number of hierarchy levels without any limit in the depth of the hierarchy. The following is an example:

• Parent Project

  • Child Project

    • Grand Child Project

      • Great Grand Child Project

        • Great-Great Grand Child Project

        ….

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.

How can I view my ICLA document after I sign it?

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.

Which CCLA approval criteria option has the lowest maintenance overhead?

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.

Where do I view my individual CLA (ICLA) after I sign the ICLA?

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.

Why is my EasyCLA status not updated even after I complete the process.

(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,.org,.cc.

This document provides a detail description of LFX EasyCLA application, and how to use the application based on your access role.

To get started with the application, see the Getting Started page, and for any troubleshooting related information, see the Troubleshooting page.

EasyCLA Project Requirements

To utilize EasyCLA, a project must adhere to the following criteria:

• Linux Foundation Hosting: EasyCLA is tailored exclusively for projects under the Linux Foundation umbrella. Projects or repositories hosted elsewhere are not supported.

• Supported Platforms: Projects must be hosted on GitHub, Gerrit, or GitLab.

• Gerrit Requirements: The Gerrit instance must be hosted by the Linux Foundation for projects using Gerrit.

• Repository Settings: Repository administrators are required to enable Branch Restrictions and Branch Protection on GitHub or GitLab. These settings must enforce required status checks on branches, irrespective of the organization member's role.

Accessing EasyCLA

CLA Managers seeking access to EasyCLA must have an LF Single Sign-On (SSO) account. To create an LF SSO account, visit .

For a project to use EasyCLA, it must meet the following requirements:

Problem:

EasyCLA was previously enabled for a GitHub repository, but someone other than the project manager has subsequently disabled it.

Solution:

Enable Branch Protection

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.

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

What Role Are You?

How you interact with EasyCLA depends on your role. EasyCLA supports the following roles in its workflow:

• Project Manager

• Contributor

• CLA Manager

• CLA Signatory

When a Contributor License Agreement (CCLA) is first implemented, the roles of Contributor, CLA Manager, and CLA Signatory may be held by the same individual or different people. Each contributing company decides which employees will fill these roles.

Understanding these roles is essential to determine who should be designated for each position. Review the following roles to facilitate discussions with your company's management and legal counsel.

Project Manager

A Project Manager is typically a project administrator or maintainer 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.

Contributor

A contributor is typically a developer contributing code to a GitHub or Gerrit project set up on EasyCLA.

The specific workflow a contributor follows depends on two factors:

• Whether the project is hosted on GitHub or Gerrit.

• Whether they are contributing on their behalf or behalf of a company (usually their employer).

After submitting a contribution to GitHub or Gerrit, a contributor who has not yet been authorized under a signed CLA will initially encounter a block. To resolve this, they will use the EasyCLA Contributor Console to either:

• Sign an Individual Contributor License Agreement (ICLA) if contributing on their behalf.

• Identify the company on whose behalf they are contributing, allowing them to either be authorized under a signed Corporate Contributor License Agreement (CCLA) or initiate the CCLA signing process.

CLA Manager

A CLA manager is an individual authorized by a company to manage the list of authorized contributors and other CLA managers under that company's Corporate Contributor License Agreement (CCLA) for a project.

A CLA Manager uses the EasyCLA Corporate Console to:

• Add Contributors to Approved List

• Add or Delete CLA Managers

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, the specified Initial CLA Manager can use the EasyCLA Corporate Console to manage the list of authorized contributors. They can also designate additional CLA managers.

CLA Signatory

A CLA signatory is an individual authorized by their company to sign a Corporate Contributor License Agreement (CCLA) on its behalf.

If a company's CLA signatory is the same as their initial CLA manager, 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, 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.

A Project Manager can sign in to the EasyCLA Project Control Center to perform the CLA set-up and management tasks for projects that you manage.

To Sign in:

1. Go to https://projectadmin.lfx.linuxfoundation.org/.

2. Click Sign in with SSO.

3. Enter your credentials as the Project Manager and click Sign In.

4. Click a project to view more about the project or search for a project from the left navigation pane. For details, see View Project CLA Details.

Project Managers are the project administrators or maintainers of the project. They set up a project on EasyCLA, and manage configuration details, such as the GitHub organization or Gerrit instance or GitLab groups, and associated repositories. The Project Manager uses the Project Control Center for these actions.

As a Project Manager, you can perform the following activities:

4. Add and manage or or

Additionally, you can view and manage CLA details, GitHub, Gerrit, and GitLab organizations and repositories:

For EasyCLA integrated GitHub organizations and repositories, EasyCLA sends email notification to project managers regarding any changes to the repositories. EasyCLA takes the following actions for different events:

• Repository Renamed: EasyCLA updates GitHub repository table entry to match the new GitHub repository name, and notifies the project manager.

• Repository Archived: EasyCLA takes no action, however notifies the project manager that the repository is archived.

• Repository Deleted: EasyCLA disables the repository, and notifies the project manager.

• Repository Moved to a Different Organization:

  • If an EasyCLA enabled repository is moved from one organization to another within the same CLA Group, EasyCLA simply notifies the project manager about the action.

  • If a repository is moved from one organization to another where EasyCLA is not configured or the CLA Group is different, EasyCLA disables the repository, and notifies the project manager.

Project managers can edit and update CLA templates to display the correct email address of the person managing the project so that contributors can submit signed CLAs to the mentioned email addresses if they want to sign them manually, rather than via DocuSign.

1. Sign in to the .

2. Under My Projects, click a project, and scroll down to Tools Status section, and click EasyCLA.

3. Under CLA Groups, select a CLA group for which you want to update templates.

4. Navigate to TEMPLATES tab, and click Edit Template.

5. Provide email address of the person managing the project in the respective field, and click Update Template.

Note: This email address is displayed in the CLA templates as the email address for contributors to submit signed CLAs if they want to sign them manually, rather than via DocuSign.

6. Click Update Template.

If you are having issues with EasyCLA, go to , and file a ticket.

The following sections help you troubleshoot common problems that you might encounter when using the EasyCLA tool.

GitHub pull request is not passing

Problem:

I have an agreement on file, but EasyCLA does not authorize me and displays "Missing ID on Commit".

Solution:

• 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.

(GitHub) Unable to contribute to EasyCLA-enforced repositories

Problem:

Contributors' commits are linked to their GitHub accounts, however, they are still facing issues contributing to EasyCLA-enforced repositories.

Solution:

Or

(Gerrit) Unable to contribute to EasyCLA-enforced repositories

Problem:

Contributor's commits are linked to Gerrit account, however, they are still having trouble contributing to EasyCLA-enforced repositories.

Solution:

Ensure that your Gerrit email address is added to the approved list, and you must log in to the Gerrit instance of your project using the same email address that is added to the approved list.

(GitHub) Individual Contributor's EasyCLA status is not updated

Problem:

After a Contributor has signed an ICLA, EasyCLA status is not updated on the contributor console.

Solution:

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.

(Gerrit) Individual Contributor's EasyCLA status is not updated

Problem:

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.

Solution:

(GitHub) Corporate Contributor's EasyCLA status is not updated

Problem:

For a CCLA, after a Contributor has been added to the approved list for the first time, the CLA status still displays Not Covered.

Solution:

(Gerrit) Corporate Contributor's EasyCLA status is not updated

Problem:

For a CCLA, after a contributor has been added to the approved list for the first time, the CLA status on the Git command line still displays No contributor agreement when you push the code change.

Solution:

Navigate to the Gerrit window, sign out, sign in again, and then push the code.

EasyCLA status displays "Expected"​ in the "Checks" section of the Pull Request

Problem:

In the “Checks” section of the pull request, EasyCLA status is showing as “Expected”.

Solution:

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.

EasyCLA status does not change to "Authorized" for multiple open pull requests after signing ICLA and/or CCLA

Problem:

After signing an ICLA or verifying under a CCLA, the status does not change to “Authorized” for multiple open pull requests.

Solution:

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.

I cannot use EasyCLA for my Linux Foundation-hosted project

Problem:

After hosting my project on The Linux Foundation, I can not use EasyCLA for my project.

Solution:

My company is not displayed in the list when I am trying to contribute code under a corporate CLA (CCLA)

Problem:

When I am trying to contribute code under a CCLA, my company is not displayed in the list.

Solution:

I cannot view my individual CLA (ICLA) after I sign it

Problem:

I have signed an ICLA; however, I cannot view the signed ICLA.

Solution:

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.

\

The Project Manager can add new projects to a CLA group or remove projects from a CLA group.

1. Sign in to the .

2. Under My Projects, click a project.

3. Scroll down to Tools Status section, and click EasyCLA.

4. Under CLA Groups, select a CLA group for which you want to manage projects.

5. Select or deselect the check box next to a project to add or remove the project from the CLA group.

6. Click Update CLA Group.

Note: A project's check box is selected and unavailable under a CLA group if the project has already been added to another CLA group.