ڈچ اور یورپی یونین کے قانون کے تحت اوپن سورس سافٹ ویئر لائسنس

تقریباً ہر تجارتی سافٹ ویئر پروڈکٹ میں اوپن سورس اجزاء ہوتے ہیں، عام طور پر سینکڑوں، جو وکلاء کے بجائے ڈویلپرز کے ذریعے منتخب کیے جاتے ہیں۔ یہ ایک مسئلہ بن جاتا ہے جب کوئی یہ نہیں کہہ سکتا کہ کون سے لائسنس لاگو ہوتے ہیں، ان کی کیا ضرورت ہے، اور کیا پروڈکٹ اس کی تعمیل کرتی ہے۔ یہ مضمون وضاحت کرتا ہے کہ اوپن سورس لائسنس ڈچ اور یورپی یونین کے قانون کے تحت کیسے کام کرتے ہیں، خطرہ کہاں ہے، اور کیا ہونا چاہیے۔

قانونی لحاظ سے اوپن سورس لائسنس کیا ہے۔

اوپن سورس لائسنس ایک کاپی رائٹ لائسنس ہے جو شرائط کے ساتھ دیا جاتا ہے۔ یہ چھوٹ نہیں ہے، عوامی ڈومین کے لیے وقف نہیں ہے، حقوق سے دستبردار نہیں ہے، اور اس سلسلے میں یہ ڈچ قانون کے تحت کسی دوسرے سافٹ ویئر لائسنس کی طرح کام کرتا ہے ۔ مصنف آرٹ کے تحت کاپی رائٹ کو برقرار رکھتا ہے۔ 1 اوہ اور آرٹ۔ 10 Aw، جو کمپیوٹر پروگراموں کو کام کے طور پر تحفظ فراہم کرتا ہے، اور لائسنس ایسی کارروائیوں کی اجازت دیتا ہے جو بصورت دیگر آرٹ کے تحت خصوصی حقوق کی خلاف ورزی کرتے ہیں۔ 12 اوہ اور آرٹ۔ 13 اے۔

نتیجہ تعریف سے زیادہ اہمیت رکھتا ہے۔ تعمیل کریں، اور آپ کی کاپی کرنا اور تقسیم کرنا جائز ہے۔ تعمیل کرنے میں ناکام رہتے ہیں، اور اجازت اس بات کا احاطہ نہیں کرتی ہے کہ آپ نے کیا کیا: آپ کا استعمال کاپی رائٹ کی خلاف ورزی ہے، معاہدے کی خلاف ورزی نہیں۔ زیادہ تر کاپی لیفٹ لائسنس خلاف ورزی پر خود بخود ختم کر کے اس کو تقویت دیتے ہیں — GPLv2 بغیر کسی علاج کی مدت کے، جبکہ GPLv3 اور AGPLv3 حقوق کو بحال کرتے ہیں اگر خلاف ورزی نوٹس کے بعد ایک متعین ونڈو کے اندر ٹھیک ہو جاتی ہے۔

ڈچ عدالتیں اس استدلال کا اطلاق کرتی ہیں۔ آر بی میں Amsterdam 22 ستمبر 2020، ECLI:NL:RBAMS:2020:4717، ایک ڈسٹری بیوٹر جس نے لائسنس کے متن اور کاپی رائٹ نوٹس کو فورک شدہ کوڈ بیس سے ہٹا دیا تھا، اس کی اجازت کھو دی گئی تھی اور خلاف ورزی کی گئی تھی۔ نئے کوڈ کی ایک بڑی مقدار کو شامل کرنے سے ایک آزاد کام نہیں ہوا: اصل شناختی طور پر موجود رہا، لہذا ذمہ داریوں نے اس کے ساتھ سفر کیا۔

دو خاندان: اجازت اور کاپی لیفٹ

اجازت دینے والے لائسنس - MIT، BSD لائسنسز، Apache 2.0 - استعمال، ترمیم اور دوبارہ تقسیم کی اجازت دیتے ہیں، بشمول بند ماخذ پروڈکٹس کے اندر، بشرطیکہ آپ کاپی رائٹ نوٹس اور لائسنس کے متن کو محفوظ رکھیں۔

Copyleft لائسنس کا تقاضا ہے کہ جب آپ سافٹ ویئر تقسیم کرتے ہیں، یا اس پر بنی کوئی چیز، آپ اسی لائسنس کے تحت ایسا کرتے ہیں اور متعلقہ ذریعہ دستیاب کرتے ہیں۔ وہ رسائی میں مختلف ہیں۔

