ڊچ ۽ EU قانون جي تحت اوپن سورس سافٽ ويئر لائسنس

تقريبن هر ڪمرشل سافٽ ويئر پراڊڪٽ ۾ اوپن سورس جزا هوندا آهن، عام طور تي سوين، جيڪي وڪيلن جي بدران ڊولپرز پاران چونڊيا ويندا آهن. اهو هڪ مسئلو بڻجي ويندو آهي جڏهن ڪو به اهو نٿو چئي سگهي ته ڪهڙا لائسنس لاڳو ٿين ٿا، انهن کي ڇا گهربل آهي، ۽ ڇا پراڊڪٽ ان جي تعميل ڪري ٿو. هي آرٽيڪل وضاحت ڪري ٿو ته اوپن سورس لائسنس ڊچ ۽ EU قانون جي تحت ڪيئن ڪم ڪن ٿا، خطرو ڪٿي آهي، ۽ ڇا هجڻ گهرجي.

قانوني لحاظ کان اوپن سورس لائسنس ڇا آهي؟

هڪ اوپن سورس لائسنس هڪ ڪاپي رائيٽ لائسنس آهي جيڪو شرطن جي تابع ڏنو ويندو آهي. اهو ڪا دستبرداري ناهي، عوامي ڊومين لاءِ وقف ناهي، حقن جي ڇڏڻ ناهي، ۽ انهي لحاظ کان اهو ڊچ قانون تحت ڪنهن ٻئي سافٽ ويئر لائسنس وانگر ڪم ڪري ٿو . ليکڪ آرٽيڪل 1 او ۽ آرٽ تحت ڪاپي رائيٽ برقرار رکي ٿو. 10 او، جيڪو ڪمپيوٽر پروگرامن کي ڪم جي طور تي محفوظ ڪري ٿو، ۽ لائسنس اهڙن ڪمن جي اجازت ڏئي ٿو جيڪي ٻي صورت ۾ آرٽيڪل 12 او ۽ آرٽ تحت خاص حقن جي خلاف ورزي ڪندا. 13 او.

نتيجو تعريف کان وڌيڪ اهم آهي. تعميل ڪريو، ۽ توهان جي ڪاپي ڪرڻ ۽ ورڇ قانوني آهي. تعميل ڪرڻ ۾ ناڪامي، ۽ اجازت توهان جي ڪيل ڪم کي ڍڪي نه ٿي: توهان جو استعمال ڪاپي رائيٽ جي خلاف ورزي آهي، معاهدي جي ڀڃڪڙي ناهي. گھڻا ڪاپي ليفٽ لائسنس ڀڃڪڙي تي خودڪار طريقي سان ختم ڪندي هن کي مضبوط ڪن ٿا — GPLv2 بغير ڪنهن علاج جي مدت جي، جڏهن ته GPLv3 ۽ AGPLv3 حقن کي بحال ڪن ٿا جيڪڏهن ڀڃڪڙي نوٽيس کان پوءِ هڪ مقرر ڪيل ونڊو اندر علاج ڪئي وڃي.

ڊچ عدالتون هن دليل کي لاڳو ڪن ٿيون. آر بي ۾. Amsterdam 22 سيپٽمبر 2020، ECLI:NL:RBAMS:2020:4717، هڪ ورهائيندڙ جنهن فورڪڊ ڪوڊ بيس مان لائسنس ٽيڪسٽ ۽ ڪاپي رائيٽ نوٽيس هٽايو هو، ان کي پنهنجي اجازت وڃائي ۽ خلاف ورزي ڪرڻ جو ذميوار قرار ڏنو ويو. نئين ڪوڊ جي وڏي مقدار کي شامل ڪرڻ سان هڪ آزاد ڪم پيدا نه ٿيو: اصل سڃاڻپ طور تي موجود رهيو، تنهن ڪري ذميواريون ان سان گڏ سفر ڪيون.

ٻہ خاندان: اجازت ڏيندڙ ۽ ڪاپي ليفٽ

اجازت ڏيندڙ لائسنس - MIT، BSD لائسنس، Apache 2.0 - استعمال، ترميم ۽ ٻيهر ورڇ جي اجازت ڏين ٿا، بشمول بند ذريعن جي شين جي اندر، بشرطيڪ توهان ڪاپي رائيٽ نوٽيس ۽ لائسنس ٽيڪسٽ محفوظ رکون.

ڪاپي ليفٽ لائسنس جي ضرورت آهي ته جڏهن توهان سافٽ ويئر، يا ان تي ٺهيل ڪا شيءِ ورهائيندا آهيو، ته توهان ساڳئي لائسنس تحت ائين ڪندا آهيو ۽ لاڳاپيل ذريعو دستياب ڪندا آهيو. اهي پهچ ۾ مختلف آهن.

