10.3 खरीद, ओपन सोर्स, और लाइसेंसिंग

अवलोकन और प्रेरणा

लगभग हर आधुनिक सॉफ़्टवेयर सिस्टम अधिकांशतः उन घटकों से इकट्ठा किया गया है जिन्हें किसी और ने लिखा। ओपन-सोर्स सॉफ़्टवेयर ऑपरेटिंग सिस्टम, भाषाओं, फ्रेमवर्क, डेटाबेस, और क्लाउड इन्फ्रास्ट्रक्चर की नींव बनाता है। यह एंटरप्राइज़ में दो तरीकों से प्रवेश करता है: जानबूझकर खरीद के माध्यम से, और व्यक्तिगत डेवलपर के आकस्मिक import स्टेटमेंट के माध्यम से। यह अध्याय उस उपभोग (और, जहाँ यह फिट बैठे, योगदान) को जानबूझकर करने के बारे में है। इसका मतलब है एक रणनीति, लाइसेंस अनुपालन, दायित्वों और कॉपीलेफ़्ट जोखिम की समझ, और आप जिन घटकों पर निर्भर हैं उनके अनिवार्य जीवन-अंत के लिए एक योजना।

बड़ी टीमों के लिए दांव एक साथ कानूनी, परिचालनात्मक, और सामरिक हैं। कानूनी रूप से, ओपन-सोर्स लाइसेंस वास्तविक दायित्वों के साथ लागू करने योग्य अनुबंध हैं। कॉपीलेफ़्ट (लाइसेंसिंग जो डेरिवेटिव कार्यों को उन्हीं शर्तों के तहत साझा करने की माँग कर सकती है) को गलत समझना, सबसे बुरी स्थिति में, मालिकाना स्रोत के प्रकटीकरण को मजबूर कर सकता है या मुकदमेबाज़ी को ट्रिगर कर सकता है। लाइसेंस उल्लंघन ड्यू डिलिजेंस के दौरान एक अधिग्रहण या एक सार्वजनिक पेशकश को भी रोक सकते हैं। परिचालनात्मक रूप से, अप्रबंधित निर्भरताएँ सड़ जाती हैं: घटक अनुरक्षण-रहित हो जाते हैं, भेद्यताएँ जमा करते हैं, और उत्पादन में गहरे दबे रहते हुए ही जीवन के अंत तक पहुँचते हैं। सामरिक रूप से, ओपन सोर्स एक लागत-बचत इनपुट से बढ़कर है। यह लॉक-इन से बचने, प्रतिभा को आकर्षित करने, और उन इकोसिस्टम को आकार देने का एक तरीका है जिन पर आप निर्भर हैं, ऐसे फायदे जो आप तभी पाते हैं जब आप जानबूझकर संलग्न होते हैं।

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

मुख्य सिद्धांत

• ओपन सोर्स एक आपूर्ति-श्रृंखला है, मुफ़्त चीज़ नहीं। उपभोग किए गए घटकों को किसी भी महत्वपूर्ण आपूर्तिकर्ता जितनी ही कठोरता से मानें।
• लाइसेंस दायित्व हैं, अनदेखा करने की अनुमतियाँ नहीं। हर निर्भरता शर्तें रखती है; भेजने से पहले उन्हें जानें।
• कॉपीलेफ़्ट एक डिज़ाइन बाधा है, कोई वर्जना नहीं। कॉपीलेफ़्ट लाइसेंस उपयोगी और मूल्यवान हैं; उन्हें बस इसकी आवश्यकता है कि आप समझें कि आप सॉफ़्टवेयर को कैसे संयोजित और वितरित करते हैं।
• जानबूझकर उपभोग करें, सामरिक रूप से योगदान दें। तय करें कि क्या लाना है और, जहाँ यह आपकी सेवा करे, फोर्क करने की बजाय अपस्ट्रीम में निवेश करें।
• हर चीज़ की सूची बनाएँ। आप वह अनुपालन, सुरक्षित, या अपडेट नहीं कर सकते जिसे आप देख नहीं सकते; एक SBOM (सॉफ़्टवेयर बिल ऑफ़ मटेरियल्स, आपके सॉफ़्टवेयर के घटकों की एक पूरी सूची) बुनियादी आवश्यकता है।
• शुरुआत से ही जीवन-अंत की योजना बनाएँ। हर निर्भरता एक दिन अनुरक्षण-रहित हो जाएगी; इसके लिए मजबूर होने से पहले अपना निकास जानें।
• सरकार में, ओपन को डिफ़ॉल्ट बनाएँ। ओपन स्टैंडर्ड और ओपन सोर्स को प्राथमिकता दें, और पब्लिक-मनी कोड को खुला प्रकाशित करें जब तक कोई विशिष्ट कारण न हो कि ऐसा न करें।

सिफारिशें

एक ओपन-सोर्स रणनीति और उपभोग नीति तय करें

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

