लाइसेंस बदलने के बाद भी Liquibase का खुद को "open source" बताकर प्रचार जारी

 (github.com/liquibase)
1 पॉइंट द्वारा GN⁺ 2025-10-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Liquibase ने अपने पुराने open source लाइसेंस से Functional Source License(FSL) में बदलाव किया है
  • FSL, Open Source Initiative (OSI) के मानकों के अनुसार आधिकारिक open source लाइसेंस नहीं है, फिर भी README आदि में इसे अब भी open source प्रोजेक्ट के रूप में पेश किए जाने पर सवाल उठे हैं
  • कम्युनिटी में एक ओर यह राय है कि FSL आधिकारिक open source मानकों का उल्लंघन करता है, जबकि दूसरी ओर इसके open source आवश्यकताओं को पूरा करने की दलील भी दी जा रही है
  • प्रोजेक्ट के भीतर README में मौजूद open source उल्लेखों को सुधारने का काम जारी है
  • यह भी कहा जा रहा है कि FSL में प्रतिस्पर्धी उपयोग को सीमित करने जैसी शर्तें OSI Open Source Definition के कुछ प्रावधानों से टकराती हैं

मुद्दे का सार

  • Liquibase प्रोजेक्ट का लाइसेंस हाल ही में Functional Source License(FSL) में बदला गया है
  • लेकिन README.md जैसी आधिकारिक दस्तावेज़ों में अब भी Liquibase को open source प्रोजेक्ट बताया जा रहा है, जिससे कम्युनिटी में भ्रम और मतभेद पैदा हुए हैं

रिपोर्ट की गई बातें और विवाद

  • इश्यू लिखने वाले ने बताया कि FSL में बदलाव के बाद भी Liquibase को open source बताया जाना समस्या है
  • Liquibase ने खुद भी पहले यह कहा है कि FSL open source लाइसेंस नहीं है
  • प्रोजेक्ट दस्तावेज़ों में open source शब्द का आगे इस्तेमाल न हो, इसके लिए README और अन्य दस्तावेज़ों में बदलाव की मांग की गई है

कम्युनिटी और संबंधित लोगों की राय

  • कुछ प्रतिभागियों का कहना है कि FSL OSI-स्वीकृत open source लाइसेंस के मानकों को पूरा करता है, और यदि औपचारिक समीक्षा के बाद FSL को OSI स्वीकृति मिल जाती है तो कोई समस्या नहीं होगी
  • इसके विपरीत, अन्य प्रतिभागियों ने जोर देकर कहा कि FSL में “allowed purpose” जैसी शर्तों के कारण यह OSI की open source definition की कई धाराओं (1, 3, 5, 6) का उल्लंघन करता है
  • कुछ लोगों ने “Fair Source” और “वास्तविक open source” के बीच अंतर पर जोर देते हुए कहा कि FSL को Fair Source के रूप में वर्गीकृत किया जाना चाहिए

समस्या के समाधान की प्रक्रिया और दस्तावेज़ संशोधन

  • प्रोजेक्ट के एक contributor ने इस मुद्दे के जवाब में README.md को अपडेट करना और open source उल्लेखों को धीरे-धीरे हटाना शुरू कर दिया है
  • हालांकि repository के अलग-अलग हिस्सों में अब भी कुछ ‘open source’, ‘oss’ जैसे शब्द बचे हुए हैं, इसलिए आगे और समीक्षा व सफाई की जाएगी

Open Source Definition और FSL(Functional Source License) की समस्या

  • Richard Fontana जैसे open source जगत के प्रमुख लोगों ने स्पष्ट किया है कि FSL प्रतिस्पर्धी उपयोग पर रोक जैसी शर्तों के कारण OSI Open Source Definition का उल्लंघन करता है
  • Open Source Definition में “क्षेत्र, व्यक्ति और संगठन के आधार पर भेदभाव न करने” जैसी शर्तें हैं, और प्रतिस्पर्धी उपयोग पर रोक इनसे मेल नहीं खाती
  • FSL दो साल बाद MIT या Apache License में बदल जाएगा और तब पूरी तरह open source हो जाएगा, लेकिन उससे पहले तक कुछ प्रतिबंधित शर्तें बनी रहती हैं

निष्कर्ष और मौजूदा स्थिति

  • यह इश्यू Liquibase की open source लेबलिंग को ठीक करने की प्रक्रिया में कम्युनिटी की पारदर्शिता की मांग और open source की मूल प्रकृति पर चर्चा को आगे बढ़ा रहा है
  • README जैसी आधिकारिक दस्तावेज़ों में संशोधन शुरू हो चुका है, और Fair Source तथा open source के बीच अंतर के मानदंड पर वास्तविक उदाहरण के रूप में चर्चा हो रही है
  • OSI स्वीकृति मिले या न मिले, लाइसेंस की वास्तविक शर्तें अंतरराष्ट्रीय open source कम्युनिटी में महत्वपूर्ण मायने रखती हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-17
