在盡職調查之前就補齊書面權利鏈的軟體公司

分析範圍

本案例是教學合成案例（synthetic teaching case），不對應任何真實存在的公司、交易、契約或人物。所有公司名稱、資產數量、金額、時程與內部對話都是為教學而設計的 example。設計目的是讓讀者看見「智慧財產權利鏈完整」這句話在實務上到底由哪些具體動作構成——一份可以逐列檢查的清單、一輪針對缺口的補件，以及持續付出的行政成本——而不是一個抽象的形容詞。

案例 as-of 2026-07-31。Jurisdiction 未指定，而且這一點在本案例中特別重要。 本案例牽涉的每一項制度都因地區而異：受僱人職務上完成的著作或發明其權利歸屬於誰、需不需要書面約定才能移轉、成立公司之前個人所完成的成果要用什麼文件移入公司、承攬人（contractor）與受僱人在權利歸屬上的預設規則差在哪裡、權利讓與是否需要登記或公證才對第三人生效、以及營業秘密要達到什麼程度的保密措施才受保護——這些全部依當地法令與契約而不同。

因此本案例通篇不主張任何地區的法律要求什麼。 文中出現的每一個制度性問題，都應該被讀成「這家公司當時必須拿去問當地合格專業人士的問題」，而不是「法律規定如此」。讀者若把文中任何一份文件安排當成自己所在地的合法或足夠做法，那是誤用。與數位服務、隱私相關的地區差異請見隱私與數位服務的地區差異；任何實際安排前應尋求當地合格的法律專業協助。

明示的簡化假設（這些簡化在真實交易中不成立）：

假設所有相關人員都還聯絡得上、也都願意配合補簽。真實案例中最常見的困難正好相反：早期的合作者已經失聯、已離職且關係不佳、或已經自己創業做類似產品。
假設公司只有單一產品線與單一品牌，不考慮多產品、多品牌或跨國子公司之間的權利歸屬。
不考慮專利。本案例的公司沒有申請任何專利，因此不涉及發明人認定、申請時點與新穎性的問題。
不考慮客戶契約中反向授權給客戶的部分，也不考慮公司自己對外授權的收入。

資料缺口（明列，不臆測補齊）： 本案例沒有交易對方的完整問卷原文、沒有對方內部如何評分的紀錄、沒有其他被評估標的的可比資料、也沒有這家公司若不做清點會發生什麼的觀察。因此本案例無法判斷這份權利鏈在對方的決策中占多少權重，也無法判斷 63 項資產這個規模相對於同類公司是多是少。

fact / inference / example 的標示原則： 清單上的加總（51 加 12 等於 63）是可以逐步驗算的 fact；公司名稱、資產項數、金額與所有敘事細節是 example；至於「因為事前補齊了缺口，所以盡職調查才沒有被要求調整價格」這類敘述，是作者的 inference，文中會逐一標示，並在後段明確說明為什麼它不證明因果。

情境與決策

「昱衡互動」是一家十九人的軟體公司，做一款面向一般消費者的行動應用程式，同時提供企業版授權給少數企業客戶。公司在成立後第二年開始有穩定收入，第三年年初接到一家較大的同業表達策略投資與後續可能收購的意向。

決策點發生在收到意向之前，而不是之後——這是本案例最重要的結構特徵。

事情的起點很平凡。公司第二年第三季在準備一份企業客戶的授權合約時，法務外包顧問問了一個問題：「這款產品裡的程式碼，是不是全部都屬於公司？」共同創辦人甲的直覺回答是「當然」。顧問接著問了第二個問題：「那你能不能給我一份清單，列出每一段程式碼是誰寫的、以及公司憑哪一份簽過名的文件擁有它？」

這個問題沒有人能當場回答。這不是因為公司做錯了什麼，而是因為沒有人做過這件事。程式碼一直在增加，人一直在來去，第三方元件一直在被引入，而「誰擁有它」這個問題從來沒有被逐項問過。

兩位創辦人當時掌握的資訊：

