सिस्टम र सफ्टवेयर विकासको सम्झौता अनुपालन जिम्मेवारी के हो? संशोधन बिन्दुहरूको व्याख्या

यदि तपाईंले अर्डर गरेको सिस्टम डेलिभरी पछि त्रुटि देखा परे, जापानी कानून अनुसार त्यसको कानूनी उपचार के होला?

प्रयोग विधि जटिल छ, प्रक्रिया गति ढिलो छ, अर्डर गरिएका सुविधाहरू समावेश छैनन्… यस्ता सिस्टम सम्बन्धी समस्याहरूको सामना गर्दा, अर्डरकर्ताले सिस्टम विकास गर्ने वेन्डरसँग ‘अनुबंध अनुरूपता जिम्मेवारी’ (Contract Non-Conformity Liability) को मुद्दा उठाउनु पर्ने हुन्छ।

‘अनुबंध अनुरूपता जिम्मेवारी’ 2017 (2017) मा भएको मिनपो (जापानी सिभिल कोड) संशोधनबाट खारेज गरिएको ‘दोष धारणा जिम्मेवारी’ (Defect Warranty Liability) को स्थानमा नयाँ स्थापना गरिएको हो। त्यसैले, यो संशोधनले सिस्टम र सफ्टवेयर विकासमा कसरी प्रभाव पार्छ भन्ने कुरामा ध्यान दिन आवश्यक छ।

अक्सर डेलिभरी पछि उत्पन्न हुने समस्याहरू। यस्ता समस्याहरूलाई टाल्नका लागि, ‘अनुबंध अनुरूपता जिम्मेवारी’ को सामग्री र संशोधनको प्रभावलाई व्याख्या गर्नेछौं।

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

२०१७ ईस्वी (हेइसेइ २९ वर्ष) जुन २ तारिखमा प्रकाशित ‘सिभिल कोडको केही भागहरूमा संशोधन गर्ने कानून’ २०२० ईस्वी अप्रिल १ देखि लागू भएको छ।

सिभिल कोडको भित्र, करार लगायतका विषयहरूमा सबैभन्दा मौलिक नियमहरू निर्धारित गरिएको खण्डलाई ‘ऋण सम्बन्धी कानून’ भनिन्छ।

ऋण सम्बन्धी कानूनको विषयमा १८९६ ईस्वी (मेइजी २९ वर्ष) को स्थापना देखि लगभग १२० वर्षसम्म धेरै परिमार्जन भएको थिएन।

त्यसैले, वर्तमान समाजलाई ध्यानमा राखेर यस पटकको संशोधनमा ठूलो परिवर्तन गरिएको छ।

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

यसले ‘दोष जिम्मेवारी’ भनिने प्रथालाई ‘करार अनुपालन जिम्मेवारी’ले प्रतिस्थापन गरेको छ।

जापानी कानून अनुसार के हो ‘契約不適合’?

‘契約不適合’ भन्नाले, सम्झौता गर्ने पक्षहरूको सहमति वा सम्झौताको उद्देश्य र प्रकृतिको आधारमा, उत्पादनले आफ्नो मौलिक कार्य, गुणस्तर, प्रदर्शन वा अवस्था समेटेको छैन भन्ने कुरा जनाउँछ।

यो ‘契約不適合’ जापानी नागरिक संहिता (民法) को संशोधनबाट परम्परागत ‘瑕疵 (काशी)’ को स्थानमा प्रयोगमा ल्याइएको हो।

सिस्टम वा सफ्टवेयर विकासमा, तयार पारिएको सिस्टमले पहिले निर्धारित विशेषताहरूसँग मेल खाँदैन वा सिस्टम वा सफ्टवेयरको प्रकृतिको आधारमा सामान्यतया भएको हुनुपर्ने कार्य वा प्रदर्शन छैन भने त्यस्ता अवस्थाहरू ‘契約不適合’ मा पर्दछन्।

‘契約不適合’ को अवस्था निर्धारण गर्दा, पक्षहरूको सहमति, सम्झौताको उद्देश्य र प्रकृति महत्वपूर्ण मानिन्छ।

