अपने लक्ष्यों तक पहुँचने में GPL कितना सफल है? [बन्द है]

Question

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

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

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

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

Comments

GPL उपयोग पर कोई प्रतिबंध नहीं लगाता है । यह केवल वितरण है कि यह प्रतिबंध बनाता है।

— whatsisname

इसके विपरीत मालिकाना सॉफ्टवेयर के साथ होना चाहिए, न कि वाणिज्यिक। मुफ्त सॉफ्टवेयर के साथ बहुत सारे वाणिज्य चल रहे हैं।

— लार्स विर्जेनियस

एसआई ʇı ʇɐɥʍ यू ओ ɹǝƃuıɟ ʎɯ ʇnd ǝʇınb ʇ, uɐɔ ı ʇnq 'uǝʇʇıɹʍ sɐʍ ן dƃ ǝɥʇ uǝɥʍ ɯoɹɟ ʇuǝɹǝɟɟıp sɯǝǝs पी ןɹ oʍ ǝɥʇ ʇnoqɐ ƃuıɥʇǝɯos

— टिम पोस्ट

Answer 1

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

जीपीएल सॉफ्टवेयर्स का विरोध निश्चित रूप से linux और FSF (gcc, आदि ...) से आने वाली हर चीज का है। दिलचस्प बात यह है कि लिनेक्स के लिए, जीपीएल को उसके राजनीतिक रुख के लिए नहीं चुना गया था, लेकिन पारस्परिकता के विचार के कारण, जैसा कि लिनुस टोरवाल्ड ने कई बार कहा था। मैं आपको अपना कोड देता हूं, लेकिन अगर आप मेरा उपयोग करते हैं, तो आपको मुझे अपना एक्सचेंज देना होगा।

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

जीसीसी के लिए, स्टालमैन ने कई बार लिखा है कि जीपीएल ने "प्रॉप्रिटाइजेशन" के खिलाफ परियोजना को क्यों बचाया।

Comments

स्टैलमैन ने कई चीजें लिखी हैं जो शानदार हैं। उन्होंने कई ऐसी बातें भी लिखी हैं जिनका वास्तविकता से गहरा संबंध है। हिम ने दावा किया कि जीपीएल ने "प्रॉप्रिटैराइजेशन" के खिलाफ जीसीसी बचाई है, जरूरी नहीं कि यह ऐसा हो।

— मेरे सही चुनाव

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

— डेविड कूर्नापेउ

Oracle उदाहरण एक मान्य है, धन्यवाद। लिनक्स की सफलता के लिए, मुझे संदेह है कि जीपीएल बहुत मायने रखता है क्योंकि बीएसडी-लाइसेंस प्राप्त ओएस के स्पष्ट उदाहरण हैं। वे कुछ हद तक कम लोकप्रिय हैं, लेकिन मुझे अत्यधिक संदेह है कि जीपीएल इसका कारण है। Gcc के लिए, मुझे यकीन नहीं है कि वास्तव में 'प्रोप्रिटाइजेशन' का यहाँ क्या मतलब है, लेकिन Intel के अपने स्वामित्व वाले कंपाइलर (gcc से बेहतर) हैं, इसलिए यदि Stallman इस परिदृश्य को रोकना चाहते थे, तो वह असफल रहे।

— StasM

मेरा मतलब था कि अगर जीसीएस बीएसडी होते, तो लोग समुदाय को कोड दिए बिना अपने सुधार जोड़ सकते थे। जीसीसी (है) को इस तरह से लिखा गया था जैसे कि इसे निजी एपीआई के साथ एकीकृत किए बिना इसे विस्तारित करना मुश्किल था इसे रोकने के लिए ( gcc.gnu.org/wiki/GCC_Plugins )।

— डेविड कर्नप्यू

Answer 2

मैं कहूंगा कि अप्रतिबंधित लाइसेंस जैसे कि BSD, MIT और Apache लाइसेंस ने GPL की तुलना में FOSS को बढ़ावा देने के लिए कहीं अधिक किया है।

