PHP RFC：PHP 许可证更新

• 日期：2025-07-10
• 作者：Ben Ramsey，ramsey@php.net
• 建议版本：PHP 9.0
• 状态：正在讨论
• 首次发布于：http://wiki.php.net/rfc/php_license_update

引言

PHP 及其自定义开源许可证长期存在混淆、担忧和争议，而涵盖 Zend/ 目录源代码的 Zend 引擎许可证进一步加剧了这种混淆，并因其并非开源倡议组织(OSI)批准的许可证而使问题复杂化。本 RFC 提议对 PHP 许可证进行务实的简化，以消除这种混淆，保留所有 PHP 贡献者的版权，并授予用户与原许可证相同的权利。实现这一目标的提议许可证是 修改版 BSD 许可证，通常称为 3 条款 BSD 许可证。

提案

本提案通过发布PHP许可证和Zend引擎许可证的新版本，解决了开源社区长期存在的问题。修改版BSD许可证被采纳为PHP许可证第4版，以及Zend引擎许可证第3版。

修改版BSD许可证有时也被称为“新”、“修订版”或“3条款”BSD许可证。其SPDX标识符为BSD-3-Clause。1) 该许可证同时获得开源倡议组织(OSI)和自由软件基金会(FSF)的认可，被视为自由软件许可证。2) 3) FSF已将其指定为与GNU通用公共许可证(GPL)兼容，且它是OSI批准的许可证。

PHP 许可证第 3.01 版和 Zend 引擎许可证第 2.00 版将修改后的 BSD 许可证与仅适用于 PHP 组和 Zend Technologies(现为 Perforce Software 的子公司)的特殊条款相结合。在移除这些特殊条款后，许可证与修改后的 BSD 许可证完全相同，且贡献者授予的权利或用户享有的权利均未发生变化。

采用修改版BSD许可证后：

• 贡献者授予的权利保持不变。
• 用户获得的权利保持不变。
• 我们将与PHP组和Perforce软件合作，移除其专属条款。
• PHP软件和Zend引擎将采用同时获得OSI批准且与GPL兼容的许可条款。

建议，PHP项目将：

1. 与PHP组合作，采用修改版BSD许可证作为PHP许可证，版本4。
2. 与 Perforce Software 合作，采用 修改版 BSD 许可证 作为 Zend 引擎许可证，版本 3。
3. 废弃 PHP 许可证和 Zend 引擎许可证。强烈建议不要在新的项目中使用这些许可证，无论是在PHP项目内部还是外部。
4. 从PHP软件中删除LICENSE文件的内容，并用下方新LICENSE文件部分中指定的内容替换。
5. 从 Zend 引擎中删除 Zend/LICENSE 文件。
6. 将 PHP 软件中所有 PHP 源文件的文件头替换为下方 新 PHP 源文件头 部分中指定的内容。
7. 将所有 Zend 引擎源文件的文件头替换为下方 新 Zend 引擎源文件头 部分中指定的内容。
8. 更新其他相关文档和网页以反映这些更改，例如https://www.php.net/license/。

背景， 变更授权 和 额外背景 部分提供了此次变更的进一步背景和法律依据。

修改版BSD许可证

以下是修改版BSD许可证的完整文本。

以源代码或二进制形式重新分发和使用(无论是否修改)均被允许，但须满足以下条件：

1. 重新分发的源代码必须保留上述版权声明、本条件列表以及以下免责声明。
2. 以二进制形式重新分发的软件必须在随附的文档和/或其他材料中完整保留上述版权声明、本条件列表以及以下免责声明。
3. 未经版权持有者或其贡献者事先书面许可，不得使用版权持有者或其贡献者的名称来为基于本软件衍生出的产品进行背书或推广。

本软件由版权持有者和贡献者按“原样”提供，不提供任何明示或暗示的保证，包括但不限于对适销性或适用于特定目的的暗示保证。在任何情况下，版权持有者或贡献者均不对任何直接、间接、偶然、特殊、惩罚性或后果性损害(包括但不限于替代商品或服务的采购；使用、数据或利润的损失； 或业务中断)的责任，无论损害如何造成，也无论基于何种责任理论(包括合同、严格责任或侵权行为(包括过失或其他))，只要损害与使用本软件有关，即使已被告知可能发生此类损害。

新许可文件

版权 © 1999–2025，PHP 组和贡献者。
版权 © 1999–2025，Zend 由 Perforce 提供。

以源代码或二进制形式重新分发和使用，无论是否
修改，均在满足以下条件的情况下允许：

1. 重新分发源代码必须保留上述版权声明、本
   条件列表以及以下免责声明。
2. 二进制形式的重新分发必须在随附的文档
   和/或其他材料中复制上述版权声明、
   本条件列表以及以下免责声明。
3. 未经特定事先书面许可，不得使用版权持有者或其
   贡献者的名称来为衍生自本软件的产品提供背书或推广。

本软件由版权持有者和贡献者按“原样”提供，
任何明示或暗示的保证，包括但不限于
关于适销性或适用于特定目的的暗示保证，
均被明确排除。在任何情况下，版权持有者或贡献者均不对
任何直接、间接、偶然、特殊、惩罚性或后果性损害(包括但不限于
采购替代商品或服务；使用、数据或利润的损失； 或业务中断)的责任，
无论损害如何造成，也无论基于何种责任理论，
无论是合同、严格责任，还是侵权(包括过失或其他原因)，
只要损害与使用本软件有关，即使已被告知可能发生此类损害。

新 PHP 源文件头部

提供的作者名称仅为示例，旨在说明我们在每个文件头部保留现有作者名称。

/*
+———————————————————– ———–+
| 版权 © PHP 组和贡献者。 |
+——————————————————————— -+
| 本源文件受修改版 BSD 许可证约束，该许可证 |
| 与本软件包一同打包在 LICENSE 文件中，并可通过 |
| 万维网在 https://www.php.net/license/ 获取。 |
| |
| SPDX-License-Identifier: BSD-3-Clause |
+———————————————————————-+
| 作者：John Smith john@example.com |
| Kira Torres kira@example.com |
+————————————————————— ——-+
*/