公司有一份標準的雇傭契約範本，裡面有職務上完成成果歸屬公司的條款。
公司與外部設計工作室、外部承攬工程師各有簽過契約，但版本不一致，是不同時期用不同範本簽的。
產品裡用了大量開源（open source）元件，但沒有人整理過清單。
創辦人甲在公司成立之前約六個月，就已經自己寫了核心後端的第一版，那時候還沒有公司。

他們當時不知道的：

上述哪些安排在自己所在地是足夠的、哪些不是。
成立前個人完成的成果，要用什麼文件、在什麼時點移入公司才算數。
開源元件裡有沒有條件會影響公司對外授權的方式。
一年半後會有人來做盡職調查（due diligence）。

創辦人做的決定是：在沒有任何外部壓力的情況下，先做一次完整清點。 兩位創辦人明確地把這件事定位成一次性的專案，而不是持續的合規流程——這個定位後來被證明是錯的，第五節會說明。這個決策與風險清單的核心邏輯相同：先把不確定的事變成一張可以逐列檢查的表，才有可能討論處理方式。

採取方案與 failed alternative

第一步：把資產列出來，而不是把權利列出來

清點的第一個方法論選擇很關鍵。團隊一開始想從「我們有哪些權利」出發，很快就卡住了，因為那要求先知道答案才能提問。改成從「產品由哪些東西構成」出發之後才動得起來：不問權利，只問「這個東西是什麼、誰做的、什麼時候做的、有沒有一份簽過名的文件」。

最終清單共 63 項資產，分成六類：

類別	項數	建立者	依據的書面文件
成立前由創辦人完成的程式碼與設計	4	創辦人甲、乙	成立時的權利移轉文件
受僱人在職務中完成的程式碼與文件	21	在職與離職員工共 14 人	雇傭契約中的職務成果條款
外部承攬人完成的成果	9	5 位承攬人、1 家設計工作室	各自的委製或承攬契約
第三方授權素材（字體、圖庫、音效）	7	第三方	商業授權條款
開源元件	20	第三方	各元件自己的授權條款
品牌與內部方法（名稱、標誌、演算法參數）	2	內部	商標申請與營業秘密管理措施

驗算： 4 + 21 + 9 + 7 + 20 + 2 = 63。逐步相加：4 加 21 等於 25；25 加 9 等於 34；34 加 7 等於 41；41 加 20 等於 61；61 加 2 等於 63。與總數相符。

逐項檢查後的結論是：51 項有完整且對應正確的書面文件，12 項有缺口。 驗算：51 + 12 = 63，與總數一致。

12 項缺口再分類為三種處理方式：8 項可以補簽解決、3 項需要升級或更換授權、1 項需要移除重寫。 驗算：8 + 3 + 1 = 12。

這裡要說一句直白的話：有缺口是正常的，而且缺口本身不是這家公司的過失。 一家從零長到十九人的公司，在成長過程中不可能每一份文件都在正確的時點用正確的版本簽好。一個「從第一天起就完美無缺」的案例對讀者沒有教學價值，因為那不是任何人的實際處境。有教學價值的是：缺口在什麼時候被發現、以什麼成本被關閉。

第二步：關閉八項可補簽的缺口

八項之中最典型的三類是：

創辦人成立前的成果。 創辦人甲在成立公司前六個月寫的核心後端第一版，成立時公司只有一份章程與出資紀錄，沒有任何文件描述這段程式碼如何進入公司。兩位創辦人補簽了一份把成立前相關成果移轉給公司的文件，並在文件中逐項列出具體是哪些檔案、哪個時間區間、以及當時是在哪個環境完成的。這份文件在不同地區的效力、需不需要對價、以及能不能追溯到成立日，都是他們拿去問當地律師的問題，本案例不主張任何答案。

設計工作室的委製契約缺少讓與條款。 品牌標誌是公司成立第四個月委託外部工作室設計的，當時簽的是一份兩頁的報價確認，內容只寫了交付項目與付款方式，沒有寫成果的權利歸屬。工作室仍在營業，補簽並不困難，但雙方對「是否包含當初被否決的三個未採用版本」有討論——最後的處理是只就實際採用的版本補簽，未採用版本明確排除，避免製造一份雙方認知不一致的文件。

