我以為 MIT 是麻省理工：給 Vibe Coder 的 License 入門筆記

開場：那些年我以為的 License

老實說，2012年我開始想學程式的時候，影片教學先從 fork 一個專案開始，裡面就有 LICENSE 檔案，看了兩行就納悶。心裡想說，啊這不就是法律條款嗎？跟我有什麼關係？教學不是就教 fork 一個專案來練習而已嗎？

然後當我看到一個叫做「MIT」的 License，我真的以為那是麻省理工學院的專利。我還想說，哇這個專案好厲害喔連麻省理工都有參與。後來才知道，那是源自 1980 年代 MIT 的 X Window System 專案，後來慢慢演變成現在我們看到的版本。跟今天的麻省理工其實沒什麼直接關係了。

更慘的是，我還曾經把 Apache 當成美洲原住民的名字（雖然一開始命名確實有相關），甚至 GPL 當成某個電信公司縮寫（GNU General Public License，跟通訊業完全沒關係），直到去年開始認真學習 Vibe Coding 並且看了慕約 365 AI 訂閱後，我才想要花時間去搞懂這些到底是什麼。

如果你也有過類似的尷尬時刻，這篇文章就是寫給你的。

這篇文章想做三件事：讓你看得懂各種 License 在幹嘛、知道自己的專案該選什麼、以及，最重要的，不要再看到 License 就緊張。

先誠實講一件事～為了寫這篇文章，我也是第一次認真搞懂 SSPL、BSL、OpenRAIL 這些冷門的東西。所以這篇不是什麼專家指南，比較像是一份學習筆記。我們一起補課。

§ 1. 為什麼 Vibe Coder 該在乎 License？

先講一個冷知識：如果一個 GitHub 專案沒有放 License 檔案，嚴格來說，你連 fork 都不能 fork。（ 理論上是這樣，但感謝提醒，我補在文章最後面了。 ）

我知道這聽起來很荒謬。但著作權法的預設是「保留所有權利」。作者寫出程式碼的那一瞬間，著作權就歸他所有。沒寫 License，那預設答案就是「不可以呦！」。

根據研究，GitHub 上將近一半的公開 repo 沒放 License。這些程式碼你隨便用，嚴格來說都踩線，所以其實你認真看一下repo上面有些 issue ，都會特別請原作者增加相關的 License 但是我不知道大家有沒有特別注意到這件事情 。

不信 License 很重要？那講個真實故事。

2017 年，Facebook 在 React 的 License 裡加了一條「如果你對 Facebook 發動專利訴訟，React 授權自動作廢」。結果 Apache 軟體基金會看不下去，直接把這個 License 列為「Category X」，禁止所有 Apache 專案使用 React。連全球超過四成網站使用的 WordPress 共同創辦人 Matt Mullenweg 都跳出來說要把 React 換掉。

順便解釋一下「Category X」是什麼。Apache 基金會內部把第三方 License 分三級：Category A 是隨便用（MIT、BSD 這種）、Category B 是有條件可以用（MPL 這種弱傳染）、Category X 就是黑名單，所有 Apache 專案碰都不能碰。平常被點名到 X 的多半是 GPL / LGPL / AGPL 家族或帶詭異條款的授權。Facebook 的 BSD+Patents 能擠上這份名單，等於被蓋了個「你這 License 太危險」的章。

結果呢？Facebook 認輸了。兩個月後就把 React 改回乾淨的 MIT License。

一條 License 條款，可以讓一個全世界最大社群平台的公司低頭。所以如果你覺得 License 只是形式，那你低估它了。

還有一個 Vibe Coder 最常問的問題：「我可以直接 fork 別人的專案，然後拿去販售嗎？」

這個問題的答案其實不是 Yes 或 No，而是「要看你 fork 的是哪張 License」。我們在後面每一個 License 類別裡，都會順便回答這個問題。

§ 2. License 大地圖：五大類一次看懂

在深入每一張 License 之前，我們先看地圖。所有的 License 其實可以放在一個光譜上：

光譜最左邊是「你愛怎麼用就怎麼用」，最右邊是「看一眼都要付錢」。然後中間漸層是「我給你用，但有條件」。

整理成五大類，大概長這樣：

Vibe Coder 最常碰到的是 A 和 B，最容易忽略的是 D 和 E（我自己就完全沒聽過）。我們一組一組來看。

