(This is part of the process for releasing Google-owned code as open source. There are different processes for patches and IARC projects.)
Contributions from Googlers
When Googlers outside your team wish to patch your project, please have them follow the go/patching process. There is no need for a CLA or for changes to the copyright information as with non-Google contributions.
You and your team may continue working on the project without OSPO's review, but please contact emailremoved@ if you are making significant changes to the project's scope.
Contributions from non-Googlers
After releasing, you may wish to accept patches from non-Googlers. This is encouraged! Running a successful open source project is a broad enough topic to fill a book. Lucky for us, Karl Fogel has written that book and released it under a Creative Commons license. You can find the free eBook at http://producingoss.com/.
First, decide upon and communicate how you'll manage modifications to the codebase. Your workflow represents a barrier to entry for new contributors, so lower it as much as possible. A good rule of thumb is that your workflow should be able to scale to at least 20x your initial number of contributors. Appoint at least two team members to ensure the workflow is adhered to.
Next, here's what you need to do to accept patches from non-Googlers:
Contribution License Agreements (CLAs)
Before accepting patches from non-Googlers, you must ensure the contributor has signed a Contributor License Agreement (CLA). See go/cla#verify for instructions.
This is not required for projects which have been approved by go/iarc to be released into personal accounts.
Copyright info
When a project is initially released, a "Copyright Google LLC" notice is required in the headers of all source files. New files added to a Google-maintained open source project should also include a license header with a "Google LLC" copyright notice, whether the file is created by a Googler or Non-Googler.
From a legal perspective, leaving "Copyright Google LLC" in the headers does not affect the contributors' rights. Most contributors don't care about this, especially for small patches.
However for projects that accept a great deal of external code (such as Chromium), you may wish to optionally update the copyright statements in your source code to "Copyright 2014 The [Project] Authors" to acknowledge the community's efforts. You may do this if you create and maintain AUTHORS and CONTRIBUTORS files. This requires ongoing maintenance but builds goodwill among your contributors.
Patched code is third_party code
Once external patches to a project have been accepted, that code is no longer exclusively copyrighted by Google. That means that, like any other open source software we use, it is subject to our go/thirdparty policies and must be moved to a third_party directory. This means //third_party if stored in Piper.
Pre-Google Personal Projects
If you still maintain a project you started before you worked at Google, you can accept patches however you would like. No Google CLA is required. (We do encourage you to follow our best practices and standards, but you don't have to.)
Patches from Googlers may be accepted under the terms of go/patching.
Post-Google Side Projects
If you leave Google, you have two options for how to continue working on any side project you released while here.
If the repo is in a Google-owned org, you can simply fork the project to a new repo.
If the repo is not in a Google-owned org, you can leave the repo where it is and remove the CLA bot hook and any suggestion that the project continues to be maintained by Google. Code you authored during your employment period remains copyright Google, and those notices should not be removed.
If you released packages for your side project on Maven/Cargo/NPM/etc., package releasing rights go with you.
In some cases, we will approve moving repositories from a Google-owned GitHub org to a personal org. Raise a bug here (before you depart Google) to inquire.