在这里,我们尽量列举最常见的自由软件许可证,但是我们不能全部都列举完;我们会尽最大努力去回答关于自由软件许可证的问题,不管问题涉及的自由软件许可证是否列在这里。许可证会大致按照字母顺序在每个章节列出。
-
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 做出点滴贡献的人签署一份免责声明;这就是一个解决方案。如果你从事的项目没有此类正式的贡献者政策,那么 CC0 是一个人人可用的好工具。它正式确认你的作品属于公有领域,并为法律不允许的情况提供一份保底的许可证。
-
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。如果你想把自己的作品奉献给公有领域,那么我们建议你使用 CC0。CC0 也是对公有领域的献礼,也带有一个保底许可证,不过它比 Unlicense 更全面和更成熟。
-
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。
-
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。要完成此两步再授权,你首先要让代码的许可证支持 CeCILL v2,把该代码添加到使用 EUPL 许可证的程序中,做好再授权到 CeCILL v2 的准备。然后,然后你再找到或撰写按照 GPLv3+ 许可证授权的代码,并添加到程序中。这样,最后使用 CeCILL 许可证的程序就有了再授权到 GPLv3+ 的基础。
-
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 许可证是两个许可证的联合,一个是 “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 的要求。
如果你是程序的版权所有者,你就可以合法地这样做。请把这个说明添加在源文件里,就放在声明本程序使用 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 的许可证。
在不违反我们的常规政策的情况下,我们会提供这些许可证的链接:我们不会链接促进、鼓励或帮助使用非自由软件包的链接。我们不会做非自由软件的免费推广,我们尽可能避免更多人使用非自由软件。同样地,除非有充足的理由,我们避免指出使用这些许可证的程序名称。
表达人们观点的作品——备忘录、评论等——其目的和实用性作品如软件和文档有根本区别。因此,我们期望它们为接收方提供不同的许可:就是全文复制和发布作品的权限。在演说中,Richard Stallman 先生经常讨论此问题。
3D 打印物体的设计也是有实用目的的,也应该有自由许可证。我们建议使用 GNU GPL 或一个自由版的 Creative Commons 许可证:CC-BY、CC-BY-SA 或 CC0。