ဒတ်ချ်နှင့် EU ဥပဒေအရ open source software လိုင်စင်များ

စီးပွားဖြစ်ဆော့ဖ်ဝဲလ်ထုတ်ကုန်တိုင်းနီးပါးတွင် open source အစိတ်အပိုင်းများပါဝင်ပြီး ရှေ့နေများထက် developer များက ရွေးချယ်ထားသော ရာပေါင်းများစွာပါဝင်သည်။ မည်သည့်လိုင်စင်များ အကျုံးဝင်သည်၊ ၎င်းတို့ လိုအပ်သည်နှင့် ထုတ်ကုန်သည် ကိုက်ညီမှုရှိမရှိကို မည်သူမျှ မပြောနိုင်သောအခါ ၎င်းသည် ပြဿနာတစ်ခု ဖြစ်လာသည်။ ဤဆောင်းပါးသည် ဒတ်ချ်နှင့် EU ဥပဒေအရ open source လိုင်စင်များ မည်သို့အလုပ်လုပ်သည်၊ အန္တရာယ်ရှိသည့်နေရာနှင့် မည်သည်တို့ကို ထားရှိရမည်ကို ရှင်းပြထားသည်။

ဥပဒေရေးရာအရ open source လိုင်စင်ဆိုတာ ဘာလဲ

အိုးပင်းဆို့စ်လိုင်စင်ဆိုသည်မှာ စည်းကမ်းချက်များနှင့်အညီ ပေးအပ်ထားသော မူပိုင်ခွင့်လိုင်စင်တစ်ခုဖြစ်သည်။ ၎င်းသည် စွန့်လွှတ်ခြင်းမဟုတ်၊ အများပြည်သူပိုင်ဒိုမိန်းအတွက် အပ်နှံခြင်းမဟုတ်၊ အခွင့်အရေးများကို စွန့်လွှတ်ခြင်းမဟုတ်၊ ထိုသဘောအရ ၎င်းသည် ဒတ်ချ်ဥပဒေအရ အခြားဆော့ဖ်ဝဲလိုင်စင်များ ကဲ့သို့ပင် အလုပ်လုပ်ပါသည် ။ စာရေးသူသည် ကွန်ပျူတာပရိုဂရမ်များကို လက်ရာများအဖြစ် ကာကွယ်ပေးသည့် အပိုဒ် 1 Aw နှင့် အပိုဒ် 10 Aw အောက်တွင် မူပိုင်ခွင့်ကို ထိန်းသိမ်းထားပြီး၊ လိုင်စင်သည် အပိုဒ် 12 Aw နှင့် အပိုဒ် 13 Aw အောက်တွင် သီးသန့်အခွင့်အရေးများကို ချိုးဖောက်မည့် လုပ်ဆောင်မှုများကို ခွင့်ပြုသည်။

အဓိပ္ပာယ်ဖွင့်ဆိုချက်ထက် အကျိုးဆက်က ပိုအရေးကြီးပါတယ်။ လိုက်နာမယ်ဆိုရင် သင့်ရဲ့ မိတ္တူကူးခြင်းနဲ့ ဖြန့်ဖြူးခြင်းဟာ တရားဝင်ပါတယ်။ လိုက်နာဖို့ ပျက်ကွက်ရင် ခွင့်ပြုချက်က သင်လုပ်ခဲ့တာတွေကို အကျုံးမဝင်ပါဘူး- သင့်ရဲ့အသုံးပြုမှုဟာ မူပိုင်ခွင့်ချိုးဖောက်မှုဖြစ်ပြီး စာချုပ်ချိုးဖောက်မှု မဟုတ်ပါဘူး။ copyleft လိုင်စင်အများစုဟာ ချိုးဖောက်မှုအပေါ် အလိုအလျောက် ရပ်စဲခြင်းဖြင့် ဒါကို အားဖြည့်ပေးပါတယ် - GPLv2 ဟာ ကုသချိန်မရှိဘဲ ချိုးဖောက်မှုဖြစ်ပြီး GPLv3 နဲ့ AGPLv3 တို့ဟာ အသိပေးချက်ပြီးနောက် သတ်မှတ်ထားတဲ့ ဝင်းဒိုးတစ်ခုအတွင်း ချိုးဖောက်မှုကို ပျောက်ကင်းအောင် လုပ်ဆောင်ပါက အခွင့်အရေးများကို ပြန်လည်ပေးအပ်ပါတယ်။

ဒတ်ချ်တရားရုံးများသည် ဤကျိုးကြောင်းဆင်ခြင်ချက်ကို ကျင့်သုံးကြသည်။ Rb တွင်။ Amsterdam ၂၀၂၀ ခုနှစ်၊ စက်တင်ဘာလ ၂၂ ရက်၊ ECLI:NL:RBAMS:2020:4717 တွင်၊ forked codebase မှ လိုင်စင်စာသားနှင့် မူပိုင်ခွင့်အသိပေးချက်ကို ဖယ်ရှားခဲ့သော ဖြန့်ဖြူးသူတစ်ဦးသည် ၎င်း၏ခွင့်ပြုချက်ကို ဆုံးရှုံးခဲ့ပြီး ချိုးဖောက်မှုအဖြစ် ဆုံးဖြတ်ခံခဲ့ရသည်။ ကုဒ်အသစ်များစွာထည့်သွင်းခြင်းသည် လွတ်လပ်သောလက်ရာတစ်ခုကို မဖန်တီးနိုင်ခဲ့ပါ- မူရင်းသည် ထင်ရှားစွာရှိနေသောကြောင့် တာဝန်ဝတ္တရားများသည် ၎င်းနှင့်အတူ လိုက်ပါလာခဲ့သည်။

မိသားစုနှစ်စု- ခွင့်ပြုခြင်းနှင့် ကူးယူခြင်း

ခွင့်ပြုချက်လိုင်စင်များ — MIT၊ BSD လိုင်စင်များ၊ Apache 2.0 — သည် မူပိုင်ခွင့်သတိပေးချက်များနှင့် လိုင်စင်စာသားကို သင်ထိန်းသိမ်းထားပါက closed-source ထုတ်ကုန်များအတွင်း အပါအဝင် အသုံးပြုခြင်း၊ ပြုပြင်မွမ်းမံခြင်းနှင့် ပြန်လည်ဖြန့်ဖြူးခြင်းကို ခွင့်ပြုသည်။

Copyleft လိုင်စင်များတွင် သင်သည် ဆော့ဖ်ဝဲ သို့မဟုတ် ၎င်းပေါ်တွင်တည်ဆောက်ထားသော တစ်ခုခုကို ဖြန့်ဝေသည့်အခါ တူညီသောလိုင်စင်အောက်တွင် လုပ်ဆောင်ပြီး သက်ဆိုင်ရာရင်းမြစ်ကို ရရှိနိုင်အောင် ပြုလုပ်ရန် လိုအပ်သည်။ ၎င်းတို့သည် ရောက်ရှိနိုင်မှုတွင် မတူညီပါ။

