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

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

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

یہ معاملہ اس وقت تک 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 code ایسی licence کے تحت جاری کیا جس میں copyright notice برقرار رکھنے کا تقاضا تھا اور ہر قسم کی warranty سے دست برداری شامل تھی۔ اصل version میں چار clauses تھے۔ تیسرا clause، یعنی advertising clause، software کی features کا ذکر کرنے والے تمام advertising material میں University کا acknowledgement لازمی قرار دیتا تھا۔ یہ طریقہ بڑے پیمانے پر قابلِ عمل نہیں تھا۔ Stallman نے NetBSD کے 1997 version میں 75 الگ acknowledgements شمار کیے۔ UC Berkeley نے اپنے Office of Technology Licensing کے William Hoskins کے خط کے ذریعے 22 July 1999 کو یہ clause ختم کر دیا۔

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

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

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

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 کو third parties کے لیے service کے طور پر پیش کرتے ہیں تو آپ کو اسے پیش کرنے کے لیے استعمال ہونے والی ہر چیز کا source publish کرنا ہوگا، جس میں اس کے گرد موجود management اور orchestration software بھی شامل ہے۔ اس obligation کی واضح حد نہیں ہے، اور کسی court نے ابھی اس کی تشریح نہیں کی۔ OSI نے اس licence کو کبھی approve نہیں کیا، اور MongoDB نے March 2019 میں اپنی application واپس لے لی۔ Debian پہلے ہی December 2018 میں کہہ چکا تھا کہ SSPL software اس کے archive میں شامل نہیں ہونا چاہیے، اور Fedora نے January 2019 میں فیصلہ کیا کہ یہ licence free نہیں ہے۔ اس کے بعد Red Hat نے MongoDB کو Fedora اور Red Hat Enterprise Linux دونوں سے ہٹا دیا۔ Relicence کا عملی نتیجہ یہی ہوتا ہے: distribution software کی packaging بند کر دیتی ہے، اس لیے اب آپ کی upgrades vendor کے repository سے اور vendor کے schedule کے مطابق آتی ہیں۔

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

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

OpenSearch: operator کے لیے licence 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 بن گیا۔

اس کے بعد یہ معاملہ مزید دو بار بدلا۔ Elastic نے 29 August 2024 کو اعلان کیا کہ وہ AGPLv3 کو تیسرے licence option کے طور پر شامل کرے گا، اور اس کی licensing FAQ میں اس اضافے کو September 2024 میں رکھا گیا ہے؛ اس لیے موجودہ Elasticsearch دوبارہ OSI-approved open source ہے۔ 16 September 2024 کو AWS نے OpenSearch کو OpenSearch Software Foundation کے حوالے کر دیا۔ یہ foundation Linux Foundation کے زیرِ میزبانی ہے، اور اس سے fork کو ایسی governance home ملی جو کسی ایک company تک محدود نہیں۔ تقسیم کے پانچ سال بعد دونوں projects open source ہیں، دونوں maintain کیے جا رہے ہیں، اور October 2026 تک OpenSearch اپنی 3.x series میں ہے۔

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

یہ فرق طے کرتا ہے کہ relicence سے کتنا نقصان ہوگا: vendor کے public 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 اور معاوضہ لینے والے 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 کرنے سے چند ماہ کا وقت مل سکتا ہے، لیکن یہ مستقل منصوبہ نہیں ہے۔