文章目錄
- 前言
- 關于BlackDuck許可證風險對比圖
- 弱互惠型許可證
- 舉個例子
- 具體示例
- LGPL系列
- LGPL-2.0-only
- LGPL-2.0-or-later
- LGPL-2.1-only
- LGPL-2.1-or-later
- LGPL-3.0-only
- LGPL-3.0-or-later
- MPL系列
- MPL-1.0
- MPL-1.1
- MPL-2.0
- EPL系列
- EPL-1.0
- EPL-2.0
- 互惠型許可證
- GPL系列
- GPL-1.0
- GPL-2.0
- GPL-3.0
- EUPL系列
- EUPL-1.0
- EUPL-1.1
- EUPL-1.2
- CECILL系列
- CeCILL 1.0
- CeCILL 2.0
- CeCILL-B
- CeCILL-C
- 強互惠型許可證
- AGPL系列
- AGPL 1.0
- AGPL 3.0
- SSPL系列
- SSPL 1.0
- 總結
前言
接上篇文章所講,使用開源組件,忽略開源許可證問題是存在合規風險的,但是關于什么場景下真實存在風險,以及什么樣的風險?很多文章也沒有講的很明白,這些內容大部分都隱藏在晦澀難懂的許可證原文里面。通過一段時間的接觸,包括收集資料、翻譯許可證原文等學習,特此整理了一部分……
關于BlackDuck許可證風險對比圖
不知道你是否跟我一樣看到僅匯總、實施標準、先決條件……,是不是一臉懵??,還是不清楚導致這是組件的什么用法,知名SCA工具對于許可證這一點做的似乎并不是特別友好,不知道掃出來一大堆許可證,安全部門或者法務(有些公司許可證合規問題是由法務部門處理)是不是也是一臉懵。
下面進行一些許可證風險場景整理,以及再總結一張較為口語化的風險對比圖……
弱互惠型許可證
允許代碼與閉源軟件結合使用,但要求對許可證下的代碼修改部分保持開源
即許可證允許你將開源代碼與閉源代碼一起使用,但如果你修改了開源部分的代碼,那么你必須將這些修改也開源
舉個例子
假設有一個閉源的圖像處理軟件,使用了一個LGPL許可的圖像處理庫(例如libpng)來處理PNG文件。有以下兩種場景:
- 直接結合使用:
直接將libpng庫集成到該閉源軟件中,并發布軟件,這種情況下不需要將整個軟件開源。
只需在軟件文檔中包含libpng的LGPL許可證文本和版權聲明。 - 修改部分保持開源:
如果你發現libpng庫中有個錯誤或者你需要一個新的功能,你對libpng庫進行了修改。
根據LGPL許可證,你必須將修改后的libpng代碼開源,并以LGPL許可證發布。
這意味著你需要提供修改后的libpng源代碼,并在文檔中注明這些修改。
具體示例
假設你修改了libpng庫中的一個函數,以提高它的性能:
// libpng 修改后的函數
void improved_png_function() {
// 改進的代碼
}
在這種情況下,你需要將修改后的libpng代碼開源,并確保任何人都可以獲得這些修改后的源代碼。這可以通過在你的軟件發布頁面提供一個下載鏈接,或者將代碼提交到公共代碼庫(如GitHub)上。同時,你的閉源圖像處理軟件依然可以保持閉源。
提供修改后的libpng庫源代碼
下載鏈接:<提供修改后的libpng庫代碼的鏈接>
修改說明:<簡要說明你對libpng庫所做的修改>
LGPL系列
LGPL(Lesser General Public License)是GNU許可證家族的一部分,旨在為開源軟件提供一種更靈活的共享方式。不同版本和變體的LGPL許可證在細節和要求上有所不同。
運行環境:
LGPL 許可的核心要求在所有語言中都是一致的,即允許動態鏈接庫而無需開源應用程序代碼,但靜態鏈接庫時需要提供重新鏈接的機制和開源對庫的修改部分。
LGPL-2.0-only
許可證原文
特點:
修改和分發:允許用戶修改和分發修改后的版本,但必須以LGPL-2.0許可證發布。
鏈接要求:允許與閉源軟件鏈接,但要求修改后的庫本身必須開源。
分發源代碼:在分發修改后的版本時,必須提供相應的源代碼。
適用場景:適用于需要確保庫保持開源,但允許其與閉源軟件結合使用的項目。
版本變化:首次發布:這是LGPL的第一個版本,旨在提供更寬松的條件,以促進自由軟件庫的使用。