copyleft trigger နှင့် linking မေးခွန်း

မူပိုင်ခွင့်လက်ဝဲတာဝန်ဝတ္တရားများသည် ဖြန့်ဖြူးမှုအပေါ်တွင်သာ သက်ရောက်မှုရှိပြီး အသုံးပြုမှုအပေါ်တွင် သက်ရောက်မှုမရှိပါ။ GPL ဆော့ဖ်ဝဲကို အတွင်းပိုင်းတွင် လည်ပတ်နေသော ကုမ္ပဏီတစ်ခုသည် မည်မျှပင် အကြီးအကျယ်ပြုပြင်မွမ်းမံပါစေ၊ မည်သည့်အရာကိုမျှ ဖြန့်ဝေခြင်းမရှိ၊ မည်သည့်အရာကိုမျှ ပေးရန်မလိုအပ်ပါ။ “ကျွန်ုပ်တို့ ဖြန့်ဝေပြီးပြီလား” ဆိုသည်မှာ အမြဲတမ်း ပထမဆုံးမေးခွန်းဖြစ်ပြီး၊ ထို့ကြောင့်ပင် ကွန်တိန်နာများ၊ စက်ပစ္စည်းများ၊ firmware နှင့် SDK များသည် အတွင်းပိုင်းကိရိယာများထက် ပိုမိုအရေးပါသည်။

ဒုတိယမေးခွန်းက ပိုခက်ပါတယ်။ GPL မှာ အမေရိကန်ရဲ့ အယူအဆကို ကူးယူပြီး ဆင်းသက်လာတဲ့ လက်ရာတစ်ခုအကြောင်း ပြောထားပါတယ်။ ဒတ်ချ်ဥပဒေမှာ ဒီလိုအသုံးအနှုန်း မရှိပါဘူး။ မူရင်းကနေ ကာကွယ်ထားတဲ့ ဖော်ပြချက်ကို ပြန်လည်ထုတ်လုပ်ထားခြင်း ရှိ၊ မရှိ မေးမြန်းတဲ့ ခွဲခြမ်းစိတ်ဖြာမှုမှာ မျိုးပွားခြင်းနဲ့ လိုက်လျောညီထွေဖြစ်အောင် ပြုလုပ်ခြင်းဆိုင်ရာ အခွင့်အရေးတွေကို ဖြတ်သန်းပါတယ်။

လက်တွေ့အခြေအနေကတော့ ချိတ်ဆက်ခြင်းပါ။ ပိုင်ဆိုင်မှုဆိုင်ရာ မော်ဂျူးတစ်ခုကို GPL စာကြည့်တိုက်နှင့် ချိတ်ဆက်ခြင်းသည် copyleft ၏ လက်အောက်ခံ လက်ရာတစ်ခုကို ဖန်တီးပေးသည်ဖြစ်စေ မဖြစ်စေ ဒတ်ချ်တရားရုံးမှ ဘယ်သောအခါမှ ဆုံးဖြတ်ခဲ့ခြင်း မရှိသလို EU အာဏာပိုင်လည်း မရှိပါ။ ချိတ်ဆက်ခြင်းသည် ပေါင်းစပ်လက်ရာတစ်ခုကို ဖန်တီးပေးသည်ဟူသော Free Software Foundation ၏ အမြင်သည် လိုင်စင်ထိန်းသိမ်းသူ၏ အဓိပ္ပာယ်ဖွင့်ဆိုချက်ဖြစ်ပြီး ဥပဒေမဟုတ်ဘဲ ဆန့်ကျင်ဘက်အမြင်လည်း အလားတူပင် စမ်းသပ်ထားခြင်း မရှိပါ။ အင်တာနက်၏ အကြိုက်ဆုံးအဖြေ — dynamic linking ဘေးကင်းသည်၊ static linking မဟုတ် — သည် ဒတ်ချ်မူပိုင်ခွင့်ဥပဒေတွင် အခြေခံမရှိပါ။ compiler သည် မည်သို့ပြုမူသည်ကို မမေးပါ။ ပိုမိုကာကွယ်နိုင်သော ခွဲခြမ်းစိတ်ဖြာမှုတစ်ခုတွင် အစိတ်အပိုင်းများ မည်မျှနီးကပ်စွာ ပေါင်းစပ်ထားသည်ကို မေးမြန်းသည်- ၎င်းတို့သည် လိပ်စာနေရာနှင့် ဒေတာဖွဲ့စည်းပုံများကို မျှဝေပါသလား၊ ပေါင်းစပ်မှုကို ထုတ်ကုန်တစ်ခုတည်းအဖြစ် ပို့ဆောင်ပါသလား၊ တစ်ခုတည်း လုပ်ဆောင်နိုင်ပါသလား၊ ပိုင်ဆိုင်မှုဆိုင်ရာဘက်မှ headers၊ macros သို့မဟုတ် inline code ကို copyleft ဘက်မှ ပြန်လည်ထုတ်လုပ်ပါသလား။ ထိုမေးခွန်းများသည် များသောအားဖြင့် အန္တရာယ်ကို ဖြေရှင်းပေးပါသည်။ ၎င်းတို့ မဖြေရှင်းသည့်နေရာတွင် အစိတ်အပိုင်းကို လုပ်ငန်းစဉ်နယ်နိမိတ်နောက်တွင် ခွဲထုတ်ပါ၊ ၎င်းကို အစားထိုးပါ သို့မဟုတ် စီးပွားဖြစ်လိုင်စင်ယူပါ။

AGPL နှင့် ကွန်ရက်အသုံးပြုမှု

AGPL တည်ရှိနေခြင်းမှာ copyleft ကို ဖြန့်ဖြူးမှုမှ လှုံ့ဆော်ပေးပြီး SaaS ဝန်ဆောင်မှုပေးသူများက ဖြန့်ဖြူးခြင်းမပြုသောကြောင့်ဖြစ်သည်။ ၎င်း၏ network clause တွင် သင်သည် software ကို ပြုပြင်မွမ်းမံပြီး အဝေးမှ အပြန်အလှန် ဆက်သွယ်နေသော အသုံးပြုသူများ ရရှိနိုင်အောင် ပြုလုပ်ပါက သင်ပြုပြင်ထားသော version ၏ သက်ဆိုင်ရာ source ကို ၎င်းတို့အား ပေးဆောင်ရန် လိုအပ်သည်။

