Redis ने dual source-available लाइसेंसिंग अपनाई

 (redis.com)
2 पॉइंट द्वारा GN⁺ 2024-03-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Redis Redis 7.4 से BSD 3-Clause वितरण बंद कर रहा है और आगे Redis को RSALv2 या SSPLv1 के तहत उपलब्ध कराएगा, जिससे लाइसेंसिंग की सीमाएँ बड़े स्तर पर बदल जाएँगी
  • source code, Redis Community Edition के रूप में मुफ़्त उपलब्ध रहेगा, लेकिन नया लाइसेंस OSI-परिभाषित open source नहीं माना जाएगा
  • Redis, Core और Stack को एकीकृत करके search, JSON, vector, probabilistic data structures और time-series data model को एक मुफ़्त पैकेज में शामिल करने की योजना बना रहा है
  • internal/personal use, client libraries, integration partners और मौजूदा Redis Enterprise customers पर इसका असर नहीं होगा, लेकिन प्रतिस्पर्धी managed services नया Redis source code मुफ़्त में इस्तेमाल नहीं कर सकेंगी
  • Redis 8 से Redis Stack की सुविधाएँ सीधे Redis में शामिल होंगी, और उसके बाद अलग Redis Stack build का end-of-life शुरू होगा

Redis लाइसेंस बदलाव का दायरा

  • Redis अब आगे आने वाले सभी Redis versions को source-available license के तहत वितरित करेगा
  • Redis 7.4 से Redis Core software को Redis Source Available License v2 या Server Side Public License v1 में से किसी एक के तहत इस्तेमाल किया जा सकेगा
  • इसे अब BSD 3-Clause license के तहत वितरित नहीं किया जाएगा
  • Redis source code, Redis GitHub repository के माध्यम से Redis Community Edition के रूप में मुफ़्त उपलब्ध रहेगा
  • RSALv2 और SSPLv1, दोनों OSI-approved licenses नहीं हैं, और दोनों में उपयोग संबंधी प्रतिबंध हैं

Redis Stack एकीकरण और product composition में बदलाव

  • आगे की source-available releases में Redis Core और Redis Stack को एकीकृत किया जाएगा
  • इसमें search, JSON, vector, probabilistic data structures और time-series data model शामिल होंगे
  • इसे एक मुफ़्त download package के रूप में उपलब्ध कराया जाएगा, और Redis का उपयोग इन कामों के लिए किया जा सकेगा
    • high-performance key/value store
    • document store
    • query engine
    • generative AI applications के लिए low-latency vector database
  • Redis 8 से, मौजूदा Redis Stack में RSALv2 या SSPLv1 के तहत उपलब्ध नए data types और processing engines को default offering में शामिल करने की योजना है
  • Redis 8 उपलब्ध होने के बाद अलग Redis Stack build की ज़रूरत नहीं रहेगी और Redis Stack end-of-life प्रक्रिया शुरू होगी

बदलाव की पृष्ठभूमि और Redis का दृष्टिकोण

  • Redis का कहना है कि वह Redis Stack distribution के advanced Redis modules पर पहले से ही dual licensing लागू करता आ रहा है, और Redis 6 के बाद redis.io downloads में 50% से अधिक Redis Stack से आए हैं
  • Redis का मानना है कि एक साथ कई distributions बनाए रखना उसके भविष्य के development roadmap से टकराता है
    • open source distribution
    • source-available distribution
    • on-premises और cloud platforms के लिए optimized commercial software
  • Redis का कहना है कि बड़े cloud service providers, Redis के निवेश और open source community का commercialization कर रहे हैं
  • यह बदलाव, feature-rich free software और enterprise products में निवेश जारी रखने के लिए commercial usage को manage करने का कदम है
  • इस बदलाव के बाद Redis, OSI definition के अनुसार अब open source नहीं रहेगा

