MongoDBが提起した特許訴訟は、オープンソース互換プロジェクトに対する新たなリスクなのか？

投稿者:Shuji Sadoカテゴリー:Index、License Compliance、未分類タグ:、、、、、

MongoDB社がFerretDB社を提訴した件は、一般にはMongoDBの名称やブランドの使い方、あるいは「MongoDB互換」「MongoDBの代替」といったマーケティング上の表示の問題として受け取られている傾向がある。実際、MongoDB社自身も、FerretDB社のマーケティングが開発者に誤認を与え、MongoDBのブランド価値を損なうものだと強く主張している。

しかし、訴訟の構造を見ていくと、それだけの問題であると認識するのは不十分と言わざるを得ない。公開された訴状では、請求原因のうち大きな部分が特許侵害に割かれており、MongoDB社はFerretDB社の実装や提供行為が自社の特許を侵害していると主張している。つまり本件は、単に「互換性の表示が適切だったか」「MongoDBの名称をどこまで使えるか」という争いに留まらず、MongoDB互換を成立させるための技術的な実装領域そのものが特許の観点から問題視されている事件である。

この点は、オープンソースの文脈では特に重要である。表示や商標の争いであれば、表現の修正や是正によって比較的早い段階で着地する余地がある。これに対し、特許侵害が中心に据えられると、問題は宣伝文句の適否ではなく実装そのものへ移ることになる。互換製品としてユーザーに価値を与えるために必要な機能が特許クレームの射程に入るなら、訴訟の意味は大きく変わる。

本稿では、まず訴訟の経緯と現在の状況を確認し、その上でMongoDB社が何を問題にしているのかを法務面から整理しつつ、この事件がオープンソース互換プロジェクトにとってどのような新しい特許リスクを示しているのかを考えていく。

  1. 訴訟に至る経緯と現在の状況
  2. この訴訟で何が問題にされているのか
  3. オープンソース互換プロジェクトにとって何が新しいのか
  4. AGPLとの関係、及び何故違和感が強いのか
  5. まとめ
  6. 参考

English version: https://shujisado.org/2026/07/15/mongodb-v-ferretdb-when-open-source-compatibility-becomes-a-patent-risk/

訴訟に至る経緯と現在の状況

公開されている2023年11月3日付の警告書簡を見ると、MongoDB社は提訴よりかなり前の段階から、FerretDB社に対して複数の法的論点をまとめて突きつけていた。そこでは、MongoDB互換をうたう表示、MongoDB関連文書や仕様の利用、そして特許侵害が一体の問題として扱われている。

特に特許について、MongoDB社は、自社の米国特許が集約フレームワークや非リレーショナル・データベースにおけるデータの読み書きに関係していると述べていた。しかも、警告はこの一通で終わっていない。訴状によれば、2023年11月29日には第2信が、2025年5月16日にはMongoDB社が主張する特許クレームとFerretDB製品を対比するクレームチャートを含む第3信が送付されている。したがって、本件の特許論は提訴時に突然持ち出されたものではない。少なくとも2023年の段階で、MongoDB社はFerretDB社に対し、互換実装そのものが自社特許に抵触し得るという立場を示し、提訴の直前にはクレーム単位の対応表まで提示していたことになる。

その後、MongoDB社は2025年5月23日にデラウェア連邦地方裁判所へ提訴した。公開ドケットでは、この事件は特許侵害を原因とする訴訟として整理されている。訴状の構成を見ても、請求原因6本のうち4本が特許侵害であり、残る2本はランハム法上の虚偽広告と、デラウェア州法 (6 Del. C. § 3313)に基づく商標希釈である。連邦商標法上の商標権侵害の請求は含まれていない。少なくとも外形上では、本件の法的な重心が特許側に置かれていることは否定しがたい。

手続面では、FerretDB社の応答期限が数度延長された後、2025年9月17日に答弁書と反訴が提出された。MongoDB社は反訴の一部に対する却下申立てを行ったが、FerretDB社が2025年11月5日に修正版の答弁書と反訴を提出したため、その申立ては判断の実益を失ったもの(moot)として却下されている。