အချက်သုံးချက်ကို မကြာခဏ လွတ်သွားလေ့ရှိပါတယ်။ ဒီတာဝန်ဝတ္တရားဟာ ဝန်ဆောင်မှုကို အသုံးပြုသူတွေအတွက် သက်ရောက်ပြီး open-signup product မှာ နှစ်သိမ့်မှုနည်းပါးပါတယ်။ ပြုပြင်မွမ်းမံမှုကြောင့် ဖြစ်ပေါ်လာတာကြောင့် ပြုပြင်မထားတဲ့ component က ပါဝင်ပတ်သက်မှာမဟုတ်ပေမယ့် patched build ကတော့ ပါဝင်ပတ်သက်နိုင်ပါတယ်။ ပြီးတော့ သင့်ရဲ့ stack ရဲ့ ကျန်တဲ့အပိုင်းတွေအတွက် GPL လိုပဲ combined-work မေးခွန်းကိုလည်း ပေါ်ပေါက်စေပါတယ်။ ဒါကြောင့်လည်း ကုမ္ပဏီအများစုက production code မှာ AGPL ကို တားမြစ်ထားတာပါ။

လိုင်စင် တွဲဖက်အသုံးပြုနိုင်မှု

လိုက်ဖက်ညီမှုဆိုသည်မှာ ဖြန့်ဖြူးမှုတစ်ခုတည်းတွင် နှစ်ခုစလုံးကို မဖြည့်ဆည်းနိုင်သော တာဝန်ဝတ္တရားများ ပြဋ္ဌာန်းထားသည့် လိုင်စင်များ၏ အစိတ်အပိုင်းများကို ပေါင်းစပ်ခြင်း၏ ပြဿနာဖြစ်သည်- ခွင့်ပြုထားသော လိုင်စင်များသည် အရာအားလုံးနီးပါးနှင့် တွဲဖက်အသုံးပြုနိုင်ပြီး copyleft လိုင်စင်များသည် ၎င်းတို့၏ကိုယ်ပိုင်စည်းကမ်းချက်များ ခွင့်ပြုထားသည့်အရာများဖြင့်သာ တွဲဖက်အသုံးပြုနိုင်သည်။ စံသတ်မှတ်ချက်မှာ Apache 2.0 နှင့် GPLv2 ဖြစ်သည်။ Apache Software Foundation နှင့် Free Software Foundation တို့က ပေါင်းစပ်မှုကို ခွင့်မပြုပါ၊ အဘယ်ကြောင့်ဆိုသော် Apache 2.0 ၏ မူပိုင်ခွင့်ရပ်စဲခြင်းနှင့် လျော်ကြေးပေးခြင်းဆိုင်ရာ ပြဋ္ဌာန်းချက်များသည် GPLv2 က ခွင့်မပြုသော နောက်ထပ်ကန့်သတ်ချက်များဖြစ်သောကြောင့်ဖြစ်သည်။ GPLv3 ကို ၎င်းတို့ကိုလက်ခံရန် ရေးဆွဲခဲ့သည်။ လိုက်ဖက်ညီမှုသည်လည်း ဦးတည်ချက်ဖြစ်သည်- Apache ကုဒ်ကို GPLv3 ပရောဂျက်ထဲသို့ စုပ်ယူနိုင်သော်လည်း ပြောင်းပြန်မဟုတ်ပါ။ GPL အစိတ်အပိုင်းတစ်ခု မှားယွင်းသောနေရာတွင် ရှိနေခြင်းသည် လိုင်စင်ပြန်လည်အသုံးပြုခြင်း၊ ပြန်လည်အင်ဂျင်နီယာပြုလုပ်ခြင်း သို့မဟုတ် ဖယ်ရှားခြင်းအကြား ရွေးချယ်မှုကို အတင်းအကျပ်ဖြစ်စေနိုင်သည် - ထုတ်ဝေပြီးနောက်ထက် ထုတ်ဝေပြီးနောက်တွင် များစွာစျေးသက်သာသည်။

အထောက်အထားနှင့် အသိပေးချက် တာဝန်ဝတ္တရားများ

အများဆုံး ချိုးဖောက်ခံရတဲ့ တာဝန်ဝတ္တရားတွေကတော့ သိသာထင်ရှားမှု အနည်းဆုံးပါပဲ- မူပိုင်ခွင့် အသိပေးချက်တွေ၊ လိုင်စင်စာသားတွေ၊ ငြင်းဆိုချက်တွေနဲ့ Apache 2.0 အောက်မှာ ဖြန့်ဖြူးမှုနဲ့အတူ ပါလာတဲ့ ပစ္စည်းတွေမှာ NOTICE အကြောင်းအရာတွေကို ပြန်လည်ဖော်ပြခြင်းပါ။ မိသားစုတိုင်းက MIT နဲ့ BSD အပါအဝင် ဒါတွေကို ချမှတ်ကြပါတယ်။ ဘယ်သူမှ မပိုင်ဆိုင်တဲ့အတွက် ချိုးဖောက်ခံရတာဖြစ်ပြီး ပြင်ဆင်ရတာ အလွယ်ကူဆုံးပါပဲ - ပုံမှန်အားဖြင့် ထုတ်ကုန်နဲ့အတူ ပါလာတဲ့ ထုတ်ပေးထားတဲ့ attribution ဖိုင်တစ်ခုပါ။ အထက်ဖော်ပြပါ ဒတ်ချ်အမှုက ဒီပျက်ကွက်မှုကို ဖြစ်ပေါ်စေခဲ့ပါတယ်။

မူပိုင်ခွင့်ပေးအပ်ခြင်းနှင့် မူပိုင်ခွင့်လက်စားချေခြင်း

MIT နှင့် BSD တို့သည် မူပိုင်ခွင့်များအကြောင်း ဘာမှမပြောကြဘဲ မူပိုင်ခွင့်လိုင်စင်ကို သွယ်ဝိုက်၍ ရမရကိုလည်း မဆုံးဖြတ်ရသေးပါ။ Apache 2.0 တွင် ပံ့ပိုးသူတစ်ဦးစီထံမှ တိကျသော၊ မူပိုင်ခွင့်ကင်းလွတ်သော မူပိုင်ခွင့်လိုင်စင်ကို ထည့်သွင်းထားပြီး လက်စားချေသည့်စာပိုဒ်လည်း ပါဝင်သည်- လက်ရာသည် ချိုးဖောက်သည်ဟု စွပ်စွဲသည့် မူပိုင်ခွင့်တရားစွဲဆိုမှုကို ယူဆောင်လာပြီး သင့်မူပိုင်ခွင့်လိုင်စင်ကို ရပ်စဲသည်။ GPLv3 တွင် နှိုင်းယှဉ်နိုင်သော ထောက်ပံ့ငွေနှင့် ၎င်း၏ကိုယ်ပိုင် မူပိုင်ခွင့်ပြဋ္ဌာန်းချက်များ ပါဝင်သည်။

