?

【編者按】本譯文系開放原子開源基金會源譯識項目組與ALC Beijing聯合發布，由郭雪雯、薛楊潔翻譯，經姜寧、王荷舒審校。本譯文基于CC-BY 4.0許可，為選用Apache許可證進行分發的開源項目提供參考，通過共譯凝聚對開源的共識。

如果您有任何疑問，歡迎聯系我們translation@openatom.io或訪問源譯識項目倉庫https://atomgit.com/translation.

譯文全文

（雙語對照版請瀏覽文末“閱讀原文”）

目的

本政策向Apache軟件基金會的項目提供許可指引，列出了第三方開源組件納入Apache軟件基金會產品時可接受的許可證。

項目可將許可問題提交給法務委員會JIRA進行討論。

許可證標準

下列標準作為本頁許可證分類指引。

1、許可證必須符合開源定義?。

2、在實踐中適用的許可證不得在Apache 2.0許可證所設限制之外再設置實質限制。

?.（最后訪問：2019-02-16）

宏觀分類

本政策在宏觀上將許可證分為三類。

A 類：Apache軟件基金會產品中可以納入A類許可證。它們可稱之為“類Apache”的許可證。

B 類：Apache軟件基金會產品在特定條件下可以納入B類許可證。該類許可證“有可能”被納入。

X 類：Apache軟件基金會產品中不得納入X類許可證。

A類：

我們能在ASF項目中納入什么？

從可否納入Apache軟件基金會產品的角度考慮，我們認為以下許可證與Apache 2.0許可證條款類似：

? Apache 許可證2.0

? Apache 軟件許可證1.1，包括其變體：

-PHP 許可證3.01

-MX4J 許可證

? BSD（不含廣告條款）- 包括其變體：

- BSD 2條

-BSD 3條

-DOM4J 許可證

-PostgreSQL 許可證

-Eclipse 分發許可證1.0

-Lawrence Berkeley 國家實驗室 BSD

?MIT / X11

-ISC

-新澤西州標準 ML

-杯形語法分析器生成器

?ICU

?伊利諾伊大學/ NCSA

?W3C 軟件許可證

?W3C 社區貢獻者許可協議-在發布至少45天后適用

?X.Net

?zlib/libpng

?FSF autoconf 許可證

?DejaVu 字體（Bitstream Vera / Arev 許可證）

?學術自由許可證3.0

?服務+組件+架構+技術規范

?OOXML XSD ECMA 許可證

?Microsoft 公共許可證（MsPL）

?知識共享僅版權貢獻

?Python 軟件基金會許可證

?Python Imaging 庫軟件許可證

?Adobe Postcript（R）AFM 文件

?Boost 軟件許可證1.0版

?COLT 中 CERN 程序包許可證，但請注意，這僅適用于 COLT 中的 CERN 軟件包，不適用于其他

?英國開放政府許可證。該許可允許許可方提供自定義歸屬通知。如有，請在 NOTICE 中注明。如果沒有提供，那么在 NOTICE 上注明“包含根據開放政府許可證3.0版許可的公共部門信息”。

?WTF 公共許可證

?浪漫 WTF 公共許可證

?UNICODE 公司許可協議-數據文件和軟件

?Zope 公共許可證2.0

?ACE 許可證

?Oracle 通用寬松許可證（UPL）1.0版

?開放網格論壇許可證

?谷歌“附加知識產權授權(專利)”文件

?零限制許可證

?歷史許可聲明和免責聲明

?木蘭寬松型軟件許可證, 第2版

?藍橡樹模型許可證1.0.0

此類中多個許可證都包含項目需要遵守的特定署名條款，通常是將其添加到 NOTICE 文件中。請確保您在納入這些作品時有這樣做。

對于“已許可”至公共領域的作品

您可以將處于公共領域（或被與之具有相似效果的許可證所覆蓋）的作品納入Apache產品中。您必須（以與A類清單相似的方式）提供署名。

滿足下列條件之一的作品應被視為處于公共領域：

?該作品帶有

-知識共享公共領域標識

-由作者提供的適當的貢獻（至公共領域）聲明

?有明確的證據證明該作品的美國版權

-保護期屆滿

-無法被主張

我們視為與公共領域具有相似效果的許可證有：

?知識共享CC0 “無權利保留”

?知識共享公共領域證明

