# सोर्स-अवेलेबल सुरक्षा सॉफ्टवेयर का आकलन कैसे करें

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

मैंने टीमों को क्रिप्टोग्राफिक डिजाइन पर कई सप्ताह और उनके रहस्यों को संभालने वाले कोड के लाइसेंस पर आधा घंटा लगाते देखा है। यह क्रम उलटा है। आपकी समीक्षा को एक ठोस सवाल का जवाब देना चाहिए: यदि विक्रेता, रिपॉजिटरी और व्यावसायिक संबंध, तीनों आपके सामने बदल जाएं, तो आपका संगठन कानूनी और तकनीकी रूप से क्या करता रह सकता है?

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

## लाइसेंस सॉफ्टवेयर को किस श्रेणी में रखता है?

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

Open Source Initiative की Open Source Definition इस अंतर को काम का बनाती है। इसके मानदंड सोर्स तक पहुंच के साथ व्युत्पन्न कार्य, मुक्त पुनर्वितरण और किसी कार्यक्षेत्र पर रोक न होने की मांग करते हैं। कोई लाइसेंस हर पंक्ति प्रकाशित करके भी उत्पादन उपयोग, प्रतिस्पर्धी सेवा या किसी कारोबारी वर्ग को रोकता है, तो वह इस परिभाषा पर खरा नहीं उतरता।

“ओपन सोर्स” को “हम रिपॉजिटरी पढ़ सकते हैं” का दोस्ताना पर्याय न बनाएं। लाइसेंस का सटीक नाम, संस्करण और पहचान दर्ज करें। फिर दर्ज करें कि Open Source Initiative ने उसे मंजूरी दी है या नहीं। SPDX License List लाइसेंस टेक्स्ट को एक समान ढंग से पहचानने में मदद करती है, लेकिन सूची में मौजूद होना अपने आप मंजूरी नहीं है। सूची में OSI मंजूरी का अलग क्षेत्र है और उसमें BUSL-1.1 तथा Elastic-2.0 जैसे लाइसेंस भी हैं जिन्हें OSI मंजूर नहीं दिखाया गया है।

यह अंतर केवल शब्दों का नहीं है। आपका निर्भरता स्कैनर Apache-2.0 को अपने आप अनुमति दे सकता है, जबकि किसी खास सोर्स-अवेलेबल लाइसेंस को मैन्युअल समीक्षा में भेज सकता है। आपकी खरीद नीति बदलाव की अनुमति तभी दे सकती है जब पुनर्वितरण अधिकार साफ हों। घटना संभालने वाला इंजीनियर मान सकता है कि टीम दिखने वाले कोड को सुधार कर तैनात कर सकती है, जबकि लाइसेंस उस उत्पादन उपयोग पर रोक लगाता हो।

नतीजे को एक ऐसे वाक्य में दर्ज करें जिसे बाद में कोई नरम न कर सके: “कोड [सटीक लाइसेंस] के तहत उपलब्ध है, जिसे OSI ने [मंजूर किया है/मंजूर नहीं किया है], और हमारा तय उपयोग [विशिष्ट अनुमति या पाबंदी] पर निर्भर है।” यदि टीम यह वाक्य पूरा नहीं कर सकती, तो पहली समीक्षा पूरी नहीं हुई।

## क्या लाइसेंस हमारी वास्तविक तैनाती की अनुमति देता है?

लागू लाइसेंस टेक्स्ट को तैनाती के नक्शे के साथ पढ़ें, विक्रेता के सारांश पेज के साथ नहीं। “उत्पादन”, “प्रबंधित सेवा”, “प्रतिस्पर्धी पेशकश”, “आंतरिक व्यावसायिक उद्देश्य” और “अधिकृत उपयोगकर्ता” जैसे शब्द तभी अर्थ रखते हैं जब आप उन्हें प्रक्रियाओं, खातों, ग्राहकों और डेटा प्रवाह से जोड़ते हैं।

हर कानूनी इकाई और सॉफ्टवेयर का उपयोग करने या उसका परिणाम पाने वाले हर व्यक्ति के चारों ओर सीमा बनाएं। मूल कंपनी, सहायक कंपनी, ठेकेदार, प्रबंधित सेवा प्रदाता और ग्राहक एक ही धारा के तहत अलग स्थिति में हो सकते हैं। यदि कोई एजेंट ग्राहक की ओर से API कॉल करता है, तो पूछें कि ग्राहक को सोर्स-अवेलेबल उत्पाद सेवा के रूप में मिल रहा है या केवल आपके उत्पाद का परिणाम। बिक्री चैट के एक संदेश से इस सवाल को तय न करें।

