2009-12-06 15 views
17

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

इसका मतलब यह है जीपीएल लाइसेंस वास्तव में है पर जो एक पहले "निर्मित" है निर्भर करता है? यदि स्वामित्व पुस्तकालय पहले बनाया गया है (जैसे कि विंडोज डीएलएल) जो बिना किसी लिंकिंग और जीपीएल कोड के प्रकाशित होते हैं और बाद में एक जीपीएल प्रोग्राम इसके साथ जुड़ा हुआ है, तो जीपीएल प्रोग्राम मालिकाना पुस्तकालय को जीपीएल में परिवर्तित नहीं कर सकता है हालांकि मालिकाना कोड है जीपीएल कोड के साथ "जुड़ा हुआ"।

यदि यह मामला है, कंपनी इस तरह NVIDIA या रियलनेटवोर्क्स निम्नलिखित कर सकते हैं? आइए मान लें कि वे स्वामित्व वाले एचडीडीकोडिंग मीडिया डिकोडिंग इंजन लाइब्रेरी को निजी रखना चाहते हैं, लेकिन वे अपने हार्डवेयर को प्रदर्शित करने के लिए ओपनसोर्स जीपीएल कोड को "लीवरेज" करना चाहते हैं।

  1. वे मीडिया डिकोडिंग करने के लिए एक मालिकाना पुस्तकालय बनाते हैं और कुछ नमूना कोड जारी करते हैं।
  2. कोई (ओपनसोर्स विकास) "प्लगइन" कि इस तरह के XBMC, Mplayer या वीएलसी के रूप में GPLed कोड के लिए इस मालिकाना पुस्तकालय में जुड़ा हुआ है बनाता है।
  3. उनका तर्क कर सकते हैं कि जब से वे मालिकाना पुस्तकालय बनाया गया पहला (सिर्फ एमएस की तरह सभी DLLs पहले बनाना), जीपीएल कार्यक्रमों है कि उनके स्वामित्व कोड के साथ लिंक उन्हें जीपीएल कोड में गुप्त नहीं है। सिद्धांत रूप में

एक कर सकते हैं का कहना है कि खुले स्रोत डेवलपर हैं जो जीपीएल vlc.exe फ़ाइल कि NVidia मालिकाना डीकोडर पुस्तकालय के साथ लिंक बनाता है जीपीएल लाइसेंस उल्लंघन कर रहा है।

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

केस 2: इसमें क्या गलत है:

NVIDIA के लिए एक नया हार्डवेयर मतिहीनता पुस्तकालय है कि खाल नवीनतम ग्राफिक्स कार्यों बना सकते हैं। वे इस पुस्तकालय के साथ एक फ्रीबीएसडी ड्राइवर भी बनाते हैं और बीएसडी चालक का स्रोत कोड जारी करते हैं लेकिन लाइब्रेरी स्रोत कोड नहीं।

किसी ने (लिनक्स डेवलपर) को लागू कर सकते हैं। Linux ड्राइवर है कि इस पुस्तकालय Linux के लिए एक NVIDIA ग्राफ़िक्स ड्राइवर बनाने के लिए साथ लिंक लेकिन चूंकि एनवीडिया ने ऐसा नहीं किया है, इसलिए वे "लिनक्स समर्थन" सक्षम करते समय लाइब्रेरी स्रोत को "छुपा" रख सकते हैं।

यह निश्चित रूप से जीपीएल की भावना का उल्लंघन करता है।

तो इसका मतलब यह है कि विंडोज़/मैक/iPhone/PSP3 में GPLed स्रोत के साथ बनाए गए किसी भी exe चल भी जीपीएल की भावना का उल्लंघन करता है?

+4