लाइसेंस अनुपालन, दायित्वों, और कॉपीलेफ़्ट जोखिम प्रबंधित करें

लाइसेंस परिवारों और उनके दायित्वों को जानें। अनुमेय लाइसेंस (जैसे MIT, BSD, और Apache 2.0) मुख्य रूप से एट्रिब्यूशन और नोटिस संरक्षण की माँग करते हैं; Apache 2.0 एक स्पष्ट पेटेंट अनुदान जोड़ता है। कमज़ोर कॉपीलेफ़्ट (जैसे LGPL और MPL) आपको कवर की गई फ़ाइलों में संशोधन साझा करने की आवश्यकता रखता है लेकिन सामान्यतः आपको मालिकाना कोड के साथ संयोजित करने देता है। मज़बूत कॉपीलेफ़्ट (जैसे GPL) की माँग हो सकती है कि पूरे वितरित कार्य को उन्हीं शर्तों के तहत पेश किया जाए। नेटवर्क कॉपीलेफ़्ट (AGPL) उस दायित्व को नेटवर्क पर पेश किए गए सॉफ़्टवेयर तक विस्तारित करता है, न केवल बाइनरी के रूप में वितरित सॉफ़्टवेयर तक। जो दायित्व सबसे अधिक मायने रखते हैं वे दो चीज़ों पर निर्भर करते हैं: क्या आप सॉफ़्टवेयर वितरित करते हैं, और आप घटकों को कितनी कसकर संयोजित करते हैं। अनुपालन को स्वचालित करें: निर्भरताओं में लाइसेंस के लिए स्कैन करें, आवश्यक एट्रिब्यूशन और नोटिस फ़ाइलें उत्पन्न करें और भेजें, और बिल्ड को नीति पर गेट करें ताकि एक निषिद्ध लाइसेंस चुपचाप उत्पादन में प्रवेश न कर सके।

एक ओपन सोर्स प्रोग्राम ऑफ़िस (OSPO) स्थापित करें

यदि आप पैमाने पर ओपन सोर्स का उपभोग करते हैं, तो एक केंद्र बिंदु बनाएँ, एक OSPO, जो ओपन-सोर्स रणनीति, नीति, अनुपालन टूलिंग, योगदान गवर्नेंस, और समुदाय संबंधों का मालिक हो। OSPO हर टीम के अपने निर्णय लेने की अराजकता को रोकता है। यह वह विशेषज्ञता प्रदान करता है जिसे व्यक्तिगत टीमें बनाए नहीं रख सकतीं। और यह सामरिक मूल्य को कैप्चर करता है: किन परियोजनाओं में निवेश करना है, कब अपस्ट्रीम योगदान देना है, और अपनी खुद की ओपन-सोर्स परियोजनाओं को अच्छी तरह कैसे रिलीज़ करना है, यह तय करना। एक छोटा OSPO भी (कभी-कभी एक व्यक्ति साथ में एक क्रॉस-फंक्शनल कार्य समूह) एक स्वतंत्र-सबके-अपने की तुलना में स्थिरता में नाटकीय रूप से सुधार करता है और कानूनी जोखिम को कम करता है।

योगदान को, और जहाँ उपयुक्त हो, प्रकाशन को गवर्न करें

जानबूझकर तय करें कि कब वापस योगदान देना है। जिन परियोजनाओं पर आप निर्भर हैं उनमें फिक्स और फ़ीचर को अपस्ट्रीम करना आपके रखरखाव बोझ को कम करता है, क्योंकि आप निजी पैच ढोना बंद कर देते हैं। यह सद्भावना और प्रभाव भी बनाता है, और आपके लिए महत्वपूर्ण घटकों को मज़बूत करता है। डेवलपर को स्वीकृत योगदानों के लिए एक स्पष्ट, तेज़ प्रक्रिया दें, जिसमें बौद्धिक संपदा और योगदानकर्ता समझौतों को कैसे संभाला जाता है यह भी शामिल हो। जब आप अपनी खुद की ओपन-सोर्स परियोजनाएँ जारी करते हैं, तो इसे ठीक से करें: एक उपयुक्त लाइसेंस चुनें, गवर्नेंस का दस्तावेज़ीकरण करें, और अनुरक्षण के प्रति प्रतिबद्ध हों। एक छोड़ी गई परियोजना आपकी प्रतिष्ठा को किसी परियोजना न होने से अधिक नुकसान पहुँचाती है।

सरकारी ओपन-सोर्स और “पब्लिक मनी, पब्लिक कोड” आदेशों को पूरा करें