三位早期離職員工的契約用的是舊版範本。 舊版範本裡的職務成果條款寫得很含糊。三人都同意補簽確認文件，其中一位提出希望公司同時確認他個人在職期間的業餘專案不受影響——公司接受，並把界線寫進文件。這件事後來被團隊認為是整輪補簽中最有價值的一次對話，因為它把一個原本模糊的邊界變成雙方都同意的白紙黑字。

第三步：那項真正尷尬的資產

最麻煩的一項是這樣的。第九個月時，公司找了一位外部承攬工程師寫「客戶資料匯入工具」。合約是完整的，有明確的權利讓與條款，也有一句標準的保證：承攬人保證交付成果為其原創、且不侵害第三人權利。

清點時，團隊用工具比對程式碼與公開來源，發現匯入工具中有一段約六十行的解析邏輯，與某個公開專案的程式碼高度相似。聯絡這位承攬人後，他坦白說明：他確實從那個公開專案取用了這段邏輯，因為那是處理某種格式的標準做法；他當時的理解是「這是公開的、大家都在用」。

問題出在哪裡： 那個公開專案的授權條款附有標示出處的條件——使用者必須保留原始的著作權聲明並在散布時隨附授權文字。公司的產品從來沒有這樣做，因為沒有人知道有這回事。同時，承攬契約中那句「保證為原創」的陳述，就這段程式碼而言並不準確。

兩位創辦人當時面對的選項，以及他們如何評估：

第一個選項是移除並重寫。優點是徹底、不留任何後續義務。缺點是這段邏輯經過一年多的實際使用已經很穩定，重寫要重新測試，而且重寫者若曾看過原始碼，「乾淨重寫」本身是否成立又是另一個需要處理的問題。

第二個選項是遵守授權條件、把它做對。也就是：在產品內加入一個開源授權聲明頁面，逐項列出所使用的元件、其授權條款與必要的著作權聲明；在程式碼庫中加入對應的聲明檔案；並在對外散布的安裝檔中一併包含。

第三個選項是什麼都不做，賭沒有人會發現。

他們選了第二個。理由是：這個授權條款要求的東西，本來就是公司應該做而且做得到的事——標示出處的成本是一次性的、可驗證的、而且對產品沒有任何功能影響。移除重寫則是用高成本換取「不必做一件低成本的事」，划不來。

同時他們做了兩件配套的事。其一，請這位承攬人書面確認交付成果中其餘部分為其原創、並重新確認權利讓與；那句不準確的原創保證則以一份補充文件說明實際情況，而不是假裝它是準確的。團隊當時的判斷是：一份與事實不符的保證，日後被發現時的殺傷力遠大於一份誠實的補充說明。 其二，把「所有外部承攬成果在驗收前必須進行來源比對」寫進流程。

檢查完 20 項開源元件後，另外發現 2 項也有類似的標示要求，一併納入同一份聲明；還有 1 項的條款團隊看不懂其對「散布」的定義是否涵蓋公司的雲端服務型態，這一項被送去問外部律師，最後的處理是替換成另一個功能相近、條件較單純的元件——這就是前面 12 項缺口中「1 項需要移除重寫」的那一項。

第四步：三項需要升級的授權

產品介面使用的一套字體，公司當初買的是設計稿用途的授權，但實際上把字體檔嵌入了行動應用程式中散布給終端使用者。這兩種用途在該字體的授權條款裡是分開計價的。公司補購了嵌入用途的授權。另外兩項是圖庫素材，原本的授權範圍不涵蓋商業性的產品內使用，同樣補購。

這三項的共同結構值得注意：公司付過錢，也有合法的授權文件，但用途超出了授權範圍。 這是清點時最容易被漏掉的一類缺口，因為「我們有買」這個事實會讓人停止繼續問「買的是哪一種」。

Failed alternative：等到有人來查再說

這是絕大多數同規模公司實際採取的做法，也是昱衡互動在顧問問出那個問題之前的做法。它在什麼時候看起來合理？

