FFmpeg を商用プロジェクトで利用する際、最も慎重に扱うべきテーマがライセンスと特許問題です。開発チームが「とりあえず動かせばいい」と進めてしまうと、後々のリリース直前に法務部門から差し戻され、大幅な手戻りが発生するケースも少なくありません。

本記事では、FFmpeg のライセンス体系（GPL・LGPL・nonfree）の違いと、configure オプションによるライセンスの変化、さらに企業の法務・コンプライアンス部門との調整を含めた実務的な対応方法まで、包括的に解説します。単なるライセンス条文の説明ではなく、実際のプロジェクトで「何をチェックし、どう判断すべきか」に焦点を当てた内容になっています。

背景

FFmpeg とは何か

FFmpeg は、動画・音声ファイルの変換、エンコード、デコード、ストリーミング処理など、マルチメディア処理に必要なほぼすべての機能を提供するオープンソースプロジェクトです。YouTube、Netflix、VLC などの大規模サービスから、スマートフォンアプリ、組み込み機器まで、幅広い領域で利用されています。

その強力さゆえに、企業が動画処理機能を実装する際の第一選択肢となることが多いのですが、同時にライセンスと特許の複雑さでも知られています。

ライセンスが複雑な理由

FFmpeg が単一のライセンスで提供されていれば話は簡単なのですが、実際には以下の要因が複雑さを生んでいます。

#	要因	説明
1	コンポーネントごとの異なるライセンス	libavcodec、libavformat など、各ライブラリが個別にライセンスを持つ
2	外部ライブラリへの依存	x264、x265、fdk-aac など、それぞれ異なるライセンスを持つ外部コーデックを利用可能
3	configure オプションによる変化	ビルド時のオプションによってライセンスが LGPL から GPL、さらには nonfree に変化する
4	特許問題	H.264、H.265、AAC などのコーデックには特許が絡む

以下の図は、FFmpeg のライセンス構造を視覚的に示したものです。

mermaidCopy codeflowchart TB
    ffmpeg["FFmpeg プロジェクト"]

    ffmpeg --> lgpl["LGPL コンポーネント<br/>（デフォルト）"]
    ffmpeg --> gpl["GPL コンポーネント<br/>（特定機能）"]
    ffmpeg --> nonfree["nonfree コンポーネント<br/>（特定コーデック）"]

    lgpl --> libavcodec["libavcodec"]
    lgpl --> libavformat["libavformat"]
    lgpl --> libavutil["libavutil"]

    gpl --> x264lib["libx264"]
    gpl --> x265lib["libx265"]
    gpl --> postproc["libpostproc"]

    nonfree --> fdkaac["fdk-aac"]
    nonfree --> openssl["OpenSSL<br/>（3.0以前）"]

    style lgpl fill:#90EE90
    style gpl fill:#FFD700
    style nonfree fill:#FF6B6B

この図からわかるように、FFmpeg のライセンスは単純な一枚岩ではなく、選択したコンポーネントやビルドオプションによって変化します。企業での利用を検討する際は、この構造を正確に理解することが第一歩となるでしょう。

オープンソースライセンスの基礎知識

FFmpeg のライセンスを理解する前提として、GPL と LGPL の違いを押さえておく必要があります。

**GPL（GNU General Public License）**は、いわゆる「コピーレフト」ライセンスの代表格です。GPL ライセンスのコードを使用した場合、その成果物全体も GPL として公開する義務が生じます。これを「感染性」と表現することもあります。

**LGPL（Lesser GNU General Public License）**は、GPL の制約を緩和したバージョンです。LGPL ライブラリを動的リンクする場合は、アプリケーション全体を公開する必要はありません。ただし、静的リンクする場合や LGPL 部分を改変した場合は、その部分のソースコード公開義務が発生します。

nonfree は、厳密にはライセンスの種類ではなく、FFmpeg の configure オプションで --enable-nonfree を指定した場合の状態を指します。この状態では、再配布が制限されるコンポーネントが含まれるため、商用配布が実質的に不可能になります。

課題

企業が直面するライセンス問題

実務では、以下のような課題に直面することが多いでしょう。