सार्वजनिक-क्षेत्र की टीमों को खुलेपन को डिफ़ॉल्ट के रूप में मानना चाहिए। लॉक-इन से बचने और एजेंसियों और विक्रेताओं के बीच काम करने के लिए ओपन स्टैंडर्ड को प्राथमिकता दें। सार्वजनिक धन से विकसित स्रोत कोड को खुले तौर पर प्रकाशित करें, जब तक कोई विशिष्ट, दस्तावेज़ीकृत छूट लागू न हो: सुरक्षा-संवेदनशील घटकों, तीसरे-पक्ष अधिकारों, या गोपनीयता चिंताओं के लिए। बनाने से पहले पुन: उपयोग करें: जाँचें कि क्या किसी अन्य एजेंसी ने पहले ही उपयुक्त कोड जारी किया है। इन अपेक्षाओं को खरीद में शामिल करें, ताकि विक्रेता खुला, पुन: उपयोग योग्य, अच्छी तरह दस्तावेज़ीकृत कोड दें, सरकार के पास उचित अधिकार रहें, बजाय मालिकाना ब्लैक बॉक्स के जिन्हें एजेंसी बनाए या साझा नहीं कर सकती।

निर्भरताओं और जीवन-अंत सॉफ़्टवेयर का प्रबंधन करें

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

व्यापार-संतुलन: फायदे और नुकसान

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

केंद्रीय तनाव डेवलपर गति और नियंत्रण के बीच है। सब कुछ भारी समीक्षा के पीछे बंद कर दें, और डेवलपर नीति के आसपास रास्ता बना लेते हैं। इससे अप्रबंधित छाया निर्भरताएँ बनती हैं, जो एक अनुमेय-लेकिन-दृश्यमान दृष्टिकोण से बदतर हैं। इसे पूरी तरह अनियंत्रित छोड़ दें, और आप अदृश्य रूप से कानूनी और सुरक्षा ऋण जमा करते हैं। समाधान स्वचालन और क्यूरेशन है: पूर्व-जाँचे गए घटकों, पाइपलाइन स्कैनिंग, और स्पष्ट डिफ़ॉल्ट के माध्यम से अनुपालित मार्ग को सबसे तेज़ मार्ग बनाएँ, ताकि आपको घर्षण के बिना नियंत्रण मिले। कॉपीलेफ़्ट पर, व्यापार-संतुलन “जोखिम भरा बनाम सुरक्षित” नहीं बल्कि “समझा हुआ बनाम नहीं” है। कॉपीलेफ़्ट पूरी तरह उपयोग योग्य है एक बार जब आप जान जाएँ कि आप कैसे संयोजित और वितरित करते हैं।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. आंतरिक, वितरित, और नेटवर्क-सर्व किए गए संदर्भों में मज़बूत और नेटवर्क कॉपीलेफ़्ट के लिए आपका स्पष्ट नियम क्या है? कॉपीलेफ़्ट एक डिज़ाइन बाधा है, कोई वर्जना नहीं, और दायित्व दो चीज़ों पर निर्भर करते हैं: क्या आप सॉफ़्टवेयर वितरित करते हैं और आप घटकों को कितनी कसकर संयोजित करते हैं। एक आंतरिक टूल में GPL आपके भेजे जाने वाले उत्पाद में लिंक किए गए GPL से बहुत अलग व्यवहार करता है, और AGPL प्रकटीकरण कर्तव्यों को उस सॉफ़्टवेयर तक विस्तारित करता है जिसे आप केवल नेटवर्क पर पेश करते हैं, जो आपके बिल्ड-बनाम-अपनाएँ गणना को उस किसी भी चीज़ के लिए बदल देता है जिसे आप एक सेवा के रूप में चलाते हैं। हर संदर्भ के लिए नियम लिखें, ताकि एक डेवलपर बिना वकील को बुलाए जाने कि (उदाहरण के लिए) अनुमेय हर जगह पूर्व-स्वीकृत है, मज़बूत कॉपीलेफ़्ट आंतरिक रूप से ठीक है लेकिन भेजे जाने वाले उत्पाद से अवरुद्ध है, और AGPL को नेटवर्क सेवा को छूने से पहले समीक्षा चाहिए। सबूत लाएँ: अपने वर्तमान निर्भरता वृक्ष को स्कैन करें और खोजें कि कॉपीलेफ़्ट घटक आपकी वितरण सीमा के सापेक्ष पहले से कहाँ बैठे हैं। फिर बिल्ड को उस नीति पर गेट करें, क्योंकि एक नियम जिसे कोई स्कैनर लागू नहीं करता वह नियम है जिसे डेवलपर गलती से तोड़ देंगे।

