PHP के लिए लाइसेंस को BSD 3-Clause में बदलने का प्रस्ताव

• PHP प्रोजेक्ट वर्तमान जटिल और असंगत PHP-विशिष्ट लाइसेंस तथा Zend Engine लाइसेंस को BSD 3-Clause (Modified BSD License) में एकीकृत करने वाले RFC पर चर्चा कर रहा है
• नया लाइसेंस PHP 9.0 से लागू करने का प्रस्ताव है, और source code, headers तथा documentation में BSD 3-Clause को अपनाया जाएगा; पुराने विशेष प्रावधान और brand-संबंधी प्रतिबंध हट जाएंगे
• OSI और FSF की स्वीकृति, GPL compatibility आदि के जरिए कानूनी स्पष्टता सुनिश्चित होगी, और contributors व users के अधिकार पहले जैसे ही रहेंगे
• लाइसेंस बदलाव के लिए PHP Group और Perforce Software (पूर्व Zend) की औपचारिक सहमति जरूरी है, और community discussion के बाद 6 महीने से अधिक की चर्चा व voting process चलेगी
• यह बदलाव PECL/extensions जैसे बाहरी प्रोजेक्ट्स में भी BSD 3-Clause चुनने की सिफारिश करता है, और “PHP License” के उपयोग की सिफारिश नहीं करता

---

अवलोकन

• PHP प्रोजेक्ट में लंबे समय से अपने अलग open source license और Zend Engine License की वजह से उलझन और विवाद बने हुए थे
• खास तौर पर Zend directory के source पर लागू Zend Engine License OSI-approved license नहीं है, इसलिए जटिलता बढ़ती है
• यह RFC सभी PHP contributors के copyright को सुरक्षित रखते हुए users को मौजूदा लाइसेंस जैसे ही अधिकार देने वाला व्यावहारिक license simplification प्रस्तावित करता है
• BSD 3-Clause (Modified BSD License) को नए official license के रूप में अपनाकर, अधिकार और उपयोग शर्तें बरकरार रखते हुए जटिलता और गलतफहमी कम करना इसका लक्ष्य है

प्रस्ताव और प्रमुख परिवर्तन

• प्रस्ताव का मूल यह है कि PHP License और Zend Engine License के नए versions जारी कर Modified BSD License (BSD-3-Clause, OSI/FSF दोनों से approved) को औपचारिक रूप से अपनाया जाए
• मौजूदा PHP License (version 3.01) और Zend Engine License (version 2.00) विशेष clauses को छोड़कर लगभग Modified BSD जैसे ही हैं, इसलिए अधिकारों में मूलभूत बदलाव नहीं होगा
• लाइसेंस अपडेट के बाद:
  • contributors और users को दिए जाने वाले अधिकारों में कोई बदलाव नहीं होगा
  • PHP Group और Perforce Software के साथ मिलकर विशिष्ट समूह-आधारित clauses हटाए जाएंगे
  • PHP और Zend Engine, OSI-approved और GPL-compatible license के तहत उपलब्ध होंगे
• पुराने PHP License और Zend Engine License का उपयोग अब अनुशंसित नहीं होगा
• LICENSE और source में license headers भी नए format से बदले जाएंगे

लाइसेंस के पूर्ण पाठ का सारांश

• BSD 3-Clause के तहत copy, modify और distribute करना स्वतंत्र है, लेकिन copyright notice, disclaimer और नाम/brand के अनधिकृत उपयोग पर रोक जैसी शर्तें शामिल हैं
• BSD-3-Clause एक OSI (Open Source Initiative) और FSF दोनों द्वारा स्वीकृत free software license है और GPL-compatible भी है

परिवर्तन प्रक्रिया और स्वीकृति

• RFC community में सार्वजनिक चर्चा के बाद voting से तय होगा, और औपचारिक सहमति व मतदान के बाद लागू किया जाएगा
• लाइसेंस परिवर्तन के लिए PHP Group और Perforce Software की आधिकारिक सहमति आवश्यक है
• पुराने source code contributors के अधिकार यथावत रहेंगे, और यह बदलाव मौजूदा अधिकारों का उल्लंघन नहीं करता
• community को 6 महीने से अधिक की चर्चा अवधि देने के बाद मतदान से अंतिम निर्णय होगा
• यह बदलाव PHP 9.0 में आधिकारिक रूप से शामिल किया जाएगा

