सॉफ्टवेयर विकास समझौता मार्गदर्शिका: शामिल करने के लिए 15 आवश्यक खंड

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

सॉफ्टवेयर विकास समझौते में कौन-कौन से खंड शामिल होने चाहिए?

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

1. परियोजना का दायरा और आवश्यकताएँ

कार्यक्षेत्र खंड स्पष्ट रूप से परिभाषित करता है कि डेवलपर से क्या निर्माण करने की अपेक्षा की जाती है। समझौते में निम्नलिखित बातें शामिल होनी चाहिए:

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

2. अपेक्षित परिणाम और महत्वपूर्ण पड़ाव

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

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

3. विकास समयरेखा

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

अनुबंध में ग्राहक की प्रतिक्रिया के लिए 5 से 10 कार्यदिवसों जैसी एक निश्चित समीक्षा अवधि भी निर्धारित की जा सकती है। यदि किसी भी पक्ष के कारण देरी होती है, तो समझौते में यह स्पष्ट होना चाहिए कि समय सीमा को कैसे समायोजित किया जाएगा। उदाहरण के लिए, ग्राहक से आवश्यक जानकारी प्राप्त करने में देरी से विकास कार्यक्रम में वृद्धि हो सकती है।

4. शुल्क और भुगतान की शर्तें

भुगतान की शर्तें सरल और स्पष्ट होनी चाहिए। समझौते में कुल कीमत या प्रति घंटा दर, भुगतान की तारीखें, कर, खर्च और देर से भुगतान के परिणामों का उल्लेख होना चाहिए।

दो सामान्य मूल्य निर्धारण मॉडल इस प्रकार हैं:

• निश्चित शुल्क: किसी परिभाषित परियोजना के दायरे के लिए पूर्व निर्धारित राशि।
• समय और सामग्री: भुगतान वास्तविक घंटों या उपयोग किए गए संसाधनों के आधार पर किया जाता है, जो आमतौर पर उन परियोजनाओं के लिए उपयुक्त होता है जहां आवश्यकताएं बदल सकती हैं।

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

5. परीक्षण और स्वीकृति

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

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

6. बौद्धिक संपदा स्वामित्व

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

• कस्टम कोड: ग्राहक के लिए विशेष रूप से विकसित किया गया कोड।
• पूर्व-मौजूद बौद्धिक संपदा: डेवलपर के स्वामित्व वाले उपकरण, लाइब्रेरी, फ्रेमवर्क या कोड।
• तृतीय-पक्ष सॉफ़्टवेयर: बाहरी विक्रेताओं द्वारा नियंत्रित घटक।
• ओपन-सोर्स कंपोनेंट्स: सॉफ्टवेयर जो अपने लागू ओपन-सोर्स लाइसेंस द्वारा शासित होता है।

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

यह भी पढ़ें: बौद्धिक संपदा अधिकारों का दावा कैसे करें

7. स्रोत कोड और रिपॉजिटरी तक पहुंच

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

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

8. ओपन-सोर्स और थर्ड-पार्टी सॉफ्टवेयर

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

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

9. गोपनीयता और डेटा संरक्षण

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

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

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

10. सुरक्षा और अनुपालन

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

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

11. वारंटी और रखरखाव

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

वारंटी अवधि आम तौर पर लॉन्च या औपचारिक स्वीकृति के बाद 30 से 90 दिनों के बीच होती है, जो समझौते पर निर्भर करती है। रखरखाव, वारंटी सहायता से अलग होता है। वारंटी समाप्त होने के बाद, पक्षकार निगरानी, ​​अपग्रेड, ऑपरेटिंग सिस्टम में बदलाव, सर्वर सहायता, बग फिक्स और नई सुविधाओं को कवर करने वाली एक अलग रखरखाव व्यवस्था में प्रवेश कर सकते हैं।

12. क्षतिपूर्ति और दायित्व की सीमा

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

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

13. समाप्ति और संक्रमण

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

• अनुबंध के उल्लंघन के लिए अनुबंध की समाप्ति तब संभव हो सकती है जब एक पक्ष समझौते का महत्वपूर्ण रूप से उल्लंघन करता है और 15 से 30 दिनों जैसी निर्दिष्ट सुधार अवधि के भीतर समस्या को ठीक करने में विफल रहता है।
• सुविधा के आधार पर अनुबंध समाप्त करने से किसी भी पक्ष को अग्रिम लिखित सूचना के अधीन, उल्लंघन साबित किए बिना समझौते को समाप्त करने की अनुमति मिल सकती है।

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

