软件许可证（或软件许可协议）是一种具有法律性质的合同或指导，由软件作者与软件用户签订，用以规定和限制软件用户使用、拷贝、修改和再发布软件（或其源代码）的权利，以及软件作者应尽的义务。

常见许可证及其差异

根据许可证使用时间，软件许可证可分为终身许可证和年度许可证。

  • 终身许可证，顾名思义，便是一旦与软件开发商达成协议，签订合同后可终身无限制的使用该软件。此类许可证多见于个人用户领域。
  • 年度许可证，指的是客户与软件开发商商签订协议，按年付费来使用该软件。此类软件许可证多见于商业软件领域。相比终身许可证，年度许可证不太像是购买软件，而更像是租赁软件使用，不过却更为灵活。

分发（distribution）指将版权作品从一个人转移到另一个人或公司，如果你是自己使用，不提供给他人，就没有分发。云服务（SaaS）不构成分发，即你使用开源软件提供云服务，不必提供源码。但是，Affero GPL (AGPL) 许可证规定云服务也必须提供源码。

常见的许可证主要有 GPL、LGPL、AGPL、MPL、MIT、BSD 和 Apache，各个许可证还包含不同版本。根据使用条件不同，可以将这些许可证大致分为两类：Copyleft 许可证和宽松式许可证（permissive license），主要对使用、修改和分发的场景作出相应约束。

宽松式许可证

最基本的类型，对用户几乎没有限制。

  • 用户可以使用代码，做任何想做的事情，可以修改代码后闭源。
  • 不担保代码质量，用户自担风险。
  • 用户必须披露原始作者。

宽松式许可证都规定分发软件时，必须保留原始的许可证声明，区别在于要求用户遵守的条件不同。

  1. BSD（Berkeley Software Distribution） —— 特点是可以自由使用、修改、再发布。但是在商用或者个人分发过程中必须带有原来代码的许可证，且不能用原作者相关信息去做宣传。
  2. MIT —— 源自麻省理工学院（Massachusetts Institute of Technology, MIT），是使用最广泛的一种开源许可证。其特点和 BSD 许可证类似，只要在项目的所有副本中包含版权声明和许可声明，就无需承担任何责任。
  3. Apache —— 作为宽松式许可证中的一员，Apache 多了几个限制条件，禁止使用其商标与作者的相关信息进行商业行为，必须明确指出所有修改过的文件。

Copyleft 许可证

Copyleft 是一种让程序或其它作品保持自由（是言论自由的自由，而不是“零价格”）的通用方法，并要求对 Copyleft 程序的任何修改和扩展都保持自由。

Copyright 直译是"复制权"，这是版权制度的核心，意为不经许可，用户无权复制。Copyleft 是理查德·斯托曼发明的一个词，与 Copyright 相对，Copyleft 的含义是不经许可，用户可以随意复制。核心是：修改后的 Copyleft 代码不得闭源，比宽松式许可证的限制要多：

  • 如果分发二进制格式，必须提供源码。
  • 修改后的源码，必须与修改前保持许可证一致。
  • 不得在原始许可证以外，附加其他限制。

对用户的限制从最强到最弱排序：AGPL > GPL > LGPL > MPL。

  1. AGPL（Affero 通用公共许可证） —— AGPL 是 GPL 的一个补充，在 GPL 的基础上加了一些限制。GPL 的约束生效前提是该软件 "发布"，有的公司就使用 GPL 组件编写 web 系统，但是不发布系统，只用这个系统在线提供服务，这样就避免了开源系统代码。而 AGPL 要求如果云服务 (即 SaaS) 用到的代码是该许可证，那云服务的代码也必须开源。
  2. GPL（通用公共许可证） —— GPL 和 BSD 区别还是很大的，GPL 主张代码及衍生代码的开源，不允许修改后和衍生的代码做为闭源的商业软件进行发布和出售。如果已发布商业软件源码里含有 GPL 开源软件源码，则必须对该商业软件进行开源或者下架处理。
  3. LGPL（Lesser 通用公共许可证） —— LGPL 允许商业软件通过类库引用的方式使用 LGPL 类库，而不需要开源商业软件源码。
  4. MPL（Mozilla 公共许可证） —— 在商业软件中，如果含有 MPL 许可证的代码在单独的文件内，其他新增的文件就可以避免开源。

