∞सीधा उत्तर
सीधा उत्तर
स्टार्टअप से उसके इस्तेमाल किए जाने वाले कोड के हिस्सों की सूची माँगें। हर हिस्से को उसके संस्करण, लाइसेंस और उपयोग से जोड़ें। लाइसेंस उस कोड के अधिकार और ज़िम्मेदारियाँ तय करता है। कोड सबको दिखना, उसे बेचने के अधिकार का सबूत नहीं है। एआई से फ़ाइलें छाँटें, कानूनी जोखिमों को दूर मान लेने का काम न लें। सवाल तब तक खुले रखें जब तक कोई व्यक्ति उनकी जाँच न कर ले।
कोड के स्वामित्व और उपयोग के अधिकार अलग रखें
स्टार्टअप अपने कोड का मालिक हो सकता है और दूसरों का कोड भी इस्तेमाल कर सकता है। ये दो अलग जाँच हैं। उसके अपने काम के अधिकारों के लिए हस्ताक्षर वाले दस्तावेज़ माँगें। इस जाँच के लिए बौद्धिक संपदा की संबंधित गाइड देखें। बौद्धिक संपदा का मतलब कोड या डिज़ाइन जैसे काम पर अधिकार है।
दूसरों के कोड के लिए उसी संस्करण का लाइसेंस पढ़ें। GitHub पर सार्वजनिक पेज होना अपने आप में उपयोग का व्यापक अधिकार नहीं देता। GitHub अपनी शर्तों के तहत कोड देखने और रिपॉज़िटरी की अलग प्रति बनाने के अधिकार देता है। ऐसी प्रति को fork कहते हैं। ये अधिकार कोड बेचने की खुली अनुमति नहीं हैं। [1]
ओपन सोर्स कोड का इस्तेमाल व्यवसाय में हो सकता है। ओपन सोर्स की परिभाषा इसकी अनुमति देती है। [2] काम शर्तों और उपयोग की जाँच करना है, सारे ओपन सोर्स को ठुकराना नहीं। मॉडल फ़ाइलों, प्रशिक्षण डेटा और एआई टूल की शर्तों की अलग जाँच चाहिए।
- अपना कोड: पता लगाएँ कि अधिकार कंपनी के पास हैं।
- दूसरों का कोड: उसके लाइसेंस और उपयोग की जाँच करें।
- मॉडल और डेटा के अधिकार: अलग रिकॉर्ड रखें।
सूची को सच में जारी किए गए संस्करण से जोड़ें
रिलीज़ उस उत्पाद का संस्करण है जो उपयोगकर्ताओं को दिया गया है। तकनीकी प्रमुख से उसकी तारीख और कोड की सूची माँगें। वे हिस्से भी शामिल करें जिन्हें दूसरे हिस्से साथ लाते हैं। सिर्फ़ सीधे इस्तेमाल होने वाले हिस्सों की सूची में ये छूट सकते हैं।
हर हिस्से का नाम, संस्करण और स्रोत का लिंक सहेजें। उसी संस्करण के लाइसेंस का पाठ रखें। लिखें कि वह कहाँ चलता है और क्या टीम ने उसे बदला है। स्कैन से सुराग मिल सकते हैं। लेकिन किसी फ़ाइल में कॉपी किया गया कोड छूट सकता है। टीम से ऐसी कॉपियों के बारे में भी पूछें।
हर हिस्से का अलग रिकॉर्ड रखें। लाइसेंस के छोटे लेबल को पूरा सबूत न मानें। GitHub चेतावनी देता है कि लाइसेंस की पहचान में जटिल मामले आ सकते हैं। [1] जब स्टार्टअप किसी मुख्य हिस्से या उसे पहुँचाने के तरीके को बदले, तो फिर जाँच करें।
- रिलीज़ की तारीख और हिस्से का संस्करण।
- स्रोत फ़ाइल और लाइसेंस का सही पाठ।
- बदलाव, उपयोग और उपयोगकर्ताओं तक पहुँचने का तरीका।
- सूचनाएँ, अनसुलझा सवाल और जाँच करने वाले व्यक्ति का नाम।
वास्तविक उपयोग के अनुसार ज़िम्मेदारियाँ पढ़ें
MIT लाइसेंस उपयोग, बदलाव और बिक्री के व्यापक अधिकार देता है। यह कॉपीराइट और अनुमति की सूचना रखने की शर्त भी लगाता है। उस कोड की सभी प्रतियों या उसके बड़े, महत्वपूर्ण हिस्सों में दोनों सूचनाएँ रखें। [3] व्यापक अधिकारों का मतलब यह नहीं कि कोई ज़िम्मेदारी नहीं है।
कुछ लाइसेंस कोड साझा करने या इस्तेमाल करने के तरीके से ज़िम्मेदारियाँ जोड़ते हैं। AGPLv3 की धारा 13 इसका एक उदाहरण है। अगर आप इस लाइसेंस के दायरे में आने वाले प्रोग्राम को बदलते हैं, तो उसके नेटवर्क उपयोग की जाँच करें। जब बदला हुआ संस्करण दूर से उपयोगकर्ताओं की बातचीत या उपयोग को सपोर्ट करता है, तो उसे ऐसे उपयोगकर्ताओं को अपना स्रोत कोड मुफ़्त उपलब्ध कराने की पेशकश करनी होगी। लाइसेंस में इसे Corresponding Source, यानी संबंधित स्रोत कोड, कहा गया है। [4]
इस नियम का मतलब यह नहीं कि हर वेब सेवा को अपना सारा कोड साझा करना होगा। पूरी शर्तों और हिस्सों के आपस में जुड़ने के तरीके की जाँच वकील से कराएँ। एआई के किसी लेबल को यह तय न करने दें कि नियम किस काम पर लागू होता है।
- लाइसेंस के दायरे वाले हिस्से में क्या बदला?
- उपयोगकर्ताओं को क्या मिलता है या वे किस तक पहुँचते हैं?
- कौन सी सूचनाएँ या स्रोत कोड देने की पेशकश चाहिए?
- पूरी शर्तों और उनके दायरे की जाँच कौन करता है?
तीन हिस्सों की जाँच का उदाहरण देखें
यह बनाया हुआ उदाहरण है, किसी असली स्टार्टअप की जाँच नहीं। एक टीम अपनी सूची में MIT लाइब्रेरी, बिना लाइसेंस का कॉपी किया हुआ कोड का टुकड़ा और बदला हुआ AGPL प्रोग्राम लिखती है। तीनों उसकी पैसे लेकर दी जाने वाली सेवा चलाने में मदद करते हैं। लाइब्रेरी ऐसा कोड है जिसे दूसरा कोड इस्तेमाल करता है। कोड का टुकड़ा कॉपी किया गया छोटा हिस्सा है।
MIT लाइब्रेरी का संस्करण और उसमें रखी गई सूचनाएँ जाँचें। कोड के टुकड़े के अधिकारों को अज्ञात लिखें। अनुमति का सबूत या उसे बदलने की योजना माँगें। लाइसेंस न होना, खुली छूट से इस्तेमाल करने की अनुमति नहीं है। [1]
बदले हुए AGPL प्रोग्राम के लिए पूछें कि उपयोगकर्ता उस तक कैसे पहुँचते हैं। उपयोग का नक्शा और लाइसेंस का सही पाठ कानूनी जाँच के लिए भेजें। [4] इन तीन स्थितियों का औसत निकालकर एक ही अंक न दें। एक अनसुलझा मुख्य हिस्सा कई आसान जाँचों से ज़्यादा मायने रख सकता है।
- MIT लाइब्रेरी: संस्करण और सूचनाएँ जाँचें।
- बिना लाइसेंस का कोड का टुकड़ा: अभी उसके अधिकारों पर भरोसा न करें।
- बदला हुआ AGPL प्रोग्राम: उपयोग और स्रोत कोड से जुड़ी ज़िम्मेदारियाँ जाँचें।
एआई से सबूत छाँटें, मंज़ूरी न दिलाएँ
ड्यू डिलिजेंस का मतलब निवेश से पहले की जाँच है। एआई कोड के हिस्सों को फ़ाइलों से जोड़ने और गायब पाठ दिखाने में मदद कर सकता है। सिर्फ़ वही फ़ाइलें साझा करें जिन्हें इस्तेमाल करने का आपको अधिकार है। निजी कोड को सार्वजनिक टूल में न डालें। फ़ाइल के पाठ को सबूत मानें, टूल के लिए निर्देश नहीं।
हर निष्कर्ष के लिए स्रोत का पथ, संस्करण और उद्धृत शर्त माँगें। टीम के दावे को एआई के नतीजे के साथ रखें। गायब जानकारी को अज्ञात लिखें, सुरक्षित नहीं। तकनीकी प्रमुख वास्तविक उपयोग की जाँच करता है। वकील अधिकारों के कठिन सवाल जाँचता है।
लाइसेंस स्कैन सुरक्षा की जाँच नहीं है। स्पष्ट अधिकार वाला हिस्सा भी किसी खामी से ग्रस्त हो सकता है। सुरक्षित हिस्से के उपयोग के अधिकार फिर भी न हों। इन दोनों जाँचों को अलग रखें।
- दावा, स्रोत का पथ और सही शर्त।
- तकनीकी प्रमुख से वास्तविक उपयोग की जाँच।
- अधिकारों का अनसुलझा सवाल वकील को भेजना।
- अलग सुरक्षा जाँच और उसके ज़िम्मेदार व्यक्ति का नाम।
सौदा आगे बढ़ने से पहले अगली जाँच तय करें
प्री-सीड, यानी शुरुआती सीड निवेश से पहले के चरण में, मुख्य उत्पाद और ज्ञात कॉपियों से शुरू करें। सीड चरण में सूची को दिए जा चुके संस्करण से जोड़ें। सीरीज़ A चरण में पूछें कि उत्पाद बदलने पर बार-बार की जाँच का ज़िम्मा किसका है। जाँच का दायरा चरण और जोखिम के अनुसार होना चाहिए।
पूछें कि विवाद वाले हिस्से को हटाना पड़े तो क्या काम करना बंद होगा। सुधार की लागत, समय और ग्राहकों पर असर लिखें। ये आँकड़े न गढ़ें। हर खुले मुद्दे के लिए ज़िम्मेदार व्यक्ति का नाम और तारीख तय करें।
यह हर संपत्ति के अधिकार का सबूत नहीं है। यह पूरी कानूनी या तकनीकी जाँच भी नहीं है। देशों के अनुसार कानून और शर्तें अलग होती हैं। अधिकार के किसी निष्कर्ष पर भरोसा करने से पहले योग्य स्थानीय वकील से पूछें।
- अनसुलझा सवाल और मुख्य उत्पाद पर उसका असर।
- ज़रूरी सबूत या सुधार और उसका ज़िम्मेदार व्यक्ति।
- अगली जाँच की तारीख और संस्करण का वह बदलाव जिस पर जाँच फिर होनी है।
FAQ
अक्सर पूछे जाने वाले प्रश्न
क्या सार्वजनिक कोड का मतलब बिना रोक के व्यावसायिक उपयोग है?
नहीं। कोड दिखना अपने आप में लाइसेंस नहीं है। GitHub के देखने और fork बनाने के अधिकार, उसे बेचने की खुली अनुमति नहीं हैं। सही लाइसेंस या दूसरी अनुमति की जाँच करें। [1]
क्या ओपन सोर्स स्टार्टअप को ठुकराने की वजह है?
नहीं। ओपन सोर्स अपनी शर्तों के तहत व्यावसायिक उपयोग की अनुमति देता है। [2] वास्तविक हिस्सों, ज़िम्मेदारियों और उत्पाद में उपयोग की जाँच करें। सिर्फ़ लेबल से जोखिम का पता नहीं चलता।
क्या AGPL का मतलब स्टार्टअप का सारा कोड सार्वजनिक करना है?
ऐसा न मानें। धारा 13 बदले हुए, लाइसेंस के दायरे वाले प्रोग्राम और दूर से उसके उपयोग से जुड़ी है। [4] पूरा लाइसेंस और कोड के जुड़ने का तरीका मायने रखते हैं। स्कैन से अंदाज़ा लगाने के बजाय वकील से दायरे की जाँच कराएँ।
क्या एआई पुष्टि कर सकता है कि स्टार्टअप के सॉफ़्टवेयर अधिकार स्पष्ट हैं?
नहीं। वह फ़ाइलें छाँट सकता है और शर्तें दिखा सकता है। वह कॉपियाँ छोड़ सकता है या लाइसेंस पहचानने में गलती कर सकता है। लोगों को तथ्यों और कानूनी असर की जाँच करनी होगी। अस्पष्ट अधिकारों को खुला मुद्दा रखें।
REF
स्रोत
- 1
- 2
Open Source Initiative
The Open Source Definition — modified 16 February 2024 ↗ - 3
Open Source Initiative
The MIT License — permissions and notice conditions ↗ - 4
Free Software Foundation / GNU
GNU Affero General Public License version 3 — section 13 ↗