2. क्या आपको एक ओपन सोर्स प्रोग्राम ऑफ़िस की आवश्यकता है, और आज लाइसेंस नीति, स्कैनिंग, और योगदान निर्णयों का मालिक कौन है? यदि ईमानदार उत्तर “कोई नहीं” या “हर टीम तय करती है” है, तो आप एक स्वतंत्र-सबके-अपने चला रहे हैं जो अदृश्य रूप से कानूनी और सुरक्षा ऋण जमा करता है। एक OSPO, यहाँ तक कि एक व्यक्ति साथ में एक क्रॉस-फंक्शनल कार्य समूह, उस अराजकता को रोकता है और सामरिक मूल्य को कैप्चर करता है: किन अपस्ट्रीम परियोजनाओं में निवेश करना है, कब योगदान देना है, और अपनी खुद की परियोजनाओं को अच्छी तरह कैसे रिलीज़ करना है। बैठक में सबूत लाएँ: क्या कोई वर्तमान स्वीकृत-लाइसेंस सूची, SBOM, और उस व्यक्ति का नाम बना सकता है जो अधिग्रहण ड्यू डिलिजेंस के दौरान एक कॉपीलेफ़्ट प्रश्न को संभालेगा? उत्तर को स्पष्ट स्वामित्व सौंपना चाहिए और पूर्व-जाँचे गए घटकों और पाइपलाइन स्कैनिंग के माध्यम से अनुपालित मार्ग को सबसे तेज़ मार्ग बनाना चाहिए, ताकि डेवलपर को घर्षण के बिना नियंत्रण मिले। कोड कॉपी करने से धीमी नीति को बस नज़रअंदाज़ कर दिया जाएगा।

3. यदि कल कोई निर्भरता छोड़ दी जाए तो कौन सी सबसे अधिक चोट पहुँचाएगी, और हर एक के लिए आपकी पहले से तय प्रतिक्रिया क्या है? हर निर्भरता अंततः जीवन के अंत तक पहुँचती है, और उस घटना का महंगा संस्करण यह खोजना है कि एक मूल घटक ने महीनों पहले समर्थन खो दिया, तभी जब कोई भेद्यता ध्यान मजबूर करे। छोड़े जाने के जोखिम वाले अपने महत्वपूर्ण घटकों के लिए, पहले से तय करें कि क्या आप अनुरक्षक को वित्तपोषित करेंगे, स्वयं रखरखाव में योगदान देंगे, फोर्क करेंगे, या बदलेंगे। सबूत लाएँ: अपने SBOM से, उन घटकों को सूचीबद्ध करें जिनकी विफलता एक राजस्व या मिशन-महत्वपूर्ण सेवा को रोक देगी, और हर एक की रखरखाव स्थिति और सुरक्षा-समर्थन विंडो नोट करें। उत्तर को जीवन-अंत को एक आश्चर्य से एक ट्रैक किए गए परिचालनात्मक जोखिम में बदलना चाहिए जिसमें एक नियोजित प्रवासन हो, जो किसी अन्य जोखिम जैसे ही मानक पर रखा गया हो। निर्भरताओं को छोटे, बार-बार होने वाले कदमों में वर्तमान रखना दुर्लभ, विशाल, मजबूर छलांग से कहीं अधिक सस्ता है।

4. क्या आप एक पूर्ण, वर्तमान SBOM उत्पन्न कर सकते हैं जो आपके ट्रांज़िटिव निर्भरता वृक्ष में पूरी तरह नीचे तक पहुँचे, और कितनी जल्दी? जब कोई सुर्खी भेद्यता किसी व्यापक रूप से उपयोग की जाने वाली लाइब्रेरी में उतरती है, तो नेतृत्व जो पहला प्रश्न पूछता है वह है “क्या हम उजागर हैं, और कहाँ?” एक टीम जो घंटों के भीतर जवाब नहीं दे सकती वह पहले से ही पीछे है, क्योंकि वास्तविक जोखिम आमतौर पर निर्भरताओं में कई परतें नीचे छिपा होता है जिसे किसी ने जानबूझकर नहीं चुना। प्रतिस्पर्धी विचार लागत और शोर है: कई सेवाओं में पूर्ण ट्रांज़िटिव सूची एक बड़ी, उथल-पुथल भरी सूची उत्पन्न करती है, और अति-अलर्टिंग लोगों को इसे नज़रअंदाज़ करना सिखाती है, इसलिए आपको तय करना होगा कि वास्तव में कितनी गहराई और कितनी गंभीरता कार्रवाई को ट्रिगर करती है। चर्चा में सबूत लाएँ: अभी एक उत्पादन सेवा के लिए एक ताज़ा SBOM उत्पन्न करने का प्रयास करें, गिनें कि कितने घटक प्रत्यक्ष बनाम ट्रांज़िटिव हैं, और समय बताएँ कि इसमें कितना समय लगा। एक एंटरप्राइज़ या सरकारी निकाय के लिए, इसे एक ठोस घटना-प्रतिक्रिया लक्ष्य और प्रभावित घटकों को प्रकट करने के किसी भी नियामक कर्तव्य से जोड़ें, क्योंकि उस एक्सपोज़र की रिपोर्ट करने का एक आदेश जिसे आप गिन नहीं सकते वह एक आदेश है जिसे आप तोड़ेंगे।