ڪاپي ليفٽ ٽرگر ۽ لنڪنگ سوال

ڪاپي ليفٽ ذميواريون ورڇ تي ڀاڙين ٿيون، استعمال تي نه. هڪ ڪمپني جيڪا اندروني طور تي GPL سافٽ ويئر هلائي رهي آهي، جيتوڻيڪ تمام گهڻي تبديل ٿيل هجي، ڪجهه به ورهائي نه ٿي ۽ نه ئي ڪجهه قرضدار آهي. "ڇا اسان ورهايو آهي؟" هميشه پهريون سوال آهي، ۽ اهو ئي سبب آهي ته ڪنٽينر، اپلائنسز، فرم ويئر ۽ SDK اندروني ٽولنگ کان وڌيڪ اهم آهن.

ٻيو سوال ڏکيو آهي. جي پي ايل هڪ "پروگرام تي ٻڌل ڪم" جي ڳالهه ڪري ٿو، جيڪو آمريڪي تصور جي هڪ مشتق ڪم کي قرض وٺي ٿو. ڊچ قانون ۾ اهڙو ڪو به اصطلاح ناهي: تجزيو پيداوار ۽ موافقت جي حقن ذريعي هلندو آهي، پڇندو آهي ته ڇا اصل کان محفوظ اظهار کي ٻيهر پيدا ڪيو ويو آهي.

عملي معاملو لنڪنگ جو آهي. ڇا هڪ ملڪيت واري ماڊل کي GPL لائبريري سان ڳنڍڻ هڪ ڪم کي ڪاپي ليفٽ جي تابع بڻائي ٿو، اهو ڪڏهن به ڊچ عدالت پاران فيصلو نه ڪيو ويو آهي، ۽ ڪو به پابند EU اختيار ناهي. فري سافٽ ويئر فائونڊيشن جو خيال ته لنڪنگ هڪ گڏيل ڪم ٺاهي ٿو لائسنس اسٽيورڊ جي تشريح آهي، قانون نه، ۽ مخالف نظريو برابر غير آزمائشي آهي. انٽرنيٽ جو پسنديده جواب - متحرڪ لنڪنگ محفوظ، جامد لنڪنگ نه - ڊچ ڪاپي رائيٽ قانون ۾ ڪو به بنياد ناهي، جيڪو اهو نه پڇي ٿو ته هڪ مرتب ڪندڙ ڪيئن عمل ڪري ٿو. هڪ وڌيڪ قابل دفاع تجزيو پڇي ٿو ته اجزاء ڪيتري ويجهڙائي سان گڏ ڪيا ويا آهن: ڇا اهي هڪ ايڊريس اسپيس ۽ ڊيٽا اسٽرڪچر شيئر ڪن ٿا، ڇا ميلاپ هڪ پراڊڪٽ جي طور تي موڪليو ويو آهي، يا ته اڪيلو ڪم ڪري سگهي ٿو، ڇا ملڪيت واري پاسي ڪاپي ليفٽ پاسي کان هيڊر، ميڪرو يا ان لائن ڪوڊ ٻيهر پيدا ڪري ٿو؟ اهي سوال عام طور تي خطري کي حل ڪن ٿا. جتي اهي نه ڪندا آهن، جزو کي پروسيس جي حد جي پويان الڳ ڪريو، ان کي تبديل ڪريو، يا تجارتي لائسنس وٺو.

AGPL ۽ نيٽ ورڪ استعمال

AGPL موجود آهي ڇاڪاڻ ته ڪاپي ليفٽ ورڇ ذريعي شروع ٿئي ٿو ۽ SaaS فراهم ڪندڙ ورهائيندا نه آهن. ان جي نيٽ ورڪ شق جي ضرورت آهي ته جيڪڏهن توهان سافٽ ويئر کي تبديل ڪريو ۽ ان کي استعمال ڪندڙن لاءِ دستياب ڪريو جيڪي ان سان دور دراز سان رابطو ڪري رهيا آهن، ته توهان انهن کي پنهنجي تبديل ٿيل ورزن جو لاڳاپيل ذريعو پيش ڪندا آهيو.

