Claude 5 天重寫舊庫引發全網爭議，維護者擅自更換開源授權，退網 15 年的原作者突現身：不准修改！

花 5 天時間借助 Claude Code 重寫營運十餘年的舊程式碼庫後，項目維護者直接將開源授權從 LGPL 改為更寬鬆的 MIT。 近日，Python 經典編碼檢測工具 chardet 因此陷入輿論中心。 更具戲劇性的是，這個庫的新版發布後，自 2011 年起便淡出公眾視野的原作者突然現身，要求項目維護者立刻將授權改回原版。 然後維護者堅稱，新版本是用 AI 從零開始編寫的，與舊版本無關。

原作者隱退，維護者上崗。 簡單來說，chardet 是 Python 生態中極為常用的文本編碼檢測庫，核心功能是自動識別位元流的編碼格式，如 UTF-8、GBK、ISO-8859-1 等。 它看似小眾，卻是很多程式的基礎組件。如果你曾安裝過 Python 的 requests 庫，它很可能已經在你的電腦上默默執行。此前有資料統計，chardet 單年度下載量達到 8.54 億次。 該庫最早由開發者 Mark Pilgrim 在 2006 年創建，並使用 LGPL 授權發布。 熟悉開源授權的開發者想也不陌生，LGPL 允許修改與分發，但對二次分發與商業使用有嚴格限制，衍生作品通常需繼續使用相同授權。 原作者在維護多年後，於 2011 年完全退出公眾視野，chardet 的維護工作由其他人接手。 其中 Dan Blanchard 是最重要的維護者之一，他負責自 2012 年 7 月 chardet 1.1 版以來的每個版本，貢獻了接近 700 次提交。而排名第二的維護者只有 48 次。

在 Claude 的協助下，維護者用 5 天完成對 chardet 庫的全面重寫。 時間來到上週，Dan Blanchard 發布了 chardet 7.0 版本，並在 GitHub 頁面上聲稱這是一次「完全重寫的版本，採用了 MIT 授權」。 同時，他表示，該庫的包名和公開 API 保持不變——可直接取代 chardet 5.x/6.x，速度更快，準確度更高。支援 Python 3.10 及以上版本，無任何執行時依賴，可在 PyPy 上運行。

問題來了，MIT 授權比 LGPL 寬鬆很多，你可以自由使用、修改、複製和散佈軟體，包括將其用在商業軟體中，只要保留原作者版權聲明即可。 至於為何要變更授權，Dan Blanchard 在接受外媒採訪時表示，長期以來，他希望 chardet 能進入 Python 標準庫，但受限於舊授權、效能與準確率，此外也因為時間有限，始終無法推進。 「如今，Claude 讓我在大約 5 天內就能完成我想做的事情」，Dan Blanchard 說。 因此，他借助 Claude Code 重寫了 chardet 7.0 版本，並將其發布出來。

原作者「閃現」抗議：拒絕對原始程式碼的非法重新授權。 就在新版本發布兩天後，一個暱稱為 Mark Pilgrim 的用戶在 GitHub 上發文稱，自己就是 chardet 的原作者，感謝長期維護者與貢獻者，但 Dan Blanchard 將 7.0 版本以 MIT 授權發布，屬於對 LGPL 程式碼的非法重新授權，直接違反開源協議。 他明確反對此次授權變更。 以下是他在 GitHub issue 中提交的完整內容： 您好，我是 Mark Pilgrim。您或許還記得我寫過的一些經典作品，例如《深入淺出 Python》以及「Universal Character Encoding Detector」。我也是 chardet 的最初作者。 首先，我想感謝目前的維護者，以及這些年來所有為此項目做出貢獻並持續改進它的人。這確實是自由軟體成功發展的典型案例。 不過，近來有人提醒我，在 7.0.0 版本的發布中，維護者聲稱他們有權對此項目進行「重新授權（relicense）」。事實上，他們並沒有這樣的權利；這樣做是對 GNU Lesser General Public Licence（LGPL）的明顯違反。 根據 LGPL 的規定，對已授權程式碼進行修改後發布時，仍必須繼續使用相同的 LGPL 授權。維護者聲稱這是一次「完全重寫（complete rewrite）」，但這並不成立，因為他們曾經大量接觸過原始的授權程式碼（換句話說，這並不是所謂的「乾淨室實作」，即完全隔離、未接觸原始程式碼的獨立實作）。即使在開發過程中加入了某種複雜的程式碼生成器，也不會因此自動獲得額外的授權權利。 因此，我在此郑重要求他們將項目的授權恢復為最初的版本。

