License Review for Shipping Products


If you are shipping an Android app, an iOS app, a desktop app, or consumer hardware outside the company, you need to read this. Your app or device uses open source software, and we need to perform a simple check to make sure we are satisfying our obligations under the licenses.

If you are an Android app that builds with Blaze, a GMS Core module, a GMS Core SDK component, or Granular SDK we have an automated form you can use below. Otherwise scroll to the bottom section of this page.

You may need to display some text to a user within a help and/or settings menu. You may have scarier obligations like having to give the source to your app to every user. We use this process to figure out where you stand and make sure everything is OK before you ship.

The review is a legal requirement- it has nothing to do with whether your app or product is open source.

Every time compiled software is distributed outside of Google, we trigger license compliance obligations. A license review must be performed for the initial launch of any compiled software, and for every subsequent release. However, if the software ships multiple releases per month then a minimum of at least one license review per month is sufficient.

When no distribution of software is taking place

Software is “distributed outside of the company” anytime software is sent to users, run on users’ devices, made available for users to copy, or published to cloud containers that users possess file system access to.

A license review is required whenever software is distributed outside of Google in binary or object code form.

If your launch calendar includes an External License Review bit, but no binaries are being distributed outside the company, please create a ticket following the process below and put a comment in the ticket stating: No software distribution taking place.

Please never set the External License Review to FYI. Launches that never entail distribution of software outside the company should not have an External License Review bit at all rather than an FYI bit.

Distributions of source code alone are not subject to the go/licensereview process. However, if the source distribution includes open source code, the go/releasing and go/patching processes do apply.

When you’re releasing a web-based application

Javascript, typescript, or other third party code thats transmitted to clients over the web also counts as a distribution and is subjected to the same review as other applications that are being distributed.

Since the license review automation has no idea how your application is structured, it is helpful to organize your build targets such that there is one build target that groups together all dependencies that are distributed via your app (eg a filegroup containing all the processed javascript).

Use this target when completing the form below instead of your application. This will avoid any unnecessary additional review - many server targets depend on restricted code and that’s OK because you’re not distributing that code.

When you need our review bit on your calendar

If you are regularly distributing compiled binaries to third parties via an ariane calendar, that calendar needs our review bit to audit third party dependencies and ensure the distribution is in compliance.

Please follow http://linkremoved/ to add a bit called ‘external license review’ to your calendar, and please make sure the bit is only assigned to the mdb ‘app-license-review’, and not a human being or another alias.

When to file and how to escalate

Please file your ticket at least 14 days before you launch.

Please give at least 7 days before you ping anyone.

Please don’t ping reviewers directly. Instead, email emailremoved@ if a license review is dragging.

Submit your ticket

Before you submit your ticket:

  • If you are an Android app stored on google3, and building with Blaze, you must configure go/android-license-library before you ship.

  • If you are an iOS app, you must configure go/iosopensource before you ship.

  • If you are a GMS Core module or SDK component you must read and comply with go/gmscore-thirdparty before you ship.

As long as you build using Blaze, you can create your license review using the form below. However, if you do not fall into one of the three categories above, you are responsible for ensuring that legal notices are being displayed. Please email emailremoved@ if you have any questions about meeting your go/thirdpartylicenses#notice requirements.

Once you have configured the appropriate license display mechanism for your app, please use this form for an expedited review. If you don’t know how to fill this out, please consult an engineer on your team. Please don’t submit blank tickets.

Please fill out each field completely exactly as requested. Fill out one ticket per blaze target that you are launching.

You cannot use many –config or –blazerc flags, because they are not supported by buildrabbit. Configs defined in the global blazerc may work.

Please note that your Blaze target path must begin with “//” and your Blaze target must be supplied in the correct field of the form, or the automated Blaze query will not run.

Submit your ticket here

TIP: If you would like to test your blaze target without triggering a review you can use go/ospo-querytool.

If you don’t build with Blaze

No problem!

Gradle users: please use this Google-supported license plugin

Otherwise, please fill out a new bug and attach a completed licensing compliance worksheet (go/licensingworksheet). Please do not add anyone from the Open Source Programs Office to this bug. This bug will automatically cc emailremoved@ which will add it to our twice-weekly review queue.

How to allow by_exception_only and restricted dependencies

When you fill out the form above, a bug will be generated which may not be automatically approved because it has detected you are shipping some by_exception_only or restricted dependencies.

Handling suspected false positives

We use go/blaze-cquery to build the dependency graph, which is designed to properly account for different build configurations. If a restricted or by_exception_only dependency is popping up, it’s probably because it is actually being shipped.

If you still think a reported dependency is a false positive:

  1. File a bug asserting that blaze cquery is falsely reporting your dependency.

  2. Send a CL to update the by_exception_only proto or the restricted proto. Add “license-escalation” as well as your manager to the R line, reference the bug you filed against blaze-cquery in the CL description, and paste the text:

    I assert this is a false dependency, I have contacted the blaze cquery team to fix it in bug …NNN. I promise to remove this dependency from the allowlist once the issue is fixed, or if I ever actually include this dependency.

Including a by_exception_only dependency

  1. Send an email to your product counsel, cc’ing emailremoved@, linking to your bug, listing out the by_exception_only dependencies that were generated, and linking to the LICENSE file of each dependency.

  2. Your product counsel needs to certify over email your use of the code falls within the license Google has. If your product counsel and emailremoved@ determine you have the right to ship, please update the above-referenced by_exception_only proto to silence the report.

Including a restricted dependency

  1. You should almost never do this. You will likely be required to publicly mirror the entire source for your application. First consider alternatives with your management, and then contact emailremoved@ to discuss if you believe you need to do this.

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.