डच कायद्यानुसार सॉफ्टवेअर एस्क्रो

जर तुमचा व्यवसाय तुम्ही न लिहिलेल्या सॉफ्टवेअरवर अवलंबून असेल, तर तुम्ही ते बनवणाऱ्या कंपनीवर अवलंबून असता. तुमच्याकडे ऑब्जेक्ट कोड आणि परवाना असतो; तर पुरवठादाराकडे सोर्स कोड, बिल्ड पाइपलाइन आणि ज्ञान असते. जोपर्यंत पुरवठादार आर्थिकदृष्ट्या सक्षम आणि कार्यक्षम असतो, तोपर्यंत ही विषमता सहन करण्यायोग्य असते, आणि ज्या क्षणी तो तसा राहत नाही, त्या क्षणी ती तशी राहत नाही. सॉफ्टवेअर एस्क्रो हे एक प्रमाणित उत्तर आहे, परंतु ते केवळ डच दिवाळखोरी कायद्याचा विचार करून तयार केले असेल तरच प्रभावी ठरते — आणि बहुतेक व्यवस्था तशा नसतात.

एस्क्रो म्हणजे काय आणि त्यामुळे कोणत्या जोखमीचे निराकरण होते

पुरवठादार सोर्स कोड आणि सहाय्यक साहित्य एका स्वतंत्र तृतीय पक्षाकडे जमा करतो, जो एक निश्चित घटना घटेपर्यंत ते स्वतःकडे ठेवतो आणि नंतर ग्राहकाला परत करतो. ग्राहक सॉफ्टवेअर चालू ठेवण्यासाठी त्या कोडचा वापर आणि त्यात बदल करू शकतो. धोका मालकीचा नसून सातत्याचा आहे: जो ग्राहक एका पुरवठादाराच्या उत्पादनावर आपली ऑर्डर प्रोसेसिंग, रुग्णांच्या नोंदी किंवा उत्पादन नियोजन चालवत आहे, तो रातोरात दुसऱ्या पुरवठादाराकडे जाऊ शकत नाही, कारण स्थलांतराला अनेक महिने लागतात आणि त्यासाठी सहसा दुसऱ्या पुरवठादाराच्या मदतीची आवश्यकता असते. एस्क्रोमुळे व्यवस्थितपणे बाहेर पडण्यासाठी वेळ मिळतो. तीन परिस्थिती महत्त्वाच्या आहेत:

• दिवाळखोरी. पुरवठादाराला दिवाळखोर घोषित केले जाते, विश्वस्ताची नियुक्ती केली जाते, कर्मचारी नोकरी सोडतात आणि मिळणारी मदत थांबते. एस्क्रोची ही परिस्थिती लिहिलेली असते आणि यातच डच कायदा सर्वाधिक लागू होतो.
• बंद करणे. पुरवठादार उत्पादन मागे घेतो, तुमची आवृत्ती बंद करतो, किंवा तुमच्या उपयोजनामध्ये स्वारस्य नसलेल्या व्यक्तीद्वारे त्याचे अधिग्रहण केले जाते. दिवाळखोरीपेक्षा हे अधिक सामान्य आहे, आणि अनेकदा हे विमोचन कलमातून वगळले जाते.
• देखभाल करण्यात सतत अपयश. पुरवठादार अजूनही अस्तित्वात आहे आणि बिले पाठवतो, पण तो आता दोष दुरुस्त करत नाही, सुरक्षा पॅचेस पाठवत नाही किंवा उत्पादनाला त्याच्या अवलंबित्व घटकांशी सुसंगत ठेवत नाही.

द्विपक्षीय आणि त्रिपक्षीय व्यवस्था

द्विपक्षीय व्यवस्था म्हणजे मुख्य करारातील एक वचन असते की, एखादी निश्चित घटना घडल्यास पुरवठादार सोर्स कोड सुपूर्द करेल. ही व्यवस्था सोपी आणि कमकुवत असते: कोणतीही रक्कम जमा झाली आहे किंवा अद्ययावत ठेवली गेली आहे, हे कोणीही स्वतंत्रपणे तपासत नाही, आणि सर्वात महत्त्वाचे म्हणजे, दिवाळखोरीच्या परिस्थितीत तुम्ही विश्वस्ताला मालमत्तेचे असे दायित्व पार पाडण्यास सांगत असता, जे करण्यास तो बांधील नसतो.