မူပိုင်ခွင့်ရှိသော ကုမ္ပဏီများအတွက် သက်ရောက်မှုနှစ်ခု။ သင့်အင်ဂျင်နီယာများသည် Apache သို့မဟုတ် GPLv3 လိုင်စင်ရ ပရောဂျက်များတွင် ပါဝင်ပါက၊ သင်သည် သင့်ကိုယ်ပိုင် မူပိုင်ခွင့်များအောက်တွင် လိုင်စင်များ ပေးအပ်နေခြင်းဖြစ်သည်။ ထို့အပြင် သင်အသုံးပြုသော Apache လိုင်စင်ရ အစိတ်အပိုင်းများပေါ် မူတည်၍ ကုမ္ပဏီတစ်ခုကို မူပိုင်ခွင့်များ အခိုင်အမာပြောဆိုပါက၊ လက်စားချေမှုသည် သင်အားကိုးရသော လိုင်စင်ကို ဆုံးရှုံးစေနိုင်သည်။

EUPL နှင့် နယ်သာလန် အစိုးရကဏ္ဍ

၂၀၁၇ ခုနှစ် မေလတွင် အကောင်အထည်ဖော်သည့် ဆုံးဖြတ်ချက်ဖြင့် ဥရောပကော်မရှင်မှ အတည်ပြုခဲ့သော European Union Public License ဗားရှင်း 1.2 သည် ထူးခြားသော အင်္ဂါရပ်သုံးရပ်ပါရှိသော OSI မှ အတည်ပြုထားသော copyleft လိုင်စင်တစ်ခုဖြစ်သည်။

• ဘာသာစကား။ ၎င်းသည် EU ၏ တရားဝင်ဘာသာစကားများဖြင့် ရှိပြီး အတည်ပြုထားသော ဗားရှင်းအားလုံးတွင် တန်ဖိုးတူညီသောကြောင့် ဒတ်ချ်အာဏာပိုင်တစ်ဦးသည် ဒတ်ချ်ဘာသာဖြင့် စာချုပ်ချုပ်ဆိုနိုင်သည်။
• သဟဇာတ။ နောက်ဆက်တွဲတွင် တွဲဖက်အသုံးပြုနိုင်သော လိုင်စင်များ — GPLv2 နှင့် v3၊ AGPLv3၊ LGPL၊ MPL 2၊ EPL 1.0၊ OSL နှင့် CeCILL — တို့ကို စာရင်းပြုစုထားပြီး EUPL ကုဒ်နှင့် စာရင်းဝင်လိုင်စင်အောက်ရှိ ကုဒ်ကို ပေါင်းစပ်ထားသော derivative work တစ်ခုကို ထိုလိုင်စင်အောက်တွင် ဖြန့်ဝေခွင့်ပြုသည်။
• လက်လှမ်းမမီ။ ၎င်း၏ ဖြန့်ဖြူးမှု အဓိပ္ပာယ်ဖွင့်ဆိုချက်တွင် အလုပ်ကို အွန်လိုင်း သို့မဟုတ် အော့ဖ်လိုင်းတွင် ရရှိနိုင်အောင် ပြုလုပ်ခြင်း ပါဝင်သည်။ သို့မဟုတ် ၎င်း၏ မရှိမဖြစ် လုပ်ဆောင်ချက်များကို ဝင်ရောက်ခွင့်ပေးခြင်းနှင့် အပိုဒ် ၅ EUPL သည် copyleft တာဝန်ဝတ္တရားကို ထိုလုပ်ဆောင်ချက်ကို ပေးဆောင်သည့် အဝေးထိန်း အပြန်အလှန်ဆက်သွယ်မှုအထိ သယ်ဆောင်ထားသည်။ ထို့ကြောင့် ၎င်းသည် GPL တွင် မပါဝင်သော နည်းလမ်းဖြင့် ဝန်ဆောင်မှုတစ်ခုအဖြစ် ပေးပို့ထားသော software သို့ ရောက်ရှိသည်။

ဒတ်ခ်ျအစိုးရကဏ္ဍဖောက်သည်တစ်ဦးသည် EUPL ကို ဥပဒေထက် မူဝါဒကိစ္စတစ်ခုအဖြစ် လိုအပ်နိုင်ပါသည်။ Interoperable Europe Act, Regulation (EU) 2024/903 သည် အစိုးရကဏ္ဍအဖွဲ့အစည်းများအား open source ကဲ့သို့သော ကန့်သတ်ချက်ရှိသော လိုင်စင်စည်းကမ်းချက်များမပါဘဲ interoperability solution များကို ဦးစားပေးရန် ညွှန်ကြားထားပြီး၊ ၎င်းသည် ညီမျှသည်။ အမျိုးသားအဆင့်တွင် open source ၏ မူသည် ဥပဒေပေါ်တွင်မဟုတ်ဘဲ အစိုးရအဖွဲ့၏ ဆုံးဖြတ်ချက်များနှင့် မူဝါဒလမ်းကြောင်းများပေါ်တွင် မူတည်သည်- Wet digitale overheid သည် ဒစ်ဂျစ်တယ်အထောက်အထားအခြေခံအဆောက်အအုံကို လွယ်ကူချောမွေ့စေသော်လည်း source code အားလုံးကို ထုတ်ဝေရန် ပြဋ္ဌာန်းနိုင်သော တာဝန်မရှိပါ။ တင်ဒါစာရွက်စာတမ်းများကို ဖတ်ရှုပါ- EUPL လိုအပ်ချက်သည် သင်၏ ပေးပို့ရမည့်အရာကို ချည်နှောင်ထားပြီး သင်ပြန်လည်အသုံးပြုရန် ရည်ရွယ်ထားသော proprietary code နှင့် မကိုက်ညီနိုင်သည်။

လက်တွေ့အကောင်အထည်ဖော်မှု

ဘယ်သူတရားစွဲဆိုနိုင်လဲ။ မူပိုင်ခွင့်ရှိသူ — တစ်ဦးချင်းပံ့ပိုးသူများ သို့မဟုတ် ဖောင်ဒေးရှင်း သို့မဟုတ် အပ်နှင်းထားသော မူပိုင်ခွင့်ကို ပိုင်ဆိုင်သော ကုမ္ပဏီ။ အပိုင်းပိုင်းကွဲနေသော စာရေးသူဖြစ်မှုသည် လက်တွေ့ကျသော အတားအဆီးဖြစ်သည်- တောင်းဆိုသူသည် ပြဿနာရှိသော ကုဒ်၏ပိုင်ဆိုင်မှုကို သက်သေပြရမည်။ virtualisation vendor ကို kernel developer ၏ စာရေးသူဖြစ်မှုအထောက်အထားမရှိခြင်းကြောင့် တောင်းဆိုမှု မအောင်မြင်ခဲ့သည့် အထင်ရှားဆုံး ဥရောပ GPL အမှုတွင် ရှုံးနိမ့်ခဲ့သည် (LG Hamburg ၈ ဇူလိုင် ၂၀၁၆၊ ၃၁၀ O ၈၉/၁၅; OLG Hamburg ၂၈ ဖေဖော်ဝါရီ ၂၀၁၉၊ ၅ U ၁၄၆/၁၆)။

