人们经常问我们，为他们的项目向他们推荐什么许可证。

• https://www.gnu.org/licenses/license-recommendations.html
• 作者：Fsf

前言

人们经常问我们，为他们的项目向他们推荐什么许可证。我们过去已经公开地写了关于这个的文章，但信息在不同的文章、FAQ 条目和许可证注释之间分散开了。这篇文章收集所有的信息至一个单一的来源中，让人们更简单地跟着做并可以参考。

这些推荐是用于那些被设计来做实用工作的作品的。这包括了软件、文档和一些其他的东西。艺术作品、以及表达观点的作品，则不一样；GNU项目对它们该怎么发布没有通用的立场，除了它们应该在没有非自由软件的情况下可以使用（特别是 没有DRM ）。然而，对于和某个程序在一起的艺术作品，你可能需要听从这些推荐。

这些推荐可以用于许可一个你创建的作品——不论是已有作品的修改版还是原创作品。它们不能解决结合已有不同许可证的材料的问题。如果你在寻求那方面的帮助，请查看 GPL FAQ 。

在你看了我们的推荐之后，如果你想要建议，你可以写邮件到 <licensing@gnu.org> 。注意许可证小组的回信可能需要几个星期；如果你在一个月内没有得到回复，请再写一次。

贡献到一个已有的项目

当你贡献到一个已有的项目时，你通常应该在和原作品相同的许可证之下发布你修改过的版本。和项目的维护者合作是件好事，而为你的修改使用不同的许可证经常会让合作变得困难。你只应在有强大理由支持的时候才那样做。

一种可以合理使用不同许可证的情形是，你在非 copyleft 许可证下的作品上做出了主要修改。如果你创建的这个版本比原来的版本有用得多，那么就值得让你的作品 copyleft 化，就和我们通常 推荐 copyleft 的原因 一样。如果你是在这种情况下，请遵循以下用于许可一个新项目的建议。

无论是什么理由，如果你选择以不同许可证发布你的贡献，你必须确保原有的许可证允许素材可以在你选择的许可证之下使用。至少从良心上讲，请明确地表示哪部分的作品是在哪种许可证之下。

软件

对不同的项目我们推荐不同的许可证，这主要依据软件的目的。通常来说，我们推荐使用最 copyleft 而不影响目的的许可证。我们的文章 “什么是 copyleft?” 更详细地解释了 copyleft 的概念，以及为什么它通常是最好的许可方案

对大多数程序，我们推荐你为你的项目使用最新版的 GPL 。它强大的 copyleft 适合所有类型的软件，并对用户的自由有很多保护。也请允许使用 GPL 的未来版本—换句话说，在许可声明中写上你的程序被 GPL v3 或其更新版本覆盖。

此处有关于 如何在 GNU GPL 之下发布程序 的更多建议。

现在看看例外情形，这些情形下使用别的许可证比使用 GPL 更好。

小程序

对大多数小程序，使用 copyleft 是不值得的。我们用300行作为基准：当一个软件包的源码比这个短，copyleft 带来的好处通常太小，不足以对抗确保许可证的复本总是伴随软件的不便。

对这些程序，我们推荐 Apache 2.0 许可证 。这是一个 pushover（非 copyleft）软件许可证，它有用于避免贡献者和分发者起诉专利侵权的条目。这并不会让软件避免来自专利的威胁（一个软件许可证是做不到的），但它避免了专利持有者打着自由的幌子发布软件，这种情况下专利持有者会相当于做了一次“诱导转向”，然后要求接受者同意专利证书中的非自由条目。

在不严格的 pushover 许可证中，Apache 2.0 是最好的；所以如果你要用一个不严格的 pushover 许可证，不论什么原因，我们推荐用这一个。

库

对于库，我们分三种情形。

一些实现了自由数据格式的库与那些限制性数据竞争，例如 Ogg Vorbis（与 MP3 音频竞争）和 WebM（与 MPEG-4 视频竞争）。自由标准的成功需要众多专有软件能够链接到自由标准的库来处理数据。例如，我们希望非自由的媒体播放器，尤其是应用程序，既可以处理 Ogg Vorbis 也可以处理 MP3。

在这些特殊的情况下，如果你的目的是说服专有应用开发者使用自由标准的库，那么你就应该对这些库使用宽松的许可证，比如 Apache 2.0 许可证 ，这样专有应用就容易包含这些库。