पृष्ठभूमि और ऐतिहासिक संदर्भ

• शुरुआती PHP 1 और 2, GPL के तहत थे; बाद में Apache license और custom BSD-आधारित licenses से गुजरते हुए प्रोजेक्ट विकसित हुआ
• Zend Engine ने अलग license बनाए रखा, लेकिन अब इसे व्यवहारिक रूप से अलग न किए जा सकने वाले एक ही प्रोजेक्ट का हिस्सा माना जाता है
• पुराने PHP license में नाम के उपयोग पर प्रतिबंध और brand protection clauses जैसी चीजों ने दूसरे open source software के साथ compatibility और distribution में लगातार समस्याएँ पैदा कीं

मौजूदा कोड, extensions, दस्तावेज़ों पर प्रभाव

• यह RFC पूरे php-src पर लागू होगा (उन codebases को छोड़कर जिन पर अलग license स्पष्ट रूप से लागू है), और PECL/extensions आदि में भी BSD 3-Clause अपनाने की सिफारिश करता है
• नए और मौजूदा PHP source repos में PHP License या Zend Engine License के तहत आने वाले पूरे code पर इसका असर होगा
• मौजूदा लाइसेंस (z.B. timelib जैसे अलग licensed code) इस बदलाव के दायरे में नहीं आएंगे
• PHP manual आगे भी Creative Commons Attribution 3.0 या उससे ऊपर के license के तहत ही रहेगा
• मौजूदा extension modules/software को PHP License v4 (Modified BSD) अपनाने का विकल्प दिया जाएगा
• भविष्य के extensions और नए projects के लिए नवीनतम BSD/Apache जैसे मान्य licenses के उपयोग की सिफारिश की जाती है

निष्कर्ष

• PHP और Zend Engine की license संरचना 3-clause BSD में सरल होने से open source ecosystem में स्पष्टता, compatibility, commercial use और legal stability बढ़ने की संभावना है
• यदि यह प्रस्ताव स्वीकृत और लागू होता है, तो users BSD-3-Clause के आधार पर PHP और Zend Engine का स्वतंत्र रूप से उपयोग कर सकेंगे
• contributors, community और प्रमुख कंपनियों की सहमति व voting process पूरी होने के बाद इसे आधिकारिक रूप से लागू किया जाएगा

[GN⁺]

Hacker News की राय

• यह बताया गया कि Meta जिस भाषा का उपयोग करता है वह PHP नहीं बल्कि Hack है, लेकिन Hack की पैकेजिंग, डोक्युमेंटेशन और उपलब्धता अच्छी नहीं है; कारण यह बताया गया कि वह Meta के भीतर दिखाई देने वाला काम नहीं है इसलिए परफॉर्मेंस रिव्यू में नहीं गिना जाता, साथ ही यह भी इंगित किया गया कि आंतरिक ज्ञान को छिपाकर रखना नौकरी की सुरक्षा से जुड़ जाता है। लाइसेंस के संदर्भ में यह भी कहा गया कि Meta, Google, Microsoft, Apple जैसी बड़ी IT कंपनियां AGPL सॉफ्टवेयर के उपयोग पर सख्ती से रोक लगाती हैं, क्योंकि AGPL की “Remote Network Interaction” धारा की अस्पष्टता के कारण वे कानूनी जोखिम नहीं लेना चाहतीं। साथ में यह सुझाव भी दिया गया कि अगर आप चाहते हैं कि बड़ी कंपनियां या सामान्य व्यवसाय आपके कोड का बिल्कुल उपयोग न कर सकें, तो AGPL चुनें। संदर्भ: Google की AGPL नीति दस्तावेज़
  • इस बात पर जोर दिया गया कि कई कंपनियां वास्तव में AGPL सॉफ्टवेयर (जैसे Grafana, Mastodon, Mattermost आदि) का आंतरिक रूप से उपयोग करती हैं, हालांकि बाहरी भुगतान करने वाले ग्राहकों के लिए सेवाओं में इसका उपयोग कम होता है। एक डेवलपर के रूप में, मैंने कहा कि मुझे बड़ी कंपनियों की अत्यधिक चिंताओं से अधिक अपने सॉफ्टवेयर के उपयोगकर्ताओं की स्वतंत्रता की चिंता है।
  • यह बताया गया कि AGPL का प्रभाव ‘सभी व्यवसायों’ पर नहीं, बल्कि केवल ‘उन कंपनियों’ पर पड़ता है जो मेरे सॉफ्टवेयर के साथ proprietary network service चलाती हैं; यही AGPL का मूल उद्देश्य है। यह भी समझाया गया कि Google की नीति में भी इसी वजह से network provider होने का आधार स्पष्ट रूप से लिखा है। अधिकांश गैर-तकनीकी कंपनियों पर इसका कोई प्रभाव नहीं पड़ता और उन्हें इसकी चिंता करने की ज़रूरत नहीं है।
  • यदि आप एक open source startup हैं, तो AWS जैसे mega-cloud द्वारा दब जाने से बचने के लिए AGPL + commercial dual license (IP transfer CLA सहित) की सिफारिश की गई।
  • यह समझाया गया कि कई बड़ी कंपनियां AGPL सॉफ्टवेयर इसलिए उपयोग करती हैं क्योंकि dual licensing संभव होती है; यानी AGPL के ज़रिए open source होने का प्रचार किया जा सकता है, और commercial license के तहत उपयोग करने पर ग्राहक कंपनियों से शुल्क लिया जा सकता है।
  • यह धारणा व्यक्त की गई कि हाल के दिनों में Go का काफी उपयोग हो रहा है, और ऐसा लगा कि कई पैकेज Go में फिर से लिखे गए हैं।