Business Source License 1.1 दिखाता है कि भरे गए मापदंड क्यों मायने रखते हैं। इसका मानक टेक्स्ट कॉपी, बदलाव, व्युत्पन्न कार्य, पुनर्वितरण और गैर-उत्पादन उपयोग का अधिकार देता है। लाइसेंस देने वाला सीमित उत्पादन उपयोग की अतिरिक्त अनुमति दे सकता है और हर संस्करण बाद में तय Change Date या लाइसेंस की अंतिम समय सीमा पर किसी नामित ओपन सोर्स लाइसेंस में बदलता है। इसलिए वास्तविक अनुमति का एक हिस्सा उस उत्पाद और संस्करण के लाइसेंस हेडर में रहता है। Additional Use Grant और Change License पढ़े बिना सामान्य BSL विवरण पढ़ना जरूरी शर्तों को अनजाना छोड़ देता है।

Elastic License 2.0 का ढांचा अलग है। Elastic के अपने FAQ के मुताबिक यह लाइसेंस उपयोग, बदलाव, व्युत्पन्न कार्य और पुनर्वितरण की अनुमति देता है, लेकिन उत्पाद को प्रबंधित सेवा के रूप में देने, लाइसेंस-की व्यवस्था से बचने और नोटिस हटाने पर रोक लगाता है। इससे यह तय नहीं होता कि आपकी खास होस्ट की गई संरचना अनुमत है। यह बताता है कि किस सीमा पर लिखित जवाब चाहिए।

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

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

कॉपीराइट अनुमति को पूरे सौदे के बाकी हिस्सों से अलग रखें। रिपॉजिटरी लाइसेंस किसी उपयोग की अनुमति दे सकता है, जबकि सदस्यता समझौता, सेवा शर्तें, ट्रेडमार्क नीति, पेटेंट धारा, निर्यात शर्त या सहायता अनुबंध दूसरी शर्त लगा सकते हैं। संदर्भ से शामिल हर दस्तावेज इकट्ठा करें और तय करें कि टकराव होने पर कौन प्रभावी होगा। खाते के मालिक ने जिस क्लिक-थ्रू को स्वीकार किया है, उसे LICENSE फाइल के साथ समीक्षा में रखें।

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

मुख्य रिपॉजिटरी और उसकी निर्भरताओं के लाइसेंस अलग-अलग देखें। ऊपरी स्तर का उदार लाइसेंस किसी असंगत लाइब्रेरी, पुनर्वितरण से रोके गए मॉडल या नियम समूह, पैकेजिंग सीमा वाले फॉन्ट या उत्पादन में जरूरी केवल-बाइनरी सहायक को ठीक नहीं कर सकता। जिस रिलीज को आप भेजेंगे उससे निर्भरता लाइसेंस सूची बनाएं, फिर unknown, custom या NOASSERTION वाली प्रविष्टियां जांचें। आपकी तैनाती को घटक चाहिए तो “वैकल्पिक” लिखे होने से फर्क नहीं पड़ता।

अनुबंध के वादों को लाइसेंस वाले कॉलम में न रखें। सहायता के उत्तर का लक्ष्य, सुरक्षा सूचना की जिम्मेदारी, सोर्स देने की तारीख और कीमत सुरक्षा अपनाने का फैसला स्वीकार्य बना सकते हैं, लेकिन आम तौर पर वे तय अवधि के लिए खास पक्षों को बांधते हैं। लाइसेंस अधिकार हर प्रति के साथ लंबे समय तक रह सकते हैं। रिकॉर्ड में बताएं कि कौन-सी सुरक्षा किस दस्तावेज से आती है और अनुबंध खत्म होने पर क्या होगा।

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

## क्या हम उसी चीज को जांच, बना, सुधार और भेज सकते हैं?

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

विक्रेता अक्सर उपयोगी कोर प्रकाशित करते हैं, पर बिल्ड ढांचा, हस्ताक्षर के कदम, तैयार की गई फाइलें, प्रीमियम मॉड्यूल या आधिकारिक रिलीज की पैकेजिंग नहीं देते। ऐसी रिपॉजिटरी फिर भी किसी शोधकर्ता को पार्सर समझने या क्रिप्टोग्राफिक कॉल जांचने में मदद कर सकती है। यदि जारी बाइनरी अनुपलब्ध हिस्सों पर निर्भर है, तो वह आपातकालीन फोर्क का आधार नहीं बन सकती।

