Chaindocसॉफ्टवेयर डेवलपमेंट एग्रीमेंट: संपूर्ण गाइड + मुफ्त टेम्पलेट
मुफ्त सॉफ्टवेयर डेवलपमेंट एग्रीमेंट टेम्पलेट डाउनलोड करें। IP अधिकार, भुगतान शर्तें, स्वीकार्यता परीक्षण और बहुत कुछ। मिनटों में ऑनलाइन कस्टमाइज़ करें और हस्ताक्षर करें।
Introduction
अधिकांश सॉफ्टवेयर प्रोजेक्ट इसलिए फेल नहीं होते क्योंकि डेवलपर्स कोडिंग में खराब थे। वे इसलिए फेल होते हैं क्योंकि किसी ने यह नहीं लिखा कि "काम पूरा" होने का क्या मतलब है। Standish Group की CHAOS रिपोर्ट के अनुसार सॉफ्टवेयर प्रोजेक्ट्स की सफलता दर मात्र 31% है — और स्कोप में असहमति, अस्पष्ट IP स्वामित्व और विवादित भुगतान शर्तें सबसे सामान्य दोषी हैं।
एक सॉफ्टवेयर डेवलपमेंट एग्रीमेंट काम शुरू होने से पहले ये सब ठीक कर देता है। यह क्लाइंट और डेवलपर (या एजेंसी) के बीच एक अनुबंध है जो यह परिभाषित करता है कि क्या बनाया जाएगा, किसका होगा, इसकी लागत क्या होगी, और कुछ गलत होने पर क्या होगा। इसके बिना, आप अच्छी नीयत और याददाश्त पर निर्भर हैं — और अदालतें इनमें से किसी को भी स्वीकार नहीं करतीं।
यह गाइड सब कुछ कवर करता है: जब आपको एक सॉफ्टवेयर डेवलपमेंट एग्रीमेंट की आवश्यकता होती है, चार अनुबंध प्रकार और कब किसका उपयोग करें, हर वह खंड जो वास्तव में मायने रखता है, और एक मुफ्त डाउनलोड योग्य टेम्पलेट जिसे आप अपने प्रोजेक्ट के लिए कस्टमाइज़ कर सकते हैं। यदि आप पहले से ही बेसिक्स जानते हैं और सीधे टेम्पलेट पर जाना चाहते हैं, तो टेम्पलेट सेक्शन पर आगे बढ़ें। अन्यथा, संदर्भ मायने रखता है — विशेष रूप से IP सेक्शन, जहां अधिकांश एग्रीमेंट चुपचाप फेल हो जाते हैं। समझौतों और अनुबंधों के बीच अंतर को लेकर एक व्यापक नज़रिए के लिए, हमारा contracts vs. agreements गाइड जानने योग्य कानूनी भेद को कवर करता है।
सॉफ्टवेयर डेवलपमेंट एग्रीमेंट क्या है?
एक सॉफ्टवेयर डेवलपमेंट एग्रीमेंट (SDA) एक क्लाइंट और एक सॉफ्टवेयर डेवलपर या डेवलपमेंट कंपनी के बीच एक कानूनी रूप से बाध्यकारी अनुबंध है। यह कार्य के दायरे, भुगतान संरचना, डिलीवरी समयरेखा, बौद्धिक संपदा स्वामित्व, गोपनीयता शर्तों और यदि किसी भी पार्टी को व्यवस्था से बाहर निकलने की आवश्यकता हो तो क्या होगा, यह परिभाषित करता है।
SDA एक प्रस्ताव, प्रोजेक्ट ब्रीफ, या Slack थ्रेड नहीं है जो काम की पुष्टि करता हो। यह औपचारिक कानूनी रिकॉर्ड है जो विकास शुरू होने से पहले दोनों पक्षों द्वारा सहमत किए गए थे। हस्ताक्षरित होने के बाद, यह वह दस्तावेज़ है जिसे आप किसी विवाद की स्थिति में संदर्भित करेंगे — और यदि ऐसा होता है तो अदालत पढ़ेगी।
SDA क्या कवर करता है
एक सही ढंग से तैयार किया गया सॉफ्टवेयर डेवलपमेंट एग्रीमेंट निम्नलिखित को संबोधित करेगा:
- कार्य का दायरा — डेवलपर क्या बनाएगा, इतनी विशिष्टता के साथ कि कोई तीसरा पक्ष पूर्णता का आकलन कर सके
- डिलीवरेबल और माइलस्टोन — क्या डिलीवर किया जाएगा, किस रूप में, और कब तक
- भुगतान शर्तें — कुल शुल्क, भुगतान अनुसूची, और प्रत्येक भुगतान को क्या ट्रिगर करता है
- IP स्वामित्व — कोड लिखे जाने के बाद किसका होगा
- गोपनीयता — प्रत्येक पक्ष को कौन सी प्रॉप्राइटरी जानकारी निजी रखनी चाहिए
- स्वीकार्यता परीक्षण — क्लाइंट कैसे मूल्यांकन करता है कि डिलीवर किया गया सॉफ्टवेयर आवश्यकताओं को पूरा करता है
- वारंटी — डेवलपर सॉफ्टवेयर की कार्यक्षमता के बारे में क्या गारंटी देता है
- समाप्ति की शर्तें — कोई भी पक्ष कैसे एग्रीमेंट समाप्त कर सकता है और पहले से पूरे किए गए काम का क्या होगा
कुछ क्लाइंट SDA को Statement of Work के साथ भ्रमित करते हैं। इनमें कुछ समानता है, लेकिन वे एक ही चीज़ नहीं हैं — और यह अंतर मायने रखता है। MSA और SOW के बीच संबंध बताता है कि ये दस्तावेज़ दीर्घकालिक एंगेजमेंट में कैसे एक साथ काम करते हैं।
आपको सॉफ्टवेयर डेवलपमेंट एग्रीमेंट कब चाहिए?
संक्षिप्त उत्तर: जब भी आप किसी को सॉफ्टवेयर बनाने के लिए भुगतान कर रहे हैं, या इसे बनाने के लिए भुगतान प्राप्त कर रहे हैं।
अनुबंध तब भी मायने रखता है जब आप एक सोलो फ्रीलांसर को दो सप्ताह के प्रोजेक्ट के लिए काम पर रख रहे हों या एक 20-व्यक्ति की एजेंसी को 12-महीने के प्रोडक्ट बिल्ड के लिए लगा रहे हों। पैमाना बदलता है; लिखित शर्तों की आवश्यकता नहीं।
आपके पास एक सॉफ्टवेयर डेवलपमेंट एग्रीमेंट होना चाहिए जब:
- आप सॉफ्टवेयर डेवलपमेंट आउटसोर्स कर रहे हैं — विशेष रूप से ऑफशोर या रिमोट टीमों के लिए जहां क्षेत्राधिकार में अंतर अनौपचारिक समझौतों को जटिल बनाता है
- कस्टम सॉफ्टवेयर बनाया जा रहा है — जितना अधिक अनूठा काम होगा, उतना अधिक IP स्वामित्व को स्पष्ट दस्तावेजीकरण की आवश्यकता होगी
- कई विकास चरण मौजूद हैं — माइलस्टोन-आधारित भुगतान के लिए प्रत्येक चरण को ट्रिगर करने के लिए लिखित स्वीकृति मानदंड की आवश्यकता होती है
- संवेदनशील डेटा या सिस्टम शामिल हैं — किसी भी प्रोजेक्ट में जो ग्राहक डेटा को छूता है, उसे गोपनीयता और सुरक्षा खंडों की आवश्यकता होती है
- आप प्रॉप्राइटरी फ्रेमवर्क पर बना रहे हैं — पहले से मौजूद कोड जो कस्टम डिलीवरेबल में शामिल होता है, एक स्पष्ट एग्रीमेंट के बिना गंदा स्वामित्व प्रश्न पैदा करता है
- आप सीमाओं के पार काम कर रहे हैं — जब डेवलपर और क्लाइंट अलग-अलग देशों में हों तो शासी कानून और क्षेत्राधिकार का नाम लेना ज़रूरी है
वह एक स्थिति जहां आप पूर्ण SDA के बिना प्रबंधन कर सकते हैं: बहुत छोटा, कम-मूल्य का काम जो एक व्यापक मास्टर सर्विस एग्रीमेंट द्वारा शासित हो जो पहले से ही सभी प्रासंगिक शर्तों को कवर करता है। लेकिन तब भी, अधिकांश वकील आपको कागजी कार्रवाई करने की सलाह देंगे।
अधिकांश क्षेत्राधिकारों में, सॉफ्टवेयर डेवलपमेंट के लिए एक मौखिक समझौता तकनीकी रूप से लागू करने योग्य है — लेकिन इसे साबित करना लगभग असंभव है। यदि कोई क्लाइंट सहमत किए गए की बहस करता है, तो सबूत का बोझ उस पर पड़ता है जो दावा करता है कि एग्रीमेंट मौजूद था। दोनों पक्षों द्वारा हस्ताक्षरित एक लिखित SDA पूरी तरह से उस अस्पष्टता को हटा देता है।
सॉफ्टवेयर डेवलपमेंट एग्रीमेंट के प्रकार
कोई एक SDA टेम्पलेट नहीं है जो हर एंगेजमेंट के लिए फिट हो। अनुबंध संरचना को प्रोजेक्ट की कीमत और दायरे से मेल खाना चाहिए — और गलत संरचना का चयन करने से अच्छे परिणामों के खिलाफ काम करने वाले प्रोत्साहन पैदा होते हैं।
| अनुबंध प्रकार | सबसे अच्छा किसके लिए | भुगतान मॉडल | जोखिम कौन उठाता है |
|---|---|---|---|
| Fixed-Price | स्थिर आवश्यकताओं वाले अच्छी तरह परिभाषित प्रोजेक्ट्स | Lump sum या निर्धारित माइलस्टोन पर % | डेवलपर ओवररन जोखिम उठाता है; क्लाइंट को लागत की निश्चितता मिलती है |
| Time & Materials (T&M) | अन्वेषणात्मक काम या जहां आवश्यकताएं विकसित होंगी | Hourly/daily rate x लॉग किए गए वास्तविक घंटे | क्लाइंट ओवररन जोखिम उठाता है; डेवलपर को लचीलापन मिलता है |
| Dedicated Team | लगातार टीम की आवश्यकता वाला निरंतर प्रोडक्ट डेवलपमेंट | प्रति डेवलपर FTE मासिक रिटेनर | साझा — क्लाइंट काम का निर्देशन देता है, डेवलपर घंटे डिलीवर करता है |
| MSA + SOW | एक से अधिक प्रोजेक्ट्स को दीर्घकालिक क्लाइंट संबंध | प्रति-प्रोजेक्ट, प्रत्येक SOW में परिभाषित | प्रति एंगेजमेंट बातचीत |
Fixed-price contracts
एक fixed-price SDA तब काम करता है जब प्रोजेक्ट की आवश्यकताएं स्थिर हैं और विकास शुरू होने से पहले अच्छी तरह समझ में आती हैं। डेवलपर एक सहमत कुल शुल्क के लिए एक परिभाषित दायरा डिलीवर करने का प्रतिबद्धता करता है। बजट निश्चितता क्लाइंट के लिए मुख्य आकर्षण है। जोखिम: यदि आवश्यकताएं अंडरस्पेसिफाइड निकलती हैं, तो डेवलपर या तो ओवररन को अवशोषित करता है या विवाद शुरू हो जाते हैं।
Time and materials contracts
T&M contracts अन्वेषणात्मक प्रोजेक्ट्स, प्रारंभिक-चरण के उत्पादों, या किसी भी स्थिति के लिए समझ में आते हैं जहां पूरा दायरा अपफ्रंट परिभाषित नहीं किया जा सकता। क्लाइंट सहमत दरों पर वास्तविक घंटों के लिए भुगतान करता है। आपको लचीलापन मिलता है; ट्रेडऑफ लागत अनिश्चितता है। बजट कैप और मासिक सीलिंग इस जोखिम को प्रबंधित करने में मदद करते हैं।
Dedicated team agreements
उन कंपनियों के लिए जिन्हें एक सुसंगत रिमोट इंजीनियरिंग टीम की आवश्यकता होती है — बजाय एक बार के प्रोजेक्ट डिलीवरी के — एक dedicated team agreement एक निरंतर संबंध की शर्तें निर्धारित करता है। IT कंपनियों के लिए कॉन्ट्रैक्ट मैनेजमेंट में आमतौर पर आउटसोर्सिंग पार्टनरों के साथ काम करते समय यह मॉडल शामिल होता है।
MSA + SOW structure
बड़े एंगेजमेंट अक्सर मास्टर कानूनी फ्रेमवर्क (MSA) को प्रोजेक्ट-विशिष्ट शर्तों (SOW) से अलग करते हैं। MSA एक बार IP, गोपनीयता, देनदारी और विवाद समाधान को कवर करता है; प्रत्येक SOW एक विशेष प्रोजेक्ट के लिए विशिष्ट डिलीवरेबल, समयरेखा और भुगतान को कवर करता है।
महत्वपूर्ण खंड जो हर सॉफ्टवेयर डेवलपमेंट एग्रीमेंट में शामिल होने चाहिए
सभी खंड समान वजन नहीं रखते। ये वे हैं जहां गायब या अस्पष्ट भाषा वास्तविक दुनिया के विवादों का कारण बनती है।
1. कार्य का दायरा और डिलीवरेबल
इतनी विस्तार से वर्णन करें कि प्रोजेक्ट में अनधिकृत व्यक्ति यह आकलन कर सके कि क्या डिलीवर किया गया था। कार्यात्मक आवश्यकताएं, तकनीकी विशिष्टताएं, समर्थित प्लेटफॉर्म और प्रदर्शन बेंचमार्क सब यहां संबंधित हैं। स्पष्ट रूप से नाम दें कि दायरे से बाहर क्या है।
अस्पष्ट दायरा सॉफ्टवेयर विवादों का एकमात्र सबसे सामान्य स्रोत है। "एक वेबसाइट बनाएं" दायरा नहीं है। "Exhibit A में सूचीबद्ध सुविधाओं वाला एक रेस्पॉन्सिव React/Next.js एप्लिकेशन बनाएं, मोबाइल पर Lighthouse प्रदर्शन स्कोर 90+ पास करते हुए" एक दायरा है।
2. भुगतान शर्तें और माइलस्टोन अनुसूची
प्रत्येक भुगतान सूचीबद्ध करें: राशि, ट्रिगर घटना और भुगतान विधि। माइलस्टोन-आधारित भुगतान स्वीकृत डिलीवरेबल से बंधे होने चाहिए, न कि केवल कैलेंडर तिथियों से। मुद्रा, भुगतान समयरेखा (Net-15 या Net-30 मानक है) और देर भुगतान जुर्माना परिभाषित करें।
3. बौद्धिक संपदा स्वामित्व
यह वह खंड है जिसे अधिकांश क्लाइंट बहुत जल्दी पढ़ते हैं। कस्टम कोड किसका है? डेवलपर जोड़ने वाला कोई पहले से मौजूद कोड किसका है? क्या ओपन-सोर्स सॉफ्टवेयर कवर है? SDA का IP सेक्शन निर्धारित करता है कि डिलीवरी के बाद सॉफ्टवेयर का उपयोग, संशोधन, बिक्री या लाइसेंस कौन कर सकता है। इसे गलत करें और परिणाम महंगे हैं — नीचे IP सेक्शन में Cadence v. Avanti केस देखें।
4. गोपनीयता
SDA में पारस्परिक गोपनीयता दायित्व शामिल होने चाहिए। डेवलपर क्लाइंट डेटा या प्रॉप्राइटरी बिजनेस लॉजिक का खुलासा नहीं कर सकता; क्लाइंट डेवलपर की प्रॉप्राइटरी प्रक्रियाओं या टूलिंग का खुलासा नहीं कर सकता। स्टैंडअलोन एग्रीमेंट में अधिक मजबूत NDA शर्तों के लिए, सॉफ्टवेयर कंपनियों के लिए contractor NDA गाइड इसके साथ पढ़ने योग्य है।
5. स्वीकार्यता परीक्षण
परिभाषित करें कि क्लाइंट प्रत्येक डिलीवरेबल की समीक्षा और स्वीकृति कैसे करता है। समीक्षा विंडो (5-10 व्यावसायिक दिन सामान्य है), फीडबैक प्रारूप, पासिंग के लिए मानदंड, और यदि क्लाइंट समीक्षा विंडो के भीतर प्रतिक्रिया नहीं देता है तो क्या होगा (deemed acceptance)।
6. वारंटी
डेवलपर यह गारंटी देना चाहिए कि सॉफ्टवेयर निर्दिष्ट के अनुसार कार्य करेगा, कि कोड मूल है (या उचित रूप से लाइसेंस प्राप्त है), और डिलीवरी तीसरे पक्ष के IP अधिकारों का उल्लंघन नहीं करेगी। लॉन्च के बाद खोजे गए दोषों के लिए एक वारंटी अवधि — आम तौर पर 30-90 दिन — क्लाइंट की रक्षा करती है।
7. समाप्ति की शर्तें
प्रत्येक पक्ष को उचित नोटिस के साथ बाहर निकलने में सक्षम होना चाहिए। नोटिस अवधि (30 दिन मानक है), प्रगति में काम का क्या होगा, और जल्दी समाप्ति पर अंतिम भुगतान कैसे गणना की जाएगी, इसे परिभाषित करें। एक cause clause के लिए समाप्ति (भौतिक उल्लंघन, दिवालियापन या गैर-भुगतान को कवर करते हुए) को सुविधा के लिए समाप्ति से अलग होना चाहिए।
8. शासी कानून और क्षेत्राधिकार
उस देश और राज्य/क्षेत्र का नाम लें जिसका कानून अनुबंध को शासित करता है। जब डेवलपर और क्लाइंट अलग-अलग देशों में हों, तो यह खंड तय करता है कि कौन सी अदालतें विवाद को संभालेंगी। इसे औपचारिक लगने के कारण छोड़ना नहीं है — यह सीमा-पार एंगेजमेंट में सबसे व्यावहारिक रूप से महत्वपूर्ण खंडों में से एक है।
सॉफ्टवेयर डेवलपमेंट एग्रीमेंट में IP स्वामित्व, दायरा और माइलस्टोन भुगतान शर्तें विकास शुरू होने से पहले स्पष्ट रूप से सहमत होनी चाहिए।
स्पष्ट स्वीकृति मानदंड और deemed-acceptance भाषा के साथ एक समीक्षा विंडो के बिना, भुगतान विवाद लगभग अनिवार्य हो जाते हैं। क्लाइंट हमेशा दावा कर सकता है कि सॉफ्टवेयर "तैयार" नहीं था और अनिश्चित काल तक भुगतान रोक सकता है। विकास शुरू होने से पहले पास/फेल मानदंड लिखें, इसके बाद नहीं कि क्या यह पास हुआ इस पर बहस कर रहे हों।
सॉफ्टवेयर डेवलपमेंट एग्रीमेंट टेम्पलेट
अपने एग्रीमेंट की नींव के रूप में इस टेम्पलेट का उपयोग करें। सभी कोष्ठक वाले फ़ील्ड को अपनी विशिष्ट शर्तों से बदलें। जटिल प्रोजेक्ट्स के लिए, अंतिम संस्करण की समीक्षा के लिए एक सॉफ्टवेयर अटॉर्नी को लगाएं — विशेष रूप से IP और वारंटी सेक्शन।
| Milestone | Deliverable | Due Date | Payment |
|---|---|---|---|
| M1: Kickoff | [Deliverable description] | [Date] | [Amount] |
| M2: [Phase name] | [Deliverable description] | [Date] | [Amount] |
| M3: Final Delivery | [Deliverable description] | [Date] | [Amount] |
IT कंपनियों के लिए कॉन्ट्रैक्ट मैनेजमेंट में आमतौर पर एकाधिक डेवलपमेंट पार्टनरों के साथ अनुबंध प्रबंधित करना शामिल होता है — सभी SDA को एक एकल दस्तावेज़ प्रबंधन प्रणाली में केंद्रीकृत करना, संस्करण इतिहास और छेड़छाड़-रोधी हस्ताक्षरों के साथ, Word दस्तावेज़ों को वापस और आगे ईमेल करने की अराजकता को दूर करता है।
ऊपर दिया गया टेम्पलेट अधिकांश सॉफ्टवेयर डेवलपमेंट एंगेजमेंट के लिए कोर खंडों को कवर करता है। जटिल बहु-चरण वाले प्रोजेक्ट्स, एंटरप्राइज लाइसेंसिंग, या अंतर्राष्ट्रीय आउटसोर्सिंग सौदों के लिए, हस्ताक्षर करने से पहले एक सॉफ्टवेयर अटॉर्नी से IP, वारंटी और liability सीमा सेक्शन की समीक्षा करवाएं। टेम्पलेट एक शुरुआती बिंदु है, कानूनी सलाह का विकल्प नहीं।
मिनटों में अपना सॉफ्टवेयर डेवलपमेंट एग्रीमेंट साइन करें
Chaindoc का उपयोग करें अपने SDA को हस्ताक्षर के लिए भेजने, ब्लॉकचेन-सत्यापित स्वीकृतियों को एकत्र करने और माइलस्टोन भुगतानों को ट्रिगर करने के लिए — सब कुछ एक डैशबोर्ड से। कोई और ईमेल थ्रेड और "final_v3_FINAL.docx" नहीं।
टेम्पलेट कैसे भरें: चरण-दर-चरण गाइड
ऊपर दिए गए टेम्पलेट में भरने के लिए एक दर्जन से अधिक फ़ील्ड हैं। यहां बताया गया है कि प्रत्येक को कैसे संभालें ताकि बाद में विवाद पैदा करने वाले अंतराल न छूटें।
चरण 1: अनुबंध छूने से पहले दायरा परिभाषित करें
तब तक टेम्पलेट न खोलें जब तक आपने यह दस्तावेज़ीकृत नहीं कर लिया कि सॉफ्टवेयर को वास्तव में क्या करने की आवश्यकता है। कार्यात्मक आवश्यकताएं, तकनीकी बाधाएं, समर्थित प्लेटफॉर्म, इंटीग्रेशन निर्भरताएं — सब कुछ। SDA का दायरा सेक्शन उतना ही अच्छा है जितनी उसके पीछे की स्पेसिफिकेशन दस्तावेज़।
जटिल प्रोजेक्ट्स के लिए, पूरी स्पेसिफिकेशन को Exhibit A के रूप में संलग्न करें और दायरा खंड से इसका संदर्भ दें। यह मुख्य अनुबंध को पठनीय रखते हुए यह सुनिश्चित करता है कि पूरी तकनीकी विस्तार कानूनी रूप से संलग्न है।
चरण 2: माइलस्टोन अनुसूची बनाएं
डिलीवरी तिथि से पीछे की ओर काम करें। प्रोजेक्ट को चरणों में तोड़ें — डिस्कवरी, डिज़ाइन, डेवलपमेंट, टेस्टिंग, डिप्लॉयमेंट — और प्रत्येक को एक डॉलर राशि और नियत तिथि सौंपें। चरण भुगतान प्रत्येक चरण में डिलीवर किए गए मूल्य के अनुरूप होने चाहिए।
चेतावनी: यह अधिकांश पक्षों की अपेक्षा लंबा समय लेता है, विशेष रूप से पहली बार के एंगेजमेंट पर। माइलस्टोन और भुगतान को सही करने के लिए दोनों पक्षों की उपस्थिति में 1-2 घंटे का बजट बनाएं।
चरण 3: स्पष्ट रूप से IP स्वामित्व का संबोधन करें
ध्यान से सेक्शन 3 पढ़ें और सभी रिक्त स्थान भरें। यदि डेवलपर इस प्रोजेक्ट से पहले बनाए गए प्रॉप्राइटरी फ्रेमवर्क या टूल का उपयोग कर रहा है, तो उन्हें pre-existing work carveout में सूचीबद्ध करें। यदि आप ओपन-सोर्स लाइब्रेरी का उपयोग कर रहे हैं, तो लाइसेंस का नाम लें।
कस्टम work assignment (सेक्शन 3.1) आम तौर पर क्लाइंट के लिए सबसे महत्वपूर्ण खंड है: यह वह है जो डिलीवर किए गए कोड का स्वामित्व डेवलपर से आप में स्थानांतरित करता है। इसे अस्पष्ट मत छोड़ें।
चरण 4: स्वीकृति विंडो और मानदंड निर्धारित करें
इसे भरने से पहले समीक्षा विंडो तय करें। दस व्यावसायिक दिन सामान्य हैं। दो सप्ताह व्यस्त क्लाइंटों को वास्तव में डिलीवरेबल का परीक्षण करने के लिए पर्याप्त समय देते हैं; कुछ भी छोटा समीक्षक यात्रा कर रहे हों या अन्यथा व्यस्त हों तो विवाद पैदा करने की प्रवृत्ति रखता है।
सेक्शन 5 के लिए, स्वीकृति मानदंड Exhibit A में संबंधित हैं। विशिष्ट, परीक्षण योग्य मानदंड लिखें: "4G कनेक्शन पर मोबाइल ऐप 3 सेकंड के भीतर डैशबोर्ड लोड करता है" "ऐप तेज़ होना चाहिए" से बेहतर है।
चरण 5: जानबूझकर शासी कानून चुनें
घरेलू प्रोजेक्ट्स के लिए, डेवलपर के होम स्टेट/देश का उपयोग करें (वे स्थानीय अदालतों से अधिक परिचित हैं)। सीमा-पार प्रोजेक्ट्स के लिए, कोई भी पक्ष तटस्थ क्षेत्राधिकार को पसंद कर सकता है। Delaware कानून US-आधारित टेक अनुबंधों के लिए सामान्य है; English कानून अक्सर अंतर्राष्ट्रीय टेक एग्रीमेंट के लिए उपयोग किया जाता है। जो भी आप चुनें, दोनों पक्षों को स्पष्ट रूप से सहमत होने की आवश्यकता है — इसे खाली मत छोड़ें।
चरण 6: अनुपालक eSignature के साथ साइन करें
PDF पर हस्तलिखित हस्ताक्षर का स्कैन किया गया चित्र अधिकांश क्षेत्राधिकारों में कानूनी रूप से कमज़ोर है। इलेक्ट्रॉनिक हस्ताक्षर जो दस्तावेज़ हैश और समय-मुद्रांकित completion certificate जनरेट करते हैं, उन्हें अस्वीकार करना बहुत कठिन है। संयुक्त राज्य अमेरिका में ESIGN Act और UETA, और यूरोपीय संघ में eIDAS के तहत, इलेक्ट्रॉनिक हस्ताक्षर व्यावसायिक एग्रीमेंट के लिए पूर्ण कानूनी बल लेते हैं। साइनिंग प्लेटफॉर्म को प्रत्येक हस्ताक्षर को दस्तावेज़ के क्रिप्टोग्राफिक हैश से बांधना चाहिए — ताकि हस्ताक्षर के बाद की कोई भी छेड़छाड़ तुरंत पता चल सके।
महत्वपूर्ण खंड जो अधिकांश एग्रीमेंट में छूट जाते हैं
अधिकांश टेम्पलेट बेसिक्स को कवर करते हैं। ये वे खंड हैं जो सस्ते या जल्दी तैयार किए गए एग्रीमेंट से बाहर हो जाते हैं — और जब कुछ गलत होता है तब सबसे अधिक मायने रखते हैं।
पास/फेल मानदंड के साथ स्वीकार्यता परीक्षण
ऊपर के टेम्पलेट में सेक्शन 5 परिभाषित करता है कि क्लाइंट *कब* और *कैसे* डिलीवरेबल की समीक्षा करता है। जो अधिकांश एग्रीमेंट छोड़ देते हैं: पासिंग के लिए वास्तविक मानदंड। मापने योग्य पास/फेल बेंचमार्क के बिना, स्वीकृति एक बातचीत बन जाती है। क्लाइंट हमेशा यह तर्क दे सकता है कि सॉफ्टवेयर "काफी अच्छा" नहीं है। विकास शुरू होने से पहले Exhibit A में वस्तुनिष्ठ मानदंड लिखें।
सोर्स कोड एस्क्रो
यदि आपका व्यवसाय कस्टम सॉफ्टवेयर पर निर्भर करता है और डेवलपर व्यवसाय बंद कर देता है, तो आपको सोर्स कोड तक पहुंच की आवश्यकता होती है। एक सोर्स कोड एस्क्रो खंड डेवलपर को एक तटस्थ एस्क्रो एजेंट के साथ सोर्स कोड जमा करने की आवश्यकता है। यदि डेवलपर संचालन बंद कर देता है या भौतिक रूप से एग्रीमेंट का उल्लंघन करता है, तो एस्क्रो कोड को क्लाइंट को जारी करता है। अधिकांश क्लाइंट इसके लिए कभी नहीं सोचते — जब तक उन्हें इसकी आवश्यकता नहीं होती।
डिलीवरी के बाद देनदारी अवधि
सेक्शन 7 कुल देनदारी को सीमित करता है, लेकिन कई टेम्पलेट्स समय विंडो को संबोधित नहीं करते हैं। देनदारी कब समाप्त होती है? यदि डिलीवरी के 18 महीने बाद एक दोष डेटा लॉस का कारण बनता है, तो क्या डेवलपर अभी भी देनदार है? वारंटी अवधि और वारंटी-पश्चात देनदारी विंडो को स्पष्ट रूप से परिभाषित करें। वारंटी अवधि के बाद, डेवलपर का एकमात्र दायित्व आम तौर पर उन दोषों को संबोधित करना होता है जो उन्होंने उत्पन्न किए हैं — क्लाइंट संशोधनों द्वारा पेश किए गए बग नहीं।
चेंज कंट्रोल प्रक्रिया
सेक्शन 9 स्कोप परिवर्तनों के लिए एक हस्ताक्षरित Change Order की आवश्यकता है। जो अधिकांश एग्रीमेंट छोड़ देते हैं: Change Orders पर हस्ताक्षर करने का अधिकार किसके पास है, इसे परिभाषित करना। यदि क्लाइंट साइड पर एक प्रोजेक्ट मैनेजर मौखिक रूप से एक नई सुविधा का अनुरोध करता है और डेवलपर इसे बनाता है, तो क्या डेवलपर को भुगतान दिया जाना चाहिए? केवल तभी जब Change Order प्रक्रिया का पालन किया गया हो। विशिष्ट भूमिकाओं (व्यक्तियों को नहीं, जिनके पद बदलते हैं) का नाम लें जिनके पास परिवर्तनों को अधिकृत करने का अधिकार है।
ओपन सोर्स लाइसेंस अनुपालन
Linux Foundation रिपोर्ट करता है कि 92% व्यावसायिक सॉफ्टवेयर में ओपन-सोर्स घटक होते हैं। प्रत्येक घटक का लाइसेंस सॉफ्टवेयर के उपयोग, संशोधन और वितरण पर शर्तें लगाता है। उदाहरण के लिए, एक GPL-लाइसेंस प्राप्त लाइब्रेरी copyleft दायित्वों को ट्रिगर कर सकती है जो आपको अपने प्रॉप्राइटरी कोड को ओपन-सोर्स करने के लिए मजबूर करती है। SDA को डेवलपर से सभी ओपन-सोर्स घटकों का खुलासा करने और क्लाइंट के अभिप्रेत उपयोग के साथ उनकी अनुकूलता की पुष्टि करने की आवश्यकता होनी चाहिए।
सॉफ्टवेयर डेवलपमेंट एग्रीमेंट में IP अधिकार
IP स्वामित्व वह खंड है जिसे अधिकांश क्लाइंट स्किम करते हैं — और जिसे गलत होने के परिणाम सबसे बड़े होते हैं।
Cadence v. Avanti केस: एक $265M सबक
2002 में, एक California अदालत ने पाया कि Avanti Corporation ने एक प्रतिस्पर्धी उत्पाद में चोरी किया गया Cadence सोर्स कोड का उपयोग किया था। हर्जाना पुरस्कार $265M तक पहुंच गया। यह केस सॉफ्टवेयर IP मुकदमेबाजी में अक्सर उद्धृत किया जाता है क्योंकि यह दर्शाता है कि जब सोर्स कोड स्वामित्व पर विवाद होता है या, इससे भी बदतर, जब कोड जो कभी भी उत्पाद में शामिल नहीं होना चाहिए था, वहां समाप्त हो जाता है, तो क्या होता है। एक अच्छी तरह से तैयार किया गया IP खंड न केवल अंतिम डिलीवरेबल का स्वामी कौन है यह परिभाषित करता है — यह डेवलपर से यह वारंटी करने की आवश्यकता करता है कि कोई तीसरे पक्ष का IP अनुचित रूप से शामिल नहीं किया गया था।
चार IP मॉडल
| मॉडल | क्लाइंट को क्या मिलता है | डेवलपर क्या रखता है | सबसे अच्छा किसके लिए |
|---|---|---|---|
| Full Client Ownership | कस्टम कोड के सभी अधिकार, जिसमें संशोधित, पुनर्विक्रय, उपलाइसेंस करने का अधिकार शामिल है | इस प्रोजेक्ट से कुछ नहीं | जहां क्लाइंट को पूर्ण वाणिज्यिक नियंत्रण की आवश्यकता हो |
| Licensed Use | डिलीवर किए गए सॉफ्टवेयर का उपयोग करने का लाइसेंस; कोर IP को संशोधित नहीं कर सकता | कोड का स्वामित्व, अन्य क्लाइंट्स के लिए पुन: उपयोग करने की क्षमता | SaaS टूल या डेवलपर की प्रॉप्राइटरी स्टैक पर बने प्लेटफॉर्म |
| Open Source Hybrid | उनके संबंधित लाइसेंसों के तहत ओपन-सोर्स घटक + क्लाइंट को सौंपा गया कस्टम काम | डेवलपर IP carveouts | आधुनिक सॉफ्टवेयर के लिए सबसे व्यावहारिक मॉडल |
| Joint Ownership | IP पर साझा अधिकार | IP पर साझा अधिकार | शायद ही सलाह दी जाए; जटिल लाइसेंसिंग और रखरखाव समस्याएं पैदा करता है |
पहले से मौजूद बनाम कस्टम काम
अधिकांश डेवलपर टूल, फ्रेमवर्क और लाइब्रेरी लाते हैं जो उन्होंने आपके प्रोजेक्ट शुरू होने से पहले बनाए थे। ये "पहले से मौजूद कार्य" या "बैकग्राउंड IP" हैं। SDA को स्पष्ट रूप से पहचानना चाहिए कि कौन सा पहले से मौजूद कार्य शामिल किया जाएगा और क्लाइंट को इसे डिलीवर किए गए सॉफ्टवेयर के हिस्से के रूप में उपयोग करने का लाइसेंस प्रदान करना चाहिए — उन अंतर्निहित टूल का स्वामित्व स्थानांतरित किए बिना।
व्यक्तिगत डेवलपर अनुबंधों में IP assignment कैसे काम करता है, इस पर गहन नज़र के लिए, डेवलपर्स के लिए IP assignment agreement गाइड कोड स्वामित्व को स्थानांतरित और लाइसेंस करने की यांत्रिकी को कवर करता है।
Work-for-hire doctrine
संयुक्त राज्य अमेरिका में, कर्मचारी द्वारा उनके रोजगार के दायरे में लिखा गया कोड स्वचालित रूप से work-for-hire है, जो नियोक्ता का है। एक स्वतंत्र ठेकेदार द्वारा लिखा गया कोड स्वचालित रूप से work-for-hire *नहीं* है — ठेकेदार कॉपीराइट बरकरार रखता है जब तक कि एग्रीमेंट स्पष्ट रूप से इसे सौंप न दे। यह अंतर उन क्लाइंटों को भ्रमित करता है जो मानते हैं कि उन्होंne इसके लिए भुगतान किया है इसलिए वे कोड के मालिक हैं। एक assignment खंड के बिना, वे नहीं हैं।
US कॉपीराइट कानून के तहत, एक ठेकेदार उस कोड का स्वामित्व बनाए रखता है जो वे लिखते हैं जब तक कि अधिकारों की लिखित सौंपी न हो। यदि आपके सॉफ्टवेयर डेवलपमेंट एग्रीमेंट में एक स्पष्ट IP assignment खंड (या जहां लागू हो work-for-hire खंड) शामिल नहीं है, तो डेवलपर कोड का मालिक है — भले ही आपने पूरा भुगतान कर दिया हो। यह सॉफ्टवेयर अनुबंधन में सबसे सामान्य और महंगे आश्चर्यों में से एक है।
MSA बनाम SOW: क्या अंतर है?
ये तीन दस्तावेज़ लगातार भ्रमित होते हैं। प्रत्येक की एक अलग भूमिका है, और गलत का उपयोग करना — या उन्हें मिलाना — जवाबदेही अंतराल पैदा करता है।
| दस्तावेज़ | यह क्या करता है | बाध्यकारी? | कब बनाया जाता है |
|---|---|---|---|
| Software Development Agreement (SDA) | एकल प्रोजेक्ट का पूरा अनुबंध: दायरा, IP, भुगतान, वारंटी, समाप्ति | हां | प्रोजेक्ट शुरुआत में |
| Master Service Agreement (MSA) | दीर्घकालिक कानूनी ढांचा: देनदारी, IP बेसलाइन, गोपनीयता, शासी कानून | हां | एक बार, संबंध शुरुआत में |
| Statement of Work (SOW) | MSA के तहत प्रोजेक्ट-विशिष्ट डिलीवरेबल, समयरेखा और भुगतान | हां | MSA के तहत प्रति प्रोजेक्ट |
| Change Order | मौजूदा SDA या SOW के लिए अधिकृत दायरा संशोधन | हां | प्रोजेक्ट के दौरान आवश्यकतानुसार |
| Proposal / Quote | पूर्व-अनुबंधिक दस्तावेज़; क्लाइंट स्वीकार या अस्वीकार कर सकता है | नहीं | अनुबंध से पहले |
एक बार के प्रोजेक्ट्स के लिए, एक स्टैंडअलोन SDA (इस गाइड में टेम्पलेट की तरह) सब कुछ कवर करता है। समय के साथ एक डेवलपमेंट पार्टनर के साथ निरंतर एंगेजमेंट के लिए — जहां आप एक साथ कई प्रोजेक्ट्स चला रहे हैं — MSA + SOW संरचना अधिक कुशल है। MSA एक बार कानूनी ढांचे की बातचीत करता है; प्रत्येक प्रोजेक्ट एक नया SOW जोड़ता है। हमारा Statements of Work का संपूर्ण गाइड SOW संरचना का विस्तार से वर्णन करता है।
सॉफ्टवेयर डेवलपमेंट एग्रीमेंट को ऑनलाइन कैसे साइन करें
एक हस्ताक्षरित SDA प्राप्त करने का मतलब पहले प्रिंट करना, स्कैन करना, ईमेल करना और उम्मीद करना होता था कि दूसरे पक्ष का संस्करण आपके से मेल खाता है। अब इस तरह से करने का कोई अच्छा कारण नहीं है।
इलेक्ट्रॉनिक हस्ताक्षर को कानूनी रूप से मान्य क्या बनाता है
ESIGN Act (US) और eIDAS (EU) के तहत, एक इलेक्ट्रॉनिक हस्ताक्षर व्यावसायिक एग्रीमेंट के लिए कानूनी रूप से मान्य है जब यह:
- हस्ताक्षर करने के इरादे से किसी द्वारा लगाया गया हो
- हस्ताक्षर किए जा रहे विशिष्ट दस्तावेज़ से जुड़ा हुआ हो
- हस्ताक्षरकर्ता को जिम्मेदार ठहराने में सक्षम हो
- रिकॉर्ड एक ऐसे रूप में संग्रहीत हो जिसे बाद में पुनर्प्राप्त किया जा सके
क्रिप्टोग्राफिक हस्ताक्षर और आगे बढ़ते हैं: प्रत्येक हस्ताक्षर गणितीय रूप से दस्तावेज़ के हैश से बंधा होता है। हस्ताक्षर करने के बाद एक भी अक्षर बदलें, और हैश बदल जाता है, जिससे छेड़छाड़ तुरंत पता चल जाती है। यह non-repudiation एग्रीमेंट को अदालत में बचाव योग्य बनाता है — न तो कोई पक्ष बाद में दावा कर सकता है कि दस्तावेज़ को बदल दिया गया था।
साइनिंग वर्कफ्लो कैसे काम करता है
IT कंपनियों के लिए दस्तावेज़ प्रबंधन में आमतौर पर एक साथ कई SDA, SOW और NDA चलते हैं। एक विशेष-निर्मित वर्कफ्लो ईमेल-आधारित साइनिंग के साथ आने वाले संस्करण-नियंत्रण बुरे सपने को रोकता है:
- 1.अंतिम SDA को एक कॉन्ट्रैक्ट मैनेजमेंट प्लेटफॉर्म पर अपलोड करें
- 2.प्रत्येक हस्ताक्षरकर्ता का ईमेल पता और साइनिंग क्रम जोड़ें
- 3.प्रत्येक पार्टी को एक सुरक्षित साइनिंग लिंक प्राप्त होता है — साइन करने के लिए कोई खाता आवश्यक नहीं
- 4.हस्ताक्षर लगाए जाते हैं; प्लेटफॉर्म timestamps, IP पतों और दस्तावेज़ हैश के साथ completion certificate जनरेट करता है
- 5.दोनों पक्षों को स्वचालित रूप से पूरी तरह से निष्पादित दस्तावेज़ प्राप्त होता है
- 6.ऑडिट ट्रेल अपरिवर्तनीय रूप से संग्रहीत होता है, भविष्य के संदर्भ या विवाद समाधान के लिए सुलभ
साइनिंग से जुड़े माइलस्टोन भुगतान
एक आधुनिक कॉन्ट्रैक्ट प्लेटफॉर्म में सबसे उपयोगी सुविधा स्वयं हस्ताक्षर नहीं है — यह हस्ताक्षर को उसके बाद क्या होता है से जोड़ना है। जब कोई डेवलपर एक माइलस्टोन डिलीवर करता है और क्लाइंट स्वीकृति फॉर्म पर हस्ताक्षर करता है, तो भुगतान ट्रिगर स्वचालित रूप से चालू हो जाता है। कोई मैनुअल इनवॉइस पीछा नहीं, कोई "मुझे लगा आप अलग से इनवॉइस भेजेंगे" भ्रम नहीं। कॉन्ट्रैक्ट-लिंक्ड भुगतान प्रबंधित करने वाली टीमों के लिए, यह स्वीकृति और बिलिंग के बीच अंतर को दूर करता है।
कॉन्ट्रैक्ट मैनेजमेंट योजनाओं की पूर्ण मूल्य निर्धारण जानकारी के लिए, Chaindoc की pricing page में शामिल है कि प्रत्येक टियर पर क्या शामिल है।
एक विशेष-निर्मित वर्कफ्लो SDA हस्ताक्षर घटनाओं को माइलस्टोन भुगतानों से जोड़ता है, स्वीकृति और बिलिंग के बीच अंतर को समाप्त करता है।
टैग
अक्सर पूछे जाने वाले प्रश्न
Chaindoc और सुरक्षित दस्तावेज़ साइनिंग से जुड़े सामान्य सवालों के जवाब।
क्या आप अपने दस्तावेज़ों को ब्लॉकचेन के साथ सुरक्षित करने के लिए तैयार हैं?
हमारे प्लेटफ़ॉर्म का उपयोग करने वाले हजारों व्यवसायों में शामिल हों जो सुरक्षित दस्तावेज़ प्रबंधन, डिजिटल हस्ताक्षर, और ब्लॉकचेन तकनीक द्वारा संचालित सहयोगात्मक कार्यप्रवाह के लिए हैं।