नेदरल्याण्ड्समा आईटी सेवा सम्झौता: कुन धाराहरू महत्त्वपूर्ण छन् र किन

IT सेवा सम्झौता भनेको त्यस्तो सम्झौता हो जस अन्तर्गत प्रदायकले तपाईंको व्यवसायमा प्रविधि सेवाहरू प्रदान गर्दछ: व्यवस्थित IT, सफ्टवेयर विकास, होस्टिंग, समर्थन वा संयोजन। डच कानून अन्तर्गत यो सामान्यतया डच नागरिक संहिताको पुस्तक ७ (Burgerlijk Wetboek, BW) अन्तर्गत सेवाहरूको लागि सम्झौता हो (overeenkomst van opdracht), तर यो कामको लागि सम्झौता बन्छ (aanneming van work) जहाँ प्रदायकले परिभाषित परिणाम प्रदान गर्नुपर्छ।

त्यो वर्गीकरणले धेरै कुरा निर्धारण गर्छ। यसले प्रदायकले आफ्नो सर्वोत्तम प्रयास गर्नुपर्छ कि परिणाम, तपाईं सम्झौता चाँडै समाप्त गर्न सक्नुहुन्छ कि सक्नुहुन्न, र समयसीमा छुट्दा के हुन्छ भनेर निर्धारण गर्छ।

डच कानून अन्तर्गत IT सेवा सम्झौता कस्तो प्रकारको सम्झौता हो?

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

डच कानूनले दुई प्रकारका दायित्वहरूलाई छुट्याउँछ जुन अंग्रेजी भाषाको IT सम्झौताहरूले प्रायः धमिलो पार्छ। उत्तम प्रयासको दायित्व (inspanningsverbintenis) ले प्रदायकलाई उचित रूपमा सक्षम पेशेवरको हेरचाहमा काम गर्न आवश्यक छ। यदि प्रदायक त्यो मापदण्ड पूरा गर्न असफल भयो भने मात्र यो उल्लङ्घन हुन्छ। परिणामको दायित्व (resultaatsverbintenis) लाई परिभाषित परिणाम चाहिन्छ। यदि त्यो परिणाम प्रदान गरिएन भने, प्रदायकले जतिसुकै प्रयास गरे पनि उल्लङ्घन गर्छ।

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

वर्गीकरणले समाप्तिलाई कसरी असर गर्छ?

यसले कसले र कुन सर्तहरूमा सम्झौता समाप्त गर्न सक्छ भन्ने निर्णय गर्छ। सेवाहरूको लागि सम्झौता अन्तर्गत, ग्राहकले सिद्धान्ततः जुनसुकै बेला सम्झौता समाप्त गर्न सक्छ।

धारा ७:४०८ BW अनुसार, ग्राहकले कुनै पनि समयमा सेवाहरूको लागि सम्झौता समाप्त गर्न सक्छ। त्यसपछि प्रदायकले गरेको कामको लागि उचित पारिश्रमिक पाउने हकदार हुन्छ (धारा ७:४११ BW)। ग्राहक एक निजी व्यक्ति भएको अवस्थामा त्यो अधिकारलाई बहिष्कार गर्न सकिँदैन। व्यवसायहरू बीच यो हुन सक्छ, र प्रदायक सर्तहरूले नियमित रूपमा यसलाई बहिष्कार वा प्रतिबन्धित गर्दछ। आफ्नो व्यवसायको क्रममा असाइनमेन्ट लिएको प्रदायकले बाध्यकारी कारणहरूको लागि मात्र समाप्त गर्न सक्छ (gewichtige redenen)। यदि तपाईंले ती पूर्वनिर्धारित नियमहरू विरुद्धको समाप्ति खण्ड पढ्नुभयो भने, तपाईंले तुरुन्तै देख्न सक्नुहुन्छ कि सम्झौता कसको लागि मस्यौदा गरिएको थियो। सेवाहरूको लागि सम्झौताको लागि हाम्रो गाइडले वैधानिक नियमहरूलाई थप विवरणमा सेट गर्दछ।

कुन कागजातले के गर्छ?

IT संलग्नता विरलै एउटा कागजात हुन्छ। तपाईंले सामान्यतया एउटा रूपरेखा सम्झौता, कामको एक वा बढी विवरण, सेवा स्तर सम्झौता, डेटा प्रशोधन सम्झौता र प्रदायकको सामान्य नियम र सर्तहरू पाउनुहुनेछ।

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

तपाईं दायरा, स्वीकृति र परिवर्तन नियन्त्रणलाई कसरी परिभाषित गर्नुहुन्छ?

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

