اوپن سورس کے قانونی مضمرات کو سمجھنا

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

لوگ اوپن سورس کے قانونی پہلو کی اتنی پرواہ کیوں کرتے ہیں؟

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

عام طور پر، اس کا مطلب ہے کہ کوئی اور آپ کے کام کو ٹیک ڈاؤن، شیک ڈاؤن، یا قانونی چارہ جوئی کے خطرے کے بغیر استعمال، کاپی، تقسیم یا ترمیم نہیں کر سکتا۔

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

اگر آپ اوپن سورس لائسنس کا اطلاق نہیں کرتے ہیں، تو ہر وہ شخص جو آپ کے پروجیکٹ میں تعاون کرتا ہے اپنے کام کا خصوصی کاپی رائٹ ہولڈر بن جاتا ہے۔ اس کا مطلب ہے کہ کوئی بھی اپنے تعاون کو استعمال، کاپی، تقسیم یا ترمیم نہیں کر سکتا – اور یہ کہ “کوئی بھی” آپ کو شامل نہیں کرتا ہے۔

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

کیا عوامی GitHub پروجیکٹ اوپن سورس ہیں؟

جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں تو آپ کے پاس ریپوزٹری کو نجی یا **عوامی بنانے کا اختیار ہوتا ہے۔ **

ذخیرہ بنائیں

