Content Comparison

Known Issues

In the CLA Corporate Console at organization.lfx.linuxfoundation.org, when adding an Approval Criteria or a CLA Manager, the "pop-up" window appears in the bottom left side of the screen and the user is unable to perform any action.

The CLA Corporate Console javascript is trying to get timezone prefix from the Date object. However, if the locale setting is not in English, the Date object will have timezone prefix in its local language, causing the issue. 

While the fix is being implemented for this, we ask the CLA Managers to set their browser language setting to English. This will allow the "pop-up" window to show correctly.

Installing EasyCLA on GitLab repositories

GitLab changed how they managed their authorization for the EasyCLA integration. It now requires a rotating token rather than a static long-lived token. As a result, the EasyCLA GitLab integration is experiencing token expired errors. This issue was reported and is being tracked at https://github.com/communitybridge/easycla/issues/3537

Some FAQ

Do you need an LFID account to sign the Corporate CLA?

No, only the user that will become the Initial CLA Manager will need to have a LFID account to initiate the signatory process in the Corporate CLA Console at organization.lfx.linuxfoundation.org. That user will be prompted with the question "Are you authorized to sign this CLA on your company's behalf?". Selecting "No", the Initial CLA Manager can add the Name and the Email Address of the person authorized to sign the Corporate CLA. This person will receive a DocuSign email and perform the signature without needing to log into the CLA Corporate Console. Once completed, the Initial CLA Manager will received a confirmation email. For more information, please visit: https://docs.linuxfoundation.org/lfx/easycla/v2-current/corporate-cla-managers/coordinate-signing-cla-and-become-initial-cla-manager.

Why does the Linux Foundation ask contributors to some projects to sign CLAs?

...

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 it on behalf of the company. After the Corporate CLA is signed, your email address needs to be included in a whitelist Approved List that is associated with your employer for this project. A CLA manager for your company is responsible for managing the whitelistsApproved Lists.

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.

Which Corporate CLA whitelist Approved List option has the lowest maintenance overhead?

The Domain Whitelist Approved List option requires less overhead for signatories and CLA managers because it allows entities to contribute under any email address under that domain name. When signatories and CLA managers use the Email Whitelist Approved List instead of the Domain WhitelistApproved List, they must use the tool to add an email address every time a new company contributor joins the project. Therefore, using the Domain Whitelist Approved List requires less overhead because signatories and CLA managers do not need to add and manage numerous employee email addresses.

...

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.

Why does EasyCLA redirect and update a previous 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 "/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 not 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.