如何选择

乌克兰程序员 Paul Bagwell，画了一张分析图，说明应该怎么选择。下面是制作的中文版：

一些示例包括：

  • Apache：需要 Apache 2.0 协议。
  • Cloud Native Computing Foundation：默认规定 Apache 2.0 协议。
  • GNU：建议大多数程序使用 GNU GPLv3 协议。
  • NPM packages：绝大多数使用 MIT 或非常相似的 ISC 协议（等同于 BSD 2 和 MIT）。
  • OpenBSD：更建议 ISC 协议。
  • Rust：程序包基本上都同时使用 MIT 和 Apache 2.0 两个协议来授权。
  • WordPress：插件和主题必须为 GNU GPLv2 协议（或更高版本）。

软件

通常来说，我们推荐使用最 Copyleft 而不影响目的的许可证。对大多数程序，我们推荐使用最新版的 GPL。它强大的 Copyleft 适合所有类型的软件，并对用户的自由有很多保护。为了将来许可证的升级，请声明 “版本 3 或者任何新版本”，这样你的程序就 在许可证层面兼容其他将来按照后续 GPL 版本发布的程序。

小程序

对大多数小程序，使用 Copyleft 是不值得的。我们用300行作为基准：当一个软件包的源码比这个短，Copyleft 带来的好处通常太小，不足以对抗确保许可证的复本总是伴随软件的不便。

对这些程序，我们推荐 Apache 2.0 许可证。这是一个弱的、松散的、“顺从型”（非 Copyleft）软件许可证，它有用于避免贡献者和分发者起诉专利侵权的条目。这并不会让软件避免来自专利的威胁（一个软件许可证是做不到的），但它避免了专利持有者打着自由的幌子发布软件，这种情况下专利持有者会相当于做了一次“诱导转向”，然后要求接受者同意专利证书中的非自由条目。

在不严格的（顺从型）许可证中，Apache 2.0 是最好的；所以如果你要用一个不严格的许可证，不论什么原因，我们推荐用这一个。

库

对于库，我们分三种情形。

  1. 如果你是专有应用开发者使用自由标准的库，那么你就应该对这些库使用宽松的许可证，比如 Apache 2.0 许可证，这样专有应用就容易包含这些库。
  2. 如果开发者已经使用现有的以非自由或不严格的 pushover 许可证发布的库，那么我们建议使用 Copyleft 许可证 LGPL。较为宽松的 GPL（LGPL）允许私有软件开发者使用其保护起来的库，LGPL 提供了给用户自由的弱 Copyleft。
  3. 对于提供了特别设计，并且不会与现有非 Copyleft 或非自由库竞争的，我们推荐使用原始的 GNU GPL。

服务器软件

如果其他人很有可能会给你在服务器上跑的软件制作改进版并且不向其他人分发他们的版本，而且你担心这将把你的版本置于一个不利的地位，我们推荐 AGPL。AGPL 的条目和 GPL 几乎相同，唯一实质的区别是它有一个额外的条件确保通过网络用这个软件的人们可以获得它的源代码。

专利

某些许可证（Apache 2 和 GPL v3 等）包含明确的条款，授予用户许可使用软件所包含的所有专利。BSD 3条款净化版许可证、开放数据库许可证和知识共享许可证明确声明它不授予贡献者专利的任何权利。另一些许可证（BSD、MIT 和 GPL v2）没提到专利。但是一般认为，它们默认给予用户专利许可，不构成侵犯专利。除非有明确的"保留专利"的条款，使用开源软件都不会构成侵犯专利。

