license-compatibility.html - en to zh_CN translation catalogue (54 entries)

note: type: Content of: <title>
en: License Compatibility and Relicensing - GNU Project - Free Software Foundation
zh_CN: 许可证兼容性和再次授权 - GNU 工程 - 自由软件基金会

note: type: Content of: <div><h2>
en: License Compatibility and Relicensing
zh_CN: 许可证兼容性和再次授权

note: type: Content of: <div><address>
en: by Richard Stallman
zh_CN: Richard Stallman 著

note: type: Content of: <div><p>
en: If you want to combine two free programs into one, or merge code from one into the other, this raises the question of whether their licenses allow combining them, or prohibit combining them.<a href="#f1">[1]</a>
zh_CN: 如果你要把两个自由程序合而为一，或者把其中之一的代码并入另一个，那么就会有一个它们的许可证是否允许/禁止这样做的问题。<a href="#f1">[1]</a>

note: type: Content of: <div><p>
en: There is no problem merging programs that have the same license, if it is a reasonably behaved license, as nearly all free licenses are.<a href="#f2">[2]</a>
zh_CN: 如果两个软件使用同样的许可证，应该没有问题，假定该许可证象几乎所有的自由软件许可证一样顺理成章。<a href="#f2">[2]</a>

note: type: Content of: <div><p>
en: What then when the licenses are different? In general we say that several licenses are <em>compatible</em> if there is a way to merge code under those various licenses while complying with all of them.  The result, often, is a program with parts under various different compatible licenses&mdash;but not always.  Such combinability, or the absence of it, is a characteristic of a given set of licenses, and is not dependent on what order you mention them in.  The set of licenses also controls which license is required for the combined program.
zh_CN: 那么如果许可证不一样会如何呢？一般来说，如果有方法可以合并代码而又能同时遵循各个代码的许可证，那么我们就说这些许可证是 <em>兼容的</em>。其结果经常是一个由各个部分使用不同许可证的组合程序&mdash;&mdash;但也不尽然。具有这个兼容性，或者没有此兼容性，是许可证组合在一起的特点，这个特点并不依赖于你使用它们的顺序。该许可证组合还决定着该合并程序需要哪个许可证。

note: type: Content of: <div><p>
en: We divide licenses into three classes: lax (also &ldquo;permissive&rdquo; or &ldquo;pushover&rdquo;), intermediate, and copyleft.  A lax license does nothing to interfere with putting the code into proprietary software.  A copyleft license prohibits that, by requiring all reuse to be in programs under the same license.  An intermediate license puts some conditions on adding proprietary code but does not try to prohibit it.
zh_CN: 我们把许可证分为三类：松散型（也即 &ldquo;纵容型&rdquo; 或者 &ldquo;顺从型&rdquo;），中间型和 copyleft 型。松散型许可证不介意专有软件使用其代码。copyleft 许可证禁止专有软件使用其代码，它明确要求所有使用其代码的程序都要使用同样的许可证。中间型许可证限制但并不禁止专有软件使用其代码。

note: type: Content of: <div><p>
en: In general, lax permissive licenses (modified BSD, X11, Expat, Apache, Python, etc.) are compatible with each other.  That's because they have no requirements about other code that is added to the program.  They even permit putting the entire program (perhaps with changes)  into a proprietary software product; thus, we call them &ldquo;pushover licenses&rdquo; because they can't say &ldquo;no&rdquo; when one user tries to deny freedom to others.
zh_CN: 一般地，松散型许可证（修改版 BSD、X11、Expat、Apache、Python 等）是互相兼容的。这是因为它们对添加到程序里的代码并无要求。它们甚至允许把整个程序（或许带有修改）添加到专有软件之中；因此，我们称之为 &ldquo;顺从型许可证&rdquo;，理由是它们在用户的自由被否定时没有说 &ldquo;不&rdquo;。

