FSL: बाज़ार के लिए एक लाइसेंस, कैथेड्रल के लिए नहीं
SaaS software के लिए एक नया “Functional Source License” (FSL) दो साल तक commercial competitors को रोकने का लक्ष्य रखता है, जबकि बाद में स्वचालित रूप से एक permissive open-source license पर स्विच करने का वादा करता है। समर्थक इसे development fund करने और बड़े cloud providers की “free-riding” प्रवृत्ति को सीमित करने का व्यावहारिक तरीका मानते हैं, साथ ही users को source access और long-term escape hatch भी देता है; आलोचकों का कहना है कि यह core free-software सिद्धांतों को कमजोर करता है, contributions और forking को जटिल बनाता है, और open source तथा source-available models के बीच की रेखा को धुंधला करता है। यह चर्चा timed license changes से जुड़ी legal और trust concerns को भी सामने लाती है और commercial SaaS businesses को बनाए रखने तथा unrestricted software freedom को संरक्षित रखने के बीच व्यापक तनाव को उजागर करती है.
FSL का दायरा और प्रकृति
- FSL को एक “source-available, eventually-open” लाइसेंस के रूप में देखा जाता है: कोड अभी एक non-compete प्रतिबंध के साथ उपयोग योग्य है, और दो साल बाद स्वतः Apache 2.0 बन जाता है।
- यह प्रतिबंध मुख्यतः प्रतिस्पर्धी SaaS पेशकशों को लक्षित करता है; गैर-व्यावसायिक और गैर-प्रतिस्पर्धी self-hosting की अनुमति है।
- कुछ लोग इसे SaaS के लिए “least-worst” मानते हैं: पूरी तरह proprietary या BUSL से बेहतर, लेकिन विशिष्टता अवधि के दौरान स्पष्ट रूप से FOSS नहीं।
Forks, “bazaar vs cathedral,” और contribution dynamics
- आलोचकों का तर्क है कि FSL संरचनात्मक रूप से cathedral जैसा है: एक विशेष पक्ष वाणिज्यिक उपयोग को नियंत्रित करता है; अर्थपूर्ण forks को दो साल पीछे रहना पड़ता है और मूल टीम की गति से मेल खाना पड़ता है।
- चिंता यह है कि “community” fork में security fixes और features हमेशा दो साल पीछे रहेंगे, जिससे वास्तविक प्रतिस्पर्धा या सुरक्षा कठिन हो जाएगी।
- अन्य लोग जवाब देते हैं कि forks फिर भी संभव हैं, खासकर यदि मुख्य project ठहर जाए, और यह भी नोट करते हैं कि कई open projects पहले से ही CLA या special contributor grants की माँग करते हैं।
कानूनी और व्यावहारिक चिंताएँ
- एक thread सवाल उठाता है कि क्या समय-विलंबित relicensing और automatic termination कुछ EU laws के तहत मान्य हैं; अन्य लोग जवाब देते हैं कि समय-आधारित grants आम हैं और terms पहले से ज्ञात होते हैं।
- उठाए गए edge cases: यदि भविष्य के license का संदर्भ (जैसे Apache) “गायब” हो जाए तो क्या होगा; प्रतिक्रियाएँ बताती हैं कि अदालतें संभवतः intent को मानेंगी और मौजूदा forks के पास वही license रहेगा जो उनके पास पहले से है।
- “competing use” और “exposing APIs” क्या माना जाए, इस अस्पष्टता के कारण कुछ लोग legal risk से सावधान रहते हैं।
व्यावसायिक मॉडल और “free-rider” बहस
- समर्थक FSL को cloud providers या resellers से सुरक्षा के रूप में देखते हैं जो product को hosted service के रूप में पुनर्पैक करते हैं लेकिन उसके विकास को funding नहीं देते।
- आलोचकों का कहना है कि software भौतिक commons की तरह “घिसता” नहीं है; “हानिकारक free-riding” असल में business-model की समस्या है, license की नहीं।
- कुछ का तर्क है कि open source स्वाभाविक रूप से commercial exploitation पर monopoly छोड़ देता है; यदि यह स्वीकार्य नहीं है, तो project को स्पष्ट रूप से proprietary होना चाहिए।
FOSS परिभाषाओं और messaging से संबंध
- बहुत से लोग जोर देते हैं कि FSL, FSF/OSI परिभाषाओं के अनुसार, field-of-use (no-competition) प्रतिबंधों के कारण Free/Open Source नहीं है।
- product को “open source” या “single-source open source” कहने वाली marketing के खिलाफ कड़ा विरोध है; कई लोगों को लगता है कि यह स्थापित terminology को धुंधला करती है।
- Sentry प्रतिनिधि स्वीकार करते हैं कि FSL expiry तक Open Source नहीं है, इसे “open source ideals” के अनुरूप बताते हैं, और कहते हैं कि कुछ सार्वजनिक शब्दावली संशोधित की जाएगी।
विकल्प और ecosystem पर प्रभाव
- कुछ लोग AGPL/GPL को सरल, स्थापित समाधान के रूप में सुझाते हैं; प्रतिवाद commercial environments में GPL stigma, app-store incompatibility, और कथित “viral” risk पर जोर देते हैं।
- कई commenters कहते हैं कि वे FSL के तहत योगदान नहीं करेंगे, क्योंकि freedom पर दो साल की देरी अस्वीकार्य है; अन्य लोग मुख्यतः debugging और self-hosting के लिए source की परवाह करते हैं, औपचारिक FOSS स्थिति की नहीं।