#	課題	具体例
1	使用しているライセンスの把握漏れ	開発時に --enable-gpl を付けてビルドしていたが、法務レビューで発覚
2	動的リンク vs 静的リンクの判断	モバイルアプリでの配布方法とライセンス義務の関係
3	特許ライセンスの取得要否	H.264 エンコーダーを商用利用する際の MPEG LA への対応
4	ソースコード公開範囲の特定	GPL でビルドした場合、自社アプリのどこまで公開すべきか
5	nonfree コンポーネントの識別	どのコーデックが nonfree に該当するか

以下の図は、configure オプションによってライセンスがどう変化するかを示しています。

mermaidCopy codeflowchart LR
    start["FFmpeg ビルド開始"]

    start --> check1{"--enable-gpl<br/>指定？"}
    check1 -->|No| lgpl["LGPL<br/>再配布可能"]
    check1 -->|Yes| check2{"--enable-nonfree<br/>指定？"}

    check2 -->|No| gpl["GPL<br/>ソース公開必須<br/>再配布可能"]
    check2 -->|Yes| nonfree["nonfree<br/>再配布不可<br/>商用利用注意"]

    lgpl --> dist1["商用配布: OK<br/>ソース公開: 不要<br/>（動的リンク時）"]
    gpl --> dist2["商用配布: OK<br/>ソース公開: 必須<br/>（改変部分）"]
    nonfree --> dist3["商用配布: NG<br/>社内利用のみ"]

    style lgpl fill:#90EE90
    style gpl fill:#FFD700
    style nonfree fill:#FF6B6B

この図が示すように、ビルド時の選択が最終的な配布可能性を決定します。開発初期段階で誤った判断をすると、後から修正するのは極めて困難です。

特許の罠

ライセンスだけでなく、特許問題も重要な課題となります。多くの動画コーデックには特許が存在し、商用利用時にはライセンス料の支払いが必要になる場合があります。

主要コーデックの特許状況

#	コーデック	特許プール	商用利用時の注意点
1	H.264/AVC	MPEG LA	エンコーダー配布には年間ライセンス料が必要
2	H.265/HEVC	MPEG LA, HEVC Advance	H.264 より複雑なライセンス体系
3	AAC	Via Licensing	エンコーダー利用時に注意
4	VP9	Google（ロイヤリティフリー）	比較的安全
5	AV1	Alliance for Open Media（ロイヤリティフリー）	特許リスクが最も低い

特に注意が必要なのは、ソフトウェアライセンス（GPL/LGPL）と特許ライセンスは別物だという点です。FFmpeg 自体が LGPL でも、H.264 エンコーダーを商用配布する場合は MPEG LA への特許ライセンス料支払いが別途必要になります。

法務部門とのコミュニケーション障壁

技術者と法務担当者の間で、以下のような認識のずれが生じることも珍しくありません。

• 技術者：「LGPL だから問題ない」
• 法務担当者：「動的リンクとは？ソースコード公開の範囲は？」

このギャップを埋めるためには、技術的な実装詳細を法務用語に翻訳して説明する必要があります。例えば「動的リンク」を「実行時に外部ライブラリを読み込む方式で、アプリケーション本体とは独立している」と説明するなど、具体的なイメージが湧くように工夫することが求められるでしょう。

解決策

ライセンス戦略の立て方

企業で FFmpeg を利用する際の基本戦略は、以下の 3 つのパターンに分類できます。

1. LGPL モードでの利用（最も安全）

デフォルトの LGPL モードでビルドし、GPL や nonfree を必要とする機能は使用しない方針です。この場合、動的リンクで利用する限り、自社アプリケーションのソースコード公開義務はありません。

2. GPL モードでの利用（ソース公開前提）

x264 や x265 など GPL コーデックが必須の場合、GPL でビルドして FFmpeg に関連する部分のソースコードを公開する方針です。この場合でも、自社のビジネスロジック部分を切り離して設計すれば、影響範囲を最小化できます。

3. 社内利用限定（nonfree も許容）

社内ツールや分析基盤など、外部配布しない用途であれば、nonfree オプションも使用できます。ただし、クラウドサービスとして提供する場合は「配布」に該当する可能性があるため、慎重な判断が必要です。

以下の図は、プロジェクトの配布形態に応じた適切な戦略選択フローを示しています。

