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

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

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

「LGPLって結局何がOKで何がNG？」「H.264を使ったら特許料が必要？」「SaaSに組み込んでも大丈夫？」——こういった疑問に対して、ネット上の情報は断片的で、しかも古いまま放置されているものが多い。特にOpenH264の特許カバー範囲は、不正確な解説が広く出回っている。

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

あなたのケースはどれ？

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

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

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

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

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

FFmpegはライブラリ群で構成されている。公式のライセンスページが明言しているとおり、本体はLGPL 2.1以降で、GPLのコードを有効化した場合のみ全体がGPLになる。

かつて唯一GPLだった後処理ライブラリ libpostproc は、FFmpeg 8.0で本体から削除された。現在は本体外で保守される source plugin として明示的に取り込んだ場合のみ入る。8系を使う限り、libpostproc由来のGPL混入は考えなくていい。

重要なのは「デフォルトのライセンス」という言葉だ。ビルド時のオプション次第で、ライセンスは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に加えた変更がある場合はソースコードを公開する
• デバッグ目的の改変・リバースエンジニアリングをEULAで禁止しない（第6条が明示的に要求している。見落とされがちだが、FFmpeg公式のチェックリストにも「EULAからリバースエンジニアリング禁止条項を取り除くこと」とある）

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

GPL（General Public License）:

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

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

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

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

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

これは代表例で、完全なリストは configure の EXTERNAL_LIBRARY_GPL_LIST にある（avisynth、libcdio、libdavs2、libdvdnav / libdvdread、libxavs / libxavs2 なども含む計13ライブラリ）。

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

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

GPU利用者が踏みやすい罠がもうひとつある。--enable-cuda-nvcc と --enable-libnpp（CUDA SDK系）も configure の HWACCEL_LIBRARY_NONFREE_LIST で nonfree 扱いだ。NVENC 自体は GPL / nonfree のどちらのリストにも入っていないので、LGPLビルドのまま使える。

なお、古い解説では OpenSSL が nonfree 扱いと書かれていることが多いが、現在は違う。LGPLビルドなら --enable-openssl をそのまま併用できる。--enable-gpl と OpenSSL 3.0以降を組み合わせる場合は、Apache-2.0ライセンスがGPLv2と非互換なため --enable-version3（GPLv3化）が必要になる——nonfree が要求されるのは「GPL + OpenSSL 3.0未満」の組み合わせだけだ（出典: configure のライセンス判定実装）。

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

よくある解説（本記事の旧版を含む）は「ffmpeg -version の License: 行を見る」と書いているが、ffmpeg -version に License 行は存在しない（出力されるのはバージョン・コンパイラ・configuration とライブラリバージョンだけ。fftools/opt_common.c の実装で確認できる）。ライセンスを表示するのは ffmpeg -L だ。

ffmpeg -hide_banner -L

# GPLビルドの出力（Ubuntu 24.04 の apt 版で実測）
ffmpeg is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

LGPLビルドなら「GNU Lesser General Public License ... version 2.1」、nonfreeビルドなら「This version of ffmpeg has nonfree parts compiled in」（=再配布不可）と表示される。あわせて ffmpeg -version の configuration: 行に --enable-gpl / --enable-nonfree が入っていないかも確認しよう。

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

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

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

MPEG LAとVia Licensingが2023年に統合して設立されたVia Licensing Alliance（Via LA）が特許プールを管理している。製品やサービスでH.264を使う場合、エンコード量やユーザー数に応じてライセンス料が発生しうる。「H.264特許は2027年に切れる」とよく言われるが、単一の失効日は存在しない。Via LA自身が公開する特許リスト（AVC Attachment 1・2026年5月版）には、いまも約2,500件の有効特許が100を超える法域にわたって載っていて、2024〜25年に成立した権利まで含まれる（別掲の失効済みリストのほうがずっと長いとはいえ、だ）。本記事の執筆で実際に踏んだ注意点をひとつ: Google Patentsの「adjusted expiration」とプール自身のリストは食い違うことがある。失効日が判断材料になるなら、検索エンジンでなくプールのリストを見ること。

OpenH264という選択肢: Ciscoが公開しているH.264実装「OpenH264」を使うと特許料を回避できる場合がある。ただし 条件が厳しく、最も誤解されやすいポイント なので、後述の専用セクションで正確に解説する。