کاپی لیفٹ ٹرگر اور لنک کرنے والا سوال

کاپی لیفٹ ذمہ داریاں تقسیم پر کاٹتی ہیں، استعمال پر نہیں۔ ایک کمپنی جو اندرونی طور پر GPL سافٹ ویئر چلا رہی ہے، اگرچہ بہت زیادہ ترمیم کی گئی ہے، کچھ بھی تقسیم نہیں کرتی اور نہ ہی کچھ واجب الادا ہے۔ "کیا ہم نے تقسیم کیا ہے؟" ہمیشہ پہلا سوال ہوتا ہے، اور یہی وجہ ہے کہ کنٹینرز، آلات، فرم ویئر اور SDKs اندرونی ٹولنگ سے زیادہ اہمیت رکھتے ہیں۔

دوسرا سوال زیادہ مشکل ہے۔ GPL ایک "پروگرام پر مبنی کام" کے بارے میں بات کرتا ہے، ایک مشتق کام کے امریکی تصور کو مستعار لے کر۔ ڈچ قانون میں ایسی کوئی اصطلاح نہیں ہے: تجزیہ تولید اور موافقت کے حقوق کے ذریعے چلتا ہے، یہ پوچھتا ہے کہ آیا اصل سے محفوظ اظہار کو دوبارہ پیش کیا گیا ہے۔

عملی کیس جوڑ رہا ہے۔ آیا ملکیتی ماڈیول کو GPL لائبریری سے جوڑنے سے کاپی لیفٹ کے تابع ایک کام تخلیق ہوتا ہے یا نہیں اس کا فیصلہ ڈچ عدالت نے کبھی نہیں کیا ہے، اور EU کا کوئی پابند نہیں ہے۔ فری سافٹ ویئر فاؤنڈیشن کا نظریہ کہ لنک کرنے سے مشترکہ کام بنتا ہے لائسنس اسٹیورڈ کی تشریح ہے، قانون کی نہیں، اور مخالف نظریہ بھی اتنا ہی غیر تجربہ شدہ ہے۔ انٹرنیٹ کا پسندیدہ جواب — متحرک لنکنگ محفوظ، جامد لنک نہیں — کی ڈچ کاپی رائٹ قانون میں کوئی بنیاد نہیں ہے، جو یہ نہیں پوچھتا کہ مرتب کرنے والا کیسا برتاؤ کرتا ہے۔ ایک زیادہ قابل دفاع تجزیہ پوچھتا ہے کہ اجزاء کو کس طرح قریب سے جوڑا جاتا ہے: کیا وہ ایڈریس اسپیس اور ڈیٹا ڈھانچے کا اشتراک کرتے ہیں، کیا امتزاج ایک پروڈکٹ کے طور پر بھیجا جاتا ہے، یا تو اکیلے کام کرسکتا ہے، کیا ملکیتی سائیڈ کاپی لیفٹ سائیڈ سے ہیڈرز، میکروز یا ان لائن کوڈ کو دوبارہ تیار کرتی ہے؟ یہ سوالات عام طور پر خطرے کو حل کرتے ہیں۔ جہاں وہ ایسا نہیں کرتے ہیں، عمل کی حد کے پیچھے جزو کو الگ کر دیں، اسے تبدیل کریں، یا تجارتی لائسنس لیں۔

AGPL اور نیٹ ورک کا استعمال

AGPL موجود ہے کیونکہ کاپی لیفٹ تقسیم کے ذریعہ متحرک ہوتا ہے اور SaaS فراہم کرنے والے تقسیم نہیں کرتے ہیں۔ اس کے نیٹ ورک کی شق کا تقاضہ ہے کہ اگر آپ سافٹ ویئر میں ترمیم کرتے ہیں اور اسے اس کے ساتھ دور سے بات چیت کرنے والے صارفین کے لیے دستیاب کرتے ہیں، تو آپ انہیں اپنے ترمیم شدہ ورژن کا متعلقہ ذریعہ پیش کرتے ہیں۔

