FFmpeg is widely known as a "free" tool. But the moment you try to use it commercially, things get significantly more complicated.
"What is LGPL?" "Do I need to pay patent fees for H.264?" "Can I embed it in a SaaS product?"—the answers to these questions are scattered and inconsistent across the internet.
This article breaks down the full picture of FFmpeg licensing so you can make informed decisions for commercial use. It's written from the perspective of developers and businesses actually using FFmpeg, not legal counsel.
FFmpeg is "Free" but Not "Unrestricted"
FFmpeg is open-source software with publicly available source code. "Free" in the sense of cost—yes. "Free to use however you want"—that's a different question.
FFmpeg is a collection of libraries, each carrying its own license.
| Library | Purpose | Default License |
|---|---|---|
| libavcodec | Encoding & decoding | LGPL 2.1 or later |
| libavformat | Container I/O | LGPL 2.1 or later |
| libavfilter | Filter processing | LGPL 2.1 or later |
| libswscale | Scaling | LGPL 2.1 or later |
| libswresample | Audio resampling | LGPL 2.1 or later |
| libpostproc | Post-processing | GPL 2 or later |
The phrase "default license" is key. Depending on build-time options, the license can shift from LGPL to GPL. This is the core of FFmpeg's licensing complexity.
Separately from the license, patent issues also exist. Using H.264 or H.265 may require patent licensing from organizations like MPEG-LA—completely independent of FFmpeg's open-source license.
LGPL vs GPL: What's the Difference?
LGPL and GPL are both free software licenses, but their implications for commercial use differ significantly.
LGPL (Lesser GPL):
LGPL is called "weak copyleft." When you link FFmpeg's LGPL libraries into your application using dynamic linking, you are not required to open-source your own application code. However, you must meet these conditions:
- Provide a way for users to replace the FFmpeg library portion
- Display FFmpeg's full license text and attribution
- Publish the source of any modifications you made to FFmpeg itself
GPL (General Public License):
GPL is "strong copyleft." Incorporating GPL-licensed code into your application makes the entire application GPL. This means you must release your application's source code under the GPL.
For commercial proprietary software, this is often a fatal constraint—most business models depend on keeping source code private.
A Complete List of Options That Trigger GPL
The following configure options enable code under GPL or more restrictive licenses. Using any of them changes the license of your entire FFmpeg build.
Options That Enable GPL
| Option | What It Includes | Notes |
|---|---|---|
--enable-gpl | x264, x265, xvid, etc. | This flag itself declares GPL |
--enable-libx264 | H.264 encoder (x264) | GPL 2 or later |
--enable-libx265 | H.265 encoder (x265) | GPL 2 or later |
--enable-libxvid | MPEG-4 encoder | GPL 2 or later |
--enable-libvpx | VP8/VP9 encoder | LGPL, but check combinations |
--enable-frei0r | Video filter plugins | GPL 2 or later |
--enable-librubberband | Pitch/tempo shifting | GPL 2 or later |
--enable-libvidstab | Video stabilization | GPL 2 or later |
Non-Free License Options (--enable-nonfree)
| Option | What It Includes | Notes |
|---|---|---|
--enable-libaacplus | HE-AAC encoder | Not redistributable |
--enable-libfdk-aac | FDK-AAC encoder | Redistribution restrictions |
--enable-openssl | HTTPS support | Apache/SSLeay, commercially OK |
A build with --enable-nonfree cannot be redistributed at all. Using it on your own server for internal purposes is acceptable, but distributing the binary to others is not.
How to Check the License of a Build
To verify which license a compiled FFmpeg binary falls under, run:
ffmpeg -version
Look for the License: line in the output.
# Example output (LGPL build)
# License: LGPL version 2.1 or later
# Example output (GPL build)
# License: GPL version 2 or later
The Patent Trap: H.264 and H.265 (MPEG-LA)
Entirely separate from FFmpeg's open-source license, codec patents are their own problem.
H.264 (AVC) Patent Status:
MPEG-LA manages the patent pool. Using H.264 in products or services may require a license fee depending on volume, number of users, and whether the content is paid or free. Certain exemptions existed for free internet streaming, but these conditions may change. The landscape beyond 2027 is uncertain.
H.265 (HEVC) Patent Status:
More complex than H.264. Multiple patent pools exist (MPEG-LA, HEVC Advance, Velos Media), each potentially requiring separate licensing. The H.265 patent environment is widely considered more fragmented and problematic than H.264's.
Realistic Risk Assessment:
Individual developers and small startups are rarely pursued by patent pool holders, but large-scale commercial services cannot ignore this risk. If safety is a priority, choosing patent-free codecs like AV1 or VP9 is the best course of action.
How to Build a Safe Commercial Binary
The guiding principle for a commercially safe FFmpeg build is to stay within LGPL. Concretely: build without --enable-gpl and --enable-nonfree.
Here is a configure example for an LGPL-compliant, commercially safe build:
./configure \
--prefix=/usr/local \
--disable-static \
--enable-shared \
--enable-libvorbis \
--enable-libopus \
--enable-libvpx \
--enable-libdav1d \
--enable-libaom \
--enable-libwebp \
--enable-libfreetype \
--enable-libfontconfig \
--enable-libass \
--disable-gpl \
--disable-nonfree
The codecs and formats available in this build:
| Codec | License | Use Case |
|---|---|---|
| AV1 (libaom, libdav1d) | BSD-style | Video encoding (next-gen) |
| VP8/VP9 (libvpx) | BSD | Video encoding (web) |
| Opus (libopus) | BSD | Audio encoding |
| Vorbis (libvorbis) | BSD | Audio encoding (legacy) |
| WebM | Patent-free | Container |
| WebP (libwebp) | BSD | Still images |
Dynamic Linking vs Static Linking:
Building with --enable-shared (dynamic linking) is recommended. It more easily satisfies LGPL's requirement that users can replace the library. Static linking is not impossible, but you'll need to separately provide a mechanism for library replacement.
FAQ: SaaS, Server-Side Usage, and Output Copyright
Can I use FFmpeg in a SaaS product?
If you run an LGPL build of FFmpeg on your server and offer it as a service to users, you are not required to open-source your application. LGPL's "linking" concept concerns software distribution—operating a SaaS service is not distributing the library itself.
You are still required to:
- Display FFmpeg's LGPL license attribution (e.g., on an About or Licenses page)
- Document the version and components of FFmpeg you use
What if I only run FFmpeg server-side and never distribute the binary?
If you run FFmpeg on your server without distributing the binary externally, using a GPL build generally does not trigger the source disclosure obligation—this is commonly known as the "ASP loophole." The exception is AGPL-licensed code, which closes this loophole.
Who owns the copyright of video files I produce with FFmpeg?
The copyright of the output belongs to whoever created the content—you. FFmpeg is a tool. Using a tool to create something does not grant the tool's license any claim over the resulting work.
Where can I get a redistributable FFmpeg build for Windows?
Pre-built LGPL-compliant binaries from third parties are an option. See How to Get a Redistributable FFmpeg Build for Windows for details. For Linux server setups, Setting Up a Redistributable FFmpeg Build on Linux is a useful reference.
Real-World Cases Where This Became a Problem
Here are some notable cases where FFmpeg licensing or codec patents created real issues. These are general overviews of publicly known situations.
VideoLAN (VLC) and H.264/H.265 Patent Issues:
VLC, like FFmpeg, is an open-source video tool. It was once the target of litigation in France from H.264 patent holders. The case was ultimately resolved, but it remains a well-known example of the real-world risk codec patents carry.
Streaming Services and HEVC Advance:
Multiple large video streaming services have been approached by HEVC Advance—one of the H.265 patent pools—for licensing fees. This illustrates how fragmented and complex the H.265 patent landscape is.
Proprietary Software Embedding a GPL Build:
Though rarely publicized, there are multiple cases where software vendors embedded a GPL FFmpeg build into proprietary software without publishing source code, and were called out by the FFmpeg developer community for GPL violations.
Video Editor FFmpeg License Violations:
As documented in Video Editing Software and FFmpeg License Risk Cases, commercial software embedding FFmpeg without proper license attribution is regularly flagged by the community.
Key Lessons:
- Always include license attribution, even for LGPL builds
- Never embed a GPL build in closed-source software
- Treat H.264/H.265 patents as a completely separate issue from FFmpeg's open-source license
Wrapping Up
Here's a summary of what to do for safe commercial use of FFmpeg.
Licensing:
- Build without
--enable-gpland--enable-nonfree - LGPL builds can be embedded in SaaS and commercial apps without source disclosure
- Always include license attribution
- Verify your build's license with
ffmpeg -version
Codec Selection:
- AV1 + Opus + WebM is the safest choice (patent-free)
- If using H.264/H.265, investigate the patent situation separately
- See the AV1 vs H.265 vs H.264 comparison article for more detail
When in Doubt:
For large-scale commercial use (significant annual revenue or high encoding volume), consult an intellectual property lawyer. Even at a smaller scale, forming the habit of always including license attribution is essential.
FFmpeg is a powerful tool, but treating it as "free to use however you want" is the highest-risk mistake you can make. Use it with the right knowledge, and it's a rock-solid foundation for commercial products.