www-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

www/licenses po/license-compatibility.translist...


From: GNUN
Subject: www/licenses po/license-compatibility.translist...
Date: Fri, 24 Jan 2020 09:01:43 -0500 (EST)

CVSROOT:        /web/www
Module name:    www
Changes by:     GNUN <gnun>     20/01/24 09:01:43

Modified files:
        licenses/po    : license-compatibility.translist 
                         license-compatibility.zh-cn.po 
Added files:
        licenses       : license-compatibility.zh-cn.html 
        licenses/po    : license-compatibility.zh-cn-en.html 

Log message:
        Automatic update by GNUnited Nations.

CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/license-compatibility.zh-cn.html?cvsroot=www&rev=1.1
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/po/license-compatibility.translist?cvsroot=www&r1=1.4&r2=1.5
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/po/license-compatibility.zh-cn.po?cvsroot=www&r1=1.1&r2=1.2
http://web.cvs.savannah.gnu.org/viewcvs/www/licenses/po/license-compatibility.zh-cn-en.html?cvsroot=www&rev=1.1

Patches:
Index: po/license-compatibility.translist
===================================================================
RCS file: /web/www/www/licenses/po/license-compatibility.translist,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -b -r1.4 -r1.5
--- po/license-compatibility.translist  23 Oct 2016 09:58:00 -0000      1.4
+++ po/license-compatibility.translist  24 Jan 2020 14:01:43 -0000      1.5
@@ -6,6 +6,7 @@
 <span dir="ltr"><a lang="fr" hreflang="fr" 
href="/licenses/license-compatibility.fr.html">français</a>&nbsp;[fr]</span> 
&nbsp;
 <span dir="ltr"><a lang="it" hreflang="it" 
href="/licenses/license-compatibility.it.html">italiano</a>&nbsp;[it]</span> 
&nbsp;
 <span dir="ltr"><a lang="ru" hreflang="ru" 
href="/licenses/license-compatibility.ru.html">русский</a>&nbsp;[ru]</span>
 &nbsp;
+<span dir="ltr"><a lang="zh-cn" hreflang="zh-cn" 
href="/licenses/license-compatibility.zh-cn.html">简体中文</a>&nbsp;[zh-cn]</span>
 &nbsp;
 </p>
 </div>' -->
 <link rel="alternate" type="text/html" 
href="/licenses/license-compatibility.html" hreflang="x-default" />
@@ -13,4 +14,5 @@
 <link rel="alternate" type="text/html" lang="fr" hreflang="fr" 
href="/licenses/license-compatibility.fr.html" title="français" />
 <link rel="alternate" type="text/html" lang="it" hreflang="it" 
href="/licenses/license-compatibility.it.html" title="italiano" />
 <link rel="alternate" type="text/html" lang="ru" hreflang="ru" 
href="/licenses/license-compatibility.ru.html" title="русский" />
+<link rel="alternate" type="text/html" lang="zh-cn" hreflang="zh-cn" 
href="/licenses/license-compatibility.zh-cn.html" title="简体中文" />
 <!-- end translist file -->

Index: po/license-compatibility.zh-cn.po
===================================================================
RCS file: /web/www/www/licenses/po/license-compatibility.zh-cn.po,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -b -r1.1 -r1.2
--- po/license-compatibility.zh-cn.po   24 Jan 2020 13:39:41 -0000      1.1
+++ po/license-compatibility.zh-cn.po   24 Jan 2020 14:01:43 -0000      1.2
@@ -41,8 +41,8 @@
 #. type: Content of: <p>
 msgid ""
 "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\">(**)</a>"
+"reasonably behaved license, as nearly all free licenses are.<a href=\"#f2\">"
+"(**)</a>"
 msgstr ""
 "如果两个软件使用同æ 
·çš„许可证,应该没有问题,假定该许可证象几
乎所有的自由软件"
 "许可证一样顺理成章。<a href=\"#f2\">(**)</a>"
@@ -104,8 +104,8 @@
 msgstr ""
 "在把使用松散型许可证的代ç 
åˆåœ¨ä¸€èµ·æ—¶ï¼Œç»„合程序的每个部分都带有自己的许可证。"
 "当这些代码交织在一起无