新 Zend 引擎源文件头部

提供的作者名称仅为示例，旨在说明我们在每个文件头部保留了原有的作者名称。

/*
+——————————————- —————————+
| Zend 引擎 |
+———————————————————– ———–+
| 版权 © Zend 由 Perforce 和贡献者所有。 |
+——————————————————————– –+
| 本源文件受修改版 BSD 许可证约束，该许可证 |
| 与本包中的 LICENSE 文件捆绑，并可通过 |
| 万维网在 https://www.php.net/license/ 获取。 |
| |
| SPDX-License-Identifier: BSD-3-Clause |
+———————————————————————-+
| 作者：约翰·史密斯 john@example.com |
| 基拉·托雷斯 kira@example.com |
+———————————————————————-+
*/

背景

PHP 许可证和 Zend 引擎许可证与 GPL 不兼容4)，且 Zend 引擎许可证未获得 OSI 批准。尽管 OSI 许可批准委员会投票批准了 PHP 许可的 3.0 和 3.01 版本，但每个版本都遵循了“遗产批准”流程，这意味着这些许可在 OSI 批准它们之前已经广泛使用了多年。因此，OSI 批准 PHP 许可证更多是基于其意图，而非其内容。如果 OSI 许可证批准委员会未考虑 PHP 许可证的遗留使用情况，仅凭其内容批准的可能性很低。

最初，尽管 Zend 引擎与 PHP 一起打包在 Zend/ 目录中，但它被视为一个完全独立的产品，可以与 PHP 分离并单独使用。确实，这是最初的意图，也是 PHP 和 Zend 引擎拥有独立许可证的原因。然而，经过 25 年的在同一源代码仓库中的“共存”，两者已紧密交织，以至于 Zend 引擎无法再被分离并作为独立产品使用。它们共同构成了 PHP 编程语言的参考实现。

历史背景

Rasmus Lerdorf在创建PHP时，自由软件运动中的一部分人对运动的政治和哲学感到不满，并分裂出来，围绕一套更宽松的许可证凝聚在一起，这些许可证被视为对商业使用更友好——这便是开源运动的起源。

框架争论、随之而来的转变以及开源运动的诞生，可以被视为一个衍生运动，它不仅有着不同的诊断和更灵活的范围，还努力避免他们认为创始运动中阻碍商业增长的“错误”。5)

在最初的发布公告中，Lerdorf写道：“这些工具属于公共领域，并根据GNU通用公共许可证分发。是的，这意味着它们是免费的！”6) 7) Lerdorf选择将PHP版本1和PHP/FI(版本2)在GNU通用公共许可证第2版(GPLv2)的条款下发布，但他意识到开源运动中日益增长的担忧，即商业利益方对在组织中使用GPL软件感到恐惧甚至禁止——事实上，许多组织至今仍延续这一做法。在1997年的一篇讨论许可的邮件列表帖子中，Lerdorf表示：“如果我能做到，PHP将永远免费。但我并不反对让商业实体尝试推出商业版本，只要条款确保主要贡献者不会感到受骗。”8)

这导致了PHP 3中的双许可证模型，允许用户选择在GPLv2条款下使用PHP，或使用基于Apache许可证1.0版本的自定义许可证。“我们的许可证与Apache许可证完全相同(因为我们就是从那里复制的)，除了第一个条款，”Lerdforf在1999年的一篇邮件列表帖子中写道。9) 该条款限制了商业用途：

基于PHP衍生的大型作品或捆绑PHP的作品的商业分发，需获得PHP开发团队的书面许可。您可以对复制的物理转移行为收取费用，但必须明确说明所收取的费用是针对分发行为，而非软件本身。您可以选择以收取费用为条件提供保修服务。10)

双许可证模式给一个缺乏处理法律问题能力的团队带来了诸多挑战。在同一讨论中，Lerdorf提到曾收到多家公司要求提供签名版纸质文件以授权使用PHP的请求，但无法妥善回应。11) 企业对自由开源软件缺乏理解，且PHP项目内部对用户应享有的自由程度存在显著分歧。当时，Zeev Suraski写道：“人们不应被赋予法律权利，可以随心所欲地使用PHP。”12) 然而，由于Lerdorf将第一条款称为“那个难以执行的条款”， 13) 团队最终在PHP 3.0.14中删除了该条款。14)

与此同时，GPL 的作者兼 FSF 创始人理查德·斯托曼(Richard Stallman)与 PHP 项目就其使用 GPL 许可证一事存在重大分歧，15) 16) 因此，PHP 项目停止了双许可证策略，取消了 GPL 许可证作为选项，PHP 4.0.0 随附 PHP 许可证第 2.02 版和 Zend 许可证第 0.92 版， 17) 用于 Zend/ 目录内的源代码。

Suraski 和 Andi Gutmans 最初计划将 Zend/ 目录设为只读，所有源代码由两人共同拥有，以便他们能够“将 Zend 引擎用于除 PHP 以外的其他用途”。18) 显然，他们——以及 PHP 项目的其他早期成员——将 Zend 引擎视为与 PHP 完全分离的实体。在 1999 年的一次采访中，Lerdorf 明确了围绕独立许可证的许可问题：

PHP 4 与 Zend 并非同义词。至于许可问题，Zend 许可仅在您将 Zend 从 PHP 中分离并尝试将其嵌入其他系统时生效。19)

安德烈·兹米耶夫斯基对此进行了进一步阐述：

我认为人们对 Zend 在 PHP 基础设施中扮演的角色仍存在一些误解。主语言(PHP)使用引擎(Zend)提供的基础服务——例如内存分配、持久资源、编译和执行等服务。PHP本身则提供函数库、与Web服务器的接口、.ini文件支持等。20)

古特曼斯暗示了Zend引擎未来可能的用途，这解释了为何需要单独的许可证：

