技术

开源许可证选择踩坑记录

,

开源许可证选择踩坑记录

开源项目选许可证是个头疼的事，MIT、GPL、Apache各有讲究。记录一下几种主流许可证的特点和踩过的坑。

主流许可证对比

许可证 宽松程度 商业使用 闭源衍生 专利授权
MIT 最宽松 允许 允许 不明确
Apache 2.0 宽松 允许 允许 明确
GPL 严格 允许 必须开源 有
BSD 宽松 允许 允许 不明确

MIT许可证

最宽松的许可证，适合工具库和个人项目。

核心条款：

  • 允许自由使用、复制、修改、合并、出版发行、再许可和/或销售
  • 必须保留版权声明和许可声明
  • 作者不承担任何责任

适用场景：

  • JavaScript/npm包
  • 工具类库
  • 前端框架（React、Vue、jQuery等）

坑1：专利问题

MIT许可证没有明确的专利授权条款。如果你担心专利纠纷，建议用Apache 2.0。

Apache License 2.0

企业开源项目首选，有明确的专利保护。

核心条款：

  • 允许修改源代码后闭源
  • 必须对每个修改过的文件做版权声明
  • 明确授予专利权（重要！）
  • 如果使用Apache License的代码被起诉专利侵权，许可证终止

适用场景：

  • Android（AOSP）
  • Apache软件基金会项目
  • 需要专利保护的企业项目
  • 大型开源项目

与MIT的区别：

方面 MIT Apache 2.0
简洁性 简洁 详细
专利授权 不明确 明确授予
商标使用 未提及 不允许
修改声明 未要求 要求

GPL许可证

GPL的核心是Copyleft：如果你使用了GPL代码，你的代码也必须开源。

版本对比：

版本 特点 传染性
GPLv2 经典版本 强
GPLv3 抗TiVo化、专利保护 强
AGPLv3 网络服务也算分发 最强
LGPL 库专用，较宽松 较弱

坑2：GPL传染性

1
2
3
4
5
6
7
8
9
10
11
场景1：使用GPL库
你的应用 ──链接──> GPL库
结果：你的应用必须GPL开源

场景2：修改GPL软件
你修改了Linux内核
结果：修改必须GPL开源

场景3：独立开发
你独立开发的软件
结果：可以任意选择许可证

坑3：GPLv2和Apache 2.0不兼容

Apache 2.0的专利条款与GPLv2存在冲突，不能混用。GPLv3可以兼容Apache 2.0。

BSD许可证

BSD有2-Clause和3-Clause两个版本：

版本 特点
BSD 2-Clause 最简洁
BSD 3-Clause 增加非背书条款

核心条款：

  • 允许修改后闭源
  • 不对修改文件做说明要求
  • BSD 3-Clause：不得使用原作者名字推广

许可证选择建议

个人项目/工具库

推荐：MIT License

  • 简单易懂
  • 最大化传播
  • 无使用限制

企业开源项目

推荐：Apache License 2.0

  • 明确的专利保护
  • 允许商业使用
  • 降低法律风险

社区/自由软件项目

推荐：GPLv3

  • 确保代码自由
  • 防止闭源侵占
  • 维护社区利益

文档/非代码内容

推荐：Creative Commons

  • CC BY：署名
  • CC BY-SA：署名-相同方式共享
  • CC0：放弃版权

坑4：许可证兼容性问题

兼容性矩阵：

MIT Apache 2.0 GPLv2 GPLv3
MIT ✓ ✓ ✓ ✓
Apache 2.0 ✓ ✓ ✗ ✓
GPLv2 ✓ ✗ ✓ ✗
GPLv3 ✓ ✓ ✗ ✓

✓ 可以组合，✗ 存在冲突

常见冲突场景：

场景1：GPL与专有软件

1
2
3
4
5
6
7
问题：可以将GPL代码用于专有软件吗？
答案：不可以，除非你的软件也开源

解决方案：
1. 更换为MIT/Apache代码
2. 将GPL代码作为独立进程
3. 联系作者获取商业许可

场景2：Apache 2.0与GPLv2

1
2
3
4
5
6
7
问题：Apache 2.0代码可以用于GPLv2项目吗？
答案：不可以，存在专利条款冲突

解决方案：
1. 升级到GPLv3
2. 寻找替代代码
3. 请求作者双重许可

企业合规实践

开源治理流程

1
2
3
4
5
6
7
引入开源组件流程：

1. 需求评估
2. 许可证审查
3. 安全扫描
4. 审批使用
5. 持续监控

许可证扫描工具

工具 特点
FOSSology 开源、专业
ScanCode 开源、命令行
Black Duck 商业、全面
Snyk 商业、SaaS
GitHub Dependency Graph 免费、集成

项目文件规范

1
2
3
4
5
PROJECT_ROOT/
├── LICENSE              # 主许可证文件
├── LICENSE-3RD-PARTY    # 第三方许可证汇总
├── NOTICE               # 版权声明（Apache需要）
└── README.md            # 许可证说明

源代码文件头部：

1
2
3
4
5
6
7
8
/**
 * @license
 * [项目名称]
 * Copyright (c) [年份] [作者]
 *
 * Licensed under the [许可证名称]
 * See LICENSE file in the project root for full license information.
 */

坑5：没有许可证的风险

如果代码没有明确的许可证：

  • 默认保留所有权利
  • 他人无法合法使用
  • 无法形成开源社区
  • 商业使用存在法律风险

建议：即使是不重要的项目，也建议加个MIT许可证，方便别人使用。

许可证变更

可以变更，但需要：

  1. 获得所有版权持有者的同意
  2. 或获得所有贡献者的许可
  3. 旧版本代码仍受原许可证约束

变更流程：

  1. 发布公告说明变更原因
  2. 联系所有贡献者获取同意
  3. 更新LICENSE文件
  4. 更新所有源代码文件头部
  5. 发布公告说明变更完成
  6. 保留历史LICENSE文件

双许可证策略

某些项目采用双许可证：

1
2
3
4
5
6
7
8
9
本项目采用双重许可：

1. 开源版本：GPLv3
   - 免费使用
   - 必须开源

2. 商业版本：商业许可
   - 需要付费
   - 可以闭源

MySQL、Qt等项目都采用了这种策略。

快速选择指南

1
2
3
4
5
6
7
8
9
最大化传播  ──────────────────────>  MIT

专利保护    ──────────────────────>  Apache 2.0

确保自由    ──────────────────────>  GPL

公共领域    ──────────────────────>  Unlicense/CC0

文档内容    ──────────────────────>  CC-BY

按项目类型推荐：

项目类型 推荐许可证
npm包 MIT
前端框架 MIT
开发工具 MIT/Apache
操作系统 GPL
数据库 GPL/Apache
文档 CC-BY-SA

总结

开源许可证选择的几点建议：

  1. MIT：最宽松，适合工具库和个人项目，但专利保护不明确
  2. Apache 2.0：有专利保护，适合企业开源项目
  3. GPL：确保代码自由，但传染性强，使用需谨慎
  4. BSD：简洁宽松，适合学术项目
  5. 兼容性：Apache 2.0和GPLv2不兼容，注意检查
  6. 合规：企业使用开源组件要建立审查流程

项目初期就确定好许可证，后期变更很麻烦。如果不确定，先用MIT，后续可以升级。