एक VPN इंटरफ़ेस, एक GPL इंजन और एक इंस्टॉलर: क्या वितरित होता है?

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

इंस्टॉलर डिस्क पर क्या रखता है, वहीं से शुरू करें

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

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

सूची संस्करणों के साथ लिखें, क्योंकि मुख्य रिलीज़ों के बीच शर्तें अलग होती हैं।

dpkg -L openvpn | head -n 40
openssl version -a

इंटरफ़ेस को इंजन से अलग करें

OpenVPN की कॉपी फ़ाइल GPL संस्करण 2 बताती है और OpenSSL के लिए लिंकिंग अपवाद दर्ज करती है, जो तय दायरे वाली विशेष अनुमति है, शर्तें मिलाने का सामान्य लाइसेंस नहीं।

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

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

नोट करें कि आपने कौन-सी फ़ाइलें बदलीं

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

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

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

OpenSSL संस्करण अलग से जाँचें

OpenSSL 3.0 और उसके बाद Apache License 2.0 के अंतर्गत वितरित होते हैं, जबकि पुरानी रिलीज़ें OpenSSL/SSLeay शर्तें लिए होती हैं। ये अलग दायित्वों वाले अलग दस्तावेज़ हैं, और बंडल किया गया इंजन उनमें से कोई भी लिंक कर सकता है जो आपके बिल्ड सिस्टम को मिला।

बिल्ड स्क्रिप्ट में नाम वाला नहीं, वास्तव में वितरित होने वाला संस्करण पुष्ट करें।

OpenVPN पर निर्भरता OpenSSL के हर बदलाव को GPL कोड नहीं बनाती, और लिंकिंग अपवाद लाइब्रेरी के पुनर्वितरण के साथ आने वाले अन्य दायित्वों को नहीं हटाता। अपवाद को बड़े विश्लेषण में एक खंड मानें, और TLS लाइब्रेरी की अपनी सूचनाएँ बाकी सब के साथ दर्ज करें।

प्रमाण पैकेज जुटाएँ

पैकेज के चार भाग हैं: संस्करणों सहित फ़ाइल सूची, एकीकरण का विवरण, अंतरों सहित बदलावों की सूची और वितरित रूप में लाइसेंस पाठ। आप जो सूचना फ़ाइल वितरित करते हैं और जहाँ स्रोत कोड प्रस्तावित होता है वह जोड़ें, यदि आपके दायित्व प्रस्ताव की माँग करते हैं।

पैकेज को एक स्वामी के अधीन रखें ताकि कोई रिलीज़ उसके बिना बाहर न जाए।

इनमें से कोई भी कानूनी सवाल तय नहीं करता, और यही बात है: यह सक्षम समीक्षक को किसी के स्मृति से जोड़े गए सारांश के बजाय तथ्य देता है। विक्रेता का विपणन विवरण उसके स्थापत्य का प्रमाण नहीं है, और उसके बारे में आपका अपना अनुमान भी प्रमाण नहीं है।