क्या जीपीएल में कोई खामी है जो मालिकाना सॉफ्टवेयर को जीपीएल पुस्तकालयों के साथ जोड़ने की अनुमति देती है?


15

आइए एक काल्पनिक परिदृश्य की जांच करें:

कंपनी एक्स एक मालिकाना कार्यक्रम (ए) लिखता है जो गतिशील रूप से एक मालिकाना पुस्तकालय (बी) के साथ जोड़ता है। कंपनी Y, GPL के तहत लाइसेंस प्राप्त लाइब्रेरी (C) का उपयोग करना चाहती है, और इसलिए एक रैपर लाइब्रेरी (D) लिखती है, जो A और C दोनों से गतिशील रूप से लिंक करती है और C द्वारा उपयोग की जाने वाली API कॉलों में A द्वारा प्रयुक्त API कॉल का अनुवाद करती है।

जैसा कि डी को सी के साथ उपयोग करने का इरादा है, और सी की एपीआई कॉल का उपयोग करता है, यह सी का एक व्युत्पन्न कार्य है और इसलिए इसे जीपीएल * की शर्तों के तहत वितरित किया जाना चाहिए। नतीजतन, ए और डी के संयुक्त काम को भी जीपीएल की शर्तों के तहत वितरित किया जाना चाहिए, जो कि असंभव है कि कंपनी वाई के पास ए के लिए स्रोत कोड नहीं है, इसलिए कहा गया है, जब तक कि कंपनी वाई खुद डी वितरित करती है। , कोई समस्या नहीं है। हालाँकि, कंपनी Y की कार्रवाइयों की परवाह किए बिना, कंपनी X, A को वितरित करके GPL का उल्लंघन नहीं करता है, यहां तक ​​कि B. के बिना भी D के अस्तित्व में होने का यह अर्थ नहीं है कि A, C का एक व्युत्पन्न कार्य है (D के माध्यम से) जिसे लाइसेंस प्राप्त होना चाहिए साथ ही जी.पी.एल.

अब यह खामी है: ऐसा कुछ भी नहीं है जो कंपनी एक्स को डी के अपने स्वयं के संस्करण को लिखने से रोकता है, इसे ए से अलग से वितरित करता है, और एंड-यूजर्स को ए चलाने के दौरान बी के बजाय डी का उपयोग करने के लिए कहता है। ऐसा लगता है कि एक कंपनी सक्षम है जीपीएल का उल्लंघन किए बिना एक जीपीएल पुस्तकालय का उपयोग करने के लिए एक मालिकाना कार्यक्रम डिजाइन करना, इसलिए जब तक कि जीपीएल पुस्तकालय से मालिकाना कार्यक्रम को इन्सुलेट करने के लिए एक आवरण मॉड्यूल का उपयोग किया जाता है और उस मॉड्यूल को अलग से वितरित किया जाता है।

क्या मैं अपने तर्क में सही हूं? क्या यह जीपीएल में एक वास्तविक खामियाजा है?

* डी भी ए का व्युत्पन्न कार्य है, लेकिन इस परिदृश्य के प्रयोजनों के लिए, कंपनी एक्स ने स्पष्ट रूप से डी के निर्माण को अधिकृत किया है और इसे जीपीएल के तहत लाइसेंस प्राप्त करने की अनुमति दी है।


1
संक्षिप्त उत्तर: नहीं।
whatsisname

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

4
@tdammers: AFAIK गतिशील जोड़ने करता मेकअप कोड एक व्युत्पन्न काम करते हैं, और आप सही हैं, यह शायद संभव नहीं BSD लाइसेंस के तहत सॉफ्टवेयर वितरित करने के लिए जब यह जीपीएल libs का उपयोग करता है। यही कारण है कि बहुत सारे ओपन सोर्स लाइब्रेरी के लेखक जीपीएल के बजाय एलजीपीएल के तहत अपने काम की पेशकश करते हैं।
डॉक्टर ब्राउन

2
@tdammers: इस परिदृश्य के प्रयोजनों के लिए, मैं स्टालमैन के दृष्टिकोण को जोड़ने के लिए ले जा रहा हूं: गतिशील और स्थिर दोनों लिंकिंग जीपीएल का उल्लंघन करते हैं।
माइकल कौरलस

3
@mouviciel अदालत के फैसले से संकेत मिला है कि अंतर के उद्देश्यों के लिए एपीआई की प्रतिकृति बनाना कानूनी है। मेरा मानना ​​है कि यह स्वतंत्र रूप से अमेरिका और यूरोपीय संघ दोनों में उच्च-स्तरीय अदालतों द्वारा पाया गया है, इसलिए कानूनी स्थिति बहुत ठोस है (जब तक कि कोई कानून को सक्रिय रूप से नहीं बदलता है)।
डोनल फैलो