法分辨时,组合程序应该带上所有代ç 
çš„许可证。由于这些许"
-"可证都是松散型的,所以å…
¨éƒ½å¸¦ä¸Šé™¤äº†å¤ªé•¿ä¹‹å¤–也没有别的问题。<a href="
-"\"#f3\">(***)</a>"
+"可证都是松散型的,所以å…
¨éƒ½å¸¦ä¸Šé™¤äº†å¤ªé•¿ä¹‹å¤–也没有别的问题。<a href=\"#f3\">"
+"(***)</a>"
 
 #. type: Content of: <p>
 msgid ""

Index: license-compatibility.zh-cn.html
===================================================================
RCS file: license-compatibility.zh-cn.html
diff -N license-compatibility.zh-cn.html
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ license-compatibility.zh-cn.html    24 Jan 2020 14:01:42 -0000      1.1
@@ -0,0 +1,243 @@
+<!--#set var="ENGLISH_PAGE" value="/licenses/license-compatibility.en.html" -->
+
+<!--#include virtual="/server/header.zh-cn.html" -->
+<!-- Parent-Version: 1.86 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>许可证兼容性和再次授权 - GNU 工程 - 
自由软件基金会</title>
+
+<!--#include virtual="/licenses/po/license-compatibility.translist" -->
+<!--#include virtual="/server/banner.zh-cn.html" -->
+<h2>许可证兼容性和再次授权</h2>
+
+<p>Richard Stallman 著</p>
+
+<p>如果你要把两个自由程序合而为一,或者把å…
¶ä¸­ä¹‹ä¸€çš„代码并å…
¥å¦ä¸€ä¸ªï¼Œé‚£ä¹ˆå°±ä¼šæœ‰ä¸€ä¸ªå®ƒä»¬çš„许可证是否允许/禁止这æ 
·åšçš„问题。<a
+href="#f1">(*)</a></p>
+
+<p>如果两个软件使用同æ 
·çš„许可证,应该没有问题,假定该许可证象几
乎所有的自由软件许可证一样顺理成章。<a href="#f2">(**)</a></p>
+
+<p>那么如果许可证不一æ 
·ä¼šå¦‚何呢?一般来说,如果有方法可以合并代ç 
è€Œåˆèƒ½åŒæ—¶éµå¾ªå„个代ç 
çš„许可证,那么我们就说这些许可证是
+<em>兼容的</em>。å…
¶ç»“果经常是一个由各个部分使用不同许可证的组合程序&mdash;&mdash;但也不尽然。å
…·æœ‰è¿™ä¸ªå…¼å®¹æ€§ï¼Œæˆ–者没有此å…
¼å®¹æ€§ï¼Œæ˜¯è®¸å¯è¯ç»„合在一起的特点,这个特点并不依赖于你
使用它们的顺序。该许可证组合还决定着该合并程序需要哪个许可证。</p>
+
+<p>我们把许可证分为三类:松散型(也即 &ldquo;纵容型&rdquo; 
或者 &ldquo;顺从型&rdquo;),中间型和 copyleft
+型。松散型许可证不介意专有软件使用其代码。copyleft
+许可证禁止专有软件使用其代码,它明确要求所有使用å…
¶ä»£ç çš„程序都要使用同æ 
·çš„许可证。中间型许可证限制但并不禁止专有软件使用å…
¶ä»£ç ã€‚</p>
+
+<p>一般地,松散型许可证(修改版 
BSD、X11、Expat、Apache、Python
+等)是互相兼容的。这是因为它们对添加到程序里的代ç 
å¹¶æ— è¦æ±‚。它们甚至允许把整个程序(或许带有修改)添加
到专有软件之中;因此,我们称之为
+&ldquo;顺从型许可证&rdquo;,理由是它们在用户的自由被否定时没有说
 &ldquo;不&rdquo;。</p>
+
+<p>在把使用松散型许可证的代ç 
åˆåœ¨ä¸€èµ·æ—¶ï¼Œç»„合程序的每个部分都带有自己的许可证。当这些代ç
 äº¤ç»‡åœ¨ä¸€èµ·æ— æ³•åˆ†è¾¨æ—¶ï¼Œç»„合程序应该带上所有代ç 
