GPL بمقابلہ MIT بمقابلہ Apache: آپ سے کیا تقاضا ہے

GPL بمقابلہ MIT بمقابلہ Apache: ہر license آپ سے کیا تقاضا کرتا ہے

GPL، MIT اور Apache 2.0 ایک ہی سوال کے مختلف جواب دیتے ہیں: جب آپ software دوسروں کو فراہم کرتے ہیں تو آپ پر ان کا کیا حق واجب ہوتا ہے؟ MIT صرف copyright notice کا تقاضا کرتا ہے، اس کے علاوہ کچھ نہیں۔ Apache 2.0 اس notice کے ساتھ ہر اس شخص کے درمیان patent معاہدہ بھی شامل کرتا ہے جو code میں حصہ لیتا ہے۔ GPL کا تقاضا ہے کہ آپ اپنے تیار کردہ software کے source کو اسی license کے تحت شائع کریں جس کے تحت آپ کو software ملا تھا۔

یہ معاملہ اس وقت تک lawyers کے لیے موزوں سوال محسوس ہوتا ہے جب تک آپ کے زیرِ انتظام کوئی project اپنا license تبدیل کر کے دو حصوں میں تقسیم نہ ہو جائے۔ اس کے بعد یہ operations کا سوال بن جاتا ہے۔ آپ کو دو package repositories میں سے ایک کا انتخاب کرنا پڑتا ہے، جبکہ client libraries ایک دوسرے کے ساتھ رابطہ کرنا بند کر دیتی ہیں۔ یہ guide ان licenses اور ان کے طریقۂ کار کے بارے میں ہے، نہ کہ اس تحریک کے بارے میں جس نے انہیں جنم دیا۔ اسی لیے ہر section وہاں ختم ہوتا ہے جہاں اس کا تعلق آپ سے بنتا ہے: اس شخص سے جسے upgrade چلانا ہوتا ہے۔

GPL کیوں موجود ہے: ایک ایسا printer جسے کوئی ٹھیک نہیں کر سکتا تھا

1980 کے آس پاس MIT Artificial Intelligence Lab کو Xerox 9700 laser printer ملا۔ لیب نے ایک پہلے printer کے software میں ترمیم کی تھی تاکہ وہ بتا سکے کہ آپ کا job کب jam ہو گیا ہے۔ نئے printer کے لیے source code دستیاب نہیں تھا، اور nondisclosure agreement کی وجہ سے اسے فراہم کرنے کی درخواست مسترد کر دی گئی۔ اس وقت لیب کے programmer Richard Stallman نے اس انکار کو محض ایک خراب تجربہ نہیں بلکہ عام صورتِ حال سمجھا، اور 27 September 1983 کو GNU project کا اعلان کیا۔

Copyleft، copyright law ہی سے اخذ ہوتا ہے، اس کے خلاف نہیں۔ عام طور پر آپ کو کسی دوسرے کے code کو copy کرنے کا کوئی حق حاصل نہیں ہوتا۔ GPL یہ حق ایک شرط کے ساتھ دیتی ہے: اگر آپ program کسی دوسرے شخص کو دیتے ہیں تو آپ کو اسے source code بھی اسی شرائط کے تحت دینا ہوگا، تاکہ وہ وہ کام کر سکے جو لیب نہیں کر سکی۔ یہ شرط نافذ کی جا سکتی ہے، کیونکہ licence کے بغیر آپ کو ابتدا ہی میں copy تقسیم کرنے کی اجازت حاصل نہیں تھی۔

Stallman نے پہلے GNU Emacs کے لیے licence لکھی، پھر اسے عام شکل دے کر 25 February 1989 کو GPL version 1 بنایا۔ GPL version 2، June 1991 میں جاری ہوئی، اور آج بھی زیادہ تر system software کی licence یہی ہے۔ Libraries کے لیے Lesser GPL متعارف کرائی گئی، تاکہ copyleft library کو کسی بھی licence کے تحت program سے link کیا جا سکے، اور وہ program خود GPL کے دائرے میں نہ آ جائے۔