我非常希望未来能将 Zend 引擎嵌入 MySQL。我认为能够用访问数据库的脚本引擎相同的语言编写数据库的存储过程代码将非常棒。[…]

Zend 引擎是以一种可用于 PHP 以外其他产品的形式编写的。[Zend 许可证]允许我们(Zend 公司)保留在其他商业用途中使用它的权利。然而，作为 PHP 的一部分，Zend 可以自由使用，并受 PHP 许可证约束。21)

后来，古特曼解释了为何他认为 Zend 引擎的独立许可证不会给贡献者带来任何问题：

没有人真正为脚本引擎做贡献，而是通过添加额外的模块和函数来扩展 PHP。除了我们之外，还有其他开发者一直在扩展 PHP 的功能。22)

此后，许可证仅经历了一次重大变更，产生了 Zend 引擎许可证 2.00 版，首次随 PHP 4.2.0(2002 年 4 月 22 日)发布，以及 PHP 许可证 3.0 版，首次随 PHP 4.2.3(2002 年 9 月 6 日)发布。

2003年5月，Lerdorf向OSI提交了PHP许可证3.0版本的审批申请，并在申请中暗示，一旦该版本获得OSI批准，他希望将PHP切换至Apache许可证2.0版本。

希望新的Apache许可证一旦最终确定，将获得OSI批准，并且具有项目无关性的重大优势，因此像PHP这样与Apache密切相关的项目可以直接使用它，而无需进行修改，我们也不需要所有这些类似Apache的许可证。23)

几年后，PHP许可证的措辞发生了一点点变化，导致版本号更改为3.01。24) 这一新版本虽与原版几乎相同，但从未获得OSI批准，这一问题在14年后浮出水面，当时Matthew Sheahan在php-general邮件列表中询问了版本3.01的OSI批准状态。

我团队使用 phpdbg 工具的能力取决于其许可证获得 OSI 批准。在 https://www.php.net/license/ 中的表述表明 PHP 3.01 许可证已获得 OSI 批准，但 OSI 对此持不同意见； https://opensource.org/licenses/alphabetical 仅显示对 PHP 3.0 许可证的批准。(3.0 和 3.01 在实质上完全相同这一事实对我们毫无帮助。)25)

安德烈亚斯·海格尔(Andreas Heigl)在php-internals邮件列表中提问：“这里有人还记得当初为何要修改许可证吗？”26) 作为回应，约翰内斯·施吕特提到了Debian 辩论。

我的记忆可能有误，但我认为 Debian 社区曾就 PECL 扩展采用 PHP 许可证 [sic] 3.0 以及相关表述不够理想的问题展开过讨论。新的措辞(及网站链接)应明确指出PECL(和PEAR)是“PHP软件”，但并非“PHP”。27)

当时，Ben Ramsey自愿联系OSI，正式申请PHP许可证的“遗产批准”。28) “历史批准”指定允许许可证管理员或任何感兴趣的许可证持有者请求“对已由现有社区广泛使用但此前未获批准的历史/遗留许可证进行追溯批准”。29) 因此，2020年3月4日，Ramsey向OSI许可审查列表提交了遗产批准请求，30) 2020年5月13日，OSI董事会投票批准了PHP许可证，版本3.01。31)

Zend与PHP协会

PHP协会是一家于2000年2月在美国内布拉斯加州注册的公共利益公司。32) PHP协会的每位董事同时也是PHP组的成员。33) 34) 从此可以推断，PHP 组成立 PHP 协会是为了在法律和商业事务中代表该组。

2000年5月22日，即PHP团队发布PHP 4.0.0版本(包含Zend Engine 1.0.0版本)的同一天，Zend Technologies与PHP协会签署协议，以确保Zend Engine作为开源产品持续可用。

该协议特别规定：35)

由于Zend引擎是PHP的关键组件，Zend在此向PHP协会作出以下承诺和保证：

• Zend将继续以Zend开源许可证的形式提供Zend引擎作为开源产品。如果Zend更改Zend开源许可证的条款，新许可证将与开源倡议组织的开源定义保持一致。
• PHP协会现被授权以源代码和目标代码形式，将Zend引擎作为PHP的集成组件，向同意受PHP开源许可证2.02版约束的最终用户进行推广、分发和转授权。[…] 然而，如果 Zend 引擎被修改或与 PHP 的其他部分分离，则修改或分离后的 Zend 引擎的使用将不再受 PHP 开源许可证的约束，而是受 Zend 开源许可证的约束。

PHP 协会同意协议的条款，其中包括以下条件：

• “协会不得删除或修改 Zend 引擎上出现的任何知识产权权利或许可声明，并应在制作的每个 Zend 引擎副本上复制并显示此类声明。”
• “未经 Zend 的书面同意，协会不得以任何方式(包括法律规定)全部或部分转让本函件。任何未经此类同意的转让尝试均属无效。本函件将约束并惠及各方的经授权继任者和受让人。”

鉴于美国大多数州的公司法规定，即使PHP协会已不再是活跃实体，其仍可能受本合同的法律约束，且合同条款随Zend被Rogue Wave于2015年收购及被Perforce Software于2019年收购而延续。

许可证变更日志

PHP 1 和 2

PHP 1.0 和 2.0(又称 PHP/FI)均采用 GNU GPL 2.0 版本授权。36) 37)

PHP 3

PHP 3.0同时采用GPL第2版和一种自定义的BSD风格许可证，该许可证最终被称为“PHP许可证”。该 BSD 风格许可证即 Apache 许可证第 1.0 版，但有两项重大差异：

1. PHP 添加了一项新条件，要求商业分发需获得书面许可。
2. PHP 省略了原 Apache 许可证中的第五项条件。

该许可证未包含版本标识符，版权持有者被列为“PHP开发团队”。

修订版 1

在 PHP 3.0.1 中，PHP 团队在 PHP 许可证的第 5 条条件中添加了以下额外声明：