त्रिपक्षीय व्यवस्थेमध्ये एस्क्रो एजंटला एक करार करणारा पक्ष म्हणून समाविष्ट केले जाते. एजंट मालमत्तेचा ताबा घेतो, ठेव तपासतो, ती स्वतःकडे ठेवतो आणि ती रक्कम मुक्त करण्याची थेट जबाबदारी तुमच्यावर असते. एजंटला पैसे देण्याचे हेच मुख्य कारण आहे: रक्कम मुक्त करणे हे दिवाळखोर मालमत्तेद्वारे नव्हे, तर एका सक्षम तृतीय पक्षाद्वारे त्याच्या स्वतःच्या कराराअंतर्गत केलेले कार्य ठरते. रक्कम मुक्त करण्याची घटना घडली आहे की नाही, हे ठरवण्याचा अधिकार एजंटकडे असतो, ज्यामुळे तुम्हाला मदत करण्याची कोणतीही प्रेरणा नसलेल्या विश्वस्ताचा अधिकार काढून घेतला जातो.

प्रत्यक्षात काय जमा केले जाते

सर्वात सामान्य त्रुटी कायदेशीर नसते. ती एक अशी ठेव असते ज्यात फक्त सोर्स कोड असतो आणि बाकी काहीही नसते. केवळ सोर्स कोड कंपाइल होत नाही: बिल्ड करण्याच्या सूचना आणि डिपेंडन्सीची यादी न देता डेव्हलपरला दिल्यास, एका मोठ्या कोडबेसमधून चालू होणारी बायनरी तयार होण्यासाठी रिव्हर्स इंजिनिअरिंगला अनेक आठवडे लागू शकतात — आणि जेव्हा सिस्टम आधीच असमर्थित (unsupported) असते, तेव्हा तुमच्याकडे इतका वेळ नसतो. बिल्ड करण्याच्या सूचनांशिवाय ठेवलेली ठेव निरुपयोगी असते.

अद्ययावत करण्याचे बंधन घाला. सहीच्या वेळी एकदा जमा केलेली ठेव एक किंवा दोन विमोचन चक्रांमध्ये कालबाह्य होईल. ठेवींना विमोचन वेळापत्रकाशी जोडा — प्रत्येक प्रमुख विमोचनासोबत, किंवा एका निश्चित अंतराने — आणि विलंब झाल्यास कळवण्याचा हक्क काढून घ्या.

पडताळणी: तुम्ही कशासाठी पैसे देत आहात

खालील मधला पर्याय मानक म्हणून खरेदी करा, आणि संपूर्ण चाचणी घ्या जिथे सेवा खंडित झाल्यास अस्तित्वाचा प्रश्न निर्माण होईल. केवळ फाईल-स्तरावरील तपासणी करणे म्हणजे जवळजवळ काहीच खरेदी न करण्यासारखे आहे.

• फाईल-स्तरावरील तपासणी. एजंट पुष्टी करतो की जमा केलेली माहिती वाचण्यायोग्य, व्हायरसमुक्त आहे आणि फाईल सूचीशी जुळते. यातून काहीतरी पोहोचले आहे हे सिद्ध होते, ते काम करते हे नाही.
• पूर्णता आणि दस्तऐवज पुनरावलोकन. एजंट डिपॉझिटच्या आधारे बिल्ड सूचना आणि डिपेंडन्सी तपासतो आणि त्रुटींची नोंद करतो. हा मधला पर्याय बहुतेक ग्राहकांसाठी योग्य आहे: तो संपूर्ण चाचणीच्या खर्चाच्या तुलनेत खूपच कमी खर्चात सामान्य चुका शोधून काढतो — जसे की, गहाळ बिल्ड स्टेप्स, डॉक्युमेंट नसलेल्या डिपेंडन्सी, किंवा असा घटक जो वापरण्याचा तुम्हाला अधिकार नाही.
• संपूर्ण बिल्ड आणि रन चाचणी. एजंट स्वच्छ वातावरणात डिपॉझिट संकलित करतो आणि चाचणी डेटावर त्याची चाचणी घेतो. डिपॉझिट कार्य करते हे सिद्ध करणारी ही एकमेव पातळी आहे, परंतु सॉफ्टवेअर बदलत असल्यामुळे ही प्रक्रिया अधिक संथ, महागडी आणि पुनरावृत्तीची आवश्यकता असणारी आहे.

