क्या LGPL मुझे ऐसा करने की अनुमति देता है?


16

मैं एक LGPL सॉफ्टवेयर का उपयोग करके एक वाणिज्यिक सॉफ्टवेयर विकसित करने की योजना बना रहा हूं।

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

फिर मैं अपने मालिकाना सॉफ्टवेयर में उन कार्यों को लागू करने की योजना बना रहा हूं। मैं संशोधित LGPL कोड वितरित करने के लिए तैयार हूं, लेकिन मालिकाना सॉफ्टवेयर नहीं है जो मेरे इच्छित तरीके से कार्य करता है।

क्या यह LGPL के नियमों और शर्तों का उल्लंघन करता है?



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

बताना कठिन है। इसे पढ़ें: javalobby.org/java/forums/t15903.html - वे जावा के बारे में बात कर रहे हैं, लेकिन यह किसी भी ओओ भाषा पर लागू होता है।
माइक Baranczak

जवाबों:


26

यह एक जटिल प्रश्न है, लेकिन मेरा मानना ​​है कि आप जो प्रस्ताव देते हैं, उसकी अनुमति नहीं है।

आप लाइब्रेरी में हुक जोड़ने का सुझाव दे रहे हैं जिससे आपको लाइब्रेरी को सब-क्लास करना आसान हो जाए और इस तरह, बहुत कम से कम। LGPL की भावना को दरकिनार करना ।

समस्या यह है, यदि आप एक वर्ग को उप-वर्ग करते हैं, जो आपके ही कोड में LGPL लाइसेंस के अधीन है , तो आपका काम पुस्तकालय के आधार पर एक काम बन जाता है , बजाय एक काम के जो पुस्तकालय का उपयोग करता है, जिसका अर्थ है कि आपका कोड एक व्युत्पन्न है वह कार्य जो धारा 6 ( LGPL v2.1 ) के तहत कवर किए गए एक के बजाय धारा 2 ( LGPL v2.1 ) के अंतर्गत आता है । यानी यह LGPL के अधीन हो जाता है !

मुझे लगता है कि स्टीफन कोलबोर्न ने ज्वालामुखी पर एक अच्छा सारांश प्रदान किया है

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

वैकल्पिक रूप से, आप सीधे एफएसएफ से पूछ सकते हैं । उनके संपर्क पृष्ठ से :

मुफ्त सॉफ्टवेयर लाइसेंसिंग और कॉपीराइट के बारे में प्रश्नों के लिए

कृपया हमारे लाइसेंसिंग FAQ , लाइसेंस सूची , सामान्य कॉपीलेफ्ट जानकारी और संबंधित पृष्ठों की जांच करें । यदि प्रश्न बने रहते हैं, तो ईमेल करें <licensing@gnu.org>।

संयोग से, संबंधित प्रश्न में प्रतिबिंब और LGPL में , gbjbaanb LGPL 3.0 परिप्रेक्ष्य के साथ उत्तर देता है


4
मुझे "एफएसएफ से पूछें" सुझाव पसंद है
जेडजेआर

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

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

6
LGPL 3.0 में कहा गया है: "लाइब्रेरी द्वारा परिभाषित क्लास के एक उपवर्ग को परिभाषित करना लाइब्रेरी द्वारा प्रदान किए गए इंटरफ़ेस का उपयोग करने का एक तरीका माना जाता है।" इसलिए इसे कम से कम LGPL 3.0 के तहत अनुमति दी जानी चाहिए।
डेविड

3
@ डेविड - मेरा मानना ​​है कि एलजीपीएल लाइब्रेरी को संशोधित करके आप एक ऐसे फ़ंक्शन को ओवरराइड करने की अनुमति दे सकते हैं, जो सामान्य रूप से ओवर-राइड नहीं हो सकता है। पुस्तकालय के साथ 'संबंध' द्वारा उपयोग किया जाता है, इसलिए कमजोर कॉपीलेफ्ट सक्रिय हो जाता है।
मार्क बूथ

13

मानक मैं एक वकील अस्वीकरण नहीं हूँ।

LGPL को आपके स्रोत का उपयोग करने वाले किसी भी व्यक्ति को वितरित किए जाने वाले पुस्तकालय स्रोत कोड में संशोधन की आवश्यकता होती है। इसकी आवश्यकता नहीं है कि आपका कोड, जो लाइब्रेरी का उपयोग करता है, खुले-खट्टे हो और उसी लाइसेंस के तहत जारी किए जाएं।