note: type: Content of: <div><p>
en: In a combination of programs under lax licenses, each part carries the license it came with.  When the code is merged to the point that the parts can't be distinguished any more, that merged code should carry all the licenses of the merged parts.  Since all the licenses are lax anyway, this causes no practical problem except that the list of licenses gets long.<a href="#f3">[3]</a>
zh_CN: 在把使用松散型许可证的代码合在一起时，组合程序的每个部分都带有自己的许可证。当这些代码交织在一起无法分辨时，组合程序应该带上所有代码的许可证。由于这些许可证都是松散型的，所以全都带上除了太长之外也没有别的问题。<a href="#f3">[3]</a>

note: type: Content of: <div><p>
en: By the same token, lax licenses are usually compatible with any copyleft license.  In the combined program, the parts that came in under lax licenses still carry them, and the combined program as a whole carries the copyleft license.  One lax license, Apache 2.0, has patent clauses which are incompatible with GPL version 2; since I think those patent clauses are good, I made GPL version 3 compatible with them.
zh_CN: 同理可知，松散型许可证通常也和 copyleft 许可证兼容。在组合程序中，使用松散型许可证的代码仍然带着松散型许可证，而组合程序整体使用 copyleft 许可证。有一个松散型许可证，Apache 2.0，带有和 GPL v2 不兼容的专利条款；由于我认为这些专利条款还不错，所以我让 GPL v3 与之兼容了。

note: type: Content of: <div><p>
en: The one important exception is the original BSD license, because of the &ldquo;obnoxious advertising clause.&rdquo; This condition required a specific notice in <em>all</em> advertising of <em>any</em> product containing <em>any</em> code released under the original BSD license.  This was, and is, incompatible with all actual copyleft licenses.  It was also a pain in the neck for every distro, as programs accumulated with similar but different advertising requirements.  At one point, a BSD distro required over 70 different notices.
zh_CN: 因其 &ldquo;令人反感的广告条款&rdquo;，原始 BSD 许可证是一个重要的例外。该广告条款要求包含 <em>任何</em> 使用原始 BSD 许可证代码的 <em>任何</em> 产品的 <em>所有</em> 广告都要带有一个特定的声明。这种做法过去和所有已知的 copyleft 许可证都不兼容，现在也是。当程序里积攒了越来越多相似而又不同的广告声明时，每个发行版都忍受着一种如芒在背的痛苦。有段时间，一个 BSD 发行版需要包含 70 多个不同的声明。

note: type: Content of: <div><p>
en: I mostly eliminated this problem by convincing a dean, Hal Varian, to arrange for UC Berkeley to publish the &ldquo;modified BSD license&rdquo; (without the advertising clause) and rerelease the code of the Berkeley System Distribution under that.  Nowadays the original BSD license is (fortunately) rarely used, but we must still take care <a href="/licenses/bsd.html">not to talk about &ldquo;the&rdquo; BSD license</a>.
zh_CN: 我说服 Hal Varian，UC Berkeley 的一位校长，促使他们发布 &ldquo;修改版 BSD 许可证&rdquo;（没有广告条款）并将 BSD 代码按照此许可证发布。这样就基本上根除了上面所说的问题。现在，原始 BSD 许可证（所幸）已经很少被使用了，但是我们还是必须小心 <a href="/licenses/bsd.html">避免讨论 &ldquo;该&rdquo; BSD 许可证</a>。

note: type: Content of: <div><p>
en: In general, two different copyleft licenses are unavoidably incompatible unless they have explicit compatibility provisions.  This is not due to a mistake in the details; it's inherent in the idea of copyleft.  The idea of copyleft is that &ldquo;Modified and extended versions must be under the same license.&rdquo; If license A (on program P) says extended programs must be under license A, and license B (on program Q) says extended programs must be under license B, they have an irreconcilable disagreement; the license of the combined program which includes code from P plus code from Q would have to be A, <em>and</em> it would have to be B.
zh_CN: 一般来说，两个不同的 copyleft 许可证是无可避免地不兼容，除非两者之间有明确的兼容条款。这不是因为细节有误；这是 copyleft 理念与生俱来的特点。copyleft 的理念是 &ldquo;修改和扩展的版本必须延用同样的许可证。&rdquo;如果使用许可证甲的扩展程序 A 必须延用许可证甲，使用许可证乙的程序 B 必须延用许可证乙，那么它们之间就是不可调和；如果合并程序包含 A 和 B 的代码，那么合并程序的许可证必须是甲，<em>也</em>必须是乙。

