Elasticsearch को लेकर AWS और Elastic के बीच टकराव
(blog.opsnow.com)हाल ही में Elasticsearch के open source छोड़ने, SSPL घोषित करने, और AWS द्वारा अलग से fork करके Apache License 2.0 वाले open source community को बनाए रखने की बात करने वाले लेख सामने आए। उन्हें देखकर मैंने दोनों के बीच लंबे समय से चले आ रहे टकराव का सारांश तैयार किया है.
बीच-बीच में अगर कोई कमी या गलती हो, तो कृपया कमेंट करें; उसे शामिल किया जाएगा.
10 टिप्पणियां
मुझे व्यक्तिगत रूप से यह अच्छी तरह समझ नहीं आता कि OSI ने SSPL को open source लाइसेंस के रूप में सूचीबद्ध करने से इनकार क्यों किया। यह AGPL का थोड़ा अधिक स्पष्ट किया गया लाइसेंस लगता है, और मेरी समझ यह थी कि यह SaaS व्यवसायों से सभी source code सार्वजनिक करने को कहता है। लेकिन OSI इसे SaaS को "प्रतिबंधित" करने के रूप में क्यों देखता है, यह मुझे ठीक से समझ नहीं आता।
OSI का बयान 1 पढ़ने पर भी, वह Elastic के SSPL अपनाने के इरादे की आलोचना करता है, लेकिन यह नहीं समझाता कि SSPL की कौन-सी धारा उपयोग को "प्रतिबंधित" कर रही है। सामग्री पढ़ने पर मुझे यह साफ नहीं लगता कि AGPL की तुलना में इसमें कोई अतिरिक्त "प्रतिबंध" है। क्या मैं लाइसेंस की व्याख्या गलत कर रहा हूँ...
लाइसेंस के बारे में आवेदन वापस लेने वाला MongoDB था। इसे OSI ने खारिज नहीं किया था। बेशक, OSI की तरफ़ से भी यह प्रतिक्रिया थी कि विवादित हिस्सों के कारण इसे open source के रूप में मान्यता देना मुश्किल है, लेकिन इस स्थिति को पहले से भांपकर MongoDB ने खुद ही आवेदन वापस ले लिया था।
सुधार के लिए धन्यवाद। लगता है कि मेरा वर्णन थोड़ा सटीक नहीं था। फिर भी यह सही है कि MongoDB ने पहले वापसी की थी, लेकिन लिंक में दिए गए OSI पोस्ट को देखें तो यह भी साफ है कि OSI का SSPL के मौजूदा संस्करण को स्वीकार करने का कोई इरादा नहीं है... इसलिए मुझे नहीं लगता कि आगे-पीछे का क्रम इतना महत्वपूर्ण दिखता है।
सहमत हूँ। ^^
मुझे भी थोड़ा संदेह है, इसलिए खोजते समय यह सामग्री मिली और उसका लिंक साझा कर रहा हूँ.
https://ceart.kr/component/file/…
अंश
सबसे पहले, SSPL और AGPL में अंतर इस प्रकार है। पहले का AGPL यह कहता है कि यदि कोई सॉफ़्टवेयर वितरित नहीं किया गया हो और server side पर चल रहा हो, तब भी GPL की तरह सेवा प्रदाता को उस सॉफ़्टवेयर में किए गए सभी संशोधन और जोड़े गए हिस्सों का पूरा source code सार्वजनिक करना होगा, लेकिन यह शर्त केवल उसी server तक सीमित रहती है.
इसके विपरीत, SSPL में केवल उस code ही नहीं, बल्कि जब उसे As-a-Service रूप में प्रदान किया जाता है, तब साथ में आवश्यक management software, user interface, API, automation software, monitoring software, backup और storage software आदि, यानी As-a-Service उपयोगकर्ता द्वारा चलाए जाने वाले सभी software का code सार्वजनिक करना अनिवार्य होता है। दूसरे शब्दों में, जब cloud providers MongoDB को service के रूप में प्रदान करते हैं, तो अपनी service की प्रतिस्पर्धात्मक बढ़त बनाए रखने के लिए उन्होंने जो भी software बनाया है, उसका source code भी पूरी तरह सार्वजनिक करना होगा.
मैं MongoDB और Redis के बारे में भी खोजबीन करने वाला था... यहाँ यह अच्छी तरह समझाया गया था!
इसके अलावा, अगर आप PDF देखें तो उसमें यह भी समझाया गया है कि OSI के अनुरूप न होने वाला हिस्सा क्या है। कहा गया है कि यह स्वतंत्रता पर प्रतिबंध और अलग कृतियों पर सीमाएँ लगाने से संबंधित है।
ओह... कुल मिलाकर यह PDF बहुत बढ़िया तरीके से लिखा गया है। लिंक के लिए धन्यवाद.
इसे इस तरह देखने पर AGPL से फर्क क्या है और SSPL को स्वीकार न करने की वजह भी समझ में आती है, लेकिन यह भी लगता है कि OSI शायद कुछ ज़्यादा ही permissive रुख की ओर झुका हुआ है।
पूरी हिस्ट्री बहुत अच्छी तरह से व्यवस्थित की गई है, इसलिए इसे आराम से पढ़ पाया। धन्यवाद!
संबंधित लेख देखें
https://hi.news.hada.io/topic?id=3620 - AWS ने Elasticsearch और Kibana के open source fork की घोषणा की
https://hi.news.hada.io/topic?id=3606 - Elastic ने लाइसेंस बदला ताकि AWS इसका उपयोग न कर सके