ऐसी मशीन पर साफ बिल्ड चलाएं जिसमें किसी डेवलपर का निजी कैश न हो। कमिट या टैग तय करें, कमांड सहेजें और बने पैकेज की विक्रेता की रिलीज से तुलना करें। परियोजना समर्थन करती हो तो हर बाइट का समान होना बहुत अच्छा है, पर दस्तावेज से समझाया जा सकने वाला अंतर भी स्वीकार्य हो सकता है। क्रेडेंशियल या ऑडिट प्रमाण संभालने वाले घटक में ऐसे अस्पष्ट बाइनरी हिस्से स्वीकार न करें जिनका संबंधित सोर्स में कोई स्रोत नहीं है।

सफल बिल्ड की स्क्रीनशॉट के बजाय छोटा प्रमाण रिकॉर्ड रखें:

```text
release: 4.2.1
source_ref: refs/tags/v4.2.1
source_commit: 8f2c...91a
build_command: ./scripts/build-release
artifact: dist/tool-4.2.1.pkg
artifact_sha256: 1c71...0be
vendor_sha256: 93a4...82d
comparison: differs
explained_differences: signing envelope, build timestamp
unexplained_files: none
patch_deploy_allowed_by: License section 2, counsel ticket LEG-184
```

यह रिकॉर्ड दो अलग नतीजे निकालने को मजबूर करता है। “हमने इसे बना लिया” तकनीकी निष्कर्ष है। “हम अपने बिल्ड को चला और पुनर्वितरित कर सकते हैं” कानूनी निष्कर्ष है। टीमें अक्सर दोनों को मिला देती हैं और घटना के समय पता चलता है कि आधा उत्तर गायब है।

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

अंत में योगदानकर्ता शर्तें देखें। Contributor License Agreement विक्रेता को योगदान का लाइसेंस बदलने का अधिकार दे सकता है, जबकि बाहरी योगदानकर्ता भविष्य का व्यावसायिक कोड इस्तेमाल नहीं कर सकते। यह व्यवस्था उचित हो सकती है, पर परियोजना बंटने पर इससे तय होगा कि उसे कौन आगे ले जा सकता है। दर्ज करें कि योगदान के लिए Developer Certificate of Origin, कॉपीराइट हस्तांतरण, व्यापक CLA या कोई घोषित प्रक्रिया इस्तेमाल होती है।

## क्या रिलीज सार्वजनिक रिपॉजिटरी से मेल खाती हैं?

सुरक्षा समीक्षा किसी खास आर्टिफैक्ट पर लागू होती है, किसी अमूर्त रिपॉजिटरी पर नहीं। आपके इंस्टॉल किए संस्करण, सोर्स कमिट, लाइसेंस टेक्स्ट, निर्भरता समूह और उस रिलीज की सुरक्षा सूचना के बीच भरोसेमंद संबंध जरूरी है।

रिलीज इतिहास से शुरू करें। हस्ताक्षरित टैग या दूसरी प्रमाणित रिलीज व्यवस्था, सुरक्षा बदलाव पहचानने वाले चेंजलॉग, रखरखाव वाली रिलीज शाखाएं और बाइनरी रिलीज से सोर्स मिलने तक दोहराया जाने वाला अंतर देखें। एक बार सोर्स देर से आना गलती हो सकता है। हमेशा रहने वाला अंतर बताता है कि सार्वजनिक रिपॉजिटरी उत्पादन का असली स्रोत नहीं है।

रखरखाव करने वाले से रिलीज क्रम और सहायता अवधि को स्थायी दस्तावेज में लिखने को कहें। “लगातार अपडेट” कुछ नहीं बताता। आपको जानना है कि किन शाखाओं में सुरक्षा सुधार आएंगे, पुराने संस्करण कब तक समर्थित हैं, सुधार ग्राहक बाइनरी से पहले सोर्स में आएंगे या बाद में, और क्या गोपनीय खुलासा अवधि स्वयं बिल्ड करने वालों को जोखिम में छोड़ेगी। पिछली गतिविधि देखकर सेवा का वादा न गढ़ें।

केवल सबसे नया टैग देखने के बजाय हाल की तीन रिलीज की तुलना करें। हर रिलीज के लिए चार सवाल पूछें:

