UI 用了別人的品牌名：濾鏡預設的商標風險與改名執行
App 裡有 19 個底片濾鏡 preset，顯示名稱直接用了相機廠商的機型名，上架前被抓出來全部改名。這篇記錄風險怎麼分級、為什麼這是商標問題而不是著作權問題，以及改名時怎麼避免留下使用者資料沒對齊的靜默退化。適合對商標的「指示性合理使用」有基礎概念、正在準備 App 上架的人讀。讀完能知道一套具體的風險分級方法，以及改名這種看似簡單的工作，實際上牽涉到哪些容易漏掉的環節。
這是 追追推推 追星族遠征紀錄 App 複盤 的延伸閱讀。
起點：一個使用者的提問
App 裡「超級拍立得」這個付費功能，提供 19 個底片濾鏡 preset，名稱直接顯示在 UI 上，不是只存在程式碼裡的內部代號。有使用者問了一句「會不會有違法疑慮」，才啟動這次盤點。
值得記的是，這個問題不是稽核工具抓出來的。靜態分析、lint、型別檢查都不會告訴你「這個字串是別人的註冊商標」，這種風險只能靠人去問、去查。
風險怎麼分級
盤點結果分成四級：
| 等級 | 項目 | 判斷理由 |
|---|---|---|
| 高 | INSTAX-100 / 250 / 500 / 800 / 50 | INSTAX 是相機廠商的註冊商標，用的是品牌全大寫標準寫法，五個數字都對得上真實機型 |
| 中高 | mini 99 / 45 / 12 / 40 / 50 / 90 | 單看「mini 12」很弱，但與上面五條並排在同一個濾鏡列裡，整體讀作同一個品牌系列 |
| 中 | SX70暖霧、600復古 | 另一家廠商的機型商標，商標權現由專門的 IP 控股公司持有 |
| 安全 | 關、寫實、陳年、露出過度1-3 | 純描述性詞彙 |
19 個裡有 13 個有風險。
分級裡最關鍵的洞察是「並排效應」：單獨一個弱勢名稱可能沒事，但一整列排在同一個選單裡，會讓使用者產生「這是官方系列」的整體印象。風險不是逐條獨立算的，要看整組排列起來的樣子。
為什麼是商標問題，不是著作權問題
這是最容易搞混的一層。
色彩曲線、gain、offset 這些是功能性參數，著作權基本不保護。把某個廠商的底片色調擬合出來，這件事本身不構成侵權。真正的問題在於，用他人的品牌名稱當自己商品的功能名稱。
逐條檢驗「指示性合理使用」的三要件（美國 New Kids 標準、台灣商標法第 36 條），第一與第三條站不住：五條同品牌機型名排成一列，出現在付費功能裡，一般使用者會合理認為這是官方授權的底片模擬。
務實的風險判斷值得原樣記下：
這類事情多半不是被告，而是收到律師信要求下架或改名。但那時 App 已上線、使用者資料裡已存了這些字串，處理成本比現在高一個量級。
另外兩層風險
除了商標本身，還有兩件容易忽略的事。
第一是商標鏈會繼承。這批參數的來源是以 14 張某修圖 App 的實拍樣本逐張定量擬合，品牌鏈是「相機廠商到修圖 App 到本專案」，連名字一起沿用，等於把中間那層對相機廠商的商標使用問題原封繼承過來。
第二是平台審核也管這件事。App Store 審核指南 5.2.5 對第三方商標敏感，這不只是法務問題，也是能不能過審的問題。
改名怎麼執行
改名要做的事，跟當時正在進行的多語系工項幾乎完全相同：把顯示字串抽成 i18n key（多語系翻譯用的識別碼，程式讀 key 去查對應語言的顯示文字），寫 migration（資料庫欄位變更時，用來把舊資料轉換成新格式的腳本）回填舊值。差別只在新的 i18n 值從「翻譯」變成「重新命名」。所以直接併進去執行，沒有另外開一個獨立任務。
新名稱採語意詞，例如 haze 薄霧、clear 清透、azure 靛藍、indigo 深藍、faded 褪色。soft-1 到 soft-5 這種流水號被否決，理由是 id 一旦寫進資料庫就是永久值，之後若有人在中間插隊或刪除某一項，流水號就會跟實際外觀脫節。
三項最值得記的執行細節：
FilmPreset.name這個欄位整個移除，不是改值。理由是「留著就會有人把顯示名放回去」，把犯錯的機會從結構上拿掉，而不是靠約定。- 工廠函式從
meitu()改名為fitted()，廠牌名連函式名都不留。 - 新增 15 個測試，做 id、i18n key、migration 三邊逐項比對，並在測試裡釘住「新 id 不得再含廠牌字樣」。
第三項是這次執行裡最好的工程判斷，因為它處理的是一個容易被忽略的失效模式：
查不到 preset 是靜默退化——回到中性、不報錯、不留痕。
如果 migration 漏了一個 id，使用者的舊卡片濾鏡會默默失效，沒有任何錯誤訊息。這種缺陷不會被 crash 報告抓到，只能靠測試在 CI 上釘住。
技術細節：三邊比對測試在檢查什麼
三邊指的是舊 preset 的 id 清單、i18n key 清單、migration 裡的回填對照表。 測試逐項確認三邊數量一致、每個舊 id 都能在 i18n key 裡找到對應項、每個 migration 條目都有實際落地的新值。 同時釘住一條規則：新 id 字串裡不得含有原廠牌名稱的片段，避免改名改一半又漏掉幾個。
實機確認既有卡片的濾鏡仍套得出來，這一項當時未完成，誠實記著，屬於尚未驗證的部分。
兩件相鄰但刻意未裁決的事
留著這兩條是為了記住「哪裡停手」。
第一是「拍立得」這三個字，是某廠商早年在台灣的譯名，今日已泛用化，風險偏低。但若要進商店名稱或截圖文案，就該先查註冊狀態再定，不能因為現在覺得安全就直接跳過查證。
第二是相紙外框造型。經典白框在美、歐有註冊的立體商標，也就是 trade dress。本專案走的是另一家的幾何規格，結論是現階段不建議動，因為動它等於重做全 App 的相紙幾何。這是一個很好的範例：風險存在不等於現在就要處理，處理成本與風險大小要一起看。
可遷移的通用知識
- 品牌名出現在 UI 顯示字串裡，靜態工具抓不到，只能靠人問。
- 並排效應：一組弱勢名稱放在一起會產生官方授權的整體印象，風險要整體評估，不能逐條獨立算。
- 功能性參數（色彩曲線、演算法）與品牌名稱是兩件事，前者著作權多半不保護，後者是商標問題。
- 素材或參數如果來自第三方，商標使用的問題會沿著來源鏈繼承下來。
- 顯示名一旦寫進資料庫就變成永久值，改名必須配 migration 回填。
- 改名時把可以放回舊值的欄位整個刪掉，比留著欄位加註解可靠。
- 「查不到就回預設」的容錯設計，在資料遷移的情境下會變成靜默退化，要用測試做三邊比對釘住。
- 實務上的風險多半是收律師信要求改名，而不是被告，但上線後才處理，成本高一個量級。
相關連結
- 追追推推 追星族遠征紀錄 App 複盤
- App Store 五次退件實錄：條款判讀與回覆紀律 —— 同一個 App 上架時的另一組合規戰場