LGPL License Explained — Plain English Guide (Lesser GPL & Proprietary Use)

The GNU Lesser General Public License (LGPL) is a weak copyleft license that lets proprietary software use LGPL-licensed libraries without open-sourcing the consuming application — making it the go-to choice for libraries that want both community contributions and corporate adoption. It powers glibc, FFmpeg, and formerly Qt framework.

What You’ll Learn

By the end of this guide, you’ll understand how the LGPL’s linking exception works, when you can use LGPL code in proprietary software, what happens if you modify LGPL code, and how to choose between LGPL, GPL, and MIT for your own projects.

Why It Matters

The LGPL sits in a sweet spot between the strong copyleft of the GNU GPL and the permissiveness of the MIT License. It’s designed specifically for libraries — code that other projects depend on. Using LGPL incorrectly can force you to open-source your own code. Using it correctly lets you build commercial products on top of battle-tested libraries. This distinction affects millions of developers who use LGPL-licensed libraries every day.

Real-World Use

Your company’s mobile app uses an LGPL-licensed video encoding library to compress user-uploaded videos. You link to the library as a shared dynamic library (.so/.dll/.dylib). Your app stays proprietary, and your business logic remains closed-source. If you had statically linked the same library instead, you’d need to provide your users with the object files to relink with updated library versions. That’s the LGPL’s linking exception in action.

Quick Reference

What the LGPL Actually Says

The LGPL is the GNU GPL with a special exception for libraries. Think of it as “GPL + linking exception.” The core copyleft rules still apply to the library itself, but the exception carves out how other code can use it.

The Linking Exception

The critical difference from the GPL is how linking works:

• Dynamic linking: If your proprietary application dynamically links to an LGPL library (loading it at runtime as a .so, .dll, or .dylib), your application is considered a “work that uses the library” — not a derivative work. Your code stays proprietary.
• Static linking: If you statically link the LGPL library into your binary, your application is a derivative work of the library. You must provide the object files so users can relink your application with a modified version of the library.

What You Must Provide

When you distribute LGPL code (modified or not), you must provide:

1. The source code for the LGPL-licensed library itself (including your modifications)
2. A copy of the LGPL license
3. Copyright notices
4. If statically linked: the object files or relinkable intermediate files so users can recompile the library and relink your application

Section 6(d) — The Relink Provision

This is the most technically important part of the LGPL:

If you convey a copy of a modified library, or a work that uses the library, you must also provide… the Corresponding Application Code — the material you need to install and run modified versions of the library in connection with the work.

For static linking, this means you must provide your application’s object files (or equivalent) so a user can replace the library and relink. For dynamic linking, this requirement evaporates.

Can I Use LGPL Code in Commercial Products?

Yes — if you follow the linking rules. The LGPL explicitly allows commercial use. Here’s the breakdown:

You Can Always:

• Use LGPL libraries in proprietary commercial products
• Sell products that include LGPL code
• Distribute LGPL code alongside your proprietary code
• Modify LGPL code for your own use (internally)

You Must Do:

• If you distribute modified LGPL code: release your modifications under LGPL
• If you statically link: provide object files for relinking
• If you dynamically link: your proprietary code is not affected
• Include the LGPL license text and copyright notices

The “Distribution” Trigger

Like the GPL, LGPL obligations only activate when you distribute the software. Using LGPL code internally? No obligations. Shipping it to customers? Obligations apply.

Real-World Projects Using LGPL

LGPL vs GPL vs MIT — When to Use Which

The LGPL is the pragmatic compromise: it gives library authors copyleft protection on their work while allowing proprietary software to benefit from it.

Common Misconceptions

“LGPL means my whole app must be open source”

No — only the LGPL-licensed library itself and any modifications you make to it. Your proprietary code that links to the library is not affected (under dynamic linking).

“I can’t charge money for LGPL software”

You absolutely can. Commercial use is explicitly permitted. You can sell products that include LGPL code, charge for support, and build a business around it.

“Static linking is banned under LGPL”

Not banned — it’s allowed, but with additional obligations. You must provide object files or equivalent so users can relink. In practice, most commercial projects prefer dynamic linking to avoid this requirement.

