文档备案控制台登录立即注册
首页文章问答视频活动下载资源团队号镜像站

漫谈开源许可证：开发者需要知道的法理和事例

字节跳动开源
字节跳动开源
技术
技术

picture.image

来源｜字节跳动 Web Infra - Web Solutions 团队

感谢字节跳动开源法务 @孙振华 提供的专业指导和修改意见。

本文仅供开发者探讨，不构成任何法律意见。如有需求请咨询公司法务或者律师。 开源许可证是开源软件的基础，它规定了开源软件的使用、修改和分发的条件。对于开发者和使用者来说，了解开源许可证的定义、法律原理和常见许可证是非常重要的。选择合适的开源许可证也是一个关键的决策，因为它将直接影响到软件的使用和分发。此外，在实践中，开源许可证也可能会引起一些问题，因此使用者和开发者需要注意一些细节。

在本文中，我们将全面介绍开源许可证的各个方面，以帮助贡献者和使用者更好地了解和使用开源软件。

0 1

开源软件

我们日常讨论中提及的 “开源软件” 通常是一个很模糊的概念，在详细介绍有关开源许可证的内容之前我们需要先辨明这个词的定义。

picture.image 图片来源：维基百科

维基百科相关条目有这样一张信息量很大的图片，描述了各种许可下的软件分类。这里我们可以先将开源软件等价于图中的 FOSS 软件，然后根据这张图可以有以下解读：

  • 开源软件 ≠ 免费软件

“自由软件”是关乎自由的问题，与价格无关。要理解这个概念，你要按照 Free Software 中的“Free”是指“自由言论（free speech）”中的自由，而非“免费午餐（free lunch）”的免费这一意项。

  • 自由但不免费：Red Hat Enterprise Linux 对任何人开放源代码，但用户需要付费才能使用基于其商标授权的软件和售后服务
  • 免费但不自由：所有允许用户免费使用的专有软件（如 Google Chrome，基于 Chromium 添加了一些专有代码）
  • 开源软件 ≠ 源码可得的软件

前者强调用户对软件源码修改、再分发、版权 & 专利上的权利，后者在口语中常被误认为等价于开源软件，但它仅代表用户能够访问源代码、并不代表用户能够如期所愿地利用这些代码

  • 源码可得的软件 = FOSS 软件 + 源码可得的专有软件
  • 不自由但源码可得的软件：Unreal Engine 允许用户在签署 EULA 后访问和贡献其源码，但其仍然是为 Epic 公司所有的专有软件，用户并没有开源许可证通常会授予的再分发、专利等方面的相关权利。
  • Free (Libre) software ≠ Open source

从官方定义上看自由软件和开源软件都是源码可得的，将两者特地做区分应该是出于意识形态。

自由软件定义：... 作为前提，用户必须可以访问到该软件的源代码。

自由软件社区有两大政治阵营：自由软件运动和开源。自由软件运动是为 计算机用户自由 而进行的活动；我们认为非自由程序是对用户的不公正。开源阵营刻意避开用户公正的问题，转而以 仅仅实用的益处 来立意。

02

开源许可证

开源许可证可以看作是一种项目所有者与用户之间签订的合同，用户通过遵守许可证的要求来获取其授予的权利。作品没有依据任何开源许可证发布的话，根据著作权法默认不授予第三人权利，而非进入共有领域。用户如果不接受条款那也就没有权利复制和分发这些项目及其派生作品。

注意：在美国法律中许可证与合同两个概念存在显著区别。

维基百科根据授予使用者权利的不同，将软件授权方式进行如下划分。以下表格修改和翻译自相关条目：

picture.image

picture.image

当我们在说 开源许可证 的时候，其实我们在说的是这些当中的 宽松许可 和 Copyleft 互惠性条款 ：

宽松许可： 利用现有著作权法来保证使用和创作的自由，有时也被称为 Copycenter 许可。

宽松许可是一种对软件的发布 / 传递有最低要求的开源软件许可类型。因此，这种许可协议将不保证被使用软件的派生版会继续保持自由软件的形式。与此相对的是有着互惠／相同方式共享要求的许可协议。这两种开源许可证都对软件可以如何使用、研究或修改提供同样自由。其主要差别是，当软件被分发（不论有无被修改）时， 宽松许可允许分发者限制他人对源代码的获取权 ，而 copyleft 许可则不允许这种限制。

Copyleft 许可 ：利用著作权法要求被授权者使用同样授权分发派生作品，以进一步促进这种自由。

