Docs
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).
- BCL
- Creative Commons “Attribution-ShareAlike” (CC BY-SA) and “Attribution-NoDerivs” (CC BY-ND) licenses
- GNU Classpath’s GPL + exception
- GNU GPL v1, v2, v3
- GNU LGPL v2.1, v3 (though marked as restricted, LGPL-licensed components can be used without observing all of the restricted-type requirements if the component is dynamically-linked).
- Netscape Public License NPL 1.0 and NPL 1.1
- OSL
- QPL
- Sleepycat License
- qmail Terms of Distribution
- Anything else not explicitly listed without prior legal sign-off.
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).
- Common Development and Distribution License CDDL 1.0, CDDL 1.1
- CeCILL-C License
- CPL 1.0
- EPL 1.0 and EPL 2.0 (Eclipse Public License)
- IPL 1.0 (IBM Public License)
- Mozilla Public License MPL 1.0, MPL 1.1, and MPL 2.0
- Apple Public Source License (APSL) 2.0
- Ruby
Changes to reciprocally-licensed third-party source code in //piper/…/third_party will be made available by mirroring the altered third-party source code in 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.
- AFL 2.1 and AFL 3.0
- Apache License 2.0
- Artistic License 1.0 and Artistic License 2.0
- ASL 1.1 (Apache Software License 1.1)
- Autodesk DWF Toolkit
- Boost Software License
- BSD (occasionally referred to as the “University of California” license)
- BSD 3-clause (sometimes called BSD-new)
- BSD + Patent
- Creative Commons “Attribution” (CC BY) license
- JSON License (MIT license with the added note: “The Software shall be used for Good, not Evil.”)
- Eclipse Distribution License (BSD variant)
- FreeType Project License
- ISC License
- libjpeg-turbo
- LibTIFF
- Lucent Public License 1.02 (used by Plan 9 now, but different from “the Plan 9 license”)
- Microsoft Public License (MS-PL)
- MIT/X11/Expat
- NCSA
- OpenSSL
- PHP License 2.02 and 3.0
- PostgreSQL License
- Python Software Foundation
- TCP Wrappers
- Unicode, Inc. License Agreement - Data Files and Software
- Universal Permissive License (UPL), Version 1.0
- W3C Software license
- X.Net
- Zend Engine License, v2.00
- zlib/libpng
- ZPL
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 agreement and
a Google Drive link to the commercial agreement (with access granted to
emailremoved@).
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 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....
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:
- It is non-trivial to place software in the public domain. While an explicit disclaimer of copyright protection is required, that is not necessarily sufficient.
- While works of the U.S. Government are placed in the public domain, works created by contractors under government contracts may not be.
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).
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.”
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) and SSPL not allowed
Code released under the GNU Affero General Public License (AGPL) or the Server Side Public Licese (SSPL) cannot be used in google3 under any circumstances, and only very rarely on workstations. Read more at go/agpl and go/nomongo.
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) 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© 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.
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 to the WTFPL on account of its vague grant of rights and likewise cannot be used at Google, nor can Beerware-licensed projects be patched by Googlers.
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.
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 Common 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](/docs/thirdparty/licenses/#same).
licenses(["notice"])
Document the multiple-license situation in the LICENSE file. Include the texts
of all of the licenses in a single LICENSE file, separating the licenses with
dashed line dividers. Include a note explaining that the entire project is
licensed for use under the terms of any of these licenses. If different licenses
apply to different parts of the project, then see the next section
instead.
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. For example, for a package with different
portions under the GPL v2, BSD license, and MIT license:
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>
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',
# 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:
- The LGPL-licensed library must be used as a shared library (dynamically-linked).
- 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).
- 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.
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.