สิทธิบัตร OrioleDB เปิดให้ชุมชน Postgres ใช้ได้อย่างเสรีแล้ว

 (supabase.com)
10 คะแนน โดย GN⁺ 2025-09-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Supabase ได้ดำเนินการซื้อสิทธิ์สิทธิบัตร OrioleDB เสร็จสมบูรณ์แล้ว
  • มอบสิทธิ์ใช้งานแบบไม่ผูกขาดสำหรับ สิทธิบัตรสหรัฐอเมริกา 10,325,030 (Durable multiversion B+-tree) ให้แก่ผู้ใช้ OrioleDB ทุกคน
  • OrioleDB เป็น ส่วนขยายประสิทธิภาพสูง ที่มาแทนที่ storage engine เดิมของ Postgres และช่วยยกระดับประสิทธิภาพกับความสามารถในการขยายระบบในสภาพแวดล้อมคลาวด์อย่างมาก
  • โครงการนี้จะยังคงพัฒนาต่อในรูปแบบ โอเพนซอร์ส และตั้งเป้ามาตรฐานรวมถึงการถูกรวมเข้าแกนหลักผ่านความร่วมมือกับชุมชน Postgres
  • ใบอนุญาตสิทธิบัตรนี้มีเป้าหมายเพื่อ ปกป้องทรัพย์สินทางปัญญา (IP) และทำหน้าที่เป็น "โล่" เพื่อตอบโต้ภัยคุกคามต่อโอเพนซอร์ส

การเปิดสิทธิบัตร OrioleDB และเบื้องหลังการเข้าซื้อ

  • Supabase เพิ่งเสร็จสิ้นกระบวนการเข้าซื้อทางกฎหมายของ OrioleDB อย่างสมบูรณ์
  • ทำให้บริษัทถือครองสิทธิทั้งหมด รวมถึง สิทธิบัตรสหรัฐอเมริกา 10,325,030 (Durable multiversion B+-tree)
  • จากนี้ Supabase จะมอบสิทธิบัตรนี้อย่างเป็นทางการในรูปแบบไม่ผูกขาดให้แก่ผู้ใช้ OrioleDB และทุกฟอร์กของมัน (รวมถึงบริการเชิงพาณิชย์)
  • นโยบายการให้สิทธิ์นี้มีผลภายใต้ไลเซนส์ของ OrioleDB

ภาพรวมและประสิทธิภาพของ OrioleDB

  • OrioleDB เป็นส่วนขยายด้าน storage ที่ใช้ประโยชน์จาก ระบบจัดเก็บข้อมูลแบบ pluggable ของ Postgres
  • มันทำงานแบบ drop-in replacement เพื่อแทนที่ storage engine เดิมของ Postgres
  • ออกแบบมาเพื่อรีดประสิทธิภาพและความสามารถในการขยายระบบของ Postgres ให้สูงสุด ด้วยการปรับให้เหมาะกับฮาร์ดแวร์ยุคใหม่และ โครงสร้างพื้นฐานคลาวด์
  • ตามเบนช์มาร์กอย่างเป็นทางการ มันให้ ประสิทธิภาพเร็วกว่า Heap engine ราว 5.5 เท่า (TPC-C, อ้างอิง 500 warehouses)

ทิศทางการพัฒนาโครงการและนโยบายโอเพนซอร์ส

  • Supabase ร่วมกับทีม OrioleDB มุ่งพัฒนา storage engine ประสิทธิภาพสูงด้วย แนวทางที่ให้ Postgres มาก่อนเป็นอันดับแรก
  • OrioleDB เป็น โครงการโอเพนซอร์ส ที่ทุกคนสามารถมีส่วนร่วมได้ ทั้งโค้ด เอกสาร การทดสอบ และ issues
  • เป้าหมายคือทำให้ storage engine แบบ drop-in สมบูรณ์บนพื้นฐานของ Table Access Method API ของ Postgres
  • ขณะนี้กำลังผลักดันให้ OrioleDB ถูก ทำให้เป็นมาตรฐานและรวมเข้า mainline ในรูปแบบโมดูลส่วนขยาย ผ่านความร่วมมือกับชุมชน Postgres