請注意某作品是否處于公共領域可能是個疑難問題。判斷某作品的版權保護期是否屆滿可能很重要，并且在不同的司法管轄區中可能有不同的結論。如果您對某作品是否屬于公共領域存疑，請在legal-discuss@上或者通過JIRA議題來提交話題。

B類：

我們或許能在ASF項目中納入什么？

您可以在Apache軟件基金會產品中納入本節所述的許可證和/或項目，前提是其滿足特定條件。

恰當標記的條件

在所有B類相關情形下，其被納入我們的產品這一事實都不應使我們的用戶感到意外。如果我們能為發行版附上恰當且顯著的標記，用戶更有可能知道存在與Apache許可證明顯不同的限制。恰當且顯著的標記是指用戶在了解發行版時會讀到的標記（例如在README文件中），且該標記應該指明第三方產品及其許可證，并且提供其主頁鏈接。也請遵守該特定許可證中的任何署名/聲明要求。

僅以二進制形式納入的條件

任何B類許可下的作品僅得以二進制的形式納入Apache軟件基金會的便利二進制發行版中。不得將B類許可下的作品納入源代碼形式的發行版本中。

“弱著佐權”許可證

本節中提及的每個許可證都要求某種程度的互惠性。這可能要求采取額外行動，以盡量減少Apache產品的用戶在不了解適用要求的情況下對Apache產品中基于不同許可要求部分進行衍生創作的可能性。

如果您進行恰當標記（見上文），您可以在Apache產品中以二進制形式納入基于以下許可證的軟件：

?通用發展和分發許可證：CDDL 1.0和 CDDL 1.1

?通用公共許可證：CPL 1.0

? Eclipse 公共許可證：EPL 1.0

? IBM 公共許可證：IPL 1.0

? Mozilla 公共許可證：MPL 1.0，MPL 1.1和 MPL 2.0

? Sun 公共許可證：SPL 1.0

?開放軟件許可證3.0

?Erlang 公共許可證

?UnRAR 許可證（僅用于解壓縮）

?SIL 開放字體許可證

?Ubuntu 字體許可版本 1.0版

?IPA 字體許可協議 1.0版

?Ruby 許可證（包括將 GPLv2 列為可選的 Ruby 1.9.2 舊版本許可證

? Eclipse 公共許可證2.0：EPL 2.0

通過僅以目標碼/二進制形式納入，減小了基于第三方作品進行衍生創作的可能。這回應了本政策的第二個指導原則。

對于ASF產品在運行時直接使用的少量源代碼的情況，該源代碼未經修改且無論如何也不太可能被修改的（如因被某一標準所規定），您可以納入經過適當標記的源代碼。例如web-facesconfig_1_0.dtd，納入此代碼是JSR 127:JavaServer Faces技術參數的強制規定。

納入知識共享署名許可下的內容

知識共享署名（CC-BY）許可證（第2.5、3.0和4.0版）下的作品包含與“有效技術措施”相關的條款，這可能會讓用戶感到意外。因此您應當對其作出恰當標記并且僅以二進制形式納入。

在知識共享署名-以相同方式分享下所許可的未經修改的媒體內容

您可以在Apache產品中納入在知識共享署名-以相同方式共享2.5版、知識共享署名-以相同方式共享3.0版和知識共享署名-以相同方式共享4.0版下許可的未經修改的媒體內容，只要您遵守許可證中的署名條款，這可能要求對LICENSE/NOTICE/README作出修改。如果涉及其他類型知識共享-以相同方式分享許可證下許可的作品，請聯系Legal PMC。

請注意，媒體內容是指在我們的文檔中使用的二進制視覺/視頻/音頻元素。我們無意將其納入源代碼中。

我能從Stack Overflow復制代碼并將其貢獻給ASF項目嗎？

不能，除非您聯系原作者并從其處獲得在Apache項目中根據Apache 2.0許可證使用其代碼的權利。

Doug Lea并發庫

Doug Lea并發庫屬于公共領域，但其中包含的某些Sun文件不屬于公共領域。您可以按類似上述“弱著佐權”列表資源的納入方式將該庫納入ASF產品中。“如果進行恰當標記，可以將其以二進制形式納入Apache產品中”。如果要使用源代碼，則請移除Sun許可給Doug的文件，并將其按A類處理（或者從Harmony獲取文件）。

將OSGi元數據添加到弱著佐權許可下的二進制文件中