त्यसैले, सिस्टम वा सफ्टवेयर विकासको उद्देश्य र आदेश दिने प्रक्रियालाई लिखित रूपमा राख्नु र आदेश दिने पक्षले कस्तो प्रकारको माग वा अवधारणा राखेको थियो भन्ने कुरा स्पष्ट पार्नु महत्वपूर्ण छ।

सफ्टवेयरको दोष जुन ‘जापानी कानुन अनुसार सम्झौता अनुपयुक्तता’ मा पर्दछ

सफ्टवेयरमा समस्या उत्पन्न भएमा र मर्मत ढिलाइ हुँदा

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

उदाहरणका लागि, अपनाइएको स्टक जाँच प्रणालीमा खोजी प्रक्रियामा ३० मिनेट भन्दा बढी समय लाग्ने जस्ता समस्या उत्पन्न भएको छ र ग्राहकहरूको प्रश्नको जवाफ दिन अलग हातले लेखिएको स्टक रेजिस्टर बनाउनुपर्ने अवस्था आएको छ, जुन अहिलेको ‘सम्झौता अनुपयुक्तता’ अन्तर्गत ‘दोष’ मा पर्दछ भनी मान्य गरिएको न्यायाधीशको निर्णय छ (टोक्यो जिल्ला अदालत, हेइसेइ (2002) १४ वर्ष अप्रिल २२ तारिख)।

दोषहरू क्रमशः प्रकट हुँदै गरेको अवस्था

यस्तै, प्रत्येक व्यक्तिगत दोषहरू हल्का हुन सक्छन् र सुधारमा धेरै समय नलाग्न सक्छ, तर दोषहरू बारम्बार प्रकट हुन्छन् र सबै दोषहरूलाई सुधार गरी सामान्य रूपमा कार्यान्वयन गर्न लामो समय लाग्न सक्छ।

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

सफ्टवेयरको दोष जुन ‘अनुबंध अनुपयुक्तता’ मा पर्दैन

तत्काल मर्मत गरिएको वा विकल्प उपाय अपनाइएको खण्डमा

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

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

त्यसैले, दोषहरू भएको भए पनि, यदि तत्काल मर्मत गर्ने वा अन्य उपायहरू अपनाइएको छ भने त्यसलाई ‘दोष’ मान्नु हुँदैन।

यो विचार ‘अनुबंध अनुपयुक्तता’ को सन्दर्भमा पनि उस्तै गरिन्छ।

यहाँ ‘तत्काल’ भन्ने निर्णयको आधार सिस्टम विकासको प्रक्रियामा बनाइएका मिनट्स वा अन्य प्रमाणहरू हुन्।

यी प्रमाणहरूको महत्वको बारेमा तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।

https://monolith.law/corporate/the-minutes-in-system-development[ja]

विशेष व्यक्तिले अपरेशन विधि सजिलै बुझ्न नसकेको अवस्था

अपरेशनको सुविधा र प्रयोगकर्ताको अनुभवमा व्यक्तिगत विचारहरू प्रमुख हुने भएकोले, सामान्य प्रयोगकर्ताको मानक अनुसार प्रयोग गर्न अयोग्य हुने अवस्थामा मात्र ‘अनुबंध अनुपयुक्तता’ मा पर्छ।

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

वेन्डरको काम बाहेक अन्य कारणले दोष उत्पन्न भएको अवस्था

सिस्टम वा सफ्टवेयर विकास गर्ने वेन्डरको विकास कार्यसँग सम्बन्धित नभएका कारणहरूले दोष उत्पन्न भएको अवस्थामा, यस सिस्टम वा सफ्टवेयरमा ‘अनुबंध अनुपयुक्तता’ छ भन्न सकिन्न।

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

【पूरक】प्रयोगकर्ताको निर्देशनले दोष उत्पन्न भएको अवस्था

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

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