प्रकाशन कार्यक्रम, ज्यांची रचना अशा प्रकारे केली आहे की त्यावर वाद घालता येणार नाही.

मुक्तता कलम हे एक असे उद्दीपक आहे, जे एस्क्रो एजंटने दबावाखाली आणि कायदेशीर सल्ल्याशिवाय लागू केले पाहिजे. प्रत्येक घटना ही पुरवठादाराच्या वर्तनाबद्दलच्या निर्णयावरून नव्हे, तर एखाद्या दस्तऐवजावरून किंवा कालावधी उलटल्यावर सिद्ध करता आली पाहिजे.

दोन मुद्दे बहुतांश काम करतात. विरोधाचा भार पुरवठादारावर टाका: ग्राहक पुराव्यासह एजंटला सूचित करतो, पुरवठादाराला आक्षेप घेण्यासाठी एक छोटा निश्चित कालावधी मिळतो आणि आक्षेप न घेतल्यास एजंट जबाबदारीतून मुक्त होतो. आणि विवादाचा मार्ग आगाऊ निश्चित करा — तज्ज्ञांकडून निर्णय किंवा कमी कालावधीत लवाद — जेणेकरून आक्षेप घेतल्यास महिन्यांऐवजी काही दिवसांची सवलत मिळेल.

डच दिवाळखोरीचा प्रश्न

वरील सर्व कराराची रचना आहे. पुरवठादार दिवाळखोर झाल्यावर ती लागू होते की नाही, हे पुढील बाबींवरून ठरते.

विश्वस्त काय नाकारू शकतो

कलम ३७ एफडब्ल्यू अंतर्गत, जिथे दिवाळखोरीच्या आदेशाच्या वेळी दोन्हीपैकी कोणत्याही पक्षाकडून परस्पर कराराची पूर्णपणे पूर्तता झालेली नसते, तिथे प्रतिपक्षी विश्वस्ताला तो कराराची पूर्तता करेल की नाही हे जाहीर करण्यासाठी एक वाजवी लेखी मुदत देऊ शकतो; जर त्याने तसे केले नाही, तर तो बदल्यात पूर्ततेची मागणी करण्याचा हक्क गमावतो. कलम ३७ एफडब्ल्यू जे करत नाही ते म्हणजे, ते करार संपुष्टात आणत नाही किंवा विश्वस्ताला तो संपुष्टात आणण्याचा अधिकार देत नाही. करार अस्तित्वात राहतो; विश्वस्त केवळ पूर्तता करण्यास बांधील नसतो, आणि प्रतिपक्षीकडे कलम ३७ए एफडब्ल्यू अंतर्गत दिवाळखोरीमध्ये दावा करण्याचा हक्क शिल्लक राहतो.

सॉफ्टवेअरच्या बाबतीत याचा अर्थ असा की, विश्वस्त देखभाल, साहाय्य, अद्यतने, होस्टिंग आणि पुढील ठेवी नाकारू शकतो: या अशा सक्रिय सेवा आहेत ज्यांमुळे मालमत्तेला खर्च येतो. नकार मिळण्याची अपेक्षा ठेवा. प्रश्न हा आहे की, विश्वस्त आणखी पुढे जाऊन, तुमच्याकडे आधीपासून असलेल्या गोष्टी वापरण्यापासून तुम्हाला थांबवू शकतो का.