14. गैर-अनुरोध और कर्मियों का उपयोग

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

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

15. विवाद समाधान एवं सामान्य शर्तें

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

यदि विवाद का समाधान नहीं होता है, तो अनुबंध में अदालती कार्यवाही से पहले मध्यस्थता या मध्यस्थता का प्रावधान हो सकता है। समझौते में निम्नलिखित बातें भी स्पष्ट रूप से बताई जानी चाहिए:

• शासी कानून।
• क्षेत्राधिकार।
• जहां लागू हो, वहां मध्यस्थता या सुलह प्रक्रिया।
• औपचारिक सूचना संबंधी आवश्यकताएं।
• संशोधन प्रक्रियाएँ।
• अप्रत्याशित घटनाएँ।

सॉफ्टवेयर विकास समझौते की चेकलिस्ट

व्यवसायों को किन सामान्य गलतियों से बचना चाहिए?

1. अस्पष्ट प्रोजेक्ट स्कोप का उपयोग करना: "डेवलपर एक ई-कॉमर्स एप्लिकेशन बनाएगा" जैसा कथन आमतौर पर पर्याप्त विस्तृत नहीं होता है। एक उचित स्कोप में सुविधाओं, तकनीकी आवश्यकताओं, एकीकरणों और बहिष्करणों को स्पष्ट रूप से बताया जाना चाहिए।
2. स्वीकृति मानदंड परिभाषित न करना: वस्तुनिष्ठ स्वीकृति मानकों के बिना, इस बात पर असहमति उत्पन्न हो सकती है कि कोई उपलब्धि पूरी हुई है या नहीं।
3. स्रोत कोड के स्वामित्व को अस्पष्ट छोड़ना: सॉफ़्टवेयर के लिए भुगतान करने का मतलब यह नहीं है कि सभी बौद्धिक संपदा अधिकार स्वतः ही हस्तांतरित हो गए हैं। स्वामित्व और लाइसेंसिंग को लिखित समझौते में स्पष्ट रूप से शामिल किया जाना चाहिए।
4. ओपन-सोर्स लाइसेंसिंग की अनदेखी: व्यवसायों को यह जानना चाहिए कि वे किन ओपन-सोर्स घटकों का उपयोग कर रहे हैं और उनके लाइसेंस से जुड़े दायित्वों को समझना चाहिए।
5. परिवर्तनों का दस्तावेज़ीकरण न करना: अतिरिक्त सुविधाओं के लिए मौखिक अनुरोध मूल्य और समयसीमा को लेकर विवाद उत्पन्न कर सकते हैं। प्रत्येक महत्वपूर्ण परिवर्तन के लिए लिखित अनुमोदन प्रक्रिया आवश्यक है।
6. डेटा सुरक्षा पर ध्यान न देना: अनुबंध में सुरक्षा संबंधी जिम्मेदारियों का विभाजन होना चाहिए और इसमें पहुंच नियंत्रण, एन्क्रिप्शन, परीक्षण, डेटा उल्लंघन की रिपोर्टिंग और व्यक्तिगत डेटा के प्रबंधन को शामिल किया जाना चाहिए।
7. रखरखाव की शर्तों का स्पष्ट न होना: समझौते में यह स्पष्ट होना चाहिए कि कौन से दोष वारंटी के अंतर्गत आते हैं और किन सेवाओं के लिए अतिरिक्त भुगतान की आवश्यकता होती है।
8. समाप्ति की योजना न बनाना: एक उचित निकास प्रक्रिया में सोर्स-कोड की डिलीवरी, क्रेडेंशियल, डेटाबेस, दस्तावेज़ीकरण, होस्टिंग एक्सेस और पूर्ण किए गए कार्य के लिए भुगतान शामिल होना चाहिए।

निष्कर्ष

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

अस्वीकरण : यह ब्लॉग केवल सूचनात्मक उद्देश्यों के लिए है। यदि आपको कानूनी परामर्श की आवश्यकता है, तो कृपया किसी अनुभवी कॉर्पोरेट वकील से संपर्क करें।