10.12 اوپن سورس بمقابلہ کلوزڈ سورس

جائزہ اور محرکات

تقریباً ہر جدید نظام اس سافٹ ویئر کا امتزاج ہے جو آپ نے لکھا، جو آپ نے خریدا، اور جو آپ نے مفت لیا۔ ان میں سے دو کے ساتھ بنیادی انتخاب آتا ہے: کیا سافٹ ویئر اوپن سورس ہے یا کلوزڈ سورس؟ اوپن سورس سافٹ ویئر (OSS) ایسے لائسنس کے تحت تقسیم ہوتا ہے جو ہر کسی کو سورس کوڈ، یعنی پروگرام کی تعریف کرنے والی انسان کے پڑھنے کے قابل ہدایات، استعمال کرنے، مطالعہ کرنے، ترمیم کرنے، اور دوبارہ تقسیم کرنے کا حق دیتا ہے۔ کلوزڈ سورس سافٹ ویئر، جسے ملکیتی سافٹ ویئر بھی کہتے ہیں، تیار شدہ پروڈکٹ کے طور پر تقسیم ہوتا ہے جس کا سورس کوڈ فروخت کنندہ نجی رکھتا ہے۔ آپ کو لائسنس کے تحت اسے چلانے کا حق ملتا ہے، مگر یہ دیکھنے یا بدلنے کا نہیں کہ یہ کیسے کام کرتا ہے۔ درمیانی قسم، source-available سافٹ ویئر، سورس پڑھنے کے لیے شائع کرتی ہے مگر استعمال، ترمیم، یا دوبارہ تقسیم پر پابندی لگاتی ہے۔ یہ معیاری تعریف کے مطابق نظر آنے والا ہے مگر کھلا نہیں۔

موازنے سے پہلے دو وضاحتیں اہم ہیں۔ پہلی، “free” مبہم ہے۔ کمیونٹی free-as-in-freedom (ترمیم اور بانٹنے کی آزادی، کبھی “libre” لکھا جاتا ہے) کو free-as-in-price (صفر لاگت، “gratis”) سے ممتاز کرتی ہے۔ اوپن سورس آزادی کے بارے میں ہے، ضروری نہیں قیمت کے بارے میں۔ دوسری، اوپن سورس لائسنس دو خاندانوں میں بٹتے ہیں۔ Permissive لائسنس (جیسے MIT، BSD، اور Apache 2.0) آپ کو تقریباً کچھ بھی کرنے دیتے ہیں، بشمول کوڈ کو کلوزڈ پروڈکٹ میں شامل کرنا۔ Copyleft لائسنس (جیسے GNU General Public Licence، GPL) تقاضا کرتے ہیں کہ آپ کے تقسیم کردہ مشتق کام بھی انہی کھلی شرائط پر جاری ہوں، ایسا باہمی اصول جسے ناقدین “viral” اور حامی “share-alike” کہتے ہیں۔

یہ باب انتخاب کو دو طرف سے دیکھتا ہے۔ بطور صارف آپ فیصلہ کرتے ہیں کہ اوپن سورس یا ملکیتی جزو اپنائیں۔ بطور پیدا کنندہ آپ فیصلہ کرتے ہیں کہ اپنا بنایا سافٹ ویئر اوپن سورس کریں یا نہیں۔ بڑے اداروں اور خاص طور پر حکومت کے لیے دونوں فیصلے لائسنس فائل سے کہیں زیادہ وزن رکھتے ہیں۔ وہ خریداری (باب 10.3)، ڈیجیٹل خودمختاری (باب 10.11)، سپلائی چین کی سیکیورٹی (باب 4.2)، باہمی عمل پذیری (باب 3.8)، اور بنانے-یا-خریدنے کے حساب (باب 6.1) کو چھوتے ہیں۔

بنیادی اصول

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

سفارشات

جزو کو صرف لائسنس پر نہیں، پراجیکٹ پر پرکھیں