note: type: Content of: <div><p>
en: This is why GPL version 2 is incompatible with GPL version 3; it could not be avoided.  Likewise, the conditions of CC-BY-SA 4.0 would be inherently incompatible with those of CC-BY-SA 3.0, and the authors could not have avoided this.
zh_CN: 这就是为什么 GPL v2 和 GPL v3 不兼容；这个无法避免。同样地，CC-BY-SA 4.0 的条件也天然不兼容 CC-BY-SA 3.0 的条件，其作者也无法避免这一点。

note: type: Content of: <div><p>
en: There are two approaches for avoiding the incompatibility problem caused by different versions of copyleft licenses.
zh_CN: 有两个方法来摆脱不同版本 copyleft 许可证带来的先天不兼容性。

note: type: Content of: <div><p>
en: The FSF uses the approach of asking people to release programs under &ldquo;GNU GPL version N or any later version.&rdquo; This licensing is compatible with version N, and also with N+1 (because it offers version N+1 as an option).  When you combine code under &ldquo;GPL 3 or later&rdquo; with code under &ldquo;GPL 2 or later,&rdquo; the license of the combination is their intersection, which is &ldquo;GPL 3 or later.&rdquo;
zh_CN: FSF 使用请求人们按照 &ldquo;遵循 GNU GPL 版本 N 或任何以后版本&rdquo; 来发布程序这一方法来解决此兼容性问题。这种授权兼容版本 N，也兼容版本 N+1（因为它确认版本 N+1 是可选项）。当你将遵循 &ldquo;GPL 3 或以后版&rdquo; 的代码和遵循 &ldquo;GPL 2 或以后版&rdquo; 的代码合并时，组合代码的许可证是它们的交集，就是 &ldquo;GPL 3 或以后版&rdquo;。

note: type: Content of: <div><p>
en: We hope we will never need to make a GNU GPL version 4, but nothing is perfect and we can't assume we have anticipated all the issues.  By releasing your code under GNU GPL 3 or later, you permit your code to upgrade to GNU GPL version 4 if we ever need one.
zh_CN: 我们希望我们再也不会有 GNU GPL v4，但是人无完人、世事难料，我们无法预见所有的情况。通过按照遵循 GNU GPL 3 或以后版本来发布程序，你就允许你的代码许可证升级到 GNU GPL v4，一旦我们发布了 v4。

note: type: Content of: <div><p>
en: The other approach is to make each version of the license explicitly allow upgrading to later versions.  The Mozilla Foundation uses this approach, as does PHP.  Creative Commons, uses it for CC-BY-SA: version 4.0 (the current version) explicitly permits any user to upgrade to later versions of CC-BY-SA for modified works.
zh_CN: 另一个方法是让每一个版本都明确允许升级到以后的版本。Mozilla 基金会使用该方法，PHP 也使用该方法。Creative Commons 对 CC-BY-SA 4.0 版（当前版）使用此方法：明确允许任何用户将修改版作品的许可证升级到以后版本的 CC-BY-SA。

note: type: Content of: <div><p>
en: Only the GNU licenses give authors a choice about whether to permit upgrades to future license versions.  When I wrote the first version of the GNU GPL, in 1989, I considered including a license upgrade option as is found now in CC licenses, but I thought it more correct to give that choice to each author.  Thus, the author could release a program either under &ldquo;GPL 1 only&rdquo; or &ldquo;GPL 1 or later.&rdquo;
zh_CN: 只有 GNU 许可证给了作者选择是否允许升级到未来许可证版本的权利。当年我编写第一个 GNU GPL 版本的时候，那是 1989 年，我曾经想过包含一个许可证升级的选项，就像现在的 CC 许可证一样，但是我觉得把选择权交给作者更正当。这样，作者就可以把其程序按照 &ldquo;只用 GPL 1&rdquo; 或者 &ldquo;用 GPL 1 或以后版&rdquo; 来发布。

