Bitwarden Server 许可证体系全解AGPL 3.0、Bitwarden License 与 OSS 构建开关【免费下载链接】serverBitwarden infrastructure/backend (API, database, Docker, etc).项目地址: https://gitcode.com/GitHub_Trending/ser/serverBitwarden 的 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 当前软件产品线的许可证归属如下产品/模块许可证适用范围Bitwarden 客户端Desktop、Web、Browser、Mobile、CLIGPL 3.0个人密码库核心代码Bitwarden 主服务器serverAGPL 3.0仓库主体代码Commercial.Core、SSO 集成等新模块Bitwarden License源码可用面向大型组织与企业的功能生产环境需付费订阅这一划分在实际仓库中同样有据可查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.0Bitwarden License 代码只存在于/bitwarden_license目录。AGPL 3.0 全文见 LICENSE_AGPL.txtGNU Affero General Public License, Version 3, 19 November 2007Bitwarden License 协议全文见 LICENSE_BITWARDEN.txtBitwarden License Agreement Version 1, 4 September 2020。三、目录级许可划分如何判定某个源码文件的许可证在 LICENSE_FAQ.md 的 FAQ 中官方给出了仓库内许可证判定的明确规则每个 Bitwarden 仓库根目录都有一个LICENSE.txt文件说明该仓库适用的许可证目录不仅是逻辑组织单元也是许可划分单元仓库根目录下bitwarden_license/目录内的所有源文件受 Bitwarden License 约束bitwarden_license/之外的任何文件默认适用 AGPL 3.0。在当前仓库中bitwarden_license/src 目录下包含五个商业模块Commercial.Core/——商业核心逻辑bitwarden_license/src/Commercial.CoreCommercial.Infrastructure.EntityFramework/——商业模块的 EF 基础设施实现bitwarden_license/src/Commercial.Infrastructure.EntityFrameworkScim/——SCIM 身份供应集成bitwarden_license/src/ScimServices/——商业服务层bitwarden_license/src/ServicesSso/——企业 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:DefineConstantsOSS参数来禁用该引用构建出纯开源版本。这一声明在源码中得到完整印证。查看 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:DefineConstantsOSS对于需要在无商业许可前提下构建、审计或二次开发服务器核心能力的团队这一开关是规避 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 订阅。官方明确说明这一模式参考了其他成功的开源商业公司的许可策略例如 ElasticNYSE: ESTC与 ConfluentNASDAQ: CFLT采用的源码可用模式。这是开放与商业目标之间取得平衡的典型设计。5.5 Bitwarden 到底是不是开源软件答案需要分层表述是开源的个人使用的密码管理客户端、主服务器以及大量库采用 GPL 家族许可证。GPL 由自由软件基金会Free Software Foundation创建并被开源促进会Open Source InitiativeOSI认可为开源许可证不是 OSI 定义的开源Bitwarden License 不符合 OSI 的开源定义属于源码可用许可证。5.6 分发/服务时能否使用 Bitwarden 名称商标规则许可证只授予版权相关权利不授予任何商标、服务标记或 Logo 权利除非为满足声明要求所必需。Bitwarden 商标是 Bitwarden, Inc. 拥有的可信标记使用须遵守 TRADEMARK_GUIDELINES.md 中的严格规则。该指南的核心要点包括无需许可即可使用的情形真实地指称 Bitwarden 产品、服务或功能在不误导的前提下说明你的产品或服务基于其开源代码——这两种情况无需事先许可需要许可的情形任何其他使用方式允许使用时的规范必须完全按照 TRADEMARK_GUIDELINES.md 所示方式使用不得缩写、加连字符或删减元素始终将商标用作形容词并后接通用名词绝不能当作名词或动词使用只能用于指称 Bitwarden 的某个产品或服务不得以暗示 Bitwarden 赞助或关联的方式使用不得将商标的任何部分用作你的企业、产品或服务名称、应用名、域名、出版物或其他标志以免造成混淆。即使在自托管场景下也要遵守上述规则。六、对开发者与自托管用户的实际意义综合以上内容可以从三个角色视角总结本仓库许可结构的实操要点自托管用户Self-host自行部署时默认服务器主体AGPL 3.0与商业模块Bitwarden License会同时构建。若你未购买商业订阅应通过/p:DefineConstantsOSS构建纯开源版本或确保自身使用符合许可证边界商标使用方面参照 TRADEMARK_GUIDELINES.md 如实标注即可通常无需额外授权。二次开发者复制或修改代码前先按目录判定法确认文件归属——bitwarden_license/内的代码不得在未获商业授权的情况下用于生产AGPL 代码的修改与分发需履行 copyleft 义务。服务提供商任何 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 4:25:56 · 阅读 1.2k 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/serverBitwarden 的 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 当前软件产品线的许可证归属如下产品/模块许可证适用范围Bitwarden 客户端Desktop、Web、Browser、Mobile、CLIGPL 3.0个人密码库核心代码Bitwarden 主服务器serverAGPL 3.0仓库主体代码Commercial.Core、SSO 集成等新模块Bitwarden License源码可用面向大型组织与企业的功能生产环境需付费订阅这一划分在实际仓库中同样有据可查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.0Bitwarden License 代码只存在于/bitwarden_license目录。AGPL 3.0 全文见 LICENSE_AGPL.txtGNU Affero General Public License, Version 3, 19 November 2007Bitwarden License 协议全文见 LICENSE_BITWARDEN.txtBitwarden License Agreement Version 1, 4 September 2020。三、目录级许可划分如何判定某个源码文件的许可证在 LICENSE_FAQ.md 的 FAQ 中官方给出了仓库内许可证判定的明确规则每个 Bitwarden 仓库根目录都有一个LICENSE.txt文件说明该仓库适用的许可证目录不仅是逻辑组织单元也是许可划分单元仓库根目录下bitwarden_license/目录内的所有源文件受 Bitwarden License 约束bitwarden_license/之外的任何文件默认适用 AGPL 3.0。在当前仓库中bitwarden_license/src 目录下包含五个商业模块Commercial.Core/——商业核心逻辑bitwarden_license/src/Commercial.CoreCommercial.Infrastructure.EntityFramework/——商业模块的 EF 基础设施实现bitwarden_license/src/Commercial.Infrastructure.EntityFrameworkScim/——SCIM 身份供应集成bitwarden_license/src/ScimServices/——商业服务层bitwarden_license/src/ServicesSso/——企业 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:DefineConstantsOSS参数来禁用该引用构建出纯开源版本。这一声明在源码中得到完整印证。查看 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:DefineConstantsOSS对于需要在无商业许可前提下构建、审计或二次开发服务器核心能力的团队这一开关是规避 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 订阅。官方明确说明这一模式参考了其他成功的开源商业公司的许可策略例如 ElasticNYSE: ESTC与 ConfluentNASDAQ: CFLT采用的源码可用模式。这是开放与商业目标之间取得平衡的典型设计。5.5 Bitwarden 到底是不是开源软件答案需要分层表述是开源的个人使用的密码管理客户端、主服务器以及大量库采用 GPL 家族许可证。GPL 由自由软件基金会Free Software Foundation创建并被开源促进会Open Source InitiativeOSI认可为开源许可证不是 OSI 定义的开源Bitwarden License 不符合 OSI 的开源定义属于源码可用许可证。5.6 分发/服务时能否使用 Bitwarden 名称商标规则许可证只授予版权相关权利不授予任何商标、服务标记或 Logo 权利除非为满足声明要求所必需。Bitwarden 商标是 Bitwarden, Inc. 拥有的可信标记使用须遵守 TRADEMARK_GUIDELINES.md 中的严格规则。该指南的核心要点包括无需许可即可使用的情形真实地指称 Bitwarden 产品、服务或功能在不误导的前提下说明你的产品或服务基于其开源代码——这两种情况无需事先许可需要许可的情形任何其他使用方式允许使用时的规范必须完全按照 TRADEMARK_GUIDELINES.md 所示方式使用不得缩写、加连字符或删减元素始终将商标用作形容词并后接通用名词绝不能当作名词或动词使用只能用于指称 Bitwarden 的某个产品或服务不得以暗示 Bitwarden 赞助或关联的方式使用不得将商标的任何部分用作你的企业、产品或服务名称、应用名、域名、出版物或其他标志以免造成混淆。即使在自托管场景下也要遵守上述规则。六、对开发者与自托管用户的实际意义综合以上内容可以从三个角色视角总结本仓库许可结构的实操要点自托管用户Self-host自行部署时默认服务器主体AGPL 3.0与商业模块Bitwarden License会同时构建。若你未购买商业订阅应通过/p:DefineConstantsOSS构建纯开源版本或确保自身使用符合许可证边界商标使用方面参照 TRADEMARK_GUIDELINES.md 如实标注即可通常无需额外授权。二次开发者复制或修改代码前先按目录判定法确认文件归属——bitwarden_license/内的代码不得在未获商业授权的情况下用于生产AGPL 代码的修改与分发需履行 copyleft 义务。服务提供商任何 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考