Claude 5天重寫老庫引全網爭議，維護者擅自更換開源協議，退網15年原作者突然現身：不準改！

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

花 5 天時間借助 Claude Code 重寫運營十余年的老舊代碼庫后，項目維護者直接將開源許可證從 LGPL 改為更寬松的 MIT。

近日，Python 經典編碼檢測工具 chardet 因此陷入輿論中心。

更具戲劇性的是，這個庫的新版發布后，自 2011 年便淡出公眾視野的原作者突然現身，要求項目維護者立刻將許可改回原版。

然維護者堅稱，新版本是用 AI 從零開始寫的，與舊版本無關。

至此，一場關于 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。你也許還記得我寫過的一些經典作品，比如《Dive Into Python》以及“Universal Character Encoding Detector”。我也是 chardet 的最初作者。

首先，我想感謝目前的維護者，以及這些年來所有為這個項目做出貢獻并不斷改進它的人。這確實是一個自由軟件成功發展的典型案例。

不過，最近有人提醒我，在 7.0.0 版本的發布中，維護者聲稱他們有權對這個項目進行“重新授權（relicense）”。實際上，他們并沒有這樣的權利；這么做是對 GNU Lesser General Public License（LGPL）許可的明確違反。

根據 LGPL 的規定，對已授權代碼進行修改后發布時，仍然必須繼續使用同樣的 LGPL 許可證。維護者聲稱這是一次“完全重寫（complete rewrite）”，這一點并不成立，因為他們曾經大量接觸過原本的授權代碼（也就是說，這并不是所謂的“clean room 實現”，即完全隔離、未接觸原代碼的獨立實現）。即使在開發過程中加入了某種復雜的代碼生成器，也不會因此自動獲得額外的授權權利。

因此，我在此鄭重要求他們將項目的許可證恢復為最初的版本。

到底是誰的代碼？誰說了算？

首先簡單解釋一下 Mark Pilgrim 在聲明中提到的“clean room”。

計算機工程師和程序員長期以來依賴逆向工程來實現程序功能，而不直接復制受版權保護的原始代碼。簡單來說，就是在不侵犯版權的前提下“模仿”軟件的行為和功能。過去，這種做法通常遵循所謂的“潔凈房間（clean room）”原則：由完全不接觸原始代碼的人重新實現功能，以確保生成的新代碼不會構成原作的衍生作品。

Blanchard 在回應中承認，自己維護了 chardet 超過十年了，確實長期接觸過原始代碼庫。

傳統的 clean-room 方法通常要求嚴格區分兩組人：一組了解原始實現，另一組負責編寫新的實現，而兩者之間必須完全隔離。

客觀的說，在這個項目里，Blanchard 并不滿足「clean-room 」這樣的隔離要求。

但是他認為，clean-room 方法本身只是一種手段，它的目的在于確保最終產生的代碼不是原始代碼的“衍生作品”。換句話說，clean-room 是達到目標的一種方式，但并不是目標本身。

在這次情況下，他可以通過直接的技術測量來證明最終結果達到了同樣的目標——新的代碼在結構上是獨立于舊代碼的，而不僅僅依賴開發流程上的保證。

基于此，他用代碼相似度檢測工具 JPlag 給出數據證明：chardet7.0 版本的文件與 6.0 版本的對應文件，最大相似度僅1.29%；而 5.2 版本到 6.0 版本則有些文件相似度高達 80%。

Blanchard 強調，他從零開始創建了新的代碼庫，沒有直接搬運任何舊文件。

如果僅僅因為曾經接觸過原始代碼就足以否定一次重寫，那么對于任何 LGPL 項目的維護者來說，未來想在不同許可證下重新實現相同功能幾乎都會變得不可能——無論最終寫出的代碼與原代碼有多么不同。

我不認為 LGPL 的要求是這樣的，但我也愿意聽取不同的解讀。在我看來，核心問題在于：新的代碼是否來源于舊代碼（是否屬于衍生作品）。而從前面提到的證據來看，它并不是。

AI 如何參與

為了保持完全透明，Blanchard 進一步分享了這次重寫的具體過程：

我使用了 Claude 的 “superpowers brainstorming” 能力來生成一份設計文檔，里面詳細說明了我希望采用的架構和實現思路。

這份設計基于我為這次重寫設定的一系列要求（這些要求最初是我在手機的 Notes 里寫下的，沒有提交到倉庫中，但我在這里列出來作為背景說明）：

1. 對外 API 保持兼容
   

2. 項目仍然叫 chardet，因為計劃是用新實現替換原有 chardet

3. 不基于任何 GPL 或 LGPL 代碼

4. 在測試數據上保持與 chardet 相當的編碼檢測準確率

