स्रोत कोड स्वामित्व के लिए फ्रीलांस अनुबंध कैसे लिखें

1. सटीक कोड-स्वामित्व परिणाम को परिभाषित करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. पूर्व-निर्मित उपकरण, टेम्पलेट और पुन: प्रयोज्य घटक अलग करें

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

सबसे साफ़ तरीका यह है कि एक अटैचमेंट या शेड्यूल में बाहर किए गए सामग्रियों के नाम दिए जाएं। इसे शेड्यूल ए, शेड्यूल बी, या प्रदर्शनी 1 कहें। हर पूर्व-निर्मित उपकरण, टेम्पलेट, या पुन: उपयोग करने योग्य घटक की सूची बनाएं जिसे फ्रीलांसर असाइन नहीं करता। यदि ग्राहक को डिलीवर करने योग्य के अंदर उन वस्तुओं में से एक का उपयोग करने की अनुमति है, तो कहें कि क्या वह उपयोग एक लाइसेंस के तहत है, और क्या लाइसेंस विशेष या गैर-विशेष है। छोटे लेबल बड़े झगड़ों को रोकते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. अनुबंध भेजने से पहले एक हस्ताक्षर-तैयार चेकलिस्ट जोड़ें

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

यहाँ एक व्यावहारिक प्री-सेंड सूची है:

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

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

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