然而，我们必须看到这种策略对 Ogg Vorbis 并未奏效。即使我们修改版权许可证允许专有应用轻易地包含该库的代码，专有应用的开发者一般来说还是没有包含该库。我们在许可证上的牺牲最终并没有让我们获益。

对所有其他的库，我们推荐某种 copyleft 许可证。如果开发者已经使用现有的以非自由或不严格的 pushover 许可证发布的库，那么我们建议使用 GNU 宽通用公共许可证（LGPL） 。

在第一种情形中，库实现了一个伦理上更优秀的标准，但在这里不像第一种情形，库的广泛使用并不会达成实际好处，所以完全没有理由避免 copyleft。然而，如果你要求用库的开发者在 copyleft 下发布整个程序，他们会简单地用另一个可用的库，那样也不会推进我们的事业。较为宽松的 GPL（LGPL）是设计于填补这些情形中间地带的，允许私有软件开发者使用其保护起来的库，但考虑到库代码本身，LGPL 提供了给用户自由的弱 copyleft。

对于提供了特别设计，并且不会与现有非 copyleft 或非自由库竞争的，我们推荐使用原始的 GNU GPL。要知道原因，请阅读 《为什么你不应该在下一个函数库中使用 LGPL》 。

服务器软件

如果其他人很有可能会给你在服务器上跑的软件制作改进版并且不向其他人分发他们的版本，而且你担心这将把你的版本置于一个不利的地位，我们推荐 GNU Affero 通用公共许可证（AGPL） 。AGPL 的条目和 GPL 几乎相同；唯一实质的区别是它有一个额外的条件确保通过网络用这个软件的人们可以获得它的源代码。

对于用户们而言，AGPL 的要求没有解决当他们委托其计算或者数据给别人的服务器时，会产生的问题。例如，它不会制止 作为软件替代品的服务（SaaSS） 拒绝给予用户的自由—但大多数服务器不做 SaaSS。要想知道更多关于这些的问题，请阅读 《为什么要使用 GNU Affero GPL》 。

文档

对教程、参考手册和其他大型文档工作，我们推荐 GNU 自由文档许可证 。对教育型工作，这是个很强的 copyleft 许可证，最早为软件文档而编写，并包含特别说明，即当这些作品被分发或修改时的常见问题。

对于短的、次要的文档工作，例如参考卡片，最好使用 GNU全面容许性许可证 ，因为一份 GFDL 的复本难以放进一张参考卡片里面。不要用CC-BY，因为它和 GFDL 不兼容。

对于 man 手册页面，如果页面很长，我们推荐 GFDL，而如果它很短，则推荐 GNU全面容许性许可证 。

一些文档包括了软件源代码。例如，一个编程语言的的手册可能包括让用户遵循的例子。你应当既在 FDL 之下在手册中包含它们，又在另一个适合软件的许可证下发布它们。这样做使得在其他项目中用这些代码变得简单。我们推荐你用 CC0 贡献小段的代码到公有领域，并在有关软件项目使用的相同的许可证之下分发大段的代码。

其他用于程序的数据

这段讨论你会包括在软件中的所有其他实用作品。例如图表和其他功能性或有用的图像、字体和地理数据等。你也可以在艺术中遵循这些，尽管你不这样做我们也不会批评你。

如果你正特意为一个软件项目创作这些作品，我们通常推荐你在和软件使用相同的许可证下发布你的作品。用我们推荐的许可证这样做不会有问题：GPLv3、LGPLv3、AGPLv3 和 GPLv2 都可以用于任何类型—不只是软件—只需受版权保护并对修改版有清晰首选的形式。使用与软件相同的许可证会让分发者更容易遵守规定，并可以避免任何对潜在的兼容性问题的顾虑。如果提供了一些特别的实用的好处，比如和其他自由项目更好地合作，那么使用一个不同的许可证可能是合适的。

如果你的作品不是为某个特定的软件项目而创作的，或者使用和项目相同的许可证不合适，那么我们只推荐你选择一个适合你作品的 copyleft 许可证。有一些 在我们的许可证列表中列出 。如果没有许可证看起来合适的， 创作共用署名-相同方式共享许可证（CC-BY-SA） 是一个可以用于很多不同种类作品的 copyleft 许可证。

点击“了解更多”可访问文内链接