नेबुला, बर्झोना आणि क्रेडिट सुईस/जोंगेपियर

दशकभर ही बाब खरोखरच अनिश्चित होती. नेबुला प्रकरणात (Hoge Raad, 3 November 2006, ECLI:NL:HR:2006:AX8838) सर्वोच्च न्यायालयाने असा निर्णय दिला की, जरी दिवाळखोरीमुळे विद्यमान करार स्वतःहून संपुष्टात येत नसले तरी, वापराचा हक्क असलेला प्रतिपक्ष, जणू काही दिवाळखोरी झालीच नाही अशा प्रकारे विश्वस्ताविरुद्ध तो हक्क वापरणे सुरू ठेवू शकत नाही; कारण तसे केल्यास एका धनकोला इतरांच्या नुकसानीवर दिवाळखोरीकडे दुर्लक्ष करण्याची मुभा मिळाली असती. याचा व्यापक अर्थ असा लावला गेला की, विश्वस्ताला पूर्वीपासून अस्तित्वात असलेला वापराचा हक्क रद्द करण्याची परवानगी मिळत आहे, आणि त्यामुळे परवानाधारकांमध्ये भीतीचे वातावरण निर्माण झाले.

तो अर्थ टिकला नाही. एबीएन ॲम्रो/बेर्झोना (Hoge Raad, 11 July 2014, ECLI:NL:HR:2014:1681) प्रकरणात सर्वोच्च न्यायालयाने असे ठरवले की दिवाळखोरीचा विद्यमान परस्पर करारांवर किंवा त्यातून उद्भवणाऱ्या जबाबदाऱ्यांवर कोणताही परिणाम होत नाही, आणि ती विश्वस्ताला असा कोणताही अधिकार देत नाही जो कायदा किंवा करार त्याला देत नाही — उदाहरणार्थ, तो चालू असलेला भाडेकरार रद्द करू शकत नाही.

क्रेडिट सुईस/जोंगेपियर क्यूक्यू (होगे राड, २३ मार्च २०१८, ECLI:NL:HR:2018:424) मध्ये या प्रकरणाचा निपटारा झाला . विश्वस्त निष्क्रियपणे कार्य करण्यास नकार देऊ शकतो, परंतु दिवाळखोरीमुळे त्याला कर्जदाराने दिवाळखोरीपूर्वी केलेले कार्य रद्द करण्याचा, किंवा एखाद्या गोष्टीला सहन करणे किंवा त्यापासून परावृत्त होणे या स्वरूपाचे चालू असलेले कार्य समाप्त करण्याचा अधिकार मिळत नाही.

सॉफ्टवेअरच्या बाबतीत तो वाक्यांश महत्त्वाचा आहे. परवाना म्हणजे मूलतः हक्कधारकाने, अन्यथा कॉपीराइटचे उल्लंघन करणाऱ्या वापरास सहन करण्याचे दिलेले वचन असते — ही सहनशीलतेची एक निरंतर पूर्तता असते. त्यामुळे, सध्याच्या कायद्यानुसार, दिवाळखोरीपूर्वी वैधपणे दिलेला परवाना दिवाळखोरीनंतरही वैध राहतो आणि विश्वस्त तो रद्द करू शकत नाही. विश्वस्त सर्व सक्रिय गोष्टी नाकारू शकतो, परंतु तुमच्याकडे असलेला वापराचा हक्क बंद करू शकत नाही.

तुमच्या व्यवस्थेसाठी याचा काय अर्थ होतो

