GPL विरुद्ध MIT विरुद्ध Apache: परवाना इतिहास

GPL विरुद्ध MIT विरुद्ध Apache: प्रत्येक परवाना तुमच्याकडून काय अपेक्षित करतो

GPL, MIT आणि Apache 2.0 हे एकाच प्रश्नाचे वेगवेगळ्या प्रकारे उत्तर देतात: तुम्ही सॉफ्टवेअर इतरांना वितरित करता तेव्हा त्यांच्याप्रती तुमची काय जबाबदारी असते? MIT परवान्यासाठी copyright notice देणे पुरेसे असते. Apache 2.0 मध्ये त्या notice सोबत code शी संबंधित प्रत्येक व्यक्तीमधील patent संबंधी तरतूद असते. GPL नुसार, तुम्ही त्यावर आधारित तयार केलेल्या सॉफ्टवेअरचा source code तुम्हाला मिळालेल्या त्याच परवान्याखाली प्रकाशित करणे आवश्यक असते.

प्रकल्पाचा licence बदलून तो दोन भागांत विभागला जात नाही, तोपर्यंत हा कायदेशीर तज्ज्ञांसाठीचा प्रश्न वाटू शकतो. त्यानंतर तो operations शी संबंधित प्रश्न बनतो. तुमच्यासमोर निवडण्यासाठी दोन package repositories असतात आणि client libraries एकमेकांशी संवाद साधणे थांबवतात. हा मार्गदर्शक परवान्यांबद्दल आणि त्यांच्या कार्यपद्धतीबद्दल आहे; ते निर्माण करणाऱ्या चळवळीबद्दल नाही. त्यामुळे प्रत्येक विभागाचा शेवट त्या ठिकाणी होतो जिथे त्याचा तुमच्यावर परिणाम होतो: upgrade चालवणाऱ्या व्यक्तीवर.

GPL का अस्तित्व का कारण: ज्याला कोणीही दुरुस्त करू शकत नव्हते असा printer

सुमारे 1980 मध्ये MIT Artificial Intelligence Lab ला Xerox 9700 laser printer मिळाला. प्रयोगशाळेने त्यापूर्वीच्या printer साठी software मध्ये बदल केले होते, त्यामुळे तुमचे काम अडकले की printer तुम्हाला कळवत असे. नवीन printer साठी source code उपलब्ध नव्हता. nondisclosure agreement मुळे तो देण्याची विनंती नाकारण्यात आली. त्या वेळी प्रयोगशाळेत programmer असलेल्या Richard Stallman यांनी हा प्रसंग केवळ एक अपवाद न मानता सर्वसाधारण समस्या मानली आणि 27 September 1983 रोजी GNU project जाहीर केला.

Copyleft हे copyright law वर आधारित आहे; ते त्याच्या विरोधात नाही. Default नुसार दुसऱ्याचा code copy करण्याचा अधिकार तुम्हाला मुळीच नसतो. GPL हा अधिकार एका अटीवर देते: तुम्ही program दुसऱ्याला दिल्यास, त्याला त्याच अटींनुसार source द्यावा लागतो, जेणेकरून प्रयोगशाळेला करता आले नाही ते तो करू शकेल. ही अट अंमलात आणता येते, कारण licence शिवाय तुम्हाला सुरुवातीपासूनच कोणतीही परवानगी नव्हती.

Stallman यांनी प्रथम GNU Emacs साठी licence लिहिले. त्यानंतर 25 February 1989 रोजी त्याचे सामान्यीकरण करून GPL version 1 तयार केली. GPL version 2 June 1991 मध्ये आली आणि तुम्ही चालवत असलेल्या बहुतेक system software साठी आजही तीच licence आहे. Libraries साठी Lesser GPL आली. त्यामुळे copyleft library कोणत्याही licence अंतर्गत असलेल्या program शी link करता येते आणि तो program GPL अंतर्गत आणण्याची गरज पडत नाही.

