授權條款相容性與重新授權

作者：Richard Stallman

如果您想將兩個自由程式合併為一個，或將程式碼從一個合併到另一個，這會引出一個問題：它們的授權條款是否允許合併它們，還是禁止合併它們。[1]

如果授權條款相同，且是合理運作的授權條款（幾乎所有自由授權條款都是如此[2]），那麼合併程式就沒有問題。

那麼，當授權條款不同時呢？一般來說，如果存在一種在遵守所有授權條款的情況下合併這些不同授權條款下程式碼的方法，我們就說這幾個授權條款是相容的。結果通常是一個程式包含在各種不同相容授權條款下的部分，但並非總是如此。這種可組合性或缺乏可組合性是給定授權條款集的特性，並且不取決於您提及它們的順序。授權條款集也控制著組合程式所需的授權條款。

我們將授權條款分為三類：寬鬆型（也稱為「許可型」或「推卸責任型」）、中等型和著作權保護型。寬鬆型授權條款不會妨礙將程式碼放入專有軟體中。著作權保護型授權條款禁止這樣做，它要求所有重複使用都必須在相同授權條款下的程式中進行。中等型授權條款對添加專有程式碼施加了一些條件，但並未嘗試禁止它。

一般來說，寬鬆許可型授權條款（修改後的 BSD、X11、Expat、Apache、Python 等）彼此相容。這是因為它們對添加到程式中的其他程式碼沒有任何要求。它們甚至允許將整個程式（可能經過修改）放入專有軟體產品中；因此，我們稱它們為「推卸責任型授權條款」，因為當有使用者試圖剝奪其他人的自由時，它們無法說「不」。

在寬鬆授權條款下的程式組合中，每個部分都帶有它自己的授權條款。當程式碼合併到各部分無法再區分時，合併後的程式碼應帶有所有合併部分的授權條款。由於所有授權條款都是寬鬆的，因此除了授權條款列表變長之外，這不會造成任何實際問題。[3]

同樣地，寬鬆授權條款通常與任何著作權保護型授權條款相容。在組合程式中，以寬鬆授權條款進入的部分仍然帶有它們的授權條款，而整個組合程式則帶有著作權保護型授權條款。一個寬鬆授權條款，Apache 2.0，具有與 GPL 第 2 版不相容的專利條款；由於我認為這些專利條款很好，所以我使 GPL 第 3 版與它們相容。

一個重要的例外是原始 BSD 授權條款，因為它有「令人厭惡的廣告條款」。此條件要求在任何包含任何根據原始 BSD 授權條款發布的程式碼的產品的所有廣告中都必須包含特定聲明。這過去是，現在也是，與所有實際的著作權保護型授權條款不相容的。對於每個發行版來說，這也是一件令人頭痛的事，因為程式累積了類似但不同的廣告要求。曾經有一次，一個 BSD 發行版需要超過 70 個不同的聲明。

我主要透過說服一位院長 Hal Varian 安排加州大學柏克萊分校發布「修改後的 BSD 授權條款」（沒有廣告條款）並根據該授權條款重新發布柏克萊系統發行版的程式碼，從而消除了這個問題。如今，原始 BSD 授權條款（幸運地）很少使用，但我們仍然必須注意不要談論「該」BSD 授權條款。

一般來說，除非兩個不同的著作權保護型授權條款具有明確的相容性條款，否則它們不可避免地是不相容的。這不是由於細節上的錯誤；這是著作權保護概念固有的。著作權保護的概念是「修改和擴展的版本必須在相同的授權條款下」。如果授權條款 A（在程式 P 上）規定擴展程式必須在授權條款 A 下，而授權條款 B（在程式 Q 上）規定擴展程式必須在授權條款 B 下，它們就會產生不可調和的分歧；包含來自 P 的程式碼加上來自 Q 的程式碼的組合程式的授權條款必須是 A，而且它必須是 B。

這就是為什麼 GPL 第 2 版與 GPL 第 3 版不相容的原因；這是無法避免的。同樣地，CC-BY-SA 4.0 的條件本質上會與 CC-BY-SA 3.0 的條件不相容，作者也無法避免這種情況。

有兩種方法可以避免不同版本的著作權保護型授權條款造成的不相容問題。

FSF 使用的方法是要求人們以「GNU GPL 第 N 版或任何更高版本」發布程式。這種授權條款與第 N 版相容，也與 N+1 版相容（因為它提供了 N+1 版作為選項）。當您將「GPL 第 3 版或更高版本」下的程式碼與「GPL 第 2 版或更高版本」下的程式碼組合時，組合的授權條款是它們的交集，即「GPL 第 3 版或更高版本」。

我們希望我們永遠不需要製作 GNU GPL 第 4 版，但沒有什麼是完美的，我們不能假設我們已經預料到所有問題。透過以 GNU GPL 第 3 版或更高版本發布您的程式碼，您允許您的程式碼升級到 GNU GPL 第 4 版（如果我們需要的話）。