本条款不适用于与PHP配合使用的附加库或工具。在这种情况下，可使用PHP名称表明该产品支持PHP。

修订版 2

在 PHP 3.0.14 中，PHP 团队删除了要求获得书面许可才能进行商业分发的第 1 条条件。

此时，该许可证与 Apache 许可证几乎完全一致，仅增加了 修订版 1 中提到的条款，并删除了 Apache 许可证 1.0 版本中出现的第五个条件。

PHP 4

PHP 许可证，版本 2.02

PHP 4.0.0 包含 PHP 许可证，版本 2.02，38)，该版本代表了在 PHP 4.0 的 beta 和发布候选阶段对许可证进行的多次修订。除新增针对 Zend 引擎的独立许可证(该引擎为 PHP 4 新增)外，本版本的 PHP 许可证还包含以下变更：

1. 移除了“广告材料”条款。
2. 新增条款，授予 PHP 组在“任何时候且无需事先通知”修改许可证的权利，前提是修改内容保持 PHP 的自由开源性质。
3. 添加了一项新条款，允许在与 PHP 捆绑的情况下，根据 PHP 许可证条款分发 Zend 引擎。当 Zend 引擎与 PHP 分离时，其使用受 Zend 引擎许可证约束。

该许可证将“2.02”作为版本标识符，并将版权持有者列为“PHP 组”。

Zend引擎许可证

Zend引擎许可证最初是Q公共许可证(QPL)39)的副本，并在PHP 4.0.0中作为Zend引擎许可证，版本0.92包含在内。40) 然而，PHP 4.2.0 包含了一个全新的 Zend 引擎许可证版本 2.00，其条款与 PHP 许可证版本 2.02 几乎相同。主要区别在于新增了作为第 6 条条件的“广告条款”，而非 PHP 许可证 2.02 版中出现的 Zend 引擎条款。41)

PHP 许可证，版本 3.0

PHP 4.2.3 将 PHP 许可证更新至 3.0 版本。42) 该版本包含以下变更：

1. 移除了第 3 条中的“不适用于附加库或工具”条款。
2. 添加了新的第四个条件，禁止任何衍生产品自称“PHP”。
3. 删除了许可证 2.02 版本的第六个条件，这意味着当 Zend 引擎与 PHP 捆绑时，不再受 PHP 许可证条款的约束，而是始终适用 Zend 引擎许可证，该许可证适用于 Zend/ 目录中的源代码。

PHP 5+

PHP 许可证，版本 3.01

PHP 5.1.2 和 4.4.2 将 PHP 许可证更新至版本 3.01，对 PHP 许可证进行了非常小的修改。43) 44) 45)

BSD 风格许可证

PHP 许可证和 Zend 引擎许可证均为 BSD 风格许可证。如前所述，Lerdorf 将 Apache 许可证第 1.0 版作为原始 PHP 许可证的模板，46) 而 Apache 许可证第 1.0 版源自原始的 4 条款 BSD 许可证。47) 事实上，两者完全相同，只是 Apache 许可证添加了第 5 条和第 6 条：

5. 基于本软件衍生出的产品不得称为“Apache”，也不得在名称中使用“Apache”一词，除非获得 Apache 组的书面许可。

1. 以任何形式重新分发时，必须保留以下声明：“本产品包含由 Apache 组为 Apache HTTP 服务器项目(http://www.apache.org/)开发的软件。” 48)

由此延伸，PHP 许可证是 BSD 4 条款许可证的衍生版本。

BSD 4条款许可证并非 OSI 批准的许可证，49) 而自由软件基金会(FSF)认为其虽为自由许可证但存在问题。50) 这两种立场均是对 BSD 广告条款的回应：

所有提及本软件功能或使用方式的广告材料必须显示以下声明：本产品包含由该组织开发的软件。

对于PHP许可证，版本3.01，条件1和2与BSD 4条款许可证的条件1和2完全相同。PHP许可证的条件3在功能上与BSD的条件4相似。PHP许可证的条件6在功能上与BSD 4条款许可证的条件3相似。PHP新增了条件4和5。

对于 Zend 引擎许可证(版本 2.00)，条件 1 和 2 与 BSD 4 条款许可证的条件 1 和 2 完全相同。Zend 引擎许可证的条件 3 在功能上与 BSD 4 条款许可证的条件 4 相似。Zend 引擎许可证的条件 5 和 6 在功能上与 BSD 4 条款许可证的条件 3 相似。Zend新增了第4条条件。

版权与开源贡献

每位贡献者对其对开源项目所做的具体贡献拥有版权，前提是这些贡献具有可版权性。某些贡献(如拼写错误修正、空格调整等)不具有可版权性，但任何更具实质性的贡献均归贡献者所有，前提是该贡献为其独立创作。

换言之，尽管许可声明中指出版权属于 PHP 组51) 或 Zend 技术公司52)所有，但从技术上讲，这些版权声明仅适用于这些组织或代表这些组织贡献代码的个人所贡献的特定代码。

向开源项目贡献代码并不意味着你默认将版权转让给该项目。要实现这一点，每位贡献者必须签署一份贡献者许可协议，明确声明他们将版权转让给代码的所有者。目前，没有人签署过此类协议，因此每位贡献者仍保留其对PHP项目所贡献代码的版权。

然而，隐含的是许可的转让。当有人为开源项目贡献代码时，他们拥有其贡献的版权，但除非他们指定了覆盖其贡献的不同许可(这完全有效，例如Derick Rethans的timelib，它被包含在PHP源代码中)，否则默认情况下，他们被视为在与项目相同的许可条款下授予其贡献的使用权。因此，贡献者无法事后要求移除其所有受版权保护的代码；这些代码受相同许可条款约束，且该许可无法撤销。然而，如果项目决定更改许可条款，贡献者可要求移除其受版权保护的代码，因为他们可能不愿将其作品授予新许可条款。

