发布软件这28年，我历经三种许可时期。Midgard是Web框架，项目全用LGPLv2；当时自由软件许可不多，用弱copyleft正合适。约2011年认真写JavaScript后，我改用MIT，这种许可简单、互通、无附加条件，也受NPM生态欢迎。Flowhub关闭后几年，我几乎没发布软件。今年，我的默认许可换成了EUPL-1.2。

过去 28 年发布软件的经历里，我经历了三个截然不同的软件许可时代。我最近的作品都采用欧洲联盟公共许可证 1.2（EUPL-1.2），下面解释一下原因。

Midgard 当时用的全是 LGPLv2。那时更简单，自由软件许可证也不多。Midgard 是个 Web 框架，用弱 copyleft 许可是合理选择。随 Midgard 发布的示例网站采用 X11 许可。

约 2011 年起我更认真地用 JavaScript 工作，便换成了 MIT 许可。这是个「你想怎么用都行，只要别告我」式的简单许可，受 NPM 包生态青睐，互操作容易，没有附加条件。

Flowhub 关停后，我有几年几乎没发布软件，要么因为工作状况不允许，要么因为忙着弄船。

转用 EUPL

今年我决定把「默认许可」换成 EUPL-1.2。这是欧盟制定并发布的、经 OSI 批准的自由软件许可，和我过去用的许可差别很大。EUPL 是强 copyleft 许可，无论软件以何种方式分发都要求以互惠方式授权，从而堵住了「SaaS 漏洞」。

多年下来已经清楚：我们这些「开源」阵营（相对「自由软件」阵营而言）一直错了。我们赢了辩论，用户和开发者却没得到什么。我们的努力只是让大公司能更廉价地造东西，让亿万富翁变成万亿富翁。

所以是时候别再折腾宽松许可了。如果企业不想按我们的条件用软件，尽可以花钱花精力去做自己的。

EUPL 还有具有法律效力的官方译文，覆盖 23 种语言。在这个多数软件在硅谷之外的世界被构建和使用的时代，这点也不无好处。

以下是我已经以 EUPL 发布的几样东西：

• reticulum-js：Reticulum 网状网络协议的 JavaScript 实现
• dacar：基于 Reticulum 的去中心化授权系统
• signalk-energy-predictor：面向可再生能源动力船只的预测系统
• offshore-blogging-system：通过 InReach 卫星短信发布博客文章和下载天气数据的工具

此外，NoFlo 开发环境的重写版也在 EUPL 下进行。NoFlo 本身会保持 MIT 许可，因为它是个已有大量第三方贡献的存量项目。

讨论整体对「开源运动让大公司白嫖、普通开发者获益甚少」的悲观论调持反对态度，多数开发者认可开源带来的普惠价值，同时围绕 EUPL 的实用性、许可证选择与商业平衡展开多元讨论。

认为开源运动成果显著，大公司获利是预期内的正向结果

• 不少开发者指出开源的核心目标是降低技术门槛、让更多人能用上优质软件，大公司使用本就是预期内的事，没有开源反而会扼杀大量中小创业者的机会，高赞
• 有观点认为开源提升了社会资源分配效率，大公司创造万亿价值的同时也反哺了生态，所谓「获益甚少」不符合事实，较多人 > 我们当初选 MIT 许可证时，就知道大公司会用它，我们本来就想让他们用，以此把新用户拉进社区，这从来不是问题（@ricardobeat）
• 还有人强调不能把个人理想强加给所有开源开发者，不少人选择宽松许可证就是想无条件回馈世界，不介意任何人使用，较多人

认可 EUPL 的价值，但也有明确顾虑

• 部分开发者认为 EUPL 适合欧盟语境的项目，法律基础基于欧盟法律，同时兼顾了 copyleft 理念和政府、企业的使用需求，较多人
• 有用户指出 EUPL 存在条款逻辑矛盾，先声明用户拥有权利，后续又附加条件，让人对其法律效力存疑，少数人
• 有人发现 EUPL 的「许可证转换」条款会弱化 copyleft 强度，可直接转为 EPL、MPL 等较宽松许可证，若想严格约束 SaaS 闭源使用，不如直接选 AGPL，高赞 > EUPL 的转换条款意味着它的强度只会等同于它允许转换的最弱许可证，想防 SaaS 闭源的话还不如直接指定 AGPL（@apt-get）
• 还有观点认为 EUPL 核心设计目标是方便欧盟机构跨成员国的版权、专利规则适配，优先保障许可证混用的兼容性，而非针对超大规模科技公司设计，较多人

宽松许可证更适合长期和商业化场景

• 不少开发者偏爱 Apache 2.0 这类宽松许可证，认为没必要限制他人使用方式，看到自己的代码被用在商业项目中反而有成就感，同时鼓励商业方反哺社区，较多人 > 我个人的原则是只要别把商业支持需求甩给社区项目就行，能靠我的代码做生意我反而开心，良性的商业共生关系能让更多人 sponsor 开源工作（@Joel_Mckay）
• 有观点指出开源许可证的选择本质是「为乐趣分享」和「靠代码盈利」的 dichotomy，前者适合完全开放，后者则需要更审慎的授权设计，少数人

质疑当前许可证难以应对 AI 训练的新问题

• 有开发者认为包括 EUPL 在内的现有开源许可证都无法阻止 AI 训练时无偿使用代码，需要专门的条款约束这类「IP 盗窃」行为，甚至提出违规公司需支付高额赔偿，少数人

有价值的补充

• 硬件/电子领域可优先考虑 CERN OHL 许可证，它覆盖了 GPL、AGPL 等通用许可证未适配的硬件开源场景
• 双许可证模式（如非商用免费、生产环境收费）的落地难度较高，新项目采用可能直接降低 adoption 率，已有不少成熟项目（如 Terraform、Redis）改许可证的前车之鉴可作为参考
• 许可证选择可以动态调整：自己独立拥有的代码可以后续更换许可证，早期也可针对不同场景选用不同许可证，无需一开始就定死所有规则
• 强 copyleft 许可证（如 AGPLv3）的代码后续可以再发布为更宽松的许可证（如 MIT），也可以同时提供商业授权选项，版权方拥有完全的授权主导权