çš„许可证。由于这些许可证都是松散型的,所以å…
¨éƒ½å¸¦ä¸Šé™¤äº†å¤ªé•¿ä¹‹å¤–也没有别的问题。<a
+href="#f3">(***)</a></p>
+
+<p>同理可知,松散型许可证通常也和 copyleft 许可证å…
¼å®¹ã€‚在组合程序中,使用松散型许可证的代ç 
ä»ç„¶å¸¦ç€æ¾æ•£åž‹è®¸å¯è¯ï¼Œè€Œç»„合程序整体使用
+copyleft 许可证。有一个松散型许可证,Apache 2.0,带有和 GPL 
v2 不å…
¼å®¹çš„专利条款;由于我认为这些专利条款还不错,所以我让
+GPL v3 与之兼容了。</p>
+
+<p>因其 &ldquo;令人反感的广告条款&rdquo;,原始 BSD 
许可证是一个重要的例外。该广告条款要求包含 <em>任何</em> 
使用原始 BSD
+许可证代码的 <em>任何</em> 产品的 <em>所有</em> 
广告都要带有一个特定的声明。这种做法过去和所有已知的 
copyleft
+许可证都不å…
¼å®¹ï¼ŒçŽ°åœ¨ä¹Ÿæ˜¯ã€‚当程序里积攒了越来越多相似而又不同的广告声明时,每个发行版都忍受着一种如芒在背的痛苦。有段时间,一个
 BSD 发行版需要包含
+70 多个不同的声明。</p>
+
+<p>我说服 Hal Varian,UC Berkeley 的一位校长,促使他们发布 
&ldquo;修改版 BSD 许可证&rdquo;(没有广告条款)并将
+BSD 代码按照此许可证发布。这样就基本上æ 
¹é™¤äº†ä¸Šé¢æ‰€è¯´çš„问题。现在,原始 BSD 
许可证(所幸)已经很少被使用了,但是我们还是必须小心 
<a
+href="/licenses/bsd.html">避免讨论 &ldquo;该&rdquo; BSD 
许可证</a>。</p>
+
+<p>一般来说,两个不同的 copyleft 许可证是无可避免的不å…
¼å®¹ï¼Œé™¤éžä¸¤è€…之间有明确的兼容条款。这不是因
为细节有误;这是 copyleft
+理念与生俱来的特点。copyleft 的理念是
+&ldquo;修改和扩展的版本必须延用同æ 
·çš„许可证。&rdquo;如果使用许可证甲的扩展程序必
须延用许可证甲,使用许可证乙的程序必
须延用许可证乙,那么它们之间就是不可调和;如果合并程序,许可证å¿
…须是甲,<em>也</em>必须是乙。这就是为什么
+GPL v2 和 GPL v3 不兼容;这是无法避免的。同样地,CC-BY-SA 4.0 
的要求就天生和 CC-BY-SA 3.0
+不兼容,而且作者也无法避免这一点。</p>
+
+<p>有两个方法来摆脱新版 copyleft 许可证带来的先天不å…
¼å®¹æ€§ã€‚</p>
+
+<p>FSF 使用请求人们按照 &ldquo;遵循 GNU GPL 版本 N 
或任何以后版本&rdquo;
+来发布程序这一方法来解决此兼容性问题。这种授权å…
¼å®¹ç‰ˆæœ¬ N,也兼容版本 N+1(因为它确认版本 N+1 
是可选项)。当你将遵循 &ldquo;GPL 3
+或以后版&rdquo; 的代码和遵循 &ldquo;GPL 2 或以后版&rdquo; 
的代码合并时,组合代码的许可证是它们的交集,就是
+&ldquo;GPL 3 或以后版&rdquo;。</p>
+
+<p>我们希望我们再也不会有 GNU GPL v4,但是人无
完人、世事难料,我们无法预见所有的情况。通过按照遵循 
GNU GPL 3
+或以后版本来发布程序,你就允许你的代码许可证升级到 
GNU GPL v4,一旦我们发布了 v4。</p>
+
+<p>另一个方法是让每一个版本都明确å…
è®¸å‡çº§åˆ°ä»¥åŽçš„版本。这就是 Creative Commons 
采用的办法:例如,CC-BY-SA 4.0
+版(当前版)明确允许任何用户将许可证升级到以后版本的 
CC-BY-SA(一旦有了)。Mozilla 基金会也是使用该方法。</p>
+
+<p>只有 GNU 许可证给了作者选择是否å…
è®¸å‡çº§åˆ°æœªæ¥è®¸å¯è¯ç‰ˆæœ¬çš„权利。当年我编写第一个 GNU GPL 
版本的时候,那是 1989
+年,我曾经想过包含一个许可证升级的选项,就像现在的 CC 
许可证一样,但是我觉得把选择权交给作者更正当。这æ 
·ï¼Œä½œè€…就可以把其程序按照 &ldquo;只用
+GPL 1&rdquo; 或者 &ldquo;用 GPL 1 或以后版&rdquo; 来发布。</p>
+
+<p>从那时起,我就在思量当时的决定是否明智。像 Linux 这æ 
·çš„程序,只允许一个版本的 GNU GPL 
并拒绝升级许可证,这就导致实际上的不兼容。<a
+href="#f4">(****)</a>或许我们应该在 GPL v4 的时侯包
含一个升级条款,如果我们需要版本 4 的话。</p>
+
+<p>有些 copyleft 许可证有一个明确的再次授权条款,该条款å…
è®¸å°†ä»£ç æŒ‰ç…§ä¸åŒçš„ copyleft 许可证授权,这样就允许了 
copyleft
+许可证之间的交叉授权。例如,CeCILL 许可证明确许可将代ç 
æŒ‰ç…§ GNU GPL v2 或以后版再次授权。如果程序 P 使用 CeCILL
+许可证授权,而你想把它和按照 GPL v3 或以后版授权的程序 
Q 合并在一起,那么 CeCILL 许可证允许你
这么做,合并或组合的代码使用 GPL
+v3 或以后版授权。</p>
+
+<p>明确的再次授权许可和å…
¼å®¹æ€§å¹¶ä¸æ˜¯ä¸€å›žäº‹ï¼ˆè™½ç„¶å†æ¬¡æŽˆæƒåŽçš„代码可以和其他代ç 
å…¼å®¹ï¼‰ï¼ŒäºŒè€…也不对称。例如,CeCILL 许可证明确允许将代ç 
å†æ¬¡æŽˆæƒç»™
+GNU GPL,而 GNU GPL 并不允许将代码再次授权给 CeCILL。因
此,你不能合并 P 和 Q 两个程序并把它们按照 CeCILL
+许可证发布;那样就违反了 Q 程序使用的 GPL 
许可证的要求。它们的合并程序只允许使用适当的 GPL 
版本来发布。</p>
+
+<p>类似,CC-BY-SA 4.0 明确允许修改版再次授权可以使用 GPL v3 
许可证,但是 GPL v3 并不允许再次授权到
+CC-BY-SA。这个问题应该不会影响软件代码;Creative Commons 
许可证的说明指出它不用于代码,并且也指出如果是代ç 
ï¼Œåº”该使用 GNU
+GPL 许可证。但是还有一些å…
¶ä»–种类的作品,比如硬件设计或游戏艺术等,这时就会碰到把使用
 CC-BY-SA 的材料和使用 GNU GPL
