1 files changed, 52 insertions, 0 deletions
diff --git a/content/article/clj-license.md b/content/article/clj-license.md
new file mode 100644
index 00000000..b9657ecc
--- /dev/null
+++ b/content/article/clj-license.md
@@ -0,0 +1,52 @@
++++
+title = 'Coffee Break Clojure, on License'
+subtitle = '谈谈开源协议'
+slug = 'clj-license'
+tags = []
+categories = ''
+date = 2026-10-09T00:07:13+08:00
+draft = true
+toc = true
++++
+
+这是一期番外，起因是有人给 weepinbell 提了个 [Issue](https://codeberg.org/eltrac/weepinbell/issues/60)，问我 AGPL 协议和 EPL 协议是否兼容。一开始我以为 Clojure 作为一门编程语言，算作[系统库](https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException)，不需要考虑协议问题，被提醒之后才意识到事情没有那么简单。<!--more-->
+
+简短的回答：
+
+1. Clojure 用 EPL 协议授权，与 GPL 协议及其变体不兼容；
+2. Clojure 是作为依赖被打包在 Clojure 程序里的，不算系统库，Clojure 生态里其他用 EPL 授权的库也一样；
+3. GNU 对此有写一条 [FAQ 条目](https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs)回答，建议用 GPL 分发软件的开发者在这种情况下，给 `LICENSE` 附加一条说明，作为代码的版权所有者批准用户将自己用 GPL 协议授权的代码与 EPL 授权的代码链接。可以理解为，对指定的软件库放宽限制。
+4. 比较出名的 Clojure 项目 [Logseq](https://github.com/logseq/logseq/blob/master/LICENSE.md) 和 [Metabase](https://github.com/metabase/metabase/blob/master/LICENSE-AGPL.txt) 就是这么做的。
+
+如果你愿意读更长的版本，那就继续往下读吧。
+
+## 开源协议杂谈
+
+本人对法律条文相当不敏感（这大概是要吃亏的），所以很长一段时间都默认用 MIT 授权我写的代码。我对 MIT 协议的理解是：只要署我的名字就好了，代码你随便用，但出了事你也别找我。总之是相当宽松的协议，而且非常简短。我很喜欢简单的东西。
+
+今年我逐渐意识到 MIT 协议的简洁所造成的代价：根据 [Codeberg 的指南](https://docs.codeberg.org/getting-started/licensing/#patent-usage)，MIT 有个完全没涉及到的领域——软件专利。如果软件包含受专利保护的算法或代码，Apache-2.0 协议明文允许用户使用这些专利，BSD 3-Clause Clear 明文**不**允许用户使用这些专利，而 MIT，完全没提到专利问题。所以，如果开发者持有软件专利，用 MIT 或 BSD 3-Clause Clear 协议授权分发软件，他就可以告用户侵犯了他的专利，即便软件是开放源代码的。
+
+这只是用户要承受的风险。开发者本人是版权持有者，只是通过开源协议，以某种条约把软件的使用权、分发权和自由研究的权利授予给了用户，开源协议是用户要遵守的协议（用户包括调用这个软件库的开发者、在服务器上运行这个软件的服务提供商、软件的终端用户等等）。
+
+如果开发者本来就不是专利的持有者，不是代码的版权所有者，那他用什么协议授权都不行，他没有这个权力。同理，开发者用大语言模型生成的代码不是他自己写的，而是由一个概率统计机器，将其他人的代码拼凑而成，而这些人是谁、代码原本是用什么协议授权的，已经无从得知——我想说这是赤裸裸的侵权，不过大众或许会说这是科技发展造成的灰色地带，而精神状况存疑的 Sam Altman 会说：[这是人们应该接受的坏事，为了造福 “AI”](https://www.politico.com/news/2026/10/04/sam-altman-decoded-interview-ai-01106217)。
+
+## Why, Clojure? Why EPL?
+
+Eclipse Public License（简称 EPL）不能算常见的开源协议，[Choose a License](https://choosealicense.com/licenses/) 的指南里甚至没提到 EPL（尽管这个指南确实不全，连 BSD 系列协议都没提到）。EPL 和 GPL 不兼容，和 MIT 也不兼容，所以 Rich Hickey[^1] 为什么要选这么奇怪的协议？
+
+我没能找到公开的决策记录，但根据我在[第 80 期周刊](/weekly/80/#重新审视开源协议选择)引用过的一篇文章的说法（这篇文章来自一家名为 JUXT 的公司，他们用 Clojure 做开发），Clojure 选用 EPL 主要出于两个原因：
+
+1. EPL 禁止大公司发布闭源版本的 Clojure 分支。
+2. EPL 使得 Clojure 的衍生作品可以被合并回 Clojure 核心代码。
+
+对比 GPL 等较强的 Copyleft 协议，EPL 的 Copyleft 属性较弱，这也使得用户可以用 Clojure 编写专有软件、闭源软件和商用。事实也证明，的确有不少公司（Cisco、CircleCI、Roam Research、Nubank……）都用 Clojure 开发自己内部的软件系统或发布专有软件。
+
+不过这真的值得吗？我最近也发现，Clojure 尽管有很强的工程价值却不被业界广泛使用的原因之一，**或许**就是开源社区不够有活力，不少用 Clojure 编写的软件都是闭源的，用 Clojure 写的较出名的开源项目屈指可数。[^2]
+
+所以，即便了解了缘由之后，我还是想感叹：*Why, Clojure? Why EPL?*
+
+## 
+
+[^1]: Clojure 的创始人。
+
+[^2]: 虽然主要原因还是写 Lisp 的人太少了。