क्या आपको हर स्रोत फ़ाइल के साथ एक लाइसेंस नोटिस शामिल करना होगा?

Question

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

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

क्या कोई कारण है कि मैं अपनी परियोजनाओं में इस तरह के नोटिस को शामिल करना चाहूंगा, या बस एक नोटिस में शामिल होगा READMEऔर एक @licenseटैग काफी अच्छा होगा? क्या यह अधिकांश लाइसेंसों के "स्पष्ट रूप से कहा गया" नियम को प्रभावित करता है, या क्या यह सिर्फ इतना अधिक है कि लोग बहस नहीं करेंगे?

Comments

आपके संपादक को आपको लाइसेंस को 1 पंक्ति में मोड़ने / छिपाने की अनुमति देनी चाहिए।

— पाब्बी

यथार्थवादी रूप से, यदि कोई आपके कोड को स्टील करता है, तो एक चर का नाम बदलकर कॉपीराइट हटा देगा और क्या अदालत इन 2 फाइलों को समान मान लेगी?

— NoChance

@ ईमद: नहीं, अदालत यह नहीं कहेगी कि वे समान हैं। (लेकिन वे "अनिवार्य रूप से समान" हो सकते हैं।) हाँ, एक अदालत यह कहेगी कि यह कॉपीराइट का उल्लंघन है।

— एंड्रयू डलके

प्रासंगिक: softwareengineering.stackexchange.com/a/19653/94635

— Ioannis Filippidis

इसके अलावा: opensource.stackexchange.com/a/322/7022

— Ioannis फिलिपिडिस

Answer 1

मेरी समझ में, GPLv3 दृढ़ता से सुझाव देता है (या शायद इसकी आवश्यकता भी है, कम से कम यह कि मैं पाठ को कैसे समझता हूं कि इन शर्तों को आपके नए कार्यक्रमों में कैसे लागू किया जाए , इसकी धारा 17 के बाद) प्रत्येक स्रोत फ़ाइल में एक कॉपीराइट नोटिस। इसे कहते हैं

ऐसा करने के लिए, कार्यक्रम को निम्नलिखित नोटिस संलग्न करें। वारंटी के बहिष्करण को प्रभावी ढंग से बताने के लिए प्रत्येक स्रोत फ़ाइल की शुरुआत में उन्हें संलग्न करना सबसे सुरक्षित है; और प्रत्येक फ़ाइल में कम से कम "कॉपीराइट" लाइन और एक पॉइंटर होना चाहिए जहां पूर्ण नोटिस पाया जाता है।

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

और जीएनयू परियोजनाएं जो एफएसएफ के स्वामित्व वाली हैं, जैसे जीसीसी, हर फाइल में ऐसा नोटिस है।