此外，常见惯例规定，一旦版权声明被放置在源文件中，它应保留在该源文件中，包括任何列出的年份，尽管年份无需更新。例如，查看任何 WebKit 源文件的文件头。53) WebKit 甚至规定，在对文件进行“重大”修改时，需在每个文件中添加版权声明。54)

修改权限

谁拥有进行这些修改的权限？

我们已明确，每位贡献者对其在开源项目中的个人贡献拥有版权，且除非另有说明，他们会向用户授予与修改的源文件所采用的许可证相同的权利。通常，更改开源项目的许可证时，必须获得所有版权所有者的批准，因为新许可证的条款可能改变所授予的权利。然而，如本节及其他文档中所述，切换至修改版BSD许可证不会改变非PHP组或Perforce Software的贡献者所授予的任何权利。

是否需要获得所有贡献者的许可？

简短的回答是“不需要”。然而，作为一种礼节，我们将就这一主题保持讨论至少六个月，然后再对提案进行投票。

此前，我们已明确，每位贡献者对其具体贡献享有版权，除非他们指定了覆盖其贡献的其他许可证，否则默认认为他们已授权其贡献在与项目相同的许可证条款下使用。我们还详细明确了，PHP许可证第3.01版和Zend引擎许可证第2.00版，在移除各自许可证中的第4、5和6条条件后，与修改版BSD许可证完全一致。55)

毫无疑问，贡献者有权授予用户使用其代码的许可，具体条件为1和2。这些条件适用于PHP许可证、Zend引擎许可证和修改后的BSD许可证。本提案不会更改这些条件中任何部分的措辞：

以源代码或二进制形式重新分发和使用(无论是否修改)均被允许，前提是满足以下条件：

1. 源代码的重新分发必须保留上述版权声明、本条件列表以及以下免责声明。
2. 二进制形式的重新分发必须在随分发提供的文档和/或其他材料中复制上述版权声明、本条件列表以及以下免责声明。

条件 3 在不同许可证中存在差异。然而，从字面意义上看，PHP 和 Zend Engine 许可证中该条件的意图与修改版 BSD 许可证的第 3 条条件相同。此外，根据PHP和Zend Engine许可证的表述，贡献者无权对其自身贡献主张这些条款，因为这些条款分别专属于PHP组和Perforce软件公司，但他们有权主张修改版BSD许可证的第3个条款。

PHP 许可证

未经事先书面许可，不得使用“PHP”名称来背书或推广从本软件派生的产品。如需书面许可，请联系 group@php.net。

Zend 引擎许可证

未经 Zend Technologies Ltd. 事先许可，不得使用“Zend”和“Zend 引擎”名称来背书或推广从本软件衍生出的产品。如需书面许可，请联系 license@zend.com。

修改版 BSD 许可证

未经特定事先书面许可，不得使用版权持有者或其贡献者的名称来为衍生自本软件的产品背书或推广。

当我们仔细查看 PHP 许可证和 Zend 引擎许可证的第 4、5 和 6 条条件时，似乎除了 PHP 组和 Perforce Software 的代表外，其他贡献者无法为其贡献授予或主张这些条件。从许可证中删除这些条款不会改变贡献者(除PHP组和Perforce Software外)所授予或限制的任何权利(见下文)。

基于此，我们无需获得所有贡献者的许可即可进行这些修改。

是否需要获得PHP组的许可？

是的。

本提案移除了以下条款，而这些条款仅由PHP组对PHP源代码拥有主张权：

4. 未经group@php.net事先书面许可，基于本软件衍生出的产品不得称为“PHP”，也不得在名称中包含“PHP”。您可以通过使用“Foo for PHP”来表明您的软件与PHP兼容，而非将其命名为“PHP Foo”或“phpfoo”

5. PHP组可不时发布修订版或新版本的许可协议。每个版本将被赋予一个唯一的版本号。一旦受保护的代码在特定版本的许可证下发布，您可始终继续在该版本条款下使用该代码。您亦可选择在PHP组发布的后续版本许可证条款下使用该受保护代码。除PHP组外，任何其他方均无权修改本许可证下创建的受保护代码所适用的条款。

6. 以任何形式进行的重新分发必须保留以下声明：“本产品包含 PHP 软件，可从 http://www.php.net/software/ 免费获取”。

好消息是，条件 5 授予 PHP 组修改 PHP 许可的权限，无需获得任何贡献者的批准。

根据 PHP 协会(如前文在 Zend 和 PHP 协会 中讨论的)所采纳的章程，我们可能需要获得 PHP 组的一名或多名代表的批准才能接受此提案。目前没有协会章程的公开记录，因此除非章程中规定了法定人数，否则我们需要获得以下人员的批准：

• Thies C. Arntzen (已批准，2024-05-10)
• Stig Bakken (已批准，2025-02-21)
• Shane Caraveo (已批准，2024-05-10)
• Andi Gutmans (已批准，2024-05-13)
• Rasmus Lerdorf (已批准，2025-06-27)
• Sam Ruby (已批准，2025-06-27)
• Sascha Schumann (已批准，2025-06-27)
• Zeev Suraski (已批准，2024-05-13)
• 吉姆·温斯泰德 (已批准，2024-05-09)
• 安德烈·兹米耶夫斯基 (已批准，2024-05-14)

我们是否需要获得Perforce软件的许可？

注意： Perforce Software 的法律代表已非正式批准此提案。下一步是正式书面批准。

是的。

作为 Zend Technologies 的继任者，Perforce Software 是 Zend 许可协议的签约方，并拥有 Zend 引擎许可。本提案将取消以下条件，而 Perforce Software 对此类条件对 Zend 引擎源代码具有独特的主张权：

1. Zend Technologies Ltd. 可不时发布修订版和/或新版本的许可协议。每个版本将被赋予一个独特的版本号。一旦受保护的代码在特定版本的许可下发布，您可始终继续按照该版本的条款使用该代码。您也可选择按照 Zend Technologies Ltd. 发布的后续任何版本的许可条款使用该受保护代码。除 Zend Technologies Ltd. 外，任何其他方均无权修改本许可下创建的受保护代码适用的条款。

