常見開源協議詳解：哪些行為被允許？哪些被限制？

開源世界的魅力在于共享與合作，但不同的開源協議對分發、修改、再發布以及宣傳/推廣有不同的要求和限制。很多開發者在 fork 項目、改 README、放到自己倉庫并在自媒體傳播 時，會擔心是否觸犯了協議。

本文將逐一分析常見開源協議，并給出對照表，幫助你快速判斷哪些行為合規，哪些需要注意。

金句總結：

大多數主流開源協議都允許你自由修改、再發布和傳播，只要保留版權、不假冒官方；真正需要警惕的，是那些帶有商業限制或公司自定義的“偽開源”協議。

---

一、四類常見操作定義

在進入對照之前，先明確幾個關鍵詞：

1. 再分發 + 修改

   • fork 項目、修改源代碼或文檔（README、配置文件、接口等）。

2. 再發布

   • 將修改后的項目放到自己的倉庫，或打包發布。

3. 宣傳 / 推廣

   • 在博客、自媒體、視頻等渠道傳播，并附上自己倉庫的鏈接。

---

二、常見開源協議逐一解析

1. MIT License

• 極度寬松，只要求保留原始版權聲明。
• ? 允許修改、再分發、再發布。
• ? 可以隨意推廣和傳播，但不能去掉原作者版權聲明。

典型項目：jQuery、Rails。

---

2. Apache License 2.0

• 與 MIT 類似，但多了“專利權授予”。
• ? 修改、再發布、傳播都允許。
• ? 可以用于商業項目。
• ?? 需要在修改后的版本中明確說明修改內容，并保留原作者版權聲明。

典型項目：Hadoop、Kubernetes。

---

3. BSD (2-Clause / 3-Clause)

• BSD 2-Clause 非常接近 MIT；BSD 3-Clause 增加了一條“不能用原作者名義做背書”。
• ? 修改、再分發、再發布均允許。
• ?? 不允許用原作者名字做宣傳。
• ? 你可以在自媒體推廣，但要避免暗示這是官方版本。

典型項目：FreeBSD、Go 語言（早期）。

---

4. GPLv3 / LGPL

• 嚴格的“傳染性協議”。
• ? 允許修改和再分發，但必須同樣以 GPL 協議開源。
• ? 可以推廣和傳播。
• ?? 不能改成閉源再分發。
• ?? 如果作為庫使用（LGPL），動態鏈接允許閉源，但修改庫本身必須開源。

典型項目：Linux 內核（GPL）、FFmpeg（LGPL）。

---

5. MPL (Mozilla Public License)

• “文件級別開源”協議。
• ? 修改、再分發允許。
• ? 可以用于閉源項目，但修改過的文件必須開源。
• ? 推廣傳播不受限制。

典型項目：Firefox、Thunderbird。

---

6. EPL (Eclipse Public License)

• 類似 MPL，帶“文件級別傳染性”。
• ? 修改、再分發允許。
• ?? 修改后的部分必須繼續遵循 EPL。
• ? 推廣允許。

典型項目：Eclipse IDE。

---

7. SSPL (Server Side Public License)

• MongoDB 推出的協議。
• ? 再分發允許。
• ?? 如果用于提供云服務，則必須開源整個服務端代碼。
• ? 自媒體傳播允許，但商用時限制極大。

典型項目：MongoDB。

---

8. Commons Clause / BSL（商業限制開源）

• 這些協議表面“開源”，實質限制商用。
• ? 允許個人修改、再發布、傳播。
• ?? 不允許將項目用于商業化（收費服務、二次銷售）。
• ? 自媒體傳播沒問題，但商業推廣會觸雷。

典型項目：部分數據庫（如 Redis 一度采用 Commons Clause 組件）。

---

9. 公司自定義“偽開源協議”（如 FIT2CLOUD License）

• 在 GPL 上加限制，常見條款：禁止反編譯、禁止衍生、禁止商業分發。
• ?? 改名、再發布、在自媒體傳播可能被視為違規。
• ? 內部使用通常沒問題。
• ? 基本不算真正意義的開源。

---

三、對照表（總結）

