一分鐘理解 GNU LGPL：函式庫專用授權，動態連結與靜態連結怎麼算？

GNU Lesser General Public License（LGPL，GNU 較寬鬆通用公共授權條款）是自由軟體基金會為函式庫設計的授權。它保留了 GPL 對函式庫本身的 Copyleft 要求，但允許閉源程式透過連結的方式使用這個函式庫，因此被廣泛用於系統函式庫與 GUI 框架。

LGPL 一句話重點

修改 LGPL 函式庫本身要開源；只是「呼叫」這個函式庫的應用程式，可以維持閉源。

使用 LGPL 函式庫時的義務

• 函式庫的修改要開源：改了 LGPL 函式庫本身，散布時要以 LGPL 提供修改後的原始碼
• 讓使用者可以替換函式庫：使用者必須能把程式中的 LGPL 函式庫換成自己修改的版本
• 保留授權聲明：散布時須附上 LGPL 授權文字與版權資訊
• 不得禁止逆向工程：為了除錯這些修改，授權條款不能禁止使用者進行逆向工程

動態連結與靜態連結的差別

連結方式	閉源程式可以嗎？	要注意什麼
動態連結（.so / .dll）	可以	最常見也最省事的做法，使用者可以直接替換函式庫檔案
靜態連結	可以，但較麻煩	須提供目的檔（object files）等材料，讓使用者能與修改後的函式庫重新連結

實務上，閉源商業軟體使用 LGPL 函式庫時，大多選擇動態連結來降低授權風險。

LGPL 與 GPL 怎麼選？

FSF 官方的建議是：如果你的函式庫提供的是獨特功能，用 GPL 可以讓自由軟體保有優勢；如果市面上已有同類的閉源替代品，用 LGPL 讓更多人採用反而更有利於自由軟體的推廣。

採用 LGPL 的知名專案

• GNU C Library（glibc）
• GTK
• Qt（提供 LGPLv3 與商業授權雙授權）
• FFmpeg（預設 LGPL，啟用部分元件後為 GPL）

GPL、LGPL、MPL、MIT 比較

授權	Copyleft 強度	修改後要開源的範圍	可否與閉源程式結合	代表專案
GPL	強	整個衍生作品	不行（散布時整體須採 GPL）	Linux 核心、Git、WordPress
LGPL	弱（函式庫層級）	函式庫本身	可以，透過連結使用	glibc、GTK、Qt（LGPLv3 選項）
MPL 2.0	弱（檔案層級）	被修改的 MPL 檔案	可以，以檔案為界	Firefox、Thunderbird、LibreOffice
MIT	無（寬鬆授權）	不需開源，保留版權聲明即可	可以	React、jQuery、Node.js

延伸閱讀

• 一分鐘理解 GPL：授權義務、常見誤解與 GPLv2 / GPLv3 差異
• 一分鐘理解 MPL 2.0：檔案層級的 Copyleft

本文僅為授權概念的入門整理，不構成法律意見。實際條款請以官方英文版全文為準，商業產品涉及授權問題建議諮詢專業法律人士。