वर्गीय विरासत पर एक खंड सहित LGPL के अधिक विस्तृत, लेकिन गैर-वकील विवरण के लिए विकिपीडिया


+1। संक्षेप में: हमें लगता है कि यह LGPL (लेकिन IANAL) का उल्लंघन नहीं करता है
MarkJ

@ मर्कज - जैसा कि मैं अपने जवाब में समझाता हूं , मुझे यकीन नहीं है कि जैसा कि सामने आया है, सवाल बस वर्गीय विरासत का मामला है।
मार्क बूथ

9
मुझे लगता है कि लोग IANAL टाइप करना पसंद करते हैं क्योंकि इसमें "ANAL" होता है।
g33kz0r

5

"मैं एलजीपीएल कोड को संशोधित करना चाहता हूं ..." यह पर्याप्त कहता है कि आपको उस संशोधित कोड को जारी करना होगा । फिर यह विस्तारित करना कि क्या संशोधित कोड एक व्युत्पन्न कार्य है, विवाद के लिए है और यदि यह LGPL के अधीन है।

ऐसा प्रतीत होता है कि आप एलजीपीएल को दरकिनार कर रहे हैं, इस मामले में इन तकनीकों के साथ आप नहीं कर सकते हैं।

यदि यह एक व्युत्पन्न कार्य है, तो प्रोग्राम की शर्तों को "ऐसे संशोधनों को डीबग करने के लिए ग्राहक के स्वयं के उपयोग और रिवर्स इंजीनियरिंग के लिए संशोधन" की अनुमति देनी होगी। एलजीएल कार्यक्रम का उपयोग करने वाला कार्य एक व्युत्पन्न कार्य है या नहीं यह एक कानूनी मुद्दा है।

लेकिन अगर आप जो करने की कोशिश कर रहे हैं वह एलजीपीएल को दरकिनार कर रहा है तो मैं मार्क बूथ द्वारा अनुशंसित एफएसएफ से संपर्क करूंगा ।


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

@MarkBooth मैं आपसे और अन्य लोगों से सहमत हूं कि इस मामले में यह work based onतब से है जब वे पहले निजी कोड को उजागर करने के लिए LGPL में बदलाव कर रहे हैं।

1

मेरा अनुमान: (लेकिन IANAL) आपको एलजीपी कोड के रूप में संशोधित पुस्तकालय को खुले स्रोत के रूप में जारी करना चाहिए और फिर इसे एक वाणिज्यिक कार्यक्रम में छोड़ देना चाहिए। इससे काम बन जाएगा। प्रभावी रूप से आप लाइब्रेरी के चारों ओर एक खुला स्रोत कांटा होगा और फिर आप इसके लिए एक फ्रंट एंड बेच रहे होंगे।

लेकिन जैसा कि कई अन्य लोगों ने ठीक कहा है, एफएसएफ से पूछें : यह एक पेचीदा देशज परिदृश्य है जो आपके पास है; यदि आप इसे लागू करते हैं या नहीं, तो वे बहुत सोच रहे होंगे। (या कम से कम इसके बारे में पर्याप्त रूप से परेशान करें जैसे कि विषय पर एक एफएक्यू प्रविष्टि प्रकाशित करें)


1

https://www.gnu.org/licenses/lgpl-java.html

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

संक्षेप में, विरासत के साथ कोई समस्या नहीं है जब तक आप पुस्तकालय कोड को स्वयं नहीं बदलते हैं, लेकिन यदि आप इसे बदलते हैं, तो भी आपको केवल लाइब्रेरी संशोधित कोड जारी करने की आवश्यकता होती है, न कि आपके आवेदन कोड की।


1
आपका उत्तर कई अन्य उत्तरों का खंडन करता है लेकिन आपके दावों को वापस करने के लिए बहुत कुछ प्रदान नहीं करता है। अन्य उत्तर अधिक विस्तृत हैं और उनके कथनों को समझाने का बेहतर काम करते हैं। अपना दावा वापस करने के लिए कृपया लाइसेंस या एफएसएफ से प्रासंगिक उद्धरण प्रदान करने के लिए अपना उत्तर संपादित करें।

वास्तव में मेरा उत्तर मेरे दावों को वापस करने के लिए कितना प्रदान नहीं करता है? मैंने आधिकारिक GNU पेज पर लिंक डाल दिया है जो LGPL और वर्ग की विरासत के बारे में भ्रम को साफ करता है। इसे LGPL v3 को कवर करने के लिए भी अपडेट किया गया है।
निक.बी

1
इसे भी देखें: meta.stackexchange.com/questions/225370/…
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.