License guide · Copyleft
LGPL-3.0, in plain English
The GNU Lesser General Public License (LGPL-3.0) is weak copyleft — and it was written specifically so that proprietary software can use it. Unlike the full GPL, you may link an LGPL library into a closed-source, commercial application and distribute the whole, on two conditions: the library’s own source (and your changes to it) stay open under the LGPL, and the user can relink a modified version of the library. Your application code can stay proprietary.
Updated 27 Jul 2026 · by the depproof team
General information, not legal advice. The controlling text is the license itself and the facts of how you link and ship. Primary source: the GNU Lesser General Public License, version 3.
Weak copyleft: the whole point of the “Lesser”
The LGPL is genuine, OSI-approved open source — but its job is different from the GPL’s. Where the GPL is strong copyleft and pulls the entire combined work under its terms, the LGPL is weak copyleft: it protects the freedom of the library, but deliberately stops the copyleft from spreading to the separate program that merely uses the library. That’s why it’s called the Lesser GPL — and why a proprietary product can ship with an LGPL dependency where a GPL one would force the whole product open.
Structurally, LGPL-3.0 isn’t a standalone license: it is the GPLv3 plus a set of additional permissions. You read the GPLv3, then the LGPL relaxes specific requirements for the case where the code is a library linked into a larger work.
The core mechanism: link, but keep the library replaceable
The deal the LGPL offers is precise. You may combine an LGPL library with your own proprietary application and distribute the result, provided you:
- Keep the library open. The LGPL library’s source — plus any modifications you make to the library itself — stays available under the LGPL. Your separate application code does not.
- Let the user relink. Whoever receives your combined work must be able to swap in a modified version of the LGPL library and have it still run. The clean way is dynamic linking: ship the library as a shared object the app loads at runtime, and the user can rebuild and replace it.
- Give notice. Make clear the work uses the LGPL library and include a copy of the license, so recipients know the freedom (and the relinking right) exists.
Static linking is still permitted, but stricter: because the library is baked into your binary, you must supply the means to relink — typically your application’s object files (or source) so a user can combine a modified LGPL library with your code and produce a working program. Dynamic linking is simply the lower-effort route to the same obligation.
Can you…? The LGPL decision at a glance
| Can you… | Under LGPL-3.0? |
|---|---|
| Use it in a proprietary app via dynamic linking and distribute the whole | Yes — with conditions (open library + relinking) |
| Keep your own separate application code proprietary | Yes |
| Keep your modifications to the LGPL library itself proprietary | No — library changes go back under the LGPL |
| Prevent users from relinking a modified version of the library | No — the relinking right is required |
| Static-link into a proprietary binary without providing relink means | No — you must supply object code/source to relink |
| Run it as a SaaS on your own servers | Yes — no network clause; distribution is the trigger |
So the LGPL question isn’t “open or closed?” — it’s “have I kept the library a separate, replaceable, open component?” If yes, your proprietary, commercial software is free to ship with it. Note the contrast with the AGPL-3.0, whose network clause can trigger source obligations even for SaaS.
Where LGPL trips up dependency and license policy
LGPL gets misread in both directions. Some teams see “GPL” in the name and blanket-ban every *GPL license — needlessly excluding safe LGPL libraries they could lawfully ship inside a proprietary product. Others treat LGPL like MIT and forget the relinking obligation entirely, which bites hardest when they statically link. Both mistakes come from classifying by keyword instead of by what the license actually requires.
The practical move is to make LGPL visible in your dependency inventory — distinct from GPL and AGPL — and decide policy per license, so you neither exclude safe libraries nor miss a real obligation.
- Check your Maven dependency licenses — surface LGPL, GPL, and AGPL across the full transitive tree, without a build.
- Check your npm dependency licenses — classify copyleft licenses in your JavaScript dependencies.
- See org-wide license posture — roll every project’s copyleft exposure into one view for legal and compliance.
LGPL vs GPL vs AGPL, in one line each
- MPL-2.0 (file-level copyleft). The narrowest of the three: only the covered files and your changes to them stay open.
- LGPL-3.0 (weak copyleft). Proprietary apps can link and ship it; only the library and your changes to it stay open; users must be able to relink.
- GPL-3.0 (strong copyleft). Linking pulls the whole combined work under the GPL; the classic “can’t hide it in a proprietary product” license.
- AGPL-3.0 (network copyleft). GPL plus a network clause — even offering it as a SaaS can trigger source-availability obligations.
Frequently asked questions
Can proprietary or commercial software use an LGPL library?
Yes — that is the entire point of the LGPL. Unlike the full GPL, the Lesser GPL is designed so that a proprietary, closed-source application can link against an LGPL library and be distributed as a whole, without the application itself becoming subject to copyleft. The conditions are that the LGPL library’s own source (including any changes you made to it) stays open under the LGPL, and that whoever receives your combined work can replace the library with a modified version and relink. Meet those and your application code can stay proprietary.
Is LGPL-3.0 open source?
Yes. LGPL-3.0 is an OSI-approved, Free Software Foundation open-source license. It is a “weak copyleft” license: it protects the freedom of the library itself, but deliberately does not spread copyleft to the separate program that merely uses the library. So it sits between permissive licenses like MIT (no copyleft at all) and the GPL (strong copyleft that covers the whole combined work).
What is the difference between dynamic and static linking under LGPL?
Both are allowed, but they carry different obligations because both ultimately require that the end user can substitute a modified version of the LGPL library and relink. Dynamic linking (a shared library the app loads at runtime) satisfies this naturally — the user can drop in a rebuilt library. Static linking bakes the library into your binary, so to preserve the same freedom you must provide the means to relink: typically the application’s object code (or source) so a user can combine a modified LGPL library with it. Dynamic linking is simply the easier path to compliance.
Do I have to open-source my application if I use an LGPL library?
No. Your separate application code can remain proprietary. What must be shared under the LGPL is the library itself and any modifications you make to that library. The obligation attaches to the LGPL-licensed component, not to the program that links against it — provided you keep it a genuinely separate, replaceable component (the relinking requirement) rather than merging it into your own code.
Does the LGPL have a network / SaaS clause like the AGPL?
No. Like the GPL, the LGPL’s obligations are triggered by distribution — conveying the software to someone else. Running LGPL-licensed code on your own servers to provide a SaaS is not distribution, so it does not trigger the source-availability requirements. Only the AGPL adds a network-use clause that treats remote interaction like distribution.
Why does LGPL matter for my dependency and license policy?
Because it is easy to get wrong in both directions. Some teams see “GPL” in the name and blanket-ban every *GPL license, needlessly excluding safe LGPL libraries they could legally ship in a proprietary product. Others treat LGPL as if it were MIT and forget the relinking obligation — especially when they statically link. The practical step is to detect and classify LGPL (versus GPL and AGPL) explicitly in your dependency inventory, and set policy per license rather than by keyword.
General information, not legal advice; confirm specific decisions with counsel. “LGPL” and “GNU Lesser General Public License” refer to the license published by the Free Software Foundation and are used nominatively.