總結了一下各類軟體許可協議

語言: CN / TW / HK

theme: nico

持續創作,加速成長!這是我參與「掘金日新計劃 · 10 月更文挑戰」的第10天,點選檢視活動詳情

介紹

軟體許可證(或軟體許可協議)是一種具有法律性質的合同或指導,由軟體作者與軟體使用者簽訂,用以規定和限制軟體使用者使用、拷貝、修改和再發布軟體(或其原始碼)的權利,以及軟體作者應盡的義務。

常見許可證及其差異

根據許可證使用時間,軟體許可證可分為終身許可證和年度許可證。 - 終身許可證,顧名思義,便是一旦與軟體開發商達成協議,簽訂合同後可終身無限制的使用該軟體。此類許可證多見於個人使用者領域。 - 年度許可證,指的是客戶與軟體開發商商簽訂協議,按年付費來使用該軟體。此類軟體許可證多見於商業軟體領域。相比終身許可證,年度許可證不太像是購買軟體,而更像是租賃軟體使用,不過卻更為靈活。

分發(distribution)指將版權作品從一個人轉移到另一個人或公司,如果你是自己使用,不提供給他人,就沒有分發。雲服務(SaaS)不構成分發,即你使用開源軟體提供雲服務,不必提供原始碼。但是,Affero GPL (AGPL) 許可證規定雲服務也必須提供原始碼。

常見的許可證主要有 GPL、LGPL、AGPL、MPL、MIT、BSD 和 Apache,各個許可證還包含不同版本。根據使用條件不同,可以將這些許可證大致分為兩類:Copyleft 許可證和寬鬆式許可證(permissive license),主要對使用、修改和分發的場景作出相應約束。

寬鬆式許可證

最基本的型別,對使用者幾乎沒有限制。 - 使用者可以使用程式碼,做任何想做的事情,可以修改程式碼後閉源。 - 不擔保程式碼質量,使用者自擔風險。 - 使用者必須披露原始作者。

寬鬆式許可證都規定分發軟體時,必須保留原始的許可證宣告,區別在於要求使用者遵守的條件不同。 1. BSD(Berkeley Software Distribution) —— 特點是可以自由使用、修改、再發布。但是在商用或者個人分發過程中必須帶有原來程式碼的許可證,且不能用原作者相關資訊去做宣傳。 2. MIT —— 源自麻省理工學院(Massachusetts Institute of Technology, MIT),是使用最廣泛的一種開源許可證。其特點和 BSD 許可證類似,只要在專案的所有副本中包含版權宣告和許可宣告,就無需承擔任何責任。 3. Apache —— 作為寬鬆式許可證中的一員,Apache 多了幾個限制條件,禁止使用其商標與作者的相關資訊進行商業行為,必須明確指出所有修改過的檔案。

Copyleft 許可證

Copyleft 是一種讓程式或其它作品保持自由(是言論自由的自由,而不是“零價格”)的通用方法,並要求對 Copyleft 程式的任何修改和擴充套件都保持自由。

Copyright 直譯是"複製權",這是版權制度的核心,意為不經許可,使用者無權複製。Copyleft 是理查德·斯托曼發明的一個詞,與 Copyright 相對,Copyleft 的含義是不經許可,使用者可以隨意複製。核心是:修改後的 Copyleft 程式碼不得閉源,比寬鬆式許可證的限制要多: - 如果分發二進位制格式,必須提供原始碼。 - 修改後的原始碼,必須與修改前保持許可證一致。 - 不得在原始許可證以外,附加其他限制。

對使用者的限制從最強到最弱排序:AGPL > GPL > LGPL > MPL。 1. AGPL(Affero 通用公共許可證) —— AGPL 是 GPL 的一個補充,在 GPL 的基礎上加了一些限制。GPL 的約束生效前提是該軟體 "釋出",有的公司就使用 GPL 元件編寫 web 系統,但是不釋出系統,只用這個系統線上提供服務,這樣就避免了開源系統程式碼。而 AGPL 要求如果雲服務 (即 SaaS) 用到的程式碼是該許可證,那雲服務的程式碼也必須開源。 2. GPL(通用公共許可證) —— GPL 和 BSD 區別還是很大的,GPL 主張程式碼及衍生程式碼的開源,不允許修改後和衍生的程式碼做為閉源的商業軟體進行釋出和出售。如果已釋出商業軟體原始碼裡含有 GPL 開源軟體原始碼,則必須對該商業軟體進行開源或者下架處理。 3. LGPL(Lesser 通用公共許可證) —— LGPL 允許商業軟體通過類庫引用的方式使用 LGPL 類庫,而不需要開源商業軟體原始碼。 4. MPL(Mozilla 公共許可證) —— 在商業軟體中,如果含有 MPL 許可證的程式碼在單獨的檔案內,其他新增的檔案就可以避免開源。

