FFmpegの商用ライセンス完全ガイド

FFmpegはデフォルトのLGPLビルドであれば商用利用可能だ。ただし --enable-gpl や --enable-nonfree を付けた瞬間にルールが変わる。さらにH.264/H.265にはライセンスとは独立した特許料の問題がある。AV1 + Opusなら完全にロイヤリティフリーだ。

——と、結論だけ書くと簡単に見えるが、実際に商用プロダクトに組み込もうとすると判断に迷うポイントが山ほどある。

「LGPLって結局何がOKで何がNG？」「H.264を使ったら特許料が必要？」「SaaSに組み込んでも大丈夫？」——こういった疑問に対して、ネット上の情報は断片的で、正確な答えにたどり着くのが難しい。

この記事は、FFmpegのライセンス全体像・コーデック特許リスク・再配布可能なバイナリのビルド手順（Windows / macOS / Linux）をまとめた実践ガイドだ。

あなたのケースはどれ？

FFmpegの商用利用で「ライセンス料を払わないといけないのか」は、使い方によって答えが変わる。まずあなたのケースを確認しよう。

大多数のケースで ライセンス料は発生しない 。ポイントは「GPLオプションを付けずにビルドする」「特許コーデックを避けるか、OpenH264を使う」の2つだ。以下で詳しく解説する。

FFmpegのコマンドに慣れていない場合は、FFmpegコマンドジェネレーターでGUIからコマンドを生成できる。

FFmpegは「無料」だが「自由」ではない

FFmpegはソースコードが公開されているオープンソースソフトウェアだ。「無料」という意味では確かにそうだが、「好きに使っていい」かどうかは別の話になる。

FFmpegはライブラリ群で構成されており、それぞれが異なるライセンスを持つ。公式のライセンスページに詳細がある。

重要なのは「デフォルトのライセンス」という言葉だ。ビルド時のオプション次第で、ライセンスはLGPLからGPLへと切り替わる。これがFFmpegのライセンス問題の核心だ。

また、ライセンスとは別に 特許の問題 も存在する。H.264やH.265を使う場合、コーデックの特許保有者（Via Licensing Alliance等）への特許料が別途発生する可能性がある。これはFFmpegのライセンスとは完全に独立した話だ。

LGPLとGPLの違い

LGPLとGPLはどちらもフリーソフトウェアのライセンスだが、商用利用に与える影響が大きく異なる。

LGPL（Lesser GPL）:

LGPLは「弱いコピーレフト」と呼ばれる。FFmpegのLGPLライブラリをアプリケーションに 動的リンク で組み込む場合、自分のアプリケーションのソースコードを公開する義務はない。ただし以下の条件を満たす必要がある（LGPL 2.1 第6条）。

• ユーザーがFFmpegライブラリ部分を差し替えられる仕組みを用意する
• FFmpegのライセンス全文とライセンスの帰属を明示する
• FFmpegに加えた変更がある場合はソースコードを公開する

静的リンクでもLGPL準拠は可能だが、その場合はユーザーが再リンクできるようオブジェクトファイルまたはソースコードを提供する必要がある（LGPL 2.1 第6条）。動的リンクのほうが運用は簡単だ。

GPL（General Public License）:

GPLは「強いコピーレフト」だ。GPLなコードをアプリケーションに組み込むと、そのアプリケーション全体がGPLになる。つまり 自分のアプリケーションのソースコードをGPLで公開しなければならない 。

商用の独自ソフトウェアにとって、これは致命的な制約になりうる。多くのビジネスモデルはソースコードを非公開にすることで成立しているからだ。

GPLに切り替わるオプション一覧

FFmpegのconfigureオプションのうち、GPLまたはそれより制限の強いライセンスのコードを有効化するものを整理する。

GPLを有効化するオプション

非フリーライセンス（--enable-nonfree）

--enable-nonfree を付けたビルドは再配布自体が禁止される。サーバー上で自社のみが使う場合は問題ないが、バイナリを他者に配布することはできない。

ライセンスチェックの方法

ffmpeg -version

出力の License: 行でライセンスを確認できる。

# LGPL版の例
License: LGPL version 2.1 or later

# GPL版の例
License: GPL version 2 or later

特許コーデックの罠（H.264 / H.265）

FFmpegのライセンスとは完全に独立した問題として、コーデックの特許がある。

