Licenses

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"])

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.

NOTE: New license rules should not be commented with the specific license, e.g. with '# GPL v2'. In BUILD files that have these, feel free to remove the comment.

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 apply the same permissions and limitations set by the Restricted category of licenses, but with one important exception. The obligation to make source code available to recipients of software that depends on a Reciprocally-licensed library only extends to the contents of the library itself, together with any additions to or modifications of that individual library. Unlike GPL and other Restricted licenses, the other components of the software depending on the Reciprocal library do not need to have their source released under the corresponding reciprocal license.

The distribution of software that contains reciprocally-licensed components triggers our obligation to make the corresponding source code of those components available to end users. Reciprocally-licensed third-party source code in //piper/third_party must be made available by mirroring it to a repository at third-party-removed.googlesource.com. Shortcut for setting up new projects.

If reciprocally-licensed dependencies are surfaced in go/licensereview bugs for application launches, the team responsible for the app launch must create the new project repository at third-party-removed.googlesource.com if it does not already exist. Engineering employees are able to create new projects. The project should sync from //third_party using go/copybara, and include our modifications to the third party source code. If more than one version of a given dependency needs to be mirrored, the naming of the external mirrors should be the same as the naming of the //third_party versions, e.g., v1 and v2. //third_party/libraryX/v1 should be mirrored to third-party-removed.googlesource.com/libraryX/v1, and //third_party/libraryX/v2/folder should be mirrored to third-party-removed.googlesource.com/libraryX/v2/folder. Exceptions should be made where the internal name should not be shared externally, such as when there are confidential internal codenames involved, or we would not want to mirror embargoed security fixes.

The open source office also encourages Google engineers to provide beneficial changes back to the upstream open source project under the go/patching policy. However, if there are compelling reasons not to mirror the internal modifications externally or share them upstream, such as when there are embargoed security fixes or valuable proprietary IP additions that should remain internal, then the reciprocally-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 allow 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 'METADATA' file in the internal //piper/.../third_party directory should be updated to include a link to the external third-party-removed.googlesource.com mirror.

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.

If the software at issue is a binary that is being sent to end-users' devices, that users only interact with through a command line interface, then we would recommend setting up a flag that can be passed through the tool to make the console read out these notices (e.g. --notices). Alternatively, these notices can be concatenated into a THIRD_PARTY_NOTICES.txt file that is bundled with the software, as long as the software is being sent to a device that permits the end user to view the text of that file.

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. Examples of licenses that are commonly used by open development communities that must be treated as by_exception_only include:

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 agreement and a Google Drive link to the fully signed commercial agreement (with access granted to emailremoved@).

NOTE: The complete text of the document that spells out Google's permission to use the software should be reproduced in the LICENSE file if possible. If that document contains highly-sensitive terms that can only be shared with a limited audience, it is fine for the LICENSE file to not include the complete agreement text, but that agreement must be hosted on Drive, shared with emailremoved@, and linked-to in the LICENSE file.

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

[mandatory]
Drive link to a fully signed PDF of the agreement: ... drive link goes here ...
[optional]
See http://linkremoved/
for details of the licensing agreement.

Please contact <emailremoved@> with any questions.

==========================================

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

By_exception_only licenses with Notice requirements

If the terms of a by_exception_only license require inclusion of the license text in redistributions of the software, the license designation in the BUILD file must be:

licenses(["by_exception_only","notice"])

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 appropriate is 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).

As noted at go/thirdparty/documentation#google-owned-code, The LICENSE file for Google-authored, not-yet-released code should only contain the following text: "Google owned, no external contributions."

Open Sourced Google-Authored projects

Once a project has been open sourced with an accompanying LICENSE, the project must use the LICENSE in the package rather than be treated as unencumbered and any external contributions must sign a Contributor License Agreement (see go/cla).

Hardware licenses 🔨

The Apache license is our preferred license not only for source code but also for hardware. Licenses used for hardware do not need to include the word "hardware" in the name of the license. This section provides examples of hardware-specific licenses that may be checked in at Google, but please check where these licenses appear in the lists by license type above for instructions on how to treat each license as different versions may be categorized differently. For example, the different versions of the CERN OHL appear in almost every category of license type (notice, reciprocal, restricted, and by_exception_only).

  • Solderpad Hardware License; treat Solderpad projects as Apache licensed. The standard SHL-0.5, SHL-0.51, SHL-2.0, and SHL-2.1 texts provide the dual licensing option to treat the project as Apache-licensed. Retain standard Apache License Version 2.0 license terms in the LICENSE file.
  • CERN Open Hardware License 1.1
  • CERN Open Hardware License 1.2
  • CERN Open Hardware License 2 - Weakly Reciprocal Variant
  • CERN Open Hardware License 2 - Permissive Variant
  • CERN Open Hardware License 2 - Strongly Reciprocal Variant
  • PresubmitR Open Hardware License

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), OSL, and SSPL not allowed

Code released under the GNU Affero General Public License (AGPL), the Open Software License (OSL), or the Server Side Public License (SSPL) cannot be used in google3 under any circumstances, and only very rarely on workstations. Read more at go/agpl, go/sspl, and go/nomongo.