許可證種類

如何選擇

烏克蘭程式設計師 Paul Bagwell,畫了一張分析圖,說明應該怎麼選擇。下面是製作的中文版:

free_software_licenses.png

一些示例包括: - Apache:需要 Apache 2.0 協議。 - Cloud Native Computing Foundation:預設規定 Apache 2.0 協議。 - GNU:建議大多數程式使用 GNU GPLv3 協議。 - NPM packages:絕大多數使用 MIT 或非常相似的 ISC 協議(等同於 BSD 2 和 MIT)。 - OpenBSD:更建議 ISC 協議。 - Rust:程式包基本上都同時使用 MIT 和 Apache 2.0 兩個協議來授權。 - WordPress:外掛和主題必須為 GNU GPLv2 協議(或更高版本)。

軟體

通常來說,我們推薦使用最 Copyleft 而不影響目的的許可證。對大多數程式,我們推薦使用最新版的 GPL。它強大的 Copyleft 適合所有型別的軟體,並對使用者的自由有很多保護。為了將來許可證的升級,請宣告 “版本 3 或者任何新版本”,這樣你的程式就 在許可證層面相容其他將來按照後續 GPL 版本釋出的程式。

小程式

對大多數小程式,使用 Copyleft 是不值得的。我們用300行作為基準:當一個軟體包的原始碼比這個短,Copyleft 帶來的好處通常太小,不足以對抗確保許可證的複本總是伴隨軟體的不便。

對這些程式,我們推薦 Apache 2.0 許可證。這是一個弱的、鬆散的、“順從型”(非 Copyleft)軟體許可證,它有用於避免貢獻者和分發者起訴專利侵權的條目。這並不會讓軟體避免來自專利的威脅(一個軟體許可證是做不到的),但它避免了專利持有者打著自由的幌子釋出軟體,這種情況下專利持有者會相當於做了一次“誘導轉向”,然後要求接受者同意專利證書中的非自由條目。

在不嚴格的(順從型)許可證中,Apache 2.0 是最好的;所以如果你要用一個不嚴格的許可證,不論什麼原因,我們推薦用這一個。

對於庫,我們分三種情形。 1. 如果你是專有應用開發者使用自由標準的庫,那麼你就應該對這些庫使用寬鬆的許可證,比如 Apache 2.0 許可證,這樣專有應用就容易包含這些庫。 2. 如果開發者已經使用現有的以非自由或不嚴格的 pushover 許可證釋出的庫,那麼我們建議使用 Copyleft 許可證 LGPL。較為寬鬆的 GPL(LGPL)允許私有軟體開發者使用其保護起來的庫,LGPL 提供了給使用者自由的弱 Copyleft。 3. 對於提供了特別設計,並且不會與現有非 Copyleft 或非自由庫競爭的,我們推薦使用原始的 GNU GPL。

伺服器軟體

如果其他人很有可能會給你在伺服器上跑的軟體製作改進版並且不向其他人分發他們的版本,而且你擔心這將把你的版本置於一個不利的地位,我們推薦 AGPL。AGPL 的條目和 GPL 幾乎相同,唯一實質的區別是它有一個額外的條件確保通過網路用這個軟體的人們可以獲得它的原始碼。

專利

某些許可證(Apache 2 和 GPL v3 等)包含明確的條款,授予使用者許可使用軟體所包含的所有專利。BSD 3條款淨化版許可證、開放資料庫許可證和知識共享許可證明確宣告它不授予貢獻者專利的任何權利。另一些許可證(BSD、MIT 和 GPL v2)沒提到專利。但是一般認為,它們預設給予使用者專利許可,不構成侵犯專利。除非有明確的"保留專利"的條款,使用開源軟體都不會構成侵犯專利。

