如何为自己的作品选择许可证

人们经常问我们推荐他们为自己的项目使用什么许可证。我们之前已经公开撰写过这方面的内容，但是信息分散在不同的文章、常见问题解答和许可证评论中。本文将所有信息收集到一个来源，以便人们更容易遵循和参考。

这些建议适用于旨在完成实际工作的作品。其中包括软件、文档和其他一些东西。艺术作品和表达观点的作品是不同的问题；GNU 项目对于如何发布它们没有统一的立场，只是它们都应该在没有非自由软件的情况下使用（特别是，没有 DRM）。但是，您可能希望将这些建议用于与特定程序相关的艺术作品。

这些建议适用于为自己创建的作品授权——无论是现有作品的修改还是新的原创作品。它们不涉及在不同许可证下组合现有材料的问题。如果您需要这方面的帮助，请查看 我们的 GPL 常见问题解答。

在您了解我们在此处的建议后，如果您需要建议，可以写信给 <[email protected]>。请注意，许可团队可能需要几周的时间才能回复您；如果一个月内没有收到回复，请再次写信。

为现有项目做贡献

当您为现有项目做出贡献时，通常应该使用与原始作品相同的许可证发布您的修改版本。与项目维护者合作是好事，并且为您的修改使用不同的许可证通常会使这种合作非常困难。只有当有充分的理由时，您才应该这样做。

可以使用不同许可证的一种情况是，当您对非 Copyleft 许可证下的作品进行重大更改时。如果您创建的版本比原始版本更有用，那么为您的作品加上 Copyleft 是值得的，所有原因都与我们通常推荐 Copyleft 的原因相同。如果您处于这种情况，请遵循以下为新项目许可的建议。

如果您出于任何原因选择使用不同的许可证发布您的贡献，您必须确保原始许可证允许在您选择的许可证下使用该材料。为了诚实起见，请明确显示作品的哪些部分属于哪个许可证。

软件

我们为不同的项目推荐不同的许可证，主要取决于软件的用途。一般来说，我们建议使用最强的 Copyleft 许可证，而不会干扰该目的。我们的文章“什么是 Copyleft？”更详细地解释了 Copyleft 的概念，以及为什么它通常是最佳的许可策略。

对于大多数程序，我们建议您为您的项目使用最新版本的GNU 通用公共许可证 (GPL)。其强大的 Copyleft 适用于各种软件，并包括对用户自由的众多保护措施。为了允许未来的许可证升级，请指定“版本 3 或任何更高版本”，以便您的程序在未来版本中可以与根据后续 GPL 版本发布的代码许可证兼容。

以下是关于如何根据 GNU GPL 发布程序的更多建议。

现在是例外情况，在这些情况下，最好使用其他许可证而不是 GNU GPL。

小型程序

对于大多数小型程序来说，使用 Copyleft 是不值得的。我们使用 300 行作为我们的基准：当一个软件包的源代码短于此行数时，Copyleft 提供的好处通常太小，不足以证明确保许可证副本始终伴随软件的不便性是合理的。

对于这些程序，我们推荐 Apache 许可证 2.0。这是一个宽松的、宽松的、“容易屈服的”（非 Copyleft）软件许可证，其条款旨在防止贡献者和分销商因专利侵权而起诉。这并不能使该软件免受专利威胁（没有软件许可证可以做到这一点），但它确实可以防止专利持有者设置“诱饵和转换”，即他们以自由条款发布软件，然后要求接收者同意专利许可中的非自由条款。

在宽松的（容易屈服的）许可证中，Apache 2.0 是最好的；因此，如果您要使用宽松的许可证，无论出于什么原因，我们都建议使用该许可证。

库

对于库，我们区分三种情况。

一些库实现了与受限数据格式竞争的自由数据格式，例如 Ogg Vorbis（与 MP3 音频竞争）和 WebM（与 MPEG-4 视频竞争）。自由格式的成功需要允许许多专有应用程序程序链接到代码中以处理该格式。例如，我们希望非自由媒体播放器，尤其是电器，包含 Ogg Vorbis 和 MP3 的代码。

在这些特殊情况下，如果您旨在说服专有应用程序开发人员使用该库来实现自由格式，您需要通过在宽松的许可证下许可该库来使其变得容易，例如 Apache 许可证 2.0。

