昨天，火山引擎被曝不遵守 Apache 2.0 許可證要求，其中的 Application Performance Monitoring - Distributed Tracing(應用性能監控全鏈路版)以非法方式重新發行了 Apache SkyWalking。

Apache SkyWalking 官網上聲稱：

火山引擎的團隊更改了所有軟包名稱，刪除了 Apache 軟件基金會的抬頭，在重新發行時沒有保留 Apache 軟件基金會和 Apache SkyWalking 的 LICENSE(許可證)和 NOTICE(告知)文件。此外，在對方的網站上找不到任何聲明他們在發行 SkyWalking 的內容。

起因

Apache SkyWalking 是一個分布式系統的開源 APM，是 Apache 軟件基金會的頂級項目。

1 月 28 日，Apache SkyWalking 收到了一個提交者(匿名)的許可證違規報告。他們有一個云服務，叫做應用性能監控全鏈路版(Application Performance Monitoring - Distributed Tracing)。在 Java 服務監控部分，匿名提交者提供了這個代理下載鏈接：

??https://datarangers.com.cn/apminsight/repo/v2/download/java-agent/apminsight-java-agent_latest.tar.gz??

Apache SkyWalking 官方團隊下載并在已經將其存檔，已經確認這是一個 SkyWalking Java agent 的二次分發，并給出了三點證據，讀者可以與官方的 SkyWalking 源代碼(https://github.com/apache/skywalking-java)進行比較。

細節

以下是官網披露的違反 Apache 2.0 許可證的細節：

1、第一個也是最簡單的部分是 agent.config 文件，該文件使用相同的配置鍵和相同的配置格式。

這是火山引擎的版本，可以對比 SkyWalking agent.config

2、在 apmplus-agent.jar 即 Volcengine 的代理核心 jar 文件中，你可以輕松找到幾個與 SkyWalking 的核心類一模一樣的核心類。

ComponentsDefine 類根本沒有變化，就連組件 ID 和名稱都一樣

這是火山引擎的版本，SkyWalking 的版本鏈接：

??https://github.com/apache/skywalking-java/blob/395ce4f86ae14cf24af489a6aa7e849b1d9a27ed/apm-protocol/apm-network/src/main/java/org/apache/skywalking/apm/network/trace/component/ComponentsDefine.java。??

3、代碼名稱、軟件包名稱和代碼層次結構全部與 SkyWalking 6.x 版本一模一樣。

火山引擎版本的軟件包層次結構

SkyWalking 的版本詳見：

??https://github.com/apache/skywalking-java/tree/v6.6.0/apm-sniffer/apm-agent-core/src/main/java/org/apache/skywalking/apm/agent/core/context。??

Apache 許可證

Apache 許可證是著名的非盈利開源組織 Apache 采用的協議，Apache 2.0 許可證相對 GPL 已經非常寬松了。比如：商業軟件可以任意的使用 BSD，Apache 2.0 發布的軟件代碼不需要開放源代碼，只需要提及代碼的原出處就可以了。

協議中明確寫出，只要遵守該許可的條款和條件的前提下，每位貢獻者將被授予永久的、全球性的、非排他性的、免費的、免版稅的、不可撤銷的版權許可，以復制、準備衍生作品、公開展示、公開使用、再許可、分發本作品和其衍生作品(無論是以“源碼”還是“目標”形式)。

也就是不僅可以用，還可以對基于 Apache License Version 2.0 的作品或衍生作品進行修改或增補，并應用到商業項目。但前提是滿足以下幾個條件：

1. 需要給代碼的用戶一份 Apache License;
2. 如果你修改了代碼，需要在被修改的文件中說明;
3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明;
4. 如果再發布的產品中包含一個 Notice 文件，則在 Notice 文件中需要帶有 Apache License。你可以在 Notice 中增加自己的許可，但不可以表現為對 Apache License 構成更改。

也就是說，就是需要在相關產品的發行版本，Notice 文件、源碼或文檔里，添加歸屬聲明的可讀拷貝，并給接收者提供開源項目中提供的 Apache License Version 2.0 許可證的拷貝，在分發的衍生作品的源代碼中，必須保留本作品源碼中的所有版權、專利、商標和歸屬聲明。

反思

所有的開源許可證都帶有"披露要求"(notice requirement)，即要求軟件的分發者必須向用戶披露，軟件里面有開源代碼。如果一種開源許可證沒有任何使用條件，連保留作者信息都不需要，那么就等同于放棄版權了。

其實遵守并不難。一般來說，你只要在軟件里面提供完整的原始許可證文本，并且披露原始作者，就滿足了"披露要求"。

開源協議在方便每個開發者貢獻代碼的同時，不但保護原始作者的身份，也是為了可以阻止其它人將某個產品據為己有。

目前，世界上流行的開源協議也不少，如何來選擇也是開發者需要考慮的問題。關于常用的開源許可證，最流行的六種 ----GPL、BSD、MIT、Mozilla、Apache 和 LGPL---- 之中做選擇，也很復雜。

烏克蘭程序員 Paul Bagwell，畫了一張分析圖，這里附上一張中文版，希望能幫助大家搞清楚這六種許可證之間的最大區別。

總結

目前國際公認的開源許可證的共同特征是，都允許用戶免費地使用、修改、共享源碼，但是都有各自的使用條件。在如今一個大的開源開發背景下，開源軟件衍生的商業產品越來越多，開發者在選擇和使用開源代碼時，一定要注意遵守開源協議。

火山引擎相關負責人表示，火山引擎接到社區反饋后，第一時間調查處理此事，正在相關產品文檔和分發SDK上加入SkyWalking的版權聲明，并聯系開發者溝通道歉。

火山引擎會嚴格遵循開源社區規范，全面自查，避免此類問題再次發生。