5. कब एक महत्वपूर्ण निर्भरता को वित्तपोषित करना, उसमें योगदान देना, या उसका स्टीवर्ड बनना मुफ़्त के रूप में मानने के बजाय लायक है? अधिकांश संगठन ओपन सोर्स का उपभोग ऐसे करते हैं जैसे यह एक यूटिलिटी हो, फिर चौंक जाते हैं जब एक राजस्व सेवा को आधार देने वाला घटक एक अवैतनिक स्वयंसेवक निकलता है। जानबूझकर एक अनुरक्षक को वित्तपोषित करने, फिक्स अपस्ट्रीम करने, या अपनी खुद की परियोजना जारी करने और उसका स्टीवर्ड बनने का निर्णय एक नाज़ुक मुफ़्त इनपुट को एक टिकाऊ, प्रभावित इनपुट में बदल देता है, और यह आपके इंजीनियरों को हर अपग्रेड में निजी पैच ढोने से रोकता है। तनाव यह है कि योगदान और स्टीवर्डशिप वास्तविक, निरंतर इंजीनियरिंग समय की लागत उठाते हैं और बौद्धिक-संपदा और प्रक्रिया ओवरहेड रखते हैं, इसलिए आप इसे हर चीज़ के लिए नहीं कर सकते। सबूत लाएँ: अपने SBOM से, उन मुट्ठी भर घटकों को चिह्नित करें जिनकी विफलता एक मिशन-महत्वपूर्ण सेवा को रोक देगी, और हर एक की अनुरक्षक गिनती, वित्तपोषण, और आप पहले से उसके खिलाफ कितने निजी पैच ढो रहे हैं यह नोट करें। एक बड़े या सार्वजनिक संगठन के लिए, एक छोड़ी गई ओपन-सोर्स रिलीज़ की प्रतिष्ठा लागत को तौलें जिसे आपने धूमधाम से प्रकाशित किया था, और, सरकार में, प्रकाशित पब्लिक-मनी कोड की निरंतर स्टीवर्डशिप को डिलीवरी का हिस्सा मानें, वैकल्पिक अतिरिक्त नहीं।

6. क्या आपकी खरीद वास्तव में आपको आवश्यक अधिकारों के साथ खुला, पुन: उपयोग योग्य, अच्छी तरह दस्तावेज़ीकृत कोड देती है, या मालिकाना ब्लैक बॉक्स जिन्हें आप बनाए या छोड़ नहीं सकते? ओपन-सोर्स विशेषज्ञता के बिना लिखे गए अनुबंध नियमित रूप से एक विक्रेता को वह नियंत्रण सौंप देते हैं जिसका आपको पछतावा होगा: बंद फ़ॉर्मैट, प्रकाशित या संशोधित करने का कोई अधिकार नहीं, और निर्भरताएँ जिन्हें एजेंसी तब पैच नहीं कर सकती जब विक्रेता आगे बढ़ जाए। इसे जल्दी ठीक करना नवीनीकरण पर यह खोजने से कहीं अधिक सस्ता है कि आप छोड़ नहीं सकते। प्रतिस्पर्धी विचार गति और विक्रेता चुनाव हैं: खुले डिलिवरेबल और पोर्टेबिलिटी की माँग करना क्षेत्र को संकीर्ण कर सकता है और एक अवार्ड को धीमा कर सकता है, और कुछ वास्तव में उपयोगी आपूर्तिकर्ता इसका विरोध करते हैं। सबूत लाएँ: दो हालिया अनुबंध निकालें और जाँचें कि क्या वे लाइसेंस शर्तें, स्रोत-कोड डिलीवरी, दस्तावेज़ीकरण मानक, SBOM प्रावधान, और संगठन द्वारा रखे गए अधिकार निर्दिष्ट करते हैं। एंटरप्राइज़ खरीद के लिए, इसे लॉक-इन और कुल-लागत विश्लेषण से जोड़ें; सरकार के लिए, इसे डिफ़ॉल्ट-रूप-से-खुला और “पब्लिक मनी, पब्लिक कोड” आदेशों से, और उस दस्तावेज़ीकृत-छूट प्रक्रिया से जोड़ें जो आपको केवल सुरक्षा-संवेदनशील हिस्सों को बंद करने देती है, पूरे सिस्टम को नहीं।

क्षेत्रीय दृष्टिकोण

स्टार्टअप। आप लगभग हर चीज़ ओपन सोर्स से इकट्ठा करते हैं और आपके पास कोई वकील नहीं है, इसलिए नियम को एक पृष्ठ तक रखें: MIT और Apache 2.0 जैसे अनुमेय लाइसेंस पूर्व-स्वीकृत हैं, मज़बूत कॉपीलेफ़्ट आंतरिक टूलिंग के लिए ठीक है लेकिन भेजे जाने वाले उत्पाद से अवरुद्ध है, और कुछ भी अजीब एक त्वरित संस्थापक समीक्षा पाता है। पाइपलाइन में एक लाइसेंस और भेद्यता स्कैन जोड़ें और पहले दिन से एक SBOM रखें, क्योंकि इसे ठीक करने का सबसे सस्ता क्षण किसी अधिग्रहणकर्ता के ड्यू डिलिजेंस से पहले है जो आपके निर्भरता वृक्ष को खंगालेगा। डर के कारण कॉपीलेफ़्ट को प्रतिबंधित न करें; इसे समझें, और आगे बढ़ें।

