GPL, MIT और Apache लाइसेंस में क्या अंतर है?

GPL बनाम MIT बनाम Apache: प्रत्येक लाइसेंस आपसे क्या अपेक्षा करता है

GPL, MIT और Apache 2.0 एक ही प्रश्न का उत्तर अलग-अलग तरीकों से देते हैं: जब आप सॉफ़्टवेयर को आगे बढ़ाते हैं, तो आप अन्य लोगों के प्रति क्या उत्तरदायी हैं? MIT केवल एक कॉपीराइट नोटिस की मांग करता है और कुछ नहीं। Apache 2.0 उस नोटिस के साथ-साथ कोड को छूने वाले प्रत्येक व्यक्ति के बीच एक पेटेंट समझौते की मांग करता है। GPL आपसे यह अपेक्षा करता है कि आप उस सॉफ़्टवेयर के सोर्स कोड को प्रकाशित करें जिसे आपने उस पर बनाया है, उसी लाइसेंस के तहत जो आपको प्राप्त हुआ था।

यह वकीलों के लिए एक प्रश्न जैसा दिखता है, जब तक कि वह दिन न आ जाए जब आपके द्वारा चलाया जाने वाला कोई प्रोजेक्ट अपना लाइसेंस बदल ले और दो भागों में विभाजित हो जाए। तब यह एक ऑपरेशंस का प्रश्न बन जाता है। आपके पास चुनने के लिए दो पैकेज रिपॉजिटरी होती हैं, और क्लाइंट लाइब्रेरीज़ एक-दूसरे से बात करना बंद कर देती हैं। यह गाइड लाइसेंस और उनके काम करने के तरीके के बारे में है, न कि उस आंदोलन के बारे में जिसने उन्हें जन्म दिया, इसलिए प्रत्येक सेक्शन वहीं समाप्त होता है जहाँ वह आपको प्रभावित करता है: वह व्यक्ति जिसे अपग्रेड चलाना है।

GPL का अस्तित्व क्यों है: एक ऐसा प्रिंटर जिसे ठीक करने की अनुमति किसी को नहीं थी

लगभग 1980 में MIT Artificial Intelligence Lab को एक Xerox 9700 लेजर प्रिंटर प्राप्त हुआ। लैब ने पहले के एक प्रिंटर के सॉफ्टवेयर में सुधार किया था ताकि वह बता सके कि आपका जॉब कब जाम हो गया है। नए प्रिंटर के लिए कोई source code उपलब्ध नहीं था, और nondisclosure agreement के कारण इसके लिए किए गए अनुरोध को अस्वीकार कर दिया गया। उस समय लैब में प्रोग्रामर रहे Richard Stallman ने उस इनकार को एक खराब दिन के बजाय एक सामान्य स्थिति माना, और 27 September 1983 को GNU project की घोषणा की।

Copyleft को copyright कानून के आधार पर बनाया गया है, न कि उसके विरुद्ध। डिफ़ॉल्ट रूप से, आपके पास किसी और के code को कॉपी करने का कोई अधिकार नहीं है। GPL एक शर्त पर वह अधिकार प्रदान करता है: यदि आप प्रोग्राम किसी और को देते हैं, तो आपको उन्हें उसी शर्तों के तहत source code भी देना होगा, ताकि वे वह कर सकें जो लैब नहीं कर सकी थी। यह शर्त लागू करने योग्य है क्योंकि licence के बिना आपके पास मूल रूप से कोई अनुमति ही नहीं थी।

Stallman ने सबसे पहले GNU Emacs के लिए एक licence लिखा, फिर 25 February 1989 को इसे सामान्यीकृत करके GPL version 1 बनाया। GPL version 2 जून 1991 में आया, और यह अभी भी आपके द्वारा चलाए जाने वाले अधिकांश system software का licence है। Lesser GPL को libraries के लिए लाया गया, ताकि एक copyleft library को किसी भी licence के तहत आने वाले प्रोग्राम द्वारा link किया जा सके, बिना उस प्रोग्राम को GPL के दायरे में लाए।

एक विवरण यह तय करता है कि GPL एक self-hoster को कैसे प्रभावित करता है। यह दायित्व distribution (वितरण) पर लागू होता है, न कि उपयोग पर। आप एक GPL प्रोग्राम को modify कर सकते हैं, उसे अपने सर्वर पर चला सकते हैं, और जनता को सेवा दे सकते हैं, और आप किसी के प्रति जवाबदेह नहीं हैं, क्योंकि आपने कभी किसी को उसकी copy नहीं दी। यही वह अंतर है जिसके कारण AGPL का अस्तित्व है।