§ 3. 寬鬆派：Vibe Coder 最常遇到的三兄弟

寬鬆派有三個主角：MIT、BSD、Apache 2.0。差別在於「寬鬆到什麼程度」跟「有沒有額外保障」。

用租房的比喻來解釋最清楚。

MIT：掛房東名牌的便宜公寓

MIT License 的條款短到一張便條紙就寫得完，整份英文版不到 200 個字。核心意思只有一句：你要用、要改、要商業販售、要做任何事都可以，只要門口掛著我（房東）的名字。

你甚至可以把 MIT 程式碼整碗端走變成閉源商業產品（只要有保留原作者的著作權聲明）。這就是為什麼全世界有將近三分之一的 GitHub 專案用 MIT。因為對開發者跟商業公司都最友善。

代表專案：React、Vue、Next.js、Tailwind CSS、jQuery。你可能每天都在用 MIT 授權的東西，只是你完全沒有感覺而已。

BSD 3-Clause：MIT ＋ 不准用我招牌背書

BSD 3-Clause 幾乎跟 MIT 一模一樣，就多一條「你不能用我或我貢獻者的名字，來幫你的衍生產品背書」。

翻成人話：你改了我的程式做成新產品要賣可以，但廣告上不能說「這是某某大神參與的產品」。除非你有得到我同意。（ 意思就是出事了也不關我的事 XD ）

代表專案：FreeBSD、Nginx、PostgreSQL（其實 PostgreSQL 有自己專屬的 License，本質類似 BSD 和 MIT）。

Apache 2.0：MIT ＋ 專利保險

Apache 2.0 把 MIT 的基礎再加了兩個東西：專利條款和商標條款。

專利條款是什麼意思？如果我貢獻了一段程式碼給 Apache 專案，我等於同時授權你使用我的相關專利。但如果你反過來告我（或其他貢獻者）專利侵權，你的授權就自動作廢。

白話就是：這是一個「我不告你，你也不能告我」的互不侵犯條約。

代表專案：Kubernetes、Android（核心部分）、TensorFlow、Apache 一整個家族。

能 fork 寬鬆派拿去賣嗎？

可以，而且完全合法。

你 fork React 做成一個 UI 框架拿去賣訂閱制、fork Vue 做成一個閉源的企業版、fork Kubernetes 整個包成自己的雲端服務收錢，全部都可以。

唯一的條件：保留原作者的版權聲明和 License 檔案。就這樣。

這也是為什麼寬鬆派被商業公司寵愛。AWS / Azure / Google Cloud 一大堆商業服務底層都是 MIT / Apache 2.0 的東西，然後外面包一層付費介面賣錢。合法、常見、不會被詬病（ 呃～至少不會被法律詬病啦 ）。

§ 4. 傳染派：GPL 家族，溫柔的病毒

如果說寬鬆派像是「隨便住，留個名就好」，那傳染派就像是「你住可以，但你改裝之後，下一個租客也要能自由改裝」。

這裡面最有名的就是 GPL（GNU General Public License），它最大的特色就是傳染性。用阿嬤的食譜來比喻：

阿嬤的食譜

阿嬤把紅燒肉食譜傳給你，但有一個規矩：你可以用、可以改良、可以免費教給任何人。但你改良過的版本，也必須免費教給任何想學的人。你不能把改良版鎖進家族秘笈，自己開餐廳賺錢。

這就是 GPL。你用了 GPL 的程式碼，你改出來的東西也必須以 GPL 釋出。

傳染範圍從輕到重，分成四種：

• LGPL：只傳染到 library 本身。你動態連結可以逃，靜態連結會被抓。

• MPL 2.0：檔案級傳染。你改到哪個檔案，哪個檔案就要開源。沒動的檔案不受影響。

• GPL v2 / v3：整包傳染。你的專案只要連結了 GPL 程式，整個專案都要 GPL。

• AGPL：連 SaaS 也傳染。這個是為了堵住雲端大廠白嫖開源軟體的漏洞設計的。

Linux kernel 的特例

Linux kernel 用 GPL v2，但 Linus Torvalds （我應該不用解釋他是誰吧？ XD）很聰明地加了一個叫 syscall exception 的豁免條款。意思是：你跑在 Linux 上面的用戶空間程式，不會被 GPL 傳染。

