Open Source Software का इतिहास और विकास

ओपन सोर्स सॉफ्टवेयर क्या है और यह कहाँ से आया

ओपन सोर्स सॉफ्टवेयर का इतिहास मुख्य रूप से इसके लाइसेंस का इतिहास है, क्योंकि लाइसेंस ही वह एकमात्र चीज है जो यह तय करती है कि आप किसी और द्वारा लिखे गए कोड के साथ क्या कर सकते हैं। उन लाइसेंसों के लिखे जाने से बहुत पहले ही कोड को खुले तौर पर साझा किया जाता था। जब कोड एक उत्पाद बन गया, तो इसे साझा करना बंद हो गया, और उन लाइसेंसों को इसलिए लिखा गया ताकि कानूनी अदालतों में साझा करने की प्रक्रिया मान्य रहे।

यह संक्षिप्त विवरण है। विस्तृत विवरण महत्वपूर्ण है क्योंकि आज आप सर्वर पर जो सॉफ्टवेयर चलाते हैं, वह अभी भी उन निर्णयों के प्रभाव को दर्शाता है। उनमें से कुछ निर्णय 1983 में लिए गए थे। कुछ पिछले साल लिए गए थे, और यही कारण है कि हमारी self-hosting गाइड में मौजूद कुछ एप्लिकेशन अब अलग-अलग नामों वाले दो संस्करणों में आते हैं।

सॉफ्टवेयर को बेचे जाने से पहले साझा किया जाता था

1950 और 1960 के दशक में, सॉफ्टवेयर मशीन के साथ आता था। IBM अपने सिस्टम के साथ source code प्रदान करता था, और 1955 में स्थापित SHARE जैसे उपयोगकर्ता समूह टेप के माध्यम से प्रोग्रामों का आदान-प्रदान करते थे। दो चीजों ने इस चलन को समाप्त कर दिया। 1969 में IBM ने घोषणा की कि वह सॉफ्टवेयर की कीमत हार्डवेयर से अलग तय करेगा, जिससे सॉफ्टवेयर के लिए एक स्वतंत्र बाजार तैयार हुआ। इसके बाद कानून भी सक्रिय हो गया। 1980 के Computer Software Copyright Act ने यह पुष्टि की कि संयुक्त राज्य अमेरिका में प्रोग्राम कॉपीराइट योग्य कार्य हैं। 1980 के बाद, जो कोड आपने नहीं लिखा था, वह डिफ़ॉल्ट रूप से बंद (closed) हो गया, इसलिए उसे साझा करने के लिए लेखक से लिखित अनुमति की आवश्यकता होने लगी।

The Homebrew Computer Club और Hobbyists के लिए खुला पत्र

The Homebrew Computer Club ने अपनी पहली बैठक मार्च 1975 में Menlo Park, California के एक गैरेज में आयोजित की थी। सदस्य अपने साथ हार्डवेयर और पेपर टेप लाते थे, और सॉफ्टवेयर की कॉपी करना बैठक का एक हिस्सा था। Bill Gates और Paul Allen द्वारा लिखा गया Altair BASIC, कॉपी किए गए टेप के माध्यम से पूरे कमरे में घूमता था। फरवरी 1976 में Gates ने क्लब के न्यूज़लेटर में "An Open Letter to Hobbyists" के साथ जवाब दिया।

जैसा कि अधिकांश hobbyists जानते होंगे, आप में से अधिकतर लोग अपना सॉफ्टवेयर चुराते हैं।

उन्होंने लिखा कि दस में से एक से भी कम Altair मालिकों ने BASIC के लिए भुगतान किया था, और इसे लिखने में जो कंप्यूटर समय लगा, उसका मूल्य 40,000 dollars से अधिक था। आधुनिक बहस के सभी बिंदु पहले से ही उस पत्र में मौजूद हैं। सॉफ्टवेयर की कॉपी करने में कुछ खर्च नहीं होता और यह कॉपी करने वाले हर व्यक्ति की मदद करता है। लेकिन इसे लिखने में किसी के जीवन का एक साल खर्च हुआ है। नीचे वर्णित प्रत्येक licence इन दोनों तथ्यों का एक साथ समाधान खोजने का एक प्रयास है।

1983 में GNU और एक कानूनी आविष्कार के रूप में GPL

