LGPL in Practice: The FFmpeg DLLs Inside Proprietary Products

LGPL in Practice: The FFmpeg DLLs Inside Proprietary Products

LGPL is the license everyone believes they understand: "it's fine in proprietary software as long as you link dynamically." That one-liner is roughly true and completely insufficient. The obligations are concrete and checkable, and anyone who has opened a vendor SDK folder knows they're routinely half-met in shipping commercial products.

FFmpeg is the most bundled LGPL codebase in existence, which makes it the perfect worked example. (Standard note: engineering guidance, not legal advice.)

The three obligations, concretely

Picture borrowing a screwdriver from a neighbor: you can use it for the project at hand, but it has to stay returnable and swappable at any time. That's the spirit of LGPL. Shipping an LGPL library inside a proprietary product commits you to three things:

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. Statically link that code into your binary and the replaceability argument collapses — along with your compliance.
3. Provide source for the LGPL parts. Not your application — the LGPL library itself, including any modifications you made to it. Unmodified upstream? A written offer or a link that reliably serves the exact corresponding source satisfies it.

What LGPL does not demand is opening your own application. 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 is perfectly legal when the three obligations are met. 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 moment your product loads the native library, the LGPL applies to your product with full force. 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 integrate a vendor SDK into your deliverable, you're redistributing everything inside it — 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.

It's an hour of work on most products. Compare that to renegotiating an architecture after an enforcement letter. LGPL is the manageable copyleft, but only for integrators who do the hour. Its aggressive sibling is a different story, which is why AGPL and commercial computer vision gets its own article.