note: type: Content of: <div><p>
en: Since then, I have come to question the wisdom of that decision.  Programs such as Linux, which allow only one GNU GPL version and reject license upgrades, cause practical incompatibility.<a href="#f4">[4]</a> If we ever make a GPL version 4, perhaps we should include an upgrade clause that automatically permits relicensing to higher-numbered versions, 5 and up.
zh_CN: 从那时起，我就在思量当时的决定是否明智。像 Linux 这样的程序，只允许一个版本的 GNU GPL 并拒绝升级许可证，这就导致实际上的不兼容。<a href="#f4">[4]</a>或许我们应该在 GPL v4 的时侯包含一个自动升级条款，如果我们需要版本 4 的话。

note: type: Content of: <div><p>
en: Some copyleft licenses allow cross-copyleft combinations with an explicit relicensing clause giving permission to put the code under a different copyleft license.  For instance, the CeCILL gives explicit permission to relicense code to GNU GPL version 2 and later versions.  If program P is under the CeCILL, and you want to combine it with program Q that's under GPL version 3 or later, the CeCILL says you can do that and put the combination or merged code under GPL version 3 or later.
zh_CN: 有些 copyleft 许可证有一个明确的再次授权条款，该条款允许将代码按照不同的 copyleft 许可证授权，这样就允许了 copyleft 许可证之间的交叉授权。例如，CeCILL 许可证明确许可将代码按照 GNU GPL v2 或以后版再次授权。如果程序 P 使用 CeCILL 许可证授权，而你想把它和按照 GPL v3 或以后版授权的程序 Q 合并在一起，那么 CeCILL 许可证允许你这么做，合并或组合的代码使用 GPL v3 或以后版授权。

note: type: Content of: <div><p>
en: Explicit relicensing permission is not the same thing as compatibility (though relicensing code can make it compatible with other code) and it is not symmetrical.  For instance, the CeCILL gives explicit permission to relicense code to GNU GPL, but the GNU GPL does not permit relicensing to the CeCILL.  Thus, you can't combine those two programs P and Q and distribute the combination under the CeCILL; that would violate the GPL in its use of program Q.  The only permitted way to release that combined program is under the appropriate GPL version(s).
zh_CN: 明确的再次授权许可和兼容性并不是一回事（虽然再次授权后的代码可以和其他代码兼容），二者也不对称。例如，CeCILL 许可证明确允许将代码再次授权给 GNU GPL，而 GNU GPL 并不允许将代码再次授权给 CeCILL。因此，你不能合并 P 和 Q 两个程序并把它们按照 CeCILL 许可证发布；那样就违反了 Q 程序使用的 GPL 许可证的要求。它们的合并程序只允许使用适当的 GPL 版本来发布。

note: type: Content of: <div><p>
en: Likewise, CC BY-SA 4.0 explicitly permits relicensing modified versions to GNU GPL version 3, but GPL version 3 does not permit relicensing to CC BY-SA.  This issue should never arise for software code; Creative Commons says its licenses are not meant for code, and says that the license to use for code is the GNU GPL.  But there are other kinds of works, such as hardware designs or game art, where you might have occasion to merge material released under CC-BY-SA with material released under the GNU GPL.  This can be done through CC BY-SA's explicit relicensing permission.
zh_CN: 类似，CC-BY-SA 4.0 明确允许修改版再次授权可以使用 GPL v3 许可证，但是 GPL v3 并不允许再次授权到 CC-BY-SA。这个问题应该不会影响软件代码；Creative Commons 许可证的说明指出它不用于代码，并且也指出如果是代码，应该使用 GNU GPL 许可证。但是还有一些其他种类的作品，比如硬件设计或游戏艺术等，这时就会碰到把使用 CC-BY-SA 的材料和使用 GNU GPL 的材料合并的问题。这种情况可以使用 CC-BY-SA 许可证中明确说明的再次授权条款。

