क्या यह आपके लिए मायने रखता है कि एक सॉफ्टवेयर "उपलब्ध स्रोत" है, लेकिन "खुला स्रोत" नहीं है


11

आप शायद ओएसआई द्वारा आधिकारिक तौर पर अनुमोदित ओपन सोर्स लाइसेंस की सूची जानते हैं। सबसे विशेष रूप से मुझे लगता है कि जीपीएल, एमआईटी होगा, [अपना पसंदीदा लाइसेंस यहां डालें]।

मैं हाल ही में एक परियोजना में भाग गया, जो हालांकि खुला स्रोत था (निर्माता ने सभी स्रोत कोड उपलब्ध कराए थे), आधिकारिक तौर पर उन आधिकारिक लाइसेंसों में से एक के तहत खुला स्रोत नहीं था।

  • इसने स्रोत को जारी किया, लेकिन भविष्य में स्रोत को जारी करने का कोई वादा नहीं किया।

  • इसने संशोधन के सुझावों की अनुमति दी, लेकिन पैच स्वीकार करने का कोई वादा नहीं किया और बाहरी रूप से पैच किए गए संस्करणों के बाहरी वितरण को अस्वीकार कर दिया।

  • इसने व्यावसायिक या सशुल्क परियोजनाओं में सॉफ्टवेयर के उपयोग की अनुमति दी, लेकिन स्वयं सॉफ्टवेयर की बिक्री को रोक दिया।

मुझे लगता है कि इसे "उपलब्ध स्रोत" कहा जा सकता है खुला स्रोत नहीं जैसा कि हम इसके बारे में सोचना चाहते हैं।

मैं देख सकता हूं कि किसी कंपनी की प्रबंधन टीम इस सॉफ्टवेयर के साथ व्यापार क्यों नहीं करना चाहेगी। वे इसे कांटा नहीं कर सकते, वे इसे बेच नहीं सकते, वे सॉफ़्टवेयर का अपना संस्करण नहीं बना सकते और इसे वितरित या बेच नहीं सकते।

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

तो हम जानते हैं कि एक कंपनी जो इस "उपलब्ध स्रोत" सॉफ़्टवेयर पर अपने व्यवसाय को आधार बनाना चाहती है, वह ऐसा नहीं कर सकती है, लेकिन सॉफ्टवेयर इंजीनियरिंग टीम के किसी व्यक्ति के रूप में, क्या वे अंतर आपके लिए महत्वपूर्ण हैं या क्या वे कम प्रासंगिक लगते हैं?

जिज्ञासु दूसरों के इस बारे में क्या सोचते हैं।


1
मुझे लगा कि OSS के बिंदु का एक हिस्सा यह था कि आप किसी और को स्वीकार करने और एक पैच को वितरित करने के लिए निर्भर नहीं थे, आपके पास स्रोत था ताकि आप पूरी चीज़ खुद कर सकें (एक प्रतिस्पर्धी शाखा / उत्पाद के रूप में पूरी चीज़ स्थापित करने सहित) यदि आप चाहते हैं)?
जॉन हॉपकिंस

संभावित डुप्लिकेट: प्रोग्रामर.स्टैकएक्सचेंज.
com

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

जवाबों:


5

परियोजनाओं के लिए जो इस सॉफ़्टवेयर द्वारा प्रदान की गई कार्यक्षमता को खरोंच से विकसित करना होगा, ऐसा न करना एक निश्चित सुविधा है।

लेकिन क्या एक तुलनीय खुला स्रोत पैकेज बेहतर होगा अन्य कारकों पर निर्भर करता है:

  • क्या इसका उपयोग किसी सेवा को प्रदान करने या किसी अन्य उत्पाद के हिस्से के रूप में बंडल करने के लिए किया जाएगा?
  • क्या उनके पास उत्पाद को स्वतंत्र रूप से बढ़ाने और बनाए रखने के लिए संसाधन हैं?
  • खुले स्रोत संस्करण (कोड या प्रोजेक्ट प्रबंधन में) पर इस सॉफ़्टवेयर का उपयोग करने के लिए कोई प्रतिस्पर्धात्मक लाभ है?

उत्तर देना नहीं इंगित करता है इन कारकों में से किसी को ओएसएस एक बेहतर विकल्प है।

अधिकांश समय, कोड ही निर्धारण कारक नहीं होता है। बड़ी तस्वीर की जांच करने की जरूरत है।