کوئی بھی انحصار، اوپن سورس یا ملکیتی، اپنانے سے پہلے اس کی صحت کا اندازہ لگائیں: ریلیز کی تال، maintainers کی تعداد اور تنوع، سیکیورٹی رپورٹس پر ردعمل، اور اپنانے کی وسعت۔ واحد maintainer والی اوپن سورس لائبریری اور چھوٹا ملکیتی فروخت کنندہ ایک ہی bus-factor خطرہ رکھتے ہیں (یہ خطرہ کہ ایک یا چند کلیدی لوگوں کے جانے پر پراجیکٹ ڈھے جائے)۔ وسیع شراکت داروں یا مالی طور پر مضبوط فروخت کنندہ والے اجزا کو ترجیح دیں، اور جائزہ due diligence کے حصے کے طور پر ریکارڈ کریں (ابواب 10.2، 4.2)۔

لائسنسوں کو اولین درجے کی ذمہ داری کے طور پر پڑھیں اور ٹریک کریں

ہر جزو اور اس کے لائسنس کی فہرست رکھیں، اور پالیسی نافذ کریں کہ کن استعمالات کے لیے کون سے لائسنس خاندان قابل قبول ہیں۔ فیصلہ کن فرق copyleft ہے۔ Permissive کوڈ (MIT، Apache 2.0) عموماً کلوزڈ پروڈکٹس میں آزادانہ شامل ہو سکتا ہے۔ مضبوط copyleft (GPL) آپ کو اپنے تقسیم کردہ مشتق کو انہی شرائط پر جاری کرنے کا پابند کر سکتا ہے۔ خودکار software composition analysis (SCA) استعمال کریں، ایسے آلات جو آپ کے انحصار اسکین کر کے اجزا، لائسنس، اور معلوم کمزوریاں پہچانتے ہیں، اور software bill of materials (SBOM) بنائیں، پروڈکٹ کے ہر جزو کی رسمی فہرست (ابواب 10.3، 4.2)۔

سیکیورٹی کا فیصلہ عمل سے کریں، کھلے پن سے نہیں

یہ نہ فرض کریں کہ اوپن سورس “many eyes” دلیل (Linus کا قانون: “کافی آنکھیں ہوں تو ہر bug اتھلا ہے”) کی وجہ سے محفوظ ہے۔ اور نہ فرض کریں کہ ملکیتی کوڈ security-through-obscurity (یہ ناقص یقین کہ سورس چھپانے سے خامیاں چھپتی ہیں) سے محفوظ ہے۔ بہت سی آنکھیں تبھی مدد کرتی ہیں جب اہل لوگ واقعی دیکھیں، اور بہت سے وسیع استعمال شدہ پراجیکٹس کم سنبھالے جاتے ہیں۔ دونوں ماڈل سپلائی چین کا خطرہ رکھتے ہیں: اوپن سورس سمجھوتہ شدہ یا متروک انحصار کے ذریعے، ملکیتی مبہم کوڈ اور ایسے اپ ڈیٹ چینلز کے ذریعے جنہیں آپ جانچ نہیں سکتے۔ ماڈل سے قطع نظر ورژن pin کریں، ماخذ کی توثیق کریں، مسلسل اسکین کریں، اور advisories پر نظر رکھیں (باب 4.2)۔

اخراج اور باہمی عمل پذیری کے لیے ڈیزائن کریں

ایسے اجزا کو ترجیح دیں جو کھلے معیارات اور پورٹیبل ڈیٹا فارمیٹس بولتے ہیں، تاکہ آپ بعد میں انہیں بدل سکیں (ابواب 3.8، 10.11)۔ اوپن سورس کے ساتھ آپ کو حتمی اخراج ملتا ہے: اگر پراجیکٹ رک جائے تو آپ اسے fork کر سکتے ہیں (اپنی نقل بنا کر برقرار رکھنا)۔ ملکیتی سافٹ ویئر کے ساتھ پہلے سے تحفظات طے کریں: کھلے فارمیٹس میں ڈیٹا کی برآمد، دستاویزی APIs، اور source-code escrow (قانونی انتظام جہاں فروخت کنندہ سورس تیسری پارٹی کے پاس جمع کراتا ہے، جو فروخت کنندہ کے ناکام ہونے پر آپ کو ملتا ہے)۔ ایسا ڈیزائن کریں کہ کوئی بھی جزو، کسی بھی قسم کا، آپ کے نظام کو یرغمال نہ بنا سکے۔

فروخت کی قیمت نہیں، ملکیت کی کل لاگت تولیں