協議類型	再分發+修改	再發布（放倉庫）	宣傳/推廣	特別限制
MIT	? 允許	? 允許	? 允許	保留版權聲明
Apache 2.0	? 允許	? 允許	? 允許	說明修改、保留版權
BSD 2-Clause	? 允許	? 允許	? 允許	保留版權聲明
BSD 3-Clause	? 允許	? 允許	? 允許	不可用原作者背書
GPLv3	? 允許	? 允許	? 允許	必須繼續 GPL 開源
LGPL	? 允許	? 允許	? 允許	修改庫要開源
MPL	? 允許	? 允許	? 允許	修改文件需開源
EPL	? 允許	? 允許	? 允許	修改部分需 EPL
SSPL	? 允許	? 允許	? 允許	提供服務需全開源
Commons Clause	?? 有限制	?? 有限制	? 允許	禁止商用
BSL	?? 有限制	?? 有限制	? 允許	商業化需付費
偽開源協議	? 嚴重限制	? 嚴重限制	?? 有風險	禁止衍生、商業分發

---

四、開發者實用建議

1. 先看 LICENSE 文件

   • MIT/Apache/BSD → 放心大膽玩。
   • GPL/LGPL → 注意“傳染性”，要繼續開源。
   • SSPL/Commons Clause/BSL → 慎用，尤其在商業項目。
   • 自定義協議 → 高度警惕，可能不是“真正的開源”。

2. Fork + 改 README 并傳播，一般安全

   • 只要保留版權聲明，不假冒官方，MIT/Apache/GPL 都支持。

3. 推廣時避免誤導

   • 可以寫“我基于 XXX 項目 fork 的版本”，
   • 但不要寫“這是官方改版”或“原作者推薦”。

---

五、總結

1. “是否允許再發布（fork 到自己倉庫并公開）”
2. “是否允許再分發 + 修改”
3. “是否允許宣傳/推廣（自媒體傳播、貼倉庫鏈接）”

---

1) 是否允許「再發布」

flowchart TDA([是否允許再發布？<br/>（fork 到自己倉庫并公開）]) --> B{所采用的許可證類別}B --> P[寬松協議<br/>MIT / Apache-2.0 / BSD]B --> G[強傳染協議<br/>GPLv3 / LGPL]B --> F[文件級傳染<br/>MPL-2.0 / EPL-2.0]B --> S[服務側開源<br/>SSPL]B --> C[限制商業條款<br/>Commons Clause / BSL]B --> Z[自定義/偽開源<br/>公司定制許可證（如某些“基于GPL但加限制”）]P --> POK[? 允許再發布]G --> GOK[? 允許再發布（但需繼續用 GPL/LGPL 開源）]F --> FOK[? 允許再發布（修改過的文件需開源）]S --> SOK[?? 再發布允許；若提供云服務→需開源整套服務端]C --> CN[?? 視具體條款；常限制商業化再發布/銷售]Z --> ZNO[? 通常禁止再發布/衍生/商業分發]%% 說明卡片POK --- Pnote[保留版權與 LICENSE；<br/>Apache 需保留 NOTICE/說明修改；<br/>BSD-3 禁官方背書]GOK --- Gnote[必須提供源碼或獲取途徑；<br/>修改后繼續 GPL/LGPL；<br/>避免閉源再分發]FOK --- Fnote[僅修改過的文件需開源；<br/>可與閉源代碼并存；<br/>保留版權與 NOTICE]SOK --- Snote[用作 SaaS/云服務時觸發“整套服務端開源”義務]CN --- Cnote[“非商業/禁止出售/不許作為付費服務”等常見限制]ZNO --- Znote[常見條款：禁止衍生、反編譯、再分發、商用等]classDef ok fill:#E6FFED,stroke:#0A7C2E,color:#0A7C2E;classDef warn fill:#FFF6E6,stroke:#C77C12,color:#C77C12;classDef no fill:#FFEAEA,stroke:#B71C1C,color:#B71C1C;class POK,GOK,FOK ok;class SOK,CN warn;class ZNO no;

---

2) 是否允許「再分發 + 修改」