अधिकांश विवादहरू सुरु हुने ठाउँको क्षेत्र खण्ड हो। "व्यवस्थित नेटवर्क सेवाहरू" क्षेत्र होइन; यो एक वर्ग हो। कार्ययोग्य विवरणले के निगरानी गरिन्छ र कुन घण्टामा, के प्याच गरिन्छ र कति पटक, र कतिवटा अन्त्य बिन्दुहरू र प्रयोगकर्ताहरू कभर गरिन्छ भनेर बताउँछ। यसले अनबोर्डिङ र अफबोर्डिङमा के समावेश छ, कुन घटनाहरू दायरामा छन्, के स्पष्ट रूपमा बहिष्कृत गरिएको छ, र अनुमानित आधाररेखाभन्दा बाहिर भोल्युम बढ्दा के हुन्छ भनेर पनि बताउँछ।

समावेशीकरण जत्तिकै बहिष्करणहरू महत्त्वपूर्ण हुन्छन्, र भरपर्दो प्रदायकहरूले तिनीहरूलाई स्वागत गर्छन्। सामान्य उम्मेदवारहरू घण्टा बाहिरको आपतकालीन काम, हार्डवेयर खरिद, तेस्रो-पक्ष सफ्टवेयर इजाजतपत्र, साइट भ्रमण, ग्राहक त्रुटि पछि डेटा रिकभरी, र प्रदायकले स्थापना नगरेका प्रणालीहरूको लागि समर्थन हुन्। जहाँ यी बहिष्कृत छन्, सम्झौताले आवश्यक परेमा उनीहरूलाई कुन दरमा शुल्क लिइनेछ भनेर पनि उल्लेख गर्नुपर्छ।

तपाईंलाई कहिले स्वीकृति प्रक्रिया चाहिन्छ?

जब कुनै चीज केवल सञ्चालन गर्नुको सट्टा निर्माण गरिन्छ। यो बिना, प्रदायकले वास्तवमा कहिले डेलिभर गरेको छ भन्ने कुरा स्पष्ट हुँदैन।

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

परिवर्तन नियन्त्रण किन उही समस्याको अंश हो?

किनभने प्रत्येक महत्वपूर्ण IT संलग्नता यसको जीवनकालमा परिवर्तन हुन्छ। प्रक्रिया बिना, तपाईं पछि सहमति भएको कुराको बारेमा बहस गर्नुहुनेछ।

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

सेवा स्तर सम्झौतामा के समावेश हुनुपर्छ?

प्रयोगयोग्य SLA ले मेट्रिक, कसरी र कुन अवधिमा मापन गरिन्छ, के बहिष्कृत गरिन्छ र असफलतामा के हुन्छ भनेर बताउँछ। ती प्रत्येक तत्वले चुपचाप अर्थको हेडलाइन संख्या खाली गर्न सक्छ।

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

उपलब्धतालाई नै लिनुहोस्। ९९.९ प्रतिशतको ग्यारेन्टी प्रभावशाली सुनिन्छ र अझै पनि ३०-दिनको महिनामा लगभग ४३ मिनेट डाउनटाइमको अनुमति दिन्छ; ९९ प्रतिशतले सात घण्टा भन्दा बढीको अनुमति दिन्छ। यो तथ्याङ्कले केवल तीनवटा कुरा थाहा पाएपछि मात्र केही अर्थ राख्छ:

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

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

सेवा क्रेडिटको वास्तवमा मूल्य के हो?

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

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

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

शुल्क र भुक्तानी कसरी निर्धारण गर्नुपर्छ?

मूल्य निर्धारण मोडेल, अनुक्रमणिका र बीजकलाई सटीक रूपमा वर्णन गर्नुहोस्। जहाँ सम्झौता मौन छ, ढिलो भुक्तानी सम्बन्धी डच वैधानिक नियमहरूले खाडल भर्छन्।

मूल्य निर्धारण मोडेल बताउनुहोस्: निश्चित शुल्क, प्रति प्रयोगकर्ता, प्रति उपकरण, प्रति टिकट, समय र सामग्री, वा संयोजन, र प्रत्येकमा के समावेश छ। प्रदायकको विवेकमा वार्षिक वृद्धिलाई अनुमति दिनुको सट्टा मूल्य वृद्धिको लागि सूचकांक र समीक्षा मितिको नाम दिनुहोस्। बीजकहरू कहिले जारी गरिन्छ, तिनीहरूले के निर्दिष्ट गर्नुपर्छ र भुक्तानी कहिले बाँकी हुन्छ भन्नुहोस्।

युरोपेली ढिलो भुक्तानी निर्देशन लागू गर्ने डच नियमहरू कुनै पनि व्यावसायिक सम्झौतामा जस्तै IT सम्झौताहरूमा पनि लागू हुन्छन्। धारा 6:119a BW अनुसार, कुनै अवधिमा सहमति नभएको अवस्थामा व्यवसायहरू बीचको भुक्तानी 30 दिन भित्र बाँकी रहन्छ। लामो अवधिमा सहमति हुन सक्छ, तर 60 दिन भन्दा बढीको अवधि ऋणदातालाई घोर अन्यायपूर्ण भएमा शून्य हुन्छ। एक पटक भुक्तानी ढिलो भएपछि, वैधानिक व्यावसायिक ब्याज स्वचालित रूपमा चल्छ। ऋणदाताले न्यूनतम €40 (धारा 6:96 BW) सहितको सङ्कलन लागत पनि दाबी गर्न सक्छ।

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