اختیارات کا موازنہ ملکیت کی کل لاگت (TCO) پر کریں، یعنی حصول، انضمام، آپریشن، سپورٹ، تربیت، اپ گریڈ، اور آخری تبدیلی سمیت پوری زندگی کی لاگت، صرف لائسنس کی فیس پر نہیں۔ اوپن سورس اکثر لائسنس کی لاگت کے بدلے زیادہ آپریشنل اور عملے کی لاگت لیتا ہے۔ ملکیتی سافٹ ویئر اکثر پیش گوئی کے قابل سبسکرپشن فیس کے بدلے lock-in اور کم کنٹرول لیتا ہے۔ ماڈل کی اپنی لاگت شامل کریں: خود سپورٹ اوپن سورس کو اندرونی مہارت چاہیے، جبکہ ملکیتی سافٹ ویئر کو فروخت کنندہ کے انتظام کی صلاحیت۔

بطور پیدا کنندہ، جو آپ کو ممتاز نہیں کرتا اسے اوپن سورس کریں

اپنے سافٹ ویئر کو اس میں درجہ بند کریں جو مسابقتی یا مشن کا فائدہ دیتا ہے اور جو غیر امتیازی plumbing ہے۔ امتیازی چیزیں ملکیتی رکھیں۔ عام انفراسٹرکچر کو اوپن سورس کرنے پر غور کریں، جہاں کمیونٹی دیکھ بھال اور بہتری بانٹ سکتی ہے۔ حکومت کے لیے “عوامی پیسہ، عوامی کوڈ” (یہ اصول کہ ٹیکس دہندگان کے فنڈ سے بنا سافٹ ویئر ڈیفالٹ طور پر عوامی طور پر دستیاب ہو) کو شفافیت، دوبارہ استعمال، اور خودمختاری کے محرک کے طور پر تولیں (ابواب 10.5، 10.11)۔ لائسنس دانستہ چنیں: اپنانا زیادہ سے زیادہ کرنے کو permissive، ماحولیاتی نظام کھلا رکھنے کو copyleft۔

سمجھوتے: فوائد اور نقصانات

پہلو	اوپن سورس	کلوزڈ / ملکیتی
حصول کی لاگت	عموماً حاصل کرنے میں صفر	لائسنس یا سبسکرپشن کی فیس
ملکیت کی کل لاگت	لاگت آپریشنز اور عملے کی طرف منتقل	زیادہ پیش گوئی کے قابل، مگر lock-in کا پریمیم
کنٹرول اور حسب ضرورت	مکمل: آپ سورس پڑھ اور بدل سکتے ہیں	جو فروخت کنندہ ظاہر کرے اس تک محدود
سپورٹ اور جوابدہی	کمیونٹی، یا ادا شدہ تیسری پارٹی؛ کوئی ایک ذمہ دار نہیں	معاہداتی سپورٹ اور واضح جوابدہ فریق
سیکیورٹی کی کیفیت	قابل آڈٹ؛ واقعی برقرار ہو تو “many eyes”	فروخت کنندہ کا منظم؛ مبہم؛ obscurity تحفظ نہیں
درازی عمر / ترک	برقرار ہو تو fork ہو سکتا ہے؛ پھر بھی مرجھا سکتا ہے	فروخت کنندہ کی بقا اور روڈ میپ پر منحصر
فروخت کنندہ کا lock-in	کم: سورس اور کھلے فارمیٹس اخراج ممکن بناتے ہیں	زیادہ، جب تک معیارات اور escrow سے کم نہ ہو
ماحولیاتی نظام	کھلی کمیونٹی اور باہمی عمل پذیری	منتخب، مربوط، کبھی دیواروں والا

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

اپنی ٹیم کے ساتھ بحث کے سوالات

