फ्रीलांस कॉन्ट्रैक्ट में सोर्स कोड स्वामित्व

1. कोड-स्वामित्व का सही परिणाम तय करें

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

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

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

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

2. दायरे में आने वाली विशिष्ट कोड संपत्तियों की पहचान करें

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

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

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

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

3. स्पष्ट बौद्धिक संपदा हस्तांतरण क्लॉज़ जोड़ें

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

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

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

प्लेटफ़ॉर्म की शर्तों और नियमों पर संबंधित दृष्टि के लिए 24freelance.pro साइट के नियम. freelance पेज उपयोगी पृष्ठभूमि देता है। यह आपके लिए क्लॉज़ नहीं लिखेगा, लेकिन यह याद दिलाता है कि औपचारिक नियम और कॉन्ट्रैक्ट भाषा में टकराव नहीं होना चाहिए।

4. पहले से मौजूद टूल, टेम्पलेट और पुन: उपयोग योग्य घटकों को अलग करें

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

सबसे साफ़ तरीका है कि अपवादित सामग्री को किसी अटैचमेंट या शेड्यूल में नाम देकर लिखा जाए। इसे Schedule A, Schedule B, या Exhibit 1 कहें। हर पहले से मौजूद टूल, टेम्पलेट, या पुन: उपयोग योग्य घटक की सूची बनाएं जिसे फ्रीलांसर असाइन नहीं कर रहा। अगर क्लाइंट को इनमें से किसी आइटम का उपयोग डिलीवरबल के भीतर करने की अनुमति है, तो लिखें कि वह उपयोग लाइसेंस के तहत है या नहीं, और लाइसेंस एक्सक्लूसिव है या नॉन-एक्सक्लूसिव। छोटे लेबल बड़े झगड़े रोकते हैं।

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

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

5. डिलीवरी, रिपॉज़िटरी एक्सेस, और हैंडऑफ़ की शर्तें तय करें

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

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

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

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

6. गोपनीयता, ओपन-सोर्स, और थर्ड-पार्टी कोड के नियम शामिल करें

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

ओपन-सोर्स सामग्री के लिए एक नियम तय करें। उदाहरण के लिए, फ्रीलांसर ओपन-सोर्स कोड का उपयोग केवल तभी कर सकता है जब क्लाइंट लिखित में मंज़ूरी दे, और केवल तब जब लाइसेंस शर्तें क्लाइंट की स्वामित्व अपेक्षाओं से टकराती न हों। इसका मतलब है कि फ्रीलांसर को प्रोजेक्ट में उपयोग किए गए GPL, LGPL, MIT, Apache, या इसी तरह के किसी भी कंपोनेंट की पहचान करनी होगी और उसके व्यावहारिक प्रभाव की व्याख्या करनी होगी। नाम मायने रखते हैं।

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

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

7. स्वीकृति, भुगतान, और स्वामित्व-हस्तांतरण का समय तय करें

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

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

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

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

8. कॉन्ट्रैक्ट भेजने से पहले साइन-रेडी चेकलिस्ट जोड़ें

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

यहाँ एक व्यावहारिक भेजने-से-पहले की सूची है:

• प्रोजेक्ट का नाम statement of work से मेल खाता है।
• रिपॉज़िटरी लोकेशन URL या सटीक पथ से पहचानी गई है।
• स्वामित्व क्लॉज़ बताता है कि हस्तांतरण कब होगा।
• अपवादित सामग्री शेड्यूल में सूचीबद्ध है।
• डिलीवरी दायित्वों में सोर्स फ़ाइलें, दस्तावेज़, और एक्सेस शामिल हैं।
• ओपन-सोर्स और थर्ड-पार्टी कोड के नियम लिखे गए हैं।
• स्वीकृति और भुगतान का समय आपस में जोड़ा गया है।
• क्षेत्राधिकार-विशिष्ट भाषा की कानूनी समीक्षा हो चुकी है।

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

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