GPL self-hoster वर कसा परिणाम करते हे एका मुद्द्यावर ठरते. ही obligation use वर नव्हे, तर distribution वर लागू होते. तुम्ही GPL program मध्ये बदल करून तो तुमच्या स्वतःच्या server वर चालवू शकता आणि त्याद्वारे public ला सेवा देऊ शकता. तुम्ही त्याची copy कोणालाही दिलेली नसल्यामुळे तुम्हाला कोणालाही काहीही देणे लागत नाही. या उणीवेमुळे AGPL अस्तित्वात आली.

मोकळी परवान्यांची परंपरा: BSD, त्यानंतर MIT

Berkeley ने वेगळा मार्ग स्वीकारला. Computer Systems Research Group ने आपले Unix काम अशा परवान्याखाली प्रकाशित केले, ज्यामध्ये copyright notice कायम ठेवण्याची अट होती आणि कोणतीही warranty नाकारण्यात आली होती. मूळ आवृत्तीत चार clauses होत्या. चौथ्या clause नुसार, software च्या वैशिष्ट्यांचा उल्लेख करणाऱ्या प्रत्येक जाहिरात सामग्रीमध्ये University चे acknowledgement देणे आवश्यक होते. ही अट मोठ्या प्रमाणावर लागू करणे शक्य नव्हते. NetBSD च्या 1997 मधील एका आवृत्तीत Stallman ने 75 स्वतंत्र acknowledgements मोजले. UC Berkeley ने आपल्या Office of Technology Licensing मधील William Hoskins यांच्या पत्राद्वारे 22 July 1999 रोजी ही clause मागे घेतली.

यातून 3-clause BSD licence उरला. त्यात contributors यांच्या नावांचा वापर तुमच्या product चे endorsement करण्यासाठी करण्यास बंदी घातली आहे. 2-clause आवृत्तीत ही अटसुद्धा काढून टाकली आहे. MIT licence चा मजकूर 1980s मध्ये MIT मधून आला. त्या काळात तो X Window System साठी वापरला जात होता. प्रत्यक्षात तो 2-clause BSD सारखेच काम करतो.

या परवान्यांमागील उद्देश वेगवेगळे होते. सार्वजनिक पैशातून निधी मिळालेल्या University ला तिचे काम कंपन्यांसह सर्वत्र वापरले जावे असे वाटत होते. GNU project ला असा commons हवा होता, जो बंद करता येणार नाही. दोन्ही भूमिका प्रामाणिक आहेत. दोन्हींसाठी एक अपयशाची शक्यता आहे. Permissive code खाजगी स्वरूपात घेतला जाऊ शकतो आणि त्यातून तुम्हाला काहीही परत मिळत नाही. Copyleft code ची अट स्वीकारण्यास कंपन्यांचे वकील नकार देत असल्याने त्या कंपन्या तो code वापरत नाहीत.

Berkeley कडून आणखी एक धडा मिळतो. या post मध्ये पुन्हा पुन्हा त्याच धड्याकडे लक्ष वेधले आहे. AT&T's Unix System Laboratories ने 1992 मध्ये BSD code संदर्भात Berkeley Software Design विरुद्ध दावा दाखल केला. हे प्रकरण early 1994 मध्ये तडजोडीने मिटले. दोन वर्षे BSD वर सुरक्षितपणे build करता येईल की नाही याची कोणालाही खात्री नव्हती. Linux वाढत असताना त्याचा adoption थांबला. कायदेशीर अनिश्चिततेमुळे adoption एखाद्या अनुपलब्ध feature पेक्षा अधिक वेगाने थांबतो.

Apache 2.0 मध्ये पेटंट परवाना का जोडला

Apache Group चा पहिला परवाना हा BSD 4-clause वर आधारित प्रकार होता आणि त्यातही तीच जाहिरातविषयक अडचण होती. 2000 मध्ये आलेल्या Version 1.1 ने ते कलम काढून टाकले. जानेवारी 2004 मध्ये प्रकाशित झालेली Version 2.0 ही किरकोळ दुरुस्ती नसून पूर्णपणे पुनर्लेखन केलेली आवृत्ती होती.

