Skip to main content
SourceTrustSign in

Help center

Guides for SourceTrust: Importing dependencies, reviewing licenses, external obligations, publishing attestation pages, billing, plain-language license explainers, and procurement-oriented explainers for common open-source licenses.

LGPL linking compliance

← All articles

LGPL treats static and dynamic linking differently. You must know how this library is combined with your code.

Formal terms: LGPL linking compliance · confirm static vs dynamic linking and that users can replace or relink the LGPL component.

The GNU Lesser General Public License (LGPL) is a weak copyleft license used heavily in native libraries, media codecs, and system components. Its rules depend on how your proprietary code links to the LGPL library.

Static vs dynamic linking (plain language)

  • Dynamic linking: the LGPL library is a separate file (DLL, .so, framework) that users can replace. This is the common compliant pattern for proprietary apps.
  • Static linking: the LGPL object code is baked into your binary. You typically must provide relinkable objects or source so users can reconstruct the binary with a modified LGPL portion.

What to document

  1. Identify whether this component is linked statically or dynamically in each shipping configuration (desktop, mobile, embedded).
  2. If dynamic: confirm users can obtain and substitute the LGPL library file without rebuilding your entire product.
  3. If static: work with engineering and counsel on the LGPL-compliant distribution package (often object files + build scripts).
LGPL shows both linking and conditional source-distribution reviews in Distributed binary, Library or SDK, and Mixed. Review actual delivery and the license-specific duties before acknowledging both; where a stated trigger does not apply, confirm that conclusion.