यस्तो निर्णयको पछाडि भने, सफ्टवेयर विकासमा आदेश दिने प्रयोगकर्ता पक्षले पनि ‘सहयोगी दायित्व’ बहन गर्नुपर्छ भन्ने सोचाइ रहेको छ। विस्तृत जानकारीका लागि, तलको लेख हेर्नुहोस्।

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

जापानी कानुन अनुसार ठेक्का अनुपयुक्त जिम्मेवारीमा आधारित भवन निर्माता/क्रेताले गर्न सक्ने दाबीहरू

यहाँ हामी सिस्टम र सफ्टवेयर विकास सम्बन्धित ठेक्का अनुपयुक्त जिम्मेवारीको सामग्रीलाई, संशोधनबाट भएका परिवर्तनहरू समेत समावेश गरी व्याख्या गर्नेछौं।

मर्मत दाबी

यदि कुनै दोष ठेक्का अनुपयुक्तको रूपमा मानिन्छ भने, आदेशकर्ताले मर्मतको दाबी गर्न सक्नेछन्।

संशोधन भन्दा पहिले, यदि समस्या महत्वपूर्ण थिएन र मर्मतको लागि अत्यधिक खर्च आवश्यक थियो भने, मर्मत दाबी गर्न सकिन्थेन। तर संशोधनले यस्तो सीमालाई हटाएको छ।

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

क्षतिपूर्ति दाबी

यदि कुनै दोषपूर्ण सिस्टम वा सफ्टवेयरका कारण सामान्य व्यापार गर्न असम्भव हुन्छ वा अतिरिक्त खर्च गर्नुपर्छ भने, आदेशकर्ताले क्षतिपूर्ति दाबी गर्न सक्नेछन्।

संशोधन भन्दा पहिले, विशेष सम्झौता नभएसम्म दोषको हुनु नहुनुलाई बिना प्रश्न गरी क्षतिपूर्ति दाबी गर्न सकिन्थ्यो।

तर, संशोधनले, यदि कार्यान्वयनकर्तासँग मुक्ति कारण (ऋणीको दोषमा ल्याउन सकिने कारण) छ भने, क्षतिपूर्ति दाबी गर्न सकिने छैन।

यसकारण, विक्रेताले मुक्ति कारण साबित गरे भने, क्षतिपूर्ति जिम्मेवारी बहन गर्नु पर्दैन।

ठेक्का रद्दीकरण

सिस्टम वा सफ्टवेयरको ठेक्का अनुपयुक्तको कारणले, विकास ठेक्का रद्द गर्न सकिन्छ।

पहिले उल्लेख गरिएको न्यायिक निर्णयमा, इन्भेन्टरी प्रश्न सिस्टमको खोजी प्रक्रियामा ३० मिनेट भन्दा बढी समय लाग्ने जस्ता प्रक्रिया समय अत्यधिक लम्बो हुने र टर्मिनल आफैंको प्रयोग गर्न नसकिने जस्ता अवरोधहरू उत्पन्न हुने दोषहरू थिए, र प्रयोगमा ल्याइएको सिस्टमको निरन्तर प्रयोग छोड्न बाध्य भएकोले, ठेक्का रद्दीकरणलाई स्वीकार गरिएको छ (टोक्यो जिल्ला न्यायाधीश हेइसेइ (2002) अप्रिल २२)।

संशोधन भन्दा पहिले, दोषका कारण “ठेक्का गरेको उद्देश्य प्राप्त गर्न सकिने” अवस्थामा मात्र ठेक्का रद्द गर्न सकिन्थ्यो। तर संशोधनले यस्तो सीमालाई हटाएको छ।

तथापि, संशोधित कानुन अनुसार पनि, यदि ठेक्का अनुपयुक्तको डिग्री “हल्का” छ भने, रद्दीकरण स्वीकार गरिने छैन, यसमा ध्यान दिनु आवश्यक छ।

पारिश्रमिक कटौती दाबी

पारिश्रमिक कटौती दाबी अधिकार संशोधनबाट नयाँ स्थापित भएको छ।