यातून दोन गोष्टी निष्पन्न होतात. सुटकेचे दायित्व पुरवठादारावर नव्हे, तर एस्क्रो एजंटवर ठेवावे: तिसऱ्या पक्षाकडे स्वतंत्र अभिरक्षा म्हणून स्थापित केल्यास, ही सुटका एजंटची स्वतःची कामगिरी असते, आणि कलम ३७ एफडब्ल्यू अंतर्गत विश्वस्ताचा अधिकार हा सक्षम एजंटऐवजी इस्टेटीकडून अपेक्षित असलेल्या कामगिरीवर लागू होतो, याउलट द्विपक्षीय वचनामध्ये इस्टेटीकडून कामगिरीची आवश्यकता असते, जी विश्वस्त नाकारू शकतो. आणि सुटकेच्या वेळी नव्हे, तर परवाना सुरुवातीलाच द्यावा — हा मसुद्यातील सर्वात महत्त्वाचा मुद्दा आहे, ज्यावर खाली चर्चा केली आहे.

दिवाळखोरीऐवजी पुनर्रचनेच्या प्रक्रियेत, कलम ३७३ एफडब्ल्यू हे 'इप्सो फॅक्टो' कलमांवरील अवलंबनावर निर्बंध घालते — म्हणजेच, केवळ पुनर्रचना प्रक्रिया सुरू झाली आहे म्हणून प्रतिपक्षाला करारामध्ये सुधारणा करण्याची, तो स्थगित करण्याची किंवा संपुष्टात आणण्याची परवानगी देणाऱ्या तरतुदी. हा निर्बंध योजना प्रक्रियेत लागू होतो, दिवाळखोरीत नाही, आणि त्याचे उत्तर पुन्हा संरचनात्मक आहे: जेव्हा व्यवस्था तिसऱ्या पक्षाद्वारे स्वतंत्र अभिरक्षा म्हणून तयार केली जाते, तेव्हा मुक्तता ट्रिगर एजंटच्या स्वतःच्या दायित्वावर लागू होतो आणि दिवाळखोरीप्रमाणेच डब्ल्यूएचओए (WHOA) पुनर्रचनेतही, ती बाजूला ठेवता येण्याजोगी 'इप्सो फॅक्टो' तरतूद ठरत नाही.

परवान्याची रचना कशी असावी

एस्क्रो तुम्हाला सोर्स कोडची एक प्रत देतो, त्यावर काहीही करण्याचा अधिकार नाही. सोर्स कोड हे एक संरक्षित कार्य आहे; ते कंपाइल करणे, त्यात बदल करणे आणि त्याचा परिणाम चालवणे या प्रतिबंधित कृती आहेत. या कृतींना लागू होणाऱ्या परवान्याशिवाय, मुक्त केलेली ठेव ही एक अशी फाईल आहे जी तुम्ही उघडू शकत नाही. एस्क्रोसोबत असा परवाना जोडा जो ग्राहकाला, कोड मुक्त झाल्यावर, सोर्स कोड वापरण्याची, कंपाइल करण्याची, त्यात बदल करण्याची आणि तो पुढे विकसित करण्याची, तसेच हे काम तिसऱ्या पक्षाकडून करून घेण्याची स्पष्टपणे परवानगी देईल — प्रत्यक्षात, तुम्हाला स्वतः ते काम करावे लागणार नाही.

मग वेळेचा प्रश्न येतो. सुटकेच्या वेळी दिलेला परवाना नाजूक असतो. जर सुटकेची घटना स्वतः दिवाळखोरी असेल, तर परवाना अशा कर्जदाराने मंजूर करणे आवश्यक आहे, ज्याने दिवाळखोरीच्या आदेशाच्या दिवसापासून मालमत्तेची विल्हेवाट लावण्याचा अधिकार गमावला आहे; कलम २३ एफडब्ल्यू आणि कलम ३५ एफडब्ल्यू आड येतात, आणि विश्वस्त तुमच्यासाठी परवाना मंजूर करणार नाही. क्रेडिट सुईस/जोंगेपियर प्रकरणानुसार, तुमच्याकडे आधीपासून असलेला परवाना विश्वस्त रद्द करू शकत नाही — पण जर तुमच्याकडे कधी परवाना असेलच, तर रद्द करण्यासारखे काहीच नाही.

