開源授權常識補充包(2024 版)

【聲明】本文為非法律背景開發者對開源授權的不專業理解，不擔保資訊正確(如發現謬誤歡迎指正)，讀者請自行衡量風險或請教相關專家。

這年頭開發系統，你很難完全不碰開源軟體或程式庫，但開源不代表可以免費任意使用，有些開源授權條款仍需遵守才不致惹上麻煩，歷史上不乏公司因此被告的案例，例如：Cisco Linksys 違反 GPL、VMware ESXi 未遵守 GPLv2 要求開源。

為避免違反開源授權條款，寫程式寫到被吉。江湖在走，開源授權基本知識要有。

最近查到開源軟體管理廠商 Mend.io (原名 WhiteSource)的一份白皮書 - 當代主要開源授權指南，我認為有一定的專業度與權威性，很值得參考。這篇將以其為依據，簡要整理出開發者該注意的點。

使用開源軟體，有個重要名詞一定要認識- Copyleft。

傳統 Copyright 著作權觀念限制你必須先取得授權才能使用、修改及分享，而 Copyleft 則是作者允許其他人有權使用、修改及分享其作品，但有個前提：使用 Copyleft 程式的專案也必須採用 Copyleft 授權，對全天下公開分享。Copyleft 如病毒感染的特性讓許多人談開源色變，專案只要沾上 Copyleft 程式庫，就得捐出來 大家免費用，獻給競爭對手參考，有哪家企業受得了？

GNU GPL 是 Copyleft 的經典授權，但強迫開源特性令人卻步，導致許多人乾脆避用。開發者的心血成果沒人敢用，產生不了價值，也影響社群參與改良的意願(誰想花時間做沒(人)用的東西呢？)，這有點違背開源的初衷。因此，後來開始出現毒性較弱較溫和的弱化版 Copyleft，例如：GPL with Classpath Exception、Lesser GPL(LGPL)，以及 CDDL、EPL、Ms-PL... 等，將「只要沾邊就必須整個開源」改成「若有修改開源程式庫，修改成果才需以相同授權方式開源」之類較寬鬆的要求，有利於軟體推廣及發展。

Copyleft 之外，有另一種較寬容(Permissive)的開源授權類型，作者允許其他人使用、修改及分享其程式，並可自由決定成果要不要開源。授權會附加一些條件，有些限制只能用於非營利，有些允許免費商業使用，有些要求註明作者，不同授權限制與要求各自不同，應用前需認明。目前常見的寬容授權包含 MIT、Apache、BSD 等，已成為開源授權的主流，數量遠多於泛 Copyleft 家族。

2023 開源授㩲排行榜

MIT 授權因簡短好懂，不需法律專業知識即能理解，是目前開發者最愛的開源授權，獲得 Python、.NET、Ruby on Rails、TensorFlow、React、Vue.js、Angular、Node.js 等熱門專案採用。

Apache 2.0 也很受歡迎，尤其受法律專業人士青睞，主因是它提供專利授權，禁止其他人用專利對原始專案或其貢獻者提出侵權訴訟。經典代表有 Kubernetes、OpenSSL、Swift 及 Rust。

GPL 家族在三年前在開源界還佔有 18% 年的比例，如今只剩 6%，加上 MS-PL 也不到 7%。Linux Kernel 是 GPL 的經典代表。

以下是常見開源授權的對照：

授權	種類	須提供原始碼	須依相同授權 提供原始碼	須依相同授權 開放整個專案	其他注意事項	專利授權
MIT	Permissive	No	No	No		No*
APACHE 2.0	Permissive	No	No	No	需註明重大修改	Yes
BSD 3-CLAUSE	Permissive	No	No	No		No*
GPL V3.0	Strong copyleft	Yes	Yes	Yes
GPL V2.0	Strong copyleft	Yes	Yes	Yes
LGPL	Weak copyleft	Yes	Yes	No		可，基於 GPL v3
MS-PL	Weak copyleft	No	Yes (若有散佈原始碼)	No
AGPL V3.0	Strong copyleft	Yes	Yes	Yes	可透過網路存取即視為散佈
CDDL	Weak copyleft	Yes	Yes	No	需註明修改者	若經修改後具專利授權
ECLIPSE PUBLIC LICENSE (EPL) V2.0	Weak copyleft	Yes	Yes	No
GPL WITH CLASSPATH EXCEPTION	Weak copyleft	Yes	Yes	No		可，基於 GPL v3

Mend.io 文件偏簡略，我另外再參考 Yuren 前輩的文章作為補充：

• 開放源碼授權概觀（上）
• 開放源碼授權概觀（下）

開源授權的核心精神包含：

1. 開放源碼 (Open Source)：提供原始碼
2. 自由散佈 (Free Redistribution)：允許其他人自由散佈
3. 衍生著作（Derived Works）：授權其他人修改衍生出新產品

而使用上的限制與義務由寬鬆到嚴格約略排列如下：

圖片來源

以下整理各授權的重點及差異比較：

