सिस्टम और सॉफ्टवेयर विकास के अनुबंध की अनुपयुक्त जिम्मेदारी क्या है? संशोधन बिंदुओं की व्याख्या

यदि आपने जो सिस्टम आदेश दिया था, उसकी डिलीवरी के बाद उसमें कोई त्रुटि होती है, तो कानूनी रूप से उसका सामना कैसे करना चाहिए?

ऑपरेशन करने का तरीका कठिन है, प्रसंस्करण की गति धीमी है, आदेश दिए गए सुविधाओं की कमी है… इन सिस्टम की समस्याओं के लिए, आदेश देने वाले के रूप में, सिस्टम विकास करने वाले विक्रेता के प्रति “अनुबंध अनुरूपता दायित्व” का मुद्दा उठाना होगा।

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

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

संविधान से अनुरूप नहीं होने की जिम्मेदारी के संशोधन के बिंदु

2017 में (हेसी 29 वर्ष (2017 ईसवी)) 2 जून को प्रकाशित ‘सिविल कोड का कुछ हिस्सा संशोधित करने वाले कानून’ को 2020 के 1 अप्रैल से लागू किया गया।

सिविल कोड में, संविधानों आदि के संबंध में सबसे मूलभूत नियम जिसे निर्धारित किया गया है, उसे ‘ओब्लिगेशन लॉ’ कहा जाता है।

ओब्लिगेशन लॉ के बारे में, 1896 में (मेजी 29 वर्ष (1896 ईसवी)) के निर्माण के बाद, लगभग 120 वर्षों तक कोई संशोधन नहीं किया गया था।

इसलिए, वर्तमान समाज के अनुरूप बनाने के लिए इस बार का संशोधन एक महत्वपूर्ण संशोधन है।

विशेष संशोधन बिंदुओं में, विभिन्न बिंदुओं के बावजूद, संविधान से अनुरूप नहीं होने की जिम्मेदारी की नई अवधारणा का निर्माण, मुख्य संशोधन बिंदुओं में से एक है।

इसके बाद, जिसे ‘दोष गारंटी जिम्मेदारी’ कहा जाता था, उसे ‘संविधान से अनुरूप नहीं होने की जिम्मेदारी’ में बदल दिया गया है।

अनुबंध अनुरूपता क्या है

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

यह “अनुबंध अनुरूपता” नागरिक संहिता के संशोधन के द्वारा पहले के “दोष” के स्थान पर लागू किया गया था।

सिस्टम या सॉफ्टवेयर विकास में, यदि समाप्त सिस्टम पूर्वनिर्धारित विनिर्देशों से मेल नहीं खाता है, या यदि सिस्टम या सॉफ्टवेयर की प्रकृति के आलोक में सामान्य रूप से होने वाली कार्यक्षमता या प्रदर्शन नहीं है, तो यह “अनुबंध अनुरूपता” के अंतर्गत आता है।

“अनुबंध अनुरूपता” की उपस्थिति का निर्णय लेते समय, समझौते या अनुबंध के उद्देश्य और प्रकृति पर विशेष ध्यान दिया जाता है।

इसलिए, सिस्टम या सॉफ्टवेयर विकास के उद्देश्य और आदेश देने की प्रक्रिया को लिखित रूप में रखना, और यह स्पष्ट करना कि आदेशकर्ता ने किस प्रकार की मांग या छवि रखी थी, महत्वपूर्ण होता है।

सॉफ्टवेयर की खराबी जो ‘अनुबंध अनुरूपता’ के लिए प्रासंगिक होती है

जब सॉफ्टवेयर में समस्या उत्पन्न होती है और मरम्मत में देरी होती है

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

उदाहरण के लिए, यदि आपके द्वारा स्थापित स्टॉक जांच सिस्टम की खोज प्रक्रिया में 30 मिनट से अधिक समय लग रहा है, और ग्राहकों से पूछताछ करने के लिए आपको अलग से हस्तलिखित स्टॉक लेजर तैयार करना पड़ता है, तो ऐसे मामले में, वर्तमान ‘अनुबंध अनुरूपता’ के अंतर्गत ‘दोष’ मान्य होता है। इस पर एक न्यायिक निर्णय मौजूद है (टोक्यो जिला न्यायालय, 22 अप्रैल 2002 (हिजी 14 वर्ष))।