案例

  1. 2019 年,在數字天堂北京網路技術有限公司 訴 柚子北京科技有限公司的案件中,柚子北京 由於開發人員在 2015 年使用了 數字天堂 的 HBuilder 軟體工具中三款外掛的部分原始碼,未遵守開源軟體許可證,將具有開源要求的軟體產品作為商業產品。被開源軟體的著作權人訴請違約和侵權,故而承擔法律責任。
  2. 2021 年 4 月 30 日,羅盒公司狀告風靈公司侵權獲賠 50 萬元,同時要求風靈公司停止侵權行為。在該案件中原告羅盒公司,獨立開發 “羅盒 (Virtual App) 外掛化框架虛擬引擎系統 V1.0”(簡稱 VirtualApp V1.0),在 2016 年引入 GPL3.0 許可證,於 2017 年取得計算機軟體著作權登記證書,且宣告用於商業用途請購買商業授權。2018 年原告發現名為 “點心桌面” 的軟體使用了 VirtualApp V1.0 的程式碼,經過原始碼分析對比,發現兩者之間高度相似,遂起訴被告福建風靈公司。經法院審判被告賠償原告為制止侵權行為而支出的合理費用 50 萬元。此次判決是中國首個明確 GPL3.0 許可證具有法律效力的案例。
  3. 2021 年 12 月中旬,抖音海外版 TikTok 上線一款名為 TikTok Live Studio 的 APP,有網友發現,此軟體違反 GPL 許可證,違規使用開源軟體 OBS(一個免費的開源視訊錄製和視訊實時流軟體,且允許任何人免費應用和商用)的原始碼,既然允許商用,但是為什麼還會被曝違規呢?這裡就需要再科普一下 GPL 許可證,GPL 許可證具有很強的傳染性,如果一款軟體使用 GPL 許可證的開源軟體原始碼,那麼該軟體也必須採用 GPL 許可證,進行開源或者下架處理。此事曝光之後,OBS 開發者證實此事,TikTok 也對此事進行了迴應,並刪除 TikTok Live Studio 的下載頁面。

建議

  1. 軟體開發者使用開源軟體時,需要謹慎選擇開源軟體,關注其開源許可證的內容及相關條件,避免潛在的法律風險。
  2. 企業應當建立一個完善機制,識別企業中所使用的開源軟體清單,明確對應的開源許可證及權利約束,及時規避相關合規風險。
  3. 通過隔離機制避免開源許可證傳染,如對於 MPL 許可證下程式碼的使用,應把該許可證的程式碼放在單獨的檔案內避免許可證傳染;LGPL 下的程式碼,可採用動態連結呼叫該許可證的庫實現隔離。
  4. 有些元件是存在多種許可證的,可能不同目錄檔案指定的許可證型別不一樣,要特別注意。
  5. 有些元件你沒有直接依賴,但是可能存在間接依賴的情況,你需要特別注意檢視相關元件的依賴關係。
  6. 使用 murphysec 開源工具掃描您的程式碼目錄,它會幫您一鍵識別出來您的程式碼專案中使用的所有開源元件,包括直接依賴和間接依賴的元件清單,同時列出所有元件對應的開源許可證資訊;根據報告的提示可以明確看到對應元件的許可證在什麼場景下存在許可證合規風險;根據許可證的合規風險提示,來判斷您的專案是否存在違反的可能性,並調整您所引入的元件,來解決這個風險。

使用

在原始碼的根目錄中建立一個文字檔案(通常命名為 LICENSE 或 LICENSE.txt),並將許可證文字複製到該檔案中。將 [year] 替換為當前年份,並將 [fullname] 換為版權所有者的姓名。如果可以,新增軟體許可協議到專案程式包的描述中(例如:Node.js、Ruby、和 Rust),這將確保許可證顯示在軟體包目錄中。

參考資料

  1. 附錄
  2. 如何選擇開源許可證?
  3. 為什麼GPL是更好的開源許可證?
  4. 總結了一下程式設計師們都應該知道的各類開源許可證及合規相關的知識