Contributing to existing open source projects is encouraged! Whether you're patching a Google project, a side project, an external project, 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.
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 google.com email unless:
- You have a history of contributing to the repo under a different email before your employment at Google
- The patch is submitted via mailing list and submitting with google.com is non-trival (i.e. sending patches to your corp account to forward to a mailing list). How to associate your commit with a google.com email.
Stuff That Does Not Require Review
Patches that don't require any review!
You may submit your patch for any of the following repos. 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 email emailremoved@ for review before patching.
Any project which is:
A publicly available and discoverable repository
- This includes GitHub, GitLab, BitBucket, and other publicly available source code hosts that do not require authentication (e.g., git.kernel.org).
AND is NOT licensed under a license listed in the Forbidden Licenses section below.
AND is licensed under a go/thirdpartylicenses#notice, go/thirdpartylicenses#reciprocal, or go/thirdpartylicenses#restricted license.
- See Identifying license type for help identifying a repository's license type.
- Email emailremoved@ for guidance on non-standard open source licenses.
AND is not on the list of projects that require SVP approval.
AND does not require you to sign a CLA that is not found on the pre-approved CLA list.
Any Google-maintained open source project (e.g., Chromium, Android, Go).
NOTE: Googlers are permitted to patch dual-licensed open source projects as long as all of the licenses that the project is made available under are individually permitted.
<= 100 lines of code or Stack Overflow
You can publish small snippets, and answer questions on Stack Overflow, but please include the following license header.
IMPORTANT: You must add the following header:
Copyright 2022 Google LLC. SPDX-License-Identifier: Apache-2.0
You can file bugs against projects.
Administering open source repositories
You may do administrative work on projects such as accept pull requests, respond to comments, open and close issues, and other admin work, including publishing new releases of existing projects.
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.
Stuff You Either Can't Do, or Which Requires Review
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.
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
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.
CLAs, Licensing, and Specialty Policies
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.
License Headers and Copyright Notices
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 try the following:
- GitHub may help you. Under the description of the repository, GitHub will display the type of license if it is able to identify it.
Use the license classifier CLI to identify the license.
The README may name the license 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.
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.
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.