原始碼歸屬與專案交接指南：著作權、合約條款與完整交接清單
多數專案在進行中都相安無事，真正的考驗出現在結案那一刻，或是決定換廠商的時候。這時候常見的對話是：「原始碼可以給我們嗎？」「當初合約沒寫要給。」「可是錢是我們付的。」
這類爭執幾乎都不是誰惡意，而是簽約時沒有把權利與交付物寫清楚。以下把原始碼歸屬的觀念、合約該寫什麼、交接該拿到哪些東西，以及對方不配合時的處理方式整理出來。需要特別說明的是，涉及具體權利認定時仍建議請法務或律師依實際合約判斷，這裡談的是觀念與實務準備。
先分清楚：著作權、所有權與使用權
日常對話裡「這個系統是我的」其實混在一起講了三件事。
著作權是法律上對這份程式碼的權利，包含能不能修改、能不能再利用、能不能授權給第三方。它不會因為你付了錢就自動移轉，而是要看合約怎麼約定。
原始碼的交付只是「拿到檔案」。拿到檔案不等於有權利修改或再利用——這兩件事是分開的，實務上也確實會出現「檔案給你但權利不給你」的安排。
**使用權（授權）**則是允許你在約定範圍內使用，例如只能用在本公司、不能轉授權、不能改作。授權的範圍可寬可窄，要看條款寫到什麼程度。
怎麼判斷你要哪一種：如果這個系統是你的核心業務資產，未來可能要擴充、要換廠商、要衍生其他產品，那就該爭取著作權讓與或至少是完整的修改與再利用權。如果只是一般的形象網站或標準化工具，授權使用通常就夠了，也可以換到比較合理的成本結構。
為什麼「原始碼給我」這句話不夠具體
只寫這五個字，實務上會留下至少三個模糊地帶。
第一，範圍模糊。一個系統通常包含多個部分：專案專屬的程式碼、廠商自有的共用元件或框架、第三方的開源套件、以及付費購買的商用元件。其中廠商自有的部分未必會隨專案移轉，商用元件的授權也可能綁定在廠商名下。這些都要逐項講清楚。
第二，時間點模糊。什麼時候交？結案時、尾款付清時、還是保固期滿？中途終止合作要不要交？這些情境都該寫。
第三，形式模糊。交一個壓縮檔，和交出完整的版本紀錄（開發過程的每次修改歷程），差別很大。只有最終檔案，等於後面接手的人看不到任何演進脈絡，維護難度會明顯提高。
另外值得注意的是開源套件的授權條件。系統裡使用的開源元件各有不同的授權要求，有些會影響你後續能怎麼散布或商用，這部分可以先讀開源授權白話指南建立基本判斷。
合約裡該事先寫清楚的條款
不需要寫得像法律論文，但以下幾項建議一定要有文字：
- 著作權歸屬：是讓與給業主、由廠商保留並授權、還是共有。若是授權，寫明範圍（能否修改、能否轉授權、有無期限與地域限制）。
- 交付物清單：原始碼、設計原始檔、資料庫結構、部署與環境設定說明、操作手冊，逐項列出。
- 交付時間點與條件：綁在哪個付款節點或哪個階段完成。
- 廠商保留的部分：哪些共用元件不隨專案移轉、業主是否取得使用授權、後續能不能自行修改。
- 中止合作時的處理：專案中途終止，已完成的部分怎麼交、怎麼結算。
- 帳號與環境的移交方式：由誰持有主帳號、如何轉移。
最常踩到的一步是只在報價單上寫一句「含原始碼」就以為足夠。報價單通常不是完整的契約文件，而且「含原始碼」沒有回答上面任何一個問題。挑選合作對象時把這些當成必問項目，如何挑選軟體開發公司裡整理了其他該問的問題與紅旗訊號。
交接清單一：程式碼與版本紀錄
實際交接時，程式碼這一項要確認的不只是「拿到了」，而是「拿到的能用」：
- 完整的版本控管紀錄，而不只是最後一版的檔案。
- 專案能在別的環境重新建置起來所需的設定範例（不含正式環境的密碼）。
- 說明文件，至少要能回答：怎麼安裝、怎麼在本機跑起來、怎麼部署到正式環境。
- 資料庫結構與初始資料的匯出。
驗證方式很直接：請另一位工程師（可以是你未來的維護廠商）依照交付的文件，在乾淨的環境把系統重新跑起來。跑得起來，交接才算完成；跑不起來，就代表還缺東西。這一步值得在尾款付清前做。
交接清單二：伺服器、網域與環境
這一區最常出狀況，因為它散落在很多地方：
- 網域：註冊在誰名下、註冊商帳號在誰手上、到期日是什麼時候、有沒有設定自動續約。
- 主機或雲端平台：帳號歸屬、付款方式綁誰的卡、有哪些服務在上面跑。
- DNS 設定：目前的解析紀錄有哪些、由誰管理。
- 憑證：到期日與續發方式。
- 備份：備份在哪裡、多久一次、怎麼還原、還原有沒有實際演練過。
最需要優先處理的是網域。網域如果註冊在廠商或某位離職員工名下，一旦聯絡不上，整個品牌的網址與信箱都會受影響，而且處理程序相當麻煩。網域、主機與 DNS 之間的關係如果不清楚，可以先讀網域與 DNS 白話指南再來核對。
交接清單三：第三方服務帳號
現代系統通常串接不少外部服務，每一個都是獨立的帳號與權限：
金流服務、物流服務、簡訊或郵件寄送、地圖服務、分析工具、錯誤監控、社群登入、雲端儲存、票券或發票系統。
每一項要確認三件事：帳號註冊在誰名下、登入方式與雙重驗證綁在誰的手機、以及帳單付給誰。建議的做法是所有服務一律用公司的共用信箱註冊，開子帳號給廠商使用，而不是直接把主帳號交出去。這樣換廠商時只需要停用子帳號，不必逐一重設。
最常踩到的一步是交接時只清點「有在用的服務」，漏掉測試或備援用的帳號。這些帳號平常沒人注意，但它們可能仍在計費，也可能握有正式環境的存取權。
交接清單四：文件與後續維護知識
文件不需要多，但要能回答接手的人最常問的問題：
- 系統有哪些主要功能模組，各自負責什麼。
- 重要的業務規則寫在哪裡（例如計價邏輯、權限規則）。
- 定期執行的排程工作有哪些、跑在什麼時間。
- 過去發生過什麼問題、當時怎麼處理。
- 已知的限制與尚未處理的項目。
最後一項尤其有價值。誠實列出已知問題的交接，比看起來完美的交接可靠得多——問題不會因為沒寫就消失，只會讓下一個人多花時間重新發現。至於交接之後誰負責什麼：維護期間的責任分配、服務水準與費用型態屬於另一份合約的範圍，網站維護費用包含什麼談的是那一段；這篇只處理結案或換手的那一刻，你手上該拿到什麼。
廠商不配合時可以怎麼處理
先確認一件事：對方是不想給，還是給不出來。後者其實不少見——小型團隊人員異動後，連自己都找不到完整資料。兩種情況的處理方式不同。
比較務實的步驟大致是這樣：先以書面（電子郵件即可）列出要求交付的項目清單，附上合約條款依據，給一個明確的回覆期限；同時盤點自己手上已經握有的部分，凡是註冊在公司名下、由公司信箱與付款方式綁定的資產，多半不必等廠商點頭就能先處理，優先把這些的控制權收回來。若對方仍不回應，再依合約的爭議處理條款進行，此時建議請法務或律師介入評估。
同時要做的是止血準備：確認網域與主機的續費不會中斷、備份是否在自己手上、有沒有替代方案能維持營運。實務上最糟的狀況不是拿不到原始碼，而是在爭執期間網域到期或主機停用，導致服務直接中斷。
預防遠比事後處理便宜。平常就把三件事維持在自己手上：網域註冊在公司名下、所有第三方服務用公司共用信箱註冊、以及每季確認一次備份能不能還原。做到這三件，即使與廠商合作結束得不愉快，你也還握著繼續營運的基礎。
把這篇的交接清單拿去對照你目前的系統，通常會冒出幾個「我不確定在誰手上」的項目——那些就是要優先處理的。跟 NETVANA 談談你的情況，不論是新合作要先把權利與交付物寫進合約，還是既有系統想盤點交接缺口，都可以聊。軟體服務沒有固定套餐，一律先了解需求再報價；專案費用結清後我們會完整移交原始碼、設計檔案與相關文件，各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：合約模式會直接影響交付物怎麼約定，看固定報價還是敏捷開發；接手別人留下的舊系統要怎麼評估，看舊系統現代化指南；驗收與付款節點怎麼綁在一起，看軟體驗收怎麼做；主機與託管方式的選擇會影響交接難度，可以讀網站主機怎麼選。
