10 ポイント 投稿者 GN⁺ 2025-09-11 | 1件のコメント | WhatsAppで共有
  • Supabase が OrioleDB 特許の最終取得を完了
  • 米国特許 10,325,030(Durable multiversion B+-tree)の非独占的ライセンスを OrioleDB のすべての利用者に提供
  • OrioleDB は Postgres の既存ストレージエンジンを置き換える 高性能拡張機能 で、クラウド環境での性能とスケーラビリティを大幅に向上
  • このプロジェクトは オープンソース として継続して開発され、Postgres コミュニティとの協業を通じて標準化とコア統合を目指す
  • 特許ライセンスは 知的財産(IP)保護 を目的としており、オープンソースに対する脅威に対応する「盾」の役割を果たす

OrioleDB 特許公開と買収の背景

  • Supabase は OrioleDB の完全な法的買収手続きを最近完了した
  • 米国特許 10,325,030 (Durable multiversion B+-tree) を含むすべての権利を保有することになった
  • 現在 Supabase は、OrioleDB およびすべてのフォーク(商用サービスを含む)の利用者に対して、この特許を非独占的に正式提供している
  • このライセンス方針は OrioleDB ライセンスに基づいて適用されている

OrioleDB の概要と性能

  • OrioleDB は Postgres のプラガブルストレージシステム を活用するストレージ拡張機能
  • 既存の Postgres ストレージエンジンを置き換える ドロップイン方式 で動作する
  • 最新ハードウェアおよび クラウドインフラ最適化 により、Postgres の性能とスケーラビリティを最大化する
  • 公式ベンチマークによれば、Heap エンジン比で約 5.5 倍高速な性能(TPC-C、500 warehouses 基準)を示す
広告

プロジェクトの開発方針とオープンソースポリシー

  • Supabase は OrioleDB チームとともに Postgres ファースト戦略 で高性能ストレージエンジン開発に注力している
  • OrioleDB は オープンソースプロジェクト であり、誰でもコード、ドキュメント、テスト、Issue などに貢献できる
  • 目的は Postgres の Table Access Method API に基づくドロップインストレージエンジンを完成させること
  • Postgres コミュニティとの協業を通じて、OrioleDB を拡張モジュールとして 標準化しメインラインに統合 することを進めている

ライセンスおよび IP 互換ポリシー

  • OrioleDB ライセンスは PostgreSQL ライセンス をベースに作成されている
  • Supabase は、すべての OrioleDB 利用者が特許(US 10,325,030)を自由に利用できるよう、非独占ライセンスを提供している
  • この特許は、オープンソースを脅かす 敵対的な IP 訴訟から防御 するための「盾」という性格を持つ

Postgres と歩調を合わせた発展戦略

  • OrioleDB は Postgres 自体と競合することを目的としておらず、Postgres の機能と性能を向上 させることを目標としている
  • 長期的には Postgres 公式ストレージに OrioleDB が統合される ことが理想的な方向性
  • そのために ストレージエンジン拡張性に関するパッチ作業 を Postgres コミュニティと継続的に協力している
  • 性能・安定性の改善と本番環境での検証、ドキュメント整備、オンボーディング強化を着実に進めている
  • ベンチマーク、移行ノート、実運用フィードバック の共有、技術コミュニティでの活発な議論、実際に試してみること、Issue/PR への貢献を広く奨励している