なお「閉ソースでx264品質が必要」なケースには、x264プロジェクト自身が商用ライセンスを提供している（窓口: x264licensing@videolan.org）。これで解除できるのは著作権（GPL義務）の側だけで、H.264特許（Via LA）は別途残る点に注意。

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

H.264よりも複雑で、しかも最近再編された。アクティブな2つのプール——HEVC Advanceと、かつてVia LAが運営していたHEVC/VVCプログラム——は、2025年12月15日以降どちらもAccess Advanceの傘下 にある（Access AdvanceがVia LAのプログラムを買収し、子会社Video Codec Licensing LLCが「VCL Advance」として運営）。かつて第3のプールを運営していたVelos Mediaは2022年後半にプール型ライセンスを終了し、個別ライセンスに移行した（会社は存続して権利行使を続けている）。Access AdvanceのHEVCプールだけで27,000件超の特許をカバーする（2025年7月の同社発表時点）。新規ライセンシー向けの約25%値上げは、旧料率で契約できる経過措置の期限（2026年6月30日）が再延長されないまま過ぎ、現在は新料率での契約になっている。特許の存続期間もH.264より長く、商用利用には特に注意が必要だ。

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

• GPL違反の公表: FFmpegプロジェクトはGPL違反企業を公表する「Hall of Shame」ページを運用してきた（2026年7月時点ではエントリ更新まで休止中と表示されている）。GPLビルドをソース非公開の商用ソフトに組み込み、コミュニティから指摘を受けた事例は実際に複数ある
• 特許の権利行使は現在進行形: HEVC特許を巡っては、Velos Mediaが2026年3月にDisneyのストリーミングサービスを米連邦地裁に提訴した（Bloomberg Law報道）。コーデック特許のリスクは過去の話ではない
• 法域による違い: VLCがコーデック特許のライセンスなしで配布できているのは、フランス法も欧州特許条約もソフトウェアを特許対象と認めていないことが根拠だ（VideoLAN公式のlegalページが明言している）。逆に言えば、特許リスクはあなたの製品をどの国で売るかによってまったく変わる

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

安全なコーデック選択

OpenH264 — 「特許料ゼロ」には厳しい条件がある

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

そこで名前が挙がるのがCiscoの OpenH264 だ。ただし「OpenH264を使えば特許料フリー」という理解は半分間違っている。ネット上の解説の多くがここを不正確に書いているので、一次ソースベースで条件を正確に整理する。

OpenH264とは

CiscoがBSDライセンスで公開しているH.264エンコーダー/デコーダーで、WebRTCのようなリアルタイム通信向けに設計されている。ここで効いてくるのが、BSDはあくまで 著作権 のライセンスであって、特許 は別枠だという区別だ。

Ciscoが特許料を負担するのは「公式バイナリ」だけ

CiscoがMPEG LA（現Via LA）への特許料を肩代わりしてくれるのは、Ciscoがビルドして配布する公式バイナリモジュールを使う場合だけ だ。公式FAQは、ソースコードを自社製品に組み込んで自分で配布する場合の質問にこう答えている。

"No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user's computer or device."（いいえ。Ciscoがカバーするのは自社バイナリモジュールの特許料だけで、利用する製品はインストール時にユーザーの端末へモジュールをダウンロードしなければならない）

さらにバイナリライセンス（BINARY_LICENSE.txt）の条件として、Ciscoバイナリは「サードパーティ製ソフトに事前統合・同梱されず、エンドユーザーのデバイスへインストール時に個別ダウンロードされる」必要がある。

つまり、FFmpegを --enable-libopenh264 付きでビルドして自社アプリに同梱配布する構成は、①ソースからのビルド ②事前統合——の二重に対象外だ。この形でH.264エンコーダーを配布すれば、特許ライセンスの責任は配布者であるあなたに残る。

Firefoxが「同梱」せず「実行時ダウンロード」する理由

この条件を満たす実装例がFirefoxだ。MozillaはH.264対応を発表した2013年の公式ブログで、「Firefoxは必要になったときにCiscoのバイナリモジュールを各ユーザーのマシンへ自動ダウンロードする」と説明している。同梱したら特許カバーが外れるからこその設計だ。

自社アプリで同じ構成を組むなら:

• libopenh264を 動的リンク でビルドし、ライブラリ本体（.dll / .so）はアプリに同梱しない
• インストール時または初回起動時に、Ciscoの配布サーバーから公式バイナリをエンドユーザーの端末へダウンロードする
• 表示義務などの詳細条件はBINARY_LICENSE.txtを必ず原文で確認する

エンコーダーは実質Constrained Baseline

もうひとつ誤解が多いのが対応プロファイルだ。Cisco自身の公式READMEは、エンコーダーの能力を Constrained Baseline Profile（Level 5.2まで） と記載している。厳密に言うと、CABACを有効にした場合はMain/Highを名乗るストリームも出力できる——公式チェンジログによればv1.8.0以降、CABAC指定時のデフォルトプロファイルはHighだ——が、High Profileの肝心の圧縮ツールは実装していない。READMEが挙げるエンコーダーのインター予測は参照フレーム1枚のみで、エンコーダー実装にBフレームと8x8変換の経路は存在しない。デコーダー側は先へ進んでいる（v1.5.0でConstrained High、チェンジログによればv2.0.0でMain/HighのBフレームデコードに対応）が、それはエンコードとは別の話だ。

Bフレームや8x8変換が使えない分、同ビットレートでの圧縮効率はx264のHigh Profileに明確に劣る。リアルタイム通信には十分でも、VODのような品質重視のエンコードには向かない。

FFmpegでOpenH264を使う

執筆時点のOpenH264最新版はv2.6.0（2025年2月リリース）。FFmpegからは --enable-libopenh264 で使える。ビルド自体はLGPL互換でライセンス上の問題はない——問題になるのは上で書いた特許カバーの条件だけだ。

# 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

整理すると、「H.264が必要・特許料も避けたい・バイナリを配布する」を全部満たす王道は Cisco公式バイナリの実行時ダウンロード構成 だけだ。それが難しいアーキテクチャなら、エンコード処理をサーバー側に寄せて配布自体をなくすか、Via LAとのライセンス契約を検討するか、納品フォーマットをAV1に交渉するか——のいずれかになる。

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

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

本記事のコマンドは執筆時点の最新安定版 FFmpeg 8.1.2「Hoare」（2026年6月17日リリース）を対象にしている。

configureオプション

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

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

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

出力が「GNU Lesser General Public License ... version 2.1」で始まっていればLGPLビルドだ。あわせて ffmpeg -version の configuration: 行に --enable-gpl が 含まれていない こと、libx264 や libfdk_aac が含まれていないことも確認しよう。

再配布チェックリスト

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

• ffmpeg -L がLGPL 2.1のライセンス文を表示する（GPL文・nonfree警告でない）
• configuration: に --enable-gpl が含まれていない
• 特許コーデック（x264, x265, mp3lame, fdk-aac）が有効になっていない
• COPYING.LGPLv2.1 ファイルを同梱している
• ドキュメントに「FFmpegをLGPLで使用している」旨を明記している
• 共有ライブラリ（DLL / .so / .dylib） として配布している、または静的リンクの場合は再リンク用のオブジェクトファイルを提供している
• EULAでリバースエンジニアリングを全面禁止していない（LGPL 2.1 第6条の要求）

パッケージングと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.2 && \
    ./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.2
        ./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の「再配布」条件の大部分が関係しないからだ。

FFmpegのバイナリがユーザーの手に渡らない＝ライセンス上の「配布」が発生しない。これがSaaS構成の強みだ。

SaaS利用で守るべきこと

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

SaaS利用で不要なこと

• 自社アプリケーションのソースコード公開（LGPLの場合）
• ソフトウェア製品としての特許ライセンス（エンコーダー/デコーダー製品の課金カテゴリは配布者向け。バイナリを配布しないSaaSは対象外）
• GPLビルドの回避（サーバー上のみなら「ASP抜け穴」でGPLビルドも使える）

ただしコーデック特許が完全に消えるわけではない。エンドユーザーに無料のインターネット動画はMPEG LAの2010年発表によりライセンス存続期間中ロイヤリティ免除とされてきたが、それで全部ではなくなった。Via LAの現行AVC料金表には OTT配信・FAST配信・ソーシャルメディア・クラウドゲーミング といったサービスカテゴリが並び、最大ティアは年450万ドルに達する。適用対象は2026年以降の新規ライセンシーで、2025年末時点で契約中だった事業者は従来のストリーミング条件を維持する（Via LAがStreaming Media誌の取材に回答）。2010年の免除とこれらの新カテゴリがどう整合するのかはVia LAの公開ページには書かれていない——規模があるなら弁護士に確認する領域だ。配信事業者への権利行使も現在進行形だ（上のVelos対Disney訴訟）。規模のあるH.264/H.265配信サービスを運営するならプールの条件を読み、その話から降りたいならAV1でエンコードする。