其一，清點沒有立即的商業回報。兩位創辦人估算這輪清點與補件耗掉約 240 小時的內部工時，加上外部律師費用約 180,000 元。這些資源本來可以拿去做產品。在一家還在找成長的公司裡，這個機會成本是真實的，不是藉口。

其二，大多數時候真的不會出事。權利鏈的缺口不像伺服器當機，它不會自己發作。一家公司可以帶著十二個缺口營運很多年而毫無感覺。

其三，「等有需要時再處理」聽起來像是合理的時間管理。畢竟如果永遠沒有交易、沒有客戶詢問、沒有爭議，那些文件就永遠不需要。

它在什麼假設下失效？ 這個做法隱含一個假設：缺口的修補成本與修補時點無關。而這個假設是錯的，原因有三層：

第一層是人的可得性。 補簽需要對方配合，而對方配合的意願隨時間單調下降。離職員工在離職當月願意簽的文件，三年後可能不願意簽，或提出條件。設計工作室今天還在營業，明年可能已經解散。承攬人今天願意誠實說明程式碼來源，在他自己已經創業做競品之後就未必。時間不會讓缺口變小，只會讓能關閉它的人變少。

第二層是議價位置。 在沒有交易的時候補簽，補簽是一件行政事務；在盡職調查進行中補簽，補簽變成一個對方知道的籌碼。同一份文件、同一個對方，在兩個時點的取得成本可能差很多倍。

第三層是時間壓力下的品質。 盡職調查通常有時程。在兩週內要補齊十二項缺口，做出來的東西會是為了交差而簽的文件，而不是為了正確而簽的文件。而一份寫得不精確的權利文件，在日後可能比沒有文件更難處理。

預警訊號（不需要後見之明，當下就觀察得到）： 沒有人能在十分鐘內回答「這段程式碼憑哪份文件屬於公司」；不同時期簽的承攬契約用的是不同範本而沒有人知道差在哪；產品裡的開源元件沒有清單；有人用「應該沒問題吧」回答權利歸屬問題；以及公司成立前就存在的成果，從來沒有被任何文件提到過。

結果與因果限制

觀察到的結果（fact，均可從前述清單直接驗算）：

清點共列出 63 項資產，其中 51 項文件完整、12 項有缺口，51 + 12 = 63。
12 項缺口的處理分為補簽 8 項、授權升級 3 項、移除重寫 1 項，8 + 3 + 1 = 12。
全部 12 項在盡職調查開始前約十一個月完成關閉。
內部投入約 240 小時，外部法律費用約 180,000 元，授權補購費用約 95,000 元。合計外部現金支出 180,000 + 95,000 = 275,000 元。
一年半後，對方的盡職調查中與智慧財產相關的問卷共 34 題，公司在 9 個工作天內完成全部回覆並附上對應文件。
該次盡職調查的智慧財產部分沒有產生任何 remediation 要求，也沒有產生任何與智慧財產相關的價格調整或價金保留。

本案例的 outcome 標記為 success，而 success 在此的意義被限定得非常窄：它只表示盡職調查的智慧財產部分在沒有補救要求、沒有價格調整的情況下完成。 以下三件事都不在 success 的範圍內，必須逐一講清楚：

它不表示這條權利鏈促成了那筆交易。 交易能不能成、以什麼條件成，取決於產品、市場、團隊、對方的策略需要與當時的資金環境，這些因素的權重遠大於文件。一條乾淨的權利鏈能做到的，充其量是移除一個可能讓交易變糟或變慢的理由，而不是提供一個成交的理由。把「我們文件很乾淨」當成交易論述，是把衛生條件誤認為賣點。
它不表示每一家權利鏈乾淨的公司都會有好結果。 本案例沒有對照組。我們沒有觀察到「同一家公司、同一個對方、沒有做過清點」會發生什麼；也沒有觀察到其他做過同樣清點但交易失敗的公司——而那樣的公司一定存在，只是不會被寫成案例。只看成功案例來推論做法有效，是最常見的推論錯誤之一。
它不表示 63 項、12 項、275,000 元這些數字有任何參考價值。 這些是為了讓算術清楚而設計的 example，不是從真實母體抽樣得到的，不具統計代表性。

