本篇文章更新時間：2026/03/06
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
chardet 授權風波：原作者親上火線的關鍵提醒
編輯前言：當一個開源專案的授權被悄悄變更，影響的不只是開發者社群，更牽動整個生態系的信任度。這篇筆記整理自 No right to relicense this project，原作者 Mark Pilgrim 罕見出面澄清，值得所有關注開源授權的人讀一讀。
核心觀點 (Key Takeaways)
- chardet 的原作者 Mark Pilgrim 明確指出：現任維護者 沒有權利重新授權（relicense）這個專案。
- 依照 LGPL 要求，修改後的程式碼必須沿用相同授權，無法單方面變更。
- 即使維護者聲稱版本 7.0.0 是「complete rewrite」，只要不是 clean room 實作，仍無法避開原本的 LGPL 限制。
深入解析
原文中，Mark Pilgrim 直接登場並表明身份。他以過去寫過 Dive Into Python 與 Universal Character Encoding Detector 聞名，如今以 chardet 原作者的身分，對專案現況提出嚴正聲明。
原文強調：「They have no such right; doing so is an explicit violation of the LGPL.」
從他的角度，這次的問題其實非常單純：如果原始程式碼是以 LGPL 授權釋出，任何後續修改、延伸版本都必須沿用 LGPL，這是開源授權的基礎規則。
- 非 clean room，就不能說是完全重寫：原作者指出，維護者曾深入參與原程式碼，不可能完全隔離，因此無法主張「完全重寫」作為重新授權的理由。
- 使用 code generator 也無法改變法律現實：維護者似乎認為透過 code generator 可以避開授權限制，但 Mark 明確否定了這個想法。
最終，Mark 用相當溫和但堅決的語氣表示，希望團隊將授權「復原」到原本的 LGPL。
筆者心得與啟發
看到這段對話，我最大的感觸是：開源專案的技術可以演進，但授權不能被忽視。
很多人會把開源視為一個技術選擇，但其實授權背後是一套必須遵守的契約。這次事件也提醒我，所謂「重寫」並不是一種模糊的口號，而是必須經得起 clean room 標準的檢驗。
對開發者來說，若你在使用或維護開源專案：
- 請務必理解你接手的授權
- 若要變更授權，務必確認是否擁有全部著作權人的授權同意
- 不確定時就回頭看原作者寫過什麼、簽過什麼
這起事件可能會成為之後許多專案討論授權時引用的案例。也提醒我：技術是中性的，但開源的信任與社群關係絕對不是。