ओपन सोर्स लाइसेंस (जैसे जीएनयू-जीपीएल) का क्या अर्थ है?

Question

मैं एक ओपन सोर्स उत्पाद का उपयोग करने की उम्मीद कर रहा हूं जिसमें जीएनयू-जीपीएल लाइसेंस की तरह है और यह कहता है कि यदि मैं उस उत्पाद का उपयोग करता हूं, तो मुझे अपने आवेदन का स्रोत कोड साझा करना होगा।

मैं इसके बारे में थोड़ा उलझन में हूं। मैं समझता हूं कि लिनक्स जीएनयू-जीपीएल लाइसेंस के तहत भी उपलब्ध है। क्या इसका मतलब है सभी लिनक्स एप्लिकेशन ओपन सोर्स होना चाहिए? क्या इसका मतलब है कि मैं ओरेकल कॉर्प से कम से कम ओरेकल डीबी के स्रोत कोड के लिए पूछ सकता हूं (कम से कम वह हिस्सा जो लिनक्स पर चलता है)?

संपादित करें:

FAQ से लिया: एक पुस्तकालय जीपीएल (नहीं LGPL) के तहत जारी की है

हैं, तो इसका मतलब यह है है कि किसी भी कार्यक्रम का उपयोग करता है जो यह के तहत किया गया है जीपीएल या जीपीएल-संगत लाइसेंस?

हां, क्योंकि कार्यक्रम वास्तव में लाइब्रेरी में शामिल है।

Answer 1

यह जानना महत्वपूर्ण है कि "जीपीएल" दो लाइसेंसों का उल्लेख कर सकता है।

• GNU जनरल पब्लिक लाइसेंस
• GNU अल्प जनरल पब्लिक लाइसेंस (उर्फ) लाइब्रेरी जनरल पब्लिक लाइसेंस

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

अब, दो लाइसेंसों के बीच अंतर बहुत महत्वपूर्ण हो जाते हैं।

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

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

यदि ओरेकल ने जीपीएल कवर लाइब्रेरी के खिलाफ लोड या लिंक करने के लिए आवश्यक सॉफ़्टवेयर जारी किया है, तो कहें .. readline(), फिर हाँ, वे कोड साझा करने के लिए बाध्य होंगे। ओरेकल (यूनिक्स जैसे ऑपरेटिंग सिस्टम के लिए सॉफ़्टवेयर लिखने वाले कई अन्य लोगों की तरह) पुस्तकालयों को चुनने के लिए सावधान है जो अधिक अनुमोदित लाइसेंस (उर्फ 2 या 3-क्लॉज बीएसडी) के तहत जारी किए जाते हैं, या स्वयं को लागू करते हैं।

जहां तक ​​कर्नेल जाता है, बस अपने सिस्कल इंटरफ़ेस का उपयोग करके संयुक्त कार्य नहीं होता है। जबकि हम में से ज्यादातर सिस्टम सी लाइब्रेरी को इन जटिलताओं को दूर करते हैं, आप जो कुछ भी चाहते हैं उसके तहत अपने स्वयं के सिस्कोल को लागू करने के लिए पूरी तरह से स्वतंत्र हैं। यह दिखाता है कि सिस्टम सी पुस्तकालय के लिए एलजीपीएल एक बहुत ही रणनीतिक पसंद क्यों था। अगर यह दूसरी तरफ था, तो जीएनयू/लिनक्स ने अधिक डेवलपर्स को आकर्षित करने से रोक दिया होगा। ध्यान दें, कि कई लिनक्स शीर्षलेख जो कर्नेल के सिस्कल इंटरफ़ेस से बात करने के लिए आवश्यक जादू संख्याओं को परिभाषित करते हैं, उनमें कोई भी लाइसेंस निर्दिष्ट नहीं है। उदाहरण के लिए linux/sysctl.h देखें, या कर्नेल के साथ वितरित COPYING फ़ाइल में लिनस से यह नोट देखें:

नोट! यह कॉपीराइट नहीं कवर उपयोगकर्ता प्रोग्राम हैं जो सामान्य प्रणाली द्वारा गिरी सेवाओं का उपयोग करता है कहता है - इस केवल गिरी के सामान्य उपयोग माना जाता है, और नहीं गिरावट के तहत "व्युत्पन्न काम" के शीर्षक से करता है।इसके अलावा ध्यान दें कि नीचे दिए गए जीपीएल को कॉपीराइट सॉफ्टवेयर फ्री सॉफ्टवेयर फाउंडेशन द्वारा कॉपीराइट किया गया है, लेकिन कोड का उदाहरण (लिनक्स कर्नेल) को और अन्य लोगों ने वास्तव में लिखा है।

भी ध्यान रखें कि है लाइसेंस के इस विशेष संस्करण जीपीएल का ही मान्य संस्करण जहाँ तक गिरी का सवाल है (यानी वी 2, v2.2 नहीं या v3.x या जो कुछ भी), जब तक स्पष्ट रूप से अन्यथा कहा गया।

    Linus Torvalds 

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

संक्षेप में, यदि आप जीपीएल द्वारा कवर की गई लाइब्रेरी के खिलाफ लिंक या लोड करते हैं, तो आपको अपना कोड उसी लाइसेंस के तहत उपलब्ध कराना होगा। यदि आप एलजीपीएल द्वारा कवर की गई लाइब्रेरी के खिलाफ लिंक या लोड करते हैं, तो लाइसेंसिंग की शर्तें आपके ऊपर हैं।

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

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

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

यह विषय अभी भी उतना ही संवेदनशील है जितना 90 के दशक में था।

Answer 2

मेरा मानना ​​है कि आपके अधिकांश प्रश्न FAQ द्वारा कवर किए जाने चाहिए।

संक्षेप में: नहीं, सभी लिनक्स अनुप्रयोगों को ओपन सोर्स नहीं होना चाहिए। नहीं, आप ओरेकल डीबी के लिए स्रोत कोड के लिए नहीं पूछ सकते हैं।

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

Answer 3

लिनक्स कर्नेल है, कोई भी एप्लिकेशन सीधे कर्नेल का उपयोग नहीं करेगा, बल्कि लाइब्रेरी पर, आमतौर पर जीएलबीबीसी जिसे एलजीपीएल के तहत जारी किया जाता है। इससे जीपीएल श्रृंखला थोड़ी सी टूट जाती है क्योंकि जीएलबीबीसी कर्नेल को सिंक करता है लेकिन ऐसा लगता है कि ऐसा लगता है। तो मुझे डर है कि आपको ओरेकल से कोड नहीं मिलेगा :-)।

यदि आवेदन किसी भी जीपीएल लाइसेंस प्राप्त कोड का उपयोग करता है तो आपको उस आवेदन के लिए स्रोत कोड (केवल अपनी पसंद के लाइसेंस के तहत खुला स्रोत नहीं) को जीपीएल के तहत लाइसेंस प्राप्त करना होगा। इससे जीपीएल वास्तव में एक बहुत ही सीमित लाइसेंस बनाता है जो उत्पादों को "दूषित" कर रहा है, यही कारण है कि इसे वायरल लाइसेंस भी कहा जाता है।

Answer 4

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

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

FAQ कि एक previous answer में उल्लेख किया गया था इस मुद्दे का एक precise discussion होता है और हाथ की संबंध होने के रूप में जहां एक संकलक और कर्नेल अर्हता प्राप्त करने का एक उदाहरण देता है, और इस तरह संकलक किसी भी जीपीएल लाइसेंस के बिना अलग से जारी किया जा सकता है कि कर्नेल हो सकता है, बशर्ते कि रिहाई ठीक से हो।हालांकि, मुझे लगता है कि जीपीएल शामिल नियम के मुकाबले ज्यादा अपवाद है।

यह समझना महत्वपूर्ण है कि LGPL license की तुलना में इस संबंध में काफी अलग है, जो रिलीज़ के संबंध में अधिक अनुमोदित है।