PHP项目开源协议与合规

wen PHP项目 2026-07-21 92

本文目录导读：

PHP项目开源协议与合规

如何选择开源协议？
五大常见PHP开源协议详解
PHP项目的合规实践（实操指南）
针对PHP项目的特殊注意事项
给PHP开发者的建议

这是一个非常专业且重要的问题，在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