如果沒有這條豁免，那所有在 Linux 上跑的商業軟體（包括你電腦裡的 Chrome、VS Code、各種 app）全部都要開源。那 Linux 早就沒有今天的生態了。

為什麼企業法務看到 GPL 會心臟病發

對公司來說，GPL 是一個惡夢。只要工程師不小心 npm install 了一個 GPL library，公司產品整包都要開源。對商業機密就是核彈級災難。所以很多公司內部會有「開源 License 黑名單」，GPL 第一個上榜。

順便講一個商業實務的冷知識：很多公司用 GPL 搭配「雙授權」（Dual Licensing）模式。像是 MySQL、Qt。意思是：你想免費用，就接受 GPL 的傳染；你想閉源商用，花錢跟我買商業授權。

一石二鳥。這就是開源也能賺錢的路之一。

冷知識彩蛋：Rust 為什麼雙授權？

你去看 Rust 生態系的 crate，絕大部分會寫 MIT OR Apache-2.0。這不是作者決定困難症，這是生態系的智慧。

為什麼？因為 Apache 2.0 提供專利保護，但跟 GPL v2 不相容；MIT 夠寬鬆可以跟 GPL v2 相容，但沒有專利保護。兩個都掛上去，使用者想挑哪個就哪個，可以跟任何專案接軌。

這招聰明到整個 Rust 社群都模仿。如果你在思考自己的 side project 要用什麼 License，MIT OR Apache-2.0 是一個非常穩的選擇。

老師我有問題：能 fork 傳染派拿去賣嗎？

可以，但有個大陷阱。

GPL 其實沒禁止你拿去販售。你可以把 Linux kernel 燒成光碟賣錢，沒人攔你。但是有一個關鍵條款：買你軟體的人，有權拿到原始碼，而且他拿到之後可以免費散布給任何人。

也就是說：你賣第一份可能有人買，但對方拿到之後放上 GitHub，第二份之後就沒人會跟你買了。

所以純靠「賣 GPL 軟體」賺錢幾乎不可能。但有兩條變形路線：

• 賣服務：Red Hat 賣的不是 Linux（Linux 免費下載），賣的是技術支援、訂閱升級、安全修補。這是 Red Hat 年營收超過 60 億美元的商業模式。

• 雙授權：像 MySQL 那樣，GPL 版免費 + 商業版收費，讓不想被傳染的公司花錢買解脫。

§ 5. 最有戲的章節：付費可見派的 License 戰爭

終於寫到這一組。

坦白講，在寫這篇文章之前，我根本不知道有這一派 License 存在。MongoDB 改授權我是知道的（大概吧…），但 SSPL、BSL、FSL、ELv2 這些縮寫，我只有查資料時才第一次搞懂它們在講什麼。

所以如果你也沒聽過，這非常正常，不要覺得自己很遜，這個領域是圈內才會在意的冷門地帶。

背景：雲端大廠白嫖事件

過去十年，AWS、Google Cloud、Azure 這些雲端巨頭做了一件事：把開源軟體包成 managed service，讓使用者按月付費用，但不回饋社群任何東西。

對開源專案的商業公司來說，這等於是白嫖。你辛辛苦苦維護專案，結果 AWS 把你的產品包一包變成自己的服務賺錢。

於是一連串的反擊開始了。

四大戰役時間線

2018 年 10 月：MongoDB → SSPL

MongoDB 是開第一槍的。他們從 AGPL v3 改成自己設計的 SSPL（Server Side Public License），要求：你如果要把 MongoDB 包成服務給別人用，你要把整個服務架構的原始碼全部開源（包括管理軟體、監控系統、備份工具）。

實際上就是擋 AWS 的 DocumentDB（AWS 的 MongoDB 相容服務）。但這個 License 太辣，OSI（Open Source Initiative，開源認證最大的機構）拒絕認可 SSPL 是開源。

2021 年 1 月：Elastic → SSPL + ELv2

Elastic（Elasticsearch 的公司）看 MongoDB 這招不錯，也跟進。從 Apache 2.0 改成 SSPL / ELv2 雙授權。

然後社群就 fork 了。AWS 直接 fork 出 OpenSearch，至今都還在維護。

有趣的是 2024 年 Elastic 又加回 AGPL v3，宣稱「回歸開源」。兜了一大圈。

2023 年 8 月：HashiCorp → BSL