+的材料合并的问题。这种情况可以使用 CC-BY-SA 
许可证中明确说明的再次授权条款。</p>
+
+<p>不幸的是,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 
对该材料再次授权。(另外,你也可以直接请该材料的作者
立即授予你许可。)</p>
+
+<p>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 
是两个不同系列的许可证。</p>
+
+<p>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 加上额外的条款构成。</p>
+
+<p>对 GNU LGPL 版本 2.1 来说,它明确允许再次授权到 GNU GPL v2 
或者以后版本。</p>
+
+<p>中间型的许可证是指对重新发布有重要的要求但是又不是 
copyleft 的那些许可证。Eclipse 公共许可证和 Mozilla
+公å…
±è®¸å¯è¯éƒ½æ˜¯ä¸­é—´åž‹è®¸å¯è¯ã€‚由于中间型许可证的要求不å…
è®¸ç»„合程序使用 copyleft 许可证,所以它们一般都不兼容 
copyleft
+许可证。Mozilla 公共许可证允许将代码再次授权到 GNU 
GPL,除非该代码明确拒绝这样做。</p>
+
+<p>最后,双重许可证怎么办呢?<a
+href="#f5">(*****)</a>双重许可证是一种分割:它的意思是同一个程序可以选择两个或多个许可证中的一个。例如,老版本的
 Perl
