本文目录导读：
这是一个非常专业且重要的问题，在PHP开源项目中，选择合适的开源协议并确保合规，不仅关系到法律风险，还直接影响项目的生态、商业模式和社区贡献。
下面从协议选择、常见协议详解、合规实践以及针对PHP项目的特殊注意事项四个维度进行详细拆解。
如何选择开源协议？
选择一个协议,本质上是在回答三个问题：
- 允许商业化吗？ 别人能否打包你的代码去卖钱？
- 允许闭源/私有化修改吗？ 别人修改代码后,是否可以不给任何人看？
- 要求“传染”吗？ 如果别人用了你的库,他的整个项目也必须开源吗？
决策速查表：
| 你的目标 | 推荐协议 | 核心约束 |
|---|---|---|
| 极简主义，允许别人随意使用、修改、闭源 | MIT | 仅需保留版权声明 |
| 允许闭源，但要求修改过的文件必须声明 | Apache 2.0 | 保留声明 + 专利条款 |
| 如果别人修改了代码，修改部分必须开源 | LGPL | 动态链接无需开源，静态链接需开源修改 |
| 强迫所有使用你代码的项目都开源 | GPL v3 / AGPL v3 | 强传染性，AGPL针对网络服务 |
| 保护自己，禁止别人用你的名字做推广 | 所有主流协议 | 均有此条款（如Apache 2.0） |
| 完全是个人学习项目，无所谓 | MIT | 最友好，无后顾之忧 |
五大常见PHP开源协议详解
MIT 协议 （Massachusetts Institute of Technology）
- 特点： 最宽松、最简短。
- 允许： 商用、分发、修改、私有化、Sublicense（再许可）。
- 要求： 必须在所有副本中保留版权声明和许可声明。
- 适合： Composer包、框架组件、工具库、入门级CMS。
- PHP示例： Laravel、Symfony Components、Monolog、PHPUnit。
Apache License 2.0
- 特点： 同样宽松，但比MIT多了一个专利授权条款。
- 允许： 几乎与MIT相同。
- 要求： 保留版权声明 + 声明修改的文件（NOTICE文件）。
- 适合： 需要专利保护的企业级项目。
- PHP示例： 许多大型企业框架（如 Zend Framework 的某些部分）。
GPL v3 （GNU General Public License）
- 特点： 强传染性（Copyleft），任何包含GPL代码的衍生作品,也必须以GPL发布。
- 核心逻辑： 你如果发布了包含GPL代码的软件,那么整个软件都必须开源。
- 典型冲突： 在WordPress生态中，主题/插件如果使用了GPL代码，必须开源，这也是为什么WordPress强制所有主题/插件使用GPL的原因。
- 适合： 希望代码永远开源的社区项目,或反商业闭源的项目。
- PHP示例： Drupal（核心）、WordPress（核心）、Magento。
LGPL （GNU Lesser General Public License）
- 特点： “弱”传染性，允许通过动态链接（在PHP中通常是
include或require）使用,而无需开源主程序。 - 核心差异： 如果修改了LGPL库本身，修改必须开源，但如果只是调用它,可以闭源。
- 适合： 高质量的库（Library）,希望被广泛使用的工具。
- PHP示例： PHP官方扩展（如
ext/ldap）、部分PHP客户端库。
AGPL v3 （GNU Affero General Public License）
- 特点： 网络服务版GPL，GPL的漏洞在于：如果软件运行在服务器上（SaaS），用户不下载代码，就不需要开源，AGPL堵住了这个漏洞——即使通过网络使用（不下载）,也必须开源。
- 适合： 在线服务、网络API、SaaS平台组件。
- PHP示例： Nextcloud（文件同步）、Moodle（学习管理系统）。
PHP项目的合规实践（实操指南）
代码层面
- 文件头注释： 每个
.php、.js、.css文件头部应包含如下注释：<?php /** * 项目名称 * * @license MIT * @link https://github.com/your/project * @author Your Name * @copyright 2023 Your Organization */
- LICENSE文件： 在项目根目录放置一个纯文本的
LICENSE粘贴对应协议全文。 - Composer.json申明： 在
composer.json中明确声明协议：{ "name": "vendor/project", "license": "MIT" // 或 "GPL-3.0-or-later", "Apache-2.0", "LGPL-2.1-only" 等 }
依赖管理（License Compliance Scanning）
这是最容易踩坑的地方，你项目用了100个Composer包，只要其中一个是GPL/AGPL,就可能污染整个项目。
-
检查工具：
composer license（需要composer/composer）：直接在终端运行,列出所有依赖的协议。FOSSA（fossa.com）： 免费为开源项目提供扫描,自动识别冲突。WHODID（github.com/composer/whodid）： 查看依赖的协议。- 自动化CI： 在GitHub Actions中集成扫描,强制非合规的PR无法合并。
-
常见冲突场景：
- 你的项目是闭源商业软件，但
composer install了一个GPL v3的库 → 违法（必须开源整个项目）。 - 解决方案： 替换为MIT或Apache 2.0的替代库；或者购买该库的商业授权；或者将GPL库封装为独立的微服务（通过网络API调用，而非代码集成）。
- 你的项目是闭源商业软件，但
专利与商标合规（针对Apache 2.0）
- 专利： 如果你向Apache 2.0项目提交了代码，视为你授予了该项目一个专利许可,这在公司内部需要法务确认。
- 商标： 你不能使用项目名（如“Laravel”）来推广你的衍生作品，除非获得授权，常见做法是说明“基于Laravel”。
修改与衍生作品（针对GPL/LGPL）
- GPL： 如果你修改了
WordPress核心代码（哪怕一行），并公开发布,你的修改必须以GPL发布。 - LGPL： 如果你修改了
phpMyAdmin，你的修改必须开源，但如果只是通过include调用phpMyAdmin的某个类,主程序可以闭源。 - WordPress主题/插件注意： WordPress官方要求所有主题和插件必须使用GPL（v2或更高版本），这是因为他们认为通过API调用了WordPress核心（GPL），就构成了衍生作品，这是一个争议话题,但实践上建议遵守。
针对PHP项目的特殊注意事项
Composer 与双重许可
许多PHP库（尤其是商业友好的）采用双重许可（Dual Licensing）。
- 示例： MySQL、PHPOffice/PHPExcel。
- 规则： 如果你是个人或小非营利组织，可以免费使用（GPL），如果你是商业公司且不想开源自己的代码,必须购买商业许可。
- 操作： 使用
composer require前，务必检查项目根目录是否有LICENSE文件或README中的说明。
PHP 代码的动态与静态链接
PHP是解释型语言，没有传统编译语言的“静态链接”,但在PHP生态中：
- “动态链接” ≈ 运行时加载：
require_once一个库类。 - “静态链接” ≈ 代码复制/修改：将库代码直接粘贴到自己的框架中,或对库进行深度定制。
对于LGPL库，通过Composer的自动加载（动态链接）使用，通常被认为是合规的，你的主项目可以闭源，但如果你修改了LGPL库的源代码,必须开源这些修改。
Docker 与容器部署
如果你的PHP项目打包成Docker镜像发布：
- 镜像中的代码（包括Composer依赖）的协议依然适用于镜像使用者。
- 如果你在镜像中包含了GPL软件（如
ffmpeg），整个镜像理论上应遵守GPL，但实践中，容器化部署（用户仅运行而不分发）可能绕开此限制,建议咨询法务。
Readme 与声明
- 如果你的项目使用了Apache 2.0或LGPL库，请在你的
README.md中添加一行：This project uses [Library Name] licensed under Apache License 2.0.
给PHP开发者的建议
| 场景 | 推荐协议 |
|---|---|
| 个人小工具、学习项目 | MIT |
| 开源框架（希望被采用） | MIT 或 Apache 2.0 |
| 企业级商业组件（需专利） | Apache 2.0 |
| CMS或社区项目（强版权） | GPL v2 或 GPL v3 |
| 高质量库（希望被闭源使用） | MIT 或 LGPL |
| 网络API/SaaS组件（拒接云薅羊毛） | AGPL v3 |
最后的建议：
- 永远不要忽视
composer.json中的协议声明。 - 如果你的项目是商业闭源的，在
composer require任何包之前，先运行composer license扫描。 - 国际法律问题，请务必咨询法务（特别是涉及专利、商标或AGPL时），以上信息为通用建议,不构成法律意见。