दिवाळखोरी होण्यापूर्वीच, करारातच एका पूर्व-अटीच्या अधीन राहून तो हक्क प्रदान करावा: तो आता प्रदान केलेला असावा आणि एका विमोचन घटनेवर (release event) तो अंमलात यावा. हा हक्क कराराच्या तारखेपासून अस्तित्वात असतो; फक्त त्याची अंमलबजावणी पुढे ढकलली जाते. डच कायदा सामान्यतः या रचनेला अनुकूल आहे. राबोबँक/रियुसर (Rabobank/Reuser) प्रकरणात (Hoge Raad, 3 June 2016, ECLI:NL:HR:2016:1046) सर्वोच्च न्यायालयाने हे मान्य केले की, जिथे दिवाळखोरीपूर्वी एक सशर्त हक्क निर्माण केला गेला होता, तिथे नंतर कर्जदाराच्या कोणत्याही पुढील कृतीशिवाय त्या अटीची पूर्तता अंमलात येते. ते प्रकरण वस्तूंच्या सशर्त हस्तांतरणाशी आणि सशर्त हक्कावरील तारणाशी संबंधित होते. सशर्त प्रदान केलेल्या कॉपीराइट परवान्याला हे लागू करणे, हा न्यायालयांनी निश्चित केलेला मुद्दा नसून, कायदेशीर साहित्यातून समर्थित एक विस्तार आहे आणि तो तसाच मांडला गेला पाहिजे.

याचीही पुष्टी करा की जारी केलेल्या सामग्रीच्या वापरासाठी पुरवठादार किंवा त्याच्या विश्वस्तांच्या पुढील संमतीची आवश्यकता नाही आणि उत्तराधिकारी विकासकाला उप-परवाना देण्याची परवानगी आहे.

SaaS आणि क्लाउड: केवळ सोर्स कोड पुरेसा नाही

तुम्ही स्वतः चालवत असलेल्या सॉफ्टवेअरसाठी, सोर्स कोड, बिल्ड करण्याच्या सूचना आणि परवाना हे जवळजवळ एक संपूर्ण उत्तर आहे. सेवेच्या बाबतीत मात्र तसे नाही. जर पुरवठादाराचा प्लॅटफॉर्म बंद पडला, तर तुम्ही ॲप्लिकेशन, ते ज्या वातावरणात चालत होते ते आणि तुमचा डेटा गमावून बसता — आणि सोर्स कोड फक्त पहिली गोष्ट हळूहळू परत मिळवून देतो. SaaS सातत्य व्यवस्थेमध्ये तीन गोष्टींचा समावेश असणे आवश्यक आहे:

• कार्यप्रणालीचे वातावरण. कंटेनर इमेजेस, इन्फ्रास्ट्रक्चर-ॲज-कोड डेफिनिशन्स, कॉन्फिगरेशन, नेटवर्क आणि सुरक्षा सेटिंग्ज, रनटाइम डिपेंडन्सीज — इतरत्र प्लॅटफॉर्म उभा करण्यासाठी पुरेसे आहे.
• डेटा. तुमच्या स्वतःच्या डेटाची, दस्तऐवजीकृत, गैर-मालकी हक्काच्या स्वरूपात आणि स्कीमासह नियमित निर्यात. जो डेटा तुम्ही वाचू शकत नाही, तो तुमचा डेटा नाही, आणि ही निर्यात केवळ रिलीजच्या वेळीच नव्हे, तर संपूर्ण कराराच्या कालावधीत चालू राहिली पाहिजे.
• यजमान संबंध. पुरवठादाराच्या होस्टिंग प्रोव्हायडरसोबतच्या करारामध्ये प्रवेश करण्याचा एक मार्ग, किंवा त्या प्रोव्हायडरला सूचना देणे की तुम्ही खाते ताब्यात घेऊन थेट पैसे देऊ शकता.

पर्याय, आणि पैसे कोण देणार

