LGPL vs GPL: Key Linking Differences Explained
LGPL is GPL with one deliberate escape hatch, and that hatch is the whole argument. Under the GNU Lesser General Public License you can link a closed-source program against the library and keep your own code private, as long as the library stays swappable and its source stays available. The plain GNU General Public License grants no such exception: link its code in and ship it, and your whole program goes GPL. If that split doesn't seem to matter for how your binary actually links, you haven't read the license text yet.
Last updated: 2026-07-21
Most developers reach for the LGPL without knowing what it obligates them to do, then find out at ship time. I'll be specific about where the copy-paste answers get it wrong.
What the LGPL actually is
It's a free software license from the Free Software Foundation, built as the looser sibling of the GPL. Both are copyleft, so they keep the code and its derivatives free to use, modify, and redistribute. The difference sits in exactly one place: how each one treats proprietary code that links against it.
The name trips people up, so clear it now. The LGPL started life as the Library General Public License, written for software libraries. The Free Software Foundation later renamed the "Library" part to "Lesser" to say out loud that it gives you less copyleft than the full GPL, on purpose. You'll see it called the GNU LGPL or the lesser GNU public license. Same document.
Two versions are in circulation, 2.1 and 3.0, and they differ on patents and how combined works are handled. Read the exact version you're shipping against, and pull it from the GNU LGPL page, not a random gist that may be edited or stale.
How does LGPL differ from GPL?
The GPL forces your whole project open; the LGPL confines that force to the library. Everything else follows from that.
Under the GPL, any derived software must also be licensed under the GPL. Link GPL code in, distribute the result, and you owe your program's source under the GPL too. There is no "just this part" option, and people keep hoping there is.
The LGPL shrinks the blast radius to the library itself. Link an LGPL library into a proprietary program and your program stays closed. Modify the library and distribute it, and those changes go out under the LGPL. Your application code stays clear of the copyleft, as long as you leave the library a separate, replaceable piece.
| Question | GPL | LGPL |
|---|---|---|
| Can proprietary code link to it? | No, the whole work goes GPL | Yes, if the library stays swappable |
| Must you open your application source? | Yes | No |
| Must you open changes to the licensed code? | Yes | Yes |
| Copyleft scope | Entire combined work | The library only |
So the GPL is the stricter copyleft and the LGPL trades strictness for reach. Want every downstream user to get full source? The GPL does that; the LGPL deliberately won't.
Why the linking method decides your obligations
Here's the part the top Stack Overflow answer skips: how you link changes what the LGPL demands. The license doesn't care that you used the library. It cares whether a user can replace it.
Dynamic linking is the clean path. Your program loads the LGPL library at runtime as a separate shared object, so a user can drop in their own build of it. You keep your source closed and you're done once you meet the notice and source rules for the library.
Static linking is where people get burned. Compile the LGPL code straight into your binary and the user can't swap the library without your object files. The LGPL still permits this, but now you have to hand users what they need to relink your app against a modified library. That usually means shipping your object files or another linkable form. Miss it and you're out of compliance while you think you're fine.
The real question is never "did I use an LGPL library." It's "can the person I shipped to rebuild that library and make my program use it." Answer that for your actual build and the obligation stops being fuzzy.
Can you keep your application proprietary under LGPL?
Yes, and that's the entire reason the license exists. It's why commercial teams pick LGPL libraries over GPL ones.
You can ship a closed, commercial application that links an LGPL library and never publish a line of your own code. What "keep it closed" does not cover is the library. Patch the library and those patches ship under the LGPL. You also have to preserve the user's ability to relink against a different build, which is exactly where dynamic linking earns its keep.
One limit the LGPL won't let you dodge: you can't hide that you used it. You still owe the notices and a way to get the library's source. Closed app, open library, visible attribution.
Where LGPL and GPL code can mix
LGPL code flows into a GPL project cleanly, because the LGPL is built to be compatible with the GPL. Use an LGPL library inside a GPL program and the combined work simply carries GPL terms. The lesser license upgrades to the stricter one without a fight.
The reverse fails the way beginners don't expect. You can't pull GPL code into an LGPL library and keep that library under the plain LGPL, because the GPL's copyleft drags the whole thing up to GPL. The license even ships a clause letting you convert a copy to the ordinary GPL when you want that.
Version compatibility is its own trap. GPL version 2 only code doesn't mix with GPL version 3 material, so check the version numbers, not just the family names. When you're weighing several options, my walkthrough on how to choose an open source license runs the questions in order.
Choosing LGPL over GPL for your own library
Pick the LGPL when you want wide adoption, including inside proprietary and commercial products. Pick the GPL when you want every program built on your code to also be free, and you'll accept losing the closed-source users to get it. That's the whole call, and it's as much ideology as engineering.
Three questions before you commit:
- Is this a library or module meant to be embedded? If yes, the LGPL removes the biggest reason a commercial team would skip it.
- Do you want proprietary programs to use it? GPL says no by default; LGPL says yes.
- Do you care more about reach or about forcing downstream freedom? Reach points to LGPL, enforced freedom to GPL.
Device drivers and low-level components are a common LGPL case, because you want hardware vendors to actually ship your code. I dug into that trade-off in when to use LGPL for device drivers. If you want maximum copyleft, don't reach for the LGPL and then act surprised when closed products build on you. That's the feature working as designed.
Your real obligations when you ship LGPL code commercially
Meet four duties and you're compliant, whatever your build system does:
- Preserve relinking. Users must be able to swap the library for their own build and still run your program. Dynamic linking hands you this for free; static linking makes you ship object files or another linkable form.
- Provide the library's source. Offer the complete source of the library plus any changes you made. A working download link covers it, and you owe nobody your application source.
- Carry the notices. Keep the copyright and license notices intact, say plainly that the work uses LGPL code, and include a copy of the license text.
- Release your library changes. If you modify the library and distribute it, those changes go out under the same LGPL terms. "We only tweaked one function" is not an exemption.
Do these and you can charge money, keep your app closed, and stay clean. Skip the relinking part because "it compiled fine" and you've quietly broken the one rule the LGPL actually enforces.
How to verify your build really complies
Don't trust what you assume your toolchain did. Check the binary. I've watched developers swear they linked dynamically while their build baked the whole library into the executable.
Run this first: ldd ./your-binary. It lists the shared libraries your program loads at runtime. If the LGPL library shows up there as its own .so, you're dynamic and the relinking duty is met. If it's not in that list, it was probably pulled in statically, and now you owe users a linkable form.
Cross-check with nm ./your-binary to see whether the library's symbols are compiled straight in, and read the actual link command in your build log. A -static flag or a .a archive on the link line changes your obligations no matter what the README claims. Check the output; that tells you the truth.
If you're shipping this inside kernel code, the license string you declare has teeth too. My notes on GPL compliance in kernel code cover where that bites. Everywhere else the rule holds: verify from the build output, not from what you meant to do.
FAQ
Is the LGPL a free software or open source license?
Both. The Free Software Foundation publishes it as a free software license, and it also meets the open source definition. It's copyleft, so not permissive like MIT or Apache, but it's genuinely open.
Does using an LGPL library make my app "open source"?
No. Linking one on its own doesn't touch your application's license. Your code can stay proprietary. Only the library and any changes you make to it live under the LGPL.
Can I sell software that uses LGPL code?
Yes. Charging money is fine. You meet the same duties you'd meet for a free release: relinking rights, source for the library, and the notices.
What happens if I fix a bug in the LGPL library?
Distribute the fixed version and you release the fix under the LGPL. Patches you keep internal and never ship don't trigger anything, but the moment it goes out the door, so does the source for your change.
Is LGPL 2.1 different enough from LGPL 3.0 to matter?
Yes, on patents and how combined works are handled. Treat them as separate licenses when you mix code, and read the version you actually ship under instead of assuming they swap in for each other.
