Contributor License Agreements

Whenever a non-Googler wants to submit a patch to a Google open source project, they must first sign a Contributor License Agreement (CLA). This allows the contributor to retain their ownership in the code submitted while granting Google the necessary legal rights to use that contribution. The CLA only needs to be signed once and it covers all Google projects.

NOTE: Looking for information about signing a CLA yourself so you can contribute code to a non-Google project? See go/patching instead.

External Website (where contributors sign and manage their CLAs): https://cla.developers.google.com/

Internal Website (where Googlers can lookup CLAs): http://linkremoved/

CLA Change/Information Requests: http://linkremoved/

Discussion Group: emailremoved@

Why do we even have a CLA?

Our CLA allows open source projects administered by Google to safely accept code and documentation from external contributors. But why is our CLA written the way it is? Who can sign it and why? How do we make sure external commits are safe to use in a scalable way?

These and other frequent questions about CLAs are answered at go/cla-policy.

What's in the CLA?

Our CLAs are based on the Apache Software Foundation's CLAs.

Signing a CLA

Googlers, Interns, TVCs

Googlers, Interns, and TVCs should not directly sign a CLA.

  • Googlers (FTEs) and Interns must register their account at go/github-docs#accounts.
  • TVCs have a different process: go/opensource/github/tvc.

External Contributors

Contributors can manage their agreements and sign new ones at https://cla.developers.google.com/. Make sure that you direct users there in your CONTRIBUTING file. Contributors must sign in with a Google account to sign the CLA or manage their CLA agreements.

There are actually two versions of the Google CLA, and which version needs to be signed depends on who owns the contribution being made. If the individual owns the contribution themselves, they can sign the Individual CLA. If the contribution is owned by their employer, they need a Corporate CLA. It's up to the contributor to know whether their work is owned by their employer or not.

Individual CLAs are simple click-through agreements that are accepted immediately. As soon as a contributor submits the form, you should be able to accept their contributions. Corporate CLAs, on the other hand, must be signed by someone with signing authority for the corporation (typically a director or higher, or a lawyer), and must also be reviewed by someone at Google. Therefore, corporate CLAs tend to take a few days to process before you can begin accepting contributions. Accepted corporate agreements can be seen at http://linkremoved/.

The Corporate CLA is only signed once per corporation. As part of signing the CLA, they designate a Google Group that identifies who at their company is authorized to contribute to Google projects. If someone is trying to contribute to your project, but they are not in their company's authorized contributor group, they'll need to contact whoever administers the group for their company. If you need help identifying who that is, just file a request.

Verifying CLAs

It is the responsibility of the project owner to ensure that contributors have signed the CLA before accepting their patches. Fortunately, this can be an automated process for most all projects. If your project is not already doing automated CLA checks, see the following instructions to set it up:

You can manually lookup CLAs by email or GitHub username at http://linkremoved/.

If you've corrected whatever CLA issues exist, you need to trigger a rescan for the new status to be reflected on GitHub.

  • If your repository is included in the GitHub checks rollout, you can trigger a rescan by opening the check details page, and "Re-run" on the left side. If you don't have access to this button, you can also trigger a rescan here.

  • If your repo is not in the rollout, you can do so by leaving a comment that includes @googlebot. The rest of the comment doesn't really matter as long as it includes that string, though we typically recommend something like @googlebot rescan.

Particularly for projects on GitHub, there are times when we're not able to automatically verify CLAs (see Troubleshooting CLAs). At the end of the day, we always rely on the project owners to verify the CLA status, whether that means simply looking for the commit status set by SignCLA, or by manually checking the CLA themselves. It's okay to accept a contribution that you are certain is covered by a CLA, even if the automatic verification failed for some reason.

To manually verify a pull request's CLA status, you must check that the pull request opener, as well as all authors and co-authors, are covered under a CLA. Committers do not need to be covered under a CLA as long as they are not also a PR opener, author, or co-author. You may look up each user's GitHub login and associated email addresses in http://linkremoved/ to see if they are covered.

  • If your repository is included in the GitHub checks rollout, please visit the Googlers link near the bottom of the check run details, or enter your pull request here. The link will take you to a page where you can request an override.

  • If your repository is not included in the GitHub checks rollout, you must first have added the cla: yes issue label to your repo. You can manually set this label to override the CLA status set by SignCLA. Whenever you do this, also leave a comment explaining why the CLAs are okay. For example, whether you manually verified the CLAs, or if this was really just a merge commit and all of the other commits in question had already been previously reviewed. This action can only be performed by Googlers who have registered their GitHub account at go/github.

If you are ever uncertain, just file an issue with a link to the pull request. We're happy to help, and we love to identify edge cases that aren't being handled properly.