अनुमतिवादी परंपरा: पहले BSD, फिर MIT

Berkeley ने एक अलग रास्ता अपनाया। Computer Systems Research Group ने अपने Unix कार्य को एक ऐसे licence के तहत जारी किया जिसमें केवल copyright notice को बनाए रखने का अनुरोध किया गया था और सभी प्रकार की वारंटी को अस्वीकार कर दिया गया था। मूल संस्करण में चार खंड (clauses) थे, और चौथा, विज्ञापन खंड (advertising clause), यह अनिवार्य करता था कि सॉफ्टवेयर की विशेषताओं का उल्लेख करने वाली सभी विज्ञापन सामग्री में विश्वविद्यालय का आभार व्यक्त किया जाए। यह तरीका बड़े पैमाने पर काम नहीं करता है। Stallman ने 1997 के NetBSD संस्करण में 75 अलग-अलग आभारों की गणना की थी। UC Berkeley ने 22 July 1999 को अपने Office of Technology Licensing के William Hoskins के एक पत्र के माध्यम से इस खंड को हटा दिया।

जो शेष बचा है वह 3-clause BSD licence है, जो योगदानकर्ताओं के नामों का उपयोग करके अपने उत्पाद का समर्थन करने पर प्रतिबंध जोड़ता है, और 2-clause संस्करण है, जो इसे भी हटा देता है। MIT licence का टेक्स्ट 1980 के दशक में MIT से आया, जहाँ यह X Window System को कवर करता था, और व्यवहार में यह 2-clause BSD जैसा ही कार्य करता है।

उद्देश्य अलग-अलग थे। सार्वजनिक धन से वित्तपोषित एक विश्वविद्यालय चाहता था कि उसके काम का उपयोग हर जगह हो, जिसमें कंपनियां भी शामिल हों। GNU project एक ऐसा commons चाहता था जिसे बंद न किया जा सके। दोनों स्थितियां ईमानदार हैं, और दोनों में विफलता का एक तरीका है। Permissive code को निजी बनाया जा सकता है, और आपको बदले में कुछ नहीं मिलता। Copyleft code को उन कंपनियों द्वारा अस्वीकार कर दिया जाता है जिनके वकील इस शर्त को स्वीकार नहीं करेंगे।

Berkeley से एक दूसरा सबक भी मिलता है, और यह वही है जिस पर यह पोस्ट बार-बार लौटती है। AT&T की Unix System Laboratories ने 1992 में BSD code को लेकर Berkeley Software Design पर मुकदमा दायर किया, और यह मामला 1994 की शुरुआत में सुलझ गया। दो वर्षों तक कोई भी यह सुनिश्चित नहीं कर सका कि BSD पर निर्माण करना सुरक्षित है या नहीं, और Linux के बढ़ने के दौरान इसका adoption रुक गया। कानूनी अनिश्चितता किसी फीचर की कमी की तुलना में adoption को अधिक तेजी से रोकती है।

Apache 2.0 में पेटेंट अनुदान क्यों जोड़ा गया

Apache Group का पहला लाइसेंस BSD 4-clause का एक व्युत्पन्न (derivative) था, जिसमें वही विज्ञापन संबंधी समस्या थी। वर्ष 2000 में आए Version 1.1 ने उस क्लॉज को हटा दिया। जनवरी 2004 में प्रकाशित Version 2.0, किसी पैच के बजाय एक पूर्ण पुनर्लेखन था।

इसमें सबसे महत्वपूर्ण अतिरिक्त प्रावधान पेटेंट से संबंधित है। MIT और BSD लाइसेंस में इनके बारे में कुछ भी नहीं कहा गया है। एक योगदानकर्ता (contributor) आपको अपने कोड के लिए स्पष्ट कॉपीराइट अनुमति दे सकता है, लेकिन फिर भी वह उस कोड के कार्य पर पेटेंट रख सकता है और बाद में उसका उपयोग करने वालों पर मुकदमा कर सकता है। Apache 2.0 इस खामी को दूर करता है: प्रत्येक योगदानकर्ता अपने योगदान के लिए एक पेटेंट लाइसेंस प्रदान करता है, और यदि कोई व्यक्ति यह दावा करते हुए मुकदमा करता है कि यह कार्य उनके पेटेंट का उल्लंघन करता है, तो उनका अपना पेटेंट लाइसेंस समाप्त हो जाता है। यह खतरा पारस्परिक है, इसलिए व्यवहार में कोई भी मुकदमा नहीं करता है।