Business Source License not allowed

Not to be confused with the other BSL (Boost Software License), which is a Notice license. This license is not an open source license per the notice at the bottom of its text.

Cryptographic Autonomy License (CAL) not allowed

The Cryptographic Autonomy License is not allowed because it has complex obligations that require oversight from general counsel.

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.

CPOL not allowed

The Code Project Open License (CPOL) can't be used at Google because of the broad definition of 'Articles,' which could extend to code comments or essential documentation, and the explicit disclaimer of a license to Articles.

European Union Public Licence (EUPL) not allowed

The EUPL is very similar to the AGPL. For the same reasons that the AGPL is banned, the use of EUPL-licensed software is not allowed 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.

Watcom-1.0 not allowed

Code released under the Sybase Open Watcom Public License version 1.0 cannot be used at Google. Provision 12.1(c) terminates the license if any patent litigation is filed against Sybase or any contributor, including cross claims and counterclaims, without limiting the scope of this provision to patent litigation concerning the specific software being licensed. This provision goes too far in restricting the exercise of Google's patent rights and is therefore prohibited at Google.

"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.

Commons Clause not allowed

The Commons Clause prohibits any commercial use of the software. As with the above, everything that Google undertakes is a commercial endeavor, so no code released under any license that includes the Commons Clause may be used at Google.

Other licenses not listed

If a license is not listed above in this section, then it requires approval from emailremoved@ (for example by adding emailremoved@ to the R= line of the CL). This approval is required for each usage of the license at Google; you cannot assume that just because an unlisted license was approved for one usage that it is automatically approved for all other usages.

Code released under multiple licenses

All of the code is under the same licenses

When code has been dual-licensed, allowing the recipient to pick between several licenses (e.g. the MIT/GPL dual-licensed jQuery), assume that Google will be using the code under the least restrictive license. In this example, that would be MIT ('notice'), and the BUILD file would contain (including comment):

# Dual-licensed, using the least restrictive per [go/thirdpartylicenses#same](/documentation/reference/thirdparty/licenses/#same).
licenses(["notice"])

Document the multiple-license situation in the BUILD file or the METADATA file. The LICENSE file should contain only the text of the chosen LICENSE.

If different licenses apply to different parts of the project, then see the next section instead.

How to deal with small variations in licenses

If a package contains multiple copies of a license with minor variations, please include each variation in the LICENSE file separated by a horizontal line.

This includes for example:

  • The copyright year or owners are different.
  • The appendix text is included in one place but not the other.

In any case where the licenses are different, include the full version of each license in the LICENSE file separated by a horizontal line.

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 the following manner.

In the BUILD file, the file-scope licenses() needs to reflect the MOST restrictive license type that applies. For example, for a package with different portions under the GPL v2, BSD license, and MIT license, the license conditions are as follows:

License Condition
GPL v2 restricted
BSD notice
MIT notice

The most restrictive license in this case is "restricted" and the licenses() rule would need to be:

licenses(["restricted"])

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 by license type, and annotated with the licenses= parameter:

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

cc_library(
    name = "bar_encoder",
    srcs = ["bar_encode.cc"],
      ...
    licenses = ["reciprocal"],
)

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.

For Example:

Files: src/<directory name>/*

<License Text>

------------------

Files: src/<directory name>/*

<License Text>

Combinations of Restricted and By_Exception_Only Code

If code licensed to us under a commercial license (e.g. custom agreement, EULA) is intermixed with code licensed to us under a restricted license (e.g. GPL, LGPL), the following warning comment needs to be added to the library's BUILD and METADATA files in ALL-CAPS, directly beneath the go/thirdpartylicenses#ByExceptionOnly warning header and above the "# Description" line, with no blank lines in between.

# *** THIS PACKAGE CANNOT BE DISTRIBUTED OUTSIDE OF GOOGLE. ***

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 list 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 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',
# 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"],
)

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

If you are distributing software outside of the company that incorporates any LGPL-licensed libraries, there are ways of meeting your license obligations that are less restrictive than the GPL's obligations if certain requirements are observed. Please reach out to emailremoved@ if you plan to redistribute LGPL-licensed software in any way, and the Open Source Compliance team will be able to review your case and advise.

The following steps are required in order to be able to take advantage of the reduced requirements:

  1. The LGPL-licensed library must be used as a shared library (dynamically-linked).
  2. For LGPL v3 only, the user must be able to replace the shared library with a compatible library and have it work (the user must be able to swap out libraries on the device).
  3. Customers must receive either object files or source code (including any modifications) of the LGPL-licensed library.

NOTE: You are not required to provide support for the LGPL-licensed library. You are not required to work around bugs or problems in compatible libraries, or perform tech support for customer modifications. You are required to make library replacement possible (for LGPL v3). You are required to permit user modification of the software, and to not prohibit user modification in the terms of service.

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.

PLEASE ALSO NOTE: Configuring Blaze to dynamically-link components is difficult. Please consider whether dynamically-linking is an available option before depending on LGPL-licensed code.