![[GNU 头像]](/graphics/heckert_gnu.transp.small.png){kind=small}
GNU ![[Search www.gnu.org]](/graphics/icons/search.png){kind=icon}
![[Other languages]](/graphics/icons/translations.png){kind=icon}
为了明确起见，请不要说“在 GNU GPL 2 下许可”！
作者：Richard Stallman1989 年，当我编写 GNU 通用公共许可证 (GNU GPL) 时，我意识到可能需要进行更改：FSF 有朝一日可能会有理由发布新版本。所以我将该许可证称为“版本 1”，并建立了一个框架，使用户能够将程序升级到以后的许可证版本。
使用自由许可证这样做没有惯例的方式；据我所知，以前从未这样做过。开发人员已经以不同的许可证发布了程序的新版本，也许他们已经发布了旧版本的新版本，提供了在不同许可证下使用的选择，但他们从未建立一个系统化的方法来为用户提供选择使用程序的已发布版本的未来许可证版本的机会。
我不知道开发人员会如何回应这项创新，因此我决定让每个开发人员选择是否允许未来的版本。这意味着开发人员可以仅在 GNU GPL 版本 1 下发布程序，或者在 GPL 版本 1 或任何后续版本下发布。开发人员声明他们的选择的方式是在每个源文件开头的许可证声明中。GPL 中规定了做此决定的方式。
自由软件基金会敦促开发人员选择“或任何后续版本”，因为这意味着用户可以自由地在 GNU GPL 版本 1 下使用该程序，或者在版本 2 下（一旦有版本 2），或者在版本 3 下（一旦有版本 3）。如果我们需要制作版本 4，他们也可以自由地在版本 4 下使用它。
此后，FSF 分别在 1991 年和 2007 年发布了 GNU GPL 版本 2 和版本 3。每个版本都允许开发人员选择坚持仅使用一个许可证版本，或者允许在未来的许可证版本下使用。（GPL 3 还允许“代理”选项，其中指定的网页可以随后允许使用特定的未来版本。）
发布具有许可证升级权限的程序对于避免在不同 GPL 版本下发布的程序之间的不兼容性至关重要。
在没有任何明确的兼容性机制的情况下，两个不同的版权许可证几乎不可避免地会不兼容。这是因为每个许可证都必然要求程序的修改版本以相同的许可证发布。因此，仅在 GPL 版本 2 下发布的代码不能与仅在 GPL 版本 3 下发布的代码合并。
GPL 版本之间兼容性的机制是在“版本 N 或任何后续版本”下发布程序。在 GPL-2.0 或更高版本下发布的程序可以与在 GPL-3.0 或更高版本下发布的代码合并，因为“3 或更高版本”是“2 或更高版本”的子集。
一些开发人员说：“我现在将仅在 GNU GPL 版本 3 下发布。当我看到 GPL 版本 4 时，如果我喜欢它，我将重新许可我的程序以允许在版本 4 下使用。” 如果您是唯一作者，并且在当时仍然活着、健康、可以联系到并注意到，这将会很好地工作。但是，如今的版权持续的时间异常长；在没有重大改革的情况下，您代码的版权在美国将在您去世后持续 70 年（在墨西哥为 100 年）。您是否已安排您的继承人考虑是否将您的代码重新许可为 GPL 版本 4，如果您已经不在世时能够考虑它？
但是即使在您在世的时候，也会发生麻烦。如果我们十年后发布 GNU GPL 版本 4，到那时，由于您这样做，其他 50 个人已经向您的程序添加了内容，他们只是在 GPL-3.0-only 下发布了他们添加的代码，该怎么办？您可以批准您最初发布的程序的 GPL 4，但那时联系 50 位后续开发人员以获得他们对其添加内容的 GPL 4 使用许可将是一项艰巨的任务。
避免这些问题的方法是在一开始就批准许可证声明中的未来 GPL 版本。请在源发布的每个非平凡文件中添加如您正在使用的 GPL 版本末尾所示的许可证声明。
由于我们以这种方式处理许可证兼容性，当人们告诉您一个程序是“在 GNU GPL 版本 2 下”发布时，他们并没有明确该程序的许可。它是在 GPL-2.0-only 下发布的，还是在 GPL-2.0-or-later 下发布的？ 您可以将代码与在 GPL-3.0-or-later 下发布的软件包合并吗？
当 GitHub 等网站邀请开发人员在其他许可证选项中选择“GPL 3”或“GPL 2”，并且没有提出未来版本的问题时，这会导致数千名开发人员的代码许可不明确。要求这些用户在“仅”和“或更高版本”之间进行选择将使他们明确其代码的许可。它还提供了一个机会来解释后一种选择如何避免未来的不兼容性。
诸如“GPL-2.0”或“GPL-3.0”之类的缩写许可证指示符也会导致混淆。不了解“2 only”和“2 or later”之间区别的人和组织，在两种情况下都倾向于写“GPL-2.0”，而没有意识到需要做出区分。
因此，当您使用 SPDX 许可证指示符时，请使用这些
- GPL-2.0-only 或 GPL-2.0-or-later
- GPL-3.0-only 或 GPL-3.0-or-later
- LGPL-2.0-only 或 LGPL-2.0-or-later
- LGPL-2.1-only 或 LGPL-2.1-or-later
- LGPL-3.0-only 或 LGPL-3.0-or-later
- AGPL-3.0-only 或 AGPL-3.0-or-later
- GFDL-1.3-only 或 GFDL-1.3-or-later
请勿使用旧的、模棱两可的许可证指示符，它们将被弃用
- GPL-2.0
- GPL-3.0
- LGPL-2.0
- LGPL-2.1
- LGPL-3.0
- AGPL-3.0
- GFDL-1.3。
在 1989 年，似乎必须让开发人员选择 GPL 版本“1 only”或 GPL 版本“1 or later”，但这造成了一种我们本可以避免的复杂性。与此同时，一些无条件地让用户可以选择升级到以后的许可证版本的许可证已得到广泛接受。这些包括 Mozilla 公共许可证和 Eclipse 公共许可证。每个版本都表明，如果同一许可证有后续版本，则用户可以自由地在后续版本下使用该作品。Creative Commons 版权许可证 CC BY-SA 允许用户在修改作品时升级许可证版本。
也许我们应该在 GNU GPL 的未来版本中切换到该方法。但这需要在未来考虑。
我们感谢 SPDX 决定更改 GNU 系列许可证的短标识符，以明确“or later”与“only”的选择。即将发布的 SPDX 许可证列表的许可证标识符将使用上述建议的标识符。诸如“GPL-2.0”之类的令人困惑的标识符将被弃用。我们要求人们尽快将它们替换为新的明确标识符。
通过使用明确指示“only”或“any later version”的标识符，我们可以让社区意识到其中的区别，并鼓励开发人员明确声明他们的决定。
![[FSF 徽标]](/graphics/fsf-logo-notext-small.png){kind=logo}