کیا ہم pipeline میں خودکار SCA اور SBOMs کے ساتھ لائسنس کی پالیسی نافذ کرتے ہیں، خاص طور پر مضبوط copyleft کو بھیجنے سے پہلے پکڑنے کے لیے؟ تقسیم شدہ ملکیتی پروڈکٹ میں GPL لائبریری شامل کرنا آپ کو اپنا سورس جاری کرنے کا پابند کر سکتا ہے، اور یہ حیرت عموماً دیر سے ابھرتی ہے، جب اسے ختم کرنا مہنگا ہے۔ ہر جزو اور اس کے لائسنس کی فہرست رکھیں، نافذ کریں کہ کن استعمالات کے لیے کون سے لائسنس خاندان قابل قبول ہیں، اور software composition analysis خودکار چلائیں تاکہ pipeline خلاف ورزیاں روکے نہ کہ وکیل ship کے وقت پکڑے۔ SBOM معمول کے طور پر بنائیں۔ بڑی یا سرکاری ملکیت کے لیے یہ سپلائی چین کی صفائی بھی ہے اور اکثر خریداری کا تقاضا۔ اپنی موجودہ لائسنس فہرست لائیں، یا یہ حقیقت کہ آپ کے پاس نہیں، اور طے کریں کہ پالیسی کا مالک کون ہے۔
جب ہم کوئی انحصار اپناتے ہیں تو کیا ہم due diligence کے طور پر پراجیکٹ کی صحت اور bus-factor کا اندازہ لگاتے ہیں؟ واحد maintainer والی اوپن سورس لائبریری اور چھوٹا ملکیتی فروخت کنندہ ایک ہی خطرہ رکھتے ہیں: ایک یا چند کلیدی لوگوں کے جانے پر پراجیکٹ ڈھ جاتا ہے۔ کچھ بھی اپنانے سے پہلے ریلیز کی تال، maintainers کی تعداد اور تنوع، سیکیورٹی رپورٹس پر ردعمل، اور اپنانے کی وسعت جانچیں، اور جائزہ ریکارڈ کریں۔ کوئی ماڈل ڈیفالٹ طور پر زیادہ محفوظ نہیں؛ “many eyes” تبھی مدد کرتی ہیں جب اہل لوگ واقعی دیکھیں، اور بہت سے وسیع استعمال شدہ پراجیکٹس کم سنبھالے جاتے ہیں۔ اپنی پروڈکٹ جن تین چار انحصار پر سب سے زیادہ تکیہ کرتی ہے وہ لائیں اور ہر ایک کے لیے پوچھیں کہ اس کے آپ کا مسئلہ بننے سے پہلے کتنے لوگوں کو چھوڑنا ہوگا۔ اگر آپ جواب نہیں دے سکتے تو وہی جائزہ ہے جو آپ پر اپنے آپ کا واجب ہے۔
جب ہم ملکیتی خریدتے ہیں تو کیا ہم اخراج کے تحفظات پہلے سے محفوظ کرتے ہیں؟ ملکیتی سافٹ ویئر کنٹرول کے بدلے جوابدہی اور سہولت دیتا ہے، اور چھپی لاگت lock-in ہے: منتقلی کی لاگتیں جو فروخت کنندہ کو بہت کم چارہ جوئی کے ساتھ قیمتیں بڑھانے یا سروس گرانے دیتی ہیں۔ دستخط سے پہلے، جب آپ کے پاس اب بھی اثر ہے، تحفظات طے کریں: کھلے فارمیٹس میں ڈیٹا کی برآمد، دستاویزی APIs، اور source-code escrow جو فروخت کنندہ کے ناکام ہونے پر سورس جاری کرے۔ اوپن سورس کے ساتھ آپ کا اخراج fork کرنے کی صلاحیت ہے؛ ملکیتی کے ساتھ آپ کو اخراج معاہدے میں لکھنا ہوگا۔ اپنے سب سے نازک ملکیتی نظام لائیں اور پوچھیں کہ اگر فروخت کنندہ قیمت دگنی کر دے یا ڈوب جائے تو اصل میں کیا ہوتا ہے۔ اگر جواب “ہم پھنس گئے” ہے تو تجدید پر معاہدہ ٹھیک کریں۔
جو سافٹ ویئر ہم خود بناتے ہیں اس کے لیے ہم کیسے طے کرتے ہیں کہ کیا اوپن سورس کریں اور کیا بند رکھیں، اور یہ فیصلہ کرنے کا اختیار کس کے پاس ہے؟ ایک سمت میں غلط ہوں تو آپ وہ کوڈ دے دیتے ہیں جو آپ کو ممتاز کرتا ہے؛ دوسری میں غلط ہوں تو آپ عام plumbing ذخیرہ کرتے ہیں جس کی دیکھ بھال کمیونٹی خوشی سے بانٹتی۔ متصادم دباؤ حقیقی ہیں: انجینئر عوامی ریپوزٹری کی بھرتی اور ساکھ کا فائدہ چاہتے ہیں، جبکہ پروڈکٹ اور قانونی حریفوں کو برتری دینے یا سیکیورٹی کے لحاظ سے حساس heuristic ظاہر کرنے سے فکرمند ہیں۔ اپنے نظاموں کی ایماندار درجہ بندی مشن کو ممتاز کرنے والے اور غیر امتیازی انفراسٹرکچر میں لائیں، اور اس شخص یا بورڈ کا نام لیں جو ریلیز پر دستخط کرے، کیونکہ جس نے ریپوزٹری push کی اس کا فوری فیصلہ ہی کرون جیولز کے لیک ہونے کا طریقہ ہے۔ بڑے انٹرپرائز کے لیے سوال پورٹ فولیو کی حکمت عملی ہے، اور حکومت کے لیے یہ “عوامی پیسہ، عوامی کوڈ” سے ٹکراتا ہے، یعنی اصول کہ ٹیکس دہندگان کا فنڈ کیا سافٹ ویئر ڈیفالٹ طور پر عوامی ہو، اس لیے پہلے سے طے کریں کہ کون سے استثنا (قومی سلامتی، فراڈ کی شناخت، ذاتی ڈیٹا) کوڈ بند رکھنے کا جواز دیتے ہیں۔
کیا ہمارے بنانے-یا-خریدنے کے موازنے ملکیت کی پوری کل لاگت پکڑتے ہیں، یا ہم اب بھی صفر لائسنس فیس کو صفر لاگت سمجھتے ہیں؟ اوپن سورس کے ساتھ سب سے عام مالی غلطی “حاصل کرنے میں مفت” کو “چلانے میں مفت” پڑھنا ہے، پھر یہ دریافت کرنا کہ انضمام، آپریشنز، سیکیورٹی ردعمل، اور ادا شدہ سپورٹ ہر اس لائسنس سے بڑھ جاتے ہیں جو آپ نے بچایا۔ کھنچاؤ یہ ہے کہ ملکیتی سبسکرپشن invoice پر مہنگی لگتی ہے مگر lock-in کا پریمیم چھپاتی ہے، اور کھلا جزو invoice پر مفت لگتا ہے مگر لاگت آپ کے اپنے عملے پر ڈالتا ہے۔ دو یا تین حقیقی فیصلوں کے لیے ایک جیسا TCO ماڈل لائیں: حصول، انضمام، آپریشن، سپورٹ، تربیت، اپ گریڈ، سیکیورٹی ردعمل، اور آخری تبدیلی، پہلے سال کی بجائے پوری زندگی پر قیمت لگی ہوئی۔ انٹرپرائز یا سرکاری ملکیت میں آپریٹنگ ماڈل کی اپنی لاگت شامل کریں، کیونکہ خود سپورٹ اوپن سورس ایسی اندرونی مہارت مانگتا ہے جو آپ کو بھرتی اور برقرار رکھنی ہوگی، اور وہ موازنہ جو ان لائنوں کو چھوڑے اسے تجزیہ نہیں، شہادت سمجھیں۔
کیا ہم جزو کی سیکیورٹی کا فیصلہ اس کے عمل سے کرتے ہیں، یا کھلے پن کے لیبل پر تکیہ کرتے ہیں، چاہے “many eyes” ہو یا بند کوڈ کی رازداری؟ دونوں ڈیفالٹ جال ہیں: “many eyes” تبھی بچاتی ہیں جب اہل لوگ واقعی کوڈ جانچیں، اور بہت سے وسیع استعمال شدہ کھلے پراجیکٹس ایک تھکے ہوئے maintainer پر چلتے ہیں، جبکہ بند سورس جو حملہ آوروں کے نہ دیکھنے پر انحصار کرے security through obscurity ہے، کنٹرول نہیں۔ بحث اس لیے اہم ہے کہ یہ بدلتی ہے کہ آپ نایاب سیکیورٹی کی کوشش کہاں خرچ کرتے ہیں، اور ایماندار جواب یہ ہے کہ دونوں ماڈل سپلائی چین کا خطرہ رکھتے ہیں، اوپن سورس سمجھوتہ شدہ یا متروک انحصار کے ذریعے اور ملکیتی ایسے مبہم اپ ڈیٹ چینلز کے ذریعے جنہیں آپ جانچ نہیں سکتے۔ اپنے سب سے نازک اجزا کی شہادت لائیں: انہیں اصل میں کون جانچتا ہے، advisories کتنی تیزی سے patch ہوتی ہیں، کیا ورژن pin اور ماخذ کی توثیق ہے، اور کیا آپ SBOM بناتے ہیں۔ بڑی یا سرکاری ملکیت کے لیے اسے خریداری اور مسلسل اسکیننگ کی ذمہ داریوں سے جوڑیں، کیونکہ ضابطہ ساز پوچھے گا کہ آپ نے کیا جانچا، یہ نہیں کہ سورس عوامی تھا یا نہیں۔