案例

  1. 2019 年，在数字天堂北京网络技术有限公司 诉 柚子北京科技有限公司的案件中，柚子北京 由于开发人员在 2015 年使用了 数字天堂 的 HBuilder 软件工具中三款插件的部分源代码，未遵守开源软件许可证，将具有开源要求的软件产品作为商业产品。被开源软件的著作权人诉请违约和侵权，故而承担法律责任。
  2. 2021 年 4 月 30 日，罗盒公司状告风灵公司侵权获赔 50 万元，同时要求风灵公司停止侵权行为。在该案件中原告罗盒公司，独立开发 “罗盒 (Virtual App) 插件化框架虚拟引擎系统 V1.0”（简称 VirtualApp V1.0），在 2016 年引入 GPL3.0 许可证，于 2017 年取得计算机软件著作权登记证书，且声明用于商业用途请购买商业授权。2018 年原告发现名为 “点心桌面” 的软件使用了 VirtualApp V1.0 的代码，经过源码分析对比，发现两者之间高度相似，遂起诉被告福建风灵公司。经法院审判被告赔偿原告为制止侵权行为而支出的合理费用 50 万元。此次判决是中国首个明确 GPL3.0 许可证具有法律效力的案例。
  3. 2021 年 12 月中旬，抖音海外版 TikTok 上线一款名为 TikTok Live Studio 的 APP，有网友发现，此软件违反 GPL 许可证，违规使用开源软件 OBS（一个免费的开源视频录制和视频实时流软件，且允许任何人免费应用和商用）的源代码，既然允许商用，但是为什么还会被曝违规呢？这里就需要再科普一下 GPL 许可证，GPL 许可证具有很强的传染性，如果一款软件使用 GPL 许可证的开源软件源码，那么该软件也必须采用 GPL 许可证，进行开源或者下架处理。此事曝光之后，OBS 开发者证实此事，TikTok 也对此事进行了回应，并删除 TikTok Live Studio 的下载页面。

建议

  1. 软件开发者使用开源软件时，需要谨慎选择开源软件，关注其开源许可证的内容及相关条件，避免潜在的法律风险。
  2. 企业应当建立一个完善机制，识别企业中所使用的开源软件清单，明确对应的开源许可证及权利约束，及时规避相关合规风险。
  3. 通过隔离机制避免开源许可证传染，如对于 MPL 许可证下代码的使用，应把该许可证的代码放在单独的文件内避免许可证传染；LGPL 下的代码，可采用动态链接调用该许可证的库实现隔离。
  4. 有些组件是存在多种许可证的，可能不同目录文件指定的许可证类型不一样，要特别注意。
  5. 有些组件你没有直接依赖，但是可能存在间接依赖的情况，你需要特别注意查看相关组件的依赖关系。
  6. 使用 murphysec 开源工具扫描您的代码目录，它会帮您一键识别出来您的代码项目中使用的所有开源组件，包括直接依赖和间接依赖的组件清单，同时列出所有组件对应的开源许可证信息；根据报告的提示可以明确看到对应组件的许可证在什么场景下存在许可证合规风险；根据许可证的合规风险提示，来判断您的项目是否存在违反的可能性，并调整您所引入的组件，来解决这个风险。

使用

在源代码的根目录中创建一个文本文件（通常命名为 LICENSE 或 LICENSE.txt），并将许可证文本复制到该文件中。将 [year] 替换为当前年份，并将 [fullname] 换为版权所有者的姓名。如果可以，添加软件许可协议到项目程序包的描述中（例如：Node.js、Ruby、和 Rust），这将确保许可证显示在软件包目录中。

参考资料

  1. 附录
  2. 如何选择开源许可证？
  3. 为什么GPL是更好的开源许可证?
  4. 总结了一下程序员们都应该知道的各类开源许可证及合规相关的知识