के तपाईं प्रदायकको मानक सर्तहरूमा वार्ता गर्न सक्नुहुन्छ?

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

लगभग हरेक डच आईटी प्रदायकले लागू हुने आफ्ना सामान्य नियम र सर्तहरू (algemene voorwaarden) घोषणा गर्दछ। यस क्षेत्रमा धेरैले उद्योग संघद्वारा प्रकाशित मानक सर्तहरू प्रयोग गर्छन्। यी सर्तहरू व्यावसायिक रूपमा मस्यौदा गरिएका छन् र दृढतापूर्वक प्रदायक-उन्मुख छन्: सर्वोत्तम प्रयास दायित्वहरू, छोटो गुनासो अवधिहरू, सम्झौता रकमको अंशमा सीमित दायित्व, र परिणामात्मक हानिको व्यापक बहिष्करण।

पहिलो नियम जानकारी दिने कर्तव्यसँग सम्बन्धित छ। सामान्य सर्तहरूको प्रयोगकर्ताले अर्को पक्षलाई सम्झौता सम्पन्न हुनुभन्दा अघि वा व्यवहारमा तिनीहरूलाई आपूर्ति गरेर तिनीहरूलाई पढ्नको लागि उचित अवसर दिनुपर्छ। यदि त्यसो भएन भने, व्यक्तिगत खण्डहरू रद्द गर्न सकिन्छ (लेख 6:233 र 6:234 BW)। दोस्रो नियम फारमहरूको लडाईसँग सम्बन्धित छ। जहाँ दुबै पक्षहरूले आफ्नै सर्तहरू उल्लेख गर्छन्, डच कानूनले धारा 6:225(3) BW मा "पहिलो शट" नियम पालना गर्दछ: पहिले उल्लेख गरिएका सर्तहरू लागू हुन्छन्, जबसम्म अर्को पक्षले तिनीहरूलाई स्पष्ट रूपमा अस्वीकार गर्दैन। त्यो धेरै अन्य कानुनी प्रणालीहरूमा स्थितिको विपरीत हो। सामान्य सर्तहरू र सर्तहरूमा व्याख्या गरिएको र अन्तर्राष्ट्रिय व्यावसायिक सम्झौताहरूमा पाँच सबैभन्दा सामान्य गल्तीहरूमा हाम्रो गाइडहरूले देखाउँछन् कि यो कसरी व्यवहारमा काम गर्दछ।

सफ्टवेयर र स्रोत कोड कसको स्वामित्वमा छ?

यसलाई सिर्जना गर्ने व्यक्तिले, यसको लागि भुक्तानी गर्ने पक्षले होइन। यदि यो तपाईंलाई लिखित रूपमा तोकिएको छ र कामद्वारा हस्तान्तरण गरिएको छ भने मात्र तपाईंले प्रतिलिपि अधिकार प्राप्त गर्नुहुन्छ।

सफ्टवेयरको लागि भुक्तानी गर्दा तपाईंलाई यसको मालिक बनाउँदैन। डच प्रतिलिपि अधिकार ऐन (Auteurswet) अन्तर्गत, काम सिर्जना गर्ने व्यक्ति लेखक हो र प्रतिलिपि अधिकार राख्छ। कुनै पनि नियमले कामको लागि कमिसन वा भुक्तानी गर्ने व्यक्तिलाई स्वामित्व हस्तान्तरण गर्दैन। दुई अपवादहरू छन्। जहाँ एक कर्मचारीले आफ्नो कर्तव्यको भागको रूपमा काम सिर्जना गर्दछ, रोजगारदातालाई लेखक मानिन्छ (धारा 7 Auteurswet)। जहाँ एक कानूनी संस्थाले लेखकको रूपमा प्राकृतिक व्यक्तिको नाम नलिई आफ्नै रूपमा काम प्रकाशित गर्दछ, त्यो संस्थालाई लेखक मानिन्छ (धारा 8 Auteurswet)। कुनै पनि अपवादले बाह्य प्रदायक वा स्वतन्त्र विकासकर्तालाई संलग्न गर्ने ग्राहकको सामान्य मामलालाई समेट्दैन।

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

पृष्ठभूमि, अग्रभूमि र तेस्रो-पक्ष सामग्रीलाई कसरी अलग गर्नुहुन्छ?

प्रत्येक वर्गलाई आफ्नै नियम दिनुहोस्: पृष्ठभूमि सामग्रीको लागि इजाजतपत्र, अग्रभूमि सामग्रीको स्वामित्व, र तेस्रो-पक्ष र खुला स्रोत घटकहरूको लागि वारेन्टी।

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

तपाईंलाई कहिले स्रोत कोड एस्क्रो चाहिन्छ?

जब तपाईंको व्यवसाय तपाईंको स्वामित्वमा नभएको सफ्टवेयरमा निर्भर हुन्छ। यदि प्रदायकले अब यसलाई कायम राख्न सक्दैन भने एस्क्रोले तपाईंलाई स्रोत कोडमा पहुँच दिन्छ।

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