जवाबों:


10

IANAL, लेकिन यहाँ GPL की सीमा के भीतर अनुमति दी गई है:

  • सार्वजनिक रूप से संयुक्त काम "ए - बी" वितरित करें: ठीक है, किसी भी मालिकाना लाइसेंस के तहत किया जा सकता है

  • C: Y के लिए C के लिए एक आवरण लिबास D बनाएं: ठीक है, इसका मतलब यह नहीं है कि A को GPL के तहत रखा जाना है

  • संयुक्त उत्पाद "ए - डी - सी" का आंतरिक रूप से वाई द्वारा उपयोग करें: यह भी ठीक है, जब तक संयोजन जनता को वितरित नहीं किया जाता है तब तक जीपीएल को स्रोत ए को खोलने की आवश्यकता नहीं है।

  • सार्वजनिक रूप से संयुक्त कार्य "ए - डी - सी" वितरित करें: इसके लिए ए को खुले-खट्टे होने और जीपीएल के तहत रखे जाने की आवश्यकता होगी (और इससे कोई फर्क नहीं पड़ता अगर एक्स या वाई ने इस संयोजन को वितरित किया है; इसके अलावा, यदि वाई करना चाहता है; यह कि, उन्हें X से A के लिए वितरण लाइसेंस की आवश्यकता होगी, बेशक)

अब दिलचस्प सवाल यह है कि क्या GPL के तहत खुले स्रोत के रूप में D & C को अलग से वितरित किया जा सकता है, A & B (या सिर्फ A बिना B) को एक मालिकाना लाइसेंस के तहत वितरित किया जा सकता है, और अंतिम-उपयोगकर्ता B और D & C द्वारा स्वयं के द्वारा प्रतिस्थापित करता है?

यहां "एबी" के लिए अंतिम संशोधन जो ए डिबेट पर निर्भर करता है डी एंड सी अंतिम उपयोगकर्ता द्वारा किया जाता है - वितरण के बाद । तो कोई यह तर्क दे सकता है कि अंतिम संशोधन केवल अंत उपयोगकर्ता द्वारा आंतरिक रूप से किया जाता है। और ऐसा लगता है कि यह वास्तव में जीपीएल का उल्लंघन किए बिना संभव है - और जो आपको मिलता है वह "एसी एंड डी" का एक काम संयोजन है जहां ए मालिकाना लाइसेंस के तहत है और जीपीएल के तहत सी एंड डी है।

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

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

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

EDIT2: दोहरे लाइसेंस वाले काम उपलब्ध हैं, गैर-व्यावसायिक उपयोग के लिए GPL लाइसेंस और वाणिज्यिक उपयोग के लिए एक मालिकाना लाइसेंस , जैसे कि। तो आपके "लूपहोले" का अर्थ होगा कि इस तरह के लिब पर आधारित उत्पाद विकसित करना (वाणिज्यिक संस्करण का उपयोग करना, इसलिए जीपीएल आपके उत्पाद पर लागू नहीं होता है), अपने उत्पाद को सार्वजनिक रूप से बिना लिबास के बंद-स्रोत के रूप में वितरित करें और अंत दें। उपयोगकर्ता स्वयं द्वारा GPLed संस्करण प्राप्त और स्थापित करता है। इस तरह के एक मामले के लिए, मुझे लगता है कि लिबर के विक्रेता के पास लाइसेंस उल्लंघन के लिए आपके ऊपर मुकदमा करने का एक अच्छा मौका होगा (यदि आप उसके परिवाद के लिए भुगतान नहीं करते हैं, तो निश्चित रूप से)। क्या यह परेशानी के लायक है? शायद ऩही। विशेष रूप से मेरे द्वारा जुड़े उदाहरण में, आपको या तो लिबास खरीदना होगा, क्योंकि मूल्य निर्धारण इस बात पर निर्भर नहीं है कि आप अपने उत्पाद को कितनी बार बेचते हैं, लेकिन केवल कितने देव विकास के दौरान लिब का उपयोग कर रहे हैं।

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


2
मेरी आंत की भावना मुझे बताती है कि अगर कंपनी कॉम्बो का Aविज्ञापन करना शुरू कर देती है तो वकील और भी मज़ाक करना शुरू कर देंगे A - C&D
बार्ट वैन इनगेन शेनॉ

1
@BartvanIngenSchenau: मैं सहमत हूं। लेकिन मैं एक अलग परिदृश्य की कल्पना कर सकता हूं: एक्स एबी को वितरित करता है, और वाई केवल एक इंस्टॉलर के साथ एक "ऐड-ऑन" सी और डी को वितरित करता है (और विज्ञापित करता है) जो एबी के इंस्टॉल फ़ोल्डर में बी की जगह लेता है?
डॉक ब्राउन