2.0 का शेष भाग प्रशासनिक है, और यही कारण है कि कंपनियां इसे पसंद करती हैं। इसमें एक परिभाषित NOTICE फाइल होती है, जिससे श्रेय (attribution) देने के लिए एक निश्चित स्थान होता है, न कि वह पूरे ट्री में बिखरा रहता है। लाइसेंस को हर सोर्स फाइल में पेस्ट करने के बजाय संदर्भ (reference) द्वारा लागू किया जा सकता है। योगदान स्पष्ट शर्तों के अंतर्गत आते हैं। ट्रेडमार्क को इसमें शामिल नहीं किया गया है। Apache 2.0 निर्भरता (dependency) की कानूनी समीक्षा करने पर वे सभी प्रश्न पहले से ही हल मिलते हैं जो पूछे जाने की आवश्यकता होती है, इसलिए अनुमोदन एक सामान्य प्रक्रिया बन जाती है, और "कॉर्पोरेट डिफॉल्ट" का अधिकांश अर्थ यही है।

GPLv3 ने क्या बदला, और Linux क्यों GPLv2 पर ही रहा

TiVo ने Linux चलाने वाला एक वीडियो रिकॉर्डर शिप किया और kernel source को वैसे ही प्रकाशित किया जैसा GPLv2 के लिए आवश्यक है। इसके बाद हार्डवेयर ने बूट के समय एक cryptographic signature की जाँच की और किसी ऐसे kernel को चलाने से मना कर दिया जिसे वह पहचानता नहीं था। आप source को पढ़ सकते थे, उसे बदल सकते थे और compile कर सकते थे। लेकिन आप उसे उस डिवाइस पर नहीं चला सकते थे जिससे वह आया था। लाइसेंस के शब्दों का पालन तो हुआ लेकिन उसका उद्देश्य विफल हो गया, और इस प्रक्रिया को tivoisation का नाम दिया गया।

29 June 2007 को प्रकाशित GPL version 3, सीधे तौर पर इसका उत्तर देता है। जब आप किसी consumer device के भीतर binary को convey करते हैं, तो आपको "Installation Information" भी प्रदान करनी होगी: यानी वे keys या निर्देश जो संशोधित संस्करण को install करने और उसे चलाने के लिए आवश्यक हैं। Version 3 ने एक स्पष्ट patent grant भी जोड़ा, जो November 2006 के Microsoft और Novell patent समझौते के जवाब में लिखी गई शर्तें थीं, और Apache 2.0 के साथ एकतरफा संगतता (one-way compatibility) भी शामिल की।

Linux ने इसका अनुसरण नहीं किया। kernel केवल GPL version 2 है, जिसमें "or any later version" जैसी कोई escape clause नहीं है, और इसकी COPYING फाइल ऐसा ही कहती है। Linus Torvalds ने signed hardware के लिए anti-tivoisation शर्तों पर सार्वजनिक रूप से आपत्ति जताई थी। व्यावहारिक बाधा असहमति से कहीं बड़ी है: kernel के हजारों copyright holders हैं, इसलिए यदि हर कोई चाहे भी, तो भी कोई भी उन अनुमतियों को इकट्ठा नहीं कर सकता जो relicence के लिए आवश्यक होंगी। यह अकेला तथ्य किसी प्रोजेक्ट के पास मौजूद सबसे मजबूत सुरक्षा है, और जब आप किसी एक कंपनी के स्वामित्व वाले प्रोजेक्ट को देखते हैं तो इसे याद रखना उचित है।

दूसरा 2007 का लाइसेंस आपके लिए अधिक मायने रखता है। उसी वर्ष November में प्रकाशित GNU Affero GPL version 3, source obligation को उन लोगों तक विस्तारित करता है जो नेटवर्क पर प्रोग्राम के साथ इंटरैक्ट करते हैं। यदि आप जनता के लिए कोई संशोधित AGPL सर्विस चलाते हैं, तो आप उन उपयोगकर्ताओं को source देने के लिए बाध्य हैं। यही कारण है कि इतना अधिक self-hosted वेब सॉफ्टवेयर AGPL है। Nextcloud इसका एक उदाहरण है, और यदि आप Nextcloud के self-hosted विकल्पों की तुलना कर रहे हैं, तो प्रत्येक candidate के repository में मौजूद लाइसेंस लाइन आपको उसके feature list की तुलना में उसके अगले पांच वर्षों के बारे में अधिक जानकारी देती है।