5. 以任何形式进行的重新分发必须保留以下声明：“本产品包含 Zend 引擎，可免费获取自 http://www.zend.com”

6. 所有提及本软件功能或使用情况的广告材料必须显示以下声明：“Zend 引擎可免费获取，网址为 http://www.zend.com”

正如PHP许可证授予PHP组修改PHP许可证的权限，Zend引擎许可证也授予Perforce软件公司独家修改Zend引擎许可证的权限，无需其贡献者的批准。

为了实施本RFC中提议的修改，PHP项目将要求PHP组的代表(或代表们)与Perforce软件公司的代表合作，以达成此提议的共识。

是否需要对此进行投票？

是的。

尽管 PHP 许可证和 Zend 引擎许可证包含允许 PHP 组和 Perforce Software 随时修改许可证的条款，但在实践中，PHP 项目社区管理着 PHP 编程语言的主要参考版本和 Zend 引擎。因此，PHP 项目社区的投票对于实施此修改至关重要。

通过 PHP 项目社区投票接受此 RFC 将：

1. 表明 PHP 项目社区有意进行这些更改。
2. 向 PHP 组和 Perforce 软件表明我们希望进行这些更改，并请求他们协助我们完成这些更改。

讨论期

我们将开放为期不少于六个月的讨论期，随后再就本 RFC 进行投票。

向后不兼容的更改

本 RFC 不会引入任何向后不兼容的更改。

PHP 许可证第 3.01 版和 Zend 引擎许可证第 2.00 版的条款与修改版 BSD 许可证的条款完全兼容。拟议的许可证不会减少任何用户权利，也不会对之前根据PHP许可证第3.01版或Zend引擎许可证第2.00版授权的代码使用添加任何新限制。拟议的许可证不会增加或减少贡献者授予的任何权利。

拟议的PHP版本

本RFC提议在PHP 9.0.0版本中全面实施这些许可证变更。

RFC 影响

范围

本提案影响 PHP 软件仓库(https://github.com/php/php-src)中所有目前采用 PHP 许可证或 Zend 引擎许可证授权的源代码。PHP 软件仓库中任何具有独立许可条款的源代码(例如 ext/date/lib/ 中的 timelib)不受本提案影响。

文档

本提案对 PHP 软件仓库的更改不会影响 PHP 手册。PHP 手册将继续采用 Creative Commons Attribution 3.0 许可证或更高版本。56)

现有扩展和其他软件

本提案发布了 PHP 许可证的新版本，触发了 PHP 许可证第 3.01 版的第 5 条，该条款规定(强调部分)：

PHP 组可不时发布修订版或新版本的许可证。每个版本将被赋予一个独特的版本号。一旦受保护的代码在特定版本的许可证下发布，您可始终继续按照该版本的条款使用该代码。您也可选择按照 PHP 组发布的后续版本许可证的条款使用该受保护代码。 除 PHP 组外，任何其他方均无权修改本许可协议下创建的受许可代码适用的条款。

使用任何基于 PHP 许可协议第 3.01 版发布的 PHP 扩展或其他软件的用户，可选择在 PHP 许可协议第 4 版(即修改版 BSD 许可协议)的条款下使用该软件。

PHP 扩展及其他软件的维护者，若其软件是根据 PHP 许可证第 3.01 版条款发布的，可选择将软件许可证升级至 PHP 许可证第 4 版(即修改版 BSD 许可证)。为减少许可证泛滥，不建议使用“PHP许可证，版本4”作为许可证名称。若需SPDX标识符，请使用BSD-3-Clause。

历史上，许多上传到 PECL 的扩展都采用 PHP 许可证第 3.01 版进行授权。事实上，发布 PECL 包的建议之一是：“我们强烈建议贡献者为其扩展选择 PHP 许可证 3.01，以避免扩展最终用户可能遇到的麻烦。其他可靠的选择包括BSD和Apache类型许可证。”57)

此处提到的“潜在问题”几乎总是源于使用像 GPL 这样的 copyleft 许可证。FSF 认为 PHP 扩展与 PHP 软件的组合构成一个单一的组合程序。58) 因此，使用 GPL 许可证授权 PHP 扩展会导致一种令人困惑的状态，这对分销商尤其成问题。

新的PHP扩展和其他软件不应使用PHP许可证。推荐的许可证包括但不限于(按字母顺序排列)：

1. Apache许可证，版本2.0
2. 简化版BSD许可证
3. 修改版BSD许可证
4. GNU 较少通用公共许可证第 3 版
5. MIT 许可证
6. Mozilla公共许可证2.0
7. 无许可证

待解决问题

将在讨论过程中更新.

提案投票选项

是否采用修改版BSD许可证作为PHP许可证第4版和Zend引擎许可证第3版的新版本，并废止PHP许可证和Zend引擎许可证，如提案部分所提议？

是/否

参考资料

补丁

• php-src 更改 – 来自 php-license-update 工作分支(此分支已拆分为多个较小的提交以方便审查)
• web-php 更改 – 来自 php-license-update 工作分支

实现

实现后将更新。

讨论

1. debian-legal: 更新 PHP 许可证
2. OSI 许可讨论组: 更新 PHP 许可协议
3. PHP 内部讨论组: 更新 PHP 许可证

被拒绝的功能

将在讨论中更新.

附加背景

关于 PHP 许可证的讨论和分歧有很多。本节突出显示了本文件 earlier 部分未包含的几个更实质性的讨论。

与RMS的分歧

RMS是否接受了PHP/Zend的许可结构？59) 60)

这表明在2001年5月之前，PHP维护者与理查德·斯托曼(即RMS)之间存在分歧。然而，这一分歧的具体性质尚不清楚，因为在公开邮件列表或论坛上没有相关记录。

在2004年发表的一篇文章中，肖恩·迈克尔·克纳尔引用了古特曼斯的话，后者提到了与RMS关于PHP许可证的过去交流。

