使用开源代码和开源软件如何选择开源许可证

最新推荐文章于 2024-09-27 07:00:00 发布

北京王老师

最新推荐文章于 2024-09-27 07:00:00 发布

阅读量2.7k

点赞数

文章标签：开源软件开源

本文链接：https://blog.csdn.net/SE_JW/article/details/131009551

版权

文章详细列举并对比了各种常见的开源许可证，如GPL、BSD、MIT、Mozilla、Apache和LGPL等，探讨了它们的异同和兼容性问题，特别是对GPL的兼容性。文章强调了最宽松的MIT许可证和Apache许可证，以及严格的GPL许可证。同时，还提到了一些不兼容GPL的自由软件许可证和非自由软件许可证，提醒开发者在选择许可证时要谨慎。

摘要由CSDN通过智能技术生成

常用的开源许可证

世界上的开源许可证大约有近百种，如何使用开源代码和开源软件并正确理解、遵守这些开源许可证赋予的权利和义务是个比较繁琐的问题，我们对其中主要的六种许可证GPL、BSD、MIT、Mozilla、Apache和LGPL做个简单的梳理，对比一下各自的约定内容和大致区别。

我们画一幅图做个简单对比：

使用开源代码和开源软件如何选择开源许可证_开源许可证

可以看出，最为宽松的时MIT许可证，其次是Apache许可。较为严格的时GPL，Mozilla等，要求新增、修订的开源代码必须持续开源。

各类许可证介绍

简介

我们有对许可证进行分类的一些关键标准：

许可证是否为合格的自由软件许可证。
许可证是否是一个 copyleft 许可证。
许可证是否兼容 GNU GPL。除非特别说明，此处兼容是指同时兼容 GPLv2 和 GPLv3。
许可证是否有其他实际操作问题。

在这里，我们尽量列举最常见的自由软件许可证，但是我们不能全部都列举完；我们会尽最大努力去回答关于自由软件许可证的问题，不管问题涉及的自由软件许可证是否列在这里。许可证会大致按照字母顺序在每个章节列出。

如果你发现有对我们许可证的违反事例，请参看违反许可证页面。

如果你有一个新项目，而你还没有确定使用哪个许可证，“如何为你的作品选择一份许可证” 是我们提供的一份简便易行的详细建议。

由于资源有限，我们不会回答辅助专有软件开发或发布的问题。如果你的问题比较具体而且没有列在本页或 GNU许可证常见问题，那么对你的回答就会快些。我们欢迎有能力的志愿者帮助我们回答许可证相关的问题。

如果你正在考虑撰写一个新的许可证，请也联系我们。不同自由软件许可证数目的增长今天已经成为自由软件社区的重要问题，无论是对用户，还是对开发者。我们会尽最大努力按你所需找到一个现有的自由软件许可证。

如果你不确定某个软件包的许可证，请访问自由软件目录，那里分类列出了上万个自由软件包以及它们的许可证信息。

软件许可证

兼容 GPL 的自由软件许可证