您可將OSGi元數據插入“B類”許可下的Jar文件中，只要您在對Jar文件的顯著標記中說明您這樣做了。

Cobertura報告

您可以將Cobertura報告納入ASF發行版中。

對于禁止修改的許可證

有些許可證對未經修改的副本的再分發賦予了廣泛的權利。此類許可證不是開源的，但它們確實滿足上述第二條和第三條指導原則。

Apache項目不得在版本控制或發布的源碼包中包含此類許可證下許可的材料。但在構建過程中自動下載諸如字體和標準化數據之類的非軟件材料，并將它們納入生成的二進制文件中的情況是允許的。此種使用方式明確表明，這些依賴不是該項目開源代碼的一部分。

如上所述，您可以使用基于下列許可證許可的材料：

?用于 PDF CJK 字體的 CMaps

?JCR API jar 文件（Day Spec 許可證+附加許可）

?WSDL（2004）schema 文件許可證

在ASF產品中納入構建工具

許多語言已經發展出相關工具的生態，這些工具幫助構建發行版的構件。鑒于這些工具可能并不總在其他兼容許可證下可得，我們已經批準了允許納入Apache產品發行版的特定工具，以便其用于該特定目的。

請注意，該工具不得影響項目源代碼的許可。我們也期望使用該工具構建源代碼也是該工具的典型用途。

截至目前，我們已經為此類用途批準下列工具：

? Autotools 產品族，特別是：

- Autoconf

- Automake

- Libtool

- mkinstalldirs.sh

?OCamlMakefile

?setup.rb

在創建動態加載的XS模組時納入Perl許可的頭文件

對鏈接已編譯的C語言代碼以創建動態加載的XS模組的Perl綁定程序進行開發，需要納入Perl許可證（http://dev.perl.org/licenses/- GPL-any/Artistic1,包含例外）下許可的頭文件。

您可以納入這些頭文件—— XSUB.h, perl.h 和 EXTERN.h(參見：LEGAL-79)。

納入Doxygen生成的配置文件

您可以使用這些文件，只要您移除了生成的注釋。

Apache項目能夠包含基于Ruby許可作品的外部依賴嗎？

一個主要且明顯使用Ruby編寫的項目可以依賴于Matz’s Ruby Interpreter(MRI)，也可以依賴于任何Ruby許可證許可的Gem。

當然，依賴于其他許可證（如MIT）下編寫的其他Gem可能也可以，這取決于具體的許可證。

還請注意，Ruby許可證是被列在上述用于二進制形式的“B類”弱著佐權列表中（例如 JRuby）。

從Java9開始，Javadoc允許納入搜索功能，該功能包含在其他開源許可證下許可的JavaScript。Apache項目可以包含Javadoc嗎?

從Java9開始，Javadoc可以包含在MIT、MIT OR GPL-3.0或GPL-2.0 WITH classpath Exception-2.0下許可的JavaScript。Apache 二進制發行版本（包括Maven javadoc jar）和Apache網站可能會因使用javadoc而包含這個JavaScript。但其不得包含在源代碼發行版本中。

X類：

我們不能在ASF項目中納入什么？

您不得在Apache產品中包含下列許可證：

?不符合“開源定義”：

-二進制碼許可證（BCL）

-英特爾簡化軟件許可證

-JSR-275許可證

-對使用領域有限制：

* 微軟限制公共許可證

*亞馬遜軟件許可證（ASL）

*Satori RTM 的 Java SDK 許可證

*Redis 可用源代碼許可證（RSAL）

*Booz Allen 公共許可證

*Confluent 社區許可證 1.0版

*商業源代碼許可證 1.1

* 任何包含共享條款許可條件 1.0版的許可證

-非商業許可證：

*知識共享非商用變體

*Sun 社區源代碼許可證3.0

?對更大的作品施加限制：

-GNU GPL 1,2,3

*本頁其他部分明確允許的 GNU GPL 的特殊例外(例如 GNU Classpath)。

-GNU Affero GPL 3

-GNU LGPL 2,2.1,3

-QPL

-Sleepycat 許可證

-服務器端公共許可證（SSPL）第1版

-代碼項目開放許可證（CPOL）

?其他關切：

-BSD-4條款 / BSD-4條款（加州大學專用）

-Facebook BSD + 專利許可證

-NPL1.0 / NPL1.1

-荒唐的許可證：

*The Solipsistic Eclipse 公共許可證