古特曼斯表示，他过去曾与自由软件基金会创始人理查德·斯托曼就这类问题交换过邮件。“我们在许可证问题上显然意见不一。他[理查德·斯托曼]不喜欢我们的许可证，我们也清楚这一点，”古特曼斯说。“我们彼此知晓，但PHP项目无意转向某种GPL许可证。”61)

在这同一场采访中，古特曼斯阐述了他对用户使用PHP时权利的看法：“我们喜欢PHP非常开放这一点。关于‘自由’的真正含义，这是一个长期的讨论。当我想到‘自由’时，我的用户可以随心所欲地使用它。” 他继续说道：“PHP的大部分用户都是靠PHP谋生的人，他们对GPL许可协议毫不在意。他们只是高兴PHP有自己的许可协议，可以随心所欲地使用它，并将其与商业产品捆绑销售。”

Debian 争议

Debian 为 PHP 创建补丁并分发修改后的 PHP 版本，使用这些补丁。从某种意义上说，他们违反了 PHP 许可证的第 4 条。

由于 Debian(或至少可能)在其包中分发了不属于上游的补丁，我们分发的是衍生产品，因此不得将其命名为 PHP。

这不仅影响 Debian，还影响其他试图以某种方式增强或修复 PHP 的 PHP 发行版。62)

Schulze 发送了一封邮件向 PHP 组寻求澄清，并将其回复发布到 debian-legal 邮件列表，称：

安迪·古特曼斯回复并告知我，他代表PHP组发言：

根据你的问题，BSD类许可中包含此类条款是Apache和PHP长期以来用于维护和保护其品牌的方式。 minor build changes和回溯的安全修复是可以接受的，如果你只做这些，就没有必要重命名包。问题在于当您开始对实际功能进行重大修改时，

该许可条款及意图与Apache许可完全一致，我们认为您也在使用该许可。

因此，一旦我们的维护者或安全团队添加了超过仅限[sic]“构建更改和回溯的安全修复”的内容，我们就必须重命名PHP(和Apache)包。63)

同年晚些时候，Joerg Jaspert 在处理 Debian 的“NEW 队列”时，注意到一些使用 PHP 许可证的 PHP 扩展。

但使用 PHP 许可证的一个主要问题是，它始终只提及“PHP”、“由 PHP 开发团队提供的软件”、“由许多个人代表 PHP 组开发的软件”以及“本软件包含 Zend 引擎”。我 [sic] 确信没有一个 php-* 模块包含 Zend 引擎。:)

因此，对于NEW队列中的此类包，大家有什么建议？我倾向于将其移除，并要求上游项目使用合理的许可证…64)

确实，没有一个PHP模块(也称为扩展)包含PHP源代码或Zend引擎源代码。Jaspert倾向于将这些包从Debian仓库中移除，并要求上游项目维护者“使用一个合理的许可证”。

几年后，Debian关于PHP许可证的辩论仍在继续。2014年，Jake Edge总结了当时在debian-legal邮件列表上新出现的争论。他报告称，从Debian的角度来看，PHP许可证使得PHP以及任何使用该许可证的扩展或其他代码无法分发。65)

在debian-devel邮件列表上，马蒂亚斯·乌尔里希斯(Matthias Urlichs)感叹道：

显然，PHP/Zend对第三方如何(滥用)该许可证毫不在意。同样显而易见的是，这些第三方认为该许可证完全适用，不会更改它，并认为我们提这件事很奇怪。66)

乌尔里希斯为Debian团队列出了三个选项，最后一个是：

咬紧牙关承认，当其他人将一种颜色称为“浅蓝色”而我们认为是“青色”时，我们不妨直接记录[sic]这一事实，而非试图说服他人他们是错的，即使从我们的角度看他们确实错了。毕竟，颜色本身不会因名称不同而改变。

同样地，这份许可证之所以有效，是因为所有人都认为它有效(考虑到意图等因素)。这些包的作者或贡献者(其他人没有法律地位这样做)起诉我们分发此代码的可能性是……嗯……我怀疑如果你想让律师发笑，你大可以问问他们。

大约在这个时候，皮埃尔·乔伊(Pierre Joye)促使pecl-dev邮件列表讨论这些问题，他说：“Debian开始要求更改PHP扩展的PHP许可证，理由是PHP许可证仅适用于PHP本身。”67)

该完整讨论串可在PHP邮件列表网站上查看：https://news-web.php.net/php.pecl.dev/11927#:~:text=Thread,-(27%20messages

詹姆斯·韦德将讨论带到了php-qa邮件列表，他说：“似乎对PHP许可证存在一些误解。”68) 随后他问道：

1. 《PHP 许可证，版本 3.01》是否是经开源倡议组织(OSI)认证的开源许可证？其官网仅列出《PHP 许可证 3.0(PHP-3.0)》。
2. 《PHP 许可证，版本 3.01》何时发布？
3. 《PHP 许可证，版本 3.01》是否可用于 PHP 自身以外的其他用途？
4. 将项目从《PHP 许可证，版本 3.01》更改为 LGPL 或 BSD 许可证是否存在法律影响？
5. PHP 许可证是否足够清晰，以确保其正确应用于扩展？
6. 为什么(Apache风格的)PHP许可证会被Debian列为“严重违规”，而Apache许可证却没有？

此讨论在pecl-dev邮件列表中继续，该列表可在PHP邮件列表网站上找到：https://news-web.php.net/php.pecl.dev/12091#: ~:text=Thread,-(32%20messages

在该线程中，Walter Landry 对 Ángel González 的回应中感叹道：69)

Ángel González 写道：

为了保持 PHP 许可证的精神并同时解决严格的解释问题，我提议对 PHP 许可证 3.01 进行以下修改，希望这能让双方都满意：

停下。请停下。请选择一个现有的、广为人知的许可证，这样我们就不必再次争论这是否真的解决了所有问题。

