你在 GitHub 创建新项目的时候，License 选什么？

MIT？太慷慨了，大公司拿去白嫖一分钱不给。GPL？太极端了，个人用户也被传染条款吓跑。Apache 2.0？和 MIT 一样拦不住商业白嫖。

最现实的诉求其实是：个人开发者和小团队免费用，大企业想用在生产环境就得付费。

这个需求在 2023-2026 年已经有一套成熟的解决方案了。HashiCorp、MongoDB、Elastic、Sentry 这些公司都走过这条路。这篇文章把所有方案摊开来讲清楚。

本文提纲

1. 先搞清楚：这些都不是"开源"
2. BSL 1.1：用得最多，HashiCorp 同款
3. FSL：Sentry 推出的 BSL 升级版
4. ELv2：Elastic 同款，最简洁
5. SSPL：MongoDB 同款，最激进
6. Commons Clause：最轻量，加一段话就行
7. AGPL 双授权：唯一真正的"开源"方案
8. 六种方案怎么选
9. 落地实操：GitHub 项目怎么配

先搞清楚：这些都不是"开源"

OSI（Open Source Initiative）对"开源"有严格定义。以下所有方案都不是 OSI 认可的开源许可证。它们统称为 "Source-Available"（源码可见） 或 "Fair-Code"（公平代码）。

• 源码你能看到 ✅
• 你能修改和学习 ✅
• 但商业使用有限制 ⚠️

这不丢人。HashiCorp（Terraform）、MongoDB、Elastic（Elasticsearch）、Sentry 这些估值几十亿的公司都这么干。可持续的软件需要可持续的收入。

BSL 1.1：用得最多，HashiCorp 同款

Business Source License 由 MariaDB 的创始人 Monty Widenius 设计，是目前最主流的"个人免费、企业付费"许可证。

怎么工作

1. 源码公开，你可以看、改、分发
2. 非生产使用免费（开发、测试、学习）
3. 生产使用受 Additional Use Grant 控制——作者可以允许或限制特定场景
4. 到了 Change Date（默认首次发布后 4 年），自动转为开源许可证（GPLv2+）

关键参数：Additional Use Grant

这是 BSL 最灵活的地方。你在里面写清楚什么场景免费：

Additional Use Grant: You may use this software for production purposes
with up to 3 server instances. For more than 3 instances, a commercial
license is required.

常见的写法：
- 按服务器数量限制（≤3 台免费）
- 按收入限制（年营收 < $1M 免费）
- 按用户数限制（< 5 用户免费）
- 按场景限制（非商业用途免费）

谁在用

优点

• 业界标准，最多项目使用
• 法律审查历史最长
• 时间延迟机制（4 年后自动开源）让社区有信心
• GitHub 上可以直接选

缺点

• "非生产使用"的定义有灰色地带
• 4 年后才开源对社区吸引力不足
• HashiCorp 切换后引发了 OpenTofu 分支事件

FSL：Sentry 推出的 BSL 升级版

Functional Source License 是 2024 年 Sentry 团队设计的新许可证，解决了 BSL 的几个痛点。

和 BSL 的区别

为什么 FSL 可能是 2026 年的最佳选择

1. 2 年后自动变 Apache 2.0 / MIT — 这意味着社区知道项目最终会完全开源，不用等 4 年
2. 限制更精准 — 不是一刀切限制"生产使用"，而是限制"竞争性商业用途"（比如拿你的软件做竞品 SaaS）
3. 两种标准变体 — 选 Apache 2.0 还是 MIT 做最终许可证，不用自己想
4. Sentry 背书 — 估值几十亿的公司在用，法律上有保障

谁在用

• Sentry（从 BSL 迁移到 FSL）
• 越来越多的新项目

ELv2：Elastic 同款，最简洁

Elastic License 2.0 是所有方案里文本最短、最容易理解的。

全文核心就两条禁令

你不能：
1. 把软件作为托管/管理服务提供给第三方（用户能访问软件的核心功能）
2. 篡改许可证密钥功能

你可以：
- 使用、复制、分发、修改
- 在组织内部使用
- 在此基础上构建产品
- 自己部署

ELv2 适合什么场景

ELv2 精准打击的是 "云厂商白嫖" — AWS 拿你的开源项目做成托管服务卖钱。它不影响：
- 个人开发者使用
- 企业内部使用
- 在你的软件基础上构建自己的产品

它只限制一件事：不能把软件本身当成服务卖。

谁在用

优点

• 文本最短，一页纸读完
• 限制精准，不影响普通用户
• 30 天违约补救期（给了改正机会）

缺点

• 不限制企业内部使用（如果企业只是自用，你收不到钱）
• 没有"自动变开源"的时间机制

SSPL：MongoDB 同款，最激进

Server Side Public License 基于 GPLv3，但加了一条极端条款。

核心条款

如果你把 SSPL 软件的功能作为服务提供给第三方，你必须公开整个服务栈的源码——不仅是 SSPL 软件本身，还包括：

• 所有管理软件
• 监控、日志、备份软件
• 所有自动化和编排工具
• 整个基础设施的代码

为什么这么激进

MongoDB 2018 年切到 SSPL，直接导火索是 AWS DocumentDB — Amazon 拿 MongoDB 的开源代码做成托管服务卖钱，一分钱不给 MongoDB。

SSPL 的设计目标就是让云厂商无法白嫖：你要么公开一切，要么买商业许可。

OSI 的态度

SSPL 提交给 OSI 审核，被拒绝了。理由是它要求公开"其他不相关的软件"，违反了 OSD 第 9 条（不能限制一起分发的其他软件）。