• PHP लाइसेंस और उसके इतिहास से जुड़ी सामग्री एक ही जगह पर, बिना मार्केटिंग या AI-जनित सामग्री के, सुव्यवस्थित रूप में दी गई है—यह बहुत अच्छा लगा।
  • यह मज़ेदार टिप्पणी भी जोड़ी गई कि AI-जनित कंटेंट वास्तव में कोई अतिरिक्त जानकारी नहीं देता; बेकार की बातें तो पहले से मौजूद थीं, इसलिए इसमें मूलतः कुछ नया नहीं है।
• 25 साल पहले जब मैंने सीधे PHP Zend Engine का source code पढ़ा था, तब जीवन में पहली बार triple pointer (zval***) देखा था। उसके बाद मैंने PHP से बहुत तरह के काम किए, और हाई स्कूल के समय प्रोग्रामिंग प्रतियोगिता में भी CLI environment में PHP का उपयोग करके भाग लिया था, लेकिन उस समय स्टाफ उस भाषा और environment से परिचित नहीं था इसलिए बाहर होना पड़ा—एक साथ मज़ेदार और दुखद अनुभव। उस समय PHP ने जो संभावनाएं दीं, उसके लिए आभार व्यक्त किया गया।
  • इस कहानी को दिलचस्प बताया गया, और जवाब में किसी ने अपना graduation project Perl में करने का अनुभव साझा किया।
  • triple “naked” pointer को तार्किक रूप से स्वीकार करना कठिन बताया गया। performance से पहले ही implicit indirection की जटिलता को समझाना मुश्किल है; उदाहरण के लिए struct member जैसी स्पष्ट चीज़ समझी जा सकती है, लेकिन यूं ही अतिरिक्त जटिलता जोड़ना तर्कसंगत नहीं लगता। इसी संदर्भ में एक परिचित का अक्सर कहा गया वाक्य याद किया गया: “यह simple क्यों नहीं है?”