1件のコメント

 
GN⁺ 2025-09-11
Hacker Newsの意見
  • 特許とコードをざっと見た限り、ほぼすべての研究が以前に複数の研究者たちによって行われてきた研究から取られているように感じた
    他人のものを盗んでおいて善意で皆と共有すると言っても、結局はただの窃盗にすぎない
    米国特許商標庁で特許承認の判子をもらったからといって、本当に新しいものを発明したことにはならない
    むしろ行政担当者を説得して、他人の研究を自分のものだと主張する根拠を得ただけだ
    正しい側に立ちたいなら、この特許を放棄し、自分が盗もうとした研究コミュニティに謝罪すべきだ

    • どうやってそんな結論に至ったのか気になる
      特許本文に出てくる内容の大半は、よく知られたことばかりであるのが普通だ
      重要なのは、特許請求の範囲に新規性のある内容が含まれているかどうかだ
      特許の説明は、その分野の通常の専門家が再現できるだけ十分でなければならず、単に以前の論文に同じ手順が見つかるという程度では不十分だ
      弁護士がどこまで詳細に書くかはケースごとに違い、CPUやプログラムのようなものを冗長に説明しなければならない場合もある
      論争を避けるには、よく知られた手法も書いておく方がよく、そうでないと後になって些細なことで法廷闘争になることがある

    • Supabaseに対して厳しすぎる評価だと思う
      研究は重要だが、USPTOに「Reduction to Practice」のような制度があるのは、結局すべてが先行研究の上に積み重なっていることを認めているからだ
      実際に部品を組み合わせて、きちんと動作するシステムを作り上げたこと自体が新規性である点を無視すべきではない
      https://en.wikipedia.org/wiki/Reduction_to_practice

    • 「特許をなくせ」という意見について言えば、いまSupabaseが提示しているやり方は事実上それに近い
      誰でもその特許の保護を受けられるようにしているのだから、特許トロールやIP訴訟への防御が少しやりやすくなるわけだ

    • この意見はよく分からない
      実際、Supabaseは特許をオープンソースとして公開しようとしており、Postgresへのupstream作業も進めている
      別の会社を買収して特許を取得したうえで、それをコミュニティに還元するために弁護士費用まで払って努力している
      企業が不正な行為をしたなら批判されるべきだが、このコメントは少し無理に怒っているように見える
      企業がコミュニティと関わろうとするたびに毎回こんなふうに非難していたら、企業はもう参加しなくなる
      批判すべき点(たとえばライセンス変更の問題など)が一部あったとしても、前向きな行動については一緒に歓迎すべきだと思う
      こうした変化はコミュニティ全体の利益になる

  • ブログで見た内容
    「この特許は、オープンソースを敵対的に脅かすIP問題から守る盾として機能する」
    しかし現在のライセンスには
    「ライセンスを持つ利用者がSupabaseに対して訴訟を提起した場合、その時点で当該ライセンスは終了する」
    という文言が入っており、単なる税務訴訟のような些細な法的問題だけでもライセンスを失う可能性がある
    公的機関の立場では負担になりうるので、特許に限定してもっと狭く書くか、OSI認証ライセンスの方がよいように思う
    https://github.com/orioledb/orioledb/blob/main/LICENSE

    • (Supabase CEO)
      この内容は法務チームと一緒に再確認して、より明確にしたい
      私たちの意図は明確であり、参考になる例や意見があれば、遡及不可(取消不可)なレベルまで含めて改善したい
      コミュニティが維持コストを負担する準備があるなら、特許そのものを寄付することにも前向きだ

    • Apache 2.0ライセンスの方が特許問題にはより適している
      敵対的な特許訴訟についてライセンスを終了させる仕組みになっており、税務問題などはライセンス終了の対象にならない
      https://opensource.org/license/apache-2-0

    • Supabaseのための盾であって、私たちのための盾ではない

    • 今のライセンスで、友好的なフォークや再配布も許可されるのか気になる
      最初は自由な使用、複製、修正、配布が許可されると書かれているが、
      後ろの方には「特許についてライセンスを付与する」という文があり、修正後に配布されたコードにもこれが適用されるのか曖昧だ
      たとえばGPLv2は「再配布のたびに元の権利者からライセンスを受ける」と明確だ
      オープンソースコードに毒条項を入れるなら、その影響はすべての利用者に明確であるべきだ

    • 特に問題はないように見える
      彼らが言うように盾として使うのであって、もし彼らを訴えるなら無料ライセンスを受ける資格はないと思う

  • データベース特許をオープンソース化するのは珍しい
    これが他の企業にも、オープンエコシステムの方がクローズドIPより導入が速いという事実を認識させるきっかけになるのか気になる

    • オープンソースでないと営業フローに大きな摩擦が生じるのは、ほぼ既定路線の現実だ
      一部の特殊なケースを除けば、たいていはオープンソースでないと厳しい
  • SupabaseがOrioleDBの米国特許を、すべての利用者(商用フォークを含む)に非独占的にライセンスする
    さらに、OrioleDBは1時間前にApache 2.0ライセンスへ変更されたとのこと
    https://github.com/orioledb/orioledb/commit/44bab2aa9879feb74bb1b6f056f7dba2d3ae5a90

  • データ構造に特許を出すのは本当に気に入らない

    • 参考までに、私たちはそのようなやり方を好んでいない
      OrioleDB自体は買収前から開発されており、私たちは可能な限り最大限に自由なオープンソースライセンスを維持しようと努めている
  • ソフトウェア特許は本当にアメリカ的な文化だ
    こういう場合には、むしろ中国のように特許法を無視するアプローチの方がましだと思う

    • 中国は一般的に、知的財産権や窃盗を先進国とは異なる形で扱っている

    • 製造業の段階ではIPを軽視するが、IPベースの産業になると逆にIPを活用する
      米国は近年、著作権が非常に重要だとかLLMを止めろとか、IPを強調する文化が強まっている

    • そのアプローチはイノベーションを殺し、研究資金も枯渇させる

  • データ構造のようなものでも特許にできるとは知らなかった

    • IP保有者は「特許にできるものは何でも出して、残りは威嚇交渉に使え」という発想で動く
      データ構造そのものではなく、新しいアルゴリズムや改良について「革新的な手続き」と認定されることがある
      実際に有用性の向上や技術的進歩があると裁判所に認められれば、手続特許は維持される
      些細な特許であっても争うには膨大な時間と費用がかかる
      私は弁護士でも裁判官でもないが、この分野を長く見てきてそうした傾向を見てきた

    • 米国では可能だが、米国外の国では難しい

    • 司法・法域ごとに異なる
      欧州ではまだこの種の特許は認められていないが、継続的にロビー活動が行われている
      結局のところ通そうとする試みは続くだろうから、市民の自由を損なおうとするこうした執拗さには法的制裁が必要だと思う

  • OrioleDBには本当に大きな期待を寄せている
    PostgresをあらゆるDBに適した形へスケールさせる次の段階に見えるし、ベンチマークも自分で確認しているが、結果は非常に印象的だ
    https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N

    • ベンチマークを確認してくれてありがとう
      まもなくRCの準備が整う予定で、12月を目標にしている
      コードだけでなく、ベンチマークやストレステストに貢献してくれるならとても助かる

    • READMEとコメントを見る限り、OrioleDBはanti-bloatのような技術のおかげで、書き込み負荷の高いワークロードで特に強みが大きそうだ
      テキストやJSONBフィールドが大きく、TOAST処理される場合にも性能を発揮するのか気になる
      また、1%程度の非推奨ワークロードや弱点があるのかも気になる
      https://github.com/orioledb/orioledb?tab=readme-ov-file#orioledb--a-cloud-native-storage-engine-for-postgresql
      https://news.ycombinator.com/item?id=30462695

    • OrioleDBは確かに興味深く見えるが、保存構造が変わると他の拡張との互換性が問題になる可能性がある
      pg_search(ParadeDB)やTimescaleなどが影響を受けるかもしれず、
      類似例としてYugabyteDBがRocksDBを統合した際、PostgreSQL拡張との連携で苦労していた

  • Supabaseは継続的にPostgresエコシステムへ非常に大きな価値を提供している

  • これはオープンソースライセンスではない
    "もしライセンス保有者がSupabaseに対して法的訴訟を提起した場合、その時点でライセンスは終了する"
    これは毒条項だ
    少なくとも、このライセンスは無邪気すぎてSupabaseの顧客でさえ利用を妨げられるし、最悪の場合、コミュニティプロジェクトという名目でSupabaseに免責特権を与えようとする試みにもなりうる
    契約、IP、雇用、その他の問題で訴えればライセンス喪失だ
    データ損失の問題で訴えても、直ちにライセンス違反として反訴できるようになる
    Postgresライセンスを名乗りながらこんな条項を入れるのは奇妙だ
    OrioleDBは明らかに有望なプロジェクトだが、このライセンスの下ではオープンソースでもなく、使える人も限られる

    • sam、おそらく私のことを十分知っていると思うし、私たちのチームがどれほどオープンソースを重視しているかも分かっているはずだ
      もっと積極的に管理すべきだったが、そこは不十分だった
      今はApache 2.0に切り替わっており、特許関連の権利も明確に付与され、コードをupstreamするときにはPostgreSQL向けに再ライセンスすることも可能だ
      ブログも修正する予定だ
      https://github.com/orioledb/orioledb/pull/558

    • 以前FacebookがReactライセンスに似たような条項を入れていて、かなり後になってから削除した
      Apache2の特許条項に似て見えるが、実際には特定ソフトウェアの利用範囲だけに限定されたものではない

    • 単なるApache 2スタイルの寛容なライセンスではないのか気になる