谁在用

• MongoDB（几乎唯一的重量级用户）
• Inngest（事件驱动函数平台）

优点

• 对云厂商威慑力最强
• 基于 GPLv3，法律框架成熟

缺点

• 只有 MongoDB 在用，社区接受度低
• "公开整个服务栈"的要求在法律上未被测试
• 过于激进，连正常的企业使用都可能被吓到
• 不推荐新项目使用

Commons Clause：最轻量，加一段话就行

Commons Clause 不是独立许可证，而是加在你现有许可证（Apache 2.0、MIT 等）上的一个额外条件。

核心就一句话

你不能 Sell 这个软件。

"Sell" 的定义：把软件的功能作为产品或服务提供给第三方并收费（包括托管费、咨询费、支持服务费）。

实际效果

• ✅ 个人使用：免费
• ✅ 企业内部使用：免费
• ✅ 用你的软件构建自己的产品：免费
• ❌ 把你的软件重新打包卖 SaaS：不行
• ❌ 用你的软件提供付费托管服务：不行

谁在用/用过

• Redis Labs（Redis Graph、RedisAI 模块，后来换了别的许可证）
• 一些小型项目

优点

• 改动最小——在你现有的 Apache 2.0/MIT 上加一段话
• 不影响普通用户
• 概念简单

缺点

• 使用率在下降，社区向 BSL/FSL 聚拢
• "Sell" 的定义有灰色地带
• 没有时间延迟机制

AGPL 双授权：唯一真正的"开源"方案

如果你坚持要 OSI 认可的开源许可证，AGPL 双授权是唯一选择。

怎么工作

1. 项目以 AGPLv3 发布（这是 OSI 认可的开源许可证）
2. AGPL 的"网络传染"条款要求：任何通过网络提供 AGPL 软件服务的人，必须公开所有修改和相关代码
3. 大企业不愿公开自己的代码，所以必须向你购买商业许可证
4. 你同时提供两种选择：免费的 AGPL 版本，付费的商业版本

为什么有效

大多数有法律部门的公司有 "AGPL 黑名单" — 禁止在任何项目中使用 AGPL 软件。这意味着他们要么不用你的项目，要么付钱。通常会付钱。

谁在用

优点

• AGPL 是 OSI 认可的开源许可证
• 不需要写新许可证
• 法律框架成熟

缺点

• AGPL 的"传染性"会吓跑一些个人用户
• 企业可能直接选择不用，而不是付费
• 你需要维护两个版本（AGPL 版 + 商业版）

六种方案怎么选

MERMAID_BLOCK_0

一张表搞定

我的推荐

2026 年新项目：选 FSL。

理由：
1. 2 年后自动变 Apache 2.0/MIT，社区接受度高
2. 限制精准，不影响个人用户
3. 文本简洁，容易理解
4. Sentry 背书，有商业验证

已有项目想改许可证：选 BSL 1.1。

理由：
1. 最多公司用过，法律风险最低
2. GitHub 和各大平台都有支持
3. Additional Use Grant 灵活，可以精确控制免费范围

只想阻止云厂商：选 ELv2。

理由：
1. 最简洁，限制最精准
2. 不影响任何终端用户
3. Elastic 验证了它的有效性

落地实操：GitHub 项目怎么配

1. 创建 LICENSE 文件

FSL（推荐）：到 https://fsl.software/ 下载对应变体，放到项目根目录的 LICENSE 文件。

BSL 1.1：

Business Source License 1.1

License text: https://mariadb.com/bsl11/

Parameters:

Additional Use Grant: You may use this work for non-production
purposes only. Production use requires a commercial license.
Contact license@example.com for details.

Change Date: 2028-01-01

Change License: Apache License 2.0

ELv2：从 https://www.elastic.co/licensing/elastic-license 获取文本。

2. README 里加许可证说明

## License

This project is licensed under the [Functional Source License (FSL)](LINK).
- ✅ Free for individual and non-commercial use
- ✅ Free for learning, development, and testing
- ✅ Automatically converts to Apache 2.0 after 2 years
-  Production/commercial use requires a license — contact us

3. 在贡献者协议（CLA/DCO）里加许可证变更权

这一步必须在你接受第一个 PR 之前做。否则以后换许可证需要所有贡献者同意。

用 CLA Assistant 或在贡献指南里加：

## Contributing

By submitting a pull request, you agree to license your contribution
under the same license as this project, and grant the project maintainer
the right to re-license your contribution as part of future license changes.

4. package.json / pyproject.toml 里声明

{
  "license": "SEE LICENSE IN LICENSE"
}

不要填标准 SPDX 标识符（如 "MIT"），因为 GitHub 的自动检测不支持这些非标准许可证。用 "SEE LICENSE IN LICENSE" 然后在 LICENSE 文件里写清楚。

5. 别忘了这些

• [ ] GitHub 仓库 Settings → 关于 License 的描述
• [ ] 发布第一个版本前确定许可证（之后改很麻烦）
• [ ] 在官网/文档里清楚地解释你的许可证策略
• [ ] 如果提供商业许可，准备一个 license@yourproject.com 邮箱

选 License 不是选最好看的那个，是选最适合你商业模式的那个。如果你想让个人免费用、企业付费，2026 年的最佳答案是 FSL 或 BSL 1.1。别自己造许可证——已经有足够好的轮子了。

作者: itech001
来源: 公众号：AI人工智能时代
主页: https://www.theaiera.cn，每日分享最前沿的AI新闻和技术。

本文首发于 AI人工智能时代，转载请注明出处。