ایک تفصیل یہ طے کرتی ہے کہ GPL کسی self-hoster کو کیسے متاثر کرتی ہے۔ یہ ذمہ داری use پر نہیں بلکہ distribution پر عائد ہوتی ہے۔ آپ GPL program میں ترمیم کر سکتے ہیں، اسے اپنے server پر چلا سکتے ہیں، اور اس کے ذریعے عوام کو service دے سکتے ہیں، پھر بھی آپ کسی کے ذمہ دار نہیں ہوں گے، کیونکہ آپ نے کسی کو اس کی copy فراہم نہیں کی۔ یہی خلا AGPL کے وجود کی وجہ ہے۔

رواداری کی روایت: BSD، پھر MIT

Berkeley نے مختلف راستہ اختیار کیا۔ Computer Systems Research Group نے اپنا Unix کام ایسے license کے تحت جاری کیا جس میں copyright notice برقرار رکھنے کا تقاضا تھا اور تمام warranty سے دست برداری شامل تھی۔ اصل ورژن میں چار clauses تھے۔ چوتھا clause، یعنی advertising clause، تقاضا کرتا تھا کہ software کی خصوصیات کا ذکر کرنے والے ہر advertising material میں University کا اعتراف شامل ہو۔ یہ طریقہ بڑے پیمانے پر قابل عمل نہیں تھا۔ Stallman نے NetBSD کے 1997 ورژن میں 75 الگ acknowledgements شمار کیے۔ UC Berkeley نے William Hoskins، جو اس کے Office of Technology Licensing سے وابستہ تھے، کے خط کے ذریعے 22 July 1999 کو یہ clause واپس لے لیا۔

باقی 3-clause BSD licence رہ جاتی ہے، جس میں contributors کے نام اپنے product کی endorsement کے لیے استعمال کرنے پر پابندی شامل ہے۔ 2-clause ورژن میں یہ پابندی بھی ختم کر دی گئی ہے۔ MIT licence کا متن 1980s میں MIT سے سامنے آیا، جہاں یہ X Window System کے لیے استعمال ہوتا تھا۔ عملی طور پر یہ 2-clause BSD جیسا ہی کام کرتا ہے۔

مقاصد مختلف تھے۔ عوامی رقم سے چلنے والی University چاہتی تھی کہ اس کا کام companies سمیت ہر جگہ استعمال ہو۔ GNU project ایسا commons چاہتا تھا جسے بند نہ کیا جا سکے۔ دونوں مؤقف دیانت دار ہیں، اور دونوں میں failure mode موجود ہے۔ Permissive code کو private کیا جا سکتا ہے، اور آپ کو اس کے بدلے کچھ واپس نہیں ملتا۔ Companies copyleft code سے انکار کرتی ہیں کیونکہ ان کے lawyers یہ شرط قبول نہیں کرتے۔

Berkeley سے ایک دوسرا سبق بھی ملتا ہے، اور یہی وہ نکتہ ہے جس کی طرف یہ post بار بار لوٹتی ہے۔ AT&T's Unix System Laboratories نے 1992 میں BSD code کے معاملے پر Berkeley Software Design کے خلاف مقدمہ دائر کیا، اور یہ مقدمہ early 1994 میں طے ہو گیا۔ دو سال تک کوئی یقین سے نہیں کہہ سکتا تھا کہ BSD پر build کرنا محفوظ ہے۔ اسی دوران adoption رک گئی جبکہ Linux پھیلتا رہا۔ Legal uncertainty، missing feature کے مقابلے میں adoption کو زیادہ تیزی سے روکتی ہے۔

Apache 2.0 نے patent grant کیوں شامل کیا

Apache Group کا پہلا licence بھی BSD 4-clause کا مشتق تھا اور اس میں وہی advertising مسئلہ موجود تھا۔ Version 1.1 نے 2000 میں یہ clause ختم کر دیا۔ Version 2.0، جو January 2004 میں شائع ہوا، محض patch نہیں بلکہ ازسرنو تحریر تھا۔

