在閱讀軟體工程與智慧財產權文件時，經常會同時看到 OSS、OSI 與 OSD 這三個縮寫。簡單來說，Open Source（英文全名 Open Source Software，標準縮寫為 OSS，中文稱「開源軟體」或「開放原始碼軟體」）是指公開原始碼並允許自由使用、修改與再散佈的軟體；而一套軟體能否合法自稱為 OSS，則必須通過「開放原始碼促進會（OSI, Open Source Initiative）」依據「開源軟體定義（OSD, The Open Source Definition）」10 大規範所進行的開源軟體授權審核（註：早期部分中文文章曾將開源軟體誤寫為 OOS，但 OOS 實為 Out of Spec 或 Out of Service 的縮寫）。
然而，「開源」絕不等同於「放棄著作權或無條件免費商用」。不同開源軟體授權條款對商業閉源專案的限制差異極大（例如 MIT 幾乎無限制，而 GPL 具備強制開源的傳染性）。開發者與技術負責人在引入第三方套件前，必須先釐清授權義務，避免引發法律糾紛。若您正在評估作業系統層級的導入，可同步參考：〈開源作業系統選型：開發者必看的硬體相容性與授權合規要點〉。
⚡ 快速跳轉：
| 縮寫與專有名詞 | 英文全名 | 中文名稱 | 在開源生態系中的核心角色與定位 |
|---|---|---|---|
| OSS | Open Source Software | 開源軟體 / 開放原始碼軟體 | 公開原始碼並採用合規開源授權的軟體專案（如 Linux、Node.js、React、MySQL）。切勿與品管超規 OOS 混淆。 |
| OSI | Open Source Initiative | 開放原始碼促進會 | 1998 年創立的國際非營利審核機構，負責維護 OSD 標準並認證全球合法的開源授權條款（OSI-Approved Licenses）。 |
| OSD | The Open Source Definition | 開源軟體定義（10 大規範） | 判定一套軟體授權是否屬於「真正開源」的 10 項憲法級準則（包含允許衍生修改、不得禁止商業用途等）。 |
💡 跨領域同音縮寫補充：
OSS：在雲端與電信領域偶爾指「物件儲存服務（Object Storage Service）」或「營運支援系統（Operations Support Systems）」。OSI：在電腦網路領域指 ISO 制定的「OSI 七層網路模型（Open Systems Interconnection Model，實體層至應用層）」。OSD：在電腦硬體領域指顯示器的「螢幕顯示選單（On-Screen Display，常見問題為長按 Menu 鍵 10 秒即可解除 OSD 鎖定）」，在 Ceph 分散式儲存叢集中則指Object Storage Daemon。
1. Open Source (OSS) 與閉源軟體、免費軟體 (Freeware) 的差異
許多初學者常將「開源軟體（OSS）」與「免費軟體（Freeware）」或「原始碼公開軟體（Source-Available）」混為一談。事實上，免費軟體僅代表「不收費」，使用者通常只能下載編譯後的可執行檔（Binary），無法檢視或修改底層原始碼；而開源軟體的核心在於「原始碼開放、允許二次修改與自由再散佈，且不限制商業使用」。
| 比較維度 | 開源軟體 (Open Source / OSS) | 免費軟體 (Freeware) | 商業閉源軟體 (Proprietary) |
|---|---|---|---|
| 原始碼公開性 | 完整公開，可自由檢視與資安稽核 | 不公開（僅提供編譯後執行檔） | 不公開（屬企業營業秘密） |
| 修改與二次開發 | 允許修改並發布衍生版本 | 禁止反組譯或修改程式碼 | 禁止修改，僅能依 EULA 約定使用 |
| 授權費用 | 軟體本身免授權費（可收技術支援費） | 免費使用（常含內購或功能限制） | 需購買授權金（License）或訂閱 |
| 商業用途限制 | 依 OSD 第 6 條，不得禁止商業使用 | 視授權而定（許多免費軟體禁止商用） | 需購買商業授權版本 |
2. OSI 開放原始碼促進會與 OSD 開源軟體定義 10 大規範
並非只要把程式碼放到 GitHub 公開給大家看，就能自稱為「開源軟體（OSS）」。在國際法務與軟體工程標準中，必須由 OSI（開放原始碼促進會） 依據 OSD（開源軟體定義） 審核通過的授權條款，才具備正式的開源地位。
什麼是 OSI（Open Source Initiative，開放原始碼促進會）？
OSI 是於 1998 年由 Bruce Perens 與 Eric S. Raymond 等開源先驅創立的國際非營利組織。為了讓企業界理解開放原始碼的商業價值並建立一致的法律標準，OSI（開放原始碼促進會） 建立了嚴謹的授權條款審核流程（License Review Process）。只有通過 OSI 認證並列入 OSI 認證開源授權清單 的授權協議（如 MIT、Apache-2.0、GPL-3.0），才能合法稱為開源軟體授權。
什麼是 OSD（The Open Source Definition，開源軟體定義 10 大規範）？
OSD（開源軟體定義） 是 OSI 用來檢驗授權條款是否合規的 10 大黃金準則。任何軟體授權協議只要違反其中一條，就不能稱為 Open Source：
- 自由再散佈（Free Redistribution）：授權條款不得限制任何一方將該軟體作為整合軟體的一部分進行販售或贈與，且不得要求收取權利金或授權費。
- 完整原始碼取得（Source Code）：程式必須包含完整原始碼，並允許以原始碼及編譯後的形式散佈。若產品未隨附原始碼，必須提供無額外費用的公開下載管道，嚴禁故意提供混淆過（Obfuscated）的程式碼。
- 允許衍生著作（Derived Works）：授權條款必須允許修改與建立衍生著作，並允許衍生著作以與原軟體相同的授權條款進行再散佈。
- 原創作者原始碼的完整性（Integrity of The Author's Source Code）：授權條款可要求修改後的衍生版本必須使用「不同的軟體名稱」或「不同的版本號」，以區別於原始軟體，保障原作者聲譽。
- 不得對特定個人或團體有差別待遇（No Discrimination Against Persons or Groups）：不得因國籍、族群、立場或特定群體而限制其使用與貢獻權利。
- 不得限制使用領域（No Discrimination Against Fields of Endeavor）：絕對不能禁止將軟體用於商業用途（Commercial Use）、軍事用途或特定研究領域。凡在授權中寫有「僅供個人學習或非商業使用（Non-commercial use only）」的專案，一律違反 OSD 第 6 條，僅能稱為「原始碼公開軟體（Source-Available）」。
- 散佈授權條款（Distribution of License）：隨附於程式的各項權利必須自動適用於所有取得再散佈版本的人，無須再額外簽署其他保密或許可協議。
- 授權條款不得專屬於特定產品（License Must Not Be Specific to a Product）：程式所附帶的權利不得取決於該程式是否綁定於某特定發行版；若將其單獨抽出散佈，仍享有相同開源權利。
- 授權條款不得限制其他軟體（License Must Not Restrict Other Software）：當開源軟體與其他非開源軟體一起存放在同一儲存媒介散佈時（例如同一映像檔或安裝包），不得強制要求其他無關的獨立軟體也必須開源。
- 授權條款必須技術中立（License Must Be Technology-Neutral）：授權條款不得綁定特定硬體平台或要求必須透過特定網頁介面點擊（Click-Wrap）才生效。
3. 常見 6 大開源軟體授權條款比較（MIT / Apache 2.0 / GPL）
在商業開發中，引入第三方套件最關鍵的考量就是「修改或連結後，是否必須將自己的商業程式碼也一併公開（Copyleft 傳染性）」以及「是否包含明確的專利授權保障」。以下整理業界最常見的 6 種 OSI 認證開源授權對照表：
| 授權條款 (SPDX) | 商業閉源整合 | 修改後開源與專利條款 | 核心義務與特性說明 |
|---|---|---|---|
| MIT | 允許 | 不強制開源（無明文專利條款） | 限制最少，僅需在散佈時保留原始版權聲明與授權文件（如 React、Vue、Vite）。 |
| BSD (2/3-Clause) | 允許 | 不強制開源（無明文專利條款） | 與 MIT 類似；3-Clause 額外規定未經許可不得使用原作者或機構名稱進行商業背書促銷。 |
| Apache-2.0 | 允許 | 不強制開源（含明確專利授權） | 除保留版權聲明外，修改過的檔案需標註變更說明，並提供明確專利授權與專利反制保障（如 Kubernetes、TypeScript）。 |
| MPL-2.0 | 允許（檔案級隔離） | 僅修改之原檔案需開源（含專利授權） | 檔案級弱傳染（File-level Copyleft）：新增的獨立檔案可維持閉源，僅修改到的 MPL 檔案需公開原始碼。 |
| LGPL-3.0 | 允許（限動態連結） | 靜態連結或改庫需開源（含專利授權） | 函式庫弱傳染：商業軟體若以「動態連結（Dynamic Linking）」呼叫 LGPL 函式庫可維持閉源；若修改該庫或靜態編譯連結則需開源。 |
| GPL-3.0 / AGPL-3.0 | 不可閉源整合 | 強制開源（強傳染性，含專利授權） | 強傳染性（Strong Copyleft）：只要程式碼連結或衍生自 GPL 元件並對外散佈，整個專案必須以 GPL 開源；AGPL-3.0 更規定透過網路提供 SaaS 服務亦視為散佈。 |
4. 專案如何正確標示 SPDX 授權與自動掃描第三方套件？
無論您是打算將自己開發的專案開源，還是在公司專案中稽核第三方套件的授權風險，都可以遵循國際標準的 SPDX（Software Package Data Exchange） 識別碼與套件管理工具來處理。
1. 在專案中設定標準 SPDX 授權與 LICENSE 檔案
若要將專案開源，除了在專案根目錄建立 LICENSE 檔案放入完整授權條文外，也應在設定檔（如 Node.js 的 package.json 或 PHP 的 composer.json）中使用標準 SPDX License List 識別碼 明確宣告：
{
"name": "my-open-source-library",
"version": "1.0.0",
"description": "使用標準 SPDX 識別碼宣告開源授權",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/example/my-open-source-library.git"
}
}若屬於公司內部私有閉源專案，切勿隨意填寫 MIT，應在 package.json 中明確設定為 "license": "UNLICENSED" 與 "private": true，防止誤發布至公開套件庫。
2. 自動化掃描專案依賴套件的授權條款
在商業產品進入測試與部署階段（如規劃 SIT 與 UAT 測試流程 或準備上線至 Production 正式環境）前，工程團隊可透過指令工具自動盤點 node_modules 中的所有套件授權，建立軟體物料清單（SBOM）並攔截高風險的 GPL/AGPL 套件：
# 統計目前 Node.js 專案中所有第三方套件的授權類型分布
npx license-checker --summary
# 僅檢查生產環境依賴 (production)，若發現 GPL 或 AGPL 套件則直接報錯阻斷 CI/CD
npx license-checker --production --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"
# 匯出完整的軟體物料授權清單 CSV 供法務與技術團隊審核
npx license-checker --production --csv --out sbom-licenses.csv5. 商業專案選型的法律衝擊與架構隔離避險實務
在評估是否導入特定開源軟體時，技術團隊常因專注於功能與效能而忽略了授權條款帶來的長期法律債務（如同品管監控若忽略 OOC 統計失控預警，最終將演變為嚴重的 OOS 超規事故）。建議在選型階段落實以下三項合規防線：
1. 授權條款的法律衝擊三級分類
- 低風險（寬鬆型 Permissive）：如
MIT、BSD、Apache-2.0、ISC。允許將程式碼直接整合並編譯至閉源商業軟體中，僅需在說明文件或關於頁面保留原始著作權聲明（Attribution），商業應用最安全。 - 中風險（弱傳染型 Weak Copyleft）：如
LGPL、MPL-2.0、EPL。通常針對「檔案層級」或「動態連結函式庫」設有豁免邊界，只要不直接修改該開源元件內部程式碼並維持動態呼叫，主程式即可保持閉源。 - 高風險（強傳染型 Strong Copyleft 與雲端限制條款）：如
GPL-2.0、GPL-3.0、AGPL-3.0。具有強烈的「傳染性」，一旦商業軟體與其進行靜態連結或程式碼整合，散佈時就必須公開整個衍生產品的原始碼。若產品為雲端 SaaS 服務，更必須嚴防 AGPL（將網路互動視為散佈）以及近年部分資料庫改採的非開源限制條款（如 SSPL、BSL，此類條款因違反 OSD 第 6 條或第 9 條，未獲 OSI 認證）。
2. 專案選型排查檢核表
| 檢查維度 | 關鍵排查項目 | 法律風險指標 |
|---|---|---|
| 授權識別 | 檢查套件根目錄 LICENSE 與 package.json | 確認是否為 OSI 認證授權，或屬無授權（No License 預設受著作權全保護，不可隨意商用） |
| 整合方式 | 評估是靜態編譯連結、動態連結或獨立程序呼叫 | 程式碼耦合度越高，觸發 Copyleft 傳染的風險越高 |
| 商業模式 | 確認產品為本地端軟體交付、嵌入式硬體或雲端 SaaS | 實體硬體與桌面軟體交付需防範 GPL；雲端 SaaS 需防範 AGPL 與 SSPL |
| 供應鏈依賴 | 透過 license-checker 檢查間接依賴（Transitive Dependencies） | 即使主套件為 MIT，其底層依賴若含 GPL 仍會造成間接傳染 |
3. 實務避險與架構隔離建議
- 程序與微服務隔離（Process / Microservice Isolation）：若商業專案必須使用 GPL 工具（如特定影音轉檔引擎），切勿將其作為函式庫直接
import編譯進主程式。應將其部署為獨立的命令列執行程序（透過 CLI / 標準輸出入互動）或封裝為獨立微服務，透過標準網路協定與 RESTful API 介面 進行跨程序通訊，藉此在法律與架構上劃清「獨立著作」與「衍生著作」的邊界。 - 採購商業雙重授權（Dual Licensing）：許多採用 GPL/AGPL 的知名軟體廠商（如 MySQL、Qt、iText）皆有提供「商業授權版本」，企業可透過付費購買商業授權來豁免開源義務。
參考資料與延伸閱讀
- 維基百科：The Open Source Definition (OSD) 開源軟體十項定義規範
- 維基百科：Open Source Initiative (OSI) 開放原始碼促進會組織與審核機制
- 維基百科：Open-source license 開源軟體授權分類與比較
- SPDX Workgroup：SPDX License List 標準開源授權識別碼清單
- 經濟部產業發展署：自由軟體授權條款與法律合規指引
- 延伸閱讀：OOS 意思是什麼？科技業品管 Out of Spec、電商 Out of Stock 與系統 Out of Service 解析
- 延伸閱讀：OOC 意思是什麼？半導體 SPC 統計製程管制 Out of Control 與 OOS 差異解析
- 延伸閱讀：開源作業系統選型：開發者必看的硬體相容性與授權合規要點
發表迴響