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

語言: CN / TW / HK

作者丨雲昭

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

總結

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