ٽي نقطا عام طور تي ياد ڪيا ويندا آهن. ذميواري سروس جي استعمال ڪندڙن تي لاڳو ٿئي ٿي، جيڪا هڪ اوپن سائن اپ پراڊڪٽ ۾ ٿوري آرامده آهي. اهو ترميم ذريعي شروع ٿئي ٿو، تنهنڪري هڪ غير ترميم ٿيل جزو ان کي مشغول نٿو ڪري پر هڪ پيچ ٿيل تعمير ٿي سگهي ٿي. ۽ اهو ساڳيو گڏيل ڪم جو سوال اٿاري ٿو جيئن توهان جي باقي اسٽيڪ لاءِ GPL - اهو ئي سبب آهي ته ڪيتريون ئي ڪمپنيون پيداوار ڪوڊ ۾ AGPL کي منع ڪن ٿيون.

لائسنس جي مطابقت

مطابقت اهڙن حصن کي گڏ ڪرڻ جو مسئلو آهي جن جا لائسنس اهڙيون ذميواريون لاڳو ڪن ٿا جيڪي ٻئي هڪ ئي ورڇ ۾ پوريون نه ٿيون ڪري سگهجن: اجازت ڏيندڙ لائسنس تقريبن هر شيءِ سان مطابقت رکن ٿا، ڪاپي ليفٽ لائسنس صرف ان سان جيڪي انهن جون پنهنجون شرطون اجازت ڏين ٿيون. معياري ڪيس اپاچي 2.0 ۽ GPLv2 آهي. اپاچي سافٽ ويئر فائونڊيشن ۽ فري سافٽ ويئر فائونڊيشن متفق آهن ته ميلاپ جي اجازت ناهي، ڇاڪاڻ ته اپاچي 2.0 جي پيٽنٽ ختم ڪرڻ ۽ معاوضي جي دفعات اضافي پابنديون آهن جيڪي GPLv2 اجازت نٿو ڏئي. GPLv3 کي انهن کي قبول ڪرڻ لاءِ تيار ڪيو ويو هو. مطابقت پڻ هدايتي آهي: اپاچي ڪوڊ کي GPLv3 منصوبي ۾ جذب ​​ڪري سگهجي ٿو، پر ان جي ابتڙ نه. غلط جاءِ تي هڪ GPL جزو ٻيهر لائسنسنگ، ٻيهر انجنيئرنگ يا هٽائڻ جي وچ ۾ چونڊ ڪرڻ تي مجبور ڪري سگهي ٿو - بعد جي ڀيٽ ۾ ڇڏڻ کان اڳ تمام سستو.

انتساب ۽ نوٽيس جون ذميواريون

سڀ کان وڌيڪ ڀڃڪڙي ڪيل ذميداريون گهٽ ۾ گهٽ ڊرامائي آهن: ڪاپي رائيٽ نوٽيس، لائسنس ٽيڪسٽ، ڊسڪليمر ۽، اپاچي 2.0 جي تحت، تقسيم سان گڏ مواد ۾ نوٽيس مواد کي ٻيهر پيدا ڪرڻ. هر خاندان انهن کي لاڳو ڪري ٿو، MIT ۽ BSD شامل آهن. انهن جي ڀڃڪڙي ڪئي وئي آهي ڇاڪاڻ ته ڪو به انهن جو مالڪ ناهي، ۽ درست ڪرڻ آسان آهن - عام طور تي هڪ پيدا ٿيل انتساب فائل پراڊڪٽ سان موڪلي ويندي آهي. مٿي ڏنل ڊچ ڪيس بلڪل هن ناڪامي تي موڙيو.

پيٽنٽ گرانٽس ۽ پيٽنٽ جي بدلي

ايم آءِ ٽي ۽ بي ايس ڊي پيٽنٽ بابت ڪجهه به نه ٿا چون، ۽ ڇا پيٽنٽ لائسنس لاڳو ٿي سگهي ٿو اهو طئي نه ٿيو آهي. اپاچي 2.0 هر حصو وٺندڙ کان هڪ ايڪسپريس، رائلٽي فري پيٽنٽ لائسنس شامل ڪيو، هڪ انتقامي شق سان گڏ: پيٽنٽ جي قانوني ڪارروائي آڻيو جنهن ۾ الزام لڳايو ويو آهي ته ڪم خلاف ورزي ڪري ٿو ۽ توهان جو پيٽنٽ لائسنس ختم ٿي وڃي ٿو. GPLv3 ۾ هڪ مقابلي واري گرانٽ ۽ ان جي پنهنجي پيٽنٽ جون شقون شامل آهن.