然而，我们必须承认，这种策略对于 Ogg Vorbis 并没有成功。即使在更改版权许可以允许轻松地将该库代码包含在专有应用程序中之后，专有开发人员通常也没有包含它。在许可证选择中做出的牺牲最终并没有给我们带来多少好处。

对于所有其他库，我们建议使用某种 Copyleft。如果开发人员已经在使用根据非自由许可证或宽松的容易屈服的许可证发布的现有替代库，那么我们建议使用GNU 较小通用公共许可证 (LGPL)。

与第一种情况（库实现了在道德上更优越的标准）不同，这里的采用本身不会实现任何特殊的目标，因此没有理由完全避免 Copyleft。但是，如果您要求使用您的库的开发人员根据 Copyleft 发布他们的整个程序，他们只会使用可用的替代方案之一，这也不会推进我们的事业。较小 GPL 旨在填补这些情况之间的中间地带，允许专有软件开发人员使用受保护的库，但提供较弱的 Copyleft，从而为用户提供有关库代码本身的自由。

对于提供专门功能并且没有面临根深蒂固的非 Copyleft 或非自由竞争的库，我们建议使用普通的 GNU GPL。有关原因，请阅读“为什么不应该为您的下一个库使用较小 GPL。”

服务器软件

如果其他人很可能会改进您的程序以在服务器上运行，而不会将他们的版本分发给任何人，并且您担心这会使您发布的版本处于不利地位，我们建议使用GNU Affero 通用公共许可证 (AGPL)。AGPL 的条款与 GPL 的条款几乎相同；唯一的实质性区别在于，它有一个额外的条件，以确保通过网络使用该软件的人能够获得其源代码。

当用户将他们的计算或数据委托给别人的服务器时，AGPL 的要求并不能解决用户可能出现的问题。例如，它不会阻止 服务作为软件替代 (SaaSS) 剥夺用户的自由——但大多数服务器不执行 SaaSS。有关这些问题的更多信息，请阅读“为什么是 Affero GPL。”

文档

我们建议将GNU 自由文档许可证 (GFDL)用于教程、参考手册和其他大型文档作品。这是一种针对教育作品的强大 Copyleft 许可证，最初是为软件手册编写的，并包含专门解决在分发或修改这些作品时出现的常见问题的条款。

对于短小的辅助文档作品（例如参考卡），最好使用 GNU 所有许可许可证，因为 GFDL 的副本几乎无法放入参考卡中。不要使用 CC BY，因为它与 GFDL 不兼容。

对于手册页，如果页面较长，我们建议使用 GFDL，如果页面较短，则建议使用GNU 所有许可许可证。

一些文档包含软件源代码。例如，编程语言的手册可能包含供读者遵循的示例。您应该同时将这些内容以 FDL 的条款包含在手册中，并根据另一种适用于软件的许可证发布它们。这样做有助于使在其他项目中轻松使用代码。我们建议您使用CC0将小段代码贡献到公共领域，并根据相关软件项目使用的相同许可证分发较大的代码段。

程序的其他数据

本节讨论您可能包含在软件中的所有其他用于实际用途的作品。给您一些例子，这包括图标和其他功能性或有用的图形、字体和地理数据。您也可以将它们用于艺术，但如果您不这样做，我们也不会批评您。

如果您创建这些作品专门用于某个软件项目，我们通常建议您使用与该软件相同的许可证发布您的作品。使用我们推荐的许可证这样做没有任何问题：GPLv3、LGPLv3、AGPLv3 和 GPLv2 都可以应用于任何类型的作品，而不仅仅是软件，这些作品是受版权保护的，并且具有明确的首选修改形式。使用与软件相同的许可证将有助于分发者更容易遵守许可，并避免对潜在的兼容性问题产生任何疑问。如果使用不同的自由许可证可以提供一些特定的实际好处，例如更好地与其他自由项目合作，那么使用不同的自由许可证可能是合适的。

如果您的作品不是为特定的软件项目创建的，或者使用与该项目相同的许可证不合适，那么我们只建议您选择适合您作品的著作权许可证。我们在我们的许可证列表中列出了一些这样的许可证。如果没有特别合适的许可证，知识共享署名-相同方式共享许可证是一个著作权许可证，可以用于许多不同类型的作品。