သင့်လုပ်ငန်းက သင်မရေးခဲ့တဲ့ software ပေါ်မှာ မှီခိုနေရရင်၊ အဲဒီ software ကုမ္ပဏီကိုပဲ မှီခိုနေရမှာပါ။ သင်က object code နဲ့ license ကို ကိုင်ဆောင်ထားပြီး၊ supplier က source code၊ build pipeline နဲ့ knowledge တွေကို ကိုင်ဆောင်ထားပါတယ်။ အဲဒီ asymmetry ကို သည်းခံနိုင်ပေမယ့် supplier က solvency နဲ့ competent ဖြစ်ပြီး၊ solvency မရှိတဲ့ အချိန်မှာ ဒီလိုမဖြစ်တော့ပါဘူး။ Software escrow က စံအဖြေဖြစ်ပေမယ့် Dutch insolvency law ကို ထည့်သွင်းစဉ်းစားပြီး ရေးဆွဲမှသာ အလုပ်လုပ်ပါတယ် - ပြီးတော့ အစီအစဉ်အများစုက မလုပ်ဆောင်ပါဘူး။
Escrow ဆိုတာဘာလဲ၊ ဘယ်လိုအန္တရာယ်တွေကို ကိုင်တွယ်ဖြေရှင်းပေးသလဲ
ပေးသွင်းသူသည် source code နှင့် အထောက်အကူပြုပစ္စည်းများကို လွတ်လပ်သော ပြင်ပအဖွဲ့အစည်းတစ်ခုထံ အပ်နှံပြီး သတ်မှတ်ထားသော အဖြစ်အပျက်တစ်ခု မဖြစ်ပွားမချင်း သိမ်းဆည်းထားပြီးနောက် ဖောက်သည်ထံ ထုတ်ပေးပြီး ဆော့ဖ်ဝဲကို ဆက်လက်လည်ပတ်နေစေရန် ကုဒ်ကို အသုံးပြုပြီး ပြုပြင်မွမ်းမံနိုင်သည်။ အန္တရာယ်မှာ ပိုင်ဆိုင်မှုမဟုတ်ဘဲ စဉ်ဆက်မပြတ်ဖြစ်ခြင်းဖြစ်သည်- ပေးသွင်းသူတစ်ဦး၏ ထုတ်ကုန်တွင် မှာယူမှုလုပ်ဆောင်ခြင်း၊ လူနာမှတ်တမ်းများ သို့မဟုတ် ထုတ်လုပ်မှုစီမံကိန်းကို လုပ်ဆောင်နေသော ဖောက်သည်တစ်ဦးသည် တစ်ညတည်းဖြင့် ပြောင်းလဲ၍မရပါ၊ အဘယ်ကြောင့်ဆိုသော် ရွှေ့ပြောင်းခြင်းသည် လပေါင်းများစွာကြာပြီး ပုံမှန်အားဖြင့် ထွက်သွားသော ပေးသွင်းသူ၏ အကူအညီကို လိုအပ်သောကြောင့်ဖြစ်သည်။ Escrow သည် စနစ်တကျထွက်ခွာရန် အချိန်ကို ဝယ်ယူသည်။ အခြေအနေသုံးခုသည် အရေးကြီးသည်-
- ပြိုလဲမှု။ ပေးသွင်းသူ ဒေဝါလီခံကြောင်း ကြေငြာခံရပြီး၊ භාရမှူးတစ်ဦးကို ခန့်အပ်ပြီး၊ ဝန်ထမ်းများ ထွက်ခွာသွားကာ ပံ့ပိုးမှုများ ရပ်တန့်သွားသည်။ အခြေအနေ escrow ကို ရေးသားထားပြီး၊ ဒတ်ချ်ဥပဒေက အလုပ်အများဆုံးလုပ်ဆောင်သည့်နေရာဖြစ်သည်။
- ရပ်ဆိုင်းခြင်း။ ပေးသွင်းသူသည် ထုတ်ကုန်ကို ရုပ်သိမ်းခြင်း၊ သင့်ဗားရှင်းကို ရပ်ဆိုင်းခြင်း သို့မဟုတ် သင့်ဖြန့်ကျက်မှုတွင် စိတ်မဝင်စားသူတစ်ဦးက ဝယ်ယူခြင်းခံရသည်။ ဒေဝါလီခံခြင်းထက် ပို၍အဖြစ်များပြီး ရုပ်သိမ်းခြင်းအပိုဒ်တွင် မကြာခဏ ချန်လှပ်ထားလေ့ရှိသည်။
- ထိန်းသိမ်းရန် အဆက်မပြတ်ပျက်ကွက်ခြင်း။ ပေးသွင်းသူသည် ရှိနေဆဲဖြစ်ပြီး ငွေတောင်းခံလွှာများကို ဆက်လက်ပေးပို့နေသော်လည်း ချို့ယွင်းချက်များကို ပြင်ဆင်ခြင်း၊ လုံခြုံရေးပြင်ဆင်မှုများ ပေးပို့ခြင်း သို့မဟုတ် ထုတ်ကုန်ကို ၎င်း၏ မှီခိုမှုများနှင့် တွဲဖက်အသုံးပြုနိုင်အောင် ထားရှိခြင်း မရှိတော့ပါ။
နှစ်ပါတီနှင့် သုံးပါတီ သဘောတူညီချက်များ
နှစ်ဖက် သဘောတူစာချုပ်ဆိုသည်မှာ သတ်မှတ်ထားသောဖြစ်ရပ်တစ်ခုဖြစ်ပေါ်လာပါက ပေးသွင်းသူက source code ကို လွှဲပြောင်းပေးမည်ဟူသော အဓိကစာချုပ်တွင် ကတိပြုချက်တစ်ခုဖြစ်သည်။ ၎င်းသည် ဈေးသက်သာပြီး အားနည်းသည်- မည်သည့်အရာကိုမျှ အပ်နှံထားခြင်း သို့မဟုတ် လက်ရှိအခြေအနေအတိုင်းထားရှိခြင်း ရှိမရှိကို မည်သူမျှ လွတ်လပ်စွာစစ်ဆေးခြင်းမရှိပါ၊ ထို့အပြင် — ပြတ်ပြတ်သားသားပြောရလျှင် — ဒေဝါလီခံခြင်းတွင် သင်သည် භාရမှူးအား အမွေဆက်ခံသူအဖြစ် လုပ်ဆောင်ရန် တောင်းဆိုနေခြင်းဖြစ်သည်။ ၎င်းလုပ်ဆောင်ရန် တာဝန်မရှိပါ။
သုံး ပွင့်ဆိုင် သဘောတူညီချက်တွင် escrow agent တစ်ခုကို စာချုပ်ချုပ်ဆိုသူအဖြစ် ထည့်သွင်းထားသည်။ agent သည် ထိန်းသိမ်းစောင့်ရှောက်ခြင်းကို လက်ခံပြီး၊ အပ်ငွေကို စစ်ဆေးပြီး၊ သိမ်းဆည်းထားပြီး၊ ၎င်းကို ပြန်လွှတ်ပေးရန် သင့်အား တိုက်ရိုက်တာဝန်ပေးအပ်ထားသည်။ ၎င်းသည် တစ်ခုအတွက် ပေးချေရမည့် အကြောင်းရင်းတစ်ခုလုံးဖြစ်သည်- ပြန်လွှတ်ပေးခြင်းသည် ဒေဝါလီခံပိုင်ဆိုင်မှုမှ မဟုတ်ဘဲ ၎င်း၏ကိုယ်ပိုင်စာချုပ်အရ ငွေပေးချေနိုင်သော တတိယပါတီမှ ဆောင်ရွက်ခြင်းဖြစ်လာသည်။ agent သည် ပြန်လွှတ်ပေးသည့်ဖြစ်ရပ်တစ်ခု ဖြစ်ပွားခဲ့ခြင်း ရှိ၊ မရှိကိုလည်း ဆုံးဖြတ်ပြီး သင့်အား ကူညီရန် လှုံ့ဆော်မှုမရှိဘဲ භාရမှူးထံမှ ၎င်းကို ဖယ်ရှားသည်။
တကယ်အပ်နှံထားတာတွေက
အဖြစ်အများဆုံးပျက်ကွက်မှုဟာ တရားဝင်မဟုတ်ပါဘူး။ ဒါဟာ source code ပါဝင်ပြီး တခြားဘာမှမပါဝင်တဲ့ deposit တစ်ခုပါ။ source code တစ်ခုတည်းနဲ့ compile မလုပ်နိုင်ပါဘူး။ build instructions နဲ့ dependency list မရှိဘဲ developer ထံ ပေးအပ်ထားတဲ့ codebase ကြီးတစ်ခုဟာ reverse engineering လုပ်ဖို့ ရက်သတ္တပတ်ပေါင်းများစွာ ကြာနိုင်ပါတယ်။ system က support မလုပ်ရသေးတဲ့အချိန်မှာ မရှိတဲ့ အချိန်ပါ။ build instructions မပါဘဲ deposit လုပ်တာက အသုံးမဝင်ပါဘူး။
| component | အဘယ်ကြောင့်လိုအပ်သနည်း |
|---|---|
| source code၊ အပြည့်အစုံနှင့် ဗားရှင်းသတ်မှတ်ထားသည် | ဖွံ့ဖြိုးတိုးတက်ရေးဌာနခွဲနှင့် မဟုတ်ဘဲ အမှန်တကယ် ထုတ်လုပ်မှုတွင် ထုတ်ဝေမှုနှင့် ကိုက်ညီရမည်။ |
| တည်ဆောက်ခြင်းနှင့် ဖြန့်ကျက်ခြင်းဆိုင်ရာ ညွှန်ကြားချက်များ | compiler နှင့် runtime ဗားရှင်းများ၊ build script များ၊ environment variable များ၊ deployment အဆင့်များ။ ၎င်းတို့မရှိလျှင် code သည် အလုပ်လုပ်သော software ဖြစ်မလာပါ။ |
| နည်းပညာနှင့် လုပ်ဆောင်ချက်ဆိုင်ရာ စာရွက်စာတမ်းများ | ဗိသုကာ၊ ဒေတာမော်ဒယ်၊ အင်တာဖေ့စ်များ၊ သိရှိထားသော ချို့ယွင်းချက်များ။ ပြင်ပအဖွဲ့အစည်းတစ်ခုက ကုဒ်ကို ထိန်းသိမ်းနိုင်သည် သို့မဟုတ် ၎င်းကိုသာ လုပ်ဆောင်နိုင်သည်ကို ဆုံးဖြတ်သည်။ |
| ပြင်ပနှင့် open source အစိတ်အပိုင်းများ | ဗားရှင်းများနှင့် လိုင်စင်စည်းကမ်းချက်များပါရှိသော မှီခိုမှုစာရင်း။ အချို့သော စီးပွားဖြစ် အစိတ်အပိုင်းများသည် ၎င်းတို့၏ ပေးသွင်းသူထံမှ သီးခြားလိုင်စင် လိုအပ်ပါသည်။ |
| လိုင်စင်သော့များ၊ လက်မှတ်များ၊ အထောက်အထားများ | လိုင်စင်သက်တမ်းကုန်ဆုံးသွားသော server သို့ ဖုန်းခေါ်ဆိုသည့် software သည် continuity မဟုတ်ပါ။ |
အပ်ဒိတ်လုပ်ရန် တာဝန်တစ်ခုထည့်ပါ။ လက်မှတ်ထိုးချိန်တွင် တစ်ကြိမ်ပြုလုပ်သော ငွေသွင်းခြင်းသည် ထုတ်ပေးသည့် စက်ဝန်းတစ်ခု သို့မဟုတ် နှစ်ခုအတွင်း သက်တမ်းကုန်ဆုံးသွားပါသည်။ ငွေသွင်းခြင်းသည် ထုတ်ပေးသည့်အချိန်ဇယား — အဓိကထုတ်ပြန်မှုတိုင်း သို့မဟုတ် ပုံသေကြားကာလ — နှင့် ချိတ်ဆက်ပြီး နောက်ကျသည့်အခါ အသိပေးခံရရန် အခွင့်အရေးကို ရယူပါ။
အတည်ပြုခြင်း- သင်ပေးချေနေသည့်အရာ
အောက်က အလယ်အလတ်ရွေးချယ်မှုကို စံအဖြစ်ဝယ်ယူပြီး ပြတ်တောက်မှုတစ်ခုဖြစ်နိုင်သည့် အပြည့်အဝစမ်းသပ်မှုကို ဝယ်ယူပါ။ ဖိုင်အဆင့်စစ်ဆေးမှုတစ်ခုတည်းသည် ဘာမှမဝယ်ခြင်းနှင့် နီးစပ်ပါသည်။
- ဖိုင်အဆင့်စစ်ဆေးမှု။ အေးဂျင့်က ငွေသွင်းခြင်းသည် ဖတ်ရှုနိုင်ပြီး ဗိုင်းရပ်စ်ကင်းစင်ကြောင်းနှင့် ဖိုင်စာရင်းနှင့် ကိုက်ညီကြောင်း အတည်ပြုပါသည်။ ၎င်းသည် တစ်စုံတစ်ခု ရောက်ရှိပြီဖြစ်ကြောင်း သက်သေပြသော်လည်း ၎င်းသည် အလုပ်ဖြစ်ကြောင်း သက်သေပြပါသည်။
- ပြည့်စုံမှုနှင့် စာရွက်စာတမ်းများ ပြန်လည်သုံးသပ်ခြင်း။ agent က build instructions တွေနဲ့ dependencies တွေကို deposit နဲ့ တိုက်ဆိုင်စစ်ဆေးပြီး gap တွေကို report လုပ်ပါတယ်။ ဒီအလယ်အလတ် option က customer အများစုအတွက် သင့်တော်ပါတယ်- build steps တွေ ပျောက်ဆုံးနေတာ၊ documented မရှိတဲ့ dependencies တွေ၊ အသုံးပြုခွင့်မရှိတဲ့ component တွေကို full test ရဲ့ ကုန်ကျစရိတ်ရဲ့ အစိတ်အပိုင်းအနည်းငယ်နဲ့ ဖမ်းယူပေးပါတယ်။
- အပြည့်အဝတည်ဆောက်ပြီး စမ်းသပ်လည်ပတ်ခြင်း။ အေးဂျင့်သည် အပ်ငွေကို သန့်ရှင်းသောပတ်ဝန်းကျင်တွင် စုစည်းပြီး စမ်းသပ်ဒေတာနှင့် နှိုင်းယှဉ်လုပ်ဆောင်သည်။ အပ်ငွေအလုပ်လုပ်ကြောင်း သက်သေပြသည့် တစ်ခုတည်းသောအဆင့်ဖြစ်သော်လည်း ဆော့ဖ်ဝဲလ်ပြောင်းလဲသွားသည်နှင့်အမျှ ပိုနှေး၊ ပိုစျေးကြီးပြီး ထပ်ခါတလဲလဲလုပ်ဆောင်ရန် လိုအပ်ပါသည်။
ထုတ်ပြန်ပွဲများ၊ အငြင်းပွားဖွယ်ရာမရှိစေရန် ရေးဆွဲထားသည်
လွှတ်ပေးရေးအချက်သည် escrow အေးဂျင့်သည် ဖိအားအောက်တွင်နှင့် ဥပဒေအကြံဉာဏ်မပါဘဲ အသုံးချရမည့် အစပျိုးမှုတစ်ခုဖြစ်သည်။ ဖြစ်ရပ်တိုင်းကို ပေးသွင်းသူ၏ အပြုအမူနှင့်ပတ်သက်သော ဆုံးဖြတ်ချက်မှ မဟုတ်ဘဲ စာရွက်စာတမ်း သို့မဟုတ် အချိန်ကာလမှ အတည်ပြုနိုင်သင့်သည်။
| ထုတ်ဝေမှုပွဲ | ၎င်းကို အရာဝတ္ထုတစ်ခုအနေဖြင့် ဆုံးဖြတ်နိုင်စေရန် မည်သို့ပြုလုပ်ရမည်နည်း |
|---|---|
| ပေးသွင်းသူ၏ ဒေဝါလီခံခြင်း | တရားရုံး၏ စီရင်ချက် သို့မဟုတ် ဒေဝါလီခံမှု မှတ်ပုံတင်မှတ်တမ်း။ |
| ငွေပေးချေမှုများကို ရပ်ဆိုင်းထားခြင်း သို့မဟုတ် ပြန်လည်ဖွဲ့စည်းခြင်း လုပ်ထုံးလုပ်နည်း | မှတ်ပုံတင်မှတ်တမ်းအရ အုပ်ချုပ်ရေးမှူး သို့မဟုတ် ပြန်လည်ဖွဲ့စည်းရေးကျွမ်းကျင်သူ ခန့်အပ်ခြင်း။ |
| လုပ်ငန်းဖျက်သိမ်းခြင်း သို့မဟုတ် ရပ်ဆိုင်းခြင်း | ကုန်သွယ်ရေးမှတ်ပုံတင်မှ မှတ်ပုံတင်ခြင်းကို ပယ်ဖျက်ခြင်း သို့မဟုတ် ဖျက်သိမ်းရန် ဆုံးဖြတ်ချက်။ |
| ထုတ်ကုန် သို့မဟုတ် အသုံးပြုနေသော ဗားရှင်းကို ရပ်ဆိုင်းခြင်း | သက်တမ်းကုန်ဆုံးကြောင်း ရေးသားထားသော အကြောင်းကြားစာ သို့မဟုတ် ပေးသွင်းသူက ထုတ်ပြန်ချက်များ ရပ်ဆိုင်းပြီးနောက် သတ်မှတ်ထားသော ကာလ ကုန်ဆုံးခြင်း။ |
| ထိန်းသိမ်းရန် အဆက်မပြတ်ပျက်ကွက်ခြင်း | အကြောင်းကြားစာနှင့် ကုသချိန်ပြီးနောက် စာချုပ်ဆိုင်ရာ တုံ့ပြန်မှုအချိန်အတွင်း သတ်မှတ်ထားသော ပြင်းထန်မှုချို့ယွင်းချက်ကို ပြုပြင်ရန် ပျက်ကွက်ခြင်း၊ သတ်မှတ်ထားသော ဝင်းဒိုးတစ်ခုအတွင်း သတ်မှတ်ထားသော အကြိမ်အရေအတွက်အတိုင်း ထပ်ခါတလဲလဲ ပြုလုပ်ခြင်း။ |
| ဆော့ဖ်ဝဲကို ပြင်ပအဖွဲ့အစည်းတစ်ခုသို့ လွှဲပြောင်းပေးခြင်း | သတ်မှတ်ထားသောကာလအတွင်း ဝယ်ယူသူမှ ပြုပြင်ထိန်းသိမ်းမှုတာဝန်ဝတ္တရားများကို ရေးသားယူဆခြင်း မရှိပါ။ |
အချက်နှစ်ချက်က အလုပ်အများစုကို လုပ်ဆောင်ပေးပါတယ်။ ဆန့်ကျင်ဘက်ဝန်ထုပ်ဝန်ပိုးကို ပေးသွင်းသူအပေါ် ထားပါ- ဖောက်သည်က သက်သေအထောက်အထားတွေနဲ့ အေးဂျင့်ကို အကြောင်းကြားပြီး၊ ပေးသွင်းသူမှာ ကန့်ကွက်ဖို့ အချိန်တိုတိုနဲ့ ရှိပြီး၊ ကန့်ကွက်မှုမရှိရင် အေးဂျင့်က ထုတ်ပြန်ပါတယ်။ ပြီးတော့ အငြင်းပွားမှုလမ်းကြောင်းကို ကြိုတင်ပြင်ဆင်ပါ - ကျွမ်းကျင်သူရဲ့ ဆုံးဖြတ်ချက် ဒါမှမဟုတ် အချိန်တိုတိုနဲ့ ခုံသမာဓိနဲ့ ဆုံးဖြတ်ပါ - ဒါကြောင့် ကန့်ကွက်မှုက လပေါင်းများစွာမဟုတ်ဘဲ ရက်ပေါင်းများစွာကို ဝယ်ယူနိုင်ပါတယ်။
နယ်သာလန် ဒေဝါလီခံမှုပြဿနာ
အထက်ဖော်ပြပါအရာအားလုံးသည် စာချုပ်ဒီဇိုင်းဖြစ်သည်။ နောက်ဆက်တွဲသည် ပေးသွင်းသူ ဒေဝါလီခံသည့်အခါ ၎င်းသည် တည်မြဲမတည်ကို ဆုံးဖြတ်ပေးသည်။
භාရမှူးက ငြင်းဆန်နိုင်တဲ့အရာတွေ
အပိုဒ် ၃၇ Fw အရ၊ ဒေဝါလီခံအမိန့်ချမှတ်ချိန်တွင် နှစ်ဖက်စလုံးမှ အပြန်အလှန်စာချုပ်ကို အပြည့်အဝ မလုပ်ဆောင်ပါက၊ အပြန်အလှန်အကျိုးတူဆောင်ရွက်သူသည် භාရမှူးအား လုပ်ဆောင်မည်၊ မလုပ်ဆောင်မည်ကို ကြေညာရန် ကျိုးကြောင်းဆီလျော်သော ရေးသားထားသောကာလကို သတ်မှတ်နိုင်သည်။ မလုပ်ဆောင်ပါက၊ ပြန်လည်လုပ်ဆောင်ရန် တောင်းဆိုခွင့် ဆုံးရှုံးသည်။ အပိုဒ် ၃၇ Fw မှ မ လုပ်ဆောင် သည်မှာ စာချုပ်ကို ရပ်စဲခြင်း သို့မဟုတ် භාရမှူးအား ရပ်စဲရန် အာဏာပေးခြင်း ဖြစ်သည်။ စာချုပ်သည် အကျုံးဝင်သည်။ භාရမှူးသည် လုပ်ဆောင်ရန် တာဝန်မရှိသည့်အပြင်၊ အပြန်အလှန်အကျိုးတူဆောင်ရွက်သူသည် အပိုဒ် ၃၇က Fw အရ ဒေဝါလီခံမှုတွင် တောင်းဆိုမှုတစ်ခု ကျန်ရစ်ခဲ့သည်။
ဆော့ဖ်ဝဲလ်အတွက် ဒါက භාရမှူးက ပြုပြင်ထိန်းသိမ်းမှု၊ ပံ့ပိုးမှု၊ အပ်ဒိတ်များ၊ လက်ခံကျင်းပမှုနှင့် နောက်ထပ်အပ်ငွေများကို ငြင်းပယ်နိုင်သည်- အိမ်ခြံမြေငွေကုန်ကျစေသည့် တက်ကြွသောစွမ်းဆောင်ရည်များ။ ငြင်းပယ်ခံရမည်ဟု မျှော်လင့်ပါ။ မေးခွန်းမှာ ၎င်းသည် ပိုမိုမြင့်မားသွားပြီး သင်ရှိပြီးသားကို အသုံးမပြုတော့အောင် တားဆီးနိုင်မလားဆိုသည့်အချက်ဖြစ်သည်။
Nebula၊ berzona နှင့် Credit Suisse/Jongepier
ဆယ်စုနှစ်တစ်ခုကြာအောင် ဒါဟာ အမှန်တကယ် မသေချာမရေရာမှုတစ်ခု ဖြစ်ခဲ့ပါတယ်။ Nebula (Hoge Raad၊ ၂၀၀၆ ခုနှစ်၊ နိုဝင်ဘာလ ၃ ရက်၊ ECLI:NL:HR:2006:AX8838) မှာ တရားရုံးချုပ်က ဒေဝါလီခံခြင်းဟာ လက်ရှိသဘောတူညီချက်တွေကို ရပ်စဲလိုက်တာမဟုတ်ပေမယ့်၊ အသုံးပြုခွင့်ရှိတဲ့ တစ်ဖက်သတ်အဖွဲ့အစည်းဟာ ဒေဝါလီမခံရသလို භාရမှူးကို ဆက်လက်ကျင့်သုံးလို့မရဘူးလို့ ဆုံးဖြတ်ခဲ့ပါတယ်။ အဲဒီလိုလုပ်ခြင်းအားဖြင့် ငွေချေးသူတစ်ဦးဟာ တခြားသူတွေရဲ့ ကုန်ကျစရိတ်နဲ့ ဒေဝါလီခံမှုကို လျစ်လျူရှုရာရောက်ပါတယ်။ ဒါကို භාရမှူးတစ်ဦးဟာ ကြိုတင်ရှိပြီးသား အသုံးပြုခွင့်ကို စွန့်လွှတ်လိုက်တယ်လို့ ကျယ်ကျယ်ပြန့်ပြန့် ဖတ်ရှုခဲ့ကြပြီး လိုင်စင်ရသူတွေကို ထိတ်လန့်စေခဲ့ပါတယ်။
အဲဒီဖတ်ရှုမှုဟာ အသက်မဝင်ခဲ့ပါဘူး။ ABN AMRO/Berzona (Hoge Raad၊ ၂၀၁၄ ခုနှစ်၊ ဇူလိုင်လ ၁၁ ရက်၊ ECLI:NL:HR:2014:1681) မှာ တရားရုံးချုပ်က ဒေဝါလီခံခြင်းဟာ လက်ရှိ အပြန်အလှန်သဘောတူညီချက်တွေ ဒါမှမဟုတ် အဲဒီကနေ ပေါ်ပေါက်လာတဲ့ တာဝန်ဝတ္တရားတွေအပေါ် သက်ရောက်မှုမရှိဘူးလို့ ဆုံးဖြတ်ခဲ့ပြီး ဥပဒေ ဒါမှမဟုတ် စာချုပ်က မပေးတဲ့ အာဏာကို භාရမှူးကို မပေးဘူးလို့ ဆုံးဖြတ်ခဲ့ပါတယ်။ ဥပမာအားဖြင့်၊ ဆက်လက်လည်ပတ်နေတဲ့ ငှားရမ်းမှုကို ရပ်စဲလို့မရပါဘူး။
ရာထူးကို Credit Suisse/Jongepier qq (Hoge Raad၊ ၂၀၁၈ ခုနှစ် မတ်လ ၂၃ ရက်၊ ECLI:NL:HR:2018:424) တွင် အခြေချခဲ့သည်။ භාရမှူးသည် လုပ်ဆောင်ရန် ငြင်းဆန်နိုင်သော်လည်း ဒေဝါလီခံခြင်းသည် ဒေဝါလီမခံမီ အကြွေးရှင်မှ လုပ်ဆောင်ခဲ့သည့် လုပ်ဆောင်ချက်ကို ပြန်လည်ပယ်ဖျက်ရန် သို့မဟုတ် တစ်စုံတစ်ခုကို သည်းခံခြင်း သို့မဟုတ် ရှောင်ကြဉ်ခြင်းပါဝင်သည့်အတိုင်းအတာအထိ ဆက်လက်လုပ်ဆောင်ခြင်းကို အဆုံးသတ်ရန် အာဏာမပေးပါ။
အဲဒီစကားစုက software အတွက် အရေးကြီးတာပါ။ လိုင်စင်ဆိုတာ မူပိုင်ခွင့်ကို ချိုးဖောက်မယ့် အသုံးပြုမှုကို သည်းခံဖို့ မူပိုင်ခွင့်ရှိသူက ကတိကဝတ်တစ်ခုဖြစ်ပြီး သည်းခံခြင်းပါဝင်တဲ့ စဉ်ဆက်မပြတ်လုပ်ဆောင်မှုတစ်ခုလည်း ဖြစ်ပါတယ်။ ဒါကြောင့် လက်ရှိဥပဒေအရ ဒေဝါလီမခံခင် တရားဝင်ထုတ်ပေးထားတဲ့ လိုင်စင်ဟာ ဆက်လက်တည်ရှိနေပြီး භාရမှူးက ရုပ်သိမ်းလို့မရပါဘူး။ භාရမှူးက အသက်ဝင်နေတဲ့ အရာအားလုံးကို ငြင်းပယ်နိုင်ပေမယ့် သင်ကိုင်ဆောင်ထားတဲ့ အသုံးပြုခွင့်ကို ပိတ်လို့မရပါဘူး။
ဒါက မင်းရဲ့ အစီအစဉ်အတွက် ဘာကိုဆိုလိုတာလဲ
အချက်နှစ်ချက် လိုက်ပါလာသည်။ ထုတ်ပေးသူမဟုတ်ဘဲ escrow အေးဂျင့်အပေါ်တွင် လွှတ်ပေးရန်တာဝန်ကို ထားရှိပါ- တတိယပါတီမှ ထိန်းသိမ်းထားသော လွတ်လပ်သော ထိန်းသိမ်းစောင့်ရှောက်ရေးအဖြစ် တည်ထောင်ပါ၊ လွှတ်ပေးခြင်းသည် အေးဂျင့်၏ကိုယ်ပိုင်စွမ်းဆောင်ရည်နှင့် භාရမှူး၏အာဏာဖြစ်သည်။ ၃၇ Fw bites သည် solvent agent ပေါ်တွင်မဟုတ်ဘဲ အမွေဆက်ခံသူမှ ပေးရန်ရှိသော စွမ်းဆောင်ရည်များအပေါ်တွင်ဖြစ်ပြီး၊ နှစ်ဖက်ကတိကဝတ်တွင် အမွေဆက်ခံသူမှ ငြင်းပယ်နိုင်သည်။ အောက်တွင် ဆွေးနွေးထားသော အရေးကြီးဆုံး မူကြမ်းရေးဆွဲသည့်အချက်မှာ လိုင်စင်ကို လွှတ်ပေးချိန်တွင်မဟုတ်ဘဲ ကြိုတင်ခွင့်ပြုခြင်းဖြစ်သည်။
ဒေဝါလီခံခြင်းထက် ပြန်လည်ဖွဲ့စည်းခြင်းတွင်၊ အပိုဒ် ၃၇၃ Fw သည် ipso facto clauses များအပေါ် မှီခိုမှုကို ကန့်သတ်ထားသည် - ပြန်လည်ဖွဲ့စည်းခြင်းလုပ်ငန်းစဉ် စတင်ပြီဖြစ်သောကြောင့် စာချုပ်ကို တစ်ဖက်သတ်ပြင်ဆင်ခြင်း၊ ဆိုင်းငံ့ခြင်း သို့မဟုတ် ရပ်စဲခြင်းတို့ကို ခွင့်ပြုသည့် ပြဋ္ဌာန်းချက်များ။ ထိုကန့်သတ်ချက်သည် ဒေဝါလီခံခြင်းတွင် မဟုတ်ဘဲ အစီအစဉ်လုပ်ထုံးလုပ်နည်းတွင် လည်ပတ်ပြီး ၎င်း၏အဖြေသည် ဖွဲ့စည်းပုံဆိုင်ရာဖြစ်သည်- အစီအစဉ်ကို တတိယပါတီမှ လွတ်လပ်သော ထိန်းသိမ်းစောင့်ရှောက်မှုအဖြစ် ရေးဆွဲသည့်အခါ၊ လွှတ်ပေးခြင်းအစပျိုးမှုသည် အေးဂျင့်၏ကိုယ်ပိုင်တာဝန်ဝတ္တရားပေါ်တွင် လည်ပတ်ပြီး ဒေဝါလီခံခြင်းတွင်ထက် WHOA ပြန်လည်ဖွဲ့စည်းခြင်းတွင် ဘေးဖယ်ထားရန် ဖွင့်လှစ်ထားသော ipso facto ပြဋ္ဌာန်းချက်နှင့် မသက်ဆိုင်ပါ။
လိုင်စင်ကို ဘယ်လိုဖွဲ့စည်းထားရမလဲ
Escrow က source code ရဲ့ မိတ္တူကို ပေးပေမယ့် ဘာမှလုပ်ခွင့်မရှိပါဘူး။ source code ဟာ ကာကွယ်ထားတဲ့ work တစ်ခုဖြစ်ပြီး compile လုပ်ခြင်း၊ ပြင်ဆင်ခြင်းနဲ့ result ကို run လုပ်ခြင်းတွေဟာ ကန့်သတ်ထားတဲ့ လုပ်ဆောင်ချက်တွေ ဖြစ်ပါတယ်။ license မပါဘဲ released deposit ဆိုတာ folder တစ်ခုဖြစ်ပြီး ဖွင့်လို့မရပါဘူး။ escrow ကို customer က release လုပ်တဲ့အခါ source code ကို အသုံးပြုခွင့်၊ compile လုပ်ခွင့်၊ ပြင်ဆင်ခွင့်နဲ့ ဆက်လက်တီထွင်ခွင့်၊ third party တစ်ယောက်က လုပ်ဆောင်ခွင့် ပေးထားတဲ့ license နဲ့ တွဲပေးလိုက်ရင် လက်တွေ့မှာ ကိုယ်တိုင်လုပ်လို့ မရပါဘူး။
ထို့နောက် အချိန်ကိုက်ခြင်း။ ထုတ်ပေးချိန်တွင် ထုတ်ပေးသော လိုင်စင် သည် ပျက်စီးလွယ်ပါသည်။ ထုတ်ပေးသည့်ဖြစ်ရပ်သည် ဒေဝါလီခံခြင်းကိုယ်တိုင်ဖြစ်ပါက ထုတ်ပေးသည့်ငွေကို ဒေဝါလီခံအမိန့်ချမှတ်သည့်နေ့မှစ၍ အမွေဆက်ခံပစ္စည်းရှိ ပိုင်ဆိုင်မှုများကို စီမံခန့်ခွဲပိုင်ခွင့် ဆုံးရှုံးသွားသော အကြွေးရှင်မှ ထုတ်ပေးရမည်ဖြစ်သည်။ အပိုဒ် ၂၃ Fw နှင့် အပိုဒ် ၃၅ Fw တို့သည် လမ်းတွင်ရှိနေပြီး භාရမှူးက သင့်အတွက် ထုတ်ပေးမည်မဟုတ်ပါ။ Credit Suisse/Jongepier ဆိုသည်မှာ භාရမှူးသည် သင်ရှိပြီးသားလိုင်စင်ကို ရုပ်သိမ်း၍မရဟု ဆိုလိုသည် - သို့သော် သင်တွင် တစ်ခါမှ မရှိခဲ့ဖူးပါက ရုပ်သိမ်းရန် ဘာမှမရှိပါ။
စာချုပ်တွင် မည်သည့်ဒေဝါလီခံမှုမှ မပြုလုပ်မီ၊ အခြေအနေရှေ့ပြေးအခြေအနေအရ ၎င်းကို ခွင့်ပြုပါ- ယခုခွင့်ပြုပြီး လွှတ်ပေးသည့်ဖြစ်ရပ်တွင် အကျိုးသက်ရောက်မှုရှိသည်။ အခွင့်အရေးသည် စာချုပ်ချုပ်ဆိုသည့်နေ့မှစ၍ တည်ရှိနေပြီး ၎င်း၏အကျိုးသက်ရောက်မှုကိုသာ ရွှေ့ဆိုင်းထားသည်။ ဒတ်ချ်ဥပဒေသည် ယေဘုယျအားဖြင့် ဤဖွဲ့စည်းပုံကို လက်ခံသည်။ Rabobank/Reuser (Hoge Raad၊ ၂၀၁၆ ခုနှစ် ဇွန်လ ၃ ရက်၊ ECLI:NL:HR:2016:1046) တွင် ဒေဝါလီမခံမီ အခြေအနေဆိုင်ရာအခွင့်အရေးတစ်ခု ဖန်တီးခဲ့ပါက၊ အကြွေးရှင်မှ နောက်ထပ်အရေးယူဆောင်ရွက်မှုမရှိဘဲ အခြေအနေပြည့်စုံမှုသည် နောက်ပိုင်းတွင် အကျိုးသက်ရောက်မှုရှိကြောင်း တရားရုံးချုပ်က လက်ခံခဲ့သည်။ ထိုအမှုတွင် ကုန်ပစ္စည်းများ၏ အခြေအနေဆိုင်ရာလွှဲပြောင်းမှုနှင့် အခြေအနေဆိုင်ရာအခွင့်အရေးအပေါ် ကတိကဝတ်နှင့် သက်ဆိုင်သည်။ အခြေအနေအရ ခွင့်ပြုထားသော မူပိုင်ခွင့်လိုင်စင်ကို အသုံးပြုခြင်းသည် တရားရုံးများမှ ဖြေရှင်းချက်ပေးသည့်အချက်ထက် ဥပဒေရေးရာစာပေများတွင် ထောက်ခံထားသော ခန့်မှန်းချက်တစ်ခုဖြစ်ပြီး ၎င်းကို ထိုအတိုင်း တင်ပြသင့်သည်။
ထုတ်ပြန်ထားသော ပစ္စည်းကို အသုံးပြုခြင်းသည် ပေးသွင်းသူ သို့မဟုတ် ၎င်း၏ භාရမှူးထံမှ နောက်ထပ် သဘောတူညီချက် မလိုအပ်ကြောင်းနှင့် ဆက်ခံသူ developer အား လိုင်စင်ခွဲပေးခြင်းကို ခွင့်ပြုထားကြောင်းလည်း အတည်ပြုပါ။
SaaS နှင့် cloud: source code သည် မလုံလောက်ပါ
ကိုယ်တိုင်လည်ပတ်တဲ့ software အတွက် source code ၊ build instruction တွေနဲ့ license တွေက ပြီးပြည့်စုံတဲ့အဖြေတစ်ခုနဲ့ နီးစပ်ပါတယ်။ service တစ်ခုအတွက်တော့ မဟုတ်ပါဘူး။ supplier ရဲ့ platform က မှောင်မိုက်သွားရင် application၊ သူလည်ပတ်တဲ့ environment နဲ့ သင့်ရဲ့ data တွေကို ဆုံးရှုံးသွားပြီး source code က ပထမဆုံးတစ်ခုကိုပဲ ဖြည်းဖြည်းချင်း restore လုပ်ပါတယ်။ SaaS continuity arrangement မှာ အောက်ပါအချက်သုံးချက်ကို ထည့်သွင်းရပါမယ်။
- လုပ်ငန်းလည်ပတ်မှုပတ်ဝန်းကျင်။ Container image များ၊ infrastructure-as-code definitions များ၊ configuration၊ network နှင့် security setting များ၊ runtime dependencies များသည် အခြားနေရာတွင် platform ကို ရပ်တည်ရန် လုံလောက်ပါသည်။
- အချက်အလက်။ သင့်ကိုယ်ပိုင်ဒေတာကို schema ပါရှိသော မှတ်တမ်းတင်ထားသော၊ မူပိုင်ခွင့်မရှိသော format ဖြင့် ပုံမှန်ထုတ်ယူခြင်း။ သင်ဖတ်၍မရသောဒေတာသည် သင်ပိုင်ဆိုင်သောဒေတာမဟုတ်ပါ၊ ထုတ်ယူမှုများသည် ထုတ်ဝေမှုတွင်သာမက စာချုပ်တစ်လျှောက်လုံး လုပ်ဆောင်သင့်သည်။
- လက်ခံကျင်းပရေး ဆက်ဆံရေး။ ပေးသွင်းသူ၏ hosting provider နှင့် စာချုပ်ချုပ်ဆိုရန် သို့မဟုတ် အကောင့်ကို သင်လွှဲပြောင်းယူပြီး တိုက်ရိုက်ငွေပေးချေနိုင်ကြောင်း ထိုပေးသွင်းသူထံ အကြောင်းကြားရန် လမ်းကြောင်း။
အစားထိုးနည်းလမ်းများနှင့် မည်သူက ငွေပေးချေသည်
Escrow သည် အမြဲတမ်း အကောင်းဆုံးတန်ဖိုးမဟုတ်ပါ။ အထူးသဖြင့် သင်သည် ထောင်ပေါင်းများစွာသော ဖောက်သည်များထဲမှ တစ်ဦးဖြစ်ပြီး လက်တွေ့ကျသောအန္တရာယ်မှာ ကျရှုံးမှုထက် နေဝင်ချိန်ဖြစ်သည်။ ပိုမိုပေါ့ပါးသော ရွေးချယ်စရာသုံးခုသည် မကြာခဏ ပိုမိုအသုံးဝင်သည်- data exit right — အနည်းဆုံး တစ်ကြိမ်စမ်းသပ်ပြီး မှတ်တမ်းတင်ထားသော format ဖြင့် ပုံမှန်တင်ပို့မှုများ — ကုန်ကျစရိတ်မရှိသလောက်ဖြင့် exposure အများစုကို လွှမ်းခြုံခြင်း၊ running copy တစ်ခုအတွက် အခွင့်အရေး ၊ transitional period အတွက် သင် run နိုင်သော deployable image တစ်ခု၊ rebuild ထက် များစွာပိုမြန်သော service ကို restore လုပ်ခြင်း၊ နှင့် hosting provider သို့ တိုက်ရိုက်ငွေပေးချေမှု ၊ သင် migrate လုပ်နေစဉ် environment ကို run နေစဉ်တွင် ထိန်းသိမ်းထားခြင်း — အသက်သာဆုံး cloud continuity ဖြစ်ပြီး အများဆုံး လျစ်လျူရှုခံရလေ့ရှိသည်။
Escrow ကိုသုံးမယ်ဆိုရင် တစ်ကြိမ်တည်းတပ်ဆင်ခ၊ နှစ်စဉ်ထိန်းသိမ်းခနဲ့ ချက်လက်မှတ်ရဲ့အနက်ပေါ်မူတည်ပြီး ကွဲပြားတဲ့ အတည်ပြုချက်တစ်ခုအတွက် သီးခြားကောက်ခံမှုတွေ ရှိလာနိုင်ပါတယ်။ ကုန်ကျစရိတ်က ကာကွယ်မှုကို လိုချင်တဲ့သူ၊ ပုံမှန်အားဖြင့် ဖောက်သည်ဆီမှာပဲ ရှိပါတယ်။ ဒါပေမယ့် Escrow ကို ရောင်းချမှုအချက်အဖြစ် ပေးဆောင်တဲ့ ပေးသွင်းသူက ဒါကို သယ်ဆောင်နိုင်ပြီး ထုတ်ကုန်တစ်ခုတည်းရဲ့ ဖောက်သည်အများအပြားကို လွှမ်းခြုံထားတဲ့ အစီအစဉ်က အဲဒါကို ဖြန့်ကျက်ပေးပါတယ်။ ပေးသွင်းသူက ငြင်းဆန်တဲ့ ပုံမှန်ဆင်းသက်ရာနေရာပါ။ အေးဂျင့်က သင့်ကို အကြောင်းကြားရမယ့်အရာတစ်ခုကို ငွေပေးချေမှုမပြုလုပ်ဘဲ ပြုလုပ်ပါ၊ ၎င်းအစား ပေးချေပိုင်ခွင့်ရှိပါတယ်။
Escrow အစီအစဉ်တစ်ခုကို ညှိနှိုင်းရန်အတွက် စစ်ဆေးရမည့်စာရင်း
- တိုက်ရိုက်လွှတ်ပေးရန် တာဝန်ဝတ္တရားရှိသောကြောင့် လွတ်လပ်သောအေးဂျင့်တစ်ဦးနှင့် စစ်မှန်သော သုံးပွင့်ဆိုင်သဘောတူညီချက်တစ်ခုလား။
- source code ကို အသုံးပြုခွင့်၊ စုစည်းခွင့်၊ ပြုပြင်ခွင့်နှင့် ဆက်လက်တီထွင်ခွင့် လိုင်စင် ရရှိထားပါသလား။ ယခုလွှတ်ပေးမည်ဟု ကတိပေးထားသည့်အတိုင်းမဟုတ်ဘဲ၊ အခြေအနေကြိုတင်သတ်မှတ်ချက်အပေါ် မူတည်ပါသလား။
- အပ်ငွေစာရင်းတွင် ထုတ်လုပ်မှုတိုင်းတွင် အပ်ဒိတ်လုပ်ထားသော source code မဟုတ်ဘဲ build instructions၊ dependencies၊ license keys နှင့် documentation များ ပါဝင်ပါသလား။
- ဘယ်အတည်ပြုချက်အဆင့်ကို စာချုပ်ချုပ်ဆိုပြီး ဘယ်လောက်မကြာခဏ ထပ်ခါတလဲလဲ ပြုလုပ်ပါသလဲ။
- ထုတ်ပြန်မှုဖြစ်ရပ်များကို စာရွက်စာတမ်း သို့မဟုတ် အချိန်ကုန်ဆုံးမှုအပေါ် မူတည်၍ ဆုံးဖြတ်နိုင်ပါသလား၊ ကန့်ကွက်ချိန်တိုတောင်းပြီး အငြင်းပွားမှုလမ်းကြောင်းကို မြန်ဆန်စွာ သတ်မှတ်နိုင်ပါသလား။
- SaaS အတွက်- ပတ်ဝန်းကျင်၊ အချက်အလက်နှင့် hosting relationship တို့ကို လွှမ်းခြုံထားပါသလား၊ သို့မဟုတ် code တစ်ခုတည်းကိုသာ လွှမ်းခြုံထားပါသလား။
- ဘယ်သူက ငွေပေးချေသလဲ၊ ပေးသွင်းသူက ငွေပေးချေတာ ရပ်တန့်သွားရင် ဘာဖြစ်မလဲ၊ escrow သဘောတူညီချက်က အဓိကစာချုပ်ရဲ့ အုပ်ချုပ်မှုဥပဒေနဲ့ IP စည်းကမ်းချက်တွေနဲ့ ကိုက်ညီပါသလား။
ဒေဝါလီခံရတဲ့ ဒတ်ချ် භාရမှူးတစ်ယောက်က escrow agent က source code ကို ထုတ်လွှတ်တာကို တားဆီးနိုင်ပါသလား။
တိုက်ရိုက်မဟုတ်ပါ။ သုံးပွင့်ဆိုင်သဘောတူညီချက်တွင် စွန့်လွှတ်ရမည့်တာဝန်ကို escrow အေးဂျင့်မှ ၎င်း၏ကိုယ်ပိုင်စာချုပ်အရ သင့်ထံ ပေးဆောင်ရမည်ဖြစ်ပြီး အေးဂျင့်သည် ဒေဝါလီမခံပါ။ ပုဒ်မ ၃၇ Fw အရ භාရမှူး၏ အာဏာမှာ အေးဂျင့်အား ညွှန်ကြားရန်မဟုတ်ဘဲ အမွေဆက်ခံသူမှ ပေးရန်ရှိသော စွမ်းဆောင်ရည်များကို ငြင်းပယ်ရန်ဖြစ်သည်။ ပေးသွင်းသူ၏ကတိထက် သုံးပွင့်ဆိုင်သဘောတူညီချက်ကို ပိုနှစ်သက်ရခြင်း၏ အဓိကအကြောင်းရင်းဖြစ်သည်။
ကျွန်တော့်ရဲ့ software license က supplier ရဲ့ ဒေဝါလီခံမှုကို ကျော်လွှားနိုင်ပါသလား။
ဒေဝါလီခံမှု မရှင်သန်မီ တရားဝင်ထုတ်ပေးထားသော လိုင်စင်တစ်ခုဖြစ်ပြီး භාရမှူးသည် ၎င်းကို ရုပ်သိမ်း၍မရပါ။ Credit Suisse/Jongepier qq (Hoge Raad၊ ၂၀၁၈ ခုနှစ် မတ်လ ၂၃ ရက်၊ ECLI:NL:HR:2018:424) တွင် භාရမှူးတစ်ဦးသည် သည်းခံခြင်း သို့မဟုတ် ရှောင်ကြဉ်ခြင်းပါဝင်သည့် ဆက်လက်လုပ်ဆောင်သည့် လုပ်ဆောင်ချက်ကို ရပ်တန့်၍မရကြောင်း တရားရုံးချုပ်က အတည်ပြုခဲ့ပြီး လိုင်စင်သည် ထိုကဲ့သို့သော လုပ်ဆောင်ချက်တစ်ခုဖြစ်သည်။ භාရမှူးသည် ပြုပြင်ထိန်းသိမ်းမှု၊ ပံ့ပိုးမှု၊ အပ်ဒိတ်များ၊ လက်ခံခြင်း စသည့် လက်ရှိလုပ်ဆောင်နေသည့် အရာအားလုံးကို ငြင်းပယ်နိုင်သည်-
Nebula ရဲ့ ဆုံးဖြတ်ချက်က လိုင်စင်ရသူတွေအတွက် ခြိမ်းခြောက်မှုတစ်ခု ဖြစ်နေတုန်းပဲလား။
တစ်ချိန်ကကြောက်ရွံ့ခဲ့ရသည့်ပုံစံမဟုတ်ပါ။ Nebula (Hoge Raad၊ ၂၀၀၆ ခုနှစ်၊ နိုဝင်ဘာလ ၃ ရက်၊ ECLI:NL:HR:2006:AX8838) ကို භාရမှူးတစ်ဦးအား လက်ရှိအသုံးပြုခွင့်ကို လျစ်လျူရှုခွင့်ပြုသည်ဟု ကျယ်ကျယ်ပြန့်ပြန့်ဖတ်ရှုခဲ့ကြသည်။ Berzona နှင့် Credit Suisse/Jongepier တို့က ထိုဖတ်ရှုမှုကို ကန့်သတ်ထားသည်။ භාရမှူးသည် လုပ်ဆောင်ရန် ငြင်းဆိုနိုင်သော်လည်း ဥပဒေ သို့မဟုတ် စာချုပ်က မပေးထားသော အာဏာမရှိပါ၊ လိုင်စင်ကို ရုပ်သိမ်းခြင်းသည် ထိုအာဏာမျိုးမဟုတ်ပါ။
လိုင်စင်ထုတ်ပေးမှသာ ထုတ်ပေးတာ ဘာကြောင့် ပြဿနာဖြစ်ရတာလဲ။
အဘယ်ကြောင့်ဆိုသော် ဒေဝါလီခံပြီးနောက်၊ အကြွေးရှင်သည် အမွေဆက်ခံပစ္စည်း၏ပိုင်ဆိုင်မှုများကို စီမံခန့်ခွဲပိုင်ခွင့် ဆုံးရှုံးသွားပြီး භාရမှူးသည် သင့်အတွက် လုပ်ဆောင်ရန် တာဝန်မရှိသည့်အခါတွင် ထောက်ပံ့ငွေကို ပေးအပ်ရမည်ဖြစ်သောကြောင့်ဖြစ်သည်။ အမှုအခင်းဆိုင်ရာဥပဒေသည် သင်ပိုင်ဆိုင်ထားပြီးဖြစ်သော လိုင်စင်များကို ကာကွယ်ပေးသော်လည်း မည်သည့်လိုင်စင်ကိုမျှ မဖန်တီးပါ။ ထုတ်ပေးသည့်အချိန်တွင် အကျိုးသက်ရောက်သည့် ရှေ့ပြေးအခြေအနေအပေါ် မူတည်၍ ယခုပင် ထောက်ပံ့ငွေပေးပါ။
SaaS ပေးသွင်းသူတစ်ဦးအတွက် escrow က အထောက်အကူပြုပါသလား။
တစ်စိတ်တစ်ပိုင်းသာ။ source code က လုပ်ဆောင်နေတဲ့ service ကို restore မလုပ်ပါဘူး။ အလုပ်လုပ်နိုင်တဲ့ SaaS အစီအစဉ်တစ်ခုမှာ operational environment — container images, infrastructure definitions, configuration — documented format နဲ့ data ကို ပုံမှန် export လုပ်ခြင်းနဲ့ hosting provider ကို လွှဲပြောင်းယူဖို့ ဒါမှမဟုတ် ငွေပေးချေဖို့ route စတာတွေကိုလည်း လွှမ်းခြုံထားရပါမယ်။ အဲဒါတွေမရှိရင် continuity ထက် rebuild project တစ်ခုကိုပဲ ရစေပါတယ်။
အတည်ပြုခြင်းအတွက် တကယ်ပဲ ငွေပေးချေရကျိုးနပ်ပါသလား။
ဟုတ်ကဲ့၊ အလယ်အလတ်အဆင့်မှာပါ။ ဖိုင်အဆင့်စစ်ဆေးမှုက တစ်ခုခုရောက်လာတာကိုပဲ အတည်ပြုပါတယ်။ build ညွှန်ကြားချက်တွေနဲ့ dependency list ကို နှိုင်းယှဉ်ပြီး ပြီးပြည့်စုံမှုပြန်လည်သုံးသပ်ခြင်းက အရေးကြီးတဲ့ ပျက်ကွက်မှုတွေကို ဖမ်းယူပါတယ် - ပျောက်ဆုံးနေတဲ့ build အဆင့်တွေ၊ မှတ်တမ်းမတင်ထားတဲ့ dependencies တွေ၊ သင်အသုံးပြုခွင့်မရှိတဲ့ components တွေ။ အပြည့်အဝတည်ဆောက်ပြီး စမ်းသပ်မှုလုပ်ဆောင်ခြင်းဟာ တစ်ခုတည်းသော အပြီးသတ်ရွေးချယ်မှုဖြစ်ပြီး outage ဖြစ်ခြင်းက တည်ရှိမှုတစ်ခုဖြစ်လာမယ့်နေရာမှာ ၎င်းရဲ့ကုန်ကျစရိတ်နဲ့ ထိုက်တန်ပါတယ်။