پيٽنٽ پورٽ فوليو وارن ڪمپنين لاءِ ٻه اثر. جيڪڏهن توهان جا انجنيئر Apache- يا GPLv3-لائسنس ٿيل منصوبن ۾ حصو وٺندا آهن، ته توهان پنهنجي پيٽنٽ تحت لائسنس ڏئي رهيا آهيو. ۽ جيڪڏهن توهان ڪڏهن به ڪنهن ڪمپني جي خلاف پيٽنٽ جو دعويٰ ڪيو ٿا ته ساڳي Apache-لائسنس ٿيل حصن جي بنياد تي جيڪي توهان استعمال ڪندا آهيو، ته انتقام توهان کي هڪ لائسنس جي قيمت ادا ڪري سگهي ٿو جنهن تي توهان ڀروسو ڪندا آهيو.

EUPL ۽ ڊچ پبلڪ سيڪٽر

يورپي يونين پبلڪ لائسنس ورزن 1.2، جيڪو مئي 2017 ۾ فيصلي تي عمل ڪندي يورپي ڪميشن پاران منظور ڪيو ويو، هڪ OSI-منظور ٿيل ڪاپي ليفٽ لائسنس آهي جنهن ۾ ٽي امتيازي خاصيتون آهن.

• ٻولي. اهو سرڪاري يورپي يونين ٻولين ۾ موجود آهي، سڀني منظور ٿيل نسخن جي قيمت هڪجهڙي آهي، تنهنڪري هڪ ڊچ اختيار ڊچ ۾ معاهدو ڪري سگهي ٿو.
• مطابقت. هڪ ضميمه مطابقت رکندڙ لائسنسن جي فهرست ڏئي ٿو - GPLv2 ۽ v3، AGPLv3، LGPL، MPL 2، EPL 1.0، OSL ۽ CeCILL انهن مان - ۽ هڪ ڊيريويٽو ڪم کي اجازت ڏئي ٿو جيڪو EUPL ڪوڊ کي هڪ فهرست ٿيل لائسنس جي تحت ڪوڊ سان گڏ ڪري ٿو ان جي بدران ان لائسنس جي تحت ورهايو وڃي.
• پهچ. ورڇ جي ان جي تعريف ڪم کي آن لائن يا آف لائن دستياب ڪرڻ کي شامل ڪري ٿي. يا ان جي ضروري ڪارڪردگي تائين رسائي فراهم ڪرڻ، ۽ آرٽيڪل 5 EUPL ڪاپي ليفٽ جي ذميواري کي ريموٽ انٽراڪشن تائين کڻندو آهي جنهن ۾ اهو ساڳيو ڪارڪردگي پيش ڪيو ويندو آهي. تنهن ڪري اهو سافٽ ويئر تائين هڪ خدمت جي طور تي پهچندو آهي، هڪ طريقي سان GPL نٿو ڪري.

هڪ ڊچ پبلڪ سيڪٽر گراهڪ کي EUPL کي قانون جي بدران پاليسي جي معاملي جي طور تي گهربل ٿي سگهي ٿو. انٽرآپريبل يورپ ايڪٽ، ريگيوليشن (EU) 2024/903، پبلڪ سيڪٽر باڊيز کي هدايت ڪري ٿو ته اهي پابندي واري لائسنسنگ شرطن کان سواءِ انٽرآپريبلٽي حلن کي ترجيح ڏين، جهڙوڪ اوپن سورس، جتي برابر؛ قومي طور تي، اوپن سورس جو اصول، ٽينسيج ڪابينا جي فيصلن ۽ پاليسي لائينن تي ٻڌل آهي، قانون تي نه: ويٽ ڊجيٽل اوور هيڊ ڊجيٽل سڃاڻپ جي انفراسٽرڪچر کي آسان بڻائي ٿو پر سڀني سورس ڪوڊ کي شايع ڪرڻ لاءِ ڪو به قابل اطلاق ذميواري لاڳو نٿو ڪري. ٽينڊر دستاويز پڙهو: هڪ EUPL گهرج توهان جي پهچائڻ واري کي پابند ڪري ٿي ۽ شايد ملڪيت واري ڪوڊ سان مطابقت نه رکي جيڪا توهان ٻيهر استعمال ڪرڻ جو ارادو ڪيو آهي.

عملي طور تي نفاذ

ڪير ڪيس ڪري سگهي ٿو. حق رکندڙ - انفرادي حصو وٺندڙ، يا فائونڊيشن يا ڪمپني جيڪا تفويض ڪيل ڪاپي رائيٽ رکي ٿي. ٽٽل تصنيف عملي بريڪ آهي: هڪ دعويدار کي مسئلي تي ڪوڊ جي ملڪيت ثابت ڪرڻ گهرجي. اهو سڀ کان وڌيڪ مشهور يورپي GPL ڪيس کي شڪست ڏئي ٿو، جتي هڪ ورچوئلائيزيشن وينڊر جي خلاف ڪرنل ڊولپر جو دعويٰ تصنيف جي ثبوت جي کوٽ سبب ناڪام ٿي ويو (LG Hamburg 8 جولاءِ 2016، 310 O 89/15؛ OLG Hamburg 28 فيبروري 2019، 5 U 146/16 کي برقرار رکيو ويو).

