اوپن سورس سافٹ ویئر کی تاریخ اور لائسنسز

اوپن سورس سافٹ ویئر کیا ہے اور اس کی ابتدا کہاں سے ہوئی

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

یہ مختصر خلاصہ ہے۔ تفصیلی تاریخ اس لیے اہم ہے کہ آج آپ سرور پر جو سافٹ ویئر چلاتے ہیں، اس پر اب بھی ان فیصلوں کے اثرات موجود ہیں۔ ان میں سے کچھ فیصلے 1983 میں کیے گئے تھے۔ کچھ پچھلے سال کیے گئے، اور یہی وجہ ہے کہ ہماری self-hosting guides میں شامل چند ایپلی کیشنز اب مختلف ناموں کے ساتھ 2 versions میں دستیاب ہیں۔

سافٹ ویئر فروخت ہونے سے پہلے شیئر کیا جاتا تھا

1950 اور 1960 کی دہائیوں میں سافٹ ویئر مشین کے ساتھ فراہم کیا جاتا تھا۔ IBM اپنے systems کے ساتھ source code بھی فراہم کرتا تھا، اور 1955 میں قائم ہونے والے SHARE جیسے user groups، tape کے ذریعے programs ایک دوسرے کو دیتے تھے۔ دو عوامل نے یہ صورت حال بدل دی۔ 1969 میں IBM نے اعلان کیا کہ وہ software کی قیمت hardware سے الگ مقرر کرے گا۔ اس سے software کے لیے ایک آزاد market وجود میں آیا۔ پھر قانون بھی اس تبدیلی کے مطابق ہو گیا۔ Computer Software Copyright Act of 1980 نے تصدیق کی کہ United States میں programs copyright کے تحفظ کے اہل works ہیں۔ 1980 کے بعد وہ code جو آپ نے خود نہیں لکھا تھا، default طور پر closed سمجھا جاتا تھا۔ اسے شیئر کرنے کے لیے author کی تحریری اجازت درکار ہوتی تھی۔

ہوم بریو کمپیوٹر کلب اور شوقیہ صارفین کے نام کھلا خط

ہوم بریو کمپیوٹر کلب کا پہلا اجلاس مارچ 1975 میں کیلیفورنیا کے Menlo Park میں ایک گیراج میں ہوا۔ اراکین hardware اور paper tape ساتھ لائے، اور نقل بنانا اجلاس کا حصہ تھا۔ Bill Gates اور Paul Allen کا لکھا ہوا Altair BASIC نقل شدہ tape پر پورے کمرے میں گردش کرتا رہا۔ فروری 1976 میں Gates نے کلب کے newsletter میں "شوقیہ صارفین کے نام ایک کھلا خط" کے ذریعے جواب دیا۔

جیسا کہ زیادہ تر شوقیہ صارفین کو معلوم ہونا چاہیے، آپ میں سے اکثر اپنی software چوری کرتے ہیں۔

انہوں نے لکھا کہ دس میں سے ایک سے بھی کم Altair مالکان نے BASIC کی قیمت ادا کی تھی، اور اسے لکھنے کے لیے استعمال ہونے والے computer time کی مالیت 40,000 dollars سے زیادہ تھی۔ جدید دور کی پوری بحث پہلے ہی اس خط میں موجود ہے۔ Software کی نقل بنانے پر کچھ خرچ نہیں آتا اور ہر نقل بنانے والے کو فائدہ ہوتا ہے۔ لیکن اسے لکھنے میں پھر بھی کسی شخص کی زندگی کا ایک سال لگا۔ ذیل میں بیان کردہ ہر licence ایک ہی وقت میں ان دونوں حقائق کا جواب دینے کی کوشش ہے۔

1983 میں GNU، اور GPL بطور قانونی ایجاد

Richard Stallman نے ستمبر 1983 میں Usenet پر GNU کا اعلان کیا۔ Usenet وہ newsgroup network تھا جسے لوگ web سے پہلے استعمال کرتے تھے۔ GNU کا مطلب "GNU's Not Unix" ہے۔ منصوبہ ایک ایسے مکمل Unix-compatible system کا تھا جسے ہر شخص copy اور modify کر سکے۔

