फ्रीलांस अनुबंध में आईपी असाइनमेंट की जांच

बौद्धिक संपदा असाइनमेंट के लिए फ्रीलांस अनुबंध में क्या जांचें

एक फ्रीलांस अनुबंध देखने में साफ-सुथरा लग सकता है, फिर भी असली बात छूट सकती है। ग्राहक समझता है कि उसने पूरे अधिकार खरीद लिए; फ्रीलांसर सोचता है कि उसने सिर्फ तैयार फ़ाइल बेची है। यही वजह है कि फ्रीलांस अनुबंध में बौद्धिक संपदा असाइनमेंट क्या देखें यह समझना हस्ताक्षर से पहले जरूरी है, ताकि यह अंतर जल्दी विवाद न बने।

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

1. सुनिश्चित करें कि समझौता सिर्फ “कोड ओनरशिप” तक सीमित न हो

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

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

अनुबंध में ही उदाहरण माँगें। “डिलीवेबल्स में वेबसाइट कोड, स्टाइल शीट्स, UI टेक्स्ट और इंस्टॉलेशन नोट्स शामिल हैं” जैसा क्लॉज, “सभी आईपी” जैसे धुंधले वादे से कहीं बेहतर है। अगर प्रोजेक्ट में डिज़ाइन और कोड दोनों हैं, तो उन्हें अलग-अलग संपत्तियों की तरह मानें। दो हिस्से। एक नहीं।

24freelance.pro पर, यहीं ग्राहक को सिर्फ अंतिम फ़ाइल नहीं, बल्कि कार्य-संबंध पर भी सोचना चाहिए। अगर आप काम पर रखने के तरीके तुलना कर रहे हैं, तो फ्रीलांसर कैसे हायर करें वाला लेख अनुबंध तैयार करने से पहले दायरा तय करने में मदद करता है।

2. जाँचें कि डिलीवेबल्स में ड्राफ्ट, इटरेशन और अंतिम फ़ाइलें शामिल हैं या नहीं

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

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

“फाइनल अप्रूव्ड वर्ज़न” जैसी भाषा पर नज़र रखें, लेकिन उस तक पहुँचने के चरणों को भी देखें। अगर प्रोजेक्ट वर्ज़न 2 पर रुक जाए, तो क्या ट्रांसफर होगा? अगर ग्राहक ड्राफ्ट मिलने के बाद कैंसल कर दे, तो ड्राफ्ट जाएगा या नहीं? ये व्यावहारिक सवाल हैं, सैद्धांतिक नहीं।

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

3. जहाँ लागू हो, नैतिक अधिकार और वेवर भाषा की समीक्षा करें

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

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

फ्रीलांसरों को भी यह हिस्सा पढ़ना चाहिए। अनुबंध श्रेय का अधिकार सुरक्षित रख सकता है, या ग्राहक को श्रेय न देने की अनुमति दे सकता है—लेकिन किसी भी स्थिति में शब्द स्पष्ट होने चाहिए। अधूरी कानूनी भाषा, काम सार्वजनिक रूप से प्रकाशित होने पर, असली तनाव पैदा करती है।

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

4. सबकॉन्ट्रैक्टर और सहयोगियों के लिए फ्रीलांस कॉन्ट्रैक्ट में चेन ऑफ टाइटल क्या है सत्यापित करें

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

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

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

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

5. पूर्व-मौजूदा सामग्री और फ्रीलांसर टूल्स के आरक्षित अधिकार देखें

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

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

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

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

6. तीसरे पक्ष की सामग्री, ओपन-सोर्स, और लाइसेंस पास-थ्रू शर्तों की जाँच करें

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

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

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

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

7. समय की पुष्टि करें: असाइनमेंट कब होता है और ट्रांसफर किससे ट्रिगर होता है

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

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

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

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

8. सुनिश्चित करें कि अनुबंध में डिलीवरी के बाद उपयोग, संपादन और प्रवर्तन शामिल हो

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

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

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

भविष्य की वृद्धि की योजना बनाने वाली टीमों के लिए, ये अधिकार सिर्फ कानूनी सिद्धांत नहीं बल्कि वास्तविक व्यावसायिक कदमों को प्रभावित करते हैं। ऐसा अनुबंध जो बाद के संपादन, उप-लाइसेंसिंग और प्रवर्तन की अनुमति देता है, उस अजीब स्थिति से बचाता है जब ग्राहक को पता चलता है कि उसके पास एसेट तो है, लेकिन वह उसका उपयोग नहीं कर सकता। यह बहुत महँगा पड़ता है।

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

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