「PHP License 3.01 已自愿退役，不再用于新项目。」——项目维护者 Ben Ramsey 的这句话，标志着一个时代的终结。
30 年前，PHP 刚诞生时为自己量身定制了一套许可证。如今，这个运行着全球近八成网站的编程语言，终于决定放弃"特殊待遇"，全面转向 BSD 3-Clause 标准许可证。这不是简单的法律文本替换，而是一次关于开源项目如何与生态共生的关键选择。
1995：一场"量身定制"的开端
PHP License 的历史几乎与 PHP 语言本身一样长。1995 年发布的首版许可证，专门为 PHP 语言制定，核心条款之一是对"PHP"名称的使用限制——任何衍生项目都不能随意使用这个名字。
这一限制在当时或许是为了保护品牌，却埋下了长期的兼容性隐患。自由软件基金会（FSF）将其归类为与 GPL 不兼容的自由软件许可协议。这意味着，GPL 项目无法直接整合 PHP 代码，Linux 发行版打包 PHP 时需要额外处理法律合规问题。
更复杂的是，PHP 的核心执行引擎 Zend 长期单独使用另一套许可证。两套许可证并行，且都未经开源促进会（OSI）正式批准，让下游开发者疲于应对。
2024：提案背后的真实痛点
变更的导火索来自去年的社区提案。推动者没有掩饰动机：标准宽松许可证能替换掉这套"自定义"体系。
具体痛点很实在。PHP License 3.0 和 3.01 的全部退役，意味着新项目从此告别 PHP 特定的命名限制。Zend 引擎也被纳入同一框架，新命名为 PHP License version 4 和 Zend Engine License version 3——名称上的版本号跳跃，对应的是管理逻辑的彻底统一。
对于 Linux 发行版维护者来说，这是减负。对于嵌入或再分发 PHP 代码的商业项目，这是消除歧义。对于整个开源工具链，BSD 3-Clause 的广泛认可意味着更成熟的合规扫描、更清晰的兼容性判断。
BSD 3-Clause：为什么是这张"通行证"
选择 BSD 3-Clause 而非 GPL 或 Apache-2.0，本身就有产品逻辑。
BSD 3-Clause 是开源世界最宽松的许可证之一：允许自由使用、修改、分发，包括商业闭源场景；只保留三条核心约束——保留版权声明、免责声明、不得用原作者名义背书。这种"几乎不管"的风格，与 PHP 长期以来的实用主义气质高度吻合。
对比之下，原 PHP License 的命名限制是一种"过度设计"——它试图用法律手段保护品牌，却制造了生态摩擦。BSD 3-Clause 放弃这种控制，换取的是更广泛的采用和更少的法律审查成本。
新许可证同时解决了 Zend 引擎的 OSI 批准问题。此前 Zend 许可证未经 OSI 认证，在一些企业合规流程中需要额外解释。现在，整个 PHP 技术栈共享同一张"标准通行证"。
给技术选型的启示
PHP 的这次转向，验证了一个被反复讨论的趋势：自定义许可证的性价比正在崩塌。
30 年前，为项目定制许可证是常见做法——既彰显独特性，又能嵌入特定保护条款。但在今天，标准许可证的生态价值远超"量身定制"的控制感。工具链支持、法律审查成本、跨项目兼容性，这些隐性成本在规模化场景下会急剧放大。
对于正在做技术选型的团队，这是一个可操作的判断依据：优先选择采用标准 OSI 批准许可证的项目，合规成本更低，长期风险更可控。PHP 用 30 年走完的弯路，没必要再重复。
热门跟贴