FFmpegは、動画や音声を代表とした多数のメディアを扱うことのできるソフトウェアであり、LGPL 2.1の下で公開されている自由ソフトウェアです。主な用途としてメディアのエンコード・デコードやコーデックの変換などが挙げられます。
さて、最近アクセス可能となったMITライセンス下エンコーダー「 OxideAV 」は、LGPLが適用されるべきFFmpegのコードを参考にしMITライセンスとして公開する行為、いわば「ライセンスロンダリング」を行っていますと指摘されています。この記事では問題の概要などに関して簡単にまとめます。今後状況が大きく変わりうる内容ではありますが、参考になれば幸いです。
結論
- 「OxideAV」は5月にソースがアクセス可能となったRust製のエンコーダーでMITライセンス下で利用可能に
- FFmpegの開発者がライセンス違反・ライセンスロンダリングを指摘
- 「Mt.Gox」CEOのマルク・カルプレスがOxideAVを公開
ライセンスとクリーンルーム
自由ソフトウェア・オープンソースソフトウェアの大半においては、ライセンスが設定されています。ライセンスが存在しない形でもソフトウェアを公開すること自体は可能ですが、その場合においては基本的に良いソフトウェアであったとしても許可を得る必要があり極めて煩雑です。このため「この条件さえ守れば、いちいち作者の許可を取らなくても自由に使って良い」というルールをあらかじめ明文化したライセンスを設定することで再利用を容易にすることが可能となっています。また、そのソフトウェアがどのように利用されてほしいかという意思を示す手段でもあり、例えば改変した先においても自由であることを強制することで自由を担保するのか、改変した先でオープンにする必要が無い状態にすることこそが自由であるとするのか、といったスタンスを見せることが出来ます。
代表的なライセンスとして、BSDライセンス・MITライセンス・GPLなどがあり、必要に応じて適切なライセンスが選択されています。しかし、こうしたライセンスを遵守しようと努めていても、特定の機能を実現するために実装を行った結果、既存のソフトウェアのコードとほぼ同等になってしまい、意図せず著作権侵害やライセンス違反となってしまうリスクが常に存在します。
近年はコーディングAIの発達により、意図せずに著作権侵害が行われてしまう可能性があります。これはGitHub Copilotが出始めた2022年の頃から懸念されていました。さらに、意図的にライセンスを回避するために、コーディングAIを用いて既存のライブラリと同様のものを作成する場合があり、MALUSのような批判が行われているものもあります。
こうした問題を避けるために行われる実装手法の1つに「クリーンルーム設計」があります。自由ソフトウェアにおいて有名な事例としてWindowsと互換性のあるOSを目指すプロジェクトであるReactOSがあります。2006年1月に逆アセンブルによって得られたコードがある可能性が指摘された後、新たな問題の発生を防ぐために、開発者に対して「クリーンルーム設計のみで実装を行う」旨の誓約を求める措置を講じています。
OxideAV
OxideAVは、遅くとも4月中旬に開発が開始され、記事作成時点（2026年5月6日15時）で124リポジトリに分かれた多様なコンポーネントを組み合わせた「純Rustのメディア変換及び配信」を行うソフトウェアで、MITライセンスでライセンスされているとのことです。大半のコミットはMark Karpelèsと名乗るアカウント及びClaudeによって行われており、 コーディングAIの力を活用した開発 が行われたと考えられます。公式サイトによれば、
- Containers: MP4 · Matroska / WebM · Ogg · AVI · FLAC · MP3 · WAV / slin · IFF / 8SVX · PNG / APNG · GIF · JPEG · WebP · AMV · MOD · S3M
- Audio: PCM · AAC-LC · FLAC · Vorbis · Opus · CELT · Speex · MP1 / MP2 / MP3 · GSM · G.711 · G.722 · G.723.1 · G.728 · G.729
- Video: MJPEG · FFV1 · MPEG-1 · MPEG-4 Part 2 · H.263 · H.264 (partial) · H.265 (parse) · AV1 (parse) · VP8 · VP9 (partial) · Theora · ProRes 422 · AMV
- Image: PNG / APNG · GIF · WebP (lossy + lossless) · JPEG
- Subtitles: SRT · WebVTT · ASS / SSA · TTML · SAMI · MicroDVD · MPL2 · MPsub · VPlayer · PJS · AQTitle · JACOsub · RealText · SubViewer 1/2 · EBU STL · PGS · DVB · VobSub
に対応しており、同様の機能を提供するFFmpegと比較すれば機能は劣りますが、多種多様なフォーマットに対応していると言えます。2000年12月に初版が公開された後に、多くの人々による積極的なコントリビュートが行われ、25年以上経った現在でも重宝されている自由ソフトウェアですが、 1ヶ月もない中でこのような追いつきが可能になったという事実は驚かされる ものと言えます。動作を直接確認してはいませんが、もし本当に動作し、著作権的にも問題ないものであれば、まさしく新時代を切り開いたものであると言えるでしょう。しかしながら、5月6日にFFmpegはXに以下の投稿を行っており、著作権侵害の疑惑を訴えています。
Paul Mahol painstakingly reverse engineered this codec by hand and gave it the LGPL licence so that improvements remained open source.
— FFmpeg (@FFmpeg) May 5, 2026
The person running this AI thought little of this.
当該Issueにおいてはシンプルな形で「Where is docs/video/magicyuv/magicyuv-trace-reverse-engineering.md located?」とFFmpegの開発者であるPaul B Mahol氏が問う形で指摘が行われています。これは当該リポジトリのREADMEにおいて「Pure-Rustで実装されたMagicYUVロスレス・イントラ専用動画デコーダおよびエンコーダです。 docs/video/magicyuv/magicyuv-trace-reverse-engineering.mdに記載されている動作トレースを基に、クリーンルーム環境で実装 されました。C言語の依存関係は一切なく、サードパーティ製の外部ライブラリも一切参照していません。」と主張しているのに関わらず、リポジトリ内にdocsディレクトリそのものが無いためです。
FFmpegはX上で「FFmpeg開発者のポール・マホルは、AIがC言語で書かれた自身のコードをRust言語に書き換えることや、LGPLをMITライセンスに変更することについて、法的に問題のある行為である」とした上で「改良版がオープンソースのまま維持されるようLGPL」としたと記しています。この観点によれば、OxideAVはFFmpegのソースコードをAIを用いてRustへと書き換えた上、FFmpegに対して謝辞等を示さず、MITライセンスで公開したということになります。もし本当にそうであれば、クリーンルーム実装が行われていないことも明らかとなり、書かれていることの信頼そのものも難しくなってしまうと思われます。
これに対してMagicalTux氏は6日16時17分に以下のように返信を行っています。翻訳は私によるものですので、詳細は原文をご覧ください。
ご指摘ありがとうございます。方法論への批判は正当なものであり、それを踏まえて対応を進めています。
法的な立ち位置について。ワイヤフォーマット上の事実 — FOURCC 値、バイト列挙値、プレディクタ ID、デコーダが従わざるを得ない構造体レイアウト — は著作権の対象にならないという狭義の論点については、Feist v. Rural (1991) において十分な根拠があり、API 再実装の問題は Google v. Oracle (2021) においてその大部分がフェアユースの論点として処理されました。したがって厳密に著作権の問題としては、既存の資料がそれ自体として侵害に当たっていたとは考えていません。
しかし、これは私が頼りにしたい防御ではありません。境界線をめぐって法廷で争わずに済むようにするためにクリーンルームというものが存在するのです。以前のトレース文書は、クロスチェックのために
libavcodec/magicyuv.cを読みながら執筆されたものであり、レイアウトに関する疑問を解消するために同ファイルへの一度限りの暫定パッチを含んでおり、FFmpeg 内部の識別子 (magy_decode_slice10、ff_vlc_init_multi_from_lengths) を名指ししていました。そこに含まれる個々の事実の扱いがどうであれ、その方法論は弁護に耐えうるクリーンルームと呼べるものではなく、「ダーティルーム」と評されても仕方ありません。 oxideav-core のコミット9a23e86のメッセージ "matching ffmpeg's AV_PIX_FMT_GBRPLE family" は、その上にさらに自ら招いた証拠上の問題を重ねるものでした。変更点について。
- トレース文書は本日削除しました: OxideAV/docs@
937a346。履歴には残りますが、今後のクリーンルーム作業者にとっては禁止入力です。- 既存の
video/msmpeg4/ワークスペースを参考にしたクリーンルーム作業空間をdocs/video/magicyuv/に整備しました。壁で隔離された4つのエージェント役割（仕様策定/抽出/監査/実装）、役割ごとの明示的な許可リストおよび禁止入力リスト、成果物単位での出所追跡を備えています。- 依拠する情報源は、プロプライエタリのMagicYUVバイナリと、 magicyuv.com のベンダー作成ドキュメントとします。 FFmpegのソースコードはいかなるパス下からも除外し、削除済みのトレース文書も除外、 FFmpeg から派生したコミュニティ作成のサマリも除外、問題の oxideav-core コミットメッセージも禁止入力リストに載せています。本リポジトリの Implementer は、クリーンルーム成果物の
spec/およびtables/の出力のみを参照します。- 汚染された分析にまで遡れる本リポジトリのRustコードは破棄し、書き直します。今後のコミットメッセージは FFmpeg の識別子を参照しません。
言い訳ではなく、文脈として。 OxideAVはGitHub上にありますがユーザーは一人もおらず、プロジェクトは実験段階で、誰かが使えるような状態にはまだなっていません。汚染を抱えたまま前に進めるのではなく、ここで適切にやり直すべきまさにそのタイミングです。
Paul B. Mahol さんへ。あなたがFFmpegに書かれたMagicYUVのデコーダ (2016) およびエンコーダ (2017) は素晴らしい仕事であり、私たちの分析の出発点となるインスピレーションでした。私たちの分析がそれらを利用したやり方は、本来あるべき壁を尊重するものではありませんでした。お詫び申し上げます。再構築はあなたのコードを読まずに行います。
クリーンルームの各ラウンドが完了し、置き換え実装がマージされ次第、ここに続報を投稿します。
ここにおいてはあくまで著作権法上の問題ではないことを主張した上で、クリーンルーム設計に大きな欠陥が存在したことを認め再構築を行う旨が示され、FFmpegの開発者であるPaul B Mahol氏に対する謝罪の言葉も記されています。現在必要とする作業が完全に終了していないとのことで、今後とも当該Issueにおいて状況が報告される見込みです。なお、現時点でMagicalTux氏が問題を認めているのはMagicYUVデコーダの実装に関する部分のみであり、OxideAV全体の他コンポーネントについて同様の問題があるかは明らかになっていません。
マルク・カルプレス氏とOxideAV
先にも触れた通り、このOxideAVはMark Karpelèsと名乗るアカウント（MagicalTux）が主体となって開発が行われています。GitHubのプロフィールによれば東京に在住しているとのことです。東京に住んでいるMark Karpelèsさんとして有名な人に、マルク・カルプレス氏がいます。彼は2011年に買収してCEOになった後、2014年に約85万ビットコイン（世界に存在しうるビットコインのおよそ4%）が盗難されたとしたMt.GoxのCEOであり、現在はKarpelès Lab社などで事業を行っています。
マルク・カルプレス氏に対してメール及びXにおけるChat機能を用いて確認を試みましたが、Xアカウント上で公開されているメールアドレス（ contact [at] magicaltux.net ）は連絡不能でありChatは送信することが出来ませんでした。なお、GitHub上の当該アカウントはMtGoxのオーガニゼーションに所属している他、Karpelès Labのオーガニゼーション上で多数のコミットを行っていることを確認しております。Karpelès Lab社を介して確認を試みましたところ、本人であることを認めた上で、上記の返信の通りの対応を行っているとの連絡がありました。
関連リンク
- questionable LICENSE · Issue #3 · OxideAV/oxideav-magicyuv - FFmpeg開発者によるライセンスに関する疑問
- OxideAV — Pure-Rust media framework - GitHub Pages上でホストされている「公式サイト」
最後に
前回の技術に関する記事: Claude Codeに「ルーティン」機能が追加、パッケージ化された自動処理をクラウド上で実行可能
Karpelès Lab社宛に確認を取ったところ、同社としては実験段階のソフトウェアであり利用者を想定したリリースは行っておらず公式な発表を行っていないとのことです。確かにそうであるとしたらば現にソースはGitHubにホストされており、MITライセンス下にあるとされているのであれば、誰でも利用可能であることには変わりないと思われます。利用者を想定したリリースは行っておらず公式な発表を行っていないとしても、MITライセンス下に置くと宣言してしまったからには一定の責任があるのではないでしょうか。
また、今回の件に限らずAIはこれまでとは比較にならないスピードでのコーディングを可能としており、今後もこういった事例は増えていくでしょう。AIという強力なツールをどのように活用し、著作権者の権利とどう折り合いをつけていくのかは、これからの人類が背負う大きな課題となります。今後とも作者に対して敬意を持ったソフトウェアの存在が続いていくと良いのではないかと思います。
