CSTOS

人生苦短 Python水深

0%

代码协议综述

发表于 更新于 分类于
本文字数： 4k 阅读时长 ≈ 15 分钟
记录常见**代码开源协议**的相关常识。主要包括：概述、目的：、软件分类、名词解释、Apache、BSD、MIT、AGPL、LGPL、MPL、CDDL、EPL、wtfpl。

概述

目的

  • 使用开源代码，不要重复造轮，提高开发效率，节省成本。
  • 了解许可协议，规避知识产权等商业纠纷。商业产品 No GPL。
  • No GPL：GPL 的软件、社区软件、个人软件等是不允许用于商业用途的，也就是说这类软件不能成为商业软件的任何部分（如格式、协议或模块等），除开发 GPL 软件或个人学习、生活使用外！所以在商业使用自由软件时，需仔细辨别该软件的版权声明！
  • 代码协议：Protocols
    • gfdl：可改、可商用、可发表，便要标注版权
    • apache：改后要加版权声明
    • mit：使用原名用于宣传
    • bsd：不能使用原名用于宣传
    • mpl：修改代码后，上下游开源
    • gpl：所有组件都开源
    • lgpl：只引用库不修改
    • GPLv2：不需要开源硬件
    • GPLv3：需要开源硬件
    • AGPL：需要开源服务器源码

软件分类

  • 专有软件：需购买才能用，只能用，不能修改、分发等
  • 共享软件：类似于专有软件，在购买前试用
  • 免费软件：可自由分享与使用，但闭源
  • 开源软件/自由软件：可自由使用软件与源代码

名词解释

Contributors：贡献者：对某个开源软件或项止提供了代码发布的人或实体（团队、公司、组制等），按参与时间可分为 an initial Contributor 创始人 和 subsequent Contributors 参与者 .
Recipients：开源软件或项目的获取者，subsequent Contributors 也属于 Recipients 之列
Source Code：各种语言写成的源代码
Object Code：Source Code 编译后生成的类似“类库”的，提供接口供他人使用的目标代码，如 DLL、ActiveX、OCX 等。
Derivative Module：衍生模块：依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码，是对“源代码模块”的增强、改善和延续。
Separate Module：独立模块：参考或借助“源代码”开发出来的独立的，不包含、不依赖于原“源代码模块”的功能模块。

Permissive 许可证

Permissive License（宽松式许可证）允许用户不经许可可以随意复制、修改和发布，但是并不要求分发时必须使用相同的许可证，用户可以在修改代码后选择闭源，常见的 Apache、BSD、MIT 属于 Permissive 许可证。

Apache

Apache License：非盈利开源组织 Apache 采用的协议。商业应用友好，可改，可重发，可闭源商业发布与销售。

  • 需遵守以下规则：
  1. 必须在源代码中保留原始的 Apache 许可证声明。
  2. 如果用户修改了源代码，需要在被修改的文件中说明。
  3. 在衍生产品中，必须保留原来代码中的版权、专利、商标及作者规定的其他需要包含的说明等信息。
  4. 如果在分发的软件中包含 Notice 文件，则需要在 Notice 文件中包含 Apache 许可证声明。
  • 使用 Apache 2.0 许可证的应用案例包括：Apache 家族系列产品，如 Hadoop, OpenOffice, Spark，SVN, 以及 Swift、Kubernetes、Android Open Source Project (AOSP) 等。

BSD

BSD：Berkerley Software Distribution：伯克利软件发行版：商业软件可用。源代码可改，可重以，可闭源商业发布与销售。

  • 目前分为 BSD 3-Clause 和 BSD 2-Clause。顾名思义，3-Clause 包含 3 个条款，2-Clause 只有两个。需要遵守以下规则：

    1. 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的 BSD 协议。
    2. 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的 BSD 协议。
    3. 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。（仅 3-Clause 需要遵守）

  • 应用案例：Chromium，Django，FreeBSD，Nginx 等。

  • 商业集成 OK，公司选用开源工具时的首选，完全控制代码，自由使用，自由改源码，可改代码后再发布