*“不要做個鳥人”公共許可證

*JSON 許可證

“其他關切”的詳細說明：

Facebook BSD +專利許可證

Facebook BSD +專利許可證中包含一份PATENTS文件的詳細說明，以有利于許可方而非被許可方的方式將風險轉嫁給我們軟件的下游消費者，因而違反了Apache法律政策關于普適性捐贈者的要求。Facebook BSD +專利許可證的條款內容并非ALv2條款的一個子集，它們也不能像ALv2那樣進行分許可。

NPL

Netscape公共許可證是Mozilla原始許可證，包含針對Netscape適用的修訂內容。這些修訂內容允許“Netscape”（現在是AOL的一部分）無需遵守其他被許可方所必須遵守的互惠性要求。這使得該許可證不符合開源定義第5條（“不歧視個人或團體”）。

荒唐的許可證

這些許可證盡管對其創作者來說很有趣味，但從法律上看存在問題。它們通常包含一些主觀的使用領域限制，例如“不要作惡”，卻沒有給出確定該主觀限制的定義。在某些情形中，它們甚至可能沒有給出符合OSI開源定義的充分授權。我們不希望讓我們的下游消費者感到意外，所以我們禁止使用這樣的許可證。

JSON許可證

從2016年11月3日起，JSON license被歸到“X 類”許可證列表中。在此之前，是允許使用 Json Java庫。請參閱Debian的頁面獲得替代選擇列表。

它們不能被分發

Apache項目不得在ASF源代碼版本或便利二進制版本中分發X類許可證下許可的組件，不論該組件是源碼形式還是二進制形式。與有關平臺的問題一樣，如果組件適用的許可證條款不影響Apache產品的許可，您可以依賴該組件。例如，在構建過程中使用GPL下許可的工具是可以的，但是不可以納入GPL下許可的源代碼。

當它們支持可選功能時，您可以依賴它們

Apache項目可以依賴于在禁止類許可證下許可的組件，如果該組件在可選功能上。在這樣做時，項目應向用戶說明如何獲取和安裝不包含該組件的作品。可選就意味著該組件不是產品標準使用或產品達到理想質量水平所必需的。在這種情況下，您需要問自己的問題是:

?“大多數用戶是否希望使用我未添加可選組件的產品？”

常見問題

Apache產品在什么平臺運行重要嗎？

不重要，除非該平臺的條款影響到Apache產品的許可。例如，創建一個在Windows或Java上運行的產品、創建一個使用網絡服務（如 Google Services或Yahoo Search）的產品、或是創建一個產品（如JBoss或JIRA）的插件都是可以的，而創建一個Linux內核模塊則不行，因為Apache產品本身在這種情況下將不得不以Apache許可證第2.0版之外的其他許可證進行許可。

請注意，這并不意味著您可以重新分發平臺代碼本身。這當然地取決于所述代碼的許可證。如果您對平臺的許可證是否會影響到Apache 代碼有任何疑問，請查閱legal-discuss@郵件列表歸檔看是否之前存在此類問題，如果沒有，請給legal-discuss@發送郵件以解決您的疑問。

庫依賴是否必須進行知識產權審查？

不用。

知識產權審查適用于從Apache之外導入代碼庫以在Apache進一步開發的情形。

當有許可證可供選擇時，我應該如何管理作品？

在納入作品許可證時，請說明您所用的許可證，并只納入您所選的許可證。優先選擇A類，其次是B類，再次是X類。如果（比如說）作品在源代碼頭部已提及有多種許可證可選，則您不必修改作品本身。

什么是必要的第三方聲明？

當一個發行版包含第三方作品時，覆蓋這些作品的許可證可能會要求您以特定的方式告知消費者。這些第三方聲明因許可證而異。Apache 發行版應當包含每個許可證的副本，這些副本通常包含在LICENSE文檔中。對于很多許可證來說，這種聲明方式足以滿足聲明要求。某些許可證要求某些額外聲明。在很多情況下，您可以在所依賴的該構件中包含此聲明。

一個必要的第三方聲明是指上述情況以外的任何第三方聲明。

當發行版包含另一個Apache產品時，請參閱綁定其他ASF產品，獲得所需聲明的指引。

英文原文

https://www.apache.org/legal/resolved.html

ALC Beijing發布地址

https://github.com/alc-beijing/translation/blob/master/apache/license/