उदाहरण:

• कैसल परियोजना,
• jQuery,
• SQLite,
• अमरीका की एक मूल जनजाति,
• हाइबरनेट और nHibernate,
• ASP.NET MVC,
• JSON.ORG,

और बहुत सारे।

अधिकांश व्यवसाय जीपीएल को उनके विकास के प्रयास में कहीं भी जीपीएल कोड की अनुमति देने से सावधान हैं, जब तक कि व्यवसाय वास्तव में जीपीएल / मूल्य-वर्धित सेवाओं के मॉडल के तहत काम नहीं करता है।

Comments

अधिक सहमत नहीं हो सका।

— विन्यासकर्ता

मैं LGPL लाइसेंस का भी उल्लेख करूंगा, जो कुछ मुद्दों को मानक GPL के साथ संबोधित करता है: en.wikipedia.org/wiki/LGPL

— andre

उपरोक्त में से कोई भी FOSS लाइसेंसिंग को अपनाने को कैसे बढ़ावा देता है?

— मार्क एच

मुझे यह उत्तर समझ में नहीं आता है: कैसे कुछ परियोजनाओं को सूचीबद्ध करने से यह साबित होता है कि बीएसडी / एमआईटी ने ओपन सोर्स के लिए जीपीएल से अधिक काम किया है? आपको GPL प्रोजेक्ट्स (linux, gcc, gnome, kde, qt, mysql, emacs, आदि ...) के लिए एक समान सूची मिल सकती है, और यह किसी भी तरह से GPL को साबित नहीं करेगा।

— डेविड कुर्नाप्यू

@ जॉर्ज: हाँ, क्यूटी एलजीपीएल है, जीपीएल नहीं, भ्रम के लिए खेद है। मुझे नहीं लगता कि यह मेरी बात को बदलता है, हालांकि।

— डेविड कर्नैप्यू

Answer 3

GNU GPL अपने FLOSS प्रवर्तन के बावजूद सफल रहा है, इसके कारण नहीं। कंपनियां अधिकांश भाग स्वेच्छा से जीपीएल के तहत कोड जारी करने और जारी करने में योगदान कर रही हैं। इसके द्वारा कवर किए गए कोई महत्वपूर्ण एल्गोरिदम और पुस्तकालय नहीं हैं, जो वाणिज्यिक डेवलपर्स को वंचित करने के लिए मजबूर करेंगे।

Apple एक अच्छा उदाहरण बनाता है। उन्होंने KHTML को अपनाया और इसे WebKit में आगे बढ़ाया। और उन्होंने खुले स्रोत समुदाय को कोड वापस जारी किया। जबकि कोई यह मान सकता है कि एलजीएल द्वारा उन्हें मजबूर किया गया था, ऐसा लगता है कि संभावना नहीं है। डार्विन और बीएसडी उपयोगकर्ता के लिए वे बहुत स्वेच्छा से कोड प्रकाशित करते हैं। और LLVM के साथ उन्होंने एक नया FLOSS प्रोजेक्ट शुरू किया। फिर भी जाहिर है कि Apple काफी हद तक एक मालिकाना सॉफ्टवेयर विक्रेता है।

Android समान है। बेशक हार्डवेयर समर्थन यहां एक महत्वपूर्ण भूमिका निभाता है, लेकिन Google बीएसडी कोडबेस को अपना सकता था और इसे स्वामित्व में ले सकता था। लेकिन उन्होंने लिनक्स उठाया। इस प्रकार वे स्वेच्छा से वापस योगदान करते हैं, इसलिए नहीं कि गैर-जीपीएल विकल्प नहीं था।

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

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

Comments