जब सिस्टममा दोष छ र आदेशकर्ताले त्यसको मर्मतको दाबी गरेको छ तर पर्याप्त समय बितिसक्दा पनि मर्मत गरिएको छैन भने, आदेशकर्ताले पारिश्रमिक कटौती दाबी गर्न सक्नेछन्।

जिम्मेवारी बहन गर्ने अवधि

• मर्मत दाबी
• क्षतिपूर्ति दाबी
• ठेक्का रद्दीकरण
• पारिश्रमिक कटौती दाबी

यी अधिकारहरू प्रयोग गर्न सकिने अवधि सीमित छ।

विशेष गरी, आदेशकर्ताले सिस्टम वा सफ्टवेयरमा ठेक्का अनुपयुक्त छ भन्ने कुरा “थाहा पाएको दिनदेखि एक वर्ष भित्र” विक्रेतालाई सूचित गरेको खण्डमा मात्र, अधिकार प्रयोग गर्न सकिन्छ।

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

यस्तो अवधि सीमालाई अलग गर्दा, ठेक्का अनुपयुक्त जिम्मेवारीमा आधारित उल्लेखित अधिकारहरूमा नष्ट हुने समयसीमा को प्रावधान पनि लागू हुन्छ।

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

पारिश्रमिक भुक्तानी अस्वीकार

आदेशकर्ताले, विकासकर्ताले मर्मत वा क्षतिपूर्ति गर्नु भन्दा पहिले पारिश्रमिकको पूर्ण रकम भुक्तानी गर्न अस्वीकार गर्न सक्नेछन्।

जापानी अनुबंध अनुपालनताका लागि अनुबंध प्रावधानहरूका महत्वपूर्ण बिन्दुहरू

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

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

बिन्दु १: अनुबंध अनुपालनताको लागि घटनाहरू र क्षेत्र

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

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

साथै, विक्रेताले अनुचित अनुबंध अनुपालनता जिम्मेवारीको चुनौतीको लागि तयारी गर्दै अनुमानित लागतलाई धेरै बढाउन सक्छ, जुन आदेशकर्ताको लागि पनि हानिकारक हुन सक्छ।

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

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

यस प्रावधानबाट, विशिष्टता पत्र अनुसार विकास गरिएको भए पनि, आदेशकर्ताको रुचिको आधारमा अनुबंध अनुपालनता जिम्मेवारीको लागि चुनौती दिनबाट बच्न सकिन्छ।

बिन्दु २: वारंटी अवधिको स्पष्टता

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

साथै, अलग नाश हुने समयसीमा लागू भएको अवस्थामा पनि, त्यो अवधि ‘दश वर्ष’ सम्मको लागि हुन्छ, जुन लामो समयको लागि हुन्छ।

विक्रेताको लागि, कहिलेकाहीं ‘दश वर्ष’ जति लामो समयको लागि निःशुल्क वारंटी दिनु ठूलो बोझ हुन सक्छ, र त्यो खर्च अनुमानित चरणमा थप्न बाध्य हुन सक्छ।

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

त्यसैले, सिस्टमको सामग्री अनुसार वारंटी अवधिको लचिलो सेटिङ्ग गर्नु उपयुक्त हुन सक्छ।

बिन्दु ३: अनुबंध अनुपालनता उत्पन्न भएको अवस्थामा प्रतिक्रिया

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

आदेशकर्ताको रूपमा, अनुबंधमा कुन कुन सीमाहरू लागू गरिएका छन् भन्ने कुरा राम्ररी बुझ्नु आवश्यक छ।

सारांश: ‘अनुबंध अनुपालन जिम्मेवारी’ समावेशित अनुबंधको तयारीमा वकिलसँग परामर्श गरौं

जापानी नागरिक संहिता (民法) को संशोधनले सिस्टम र सफ्टवेयर विकासका कानूनी सम्बन्धमा पनि ठूलो प्रभाव पारेको छ।

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

यसको अतिरिक्त, विवादको अग्रिम रोकथामको लागि, विकास अनुबंधको चरणमा आदेशकर्ता र वेन्डर बीच पर्याप्त परामर्श गर्नु अत्यावश्यक छ।

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