छोटा व्यवसाय। किसी ओपन-सोर्स विशेषज्ञ और तंग बजट के बिना, हेडकाउंट की बजाय टूलिंग पर निर्भर रहें: बिल्ड में एक स्कैनर और एक छोटी स्वीकृत-लाइसेंस सूची वह अधिकांश काम करती है जो एक व्यक्ति करता। उपभोग को ईमानदारी से खरीदें-बनाम-बनाएँ के रूप में तैयार करें, क्योंकि एक अच्छी तरह अनुरक्षित ओपन घटक का पुनराविष्कार आमतौर पर महंगा विकल्प होता है, लेकिन ऐसे घटक पर निर्भर रहना भी है जिसकी आप कभी सूची नहीं बनाते। एक सरल रिकॉर्ड रखें कि आप क्या उपयोग करते हैं और किस लाइसेंस के तहत, ताकि एक ग्राहक सुरक्षा प्रश्नावली या एक भेद्यता चेतावनी हाथापाई न बने।

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

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

उदाहरण

स्टार्टअप। एक मोबाइल ऐप बनाने वाला चार-व्यक्तियों वाला स्टार्टअप लगभग हर चीज़ ओपन सोर्स से इकट्ठा करता है और स्टाफ पर कोई वकील नहीं है। डर के कारण कॉपीलेफ़्ट को प्रतिबंधित करने की बजाय, संस्थापक एक-पृष्ठ नीति लिखते हैं: MIT और Apache 2.0 जैसे अनुमेय लाइसेंस पूर्व-स्वीकृत हैं, GPL जैसा मज़बूत कॉपीलेफ़्ट आंतरिक टूलिंग के लिए ठीक है लेकिन प्रकटीकरण कर्तव्यों से बचने के लिए भेजे जाने वाले ऐप से अवरुद्ध है, और कुछ भी असामान्य एक त्वरित संस्थापक समीक्षा पाता है। वे पाइपलाइन में एक लाइसेंस और भेद्यता स्कैन जोड़ते हैं ताकि एक निषिद्ध लाइसेंस किसी रिलीज़ में न फिसल सके, पहले दिन से एक SBOM रखते हैं, और एक महत्वपूर्ण लाइब्रेरी में एक छोटा फिक्स अपस्ट्रीम करते हैं ताकि वे हर अपग्रेड में एक निजी पैच ढोना बंद कर दें। इसे जल्दी ठीक करना उन्हें एक दर्दनाक आश्चर्य से भी बचाता है जब एक अधिग्रहणकर्ता का ड्यू डिलिजेंस अंततः निर्भरता वृक्ष को खंगालता है।

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

सरकार। एक राष्ट्रीय डिजिटल सेवा “पब्लिक मनी, पब्लिक कोड” नीति के तहत संचालित होती है। नई सेवाएँ ओपन स्टैंडर्ड पर बनाई जाती हैं, डिफ़ॉल्ट रूप से एक सार्वजनिक कोड रिपॉज़िटरी पर खुले तौर पर विकसित की जाती हैं, और एजेंसियों में पुन: उपयोग की जाती हैं। इसके खरीद टेम्पलेट विक्रेताओं को खुला, अच्छी तरह दस्तावेज़ीकृत, पुन: उपयोग योग्य कोड देने की आवश्यकता रखते हैं, साथ में सरकार प्रकाशित और संशोधित करने के अधिकार रखती है। किसी नए घटक को शुरू करने से पहले, टीमें मौजूदा पुन: उपयोग योग्य कोड के लिए एक क्रॉस-सरकार कैटलॉग खोजती हैं। सुरक्षा-संवेदनशील मॉड्यूल को एक दस्तावेज़ीकृत प्रक्रिया के माध्यम से प्रकाशन से छूट दी जाती है, बजाय पूरे सिस्टम को बंद करने के।

बिज़नेस केस: प्रेरणाएँ, ROI, और TCO

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