HashiCorp 把 Terraform 從 MPL 2.0 改成 BSL 1.1（Business Source License，商業源碼授權）。BSL 的特色是有時間限制，限制期過了（通常 3 到 4 年）會自動變回開源。

社群炸了。OpenTofu manifesto 發起，HashiCorp 拒絕讓步，於是社群 fork 最後一版 MPL 的 Terraform 1.5.6，叫做 OpenTofu，捐給 Linux Foundation。

HashiCorp 寄存證信函說 OpenTofu 偷代碼，OpenTofu 反擊成功。2024 年 4 月 IBM 宣布以 64 億美元收購 HashiCorp，2025 年 2 月正式完成併購。故事還在繼續進行。

2024 年 3 月：Redis → SSPL + RSALv2

Redis（對，就是那個幾乎每個後端工程師都碰過的 Redis）從 BSD 改成 SSPL / RSALv2 雙授權。

社群反擊速度創紀錄：30 天內 Linux Foundation 接手成立 Valkey 專案，AWS、Google Cloud、Oracle、Ericsson 全部加入。一年內 Valkey 擴展到近 50 個貢獻企業。

這些 License 到底差在哪

最重要的一句話

新手在這裡一定要記住一件事：「開源」不等於「OSI 認可的開源」。

你在 GitHub 上看到「原始碼公開」的專案，不代表它是開源。SSPL、BSL、ELv2 都能看、能改、能散布，但它們不是 OSI 定義的開源（因為對商業用途設限）。

這個區別可能影響你能不能商用。下次看到不熟的 License，先去 OSI 官網查一下它有沒有被認可。

所以能 fork 付費可見派拿去賣嗎？

這才是重點：大部分情況不行，特別是做 SaaS 服務。

這派 License 存在的意義就是擋你做商業競爭。舉幾個實際情境：

• 你想 fork Redis（SSPL 版本）做一個 managed Redis 雲端服務賣錢？違反 SSPL，除非你把整套服務架構（包含監控、備份、前端介面等）全部以 SSPL 開源。

• 你想 fork Elasticsearch（ELv2 版本）做 search-as-a-service？違反 ELv2。

• 你想 fork 舊版 Terraform（BSL 限制期內）做 IaC 託管服務？違反 BSL。但你等 4 年後 BSL 自動轉成 MPL，那時候就可以了。

這也是為什麼 AWS、Google 這些雲端大廠都選擇 fork 出新專案（OpenSearch、Valkey、OpenTofu）繼續維護，而不是硬上違反 License 的路。他們是大公司，有律師團，違約成本算得很清楚。

對個人 Vibe Coder 來說：看到 SSPL / BSL / ELv2 / FSL，想商業用之前先把條款從頭到尾讀一遍。這不是那種「掛版權聲明就好」的寬鬆派。

§ 6. AI 時代的新挑戰

2022 年之後，AI 爆炸式發展，License 界也出現了新物種。

OpenRAIL：有倫理限制的 AI 授權

OpenRAIL（Open Responsible AI Licenses）是 Hugging Face 和 BigScience 研究聯盟在 2022 年 5 月首次推出的新型授權，第一個案例是 BLOOM 模型（BLOOM RAIL v1.0）。

它跟傳統開源 License 最大的不同：行為限制條款。

翻成白話：你可以拿去用、改、商用，但不能用於特定用途（比如大規模監控、仇恨言論生成、提供醫療診斷卻不聲明自己不是醫生等等）。

OSI 的態度是：這不算開源。因為違反 OSD（Open Source Definition）第 5 條和第 6 條「不得歧視使用者或使用領域」。但 Hugging Face 的回應是：AI 有獨特的風險，傳統開源定義不夠用。

這個辯論到現在還沒結束。

為什麼 Meta Llama 不是開源？

相信很多人都會很意外：Meta 的 Llama 2、Llama 3 都不是真正的開源。

雖然 Meta 很愛用「Open Source」這四個字行銷，但 Llama 的 Community License 有三個硬限制：

1. 月活用戶上限：商業免費使用限 7 億 MAU 以下。超過要另外談授權。

2. 競品限制：禁止用 Llama 來訓練或改進其他 AI 模型（擋競爭對手）。

3. field of use 限制：違反 OSD 第 6 條。

OSI 明確發聲明：Llama 不是開源。這件事在 AI 圈吵得沸沸揚揚。