H.264（AVC）の特許状況:

MPEG LAとVia Licensingが2023年に統合して設立されたVia Licensing Alliance（Via LA）が特許プールを管理している。製品やサービスでH.264を使う場合、エンコード量やユーザー数に応じてライセンス料が発生しうる。米国でのH.264主要特許の多くは 2027年頃に失効予定 だが（例: US 7826532 が2027年11月29日）、2016年に付与された一部の特許は 2030年以降まで有効 な可能性がある。完全に特許フリーになる時期は確定していない。

OpenH264（特許料の抜け道）: Cisco が開発した H.264 実装「OpenH264」は、Cisco が Via LA（旧MPEG LA）へ特許料を支払っているため、利用者に特許料が発生しない。FFmpeg では --enable-libopenh264 で有効にでき、LGPL ビルドと互換性がある。H.264 を商用で使いたいが特許料を避けたい場合の選択肢だ。

H.265（HEVC）の特許状況:

H.264よりも複雑だ。複数の特許プール（Access Advance、Via Licensing、Velos Media）が存在し、それぞれに別途ライセンスが必要になる可能性がある。Access AdvanceのHEVCプールだけで27,000件超の特許をカバーしており、2026年1月からは新規ライセンシーに対して25%の値上げが実施された。特許は2030年以降まで続く。商用利用には特に注意が必要だ。

実際に問題になったケース

• VideoLAN（VLC）: フランスでH.264特許保有者から訴訟を受けた。最終的には解決したが、コーデック特許の現実的なリスクを示す事例として知られている
• 動画配信サービス: 複数の大手サービスがHEVC Advanceからライセンス取得を求められた
• GPL違反: GPLビルドのFFmpegをソース公開なしで商用ソフトに組み込み、コミュニティから指摘を受けたベンダーが複数存在する

教訓: ライセンス表記は必ずする。GPLビルドを閉ソースに組み込まない。H.264/H.265の特許は独立した問題として扱う。

安全なコーデック選択

OpenH264 — H.264を特許料ゼロで使う方法

「AV1が安全なのはわかった。でもクライアントがH.264しか受け付けない」——これは実務で非常によくある話だ。AV1はエンコードが遅く、古いデバイスでのデコード対応もまだ完全ではない。企業間の納品フォーマットとしてH.264が指定されるケースは依然として多い。

そこで選択肢になるのが OpenH264 だ。

OpenH264とは

CiscoがBSDライセンスで公開しているH.264エンコーダー/デコーダーで、CiscoがVia LA（旧MPEG LA）に特許料を支払っている。つまり 利用者に特許料が発生しない 。

制約

OpenH264はH.264の全機能をカバーしているわけではない。

バージョン2.5以降でHighプロファイルに対応したため、1080pの一般的なユースケースでは十分実用的だ。ただしエンコード品質はx264に劣るため、画質が最優先の場合は注意が必要。

FFmpegでOpenH264を使う

# OpenH264を有効にしたLGPLビルド
./configure \
  --disable-nonfree \
  --enable-shared --disable-static \
  --enable-libopenh264 \
  --enable-libopus --enable-libvpx \
  --enable-libdav1d --enable-libaom

# OpenH264でエンコード
ffmpeg -i input.mov -c:v libopenh264 -b:v 4M -c:a aac output.mp4

--enable-gpl は不要。LGPLビルドのままOpenH264を使える。

再配布可能なFFmpegをビルドする

商用利用で安全なFFmpegビルドの基本方針は「LGPLの範囲内に収める」ことだ。まずは動作確認だけしたいなら、インストールガイドでパッケージマネージャー経由の導入を試してほしい。ソースからビルドが必要なのは、再配布するバイナリのライセンスを厳密にコントロールしたい場合だ。

configureオプション

以下はLGPL準拠の商用安全ビルドのconfigure例だ。特許フリーコーデックのみ有効にしている。GPLはデフォルトで無効なので、--enable-gpl を付けなければ自動的にLGPLビルドになる（--disable-gpl というフラグは存在しない）。

./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

ビルド環境のセットアップ

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

ビルドの検証

ffmpeg -version

configuration: 行に --enable-gpl が 含まれていない ことを確認する。License: が LGPL version 2.1 or later と表示されていればOKだ。libx264 や libfdk_aac が含まれていないことも確認しよう。

再配布チェックリスト