ڪيس قانون ڇا قائم ڪري ٿو. جرمن عدالتن بار بار قبول ڪيو آهي ته اوپن سورس لائسنس صحيح آهن ۽ اها خلاف ورزي تقسيم کي غير قانوني بڻائي ٿي، پهرين GPL حڪم (LG München I 19 مئي 2004، 21 O 6123/04) سان شروع ٿئي ٿي. يو ايس فيڊرل سرڪٽ جيڪبسن بمقابلہ ڪيٽزر ، 535 F.3d 1373 (فيڊ. سر. 2008) ۾ ساڳئي نتيجي تي پهتو: لائسنس جون شرطون گرانٽ جي دائري تي شرطون آهن، صرف معاهدا نه، تنهن ڪري خلاف ورزي ڪاپي رائيٽ جي دعويٰ ۽ حڪم امتناعي رليف جي حمايت ڪري ٿي. يو ايس جي قانوني ڪارروائي ڳولي رهي آهي ته ڇا هڪ ڊائون اسٽريم وصول ڪندڙ ٽئين پارٽي جي فائديمند جي طور تي GPL لاڳو ڪري سگهي ٿو. اهو ڪيليفورنيا جي سپريم ڪورٽ جي سامهون سافٽ ويئر فريڊم ڪنزروينسي بمقابلہ ويزيو ۾ مرڪزي سوال آهي : ڇا صارف، ٽئين پارٽي جي فائديمند جي طور تي، GPLv2 جي تحت سورس ڪوڊ جي جاري ٿيڻ جو مطالبو ڪري سگهن ٿا. 23 ڊسمبر 2025 تي عدالت سمري ايڊجوڊيڪيشن تي هڪ نقطو فيصلو ڪيو، جنهن ۾ چيو ويو ته GPLv2 ۽ LGPLv2.1 کي اهڙو ذريعو گهربل آهي جيڪو حاصل ڪري سگهجي ۽ ٻئي هنڌ استعمال لاءِ ٻيهر ڪم ڪري سگهجي بجاءِ ان ذريعو جي جيڪو ڊوائيس تي ٻيهر انسٽال ڪري سگهجي ۽ ان جي ڪارڪردگي برقرار رهي. ٽئين پارٽي جي فائدي وارو سوال پاڻ کي بينچ ٽرائل لاءِ ڇڏي ويو هو، جيڪو هڪ کان وڌيڪ ڀيرا ملتوي ڪيو ويو آهي. اهو ڪنهن به صورت ۾ ڪيليفورنيا جي معاهدي جي قانون جو سوال آهي، تنهن ڪري اهو هالينڊ ۾ ڪجهه به پابند نٿو ڪري؛ اهو جيڪو تبديل ڪندو اهو آهي شڪايت ڪرڻ جي قابل ماڻهن جو تعداد.

ڊچ عدالت ان کي ڪيئن ڏسندي. Auteurswet جي تحت ڪاپي رائيٽ جي خلاف ورزي جي طور تي: دعويدار ملڪيت ۽ نقل يا رابطي کي ثابت ڪري ٿو؛ مدعا عليه لائسنس بلند ڪري ٿو؛ دعويدار جواب ڏئي ٿو ته ان جون شرطون پوريون نه ٿيون، تنهن ڪري دفاع ناڪام ٿئي ٿو. آرٽيڪل 6:265 BW جي تحت معاهدي جا علاج متوازي طور تي هلن ٿا، پر ڪاپي رائيٽ مضبوط رستو آهي.

علاج. آرٽيڪل 3:296 BW تحت هڪ حڪم، عام طور تي ڏنڊ جي ادائيگي سان ۽ خلاصي ڪارروائي ۾ موجود آهي؛ آرٽيڪل 27 Aw ۽ آرٽيڪل 27a Aw تحت منافعي جو حساب ڪتاب؛ آرٽيڪل 28 Aw؛ آرٽيڪل 28 Aw تحت واپس گهرائڻ، تسليم ڪرڻ يا تباهي؛ ۽ آرٽيڪل 1019h Rv تحت مناسب ۽ متناسب قانوني خرچن جي مڪمل وصولي. جتي سافٽ ويئر مفت ۾ ورهايو ويو هو، نقصان جو اندازو لڳائڻ ڏکيو آهي، ۽ هڪ جرمن اپيليٽ ڪورٽ حڪم کي برقرار رکندي نقصان ڏيڻ کان انڪار ڪيو (OLG Hamm 13 جون 2017، 4 U 72/16). جيڪو نقصان گهٽ ۾ گهٽ آهي اهو نقصان آهي: اهو حڪم، واپس گهرائڻ، قيمتن جو حڪم، ۽ ذريعو شايع ڪرڻ آهي جيڪو توهان ڪڏهن به شايع ڪرڻ جو ارادو نه ڪيو هو.