修正版の反訴は11本からなる。うち8本は、4件の対象特許それぞれについて非侵害および無効の確認判決を求めるものであり、FerretDB社は無効主張の中で先行技術にも言及している。残る3本は攻守を反転させたもので、MongoDB社によるランハム法上の虚偽広告、名誉毀損・営業誹謗、そして取引関係への不法妨害を主張する。この中でFerretDB社は、MongoDB社のブログ記事や見込み顧客宛ての書簡が中傷キャンペーンにあたり、その結果、Linux Foundationにおけるオープンソース・データベース協業から排除されたとまで主張している。FerretDB 2.xがMicrosoftのDocumentDB拡張(後にLinux Foundationへ移管された)を基盤としていることを踏まえると、事実認定は今後の問題であるにせよ、この主張が指し示す構図の意味は小さくない。

これに対しMongoDB社は2025年12月3日、反訴のうち虚偽広告、名誉毀損、不法妨害の3本についてのみ、二度目の却下申立てを行った。特許の非侵害・無効の確認判決請求8本には向けられていない。その理論構成も本稿の関心から見て興味深い。MongoDB社は、特許権者が市場で自社特許の侵害を主張するコミュニケーションは連邦特許法によって条件付きで保護されており、その主張が客観的に根拠を欠き、かつ特許権者がそれを認識していたという「悪意」の具体的な事実主張がない限り、州法上の不法行為責任やランハム法上の責任は連邦特許法に専占される、と論じている。特許を持つ側は「侵害だ」と市場で言い回ること自体についても手厚く守られている、という主張である。この申立てをめぐる書面のやり取りは2026年1月6日に完了し、MongoDB社は口頭弁論も要請したが、本稿執筆時点(2026年7月)で、公開ドケット上に裁判所の判断はまだ現れていない。

一方、事件そのものは前に進み始めている。2026年4月28日、担当のNoreika判事は口頭命令により、当事者に対して30日以内にスケジューリング・オーダー案を協議・提出するよう命じ、最終的な侵害・無効主張の整理、クレーム解釈チャートの提出、クレーム解釈ヒアリング、専門家ディスカバリの順序に至るまで、手続の枠組みについて詳細な指針を示した。つまり本件は、和解や早期終結ではなく、ディスカバリとクレーム解釈という特許訴訟の本体に向かって動き出している。

もっとも、2025年12月の時点でディスカバリは一切行われていないとMongoDB社自身が書面で述べているとおり、事件はまだ入口にある。公開ドケットの範囲では、本稿執筆時点でも、FerretDB社のどの実装がMongoDB社のどの特許請求項を満たすのかという核心部分は、まだ公に裁かれていない。

この訴訟で何が問題にされているのか

本件が誤解されやすい理由の一つは、MongoDB社が商標や表示の論点を強く前面に出していることである。MongoDB社の公式ブログは、FerretDB社が自社製品をMongoDBの置き換え製品であるかのように見せ、MongoDBの名称やブランドを不適切に利用して開発者を誤認させていると主張している。2023年の警告書簡でも、「MongoDBのドロップイン置換である」といった表現が問題視されている。このような説明だけを見ると、本件はFerretDB社の宣伝手法やブランド利用が主因であるように見えやすい。実際、商標や表示の論点は本件に存在する。互換製品が元製品の名称をどこまで使えるか、どのような表現なら誤認を招かないかは、法務上も実務上も重要な問題である。

しかし、MongoDB社の主張はそこでは終わらない。MongoDB社は公式ブログで、FerretDB社が集約パイプラインの処理・最適化や、書込み処理の信頼性向上に関わるMongoDB社の特許を侵害していると明記している。実際、訴状が侵害の根拠として挙げているのは、$groupや$unwindといった標準的な集約ステージをサポートしていることを示すFerretDB自身のドキュメントである。つまり、MongoDBクエリ言語の標準機能を実装していること自体が、侵害主張の出発点として扱われている。このように、MongoDB社の立場から見ると、本件は「誤解を招く表示」の事件であると同時に、「互換製品を成立させるための技術的中核を無断で利用している」事件でもある。ここを落とすと、本件の重みは理解しにくい。

法務上の論点を整理すると、少なくとも三つの層がある。第一に、名称、互換性表現、ブランド利用に関する表示・商標の問題がある。第二に、MongoDBのコミュニティ版や関連文書の利用態様をどう評価するかという著作権・ライセンスの問題がある。第三に、そして本件で最も重いのが、FerretDB社の実装やその提供行為がMongoDB社の特許クレームを満たすかどうかという問題である。