اپنے GitHub پروجیکٹ کو عوامی بنانا اپنے پروجیکٹ کو لائسنس دینے کے مترادف ہے۔ عوامی پروجیکٹس [GitHub کی سروس کی شرائط] (https://help.github.com/en/github/site-policy/github-) کے تحت آتے ہیں۔ سروس کی شرائط#3-مالک-آف-مواد-کے-دائیں-سے-پوسٹ-اور-لائسنس-گرانٹس)، جو دوسروں کو آپ کے پروجیکٹ کو دیکھنے اور فورک کرنے کی اجازت دیتی ہے، لیکن آپ کا کام بصورت دیگر بغیر اجازت کے آتا ہے۔

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

بس مجھے TL؛ DR دیں کہ مجھے اپنے پروجیکٹ کی حفاظت کے لیے کیا ضرورت ہے۔

آپ خوش قسمت ہیں، کیونکہ آج اوپن سورس لائسنس معیاری اور استعمال میں آسان ہیں۔ آپ کسی موجودہ لائسنس کو براہ راست اپنے پروجیکٹ میں کاپی پیسٹ کر سکتے ہیں۔

MIT، Apache 2.0، اور GPLv3 سب سے زیادہ مقبول اوپن سورس لائسنسز ہیں، لیکن انتخاب کرنے کے لیے دیگر آپشنز موجود ہیں۔ آپ ان لائسنسوں کا مکمل متن، اور ان کے استعمال کے بارے میں ہدایات choosealicense.com پر حاصل کر سکتے ہیں۔

جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں، تو آپ سے لائسنس شامل کرنے کے لیے کہا جائے گا۔

میرے پروجیکٹ کے لیے کون سا اوپن سورس لائسنس مناسب ہے؟

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

بصورت دیگر، اپنے پروجیکٹ کے لیے صحیح اوپن سورس لائسنس کا انتخاب آپ کے مقاصد پر منحصر ہے۔

آپ کے پروجیکٹ میں انحصارات ہونے کا بہت امکان ہے (یا ہوگا)۔ مثال کے طور پر، اگر آپ Node.js پروجیکٹ کو اوپن سورس کر رہے ہیں، تو آپ شاید نوڈ پیکیج مینیجر (npm) کی لائبریریاں استعمال کریں گے۔ ان لائبریریوں میں سے ہر ایک جس پر آپ انحصار کرتے ہیں اس کا اپنا اوپن سورس لائسنس ہوگا۔ اگر ان کا ہر لائسنس “اجازت مند” ہے (عوام کو استعمال کرنے، ترمیم کرنے، اور شیئر کرنے کی اجازت دیتا ہے، بغیر کسی شرط کے ڈاؤن اسٹریم لائسنسنگ)، آپ جو بھی لائسنس چاہتے ہیں استعمال کر سکتے ہیں۔ عام اجازت یافتہ لائسنسوں میں MIT، Apache 2.0، ISC، اور BSD شامل ہیں۔

دوسری طرف، اگر آپ کے کسی بھی انحصار کا لائسنس “مضبوط کاپی لیفٹ” ہے (عوامی کو بھی وہی اجازت دیتا ہے، جو اسی لائسنس کو نیچے کی طرف استعمال کرنے کی شرط سے مشروط ہے)، تو آپ کے پروجیکٹ کو وہی لائسنس استعمال کرنا پڑے گا۔ عام مضبوط کاپی لیفٹ لائسنسوں میں GPLv2، GPLv3، اور AGPLv3 شامل ہیں۔

آپ ان کمیونٹیز پر بھی غور کر سکتے ہیں جن کی آپ کو امید ہے کہ وہ آپ کے پروجیکٹ میں استعمال کریں گے اور تعاون کریں گے:

  • کیا آپ چاہتے ہیں کہ آپ کے پروجیکٹ کو دوسرے پروجیکٹس کے ذریعے انحصار کے طور پر استعمال کیا جائے؟ اپنی متعلقہ کمیونٹی میں سب سے زیادہ مقبول لائسنس کا استعمال کرنا شاید بہتر ہے۔ مثال کے طور پر، MIT npm لائبریریوں کے لیے سب سے مقبول لائسنس ہے۔
  • کیا آپ چاہتے ہیں کہ آپ کا پروجیکٹ بڑے کاروباروں کے لیے اپیل کرے؟ ایک بڑا کاروبار ممکنہ طور پر تمام شراکت داروں سے ایک ایکسپریس پیٹنٹ لائسنس چاہتا ہے۔ اس معاملے میں، Apache 2.0 نے آپ (اور ان کو) کور کیا ہے۔
  • کیا آپ چاہتے ہیں کہ آپ کا پروجیکٹ ان شراکت داروں سے اپیل کرے جو نہیں چاہتے کہ ان کے تعاون کو بند سورس سافٹ ویئر میں استعمال کیا جائے؟ GPLv3 یا (اگر وہ بند سورس سروسز میں حصہ ڈالنا بھی نہیں چاہتے ہیں)

آپ کی کمپنی کے اوپن سورس پروجیکٹس کے لیے مخصوص لائسنسنگ کے تقاضے ہو سکتے ہیں۔ مثال کے طور پر، اسے اجازت دینے والے لائسنس کی ضرورت ہو سکتی ہے تاکہ کمپنی آپ کے پروجیکٹ کو کمپنی کے بند سورس پروڈکٹ میں استعمال کر سکے۔ یا آپ کی کمپنی کو ایک مضبوط کاپی لیفٹ لائسنس اور ایک اضافی شراکت دار معاہدے کی ضرورت ہو سکتی ہے (نیچے دیکھیں) تاکہ صرف آپ کی کمپنی، اور کوئی اور آپ کے پروجیکٹ کو بند سورس سافٹ ویئر میں استعمال نہ کر سکے۔ یا آپ کی کمپنی کو معیارات، سماجی ذمہ داری، یا شفافیت سے متعلق کچھ ضروریات ہو سکتی ہیں، جن میں سے کسی کو بھی لائسنسنگ کی مخصوص حکمت عملی کی ضرورت ہو سکتی ہے۔ اپنے [کمپنی کے قانونی شعبے] سے بات کریں (#what-does-my-companys-legal-team-need-to-know)۔

جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں، تو آپ کو لائسنس منتخب کرنے کا اختیار دیا جاتا ہے۔ مذکورہ لائسنسوں میں سے ایک کو شامل کرنا آپ کے GitHub پروجیکٹ کو اوپن سورس بنا دے گا۔ اگر آپ دوسرے اختیارات دیکھنا چاہتے ہیں تو اپنے پروجیکٹ کے لیے صحیح لائسنس تلاش کرنے کے لیے choosealicense.com کو دیکھیں، چاہے یہ سافٹ ویئر نہیں ہے .com/non-software/)۔

اگر میں اپنے پروجیکٹ کا لائسنس تبدیل کرنا چاہتا ہوں تو کیا ہوگا؟

زیادہ تر منصوبوں کو کبھی بھی لائسنس تبدیل کرنے کی ضرورت نہیں ہوتی ہے۔ لیکن کبھی کبھار حالات بدل جاتے ہیں۔

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

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

آپ کے پروجیکٹ کا موجودہ لائسنس۔ اگر آپ کے پروجیکٹ کا موجودہ لائسنس اس لائسنس کے ساتھ مطابقت رکھتا ہے جس میں آپ تبدیل کرنا چاہتے ہیں، تو آپ بس نئے لائسنس کا استعمال شروع کر سکتے ہیں۔ اس کی وجہ یہ ہے کہ اگر لائسنس A لائسنس B کے ساتھ مطابقت رکھتا ہے، تو آپ B کی شرائط کی تعمیل کرتے ہوئے A کی شرائط کی تعمیل کریں گے (لیکن ضروری نہیں کہ اس کے برعکس ہو)۔ لہذا اگر آپ فی الحال اجازت دینے والا لائسنس استعمال کر رہے ہیں (مثال کے طور پر، MIT)، تو آپ مزید شرائط کے ساتھ لائسنس میں تبدیل ہو سکتے ہیں، جب تک کہ آپ MIT لائسنس کی ایک کاپی اور کسی بھی متعلقہ کاپی رائٹ نوٹس (یعنی، کی تعمیل جاری رکھیں) MIT لائسنس کی کم سے کم شرائط)۔ لیکن اگر آپ کا موجودہ لائسنس قابل اجازت نہیں ہے (مثال کے طور پر کاپی لیفٹ، یا آپ کے پاس لائسنس نہیں ہے) اور آپ واحد کاپی رائٹ ہولڈر نہیں ہیں، تو آپ اپنے پروجیکٹ کے لائسنس کو MIT میں تبدیل نہیں کر سکتے۔ بنیادی طور پر، اجازت دینے والے لائسنس کے ساتھ پروجیکٹ کے کاپی رائٹ ہولڈرز نے لائسنس تبدیل کرنے کی پیشگی اجازت دے دی ہے۔