Free Unix! اس Thanksgiving سے میں GNU (Gnu's Not Unix) نامی ایک مکمل Unix-compatible software system لکھنا شروع کروں گا اور اسے ہر اس شخص کو مفت دوں گا جو اسے استعمال کر سکتا ہو۔

Free Software Foundation (FSF) نے 1985 میں کام شروع کیا۔ اس کی Free Software Definition میں چار آزادیاں درج ہیں، جن کی numbering zero سے شروع ہوتی ہے: program کو کسی بھی مقصد کے لیے run کرنا، اس کا مطالعہ اور modification کرنا، copies دوبارہ distribute کرنا، اور اپنی modified versions distribute کرنا۔ Freedom 1 کے لیے source code ضروری ہے، کیونکہ کوئی بھی شخص binary کا عملی طور پر مطالعہ نہیں کر سکتا۔ یہاں "Free" سے مراد آزادی ہے، قیمت نہیں۔ FSF کا اپنا جملہ ہے: free as in free speech، نہ کہ free beer۔

اصل ایجاد manifesto نہیں تھا۔ اصل ایجاد licence تھی۔ GNU General Public License (GPL) copyright کو sharing روکنے کے بجائے اسے لازم کرنے کے لیے استعمال کرتی ہے۔ آپ کو یہ چاروں آزادیاں ایک شرط پر ملتی ہیں: جس شخص کو آپ software دیتے ہیں، اسے بھی source code سمیت یہی آزادیاں ملیں۔ Stallman نے اسے copyleft کہا۔ یہ پہلی بار 1985 میں GNU Emacs کے ساتھ release ہوئی، 1989 میں GPL version 1 بنی، اور June 1991 میں version 2 جاری ہوئی۔

GPL اس لیے کام کرتی ہے کہ اس کی بنیاد copyright law پر ہے، اس کے خلاف نہیں۔ Licence کے بغیر آپ کو کسی دوسرے کے code کو distribute کرنے کا کوئی حق نہیں ہوتا۔ GPL یہ حق دیتی ہے اور اس کے ساتھ شرائط بھی عائد کرتی ہے۔ لہٰذا جو vendor modified GPL code کو router کے اندر ship کرے اور source code دینے سے انکار کرے، وہ صرف کوئی وعدہ نہیں توڑ رہا ہوتا۔ وہ copyright کی خلاف ورزی کر رہا ہوتا ہے، اور copyright holder اسے عدالت لے جا سکتا ہے۔ اسی وجہ سے enforcement ممکن ہے، خواہ یہ 2000s میں Harald Welte کے gpl-violations.org مقدمات ہوں یا Software Freedom Conservancy کا Vizio کے خلاف مقدمہ، جو 2021 میں دائر کیا گیا اور جس میں مؤقف اختیار کیا گیا کہ television خریدنے والا شخص بھی source code کا مطالبہ کر سکتا ہے۔

Linux نے نظام مکمل کر دیا

1991 تک GNU project کے پاس compiler، C library، shell اور زیادہ تر tools موجود تھے۔ اس کے پاس قابلِ استعمال kernel نہیں تھا، کیونکہ GNU کا اپنا kernel، Hurd، منصوبے کے مطابق مکمل ہونے سے کہیں زیادہ وقت لے رہا تھا۔ اگست 1991 میں Helsinki کے ایک طالب علم نے comp.os.minix newsgroup میں لکھا:

میں ایک (مفت) operating system بنا رہا ہوں (صرف شوق کے طور پر، یہ GNU کی طرح بڑا اور پیشہ ورانہ نہیں ہوگا) جو 386(486) AT clones کے لیے ہے۔

Linux 0.01 ستمبر 1991 میں ایسے licence کے تحت جاری ہوا جو Linus Torvalds نے خود لکھا تھا اور جس کے تحت اسے فروخت کرنا ممنوع تھا۔ 1992 کے آغاز میں انہوں نے اس licence کی جگہ GPLv2 نافذ کر دیا۔ بعد میں انہوں نے کہا کہ یہ ان کے بہترین فیصلوں میں سے ایک تھا۔ اسی licence نے corporate contribution کو محفوظ بنایا۔ کوئی کمپنی اپنے engineers کو kernel پر کام کرنے کے لیے تعینات کر سکتی تھی، کیونکہ اسے معلوم تھا کہ کوئی competitor ان improvements کو proprietary نہیں بنا سکتا۔

Berkeley میں ایک free Unix پہلے سے موجود تھا۔ Linux کے بجائے BSD (Berkeley Software Distribution) کے default free Unix نہ بننے کی ایک وجہ lawsuit بھی ہے۔ Unix System Laboratories نے 1992 میں Berkeley Software Design پر مقدمہ دائر کیا، اور یہ مقدمہ 1994 کے آغاز تک جاری رہا۔ ان دو برسوں کے دوران BSD systems کو legal risk درپیش تھا، جبکہ Linux پر ایسا کوئی خطرہ نہیں تھا۔ اسی عرصے میں users نے Linux اختیار کرنا شروع کیا۔ FSF لوگوں سے کہتی ہے کہ combined system کو GNU/Linux کہا جائے، کیونکہ Linux kernel ہے اور اس کے گرد موجود زیادہ تر tools GNU کے ہیں۔ زیادہ تر لوگ Linux کہتے ہیں۔ دونوں نام software کے اسی مجموعے کی طرف اشارہ کرتے ہیں۔

1998: اوپن سورس کی نئی اصطلاح، اور وہ تقسیم جو کبھی ختم نہ ہوئی

جنوری 1998 میں Netscape نے اعلان کیا کہ وہ اپنے browser کا source code جاری کرے گا۔ یہ اب تک کی سب سے بڑی کمپنی تھی جس نے ایسا قدم اٹھایا تھا، اور اس سے ایک عملی مسئلہ سامنے آیا۔ انگریزی میں "free software" کا مطلب "ایسا software جس کی کوئی قیمت نہ ہو" بھی سمجھا جاتا ہے، اور executives نے اسے بالکل اسی معنی میں لیا۔ فروری 1998 میں Palo Alto میں ایک گروپ بہتر اصطلاح تلاش کرنے کے لیے جمع ہوا، اور Christine Peterson نے "open source" کی تجویز دی۔ چند ہی ہفتوں میں Eric Raymond اور Bruce Perens نے Open Source Initiative (OSI) قائم کر دی۔ اس نے Open Source Definition منظور کی، جو ان Debian Free Software Guidelines سے اخذ کی گئی تھی جنہیں Perens نے 1997 میں تحریر کیا تھا۔

Open Source Definition میں دس معیارات ہیں۔ ان میں سے دو جدید مباحث میں زیادہ تر فیصلے کرتے ہیں: source دستیاب ہونا چاہیے، اور licence کو یہ پابندی نہیں لگانی چاہیے کہ پروگرام کون استعمال کر سکتا ہے یا اسے کس مقصد کے لیے استعمال کیا جا سکتا ہے۔ اگر کوئی licence کہتا ہے کہ "آپ اسے commercial service کے طور پر پیش نہیں کر سکتے"، تو وہ اس معیار پر پورا نہیں اترتا، چاہے وہ دوسری کئی اجازتیں دیتا ہو۔ اس جملے کو ذہن میں رکھیں۔ آج کی source-available licences اسی حد کو عبور کرتی ہیں۔

1998 میں شروع ہونے والی تقسیم licences کی قبولیت کے بارے میں نہیں، بلکہ وجوہات کے بارے میں ہے۔ FSF کا مؤقف اخلاقی ہے: جو user پروگرام تبدیل نہیں کر سکتا، وہ اپنے computer پر خود اختیار نہیں رکھتا۔ Raymond کے مضمون "The Cathedral and the Bazaar" میں business کے لیے پیش کیا گیا OSI کا مؤقف عملی ہے: open development بہتر software تیار کرتی ہے، اور company اس حقیقت سے فائدہ اٹھا سکتی ہے۔ Stallman کا جواب، "Why Open Source Misses the Point of Free Software"، آج بھی gnu.org پر شائع ہے، اور انہوں نے نئی اصطلاح کبھی قبول نہیں کی۔ Perens، جنہوں نے اسے تشکیل دینے میں مدد دی تھی، نے 1999 میں OSI کے board سے استعفیٰ دے دیا اور کہا کہ یہ movement free software سے دور ہو گئی ہے۔

یہ واضح طور پر بیان کرنا مفید ہے کہ عملی فرق کتنا کم ہے۔ FSF کی free licences کی فہرست اور OSI کی approved licences کی فہرست تقریباً ہر معاملے میں متفق ہیں، جن میں GPL، MIT، Apache 2.0 اور BSD بھی شامل ہیں۔ جو مصنفین دونوں مفاہیم کو بیک وقت بیان کرنا چاہتے ہیں، وہ FOSS (free and open source software) یا FLOSS (free/libre and open source software) استعمال کرتے ہیں۔

کمپنیوں نے کوڈ جاری کرنا کیسے سیکھا

1999 میں Red Hat کی stock market listing سے ظاہر ہوا کہ آمدنی copies فروخت کرنے کے بجائے support اور packaging میں ہے۔ IBM نے 2001 کے لیے Linux میں ایک billion dollars کی سرمایہ کاری کا عہد کیا۔ 2001 میں Microsoft کے chief executive نے Linux کو "a cancer" کہا، لیکن اسی کمپنی نے 2016 میں Linux Foundation میں platinum member کے طور پر شمولیت اختیار کی، پھر 2018 میں GitHub کو stock کی صورت میں 7.5 billion dollars میں خرید لیا۔ IBM نے 2019 میں Red Hat کو 34 billion dollars میں خرید لیا۔ ان میں سے کسی واقعے کا سبب licences کے بارے میں رائے کی تبدیلی نہیں تھا۔ تبدیلی صرف اس مقام میں آئی جہاں آمدنی موجود تھی۔ جب operating system ایک مشترکہ لاگت بن جائے تو اپنی الگ operating system کو maintain کرنا مہنگا ہوتا ہے، اور ہر vendor اس کے اوپر والی layer پر مقابلہ کرنا پسند کرتا ہے۔

Corporate ownership کا اثر دوسری سمت میں بھی ظاہر ہوتا ہے۔ جب Oracle نے 2010 میں Sun کو خریدا تو اسے MySQL اور OpenOffice.org بھی حاصل ہوئے، اور دونوں communities الگ ہو گئیں۔ MariaDB، MySQL سے نکلا، جبکہ LibreOffice کو September 2010 میں OpenOffice.org سے fork کیا گیا۔ Fork ہی وہ واحد حقیقی vote ہے جو user community کے پاس ہوتا ہے، اور licence اس vote کو ممکن بناتا ہے۔

آپ کی self-hosted ایپس میں سے بعض کے forks کیوں بنے

2018 کے بعد سے کئی کمپنیوں نے پہلے سے released software کی شرائط تبدیل کر دیں۔ ہر بار صورتِ حال تقریباً ایک جیسی تھی۔ ایک کمپنی نے تقریباً تمام developers ملازم رکھے ہوئے تھے، ایک بہت بڑے cloud provider نے اسی software کو managed service کے طور پر فروخت کیا، اور چھوٹی کمپنی نے فیصلہ کیا کہ licence ہی وہ وجہ ہے جس کے باعث وہ مقابلہ نہیں کر سکتی۔

• MongoDB نے October 2018 میں Server Side Public License (SSPL) اختیار کیا۔ SSPL کے مطابق اگر آپ یہ software دوسروں کو service کے طور پر فراہم کرتے ہیں تو اس service کی فراہمی کے لیے استعمال ہونے والی ہر چیز کا source شائع کرنا لازم ہے۔ OSI نے اسے open source کے طور پر قبول نہیں کیا، اور MongoDB نے 2019 میں اسے review سے واپس لے لیا۔
• Redis نے 2018 اور 2019 میں بعض modules کے استعمال پر پابندیاں شامل کیں، پھر March 2024 میں version 7.4 کے ساتھ main server کو دوہری source-available شرائط کے تحت منتقل کر دیا۔ آخری BSD-licensed release کا fork چند دن بعد Valkey کے نام سے سامنے آیا۔ یہ Linux Foundation کے تحت ہے اور Amazon، Google اور Oracle سمیت دیگر اداروں کی حمایت رکھتا ہے۔ May 2025 میں Redis نے Redis 8 کے لیے تیسرے اختیار کے طور پر Affero General Public License version 3 (AGPLv3) شامل کیا، جسے OSI نے منظور کیا ہے۔
• Elastic نے January 2021 میں Elasticsearch اور Kibana کو Apache 2.0 سے ہٹا کر SSPL اور Elastic License کی دوہری شرائط کے تحت منتقل کر دیا۔ Amazon نے OpenSearch fork کیا۔ Elastic نے August 2024 میں تیسرے اختیار کے طور پر AGPLv3 شامل کیا، اور September 2024 میں OpenSearch کو Linux Foundation کے تحت OpenSearch Software Foundation کے طور پر منتقل کر دیا گیا۔
• HashiCorp نے August 2023 میں Terraform اور اپنے دیگر tools کو Business Source License (BUSL) کے تحت منتقل کر دیا۔ جب تک BUSL نافذ رہتا ہے، یہ open source licence نہیں ہے، کیونکہ یہ مسابقتی production use سے منع کرتا ہے۔ ہر release ایک مقررہ تاریخ کو open licence میں تبدیل ہو جاتی ہے؛ Terraform کے لیے یہ تاریخ چار سال بعد آتی ہے۔ OpenTofu چند ہفتوں کے اندر fork کیا گیا اور اب یہ بھی Linux Foundation کے تحت ہے۔

اس معاملے میں دونوں فریقوں کے مؤقف میں حقیقت موجود ہے اور کوئی بھی بدنیتی سے کام نہیں کر رہا۔ ایک کمپنی جب پچاس ملازمین کی تنخواہیں ادا کر رہی ہو اور اس سے کہیں بڑی کمپنی اس کے کام کو دوبارہ فروخت کر رہی ہو تو اسے ایسا مسئلہ درپیش ہوتا ہے جسے محض خیرسگالی سے حل نہیں کیا جا سکتا۔ جس user نے Apache 2.0 کی شرائط کے تحت اپنا نظام بنایا ہو اور پھر نئی شرائط کے تحت بیدار ہو، اسے بھی مسئلہ درپیش ہوتا ہے، اور پہلے کسی نے اس سے اجازت نہیں لی تھی۔ ان میں سے دو معاملات میں اس کے بعد جو ہوا، اسے دیکھیں۔ forks کے مضبوط ہو جانے کے بعد Elastic اور Redis دونوں نے دوبارہ strong copyleft شامل کیا۔ Copyleft نے اصل شکایت کا جواب دیا، کیونکہ AGPLv3 service provider کو اپنے چلائے جانے والے changes شائع کرنے کا پابند کرتی ہے۔ August 2026 تک دونوں projects اور دونوں forks فعال ہیں، اور licences کا مقصد بھی یہی نتیجہ ممکن بنانا تھا۔

لائسنس میں تبدیلی کی اجازت کس کو ہے

کسی project کا licensing model اسی وقت تبدیل کیا جا سکتا ہے جب ایک فریق اس کے تمام حصوں کے copyright کو کنٹرول کرتا ہو۔ Companies یہ control دو طریقوں میں سے ایک سے حاصل کرتی ہیں۔ Copyright assignment کے ذریعے ہر contribution کی ملکیت company کو منتقل ہو جاتی ہے۔ Contributor licence agreement (CLA) میں ownership آپ کے پاس رہتی ہے، لیکن company کو آپ کے کام کا licensing model تبدیل کرنے کے لیے کافی وسیع حقوق مل جاتے ہیں۔ عموماً دونوں میں سے کوئی ایک agreement اس link پر click کر کے sign کیا جاتا ہے جسے bot آپ کی پہلی pull request پر post کرتا ہے۔

Linux میں CLA نہیں ہے۔ Contributions GPLv2 کے تحت Developer Certificate of Origin کے ساتھ شامل ہوتی ہیں، اور copyright ہزاروں افراد اور companies میں تقسیم ہے۔ کوئی بھی Linux کا licensing model تبدیل نہیں کر سکتا، کیونکہ تمام متعلقہ signatures جمع کرنا ممکن نہیں ہوگا۔ یہی تحفظ ہر ایسے project پر بھی لاگو ہوتا ہے جس کے copyright holders بہت سے اور خودمختار ہوں۔ یہ کسی وعدے سے زیادہ مضبوط تحفظ ہے، کیونکہ یہ اس حقیقت پر مبنی ہے کہ کس کی ملکیت کیا ہے۔

اس لیے جس software پر آپ انحصار کرنے کا ارادہ رکھتے ہیں، اس کے بارے میں اصل سوال یہ نہیں کہ وہ آج open source ہے یا نہیں۔ اصل سوال یہ ہے کہ اس میں تبدیلی کون کر سکتا ہے، اور کیا وہ یہ کام اکیلے کر سکتا ہے۔

حقیقت میں foundation آپ کو کیا فراہم کرتی ہے

foundation اثاثے اپنے پاس رکھتی ہے اور فیصلہ سازی کے قواعد طے کرتی ہے۔ Apache Software Foundation، Linux Foundation، اس کے اندر موجود Cloud Native Computing Foundation، اور Software Freedom Conservancy، ہر ایک یہ کام اپنے انداز میں انجام دیتی ہے۔ foundation محض نام کی وجہ سے غیر جانب دار نہیں ہوتی۔ اراکین اپنی نشستوں کے لیے ادائیگی کرتے ہیں، اور کسی بڑی foundation کے project پر full time کام کرنے والے زیادہ تر افراد کو رکن کمپنیاں تنخواہ دیتی ہیں۔ آپ کو جو چیز ملتی ہے وہ زیادہ محدود، لیکن پھر بھی بہت اہم ہے: trademark اور release process کسی ایک vendor کی ملکیت نہیں ہوتے، اس لیے کوئی ایک company project کو نجی نہیں بنا سکتی۔

trademark وہ حصہ ہے جسے لوگ نظر انداز کر دیتے ہیں۔ code کو licence حاصل ہوتا ہے۔ نام trademark ہوتا ہے، اور trademark code licence کے دائرے میں نہیں آتا۔ آپ code کو ہمیشہ fork کر سکتے ہیں۔ لیکن عموماً نام برقرار نہیں رکھ سکتے۔ اسی لیے اس مثال میں forks کو Valkey، OpenSearch، OpenTofu اور Forgejo کہا جاتا ہے۔

مینٹینر کا مسئلہ

جدید infrastructure ایسے projects پر قائم ہے جنہیں ایک یا دو بلا معاوضہ maintainers چلاتے ہیں، اور ناکامیاں اس حقیقت کو نمایاں کرتی ہیں۔ 2014 میں OpenSSL میں موجود Heartbleed bug نے ایسی library کو متاثر کیا جو ویب کے encrypted traffic کے بڑے حصے کو سنبھالتی تھی، جبکہ اسے تقریباً نہ ہونے والی مالی معاونت کے ساتھ چند افراد maintain کر رہے تھے۔ دسمبر 2021 میں Log4Shell کے واقعے کے دوران دنیا بھر کے incident response کو Apache Log4j project کی ایک چھوٹی volunteer team کے ذریعے coordinate کرنا پڑا۔

مارچ 2024 میں دریافت ہونے والا XZ Utils backdoor اس مسئلے کی سب سے واضح مثال ہے، کیونکہ حملے کا ہدف code کے بجائے maintainer تھا۔ ایک account نے تقریباً 2 سال ایسے حقیقی طور پر مفید contributions دیے جو Linux distributions میں استعمال ہونے والی compression library کے لیے تھے۔ دوسرے accounts نے تھکے ہوئے واحد maintainer پر help قبول کرنے کے لیے دباؤ ڈالا۔ اس کے بعد نئے co-maintainer نے release archives میں ایک backdoor شامل کر دیا۔ اس کا ہدف ایسے systems تھے جہاں SSH (secure shell) daemon، liblzma کے خلاف link ہوتا ہے۔ ایک developer نے یہ backdoor اس وقت دریافت کیا جب وہ یہ جانچ رہا تھا کہ logins توقع سے تقریباً آدھا سیکنڈ زیادہ وقت کیوں لے رہے ہیں۔ یہ محض خوش قسمتی تھی، اور اس واقعے میں شامل سب افراد نے عوامی طور پر یہی بات کہی ہے۔

اب مالی معاونت آنا شروع ہو گئی ہے: 2019 سے GitHub Sponsors، Open Collective، 2022 سے Germany کا Sovereign Tech Fund، اور OpenSSF کا Alpha-Omega project۔ یہ معاونت یکساں طور پر نہیں پہنچتی، اور عموماً انہی projects تک پہنچتی ہے جو پہلے ہی مشہور ہوتے ہیں۔ Regulation بھی آ رہی ہے۔ European Union کا Cyber Resilience Act دسمبر 2024 میں نافذ ہوا، جبکہ اس کی زیادہ تر ذمہ داریاں دسمبر 2027 سے لاگو ہوں گی۔ ابتدائی drafts میں manufacturer liability بلا معاوضہ volunteers پر عائد ہونے کا امکان تھا۔ اس لیے foundations اور distributions کی طویل lobbying کے بعد حتمی متن میں "open source software steward" کے نام سے ایک ہلکا تر category شامل کی گئی ہے۔

اوپن سورس کی تاریخ آپ کے VPS پر موجود سافٹ ویئر کے بارے میں کیا بتاتی ہے

ہماری self-hosting گائیڈز میں شامل ہر ایپ ان فیصلوں کے اثرات کے تحت کام کرتی ہے۔ Nextcloud ایک fork کی وجہ سے موجود ہے: 2016 میں ownCloud کے بانی اور ٹیم کے بیشتر ارکان الگ ہو گئے اور AGPLv3 کے تحت project دوبارہ شروع کیا۔ اس کے بعد سے دونوں products متوازی طور پر چل رہے ہیں۔ یہی تاریخ قابل غور Nextcloud متبادل اور self-hosted Dropbox متبادل کا پس منظر ہے، جو دونوں products سے مقابلہ کرتے ہیں۔

Git hosting میں بھی یہی صورت حال نظر آتی ہے۔ Gitea خود 2016 میں Gogs کے fork کے طور پر شروع ہوا۔ 2022 کے آخر میں project کا trademark اور domains ایک کمپنی کو منتقل ہوئے، دسمبر میں Codeberg نے Forgejo کو fork کیا، اور 2024 میں version 9 کے ساتھ Forgejo MIT سے GPLv3 پر منتقل ہو گیا۔ دونوں کا ذکر self-hosted Git server کے اختیارات میں ہے، اور licence کا فرق اس بات کی بڑی وجہ ہے کہ دونوں projects مسلسل مختلف سمتوں میں بڑھ رہے ہیں۔ دوسری طرف زیادہ تر free software GitHub پر تیار کیا جاتا ہے، جو Microsoft کی ملکیت والا closed platform ہے۔ اس موضوع پر طویل عرصے سے بحث جاری ہے اور دونوں جانب مضبوط دلائل موجود ہیں: GitHub اصل میں کیا ہے دیکھیں۔

کسی project کے لیے server مختص کرنے سے پہلے چار جانچیں دس منٹ کے قابل ہیں۔

• marketing page کے بجائے repository میں موجود LICENSE file پڑھیں۔ Pages اس وقت بھی "open source" لکھتے رہتے ہیں جب file اس دعوے کی تائید کرنا بند کر چکی ہو۔
• CLA یا copyright assignment تلاش کریں۔ اگر ایسا کوئی انتظام موجود ہو تو ایک واحد مالک future releases کی شرائط تبدیل کر سکتا ہے۔
• معلوم کریں کہ copyright کس کے پاس ہے: ایک کمپنی، متعدد contributors، یا کوئی foundation۔
• active maintainers گنیں۔ صرف ایک maintainer والا project اس شخص کے لیے بھی اتنا ہی خطرہ ہے جتنا آپ کے لیے۔

اس کا مطلب یہ نہیں کہ single-vendor software سے گریز کریں۔ ان میں سے بہت سا software بہترین ہوتا ہے، اور اس کے لیے ادائیگی ملنا اکثر اس کی maintenance جاری رہنے کی وجہ ہوتا ہے۔ اس سے صرف یہ معلوم ہوتا ہے کہ آپ کس چیز کے سامنے exposed ہیں۔ جب آپ فیصلہ کریں کہ کیا self-host کرنا قابل قدر ہے، تو comparison میں memory requirement کے ساتھ licence کو بھی شامل کریں۔

آپ اس تاریخ کا کچھ حصہ اپنے سامنے موجود machine پر پڑھ سکتے ہیں۔ Debian یا Ubuntu system کا ہر package اپنی شرائط کے ساتھ آتا ہے:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

پہلا number ان installed packages کی تعداد ہے جن میں copyright file موجود ہے۔ چھوٹے VPS میں یہ تعداد عموماً چند سو ہوتی ہے۔ دوسری command bash کی copyright file کا ابتدائی حصہ دکھاتی ہے، جس میں GNU General Public License version 3 کا نام درج ہے۔ File کا نہ ملنا اس بات کی علامت ہے کہ package Debian policy کے مطابق build نہیں کیا گیا۔ یہ نایاب صورت حال ہے، اور اس package پر اعتماد کرنے سے پہلے دوبارہ جانچ ضروری ہے۔

FAQ

free software اور open source میں کیا فرق ہے؟

یہ دونوں تقریباً ایک ہی لائسنسوں کا احاطہ کرتے ہیں، لیکن اس بات پر اختلاف ہے کہ وہ لائسنس کیوں اہم ہیں۔ "Free software" پرانی اصطلاح ہے، جو 1985 میں Free Software Foundation سے آئی۔ اس کا مؤقف اخلاقی ہے: جو صارف پروگرام تبدیل نہیں کر سکتا، وہ کمپیوٹر کو کنٹرول نہیں کرتا۔ "Open source" کی اصطلاح فروری 1998 میں اس لیے وضع کی گئی کہ انہی لائسنسوں کی وضاحت کمپنیوں کے لیے آسان ہو، اور اس کا مؤقف عملی ہے۔ GPL، MIT، BSD اور Apache 2.0 لائسنس دونوں سرکاری فہرستوں میں شامل ہیں۔ جو مصنفین دونوں کا مفہوم ایک ساتھ ادا کرنا چاہتے ہیں، وہ FOSS یا FLOSS استعمال کرتے ہیں۔

کیا source-available software اور open source ایک ہی ہیں؟

نہیں۔ source-available کا مطلب ہے کہ آپ code پڑھ سکتے ہیں۔ Open Source Definition کے مطابق open source کا مطلب یہ بھی ہے کہ لائسنس اس بات پر پابندی نہ لگائے کہ سافٹ ویئر کون استعمال کر سکتا ہے یا اسے کس مقصد کے لیے استعمال کیا جا سکتا ہے۔ SSPL اور Business Source License دونوں مسابقتی تجارتی استعمال کو محدود کرتے ہیں، اس لیے اس تعریف کے مطابق دونوں open source نہیں ہیں، اگرچہ دونوں اپنا source شائع کرتے ہیں۔ اگر آپ صرف اپنے لیے self-host کرتے ہیں تو یہ پابندی شاید کبھی آپ پر لاگو نہ ہو۔ اگر آپ اس کے اوپر کوئی product بنانا چاہتے ہیں تو پہلے لائسنس کا متن غور سے پڑھیں۔

کیا کوئی کمپنی پہلے سے دیے گئے open source لائسنس کو واپس لے سکتی ہے؟

اس code کے لیے نہیں جسے وہ پہلے ہی release کر چکی ہو۔ وہ version اسی لائسنس کے تحت رہتا ہے جس کے ساتھ اسے release کیا گیا تھا۔ اسی وجہ سے Valkey اور OpenTofu جیسے forks آخری permissively licensed commit سے شروع ہو سکے۔ کمپنی آئندہ versions کو نئی شرائط کے تحت جاری کر سکتی ہے، لیکن یہ صرف اسی صورت میں ممکن ہے جب assignment یا contributor licence agreement کے ذریعے پورے project کے copyright پر اس کا کنٹرول ہو۔ جن projects کے copyright holders متعدد آزاد فریق ہوں، Linux سمیت، انہیں کوئی بھی شخص دوبارہ لائسنس نہیں کر سکتا۔

self-hosted software میں مجھے کون سا لائسنس تلاش کرنا چاہیے؟

جس software کو آپ خود چلاتے ہیں اور دوبارہ فروخت نہیں کرتے، اس کے لیے GPL، AGPL، MIT یا Apache 2.0 جیسے OSI-approved لائسنس آپ کی تمام ضروریات پوری کرتے ہیں۔ زیادہ مفید جانچ یہ ہے کہ copyright کس کے پاس ہے، کیونکہ اسی سے طے ہوتا ہے کہ بعد میں شرائط آپ کی رضامندی کے بغیر تبدیل کی جا سکتی ہیں یا نہیں۔ کسی foundation یا متعدد آزاد contributors کے پاس موجود project کو اس کے users کے خلاف دوبارہ لائسنس نہیں کیا جا سکتا۔ Single-vendor project، جس میں contributor licence agreement ہو، دوبارہ لائسنس کیا جا سکتا ہے۔ دونوں اچھے software ہو سکتے ہیں۔ صرف ایک فریق اپنے طور پر قواعد تبدیل کر سکتا ہے۔