//third_party Owners' and Users' Responsibilities

//third_party is a shared codebase. This means that we expect folks to work together in maintaining the health of the repository. As such, there are certain rules that we expect you to follow.

Teams that do not want any of these responsibilities should avoid using open source code at Google. If you have any questions or concerns about these policies, please contact emailremoved@.

//third_party owner

Do not expect to check in open source code at Google and never have to touch it or maintain it. Do not expect to completely control the destiny of various libraries in //third_party, even if you checked it in. They are shared resources for all of Google.

As an owner, these are your responsibilities:

  1. Follow Security Policy: You must follow security policy, especially the Non-Google Software Installation Guidelines.

  2. Contact the Information Security Engineering (ISE) Team: You need to ping emailremoved@ if you have any questions or concerns about the security of your package, or you mention it in a launch security review.

  3. Monitor Vulnerabilities: You need to monitor upstream source code for security vulnerabilities. For example, by reading security announcement mailing lists or providing necessary metadata for automated vulnerability monitoring where available.

  4. Patch Vulnerabilities: You need to patch vulnerabilities in //third_party in response to security notifications in a timely manner.

  5. Maintain Library: You must keep up with supported versions so that your library is not unmaintained by upstream. We expect libraries to be regularly upgraded when necessary to keep within whatever the support horizon of upstream is. Unmaintained or unsupported versions of libraries are not acceptable in //third_party except by special exception.

  6. Review & accept maintenance changes: You must be ready to accept local changes that are approved through the LSC process, as they are crucial to moving google3 forward and keeping it secure. It is your responsibility to respond to such approved LSC reviews within 5 business days. You cannot put additional burden on LSC authors that are outside the google3 reviewer policy for LSC changes. For example, if the library has an external source of truth, it is your responsibility to upstream these changes if you do not want to maintain a local fork.

    For the majority of third-party projects this will be limited to:

    • language related changes (e.g. making code compile after compiler changes)
    • security related changes (e.g. global fixes to known security problems)
    • build system related changes (e.g. adaption of BUILD files related to changes in build rules)

  7. Inter-Team Cooperation: You need to work with other teams to upgrade when you or other teams need newer versions of libraries. This is true even if that upgrade provides you or your team no personal value.

  8. Staying informed: You're responsible for staying up to date on changes to third-party policies. In some cases, policy changes will not require package updates. However, on the occasions where they do, you will be responsible for making the necessary updates.

  9. Stepping Down: If you no longer wish to be an owner (e.g. switching teams, not enough time for maintenance, etc.), it is your responsibility to hand-off ownership to someone else. If you cannot find a replacement, the library MUST be deleted from third party.

//third_party user

The line between being a third party user and an owner is intentionally thin. If you rely on third party software, you may be asked to step up and help maintain it.

In particular, teams who use third party software are expected to have to spend time occasionally upgrading their code base to work with newer versions of third party libraries. This is a non-negotiable part of the contract of using open source code at Google.

What does this mean?

  • Teams should have tests that visibly break for Presubmit Global Presubmit (go/tgp) when their code base is incompatible with incoming updates to third party software. If an upgrade breaks your project, but does not break Presubmit Global Presubmit, it is unlikely that the changelist will be rolled back.

  • Even if tests do visibly break when an incoming update to third party software is tested, users are responsible for fixing their projects in a timely manner. When practical, third party updaters/owners are encouraged to help. The default position is that it should be possible to submit working third party upgrades with 30 days notice.

    If you need more time than that, or the upgrade causes substantial toil for users, you will need a temporary exception from the One Version Rule, allowing you to provide the new and old versions in //third_party/, giving users more time to upgrade.

Enforcement

Packages must conform to the policies posted on go/thirdparty, including this page. Most package fixes will be handled via a bug, but in some severe cases, for example when licensing issues are involved, the first step may be a CL to immediately limit the visibility of or delete the package. The response will be informed by the severity of the risk the package presents. //third_party is a shared resource, so regardless of the severity, bugs are expected to be fixed or an exception obtained within a 2 month timeframe.

If there is no owner for the package, the third party compliance team may reach out to the owners of any depending packages to notify them and give them the option to delete their calling code, take ownership of the package, migrate to an alternative package, or allow their package to be broken by deletion of the third party code.

If your package is out of compliance, you can ask for an exception in the following cases:

If you find a package that is out of compliance, please file a bug against the package.