Troubleshooting CLAs

You can check the status of a GitHub PR and trigger a rescan at go/prinfo.

NOTE: In order for the SignCLA bot to apply the cla: yes and cla: no labels to GitHub PRs, you must first add them to your repo. The label names must be typed exactly as shown above (note the space after cla:).

There are a few cases that may result in a contributor's CLA not being found.

Googlers

Current Googlers and interns do not need to sign a CLA. However, to be recognized as a Googler, they must have registered their GitHub account at go/github or use their @google.com email address in git commits. If they are contributing to a project on GitHub, they must also add this address to their GitHub account. Some teams have alternate work emails like @golang.org and @chromium.org; those are generally fine to use, as specific provision has been made for them. However, that address should still be added to the Googler's GitHub account.

See additional information and tips in the Wrong Email question below.

Ensure corporate CLA has been accepted

If the contributor is covered by a corporate CLA, make sure that the corporation is listed at http://linkremoved/. If it's not, it simply may not have been processed yet, which typically takes a few days.

After the request is entered in the system, the CLA is sent via DocuSign to an authorized signer at the company. Once that's signed, it's sent back to Google for validation and cross-signing.

If you've verified that the corporate CLA has been accepted, and that they are using the correct email address, then the problem may be that they have not been added as an authorized contributor for their company. The contributor will need to contact their company's point of contact to be added. File a request and we'll help identify who that is.

Using the wrong email address

One of the most common problems is that the git author email in the commit is not an email address associated with a CLA. The solution is to change the git author email to be an address covered by the CLA. That email should also be added to their GitHub account; it doesn't need to be the primary email, but it should be on the account. For contributors covered by a corporate CLA, this should typically be their work email address, or whatever was added to the corporate CLA's authorized contributor group.

TIP: If you're not sure what email address was used to make a commit, you can add .patch to many GitHub URLs to see the raw patch which includes the committer's email address. For example, to see the email address used in the pull request grpc/grpc#12, just append .patch to the URL: https://github.com/grpc/grpc/pull/12.patch. The same can be done for individual commit URLs: https://github.com/grpc/grpc/commit/3acf05a.patch.

NOTE: If you make edits through the GitHub website, they may receive your GitHub account's default email address. In some situations (i.e. when you end up as a co-author of a commit), SignCLA may not be able to determine who you are. In those cases, it may be appropriate for the approver to manually override the CLA.

GitHub username has changed

If the user has changed their GitHub username since signing the CLA, they won't be able to be looked up by GitHub username. Encourage the user to verify and possibly update their username and email addresses on https://cla.developers.google.com.

Most of the time, a contributor opens a pull request containing their own commits. However that's not always true, most often seen with corporate contributors or Googlers syncing a series of commits from an internal repository. We are able to handle this much of the time, but in some cases, these pull requests will be flagged as needing author consent. In these (relatively rare) cases, the comments from googlebot should inform you as to what is needed, but SignCLA will never update the status of the commit to "OK".

Found a bug with CLA Bot?

If you find a bug in the CLA Bot, you can raise an issue on issuetracker with component Open Source > Compliance > SignCLA.

Robots

For the purpose of our documentation, robots means any automation. It could be a GitHub Action, webhook triggered event, or external program that requires API keys.

Internal bots

If you have an account that is making automated commits, those commits will likely get flagged by SignCLA as not being covered by a CLA. As long as this bot is 100% Google-controlled and it is not committing unreviewed code authored by someone outside of Google, it can be allowlisted. Fill out go/signcla-robot-account to have the email address allowlisted.

NOTE: Robot accounts interfacing with GitHub should be @google.com unless there is a good reason. Robots interfacing with Gerrit can be MDB identities.

External bots

We can't assume that just because a robot is the author of a PR or change that it doesn't need a CLA.

Only human creative output is eligible for copyright protection. That means any changes that have been purely authored by a machine or a Celebes crested macaque entail no copyrighted expression that we need to worry about.

A bot committing code that a human has created (i.e. inserting boilerplate code) would something that we need a CLA for. A bot that is writing novel code or applying purely functional fixes is not something we're concerned about.

We will sometimes approve external bots to bypass the CLA check if we're sure they're applying purely functional fixes. i.e. code re-formatting, or simple version number bumps. (They must also adhere to security guidance regarding access limits, etc.) File a bug with your request.

GitHub Actions

We will not grant the github-actions account CLA permission.

If you have a GitHub Action (internal or external) that needs to author commits, create a custom account or GitHub App and register it following the internal bots section above.

GitHub Status

You can check for GitHub service issues at https://www.githubstatus.com/.