تین پوائنٹس عام طور پر چھوٹ جاتے ہیں۔ یہ ذمہ داری سروس کے استعمال کنندگان پر عائد ہوتی ہے، جو ایک کھلے سائن اپ پروڈکٹ میں بہت کم آرام دہ ہے۔ یہ ترمیم کے ذریعہ شروع ہوتا ہے، لہذا ایک غیر ترمیم شدہ جزو اس میں مشغول نہیں ہوتا ہے لیکن ایک پیچ شدہ تعمیر ہوسکتی ہے۔ اور یہ آپ کے باقی اسٹیک کے لیے جی پی ایل کی طرح مشترکہ کام کا سوال اٹھاتا ہے — یہی وجہ ہے کہ بہت سی کمپنیاں پروڈکشن کوڈ میں AGPL کو ممنوع قرار دیتی ہیں۔

لائسنس کی مطابقت

مطابقت ان اجزاء کو یکجا کرنے کا مسئلہ ہے جن کے لائسنس ایسی ذمہ داریاں عائد کرتے ہیں جو دونوں کو ایک تقسیم میں پورا نہیں کیا جا سکتا: اجازت دینے والے لائسنس تقریباً ہر چیز کے ساتھ مطابقت رکھتے ہیں، کاپی لیفٹ لائسنس صرف ان کی اپنی شرائط کے ساتھ اجازت دیتے ہیں۔ معیاری کیس Apache 2.0 اور GPLv2 ہے۔ Apache Software Foundation اور Free Software Foundation متفق ہیں کہ امتزاج کی اجازت نہیں ہے، کیونکہ Apache 2.0 کے پیٹنٹ کے خاتمے اور معاوضے کی دفعات اضافی پابندیاں ہیں جن کی GPLv2 اجازت نہیں دیتا ہے۔ انہیں قبول کرنے کے لیے GPLv3 کا مسودہ تیار کیا گیا تھا۔ مطابقت بھی دشاتمک ہے: اپاچی کوڈ کو GPLv3 پروجیکٹ میں جذب کیا جا سکتا ہے، لیکن ریورس نہیں۔ غلط جگہ پر ایک جی پی ایل جزو دوبارہ لائسنس دینے، دوبارہ انجینئرنگ یا ہٹانے کے درمیان انتخاب پر مجبور کر سکتا ہے — ریلیز سے پہلے اس کے بعد کے مقابلے میں بہت سستا ہے۔

انتساب اور نوٹس کی ذمہ داریاں

سب سے زیادہ کثرت سے خلاف ورزی کی جانے والی ذمہ داریاں کم از کم ڈرامائی ہیں: کاپی رائٹ نوٹسز، لائسنس ٹیکسٹس، ڈس کلیمر اور اپاچی 2.0 کے تحت، تقسیم کے ساتھ موجود مواد میں نوٹس کے مواد کو دوبارہ پیش کرنا۔ ہر خاندان انہیں مسلط کرتا ہے، MIT اور BSD شامل ہیں۔ ان کی خلاف ورزی کی گئی ہے کیونکہ کوئی بھی ان کا مالک نہیں ہے، اور اسے ٹھیک کرنا سب سے آسان ہے — عام طور پر ایک تیار کردہ انتساب فائل کو پروڈکٹ کے ساتھ بھیج دیا جاتا ہے۔ اوپر ڈچ کیس نے بالکل اسی ناکامی کو بدل دیا۔

پیٹنٹ گرانٹس اور پیٹنٹ کا بدلہ

ایم آئی ٹی اور بی ایس ڈی پیٹنٹ کے بارے میں کچھ نہیں کہتے ہیں، اور کیا پیٹنٹ لائسنس کا تقاضہ کیا جا سکتا ہے، یہ غیر طے شدہ ہے۔ Apache 2.0 نے ہر ایک تعاون کنندہ سے ایک ایکسپریس، رائلٹی فری پیٹنٹ لائسنس شامل کیا، جو ایک جوابی شق کے ساتھ جوڑا گیا: پیٹنٹ قانونی چارہ جوئی کا الزام لگاتے ہوئے کہ کام کی خلاف ورزی ہوتی ہے اور آپ کا پیٹنٹ لائسنس ختم ہوجاتا ہے۔ GPLv3 ایک موازنہ گرانٹ اور اس کے اپنے پیٹنٹ کی دفعات پر مشتمل ہے۔