MIT

MIT：Massachusetts Institute of Technology：源自麻省理工学院，与 BSD 一样自由的许可协议。源代码可改，可重以，可闭源商业发布与销售。

类似于 BSD-2-Clause

即需要遵守以下规则：

  1. 如果分发的软件包含源代码，则必须在源代码中保留原始的 MIT 许可证声明。
  2. 如果分发的软件仅包含二进制程序，则必须在文档或版权说明中保留原始的 MIT 许可证声明。
  • 使用 MIT 许可证的应用案例包括：Bootstrap, jQuery, Node.js, Rails 等。

Copyleft 许可证

  • Copyright（版权） 的意思是未经许可，用户无权复制和使用。Copyleft License（反版权许可证） 作为 Copyright 的反义词，意为未经许可，用户也可以随意复制、修改和发布，但要求分发者必须使用相同的许可证发布修改后的衍生作品，以保证衍生作品也能被其他人自由使用，常见的 AGPL, GPL, LGPL, MPL 属于 Copyleft 许可证。

GPL 2.0

GPL：GNU General Public License：GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。

  • 传染性：只要在一个软件中使用 (“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用 GPL 协议,既必须也是开源和免费。
  • 对商业发布的限制：“GPL 是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权.你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本.GP 对软件发行版本唯一的限制就是: 你的发行版本必须把完整的源代码一同提供.”
    • 规则：
      1、确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码
      2、GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
      3、无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
      4、开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
  • 商业软件不能使用 GPL 协议的代码。
    • 因为只要软件中引用及修改了 GPL 代码或者链接了 GPL 类库，整个软件就就必须遵循 GPL，不仅需要公开所有源码，并且允许他人可以自由地复制和分发。
  • 使用 GPLv2 许可证的应用案例包括：Linux 内核、MySQL 等。

GPL 3.0

GPL：GNU General Public License：商业软件不可用，传染性。对这种源代码可改、可发布，但必须公开改后的所有源代码，且改出来的东西也是 GPL 协议的。

  • GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
  • GPLv3 包含了明确的专利许可以及添加了对数字版权管理和加密签名的限制，不仅要求用户公开源码，还要求公布相关硬件及必要的安装信息。
  • GPLv3 能与更多的许可证兼容，例如 Apache 2.0，但这个兼容是单向的，即 GPLv3 许可证的项目中可以包含 Apache 2.0 的开源代码，但是 Apache 许可证的项目不能包含 GPLv3 的开源代码。值得注意的是，GPLv3 与 GPLv2 却并不兼容，即一个项目中不能同时包含 GPLv2 和 GPLv3 的代码，但是，如果软件以 GPL “v2 或更高版本”许可证发布，则与 GPLv3 兼容。
  • 使用 GPLv3 许可证的应用案例包括：GCC，Emacs 等。

AGPL

AGPL 是对 GPL 的补充，如果使用了 AGPL 代码的软件是一个网络应用，那么这个软件的所有源码和修改代码也必须开源，除非购买了该 AGPL 代码的商业授权。

使用 AGPL 许可证的应用案例包括：BerkeleyDB，MongoDB (2018 年 10 月前发布的版本)，Wiki.js 等。

LGPL

LGPL：GNU Library or “Lesser” General Public License：商业软件可以使用，但不能修改 LGPL 协议的代码。

  • 与 GPL 的强制性开源不同的是，LGPL 允许商业软件通过类库引用 (link) 的方式使用 LGPL 类库而不需要开源商业软件的代码。
  • 但是如果修改 LGPL 协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此 LGPL 协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以 LGPL 协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
  • 要点：商业软件可以使用，但不能修改 LGPL 协议的代码。
  • 可以私有使用 LGPL 授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在 LGPL 或其它 GPL 变种的授权下。
  • GPL/LGPL 都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品.

和 GPL 相比，LGPL 限制更少，是一个主要为类库使用设计的开源协议，需要遵守以下规则：

  1. 如果软件通过动态链接的方式使用 LGPL 类库，则该软件不需要开源。
  2. 如果软件通过静态链接的方式使用 LGPL 类库，则软件作者必须提供程序的二进制目标文件（不需要提供源代码），以便用户有机会更新 LGPL 类库并重新链接到该程序。
  3. 如果修改了 LGPL 的源码或者衍生了新的代码，则所有修改后及衍生的代码也必须遵循 LGPL 许可证。

使用 LGPL 许可证的应用案例包括：7-Zip，GLib，uClibc 等。

MPL

MPL：Mozilla Public License 1.1：商业软件可以使用，也可以修改 MPL 协议的代码，但修改后的代码版权归软件的发起者。

MPL ( Mozilla Public License 1.1 ) MPL 协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但 MPL 是允许修改，无偿使用得。MPL 软件对链接没有要求。

  • MPL License 由 Mozilla 基金会开发并维护，介于 BSD（衍生代码可以闭源）和 GPL（衍生代码必须以 GPL 方式开源）之间，最新发布的 2.0 版以更简洁和更好的兼容其他协议为目标，鼓励企业和开源社区为开发核心软件做更多贡献。使用 MPL 源码需要遵守以下规则：
  1. 如果修改了 MPL 的源码或者衍生了新的代码，并且以源代码方式发布的文件，则所有修改后及衍生的代码也必须遵循 MPL 许可证。
  2. 如果用户自有的源码通过专用接口访问 MPL 的源码及类库，则包含专用接口的代码必须遵循 MPL 许可证，用户自有源码不必遵循 MPL 许可证。
  3. 用户获得 MPL 代码中的专利许可，但是不能使用其原始商标。

使用 MPL 许可证的应用案例包括：Mozilla Firefox, Mozilla Thunderbird, Apache Flex, LibreOffice 等。

要点：商业软件可以使用，也可以修改 MPL 协议的代码，但修改后的代码版权归软件的发起者。

CDDL

CDDL (Common Development and Distribution License )：商业软件可以使用，也可以修改 CDDL 协议的代码。
CDDL（Common Development and Distribution License，通用开发与销售许可）开源协议，是 MPL（Mozilla Public License）的扩展协议，它允许公共版权使用，无专利费，并提供专利保护，可集成于商业软件中，允许自行发布许可。
要点：商业软件可以使用，也可以修改 CDDL 协议的代码。

EPL

EPL：Eclipse Public License：商业软件可以使用，也可以修改 EPL 协议的代码，但要承担代码产生的侵权责任。

  • EPL License 由 Eclipse 基金会开发并维护，在 CPL 基础上删除了专利相关诉讼的限制条款。EPL 比 GPL 许可证更为宽松，并且与 GPL 并不兼容。使用 EPL 源码需要遵守以下规则：
  1. 如果修改了 EPL 的源码或者衍生了新的代码，并且以源代码方式分发，则所有修改后及衍生的代码也必须遵循 EPL 许可证。
  2. 如果软件以二进制目标文件的形式分发，则需要声明可以根据请求向其他用户提供源代码。
  3. 用户获得 EPL 代码中的专利许可。

使用 EPL 许可证的应用主要为 Eclipse 基金会名下的软件，如著名的集成开发工具 - Eclipse。

使用 EPL 协议，需要遵守以下规则：

  1. 当一个 Contributors 将源码的整体或部分再次开源发布的时候,必须继续遵循 EPL 开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner 的授权；2. EPL 协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是 Object Code 的时候,你必须声明它的 Source Code 是可以获取的,而且要告知获取方法；3. 当你需要将 EPL 下的源码作为一部分跟其他私有的源码混和着成为一个 Project 发布的时候,你可以将整个 Project/Product 以私人的协议发布,但要声明哪一部分代码是 EPL 下的,而且声明那部分代码继续遵循 EPL；4. 独立的模块 (Separate Module),不需要开源。
    要点：商业软件可以使用，也可以修改 EPL 协议的代码，但要承担代码产生的侵权责任。

wtfpl

  • wtfpl：DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
相关文章
给博主来一杯卡布奇诺