सर्वांत महत्त्वाची भर म्हणजे पेटंट. MIT आणि BSD परवान्यांमध्ये पेटंटविषयी काहीही नमूद केलेले नाही. एखादा contributor त्याच्या code साठी तुम्हाला स्पष्ट copyright permission देऊ शकतो आणि तरीही त्या code च्या कार्यपद्धतीवर लागू होणारे पेटंट स्वतःकडे ठेवू शकतो. त्यानंतर तो तो code वापरणाऱ्या लोकांवर खटला दाखल करू शकतो. Apache 2.0 ही उणीव भरून काढतो: प्रत्येक contributor त्याच्या contribution ला लागू होणारा पेटंट परवाना देतो. तसेच हे कार्य त्यांच्या पेटंटचे उल्लंघन करते असा दावा करून जो कोणी खटला दाखल करतो, त्याचा त्या कार्यासाठीचा स्वतःचा पेटंट परवाना रद्द होतो. हा धोका परस्पर आहे. त्यामुळे प्रत्यक्षात कोणीही खटला दाखल करत नाही.

Version 2.0 मधील उर्वरित बदल प्रशासकीय स्वरूपाचे आहेत. म्हणूनच कंपन्यांना हा परवाना पसंत पडतो. NOTICE file साठी निश्चित व्यवस्था आहे. त्यामुळे attribution संपूर्ण tree मध्ये विखुरलेले न राहता एकाच ठिकाणी ठेवता येते. प्रत्येक source file मध्ये परवान्याचा मजकूर पुन्हा पुन्हा लिहिण्याऐवजी reference द्वारे तो लागू करता येतो. Contributions साठी स्पष्ट अटी लागू होतात. Trademarks या परवान्याच्या कक्षेबाहेर ठेवले आहेत. Apache 2.0 dependency चे legal review करताना अपेक्षित असलेले सर्व प्रश्न परवान्याच्या मजकुरात आधीच सोडवलेले आढळतात. त्यामुळे approval ही नेहमीची प्रक्रिया बनते. "corporate default" याचा बहुतांश अर्थ हाच आहे.

GPLv3 मध्ये काय बदलले आणि Linux GPLv2 वरच का राहिले

TiVo ने Linux चालणारा व्हिडिओ रेकॉर्डर बाजारात आणला आणि GPLv2 नुसार आवश्यक असल्याप्रमाणे kernel source प्रकाशित केला. त्यानंतर hardware ने boot वेळी cryptographic signature तपासली आणि त्याला ओळखता न येणारा kernel चालवण्यास नकार दिला. तुम्ही source वाचू शकत होता, त्यात बदल करू शकत होता आणि तो compile करू शकत होता. मात्र ज्या device मधून तो आला, त्याच device वर तो चालवता येत नव्हता. License च्या शब्दशः अटी पूर्ण झाल्या, पण त्याचा उद्देश निष्फळ ठरला. या पद्धतीला पुढे tivoisation असे नाव मिळाले.

29 June 2007 रोजी प्रकाशित झालेली GPL version 3 याला थेट उत्तर देते. Consumer device मध्ये binary वितरित करताना तुम्ही "Installation Information" देखील पुरवली पाहिजे. यात modified version install करून ती चालवण्यासाठी आवश्यक keys किंवा सूचना समाविष्ट असतात. Version 3 मध्ये स्पष्ट patent grant देखील जोडण्यात आला. November 2006 मधील Microsoft आणि Novell patent agreement ला प्रतिसाद म्हणून काही अटी लिहिण्यात आल्या. तसेच Apache 2.0 सोबत one-way compatibility जोडण्यात आली.

Linux ने हा बदल स्वीकारला नाही. Kernel फक्त GPL version 2 अंतर्गत आहे. त्यात "or any later version" हा पर्याय नाही. त्याच्या COPYING file मध्ये हे स्पष्टपणे नमूद केले आहे. Signed hardware साठीच्या anti-tivoisation अटींना Linus Torvalds यांनी सार्वजनिकपणे विरोध केला. मात्र प्रत्यक्ष अडथळा या मतभेदापेक्षा मोठा आहे. Kernel चे हजारो copyright holders आहेत. त्यामुळे सर्वांची इच्छा असली तरी relicence साठी आवश्यक permissions कोणीही एकत्र करू शकणार नाही. एखाद्या project साठी ही एकच वस्तुस्थिती सर्वात मजबूत संरक्षण ठरू शकते. एका कंपनीच्या मालकीच्या project कडे पाहताना हे लक्षात ठेवणे महत्त्वाचे आहे.