本案例明確拒絕主張的因果陳述： 「事前補齊權利鏈，可以讓盡職調查免於價格調整」是不成立的過度推論。可以支持的、範圍窄得多的說法是：當每一項資產的建立者與對應書面文件都能被指出時，回答一份 34 題的問卷變成查表工作，而不是調查工作；本案例示範了這種差別在一次具體情境中如何呈現。至於這種差別是否會轉化成更好的交易條件、在多大比例的交易中會、以及在什麼樣的對方手上會，本案例都無法回答。

同樣不能主張的反向陳述： 「如果不做清點，這筆交易就會被砍價」也是 inference 而非 fact。有可能對方根本不會發現那六十行程式碼；有可能對方發現了但不在意；也有可能對方在意的是完全不同的東西。本案例無法把這些可能性分離。

一項必須誠實記錄的代價： 這條權利鏈不是一次性成本。清點結束後，公司把「權利文件在動工前簽妥」寫進了承攬流程，結果是承攬人上工前平均多出三個工作天的行政等待，而且在接下來一年中，有一位團隊很想合作的自由工作者因為不接受契約中的權利讓與範圍而沒有合作成。兩位創辦人事後的評估是這個代價值得，但這是他們的價值判斷，不是本案例可以推廣的結論。一家更早期、更需要速度的公司做出相反的取捨，也可能是理性的。 前面說過創辦人一開始把清點定位成一次性專案——這個定位是錯的，因為新的資產每週都在產生，維持乾淨需要的是流程而不是專案。

可轉移的教訓

可泛化的機制（與地區、產業無關，因為它是結構性的）：

第一，權利鏈是逐項的，不是整體的。「我們的智慧財產沒問題」這句話不是一個可以被檢驗的陳述。可以被檢驗的陳述長這樣：「第 37 項資產由某人於某年某月完成，依據某年某月簽署的某份文件歸屬公司。」這兩句話的差別，就是有清單與沒有清單的差別。這也是為什麼清點必須從「產品由哪些東西構成」出發，而不是從「我們有哪些權利」出發——後者要求你先知道答案。

第二，外部取得的東西有兩種缺口，而第二種更常被漏掉。第一種是「沒有文件」，例如那份缺少讓與條款的設計委製契約。第二種是「有文件但用途超出範圍」，例如那套只買了設計稿用途卻被嵌入產品散布的字體。第二種之所以更常被漏掉，是因為「我們有買」這個事實會讓檢查停在那裡。判斷方法很簡單：對每一項付費取得的素材，不要問「有沒有授權」，要問「授權涵蓋的用途，和我們實際的用途，是不是同一件事」。

第三，開源元件不是免費的，是有條件的。條件的內容差異很大，從幾乎沒有要求到會影響公司自身產品如何對外提供都有。可泛化的動作只有一個：維持一份實際使用中的元件清單，並逐項讀過它的條件。至於某一條件在自己的散布方式下具體代表什麼義務，那是需要當地專業意見的問題，不是可以靠通則回答的。

第四，與事實不符的保證，比缺少保證更危險。承攬契約中那句不準確的原創保證，處理方式是補一份誠實的說明，而不是假裝它準確。這個原則的適用範圍遠大於智慧財產——任何一份描述公司做法的文件，只要與實際做法不一致，就同時是兩個問題：實際做法的問題，以及那份文件本身的問題。反向的完整示範見抄來的合規文件，那個案例中的公司走了相反的路，代價是本案例的數倍。

第五，修補成本隨時間上升，而且上升的原因是人。這是「等有需要再說」失效的根本理由，也是唯一可以不看地區就成立的論證。

不可泛化的部分：

職務上完成的成果權利歸誰、需不需要書面約定、受僱人與承攬人的預設規則差別、權利讓與是否需要登記、成立前個人成果如何移入公司、以及營業秘密需要什麼程度的保密措施——全部依 jurisdiction 而不同，本案例對這些問題一律不給答案，只示範它們是必須被問出來的問題。 相關的地區差異與查核方式見隱私與數位服務的地區差異，實際安排前應尋求當地合格的法律專業協助。
商標的取得方式與範圍同樣依地區而定。公司若在多個地區銷售，需要在每個要保護的地區分別處理，這不是一次申請就能覆蓋全球的事。
63 項、12 項缺口、240 小時、275,000 元全部是設計出來的 example，不是任何規模的基準值。
那三個工作天的承攬前置期是這家公司的選擇，不是通則。一家更依賴短期外部人力的公司，這個成本會高得多。