1. क्या टैग जारी आर्टिफैक्ट के लिए इस्तेमाल हुए सोर्स पर जाता है?
2. क्या उस टैग पर बिल्ड निर्देश और निर्भरता लॉक मौजूद हैं?
3. क्या लाइसेंस या व्यावसायिक फीचर की सीमा बदली है?
4. क्या नया वातावरण चलने वाला पैकेज बना सकता है?

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

Software bill of materials मदद करता है, लेकिन उसे सोर्स समानता का प्रमाण न मानें। SBOM आर्टिफैक्ट के घटक बताता है। वह यह साबित नहीं करता कि सार्वजनिक रिपॉजिटरी में आर्टिफैक्ट फिर बनाने के लिए कोड, बिल्ड तरीका या अधिकार हैं। दोनों इस्तेमाल करें: निर्भरता और कमजोरियों के काम के लिए SBOM, और स्वतंत्रता के लिए सोर्स से आर्टिफैक्ट का संबंध।

रिलीज की रफ्तार यह भी बताती है कि आपकी टीम को कितना रखरखाव उठाना पड़ सकता है। हर महीने फीचर जारी करके केवल नई शाखा सुधारने वाली परियोजना तेज अपग्रेड के लिए मजबूर कर सकती है। साफ बैकपोर्ट नीति वाली धीमी परियोजना चलाना आसान हो सकता है। विक्रेता द्वारा प्रचारित रिलीज की संख्या नहीं, अपनी टीम पर पड़ने वाला काम गिनें।

## आज और कल की व्यावसायिक सीमा कहां है?

योजना में मौजूद व्यावसायिक फीचर आपके सुरक्षा मार्ग पर हों, तो वे अभी न बने होने पर भी मायने रखते हैं। विक्रेता से उत्पाद को वर्तमान खुले या सोर्स-अवेलेबल कोड, वर्तमान भुगतान वाले कोड और भविष्य के भुगतान वाले कोड में बांटने को कहें, फिर हर हिस्से को अपनी जरूरी सुरक्षा व्यवस्था से जोड़ें।

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

रोडमैप अनुबंध नहीं हैं और उसमें किसी चीज का न होना भी वादा नहीं है। योजनाबद्ध फीचर को मालिक, संभावित समय, तय लाइसेंस और वैकल्पिक उपाय के साथ योजना संकेत के रूप में दर्ज करें। यदि अपनाना भविष्य के Enterprise नियंत्रण पर निर्भर है, तो अभी व्यावसायिक रास्ते की कीमत और मंजूरी तय करें या उस नियंत्रण को अनुपलब्ध मानें। स्लाइड में सुरक्षा आने वाली हो तो भी कमजोर डिजाइन तैनात न करें।

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

यह भी पूछें कि प्रोटोकॉल और डेटा प्रारूप किसके नियंत्रण में हैं। एजेंट दस्तावेज वाले प्रोटोकॉल से बात कर सकें और पूरे रिकॉर्ड स्थिर प्रारूप में निकाल सकें, तो व्यावसायिक कंसोल बदला जा सकता है। दिखने वाला कोर अपारदर्शी स्थिति रखे या भुगतान सेवा ही शुरू करने के क्रेडेंशियल दे, तो बदलना कठिन है। निजी कंट्रोल प्लेन के चारों ओर सार्वजनिक कोड बहुत कम परिचालन स्वतंत्रता दे सकता है।

Sallyport स्पष्ट तुलना देता है क्योंकि उसका वर्तमान macOS ऐप Apache-2.0 के तहत पूरा ओपन सोर्स है, जबकि व्यावसायिक Enterprise घटक अभी योजना में हैं। इससे भविष्य की टीम सुविधाओं की कीमत या सामग्री नहीं पता चलती, इसलिए अपनाने वाली टीम को वर्तमान लाइसेंस में उपलब्ध ऐप का आकलन करना चाहिए और सीमा प्रकाशित होने तक योजनाबद्ध घटकों को अनजान मानना चाहिए।

## क्या परियोजना अपनाने के बाद शर्त बदल सकती है?

संबंधित कॉपीराइट नियंत्रित करने वाला लाइसेंसदाता भविष्य के संस्करण अलग शर्तों में जारी कर सकता है। आम तौर पर वह आपके पास मौजूद संस्करण का अधिकार मिटा नहीं सकता, लेकिन उसी पर रुकने से सुधार, अनुकूलता का काम और नए प्रोटोकॉल का समर्थन छूट सकता है।