1. GPL
   是 Copyleft 的始祖，追求絕對開放並防止成果被企業私產化。專案只要沾到 GPL 元件就必須整個專案採 GPL 開源，且不得改用其他授權。GPL 的相關義務源自散佈(Distribution)行為，若只供內部使用不對外公開時，狀況會單純一些。
   但 Affero / AGPL 是 GPL 家族的例外，即便 GPL 元件只在自家系統執行沒有對外散佈，只要外部使用者能透過網路存取該服務(例如：SaaS)，就符合 AGPL 的公開散佈定義，專案必須以 GPL 公開，算是氰化物等級的劇毒 GPL。
   GPL 具有高度強制性，Free Software Foundation (FSF) 是許多 GPL 作品的擁有者，會對違反授權者提告。
   GPLv3 內容比 GPLv2 長了兩倍，更精準描述 GPL 適用對象與義務(以適用全球法律體系)，尤其防止專利濫用或用硬體製造商阻止用戶修改或升級。
2. GPL with Classpath Exception
   只靜態或動態連結 GPL 元件而未修改元件的系統，可以不用整個專案 GPL 對外公開。
   GPL with Classpath Exception 本質上還是 GPL，但加了一條但書。
3. Lesser GPL (LGPL)
   類似 GPL with Classpath Exception，只引用 LGPL 程式庫但不修改，不需要開源；若修改了 LGPL 程式庫，修改成果要以 LGPL 公開。LGPL 與 GPL 是不同的授權，建議以動態連結(參照編譯好的程式庫而非引入原始碼一起編譯)方式引用，否則當專案以靜態連結引用 LGPL 原始碼，將視為衍生作品，也必須 LGPL 授權釋出。
4. MIT
   可再細分 Expa (SPDX, Software Paackage Data Exchange) 及 X11 兩個版本，一般講 MIT 授㩲是指 Expat 版，後者多講 X11 授權。
   MIT 授權強調軟體以原樣提供(As-Is)不提供任何形式的擔保或保證，作者沒有義務提供任何形式的技術支持、更新或維護，使用時風險自負。跟 Apache 一樣允許自由使用、修改、散佈、銷售且不限定修改後採用的授權。唯一要求是需在軟體全部或部分附上不到 200 字的 MIT 授㩲聲明，一般加段註解即達標。由於對開發者高度友善，所有開源軟體有近 1/3 都採用 MIT。
5. Apache
   由 Apache Software Foundation ASF 推出。Apache 授權非常自由，允許你使用、修改、散佈或銷售，自用、內用或商業使用均可，並可更改為其他授權，Apache 有提供專利授權降低專利訴訟爭議。
   散佈含 Apache 授權元件需附上版權聲明及修改說明，修改或衍生作品可採用其他授權，未變更部分需維持 Apapche 授權，修改版本命名時不可使人誤解與 ASF 有關。
   Apache 2.0 與 GPLv3 相容，都包含專利授㩲，但最大差異是 Apache 不強制引用專案採用相同授權。
   Apache 1.0 跟 BSD 幾乎相同，2.0 與 BSD 的差異在於：Apache 2.0 有明訂著作權、專利授權及商標權細節可減少法律爭議，並可直接用於其他專案不需調整(Rewording)。
6. BSD
   BSD 有多個版本：原始 BSD、3-Clause Modified BSD、2-Clause Simplified BSD/FreeBSD。
   BSD 允許自由修改及散佈原始碼或二進位檔案，前提是要附上版權聲明。原始 BSD 有四個附加款條，修正版 BSD (三條款版)移除了宣傳柏克萊大學貢獻的要求，簡化版(二條款版)再移除禁止以原作者、貢獻者或機構名稱推廣的非背書限制，進一步方便商業使用。
   與 MIT 相比，修正版 BSD 的非背書條款可防止衍生作品利用貢獻者的名字為其背書，散佈時需依當前內容修改 BSD 授權內容；而 MIT 強調無擔保無保證，可直接使用 MIT 原始授權文件，不需要為專案特別修改。
7. Ms-PL
   Ms-PL 是微軟推出的開源授權，允許自由重製、散佈及改寫，但不能使用貢獻者的名稱、Logo 及商標，另外也跟 MIT 一樣，強調作者不提供擔保或保證。
   若選擇以原始碼方式散佈 Ms-PL 軟體時，必須維持 Ms-PL 授權；若釋出是編譯過版本，則可採用其他相容授權。
   Ms-PL 之外有個類似的 Ms-RL，比 Ms-PL 更具強制性，任何包含 Ms-RL 程式的專案都必須以 Ms-RL 授權方式發布並原始碼及授權聲明。
8. CDDL 與 EPL 沒啥機會遇上，先跳過

【結語】

如果可以為專案選擇開源授權，應該用哪個？

• 個人專案可選最鬆散的 MIT 授權，讓使用者可以自由的使用，開源要閉源都行，並沒有太多的限制。
• 公司相關專案可選擇 Apache 授權，跟 MIT 一樣允許開源或閉源使用，但其對著作權及專利權的規格較明確仔細，不易因不同國家的預設著作權行為差異出現爭議。
• 若想禁止衍生作品打著你的名號推廣行銷，可選修正版 BSD (BSD 3-CLAUSE)。
• 若有用到 LGPL 元件或程式庫，若採靜態連結(包入 LGPL 軟體原始碼一起編譯)，則必須也用 LGPL。

A overview and introduction to common open source licenses.