Bear अब source-available लाइसेंस में बदल गया है

 (herman.bearblog.dev)
5 पॉइंट द्वारा GN⁺ 2025-09-02 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Bear प्रोजेक्ट ने MIT लाइसेंस से Elastic License में बदलाव किया है
  • पहले का MIT लाइसेंस कोड के मुक्त उपयोग और fork की अनुमति देता था, लेकिन नया लाइसेंस इसे होस्टेड सर्विस उपलब्ध कराने पर सीमित करता है
  • कई open source प्रोजेक्ट भी मुफ्त प्रतिस्पर्धा रोकने के लिए इसी तरह के लाइसेंस बदलाव अपना रहे हैं
  • AI युग में कोड की नकल कर उसे सर्विस के रूप में उपलब्ध कराना बहुत आसान हो गया है
  • कोड का खुलापन महत्वपूर्ण है, लेकिन यूज़र कम्युनिटी और लगातार संचालन की इच्छा ही Bear की असली ताकत है

Bear के source-available लाइसेंस बदलाव की पृष्ठभूमि

  • Bear प्रोजेक्ट ने शुरुआत में MIT लाइसेंस के तहत source public किया था, ताकि सीखने, auditability, और यूज़र्स को privacy और security के प्रति भरोसा देने का लक्ष्य पूरा हो सके
  • लेकिन समय के साथ Bear प्रोजेक्ट के कोड पर आधारित प्रतिस्पर्धी सर्विसेज़ सामने आने लगीं
    • अपने software को प्यार से विकसित किया गया था, लेकिन source का आसानी से कॉपी होकर प्रतिस्पर्धा में बदल जाना निराशा और आर्थिक असुरक्षा का कारण बना
    • open source के मूल्यों पर भरोसा था, लेकिन व्यवहार में कठिनाइयाँ झेलनी पड़ीं

लाइसेंस बदलने का फैसला

  • हाल की घटनाओं के बाद, MIT लाइसेंस से Elastic License (Elastic Search में अपनाए गए copyleft तरीके) में बदलने का निर्णय लिया गया
    • Elastic License, MIT से मिलता-जुलता है, लेकिन software को होस्टेड या managed service के रूप में उपलब्ध कराने पर रोक लगाता है
    • लाइसेंस की विस्तृत शर्तें GitHub लिंक par dekhi ja sakti hain

open source ecosystem का रुझान

  • जाँच से पता चला कि कई open source प्रोजेक्ट पिछले कुछ वर्षों में "फ्री-राइडिंग प्रतिस्पर्धा" को रोकने के लिए लाइसेंस को सीमित करने की दिशा में बढ़े हैं
    • उदाहरण: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry आदि कई प्रोजेक्ट ने ऐसे ही फैसले लिए हैं

AI युग और बढ़ती प्रतिस्पर्धा

  • AI coding tools के आने से, “इस repository को fork करो, नाम बदलो, और EC2 पर deploy कर do” जैसी तेज़ नकल और service-ization संभव हो गई है
  • इस तरह का बदला हुआ माहौल मूल रचयिता पर और अधिक बोझ और जोखिम डालता है

Bear की खास वैल्यू

  • Bear platform की असली वैल्यू सिर्फ source code में नहीं, बल्कि इसका उपयोग करने वाली community और operator की दीर्घकालिक जिम्मेदारी में है
  • आगे कोड स्तर पर कुछ सीमाएँ आ सकती हैं, फिर भी platform को ईमानदारी से maintain करते रहने की प्रतिबद्धता जताई गई है

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

3 टिप्पणियां

 
coremaker 2025-09-02

ऐसा लगता है कि GPLv3 और AGPL का इस्तेमाल उनके लाइसेंस बनाने वालों की मूल मंशा के अनुसार नहीं हो रहा है.
ज़्यादातर मामलों में dual license की अनुमति देने की वजह से, मैंने बहुत बार देखा है कि आखिरकार इन्हें commercial उपयोग को मजबूर करने वाले एक साधन की तरह इस्तेमाल किया जाता है.

इस मायने में, मुझे लगता है कि Apache या MIT उन गिने-चुने open source लाइसेंसों में हैं जो अपनी शुरुआती मंशा के मुताबिक काम करते हैं.
(हालांकि, मुझे नहीं लगता कि कोई पूरी तरह निष्कलंक open source लाइसेंस मौजूद है.)
 