मैं उस वैकल्पिक परिदृश्य की भी कल्पना कर सकता हूं, और वकीलों के लिए इसमें एक छेद डालना Aऔर C&Dविभिन्न कानूनी संस्थाओं से आना बहुत कठिन होगा ।
बार्ट वैन इनगेन शेनॉ

1
@DocBrown: क्या समतुल्य मालिकाना पुस्तकालय B का अस्तित्व भी मायने रखता है? क्या कंपनी X इस धारणा के तहत खुद को A नहीं बेच सकती कि अंत उपयोगकर्ता को इसका उपयोग करने के लिए एक कार्यशील पुस्तकालय खोजना होगा, फिर "सुविधापूर्वक" उन्हें D प्रदान करें?
माइकल कौरलैस

1
@MichaelKourlas: लिबास बी का अस्तित्व सी के विक्रेता के लिए एक्स पर मुकदमा करने के लिए बहुत कठिन बना देगा, क्योंकि यह एक्स के लिए यह प्रमाण देना आसान बनाता है कि ए सी का "व्युत्पन्न काम" नहीं है
डॉक्टर ब्राउन

3

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

एक अन्य उत्तर का दावा है "चूंकि कार्यक्रम पुस्तकालय पर निर्भर करता है इसलिए यह अभी भी एक व्युत्पन्न कार्य है" - लेकिन यदि कार्यक्रम वास्तव में काम नहीं करता है क्योंकि पुस्तकालय नहीं है, तो यह व्युत्पन्न नहीं है।

लेकिन अंत में, यदि आप "कमियां" पर भरोसा करते हैं तो आपको यह विचार करना चाहिए कि आपका दृष्टिकोण पहली जगह में सही नहीं हो सकता है।


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

1

लिंकिंग GPL द्वारा एक व्युत्पन्न को परिभाषित करता है। यह विशिष्ट स्थिति वह है जिसे LGPL ने हैंडल करने के लिए डिज़ाइन किया था: जहाँ आप लाइब्रेरी को GPL के रूप में रिलीज़ करना चाहते हैं, लेकिन लिंक किए गए लाइसेंस की स्पष्ट सीमा के रूप में लिंकिंग को परिभाषित करते हैं, या वैकल्पिक रूप से, जहाँ आप कुछ GPL कोड के विरुद्ध लिंक करना चाहते हैं, लेकिन इसके लिए आपका स्वयं का होना आवश्यक है कार्य गैर-जीपीएल लाइसेंस के तहत ही जारी किया जाएगा।

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

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


0

मैं एक वकील नहीं हूं, लेकिन जहां तक ​​मैं आपको बता सकता हूं कि आप सही नहीं हैं, क्योंकि कार्यक्रम पुस्तकालय पर निर्भर करता है - यह अभी भी एक व्युत्पन्न काम है। उसी तरह जो एक अनुक्रमिक एक व्युत्पन्न कार्य है। कम से कम यह पुस्तकालय में परिभाषित एपीआई पर आधारित है।


एक रैपर मॉड्यूल को शामिल करके एपीआई समस्या को ठीक नहीं किया जा सकता है जिसे आप कॉपीराइट के मालिक हैं? (देखें windyroad.com.au/2006/04/20/… जो मैं बात कर रहा हूँ, उसके एक उदाहरण के लिए)
माइकल कौरलस

मैंने आवरण घटक को जोड़ने के लिए प्रश्न को अपडेट किया है।
माइकल कौरलस

@ user92103 क्या यह सामान्य प्रश्न आपके प्रश्न को संबोधित करता है? gnu.org/licenses/gpl-faq.html या यह P.SE प्रश्न: प्रोग्रामर.स्टैकएक्सचेंज.
अप्सिलर्स

1
@apsillers: P.SE प्रश्न नेटवर्क पर क्लाइंट-सर्वर संचार से संबंधित है। हालांकि यह निश्चित रूप से जीपीएल को दरकिनार करने का एक संभव तरीका है, यह वही है जो मैं यहां (डायनेमिक लिंकिंग) के बारे में बात कर रहा हूं। मैंने GPL FAQ को देखा, और उनके पास एक रैपर मॉड्यूल से निपटने वाला प्रश्न है, लेकिन यह प्रश्न मानता है कि वितरक वितरण के बिंदु पर मालिकाना आवेदन के साथ GPL लाइब्रेरी को बंडल करता है। इस मामले में, अंतिम उपयोगकर्ता बंडलिंग कर रहा है, जो नाटकीय रूप से चीजों को बदलता है।
माइकल कौरलस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.