users और partners पर असर

  • Redis के मौजूदा open source versions या नई dual-licensed releases को internal/personal use के लिए इस्तेमाल करने वाले end users पर कोई असर नहीं होगा
  • Redis के साथ काम करने वाली client libraries या अन्य integrations बनाने वाले partners पर भी कोई बदलाव नहीं होगा
  • Redis द्वारा मेंटेन की जाने वाली सभी Redis client libraries open source license के तहत ही रहेंगी
  • मौजूदा Redis Enterprise customers पर कोई असर नहीं होगा, क्योंकि उन्हें अलग से negotiated license terms के तहत technology मिलती है
  • Redis Community Edition या Enterprise का non-competitive तरीके से उपयोग करने वाले integration और managed service partners, Redis के साथ partnership के जरिए समाधान बनाना, चलाना और उपलब्ध कराना जारी रख सकेंगे
  • Partner Program भविष्य में Redis technology, features और releases तक exclusive access देगा

cloud services और competing products पर प्रतिबंध

  • नए license के तहत Redis hosting service देने वाले cloud service providers, Redis source code को मुफ़्त में इस्तेमाल नहीं कर सकेंगे
  • उदाहरण के लिए, कोई cloud service provider Redis 7.4 तभी उपलब्ध करा सकेगा जब वह code maintainer Redis के साथ license terms पर सहमत हो
  • Redis के अनुसार “competitive offering” ऐसा product है जो Redis codebase से निकला हो, Redis commercial products की सुविधाओं से काफ़ी मेल खाता हो, और किसी तीसरे पक्ष को बेचा जाता हो
    • paid support contract के तहत बिक्री भी इसमें शामिल है
    • उदाहरण के तौर पर, ऐसा solution जिसमें Redis को host या embed किया गया हो और जिसे Redis Enterprise Software या Redis Cloud के प्रतिस्पर्धी रूप में बेचा जाता हो
  • Redis का उपयोग करने वाले लेकिन Redis से सीधे प्रतिस्पर्धा न करने वाले solutions पर इसका असर नहीं होगा
  • विशेष use cases के लिए redis_licensing@redis.com पर संपर्क करने को कहा गया है

RSALv2 और SSPLv1 की शर्तें

  • RSALv2 एक non-copyleft permissive license है, जो software के उपयोग, copy, distribution, making available और derivative works तैयार करने की अनुमति देता है
  • RSALv2 में दो मुख्य प्रतिबंध हैं
    • software का commercialization नहीं किया जा सकता और न ही इसे managed service के रूप में दूसरों को दिया जा सकता है
    • license, copyright या अन्य notices को हटाया या छिपाया नहीं जा सकता
  • SSPLv1 AGPL पर आधारित है, और यदि software को service के रूप में दिया जाता है तो पूरी service का source code SSPL के तहत जारी करना होगा
    • इसमें management software, user interfaces, API, automation software, monitoring, backup, storage और hosting software शामिल हैं
    • MongoDB इस license का publisher है
  • SSPL के तहत licensed software के modified version को किसी दूसरे license के तहत redistribute नहीं किया जा सकता
  • dual license में RSALv2 चुनने पर, जब तक RSALv2 के प्रतिबंधों का पालन हो—जैसे कि functionality को किसी तीसरे पक्ष को service के रूप में न देना—तब तक modification और redistribution संभव है

मौजूदा BSD versions और security patches

  • license बदलाव retroactive नहीं है
  • बदलाव से पहले का सारा source code और releases, BSD 3-Clause license के तहत ही रहेंगे
  • users, संबंधित license terms का पालन करते हुए मौजूदा BSD versions को अनिश्चित काल तक इस्तेमाल कर सकते हैं
  • Redis की योजना है कि Redis Community Edition उपलब्ध रहने तक, मौजूदा security policy के अनुसार संबंधित releases के security updates और critical bug fixes देता रहे
  • मौजूदा BSD 3-Clause versions के लिए critical security patch backports, Redis Community Edition 9.0 जारी होने से पहले तक दिए जाएँगे; उसके बाद patches नए dual license के तहत उपलब्ध होंगे

naming, contributions और code mixing की शर्तें

  • Redis 7.2 और उससे पहले की releases को Redis OSS ही कहा जाएगा
  • Redis 7.4 से सार्वजनिक और मुफ़्त उपलब्ध version को Redis Community Edition कहा जाएगा
  • product names में अब “Redis” या “for Redis” का उपयोग नहीं किया जा सकेगा, लेकिन product description में Redis-compatible या legacy-Redis-based लिखा जा सकता है
  • community contributions पहले की तरह स्वीकार किए जाएँगे, लेकिन contribution review के लिए Contributor License Agreement से सहमति ज़रूरी होगी
  • RSALv2 या SSPLv1 code और अन्य licenses वाले code को साथ में इस्तेमाल किया जा सकता है, बशर्ते हर component अपना license बनाए रखे और GPL जैसे strong copyleft code के साथ mix न किया जाए
  • किसी संगठन के भीतर service के रूप में Redis host करना अनुमत है, और संगठन में affiliates तथा subsidiaries शामिल हैं

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