5. 語言檢測不是硬性要求，但如果實現起來很容易，或者是其他設計的副產品，可以順帶實現
   

6. 高性能、內存效率高：能夠有效利用多核 CPU

7. 沒有運行時依賴

8. 必須同時支持 PyPy 和 CPython

9. 設計要干凈、現代化

10. 如果使用訓練得到的統計模型，數據來源應使用 Hugging Face 的 load_dataset API
    

11. 任何訓練代碼都應在本地緩存數據，以便在開發過程中頻繁重新訓練

12. 經常進行性能基準測試

13. 避免使用大量巨大的字典字面量，因為在 CPython 3.12 中導入這類結構會非常慢

之后，Blanchard 表示，他在一個完全空的倉庫中開始開發，并且沒有訪問舊代碼庫。同時，他還明確指示 Claude：不要基于任何 LGPL 或 GPL 許可的代碼進行實現。

接下來，其本人使用 Claude 對生成的每一部分代碼進行審查、測試和反復迭代。

不過，Blanchard 也坦言，自己并沒有逐行手寫這些代碼，但在整個過程中，他深度參與了架構設計、代碼評審以及每一步的迭代改進。

我理解這確實是一個新的、讓人不太適應的領域：在一個長期存在的開源項目重寫過程中使用 AI 工具，確實會引發合理的疑問。不過，從現有證據來看情況是清楚的：7.0 是一個獨立作品，而不是基于 LGPL 代碼庫的衍生作品，因此使用 MIT License 是正當的。

爭議點：AI 生成代碼的邊界難界定

盡管 Blanchard 力求獨立生成代碼，但仍存在一些復雜因素。

首先，有網友發現，Claude 在重寫 chardet 7.0 版本時，明確使用了 chardet 早期版本的一些元數據文件，這引發了業界開發者對這個新版本是否真的是“衍生版本”的質疑。

另一方面，Claude 模型在訓練時吸收了大量公開網絡數據，其中可能包括早期 chardet 的開源代碼。是否意味著 AI 生成的代碼屬于原作衍生，仍存在爭議。

此外，還有人為因素。雖然新版本的代碼是由 Claude 生成的，但正如上文提到的，Blanchard 表示他“使用 Claude 對結果的每個部分進行了審查、測試和迭代……我沒有親手編寫代碼，但我深度參與了代碼的設計、審查和迭代的每一個環節。” 讓一位對早期 chardet 代碼非常熟悉的人如此深入地參與新代碼的審查，也可能影響到這個版本是否可以被視為一個全新的項目。

不止如此，Blanchard的所有操作都是在chardet 這個庫的同一個軟件包名稱、同一個存儲庫、同一個PyPI 列表中完成的，更重要的是新版本的名字還是叫做 chardet。

網友看法

這起事件在開源社區引發廣泛討論，直指 AI 時代的底層規則空白。

有人為維護者 Blanchard 所受到的指責辯護：

Blanchard 獨自維護這個庫，無資金、無協作者、無支援。chardet 團隊另外兩人最晚 2017 年就停更，其中一人 2012 年后再無提交。原作者 2011 年徹底清空互聯網痕跡。這是 Python 生態最依賴的包之一，全靠一個人用業余時間撐著?，F在這個人做了大家不喜歡的事，突然所有人都對治理、托管、自由軟件精神高談闊論。

也有用戶 Armin Ronacher 寫了一篇《AI 與忒修斯之船》。他把 AI 重寫看作終于擺脫 GPL 的出路 —— 他認為 GPL 限制了分享：

如果你扔掉所有代碼從零開始，即便最終行為一致，那也是一艘新船。

不過，有不少網友認為：

把 Copyleft 代碼喂給訓練過它的模型，讓模型生成功能等價產物，指著輸出說 “看，沒有相似性”。查重工具找不到匹配 token，不代表作品獨立，只代表洗白有效。如果這套手法合法，現存所有 Copyleft 項目，只要跑一次 Claude 就能變成 MIT，甚至閉源。正反都行得通。

GitHub 討論區里，更有人犀利地點評道：把泄露的 Windows 源碼丟給大模型重寫，再以開源發布，能接受嗎？如果不能，解釋 chardet 為何不同。機制完全一樣，唯一變量是你是否同情版權方。

自由軟件基金會（FSF）執行董事 Zo? Kooyman 直言：“AI 模型吸收了要重新實現的代碼，因此根本不存在真正‘潔凈’?！?/p>

一方是經典開源協議的底線，一方是 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/

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯合主辦「2026 奇點智能技術大會」將在上海隆重召開，大會聚焦 Agent 系統、世界模型、AI 原生研發等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術大會上海站，我們不見不散！