AI 的開源授權：為什麼商用會踩雷
GNU General Public License（GPL）系列是最經典的 copyleft 授權，要求「衍生作品」在散布時必須以相同授權開源。對 AI 專案而言，風險主要有兩個層面。
第一是推論框架的傳染性。如果團隊使用了 GPL 授權的推論工具，並將其與自家專有程式碼連結（linking），就可能被認定為衍生作品，導致整個產品被迫開源。雖然「連結」的認定在實務上有爭議，但風險不容小覷。這也是為什麼多數商業 AI 團隊會刻意避開 GPL 授權的函式庫，轉而選用 Apache 2.0 或 MIT 授權的替代品。
第二是 AGPL（Affero GPL）的網路條款。AGPL 被稱為「SaaS 條款」，因為它把 GPL 的觸發條件從「散布」擴大到「透過網路提供服務」。換句話說，即使你沒有散布軟體，只要讓使用者透過網路使用你的服務，就必須向使用者提供完整原始碼。對於把模型包成 API 販售的團隊而言，這幾乎是致命條款。曾有團隊把 AGPL 授權的向量資料庫直接部署在雲端服務中，直到準備募資時才被盡職調查（DD）揪出來，最後只能緊急重寫架構。
實務建議是：建立一份「授權白名單與黑名單」，把 AGPL、SSPL 這類高風險授權列為黑名單，任何依賴套件在引入前都必須經過自動化掃描（例如使用 FOSSA、Snyk、Black Duck 等工具），並在 CI/CD 流程中設下阻擋規則。
Apache 2.0 的專利條款與商標限制
Apache 2.0 是商業友善的 permissive 授權，允許自由使用、修改、散布，甚至閉源商用。它之所以受歡迎，是因為它附帶了明確的專利授權條款：貢獻者授權使用者使用其專利，但若使用者對貢獻者提起專利訴訟，授權就會自動終止。這對 AI 領域特別重要，因為模型與演算法經常牽涉專利。
不過，Apache 2.0 也有兩個常被忽略的限制。第一是商標授權並未被包含在內。條款第 6 條明文規定，本授權不授予商標使用權。這意味著你可以在產品中標示「基於 Apache 2.0 授權的 XYZ 模型」，但不能使用原專案的名稱或 Logo 做為行銷素材，否則可能構成商標侵權。
第二是「NOTICE」檔案的要求。若原始專案附有 NOTICE 檔案，散布時必須保留該檔案內容。許多團隊在打包產品時會把它壓縮或忽略，這在嚴格解釋下可能構成違約。雖然實務上很少因此被起訴，但在跨國交易或大型企業採購的合約審查中，這類細節經常被拿出來放大檢視。
MIT 與 BSD：看似無害，仍藏細節
MIT 與 BSD 是限制最少的授權，幾乎可以自由使用、修改、商用、閉源，唯一的要求是保留著作權聲明與免責條款。對 AI 專案而言，這類授權通常出現在小型工具、資料處理腳本或推論函式庫中。
但「無害」只是表象。首先，MIT 授權不包含專利授權，若你使用的函式庫涉及他人專利，MIT 並不能幫你擋子彈。其次，若模型本身是基於 MIT 授權的程式碼訓練而成，並不代表模型權重也自動套用 MIT——因為權重與程式碼是不同標的。這種「授權錯位」在組合式 AI 產品中極為常見，也是最容易被忽略的風險點。
此外，許多團隊會把多個 MIT 授權的元件整合後，只保留一份統一的授權聲明。嚴格來說，每個元件都應保留各自的著作權聲明，尤其是當這些元件來自不同貢獻者時。雖然實務上很少因此引發訴訟，但在大型企業的開源合規審查（Open Source Compliance Review）中，這會被視為不專業的表現。
客製化模型授權：Llama、OpenRAIL 與 RAIL 的實務差異
真正讓商用團隊踩雷的，往往是這些「非標準」的模型授權。以下用三個代表性案例說明。
Meta Llama 系列採用的是「Llama 社群授權」，本質上不是開源授權，而是帶有條件限制的商業授權。條款中明文規定，若產品或服務的月活躍使用者超過 7 億人，必須另外向 Meta 申請商業授權。此外，還禁止使用該模型來訓練其他「競爭性」的大型語言模型，並要求衍生模型名稱必須加上「Llama」字樣，且必須在顯著位置標示「Built with Llama」。這些條件在商用情境中經常被忽略，尤其是新創團隊，往往以為「免費下載就能免費商用」，直到產品規模做大、被 Meta 的法務盯上才驚覺代誌大條。
BigScience BLOOM採用的是 BigScience RAIL 授權，這是「Responsible AI License」的一種。它允許商用，但附帶一系列使用限制，例如不得用於歧視、監控、散播假訊息等用途。違反這些限制時，授權會自動終止。問題在於「歧視」「假訊息」的定義相當模糊，實務上難以界定。若你的產品是開放式聊天機器人，使用者可能用它生成帶有偏見的內容，這時責任歸屬就會變得棘手。
Stable Diffusion 早期採用 CreativeML Open RAIL-M 授權，同樣允許商用，但要求衍生模型必須採用相同授權，並禁止特定用途。這對想要閉源微調模型、當成商業機密的團隊來說，是相當大的限制。後來 Stability AI 雖有調整部分條款，但整體邏輯仍是「開放但不完全自由」。
這三類授權的共同點是：它們都不是 OSI 認證的開源授權，而是釋出者自訂的合約。因此，把它們當成「開源」來看待，本身就是一種認知錯誤。團隊在引入這類模型前，必須逐條閱讀授權條款，並請法務確認商用情境是否落在允許範圍內。
三、商用踩雷的五大真實場景
授權條文讀起來枯燥，但當它變成訴訟或盡職調查清單上的項目時，殺傷力十足。以下整理五個實務上最常見的踩雷場景，並說明其成因與後果。
場景一：把 AGPL 模型或工具部署成 API 服務
這是最經典、也最致命的錯誤。某新創團隊使用 AGPL 授權的向量資料庫作為 RAG 系統的後端，並將其包裝成 SaaS 產品對外銷售。由於 AGPL 的網路條款規定「透過網路提供服務即觸發開源義務」，該團隊理論上必須向所有使用者提供完整的原始碼，包括自家撰寫的商業邏輯。結果在 A 輪募資的盡職調查中，投資人發現這個問題，要求團隊在交割前完成架構重寫，否則交易破局。
這類風險的可怕之處在於它不會立刻爆發。AGPL 的授權人通常不會主動巡查，但一旦團隊規模變大、被競爭對手或授權倡議組織盯上，或是進入併購流程，問題就會浮上檯面。屆時要嘛開源、要嘛重寫、要嘛支付和解金，三條路都很痛。
場景二：忽略使用人數或營收門檻
許多模型授權會設定「商用門檻」，例如 Llama 的 7 億月活躍使用者上限、某些授權要求年營收超過一定金額須另行付費。這類條款的陷阱在於「計算方式」：月活躍使用者怎麼定義？是產品整體還是單一功能？營收是集團合併計算還是單一法人？
曾有一家 B2B SaaS 公司使用某開源模型，認為自己只有數百個企業客戶、使用者不到十萬人，應該安全過關。但授權條款計算的是「終端使用者」，而該公司的客戶多半是大型企業，其內部員工加總起來超過千萬人。結果在與跨國企業簽約時，對方要求提供授權合規證明，才發現早已超過門檻卻未申請商業授權。雖然最終以補授權方式解決，但過程中付出的談判成本與商業信譽損失，遠超過授權費本身。
場景三：訓練資料夾帶的著作權與個資問題
模型權重的授權是一回事，訓練資料的合法性又是另一回事。許多團隊以為「只要模型授權允許商用，輸出就能商用」，這是嚴重的誤解。
假設你使用一個 MIT 授權的模型，但它是在包含大量盜版書籍、新聞文章、個資的資料集上訓練而成。那麼模型輸出是否構成「衍生作品」，就會牽涉原始著作權人的權利。目前各國法院對此尚無一致見解，但已有幾起代表性訴訟，例如美國的《紐約時報》控告 OpenAI 案、Getty Images 控告 Stability AI 案，都在處理這個問題。
對商用團隊而言，實務上的自保方式是：要求模型供應商提供訓練資料的來源說明與授權證明，並在合約中加入「智慧財產權保證條款」（IP Indemnification），約定若因訓練資料侵權導致訴訟，由供應商負責賠償。若供應商無法提供這類保證，則應評估改用資料來源較透明的模型，或自行以合法資料重新訓練。
場景四：輸出內容的責任與免責條款
多數開源授權都包含「免責條款」（Disclaimer of Warranty），聲明軟體或模型「按現狀提供」，不保證適用性與正確性。這意味著若模型輸出錯誤資訊、造成使用者損失，授權人通常不負賠償責任。
但免責條款保護的是授權人，不是商用團隊。若你的產品使用開源模型生成內容，並以此向客戶收費，那麼對客戶的責任仍由你承擔。例如醫療、金融、法律領域的 AI 應用，若模型給出錯誤建議導致損害，客戶可能依消費者保護法或契約法向你求償。這時授權條款裡的免責聲明幫不上忙，反而可能因為你「未盡告知義務」而加重責任。
更棘手的是使用政策（AUP）的連帶責任。部分模型授權規定，若使用者違反使用政策（例如生成仇恨言論、兒少不當內容），授權人可終止授權。若你的產品是開放式平台，無法完全控制使用者行為，就可能因為少數使用者的濫用行為，導致整個服務的授權被撤銷。這種「連坐條款」在實務上雖少見啟動，但一旦發生，影響層面極大。
場景五：授權變更與回溯風險
開源專案的授權並非一成不變。歷史上已有多次知名案例：某專案從 Apache 2.0 改為 SSPL、某資料庫從 BSD 改為 AGPL，每次變更都在社群掀起波瀾。對商用團隊而言，這意味著「今天合規，不代表明天合規」。
AI 領域的授權變更更為頻繁，因為模型釋出者經常在商業壓力下調整條款。例如某模型原本允許自由商用，後來新增「不得用於軍事用途」或「不得用於訓練競爭模型」的限制，且條款變更可能溯及既往地適用於新版本。若團隊沒有建立版本控管機制，持續自動更新依賴套件，就可能在不自知的情況下引入新限制。
實務建議是：鎖定特定版本，並在升級前進行授權差異比對。同時，在合約中要求供應商承諾「授權不會在合約期間內變更為更嚴格條款」，或至少提供變更通知期。對於關鍵基礎設施，則應評估 fork 一份程式碼自行維護，以降低上游變更帶來的衝擊。
四、建立企業的 AI 開源合規流程
看完上述風險，讀者可能會覺得「那乾脆全部自己寫」。但在 AI 時代，完全不使用開源資源幾乎不可能，也不經濟。務實的做法是建立一套可持續的合規流程，讓風險被辨識、被量化、被管理，而不是被忽略。
授權盤點清單：從模型卡到 SBOM
第一步是盤點。團隊應針對每一個引入的 AI 元件，建立一份「授權檔案」，內容至少包含：
元件名稱與版本
授權類型（MIT、Apache 2.0、GPL、AGPL、客製化授權等）
授權原文連結與快照（避免日後變更）
使用方式（連結、修改、散布、SaaS 提供）
是否涉及專利、商標、使用政策限制
訓練資料來源與授權狀態（若為模型）
商用條件（人數門檻、營收門檻、標示要求）
對模型而言，這份清單可以從「模型卡」（Model Card）與「授權檔案」中擷取；對軟體依賴而言，則應建立軟體物料清單（SBOM），並整合到 CI/CD 流程中，每次建置都自動掃描授權變更。如此一來，授權風險就能像資安漏洞一樣被持續監控，而不是等到出事才亡羊補牢。
法律與工程團隊的協作機制
合規不是法務一個部門的事。工程團隊負責技術盤點與依賴管理，法務團隊負責條文解釋與風險評估，產品團隊則負責確認使用情境是否落在授權範圍內。三者之間需要有明確的協作機制。
建議做法包括：
替代方案與商業授權談判
當某個關鍵元件授權風險過高時，團隊應評估替代方案。選項包括：
自行 fork 並維護：適用於程式碼類元件，但需評估維護成本。
重新訓練模型：適用於資料授權有疑慮的情況，但成本最高。
商業授權談判時，應特別注意以下條款：授權範圍（可使用於哪些產品）、使用人數或營收上限、是否允許修改與再散布、輸出內容的權利歸屬、侵權賠償責任、授權期間與終止條件、以及未來授權變更的處理方式。這些條款往往比價格更重要，因為它們決定了產品能否規模化。
五、結語：開源是加速器，不是免責金牌
AI 的開源生態為產業帶來了前所未有的創新速度，這是好事。但「開源」二字在 AI 領域的意涵遠比傳統軟體複雜，它同時牽涉程式碼、權重、資料與使用政策四個層面。任何一層的誤解，都可能讓一個看似順利的商業模式瞬間崩盤。
對企業而言，真正的競爭力不在於「有沒有用開源」，而在於「能不能用得有紀律」。建立授權盤點機制、培養跨部門的合規意識、在產品設計初期就把授權風險納入考量，這些看似繁瑣的動作，其實是在為企業的長期發展買保險。畢竟，當公司規模變大、準備進入資本市場或跨國併購時，一份乾淨的授權履歷，往往比任何技術亮點都更能說服投資人與合作夥伴。
開源是加速器，不是免責金牌。懂得踩煞車的團隊，才能把這台加速器開得又穩又遠。
最後提醒：本文僅就實務常見情境進行說明，不構成法律意見。個別授權條款的解釋與適用，仍應諮詢專業律師，並依實際使用情境進行評估。