バイナリを配布する前に、以下を満たしているか確認する。

• ffmpeg -version の License: が LGPL version 2.1 or later である
• configuration: に --enable-gpl が含まれていない
• 特許コーデック（x264, x265, mp3lame, fdk-aac）が有効になっていない
• COPYING.LGPLv2.1 ファイルを同梱している
• ドキュメントに「FFmpegをLGPLで使用している」旨を明記している
• 共有ライブラリ（DLL / .so / .dylib） として配布している、または静的リンクの場合は再リンク用のオブジェクトファイルを提供している

パッケージングとCI/CD

ビルドした FFmpeg を配布・運用するための方法を紹介する。

tar.gz による配布

./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 による再現可能なビルド

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/

GitHub Actions や Docker を使った自動ビルドを構築しておくと、FFmpeg のセキュリティアップデートが出たときに素早く対応できる。FFmpeg公式のリリースページをウォッチしておこう。特にVPSでエンコードサーバーを運用している場合、セキュリティパッチの適用は重要だ。

SaaS・サーバーサイド利用の場合

SaaSやバックエンドでFFmpegを動かす場合は、ルールがぐっとシンプルになる。バイナリを外部に配布しないため、LGPLの「再配布」条件の大部分が関係しないからだ。

SaaS利用で守るべきこと

• 帰属表示: Aboutページやライセンスページに「FFmpegをLGPL 2.1で使用」と記載する
• バージョン情報の記載: 使用しているFFmpegのバージョンとコンポーネントを文書化する
• 改変ソースの公開: FFmpeg本体に変更を加えた場合のみ、変更部分のソース公開が必要

SaaS利用で不要なこと

• 自社アプリケーションのソースコード公開（LGPLの場合）
• 特許料の支払い（バイナリを配布していないため、Via LAの特許ライセンスは配布者に適用される）
• GPLビルドの回避（サーバー上のみなら「ASP抜け穴」でGPLビルドも使える）

YouTube、Netflix、Twitch、Discordなど大手SaaS企業もFFmpegをバックエンドで使用している。FFmpegの公式サイトにも利用企業が掲載されている。

よくある質問

FFmpegを商用製品に組み込んでいいか

組み込める。ただしビルドのライセンスに注意が必要だ。--enable-gpl を付けてビルドすると、あなたの製品全体がGPL準拠を求められる（= ソースコード公開義務）。LGPL（デフォルト）で動的リンクすれば、自社のプロプライエタリコードは公開不要だ。ffmpeg -version でライセンスを必ず確認しよう。

SaaSとしてFFmpegを組み込んでいいか

LGPLビルドのFFmpegをサーバーサイドで動かし、ユーザーにサービスとして提供する場合、ソースコードの公開義務はない。LGPLの「リンク」の概念はソフトウェアの配布に関するものであり、SaaSはライブラリを配布しているわけではないからだ。ただし、FFmpegのLGPLライセンスの帰属表示（Aboutページ等）とバージョン・コンポーネント情報の記載は必要だ。

サーバーサイドでのみ動かす場合（バイナリ配布なし）

サーバー上でFFmpegを動かし、バイナリを外部に配布しない場合、GPLビルドを使っていてもソースコード公開義務は発生しないという解釈が一般的だ（「ASP抜け穴」と呼ばれる）。ただしAGPLが適用されているコードが含まれる場合は別だ。多くの企業がこの解釈に基づいて、社内サーバーでGPLビルドを正当に運用している。

H.264やH.265を使うと特許料が発生するか

発生しうる。H.264とH.265は特許プール（Via LA、Access Advance）によって管理されている。これらのコーデックを使った製品を配布する場合、ロイヤリティが必要になる可能性がある。特許料を避けたいならAV1が最も安全な選択肢だ。詳しくはコーデック比較記事を参照してほしい。

AV1 + Opus + WebM は本当に安全か

AV1はAlliance for Open Mediaがロイヤリティフリーを宣言しており、Google、Mozilla、Amazon、Netflixなどが参加している。SisvelがAV1に対する特許プールを形成し一部のハードウェアメーカーにライセンスしているが、AOMメンバーはこれを認めておらず、2026年時点でソフトウェア利用者が追及されたケースはない。ソフトウェア製品であれば、AV1 + Opusは現時点で最も安全な組み合わせだ。