(#GPLCompatibleLicenses)

以下许可证为合格的自由软件许可证，而且兼容 GNU GPL。

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

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

请注意 GPLv3 本身和 GPLv2 并不兼容。不过，大多数使用 GPLv2 发布的软件也允许你使用 GPL 的以后版本。这样的话，你就能够按照 GPLv3 做合理的代码合并。如果需要了解 GNU 许可证兼容的更多信息，请参看 GNU 许可证常见问题。

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

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

请注意 GPLv2 本身不兼容 GPLv3。不过，大多数使用 GPLv2 发布的软件也允许你使用 GPL 的以后版本。这样的话，你就能够按照 GPLv3 做合理的代码合并。如果需要了解 GNU 许可证 GNU 许可证之间的兼容性，请参看 GNU 许可证常见问题。

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

这是 LGPL 的最新版：它是自由软件许可证，但不是严格的 copyleft 许可证，因为它允许连接非自由的模块。它兼容 GPLv3。我们建议只在特殊情况下使用该许可证。

请注意 LGPLv3 本身不兼容 GPLv2。不过，大多数使用 GPLv2 许可证的软件也允许你使用 GPL 以后版许可证的条款。在这种情况下，你可以使用 GPLv3 的条款来做代码合并。如果需要了解 GNU 许可证之间的兼容性，请参看 GNU 许可证常见问题。

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

这是上一版的 LGPL：它是自由软件许可证，但不是严格的 copyleft 许可证，因为它允许连接非自由的模块。它兼容 GPLv2 和 GPLv3。我们一般建议只在特殊情况下使用最新版 LGPL。如果要了解更多 LGPLv2.1 和其他 GNU 许可证的兼容信息，请参看 GNU 许可证常见问题。

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

这是一个自由软件许可证，也是 copyleft 许可证。其条款实际上是由 GPLv3 的条款加上在第 13 节增加的一个段落构成的，该段落允许网络软件用户可以通过网络获得使用以此许可证授权的软件源代码。我们建议开发者考虑为正常情况下通过网络使用的软件采取 GNU AGPL 许可证。

请注意 GNU AGPL 和 GPLv2 不兼容。从技术上说，它也不严格兼容 GPLv3：你无法随意将按照 GNU AGPL 发布的软件按照 GPLv3 的条款输送或修改，反之也不行。不过，你可以把按照这两种许可证发布的独立模块或源代码合并为一个单一的项目，这样就为其他程序员提供了一个可以随意修改的程序。参看两个许可证的第 13 节来了解详情。

GNU 全权许可许可证 (#GNUAllPermissive)

这是一个松散的、纵容型自由软件许可证，它兼容 GNU GPL。我们建议 GNU 软件包的 README 和其他支持性文件使用该许可证。程序员可以在类似的情形下按照自己的意愿使用该许可证。

该许可证较早的版本没有最新版的第二句清晰的免责声明。此处的分析适用于最新版和早期版。

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

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

请注意该许可证不兼容 GPL v2，因为它的一些要求没有包含在 GPL v2 中。这包括某些专利中止和侵害保护条款。其中的专利中止条款是不错的，因此我们推荐大型的软件可以使用 Apache 2.0 许可证而不是其他松散型许可证。

Artistic 许可证 2.0 (#ArtisticLicense2)

这是一个自由软件许可证，感谢其第 4 节(c)(ii)中的再次授权选项，它兼容 GPL。

澄清后的 Artistic 许可证 (#ClarifiedArtistic)

这是一个自由软件许可证，它兼容 GPL。它是一个澄清了 Artistic 许可证 1.0 的最小修正集。

Berkeley 数据库许可证(又称为 Sleepycat 软件产品许可证) (#BerkeleyDB)

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

Boost 软件许可证 (#boost)

这是一个松散的、纵容型、非 copyleft 的自由软件许可证，它兼容 GNU GPL。

修改版 BSD 许可证 (#ModifiedBSD)

这是删除了原始版 BSD 许可证的广告条款之后的修改版许可证。它是一个松散的、纵容型、非 copyleft 的自由软件许可证，它兼容 GNU GPL。

该许可证有时也被称为 3-clause 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(又称为 “2-clause 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 Consortium 名称的额外段落。虽然不是什么大问题，但它就是区别所在。

由于 Apache 2.0 许可证避免了专利背叛，所以我们建议大型程序使用 Apache 2.0 许可证。

FreeBSD 许可证 (#FreeBSD)

这是把原始 BSD 许可证的广告条款和另一项条款删除之后的版本。(它有时也被称为 “2-clause 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 开源许可证 (#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 v2.0、GNU LGPL v 2.1、GNU AGPL v 3 以及所有这些许可证以后版本的说明。当你获得采用 MPL 2.0 许可证的作品，你可以把它和其他采用以上 GNU 许可证的作品组合在一起，创作 “较大作品”。其第 3.3 节授权你可以使用和以上 GNU 许可证一样的条款来发布组合了 MPL 的较大作品，但是有一个条件：原来按照 MPL 发布的那些文件还是可以使用 MPL 条款的。换句话来说，当你做组合程序时，那些原先按照 MPL 发布的文件变成了 MPL 和 GNU 双重许可证。最终的结果是，较大作品整体上按照 GNU 许可证发布。收到组合程序的人，如果要使用原来遵循 MPL 的文件，可以继续按照 MPL 使用这些文件；如果要按照 GNU 许可证的条款整体或部分地发布较大作品，那么也没有限制。

这里的重点是，其中关于 MPL 的条款仅适用于第一次创作和发布较大作品。如果此条款也必须应用于后续作品，那么它就是一个额外限制条件，就不兼容 GPL 和 AGPL 了。理解了这一点，当你为已有项目做贡献时，我们通常建议你使用和项目一样的许可证；即使没人要求你这样做，也是一样。如果你获得一个使用 GNU 许可证的作品，其中有些文件同时也使用 MPL，那么你应该只移除那些非常必要的文件的 MPL 许可证。

在创作较大作品之前，请查看其中使用 MPL 软件的许可证声明。有些使用 MPL 2.0 发布初始软件的贡献者可能会选择取消以上兼容条款，其许可证声明中会加一句话，说该作品 “不兼容次级许可证”。任何带有此声明的软件都不兼容 GPL 和 AGPL。

使用前期 MPL 版本的软件可以升级到版本 2.0，但是任何还没有使用以上 GNU 许可证的软件必须标记为不兼容次级许可证。这意味着仅使用早期 MPL 许可证的软件仍然不兼容 GPL 和 AGPL。

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

该许可证基于 Expat and 修改版 BSD 许可证。它是一个松散的、纵容型、非 copyleft 的自由软件许可证，兼容 GNU GPL。

Netscape JavaScript 的许可证 (#NetscapeJavaScript)

这是一个 Netscape 公共许可证和 GNU GPL 的或组合。因此，它是一个自由软件许可证，兼容 GNU GPL，但是不是强 copyleft。

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

这是一个纵容型、非 copyleft 的自由软件许可证，它兼容 GNU GPL。

Perl 5 及更低版的许可证 (#PerlLicense)

该许可证是 Artistic 许可证 1.0 和 GNU GPL 的或集—换句话说，你可以在这两个许可证中任选一个。它是自由软件许可证，但并不是真正的 copyleft 许可证。因为它选 GNU GPL 作为一个选项，所以它兼容 GNU GPL。

我们建议你的 Perl 4 或 Perl 5 软件包使用该许可证，这样可以促进 Perl 程序的和谐和一致。除了 Perl 之外，我们强烈敦促你不要使用该许可证；只使用 GNU GPL 更好。

公有领域 (#PublicDomain)

属于公有领域并不是拥有一个许可证；而是反过来，属于公有领域的材料是没有版权的，也没有必要有许可证。不过，实际来说，如果一个作品属于公有领域，那么它也可能具有非 copyleft 的、全权的自由软件许可证。公有领域的材料兼容 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, Inc. 的数据文件和软件许可证协议 (#Unicode)

这是 Unicode, Inc. 对 Unicode 字符数据库采用的许可证——此数据库是帮助开发者在其程序中实现 Unicode 标准的各种数据文件。这是一个松散的纵容型许可证，并和所有版本的 GPL 兼容。

你在自己的软件中使用按该许可证协议授权的文件，应该没有任何问题，但是我们建议你在软件中包含该协议的全文拷贝。因为有些文件带有另外的非自由许可证条款、或者没有任何许可证信息，所以全文拷贝会让其他想要分发你的软件的人避免混淆。当然，你也应该按照该许可证协议的条款分发这些文件，但是这就比较直接了当了。

请注意弄清楚你使用的文件确实使用的是该许可证协议。Unicode, Inc. 发布的其他文件使用的是 Unicode Terms of Use，这是一个不同的、非自由的许可证，这两个许可证出现在同一个页面，但是授权给不同的文件。此许可证协议的最上部写明了它授权的文件。

你自己的软件请不要使用该许可证协议。如果你要的是松散的纵容型许可证，请对小型项目使用 Expat 许可证，对大型项目使用 Apache 2.0 许可证。这些才是更通用、在自由软件社区被更广泛认同的许可证。

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

这是一个松散的、纵容型非 copyleft 的自由软件许可证，它兼容 GNU GPL。该许可证提供了对软件作品的专利许可证能力，不过如果要用松散许可证的话，我们还是推荐 Apache 2.0 许可证，它可以避免专利背叛。

Unlicense (#Unlicense)

Unlicense 是对公有领域的献礼。按照 Unlicense 授权的作品按照法律允许的最大限度奉献给公有领域，并且它还有一个附加的松散型许可证，用来覆盖法律奉献不足的地方。Unlicense 的公有领域条款和附加松散型许可证都兼容 GNU GPL。

Vim 许可证，版本 6.1 及以后版 (#Vim)

这是一个自由软件许可证，不是真正意义的 copyleft 许可证。它使用一个明确的转换条款兼容 GPL。

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

这是一个兼容 GPL 的自由软件许可证。

WebM 的许可证 (#WebM)

Google 的 WebM 实现使用修改版 BSD 许可证。Google 也为其拥有或控制的专利提供了单独的专利许可证(令人困惑地称之为 “附加 IP 授权”)，这些专利涉及其 WebM 的实现。GPL 软件可以和此许可证条款兼容：它允许分发者运用 GPL 赋予的权利，同时满足所有 GPL 的条件。因此，WebM 许可证是自由的，并兼容 GPL。

WTFPL，版本 2 (#WTFPL)

这是一个松散的、纵容型、非 copyleft 的自由软件许可证，它兼容 GNU GPL。

我们并不推荐使用此许可证。如果你要为小型程序使用松散的纵容型许可证，我们建议使用 X11 许可证。更大型的程序通常就应该是 copyleft 的；不过，如果你坚持使用松散的纵容型许可证，我们建议你使用 Apache 2.0 许可证，它可以保护用户不受专利背叛的侵害。

WxWidgets 库许可证 (#Wx)

WxWidgets 许可证是一个兼容 GPL 的自由软件许可证。它由 GNU Lesser GPL 2.0 或者其任何以后版本，加上一个额外的允许分发者按照自选的许可证(包括专有)发布使用该库的二进制的条款。它是弱 copyleft 的，甚至比 LGPL 还要弱，所以我们建议只在特殊情况下使用它。

WxWindows 库许可证(#Wxwind)

WxWidgets 库许可证的老名字。

X11 许可证 (#X11License)

这是一个松散的、纵容型非 copyleft 自由软件许可证，它兼容 GNU GPL。老版本的 XFree86 使用同样的许可证，现在还有些 XFree86 的变种也在使用该许可证。后来的 XFree86 版本使用的是 XFree86 1.1 许可证。

有些人称之为 “MIT 许可证”，但是这样是误导，因为 MIT 使用多种软件许可证。这样也很含糊，因为同一批人也把 Expat 许可证叫做 “MIT 许可证”，不做区分。我们建议不要使用 “MIT 许可证” 一词。

X11 许可证和 Expat 许可证的区别是 X11 许可证有个关于使用 X Consortium 名称的额外段落。虽然不是什么大问题，但它就是区别所在。

对小型程序来说，这个许可证没问题。较大的程序通常就应该是 copyleft 的；但是如果你要为大型程序使用松散的、纵容型许可证，我们建议你使用 Apache 2.0 许可证，它会保护软件用户不被专利背叛侵害。

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

这是一个松散的、纵容型非 copyleft 的自由软件许可证，它兼容 GPL v3。

请注意此许可证不兼容 GPL v2，这是因为它对所有包含致谢的文档有额外要求。

目前有好几个 XFree86 的变种，只有其中一部分使用该许可证。还有些继续使用 X11 许可证。

ZLib 的许可证 (#ZLib)

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

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

这是一个松散的、纵容型非 copyleft 的自由软件许可证，它兼容 GNU GPL。

不兼容 GPL 的自由软件许可证

(#GPLIncompatibleLicenses)

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

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

Affero 通用公共许可证是一个自由软件许可证、copyleft，它不兼容 GNU GPL。它包含 GNU GPL 版本 2，但是 Affero 添加了 FSF 批准过的额外一节。新的一节是 2(d)，它覆盖通过网络服务或计算机网络发布的应用程序。

该许可证已经被 GNU Affero 通用公共许可证版本 3 替代；请使用新版本。

Academic 自由许可证，一直到 3.0 的所有版本 (#AcademicFreeLicense)

Academic 自由许可证是一个自由软件许可证，非 copyleft，不兼容 GNU GPL。其最近的一些版本带有类似开放软件许可证的条款，因此应该避免使用这些版本。

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

这是一个纵容型非 copyleft 的自由软件许可证。它带有一些条款使之不兼容 GNU GPL，比如它强烈禁止使用和 Apache 相关的名称。

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

这是一个松散的、纵容型非 copyleft 的自由软件许可证，带有一个广告条款。该条款造成了和原始 BSD 类似的实际问题，这也造成它不兼容 GNU GPL。

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

这是一个自由软件许可证，它不兼容 GNU GPL。我们不建议对新写的软件使用该许可证，但是对已经使用该许可证的软件进行改进没有问题。更多解释。

BitTorrent 开放源代码许可证 (#bittorrent)

这是一个自由软件许可证，但是它不兼容 GPL，理由同 Jabber 开放源代码许可证。

原始 BSD 许可证 (#OriginalBSD)

它有时也被叫做 “4-段论 BSD 许可证”.

它是一个松散的、纵容型非 copyleft 的自由软件许可证，带有严重漏洞：“让人恼火的 BSD 广告条款”。这个漏洞并不致命；就是说，它并不让软件变成非自由的软件。但是却带来实际的问题，并使之不兼容 GNU GPL。

我们强烈不建议你的软件使用原始 BSD 许可证。如果你想要一个松散的、纵容型非 copyleft 的自由软件许可证，那么使用修改版 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 宽通用公共许可证差不多的弱 copyleft 属性。因为它没有带有基础 CeCILL 中明确的兼容条款，所以它不兼容 GNU GPL。

请不要使用该许可证发布软件。

共同开发和发布许可证(CDDL)，版本 1.0 (#CDDL)

这是一个自由软件许可证。它是一个按文件的弱 copyleft 许可证(类似 Mozilla 公共许可证 1)，这就使之不兼容 GNU GPL。这意味着一个使用 GPL 的模块和一个使用 CDDL 不能合法的连接到一起。我们因此强烈建议你不要使用 CDDL。

关于为什么不能组合 CDDL 许可证作品和 GPL 许可证作品的举例说明，请看自由软件基金会的表述，解释、执行和改变 GNU GPL，在组合 Linux 和 ZFS 情况下的应用。

另外，CDDL 也不幸使用了 “知识产权” 这个术语。

普通公共属性许可证 1.0 (CPAL) (#CPAL)

这是一个自由软件许可证。它以 Mozilla 公共许可证版本 1 为基础，因此不兼容 GPL：它对软件的修改版有好几个 GPL 没有的要求。它还要求如果你允许其他人使用软件，你需要公布程序的源代码。

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

这是一个自由软件许可证。不幸的是，它的弱 copyleft 属性和选择使用法律条款使之不兼容 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 基本是一样的。唯一的变化是版本 2.0 为某些代码明确提供了可以使用 GNU GPL 版本 2 或以后版作为 “次级许可证” 的选项。

如果原始贡献者将某些代码发布，并指明以 GNU GPL 版本 2 或以后版本作为次级许可证，那么这个代码就兼容 GPL 的这些版本。(对用户来说，这样做大致相当于把这些代码按照 EPL | GPL 双许可证发布。)不过，不带该指示条款的 EPL2 还是不兼容 GPL。

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

这是一个自由软件许可证。就该许可证本身而言，它具有和 GPL 类似的 copyleft 属性，但并不兼容。不过，它给了许可证接受方重新选择某些再授权许可证的方法，其中——Eclipse 公共许可证和普通公共许可证——只是弱 copyleft 的许可证。因此，开发者不能依赖此许可证来保证强 copyleft。

EUPL 允许使用 GPLv2 再授权，因为 GPLv2 列在其可再授权许可证里。它也非直接地允许使用 GPLv3 再授权，因为它可以使用 CeCILL v2 再授权，而 CeCILL v2 可以再授权给任何版本的 GNU GPL。

要完成此两步再授权，你首先要让代码的许可证支持 CeCILL v2，把该代码添加到使用 EUPL 许可证的程序中，做好再授权到 CeCILL v2 的准备。然后，然后你再找到或撰写按照 GPLv3+ 许可证授权的代码，并添加到程序中。这样，最后使用 CeCILL 许可证的程序就有了再授权到 GPLv3+ 的基础。

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

这是一个自由软件许可证。就该许可证本身而言，它具有和 GPL 类似的 copyleft 属性，但并不兼容。不过，它给了许可证接受方重新选择某些再授权许可证的方法，其中——Eclipse 公共许可证——只是弱 copyleft 的许可证。因此，开发者不能依赖此许可证来保证强 copyleft。

EUPL 只允许再授权到 GPLv2 或 GPLv3 中的一个，因为这两个许可证是可再授权许可证中的两个选项。它还间接地允许再授权到 GPL 版本 3 或者以后版本，因为你可以再授权到 CeCILL v2，而 CeCILL v2 有方法可以再授权到任何版本的 GNU GPL。

Fraunhofer FDK AAC 许可证 (#fdk)

这是一个自由软件许可证。它不兼容任何版本的 GNU GPL。

该许可证有一个危险，它表述了它不授权给你任何专利许可，并希望你购买专利。因此，而且因为该许可证的作者是周知的专利侵略者，我们建议你使用该许可证发布或再发布软件时要小心：首先要考虑许可证发布方是否可能在诱惑你进入专利侵权。如果你判断相关程序是专利陷阱的诱饵，那么避开该程序是明智之选。

相关的专利也有可能已经失效。根据 Fraunhofer 是否还有有效的专利保护这些作品，相关软件可能是陷阱，也可能不是。(当然，任何程序都可能被专利威胁，唯一的方法是把专利法改成对软件是安全的专利法。)

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 没有问题。

微软公共许可证(Ms-PL) (#ms-pl)

这是一个自由软件许可证；它不是强 copyleft，也不兼容 GNU GPL。因此，我们强烈建议你不要使用 Ms-PL 许可证。

微软互惠许可证(Ms-RL) (#ms-rl)

这是一个自由软件许可证。它以微软公共许可证为基础，添加了一些略微增强 copyleft 的条款。它也不兼容 GNU GPL，因此我们强烈建议你不要使用 Ms-RL 许可证。

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

这是一个自由软件许可证，不是强 copyleft；不像 X11 许可证，该许可证有一些复杂的限制使之不兼容 GNU GPL。就是说，一个 GPL 模块和一个 MPL 模块不能合法连接到一起。因此我们强烈建议你不要使用 MPL 1.1 许可证。

不过，MPL 1.1 有一个条款(section 13)允许程序(或程序的一部分)选择另一个许可证。如果程序的某个部分允许 GNU GPL 或其他兼容 GPL 的许可证作为另一个许可证，那么该部分程序兼容 GPL。

MPL 版本 2.0 有一些改进，包括默认兼容 GPL。请参看该条目了解详情。

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

这是一个自由软件许可证，基本上和 Mozilla 公共许可证版本 1.1 一样。也如 MPL，NOSL 有一些复杂的限制使之不兼容 GNU GPL。就是说，一个 GPL 模块和一个 NOSL 模块不能合法连接在一起。因此我们强烈建议你不要使用 NOSL。

Netscape 公共许可证(NPL)，版本 1.0 和 1.1(#NPL)

这是一个自由软件许可证，不是强 copyleft，不兼容 GNU GPL。它是 Mozilla 公共许可证版本 1.1 加上一个条款允许 Netscape 使用你添加的代码，即使是用在他们的专有软件里。当然，他们并没有对等地给你许可来使用他们的代码。我们强烈建议你不要使用 NPL。

Nokia 开源许可证 (#Nokia)

它和 Mozilla 公共许可证版本 1 类似：是一个不兼容 GNU GPL 的自由软件许可证。

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

这是一个纵容型、非 copyleft 的自由软件许可证，它有一些要求(在第 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 的许可证。你必须遵守这两个许可证。这两个许可证联合的结果是该许可证是一个 copyleft 的自由软件许可证，它不兼容 GNU GPL。它还有一个广告条款，就像原始 BSD 许可证和 Apache 1 许可证一样。

我们建议你在软件中使用 GNUTLS 代替 OpenSSL。不过，没有理由不使用 OpenSSL 和已经使用 OpenSSL 的应用。

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

这是一个自由软件许可证，但是不兼容 GPL。其第 5 节使之不兼容 GPL。

PHP 许可证，版本 3.01 (#PHP-3.01)

大多数 PHP4 使用此许可证。它是一个非 copyleft 的自由软件许可证。由于它包含了对衍生产品使用 “PHP” 名称的严格限制，所以它不兼容 GNU GPL。

我们建议你除 PHP 附加组件外不要使用该许可证。

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

这是一个自由软件许可证，它不兼容 GNU GPL。主要的不兼容性在于此 Python 许可证受美国弗吉尼亚州法律管辖，而 GPL 不允许这样。

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

这是一个非 copyleft 的自由软件许可证，它不兼容 GNU GPL。因为它要求更改只能以 patch 的形式发布，所以它还给实际使用带来了巨大的不便。

我们建议你不要为自己的软件使用 QPL，而且只在绝对必要时再使用 QPL 软件包。不过，此建议不再适用于 Qt 本身，因为 Qt 也按照 GNU GPL 发布了。

由于 QPL 不兼容 GNU GPL，所以你不能把 GPL 程序和 QPL 程序连接到一起，无论如何都不行。

不过，如果你写的程序使用了 QPL 库(比如 FOO)，如果你想把你的程序按照 GNU GPL 发布，那么这个比较容易。你可以添加以下声明解决你的程序面临的问题：

作为一个特别的例外，你有权将此程序和 FOO 库连接，并发布可执行文件，
  只要除 FOO 之外的所有可执行文件都符合 GNU GPL 的要求。

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

RPSL 是一个自由软件许可证，它由于这几点不兼容 GPL：它要求衍生作品使用 RPSL 条款，并要求在华盛顿州西雅图处理诉讼。

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

这是一个自由软件许可证，不是强 copyleft，它不兼容 GNU GPL，只是因为细节而不是因为主要政策。

Sun 公共许可证 (#SPL)

它基本和 Mozilla 公共许可证版本 1 一样：是一个不兼容 GNU GPL 的自由软件许可证。请不要把它和 Sun 社区源代码许可证混淆，后者不是自由软件许可证。

xinetd 的许可证 (#xinetd)

这是一个 copyleft 的自由软件许可证，它不兼容 GPL。它对修改版的发布做出了一些和 GPL 发布修改版相冲突的额外限制，所以它不兼容 GPL。.

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

这是一个自由软件许可证。它的 copyleft 属性和 Mozilla 公共许可证类似。它在第 7 节还有一个法律条款的选择。这些都使之不兼容 GPL。此许可证也不幸地使用了 “知识产权” 这个术语。

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

PHP4 有一个部分使用了该许可证。它是一个非 copyleft 地自由软件许可证，不兼容 GNU GPL，它有类似原始 BSD 许可证有的实际操作问题。

我们建议你自己的软件不要使用此许可证。

Zimbra 公共许可证 1.3 (#Zimbra)

此许可证和 Yahoo! 公共许可证 1.1 一样，只是它由 VMWare 而不是由 Yahoo! 提供。我们的评论适用于此许可证；它是不兼容 GPL 的部分 copyleft 的自由软件许可证。

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

这是一个松散的、相当纵容的非 copyleft 自由软件许可证，它有和原始 BSD 许可证类似的实际操作问题，它不兼容 GNU GPL。

我们建议你的软件不要使用 ZPL 版本 1。不过，没有理由避免运行已经按照该许可证发布的软件，包括 Zope 以前的版本。

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

非自由软件许可证

(#NonFreeSoftwareLicenses)

这些许可证不是自由软件许可证。非自由软件许可证当然不兼容 GNU GPL。

当然，我们强烈建议你避免使用非自由软件许可证，并且尽可能避免非自由软件。

我们无法在此列举全部的非自由软件许可证；毕竟，每个专有软件公司都有自己的许可证。此处，我们关注那些经常被误解为是自由软件许可证，而实际上，不是自由软件许可证的许可证。

在不违反我们的常规政策的情况下，我们会提供这些许可证的链接：我们不会链接促进、鼓励或帮助使用非自由软件包的链接。我们不会做非自由软件的免费推广，我们尽可能避免更多人使用非自由软件。同样地，除非有充足的理由，我们避免指出使用这些许可证的程序名称。

No license (#NoLicense)

如果源代码没有带有给予其用户四个基本自由的许可证，除非它明确并有效地说明是公有领域作品，那么它不是自由软件。

有些开发者认为没有许可证的代码自动是公有领域作品。在当今的版权法之下，这个不对；反之，任何可以有版权的作品默认是受版权法保护的。这些作品包括程序。没有许可证不会给予用户自由。在有些国家，用户下载没有许可证的代码，仅仅是编译或运行这些代码就已经侵犯了版权。

有些国家允许作者将代码放到公有领域，但是需要明确的操作，而且如何操作会随着法律框架不同而变化。在大多数情况下，最好使你的代码使用 copyleft 许可证，这样的代码可以让所有用户都获得自由。

由美国政府雇员编写的代码是特例，因为美国版权法明确把这些代码放到公有领域；但是这个不包括美国政府付钱让某个公司做的工作。它也不适用于其他国家，许多国家允许政府拥有自己写的代码的版权。

Aladdin 自由公共许可证 (#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 的网站，也需要许可证。这并不构成实际操作的问题，因为该许可证已经授权此链接。(无论怎样，人们不应该增加指向非自由软件的链接。)但是这种要求不合理，也不应该被推广。

代码项目开放许可证，版本 1.02 (#cpol)

代码项目开放许可证不是一个自由软件许可证。其第 5.6 节限制人们使用其作品。其第 5.4 节本身就禁止其软件的商业发布——根据你对第 3.4 的不同解读，你可能根本无权发布其软件本身。

Commons Clause (#comclause)

“Commons Clause(共用条款)” 不是自由软件许可证，因为它禁止销售程序拷贝，甚至禁止以任何商业服务的一部分来运行程序。更离谱的是，它还曲解 “commons(共用)” 和 “sell(销售)。”

我们强烈建议人们拒绝使用此许可证的程序并开发其自由软件替代。如果程序以前的版本是自由软件，那么继续在以前版本上开发也是一个选项。

CNRI 数字对象集合许可证协议 (#DOR)

这是一个非自由的许可证，因为其第 3 条有争议地包含了不许违背任何被运行程序的许可证的要求——即使是专有软件的许可证。

eCos 公共许可证，波拿巴 1.1 (#eCos11)

这是 eCos 的老许可证。它不是自由软件许可证，因为它要求把每个已发布的修改版都发送给特定的初始开发者。其中还有一些措辞的意思我们不是太清楚，可能也会是个问题。

现今，eCos 使用 GNU GPL 加上允许连接非自由软件的额外许可。

Hippocratic 许可证 1.1 (#hippocratic)

这不是一个自由软件许可证，因为它限制了用户使用软件的目的。这一点违背了自由之零。该条目以前是以 First Do No Harm 许可证列出来的。

公共管理计算机软件的 GPL (#GPL-PA)

GPL-PA(其原始名称是葡萄牙语 “Licença Pública Geral para Administração Pública”)由于以下原因不是自由软件许可证：

它只允许在 “普通情形下” 使用。
它不允许发布没有二进制的源代码。
它以 50 年为一个循环。

Hacktivismo 增强源代码软件许可证协议(HESSLA) (#HESSLA)

这不是一个自由软件许可证，因为它限制用户使用软件的目的，并大量限制软件修改版的使用目的。

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

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

JSON 许可证 (#JSON)

这是 JSON 数据交换格式最初实现时使用的许可证。它使用 Expat 许可证作为基础，但是加了一项强制条款：“此软件应该做善事，而不能做坏事。”这个条款违反了自由之零：它限制软件的使用目的。虽然此条款可能很难强制执行，但是我们也不能如此假设。因此，这是一个非自由的许可证。

ksh93 的老许可证 (#ksh93)

ksh93 常常是按照其老的许可证来传播的，这不是一个自由软件许可证。其中一个原因是它要求所有的改动都要发给其开发者。

Lha 的许可证 (#Lha)

lha 许可证因为太过模糊以至于你都不知道自己有什么权利，所以必须当作是一个非自由软件许可证。

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

该许可证不允许商业发布，而且只允许特定情况下的商业使用。

微软还有一些描述 “共享源代码” 的许可证，其中一些还有不同的限制。

NASA 开源协议 (#NASA)

NASA 开源协议，版本 1.3，不是一个自由软件许可证，因为它的一个要求是你的修改是 “原创”。自由软件的开发依赖合并第三方代码，而 NASA 许可证不允许。

我们强烈建议你不要使用此许可证。另外，如果你是美国公民，请写信告知 NASA 应该使用一个真正的自由软件许可证。

Oculus Rift SDK License (#OculusRiftSDK)

这不是一个自由软件许可证；它有几个致命的漏洞。

你不能发布比整个 libOVR 程序少的东西。
你的发布权利会在模糊的条件下被中止。
修改版的作者要按需把修改版发给 Oculus。
只能在他们的产品里使用发布的程序。
新版许可证会完全取代旧版许可证，这就是说你已经获得的权利会被剥夺。

可能还有更多漏洞；已经看到这么多，我们就没有再看下去。开放公共许可证 (#OpenPublicL)

这不是一个自由软件许可证，因为它要求把每个已发布的修改版发送给特定的初始开发者。该许可证里还有许多我们不清楚含义的词语，它们可能也有问题。

Peer-Production 许可证 (#PPL)

Peer-Production 许可证不是一个自由软件许可证，因为它限制谁可以发布程序以及为什么目的发布。它也没有给予人们可以运行程序的权利。

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-style License其部分代码使用 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。)

文档的许可证

自由文档许可证

(#FreeDocumentationLicenses)

以下许可证是自由文档许可证。

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

该许可证目的是用于 copyleft 的自由文档。我们计划使之可用于所有 GNU 手册。它也适合其他多种有用作品(比如课本和字典)。其应用范围不限于文本作品(“书籍”)。

FreeBSD 文档许可证 (#FreeBSDDL)

这是一个纵容型、非 copyleft 的自由文档许可证，它兼容 GNU FDL。

苹果通用文档许可证，版本 1.0 (#ACDL)

这是一个自由文档许可证，它不兼容 GNU FDL。它的第 (2c) 节说 “你不能在此许可证上添加其他条款”，而 GNU FDL 有一些额外的条款普通文档许可证没有，所以二者不兼容。

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

此许可证可以作为自由文档许可证使用。它是一个 copyleft 的自由文档许可证，如果其版权持有者不执行列在此许可证第 VI 节的任何 “许可证可选项”。但是，如果执行了任何一项，该许可证就不是自由许可证了。总之，它不兼容 GNU FDL。

这就造成了使用或推荐此许可证的一个实际陷阱：如果你建议 “使用开放发行许可证，版本 1.0，但是不要那些选项”，那么你建议的后半部分很容易被遗忘；有人就可能使用此许可证并带着选项，这导致手册是非自由的，但是使用者还认为她是遵循建议执行的。

类似地，如果你使用该许可证并不带选项，而有人要学你，然后改了关于选项的部分，以为这只是细节；结果是她的文档不是自由文档。

因此，尽管在不使用该许可证提供的选项的情况下，按照该许可证发行的文档是自由文档，我们最好还是使用 GNU 自由文档许可证并避免导致他人误入歧途。

请注意此许可证和开放内容许可证不同。它们经常被混淆，因为开放内容许可证通常简写为 “OPL”。为了明确，请不要使用 “OPL” 这个简写来指代任何一个许可证。用全称是值得的，它有助于人们了解你的所指。

非自由的文档许可证

(#NonFreeDocumentationLicenses)

以下许可证不是自由文档许可证：

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

这不是一个自由文档许可证，因为限制对拷贝收费。我们建议你不要使用此许可证。

请注意此许可证和开放发行许可证不同。常用的 “开放内容许可证” 缩写是 “OPL”，它使大家对两者产生混淆。为了明确起见，最好不要使用 “OPL” 这个缩写。说出全称有助于大家的理解一致，所以是值得的。

Creative Commons NonCommercial，所有版本 (#CC-BY-NC)

这不是一个自由文档许可证，因为它限制对拷贝收费。所以，我们不建议你对自己的文档使用该许可证。

此外，它有一个弱点：如果修改版有许多作者，那么为了商用要获得所有人的许可是不现实的。

Creative Commons Noderivatives，所有版本 (#CC-BY-ND)

这不是一个自由文档许可证，因为它限制发行修改版。所以，我们不建议你对自己的文档使用该许可证。

其他作品的许可证

软件和文档之外的实用作品的许可证

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

GNU GPL 可以用于非软件类的通用数据，只要对实际场景定义好 “源代码” 的含义就行。可以看到，DSL(见下文)也要求你定义什么是 “源代码”，这和 GPL 的用法类似。

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

GNU FDL 被推荐用于所有课本和教学资料。(“文档” 简单来说就是课本和其他使用仪器设备或软件的教学资料。)我们还建议 GNU FDL 用于字典、百科全书，以及任何其他为实用目的提供信息的作品。

CC0 1.0 普适版 (#CC0)

CC0 是来自 Creative Commons 的对公有领域的奉献。按照 CC0 发布的作品会以法律许可的最大限度成为公有领域的作品。如果这个做不到，那么 CC0 还提供了一个松散的、纵容型许可证作为兜底。其公有领域作品和松散许可证都兼容 GNU GPL。

如果你希望自己的非软件作品置于公有领域，那么我们建议使用 CC0。我们不建议软件作品使用 CC0，因为其条款明确表达不会授予你任何专利许可证。

也因为缺少专利授予，我们恳请你小心使用遵循该许可证的软件；你应当首先考虑软件的许可证授权方是否会控告你侵犯专利。如果开发者拒绝授予用户专利许可证，那么其程序实际上就是一个陷阱，用户应该避免使用。

Creative Commons Attribution 4.0 许可证(又称 CC BY)(#ccby)

这是一个非 copyleft 的自由许可证，它适用于艺术和娱乐作品以及教育作品。它兼容 GNU GPL 的所有版本；不过，像全部 CC 许可证一样，它不应该用于软件。

(#which-cc)Creative Commons 发布了许多非常不同的许可证。因此，说一个作品 “使用 Creative Commons 许可证” 其实并没有回答该作品究竟使用什么许可证这个重要的问题。当你看到这样的情况，请要求作者清晰可见地陈述其作品究竟使用的是哪个 Creative Commons 许可证。如果有人建议某个作品应该 “使用 Creative Commons 许可证”，那么在执行之前问清楚 “使用哪个 Creative Commons 许可证？” 是非常关键的。

Creative Commons Attribution-Sharealike 4.0 许可证(又称 CC BY-SA) (#ccbysa)

这是一个 copyleft 的自由许可证，它适用于艺术和娱乐作品以及教育作品。像全部的 CC 许可证一样，它不应该用于软件。

CC BY-SA 4.0 单向兼容 GNU GPL 版本 3：就是说你对 CC BY-SA 4.0 作品的修改版可以使用 GNU GPL 版本 3，但是 GPL 3 许可证的作品可能无法再使用 CC BY-SA 4.0 许可证。

由于 Creative Commons 只把 GNU GPL 版本 3 列在其兼容许可证列表里，所以这就意味着你不能让修改过的 CC BY-SA 作品使用 “GNU GPL 版本 3，或(按你的选择)任何以后版本。”。不过，GNU GPL 版本 3 的第 14 节允许许可证授予方定义决定是否使用 GNU GPL 以后版本的代理。因此，如果有人修改了一个 CC BY-SA 4.0 作品并把它用于一个使用 GNU GPL 版本 3 的项目，那么他们可以定义 Creative Commons 作为他们的代理(通过 http://creativecommons.org/compatiblelicenses)，这样当 Creative Commons 决定某个将来版本的 GNU GPL 是兼容许可证，那么修改版本和合并后的作品就可以使用那个版本的 GNU GPL。

请具体说明使用的是哪个 Creative Commons 许可证。

Design Science 许可证(DSL) (#dsl)

这是一个针对常规数据的自由和 copyleft 许可证。请不要用于软件和文档，因为它不兼容 GNU GPL 和 GNU FDL；不过，它可以用于其他数据。

自由艺术许可证 (#FreeArt)

这是一个针对艺术作品的自由和 copyleft 许可证。像任何自由许可证一样，它允许商业发布。它是一个 copyleft 许可证，因为任何包含其作品的较大作品或者使用此许可证发布，或者必须使用符合已知标准的类似许可证发布。请不要用于软件或文档，因为它不兼容 GNU GPL 和 GNU FDL。

开放数据库许可证 (#ODbl)

这是一个针对数据的自由和 copyleft 许可证。它不兼容 GNU GPL。请不要用于软件或文档，因为它不兼容 GNU GPL 和 GNU FDL。它提出不太便利的要求——通过签署合同来达到数据的 copyleft 效果，而数据其实不能版权化，所以我们不建议使用此许可证；不过，没有理由避免使用已经按此发布的数据。

字体的许可证

(#Fonts)

以下许可证用于计算机文件的设计，而不是艺术设计。就我们所知，设计的实现总是可以版权化的。艺术设计的法律状态就比较复杂，随着法律体系而变化。

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

GNU GPL 能用于字体。不过，请注意它不允许将字体嵌入到文档中，除非文档也是 GPL 的。如果你想这样做，请使用字体例外。请同时参看关于 GPL 字体例外的解释文章。

Arphic 公共许可证 (#Arphic)

这是一个自由和 copyleft 许可证，不兼容 GPL。它正常用于字体，在这种情况下，不兼容不造成问题。

LaTex ec 字体的许可证 (#ecfonts)

该许可证覆盖到 European Computer Modern 字体和 Text Companion 字体，它们在 LaTeX 中常用。根据使用的方式，它可能是自由的，也可能不是。如果字体包说某些字体不能修改，那么该字体包是非自由的。其他情况，字体包是自由的。初始的字体不限制修改，故是自由的。

很像 LaTeX 项目公共许可证 1.2，本许可证要求修改版作品使用和所有以前版本都不同的名称。这对要和 LaTeX 一起使用的作品是可接受的，因为 TeX 允许你创建文件名映射，但是对其他使用场景就非常讨厌并且可能工作量巨大。

IPA 字体许可证 (#IPAFONT)

这是一个自由和 copyleft 许可证，不兼容 GPL。它有一个不幸的条件，它要求衍生作品不能以程序名、字体名或文件名使用或包括初始的作品。这对字体还可以接受，因为字体可以使用自由软件工具改名或提供昵称，但是在其他使用场景下就非常讨厌并且可能工作量巨大。

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

开放字体许可证(包括其初始版，版本 1.0)是一个针对字体的自由和 copyleft 许可证。其唯一的不寻常要求是，当你销售字体时，你必须绑定某些软件，而不能单独销售。因为一个简单的 Hello World 程序也满足此要求，所以这条也算无害。我们和 SIL 都不建议将此许可证用于字体之外的其他作品。