Copyleft 源自自由软件运动，是一种 利用现有著作权体制来保障用户自由使用软件权利的许可方式 ，可以了解为 允许他人使用、传播但也存在一些限制 。根据 Copyleft 类型的许可发布的开源软件除了允许用户自由使用、散布、修改以外，Copyleft 许可要求被许可人对修改后的派生作品以相同的许可证发布，以保障其后续所有派生作品都能被任何人自由使用。与宽松许可证相比，Copyleft 许可被认为具有保护伞且互惠的作用，与现有著作权体制默认限制著作内容传播的理念完全相反。

Copyleft 许可方式虽然与常见的著作权许可模式不同：选择 Copyleft 许可方式并不代表作者放弃著作权，但与目前限制著作内容传播的著作权体制不同，Copyleft 是贯彻始终，强制被授权者使用同样许可证发布派生作品， Copyleft 许可协议不反对著作权的基本体制，却是透过利用著作权法及灵活的许可机制来进一步地促进创作自由并保障著作内容传播。

Copyleft，不是反著作权运动，不主张废止著作权，也不是公有领域。

公有领域的软件通常也被认为属于开源的范畴，但当我们在讨论开源许可证时主要在讨论的是其条款内容对开源社区的积极促进作用。

正式一点，可以形象地说：你有了大公司用来锁定一切行动的 Copyright；也有以自由软件的方式来确保那些行动无法被锁定的 Copyleft；于是伯克利加州大学就有了我们现在所谓的 copycenter，意即“把它放进复印机里，然后你想复制几份就几份吧。”

——柯克·麦库惜克，BSDCon 1999

通常主流的开源许可证都会要求在发布代码和二进制应用的时候都需要携带 “许可与版权声明”，这是因为：

如果你给别人一份软件的副本，你需要包括许可证文本和任何版权声明。这有几个关键目的：

  1. 给别人一个声明，说明他们有权使用该公共许可证下的软件。这是直接授权模式的一个关键部分，在这种模式下，每个用户直接从版权持有人那里获得许可证。
  2. 让人们知道谁是软件的幕后人物，这样他们就可以得到赞美、荣耀和冷冰冰的现金捐赠。
  3. 确保保修免责声明和责任限制（在后面）伴随该软件。每个得到该副本的人也应该得到一份这些许可人保护的副本。

没有什么可以阻止你对提供一个副本、甚至是一个没有源代码的编译形式的副本而收费。但是当你这么做的时候，你不能假装 MIT 代码是你自己的专有代码，也不能在其他许可证下提供。接受的人要知道自己在“公共许可证”下的权利。

03

贡献者许可协议

开源许可证通过灵活的运用知识产权许可来实现开放共享的开源社区的可持续发展，而非仅仅从知识产权专有性、排他性的角度出发来限制用户的权利。

但是同样站在知识产权法律的传统视角上看，很多开源项目的权利归属都有问题：项目的贡献者们分别拥有自己编写的那段代码的所有权，而维护者可能无法全权处置这些代码。这时候就需要引入贡献者许可证协议（Contributor License Agreement）来明确法律上的权利归属。理想的开源项目运作方式是：

  • Maintainer 维护项目并可以全权对侵犯项目知识产权的第三方维权
  • Contributor 为项目贡献代码，并通过签署 CLA 将所有权 / 使用权授予 Maintainer
  • Maintainer 通过开源许可证向 Contributor 以及公众授予使用权

尤其是像 GPL 这样具有明确限制条件的协议，在有人违反许可证条款的时候，更需要有一个明确的主体作为权利受侵害方来进行诉讼工作。

04

宽松开源许可

MIT、BSD、Apache 等许可证都属于宽松开源许可证的范畴。

这些许可证允许软件的自由使用、修改和分发，同时也允许将软件与闭源软件进行链接。相比于 Copyleft 许可证，宽松开源许可证的要求更加宽松，没有强制要求公开源代码。它们的目标是促进软件的广泛使用和分发，以及鼓励开发者更深度地参与到软件开发中来。与 Copyleft 许可不同，宽松开源许可证更加注重软件的自由使用和分发，而不是强制要求公开源代码。

这种开放和宽松的许可证为软件的自由和开放提供了更加灵活的选择，使其在商业软件中被广泛使用，也为开源社区的发展和壮大提供了更加广泛的支持。

开源许可证有不同版本，不同版本的细节要求会有不同。下面提供了常见的三种许可证修订版的对比：

| | MIT | Apache-2.0 | BSD-3-Clause | | 列举修改 | 无需 | 需要 | 无需 | | 推广背书 | - | - | 禁止 | | 兼容性 | GPL v2+ | GPL v3 | GPL v2+ |

MIT 许可证

MIT 许可证的内容非常简略，仅需一页 A4 纸即可完整打印。

Copyright (C)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

它授予了使用者绝大多数权利，只是要求在源码和产物的副本中保留版权信息和许可证信息。

BSD 许可证