شعبہ جاتی نقطۂ نظر

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

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

بڑا ادارہ۔ پیمانے پر مسئلہ بہت سی ٹیموں میں مستقل مزاجی ہے: تحریری لائسنس کی پالیسی، ہر pipeline میں خودکار software composition analysis اور SBOM کی تیاری، اور ٹیم کی عادت کی بجائے TCO پر مبنی بنانے-یا-خریدنے کے فیصلے۔ اوپن اور ملکیتی سافٹ ویئر کو ایک پورٹ فولیو کے طور پر منظم کریں، خریداری میں کھلے فارمیٹس اور source-code escrow جیسے اخراج کے تحفظات معیاری کریں، اور نازک انحصار کی صحت پر نظر رکھیں تاکہ ایک متروک پراجیکٹ واقعہ نہ بنے۔ پیدا کنندہ کی طرف بھی نظم رکھیں، واضح اصول کے ساتھ کہ ادارہ کیا اوپن سورس کرتا ہے اور کیا بند رکھتا ہے۔

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

مثالیں

اسٹارٹ اپ۔ تین بانیوں کا اسٹارٹ اپ اپنی پوری پروڈکٹ اوپن سورس بنیادوں (Linux، اوپن سورس ڈیٹا بیس، ویب فریم ورک) پر بناتا ہے کیونکہ وہ لائسنس کی فیس کی استطاعت نہیں رکھتا اور اگر پراجیکٹ رک جائے تو fork کی آزادی چاہتا ہے۔ بھیجنے سے پہلے ایک بانی composition-analysis اسکین چلاتا ہے اور مضبوط-copyleft لائبریری پکڑ لیتا ہے جو انہیں اپنا ملکیتی matching الگورتھم شائع کرنے پر مجبور کرتی، اس لیے وہ اسے permissive لائسنس والے مساوی سے بدل دیتے ہیں۔ وہ اس الگورتھم کو، اپنے واحد امتیاز کو، سختی سے بند رکھتے ہیں، اور خیر سگالی بنانے اور انجینئر متوجہ کرنے کو صرف چھوٹا اندرونی logging آلہ اوپن سورس کرتے ہیں۔

