持续创造，加快成长！这是我参加「日新计划 10 月更文应战」的第10天，点击检查活动详情

介绍

软件答应证（或软件答应协议）是一种具有法令性质的合同或指导，由软件作者与软件用户签定，用以规则和束缚软件用户运用、拷贝、修正和再发布软件（或其源代码）的权力，以及软件作者应尽的责任。

常见答应证及其差异

根据答应证运用时间，软件答应证可分为终身答应证和年度答应证。

  • 终身答应证，望文生义，便是一旦与软件开发商达成协议，签定合同后可终身无束缚的运用该软件。此类答应证多见于个人用户领域。
  • 年度答应证，指的是客户与软件开发商商签定协议，按年付费来运用该软件。此类软件答应证多见于商业软件领域。相比终身答应证，年度答应证不太像是购买软件，而更像是租赁软件运用，不过却更为灵活。

分发（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. 总结了一下程序员们都应该知道的各类开源答应证及合规相关的知识