اہم اضافہ patents سے متعلق ہے۔ MIT اور BSD میں ان کے بارے میں بالکل کچھ نہیں کہا گیا۔ کوئی contributor آپ کو اپنے code کے لیے واضح copyright اجازت دے سکتا ہے، لیکن پھر بھی ایسا patent رکھ سکتا ہے جو اس code کے کام کرنے کے طریقے پر لاگو ہو، اور وہ اسے استعمال کرنے والے لوگوں کے خلاف مقدمہ دائر کر سکتا ہے۔ Apache 2.0 اس خلا کو پُر کرتا ہے: ہر contributor اپنی contribution کا احاطہ کرنے والا patent licence دیتا ہے، اور جو شخص یہ دعویٰ کرتے ہوئے مقدمہ دائر کرے کہ یہ work اس کے patents کی خلاف ورزی کرتا ہے، وہ اس work کے لیے اپنا patent licence کھو دیتا ہے۔ یہ threat باہمی ہے، اس لیے عملی طور پر کوئی فریق کارروائی نہیں کرتا۔

2.0 کا باقی حصہ انتظامی نوعیت کا ہے، اور یہی وجہ ہے کہ کمپنیاں اسے پسند کرتی ہیں۔ ایک متعین NOTICE file موجود ہوتی ہے، اس لیے attribution پورے tree میں بکھرنے کے بجائے ایک ہی جگہ رہتی ہے۔ Licence کو ہر source file میں paste کرنے کے بجائے reference کے ذریعے لاگو کیا جا سکتا ہے۔ Contributions واضح شرائط کے تحت آتی ہیں۔ Trademarks خارج ہیں۔ Apache 2.0 dependency کا legal review کرتے وقت مطلوبہ ہر سوال کا جواب پہلے ہی متن میں موجود ہوتا ہے، اس لیے approval معمول کا عمل بن جاتا ہے، اور "corporate default" کا زیادہ تر مطلب یہی ہے۔

GPLv3 میں کیا بدلا، اور Linux GPLv2 پر کیوں برقرار رہا

TiVo نے Linux چلانے والا ایک video recorder جاری کیا اور kernel کا source شائع کیا، جیسا کہ GPLv2 کا تقاضا ہے۔ اس hardware نے boot کے وقت cryptographic signature کی جانچ کی اور ایسے kernel کو چلانے سے انکار کر دیا جسے وہ شناخت نہ کر سکے۔ آپ source پڑھ سکتے تھے، اس میں تبدیلی کر سکتے تھے، اور اسے compile کر سکتے تھے۔ لیکن آپ اسے اسی device پر نہیں چلا سکتے تھے جس سے وہ حاصل ہوا تھا۔ لائسنس کی ظاہری شرائط پوری ہوئیں، لیکن اس کا مقصد ناکام بنا دیا گیا۔ اس عمل کو tivoisation کا نام ملا۔

GPL version 3، جو 29 June 2007 کو شائع ہوا، اس صورتِ حال کا براہِ راست جواب ہے۔ جب آپ کسی consumer device کے اندر binary فراہم کرتے ہیں تو آپ کو "Installation Information" بھی فراہم کرنا ہوتی ہے۔ اس میں modified version install کرکے اسے چلانے کے لیے درکار keys یا instructions شامل ہیں۔ Version 3 نے ایک واضح patent grant بھی شامل کیا۔ اس میں November 2006 کے Microsoft اور Novell patent agreement کے جواب میں لکھی گئی شرائط بھی شامل تھیں، اور Apache 2.0 کے ساتھ one-way compatibility بھی دی گئی۔

Linux نے اس تبدیلی کی پیروی نہیں کی۔ Kernel صرف GPL version 2 کے تحت ہے۔ اس میں "or any later version" کی اجازت دینے والی شق موجود نہیں، اور اس کی COPYING file بھی یہی بیان کرتی ہے۔ Linus Torvalds نے signed hardware کے لیے anti-tivoisation شرائط پر عوامی طور پر اعتراض کیا۔ عملی رکاوٹ اس اختلاف سے بھی بڑی ہے۔ Kernel کے ہزاروں copyright holders ہیں۔ اس لیے relicence کے لیے درکار اجازتیں کوئی حاصل نہیں کر سکتا، چاہے سب اس پر رضامند ہی کیوں نہ ہوں۔ یہ واحد حقیقت کسی project کے لیے سب سے مضبوط تحفظ بن سکتی ہے۔ کسی ایک company کی ملکیت والے project کا جائزہ لیتے وقت اسے یاد رکھنا مفید ہے۔

