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/
Discussion Group: emailremoved@
Why do we even have a CLA?
Our CLA allows open source projects adminstered 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.
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.
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.
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:
- For Gerrit: go/gob/team/signcla
- For GitHub: go/cla/github
You can manually lookup CLAs by email or GitHub username at http://linkremoved/.
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.
If you’ve corrected whatever CLA issues exist and just want to force SignCLA to
rescan a pull request, 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
If you 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.
You can check the status of a GitHub PR and trigger a rescan at go/prinfo.
Alternatively, as mentioned above, you can add a comment
@googlebot rescan to
trigger a rescan.
There are a few cases that may result in a contributor’s CLA not being found.
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. If you think it’s taking longer than it should, email emailremoved@ to check the status.
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
.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:
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.
GitHub pull request sender is not the commit author.
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.
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
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 should be
@google.com unless there is a good reason.
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.
You can check for GitHub service issues at https://www.githubstatus.com/.
Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.