BSD 许可证的 BSD 3-Clause 版本经常被人误以为是 BSD 许可证的第三个版本，但它实际表示的是 BSD 许可证的 “三段落版本”，相比于最初的四条款版本删去了广为社区诟病的、有关于广告材料的条款。BSD 系列许可证之间的关系可以参考：

  • 0BSD ≈ 公共领域
  • BSD 2-clause ≈ MIT License
  • BSD 3-clause = BSD-new = revised BSD = BSD 2-clause + 防止推广背书
  • BSD 4-clause = BSD-old = BSD 3-clause + 广告条款

这里 “防止推广背书” 对应的条款原文（翻译）是：

事前未获取书面许可，不得使用柏克莱加州大学或本软件贡献者之名称，来为本软件之派生物做任何表示支持、认可或推广、促销之行为。

这是 BSD 3-clause 相比于其它开源许可证比较特别的一个条款，主要是为了防止项目的使用者通过碰瓷使用的开源项目以及其开发团队进行宣传。

Apache 许可证

由于这种法律、行业、一般知识产权和一般使用条款的混杂，并不清楚 MIT 许可证是否包括明示或者默示的专利许可存在争议。一般性语言“处置 deal in”和一些例子动词，尤其是“使用”，指向了一个专利许可，尽管是一个非常不明确的许可。许可证来自于版权持有人，而版权持有人可能对软件中的发明拥有或不拥有专利权，以及大多数的例子动词和“软件 the Software”本身的定义，都强烈地指向版权许可证。 诸如 Apache 2.0 之类的较新的宽松开源许可分别具体地处理了版权、专利甚至商标问题。

Apache-2.0 相比于前面提到的两种许可证的用语更加严谨、用更大的篇幅描述了更详尽的细则，并规定了专利许可的范围。

Apache-2.0 的两个特点： 需要保留 NOTICE 文件（如有）、需要携带修改声明 。

前者实际上也是大多数开源许可证都要求的归属声明义务，只是 Apache 选择将其详细描述为具体的做法。

后者则是其特有的，要求对原项目任何文件的修改都必须列举出来。

05

Copyleft 许可

代表：GPL、LGPL

Copyleft 最早来源于自由软件运动的倡导。自由软件运动的目标是通过保障软件用户的自由，促进软件的自由和开放，以及鼓励开发者更深度地参与开源社区。Copyleft 许可证要求使用者为开源事业承担更大的义务，这也是自由软件运动的核心理念之一。

这里主要介绍 Copyleft 软件许可证中最知名和流行的 GPL 和 LGPL 系列许可证，它们以其协议中 “强制代码开放” 的特性著称。这意味着如果发布的软件包含了 GPL 的代码，则通常整个独立进程所在的程序都需要使用 GPL 向软件的接收方交付源码，具体依情况而定；而 LGPL 则要求至少是代码所在的库应当向软件的接受方提供源码。这种强制性的开源要求是为了保护开源软件的自由和开放性，使得所有人都能够获得和修改源代码。

传染的边界

FFmpeg 的本体主要通过 LGPL v2.1 和其它兼容的宽松许可发布，另外包含一些默认不启用的 GPL v2.0 / GPL v3.0 可选模块，因此很适合用来讲解 GPL / LGPL 许可证。

FFmpeg License

Most files in FFmpeg are under the GNU Lesser General Public License version 2.1 or later (LGPL v2.1+).

Some other files have MIT/X11/BSD-style licenses.

Some optional parts of FFmpeg are licensed under the GNU General Public License version 2 or later (GPL v2+).

None of these parts are used by default. In this case, FFmpeg's license changes to GPL v2+.

根据以上说明，FFmpeg 的编译选项可以决定是否产物仅包含 LGPL 的代码，还是同时包含 LGPL 和 GPL 的代码，从而触发不同程度的传染性。

> 动态链接

如果将 LGPL v2.1 版的 FFmpeg 编译为动态链接库（.dll / .so）并提供给应用调用，那么这个应用是不需要在分发时开放源代码的。

LGPL 许可证最初是为了支持 GNU C 库抢占市场而创建的，所以相比于 GPL 提供了更宽松的许可条件：

使用普通 GPL 并非对每个函数库都有好处。在某些情况下，使用 LGPL 更好些。最常见的情况是，专有软件可以通过其他函数库来实现使用自由软件函数库的功能。在这种情况下，该函数库不能给自由软件带来任何特别的好处，所以最好对它使用 LGPL 许可证。

这就是为什么我们对 GNU C 库使用 LGPL 的原因。毕竟，世界上有那么多的 C 函数库； 让我们的 C 库使用 GPL 许可证会迫使专有软件的开发者去使用其他的 C 库—对他们不是问题，对我们则是。