note: type: Content of: <div><p>
en: Unfortunately, CC BY-SA 4.0 does not permit relicensing to future GPL versions.  What you should do, when you relicense material under CC BY-SA 4.0 to the GPL, is <a href="/licenses/rms-why-gplv3.html#future-proofing">specify yourself as a license version proxy</a> to indicate whether future GPL versions have been authorized for that material.  If someday there is a GPL version 4 and Creative Commons decides to allow relicensing from CC BY-SA to GPL version 4, you as proxy will be able to retroactively authorize use of that relicensed material under GPL version 4.  (Alternatively, you can ask the authors of that material to give permission right away.)
zh_CN: 不幸的是，CC-BY-SA 4.0 不允许再次授权到将来版本的 GPL。当你把使用 CC-BY-SA 4.0 的材料再次授权到 GPL，你该怎么做呢？你 <a href="/licenses/rms-why-gplv3.html#future-proofing">把你自己定义为许可证版本的代理</a>，并指明该材料是否授权给未来的 GPL 版本。如果将来有了 GPL v4 并且 Creative Commons 许可证决定允许从 CC-BY-SA 再次授权到 GPL v4，那么你作为代理就能够返回来用 GPL v4 对该材料再次授权。（另外，你也可以直接请该材料的作者立即授予你许可。）

note: type: Content of: <div><p>
en: The ordinary GNU General Public License and the GNU Affero General Public License are two different copyleft licenses, so they are naturally incompatible.  We have set up a special kind of explicit compatibility between them: you can include source code under the GNU GPL version 3 together with other source code under the GNU Affero GPL in a single combined program.  This is permitted because both of those licenses explicitly say so, and the effect is that the GNU AGPL applies to the combined program.  However, you can't simply relicense code from the GNU GPL (with or without &ldquo;or later&rdquo;) to the GNU Affero GPL, or vice versa; neither of these licenses gives permission for that.  Note also that the GNU Affero GPL version 3 is not a &ldquo;later version&rdquo; of the ordinary GNU GPL version 2, because the GNU Affero GPL and the GNU GPL are two different series of licenses.
zh_CN: GNU GPL 和 GNU Affero GPL 是两个不同的 copyleft 许可证，所以它们自然是不兼容的。我们为此设计了专门的兼容方案：你可以在同一个程序里包含使用 GNU GPL v3 的源代码和使用 GNU Affero GPL 的源代码。因为两个许可证都明确说明可以这么做，所以这个没问题，其效果就是合并的程序适用于 GNU AGPL 许可证。不过，你不能简单地把使用 GNU GPL（有或没有 &ldquo;或以后版本&rdquo;）的代码再次授权到 GNU Affero GPL，反过来也是一样；两个许可证都没有允许这样做。请也要注意，GNU Affero GPL v3 不是一个 GNU GPL v2 的 &ldquo;以后版本&rdquo;，因为 GNU Affero GPL 和 GNU GPL 是两个不同系列的许可证。

note: type: Content of: <div><p>
en: The GNU Lesser General Public License, version 3, is really the GNU General Public License version 3 plus some added extra permissions.  GPL version 3 (section 7) says you can always remove added permissions, and by doing so you get the same code under the ordinary GNU GPL version 3.  If a program permits use under GNU LGPL version 3 or later, you can relicense it to GPL version 3 or later; for each future GPL version N (N &gt; 3), we will make an LGPL version N which consists of the GPL version N plus added permissions.
zh_CN: GNU LGPL v3 真的就是 GNU GPL v3 加上额外的条款。GPL v3（第 7 节）表明你总是可以去掉那些额外的条款，这样做了之后同样的代码就遵循了常规的 GNU GPL v3。如果一个程序允许使用 GNU LGPL v3 或以后版本，那么你就可以把它再次授权到 GPL v3 或以后版本；对将来的每个 GPL 版本 N（N &gt; 3），我们都会做一个 LGPL 版本 N，它由 GPL 版本 N 加上额外的条款构成。