پیٹنٹ پورٹ فولیوز والی کمپنیوں کے لیے دو مضمرات۔ اگر آپ کے انجینئرز Apache- یا GPLv3- لائسنس یافتہ پروجیکٹس میں تعاون کرتے ہیں، تو آپ اپنے پیٹنٹ کے تحت لائسنس دے رہے ہیں۔ اور اگر آپ کبھی بھی اپاچی کے لائسنس یافتہ اجزاء کی بنیاد پر کسی کمپنی کے خلاف پیٹنٹ کا دعویٰ کرتے ہیں، تو جوابی کارروائی سے آپ کو اس لائسنس کی قیمت لگ سکتی ہے جس پر آپ انحصار کرتے ہیں۔

EUPL اور ڈچ پبلک سیکٹر

یورپی یونین پبلک لائسنس ورژن 1.2، مئی 2017 میں فیصلے کو نافذ کرتے ہوئے یورپی کمیشن کی طرف سے منظور کیا گیا، تین امتیازی خصوصیات کے ساتھ OSI سے منظور شدہ کاپی لیفٹ لائسنس ہے۔

• زبان. یہ EU کی سرکاری زبانوں میں موجود ہے، تمام منظور شدہ ورژن ایک جیسی قدر کے حامل ہیں، اس لیے ڈچ اتھارٹی ڈچ میں معاہدہ کر سکتی ہے۔
• مطابقت۔ ایک ضمیمہ مطابقت پذیر لائسنسوں کی فہرست دیتا ہے — 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)۔ یو ایس فیڈرل سرکٹ Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008) میں اسی نتیجے پر پہنچا : لائسنس کی شرائط گرانٹ کے دائرہ کار کی شرائط ہیں، نہ کہ محض معاہدوں، اس لیے خلاف ورزی کاپی رائٹ کے دعوے اور حکم امتناعی کی حمایت کرتی ہے۔ امریکی قانونی چارہ جوئی اس بات کی کھوج کر رہی ہے کہ آیا نیچے کی طرف وصول کنندہ GPL کو فریق ثالث کے مستفید کے طور پر نافذ کر سکتا ہے۔ کیلیفورنیا کی سپیریئر کورٹ کے سامنے سافٹ ویئر فریڈم کنزروینسی بمقابلہ ویزیو میں یہی مرکزی سوال ہے : کیا صارفین، تیسرے فریق کے مستفید ہونے کے ناطے، GPLv2 کے تحت سورس کوڈ کے اجراء کا مطالبہ کر سکتے ہیں۔ 23 دسمبر 2025 کو عدالت نے سمری فیصلے پر ایک نکتہ کا فیصلہ کیا، جس میں کہا گیا کہ GPLv2 اور LGPLv2.1 کو ایسے ذریعہ کی ضرورت ہے جسے حاصل کیا جا سکتا ہے اور کسی اور جگہ استعمال کے لیے دوبارہ کام کیا جا سکتا ہے بجائے اس کے کہ آلہ پر اس کی فعالیت کو برقرار رکھتے ہوئے دوبارہ انسٹال کیا جا سکے۔ فریق ثالث سے فائدہ اٹھانے والا سوال خود بنچ کے مقدمے کے لیے چھوڑ دیا گیا تھا، جسے ایک سے زیادہ بار ملتوی کیا جا چکا ہے۔ یہ کسی بھی صورت میں کیلیفورنیا کا معاہدہ قانون کا سوال ہے، لہذا یہ نیدرلینڈز میں کسی چیز کا پابند نہیں ہے۔ اس سے کیا تبدیلی آئے گی شکایت کرنے کے قابل لوگوں کی تعداد۔

ڈچ عدالت اس سے کیسے رجوع کرے گی۔ Auteurswet کے تحت کاپی رائٹ کی خلاف ورزی کے طور پر: دعویدار ملکیت اور پنروتپادن یا مواصلات کو ثابت کرتا ہے؛ مدعا علیہ نے لائسنس اٹھایا؛ دعویدار جواب دیتا ہے کہ اس کی شرائط پوری نہیں ہوئیں، اس لیے دفاع ناکام ہو جاتا ہے۔ آرٹ کے تحت معاہدے کے علاج۔ 6:265 BW متوازی طور پر چلتا ہے، لیکن کاپی رائٹ مضبوط راستہ ہے۔