एक्सपोज़र के बगल में अपनाने की लागत मामूली है: एक OSPO या कार्य समूह, स्कैनिंग टूलिंग, और एक सूची बनाए रखने का अनुशासन। न अपनाने की लागत कानूनी देयता, विफल ड्यू डिलिजेंस, अनपैच निर्भरताओं से जुड़ी सुरक्षा घटनाओं, और टाले गए अपग्रेड के संचयी खर्च के रूप में सामने आती है जो अंततः दर्दनाक बड़े-धमाके प्रवासन को मजबूर करते हैं। जब आप नेतृत्व के सामने मामला बनाते हैं, तो ओपन-सोर्स प्रबंधन को अपने कोडबेस के बहुमत के लिए आपूर्ति-श्रृंखला प्रबंधन के रूप में तैयार करें। सामरिक ऊपरी पक्ष भी नोट करें: टाला गया लॉक-इन, तेज़ डिलीवरी, प्रतिभा आकर्षण, और उन इकोसिस्टम पर प्रभाव जिन पर आप निर्भर हैं। सरकार में, आदेश आयाम जोड़ें। खुलापन अक्सर आवश्यक है, वैकल्पिक नहीं, और इसे अच्छी तरह करना गैर-अनुपालन और दोहराए गए सार्वजनिक खर्च दोनों से बचाता है।

एंटी-पैटर्न और नुकसान

• कॉपी-पेस्ट लाइसेंसिंग। डेवलपर बिना किसी लाइसेंस जाँच के घटक खींचते हैं, दायित्वों की खोज केवल ऑडिट या अधिग्रहण पर करते हैं।
• कोई सूची नहीं। जब कोई भेद्यता या लाइसेंस प्रश्न टूटता है तो “हम क्या उपयोग कर रहे हैं और किस लाइसेंस के तहत?” का जवाब न दे पाना।
• कॉपीलेफ़्ट घबराहट। समझ की बजाय डर के कारण सभी कॉपीलेफ़्ट को प्रतिबंधित करना, मूल्यवान इकोसिस्टम को त्यागना।
• छोड़ी गई ओपन-सोर्स रिलीज़। धूमधाम से एक परियोजना प्रकाशित करना और फिर कभी उसका रखरखाव न करना, प्रतिष्ठा को नुकसान पहुँचाना।
• ट्रांज़िटिव निर्भरताओं को अनदेखा करना। प्रत्यक्ष निर्भरताओं की जाँच करते हुए जबकि वास्तविक जोखिम कई परतें नीचे छिपा है।
• जीवन-अंत आश्चर्य। यह खोजना कि एक मूल घटक ने महीनों पहले समर्थन खो दिया, तभी जब कोई भेद्यता ध्यान मजबूर करे।
• कॉपी करने से धीमी नीति। एक अनुपालन प्रक्रिया इतनी भारी कि डेवलपर इसके आसपास रास्ता बना लेते हैं, अदृश्य छाया निर्भरताएँ बनाते हुए।
• सरकारी ब्लैक बॉक्स। मालिकाना सिस्टम खरीदना जिन्हें एजेंसी बनाए, साझा, या छोड़ नहीं सकती, डिफ़ॉल्ट-रूप-से-खुला सिद्धांतों के उल्लंघन में।

परिपक्वता मॉडल

स्तर 1: आरंभ। डेवलपर बिना किसी नीति या सूची के स्वतंत्र रूप से ओपन सोर्स जोड़ते हैं। लाइसेंस अनजाँचे हैं और कॉपीलेफ़्ट दायित्व अज्ञात हैं। जीवन-अंत की खोज दुर्घटनावश होती है, आमतौर पर तब जब कोई भेद्यता ध्यान मजबूर करे। कोई ओपन-सोर्स रणनीति का मालिक नहीं है।

स्तर 2: विकसित। एक बुनियादी नीति और स्वीकृत-लाइसेंस सूची मौजूद है, और कुछ टीमें उनका पालन करती हैं। स्कैनिंग होती है, लेकिन अक्सर मैनुअल रूप से, देर से, या केवल कुछ परियोजनाओं पर। प्रमुख सिस्टम के लिए एक सूची रखी जाती है जबकि ट्रांज़िटिव निर्भरताएँ अनमैप की रहती हैं। योगदान और जीवन-अंत हैंडलिंग टीमों के बीच तदर्थ और असंगत हैं।

स्तर 3: मानकीकृत। एक OSPO या समकक्ष संगठन-व्यापी रणनीति, नीति, और टूलिंग का मालिक है। लाइसेंस और भेद्यता स्कैनिंग हर पाइपलाइन में स्वचालित है, एट्रिब्यूशन और नोटिस फ़ाइलें स्वचालित रूप से उत्पन्न होती हैं, और बिल्ड को गेट किया जाता है ताकि एक निषिद्ध लाइसेंस प्रवेश न कर सके। SBOM को ट्रांज़िटिव वृक्ष में नीचे तक बनाए रखा जाता है, योगदान एक दस्तावेज़ीकृत प्रक्रिया का पालन करता है, जीवन-अंत को नियोजित प्रवासन के साथ ट्रैक किया जाता है, और सरकारी टीमें डिफ़ॉल्ट रूप से प्रकाशित करती हैं।