2024 年 10 月的大事：OSAID

這個消息可能很多人不知道：2024 年 10 月，OSI 發布了 OSAID（Open Source AI Definition），史上第一次正式定義「開源 AI」。

OSAID 要求一個 AI 系統要被稱為「開源」必須滿足：模型權重公開、訓練程式碼公開、訓練資料資訊公開（三個全部都要）。

結果是：目前幾乎沒有任何主流 LLM 達標。OpenAI、Google Gemini、Meta Llama、Anthropic Claude 全部都不合格。

所以當有人跟你說「這是開源 AI」，你可以先問他：OSAID 合格嗎？我只能說～呵呵～笑死 XD。

隱藏議題：AI 生成的程式碼誰擁有著作權？

這題對 Vibe Coder 尤其重要。你用 Claude Code、Copilot、Cursor 寫出來的程式碼，著作權歸誰？

美國版權局 2023 年 2 月有一個裁定（Zarya of the Dawn 案）：純 AI 生成的圖像沒有著作權。但如果人類有「實質創作貢獻」，比如撰寫文字、編排、挑選組合，這個部分是有著作權的。

更複雜的是：GitHub Copilot 2022 年被集體訴訟，指控用 GPL 授權的程式碼訓練，卻讓輸出結果不帶 GPL 條款。訴訟還在跑，但這個灰色地帶是整個 AI 產業的未爆彈（ 知道這個會不會開始抖了 XD）。

能 fork AI 模型拿去賣嗎？

可以，但要看你的 app 有多紅，還有你是不是用來打造自家 AI。

以 Llama 為例，你可以 fork Llama 3 做成一個商業 app、做成客服機器人、做成 API 服務賣錢。但要注意兩個 checkpoint：

• MAU 天花板：你的服務月活用戶超過 7 億，就要另外跟 Meta 談授權。對 99.99% 的個人開發者來說這不是問題，但如果你幸運到變成 TikTok 這樣的規模，就要記得繳費。

• 禁止用來訓練競品：你不能用 Llama 來訓練或改進其他基礎模型（但實際的情形又是另外一回事了，後面我會再講到這個部分）。

如果你是 OpenRAIL 授權的模型，重點則是不能拿去做條款禁止的用途（大規模監控、仇恨言論生成等）。至於商業賺錢本身，大多數 OpenRAIL 授權沒禁止。

§ 7. 台灣視角：我們有自己的 License 嗎？

寫到這裡，我自己也好奇一件事：台灣有沒有專屬的軟體 License？

答案是：沒有。但這反而是好事，後面會解釋為什麼。

那台灣做了什麼？

雖然沒自創 License，台灣在「翻譯」和「推廣」這兩件事上做了不少。

自由軟體鑄造場（OSSF）2003–2015

這是中央研究院資訊所跟經濟部工業局合作的大專案。任務是翻譯國際 License 條款、做法律諮詢、推廣自由軟體文化。他們累積了一大堆華語資源，讓台灣工程師可以用中文搞懂 License。2015 年政策調整停辦，但遺產還在。

創用 CC（Creative Commons Taiwan）2003 至今

這個你可能在網路素材看過：「創用 CC 授權」。這是中研院主持的 CC 在台合作機構。2005 年 10 月由計畫主持人莊庭瑞帶專家會議確立「創用 CC」這個譯名，加上口號「我們創造，我們使用，我們 CC！」。

我個人覺得這個譯名比中國版的「知識共享」更有味道。「創」跟「用」同時在，很有 CC 精神。

g0v 的三層授權分工（最實用）

g0v 零時政府社群多年下來累積了一套開源分工，我覺得非常值得 Vibe Coder 直接抄：

• 程式碼 → MIT License

• 文件、插畫 → CC BY

• 設計稿（Mockup / Wireframe） → CC0

三層分工，清楚、輕便、跟國際接軌。如果你的 side project 包含文件跟設計稿，這個模板可以直接拿去用，省去自己煩惱（ 至少不用想太多 ）。

政府推廣 20 年但還綁在微軟

這個反差滿有趣的。國發會從民國 91 年就開始推廣公部門使用自由軟體，行政院也訂了〈政府資料開放作業原則〉。結果？《報導者》寫過一篇〈自願被微軟綁架的台灣政府〉，講公部門到現在還是高度依賴微軟生態。