علاج۔ آرٹ کے تحت ایک حکم نامہ۔ 3:296 BW، عام طور پر جرمانے کی ادائیگی کے ساتھ اور خلاصہ کارروائی میں دستیاب؛ آرٹ کے تحت نقصانات 27 او اور آرٹ کے تحت منافع کا حساب۔ 27a آرٹ کے تحت یاد کرنا، ہتھیار ڈالنا یا تباہی کرنا۔ 28 اے; اور آرٹ کے تحت معقول اور متناسب قانونی اخراجات کی مکمل وصولی 1019h Rv جہاں سافٹ ویئر مفت تقسیم کیا گیا تھا، نقصان کا اندازہ لگانا مشکل ہے، اور ایک جرمن اپیل کورٹ نے حکم امتناعی کو برقرار رکھتے ہوئے ہرجانہ دینے سے انکار کر دیا (OLG Hamm 13 جون 2017، 4 U 72/16)۔ جو کاٹتا ہے وہ شاذ و نادر ہی نقصان پہنچاتا ہے: یہ حکم امتناعی، یاد دہانی، اخراجات کا حکم، اور وہ ذریعہ شائع کرنا ہے جسے آپ شائع کرنا کبھی نہیں چاہتے تھے۔

جب آپ کو تعمیل کا مسئلہ معلوم ہوتا ہے۔

دریافت عام طور پر گاہک کے حفاظتی سوالنامے، مستعدی کے دوران اسکین، یا حق دار کے خط سے آتی ہے۔ اس کے بعد تدارک اس طرح چلتا ہے۔ اگر نمائش سنگین ہو تو متاثرہ عمارت کی تقسیم کو روک دیں۔ کون سا جزو، کون سا ورژن، کون سا لائسنس، کون سی مصنوعات اور ریلیز، کس مدت میں قائم کریں۔ اس بات پر کام کریں کہ لائسنس کی اصل میں کیا ضرورت ہے — اکثر سورس ریلیز کے بجائے ایک انتساب فائل۔ نوادرات تیار کریں: نوٹس، لائسنس کے متن، مکمل متعلقہ ماخذ بشمول تعمیر اسکرپٹ، اور ایک تحریری پیشکش جہاں استعمال ہو۔ ایک تعمیل شدہ ریلیز بھیجیں، پھر حق دار کو بتائیں کہ آپ نے کیا کیا ہے اس پر بحث کرنے کی بجائے کہ آپ کو کرنا پڑا۔

GPLv3 اور AGPLv3 کے تحت کیور ونڈو رفتار کو قانونی قدر فراہم کرتی ہے۔ GPLv2 کے تحت کوئی علاج کا حق نہیں ہے، یہی وجہ ہے کہ زیادہ تر نفاذ گفت و شنید کی تعمیل پر ختم ہوتا ہے۔ یہ بھی نوٹ کریں کہ استحقاق آپ کے وکیل کے مشورے سے منسلک ہوتا ہے، اندرونی انجینئرنگ رپورٹ سے نہیں۔

M&A میں اوپن سورس اور مناسب تندہی

سافٹ ویئر کے حصول میں، اوپن سورس ایک معیاری محنتی کام کا سلسلہ ہے، اور بنیادی پروڈکٹ میں ایک غیر ظاہر شدہ کاپی لیفٹ جزو ان چند نتائج میں سے ایک ہے جو حقیقی طور پر کسی معاہدے کو آگے بڑھاتے ہیں: اگر پروڈکٹ کو اس کے ماخذ کو جاری کیے بغیر تقسیم نہیں کیا جا سکتا، تو خریدار قیمت سے مختلف اثاثہ حاصل کر رہا ہے۔

ایک کوڈبیس اسکین، لائسنس کے ساتھ اجزاء کی انوینٹری، اور شراکت دار اور ٹھیکیدار کے انتظامات کے بارے میں سوالات کی توقع کریں۔ عام نتائج ایک مخصوص معاوضہ، ایک برقراری زیر التواء تدارک، ایک شرط کی نظیر جس کو ہٹانے کی ضرورت ہوتی ہے، یا ایک مخصوص اوپن سورس وارنٹی۔ بیچنے والوں کو پہلے اسکین کرنا چاہیے: آپ جو نتائج ظاہر کرتے ہیں وہ مذاکرات ہیں، خریدار کے مشیر کی جانب سے جو نتائج سامنے آتے ہیں وہ فائدہ مند ہیں۔ خریداروں کو "کمپنی اپنے IP کی مالک ہے" نہیں بلکہ ایک ایسی نمائندگی تلاش کرنی چاہیے کہ کوئی بھی پروڈکٹ اوپن سورس کو شامل نہیں کرتا جس کے لیے ملکیتی سورس کوڈ کے انکشاف کی ضرورت ہوتی ہے۔