大手も同じ構成だ。Netflixは公式テックブログ（MezzFS解説・2019年）でエンコードパイプラインにFFmpegを使っていることを公開しており、Metaも「FFmpeg at Meta」（2026年）という記事で大規模メディア処理基盤でのFFmpeg運用を解説している。

よくある質問

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

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

SaaSやサーバーサイドでFFmpegを使う場合のルールは

LGPLビルドのFFmpegをサーバーサイドで動かし、ユーザーにサービスとして提供する場合、自社アプリのソースコード公開義務はない。LGPLの条件は「配布」に紐づくもので、SaaSはバイナリを配布していないからだ。さらにバイナリを一切配布しないなら、GPLビルドでもソース公開義務は発生しないという解釈が一般的だ（「ASP抜け穴」と呼ばれる）。ただしFFmpegのライセンス帰属表示（Aboutページ等）とバージョン情報の文書化は行うべきだ。

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

発生しうる。H.264はVia LA、H.265はAccess Advanceの特許プールが管理しており、課金対象はエンコーダー/デコーダーを含む製品の製造・販売者や動画配信事業者だ。一方、自分でエンコードした動画をYouTubeに上げるだけの個人に特許料は発生しない。エンドユーザーが無料で視聴するインターネット動画について、MPEG LA（現Via LA）は2010年にライセンス存続期間中のロイヤリティ免除を発表している（無料放送TVは対象外・文言も「恒久」でなく "entire life of this License"。なお現行のVia LA料金表は新規ライセンシー向けにFAST配信・ソーシャルメディアのカテゴリを設けている）。特許料を避けたいならAV1が最も安全な選択肢だ。

OpenH264を使えば特許料は本当にゼロになるか

条件付きでゼロになる。Ciscoが特許料を負担するのは「Ciscoが配布する公式バイナリを、インストール時にエンドユーザーの端末へ個別ダウンロードする」構成だけだ（公式FAQ）。ソースからビルドして自社アプリに同梱した場合は対象外で、特許料の責任は配布者にある。Firefoxがバイナリを同梱せず実行時にダウンロードするのはこのためだ。

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

ソフトウェア製品なら安全と言える。AV1はAlliance for Open Mediaのロイヤリティフリー特許ポリシーのもとで開発されており、Google、Mozilla、Amazon、Netflixなどが参加している。周縁には第三者のプールが2つある: SisvelのAV1プールはテレビなどのコンシューマー機器が対象で、ソフトウェア利用者への請求事例は確認されていない（ただし将来の課金を明確には否定していない）。またAvanci VideoはHEVC/VVC/VP9/AV1/MPEG-DASHをまとめた配信事業者向けライセンスを提供している。いずれも「AV1をエンコードするソフトウェアを出荷する」ことの安全性は変えない。AV1 + Opusは現時点で最も安全な組み合わせだ。

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

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

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

GPLビルドをプロプライエタリ製品に含めて配布した場合、GPL違反となる。FFmpegプロジェクトは違反企業を公表する「Hall of Shame」ページを運用してきた（2026年7月時点では更新休止中の表示）。対処法は、LGPLビルドへの切り替え、自社アプリのオープンソース化、またはバイナリ配布の停止のいずれかだ。既に出荷済みの場合は弁護士に相談すべきだ。

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

注意が必要だ。apt install ffmpeg も brew install ffmpeg も、ほとんどの場合 GPLビルド だ（Debianのビルド設定にもHomebrewのformulaにも --enable-gpl が入っている。Homebrewは --enable-version3 付きでGPLv3だ）。僕の手元のUbuntu 24.04のapt版で実測したところ、configuration: 行に --enable-gpl が含まれ、ffmpeg -L はGPLv2のライセンス文を表示した。開発・検証や社内サーバー用途なら問題ないが、商用製品に同梱する場合はソースからLGPLビルドを自分で作る必要がある。

まとめ

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

ライセンス面:

• --enable-gpl と --enable-nonfree を付けずにビルドする（GPLはデフォルト無効）
• LGPLビルドならSaaS・商用アプリに組み込める（ソース公開不要）
• ライセンス帰属表示は必ず行い、EULAでリバースエンジニアリングを禁止しない
• ffmpeg -L と configuration: 行でビルドのライセンスを確認する

コーデック選択:

• AV1 + Opus + WebM が最も安全（特許フリー）
• H.264が必要で特許料を避けたいなら、Cisco公式バイナリの実行時ダウンロード構成を検討する（ソースビルドの同梱は特許カバーの対象外）
• H.264/H.265 を使う場合は特許の問題を別途確認する
• FFmpegコマンドの生成は コマンドジェネレーター で簡単にできる

ビルドと配布:

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

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

関連記事:

• その動画素材は罠かもしれない：動画編集ソフトが抱えるFFmpegの脆弱性リスク
• FFmpegコマンドジェネレーター — GUIでFFmpegコマンドを生成

参考文献

• FFmpeg License and Legal Considerations — デフォルトLGPL 2.1+・GPL化条件・準拠チェックリスト。参照日 2026-07-26
• FFmpeg LICENSE.md（n8.1.2） — ライブラリ別ライセンスと --enable-gpl の挙動。参照日 2026-07-26
• FFmpeg configure（n8.1.2） — GPL/nonfreeライブラリの完全リスト・OpenSSL判定。参照日 2026-07-26
• FFmpeg Download — 8.1.2「Hoare」2026-06-17リリース。参照日 2026-07-26
• GNU LGPL 2.1 — 第6条（リンク条件・リバースエンジニアリング）。参照日 2026-07-26
• Cisco OpenH264 FAQ — 特許カバーは公式バイナリのみ。参照日 2026-07-26
• OpenH264 BINARY_LICENSE.txt — 個別ダウンロード・事前統合禁止の条件。参照日 2026-07-26
• openh264 README・RELEASESチェンジログ — エンコーダーはConstrained Baseline（Level 5.2まで・参照フレーム1枚）、v1.8.0以降CABAC時のデフォルトはHigh、デコーダーはv2.0.0でBフレーム対応。参照日 2026-07-26
• Mozilla公式ブログ（2013） — Firefoxの実行時ダウンロード方式。参照日 2026-07-26
• Via LA AVC/H.264ライセンスプログラム — AVCプールの管理と現行料金表（OTT・FAST配信・ソーシャルメディアのカテゴリ）。参照日 2026-07-26
• Streaming Media: Via LAのAVC料金改定に関する回答 — 新料金体系は2026年以降の新規ライセンシーのみ・既存は従来条件を維持。参照日 2026-07-26
• Via LA AVC Attachment 1（2026年5月版） — AVCプールの特許ごとの失効日。参照日 2026-07-26
• MPEG LAプレスリリース（2010） — 無料インターネット動画のロイヤリティ免除。参照日 2026-07-26
• Via LA HEVC/VVCプログラムページ — 2025-12-15にAccess Advanceが買収・現在はVCL Advance。参照日 2026-07-26
• Access Advance: HEVC/VVC料金（〜2030）・旧料率期限の延長告知 — 27,000件超（2025年7月発表時点）・新料率は署名期限2026-06-30の経過後に適用。参照日 2026-07-26
• IAM: Velosプール型ライセンス終了 — Velosプールの解体（2022年12月）。参照日 2026-07-26
• Avanci Video — HEVC/VVC/VP9/AV1/MPEG-DASHをまとめた配信事業者向けライセンス。参照日 2026-07-26
• Bloomberg Law: Velos対Disney訴訟 — 2026年3月提訴。参照日 2026-07-26
• AOMedia Patent License — AV1のロイヤリティフリー特許ポリシー。参照日 2026-07-26
• Sisvel AV1ライセンスプログラム — 対象はコンシューマー機器。参照日 2026-07-26
• VideoLAN legalページ — 仏法・欧州特許条約ともソフトウェアを特許対象と認めない。参照日 2026-07-26
• x264プロジェクトページ — 商用ライセンスの窓口。参照日 2026-07-26
• Debian ffmpegのdebian/rules・Homebrew ffmpeg formula — パッケージマネージャー版は --enable-gpl。参照日 2026-07-26
• MSYS2 Environments — UCRT64推奨。参照日 2026-07-26