opensource.google.com

Menu

Docs

Contributor License Agreements

go/cla

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 Google’s open source projects 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

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.

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 email emailremoved@.

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

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. But if you are ever uncertain, just email emailremoved@ with a link to the pull request. We’re happy to help, and we’d love to identify any edge cases that aren’t being handled properly.

Troubleshooting CLAs

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 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. This is true even if they have registered their GitHub account at go/github. 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.

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.

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

Robot accounts

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 whitelisted. Email emailremoved@ with the email address the bot is using, requesting that it be added to emailremoved@.

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.