PHP 怎么许可合规

本文目录导读：

1. 核心：PHP 本身（PHP Runtime）的许可
2. 重点：第三方库与 Composer 依赖（多数合规问题的来源）
3. 特殊场景：PHP 扩展（Extension）的许可
4. 特别注意事项（针对中国开发者的“高危红线”）
5. 实战：如何构建合规的 PHP 项目（操作步骤）
6. 核心结论

在 PHP 中谈“许可合规”，通常涉及三个层面：代码版权（License）、运行时环境（Runtime） 以及分发（Distribution），绝大多数时候，开发者担心的其实是“我用了别人的代码库，会不会被告”以及“我写的代码要不要开源”。

以下是 PHP 许可合规的全面指南,按场景分类：

核心：PHP 本身（PHP Runtime）的许可

• 许可证：PHP 使用的是 PHP License 3.01（或 MIT License（部分版本和扩展）。
• 合规要点：PHP 许可证是宽松的，允许闭源商业使用，你可以自由地用它开发商业软件、出售软件，甚至修改 PHP 引擎,只要你保留版权声明即可。
• 使用 PHP 语言本身做任何项目，都不强制开源，也不强制付费。

重点：第三方库与 Composer 依赖（多数合规问题的来源）

这是最容易踩坑的地方，当你使用 composer require 引入第三方包时，必须检查它们的 LICENSE 文件。

常见的许可证类型与义务：

• MIT / BSD / Apache 2.0（宽松）：可以闭源商用，必须保留原作者的版权声明（在源码中或依赖清单中）。
• GPL / AGPL（强传染性）：如果使用 GPL 库，你的代码可能必须开源，且以 GPL 协议发布。
  • 特别提醒：AGPL（如某些数据库驱动或 SaaS 库）要求即使以 Web 服务形式提供（不分发软件），也必须开放源码，如果做 SaaS 产品，强烈建议避开 AGPL 依赖。
• LGPL（弱传染）：如果你通过动态链接调用（如 PHP 扩展），通常可以闭源；如果修改了库本身,则需要开源修改部分。

合规操作清单：

1. 检查依赖树：运行 composer licenses 查看当前项目的所有依赖及其许可证。
2. 确认是否分发：
   • 如果你只是部署在服务器上（不向用户分发代码），GPL 通常不触发传染（但 AGPL 会触发）。
   • 如果你将代码打包出售、提供给客户作为成品（如提供压缩包源码、交付给第三方），GPL 就会强制要求整体开源。
3. 保留版权声明：即使使用 MIT 库，也必须在下游（如 vendor/ 目录或 THIRD_PARTY_NOTICES 文件中）保留所有 License 文件。

特殊场景：PHP 扩展（Extension）的许可

• PECL 扩展：多数是 PHP License 或 MIT,允许商用。
• 商业扩展（如 IonCube Loader、某些性能优化插件）：这些是闭源的，使用时需购买商业授权，且不能将其包含在你的分发包中（通常只允许在目标服务器上安装）。

特别注意事项（针对中国开发者的“高危红线”）

A. 禁止篡改版权信息

• 哪怕你只改了别人开源项目的一个变量，只要保留了原作者版权，你就不能删除或覆盖原作者的版权声明。“换皮”不代表能消除版权。

B. 避免“云原生”陷阱（SaaS / API 服务）

• 如果你开发的是 API 接口供别人调用，你只是在服务器端运行，这时 GPL 库通常不传染，但 AGPL 库会强制你将整个服务开源，如果你不想开源，在 composer.json 中务必备注 "license": "proprietary"，并筛选掉 AGPL 依赖。

C. 字体、图片和模板

• 合规检查不仅限于 .php 文件，包含在项目中的 字体（.ttf/.woff）、富文本编辑器、CSS 框架 也有各自的许可（如 SIL OFL、CC-BY），如果你在商业模板中使用了免费许可的字体,需要保留属性声明。

实战：如何构建合规的 PHP 项目（操作步骤）

1. 设立“许可白名单”：在团队规范中，只允许使用 MIT、BSD、Apache、PHP License、ISC，禁用 AGPL，谨慎使用 GPL/LGPL。
2. 使用工具扫描（推荐）：
   • composer licenses：手动查看。
   • FOSSA 或 Snyk（接入 CI/CD）：自动扫描第三方依赖的漏洞和许可证不合规问题。
3. 生成“第三方依赖清单”：在项目根目录维护一份 THIRD-PARTY-LICENSES.md，列出每个依赖的版权方和许可证链接，发布商业产品前,让法务审核此文件。
4. 备份（极少用但重要）：如果你的商业项目不可避免地使用了 GPL 类代码库来避免 AGPL 传染，可以考虑将 GPL 部分剥离为独立命令行工具或独立微服务，通过 shell_exec() 或 HTTP API 调用，实现进程隔离，避免 GPL 代码与你的代码发生“模块融合”。

核心结论

• 用 PHP 写代码，免罪：PHP 语言本身不会导致你必须开源。
• 用 Composer 包，要审查：这是唯一真正需要担心的地方。
• 做 SaaS / API 服务：默认避开 AGPL。
• 做源码分发/交付：确保所有依赖都是宽松许可证,且保留了所有版权声明。

只要做好“依赖许可证审计”和“版权声明保留”这两步，你的 PHP 项目就是完全合规的，如果在公司内部，建议拉起项目管理或法务做一个简单的许可证审批表,万事大吉。