केवल ओपन सोर्स समुदाय का समर्थन करने के लिए सही लाइसेंस ढूँढना। GPLv3 बहुत सख्त, LGPLv3 भी अनुमत

Jan 03 2021

मैंने एक ओपन सोर्स लाइब्रेरी बनाई है ( https://github.com/pitschr/knx-link) जो अन्य खुले स्रोत परियोजनाओं द्वारा उपयोग किए जाने के लिए डिज़ाइन किया गया है; अंत उपयोगकर्ताओं द्वारा नहीं। वर्तमान में इसे GPLv3 के रूप में लाइसेंस प्राप्त है।

मेरा मुख्य लक्ष्य यह है कि मेरी लाइब्रेरी का उपयोग करने वाली प्रत्येक परियोजना को खुला स्रोत होना चाहिए । मेरे लिए व्यक्तिगत रूप से यह कोई फर्क नहीं पड़ता कि मेरी लाइब्रेरी का उपयोग करने वाली अन्य परियोजना को उदाहरण के लिए Apache-2.0 या MIT पर लाइसेंस प्राप्त है, जब तक कि अंतिम उपयोगकर्ता द्वारा उपयोग की जाने वाली परियोजना उदाहरण GitHub पर खुली नहीं है।

विभिन्न लाइसेंसों के आधार पर मैं यह देखता हूं कि:

  • LGPLv3 सही विकल्प नहीं होगा क्योंकि यह एक मालिकाना सॉफ्टवेयर से जुड़ा होने की अनुमति देता है
  • GPLv3 मेरे लिए बहुत सख्त प्रतीत होता है, क्योंकि यह लागू करता है कि अन्य सॉफ्टवेयर को GPLv3 के रूप में भी लाइसेंस प्राप्त करने की आवश्यकता है। इसके अलावा, GPLv3 को Apache-2.0 / MIT के तहत लाइसेंस प्राप्त एक परियोजना द्वारा उपयोग करने की अनुमति नहीं है
  • Apache-2.0 और MIT लाइसेंस मेरे लिए विकल्प नहीं हैं क्योंकि वे सीधे मालिकाना सॉफ्टवेयर द्वारा उपयोग किए जा सकते हैं

मुझे अपने उद्देश्य के लिए सही लाइसेंस नहीं मिला। फिर से, यह मेरे पुस्तकालय का उपयोग करने के लिए पूरी तरह से ठीक है, जब तक कि अंत-उपयोगकर्ता परियोजना / सॉफ़्टवेयर स्वयं ही खुला स्रोत नहीं है कि इसे GPLv3 के तहत लाइसेंस प्राप्त करने की आवश्यकता है ? मेरा मुख्य लक्ष्य केवल खुले स्रोत समुदाय का समर्थन करना है!

क्या मैं इस विचार के साथ अकेला हूँ? सबसे अच्छा तरीका क्या है? मेरे लिए कौन सा लाइसेंस सबसे उपयुक्त होगा?

धन्यवाद, क्रिस्टोफ़ (जो थोड़ा भ्रमित है)

जवाब

4 planetmaker Jan 03 2021 at 16:46

खुले स्रोत लाइसेंसों पर दो मूलभूत रूप से भिन्न हैं:

क) एमआईटी, अपाचे आदि जैसे - जो मोटे तौर पर बोल रहे हैं - परवाह नहीं करते कि उनके स्रोतों का क्या होता है जब तक कि क्रेडिट बनाए रखा और संचार किया जाता है।

ख) और अधिक सख्ती से खुला स्रोत लाइसेंस है, कॉपी-बाएं लाइसेंस, जो यह सुनिश्चित करना चाहते हैं कि कोई भी व्युत्पन्न अवशेष भी खुला स्रोत है, विशेष रूप से जीपीएल लाइसेंस।

लाइसेंस को आमतौर पर (प्रारंभिक) लेखकों द्वारा इस कारण से चुना जाता है कि वह पहले या बाद में चाहता है।

इस तरह के एक लाइसेंस के रूप में आप की तलाश में तैयार किया जा सकता है, लेकिन कम उपयोग करता है: एक अनुज्ञापत्र-लाइसेंस प्राप्त परियोजना एक लाइसेंस का उपयोग नहीं करना चाहेगी जो केवल ओपन-सोर्स प्रोजेक्ट में उपयोग किया जा सकता है; इसके लाइसेंस को विशेष रूप से चुना गया था ताकि मालिकाना उपयोग संभव हो।

पहले से ही कॉपी-लेफ्ट लाइसेंस वाली परियोजना को इस तरह के लाइसेंस की आवश्यकता नहीं है - यह जीपीएल का उपयोग भी कर सकता है जो यह सुनिश्चित करता है कि: खुला स्रोत रहें और खुला स्रोत रहें।

इस तरह, यह भी तर्क दिया जा सकता है कि एक लाइसेंस जो केवल एक ओपन सोर्स प्रोजेक्ट में ही उपयोग किया जा सकता है: जीपीएल। अधिकांश ओपन सोर्स लाइसेंस इस अर्थ में जीपीएल के साथ संगत हैं कि उनका उपयोग जीपीएल-लाइसेंस प्राप्त परियोजना में किया जा सकता है (केवल व्युत्पन्न / संयुक्त सॉफ्टवेयर के लिए लाइसेंस को जीपीएल में बदलकर - तब भी जब उल्लेखनीय अपवाद अपाचे या एमपीएल के साथ असंगति की तरह मौजूद हैं। ) का है।

3 JNic Jan 08 2021 at 06:48

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

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

जीएनयू जीपीएल के साथ संगत लाइसेंस हैं। जीएनयू जीपीएल-लाइसेंस प्राप्त सॉफ़्टवेयर में किसी भी संगत लाइसेंस के तहत कोड हो सकता है।