mermaidCopy codeflowchart TD
    start["FFmpeg 利用プロジェクト"]

    start --> q1{"外部配布<br/>する？"}

    q1 -->|No| internal["社内利用限定<br/>パターン 3"]
    q1 -->|Yes| q2{"GPL コーデック<br/>が必須？"}

    q2 -->|No| strategy1["LGPL モード<br/>パターン 1"]
    q2 -->|Yes| q3{"ソースコード<br/>公開可能？"}

    q3 -->|Yes| strategy2["GPL モード<br/>パターン 2"]
    q3 -->|No| alternative["代替コーデック<br/>検討<br/>（VP9/AV1）"]

    internal --> build3["--enable-nonfree<br/>使用可能"]
    strategy1 --> build1["デフォルトビルド<br/>動的リンク"]
    strategy2 --> build2["--enable-gpl<br/>ソース公開準備"]
    alternative --> build1

    style strategy1 fill:#90EE90
    style strategy2 fill:#FFD700
    style build3 fill:#FF6B6B

この図から、配布形態とコーデック要件によって、取るべき戦略が明確になることがわかります。

configure オプションの正しい使い方

FFmpeg のライセンスは、configure オプションによって決定されます。実務で使用する主要なオプションを理解しておきましょう。

ライセンス関連の主要オプション

bashCopy code# LGPL モード（デフォルト）
./configure

上記のように、何もオプションを付けなければ LGPL モードでビルドされます。これが最も制約の少ない形態です。

bashCopy code# GPL モード
./configure --enable-gpl

--enable-gpl を指定すると、GPL ライセンスのコンポーネントが利用可能になります。この場合、成果物全体が GPL となります。

bashCopy code# nonfree モード（再配布不可）
./configure --enable-nonfree

--enable-nonfree を指定すると、再配布が制限されるコンポーネントが有効になります。商用配布を予定している場合は、このオプションを使用してはいけません。

外部コーデックとライセンスの関係

外部コーデックを有効にする場合、それぞれのライセンスを把握する必要があります。

bashCopy code# x264（GPL）を使用
./configure --enable-gpl --enable-libx264

x264 は GPL ライセンスなので、--enable-gpl が必須となります。このビルドで作成したバイナリを配布する場合、GPL の義務を負います。

bashCopy code# fdk-aac（nonfree）を使用
./configure --enable-nonfree --enable-libfdk-aac

fdk-aac は nonfree に分類されるため、--enable-nonfree が必要です。このビルドは再配布できません。

bashCopy code# VP9（LGPL 互換）を使用
./configure --enable-libvpx

libvpx（VP9 コーデック）は BSD ライセンスなので、LGPL モードでも使用できます。特許的にもロイヤリティフリーなため、商用利用のハードルが低いでしょう。

ライセンス確認コマンド

ビルド後のバイナリがどのライセンスになっているかは、以下のコマンドで確認できます。

bashCopy codeffmpeg -version

出力の冒頭に configuration: という行があり、使用された configure オプションが表示されます。

plaintextCopy codeconfiguration: --enable-gpl --enable-libx264 --enable-libvpx

また、以下のコマンドでライセンス情報も確認できます。

bashCopy codeffmpeg -L

出力例は以下のようになります。

plaintextCopy codeFFmpeg version n6.0 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 11.3.0
  configuration: --enable-gpl --enable-libx264

This version of FFmpeg has GPL components enabled.
This means that the resulting binary is covered by the GPL.

このように、ビルドに使用したオプションとライセンス状態を明示的に確認できます。法務レビューの際には、この出力を証跡として残しておくと良いでしょう。

特許問題への対応

特許ライセンスの取得要否は、以下の基準で判断します。

#	判断基準	対応
1	エンコーダーを配布する	MPEG LA 等へのライセンス契約が必要
2	デコーダーのみ配布する	多くの場合は不要（要確認）
3	ストリーミング配信を行う	サービス形態によっては必要
4	社内利用のみ	基本的に不要
5	ロイヤリティフリーコーデックを使用	不要（VP9、AV1 など）

MPEG LA とのライセンス契約

H.264 エンコーダーを商用配布する場合、MPEG LA とのライセンス契約が必要になることがあります。具体的な料金体系は年間のユニット数によって変動しますが、中小企業にとっては無視できないコストになる可能性があります。