讀者可以怎麼用：

第一，做一張表，不要做一份備忘錄。四個欄位就夠：這是什麼、誰做的、什麼時候做的、憑哪一份簽過名的文件屬於公司。填不出第四欄的每一列，就是一個缺口。這張表的完整框架見智慧財產，概念邊界見智慧財產概念。

第二，在沒有壓力的時候做。這是本案例唯一一個時點性的建議，理由在前面已經論證過：能關閉缺口的人會隨時間流失，而在交易進行中補簽會改變議價位置。

第三，把每一個缺口的處理方式寫下來，包括「決定不處理」的那些。有些缺口的關閉成本高於它的風險，決定不處理是合理的，但那個決定應該是被記錄下來的判斷，而不是被遺漏的項目。這兩者在清單上看起來一樣，在日後的差別很大。這正是風險清單對「接受」這種處理方式所要求的紀律。

第四，清點結束後，把它變成流程。新的資產每週都在產生。一次性的清點只能證明某個時點是乾淨的，證明不了下個月還是。

資料來源

Copyright（WIPO）支持本案例的兩項框架性事實基礎。其一，著作權保護的對象是表達（expressions），而不是背後的想法或方法；本案例中「哪些程式碼與設計屬於可被歸屬與移轉的資產」這個清點單位，正是建立在這個區分上。其二，該頁指出在 Berne Convention 之下，著作權保護自動取得，不以登記或其他形式要件為前提，而多數國家另設有自願性的登記制度，用途在於協助釐清歸屬爭議與便利交易。這一點解釋了本案例的核心緊張：權利可能自動產生，但「它屬於公司」這件事不會自動產生書面證據，而盡職調查要看的正是後者。適用範圍限制： 該頁提供的是國際組織的一般性說明，不是任何地區的法律條文；受僱人或承攬人完成的成果其權利歸屬如何認定、移轉是否需要書面或登記，均依當地法令而不同，本案例不主張任何地區的規則。Accessed 2026-07-31。

Trademarks（WIPO）支持本案例對品牌資產的處理方式。該頁說明商標保護可在國家或區域層級透過註冊取得，並指出申請人可向每一個希望取得保護的國家的商標主管機關個別提出申請，或使用 WIPO 的 Madrid System 提出國際申請。本案例據此指出：品牌不是「申請一次就全球有效」的資產，公司在哪些地區銷售、就需要在哪些地區分別處理。適用範圍限制： 該頁描述的是取得保護的途徑，不是任何地區的具體要件、費用或期限；本案例不主張任何註冊條件、審查標準或保護範圍。Accessed 2026-07-31。

Trade Secrets（WIPO）支持本案例對「演算法參數與內部方法」這一類資產的處理。該頁說明營業秘密指的是因保密而具商業價值、僅為有限範圍之人所知，且權利人已採取合理保密措施的資訊，涵蓋技術性與商業性資訊（例如配銷方法、供應商與客戶名單）；並指出可採取的預防措施包括保密協議、存取控制與資訊安全措施。該頁同時載明一項重要界線：營業秘密的持有人無法阻止他人使用其獨立取得或獨立開發出的相同資訊。本案例引用此界線來說明，為什麼這類資產在清單上要記錄的是「採取了哪些保密措施」，而不是一份權利證書。適用範圍限制： 「合理保密措施」的具體標準、以及未經授權取得或使用時的救濟途徑，全部依當地法令而不同，本案例不主張任何地區的判斷標準。Accessed 2026-07-31。

關於本案例數字的來源： 公司名稱、資產項數（63、51、12、8、3、1）、工時、金額與所有敘事細節全部是教學 example，不來自上述任何來源，也不對應任何真實個體或交易。三筆來源支持的是概念邊界與判斷框架，不是本案例的事實。