2007 کا دوسرا licence آپ کے لیے زیادہ اہم ہے۔ GNU Affero GPL version 3، جو اسی سال November میں شائع ہوا، source فراہم کرنے کی ذمہ داری ان لوگوں تک بڑھاتا ہے جو network کے ذریعے program کے ساتھ interact کرتے ہیں۔ اگر آپ modified AGPL service عوام کے لیے چلاتے ہیں تو آپ ان users کو source فراہم کرنے کے پابند ہیں۔ اسی وجہ سے بہت سا self-hosted web software AGPL کے تحت ہے۔ Nextcloud اس کی ایک مثال ہے۔ اگر آپ Nextcloud کے self-hosted متبادل کا تقابل کر رہے ہیں تو ہر candidate کے repository میں موجود licence line اس کی اگلے پانچ سال کی سمت کے بارے میں اس کی feature list سے زیادہ بتاتی ہے۔

آپ عملی طور پر کون سے licences یکجا کر سکتے ہیں؟

Compatibility ایک ہی سمت میں کام کرتی ہے: permissive licences سے copyleft licences کی طرف۔

• MIT اور BSD code کو کسی بھی project میں شامل کیا جا سکتا ہے، حتیٰ کہ closed product میں بھی۔
• Apache 2.0 code کو GPLv3 project میں شامل کیا جا سکتا ہے، اور combined work GPLv3 کے تحت ہوتا ہے۔
• Apache 2.0 code کو GPLv2-only project میں شامل نہیں کیا جا سکتا۔ اس کی patent termination اور indemnity شرائط اضافی conditions ہیں، جنہیں GPLv2 شامل کرنے کی اجازت نہیں دیتا۔ FSF اور ASF دونوں یہی نتیجہ شائع کرتے ہیں۔
• آپ GPL code کو اپنی طرف سے permissive licence میں منتقل نہیں کر سکتے۔ یہ صرف copyright holders کر سکتے ہیں، اس لیے معاملہ دوبارہ اسی سوال پر آ جاتا ہے کہ وہ کون ہیں۔

ری لائسنسنگ کا دور: SSPL، BUSL، اور یہ کیا نہیں ہیں

اس کا محرک تجارتی تھا۔ کسی کمپنی کے پاس کسی product کا copyright ہوتا ہے، کوئی cloud provider اسے بڑے پیمانے پر managed service کے طور پر فروخت کرتا ہے اور بدلے میں بہت کم تعاون کرتا ہے، تو کمپنی اس صورت حال کو روکنے کے لیے licence تبدیل کر دیتی ہے۔ Redis Labs نے اگست 2018 میں کئی modules کے لیے Apache 2.0 کے اوپر Commons Clause شامل کر کے پہلا نمایاں قدم اٹھایا۔ MongoDB نے 16 October 2018 کو AGPLv3 سے Server Side Public License پر منتقل ہو کر اس کی پیروی کی۔

SSPL، AGPL ہی ہے جس کا ایک section دوبارہ لکھا گیا ہے۔ اگر آپ program کو تیسرے فریق کو service کے طور پر فراہم کرتے ہیں تو آپ کو اسے فراہم کرنے کے لیے استعمال ہونے والی ہر چیز کا source publish کرنا ہوگا، جس میں اس کے گرد موجود management اور orchestration software بھی شامل ہے۔ اس obligation کی واضح حد موجود نہیں، اور کسی عدالت نے اسے آزمایا نہیں ہے۔ OSI نے اس licence کو کبھی منظور نہیں کیا، اور MongoDB نے March 2019 میں اپنی application واپس لے لی۔ Debian پہلے ہی December 2018 میں کہہ چکا تھا کہ SSPL software اس کے archive میں شامل نہیں ہونا چاہیے، اور Fedora نے January 2019 میں فیصلہ دیا کہ یہ licence free نہیں ہے۔ اس کے بعد Red Hat نے MongoDB کو Fedora اور Red Hat Enterprise Linux دونوں سے ہٹا دیا۔ ری لائسنسنگ کا عملی نتیجہ یہی ہوتا ہے: distribution software کی packaging بند کر دیتی ہے، اس لیے آپ کے upgrades اب vendor repository سے vendor کے schedule کے مطابق آتے ہیں۔