Richard Stallman ने सितंबर 1983 में Usenet पर GNU की घोषणा की। Usenet वह newsgroup नेटवर्क था जिसका उपयोग वेब से पहले लोग करते थे। GNU का अर्थ है "GNU's Not Unix"। योजना एक पूर्ण Unix-compatible सिस्टम बनाने की थी जिसे कोई भी कॉपी और बदल सके।

Free Unix! इस Thanksgiving से मैं एक पूर्ण Unix-compatible सॉफ्टवेयर सिस्टम लिखना शुरू कर रहा हूँ जिसे GNU (Gnu's Not Unix के लिए) कहा जाएगा, और इसे उन सभी को मुफ्त में दूँगा जो इसका उपयोग कर सकते हैं।

Free Software Foundation (FSF) की स्थापना 1985 में हुई। इसकी Free Software Definition में चार स्वतंत्रताएं सूचीबद्ध हैं, जिन्हें शून्य से गिना जाता है: प्रोग्राम को किसी भी उद्देश्य के लिए चलाना, उसका अध्ययन करना और उसे बदलना, उसकी प्रतियां पुनर्वितरित करना, और अपने बदले हुए संस्करणों को वितरित करना। स्वतंत्रता 1 के लिए source code की आवश्यकता होती है, क्योंकि कोई भी व्यक्ति binary का व्यावहारिक रूप से अध्ययन नहीं कर सकता है। यहाँ "Free" का अर्थ स्वतंत्रता है, न कि कीमत। FSF का अपना वाक्यांश है: free as in free speech, not free beer (स्वतंत्रता वैसी ही जैसे अभिव्यक्ति की स्वतंत्रता, न कि मुफ्त बीयर)।

घोषणापत्र आविष्कार नहीं था। लाइसेंस आविष्कार था। GNU General Public License (GPL) साझा करने की आवश्यकता के लिए copyright का उपयोग करता है, न कि इसे रोकने के लिए। आपको चार स्वतंत्रताएं एक शर्त पर मिलती हैं: जिसे भी आप सॉफ्टवेयर देते हैं, उसे भी ये स्वतंत्रताएं source के साथ मिलनी चाहिए। Stallman ने इसे copyleft कहा। यह सबसे पहले 1985 में GNU Emacs के साथ आया, 1989 में GPL version 1 बना, और जून 1991 में version 2 बना।

GPL इसलिए काम करता है क्योंकि यह copyright कानून पर आधारित है, उसके खिलाफ नहीं। लाइसेंस के बिना आपको किसी और के code को वितरित करने का कोई अधिकार नहीं है। GPL वह अधिकार प्रदान करता है और उस पर शर्तें लगाता है। इसलिए, जो vendor किसी router के अंदर modified GPL code डालता है और source देने से इनकार करता है, वह कोई वादा नहीं तोड़ रहा है। वे copyright का उल्लंघन कर रहे हैं, जिसे लेकर copyright धारक अदालत जा सकता है। यही कारण है कि प्रवर्तन संभव है, 2000 के दशक में Harald Welte के gpl-violations.org मामलों से लेकर 2021 में Software Freedom Conservancy द्वारा Vizio के खिलाफ दायर मुकदमे तक, जो यह तर्क देता है कि जिस व्यक्ति ने टेलीविजन खरीदा है, वह भी source की मांग कर सकता है।

Linux ने सिस्टम को पूरा किया

1991 तक GNU प्रोजेक्ट के पास compiler, C library, shell और अधिकांश tools मौजूद थे। उनके पास कोई कार्यशील kernel नहीं था, क्योंकि GNU का अपना kernel, Hurd, योजना से कहीं अधिक समय ले रहा था। अगस्त 1991 में हेलसिंकी के एक छात्र ने comp.os.minix newsgroup पर पोस्ट किया:

मैं 386(486) AT clones के लिए एक (free) operating system बना रहा हूँ (सिर्फ एक hobby है, यह gnu की तरह बड़ा और professional नहीं होगा)।

Linux 0.01 सितंबर 1991 में Linus Torvalds द्वारा स्वयं लिखे गए licence के तहत आया, जिसने इसे बेचने पर रोक लगा दी थी। उन्होंने 1992 की शुरुआत में इसे GPLv2 से बदल दिया और बाद में कहा कि यह उनके सबसे अच्छे निर्णयों में से एक था। इसी licence ने कॉर्पोरेट योगदान को सुरक्षित बनाया: कोई भी कंपनी अपने engineers को kernel पर काम करने के लिए लगा सकती थी, यह जानते हुए कि कोई competitor उन सुधारों को निजी नहीं बना सकता।

Berkeley में पहले से ही एक free Unix मौजूद था। Linux का न कि BSD (Berkeley Software Distribution) का default free Unix बनने का एक कारण कानूनी मुकदमा था। Unix System Laboratories ने 1992 में Berkeley Software Design पर मुकदमा दायर किया, और यह मामला 1994 की शुरुआत तक चला। उन दो वर्षों के दौरान BSD systems पर कानूनी जोखिम था जबकि Linux पर कोई नहीं था, और तभी users की संख्या बढ़ी। FSF लोगों से संयुक्त सिस्टम को GNU/Linux कहने का आग्रह करता है, क्योंकि Linux केवल kernel है और इसके आसपास के अधिकांश tools GNU के हैं। अधिकांश लोग इसे Linux कहते हैं। दोनों नाम software के उसी संग्रह की ओर संकेत करते हैं।

1998: ओपन सोर्स रीब्रांडिंग, और वह विभाजन जो कभी नहीं भरा

जनवरी 1998 में Netscape ने घोषणा की कि वह अपने ब्राउज़र का सोर्स कोड प्रकाशित करेगा। ऐसा करने वाली यह अब तक की सबसे बड़ी कंपनी थी, और इसने एक व्यावहारिक समस्या को उजागर किया। अंग्रेजी में "free software" वाक्यांश का अर्थ "वह सॉफ्टवेयर जो मुफ्त है" निकलता है, और अधिकारियों ने बिल्कुल यही समझा। फरवरी 1998 में पालो ऑल्टो में एक बेहतर शब्द खोजने के लिए एक समूह मिला, और Christine Peterson ने "open source" का प्रस्ताव रखा। कुछ ही हफ्तों के भीतर Eric Raymond और Bruce Perens ने Open Source Initiative (OSI) की स्थापना की। इसने Open Source Definition को अपनाया, जिसे 1997 में Perens द्वारा लिखे गए Debian Free Software Guidelines से अनुकूलित किया गया था।

Open Source Definition में दस मानदंड हैं। उनमें से दो अधिकांश आधुनिक तर्कों का निर्णय करते हैं: सोर्स उपलब्ध होना चाहिए, और लाइसेंस को यह प्रतिबंधित नहीं करना चाहिए कि प्रोग्राम का उपयोग कौन कर सकता है या वे इसका उपयोग किस लिए कर सकते हैं। एक लाइसेंस जो कहता है "आप इसे व्यावसायिक सेवा के रूप में पेश नहीं कर सकते" वह इस परीक्षण में विफल हो जाता है, चाहे वह कुछ भी अनुमति दे। उस वाक्य को याद रखें। यह वह रेखा है जिसे आज के source-available लाइसेंस पार करते हैं।

1998 में जो विभाजन शुरू हुआ वह कारणों के बारे में है, न कि इस बारे में कि कौन से लाइसेंस स्वीकार्य हैं। FSF का तर्क नैतिक है: एक उपयोगकर्ता जो प्रोग्राम को बदल नहीं सकता, वह अपने स्वयं के कंप्यूटर को नियंत्रित नहीं करता है। OSI का तर्क, जिसे Raymond के निबंध "The Cathedral and the Bazaar" द्वारा व्यवसायों के सामने रखा गया, व्यावहारिक है: ओपन डेवलपमेंट बेहतर सॉफ्टवेयर का उत्पादन करता है, और एक कंपनी उस पर कार्य कर सकती है। Stallman का उत्तर, "Why Open Source Misses the Point of Free Software", अभी भी gnu.org पर प्रकाशित है, और उन्होंने कभी भी नए शब्द को स्वीकार नहीं किया है। Perens, जिन्होंने इसे बनाने में मदद की थी, ने 1999 में OSI बोर्ड से इस्तीफा दे दिया और कहा कि आंदोलन फ्री सॉफ्टवेयर से दूर हो गया है।

यह सटीक होना उचित है कि व्यावहारिक अंतर कितना छोटा है। फ्री लाइसेंस की FSF की सूची और स्वीकृत लाइसेंस की OSI की सूची लगभग हर चीज पर सहमत है, जिसमें GPL, MIT, Apache 2.0 और BSD शामिल हैं। जो लेखक एक साथ दोनों अर्थों का उपयोग करना चाहते हैं, वे FOSS (free and open source software) या FLOSS (free/libre and open source software) का उपयोग करते हैं।

कंपनियों ने कोड शिप करना कैसे सीखा

1999 में Red Hat की स्टॉक मार्केट लिस्टिंग ने यह दिखाया कि सॉफ्टवेयर की प्रतियां बेचने के बजाय सपोर्ट और पैकेजिंग में पैसा है। IBM ने 2001 के लिए Linux में एक बिलियन डॉलर का निवेश करने का संकल्प लिया। 2001 में Microsoft के मुख्य कार्यकारी अधिकारी ने Linux को "कैंसर" कहा था, और उसी कंपनी ने 2016 में Linux Foundation को प्लेटिनम सदस्य के रूप में ज्वाइन किया, फिर 2018 में 7.5 बिलियन डॉलर के स्टॉक में GitHub को खरीद लिया। IBM ने 2019 में 34 बिलियन डॉलर में Red Hat को खरीदा। इनमें से कोई भी लाइसेंस के प्रति विचारों में बदलाव नहीं था। यह इस बात में बदलाव था कि पैसा कहाँ स्थित है। जब एक ऑपरेटिंग सिस्टम एक साझा लागत (shared cost) बन जाता है, तो अपने स्वयं के सिस्टम को बनाए रखने के लिए भुगतान करना महंगा होता है, और हर विक्रेता उसके ऊपर की लेयर पर प्रतिस्पर्धा करना पसंद करता है।

कॉर्पोरेट स्वामित्व का दूसरा पहलू भी है। जब Oracle ने 2010 में Sun को खरीदा, तो उसे MySQL और OpenOffice.org विरासत में मिले, और दोनों समुदाय वहां से चले गए। MariaDB का विकास MySQL से हुआ, और सितंबर 2010 में OpenOffice.org से LibreOffice को fork किया गया। एक fork ही वह एकमात्र वोट है जो एक उपयोगकर्ता समुदाय के पास वास्तव में होता है, और लाइसेंस ही वह चीज है जो उस वोट को संभव बनाती है।

कुछ self-hosted apps के forks क्यों मौजूद हैं

2018 के बाद से कंपनियों के एक समूह ने अपने द्वारा पहले ही release किए गए software की शर्तों में बदलाव किया। हर बार स्थिति एक जैसी थी। एक कंपनी ने लगभग सभी developers को नौकरी पर रखा था, एक बहुत बड़ी cloud provider ने उसी software को managed service के रूप में बेचा, और छोटी कंपनी ने यह तय किया कि इसकी वजह software का license है जिसके कारण वह प्रतिस्पर्धा नहीं कर पा रही है।

• MongoDB ने अक्टूबर 2018 में Server Side Public License (SSPL) अपनाया। SSPL के अनुसार यदि आप software को service के रूप में दूसरों को प्रदान करते हैं, तो आपको उस service को प्रदान करने के लिए उपयोग की जाने वाली हर चीज़ का source code प्रकाशित करना होगा। OSI ने इसे open source के रूप में स्वीकार नहीं किया, और MongoDB ने 2019 में इसे समीक्षा से वापस ले लिया।
• Redis ने 2018 और 2019 में कुछ modules पर उपयोग प्रतिबंध जोड़े, फिर मार्च 2024 में version 7.4 के साथ मुख्य server को dual source-available शर्तों पर स्थानांतरित कर दिया। अंतिम BSD-licensed release का एक fork कुछ दिनों बाद Valkey के रूप में सामने आया, जो Linux Foundation के अंतर्गत है और जिसे Amazon, Google और Oracle जैसे अन्य लोगों का समर्थन प्राप्त है। मई 2025 में Redis ने Redis 8 के लिए तीसरे विकल्प के रूप में Affero General Public License version 3 (AGPLv3) जोड़ा, जिसे OSI द्वारा अनुमोदित किया गया है।
• Elastic ने जनवरी 2021 में Elasticsearch और Kibana को Apache 2.0 से हटाकर dual SSPL और Elastic License शर्तों पर स्थानांतरित कर दिया। Amazon ने OpenSearch को fork किया। Elastic ने अगस्त 2024 में तीसरे विकल्प के रूप में AGPLv3 जोड़ा, और OpenSearch को सितंबर 2024 में Linux Foundation को OpenSearch Software Foundation के रूप में स्थानांतरित कर दिया गया।
• HashiCorp ने अगस्त 2023 में Terraform और अपने अन्य tools को Business Source License (BUSL) पर स्थानांतरित कर दिया। BUSL लागू रहने के दौरान open source license नहीं है, क्योंकि यह प्रतिस्पर्धी production उपयोग को प्रतिबंधित करता है। प्रत्येक release एक निश्चित तिथि पर open license में बदल जाता है, जो Terraform के लिए चार साल बाद है। OpenTofu को कुछ ही हफ्तों के भीतर fork कर लिया गया और अब यह भी Linux Foundation के अंतर्गत है।

इस मामले के दोनों पक्षों के पास ठोस तर्क हैं और कोई भी दुर्भावना से काम नहीं कर रहा है। एक कंपनी जो पचास लोगों का वेतन दे रही है, जबकि एक बहुत बड़ी फर्म उसके काम को फिर से बेच रही है, उसके सामने एक ऐसी समस्या है जिसे केवल goodwill से ठीक नहीं किया जा सकता। एक user जिसने Apache 2.0 शर्तों पर अपना infrastructure बनाया और अचानक नई शर्तों के तहत काम करने के लिए मजबूर हुआ, उसके सामने भी एक समस्या है, और किसी ने उनसे पहले नहीं पूछा। ध्यान दें कि उन मामलों में से दो में आगे क्या हुआ। Forks के स्थापित होने के बाद, Elastic और Redis दोनों ने वापस मजबूत copyleft को अपनाया। Copyleft ने मूल शिकायत का समाधान किया, क्योंकि AGPLv3 एक service provider को उन बदलावों को प्रकाशित करने के लिए बाध्य करता है जिन्हें वह चला रहा है। अगस्त 2026 तक दोनों projects और दोनों forks अभी भी सक्रिय हैं, जो कि वही परिणाम है जिसके लिए इन licenses को डिज़ाइन किया गया था।

लाइसेंस बदलने का अधिकार किसे है

किसी प्रोजेक्ट का लाइसेंस केवल तभी बदला जा सकता है जब कोई एक पक्ष उसके पूरे कॉपीराइट को नियंत्रित करता हो। कंपनियाँ यह नियंत्रण दो तरीकों में से किसी एक से प्राप्त करती हैं। कॉपीराइट असाइनमेंट (copyright assignment) हर योगदान का स्वामित्व कंपनी को सौंप देता है। एक कंट्रीब्यूटर लाइसेंस एग्रीमेंट (CLA) स्वामित्व आपके पास रहने देता है, लेकिन कंपनी को आपके काम को रीलाइसेंस करने के लिए पर्याप्त व्यापक अधिकार प्रदान करता है। इनमें से किसी भी एक पर आमतौर पर आपके पहले pull request पर एक बॉट द्वारा पोस्ट किए गए लिंक पर क्लिक करके हस्ताक्षर किए जाते हैं।

Linux का कोई CLA नहीं है। योगदान GPLv2 के तहत एक Developer Certificate of Origin के साथ आते हैं, और कॉपीराइट हजारों लोगों और कंपनियों में फैला हुआ है। कोई भी Linux को रीलाइसेंस नहीं कर सकता, क्योंकि कोई भी उन सभी हस्ताक्षरों को कभी इकट्ठा नहीं कर पाएगा। यही सुरक्षा कई स्वतंत्र कॉपीराइट धारकों वाले किसी भी प्रोजेक्ट पर लागू होती है, और यह किसी वादे की तुलना में एक मजबूत सुरक्षा है, क्योंकि यह इस तथ्य पर आधारित है कि किसका स्वामित्व किसके पास है।

इसलिए, जिस सॉफ्टवेयर पर आप निर्भर रहने की योजना बना रहे हैं, उसके बारे में पूछने वाला सवाल यह नहीं है कि क्या वह आज ओपन सोर्स है। बल्कि यह है कि इसे कौन बदल सकता है, और क्या वे इसे अकेले कर सकते हैं।

एक फाउंडेशन वास्तव में आपको क्या प्रदान करता है

एक फाउंडेशन संपत्ति को सुरक्षित रखता है और निर्णय लेने की प्रक्रिया के नियम निर्धारित करता है। Apache Software Foundation, Linux Foundation, इसके अंतर्गत आने वाली Cloud Native Computing Foundation, और Software Freedom Conservancy, प्रत्येक इस कार्य का अपना संस्करण पूरा करते हैं। कोई फाउंडेशन जादुई रूप से तटस्थ नहीं होता है। सदस्य अपनी सीटों के लिए भुगतान करते हैं, और किसी बड़े फाउंडेशन प्रोजेक्ट पर पूर्णकालिक काम करने वाले अधिकांश लोगों को सदस्य कंपनियों द्वारा वेतन दिया जाता है। आपको जो मिलता है वह सीमित है लेकिन फिर भी बहुत मूल्यवान है: ट्रेडमार्क और release process किसी एक वेंडर के पास नहीं होते हैं, इसलिए कोई भी एक कंपनी प्रोजेक्ट को निजी नहीं बना सकती है।

ट्रेडमार्क वह हिस्सा है जिसे लोग अक्सर नजरअंदाज कर देते हैं। कोड लाइसेंस प्राप्त होता है। नाम एक ट्रेडमार्क होता है, और ट्रेडमार्क कोड लाइसेंस के अंतर्गत नहीं आता है। आप हमेशा कोड को fork कर सकते हैं। आप आमतौर पर नाम को अपने पास नहीं रख सकते। यही कारण है कि इस कहानी में मौजूद forks को Valkey, OpenSearch, OpenTofu और Forgejo कहा जाता है।

मेंटेनर्स की समस्या

आधुनिक इंफ्रास्ट्रक्चर उन प्रोजेक्ट्स पर टिका है जिन्हें एक या दो अवैतनिक मेंटेनर्स संभालते हैं, और इनकी विफलताएं ही इस वास्तविकता को उजागर करती हैं। 2014 में OpenSSL में आया Heartbleed बग एक ऐसी लाइब्रेरी में था जो वेब के एन्क्रिप्टेड ट्रैफिक का एक बड़ा हिस्सा संभालती थी, और इसे लगभग बिना किसी फंड के मुट्ठी भर लोग मेंटेन कर रहे थे। दिसंबर 2021 में Log4Shell ने दुनिया भर की इंसिडेंट रिस्पॉन्स प्रक्रिया को Apache Log4j प्रोजेक्ट की एक छोटी स्वयंसेवी टीम के भरोसे डाल दिया था।

मार्च 2024 में मिला XZ Utils बैकडोर इसका सबसे सटीक उदाहरण है, क्योंकि इस हमले ने कोड के बजाय मेंटेनर को निशाना बनाया। एक अकाउंट ने लगभग दो साल तक Linux डिस्ट्रिब्यूशन्स में इस्तेमाल होने वाली एक कम्प्रेशन लाइब्रेरी में वास्तव में उपयोगी योगदान दिया। अन्य अकाउंट्स ने थके हुए एकमात्र मेंटेनर पर मदद स्वीकार करने का दबाव बनाया। नए को-मेंटेनर ने फिर रिलीज़ आर्काइव्स में एक बैकडोर डाल दिया, जिसका लक्ष्य वे सिस्टम थे जहाँ SSH (secure shell) डेमन liblzma के साथ लिंक होता है। एक डेवलपर ने इसे तब खोजा जब वह यह जांच रहा था कि लॉगिन में उम्मीद से लगभग आधा सेकंड अधिक समय क्यों लग रहा है। यह केवल किस्मत थी, और इसमें शामिल सभी लोगों ने सार्वजनिक रूप से यह स्वीकार किया है।

पैसा आना शुरू हो गया है: 2019 से GitHub Sponsors, Open Collective, 2022 से जर्मनी का Sovereign Tech Fund, और OpenSSF का Alpha-Omega प्रोजेक्ट। यह पैसा असमान रूप से आता है, और यह अक्सर उन्हीं प्रोजेक्ट्स तक पहुँचता है जो पहले से ही प्रसिद्ध हैं। नियमन भी आ रहा है। यूरोपीय संघ का Cyber Resilience Act दिसंबर 2024 में लागू हुआ, जिसके अधिकांश कर्तव्य दिसंबर 2027 से प्रभावी होंगे। शुरुआती ड्राफ्ट में अवैतनिक स्वयंसेवकों पर निर्माता की जवाबदेही थोपी जा सकती थी, इसलिए फाउंडेशन्स और डिस्ट्रिब्यूशन्स द्वारा लंबी लॉबिंग के बाद अंतिम टेक्स्ट में "ओपन सोर्स सॉफ्टवेयर स्टीवर्ड" नामक एक हल्की श्रेणी बनाई गई है।

ओपन सोर्स का इतिहास आपके VPS पर मौजूद सॉफ्टवेयर के लिए क्या मायने रखता है

हमारे self-hosting गाइड्स में मौजूद हर application इन निर्णयों के परिणाम स्वरूप है। Nextcloud एक fork के कारण अस्तित्व में आया: 2016 में ownCloud के संस्थापक और उनकी टीम का एक बड़ा हिस्सा अलग हो गया और उन्होंने AGPLv3 के तहत प्रोजेक्ट को फिर से शुरू किया, और तब से ये दोनों प्रोडक्ट्स समानांतर चल रहे हैं। यह इतिहास Nextcloud के विचारणीय विकल्पों और self-hosted Dropbox विकल्पों की पृष्ठभूमि है, जो उन दोनों के साथ प्रतिस्पर्धा करते हैं।

यही पैटर्न Git होस्टिंग में भी दिखाई देता है। Gitea की शुरुआत 2016 में Gogs के एक fork के रूप में हुई थी। 2022 के अंत में प्रोजेक्ट का ट्रेडमार्क और डोमेन एक कंपनी के पास चले गए, जिसके बाद दिसंबर में Codeberg ने Forgejo को fork किया, और 2024 में version 9 के साथ Forgejo MIT से GPLv3 पर स्थानांतरित हो गया। दोनों को self-hosted Git सर्वर विकल्पों में कवर किया गया है, और लाइसेंस का अंतर ही उनके लगातार अलग होने का एक बड़ा कारण है। इस बीच, अधिकांश free software को Microsoft के स्वामित्व वाले एक बंद प्लेटफॉर्म, GitHub पर विकसित किया जाता है, जो एक पुरानी बहस है जिसके दोनों पक्षों के अपने तर्क हैं: देखें GitHub वास्तव में क्या है।

किसी प्रोजेक्ट के लिए सर्वर समर्पित करने से पहले, चार जाँचें करना दस मिनट के समय के लायक है।

• रिपॉजिटरी में LICENSE फाइल पढ़ें, न कि मार्केटिंग पेज। फाइल के शर्तों से सहमत न होने के काफी समय बाद तक भी पेज "open source" होने का दावा करते रहते हैं।
• CLA या copyright assignment की तलाश करें। यदि ऐसा कोई प्रावधान है, तो एक अकेला मालिक भविष्य के releases की शर्तों को बदल सकता है।
• पता लगाएँ कि copyright किसके पास है: एक कंपनी, कई contributors, या कोई फाउंडेशन।
• सक्रिय maintainers की संख्या गिनें। एक maintainer वाला प्रोजेक्ट उस व्यक्ति के लिए उतना ही जोखिम भरा है जितना कि आपके लिए।

इसका मतलब यह नहीं है कि single-vendor सॉफ्टवेयर से बचें। इनमें से कई बेहतरीन होते हैं, और भुगतान मिलना ही अक्सर उनके मेंटेनेंस का कारण होता है। यह आपको बताता है कि आप किन जोखिमों के प्रति संवेदनशील हैं। जब आप निर्णय ले रहे हों कि क्या self-host करने योग्य है, तो लाइसेंस को memory requirement के साथ तुलना में रखें।

आप इस इतिहास का कुछ हिस्सा अपने सामने मौजूद मशीन पर पढ़ सकते हैं। Debian या Ubuntu सिस्टम पर हर package अपनी शर्तें साथ लाता है:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

पहली संख्या यह दर्शाती है कि कितने installed packages में copyright फाइल है, जो आमतौर पर एक छोटे VPS पर कुछ सौ होती है। दूसरी कमांड bash के लिए फाइल का शुरुआती हिस्सा प्रिंट करती है, जिसमें GNU General Public License version 3 का उल्लेख है। फाइल का न होना यह दर्शाता है कि package को Debian policy के अनुसार नहीं बनाया गया है, जो कि दुर्लभ है और उस पर भरोसा करने से पहले दोबारा जाँच करना उचित है।

FAQ

Free software और open source में क्या अंतर है?

ये लगभग एक ही तरह के लाइसेंसों को कवर करते हैं, लेकिन इस बात पर असहमत हैं कि ये लाइसेंस क्यों महत्वपूर्ण हैं। "Free software" पुराना शब्द है, जो 1985 में Free Software Foundation द्वारा दिया गया था, और इसका तर्क नैतिक है: जो उपयोगकर्ता प्रोग्राम को बदल नहीं सकता, वह कंप्यूटर को नियंत्रित नहीं करता है। "Open source" शब्द फरवरी 1998 में बनाया गया था ताकि कंपनियों को उन्हीं लाइसेंसों को समझाना आसान हो सके, और इसका तर्क व्यावहारिक है। GPL, MIT, BSD और Apache 2.0 लाइसेंस दोनों आधिकारिक सूचियों में शामिल हैं। जो लेखक दोनों का एक साथ उल्लेख करना चाहते हैं, वे FOSS या FLOSS का उपयोग करते हैं।

क्या source-available software और open source एक ही हैं?

नहीं। Source-available का अर्थ है कि आप कोड पढ़ सकते हैं। Open Source Definition के तहत, open source का अर्थ यह भी है कि लाइसेंस यह प्रतिबंधित नहीं कर सकता कि सॉफ्टवेयर का उपयोग कौन करता है या वे इसका उपयोग किस लिए करते हैं। SSPL और Business Source License दोनों प्रतिस्पर्धी व्यावसायिक उपयोग को प्रतिबंधित करते हैं, इसलिए उस परिभाषा के अनुसार कोई भी open source नहीं है, भले ही दोनों अपना सोर्स कोड प्रकाशित करते हों। यदि आप केवल अपने लिए self-host करते हैं, तो प्रतिबंध शायद आपको कभी प्रभावित न करे। यदि आप इसके ऊपर कोई उत्पाद बनाना चाहते हैं, तो पहले लाइसेंस टेक्स्ट को ध्यान से पढ़ें।

क्या कोई कंपनी पहले से दिया गया open source लाइसेंस वापस ले सकती है?

उस कोड के लिए नहीं जिसे वह पहले ही जारी कर चुकी है। वह संस्करण उसी लाइसेंस के तहत रहता है जिसके साथ उसे ship किया गया था, और यही कारण है कि Valkey और OpenTofu जैसे forks अंतिम permissively licensed commit से शुरू हो सके। कंपनी जो कर सकती है वह यह है कि भविष्य के संस्करणों को नई शर्तों के तहत रखे, और वह ऐसा तभी कर सकती है यदि वह assignment या contributor licence agreement के माध्यम से पूरे प्रोजेक्ट पर कॉपीराइट को नियंत्रित करती हो। Linux सहित कई स्वतंत्र कॉपीराइट धारकों वाले प्रोजेक्ट्स को कोई भी relicense नहीं कर सकता है।

self-hosted software में मुझे कौन सा लाइसेंस देखना चाहिए?

ऐसे सॉफ्टवेयर के लिए जिसे आप स्वयं चलाते हैं और दोबारा नहीं बेचते हैं, GPL, AGPL, MIT या Apache 2.0 जैसा कोई भी OSI-approved लाइसेंस आपको वह सब कुछ देता है जिसकी आपको आवश्यकता है। अधिक उपयोगी जाँच यह है कि कॉपीराइट किसके पास है, क्योंकि यह तय करता है कि बाद में शर्तें बदल सकती हैं या नहीं। किसी फाउंडेशन या कई स्वतंत्र योगदानकर्ताओं द्वारा संचालित प्रोजेक्ट को उसके उपयोगकर्ताओं के विरुद्ध relicense नहीं किया जा सकता है। contributor licence agreement वाले single-vendor प्रोजेक्ट को relicense किया जा सकता है। दोनों अच्छे सॉफ्टवेयर हो सकते हैं। केवल उनमें से एक ही अपने दम पर नियम बदल सकता है।