flowchart TDA([是否允許再分發 + 修改？]) --> B{許可證類別}B --> P[寬松協議<br/>MIT / Apache-2.0 / BSD]B --> G[強傳染協議<br/>GPLv3 / LGPL]B --> F[文件級傳染<br/>MPL-2.0 / EPL-2.0]B --> S[服務側開源<br/>SSPL]B --> C[限制商業條款<br/>Commons Clause / BSL]B --> Z[自定義/偽開源]P --> POK[? 一般允許]G --> GOK[? 允許；修改需繼續 GPL/LGPL]F --> FOK[? 允許；修改過的文件需開源]S --> SOK[? 允許；若作為服務對外→觸發全棧開源義務]C --> CN[?? 再分發/修改若涉商業目的可能受限]Z --> ZNO[? 常直接限制修改/衍生/反編譯]POK --- Pnote[要求保留版權、LICENSE/NOTICE；<br/>Apache 需標注修改]GOK --- Gnote[傳播修改版時須同許可；<br/>提供源碼]FOK --- Fnote[僅“被修改的文件”要開源；<br/>便于與閉源組合]SOK --- Snote[核心風險在“對外提供服務”]CN --- Cnote[注意“非商業/禁止盈利/延遲開源（BSL）”等條款]ZNO --- Znote[部分“開源名義”但條款高度限制]classDef ok fill:#E6FFED,stroke:#0A7C2E,color:#0A7C2E;classDef warn fill:#FFF6E6,stroke:#C77C12,color:#C77C12;classDef no fill:#FFEAEA,stroke:#B71C1C,color:#B71C1C;class POK,GOK,FOK,SOK ok;class CN warn;class ZNO no;

---

3) 是否允許「宣傳/推廣」（自媒體傳播 & 貼倉庫鏈接）

flowchart TDA([是否允許宣傳/推廣？<br/>（寫文章/視頻、貼自己倉庫鏈接）]) --> B{許可證類別}B --> P[寬松協議<br/>MIT / Apache-2.0 / BSD]B --> G[強傳染協議<br/>GPLv3 / LGPL]B --> F[文件級傳染<br/>MPL-2.0 / EPL-2.0]B --> S[服務側開源<br/>SSPL]B --> C[限制商業條款<br/>Commons Clause / BSL]B --> Z[自定義/偽開源]P --> POK[? 一般允許]G --> GOK[? 一般允許]F --> FOK[? 一般允許]S --> SOK[? 一般允許；注意云服務條款]C --> CN[?? 宣傳可行；但“商業推廣/打包銷售”可能違規]Z --> ZNO[?? 高風險：有的條款限制對外傳播/商用宣介]POK --- Pnote[勿移除版權；BSD-3/Apache 禁“官方背書”暗示；<br/>商標/Logo 需遵守商標政策]GOK --- Gnote[勿誤導為“官方發行版”；<br/>提供倉庫與源碼獲取路徑]FOK --- Fnote[同上；并注意對修改文件的合規披露]SOK --- Snote[宣傳可行；若提供服務則觸發額外義務]CN --- Cnote[“可宣傳≠可商用/收費”；謹慎用詞避免構成商業化]ZNO --- Znote[閱讀條款；部分協議限制“再分發/衍生”的同時也限制公開傳播場景]classDef ok fill:#E6FFED,stroke:#0A7C2E,color:#0A7C2E;classDef warn fill:#FFF6E6,stroke:#C77C12,color:#C77C12;class POK,GOK,FOK,SOK ok;class CN,ZNO warn;

---

快速參考表

類別	典型協議	再分發+修改	再發布（公開倉庫）	宣傳/推廣	關鍵注意點
寬松	MIT / Apache-2.0 / BSD	?	?	?	保留版權/NOTICE；BSD-3 & Apache 禁官方背書/商標誤用
強傳染	GPLv3 / LGPL	?（需繼續 GPL/LGPL）	?（需繼續 GPL/LGPL）	?	提供源碼/獲取途徑；勿閉源再分發
文件級傳染	MPL-2.0 / EPL-2.0	?（修改過的文件需開源）	?	?	便于與閉源并存；聚焦“被修改文件”
服務側開源	SSPL	?	?	?	若對外提供服務→需開源整套服務端
限制商業	Commons Clause / BSL	??（非商用/延遲開源等）	??	??（宣傳可但慎商用導向）	具體條款優先：常限制盈利/銷售/付費服務
自定義/偽開源	公司定制（含“基于GPL+限制”）	?/??	?/??	??	常見“禁止衍生/再分發/反編譯/商用”

小貼士：改名+改 README+fork+貼鏈接 在主流標準開源協議（MIT/Apache/BSD/GPL/MPL/EPL）中通常合規；務必保留版權、標注修改、不冒充官方。涉及 SSPL/Commons Clause/BSL/定制許可證時，須逐條核對是否限制商業化或再分發。

六、結語

絕大多數主流開源協議（MIT、Apache、BSD、GPL）都 支持自由修改、再發布和傳播，只要遵守版權聲明與協議要求即可。真正需要警惕的，是 帶商業限制的協議 和 公司自定義的“偽開源”協議。

在你 fork、改名、宣傳之前，花 5 分鐘讀 LICENSE 文件，就能避免大麻煩。

---