آپ کے پراجیکٹ کے موجودہ کاپی رائٹ ہولڈرز۔ اگر آپ اپنے پروجیکٹ کے واحد تعاون کنندہ ہیں تو آپ یا آپ کی کمپنی پروجیکٹ کے واحد کاپی رائٹ ہولڈر ہیں۔ آپ جو بھی لائسنس آپ یا آپ کی کمپنی چاہتے ہیں اس میں شامل یا تبدیل کر سکتے ہیں۔ بصورت دیگر کاپی رائٹ ہولڈرز ہو سکتے ہیں جن سے آپ کو لائسنس تبدیل کرنے کے لیے معاہدے کی ضرورت ہے۔ وہ کون ہیں؟ جو لوگ آپ کے پروجیکٹ میں کام کرتے ہیں وہ شروع کرنے کے لیے ایک اچھی جگہ ہے۔ لیکن کچھ معاملات میں کاپی رائٹ ان لوگوں کے آجروں کے پاس ہوگا۔ کچھ معاملات میں لوگوں نے صرف کم سے کم تعاون کیا ہوگا، لیکن اس میں کوئی سخت اور تیز قاعدہ نہیں ہے کہ کوڈ کی کچھ لائنوں کے تحت کی جانے والی شراکتیں کاپی رائٹ کے تابع نہ ہوں۔ کیا کرنا ہے؟ یہ منحصر کرتا ہے. نسبتاً چھوٹے اور نوجوان پروجیکٹ کے لیے، یہ ممکن ہو سکتا ہے کہ تمام موجودہ شراکت داروں کو کسی مسئلے میں لائسنس کی تبدیلی یا پل کی درخواست پر رضامندی دلائیں۔ بڑے اور طویل المدتی منصوبوں کے لیے، آپ کو بہت سے شراکت داروں اور یہاں تک کہ ان کے وارثوں کو تلاش کرنا پڑ سکتا ہے۔ موزیلا کو فائر فاکس، تھنڈر برڈ، اور متعلقہ سافٹ ویئر کو دوبارہ لائسنس دینے میں (2001-2006) سال لگے۔

متبادل طور پر، آپ شراکت کنندگان کو کچھ شرائط کے تحت لائسنس کی کچھ تبدیلیوں کے لیے پیشگی (اضافی شراکت کنندہ کے معاہدے کے ذریعے - نیچے دیکھیں) سے اتفاق کر سکتے ہیں، جو آپ کے موجودہ اوپن سورس لائسنس کی اجازت سے ہٹ کر ہے۔ یہ لائسنسوں کو تبدیل کرنے کی پیچیدگی کو تھوڑا سا بدل دیتا ہے۔ آپ کو سامنے اپنے وکلاء سے مزید مدد کی ضرورت ہوگی، اور آپ پھر بھی لائسنس کی تبدیلی کو انجام دیتے وقت اپنے پروجیکٹ کے اسٹیک ہولڈرز سے واضح طور پر بات چیت کرنا چاہیں گے۔