note: type: Content of: <div><p>
en: As for GNU Lesser GPL version 2.1, that explicitly permits relicensing to GNU GPL version 2 or later.
zh_CN: 对 GNU LGPL 版本 2.1 来说，它明确允许再次授权到 GNU GPL v2 或者以后版本。

note: type: Content of: <div><p>
en: Intermediate licenses are those which have substantive requirements on redistribution but are not copyleft licenses.  Examples include the Eclipse Public License and the Mozilla Public License.  Intermediate licenses tend to be incompatible with any copyleft licenses because their requirements don't permit the combined program to be under the copyleft license.  The Mozilla Public License permits relicensing to the GNU GPL except when the code explicitly denies this permission.
zh_CN: 中间型的许可证是指对重新发布有重要的要求但是又不是 copyleft 的那些许可证。Eclipse 公共许可证和 Mozilla 公共许可证都是中间型许可证。由于中间型许可证的要求不允许组合程序使用 copyleft 许可证，所以它们一般都不兼容 copyleft 许可证。Mozilla 公共许可证允许将代码再次授权到 GNU GPL，除非该代码明确拒绝这样做。

note: type: Content of: <div><p>
en: Finally, what about dual licensing?<a href="#f5">[5]</a> A dual license is a disjunction: it means that the same program carries a choice of two or more different licenses.  For instance, older versions of Perl carried a dual license: the disjunction of the Artistic License and the GNU General Public License.  This meant that each user could choose to use and redistribute Perl under one license or the other, or under both in disjunction like the Perl release itself.  A disjunction is compatible with a set of other licenses if any one of the license choices in the disjunction is compatible with that set.
zh_CN: 最后，双重许可证怎么办呢？<a href="#f5">[5]</a>双重许可证是一种或的关系：它的意思是同一个程序可以选择两个或多个许可证中的一个或几个。例如，老版本的 Perl 就带有双重许可证：或者是 Artistic 许可证，或者是 GNU 通用公共许可证。这意味着每个用户都可以选择并按照其中一个许可证或者就按照 Perl 原来的方式再次授权 Perl。如果双重许可证中的一个许可证和一组许可证兼容，那么该双重许可证就和该组许可证兼容。

note: type: Content of: <div><p>
en: When you choose a license for your code, please choose GNU GPL version 3 or later, or some license compatible with that.  This is the way to make your code combinable with nearly all the corpus of free software.  Choosing GPL or AGPL, version 3 or later, will also do the utmost to defend freedom for all users of all versions of your code.
zh_CN: 当你选择许可证时，请选择 GNU GPL v3 或者以后版本，或者是与之兼容的许可证。这是使你的代码能够和几乎所有自由软件集合的代码组合的正确方法。选择 GPL 或 AGPL，v3 或者以后版本，也会最大程度地保护所有使用你各个版本代码的用户的自由。

note: type: Content of: <div><h3>
en: Combining code
zh_CN: 合并代码

note: type: Content of: <div><p>
en: When a set of licenses are compatible, that means you can legally combine or merge a number of programs each licensed under one of those licenses.  How, then, is the combined program licensed?
zh_CN: 当一组许可证兼容时，这就意味着你可以合法地合并或融合一系列按照其中某个许可证发布的程序。那么，合并后的程序该怎样授权呢？

note: type: Content of: <div><p>
en: Each free software license says you must keep the license with the code that is covered by it.  So in a strict sense, the licensing of the combined program includes the licenses of all its parts.  However, sometimes you want a <em>summary</em> answer to the question of how the combined program is licensed.  Which licenses does someone using the combined program <em>need to pay attention to?</em>
zh_CN: 每个自由软件许可证都说你必须保持其代码原有的许可证。所以严格来讲，合并程序的许可证要包含其所有组成部分的许可证。不过，有时你想要一个 <em>总结性</em> 的回答来解决合并程序该如何授权的问题。究竟哪一个许可证是使用合并程序的人 <em>要关注的呢？</em>

note: type: Content of: <div><p>
en: To compute that, you start with a list of all the pertinent licenses.  Then you can delete from the list any license which is subsumed by another in the list.
zh_CN: 为了计算，你要从所有直接相关的许可证列表开始。然后你可以把列表中一些能够被另外一些许可证包含的许可证删除。

