关于开源:开源许可证保姆级入门手册

5次阅读

共计 3017 个字符，预计需要花费 8 分钟才能阅读完成。

开源许可证是个相当庞杂的领域，仅 OSI (Open Source Initiative, 凋谢源代码促进会) 批准的许可证就有 80 多种；此外，还有数百种在开源生态中流传的其余许可证。

尽管有些开源许可证绝对简洁明了，适宜只想简略公布开源我的项目的人应用；但还有一些许可证十分简短简单，甚至须要业余的法务团队染指。

本文将以比照模式剖析开源许可证相干的一些因素，以便读者疾速清晰地把握这一畛域的基础知识。（省流版许可证抉择倡议见文末~）

开源许可证通常能够分为两大类：宽松式许可证及 Copyleft 许可证（也称著佐权）。二者的差异次要在于宽松度以及与应用开源软件组件相干的要求和许可权限的多少。

当一个开源组件采纳 Copyleft 许可证时，开发人员有权应用、批改和共享该作品，前提是要履行对应的任务。一旦代码中应用了许可证为 Copyleft 类的开源组件，就须要向别人凋谢你的代码。GPL 许可证族是这类许可证中最早呈现也是最风行一种，蕴含许多版本和变种。

与之绝对，宽松式许可证是另一个极其。它保障了应用、批改和从新散发的自在，同时也容许创立专有的派生作品。宽松式许可证对于采纳它的组件的应用简直没有限度，并且简直不须要回报。这类许可证中，最简洁明了和最受欢迎的是 MIT 许可证。

除去这两大类别的差别，每一类下许可证和许可证族也会因为一些附加参数而产生具体差别。

例如，同属宽松式许可证的 MIT 许可证和 Apache 许可证大同小异，同属 Copyleft 类的 Eclipse 许可证和 GPLv3 许可证也并没有共用雷同的条款和条件。

每个开源许可证都有本人独特的限度、条件和权限。GitHub 的 choosealicense.com 旨在帮忙开发人员找到适合的开源许可证；下面提供了一个附录，用于比拟不同许可证，并依据许可证受权和限度的内容比照它们的差异性。

依据这个附录，开源许可证授予我的项目在版权或其余知识产权法律下可能不被容许的行为许可；这些许可通常须要恪守特定条件。大多数开源许可证还具备罢黜担保和责任的限度，有时还明确排除了专利或商标的许可受权。

在开源许可证中，最常被授予权限的行为波及商业应用、散发、批改和私人应用。

其中，一个重要区别是专利应用的许可。许多开源许可证在特定条件下明确授予贡献者的专利权，例如 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 等。

尽管所有开源许可证都会授予商业应用、散发、批改和私人应用的权限，但这些权限受特定条件的束缚；不同许可证的条件各不相同。这些条件可能包含在通过网络或其余渠道散发软件时提供源代码，应用开源我的项目时纳入许可证信息和版权申明，在同一许可证下公布代码批改，记录对代码进行的所有更改等。

通常状况下，Copyleft 许可证比宽松式许可证附带更多条件。随着开源的应用愈发广泛，前者在商业组织中的的风行度也在逐步降落

最典型的例子是 GPL 许可证族对网络散发的限度。尽管 GPL 2.0 和 3.0 的条件并未明确规定网络应用属于散发，但作为公认最强 Copyleft 许可证，AGPL v3.0 要求应用批改后的版本提供网络服务时，必须提供该版本的残缺源代码。

比拟开源许可证的另一种办法是看它们的限度。开源许可证的限度波及责任、明确申明不授予商标权和不提供担保。

对商标应用的限度能够看作一个分野。大多数 GPL 族许可证并没有明确规定不授予商标权，而 Creative Commons 和 Apache v2.0 则明确蕴含这一限度。值得注意的是，GitHub 的 choosealicense.com 指出，没有这种申明的许可证可能不授予任何隐含的商标权力。

尽管 Eclipse 开源许可证（EPL）和 GNU GPL 许可证族都被认为是 Copyleft 许可证，二者宽松水平不同。GNU GPL 许可证族有强制性的 Copyleft 条款，无论用户代码中蕴含多少 GPL 代码，都要公开其软件的残缺源代码。

EPL 算是一种较弱的 Copyleft 许可证。它不要求用户共享其整个软件我的项目，而只需在以源代码模式散发时开源任何蕴含 EPL 组件的源码，并在以对象模式散发时按需提供源代码。

此外，EPL 只要求用户在源码模式散发时中披露局部源代码，对二进制文件模式没有要求；而 GPL 族则要求在源代码和二进制文件的复制或衍生版本中都持续应用同一许可证。

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/

正文完