Business Source License ایک مختلف طریقہ ہے۔ یہ MariaDB کے founders کی طرف سے آیا، اور version 1.1 کا تعلق 2017 سے ہے۔ یہ copyleft نہیں ہے اور open source بھی نہیں ہے۔ Source عوامی ہوتا ہے، استعمال مفت ہوتا ہے، سوائے اس استعمال کے جسے vendor licence سے خارج کرتا ہے۔ عموماً یہ کسی competing hosted service کو چلانا ہوتا ہے۔ ہر release خودکار طور پر change date پر ایک حقیقی open source licence میں تبدیل ہو جاتا ہے، اور یہ date اس release کے چار سال بعد سے زیادہ نہیں ہو سکتی۔ جس licence میں تبدیلی ہو، اس کا GPLv2-compatible ہونا ضروری ہے۔ HashiCorp نے 10 August 2023 کو Terraform اور اپنی دیگر products کو BUSL 1.1 پر منتقل کیا۔ Outline بھی اسے استعمال کرتا ہے، اور اگر آپ خود میزبانی کے لیے Notion کے متبادل منتخب کر رہے ہیں تو یہ بات جاننا مفید ہے: اسے اپنی team کے لیے چلانا allowed ہے، لیکن اس پر service بنانا allowed نہیں ہے۔

دونوں licences بے ایمانی پر مبنی نہیں ہیں۔ دونوں واضح طور پر کہتے ہیں کہ وہ source available ہیں۔ OSI کی definition کے مطابق ان میں سے کوئی بھی open source نہیں ہے، اور اس فرق کا اثر cloud provider کے بجائے آپ پر پڑتا ہے، حالانکہ licence کا ہدف cloud provider ہی تھا۔

OpenSearch: آپریٹر کے لیے لائسنس fork کی لاگت

Elastic نے 14 January 2021 کو اعلان کیا کہ Elasticsearch اور Kibana، release 7.11 سے Apache 2.0 چھوڑ کر SSPL یا Elastic License میں سے ایک لائسنس اختیار کریں گے۔ Version 7.10.2 آخری Apache 2.0 release تھا۔ تقریباً ایک ہفتے بعد AWS نے کہا کہ وہ دونوں کا Apache 2.0 fork بنائے گا اور اسے maintain کرے گا۔ 12 April 2021 کو اس fork کا نام OpenSearch رکھا گیا، جبکہ Kibana کا نام بدل کر OpenSearch Dashboards کر دیا گیا۔ OpenSearch 1.0، Elasticsearch 7.10.2 اور Kibana 7.10.2 کی بنیاد پر تیار ہو کر 12 July 2021 کو عام طور پر دستیاب ہوا۔

دیکھیں کہ اس تبدیلی کی قیمت clusters چلانے والے لوگوں کو کیسے ادا کرنا پڑی۔ Package names اور repositories بدل گئے۔ Runbook میں Kibana کا ہر حوالہ OpenSearch Dashboards بن گیا۔ Plugin names منتقل ہوئے۔ پھر یہ تقسیم application code تک پہنچ گئی: Elastic کی official client libraries کے version 7.13 سے client یہ جانچتا ہے کہ وہ کس سے connected ہے، اور اگر سامنے موجود چیز Elasticsearch نہ ہو تو کام جاری رکھنے سے انکار کر دیتا ہے۔ وہ اطلاع دیتا ہے کہ server نامعلوم product ہے۔ ایسی کمپنی کا licence فیصلہ جس کے لیے آپ کام نہیں کرتے، آپ کی اپنی application کے اندر failing call بن گیا۔

اس کے بعد صورت حال مزید دو بار بدلی۔ 29 August 2024 کو Elastic نے AGPLv3 کو تیسرے licence option کے طور پر شامل کیا، اس لیے موجودہ Elasticsearch دوبارہ OSI-approved open source ہے۔ 16 September 2024 کو AWS نے OpenSearch کو Linux Foundation کے زیر انتظام OpenSearch Software Foundation کو منتقل کر دیا۔ اس سے fork کو ایسی governance home مل گئی جو کسی ایک کمپنی تک محدود نہیں ہے۔ تقسیم کے پانچ سال بعد دونوں projects open source ہیں، دونوں maintained ہیں، اور August 2026 تک OpenSearch اپنی 3.x series میں ہے۔