एस्क्रो नेहमीच सर्वोत्तम पर्याय नसतो, विशेषतः मानक उत्पादनांसाठी, जिथे तुम्ही हजारो ग्राहकांपैकी एक असता आणि अपयशाऐवजी सेवा बंद पडण्याचा खरा धोका असतो. तीन सोपे पर्याय अनेकदा अधिक उपयुक्त ठरतात: डेटा एक्झिट राईट — दस्तऐवजीकृत स्वरूपात ठराविक कालावधीने निर्यात करणे, ज्याची किमान एकदा चाचणी केलेली असते — ज्यामुळे जवळजवळ कोणत्याही खर्चाशिवाय बहुतेक धोका कमी होतो; रनिंग कॉपीचा अधिकार , एक डिप्लॉय करण्यायोग्य इमेज जी तुम्ही संक्रमणकालीन कालावधीसाठी चालवू शकता, ज्यामुळे पुनर्बांधणीपेक्षा खूप वेगाने सेवा पूर्ववत होते; आणि होस्टिंग प्रोव्हायडरला थेट पेमेंट करणे , ज्यामुळे तुम्ही स्थलांतर करत असताना वातावरण चालू राहते — हा क्लाउड सातत्य राखण्याचा सर्वात स्वस्त मार्ग आहे, आणि ज्याकडे बहुतेकदा दुर्लक्ष केले जाते.

जेव्हा तुम्ही एस्क्रोचा वापर करता, तेव्हा एक-वेळचे सेट-अप शुल्क, नियमित वार्षिक कस्टडी शुल्क आणि तपासणीच्या खोलीनुसार प्रत्येक पडताळणीसाठी स्वतंत्र शुल्क आकारले जाईल अशी अपेक्षा ठेवा. हा खर्च ज्याला संरक्षण हवे आहे त्याच्यावर असतो, जो सामान्यतः ग्राहक असतो. तथापि, एस्क्रोला विक्रीचा एक मुद्दा म्हणून सादर करणारा पुरवठादार ते देऊ शकतो आणि एकाच उत्पादनाच्या अनेक ग्राहकांना समाविष्ट करणारी बहु-लाभार्थी व्यवस्था हा खर्च विभागून देते — आणि हीच ती सामान्य स्थिती आहे जिथे पुरवठादार विरोध करतो. पैसे न भरल्यास एजंटने तुम्हाला सूचित करणे बंधनकारक करा आणि त्याऐवजी पैसे भरण्याचा हक्क त्याला द्या.

एस्क्रो व्यवस्थेच्या वाटाघाटी करण्यासाठीची तपासणी सूची

• हा एक खरा त्रिपक्षीय करार आहे का, ज्यामध्ये एका स्वतंत्र एजंटवर तुमची थेट जबाबदारी आहे?
• सोर्स कोड वापरण्याचा, संकलित करण्याचा, सुधारित करण्याचा आणि पुढे विकसित करण्याचा परवाना मंजूर करण्यात आला आहे का? आताप्रकाशनाच्या वेळी वचन दिल्याऐवजी, पूर्व-अटीच्या अधीन राहून?
• डिपॉझिट लिस्टमध्ये केवळ सोर्स कोडच नाही, तर प्रत्येक रिलीजसोबत अपडेट होणारे बिल्ड इन्स्ट्रक्शन्स, डिपेंडन्सीज, लायसन्स कीज आणि डॉक्युमेंटेशन यांचाही समावेश असतो का?
• कोणत्या पडताळणी स्तराचे कंत्राट दिले आहे, आणि त्याची किती वेळा पुनरावृत्ती केली जाते?
• एखाद्या दस्तऐवजावरून किंवा कालावधी उलटल्यावर प्रकाशन घटना निश्चित करता येतात का, ज्यामध्ये आक्षेप नोंदवण्यासाठी कमी कालावधी आणि जलद विवाद निवारण मार्ग उपलब्ध आहे?
• SaaS साठी: यामध्ये पर्यावरण, डेटा आणि होस्टिंग संबंध यांचा समावेश आहे, की फक्त कोडचा?
• पैसे कोण देणार, पुरवठादाराने पैसे देणे थांबवल्यास काय होईल, आणि एस्क्रो करार मुख्य करारातील नियामक कायदा व बौद्धिक संपदा कलमांशी सुसंगत आहे का?