मुझे एक कार्यक्रम (J.Pitrat's CAIA सिस्टम) के बारे में भी पता है, जो एक मुफ्त सॉफ्टवेयर सामुदायिक वेब साइट पर मना कर दिया गया है क्योंकि इसकी हर फाइल में ऐसा कोई नोटिस नहीं था।

मैं एक वकील नहीं हूं , लेकिन मेरा मानना ​​है कि जीपीएलवी 3 कार्यक्रम के हर स्रोत फ़ाइल में इस तरह का नोटिस व्यावहारिक रूप से अनिवार्य है ।

^{(यदि आप अन्य लाइसेंस का उपयोग करते हैं, विशेष रूप से एक गैर-एफएसएफ एक, तो इसे लागू करने के तरीके के बारे में ध्यान से पढ़ें; वाईएमएमवी; हालांकि AFAIK हर फाइल में एक नोटिस लिख रहा है, नुकसान नहीं पहुंचाएगा।)}

Comments

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

— एंड्रयू डल्के

मैं सहमत हूं, और मैंने उद्देश्य पर "स्रोत फ़ाइल" कहा। दरअसल, CAIA की प्रणाली स्मालटाक की तरह थोड़ी है: छवि डेटा फ़ाइलों में है, और CAIA "स्रोत फाइलें" मैंने उल्लेख किया है कि सी फाइलें उत्पन्न होती हैं। हालांकि, मेरा जीसीसी एमईएलटी (एफएसएफ कॉपीराइट के तहत जीसीसी की एक शाखा) भी मेटा-प्रोग्राम्ड है, और मैं उत्पन्न सी फाइलों में कॉपीराइट नोटिस टिप्पणियों को उत्पन्न करने के लिए ध्यान रखता हूं (और मैंने उन्हें हाथ से लिखे सी एंड एमईएलटी कोड में डाल दिया)।

— बेसाइल स्टारीनेवविच

मुद्दा लेना। मैं अब MELT के बारे में एक पैराग्राफ जानता हूं। सामान्य तौर पर यह सबसे अच्छा है कि उत्पन्न फ़ाइलों में कॉपीराइट नोटिस शामिल है क्योंकि लाइसेंस को "संलग्न" करना बहुत कठिन है अन्यथा। जैसे, "yacc" और "lex" प्रतिबंधित हैं कि वे क्या कर सकते हैं।

— एंड्रयू डेल्के

व्यक्तिगत अनुभव से: सावन पर एक परियोजना को स्वीकार करने के लिए आपके पास प्रत्येक फ़ाइल में एक लाइसेंस होना चाहिए।

— Mael

बस स्पष्ट करने के लिए, GPL FAQ के अनुसार, #LicenseCopyOnly और #NoticeInSourceFile इस लेखन के समय, यह आवश्यक नहीं है कि कैसे लागू किया जाए ... हर स्रोत फ़ाइल पर पाठ; ध्यान दें कि भाषा "चाहिए" का उपयोग करती है और "नहीं" चाहिए। हालांकि, वे दृढ़ता से अनुशंसा करते हैं कि आप इस अभ्यास का पालन करें।

— शून्य रात्रि

Answer 2

मैंने कई परियोजनाएँ देखी हैं जो केवल README में लाइसेंस का उल्लेख करती हैं या एक LICENSE या COPYING फ़ाइल में।

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

यदि कोई आपके सॉफ़्टवेयर का उपयोग करता है तो उन्हें लाइसेंस समझौते का पालन करना चाहिए, या वे जो कर सकते हैं उस पर उचित उपयोग प्रतिबंधों का पालन करें।

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

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

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

संक्षेप में, आपको प्रत्येक फ़ाइल में लाइसेंस डालने की आवश्यकता नहीं है। मुझे लगता है कि यह ओवरकिल है। ऐसा करने में कोई अतिरिक्त कानूनी सुरक्षा नहीं है। यह कुछ हद तक डाउनस्ट्रीम उपयोगकर्ता की मदद करता है, लेकिन बहुत अधिक नहीं।

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

उदाहरण के लिए, डिफॉल्ट एक्लिप्स टेम्प्लेट प्रत्येक फ़ंक्शन से पहले मुझे लगता है कि बेकार मेटाडेटा के बारे में क्या कहता है, जो मुझे लगता है कि संस्करण नियंत्रण द्वारा बहुत बेहतर कब्जा कर लिया गया है। लेकिन कई दुकानों में यह प्रथा आम है।

Comments

उदाहरण के लिए, मुझे Rails स्रोत फ़ाइलों में लाइसेंस से संबंधित कुछ भी दिखाई नहीं देता है।

— एंटोन बार्कोवस्की

और शीर्ष-स्तरीय पायथन मानक पुस्तकालय में 200 फाइलों में, केवल 34 में "कॉपीराइट" शब्द शामिल है, और उनमें से केवल 4 पायथन सॉफ्टवेयर फाउंडेशन के लिए हैं, जो कॉपीराइट को पायथन को नियंत्रित करता है।

— एंड्रयू डल्के

हाँ, मुझे नहीं लगता कि प्रति-फ़ाइल कॉपीराइट नोटिस पिछले जा रहे हैं ... यह अभी भी बहुत ज्यादा है .. यह अभी भविष्य का तरीका नहीं हो सकता है .. सोचें DRY ... रूट स्तर LICENSE, और चलो इसे एक दिन बुलाओ .. मुझे लगता है कि

— npm

Answer 3

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

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

Comments

क्या स्रोत फ़ाइल के विभिन्न अंशों को कॉपी-पेस्ट के माध्यम से अलग करना आसान नहीं है? फिर क्या? यह तर्क मुझे असंगत लगता है।

— ट्रैविस ग्रिग्स

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

— रिच रीमर

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

— xenoterracide

Answer 4

एक भूमिगत बंकर में कोई गुप्त महाशक्ति बैठक नहीं है जो कहती है कि आपको इसे प्रत्येक स्रोत फ़ाइल में रखना होगा।

यह उपयोगकर्ता को यह स्पष्ट कर देता है कि यह फ़ाइल जो भी लाइसेंस के तहत है और वास्तव में अधिकांश जीपीएल सॉफ़्टवेयर में एक छोटा प्रस्तावना है जिसमें लाइसेंस को पढ़ने के लिए कहा जाता है। याद रखें कि परियोजनाएँ अलग हो जाती हैं और फ़ाइलें पुन: उपयोग हो जाती हैं, इसलिए केवल एक ही फ़ाइल में संदेश डालना एक अच्छा विचार नहीं हो सकता है।

यदि किसी अप्रत्याशित घटना में यह कभी अदालत में गया हो तो आपके पास अधिक दावा हो सकता है यदि आपने प्रत्येक फ़ाइल को अपने काम के रूप में स्पष्ट रूप से चिह्नित किया था और यह किस लाइसेंस के तहत था - तब कोई भी दावा नहीं कर सकता था कि उन्होंने सोचा था कि यह प्रेटिकल फ़ाइल कवर नहीं की गई थी

Answer 5

मैंने लगभग एक समान प्रश्न पोस्ट किया। झुंझलाहट के बारे में कम और तकनीकी के बारे में अधिक। टीएल; डीआर: मेरा मानना ​​है कि उत्तर लेखक की प्राथमिकताओं का विषय है। शायद इरादे प्राथमिकता से ज्यादा सटीक होंगे ...

मेरा मानना ​​है कि "ओके" की आपकी परिभाषा के आधार पर, आपके स्रोत में लाइसेंस का संदर्भ देना ठीक है। आइए इस बात से सहमत हैं कि "अपुष्ट" शब्द एक स्रोत फ़ाइल को इंगित करता है जो एक परियोजना का हिस्सा है जिसे बेरहमी से इसे प्यार कोड आधार से अलग किया गया है। कहा फ़ाइल में इस तरह की एक पंक्ति है:

# This file is covered by the LICENSING file in the root of this project.

या इस तरह एक बहुत कूलर लाइन:

* @license OMGBBQ <http://goodlics.com/bbq>

"लेकिन रुकें!" , आप कहते हैं, "आपने अभी कहा कि फ़ाइल को उसके प्रोजेक्ट से अलग कर दिया गया था! और goodlics.com एक डोमेन स्क्वैटर पर रीडायरेक्ट करता है! ट्राइसेप पर जा रहा रोकें!" आप सही हैं, मैंने कहा था कि, लेकिन यह ठीक हो सकता है, और मुझ पर चिल्लाना बंद करो। यहाँ मेरे वकील का तर्क नहीं है:

• लगभग हर देश [बर्न] कन्वेंशन को महसूस करने के लिए सहमत हो गया है, जिसका मतलब है कि AFAIK का मतलब है कि यदि आप कुछ बनाते हैं, तो आपके पास उस पर कॉपीराइट है, अवधि। आपको (c) लाइन या उस जैसी किसी भी बकवास की आवश्यकता नहीं है, लेकिन वह सामान (प्लस थर्ड पार्टी VCS जैसे GitHub) यह साबित करना आसान बनाता है कि आपने इसे बनाया और जब आपने इसे बनाया।
• इसलिए, यदि आप अपने द्वारा बनाए गए कुछ रसदार 1337 कोड को ऑनलाइन पोस्ट करते हैं, तो आपके पास इस पर कॉपीराइट है। किसी को भी (कानूनी रूप से) इसकी नकल करने की अनुमति नहीं है। यह दुर्लभ है, और चौंकाने वाला है, मुझे पता है, लेकिन मैंने सुना है कि लोग कभी-कभी कानून तोड़ते हैं। यह अभी भी संभव है।
• यह कमाल nyancat-bcminer-algo.qbasicफ़ाइल आप ने लिखा है और या नहीं लाइवजर्नल पर पोस्ट किया जाता है, यह विश्वास, नहीं सार्वजनिक डोमेन। जब तक आप यह नहीं कहते कि यह सार्वजनिक डोमेन है। डिफ़ॉल्ट रूप से यह आपका और आपका अकेला है। यह ... कीमती है । (कम से कम 25-50 + साल के लिए, जब तक आप डिज़्नी न हों।)
• लोग पारंपरिक रूप से इस आशय का संचार करते हैं (कुछ या सभी अधिकारों को आप और आपके अकेले नहीं) लाइसेंसधारियों के माध्यम से; लेकिन आपको उस इरादे की घोषणा करने की आवश्यकता है; यह ऑप्ट-आउट ऑप्ट-आउट (HAHA GET IT) है? अपने कॉपीराइट से बाहर निकलने का विकल्प? AWESOME)। अपने टिकट निकालो, हम लगभग वहाँ हैं!
• यदि यह ठीक है कि उपरोक्त अप्रकाशित फाइलें निजी डोमेन हैं - अर्थात, कानूनी रूप से प्रतिलिपि नहीं है, तो संभावित रूप से टूटे हुए संदर्भ का उपयोग करना पूरी तरह से ठीक है। हालांकि, अगर यह ठीक नहीं है , तो मुझे लगता है कि आपको हर स्रोत फ़ाइल के भीतर लाइसेंस पाठ को शामिल करने की आवश्यकता है। इस तरह से, बिना साथी फ़ाइलों को अभी भी जिस तरह से आप prioriti-- लाइसेंस प्राप्त करना सुनिश्चित हैं इरादा । हाँ, यह बेहतर है।