اختتام ہی اصل سبق ہے۔ Licence واپس آ گیا، لیکن fork برقرار رہا۔ جب ecosystem میں ہر چیز کے دو versions ہو جائیں تو کاغذی کارروائی واپس لینے سے وہ دوبارہ merge نہیں ہوتے۔

یہ فرق طے کرتا ہے کہ relicence سے کتنا نقصان ہوگا: vendor کے announcement اور ایسے stable fork کے درمیان کا فاصلہ جسے آپ واقعی deploy کر سکتے ہوں۔

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

ہر gap کو vendor کے public announcement سے fork کے پہلے stable release تک شمار کیا گیا ہے، اور اس کے لیے ذیل میں دی گئی dates استعمال کی گئی ہیں۔ OpenSearch 1.0 میں 179 دن لگے، کیونکہ fork کا نام بدلنا اور اسے دوبارہ build کرنا پڑا، جبکہ نقل کرنے کے لیے پہلے سے کوئی fork موجود نہیں تھا۔ OpenTofu میں 153 دن لگے۔ Valkey میں 27 دن لگے، کیونکہ اس نے Redis 7.2.4 کا fork بنایا اور protocol اور on-disk format کو یکساں رکھا۔ اصل مفید بات سمت ہے: اب ایک قابل اعتماد fork چند ہفتوں میں سامنے آ جاتا ہے، اور پہلے دن ہی foundation اور paid maintainers اس سے وابستہ ہوتے ہیں۔

Valkey اور OpenTofu: وہی نمونہ، زیادہ تیز رفتاری

Redis Ltd نے 20 مارچ 2024 کو Redis کو 3-clause BSD لائسنس سے RSALv2 یا SSPLv1 میں سے کسی ایک کے انتخاب پر منتقل کر دیا۔ آٹھ دن بعد Linux Foundation نے Valkey کا اعلان کیا، جو Redis 7.2.4 سے fork ہوا تھا اور BSD 3-clause کے تحت برقرار رہا۔ Valkey 7.2.5، 16 اپریل 2024 کو جاری ہوا۔ اس میں وہی protocol اور وہی data files تھیں، اس لیے زیادہ تر operators کے لیے migration صرف package name تبدیل کرنے تک محدود رہی۔ پھر Redis نے مئی 2025 میں Redis 8 میں AGPLv3 کو تیسرا اختیار شامل کیا۔ OSI کی تعریف کے مطابق اس سے Redis دوبارہ open source بن گیا، جبکہ Valkey اپنی الگ governance کے تحت جاری رہا۔ اس کی صورت حال Elasticsearch سے بہت ملتی ہے۔

Terraform نے بھی یہی راستہ اختیار کیا، مگر ایک اضافی باب کے ساتھ۔ OpenTofu نے Mozilla Public License 2.0 کے تحت جاری ہونے والے آخری release سے fork کیا، ستمبر 2023 میں Linux Foundation میں شامل ہوا، اور 10 جنوری 2024 کو 1.6.0 جاری کیا۔ 3 اپریل 2024 کو HashiCorp کے وکلا نے project کو cease and desist letter بھیجا۔ ان کا دعویٰ تھا کہ BUSL-licensed Terraform release کا code fork میں copy کیا گیا ہے۔ OpenTofu نے 11 اپریل 2024 کو تفصیلی جواب شائع کیا اور اس دعوے سے انکار کیا۔ اس نے متنازع code کا ماخذ اس MPL-licensed history کو قرار دیا جسے دونوں projects مشترک طور پر استعمال کرتے ہیں۔ اس کے بعد public سطح پر مزید کوئی پیش رفت نہیں ہوئی۔ اس واقعے کا اصل خطرہ یاد رکھنے کے قابل ہے: صرف ایک الزام بھی adoption کو ایک quarter تک روک سکتا ہے۔ تیس سال پہلے Berkeley lawsuit کا اثر بھی یہی تھا۔