بڑا ادارہ۔ بڑا بیمہ کار اپنا بنیادی پلیٹ فارم اوپن سورس بنیادوں پر چلاتا ہے: Linux، وسیع استعمال شدہ اوپن سورس ڈیٹا بیس، اور container orchestrator۔ لیکن وہ ملکیتی actuarial-ماڈلنگ سوٹ خریدتا ہے، کیونکہ فروخت کنندہ کی شعبہ جاتی مہارت، ضابطے کی توثیقیں، اور سپورٹ معاہدہ فیس کے قابل ہیں اور کوئی موازنہ کے قابل اوپن متبادل نہیں۔ وہ بنیادی plumbing پر جوابدہی اور patches لینے کو تجارتی اوپن سورس (کھلے اجزا کی فروخت کنندہ سے سپورٹ شدہ ڈسٹری بیوشنز) کی سبسکرپشن ادا کرتا ہے، جبکہ جو قیمت سازی کا الگورتھم اسے ممتاز کرتا ہے اسے سختی سے ملکیتی اور اندرونی رکھتا ہے۔ ہر انتخاب نظریہ نہیں، TCO کا تجزیہ (باب 10.10) چلاتا ہے۔

حکومت۔ قومی ٹیکس ایجنسی، “عوامی پیسہ، عوامی کوڈ” کی پالیسی کے تحت، نئی benefits-eligibility سروس اوپن سورس اجزا اور کھلے معیارات (باب 3.8) پر بناتی ہے، تاکہ دوسری ایجنسیاں اسے دوبارہ استعمال کر سکیں اور شہری قواعد کا آڈٹ کر سکیں۔ وہ غیر حساس کوڈ عوامی ریپوزٹری میں شائع کرتی ہے، سیکیورٹی کی وجوہات سے صرف فراڈ کی شناخت کے heuristics بند رکھتی ہے۔ یہ فروخت کنندہ کا lock-in گھٹاتا اور ڈیجیٹل خودمختاری (باب 10.11) آگے بڑھاتا ہے۔ خریداری کے قواعد (باب 10.3) کسی بھی ملکیتی جزو سے کھلے فارمیٹس میں ڈیٹا کی برآمد اور source-code escrow لازم کرتے ہیں، تاکہ سپلائر کے ناکام ہونے پر تسلسل کی ضمانت ہو۔