တရားရုံးက ချမှတ်ထားတဲ့ ပြဋ္ဌာန်းချက်။ ဂျာမန်တရားရုံးများသည် open source လိုင်စင်များသည် တရားဝင်ပြီး ချိုးဖောက်မှုသည် ဖြန့်ဖြူးမှုကို တရားမဝင်ဖြစ်စေကြောင်း အကြိမ်ကြိမ်လက်ခံခဲ့ပြီး၊ ပထမဆုံး GPL တားမြစ်မိန့် (LG München I 19 May 2004, 21 O 6123/04) မှစတင်၍။ အမေရိကန် ဖက်ဒရယ်တရားရုံးသည် Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008) တွင် အလားတူ နိဂုံးချုပ်ခဲ့သည်- လိုင်စင်စည်းကမ်းချက်များသည် ခွင့်ပြုချက်၏ အတိုင်းအတာအပေါ် အခြေအနေများဖြစ်ပြီး ပဋိညာဉ်များသက်သက်မဟုတ်ဘဲ၊ ထို့ကြောင့် ချိုးဖောက်မှုသည် မူပိုင်ခွင့်တောင်းဆိုမှုနှင့် တားမြစ်မိန့်သက်သာခွင့်ကို ထောက်ခံသည်။ အမေရိကန် တရားစွဲဆိုမှုသည် downstream recipient သည် GPL ကို third-party beneficiary အဖြစ် ပြဋ္ဌာန်းနိုင်မလားဆိုသည်ကို စူးစမ်းလေ့လာနေသည်။ ၎င်းသည် ကယ်လီဖိုးနီးယားပြည်နယ် အမြင့်ဆုံးတရားရုံးတွင် Software Freedom Conservancy v Vizio တွင် အဓိကမေးခွန်းဖြစ်သည် - third-party beneficiary များအနေဖြင့် GPLv2 အောက်ရှိ source code ကို ထုတ်ပြန်ရန် စားသုံးသူများက တောင်းဆိုနိုင်မလားဆိုသည့် အဓိကမေးခွန်းဖြစ်သည်။ ၂၀၂၅ ခုနှစ် ဒီဇင်ဘာလ ၂၃ ရက်နေ့တွင် တရားရုံးက အကျဉ်းချုပ်ဆုံးဖြတ်ချက်နှင့် ပတ်သက်၍ အချက်တစ်ချက်ကို ဆုံးဖြတ်ခဲ့ပြီး GPLv2 နှင့် LGPLv2.1 တို့သည် စက်ပစ္စည်းပေါ်တွင် ၎င်း၏လုပ်ဆောင်ချက်ကို အပြည့်အဝပြန်လည်ထည့်သွင်းနိုင်သည့် အရင်းအမြစ်ထက် အခြားနေရာတွင် အသုံးပြုရန် ရယူပြီး ပြန်လည်လုပ်ဆောင်နိုင်သော အရင်းအမြစ်များ လိုအပ်ကြောင်း ဆုံးဖြတ်ခဲ့သည်။ ပြင်ပအကျိုးခံစားခွင့်ရှိသူ မေးခွန်းကိုယ်တိုင်က တစ်ကြိမ်ထက်ပို၍ ရွှေ့ဆိုင်းထားသော ရုံးတင်စစ်ဆေးမှုအတွက် ကျန်ရှိနေခဲ့သည်။ ၎င်းသည် ကယ်လီဖိုးနီးယား စာချုပ်ဥပဒေမေးခွန်းတစ်ခုဖြစ်သောကြောင့် နယ်သာလန်တွင် မည်သည့်အရာကိုမျှ ချည်နှောင်ထားခြင်းမရှိပါ။ ၎င်းပြောင်းလဲမှုမှာ တိုင်ကြားနိုင်သူအရေအတွက်ဖြစ်သည်။

ဒတ်ခ်ျတရားရုံးက ဘယ်လိုချဉ်းကပ်မလဲ။ Auteurswet အရ မူပိုင်ခွင့်ချိုးဖောက်မှုအနေဖြင့်- တောင်းဆိုသူသည် ပိုင်ဆိုင်မှုနှင့် မျိုးပွားခြင်း သို့မဟုတ် ဆက်သွယ်မှုကို သက်သေပြသည်။ တရားခံသည် လိုင်စင်ကို ရုပ်သိမ်းသည်။ တောင်းဆိုသူက ၎င်း၏စည်းကမ်းချက်များနှင့် မကိုက်ညီကြောင်း ဖြေကြားသောကြောင့် ခုခံချေပမှု မအောင်မြင်ပါ။ အပိုဒ် ၆:၂၆၅ BW အရ စာချုပ်ဆိုင်ရာ ကုစားနည်းများသည် တစ်ပြိုင်နက်တည်း လည်ပတ်နေသော်လည်း မူပိုင်ခွင့်သည် ပိုမိုအားကောင်းသော လမ်းကြောင်းဖြစ်သည်။

ကုစားနည်းများ။ ပုဒ်မ 3:296 BW အရ တားမြစ်မိန့်၊ ပုံမှန်အားဖြင့် ဒဏ်ကြေးပေးဆောင်ရမည်ဖြစ်ပြီး အကျဉ်းချုပ်တရားစွဲဆိုမှုများတွင် ရရှိနိုင်သည်။ ပုဒ်မ 27 Aw အရ ပျက်စီးဆုံးရှုံးမှုများနှင့် ပုဒ်မ 27a Aw အရ အမြတ်ငွေစာရင်း၊ ပုဒ်မ 28 Aw အရ ပြန်လည်သိမ်းဆည်းခြင်း၊ အပ်နှံခြင်း သို့မဟုတ် ဖျက်ဆီးခြင်း၊ နှင့် ပုဒ်မ 1019h Rv အရ ကျိုးကြောင်းဆီလျော်ပြီး အချိုးကျသော တရားရေးကုန်ကျစရိတ်များကို အပြည့်အဝပြန်လည်ရရှိခြင်း။ ဆော့ဖ်ဝဲကို အခမဲ့ဖြန့်ဝေသည့်အခါ ဆုံးရှုံးမှုကို တွက်ချက်ရန်ခက်ခဲပြီး ဂျာမန်အယူခံတရားရုံးက တားမြစ်ချက်ကို ထောက်ခံနေစဉ်တွင် ပျက်စီးဆုံးရှုံးမှုပေးရန် ငြင်းဆိုခဲ့သည် (OLG Hamm 13 June 2017, 4 U 72/16)။ ပျက်စီးဆုံးရှုံးမှုမှာ ရှားရှားပါးပါးသာဖြစ်သည်- တားမြစ်မိန့်၊ ပြန်လည်သိမ်းဆည်းခြင်း၊ ကုန်ကျစရိတ်အမိန့်နှင့် သင်ထုတ်ဝေရန် ရည်ရွယ်ထားသည့် အရင်းအမြစ်ကို ထုတ်ဝေရခြင်းတို့ဖြစ်သည်။

