把自己的公開專案從 MIT 改成 Elastic License 2.0
一個作者的法律與實務筆記
一個公開原始碼的專案，作者想改授權就能改嗎？今年五月底我把 tw-legal-rag 放上 GitHub，用的是 MIT；八月九日，我把它換成 Elastic License 2.0。中間隔了七十八天，三位外部貢獻者，還有一次把他們的程式碼全部移除再重寫的過程。
這篇不是在說 MIT 不好。是在說我當初沒想清楚的一件事，以及換授權時法律上真正卡住的地方在哪裡。如果你也維護一個有人在用的專案，這些坑比授權條文本身更值得先知道。
起點：為什麼一開始是 MIT
選 MIT 的理由很單純：我要的是曝光，不是控制。這個工具的目的是讓台灣的律師和法務知道一件事，AI 可以查真實判決、逐筆附出處，而不是憑記憶編字號。要讓人相信，最快的方法就是把程式碼攤開，誰都可以裝、可以改、可以拿去用。
效果比預期快。五月底一篇 Threads 貼文，三天內帶來一百三十九顆星。到我寫這篇的時候是兩百九十五顆，在同類的台灣法律檢索工具裡是最高的。MIT 是門檻最低的授權，fork、修改、商用都不用問我。對一個想被看見的專案，這是正確的起點。
轉折：不是有人盜用，是我發現授權擋不住
先說清楚：到今天為止，我沒有找到任何人把這個專案包裝起來轉售。八月做的歸戶分析，最大的使用者是一位律師在做專案型查詢，不是轉售者。轉折點不是被盜用，是六月底我在審查幾個高用量來源時想通的一件事。
這個專案的價值不在那幾百行 CLI 程式碼，在它背後連著的託管檢索服務，兩千多萬筆判決、函釋與憲法法庭裁判的檢索端點。MIT 管的是程式碼，管不到服務。換句話說，有人可以一行不改、拿我的程式碼包成自己的產品，接我的伺服器，對外收費，而 MIT 對此完全沒有意見。
問題從來不是「他會不會」，是「我要不要把可以變成不可以」。既然這個專案要長期經營，我決定在還沒有人這麼做之前先把規則寫清楚，而不是等事情發生再改。事後改規則，不管法律上站不站得住，觀感上一定輸。
選項：全面禁商用，還是只禁一件事
第一個直覺是 PolyForm Noncommercial，乾脆禁止商業使用。想了一天就否決了，因為這個專案的核心用戶就是商業使用者：律師查判決是執業，企業法務查判決是工作。全面禁商用等於把真正的用戶擋在外面，留下來的只剩學生和研究者。這不是我要的結果。
Elastic License 2.0 只禁三件事：第一，不得把軟體做成託管或代管服務提供給第三方，讓他們取得軟體的實質功能；第二，不得繞過授權金鑰機制；第三，不得移除授權與著作權聲明。其餘的，包括商業使用、修改、企業內部部署，全部允許。
這正好對上我的需求。律師拿去用，可以；企業裝在內網用，可以；拿去開一家「法律 AI 公司」，把我的檢索服務當成自己的產品賣，不行。授權的精準度比授權的嚴格度重要。
真正的法律問題：外部貢獻者的程式碼
這是整件事最麻煩的地方，也是多數人換授權時沒想到的。七月我併入了三位外部貢獻者的 pull request，合計五個 commit、三百零八行。專案沒有貢獻者授權協議（CLA）。
沒有 CLA 的專案，貢獻者把程式碼交給你時，授權給專案的就是專案當時的授權，也就是 MIT，但著作權仍然在他們手上。我可以在 MIT 之下繼續使用他們寫的東西，卻不能單方面把那些程式碼改成 ELv2，因為那等於替別人的著作決定授權條件。這件事跟我是不是專案擁有者無關，著作權不會因為你擁有 repo 就自動移轉。
兩條路：逐一取得同意，或移除。我選了移除。理由不是怕聯絡人，是我要的是「以後每一行都不需要再問任何人」的狀態。CONTRIBUTING 裡寫得很直白：這是一個單一作者的 codebase，目的是讓著作權歸屬沒有任何模糊，專案才能清楚地提供商業授權、也才能在需要時改條款，不必回頭追蹤每一位過去的貢獻者。SQLite 與 Litestream 走的是同一條路，這不是我發明的做法。
移除之後要重寫，而重寫要乾淨。我用的是 clean room：不讀被移除的 diff，只讀當初的 issue。依據是著作權法第十條之一，原文是：
「依本法取得之著作權，其保護僅及於該著作之表達，而不及於其所表達之思想、程序、製程、系統、操作方法、概念、原理、發現。」著作權法第 10 條之 1
issue 裡寫的是問題描述，那是思想；受保護的是他們寫出來的那段程式碼，那是表達。從問題描述出發重新寫，寫出來的表達就是我的。重寫完跑測試，十三個全過，功能一樣，程式碼一行不同。順帶一提，這也是為什麼 CONTRIBUTING 請大家不要在 issue 裡貼程式碼：貼了，乾淨的重寫就變難了。
授權擋不住的三件事
換完授權之後，我花了更多時間在想授權擋不住什麼。答案有三個，而且每一個都需要授權以外的東西來補。
第一，舊版本。v1.2.2 以前永遠是 MIT。授權是授與出去的權利，給了就收不回來，任何人今天都可以 fork v1.2.2 拿去商用，我無話可說。能做的只有往前走：新功能只進 2.x，服務端八月二十日的改版，舊版 CLI 拿不到完整內容。時間會替你把舊版變成次等品。
第二，名字。ELv2 管程式碼，不管商標。有人 fork 舊版叫它「TW Legal RAG Pro」，授權條款對此一個字都說不上。所以 v2.0.0 同一天上了商標政策：程式碼可以用，「TW Legal RAG」「Dr.Legal」這些名稱不行。這一層的保護走的是商標法，跟授權完全是兩條路。
第三，服務本身。程式碼換了授權，不代表我的伺服器就有了使用條款。所以第三份文件是託管服務的使用條款：允許個人、企業內部、研究與專業執業使用；禁轉售、禁大量匯出、禁止拿輸出去訓練模型。
一個字的差別：開源與公開原始碼
換成 ELv2 之後，README 裡所有的「開源」都改成了「公開原始碼」，英文用 source-available。這不是修辭潔癖。
Open Source Initiative 的開放原始碼定義第六條要求不得歧視任何使用領域。ELv2 禁止託管服務，就是對一個使用領域的限制，所以它不符合定義，OSI 也從未認可它是開源授權。BSL、SSPL 也一樣。繼續自稱開源是對用戶的誤導；對一個律師來說，那更是對自己專業的不誠實。
這一點很多專案沒分清楚，看到 GitHub 上有程式碼就叫開源。分清楚的好處是，當有人質疑「你說開源為什麼不能商用」時，你不需要解釋，因為你從來沒這樣說過。
收尾：從授權條款邁向授權策略
回頭看，我在第一個 commit 就該做的事只有一件：想清楚這個專案的價值在哪一層。在程式碼那一層，MIT 沒有任何問題；在服務那一層，MIT 什麼都擋不住。我在第一天沒有分這兩層，所以七十八天後要用移除、重寫、加三份文件來補。
授權條款是工具，授權策略才是決定：哪些東西送出去、哪些留在手上、名字由誰管、服務怎麼約束。四份文件各守一層，LICENSE 守程式碼、TRADEMARK 守名稱、TERMS 守服務、CONTRIBUTING 守未來每一行的歸屬。缺一層，就有洞。
最後一個數字。換授權之後，星數沒有掉，反而繼續往上。我的解讀是，用戶在意的從來不是「能不能拿去賣」，是「這個東西會不會一直在」。把規則說清楚，反而是讓它一直在的方法。
本文為作者個人經驗與觀點，不構成法律建議。授權條款的適用請依個案判斷。