opensource.google.com

Menu

Docs

Licenses

go/thirdpartylicenses

Background

Google needs to comply with open source licenses for all software that we distribute externally. This is typically straight-forward, because a lot of software is distributed under a license that we’ve already vetted. This document gives more information on what those licenses are, what categories they fall under, and how to handle them. See go/thirdparty for general rules for putting code in //piper/third_party. Contact emailremoved@ if you have questions.

The licenses() list (only for //third_party packages)

The licenses() list does not belong in BUILD files outside of //{google3,googleclient,googleclient/wireless,...}/third_party. For a complete list of //third_party repositories, see go/thirdparty. Similarly, the distribs() list does not belong in BUILD files inside //third_party packages. These two rules are mutually exclusive. For the rest of this document, //third_party is assumed to refer to all known third-party source code repositories.

A license type is a group of actual software licenses that have the same repercussions on the Google build process with respect to the distribution method specified by a build target. For example, the string ‘notice’ is used to represent all of the licenses that would create some sort of copyright documentation requirement in externally distributed software. licenses() is used at BUILD file scope to specify the license-type identifier string (for software licensed under more than one license, see below) for all of the build rules in a given BUILD file.

NOTE: The licenses() directive must appear before the first build rule in the BUILD file.

Strings naming each unique license type that applies to a //third_party BUILD file are specified by a list of strings supplied to licenses() at BUILD-file scope.

For example, the //piper/.../BUILD file would be updated with something like:

licenses(["restricted"])  # GPLv2

The list of license type strings known to blaze can be found in License.java. A fatal error is generated if a license type string is encountered in a BUILD file that is not present in License.java. The different license type strings are discussed below.

License types

The ‘restricted’ licenses

The ‘restricted’ licenses are the primary reason for the creation of this project. Licenses in this category require mandatory source distribution (including Google source code) if Google ships a product that includes third-party code protected by such a license. Also, any use of source code under licenses of this type in a Google product will “taint” Google source code with the restricted license. Third-party software made available under one of these licenses must not be part of Google products that are delivered to outside customers. Such prohibited distribution methods include ‘client’ (downloadable Google client software) and ‘embedded’ (such as software used inside the Google Search Appliance).

The ‘restricted_if_statically_linked’ license

WARNING: Do not use this type of license without contacting emailremoved@!

The ‘restricted_if_statically_linked’ license is a special case of license checking for go/grte. GRTE (Google Run Time Environment) has a special exception if it is shipped with the operating system and not linked statically into the binary.

The ‘reciprocal’ licenses

The ‘reciprocal’ licenses allow usage of software made available under such licenses freely in unmodified form. If the third-party source code is modified in any way (even changes to accommodate the google3 build environment) these modifications to the original third-party source code must be made available (but, in contrast to the ‘restricted’ licenses above, Google source code itself will be unaffected by the license).

Changes to the third-party source code will most likely be made available by mirroring the altered third-party source code on a googlesource.com repository.

The open source office encourages Google engineers to provide beneficial changes back to the upstream open source project, via go/patching. However, if the modifications are google3-specific and cannot be mirrored, then the ‘reciprocal’-licensed package must not be used in software that is distributed outside of Google. For example: client applications, the Google Search Appliance, Android applications. Use package visibility specifications to white-list only binary targets that may depend on the package in question and an ALL-CAPS notice at the top of the BUILD file to indicate that the package contains patches which cannot be open sourced.

The ‘notice’ licenses

The ‘notice’ licenses contain few restrictions, allowing original or modified third-party software to be shipped in any Google product without endangering or encumbering Google source code. All of the licenses in this category do, however, have an “original Copyright notice” or “advertising clause”, wherein any external distributions must include the notice or clause specified in the license.

For downloaded Google ‘client’ products, the necessary notice files can be installed to some subdirectory of the Google product. For ‘embedded’ Google products, such as the Google Search Appliance, or Android apps that make use of ‘notice’-licensed source code, the required notices either need to be linked off of an “About” page or possibly included in printed documentation.

NOTE: SIL Open Font License (OFL-1.1) is not a ‘notice’ license and has additional restrictions. Please mark packages that use the OFL-1.1 license as ‘by_exception_only’.

The ‘permissive’ licenses

The ‘permissive’ license type can be used in (relatively rare) cases where third-party software is under a license (not “Public Domain” or “free for any use” like ‘unencumbered’) that is even more lenient than a ‘notice’ license. Use the ‘permissive’ license type when even a copyright notice is not required for license compliance. For example, this license type can be used when a third-party cc_library() rule only adds header files (licensed under, say, the GNU LGPL) to the include path for compilation, but no actual binary libraries or source files. (Yes, these cases exist, such as with header files that define interfaces to dynamically-loaded libraries that are present in the operating system distribution itself.)

The ‘by_exception_only’ licenses

Some third-party licenses are simply incompatible with all (or most) uses in combination with Google source code. Commercial third-party packages that are purchased and licensed only for a specific use fall into this category. In such cases, an explicit exception for each Google target build rule licensed to make use of the third-party package is needed. To enforce these explicit exceptions at the BUILD rule level, see below.

Some third-party licenses have conflicting license terms. Others impose terms that would interfere with the use of the licensed source code at Google. In these cases we use the ‘by_exception_only’ license classification. Packages that fall under the ‘by_exception_only’ license classification are expected to be rare occurrences.

If your license type ends up being ‘by_exception_only’, use an ALL-CAPS warning saying the following both at the very top of the METADATA file and as a comment at the very top of the BUILD file, before the package description if any, with no blank line in between the last line of this comment block and the “# Description” line:

# *** THIS PACKAGE HAS SPECIAL LICENSING CONDITIONS.  PLEASE
#     CONSULT THE OWNERS AND emailremoved@ BEFORE
#     DEPENDING ON IT IN YOUR PROJECT. ***

Documenting commercial licenses

The license type should be “by_exception_only” in the BUILD file:

licenses(["by_exception_only"])

For commercial //third_party packages, host a copy of the license agreement in Drive and share read permissions with the emailremoved@ mailing list.

Create the CL to import the code.

Create a LICENSE file in the CL containing the full text of the license and a http://linkremoved/ link to the commercial agreement.

Add emailremoved@ to your CL. OSPO will then either +1 if the licensing documentation is correct, or comment if the licensing documentation needs to be fixed.

See http://linkremoved/
for details of the licensing agreement.
[and/or]
Drive link to the agreement: ... drive link goes here ...

Please contact <emailremoved@> with any questions.

LICENSE TEXT
... Full text of the license goes here....

The ‘unencumbered’ licenses

In addition to the Public Domain and Google-authored code cases below, actual licenses exist that basically declare that the code is “free for any use”:

Public domain and “Free For Any Use”

NOTE: Apply this label with caution. Public domain is a complex topic that requires legal analysis on a case by case basis. You must email emailremoved@ and ask for a special review before you check in public domain code.

The ‘unencumbered’ licenses include those often referred to as “Public Domain” or “free for any use.” These licenses have even fewer restrictions than licenses in the ‘notice’ category, but this licence type should be assigned to a third-party build rule with caution, because:

Third-party software whose copyright notice explicitly states that the work has been placed in the “public domain” by the author or is “free for any use” will be assigned the ‘unencumbered’ license type. As discussed in the links above, this does not necessarily mean that the work is unprotected by copyright, but granting of a very lenient license by the author can most likely be assumed.

Google-Authored code

Another instance where the ‘unencumbered’ license type is used is with code that Google itself has authored. This may be code that Google has authored, released as open source software, and then placed back into //third_party for use within Google. Software that Google has released as open source often falls into this category (but see the note about external contributions below). This also includes Google-authored code in a third-party package (such as tests added by Google) that Google has not open sourced but that exists in the //third_party package with the third-party code. This is typically handled by the licenses= build directive parameter for the specific build rules in the //third_party package that are building the Google-authored code (while the rest of the package has its license type set by the file-scoped licenses() directive).

Google-Authored projects that accept external contributions

Google-authored open source projects that accept external contributions are required to have the external contributors sign a Contributor License Agreement (see go/cla). Once a project has received any external contributions, you must identify and use the open source license in your //third_party package rather than ‘unencumbered’. We strongly suggest that you make this switch as soon as you release the project publicly, rather than waiting until your first external contribution.

Some software simply cannot be used at Google

For various reasons described in the following sections, some software is available only under license terms that make it unsuitable for use at Google. Exceptions may exist in some rare circumstances; contact emailremoved@ if in doubt.

AGPL (Affero GPL) not allowed

Code released under the GNU Affero General Public License (AGPL) cannot be used in google3 under any circumstances, and only very rarely on workstations. Read more at go/agpl.

CPAL not allowed

Likewise, code released under the Common Public Attribution License (CPAL), notably the Mule ESB and most of the code that backs Reddit, cannot be used at Google; it is AGPL-like in crucial ways and is disallowed for the same reasons.

European Union Public Licence (EUPL) is (at best) by_exception_only

Though similar in some ways to ‘restricted’ licenses, the EUPL is a ‘by_exception_only’ license at Google due to some onerous compliance requirements involving derived works. Even with this ‘by_exception_only‘ classification, some software available under the EUPL may not be usable by Google at all, depending on the specific circumstances. Ask the emailremoved@ mailing list about specific EUPL-licensed software before attempting to use it at Google.

SISSL not allowed

Code released under the Sun Industry Standards Source License (SISSL) cannot be used at Google. This license has terms that are very difficult to comply with (even Sun, before being acquired, ceased to use or recommend this license). Source files related to sFlow sometimes are released under this license, but are typically also available under a slightly less onerous sFlow License.

WTFPL not allowed

Code released under the WTFPL cannot be used at Google. This license has a large number of issues (lack of warranty disclaimer, very vague rights grant), and was also rejected as an open source license by OSI. We also do not allow contribution to projects under the WTFPL.

The Beerware license has similar issues.

See go/whatisalicense for more information on what we look for in a license.

“Non-Commercial” licenses not allowed

Everything that Google undertakes, including research, is considered a commercial endeavor, so no code released under a license that restricts it to non-commercial uses may be used at Google. For example, works under any Creative Commons licenses containing NC (CC BY-NC, CC BY-NC-SA, CC BY-NC-ND) may not be used at Google.

Code released under multiple licenses

All of the code is under the same multiple licenses

When code that has been released under multiple licenses (e.g. the MIT/GPL dual-licensed jQuery or the MPL/GPL/LGPL tri-licensed Mozilla), assume that Google will be using the code under the least restrictive license. In the two examples above, that would be MIT (’notice’) and MPL (’reciprocal’), respectively.

Document the multiple-license situation in the BUILD file:

licenses(["notice"])  # MIT (also dual-licensed GPL v2)

Concatenate the texts of all of the licenses into a single LICENSE file, separating the different licenses with dashed line dividers.

Parts of the code are under different licenses

When a package contains code that has portions under different licenses, things get complicated.

If the code is actually from separate identifiable sources, it should be broken up into separate packages, each including the BUILD, LICENSE, and METADATA (i.e., metadata files), that correspond to each separable package of code.

If the code really is a single package (or is otherwise inseparable), you must document the licenses in this the following manner.

In the BUILD file, the file-scope licenses() needs to reflect the MOST restrictive license type that applies:

licenses(["restricted"])  # GPL v2, portions BSD, MIT

If using all of the code under the terms of the most-restrictive license is acceptable, that file-scope specification is enough.

If not, and if portions of the code that are under less-restrictive licenses can be used separately from the rest of the package, it is possible (but not required) to split that code out into its own build rules, grouped per-license, and annotated with the licenses= parameter:

cc_library(
    name = "foo_decoder",
    srcs = ["foo_decode.cc"],
      ...
    licenses = ["notice"],  # BSD
)

cc_library(
    name = "bar_encoder",
    srcs = ["bar_encode.cc"],
      ...
    licenses = ["notice"],  # MIT
)

All build rules not explicitly annotated with the licenses= parameter will be covered by the file-scope licenses() directive.

Concatenate the texts of all of the licenses into a single LICENSE file, separating the different licenses with dashed line dividers. Include a brief note after each divider and before the actual license text mentioning for which code the license text applies.

The distribs() list (only for packages outside of //third_party)

The distribs() list does not belong in BUILD files inside //third_party packages. Similarly, the licenses() list does not belong in BUILD files outside //third_party. These two are mutually exclusive.

distribs() is used at BUILD file scope to specify one or more distribution-method identifier strings (the use case for multiple values is unclear, but the implementation is not significantly complicated by this additional flexibility) for all of the build rules in a given BUILD file. Currently, the distribs() directive must appear before any build rules in the BUILD file.

A “distribution method” is a group of ways that Google software is distributed or used that have the same repercussions on the Google build process with respect to the license types with which they might conflict. Some example distribution methods include:

  • internal’ — used exclusively internally at Google (usually corp, not prod web applications, though internal prod tools could use ‘internal’)
  • web’ — used on an externally accessible (prod) Google web property (this may matter in the future, for certain licenses such as “GPLv3”)
  • client’ — externally distributed (for example, downloadable) client software (for example, Google Toolbar)
  • embedded’ — software embedded in an externally distributed (for example, leased or sold) hardware product (for example, the Google Search Appliance)

Strings naming each unique distribution-method that applies to a google3-style BUILD file outside of //third_party are specified by a list of strings supplied to the distribs() list at BUILD-file scope. For example, the //piper/.../BUILD file would be updated with something like:

# Package is shipped out embedded in a Google Search Appliance.
distribs(["embedded"])

The list of distribution-method strings known to blaze can be found in Bazel’s License.java. A fatal error is generated if a distribution-method string is encountered in a BUILD file rule that is not present in the above file.

Restricting build dependencies

For ‘by_exception_only’ licenses (and a few others) you will probably want to restrict all BUILD rules in the package so they can only be depended on by the approved whitelist of packages. You can do this using the package group (go/be#package_group) and package (go/be#package) functions to restrict the visibility of the package:

# File: //third_party/theirpackage/BUILD
# Only allow packages in the whitelisted group 'allowed_users' to see the rules
# in this package.
package_group(
    name = "allowed_users",
    packages = ["//myteam/mypackage"]
)
package(default_visibility = [":allowed_users"])

This approach only changes the visibility of a single package. If your package has any subpackages, you will probably want to restrict visibility of those packages to only the topmost package:

# File: //third_party/theirpackage/BUILD
package_group(
    name = "theirpackage_only",
    packages = ["//third_party/theirpackage"],
)

# File: //third_party/theirpackage/subpackage1/BUILD, subpackage2/BUILD, etc.
# Only allow the enclosing package to access
package(default_visibility = ["//third_party/theirpackage:theirpackage_only"])

TIP: While this approach is strongly recommended for third-party packages with ‘by_exception_only’ licenses, it can be good practice for all sorts of other package structures as well.

Specifying exceptions to license-compliance conflicts

The license-compliance checking feature includes an audited “exception” mechanism that can be used to disable the warning or error messages that would otherwise be produced when a particular build target specifies a distribution method that is incompatible with the license of one of its dependencies. Some situations where such an exception mechanism should be used to bypass incompatibility issues include:

  • the “copyright notice” requirement of a BSD-licensed third-party software component has been verified to have been met in the final product
  • a special license (usually purchased from the software author) has been obtained for a third-party software component to allow commercial use of that component in ways that do not comply with the original open source license of the software
  • a commercially licensed third-party component with a restrictive license is being used in a way that complies with that license

The license-to-distribution incompatibility exceptions that have been authorized are explicitly recorded in the licenses() list of the third-party BUILD file whose license specification is involved in the incompatibility. The Piper history of the third-party BUILD files, and the existing code review tracking system (both already familiar to Google developers), are used to maintain the audit trail for decisions about granted exceptions.

To make use of a previous example, a license-compliance conflict exception would be added to the existing third-party //piper/third_party/pdftohtml/BUILD file like this:

licenses([
  'restricted',     # GPLv2
# A special license was purchased from Joe Smith, author of pdftohtml.
# The foo_bin binary, which depends on pdftohtml, can be distributed
# without source code.  All binaries and libraries in
# //piper/.../BUILD are assumed to be covered by this license.
  "exception=//foo:foo_bin",
])

NOTE: exception= is a string prefix, not a keyword parameter! The format of this string is picky, and spaces are not permitted within the exception string. Please see the example above.

The name of a target build rule (which has presumably specified a distribution method), when added to the licenses() list of a third-party BUILD file with an exception= prefix, indicates an exception is granted only to that specific build rule (”//foo:foo_bin” in this example). When the exception string is placed in the licenses() list of the third-party BUILD file, the exception is granted for all of the third-party build rules in that BUILD file.

As shown in the examples above, a comment should be included in the third-party BUILD file documenting the specifics of the exception, and these specifics should be included in the changelist description (at least in summary form) for the changelist where the exception was added to that BUILD file.

To distinguish between exceptions and actual license-type strings in the licenses() list of a third-party BUILD file, actual license-type strings are not permitted to begin with the exception= prefix.

The licenses build rule parameter

Please use the BUILD file scope licenses() list whenever possible. Only use the licenses= parameter when a specific build rule has a license type different from the BUILD file default specified for the entire file by licenses().

One of the new Rule class constructor parameters, licenses, can be used to specify one or more license-type identifier strings (some third-party software is licensed under more than one license, though this is uncommon). (See the licenses() list above section for details about license-type strings.) For example, the cc_binary() rule for the “pdftohtml” target in //piper/third_party/pdftohtml/BUILD would specify a build-rule-specific license type with something like:

cc_binary(
    name = "pdftohtml",
      ...
    licenses = ["restricted"],  # GPLv2
)

Use of the licenses() list in the BUILD file to specify a single license type (or possibly a list of license types) for all of the build rules in a BUILD file is preferred, and the licenses parameter should only be used for the special case of one build rule having a different license type from the rest of the build rules in the same BUILD file described earlier.

In a fashion analogous to the way it works in the licenses() list in a third-party BUILD file, a license-compliance conflict exception can be added to a specific existing third-party build rule like this:

cc_binary(
    name = "pdftohtml",
      ...
    licenses = [
# Duplicate the 'restricted' license type from BUILD file licenses()
# list, since providing an argument to the 'licenses' parameter
# overrides it, and the license type information is still needed
# for this build rule.
            'restricted',
# A special license was purchased from Joe Smith, author of pdftohtml.
# The foo_bin binary, which depends on pdftohtml, can be distributed
# without source code.  Other binaries added to //piper/.../BUILD
# may *not* be covered by this license.
            "exception=//foo:foo_bin",
    ],
)

The gconfig path and name of a Google target build rule (which has presumably specified a distribution method), when added to the licenses list of a third-party build rule with an exception= prefix, indicates an exception is granted only to that specific build rule (”//foo:foo_bin” in this example). When the exception string is placed in the licenses list of a third-party build rule, the exception is only granted for dependency on that particular third-party build rule. None of the other build rules in the in that third-party BUILD file are granting an exception.

The distribs build rule parameter

Please use the BUILD file scope distribs() list whenever possible. Only use the distribs= parameter when a specific build rule has a distribution method different from the BUILD file default (such as test targets that are not shipped outside of Google with the other build targets in the BUILD file) specified for the entire file by distribs().

Another new Rule class constructor parameter, distribs, can be used to specify one or more distribution-method identifier strings (the use case for multiple values is unclear, but the implementation is not significantly complicated by this additional flexibility). (See the distribs() list section above for details about distribution-method strings.) For example, the genrule() rule for the “google-enterprise-core.rpm” target in //piper/…/BUILD would be specify a build-rule-specific distribution method with something like:

genrule(
    name = "google-enterprise-core.rpm",
      ...
    distribs = ["embedded"],
)

Use of the distribs() list to specify a single distribution method (or possibly a list of distribution methods) for all of the build rules in a BUILD file is preferred, and the distribs parameter should only be used for the special case of one build rule having a different distribution method from the rest of the build rules in the same BUILD file described earlier.

LGPL linking requirements

The LGPL has an “escape clause” that says that one way of satisfying the requirements of the LGPL when using LGPL’d libraries is to do the following:

  1. Make the LGPL’d library a shared library
  2. Allow the user to replace the shared library with a compatible library and have it work
  3. Allow customer modification and reverse engineering for the purpose of debugging these modifications

NOTE: This does not require that you actually support this, only that you make it possible. You are not required to work around bugs or problems in compatible libraries, or perform tech support for customer modifications. You are only required to make library replacement possible, and user modification not prohibited by TOS. These requirements only apply to products shipped to end users. Software that is run internally (even if displayed on the web to the user) does not have to meet these requirements. For reference, the example case of something that cannot meet these requirements right now is the Google Search Appliance, because they do not allow the user access to the filesystem which contains the libraries.

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.