+就带有双重许可证:或者是 Artistic 许可证,或者是 GNU 
通用公共许可证。这意味着每个用户都可以选择并按照å…
¶ä¸­ä¸€ä¸ªè®¸å¯è¯æˆ–者就按照 Perl
+原来的分割方式再次授权 
Perl。如果双重许可证中的一个许可证和一组许可证å…
¼å®¹ï¼Œé‚£ä¹ˆè¯¥åŒé‡è®¸å¯è¯å°±å’Œè¯¥ç»„许可证兼容。</p>
+
+<p>当你选择许可证时,请选择 GNU GPL v3 或者以后版本,或者
是与之兼容的许可证。这是使你的代码能够和几
乎所有自由软件集合的代码组合的正确方法。选择
+GPL 或 AGPL,v3 或者
以后版本,也会最大程度地保护所有使用你各个版本代ç 
çš„用户的自由。</p>
+
+<h3 id="combining">合并代码</h3>
+
+<p>当一组许可证兼容时,这就意味着你
可以合法地合并或融合一系列按照å…
¶ä¸­æŸä¸ªè®¸å¯è¯å‘布的程序。那么,合并后的程序该怎æ 
·æŽˆæƒå‘¢ï¼Ÿ</p>
+
+<p>每个自由软件许可证都说你必须保持其代ç 
åŽŸæœ‰çš„许可证。所以严格来讲,合并程序的许可证要包含å…
¶æ‰€æœ‰ç»„成部分的许可证。不过,有时你想要一个
+<em>总结性</em> 
的回答来解决合并程序该如何授权的问题。究竟哪一个许可证是使用合并程序的人
 <em>要关注的呢?</em></p>
+
+<p>为了计算,你要从所有直接相å…
³çš„许可证列表开始。然后你
可以把列表中一些能够被另外一些许可证包含的许可证删
除。</p>
+
+<p>如果遵循许可证甲意味着也遵循许可证乙,那么我们就说许可证甲
 <em>包含</em> 许可证乙。</p>
+
+<p>例如,GNU GPL 版本 N 和 GNU Affero GPL 版本 N 都包含了 GNU 
Lesser GPL 版本 N,而它们三个都包含了 GNU
+Lesser GPL 版本 2.1。</p>
+
+<p>任一版本 N 的 GNU 许可证,如果 N 不小于 3,那么它就包
含了 Apache 2.0 许可证。</p>
+
+<p>GNU GPL 版本 N 包含了与之兼容的所有版本的 Mozilla 公å…
±è®¸å¯è¯ã€‚</p>
+
+<p>Apache 2.0 许可证包含了 BSD、Expat、X11、ISC 和 CC-0 
许可证。BSD 3 条款包含了 BSD 2 条款。BSD
+许可证包含了 Expat、X11 和 ISC 许可证以及 CC-0。</p>
+
+<p>此处并非要提供一个完整列表,但是如果我们发现还有å…
¶ä»–值得说明的例子,我们还会添加。</p>
+
+<p>当某些许可证被包含时,你仍然需要在发布组合程序时包
含该许可证的拷贝。</p>
+
+<h3 id="footnotes">脚注</h3>
+
+<p id="f1"><b>*</b> 可以想象还可能有关于合并程序的å…
¶ä»–法律问题,这些问题可能和合并程序的许可证无å…
³ã€‚我们只讨论和许可证本身有关的问题。</p>
+
+<p id="f2"><b>**</b> 实际当中用到的不那么顺理成章
的许可证主要是 TeX 的许可证:如果两个程序都按照 TeX
+的方式授权,那么你
就没有办法发布两个程序的组合程序。</p>
+
+<p>TeX 许可证允许发布的修改版只能是原来的版本加
上一个差异文件。如果甲和乙两个程序分别按照 Tex
+许可证发布,然后再合并,那么按照甲程序加
上一个差异文件来发布合并程序就违反了乙程序的许可证。反过来,发布乙程序åŠ
 ä¸Šå·®å¼‚文件的话又违反了甲的许可证。按照å…