另一種方法是使每個版本的授權條款明確允許升級到更高版本。Mozilla 基金會使用這種方法，PHP 也是如此。創用 CC 對於 CC-BY-SA 使用了這種方法：第 4.0 版（目前版本）明確允許任何使用者將修改作品升級到更高版本的 CC-BY-SA。

只有 GNU 授權條款讓作者可以選擇是否允許升級到未來的授權條款版本。當我在 1989 年編寫 GNU GPL 的第一個版本時，我考慮過包含現在在 CC 授權條款中找到的授權條款升級選項，但我認為將該選擇權交給每位作者更正確。因此，作者可以選擇以「僅 GPL 第 1 版」或「GPL 第 1 版或更高版本」發布程式。

從那時起，我開始質疑該決定的智慧。諸如 Linux 之類的程式僅允許一個 GNU GPL 版本並拒絕授權條款升級，這會導致實際的不相容性。[4] 如果我們製作 GPL 第 4 版，也許我們應該包含一個升級條款，該條款自動允許重新授權到更高編號的版本，例如第 5 版及更高版本。

一些著作權保護型授權條款允許與其他著作權保護型授權條款交叉組合，並具有明確的重新授權條款，允許將程式碼置於不同的著作權保護型授權條款下。例如，CeCILL 明確允許將程式碼重新授權為 GNU GPL 第 2 版和更高版本。如果程式 P 在 CeCILL 下，並且您想將其與 GPL 第 3 版或更高版本下的程式 Q 組合，CeCILL 規定您可以這樣做，並將組合或合併的程式碼置於 GPL 第 3 版或更高版本下。

明確的重新授權許可與相容性不同（儘管重新授權程式碼可以使其與其他程式碼相容），並且它不是對稱的。例如，CeCILL 明確允許將程式碼重新授權為 GNU GPL，但 GNU GPL 不允許重新授權為 CeCILL。因此，您不能將程式 P 和 Q 組合起來，並在 CeCILL 下發布組合；那樣會在使用程式 Q 時違反 GPL。發布該組合程式的唯一允許方式是在適當的 GPL 版本下。

同樣地，CC BY-SA 4.0 明確允許將修改後的版本重新授權為 GNU GPL 第 3 版，但 GPL 第 3 版不允許重新授權為 CC BY-SA。這個問題永遠不應該出現在軟體程式碼中；創用 CC 聲稱其授權條款不適用於程式碼，並聲稱用於程式碼的授權條款是 GNU GPL。但是還有其他類型作品，例如硬體設計或遊戲美術，您可能有機會將根據 CC-BY-SA 發布的素材與根據 GNU GPL 發布的素材合併。這可以透過 CC BY-SA 的明確重新授權許可來完成。

不幸的是，CC BY-SA 4.0 不允許重新授權到未來的 GPL 版本。當您將 CC BY-SA 4.0 下的素材重新授權到 GPL 時，您應該將自己指定為授權條款版本代理人，以表明是否已授權將未來的 GPL 版本用於該素材。如果有一天出現 GPL 第 4 版，並且創用 CC 決定允許從 CC BY-SA 重新授權到 GPL 第 4 版，那麼您作為代理人將能夠追溯授權在 GPL 第 4 版下使用該重新授權的素材。（或者，您可以要求該素材的作者立即給予許可。）

普通的 GNU 通用公共授權條款和 GNU Affero 通用公共授權條款是兩個不同的著作權保護型授權條款，因此它們自然是不相容的。我們在它們之間建立了一種特殊的明確相容性：您可以將 GNU GPL 第 3 版下的原始碼與 GNU Affero GPL 下的其他原始碼包含在一個組合程式中。這是允許的，因為這兩個授權條款都明確說明了這一點，並且效果是 GNU AGPL 適用於組合程式。但是，您不能簡單地將程式碼從 GNU GPL（無論是否帶有「或更高版本」）重新授權為 GNU Affero GPL，反之亦然；這些授權條款都不允許這樣做。另請注意，GNU Affero GPL 第 3 版不是普通 GNU GPL 第 2 版的「更高版本」，因為 GNU Affero GPL 和 GNU GPL 是兩個不同的授權條款系列。

GNU 寬鬆通用公共授權條款第 3 版實際上是 GNU 通用公共授權條款第 3 版加上一些額外的許可。GPL 第 3 版（第 7 節）規定您可以隨時刪除添加的許可，這樣做您就可以獲得與普通 GNU GPL 第 3 版相同的程式碼。如果程式允許在 GNU LGPL 第 3 版或更高版本下使用，您可以將其重新授權為 GPL 第 3 版或更高版本；對於每個未來的 GPL 版本 N（N > 3），我們都將製作一個 LGPL 版本 N，它由 GPL 版本 N 加上添加的許可組成。