1 टिप्पणियां

 
GN⁺ 2024-03-22
Hacker News की राय

  • इससे Redis Labs के भी बिगड़ने की काफी संभावना है, जैसे Hashicorp दबाव में आकर खरीदार ढूंढती दिखी थी, और शायद यह Redis Labs की नकल करने वालों को भी रोक नहीं पाएगा
    असली नुकसान उन छोटे startups को होगा जो कानूनी झंझट के बिना Redis cache इस्तेमाल करना चाहते हैं। AWS Redis को fork कर सकता है, और अगर वह उस fork को permissive license के तहत जारी कर दे, तो license के लिहाज से Redis Labs वाला विकल्प और खराब दिख सकता है
    यह मुश्किल फैसला है, लेकिन मेरे हिसाब से बेहतर है कि code को proprietary रखा जाए, या फिर Apache या MIT पर ही टिके रहें। बीच में license बदलना सच में खराब है और उल्टा असर करने के लिए बना हुआ लगता है
    Open source का मतलब है users को software पर ownership जैसा नियंत्रण देना। पैसा कमाने के लिए कानूनी चालों से इसे bypass करने की कोशिश की जाए, तो चोट बड़ी कंपनियों की teams को नहीं, users को लगती है। Redis हमेशा से permissive open source project रहा है, और इसी वजह से सफल हुआ। उन शर्तों को बदलने से आगे का पूरा हिसाब बदल जाता है, और इसमें जुड़े सभी लोगों के लिए खराब नतीजों का संकेत मिलता है

    • यह घटना लंबे समय में इस विचार को लगभग खत्म करती लगती है कि कंपनियां open source users की जरूरतों की अच्छी संरक्षक हो सकती हैं
      हमें PostgreSQL जैसे foundation-owned software और कंपनी-स्वामित्व वाले open source के बीच का फर्क और साफ देखना चाहिए। जब focus “shareholder value maximize” करने पर होता है, तो users की आजादी बचाने का लक्ष्य आखिरकार पीछे धकेला ही जाएगा
      Redis community के लिए बेहतर होता कि Antirez रोजगार संबंध और project ownership को अलग करके इसे किसी nonprofit के हवाले कर देते। Apache Redis जैसा कोई रूप community के लिए बेहतर होता, और Redis Labs भी उसके आसपास proprietary extensions और cloud business बना सकती थी
    • समय के साथ मैं इस नजरिए से सहमत हो गया हूं, और इसे ऐसे सारांशित करता हूं: अगर लक्ष्य profit है, तो core product को open source के रूप में जारी न करें
      हमने बार-बार देखा है कि जब कोई कंपनी अपना core software permissive license के तहत जारी करती है, तो कोई बड़ा competitor आकर उसी software को redistribute करने वाला solution बेचने लगता है
      अगर कंपनी का मुख्य लक्ष्य profit है, तो यह अस्तित्व के लिए खतरा है। इसके उलट, अगर कंपनी का लक्ष्य nonprofit maintainer की तरह software को जारी रखना है, तो यह बड़ी सफलता है
      यह logic उन auxiliary software पर लागू नहीं होता जो core product नहीं हैं—जैसे ऐसे उपयोगी tools जो development के दौरान बने, लेकिन जिन्हें सीधे बेचकर पैसा कमाना लक्ष्य नहीं है
    • Open source में “तुम लोग implement करो, हम बेचेंगे, धन्यवाद” वाली समस्या है
      यह license बदलाव उसी समस्या, यानी cloud hyperscalers को मुफ्त में फायदा उठाने से रोकने की कोशिश है
      मुझे यह बेहतर AGPL जैसा लगता है। दार्शनिक बारीकियों या OSI approved list में मेरी रुचि नहीं है, और आखिरकार यह AGPL से काफी कम restrictive है। source code मौजूद है, मैं इसे local पर चला सकता हूं, और अपने project, commercial project, workplace, bare metal, VM, Docker, k8s, Azure में एक ही तरह से इस्तेमाल कर सकता हूं
      Microsoft को जो premium पहले से मिल रहा है, उसका एक हिस्सा उसे share करना पड़े—इससे मेरा कोई लेना-देना नहीं। बल्कि sustainable business model खोज निकालने के लिए तारीफ होनी चाहिए
    • “Open source users की software ownership है” कहना गलत है
      OSS developers copyright रखते हैं। public domain को छोड़ दें, तो license और शर्तें बदलने का अधिकार सिर्फ author के पास होता है। users को software और code से कई काम करने का license मिलता है, ownership नहीं
    • “पैसा कमाने के लिए कानूनी चालों से bypass करना” enshittification की याद दिलाता है
      पूरी तरह सहमत हूं, और लगता है Cory Doctorow की दलील में एक और उदाहरण जुड़ गया है

  • अब तक शायद fork पहले से चल रहा होगा। किसी कंपनी को अपनी ही developer community से खुद को काटते देखना थोड़ा दुखद है
    वे ऐसा क्यों कर रहे हैं, यह समझ में आता है, लेकिन मुझे नहीं लगता कि लंबी अवधि में यह चलेगा
    ज़्यादातर Redis users ने इसके पीछे वाली कंपनी को कभी एक पैसा भी नहीं दिया है, और मैंने भी नहीं। पैसे कमाने के लिए वे ऐसा कर रहे हैं, यह समझ में आता है, लेकिन मेरा व्यवहार नहीं बदलेगा। मैं बस fork इस्तेमाल करूंगा। Redis के बाकी ज़्यादातर users, बाहरी contributors, और Redis को commercially offer करने वाले सभी cloud providers भी ऐसा ही करेंगे, और समय के साथ मौजूदा Redis employees में से भी काफ़ी लोग उधर जा सकते हैं
    Commercial users और cloud providers बहुत हैं, इसलिए इनके संगठित होने में ज़्यादा समय नहीं लगेगा। पहले से बहुत सारे paying users हैं, इसलिए असल में यह लगभग होना ही है
    Terraform, Elasticsearch, Red Hat आदि में पहले से ऐसे ही उदाहरण मौजूद हैं। अपने target users और potential customers के बड़े हिस्से को open-source fork पर निर्भर बना देना business strategy के तौर पर गलत दिशा जैसा लगता है
    जब Oracle ने Sun के open-source projects, जैसे mysql, hudson, openoffice वगैरह लिए थे, तब भी उसने ज़्यादातर control बहुत जल्दी खो दिया था। Oracle के closed-source products इस्तेमाल करने के लिए मनाने की कोशिशों का ज़्यादा असर नहीं हुआ। Java तक अंततः कुछ हद तक पीछे हटा, और आजकल केंद्र openjdk है। कुछ बैंकों को छोड़ दें तो Oracle JDK इस्तेमाल करने वाले लोग बहुत कम हैं। इसकी ज़रूरत नहीं है, और Oracle ने भी बहुत पहले यह दिखावा करना बंद कर दिया कि इसमें कोई advantage है। सारी development OpenJDK में होती है, और certified builds देने वाली कई कंपनियां हैं
    व्यक्तिगत रूप से मैं Elasticsearch और Opensearch consulting करता हूं, और हाल के ज़्यादातर customers Opensearch को default मानते हैं। बस प्रवाह उसी तरफ है। सभी free और open-source विकल्प चुनते हैं
    निष्कर्ष सिर्फ एक है। ऐसा Redis fork बनेगा जिसे मौजूदा Redis users का बड़ा बहुमत इस्तेमाल करेगा

    • Microsoft ने 3 दिन पहले लगभग drop-in replacement जारी किया है[1]। उसका दावा है कि यह ज़्यादातर Redis clients के साथ काम करता है। कम से कम Azure users के लिए यह काफ़ी बड़ा बदलाव ला सकता है
      [1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
    • Long-term strategy Broadcom-style view से देखें तो शायद काम कर सकती है। बहुत सारे users पकड़ने के बजाय, product के इर्द-गिर्द अपना system बना चुके बहुत महंगे, थोड़े से customers को target करने का तरीका
      Enterprises पूरी तरह migrate न करने के लिए, या short term में migration के दौरान, price hikes झेल सकते हैं
      Short-term churn रोकने के लिए provider “time खरीदकर” prices कम रख सकता है, और जब project fork से पर्याप्त अलग हो जाए कि migration बहुत मुश्किल हो जाए, तब prices बढ़ा सकता है
      किसी भी तरह, long term में अलग-अलग sizes की बहुत सारी companies को support करते रहने के बजाय कुछ companies से बड़ी कमाई हो सकती है। मुझे यह पसंद नहीं है, लेकिन लगता है कि यह काम कर सकता है
    • एक fork पहले से चल रहा है: https://codeberg.org/redict/redict
    • Long term में FOSS को industry की किसी समय की trend माना जा सकता है और शायद वह फिर दोहराई न जाए। Industry वापस ऐसे trial और demo versions की तरफ स्थिर हो सकती है जिनमें free tier या source code में full functionality नहीं दी जाती
    • Cynically देखें तो Oracle के पास पहले से कहीं ज़्यादा महंगा alternative था, इसलिए उसे MySQL को revenue-focused बनाने की ज़रूरत नहीं थी
      MySQL community को बांटना, usage और external development को कमजोर करना, और पूरे project की गति धीमी करना ही अच्छा return on investment दे सकता था

  • ऐसे projects की बड़ी driving force अब भी hosting revenue है, और इसी वजह से license changes होते हैं
    trend देखें तो project-owning company के लिए suitable open source शायद सिर्फ libraries ही हैं। अगर program हो, जैसे database जैसा server software, तो उसे source-available होना चाहिए या किसी foundation के तहत होना चाहिए। यह कठिन है और सही जवाब क्या है, मुझे नहीं पता
    मैं ऐसा model देखना चाहूंगा जो complex programs के लिए permissive open-source licenses को वापस ला सके, लेकिन अभी कोई viable तरीका नहीं दिखता। शायद trademark enforcement और open-source code, और केवल licensed builds provide करने का तरीका हो सकता है
    बहरहाल, आगे भी popular open-source software का उदय और पतन, या license changes देखते रहेंगे। Developers और companies के लिए शुरुआत में open-source से शुरू करने के फायदे बहुत बड़े हैं, और बाद में बदलने का दबाव भी बहुत बड़ा है
    कम से कम मैं यह मानना चाहूंगा कि Redis ने दुनिया को जितनी value दी, वह उससे ली गई value से कहीं ज़्यादा थी। सचमुच भारी अंतर है
    यह देखना दिलचस्प होगा कि fork कितनी जल्दी आता और सफल होता है, और 5 साल बाद Redis नाम की company की revenue growth curve कैसी होगी

    • आखिरकार, क्या यह वही structure नहीं है जहां विशाल cloud providers Redis जैसी companies का lunch खा जाते हैं?
      Licenses के बारे में मुझे अच्छी तरह नहीं पता, लेकिन foundational technology बनाने वाली small-to-mid-sized companies को oligopolistic cloud giants द्वारा commoditize करके ऊंची कीमत पर resell किए जाने की स्थिति से मैं काफी सहमत हूं। बल्कि हैरानी है कि इसमें इतना समय लगा
      अगर मानें कि companies और open source दोनों ही healthy ecosystem चाहते हैं, तो license change के अलावा क्या विकल्प हो सकते हैं, यह जानने की उत्सुकता है
    • मुझे नहीं लगता कि foundation इस समस्या का कोई magical solution है
      ऐसे कई मामले हैं जहां एक single company ने foundation से बाहर effectively “fork” करके निकलने का फैसला किया, और community अंततः वही परिणाम झेलती है
    • “complex programs के लिए permissive open-source license” से मतलब AGPL3 जैसा कुछ है?
      https://spdx.org/licenses/AGPL-3.0-or-later.html
    • यह मान लेना मददगार होगा कि developers भी बाकी professionals से अलग नहीं हैं। अपने काम के लिए compensation की उम्मीद रखते हुए work tools बनाने वाले व्यक्ति को एक पैसा भी न देना चाहना sustainable नहीं है
      Work tools बनाने वालों को भी bills चुकाने होते हैं
      एक अर्थ में FOSS के सपने के fail होने में developers खुद भी जिम्मेदार हैं
      हम धीरे-धीरे public domain और shareware के दिनों की ओर लौट रहे हैं
    • “open-source code पर सिर्फ licensed builds देना” open source नहीं है

  • लोग हमेशा कहते रहे हैं कि open source से पैसे कमाने का मॉडल support services है। मसलन, अगर कोई कंपनी Postgres इस्तेमाल करती है, तो on-premises configuration में कोई expert मदद करता है और outages संभालता है।
    लेकिन “cloud” के दौर में कंपनियां बस Amazon, Microsoft, Google आदि की managed services इस्तेमाल कर लेती हैं, और project maintainers व उनके आसपास के लोगों के वित्तीय अवसर असल में खत्म हो जाते हैं। कोई भी यह नहीं देखना चाहता कि OSS पर जी-जान से मेहनत करने के बाद AWS बदले में कुछ भी न दे और लाखों डॉलर कमा ले।

    • खुलासा: मैं Amazon में काम करता/करती हूं, लेकिन Redis से जुड़ी cloud services में सीधे तौर पर शामिल नहीं हूं। मैं open source program office के करीब हूं, और open source projects में collaboration के लिए जरूरी कठिन काम करने वाले लोगों को बहुत अहम मानता/मानती हूं।
      Madelyn Olson ने AWS में employed रहते हुए कई वर्षों तक कठिन काम करके अन्य Redis core developers का भरोसा जीता और core maintainer बनीं। उन्होंने और अन्य AWS developers ने Redis core engine में काफी योगदान दिया है। यह कहना सही होगा कि उन्होंने भी Redis community के लिए मेहनत की है।
      संबंधित contributions के बारे में यहां और पढ़ा जा सकता है: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

  • और अधिक open source projects को SSPL अपनाना चाहिए, या Llama 2 की तरह free use के लिए कंपनी के आकार पर सीमा लगाने जैसे तरीकों के साथ प्रयोग करना चाहिए। यानी open source हो, लेकिन अरबों डॉलर वाली cloud hyperscaler कंपनियों पर लागू न हो।
    किसी individual developer ने योगदान देते समय यह इरादा नहीं रखा था कि AWS को free ride मिल सके।
    projects के ज्यादा restrictive licenses की ओर जाने की सबसे बड़ी वजह AWS है। AWS को जो सही काम करना चाहिए था, वह था original authors या company के काम का सम्मान करना और original developer द्वारा support किए गए products को मजबूती देना। इसके बजाय AWS जब किसी OSS product को सफल होते देखता है, तो competing product बना देता है। बेहतर integration और marketing power की वजह से third-party vendor के पास जीतने का मौका नहीं रहता।
    ऊपर से Amazon और AWS open source के बड़े, शायद सबसे बड़े beneficiaries हैं, फिर भी बहुत कम वापस देते हैं। Google, Microsoft, यहां तक कि Oracle भी Amazon की तुलना में open source में ज्यादा योगदान देते हैं।

    • SSPL और AGPL ठीक हैं, लेकिन शर्त यह है कि कोई CLA न हो जो मुझसे मेरे अधिकार किसी और को सौंपने को कहे।
      मैंने CLA वाले projects में कभी योगदान नहीं दिया है, और जब तक मेरा employer मुझे इसके लिए पैसे नहीं देता, आगे भी ऐसा करने का इरादा नहीं है।
    • पहले मैंने ऐसी FOSS license की वकालत की थी जो AI को code लिखने से रोके। इस पर काफी negative reaction मिला कि यह FOSS नहीं है, क्योंकि यह restrictions लगाती है। SSPL भी वैसा ही है।
      लेकिन लंबे समय तक FOSS की viability के लिए हमें उन बड़ी कंपनियों से खुद को बचाने के लिए restrictions की जरूरत पड़ सकती है, जो FOSS developers का practically exploitation करती हैं।
    • यह भी नहीं भूलना चाहिए कि कई OSS projects के popular होने की बड़ी वजहों में से एक AWS भी है।
      Redis, Mongo, ES, HashiCorp product suite, और पूरा big data ecosystem AWS की offerings के जरिए ज्यादा व्यापक रूप से पहचाने गए। ऐसे कई कम-ज्ञात databases भी हैं जो वर्षों से develop हुए हैं, लेकिन AWS या किसी अन्य बड़े cloud provider ने उन्हें push नहीं किया, इसलिए लोग अब भी उन्हें नहीं जानते।
      साथ ही, permissive license की वजह से usage और popularity बढ़ने पर कई projects को bug reports, PRs, patches जैसे contributions मिले। SSPL, BSL family licenses वाली चीजों में मैं ज्यादा contribute नहीं करना चाहता/चाहती, क्योंकि मैं ऐसी चीज पर समय बर्बाद नहीं करना चाहता/चाहती जिसे बाद में freely इस्तेमाल नहीं कर सकूंगा/सकूंगी।
    • यह बात भुलाई जा रही है कि Redis बड़ा ठीक इसलिए हुआ क्योंकि वह free और open था।
      अगर Redis शुरुआत से Llama 2 जैसी restrictions के साथ आया होता, तो वह शुरू में ही fail हो जाता। इसके मुख्य consumers enterprises हैं, और Llama 2 के लोकप्रिय होने की मुख्य वजह यह थी कि उसने शुरुआती दौर में individuals को personal use के लिए high-quality LLM उपलब्ध कराया।
      RESP-compatible key-value store कोई खास असाधारण चीज नहीं है। Microsoft ने भी अभी MIT license के तहत अपना implementation garnet जारी किया है। Redis की value हमेशा इस बात में थी कि वह free और open source था, और उस community में थी जिसने उसे sustain किया। अब Redis को इस्तेमाल करने की सबसे बड़ी वजह ही छोड़ दी गई है।
    • कुछ मामलों में AWS original developer पक्ष को support भी करता है। Managed Grafana और Prometheus में वह Grafana Labs के साथ collaborate करता है।
      लेकिन मेरी जानकारी में असल में बस यही case है, और MongoDB, Redis, Memcached, MySQL, PgSQL आदि लगभग हर दूसरे मामले में ऐसा नहीं है।

  • Redis Inc. https://github.com/redis/redis/ project को 3-clause BSD license से हटाकर दो ऐसे licenses की dual licensing में ले जा रही है जिन्हें OSI approval नहीं मिला है।
    पहले कहा गया था कि “Redis core license 3-Clause-BSD के तहत licensed है और आगे भी हमेशा ऐसा ही रहेगा।” (https://redis.com/blog/redis-labs-modules-license-changes/)

    • यह उन कंपनियों पर MBA CEOs के कब्जे का नतीजा है जिन्होंने open source project develop नहीं किया, बल्कि सिर्फ adopt किया

  • अगर support खत्म होने की चिंता है, तो Redis 7.4 नए license के तहत पहली release होगी और 7.2 पुराने license की आखिरी release होगी
    Redis किसी समय पर दो अतिरिक्त releases को support करता है: latest major.(minor-1), (major-1).(last-minor)
    मोटे तौर पर इसका मतलब है कि 8.0 आने पर 6.2 का support खत्म होगा, और 7.6 या 8.0 आने पर 7.2 का support खत्म होगा
    पिछले releases को देखते हुए, 8.0 के मार्च–मई 2025 के आसपास आने की उम्मीद है। इसलिए अगर आप 3BSD license के तहत Redis पर निर्भर हैं, तो उसी हिसाब से plan करना चाहिए
    Ubuntu, redis को universe repository में package करता है, इसलिए security upgrades केवल Ubuntu Pro customers को मिलते हैं। इसलिए Ubuntu 20.04 में, Ubuntu Pro के ESM users को छोड़कर, अप्रैल 2024 में redis upgrades रुक जाएंगे
    Debian 11/12 Redis 6.0/7.0 को follow करते हैं, इसलिए 7.2 के patches backport करने की जिम्मेदारी उनकी होगी। अगर 7.2 को security updates नहीं मिलते और वे सिर्फ 7.4 branch में दिए जाते हैं, तो यह कैसे होगा, यह साफ नहीं है
    आपका direct usage नए license के compatible हो तब भी आप indirect रूप से प्रभावित हो सकते हैं। संभावना है कि distributions अगली release में official repositories से redis को हटा दें, इसलिए अगले distribution upgrade cycle में इसे ध्यान में रखना होगा
    (मैं https://endoflife.date/redis maintain कर रहा हूं, इसलिए अगर किसी को support end और support पर इसके असर की स्पष्ट जानकारी है, तो PR merge किया जा सकता है)

  • नया license SSPL, कम से कम field-of-use restriction की वजह से, बहुत संभव है कि open source न हो: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

    • SSPL निश्चित रूप से open source नहीं है, और clause 6 का उल्लंघन करता है
      https://opensource.org/definition-annotated#6
      open source, और कुछ मायनों में free software, का core यही बात है। copyleft licenses में restrictions होते हैं, लेकिन अगर आप उन restrictions का पालन करते हैं तो उस software से जो चाहें बना सकते हैं। SSPL, FSL, BUSL licenses खास commercial तरीके से competition को पूरी तरह रोकते हैं
      ज्यादातर business models copyleft का पालन नहीं करना चाहते, इसका मतलब यह नहीं कि वह open source नहीं है। वह बस उस business model के लिए fit नहीं बैठता
    • “शायद” नहीं, यह साफ तौर पर non-free license है
    • मुझे लगता है कि ऐसी चीजों के लिए एक नए term की जरूरत है
      SSPL, BSL, FSL जैसे नए licenses तेजी से popular हो रहे हैं, और इसके अच्छे कारण भी हैं। 20 साल पहले AWS द्वारा FOSS को पूरी दुनिया में resell करने वाली स्थिति नहीं थी, इसलिए conditions आज से काफी अलग थीं
      restrictions की वजह से यह “open source” नहीं है, लेकिन अगला नजदीकी term “source-available” भी reality को ठीक से नहीं दिखाता। उसका मतलब ज्यादा ऐसा लगता है कि source code technically कहीं मौजूद भर है
      ElasticSearch, Sentry वगैरह अब भी publicly developed होते हैं, project से असंबंधित लोग भी PR भेज सकते हैं, और अगर आप project के पीछे वाली company से publicly compete करने की कोशिश नहीं कर रहे हैं तो कोई भी अपनी इच्छानुसार काम कर सकता है

  • इसी समय Microsoft ने Garnet publish किया: https://github.com/microsoft/garnet
    timing अच्छी है

    • Garnet से जुड़े HN discussion में किसी ने कहा था कि वे कभी MS से नहीं जुड़ेंगे
      उनका logic था कि MS bait देगा और जरूरत पड़ने पर license बदल देगा, इसलिए Redis बेहतर है क्योंकि वह हमेशा open source license बनाए रखेगा। क्या जबरदस्त prediction था
    • Microsoft और Azure इस बदलाव से पूरी तरह सहमत लगते हैं: https://azure.microsoft.com/en-us/blog/redis-license-update-...
    • जिज्ञासा है कि यह research product है या production environment के लिए है
    • समझ नहीं आता कि इतने महत्वपूर्ण software को C# या Java जैसी ऐसी languages में क्यों लिखा जाता है जिनके लिए पूरा runtime और VM install करना पड़ता है

  • लगता है Redis और Hashicorp के technical founders अपनी-अपनी companies के FOSS से दूर जाने और बड़े तूफान में फंसने से पहले हट गए। अगर timeline गलत नहीं है तो यही बात है
    जिज्ञासा है कि क्या उन्हें यह पहले से पता था और वे इसके खिलाफ थे, या पता था लेकिन reputation hit से बचना चाहते थे। आप इस move से सहमत हों या नहीं, reputation damage तो होता है। या क्या उनके जाने की वजह से ही बदलाव को आगे बढ़ाया जा सका
    यह पूरी तरह speculation है, लेकिन Hashi में जो देखा था वही Redis में भी दोहराता दिख रहा है, इसलिए ध्यान खींचता है

    • हो सकता है उनके जाने से पहले उनके पास इसे रोकने लायक influence था
      Hashi से समानता मुझसे भी छूटी नहीं
    • ज्यादा plausible यह है कि उन्होंने बस project या company को काफी लंबे समय तक चलाया था और वे किसी नए, ज्यादा interesting काम की ओर बढ़ना चाहते थे। या शायद वे बस cash out करना चाहते थे