Open Source Patching

Contributing to existing open source projects is encouraged! Whether you’re patching a Google project, a personal project, an external one, or forking an existing repository, this page applies to you. There are some requirements before you start patching, and guides to help you figure out the right path.

Common rules

For all patches to open source projects:

  • If patching a project on GitHub, you must register your GitHub ID at go/github first.

  • Please associate your commit with your email unless you have a history of contributing to the repo under a different email before your employment at Google. How to associate your commit with a email.

  • Optional: you may add Google LLC as a project author in the AUTHORS file. This helps provide visibility into Google/Googlers’ contributions to open source.

There is no limit on the size or complexity of a patch, but if the patch is less than or equal to 100 lines of code, refer to the Snippets policy below. Please recall that Google will claim copyright and other ownership rights over your patches.


Patches that don’t require any review!

You may submit your patch for any of the following repos without using the form at the bottom of this page. No review required! You must still follow the common rules.

NOTE: If a project below requires you to sign a Contributor License Agreement (CLA), you must still email emailremoved@ for review before patching.

  • Any project which is:
    • A public repo on GitHub
    • AND is under the Apache 2, Artistic license, Boost Software License, BSD*, CC-BY, CC-BY-SA, EPL, GPL*, ISC, LGPL*, MIT, MPL, MS-PL, OFL, or Zlib License.
    • AND does not require you to sign a CLA that is not found on the pre-approved CLA list.
    • AND is not on the list below of projects that require SVP approval.
  • Any repo for which you’ve already been given blanket approval from OSPO or used the approval form once
  • Any Google-maintained open source project like Chromium, Android, Go, etc
  • To support COVID-19 response efforts, exceptions have been made for some projects that would not normally be okay to patch (because of their license, for example):
    • Nextstrain projects
    • Medic Mobile projects

These exceptions to the review requirement exist regardless of the length of the patch.

Projects that require SVP approval

Patches to the following projects are not allowed without SVP approval. Please obtain SVP approval by email and forward it to emailremoved@. You may also email emailremoved@ with any questions.

List of projects removed.

Forbidden patches

Our general philosophy is that we do not allow patches to projects that Google cannot use, either because of the terms of the license or Google policy. For example, we can’t use software that restricts commercial use, so we don’t contribute to those projects. In some cases, you may be able to contribute to these projects via IARC.

You can’t patch projects with any of the following licenses:

  • No License
  • AGPL (except those with special exceptions)
  • Public domain dedications (including CC0 and Unlicense)
    • Exceptions: United States government projects; BSD0.
  • CC BY-NC-*
  • Hippocratic License
  • Private repositories (unless under a written agreement between Google and a third party)

See go/whatisalicense for more information on licenses.

Do not upload your Google-specific dotfiles to GitHub or other external source control systems. This is a classic way to leak confidential information. See go/eng-resources/dotfiles for techniques to ensure you don’t leak information in your dotfiles.

Use the form for all other patches, but only once per repo.

IMPORTANT: You must go through this process (and submit the form if necessary) before sharing a patch externally (i.e. pushing it to GitHub or another non-Google repository or emailing it outside the company.)

You only need to go through this process once per repository. But remember that the common rules apply to all patches.


IMPORTANT: You can’t sign Contributor License Agreements (CLAs) for any companies or projects not listed below. If you want to sign an unlisted CLA, email it to emailremoved@ for review.

Google already has CLAs on file with:

List of on-file CLAs removed.

You may sign the Pre-Approved Individual CLAs listed below:

List of OK to sign individual CLAs removed.

All published source files should have some form of license header with at least one copyright notice.

When Googlers are publishing snippets, this can be a simple SPDX header. For larger publications, files should have complete license headers.

When contributing to third-party projects, Googlers do not need to add Google’s copyright notice when authoring patches to existing files. Googlers should add Google’s copyright notice (or a “The Project Authors” style copyright notice) to new files being added to the library if permitted by the project maintainers.

Any file that has already been published with a copyright notice attached to it must include that copyright notice when the file, or any portion thereof, is added to any project.

Identifying license type

To figure out what license a repository uses, GitHub may help you out. Under the description of the repository, GitHub will display the type of license if it is able to identify it.

License identification

If it is unable to identify the license, the README may name it for you or you can directly examine the LICENSE file to determine the license. SPDX can help you figure out the exact type of license.

Forking on GitHub

There are two primary reasons to fork a repository on GitHub:

  • To contribute to the upstream repository
  • To create a permanent fork in order to take the project in a different direction, and not contribute upstream

Forking to contribute

Forking a repository into your personal account (e.g. youruser/reponame) is part of the standard GitHub contribution flow. This is expected and perfectly fine; just make sure you follow the rules on this page when pushing any changes to your forked repository. Unless you plan to continue contributing to the project over time, we encourage you to remove the fork after your change has been merged upstream.

Permanent forks

If you are intending to fork a repo and NOT send the changes upstream (for example, you want to make a custom version of the project, or take it in a different direction), then you must proceed through go/releasing.

Things which aren’t patches & don’t require review

<= 100 lines of code

In addition to patches to existing open source projects, you may use the patching form to publish self contained code or snippets if ALL of the following are true:

  • Posted to a presentation, GitHub gist, pastebin, mailing list, web forum, chat room (e.g. IRC, Slack), etc.
  • Is a self-contained unit. (e.g. not split into multiple attachments.)
  • NOT more than 100 lines of code.
  • NOT otherwise checked into a repository as the sharing mechanism.

If any of the above are not satisfied, you must follow go/releasing.

To ensure that snippets are properly licensed, you must add the following header:

Copyright 2020 Google LLC.
SPDX-License-Identifier: Apache-2.0

These do not require human review, so you can check the instant approval box on the form.

Filing bugs

You may file a bug without requesting human review. The patching form is not required.

However, any content being added to a repository, whether it is code or simply plain text, is a patch that is governed by this process.

Administering open source repositories

If you are an administrator of an open source repository, you may continue to do administrative work such as accept pull requests, respond to comments, open and close issues, and other admin work without using this form. This includes publishing new releases of existing projects.

Debian Packages

You do not need approval to package up existing open source projects for Debian, or to maintain an existing configuration for Debian, or to otherwise administer a Debian package for an open source project.

However, if you wish to substantively modify or substantively contribute to an underlying open source project, please do so under the regular go/patching guidance.

Stack Overflow

You can answer questions on Stack Overflow without using this form, but you still must add the appropriate headers to your code snippets:

Copyright 2020 Google LLC.
SPDX-License-Identifier: Apache-2.0

Submit your patch

Include the first 150 lines of the patch. This can be generated using:

git format-patch -n HEAD~1 --stdout | head -n 150

or a similar command, and should include the author line containing your email.

Embedded form removed. It asks for a pointer to the code, the license, and the first 150 lines of the patch.

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.