至於 GNU 寬鬆 GPL 第 2.1 版，它明確允許重新授權為 GNU GPL 第 2 版或更高版本。

中等型授權條款是指那些對重新發布有實質性要求但不是著作權保護型授權條款的授權條款。範例包括 Eclipse 公共授權條款和 Mozilla 公共授權條款。中等型授權條款往往與任何著作權保護型授權條款不相容，因為它們的要求不允許組合程式在著作權保護型授權條款下。Mozilla 公共授權條款允許重新授權為 GNU GPL，除非程式碼明確拒絕此許可。

最後，雙重授權條款呢？[5] 雙重授權條款是一種析取：它意味著同一個程式帶有多個不同授權條款的選擇。例如，舊版本的 Perl 帶有雙重授權條款：藝術授權條款和 GNU 通用公共授權條款的析取。這意味著每個使用者都可以選擇在其中一個或另一個授權條款下使用和重新發布 Perl，或者像 Perl 發行版本身一樣在兩者析取的授權條款下使用和重新發布。如果析取中的任何一個授權條款選擇與該組其他授權條款相容，則析取與一組其他授權條款相容。

當您為您的程式碼選擇授權條款時，請選擇 GNU GPL 第 3 版或更高版本，或與之相容的某些授權條款。這是使您的程式碼幾乎可以與所有自由軟體語料庫組合的方式。選擇 GPL 或 AGPL 第 3 版或更高版本，也將盡最大努力捍衛您的程式碼所有版本的所有使用者的自由。

組合程式碼

當一組授權條款相容時，這意味著您可以合法地組合或合併許多程式，每個程式都在這些授權條款之一授權下。那麼，組合程式是如何授權的呢？

每個自由軟體授權條款都規定您必須將授權條款與其涵蓋的程式碼一起保留。因此，從嚴格意義上講，組合程式的授權條款包括其所有部分的授權條款。但是，有時您想要一個關於組合程式如何授權的摘要答案。使用組合程式的人需要關注哪些授權條款？

要計算出這一點，您首先要列出所有相關的授權條款。然後，您可以從列表中刪除列表中另一個授權條款所包含的任何授權條款。

當遵守授權條款 A 意味著遵守授權條款 B 時，我們說授權條款 A 包含授權條款 B。

例如，GNU GPL 第 N 版和 GNU Affero GPL 第 N 版都包含 GNU 寬鬆 GPL 第 N 版，並且這三個都包含 GNU 寬鬆 GPL 第 2.1 版。

任何 GNU 授權條款，第 N 版，都包含 Apache 2.0 授權條款，前提是 N 至少為 3。

GNU GPL 第 N 版包含與之相容的所有版本的 Mozilla 公共授權條款。

Apache 2.0 授權條款包含 BSD、Expat、X11、ISC 和 CC-0 授權條款。BSD 3 條款包含 BSD 2 條款。BSD 授權條款包含 Expat、X11 和 ISC 授權條款以及 CC0。

這並非旨在成為完整列表，但如果我們被告知其他值得提及的情況，我們將添加它們。

當某些授權條款被包含時，您仍然需要在組合程式的所有發行版中包含它的副本。

腳註

關於程式的特定組合，可能會出現其他法律問題，這些問題與要組合的程式的著作權授權條款無關，這並非不可思議。我們僅討論授權條款本身的含義。
實際使用中主要的、不合理運作的授權條款是 TeX 的授權條款：如果兩個程式的授權條款與 TeX 完全相同，則沒有授權方式來發行它們的合併版本。

TeX 授權條款僅允許以原始版本加上差異檔案的形式發行修改後的版本。如果 A 和 B 以這種方式單獨發布，然後合併，則將合併後的程式作為 A 加上更改檔案發行會違反 B 的授權條款。將其作為 B 加上更改檔案發行會違反 A 的授權條款。以任何其他方式發行都會違反兩個授權條款。

TeX 在 1982 年發布並非巧合：從那時起，我們的社群學會了編寫合理運作的授權條款。
以原始碼形式發行時，通常只需將授權條款聲明保留在原始碼中即可；額外的授權條款聲明要求通常僅在發行不帶原始碼的二進位檔案時才會針對寬鬆授權條款出現。
此外，GPL 第 2 版仍然允許透過拒絕除特殊簽名二進位檔案之外的所有檔案的硬體使二進位檔案成為非自由軟體，並且仍然不允許透過 torrent 發行二進位檔案。我們在第 3 版中修復了這些問題和其他問題，但我們無法更改第 2 版。
有些人使用術語「雙重授權條款」來指代出售例外情況，但這是一個誤稱。請參閱出售例外情況。請注意，如果出售授權條款的程式包含任何不在自由（libre）發行版中的程式碼，那不是出售例外情況，那是專有軟體。