کیا میرے پروجیکٹ کو شراکت دار کے اضافی معاہدے کی ضرورت ہے؟

شاید نہیں۔ اوپن سورس پروجیکٹس کی اکثریت کے لیے، اوپن سورس لائسنس واضح طور پر ان باؤنڈ (مطابقت کنندگان سے) اور آؤٹ باؤنڈ (دوسرے شراکت داروں اور صارفین کے لیے) لائسنس کے طور پر کام کرتا ہے۔ اگر آپ کا پروجیکٹ GitHub پر ہے تو، GitHub کی سروس کی شرائط “inbound=outbound” کو explicit default۔

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

اس کے علاوہ، “کاغذی کارروائی” کو شامل کرنے سے جو کچھ کے خیال میں غیر ضروری، سمجھنا مشکل، یا غیر منصفانہ ہے (جب معاہدے کے وصول کنندہ کو شراکت داروں یا عوام کو پروجیکٹ کے اوپن سورس لائسنس کے ذریعے سے زیادہ حقوق ملتے ہیں)، ایک اضافی شراکت کنندہ کے معاہدے کو غیر دوستانہ سمجھا جا سکتا ہے۔ پروجیکٹ کی کمیونٹی کو۔

کچھ حالات جہاں آپ اپنے پروجیکٹ کے لیے اضافی شراکت دار کے معاہدے پر غور کرنا چاہتے ہیں ان میں شامل ہیں:

  • آپ کے وکلاء چاہتے ہیں کہ تمام شراکت دار واضح طور پر (sign، آن لائن یا آف لائن) شراکت کی شرائط کو قبول کریں، شاید اس لیے کہ انہیں لگتا ہے کہ اوپن سورس لائسنس خود کافی نہیں ہے (حالانکہ یہ ہے!) اگر یہ واحد تشویش ہے تو، ایک شراکت دار معاہدہ جو پروجیکٹ کے اوپن سورس لائسنس کی توثیق کرتا ہے کافی ہونا چاہئے۔ jQuery Individual Contributor License Agreement ہلکے وزن کے اضافی کنٹریبیوٹر کے معاہدے کی ایک اچھی مثال ہے۔
  • آپ یا آپ کے وکلاء چاہتے ہیں کہ ڈویلپر اس بات کی نمائندگی کریں کہ وہ جو بھی عہد کرتے ہیں وہ مجاز ہے۔ ایک Developer Certificate of Origin کی ضرورت یہ ہے کہ کتنے پروجیکٹ اسے حاصل کرتے ہیں۔ مثال کے طور پر، Node.js کمیونٹی استعمال کرتا ہے DCO اس کے بجائے۔ آپ کے ذخیرے پر DCO کے نفاذ کو خودکار کرنے کا ایک آسان آپشن DCO Probot ہے۔
  • آپ کا پروجیکٹ اوپن سورس لائسنس کا استعمال کرتا ہے جس میں ایکسپریس پیٹنٹ گرانٹ شامل نہیں ہے (جیسے MIT)، اور آپ کو تمام شراکت داروں سے پیٹنٹ گرانٹ کی ضرورت ہے، جن میں سے کچھ بڑے پیٹنٹ پورٹ فولیوز والی کمپنیوں کے لیے کام کر سکتی ہیں جو آپ کو نشانہ بنانے کے لیے استعمال ہو سکتی ہیں۔ یا پروجیکٹ کے دوسرے معاونین اور صارفین۔ Apache Individual Contributor License Agreement ایک عام طور پر استعمال ہونے والا اضافی شراکت دار معاہدہ ہے جس میں پیٹنٹ گرانٹ ہے جو Apache لائسنس 2.0 میں پایا جاتا ہے۔
  • آپ کا پروجیکٹ کاپی لیفٹ لائسنس کے تحت ہے، لیکن آپ کو پروجیکٹ کا ملکیتی ورژن بھی تقسیم کرنا ہوگا۔ آپ کو کاپی رائٹ تفویض کرنے یا آپ کو (لیکن عوام کو نہیں) اجازت دینے والا لائسنس دینے کے لیے ہر تعاون کنندہ کی ضرورت ہوگی۔ MongoDB Contributor Agreement اس قسم کے معاہدے کی ایک مثال ہے۔
  • آپ کو لگتا ہے کہ آپ کے پروجیکٹ کو اس کی زندگی بھر کے لیے لائسنسوں کو تبدیل کرنے کی ضرورت پڑ سکتی ہے اور آپ چاہتے ہیں کہ شراکت دار اس طرح کی تبدیلیوں کے لیے پیشگی اتفاق کریں۔