ہر fork کا آغاز licence سے نہیں ہوتا۔ Forgejo نے 2022 میں Gitea سے fork کیا، کیونکہ Gitea کی development ایک company کے زیر انتظام منتقل ہو گئی تھی۔ یہ licensing کے بجائے governance کا اختلاف تھا۔ Forgejo اپنی version 8 series تک MIT کے تحت رہا، پھر 2024 میں version 9.0 سے GPLv3 or later کے تحت دوبارہ license کیا گیا، تاکہ اس کا code کسی commercial طور پر controlled product میں واپس شامل نہ کیا جا سکے۔ اگر آپ self-hosted Git server کے اختیارات کا جائزہ لے رہے ہیں تو یہ جوڑی ایک codebase اور دو مختلف فلسفوں کی سب سے واضح موجودہ مثال ہے۔

کوئی چیز اپنانے سے پہلے کیا جانچنا چاہیے

پہلی تنصیب کے بعد نہیں، بلکہ اس سے پہلے یہ چار سوال پوچھیں۔

1. کاپی رائٹ کس کے پاس ہے؟ دوبارہ لائسنس دینے کے لیے ہر کاپی رائٹ مالک کی اجازت درکار ہوتی ہے، اس لیے سینکڑوں آزاد contributors والے ایسے project کو، جس میں حقوق منتقل کرنے کا معاہدہ نہ ہو، حقیقتاً دوبارہ لائسنس نہیں کیا جا سکتا۔ جس project کی تمام ملکیت ایک کمپنی کے پاس ہو، اسے board meeting میں دوبارہ لائسنس کیا جا سکتا ہے۔
2. کیا CLA موجود ہے، اور یہ کیا اجازت دیتا ہے؟ ایسا contributor licence agreement جو کمپنی کو آپ کی contribution کو اپنی پسند کی کسی بھی شرائط کے تحت دوبارہ لائسنس کرنے کی اجازت دے، اوپر بیان کردہ ہر relicence کے پیچھے موجود عین طریقۂ کار ہے۔ DCO (developer certificate of origin)، یعنی وہ sign-off line جسے Linux kernel نے 2004 میں اپنایا، کوئی حق منتقل نہیں کرتا۔ کسی foundation کے پاس موجود CLA، کمپنی کے پاس موجود CLA سے زیادہ محفوظ ہوتا ہے، کیونکہ کمپنی فروخت کی جا سکتی ہے۔
3. ٹریڈ مارک کا مالک کون ہے؟ Elastic نے Elasticsearch کا نام اپنے پاس رکھا، اس لیے fork کو اپنا نام تبدیل کرنا پڑا، اور Kibana کا ذکر کرنے والے ہر runbook کو دوبارہ لکھنا پڑا۔
4. خاص طور پر آپ کو دوبارہ لائسنس دینے کی کیا قیمت ادا کرنا پڑے گی؟ data format، client libraries، وہ configuration جسے آپ دوبارہ لکھیں گے، اور یہ بھی شمار کریں کہ آیا پہلے سے کوئی compatible fork موجود ہے۔

دو commands چند seconds میں اس کا کچھ حصہ واضح کر دیتی ہیں۔

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

ہر Debian اور Ubuntu package میں /usr/share/doc/<package>/copyright پر ایک file موجود ہوتی ہے۔ اس میں آپ کے install کردہ version کا licence درج ہوتا ہے، نہ کہ وہ licence جسے project آج استعمال کرتا ہے۔ Ubuntu 24.04 میں bash کے لیے یہ file GNU General Public License version 3 کا نام درج کرتی ہے۔ دوسری command کو source checkout کے اندر چلانے سے خود licence file کی history مل جاتی ہے۔ اگر گزشتہ دو سال میں اس file پر کوئی commit ہوا ہو تو project پر کچھ بنانے سے پہلے اسے پڑھنا مفید ہے۔ اگر command کچھ بھی print نہ کرے تو repository نے اپنی licence file کا کوئی اور نام رکھا ہوا ہے؛ root directory کی فہرست بنائیں اور تلاش کریں۔

