Bitwarden Server 许可证体系全解：AGPL 3.0、Bitwarden License 与 OSS 构建开关

Bitwarden Server 许可证体系全解：AGPL 3.0、Bitwarden License 与 OSS 构建开关

【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server

Bitwarden 的 server 仓库采用"开源 + 源码可用（Source Available）"的双轨许可策略：仓库主体默认以 AGPL 3.0 发布，而面向大型组织的商业模块则以 Bitwarden License 发布。本文以仓库根目录的 LICENSE_FAQ.md 为骨架，结合 LICENSE.txt、LICENSE_AGPL.txt、LICENSE_BITWARDEN.txt、TRADEMARK_GUIDELINES.md 与构建源码，系统讲解各模块许可证的判定规则、OSS构建开关的底层实现、托管服务场景下的 copyleft 边界，以及商标使用规范，帮助开发者、自托管运维者和二次开发者准确理解本仓库的许可边界。

一、Bitwarden 的开源理念与双轨许可模式

Bitwarden 将全部软件产品的源码公开在 GitHub 上，欢迎任何人审查（review）、审计（audit）与贡献（contribute）代码。其核心理念是：源码透明（source code transparency）是密码管理类安全产品给客户带来的关键价值——用户可以通过审阅源码来验证产品是否真的如宣传那样保护数据。

在此基础上，Bitwarden 并未采用单一许可证，而是为不同模块配置了不同许可证，形成两个层级：

• 开源层级（Open Source Tier）：核心产品基于 GPL 家族开源许可证发布，包括 GPL 3.0 与 AGPL 3.0；
• 源码可用层级（Source Available Tier）：少量面向大型组织而非个人/家庭的功能模块，采用 Bitwarden License（商业许可证）发布。

需要特别澄清的是：Bitwarden License 并不属于 OSI 定义的"开源许可证"，而是"源码可用"许可证。这一点在文档的 FAQ 中被明确承认，也是理解本仓库许可结构的起点。

二、当前产品的许可证归属

根据 LICENSE_FAQ.md 的说明，Bitwarden 当前软件产品线的许可证归属如下：

这一划分在实际仓库中同样有据可查：LICENSE.txt 开篇即声明：

Source code in this repository is covered by one of two licenses: (i) the GNU Affero General Public License (AGPL) v3.0 (ii) the Bitwarden License v1.0. The default license throughout the repository is AGPL v3.0 unless the header specifies another license. Bitwarden Licensed code is found only in the /bitwarden_license directory.

即：仓库默认许可证是 AGPL 3.0，Bitwarden License 代码只存在于/bitwarden_license目录。AGPL 3.0 全文见 LICENSE_AGPL.txt（GNU Affero General Public License, Version 3, 19 November 2007），Bitwarden License 协议全文见 LICENSE_BITWARDEN.txt（Bitwarden License Agreement Version 1, 4 September 2020）。

三、目录级许可划分：如何判定某个源码文件的许可证

在 LICENSE_FAQ.md 的 FAQ 中，官方给出了仓库内许可证判定的明确规则：

1. 每个 Bitwarden 仓库根目录都有一个LICENSE.txt文件，说明该仓库适用的许可证；
2. 目录不仅是逻辑组织单元，也是许可划分单元：
   • 仓库根目录下bitwarden_license/目录内的所有源文件受 Bitwarden License 约束；
   • bitwarden_license/之外的任何文件，默认适用 AGPL 3.0。

在当前仓库中，bitwarden_license/src 目录下包含五个商业模块：

• Commercial.Core/——商业核心逻辑（bitwarden_license/src/Commercial.Core）；
• Commercial.Infrastructure.EntityFramework/——商业模块的 EF 基础设施实现（bitwarden_license/src/Commercial.Infrastructure.EntityFramework）；
• Scim/——SCIM 身份供应集成（bitwarden_license/src/Scim）；
• Services/——商业服务层（bitwarden_license/src/Services）；
• Sso/——企业 SSO 集成服务（bitwarden_license/src/Sso）。

同时，bitwarden_license/test 下还包含这些商业模块对应的测试工程（如Commercial.Core.Test、SSO.Test、Scim.Test等）。当你在本仓库中阅读或复制任何文件时，首先判断其路径是否位于bitwarden_license/之下，即可快速确定其许可归属。

四、OSS 构建开关：从编译层面剥离商业模块

LICENSE_FAQ.md 中给出了一个非常实用的操作细节：Api 模块默认包含处于 Bitwarden License 之下的 Commercial.Core，但可以通过给dotnet传递/p:DefineConstants="OSS"参数来禁用该引用，构建出纯开源版本。

这一声明在源码中得到完整印证。查看 src/Api/Api.csproj 的工程文件：

<Choose> <When Condition="!$(DefineConstants.Contains('OSS'))"> <ItemGroup> <ProjectReference Include="..\..\bitwarden_license\src\Commercial.Core\Commercial.Core.csproj" /> <ProjectReference Include="..\..\bitwarden_license\src\Commercial.Infrastructure.EntityFramework\Commercial.Infrastructure.EntityFramework.csproj" /> <ProjectReference Include="..\..\bitwarden_license\src\Services\Pam\Pam.csproj" /> </ItemGroup> </When> </Choose>

其逻辑非常直白：

• 默认情况（未定义OSS常量）：Choose/When条件!$(DefineConstants.Contains('OSS'))成立，Api 工程会通过ProjectReference引用三个位于bitwarden_license/下的商业模块——Commercial.Core、Commercial.Infrastructure.EntityFramework以及商业服务层的Pam；
• 定义OSS常量后：条件不成立，上述三个商业模块引用被整体移除，Api 模块退化为纯 AGPL 组件构成的版本。