इसीलिए “वे कोड वापस नहीं ले सकते” कमजोर सांत्वना है। आपका असली चुनाव नई शर्त मानना, कमजोर शाखा पर रुकना या फोर्क का खर्च उठाना हो सकता है। अपनाने से पहले इन लागतों का आकलन करें, जब सॉफ्टवेयर को मना करना सस्ता है।

रिपॉजिटरी संचालन और कॉपीराइट के केंद्रीकरण को देखें। कौन मर्ज कर सकता है? रिलीज कौन बनाता है? क्या बाहरी रखरखावकर्ता संगत वितरण जारी कर सकते हैं? क्या रोजगार और योगदान समझौतों से लगभग सारा कॉपीराइट एक कंपनी के पास है? कंपनी के नेतृत्व वाली परियोजना अच्छी तरह चल सकती है, लेकिन केंद्रित नियंत्रण से भविष्य में लाइसेंस बदलना आसान और समुदाय के लिए आगे बढ़ना कठिन होता है।

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

इसके बाद बदल सकने वाली चीजों की निगरानी करें:

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

ये नियंत्रण लाइसेंस के वादे को ऐसी चीज बनाते हैं जिसे इंजीनियरिंग देख सकती है। वे सामान्य निर्भरता अपडेट को बिना समीक्षा नई जिम्मेदारियां लाने से भी रोकते हैं।

विक्रेता के सार्वजनिक वादे पर भरोसा न करें कि लाइसेंस कभी नहीं बदलेगा, जब तक आपका जोखिम निर्णय उस गैर-बाध्यकारी वादे को साफ तौर पर स्वीकार न करे। स्थिर अधिकार जरूरी हैं तो आवश्यक कोड के लिए मानक OSI-मंजूर लाइसेंस चुनें या ऐसी शर्त तय करें जो व्यावसायिक संबंध के बाद भी रहे। अच्छे इरादे स्थायी अनुमति की जगह नहीं लेते।

## क्या भरोसेमंद निकास मार्ग मौजूद है?

भरोसेमंद निकास मार्ग सुरक्षा काम को माइग्रेशन तक चलने देता है, बिना लाइसेंस तोड़े और ऐसी सेवा पर निर्भर हुए जो गायब हो सकती है। सार्वजनिक रिपॉजिटरी इसका केवल एक हिस्सा है।

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

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

फोर्क के लिए लोग भी चाहिए। उस टीम का नाम लिखें जो कोड संभालेगी, जरूरी भाषा और प्लेटफॉर्म ज्ञान का अनुमान लगाएं, और ऐसी निर्भरता पहचानें जिसे फिर बांटा नहीं जा सकता। कोई यह काम नहीं ले सकता तो “केवल माइग्रेशन” लिखें, रिपॉजिटरी को झूठा विकल्प न बनाएं।

ट्रेडमार्क की योजना अलग रखें। सॉफ्टवेयर लाइसेंस अक्सर कोड अधिकार देता है, ब्रांड अधिकार नहीं। आपके फोर्क को नया नाम, पैकेज पहचान, हस्ताक्षर पहचान, अपडेट चैनल और दस्तावेज चाहिए हो सकते हैं। योजना में यह संभाला जा सकता है, जल्दी की रिलीज में पता चले तो बाधा बनता है।

देर से ओपन सोर्स में बदलाव लंबी अवधि सुधार सकता है, लेकिन उसे हर संस्करण के लिए देखें। BSL 1.1 में हर संस्करण की अपनी Change Date है और लाइसेंस हर संस्करण पर अलग लागू होता है। खुल चुका पुराना संस्करण नए प्रतिबंधित संस्करण के सुरक्षा सुधारों से खाली हो सकता है। “बाद में ओपन सोर्स” का मतलब यह नहीं कि जरूरत के समय चल रहा संस्करण ओपन सोर्स है।

ऐसा निकास लक्ष्य तय करें जिसे जांचा जा सके, जैसे: “दस कार्य दिवस में हम अंतिम मंजूर रिलीज फिर बना सकते हैं, स्थानीय सुधार तैनात कर सकते हैं, संगठन का पूरा डेटा निकाल सकते हैं और विक्रेता ढांचे के बिना माइग्रेशन शुरू कर सकते हैं।” अपने जोखिम के मुताबिक समय चुनें, फिर अभ्यास करें। जांच विफल हो तो कमी के लिए धन दें या विक्रेता निर्भरता को स्वीकार किया जोखिम लिखें।