FFmpegで作った動画ファイルの著作権は誰にあるか

出力された動画ファイルの著作権は、コンテンツを作った人（あなた）にある。Photoshopで作った画像がAdobe のものにならないのと同じで、FFmpegはツールであり、ツールを使って作った成果物の著作権をFFmpegが主張することはない。

GPLビルドを誤って配布してしまったらどうなるか

GPLビルドをプロプライエタリ製品に含めて配布した場合、GPL違反となる。FFmpegプロジェクトはGPL違反事例のリストを公開しており、企業名が公開されたケースもある。対処法は、LGPLビルドへの切り替え、自社アプリのオープンソース化、またはバイナリ配布の停止のいずれかだ。既に出荷済みの場合は弁護士に相談すべきだ。

パッケージマネージャーでインストールしたFFmpegは商用利用できる？

注意が必要だ。apt install ffmpeg や brew install ffmpeg でインストールされるFFmpegは、ほとんどの場合 GPLビルド だ。ffmpeg -version で確認すると License: GPL version 2 or later と表示されるはずだ。開発やテスト用途なら問題ないが、商用製品に組み込む場合はソースからLGPLビルドを自分で作る必要がある。

FFmpegでエンコードした動画をYouTubeにアップするのに特許料は必要？

不要だ。動画をYouTubeにアップロードする行為自体にはH.264の特許料は発生しない。特許料が問題になるのは「H.264エンコーダーを含むソフトウェアを配布する」ケースだ。あなたがローカルのFFmpegでエンコードしてYouTubeに上げるだけなら、YouTube側がライセンスを処理している。

OpenH264の品質はx264と比べてどのくらい違う？

同ビットレートで比較すると、OpenH264はx264より画質が劣る。特に低ビットレート（1-2 Mbps）での差が顕著だ。4-8 Mbpsの十分なビットレートを確保できる用途なら実用上の差は小さくなる。「特許料ゼロでH.264互換」というメリットと天秤にかけて判断しよう。画質が最優先なら、AV1（libaom）の方がOpenH264より高品質で、かつ特許フリーだ。

まとめ

FFmpegの商用利用を安全に行うためのポイントをまとめる。

ライセンス面:

• --enable-gpl と --enable-nonfree を付けずにビルドする（GPLはデフォルト無効）
• LGPLビルドならSaaS・商用アプリに組み込める（ソース公開不要）
• ライセンス帰属表示は必ず行う
• ffmpeg -version でビルドのライセンスを確認する

コーデック選択:

• AV1 + Opus + WebM が最も安全（特許フリー）
• H.264 が必要なら OpenH264 を検討する（Cisco が特許料を負担）
• H.264/H.265 を使う場合は特許の問題を別途確認する
• AV1/H.265/H.264の比較記事で画質・速度のベンチマークを確認できる
• FFmpegコマンドの生成は コマンドジェネレーター で簡単にできる

ビルドと配布:

• 全 OS で ./configure --disable-nonfree --enable-shared が基本（--enable-gpl は付けない）
• 共有ライブラリ（DLL / .so / .dylib）で配布する（静的リンクの場合は再リンク用ファイル提供が必要）
• COPYING.LGPLv2.1 を必ず同梱する
• Docker / GitHub Actions で自動ビルドを構築すると運用が楽になる

判断に迷ったら、知的財産専門の弁護士に相談することを強く勧める。FFmpegは強力なツールだが、「無料だから何でも使える」という誤解を持ったまま商用利用を進めるのが最もリスクが高い。

ライセンスの問題をクリアしたら、次はコストの話だ。マネージドサービスと自前運用で迷っているならMediaConvert vs FFmpegのコスト比較が参考になる。エンコード速度を上げたいならGPUエンコード（NVENC/QSV）ガイドも合わせて読んでほしい。

関連記事:

• FFmpeg最新版インストールガイド【全OS対応】
• FFmpegの使い方 完全ガイド【実用コマンド集】
• FFmpegが難しい人のためのGUIソフト比較
• AWS MediaConvert vs FFmpeg：コスト比較
• その動画素材は罠かもしれない：動画編集ソフトが抱えるFFmpegの脆弱性リスク
• FFmpeg + Python：動画バッチ処理の自動化
• VPSでFFmpegエンコードサーバーを構築する
• FFmpegコマンドジェネレーター — GUIでFFmpegコマンドを生成