Mattermost 拒絕澄清專案授權狀態

背景

Mattermost 是一個知名的協作平台，近期因其授權條款（License）表述模糊且拒絕進一步澄清，在 GitHub 與 Hacker News 上引發廣泛爭議。開發團隊在面對社群質疑時，以「目前不打算針對此類建議進行調整」的強硬態度回應，導致使用者對該專案的開源誠信與法律風險產生疑慮。

社群觀點

社群對 Mattermost 官方的回應感到不滿，特別是針對其公關用語中表現出的「企業式傲慢」。有網友指出，官方使用的「at this time」（目前）與「as such」（針對此類）等詞彙，雖然在法律上保留了未來的變動空間，但本質上是一種「承重式模糊」（load-bearing vagueness），意圖在不給予明確承諾的情況下，維持一種專業且不可侵犯的假象。這種刻意拉開距離的企業口吻，被認為是為了規避與利益相關者的直接對話，讓開發者感到被排擠。

針對授權條款本身的討論則更為激烈。許多技術人員指出，Mattermost 的授權結構極其混亂：二進位檔採用 MIT 授權，但原始碼卻宣稱「可能」適用 AGPL v3.0，同時又夾雜了 Apache 2.0 的部分組件，並保留了商業授權的選項。爭議核心在於「You may be licensed」（你可能獲得授權）這種不確定的措辭，這在法律文件上顯得極不專業且具誤導性。批評者認為，AGPL 本身並不禁止商業例外，但 Mattermost 試圖將多種互斥的邏輯縫合在一起，卻又不願給出清晰的定義，這讓企業用戶面臨極大的合規風險。有觀點認為，如果授權條款需要極高的閱讀理解能力才能勉強解讀，那它本質上就失去了開源授權保護使用者的初衷。

這種不透明的態度促使不少長期使用者考慮轉向其他替代方案。社群中多次提到 Zulip 作為首選，認為其在處理開源社群關係與授權透明度上表現更佳，儘管其獨特的線程組織方式（Topics）評價兩極。此外，也有人推薦 Rocket.Chat 或回歸最原始的 IRC 協議。部分資深開發者警告，當一個專案從「開源」轉向「開源核心」（Open Core）模式時，若處理不當，往往會演變成對社群的背叛。Mattermost 過去九個月內在文件描述上的微小改動，被視為一種緩慢的「地毯式撤換」（rug pull），旨在利用開源的名聲獲取流量，卻在法律層面築起高牆。

最後，討論也延伸到了版權蟑螂（Copyright Trolls）的議題。有網友分享了在 Creative Commons 授權下因微小的標註錯誤而被索賠的案例，藉此強調授權條款清晰度的重要性。如果一個專案的授權條款存在模糊地帶，極有可能成為法律訴訟的陷阱。對於 Mattermost 拒絕澄清的行為，社群普遍的共識是：如果官方不願意給出明確的答案，最安全的做法就是假設該軟體並非真正的開源，並在商業環境中謹慎避開。

延伸閱讀

在討論串中，社群成員推薦了幾個被認為在授權與社群經營上更為健全的替代方案，包括 Zulip、Rocket.Chat 以及 Anytype。針對 IRC 的現代化應用，則提到了 Ergo 伺服器與 Halloy、The Lounge 等客戶端。此外，關於授權陷阱的討論中，也引用了 Cory Doctorow 針對 Creative Commons 標註詐騙的深度分析文章。