यह तर्क दो महाकाव्य और संभवतया अमान्य धारणाएँ बनाता है:

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

बंदर-मस्तिष्क वायुमार्ग की सवारी के लिए धन्यवाद।

डिस्क्लेमर: यह मेरे लिए तर्कसंगत लगता है कि मैं 90% सुनिश्चित हूं कि मैं 100% गलत हूं।

Answer 6

लाइसेंस और प्रस्तावना में अंतर है ।

अपनी कुछ परियोजनाओं में मैं जीएनयू जनरल पब्लिक लाइसेंस, संस्करण 3.0 का उपयोग कर रहा हूं । GNU GPL के लिए हर स्रोत कोड फ़ाइल पर प्रस्तावना आवश्यक है:

प्रस्तावना और निर्देश GNU GPL के अभिन्न अंग हैं और इन्हें छोड़ा नहीं जा सकता है।

स्रोत: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

तो यहाँ मैं क्या कर रहा हूँ:

1. License.txt जोड़ें

नियमों का पालन करने के लिए मैंने अपनी परियोजना के भंडार की जड़ में एक LICENSE.txt डाला । यह GitHub द्वारा भी सुझाया गया है (देखें " लाइसेंस कहां रहता है" )।

2. ऑटो फोल्ड का उपयोग करके प्रस्तावना जोड़ें

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

