{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/introduction-of-open-source-license",
"result": {"pageContext":{"blog":{"id":"Blogs_308","title":"一文看懂开源许可证丨开源知识科普","tags":["开源知识科普"],"category":{"name":"观点洞察"},"summary":"PingCAP 从第一行代码开源，六年里积累了一些经验和教训，在《开源知识科普》栏目中，我们将与大家分享和交流在开源成长路径中的思考和感受，以及参与开源项目的正确姿势。本期话题就从开源的基础——开源许可证开始，希望对大家了解开源、参与开源有一定帮助。","body":"> **编者按：** \n> 在很多人眼中，「开源」是一个时髦且有情怀的词汇，始终伴随有理想主义色彩，因此不少公司开始给自己贴上“开源”标签。但一个优秀的开源项目远远不止是简单的公开源代码，而是需要将其当作公司战略进行贯彻，才能架设起牢不可破的信任桥梁。\n> PingCAP 从第一行代码开源，六年里积累了一些经验和教训，在《开源知识科普》栏目中，我们将与大家分享和交流在开源成长路径中的思考和感受，以及参与开源项目的正确姿势。本期话题就从开源的基础——开源许可证开始，希望对大家了解开源、参与开源有一定帮助。\n\n\n近年来，开源正在变得越来越火，我们经常会看到 “某企业宣布开源”、“某开源大会召开”、“某开源项目获得融资”。个人开发者与企业比以往任何时候都更愿意参与到开源项目的建设和贡献中，开源在国内 IT 领域获得了前所未有的热度，也获得了产业界和投资圈的广泛关注。\n\n但总有些人听到开源一词时，就会误以为 “开源软件是免费的，因此我可以不受限制地随意使用”。在开源诞生之初，自由软件是当时的主流提法，回顾开源的发展史，从自由软件到开源运动实现了非常大的跨越，前者更多的是一种精神的倡导，而后者着眼于软件的协同开放，因此会有非常严谨的开源许可证的规则和限制。开源软件能走到今天的发展程度，就是因为有了这么一套遵从开源精神的规则体系，才能够健康发展。开源精神的载体之一就是开源许可证，今天我们就来扒一扒开源许可证与开源的关系，以及它背后折射出的问题。\n\n## 什么是开源许可证？（“Open Source License”）\n\n首先需要明确的是，开源软件源代码的著作权既没有被放弃也没有过期，其修改和发行等仍然要受到著作权法或者开源软件许可证的制约。\n\n我们接触到的开源软件一般都有对应的开源许可证（Open Source License）对软件的使用、复制、修改和再发布等进行限制。许可证即授权条款，开源许可证就是保证开源软件这些限制的法律文件，目的在于规范受著作权保护的软件的使用或者分发行为。**开源许可证是开源软件生态系统的基础，可以促进软件的协同开发**。\n\n## 常见开源许可证\n\n常见的开源许可证主要有 Apache、MIT、BSD、GPL、LGPL、MPL、SSPL 等，可以大致分为两大类：**宽松自由软件许可协议（“Permissive free software licence”）和著佐权许可证（“copyleft license”）**。\n\nPermissive free software licence 是一种对软件的使用、修改、传播等方式采用最低限制的自由软件许可协议条款类型。这种类型的软件许可协议将不保证原作品的派生作品会继续保持与原作品完全相同的相关限制条件，从而为原作品的自由使用、修改和传播等提供更大的空间。\n\n而 Copyleft License 是在有限空间内的自由使用、修改和传播，且不得违背原作品的限制条款。如果一款软件使用 Copyleft 类型许可协议规定软件不得用于商业目的，且不得闭源，那么后续的衍生子软件也必须得遵循该条款。\n\n**两者最大的差别在于**：在软件被修改并再发行时， Copyleft License 仍然强制要求公开源代码（衍生软件需要开源），而 Permissive free software licence 不要求公开源代码（衍生软件可以变为专有软件）。\n\n其中，Apache、MIT、BSD 都是宽松许可证，GPL 是典型的强著佐权（copyleft ）许可证，LGPL、MPL 是弱著佐权（copyleft ）许可证。SSPL 则是近年来 MongoDB 创建的一个新许可证，存在较大争议，开放源代码促进会 OSI 甚至认为 SSPL 就不是开源许可协议。\n\n此外，还有一类是 Creative Commons（CC）知识共享协议。严格意义上说该协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。CC 协议种类繁多，每一种都授权特定的权利。大多数的比较严格的 CC 协议会声明 “署名权，非商业用途，禁止衍生” 条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的 CC 协议类型当属 “署名” 协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。\n\n\n来源：https://moqod.com/mobile-web-software-development/\n\n可以看出，不同许可证之间的差异非常大，你可能会困惑，搞得这么复杂的目的是什么呢？\n这就不得不从**开源的历史**讲起了。\n\n开源这个词最初其实是指开源软件（OSS）。开源软件是源代码可以任意获取的计算机软件，任何人都能查看、修改和分发他们认为合适的代码。**在开源领域中，存在着两大阵营**：FSF（Free Software Foundation，自由软件基金会) 和 OSI（Open Source Initiative，开放源代码促进会），**他们对开源有着不同的理念**。\n\nFSF 是开源泰斗 RMS 创立的重要的开源软件基金会 (1985/10/04), FSF 创立之初主要是为了筹集资金来建设 GNU 的内核 Hurd 项目及工具链，虽然 GNU 项目本身没有完成，但是该过程中创造出的大量软件工具，日后成为了 GNU/Linux 的重要组成部分。为了贯彻 RMS 对 “自由” 和 “开源” 的理解，FSF 建立了开源领域的第一个 “copyleft” 属性的许可证 - GPL (GNU Public License) 。\n\nOSI 由开源界泰斗 Bruce Perens 和 Eric S. Raymond (ESR) 在 1998 年组建，目的是在原教旨主义开源 (最早的开源运动发起和推动者们) 与软件工业/商业之间激烈矛盾中，寻求更平衡的体系和治理机制。OSI 组织批准过的许可大概有 80 种，包括 Apache License v2、GPL v2、MIT/BSD 等。\n\nFSF 与 OSI 是推广和维护开源秩序的非盈利组织，维护着 “开源” 的定义以及主要的开源软件协议递交、讨论与审核。只要条款被审核通过是符合开放源代码定义的，就可以称之为开放源码授权条款，采用开放源码条款散布授权的软件即是开放源码软件，若一份商业产品中包含有开放源码软件，其包装上可以标上开放源码促进会的证明标章，认识这个标章的消费者就可以知道产品中有使用到开放源码软件，进而因为开放源码软件特有的优点而购买产品。\n\n\n\n下面，我们通过一张表来简单了解一下常见开源许可证之间的区别：\n\n\n来源：https://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html\n\n其中，Apache 许可证（Apache License）license 是一个由 Apache 软件基金会发布的自由软件许可证，最初为 Apache http 服务器而撰写。此许可证最新版本为 “版本 2”，于 2004 年 1 月发布。**Apache 许可证鼓励代码共享和最终原作者的著作权，允许源代码修改和再发布**。但是需要遵循以下条件：\n\n- 需要给代码的用户一份 Apache Licence；\n- 如果修改了代码，需要在被修改的文件中说明；\n- 在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明；\n- 如果再发布的产品中包含一个 Notice 文件，则在 Notice 文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但是不可以表现为对 Apache Licence 构成更改；\n- Apache Licence 也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足并作为开源或商业产品发布/销售。\n\n例如，在一个使用 Apache 许可证的开源项目中，其下游 Fork 的企业不仅没有回馈上游开源项目，反而将衍生的代码更改为不受 OSI 认可的 SSPL Licence，另行宣布成为一个新的开源项目，误导了很多不明真相的人，以为又涌现出一个新的开源项目。但该行为其实已经对原开源项目的合法权益造成了侵害，也有背开源精神。\n\n作为从第一天就以开源作为发展基础的开源基础软件公司，PingCAP 鲜明地反对一些在开源软件领域 “**违背开源精神，破坏游戏规则**” 的行为。\n\nPingCAP 目前开源的项目包含 TiDB、TiKV 及 Chaos Mesh，都是基于 Apache 2.0 的协议来开发和运营的，任何个人、公司、云厂商，只要不违反 Apache 2.0 协议的相关规定，都可以自由地去下载、研读、改写、编译原代码，甚至可以发行自己的发行版，进行相应的商业活动。\n\nPingCAP 在设计这个公司的时候，就在为开源做持续贡献的设计作准备，比如在开源治理体系上，我们认为自己就是开源技术体系的一部分，并设有专门的团队持续运营开源社区。\n\n在开源技术体系中，开源社区是整个新技术创新的上游源头，也是创新技术的孵化器。开源社区不断推动各种开源项目，并通过全球协作实现产品的快速迭代。通过这种源头创新的方式，可以不断把创新技术通过全球社区协作的方式 “生产” 出来，**开源社区实际上已经变成了新技术的创新引擎**。\n\n在刚刚发布的《开源社区成熟度研究报告》 2.0 中，TiDB 社区被作为开源社区运营和治理实践典范作为研究对象，探索开源社区的健康可持续发展。报告中还首次提出了**开源社区成熟度模型与开源社区度量体系**，对开源感兴趣的同学可以[点此查看](https://pingcap.com/zh/insight-detail/open-source-community-maturity)。\n\n作为开源生态的一员，我们欢迎任何人参与到开源事业中，共同繁荣开源领域，开源今天的局面来之不易，需要所有参与其中的人共同维护，敬畏游戏规则，遵从开源精神，才能创造开源的美好明天。\n\n\n\n**附：常见开源许可证介绍**\n\n- **Apache**：Apache 许可证（Apache License），是一个由 Apache 软件基金会发布的自由软件许可证，最初为 Apache http 服务器而撰写。Apache 许可证要求被授权者保留著作权和放弃权利的声明，但它不是一个反著作权的许可证。此许可证最新版本为 “版本2”，于 2004 年 1 月发布。Apache 许可证是宽松的，因为它不会强制派生和修改作品使用相同的许可证进行发布。\n\n- **MIT**：MIT 许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称 “ X 条款”（X License）或 “ X11 条款”（X11 License）。MIT 内容与三条款 BSD 许可证（3-clause BSD license）内容颇为近似，但是赋予软件被授权人更大的权利与更少的限制。有许多团体均采用 MIT 许可证。例如著名的 ssh 连接软件 PuTTY 与 X Window System (X11) 即为例子。Expat 、Mono 开发平台库、Ruby on Rails、 Lua 5.0 onwards 等等也都采用 MIT 授权条款。\n\n- **BSD**：BSD 许可协议（ Berkeley Software Distribution license ）是自由软件中使用广泛的许可协议之一。BSD 就是遵照这个许可证来发布，也因此而得名 BSD 许可协议。BSD 包最初所有者是加州大学的董事会，这是由于 BSD 源自加州大学伯克利分校。BSD 开始后，BSD 许可协议得以修正，使得以后许多 BSD 变种，都采用类似风格的条款。跟其他条款相比，从 GNU 通用公共许可证（GPL）到限制重重的著作权（Copyright），BSD 许可证比较宽松，甚至跟公有领域（Public Domain）更为接近。事实上，BSD 许可证被认为是 copycenter（中间著作权），介乎标准的 copyright 与 GPL 的 copyleft 之间。\"Take it down to the copy center and make as many copies as you want\"。可以说，GPL 强迫后续版本必须一样是自由软件，BSD 的后续版本可以选择要继续是 BSD 或其他自由软件条款或闭源软件等等。\n\n- **GPL**：GPL 协议和 BSD、Apache Licence 等鼓励代码重用的许可很不一样。GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。由于 GPL 严格要求使用了 GPL 类库的软件产品必须使用 GPL 协议，对于使用 GPL 协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用此作为类库和二次开发的基础。\n\n- **LGPL**：LGPL 是 GPL 的一个为主要为类库使用设计的开源协议。和 GPL 要求任何使用/修改/衍生自 GPL 类库的的软件必须采用 GPL 协议不同。LGPL 允许商业软件通过类库引用 (link) 方式使用 LGPL 类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。但是如果修改 采用 LGPL 协议的代码或者对其进行衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此采用 LGPL 协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以采用 LGPL 协议的代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。\n\n- **SSPL**：SSPL 是 MongoDB 创建的一个源码可用的许可证，以体现开源的原则，同时提供保护，防止公有云供应商将开源作品作为服务提供而不回馈此开源作品。SSPL 允许自由和不受限制的使用和修改开源作品，但如果你把此开源作品作为服务提供给别人，你也必须在 SSPL 下公开发布任何修改以及管理层的源代码。开放源代码促进会 OSI 对 SSPL 颇有微词，它认为 SSPL 不是开源许可协议，实际上是一个源代码可用的许可证。\n\n- **Elastic License**：Elastic License 是非商业许可证，核心条款是如果将产品作为 SaaS 使用则需要获得商业授权。","date":"2021-10-20","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"introduction-of-open-source-license","file":null,"relatedBlogs":[]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}