मैं इस प्रश्न को ऑफ-विषय के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि ** यह लाइसेंसिंग या कानूनी मुद्दों ** के बारे में है, प्रोग्रामिंग या सॉफ्टवेयर विकास नहीं। [यहां देखें] (http: //meta.stackoverflow।कॉम/ए/274964/1402846) विवरण के लिए, और [सहायता/विषय] अधिक के लिए। –

उत्तर

8

जीएनयू जीपीएल पूछे जाने वाले प्रश्न से:

Can I apply the GPL when writing a plug-in for a non-free program?

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

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

भी सवाल I am writing free software that uses a non-free library देखें।

और:

What legal issues come up if I use GPL-incompatible libraries with GPL software?

जीपीएल के दोनों संस्करणों की उनके copyleft के लिए एक अपवाद है, आमतौर पर प्रणाली पुस्तकालय अपवाद कहा जाता है। तो जीपीएल असंगत पुस्तकालयों आप एक प्रणाली पुस्तकालय के लिए मानदंडों को पूरा उपयोग करना चाहते हैं , तो आप के लिए कुछ भी उन्हें इस्तेमाल करने के लिए विशेष कर नहीं है; पूरे प्रोग्राम के लिए स्रोत कोड वितरित करने की आवश्यकता में उन पुस्तकालयों को शामिल नहीं किया गया है, भले ही आप किसी लिंक किए गए निष्पादन योग्य को वितरित करते हैं।

"सिस्टम लाइब्रेरी" के रूप में गणना के मानदंड जीपीएल के विभिन्न संस्करणों के बीच भिन्न होते हैं। GPLv3 स्पष्ट रूप से परिभाषा से बाहर करने के लिए "सिस्टम पुस्तकालय" खंड 1 में , को परिभाषित करता है "संगत स्रोत।" GPLv2 अंत खंड 3 के के पास, निम्नलिखित कहते हैं:

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

...

+0

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

+0

यह ध्यान रखना बहुत महत्वपूर्ण है कि हर कोई जीपीएल आत्मसमर्पण के एफएसएफ के संस्करण से सहमत नहीं है। –

+0

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

0

IANAL, लेकिन निर्माण के क्रम में कोई फर्क नहीं पड़ता। यदि दो द्विआधारी लिंकिंग जीपीएल का उल्लंघन होगा, तो जीपीएल द्वारा इसकी अनुमति नहीं है, भले ही पहले बनाया गया था।

केस 1, प्रणाली पुस्तकालय अपवाद द्वारा संबोधित किया जाता है के रूप में माइकल बर उद्धृत। ध्यान दें कि यह समय-निर्भर नहीं है - अगर यह सिस्टम लाइब्रेरी अपवाद के लिए नहीं था, तो यह विंडोज 98 पर 2003 में लिखे गए जीपीएल कोड को चलाने के लिए जीपीएल उल्लंघन का उतना ही होगा (जिसे जीपीएल कोड से पहले लिखा गया था) इसे Vista पर चलाने के लिए होगा (जिसे जीपीएल कोड के बाद लिखा गया था)।

मैं मानता हूं कि केस 2 जीपीएल की भावना का उल्लंघन करता है, लेकिन, जैसा कि शब्द जीपीएल द्वारा उपयोग किया जाता है, क्योंकि एनवीडिया ड्राइवर लिनक्स कर्नेल के साथ "लिंक" नहीं है क्योंकि इसे मॉड्यूल के रूप में लोड किया जाता है। आप लिनक्स कर्नेल को गैर-निशुल्क एनवीडिया बाइनरी के साथ स्थिर रूप से लिंक करने में सक्षम नहीं होंगे, लेकिन इन दिनों किसी भी तरह से स्थैतिक रूप से जुड़े कर्नेल वितरित करते हैं?

5

आपके पास जीपीएल प्रतिबंध लागू होने के तरीके की मौलिक गलतफहमी है। आपका पहला उदाहरण "सिस्टम लाइब्रेरी छूट" द्वारा कवर किया गया है - लेकिन यदि यह नहीं था, तो इसका प्रभाव आपके पास सकारात्मक नहीं होगा।

जीपीएल का कहना है कि यदि आप जीपीएल कार्यक्रम या इसके व्युत्पन्न को वितरित करते हैं, तो आपको कार्यक्रम या व्युत्पन्न को जीपीएल समकक्ष शर्तों के तहत स्रोत प्रदान करना होगा (जिन लोगों को आपने प्रोग्राम/व्युत्पन्न वितरित किया है)।

इसका मतलब है कि यदि मैं आपके जीपीएल प्रोग्राम को माइक्रोसॉफ्ट के कुछ कोड से जोड़ता हूं, तो मुझे स्रोत को मोम की पूरी गेंद को प्रदान करना होगा, या आपके कॉपीराइट को तोड़ने के लिए आपके द्वारा मुकदमा चलाया जा रहा है। ध्यान दें कि जब तक माइक्रोसॉफ्ट एक तीसरी पार्टी है, तो यह पर (बिल्कुल!) पर कोई प्रतिबंध नहीं लगाता है। अगर मेरे पास माइक्रोसॉफ्ट के कोड तक पहुंच नहीं है, जो संभवतः है, तो मैं आपके लाइसेंस का उल्लंघन किए बिना उस व्युत्पन्न कार्य को वितरित नहीं कर सकता।

0

आप उन्हें जोड़ने से अन्य प्रोग्राम लाइसेंस बदल नहीं सकते हैं, कभी नहीं। यदि आपका लाइसेंस गैर-मुक्त स्रोत कार्यक्रमों को जोड़ने की अनुमति नहीं देता है तो आपको या तो अपना लाइसेंस बदलना होगा या उन कार्यक्रमों से लिंक करना बंद करना होगा। यदि अन्य कार्यक्रम आपके साथ जुड़े हैं तो स्थिति अलग होगी। उस स्थिति में उन्हें अपने लाइसेंस को रोकना होगा या अपने कार्यक्रम से जुड़ना बंद कर देना चाहिए।

0

इसका मतलब क्या है, बस यह है कि आप कोड या पुस्तकालयों के शीर्ष पर जीपीएल लागू नहीं कर सकते हैं जो compatible with the GPL नहीं हैं और एक संकलित संयुक्त कार्य वितरित नहीं करते हैं, जब तक आप linking exception लागू नहीं करते।

लिंकिंग अपवाद आपके लिए गैर-मुक्त बिट्स युक्त संकलित निष्पादन योग्य वितरित करने का एक तरीका प्रदान करता है, जबकि स्रोत प्रारूप में प्रोग्राम वितरित करने के लिए कोई विशेष अनुमति की आवश्यकता नहीं होती है।

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

तो, अपने पहले प्रश्न का उत्तर देने के लिए, नहीं .. यह 'चिकन या अंडा' परिदृश्य नहीं है। जब मैं अपवाद लिखने की संभावना से सामना करता हूं, तो मैं अनुशंसा करता हूं कि अपाचे या 3 क्लॉज बीएसडी लाइसेंस जैसे कम प्रतिबंधों के साथ लाइसेंस चुनना बेहतर होगा।

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

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

यह सबसे बड़ा कारण है कि लिनक्स (कर्नेल में) केवल जीपीएल वी 2 बना हुआ है।