LGPL in Practice: The FFmpeg DLLs Inside Proprietary Products

LGPL permits libraries to be used in proprietary software under specific conditions. Dynamic linking can support component replacement, but it does not remove obligations to provide license texts and matching source. Check the applicable license version and the way the product is distributed.

FFmpeg is commonly bundled in commercial products, so it is a useful worked example. (Standard note: engineering guidance, not legal advice.)

The three obligations, concretely

When shipping an LGPL library inside a proprietary product, check these three obligations under the applicable version:

1. Ship the license text. The LGPL text, plus the copyright notices, travels with the product — an installer folder, an about screen, a licenses/ directory. Trivial, and still the most commonly skipped step.
2. Keep the component replaceable. The user must be able to swap the LGPL library for their own build. Dynamic linking is the classic mechanism: if avcodec-61.dll sits next to your executable, a user can rebuild FFmpeg and drop their DLL in. Static linking can also comply, but requires a relinking route, such as object files and materials that let users rebuild with a modified library, under the applicable LGPL version.
3. Provide source for the LGPL parts. Not your application — the LGPL library itself, including any modifications you made to it. The method must match the license version and distribution route. The official FFmpeg checklist calls for the exact matching source, changes, and build instructions. A link to a generic upstream page is not evidence of compliance.

Also check your end-user terms: the FFmpeg checklist requires removing restrictions on reverse engineering. The applicable LGPL version defines the rights needed for modification and debugging.

LGPL can permit your application to remain closed when its conditions are met. That's the entire point of the license — and why the boundary rules above are worth getting exactly right.

The DLLs sitting next to closed binaries

Install a proprietary access-control suite, a CCTV video management system, or a kiosk platform and look inside the program folder. You'll very often find avcodec.dll, avformat.dll, avutil.dll, swscale.dll (FFmpeg) sitting next to fully closed executables. That arrangement can comply when all applicable license conditions are met; the three checks above are a starting point. In practice, the license text is frequently missing, and asking the vendor for the corresponding FFmpeg source produces silence.

One subtlety multiplies the risk: FFmpeg's license depends on how it was built. A default build is LGPL; configure it with --enable-gpl (for x264 and friends) and the whole build becomes GPL — a different license with obligations no proprietary product can meet by shipping a DLL. Nonfree flags make the build undistributable entirely.

So "which FFmpeg build did the vendor ship?" isn't pedantry. It decides which license you're actually subject to.

The MIT wrapper illusion

The npm ecosystem adds a modern trap. A package can be MIT-licensed, look spotless in every license scanner, and be nothing but a thin binding over an LGPL native library. The libgphoto2-style camera control wrappers are a classic of the genre, and the FFmpeg wrapper packages behave identically. The wrapper's MIT license covers the JavaScript glue and nothing else.

The native library retains its LGPL license. Your obligations depend on how the product links to it and whether you distribute the library or a combined work. Scanners that read package.json files can't see this — the check that works is looking at what the process actually loads at runtime, the .so and .dll files, not the manifests. I've covered where this fits among the other license traps in open-source licenses in commercial software.

The vendor's gaps become your gaps

Here's the part that turns an abstract compliance question into a commercial one. When you bundle a vendor SDK in your deliverable, you are redistributing the components you include — including the LGPL binaries the vendor bundled and whatever obligations they left unmet.

A due-diligence review of your product will find their missing license texts, and "the vendor shipped it that way" is not a defense available to you. You're the distributor now. The time to fix this is contract time: compliance statements and redistribution rights in the supply agreement, before the SDK is welded into your architecture.

The integrator's checklist

Before any delivery that bundles native code, mine runs like this: inventory every .dll and .so in the package, including the ones a vendor SDK dragged in. Identify each one's actual license, which for FFmpeg means identifying the build configuration. Verify the three obligations for everything LGPL, then put the vendor's compliance in writing where it's missing.

A review before delivery helps avoid costly architecture changes after a licensing problem is found. Keep the compliance evidence complete. Other license risks are discussed in AGPL and commercial computer vision.

What should you request from the vendor?

Ask for component versions, FFmpeg configuration, license texts, and the route to matching source. The vendor should also demonstrate replacement of the LGPL parts under the chosen mechanism. Keep that evidence with the handover package.