但是如果编译 FFmpeg 时启用了 GPL 参数，即便应用仅仅调用编译的 FFmpeg 动态链接库，该应用程序也需要程序遵循 GPL 许可证要求开源。

此处 FFmpeg 中的 LGPL 是指 LGPL v2.1，相比之下 LGPL v3.0 有一些额外的要求，比如要求消费级别的硬件不能被锁定，因此出于合规性要求，LGPL v3.0 在锁定的消费硬件上使用难以合规。

> 系统平台

操作系统是一个开放的容器，它不能知道和限制其平台上运行的程序需要遵守的法律要求。因此操作系统也不应该受到运行在其上的应用程序的条款限制。

Q：我是否可以用专有系统库连接一个 GPL 程序？( #SystemLibraryException )

两版 GPL 都有关于 copyleft 的例外，通常成为系统库例外。如果你用的 GPL 不兼容库满足了系统库的条件，那么你就不用对这些库做任何处理而直接使用；整个程序的源代码发布要求也不包含这些系统库，即使你发布的是连接了这些库之后的可执行文件也是一样。

> 依赖包

ffmpeg.wasm 项目是 FFmpeg 的 WebAssembly / JavaScript 移植版本。它可以在浏览器内实现视频和音频的录制、转换和流媒体功能。其核心能力通过 @ffmpeg/core 和 @ffmpeg/ffmpeg 两个 npm 包来提供，前者 fork 自 FFmpeg 用于编译产出其 wasm 产物，后者则是对应的 JavaScript API Binding。

@ffmpeg/ffmpeg 作为一个 npm 包只是依赖于 FFmpeg 而没有分发其源码或产物，因此并不触发 GPL 许可证的传染性。


            
// src/browser/defaultOptions.js
            
import pkg from '../../package.json';
            

            
const corePath = typeof process !== 'undefined' && process.env.NODE_ENV === 'development'
            
  ? new URL('/node_modules/@ffmpeg/core/dist/ffmpeg-core.js', import.meta.url).href
            
  : `https://unpkg.com/@ffmpeg/core@${pkg.devDependencies['@ffmpeg/core'].substring(1)}/dist/ffmpeg-core.js`;
            

            
export default { corePath };

‍


            
// src/node/getCreateFFmpegCore.js
            
const { log } = require('../utils/log');
            

            
module.exports = ({ corePath }) => new Promise((resolve) => {
            
  log('info', `fetch ffmpeg.wasm-core script from ${corePath}`);
            
  // eslint-disable-next-line import/no-dynamic-require
            
  resolve({ createFFmpegCore: require(corePath) });
            
});

名义上 @ffmpeg/ffmpeg 并不依赖 @ffmpeg/core 或其它任何 FFmpeg 项目分叉，使用者可以使用任意兼容 FFmpeg API 的库替代之，但在实际使用时几乎只能选择同时安装 @ffmpeg/core 作为依赖。这就意味着处理 GPL 传染性问题的责任就交给了更上层的应用。


          
              

            $ npm install -S @ffmpeg/ffmpeg @ffmpeg/core

> 独立软件

独立的程序即使与包含 GPL 代码的 FFmpeg 一起分发也不会受到 GPL 的传染，甚至这个程序可以在保证进程隔离等条件的情况下通过命令行等方式与 FFmpeg 通信，以使用 FFmpeg 提供的功能。

Q：“聚合版”和其他“修改版”有什么不同？( #MereAggregation )

“聚合版”包含有多个独立的程序，并在同一个 CD-ROM 或其他媒体上发行。GPL 允许你制作并发布一个聚合版，即使其他软件的许可证不是自由许可证或不是 GPL 兼容的许可证也可以。唯一的条件是你的聚合版的许可证不能禁止用户行使每个独立程序的许可证允许的权利。

究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。

如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。

反过来，pipes、sockets 和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。

GPL 许可证的 FAQ 中对独立程序的解释稍显暧昧，其出发点可能是为了避免有人将包含 GPL 代码的 FFmpeg 封装成为一个通过 RPC 通信暴露全部接口的程序、将其提供给专有软件使用，但在法律上很难具体提供一个标准界定这种行为，所以 GNU 希望将裁量的权力交给具体负责实务的法官。

内部使用

用户可以修改基于 GPL 授权的程序并仅供自己使用而不公开，这时候没有发生 “发布” 行为，也不会触发 GPL 的开源义务。

类似于财税领域将公司看作是概念上的 “法人” 个体，开源许可证也常将公司看作法律意义上的个体，即公司内部员工之间分发或者修改将不会被认为是 “发布”，与此相关的所有条款从这份代码传递给公司以外的人开始生效。

常见的内部使用的场景包括：视频网站依赖于 FFmpeg 来处理音视频数据，或者云服务商推出基于 FFmpeg 的 SaaS 方案。

Q：在组织或公司内部使用是不是“发布”？( #InternalDistribution )

不是，在公司内部使用只是公司为自己制作拷贝。因此，公司或组织可以开发自己的修改版并在内部部署，其员工也无权对外发布。

然而，当公司把拷贝发送给其他组织或个人时，就是发布。具体来说，为合同商提供拷贝来离岸使用就是发布。

Q： GPL 是否要求修改版的源代码公开？( #GPLRequireSourcePostedPublic )

GPL 不要求你发布你的修改版或者任何一部分修改版。你有自由修改并自用，而不必发布。这个规则也适用于机构（包括公司）；机构可以做出修改版并在内部使用而不向其他外部组织发布。但是如果你以某种方式把修改版向公众发布，GPL 就要求你向用户提供修改版的源代码。因此，GPL 允许程序按某些方式发布，而不允许用其他的方式发布；但是，是不是发布由你来决定。

Q： 某公司在网站上运行一个 GPL 软件的修改版。按照 GPL，该公司是否必须发布其修改版的源代码？( #UnreleasedMods )

GPL 允许任何人做一个修改版自己用而不发布。你所说的公司的做法就是一个这样的特例。因此，该公司不必发布其修改版。当该修改版使用的许可证是 GNU Affero GPL 时，情况有所不同。

把这个情况和网站包含或链接到独立的 GPL 程序做个比较，这些 GPL 程序在用户访问网站时分发给了用户（经常是 JavaScript 程序，但是也可以使用其他语言）。此时，这些发布给用户的程序的源代码必须按照 GPL 的条款来发布。

Q： 如果我知道有人有一份 GPL 软件的拷贝，我是否可以要求他们给我一份？( #CanIDemandACopy )

不。GPL 允许一个人制作和发行软件的拷贝，只是当这个人选择这样做的时候。这个人也有权利选择不发行该软件。

06

云商业化限制许可

AGPL 许可证

近年云服务商业模式兴起，也导致出现了更适应时代的、针对云服务的 AGPL v3 许可证。

顾名思义 AGPL v3 衍生自 GPL 系列，但通过扩大开源义务的范围来限制了商业公司将项目用于提供收费的 SaaS 服务。

GNU Affero((1)) 通用公共许可证是由普通的 GNU 公共许可证第三版的修改版。它有一个额外要求：如果您在服务器上运行一个由 GNU AGPL 许可的修改版的软件，并且让其他用户与这个软件通信，那么这个服务器也必须允许他们下载这个正在运行的修改版本相对应的源代码。

Q： 某公司在网站上运行一个许可证为 GNU Affero GPL (AGPL) 的程序的修改版。按照 AGPL，该公司是否必须发布其修改版的源代码？( #UnreleasedModsAGPL )

GNU Affero GPL 要求该修改版软件为其用户提供一个通过计算机网络获取源代码的方法。你所说的公司正处在这样一个状态下，所以它必须发布修改版软件的源代码。

Q： 在 AGPLv3 中，什么应该算作是“通过计算机网络和 [该软件] 远程交互？”( #AGPLv3InteractingRemotely )

如果程序的设计明显是通过网络接受用户请求和发送回复，那么该程序就符合远程交互的判定条件。符合此类条件的常见程序包括网络服务器和邮件服务器、交互式网络应用程序以及在线游戏的服务器。

如果程序的设计不是明显地通过网络来和用户交互，但是该程序碰巧运行在一个需要网络交互的环境下，那么它不算是远程交互程序。例如，用户使用 SSH 或远程 X 会话运行了某个应用。

它的诞生就是由于以往的 GPL 等 Copyleft 软件许可并没有针对这种场景做出限制：云服务商可以使用 MySQL 或者其修改版提供开箱即用的数据库服务。因为没有对外发布修改版 MySQL 的二进制程序，当然也不会触发 GPL 许可证的传染性开源义务。

这样长此以往云服务商可能通过持续投入改进 MySQL 获得可观的性能提升，同时又因为无需开源这部分的修改代码而获得相对于社区和竞争对手的商业优势。最终可能导致用户纷纷付费使用闭源的数据库服务而不再使用和贡献最初的 MySQL 项目，而这是与 FSF 的自由软件运动的初衷相违背的。

SSPL 许可证

该许可证规定，如果将程序或修改版本的功能作为服务提供给第三方使用，那就必须以网络下载的方式向所有人免费提供服务源代码。

其中，“服务源代码”指程序或修改版本的相应源代码，以及你用于将程序或修改版本作为服务提供的所有程序的相应源代码，包括但不限于管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件，以便用户可以使用你提供的服务源代码运行服务实例。

SSPL 协议与 GPL 和 AGPL 协议不同，它规定如果使用 SSPL 软件为 SaaS 服务开发软件，那就需要将这个 SaaS 服务 所有配套软件 的源码全部公开。这就几乎杜绝了商业公司使用基于 SSPL 授权的开源项目并对外提供服务的可能性。

07

多种许可

知名数据库软件 MySQL 存在两种授权方式：

  • 通过 GPL 许可证进行开源，社区用户可以免费使用
  • 通过商业许可授权企业客户，客户可以随意使用和修改 MySQL 并且无需开源

Oracle 这样的做法是希望更广泛地推广 MySQL 并一定程度地参与开源社区，在收获广大用户群体之后针对其中有特殊需求的企业客户制定商业化收费方案。因为 Oracle 完全拥有 MySQL 代码的版权，所以这样的双许可做法也是合理合规的。

Q： 我听说有人获得了一份按照其他许可证发布的 GPL 程序。这可能吗？( #HeardOtherLicense )

GNU GPL 没有赋予用户为程序附加其他许可证的权利。但是，程序的版权持有者可以同时按照多个许可证发布自己的程序。其中一个可以是 GNU GPL。

假设程序的版权持有者添加了许可证并且你从合法途径获得该程序的拷贝，那么你得到的程序拷贝带有的许可证就是你的拷贝适用的许可证。

Q：我愿意把我写的程序按照 GNU GPL 发布，但是我也想在非自由软件里使用同样的代码。( #ReleaseUnderGPLAndNF )

虽然把程序发布为非自由软件总是一个道德污点，但是法律并没有阻碍你这么做。如果你是自己代码的版权持有者，那么你可以在不同时间按照不同的非排他许可证发布。

08

代码所有权

如前文所说：项目所有者持有其专利和版权，向用户授予的是不可撤销的使用权，且要求用户承担许可证的限制性条款。

这些限制性条款是项目所有者为用户施加的限制，所有者自己并不需要遵守许可证的要求。也因此所有者不需要承担开源义务——当然也可以随时修改项目的许可证甚至将项目转为闭源。此前发布的版本依然按照原有许可证授予用户不可撤销的许可。

然而在理想情况之外，如果社区贡献者在提交代码时未签署额外协议，知识产权法律通常会默认代码的所有权属于贡献者本人，这可能导致权利归属的争议。在这种情况下，贡献者有可能主张自己对代码的所有权，并可能对项目所有者提起诉讼。如果项目所有者本身不持有相关专利和版权，那么他们的授权或更改授权的行为可能会被质疑。

不过通常情况下，贡献者为项目贡献代码时，被认为已经同意了基于相关协议分发其编写的代码。如果不是这样，开源社区的运作将会受到严重影响。

picture.image

而 Oracle 正是通过这样的协议收集社区贡献的代码的权利，并将其用在自己的商业化服务中：

Why does Oracle have a Contributor Agreement?

The OCA protects the integrity of the code base, which in turn protects the development community and the users of the project.

For Oracle-sponsored projects (i.e. projects that require an OCA), Oracle acts on behalf of the community in the event of any legal challenge. This is in keeping with how other code stewards, including the Free Software Foundation, the Apache Software Foundation, and the Eclipse Foundation operate. In order to represent a code base against legal challenges, Oracle needs to have copyright ownership of all the code in that project.

Consolidating ownership of the code also allows for the possibility of relicensing the whole code base should that become desirable. Having the ability to license code under a different license can be a useful tool, and not having that flexibility may be a drawback. Without aggregated copyright, Oracle would have to contact and obtain permission from every single contributor in order to license the code under a different license. Consolidating ownership in this way is a common practice in various open source communities.

The joint copyright assignment also allows Oracle to act as a bridge between different communities using the same code under different licenses. This allows the sharing of code between open-source projects which might otherwise not be possible and it allows Oracle to license source code to parties who are not yet prepared to work with an open-source license.

Most importantly, having joint ownership of copyright allows Oracle to offer commercial, binary distributions of the project. Without this ability, it would not be possible for Oracle to open its technologies, nor feasible to continue to invest in them as a business and employ developers working on the code.

Oracle 也向社区保证这些贡献的代码都会被开源（但并没有说不能用于闭源的专有软件）：

By accepting an OCA, Oracle promises that it will make your contributions available under a free or open-source software license for as long as Oracle continues to distribute them.

09

改变许可证

项目拥有者虽然不能撤销、改变此前对用户的授权，但可以：

  • 终止此后版本的开源许可
  • 将此后的版本转为其它开源许可

开源项目可以根据项目的需求和发展情况进行许可证的变更，但这种变更可能会引起争议和不信任，因为开发者和用户可能会担心他们的权利和利益会受到损害。开源项目的负责人即使通过 CLA 从贡献者手中收集权利，也需要仔细权衡各种因素，包括商誉、口碑和法律风险等。

MongoDB 是一个开源的文档型数据库，最初采用 AGPL 许可证。然而，为了更好地维护其商业利益，MongoDB 公司在 2018 年将 MongoDB 的许可证从 AGPL 迁移到了 SSPL。AGPL 许可证要求任何使用该软件的公司都必须公开其修改后的源代码，而 SSPL 许可证更进一步，要求任何使用该软件作为服务的公司都必须公开其全部服务端代码。开源组织 OSI 表示 SSPL 许可证要求使用该软件的公司公开其服务端代码，这可能会削弱开源社区的合作和创新。

React 作为最流行的 JavaScript 库之一闻名前端领域。然而 2017 年 Facebook 将 React 的许可证从 MIT 更改为 BSD + Patents 许可证。这个许可证引起了争议，因为它包含了一个专利条款，这意味着如果有人控告 Facebook 侵犯了相关专利，那么使用 React 的其他人也将受到影响。这导致一些公司和社区开始寻找替代品，以避免潜在的法律风险。Facebook 后来回应了这些担忧，将 React 的许可证改回了 MIT 许可证。

picture.image

10

使用许可证

前端网页应用

前端应用大多依赖于构建工具提供的能力，将依赖包的许可证提取出来并随产物发布到 CDN。例如 terser-webpack-plugin 允许用户通过 extractComments 选项配置提取注释语句的行为，主要用于搜索各个 chunk 中有关版权信息的注释并将其抽出到单独的 *.LICENSE.txt 文件中。由于普通用户通常不会访问加载这些版权文件，虽然不能降低整体的产物体积，但可以在保证合规的前提下降低 CDN 成本并减少客户端的负载。

picture.image /static/js/lib-react.dc2ff192.js

picture.image /static/js/lib-react.dc2ff192.js.LICENSE.txt

这是 webpack 的默认行为和最佳实践，有助于保证合规并提升性能，但它并不是一个在法律上明确有效的声明行为，也并不是受到行业内的广泛认可的标准做法。Wappalyzer 对使用 webpack 构建的热门网站的进行了统计，访问这些网站可以发现它们大多都不允许用户获取到 *.LICENSE.txt 的许可证声明文件。

picture.image

Hybrid 动态下发

通过结合 React Native、Webview、小程序等动态化的前端技术搭建的 Hybrid 移动应用，相比运行在浏览器里的前端网页来说开发者要推进开源合规相关的工作可能更加困难。因为相比于网页来说，用户无法通过正常途径访问手机应用中产物的源码和许可证文件。传统的原生 Android / iOS 应用通常会选择将所有开源许可信息列举在独立的 “开源软件声明” 页面中，但 Hybrid 应用中使用前端技术搭建的部分通常迭代速度较快所以很多时候难以顾及去展示软件许可。

更重要的是对于 Hybrid 应用来说如果需要正确处理应用中前端项目引入的开源依赖，可能需要改造整套工作流程并引入额外的复杂度。

选择许可证

对于开源项目的使用者来说： 在使用开源社区的成果的同时关注许可证的限制条款、尽到合理的开源义务，有助于避免潜在的法律风险并维护商誉。

MIT、BSD-3、Apache-2.0 等系列的 宽松许可证 一般都可以 放心使用 ，但需要注意遵守许可证条款的内容，尤其是注意常常需要 携带许可证副本 。

而 Copyleft 许可证 对商业公司不太友好，需要认真评估使用场景并 谨慎使用 。这类许可证包括 GPL、LGPL、AGPL、SSPL 等系列，其中尤其是 AGPL 和 SSPL 几乎只能用于完全对内的服务。

另外需要注意的是类似 WTFPL 这样表达口语化的许可证，即使其已经得到 OSI 的认可并被收录，但也可能会因为法律信息声明不充分而导致 潜在风险 ，因此使用时也需要充分评估并咨询法务同学。

picture.image

对于开源项目的维护者来说： 应该了解如何选择合适的许可证来促进开源社区参与并保护自己的权益。一般来说，选择的许可证应尽可能是有一定的权威性、易于理解的开源许可证，例如：

  1. GPL-2.0 或 GPL-3.0
  2. Apache 2.0
  3. MPL-2.0
  4. EPL-2.0
  5. MIT
  6. BSD-2-Clause 或 BSD-3-Clause

也有譬如 Mulan Permissive Software License (Mulan PSL-2.0) 这样的新兴许可证正在被越来越多的采用，可以在需要具有明确专利条款的宽松许可证的情况下使用。

11

Mega List

表格修改和翻译自 https://choosealicense.com/

picture.image

标识说明

开源许可证授予公众对许可作品进行某些行为的 🟢 权限 ，以避免现行的知识产权法律否认公众对于开源作品的权利。

大多数开源许可证授予的权限都需要遵守一定的 🔵 条件 。大多数开源许可证也存在 🔴 限制 ，通常否认保修和责任，有时明确排除专利或商标的许可授权。

  • 商业用途
  • 🟢 许可的物料及其派生可以用于商业用途。
  • 发布
  • 🟢 许可的物料可以被发布。
  • 修改
  • 🟢 许可的物料可以被修改。
  • 专利使用权
  • 🟢 许可证自贡献者们明确授予了专利的使用权。
  • 🔴 许可证明确声明不授予专利的任何权利。
  • 内部使用
  • 🟢 许可的物料可以私有使用和修改。
  • 闭源
  • 🔵 发布许可的物料时必须使源代码可得。
  • 许可和版权声明
  • 🔵 许可的物料必须包含许可证副本和版权声明。
  • 许可和版权声明（仅源码）
  • 🔵 许可的源代码物料必须包含许可证副本和版权声明。
  • 网络服务分发义务
  • 🔵 用户通过网络与许可的物料交互时有权获得源代码。
  • 相同许可
  • 🔵 发布许可的物料时，对其的修改也必须以相同许可证分发。有些情况下也可以使用类似或相关的许可证。
  • 相同许可 (文件)
  • 🔵 发布许可的物料时，对既存文件的修改也必须以相同许可证分发。有些情况下也可以使用类似或相关的许可证。
  • 相同许可 (库)
  • 🔵 发布许可的物料时，对其的修改也必须以相同许可证分发。有些情况下也可以使用类似或相关的许可证。此条件可能不适用于使用许可材料作为库的作品。
  • 罗列变更
  • 🔵 对许可的物料的修改必须在文档中列出。
  • 限制性责任
  • 🔴 许可证包含限制性责任。
  • 商标使用权
  • 🔴 许可证明确声明不授予商标使用权。没有相关声明的许可证亦不代表隐性授予商标使用权。
  • 保修责任

  • 🔴 许可证明确声明不提供任何保修。

｜ References

这篇文章参考或引用了来自以下链接的公开内容。

| 关于团队

我们是字节跳动 Web Infra - Web Solutions 团队，服务于整个公司的 Web 生态，我们的愿景是 打造世界一流的 Web 生态技术体系，为字节产品提供极致的用户体验和开发体验。团队打造了一系列 Web 工具来提升开发效率和体验，包括但不限于：

  • 基于 Rust 的 Web 构建工具 —— Rspack，旨在建设高性能前端工具链，让跨端和 Web 场景拥有 “快人一步” 的开发体验，具备极速的编译和热更新性能。

  • 基于 Rspack 的开源方案，包括 Rsbuild、Rspress 和 Modern.js，构成一系列开箱即用的解决方案，提供从 Web 构建、静态站点生成到全栈研发的多场景支持。

  • 高性能 Web 解决方案，基于 Web 不止于 Web。突破传统的 WebView，与端、浏览器内核相结合，持续探索各种端性能优化方式，让开发者以极低成本享受优化能力。

  • 现代 Web 工程体系，包括基于 React 的渐进式 Web 开发框架、基于 esbuild 的模块开发工具、monorepo 解决方案、微前端 / 微模块解决方案、构建诊断分析工具。

当前，这些工具在 ByteDance 内部被广泛使用和好评。同时，其中多个项目已经开源到 GitHub，与社区开发者共同建设和发展。

Web Infra 团队正在寻求经验丰富的前端工程师，来共同打造高性能前端工具和 AI-first 视角之下的新产品，从而给开发者、用户带来更好的开发体验、用户体验，作为 Web Infra 团队成员，你将：

  • 设计和研发 Web 工具，包括但不限于：Web 研发框架、Rust bundler 等。

  • 建设通用和开源的现代 Web 工程体系、工程方案和最佳实践。

  • 帮助 Web 开发者提升效率和质量，探索 / 引进 / 保障最佳实践和新技术新方案。

  • 跟进前端社区的变动，实践最新的前端技术并跟进到架构设计之中。

  • 共同探索 AI-first 视角之下的下一代产品。

欢迎前往网站 https://webinfra.org/about 查看详情。

特别说明：文中链接较多，可点击底部 「阅读原文」 前往网页 blog 查看完整内容。

165
0
0
0
关于作者
字节跳动开源
字节跳动开源
相关产品
评论
未登录
看完啦，登录分享一下感受吧～
暂无评论