MPEG LA の公式サイト（https://www.mpegla.com/）で最新の料金表を確認できます。なお、年間 10 万ユニット以下であれば無償の範囲に含まれるケースもあるため、自社のビジネス規模と照らし合わせて検討する必要があるでしょう。

代替コーデックの検討

特許問題を回避する最も確実な方法は、ロイヤリティフリーのコーデックを使用することです。

• VP9：Google が開発したオープンなコーデック。YouTube でも使用されており、実績も十分です。
• AV1：次世代コーデックとして Alliance for Open Media が開発。特許リスクが最も低く、圧縮効率も優れています。

ただし、AV1 はまだエンコード速度が遅いという課題があるため、リアルタイム処理が必要な用途では VP9 を選択する方が現実的でしょう。

動的リンク vs 静的リンクの選択

LGPL でビルドした FFmpeg を利用する場合、動的リンクと静的リンクでライセンス義務が異なります。

動的リンク

実行時に共有ライブラリ（.so、.dll、.dylib）を読み込む方式です。この場合、アプリケーション本体と FFmpeg は独立したコンポーネントとして扱われるため、アプリケーション側のソースコード公開義務は発生しません。

javascriptCopy code// Node.js での動的リンク例
const ffmpeg = require('fluent-ffmpeg');

ffmpeg('/path/to/input.mp4')
  .output('/path/to/output.webm')
  .on('end', () => console.log('完了'))
  .run();

この例では、fluent-ffmpeg パッケージを通じて外部の FFmpeg バイナリを呼び出しています。アプリケーション本体と FFmpeg は分離されているため、LGPL の義務は FFmpeg 部分のみに適用されます。

静的リンク

コンパイル時に FFmpeg のコードをアプリケーションに組み込む方式です。この場合、アプリケーション全体が LGPL の影響を受け、ソースコード公開義務が発生する可能性があります。

モバイルアプリなど、配布物を単一バイナリにする必要がある場合は慎重な判断が求められます。iOS アプリの場合は、FFmpeg 部分のソースコードを公開し、リンク可能な形式で提供する義務が生じることがあるでしょう。

推奨アプローチ

商用プロジェクトでは、可能な限り動的リンクを選択することをお勧めします。技術的に動的リンクが難しい場合は、以下の対応を検討してください。

• FFmpeg 部分を独立したプロセスとして実行する
• GPL モードでビルドし、該当部分のソースコードを公開する
• 商用ライセンスを提供しているフォークを利用する（libav など）

具体例

ケース 1：動画配信サービス（LGPL モード）

要件

• Web ブラウザ向けに動画配信を行う SaaS サービス
• アップロードされた動画を自動的に複数フォーマットに変換
• エンコーダーの配布はなく、サーバー上でのみ使用

ライセンス戦略

このケースでは、エンコーダーを外部配布しないため、LGPL モードで十分です。VP9 や AV1 を使用すれば、特許問題も回避できます。

実装方針

サーバー側で FFmpeg を使った変換処理を実装します。

typescriptCopy code// 動画変換サービスの型定義
interface VideoConversionJob {
  inputPath: string;
  outputFormats: VideoFormat[];
  userId: string;
}

interface VideoFormat {
  codec: 'vp9' | 'av1' | 'h264';
  resolution: string;
  bitrate: string;
}

この型定義で、変換ジョブの構造を明確化します。コーデックは列挙型で限定し、意図しないコーデックが使われないようにしています。

typescriptCopy code// FFmpeg ビルドスクリプト（Docker）
import { exec } from 'child_process';
import { promisify } from 'util';

const execAsync = promisify(exec);

async function buildFFmpeg(): Promise<void> {
  const configureOptions = [
    '--enable-libvpx', // VP9 サポート
    '--enable-libaom', // AV1 サポート
    '--enable-shared', // 動的ライブラリとしてビルド
    '--disable-static', // 静的リンクは無効化
  ];

  const command = `./configure ${configureOptions.join(
    ' '
  )} && make -j$(nproc)`;

  try {
    const { stdout, stderr } = await execAsync(command);
    console.log('ビルド成功:', stdout);
  } catch (error) {
    console.error('ビルド失敗:', error);
    throw error;
  }
}

このスクリプトは、LGPL モードで VP9 と AV1 をサポートする FFmpeg をビルドします。--enable-shared により動的ライブラリとして生成されます。