¶ä»–方式发布的话就违反了甲乙两个程序的许可证。</p>
+
+<p>这个并不意外,TeX 早在 1982 
年就发布了:社区从此逐渐学会了撰写顺理成章
的许可证。</p>
+
+<p id="f3"><b>***</b>
+当发布源代码时,在源代码里加å…
¥è®¸å¯è¯å£°æ˜Žé€šå¸¸å°±è¶³å¤Ÿäº†ï¼›åªæœ‰è±¡ä½¿ç”¨æ¾æ•£åž‹è®¸å¯è¯çš„ä»…
发布二进制而不带源代ç 
çš„程序才需要额外的许可证声明。</p>
+
+<p id="f4"><b>****</b> 另外,GPL v2
+仍然å…
è®¸éžè‡ªç”±çš„二进制&mdash;&mdash;硬件只运行特别签名的二进制而拒绝å
…¶ä»–二进制文件,而且仍然不允许使用 torrent 发布二进制。<a
+href="/licenses/rms-why-gplv3.html">我们在版本 3 
中修复了这些问题,还修复了å…
¶ä»–问题</a>,但是我们不能改变版本
+2。</p>
+
+<p id="f5"><b>*****</b> 有人使用 &ldquo;双重许可证&rdquo; 来å…
œå”®è®¸å¯è¯ä¾‹å¤–,但是词不达意。请参看 <a
+href="/philosophy/selling-exceptions.html">å…
œå”®ä¾‹å¤–</a>。请注意,如果某个许可证兜售的程序包
含了任何非自由的代码,那么它就不是在å…
œå”®ä¾‹å¤–,它就是非自由软件。</p>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+ </div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.zh-cn.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>请将有关自由软件基金会(FSF) &amp; 
GNU的一般性问题发送到<a
+href="mailto:address@hidden";>&lt;address@hidden&gt;</a>。也可以通过<a
+href="/contact/">其他联系方法</a>联系自由软件基金会(FSF)。有å…
³å¤±æ•ˆé“¾æŽ¥æˆ–其他错误和建议,请发送邮件到<a
+href="mailto:address@hidden";>&lt;address@hidden&gt;</a>。</p>
+
+<p>
+<!-- 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 href="mailto:address@hidden";>
+
+        &lt;address@hidden&gt;</a>.</p>
+
+        <p>For information on coordinating and submitting translations of
+        our web pages, see <a
+        href="/server/standards/README.translations.html">Translations
+        README</a>. -->
+我们尽最大努力来提供精准和高质量的翻译,但难å…
ä¼šå­˜åœ¨é”™è¯¯å’Œä¸è¶³ã€‚如果您在这方面有评论或一般性的建议,请发送至
 <a
+href="mailto:address@hidden";>&lt;address@hidden&gt;</a>。</p><p>å…
³äºŽè¿›è¡Œåè°ƒä¸Žæäº¤ç¿»è¯‘的更多信息参见
+<a href="/server/standards/README.translators.html">《译者
指南》</a>。</p>
+</div>
+
+<!-- Regarding copyright, in general, standalone pages (as opposed to
+     files generated as part of manuals) on the GNU web server should
+     be under CC BY-ND 4.0.  Please do NOT change or remove this
+     without talking with the webmasters or licensing team first.
+     Please make sure the copyright date is consistent with the
+     document.  For web pages, it is ok to list just the latest year the
+     document was modified, or published.
+     
+     If you wish to list earlier years, that is ok too.
+     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
+     years, as long as each year in the range is in fact a copyrightable
+     year, i.e., a year in which the document was published (including
+     being publicly visible on the web or in a revision control system).
+     
+     There is more detail about copyright years in the GNU Maintainers
+     Information document, www.gnu.org/prep/maintain. -->
+<p>Copyright &copy; 2016, 2018 Free Software Foundation, Inc.</p>
+
+<p>本页面使用 <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/";>Creative Commons
+Attribution-NoDerivatives 4.0 International License</a> 授权。</p>
+
+<!--#include virtual="/server/bottom-notes.zh-cn.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+<b>翻译团队</b>:<a rel="team"
+href="https://savannah.gnu.org/projects/www-zh-cn/";>&lt;CTT&gt;</a>,2020。</div>
+
+<p class="unprintable"><!-- timestamp start -->
+最后更新:
+
+$Date: 2020/01/24 14:01:42 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>