もっとも、この第二の層は2023年の警告書簡では持ち出されたものの、訴状の請求原因としては採用されていない。コードを複製していない独立実装に対して、著作権やライセンスを法的な武器として構成することの難しさを、MongoDB社自身が示した形とも言える。そして、だからこそ武器は特許に絞られた、と読むことも可能である。前二者には、表示の修正や運用変更によって一定程度切り分けられる余地がある。だが、第三の問題は、互換製品の提供価値そのものに食い込む。仮に特許侵害が認められれば、単なる表示修正では済まない。実装変更、機能制限、ライセンス交渉、あるいは事業継続そのものへの影響が生じ得るからである。

オープンソース互換プロジェクトにとって何が新しいのか

訴状で特定されている特許は4件であるが、本件の重要性はそれらの特許が狙っている領域にある。米国特許第8,996,463号 (2015年3月31日発行)、第9,262,462号 (2016年2月16日発行)、第10,031,956号 (2018年7月24日発行)の3件は、いずれも「Aggregation Framework System Architecture and Method」と題する集約フレームワーク特許であり、第10,866,868号（2020年12月15日発行）は「Systems and Methods for Optimization of Database Operations」と題し、書込みの失敗を検知して同一の書込みを再実行する仕組み、いわゆるretryable writesに向けられている。これらはいずれも周辺的な機能ではなく、MongoDB互換をうたう製品であれば、利用者が当然に期待しやすい中核領域であると考えられる。

もちろん、実際にFerretDB社の実装がMongoDB社の特許請求項を満たすかどうかは、今後の訴訟で判断されるべき問題である。クレーム解釈、実装の具体的内容、先行技術等との関係を見なければ、結論を断定することはできない。しかし、本件の本質は、最終的にMongoDB社が勝つかどうかだけではない。重要なのは、互換製品としての価値を支える機能領域が、特許訴訟の主戦場に置かれているという構図そのものである。

互換プロジェクトは、既存ユーザーの移行コストを下げ、既存のツールや運用資産を活かし、特定ベンダーへのロックインを緩和することによって価値を持つ。そのためには、単に接続のインターフェースだけを似せるのでは足りず、実際に使われる機能の中核に近づかざるを得ない。ところが、その中核部分が特許クレームの射程に置かれるなら、互換性の価値そのものが法的リスクに変わる。

さらに、訴状の射程はFerretDB社に留まらない。MongoDB社は、対象製品を通常の意図された方法で使用するユーザー自身が直接侵害者であり、FerretDB社はそれを誘発し、寄与する間接侵害者であるという理論を採っている。Apache 2.0で配布される互換実装を「採用する側」までが侵害理論の射程に入るのだとすれば、これは互換製品を開発する者だけでなく、それを選定・導入する企業のリスク評価にも直接響いてくることになる。加えて、MongoDB社が求める救済には損害賠償だけでなく予備的・終局的差止めが含まれており、狙いが金銭的な清算ではなく提供行為の停止にあることも読み取れる。

この状況は、コードの複製やライセンス条件違反が問題となる従来の争点とは性質が異なると言わざるを得ない。著作権であれば、クリーンルーム実装という発想が比較的分かりやすいが、特許は独自実装であっても侵害が成立し得る。つまり、「コードはコピーしていない」というだけでは防御として足りない可能性があり、この点がオープンソース互換プロジェクトにとって大きな不確実性となる。

そして、この構図は、AIコーディングの爆発的な普及が起きている現在においてはさらに重みを増す。念のために言えば、本件自体がAIコーディングを念頭に起こされたという証拠はない。FerretDB社の設立は2021年、最初の警告書簡は2023年である。しかし、AI支援によって、既存製品と機能的に等価な独立実装を短期間・低コストで書き上げることは、今後ますます容易になっていく。コードを一行も複製せずに互換ソフトウェアを作るという営みは、もはや特別で例外的な労力を要する挑戦ではなくなりつつあるのである。もっとも、特許はコードの由来を問わず、人間が書いたのか、AIが書いたのか、クリーンルームだったのか、実装の独立性は特許侵害の成否に影響しない。独立実装のコストが下がれば下がるほど、既存ベンダーにとって独立互換実装を止める実効的な手段は特許に収斂していく。本件が示す特許前面型の戦略は、AIコーディング時代にこそ一般化しやすいと見るべきだろう。

AGPLとの関係、及び何故違和感が強いのか