Hacker News राय

  • अगर 4.x वर्ज़न अब इस्तेमाल नहीं किया जा सके, तो उसके विकल्प ढूँढने का काम शुरू कर रहा हूँ
    OSS लाइसेंस से paid मॉडल में जाना मैं समझ सकता हूँ, अगर कोई उपयोगी software से कमाई करना चाहता है
    लेकिन open source से लाइसेंस बदलना मुझे एक तरह की bait-and-switch रणनीति लगता है
    ऐसे फ़ैसले तुरंत भरोसा तोड़ देते हैं, और उन users को भी खो देते हैं जिनसे अभी कमाई मुश्किल हो लेकिन लंबे समय में संभावना हो
    मुझे लगा था कि Elastic और TerraForm के मामलों से पहले ही अहम सबक मिल चुका होगा
    Flyway भी कभी भी ऐसी ही राह पर जा सकता है, इसलिए उस पर भी भरोसा कम लगा
    अगर कोई fork नहीं आता, तो हमारे production use case के हिसाब से migration library खुद बनाने पर भी विचार कर रहा हूँ
    Liquibase सिर्फ़ सुविधा की वजह से इस्तेमाल किया था, ऐसा नहीं कि उसका कोई विकल्प ही नहीं है

    • EventstoreDB (अब KurrentDB) और NATS पर भी service reliability के मामले में शक किया जाता है
      EventstoreDB ने तो लाइसेंस पहले ही बदल दिया था, और NATS ने user backlash की वजह से सिर्फ़ योजना ही वापस ली
      अब ऐसा लगने लगा है कि इस तरह का कदम एक तरह की business strategy बन गया है

    • open source का सबसे बड़ा फ़ायदा यही है कि पुराने वर्ज़न को कभी भी fork करके इस्तेमाल किया जा सकता है
      मुझे यह बदलाव मूल रूप से product की कीमत बढ़ाने से बहुत अलग नहीं लगता

    • यह Postgres-only है, लेकिन automation को एक कदम आगे ले जाने वाला pgroll नाम का एक project भी है

    • Flyway (Apache license) के अलावा Atlas (Apache), Sqitch (MIT) जैसे लाइसेंस भी हैं जो अभी भी open source हैं

    • मुझे जिज्ञासा है कि Elastic के नज़रिए से लाइसेंस बदलना क्या सच में विफल रहा था
      कुछ समय तक stock price गिरी थी, लेकिन कंपनी वास्तव में अब भी मज़बूत है
      मेरी जानकारी में search और RAG क्षेत्र के सभी developers अभी भी Elastic NV द्वारा दिया गया Elasticsearch ही इस्तेमाल करते हैं (ना open source fork, ना कोई alternative)
      खासकर अगर Elastic के सबसे अहम customer segment यानी paid customers को देखें, तो शायद भरोसा टूटने के बजाय उल्टा असर हुआ
      असल revenue भी 2020 की तुलना में दोगुना बढ़ा

  • कुछ लोग अब भी इसे open source कहते हैं, लेकिन Liquibase ने खुद साफ़ कहा है कि FSL open source license नहीं है
    Liquibase की आधिकारिक ब्लॉग घोषणा देखें

    • यह बदलाव अभी एक महीने से भी कम पुराना है, इसलिए हो सकता है README में अभी तक ठीक से अपडेट न हुआ हो
      हाल में ऐसे बहुत से projects दिखे हैं जो सिर्फ़ source available होकर भी खुद को open source जैसा brand करते हैं, यह निराशाजनक है

  • अगर Liquibase ने मज़बूत copyleft (जैसे GNU AGPL) की जगह Apache चुना, तो उसे पहले से मानकर चलना चाहिए था कि दूसरी कंपनियाँ closed-source derivatives बनाएँगी
    आख़िरकार यह Liquibase का अपना चुना हुआ रास्ता था, इसलिए इसकी ज़िम्मेदारी भी Liquibase पर ही है

    • ऐसा लगता है कि एक तय अवधि के बाद यह अपने-आप Apache में बदल जाता है
      यह बेहतर है या नहीं, इस पर मैं निश्चित नहीं हूँ

    • कंपनियाँ वास्तव में AGPL जैसे लाइसेंस से भी अपने लक्ष्य हासिल कर सकती हैं
      Redis ने भी बदलाव किया था और community की प्रतिक्रिया सकारात्मक थी
      अगर Liquibase AGPL dual license चुनता, तो मुझे नहीं लगता users को उससे दिक्कत होती

  • इसे शायद "2 साल delayed open source" या "2 साल बाद open source" कहना चाहिए
    असल में यह मुझे "जब तक बेकार न हो जाए, तब open source" जैसा लगता है
    मेरे हिसाब से ऐसे मॉडल में असली सार यह है कि यह स्वतंत्रता का सम्मान करने की छवि देता है, लेकिन वास्तव में करता नहीं

    • इतना जल्दी पुराने वर्ज़न का बेकार हो जाना भी बहुत आम नहीं है
      मैं इसे अपनी स्वतंत्रता के प्रति अनादर नहीं मानता
      मक़सद कुछ सीमाएँ कंपनियों (इंसानों पर नहीं) पर लगाना है

    • enterprise क्षेत्र में open source का मूल तत्व 'स्वतंत्रता' से ज़्यादा भरोसा और transparency है
      सिर्फ़ source available होने पर भी बिना कानूनी/monetization समस्या के FOSS के फ़ायदे लिए जा सकते हैं
      ऑनलाइन दुनिया में open source model पर कुछ ज़्यादा ही अंधा भरोसा दिखता है
      2 साल की hybrid policy भी काफ़ी उचित लगती है, और अगर नया लाइसेंस पसंद नहीं है तो पुराना वर्ज़न इस्तेमाल किया जा सकता है

    • delayed open source — अंग्रेज़ी के 'late' की तरह, इसमें भी दोहरे अर्थ हैं

    • #source-washing

  • अगर आप इस नए लाइसेंस से परिचित नहीं हैं, तो FSL का विस्तृत विवरण देखें

    • FSL पर अतिरिक्त संदर्भ: इसे Sentry ने बनाया था; यह लाइसेंस क्यों ज़रूरी था और किस समस्या को हल करने की कोशिश करता है, यह Sentry ब्लॉग में देखा जा सकता है

    • व्यक्तिगत रूप से मुझे जो एकमात्र acceptable closed-source license लगता है, वह BuSL "Business Source License" है
      4 साल की समय-सीमा के बाद यह अनिवार्य रूप से open source हो जाता है, और उससे पहले source available रहता है
      यह अनावश्यक license proliferation को भी रोकता है
      Business Source License wiki भी देखी जा सकती है

    • मुझे शक है कि 2 साल की अवधि बहुत छोटी तो नहीं है
      बड़ी कंपनियाँ 5 साल पुराने software भी आराम से चलाती हैं, और मेरे लिए Redis का 2012 वर्ज़न या Postgres का 2020 वर्ज़न भी काफ़ी ठीक है

  • मैंने ऐसे मामलों का history और कंपनियों की सूची एक बार संकलित की थी
    संबंधित ब्लॉग पोस्ट में यह रखा है, और अगर किसी को और उदाहरण पता हों तो साझा करें

    • isitreallyfoss.com भी संदर्भ सामग्री के रूप में उपयोगी है

  • मुझे लगा कि pro features बार-बार community version के syntax को तोड़ देते हैं, इसलिए transparency बिल्कुल नहीं है
    बिलकुल, काम का उचित प्रतिफल मिलना चाहिए, लेकिन "हम पहले open source थे और फिर चुपचाप नहीं रहे" अब बहुत आम होता जा रहा है
    ऐसे बदलाव हमेशा जैसे चुपचाप किए जाते हैं, मानो उम्मीद हो कि किसी का ध्यान न जाए

    • वास्तव में FSL का आम developer के रोज़मर्रा के flow पर बड़ा असर नहीं पड़ता
      मुझे जिज्ञासा है कि वास्तविक नुकसान या मुख्य समस्या आख़िर है क्या
      बल्कि मुझे competitive और non-competitive उपयोग के बीच का फ़र्क पसंद है

  • comments का माहौल थोड़ा अजीब लग रहा है
    ज़्यादातर लोग सिर्फ़ "base" देखकर बिल्कुल असंबंधित services सुझा रहे हैं, या फिर कह रहे हैं कि source available है तो वह open source है

  • मुझे पता ही नहीं था कि Liquibase ने लाइसेंस बदल दिया है
    असल में लगभग हर web framework के विकल्प हैं, और Alembic तथा Flyway जैसे framework-independent विकल्प भी बहुत हैं
    इस समय यह कदम थोड़ा अजीब लगता है

  • यह मुद्दा Keycloak जैसे OSS projects के लिए भी समस्या पैदा कर सकता है
    CNCF policy के अनुसार non-open-source licenses का इस्तेमाल नहीं किया जा सकता, इसलिए Keycloak Liquibase का उपयोग नहीं कर सकता
    Debian, Fedora जैसी distributions में भी OSS license की शर्तें होती हैं, इसलिए सोच रहा हूँ कि क्या ऐसे distributions में Liquibase पर निर्भर projects शामिल हो पाएँगे
    Keycloak issue का विस्तृत लिंक

    • Liquibase को Debian, Fedora के main repos में शामिल नहीं किया जा सकता
      लेकिन अलग repositories या rpm fusion non-free जैसे custom repos में शामिल किया जा सकता है