7 पॉइंट द्वारा xguru 2024-04-01 | 3 टिप्पणियां | WhatsApp पर शेयर करें

SSPL बुरा क्यों है

  • SSPL(Server Side Public License) सभी उपयोगकर्ताओं, कंपनियों, और सामान्य रूप से पूरे कम्युनिटी के लिए एक भयानक लाइसेंस है
  • SSPL लाइसेंस वाले प्रोडक्ट open source नहीं हैं, वे cloud और managed service प्रतिद्वंद्वियों को खत्म करने, hosting की कीमतें बढ़ाने, और open source को मारने का लक्ष्य रखते हैं
  • SSPL का उद्देश्य बड़ी कंपनियों से लड़ने की तुलना में निवेशकों को पैसा लौटाने के अधिक करीब हो सकता है

SSPL क्या है

  • SSPL एक लाइसेंस है जिसे 2008 में MongoDB, Inc ने MongoDB के उपयोग को सीमित करने के लिए पेश किया था
  • Elasticsearch, Kibana, Graylog जैसे प्रोडक्ट भी अब SSPL लाइसेंस का उपयोग करते हैं
  • धारा 13 के अनुसार, अगर आप प्रोडक्ट को सीधे ग्राहकों को उपलब्ध कराना चाहते हैं, तो आपको "service source code" सार्वजनिक रूप से उपलब्ध कराना होगा

SSPL सबके लिए बुरा क्यों है

  • SSPL को कुछ बुरी नीयत वाली cloud कंपनियों को, जो कम्युनिटी में योगदान दिए बिना मुनाफा कमाती हैं, रोकने के लिए एक अच्छे समाधान के रूप में पेश किया गया था, लेकिन वास्तव में यह स्वतंत्रता के लिए खतरा और प्रतिद्वंद्वियों को खत्म करने वाला लाइसेंस है
  • यह लाइसेंस पहले open source रहे प्रोडक्ट्स को 'free' की भ्रामक भावना के पीछे छिपाकर commercial products में बंद करने से अधिक कुछ नहीं है। शायद अब ऐसे software को "Freemium" software कहना चाहिए
  • MongoDB, Elasticsearch, Kibana, Graylog अब open source प्रोडक्ट नहीं रहे, और ये कंपनियाँ अब पूरी तरह तय कर सकती हैं कि कौन अपने ग्राहकों को उनका प्रोडक्ट प्रस्तावित कर सकता है। यह प्रतिद्वंद्वियों को खत्म करना है
  • अब वे बिना किसी प्रतिद्वंद्वी के अपना cloud hosting solution दे सकते हैं, source code सार्वजनिक किए बिना, और अपनी तय की हुई फीस के जरिए प्रतिस्पर्धा और innovation को खत्म कर सकते हैं
  • इसका मतलब है कि हमारे जैसे ग्राहकों के पास अब cloud provider चुनने की शक्ति नहीं बचती
  • स्वाभाविक रूप से hosting की कीमतें बढ़ेंगी, और हमारे पास केवल यही विकल्प बचेगा कि अपनी infrastructure पर hosting हिस्से को संभालने के लिए एक समर्पित टीम रखें। ठीक वही चीज़ जिससे हम पिछले कुछ वर्षों में cloud hosting solutions के जरिए बचना चाहते थे

SSPL का उपयोग करने वाली कंपनियाँ

  • MongoDB प्रोडक्ट 2018 से SSPL लाइसेंस का उपयोग कर रहे हैं, और इसके पीछे MongoDB, Inc है
  • Elasticsearch प्रोडक्ट 2021 से SSPL लाइसेंस का उपयोग कर रहे हैं, और इसके पीछे Elastic NV है
  • Graylog प्रोडक्ट 2020 से SSPL लाइसेंस का उपयोग कर रहे हैं, और इसके पीछे GrayLog, Inc. है

