मृत खुली स्रोत निर्भरताओं से निपटने के लिए कैसे?

Question

मैं ओपन-सोर्स रिलीज के लिए एक प्रोजेक्ट तैयार करने की कोशिश कर रहा हूं और एक समस्या में भाग गया हूं ... यह प्रोजेक्ट कई ओपन-सोर्स घटकों पर निर्भर करता है जिन्हें मैंने अपनी lib निर्देशिका में जार-फाइल के रूप में संग्रहीत किया है तारीख। उनमें से कुछ कुछ साल पहले की तारीखें हैं, और उनमें से कम से कम एक ओपन-सोर्स प्रोजेक्ट से है, जिसकी साइट गायब हो गई है और जिसका स्रोत मैं (रेडॉक्स लाइब्रेरी) की एक प्रति नहीं ढूंढ पा रहा हूं।

मेरी दुविधा यह है कि मुझे नहीं पता कि जब मैं इसे रिलीज़ करता हूं तो मुझे अपने प्रोजेक्ट को कैसे पैकेज करना है ... मुझे स्रोत के बिना जेएआर-फाइल शामिल नहीं करना चाहिए क्योंकि वह लाइसेंस की शर्तों का उल्लंघन करेगा जिसके तहत मैंने उपयोग किया था कोड स्वयं, लेकिन मुझे नहीं लगता कि यह जेएआर फ़ाइल आसानी से खोजने योग्य है इसलिए मैं भी एक ऐसा कहना नहीं चाहता हूं जो कहता है "यह जार, शुभकामनाएं पाएं!"।

इस मामले में सबसे अच्छा अभ्यास क्या है? गौणतः और ("सभी जार अब आप पर! से आयात का स्रोत रखने के अलावा अन्य), किसी को पता है जहाँ मैं इस विशेष पुस्तकालय के लिए स्रोत मिल सकती है?

धन्यवाद!

Answer 1

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

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

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

Answer 2

लाइसेंस का कहना है यदि आपके पास स्रोत को शामिल करने के लिए आपको स्रोत शामिल करना होगा।

मूल लेखकों से संपर्क करने का प्रयास करें। शायद this Ohloh link मदद करेगा। यदि आप उन तक नहीं पहुंच सकते हैं, तो शायद आप किसी अन्य प्रोजेक्ट से स्रोत की प्रति प्राप्त कर सकते हैं लाइब्रेरी। अंतिम उपाय के रूप में आप Google's cache या archive.org को आजमा सकते हैं।

Answer 3

अद्यतन: बिंगो !!

यहां रेडॉक्स Subversion repository है। स्रोत कोड के लिए http://svn.codehaus.org/radeox/main/trunk/src/java/org/radeox/ पर नेविगेट करें।

इससे पहले ...

स्टीफ़न श्मिट, लेखक, वर्तमान में http://www.codemonkeyism.com पर एक ब्लॉग चल रहा है की तरह लग रहा। ईमेल सहित उनकी संपर्क जानकारी here है, और August 2007 से एक प्रविष्टि ने परियोजना को Reposita.org पर फेंकने के बारे में बात की (जो अभी तक प्रतीत नहीं होता है)। उनके presentations ने उन्हें पिछले साल ImobilienScout24 पर रखा था।

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

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