typescriptCopy code// 動画変換処理の実装
import ffmpeg from 'fluent-ffmpeg';

async function convertVideo(
  job: VideoConversionJob
): Promise<string[]> {
  const outputPaths: string[] = [];

  for (const format of job.outputFormats) {
    const outputPath = generateOutputPath(
      job.inputPath,
      format
    );

    await new Promise<void>((resolve, reject) => {
      ffmpeg(job.inputPath)
        .videoCodec(
          format.codec === 'vp9'
            ? 'libvpx-vp9'
            : 'libaom-av1'
        )
        .size(format.resolution)
        .videoBitrate(format.bitrate)
        .output(outputPath)
        .on('end', () => {
          outputPaths.push(outputPath);
          resolve();
        })
        .on('error', (err) => reject(err))
        .run();
    });
  }

  return outputPaths;
}

function generateOutputPath(
  inputPath: string,
  format: VideoFormat
): string {
  const ext = format.codec === 'vp9' ? 'webm' : 'mp4';
  return `${inputPath}_${format.resolution}.${ext}`;
}

この実装では、VP9 と AV1 のみを使用しているため、特許問題もクリアしています。サーバー上での処理なので、バイナリの配布もありません。

ライセンスチェックリスト

このプロジェクトで法務レビューを通すためのチェックリストは以下の通りです。

#	チェック項目	状態	備考
1	FFmpeg のライセンス	LGPL	デフォルトビルド
2	GPL オプションの使用	なし	--enable-gpl 未使用
3	nonfree オプションの使用	なし	--enable-nonfree 未使用
4	バイナリの外部配布	なし	サーバー内のみで使用
5	特許対象コーデック	なし	VP9/AV1 のみ使用
6	ソースコード公開義務	なし	動的リンク＋配布なし

ケース 2：モバイルアプリ（GPL モード）

要件

• スマートフォンアプリで動画編集機能を提供
• H.264 エンコーダーが必須（デバイス互換性のため）
• アプリストアで配布

ライセンス戦略

H.264 を使用するため、libx264 が必要です。libx264 は GPL なので、GPL モードでビルドし、FFmpeg に関連する部分のソースコードを公開する方針を取ります。

configure オプション

bashCopy code# GPL モードで H.264 サポートを有効化
./configure \
  --enable-gpl \
  --enable-libx264 \
  --enable-shared \
  --disable-static

このビルドでは GPL モードになるため、FFmpeg を含む部分のソースコード公開が必要になります。

アプリ構成の工夫

GPL の影響範囲を最小化するため、アプリを以下のように分離します。

mermaidCopy codeflowchart TB
    app["モバイルアプリ<br/>（プロプライエタリ）"]
    wrapper["FFmpeg ラッパー層<br/>（GPL・公開）"]
    ffmpeg["FFmpeg ライブラリ<br/>（GPL・公開）"]

    app -->|プロセス間通信| wrapper
    wrapper -->|動的リンク| ffmpeg

    app --> ui["UI/UX コード"]
    app --> business["ビジネスロジック"]
    app --> api["API 通信"]

    wrapper --> encode["エンコード処理"]
    wrapper --> decode["デコード処理"]

    style app fill:#87CEEB
    style wrapper fill:#FFD700
    style ffmpeg fill:#FFD700

この図が示すように、FFmpeg を使用する部分を独立したラッパー層として切り出し、アプリ本体とはプロセス間通信で連携します。これにより、GPL の影響を最小限に抑えることができます。

ラッパー層の実装

typescriptCopy code// FFmpeg ラッパー層（GPL・公開対象）
// このファイルは GPL ライセンスでソースコード公開されます

export interface EncodeRequest {
  inputPath: string;
  outputPath: string;
  preset: 'ultrafast' | 'fast' | 'medium' | 'slow';
}

export interface EncodeResponse {
  success: boolean;
  outputPath?: string;
  error?: string;
}

ラッパー層のインターフェースを明確に定義します。この部分は GPL として公開されますが、ビジネスロジックは含まれていません。

typescriptCopy code// FFmpeg ラッパーの実装
import { exec } from 'child_process';

export async function encodeVideo(
  request: EncodeRequest
): Promise<EncodeResponse> {
  const command = buildFFmpegCommand(request);

  try {
    await executeCommand(command);
    return {
      success: true,
      outputPath: request.outputPath,
    };
  } catch (error) {
    return {
      success: false,
      error: String(error),
    };
  }
}

