3.项目开源协议_.md 4.4 KB
一、主流开源协议对比
| 协议名称 | 核心特点 | 适用场景 |
|---|---|---|
| MIT | - 最宽松的协议- 允许闭源和商业化- 仅需保留版权声明 | 希望代码被广泛使用（包括闭源项目） |
| BSD | - 类似MIT- 新增“不得用作者名推广衍生品”条款（BSD-3-Clause） | 与MIT类似，但需避免署名争议 |
| Apache 2.0 | - 允许闭源和商业化- 明确专利授权- 修改文件需标注变更 | 需要专利保护的企业级项目 |
| GPL v3 | - 严格“传染性”- 衍生作品必须开源并采用GPL- 禁止专利诉讼 | 希望代码及衍生作品始终开源 |
| LGPL v3 | - 宽松版GPL- 允许动态链接闭源- 静态链接需提供代码 | 库开发（如Qt本身），允许闭源项目使用但保留库的开源性 |
| ISC | - 等同于MIT/BSD- 更简洁的法律文本 | LibreSSL等网络/安全项目常用 |
| OpenSSL | - 自定义协议- 需声明“This product includes software developed by OpenSSL" | 使用OpenSSL的强制要求 |
二、项目关键依赖分析
Qt框架
- 默认采用GPL v3，商用需购买商业许可。
- 若动态链接Qt库且不修改Qt代码，可用LGPL v3保留闭源权利。
OpenSSL
- 协议：OpenSSL License + SSLeay License
要求：分发的应用必须包含声明：
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/)
- 协议：OpenSSL License + SSLeay License
LibreSSL
- 协议：ISC License
- 要求：仅需保留版权声明，无传染性。
- 协议：ISC License
三、协议选择建议
场景1：希望闭源或商业化
推荐协议：MIT + 满足OpenSSL声明
- 优势：允许闭源分发，法律风险最低。
- 注意：
- 使用OpenSSL的应用需在文档/UI中添加声明。
- 使用LibreSSL的应用仅需保留ISC版权声明。
示例：
// 在应用程序的"关于"页面或LICENSE文件中注明： This software uses OpenSSL under the OpenSSL License (https://www.openssl.org/source/license.html)
- 优势：允许闭源分发，法律风险最低。
场景2：强制衍生作品开源
- 推荐协议：GPL v3
- 优势：确保所有修改版本保持开源。
- 注意：
- OpenSSL与GPL不完全兼容（需法律审查），建议替换为LibreSSL（ISC协议兼容GPL）。
- Qt需以GPL或LGPL动态链接。
- 优势：确保所有修改版本保持开源。
场景3：平衡开放性与灵活性
- 推荐协议：Apache 2.0
- 优势：明确专利授权，适合企业协作。
- 注意：需处理OpenSSL的声明要求。
- 优势：明确专利授权，适合企业协作。
四、分应用建议
| 应用类型 | 推荐协议 | 依赖处理 |
|---|---|---|
| 使用OpenSSL | MIT + 声明 | 必须包含OpenSSL声明，确保法律合规 |
| 使用LibreSSL | Apache 2.0 | 利用专利条款保护，同时LibreSSL的ISC协议无额外负担 |
五、最终推荐组合
统一简化方案
- 两个应用均采用 MIT License
- 处理OpenSSL的声明，LibreSSL无需额外操作。
- 两个应用均采用 MIT License
企业友好方案
- 使用OpenSSL的应用：MIT + OpenSSL声明
- 使用LibreSSL的应用：Apache 2.0
- 使用OpenSSL的应用：MIT + OpenSSL声明
社区共建方案
- 两个应用均采用 GPL v3
- 将OpenSSL替换为LibreSSL以解决协议兼容性问题。
- 两个应用均采用 GPL v3
六、实施步骤
- 在项目根目录添加
LICENSE文件。 - 在代码文件头添加版权声明（如
Copyright 2023 Your Name. Licensed under MIT.）。 - 对使用OpenSSL的应用，在用户可见位置添加声明。
- 分发时确保依赖库的许可证文件被包含（如OpenSSL的LICENSE）。