इतर 2007 मधील license तुमच्यासाठी अधिक महत्त्वाचा आहे. त्याच वर्षी November मध्ये प्रकाशित झालेली GNU Affero GPL version 3 network वरून program शी संवाद साधणाऱ्या लोकांपर्यंत source देण्याची जबाबदारी वाढवते. Modified AGPL service सार्वजनिक वापरासाठी चालवली, तर त्या users ना source द्यावा लागतो. म्हणूनच self-hosted web software पैकी बरेच software AGPL अंतर्गत आहे. Nextcloud हे त्याचे एक उदाहरण आहे. जर तुम्ही Nextcloud चे self-hosted पर्याय यांची तुलना करत असाल, तर प्रत्येक candidate च्या repository मधील license line त्याच्या feature list पेक्षा पुढील पाच वर्षांबद्दल अधिक माहिती देते.

तुम्ही प्रत्यक्षात कोणते licences एकत्र करू शकता?

Compatibility एका दिशेने कार्य करते: permissive licence कडून copyleft licence कडे.

• MIT आणि BSD code कोणत्याही प्रकल्पात समाविष्ट करता येतो, closed product मध्येही.
• Apache 2.0 code GPLv3 project मध्ये समाविष्ट करता येतो आणि एकत्रित work GPLv3 अंतर्गत येते.
• Apache 2.0 code GPLv2-only project मध्ये समाविष्ट करता येत नाही. त्यातील patent termination आणि indemnity अटी या अतिरिक्त अटी आहेत. GPLv2 अंतर्गत अशा अटी जोडण्याची अनुमती नाही. FSF आणि ASF दोघेही हा निष्कर्ष प्रकाशित करतात.
• GPL code तुम्ही स्वतः permissive licence अंतर्गत आणू शकत नाही. हे केवळ copyright holders करू शकतात. त्यामुळे ते कोण आहेत हा प्रश्न पुन्हा उपस्थित होतो.

पुनर्परवाना देण्याचा काळ: SSPL, BUSL आणि त्या काय नाहीत

यामागील कारण व्यावसायिक होते. एखाद्या उत्पादनाचे copyright एखाद्या कंपनीकडे असते, cloud provider ते उत्पादन मोठ्या प्रमाणावर managed service म्हणून विकतो आणि त्या बदल्यात फारच कमी योगदान देतो; त्यामुळे कंपनी हे थांबवण्यासाठी licence बदलते. Redis Labs ने August 2018 मध्ये अनेक modules साठी Apache 2.0 वर Commons Clause जोडून ही बाब प्रथम स्पष्टपणे केली. त्यानंतर MongoDB ने 16 October 2018 रोजी AGPLv3 वरून Server Side Public License वर स्थलांतर केले.

SSPL मध्ये AGPL मधील एक section पुन्हा लिहिलेला आहे. एखादा program third parties ना service म्हणून उपलब्ध करून दिल्यास, तो उपलब्ध करून देण्यासाठी वापरत असलेल्या प्रत्येक गोष्टीचा source प्रकाशित करावा लागतो. त्यात संबंधित management आणि orchestration software चाही समावेश होतो. या बंधनाची स्पष्ट मर्यादा नाही आणि कोणत्याही न्यायालयाने अद्याप त्याची चाचणी केलेली नाही. OSI ने या licence ला कधीही मान्यता दिली नाही आणि MongoDB ने March 2019 मध्ये आपला application मागे घेतला. Debian ने December 2018 मध्येच सांगितले होते की SSPL software त्याच्या archive मध्ये समाविष्ट करता येणार नाही. Fedora ने January 2019 मध्ये या licence ला free नसल्याचा निर्णय दिला. त्यानंतर Red Hat ने Fedora आणि Red Hat Enterprise Linux मधून MongoDB काढून टाकले. पुनर्परवान्याचा हा यांत्रिक परिणाम आहे: distribution त्या software चे packaging थांबवते. त्यामुळे तुमचे upgrades आता vendor च्या वेळापत्रकानुसार vendor repository मधून येतात.