अजीब बात है कि आपको एंड्रॉइड का उल्लेख करना चाहिए, क्योंकि यह जीपीएल में जानबूझकर एक खामियों को खोजने का तरीका है जो उन्हें एक अनम्य प्लेटफ़ॉर्म को जारी करने की अनुमति देता है। (कुछ जो बाद में GPL के संस्करण प्रतिबंधित हैं)। Google बिल्कुल उसी आदर्श को FSF के रूप में साझा नहीं करता है, और यह तथ्य कि Android FOSS सॉफ़्टवेयर काफी हद तक अप्रासंगिक है, क्योंकि किसी के पास अपने स्वयं के प्लेटफ़ॉर्म पर Google के साथ प्रतिस्पर्धा करने के लिए संसाधन नहीं हैं (यदि उनके पास चिंतित होने के लिए प्रतिस्पर्धा थी, तो वे होंगे) ve एक वैकल्पिक समाधान चुना)। इसके अलावा, Apple ने LLVM शुरू नहीं किया।

— मार्क एच

@sparkie: यह दिलचस्प है। कल ही मैंने एक लेख पढ़ा है जहाँ एक Google डेवलपर ने हैंडसेट विक्रेताओं को थर्ड पार्टी एंड्रॉइड फ़र्मवेयर के खिलाफ मोबाइल फोन को लॉक करने के लिए पटक दिया था। (हालांकि मुझे इस बात में कोई संदेह नहीं है कि Googles के ओपन सोर्स प्रयास ज्यादातर प्रेजेंटेशनल हैं।)

— mario

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

— 9000

Answer 4

जीएनयू मैनिफेस्टो को देखते हुए , यह स्पष्ट नहीं है कि एफओएसएस सॉफ्टवेयर जारी करने के लिए निगमों को आश्वस्त करना लक्ष्य में से एक था। यहाँ एक उद्धरण है:

ताकि मैं बिना बेईमानी के कंप्यूटरों का उपयोग करना जारी रख सकूं, मैंने एक पर्याप्त बॉडी को मुफ्त सॉफ्टवेयर के साथ रखने का फैसला किया है, ताकि मैं बिना किसी सॉफ्टवेयर के भी काम कर सकूं जो कि मुफ्त नहीं है।

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

Comments

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

— StasM

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

— लैरी कोलमैन

Answer 5

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

Comments

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

— डेविड कौरनाप्यू

Answer 6

मेरा व्यक्तिगत दृष्टिकोण एक व्यक्तिगत डेवलपर में से एक है, जो विकलांगता के कारण कुछ समय के लिए नियोजित नहीं है, और मेरे पास एकमात्र मूल्यवान कौशल से फिर से जीवन बनाने में सक्षम होने की उम्मीद (या सपने देखने) है।

GPL का उपयोग हर समय वाणिज्यिक परियोजनाओं के लिए किया जाता है। मुद्दा यह है कि कभी-कभी इसकी "वायरल" प्रकृति कहा जाता है, जिसका अर्थ है कि यदि आप किसी परियोजना में कुछ जीपीएल कोड का उपयोग करते हैं, तो आपको संभवतः उस परियोजना के लिए सभी कोड को जीपीएल करने की आवश्यकता है । कुछ गतिशील लिंकिंग के लिए एक बहिष्करण का दावा करते हैं। साझा डेटा संरचनाओं के कारण प्लग-इन पर GPL FAQ डायनेमिक लिंकिंग का दावा करता है - http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins। यह अजीब लगता है क्योंकि हर विंडोज़ एप्लीकेशन डायनेमिक-लिंक विन्डोज़ कम्पोनेंट्स और शेयर डेटा स्ट्रक्चर्स विथ विंडोज (एक एप्लीकेशन कई मायनों में एक ऑपरेटिंग-सिस्टम प्लग इन है), फिर भी जीएनयू द्वारा जारी जीपीएल विंडोज ऐप सहित बहुत सारे ऐप हैं। हो सकता है इसका मतलब यह है कि हैंडर्स के रूप में प्रच्छन्न संकेत और कार्यों के माध्यम से अधिकांश पहुंच डेटा संरचनाओं को साझा करने के रूप में गिना नहीं जाता है, जो किसी विशेष रूप से डिज़ाइन किए गए प्लगइन एपीआई या गतिशील रूप से जुड़े पुस्तकालय का उपयोग कर सकता है, लेकिन संभवतः एक व्यक्तिगत डेवलपर को सुरक्षित खेलना होगा ऐसे मुद्दों पर।

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

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

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

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