20 幾年過去了，台灣開源推廣在民間（g0v、OCF、創用 CC）做得風風火火，政府那邊的實際落地始終緩慢。這也是台灣開源圈的集體無奈。

為什麼沒自創 License 其實是好事

開源生態是全球互通的。自創 License 會有兩個問題：一是相容性，二是認可度。

SSPL 就是活例子。設計精美，但 OSI 不認可，結果讓 MongoDB 在開源圈被孤立了好多年。

台灣走「翻譯 + 推廣 + 在地實踐（g0v 三層分工）」這條路其實非常聰明。我們不需要另一個 License，我們需要的是讓大家都看得懂現有的 License。

§ 8. Vibe Coder 實戰決策樹

講了這麼多，你終於要釋出自己的 side project。該選什麼？

釋出專案時的決策樹

四個 Yes/No 問題，就能幫你定位：

Q1. 你希望別人能商用嗎？
否 → CC BY-NC
（適合文件素材，不建議用在程式碼）
是 → 進 Q2

Q2. 你希望別人修改後的衍生物也必須開源嗎？
是 → 進 Q3
否 → 進 Q4

Q3. 這個專案會以 SaaS／網路服務提供嗎？
是 → AGPL v3
否 → GPL v3

Q4. 你需要明確的專利授權與專利終止條款嗎？
是 → Apache 2.0
否 → MIT

（ 超級感謝大家的指正，這張圖終於改對了）

4/23 GPT Image2 真的棒，圖我又重做了，其他圖先這樣吧 XD

最方便（懶）的做法：抄 g0v

如果你真的不想想這麼多，直接套用前面 §7 講過的 g0v 三層分工就好（程式 MIT、文件 CC BY、設計稿 CC0）。八成情況夠用。

能不能 fork 拿去賣？一張圖看完

我們前面每個 License 類別都講過了，這裡做一張紅黃綠燈速查：

再複習一次使用別人程式碼時的三大坑

• 坑 1：沒寫 License 不是「隨便用」，是「完全不能用」。這個很多新手會誤會。

• 坑 2：MIT 要連版權聲明一起複製。不能只把程式碼貼過去，把那段 Copyright (c) xxxx 也要帶著。不然嚴格來說你違反 MIT 條款。

• 坑 3：GPL 會傳染。不要在商業專案隨便 import GPL library。如果真的要用，先跟法務打聲招呼。

§ 8.5 但說真的：License 是防君子不防小人

講到這裡，我想跟你講一個我自己想了很久的觀點。

License 說穿了，沒有任何技術門檻。

你硬要把別人的程式碼整碗端走、改個名字上架、當作自己的作品？沒人攔得住你。GitHub 不會跳警告說「你違反 GPL 了喔」；法院打官司？開源社群的跨國訴訟案例少得可憐，成本高到勸退任何獨立開發者。

所以 License 到底在防什麼？

我覺得它防的是兩件事：防的是「不知道」，防的是「遺忘」。

讓善意的人有個依循（知道怎麼用才合規）、把作者的存在留在程式碼裡（未來某個人打開檔案，還看得到最早那個貢獻者的名字）。

真的有人端走會怎樣？

頂多就是被詬病、留下信譽污點而已。但不要小看這件事。開源圈子很小、記性很好。

React 那場 2017 年的 BSD+Patents 風暴就是證明。不是法院判的，是整個社群用輿論把 Facebook 逼到讓步。WordPress 說要換、Apache 說要禁、Fedora 說要拒。一個一個表態，最後全世界最大的科技公司之一，低頭改 License。

開源社群的真正基礎

我漸漸覺得，開源世界運作的真正基礎不是法律，是信任、尊重、互惠。

大家要的，其實只是一個尊重。

一句「我用了你的 X，幫你寫進 README 了」、一個 GitHub star、一個 PR 回饋、一聲「謝謝」。就這樣而已。

不告而取謂之賊

古人兩千多年前就講過了：不告而取謂之賊。

你想一下，你希望未來別人怎麼對待你的程式碼？直接端走、改名上架當自己的？還是好好掛你名字、跟你說一聲「欸這段我借了」？

講個反面的例子：連古人買官都有規矩

講一個更有畫面的例子。古代有一種制度叫「捐納」，就是花錢買官（清朝特別盛行，跟科舉、蔭封、保舉並列為四大仕官途徑）。這東西在今天看起來很黑，但它其實是公開的制度。