လိုက်နာမှုပြဿနာတစ်ခုကို သင်တွေ့ရှိသောအခါ

ရှာဖွေတွေ့ရှိမှုသည် များသောအားဖြင့် ဖောက်သည်၏ လုံခြုံရေးမေးခွန်းလွှာ၊ စစ်ဆေးနေစဉ် စကင်ဖတ်ခြင်း သို့မဟုတ် မူပိုင်ခွင့်ရှိသူထံမှ စာတစ်စောင်မှ ရရှိလေ့ရှိသည်။ ထို့နောက် ပြုပြင်မွမ်းမံခြင်းသည် အောက်ပါအတိုင်း လုပ်ဆောင်သည်။ ထိတွေ့မှုပြင်းထန်ပါက ထိခိုက်ခံရသော တည်ဆောက်မှု၏ ဖြန့်ဝေမှုကို ရပ်တန့်ပါ။ မည်သည့်အစိတ်အပိုင်း၊ မည်သည့်ဗားရှင်း၊ မည်သည့်လိုင်စင်၊ မည်သည့်ထုတ်ကုန်များနှင့် မည်သည့်ကာလအတွင်း ထုတ်ဝေမှုများကို သတ်မှတ်ပါ။ လိုင်စင်သည် အမှန်တကယ် လိုအပ်သည်များကို တွက်ချက်ပါ - မကြာခဏဆိုသလို ရင်းမြစ်ထုတ်ပြန်ချက်ထက် အထောက်အထားဖိုင်တစ်ခု။ ရှေးဟောင်းပစ္စည်းများကို ပြင်ဆင်ပါ- အသိပေးချက်များ၊ လိုင်စင်စာသားများ၊ တည်ဆောက်မှုဇာတ်ညွှန်းများအပါအဝင် သက်ဆိုင်ရာရင်းမြစ်အပြည့်အစုံနှင့် အသုံးပြုသည့်နေရာတွင် ရေးသားထားသော ကမ်းလှမ်းချက်။ လိုက်နာသော ထုတ်ပြန်ချက်တစ်ခုကို ပေးပို့ပြီးနောက် သင်လုပ်သင့်မလုပ်သင့်ကို ငြင်းခုံမည့်အစား သင်ဘာလုပ်ခဲ့ကြောင်း မူပိုင်ခွင့်ရှိသူအား ပြောပြပါ။

GPLv3 နှင့် AGPLv3 အောက်တွင် cure window သည် မြန်နှုန်းကို တရားဝင်တန်ဖိုးပေးသော်လည်း GPLv2 အောက်တွင် cure right မရှိပါ၊ ထို့ကြောင့် အများစုသော အကောင်အထည်ဖော်မှုသည် ညှိနှိုင်းထားသော လိုက်နာမှုဆိုင်ရာ ကတိကဝတ်ဖြင့် အဆုံးသတ်သည်။ အထူးအခွင့်အရေးသည် အတွင်းပိုင်းအင်ဂျင်နီယာအစီရင်ခံစာနှင့် မဟုတ်ဘဲ သင့်ရှေ့နေထံမှ အကြံဉာဏ်နှင့် ဆက်စပ်နေကြောင်းလည်း သတိပြုပါ။

M&A တွင် open source နှင့် due diligence

ဆော့ဖ်ဝဲလ်ရယူမှုတွင်၊ open source သည် စံသတ်မှတ်ထားသော ကြိုးစားအားထုတ်မှုလုပ်ငန်းစဉ်တစ်ခုဖြစ်ပြီး အဓိကထုတ်ကုန်ရှိ ထုတ်ဖော်မထားသော copyleft အစိတ်အပိုင်းသည် အရောင်းအဝယ်တစ်ခုကို အမှန်တကယ်ရွှေ့လျားစေသည့် တွေ့ရှိချက်အနည်းငယ်ထဲမှ တစ်ခုဖြစ်သည်- ထုတ်ကုန်ကို ၎င်း၏ရင်းမြစ်ကို မထုတ်ပြန်ဘဲ ဖြန့်ဝေ၍မရပါက၊ ဝယ်သူသည် ဈေးနှုန်းသတ်မှတ်ထားသော ပိုင်ဆိုင်မှုနှင့် မတူညီသောပိုင်ဆိုင်မှုကို ရယူနေခြင်းဖြစ်သည်။

codebase scan၊ လိုင်စင်ပါ component inventory နှင့် contributor နှင့် contractor arrangements များအကြောင်း မေးခွန်းများကို မျှော်လင့်ပါ။ ပုံမှန်ရလဒ်များမှာ သီးခြားလျော်ကြေးပေးခြင်း၊ ထိန်းသိမ်းမှုဆိုင်းငံ့ထားသော ပြုပြင်မှု၊ ဖယ်ရှားရန် လိုအပ်သော condition precedent သို့မဟုတ် bespoke open source warranty တို့ဖြစ်သည်။ ရောင်းသူများသည် ဦးစွာ scan လုပ်သင့်သည်- သင်ထုတ်ဖော်သောတွေ့ရှိချက်များသည် ညှိနှိုင်းမှုတစ်ခုဖြစ်ပြီး ဝယ်သူ၏အကြံပေး၏တွေ့ရှိချက်များသည် leverage ဖြစ်သည်။ ဝယ်သူများသည် “ကုမ္ပဏီသည် ၎င်း၏ IP ကိုပိုင်ဆိုင်သည်” မဟုတ်ဘဲ မည်သည့်ထုတ်ကုန်တွင်မျှ proprietary source code ထုတ်ဖော်ရန် လိုအပ်သော open source မပါဝင်ကြောင်း ကိုယ်စားပြုမှုကို ရှာဖွေသင့်သည်။

ပစ္စည်းဥပဒေကြမ်း၊ စကင်ဖတ်ခြင်းနှင့် ဆိုက်ဘာခံနိုင်ရည်ရှိမှုအက်ဥပဒေ

ဆော့ဖ်ဝဲလ် ပစ္စည်းစာရင်းဆိုသည်မှာ ဗားရှင်းများနှင့် လိုင်စင်များပါရှိသော ထုတ်ကုန်၏ အစိတ်အပိုင်းများစာရင်းဖြစ်သည်။ မကြာသေးမီကအထိ စာချုပ်စာတမ်းသက်သက်ဖြင့်သာ မှတ်ပုံတင်ထားသော်လည်း ယခုအခါ စည်းမျဉ်းစည်းကမ်းဆိုင်ရာ အခြေအနေသို့ ရောက်ရှိနေပြီဖြစ်သည်။