مواد کا بل، سکیننگ اور سائبر ریزیلینس ایکٹ

مواد کا ایک سافٹ ویئر بل مصنوعات کے اجزاء کی فہرست ہے، ورژن اور لائسنس کے ساتھ۔ حال ہی میں مکمل طور پر معاہدہ تک، اب یہ بھی ریگولیٹری ہے۔

سائبر ریزیلینس ایکٹ، ریگولیشن (EU) 2024/2847، 10 دسمبر 2024 کو نافذ ہوا اور مرحلہ وار شروع ہوا۔ یہ ڈچ سائبرسیکیوریٹی ایکٹ کے ساتھ بیٹھا ہے ، جو پروڈکٹ کے بجائے تنظیم کو مخاطب کرتا ہے۔ آرٹ میں فعال طور پر استحصال شدہ کمزوریوں اور شدید واقعات کے لیے رپورٹنگ کی ذمہ داریاں۔ 14 CRA 11 ستمبر 2026 سے اپلائی کریں گے۔ 11 جون 2026 سے کنفارمیٹی اسسمنٹ باڈیز کے نوٹیفکیشن پر دفعات؛ 11 دسمبر 2027 سے مکمل ضابطہ (آرٹ 71 CRA)۔ Annex I CRA مینوفیکچررز سے پروڈکٹ کے اجزاء کی شناخت اور دستاویز کرنے کا تقاضا کرتا ہے، بشمول عام طور پر استعمال شدہ اور مشین کے ذریعے پڑھنے کے قابل فارمیٹ میں مواد کا ایک سافٹ ویئر بل تیار کرنا جس میں انتہائی کم سے کم اعلیٰ سطح پر انحصار شامل ہو۔ اسے شائع کرنے کی ضرورت نہیں ہے۔ مارکیٹ کی نگرانی کے حکام اس کی درخواست کر سکتے ہیں۔

تجارتی سرگرمی کے باہر فراہم کردہ مفت اور اوپن سورس سافٹ ویئر CRA سے باہر آتا ہے۔ ریگولیشن میں اوپن سورس سافٹ ویئر اسٹیورڈ کو متعارف کرایا گیا ہے — ایک قانونی شخص جو تجارتی سرگرمیوں کے لیے اوپن سورس سافٹ ویئر کی ترقی کے لیے مستقل تعاون فراہم کرتا ہے — آرٹ میں ہلکی ذمہ داریوں کے ساتھ۔ 24 CRA: ایک دستاویزی سائبر سیکیورٹی پالیسی، مارکیٹ کی نگرانی کے حکام کے ساتھ تعاون، اور رپورٹنگ۔ اگر آپ اوپن سورس کو کمرشلائز کرتے ہیں، یا کسی پروجیکٹ کو دوسرے کمرشلائز کرتے ہیں، تو اس بات کا تعین کریں کہ آپ کون سا کردار ادا کرتے ہیں۔ کمیشن نے 27 جولائی 2026 کو اپنی پہلی رہنمائی کو اپنایا: سائبر ریسیلینس ایکٹ (CRA) کے اطلاق پر کمیشن کی رہنمائی، کمیونیکیشن C(2026) 5252 سے منسلک، جو کہ دیگر چیزوں کے ساتھ ساتھ جب فری اور اوپن سورس سافٹ ویئر دائرہ کار میں آتا ہے۔ مواد کے سافٹ ویئر بل کے لیے فارمیٹ تجویز کرنے والا کوئی عمل درآمد نہیں کیا گیا ہے، اس لیے ریگولیشن کا اپنا معیار - ایک عام طور پر استعمال ہونے والا، مشین سے پڑھنے کے قابل فارمیٹ - اس وقت کے لیے پیمانہ رہتا ہے۔

CI میں چلایا جانے والا سافٹ ویئر کمپوزیشن تجزیہ انوینٹری پیش کرنے کی تعمیل، لائسنس کا جائزہ اور مستعد ایک ساتھ پیدا کرتا ہے۔ اس طرح کے ٹولز وینڈرڈ کوڈ سے محروم رہتے ہیں، دوہری لائسنس والے پروجیکٹس کی غلط شناخت کرتے ہیں اور لائسنس کی شرائط کو نہیں پڑھ سکتے: آؤٹ پٹ کو جائزے کے آغاز کے طور پر سمجھیں، جائزے کو نہیں۔

