跳转至正文
开源

理解开源软件许可证

开源软件许可证大致分为两类:一类是 copyleft 许可证,另一类是宽松型开源许可证。

理解开源软件许可证

开源软件许可证大致分为两类:一类是 copyleft 许可证,另一类是宽松型开源许可证。

在本文中,我将解释什么是开源软件许可及其类型。

简介

开源许可证是一种允许用户自由查看、修改和分享软件源码的许可类型。通过这种方式,用户能够频繁更新 code 源码,并在原始产品的基础上进行开发。

根据所选的开源许可证类型,用户对 code 进行某些操作(例如出售或商业使用)的权限会有所不同。此外,开源许可证有很多不同类型,每种都会根据你使用源材料的方式提供不同的条款和条件。

因此,在利用其优势之前,充分了解某种开源许可证类型很重要。在做任何决定前,请务必阅读下文了解更多。

开源许可证类型

开源许可证类型

宽松许可证

宽松许可证(有时也称为非 Copyleft 许可证)允许用户使用、修改和共享源码 code,但用户也可以选择在重新分发(包括衍生作品)时更改其中部分条款和条件。在软件语境下,衍生作品是指基于现有程序开发的软件。如果原作品是在宽松许可证下发布的,创作者可以选择用与原作品许可证不同的条款来分享其衍生作品。

Copyleft 许可证

开源中的 Copyleft 许可证赋予开源软件用户与作者相同的自由,可以修改、使用和重新分发软件。但它要求用户将特定权利传递给下游用户,即授予他们最初获得的相同权利。

Copyleft 许可证规定了 code 可以如何被重新分发和修改,禁止任何将其变为专有或闭源的尝试。这确保修改软件的开发者能获取源代码 code,以便更新甚至合并自己的更改。当然,任何修改也必须公开,让其他人也能从其开源可用性中受益。这在学术或研究场景下不是问题,但在构建商业软件时往往是个劝退点。

为什么要包含开源软件许可证?

当你以开源形式发布或分享软件时,附带一份开源软件许可证至关重要。许可证有以下几个重要作用:

  • 促进协作与创新。

开源许可证允许任何人查看、修改和分发你软件的源代码 code。这能鼓励其他开发者为你项目做贡献、修复 bug 并添加新功能,从而打造出更健壮、更具创新性的软件产品。

  • 让用户拥有更多控制权和灵活性。

开源许可证通常允许用户出于任何目的(包括商业用途)使用、修改和分发软件。这让用户对软件使用体验拥有更多控制权,并减少了对专有软件供应商的依赖。

  • 围绕你的软件建立社区。

开源许可证可以帮助你建立一个对你的软件充满热情的开发者和用户社区。这个社区能为你的项目提供支持、反馈和新创意。

  • 让你的软件更易于获取且更具包容性。

开源软件通常可以免费下载和使用,并且通常支持多种语言。这使得全球各地的人们无论收入或背景如何,都能更轻松地使用它。

除了这些好处,开源许可证还可以帮助你:

  • 避免版权侵权。

如果你在没有许可证的情况下分发软件,可能会面临版权侵权诉讼的风险。开源许可证明确授予用户使用、修改和分发软件的权限,从而保护你免受法律责任。

  • 吸引并留住顶尖人才。

许多优秀的软件开发者会被开源项目吸引。通过使用开源许可证发布软件,你可以让公司对潜在员工更具吸引力。

  • 提升品牌声誉。

开源软件在技术社区中备受尊重。通过使用开源许可证发布软件,你可以展示对协作与创新的承诺。

oss_licence(1)

宽松型软件许可证(Permissive licenses)是最受欢迎的许可证类型之一。本质上,这类许可证允许用户在极少限制下随意修改和重新分发软件。三种最流行的宽松型许可证是:

MIT 许可证

本指南中介绍的 MIT 许可证 是最流行、最宽松的开源软件许可证之一。它赋予用户极大的自由度,只要遵守许可证中规定的所有条件,用户就可以自由地分享、修改、使用以及将相关材料商业化。

Apache License 2.0

Apache License 2.0 是一种流行的宽松型软件许可证,允许用户自由修改和重新分发软件,同时确保由此产生的版权声明和通知保持原样。这种开源许可证允许专有修改和再分发,并提供清晰的许可条款,让任何人在使用软件时都能明确自己的权利。

BSD (Berkeley Software Distribution) 许可证

GitHub 让你可以在两种 BSD 许可证之间选择,分别是 BSD 2-Clause “Simplified” License,有时也被称为 “FreeBSD” 许可证;以及 BSD 3-Clause “New” 或 “Revised” 许可证. 这两种许可证的主要区别在于 3-clause 条款。该条款限制软件用户使用作者、作者群或贡献者的姓名来为产品或服务背书。