因此，构建纯开源 Api 模块的命令为：

dotnet build src/Api/Api.csproj /p:DefineConstants="OSS"

对于需要在无商业许可前提下构建、审计或二次开发服务器核心能力的团队，这一开关是规避 Bitwarden License 代码进入构建产物的关键手段。需要说明的是，该开关只会影响 Api 模块的工程引用关系，bitwarden_license/目录下的商业模块源码本身依然存在，其许可归属不变。

五、常见问题深度解读

5.1 如何贡献 Bitwarden 开源项目？

Bitwarden 欢迎开发者社区的新成员，提供多种贡献途径，官方推荐通过其社区资源中的 GitHub 贡献论坛参与。就本仓库而言，遵循开源协作的一般流程即可：fork、修改、提交 PR，并遵守仓库的 CONTRIBUTING.md 与 SECURITY.md 约定。

5.2 如何确定一个程序适用的许可证？

如前文所述：查看仓库根目录的LICENSE.txt；在 server 仓库中，再以bitwarden_license/目录为分界线做二次判定。这条规则是官方明确给出的判定流程，可直接用于本仓库内任意源码文件的许可归属判断。

5.3 能否基于 Bitwarden 产品提供托管服务（as-a-service）？

这是企业用户最关心的问题，官方给出了明确的合规指引，核心结论是：提供 Bitwarden "as-a-service" 必须高度警惕 AGPL 与 Bitwarden License 的强 copyleft 属性：

• 对Bitwarden License下的服务器软件：生产环境使用需要与 Bitwarden 签订独立的商业协议（LICENSE_BITWARDEN.txt 第 2.1 条明确：许可仅限非生产环境的内部开发与内部测试）；
• 对AGPL 3.0下的服务器软件：官方观点是，在实际操作中几乎无法想象一种不修改 Bitwarden 代码就能对外提供 "as-a-service" 的场景，而任何修改都会触发 AGPL 3.0 的强 copyleft 条款——即修改后的衍生代码也必须以 AGPL 3.0 向网络用户开放源码。

因此，有意提供托管服务的组织应加入 Bitwarden Partner Program，以获取授权合作伙伴可用的资源与支持。

5.4 Source Available 许可证授予了哪些权利？

Bitwarden License 授予用户以下权利：

• 将软件源码用于非生产目的的内部开发与内部测试；
• 在生产环境或直接支撑生产的环境中使用，需要付费的 Bitwarden 订阅。

官方明确说明，这一模式参考了其他成功的开源商业公司的许可策略，例如 Elastic（NYSE: ESTC）与 Confluent（NASDAQ: CFLT）采用的源码可用模式。这是"开放与商业目标之间取得平衡"的典型设计。

5.5 Bitwarden 到底是不是开源软件？

答案需要分层表述：

• 是开源的：个人使用的密码管理客户端、主服务器以及大量库采用 GPL 家族许可证。GPL 由自由软件基金会（Free Software Foundation）创建，并被开源促进会（Open Source Initiative，OSI）认可为"开源"许可证；
• 不是 OSI 定义的开源：Bitwarden License 不符合 OSI 的开源定义，属于"源码可用"许可证。

5.6 分发/服务时能否使用 "Bitwarden" 名称（商标规则）

许可证只授予版权相关权利，不授予任何商标、服务标记或 Logo 权利（除非为满足声明要求所必需）。Bitwarden 商标是 Bitwarden, Inc. 拥有的可信标记，使用须遵守 TRADEMARK_GUIDELINES.md 中的严格规则。该指南的核心要点包括：

• 无需许可即可使用的情形：真实地指称 Bitwarden 产品、服务或功能；在不误导的前提下说明你的产品或服务基于其开源代码——这两种情况无需事先许可；
• 需要许可的情形：任何其他使用方式；
• 允许使用时的规范：
  • 必须完全按照 TRADEMARK_GUIDELINES.md 所示方式使用，不得缩写、加连字符或删减元素；
  • 始终将商标用作形容词并后接通用名词，绝不能当作名词或动词使用；
  • 只能用于指称 Bitwarden 的某个产品或服务，不得以暗示 Bitwarden 赞助或关联的方式使用；
  • 不得将商标的任何部分用作你的企业、产品或服务名称、应用名、域名、出版物或其他标志，以免造成混淆。

即使在自托管场景下，也要遵守上述规则。

六、对开发者与自托管用户的实际意义

综合以上内容，可以从三个角色视角总结本仓库许可结构的实操要点：

1. 自托管用户（Self-host）：自行部署时，默认服务器主体（AGPL 3.0）与商业模块（Bitwarden License）会同时构建。若你未购买商业订阅，应通过/p:DefineConstants="OSS"构建纯开源版本，或确保自身使用符合许可证边界；商标使用方面，参照 TRADEMARK_GUIDELINES.md 如实标注即可，通常无需额外授权。
2. 二次开发者：复制或修改代码前，先按"目录判定法"确认文件归属——bitwarden_license/内的代码不得在未获商业授权的情况下用于生产；AGPL 代码的修改与分发需履行 copyleft 义务。
3. 服务提供商：任何 "as-a-service" 形态都需要特别评估 AGPL 的 copyleft 触发条件与 Bitwarden License 的生产授权要求，建议直接联系 Bitwarden 洽谈商业合作。

关于本仓库更细粒度的工程结构，可继续阅读 README.md 与 bitwarden_license/README.md；贡献流程见 CONTRIBUTING.md；安全相关的披露流程见 SECURITY.md。

【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/server