तो यहाँ है कि यह कैसा दिखता है:

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

मुझे लगता है कि यह आराम और कानूनी सुरक्षा के बीच एक बहुत अच्छा समझौता है।

यदि आपके पास बहुत सी परियोजनाएँ हैं जहाँ आपको लाइसेंस जोड़ने की आवश्यकता है, तो http://www.addalicense.com/ मदद की हो सकती है।

कृपया ध्यान दें: मेरी सलाह GPLv3 को संदर्भित करती है। अन्य लाइसेंस प्रकारों को प्रस्तावना की आवश्यकता नहीं हो सकती है।

Comments

«जीएनयू जीपीएल प्रत्येक स्रोत कोड फ़ाइल पर प्रस्तावना होना आवश्यक बनाता है:» यह नहीं करता है। आपके द्वारा उद्धृत किया गया भाग आपको LICENSEफ़ाइल से प्रस्तावना को निकालने से रोकता है , अर्थात आप इसे ड्रॉप करके GPL के पाठ को बदल नहीं सकते।

— एंड्रिया लेज़रोज़ेटो

Answer 7

यहाँ अभी तक उल्लेख नहीं किया गया एक और व्यावहारिक तरीका है।

SPDX-License-Identifierटैग। https://spdx.org/using-spdx

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

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

इसके अलावा, सॉफ्टवेयर सप्लाई-चेन विश्लेषण को स्वचालित करने वाले लोग मशीन-पठनीय लाइसेंस विवरण के एक सामान्य मानक से चिपके रहने के लिए आभारी होंगे।