• यह चिंता जताई गई कि यदि सभी contributors की सहमति न ली जाए, तो कोई दुर्भावनापूर्ण contributor समस्या खड़ी कर सकता है। अमेरिका जैसे स्थानों में केवल परेशान करने के लिए मुकदमे दायर किए जा सकते हैं, और हर किसी को अपनी जेब से जवाब देना पड़ता है; नतीजतन कानूनी बचाव को लेकर अत्यधिक सतर्क संस्कृति बन जाती है। साथ में Richard Stallman, PHP के GPL उपयोग, और उसके कारण dual licensing रुक जाने की पुरानी घटना का भी उल्लेख किया गया।
  • यह समझाया गया कि PHP Group, “or later” clause की वजह से, अलग से contributors की सहमति लिए बिना लाइसेंस को संशोधित कर नई version जारी कर सकता है।
  • यह इंगित किया गया कि Stallman से जुड़ा जिस लाइसेंस प्रसंग का उल्लेख हुआ, वह वास्तव में MySQL के GPL में जाने और उसके PHP लाइसेंस पर पड़े प्रभाव से अधिक संबंधित है; यह बात समझ में नहीं आती कि केवल Stallman की नापसंदगी के कारण GPL छोड़ने का कोई कारण बनता हो।
• संबंधित पृष्ठभूमि PHP wiki के license change background दस्तावेज़ में देखी जा सकती है।
• यदि आप software license और उनके संशोधन के बारे में विशेषज्ञ स्तर की समझ बनाना चाहते हैं, तो यह अवश्य पढ़ने लायक पेज है। साथ ही यह भी रेखांकित किया गया कि इस बार का license change ऐसा समाचार है जो हमसे कोई बदलाव या re-certification नहीं मांगता; contributors और users दोनों पर इसका कोई प्रभाव नहीं है।
  • इस पर हल्के-फुल्के अंदाज़ में यथार्थवादी सावधानी जताई गई कि “बिना बड़े बदलाव के आगे बढ़ रहा है” जैसी खबरें कभी-कभी 787MAX और MCAS जैसी भारी घटनाओं के साथ भी आई थीं।
  • वास्तव में क्या बदला है, इसे विस्तार से समझाया गया: PHP/Zend trademark से जुड़ी पंक्तियां हटाई जा रही हैं, और दोनों projects को एक ही license में एकीकृत किया जा रहा है। यानी पहले “PHP”, “Zend”, “Zend Engine” नामों के उपयोग के लिए अलग-अलग अनुमतियां चाहिए थीं, अब copyright holder और contributors के नामों पर एक समान नियम लागू होगा। साथ ही attribution, revision, certification, notification से जुड़ी धाराएं (4~6) भी हटाई जा रही हैं।
• यह सवाल उठाया गया कि license दस्तावेज़ों में महत्वपूर्ण हिस्से पूरे बड़े अक्षरों (ALL CAPS) में क्यों लिखे जाते हैं।
  • यह समझाया गया कि अमेरिकी कानून में warranty/liability disclaimer को “conspicuous” यानी स्पष्ट रूप से दिखने वाला होना चाहिए, और सामान्य पाठ में इसे दिखाने का सबसे आसान तरीका ALL CAPS है।
  • यह भी कहा गया कि यह upper/lower case विवाद को ही खत्म करने का तरीका है; अगर सारे शब्द बड़े अक्षरों में हों, तो सब कुछ emphasized माना जाता है और भ्रम कम होता है।
  • commercial law (UCC) प्रावधानों के अनुसार, उसे इस तरह लिखा होना चाहिए कि कोई भी समझदार व्यक्ति उसे अवश्य नोटिस करे; ऐसा करने का एक तरीका यह है कि heading बड़े अक्षरों में हो। इसलिए पूरे हिस्से को ALL CAPS में लिखने पर अदालत भी उसे पर्याप्त रूप से ‘दिखाई देने वाला’ मान सकती है।
• किसी जानकार व्यक्ति से ELI5 स्तर पर बदलाव समझाने का अनुरोध किया गया, और पूछा गया कि क्या पूरे PHP का लाइसेंस बदल रहा है।
  • जवाब में पूछा गया कि “पूरा PHP” से ठीक क्या मतलब है, और समझाया गया कि यह बदलाव भाषा स्वयं—यानी interpreter, runtime, और standard library—पर लागू होता है।
• यह पूछा गया कि MIT license कहीं अधिक सरल है, तो फिर उसका उपयोग क्यों नहीं किया गया।
  • इसके जवाब में प्रतिप्रश्न किया गया कि क्या MIT और BSD-3-Clause के बीच का अंतर वास्तव में इतना सरल है कि व्यावहारिक रूप से महसूस किया जा सके, और MIT license तथा BSD-3-Clause license के बीच कोई अर्थपूर्ण अंतर है भी या नहीं।