اگر آپ اپنا کوڈ شائع کرتے ہیں: CLAs اور DCO

ایک کمپنی جو کوڈ جاری کرتی ہے اور باہر کے تعاون کو قبول کرتی ہے اسے یہ جاننا چاہیے کہ اس کے پاس انضمام کے حقوق ہیں۔ شراکت دار لائسنس کا معاہدہ پروجیکٹ اور شراکت کنندہ کے درمیان ایک معاہدہ ہوتا ہے، جو عام طور پر ایک وسیع کاپی رائٹ لائسنس اور ایک ایکسپریس پیٹنٹ لائسنس دیتا ہے، جس میں اصلیت اور اختیار کی ضمانت ہوتی ہے۔ یہ وہی ہے جو کمپنی کو بعد میں اپنے پروجیکٹ کو دوبارہ لائسنس دینے دیتا ہے، یا اوپن سورس کے ساتھ تجارتی لائسنس پیش کرتا ہے۔ اس کی قیمت رگڑ ہے۔

ڈیولپر سرٹیفکیٹ آف اوریجن ، جو لینکس کرنل اور بہت سے دوسرے پروجیکٹس کے ذریعہ استعمال کیا جاتا ہے، لائسنس گرانٹ نہیں ہے بلکہ ایک ہلکا پھلکا تصدیق ہے، جو ہر کمٹ میں سائن آف لائن کے طور پر شامل کیا جاتا ہے، تاکہ شراکت کنندہ پروجیکٹ کے لائسنس کے تحت کوڈ جمع کراسکے۔ کم بوجھل، اور کم حفاظتی: کوئی پیٹنٹ لائسنس، کوئی دوبارہ لائسنسنگ نہیں۔

اگر دوہری لائسنسنگ یا مستقبل کی رضامندی قابل فہم ہے، تو CLA استعمال کریں۔ اگر پراجیکٹ حقیقی عام ہے، تو ڈی سی او عام طور پر کافی ہوتا ہے۔ کسی بھی طرح سے، یقینی بنائیں کہ آپ کے روزگار اور ٹھیکیدار کے معاہدے آپ کے لوگوں کے لکھے ہوئے کوڈ میں کاپی رائٹ تفویض کرتے ہیں۔

ایک عملی پالیسی چیک لسٹ

• فی پروڈکٹ اجزاء کی انوینٹری بنائیں اور ہاتھ سے نہیں بلکہ تعمیراتی پائپ لائن میں جاری کریں۔
• ایک داخلی پالیسی شائع کریں: ایک اجازت یافتہ فہرست، ایک ممنوعہ فہرست اور ہر چیز کے لیے منظوری کا راستہ۔
• تحریری طور پر وضاحت کریں کہ تقسیم کے طور پر کیا شمار ہوتا ہے — آن پریمائز انسٹالز، آلات، کنٹینرز، SDKs، موبائل ایپس، فرم ویئر۔
• ہر پروڈکٹ کے ساتھ تیار کردہ انتساب فائل بھیجیں۔
• لائسنس کے انتخاب کو ڈیزائن کے وقت منظور کریں، جب کوئی جزو منتخب کیا جاتا ہے، ریلیز کے وقت نہیں۔
• فیصلہ کریں کہ آیا بیرونی منصوبوں میں شراکت کو منظوری کی ضرورت ہے، اس میں شامل پیٹنٹ گرانٹس کو دیکھتے ہوئے، اور پہلی بیرونی شراکت سے پہلے ایک CLA یا DCO کا انتخاب کریں۔
• آئی پی وارنٹی، معاوضے اور ایسکرو شرائط کو اصل میں پروڈکٹ میں اوپن سورس کے ساتھ سیدھ میں رکھیں۔
• جائزہ کو فنڈ ریزنگ یا فروخت کے عمل سے پہلے چلائیں، ایک کے دوران نہیں۔

Law & More سافٹ ویئر کمپنیوں اور ان کے سرمایہ کاروں کو مشورہ دیتا ہے۔ Eindhoven اور Amsterdam لین دین میں اوپن سورس کی تعمیل، لائسنس کا جائزہ، شراکت دار کے انتظامات اور اوپن سورس ورک اسٹریم پر۔