有趣的是，當時的買官交易通常會搭配一種叫「合符」或「書契」的機制。就是一張契約寫好之後從中間切開，買方拿一半、賣方拿一半。等官位真的辦下來了，兩半合對得起來，才付最後的尾款。

想想看：即使是這種被後世罵到臭頭的灰色交易，古人都還有「分一半、合對、確認交割才付款」的基本誠信機制。

反觀今天某些人，對別人的開源程式碼說抄就抄、說拿就拿，連一句「我用了你的 X」都懶得講。這連古代買官的基本禮數都不如。

選 License 是保護傘，選擇尊重是禮物

選 License 是給自己的保護傘，但選擇尊重別人的 License，是給整個社群的禮物。

感概而寫

前人開路，後人端走，有時候，真的不要讓前人心寒，有道是：

雷雨乍停天灰濛

AI 時代提燈籠

蒸餾過後殘餘燼

超英趕美偽真龍

無奈歌喉不佳，不然應該為這些前輩感嘆高歌一曲。

§ 9. 真正的收尾：開源作為程式設計師的「立言」

文章到這裡本來可以結束了。但我想再多聊一層。

《左傳·襄公二十四年》有一段很有名的話，叔孫豹講的「三不朽」：

大上有立德，其次有立功，其次有立言。雖久不廢，此之謂不朽。

古人把「立言」放在最下位。最高是立德（建立品德典範），其次立功（建立功業），最後才是立言（著書立說、留下思想）。

但我最近越想越覺得，這個排序也許是反的。

立功會過時，立德靠文字記錄，立言卻能超越時間

你想想： - 立功：你做的產品會過時、公司會倒、功業會隨時代湮滅。Nokia 做過世界第一的手機，現在呢？ - 立德：你的品德要靠後人記錄下來。但記錄本身，不就是文字、就是「言」嗎？ - 立言：寫下來的思想，反而最能穿越時間。

《論語》《道德經》能流傳兩千多年，不是因為孔子老子做了多偉大的功業或多高尚的德行。是因為有人把他們的話寫下來。甚至連「三不朽」這個觀念本身，也是靠《左傳》這本書的「立言」才流傳到今天。

這其實很諷刺。

套回程式設計師身上

• 寫出爆紅產品 = 立功（產品會死）

• 帶出優秀團隊 = 立德（團隊會散）

• 把程式碼開源 = 立言（它會永遠在 GitHub 上）

Linus Torvalds 如果當年只是寫了 Linux 卻沒把它放上 GPL，Linux 早就跟其他被封存的 side project 一樣消失了。他真正不朽的不是寫了 Linux，是把 Linux 放在 GPL 下，讓全世界都能用、能改、能延續。

他做的不只是技術選擇，是一個立言的選擇。

但這一層最被輕忽

我們寫 code，大多是為了 KPI、為了 salary、為了 launch date。我們很少會停下來問自己：

這段 code，在我離職之後還會活著嗎？在我死後 50 年還會被人讀嗎？

我們把「開源」當成技術行為，沒意識到那其實是一種「立言」的選擇。

留給你一個問題

古人把「言」放最下位。但也許，在這個程式碼能瞬間複製、永遠存檔、跨越國界流傳的時代，「立言」才是真正的千秋萬世？

下一次，當你在猶豫自己的 side project 要不要開源的時候，也許這個問題的答案，不在法律條款裡。

在你自己心裡。

結語

老實說，這篇文章也是我邊查邊寫的學習筆記。SSPL、BSL、OpenRAIL、OSAID 這些東西，我也是寫到一半才真的搞懂（我～應該～可能～有搞懂吧 XD）。所以如果你看到這裡覺得自己對 License 的理解又進步了一點點，那我們都一樣。

你不需要變成法律專家。看完這篇，你已經贏過 80% 的新手。

如果這篇對你有用，歡迎分享給也在 Vibe Coding 路上的朋友。畢竟，講到「立言」這件事，分享知識本身不就是最好的立言嗎？

補充：

2026-04-19 感謝慕約的提醒，我疏忽了這一段
GitHub 有自己的規定：

• 專案要是 public 且沒有關閉 fork 功能，別人就可以 fork。

• 一但你設成 private 或在 Settings 中關掉「允許 fork」，別人就真的無法 fork了（當然手動下載你一樣沒轍）。