note: type: Content of: <div><p>
en: We say that a license A <em>subsumes</em> license B when compliance with license A implies compliance with license B.
zh_CN: 如果遵循许可证甲意味着也遵循许可证乙，那么我们就说许可证甲 <em>包含</em> 许可证乙。

note: type: Content of: <div><p>
en: For instance, the GNU GPL version N and the GNU Affero GPL version N both subsume the GNU Lesser GPL version N, and all three of those subsume the GNU Lesser GPL version 2.1.
zh_CN: 例如，GNU GPL 版本 N 和 GNU Affero GPL 版本 N 都包含了 GNU Lesser GPL 版本 N，而它们三个都包含了 GNU Lesser GPL 版本 2.1。

note: type: Content of: <div><p>
en: Any GNU license, version N, subsumes the Apache 2.0 license provided N is at least 3.
zh_CN: 任一版本 N 的 GNU 许可证，如果 N 不小于 3，那么它就包含了 Apache 2.0 许可证。

note: type: Content of: <div><p>
en: The GNU GPL, version N, subsumes all versions of the Mozilla Public License that are compatible with it.
zh_CN: GNU GPL 版本 N 包含了与之兼容的所有版本的 Mozilla 公共许可证。

note: type: Content of: <div><p>
en: The Apache 2.0 license subsumes the BSD, Expat, X11, ISC and CC-0 licenses.  BSD 3 clause subsumes BSD 2 clause.  The BSD licenses subsume the Expat, X11 and ISC licenses and CC0.
zh_CN: Apache 2.0 许可证包含了 BSD、Expat、X11、ISC 和 CC-0 许可证。BSD 3 条款包含了 BSD 2 条款。BSD 许可证包含了 Expat、X11 和 ISC 许可证以及 CC-0。

note: type: Content of: <div><p>
en: This is not meant to be a complete list, but if we are informed of other cases worth mentioning, we will add them.
zh_CN: 此处并非要提供一个完整列表，但是如果我们发现还有其他值得说明的例子，我们还会添加。

note: type: Content of: <div><p>
en: When some license is subsumed, you still need to include a copy of it with all distribution of the combined program.
zh_CN: 当某些许可证被包含时，你仍然需要在发布组合程序时包含该许可证的拷贝。

note: type: Content of: <div><h3>
en: Footnotes
zh_CN: 脚注

note: type: Content of: <div><ol><li><p>
en: It is not inconceivable that other legal issues might arise about a specific combination of programs, issues not related to the copyright licenses of the programs to be combined.  We discuss only the implications of the licenses themselves.
zh_CN: 可以想象还可能有关于合并程序的其他法律问题，这些问题可能和合并程序的许可证无关。我们只讨论和许可证本身有关的问题。

note: type: Content of: <div><ol><li><p>
en: The main license in actual use that isn't reasonably behaved is the license of TeX: if two programs are licensed just the way TeX is, there is no authorized way to distribute a merged version of them.
zh_CN: 实际当中用到的不那么顺理成章的许可证主要是 TeX 的许可证：如果两个程序都按照 TeX 的方式授权，那么你就没有办法发布两个程序的组合程序。

note: type: Content of: <div><ol><li><p>
en: The TeX license permits distribution of a modified version only in the form of the original version plus a differences file.  If A and B are separately released that way, then merged, distributing the merged program as A plus a change file violates the license of B.  Distributing this as B plus a change file violates the license of A.  Distributing this in any other way violates both licenses.
zh_CN: TeX 许可证允许发布的修改版只能是原来的版本加上一个差异文件。如果甲和乙两个程序分别按照 Tex 许可证发布，然后再合并，那么按照甲程序加上一个差异文件来发布合并程序就违反了乙程序的许可证。反过来，发布乙程序加上差异文件的话又违反了甲的许可证。按照其他方式发布的话就违反了甲乙两个程序的许可证。