SIDEBAR OSS परियोजनाएं कानूनी रूप से वादा नहीं कर सकती हैं कि वे भविष्य के संस्करणों को खुला रखेंगे, या भविष्य के संस्करण होंगे। यही कारण है कि एक खुला लाइसेंस होना इतना फायदेमंद है। इसके अलावा, ओएसएस परियोजनाओं को योगदानकर्ताओं (विशेषकर स्वामित्व या अधिकारों के हस्तांतरण के बिना) से पैच स्वीकार करने की आवश्यकता नहीं है।


2

इस और किसी भी अन्य बाहरी पुस्तकालय के लिए सवाल रखरखाव है

आपके आवेदन का जीवनकाल क्या है और इस पुस्तकालय का स्पष्ट जीवनकाल क्या है? आपकी उम्मीद कम से कम होनी चाहिए।

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

यह सोचा अकेले पुस्तकालय का उपयोग करने के लिए महंगा बना सकता है।

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

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

क्या आप विचाराधीन पुस्तकालय पर चर्चा करने के लिए स्वतंत्र हैं?


2

ईमानदार होने के लिए, मैं यह नहीं देखता कि किसी कंपनी की प्रबंधन टीम को इस तरह के "उपलब्ध स्रोत" पुस्तकालय का उपयोग करने में समस्या क्यों होगी। जहां तक ​​उनके स्वयं के उत्पाद में एकीकरण का सवाल है, वे इसे केवल एक बंद-स्रोत पुस्तकालय के रूप में मान सकते हैं।

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

केवल वही स्थितियाँ, जहाँ, IMHO, "ओपन सोर्स" प्रश्न में उल्लिखित "उपलब्ध स्रोत" लाइसेंस को धड़कता है

  • हमारे उत्पाद के लाइसेंस में निहित पुस्तकालयों के स्रोतों के प्रकटीकरण की भी आवश्यकता है
  • हम पुस्तकालय के एक उन्नत / विस्तारित संस्करण के उत्पादन के व्यवसाय में हैं

1

यही कारण है कि फ्री सॉफ्टवेयर फाउंडेशन सॉफ्टवेयर का वर्णन करने के लिए 'फ्री' या 'नॉन-फ्री' शब्दों का उपयोग करता है । वे कीमत का उल्लेख नहीं कर रहे हैं, लेकिन प्रतिबंध जो सॉफ़्टवेयर के उपयोग या वितरण पर रखे गए हैं।

ऐसा लगता है कि आपने एक दुर्लभ कोने के मामलों में से एक को मार दिया है, जहां आपके पास किसी चीज़ के स्रोत कोड तक पूरी पहुंच है, लेकिन सॉफ्टवेयर OSI परिभाषा द्वारा "ओपन सोर्स" नहीं है ।

किसी भी शब्द में एक मिथ्या नाम बनने की क्षमता है। मैंने अपनी पहली प्रति emacs (QIC टेप पर) के लिए $ 50 का भुगतान किया, लेकिन emac मुफ्त सॉफ्टवेयर है । मेरे पास कुछ स्वामित्व अनुप्रयोगों के लिए स्रोत कोड है जो मेरी कंपनी आंतरिक रूप से उपयोग करती है, लेकिन वे खुले स्रोत नहीं हैं।

वह चीज जो सबसे बड़ा लाल झंडा उठाती है (कम से कम मेरे लिए) भविष्य के संस्करणों के स्रोत कोड तक पहुंचने की कोई गारंटी नहीं है। यदि आप इस उपकरण को संशोधित करने में सक्षम होना चाहते हैं, तो मैं सावधान रहूंगा। यहां तक ​​कि अगर आपके पास विक्रेता के साथ मौखिक समझौता है, तो आपके पास हमेशा कोड होगा, जब तक कि यह अनुबंध के रूप में नहीं है .. यह समझौता कभी नहीं हुआ।

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

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


-1

यह काफी मायने रखता है। आपके द्वारा वर्णित "उपलब्ध स्रोत" दृष्टिकोण के साथ मुख्य मुद्दे:

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

मेरा सुझाव: एक खुले स्रोत लाइसेंस के तहत सॉफ़्टवेयर को जारी करने के लिए निर्माता को मनाने की कोशिश करें। यह सभी के लिए एक जीत / जीत होनी चाहिए - आप क्योंकि आपको ओपन सोर्स लाइसेंसिंग के तहत इच्छित सॉफ़्टवेयर मिलता है, इसलिए निर्माता क्योंकि प्रोजेक्ट ओपन सोर्स बनाने से सॉफ़्टवेयर को लंबे समय में बहुत अधिक सफल बनाने की संभावना है।


बिल्ली "वास्तविक खुला स्रोत" है जो लाइसेंस मुझे वर्णन करता है वह मुझे वास्तविक लगता है।
रामहाउंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.