以下许可证符合自由软件许可证的资格，并且与兼容 GNU GPL。

GNU 通用公共许可证 (GPL) 第 3 版 (#GNUGPL) (#GNUGPLv3)

这是 GNU GPL 的最新版本：一个自由软件许可证，也是一个 Copyleft 许可证。我们建议大多数软件包使用它。

请注意，GPLv3 本身与 GPLv2 不兼容。但是，在 GPLv2 下发布的大多数软件也允许您使用 GPL 稍后版本的条款。如果出现这种情况，您可以使用 GPLv3 下的代码进行所需的组合。要了解有关 GNU 许可证之间兼容性的更多信息，请参阅我们的常见问题解答。

GNU 通用公共许可证 (GPL) 第 2 版 (#GPLv2)

这是 GNU GPL 的先前版本：一个自由软件许可证，也是一个 Copyleft 许可证。我们建议大多数软件使用最新版本。

请注意，GPLv2 本身与 GPLv3 不兼容。但是，在 GPLv2 下发布的大多数软件也允许您使用 GPL 稍后版本的条款。如果出现这种情况，您可以使用 GPLv3 下的代码进行所需的组合。要了解有关 GNU 许可证之间兼容性的更多信息，请参阅我们的常见问题解答。

GNU 较宽松通用公共许可证 (LGPL) 第 3 版 (#LGPL) (#LGPLv3)

这是 LGPL 的最新版本：一个自由软件许可证，但不是一个强大的 Copyleft 许可证，因为它允许与非自由模块链接。它与 GPLv3 兼容。我们建议仅在特殊情况下使用它。

请注意，LGPLv3 本身与 GPLv2 不兼容。但是，在 GPLv2 下发布的大多数软件也允许您使用 GPL 稍后版本的条款。如果出现这种情况，您可以使用 GPLv3 下的代码进行所需的组合。要了解有关 GNU 许可证之间兼容性的更多信息，请参阅我们的常见问题解答。

GNU 较宽松通用公共许可证 (LGPL) 第 2.1 版 (#LGPLv2.1)

这是 LGPL 的先前版本：一个自由软件许可证，但不是一个强大的 Copyleft 许可证，因为它允许与非自由模块链接。它与 GPLv2 和 GPLv3 兼容。我们通常建议LGPL 的最新版本，仅在特殊情况下使用。要了解有关 LGPLv2.1 如何与其他 GNU 许可证兼容的更多信息，请参阅我们的常见问题解答。

GNU Affero 通用公共许可证 (AGPL) 第 3 版 (#AGPL) (#AGPLv3.0)

这是一个自由软件，Copyleft 许可证。其条款有效地包含 GPLv3 的条款，并在第 13 节中增加了一个段落，允许通过网络与许可软件交互的用户接收该程序的源代码。我们建议开发人员考虑对任何通常通过网络运行的软件使用 GNU AGPL。

请注意，GNU AGPL 与 GPLv2 不兼容。从严格意义上讲，它在技术上也不与 GPLv3 兼容：您不能在 GPLv3 的条款下随意获取在 GNU AGPL 下发布的代码并进行传送或修改，反之亦然。但是，您可以在一个项目中组合在这些许可证下发布的单独模块或源文件，这将为许多程序员提供他们制作所需程序所需的所有权限。有关详细信息，请参阅这两个许可证的第 13 节。

GNU 全部允许许可证 (#GNUAllPermissive)

这是一个宽松的、允许的自由软件许可证，与 GNU GPL 兼容，我们建议 GNU 软件包将其用于 README 和其他小型支持文件。所有开发人员都可以随意在类似情况下使用它。

此许可证的较旧版本没有包含明确保证免责声明的第二句。相同的分析适用于这两个版本。

Apache 许可证，第 2.0 版 (#apache2)

这是一个自由软件许可证，与 GNU GPL 第 3 版兼容。

请注意，此许可证与 GPL 第 2 版不兼容，因为它有一些该 GPL 版本中没有的要求。其中包括某些专利终止和赔偿条款。专利终止条款是一件好事，这就是为什么我们建议对重要程序使用 Apache 2.0 许可证而不是其他宽松的允许许可证的原因。

艺术许可证 2.0 (#ArtisticLicense2)

此许可证是一个自由软件许可证，由于第 4(c)(ii) 节中的重新许可选项，与 GPL 兼容。

明确的艺术许可证 (#ClarifiedArtistic)

此许可证是一个自由软件许可证，与 GPL 兼容。它是纠正艺术许可证 1.0模糊性所需的最小更改集。

Berkeley 数据库许可证（又名 Sleepycat 软件产品许可证） (#BerkeleyDB)

这是一个自由软件许可证，与 GNU GPL 兼容。

Boost 软件许可证 (#boost)

这是一个宽松的、允许的非 Copyleft 自由软件许可证，与 GNU GPL 兼容。

修改后的 BSD 许可证 (#ModifiedBSD)

这是原始的 BSD 许可证，通过删除广告条款进行了修改。它是一个宽松的、允许的非 Copyleft 自由软件许可证，与 GNU GPL 兼容。

此许可证有时被称为 3 条款 BSD 许可证。

修改后的 BSD 许可证还不错，作为宽松的许可许可证来说，尽管 Apache 2.0 许可证更受欢迎。但是，即使对于小型程序等特殊情况，推荐使用“BSD 许可证”也是有风险的，因为很容易出现混淆，并导致使用有缺陷的原始 BSD 许可证。为了避免这种风险，您可以建议使用 X11 许可证代替。X11 许可证和修改后的 BSD 许可证几乎等效。

但是，对于大型程序，Apache 2.0 许可证更好，因为它能防止专利陷阱。

CeCILL 版本 2 (#CeCILL)

CeCILL 是一个自由软件许可证，明确与 GNU GPL 兼容。

CeCILL 的文本使用了几个应该避免的有偏见的术语：“知识产权”和“保护”；这个决定是不幸的，因为阅读许可证往往会传播这些术语的预设。然而，这并没有给 CeCILL 下发布的程序带来任何特殊问题。

如果有人用专利攻击该程序，CeCILL 的第 9.4 节承诺程序的开发者会以某种形式与用户合作。你可能会认为这对开发者来说是个问题；然而，如果你确定无论如何你都想以这些方式与用户合作，那么这对你来说就不是问题。

Clear BSD 许可证 (#clearbsd)

这是一个自由软件许可证，与 GPLv2 和 GPLv3 都兼容。它基于修改后的 BSD 许可证，并添加了一个明确声明不授予你任何专利许可的条款。因此，我们建议您谨慎使用此许可证下的软件；您应该首先考虑许可人是否可能因专利侵权起诉您。如果开发者拒绝向用户提供专利许可来为您设置陷阱，那么避免使用该程序是明智的。

Cryptix 通用许可证 (#CryptixGeneralLicense)

这是一个宽松的、允许的非 copyleft 自由软件许可证，与 GNU GPL 兼容。它几乎与FreeBSD（也称为“双条款 BSD”）许可证相同。

eCos 许可证版本 2.0 (#eCos2.0)

eCos 许可证版本 2.0 是一个与 GPL 兼容的自由软件许可证。它由 GPL 加上一个允许链接到非 GPL 软件的例外组成。该许可证与 LGPL 有相同的缺点。

教育社区许可证 2.0 (#ECL2.0)

这是一个自由软件许可证，并且与 GPLv3 兼容。它基于Apache 许可证 2.0；专利许可的范围已更改，以便当组织的员工从事项目时，该组织不必将其所有专利许可给接收者。此专利许可和第 9 节中的赔偿条款使该许可证与 GPLv2 不兼容。

Eiffel 论坛许可证，版本 2 (#Eiffel)

这是一个自由软件许可证，与 GNU GPL 兼容。Eiffel 许可证的先前版本与 GPL 不兼容。

EU DataGrid 软件许可证 (#EUDataGrid)

这是一个宽松的、允许的非 Copyleft 自由软件许可证，与 GNU GPL 兼容。

Expat 许可证 (#Expat)

这是一个宽松的、允许的非 Copyleft 自由软件许可证，与 GNU GPL 兼容。

有些人称此许可证为“MIT 许可证”，但该术语具有误导性，因为 MIT 为软件使用了许多许可证。它也是模棱两可的，因为同样的人也称X11 许可证为“MIT 许可证”，未能区分它们。我们建议不要使用“MIT 许可证”这个术语。

X11 许可证和 Expat 许可证之间的区别在于 X11 许可证包含一个关于使用 X 联盟名称的额外段落。这没什么大不了的，但这是一个真正的区别。

对于大型程序，最好使用 Apache 2.0 许可证，因为它能阻止专利陷阱。

FreeBSD 许可证 (#FreeBSD)

这是删除了广告条款和另一个条款的原始 BSD 许可证。（它有时也被称为“双条款 BSD 许可证”）。它是一个宽松的、允许的非 copyleft 自由软件许可证，与 GNU GPL 兼容。

我们关于修改后的 BSD 许可证的评论也适用于此许可证。

Freetype 项目许可证 (#freetype)

这是一个自由软件许可证，并与 GPLv3 兼容。它有一些归属要求，使其与 GPLv2 不兼容。

历史许可通知和免责声明 (#HPND)

这是一个宽松的、允许的、弱的自由软件许可证，与 GPL 兼容。它类似于Python 1.6a2 及更早版本的许可证。

iMatix 标准函数库的许可证 (#iMatix)

这是一个自由软件许可证，并且与 GPL 兼容。

imlib2 的许可证 (#imlib)

这是一个自由软件许可证，并且与 GPL 兼容。作者向我们解释说，GPL 的提供源代码的所有选项都意味着源代码已经“公开提供”了，用他们的话说。

独立 JPEG 组许可证 (#ijg)

这是一个自由软件许可证，并且与 GNU GPL 兼容。作者向我们保证，按照 GPL 要求记录更改的开发人员也将遵守本许可证中的类似要求。

非正式许可证 (#informal)

“非正式许可证”是指诸如“对此做任何您想做的事情”或“您可以重新分发此代码并更改它”之类的声明。

在美国，这些许可证应该根据作者的意图来解释。因此，它们可能意味着它们看起来的意思。这将使它们成为非 copyleft 自由软件许可证，并与 GNU GPL 兼容。但是，不幸的措辞选择可能会赋予它不同的含义。

但是，许多其他国家/地区对版权许可证采取更严格的方法。无法得知这些国家/地区的法院可能会决定非正式声明意味着什么。法院甚至可能决定它根本不是许可证。

如果您希望您的代码是自由的，请不要为您的用户招致不必要的麻烦。请选择并应用已建立的自由软件许可证。我们提供建议，我们建议您遵循这些建议。

英特尔开源许可证 (#intel)

这是一个自由软件许可证，与 GNU GPL 兼容。

ISC 许可证 (#ISC)

此许可证有时也称为 OpenBSD 许可证。这是一个自由软件许可证，并且与 GNU GPL 兼容。

此许可证有一个不幸的措辞选择：它为接收者提供了“使用、复制、修改和分发此软件的权限……” 这与 Pine 的许可证中的语言相同，华盛顿大学后来声称禁止人们分发该软件的修改版本。

ISC 告诉我们他们不同意华盛顿大学的解释，我们有充分的理由相信他们。ISC 还更新了许可证，使其变为“允许使用、复制、修改和/或分发此软件……” 虽然包含“和/或”并没有完全解决问题，但没有理由避免在此许可证下发布的软件。但是，为了确保这种语言将来不会引起任何麻烦，我们鼓励开发人员为其自己的作品选择其他许可证。FreeBSD 许可证同样是允许和简洁的。但是，如果您想要一个宽松、弱的许可证，我们建议使用 Apache 2.0 许可证。

Mozilla 公共许可证 (MPL) 版本 2.0 (#MPL-2.0)

这是一个自由软件许可证。第 3.3 节提供了此许可证与 GNU GPL 版本 2.0、GNU LGPL 版本 2.1、GNU AGPL 版本 3 以及这些许可证的所有更高版本之间的间接兼容性。当您在 MPL 2.0 下接收工作时，您可以创建一个将该工作与这些 GNU 许可证下的工作相结合的“更大作品”。当您这样做时，第 3.3 节允许您在相同 GNU 许可证的条款下分发 MPL 涵盖的作品，但有一个条件：您必须确保最初在 MPL 下的文件仍然在 MPL 的条款下可用。换句话说，当您以这种方式进行组合时，最初在 MPL 下的文件将以 MPL 和 GNU 许可证（们）进行双重许可。最终结果是，整个更大作品将由 GNU 许可证（们）涵盖。从您那里收到该组合的人可以选择根据该许可证的条款使用最初由 MPL 涵盖的任何文件，或者在没有任何进一步限制的情况下，根据 GNU 许可证的条款分发全部或部分更大作品。

重要的是要理解，根据 MPL 条款分发文件的条件仅适用于第一个创建和分发更大作品的一方。如果它也适用于他们的接收者，那么它将是一个额外的限制，并且与 GPL 和 AGPL 不兼容。也就是说，当您为现有项目做出贡献时，我们通常建议您将您的更改保留在同一许可证下，即使您没有被要求这样做。如果您在 GNU 许可证下收到作品，其中某些文件也在 MPL 下，则只有在有充分理由证明其合理性时，才应从这些文件中删除 MPL。

在此方式创建更大作品之前，请检查 MPL 涵盖软件上的许可证通知。在 MPL 2.0 下发布原创作品的各方可以选择通过在许可证通知中包含一句“与二级许可证不兼容”的句子来选择退出此兼容性。任何包含此通知的软件都不与 GPL 或 AGPL 兼容。

MPL 先前版本下的软件可以升级到 2.0 版本，但任何尚未在所列 GNU 许可证之一下提供的软件必须标记为与二级许可证不兼容。这意味着仅在 MPL 先前版本下可用的软件仍然与 GPL 和 AGPL 不兼容。

NCSA/伊利诺伊大学开源许可证 (#NCSA)

该许可证基于 Expat 和 修改的 BSD 许可证的条款。它是一种宽松的、允许的非著作权自由软件许可证，与 GNU GPL 兼容。

Netscape JavaScript 许可证 (#NetscapeJavaScript)

这是 Netscape 公共许可证 和 GNU GPL 的析取。因此，它是一个自由软件许可证，与 GNU GPL 兼容，但不是一个强著作权许可证。

OpenLDAP 许可证，版本 2.7 (#newOpenLDAP)

这是一个允许的非著作权自由软件许可证，与 GNU GPL 兼容。

Perl 5 及以下版本的许可证 (#PerlLicense)

该许可证是 Artistic License 1.0 和 GNU GPL 的析取，换句话说，您可以选择这两种许可证中的任何一种。它符合自由软件许可证的条件，但可能不是真正的著作权许可证。它与 GNU GPL 兼容，因为 GNU GPL 是替代方案之一。

我们建议您对您编写的任何 Perl 4 或 Perl 5 包使用此许可证，以促进 Perl 编程的一致性和统一性。在 Perl 之外，我们敦促您不要使用此许可证；最好只使用 GNU GPL。

公共领域 (#PublicDomain)

处于公共领域不是一种许可证；相反，它意味着该材料不受版权保护，不需要许可证。但在实践中，如果作品处于公共领域，它也可能拥有一个完全允许的非著作权自由软件许可证。公共领域材料与 GNU GPL 兼容。

如果您想将您的作品发布到公共领域，我们鼓励您使用正式的工具来完成。我们的解决方案是要求向 GNU 做出少量贡献的人签署一份免责声明表格。如果您正在从事一个没有正式贡献政策的项目，请联系该项目以讨论如何在项目的许可模式内做出最佳贡献。

Python 2.0.1、2.1.1 及更新版本的许可证 (#Python)

这是一个自由软件许可证，与 GNU GPL 兼容。但是请注意，Python 的中间版本（1.6b1 至 2.0 和 2.1）采用不同的许可证（见下文）。

Python 1.6a2 及更早版本的许可证 (#Python1.6a2)

这是一个自由软件许可证，与 GNU GPL 兼容。但是请注意，较新版本的 Python 采用其他许可证（见上文和下文）。

Ruby 的许可证 (#Ruby)

这是一个自由软件许可证，通过明确的双重许可条款与 GPL 兼容。

SGI 自由软件许可证 B，版本 2.0 (#SGIFreeB)

SGI 自由软件许可证 B 版本 2.0 是一个自由软件许可证。它与 X11 许可证 基本相同，具有提供许可证通知的可选替代方法。

先前版本的 SGI 自由软件许可证 B 尽管名称如此，但并非自由软件许可证。但是，它们都包含允许您升级到新版本许可证的条款（如果您选择这样做）。因此，如果一个软件是在任何版本的 SGI 自由许可证 B 下发布的，您可以使用此自由版本的条款。

新泽西州标准 ML 版权许可证 (#StandardMLofNJ)

这是一个宽松的、允许的非 Copyleft 自由软件许可证，与 GNU GPL 兼容。

Unicode 公司数据文件和软件许可证协议 (#Unicode)

这是 Unicode 公司已应用于 Unicode 字符数据库的许可证，该数据库是开发人员可以用来帮助在其程序中实现 Unicode 标准的各种数据文件。它是一个宽松的许可许可证，与所有版本的 GPL 兼容。

如果您想在自己的软件中使用本许可协议涵盖的文件，这应该没有任何问题，但我们建议您同时包含其文本的完整副本。某些文件包含非自由的替代许可条款，或者根本没有许可信息，因此包含许可协议的副本将有助于避免其他人在分发您的软件时产生混淆。当然，您还需要遵循本许可协议中关于分发文件的条件，但这些条件非常简单。

请注意确保您正在使用的文件受本许可协议的约束。Unicode 公司发布的其他文件受 Unicode 使用条款的约束，这是一个不同的非自由许可证，它出现在同一页面上，但涵盖不同的文件。本许可协议顶部的简短说明详细说明了它涵盖哪些文件。

请不要将本许可协议用于您自己的软件。如果您想为您的项目使用宽松的许可许可证，请为小型程序使用 Expat 许可证，为大型程序使用 Apache 2.0 许可证。这些更常见，并在自由软件社区中得到广泛认可。

通用许可许可证 (UPL) (#UPL)

这是一个宽松的、允许的非著作权自由软件许可证，与 GNU GPL 兼容。该许可证确实提供了对软件作品授予专利许可的能力，但是，当您选择将您的作品置于宽松的许可证下时，我们仍然建议使用 Apache 2.0 许可证以避免专利陷阱。

The Unlicense (#Unlicense)

Unlicense 是对公共领域的贡献。根据 Unlicense 发布的著作将在法律允许的最大范围内贡献给公共领域，并且还附带一个额外的宽松许可证，以帮助涵盖任何贡献不足的情况。公共领域作品和 Unlicense 提供的宽松许可证均与 GNU GPL 兼容。

Vim 的许可证，版本 6.1 或更高版本 (#Vim)

这是一个自由软件许可证，部分著作权但不完全是。通过明确的转换条款，它与 GPL 兼容。

W3C 软件声明和许可证 (#W3C)

这是一个自由软件许可证，并且与 GPL 兼容。

WebM 的许可证 (#WebM)

谷歌的 WebM 实现受 修改的 BSD 许可证 约束。谷歌还为谷歌拥有或控制的，其 WebM 实现必然侵犯的专利提供了单独的专利许可证（令人困惑地称为“额外 IP 权利授予”）。受 GPL 保护的软件可以根据此许可证的条款进行分发：它允许分发者行使 GPL 授予的所有权利，同时满足其所有条件。因此，WebM 的所有许可证都是自由的且与 GPL 兼容。

WTFPL，版本 2 (#WTFPL)

这是一个宽松的、允许的非著作权自由软件许可证，与 GNU GPL 兼容。

我们不推荐使用此许可证。如果您想要一个用于小型程序的宽松的许可许可证，我们建议使用 X11 许可证。较大的程序通常应该使用著作权保护；但是，如果您决心使用宽松的许可许可证，我们建议使用 Apache 2.0 许可证，因为它保护用户免受专利陷阱。

WxWidgets 库许可证 (#Wx)

WxWidgets 许可证是与 GPL 兼容的自由软件许可证。它由 GNU Lesser GPL 2.0 或任何更高版本组成，外加一个允许使用该库的二进制分发在分发者选择的条款（包括专有条款）下获得许可的附加权限。它是一个弱著作权，甚至比 LGPL 还要弱，因此我们 仅在特殊情况下 推荐它。

WxWindows 库许可证 (#Wxwind)

WxWidgets 库许可证 的旧名称。

X11 许可证 (#X11License)

这是一个宽松的、允许的非著作权自由软件许可证，与 GNU GPL 兼容。较早版本的 XFree86 使用相同的许可证，并且一些当前版本的 XFree86 也是如此。较新版本的 XFree86 在 XFree86 1.1 许可证 下分发。

有些人将此许可证称为“MIT 许可证”，但该术语具有误导性，因为 MIT 为软件使用了许多许可证。它也模棱两可，因为同样的人也将 Expat 许可证 称为“MIT 许可证”，而没有区分它们。我们建议不要使用“MIT 许可证”这个术语。

X11 许可证和 Expat 许可证之间的区别在于 X11 许可证包含一个关于使用 X 联盟名称的额外段落。这没什么大不了的，但这是一个真正的区别。

对于小型程序来说，这是一个不错的许可证。较大的程序通常应该使用著作权保护；但是，如果您坚持为大型程序使用宽松的许可许可证，我们建议使用 Apache 2.0 许可证，因为它保护用户免受专利陷阱。

XFree86 1.1 许可证 (#XFree861.1License)

这是一个宽松的、允许的非著作权自由软件许可证，与 GPL 的版本 3 兼容。

请注意，此许可证与 GPL 的版本 2 不兼容，因为它要求适用于发行版中包含致谢的所有文档。

目前有几个版本的 XFree86，其中只有一部分使用此许可证。一些继续使用 X11 许可证。

ZLib 的许可证 (#ZLib)

这是一个自由软件许可证，并且与 GPL 兼容。

Zope 公共许可证，版本 2.0 和 2.1 (#Zope2.0)

这是一个宽松的、允许的非著作权自由软件许可证，与 GNU GPL 兼容。

---

以下许可证是自由软件许可证，但与不兼容GNU GPL。

Affero 通用公共许可证版本 1 (#AGPLv1.0)

Affero 通用公共许可证是一个自由软件许可证，具有著作权，并且与 GNU GPL 不兼容。它由 GNU GPL 版本 2 组成，并添加了 Affero 在 FSF 批准下添加的一个附加部分。新的第 2(d) 节涵盖通过 Web 服务或计算机网络分发应用程序。

此许可证已被GNU Affero 通用公共许可证版本 3取代；请改用该版本。

学术自由许可证，所有版本至 3.0 (#AcademicFreeLicense)

学术自由许可证是一个自由软件许可证，不具有著作权，并且与 GNU GPL 不兼容。最近的版本包含类似于开放软件许可证的合同条款，出于同样的原因，应避免使用。

Apache 许可证，版本 1.1 (#apache1.1)

这是一个宽松的、非著作权的自由软件许可证。它有一些要求使其与 GNU GPL 不兼容，例如严格禁止使用与 Apache 相关的名称。

Apache 许可证，版本 1.0 (#apache1)

这是一个宽松的、非著作权的自由软件许可证，带有广告条款。这会造成像原始 BSD 许可证那样的实际问题，包括与 GNU GPL 不兼容。

Apple 公共源代码许可证 (APSL)，版本 2 (#apsl2)

这是一个自由软件许可证，与 GNU GPL 不兼容。我们建议您不要将此许可证用于您编写的新软件，但可以接受使用和改进在此许可证下发布的软件。更多解释。

BitTorrent 开源许可证 (#bittorrent)

这是一个自由软件许可证，但与 GPL 不兼容，原因与Jabber 开源许可证相同。

原始 BSD 许可证 (#OriginalBSD)

此许可证有时也称为“4 条款 BSD 许可证”。

这是一个宽松的、非著作权的自由软件许可证，但存在一个严重缺陷：“令人讨厌的 BSD 广告条款”。该缺陷并非致命；也就是说，它不会使软件成为非自由软件。但它确实会导致实际问题，包括与 GNU GPL 不兼容。

我们强烈建议您不要将原始 BSD 许可证用于您编写的软件。如果您想使用宽松的、非著作权的自由软件许可证，最好使用修改后的 BSD 许可证、X11 许可证或 Expat 许可证。更好的是，对于一个大型程序，请使用 Apache 2.0 许可证，因为它采取行动反对专利背叛。

但是，没有理由不使用根据原始 BSD 许可证发布的程序。

CeCILL-B 版本 1 (#CeCILL-B)

CeCILL-B 是一个自由软件许可证。它与 GPL 不兼容，因为它具有 GPL 中不存在的要求。第 5.3.4 节中的署名要求超出了 GPL 的要求。它还有一个奇怪的要求，您要尽“最大努力”让第三方同意“遵守本条规定的义务”。

请不要在此许可证下发布软件。

CeCILL-C 版本 1 (#CeCILL-C)

CeCILL-C 是一个具有类似GNU 宽通用公共许可证的弱著作权的自由软件许可证。它与 GNU GPL 不兼容，因为它不包含基本 CeCILL的显式 GPL 兼容性条款。

请不要在此许可证下发布软件。

通用开发和分发许可证 (CDDL)，版本 1.0 (#CDDL)

这是一个自由软件许可证。它具有按文件弱著作权（如 Mozilla 公共许可证的版本 1），这使其与GNU GPL不兼容。这意味着由 GPL 覆盖的模块和由 CDDL 覆盖的模块在法律上不能链接在一起。我们强烈建议您不要因此使用 CDDL。

有关为什么不应将 CDDL 许可的作品与 GPL 许可的作品组合在一起的说明性示例，请参阅 FSF 的声明，解释、执行和更改 GNU GPL，应用于组合 Linux 和 ZFS。

CDDL 中不幸之处还在于它使用了术语“知识产权”。

通用公共署名许可证 1.0 (CPAL) (#CPAL)

这是一个自由软件许可证。它基于Mozilla 公共许可证版本 1，并且出于相同原因与 GPL 不兼容：它对修改后的版本有几个 GPL 中不存在的要求。它还要求您在允许他人使用程序时发布程序的源代码。

通用公共许可证版本 1.0 (#CommonPublicLicense10)

这是一个自由软件许可证。不幸的是，它的弱著作权和法律选择条款使其与 GNU GPL 不兼容。

Condor 公共许可证 (#Condor)

Condor 的最新版本（从 6.9.5 起）是根据Apache 许可证 2.0发布的。只有旧版本的 Condor 使用此许可证。

Condor 公共许可证是一个自由软件许可证。它有一些要求使其与 GNU GPL 不兼容，包括对使用与 Condor 相关的名称的严格限制，并要求再分发者“声明和保证”他们将遵守美国出口法律。（如果将遵守作为许可证的实际条件，则它将不是自由软件许可证。）

Eclipse 公共许可证版本 1.0 (#EPL)

Eclipse 公共许可证类似于通用公共许可证，我们对 CPL 的评论同样适用于 EPL。唯一的更改是 EPL 取消了关于针对 EPL 程序的贡献者的专利侵权诉讼的更广泛的专利报复语言。

Eclipse 公共许可证版本 2.0 (#EPL2)

在 GPL 兼容性方面，Eclipse 公共许可证版本 2.0 与版本 1.0 基本相同。唯一的更改是它明确提供了将 GNU GPL 版本 2 或更高版本指定为某个代码的“辅助许可证”的选项。

如果初始贡献者发布一段特定代码并将 GNU GPL 版本 2 或更高版本指定为辅助许可证，则为该代码提供了与这些 GPL 版本的显式兼容性。（对于用户而言，这样做大致相当于在双重许可证 EPL | GPL 下发布该代码。）但是，没有此指定的 EPL2 仍然与 GPL 不兼容。

欧盟公共许可证 (EUPL) 版本 1.1 (#EUPL-1.1)

这是一个自由软件许可证。它本身具有可与 GPL 相媲美的著作权，并且与 GPL 不兼容。但是，它为接收者提供了在其他选定的许可证条款下重新许可作品的方法，其中一些（特别是Eclipse 公共许可证和通用公共许可证）仅提供较弱的著作权。因此，开发人员不能依靠此许可证来提供强大的著作权。

EUPL 允许重新许可为 GPLv2，因为它被列为用户可以转换到的备选许可证之一。它还间接允许重新许可为 GPL 版本 3，因为有一种方法可以重新许可为 CeCILL v2，而 CeCILL v2 提供了一种重新许可为任何版本的 GNU GPL 的方法。

要执行此两步重新许可，您首先需要编写一段您可以在 CeCILL v2 下许可的代码，或者找到一个以这种方式提供的合适的现有模块，并将其添加到程序中。将该代码添加到 EUPL 覆盖的程序中，为将其重新许可为 CeCILL v2 提供了依据。然后，您需要编写一段您可以在 GPLv3 或更高版本下许可的代码，或者找到一个以这种方式提供的合适的现有模块，并将其添加到程序中。将该代码添加到 CeCILL 覆盖的程序中，为将其重新许可为 GPLv3 或更高版本提供了依据。

欧盟公共许可证 (EUPL) 版本 1.2 (#EUPL-1.2)

这是一个自由软件许可证。它本身具有可与 GPL 相媲美的著作权，并且与 GPL 不兼容。但是，它为接收者提供了在其他选定的许可证条款下重新许可作品的方法，其中一些（特别是 Eclipse 公共许可证）仅提供较弱的著作权。因此，开发人员不能依靠此许可证来提供强大的著作权。

EUPL 仅允许重新许可为 GPLv2 和仅 GPLv3，因为这些许可证被列为用户可以转换到的两个备选许可证。它还间接允许重新许可为 GPL 版本 3 或任何更高版本，因为有一种方法可以重新许可为 CeCILL v2，而 CeCILL v2 提供了一种重新许可为任何版本的 GNU GPL 的方法。

要执行此两步重新许可，您首先需要编写一段您可以在 CeCILL v2 下许可的代码，或者找到一个以这种方式提供的合适的现有模块，并将其添加到程序中。将该代码添加到 EUPL 覆盖的程序中，为将其重新许可为 CeCILL v2 提供了依据。然后，您需要编写一段您可以在 GPLv3 或更高版本下许可的代码，或者找到一个以这种方式提供的合适的现有模块，并将其添加到程序中。将该代码添加到 CeCILL 覆盖的程序中，为将其重新许可为 GPLv3 或更高版本提供了依据。

Fraunhofer FDK AAC 许可证 (#fdk)

这是一个自由软件许可证，但就目前而言。它与任何版本的 GNU GPL 都不兼容。

它具有一种特殊危险形式，即明确声明不向您授予任何专利许可的条款，并邀请您购买一些专利。因此，并且由于许可证作者是已知的专利侵权者，我们建议您谨慎使用或重新分发此许可证下的软件：您应该首先考虑许可方是否可能旨在引诱您侵犯专利。如果您认为该程序是专利陷阱的诱饵，则明智的做法是避免使用该程序。

相关专利可能已过期。根据弗劳恩霍夫是否仍然拥有涵盖该作品的有效专利，该软件现在可能是陷阱，也可能不是。（当然，任何程序都可能受到专利的威胁，而结束这种情况的唯一方法是更改专利法，以使软件免受专利威胁。）

Gnuplot 许可证 (#gnuplot)

这是一个自由软件许可证，与 GNU GPL 不兼容。

IBM 公共许可证，版本 1.0 (#IBMPL)

这是一个自由软件许可协议。不幸的是，它包含一个法律选择条款，使其与 GNU GPL 不兼容。

Jabber 开源许可协议，1.0 版本 (#josl)

该许可协议是一个自由软件许可协议，与 GPL 不兼容。它允许在特定类别的许可协议下重新许可，这些许可协议包含 Jabber 许可协议的所有要求。GPL 不属于该类别，因此 Jabber 许可协议不允许在 GPL 下重新许可。因此，它不兼容。

LaTeX 项目公共许可协议 1.3a (#LPPL-1.3a)

我们尚未对该许可协议进行全面分析，但它是一个自由软件许可协议，其对发行版的要求比 LPPL 1.2（接下来描述）宽松。它仍然与 GPL 不兼容，因为某些修改后的版本必须包含未修改版本的副本或指向未修改版本的指针。

LaTeX 项目公共许可协议 1.2 (#LPPL-1.2)

该许可协议是 LaTeX 发行条款的不完整陈述。就其本身而言，它是一个自由软件许可协议，但与 GPL 不兼容，因为它有许多 GPL 中没有的要求。

该许可协议包含关于如何发布修改版本的复杂且令人恼火的限制，其中包括一个勉强落在可接受范围内的要求：任何修改的文件都必须有一个新名称。

此要求对于 LaTeX 可接受的原因是 TeX 具有允许您映射文件名的功能，以指定“当请求文件 foo 时使用文件 bar”。有了这个功能，这个要求只是令人恼火；如果没有这个功能，同样的要求将是一个严重的障碍，我们将不得不得出结论，它使该程序成为非自由软件。

这种情况可能会给一些重大修改带来麻烦。例如，如果您想将受 LPPL 覆盖的作品移植到另一个缺少类似重映射功能的系统，但仍然要求用户按名称请求此文件，您还需要实现一个重映射功能才能保持此软件的自由性。这会很麻烦，但如果将许可证移植到非常不同的上下文中会导致代码变为非自由软件，这一事实并不会使其在原始上下文中成为非自由软件。

LPPL 表示，在某些 LaTeX 版本中，某些文件可能具有额外的限制，这可能会使其成为非自由软件。因此，可能需要仔细检查才能生成一个自由软件版本的 LaTeX。

LPPL 提出了一个有争议的声明，即仅仅将文件放在其他几个人可以登录并访问它们的机器上本身就构成了分发。我们认为法院不会支持这一说法，但人们开始提出这种说法并不好。

请不要将此许可证用于任何其他项目。

注意：这些评论适用于 LPPL 的 1.2 版本（1999 年 9 月 3 日）。

Lucent 公共许可协议 1.02 版（Plan 9 许可协议） (#lucent102)

这是一个自由软件许可协议，但由于其法律选择条款，它与 GNU GPL 不兼容。我们建议您不要将此许可证用于您编写的新软件，但可以在此许可证下使用和改进 Plan 9。

Microsoft 公共许可协议 (Ms-PL) (#ms-pl)

这是一个自由软件许可协议；它具有不强的著作权保留，但与 GNU GPL 不兼容。因此，我们敦促您不要使用 Ms-PL。

Microsoft 互惠许可协议 (Ms-RL) (#ms-rl)

这是一个自由软件许可协议。它基于 Microsoft 公共许可协议，并增加了一个条款，以使著作权保留稍强一些。它也与 GNU GPL 不兼容，因此我们敦促您不要使用 Ms-RL。

Mozilla 公共许可协议 (MPL) 1.1 版 (#MPL)

这是一个非强著作权保留的自由软件许可协议；与 X11 许可协议不同，它有一些复杂的限制，使其与 GNU GPL 不兼容。也就是说，受 GPL 保护的模块和受 MPL 保护的模块不能合法地链接在一起。因此，我们敦促您不要使用 MPL 1.1。

但是，MPL 1.1 有一个条款（第 13 节）允许程序（或其一部分）选择其他许可协议。如果程序的一部分允许将 GNU GPL 作为替代选择，或任何其他与 GPL 兼容的许可协议作为替代选择，则该程序的那部分具有与 GPL 兼容的许可协议。

MPL 2.0 版本有许多改进，包括默认情况下与 GPL 兼容。请参阅该条目了解详情。

Netizen 开源许可协议 (NOSL)，1.0 版本 (#NOSL)

这是一个自由软件许可协议，它与 Mozilla 公共许可协议 1.1 版基本相同。与 MPL 类似，NOSL 有一些复杂的限制，使其与 GNU GPL 不兼容。也就是说，受 GPL 保护的模块和受 NOSL 保护的模块不能合法地链接在一起。因此，我们敦促您不要使用 NOSL。

网景公共许可协议 (NPL)，1.0 和 1.1 版本 (#NPL)

这是一个自由软件许可协议，不是强著作权保留，并且与 GNU GPL 不兼容。它由 Mozilla 公共许可协议 1.1 版组成，并增加了一个条款，允许 Netscape 使用您添加的代码，即使在其程序的专有版本中也是如此。当然，他们不允许您以类似的方式使用他们的代码。我们敦促您不要使用 NPL。

诺基亚开源许可协议 (#Nokia)

这类似于 Mozilla 公共许可协议 1 版：一个与 GNU GPL 不兼容的自由软件许可协议。

旧版 OpenLDAP 许可协议，2.3 版本 (#oldOpenLDAP)

这是一个允许的非著作权保留自由软件许可协议，其中一些要求（在第 4 节和第 5 节中）使其与 GNU GPL 不兼容。请注意，最新版本的 OpenLDAP 具有一个与 GNU GPL 兼容的 不同的许可协议。

我们敦促您不要将较旧的 OpenLDAP 许可协议用于您编写的软件。但是，没有理由避免运行根据此许可协议发布的程序。

开源许可协议，所有版本直到 3.0 (#OSL)

开源许可协议是一个自由软件许可协议。它在多个方面与 GNU GPL 不兼容。

最近版本的开源许可协议有一项条款，要求分发者尝试获得对许可协议的明确同意。这意味着在普通 FTP 站点上分发 OSL 软件、将补丁发送到普通邮件列表或将软件存储在普通版本控制系统中，可以说违反了许可协议，并可能使您面临终止许可协议的风险。因此，开源许可协议使得使用自由软件开发的普通工具开发软件非常困难。出于这个原因，并且因为它与 GPL 不兼容，我们建议不要将任何版本的 OSL 用于任何软件。

我们敦促您不要将开源许可协议用于您编写的软件。但是，没有理由避免运行根据此许可协议发布的程序。

OpenSSL 许可协议 (#OpenSSL)

最近版本的 OpenSSL（从 3.0.0 开始）是在 Apache 许可协议 2.0 下发布的。只有较旧版本的 OpenSSL 使用此许可协议。

OpenSSL 的许可协议是两个许可协议的结合，一个称为“OpenSSL 许可协议”，另一个是 SSLeay 的许可协议。您必须同时遵守这两个许可协议。这种组合产生了一个与 GNU GPL 不兼容的著作权保留自由软件许可协议。它还具有像 原始 BSD 许可协议 和 Apache 1 许可协议一样的广告条款。

我们建议在您编写的软件中使用 GNUTLS 而不是 OpenSSL。但是，没有理由不使用 OpenSSL 和与 OpenSSL 一起工作的应用程序。

Phorum 许可协议，2.0 版本 (#Phorum)

这是一个自由软件许可协议，但它与 GPL 不兼容。第 5 节使得该许可协议与 GPL 不兼容。

PHP 许可协议，3.01 版本 (#PHP-3.01)

此许可协议由大多数 PHP4 使用。它是一个非著作权保留自由软件许可协议。它与 GNU GPL 不兼容，因为它对在衍生产品的名称中使用“PHP”有严格的限制。

我们建议您不要将此许可协议用于 PHP 插件以外的任何内容。

Python 1.6b1 到 2.0 和 2.1 的许可协议 (#PythonOld)

这是一个自由软件许可协议，但与 GNU GPL 不兼容。主要的不兼容之处在于，此 Python 许可协议受美国弗吉尼亚州法律管辖，而 GPL 不允许这样做。

Q 公共许可协议 (QPL)，1.0 版本 (#QPL)

这是一个非著作权保留的自由软件许可证，与 GNU GPL 不兼容。它还会造成严重的实际不便，因为修改后的源代码只能以补丁的形式分发。

我们建议您避免将 QPL 用于您编写的任何内容，并且仅在绝对必要时使用受 QPL 保护的软件包。但是，这种避免不再适用于 Qt 本身，因为 Qt 现在也以 GNU GPL 发布。

由于 QPL 与 GNU GPL 不兼容，因此您不能将受 GPL 保护的程序和受 QPL 保护的程序链接在一起，无论如何都不能。

但是，如果您编写了一个使用受 QPL 保护的库（称为 FOO）的程序，并且您希望在 GNU GPL 下发布您的程序，您可以轻松地做到这一点。您可以通过向其添加如下通知来解决您的程序的冲突

  As a special exception, you have permission to link this program
  with the FOO library and distribute executables, as long as you
  follow the requirements of the GNU GPL in regard to all of the
  software in the executable aside from FOO.

如果您是该程序的版权所有者，则可以合法地这样做。在声明该程序受 GNU GPL 保护的通知之后，将其添加到源文件中。

RealNetworks 公共源代码许可证 (RPSL)，版本 1.0 (#RPSL)

RPSL 是一个自由软件许可证，由于多种原因，它与 GPL 不兼容：它要求衍生作品以 RPSL 的条款获得许可，并强制任何诉讼都必须在华盛顿州西雅图进行。

Sun 行业标准源代码许可证 1.1 (#SISSL)

这是一个自由软件许可证，不是强烈的著作权保留，由于细节而不是任何重大政策，它与 GNU GPL 不兼容。

Sun 公共许可证 (#SPL)

这本质上与 Mozilla 公共许可证版本 1 相同：一个与 GNU GPL 不兼容的自由软件许可证。请不要将此与Sun 社区源代码许可证混淆，后者不是自由软件许可证。

xinetd 的许可证 (#xinetd)

这是一个著作权保留的自由软件许可证，与 GPL 不兼容。它之所以不兼容，是因为它对修改版本的再分发施加了额外的限制，这与 GPL 中的再分发要求相矛盾。

Yahoo! 公共许可证 1.1 (#Yahoo)

这是一个自由软件许可证。它具有类似于 Mozilla 公共许可证中的著作权保留。它在第 7 节中还有一个法律选择条款。这些功能都使该许可证与 GPL 不兼容。不幸的是，该许可证还使用了术语“知识产权”。

Zend 许可证，版本 2.0 (#Zend)

此许可证由 PHP4 的一部分使用。它是一个非著作权保留的自由软件许可证，与 GNU GPL 不兼容，并且具有与原始 BSD 许可证类似的实际问题。

我们建议您不要将此许可证用于您编写的任何内容。

Zimbra 公共许可证 1.3 (#Zimbra)

此许可证与Yahoo! 公共许可证 1.1相同，只是许可证由 VMWare 而不是 Yahoo! 提供。我们在此处的评论也适用；这是一个与 GPL 不兼容的部分著作权保留自由软件许可证。

Zope 公共许可证版本 1 (#Zope)

这是一个宽松、相当宽容的非著作权保留自由软件许可证，具有与原始 BSD 许可证类似的实际问题，包括与GNU GPL不兼容。

我们强烈建议您不要将 ZPL 版本 1 用于您编写的软件。但是，没有理由避免运行已在此许可证下发布的程序，例如先前版本的 Zope。

Zope 公共许可证的版本 2.0与 GPL 兼容。

---

以下许可证不符合自由软件许可证的条件。非自由许可证会自动与GNU GPL不兼容。

当然，我们强烈建议您避免使用非自由软件许可证，并避免使用非自由程序。

我们不可能在此处列出所有已知的非自由软件许可证；毕竟，每个专有软件公司都有自己的许可证。我们在此重点关注那些经常被误认为是自由软件许可证，但实际上不是自由软件许可证的许可证。

当我们可以在不违反我们的一般政策的情况下这样做时，我们提供了指向这些许可证的链接：我们不会链接到推广、鼓励或促进使用非自由软件包的网站。我们最不想做的是给任何非自由程序一些免费的宣传，这可能会鼓励更多人使用它。出于同样的原因，我们避免了命名使用许可证的程序，除非我们认为出于特定原因它不会适得其反。

没有许可证 (#NoLicense)

如果源代码没有授予用户四个基本自由的许可证，那么除非它已明确且有效地置于公共领域，否则它不是自由软件。

一些开发人员认为，没有许可证的代码会自动进入公共领域。根据当今的版权法，情况并非如此；相反，所有受版权保护的作品默认都受版权保护。这包括程序。在没有许可证授予用户自由的情况下，他们没有任何自由。在某些国家/地区，下载没有许可证的代码的用户可能仅仅通过编译或运行它就侵犯了版权。

为了使程序成为自由软件，其版权所有者必须明确授予用户四个基本自由。他们用来执行此操作的文档称为自由软件许可证。这就是自由软件许可证的用途。

一些国家/地区允许作者将代码置于公共领域，但这需要明确的操作，并且在不同的司法管辖区中可能会有所不同。在大多数情况下，最好对您的代码进行著作权保留，以确保自由能够到达代码的所有用户。

美国政府雇员编写的代码是一个特殊的例外，因为美国版权法明确将其置于公共领域；但这不适用于美国付费给公司编写的作品。它也不适用于其他国家/地区，其中许多国家/地区确实允许国家对政府著作拥有版权。

阿拉丁自由公共许可证 (#Aladdin)

尽管其名称如此，但这不是自由软件许可证，因为它不允许收取分发费用，并且在很大程度上禁止简单地将根据其获得许可的软件与任何收费的东西打包在一起。

反 996 许可证 (#Anti-996)

这不是自由软件许可证。它对为任何目的使用程序的自由施加了限制。

请不要将此许可证用于您自己的软件。我们将避免使用此许可证下的软件，就像我们避免使用所有其他非自由软件一样。

反资本主义软件许可证 (#anticapitalist)

反资本主义软件许可证是一个非自由许可证，因为它仅将四个自由扩展到某些类型的组织，而不是所有组织。在软件许可证中以任何理由施加此类限制，都会对用户施加过多的权力。请不要使用此许可证，并且我们强烈建议您避免使用任何已在此许可证下发布的软件。

Apple 公共源代码许可证 (APSL)，版本 1.x (#apsl1)

版本 1.0、1.1 和 1.2 是非自由软件许可证。请不要使用这些许可证，并且我们强烈建议您避免使用任何已在这些许可证下发布的软件。APSL 的版本 2.0是一个自由软件许可证。

Artistic 许可证 1.0 (#ArtisticLicense)

我们不能说这是一个自由软件许可证，因为它太模糊了；有些段落过于聪明，以至于它们的含义不清楚。我们强烈建议您避免使用它，除非作为Perl 的分离许可证的一部分。

AT&T 公共许可证 (#ATTPublicLicense)

AT&T 公共许可证是一个非自由许可证。它有几个严重的问题

• 专利许可因对相关代码的任何修改而无效，无论修改多么小。
• 当您分发源代码或补丁时，您必须要求书面协议。
• 如果您分发补丁，则需要通知 AT&T。
• 您的许可证可能会在您没有过错的情况下根据第 8/3 节终止。
• 它使遵守出口管制法律成为许可证的条件。
• 某些版本的许可证要求您提供支持。
• 某些版本的许可证表示您不能以超过分发费用的价格出售该软件的副本。

该许可证还有另外两个令人讨厌的功能

• 它对 AT&T 具有非常广泛的反向许可证，远远超出了使用您的代码的范围，即使是您修改的代码也是如此。
• 它声明需要 AT&T 的许可才能链接到他们的网站。这并不是一个直接的实际问题，因为许可证说它允许进行此类链接。（无论如何，人们不应该链接到有关非自由软件的网站。）但是不应该提出或传播这种说法。

Code Project 开放许可证，版本 1.02 (#cpol)

Code Project 开放许可证不是自由软件许可证。第 5.6 节限制了您如何使用该作品。第 5.4 节禁止单独商业分发该软件 - 并且根据您如何阅读第 3.4 节，您可能根本没有权限单独分发该软件。

Commons Clause (#comclause)

“通用条款”是一种非自由许可，因为它禁止出售程序的副本，甚至禁止将程序作为实现任何商业服务的一部分运行。更令人气愤的是，它还扭曲了“通用”和“出售”这两个词的含义。

我们敦促人们拒绝使用此许可下的程序，并开发自由的替代品。如果之前的版本是以自由软件的形式提供的，那么继续开发该版本也是一种选择。

CNRI 数字对象存储库许可协议 (#DOR)

该许可是非自由的，因为第 3 条可能包括一项要求，即不得违反用户运行的任何程序的许可，即使是专有程序。

eCos 公共许可证，版本 1.1 (#eCos11)

这是 eCos 的旧许可证。它不是自由软件许可证，因为它要求将每个发布的修改版本发送给特定的初始开发人员。此许可证中还有一些我们不确定含义的其他词语，可能也存在问题。

现在 eCos 以 GNU GPL 许可发布，并附加了与非自由程序链接的额外权限。

希波克拉底许可证 1.1 (#hippocratic)

这不是自由软件许可证，因为它限制用户可以使用该软件执行的工作。这否定了自由 0。请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

此条目之前被列为“第一不伤害”许可证。

公共管理计算机程序 GPL (#GPL-PA)

GPL-PA（其葡萄牙语原名为“Licença Pública Geral para Administração Pública”）由于以下几个原因是非自由的：

• 它仅允许在“正常情况下”使用。
• 它不允许在没有二进制文件的情况下分发源代码。
• 其权限在 50 年后失效。

请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

黑客主义增强型源代码软件许可协议 (HESSLA) (#HESSLA)

这不是自由软件许可证，因为它限制人们可以使用该软件执行的工作，并实质性地限制了该程序修改版本可以执行的工作。请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

Jahia 社区源代码许可证 (#Jahia)

Jahia 社区源代码许可证不是自由软件许可证。源代码的使用仅限于研究目的。

JSON 许可证 (#JSON)

这是 JSON 数据交换格式原始实现的许可证。此许可证以 Expat 许可证为基础，但添加了一个强制性条款：“该软件应用于善，而不是恶。”这是对用途的限制，因此与自由 0 相冲突。该限制可能无法执行，但我们不能假设这一点。因此，该许可证是非自由的。

请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

ksh93 的旧许可证 (#ksh93)

ksh93 过去附带一个非自由软件许可证的原始许可证。其中一个原因是它要求将所有更改发送给开发人员。

Lha 的许可证 (#Lha)

Lha 许可证必须被认为是非自由的，因为它太模糊了，以至于您无法确定您拥有哪些权限。

Llama 3.1 社区许可协议和 Llama 3.1 可接受使用政策 (#Llama)

这不是自由软件许可证。

它否定了自由 0：它施加了“可接受的使用政策”，禁止一系列 25 种左右的用途。

政策中列出的某些用途令人发指，有些应该是非法的，有些在某些地方已经是违法的。然而，由民主控制的政府在法律中颁布的禁令和一家私营公司规定我们在生活中允许做什么之间存在着至关重要的区别。

此外，该许可证排除了某些用户，即那些其程序或服务器被广泛使用的用户。（请参阅题为“附加商业条款”的第 2 节）。自由软件许可证不得任意拒绝任何人使用该程序。

此许可证的另一个严重缺陷是，它要求用户遵守所有法律，包括其他国家/地区的贸易法规，这些法规无法在您的国家/地区强制执行。这可能会导致在某些情况下否定自由 2 和 3。即使一个国家/地区无法在您居住的地方强制执行其贸易法规，它也可以要求该程序的开发人员起诉您。

此许可证是为大型语言模型 (LLM) 编写的，该模型通过将输入数据的片段拼接在一起生成输出，而不理解生成的输出意味着什么（如果有的话）。LLM（和其他机器学习应用程序）由软件和非软件元素组成，例如模型参数。在机器学习应用程序中行使软件自由会面临超出许可证的挑战。此许可证当然无法解决这些问题，但我们在此不做详细说明，因为该许可证由于上述原因已经是非自由的。

微软的共享源代码 CLI、C# 和 Jscript 许可证 (#Ms-SS)

此许可证不允许商业分发，仅允许在特定情况下进行商业使用。

微软还有其他将其描述为“共享源代码”的许可证，其中一些许可证具有不同的限制。因此，“共享源代码”太模糊了，无法从中得出道德结论。

请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

NASA 开源协议 (#NASA)

NASA 开源协议 1.3 版不是自由软件许可证，因为它包含一项条款，要求更改必须是您的“原创作品”。自由软件开发依赖于组合来自第三方的代码，而 NASA 许可证不允许这样做。

我们敦促您不要使用此许可证。此外，如果您是美国公民，请写信给 NASA，呼吁使用真正自由的软件许可证。

Oculus Rift SDK 许可证 (#OculusRiftSDK)

这不是自由软件许可证；它有几个致命的缺陷。

• 不能重新分发少于整个程序 libOVR 的任何内容。
• 一个人的分发权利可能会在模糊的条件下被终止。
• 那些制作修改版本的人被要求按需将其发送给 Oculus。
• 仅允许与他们的产品一起使用。
• 新的许可证版本完全取代了旧版本，这意味着已经授予的权限可以被撤销。

可能还有其他致命的缺陷；在看到这么多之后，我们停止寻找更多缺陷。

请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

开放公共许可证 (#OpenPublicL)

这不是自由软件许可证，因为它要求将每个发布的修改版本发送给特定的初始开发人员。此许可证中还有一些我们不确定含义的其他词语，可能也存在问题。

请不要使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。

对等生产许可证 (#PPL)

对等生产许可证不是自由软件许可证，因为它限制谁可以重新分发该程序以及用于什么目的。它也没有给任何人运行该程序的权限。

PPL 有一些专门为艺术表演设计的条款，我们不反对将其用于艺术作品；然而，据报道，人们也提倡将其用于软件。PPL 不应用于软件、手册或其他应该自由的作品。

个人公共许可证版本 3a (#PPL3a)

个人公共许可证版本 3a 是一个非自由许可证，因为它拒绝某些用户（组织、政府、企业）享有四项自由。

PINE 的许可证 (#PINE)

PINE 的许可证不是自由软件许可证，因为它主要禁止分发修改后的版本。它还限制了可以用于出售副本的媒体。

请注意，Pine 的后继产品 Alpine 是在Apache 许可证 2.0 版下发布的。

旧版 Plan 9 许可证 (#Plan9)

这不是自由软件许可证；它缺乏基本自由，例如进行和使用私有更改的权利。当然，您不应该使用此许可证，我们敦促您避免使用任何以此许可证发布的软件。此处还提供了对此许可证的详细讨论。

在 2002 年 9 月，人们观察到 Plan 9 发布许可已被修改，添加了更多限制，尽管其日期仍为 09/20/00。然而，2003 年的进一步许可证更改使 Plan 9 成为自由软件。

互惠公共许可证 (#RPL)

互惠公共许可证是一个非自由许可证，原因有三个。1. 它对初始副本的收费价格设置了限制。2. 它要求在发布修改后的版本时通知原始开发人员。3. 它要求发布组织使用的任何修改版本，即使是私下使用。

Scilab 许可证 (#Scilab)

这不是自由软件许可证，因为它不允许商业分发修改后的版本。值得庆幸的是，从 5.0.0 版本开始，Scilab 软件是自由软件，在 CeCILL 2 版下发布。

Scratch 1.4 许可证 (#Scratch)

这不是自由软件许可证，因为它不允许商业再分发。此外，条件 4 实质性地限制了修改版本的功能。

较新版本的 Scratch 软件是在 GNU GPL 下分发的，但我们不推荐其中一些较新版本，因为它们依赖于专有软件 Adobe Air。

简单机器许可证 (#SML)

尽管名称如此，但这是一个软件许可证，并且由于以下几个原因，它是非自由的：

• 您必须在分发软件之前获得许可方的许可。
• 您不能出售该软件的副本。
• 如果您从不遵守许可证条款的人那里收到该软件，则您的许可证可能会被终止。

旧版 Squeak 许可证 (#Squeak)

最初的 Squeak 许可，应用于软件时，并非自由软件许可，因为它要求所有国家/地区的所有用户都必须遵守美国出口管制法律。应用于字体时，它也不允许修改。

此外，它还要求用户赔偿开发者，这足以让许多用户在是否使用它时三思而后行。

最近版本的 Squeak（从 4.0 版本开始）是在Expat 风格的许可下发布的，其中一部分代码在 Apache 许可 2.0 下发布。

Sun 社区源代码许可 (#SunCommunitySourceLicense)

这不是自由软件许可；它缺少必要的自由，例如发布修改版本。请不要使用此许可，我们强烈建议您避免使用任何在此许可下发布的软件。

Sun Solaris 源代码（基础发行版）许可，版本 1.1 (#SunSolarisSourceCode)

这不是自由软件许可。该许可禁止再分发，禁止商业使用该软件，并且可以撤销。

Sybase Open Watcom 公共许可版本 1.0 (#Watcom)

这不是自由软件许可。它要求您在“部署”所涵盖的软件时公开源代码，并且“部署”的定义包括许多类型的私人使用。

SystemC “开源”许可，版本 3.0 (#SystemC-3.0)

此许可要求所有接收者主动帮助许可人执行其商标。这是对用户权利施加的不合理条件，因此该许可是非自由的。它还有其他实际问题：一些要求含糊不清，并且使用了 “知识产权” 一词。

尽管名称如此，但不清楚此许可是否符合“开源”的条件。但是，我们对此的判断并非基于此。

Truecrypt 许可 3.0 (#Truecrypt-3.0)

此许可因几个原因是非自由的。它说如果您不理解该许可，则不得使用该程序。它对允许他人运行您的副本设置了条件。它对“依赖” Truecrypt 的单独程序设置了条件。商标条件适用于“相关材料”。

该许可中还有其他一些看似不可接受的点，由于我们对它们的不确定性，我们推迟了发布我们的评估。我们现在发布它以解释为什么我们不为 Truecrypt 的消亡而悲伤。有完成相同工作的自由程序。

犹他大学研究基金会公共许可 (#UtahPublicLicense)

犹他大学研究基金会公共许可是非自由许可，因为它不允许商业再分发。它还声称限制商业运行该软件，甚至商业提供关于它的咨询。这些限制可能在美国版权法下无法律效力，但在某些国家/地区可能有效；即使是断言它们也是令人发指的。

犹他大学使用此许可体现了大学限制知识而非将其贡献给公众的危险趋势。

如果大学试图对您正在编写的软件施加这样的许可，请不要放弃希望。通过坚持和坚定，以及一些预见，有可能战胜贪财的大学管理人员。

您越早提出这个问题，就越好。

YaST 许可 (#YaST)

这不是自由软件许可。该许可禁止有偿分发，这使得软件不可能被包含在公司和组织销售的许多 CD-ROM 自由软件集合中。

第 2a 节可能还有另一个问题，但那里似乎缺少一个词，因此很难确定真正的含义是什么。

（YaST 软件本身不再使用此非自由的 YaST 许可；令人高兴的是，它现在是自由软件，在 GNU GPL 下发布。）

以下许可符合自由文档许可的条件。

GNU 自由文档许可证 (#FDL)

这是一个旨在用于受著作权保护的自由文档的许可。我们计划采用它用于所有 GNU 手册。它也适用于其他类型的实用作品（例如，教科书和词典）。其适用性不限于文本作品（“书籍”）。

FreeBSD 文档许可证 (#FreeBSDDL)

这是一个宽松的非著作权保护的自由文档许可，与 GNU FDL 兼容。

Apple 通用文档许可，版本 1.0 (#ACDL)

这是一个与 GNU FDL 不兼容的自由文档许可。它之所以不兼容是因为第 (2c) 节说“您不得在此许可证的条款和条件之外添加任何其他条款或条件”，而 GNU FDL 具有通用文档许可中未考虑的其他条款。

开放出版许可，版本 1.0 (#OpenPublicationL)

如果版权所有者不使用许可的第六部分中列出的任何“许可选项”，则此许可可以用作自由文档许可。但是，如果调用了任何一个选项，则该许可将变为非自由许可。在任何情况下，它都与 GNU FDL 不兼容。

这在使用或推荐此许可时会产生实际的陷阱：如果您建议“使用开放出版许可，版本 1.0，但不要启用选项”，则很容易忘记该建议的后半部分；有人可能会使用带有选项的许可，从而使手册变为非自由的，但仍然认为他或她遵循了您的建议。

同样，如果您在不使用任何选项的情况下使用此许可来使您的手册自由，则其他人可能会决定模仿您，然后改变对这些选项的想法，认为这只是一个细节；结果是，他或她的手册是非自由的。

因此，虽然在此许可下发布的手册在未使用任何许可选项的情况下确实符合自由文档的条件，但最好使用 GNU 自由文档许可证，并避免误导他人的风险。

请注意，此许可与开放内容许可不同。这两种许可经常被混淆，因为开放内容许可通常被称为“OPL”。为了清楚起见，最好不要对任何一个许可使用缩写“OPL”。最好完整拼写它们的名称，以确保人们理解您所说的话。

---

以下许可不符合自由文档许可的条件

开放内容许可，版本 1.0 (#OpenContentL)

此许可不符合自由的条件，因为对收取副本费用有限制。我们建议您不要使用此许可。

请注意，此许可与开放出版许可不同。将“开放内容许可”缩写为“OPL”的做法导致它们之间混淆。为了清楚起见，最好不要对任何一个许可使用缩写“OPL”。最好完整拼写它们的名称，以确保人们理解您所说的话。

知识共享署名-非商业性，任何版本 (#CC-BY-NC)

此许可不符合自由的条件，因为对收取副本费用有限制。因此，我们建议您不要将此许可用于文档。

此外，它对于任何类型的工作都有一个缺点：当修改后的版本有很多作者时，实际上从所有作者那里获得商业用途的许可将变得不可行。

知识共享署名-禁止演绎，任何版本 (#CC-BY-ND)

此许可不符合自由的条件，因为对分发修改版本有限制。我们建议您不要将此许可用于文档。

GNU 通用公共许可证 (#GPLOther)

GNU GPL 可以用于非软件的一般数据，只要可以确定特定情况下“源代码”的定义所指的内容即可。事实证明，DSL（见下文）也要求您使用 GPL 使用的近似相同定义来确定“源代码”是什么。

GNU 自由文档许可证 (#FDLOther)

建议将 GNU FDL 用于所有主题的教科书和教材。（“文档”仅表示使用设备或软件的教科书和其他教材。）我们还建议将 GNU FDL 用于词典、百科全书和任何其他提供实用信息的作品。

CC0 1.0 通用 (#CC0)

CC0 是知识共享的公共领域奉献。根据 CC0 发布的作品在法律允许的最大范围内被奉献给公共领域。如果出于任何原因无法实现，CC0 还提供宽松的许可作为后备。公共领域作品和 CC0 提供的宽松许可都与 GNU GPL 兼容。

如果您想将您的非软件作品发布到公共领域，我们建议您使用 CC0。对于软件作品，不建议使用，因为 CC0 有一项条款明确声明它不授予您任何专利许可。

由于缺少这种专利授权，我们鼓励您谨慎使用此许可下的软件；您应首先考虑许可人是否可能因专利侵权起诉您。如果开发者拒绝向用户授予专利许可，则该程序实际上是用户的陷阱，用户应避免使用该程序。

知识共享署名 4.0 许可（又名 CC BY） (#ccby)

这是一个非著作权保留的自由许可协议，适用于艺术和娱乐作品，以及教育作品。它与所有版本的GNU GPL兼容；然而，像所有CC许可协议一样，它不应该用于软件。

(#which-cc)知识共享（Creative Commons）发布了许多非常不同的许可协议。因此，说一个作品“使用知识共享许可协议”并没有回答关于该作品许可的主要问题。当你在一个作品中看到这样的声明时，请要求作者修改作品，清楚且明显地说明它使用哪个知识共享许可协议。如果有人提议为某个作品“使用知识共享许可协议”，那么在进一步操作之前，必须先问清楚“哪个知识共享许可协议？”。

知识共享署名-相同方式共享 4.0 许可协议 (又名 CC BY-SA) (#ccbysa)

这是一个著作权保留的自由许可协议，适用于艺术和娱乐作品以及教育作品。像所有CC许可协议一样，它不应该用于软件。

CC BY-SA 4.0 与 GNU GPL 版本 3 单向兼容：这意味着你可以将根据 CC BY-SA 4.0 材料修改后的版本以 GNU GPL 版本 3 许可，但你不能将以 GPL 3 许可的作品重新以 CC BY-SA 4.0 许可。

由于知识共享在其兼容许可协议列表中仅列出 GNU GPL 版本 3，这意味着你不能将你改编的 CC BY-SA 作品以“GNU GPL 版本 3，或（由你选择）任何后续版本”的条款许可。然而，GNU GPL 版本 3 的第 14 条允许许可人指定一个代理来确定是否可以使用 GNU GPL 的未来版本。因此，如果有人改编了 CC BY-SA 4.0 作品并将其纳入一个以 GNU GPL 版本 3 许可的项目，他们可以将知识共享指定为他们的代理（通过https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/），这样，如果知识共享确定 GNU GPL 的未来版本是兼容许可协议，那么改编和组合后的作品就可以在该 GNU GPL 的后续版本下使用。

请明确说明正在使用哪个知识共享许可协议。

设计科学许可协议 (DSL) (#dsl)

这是一个自由且著作权保留的许可协议，适用于通用数据。请不要将其用于软件或文档，因为它与 GNU GPL 和 GNU FDL 不兼容；但是，用于其他类型的数据是可以的。

自由艺术许可协议 (#FreeArt)

这是一个自由且著作权保留的许可协议，适用于艺术作品。它允许商业发行，正如任何自由许可协议必须的那样。它是一个著作权保留许可协议，因为任何包含你收到的作品部分内容的较大作品都必须作为一个整体发布，要么使用相同的许可协议，要么使用符合既定标准的类似许可协议。请不要将其用于软件或文档，因为它与 GNU GPL 和 GNU FDL 不兼容。

开放数据库许可协议 (#ODbl)

这是一个自由且著作权保留的许可协议，适用于数据。它与 GNU GPL 不兼容。请不要将其用于软件或文档，因为它与 GNU GPL 和 GNU FDL 不兼容。它对签署合同提出了不方便的要求，试图为不可版权的数据创建类似著作权保留的效果，因此我们不建议使用它；但是，没有理由避免使用以这种方式发布的数据。

以下许可协议适用于计算机文件中设计的一个实例，而不是艺术设计。据我们所知，设计的实现始终是受版权保护的。艺术设计的法律地位是复杂的，并且因司法管辖区而异。

GNU 通用公共许可证 (#GPLFonts)

GNU GPL 可以用于字体。但是，请注意，除非该文档也以 GPL 许可，否则它不允许将字体嵌入文档中。如果你想允许这样做，请使用字体例外。另请参阅这篇关于 GPL 字体例外的解释性文章。

文鼎公共许可 (#Arphic)

这是一个著作权保留的自由软件许可协议，与 GPL 不兼容。它的正常用途是用于字体，在这种用途中，不兼容性不会造成问题。

LaTeX ec 字体许可 (#ecfonts)

此许可涵盖了欧洲计算机现代字体和文本配套字体，通常与 LaTeX 一起使用。根据它的使用方式，它可能是自由的也可能不是。如果该软件包声明该软件包中的某些字体可能无法修改，则该软件包是非自由的。否则，该软件包是自由的。原始字体对修改没有限制，因此它们是自由的。

很像 LaTeX 项目公共许可证 1.2，此许可要求对作品的修改版本使用与任何先前版本的名称不同的名称。这对于打算与 LaTeX 一起使用的作品是可以接受的，因为 TeX 允许你为程序创建文件名映射，但这非常烦人，并且在其他情况下可能负担过重。

IPA 字体许可 (#IPAFONT)

这是一个著作权保留的自由软件许可协议，与 GPL 不兼容。它有一个不幸的条件，要求衍生作品不得使用或包含原始作品的名称作为程序名称、字体名称或文件名。这对于字体是可接受的，因为可以使用自由软件工具为字体设置别名或重命名，但这非常烦人，并且在其他情况下可能负担过重。

SIL 开放字体许可 1.1 (#SILOFL)

开放字体许可（包括其原始版本，版本 1.0）是一个自由的著作权保留字体许可协议。它唯一不寻常的要求是，在销售字体时，你必须将其与某些软件捆绑在一起重新分发，而不是单独分发。由于一个简单的 Hello World 程序就可以满足要求，因此它是无害的。我们和 SIL 都不建议将此许可用于字体以外的任何其他用途。

表达某人意见的作品——回忆录、社论等等——与软件和文档等实用作品的目的根本不同。因此，我们期望它们为接收者提供一组不同的权限：仅允许逐字复制和分发作品的权限。理查德·斯托曼在他的演讲中经常讨论这个问题。

由于许多许可协议都符合这些标准，我们无法全部列出。但是，如果你正在寻找自己使用的许可协议，我们推荐两个

GNU 逐字复制许可 (#GNUVerbatim)

这是 GNU 网站多年来使用的许可协议。它非常简单，特别适合书面作品。

知识共享署名-禁止演绎 4.0 许可协议（又名 CC BY-ND） (#ccbynd)

这是 GNU 和 FSF 网站上使用的许可协议。此许可协议提供的权限与我们的逐字复制许可协议大致相同，但它更详细。我们特别推荐它用于意见的音频和/或视频作品。此许可协议的先前版本也可以使用，但我们建议你尽可能升级到此版本。请明确说明正在使用哪个知识共享许可协议。

电路是用于实际用途的，因此电路设计应带有自由许可协议。我们建议在 GNU 通用公共许可证，第 3 版或更高版本下发布它们。第 3 版是为这种用途而设计的。

用于实际用途的物体的 3D 打印机计划也应该是自由的。我们建议使用 GNU GPL 或 CC-BY 或 CC-BY-SA 等自由的知识共享许可协议之一。

装饰物体的 3D 打印机计划是艺术作品；任何知识共享许可协议都适用于它们。