火山引擎違反Apache許可證協議：商業不遵守武德？

昨天，火山引擎被曝不遵守 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，畫了一張分析圖，這裡附上一張中文版，希望能幫助大家搞清楚這六種許可證之間的最大區別。

總結 ^✦

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