GN⁺ 2025-09-02
Hacker News टिप्पणियाँ

  • मेरी समझ के अनुसार, 'Open Source' खेमे का रुख यह है कि अगर Amazon उसे AWS service के रूप में पेश नहीं कर सकता, तो वह असली open source नहीं है, और अगर कोई इसके विपरीत कहे तो वे काफ़ी नाराज़ हो जाते हैं।
    काश सब लोग लेखक जिस 'free-rider competition' की बात कर रहा है, उसे थोड़ा और स्वीकार करते। Herman जो कर रहा है, वह सबके लिए फ़ायदेमंद है, इसलिए अच्छा होता अगर "source-available" से बेहतर कोई नया शब्द होता जो इस community project की भावना को ठीक से व्यक्त करता।
    नीचे की टिप्पणी में मेरी बात बेहतर तरह से संक्षेपित है, इसलिए उसे जोड़ रहा हूँ:
    बाज़ार की स्वाभाविक winner-takes-all संरचना free and open source software (FOSS) के मिशन के लिए मददगार नहीं है। अगर बड़ी कंपनियों को इस तरह कमाई करने से नहीं रोका जाता, तो यह open source के मिशन को गंभीर रूप से कमज़ोर करता है। और इस प्रक्रिया में उपयोगकर्ता बड़ी कंपनियों के proprietary software और FOSS के मिश्रित जाल में फँस जाते हैं

    • मूल open source खेमे का रुख GPL → GPLv3 → AGPL जैसे लाइसेंसों का था, जो इस समस्या को साफ़ तौर पर रोकने का समर्थन करते थे
      MIT/BSD/Apache जैसे permissive licenses का व्यापक होना, मुझे corporate हितों के तहत free software विचारधारा को कमज़ोर करने की एक जानबूझकर चली धारा जैसा लगता है

    • ज़्यादातर लोगों को non-open-source software से भी कोई खास शिकायत नहीं होती
      समस्या तब होती है जब Terraform जैसे project open source होने की वजह से लोकप्रिय होते हैं और बढ़ते हैं, लेकिन फिर उसका maintainer उसे closed license में बदल देता है, जिससे उसकी मूल सफलता की बुनियाद ही हट जाती है
      और अगर contributors ने CLA (Contributor License Agreement) पर हस्ताक्षर किए हों, जिससे उनके code को भी मनमाने ढंग से closed license में बदला जा सके, तो वह दोगुना निराशाजनक है

    • अगर आपको open source की परवाह नहीं है, तो बस उसका इस्तेमाल मत कीजिए, अब तक open source का एक साफ़ और सुसंगत मतलब रहा है
      हर कोई अपनी मर्ज़ी से software बना सकता है, अपने मूल्यों के अनुसार चुनकर इस्तेमाल कर सकता है, इसमें समस्या जैसी कोई बात नहीं है

    • कोई भी अपनी पसंद का license इस्तेमाल कर सकता है, लेकिन यह सोचना ज़रूरी है कि ज़्यादातर open source developers MIT जैसे उदार license क्यों चुनते हैं
      व्यवहार में अच्छे open source का बाज़ार इतना बड़ा है कि विकल्प बहुत हैं, और अगर आप license पर पाबंदियाँ लगाते हैं तो लोग बस दूसरा विकल्प चुन लेते हैं
      इसलिए GPL जैसे license के साथ किसी project का व्यापक रूप से अपनाया जाना मुश्किल हो जाता है। हाँ, Linux या WordPress जैसे अपवाद बहुत सफल हुए, लेकिन यह आम बात नहीं है
      MIT जैसे permissive license के साथ भी कमाई करना कठिन है, लेकिन अगर उपयोगकर्ता ही न हों तो और भी मुश्किल हो जाता है
      यह अच्छा है या बुरा, इस पर बहस हो सकती है, लेकिन व्यवहार में लोग तर्कसंगत ढंग से ही काम कर रहे हैं। मूल रूप से software उतनी दुर्लभ चीज़ नहीं है

    • क्या AGPL ऐसे ही मामलों के लिए नहीं बनाया गया था?
      AGPL एक OSI-मान्य open source license है, जो software को network service के रूप में पेश किए जाने पर प्रतिबंध लगाता है

  • सोच रहा हूँ कि क्या maintainer ने Fair Source देखा है fair.io
    मुझे Fair Source, 'source-available' से बेहतर लगता है, क्योंकि यह DOSP(opensource.org/dosp) के तहत अंततः पूर्ण open source बनने का रास्ता भी देता है, इसलिए मुफ़्त और paid दोनों तरह के उपयोगकर्ताओं के लिए फ़ायदेमंद है, और खासकर Bear जैसे blog platform के लिए आदर्श मॉडल है
    FCL(fcl.dev) Fair Source License भी Bear Blog License की दिशा से मिलता-जुलता है, और Bear manifesto(herman.bearblog.dev/manifesto/) से भी अच्छी तरह मेल खाता है
    इससे, भले ही Bear PTY LTD बंद हो जाए, Bear खुद जारी रह सकता है (DOSP के तहत इसे परिभाषित किया जा सकता है)
    मैं Fair Source के drafting में भी शामिल रहा हूँ

    • हमारे product(morphik.ai) पर BSL(Business Source License) लागू है, और आधिकारिक तौर पर हम बस इतना कहते हैं कि repository public है (github.com/morphik-org/morphik-core)
      फिर भी 'fair source' शब्द सुनने में काफ़ी अच्छा लगता है
      क्या ऐसा मानें कि Apache या MIT की तरह समय बीतने पर open source बनने वाला software fair source कहलाएगा, या इसके लिए कुछ और जटिल मानदंड हैं?

  • मुझे लगता है कोई व्यक्ति काफ़ी हद तक भोला था। अगर आप MIT license चुनते हैं, तो कोई भी आपके code का जैसा चाहे वैसा इस्तेमाल कर सकता है। फिर बाद में जब कमाई करनी हो, तो समाधान के लिए कोई अजीब license ले आते हैं
    आख़िरकार विकल्प MIT/BSD, GPL, LGPL, AGPL ही हैं, बाकी लाइसेंस सिर्फ़ बेकार compatibility समस्याएँ पैदा करते हैं

    • मैं भी इस राय से सहमत हूँ। अगर सच में 'बिना शर्त' source public करना है, तो MIT चुनना चाहिए
      इस मामले में ऐसा नहीं लगता कि यह सचमुच साफ़ इरादा था, बल्कि कुछ धुँधले तरीके से 'अच्छा इंसान' और 'व्यवसायी' दोनों दिखने की कोशिश रही होगी

    • MPL(Mozilla Public License) भी काफ़ी उपयोगी और कम आंका गया license है
      यह GPL परिवार की तुलना में साफ़ तौर पर कम infectious है, और MIT/BSD की तुलना में ज़्यादा सीमित है (modifications को distribute करते समय source public करना पड़ता है)

    • MIT और BSD patent rights की गारंटी नहीं देते, इसलिए Apache License चुनने का एक अच्छा कारण यही है

    • Guy (निर्माता) शायद बस अपना project बना रहा था और source public करने को ही महत्व दे रहा था
      मुझे नहीं लगता कि इसके पीछे कोई खास strategic उद्देश्य था

    • जो उपयोगकर्ता यह मानते हैं कि open source project हमेशा open source ही रहेगा, वे भी भोले हैं
      लेखकों के पास license बदलने का अधिकार होता है, और इस पर चौंकना भी, या यह मानना कि open source से business बनाना आसान होगा, दोनों ही भोलेपन की बातें हैं

  • अगर आप competitive use को शुरू से रोकना चाहते हैं, तो आम तौर पर यही तरीका अपनाया जाता है। और अब 'open source' शब्द का इस्तेमाल न करना भी सही फैसला है
    लेकिन ज़्यादातर मामलों में मुझे AGPL बेहतर विकल्प लगता है। AGPL होने पर बड़ी कंपनियाँ अपने internal compliance नियमों की वजह से code इस्तेमाल नहीं कर पातीं, जिससे बड़े providers के प्रवेश पर रोक लगती है

    • AGPL को व्यावहारिक रूप से OSI-स्वीकृत source-available license की तरह इस्तेमाल करने की सलाह देना शर्मनाक है
      यह open source की मूल भावना के साथ विश्वासघात है

  • "आपने MIT के तहत open किया, और अब कोई आपके code से business करके पैसा कमा रहा है। यह देखकर हैरानी होती है कि आपने ऐसा नतीजा सोचा ही नहीं"
    ऐसा बार-बार क्यों होता है? इतने सारे developers इस स्पष्ट परिणाम को पहले से क्यों नहीं देख पाते, यह सोचने वाली बात है

    • MIT license GitHub पर नया project बनाते समय dropdown से आसानी से चुना जाने वाला default हुआ करता था, इसलिए entry barrier बहुत कम था
      जब project नया होता है और पता नहीं होता कि वह आगे कैसे बढ़ेगा, तब यह कल्पना करना मुश्किल होता है कि वह इतना बड़ा बन जाएगा कि बाद में license की चिंता करनी पड़े

    • MIT license मूल रूप से project को बाद में दोबारा relicense करने की अनुमति देता है
      Bear maintainer ने शुरुआत में permissive license चुना, फिर हालात बदलने पर उसे अधिक सख़्त license में बदल दिया
      मुझे यह एकदम तर्कसंगत निर्णय लगता है

    • मुझे लगता है 15~20 साल पहले BSD खेमे ने open source culture war जीत ली थी, इसलिए आज हम यह देख रहे हैं
      अगर GNU license वाला खेमा जीत गया होता, तो आज ecosystem कितना अलग होता, यह सोचने लायक है

  • मैंने Bear को इसलिए support किया क्योंकि वह open source था, लेकिन अगर अब ऐसा नहीं है तो support जारी रखने का कारण नहीं बचता, इसलिए मैंने subscription cancel कर दी
    अगर यह AGPL पर वापस जाए तो वह सचमुच स्वागतयोग्य होगा

    • मुझे लगता है Bear ने भी और मैंने भी, दोनों ने अपने-अपने स्तर पर उचित निर्णय लिया
      Bear को अपनी पसंद का license चुनने की आज़ादी है, और मुझे यह तय करने की कि मैं उसका इस्तेमाल करूँ या नहीं
      open source license का मूल उद्देश्य आम तौर पर आर्थिक लाभ नहीं बल्कि sharing होता है
      सिर्फ़ open source projects को support करना भी पूरी तरह समझ में आता है
      जब कमाई पैदा करनी ज़रूरी हो जाए, तब open source license शायद उपयुक्त न रहे
      कुछ developers यह ग़लतफ़हमी पाल लेते हैं कि open source उनकी आय की रक्षा करेगा, और कुछ उपयोगकर्ता यह मान लेते हैं कि project हमेशा open source ही रहेगा
      source-available या shipped-with-source जैसे मॉडल भी एक तरह के proprietary licenses हैं, उनका open source होना ज़रूरी नहीं है

  • “उपयोगकर्ता software की मुख्य functionality को host की गई service या managed service के रूप में प्रदान नहीं कर सकता”
    मैं वकील नहीं हूँ, लेकिन जानना चाहता हूँ कि क्या यह पाबंदी Bear को खुद install करके internal या personal use के लिए चलाने पर भी लागू होती है
    सच कहूँ तो अगर वह भी अनुमति नहीं है, तो फिर MIT license रखने का कारण क्या था, समझ नहीं आता
    Bear Blog License मूल पाठ

    • कोई व्यक्ति या कंपनी internal या personal use के लिए Bear को खुद host कर सकती है
      लेकिन उसे दूसरों या दूसरी कंपनियों को service के रूप में देना अनुमति नहीं है
      संदर्भ: Elastic License FAQ

  • निराशा समझ में आती है, लेकिन नया license थोड़ा अस्पष्ट है
    जब लिखा है "hosting/managed service के ज़रिए functionality प्रदान नहीं की जा सकती", तो क्या सामान्य VPS provider भी, जहाँ package manager से install किया जाता है, इसके दायरे में आएगा?
    अगर 1-click install जैसा setup script हो तो क्या होगा, या process के दौरान सिर्फ़ उसका ज़िक्र न किया जाए तो ठीक माना जाएगा? यह सब थोड़ा धुंधला लगता है
    ऐसा लगता है जैसे कोई 'नाटक' हो, जहाँ तीसरा पक्ष install script दे दे तो ठीक है, और service flow में उसका ज़िक्र न हो तो सब मान्य हो जाता है

    • यहाँ 'उपयोगकर्ता' से मतलब end user है
      यानी software को दूसरों को service (मुफ़्त/paid) के रूप में देना मना है, लेकिन खुद इस्तेमाल करना ठीक है
      मुख्य बात यह है कि accounts उपलब्ध कराना ही प्रतिबंधित माना जाना चाहिए
      turnkey hosting देना भी प्रतिबंधित है, लेकिन समस्या hosting देने वाले से ज़्यादा उस पक्ष से है जो उस hosted instance पर user accounts बनाकर बेचता है
      यह wording Amazon जैसी बड़ी कंपनियों को इस तरह database instance उपलब्ध कराकर उस पर सिर्फ़ account जारी करने से रोकने के लिए है
      दूसरी ओर, सिर्फ़ VM पर package manager से install करना ठीक है
      फिर भी इस तरह के license बहुत उलझाऊ और अस्पष्ट होते हैं
      अगर इसे open source ही बनाए रखना है, तो स्वाभाविक है कि आप चाहेंगे कि बहुत लोग इसका उपयोग करें, लेकिन अगर आप नहीं चाहते कि कोई और इसे host करे, तो code share करने के बजाय बस 'All rights reserved' ही छोड़ सकते हैं

  • मैं उसके मकसद और source public करने की इच्छा को समझता हूँ, लेकिन अगर चिंता competition की थी तो MIT की जगह AGPL पर विचार करना ज़्यादा स्वाभाविक लगता, यही सोच रहा हूँ

    • क्या AGPL के तहत भी कोई दूसरा व्यक्ति code में बदलाव किए बिना उसे जस का तस commercial रूप में फिर से नहीं बेच सकता?
      AGPL तो सिर्फ़ modifications के source को public करने के लिए बाध्य करता है
      यहाँ शायद समस्या यह है कि कोई Bearblog को लगभग ज्यों का त्यों, या बस नाम थोड़ा बदलकर commercial रूप में पेश कर दे

    • शायद शुरुआत में उसे competition की चिंता नहीं थी, और धीरे-धीरे जब वह समस्या बनी, तब उसने license बदला

  • व्यक्तिगत रूप से मुझे यही मॉडल (source public + hosting restrictions वगैरह) सबसे अच्छा license model लगता है
    मैं अपनी पसंद के अनुसार code देख और बदल सकता हूँ, और साथ ही project तथा maintainer भी अत्यधिक competition के दबाव के बिना अपनी नींव बचाए रख सकते हैं
    अगर शुरुआत से ही ऐसा किया जाए, तो बाद में अचानक बदलाव से विवाद खड़े होने या forks के मूल project से आगे निकल जाने की नौबत भी टल सकती है
    हालाँकि मुझे नहीं लगता कि Bear इतना बड़ा प्रभाव पैदा करने वाला project था
    मैं mataroa.blog का भी कभी-कभी अच्छी तरह उपयोग करता हूँ, और उम्मीद करता हूँ कि Bear maintainer को अपने project से संतोष मिलता रहे
 
