本文目录导读：
这是一个非常专业且复杂的问题,选择并组合多许可证模式，通常发生在开源项目、软件库、或企业级产品中，目的是为了实现“既要开源（获取贡献/社区影响力），又要保护商业利益（防止被竞品直接商用）”。
以下是一套系统的选择与组合框架,分为核心逻辑、常见组合模式、决策步骤三部分。
多许可证模式的核心逻辑
选择多许可证不是为了“保险”，而是为了针对不同用户群体提供不同的法律条款，你需要先明确你的项目目标：
- 贡献者（社区版）：希望他们贡献代码，要求他们遵循宽松或严格的互惠协议。
- 普通用户/开发者：允许免费使用，但受限于某些条件（如非商业、规模限制）。
- 商业客户：收取费用，获得商业使用、闭源、技术支持、或免除传染性条款的权利。
核心原则：
- 非互锁：你的许可证组合不能包含互相矛盾的条款（一个允许闭源，一个要求开源，则无法共存）。
- 层级清晰：通常采用“旗舰许可 + 备选许可”的结构。
- 版权归属：确保你有项目代码的完整版权（或征得所有版权人同意），才能自由切换许可。
5 种常见的多许可证组合模式
以下是业界最经典的几种组合,按场景分类：
模式 1：GPL v2/v3 + 商业许可证（俗称“双许可证”）
- 代表项目：MySQL、Qt（早期）、Selenium Grid
- 逻辑：
- GPL：要求任何使用此库或代码的开源项目，也必须整体以GPL发布（强传染性）。
- 商业许可：允许将项目嵌入到自己的闭源商业软件中，且无需开源。
- 适用场景：你的项目是一个核心库（如数据库、图形库、测试框架），你希望开源社区贡献，但要求最终产品开源；商业客户付费则免除开源义务。
- 优点：商业变现清晰，社区认可度高。
- 缺点：GPL的传染性导致很多商业公司天然排斥，可能降低社区采用率。
模式 2：AGPL + 商业许可证（“开源+云厂商”防坑模式）
- 代表项目：MongoDB、Redis（早期抗云原生版）、Elasticsearch（7.11前）
- 逻辑：
- AGPL：比GPL更严格，网络提供服务（SaaS/云服务）也算发布，必须开源全部源码。
- 商业许可：允许云厂商（如AWS、阿里云）直接打包提供服务而无需开源。
- 适用场景：你的项目是数据库、中间件、搜索引擎，你不想让云厂商白嫖你的项目打包成自己的付费云服务。
- 优点：有效防止云厂商薅羊毛。
- 缺点：AGPL 因为“网络穿透”条款，被很多企业内部法律部门列入黑名单。
模式 3：MIT / Apache 2.0 + 商业许可（“极宽松基础版 + 增值版”）
- 代表项目：React Native（早期）、GitLab CE + EE
- 逻辑：
- MIT/Apache 2.0：允许任何人随意复制、修改、闭源、商用，社区版本功能完整但可能有限制。
- 商业许可：提供额外的高级功能（如企业级审计、SSO、高可用）、专属支持、合规保护。
- 适用场景：SaaS 产品、开发工具，你希望最大化采用率，通过免费版本吸引用户，然后对“企业特性”收费。
- 优点：病毒式传播，几乎无法律咨询成本。
- 缺点：商业转化门槛高；竞品可以直接 fork 你的代码并做闭源商业竞争。
模式 4：LGPL + 商业许可
- 代表项目：FFmpeg、eCos
- 逻辑：
- LGPL：允许专有软件以动态链接的方式使用该库，而无需开源整个程序，但修改库本身必须开源。
- 商业许可：允许供应商将静态库嵌入闭源产品，或提供商业支持。
- 适用场景：这是一个工具库，下游开发者不想开源自己的主程序。
- 优点：比GPL友好得多，是商业软件生态中常见的“附加组件”模式。
模式 5：JSON 许可证 + 商业（已过时，但作为反面案例）
- 代表项目：早期的JSON库（程序员必须喊一声“Good, not Evil”）
- 逻辑：开源协议中加入“仅限善意使用”或类似主观条款。
- 教训：主观性条款（如 “not Evil”）极易引发法律争议，且不被OSI（开源促进会）认可。应避免在协议中使用道德、主观判断词汇。
如何决策：一步一步选择
建议按照以下 4 步 进行决策，可以做成一个简单的决策树：
第一步：明确你的“差异化人群”
- 谁是你的核心贡献者？（个人开发者 / 竞品公司）
- 谁是你的付费客户？（大型企业 / 创业公司 / 云厂商）
- 谁可能成为你的竞品？（他们会 fork 并闭源吗？）
第二步：确定你的“最小通用许可”
- 想最大化采用：选 MIT / Apache 2.0 作为基础。
- 想保护社区贡献共享：选 GPL / AGPL 作为基础。
- 想防止云厂商白嫖：选 AGPL / SSPL（Server Side Public License，服务器端公共许可证，如MongoDB、Elastic License）。
第三步：设计商业许可的“增值”内容
商业许可必须能解决以下至少一个痛点：
- 合规性：让用户不用担心“GPL传染”。
- 性能：提供更优的版本。
- 嵌入：允许静态链接进专有代码。
- 无限制：免除用户数或集群大小限制。
- 知识产权保护：提供侵权赔偿条款（大型企业最需要）。
第四步：选择组合兼容性
- 不兼容的组合：MPL（Mozilla Public License，Mozilla公共许可证） + GPL（容易冲突）。永远不要同时使用 GPL v2 和 GPL v3。
- 常用的组合：
- GPL v3 + 商业许可（最经典）
- Apache 2.0 + 商业许可（最流行）
- MIT + 商业许可（最简单，但需要功能差异来支撑）
重要注意事项
- 版权归属：如果你在GitHub上使用 GPL 或 AGPL，且接受了外部贡献者提交的 Pull Request（拉取请求），除非有 CLA（贡献者许可协议），否则你不能单方面更改这些贡献的许可证，CLA 应要求贡献者授予你“双重许可”的权力。
- 许可证的“非重叠”性：双许可模式下，用户只能择一获得许可，你不能要求用户同时遵守 GPL 和 商业许可。
- 避免“伪开源”：如果你声称“开源”，但商业许可版本功能远超基础版（如 CRM-Z 模式），会被社区批评为“开源虚假宣传”，建议使用 开放核心 (Open Core) 模型。
- 法律顾问：多许可证组合涉及复杂的法律解释（特别是涉及专利授权、破坏条款、终止条件）。请务必找开源法律专家（如 Chris DiBona 的团队或专业 OSPO律师）审核。
给三种典型人的建议
-
如果你是独立开发者做个人库，想收点咨询费：
- 组合：MIT / Apache 2.0 + 商业支持许可
- 理由：先让人用起来，商业版主要是付费问问题。
-
如果你是初创公司做数据库/中间件，防御云厂商：
- 组合：AGPL v3 + 商业许可
- 理由：借鉴MongoDB模式，防云。
-
如果你是大企业做开放核心平台，需要社区贡献：
- 组合：Apache 2.0（核心）+ SSPL 或 BSL（Business Source License，商业源代码许可证，附加功能）
- 理由：分区明确，社区不反感，商业有壁垒。
一个实用的检验方法：把你的许可证组合写成一个 README 段落，请一个非技术背景的律师读一下，如果他能 30 秒内说出“哪类人可以用、用不了”，你的组合就成功了。