Business Source License ही वेगळी पद्धत आहे. ती MariaDB च्या founders कडून आली आणि version 1.1 ही 2017 मधील आहे. ती copyleft नाही आणि open source देखील नाही. Source सार्वजनिक असतो. Vendor ने स्पष्टपणे वगळलेल्या वापराव्यतिरिक्त वापर विनामूल्य असतो. सामान्यतः वगळलेला वापर म्हणजे प्रतिस्पर्धी hosted service चालवणे. प्रत्येक release त्या release नंतर जास्तीत जास्त four years मध्ये, change date ला, आपोआप खऱ्या open source licence मध्ये रूपांतरित होतो. ज्या licence मध्ये रूपांतर होईल ती GPLv2-compatible असणे आवश्यक आहे. HashiCorp ने 10 August 2023 रोजी Terraform आणि त्याची इतर products BUSL 1.1 वर हलवली. Outline देखील हेच वापरते. त्यामुळे तुम्ही self-hosted Notion च्या पर्यायांमधून निवड करत असाल, तर ही बाब लक्षात घ्या: ते तुमच्या स्वतःच्या team साठी चालवणे अनुमत आहे; परंतु त्यावर आधारित service तयार करणे अनुमत नाही.

यापैकी कोणतेही licence अप्रामाणिक नाही. दोन्ही licences स्पष्टपणे सांगतात की त्या source available आहेत. OSI च्या व्याख्येनुसार त्यापैकी कोणतेही open source नाही. या फरकाचा परिणाम ज्या cloud provider ला लक्ष्य केले होते त्याच्यावर नव्हे, तर तुमच्यावर होतो.

OpenSearch: परवाना बदलल्याची किंमत ऑपरेटरला किती मोजावी लागते

14 January 2021 रोजी Elastic ने जाहीर केले की Elasticsearch आणि Kibana, release 7.11 पासून, Apache 2.0 सोडून SSPL किंवा Elastic License यांपैकी एका परवान्याकडे जातील. Version 7.10.2 ही Apache 2.0 अंतर्गत आलेली शेवटची release होती. सुमारे एका आठवड्यानंतर AWS ने या दोन्हींचा Apache 2.0 fork तयार करून त्याची देखभाल करण्याचे सांगितले. 12 April 2021 रोजी या fork चे नाव OpenSearch ठेवण्यात आले आणि Kibana चे नाव OpenSearch Dashboards करण्यात आले. OpenSearch 1.0 12 July 2021 रोजी सर्वसाधारणपणे उपलब्ध झाले. ते Elasticsearch 7.10.2 आणि Kibana 7.10.2 यांच्या codebase वर आधारित होते.

यामुळे clusters चालवणाऱ्या लोकांना काय किंमत मोजावी लागली ते पाहा. Package names आणि repositories बदलले. Runbook मधील Kibana चा प्रत्येक संदर्भ OpenSearch Dashboards असा बदलावा लागला. Plugin names बदलले. त्यानंतर हा विभाजन application code पर्यंत पोहोचला: Elastic च्या official client libraries च्या version 7.13 पासून client आपण कशाशी connect झाला आहे ते तपासतो आणि Elasticsearch नसलेल्या कोणत्याही गोष्टीविरुद्ध पुढे काम करण्यास नकार देतो. Server हा unknown product असल्याचे तो कळवतो. तुम्ही ज्या कंपनीत काम करत नाही, त्या कंपनीने घेतलेला licence निर्णय तुमच्या स्वतःच्या application मधील failing call म्हणून समोर आला.

यानंतर या कथेला आणखी दोन वळणे मिळाली. 29 August 2024 रोजी Elastic ने तिसरा licence पर्याय म्हणून AGPLv3 जोडला. त्यामुळे सध्याचे Elasticsearch पुन्हा OSI-approved open source झाले. 16 September 2024 रोजी AWS ने OpenSearch चे हस्तांतरण Linux Foundation द्वारे hosted असलेल्या OpenSearch Software Foundation कडे केले. त्यामुळे या fork ला एकाच कंपनीवर अवलंबून नसलेले governance home मिळाले. विभाजनानंतर पाच वर्षांनी दोन्ही projects open source आहेत, दोन्हींची देखभाल केली जाते आणि August 2026 पर्यंत OpenSearch ची 3.x series सुरू आहे.