کاروباری جواز: محرکات، ROI اور TCO

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

ملکیتی سافٹ ویئر کا کاروباری جواز جوابدہی اور سہولت ہے: پروڈکٹ کا ذمہ دار ایک فروخت کنندہ، نافذ کرنے کے قابل سپورٹ معاہدہ، مربوط فیچرز، اور پیش گوئی کے قابل بجٹ۔ اس کی چھپی لاگت lock-in ہے، یعنی منتقلی کی لاگتیں جو فروخت کنندہ کو بہت کم چارہ جوئی کے ساتھ قیمتیں بڑھانے یا سروس گرانے دیتی ہیں، نیز فروخت کنندہ کی بقا اور روڈ میپ پر انحصار۔ عام کاروباری ماڈل لکیر دھندلی کرتے ہیں: open core (کھلی بنیاد ملکیتی ادا شدہ اضافوں کے ساتھ)، dual licensing (وہی کوڈ copyleft اور ادا شدہ تجارتی لائسنس دونوں کے تحت)، software as a service (SaaS) (سافٹ ویئر ہوسٹڈ سروس کے طور پر چلتا ہے جو آپ کرائے پر لیتے ہیں، جہاں سورس غیر متعلق ہو سکتا ہے کیونکہ آپ binary کبھی نہیں رکھتے)، اور سپورٹ/سبسکرپشن ماڈل جو بصورت دیگر مفت کوڈ کے گرد سروس بیچتے ہیں۔

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

ضد نمونے اور خامیاں

“مفت کا مطلب مفت”: صفر حصول کی لاگت کو صفر TCO سمجھنا، پھر آپریشن اور سپورٹ کو کم فنڈ کرنا۔
لائسنس سے اندھاپن: تقسیم شدہ ملکیتی پروڈکٹ میں مضبوط-copyleft کوڈ شامل کرنا اور ایسی ذمہ داریاں چھیڑنا جن کا آپ نے کبھی منصوبہ نہ بنایا تھا۔
“many eyes” پر ایمان: یہ فرض کرنا کہ کھلے پراجیکٹ کا آڈٹ ہوا ہے جبکہ اس کا ایک بوجھ تلے maintainer ہے اور کوئی سیکیورٹی ریویو نہیں۔
Security-through-obscurity: یہ ماننا کہ بند سورس محض اس لیے محفوظ ہے کہ حملہ آور اسے پڑھ نہیں سکتے۔
نظریاتی مطلق پسندی: میرٹ اور TCO پر فی جزو چننے کی بجائے “سب کھلا” یا “سب ملکیتی” لازم کرنا۔
ماخذ کو نظر انداز کرنا: SBOM، ورژن pinning، یا سپلائی چین کی توثیق کے بغیر انحصار کھینچنا (باب 4.2)۔
کرون جیولز کو اوپن سورس کرنا: وہی کوڈ جاری کرنا جو آپ کو ممتاز کرتا ہے، اپنی برتری دے دینا۔
Fork کر کے بھول جانا: متروک پراجیکٹ کو fork کرنا بغیر اس صلاحیت کے کہ fork کو واقعی برقرار رکھا جا سکے۔

پختگی کا ماڈل

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

سطح 2 (ترقی)۔ کچھ ٹیمیں بنیادی عمل شروع کرتی ہیں: اجزا اور لائسنس کی فہرست، قابل قبول لائسنسوں کا موٹا نظارہ، اور کبھی کبھار software composition analysis۔ بنانے-یا-خریدنے اور کھلے-یا-بند کے فیصلے لکھے جاتے ہیں، مگر نظم و ضبط ادھورا اور ٹیم سے ٹیم غیر مستقل ہے، اس لیے copyleft یا bus-factor کی حیرت اب بھی وہاں سے پھسل سکتی ہے جہاں عادت جمی نہیں۔

