11月12日、The New Stackが「FFmpeg to Google: Fund Us or Stop Sending Bugs」と題した記事を公開した。この記事では、AIによる脆弱性報告の急増を背景に、FFmpegとGoogleの間で噴出した「オープンソースの安全性と、そのコストを誰が負担するのか」という問題について詳しく紹介されている。以下に、その内容を紹介する。
概要—「使われているのに、資金は来ない」という構図
FFmpegは動画・音声の変換、再生、編集、配信などを支える中核的なマルチメディア基盤であり、libavcodecやlibavformatなどのライブラリは、VLC、Kodi、Plex、主要ブラウザ、そしてYouTubeの動画処理基盤にも採用されている。それほど広く使われていながら、開発の大半はボランティアによって支えられており、恒常的な資金不足に直面しているという問題意識がある。
発端—AIが見つけた「極めてニッチな不具合」
議論の直接の引き金は、GoogleのAIエージェントがFFmpegに見つけた「中程度の影響度」とされる不具合だ。内容は「1995年のゲーム『Rebel Assault 2』におけるLucasArts Smushコーデックの最初の10〜20フレームのデコード問題」という極めて限定的なケースである。FFmpeg側は修正を行ったが、こうした“CVEの粗製乱造（CVE slop）”とも言える報告が雪崩のように届く一方で、修正は無償ボランティアの肩にのしかかる構造が改善しないことに強い不満を示した。
争点—企業責任とボランティア労働の境界
論点は大きく二つに整理できる。第一に、脆弱性の開示・修正プロセスの在り方である。Google Project Zero（GPZ）は2025年7月から「Reporting Transparency」を試行し、発見から1週間以内に“報告した事実”を公表し、以後90日の開示タイマーを回す運用へ移行した。これに対し、FFmpegをはじめボランティア主体のOSS側は、十分な人的・金銭的リソースがない中で強い時間的プレッシャーにさらされるのは不公平だと主張する。
第二に、巨額の利益を上げる企業が重要OSSに依存していながら、修正作業や保守体制の費用を十分に負担していない点である。FFmpeg側は「脆弱性を指摘するならパッチも添える、もしくはプロジェクトの保守を直接支援すべきだ」という姿勢を明確にした。
反論—「開示もまたコモンズへの貢献」
これに対し、ChainguardのDan Lorencは「オープンソースの公開自体がデジタル・コモンズへの貢献であり、脆弱性情報の発見と公開もまた同じコモンズへの貢献だ」と反論する。Googleはオープンソース支援を幅広く行っているとも主張し、過度な反発はむしろ支援者を遠ざけると警鐘を鳴らす。一方で、GoogleのPatch Rewards Program（パッチ報奨）については「月3件まで」など実効性の制限があるとして、FFmpeg側の不満も根強い。
波及—FFmpegだけの話ではない
記事はlibxml2の元メンテナーであるNick Wellnhoferの事例も挙げる。第三者からのセキュリティ報告対応だけで毎週数時間を費やし、無償のボランティアとしては持続不可能だとして2025年12月をもって維持を辞退するという。libxml2はブラウザ、サーバー、オフィスソフト、Linux各種パッケージにまたがる重要部品であり、ここでも「重要だが無償で支えられている」構図が限界に達しつつあることが示される。
論点の整理—「安全」と「持続可能性」の両立
AIを活用した脆弱性探索自体は、攻撃者も同様の手段を使い得る以上、守りの側にも必要である。一方で、報告が増えれば増えるほど、対応・検証・修正という重労働はメンテナーに蓄積し、資金の裏付けがなければ破綻する。結論として記事は、巨大企業がOSSから得る便益に見合う直接的な支援（保守費用、専任人員、パッチ提供など）を拡充しなければ、クリティカルな基盤OSSの維持が危うくなると指摘する。
まとめ
本件は、個別のCVEや開示ポリシーの是非にとどまらず、「AI時代のOSSセキュリティを誰がどのように担保するのか」という設計問題である。AIによる発見速度と量は今後も増す一方で、メンテナーの時間は有限である。利用規模に比例した資金提供、修正パッチの同梱、あるいはプロジェクトへの常時コミット体制など、実効性のある支援が不可欠だ。さもなくば、FFmpegやlibxml2のような基盤ソフトが維持不能となり、結果的にエコシステム全体の安全性を損なうことになる。
詳細はFFmpeg to Google: Fund Us or Stop Sending Bugsを参照していただきたい。