この事件がコミュニティに対して強い違和感を与える背景には、MongoDBのライセンスの履歴がある。MongoDBの公式READMEでは、2018年10月16日より前にリリースされた版はGNU AGPLであり、それ以後の版は過去版向けの修正を含めてSSPLで公開されると説明している。SSPL FAQにおいても、2018年10月16日以前のMongoDB Community ServerはAGPLのままであり、それ以後の版はSSPLであると述べている。

この時系列を本件で主張されている特許と重ねてみると、構図はより立体的になる。4件の対象特許のうち、3件の集約フレームワーク特許はいずれも、コミュニティ版がAGPLだった時代、すなわち2018年10月16日より前に発行されている (2015年3月、2016年2月、2018年7月)。しかも、特許が覆う機能自体もAGPL時代のリリースで出荷されたものである。集約パイプラインはMongoDB 2.2 (2012年)で導入され、retryable writesもMongoDB 3.6 (2017年)で導入された。つまり、本件で武器となっている特許は、まさにAGPLの下で長年公開され、改変も再頒布も認められてきた機能を覆う特許なのである。

ここで重要なのは、AGPL第11条が特許ライセンス条項を含んでいることである。AGPL第11条の許諾は、AGPLの条件を遵守して「貢献者版」を実行・改変・頒布する場合に、当該貢献者が保有または支配する「必須特許クレーム」へ及び得る。したがって、AGPL版MongoDBをその許諾範囲内で利用する場合には一定の特許保護を受け得るが、追加的改変によって初めて侵害するクレームや、独立に書かれた互換実装一般まで当然に許諾するものではない。

本件との関係に限れば、結果として、MongoDBのコードを利用するAGPL版の方がMongoDB自身の必須特許クレームについて明示的な許諾を受けやすく、独立互換実装の方がその許諾を利用できないという逆説が生じ得る。したがって、SSPL移行前のMongoDBをフォークし、そのコードのまま集約機能を使い続ける行為は、特許の観点ではむしろ守られている。危険なのは、コードを一行も複製していない独立再実装のほうなのである。コードの複製度合いと特許リスクが逆相関するという構図は、一般におけるオープンソース的なリスクの直感に反するものではあるだろう。

法解釈上はそうであっても、コミュニティの感覚は単純ではない。AGPL時代のMongoDBに接してきた開発者からすると、「長く公開され、改変・再頒布も認められてきた実装領域なのだから、少なくともその周辺で互換実装を作ることが、主要な特許攻撃の対象になるとは思いにくい」という感覚が生まれやすい。対象特許の大半がAGPL時代に成立し、対象機能がAGPL版として出荷されていたという事実は、この感覚に一定の説得力を与える。しかし、実際にはAGPLの特許許諾は独立に書かれた互換実装一般に当然に拡大されるわけではない。このズレこそが、本件に対して「以前からリスクはあったが、それが主たる攻撃手段として使われるとは想定されていなかった」という印象を与えることになる。

まとめ

本件は、FerretDB社の表示やブランド利用に関する争いでもある。しかし、それだけであると理解してしまうと本質を取り逃がすことになる。公開ドケット、MongoDB社の公式説明、そして2023年以降の警告書簡を突き合わせる限り、本件の重心は、MongoDB互換として価値を持つ実装領域が特許で争われている点にある。そして2026年に入り、事件はクレーム解釈と本格的なディスカバリに向けて動き出している。互換実装の中核機能と特許クレームの射程が正面から突き合わされる局面はこれから来ることになる。

この構図が深刻なのは将来への示唆である。もし、長く公開されてきた実装領域に関する特許が、互換プロジェクトに対する主要な攻撃手段として一般化していくなら、オープンソース互換プロジェクトは、著作権やライセンス条件だけでなく、既存製品の特許ポートフォリオまで前提にして設計しなければならなくなる。AIコーディングの普及が独立互換実装のコストを下げ続けるのだとすれば、この圧力は弱まるどころか、強まる方向にしか働かないだろう。

そうなれば損なわれるのは、一つのスタートアップの事業継続の問題だけではない。開発者が、公開されて育った技術領域にどこまで安心して挑戦できるのかという予見可能性そのものが揺らぐ。問われるべきなのは、MongoDB社の主張が法的に成り立ち得るかだけではない。AGPL時代からの連続性の上にある実装領域について、互換実装を封じる主要手段として特許を前面に出すことが、オープンソースの信頼と競争のあり方に照らして適切なのかが問われているのである。本件は、その問いを静かだがかなり鋭い形で突きつけている。

参考