FFmpegは「無料で使える」ツールとして広く知られている。でも商用利用しようとした瞬間、話がずっと複雑になる。
「LGPLって何？」「H.264を使ったら特許料が必要？」「SaaSに組み込んでも大丈夫？」——こういった疑問に対して、ネット上の情報は断片的なものが多い。
この記事では、FFmpegのライセンス全体像を整理して、商用利用で安全な判断ができるよう解説する。法律の専門家ではなく、実際にFFmpegを使う開発者・事業者の視点で僕がまとめた。
FFmpegは「無料」だが「自由」ではない
FFmpegはソースコードが公開されているオープンソースソフトウェアだ。「無料」という意味では確かにそうだが、「好きに使っていい」かどうかは別の話になる。
FFmpegはライブラリ群で構成されており、それぞれが異なるライセンスを持つ。
| ライブラリ | 用途 | デフォルトのライセンス |
|---|---|---|
| libavcodec | エンコード・デコード | LGPL 2.1以降 |
| libavformat | コンテナ読み書き | LGPL 2.1以降 |
| libavfilter | フィルター処理 | LGPL 2.1以降 |
| libswscale | スケーリング | LGPL 2.1以降 |
| libswresample | 音声リサンプリング | LGPL 2.1以降 |
| libpostproc | 後処理 | GPL 2以降 |
重要なのは「デフォルトのライセンス」という言葉だ。ビルド時のオプション次第で、ライセンスはLGPLからGPLへと切り替わる。これがFFmpegのライセンス問題の核心だ。
また、ライセンスとは別に 特許の問題 も存在する。H.264やH.265を使う場合、コーデックの特許保有者（MPEG-LA等）への特許料が別途発生する可能性がある。これはFFmpegのライセンスとは完全に独立した話だ。
LGPLとGPLの違い
LGPLとGPLはどちらもフリーソフトウェアのライセンスだが、商用利用に与える影響が大きく異なる。
LGPL（Lesser GPL）:
LGPLは「弱いコピーレフト」と呼ばれる。FFmpegのLGPLライブラリをアプリケーションに 動的リンク で組み込む場合、自分のアプリケーションのソースコードを公開する義務はない。ただし以下の条件を満たす必要がある。
- ユーザーがFFmpegライブラリ部分を差し替えられる仕組みを用意する
- FFmpegのライセンス全文とライセンスの帰属を明示する
- FFmpegに加えた変更がある場合はソースコードを公開する
GPL（General Public License）:
GPLは「強いコピーレフト」だ。GPLなコードをアプリケーションに組み込むと、そのアプリケーション全体がGPLになる。つまり 自分のアプリケーションのソースコードをGPLで公開しなければならない 。
商用の独自ソフトウェアにとって、これは致命的な制約になりうる。多くのビジネスモデルはソースコードを非公開にすることで成立しているからだ。
GPLに切り替わるオプション一覧
FFmpegのconfigureオプションのうち、GPLまたはそれより制限の強いライセンスのコードを有効化するものを整理する。これらのオプションを使うと、FFmpegビルド全体のライセンスが変わる。
GPLを有効化するオプション
| オプション | 含まれるもの | 備考 |
|---|---|---|
--enable-gpl | x264, x265, xvidなど | このフラグ自体がGPL宣言 |
--enable-libx264 | H.264エンコーダー（x264） | GPL 2以降 |
--enable-libx265 | H.265エンコーダー（x265） | GPL 2以降 |
--enable-libxvid | MPEG-4エンコーダー | GPL 2以降 |
--enable-libvpx | VP8/VP9エンコーダー | LGPLだが組み合わせに注意 |
--enable-frei0r | ビデオフィルタープラグイン | GPL 2以降 |
--enable-librubberband | ピッチ・テンポ変換 | GPL 2以降 |
--enable-libvidstab | 動画安定化 | GPL 2以降 |
非フリーライセンス（--enable-nonfree）
| オプション | 含まれるもの | 備考 |
|---|---|---|
--enable-libaacplus | HE-AACエンコーダー | 再配布不可 |
--enable-libfdk-aac | FDK-AACエンコーダー | 再配布制限あり |
--enable-openssl | HTTPS対応 | Apache/SSLeay、商用OK |
--enable-nonfree を付けたビルドは再配布自体が禁止される。サーバー上で自社のみが使う場合は問題ないが、バイナリを他者に配布することはできない。
ライセンスチェックの方法
ビルド済みのFFmpegがどのライセンスで構成されているかは、以下のコマンドで確認できる。
ffmpeg -version
出力の中に configuration: の行と、built with の行、そして License: の行がある。
# 出力例（LGPL版）
# License: LGPL version 2.1 or later
# 出力例（GPL版）
# License: GPL version 2 or later
特許コーデックの罠（H.264/H.265 MPEG-LA）
FFmpegのライセンスとは完全に独立した問題として、コーデックの特許がある。
H.264（AVC）の特許状況:
MPEG-LAが特許プールを管理している。製品やサービスでH.264を使う場合、年間のエンコード量・ユーザー数・有償か無償かに応じてライセンス料が発生しうる。ただし、一定の条件（インターネット上での無償配信など）では免除規定もあった。2027年以降の状況は変わる可能性がある。
H.265（HEVC）の特許状況:
H.264よりも複雑だ。複数の特許プール（MPEG-LA、HEVC Advance、Velos Media）が存在し、それぞれに別途ライセンスが必要になる可能性がある。H.265はH.264より特許環境が混乱していると言われており、商用利用には特に注意が必要だ。
現実的なリスク:
個人開発者や小規模なスタートアップが特許プール保有者から訴追されるケースは現時点では稀だが、大規模なサービスや企業での利用は無視できないリスクがある。安全を重視するなら、後述するAV1やVP9といった特許フリーのコーデックを選ぶことが最善策だ。
安全な商用ビルドの作り方
商用利用で安全なFFmpegビルドの基本方針は「LGPLの範囲内に収める」ことだ。具体的には --enable-gpl と --enable-nonfree を使わずにビルドする。
以下はLGPL準拠の商用安全ビルドのconfigure例だ。
./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
このビルドで使えるコーデックと対応フォーマットを整理する。
| コーデック | ライセンス | 用途 |
|---|---|---|
| AV1（libaom, libdav1d） | BSD系 | 映像エンコード（次世代） |
| VP8/VP9（libvpx） | BSD | 映像エンコード（Web向け） |
| Opus（libopus） | BSD | 音声エンコード |
| Vorbis（libvorbis） | BSD | 音声エンコード（レガシー） |
| WebM | 特許フリー | コンテナ |
| WebP（libwebp） | BSD | 静止画 |
動的リンクと静的リンクの選択:
--enable-shared で動的リンク（共有ライブラリ）としてビルドすることを推奨する。LGPLの要件である「ユーザーがライブラリを差し替えられる」を満たしやすくなるからだ。静的リンクでも不可能ではないが、ライブラリ差し替えの仕組みを別途用意する必要がある。
よくある質問（SaaS、サーバーサイド、出力著作権）
SaaSとしてFFmpegを組み込んでいいか
LGPLビルドのFFmpegをサーバーサイドで動かし、ユーザーにサービスとして提供する場合、ソースコードの公開義務はない。LGPLの「リンク」の概念はソフトウェアの配布に関するものであり、SaaS（サービスとして提供）はライブラリを配布しているわけではないからだ。
ただし、以下は必要だ:
- FFmpegのライセンス（LGPL）の帰属表示（Aboutページやlicensesページなど）
- FFmpegのバージョンと使用しているコンポーネントの記載
サーバーサイドでのみ動かす場合（バイナリ配布なし）
サーバー上でFFmpegを動かし、バイナリを外部に配布しない場合、GPLビルドを使っていてもソースコード公開義務は発生しないという解釈が一般的だ（「ASP抜け穴」と呼ばれる）。ただしAGPLが適用されているコードが含まれる場合は別だ。
FFmpegで作った動画ファイルの著作権は誰にあるか
出力された動画ファイルの著作権は、コンテンツを作った人（あなた）にある。FFmpegはツールであり、ツールを使って作った成果物の著作権をFFmpegが主張することはない。
Windows向けの配布可能なFFmpegビルドはどこで入手できるか
サードパーティが提供しているLGPLビルドを使う方法がある。詳細はWindows向けFFmpeg再配布ビルドの入手方法を参照してほしい。Linuxサーバー向けはLinux向けFFmpeg再配布ビルドの設定方法が参考になる。
実際に問題になったケース
FFmpegのライセンスや特許を巡って実際に問題になったケースをいくつか紹介する。あくまで一般的に知られている事例の概要だ。
VideoLAN（VLC）のH.264/H.265特許問題:
VLCはFFmpegと同様にオープンソースの動画プレイヤーだ。以前、特定の国（フランス）でH.264特許保有者から訴訟を受けたことがある。最終的には解決したが、コーデック特許の現実的なリスクを示す事例として知られている。
動画配信サービスとHEVC Advance:
複数の大手動画配信サービスがH.265（HEVC）の特許プールであるHEVC Advanceからライセンス取得を求められた事例がある。H.265の特許環境の複雑さを示している。
GPLビルドのプロプライエタリ組み込み:
一般には公表されないが、GPLで配布されているFFmpegのビルドを、ソース公開義務を無視してプロプライエタリなソフトウェアに組み込んだとして、FFmpegの開発者側からGPL違反を指摘されたソフトウェアベンダーは複数存在する。
動画編集ソフトのFFmpegライセンス違反:
動画編集ソフトとFFmpegのライセンスリスク事例でも詳しく紹介しているが、ライセンス表記なしでFFmpegを組み込んだ商用ソフトウェアがコミュニティから問題を指摘されるケースは珍しくない。
教訓:
- ライセンス表記は必ずする（LGPLを使っていても同様）
- GPLビルドを閉ソースソフトウェアに組み込まない
- H.264/H.265の特許は独立した問題として扱う
まとめ
FFmpegの商用利用を安全に行うためのポイントを僕なりにまとめる。
ライセンス面:
--enable-gpl/--enable-nonfreeなしでビルドする- LGPLビルドならSaaS・商用アプリに組み込める（ソース公開不要）
- ライセンス帰属表示は必ず行う
ffmpeg -versionでビルドのライセンスを確認する
コーデック選択:
- AV1 + Opus + WebMが最も安全（特許フリー）
- H.264/H.265を使う場合は特許の問題を別途確認する
- AV1/H.265/H.264の比較記事も参考にしてほしい
判断に迷ったら:
大規模な商用利用（年間売上が数億円規模・エンコード量が膨大）の場合は、必ず知的財産専門の弁護士に相談することを強く勧める。小規模なサービスや個人開発者であっても、ライセンス表記だけは必ず行う習慣をつけておくことが重要だ。
FFmpegは強力なツールだが、「無料だから何でも使える」という誤解を持ったまま商用利用を進めるのが最もリスクが高い。正しい知識を持って使えば、ビジネスの現場でも安心して活用できる。