PHP 项目多年来在许可证问题上一直属于“历史包袱”较重的项目，如今正准备进行一次重要而彻底的清理：由社区成员 Ben Ramsey 牵头的提案，计划废弃当前使用的两套自定义许可证——覆盖大部分代码的 PHP License 3.01 以及用于 Zend 目录代码的 Zend License 2.0——转而在未来版本中统一采用 BSD 三条款（Modified BSD）许可证。目前，PHP 社区正在就这一“PHP 许可证更新”RFC 进行投票，投票将持续到 2026 年 4 月 4 日。
在 PHP 的早期发展阶段，项目在许可证上的变更频率颇高：自 1995 年到 2006 年间，PHP 共进行了七次许可证变更或条款调整。最初，PHP 是在 GPLv2 下发布的；1998 年发布的 PHP 3 则采用了 GPLv2 与新 PHP License 的双重授权方式，这一新许可证以 Apache License 1.0 为基础，由 PHP 创始人 Rasmus Lerdorf 制定，目的是让 PHP 对商业用户更“友好”，同时仍保持自由软件属性。Lerdorf 当时表示，希望在确保 PHP 始终免费的前提下，让商业公司可以在不让主要贡献者感觉“被占便宜”的条件下尝试商业化版本。
不过，最初版本的自定义 PHP 许可证包含一条需要获得 PHP 开发团队书面许可才能进行商业再分发的条款，这在实践中被证明难以操作，最终在 PHP 3.0.14 版本中被删除。该版本附带的 LICENSE 文件甚至没有标明许可证版本号。
2000 年 5 月发布的 PHP 4.0 是一次重大重构，引入了由 Zeev Suraski 和 Andi Gutmans 编写的 Zend 引擎，这两人随后创办了 Zend Technologies，希望在独立于 PHP 的路径上商业化 Zend 引擎。Zend 向 PHP 项目提供授权，使其可以将 Zend 引擎集成进 PHP，并承诺相关代码将保持在 Zend 许可证或符合开源定义（OSD）的其他许可证之下，尽管 Zend License 本身并未获得开源促进会（OSI）正式批准。此后，PHP 源码树中 Zend 目录下的代码便采用 Zend 许可证；PHP 4.0 同时完全放弃了 GPLv2，转而采用 PHP License 2.02。
在随后的几年中，PHP License 继续被微调：PHP 3.0 版本的许可证曾获得 OSI 批准，但之后又做了一次小幅修改，形成了 PHP License 3.01。该次修改仅调整了版权年份以及对 PHP 和 Zend 致谢文字的表述方式，并未改变授权权利本身。然而，这个新版本从未再经过 OSI 审核。更麻烦的是，许可证文本表面上只适用于由“PHP Group”发布的软件，而这一“PHP Group”本身并非实际的法律实体，而是十名早期 PHP 开发者的列表。这一模糊性让部分人认为，其他主体发布的软件并不能合法地采用 PHP License 作为授权文本，从而对如 Debian 等项目造成了实际困扰。Ramsey 在 RFC 中专门梳理了这段历史背景。
在当前的 RFC 中，Ramsey 提出，自下一个主要版本起（最初写的是 PHP 9.0，后更新为“下一版本的 PHP”），用 BSD 三条款许可证统一替换目前的 PHP License 和 Zend License。他表示，在撰写这一提案时，自己已与 OSI 许可证委员会主席 Pamela Chestek 合作，处理相关法律问题与疑问。
Ramsey 称，他已经与所有 PHP Group 成员沟通过，每位成员都已表示支持这一变更。同时，他还获得了 Perforce Software 的许可——Perforce 于 2019 年通过收购 Rogue Wave 将 Zend 纳入旗下，而 Rogue Wave 在 2015 年收购了 Zend。有人可能会疑问：既然多年来有如此众多个人向 PHP 提交代码，是否需要每一位贡献者都同意才能更改许可证？在 RFC 中，Ramsey 的观点是：不需要。PHP 并未要求贡献者签署将版权转移给项目的 CLA，因此贡献者保留其贡献代码的版权；但在他们未明确声明其他授权条款的前提下，可以视为他们以项目当前的许可证向项目授予使用其贡献的权利。
换言之，贡献者对自己所提交代码享有版权，但在未指定其他许可证的情况下，其贡献是按项目所采用的许可证授权给项目使用的。Ramsey 进一步指出，通常在变更开源项目许可证时，需要取得所有版权方的同意，因为新许可证可能会改变授予用户的权利范围。但在此案例中，改用 BSD 三条款许可证并不会改变除 PHP Group 和 Perforce Software 外其他贡献者所授予的权利。因此，他认为项目并不需要逐一征求所有贡献者的明确许可。
尽管 RFC 指出从法律上并不强制要求逐一征得同意，但出于“礼貌”考虑，Ramsey 提议将讨论期至少维持六个月，以确保所有利益相关方有充分机会表达意见。自 2025 年 7 月提出 RFC 以来，他多次发布更新并提醒社区该议题仍在讨论中；截至目前，尚未出现实质性反对意见。
讨论中也出现了一些具体问题。例如，Derick Rethans 询问为何必须等到 PHP 9，而不是在 8.5 之后的“下一版本”就进行变更。Ramsey 回应称，这并无技术或法律上的硬性理由，只是出于版本节奏的直觉判断，如果社区认为在 PHP 8.6 中完成变更更合适，他也不反对。此后，RFC 便将实施时间从“PHP 9”调整为“下一版本”。
另一位开发者 Peter Kokot 则建议，应对与 GPL 的兼容性进行更清晰的说明，以便在未来与 GPL 授权软件协同时减少疑虑。他指出，PHP 在构建时可以选择链接两个 GPLv3 许可证的库：GNU Readline 和 GNU dbm (GDBM)。他希望逐步废弃在构建阶段链接这些 GPL 库的选项，以便让打包者不再为潜在的不兼容问题担忧，最终彻底移除对 GDBM 和 Readline 的链接可能性。Ramsey 回应称，在现有 PHP License 3.01 下，由于对用户附加了一些额外限制，该许可证与 GPL 不兼容，这种不兼容目前无法消除；然而若改用 Modified BSD 许可证，只要最终组合包整体以 GPL 条款发布，就不存在此类兼容性问题，这也将显著简化发行版打包工作。
2026 年 3 月 14 日，Ramsey 宣布对该 RFC 正式开启投票。投票结果以公开方式记录在 PHP Wiki 的 RFC 页面上。目前尚不确定拥有投票权的总人数——2019 年统计显示当时共有 180 名具有投票资格的开发者。投票开始后不久，已有 47 人投下赞成票，2 人选择弃权。从早期结果看，社区对该提议的态度高度正面，但在投票程序结束前，结果仍不能视为板上钉钉。无论最终结果如何，这次许可证清理和简化工作显然离不开 Ramsey 过去数年在幕后进行的沟通、协调与推进。