你有讀過 Slack 應用程式那份將近二十七萬行的授權文件嗎？ （★ 101 分）
Slack 在 Mac 平台上的應用程式是一個基於 Electron 的桌面軟體，其中包含一個龐大的授權文件。這個檔案大小約 15.2 MB，共計 272,516 行。事實上，它並不是 Slack 自行撰寫的條款，而是因為 Slack 依賴 Chromium 內核，而 Chromium 又含有大量第三方開源程式庫，每個依賴元件都附帶自己的授權條款，因此最終集合成為這份冗長的 `LICENSES.chromium.html`。由於這些程式庫的授權內容會重複出現，例如 Apache、GPL、LGPL、MIT 等大量重疊，檔案才會暴增到近 27 萬行。此外，有開發者指出這份文件的產生方式是 Google 寫的一個 Python 腳本透過 SPDX（Software Package Data Exchange, 軟體套件資料交換制式）資訊自動生成，相當重複繁瑣，並未經過有效最佳化處理。
在 Hacker News 的討論中，有人認為這顯示了「授權地獄」（License Hell）的問題，因為法律部門不願承擔風險，導致工程師只能照本宣科、為每個依賴重複附上完整授權。相對之下，Debian 社群的作法就更有效率：同樣的授權條文只提供一次，並以識別碼（identifier）在各相依元件間交互對應，如此便可避免幾百次重複貼上相同的 Apache 2.0 或 MIT 條款。有開發者指出 Slack 那份文件中光是 Apache 2.0 的授權就出現 800 次，MIT 237 次，這是為了避免任何法律上的爭議，但技術上絕非必要。社群中有人進一步建議改用 SPDX 的標準識別碼來簡寫，或者進一步壓縮授權彙編文檔，這樣既能符合法律要求，也能減少冗餘。
部分討論轉向軟體體積與資源浪費的問題。有工程師對比早年在 10MB 硬碟上仍能編程、打遊戲、收發郵件，如今一個小工具卻動輒附帶上百 MB 不必要的檔案，感嘆現代軟體的肥大相當浪費。另外也有開發者批評 Slack 不僅授權文件臃腫，其應用程式商店政策過於嚴苛，導致開發者投入時間去開發 Slack 外掛完全不值得，因為限制很多且缺乏彈性。有人甚至建議企業考慮其他開源或付費一次的解決方案，例如 Basecamp 旗下的 Once Campfire，或是開源且可自架的 Zulip、Matrix/Element。
整體來看，這次事件凸顯的不僅是 Slack 授權文件本身的荒謬長度，更顯示出當前軟體商業化與法律風險控管帶來的副作用：為了避免最小的潛在風險，公司選擇了最保守的冗餘做法，最終反而導致使用者與硬體儲存的浪費。社群普遍認為這並非 Slack 單獨的問題，而是現今開源授權和商業軟體整合後普遍存在的結構性困境。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=45308503