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

मूल लेख ↗ Hacker News चर्चा ↗

Redis में क्या बदला

  • Core Redis 3-क्लॉज BSD से डुअल लाइसेंसिंग पर चला गया:
    • स्रोत के लिए SSPLv1 (copyleft, OSI-स्वीकृत नहीं)।
    • “source-available” उपयोग के लिए RSALv2, जो “competitive offerings” (जैसे Redis-as-a-service) को प्रतिबंधित करता है।
  • ब्लॉग और FAQ इस पर ज़ोर देते हैं:
    • Self-hosted / आंतरिक उपयोग मुफ़्त बना रहता है।
    • Managed service providers को या तो SSPL का पालन करना होगा (अपना पूरा service stack open करना होगा) या commercial deals साइन करने होंगे।

यूज़र्स और distributions पर असर

  • अधिकांश टिप्पणीकारों का मानना है:
    • Redis को dependency के रूप में इस्तेमाल करने वाले सामान्य app developers कानूनी रूप से प्रभावित नहीं होंगे।
    • Redis-जैसी सेवाएँ देने वाले SaaS/DBaaS products को काफ़ी कानूनी/operational risk का सामना करना पड़ेगा।
  • कई लोगों को उम्मीद है:
    • Linux distros (Debian, Fedora, आदि) Redis को drop करेंगी या non-free repos में शिफ्ट करेंगी, जैसा MongoDB के साथ हुआ था।
    • Users अधिकतर vendor images/containers के माध्यम से install करेंगे या forks/alternatives की ओर जाएंगे।
  • कुछ लोग आख़िरी BSD-licensed releases और उनके backports के long-term security updates को लेकर चिंतित हैं।

Trust, governance, और contributor प्रतिक्रियाएँ

  • कई लोगों को यह “bait-and-switch” लगता है:
    • पहले दिए गए सार्वजनिक आश्वासन कि core BSD ही रहेगा और governance “community-led” होगी, अचानक relicensing और governance page हटाए जाने से टकराते हैं।
    • नया mandatory CLA Redis को भविष्य के contributions को relicense करने देता है; कुछ contributors कहते हैं कि वे अब योगदान नहीं देंगे।
  • अन्य लोग तर्क देते हैं:
    • BSD ने स्पष्ट रूप से इसकी अनुमति दी थी; contributors को जोखिम समझना चाहिए था।
    • यह project हमेशा उस company से काफ़ी प्रभावित था जिसने trademark खरीदा था।

Forks और alternatives

  • कई forks और alternatives पर चर्चा हुई:
    • बदलाव से पहले के commit पर frozen BSD fork।
    • Codeberg पर work-in-progress community fork (“redict”)।
    • Drop-in या protocol-compatible विकल्प: KeyDB (MIT/BSL history), Dragonfly (BSL), Microsoft Garnet (MIT), Memcached, और विभिन्न Redis-protocol backends (जैसे kvrocks)।
  • बहुत से लोग उम्मीद करते हैं कि cloud vendors और ex-core devs द्वारा समर्थित एक मज़बूत fork de facto “open Redis” बन जाएगा, और इसके लिए MariaDB, OpenSearch, और OpenTofu के precedents का हवाला देते हैं; अन्य लोग नोट करते हैं कि हर fork सफल नहीं होता।

Cloud providers और fairness

  • एक पक्ष:
    • SSPL/RSAL को “mega-corp cloud leeches” द्वारा Redis को थोड़े या बिना financial support के resell करने के विरुद्ध उचित रक्षा मानता है।
    • तर्क देता है कि sustainable OSS businesses को hosting revenue का कुछ हिस्सा capture करना चाहिए।
  • दूसरा पक्ष:
    • जवाब देता है कि बड़े clouds code और engineers का योगदान करते हैं, और BSD द्वारा दी गई freedoms के भीतर काम करते हैं।
    • तर्क देता है कि असली विफलता venture-backed “sell support/hosting” models की है, OSS की नहीं।

Licensing philosophy और OSI debate

  • व्यापक सहमति है कि Redis अब OSI definition के तहत open source नहीं है; यह “source available” है।
  • विवाद:
    • कुछ लोग SSPL को “more truly copyleft” और free-software goals के अनुरूप मानते हैं (पूरी services को open करने के लिए मजबूर करना)।
    • अन्य कहते हैं कि SSPL असंभव दायित्व थोपता है (जैसे, सभी “hosting software”) और व्यवहार में एक field-of-use restriction है।
  • thread में इन बातों के बीच confusion दिखता है:
    • “Permissive” बनाम “copyleft”.
    • “Open source” बनाम “source-available”.
    • “Free as in beer” बनाम “free as in freedom”.

FOSS businesses की sustainability

  • बार-बार उभरने वाले विषय:
    • Open core और hosted services cloud competition के तहत अक्सर असफल रहे हैं; license tightening (Redis, HashiCorp, Elastic, MongoDB) को एक “rights ratchet” की तरह देखा जा रहा है।
    • Foundations को कोई जादुई समाधान नहीं माना जाता, लेकिन Postgres, Kubernetes, Linux जैसे उदाहरणों के साथ उन्हें VC-backed companies की तुलना में अधिक स्थिर long-term stewards बताया जाता है।
  • सुझाए गए alternatives:
    • शुरुआत से AGPL का उपयोग करें।
    • Core को किसी neutral foundation के अधीन रखें; proprietary extensions या SaaS layers से monetization करें।
    • Direct funding और major users के in-house contributors को सामान्य बनाएं।
  • भविष्य पर राय अलग-अलग है:
    • कुछ लोग FOSS से वापस proprietary/shareware की ओर retreat की भविष्यवाणी करते हैं।
    • अन्य मानते हैं कि यह episode earlier forks और अधिक सावधानी से चुने गए licenses को प्रोत्साहित करेगा, न कि बड़े पैमाने पर open source का अंत करेगा।