Index: po/license-compatibility.zh-cn-en.html
===================================================================
RCS file: po/license-compatibility.zh-cn-en.html
diff -N po/license-compatibility.zh-cn-en.html
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ po/license-compatibility.zh-cn-en.html      24 Jan 2020 14:01:43 -0000      
1.1
@@ -0,0 +1,363 @@
+<!--#include virtual="/server/header.html" -->
+<!-- Parent-Version: 1.86 -->
+<title>License Compatibility and Relicensing
+- GNU Project - Free Software Foundation</title>
+ <!--#include virtual="/licenses/po/license-compatibility.translist" -->
+<!--#include virtual="/server/banner.html" -->
+<h2>License Compatibility and Relicensing</h2>
+
+<p>by Richard Stallman</p>
+
+<p>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">(*)</a></p>
+
+<p>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">(**)</a></p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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">(***)</a></p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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>.</p>
+
+<p>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 says extended
+programs must be under license A, and license B says extended programs
+must be under license B, they have an irreconcilable disagreement; the
+license of the combined program would have to be A, <em>and</em> it would
+have to be B.  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.</p>
+
+<p>There are two approaches for smoothing out the incompatibility
+inherent in new versions of copyleft licenses.</p>
+
+<p>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;.</p>
+
+<p>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.</p>
+
+<p>The other approach is to make each version of the license explicitly
+allow upgrading to later versions.  This is what Creative Commons
+does: for instance, CC-BY-SA version 4.0 (the current version)
+explicitly permits any user to upgrade to later versions of CC-BY-SA
+once those exist.  The Mozilla Foundation also uses this approach.</p>
+
+<p>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;</p>
+
+<p>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">(****)</a>  Perhaps we should include an
+upgrade clause in GPL version 4, if we ever need a version 4.</p>
+
+<p>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.</p>
+
+<p>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).</p>
+
+<p>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.</p>
+
+<p>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.)</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>As for GNU Lesser GPL version 2.1, that explicitly permits relicensing
+to GNU GPL version 2 or later.</p>
+
+<p>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.</p>
+
+<p>Finally, what about dual licensing?<a href="#f5">(*****)</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.</p>
+
+<p>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.</p>
+
+<h3 id="combining">Combining code</h3>
+
+<p>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?</p>
+
+<p>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></p>
+
+<p>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.</p>
+
+<p>We say that a license A <em>subsumes</em> license B when compliance with
+license A implies compliance with license B.</p>
+
+<p>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.</p>
+
+<p>Any GNU license, version N, subsumes the Apache 2.0 license provided
+N is at least 3.</p>
+
+<p>The GNU GPL, version N, subsumes all versions of the Mozilla Public
+License that are compatible with it.</p>
+
+<p>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 CC-0.</p>
+
+<p>This is not meant to be a complete list, but if we are informed of
+other cases worth mentioning, we will add them.</p>
+
+<p>When some license is subsumed, you still need to include a copy
+of it with all distribution of the combined program.</p>
+
+<h3 id="footnotes">Footnotes</h3>
+
+<p id="f1"><b>*</b> 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.</p>
+
+<p id="f2"><b>**</b> 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.</p>
+
+<p>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.</p>
+
+<p>It is no coincidence that TeX was released in 1982: our community has
+learned, since then, to write reasonably behaved licenses.</p>
+
+<p id="f3"><b>***</b> 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.</p>
+
+<p id="f4"><b>****</b> 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.</p>
+
+<p id="f5"><b>*****</b> 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.</p>
+
+</div><!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Please send general FSF &amp; GNU inquiries to
+<a href="mailto:address@hidden";>&lt;address@hidden&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:address@hidden";>&lt;address@hidden&gt;</a>.</p>
+
+<p><!-- 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 href="mailto:address@hidden";>
+        &lt;address@hidden&gt;</a>.</p>
+
+        <p>For information on coordinating and submitting translations of
+        our web pages, see <a
+        href="/server/standards/README.translations.html">Translations
+        README</a>. -->
+Please see the <a
+href="/server/standards/README.translations.html">Translations
+README</a> for information on coordinating and submitting translations
+of this article.</p>
+</div>
+
+<!-- Regarding copyright, in general, standalone pages (as opposed to
+     files generated as part of manuals) on the GNU web server should
+     be under CC BY-ND 4.0.  Please do NOT change or remove this
+     without talking with the webmasters or licensing team first.
+     Please make sure the copyright date is consistent with the
+     document.  For web pages, it is ok to list just the latest year the
+     document was modified, or published.
+     
+     If you wish to list earlier years, that is ok too.
+     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
+     years, as long as each year in the range is in fact a copyrightable
+     year, i.e., a year in which the document was published (including
+     being publicly visible on the web or in a revision control system).
+     
+     There is more detail about copyright years in the GNU Maintainers
+     Information document, www.gnu.org/prep/maintain. -->
+
+<p>Copyright &copy; 2016, 2018 Free Software Foundation, Inc.</p>
+
+<p>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>.</p>
+
+<!--#include virtual="/server/bottom-notes.html" -->
+
+<p class="unprintable">Updated:
+<!-- timestamp start -->
+$Date: 2020/01/24 14:01:43 $
+<!-- timestamp end -->
+</p>
+</div>
+</div><!-- for class="inner", starts in the banner include -->
+</body>
+</html>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]