Can I use an LGPL library in proprietary software?

Yes — and how you link decides what you owe. "Library copyleft. Dynamic linking lets proprietary code use it freely. Static linking requires you to enable user relinking (provide object files or use dynamic). Modifications to the library itself must be published under LGPL. Can be upgraded to GPL." The sections below separate the dynamic and static cases, with obligations generated by the same engine that powers the checker.

Can I use an LGPL library in proprietary software?

Yes. Copyleft is scoped to the library — your own application code can stay proprietary. Publish modifications to the library itself. Static linking requires a relink path for users.

Does dynamic linking change my obligations?

Dynamic linking is the low-obligation path: proprietary code can use the library with only the relink and notice duties. Your application code is unaffected; obligations attach to the library itself.

Dataset rule for dynamic linking: "LGPL: dynamic linking lets proprietary code use the library with only the relink/notice duties. GPL: still copyleft on the combined work in most readings. Permissive: notices only."

What does static linking require?

Static linking obliges you to let users relink your application against a modified version of the library — ship your object files, or switch to dynamic linking. This is the one obligation that surprises teams shipping statically linked binaries.

Dataset rule for static linking: "Matters for LGPL: static linking obliges you to let users relink against a modified library (ship object files or switch to dynamic). For GPL, linking method does not change the copyleft outcome. Permissive and MPL/EPL: scoped to their own files regardless of linking."

The engine's obligations for LGPL-2.1 under each linking model:

Dynamic linking

LGPL-2.1: retain the copyright notice and license text.
LGPL-2.1: state significant changes made to the code.
LGPL-2.1: publish the source of any modifications to the library itself.
LGPL-2.1: modifications to the library must remain under LGPL-2.1.

Static linking

LGPL-2.1: retain the copyright notice and license text.
LGPL-2.1: state significant changes made to the code.
LGPL-2.1: publish the source of any modifications to the library itself.
LGPL-2.1: modifications to the library must remain under LGPL-2.1.
LGPL-2.1: provide object files or another mechanism so users can relink against a modified version of the library.

Do I have to publish my source code?

Only modifications to the library itself. Code that links against the library is not affected, subject to the linking terms.

Does running LGPL software as SaaS require disclosure?

No. Hosting is not distribution under LGPL-2.1; running it as a service does not trigger source disclosure.

Is LGPL-3.0 different from LGPL-2.1 here?

The linking rules are the same. LGPL-3.0 adds GPLv3-era terms — an express patent grant and anti-tivoization — so the version choice matters for patents and locked-down devices, not for how you link.

Version	Express patent grant	In short
LGPL-2.1	No	Library copyleft. Dynamic linking lets proprietary code use it freely. Static linking requires you to enable user relinking (provide object files or use dynamic). Modifications to the library itself must be published under LGPL. Can be upgraded to GPL.
LGPL-3.0	Yes	Like LGPL-2.1 with GPLv3-era patent and anti-tivoization terms. Same linking rules.

Is static linking to GPL code the same story?

No. For GPL, linking method does not change the copyleft outcome — the combined work is GPL on distribution whether you link statically or dynamically. The library-friendly scoping is what LGPL adds.

The GPL side is covered in Can I use GPL code in a commercial product?