आप वास्तव में किन लाइसेंसों को मिला सकते हैं?

संगतता (compatibility) एक ही दिशा में काम करती है, permissive से copyleft की ओर।

• MIT और BSD कोड को किसी भी चीज़ में शामिल किया जा सकता है, जिसमें closed-source उत्पाद भी शामिल हैं।
• Apache 2.0 कोड को GPLv3 प्रोजेक्ट में शामिल किया जा सकता है, और संयुक्त कार्य GPLv3 बन जाता है।
• Apache 2.0 कोड को केवल GPLv2 वाले प्रोजेक्ट में शामिल नहीं किया जा सकता है। इसकी patent termination और indemnity शर्तें ऐसी अतिरिक्त शर्तें हैं जिन्हें GPLv2 जोड़ने की अनुमति नहीं देता है। FSF और ASF दोनों इस निष्कर्ष को प्रकाशित करते हैं।
• GPL कोड को आपके द्वारा किसी permissive लाइसेंस में नहीं बदला जा सकता है। केवल कॉपीराइट धारक ही ऐसा कर सकते हैं, जो आपको वापस इस सवाल पर ले आता है कि वे कौन हैं।

रीलाइसेंसिंग का युग: SSPL, BUSL, और वे क्या नहीं हैं

इसका कारण व्यावसायिक था। एक कंपनी के पास किसी उत्पाद का कॉपीराइट होता है, एक क्लाउड प्रदाता इसे बड़े पैमाने पर मैनेज्ड सर्विस के रूप में बेचता है और बहुत कम योगदान देता है, और कंपनी इसे रोकने के लिए लाइसेंस बदल देती है। Redis Labs ने अगस्त 2018 में अपने कई मॉड्यूल्स के लिए Apache 2.0 के ऊपर Commons Clause जोड़कर पहला स्पष्ट कदम उठाया। MongoDB ने 16 अक्टूबर 2018 को AGPLv3 से Server Side Public License पर जाकर इसका अनुसरण किया।

SSPL, AGPL ही है जिसमें एक सेक्शन को फिर से लिखा गया है। यदि आप प्रोग्राम को किसी तीसरे पक्ष को सर्विस के रूप में प्रदान करते हैं, तो आपको इसे प्रदान करने के लिए उपयोग किए जाने वाले हर घटक का सोर्स कोड प्रकाशित करना होगा, जिसमें इसके आसपास का मैनेजमेंट और ऑर्केस्ट्रेशन सॉफ्टवेयर भी शामिल है। उस बाध्यता की कोई स्पष्ट सीमा नहीं है, और किसी अदालत ने इसका परीक्षण नहीं किया है। OSI ने कभी भी इस लाइसेंस को मंजूरी नहीं दी, और MongoDB ने मार्च 2019 में अपना आवेदन वापस ले लिया। Debian ने दिसंबर 2018 में ही कह दिया था कि SSPL सॉफ्टवेयर उनके आर्काइव में नहीं आता है, और Fedora ने जनवरी 2019 में फैसला सुनाया कि यह लाइसेंस फ्री नहीं है, जिसके बाद Red Hat ने MongoDB को Fedora और Red Hat Enterprise Linux से हटा दिया। रीलाइसेंसिंग का यह यांत्रिक परिणाम है: डिस्ट्रिब्यूशन सॉफ्टवेयर को पैकेज करना बंद कर देता है, इसलिए आपके अपग्रेड अब वेंडर के शेड्यूल पर वेंडर रिपॉजिटरी से आते हैं।