तपाईंको डेटा कसको स्वामित्वमा छ?

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

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

प्रोसेसर सम्झौतामा के समावेश हुनुपर्छ?

जहाँ प्रदायकले तपाईंको निर्देशनमा व्यक्तिगत डेटा प्रशोधन गर्छ, GDPR लाई तोकिएको सामग्रीसँग लिखित प्रोसेसर सम्झौता आवश्यक पर्दछ। त्यो सामग्री बिना, दुबै पक्षहरू खुलासा हुन्छन्।

सामान्य डेटा संरक्षण नियमन (GDPR, डच AVG मा) को धारा २८(३) ले सम्झौतामा के समावेश हुनुपर्छ भनेर तोक्छ। यसले प्रशोधनको विषयवस्तु र अवधि, यसको प्रकृति र उद्देश्य, व्यक्तिगत डेटाका प्रकारहरू र डेटा विषयहरूको वर्गहरू वर्णन गर्नुपर्छ। यसले प्रोसेसरमा दायित्वहरूको एक सेट पनि लागू गर्नुपर्छ:

• कागजात गरिएका निर्देशनहरूमा मात्र प्रशोधन गर्ने;
• कर्मचारीहरूको गोपनीयता सुनिश्चित गर्ने;
• उपयुक्त प्राविधिक र संगठनात्मक सुरक्षा उपायहरू लिने;
• अनुमतिपत्र लिएर र समान सर्तहरूमा मात्र उप-प्रोसेसरहरूलाई संलग्न गराउने;
• डेटा विषय अनुरोधहरू र उल्लङ्घन सूचनाको साथ नियन्त्रकलाई सहयोग गर्ने;
• सेवाको अन्त्यमा डेटा मेटाउने वा फिर्ता गर्ने।

यी तत्वहरू नभएको सम्झौता अनुरूप हुँदैन। नेदरल्याण्ड्समा डेटा प्रशोधन सम्झौताको लागि हाम्रो गाइडले आवश्यक सामग्री समेट्छ।

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

सुरक्षा खण्ड कति विशिष्ट हुनुपर्छ?

तपाईंले यसलाई जाँच गर्न सक्ने गरी विशिष्ट। उपायहरूको नाम दिनुहोस् र तिनीहरूलाई प्रमाणित गर्ने तरिका आफैलाई दिनुहोस्।

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

उल्लङ्घन सूचना खण्डले के भन्नु पर्छ?

यसले प्रदायकलाई छोटो, निश्चित अवधि भित्र तपाईंलाई बताउन आवश्यक पर्दछ। अन्यथा तपाईं आफ्नै ७२-घण्टाको समयसीमा पूरा गर्न सक्नुहुन्न।

धारा ३३ GDPR अन्तर्गत, नियन्त्रकले व्यक्तिगत डेटा उल्लङ्घनको बारेमा थाहा पाएको ७२ घण्टा भित्र पर्यवेक्षक अधिकारीलाई सूचित गर्नुपर्छ, जबसम्म उल्लंघनले जोखिम प्रस्तुत गर्ने सम्भावना हुँदैन। नेदरल्याण्ड्समा त्यो अधिकार डच डेटा संरक्षण प्राधिकरण (Autoriteit Persoonsgegevens) हो। जहाँ जोखिम उच्च छ, नियन्त्रकले सम्बन्धित व्यक्तिहरूलाई पनि सूचित गर्नुपर्छ (धारा ३४ GDPR)। प्रोसेसरले अनावश्यक ढिलाइ बिना नियन्त्रकलाई सूचित गर्नुपर्छ। यदि तपाईंले ढिलो सुन्नुभयो भने तपाईंले आफ्नो समयसीमा पूरा गर्न सक्नुहुन्न भने, सम्झौतामा छोटो निश्चित अवधि भित्र सूचना आवश्यक पर्दछ र सम्पर्क बिन्दुको नाम दिनुपर्छ। यसले प्रदायकलाई अनुसन्धानमा सहयोग गर्न र लग र प्रमाण आपूर्ति गर्न पनि बाध्य पार्नुपर्छ। उप-प्रोसेसरहरू र अन्तर्राष्ट्रिय स्थानान्तरणहरूलाई समान व्यवहार चाहिन्छ, डेटा युरोपेली आर्थिक क्षेत्र छोड्ने ठाउँमा स्थानान्तरण संयन्त्र पहिचान गरिन्छ।

कुन साइबर सुरक्षा र क्षेत्र नियमहरूले सम्झौतालाई असर गर्छ?

डेटा सुरक्षा अब एक मात्र नियामक तह रहेन। डच साइबरसुरक्षा ऐन, डिजिटल सञ्चालन लचिलोपन सम्बन्धी EU नियमहरू र AI ऐन सबै प्रदायकमा सिधै पुग्न सक्छन्।