Comments

Windows कोर लाइब्रेरीज़ GPL के अंतर्गत नहीं हैं, इसलिए यदि आप उनसे लिंक करते हैं तो आपको अपना आवेदन GPL करने की आवश्यकता नहीं है। मुझे यकीन नहीं है कि वे किस लाइसेंस के तहत हैं, लेकिन यह एक ऐसा नहीं है जो कहता है, "यदि आप इससे लिंक करते हैं तो आपका आवेदन स्रोत बंद होना चाहिए।" समस्या केवल GPL लाइब्रेरी से लिंक करते समय है। विंडोज लाइब्रेरी जीपीएल नहीं हैं।

— jsternberg

मेरा कहना है कि आवेदन (प्रभावी रूप से एक ऑपरेटिंग सिस्टम प्लगइन) जीपीएल के तहत है। यदि यह गैर-जीपीएल फ़ोटोशॉप के लिए जीपीएल प्लगइन लिखने पर प्रतिबंध लगा दिया गया है (क्योंकि आप फ़ोटोशॉप स्रोत जारी नहीं कर सकते हैं), तो गैर-जीपीएल विंडोज के लिए जीपीएल "प्लगइन" लिखने पर प्रतिबंध क्यों नहीं लगाया गया है? उदाहरण के लिए विंडोज डायनेमिक-लिंक जैसे कि यूजर32.dll जैसे विंडोज डायनेमिक-लिंक पर चलने वाली कोई कमांड-लाइन एप्लिकेशन, और कंसोल I / O एपीआई के साथ डेटा संरचनाएं (न्यूनतम, स्ट्रिंग्स पर) साझा करती हैं। यह एक्सेस अप्रत्यक्ष रूप से, मानक पुस्तकालय एपीआई के माध्यम से किया जा सकता है, लेकिन जीएनयू लाइसेंस के तहत वितरित मानक पुस्तकालय कार्यान्वयन भी हैं।

— स्टीव 314

वास्तव में - मुझे लगता है कि जीएनयू लाइसेंस के तहत मानक पुस्तकालय हैं, लेकिन मुझे यकीन नहीं है कि जीपीएल का मतलब है।

— स्टीव

@ स्टीव ३१४: जीपीएल को और अधिक ध्यान से पढ़ें। आपको मानक सिस्टम घटकों से लिंक करने की अनुमति है, हालाँकि मुझे सटीक भाषा याद नहीं है। जीपीएल को सावधानीपूर्वक व्यावहारिकता के लिए डिज़ाइन किया गया था - एक निश्चित वैचारिक दृष्टिकोण को बढ़ावा देने में व्यावहारिकता, लेकिन फिर भी व्यावहारिकता।

— डेविड थॉर्नले

@ काम: जोड़ने के बारे में भूल जाओ, आदि ... जीपीएल कभी भी इसका उल्लेख नहीं करता है (एलजीपीएल करता है)। जीपीएल का कहना है कि एक व्युत्पन्न सॉफ्टवेयर, जीपीएल, जहां ली गई है purposedly अपरिभाषित छोड़ के तहत जारी किया जाना चाहिए, हालांकि यह विचार है कि यदि एक सॉफ्टवेयर के बिना मूल के बिना काम नहीं काफी परिवर्तन किया जा रहा है, यह व्युत्पन्न है। यदि आप एक OS के शीर्ष पर एक अनुप्रयोग का निर्माण करते हैं, तो OS अनुप्रयोग का व्युत्पन्न नहीं है (संबंध चिंतनशील नहीं है)

— David Cournapeau

Answer 7

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