डच कानून अन्तर्गत सफ्टवेयर एस्क्रो

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

एस्क्रो के हो र यसले सम्बोधन गर्ने जोखिम

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

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

दुई-पक्षीय र तीन-पक्षीय व्यवस्था

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

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

वास्तवमा के जम्मा गरिएको छ

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

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

प्रमाणीकरण: तपाईंले के तिर्दै हुनुहुन्छ

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

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

घटनाहरू जारी गर्नुहोस्, ताकि तिनीहरूको बारेमा बहस गर्न नसकिने गरी मस्यौदा गरिएको होस्

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

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

डच दिवालियापन प्रश्न

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

ट्रस्टीले के अस्वीकार गर्न सक्छ

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

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

नेबुला, बर्जोना र क्रेडिट सुइस/जोन्जपियर

एक दशकसम्म यो साँच्चै अनिश्चित थियो। नेबुलामा (होज राड, ३ नोभेम्बर २००६, ECLI:NL:HR:2006:AX8838) सर्वोच्च अदालतले दिवालियापनले आफैंमा अवस्थित सम्झौताहरू समाप्त नगरे पनि, प्रयोगको अधिकार भएको प्रतिपक्षले दिवालियापन भएको छैन जस्तो गरी ट्रस्टी विरुद्ध यसलाई प्रयोग गर्न जारी राख्न सक्दैन भन्ने ठहर गर्‍यो; यसले एक ऋणदातालाई अरूको खर्चमा दिवालियापनलाई बेवास्ता गर्न दिनेछ। यो व्यापक रूपमा ट्रस्टीलाई पहिले नै अवस्थित प्रयोगको अधिकारलाई अलग राख्न दिने रूपमा पढिएको थियो, र यसले इजाजतपत्र प्राप्तहरूलाई सतर्क गर्‍यो।

त्यो पढाइ जीवित रहेन। ABN AMRO/Berzona (Hoge Raad, ११ जुलाई २०१४, ECLI:NL:HR:२०१४:१६८१) मा सर्वोच्च अदालतले दिवालियापनले विद्यमान पारस्परिक सम्झौताहरू वा तिनीहरूबाट उत्पन्न हुने दायित्वहरूमा कुनै प्रभाव पार्दैन भन्ने ठहर गर्‍यो, र ट्रस्टीलाई कानून वा सम्झौताले नदिएको कुनै शक्ति दिँदैन - उदाहरणका लागि, यसले अझै पनि चलिरहेको पट्टा समाप्त गर्न सक्दैन।

यो स्थिति क्रेडिट सुइस/जोन्गेपियर qq (होज राड, २३ मार्च २०१८, ECLI:NL:HR:२०१८:४२४) मा तय गरिएको थियो। ट्रस्टीले निष्क्रिय रूपमा कार्यसम्पादन गर्न अस्वीकार गर्न सक्छ, तर दिवालियापनले यसलाई दिवालियापन अघि ऋणीले प्रदान गरेको कार्यसम्पादनलाई पूर्ववत गर्ने, न त कुनै कुरालाई सहन वा त्याग्ने गरी निरन्तर कार्यसम्पादन समाप्त गर्ने शक्ति दिन्छ।

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

तपाईंको व्यवस्थाको लागि यसको अर्थ के हो?

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

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

इजाजतपत्र कसरी संरचित हुनुपर्छ

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

त्यसपछि समय। रिहाइमा दिइएको इजाजतपत्र कमजोर हुन्छ। यदि रिहाइ घटना दिवालियापन नै हो भने, अनुदान एक ऋणी द्वारा बनाइनु पर्छ जसले, दिवालियापन आदेशको दिनदेखि, सम्पत्तिमा सम्पत्तिको निपटान गर्ने शक्ति गुमाएको छ; धारा २३ Fw र धारा ३५ Fw बाटोमा खडा हुन्छ, र ट्रस्टीले तपाईंको लागि अनुदान दिनेछैन। क्रेडिट सुइस/जोन्गेपियरको अर्थ ट्रस्टीले तपाईंसँग पहिले नै भएको इजाजतपत्र रद्द गर्न सक्दैन - तर यदि तपाईंसँग कहिल्यै थिएन भने रद्द गर्न केही छैन।

कुनै पनि दिवालियापन हुनुभन्दा पहिले, एउटा सर्तको पूर्ववर्तीको अधीनमा, सम्झौतामा नै यसलाई प्रदान गर्नुहोस्: अहिले प्रदान गरिएको, रिलीज घटनामा लागू हुने। अधिकार सम्झौताको मितिदेखि नै अवस्थित छ; केवल यसको प्रभाव स्थगित हुन्छ। डच कानून सामान्यतया यस संरचनालाई ग्रहणशील छ। Rabobank/Reuser मा (Hoge Raad, 3 जुन 2016, ECLI:NL:HR:2016:1046) सर्वोच्च अदालतले स्वीकार गर्‍यो कि दिवालियापन हुनुभन्दा पहिले जहाँ सशर्त अधिकार सिर्जना गरिएको थियो, त्यहाँ पछि शर्तको पूर्ति ऋणीद्वारा कुनै थप कार्य बिना नै प्रभावकारी भयो। त्यो मुद्दा सामानको सशर्त स्थानान्तरण र सशर्त अधिकारमाथि प्रतिज्ञासँग सम्बन्धित थियो। सशर्त रूपमा प्रदान गरिएको प्रतिलिपि अधिकार इजाजतपत्रमा यसलाई लागू गर्नु अदालतले तय गरेको बिन्दुको सट्टा कानुनी साहित्यमा समर्थित एक्स्ट्रापोलेसन हो, र यसलाई त्यस्तै रूपमा प्रस्तुत गरिनुपर्छ।

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

SaaS र क्लाउड: स्रोत कोड पर्याप्त छैन

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

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

विकल्पहरू, र कसले भुक्तानी गर्छ

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

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

एस्क्रो व्यवस्थाको लागि वार्ताको लागि चेकलिस्ट

• के यो स्वतन्त्र एजेन्टसँगको वास्तविक तीन-पक्षीय सम्झौता हो जसको लागि तपाईंलाई प्रत्यक्ष रिहाई दायित्व पर्छ?
• के दिइएको स्रोत कोड प्रयोग, संकलन, परिमार्जन र थप विकास गर्ने इजाजतपत्र हो? अब, रिहाइको वाचा गर्नुको सट्टा पूर्वसर्तको अधीनमा?
• के निक्षेप सूचीमा प्रत्येक रिलीजमा अद्यावधिक गरिएको स्रोत कोड मात्र नभई निर्माण निर्देशनहरू, निर्भरताहरू, इजाजतपत्र कुञ्जीहरू र कागजातहरू समावेश छन्?
• कुन प्रमाणीकरण स्तर अनुबंधित छ, र यो कति पटक दोहोर्याइन्छ?
• के रिलीज घटनाहरू कागजातबाट निर्धारण गर्न सकिन्छ वा समय बितेको कारणले, छोटो आपत्ति अवधि र छिटो विवाद मार्गको साथ?
• SaaS को लागि: वातावरण, डेटा र होस्टिंग सम्बन्ध समेटिएको छ, वा केवल कोड?
• कसले भुक्तानी गर्छ, आपूर्तिकर्ताले भुक्तानी गर्न बन्द गरेमा के हुन्छ, र के एस्क्रो सम्झौता मुख्य सम्झौताको शासित कानून र बौद्धिक सम्पत्ति खण्डहरूसँग मेल खान्छ?