17611538698
info@21cto.com

PHP 9.0 将更换到 BSD 许可证

开源 0 10 1天前
图片

导读:PHP 9.0 将采用 3 条款 BSD 许可证发布,以取代 PHP 双许可证 v3.01 和 Zend 引擎许可证 v2.0。

php.internals 上的投票已于 4 月 4 日结束,PHP 9.0 将采用 3 条款 BSD 许可证。

这项由 Ben Ramsey 推动的 RFC 提案,用一个搁置了 35 年之久的、符合 OSI 和 FSF 标准且兼容 GPL 的宽松许可证,取代了PHP 许可证 v3.01Zend Engine 许可证 v2.0

这是一个明智的决定,但一个有意思的问题是:为什么花了这么长时间?

PHP 实际交付的是什么


自 Zend Engine 在 PHP 4 中引入以来,PHP 一直采用两种不同的许可证进行分发。大部分源代码——运行时、扩展和解释器框架遵循 PHP 许可证 v3.01。而 Zend Engine 目录Zend/里则遵循 Zend Engine 许可证 v2.0。

开源软件联盟 (OSI) 认可前者,但不认可后者。这意味着,作为全球部署最广泛的语言之一的权威实现,PHP 一直以来都在使用一种并非 OSI 所定义的开源许可证发布其大量源代码。

PHP 许可证本身也是一份定制文件。它包含一条禁止认可条款、一条名称限制条款(“衍生自本软件的产品不得称为‘PHP’……”)以及一条关于合理使用条款,该条款含糊地暗示了“PHP”出现在衍生名称中。

这些条款的存在大多出于完全合理的历史原因——PHP 项目不希望在 2002 年出现一个名为 PHP++ 的分支,造成混乱——但这同时也意味着下游打包者花了二十年时间,针对几乎无人使用的许可证进行许可兼容性计算。发行版可以处理这个问题,但律师们对此并不乐见。

为什么选择三条款 BSD?


BSD 三条款许可证——有时也称为修改版 BSD 许可证新 BSD 许可证,这是一种宽松的许可证,允许使用、修改和重新分发,要求在源代码和二进制分发中保留署名,并禁止未经许可使用贡献者或项目的名称来支持衍生作品。最后一条的款项几乎完全实现了 PHP 名称限制条款试图实现的功能。

著名的四条款版本,其中包含令人反感的广告条款(“所有提及本软件功能或用途的广告材料必须显示以下声明……”),于1999年被伯克利大学自行弃用,因为没人能记住声明中必须出现的所有名称。

而双条款版本则完全删除了禁止认可条款。

三条款版本则折中方案:简短、宽松、可归因,并设有合理的商标邻近限制。如果您不想再为许可协议操心,那么三条款版本就是您的理想之选。

这便是 PHP 刚刚采取的措施——已经不再考虑许可证的问题了。

关于 PostgreSQL 的题外话


PostgreSQL 采用PostgreSQL 许可证发布,该许可证是另一种自定义的宽松许可证——由几段源自 BSD 许可证族的条款组成,允许使用、修改和分发,并声明不提供任何担保,不包含广告条款、名称限制条款和代言条款。从功能上看,它就是语言更友好的双条款 BSD 许可证。

你可能会问,为什么我们不直接使用双条款 BSD 许可证?答案是,该许可的出现时间早于这种区分的最终确定,甚至早于 OSI 成立的大部分时间。PostgreSQL 全球开发组目前不会再为一个已经运行了三十年且运行良好的方案重新争论。所有发行版、所有云厂商以及所有曾经审阅过该许可的法务部门都对此许可非常了解。虽然 OSI 并未将其认定为指定许可,但 OSI 认为它在功能上等同于宽松的 BSD/MIT 式许可,而且也从未有人提出过任何反驳的有力论据。

PHP其实可以效仿PostgreSQL的做法:保留自定义许可证,修复缺陷,依靠社区的善意和三十年来始终如一的实践。虽然没有这样做,但他们的选择是正确的。PostgreSQL之所以能够成功,是因为其许可证始终前后一致,始终由成熟的开发者编写,并且始终在功能上符合宽松的BSD风格许可证。PHP许可证加上Zend许可证则完全不具备这些优势,当企业法务团队不得不质疑Zend Engine许可证v2.0是否符合OSI标准时,整个方案的存亡就岌岌可危。

为什么这些很重要


2024 年至 2026 年的趋势大多相反:许多项目放弃了 OSI 认可的许可证,转而采用源代码公开的许可证——Redis、HashiCorp、Elastic 和 MongoDB 等项目都曾这样做过。

PHP 的这种转变提醒我们,标准许可证的吸引力是双向的。

如果你今天还在编写自己的开源许可证,那么到了 2026 年,你几乎肯定不应该再这样做了。如果你仍然在使用 OSI 成立之前专门为你的项目编写的许可证来发布软件,那么 PHP RFC 就是一个模板。找到与你的自定义许可证功能最接近的标准许可证,采用它,然后继续前进。

PHP 团队刚刚为打包者们解决了一大类许可问题,而他们付出的代价仅仅是一次投票和一次提交。

如果你维护的项目仍然使用自定义许可,那么计算方法也完全相同。

作者:大雄

评论

我要赞赏作者

请扫描二维码,使用微信支付哦。

分享到微信