جڏهن توهان تعميل جو مسئلو ڳوليندا آهيو

دريافت عام طور تي گراهڪ جي سيڪيورٽي سوالنامي، ڊيو ڊيليجنس دوران اسڪين، يا رائٽ هولڊر جي خط مان ايندي آهي. پوءِ ريميڊيئيشن هيٺ ڏنل طريقي سان ٿيندي آهي. جيڪڏهن ايڪسپوزر سنجيده آهي ته متاثر ٿيل بلڊ جي ورڇ کي روڪيو. اهو طئي ڪريو ته ڪهڙو جزو، ڪهڙو نسخو، ڪهڙو لائسنس، ڪهڙو پراڊڪٽ ۽ رليز، ڪهڙي عرصي دوران. ڪم ڪريو ته لائسنس اصل ۾ ڇا گهري ٿو - اڪثر ڪري سورس رليز جي بدران هڪ انتساب فائل. شيون تيار ڪريو: نوٽيس، لائسنس ٽيڪسٽ، مڪمل لاڳاپيل سورس بشمول بلڊ اسڪرپٽ، ۽ هڪ تحريري آڇ جتي استعمال ٿئي ٿي. هڪ تعميل رليز موڪليو، پوءِ رائٽ هولڊر کي ٻڌايو ته توهان ڇا ڪيو آهي ان بابت بحث ڪرڻ جي بدران ته توهان کي ڪرڻو هو.

GPLv3 ۽ AGPLv3 تحت علاج ونڊو رفتار قانوني قدر ڏئي ٿو؛ GPLv2 تحت ڪو به علاج جو حق ناهي، اهو ئي سبب آهي ته گهڻا نفاذ ڳالهين جي تعميل جي ذميواري ۾ ختم ٿين ٿا. اهو پڻ نوٽ ڪريو ته استحقاق توهان جي وڪيل جي صلاح سان ڳنڍيل آهي، اندروني انجنيئرنگ رپورٽ سان نه.

ايم اينڊ اي ۾ اوپن سورس ۽ ڊيو ڊيليجنس

سافٽ ويئر جي حصول ۾، اوپن سورس هڪ معياري محنت جو ڪم آهي، ۽ بنيادي پراڊڪٽ ۾ هڪ اڻ ظاهر ڪيل ڪاپي ليفٽ جزو انهن چند نتيجن مان هڪ آهي جيڪو حقيقي طور تي هڪ ڊيل کي منتقل ڪري ٿو: جيڪڏهن پراڊڪٽ کي ان جي ذريعن کي جاري ڪرڻ کان سواءِ ورهائي نه ٿو سگهجي، ته خريد ڪندڙ قيمت واري کان مختلف اثاثو حاصل ڪري رهيو آهي.

ڪوڊ بيس اسڪين، لائسنس سان گڏ هڪ جزو انوینٽري، ۽ ڪنٽريبيوٽر ۽ ٺيڪيدار جي انتظامن بابت سوال جي توقع ڪريو. عام نتيجا هڪ مخصوص معاوضو، هڪ برقرار رکڻ جي انتظار ۾ علاج، هڪ شرط جي مثال جنهن کي هٽائڻ جي ضرورت آهي، يا هڪ مخصوص اوپن سورس وارنٽي آهن. وڪرو ڪندڙن کي پهريان اسڪين ڪرڻ گهرجي: توهان جي ظاهر ڪيل نتيجا هڪ ڳالهه ٻولهه آهن، خريد ڪندڙ جي صلاحڪار پاران ڪيل نتيجا ليوريج آهن. خريد ڪندڙن کي "ڪمپني پنهنجي IP جي مالڪ ناهي" پر هڪ نمائندگي ڳولڻ گهرجي ته ڪو به پراڊڪٽ اوپن سورس کي شامل نه ڪري جنهن کي ملڪيت جي سورس ڪوڊ جي ظاهر ڪرڻ جي ضرورت هجي.

مواد جو بل، اسڪيننگ ۽ سائبر لچڪدار ايڪٽ