डच साइबरसुरक्षा ऐनले के चाहिन्छ?

१५ अगस्ट २०२६ देखि, यसको दायरा भित्रका संस्थाहरूले दर्ता गर्नुपर्छ, आफ्नो साइबर जोखिम व्यवस्थापन गर्नुपर्छ र महत्त्वपूर्ण घटनाहरू छिटो रिपोर्ट गर्नुपर्छ। व्यवस्थित सेवा प्रदायकहरू आफ्नै अधिकारमा दायरा भित्र पर्छन्।

डच साइबरसुरक्षा ऐन (Cyberbeveiligingswet) ले दोस्रो EU नेटवर्क र सूचना सुरक्षा निर्देशन (NIS2) लागू गर्दछ र १५ अगस्ट २०२६ देखि लागू भएको छ। यसको दायरा भित्रका संस्थाहरूले सक्षम पर्यवेक्षक अधिकारीसँग दर्ता गर्नुपर्छ, उपयुक्त जोखिम व्यवस्थापन उपायहरू लिनुपर्छ र महत्त्वपूर्ण घटनाहरू रिपोर्ट गर्नुपर्छ। रिपोर्टिङ समयरेखा NIS2 लाई पछ्याउँछ: २४ घण्टा भित्र प्रारम्भिक चेतावनी, ७२ घण्टा भित्र घटना सूचना र एक महिना भित्र अन्तिम रिपोर्ट। व्यवस्थित सेवा प्रदायकहरू र व्यवस्थित सुरक्षा सेवा प्रदायकहरू आफ्नै अधिकारमा समेटिएका छन्। दायरामा रहेका ग्राहकहरूले आफ्नो आपूर्ति श्रृंखला व्यवस्थित गरिएको देखाउन सक्षम हुनुपर्छ। सम्झौताको सर्तहरूमा, प्रदायकले तपाईंको आफ्नै रिपोर्टिङ समयसीमालाई समर्थन गर्नुपर्छ, जुन सामान्य घटना खण्डले अनुमति दिने भन्दा धेरै छोटो हुन्छ। डच साइबरसुरक्षा ऐन र यसको आवश्यकतामा हाम्रो गाइडले कसलाई समेटिएको छ भनेर सेट गर्दछ।

यदि तपाईं वित्तीय क्षेत्रमा हुनुहुन्छ भने के हुन्छ?

त्यसपछि EU डिजिटल अपरेशनल रेजिलेन्स एक्ट (DORA) ले सम्झौताको सामग्री तोक्छ। मानक IT सेवा सम्झौताले यसलाई पूरा गर्दैन।

DORA ले १७ जनवरी २०२५ देखि आवेदन दिएको छ। धारा ३० ले ICT सेवा प्रदायकहरूसँगको व्यवस्थाको लागि सम्झौता प्रावधानहरू तोकेको छ, जसमा सेवा विवरण, प्रशोधन स्थान, पहुँच, निरीक्षण र लेखा परीक्षण अधिकार, निकास रणनीति र समाप्ति अधिकारहरू समावेश छन्। वित्तीय ग्राहकहरूलाई सेवा दिने प्रदायकले ती सर्तहरूको लागि सोधिने अपेक्षा गर्नुपर्छ।

यदि एआई सेवाको हिस्सा हो भने के हुन्छ?

EU AI ऐनले मूल्य शृङ्खलामा भूमिका अनुसार दायित्वहरू बाँडफाँड गर्दछ। सम्झौतामा कसले कुन दायित्व वहन गर्छ भनेर उल्लेख गर्नुपर्छ।

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

प्रदायकले आफ्नो दायित्व कति हदसम्म सीमित गर्न सक्छ?

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

दायित्वको सीमा भनेको व्यावसायिक र कानुनी भेटघाट हो। प्रदायक सर्तहरूले सामान्यतया छोटो अवधिमा तिरेको शुल्कमा दायित्व सीमित गर्दछ र परिणामस्वरूप हुने नोक्सान, नाफा नोक्सान र डेटाको नोक्सानलाई समावेश गर्दैन। तिनीहरूले छोटो अवधिहरू पनि सेट गर्छन् जस भित्र दावी सूचित गर्नुपर्छ। ग्राहकहरूले सामान्यतया सीमा माथि वार्ता गर्छन्, प्रायः बाह्र महिना भन्दा बढीको शुल्कमा। तिनीहरूले सीमित छोड्न नसक्ने कोटीहरू पनि बनाउँछन्: गोपनीयताको उल्लङ्घन, तेस्रो-पक्ष बौद्धिक सम्पत्तिको उल्लङ्घन, र डेटा सुरक्षा उल्लङ्घनबाट उत्पन्न हुने दायित्व।

