The GNU Lesser General Public License (LGPL) is a weak-copyleft license designed for software libraries: you must keep the LGPL library itself open and share modifications to it, but you may link it into proprietary applications without those applications having to adopt the LGPL — provided users can replace or relink the library. Created by the Free Software Foundation as a more permissive companion to the GPL, the LGPL exists mainly as LGPLv2.1 (1999) and LGPLv3 (2007). It licenses widely used libraries such as GTK, glibc, and FFmpeg (in part), and it exists precisely to let free libraries be adopted by proprietary software without the full "viral" effect of the GPL.
This article explains the LGPL in general terms. It is not legal advice — consult a qualified attorney for guidance on your specific situation.
What the LGPL Permits and Requires
The LGPL grants GPL-like freedoms for the library while relaxing the copyleft obligation for the code that merely uses it.
| Category | Details |
|---|---|
| Permissions | Use the library in any software (including proprietary), modify it, distribute it, and use commercially |
| Conditions | Disclose source of the LGPL library and any modifications to it; keep the library under the LGPL; let users replace/relink the library with a modified version; preserve notices |
| Limitations | No warranty; no liability; the relinking requirement constrains how tightly you may bind the library |
The key distinction from the GPL is that copyleft attaches to the library, not to the application that links against it. Your proprietary application can stay proprietary. What you owe is (1) source and reciprocity for the library and your changes to it, and (2) a way for users to swap in their own version of the library.
Is the LGPL Copyleft or Permissive?
The LGPL is weak (library-level) copyleft. It sits between permissive licenses like MIT and the strong copyleft of the GPL. Improvements to the library must flow back under the LGPL, so the library stays free — but the application built on top of it does not inherit those terms, so proprietary use is fully possible.
The practical catch is the relinking requirement: users must be able to run your application with a modified version of the LGPL library. With dynamic linking this is straightforward — the shared library can simply be replaced. With static linking it is harder, and the LGPL requires you to provide the means (such as object files or a mechanism) for users to relink against a modified library. This is why LGPL libraries are most commonly consumed via dynamic linking. Our concepts library explains weak versus strong copyleft, and our comparison pages place the LGPL alongside the GPL and MPL.
LGPLv2.1 vs LGPLv3
The two versions differ much like GPLv2 and GPLv3:
- Patents. LGPLv3 (built on GPLv3) includes explicit patent provisions; LGPLv2.1 does not.
- Anti-"tivoization." LGPLv3 carries GPLv3's installation-information requirements for consumer devices; LGPLv2.1 does not.
- Structure. LGPLv3 is written as a set of additional permissions on top of GPLv3, whereas LGPLv2.1 is a standalone text.
As with the GPL, tracking the specific version matters for compatibility and obligations.
What the LGPL Means for Your Project and Compliance
For teams shipping proprietary software, the LGPL is usually manageable, but two obligations require deliberate engineering choices.
First, keep the library open and share your changes to it. If you modify the LGPL library itself, those modifications must be made available under the LGPL. Your application code is unaffected, but the library is not.
Second, preserve the user's ability to relink. This is the obligation teams most often get wrong. If you dynamically link the library, you are generally fine — but you must not, for example, strip the ability to substitute a different build of it. If you statically link, you take on the additional burden of providing what users need to relink against a modified library. Because of this, static linking of LGPL code into a proprietary binary is the classic compliance pitfall, and it is one worth catching before release.
You must also honor the standard attribution and notice requirements, and ship the LGPL license text. As with all copyleft, the foundation of compliance is knowing exactly which LGPL libraries you use and how they are linked. The academy covers building that awareness into your workflow.
How Safeguard Tracks LGPL License Compliance
The LGPL's obligations hinge on details that are invisible without a real inventory: which libraries are LGPL, which version, and how they are linked. Getting any of those wrong can turn a compliant integration into a violation.
Safeguard's Software Composition Analysis discovers every open-source component in your project, resolves each license, and flags LGPL libraries — including the specific version — across your full dependency tree. That gives you the authoritative list of where relinking and library-source obligations apply, rather than a manual guess that misses transitive dependencies.
SBOM Studio then records each component's license in a CycloneDX or SPDX software bill of materials, producing an auditable inventory of your weak-copyleft exposure and the evidence you need to demonstrate compliance. Policy rules let you encode how the LGPL fits your product — permitted for dynamic linking, flagged for review, or requiring a note about static linking — and evaluate every build automatically, so an LGPL library never ships in a way that breaks the relinking requirement. Create a free account to inventory the LGPL libraries in your codebase, or read the documentation to configure a policy.
Frequently Asked Questions
Can I use an LGPL library in proprietary software? Yes — that is exactly what the LGPL is designed for. You can link an LGPL library into a closed-source application without your application becoming subject to the LGPL. You must keep the library itself (and any modifications you make to it) open under the LGPL, and you must let users replace or relink the library with their own modified version.
What is the difference between the GPL and the LGPL? The GPL is strong copyleft: distributing a derivative work generally requires the whole combined program to be GPL-licensed with full source. The LGPL is weak copyleft applied to libraries: only the library and your changes to it must stay open, while an application that merely links to the library can remain proprietary. The LGPL exists specifically to let free libraries be used by non-free software.
Does static linking of an LGPL library cause problems? It creates extra obligations. With dynamic linking, users can simply replace the shared library, which satisfies the relinking requirement easily. With static linking, you must provide what users need to relink your application against a modified version of the library, such as object files or an equivalent mechanism. Because this is burdensome, LGPL libraries are usually consumed via dynamic linking.
What is the difference between LGPLv2.1 and LGPLv3? LGPLv3 is built on GPLv3 and adds explicit patent provisions and the anti-"tivoization" installation-information requirements for consumer devices; LGPLv2.1 has neither. LGPLv3 is structured as additional permissions layered onto GPLv3, while LGPLv2.1 is a standalone license. Tracking the exact version matters for both compatibility and your obligations.