जब समस्याएं क्रमशः उत्पन्न होती हैं

इसके अलावा, यदि प्रत्येक समस्या हल्की होती है और इसे सुधारने में समय नहीं लगता, लेकिन बार-बार कई बार समस्याएं उत्पन्न होती हैं, और सभी समस्याओं को सुधारने और सही ढंग से काम करने में बहुत समय लगता है, तो ऐसा माना जाता है।

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

सॉफ्टवेयर की खराबी आदि ‘संविदा अनुपयुक्तता’ के लिए प्राप्त नहीं होती है

जब देरी के बिना मरम्मत की गई हो या विकल्प सुविधा लागू की गई हो

न्यायिक मामलों में, यदि उपयोगकर्ता द्वारा बग या अन्य खराबी का उल्लेख किया गया हो, तो भी यदि देरी के बिना मरम्मत की गई हो, या उपयोगकर्ता के साथ चर्चा करके उचित मानी जाने वाली विकल्प सुविधा लागू की गई हो, तो इसे ‘दोष’ माना नहीं जाता है (टोक्यो जिला न्यायालय, 1997 (हीसे 9) फरवरी 18)।

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

इसलिए, यदि खराबी होती है, तो देरी के बिना मरम्मत करने आदि के उपाय करने पर इसे ‘दोष’ माना नहीं जाना चाहिए।

यह वर्तमान ‘संविदा अनुपयुक्तता’ के अधीन भी समान रूप से माना जा सकता है।

यहां ‘देरी के बिना’ आदि का निर्णय लेने के लिए आधार, सिस्टम विकास के प्रक्रिया में तैयार किए गए मीटिंग के नोट्स आदि के प्रमाण हैं।

इनके महत्व के बारे में नीचे दिए गए लेख में विस्तार से विवेचना की गई है।

जब किसी विशेष व्यक्ति ने ऑपरेशन को आसानी से समझा नहीं

ऑपरेटिविटी और उपयोग की सुविधा के बारे में, विषयवस्तु के आधार पर बहुत कुछ होता है, इसलिए सामान्य उपयोगकर्ता को मानक के रूप में लेते हुए, उपयोग के लिए अनुपयुक्त होने पर ‘संविदा अनुपयुक्तता’ मानी जाती है।

केवल इस बात की वजह से कि किसी विशेष व्यक्ति ने ऑपरेशन को आसानी से समझा नहीं, इसे ‘संविदा अनुपयुक्तता’ माना नहीं जा सकता है।

जब विक्रेता के काम के अलावा किसी अन्य कारण से खराबी हुई हो

यदि सिस्टम या सॉफ्टवेयर विकास करने वाले विक्रेता के विकास कार्य आदि से संबंधित किसी अन्य कारण से खराबी हुई हो, तो इस सिस्टम या सॉफ्टवेयर में ‘संविदा अनुपयुक्तता’ होने का कहना गलत होगा।

उदाहरण के लिए, यदि विक्रेता द्वारा प्राप्त न की गई हार्डवेयर की समस्या के कारण खराबी हुई हो, तो इसे ‘संविदा अनुपयुक्तता’ माना नहीं जाएगा।

【सप्लीमेंट】जब उपयोगकर्ता के निर्देशानुसार खराबी हुई हो

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

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

इस निर्णय के पीछे का विचार यह हो सकता है कि सॉफ्टवेयर विकास में, आदेश देने वाले उपयोगकर्ता को भी ‘सहयोग करने की जिम्मेदारी’ होती है। विस्तार से जानने के लिए, नीचे दिए गए लेख का संदर्भ लें।

https://monolith.law/corporate/user-obligatory-cooporation[ja]

अनुबंध अनुरूपता दायित्व के आधार पर निर्माणकर्ता / खरीददार द्वारा दावा किए जा सकने वाले मुद्दे

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