اگر آپ کو اپنے پروجیکٹ کے ساتھ اضافی کنٹریبیوٹر کا معاہدہ استعمال کرنے کی ضرورت ہے، تو کنٹریبیوٹر کی خلفشار کو کم کرنے کے لیے انٹیگریشن جیسے CLA اسسٹنٹ استعمال کرنے پر غور کریں۔

میری کمپنی کی قانونی ٹیم کو کیا جاننے کی ضرورت ہے؟

اگر آپ کمپنی کے ملازم کے طور پر اوپن سورس پروجیکٹ جاری کر رہے ہیں، تو پہلے، آپ کی قانونی ٹیم کو معلوم ہونا چاہیے کہ آپ کسی پروجیکٹ کو اوپن سورس کر رہے ہیں۔

بہتر یا بدتر کے لیے، انہیں بتانے پر غور کریں چاہے یہ ایک ذاتی پروجیکٹ ہو۔ شاید آپ کا اپنی کمپنی کے ساتھ “ملازمین کا IP معاہدہ” ہے جو انہیں آپ کے پروجیکٹس کا کچھ کنٹرول دیتا ہے، خاص طور پر اگر وہ کمپنی کے کاروبار سے بالکل متعلق ہوں یا آپ پروجیکٹ کو تیار کرنے کے لیے کمپنی کے کسی وسائل کا استعمال کرتے ہوں۔ آپ کی کمپنی کو آسانی سے آپ کو اجازت دینی چاہیے، اور ہو سکتا ہے کہ پہلے سے ہی ملازم دوست IP معاہدے یا کمپنی کی پالیسی کے ذریعے ہو۔ اگر نہیں، تو آپ گفت و شنید کر سکتے ہیں (مثال کے طور پر، وضاحت کریں کہ آپ کا پروجیکٹ آپ کے لیے کمپنی کے پیشہ ورانہ سیکھنے اور ترقی کے مقاصد کو پورا کرتا ہے)، یا جب تک آپ کو کوئی بہتر کمپنی نہ مل جائے اپنے پروجیکٹ پر کام کرنے سے گریز کریں۔

**اگر آپ اپنی کمپنی کے لیے کسی پروجیکٹ کو اوپن سورس کر رہے ہیں، تو انہیں ضرور بتائیں۔ آپ کی قانونی ٹیم کے پاس کمپنی کی کاروباری ضروریات اور اس بات کو یقینی بنانے کے بارے میں مہارت کی بنیاد پر اوپن سورس لائسنس (اور ہوسکتا ہے کہ اضافی کنٹریبیوٹر ایگریمنٹ) استعمال کرنے کے لیے پہلے سے ہی پالیسیاں موجود ہیں تاکہ یہ یقینی بنایا جا سکے کہ آپ کا پروجیکٹ اس کے انحصار کے لائسنس کی تعمیل کرتا ہے۔ اگر نہیں، تو آپ اور وہ قسمت میں ہیں! آپ کی قانونی ٹیم کو اس چیز کا پتہ لگانے کے لیے آپ کے ساتھ کام کرنے کے لیے بے تاب ہونا چاہیے۔ سوچنے کے لیے کچھ چیزیں:

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

  • تجارتی راز: غور کریں کہ کیا اس پروجیکٹ میں کوئی ایسی چیز ہے جسے کمپنی عام لوگوں کے لیے دستیاب نہیں کرانا چاہتی۔ اگر ایسا ہے تو، آپ جس مواد کو نجی رکھنا چاہتے ہیں اسے نکالنے کے بعد، آپ اپنے باقی پروجیکٹ کو اوپن سورس کر سکتے ہیں۔

  • پیٹنٹ: کیا آپ کی کمپنی کسی ایسے پیٹنٹ کے لیے درخواست دے رہی ہے جس کی اوپن سورسنگ سے آپ کا پروجیکٹ عوامی انکشاف پر مشتمل ہوگا؟ افسوس کی بات ہے، آپ کو انتظار کرنے کے لیے کہا جا سکتا ہے (یا ہو سکتا ہے کہ کمپنی درخواست کی حکمت پر نظر ثانی کرے گی)۔ اگر آپ بڑے پیٹنٹ پورٹ فولیوز والی کمپنیوں کے ملازمین سے اپنے پروجیکٹ میں شراکت کی توقع کر رہے ہیں، تو آپ کی قانونی ٹیم آپ کو شراکت داروں (جیسے Apache 2.0 یا GPLv3) کی طرف سے ایکسپریس پیٹنٹ گرانٹ کے ساتھ لائسنس استعمال کرنے کی خواہش کر سکتی ہے، یا ایک اضافی شراکت دار معاہدہ ( اوپر ملاحظہ کریں).

  • ٹریڈ مارکس: دو بار چیک کریں کہ آپ کے پروجیکٹ کا نام کسی موجودہ ٹریڈ مارکس سے متصادم نہیں ہے۔ اگر آپ پروجیکٹ میں اپنی کمپنی کے ٹریڈ مارک استعمال کرتے ہیں، تو چیک کریں کہ اس سے کوئی تنازعہ تو نہیں بنتا۔ FOSSmarks مفت اور اوپن سورس پروجیکٹس کے تناظر میں ٹریڈ مارکس کو سمجھنے کے لیے ایک عملی گائیڈ ہے۔

  • رازداری: کیا آپ کا پروجیکٹ صارفین کا ڈیٹا اکٹھا کرتا ہے؟ کمپنی کے سرورز کو “فون ہوم”؟ آپ کی قانونی ٹیم کمپنی کی پالیسیوں اور بیرونی ضوابط کی تعمیل میں آپ کی مدد کر سکتی ہے۔