سافٽ ويئر بل آف ميٽريلز هڪ پراڊڪٽ جي حصن جي انوینٽري آهي، جنهن ۾ ورجن ۽ لائسنس شامل آهن. تازو تائين خالص معاهدي تي ٻڌل نه هو، هاڻي اهو ريگيوليٽري پڻ آهي.

سائبر لچڪدار ايڪٽ، ريگيوليشن (EU) 2024/2847، 10 ڊسمبر 2024 تي لاڳو ٿيو ۽ مرحلن ۾ داخل ٿيو. اهو ڊچ سائبر سيڪيورٽي ايڪٽ سان گڏ ويٺو آهي ، جيڪو پيداوار جي بدران تنظيم کي خطاب ڪري ٿو. فعال طور تي استحصال ٿيل ڪمزورين ۽ سخت واقعن لاءِ رپورٽنگ جي ذميواريون آرٽيڪل ۾. 14 CRA 11 سيپٽمبر 2026 کان لاڳو ٿئي ٿو؛ 11 جون 2026 کان مطابقت جي تشخيصي ادارن جي نوٽيفڪيشن تي ضابطا؛ 11 ڊسمبر 2027 کان مڪمل طور تي ضابطو (آرٽ. 71 CRA). ضميمه I CRA ٺاهيندڙن کي پراڊڪٽ ۾ اجزاء جي سڃاڻپ ۽ دستاويز ڪرڻ جي ضرورت آهي، جنهن ۾ عام طور تي استعمال ٿيندڙ ۽ مشين پڙهڻ واري فارميٽ ۾ مواد جو هڪ سافٽ ويئر بل تيار ڪرڻ شامل آهي جيڪو گهٽ ۾ گهٽ مٿين سطح جي انحصار کي ڍڪيندو آهي. ان کي شايع ڪرڻ جي ضرورت ناهي؛ مارڪيٽ نگراني اختيارين ان جي درخواست ڪري سگهن ٿا.

تجارتي سرگرمي کان ٻاهر فراهم ڪيل مفت ۽ اوپن سورس سافٽ ويئر CRA کان ٻاهر آهي. ضابطو اوپن سورس سافٽ ويئر اسٽيورڊ متعارف ڪرائي ٿو - هڪ قانوني شخص جيڪو تجارتي سرگرمين لاءِ ٺهيل اوپن سورس سافٽ ويئر جي ترقي کي مسلسل مدد ڏئي ٿو - فن ۾ هلڪي ذميوارين سان. 24 CRA: هڪ دستاويزي سائبر سيڪيورٽي پاليسي، مارڪيٽ نگراني اختيارين سان تعاون، ۽ رپورٽنگ. جيڪڏهن توهان اوپن سورس کي ڪمرشلائيز ڪيو ٿا، يا ڪنهن منصوبي کي فنڊ ڏيو ٿا جيڪو ٻيا ڪمرشلائيز ڪن ٿا، اهو قائم ڪريو ته توهان ڪهڙو ڪردار ادا ڪيو ٿا. ڪميشن 27 جولاءِ 2026 تي پنهنجي پهرين هدايت اختيار ڪئي: سائبر ريزيلينس ايڪٽ (CRA) جي درخواست تي ڪميشن جي هدايت، ڪميونيڪيشن C(2026) 5252 سان ڳنڍيل، جيڪو ٻين شين جي وچ ۾ خطاب ڪري ٿو جڏهن مفت ۽ اوپن سورس سافٽ ويئر دائري ۾ اچي ٿو. سافٽ ويئر بل آف مواد لاءِ فارميٽ مقرر ڪرڻ وارو ڪو به لاڳو ڪندڙ ايڪٽ اختيار نه ڪيو ويو آهي، تنهن ڪري ضابطي جو پنهنجو معيار - هڪ عام طور تي استعمال ٿيندڙ، مشين پڙهڻ لائق فارميٽ - هن وقت لاءِ ماپ رهي ٿو.

CI ۾ هلندڙ سافٽ ويئر ڪمپوزيشن تجزيو هڪ ئي وقت انوینٽري سروسنگ تعميل، لائسنس جو جائزو ۽ محنت پيدا ڪري ٿو. اهڙا اوزار وينڊرڊ ڪوڊ کي وڃائي ڇڏيندا آهن، ٻٽي لائسنس يافته منصوبن کي غلط سڃاڻيندا آهن ۽ لائسنس جي شرطن کي نه پڙهي سگهندا آهن: آئوٽ پُٽ کي جائزو جي شروعات طور سمجهو، جائزو نه.