นโยบายไลเซนส์และความเข้ากันได้ด้าน IP

  • ไลเซนส์ของ OrioleDB ถูกเขียนขึ้นบนพื้นฐานของ PostgreSQL License
  • Supabase มอบสิทธิ์ใช้งานแบบไม่ผูกขาดเพื่อให้ผู้ใช้ OrioleDB ทุกคนสามารถใช้สิทธิบัตร (US 10,325,030) ได้อย่างเสรี
  • สิทธิบัตรนี้มีลักษณะเป็น "โล่" เพื่อ ป้องกันการฟ้องร้องด้าน IP แบบเป็นปฏิปักษ์ ที่คุกคามโอเพนซอร์ส

ยุทธศาสตร์การพัฒนาที่สอดคล้องกับ Postgres

  • OrioleDB ไม่ได้มีเป้าหมายจะแข่งขันกับ Postgres เอง แต่มีเป้าหมายเพื่อ ยกระดับความสามารถและประสิทธิภาพของ Postgres
  • ในระยะยาว ทิศทางที่เหมาะสมที่สุดคือการให้ OrioleDB ถูกรวมเข้า repository ทางการของ Postgres
  • เพื่อสิ่งนี้ ทีมงานจึงร่วมมือกับชุมชน Postgres อย่างต่อเนื่องในงานแพตช์ที่เกี่ยวข้องกับ ความสามารถในการขยายของ storage engine
  • กำลังผลักดันอย่างต่อเนื่องทั้ง การปรับปรุงประสิทธิภาพและเสถียรภาพ การตรวจสอบในสภาพแวดล้อมจริง, การจัดทำเอกสาร และการเสริมความแข็งแรงให้ onboarding
  • มีการส่งเสริมทั้งการแบ่งปัน เบนช์มาร์ก, migration notes, feedback จากการใช้งานจริง การถกเถียงเชิงเทคนิคในชุมชนอย่างคึกคัก การลองใช้งานด้วยตนเอง และการร่วมส่ง issue/PR

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-11
ความคิดเห็นบน Hacker News

  • พอไล่อ่านสิทธิบัตรกับโค้ดแบบเร็ว ๆ แล้วรู้สึกว่างานวิจัยแทบทั้งหมดหยิบมาจากสิ่งที่นักวิทยาศาสตร์หลายคนเคยทำไว้ก่อนแล้ว
    ต่อให้บอกว่าจะขโมยของคนอื่นมาแล้วแบ่งปันด้วยเจตนาดี มันก็ยังเป็นการขโมยอยู่ดี
    แค่ได้ตราประทับอนุมัติสิทธิบัตรจากสำนักงานสิทธิบัตรสหรัฐฯ ก็ไม่ได้แปลว่าได้ประดิษฐ์สิ่งใหม่จริง ๆ
    มันเป็นแค่การโน้มน้าวเจ้าหน้าที่ฝ่ายธุรการให้ยอมรับเหตุผลที่ทำให้เอางานวิจัยของคนอื่นมาอ้างเป็นของตัวเองได้เท่านั้น
    ถ้าอยากอยู่ฝั่งที่ถูกต้อง ก็ควรยกเลิกสิทธิบัตรนี้แล้วขอโทษชุมชนนักวิจัยที่ตัวเองพยายามจะขโมยผลงาน

    • อยากรู้ว่าไปสรุปแบบนั้นได้อย่างไร
      สิ่งที่อยู่ในเนื้อหาสิทธิบัตรส่วนใหญ่ก็เป็นเรื่องที่รู้จักกันดีอยู่แล้วเป็นปกติ
      ประเด็นสำคัญคือข้อถือสิทธิ์ของสิทธิบัตรมีเนื้อหาใหม่หรือไม่
      คำอธิบายสิทธิบัตรต้องละเอียดพอให้ผู้เชี่ยวชาญทั่วไปในสาขานั้นทำซ้ำได้ และแค่ชี้ได้ว่ามีขั้นตอนคล้ายกันในงานวิจัยเก่าก็ยังไม่พอ
      เรื่องที่ทนายจะเขียนละเอียดแค่ไหนก็แล้วแต่กรณี บางทีก็ต้องอธิบาย CPU หรือโปรแกรมแบบยืดยาวด้วย
      ถ้าอยากเลี่ยงข้อถกเถียง ก็ควรใส่เทคนิคที่รู้จักกันดีไว้ด้วย ไม่งั้นภายหลังอาจต้องไปสู้คดีเรื่องเล็กน้อยในศาล

    • คิดว่านี่ตัดสิน Supabase แรงเกินไป
      งานวิจัยสำคัญก็จริง แต่ที่ USPTO มีแนวคิดอย่าง ‘Reduction to Practice’ ก็เพราะยอมรับว่าทุกอย่างล้วนต่อยอดจากงานก่อนหน้า
      ไม่ควรมองข้ามว่าการเอาชิ้นส่วนต่าง ๆ มาประกอบเป็นระบบที่ใช้งานได้จริงก็ถือเป็นความใหม่แบบหนึ่ง
      https://en.wikipedia.org/wiki/Reduction_to_practice

    • เรื่องความเห็นที่ว่า “ควรล้มเลิกสิทธิบัตรไปเลย” วิธีที่ Supabase ให้ตอนนี้ก็แทบจะเทียบเท่าแบบนั้นอยู่แล้ว
      เพราะใครก็ตามได้รับความคุ้มครองจากสิทธิบัตรนี้ จึงช่วยให้ป้องกัน patent troll หรือคดีฟ้องร้องด้าน IP ได้ง่ายขึ้นเล็กน้อย

    • ฉันไม่ค่อยเข้าใจความเห็นนี้
      ในความเป็นจริง Supabase กำลังพยายามเปิดสิทธิบัตรนี้ให้โอเพนซอร์ส และก็ทำงาน upstream ให้กับ Postgres อยู่ด้วย
      พวกเขาซื้อกิจการอีกบริษัทหนึ่งเพื่อให้ได้สิทธิบัตรนี้มา แล้วก็ยังยอมจ่ายค่าทนายเพื่อส่งคืนให้ชุมชนอีก
      ถ้าบริษัททำอะไรไม่ถูกต้องก็ควรถูกวิจารณ์แน่นอน แต่คอมเมนต์นี้ดูเหมือนพยายามโกรธแบบฝืน ๆ
      ถ้าทุกครั้งที่บริษัทพยายามมีปฏิสัมพันธ์กับชุมชนแล้วโดนด่าแบบนี้ สุดท้ายบริษัทก็จะเลิกเข้ามามีส่วนร่วม
      ถึงจะมีบางจุดที่ควรวิจารณ์ได้ เช่น เรื่องการเปลี่ยนไลเซนส์ แต่กับการกระทำในทางบวกก็ควรยินดีไปด้วย
      การเปลี่ยนแปลงแบบนี้เป็นประโยชน์ต่อทั้งชุมชน

  • สิ่งที่เห็นจากบล็อก
    “สิทธิบัตรนี้ทำหน้าที่เป็นโล่ป้องกันประเด็น IP ที่เป็นภัยต่อโอเพนซอร์ส”
    แต่ในไลเซนส์ปัจจุบันมีข้อความว่า
    “หากผู้ใช้ที่ได้รับไลเซนส์ยื่นฟ้อง Supabase ไลเซนส์นั้นจะสิ้นสุดลงนับจากเวลานั้น”
    ซึ่งหมายความว่าแม้แต่ข้อพิพาททางกฎหมายเล็กน้อยอย่างคดีภาษีก็อาจทำให้เสียไลเซนส์ได้
    สำหรับหน่วยงานรัฐ เรื่องนี้อาจเป็นภาระ จึงน่าจะดีกว่าถ้าจะเขียนให้แคบลงเฉพาะเรื่องสิทธิบัตร หรือใช้ไลเซนส์ที่ OSI รับรองแทน
    https://github.com/orioledb/orioledb/blob/main/LICENSE

    • (CEO ของ Supabase)
      ผมจะกลับไปตรวจเรื่องนี้กับทีมกฎหมายอีกครั้งเพื่อทำให้ชัดเจนขึ้น
      เจตนาของเราชัดเจนอยู่แล้ว และถ้ามีตัวอย่างหรือความเห็นที่อ้างอิงได้ เราก็พร้อมปรับปรุงให้ดีขึ้นแม้ถึงระดับเพิกถอนไม่ได้
      ถ้าชุมชนพร้อมรับภาระค่าใช้จ่ายในการดูแล เราก็เปิดกว้างที่จะบริจาคตัวสิทธิบัตรเลย

    • ไลเซนส์ Apache 2.0 ดีกว่าในประเด็นสิทธิบัตร
      มันทำให้ไลเซนส์สิ้นสุดเฉพาะเมื่อมีการฟ้องร้องสิทธิบัตรในเชิงเป็นปฏิปักษ์ ดังนั้นเรื่องภาษีหรือข้อพิพาทอื่นจะไม่ทำให้ไลเซนส์สิ้นสุด
      https://opensource.org/license/apache-2-0

    • มันเป็นโล่ของ Supabase ไม่ใช่โล่ของพวกเรา

    • สงสัยว่าไลเซนส์ตอนนี้อนุญาตให้ fork แบบเป็นมิตรหรือแจกจ่ายต่อได้จริงหรือไม่
      ตอนต้นบอกว่าอนุญาตให้ใช้ คัดลอก แก้ไข และแจกจ่ายได้อย่างเสรี
      แต่ด้านหลังกลับมีประโยคว่า “ให้สิทธิไลเซนส์เกี่ยวกับสิทธิบัตร” ซึ่งยังไม่ชัดว่าครอบคลุมโค้ดที่แก้ไขแล้วและนำไปแจกจ่ายต่อหรือไม่
      เช่น GPLv2 ระบุชัดว่า “ทุกครั้งที่มีการแจกจ่ายต่อ ผู้รับจะได้รับไลเซนส์จากผู้ถือสิทธิเดิม”
      ถ้าจะใส่เงื่อนไขเป็นพิษลงในโอเพนซอร์ส ก็ควรทำให้ผลกระทบชัดเจนกับผู้ใช้ทุกคน

    • ดูไม่เห็นจะมีปัญหาอะไร
      ก็อย่างที่พวกเขาบอก มันใช้เป็นโล่ และถ้าคุณจะฟ้องพวกเขา ก็ไม่ควรมีสิทธิ์ได้ไลเซนส์ฟรี

  • การทำสิทธิบัตรฐานข้อมูลให้เป็นโอเพนซอร์สเป็นเรื่องที่พบได้ไม่บ่อย
    น่าสนใจว่านี่จะทำให้บริษัทอื่นตระหนักหรือไม่ว่าระบบนิเวศแบบเปิดถูกนำไปใช้ได้เร็วกว่าทรัพย์สินทางปัญญาแบบปิด

    • ถ้าไม่เป็นโอเพนซอร์ส แทบจะแน่นอนว่าจะมีแรงเสียดทานในกระบวนการขายสูงมาก
      นอกจากบางกรณีพิเศษ โดยทั่วไปถ้าไม่โอเพนซอร์สก็ไปได้ยาก

  • Supabase ให้สิทธิใช้งานสิทธิบัตรสหรัฐฯ ของ OrioleDB แบบไม่ผูกขาดแก่ผู้ใช้ทุกคน รวมถึง commercial fork
    และเพิ่งเปลี่ยน OrioleDB ไปใช้ไลเซนส์ Apache 2.0 เมื่อหนึ่งชั่วโมงก่อน
    https://github.com/orioledb/orioledb/commit/44bab2aa9879feb74bb1b6f056f7dba2d3ae5a90

  • ฉันไม่ชอบเลยกับการจดสิทธิบัตรโครงสร้างข้อมูล

    • เพื่อให้ชัดเจน เราเองก็ไม่ได้ชอบแนวทางแบบนั้น
      OrioleDB ถูกพัฒนามาก่อนการเข้าซื้อกิจการ และเราก็กำลังพยายามคงไลเซนส์โอเพนซอร์สแบบเสรีไว้ให้มากที่สุดเท่าที่ทำได้

  • สิทธิบัตรซอฟต์แวร์เป็นวัฒนธรรมแบบอเมริกันมากจริง ๆ
    ในกรณีแบบนี้ฉันกลับคิดว่าวิธีแบบจีนที่เมินกฎหมายสิทธิบัตรอาจดีกว่า

    • โดยทั่วไปจีนมองทรัพย์สินทางปัญญาและการขโมยต่างจากประเทศพัฒนาแล้ว

    • ตอนเป็นภาคการผลิตก็เมิน IP แต่พอกลายเป็นอุตสาหกรรมที่ขับเคลื่อนด้วย IP ก็กลับมาใช้ IP เอง
      ช่วงหลังในสหรัฐฯ ก็มีวัฒนธรรมที่เน้น IP มากขึ้น เช่น บอกว่าลิขสิทธิ์สำคัญมาก หรือเรียกร้องให้หยุด LLM

    • วิธีแบบนั้นฆ่านวัตกรรมและทำให้เงินทุนวิจัยเหือดแห้ง

  • ไม่เคยรู้มาก่อนว่าอะไรอย่างโครงสร้างข้อมูลก็จดสิทธิบัตรได้ด้วย

    • ผู้ถือครอง IP มักเดินเกมแบบ “อะไรที่จดสิทธิบัตรได้ก็จดให้หมด ที่เหลือก็เก็บไว้ใช้ข่มขู่ต่อรอง”
      ไม่ใช่ตัวโครงสร้างข้อมูลเอง แต่เป็นอัลกอริทึมหรือการปรับปรุงใหม่ที่อาจถูกตีความว่าเป็น ‘กระบวนการเชิงนวัตกรรม’
      ถ้าศาลเห็นว่ามีการเพิ่มประโยชน์ใช้สอยหรือความก้าวหน้าทางเทคนิคจริง สิทธิบัตรเชิงกระบวนการก็อาจยังยืนอยู่ได้
      ต่อให้เป็นสิทธิบัตรเล็กน้อย การจะต่อสู้ก็ยังต้องใช้เวลาและค่าใช้จ่ายมหาศาล
      ฉันไม่ใช่ทนายหรือผู้พิพากษา แต่ติดตามวงการนี้มานานพอจะเห็นแนวโน้มแบบนี้

    • ในสหรัฐฯ ทำได้ แต่ในประเทศนอกสหรัฐฯ จะยากกว่า

    • มันต่างกันไปตามเขตอำนาจศาล
      ยุโรปยังไม่ยอมให้สิทธิบัตรแบบนี้ แต่ก็ยังมีการล็อบบี้ต่อเนื่อง
      สุดท้ายก็คงยังมีความพยายามผลักดันให้ผ่านอยู่เรื่อย ๆ ดังนั้นความดื้อดึงที่พยายามบ่อนทำลายเสรีภาพของประชาชนแบบนี้ควรมีบทลงโทษทางกฎหมาย

  • คาดหวังกับ OrioleDB มากจริง ๆ
    มันดูเหมือนก้าวถัดไปของการทำให้ Postgres สเกลได้เหมาะกับฐานข้อมูลทุกประเภท และฉันก็กำลังดู benchmark ด้วยตัวเองอยู่ ผลลัพธ์น่าประทับใจมาก
    https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N

    • ขอบคุณที่ช่วยดู benchmarking
      เราใกล้พร้อมสำหรับ RC แล้ว และตั้งเป้าไว้เดือนธันวาคม
      ถ้าอยากช่วยทั้งเรื่อง benchmark และ stress test นอกเหนือจากโค้ด ก็จะเป็นประโยชน์มาก

    • จาก README และคอมเมนต์ต่าง ๆ ดูเหมือนว่า OrioleDB จะเด่นมากกับ workload ที่เขียนหนัก เพราะมีเทคนิคอย่าง anti-bloat
      อยากรู้ว่ามันยังทำงานได้ดีหรือไม่เมื่อฟิลด์ข้อความหรือ JSONB มีขนาดใหญ่จนต้องผ่าน TOAST
      แล้วมี workload ประเภทไหนบ้างราว 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 extension

  • Supabase มอบคุณค่าให้ระบบนิเวศของ Postgres อย่างมหาศาลมาโดยตลอด

  • นี่ไม่ใช่ไลเซนส์โอเพนซอร์ส
    "หากผู้ถือไลเซนส์ยื่นฟ้อง Supabase ทางกฎหมาย ไลเซนส์จะสิ้นสุดลงทันที"
    นี่คือเงื่อนไขเป็นพิษ
    อย่างน้อยที่สุดมันเป็นไลเซนส์ที่เขียนแบบไร้เดียงสาจนแม้แต่ลูกค้า Supabase เองก็อาจถูกกันไม่ให้ใช้ได้ และในกรณีแย่ที่สุดมันอาจเป็นความพยายามจะสร้างเอกสิทธิ์คุ้มกันให้ Supabase ในนามของโครงการชุมชน
    ถ้าฟ้องเรื่องสัญญา IP การจ้างงาน หรือปัญหาอื่น ๆ ก็จะเสียไลเซนส์
    ต่อให้ฟ้องเรื่องข้อมูลสูญหาย ก็อาจโดนฟ้องกลับฐานละเมิดไลเซนส์ได้ทันที
    การอ้างว่าเป็นไลเซนส์แบบ Postgres แต่แอบใส่เงื่อนไขแบบนี้มาด้วยเป็นเรื่องน่าประหลาด
    OrioleDB เป็นโครงการที่มีอนาคตมากแน่ ๆ แต่ภายใต้ไลเซนส์นี้ มันไม่ใช่โอเพนซอร์สและคนที่ใช้ได้ก็มีจำกัด

    • sam คุณน่าจะรู้จักผมดีพอจะรู้ว่าทีมเราให้ความสำคัญกับโอเพนซอร์สมากแค่ไหน
      ผมควรลงมาดูแลเรื่องนี้เชิงรุกกว่านี้และทำได้ไม่ดีพอ
      ตอนนี้เปลี่ยนเป็น Apache 2.0 แล้ว สิทธิที่เกี่ยวกับสิทธิบัตรก็ให้ไว้อย่างชัดเจน และเมื่อนำโค้ด upstream ก็สามารถ relicense เป็น PostgreSQL ได้ด้วย
      เราจะอัปเดตบล็อกด้วย
      https://github.com/orioledb/orioledb/pull/558

    • เมื่อก่อน Facebook ก็เคยใส่เงื่อนไขคล้ายกันไว้ในไลเซนส์ React และกว่าจะเอาออกก็ใช้เวลานาน
      มันอาจดูคล้ายข้อสิทธิบัตรของ Apache2 แต่จริง ๆ แล้วไม่ได้จำกัดอยู่แค่ขอบเขตการใช้ซอฟต์แวร์เฉพาะตัวนั้น

    • หรือจริง ๆ แล้วมันก็แค่ไลเซนส์แบบอนุญาตกว้างสไตล์ Apache 2 อยู่แล้ว?