ဆိုက်ဘာခံနိုင်ရည်ရှိမှုအက်ဥပဒေ၊ စည်းမျဉ်း (EU) 2024/2847 သည် ၂၀၂၄ ခုနှစ် ဒီဇင်ဘာလ ၁၀ ရက်နေ့တွင် အသက်ဝင်ခဲ့ပြီး အဆင့်လိုက်ဖြစ်သည်။ ၎င်းသည် ထုတ်ကုန်ထက် အဖွဲ့အစည်းကို ကိုင်တွယ်ဖြေရှင်းသည့် ဒတ်ချ်ဆိုက်ဘာလုံခြုံရေးအက်ဥပဒေ နှင့်အတူ တည်ရှိသည် ။ တက်ကြွစွာအသုံးချထားသော အားနည်းချက်များနှင့် ပြင်းထန်သောဖြစ်ရပ်များအတွက် အစီရင်ခံရန်တာဝန်ဝတ္တရားများသည် အပိုဒ် ၁၄ CRA တွင် ၂၀၂၆ ခုနှစ် စက်တင်ဘာလ ၁၁ ရက်နေ့မှစ၍ အကျုံးဝင်သည်။ ၂၀၂၆ ခုနှစ် ဇွန်လ ၁၁ ရက်နေ့မှစ၍ ကိုက်ညီမှုအကဲဖြတ်အဖွဲ့များ၏ အကြောင်းကြားခြင်းဆိုင်ရာ ပြဋ္ဌာန်းချက်များ၊ ၂၀၂၇ ခုနှစ် ဒီဇင်ဘာလ ၁၁ ရက်နေ့မှစ၍ စည်းမျဉ်းအပြည့်အစုံ (အပိုဒ် ၇၁ CRA)။ နောက်ဆက်တွဲ I CRA သည် ထုတ်လုပ်သူများအား ထုတ်ကုန်ရှိ အစိတ်အပိုင်းများကို ဖော်ထုတ်ပြီး မှတ်တမ်းတင်ရန် လိုအပ်ပြီး အနည်းဆုံး ထိပ်တန်းအဆင့် မှီခိုမှုများကို လွှမ်းခြုံထားသည့် အသုံးများပြီး စက်ဖြင့်ဖတ်နိုင်သော ပုံစံဖြင့် ဆော့ဖ်ဝဲလ်ပစ္စည်းစာရင်းကို ရေးဆွဲခြင်းဖြင့် လိုအပ်သည်။ ၎င်းကို ထုတ်ဝေရန် မလိုအပ်ပါ။ ဈေးကွက်စောင့်ကြည့်ရေးအာဏာပိုင်များက ၎င်းကို တောင်းဆိုနိုင်သည်။

စီးပွားဖြစ်လုပ်ဆောင်ချက်ပြင်ပတွင် ထောက်ပံ့ပေးသော အခမဲ့နှင့် open source software သည် CRA ၏ ပြင်ပတွင် ကျရောက်သည်။ စည်းမျဉ်းတွင် စီးပွားဖြစ်လုပ်ဆောင်ချက်များအတွက် ရည်ရွယ်ထားသော open source software ဖွံ့ဖြိုးတိုးတက်ရေးကို စဉ်ဆက်မပြတ်ပံ့ပိုးမှုပေးသည့် open-source software steward — စီးပွားဖြစ်လုပ်ဆောင်ချက်များအတွက် ရည်ရွယ်ထားသော open source software ဖွံ့ဖြိုးတိုးတက်ရေးကို စဉ်ဆက်မပြတ်ပံ့ပိုးမှုပေးသည့် တရားဝင်ပုဂ္ဂိုလ် — ကို မိတ်ဆက်ပေးသည်။ 24 CRA: မှတ်တမ်းတင်ထားသော ဆိုက်ဘာလုံခြုံရေးမူဝါဒ၊ ဈေးကွက်စောင့်ကြည့်ရေးအာဏာပိုင်များနှင့် ပူးပေါင်းဆောင်ရွက်မှုနှင့် အစီရင်ခံခြင်း။ သင်သည် open source ကို စီးပွားဖြစ်ပြုလုပ်ပါက သို့မဟုတ် အခြားသူများ စီးပွားဖြစ်ပြုလုပ်သော ပရောဂျက်တစ်ခုကို ရန်ပုံငွေထောက်ပံ့ပါက သင်မည်သည့်အခန်းကဏ္ဍတွင် တာဝန်ထမ်းဆောင်သည်ကို သတ်မှတ်ပါ။ ကော်မရှင်သည် ၂၀၂၆ ခုနှစ် ဇူလိုင်လ ၂၇ ရက်နေ့တွင် ၎င်း၏ပထမဆုံးလမ်းညွှန်ချက်ကို အတည်ပြုခဲ့သည်- ဆက်သွယ်ရေး C(2026) 5252 နှင့် တွဲဖက်ထားသော Cyber ​​Resilience Act (CRA) အသုံးချမှုဆိုင်ရာ ကော်မရှင်လမ်းညွှန်ချက်၊ အခမဲ့နှင့် open source software သည် မည်သည့်အရာများအတွင်း ကျရောက်သည်ကို ကိုင်တွယ်သည်။ ဆော့ဖ်ဝဲလ်ပစ္စည်းစာရင်းအတွက် ပုံစံတစ်ခုကို သတ်မှတ်ပေးသည့် အကောင်အထည်ဖော်မှုအက်ဥပဒေကိုမျှ လက်ခံကျင့်သုံးခြင်းမရှိသောကြောင့် စည်းမျဉ်း၏ကိုယ်ပိုင်စံနှုန်း — အသုံးများသော၊ စက်ဖြင့်ဖတ်နိုင်သောပုံစံ — သည် ယခုအချိန်အထိ အတိုင်းအတာတစ်ခုအဖြစ် ရှိနေသေးသည်။

CI မှာ လုပ်ဆောင်တဲ့ software ဖွဲ့စည်းပုံ ခွဲခြမ်းစိတ်ဖြာမှုက လိုက်နာမှု၊ လိုင်စင် ပြန်လည်သုံးသပ်မှုနဲ့ စစ်ဆေးမှုတို့ကို တစ်ပြိုင်နက်တည်း ဆောင်ရွက်ပေးမယ့် စာရင်းကို ဖန်တီးပေးပါတယ်။ အဲဒီလို tool တွေက ရောင်းချထားတဲ့ code ကို လွဲချော်စေပြီး၊ dual-license ပရောဂျက်တွေကို မှားယွင်းစွာ ခွဲခြားသတ်မှတ်ပြီး လိုင်စင်ရဲ့ အခြေအနေတွေကို မဖတ်နိုင်ပါဘူး- output ကို ပြန်လည်သုံးသပ်မှုရဲ့ အစအဖြစ် သဘောထားပြီး ပြန်လည်သုံးသပ်မှုအဖြစ် မဟုတ်ဘဲ ရှုမြင်ပါတယ်။