याचा शेवटचा धडा महत्त्वाचा आहे. Licence परत आला, पण fork कायम राहिला. Ecosystem मध्ये प्रत्येक गोष्टीच्या दोन आवृत्त्या तयार झाल्यानंतर कागदोपत्री बदल मागे घेऊन त्या पुन्हा एकत्र करता येत नाहीत.

Relicence मुळे किती त्रास होतो हे ठरवणारी संख्या म्हणजे announcement आणि प्रत्यक्ष deploy करता येणारा stable fork उपलब्ध होणे यांमधील कालावधी.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

प्रत्येक कालावधी vendor च्या public announcement पासून fork च्या पहिल्या stable release पर्यंत मोजला आहे. खाली दिलेल्या तारखा वापरल्या आहेत. OpenSearch 1.0 ला 179 दिवस लागले, कारण fork चे नाव बदलावे लागले आणि त्याची नव्याने निर्मिती करावी लागली; त्याची नक्कल करण्यासाठी आधीचा कोणताही fork उपलब्ध नव्हता. OpenTofu ला 153 दिवस लागले. Valkey ला 27 दिवस लागले, कारण त्याने Redis 7.2.4 चा fork केला आणि protocol तसेच on-disk format अपरिवर्तित ठेवले. यातील महत्त्वाची दिशा अशी आहे: आता विश्वासार्ह fork काही आठवड्यांत उपलब्ध होतो आणि पहिल्याच दिवसापासून foundation व सशुल्क maintainers त्याच्याशी जोडलेले असतात.

Valkey आणि OpenTofu: तोच नमुना, अधिक वेगाने

Redis Ltd ने 20 March 2024 रोजी Redis चे परवाना 3-clause BSD वरून RSALv2 किंवा SSPLv1 यांपैकी एका पर्यायात बदलले. त्यानंतर आठ दिवसांनी Linux Foundation ने Valkey ची घोषणा केली. Valkey हा Redis 7.2.4 वरून fork करण्यात आला असून तो BSD 3-clause अंतर्गतच राहिला. Valkey 7.2.5 हे 16 April 2024 रोजी प्रसिद्ध झाले. त्यात तोच protocol आणि त्याच data files होत्या. त्यामुळे बहुतेक operators साठी migration म्हणजे package name बदलणे एवढेच होते. त्यानंतर Redis ने May 2025 मध्ये Redis 8 मध्ये AGPLv3 हा तिसरा पर्याय जोडला. त्यामुळे OSI च्या व्याख्येनुसार Redis पुन्हा open source झाले. Valkey मात्र स्वतःच्या governance अंतर्गत सुरू राहिले. ही रचना Elasticsearch शी बरीच जुळते.

Terraform चा प्रवासही असाच झाला, पण त्यात एक अतिरिक्त अध्याय होता. OpenTofu ने Mozilla Public License 2.0 अंतर्गत प्रसिद्ध झालेल्या शेवटच्या release वरून fork केले. ते September 2023 मध्ये Linux Foundation मध्ये सहभागी झाले आणि 10 January 2024 रोजी 1.6.0 प्रसिद्ध केले. 3 April 2024 रोजी HashiCorp च्या वकिलांनी project ला cease and desist letter पाठवले. BUSL-licensed Terraform release मधील code fork मध्ये copy केल्याचा त्यात दावा करण्यात आला. OpenTofu ने 11 April 2024 रोजी सविस्तर उत्तर प्रसिद्ध करून हा दावा नाकारला. तसेच दोन्ही projects मध्ये समान असलेल्या MPL-licensed history मधून वादग्रस्त code आले असल्याचे स्पष्ट केले. त्यानंतर सार्वजनिकरीत्या आणखी काही घडले नाही. त्या घटनेतील लक्षात ठेवण्यासारखा खरा धोका हा आहे: केवळ आरोपामुळे adoption एका quarter साठी थांबू शकते. तीस वर्षांपूर्वी Berkeley lawsuit मुळे हाच परिणाम झाला होता.