## सोर्स दिखने पर सुरक्षा प्रतिक्रिया का मालिक कौन है?

दिखने वाला सोर्स कमजोरियों की जांच, खुलासा, सुधार या ग्राहक संचार की जिम्मेदारी तय नहीं करता। पूछें कि कमजोरी की रिपोर्ट कौन लेता है, किन संस्करणों को सुधार मिलता है, गोपनीय मुद्दे लाइसेंस उपयोगकर्ताओं तक कैसे पहुंचते हैं और आपकी टीम आपात सुधार बनाकर बांट सकती है या नहीं।

रिपॉजिटरी की सुरक्षा नीति पढ़ें और उसे वास्तविक रिलीज व्यवहार से मिलाएं। उपयोगी नीति समर्थित संस्करण, निजी रिपोर्ट का रास्ता, जवाब की अपेक्षा और खुलासा प्रक्रिया बताती है। नीति केवल “issue खोलें” कहती है तो संवेदनशील रिपोर्ट सुधार से पहले सार्वजनिक हो सकती है। समय का वादा हो तो पता करें कि वह लक्ष्य है या अनुबंध की शर्त।

पता करें कि स्वयं बिल्ड करने वालों से विक्रेता क्या अपेक्षा रखता है। कुछ विक्रेता बदलाव की अनुमति के बाद भी केवल अपने हस्ताक्षरित वितरण को समर्थन देते हैं। यह उचित हो सकता है, लेकिन आपकी रनबुक में दिखना चाहिए कि स्थानीय सुधार के बाद सहायता कहां खत्म होती है और समर्थित बिल्ड पर वापसी कैसे होगी। वरना आपात सुधार ऐसी निजी शाखा बन जाता है जिसका कोई मालिक नहीं।

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

यदि मौजूद हों तो खतरा मॉडल, संरचना नोट, निर्भरता अपडेट तरीका और बाहरी मूल्यांकन रिपोर्ट मांगें। नई परियोजना को केवल सुंदर रिपोर्ट न होने से न ठुकराएं और दायरा देखे बिना बैज पर भरोसा न करें। दर्ज करें कि टीम ने कौन-से दावे जांचे, कौन-से विक्रेता पर निर्भर हैं और कौन-से अभी बिना जांचे हैं।

उत्पादन से पहले आंतरिक मालिक तय करें। वह मालिक सुरक्षा सूचना, लाइसेंस बदलाव, रिलीज अंतर और व्यावसायिक सीमा देखता है। मालिक न हो तो सार्वजनिक सोर्स यह भावना देता है कि कोई उसे जांच सकता है, जबकि हर व्यक्ति मानता है कि कोई दूसरा जांच रहा है।

## अपनाने के रिकॉर्ड में क्या होना चाहिए?

अंतिम निर्णय ऐसे रिकॉर्ड में होना चाहिए जिसे इंजीनियरिंग, सुरक्षा, खरीद और कानूनी सलाहकार सभी चुनौती दे सकें। लंबी चैट निर्णय रिकॉर्ड नहीं है, क्योंकि उसमें संस्करण का दायरा, धारणाएं और अनसुलझे सवाल खो जाते हैं।

मंजूरी बैठक में यह छोटी जांच सूची इस्तेमाल करें:

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

हर अनसुलझे मुद्दे का मालिक और समय सीमा तय करें। धारणाएं साफ लिखें। कानूनी सलाहकार प्रबंधित सेवा उपयोग के जवाब की प्रतीक्षा कर रहे हों तो निर्णय शर्त वाला है, मंजूर नहीं। योजनाबद्ध व्यावसायिक फीचर ऑडिट रखने को नियंत्रित करता है तो उसकी कमी को सुरक्षा अपवाद में रखें, रोडमैप नोट में न छिपाएं।

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

बड़े संस्करण, लाइसेंस टेक्स्ट बदलाव, मालिकाना बदलाव, नई व्यावसायिक निर्भरता, बड़े संरचना बदलाव या विफल निकास जांच पर रिकॉर्ड फिर खोलें। ऐसा कुछ न हो तब भी समीक्षा तारीख रखें। सुरक्षा सॉफ्टवेयर चुपचाप ढांचा बन जाता है, और मूल्यांकन में आसान बदलाव एजेंट, क्रेडेंशियल और ऑडिट प्रक्रिया जुड़ने के बाद कठिन निर्भरता हो सकता है।

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