कुछ सवाल जो हमें खुद से पूछने चाहिए

  • जो कंपनी अब open source का उपयोग ही नहीं करती, वह दूसरों से "कम्युनिटी को वापस दो" कहने का नैतिक अधिकार कैसे रख सकती है?
  • जो कंपनी अपनी cloud service का source code सार्वजनिक नहीं करती, वह दूसरों से source code सार्वजनिक करने की मांग कैसे कर सकती है?
  • जो कंपनी non-open-source लाइसेंस का उपयोग करते हुए यह घोषित करती है कि open source उसके DNA का हिस्सा है, वह ऐसा कैसे कह सकती है?
  • 3000 से अधिक कर्मचारियों में से कितने लोग अपना काम और source code कम्युनिटी के साथ साझा करते हैं?(स्पॉइलर: बहुत कम)
  • क्या यह कम्युनिटी के साथ साझा करना चाहने वाली टेक कंपनी है, या निवेशकों की कमाई बढ़ाना चाहने वाली sales कंपनी?

SSPL के बारे में गलत दावे

  • "मैं cloud provider नहीं हूँ, इसलिए यह मेरे लिए प्रासंगिक नहीं है" वाला दावा वास्तव में इस बात को समझने की जरूरत रखता है कि यह मुद्दा सभी से जुड़ा है
  • "इन कंपनियों को जीवित रहने के लिए पैसे चाहिए" वाला दावा यह समझना चाहिए कि open source में पैसा कमाना बुरा नहीं है, लेकिन SSPL सही समाधान नहीं है
  • "प्रतिद्वंद्वी अभी भी मौजूद हैं। SSPL पर बातचीत हो सकती है" वाला दावा वास्तव में यह मतलब रखता है कि बाजार को नियंत्रित करने वाली कंपनी प्रतिद्वंद्वियों की कीमतें और शर्तें तय कर सकती है
  • "SSPL बड़े cloud खिलाड़ियों से लड़ता है, और छोटे व्यवसायों के लिए अच्छा है" वाला दावा इस बात को समझना चाहिए कि SSPL वास्तव में छोटे प्रतिद्वंद्वियों को दिवालिया कर सकता है और उन्हें गायब कर सकता है

open source प्रोजेक्ट्स के लिए सलाह

  • SSPL शुरुआत में एक अच्छा समाधान लग सकता है, लेकिन यह गलती न करने की सलाह है
  • अगर कुछ cloud providers समस्या हैं, तो उन्हें अनदेखा नहीं किया जा सकता और हम सबको मिलकर लड़ना चाहिए। open source की दुनिया से बाहर निकलकर लड़ना अच्छा तरीका नहीं है
  • अगर लाभप्रदता चाहिए, तो enterprise license और premium support का उपयोग करें: "अगर आपको support चाहिए, तो हमारे पास इसके लिए सबसे बेहतरीन टीम है।"
  • copyleft license का उपयोग करें ताकि कंपनियाँ कम्युनिटी को वापस दे सकें: "अगर आप हमारे code में बदलाव करते हैं, तो उसे कम्युनिटी के साथ साझा करें"
  • अगर आप फिर भी SSPL लाइसेंस चुनते हैं.. तो आप :
    • कई स्वतंत्र contributors और बड़ी कंपनियों के employee contributors को खो देंगे
    • open source software को बेहतर बनाने के लिए मेहनत करने वाले contributors के साथ विश्वासघात करेंगे
    • open source दुनिया छोड़कर Freemium software विकसित करने लगेंगे
    • अपने प्रोडक्ट को बहुत खराब buzz से जोड़ देंगे
    • दुनिया भर में आपके प्रोडक्ट का प्रचार करने में मदद करने वाले अनेक अलग-अलग खिलाड़ियों के लाभ को खो देंगे, जिससे premium support की जरूरत और बढ़ेगी

3 टिप्पणियां

 
aer0700 2024-04-04

यह open source होने की वजह से चुना भी जा सकता है, लेकिन open source होने की वजह से कभी-कभी विकल्पों की सूची से बाहर भी कर दिया जाता है.
शायद यह license AWS द्वारा MongoDB को लेकर DynamoDB बनाने वाली बात के कारण आया होगा, इसलिए open source पसंद करने वाले लोगों की नज़र में यह थोड़ा संदिग्ध लग सकता है.

 
coremaker 2024-04-01

AGPL के साथ भी तुलना करके देखना दिलचस्प होगा.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

 
xguru 2024-04-01