प्रत्येक fork ची सुरुवात licence पासून होत नाही. Gitea चे development एका company अंतर्गत गेल्यानंतर 2022 मध्ये Forgejo ने Gitea वरून fork केले. हा licensing dispute नसून governance dispute होता. Forgejo आपल्या version 8 series मध्ये MIT अंतर्गतच राहिले. त्यानंतर 2024 मधील version 9.0 पासून त्याने GPLv3 or later अंतर्गत पुन्हा licence घेतले. त्यामुळे त्याचे work व्यावसायिक नियंत्रणाखालील product मध्ये परत नेणे शक्य राहिले नाही. self-hosted Git server च्या पर्यायांचा विचार करत असल्यास, एकाच codebase मधून निर्माण झालेल्या दोन philosophies चे हे सर्वात स्पष्ट सध्याचे उदाहरण आहे.

पहिली स्थापना करण्यापूर्वी करायची चाचणी

पहिली स्थापना केल्यानंतर नव्हे, त्यापूर्वी हे चार प्रश्न विचारा.

1. कॉपीराइट कोणाकडे आहे? परवाना पुन्हा देण्यासाठी प्रत्येक कॉपीराइटधारकाची परवानगी आवश्यक असते. त्यामुळे शेकडो स्वतंत्र योगदानकर्ते असलेल्या आणि हक्क हस्तांतरण नसलेल्या प्रकल्पाचा परवाना प्रत्यक्षात बदलता येत नाही. एका कंपनीकडे सर्व हक्क असलेला प्रकल्प संचालक मंडळाच्या बैठकीत पुन्हा परवानाकृत करता येतो.
2. CLA आहे का, आणि त्यातून कोणते हक्क दिले जातात? कंपनीला तुमच्या योगदानाचा तिला योग्य वाटेल त्या कोणत्याही अटींनुसार पुन्हा परवाना देण्याची अनुमती देणारा contributor licence agreement हा वर उल्लेख केलेल्या प्रत्येक परवाना-बदलामागील नेमका mechanism आहे. Linux kernel ने 2004 मध्ये स्वीकारलेली sign-off line असलेले DCO (developer certificate of origin) कोणतेही हक्क हस्तांतरित करत नाही. Foundation कडे असलेला CLA कंपनीकडे असलेल्या CLA पेक्षा अधिक सुरक्षित असतो, कारण कंपनी विकली जाऊ शकते.
3. ट्रेडमार्कचा मालक कोण आहे? Elastic ने Elasticsearch हे नाव स्वतःकडे ठेवले. त्यामुळे fork ला स्वतःचे नाव बदलावे लागले आणि Kibana चा उल्लेख असलेले प्रत्येक runbook पुन्हा लिहावे लागले.
4. विशेषतः तुमच्यासाठी परवाना पुन्हा देण्याची किंमत काय असेल? Data format, client libraries, तुम्हाला पुन्हा लिहावी लागणारी configuration आणि आधीपासून compatible fork उपलब्ध आहे का, यांची नोंद करा.

यातील काही प्रश्नांची उत्तरे दोन commands काही सेकंदांत देतात.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

प्रत्येक Debian आणि Ubuntu package मध्ये /usr/share/doc/<package>/copyright येथे एक file असते. त्यात तुम्ही install केलेल्या version चा licence नोंदवलेला असतो; project आज कोणता licence वापरतो, हे त्यात नोंदवलेले नसते. Ubuntu 24.04 मधील bash साठी त्या file मध्ये GNU General Public License version 3 असे नमूद केलेले आहे. दुसरा command source checkout मध्ये चालवल्यास licence file चा स्वतःचा इतिहास मिळतो. गेल्या दोन वर्षांतील commit असल्यास, त्या project वर काही build करण्यापूर्वी तो वाचणे योग्य ठरते. Command ने काहीही output दिले नाही, तर repository मध्ये licence file चे नाव वेगळे असू शकते. त्यामुळे root directory ची यादी करा आणि शोधा.

