FFmpeg Commercial License Guide: LGPL, GPL & Patent Risks

FFmpeg can be used commercially if you build it under the LGPL (the default license) and avoid enabling GPL or nonfree options. Patent-encumbered codecs like H.264 and H.265 require separate licensing regardless of the FFmpeg license — use AV1 + Opus for a fully royalty-free stack.

That's the short version. The longer version is where things get complicated — and where most companies get it wrong.

"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 untangles it all.

Here's the complete picture: FFmpeg licensing, codec patent risks, and step-by-step build instructions for redistributable binaries on Windows, macOS, and Linux.

Which Situation Are You In?

Whether you need to pay licensing fees for FFmpeg depends entirely on how you use it. Find your case:

In the vast majority of cases, you don't owe any licensing fees. The two things to get right: "build without GPL options" and "use patent-free codecs or OpenH264." The rest of this article explains each in detail.

If you're not comfortable with FFmpeg commands yet, the FFmpeg Command Generator lets you build commands from a GUI.

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. You can check the official breakdown on FFmpeg's legal page.

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 Via Licensing Alliance (Via 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 (per LGPL 2.1, Section 6):

• 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

Static linking is also possible under LGPL, but you must provide the object files or source code necessary for the user to re-link against a modified version of FFmpeg (LGPL 2.1, Section 6). Dynamic linking is simpler in practice. If you want to understand how LGPL dynamic linking works with a real product, Medialooks has a good practical breakdown.

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.

Options That Enable GPL

Non-Free License Options (--enable-nonfree)

A build with --enable-nonfree cannot be redistributed at all. Using it on your own server is fine, but distributing the binary to others is not.

How to Check the License of a Build

ffmpeg -version

Look for the License: line in the output.

# LGPL build example
License: LGPL version 2.1 or later

# GPL build example
License: GPL version 2 or later

The Patent Trap: H.264 and H.265

Entirely separate from FFmpeg's open-source license, codec patents are their own problem.

H.264 (AVC) Patent Status:

Via Licensing Alliance (Via LA)—formed in 2023 by the merger of MPEG LA and Via Licensing—manages the patent pool. Using H.264 in products may require license fees depending on volume and use case. Most major US H.264 patents are set to expire around 2027 (e.g., US 7826532 expires November 29, 2027), but some patents granted as recently as 2016 may remain active until 2030 or later. The exact date when H.264 becomes fully patent-free in the US is not yet settled.

OpenH264 (a patent workaround): Cisco's OpenH264 implementation is an H.264 encoder/decoder where Cisco pays the Via LA (formerly MPEG LA) royalties on behalf of all users. It can be enabled with --enable-libopenh264 and is compatible with LGPL builds. If you need H.264 in a commercial product but want to avoid patent fees, this is a viable option.

H.265 (HEVC) Patent Status:

More complex than H.264. Multiple patent pools exist (Access Advance, Via Licensing, Velos Media), each potentially requiring separate licensing. Access Advance's HEVC pool alone covers over 27,000 patents, and they implemented a 25% rate increase for new licensees starting January 2026. Patents extend well beyond 2030. Commercial use requires particular caution.

Real-World Cases

• VideoLAN (VLC): Faced patent litigation in France from H.264 patent holders. Resolved, but a well-known example of the real risk
• Streaming services: Multiple major services were approached by HEVC Advance for H.265 licensing fees
• GPL violations: Multiple vendors have embedded GPL FFmpeg builds in proprietary software without source disclosure, and were flagged by the community

Key lessons: Always include license attribution. Never embed a GPL build in closed-source software. Treat codec patents as a separate issue from FFmpeg's license.

Safe Codec Choices

OpenH264 — H.264 Without Patent Fees

"AV1 is the safe choice — got it. But my clients only accept H.264." This comes up constantly in practice. AV1 encoding is slower, older device support is incomplete, and many B2B delivery specs still require H.264.

That's where OpenH264 comes in.

What is OpenH264?

An H.264 encoder/decoder released by Cisco under the BSD license. Cisco pays Via LA (formerly MPEG LA) royalties on behalf of all users. This means you owe zero patent fees.

Limitations

OpenH264 doesn't cover the full H.264 feature set.

Since version 2.5 added High profile support, OpenH264 is practical for most 1080p use cases. Encoding quality is lower than x264, so if quality is your top priority, be aware of the trade-off.

Using OpenH264 with FFmpeg

# LGPL build with OpenH264 enabled
./configure \
  --disable-nonfree \
  --enable-shared --disable-static \
  --enable-libopenh264 \
  --enable-libopus --enable-libvpx \
  --enable-libdav1d --enable-libaom

# Encode with OpenH264
ffmpeg -i input.mov -c:v libopenh264 -b:v 4M -c:a aac output.mp4

No --enable-gpl needed. OpenH264 works within an LGPL build.

Building Redistributable FFmpeg

The guiding principle: stay within LGPL. Simply don't pass --enable-gpl or --enable-nonfree — GPL is disabled by default. If you just want to install a pre-built FFmpeg for testing, see the installation guide first — building from source is only necessary when you need to control the exact license of your binary.

Configure Options

Here is an LGPL-compliant configure example with patent-free codecs only. GPL is disabled by default—simply don't pass --enable-gpl and your build stays LGPL (there is no --disable-gpl flag).

./configure \
  --prefix=/usr/local \
  --disable-nonfree \
  --enable-shared \
  --disable-static \
  --enable-libvorbis \
  --enable-libopus \
  --enable-libvpx \
  --enable-libdav1d \
  --enable-libaom \
  --enable-libwebp \
  --disable-libx264 \
  --disable-libx265 \
  --disable-libmp3lame \
  --disable-libfdk-aac

Setting Up the Build Environment

pacman -Syu

pacman -Su

pacman -S \
  mingw-w64-ucrt-x86_64-toolchain \
  base-devel git make nasm pkg-config \
  mingw-w64-ucrt-x86_64-cmake \
  mingw-w64-ucrt-x86_64-libvpx \
  mingw-w64-ucrt-x86_64-opus \
  mingw-w64-ucrt-x86_64-libvorbis \
  mingw-w64-ucrt-x86_64-dav1d \
  mingw-w64-ucrt-x86_64-aom \
  mingw-w64-ucrt-x86_64-libwebp

export PATH=/ucrt64/bin:$PATH
echo 'export PATH=/ucrt64/bin:$PATH' >> ~/.bashrc

git clone https://git.ffmpeg.org/ffmpeg.git
cd ffmpeg
git checkout n8.1

./configure \
  --prefix=/usr/local \
  --disable-nonfree \
  --enable-shared --disable-static \
  --enable-libvpx --enable-libopus --enable-libvorbis \
  --enable-libdav1d --enable-libaom --enable-libwebp

make -j$(nproc)
make install

Verifying the Build

ffmpeg -version

Confirm the License: line says LGPL version 2.1 or later. Verify that --enable-gpl is NOT in the configuration: line, and that libx264, libfdk_aac, and similar are NOT listed.

Redistribution Checklist

Before shipping your build:

• ffmpeg -version shows License: LGPL version 2.1 or later
• --enable-gpl is NOT in the configuration: line
• No patent-encumbered codecs are enabled (x264, x265, mp3lame, fdk-aac)
• COPYING.LGPLv2.1 is included in your distribution
• Documentation states that your product uses FFmpeg under LGPL
• FFmpeg is distributed as shared libraries (DLL / .so / .dylib), or if statically linked, you provide object files for re-linking

Packaging and CI/CD

Practical methods for distributing and maintaining your FFmpeg build.

tar.gz (simplest)

./configure --prefix=$(pwd)/bundle \
  --disable-nonfree \
  --enable-shared --disable-static \
  --enable-libvpx --enable-libopus
make -j$(nproc)
make install
cp COPYING.LGPLv2.1 bundle/
tar czf ffmpeg-lgpl-linux-x64.tar.gz bundle/

Docker for Reproducible Builds

FROM ubuntu:24.04

RUN apt-get update && apt-get install -y \
    build-essential nasm pkg-config git \
    libvpx-dev libopus-dev libvorbis-dev \
    libdav1d-dev libaom-dev libwebp-dev \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /build
RUN git clone https://git.ffmpeg.org/ffmpeg.git && \
    cd ffmpeg && git checkout n8.1 && \
    ./configure \
        --prefix=/usr/local \
        --disable-nonfree \
        --enable-shared --disable-static \
        --enable-libvpx --enable-libopus \
        --enable-libdav1d --enable-libaom && \
    make -j$(nproc) && \
    make install && ldconfig

CMD ["ffmpeg", "-version"]

GitHub Actions

name: Build FFmpeg (LGPL)
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 0 1 * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Install dependencies
      run: |
        sudo apt update
        sudo apt install -y nasm build-essential pkg-config git \
          libvpx-dev libopus-dev libvorbis-dev \
          libdav1d-dev libaom-dev libwebp-dev
    - name: Build FFmpeg
      run: |
        git clone https://git.ffmpeg.org/ffmpeg.git
        cd ffmpeg && git checkout n8.1
        ./configure --prefix=$(pwd)/bundle \
          --disable-nonfree \
          --enable-shared --disable-static \
          --enable-libvpx --enable-libopus \
          --enable-libdav1d --enable-libaom
        make -j$(nproc)
        make install
        cp COPYING.LGPLv2.1 bundle/
    - uses: actions/upload-artifact@v4
      with:
        name: ffmpeg-lgpl-build
        path: ffmpeg/bundle/

Automating your build with GitHub Actions or Docker ensures you can quickly rebuild when FFmpeg security patches are released. Watch the FFmpeg GitHub releases page for new versions — security updates in particular should be applied promptly, especially if you're running a VPS encoding server.

SaaS and Server-Side Usage

If you run FFmpeg on your own servers without distributing binaries, the rules get much simpler. Most of LGPL's "redistribution" conditions don't apply because you're not redistributing anything.

What you need to do for SaaS

• Attribution: State on your About or Licenses page that you use FFmpeg under LGPL 2.1
• Version documentation: Document which FFmpeg version and components you use
• Modified source disclosure: Only required if you've modified FFmpeg itself — publish just the changed parts

What you don't need to do for SaaS

• Open-source your own application code (under LGPL)
• Pay codec patent fees (you're not distributing the binary — Via LA's patent licenses apply to distributors)
• Avoid GPL builds (the "ASP loophole" means GPL builds are fine for server-only use)

YouTube, Netflix, Twitch, and Discord all use FFmpeg in their backend infrastructure. FFmpeg's official website lists adopters.

FAQ

Can I use FFmpeg in a commercial product?

Yes, but you need to be intentional about your build. If you build FFmpeg with --enable-gpl, your entire project must comply with GPL — meaning you'd have to release your source code. Use LGPL (the default) and link dynamically to keep your proprietary code separate. Check with ffmpeg -version to confirm.

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, 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. You still need to display FFmpeg's LGPL attribution (e.g., on an About or Licenses page) and document the version and components you use.

What if I only run FFmpeg server-side without distributing binaries?

If you run FFmpeg on your server without distributing the binary, using a GPL build generally does not trigger the source disclosure obligation — the "ASP loophole." The exception is AGPL-licensed code, which closes this loophole. Many companies legitimately run GPL builds on internal servers for this reason.

Do I need to pay royalties for H.264 or H.265?

Potentially. H.264 and H.265 are covered by patent pools (Via LA, Access Advance). If your product encodes or decodes these codecs and you distribute the software, you may owe royalties. The safest alternative is AV1 — see our codec comparison for benchmarks.

Is AV1 + Opus + WebM truly royalty-free?

AV1 is declared royalty-free by the Alliance for Open Media, backed by Google, Mozilla, Amazon, Netflix, and others. Sisvel has formed an AV1 patent pool and licensed some hardware manufacturers, but AOM members do not recognize it, and as of 2026, no software-only users have been pursued. For a software product, AV1 + Opus is the safest combination available today.

Who owns the copyright of output files?

You do. FFmpeg is a tool. The copyright of the output belongs to whoever created the content — the same way Photoshop doesn't own the images you create with it.

What happens if I accidentally distribute a GPL build?

If you distributed a GPL build in a proprietary product, you're technically in violation of the GPL. The FFmpeg project maintains a list of GPL violations, and companies have been publicly named. The fix is to either switch to an LGPL build, open-source your application, or stop distributing the binary. Consult a lawyer if you've already shipped.

Can I use FFmpeg installed via a package manager commercially?

Be careful. FFmpeg installed via apt install ffmpeg or brew install ffmpeg is almost always a GPL build. Check with ffmpeg -version — you'll likely see License: GPL version 2 or later. This is fine for development and testing, but if you're distributing a commercial product, you need to build your own LGPL binary from source.

Do I need to pay patent fees to upload FFmpeg-encoded videos to YouTube?

No. Uploading a video to YouTube doesn't trigger H.264 patent fees for you. Patent fees apply when you distribute software that includes an H.264 encoder. If you're encoding locally with FFmpeg and uploading to YouTube, YouTube handles the licensing on their end.

How does OpenH264 quality compare to x264?

At the same bitrate, OpenH264 produces lower quality than x264. The gap is most noticeable at low bitrates (1-2 Mbps). At higher bitrates (4-8 Mbps), the practical difference shrinks. Weigh the "zero patent fees for H.264 compatibility" benefit against the quality trade-off. If quality is your top priority, AV1 (libaom) actually offers better quality than OpenH264 while also being patent-free.

Wrapping Up

Key points for safe commercial use of FFmpeg:

Licensing:

• Don't pass --enable-gpl or --enable-nonfree (GPL is off by default)
• LGPL builds can be embedded in SaaS and commercial apps without source disclosure
• Always include license attribution
• Verify with ffmpeg -version

Codec Selection:

• AV1 + Opus + WebM is the safest choice (patent-free)
• If you need H.264, consider OpenH264 (Cisco pays the royalties)
• For H.264/H.265, investigate the patent situation separately
• See the AV1 vs H.265 vs H.264 comparison for quality and speed benchmarks
• Generate FFmpeg commands visually with the Command Generator

Building and Distribution:

• ./configure --disable-nonfree --enable-shared is the foundation for all platforms (no --enable-gpl)
• Distribute as shared libraries (DLL / .so / .dylib), or provide object files for re-linking if statically linked
• Always bundle COPYING.LGPLv2.1
• Automate with Docker / GitHub Actions for easier maintenance

When in doubt, consult an intellectual property lawyer. FFmpeg is a powerful tool, but treating it as "free to use however you want" is the highest-risk mistake you can make.

Once you've sorted out licensing, the next question is cost. See the MediaConvert vs FFmpeg cost breakdown if you're deciding between a managed service and running your own encoding pipeline. If you need to speed up encoding, the GPU encoding guide (NVENC/QSV) covers hardware acceleration options that stay within LGPL.

Related articles:

• How to Install the Latest FFmpeg (Windows / Mac / Linux)
• FFmpeg Commands: A Practical Guide from Basics to Advanced
• FFmpeg Too Hard? GUI Alternatives Compared
• AWS MediaConvert vs Self-Hosted FFmpeg: A Cost Breakdown
• That Video File Could Be a Trap: FFmpeg Vulnerabilities in Video Editors
• FFmpeg + Python: Batch Video Processing Automation
• Build a VPS-Based FFmpeg Encoding Server
• FFmpeg Command Generator — Build FFmpeg commands from a GUI