Third-Party

//third_party is the location in google3 where we check in all code (and data) that may not be 100% owned by Google. This includes any artifacts originating outside the company, code that Google has open-sourced, as well as code that will be open-sourced. (Its full name is //piper/.../third_party.)

IMPORTANT: All third party code must have a license.

NOTE: To make terminology simple, we'll use the word "code" below. However, process wise, it applies equally well to third-party binaries and data that need to be checked in.

What and why?

Using third-party code saves time and is consistent with our values. To use any third-party code, we import it and place its source into //third_party, which is a special repository designed specifically to house all open source code used by //piper/.../google3 projects at Google. Placing all third-party code into the same repository allows us to easily find all uses of third-party code by a project, and thus to comply with any license requirements the third-party code has.

All non-Google or open source code and data goes into //third_party

The //third_party/ subdirectory is the master directory for all code that is not 100% owned by Google. All third-party code, whether received under an open source or proprietary license, is kept in third_party.

Google-owned open source projects must be moved to third_party prior to being released under an open source license, even if Google owns 100% of the code, because the projects are expected to receive external contributions.

Google owned means code Google owns the copyright to. This means:

  • Code contributed to Google under a Google Contributor Agreement is not Google-owned, as that agreement does not assign copyright.

  • Code, tools, libraries, or protocols that are open source, free software, or under proprietary licenses must be in //third_party.

    WARNING: Please keep in mind that some code is only available under licenses that make it unsuitable for use at Google. Such code cannot be used at Google or checked into //third_party.

  • A library you wrote for your Ph.D. thesis, or code you wrote at your last job, or code you found on StackOverflow, or code you found in a textbook (it can have surprising conditions!), all need to be in //third_party.

  • Data other than source code, including precompiled binaries and libraries, WSDL, XML, XSD, and anything else that you might not consider "code" falls under this restriction. If it's going into source control, and Google doesn't own the copyright, it needs to follow this policy. In the remainder of this document, when we refer to "code," assume we are also talking about whatever kind of data you were thinking about.

  • Third-party Apps Script code does not need to live in any special location. Apps Script is not distributed outside the company and not part of a normal code storage system, so there is very little risk of it infecting Google's products. If you are ever handling Apps Script that is going to be distributed outside the company, please reach out to emailremoved@ to discuss your plan.

  • Google modifications of third-party code go into //third_party.

If you think these situations don't apply to you, please email emailremoved@.

IMPORTANT: These rules also apply to code in //experimental — you may not check in code authored outside Google into //experimental.

//third_party makes it easy to examine all non-Google code

We respect other people's rights, both in letter and spirit. When we ship a new product, we need to examine non-Google code to make sure we're complying with the authors' licenses.

It's also useful for determining how we treat the code. Tools we run to enforce Google-style (i.e., code formatters) should ignore non-Google code. When there's a security warning about non-Google code, we want to scan all non-Google code to find problems.

All these are easier when non-Google code is in one place instead of spread throughout the codebase. Hence, //third_party. //third_party also makes life easier for OSPO, which means we have more time to help you.

Project-Specific Policies

The policies and procedures documented here apply to all projects that live in google3. There are project-specific policies for:

  • Third-party libraries outside of google3
  • Android
  • Chromium
  • Fuchsia
  • Kotlin
  • Nest
  • Pixel
  • Waymo

Hardware IPs

Hardware development which involves third-party RTL, source, schematics, or other files, should generally follow go/thirdparty. There are some exceptions allowed to facilitate existing hardware design processes go/thirdparty/hardware.

packages

If you need a package with a third_party prefix, follow go/packageacl to create a CL adding your acl.textproto to the package_acls/third_party directory. For new files, send to emailremoved@ for initial review.