कोणताही licence तुम्हाला प्रत्येक परिणामापासून संरक्षण देत नाही. केवळ विचारसरणीवर आधारित निवड केल्यास अनपेक्षित अडचणी येऊ शकतात. कॉपीराइट अनेक व्यक्तींमध्ये विभागलेला किंवा foundation कडे असलेले projects प्राधान्याने निवडा आणि तुमचा data export करता येईल अशा format मध्ये ठेवा. त्यानंतर तुम्ही कोणत्या fork वर स्थलांतर कराल ते शोधा आणि गरज पडण्यापूर्वी त्याचे नाव लिहून ठेवा. प्रत्येक candidate वर ही तपासणी केल्यास एका तासापेक्षा कमी वेळ लागतो. तुम्ही 2026 मध्ये काय self-host करायचे हे ठरवत असताना upgrade आणि migration यांतील फरक स्पष्ट करणारी हीच पद्धत आहे.

FAQ

MIT licence आणि BSD licence एकच आहेत का?

प्रत्यक्षात, MIT licence ही 2-clause BSD licence शी जुळते: copyright notice आणि warranty disclaimer कायम ठेवा, त्यानंतर बंद स्वरूपाचे product तयार करण्यासह तुम्हाला हवे ते करा. 3-clause BSD licence मध्ये आणखी एक अट आहे: परवानगीशिवाय contributors ची नावे तुमच्या product च्या समर्थनासाठी वापरता येत नाहीत. जुन्या 4-clause आवृत्तीत जाहिरात साहित्यामध्ये acknowledgement देण्याची अटही होती. UC Berkeley ने 22 July 1999 रोजी ही अट मागे घेतली. त्यामुळे सध्या जवळजवळ कोणत्याही product मध्ये ती आढळत नाही.

Apache 2.0 code GPLv2 project मध्ये समाविष्ट करू शकतो का?

नाही. Apache 2.0 मध्ये GPLv2 परवानगी देत नाही अशा अटी आहेत. त्यातील मुख्य अट patent termination clause आहे. त्यामुळे combined work दोन्ही licences चे एकाच वेळी पालन करू शकत नाही. FSF आणि ASF दोन्ही हीच भूमिका प्रकाशित करतात. उलट दिशेने हे शक्य आहे: Apache 2.0 code GPLv3 project मध्ये समाविष्ट करता येतो आणि त्याचा परिणाम GPLv3 असतो. Apache 2.0 code Linux kernel मध्ये merge करता येत नाही, याचेही हेच कारण आहे. Linux kernel फक्त GPL version 2 अंतर्गत आहे.

SSPL ही open source licence आहे का?

नाही. या उत्तराचे व्यावहारिक परिणाम आहेत. OSI ने तिला कधीही मंजुरी दिली नाही आणि MongoDB ने March 2019 मध्ये आपला अर्ज मागे घेतला. Debian ने December 2018 मध्ये सांगितले की SSPL software त्याच्या archive मध्ये समाविष्ट होऊ नये. Fedora ने January 2019 मध्ये ही licence free नाही असा निर्णय दिला. त्यानंतर Red Hat ने Fedora आणि Red Hat Enterprise Linux मधून MongoDB काढून टाकले. याचा तुमच्यासाठी अर्थ असा आहे की तुमचे distribution पूर्वी maintain करत असलेले package आता vendor repository मधून येते आणि त्याचे updates vendor च्या support timetable नुसार मिळतात. Business Source License ही देखील open source ऐवजी source available licence आहे. मात्र प्रत्येक release चार वर्षांच्या आत open source licence मध्ये रूपांतरित होते.

मी आधीच चालवत असलेल्या version वर licence change लागू होतो का?

नाही. एखाद्या release सोबत दिलेली licence आधीच प्रकाशित केलेल्या copies मधून मागे घेता येत नाही. Forks शक्य होण्याचे हेच कारण आहे. OpenSearch हे Elasticsearch 7.10.2 वर आधारित तयार करण्यात आले. Apache 2.0 अंतर्गत Elastic ने प्रकाशित केलेला तो शेवटचा release होता. तुम्ही गमावता ते भविष्य, कारण पुढील security fix नवीन अटींनुसार येतो. शेवटची permissively licensed version pin केल्याने काही महिने मिळू शकतात. मात्र ही दीर्घकालीन योजना नाही.