function buildFFmpegCommand(
  request: EncodeRequest
): string {
  return [
    'ffmpeg',
    '-i',
    request.inputPath,
    '-c:v',
    'libx264',
    '-preset',
    request.preset,
    '-c:a',
    'aac',
    request.outputPath,
  ].join(' ');
}

function executeCommand(command: string): Promise<void> {
  return new Promise((resolve, reject) => {
    exec(command, (error, stdout, stderr) => {
      if (error) {
        reject(error);
      } else {
        resolve();
      }
    });
  });
}

このラッパー層は GPL として公開されますが、単純な変換処理のみを担当し、アプリ固有のビジネスロジックは含んでいません。

アプリ本体（非公開）

typescriptCopy code// アプリ本体（プロプライエタリ・非公開）
// この部分は GPL の影響を受けず、公開不要

import {
  EncodeRequest,
  EncodeResponse,
} from './ffmpeg-wrapper';

class VideoEditor {
  private userId: string;

  async processVideo(videoFile: File): Promise<void> {
    // ビジネスロジック（非公開）
    const optimizedSettings =
      this.calculateOptimalSettings(videoFile);

    // FFmpeg ラッパーを IPC 経由で呼び出し
    const response = await this.callFFmpegWrapper({
      inputPath: videoFile.path,
      outputPath: this.generateOutputPath(videoFile),
      preset: optimizedSettings.preset,
    });

    if (response.success) {
      // 処理成功時のビジネスロジック（非公開）
      await this.uploadToServer(response.outputPath);
      await this.updateUserQuota(this.userId);
    }
  }

  private calculateOptimalSettings(file: File): {
    preset: string;
  } {
    // 独自のロジック（非公開）
    return { preset: 'medium' };
  }

  private async callFFmpegWrapper(
    request: EncodeRequest
  ): Promise<EncodeResponse> {
    // IPC 経由でラッパープロセスを呼び出し
    // 実装詳細は省略
    return { success: true };
  }

  private generateOutputPath(file: File): string {
    // 独自のファイル命名規則（非公開）
    return `/output/${file.name}`;
  }

  private async uploadToServer(
    path: string
  ): Promise<void> {
    // サーバー連携ロジック（非公開）
  }

  private async updateUserQuota(
    userId: string
  ): Promise<void> {
    // ユーザー管理ロジック（非公開）
  }
}

このように構成することで、GPL ライセンスの FFmpeg を使用しながらも、アプリ本体のビジネスロジックを非公開に保つことができます。

特許ライセンスの対応

H.264 を使用するため、MPEG LA との契約が必要になる可能性があります。具体的には、以下の情報を確認する必要があるでしょう。

• 年間の配布ユニット数
• エンコーダーの配布形態（組み込みかオンデマンドか）
• 対象地域（特許は地域ごとに異なる）

年間 10 万ユニット以下の場合は無償範囲に含まれるケースもありますが、必ず MPEG LA の公式サイトで最新情報を確認してください。

法務対応チェックリスト

#	対応項目	状態	証跡
1	GPL モードでビルド	完了	configure ログ保存
2	ラッパー層のソース公開	完了	GitHub リポジトリ作成
3	アプリ本体との分離	完了	アーキテクチャ図作成
4	MPEG LA への問い合わせ	完了	回答メール保存
5	アプリストアの規約確認	完了	規約スクリーンショット保存
6	社内法務レビュー	完了	承認メール取得

ケース 3：社内動画分析ツール（nonfree 許容）

要件

• 社内のマーケティング部門向け動画分析ツール
• 外部配布は一切行わない
• 最高品質のエンコードが必要（fdk-aac を使用したい）

ライセンス戦略

外部配布しないため、nonfree オプションも使用可能です。ただし、将来的に外部提供する可能性がある場合は、早い段階でアーキテクチャを見直す必要があります。

ビルド設定

bashCopy code# 社内利用限定なので nonfree も許容
./configure \
  --enable-gpl \
  --enable-nonfree \
  --enable-libx264 \
  --enable-libx265 \
  --enable-libfdk-aac

このビルドでは最高品質のエンコードが可能になりますが、再配布はできません。

利用ガイドラインの整備

