07 नव॰ 2025·8 मिनट
रिचर्ड स्टालमैन और मुक्त सॉफ़्टवेयर: विचार जिन्होंने कोड बदल दिया
रिचर्ड स्टालमैन की मुक्त सॉफ़्टवेयर फ़िलॉसफी, GNU परियोजना और GPL की व्याख्या—और कैसे इनने लाइसेंसिंग, डेवलपर अधिकार और ओपन‑सोर्स प्रथाओं को बदल दिया।
रिचर्ड स्टालमैन की मुक्त सॉफ़्टवेयर फ़िलॉसफी, GNU परियोजना और GPL की व्याख्या—और कैसे इनने लाइसेंसिंग, डेवलपर अधिकार और ओपन‑सोर्स प्रथाओं को बदल दिया।
सॉफ़्टवेयर सिर्फ़ तकनीकी उत्पाद नहीं है—यह अनुमतियों का भी एक सेट है। कौन इसे चला सकता है, कॉपी कर सकता है, किसी मित्र के साथ साझा कर सकता है, बग ठीक कर सकता है, या उसके ऊपर कुछ नया बना सकता है? ये सवाल कोड से कम और लाइसेंसिंग से अधिक तय होते हैं। जैसे-जैसे सॉफ़्टवेयर काम, संचार और शोध का केंद्र बनता गया, "आप क्या कर सकते हैं" के नियम नवाचार को उतना ही आकार देने लगे जितना कि फीचर।
रिचर्ड स्टालमैन (अक्सर "RMS") मायने इसलिए रखते हैं क्योंकि उन्होंने उन नियमों को अनदेखा करना असंभव बना दिया। 1980 के दशक की शुरुआत में उन्होंने एक बदलाव देखा: अधिक प्रोग्राम स्रोत कोड के बिना वितरित किए जा रहे थे, और उपयोगकर्ताओं को बार‑बार बताया जा रहा था कि वे सॉफ़्टवेयर को केवल किसी और की शर्तों पर ही उपयोग कर सकते हैं। स्टालमैन ने इसे एक मामूली असुविधा नहीं, बल्कि उपयोगकर्ता और डेवलपर की स्वतंत्रता का नुकसान बताया—और उन्होंने उन स्वतंत्रताओं की रक्षा के लिए स्पष्ट सिद्धांत और कानूनी उपकरण प्रस्तावित करके जवाब दिया।
यह लेख स्टालमैन के विचारों और उनके व्यावहारिक परिणामों पर केंद्रित है: मुक्त सॉफ़्टवेयर की परिभाषा, GNU परियोजना, कॉपिलेट, और GNU जनरल पब्लिक लाइसेंस (GPL)—और इनका आधुनिक ओपन‑सोर्स पारिस्थितिकी और सॉफ़्टवेयर लाइसेंसिंग मानदंडों पर क्या असर रहा।
यह कोई जीवनचरित्र नहीं है, और न ही यह कर्नेल कंपाइल करना या रिपोजिटरी मैनेज करना जैसा तकनीकी गहरा गोता है। इसे समझने के लिए आपको प्रोग्रामिंग का बैकग्राउंड होने की आवश्यकता नहीं है।
स्टालमैन प्रभावशाली हैं और साथ ही विवादास्पद भी। यहाँ लक्ष्य तथ्यों और पठनीयता पर टिके रहना है: उन्होंने क्या तर्क दिया, कौन‑से कानूनी उपकरण उभरे, व्यवसाय और डेवलपर्स ने कैसे अनुकूलित किया, और आज भी कहां विवाद जारी हैं—ताकि आप देख सकें कि उनका काम रोज़मर्रा के सॉफ़्टवेयर चुनावों को क्यों प्रभावित करता है।
“मुक्त सॉफ़्टवेयर” को समझना आसान नहीं है क्योंकि शब्द मुक्त/फ्री कीमत के अर्थ जैसा लगता है। रिचर्ड स्टालमैन ने फ्री का मतलब स्वतंत्रता लिया—उपयोगकर्ता की उस क्षमता से कि वे अपने भरोसेमंद सॉफ़्टवेयर को नियंत्रित कर सकें।
अगर कोई प्रोग्राम $0 का है पर आपको उसे निरीक्षित करने, बदलने, या साझा करने की अनुमति नहीं है, तो वह "फ्री इन देंसिटी" हो सकता है पर स्टालमैन के मायने में वह अनफ्री है।
मुक्त सॉफ़्टवेयर को चार बुनियादी अनुमतियों से परिभाषित किया जाता है:
ये स्वतंत्रताएँ एजेंसी के बारे में हैं: आप केवल उपकरण के उपभोक्ता नहीं हैं—आप एक प्रतिभागी बन सकते हैं जो सत्यापित, अनुकूलित, और बेहतर कर सकता है।
Freedom 1 और 3 बिना स्रोत कोड (human‑readable निर्देश) के असंभव हैं। इसके बिना सॉफ़्टवेयर एक सील्ड एप्लायंस जैसा हो जाता है: आप उसे चला सकते हैं, पर यह नहीं जान सकते कि वह क्या कर रहा है, उसे ठीक नहीं कर सकते, और न ही नई ज़रूरतों के लिए अनुकूलित कर सकते हैं।
स्रोत कोड एक्सेस भरोसे के लिए भी महत्वपूर्ण है। यह स्वतंत्र समीक्षा को सक्षम बनाता है (गोपनीयता, सुरक्षा, और निष्पक्षता के लिए) और यह संभव बनाता है कि अगर मूल डेवलपर समर्थन बंद कर दे तो भी सॉफ़्टवेयर मेंटेन किया जा सके।
एक रेस्तरां के भोजन के बारे में सोचें।
यही मूल विचार है: मुक्त सॉफ़्टवेयर उन स्वतंत्रताओं के बारे में है जिनकी ज़रूरत उपयोगकर्ताओं को अपने कंप्यूटिंग पर नियंत्रण बनाए रखने के लिए होती है।
जब "सॉफ़्टवेयर लाइसेंसिंग" अधिकतर लोगों के लिए बहस का विषय नहीं था, तब बहुत सी प्रोग्रामिंग संस्कृति — विशेषकर विश्वविद्यालयों और रिसर्च लैब्स में — एक अनुमान पर चलती थी: अगर आप किसी टूल को सुधार सकते हैं, तो आप वह सुधार साझा करते थे। स्रोत कोड सॉफ़्टवेयर के साथ यात्रा करता था, लोग एक-दूसरे के काम पढ़कर सीखते थे, और फिक्स अनौपचारिक सहयोग के जरिए फैलते थे।
जैसे-जैसे सॉफ़्टवेयर एक उत्पाद बनकर उभरा, यह संस्कृति बदलने लगी। कंपनियों (और कुछ संस्थानों) ने स्रोत कोड को प्रतिस्पर्धात्मक लाभ मानना शुरू कर दिया। वितरण "कोई शेयरिंग नहीं" शर्तों के साथ आने लगा, प्रोग्राम्स के साथ कोड भेजना बंद हुआ, और गोपनियत समझौते सामान्य हो गए। जो डेवलपर्स सामूहिक रूप से समस्याएँ हल करने के आदी थे, उनके लिए यह बदलाव सिर्फ असुविधाजनक नहीं था—यह एक नियम परिवर्तन जैसा था जो समुदाय‑आधारित समस्या‑सुलझाने को कानूनी रूप से जोखिम भरा बना देता था।
सबसे अधिक दोहराई जाने वाली उत्पत्ति कहानियों में से एक MIT के AI लैब का प्रिंटर है। स्टालमैन ने बताया है कि कैसे एक नया प्रिंटर आया जिस सॉफ़्टवेयर को केवल बाइनरी रूप में वितरित किया गया था, बिना स्रोत के। व्यावहारिक समस्या दिन‑प्रतिदिन की थी: लैब चाहती थी कि प्रोग्राम जाम पर उपयोगकर्ताओं को सूचना दे या जॉब्स को बेहतर तरीके से रूट करे। पुराने "हैकर" मानदंडों के तहत कोई कोड पैच करके फिक्स साझा कर देता। यहाँ वे नहीं कर सकते थे—क्योंकि वे स्रोत नहीं देख सकते थे और न ही बदल सकते थे।
यह याद रखने योग्य है कि यह एक अकेला प्रिंटर वैश्विक आंदोलन का कारण नहीं बना—बल्कि यह उस व्यापक प्रवृत्ति का एक स्पष्ट, संबंधित उदाहरण था: जिन उपकरणों पर लोग निर्भर थे वे उपयोगकर्ताओं द्वारा फिक्स नहीं किए जा सकते थे।
स्टालमैन के लिए मूल मुद्दा केवल तकनीकी पहुँच नहीं था; यह सहयोग की स्वतंत्रता का नुकसान था। अगर आप किसी प्रोग्राम को कैसे काम करता है नहीं पढ़ सकते, तो आप उस पर वास्तव में नियंत्रण नहीं कर सकते। अगर आप सुधार साझा नहीं कर सकते, तो समुदाय बिखर जाता है और हर कोई निजी रूप से समाधान दोहराने लगता है।
इस प्रेरणा ने आगे आने वाली लाइसेंसिंग नवाचारों को आकार दिया। भलाई या अनौपचारिक मानदंडों पर भरोसा करने के बजाय, स्टालमैन चाहत थे कि ऐसे नियम हों जो उपयोग, अध्ययन, परिवर्तन, और साझा करने की क्षमता को सुरक्षित रखें—ताकि सहयोग उस वक्त भी जारी रहे जब कोई प्रोग्राम वाणिज्यिक रूप से मूल्यवान बन जाए।
स्टालमैन का बड़ा कदम केवल एक मैनिफेस्टो लिखना नहीं था—उन्होंने एक व्यावहारिक इंजीनियरिंग प्रयास शुरू किया। 1983 में उन्होंने GNU परियोजना की घोषणा की, लक्ष्य स्पष्ट था: एक पूरा ऑपरेटिंग सिस्टम बनाना जिसे कोई भी उपयोग कर सके, पढ़ सके, संशोधित कर सके, और साझा कर सके, साथ ही यह Unix के साथ संगत भी हो ताकि लोग परिचित प्रोग्राम और वर्कफ़्लोज़ चला सकें।
एक ऑपरेटिंग सिस्टम एक प्रोग्राम नहीं होता—यह एक पूरा स्टैक होता है। GNU ने रोज़मर्रा के उन सभी हिस्सों को बनाना शुरू किया जो कंप्यूटर को उपयोगी बनाते हैं, जिनमें शामिल हैं:
साधारण शब्दों में: GNU पाइपिंग, वायरिंग, और स्विचेस बना रहा था—केवल एक अप्लायंस नहीं।
1990 के दशक की शुरुआत तक GNU ने इस “यूज़रलैंड” का बड़ा हिस्सा बना दिया था, पर एक महत्वपूर्ण टुकड़ा पीछे रह गया: कर्नेल (है वह हिस्सा जो हार्डवेयर और सिस्टम रिसोर्सेज़ को सीधे मैनेज करता है)। जब Linux 1991 में आया, तो उसने उस गैप को पूरक किया।
इसीलिए आज बहुत से लोकप्रिय सिस्टम GNU कंपोनेंट्स और Linux कर्नेल का संयोजन होते हैं—अक्सर इसे “GNU/Linux” कहा जाता है।
GNU ने मुक्त सॉफ़्टवेयर विचार को वास्तविक बनाया क्योंकि उसने एक काम करने वाला आधार दिया जिस पर अन्य लोग निर्माण कर सकते थे। दर्शन ने बताया कि क्यों स्वतंत्रता मायने रखती है; GNU ने वे टूल दिए जिन्होंने स्वतंत्रता को व्यवहारिक, दोहराने योग्य, और स्केल करने योग्य बनाया।
कॉपिलेट एक लाइसेंसिंग रणनीति है जिसका उद्देश्य सॉफ़्टवेयर को सिर्फ़ पहली रिलीज़ तक ही नहीं बल्कि भविष्य के संस्करणों में भी मुफ़्त रखना है। अगर आपको कॉपिलेटेड कोड मिलता है, तो आप उसे उपयोग कर सकते हैं, पढ़ और बदल सकते हैं, और साझा भी कर सकते हैं—पर जब आप अपना संशोधित संस्करण वितरित करते हैं, तो आपको दूसरों को वही स्वतंत्रताएँ देनी होंगी।
कॉपिलेट ऐसा लगता है जैसे "एंटी‑कॉपीराइट" हो, पर यह वास्तव में कॉपीराइट कानून पर निर्भर है। लेखक अपने कॉपीराइट का उपयोग करके लाइसेंस में अनुमति नियमों को सेट करता है: "आप इसे कॉपी और संशोधित कर सकते हैं, पर अगर आप इसका पुनर्वितरण करते हैं तो आपको इसे उसी लाइसेंस के अंतर्गत रखना होगा।" बिना कॉपीराइट के, उन शर्तों को लागू करने का कानूनी तंत्र नहीं होता।
इसे कोड का अनुसरण करने वाला नियम समझें:
लक्ष्य वह पैटर्न रोकना है जिसका स्टालमैन ने चिंता जताई: कोई समुदाय का काम लेकर उसमें सुधार करे और फिर उन सुधारों को लॉक करके रख ले।
परमीसिव लाइसेंस (जैसे MIT या BSD) सामान्यत: आपको कोड के साथ लगभग कुछ भी करने देते हैं, जिसमें संशोधित संस्करणों को क्लोज्ड‑सोर्स लाइसेंस के तहत पुनर्वितरित करना भी शामिल है। कॉपिलेट लाइसेंस (जैसे GNU GPL) उपयोग और संशोधन की बड़ी स्वतंत्रताएँ रखते हैं, पर वे यह भी मांग करते हैं कि पुनर्वितरित व्युत्पन्न रचनाएँ उसी कॉपिलेट शर्तों के तहत रहें—ताकि downstream में आज़ादी बनी रहे।
GNU General Public License (GPL) ने सॉफ़्टवेयर लाइसेंसिंग को बदल दिया क्योंकि उसने “शेयरिंग” को एक लागू‑होने वाला नियम बना दिया, सिर्फ़ एक अच्छा इरादा नहीं। GPL से पहले, आप स्रोत कोड पाकर उसे सुधार कर एक बंद संस्करण भेज सकते थे जिसे उपयोगकर्ता पढ़ या संशोधित नहीं कर पाते थे। GPL ने उस गतिशीलता को उलटा: उसने पुनर्वितरण पर शर्तें लगाकर उपयोगकर्ताओं की स्वतंत्रताओं की रक्षा की।
व्यवहारिक स्तर पर, GPL उपयोगकर्ताओं को किसी भी उद्देश्य के लिए प्रोग्राम चलाने, स्रोत पढ़ने और संशोधित करने, और मूल या संशोधित संस्करण साझा करने का अधिकार देता है।
अगर आप GPL सॉफ़्टवेयर को वितरित करते हैं (विशेषकर किसी उत्पाद में), तो आपको वे समान स्वतंत्रताएँ आगे भी देनी होंगी। इसका मतलब आम तौर पर:
GPL के दायित्व मुख्य रूप से तब ट्रिगर करते हैं जब आप सॉफ़्टवेयर दूसरों को वितरित करते हैं—बाइनरी भेजना, डिवाइसेज़ के साथ सॉफ़्टवेयर बेचना, या ग्राहकों को कॉपी देना। अगर आप GPL कोड को निजी आंतरिक उपयोग के लिए बदलते हैं और इसे वितरित नहीं करते, तो आम तौर पर आपको स्रोत प्रकाशित करने की आवश्यकता नहीं होती।
कानूनी सिद्धांत की ज़रूरत नहीं है कि सार समझ में आ जाए: अगर आपका प्रोग्राम GPL कोड को ऐसा तरीके से शामिल करता है कि एक संयुक्त वर्क बनता है (उदाहरण के लिए, उसे अपने एप्लिकेशन में लिंक करना), तो अक्सर परिणाम को डेरिवेटिव वर्क माना जाता है और इसे GPL के अधीन वितरित किया जाना चाहिए। किसी GPL प्रोग्राम को सिर्फ़ चलाना, या मानक इंटरफेस पर अलग प्रक्रिया के रूप में उससे बात करना अक्सर अलग माना जाता है।
GPLv2 क्लासिक और व्यापक रूप से उपयोग किया गया है। GPLv3 पेटेंट सौदों और टिवोइज़ेशन के खिलाफ सुरक्षा जोड़ता है। LGPL लाइब्रेरीज़ के लिए डिज़ाइन किया गया है: यह कुछ शर्तों के तहत proprietary प्रोग्राम्स द्वारा लिंक करने की अनुमति देता है जबकि स्वयं लाइब्रेरी को मुक्त रखता है।
मुक्त लाइसेंस (खासकर GNU GPL) केवल “शेयर करने” की अनुमति नहीं देते—वे उपयोग, अध्ययन, संशोधन और पुनर्वितरण के अधिकारों की रक्षा करते हैं जिसे बाद में वापस लेना कठिन होता है। डेवलपर्स के लिए इसका अर्थ है कि आपके सुधार समुदाय के लिए समान शर्तों के तहत उपलब्ध रह सकते हैं, बजाय इसके कि कोई उन्हें बंद उत्पाद में समाहित कर दे और समुदाय के पास पहुंच न रहे।
GPL के तहत आप कर सकते हैं:
इसीलिए GPL को अक्सर “लागू करने योग्य पारस्परिकता” कहा जाता है। अगर कोई GPL‑कवर प्रोग्राम (या डेरिवेटिव) वितरित करता है, तो वह नीचे के उपयोगकर्ताओं पर ऐसे प्रतिबंध नहीं जोड़ सकता जो उनके संशोधनों और साझा करने की क्षमता को रोक दें।
जब आप सॉफ़्टवेयर वितरित करते हैं तो उन अधिकारों के साथ कर्तव्य आते हैं:
ये ज़िम्मेदारियाँ "गोट्चा" नहीं हैं—ये वही तंत्र हैं जो सहयोग को एकतरफा शोषण बनने से रोकते हैं।
टीमों को लाइसेंस अनुपालन को रिलीज़ हाइजीन जैसा मानना चाहिए। ट्रैक करें:
एक साधारण Software Bill of Materials (SBOM) और रिलीज़ के लिए दोहराने योग्य चेकलिस्ट अधिकतर समस्याओं को कानूनी तक पहुंचने से पहले ही रोक सकती है।
कोड के स्तर पर, “मुक्त सॉफ़्टवेयर” और “ओपन सोर्स” अक्सर कई एक जैसे प्रोजेक्ट्स को निरूपित करते हैं। फर्क मुख्य रूप से इस बात पर है कि साझा करना क्यों मायने रखता है।
Free Software मूवमेंट (रिचर्ड स्टालमैन और Free Software Foundation से जुड़ा) सॉफ़्टवेयर स्वतंत्रता को एक नैतिक मुद्दा मानता है: उपयोगकर्ताओं को सॉफ़्टवेयर चलाने, पढ़ने, बदलने, और साझा करने का अधिकार होना चाहिए। उद्देश्य सिर्फ़ बेहतर इंजीनियरिंग नहीं—उद्देश्य उपयोगकर्ता‑स्वायत्तता की रक्षा है।
Open Source दृष्टिकोण व्यावहारिक परिणामों पर जोर देता है: बेहतर सहयोग, तेज़ इटरैशन, कम बग, और पारदर्शिता के जरिए सुरक्षा में सुधार। यह बिना नैतिक दावे के यह बताने में सहज है कि खुलेपन एक बेहतर विकास मॉडल है।
1998 में Open Source Initiative (OSI) ने “open source” शब्द को लोकप्रिय बनाया ताकि विचार व्यवसाय‑अनुकूल लगे। “Free software” अक्सर मूल्यहीन (zero cost) के रूप में गलत समझा जाता था, और कुछ कंपनियाँ अधिकार‑और‑न्याय के framed संदेश से हिचकती थीं। “Open source” ने संगठनों को एक ऐसा तरीका दिया कि वे कह सकें “हम इस तरह काम कर सकते हैं” बिना बहुत आदर्शवाद दिखाए।
कई प्रोजेक्ट जो खुद को open source कहते हैं GNU GPL या दूसरे copyleft लाइसेंस का उपयोग करते हैं, जबकि अन्य परमीसिव लाइसेंस जैसे MIT या Apache चुनते हैं। कानूनी टेक्स्ट समान हो सकता है; योगदानकर्ताओं, उपयोगकर्ताओं, और ग्राहकों को दिया गया कथानक बदल जाता है। एक संदेश है “यह आपकी स्वतंत्रता की रक्षा करता है,” दूसरा है “यह गोद लेना आसान बनाता है और गुणवत्ता बढ़ाता है।”
मुक्त सॉफ़्टवेयर का मतलब "किसी को पैसे नहीं मिलता" नहीं है। यह उपयोगकर्ताओं के अधिकारों के बारे में है। कई कंपनियाँ इस स्वतंत्रता के इर्द‑गिर्द स्वस्थ राजस्व बनाती हैं—अक्सर उन चीज़ों के लिए चार्ज करके जिनमें संस्थाओं को कठिनाई होती है: विश्वसनीयता, जवाबदेही, और समय।
कई सामान्य, सिद्ध मॉडल:
एक आधुनिक मोड़ मैनेज्ड‑ऑफरिंग मॉडल का उभार है—ऐसी प्लेटफ़ॉर्म्स जो तेजी से एप्लिकेशन जनरेट और रन करते हैं। उदाहरण के लिए, Koder.ai एक वाइब‑कोडिंग प्लेटफ़ॉर्म है जो टीमों को चैट के जरिए वेब, बैकएंड और मोबाइल ऐप्स बनाने में मदद करता है—जबकि सोर्स‑कोड एक्सपोर्ट का समर्थन भी करता है। यह संयोजन (तेज़ इटरैशन + कोड स्वामित्व) सॉफ़्टवेयर स्वतंत्रता के सिद्धांतों के साथ मेल खाता है: जब ज़रूरत हो आप अपने सॉफ़्टवेयर का निरीक्षण, बदल और स्थानांतरित कर सकें।
लाइसेंस का चुनाव यह आकार दे सकता है कि मूल्य कौन कैप्चर करता है:
“कमर्शियल” बताता है कैसे बेचा जाता है; “मुक्त सॉफ़्टवेयर” बताता है उपयोगकर्ता का अधिकार क्या है। एक कंपनी मुफ्त सॉफ़्टवेयर बेच सकती है, समर्थन के लिए चार्ज कर सकती है, और फिर भी सॉफ़्टवेयर स्वतंत्रता का सम्मान कर सकती है।
किसी FOSS प्रोजेक्ट को अपनाने या उस पर किसी उत्पाद को दांव लगाने से पहले पूछें:
GPL और "FOSS" पर बहुत चर्चा होती है, पर कुछ आवर्ती मिथक टीमों के लिए भ्रम पैदा करते हैं जो सिर्फ़ कोई उत्पाद शिप करना चाहते हैं बिना गलती से लाइसेंस तोड़ें।
यह नहीं है। पब्लिक डोमेन का मतलब है कि कोई कॉपीराइट मालिक नहीं है जो शर्तें लागू करे—कोई भी बिना बाध्यता के काम को फिर से उपयोग कर सकता है।
GNU GPL बिल्कुल "नो‑स्ट्रिंग्स‑अटैच्ड" नहीं है। लेखक कॉपीराइट रखता है और व्यापक अनुमति देता है—पर केवल अगर आप GPL की शर्तों का पालन करते हैं (सबसे प्रमुख रूप से, कवर किए गए बाइनरी वितरित करने पर स्रोत साझा करना)।
कोड को दिखाई देना सुरक्षा में मदद कर सकता है, पर यह गारंटी नहीं है। एक प्रोजेक्ट ओपन सोर्स हो सकता है और फिर भी:
सुरक्षा सक्रिय मेंटेनेंस, ऑडिट, जिम्मेदार खुलासा, और अच्छे ऑपरेशनल प्रैक्टिस से आती है—न कि केवल लाइसेंस लेबल से।
लोग अक्सर GPL को "वायरल" कहते हैं जैसे कि यह अनियंत्रित रूप से सब में फैल जाए। यह एक भारित रूपक है।
यह आमतौर पर कॉपिलेट को संदर्भित करता है: अगर आप GPL कोड का डेरिवेटिव वर्क वितरित करते हैं तो आपको संबंधित स्रोत उसी GPL के तहत देना होगा। यह इच्छा के अनुसार है: यह उपयोगकर्ताओं की स्वतंत्रताओं को downstream में सुरक्षित रखता है। यह "इन्फेक्शन" नहीं है; यह एक शर्त है जिसे आप स्वीकार कर सकते हैं—या अलग कोड चुनकर उससे बच सकते हैं।
नियम पुस्तक का सार: दायित्व मुख्यतः वितरण पर ट्रिगर होते हैं।
जब यह मायने रखता है, तो कोड कैसे मिलाया गया और कैसे वितरित किया गया है, इसकी सटीक जाँच करवानी चाहिए—सिर्फ़ अनुमान पर भरोसा न करें।
रिचर्ड स्टालमैन एक विवादास्पद शख्स हैं। यह स्वीकार करना संभव है—और फिर भी उनके विचारों और उनसे जुड़े लाइसेंसों के स्थायी प्रभाव पर स्पष्ट रूप से बात की जा सकती है।
एक उपयोगी शुरुआत यह है कि दो बातचीतों को अलग रखा जाए: (1) स्टालमैन एक व्यक्ति और समुदाय सदस्य के रूप में—उसके बारे में बहसें; और (2) मुक्त सॉफ़्टवेयर सिद्धांतों, GNU परियोजना, और GNU GPL के मापने योग्य प्रभाव—ऐसे प्रभाव जिन्हें लाइसेंस टेक्स्ट, प्रोजेक्ट इतिहास, और गोद लेने के पैटर्न जैसे प्राथमिक स्रोतों से चर्चा की जा सकती है। दूसरा पक्ष तब भी विशिष्ट तथ्यों से आंका जा सकता है जब लोग पहले वाले पर अलग‑अलग राय रखते हों।
एक आवर्ती आलोचना लाइसेंसिंग के बारे में नहीं है, बल्कि शासन के बारे में है: प्रोजेक्ट कैसे निर्णय लेते हैं, किसके पास अधिकार है, और क्या होता है जब संस्थापक, मेंटेनर, और उपयोगकर्ता अलग‑अलग चीज़ें चाहते हैं। मुक्त सॉफ़्टवेयर समुदायों ने इन प्रश्नों से जूझा है जैसे:
ये प्रश्न मायने रखते हैं क्योंकि लाइसेंस कानूनी शर्तें तय करते हैं, पर वे स्वस्थ निर्णय‑प्रक्रिया स्वयं नहीं बनाते।
एक और चलती बहस समावेशन और समुदाय मानकों पर है: प्रोजेक्ट्स कैसे सम्मानजनक व्यवहार की उम्मीद रखते हैं, संघर्ष कैसे सुलझाते हैं, और नए लोगों के लिए कितने स्वागतयोग्य हैं। कुछ समुदाय औपचारिक कोड‑ऑफ‑कंडक्ट पर ज़ोर देते हैं; अन्य न्यूनतम नियम और अनौपचारिक मॉडरेशन पसंद करते हैं। कोई भी तरीका स्वतः ही "सही" नहीं है, पर ट्रेड‑ऑफ वास्तविक हैं और व्यक्तिगत हमलों के बिना पर चर्चा के योग्य हैं।
अगर आप स्टालमैन की विरासत का मूल्यांकन कर रहे हैं, तो दावों को सत्यापनीय रखें: GPL क्या माँगता है, कॉपिलेट ने अनुपालन प्रथाओं को कैसे बदला, और इन विचारों ने बाद के लाइसेंसों और संस्थाओं को कैसे प्रभावित किया। आप आलोचक हो सकते हैं, समर्थक हो सकते हैं, या अनिर्णीत—पर सटीकता, सम्मान, और स्पष्टता बनाए रखें कि किस चीज़ की आलोचना हो रही है।
स्टालमैन का सबसे बड़ा व्यावहारिक उपहार रोज़मर्रा की टीमों को एक स्पष्ट प्रश्न देता है: आप डाउनस्ट्रीम में कौन‑सी स्वतंत्रताएँ गारंटी करना चाहते हैं? इसका उत्तर लाइसेंस चयन को एक आदिवृत्ति से एक निर्णय में बदल देता है।
अगर अनिश्चित हैं, तो उद्देश्य के आधार पर निर्णय लें: गोद लेना (permissive) बनाम पारस्परिकता (copyleft) बनाम लाइब्रेरी‑अनुकूल पारस्परिकता (weak copyleft)।
अगर आप AI‑सहायता प्राप्त विकास (चैट‑आधारित प्लेटफ़ॉर्म जैसे Koder.ai) का उपयोग करते हैं, तो यह चेकलिस्ट और भी अधिक महत्वपूर्ण हो जाती है: आप फिर भी वास्तविक निर्भरतियाँ, वास्तविक आर्टिफैक्ट, और वास्तविक लाइसेंस‑बाध्यताएँ भेजते हैं। गति ज़िम्मेदारी को समाप्त नहीं करती—बल्कि दोहराने योग्य अनुपालन प्रक्रियाओं को और अधिक मूल्यवान बनाती है।
इसे उबाऊ और दोहराने योग्य रखें:
गहरे तुलनों के लिए, देखें /blog/choosing-an-open-source-license और /blog/gpl-vs-mit-vs-apache।
“मुक्त सॉफ़्टवेयर” का मतलब स्वतंत्रता है, कीमत नहीं।
एक प्रोग्राम $0 में मिल सकता है और फिर भी अनमुक्त हो सकता है अगर आप उसे निरीक्षित, संशोधित, या साझा नहीं कर सकते। मुक्त सॉफ़्टवेयर उन अधिकारों — चलाने, पढ़ने, बदलने और पुनर्वितरित करने — पर केंद्रित है जो उपयोगकर्ता को अपने सॉफ़्टवेयर पर नियंत्रण देते हैं।
परिभाषा चार अनुमतियों पर आधारित है:
अगर इनमें से कोई भी गायब है, उपयोगकर्ता का नियंत्रण घटता है और सहयोग कठिन हो जाता है।
क्योंकि आप बिना स्रोत कोड के वास्तविक रूप से सॉफ़्टवेयर का अध्ययन या संशोधन नहीं कर सकते।
स्रोत कोड एक्सेस से मिलते हैं:
कॉपिलेट कॉपीराइट कानून का उपयोग करके redistribution पर “एक जैसा साझा करें” की शर्त लगाता है।
आप सॉफ़्टवेयर का उपयोग कर सकते हैं, बदल सकते हैं और बेच भी सकते हैं, लेकिन अगर आप संशोधित संस्करण वितरित करते हैं, तो आपको प्राप्तकर्ताओं को वही स्वतंत्रताएँ देनी होंगी (आमतौर पर उसी लाइसेंस के तहत स्रोत जारी करके)।
GPL उपयोगकर्ताओं को व्यापक अधिकार देता है (चालना, पढ़ना, बदलना, साझा करना) और वितरण पर reciprocity माँगता है।
अगर आप GPL-कवर किए गए बाइनरी को वितरित करते हैं, तो आम तौर पर आपको करना होगा:
अक्सर नहीं。
GPL के लिए दायित्व आम तौर पर वितरण पर ट्रिगर होते हैं। अगर आप GPL कोड को आंतरिक उपयोग के लिए बदलते हैं और उसे अपनी संस्था के बाहर किसी को नहीं देते, तो आप आम तौर पर अपने परिवर्तन प्रकाशित करने के बाध्य नहीं होते।
(कठोर कानूनी सलाह के बजाए इसे सामान्य नियम के रूप में लें—रिश्तेदार केस हो सकते हैं।)
यह इस बात पर निर्भर करता है कि कोड कैसे जोड़ा गया है।
आम तौर पर:
जब यह मायने रखे तो वितरण से पहले सटीक एकीकरण पैटर्न को मैप करें।
वे अलग मुद्दों को लक्षित करते हैं:
यह तय करें कि क्या आप तीव्र reciprocity चाहते हैं (GPL) या लाइब्रेरी‑अनुकूल reciprocity (LGPL)।
आमतौर पर नहीं, GPL के तहत नहीं।
अगर आप GPL सॉफ़्टवेयर को अपने सर्वर पर चला रहे हैं और उपयोगकर्ता केवल नेटवर्क पर इंटरैक्ट कर रहे हैं, तो आम तौर पर आप कॉपी वितरित नहीं कर रहे—इसलिए GPL स्रोत-साझा करने की बाध्यताएँ ट्रिगर नहीं होतीं।
अगर आप चाहते हैं कि नेटवर्क‑इस्तेमाल पर भी स्रोत शेयर करना अनिवार्य हो, तो AGPL देखें और अपने डिप्लॉयमेंट मॉडल के लिए उसे सावधानी से आकलित करें।
हाँ—कई कंपनियाँ मुफ्त/ओपन-सोर्स सॉफ़्टवेयर से कमाती हैं, पर बिक्री का तरीका अलग होता है।
सामान्य मॉडल:
लाइसेंस चुनाव रणनीति को प्रभावित करता है: परमीसिव अपनाने बढ़ा सकता है; copyleft बंद‑फोर्क्स को हतोत्साहित कर सकता है और reciprocity‑आधारित मॉडल का समर्थन कर सकता है।