note: type: Content of: <div><ol><li><p>
en: It is no coincidence that TeX was released in 1982: our community has learned, since then, to write reasonably behaved licenses.
zh_CN: 这个并不意外，TeX 早在 1982 年就发布了：社区从此逐渐学会了撰写顺理成章的许可证。

note: type: Content of: <div><ol><li><p>
en: When distributing in source code form, it is usually sufficient to leave the license notices in the source code as they stand; extra license notice requirements typically only come up for lax licenses when distributing binaries without the source code.
zh_CN: 当发布源代码时，在源代码里加入许可证声明通常就足够了；只有象使用松散型许可证的仅发布二进制而不带源代码的程序才需要额外的许可证声明。

note: type: Content of: <div><ol><li><p>
en: In addition, GPL version 2 still allows binaries to be made nonfree by hardware that rejects all but special signed binaries, and still does not allow distribution of binaries by torrent.  <a href="/licenses/rms-why-gplv3.html">We fixed those problems, and others, in version 3</a>, but we can't change version 2.
zh_CN: 另外，GPL v2 仍然允许非自由的二进制&mdash;&mdash;硬件只运行特别签名的二进制而拒绝其他二进制文件，而且仍然不允许使用 torrent 发布二进制。<a href="/licenses/rms-why-gplv3.html">我们在版本 3 中修复了这些问题，还修复了其他问题</a>，但是我们不能改变版本 2。

note: type: Content of: <div><ol><li><p>
en: Some use the term &ldquo;dual licensing&rdquo; to refer to selling exceptions, but that is a misnomer.  See <a href="/philosophy/selling-exceptions.html"> Selling Exceptions</a>.  Note that if the program on which the license is sold includes any code that is not in the free (libre) release, that's not selling exceptions, that's nonfree software.
zh_CN: 有人使用 &ldquo;双重许可证&rdquo; 来兜售许可证例外，但是词不达意。请参看 <a href="/philosophy/selling-exceptions.html">兜售例外</a>。请注意，如果某个许可证兜售的程序包含了任何非自由的代码，那么它就不是在兜售例外，它就是非自由软件。

note: type: Content of: <div><div><p>
en: Please send general FSF &amp; GNU inquiries to <a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>.  There are also <a href="/contact/">other ways to contact</a> the FSF.  Broken links and other corrections or suggestions can be sent to <a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.
zh_CN: 请将有关自由软件基金会(FSF) &amp; GNU的一般性问题发送到<a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>。也可以通过<a href="/contact/">其他联系方法</a>联系自由软件基金会(FSF)。有关失效链接或其他错误和建议，请发送邮件到<a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>。

note: TRANSLATORS: Ignore the original text in this paragraph, replace it with the translation of these two: We work hard and do our best to provide accurate, good quality translations.  However, we are not exempt from imperfection. Please send your comments and general suggestions in this regard to <a hr
en: Please see the <a href="/server/standards/README.translations.html">Translations README</a> for information on coordinating and contributing translations of this article.
zh_CN: 我们尽最大努力来提供精准和高质量的翻译，但难免会存在错误和不足。如果您在这方面有评论或一般性的建议，请发送至 <a href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>。</p><p>关于进行协调与提交翻译的更多信息参见 <a href="/server/standards/README.translations.html">《译者指南》</a>。

note: type: Content of: <div><p>
en: This page is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nd/4.0/">Creative Commons Attribution-NoDerivatives 4.0 International License</a>.
zh_CN: 本页面使用 <a rel="license" href="http://creativecommons.org/licenses/by-nd/4.0/">Creative Commons Attribution-NoDerivatives 4.0 International License</a> 授权。

note: TRANSLATORS: Use space (SPC) as msgstr if you don't want credits. type: Content of: <div><div>
en: *GNUN-SLOT: TRANSLATOR'S CREDITS*
zh_CN: <b>翻译团队</b>：<a rel="team" href="https://savannah.gnu.org/projects/www-zh-cn/">&lt;CTT&gt;</a>，2020，2021。

note: timestamp start type: Content of: <div><p>
en: Updated:
zh_CN: 最后更新：