ကိုယ်ပိုင်ကုဒ်ကိုထုတ်ဝေပါက- CLA များနှင့် DCO

ကုဒ်ကိုထုတ်ဝေပြီး ပြင်ပပံ့ပိုးကူညီမှုများကိုလက်ခံသော ကုမ္ပဏီတစ်ခုသည် ၎င်းပေါင်းစည်းထားသည့်အရာများအတွက် အခွင့်အရေးများရှိကြောင်း သိရှိရမည်။ ပံ့ပိုးကူညီသူလိုင်စင်သဘောတူညီချက် သည် ပရောဂျက်နှင့် ပံ့ပိုးကူညီသူအကြား စာချုပ်တစ်ခုဖြစ်ပြီး မူရင်းနှင့် အခွင့်အာဏာအတွက် အာမခံချက်များပါရှိသော ကျယ်ပြန့်သော မူပိုင်ခွင့်လိုင်စင်နှင့် အမြန်မူပိုင်ခွင့်လိုင်စင်ကို ပေးအပ်လေ့ရှိသည်။ ၎င်းသည် ကုမ္ပဏီတစ်ခုအား ၎င်း၏ပရောဂျက်ကို နောက်ပိုင်းတွင် ပြန်လည်လိုင်စင်ချထားပေးခြင်း သို့မဟုတ် open source တစ်ခုနှင့်အတူ စီးပွားဖြစ်လိုင်စင်များကို ကမ်းလှမ်းခွင့်ပြုသည့်အရာဖြစ်သည်။ ၎င်း၏ကုန်ကျစရိတ်သည် ပွတ်တိုက်မှုဖြစ်သည်။

Linux kernel နှင့် အခြားပရောဂျက်များစွာမှ အသုံးပြုသော Developer Certificate of Origin သည် လိုင်စင်ထောက်ပံ့ငွေမဟုတ်ဘဲ ပံ့ပိုးသူသည် ပရောဂျက်၏လိုင်စင်အောက်တွင် ကုဒ်ကို တင်သွင်းနိုင်စေရန် commit တစ်ခုချင်းစီတွင် sign-off line အဖြစ်ထည့်သွင်းထားသော ပေါ့ပါးသော အသိအမှတ်ပြုလက်မှတ်တစ်ခုဖြစ်သည်။ ဝန်ထုပ်ဝန်ပိုးနည်းပါးပြီး အကာအကွယ်နည်းပါးသည်- မူပိုင်ခွင့်လိုင်စင်မရှိ၊ ပြန်လည်လိုင်စင်မလိုအပ်ပါ။

နှစ်ထပ်လိုင်စင် သို့မဟုတ် အနာဂတ်တွင် လိုင်စင်ပြန်လည်ရရှိခြင်းသည် ဖြစ်နိုင်ခြေရှိပါက CLA ကိုသုံးပါ။ ပရောဂျက်သည် စစ်မှန်သော commons တစ်ခုဖြစ်ပါက DCO သည် များသောအားဖြင့် လုံလောက်ပါသည်။ မည်သို့ပင်ဖြစ်စေ၊ သင်၏ အလုပ်ခန့်ထားမှုနှင့် ကန်ထရိုက်တာ သဘောတူညီချက်များတွင် သင်၏လူများရေးသားသော ကုဒ်တွင် မူပိုင်ခွင့်ကို သတ်မှတ်ပေးထားကြောင်း သေချာပါစေ။

လက်တွေ့ကျသော မူဝါဒစစ်ဆေးရမည့်စာရင်း

• ထုတ်ကုန်တစ်ခုလျှင် အစိတ်အပိုင်းစာရင်းကို ထုတ်ပြီး လက်ဖြင့်မဟုတ်ဘဲ build pipeline တွင် ထုတ်ဝေပါ။
• အတွင်းပိုင်းမူဝါဒတစ်ခုထုတ်ဝေပါ- ခွင့်ပြုထားသောစာရင်း၊ တားမြစ်ထားသောစာရင်းနှင့် အခြားအရာအားလုံးအတွက် ခွင့်ပြုချက်လမ်းကြောင်း။
• ဖြန့်ဖြူးမှုအဖြစ် ရေတွက်သည့်အရာကို ရေးသား၍ အဓိပ္ပာယ်ဖွင့်ဆိုပါ - on-premise installs၊ appliances၊ containers၊ SDKs၊ မိုဘိုင်းအက်ပ်များ၊ firmware။
• ထုတ်ကုန်တိုင်းနှင့်အတူ ထုတ်ပေးထားသော ရည်ညွှန်းချက်ဖိုင်ကို ပေးပို့ပါ။
• လိုင်စင်ရွေးချယ်မှုများကို ဒီဇိုင်းအချိန်တွင် အတည်ပြုပါ၊ အစိတ်အပိုင်းတစ်ခုကို ရွေးချယ်သည့်အခါတွင်သာ အတည်ပြုပါ၊ ဖြန့်ချိချိန်တွင် မဟုတ်ပါ။
• ပါဝင်ပတ်သက်သော မူပိုင်ခွင့်ထောက်ပံ့ငွေများကို ထည့်သွင်းစဉ်းစားလျှင် ပြင်ပပရောဂျက်များသို့ ပံ့ပိုးကူညီမှုများသည် ခွင့်ပြုချက်လိုအပ်ခြင်း ရှိ၊ မရှိ ဆုံးဖြတ်ပြီး ပထမဆုံး ပြင်ပပံ့ပိုးကူညီမှုမပြုမီ CLA သို့မဟုတ် DCO ကို ရွေးချယ်ပါ။
• IP အာမခံများ၊ လျော်ကြေးများနှင့် escrow စည်းကမ်းချက်များကို ထုတ်ကုန်တွင် အမှန်တကယ်ရှိသော open source နှင့် ချိန်ညှိပါ။
• ရန်ပုံငွေရှာဖွေခြင်း သို့မဟုတ် ရောင်းချခြင်းလုပ်ငန်းစဉ်မတိုင်မီ ပြန်လည်သုံးသပ်ချက်ကို လုပ်ဆောင်ပါ၊ လုပ်ငန်းစဉ်အတွင်းတွင် မဟုတ်ပါ။

Law & More ဆော့ဖ်ဝဲကုမ္ပဏီများနှင့် ၎င်းတို့၏ ရင်းနှီးမြှုပ်နှံသူများကို အကြံပေးသည် Eindhoven နှင့် Amsterdam open source လိုက်နာမှု၊ လိုင်စင်ပြန်လည်သုံးသပ်ခြင်း၊ ပံ့ပိုးကူညီသူအစီအစဉ်များနှင့် ငွေပေးငွေယူတစ်ခုတွင် open source workstream တို့အကြောင်း။