跳至内容
开源协议概述
- 开源协议是法律文件,规定他人如何使用、修改和分发你的代码
- 主要分为宽松型(permissive)和严格型(copyleft)两大类
- 选择协议前需考虑:项目目标、商业用途、兼容性等问题
常见开源协议详解
MIT 协议
- 允许:商业使用、修改、私有化、再分发
- 要求:保留原始版权声明和许可声明
- 特点:最宽松的协议之一,适合希望广泛传播的项目
Apache 2.0
- 允许:商业使用、修改、私有化、专利授权
- 要求:保留版权声明、修改文件需注明
- 特点:提供明确的专利授权,适合企业级项目
GPL (GNU通用公共许可证)
- GPLv2:要求衍生作品也必须开源
- GPLv3:增加专利条款和反DRM条款
- 特点:强传染性,适合希望保持开源生态的项目
LGPL (较宽松的GPL)
- 允许:与专有软件动态链接
- 要求:对LGPL部分修改仍需开源
- 特点:适合库文件,平衡开源与商业使用
BSD 协议
- 2-clause:极简,仅要求保留版权声明
- 3-clause:增加”不得用作者名义促销”条款
- 特点:类似MIT,但历史更悠久
AGPL (Affero GPL)
- 要求:网络服务也必须开源
- 特点:针对SaaS时代的GPL强化版
MPL (Mozilla公共许可证)
- 要求:对MPL文件修改需开源
- 允许:与其他代码混合而不传染
- 特点:介于GPL和MIT之间的折中方案
如何选择开源协议
考虑因素
- 项目目标:最大化传播 vs 保护开源生态
- 商业用途:是否允许闭源商业产品使用
- 兼容性:与其他开源项目的协议是否冲突
- 专利保护:是否需要明确的专利授权条款
- 社区偏好:某些领域有主流协议选择
选择流程
- 确定是否允许商业闭源使用 → 是:MIT/BSD/Apache;否:GPL/AGPL
- 是否需要专利保护 → 是:Apache/GPLv3
- 是否针对网络服务 → 是:考虑AGPL
- 是否是库文件 → 是:考虑LGPL/MPL
- 检查与依赖项的协议兼容性
注意事项
- 混合协议代码时要特别注意兼容性
- 更改协议需要所有贡献者同意
- 在项目根目录添加LICENSE文件
- 在文件头添加简短许可声明
- 商业项目使用开源代码前务必进行合规审查
实用建议
- 个人小项目:MIT或Apache 2.0
- 企业级项目:Apache 2.0
- 希望强制开源:GPLv3
- 网络服务项目:AGPL
- 库/框架开发:LGPL或MPL
记住:选择协议后很难更改,务必慎重考虑项目长期发展需求。