到底是誰的程式碼？誰有最終發言權？ 首先簡單解釋一下 Mark Pilgrim 在聲明中提到的「乾淨室」。 計算機工程師和程式設計師長期以來依賴逆向工程來實現程式功能，而不直接複製受版權保護的原始程式碼。簡單來說，就是在不侵犯版權的前提下「模仿」軟體的行為與功能。過去，這種做法通常遵循所謂的「潔淨房間（clean room）」原則：由完全不接觸原始程式碼的人重新實現功能，以確保產生的新程式碼不會構成原作的衍生作品。 Blanchard 在回應中承認，自己維護 chardet 已超過十年，確實長期接觸過原始程式碼庫。 傳統的 clean-room 方法通常要求嚴格區分兩組人：一組了解原始實現，另一組負責編寫新的實現，而兩者之間必須完全隔離。 客觀來說，在這個項目中，Blanchard 並未滿足「clean-room」的隔離要求。 但他認為，clean-room 方法本身只是一種手段，其目的在於確保最終產生的程式碼不是原始程式碼的「衍生作品」。換句話說，clean-room 是達到目標的一種方式，但並不是目標本身。 在這種情況下，他可以透過直接的技術測量來證明最終結果達成了同樣的目標——新的程式碼在結構上獨立於舊程式碼，而不僅僅依賴開發流程的保證。 基於此，他使用程式碼相似度檢測工具 JPlag 提供數據來證明：chardet 7.0 版本的檔案與 6.0 版本對應檔案的最大相似度僅 1.29%；而 5.2 版本到 6.0 版本則有些檔案相似度高達 80%。

Blanchard 強調，他從零開始建立了新的程式碼庫，沒有直接搬運任何舊檔案。 如果僅僅因為曾經接觸過原始程式碼就足以否定一次重寫，那麼對於任何 LGPL 項目的維護者來說，未來想在不同授權下重新實現相同功能幾乎會變得不可能——無論最終寫出的程式碼與原始程式碼有多麼不同。 我不認為 LGPL 的要求是這樣的，但我也願意聽取不同的解讀。在我看来，核心問題在於：新的程式碼是否來源於舊程式碼（是否屬於衍生作品）。而從前面提到的證據來看，它並不是。

AI 如何參與 為了保持完全透明，Blanchard 進一步分享了此次重寫的具體過程： 我使用了 Claude 的「superpowers brainstorming」能力來生成一份設計文檔，其中詳細說明了我希望採用的架構與實現思路。 這份設計基於我為此次重寫設定的一系列需求（這些需求最初是我在手機的 Notes 內寫下的，未提交到倉庫中，但我在此列出作為背景說明）： 對外 API 保持相容 專案仍稱 chardet，因為計畫是用新實現取代原有的 chardet 不基於任何 GPL 或 LGPL 程式碼 在測試資料上保持與 chardet 相當的編碼偵測準確率 語言偵測不是硬性需求，但如果實現起來很容易，或是其他設計的副產品，可順便實現 高效能、記憶體使用效率高：能有效利用多核 CPU 無任何執行時依賴 必須同時支援 PyPy 與 CPython 設計要乾淨、現代化 若使用訓練得到的統計模型，資料來源應使用 Hugging Face 的 load_dataset API 任何訓練程式碼應在本地快取資料，以便在開發過程中頻繁重新訓練 定期進行效能基準測試 避免使用大量巨大的字典直接量，因為在 CPython 3.12 中匯入此類結構會非常慢 之後，Blanchard 表示，他在一個完全空的倉庫中開始開發，且未存取舊程式碼庫。同時，他還明確指示 Claude：不要基於任何 LGPL 或 GPL 授權的程式碼進行實現。 接著，他本人使用 Claude 對生成的每一部分程式碼進行審查、測試與反覆迭代。 不過，Blanchard 也坦言，自己並沒有逐行手寫這些程式碼，但在整個過程中，他深度參與了架構設計、程式碼評審以及每一步的迭代改進。 我理解這確實是一個新的、讓人不太適應的領域：在一個長期存在的開源項目重寫過程中使用 AI 工具，確實會引發合理的疑問。不過，從現有證據來看情況很清楚：7.0 是一個獨立作品，而不是基於 LGPL 程式碼庫的衍生作品，因此使用 MIT 授權是正當的。