डोमेन नाम और साइट नाम SSPL is BAD से ही दिखता है कि यह एक इरादे के साथ बनाया गया वेबसाइट है.
कुछ जगहों पर अतिशयोक्ति भी काफ़ी है. कृपया नीचे दिए गए Hacker News के विचारों को साथ में देखें.

Hacker News राय

  • SSPL के प्रति सिद्धांतगत आपत्तियाँ हैं, लेकिन उसकी पृष्ठभूमि की समझ भी मौजूद है. यह आलोचना भी है कि Article 13 का वर्णन वस्तुनिष्ठ विश्लेषण से अधिक सनसनीखेज़ इरादे वाला है.

    • MongoDB और Elastic ने शायद यह अनुमान नहीं लगाया था कि AWS उनके प्रोडक्ट्स को रीपैकेज करके service के रूप में पेश करेगा और प्रतियोगी बन जाएगा. Elasticsearch जिस Apache license का उपयोग कर रहा था, वह इसे अनुमति देता था, लेकिन नैतिक रूप से इसे रोका जाना चाहिए था, ऐसा मत है.
    • यह भी कहा गया कि AWS OEM contract या partnership के ज़रिए 'win-win' संबंध बना सकता था, लेकिन ऐसा न करने से SSPL जैसी अप्रिय blocking को बढ़ावा मिला.
    • यह शिकायत है कि SSPL निवेशकों को खुश करने के लिए बनाया गया, लेकिन open source software होने का मतलब यह नहीं कि कंपनी का उद्देश्य गैर-लाभकारी हो; इसलिए Elastic या MongoDB को दोष देना और AWS को दोष न देना समझ से परे है, ऐसा मत है.
  • यह तर्क दिया गया कि SSPL उपयोगकर्ताओं के लिए बुरा है, क्योंकि यह monopoly को बढ़ावा देता है और community participation को कम करता है, जिसका असर अंततः सभी उपयोगकर्ताओं पर पड़ता है.

  • लोगों का पैसा कमाना स्वाभाविक है, और कोई चाहे तो SSPL project का उपयोग न करने का विकल्प चुन सकता है. यह दृष्टिकोण भी रखा गया कि SSPL license के तहत जारी software का होना, उसके बिल्कुल न होने से बेहतर है.

  • यह राय भी है कि आज का ecosystem 10 साल पहले की तुलना में बहुत बदल चुका है, और छोटी कंपनियाँ चाहती हैं कि उनके पास प्रतिस्पर्धा में टिके रहने और बढ़ने का रास्ता हो. BSL (Business Source License) जैसे license भले परफेक्ट न हों, लेकिन उन्हें एक स्वस्थ middle ground खोजने की कोशिश के रूप में देखा जा सकता है.

  • यह भी कहा गया कि SSPL की आलोचना करते हुए AGPL का ज़िक्र न करना अजीब है. उन लोगों की ओर भी इशारा किया गया जो free software का उपयोग तो करना चाहते हैं, लेकिन contribution नहीं करना चाहते.

  • एक राय यह है कि किसी एक पक्ष की ओर झुके बिना, हर मामले को अलग तरह से देखना चाहिए. SSPL cloud दिग्गजों के सामने टिके रहने की कोशिश कर रही कुछ कंपनियों के लिए अच्छा हो सकता है, लेकिन contributors का लाभ उठाने की कोशिश कर रही कुछ कंपनियों के लिए बुरा भी हो सकता है.

  • MongoDB, Elasticsearch, Graylog प्रोडक्ट्स को ग्राहकों के सामने सीधे प्रस्तावित करना प्रतिबंधित है. SSPL में 'directly' शब्द क़ानूनी विवाद की गुंजाइश देता है, और यही बात लोगों की चिंता का कारण है.

  • FSL (Functional Source License) एक अच्छा वैकल्पिक license है, जो 2 साल बाद अपने-आप Apache 2.0 या MIT में बदल जाता है. यह सरल है, source को public रखते हुए SaaS कंपनियों को काम करने का एक उचित तरीका देता है.

  • SSPL को 2008 में पेश किए जाने की ग़लत जानकारी पर सुधार किया गया. वास्तव में इसे 2018 में पेश किया गया था.

  • copyright के भविष्य पर एक-आयामी दृष्टिकोण की आलोचना.