開源軟體（Open Source Software）是原始碼公開，而且授權條款允許任何人使用、研究、修改與再散布的軟體。判斷標準不是能不能免費下載，而是授權是否符合開放原始碼促進會（OSI）的開放原始碼定義，例如不得限制販售或贈送、必須允許修改與衍生著作、不得限制使用領域。企業採用開源軟體多半不必付授權費，但要自行確認授權條件、追蹤更新與漏洞，並安排由誰負責維護，這些責任不會因為軟體免費而消失。
開源軟體是什麼：開放原始碼定義的十項條件
開源軟體是什麼？OSI 在開放原始碼定義開頭就說明，開源不只是能取得原始碼，授權還要符合十項條件：
- 自由再散布：不得限制任何人販售或贈送軟體。
- 原始碼：必須包含原始碼，並允許以原始碼與編譯後的形式散布。
- 衍生著作：必須允許修改與衍生著作，並允許以相同條款散布。
- 作者原始碼的完整性：必須明確允許散布由修改後原始碼建置的軟體。
- 不得歧視任何個人或團體。
- 不得限制使用領域，例如不能禁止用於商業。
- 權利適用於所有再取得軟體的人。
- 授權不得限定於特定產品。
- 授權不得限制一起散布的其他軟體。
- 授權必須技術中立。
OSI 也說明，經核准的開源授權要通過它的審查程序。看到「開源」字樣時，查一下授權是否在 OSI 的授權清單上，是簡單的確認方式。
開源、自由軟體與免費軟體的差別
| 名稱 | 重點 | 判斷方式 |
|---|---|---|
| 開源軟體 | 授權符合開放原始碼定義的十項條件 | 看授權是否經 OSI 核准 |
| 自由軟體 | 保障執行、研究並修改、再散布、散布修改版四大自由 | 自由軟體基金會強調講的是自由，無關價格，也必須能商業使用與散布 |
| 免費軟體 | 不收費取得 | 是否提供原始碼、能否修改，要看授權條款 |
常見的誤會有兩種。一是把「免費」當成「開源」：免費下載的工具可能不提供原始碼，也不允許修改。二是把「原始碼看得到」當成「開源」：有些軟體公開原始碼，卻限制商業用途或特定使用者，這不符合開放原始碼定義中不得限制使用領域、不得歧視個人或團體的條件。反過來，開源軟體也可以收費，GPL 就明文允許散布時收費或不收費。
常見開源授權類型：寬鬆型與著佐權型
開源授權大致分成兩類：寬鬆型主要要求保留聲明，修改後的程式可以用其他條款散布；著佐權型（copyleft）要求散布修改版時沿用相同授權並提供原始碼。下表依授權原文整理：
| 授權 | 類型 | 主要條件 |
|---|---|---|
| MIT 授權 | 寬鬆型 | 副本或主要部分要保留著作權聲明與授權聲明；按現狀提供，不負擔保 |
| Apache License 第二版 | 寬鬆型 | 附授權副本、修改過的檔案要註記、保留原有聲明與 NOTICE 檔；含專利授權，提告主張該軟體侵害專利時，提告者取得的專利授權即終止；不授予商標使用權 |
| GPL（GNU 通用公共授權條款） | 著佐權 | 散布修改版時，整個作品要以 GPL 授權給取得者；以目的碼形式散布時，要依授權列出的方式提供對應原始碼 |
| LGPL | 較寬鬆的著佐權 | 以 GPL 第三版加上額外許可，結合程式庫的作品可用自選條款散布，但不得限制修改其中的程式庫部分與為除錯所做的反向工程，並要做到授權列出的事項 |
| AGPL | 著佐權 | 在伺服器上執行修改版並讓他人透過網路使用時，要讓使用者能下載對應原始碼 |
| MPL 第二版 | 檔案層級著佐權 | 散布時修改過的 MPL 檔案要維持 MPL 並提供原始碼，可和其他授權的程式碼結合 |
同一個授權常有不同版本，條件也不同，引用時要看清楚版本並以原文為準。
GPL 義務的關鍵：有沒有散布
GPL 第三版把「散布」（convey）定義為讓他人能製作或取得副本的傳播行為，並寫明不散布時，可以製作、執行與傳播受保護的作品而沒有條件限制。因此要分情境判斷：
- 只在公司內部修改使用：沒有散布給他人時，GPL 不要求公開修改後的原始碼。
- 放在網站伺服器上提供服務：只透過網路與使用者互動、沒有傳送副本，GPL 第三版說明不算散布；但 AGPL 要求讓透過網路使用修改版的人能下載原始碼。
- 交付軟體給客戶或放進產品販售：屬於散布，要依授權提供原始碼與授權條款。
委外開發的系統若用了著佐權元件，交付後轉售或提供給第三方時就可能涉及這些義務，開發前請廠商列出元件與授權並寫進交付文件。以上為授權條款的概念整理，個案請以授權原文與專業法律意見為準。
企業採用開源軟體的風險：授權、維護與資安
- 授權合規：漏掉著作權聲明、NOTICE 檔，或把著佐權元件放進對外散布的產品卻沒提供原始碼，都可能違反授權。Apache 授權也不授予商標使用權，產品命名不能直接沿用。
- 沒有擔保：MIT 與 Apache 授權都寫明按現狀提供、不附擔保，出問題時要靠社群、自己的團隊或委外廠商修復。
- 維護中斷：專案可能停止更新，遇到新版作業系統或程式語言時無法相容。
- 資安漏洞：元件公布漏洞後，若沒有人追蹤並更新，網站或系統就持續暴露在風險中。
- 相依套件：一個元件可能再引用許多套件，授權與漏洞要連同這些套件一起看。
開源軟體和雲端訂閱服務的責任分工不同，可參考SaaS 的意思與資料責任。
採用開源軟體前的檢查清單
- 元件與授權清單：列出使用的開源元件、版本與授權，連同相依套件一起整理，每次更新後同步修改。
- 授權與用途是否相容：內部使用、提供網路服務或交付客戶，要對照的條件不同；著佐權元件和自己的程式碼放在一起時，先確認散布方式。
- 專案活躍度：看更新紀錄、問題回報的處理情形，以及是否有公開的安全通報管道。
- 維護責任：誰負責追蹤安全更新、多久更新一次、在哪裡測試；委外維護時，把回應時限與更新範圍寫進SLA 的服務水準指標。
- 退場方式：專案停止維護時，有沒有替代方案或資料匯出途徑。
網站常見的開源軟體與維護分工
企業網站常用的內容管理系統、資料庫與網頁伺服器，有許多是開源軟體。以 WordPress 為例，官方說明它以 GPL 第二版或更新版本釋出，並表示衍生作品的認定有法律灰色地帶，但認為外掛與佈景主題屬於衍生作品、同樣繼承 GPL。網站實際運作時，主程式、佈景主題、外掛與主機環境各有更新節奏，維護上要注意：
- 付費佈景主題或外掛可能有更新與支援期限，到期後能否取得安全更新要先確認。
- 外掛越多，要追蹤的漏洞越多，停止維護的外掛應找替代方案。
- 主程式、外掛與主機的程式語言版本要相容，更新前先在測試環境確認。
WordPress 適合哪些網站需求，可參考WordPress 優缺點與網站需求判斷。
常見問題
開源軟體可以拿來做商業用途嗎？
可以。開放原始碼定義要求授權不得限制使用領域，商業用途也包括在內。但仍要遵守授權條件，例如保留著作權聲明，散布著佐權軟體的修改版時提供原始碼。
開源軟體是不是比較不安全？
不能只用是否開源判斷安全性，重點在有沒有人持續修補與更新。開源專案公布漏洞後，使用者要自己追蹤並更新，選用前先看專案是否活躍、有沒有安全通報管道。
用 GPL 軟體開發的網站要公開原始碼嗎？
依 GPL 第三版，只透過網路提供服務、沒有傳送副本不算散布，但送到訪客瀏覽器執行的 JavaScript 屬於傳送副本，要另外確認其授權條件；若用的是 AGPL 授權的修改版，就要讓網路使用者能取得原始碼。實際情況請以授權原文判斷。
開源軟體需要付費嗎？
授權本身多半不收費，但開源授權也允許販售。企業實際的成本來自導入、客製、主機、維護與資安更新的人力，以及付費外掛或技術支援。
委外開發時要請廠商提供哪些開源資訊？
請廠商列出使用的開源元件、版本與授權，說明哪些是著佐權授權、對交付與散布的影響，並約定由誰負責元件的安全更新，寫進交付文件與維護合約。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
如果網站或系統已經用了開源軟體，先整理目前的元件、版本與授權清單，確認誰在負責安全更新；準備新案時，把開源元件的授權與維護方式列進需求與合約。
京采的網頁設計服務可以協助規劃網站架構與元件選用，整理外掛與套件清單，安排更新前的測試與上線流程，並把維護範圍寫進規劃。想檢查現有網站的元件狀況，歡迎與我們聯繫。
