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 for complete instructions.
When a project is initially released, a “Copyright Google” notice is required in the headers for all source files. However once you begin accepting external contributions, “Copyright Google” becomes technically inaccurate: the CLA does not transfer copyright ownership. That means the copyright of the collective work is shared among the contributors.
From a legal perspective, leaving “Copyright Google” 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 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 Personal Projects
If you leave Google, you have two options for how to continue working on any personal project you released while here.
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.
In some cases, we will approve moving repositories from a Google-owned GitHub org to a personal org. Email emailremoved@ (before you depart Google) to inquire.
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.