ndrgrd 2025-09-02

असल में open source प्रोजेक्ट्स के लिए यूज़र्स की दिलचस्पी और उनका योगदान ही लगभग एकमात्र संसाधन होता है।
अगर प्रोजेक्ट पूरी तरह स्थापित स्तर तक नहीं पहुँचा है, तो कोई भी—खासकर बड़ी कंपनियाँ—उसे fork करके सारा ध्यान अपने नाम कर लें, तो आखिर में फायदा किसी और का ही होता है।

शुरुआत से ही ऐसे licenses यूज़र्स की आज़ादी के लिए थे, डेवलपर्स के लिए नहीं।

क्या आप जानते हैं कि Windows के CLI package manager winget के मामले में भी Microsoft ने किसी और के प्रोजेक्ट को लगभग जस का तस fork करके सिर्फ नाम बदलकर जारी किया था?
मूल प्रोजेक्ट appget के लेखक ने इस पर एक लेख भी लिखा है।
The Day AppGet Died.

अगर आप—खासकर बड़ी कंपनियों या viral फैलाने में माहिर लोगों के लिए—सिर्फ दूसरों का भला करने भर तक सीमित नहीं रहना चाहते और अपने समय की क़ीमत समझते हैं, तो open source license अपनाने के बारे में फिर से सोचने की ज़रूरत है।
एक ही तरह की volunteer contribution में भी, योगदान के लिए सम्मान मिलना और पूरी तरह नज़रअंदाज़ कर दिया जाना—इन दोनों में बहुत बड़ा फ़र्क होता है।

Hacker News की टिप्पणियों में दिए गए ऐसे विकल्पों को देखिए.