開源授權白話指南：寬鬆型與著佐權的差別、商用該注意什麼
你的網站、後台、App 裡面，幾乎一定用到開源套件——框架、函式庫、字體、圖示集、編輯器元件。
多數企業主從來沒想過這件事，直到有人問起：「你們產品裡用了哪些第三方元件？授權都確認過嗎？」這個問題會出現在大型客戶的採購審查、投資人的盡職調查、或是產品要賣進特定產業的時候。這篇用白話說明開源授權在要求什麼、對商業產品可能有什麼影響，以及你在委外與合約上該做的準備。
先說清楚：本文只說明一般性的判斷原則與盤點方法，不構成法律意見。實際個案的授權適用，應該諮詢律師。
開源不等於沒有條件
「開源」指的是著作權人公開原始碼，並以特定授權條款允許他人使用、修改與散布。關鍵在於它仍然是有著作權的作品，你取得的是附條件的授權，不是進入公共領域的免費素材。
常見的條件包括：
- 保留原始的著作權聲明與授權全文
- 在你的產品中標示使用了哪些開源元件
- 若有修改，標示修改的事實
- 在特定情況下，把你的修改以相同條款釋出
這些條件在內部自用時幾乎不會有人察覺，但一旦產品對外販售、或是被納入他人的審查流程，就會被逐項檢視。
兩大類授權的白話差別
授權條款種類很多，實務上先掌握兩種性格就夠用：
| 類型 | 白話理解 | 對你的程式碼 | 常見使用情境 |
|---|---|---|---|
| 寬鬆型 | 拿去用，記得寫我的名字 | 通常沒有額外要求 | 商業產品使用顧慮較低 |
| 著佐權型 | 我開放，用了我的也要跟著開放 | 可能被要求以相同條款釋出 | 需要先確認使用方式 |
寬鬆型的核心要求多半是保留著作權與授權聲明。多數常見的前端框架與工具屬於這一類，商業使用時的主要義務是「別把人家的名字拿掉」。
著佐權型帶有延續的性質：它希望自由被傳遞下去，因此當你以特定方式使用並對外散布時，可能會要求你把相關的程式碼也以相同條款釋出。
這裡有三個常被誤解的地方：
第一，著佐權型不等於不能商用。 這兩類授權大多都允許商業使用，差別在於你的程式碼會不會被牽連。
第二，觸發條件通常與「散布」有關。 純粹在自己的伺服器上跑、不把軟體交付給別人，和把軟體包成產品賣出去，適用的判斷可能不同；也有條款把透過網路提供服務納入考量。這正是需要律師看個案的地方。
第三，「用了」有很多種用法。 把程式碼複製進自己的檔案、以套件形式引用、或只是用它產生的成品（例如用一套工具產出圖檔），性質不一樣。
還有一類常被忽略的素材：字體、圖示集、圖庫、範例版型。它們也有各自的授權條款，而且常見的限制是「可用於個人專案、商業使用需另行購買」。網站上線後才被通知字體授權不足，是真實會發生的事。
對商業產品的實際影響
授權問題很少在開發當下爆出來，通常在這幾個時點被翻出來：
大型客戶或公部門的採購審查：要求廠商提供第三方元件清單與授權說明。
投資人或併購方的盡職調查：技術盡職調查會檢視相依套件的授權相容性。NETVANA 的軟體顧問服務包含架構審查與技術盡職調查，這類清點通常就是其中一項，服務內容可以看軟體服務介紹。
要把產品交付給客戶自行部署時：散布行為一旦發生，某些條款的要求才真正啟動。
廠商更換時：接手的團隊會盤點既有相依套件，這時候如果沒有清單，就得從頭查。
另外要注意的是停止維護的套件。授權合規只是其中一面，另一面是安全性——沒人維護的套件不會再收到修補，這屬於技術債的一種，相關的判斷與處理可以看技術債是什麼與企業網站資安基本功。
相依套件怎麼盤點
現代專案的相依關係是層層堆疊的：你直接引用的套件，又各自帶進更多套件。人工清點不切實際，該做的是建立流程：
一、要求產出清單。請開發方提供完整的相依清單，包含套件名稱、版本、授權條款。多數開發生態系都有工具可以自動產生。
二、把清單納入交付項目。和原始碼、部署文件一起交付，並在每次改版時更新。NETVANA 的作法是專案費用結清後，原始碼、設計檔與文件完整移交，相依清單屬於文件的一部分。
三、建立引入新套件的判斷習慣。加入新套件前，至少確認授權類型、維護是否活躍、以及是否真的需要——為了一個小功能引入一個大套件，同時增加授權面與維護面的負擔。
四、把素材授權一併記錄。字體、圖示、圖庫、版型的授權範圍與購買證明，要和程式套件放在同一份文件裡。
四個常見的誤解
「開源就是沒有作者」。開源軟體有明確的著作權人與授權條款，不是無主物，差別只在作者選擇用什麼條件開放。
「我們沒有改它，所以沒事」。有些條款的義務在散布時就啟動，不以修改為前提；保留著作權聲明、標示使用了哪些元件，通常是最低限度的要求。
「這是廠商用的，跟我們無關」。產品交付之後，對外負責的是你的公司。這也是為什麼相依清單該列在交付項目裡，而不是留在開發方手上。
「授權看過一次就好」。相依套件會隨著版本更新而變動，新增功能時也可能引入新的套件。清單應該在每次改版時重新產出，而不是建置完就封存。
委外時，合約該寫什麼
把授權責任講清楚，是選廠商時該做的功課之一。建議至少涵蓋這幾項：
- 第三方元件清單：列為交付項目，並約定更新機制
- 授權合規的聲明與責任：廠商聲明所交付的成果未侵害第三方權利，並約定發生爭議時的處理方式
- 素材授權的歸屬：字體、圖庫、外掛的授權是買在誰名下，結案後你能不能繼續使用
- 原始碼與著作權歸屬：你擁有的是什麼、可不可以自行修改與交給其他廠商維護
- 客製程式碼與開源元件的界線：哪些部分是為你客製的、哪些是引用的開源元件
這些條款的完整討論，以及評估廠商時該問的其他問題，整理在如何挑選軟體開發公司。合約條款的具體措辭與法律效果，請由律師協助擬定與確認。
選型階段就該考慮授權
授權不只是事後盤點，在選型時就會影響決定。
以內容管理系統為例，不同路線（套裝平台、開源系統、無頭服務、客製後台）在授權性質、外掛生態與可攜性上的差異很大，選型的完整比較可以看CMS 內容管理系統怎麼選。舊系統要不要重寫時，既有相依套件的授權與維護狀態也是判斷依據之一，相關思路在舊系統現代化指南。
一個實用的提問是：如果有一天要換廠商、或要把產品賣給別人，我手上有沒有足夠的文件說明這套系統由什麼組成？ 答不出來，就是該補清單了。
開源讓小團隊也能做出完整的產品，這是它的價值；代價是你要對自己用了什麼有基本的掌握。多數情況下需要做的事並不複雜：有一份清單、清楚自己在用什麼、合約裡把責任寫明白，遇到不確定的個案再請律師確認。
如果你不確定現有系統裡用了哪些第三方元件、或是準備開發新產品想先把這件事理清楚，與 NETVANA 討論你的技術盤點需求。軟體顧問服務包含架構審查與技術盡職調查，採詢問報價制，沒有固定套餐。
延伸閱讀：委外前該問的問題與合約條款，看如何挑選軟體開發公司；套件老舊帶來的風險，看企業網站資安基本功；後台選型與授權性質的關係，看CMS 內容管理系統怎麼選；舊系統該修還是該換，看舊系統現代化指南；維護合約的邊界，看網站維護費用包含什麼；分清授權類型後，原始碼歸屬也該這樣談清楚，可以看原始碼歸屬與專案交接指南。
