■ 1. 訴訟の本質
- MongoDB社がFerretDB社を提訴した件は、商標やブランド表示の争いとして受け取られる傾向にある
- 訴状の構成を精査すると、請求原因6本のうち4本が特許侵害であり、法的重心は特許側にある
- 残る2本はランハム法上の虚偽広告とデラウェア州法上の商標希釈であり、連邦商標法上の商標権侵害請求は含まれていない
- 本件は「表示の適否」だけでなく、MongoDB互換を成立させる技術的実装領域そのものを特許の観点から問う事件である
■ 2. 訴訟の経緯と手続きの状況
- 警告書簡と提訴の経緯:
- 2023年11月3日付の第1信で、MongoDB社は特許侵害・ブランド利用・文書利用を一体の問題として提起した
- 2023年11月29日に第2信、2025年5月16日には特許クレームとFerretDB製品の対応表（クレームチャート）を含む第3信が送付された
- 2025年5月23日、MongoDB社はデラウェア連邦地方裁判所へ提訴した
- FerretDB社の応答と反訴:
- 数度の延長を経て、2025年9月17日に答弁書と反訴を提出
- 2025年11月5日に修正版答弁書・反訴（全11本）を提出
- 反訴8本は対象4特許の非侵害・無効確認判決を請求し、先行技術にも言及
- 残る3本はMongoDB社によるランハム法上の虚偽広告・名誉毀損・取引妨害を主張
- FerretDB社は、MongoDB社のブログ記事や書簡によってLinux Foundationのオープンソース協業から排除されたと主張
- MongoDB社の対抗措置:
- 2025年12月3日、反訴のうち虚偽広告・名誉毀損・不法妨害の3本についてのみ却下申立てを実施（特許関連の8本は対象外）
- 特許権者の侵害主張に関するコミュニケーションは連邦特許法で条件付き保護を受けるという理論を展開
- 手続きの現状:
- 2026年4月28日、Noreika判事がスケジューリング・オーダー案の提出を命令
- クレーム解釈ヒアリングや専門家ディスカバリに向けて手続きが進行中
- 2025年12月時点でディスカバリは未実施であり、事件は本格審理の入口段階にある
■ 3. 法的論点の構造
- 第一層（表示・商標）:
- 名称・互換性表現・ブランド利用の適否
- 互換製品が元製品の名称をどこまで使えるかという問題
- 第二層（著作権・ライセンス）:
- MongoDBのコミュニティ版や関連文書の利用態様
- 警告書簡では言及されたが、訴状の請求原因には採用されなかった
- コードを複製しない独立実装への著作権・ライセンス上の構成が困難であることを示す
- 第三層（特許）:
- FerretDB社の実装がMongoDB社の特許クレームを満たすかどうかという問題
- 本件において最も法的重量が大きい
- 侵害が認定された場合、表示修正では対処できず、実装変更・機能制限・ライセンス交渉・事業継続への影響が生じ得る
- 訴状が侵害根拠として援用したのは、$groupや$unwindといった標準的集約ステージをサポートすることを示すFerretDB自身のドキュメントであり、MongoDBクエリ言語の標準機能実装自体が侵害主張の出発点とされている
■ 4. オープンソース互換プロジェクトへの新たなリスク
- 対象特許の領域:
- 集約フレームワーク特許3件（US 8,996,463 / 9,262,462 / 10,031,956）：$groupや$unwindを含む集約パイプラインに関わる
- 書込み最適化特許1件（US 10,866,868）：retryable writesの仕組みに関わる
- いずれもMongoDB互換製品においてユーザーが当然に期待する中核機能領域
- 互換プロジェクトの構造的リスク:
- 互換プロジェクトはロックイン緩和・移行コスト低減のために中核機能の実装に近づかざるを得ない
- その中核部分が特許クレームの射程に入る場合、互換性の価値そのものが法的リスクに転化する
- ユーザー企業への波及:
- MongoDB社の理論では、互換実装を「利用するユーザー自身」が直接侵害者となり、FerretDB社は間接侵害者とされる
- Apache 2.0で配布される実装を採用・導入する企業のリスク評価にも影響する
- 求める救済に差止めが含まれており、金銭的清算ではなく提供行為の停止を狙っていることが読み取れる
- 著作権との本質的差異:
- 著作権であればクリーンルーム実装による防御が成立しやすい
- 特許は独自実装であっても侵害が成立し得るため、「コードをコピーしていない」という防御が機能しない可能性がある
- AIコーディングへの含意:
- AI支援による独立互換実装のコスト低下が進む中、既存ベンダーにとって互換実装を阻止する実効的手段は特許に収斂していく
- 本件が示す「特許前面型」の戦略はAIコーディング時代にこそ一般化しやすい
■ 5. AGPLとの関係と生じる逆説
- MongoDBのライセンス履歴:
- 2018年10月16日より前のリリースはGNU AGPL、以後はSSPL
- 集約パイプラインはMongoDB 2.2（2012年）で導入、retryable writesはMongoDB 3.6（2017年）で導入
- 対象特許3件（2015年・2016年・2018年発行）はAGPL時代に成立し、対象機能もAGPL版として出荷された
- AGPL第11条の特許許諾の範囲:
- AGPLの条件を遵守して「貢献者版」を実行・改変・頒布する場合、貢献者が保有する「必須特許クレーム」への許諾が及び得る
- ただし、独立に書かれた互換実装一般には当然に拡大されない
- 生じる逆説:
- MongoDBのコードをAGPL条件のまま利用する方が、MongoDB自身の必須特許クレームについて明示的許諾を受けやすい
- コードを一行も複製しない独立再実装の方が特許リスクが高くなる
- コードの複製度合いと特許リスクが逆相関するという構図は、オープンソースにおける一般的なリスク直感に反する
- コミュニティの違和感の源泉:
- AGPL時代から公開・出荷されてきた機能領域が、互換実装を封じる主要手段として特許で攻撃されることへの想定外感
- 法的解釈上はAGPL許諾が独立実装に及ばなくとも、「以前からリスクはあったが主たる攻撃手段として使われるとは想定されていなかった」という印象を与える
■ 6. まとめと将来的含意
- 本件の本質は表示・ブランドの問題と特許侵害の問題が重なっており、後者に法的重心がある
- 2026年に入りクレーム解釈と本格的ディスカバリに向けて手続きが進行中であり、核心部分の判断はこれから来る
- 将来への示唆:
- 長く公開されてきた実装領域の特許が互換プロジェクトへの主要攻撃手段として一般化するなら、オープンソース互換プロジェクトは著作権・ライセンス条件だけでなく既存製品の特許ポートフォリオまで前提に設計が必要になる
- AIコーディングの普及により独立互換実装のコストが低下するほど、この圧力は強まる
- 問われているのは法的成否だけでなく、AGPL時代からの連続性の上にある実装領域で互換実装を封じる主要手段として特許を前面に出すことがオープンソースの信頼と競争のあり方に照らして適切かどうかという問いである