کوئی licence آپ کو ہر ممکن نتیجے سے محفوظ نہیں رکھتا، اور صرف نظریے کی بنیاد پر انتخاب کرنے سے لوگ عموماً حیران رہ جاتے ہیں۔ ایسے projects کو ترجیح دیں جن کا copyright بہت سے لوگوں میں تقسیم ہو یا کسی foundation کے پاس ہو، اور اپنا data ایسے format میں رکھیں جسے آپ export کر سکیں۔ پھر معلوم کریں کہ ضرورت پڑنے پر آپ کس fork میں منتقل ہوں گے، اور اس کا نام پہلے ہی لکھ لیں۔ ہر candidate پر یہ جانچ لاگو کرنے میں ایک گھنٹے سے کم وقت لگتا ہے، اور جب آپ یہ فیصلہ کر رہے ہوں کہ 2026 میں کیا self host کرنا ہے تو یہی upgrade اور migration کے درمیان فرق واضح کرتی ہے۔

FAQ

کیا MIT لائسنس، BSD لائسنس جیسا ہی ہے؟

عملاً MIT لائسنس، 2-clause BSD لائسنس سے مطابقت رکھتا ہے: copyright notice اور warranty disclaimer برقرار رکھیں، پھر اپنی مرضی کا استعمال کریں، جس میں closed product بنانا بھی شامل ہے۔ 3-clause BSD لائسنس ایک اضافی شرط رکھتا ہے: contributors کے نام ان کی اجازت کے بغیر اپنی product endorsement کے لیے استعمال نہ کریں۔ پرانے 4-clause ورژن میں advertising material میں acknowledgement بھی لازم تھا۔ UC Berkeley نے 22 July 1999 کو یہ clause واپس لے لیا، اس لیے آج کے تقریباً کسی بھی software میں یہ clause موجود نہیں ہوتا۔

کیا میں Apache 2.0 code کو GPLv2 project میں شامل کر سکتا ہوں؟

نہیں۔ Apache 2.0 ایسی شرائط شامل کرتا ہے جنہیں GPLv2 شامل کرنے کی اجازت نہیں دیتا، خاص طور پر patent termination clause۔ اس لیے combined work بیک وقت دونوں licenses کی شرائط پوری نہیں کر سکتا۔ FSF اور ASF دونوں یہی نتیجہ شائع کرتے ہیں۔ الٹی سمت میں یہ ممکن ہے: Apache 2.0 code کو GPLv3 project میں شامل کیا جا سکتا ہے، اور نتیجہ GPLv3 ہوگا۔ یہی وجہ ہے کہ Apache 2.0 code کو Linux kernel میں merge نہیں کیا جا سکتا، کیونکہ وہ صرف GPL version 2 کے تحت جاری ہوتا ہے۔

کیا SSPL ایک open source license ہے؟

نہیں، اور اس جواب کے عملی نتائج ہیں۔ OSI نے اسے کبھی approve نہیں کیا، اور MongoDB نے March 2019 میں اپنی application واپس لے لی۔ Debian نے December 2018 میں کہا کہ SSPL software اس کے archive میں شامل نہیں ہونا چاہیے۔ Fedora نے January 2019 میں فیصلہ دیا کہ یہ license free نہیں ہے۔ اس کے بعد Red Hat نے Fedora اور Red Hat Enterprise Linux سے MongoDB خارج کر دیا۔ آپ کے لیے اس کا مطلب یہ ہے کہ distribution جس package کو پہلے maintain کرتی تھی، وہ اب vendor repository سے آتا ہے اور vendor کے support timetable کے مطابق update ہوتا ہے۔ Business Source License بھی open source کے بجائے source available ہے، اگرچہ ہر release چار سال کے اندر ایک open source license میں تبدیل ہو جاتا ہے۔

کیا license کی تبدیلی اس version پر بھی لاگو ہوتی ہے جسے میں پہلے سے چلا رہا ہوں؟

نہیں۔ کسی release کے ساتھ دیا گیا license پہلے سے شائع شدہ copies سے واپس نہیں لیا جا سکتا۔ یہی وجہ ہے کہ forks ممکن ہوتے ہیں۔ OpenSearch، Elasticsearch 7.10.2 سے بنایا گیا تھا، جو آخری release تھا جسے Elastic نے Apache 2.0 کے تحت شائع کیا تھا۔ آپ جس چیز سے محروم ہوتے ہیں وہ مستقبل ہے، کیونکہ اگلا security fix نئی شرائط کے تحت آتا ہے۔ آخری permissively licensed version کو pin کرنے سے چند ماہ کا وقت مل سکتا ہے، لیکن یہ مستقل منصوبہ نہیں ہے۔