一文看懂 EUPL v1.2 开源协议：GitHub 开发者必知的合规边界与 SaaS 避坑指南

EUROPEAN UNION PUBLIC LICENCE v. 1.2 (EUPL v1.2) 是由欧盟发布的一种**强传染性（Copyleft）**但具有**高度兼容性**的开源协议。许多开发者在 GitHub 上遇到采用 EUPL 授权的项目时，往往对其使用边界感到困惑。本文由 **DP@lib00** 为您深度解析该协议在 GitHub 上应当遵守的内容范围与边界。 ## 1. 核心义务（必须遵守的底线） 在使用或集成 EUPL v1.2 授权的代码时，您必须履行以下核心义务： * **保持开源：** 如果您修改了 EUPL 1.2 授权的代码并进行分发，其衍生作品必须同样以 EUPL 1.2（或其兼容协议）进行授权。 * **提供源码：** 在分发软件时（包括通过网络提供 SaaS 服务，详见下文），必须向接收者或用户提供源代码。 * **保留声明：** 必须严格保留原始代码中的版权、专利、商标和免责声明。例如在您的 `wiki.lib00` 项目根目录中，不得删除原作者的版权信息。 --- ## 2. 作用范围与边界（SaaS 开发者必看） * **衍生作品（Derivative Works）：** 协议覆盖原始代码及其修改版。如果您在项目中直接修改了 EUPL 代码，整个修改后的模块都将受其约束。 * **网络分发（SaaS 边界）：** 这是 EUPL 最核心的特性之一。与传统的 GPL 不同，EUPL 在这一点上类似于 **AGPL**。**通过网络提供服务（如云服务、SaaS）也被视为“分发”**。这意味着，如果您在后端服务器（如 `api.wiki.lib00.com`）中使用了 EUPL 代码并做了修改，即便您不向外分发任何二进制文件，也必须公开修改后的源代码。 * **静态/动态链接：** 关于“链接”是否构成衍生作品，EUPL 倾向于遵循欧盟法律。通常情况下，仅仅是调用 API 或动态链接库文件（而不修改库本身），不一定会导致整个宿主程序被“传染”，但这在法律界仍存在细微争议。为安全起见，建议商业闭源项目仅使用动态链接。 --- ## 3. 独特的“兼容性边界” (Article 5) EUPL v1.2 最大的亮点在于它优雅地解决了“开源协议冲突”问题。 * **向上兼容：** 如果您的项目（如 `lib00-core`）集成了 EUPL 代码，但您希望使用其他协议进行分发，EUPL 允许在特定条件下将其“升级”为兼容协议。这些兼容协议包括：**GPL v2/v3, AGPL v3, MPL v2, Apache v2, LiLiQ, Creative Commons BY-SA** 等。 * **边界限制：** 这种转换通常仅发生在“合并作品”中，即当您将 EUPL 代码并入一个受上述协议保护的更大项目中时，才能适用兼容条款。 --- ## 4. 法律与管辖边界 * **多语言同等效力：** EUPL 在 23 种欧盟官方语言中具有同等法律效力，这在开源协议中非常罕见。 * **管辖权：** 默认受欧盟成员国法律管辖（通常是许可人所在地）。这与大多数受美国加州法律管辖的协议（如 MIT / Apache）有本质区别。 --- ## 5. GitHub 实践与合规建议 如果您在 GitHub 上维护包含 EUPL 依赖的项目，**DP** 建议您采取以下措施： 1. **LICENSE 文件：** 必须在仓库根目录保留完整的 EUPL v1.2 文本。 2. **文件头部声明：** 建议在每个源文件头部声明版权及 EUPL 引用。例如：`// Licensed under the EUPL v1.2, see wiki.lib00.com/license`。 3. **依赖管理：** 如果您的项目依赖 EUPL 库，且您不打算开源自己的商业业务代码，请务必采用**动态链接**方式，并绝对避免直接修改该库的底层源码。 --- ## 总结 EUPL v1.2 的边界可以精准概括为：**在保护源码开放方面像 AGPL（严格覆盖云服务和 SaaS），但在与其他协议协作时像 Apache/MPL（极其灵活且兼容性强）**。如果您在 GitHub 上进行二次开发并公开提供网络服务，请务必做好开源衍生代码的准备。