डच कानूनले यी खण्डहरूमा बाहिरी सीमाहरू तोक्छ। धारा ६:२४८(२) BW अन्तर्गत, कुनै पक्षले सम्झौता अवधिमा भर पर्न सक्दैन जहाँ त्यो व्यावहारिकता र निष्पक्षताको मापदण्डद्वारा अस्वीकार्य हुनेछ। अदालतहरूले बहिष्करण खण्डलाई पक्षलाई उसको आफ्नै मनसाय वा सचेत लापरवाही (bewuste roekeloosheid को opzet), र सामान्यतया यसको वरिष्ठ व्यवस्थापनको विरुद्धमा जोगाउन निरन्तर अस्वीकार गर्छन्। उल्लङ्घनको गम्भीरता, क्षतिको प्रकृति, बीमा स्थिति र सापेक्षिक मोलमोलाई शक्ति सबैले भूमिका खेल्छन्। सम्झौता मूल्य र संलग्न जोखिमसँग देखिने सम्बन्ध बोकेको सीमा कम्बल बहिष्करण भन्दा धेरै कायम रहने सम्भावना हुन्छ।

दाबी गर्नु अघि तपाईंले के गर्नुपर्छ?

धेरैजसो अवस्थामा तपाईंले पहिले प्रदायकलाई लिखित रूपमा डिफल्टमा राख्नु पर्छ। तपाईंले सम्झौता वा कानूनले तोकेको अवधि भित्र उजुरी पनि गर्नुपर्छ।

पहिलो चरण भनेको डिफल्टको सूचना (इन्जेब्रेकेस्टेलिङ) हो। जहाँ कार्यसम्पादन अझै पनि सम्भव छ, तपाईंले क्षतिपूर्ति दाबी गर्न वा रद्द गर्न सक्नु अघि सामान्यतया लिखित सूचना दिनुपर्छ जसमा कार्यसम्पादन गर्न उचित अवधि हुन्छ (लेख ६:८२ र ६:८३ BW)। यदि निश्चित समयसीमा बितिसकेको छ वा कार्यसम्पादन असम्भव भएको छ भने त्यो आवश्यक पर्दैन। रिसाएको इमेल डिफल्टको सूचना होइन। दोस्रो चरण भनेको उजुरी अवधि हो। धारा ६:८९ BW अन्तर्गत, तपाईंले दोष पत्ता लगाएपछि उचित समय भित्र उजुरी गर्नुपर्छ, र प्रदायक सर्तहरूले सामान्यतया त्यो अवधिलाई छोटो पार्छ। समस्या पत्ता लगाउने, महिनौंसम्म यसको वरिपरि काम गर्ने र त्यसपछि मात्र गुनासो गर्ने ग्राहकले आफ्नो दाबीलाई प्रतिबन्धित पाउन सक्छ।

फोर्स मेजर खण्डले के समेट्छ?

प्रदायकको तर्फबाट यसमा के समावेश छ भनेर पढ्नुहोस्। उप-ठेकेदार र होस्टिंग साझेदारहरूको असफलताहरू प्रायः सूचीबद्ध हुन्छन्, जसले प्रदायकको आफ्नै आपूर्ति श्रृंखला जोखिमलाई तपाईंमा सार्छ।

उप-ठेकेदारहरू, होस्टिंग साझेदारहरू र टेलिकम आपूर्तिकर्ताहरूको असफलतालाई प्रायः फोर्स मेज्योरको रूपमा परिभाषित गरिन्छ। यसले प्रदायकको आफ्नै आपूर्ति श्रृंखलाको जोखिम तपाईंलाई हस्तान्तरण गर्दछ। यो बिन्दु वार्तालाप योग्य छ। व्यवस्थित सेवा सम्झौतामा यो प्रायः सबैभन्दा महत्त्वपूर्ण हुन्छ, किनकि तपाईंले त्यो श्रृंखला व्यवस्थापन गर्न प्रदायकलाई ठीकसँग भुक्तानी गर्दै हुनुहुन्छ।

सम्झौताले मानिसहरूको बारेमा के भन्नुपर्छ?

यसले प्रमुख कर्मचारीहरू, उप-ठेक्का, फ्रीलान्सरहरूको स्थिति र गैर-अनुरोधलाई समेट्नु पर्छ। IT सेवाहरू मानिसहरूद्वारा प्रदान गरिन्छ, र यी प्रत्येक बुँदाले पछि समस्या निम्त्याउन सक्छ।

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

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

के फ्रीलान्सरहरू साँच्चै स्वरोजगार छन्?

यो प्रश्न तब उठ्छ जब व्यक्तिहरू तपाईंको परिसरमा, तपाईंको निर्देशनमा, लामो समयसम्म काम गर्छन्। यदि तिनीहरूले कर्मचारी जस्तै काम गर्छन् भने, पुनर्वर्गीकरणको वास्तविक जोखिम हुन्छ।