Business Source License एक अलग उपकरण है। यह MariaDB के संस्थापकों द्वारा लाया गया था, और इसका वर्जन 1.1 वर्ष 2017 का है। यह कॉपीलेफ्ट नहीं है और यह ओपन सोर्स नहीं है। सोर्स सार्वजनिक है, उपयोग मुफ्त है, सिवाय उस उपयोग के जिसे वेंडर अलग रखता है, जो आमतौर पर एक प्रतिस्पर्धी होस्टेड सर्विस चलाना होता है, और प्रत्येक रिलीज उस रिलीज के चार साल से अधिक न होने वाली एक निश्चित तिथि पर स्वचालित रूप से एक वास्तविक ओपन सोर्स लाइसेंस में बदल जाती है। जिस लाइसेंस में यह बदलता है, उसे GPLv2-compatible होना चाहिए। HashiCorp ने 10 अगस्त 2023 को Terraform और अपने अन्य उत्पादों को BUSL 1.1 पर स्थानांतरित कर दिया। Outline भी इसका उपयोग करता है, जिसे जानना उपयोगी है यदि आप self-hosted Notion विकल्पों में से चुन रहे हैं: इसे अपनी टीम के लिए चलाना अनुमत है, और इस पर कोई सर्विस बनाना अनुमत नहीं है।

कोई भी लाइसेंस बेईमान नहीं है। दोनों स्पष्ट रूप से कहते हैं कि वे सोर्स उपलब्ध (source available) हैं। OSI की परिभाषा के अनुसार कोई भी ओपन सोर्स नहीं है, और इसका अंतर क्लाउड प्रदाता के बजाय आप पर पड़ता है, जिसे लक्षित करके यह बनाया गया था।

OpenSearch: एक लाइसेंस फोर्क ऑपरेटर को क्या कीमत चुकाने पर मजबूर करता है

Elastic ने 14 January 2021 को घोषणा की कि Elasticsearch और Kibana, release 7.11 से Apache 2.0 को छोड़कर SSPL या Elastic License के विकल्प पर चले जाएंगे। Version 7.10.2 अंतिम Apache 2.0 release था। लगभग एक सप्ताह बाद AWS ने कहा कि वह दोनों का एक Apache 2.0 फोर्क बनाएगा और उसे maintain करेगा। 12 April 2021 को इस फोर्क का नाम OpenSearch रखा गया और Kibana का नाम बदलकर OpenSearch Dashboards कर दिया गया। OpenSearch 1.0, 12 July 2021 को सामान्य रूप से उपलब्ध (generally available) हुआ, जिसे Elasticsearch 7.10.2 और Kibana 7.10.2 से बनाया गया था।

देखें कि क्लस्टर चलाने वाले लोगों को इसकी क्या कीमत चुकानी पड़ी। Package के नाम और repositories बदल गए। Runbook में Kibana का हर संदर्भ OpenSearch Dashboards बन गया। Plugin के नाम बदल गए। फिर यह विभाजन application code तक पहुँच गया: Elastic की आधिकारिक client libraries के version 7.13 से, client यह जाँचता है कि वह किससे connected है और यदि वह Elasticsearch नहीं है, तो आगे बढ़ने से मना कर देता है, और यह रिपोर्ट करता है कि सर्वर एक अज्ञात product है। जिस कंपनी में आप काम नहीं करते, वहाँ लिया गया एक लाइसेंस का निर्णय आपकी अपनी application के भीतर एक failing call के रूप में सामने आया।

यह कहानी फिर दो बार और बदली। Elastic ने 29 August 2024 को AGPLv3 को तीसरे लाइसेंस विकल्प के रूप में जोड़ा, इसलिए वर्तमान Elasticsearch फिर से OSI-approved open source है। 16 September 2024 को, AWS ने OpenSearch को Linux Foundation द्वारा होस्ट की गई OpenSearch Software Foundation को स्थानांतरित कर दिया, जिसने इस फोर्क को एक ऐसा governance home दिया जो किसी एक कंपनी का नहीं है। विभाजन के पांच साल बाद दोनों projects open source हैं, दोनों maintain किए जाते हैं, और August 2026 तक OpenSearch अपनी 3.x series पर है।

इसका अंत ही सबक है। लाइसेंस वापस आ गया और फोर्क बना रहा। एक बार जब किसी ecosystem में हर चीज के दो संस्करण हो जाते हैं, तो कागजी कार्रवाई को पलटने से वे फिर से एक नहीं होते।

वह संख्या जो यह तय करती है कि relicensing से कितना नुकसान होता है, वह घोषणा और एक स्थिर फोर्क के बीच का अंतर है जिसे आप वास्तव में deploy कर सकते हैं।