स्तर 4: प्रबंधित। कार्यक्रम को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है। आप सेवाओं में नीति-स्कैन कवरेज, एक प्रकट निर्भरता भेद्यता को पैच करने का औसत समय, उनके सुरक्षा-समर्थन विंडो के भीतर घटकों का हिस्सा, लाइसेंस-उल्लंघन बचाव दर, निर्भरता-वर्तमानता पिछड़ाव, और अपस्ट्रीम ढोए गए निजी पैच की गिनती ट्रैक करते हैं। वितरण सीमा के सापेक्ष कॉपीलेफ़्ट प्लेसमेंट की निगरानी की जाती है, और लक्ष्यों के विरुद्ध मीट्रिक राय की बजाय हर गो या नो-गो निर्णय को चलाते हैं।

स्तर 5: ऑर्केस्ट्रेट। ओपन सोर्स एक लगातार सुधारी गई सामरिक संपत्ति है जो पूरे संगठन में एकीकृत है। अनुपालन पूरी तरह स्वचालित है और गैर-अनुपालक घटक उत्पादन तक नहीं पहुँच सकते। आप जानबूझकर महत्वपूर्ण अपस्ट्रीम परियोजनाओं में निवेश करते हैं, नियमित रूप से योगदान देते हैं, और अपनी खुद की अच्छी तरह चलाई गई परियोजनाओं का स्टीवर्ड बनते हैं। निर्भरता वर्तमानता और जीवन-अंत को जोखिम और मीट्रिक के बदलने के साथ अनुकूल रूप से प्रबंधित किया जाता है, और खुलापन एक वास्तविक प्रतिस्पर्धी और नागरिक लाभ बन जाता है।

चर्चा के लिए विचार

• एक तेज़ अनुमेय डिफ़ॉल्ट और कानूनी तथा सुरक्षा ऋण से बचने के लिए आवश्यक नियंत्रण के बीच सही रेखा कहाँ है?
• एक संगठन को कब एक महत्वपूर्ण अपस्ट्रीम निर्भरता को मुफ़्त मानने की बजाय वित्तपोषित या अनुरक्षित करना चाहिए?
• आप कैसे तय करते हैं कि आपके अपने कौन से घटक ओपन सोर्स के रूप में रिलीज़ और स्टीवर्ड करने लायक हैं?
• सरकार के लिए, सिद्धांत को कमज़ोर किए बिना घटकों को डिफ़ॉल्ट-रूप-से-प्रकाशन से छूट देने की एक बचाव योग्य प्रक्रिया क्या है?
• ट्रांज़िटिव निर्भरताओं में लाइसेंस और सुरक्षा समीक्षा को वास्तव में कितनी गहराई तक जाना चाहिए?
• क्या नेटवर्क कॉपीलेफ़्ट (AGPL) उस सॉफ़्टवेयर के लिए आपकी बिल्ड-बनाम-अपनाएँ गणना बदलता है जिसे आप एक सेवा के रूप में पेश करते हैं?

मुख्य निष्कर्ष

• ओपन सोर्स अधिकांश कोडबेस का बहुमत है और इसे एक आपूर्ति-श्रृंखला के रूप में प्रबंधित किया जाना चाहिए, मुफ़्त और परिणाम-रहित नहीं माना जाना चाहिए।
• लाइसेंस वास्तविक दायित्व रखते हैं; अनुमेय, कमज़ोर-कॉपीलेफ़्ट, मज़बूत-कॉपीलेफ़्ट, और नेटवर्क-कॉपीलेफ़्ट परिवारों को समझें और वितरण और संयोजन कैसे कर्तव्यों को ट्रिगर करते हैं।
• क्यूरेशन, स्वचालित स्कैनिंग, और स्पष्ट डिफ़ॉल्ट के माध्यम से अनुपालित मार्ग को सबसे तेज़ मार्ग बनाएँ, या डेवलपर नीति के आसपास रास्ता बना लेंगे।
• पैमाने पर रणनीति, अनुपालन, योगदान, और स्टीवर्डशिप का मालिक होने के लिए एक OSPO खड़ा करें।
• एक SBOM बनाए रखें, निर्भरताओं को छोटे कदमों में वर्तमान रखें, और जीवन-अंत की योजना इसके संकट मजबूर करने से पहले बनाएँ।
• सरकार में, ओपन स्टैंडर्ड को डिफ़ॉल्ट बनाएँ और पब्लिक-मनी कोड प्रकाशित करें, बनाने से पहले पुन: उपयोग करते हुए।

संदर्भ और आगे पठन

• Heather Meeker, Open (Source) for Business and Open Source for Business
• Van Lindberg, Intellectual Property and Open Source
• The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
• OpenChain (ISO/IEC 5230), Open Source License Compliance
• Software Package Data Exchange (SPDX, ISO/IEC 5962) specification
• CycloneDX SBOM specification
• Free Software Foundation, GNU General Public License and GPL FAQ
• Open Source Initiative, The Open Source Definition and approved license list
• Free Software Foundation Europe, Public Money, Public Code
• U.S. Federal Source Code Policy and Code.gov guidance
• UK Government, Technology Code of Practice and open-standards principles