社内ツールであっても、将来的な外部展開を見据えて、以下のガイドラインを整備しておくことをお勧めします。

markdownCopy code# 社内動画分析ツール - ライセンスガイドライン

# 利用範囲

- **許可**: 社内でのデータ分析、レポート生成
- **禁止**: 外部への配布、SaaS としての提供、顧客への提供

# 技術的制約

- FFmpeg バイナリは nonfree モードでビルドされています
- このバイナリを含む成果物は外部配布できません
- 外部提供が必要になった場合は、別途 LGPL モードでの再構築が必要です

# 問い合わせ先

- 法務部門: legal@example.com
- 技術責任者: tech@example.com

このガイドラインを社内 Wiki や README に記載し、関係者全員が理解できるようにします。

クラウドサービス化の際の注意点

将来的にこのツールをクラウドサービスとして外部提供する場合、以下の対応が必要になります。

mermaidCopy codeflowchart TD
    current["現在：社内ツール<br/>nonfree 使用"]

    future{"将来：外部提供？"}

    current --> future

    future -->|SaaS 化| rebuild["FFmpeg 再ビルド<br/>LGPL モード"]
    future -->|パッケージ配布| alternative["代替コーデック<br/>検討"]
    future -->|社内利用継続| keep["変更不要"]

    rebuild --> newconfig["--enable-libvpx<br/>--enable-libaom<br/>fdk-aac 削除"]

    alternative --> vp9["VP9/AV1<br/>への移行"]

    style current fill:#FF6B6B
    style rebuild fill:#90EE90
    style alternative fill:#90EE90
    style keep fill:#FF6B6B

SaaS 化の際は「配布」に該当するため、LGPL モードでの再ビルドが必須となることを覚えておいてください。

まとめ

FFmpeg のライセンスと特許問題は、一見複雑に見えますが、以下のポイントを押さえれば実務で適切に対応できます。

ライセンス戦略の 3 原則

1. デフォルトは LGPL モード：特別な理由がない限り、LGPL モードで運用する
2. GPL は分離設計：GPL が必要な場合は、ラッパー層として分離してビジネスロジックを保護する
3. nonfree は社内限定：nonfree は外部配布しないことを組織全体で徹底する

実務で重要なこと

#	ポイント	理由
1	configure オプションを記録する	法務レビューの証跡として必要
2	動的リンクを優先する	ソースコード公開義務を最小化できる
3	ロイヤリティフリーコーデックを検討する	特許リスクを回避できる
4	ライセンス確認を自動化する	CI/CD パイプラインでチェックする
5	法務部門との早期連携	開発後期の手戻りを防止できる

特許対応の現実的な選択肢

• VP9/AV1 の採用：特許リスクがなく、圧縮効率も優秀
• MPEG LA への確認：年間ユニット数が少なければ無償の可能性あり
• デコーダーのみの提供：エンコーダー配布に比べてライセンス料が低い

開発初期段階でのチェックリスト

プロジェクト開始時に以下を確認しておくことで、後々のトラブルを防止できます。

• 配布形態を明確化する（パッケージ配布、SaaS、社内利用）
• 必要なコーデックをリストアップする
• 各コーデックのライセンスと特許を調査する
• 法務部門にライセンス戦略を相談する
• configure オプションを文書化する
• CI/CD でライセンスチェックを自動化する

FFmpeg は非常に強力なツールですが、その力を適切に活用するためには、ライセンスと特許への正しい理解が不可欠です。本記事で紹介した実務的なアプローチを参考に、皆さんのプロジェクトでも安全かつ効率的に FFmpeg を活用していただければ幸いです。

技術者と法務担当者が共通言語で対話できるようになれば、プロジェクトはよりスムーズに進むでしょう。ライセンス対応を「面倒な制約」ではなく「プロジェクトを成功に導くための設計要素」として捉えることで、より良いアーキテクチャが生まれるはずです。

関連リンク

• FFmpeg 公式サイト
• FFmpeg ライセンスとビルドオプション
• MPEG LA - H.264/AVC Patent Portfolio License
• GNU General Public License (GPL)
• GNU Lesser General Public License (LGPL)
• Alliance for Open Media - AV1
• x264 公式サイト
• libvpx (VP9) GitHub リポジトリ
• Open Source Initiative - ライセンス一覧