Skip to main content

常見開源授權條款筆記：GPL、MPL、Apache、MIT、BSD

· 6 min read

整理自 6種常見的開源軟體授權條款解析（GYB／方格子），以開發者視角濃縮「再散布義務」與選授權參考。

開源不是「沒有著作權」，而是作者透過授權條款，事先約定他人能怎麼用、怎麼改、怎麼再散布。實務上常卡在兩個問題：

  1. 我能不能拿別人的碼進商業專案？
  2. 我改完再發布，有沒有義務開源？

下面依「強制回饋」的強度，從強到弱快速對照六種常見類型。

一、光譜先看清楚​

類型代表授權一句話
Copyleft（強）GPL改了再散布，通常得整包繼續用 GPL，並提供原始碼
弱 Copyleft / CopycenterMPL原始碼檔案層級要維持開放；編譯後的執行檔相對寬鬆
寬鬆許可（Permissive）Apache、MIT、BSD可閉源再發布，條件多半是保留著作權與授權聲明
專有（Proprietary）各種 EULA沒有公用授權條款，權利幾乎全在所有人

多數授權不禁止商業使用；卡點通常是「能不能閉源」，不是「能不能賣」。

二、Copyleft：GPL 類（General Public License）​

GPL-3.0 核心精神：

  1. 散布原作與衍生作品時，原則上必須繼續採用 GPL（LGPL 另有例外）
  2. 不禁止商業使用
  3. 修改後須標示／說明修改處
  4. 須保留著作權資訊與 GNU 授權條款
  5. 必須能取得原始碼（不能只給混淆／編譯後產物當「原始碼」）
  6. 有較完整的智慧財產、責任限制與法律衝突相關約定

由 Richard Stallman 一带提倡，Linux 生態常見。特色是「再散布時條款綁死」：多數商業產品會刻意避開把 GPL 程式碼嵌進要閉源的成品，以免整包變難閉源。

但 GPL 本身並不禁止商業——例如 Red Hat Enterprise Linux 仍以授權模式營運，只是下游同樣受 GPL 拘束。

LGPL 的妥協​

LGPL（Lesser GPL） 放寬「一定要整包 GPL」的壓力：

  • 若只以 Dynamic Link（動態連結） 呼叫 LGPL 函式庫，主程式可不必採 LGPL（可閉源）
  • 若 修改 LGPL 原始碼，或 Static Link（靜態連結） 使軟體成為衍生作品，再散布時通常仍須維持 LGPL

FSF（自由軟體基金會）並不特別鼓勵新專案優先選 LGPL；它更像普及函式庫時的務實折衷。

三、弱 Copyleft：MPL 類（Mozilla Public License）​

MPL-2.0 核心精神：

  1. 執行檔／目的碼 可改採其他授權（含閉源），但須說明如何合法取得原始碼
  2. 原始碼 仍須具備，且相關檔案層級維持開放精神
  3. 不禁止商業使用
  4. 須保留著作權資訊，並能取得 MPL 條款（連結或全文）
  5. 智財、責任、管轄、準據法等條文相對完整

最初由 Netscape 起草、Mozilla 基金會維護。相較 GPL「整包都必須 GPL」，MPL 落在中間：

  • 不像 MIT／BSD／Apache 那樣，衍生作品可整包完全私有化
  • 也不像 GPL 要求原始碼與執行檔都全面 copyleft

另：MPL-2.0 與 GPL 類結合時，允許為相容而讓衍生作品轉採 GPL 類授權，增加開源生態互用性。條款裡對專利、商標「不授權」、管轄與免責也寫得較細，被視為法律結構較完整的一類。

四、寬鬆許可：Apache、MIT、BSD​

Apache License（Apache-2.0）​

  1. 不強制一定要散布原始碼；執行檔可用 NOTICE、畫面顯示等方式保留授權與著作權資訊
  2. 衍生作品不一定要繼續用 Apache，但修改處通常須標註
  3. 明確處理著作權、專利授權，並聲明不授商標
  4. 有責任限制條款（免責能否完全抵觸強制法規，仍視各地法院）

概念上較接近著作權法「衍生作品可各自負責」：改良者為自己的改動負責，也可重新決定授權方式；原作者資訊保留在 NOTICE「族譜」裡，避免攀附原品牌。

商業團隊共同開發時，原文作者較推薦這條路線——條款夠完整（含專利），又不會像 GPL／MPL 那樣強綁回饋開源。

MIT License​

  1. 不禁止商業使用
  2. 須保留著作權資訊與 MIT 條款（條款文字本身可依需求調整）
  3. 通常無須標示修改了哪些地方
  4. 未完整規範專利／商標

條款極短、門檻最低。衍生作品能否改授權雖無明文，實務多認為可改，但應移除原 MIT 聲明後再套用自己的條款。適合「想讓別人隨便用、先追求擴散」的專案。

BSD（常見 2-Clause / 3-Clause）​

  1. 不禁止商業使用
  2. 須保留著作人／著作權資訊
  3. 修改通常無須逐段標註
  4. 有責任限制；整體比 MIT 更簡、權利列舉也較少

精神與 MIT 同屬寬鬆許可。選用時留意是 2-Clause 還是 3-Clause（3-Clause 多「不得用作者名稱背書」之類條件）。

五、專有授權（Proprietary）​

軟體所有人握有完整智財權利，沒有「公用條款」可供第三人自由再散布。閉源商業軟體多屬這類；「免費」≠「開源」。

六、怎麼選？快速對照​

你在意的事較常往哪走
希望後人改了還必須回饋社群、保持開放GPL（函式庫動態連結妥協可看 LGPL）
檔案要開源，成品執行檔想較彈性MPL
商業協作、要專利條款、又不想強綁 copyleftApache-2.0
幾乎零摩擦擴散，條款越短越好MIT / BSD
產品要完全閉源、自行控權專有授權（並小心依賴是否踩到 GPL）

原文結語的實務傾向也很清楚：

  • 商業團體共同開發 → 偏 Apache
  • 不在乎別人怎麼用、希望盡量散播 → 偏 MIT / BSD
  • MPL 法律對應較完整，但原始碼仍有弱 copyleft，商業閉源仍可能猶豫

參考來源​

本文為學習筆記整理，非正式法律意見。實際選授權與合規請再對照授權全文，必要時諮詢法務。