系統交付後,程式碼和資料是誰的?

我們遇過不少企業來談新系統時,真正的痛不是功能,而是這一句:「前一家廠商不給我們原始碼,資料也搬不出來。」想改功能,只能回頭找原廠商,對方開價多少就是多少;想換廠商,發現整套系統像租的房子,住了五年,家具全是房東的。這種「被綁架」的處境,在台灣的委外開發市場非常常見——而它幾乎都可以在簽約前用幾條白紙黑字避免。

這篇我們站在開發商的立場,把委託開發前該談清楚的交付條款,誠實地攤開來講。是的,這些條款很多對開發商「不利」——我們自己的交付標準就是程式碼與資料完整交付客戶,因為我們相信長期關係應該建立在服務品質上,不是建立在客戶走不掉上。

先搞懂:你付錢買到的,預設可能不是你想的

很多企業主以為「我出錢開發的,當然是我的」。法律上未必。著作權在沒有特別約定時,歸屬可能落在實際開發的一方;而就算約定了權利歸屬,若合約沒寫「交付原始碼」,你拿到的可能只有一個能跑的系統,沒有那份能改、能搬、能延續的程式碼。權利歸屬與實體交付是兩件事,兩件都要寫進合約。

另外要分清楚兩種模式:客製化開發(為你量身打造,理應完整交付)與訂閱現成 SaaS(你買的是使用權,本來就不會拿到原始碼,但資料匯出權必須有)。兩種模式都合理,不合理的是用客製化的價格,買到 SaaS 的權利。我們在自建 vs 買現成的決策框架裡談過怎麼選,這篇聚焦在:一旦選了委託開發,合約該長什麼樣。

合約該白紙黑字的七件事

1. 原始碼完整交付:不是「可申請」、不是「結案光碟」,是持續交付——最好是客戶擁有的版本庫(如公司自己的 GitHub 組織),廠商在裡面開發,每次更新客戶即時看得到。結案才給一包壓縮檔的年代該過去了。
2. 著作財產權歸屬或永久授權:寫明客製部分的權利歸屬客戶,或至少取得不可撤銷、可修改、可轉讓給下一家廠商的永久授權。
3. 資料庫的完整資料與結構:資料是你的營運命脈。合約要保障你隨時可取得完整資料庫備份,包含資料結構說明——一堆沒有欄位說明的原始資料,搬家時跟沒有差不多。
4. 部署文件與環境交接:系統跑在哪、怎麼部署、用了哪些第三方服務、帳號在誰名下。特別注意:網域、雲端主機、金流帳號,一律註冊在客戶名下,廠商只拿授權存取。我們看過太多網域登記在前廠商名下、鬧翻後連官網都拿不回來的案例。
5. 第三方元件清單:系統用了哪些開源套件、哪些付費服務,授權條件為何。避免接手時才發現某個核心元件的授權綁在前廠商身上。
6. 交接協力義務:合約終止時,廠商有義務在合理期間內協助新團隊交接,並明訂費用計算方式。不寫這條,分手時的協助就是漫天喊價。
7. 測試與文件:自動化測試與基本技術文件是不是交付項目。有測試的程式碼,下一個團隊敢改;沒測試的,每次改動都是賭博。這也是為什麼我們把自動化測試跟 CI/CD 列為標準交付,不是選配。

好的交付條款,是讓客戶「留下來是因為想留,不是因為走不了」。敢把合約寫成這樣的廠商,通常也是對自己服務有信心的廠商。

怎麼在簽約前測試一家廠商

條款之外,分享一個簡單的試金石:直接問對方「如果三年後我們想把系統轉給內部團隊或其他廠商維護,流程是什麼?」健康的答案會具體——版本庫怎麼移轉、文件有哪些、交接怎麼收費。閃躲、模糊,或反過來強調「跟我們配合就不用想這些」的,你已經得到答案了。也建議跟對方要過往案例,看看實際交付了什麼,可以參考我們的作品集感受一下完整交付長什麼樣子。

系統會用五年、十年,廠商關係卻未必。把交付條款談清楚,不是不信任,而是讓合作雙方都輕鬆——我們自己就是這樣執業的。如果你正要委託開發,或已經卡在「要不到碼、搬不走資料」的處境想找出路,歡迎跟我們聊聊,也可以先看看客製化系統與 SaaS 服務裡我們對交付方式的說明。