开源许可证是个相当庞杂的范畴，仅OSI (Open Source Initiative, 开放源代码促进会)批准的许可证就有80多种；此外，还有数百种在开源生态中流传的其他许可证。
虽然有些开源许可证相对简洁明了，适合只想简单发布开源项目的人使用；但还有一些许可证非常冗长复杂，甚至需要专业的法务团队介入。
本文将以对比形式分析开源许可证相关的一些要素，以便读者快速清晰地掌握这一领域的基础知识。（省流版许可证选择建议见文末~）
01 宽松式许可证和Copyleft 许可证
开源许可证通常可以分为两大类：宽松式许可证及Copyleft许可证（也称著佐权）。二者的差别主要在于宽松度以及与使用开源软件组件相关的要求和许可权限的多少。
当一个开源组件采用Copyleft 许可证时，开发人员有权使用、修改和共享该作品，前提是要履行对应的义务。一旦代码中使用了许可证为Copyleft类的开源组件，就需要向他人开放你的代码。GPL许可证族是这类许可证中最早出现也是最流行一种，包含许多版本和变种。
与之相对，宽松式许可证是另一个极端。它保证了使用、修改和重新分发的自由，同时也允许创建专有的派生作品。宽松式许可证对于采用它的组件的使用几乎没有限制，并且几乎不需要回报。这类许可证中，最简洁明了和最受欢迎的是MIT许可证。
02 许可证的限制、条件和权限
除去这两大类别的差异，每一类下许可证和许可证族也会因为一些附加参数而产生具体差异。
例如，同属宽松式许可证的MIT许可证和Apache许可证迥然不同，同属Copyleft类的Eclipse许可证和GPLv3许可证也并没有共用相同的条款和条件。
每个开源许可证都有自己独特的限制、条件和权限。GitHub的choosealicense.com旨在帮助开发人员找到合适的开源许可证；上面提供了一个附录，用于比较不同许可证，并根据许可证授权和限制的内容对比它们的差异性。
根据这个附录，开源许可证授予项目在版权或其他知识产权法律下可能不被允许的行为许可；这些许可通常需要遵守特定条件。大多数开源许可证还具有免除担保和责任的限制，有时还明确排除了专利或商标的许可授权。
03 开源许可证中的权限
在开源许可证中，最常被授予权限的行为涉及商业使用、分发、修改和私人使用。
其中，一个重要区别是专利使用的许可。许多开源许可证在特定条件下明确授予贡献者的专利权，例如GPLv3、Apache license 2.0、Eclipse公共许可证1.0和2.0等。还有一些许可证明确声明不授予贡献者专利权，包括BSD 3-Clause Clear、Creative Commons Attribution 4.0 International、Creative Commons Attribution Share Alike 4.0 International、Creative Commons Zero v1.0 Universal和ODC Open Database License v1.0等。
虽然所有开源许可证都会授予商业使用、分发、修改和私人使用的权限，但这些权限受特定条件的约束；不同许可证的条件各不相同。这些条件可能包括在通过网络或其他渠道分发软件时提供源代码，使用开源项目时纳入许可证信息和版权声明，在同一许可证下发布代码修改，记录对代码进行的所有更改等。
04 开源许可证中的条件
通常情况下， Copyleft许可证比宽松式许可证附带更多条件。随着开源的使用愈发普遍，前者在商业组织中的的流行度也在逐渐下降
最典型的例子是GPL许可证族对网络分发的限制。虽然GPL 2.0和3.0的条件并未明确规定网络使用属于分发，但作为公认最强Copyleft许可证，AGPL v3.0要求使用修改后的版本提供网络服务时，必须提供该版本的完整源代码。
05 开源许可证的限制
比较开源许可证的另一种方法是看它们的限制。开源许可证的限制涉及责任、明确声明不授予商标权和不提供担保。
对商标使用的限制可以看作一个分野。大多数GPL族许可证并没有明确规定不授予商标权，而Creative Commons和Apache v2.0则明确包含这一限制。值得注意的是，GitHub的choosealicense.com指出，没有这种声明的许可证可能不授予任何隐含的商标权利。
06 Copyleft许可证：GNU GPL vs Eclipse开源许可证
虽然Eclipse开源许可证（EPL）和GNU GPL许可证族都被认为是Copyleft许可证，二者宽松程度不同。GNU GPL许可证族有强制性的Copyleft条款，无论用户代码中包含多少GPL代码，都要公开其软件的完整源代码。
EPL算是一种较弱的 Copyleft 许可证。它不要求用户共享其整个软件项目，而只需在以源代码形式分发时开源任何包含EPL 组件的源码，并在以对象形式分发时按需提供源代码。
此外，EPL只要求用户在源码形式分发时中披露部分源代码，对二进制文件形式没有要求；而GPL族则要求在源代码和二进制文件的复制或衍生版本中都继续使用同一许可证。
07 宽松式许可证：Apache 2.0 vs BSD开源许可证
BSD许可证是一种高度宽松的许可证，允许用户以任何方式修改和重新分发使用了BSD许可证的软件。早期版本的Apache许可证与BSD许可证类似，但Apache 2.0增加了一些关键的差异，使得这两种许可证区别开来。
- 明确授予专利权。Apache许可证2.0明确规定了在使用、修改或分发该许可证许可的软件时授予的专利权，并列举了撤销此类授权的情况。
- 对使用的概念进行清晰定义。Apache许可证2.0明确定义了所有使用的术语和概念，减少了歧义的空间。
- Apache许可证2.0无需重新措辞即可重复使用。其他项目可以轻松使用Apache许可证2.0而无需修改许可证文档本身的任何内容，大大节省了处理许可证问题的时间；它也因此成为开发人员最喜欢的许可证之一。
结语
无论您是正在开发一个软件项目并需要附加开源许可证以便共享，还是希望确保所使用的软件组件所附带的开源许可证与您自己的项目和需求兼容，了解每个许可证意味的不同限制、条件和权限都非常重要。有些细节看起来微不足道，但会对开源组件的使用和分发方式有决定性的影响，进而影响对开源的使用及软件制品的合规性。
图：许可证选择指南省流版（整理自https://choosealicense.com/）感谢每一位开源社区成员对OpenSCA的支持和贡献。我们鼓励更多伙伴参与到OpenSCA开源项目的建设中来，成为开源贡献者，有任何建议都可以发在评论区或者Gitee、GitHub上OpenSCA项目的Issues中。让我们一起拥抱开源，共筑开源安全生态，促进开源产业健康发展。
OpenSCA的代码会在GitHub和Gitee持续迭代，欢迎Star和PR，成为我们的开源贡献者，也可提交问题或建议至Issues。我们会参考大家的建议不断完善OpenSCA开源项目，敬请期待更多功能的支持。
GitHub：
https://github.com/XmirrorSecurity/OpenSCA-cli/releases
Gitee：
https://gitee.com/XmirrorSecurity/OpenSCA-cli/releases
OpenSCA官网：
https://opensca.xmirror.cn/