मरम्मत का अनुरोध

यदि दोष को अनुबंध अनुरूपता के रूप में मूल्यांकन किया जाता है, तो आदेशकर्ता द्वारा दोष की मरम्मत का अनुरोध किया जा सकता है।

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

हालांकि, संशोधन के बाद भी, यदि “अनुबंध अनुरूपता महत्वपूर्ण नहीं है और मरम्मत के लिए अत्यधिक खर्च की आवश्यकता है” तो मरम्मत का अनुरोध स्वीकार नहीं किया जा सकता है।

नुकसान भरपाई का अनुरोध

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

संशोधन से पहले, विशेष संधियों के अभाव में, नुकसान भरपाई का अनुरोध करने की क्षमता थी, चाहे लापरवाही हो या नहीं।

हालांकि, संशोधन के बाद, यदि प्रदर्शनकर्ता के पास मुक्ति का कारण (जो ऋणी की दोषी होने पर लौटाया नहीं जा सकता) होता है, तो नुकसान भरपाई का अनुरोध करने की क्षमता नहीं होती है।

इसलिए, विक्रेता यदि मुक्ति का कारण साबित करता है, तो उसे नुकसान भरपाई की जिम्मेदारी नहीं होती है।

अनुबंध रद्द करना

सिस्टम या सॉफ़्टवेयर की अनुबंध अनुरूपता के आधार पर, विकास अनुबंध को रद्द किया जा सकता है।

पहले से प्रस्तुत किए गए न्यायाधीश के फैसले में, स्टॉक जांच सिस्टम की खोज प्रक्रिया में 30 मिनट से अधिक समय लगने जैसी समस्याएं थीं, जिससे प्रक्रिया का समय बहुत अधिक हो गया, और टर्मिनल का उपयोग नहीं करने की समस्या भी उत्पन्न हुई, जिसके कारण उन्हें सिस्टम का निरंतर उपयोग करना छोड़ना पड़ा, और इसलिए उन्होंने अनुबंध को रद्द करने की मंजूरी दी (टोक्यो जिला न्यायालय, 22 अप्रैल 2002 (हिजी 14)).

संशोधन से पहले, दोष के कारण “अनुबंध का उद्देश्य प्राप्त करने में सक्षम नहीं होने” पर ही, अनुबंध को रद्द करने की क्षमता थी। हालांकि, संशोधन के बाद, ऐसी सीमाओं को हटा दिया गया है।

हालांकि, संशोधित कानून के तहत भी, यदि अनुबंध अनुरूपता की स्थिति “हल्की” होती है, तो रद्द करने की मंजूरी नहीं दी जाती है, इस बात का ध्यान रखना आवश्यक है।

मुआवजा कम करने का अनुरोध

मुआवजा कम करने का अधिकार, संशोधन के बाद नया स्थापित किया गया है।

जब सिस्टम में दोष होता है, और आदेशकर्ता ने उसकी मरम्मत का अनुरोध किया होता है, फिर भी उचित समय के बाद भी मरम्मत नहीं होती है, तो आदेशकर्ता द्वारा मुआवजा कम करने का अनुरोध किया जा सकता है।

जिम्मेदारी का समय

• मरम्मत का अनुरोध
• नुकसान भरपाई का अनुरोध
• अनुबंध रद्द करना
• मुआवजा कम करने का अनुरोध

इनमें से, इन अधिकारों का प्रयोग करने के लिए समय सीमित होता है।

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

संशोधन से पहले, अधिकारों का प्रयोग करने का समय सीमित था, सिस्टम या सॉफ़्टवेयर को “एक वर्ष के भीतर सौंप दिया गया” था। इसलिए, संशोधन के बाद, अधिकारों का प्रयोग करने का समय बढ़ गया है।

वैसे, इस तरह की समय सीमा के अलावा, अनुबंध अनुरूपता दायित्व के आधार पर मान्यता प्राप्त उपरोक्त अधिकारों पर नष्ट होने के नियम भी लागू होते हैं।

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

मुआवजा भुगतान अस्वीकार