“LGPL and GPL are interchangeable”

This is a dangerous misconception. Using GPL code in a proprietary product forces you to open-source the entire work. Using LGPL code in the same way (with dynamic linking) does not. They are fundamentally different.

“LGPL doesn’t apply if I don’t modify the library”

Even unmodified LGPL code has obligations when distributed. You must include the license text, copyright notices, and (for static linking) relinkable object files. But you don’t need to release your proprietary source code.

LGPL Compliance Scenarios

Scenario 1: Mobile App with LGPL Library (Dynamic Link)

Your iOS/Android app bundles an LGPL-licensed image processing library as a dynamic framework.

• Obligations: Include LGPL license text, copyright notices
• Not required: Open-source your app, provide object files
• Verdict: Standard, low-effort compliance

Scenario 2: Static Linking in Embedded Device

Your embedded Linux device statically links glibc (LGPL) into a single firmware binary.

• Obligations: Provide glibc source, your modifications to glibc, and object files/relinkable archive to allow firmware rebuild with modified glibc
• Not required: Open-source your application code
• Verdict: More work, but feasible

Scenario 3: SaaS Using LGPL Database Driver

Your web app uses an LGPL-licensed PostgreSQL driver.

• Obligations: None — you’re running on your server, not distributing
• Not required: Anything
• Verdict: No compliance work needed

When to Choose LGPL

Choose LGPL for your own projects when:

• You’re building a library (not an application)
• You want corporate adoption but with copyleft protection on the library itself
• You want contributors to share their improvements to the library
• You don’t mind proprietary software using your library (you want adoption)

Avoid LGPL when:

• You want maximum adoption with zero friction (choose MIT License)
• You want the strongest copyleft protection (choose GNU GPL)
• You’re building an application, not a library (GPL is more appropriate)
• Patent protection matters (choose Apache License 2.0)

FAQ

LGPL vs Other Licenses

graph LR
    A[Permissive
MIT / BSD / Apache] --> B[Weak Copyleft
LGPL / MPL]
    B --> C[Strong Copyleft
GPLv3]
    C --> D[Network Copyleft
AGPLv3]
    style A fill:#90EE90
    style B fill:#FFD700
    style C fill:#FFA500
    style D fill:#FF6B6B

Practice Questions

1. Your startup builds a mobile game that dynamically links to an LGPL audio library. Do you need to open-source your game? No. Dynamic linking means your game is a “work that uses the library” — not a derivative work. Your game stays proprietary. Include the LGPL notice.

2. You modify an LGPL-licensed graphics library to fix a bug, then distribute the modified library with your commercial app. What must you do? Release your fix under LGPL. Include the modified library source code with your distribution. Your proprietary app code is not affected.

3. Your embedded device statically links LGPL libraries into firmware. Your competitor wants to use a newer library version. What must you provide? The object files or relinkable archives of your application, plus the LGPL library source and any modifications. The competitor can then rebuild the firmware with a different library version.

4. Can a company take your LGPL-licensed library, modify it, and sell it as part of a proprietary product? Yes — but they must release their modifications to the library under LGPL, include the LGPL license, and (if statically linked) provide object files. Their proprietary code around the library stays private.

5. You use glibc (LGPL) in your SaaS product. Do you have any obligations? None. Running LGPL code on your servers does not constitute distribution. No source release, no license inclusion, no object files needed.

Mini Project: LGPL Linking Analysis

1. Create a simple C program that uses an LGPL library (e.g., glibc functions)
2. Build it with both static and dynamic linking:
   • gcc -static -o myapp-static myapp.c
   • gcc -o myapp-dynamic myapp.c
3. Run ldd myapp-dynamic to see the dynamically linked libraries
4. For the static build, determine what you’d need to provide for LGPL compliance
5. Write a compliance checklist for distributing each binary

Challenge: Find a real-world open-source project that chose LGPL over GPL or MIT. Read their license selection discussion in the project’s documentation or issue tracker. Write a brief analysis of why LGPL was the right choice for them.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. This guide is for educational purposes and does not constitute legal advice. Consult an attorney for specific licensing questions.