PHP 许可证变更即将生效

# PHP 许可证变更即将启动 来源：https://lwn.net/Articles/1063993/ > **请考虑订阅 LWN** 订阅是 LWN.net 的生命线。如果您欣赏这些内容并希望看到更多，您的订阅将有助于确保 LWN 持续繁荣。请访问[此页面](https://lwn.net/Promo/nst-nag1/subscribe)加入订阅，让 LWN 继续在网络上存在。 PHP 的许可证问题长期以来一直令人困惑。该项目目前使用两种许可证覆盖代码库的不同部分：[PHP v3.01](https://spdx.org/licenses/PHP-3.01.html) 覆盖大部分代码，[Zend v2.0](https://spdx.org/licenses/Zend-2.0.html) 覆盖 `Zend` 目录中的代码。自 2006 年项目确定这些许可证以来，情况已发生很大变化，对自定义许可证的需求似乎已经过去。由 Ben Ramsey 牵头的简化 PHP 许可证的工作正在进行中；如果成功，现有许可证将被弃用，取而代之的是 [BSD 三条款](https://spdx.org/licenses/BSD-3-Clause.html)许可证。PHP 社区目前正在就[许可证更新 RFC](https://wiki.php.net/rfc/php_license_update#php_rfcphp_license_update) 进行投票，截止日期为 2026 年 4 月 4 日。 在早期，PHP 项目[频繁变更许可证](https://wiki.php.net/rfc/php_license_update#license_changelog)：1995 年至 2006 年间，PHP 共七次变更许可证或修改其自定义许可证条款。最初，PHP 在 GPLv2 下发布。随后于 1998 年发布的 [PHP 3](https://www.php.net/manual/php3.php) 采用了双许可证方案；可在 GPLv2 和基于 [Apache License 1.0](https://spdx.org/licenses/Apache-1.0.html) 的新 PHP License 下使用。这是 PHP 创始人 Rasmus Lerdorf 为了让 PHP [对商业利益更具吸引力](https://marc.info/?l=php-internals&m=90279104404344)而做出的选择： > PHP2 在过去一年里吸引了不少商业实体的兴趣。GPL 加上我自己的固执扼杀了大 部分机会。如果可以的话，PHP 将永远是免费的。但我并不反对让商业实体尝试商业版本，只要条款不会让主要贡献者感到被欺骗。 然而，第一版自定义许可证包含一项条款，要求商业再分发必须获得 PHP 开发团队的书面许可。这[被证明不可行](https://marc.info/?l=php-internals&m=93061480325614&w=2)，因此该条款在 PHP 3.0.14 发布时被[删除](https://marc.info/?l=php-internals&m=94761825330057&w=2)。该版本中的 LICENSE 文件没有版本号。 2000 年 5 月发布的 [PHP 4.0](https://www.php.net/ChangeLog-4.php#4.0.0) 是一次重大改版；它包含了 [Zend Engine](https://en.wikipedia.org/wiki/Zend_Engine)，当时被描述为 PHP 脚本引擎的完全重写，由 Zeev Suraski 和 Andi Gutmans 编写。两人成立了 [Zend Technologies](https://en.wikipedia.org/wiki/Zend_%28company%29) 公司，试图将 Zend Engine 与 PHP 分开商业化；该公司提供了一项[授权](https://www.php.net/license/ZendGrant/index.php)，允许 Zend Engine 集成到 PHP 中，并保证它将始终处于 Zend 许可证或符合 [Open Source Definition](https://opensource.org/osd)（OSD）的其他许可证之下，该定义来自 [Open Source Initiative](https://opensource.org/)（OSI），尽管 Zend 许可证本身并未获得 OSI 批准。因此，PHP 项目在其源代码树的 [`Zend`](https://github.com/php/php-src/tree/master/Zend) 目录中采用了 Zend 许可证。PHP 4.0 还完全放弃了 GPLv2，转而采用 PHP License version 2.02。 PHP 的许可证后来又更新了几次；PHP 3.0 许可证获得了 OSI 批准，但该许可证收到了[一小组最终修改](https://gist.github.com/ramsey/ee9629175059d516c05d01d5051fa626)，将其推至 3.01 版本。这些修改仅更改了版权年份，并重新表述了 PHP 和 Zend 致谢的措辞方式，并未以任何方式影响授予的权利。此次变更的原因已[湮没在历史中](https://news-web.php.net/php.internals/108840)，但该版本从未获得 OSI 批准。许可证文本已被证明存在问题，因为它似乎仅适用于由"PHP Group"（https://www.php.net/credits.php）发布的软件。令人困惑的是，PHP Group [似乎并非实际的法律实体](https://externals.io/message/107098#107102)，而是早期参与 PHP 开发的十人名单。有人认为，PHP Group 以外的各方无法将其作为有效许可证使用。这给其他项目带来了麻烦，[比如 Debian](https://lwn.net/Articles/604630/)。Ramsey 在 RFC 中[详细梳理](https://wiki.php.net/rfc/php_license_update#historical_context)了 PHP 许可证的历史，供希望了解更多细节的读者参考。 #### 提案 Ramsey 于 2025 年 7 月就 RFC [开启讨论](https://discourse.thephp.foundation/t/php-dev-rfc-updating-the-php-license/2024/1)；他提议从下一个主要版本 PHP 9.0 开始，将现有两种许可证替换为三条款 BSD 许可证。他为这项工作聘请了专家；他表示正在与 OSI 许可证委员会主席 Pamela Chestek 合作处理法律问题和疑虑。 他表示已经与 PHP Group 的所有成员沟通过，每位成员都已表示同意变更。他还获得了 Perforce Software 的批准，该公司于 2019 年[收购](https://sdtimes.com/devops/perforce-expands-devops-portfolio-with-rogue-wave-acquisition/)了 Zend，作为 Rogue Wave Software 旗下资产的一部分（Rogue Wave Software 本身于 2015 年收购了 Zend）。有人可能会想，多年来向 PHP 提交代码的所有个人贡献者怎么办：他们不是也必须批准许可证变更吗？在 RFC 中，Ramsey 认为并非如此。PHP 从未要求贡献者签署贡献者许可协议（CLA）将版权转让给项目，也不存在向项目的默示版权转让。然而，存在默示的许可证*授予*： > 当有人为开源项目做出贡献时，他们拥有其贡献的版权，但除非他们为其贡献指定了不同的许可证（这完全有效，例子包括 Derick Rethans 的 timelib，它捆绑在 PHP 源代码中），否则默示他们正在按照项目相同的许可证条款授予其贡献的使用权。[...] 通常，更改开源项目的许可证时，必须获得所有版权所有者的批准，因为新许可证条款下授予的权利可能会发生变化。然而，如本节和本文档其他部分所述，改为 Modified BSD License 不会改变非 PHP Group 或 Perforce Software 的贡献者所授予的任何权利。 尽管 RFC 声称项目不需要许可，但它表示讨论将至少开放六个月，"出于礼貌"以确保利益相关方有机会回应。自 7 月 RFC 宣布以来，Ramsey [提供了更新并提醒人们](https://discourse.thephp.foundation/t/php-dev-rfc-updating-the-php-license/2024/16)该话题仍在讨论中；到目前为止，似乎没有人反对。 当然，有一些人提出了问题。Rethans [质疑](https://discourse.thephp.foundation/t/php-dev-rfc-updating-the-php-license/2024/6)"为什么要等到（ specifically ）PHP 9，而不是 PHP-next（8.5 之后的版本）？" Ramsey [表示](https://discourse.thephp.foundation/t/php-dev-rfc-updating-the-php-license/2024/7)没有技术或法律原因；只是 PHP 9 发布似乎是进行变更的合适时机。如果其他人认为 8.6 是合适的时机，那也可以。RFC 后来更新为将提案改为 PHP 的"下一个版本"。 Peter Kokot [建议](https://discourse.thephp.foundation/t/php-dev-rfc-updating-the-php-license/2024/4)应该"稍微澄清一下 GPL 兼容性，以便将来在涉及 GPL 许可软件时简化 PHP 的使用"。他指出，PHP 可以选择链接到两个使用 GPLv3 的库：[GNU Readline Library](https://tiswww.cwru.edu/php/chet/readline/rltop.html) 和 [GNU dbm](https://www.gnu.org.ua/software/gdbm/)（GDBM）数据库函数库。他考虑弃用这些库的构建时链接选项，以使 PHP "让打包者无忧"。最终，链接 GDBM 和 Readline 的可能性将被完全移除。Ramsey [表示](https://discourse.thephp.foundation/t/php-dev-rfc-updating-the-php-license/2024/5)这一变更将简化打包者的工作： > 对于那些打包 PHP 并链接到 GPL 库的人来说，当前的 PHP License version 3.01 存在不兼容性，无法解决，因为它对用户施加了额外的[限制](https://www.gnu.org/licenses/license-list.html#PHP-3.01)。然而，在 Modified BSD License 下，不存在不兼容性，只要组合包在 GPL 条款下发布。 3 月 14 日，Ramsey [宣布](https://news-web.php.net/php.internals/130311)开启 RFC 投票。投票是公开的，在 PHP wiki 的 [RFC 正文中](https://wiki.php.net/rfc/php_license_update#voting_choices)进行计票。目前不清楚总共有多少合格选民：2019 年有 [180 人](https://wiki.php.net/rfc/voting2019#eligible_voters)拥有投票权。目前，47 人投票赞成，2 人弃权；尽管早期结果似乎压倒性地支持，但尚不确定提案是否会通过。如果通过，这在很大程度上要归功于 Ramsey 在过去几年中在幕后对话、获得批准以及推动 RFC 进入最终投票方面所做的工作。