आदेशकर्ता, विकासकर्ता द्वारा मरम्मत या नुकसान भरपाई करने तक, मुआवजा की पूरी राशि का भुगतान अस्वीकार कर सकता है।

अनुबंध अनुरूपता को ध्यान में रखते हुए अनुबंध प्रावधानों के बिंदु

अनुबंध अनुरूपता की जिम्मेदारी का प्रावधान वैकल्पिक है, और पक्षों के विशेष समझौते के द्वारा, जिम्मेदारी की सीमा को सीमित करने या अधिकार का अभ्यास करने की अवधि को संक्षिप्त करने की संभावना होती है।

इसलिए, यहां हम सिस्टम और सॉफ्टवेयर विकास में, अनुबंध अनुरूपता की जिम्मेदारी के संबंध में ध्यान देने योग्य अनुबंध प्रावधानों की व्याख्या करेंगे।

बिंदु 1: अनुबंध अनुरूपता के विषय और सीमा

यदि सिस्टम या सॉफ्टवेयर से संतुष्ट नहीं है, तो आदेशकर्ता विक्रेता पर अनुबंध अनुरूपता की जिम्मेदारी का दावा करना चाहेगा।

हालांकि, विक्रेता के रूप में, यह स्वीकार्य नहीं है कि केवल विशेषताओं के आधार पर, अनुबंध अनुरूपता की जिम्मेदारी का दावा किया जाए।

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

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

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

इस प्रावधान के द्वारा, आदेशकर्ता की पसंद के आधार पर, अनुबंध अनुरूपता की जिम्मेदारी का दावा करने से बचा जा सकता है, फिर भी विशेषता पत्र के अनुसार विकास किया गया है।

बिंदु 2: गारंटी की अवधि की स्पष्टता

अनुबंध अनुरूपता की जिम्मेदारी का अधिकार कार्यान्वित करने का समय, उत्पाद को “सौंपने के समय” नहीं, बल्कि अनुबंध अनुरूपता को “जानने के समय से” शुरू होता है।

इसके अलावा, यदि अलग से नष्ट होने की समय सीमा लागू होती है, तो उसकी अवधि “दस वर्ष” की अधिकतम होती है, जो लंबी अवधि के लिए होती है।

विक्रेता के लिए, कुछ मामलों में “दस वर्ष” की लंबी अवधि के लिए मुफ्त में गारंटी देना एक बड़ा बोझ होता है, और उसे अनुमानित कीमत के चरण में जोड़ना पड़ता है।

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

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

बिंदु 3: अनुबंध अनुरूपता के उत्पन्न होने पर प्रतिक्रिया

अनुबंध अनुरूपता के उत्पन्न होने पर, नुकसान भरपाई की मांग या रद्दीकरण आदि, सिविल कानून द्वारा मान्यता प्राप्त अधिकारों में से, पक्षों के समझौते के आधार पर, कुछ को ही लागू करने की संभावना होती है।

आदेशकर्ता के रूप में, अनुबंध में किस प्रकार की सीमाएँ लगाई गई हैं, इसे ठीक से समझना आवश्यक है।

सारांश: “अनुबंध अनुपयुक्त दायित्व” से संबंधित अनुबंध पत्र का निर्माण वकील से परामर्श करें

सिविल कोड के संशोधन से, सिस्टम और सॉफ्टवेयर विकास के कानूनी संबंधों पर भी बड़ा प्रभाव पड़ा है।

यदि सप्लाई की गई सिस्टम में कोई खराबी होती है, तो क्या यह “अनुबंध अनुपयुक्तता” के अंतर्गत आता है, और किस प्रकार की जिम्मेदारी का सवाल उठाया जा सकता है, इसका एक सामान्य उत्तर नहीं हो सकता।

इसके अलावा, विवादों को पहले से ही रोकने के लिए, विकास अनुबंध के चरण में आदेशकर्ता और विक्रेता के बीच पर्याप्त वार्ता करना अत्यावश्यक है।

अनुबंध पत्र के निर्माण के बारे में किसी भी प्रकार की चिंता होने पर, कृपया विशेषज्ञ वकील से परामर्श करें।