原始碼被抄襲盜用怎麼舉證？完整證據保全教學

原始碼被抄襲盜用怎麼舉證，往往是工程師與獨立開發者最焦慮也最容易準備不足的環節。程式碼本身可以被複製、改檔名、換註解甚至只做少量變數名稱修改就重新發布，對外看起來像是獨立開發的成果。當爭議發生時，口頭說「這是我先寫的」幾乎沒有說服力，截圖、貼上程式碼片段、甚至直接比對文字相似度，都很容易被質疑為事後拼湊或選擇性呈現。真正有力的做法，是把技術可驗證的事實先保全下來：檔案在某個時間點的確存在、內容與你現在拿出的檔案完全一致、而且這個一致性可以用數學方式證明。雜湊值與中繼資料就是在這種情境下最基礎也最客觀的證據工具，它們不能替你證明法律上的著作權歸屬，卻能清楚證明兩個檔案是否為同一份內容，以及這份內容的技術特徵在何時被記錄下來。

雜湊值就是檔案的數位指紋。SHA-256、MD5、CRC32 這類演算法會把整份檔案的二進位內容轉換成一串固定長度的字元，只要檔案內容有一個位元的差異，產生的雜湊值就會完全不同。因此當你能拿出原始檔案的雜湊值與對方被指控抄襲的檔案進行比對，完全一致代表內容完全相同，不同則代表內容經歷過修改。重點是這個比對過程不依賴主觀解讀，而是可重現的計算結果。搭配時間戳記的記錄，你就能建立「在某個時間點，這個內容對應這個指紋」的技術事實。這是舉證鏈的第一步，也是後續任何法律或協商程序中最難被推翻的部分。

要為原始碼建立完整的舉證鏈，最可靠的起點是從開發過程中就保留可稽核的記錄。Git 或其他版本控制系統的 commit 歷史、遠端倉庫的推送時間、CI/CD 的建置紀錄，都能提供內容演進的時間線。在發生爭議時，先把涉案的分支或標籤打成不可變的封存，例如 tar.gz 或 zip 壓縮檔，保留檔名、目錄結構與檔案權限資訊。接著計算每個關鍵檔案的 SHA-256 與 MD5，並把結果連同檔案系統的建立、修改與存取時間一起記錄下來。不要只保存單一檔案，整個專案的檔案清單與對應雜湊值構成的清單本身也需要被雜湊封裝，這樣就能避免單一檔案被抽換的質疑。許多開發者會忽略編輯器產生的中繼資料，事實上原始碼檔案本身雖少見 EXIF，卻可能帶有編輯器暫存、檔案系統的 MAC 時間、以及壓縮檔內的建立時間，這些都是輔助證明時間順序的技術線索。

實務上，原始碼的舉證通常會包含三層技術證據。第一層是內容同一性，由雜湊值負責，證明兩份檔案位元層級完全相同。第二層是時間性，由檔案系統時間、版本控制紀錄、遠端倉庫 log、甚至第三方時間戳服務提供佐證。第三層是環境特徵，像是開發者機器上的使用者名稱、專案路徑、編譯產物中的嵌入資訊、註解中的時間戳與作者資訊，這些都能形成間接一致性的圖像。舉例來說，如果你能證明某個 .py 檔案在 2024 年 3 月 12 日 14:32 的 SHA-256 為固定值，且該值與對方在 2024 年 6 月才公開的倉庫中檔案雜湊完全一致，就能形成強力的時間矛盾。想確認自己常用格式是否能被完整分析，可以參考在 FilesAudit 支援的格式列表中可以看到 200 多種檔案類型都被涵蓋，從純文字與程式碼到壓縮檔都能被解析。

常見的錯誤會讓原本可被採信的證據變得薄弱。有人只提供程式碼截圖或複製貼上的片段，這無法證明完整檔案，也很容易被指為挑選相似段落。有人依賴雲端硬碟的「上傳時間」作為證明，卻忽略雲端服務的時間可能被同步或修改。另一個盲點是只保存最新版，刪除了舊版歷史，導致無法呈現演進過程。舉證的黃金原則是完整性、可重現性與第三方保存。完整性指你要保留整份檔案而非片段；可重現性指任何人用同一演算法都能得到相同的雜湊；第三方保存則指把雜湊與時間戳的報告交給中立平台記錄，避免自己單方面修改。

在需要快速產出專業報告的情況下，許多團隊會使用線上驗證平台先行固定證據。從網頁上傳檔案即可取得中繼資料與雜湊值報告，這類工具會自動計算 SHA-256、MD5、CRC32，並提取檔案層級的中繼資料與時間資訊，輸出可供歸檔的 PDF 報告。對於原始碼專案，通常會先把整個 repo 打包成 zip，再上傳分析，報告中會列出封存檔本身的雜湊，以及封存內的重要檔案清單與對應指紋。這份報告的價值在於它提供了當下時間戳的技術快照，並以固定的格式保存供日後對照。對於需要大量檔案批次處理的情況，桌面版應用程式可以做到無限量的本地批量分析，並保留完整的處理紀錄。

不同證據的強度並不相同，需要清楚區分技術驗證與法律結論。雜湊值能證明兩個檔案內容相同或不同，卻無法證明誰先創作；中繼資料能提供