डच कर प्रशासन (बेलास्टिङडिएन्स्ट) ले १ जनवरी २०२५ मा काम गर्ने सम्बन्धको वर्गीकरणमा पूर्ण कार्यान्वयन पुनः सुरु गर्‍यो। नाममात्र फ्रीलान्सरहरूले कर्मचारीहरू जस्तै काम गर्ने निर्माणले अब पुनर्वर्गीकरणको वास्तविक जोखिम बोक्छ, जसमा उनीहरूले काम गर्ने पक्षको लागि तलब कर परिणामहरू हुन्छन्। त्यसकारण सेवाहरूको लागि सम्झौताहरूले तपाईंलाई रोजगारदाताले जस्तै व्यक्तिहरूलाई निर्देशन दिने अधिकार दिने शब्दहरूबाट बच्नु पर्छ। दुवै पक्षले काम वास्तवमा कसरी गरिन्छ भनेर हेर्नुपर्छ, बीजकमा रहेको लेबलमा होइन।

बिन्ती नगर्ने र घरमै सेवा लिने बारे के हुन्छ?

सीमित गैर-अनुरोध खण्ड मानक हो। कुनै सेवालाई घरमै फिर्ता लिँदा, वा टोलीसँग सार्दा, कुनै उपक्रमको हस्तान्तरणमा डच नियमहरू ट्रिगर हुन सक्छन्।

सम्झौता समाप्त भएपछि प्रत्येक पक्षलाई एक निश्चित अवधिको लागि अर्को पक्षको कर्मचारी भर्ना गर्नबाट रोक्ने एउटा धारा मानक हो र सामान्यतया व्यवसायहरू बीच लागू हुन्छ, यदि यो समय र दायरामा सीमित छ भने। जहाँ तपाईं घरमै सेवा फिर्ता लिनुहुन्छ, वा यसलाई प्रदर्शन गर्ने टोलीसँग अर्को प्रदायकमा सार्नुहुन्छ, त्यहाँ उपक्रमको स्थानान्तरण सम्बन्धी नियमहरू (overgang van onderneming, लेख 7:662 र निम्न BW) लागू हुन सक्छन्। त्यसपछि कर्मचारीहरू तिनीहरूको अवस्थित नियम र सर्तहरूमा स्थानान्तरण हुन्छन्। त्यो परिणामले प्रायः पक्षहरूलाई आश्चर्यचकित गर्छ, त्यसैले संक्रमण सहमत हुनु अघि यसको विश्लेषण गर्नुहोस्, पछि होइन।

अवधि, समाप्ति र बहिर्गमनले कसरी काम गर्छ?

सुरुवाती अवधि, स्वचालित नवीकरण र सूचना अवधि जाँच गर्नुहोस्, र विस्तृत बहिर्गमन खण्डमा सहमति जनाउनुहोस्। बहिर्गमन खण्डले वास्तवमा छोड्दा कति खर्च लाग्छ भनेर निर्णय गर्छ।

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

बाहिर निस्कने बाटो के के छन्?

त्यहाँ तीन छन्: सुविधाको लागि समाप्ति, कारणको लागि समाप्ति र डच कानून अन्तर्गत उल्लङ्घनको लागि खारेजी। प्रत्येकको आफ्नै सर्तहरू छन्।

• सुविधाको लागि समाप्तिले कुनै पनि पक्षलाई, वा प्रायः ग्राहकलाई मात्र, कारण नदिई सूचना दिएर सम्झौता समाप्त गर्न दिन्छ। प्रदायकहरूले प्रायः यसलाई त्याग्छन्; यो जोड दिन लायक छ।
• कारणको लागि समाप्तिले निश्चित अवधि भित्र समाधान नगरिएको परिभाषित भौतिक उल्लङ्घनको लागि तुरुन्त समाप्तिलाई अनुमति दिन्छ। ट्रिगरहरूमा बारम्बार सेवा स्तर विफलताहरू समावेश हुनुपर्छ, केवल विनाशकारी घटनाहरू मात्र होइन।
• माथि वर्णन गरिएको पूर्वनिर्धारित सूचनाको अधीनमा रही, अनुबंधले यसलाई बहिष्कार नगरेसम्म, धारा ६:२६५ BW अन्तर्गत उल्लङ्घन (अनबाइन्डिङ) को लागि खारेजी सम्झौता मार्गहरूसँगै उपलब्ध रहन्छ।

निकास खण्डमा के समावेश हुनुपर्छ?

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

एक व्यावहारिक निकास खण्डले प्रदायकलाई समाप्ति पछिको निश्चित अवधिको लागि र सहमत दरहरूमा बाध्य पार्छ:

• सेवा जारी राख्नुहोस्;
• तपाईंको डेटालाई दस्तावेजीकृत र प्रयोगयोग्य ढाँचामा फिर्ता गर्नुहोस्;
• कागजात र कन्फिगरेसन विवरणहरू प्रदान गर्नुहोस्;
• उत्तराधिकारी प्रदायकसँग सहकार्य गर्नुहोस्;
• सम्भव भएसम्म तेस्रो-पक्ष इजाजतपत्रहरू स्थानान्तरण वा तोक्ने;
• तपाईंको डेटाको बाँकी प्रतिलिपिहरू मेटाउनुहोस् र यसलाई लिखित रूपमा पुष्टि गर्नुहोस्।

