GNU General Public License v2.0

许可·条件·限制一览

许可·条件·限制分类来源：choosealicense.com（GitHub，MIT 许可证）数据。

这是什么样的许可证

GPL-2.0 是 FSF 于 1991 年 6 月发布的 GPL 第二版。其著佐权原则与 GPL-3.0 相同：分发包含或结合了此代码的程序时，必须以 GPL-2.0 连同源代码一起提供整个程序。代表性案例有 Linux 内核（GPL-2.0-only，部分头文件带有 syscall 例外）、Git（GPL-2.0-only）、WordPress（GPL-2.0-or-later）。

only 与 or-later

使用 GPL-2.0 的项目通常会在两者中选择其一。

• GPL-2.0-only：只能按此版本的条件分发。Linux 内核采用这种方式，因此无法迁移到 GPL-3.0。
• GPL-2.0-or-later：接收者可以选择 2.0 或 FSF 此后发布的版本（3.0 等）。GPL 原文建议的声明就是这种方式。

原文第 9 条规定，未指定版本号的程序可以选择 FSF 发布的任何版本。因此，通过文件头或 SPDX 标识符明确说明是哪一种非常重要（指南）。

分发时须遵守的事项

• 随附提供源代码，或以至少 3 年有效的书面要约提供（第 3 条）。
• 保留版权声明、无担保声明和许可证副本（第 1 条）。
• 在修改过的文件中标明修改事实和日期（第 2 条 a 项）。
• 不得对接收者的权利附加额外限制（第 6 条）。如果因专利协议等原因无法遵守 GPL 条件，则根本不得分发（第 7 条）。

常见误解

• 「GPL-2.0 和 GPL-3.0 都是 GPL，可以混用」 — GPL-2.0-only 代码与 GPL-3.0 代码不能结合分发。两者中必须有一方是「or later」。
• 「也可以放入 Apache-2.0 代码」 — FSF 认为 Apache-2.0 与 GPL-2.0 不兼容。如果是「or later」项目，可以通过以 GPL-3.0 分发来解决。
• 「没有专利条款，所以可以行使专利」 — 虽然没有明确的专利许可，但第 7 条和序言包含了防止以专利限制自由的分发的宗旨。解释存在分歧，如果专利很重要，请考虑 GPL-3.0。

如何应用

将原文原样放在 LICENSE 或 COPYING 中，并在每个文件中加上官方声明。保留声明中「either version 2 of the License, or (at your option) any later version」一句即为 or-later，删掉则为 only。SPDX 标识符使用 GPL-2.0-only / GPL-2.0-or-later。

适用场景

对于 Linux 内核模块这类需要与 GPL-2.0-only 生态交换代码的项目，它是必需的。如果新项目以强著佐权为目标，专利条款和兼容性都有所改进的 GPL-3.0 或「GPL-2.0-or-later」会更灵活。

GPL-2.0 代码能放进其他项目吗？

以下是将以此许可证发布的代码合并到下列许可证的项目中一起发布时的一般判定。 在兼容性检查器中查看其他组合 →

本网站内容仅为一般信息，不构成法律意见。实际发布、合同或纠纷的判断，请咨询律师等专业人士。