「我們花了 220 萬做的系統上線兩年，現在原廠抓著 source code 不放，要換廠商每個月還要付授權費。當初合約沒寫清楚，律師說我們只有『利用權』。」
這是一位做傳產 ERP 系統的老闆親口跟我們說的話。他簽合約時看了首付、看了交期、看了功能清單——但沒看到一條叫做「著作財產權歸屬」的條款。兩年後想換廠商，才發現自己花的錢買到的是「使用」這套系統的權利，不是「擁有」這套系統。
這種狀況非常普遍。經濟部智慧財產局針對著作權法第 12 條的解釋寫得很清楚：出資聘請他人完成的著作，如果合約沒有特別約定，著作財產權歸受聘人（也就是廠商）所有，出資人（你）只能「利用」這套系統，不能轉讓、不能授權、不能改別家廠商。台灣絕大多數的軟體外包合約都沒寫清楚這一條，於是出錢的人變成最沒權利的那個。
這篇文章寫給找外包做軟體、做 APP、做網站的老闆——你不需要懂法律技術用語，但你需要在簽約前知道哪幾條一定要塞進去、不能讓廠商含糊帶過。後面會拆解著作權法的實際規範、整理合約必備條款表、提供合約檢查 SOP，並且講幾個合成案例讓你看看真實情境怎麼出包。
如果你正在規劃做產品，可以先看 從 0 到上線打造會賺錢軟體產品的完整路線圖，那篇是全景；這篇專門深入處理合約裡的法律地雷。
為什麼合約沒寫清楚，程式碼預設不是你的
台灣的軟體外包糾紛幾乎都繞著同一條法律打轉——著作權法第 12 條。這條規定看似中性，但實務上對「出資的老闆」非常不利，因為法律的預設值是站在「實際寫程式的人」那邊。
根據全國法規資料庫的著作權法第 12 條原文，出資聘請他人完成的著作，以「受聘人」（也就是接案的開發者或廠商）為著作人；著作財產權（指可以授權、轉讓、收授權金的權利）若未在合約中約定，歸受聘人享有。出資人只取得「利用權」——可以使用這套軟體，但不能再授權給第三方、不能轉讓、也不能要求廠商交付完整 source code。
這代表什麼？合約沒寫，廠商法律上是程式碼的所有人，你只是付錢的「使用者」。要換廠商？沒有 source code、沒有改作權，新廠商根本接不了。要把系統賣掉或授權給子公司？對不起，你沒有授權的權利。
三個你必須記住的法律事實：
- 「著作人」≠「著作財產權人」：著作人是創作者，享有著作人格權（永久不可轉讓的姓名表示權等）；著作財產權則是可以買賣、授權、改作的經濟權利。合約最常吵的是後者。
- 「出資人利用權」非常窄：依著作權筆記蕭雄淋律師對第 12 條的詳解，出資人只能在合理範圍內使用該著作，不能授權第三方、不能修改、不能轉讓。實務上也不能要求交付原始碼。
- 法人受聘的情況更複雜：如果你委託的是一家軟體公司（不是個人 SOHO），公司的員工才是實際著作人，公司必須先跟員工約定職務著作歸屬於公司，再把著作財產權讓與給你——這條鏈斷在哪一段，你都拿不到。
🚨合約沒寫的真實後果
出資人只取得「利用權」，沒有授權、轉讓、改作的權利。換廠商時新廠商不能合法修改舊程式碼；想把系統賣給集團其他公司不能合法授權；廠商倒閉或拒絕配合，你連程式碼都拿不到。
著作權歸屬決定流程：從合約一路看到實際情境
光看法條會迷路，用流程圖來看一次合約落入哪個結局。下面這張圖把「出資聘人完成軟體」的實際歸屬路徑攤開——你會發現只有「合約明確約定 + 廠商與員工的職務著作鏈完整」這條路，老闆才真正擁有 source code。其他每一條岔路都會把你導向「只剩利用權」的結局。
這張圖最常被忽略的是右下角那條 G→I 的線。很多老闆以為合約寫了「著作財產權歸出資人」就萬事 OK，但如果接案的是一家公司、而那家公司沒有跟員工簽職務著作約定，員工才是法律上的著作人，公司根本沒有完整權利可以讓與給你。等於你跟一個沒有產權的人買房子。
合約必備的 9 條著作權保護條款
實務上一份能保護出資人的軟體外包合約，最少要塞下面這 9 條。這份清單是恆遠數位行銷有限公司過去四年協助客戶審閱合約、處理糾紛累積出來的——每一條都對應一個曾經有人踩過的雷。
先看完整對照表，後面會逐條解釋為什麼這樣寫。
# | 條款名稱 | 關鍵約定內容 | 沒寫的後果 |
|---|---|---|---|
1 | 著作人約定 | 明定出資人為著作人（或廠商為著作人但讓與全部財產權） | 廠商保有著作人格權，得主張姓名表示權影響商業使用 |
2 | 著作財產權讓與 | 廠商於驗收完成並收到尾款後，將著作財產權「全部、永久、不可撤回」讓與出資人 | 出資人僅有利用權，不能授權他人、不能換廠商修改 |
3 | Source code 交付 | 驗收後 7 日內交付完整原始碼、設定檔、資料庫 schema、部署腳本，並保證可獨立編譯運作 | 沒有 source code，等於沒有真正擁有系統 |
4 | 第三方權利擔保 | 廠商擔保所交付程式碼未侵害任何第三人著作權、專利、營業秘密 | 廠商盜用他人程式碼，被告的是出資人 |
5 | 開源授權清單 | 廠商提供使用之開源軟體完整清單（名稱、版本、授權條款），並擔保符合該授權使用條件 | 誤用 GPL 授權程式碼可能被迫公開全部商業程式碼 |
6 | 背景智慧財產 | 區分廠商既有元件（pre-existing IP）與本案新作，既有元件須提供永久、不可撤回、可再授權之使用權 | 廠商日後拒絕授權既有元件，整個系統無法繼續使用 |
7 | 競業與保密 | 廠商不得將為本案開發的核心邏輯、特殊演算法用於競爭對手；保密期至少 5 年 | 你花錢開發的功能變成廠商的範本賣給同業 |
8 | 源碼託管（Escrow） | 由第三方機構保管最新版 source code，廠商倒閉、拒絕配合時自動釋出 | 廠商斷聯或惡意關門，系統變孤兒 |
9 | AI 輔助揭露 | 廠商揭露使用之 AI 編程工具（Copilot、Claude Code 等）並擔保產出符合著作權保護要件 | AI 生成程式碼著作權狀態不明，可能不受保護 |
第 1、2、3 條是「鐵三角」，少一條都不算完整保護。著作人約定處理人格權、財產權讓與處理經濟權利、source code 交付處理實體控制權——三者缺一不可。
⚠️「驗收後讓與」比「合約簽訂時讓與」更安全
建議第 2 條的讓與時點綁在驗收完成 + 尾款付清。理由：保護廠商的同時也保護你——廠商有動力做完整交付才能收尾款，你也有最後一筆錢做槓桿確保 source code 真的拿到手。可以參考 MVP 分階段付款驗收指南 把驗收節點和著作權讓與綁在一起。
廠商最常用的 6 個合約話術，以及怎麼破解
十份外包合約裡有八份不會明目張膽寫「著作權歸廠商」——那太刺眼。真正常見的是用「使用權」「永久授權」「不限次數使用」這種看起來很大方、實際上限制很嚴格的詞彙包裝。下面整理六個最常見的話術陷阱。
廠商說法（看似對你有利） | 實際法律意義 | 你應該堅持改成 |
|---|---|---|
「本系統永久授權給甲方使用」 | 廠商保留著作財產權，你只是長期租戶。不能換廠商、不能改作 | 「廠商將著作財產權全部、永久、不可撤回讓與甲方」 |
「驗收後甲方擁有所有權」 | 「所有權」在著作權法沒有對應概念，是廢字。法庭上仍會落入第 12 條預設 | 明確寫「著作人格權與著作財產權之歸屬」 |
「source code 屬於甲方，但乙方保留二次開發權」 | 廠商可拿你的程式碼改一改賣給競爭對手 | 加上「乙方不得將本案核心功能、商業邏輯用於與甲方相同產業之客戶」 |
「依本契約完成之軟體著作權歸甲方所有」（單句帶過） | 沒處理員工職務著作鏈，公司可能根本沒有權利可以讓與 | 加擔保條款「乙方擔保已就所有參與本案之員工取得完整職務著作財產權」 |
「乙方不得另作他用」 | 沒有期限、沒有定義「他用」是什麼，幾乎不可執行 | 具體寫保密期限、競業範圍、違反時的違約金額 |
「source code 將於專案結束後妥善保管」 | 「妥善保管」沒有定義，廠商可以說放在他們公司就是妥善保管 | 明定「驗收後 7 日內交付 source code 至甲方指定儲存位置（GitHub / GitLab repo）」 |
最毒的是第二條——「所有權」這個詞在台灣著作權法裡根本沒有定義。著作權法只有「著作人格權」和「著作財產權」兩種權利型態，廠商寫「所有權」是模糊化的話術，真上法庭時這個詞不會起任何保護作用。
關於合約陷阱的完整避雷清單，可以延伸閱讀 找外包做 APP / 軟體前必踩的 9 個雷，那篇是更廣的外包風險地圖；本篇專注在著作權與程式碼歸屬。
三個合成案例：看別人怎麼踩雷
以下三個案例是恆遠數位行銷實際處理過的糾紛，已經抹除身分資訊並合併部分情節。看看別人怎麼出包，比看法條有感得多。
案例 A：科技業老闆，220 萬 ERP 系統的人質危機
L 老闆在 2022 年找了一家中型軟體公司開發內部 ERP，合約寫的是「驗收後乙方授權甲方永久使用本系統」。第一年沒事，第二年公司業績成長想加新模組，原廠商開價 80 萬一個模組——市場行情約 30-40 萬。L 老闆想換廠商，新廠商一看到合約就退案：「沒有著作財產權讓與條款，我們改你的程式碼就是侵權，幫你做新模組要拿你的舊系統當基礎更不可能。」
結局：L 老闆額外付了 60 萬律師費和重新議約金額才取回部分權利，整個拖了 9 個月。後來他自己估算，這個合約的隱性成本超過 400 萬。
教訓：「永久使用」不等於「擁有」。合約裡每一個關鍵字都要對應到著作權法的具體權利。
案例 B：餐飲集團，廠商倒閉後的孤兒系統
M 集團 2023 年委託小工作室做了一套點餐 + 排班整合系統，合約裡 source code 那條只寫「乙方應妥善保管原始碼」。2024 年底工作室解散，主程式設計師失聯，M 集團手上只有編譯後的執行檔。系統開始出 bug 時找不到人改、要加新功能也沒有原始碼可以接力。最後集團花了 180 萬重新開發。
如果當初有寫源碼託管條款（合約必備條款第 8 條），託管機構在廠商解散時就會自動釋出 source code 給 M 集團，省下 180 萬重做的錢。
案例 C：傳產老闆，員工職務著作鏈的隱形地雷
S 老闆 2024 年委託一家三人小公司做客戶管理系統，合約裡有寫「著作財產權歸甲方」。看起來條款很完整對吧？但這家公司沒有跟員工簽過任何職務著作約定。一年後其中一名員工離職，自己拿著當時寫的程式碼到競爭對手那邊去做幾乎一模一樣的系統，S 老闆要告侵權時才發現——員工才是該段程式碼真正的著作人，公司當初讓與給 S 老闆的權利，本身就有瑕疵。
這就是合約必備條款第 4 條（第三方權利擔保）和第 1 條（著作人約定）的重要性——你必須要求廠商擔保「已取得所有員工的職務著作完整權利」，並把違反擔保的責任明確化。
簽約前的合約檢查 SOP（含查核清單）
看完前面的條款和案例你應該理解，著作權問題在簽約那一刻決勝負。簽完才發現問題，要回頭談判極其困難（廠商沒義務配合修改）。下面這套 SOP 是建議在收到廠商合約版本後 48 小時內必做的事。
步驟 | 檢查內容 | 發現問題的處理 |
|---|---|---|
Step 1 | 關鍵字搜尋 | 用 Ctrl+F 搜尋「著作財產權」「source code」「原始碼」「智慧財產」「讓與」——任一找不到就是缺失 |
Step 2 | 讓與時點檢查 | 確認「著作財產權讓與」綁定在「驗收完成 + 尾款付清」，不是合約簽訂或專案啟動 |
Step 3 | 讓與範圍檢查 | 必須是「全部、永久、不可撤回」三個詞同時出現；缺任一個都不夠 |
Step 4 | source code 交付定義 | 確認交付物清單包含：完整原始碼、資料庫 schema、設定檔、部署腳本、第三方相依套件清單 |
Step 5 | 第三方權利擔保 | 找到「擔保未侵害第三人權利」條款，並確認違反時的責任（建議違約金不低於合約總額的 2 倍） |
Step 6 | 員工職務著作擔保 | 確認廠商擔保「已就所有參與專案之人員取得完整職務著作財產權」 |
Step 7 | 開源軟體清單 | 要求廠商於驗收時提供完整 OSS 清單，並檢查是否含 GPL 等限制性授權 |
Step 8 | 源碼託管條款 | 專案金額超過 50 萬建議納入；超過 200 萬視為必備 |
Step 9 | 律師最後審閱 | 專案金額超過 100 萬建議花 1-2 萬給律師審一次，比事後糾紛便宜 100 倍 |
💡比價時就把著作權問題問清楚
詢價階段就應該問：「source code 是否完整交付？著作財產權是否讓與？是否願意配合源碼託管？」答案模糊或閃避的廠商直接從候選名單排除——不要等到合約階段才發現問題。比價時要問什麼可以參考 如何選軟體開發公司？7 個評估標準與合約必看條款。
Source code 交付不是 zip 一個檔就算完事
合約寫了「交付 source code」還不夠，因為「source code」這個詞在不同人腦中有不同意思。對廠商來說可能就是把專案資料夾打包；對你來說，真正能獨立運作的「完整交付」應該包含下面這些。
交付項目 | 說明 | 驗證方式 |
|---|---|---|
應用程式原始碼 | 所有自行撰寫的前端、後端、API 程式碼，含註解 | 能在另一台乾淨機器編譯運行 |
資料庫 schema 與遷移腳本 | 含建表語法、初始資料、版本遷移檔（migrations） | 能從零還原資料庫結構 |
設定檔範本 | .env.example、各環境設定（dev/staging/prod） | 實際金鑰可分開傳，但範本要齊 |
部署腳本與文件 | Dockerfile、docker-compose、CI/CD 設定、部署 runbook | 依文件可獨立部署成功 |
第三方套件清單 | package.json / requirements.txt / Gemfile 等鎖定版本 | 依清單可重建相依環境 |
API 文件與架構圖 | Swagger/OpenAPI、系統架構圖、資料流圖 | 新工程師可在 1 週內理解系統 |
管理後台帳號與權限說明 | 最高權限管理員帳號、角色權限矩陣 | 能完整接管系統管理 |
第三方服務帳號移轉清單 | 使用之 SaaS 服務（如金流、簡訊、雲端）的帳號歸屬與移轉方式 | 可獨立續約或更換 |
實務上建議在合約附件直接列出「交付清單檢核表」，驗收時逐項打勾。任何一項缺漏，尾款不付。這個動作把抽象的「交付 source code」變成具體的查核點，廠商沒有模糊空間。
更完整的階段付款與驗收節點設計，可以看 MVP 不是把功能砍少：找外包做 MVP 的 4 階段付款與驗收節點完整指南，那篇把驗收節點怎麼跟付款綁在一起講得很細，建議搭配本篇合約條款一起設計。
開源套件與 AI 寫程式：2026 年新出現的兩個地雷
開源授權的傳染性風險
廠商寫程式不可能完全從零造輪子，一定會用開源套件。問題是不同的開源授權對你的「商業使用」限制天差地遠。最危險的是 GPL 系列——根據 GPL 的 copyleft 條款，如果你的商業軟體裡用了 GPL 授權的核心元件並對外散布，整個商業軟體可能被要求公開原始碼。
一個老闆要記住的最低標：合約裡要求廠商提供「開源套件清單與授權條款」（commonly called SBOM, Software Bill of Materials），驗收時把這份清單拿給律師或懂的工程師掃過一眼，特別注意有沒有 GPL、AGPL、SSPL 這幾個高風險授權。對於商業 SaaS 產品，AGPL 比 GPL 更兇——它連「網路服務」都觸發 copyleft 條款。
AI 寫程式的著作權灰色地帶
2026 年的軟體外包，幾乎沒有廠商會跟你說「我們完全不用 AI 工具」。Copilot、Claude Code、Cursor 都已經是標配。問題是 AI 生成的程式碼著作權狀態還在灰色地帶——美國著作權局已經明確表示純 AI 生成的內容不受著作權保護，台灣目前沒有明確判決，但學界主流意見傾向「AI 生成需有人類創作貢獻才受保護」。
這代表如果廠商交付的程式碼中有大段純 AI 生成、沒有人類修改，這些段落可能根本不受著作權法保護——所謂的「讓與著作財產權」就變成讓與一個不存在的權利。實務上的處理方式是：合約要求廠商揭露 AI 工具使用情況，並擔保所有交付程式碼經過人類工程師實質審閱、修改、整合，符合著作權保護要件。
ℹ️AI 編程工具不是不能用，是要寫進合約
與其禁止廠商用 AI（不切實際也降低效率），不如在合約裡正面處理：要求揭露使用之 AI 工具、擔保 AI 產出已經人類實質創作貢獻、保留稽核權利。這樣既能享受 AI 帶來的效率，也能維持著作權保護的完整性。
源碼託管（Source Code Escrow）：你最後一道安全網
即使所有條款都寫對、廠商也很配合，還是有不可控的風險：廠商倒閉、廠商被併購、關鍵工程師離職、廠商與你關係惡化拒絕配合。這時候源碼託管就是你最後一道保險。
根據 國際源碼託管市場研究報告，全球軟體與源碼託管服務市場 2026 年預計達 93.95 億美元，年複合成長率 13.07%——成長動能主要來自「企業擔心廠商鎖定」。台灣目前提供託管服務的單位較少，但實務上可以用替代方案達成相同效果。
簡化版源碼託管：適合中小企業
- 方案 A：自有 Git Repository：合約要求廠商每次 release 都 push 到甲方擁有的 GitHub/GitLab 私有倉庫。最簡單、零成本，但無法防範廠商日後刪除歷史。
- 方案 B：律師事務所託管：合約簽訂時將完整 source code 燒錄光碟或加密硬碟交給律師事務所保管，每季更新。費用約 1-3 萬／年。
- 方案 C：第三方專業託管：使用如 Iron Mountain、NCC Group 等國際託管服務，費用 5-15 萬／年，但釋出條件嚴格、有完整法律保障。適合 500 萬以上專案。
選哪個方案要看專案金額和風險容忍度。一般中小企業專案（100-500 萬）建議用方案 A + B 組合：日常開發 push 到自有 repo，每季把完整版本另外給律師備份。
常見問題
Q合約已經簽了沒寫著作權歸屬，現在還能爭取嗎？
可以爭取，但難度大幅提高。廠商沒有義務同意修改合約，你只能用「商業關係」當槓桿——例如尚未付清的尾款、續約合約、新專案合作機會。建議找律師起草補充協議書，明確約定著作財產權讓與、source code 交付。如果廠商完全拒絕，務實的做法是評估換廠商重做的成本，跟廠商開出來的「贖金」比較。實際個案問題請諮詢律師或恆遠數位行銷有限公司。
Q合約寫「著作權歸甲方」這樣夠嗎？
不夠。「著作權」是上位概念，包含著作人格權與著作財產權。著作人格權法律上不可讓與（永遠跟著作人走），實務上正確寫法是：「乙方為著作人，並於驗收完成尾款付清後，將著作財產權全部、永久、不可撤回讓與甲方；乙方不行使著作人格權」。這樣才完整。
Q如果廠商堅持不讓著作財產權怎麼辦？
這通常代表廠商打算把同一套程式碼賣給多個客戶（範本式接案）。如果你的產品有獨特商業邏輯、不希望被同業複製，這種廠商不適合你的專案。退而求其次的做法是要求「在你所在產業內獨家授權」+「核心商業邏輯部分讓與」，但這條路有 80% 機會在實際落地時出現爭議。
Q我的程式碼內含開源套件，整套還能讓與嗎？
讓與的是廠商「自行撰寫」的部分；開源套件本身依其原授權條款使用，不在讓與範圍內，這是業界通則。合約要明確區分「廠商新作」與「使用之開源元件」，並要求廠商擔保所有開源使用符合該授權條件。出資人接手後同樣要遵守這些開源授權。
Q源碼託管真的有用嗎？台灣案例多嗎？
台灣本土案例不多，主要因為過去軟體外包多偏小型、合約意識較弱。但中大型專案（500 萬以上）國際標準作法都會做託管。實務上更多人用簡化版——直接用甲方擁有的 GitHub 私有 repo 接收每次 release，配合律師事務所每季備份完整版本。功能上等同託管，成本低很多。
Q我是 SaaS 訂閱模式（不是買斷），還需要管 source code 嗎？
需要——這個情境風險更高。SaaS 廠商一旦倒閉或停止服務，你連登入都做不到。SaaS 合約應該要求：1) 提供資料完整匯出機制（含 schema）；2) 廠商停止服務時的「過渡期」條款；3) 重大故障時取得讀取資料的最低權限；4) 對於關鍵任務系統考慮要求源碼託管。
Q找個人 SOHO 開發跟找公司開發，著作權處理有差嗎？
有差。SOHO 是自然人，他寫的程式碼著作權直接屬於他本人，合約讓與一步到位。公司開發則必須先確認公司與員工有職務著作約定（員工→公司），再讓與給你（公司→出資人）。權利鏈多一段，風險也多一倍。委託公司開發時務必加擔保條款：「乙方擔保已就所有參與本案之人員取得完整職務著作財產權」。
最後：把著作權問題從附錄拉到主菜
台灣老闆找外包做軟體最常犯的錯，是把合約看成「形式」。心思都放在價格、交期、功能規格——著作權那一頁通常是廠商給的範本看一看就簽了。但程式碼是否真正屬於你，會在三年後想換廠商、想擴展業務、想授權給子公司、想被併購時，決定你的議價籌碼。
具體可以做的三件事：
- 立刻做：把現有專案的合約翻出來，照本文 SOP 第 1-3 步檢查。如果發現缺漏，思考是否能在下一次續約或追加開發時補上。
- 下次簽約做：把本文的合約必備 9 條當清單，要求廠商寫進合約。沒辦法接受的廠商列為高風險。
- 專案金額大的話：花 1-2 萬請律師審閱合約，比事後糾紛便宜 100 倍。或交給有經驗的數位顧問把關。
⚠️本文不構成個案法律意見
本文為一般性資訊整理，內容基於台灣著作權法及實務經驗撰寫，不構成個案法律意見。實際合約問題，特別是金額較大或情況複雜的個案，請諮詢專業律師或恆遠數位行銷有限公司，由我們協助評估後再做決定。
如果你正在規劃軟體外包，或現有合約需要審閱，可以從報價管理服務頁開始，恆遠會在初期諮詢時把合約風險一併納入評估。也可以回到 軟體產品完整路線圖 看看其他相關階段的注意事項。著作權只是合約的其中一塊，但卻是最不能省的那一塊。
——恆遠數位行銷有限公司，給找外包老闆的一份合約防雷指南。
AUTHOR
自由揚AntonyLin
留言(0)
尚無留言，成為第一個留言的人吧！