سطح 3 (معیار بندی)۔ دستاویزی فریم ورک ادارے بھر استعمال اور پیداوار دونوں پر حکومت کرتا ہے۔ اجزا TCO اور پراجیکٹ کی صحت پر چنے جاتے ہیں، لائسنس pipeline میں خودکار نافذ ہوتے ہیں تاکہ خلاف ورزیاں build روکیں، SBOMs معمول سے بنتے ہیں، اور واضح پالیسی بتاتی ہے کہ ادارہ کیا اوپن سورس کرتا اور کیا بند رکھتا ہے۔ کھلے فارمیٹس اور source-code escrow جیسے اخراج کے تحفظات خریداری میں معیاری ہیں، اور ہر ٹیم اپنی نہیں بلکہ ایک جیسے قواعد پر چلتی ہے۔

سطح 4 (انتظام)۔ پروگرام بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ ادارہ پروڈکٹس میں SBOM کی coverage، پالیسی کی خلاف ورزی کرنے والے انحصار کا حصہ، ظاہر شدہ انحصار کی کمزوری patch کرنے کا اوسط وقت، نازک پراجیکٹس کے bus-factor اور صحت کے سکور، اور ہر انتخاب کا جواز دینے والے تخمینے کے مقابل حاصل شدہ TCO جیسے میٹرکس ٹریک کرتا ہے۔ حدیں عمل ٹرگر کرتی ہیں: جس جزو کی دیکھ بھال رک جائے یا patch کی تاخیر ہدف سے بھٹکے اسے شہادت پر تبدیلی کے لیے نشان زد کیا جاتا ہے، اور کھلے-یا-بند اور بنانے-یا-خریدنے کے فیصلوں پر اعداد کے مقابل نظر ثانی ہوتی ہے نہ کہ عادت سے دفاع۔

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

بحث کے لیے خیالات

آپ کی ملکیت میں کہاں ایک فروخت کنندہ یا maintainer کا کھونا وجودی ہوگا، اور آپ کا اخراج کا منصوبہ کیا ہے؟
آپ کے اپنے نظاموں میں کون سے عام ہیں جنہیں آپ اوپن سورس کر سکتے ہیں، اور کون سے حقیقی امتیاز ہیں جن کی حفاظت کرنی ہے؟
کیا آپ کا ادارہ “many eyes” کو حقیقی سیکیورٹی کنٹرول سمجھتا ہے یا غیر جانچا مفروضہ؟
عوامی شعبے کے قارئین کے لیے: “عوامی پیسہ، عوامی کوڈ” کا ڈیفالٹ آپ کی اگلی خریداری میں کیا بدلے گا؟
آپ کے TCO کے موازنے وہ آپریشنل اور سپورٹ کی لاگتیں کتنی اچھی طرح پکڑتے ہیں جو اوپن سورس آپ پر منتقل کرتا ہے؟

اہم نکات

کھلا بمقابلہ بند لائسنس سے طے ہوتا ہے، قیمت سے نہیں؛ free-as-in-freedom اور free-as-in-price، اور permissive اور copyleft کا فرق جانیں۔
کوئی ماڈل فطری طور پر زیادہ محفوظ یا سستا نہیں۔ کھلے پن کے لیبل کی نہیں، پراجیکٹ کے طریقوں اور اس کے پورے TCO کی جانچ کریں۔
کھلا پن lock-in کا سب سے مضبوط علاج ہے، قابل آڈٹ ہونا، پورٹیبلٹی، اور fork کی صلاحیت دیتا ہے؛ ملکیتی سافٹ ویئر کنٹرول کے بدلے جوابدہی اور سہولت دیتا ہے۔
فی جزو میرٹ پر فیصلہ کریں، اور ماڈلوں کو نظریے سے نہیں، دانستہ ملائیں۔
بطور پیدا کنندہ، عام چیز اوپن سورس کریں اور امتیازی چیز بند رکھیں، اور حکومت میں شفافیت، دوبارہ استعمال، اور خودمختاری کے لیے “عوامی پیسہ، عوامی کوڈ” کو تولیں۔

حوالہ جات اور مزید مطالعہ

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft and others, various O’Reilly titles on open-source strategy and operations
Free Software Foundation, The Free Software Definition (and the GNU General Public Licence texts)
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
Yochai Benkler, The Wealth of Networks