ती दायित्वहरू बिना तपाईं कागजमा छोड्न स्वतन्त्र हुन सक्नुहुन्छ र व्यवहारमा छोड्न असमर्थ हुन सक्नुहुन्छ।

यदि प्रदायक दिवालिया भयो भने के हुन्छ?

एक ट्रस्टी (क्युरेटर) ले कार्यभार सम्हाल्छन् र काम गरिरहन बाध्य हुँदैनन्। त्यसपछि तपाईंको उपचार दिवालियापन सम्पत्तिमा दावी हुनेछ, जुन सामान्यतया थोरै मूल्यको हुन्छ।

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

ग्राहकको रूपमा तपाईंले के जाँच गर्नुपर्छ?

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

प्रदायकको रूपमा तपाईंले के जाँच गर्नुपर्छ?

• सम्झौतामा प्रत्येक डेलिभरीको लागि तपाईंले उत्कृष्ट प्रयास गर्नुपर्छ वा परिणाम दिनुपर्छ भनी उल्लेख छ कि छैन जाँच गर्नुहोस्।
• तपाईंको दायित्व सीमा अनुबंध मूल्यसँग दृश्यात्मक सम्बन्ध राख्छ कि राख्छ भनेर जाँच गर्नुहोस्, ताकि यो धारा ६:२४८(२) BW अन्तर्गत कायम रहन्छ।
• तपाईंको प्रोसेसर सम्झौता धारा २८ GDPR अन्तर्गत तपाईंले वास्तवमा गर्ने प्रशोधनसँग मेल खान्छ कि खाँदैन जाँच गर्नुहोस्।
• तपाईं व्यवस्थित सेवा प्रदायकको रूपमा साइबर सुरक्षा ऐन अन्तर्गत पर्नुहुन्छ कि पर्दैन र २४-घण्टा प्रारम्भिक चेतावनीको समयसीमा पूरा गर्न सक्नुहुन्छ कि भनेर जाँच गर्नुहोस्।
• तपाईंका उप-ठेकेदारहरू उही सुरक्षा र गोपनीयता सर्तहरूद्वारा बाध्य छन् भनी जाँच गर्नुहोस्।

IT सेवा सम्झौताको साथ हामी तपाईंको लागि के गर्न सक्छौं?

हाम्रा IT वकिलहरूले ग्राहक र प्रदायक दुवैलाई प्रविधि सम्झौता र परियोजना असफल हुँदा उत्पन्न हुने विवादहरूमा सल्लाह दिन्छन्।

• हामी फ्रेमवर्क सम्झौता, SLA, प्रोसेसर सम्झौता र सामान्य सर्तहरूको समीक्षा गर्छौं, र प्राथमिकताको क्रम सेट गर्छौं।
• हामी अर्को पक्षसँग दायित्व सीमा, काटछाँट र विशेष उपचार शब्दावली वार्ता गर्छौं।
• हामी IP खण्ड, असाइनमेन्टको डिड र आवश्यक परेमा, स्रोत कोड एस्क्रो व्यवस्थाको मस्यौदा तयार गर्छौं।
• प्रदायकले काम गर्न नसकेको खण्डमा हामी धारा ६:८२ र ६:८३ BW अन्तर्गत पूर्वनिर्धारित सूचनाको मस्यौदा तयार गर्छौं।
• हामी समाप्ति अघि एक्जिट योजना तयार गर्छौं, त्यसैले नयाँ प्रदायकमा संक्रमणलाई समेटिन्छ।

सारांश

• IT सेवा सम्झौता सामान्यतया सेवाहरूको लागि एक सम्झौता हो (धारा ७:४०० BW र निम्न); यसलाई परिणामको दायित्व बनाउनुहोस् जहाँ तपाईं निश्चित मिति द्वारा परिभाषित परिणाम खरिद गर्दै हुनुहुन्छ।
• कार्यहरूमा क्षेत्र परिभाषित गर्नुहोस्, स्वीकृति प्रक्रिया र परिवर्तन प्रक्रियामा सहमति जनाउनुहोस्, र कागजातहरू बीचको प्राथमिकताको क्रम बताउनुहोस्।
• सेवा क्रेडिटहरू विशेष उपाय हुन् कि होइनन् र लगातार असफलताले तपाईंलाई समाप्त गर्ने अधिकार दिन्छ कि दिँदैनन् भनेर जाँच गर्नुहोस्।
• बेस्पोक सफ्टवेयरमा प्रतिलिपि अधिकार तपाईंलाई लिखित सम्झौता र कागजात (धारा २(३) Auteurswet) मार्फत मात्र हस्तान्तरण हुन्छ; भुक्तानी मात्र पर्याप्त छैन।
• GDPR-अनुरूप प्रोसेसर सम्झौता, सान्दर्भिक भएसम्म साइबर सुरक्षा ऐन प्रतिबिम्बित गर्ने धाराहरू, र विस्तृत निकास धारामा सहमति जनाउनुहोस्।

बारम्बार सोधिने प्रश्नहरू