blob: 84e57b7d1bef9c9f01d710a3d6d719ac06d841c2 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
+++
title = '开源协议杂谈'
slug = 'clj-license'
tags = ["Clojure","开源"]
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?*
## Clojure 的开源生态
不少 Clojure 库都选用 EPL 协议，还会在文档里写这样的句子：
> Distributed under the Eclipse Public License, ==the same as Clojure.==
如果细数一个 Clojure 项目的依赖项（在 `deps.edn` 或 `project.clj` 等文件里），会发现直接依赖的软件库（包括 Clojure 本身）都有不少用 EPL 授权的软件包，更别说间接依赖了。GPL 协议在 Clojure 生态中比较少见（但不是没有），这与 EPL 和 GPL 的兼容性问题有关，但更多的原因，似乎是 Clojure 社区受 Clojure 的影响，把 EPL 当作了**默认**开源协议。
Leiningen 提供的项目模板就默认生成 EPL 协议，我对这一做法其实颇有微词，倒不是说工具本身不应该带有强烈的观点，而是说工具没有权利帮代码的版权所有者选择授权协议。不过就算 Leiningen 不这么做，许多开源开发者仍然不在乎授权协议，他们只是想把代码分享出去而已。
程序员可能是互联网上最热爱分享的一群人了，这很好。我以前也抱类似的态度，直到最近的[某些事件](/weekly/101/#市场真的有辨别力吗)，我开始反思自己对待版权的态度是不是不够严肃。
认真对待授权协议，也就是认真对待自己要授予其他人的权力，一方面是为了保护自己的作品，另一方面也是为了让内容更容易传播和使用。这两者在某种程度上是矛盾的，至少具有某种张力。如果完全不允许别人使用，作品就很难传播（“流行音乐一定要流行”）；如果对授予他人的权力太过慷慨，又有可能遇到糟心事。
Clojure 选用 EPL 协议似乎是为了找到两者的平衡点，是权衡取舍之后的决定。这个平衡点在 Clojure 的历史背景和未来打算的语境下，是有意义的，但未必放之四海皆准。我们也看到，这个选择造就了一个不小的问题：Clojure 程序员不能直接给自己用 GPL 授权自己的代码，除非对 GPL 协议做附加说明。
我不知道 Rich Hickey 有没有考虑过这个后果。他可能考虑到了，并且接受这个权衡之后的结果。如果是这样最好。总之，我希望自己（以及读到这篇文章的人）以后都能认真考虑此时。在越来越多人践踏著作权（copyright）、滥用著佐权（copyleft）的当今，单单提升版权意识是不够的，还应该有更深入的思考。无论选用什么授权协议，都应该是审慎思考过后的决定。
## Why, Eltrac. Why AGPL?
[^1]: Clojure 的创始人。
[^2]: 虽然主要原因还是写 Lisp 的人太少了。
|