爭議點：AI 生成程式碼的邊界難以界定 儘管 Blanchard 力求獨立生成程式碼，但仍存在一些複雜因素。 首先，有網友發現，Claude 在重寫 chardet 7.0 版本時，明確使用了 chardet 早期版本的一些中繼資料檔案，這引發了業界開發者對此新版本是否真的算是「衍生版本」的質疑。

另一方面，Claude 模型在訓練時吸收了大量公開網路資料，其中可能包含早期 chardet 的開放原始碼。是否意味著 AI 生成的程式碼屬於原作的衍生品，仍存有爭議。 此外，還有人為因素。雖然新版本的程式碼是由 Claude 生成的，但正如上文所述，Blanchard 表示他「使用 Claude 對結果的每個部分進行審查、測試與迭代……我沒有親手編寫程式碼，但我深度參與了程式碼的設計、審查與迭代的每個環節。」 讓一位對早期 chardet 程式碼非常熟悉的人這麼深入地參與新程式碼的審查，也可能影響此版本是否可被視為全新的項目。

網友觀點 此事件在開源社群引發廣泛討論，直指 AI 時代的底層規則真空。 有人為維護者 Blanchard 所受到的指控辯護： Blanchard 獨自維護此庫，沒有資金、沒有協作者、沒有支援。chardet 團隊另外兩人最晚在 2017 年停止維護，其中一人在 2012 年後再無提交。原作者 2011 年完全清除網路痕跡。這是 Python 生態最依賴的套件之一，全靠一人利用業餘時間維持。現在這個人做了大家不喜歡的事，突然所有人都對治理、託管、自由軟體精神高談闊論。 亦有使用者 Armin Ronacher 撰寫了一篇《AI 與忒修斯之船》。他將 AI 重寫視為終於擺脫 GPL 的出路 —— 他認為 GPL 限制了分享： 「如果你拋棄所有程式碼從零開始，即便最終行為一致，那也是一艘新船。」 然而，許多網友認為： 「把 Copyleft 程式碼餵給訓練過它的模型，讓模型產生功能等價的產物，然後指著輸出說「看，沒有相似性」。查重工具找不到匹配的 token，並不代表作品獨立，只代表洗白有效。如果這套做法合法，現存所有 Copyleft 項目，只要跑一次 Claude 就能變成 MIT，甚至閉源。正反皆可行。」 在 GitHub 討論區中，更有人犀利地評論道：將洩漏的 Windows 原始碼丟給大型模型重寫，再以開源方式發布，能否接受？如果不能，請解釋為什麼 chardet 不同。機制完全相同，唯一的變數是你是否同情版權方。 自由軟體基金會（FSF）執行董事 Zoë Kooyman 直言：「AI 模型吸收了要重新實現的程式碼，因此根本不存在真正的『乾淨』。」 一方面是經典開源協議的底線，另一方面是 AI 輔助開發的新現實；在原作者消失、單人維護十年後，專案歸誰？新版 chardet 的授權究竟誰有最終發言權，你怎麼看？ 參考：

https://github.com/chardet/chardet

https://github.com/chardet/chardet/issues/327#issuecomment-4005195078

https://shiftmag.dev/license-laundering-and-the-death-of-clean-room-8528/

https://www.theregister.com/2026/03/06/ai_kills_software_licensing/

https://arstechnica.com/ai/2026/03/ai-can-rewrite-open-source-code-but-can-it-rewrite-the-license-too/