There is no such thing as the FFmpeg license. There are three, and which one governs the code inside your product was decided by whoever typed the build command — possibly years ago, possibly in a base image you inherited, possibly by a distribution packager you have never met. All three builds answer to the name “FFmpeg.” All three come from one source tree. One ships under modest, checkable conditions. One drags your entire application into copyleft. One produces a binary that FFmpeg’s own build system calls unredistributable — you may run it; handing it to anyone else is a different matter.
This article is not legal advice and is no substitute for a lawyer. It is an engineering explainer about how a build flag changes a legal object. If you ship a product containing FFmpeg — an app, a server image, firmware, a mobile binary — the right next step is to put your actual configure line in front of counsel who does software licensing. What this piece can do is tell you which question to ask and where the evidence lives.
🪜 One Source Tree, Three Different Products
FFmpeg’s legal page opens with the sentence most engineers stop reading one clause too early: “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.“
That second sentence is the whole article in miniature. The licence of a given build is not a property of the project. It is a property of your build — an output of the configure invocation, computed from which optional components you switched on. The project’s own configure script says so in its “Licensing options” help text:
--enable-gpl allow use of GPL code, the resulting libs and binaries will be under GPL [no]--enable-version3 upgrade (L)GPL to version 3 [no]--enable-nonfree allow use of nonfree code, the resulting libs and binaries will be unredistributable [no]Three flags, all defaulting to off, each a rung on a ladder that only descends in terms of what you can do with the result. Climb a rung to get a feature you want; the obligations attached to the binary change underneath you.
| Rung | Build flag | The resulting build is | What FFmpeg’s own tooling says about redistributing it |
|---|---|---|---|
| 1 — Default | (none) | LGPL-2.1-or-later | Redistributable under LGPL-2.1+ terms — the ones FFmpeg’s legal page enumerates in an 18-point checklist |
| 2 — GPL | --enable-gpl | GPL-2.0-or-later | Redistributable under GPL terms; configure states “the resulting libs and binaries will be under GPL” |
| 2b — Version 3 | --enable-version3 | (L)GPL upgraded to v3 | Same shape as the rung it modifies, at version 3 of the licence |
| 3 — Nonfree | --enable-nonfree | Nonfree | Configure states the results “will be unredistributable” |
There is a fourth thing the legal page says that surprises anyone assuming every open-source project has a paid escape hatch: “Note that FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment.” You cannot buy your way off the ladder. There is no enterprise FFmpeg licence to purchase, because no single entity is positioned to sell one — the copyright is spread across hundreds of contributors who licensed their work in, not over.
⚖️ Rung One: LGPL-2.1-or-Later, and the Relink Test
The Lesser GPL exists to answer one question: how do you let proprietary software link a free library without the library’s copyleft swallowing it? LGPL-2.1’s Section 6 answers with a bargain. You may combine a “work that uses the Library” with the Library and “distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications.”
Then it names the price. You must do one of two things. Under 6(a), ship enough material — source or object code — “so that the user can modify the Library and then relink to produce a modified executable containing the modified Library.” Under 6(b), use “a suitable shared library mechanism,” defined as one that “uses at run time a copy of the library already present on the user’s computer system, rather than copying library functions into the executable,” and that “will operate properly with a modified version of the library, if the user installs one.”
Strip the legal register and one engineering test remains — call it the relink test. Can a user of your product swap in their own build of libavcodec and still have your product work? Dynamic linking passes almost for free. Static linking does not, unless you ship object files so a user can relink by hand. That is why “use dynamic linking” is item two on FFmpeg’s compliance checklist, and why statically linking FFmpeg into a mobile binary is the most common way well-meaning teams walk into trouble.
FFmpeg’s legal page does not leave the rest to interpretation. It publishes an 18-point checklist for LGPL compliance — an unusually concrete artefact from a project that otherwise declines to give legal opinions. The items cluster into four kinds of obligation.
| Obligation | What the checklist asks for | Engineering consequence |
|---|---|---|
| Build the right thing | Compile “without --enable-gpl and without --enable-nonfree“; ensure your program “is not using any GPL libraries (notably libx264)” | Your CI configure line is a compliance artefact — pin it, review it like code |
| Link the right way | “Use dynamic linking (on windows, this means linking to dlls)” | Static linking shifts you onto the 6(a) relink path and its extra obligations |
| Publish corresponding source | Distribute FFmpeg’s source “no matter if you modified it or not,” matching “exactly” the binaries you ship; git diff > changes.diff for your changes; “explain how you compiled FFmpeg, for example the configure line”; host it “on the same webserver as the binary” | The exact source revision and the configure line must be archived per release, not reconstructed later |
| Say so, visibly | Attribution with a working source link “to every page in your website where there is a download link”; the same in your “about box” and EULA; if the EULA claims ownership, “explicitly” disclaim ownership of FFmpeg; “remove any prohibition of reverse engineering from your EULA”; apply it to all translations | Legal, marketing and web all have to act — compliance fails at organisational seams, not technical ones |
Two items sit outside those buckets and reward a second read. Item 15: “Do not misspell FFmpeg (two capitals F and lowercase ‘mpeg’)” — FFmpeg is a trademark of Fabrice Bellard, who started the project in 2000. Item 16: “Do not rename FFmpeg dlls to some obfuscated name, but adding a suffix or prefix is fine (renaming avcodec.dll to MyProgDec.dll is not fine, but to avcodec-MyProg.dll is).” Vendors rename shipped libraries to hide dependencies constantly. FFmpeg noticed, and wrote it down.
The project has also historically maintained a public “Hall of Shame” at ffmpeg.org/shame.html for projects it considered non-compliant. Checked in August 2026, that page carries only the line “Shame page will be offline until entries are updated” — but its existence says the maintainers treat compliance as something they track publicly, not as boilerplate.
🔗 Rung Two: --enable-gpl and the Copyleft That Reaches Your Application
The LGPL’s whole point is that its reach stops at the library boundary. The GPL’s whole point is that it does not. Flip --enable-gpl and, in FFmpeg’s own words, “the GPL applies to all of FFmpeg” — and the GPL’s conditions attach to the work distributed as a whole, which is where a proprietary application’s problems begin.
Why would anyone flip it? Because the components behind that flag are the ones people actually want. Configure keeps an explicit EXTERNAL_LIBRARY_GPL_LIST, and reading it beats any amount of theory:
avisynth frei0r libcdio libdavs2 libdvdnavlibdvdread librubberband libvidstab libx264 libx265libxavs libxavs2 libxvidlibx264 and libx265 are on that list, which is how most teams reach rung two without a deliberate decision. x264 is the reference-grade H.264 encoder; x265 is the widely used HEVC encoder. If your pipeline encodes with -c:v libx264, you are running a GPL build. There is a subtler trap alongside it: FFmpeg’s LICENSE.md also places a set of filters under the GPL — vf_delogo, vf_hqdn3d, vf_nnedi, vf_boxblur and roughly two dozen more — so a build can land on rung two because of a denoiser in a filter graph rather than a codec.
Here the ladder stops being abstract and becomes a business model. Both encoders are dual-licensed, and the second licence exists precisely because the GPL boundary is real enough that companies pay to stand on the other side of it.
- x264 is VideoLAN’s project. Its official page states it is “released under the terms of the GNU GPL,” and adds: “In addition to being free to use under the GNU GPL, x264 is also available under a commercial license. Contact x264licensing@videolan.org for more details.”
- x265 is MulticoreWare’s project — worth stating precisely, because it is routinely misattributed. Its own documentation says “x265 is developed by MulticoreWare,” is available “for free under the GNU GPL 2 license,” and that “for commercial companies that wish to distribute x265 without being subject to the open source requirements of the GPL 2 license, commercial licenses are available.” x265 was built on x264 code licensed from VideoLAN, and VideoLAN’s own site lists x265 among the projects it hosts — a documented imprecision on VideoLAN’s part rather than a change of authorship. The primary attribution is MulticoreWare.
The clearest sign that large organisations take this boundary seriously is Chromium. The browser codebase carries its own copy of FFmpeg, and its README.chromium documents it as a manually merged fork carrying BSD-2-Clause, BSD-3-Clause, ISC, LGPL-2.1 and MIT licences — and no GPL. That is a deliberate architectural constraint, not an accident of packaging. If you have wondered why Chromium doesn’t simply bundle x264 and be done with it, that is the reason.
🚫 Rung Three: --enable-nonfree, the Build You Cannot Ship
The third rung differs in kind, not degree. GPL and LGPL are both free-software licences: they grant redistribution rights with conditions. Rung three grants no redistribution rights at all, because it mixes code whose licences cannot be satisfied simultaneously.
Configure’s EXTERNAL_LIBRARY_NONFREE_LIST is short and specific:
decklink libfdk_aac libmpeghdeclibfdk_aac is Fraunhofer’s FDK AAC encoder, widely regarded as the best-sounding AAC encoder available to FFmpeg. decklink is Blackmagic Design’s capture-and-playback SDK — the standard way to get professional SDI video into a pipeline. Neither is exotic; both are what a working broadcast or streaming engineer reaches for. FFmpeg’s LICENSE.md explains the mechanism in a section on incompatible libraries: licences like Fraunhofer’s are incompatible with the GPL, so a build combining them needs --enable-nonfree, whose help text spells out the result — “the resulting libs and binaries will be unredistributable.”
The binary will tell you itself. ffmpeg -L prints the licence of the build in your hand, and the source of that command carries a branch for exactly this case. On a nonfree build it prints:
This version of ffmpeg has nonfree parts compiled in.Therefore it is not legally redistributable.That is not a warning buried in documentation. It is the program, asked its licence, declining to claim one. Every other branch of that function prints a full GPL, LGPL, GPLv3 or LGPLv3 notice with a redistribution grant in its first sentence. The nonfree branch prints two lines and stops.
One rung-adjacent flag is worth knowing. --enable-version3 upgrades the applicable licence from version 2 to version 3, with its own lists: EXTERNAL_LIBRARY_VERSION3_LIST (gmp, libaribb24, liblensfun, the libopencore_amr* codecs, libvo_amrwbenc, mbedtls, rkmpp) and EXTERNAL_LIBRARY_GPLV3_LIST (libsmbclient). GPLv3’s anti-tivoisation and patent provisions matter to hardware vendors in particular, which is why embedded teams sometimes care intensely about a flag desktop developers have never noticed. These lists change between releases: the authoritative version is the configure script and LICENSE.md in the tarball you actually built.
🔍 How to Check What You Actually Shipped
None of this helps if you cannot determine which build you have. FFmpeg is unusually forthcoming, and three documented options answer the question in seconds:
ffmpeg -version— “Show version.” The banner includes aconfiguration:line listing every flag the binary was built with.--enable-gplor--enable-nonfreewill be sitting there in plain sight if they are there at all.ffmpeg -buildconf— “Show the build configuration, one option per line.” The same information, formatted forgreprather than for humans.ffmpeg -L— “Show license.” The definitive answer, printed by the binary about itself.
Run all three against every FFmpeg your product touches, including the ones you did not knowingly install. That last clause is the hard part, because FFmpeg’s defining characteristic is that it arrives inside other software.
| How FFmpeg got in | What you probably inherited | What to check |
|---|---|---|
Distribution package (apt, dnf, Homebrew) | A packager’s build; distributions differ, and some ship deliberately reduced variants | ffmpeg -buildconf on the exact package version you deploy |
| A container base image | Whatever the image author configured — frozen at build time and now yours to distribute | Run the three commands inside the image, not on your laptop |
| A language wrapper (npm, PyPI, Go, crates) | Often a prebuilt static binary or bundled shared libraries fetched at install time | Find the vendored binary on disk; check its licence, not the wrapper’s |
A mobile SDK or prebuilt .framework/.aar | Very often statically linked, the case LGPL-2.1 §6(a) governs | Whether relinking is possible for your users, and what the vendor’s licence claims |
| Your own CI | Your configure line — the one artefact you fully control | Pin it, archive it per release, diff it in code review |
The recurring failure mode is not malice; it is inheritance. A team pulls a base image that already contains a --enable-gpl --enable-libfdk-aac --enable-nonfree build because someone once needed good AAC, ships that image to customers for two years, and never runs ffmpeg -L. This is the same class of problem as any other software supply-chain exposure: the risk lives in a transitive dependency nobody in the room chose. The difference is that here the answer takes one command, and the binary is willing to give it.
🧩 The Twist: None of This Touches Patents
Now the part that surprises nearly everyone, including engineers who have read the LGPL end to end.
Copyright licensing and patent licensing are two separate legal systems. Different parties grant them, they cover different things, and they are satisfied independently. A perfectly LGPL-compliant FFmpeg build — dynamic linking, source published, EULA fixed, all 18 checklist items green — has resolved exactly one of the two. It says nothing about whether the codec it implements is covered by patents, who holds them, or what they cost.
FFmpeg’s maintainers do not hedge. Asked on their own legal page whether FFmpeg uses patented algorithms, they answer: “We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of FFmpeg, so even if we were qualified we could not answer it as we do not know what is patented.” They add that “the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no, those who do lie,” and that “patent laws vary wildly between jurisdictions, and in many countries patents on algorithms are not recognized.”
| Copyright licence (LGPL / GPL / nonfree) | Patent licence | |
|---|---|---|
| What it governs | Copying, modifying and distributing a specific implementation — this source, these binaries | Practising a claimed technique, regardless of whose code implements it |
| Who grants it | The copyright holders — for FFmpeg, hundreds of individual contributors | Patent holders, often through administered pools, often also individually |
| How you comply | Follow the conditions in the licence text; FFmpeg publishes a checklist | Obtain a licence, determine you need none, or accept the exposure — a legal analysis, not a build flag |
| What a compliant build gives you | Permission to distribute the code | Nothing |
| What “open source” tells you | A great deal | Nothing |
| Where the answer lives | configure, LICENSE.md, ffmpeg -L | Outside the project entirely |
The same page draws a practical line between two audiences. On personal use: “Are you a private user working with FFmpeg for your own personal purposes? If so, there is remarkably little reason to be concerned.” On commercial use, describing companies that shipped FFmpeg in products: “These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees.” (That is the page’s wording as of August 2026; see the caution below about named administrators.)
How the patent layer is structured
You do not need to track every pool to understand the shape of the problem: a patent pool aggregates patents that multiple holders claim are essential to a standard and offers implementers one licence covering that bundle. Its usefulness depends entirely on how much of the relevant landscape it actually covers.
- H.264/AVC was licensed largely through a single administered pool — a substantial part of why it became the internet’s default video codec. One pool means one negotiation and one number.
- HEVC/H.265 ended up with multiple competing pools plus rights holders affiliated with none of them. The problem was never any single pool’s per-device rate; it was that no implementer could compute a ceiling on total exposure before shipping. Uncertainty about a liability’s size is often more paralysing than a known cost, and that fragmentation is the most common explanation for why the open web largely skipped HEVC despite its efficiency.
- AV1 was designed by the Alliance for Open Media (founded September 2015; AV1 finalised March 2018) to avoid a repeat. AOMedia publishes a royalty-free patent license that is reciprocal — accepting it obliges you to license your own essential claims back — and terminates against anyone who sues a fellow implementer. That position is contested. Sisvel operates a competing AV1 programme offering, in its own words, “royalty-bearing, non-transferable, non-assignable, non-exclusive licences…to patents related to the AV1 specification” (programme page, checked August 2026). Litigation involving AV1-related patents was reported active during 2026. Both positions are on the record; this article declares no winner.
⚠️ One caution, stated plainly: pool membership and pool administration change. Pools are acquired, merged, renamed and reorganised; rights holders join and leave; the entity administering a standard’s licensing programme today may not be the one named in an article, a wiki, or even a project’s own documentation. Reporting during 2025 described a consolidation among the HEVC/VVC pools that is not straightforwardly reflected on the affected administrators’ own live pages. This article deliberately does not assert who administers what today. If that answer bears on a decision you are making, the only reliable sources are the pools’ own current programme pages, read on the day you need them — and, again, a lawyer.
📦 What Bundling Actually Means
Three shipping shapes cause most of the confusion, and they differ in ways engineers can reason about directly.
A desktop or server application is the classic LGPL case the 18-point checklist was written for. Dynamic linking, a source tarball hosted alongside the binary, attribution on the download page and in the about box, an EULA that does not prohibit reverse engineering. Every item is achievable; most failures are organisational — the web team never added the link, or the EULA template came from a lawyer who never saw the configure line.
A container image is harder to hand-wave, because distributing an image means distributing every binary inside it. If your published image contains an FFmpeg built with --enable-gpl, GPL-covered code is in the artefact you hand to users alongside your own application. “We just used the official base image” stops being an answer here, because a container image is a shipped bundle of software, not a development convenience — and whatever is inside it comes along when you docker push.
A mobile binary is the hardest case. Mobile toolchains and app-store packaging push hard toward static linking, which is exactly the scenario LGPL-2.1 §6(a) addresses with its relink requirement — in an environment where users cannot relink an app-store binary at all. Teams shipping FFmpeg inside iOS and Android apps have spent years working through what satisfying that requirement looks like. There is no consensus you can copy off a forum, which is precisely why this is a question for counsel rather than for Stack Overflow.
Underneath all three sits a fact worth sitting with. FFmpeg is inside browsers, phones, televisions, editing suites, streaming platforms and spacecraft, and it is maintained by a small group of people, largely volunteers, funded through a patchwork of donations and grants — the same structural story as the funding behind other critical open infrastructure. The licence ladder is one of the few levers that community holds for setting terms with the enormous commercial ecosystem downstream of it. Reading it carefully is not only risk management; it is the minimum the arrangement asks for.
To restate the disclaimer this piece opened with: none of the above is legal advice. It is a map of where the evidence lives — FFmpeg’s legal page, its configure script, its LICENSE.md, the licence texts themselves, and the output of ffmpeg -L. Bring that evidence to a lawyer. Do not bring an article.
❓ Frequently Asked Questions
What is the FFmpeg license, exactly? It depends on the build. The default is the GNU Lesser General Public License version 2.1 or later. Adding --enable-gpl activates GPL-covered components, and FFmpeg’s legal page states that when those parts are used, “the GPL applies to all of FFmpeg.” Adding --enable-nonfree pulls in code whose licence is incompatible with the GPL, and the configure help says the resulting libraries and binaries “will be unredistributable.” One source tree, three different legal objects.
How do I tell which FFmpeg build I have? Three commands. ffmpeg -version prints a banner including a configuration: line with every build flag; ffmpeg -buildconf prints the same one option per line; ffmpeg -L prints the licence of that specific binary — and on a nonfree build it prints “This version of ffmpeg has nonfree parts compiled in. Therefore it is not legally redistributable.” Run them inside the container or on the device, not on a developer laptop, since those are frequently different builds.
Does using x264 or x265 change my obligations? Both sit on FFmpeg’s EXTERNAL_LIBRARY_GPL_LIST, so building either requires --enable-gpl. Both are also dual-licensed: x264 is VideoLAN’s, GPL with a commercial option through x264licensing@videolan.org; x265 is MulticoreWare’s, GPL-2 with commercial terms through license@x265.com. Those commercial programmes exist because the GPL boundary is consequential enough that companies pay to be on the other side of it. What it means for your specific product is a question for a lawyer.
If my build is fully LGPL-compliant, am I clear on patents? No — they are separate systems. A copyright licence governs copying and distributing a particular implementation; a patent licence governs practising a claimed technique, no matter whose code implements it. FFmpeg’s own maintainers say of patented algorithms: “We do not know, we are not lawyers so we are not qualified to answer this.” Complying with the LGPL resolves the copyright question and leaves the patent question entirely untouched.
Can I buy a commercial licence for FFmpeg itself? FFmpeg’s legal page states that FFmpeg “is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment.” Its copyright is held by a large number of individual contributors, so no single party is positioned to offer alternative terms for the project as a whole. Individual external libraries such as x264 and x265 do offer separate commercial licences from their own copyright holders — covering those libraries, not FFmpeg.
Is AV1 actually royalty-free? That is the Alliance for Open Media’s position, published as its AV1 Patent License 1.0 — a royalty-free, reciprocal grant that terminates against anyone suing a fellow implementer. It is contested: Sisvel operates a competing AV1 programme offering royalty-bearing licences to “patents related to the AV1 specification,” and AV1-related patent litigation was reported active during 2026. Both positions are on the record. Anyone telling you the question is settled is ahead of the evidence.
📚 Further Reading
- What Is a Container? The Idea That Powers Modern Software (and AI) — why publishing an image means distributing every binary inside it, the mechanism that turns a base-image choice into a licensing one.
- What Is Chromium? The Open-Source Engine Behind Chrome — the clearest real-world case of an organisation keeping its media stack deliberately off the GPL rung, documented in Chromium’s own
README.chromium. - MCP Server Supply Chain Security: Hardening Agent Skills — the same failure mode in another domain: the dependency carrying your obligations is usually the one nobody chose.
- Who Pays for Tor? The Funding Paradox Behind Anonymous Browsing — the funding-and-governance question underneath every widely deployed open-source component, FFmpeg very much included.
- Primary sources, in the order to read them: FFmpeg’s legal page (the 18-point checklist and the patent answer),
LICENSE.mdand theconfigurescript from the version you actually built, and the LGPL-2.1 text — Section 6 in particular.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Start with the free material, because on this subject it is genuinely better than the books. Every load-bearing claim in this article came from a document you can read right now for nothing: FFmpeg’s legal page with its 18-point checklist and its patent answer; the configure script and LICENSE.md in the version you actually built; and the canonical licence texts themselves — LGPL-2.1 and GPL-2.0. Section 6 of the LGPL is two screens long and answers more questions than any commentary on it. For the sustainability half of the story, Nadia Eghbal’s Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (Ford Foundation, 2016) is a free PDF and remains the best single report on who maintains the code everything else is built on.
The books below earn their place where a print treatment goes deeper than a spec page.
Working in Public: The Making and Maintenance of Open Source Software
Nadia Asparouhova · Stripe Press, 2020 · Paperback
The best book-length account of the arrangement this article’s licence ladder sits inside: who actually maintains widely used open-source projects, what they are and are not obliged to do, and why the economics keep producing small maintainer teams under enormous downstream demand. Read it if the closing section — FFmpeg inside browsers, phones, televisions and spacecraft, maintained largely by volunteers — is the part that stuck with you. (The same author’s earlier free report, Roads and Bridges, circulates under the name Nadia Eghbal.)
Coding Video: A Practical Guide to HEVC and Beyond
Iain E. Richardson · Wiley · Hardcover, 448 pp
If the patent half of this article is what you want to go deeper on, you first need to understand what a codec standard actually specifies — because that is the thing patent claims attach to. Richardson is the standard practical guide to HEVC’s coding tools. One honest caveat carried from the research behind this series: despite the “and Beyond” in the title, the listing does not promise substantive AV1 or VVC coverage. For those two, the free AOMedia AV1 specification and the ITU-T recommendations are the material — no mature book literature exists for either.