اگر آپ اپنی کمپنی کا پہلا اوپن سورس پروجیکٹ جاری کر رہے ہیں، تو اوپر سے گزرنے کے لیے کافی ہے (لیکن فکر نہ کریں، زیادہ تر پروجیکٹس کو کوئی بڑی تشویش نہیں ہونی چاہیے)۔

طویل مدتی، آپ کی قانونی ٹیم کمپنی کی اوپن سورس میں شمولیت سے مزید فائدہ اٹھانے اور محفوظ رہنے میں مدد کرنے کے لیے مزید کچھ کر سکتی ہے:

  • ملازمین کی شراکت کی پالیسیاں: ایک کارپوریٹ پالیسی تیار کرنے پر غور کریں جو یہ بتاتی ہو کہ آپ کے ملازمین اوپن سورس پروجیکٹس میں کس طرح تعاون کرتے ہیں۔ ایک واضح پالیسی آپ کے ملازمین کے درمیان الجھن کو کم کرے گی اور کمپنی کے بہترین مفاد میں اوپن سورس پروجیکٹس میں حصہ ڈالنے میں ان کی مدد کرے گی، چاہے وہ ان کی ملازمت کے حصے کے طور پر ہو یا اپنے فارغ وقت میں۔ ایک اچھی مثال Rackspace کی ماڈل IP اور اوپن سورس کنٹری بیوشن پالیسی ہے۔
  • کیا جاری کرنا ہے: (تقریباً) سب کچھ؟ اگر آپ کی قانونی ٹیم سمجھتی ہے اور آپ کی کمپنی کی اوپن سورس حکمت عملی میں سرمایہ کاری کی گئی ہے، وہ آپ کی کوششوں میں رکاوٹ ڈالنے کے بجائے مدد کرنے کے بہترین اہل ہوں گے۔
  • تعمیل: یہاں تک کہ اگر آپ کی کمپنی کوئی اوپن سورس پروجیکٹ جاری نہیں کرتی ہے، تو وہ دوسروں کے اوپن سورس سافٹ ویئر کا استعمال کرتی ہے۔ آگاہی اور عمل سر درد، مصنوعات میں تاخیر، اور قانونی چارہ جوئی کو روک سکتا ہے۔ .
  • پیٹنٹ: آپ کی کمپنی اوپن انوینشن نیٹ ورک میں شامل ہونا چاہتی ہے، جو ایک مشترکہ دفاعی پیٹنٹ پول ہے جو ممبران کے بڑے اوپن سورس پروجیکٹس کے استعمال کی حفاظت کرتا ہے، یا دریافت کرتا ہے۔ دیگر متبادل پیٹنٹ لائسنسنگ۔
  • گورننس: خاص طور پر اگر اور جب کسی پروجیکٹ کو [کمپنی سے باہر قانونی ادارہ] میں منتقل کرنا سمجھ میں آتا ہے (../leadership-and-governance/#do-i-need-a-legal-entity -میرے پروجیکٹ کی حمایت کرنے کے لیے)۔