长时间的讨论并未对PHP许可证做出任何修改，Debian团队就PHP许可证授权的软件发表了官方立场，其中指出：70)

PHP 许可证是一份版权许可证，试图超越版权法赋予的权利——它试图控制“PHP”这一术语的使用。

[…]

该许可证要求我们做出以下声明： “本产品包含可从http://www.php.net/software/免费获取的PHP软件”，我们无法验证该声明的真实性，亦不对该链接的维护负责。该许可证还包含可能在某些情况下不准确的免责声明，但所有这些不一致均源于其起草设计。

2020年，关于PHP许可证版本3.01是否获得OSI批准的问题再次在php-general邮件列表中提出，PHP项目通过与OSI进行正式的许可证批准流程解决了这一问题。

OSI关切

2003年5月，Lerdorf提交了PHP许可证版本3.0的正式批准请求。71)尽管邮件列表对他的请求保持沉默，但他于2003年6月3日回应称，已收到要求使用另一种许可证的回复。72)

到目前为止，除了建议我们使用另一种许可证的回复外，没有其他回复。使用另一种许可证不是一个选项，因为这是代码多年来一直发布的许可证，而我需要 OSI 批准的许可证的是已经发布的代码。我无法回到过去，将该代码在另一种许可证下发布。

大卫·约翰逊于6月4日回复：73)

我对该许可证的唯一问题是第4条的措辞(而非意图)，以及第6条的已知问题。但这两者均不会使该许可失去开源资格。既然您已在此许可下发布代码，建议修改已无意义。

当拉姆齐于2020年寻求OSI对PHP许可3.01版本的批准时74)，类似担忧再次被提出：

• “该许可证及其前身PHP许可证3.0是否符合OSD，特别是OSD 3？”75)
• “请注意，该限制不仅适用于他们的商标(无论是普通法商标还是其他类型)。它试图排除比这更广泛的原产地标识范围，并对这些标识的表达方式设置限制。这是一种对版权授予范围的限制，意味着他们可能主张因使用一种他们无权根据商标法强制执行的命名 convention 而构成版权侵权。” 我特别指的是许可限制中关于‘未经事先书面许可，不得在名称中使用‘PHP’’的部分。”76)
• “第6条在我看来带有徽章软件的特征，尽管徽章软件与可接受的作者致谢之间的界限可能有些模糊。或许因为它未要求该信息的显示位置或方式(参见BSD 4条款)，因此属于非徽章软件的一方。” 77)
• “或者，假设Ceph项目创建了一个与Kubernetes相关的项目，名为‘cephpod’，并且出于某种奇怪的原因，它使用了PHP许可的可版权代码片段。我认为这是FSF所担忧的场景，即命名限制变得不合理，从而导致该许可证被判定为与GPL不兼容，尽管我目前无法立即找到支持这一观点的依据。”78)
• “好消息是您已经拥有升级条款。您可以行使该条款并创建不包含命名限制的PHP许可证3.02。”79)
• “您可能考虑的一个激进想法是通过升级使许可证失效。你可以行使第5条条款，将其修订为PHP许可证3.02，与BSD-3许可证完全相同。一位精明的律师可能知道如何最好地实现这一点。其他项目在没有命名条款或看似冗余的归属条款的情况下也能正常运行。”80)
• “这是否意味着，任何使用PHP许可证的PHP扩展作者——或者甚至一些与PHP完全无关但使用PHP许可证的软件——可以将PHP的商标使用视为对许可证的违反，而这种情况与我认为这些许可证所预期的情况相比是否合适，即许可证颁发者也应该是商标所有者？” 81)
• “Apache软件许可证1.1版和OpenSSL许可证中也存在类似条款，可能还有其他同年代的宽松许可证。然而，第二句话可能仅在PHP许可证中独有。”82)

“那个麻烦的条款”

1999 年，Lerdorf 将 Apache 软件许可证 1.1 作为 PHP 许可证的模板，并承认其中有一个无法执行的麻烦条款。83)

我们的许可证与 Apache 许可证完全相同(因为我们就是从那里复制的)，除了第一个条款。所以，不，我们没有提出任何东西，除了那个无法执行的麻烦条款。

这指的是 PHP 许可证 1.0 版本的第 1 条，其中规定：

商业分发基于 PHP 衍生的大型作品，或与 PHP 打包的作品，需要获得 PHP 开发团队的书面许可。您可以对复制的物理传输行为收取费用，并必须明确说明所收取的费用是针对分发行为，而非软件本身。您可以选择提供保修服务以换取费用。

该条款首次出现在随 PHP 3.0.0 一起发布的全新许可证中，并在 PHP 3.0.14 中被移除，此后 PHP 许可证才开始版本化。

术语

本文件中的一些术语可能需要额外说明：

• PHP 项目：本文件使用“PHP 项目”一词，而非更狭义的“PHP 内部”或“PHP 核心”，以涵盖 PHP.net 旗下所有内容的更广泛范围。
• PHP 软件：PHP 软件指的是 PHP 编程语言的参考实现，位于 https://github.com/php/php-src。
• Zend 引擎：Zend 引擎作为 PHP 软件的一部分，位于 Zend/ 目录下，可在 https://github.com/php/php-src/tree/master/Zend 找到。

本文文字及图片出自 PHP RFC: PHP License Update

你也许感兴趣的：

• PHP 8.4 新增 DOM Selector 功能使用说明
• 使用 PHP 8.4 新 DOM Selector 解析 HTML
• 【外评】严重 PHP 漏洞使服务器面临远程代码执行风险
• PHP 不再糟糕
• 短短两年使用率下滑 40%！曾经风靡全球的 PHP 为何逐渐失去优势？
• 短短两年使用率下滑 40%！曾经风靡全球的 PHP 为何逐渐失去优势？
• PHP 8.3 正式发布的主要变化
• PHP 8：类型系统改进
• 为什么在 20 多年后，我仍然爱着 PHP 和 JavaScript
• 全球 77.5% 的网站，都在使用“世界上最好的语言” PHP！