جيڪڏهن توهان پنهنجو ڪوڊ شايع ڪيو ٿا: CLAs ۽ DCO

هڪ ڪمپني جيڪا ڪوڊ جاري ڪري ٿي ۽ ٻاهرين تعاونن کي قبول ڪري ٿي، ان کي ڄاڻڻ گهرجي ته ان کي ان جا حق آهن جيڪي اهو ضم ڪري ٿو. هڪ تعاون ڪندڙ لائسنس جو معاهدو منصوبي ۽ تعاون ڪندڙ جي وچ ۾ هڪ معاهدو آهي، عام طور تي هڪ وسيع ڪاپي رائيٽ لائسنس ۽ هڪ ايڪسپريس پيٽنٽ لائسنس ڏئي ٿو، جنهن ۾ اصليت ۽ اختيار جي ضمانت شامل آهي. اهو ئي آهي جيڪو هڪ ڪمپني کي بعد ۾ پنهنجي منصوبي کي ٻيهر لائسنس ڏيڻ جي اجازت ڏئي ٿو، يا هڪ اوپن سورس لائسنس سان گڏ تجارتي لائسنس پيش ڪري ٿو. ان جي قيمت رگڙ آهي.

ڊولپر سرٽيفڪيٽ آف اوريجن ، جيڪو لينڪس ڪرنل ۽ ٻين ڪيترن ئي منصوبن پاران استعمال ڪيو ويندو آهي، لائسنس گرانٽ نه آهي پر هڪ هلڪو تصديق آهي، جيڪو هر ڪمٽ ۾ سائن آف لائن جي طور تي شامل ڪيو ويو آهي، ته حصو وٺندڙ منصوبي جي لائسنس تحت ڪوڊ جمع ڪرائي سگهي ٿو. گهٽ بار بار، ۽ گهٽ حفاظتي: ڪو به پيٽنٽ لائسنس، ڪو به ٻيهر لائسنسنگ نه.

جيڪڏهن ٻٽي لائسنسنگ يا مستقبل جي لائسنس ممڪن آهي، ته پوءِ CLA استعمال ڪريو؛ جيڪڏهن منصوبو هڪ حقيقي ڪامنز آهي، ته پوءِ DCO عام طور تي ڪافي هوندو آهي. ڪنهن به صورت ۾، پڪ ڪريو ته توهان جا ملازمت ۽ ٺيڪيدار معاهدا توهان جي ماڻهن جي لکيل ڪوڊ ۾ ڪاپي رائيٽ تفويض ڪن ٿا.

هڪ عملي پاليسي چيڪ لسٽ

• هر پراڊڪٽ جي هڪ جزو جي انوینٽري ٺاهيو ۽ بلڊ پائپ لائن ۾ جاري ڪريو، هٿ سان نه.
• هڪ اندروني پاليسي شايع ڪريو: هڪ اجازت ڏنل فهرست، هڪ ممنوع فهرست ۽ هر شيءِ لاءِ منظوري جو رستو.
• لکت ۾ بيان ڪريو ته ڪهڙي شيءِ کي ورهائڻ ۾ شمار ڪيو ويندو آهي — آن پريمائس تنصيب، اپلائنسز، ڪنٽينرز، SDKs، موبائل ايپس، فرم ويئر.
• هر پراڊڪٽ سان گڏ هڪ ٺاهيل انتساب فائل موڪليو.
• لائسنس جي چونڊ کي ڊيزائن جي وقت منظور ڪريو، جڏهن ڪو جزو چونڊيو وڃي، نه ته رليز ٿيڻ تي.
• فيصلو ڪريو ته ڇا ٻاهرين منصوبن ۾ حصو وٺڻ لاءِ منظوري جي ضرورت آهي، پيٽنٽ گرانٽس شامل آهن، ۽ پهرين ٻاهرين حصو وٺڻ کان اڳ CLA يا DCO چونڊيو.
• IP وارنٽيز، معاوضي ۽ ايسڪرو شرطن کي پراڊڪٽ ۾ اصل ۾ اوپن سورس سان ترتيب ڏيو.
• فنڊ گڏ ڪرڻ يا وڪري جي عمل کان اڳ جائزو وٺو، نه ته هڪ دوران.

Law & More سافٽ ويئر ڪمپنين ۽ انهن جي سيڙپڪارن کي صلاح ڏئي ٿو Eindhoven ۽ Amsterdam اوپن سورس جي تعميل، لائسنس جي جائزي، حصو وٺندڙ انتظامن ۽ ٽرانزيڪشن ۾ اوپن سورس ورڪ اسٽريم تي.