[
  {
    "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 की सार्वजनिक घोषणा से लेकर फोर्क के पहले स्थिर release तक की जाती है, जिसके लिए नीचे दी गई तारीखों का उपयोग किया गया है। OpenSearch 1.0 में 179 दिन लगे, क्योंकि फोर्क का नाम बदलना पड़ा और उसे फिर से बनाना पड़ा, जबकि नकल करने के लिए कोई पिछला फोर्क उपलब्ध नहीं था। OpenTofu में 153 दिन लगे। Valkey में 27 दिन लगे, क्योंकि इसने Redis 7.2.4 को फोर्क किया और protocol तथा on-disk format को बिल्कुल समान रखा। दिशा ही सबसे महत्वपूर्ण हिस्सा है: एक विश्वसनीय फोर्क अब हफ्तों में आ जाता है, जिसके साथ पहले दिन से ही एक foundation और भुगतान किए गए maintainers जुड़े होते हैं।

Valkey और OpenTofu: वही पैटर्न, अधिक तेज

Redis Ltd ने 20 March 2024 को Redis को 3-clause BSD licence से हटाकर RSALv2 या SSPLv1 के विकल्प पर स्थानांतरित कर दिया। आठ दिन बाद Linux Foundation ने Valkey की घोषणा की, जिसे Redis 7.2.4 से fork किया गया था और जो BSD 3-clause पर ही बना रहा। Valkey 7.2.5 को 16 April 2024 को समान protocol और समान data files के साथ release किया गया, इसलिए अधिकांश operators के लिए migration केवल एक package name बदलने जैसा था। इसके बाद Redis ने May 2025 में Redis 8 में AGPLv3 को तीसरे विकल्प के रूप में जोड़ा, जो इसे OSI परिभाषा के अनुसार फिर से open source बनाता है, जबकि Valkey अपने स्वयं के governance के तहत जारी है। इसका स्वरूप Elasticsearch से काफी मिलता-जुलता है।

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

हर fork की शुरुआत licence से नहीं होती। Forgejo ने 2022 में Gitea से fork किया, जब Gitea का development एक कंपनी के अधीन चला गया; यह licensing के बजाय governance का विवाद था। Forgejo अपने version 8 series तक MIT रहा, फिर 2024 में version 9.0 से GPLv3 या बाद के version पर relicensed हो गया, ताकि इसके काम को व्यावसायिक रूप से नियंत्रित उत्पाद में वापस न खींचा जा सके। यदि आप self-hosted Git server विकल्पों पर विचार कर रहे हैं, तो वह जोड़ी एक codebase और दो दर्शनों का सबसे स्पष्ट जीवंत उदाहरण है।

किसी भी चीज को अपनाने से पहले किया जाने वाला परीक्षण

पहली बार install करने के बाद नहीं, बल्कि उससे पहले ये चार सवाल पूछें।

1. कॉपीराइट किसके पास है? लाइसेंस बदलने के लिए हर कॉपीराइट धारक की अनुमति आवश्यक है, इसलिए जिस प्रोजेक्ट में सैकड़ों स्वतंत्र योगदानकर्ता हों और कोई अधिकार हस्तांतरण (assignment) न हो, उसका लाइसेंस व्यावहारिक रूप से नहीं बदला जा सकता। जिस प्रोजेक्ट का स्वामित्व किसी एक कंपनी के पास हो, उसका लाइसेंस बोर्ड मीटिंग में बदला जा सकता है।
2. क्या कोई CLA है, और यह क्या अधिकार देता है? एक ऐसा कॉन्ट्रिब्यूटर लाइसेंस एग्रीमेंट (CLA) जो कंपनी को आपके योगदान को किसी भी शर्त पर फिर से लाइसेंस देने की अनुमति देता है, वही ऊपर बताए गए हर लाइसेंस परिवर्तन के पीछे का सटीक तंत्र है। DCO (डेवलपर सर्टिफिकेट ऑफ ओरिजिन), जिसे Linux kernel ने 2004 में अपनाया था, कोई अधिकार हस्तांतरित नहीं करता है। किसी फाउंडेशन के पास मौजूद CLA, कंपनी के पास मौजूद CLA से अधिक सुरक्षित है, क्योंकि कंपनी बेची जा सकती है।
3. ट्रेडमार्क का मालिक कौन है? Elastic ने Elasticsearch नाम अपने पास रखा, इसलिए फोर्क (fork) को अपना नाम बदलना पड़ा और Kibana का उल्लेख करने वाली हर रनबुक को फिर से लिखना पड़ा।
4. लाइसेंस बदलने से आपको विशेष रूप से क्या नुकसान होगा? डेटा फॉर्मेट, क्लाइंट लाइब्रेरी, वह कॉन्फ़िगरेशन जिसे आप फिर से लिखेंगे, और यह देखें कि क्या कोई संगत फोर्क पहले से मौजूद है।

दो कमांड्स कुछ ही सेकंड में इसका आंशिक उत्तर दे देती हैं।

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

हर Debian और Ubuntu पैकेज /usr/share/doc/<package>/copyright पर एक फाइल प्रदान करता है, और यह आपके द्वारा इंस्टॉल किए गए वर्जन का लाइसेंस रिकॉर्ड करता है, न कि वह लाइसेंस जो प्रोजेक्ट आज उपयोग करता है। Ubuntu 24.04 पर bash के लिए, वह फाइल GNU General Public License version 3 का नाम बताती है। सोर्स चेकआउट के अंदर दूसरी कमांड चलाएं और आपको लाइसेंस फाइल का इतिहास मिल जाएगा। यदि पिछले दो वर्षों में वहां कोई कमिट (commit) हुआ है, तो किसी भी प्रोजेक्ट पर कुछ भी बनाने से पहले उसे पढ़ना उचित है। यदि कमांड कुछ भी प्रिंट नहीं करती है, तो रिपॉजिटरी ने अपनी लाइसेंस फाइल का नाम कुछ और रखा है, इसलिए रूट डायरेक्टरी को लिस्ट करें और देखें।

कोई भी लाइसेंस आपको हर परिणाम से सुरक्षित नहीं रखता, और विचारधारा के आधार पर चुनाव करने से ही लोग अंत में हैरान रह जाते हैं। उन प्रोजेक्ट्स को प्राथमिकता दें जिनका कॉपीराइट कई हाथों में बंटा हो या किसी फाउंडेशन के पास हो, और अपने डेटा को ऐसे फॉर्मेट में रखें जिसे आप एक्सपोर्ट कर सकें। फिर पता करें कि आप किस फोर्क पर शिफ्ट होंगे, और जरूरत पड़ने से पहले ही उसका नाम लिख लें। प्रत्येक उम्मीदवार पर यह जांच लागू करने में एक घंटे से भी कम समय लगता है, और जब आप 2026 में क्या self host करें का निर्णय ले रहे होते हैं, तो यही चीज अपग्रेड और माइग्रेशन के बीच का अंतर तय करती है।

FAQ

क्या MIT licence और BSD licence एक ही हैं?

व्यावहारिक रूप से, MIT licence और 2-clause BSD licence समान हैं: copyright notice और warranty disclaimer को बनाए रखें, और फिर आप जो चाहें करें, जिसमें closed-source product बनाना भी शामिल है। 3-clause BSD licence में एक अतिरिक्त शर्त है, जो अनुमति के बिना contributors के नामों का उपयोग करके आपके product का समर्थन करने पर रोक लगाती है। पुराने 4-clause version में विज्ञापन सामग्री में उल्लेख (acknowledgement) की भी मांग की गई थी, जिसे UC Berkeley ने 22 July 1999 को हटा दिया था, इसलिए वर्तमान में लगभग कोई भी software इसका उपयोग नहीं करता है।

क्या मैं 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 नहीं किया जा सकता, जो केवल 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 को हटा दिया। आपके लिए इसका मतलब यह है कि जो package आपकी distribution पहले maintain करती थी, वह अब vendor के repository से आता है, और vendor के support schedule पर निर्भर करता है। Business Source License भी open source के बजाय source available है, हालाँकि प्रत्येक release चार वर्षों के भीतर open source licence में बदल जाता है।

क्या licence में बदलाव मेरे द्वारा पहले से चलाए जा रहे version पर लागू होता है?

नहीं। किसी release के साथ दिया गया licence पहले से प्रकाशित copies से वापस नहीं लिया जा सकता है, और यही कारण है कि forks संभव हैं। OpenSearch को Elasticsearch 7.10.2 से बनाया गया था, जो Elastic द्वारा Apache 2.0 के तहत प्रकाशित अंतिम release था। आप भविष्य खो देते हैं, क्योंकि अगला security fix नई शर्तों के तहत आता है। permissively licensed अंतिम version को pin करने से आपको कुछ महीनों का समय मिल सकता है, लेकिन यह कोई दीर्घकालिक योजना नहीं है।