मुक्त स्रोत सॉफ्टवेअरचा इतिहास आणि GPL ते SSPL प्रवास
Homebrew Computer Club पासून SSPL पर्यंत GPL, 1998 मधील rebrand आणि आजची relicensing लाट self-hosted अॅप्सच्या परवान्यांना कशी आकार देते, ते जाणून घ्या.
मुक्त स्रोत सॉफ्टवेअर म्हणजे काय आणि त्याची सुरुवात कुठून झाली
मुक्त स्रोत सॉफ्टवेअरचा इतिहास मुख्यतः त्याच्या परवान्यांचा इतिहास आहे, कारण दुसऱ्याने लिहिलेल्या कोडसोबत तुम्ही काय करू शकता हे ठरवणारी एकमेव गोष्ट म्हणजे परवाना. हे परवाने लिखित स्वरूपात येण्याच्या खूप आधीपासून कोड खुलेपणाने शेअर केला जात होता. कोड एक उत्पादन बनल्यानंतर तो शेअर करणे थांबले आणि न्यायालयात हे शेअरिंग टिकवून ठेवण्यासाठी परवाने तयार करण्यात आले.
ही त्याची संक्षिप्त रूपरेषा आहे. विस्तृत इतिहास महत्त्वाचा आहे, कारण आज तुम्ही सर्व्हरवर चालवत असलेल्या सॉफ्टवेअरवर त्या निर्णयांचे ठसे अजूनही दिसतात. त्यांपैकी काही निर्णय 1983 मध्ये घेण्यात आले. काही निर्णय गेल्या वर्षी घेण्यात आले आणि त्यामुळे आमच्या self-hosting मार्गदर्शिकांमधील काही अॅप्लिकेशन्स आता वेगवेगळ्या नावांच्या दोन आवृत्त्यांमध्ये उपलब्ध आहेत.
विकले जाण्यापूर्वी सॉफ्टवेअरची देवाणघेवाण केली जात होती
1950 आणि 1960 च्या दशकांत सॉफ्टवेअर मशीनसोबतच मिळत असे. IBM आपल्या सिस्टिम्ससोबत source code देत असे आणि 1955 मध्ये स्थापन झालेल्या SHARE सारखे user groups टेपवर प्रोग्रामची देवाणघेवाण करत असत. दोन घटनांमुळे ही पद्धत संपली. 1969 मध्ये IBM ने hardware पासून सॉफ्टवेअरची किंमत स्वतंत्रपणे आकारण्याची घोषणा केली. त्यामुळे सॉफ्टवेअरसाठी स्वतंत्र बाजारपेठ निर्माण झाली. त्यानंतर कायदाही बदलला. United States मधील Computer Software Copyright Act of 1980 ने प्रोग्राम हे copyright संरक्षणास पात्र लिखित कार्य असल्याचे स्पष्ट केले. 1980 नंतर तुम्ही लिहिलेले नसलेले code default ने बंदिस्त मानले जाऊ लागले. त्यामुळे ते share करण्यासाठी लेखकाची लिखित परवानगी आवश्यक झाली.
The Homebrew Computer Club आणि Hobbyists साठी खुले पत्र
The Homebrew Computer Club ची पहिली बैठक March 1975 मध्ये California मधील Menlo Park येथील एका garage मध्ये झाली. सदस्य hardware आणि paper tape घेऊन आले होते, आणि copying हा बैठकीचा एक भाग होता. Bill Gates आणि Paul Allen यांनी लिहिलेले Altair BASIC, copied tape वरून खोलीत फिरत होते. February 1976 मध्ये Gates यांनी club च्या newsletter मध्ये "An Open Letter to Hobbyists" या पत्राद्वारे उत्तर दिले.
बहुतेक hobbyists ना हे माहीत असले पाहिजे की, तुमच्यापैकी बहुतेक जण तुमचे software चोरतात.
त्यांनी लिहिले की दहा Altair मालकांपैकी एकापेक्षाही कमी जणांनी BASIC साठी पैसे दिले होते आणि ते लिहिण्यासाठी वापरलेला computer time 40,000 dollars पेक्षा अधिक किमतीचा होता. आधुनिक काळातील संपूर्ण वाद त्या पत्रात आधीच दिसतो. Software copy करण्यासाठी काहीही खर्च येत नाही आणि ते copy करणाऱ्या प्रत्येकाला त्याचा फायदा होतो. पण ते लिहिण्यासाठी अजूनही कोणाला तरी त्याच्या आयुष्यातील एक वर्ष खर्च करावे लागले. खाली वर्णन केलेला प्रत्येक licence या दोन्ही तथ्यांना एकाच वेळी उत्तर देण्याचा प्रयत्न आहे.
1983 मधील GNU आणि कायदेशीर संकल्पना म्हणून GPL
Richard Stallman यांनी सप्टेंबर 1983 मध्ये Usenet वर GNU ची घोषणा केली. वेबपूर्व काळात लोक वापरत असलेले newsgroup network म्हणजे Usenet. GNU चा अर्थ "GNU's Not Unix" असा आहे. कोणालाही प्रतिलिपी करून बदलता येईल अशी Unix-सुसंगत संपूर्ण प्रणाली तयार करण्याची योजना होती.
Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.
Free Software Foundation (FSF) ची स्थापना 1985 मध्ये झाली. तिच्या Free Software Definition मध्ये चार स्वातंत्र्ये दिली आहेत. त्यांची क्रमांकवारी शून्यापासून सुरू होते: कोणत्याही उद्देशासाठी प्रोग्राम चालवणे, त्याचा अभ्यास करून त्यात बदल करणे, त्याच्या प्रतिलिपींचे पुनर्वितरण करणे आणि बदललेल्या आवृत्त्यांचे वितरण करणे. Freedom 1 साठी source code आवश्यक असतो, कारण binary चा व्यावहारिक पद्धतीने अभ्यास करता येत नाही. येथे "Free" म्हणजे स्वातंत्र्य, किंमत नव्हे. FSF ची स्वतःची संज्ञा आहे: free as in free speech, not free beer.
नवीन संकल्पना manifesto नव्हती. ती licence होती. GNU General Public License (GPL) मध्ये copyright चा वापर वितरण रोखण्यासाठी नव्हे, तर वितरणासह sharing अनिवार्य करण्यासाठी केला जातो. तुम्हाला चारही स्वातंत्र्ये एका अटीवर मिळतात: तुम्ही software ज्याला देता, त्याला source code सहित तीच स्वातंत्र्ये मिळाली पाहिजेत. Stallman यांनी याला copyleft असे म्हटले. हे प्रथम 1985 मध्ये GNU Emacs सोबत release झाले. 1989 मध्ये ते GPL version 1 झाले आणि June 1991 मध्ये version 2 झाले.
GPL कार्य करते कारण ती copyright law वर आधारित आहे, त्याच्या विरोधात नाही. licence नसल्यास दुसऱ्याचा code वितरित करण्याचा अधिकार तुम्हाला मुळीच नसतो. GPL तो अधिकार देते आणि त्याला काही अटी जोडते. त्यामुळे एखादा vendor modified GPL code router मध्ये समाविष्ट करून source देण्यास नकार देत असेल, तर तो केवळ एखादे वचन मोडत नाही. तो copyright चे उल्लंघन करत असतो आणि copyright holder त्याच्याविरुद्ध न्यायालयात दावा दाखल करू शकतो. त्यामुळे enforcement शक्य होते. 2000s मधील Harald Welte यांच्या gpl-violations.org प्रकरणांपासून ते 2021 मध्ये दाखल झालेल्या Software Freedom Conservancy च्या Vizio विरुद्धच्या दाव्यापर्यंत ही बाब लागू होते. या दाव्यात असा युक्तिवाद आहे की television खरेदी केलेली व्यक्तीही source code ची मागणी करू शकते.
Linux ने प्रणाली पूर्ण केली
1991 पर्यंत GNU प्रकल्पाकडे compiler, C library, shell आणि बहुतेक tools उपलब्ध झाले होते. मात्र त्याच्याकडे कार्यरत kernel नव्हता, कारण GNU चा स्वतःचा kernel, Hurd, नियोजित वेळेपेक्षा बराच उशिरा विकसित होत होता. August 1991 मध्ये Helsinki येथील एका विद्यार्थ्याने comp.os.minix newsgroup वर लिहिले:
मी 386(486) AT clones साठी एक (free) operating system तयार करत आहे (हा फक्त छंद आहे; gnu सारखा मोठा आणि professional होणार नाही).
Linux 0.01 September 1991 मध्ये Linus Torvalds यांनी स्वतः लिहिलेल्या licence अंतर्गत उपलब्ध झाले. त्या licence नुसार त्याची विक्री करण्यास मनाई होती. 1992 च्या सुरुवातीला त्यांनी त्याऐवजी GPLv2 स्वीकारले. त्यानंतर त्यांनी सांगितले की हा त्यांच्या सर्वोत्तम निर्णयांपैकी एक होता. या licence मुळे कंपन्यांना योगदान देणे सुरक्षित झाले. एखादी कंपनी engineers ना kernel वर काम करण्यासाठी नियुक्त करू शकत होती, कारण एखादा competitor त्या सुधारणा private ठेवू शकत नव्हता.
Berkeley येथे free Unix आधीपासून उपलब्ध होता. Linux नव्हे तर BSD (Berkeley Software Distribution) default free Unix का बनले नाही, यामागे काही अंशी एक lawsuit कारणीभूत होता. Unix System Laboratories ने 1992 मध्ये Berkeley Software Design विरुद्ध दावा दाखल केला आणि हा खटला 1994 च्या सुरुवातीपर्यंत चालला. त्या दोन वर्षांत BSD systems वर कायदेशीर जोखीम होती, तर Linux वर कोणतीही जोखीम नव्हती. याच काळात users Linux कडे आले. Linux हे kernel आहे आणि त्याभोवतालची बहुतेक tools GNU ची आहेत, म्हणून FSF लोकांना संयुक्त system ला GNU/Linux म्हणण्याची विनंती करते. बहुतेक लोक Linux म्हणतात. दोन्ही नावे software च्या त्याच संग्रहाकडे निर्देश करतात.
1998: open source चे पुनर्ब्रँडिंग आणि कधीही भरून न आलेली फूट
जानेवारी 1998 मध्ये Netscape ने आपल्या browser चा source code प्रकाशित करण्याची घोषणा केली. असे करणारी ती त्या वेळची सर्वात मोठी कंपनी होती. त्यामुळे एक व्यावहारिक समस्या स्पष्ट झाली. "free software" या वाक्याचा इंग्रजीतील अर्थ "किंमत नसलेले software" असा घेतला जातो आणि executives ने नेमके हेच ऐकले. फेब्रुवारी 1998 मध्ये Palo Alto येथे एक गट अधिक योग्य संज्ञा शोधण्यासाठी भेटला. Christine Peterson यांनी "open source" ही संज्ञा सुचवली. काही आठवड्यांत Eric Raymond आणि Bruce Perens यांनी Open Source Initiative (OSI) स्थापन केली. Perens यांनी 1997 मध्ये लिहिलेल्या Debian Free Software Guidelines वर आधारित Open Source Definition स्वीकारण्यात आली.
Open Source Definition मध्ये दहा निकष आहेत. त्यांपैकी दोन निकष आधुनिक वादांमध्ये बहुतेक वेळा निर्णायक ठरतात: source उपलब्ध असला पाहिजे आणि licence ने program कोण वापरू शकतो किंवा तो कशासाठी वापरू शकतो यावर निर्बंध घालता कामा नयेत. "तुम्ही हे commercial service म्हणून देऊ शकत नाही" असे सांगणारे licence, इतर कोणत्याही परवानग्या देत असले तरी, ही चाचणी उत्तीर्ण होत नाही. हे वाक्य लक्षात ठेवा. आजची source-available licences हीच मर्यादा ओलांडतात.
1998 मध्ये सुरू झालेली फूट कोणती licences स्वीकारार्ह आहेत याबद्दल नाही. ती कारणांबद्दल आहे. FSF ची भूमिका नैतिक आहे: program बदलता येत नसेल, तर वापरकर्त्याचे स्वतःच्या computer वर नियंत्रण राहत नाही. Raymond यांच्या "The Cathedral and the Bazaar" या निबंधातून व्यवसाय क्षेत्रासमोर मांडलेली OSI ची भूमिका व्यावहारिक आहे: open development मुळे अधिक चांगले software तयार होते आणि कंपनी त्याचा व्यावहारिक उपयोग करू शकते. Stallman यांचा "Why Open Source Misses the Point of Free Software" हा प्रतिसाद अजूनही gnu.org वर प्रकाशित आहे आणि त्यांनी नवीन संज्ञा कधीही स्वीकारलेली नाही. ही संज्ञा तयार करण्यात मदत करणारे Perens यांनी 1999 मध्ये OSI board चा राजीनामा दिला. चळवळ free software पासून दूर गेली आहे, असे त्यांनी सांगितले.
व्यावहारिक फरक किती लहान आहे हे अचूकपणे समजून घेणे महत्त्वाचे आहे. FSF ची free licences ची यादी आणि OSI ची approved licences ची यादी जवळजवळ सर्व बाबतींत समान आहेत. यात GPL, MIT, Apache 2.0 आणि BSD यांचा समावेश आहे. दोन्ही अर्थ एकाच वेळी व्यक्त करण्याची गरज असलेले लेखक FOSS (free and open source software) किंवा FLOSS (free/libre and open source software) वापरतात.
कंपन्यांनी कोड वितरित करायला कसे शिकले
1999 मध्ये Red Hat चे stock market listing झाल्याने support आणि packaging मध्ये पैसा आहे, प्रती विकण्यात नाही, हे स्पष्ट झाले. 2001 मध्ये IBM ने Linux साठी एक अब्ज dollars देण्याची बांधिलकी जाहीर केली. 2001 मध्ये Microsoft च्या chief executive ने Linux ला “a cancer” म्हटले. त्याच कंपनीने 2016 मध्ये Linux Foundation चे platinum member म्हणून सदस्यत्व घेतले आणि 2018 मध्ये GitHub चे 7.5 billion dollars च्या stock व्यवहारात अधिग्रहण केले. 2019 मध्ये IBM ने Red Hat चे 34 billion dollars मध्ये अधिग्रहण केले. यापैकी कोणतीही घटना licences बाबत मतपरिवर्तन नव्हते. पैसा नेमका कुठे आहे, यामध्ये बदल झाला होता. Operating system हा सामायिक खर्च असल्यास स्वतःचे operating system maintain करणे महाग पडते. त्यामुळे प्रत्येक vendor त्यापेक्षा वरच्या layer वर स्पर्धा करणे पसंत करतो.
Corporate ownership चा परिणाम उलट दिशेनेही होतो. 2010 मध्ये Oracle ने Sun चे अधिग्रहण केले तेव्हा त्याला MySQL आणि OpenOffice.org मिळाले. दोन्ही समुदाय त्यातून वेगळे झाले. MySQL मधून MariaDB विकसित झाले. September 2010 मध्ये OpenOffice.org मधून LibreOffice fork करण्यात आले. User community कडे असलेले खरे मतदानाचे एकमेव साधन म्हणजे fork. Licence मुळेच ते मतदान शक्य होते.
तुम्ही self-host केलेल्या काही अॅप्सना आता forks का आहेत
2018 पासून काही कंपन्यांनी त्यांनी आधीच released केलेल्या software च्या अटी बदलल्या. प्रत्येक वेळी परिस्थिती सारखीच होती. एका कंपनीने जवळपास सर्व developers नोकरीवर ठेवले होते. त्याहून मोठ्या cloud provider ने तेच software managed service म्हणून विकले. त्या छोट्या कंपनीने licence मुळे ती स्पर्धा करू शकत नसल्याचे ठरवले.
- MongoDB ने October 2018 मध्ये Server Side Public License (SSPL) स्वीकारला. SSPL नुसार तुम्ही ते software इतरांना service म्हणून देत असाल, तर ती service देण्यासाठी वापरत असलेल्या सर्व गोष्टींचा source publish करणे आवश्यक असते. OSI ने तो open source म्हणून स्वीकारला नाही. MongoDB ने 2019 मध्ये तो review मधून मागे घेतला.
- Redis ने 2018 आणि 2019 मध्ये काही modules वर वापराच्या मर्यादा घातल्या. त्यानंतर March 2024 मध्ये version 7.4 पासून मुख्य server dual source-available अटींवर हलवला. शेवटच्या BSD-licensed release चा fork काही दिवसांत Valkey म्हणून उपलब्ध झाला. तो Linux Foundation अंतर्गत असून Amazon, Google आणि Oracle यांच्यासह इतर कंपन्यांनी त्याला पाठबळ दिले. May 2025 मध्ये Redis ने Redis 8 साठी तिसरा पर्याय म्हणून OSI-approved Affero General Public License version 3 (AGPLv3) जोडला.
- Elastic ने January 2021 मध्ये Elasticsearch आणि Kibana यांना Apache 2.0 मधून काढून dual SSPL आणि Elastic License अटींवर हलवले. Amazon ने OpenSearch fork केला. August 2024 मध्ये Elastic ने तिसरा पर्याय म्हणून AGPLv3 जोडला. September 2024 मध्ये OpenSearch ला Linux Foundation कडे OpenSearch Software Foundation म्हणून हस्तांतरित करण्यात आले.
- HashiCorp ने August 2023 मध्ये Terraform आणि आपल्या इतर tools ना Business Source License (BUSL) अंतर्गत हलवले. BUSL लागू असताना open source licence नाही, कारण ते competing production use ला मनाई करते. प्रत्येक release ठरलेल्या तारखेला open licence मध्ये रूपांतरित होते. Terraform साठी हे चार वर्षांनंतर होते. काही आठवड्यांत OpenTofu fork करण्यात आले. आता तेही Linux Foundation अंतर्गत आहे.
या दोन्ही बाजूंकडे ठोस युक्तिवाद आहे. कोणतीही बाजू गैरहेतूने वागत नाही. एखादी कंपनी पन्नास जणांचे वेतन देत असताना त्याहून मोठी कंपनी तिच्या कामाची पुन्हा विक्री करत असेल, तर goodwill मुळे सुटणार नाही अशी समस्या निर्माण होते. Apache 2.0 अटींवर software तयार करणाऱ्या वापरकर्त्याला नव्या अटी लागू झाल्याचे सकाळी समजणे हीदेखील समस्या आहे. आणि त्याला आधी कोणी विचारले नव्हते.
या प्रकरणांपैकी दोन प्रकरणांत पुढे काय झाले ते लक्षात घ्या. Forks स्थिरावल्यानंतर Elastic आणि Redis या दोघांनीही strong copyleft पुन्हा जोडले. Copyleft ने मूळ तक्रारीला उत्तर दिले, कारण AGPLv3 नुसार service provider ने तो चालवत असलेले बदल publish करणे आवश्यक असते. August 2026 पर्यंत दोन्ही projects आणि दोन्ही forks अद्याप active आहेत. Licences ज्या परिणामासाठी तयार करण्यात आल्या होत्या, तोच हा परिणाम आहे.
परवाना बदलण्याची परवानगी कोणाला आहे
एखाद्या प्रकल्पाच्या संपूर्ण कोडवरील कॉपीराइटचे नियंत्रण एका पक्षाकडे असेल, तरच त्या प्रकल्पाचा परवाना बदलता येतो. कंपन्यांना हे नियंत्रण दोनपैकी एका मार्गाने मिळते. कॉपीराइट assignment द्वारे प्रत्येक योगदानाची मालकी कंपनीकडे हस्तांतरित केली जाते. Contributor licence agreement (CLA) मध्ये मालकी तुमच्याकडेच राहते; मात्र तुमच्या कामाचा परवाना बदलण्यासाठी पुरेसे व्यापक अधिकार कंपनीला दिले जातात. यापैकी कोणत्याही प्रक्रियेसाठी सहसा तुमच्या पहिल्या pull request वर bot ने पोस्ट केलेल्या link वर click करून स्वाक्षरी केली जाते.
Linux कडे CLA नाही. योगदान GPLv2 अंतर्गत Developer Certificate of Origin सह येते आणि कॉपीराइट हजारो व्यक्ती व कंपन्यांमध्ये विभागलेला आहे. Linux चा परवाना कोणीही बदलू शकत नाही, कारण त्या सर्वांच्या स्वाक्षऱ्या एकत्र करणे कोणालाही शक्य होणार नाही. अनेक स्वतंत्र कॉपीराइटधारक असलेल्या कोणत्याही प्रकल्पाला हेच संरक्षण लागू होते. हे संरक्षण केवळ आश्वासनापेक्षा अधिक मजबूत आहे, कारण कोणाच्या मालकीचे काय आहे ही प्रत्यक्ष वस्तुस्थिती आहे.
म्हणून ज्या software वर तुम्ही अवलंबून राहण्याची योजना आखत आहात त्याबाबत विचारायचा प्रश्न असा नाही की ते आज open source आहे का. प्रश्न असा आहे की त्यात बदल कोण करू शकतो आणि तो बदल एकट्याने करू शकतो का.
फाउंडेशन प्रत्यक्षात काय देते
फाउंडेशन मालमत्ता सांभाळते आणि निर्णय कसे घेतले जातील याचे नियम निश्चित करते. Apache Software Foundation, Linux Foundation, तिच्या अंतर्गत असलेली Cloud Native Computing Foundation आणि Software Freedom Conservancy ही प्रत्येक संस्था हे काम काही प्रमाणात करते. फाउंडेशन आपोआप तटस्थ होत नाही. सदस्य त्यांच्या जागांसाठी शुल्क भरतात आणि मोठ्या फाउंडेशन प्रकल्पावर पूर्णवेळ काम करणाऱ्या बहुतेक लोकांना सदस्य कंपन्या वेतन देतात. त्यामुळे मिळणारा लाभ अधिक मर्यादित असला तरी महत्त्वाचा आहे: ट्रेडमार्क आणि release process एखाद्या एकाच vendor च्या मालकीचे नसतात. त्यामुळे कोणतीही एक कंपनी प्रकल्पाला private करू शकत नाही.
ट्रेडमार्क हा अनेकदा दुर्लक्षित राहणारा भाग आहे. Code ला licence असते. नाव हा ट्रेडमार्क असतो आणि ट्रेडमार्क code licence अंतर्गत येत नाही. तुम्ही code चा fork नेहमी करू शकता. मात्र नाव कायम ठेवता येत नाही. म्हणून या कथेतले forks Valkey, OpenSearch, OpenTofu आणि Forgejo या नावांनी ओळखले जातात.
देखभालकर्त्यांची समस्या
आधुनिक पायाभूत सुविधा एक किंवा दोन विनामोबदला देखभालकर्ते सांभाळत असलेल्या प्रकल्पांवर अवलंबून आहेत. या प्रकल्पांतील अपयशांमुळे ही बाब स्पष्ट होते. 2014 मधील OpenSSL मधील Heartbleed बगचा परिणाम वेबवरील मोठ्या प्रमाणातील encrypted traffic हाताळणाऱ्या library वर झाला. ती library जवळजवळ कोणतेही आर्थिक पाठबळ नसलेल्या मोजक्या लोकांकडून सांभाळली जात होती. डिसेंबर 2021 मधील Log4Shell मुळे जगभरातील incident response Apache Log4j प्रकल्पातील छोट्या volunteer team मार्फत करावा लागला.
मार्च 2024 मध्ये आढळलेला XZ Utils backdoor हे याचे सर्वात स्पष्ट उदाहरण आहे, कारण या हल्ल्याचे लक्ष्य code ऐवजी maintainer होता. एका account ने Linux distributions मध्ये मोठ्या प्रमाणावर वापरल्या जाणाऱ्या compression library मध्ये सुमारे दोन वर्षे खरोखर उपयुक्त योगदान दिले. इतर accounts ने थकलेल्या एकमेव maintainer वर मदत स्वीकारण्यासाठी दबाव आणला. त्यानंतरच्या co-maintainer ने release archives मध्ये backdoor स्थापित केला. हा backdoor अशा systems ला लक्ष्य करत होता ज्यांमध्ये SSH (secure shell) daemon ने liblzma शी link केलेले होते. अपेक्षेपेक्षा logins सुमारे अर्धा सेकंद उशिरा का होत आहेत, याची चौकशी करताना एका developer ला तो आढळला. हा योगायोग होता, असे या प्रकरणातील सर्व संबंधितांनी सार्वजनिकपणे सांगितले आहे.
आर्थिक मदत मिळण्यास सुरुवात झाली आहे: 2019 पासून GitHub Sponsors, Open Collective, 2022 पासून Germany's Sovereign Tech Fund आणि OpenSSF's Alpha-Omega project. ही मदत असमान प्रमाणात मिळते आणि आधीच प्रसिद्ध असलेल्या प्रकल्पांपर्यंतच ती पोहोचण्याची शक्यता जास्त असते. Regulation देखील लागू होऊ लागले आहे. European Union's Cyber Resilience Act डिसेंबर 2024 मध्ये लागू झाला. त्यातील बहुतेक कर्तव्ये डिसेंबर 2027 पासून लागू होतील. सुरुवातीच्या drafts मध्ये विनामोबदला volunteers वर manufacturer liability टाकण्याची तरतूद होती. त्यामुळे foundations आणि distributions यांनी दीर्घकाळ lobbying केल्यानंतर अंतिम मजकुरात "open source software steward" नावाची अधिक मर्यादित category तयार करण्यात आली.
ओपन सोर्सच्या इतिहासाचा तुमच्या VPS वरील सॉफ्टवेअरवर होणारा परिणाम
आमच्या self-hosting मार्गदर्शकांमधील प्रत्येक अॅप या निर्णयांनंतरच्या टप्प्यावर अस्तित्वात आहे. Nextcloud हे एका fork मुळे अस्तित्वात आले: 2016 मध्ये ownCloud चे संस्थापक आणि टीममधील मोठा भाग वेगळा झाला आणि AGPLv3 अंतर्गत प्रकल्प पुन्हा सुरू केला. तेव्हापासून ही दोन्ही उत्पादने समांतरपणे विकसित होत आहेत. हा इतिहास विचार करण्यासारखे Nextcloud पर्याय आणि दोन्ही उत्पादनांशी स्पर्धा करणारे self-hosted Dropbox पर्याय समजून घेण्यासाठी महत्त्वाचा आहे.
Git hosting मध्येही हीच पद्धत दिसते. Gitea ची सुरुवात 2016 मध्ये Gogs च्या fork म्हणून झाली. 2022 च्या अखेरीस प्रकल्पाचे trademark आणि domains एका कंपनीकडे हस्तांतरित झाले. त्याच वर्षी डिसेंबरमध्ये Codeberg ने Forgejo चा fork तयार केला. 2024 मध्ये version 9 पासून Forgejo ने MIT वरून GPLv3 कडे स्थलांतर केले. दोन्ही पर्यायांचा आढावा self-hosted Git server पर्याय येथे घेतला आहे. त्यांच्यातील licence मधील फरक हा ते सतत वेगळे का होत आहेत याचा मोठा भाग आहे. दरम्यान, बहुतांश free software हे Microsoft च्या मालकीच्या बंद platform GitHub वर विकसित केले जाते. या विषयावर दोन्ही बाजूंना ठोस मुद्दे असलेली जुनी चर्चा आहे: GitHub प्रत्यक्षात काय आहे हे पहा.
एखाद्या प्रकल्पासाठी server वापरण्याचा निर्णय घेण्यापूर्वी चार तपासण्या दहा मिनिटांत करता येतात.
- Marketing page ऐवजी repository मधील LICENSE file वाचा. त्या file मधील मजकूर बदलल्यानंतरही pages बराच काळ "open source" असे म्हणत राहतात.
- CLA किंवा copyright assignment आहे का ते तपासा. असे काही असल्यास, भविष्यातील releases च्या अटी एकच मालक बदलू शकतो.
- Copyright कोणाकडे आहे ते शोधा: एक कंपनी, अनेक contributors किंवा एखादी foundation.
- Active maintainers ची संख्या तपासा. फक्त एक maintainer असलेला प्रकल्प त्या व्यक्तीसाठीही आणि तुमच्यासाठीही जोखमीचा असतो.
याचा अर्थ single-vendor software टाळावे असा नाही. त्यातील बरेच software उत्कृष्ट असते. तसेच त्यासाठी पैसे मिळणे हे ते सातत्याने maintain केले जाण्याचे कारण असते. यामुळे तुम्ही कोणत्या गोष्टींच्या जोखमीला सामोरे जाता हे स्पष्ट होते. self-hosting करण्यास काय योग्य आहे हे ठरवताना memory requirement च्या शेजारी licence ची माहितीही तुलना करा.
तुमच्या समोर असलेल्या machine वर तुम्ही या इतिहासाचा काही भाग पाहू शकता. Debian किंवा Ubuntu system वरील प्रत्येक package स्वतःच्या अटींसह येते:
ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyrightपहिला आकडा म्हणजे installed packages पैकी किती packages मध्ये copyright file आहे हे दर्शवतो. लहान VPS वर हा आकडा सहसा काही शेकड्यांत असतो. दुसरी command bash साठी असलेल्या file चा सुरुवातीचा भाग दाखवते. त्यात GNU General Public License version 3 नमूद केलेले असते. File नसल्यास ते package Debian policy नुसार build केलेले नसण्याची शक्यता असते. असे क्वचितच घडते; त्यामुळे त्या package वर विश्वास ठेवण्यापूर्वी पुन्हा तपासणी करणे योग्य ठरते.
FAQ
मुक्त सॉफ्टवेअर आणि open source यांच्यात काय फरक आहे?
दोन्ही संज्ञा जवळपास त्याच प्रकारच्या परवान्यांना लागू होतात; फरक मुख्यतः त्या परवान्यांचे महत्त्व का आहे याबाबतच्या भूमिकेत आहे. "मुक्त सॉफ्टवेअर" ही जुनी संज्ञा आहे. ती 1985 मध्ये Free Software Foundation कडून आली आणि तिचा युक्तिवाद नैतिक आहे: वापरकर्ता प्रोग्राममध्ये बदल करू शकत नसेल, तर संगणकावर त्याचे नियंत्रण राहत नाही. "Open source" ही संज्ञा February 1998 मध्ये तयार करण्यात आली, जेणेकरून हेच परवाने कंपन्यांना समजावून सांगणे सोपे जावे; तिचा युक्तिवाद व्यावहारिक आहे. GPL, MIT, BSD आणि Apache 2.0 हे परवाने दोन्ही अधिकृत यादींमध्ये आहेत. दोन्हींचा एकत्रित अर्थ अभिप्रेत असल्यास लेखक FOSS किंवा FLOSS या संज्ञा वापरतात.
source-available सॉफ्टवेअर आणि open source एकच आहे का?
नाही. Source-available म्हणजे तुम्ही code वाचू शकता. Open Source Definition नुसार, open source परवान्याने सॉफ्टवेअर कोण वापरू शकतो किंवा ते कशासाठी वापरू शकतो यावर निर्बंध घालता येत नाहीत. SSPL आणि Business Source License हे दोन्ही स्पर्धात्मक व्यावसायिक वापरावर निर्बंध घालतात. त्यामुळे दोन्हींचा source प्रकाशित असला तरी त्या व्याख्येनुसार ते open source नाहीत. तुम्ही ते फक्त स्वतःसाठी self-host करत असाल, तर हा निर्बंध तुमच्यावर कदाचित लागू होणार नाही. त्यावर आधारित product तयार करायचा असल्यास, आधी परवान्याचा मजकूर काळजीपूर्वक वाचा.
एखाद्या कंपनीने आधीच दिलेला open source परवाना परत घेता येतो का?
कंपनीने आधीच released केलेल्या code साठी नाही. ती version ज्या परवान्याखाली releases करण्यात आली आहे, त्याच परवान्याखाली राहते. याच कारणामुळे Valkey आणि OpenTofu सारखे forks शेवटच्या permissively licensed commit पासून सुरू होऊ शकले. कंपनी भविष्यातील versions नवीन अटींखाली देऊ शकते. मात्र assignment किंवा contributor licence agreement द्वारे संपूर्ण project वरील copyright तिच्या नियंत्रणाखाली असल्यासच ती असे करू शकते. Linux सहित अनेक स्वतंत्र copyright holders असलेले projects कोणालाही relicensed करता येत नाहीत.
self-hosted सॉफ्टवेअरसाठी मी कोणता परवाना शोधावा?
तुम्ही स्वतः चालवत असलेल्या आणि पुन्हा विकत नसलेल्या सॉफ्टवेअरसाठी GPL, AGPL, MIT किंवा Apache 2.0 यांसारखा कोणताही OSI-approved परवाना आवश्यक सर्व अधिकार देतो. अधिक उपयुक्त तपासणी म्हणजे copyright कोणाकडे आहे हे पाहणे. कारण पुढे अटी तुमच्यावर लागू होतील अशा प्रकारे बदलता येतील का, हे त्यावर ठरते. Foundation किंवा अनेक स्वतंत्र contributors यांच्या नियंत्रणाखाली असलेला project त्याच्या users विरुद्ध relicensed करता येत नाही. Single-vendor project contributor licence agreement असल्यास relicensed करता येतो. दोन्ही चांगले software असू शकतात. मात्र नियम स्वतःहून बदलण्याची क्षमता फक्त एकाकडे असते.