- Supabase ने OrioleDB पेटेंट का अंतिम अधिग्रहण पूरा कर लिया है
- US Patent 10,325,030 (Durable multiversion B+-tree) के लिए OrioleDB के सभी उपयोगकर्ताओं को non-exclusive license दिया जा रहा है
- OrioleDB Postgres के मौजूदा storage engine को बदलने वाला high-performance extension है, जो cloud environment में performance और scalability को काफी बढ़ाता है
- यह प्रोजेक्ट open source के रूप में आगे भी विकसित होता रहेगा और Postgres community के साथ सहयोग के जरिए standardization और core में शामिल होने का लक्ष्य रखता है
- पेटेंट लाइसेंस का उद्देश्य intellectual property (IP) protection है, और यह open source के लिए खतरे के खिलाफ एक "shield" की तरह काम करता है
OrioleDB पेटेंट जारी करने और अधिग्रहण की पृष्ठभूमि
- Supabase ने हाल ही में OrioleDB के पूर्ण कानूनी अधिग्रहण की प्रक्रिया पूरी की है
- अब उसके पास US Patent 10,325,030 (Durable multiversion B+-tree) सहित सभी अधिकार हैं
- अब Supabase OrioleDB और उसके सभी forks (commercial services सहित) के उपयोगकर्ताओं को यह पेटेंट आधिकारिक रूप से non-exclusive रूप में दे रहा है
- यह licensing policy OrioleDB license के अनुसार लागू होती है
OrioleDB का परिचय और performance
- OrioleDB, Postgres के pluggable storage system का उपयोग करने वाला storage extension है
- यह मौजूदा Postgres storage engine को बदलने वाले drop-in तरीके से काम करता है
- modern hardware और cloud infrastructure optimization के जरिए यह Postgres की performance और scalability को अधिकतम करता है
- आधिकारिक benchmark के अनुसार, यह Heap engine की तुलना में लगभग 5.5 गुना तेज performance दिखाता है (TPC-C, 500 warehouses के आधार पर)
प्रोजेक्ट की विकास दिशा और open source policy
- Supabase, OrioleDB टीम के साथ मिलकर Postgres-first strategy के तहत high-performance storage engine development पर ध्यान दे रहा है
- OrioleDB एक open source project है, जिसमें कोई भी code, documentation, tests और issues आदि में योगदान दे सकता है
- इसका उद्देश्य Postgres की Table Access Method API पर आधारित drop-in storage engine को पूरा करना है
- Postgres community के साथ सहयोग के जरिए OrioleDB को extension module के रूप में standardize करने और mainline में शामिल कराने की दिशा में काम हो रहा है
लाइसेंस और IP compatibility policy
- OrioleDB license, PostgreSQL license के आधार पर लिखा गया है
- Supabase सभी OrioleDB उपयोगकर्ताओं को पेटेंट (US 10,325,030) स्वतंत्र रूप से उपयोग करने के लिए non-exclusive license दे रहा है
- यह पेटेंट open source को खतरे में डालने वाले hostile IP litigation से रक्षा करने के लिए एक "shield" की प्रकृति रखता है
Postgres के साथ aligned growth strategy
- OrioleDB का उद्देश्य स्वयं Postgres से प्रतिस्पर्धा करना नहीं, बल्कि Postgres की capabilities और performance को बेहतर बनाना है
- लंबी अवधि में आदर्श दिशा यह है कि OrioleDB, आधिकारिक Postgres repository में शामिल हो
- इसके लिए storage engine extensibility से जुड़े patches पर Postgres community के साथ लगातार सहयोग किया जा रहा है
- performance·stability improvements, production environment validation, documentation और onboarding को लगातार मजबूत किया जा रहा है
- benchmarks, migration notes, real-world feedback साझा करने, technical community में सक्रिय चर्चा, direct usage, और issue/PR contribution—इन सभी को प्रोत्साहित किया जा रहा है
1 टिप्पणियां
Hacker News की राय
पेटेंट और कोड को जल्दी से देखने पर लगा कि लगभग सारा शोध पहले कई वैज्ञानिकों द्वारा किए गए काम से लिया गया है
अगर आपने किसी और की चीज़ चुराई हो, तो उसे अच्छे इरादे से सबके साथ बांटने की बात भी आखिरकार चोरी ही है
सिर्फ इसलिए कि अमेरिकी पेटेंट कार्यालय ने पेटेंट पर मंजूरी की मुहर लगा दी, इसका मतलब यह नहीं कि वास्तव में कुछ नया आविष्कार किया गया है
बल्कि इसका मतलब बस इतना है कि आपने प्रशासनिक अधिकारी को मना लिया और किसी और के शोध को अपना बताने का आधार पा लिया
अगर आप सही पक्ष में खड़े होना चाहते हैं, तो इस पेटेंट को रद्द करें और उस शोध समुदाय से माफी मांगें, जिससे आप यह काम चुराने की कोशिश कर रहे थे
यह निष्कर्ष आपने कैसे निकाला, यह जानने की जिज्ञासा है
पेटेंट के मुख्य भाग में आने वाली बातें ज्यादातर जानी-पहचानी होना स्वाभाविक है
असली बात यह है कि पेटेंट claims में नया कंटेंट है या नहीं
पेटेंट विवरण इतना पर्याप्त होना चाहिए कि उस क्षेत्र का कोई सामान्य विशेषज्ञ उसे दोहरा सके; सिर्फ इतना कि पहले के पेपरों में कुछ चरण मिल जाते हैं, पर्याप्त नहीं है
वकील कितनी विस्तार से लिखते हैं, यह केस-दर-केस अलग होता है, और कभी-कभी CPU या प्रोग्राम जैसी चीज़ों का बहुत लंबा विवरण भी देना पड़ता है
विवाद से बचने के लिए जानी-मानी तकनीकों को भी लिख देना बेहतर होता है, नहीं तो बाद में मामूली बात पर अदालत में लड़ाई हो सकती है
मुझे लगता है कि Supabase पर यह टिप्पणी कुछ ज़्यादा ही कठोर है
शोध महत्वपूर्ण है, लेकिन USPTO में
Reduction to Practiceजैसी व्यवस्था इसी वजह से है कि अंततः हर चीज़ पहले के शोध पर ही बनती हैइस बात को नज़रअंदाज़ नहीं करना चाहिए कि अलग-अलग हिस्सों को जोड़कर वास्तव में सही तरह काम करने वाला सिस्टम बनाना अपने आप में नई बात हो सकती है
https://en.wikipedia.org/wiki/Reduction_to_practice
“पेटेंट को खत्म कर दो” वाली राय पर, Supabase अभी जो दे रहा है वह व्यवहार में लगभग वैसा ही है
क्योंकि यह सुनिश्चित किया जा रहा है कि कोई भी उस पेटेंट से संरक्षित हो सके, इसलिए पेटेंट ट्रोल या IP मुकदमों के खिलाफ बचाव कुछ आसान हो जाता है
यह राय मुझे ठीक से समझ नहीं आ रही
असल में Supabase पेटेंट को open source के रूप में जारी करना चाहता है और Postgres में upstream काम भी कर रहा है
उसने दूसरी कंपनी का अधिग्रहण करके पेटेंट हासिल किया, और अब उसे समुदाय को वापस देने के लिए वकीलों पर खर्च करके भी प्रयास कर रहा है
कंपनियां गलत करें तो उनकी आलोचना होना ही चाहिए, लेकिन यह टिप्पणी कुछ जबरन गुस्सा निकालने जैसी लगती है
अगर हर बार जब कोई कंपनी समुदाय के साथ जुड़ने की कोशिश करे उसे ऐसे ही कोसा जाएगा, तो कंपनियां आगे भाग लेना बंद कर देंगी
भले कुछ आलोचना के बिंदु हों, जैसे license बदलने का मुद्दा, फिर भी सकारात्मक कदमों पर साथ खुश होना चाहिए
ऐसा बदलाव पूरे समुदाय के लिए फायदेमंद है
ब्लॉग में यह देखा
“यह पेटेंट open source के प्रति शत्रुतापूर्ण IP मुद्दों से बचाने वाली ढाल का काम करता है”
लेकिन मौजूदा license में
“अगर license वाला उपयोगकर्ता Supabase के खिलाफ मुकदमा दायर करता है, तो उसी समय से वह license समाप्त हो जाएगा”
ऐसी पंक्ति है, इसलिए साधारण टैक्स विवाद जैसे मामूली कानूनी मुद्दे पर भी license खोया जा सकता है
सरकारी संस्थाओं के लिए यह बोझिल हो सकता है, इसलिए इसे पेटेंट तक सीमित और संकीर्ण रूप में लिखना, या OSI-प्रमाणित license लेना बेहतर होगा
https://github.com/orioledb/orioledb/blob/main/LICENSE
(Supabase CEO)
हम इस बात को legal team के साथ फिर से review करके और स्पष्ट करना चाहते हैं
हमारी मंशा साफ है, और अगर कोई अच्छा उदाहरण या सुझाव हो तो हम उसे irreversibility के स्तर तक भी सुधारने पर विचार करेंगे
अगर समुदाय maintenance cost संभालने के लिए तैयार हो, तो पेटेंट को खुद दान देने का विकल्प भी खुला है
Apache 2.0 license पेटेंट मुद्दों के लिए बेहतर है
उसमें केवल शत्रुतापूर्ण पेटेंट मुकदमों पर license समाप्त होता है, टैक्स जैसे मामलों पर नहीं
https://opensource.org/license/apache-2-0
यह Supabase की ढाल है, हमारी नहीं
जिज्ञासा है कि क्या मौजूदा license दोस्ताना fork या redistribution की भी अनुमति देता है
शुरुआत में लिखा है कि उपयोग, कॉपी, modification और distribution स्वतंत्र हैं,
लेकिन बाद में “पेटेंट के लिए license दिया जाता है” जैसी पंक्ति है, और यह स्पष्ट नहीं कि क्या यह modified और redistributed code पर भी लागू होती है
उदाहरण के लिए GPLv2 साफ कहता है कि “हर redistribution पर आपको मूल अधिकारधारी से license मिलता है”
अगर आप open source code में कोई toxic clause डाल रहे हैं, तो उसका असर सभी उपयोगकर्ताओं के लिए साफ होना चाहिए
मुझे इसमें खास समस्या नहीं दिखती
जैसा उन्होंने कहा, यह ढाल के रूप में इस्तेमाल के लिए है, और अगर आप उन्हीं पर मुकदमा करते हैं तो मुझे नहीं लगता कि आप मुफ्त license के हकदार हैं
डेटाबेस पेटेंट को open source करना दुर्लभ है
देखना होगा कि क्या इससे दूसरी कंपनियों को भी यह समझ आएगी कि open ecosystem, बंद IP की तुलना में अपनाने की रफ्तार तेज करता है
कुछ खास अपवादों को छोड़ दें, तो आम तौर पर open source न होने पर काम मुश्किल हो जाता है
Supabase ने OrioleDB के अमेरिकी पेटेंट को सभी उपयोगकर्ताओं, commercial fork सहित, non-exclusive license के तहत उपलब्ध कराया है
और कहा गया कि OrioleDB को एक घंटे पहले Apache 2.0 license में बदल दिया गया
https://github.com/orioledb/orioledb/commit/44bab2aa9879feb74bb1b6f056f7dba2d3ae5a90
डेटा संरचना पर पेटेंट दाखिल करना मुझे सच में पसंद नहीं है
OrioleDB खुद अधिग्रहण से पहले विकसित हो रहा था, और हम संभव हो सके उतना मुक्त open source license बनाए रखने की कोशिश कर रहे हैं
software patent सचमुच बहुत अमेरिकी चीज़ लगते हैं
ऐसे मामलों में तो मुझे चीन जैसा, पेटेंट कानून को नज़रअंदाज़ करने वाला तरीका बेहतर लगता है
चीन आम तौर पर बौद्धिक संपदा और चोरी को विकसित देशों से अलग नज़रिए से देखता है
जब बात manufacturing की हो तो IP की अनदेखी की जाती है, लेकिन जैसे ही उद्योग IP-आधारित हो जाता है, वही IP का इस्तेमाल करने लगता है
अमेरिका में हाल के समय में copyright को बहुत महत्वपूर्ण बताने, या LLM को रोकने जैसी IP-केंद्रित संस्कृति काफ़ी बढ़ी है
वह तरीका innovation को मार देता है और research funding भी सुखा देता है
मुझे पता ही नहीं था कि डेटा संरचना जैसी चीज़ों पर भी पेटेंट मिल सकता है
IP मालिक अक्सर “जो कुछ पेटेंट हो सकता है, सब पर पेटेंट लो, बाकी को धमकी और मोलभाव में इस्तेमाल करो” वाले ढंग से चलते हैं
डेटा संरचना अपने आप में नहीं, बल्कि किसी नए algorithm या सुधार को “innovative procedure” मान लिया जा सकता है
अगर अदालत यह मान ले कि उसमें उपयोगिता में सुधार या तकनीकी प्रगति है, तो process patent कायम रह सकता है
छोटा-मोटा पेटेंट भी चुनौती देना समय और पैसे की भारी बर्बादी बन सकता है
मैं न वकील हूं न जज, लेकिन लंबे समय से यह क्षेत्र देखते हुए यह रुझान देखा है
अमेरिका में यह संभव है, लेकिन अमेरिका के बाहर के देशों में मुश्किल है
यह न्यायिक/कानूनी क्षेत्र के हिसाब से अलग है
यूरोप अभी भी ऐसे पेटेंट की अनुमति नहीं देता, लेकिन इसके लिए लगातार lobbying हो रही है
आखिरकार इसे पास कराने की कोशिशें जारी रहेंगी, इसलिए नागरिक स्वतंत्रताओं को नुकसान पहुंचाने वाली ऐसी जिद पर कानूनी दंड होना चाहिए
OrioleDB को लेकर वाकई बहुत उम्मीदें हैं
यह Postgres को हर तरह के DB के लिए scale करने की अगली बड़ी सीढ़ी जैसा लगता है, और मैं खुद benchmarks भी देख रहा हूं; नतीजे बेहद प्रभावशाली हैं
https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
benchmarks देखने के लिए धन्यवाद
RC जल्द तैयार होने वाला है, और लक्ष्य दिसंबर है
अगर आप code के अलावा benchmarks और stress tests में भी योगदान देना चाहें, तो वह बहुत मददगार होगा
README और टिप्पणियों को देखकर लगता है कि OrioleDB को anti-bloat जैसी तकनीकों की वजह से write-heavy workload में बड़ा फायदा मिलता है
जानना चाहता हूं कि क्या यह तब भी अच्छा प्रदर्शन करता है जब text या JSONB field बड़े हों और TOAST प्रोसेसिंग में जाएं
और क्या कोई लगभग 1% ऐसे workload प्रकार या नुकसान हैं, जिनकी सिफारिश नहीं की जाती
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 निश्चित रूप से दिलचस्प लगता है, लेकिन storage structure बदलने पर दूसरे extensions के साथ compatibility समस्या बन सकती है
pg_search(ParadeDB), Timescale आदि प्रभावित हो सकते हैं,
और इसी तरह के एक उदाहरण में YugabyteDB को RocksDB integrate करते समय PostgreSQL extensions के साथ जुड़ने में कठिनाइयां हुई थीं
Supabase लगातार Postgres ecosystem को बहुत बड़ा value दे रहा है
यह open source license नहीं है
"अगर license धारक Supabase के खिलाफ कोई कानूनी मुकदमा दायर करता है, तो उसका license तुरंत समाप्त हो जाएगा"
यह एक toxic clause है
कम से कम यह license इतना भोला है कि Supabase के ग्राहकों के उपयोग को भी रोक सकता है, और सबसे बुरी स्थिति में यह समुदाय परियोजना के नाम पर Supabase को प्रतिरक्षा देने की कोशिश बन सकता है
contract, IP, employment या किसी और मुद्दे पर मुकदमा करें, license चला जाएगा
data loss के मामले में मुकदमा करें, तो भी वे तुरंत license violation का counterclaim कर सकते हैं
Postgres license का नाम लेकर ऐसी शर्त डालना अजीब है
OrioleDB निश्चित रूप से एक promising project है, लेकिन इस license के तहत यह न open source है और न ही व्यापक रूप से उपयोग योग्य
sam, शायद तुम मुझे इतना जानते हो कि यह समझो कि हमारी team open source को कितना महत्व देती है
मुझे इस पर और सक्रिय रूप से नज़र रखनी चाहिए थी, लेकिन मुझसे चूक हुई
अब इसे Apache 2.0 में बदल दिया गया है, पेटेंट अधिकार भी स्पष्ट रूप से दिए गए हैं, और code को upstream करते समय PostgreSQL के लिए फिर से relicense भी किया जा सकता है
ब्लॉग भी अपडेट किया जाएगा
https://github.com/orioledb/orioledb/pull/558
पहले Facebook ने React license में ऐसा ही एक clause रखा था और बहुत समय बाद उसे हटाया
यह ऊपर से Apache2 patent clause जैसा दिख सकता है, लेकिन वास्तव में यह किसी खास software के उपयोग-क्षेत्र तक सीमित नहीं है
क्या यह बस Apache 2 शैली का permissive license नहीं है?