Boost Software License

Boost Software License,源自 C++ 的 Boost Libraries,并于 2008 年获得 OSI 批准。该许可证与 MIT 和 BSD 类似,不同之处在于以二进制形式重新分发时不需要保留署名。

Copyleft 开源软件许可证

Copyleft 许可证允许软件用户使用、修改和共享 code 源码,但通过特定的限制和条款条件防止重新授权。这体现了该许可证的互惠特性,即要求用户的作品必须遵守原许可证中规定的权利。

GNU 许可证 谈到 Copyleft 软件许可证时, GPL (通用公共许可证) 是最受欢迎且应用最广泛的之一。只要用户保留某些条件(如版权声明、免责声明或添加到未修改程序中的任何其他许可证),该开源许可证就授予用户分发程序副本及修改版本的自由。

通过使用此类许可证发布软件,开发者可以确保他人能够访问其源代码 code,从而允许社区进行改进和适配,造福整个生态。此外,“copyleft”这一概念确保了任何人在使用自由软件时,都能协作共享同样的权利。

Mozilla Public License

本指南中介绍的 Mozilla Public License(简称 MPL)由 Mozilla 基金会 推出,也被认为是一种弱 copyleft 许可证。与 Eclipse Public License 相比,该许可证的区别在于它是基于文件的 copyleft,这意味着 code 可以与开源或闭源的 code 相结合。

Eclipse Public License

本指南中介绍的 Eclipse Public License由 Eclipse Foundation 推出,也被认为是一种弱 copyleft 许可证。弱 copyleft 许可证要求软件用户分享其对 code 所做的任何更改。该许可证选择采用较弱的 copyleft 机制,旨在减轻用户在使用 GNU General Public Licenses 时面临的严格限制。

如何为你的项目选择合适的许可证?

  • 如果你打算以开源协议发布项目,请选择一个与你所使用的项目兼容的协议。

  • 如果你希望允许他人将你的项目用于商业用途,请选择允许此类行为的协议。

  • 如果你希望允许他人修改并分发你的项目,请选择允许此类行为的协议。

  • 如果你想确保你的项目始终保持免费且开源,请选择 copyleft 协议。

  • 如果你不确定该选择哪种协议,可以参考 Open Source Initiative 提供的常用协议列表进行对比。

为开源项目选择正确的协议是一项重要的决策。通过仔细权衡你的需求和目标,你可以选择一个有助于实现预期结果的协议。

Capgo 新许可证

我该如何实现这一切?通过更改我的协议。

Capgo 现在已将协议从 MIT 更改为名为 GNU Affero General Public License V3 (AGPLv3) 或任何更高版本的全新协议。Capgo 版本可以在 此处找到.

Capacitor-updater (该 plugin) 现在已将协议从 LGPLv3 更改为名为 Mozilla Public License Version 2.0 (MPLv2) 或任何更高版本的全新协议。Capacitor-updater 版本可以在 此处找到.

对于订阅 Capgo Cloud 或自托管 Capgo 的用户来说,这一变化没有任何影响;但它可能会让一些试图利用我的软件直接与我竞争却不回馈社区的企业感到不满。

Google 对 AGPL 许可持有保留意见,因为他们不愿公开其闭源的 code。Google 反对 AGPL,并且 声明:“Code 在 GNU Affero General Public License (AGPL) 许可下,严禁在 Google 内部使用”。

AGPL 的目标是最大限度地保障用户自由,并鼓励公司向开源社区回馈。我是一个面向用户的独立应用程序,而非库或大型项目的一部分。我并不寻求 Google 的捐赠,因此我们很乐意采用 AGPL 许可。这对 Capgo 来说是最合适的许可方式。

总结

选择开源软件许可时需要考虑许多因素。不过,开发者社区中确实有一些主流选择。常见的宽松型许可(permissive licenses)包括 MIT License、Apache License 和 BSD License。一些常见的传染型许可(copyleft licenses)则包括 GNU General Public License 和 Mozilla Public License。

继续阅读:理解开源软件许可证

如果你正在使用 理解开源软件许可证 要规划 live update 的交付,请将其与 Capgo Live Updates 用于 Capgo Live Updates 中的产品工作流, 概览 用于 Overview 中的实现细节, 功能 用于 Features 中的实现细节, 更新行为 有关 Update Behavior 中的实现细节,请参阅 更新类型 关于 Update Types 中的实现细节。

为 Capacitor 应用提供 Live Updates

当 Web 层出现线上 Bug 时,通过 Capgo 发布修复,而不用等 App Store 审核好几天。用户会在后台收到更新,原生变更则仍走正常审核流程。

博客最新动态

Capgo 为你提供打造真正专业的移动应用所需的最有价值的洞察。